From guido@python.org Sat Jul 1 00:02:50 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 18:02:50 -0500 Subject: [Python-Dev] Idle breakage In-Reply-To: Your message of "Fri, 30 Jun 2000 23:39:26 +0200." <049601bfe2db$acea1380$f2a6b5d4@hagrid> References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> Message-ID: <200006302302.SAA21232@cj20424-a.reston1.va.home.com> > confirmed. SRE implements $ exactly as described in > the library reference, RE doesn't ;-) All this is done to match what Perl does. :-( > patch coming within 30 minutes. Saw it. Thanks! But I still get warnings in IDLE: Failed to load extension 'ParenMatch' Traceback (most recent call last): File "../Tools/idle/EditorWindow.py", line 529, in load_standard_extensions self.load_extension(name) File "../Tools/idle/EditorWindow.py", line 539, in load_extension mod = __import__(name, globals(), locals(), []) File "/projects/python/develop/guido/src/Tools/idle/ParenMatch.py", line 15, in ? import PyParse File "/projects/python/develop/guido/src/Tools/idle/PyParse.py", line 14, in ? _synchre = re.compile(r""" File "./../Lib/sre.py", line 54, in compile return _compile(pattern, flags) File "./../Lib/sre.py", line 86, in _compile p = sre_compile.compile(pattern, flags) File "./../Lib/sre_compile.py", line 217, in compile _compile(code, p.data, flags) File "./../Lib/sre_compile.py", line 121, in _compile emit(ATCODES[AT_MULTILINE[av]]) KeyError: at_boundary --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Sat Jul 1 00:10:30 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 18:10:30 -0500 Subject: [Python-Dev] Oops on AIX In-Reply-To: Your message of "Fri, 30 Jun 2000 19:52:15 +0200." <200006301752.TAA22474@python.inrialpes.fr> References: <200006301752.TAA22474@python.inrialpes.fr> Message-ID: <200006302310.SAA21344@cj20424-a.reston1.va.home.com> > After the CVS commit storm that occurred during the last 3 days, > I wanted to validate the current build on AIX. And I am stalled. > > I am not sure, but it seems like the errors I get relate with the > latest 64-bit support patches, and I don't dare to suggest corrections > in this area, so I welcome any help... let me suggest patches... If these work, please check them in: > xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c > "methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed. Index: methodobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/methodobject.c,v retrieving revision 2.28 diff -c -r2.28 methodobject.c *** methodobject.c 2000/06/30 15:01:00 2.28 --- methodobject.c 2000/06/30 22:09:55 *************** *** 180,186 **** if (x == -1) return -1; } ! y = _Py_HashPointer(a->m_ml->ml_meth); if (y == -1) return -1; x ^= y; --- 180,186 ---- if (x == -1) return -1; } ! y = _Py_HashPointer((void*)(a->m_ml->ml_meth)); if (y == -1) return -1; x ^= y; > xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c > "./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined. > "./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h. > make: 1254-004 The error code from the last command is 1. Index: posixmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v retrieving revision 2.138 diff -c -r2.138 posixmodule.c *** posixmodule.c 2000/06/29 21:12:41 2.138 --- posixmodule.c 2000/06/30 22:10:39 *************** *** 285,290 **** --- 285,291 ---- #endif /* choose the appropriate stat and fstat functions and return structs */ + #undef STAT #ifdef MS_WIN64 # define STAT _stati64 # define FSTAT _fstati64 --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Sat Jul 1 00:14:05 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 18:14:05 -0500 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: Your message of "Fri, 30 Jun 2000 11:43:14 MST." References: Message-ID: <200006302314.SAA21371@cj20424-a.reston1.va.home.com> > Not that I hope to override the heavy -1, but I don't agree with the second > point. It embodies a huge amount of knowledge that is needed to write > portable code. As such, IMO, it _does_ belong in the standard library. How > is it different in its nature from sys.platform, which is only a much weaker > version of the same concept? A more subtle way of stating my opinion could be: if we were to do something in the standard distribution about the problems that this is addressing, I think we would do it in a much more direct fashion, e.g. by making the appropriate enquiry functions directly accessible. --Guido van Rossum (home page: http://www.python.org/~guido/) From Fredrik Lundh" <046a01bfe2d9$88302360$f2a6b5d4@hagrid><049601bfe2db$acea1380$f2a6b5d4@hagrid><200006302302.SAA21232@cj20424-a.reston1.va.home.com><04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid><050501bfe2e3$b2517680$f2a6b5d4@hagrid> <14685.8480.389966.608982@anthem.concentric.net> Message-ID: <056501bfe2ec$5876c080$f2a6b5d4@hagrid> barry wrote: > Go ahead and check it in. I'll run idle and see wot hoppens. well? can I go to sleep now? please? From guido@python.org Sat Jul 1 01:35:35 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 19:35:35 -0500 Subject: [Python-Dev] Idle breakage In-Reply-To: Your message of "Sat, 01 Jul 2000 01:35:49 +0200." <056501bfe2ec$5876c080$f2a6b5d4@hagrid> References: <20000630143148.A9725@acs.ucalgary.ca><046a01bfe2d9$88302360$f2a6b5d4@hagrid><049601bfe2db$acea1380$f2a6b5d4@hagrid><200006302302.SAA21232@cj20424-a.reston1.va.home.com><04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid><050501bfe2e3$b2517680$f2a6b5d4@hagrid> <14685.8480.389966.608982@anthem.concentric.net> <056501bfe2ec$5876c080$f2a6b5d4@hagrid> Message-ID: <200007010035.TAA22470@cj20424-a.reston1.va.home.com> > barry wrote: > > > Go ahead and check it in. I'll run idle and see wot hoppens. > > well? can I go to sleep now? please? Yes. Thanks! --Guido van Rossum (home page: http://www.python.org/~guido/) From nascheme@enme.ucalgary.ca Sat Jul 1 00:41:54 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 17:41:54 -0600 Subject: [Python-Dev] Updating patches on SF Message-ID: <20000630174154.A18362@acs.ucalgary.ca> WTF is going on? I did successfully update one of my patches but now that feature no longer seems to work. I get the message: Patch Uploaded Successfully Added Patch Could Not Send Patch Update and the old patch remains. Neil From nascheme@enme.ucalgary.ca Sat Jul 1 00:46:43 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 17:46:43 -0600 Subject: [Python-Dev] Updating patches on SF In-Reply-To: <20000630174154.A18362@acs.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Fri, Jun 30, 2000 at 05:41:54PM -0600 References: <20000630174154.A18362@acs.ucalgary.ca> Message-ID: <20000630174643.A18492@acs.ucalgary.ca> Killing the disk and memory cache seemed to fix the problem. Neil From Vladimir.Marangozov@inrialpes.fr Sat Jul 1 01:13:37 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 02:13:37 +0200 (CEST) Subject: [Python-Dev] test_array failure on AIX Message-ID: <200007010013.CAA28135@python.inrialpes.fr> Any advice as to where I should look at and/or how to try fixing this? ~/python/CVS> ./python Lib/test/test_array.py **************************************** array after append: array('c', 'c') char array with 10 bytes of TESTFN appended: array('c', 'cThe quick ') char array with list appended: array('c', 'cThe quick abc') array of c after inserting another: array('c', 'ccThe quick abc') array of c converted to a list: ['c', 'c', 'T', 'h', 'e', ' ', 'q', 'u', 'i', 'c', 'k', ' ', 'a', 'b', 'c'] array of c converted to a string: 'ccThe quick abc' **************************************** array after append: array('b', [1]) array of b after inserting another: array('b', [1, 1]) array of b converted to a list: [1, 1] array of b converted to a string: '\001\001' overflow test: array('b', [-128L]) Traceback (most recent call last): File "Lib/test/test_array.py", line 137, in ? main() File "Lib/test/test_array.py", line 13, in main testtype(type, 1) File "Lib/test/test_array.py", line 132, in testtype testoverflow(type, signedLowerLimit, signedUpperLimit) File "Lib/test/test_array.py", line 25, in testoverflow raise TestFailed, "array(%s) overflowed assigning %s" %\ test_support -- test failed: array('b') overflowed assigning -128L -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido@python.org Sat Jul 1 02:19:52 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 20:19:52 -0500 Subject: [Python-Dev] test_array failure on AIX In-Reply-To: Your message of "Sat, 01 Jul 2000 02:13:37 +0200." <200007010013.CAA28135@python.inrialpes.fr> References: <200007010013.CAA28135@python.inrialpes.fr> Message-ID: <200007010119.UAA24318@cj20424-a.reston1.va.home.com> > Any advice as to where I should look at and/or how to try fixing this? > > > ~/python/CVS> ./python Lib/test/test_array.py > **************************************** > array after append: array('c', 'c') > char array with 10 bytes of TESTFN appended: array('c', 'cThe quick ') > char array with list appended: array('c', 'cThe quick abc') > array of c after inserting another: array('c', 'ccThe quick abc') > array of c converted to a list: ['c', 'c', 'T', 'h', 'e', ' ', 'q', 'u', 'i', 'c', 'k', ' ', 'a', 'b', 'c'] > array of c converted to a string: 'ccThe quick abc' > **************************************** > array after append: array('b', [1]) > array of b after inserting another: array('b', [1, 1]) > array of b converted to a list: [1, 1] > array of b converted to a string: '\001\001' > overflow test: array('b', [-128L]) > Traceback (most recent call last): > File "Lib/test/test_array.py", line 137, in ? > main() > File "Lib/test/test_array.py", line 13, in main > testtype(type, 1) > File "Lib/test/test_array.py", line 132, in testtype > testoverflow(type, signedLowerLimit, signedUpperLimit) > File "Lib/test/test_array.py", line 25, in testoverflow > raise TestFailed, "array(%s) overflowed assigning %s" %\ > test_support -- test failed: array('b') overflowed assigning -128L Look at b_setitem() in arraymodule.c. What is CHAR_MIN? Do you perchance have unsigned characters??? If so, let's just replace CHAR_MIN with -128 and CHAR_MAX with 127. --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein@lyra.org Sat Jul 1 01:32:24 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 30 Jun 2000 17:32:24 -0700 Subject: [Python-Dev] proper CVS usage is a must! (was: CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32) In-Reply-To: <395CB46B.34053D3E@lemburg.com>; from mal@lemburg.com on Fri, Jun 30, 2000 at 04:53:31PM +0200 References: <200006301029.DAA25494@slayer.i.sourceforge.net> <20000630142154.968F831047C@bireme.oratrix.nl> <395CB46B.34053D3E@lemburg.com> Message-ID: <20000630173224.O29590@lyra.org> On Fri, Jun 30, 2000 at 04:53:31PM +0200, M.-A. Lemburg wrote: > > Why was the change that occurred in revision 2.31 reverted? Accident? > > > > The change log said: > > Jack Jansen: Use include "" instead of <>; and staticforward declarations > > Accident... I'll revert that change. This is symptomatic of people not being careful with their CVS usage. *ALWAYS* do a "cvs update" before any commits. If the file has changed while you're working on it, CVS will merge the changes in with yours. You will be notified if there were any conflicts. But this is a MUST. We've seen this reversal of changes twice now. Only through the careful eye of some -checkins watchers has that fact turned up. If those people weren't watching, we'd be lost. If you're going to commit changes to Python, then please take the responsibility to use CVS correctly. Thanks! -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sat Jul 1 01:34:10 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 30 Jun 2000 17:34:10 -0700 Subject: [Python-Dev] attribution? (was: CVS: python/dist/src/Objects unicodeobject.c,2.32,2.33) In-Reply-To: <200006301458.HAA12572@slayer.i.sourceforge.net>; from lemburg@users.sourceforge.net on Fri, Jun 30, 2000 at 07:58:23AM -0700 References: <200006301458.HAA12572@slayer.i.sourceforge.net> Message-ID: <20000630173410.P29590@lyra.org> On Fri, Jun 30, 2000 at 07:58:23AM -0700, M.-A. Lemburg wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv12549/Objects > > Modified Files: > unicodeobject.c > Log Message: > Marc-Andre Lemburg : > A previous patch by Jack Jansen was accidently reverted. Is placing your email address into the log message really useful? After all, the checkin is already labeled as yours. I'm all for complete log messages, but scattering emails in there is a bit redundant. Certainly, if you commit somebody *else's* patch, then put their name in. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov@inrialpes.fr Sat Jul 1 01:37:39 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 02:37:39 +0200 (CEST) Subject: [Python-Dev] test_array failure on AIX In-Reply-To: <200007010119.UAA24318@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 30, 2000 08:19:52 PM Message-ID: <200007010037.CAA28255@python.inrialpes.fr> Guido van Rossum wrote: > > Look at b_setitem() in arraymodule.c. > > What is CHAR_MIN? > > Do you perchance have unsigned characters??? This answers your question: /usr/include/sys/limits.h:#define CHAR_MIN (0) /usr/include/sys/limits.h:#define SCHAR_MIN (-SCHAR_MAX - 1) > > If so, let's just replace CHAR_MIN with -128 and CHAR_MAX with 127. Yes! I #undef/define'd them like this in arraymodule.c and the test passes. Thanks! -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein@lyra.org Sat Jul 1 01:40:25 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 30 Jun 2000 17:40:25 -0700 Subject: [Python-Dev] Checked in new PC\config.h In-Reply-To: ; from mhammond@skippinet.com.au on Sat, Jul 01, 2000 at 01:48:43AM +1000 References: Message-ID: <20000630174025.Q29590@lyra.org> On Sat, Jul 01, 2000 at 01:48:43AM +1000, Mark Hammond wrote: > Hi all, > I noticed that PC\config.h still had a reference to "Python16.lib". I > simply checked in a new version without submitting a patch or following any > other process. I hope this was appropriate. If this isn't "proper", then the process is broken. IMO, patches are for people without commit access, or when a committer wants some feedback on their patch. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond@skippinet.com.au Sat Jul 1 02:10:08 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sat, 1 Jul 2000 11:10:08 +1000 Subject: [Python-Dev] Windows build issues In-Reply-To: <200006302133.QAA20696@cj20424-a.reston1.va.home.com> Message-ID: > > Also, I get a few warnings when compiling. One is about an /IZ > > (I think) option being ignored. There are a few other warnings > > as well which I didn't write down. > > Probably 6.0 flags that 5.0 doesn't have. What can we do? This was probably "/ZI". "/ZI" means "symbolic information for edit-and-continue" and is only VC6. "/Zi" means "symbolic information", and is in _all_ VC versions. /ZI doesnt give us much for Python. Im my experience, changing Pythion binaries while debugging is cute, but pretty useless as often a .py file _also_ needs changing, and Python doesnt really support "edit-and-continue" in the same way. MSVC kindly bumps a "/Zi" option to "/ZI" automatically and silently when doing the VC5->VC6 updgrade So I can see no reason not to use "/Zi" for both. From the GUI, it should be obvious - its the symbolic debug option without edit-and-continue. Mark. From Vladimir.Marangozov@inrialpes.fr Sat Jul 1 02:51:07 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 03:51:07 +0200 (CEST) Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: from "Ka-Ping Yee" at Jun 29, 2000 05:44:35 PM Message-ID: <200007010151.DAA00574@python.inrialpes.fr> Ka-Ping Yee wrote: > > On 30 Jun 2000, Michael Hudson wrote: > > Yup, that works fine. Don't understand the details - and as I have my > > graduation ceremony tomorrow I'm going to go to bed and leave learning > > them until some other occasion! > > Cool. > > Okay, i just discovered sunau.py. Here's my real shot at > test_linuxaudiodev.py. Can you give this a try? > > > ---- test_linuxaudiodev.py ---- > from test_support import verbose, findfile, TestFailed > import linuxaudiodev > import os, sunau Yes, but this uses sunau which assumes the audioop.c module is enabled (imported by readframes(), sunau.py line 259) which might not be the case. Besides, Michael reported that it doesn't work quite right. So I'd blindly vote for Michael Hudson's improved version which uses only linuxaudiodev and plays the test sound without noise: ----------[ test_linuxaudiodev.py posted by Michael Hudson ]----------- from test_support import verbose, findfile, TestFailed import linuxaudiodev import os,struct def play_au_file(path): fp = open(path, "r") # Read the .au file header. header = fp.read(24) hdrsize, length, encoding, rate, channels = \ struct.unpack(">xxxxiiiii", header) fp.read(hdrsize - 24) data = fp.read() fp.close() # Set the data format according to the code in the .au header. if encoding == 1: size, fmt = 8, linuxaudiodev.AFMT_MU_LAW elif encoding == 2: size, fmt = 8, linuxaudiodev.AFMT_S8 elif encoding == 3: size, fmt = 16, linuxaudiodev.AFMT_S16_BE else: raise "audio format not supported" dsp = linuxaudiodev.open("w") dsp.setparameters(rate, size, channels, fmt) dsp.write(data) dsp.close() def test(): play_au_file(findfile('audiotest.au')) test() ---------------------------------------------------------------------- -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido@python.org Sat Jul 1 04:35:33 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 22:35:33 -0500 Subject: [Python-Dev] Sorry. No Release. Message-ID: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> I can't say how disappointed I am: at the very last moment I have heard that I am not allowed to release Python 2.0b1 on July 1 as planned. Some last-minute issues have come up regarding the licensing from CNRI. BeOpen is going to resolve these issues as soon as possible, but it could be weeks... In the mean time, I thank everybody who worked very hard to make this release a success. We will continue to work on the SourceForge CVS repository as before. There will be a 2.0 release as soon as possible! --Guido van Rossum (home page: http://www.python.org/~guido/) From Vladimir.Marangozov@inrialpes.fr Sat Jul 1 04:07:28 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 05:07:28 +0200 (CEST) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 30, 2000 10:35:33 PM Message-ID: <200007010307.FAA01904@python.inrialpes.fr> Guido van Rossum wrote: > > I can't say how disappointed I am: at the very last moment I have > heard that I am not allowed to release Python 2.0b1 on July 1 as > planned. Some last-minute issues have come up regarding the licensing > from CNRI. BeOpen is going to resolve these issues as soon as > possible, but it could be weeks... Doh. The premature 2.0 release excitement died prematurely > > In the mean time, I thank everybody who worked very hard to make this > release a success. We will continue to work on the SourceForge CVS > repository as before. There will be a 2.0 release as soon as > possible! Maybe it would be good to think about and define a short-term plan of action, given that we'll have a "major" release and that now we have some more time, cf. the previous discussion on the subject. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw@beopen.com Sat Jul 1 04:13:44 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 23:13:44 -0400 (EDT) Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> <050501bfe2e3$b2517680$f2a6b5d4@hagrid> <14685.8480.389966.608982@anthem.concentric.net> <056501bfe2ec$5876c080$f2a6b5d4@hagrid> Message-ID: <14685.25064.334520.654960@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: >> Go ahead and check it in. I'll run idle and see wot hoppens. FL> well? can I go to sleep now? please? Sorry, I was off-line for a while. I see Guido gave the word, but just to follow up, yes Idle works for me too. Thanks! From mhammond@skippinet.com.au Sat Jul 1 05:56:18 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sat, 1 Jul 2000 14:56:18 +1000 Subject: [Python-Dev] Python for Windows extensions updated for Python 2.0 Message-ID: Hi all, FYI - Ive just finished checking into CVS all the changes necessary for Python 2.0. So if you update the complete Python tree from sourceforge and the Win32 extensions trees from pythonpros, you should get successful builds of everything. I recommend that you seek-and-destroy Py*16* on your machine - this will ensure that if you have missed any extension modules, you get a nice "Python16.dll not found", rather than the thread-state crash that happens if that DLL does indeed still exist. Mark. From petrilli@amber.org Sat Jul 1 06:00:16 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Sat, 1 Jul 2000 01:00:16 -0400 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <14685.1021.870885.796187@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jun 30, 2000 at 04:33:01PM -0400 References: <200006302126.QAA20621@cj20424-a.reston1.va.home.com> <14685.1021.870885.796187@bitdiddle.concentric.net> Message-ID: <20000701010016.A4402@trump.amber.org> Jeremy Hylton [jeremy@beopen.com] wrote: > Perhaps I am too easy-going, but I consider the 2.0 release a > 'dot-release' masquerading as a major revision. It might be a little > silly, but it seems even sillier to preserve a naming scheme that > makes users think that the technology is immature. I have to say I always thought Guido was a bit conservative... 1.3 -> 1.4 would have been a 3.x release from any "other company", and certainly 1.4 to 1.5 has some major new things (exception changes, etc). I think X.Y means X MAY introduce backward incompatibility, but doesn't have to. It just means major new functionality... I've seen a few of our customers go... "But wait, it's only at 1.5"... yeah, so? Chris -- | Christopher Petrilli | petrilli@amber.org From skip@mojam.com (Skip Montanaro) Sat Jul 1 08:07:00 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sat, 1 Jul 2000 02:07:00 -0500 (CDT) Subject: [Python-Dev] barest beginnings of test coverage results Message-ID: <14685.39060.785993.960514@beluga.mojam.com> I compiled the Python interpreter with the flags necessary to get statement and branch coverage information then generated coverage files using the GNU coverage tool, gcov. If you'd like a peek at the coverage files, have a look at http://www.musi-cal.com/~skip/python/Python/dist/src/ The statement/branch coverage information is for one run of executing Lib/test/regrtest.py. Anywhere there is a C source file with coverage info the filename will end in ".c.gcov". I will eventually segregate the coverage files into a parallel tree and not mix them with the build tree. I would also like to adjust the regrtest.py stuff to generate statement coverage for .py files using my trace module: http://www.musi-cal.com/~skip/python/trace.py. For an example of how far this sort of thing can go, poke around in VTK's nightly quality dashboard: http://public.kitware.com/vtk/quality/MostRecentResults/ The VTK gang has been doing this for a couple years and now displays the following information: * pass/fail and faster/slower summaries of their nightly regression tests * code coverage information (using gcc/gcov as I'm doing) * all this on eight different Unix platforms each night Skip From martin@loewis.home.cs.tu-berlin.de Sat Jul 1 08:47:20 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 1 Jul 2000 09:47:20 +0200 Subject: [Python-Dev] Minidom and Unicode Message-ID: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> While trying the minidom parser from the current CVS, I found that repr apparently does not work for nodes: Python 2.0b1 (#29, Jun 30 2000, 10:48:11) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from xml.dom.minidom import parse >>> d=parse("/usr/src/python/Doc/tools/sgmlconv/conversion.xml") >>> d.childNodes [Traceback (most recent call last): File "", line 1, in ? TypeError: __repr__ returned non-string (type unicode) The problem here is that __repr__ is computed as def __repr__( self ): return "" and that self.tagName is u'conversion', so the resulting string is a unicode string. I'm not sure whose fault that is: either __repr__ should accept unicode strings, or minidom.Element.__repr__ should be changed to return a plain string, e.g. by converting tagname to UTF-8. In any case, I believe __repr__ should 'work' for these objects. Regards, Martin From Fredrik Lundh" Message-ID: <00ab01bfe33c$3fc85620$f2a6b5d4@hagrid> guido wrote: > I can't say how disappointed I am: at the very last moment I have > heard that I am not allowed to release Python 2.0b1 on July 1 as > planned. Some last-minute issues have come up regarding the licensing > from CNRI. BeOpen is going to resolve these issues as soon as > possible, but it could be weeks... what's the legal status of the material on the SF site. can people download and redistribute snapshots of the CVS repository, or is it in some kind of legal limbo at this time? From gstein@lyra.org Sat Jul 1 10:09:23 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 02:09:23 -0700 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: <200006301748.KAA11055@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Fri, Jun 30, 2000 at 10:48:54AM -0700 References: <200006301748.KAA11055@slayer.i.sourceforge.net> Message-ID: <20000701020923.S29590@lyra.org> While I'm very glad that I suggested PyLong_FromVoidPtr() for issues like this, I think that returning an HKEY should probably use a PyCObject. You will then be able to supply a "free" function that can close the HKEY. Cheers, -g On Fri, Jun 30, 2000 at 10:48:54AM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/PC > In directory slayer.i.sourceforge.net:/tmp/cvs-serv11047/PC > > Modified Files: > msvcrtmodule.c _winreg.c > Log Message: > [*** Not tested as I don't have Windows running right now! ***] > > Trent Mick : > > Fix PC/msvcrtmodule.c and PC/winreg.c for Win64. Basically: > > - sizeof(HKEY) > sizeof(long) on Win64, so use PyLong_FromVoidPtr() > instead of PyInt_FromLong() to return HKEY values on Win64 > > - Check for string overflow of an arbitrary registry value (I know > that ensuring that a registry value does not overflow 2**31 characters > seems ridiculous but it is *possible*). > > Closes SourceForge patch #100517. >... -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sat Jul 1 11:24:38 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 03:24:38 -0700 Subject: [Python-Dev] ML replies (was: CVS: python/dist/src/PCbuild readme.txt,1.5,1.6) In-Reply-To: <14684.43443.919858.897738@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Jun 30, 2000 at 10:07:47AM -0400 References: <14684.43443.919858.897738@anthem.concentric.net> Message-ID: <20000701032438.U29590@lyra.org> On Fri, Jun 30, 2000 at 10:07:47AM -0400, Barry A. Warsaw wrote: > > >>>>> "MH" == Mark Hammond writes: > > MH> [I wishing mailing-lists would agree on how they handle > MH> reply-to :-] > > It's fundamentally broken, but the problem is in the mail readers > (MUA). There's no header (that I'm aware of) that portably tells an > MUA - "Hey, for a group follow up, don't go to the original list, go > to THIS one instead, but for an individual followup (i.e. reply) still > address that to the original author." > > This is one reason why munging reply-to is evil. But in this case > we've agreed that following up to python-dev is more important than > preserving the ability to reply to the author. What about the Mail-Followup-To header? That can be helpful for some newsreaders (e.g. Mutt). Dunno how many observe it. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sat Jul 1 11:29:59 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 03:29:59 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml/sax __init__.py,NONE,1.1 In-Reply-To: <200006291933.MAA05055@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Thu, Jun 29, 2000 at 12:33:45PM -0700 References: <200006291933.MAA05055@slayer.i.sourceforge.net> Message-ID: <20000701032959.V29590@lyra.org> Do you really want to import that many items into the xml.sax module? IMO, be specific on what is imported into xml.sax for *convenience*. Don't just import the world. Also note that the import for SAXParseException is redundant. Cheers, -g On Thu, Jun 29, 2000 at 12:33:45PM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Lib/xml/sax > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5045 > > Added Files: > __init__.py > Log Message: > > Package docstring and initialization. > > > --- NEW FILE --- > """Simple API for XML (SAX) implementation for Python. > > This module provides an implementation of the SAX 2 interface; > information about the Java version of the interface can be found at > http://www.megginson.com/SAX/. The Python version of the interface is > documented at <...>. > > This package contains the following modules: > > saxutils -- Implementation of the convenience functions normally used > to work with SAX. > > saxlib -- Implementation of the shared SAX 2 classes. > > drv_pyexpat -- Driver that allows use of the Expat parser with the classes > defined in saxlib. > > """ > > from handler import * > from expatreader import * > from _exceptions import * > from saxutils import * > from _exceptions import SAXParseException > import xmlreader > > > _______________________________________________ > Python-checkins mailing list > Python-checkins@python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From esr@thyrsus.com Sat Jul 1 11:52:22 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sat, 1 Jul 2000 06:52:22 -0400 Subject: [Python-Dev] ML replies (was: CVS: python/dist/src/PCbuild readme.txt,1.5,1.6) In-Reply-To: <20000701032438.U29590@lyra.org>; from gstein@lyra.org on Sat, Jul 01, 2000 at 03:24:38AM -0700 References: <14684.43443.919858.897738@anthem.concentric.net> <20000701032438.U29590@lyra.org> Message-ID: <20000701065222.A31221@thyrsus.com> Greg Stein : > > This is one reason why munging reply-to is evil. But in this case > > we've agreed that following up to python-dev is more important than > > preserving the ability to reply to the author. > > What about the Mail-Followup-To header? That can be helpful for some > newsreaders (e.g. Mutt). Dunno how many observe it. Eudora honors it, too. It's not an official standard, unfortunately; I was on the IETF committee where that battle was fought to a bloody draw. But it's the best you can do. -- Eric S. Raymond "The best we can hope for concerning the people at large is that they be properly armed." -- Alexander Hamilton, The Federalist Papers at 184-188 From mal@lemburg.com Sat Jul 1 12:51:43 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 13:51:43 +0200 Subject: [Python-Dev] proper CVS usage is a must! (was: CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32) References: <200006301029.DAA25494@slayer.i.sourceforge.net> <20000630142154.968F831047C@bireme.oratrix.nl> <395CB46B.34053D3E@lemburg.com> <20000630173224.O29590@lyra.org> Message-ID: <395DDB4F.F9186544@lemburg.com> Greg Stein wrote: > > On Fri, Jun 30, 2000 at 04:53:31PM +0200, M.-A. Lemburg wrote: > > > Why was the change that occurred in revision 2.31 reverted? Accident? > > > > > > The change log said: > > > Jack Jansen: Use include "" instead of <>; and staticforward declarations > > > > Accident... I'll revert that change. > > This is symptomatic of people not being careful with their CVS usage. > > *ALWAYS* do a "cvs update" before any commits. If the file has changed while > you're working on it, CVS will merge the changes in with yours. You will be > notified if there were any conflicts. > > But this is a MUST. We've seen this reversal of changes twice now. Only > through the careful eye of some -checkins watchers has that fact turned up. > If those people weren't watching, we'd be lost. > > If you're going to commit changes to Python, then please take the > responsibility to use CVS correctly. Hey, Greg, stay cool :-) The accident happened because I had to modify Trent's patch to make it apply correctly and I forgot to update the *copy* of the CVS tree in which I edited the changes. I always do a cvs update to my local CVS version before the checkins, in fact, the small script I posted to this list does the checking for me and won't accept the checkins if the local version is out of sync. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat Jul 1 12:55:02 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 13:55:02 +0200 Subject: [Python-Dev] attribution? (was: CVS: python/dist/src/Objects unicodeobject.c,2.32,2.33) References: <200006301458.HAA12572@slayer.i.sourceforge.net> <20000630173410.P29590@lyra.org> Message-ID: <395DDC16.2768421C@lemburg.com> Greg Stein wrote: > > On Fri, Jun 30, 2000 at 07:58:23AM -0700, M.-A. Lemburg wrote: > > Update of /cvsroot/python/python/dist/src/Objects > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv12549/Objects > > > > Modified Files: > > unicodeobject.c > > Log Message: > > Marc-Andre Lemburg : > > A previous patch by Jack Jansen was accidently reverted. > > Is placing your email address into the log message really useful? After all, > the checkin is already labeled as yours. > > I'm all for complete log messages, but scattering emails in there is a bit > redundant. > > Certainly, if you commit somebody *else's* patch, then put their name in. I wasn't sure whether the person who checks in patches appears in the CVS log, so I added the name and email in front of the message. I'll remove the note in my checkin script. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat Jul 1 12:56:44 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 13:56:44 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <200006302314.SAA21371@cj20424-a.reston1.va.home.com> Message-ID: <395DDC7C.4285D56A@lemburg.com> Guido van Rossum wrote: > > > Not that I hope to override the heavy -1, but I don't agree with the second > > point. It embodies a huge amount of knowledge that is needed to write > > portable code. As such, IMO, it _does_ belong in the standard library. How > > is it different in its nature from sys.platform, which is only a much weaker > > version of the same concept? > > A more subtle way of stating my opinion could be: if we were to do > something in the standard distribution about the problems that this is > addressing, I think we would do it in a much more direct fashion, > e.g. by making the appropriate enquiry functions directly accessible. platform.py does use the available functions on a couple of platforms... and it itself provides direct enquiry functions for Python programs to use. Perhaps I'm misunderstanding you here. Anyway, it's there for non-core programs to use and so far I think the core lib has managed to switch on sys.platform and do the right thing, so platform.py may not be all that necessary in the core. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat Jul 1 13:02:55 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 14:02:55 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> Message-ID: <395DDDEF.4ABB5BFC@lemburg.com> "Martin v. Loewis" wrote: > > While trying the minidom parser from the current CVS, I found that > repr apparently does not work for nodes: > > Python 2.0b1 (#29, Jun 30 2000, 10:48:11) [GCC 2.95.2 19991024 (release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> from xml.dom.minidom import parse > >>> d=parse("/usr/src/python/Doc/tools/sgmlconv/conversion.xml") > >>> d.childNodes > [Traceback (most recent call last): > File "", line 1, in ? > TypeError: __repr__ returned non-string (type unicode) > > The problem here is that __repr__ is computed as > > def __repr__( self ): > return "" > > and that self.tagName is u'conversion', so the resulting string is a > unicode string. > > I'm not sure whose fault that is: either __repr__ should accept > unicode strings, or minidom.Element.__repr__ should be changed to > return a plain string, e.g. by converting tagname to UTF-8. In any > case, I believe __repr__ should 'work' for these objects. Note that __repr__ has to return a string object (and IIRC this is checked in object.c or abstract.c). The correct way to get there is to simply return str(...) or to have a switch on the type of self.tagName and then call .encode(). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@beopen.com Sat Jul 1 14:21:12 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 01 Jul 2000 08:21:12 -0500 Subject: [Python-Dev] barest beginnings of test coverage results In-Reply-To: Your message of "Sat, 01 Jul 2000 02:07:00 EST." <14685.39060.785993.960514@beluga.mojam.com> References: <14685.39060.785993.960514@beluga.mojam.com> Message-ID: <200007011321.IAA09485@cj20424-a.reston1.va.home.com> > I compiled the Python interpreter with the flags necessary to get statement > and branch coverage information then generated coverage files using the GNU > coverage tool, gcov. If you'd like a peek at the coverage files, have a > look at > > http://www.musi-cal.com/~skip/python/Python/dist/src/ > > The statement/branch coverage information is for one run of executing > Lib/test/regrtest.py. Wow, Skip! Very impressive. But there's soooooo much data... How do we find the gems? Should we just look at one file per day and try to add testcases that get rid of the ##### comments? Is there a way to sort the files based on the number or significance of the ##### comments? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From akuchlin@mems-exchange.org Sat Jul 1 13:28:29 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat, 1 Jul 2000 08:28:29 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <200007010335.WAA29653@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 10:35:33PM -0500 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> Message-ID: <20000701082829.C2345@newcnri.cnri.reston.va.us> On Fri, Jun 30, 2000 at 10:35:33PM -0500, Guido van Rossum wrote: >I can't say how disappointed I am: at the very last moment I have >heard that I am not allowed to release Python 2.0b1 on July 1 as >planned. Some last-minute issues have come up regarding the licensing I'm not convinced this delay is wholly a bad thing. Did Barry ever track down the mysterious crashes he was seeing from running the test suite? And it's more time to experiment with the garbage collection, hunt for SRE bugs, and so forth. --amk From martin@loewis.home.cs.tu-berlin.de Sat Jul 1 13:22:39 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 1 Jul 2000 14:22:39 +0200 Subject: [Python-Dev] Minidom and Unicode In-Reply-To: <395DDDEF.4ABB5BFC@lemburg.com> (mal@lemburg.com) References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> Message-ID: <200007011222.OAA11088@loewis.home.cs.tu-berlin.de> > Note that __repr__ has to return a string object (and IIRC > this is checked in object.c or abstract.c). The correct way > to get there is to simply return str(...) or to have a > switch on the type of self.tagName and then call .encode(). Ok. I believe tagName will be always a Unicode object (as mandated by the DOM API), so I propose patch 100706 (http://sourceforge.net/patch/?func=detailpatch&patch_id=100706&group_id=5470) Regards, Martin From guido@beopen.com Sat Jul 1 14:46:29 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 01 Jul 2000 08:46:29 -0500 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: Your message of "Sat, 01 Jul 2000 08:28:29 -0400." <20000701082829.C2345@newcnri.cnri.reston.va.us> References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> Message-ID: <200007011346.IAA09576@cj20424-a.reston1.va.home.com> > I'm not convinced this delay is wholly a bad thing. Did Barry ever > track down the mysterious crashes he was seeing from running the test > suite? And it's more time to experiment with the garbage collection, > hunt for SRE bugs, and so forth. But that's what beta releases are for, right? The result now is that fewer people will try out the code than if it were released today, and the final release will undoubtedly be delayed again. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From Fredrik Lundh" <395DDDEF.4ABB5BFC@lemburg.com> Message-ID: <010601bfe35b$46727ae0$f2a6b5d4@hagrid> mal wrote: > > I'm not sure whose fault that is: either __repr__ should accept > > unicode strings, or minidom.Element.__repr__ should be changed to > > return a plain string, e.g. by converting tagname to UTF-8. In any > > case, I believe __repr__ should 'work' for these objects. >=20 > Note that __repr__ has to return a string object (and IIRC > this is checked in object.c or abstract.c). The correct way > to get there is to simply return str(...) or to have a > switch on the type of self.tagName and then call .encode(). assuming that the goal is to get rid of this restriction in future versions (a string is a string is a string), how about special- casing this in PyObject_Repr: PyObject *res; res =3D (*v->ob_type->tp_repr)(v); if (res =3D=3D NULL) return NULL; --- if (PyUnicode_Check(res)) { PyObject* str; str =3D PyUnicode_AsEncodedString(res, NULL, NULL); if (str) { Py_DECREF(res); res =3D str; } } --- if (!PyString_Check(res)) { PyErr_Format(PyExc_TypeError, "__repr__ returned non-string (type %.200s)", res->ob_type->tp_name); Py_DECREF(res); return NULL; } return res; in this way, people can "do the right thing" in their code, and have it work better in future versions... (just say "+1", and the mad patcher will update the repository) From guido@beopen.com Sat Jul 1 15:13:36 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 01 Jul 2000 09:13:36 -0500 Subject: [Python-Dev] Minidom and Unicode In-Reply-To: Your message of "Sat, 01 Jul 2000 14:52:51 +0200." <010601bfe35b$46727ae0$f2a6b5d4@hagrid> References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> Message-ID: <200007011413.JAA09667@cj20424-a.reston1.va.home.com> > mal wrote: > > > I'm not sure whose fault that is: either __repr__ should accept > > > unicode strings, or minidom.Element.__repr__ should be changed to > > > return a plain string, e.g. by converting tagname to UTF-8. In any > > > case, I believe __repr__ should 'work' for these objects. > > > > Note that __repr__ has to return a string object (and IIRC > > this is checked in object.c or abstract.c). The correct way > > to get there is to simply return str(...) or to have a > > switch on the type of self.tagName and then call .encode(). [/F] > assuming that the goal is to get rid of this restriction in future > versions (a string is a string is a string), how about special- > casing this in PyObject_Repr: > > PyObject *res; > res = (*v->ob_type->tp_repr)(v); > if (res == NULL) > return NULL; > --- > if (PyUnicode_Check(res)) { > PyObject* str; > str = PyUnicode_AsEncodedString(res, NULL, NULL); > if (str) { > Py_DECREF(res); > res = str; > } > } > --- > if (!PyString_Check(res)) { > PyErr_Format(PyExc_TypeError, > "__repr__ returned non-string (type %.200s)", > res->ob_type->tp_name); > Py_DECREF(res); > return NULL; > } > return res; > > in this way, people can "do the right thing" in their code, > and have it work better in future versions... > > (just say "+1", and the mad patcher will update the repository) +1 --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul@prescod.net Sat Jul 1 14:09:20 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 08:09:20 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> Message-ID: <395DED80.A30FB417@prescod.net> "M.-A. Lemburg" wrote: > > Note that __repr__ has to return a string object (and IIRC > this is checked in object.c or abstract.c). The correct way > to get there is to simply return str(...) or to have a > switch on the type of self.tagName and then call .encode(). > ... I prefer the former solution and unless someone screams I will check that in in a few hours. Why can't repr have a special case that converts Unicode strings to "Python strings" automatically. This case is going to byte other people. > Ok. I believe tagName will be always a Unicode object (as mandated by > the DOM API), so I propose patch 100706 > (http://sourceforge.net/patch/?func=detailpatch&patch_id=100706&group_id=5470) I would like Unicode usage to be a userland option for reasons of performance and backwards compatibility. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul@prescod.net Sat Jul 1 14:12:28 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 08:12:28 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> Message-ID: <395DEE3C.E7BAD4C3@prescod.net> Fredrik Lundh wrote: > > ... > > assuming that the goal is to get rid of this restriction in future > versions (a string is a string is a string), how about special- > casing this in PyObject_Repr: This is my prefered solution. +1 from me. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From mhammond@skippinet.com.au Sat Jul 1 14:23:21 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sat, 1 Jul 2000 23:23:21 +1000 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: <20000701020923.S29590@lyra.org> Message-ID: > While I'm very glad that I suggested PyLong_FromVoidPtr() for issues like > this, I think that returning an HKEY should probably use a PyCObject. You > will then be able to supply a "free" function that can close the HKEY. This is exactly what we do. Trents patches are just for the functions that return the underlying handle value as an integer (which is definately a useful thing to be able to do!) Mark. From gstein@lyra.org Sat Jul 1 14:51:11 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 06:51:11 -0700 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: ; from mhammond@skippinet.com.au on Sat, Jul 01, 2000 at 11:23:21PM +1000 References: <20000701020923.S29590@lyra.org> Message-ID: <20000701065111.Z29590@lyra.org> On Sat, Jul 01, 2000 at 11:23:21PM +1000, Mark Hammond wrote: > > While I'm very glad that I suggested PyLong_FromVoidPtr() for issues like > > this, I think that returning an HKEY should probably use a PyCObject. You > > will then be able to supply a "free" function that can close the HKEY. > > This is exactly what we do. Trents patches are just for the functions that > return the underlying handle value as an integer (which is definately a > useful thing to be able to do!) But I don't understand why you want an integer. From the Python programmer's standpoint, they just want a handle, right? The safety of having the "free" function is quite nice. Without it, it would seem to be "easy" to leak handles. Without using PyCObject, we'd need a complete handle type (like the one in win32api or wherever). Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov@inrialpes.fr Sat Jul 1 15:23:16 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 16:23:16 +0200 (CEST) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <200007011346.IAA09576@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 01, 2000 08:46:29 AM Message-ID: <200007011423.QAA05486@python.inrialpes.fr> Guido van Rossum wrote: > > > I'm not convinced this delay is wholly a bad thing. Did Barry ever > > track down the mysterious crashes he was seeing from running the test > > suite? And it's more time to experiment with the garbage collection, > > hunt for SRE bugs, and so forth. > > But that's what beta releases are for, right? The result now is that > fewer people will try out the code than if it were released today, and > the final release will undoubtedly be delayed again. Guido, what about reverting the version number to 2.0a3 ? We're still not in a beta stage, but there *is* a new version ready, which, if not beta, should be an alpha. We're used to see the version bumped a day or two before the release. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From akuchlin@mems-exchange.org Sat Jul 1 14:22:30 2000 From: akuchlin@mems-exchange.org (A.M. Kuchling) Date: Sat, 1 Jul 2000 09:22:30 -0400 Subject: [Python-Dev] sysconfig/SRE bug Message-ID: <200007011322.JAA25612@207-172-146-185.s185.tnt3.ann.va.dialup.rcn.com> sysconfig.py contains a pattern that breaks SRE: >>> import re, pre >>> pre.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}") >>> re.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}") Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.0/sre.py", line 54, in compile return _compile(pattern, flags) ... File "/usr/lib/python2.0/sre_parse.py", line 538, in parse p = _parse(source, state) File "/usr/lib/python2.0/sre_parse.py", line 394, in _parse raise error, "bogus range" Escaping the { and } fix this. This is a problem with the {xxx,yyy} notation for ranges; PCRE looks ahead, and treats it as a literal unless it's followed by digits of the right form. From pypcre.c: /* This function is called when a '{' is encountered in a place where it might start a quantifier. It looks ahead to see if it really is a quantifier or not. It is only a quantifier if it is one of the forms {ddd} {ddd,} or {ddd,ddd} where the ddds are digits. */ I suppose the goal of Perl compatibility means this magical behaviour needs to be preserved? --amk From bwarsaw@beopen.com Sat Jul 1 16:16:46 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sat, 1 Jul 2000 11:16:46 -0400 (EDT) Subject: [Python-Dev] Sorry. No Release. References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> Message-ID: <14686.2910.855580.146653@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> I'm not convinced this delay is wholly a bad thing. Did Barry AK> ever track down the mysterious crashes he was seeing from AK> running the test suite? No, and Purify didn't help, although it did identify a couple of small memory leaks. Nothing more serious than that. One possible source of discrepancy though is that the machine I ran the tests on apparently didn't have enough memory (at 256MB!) to run the entire regrtest under a Purify'd Python. I'm going to continue looking though. -Barry From Fredrik Lundh" Message-ID: <01f701bfe374$a661c500$f2a6b5d4@hagrid> andrew wrote: > sysconfig.py contains a pattern that breaks SRE: >=20 > >>> import re, pre > >>> pre.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}") > > >>> re.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}") > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/lib/python2.0/sre.py", line 54, in compile > return _compile(pattern, flags) > ... > File "/usr/lib/python2.0/sre_parse.py", line 538, in parse > p =3D _parse(source, state) > File "/usr/lib/python2.0/sre_parse.py", line 394, in _parse > raise error, "bogus range" >=20 > Escaping the { and } fix this. This is a problem with the {xxx,yyy} > notation for ranges; PCRE looks ahead, and treats it as a literal > unless it's followed by digits of the right form. From pypcre.c: >=20 > /* This function is called when a '{' is encountered in a place where = it might > start a quantifier. It looks ahead to see if it really is a quantifier = or not. > It is only a quantifier if it is one of the forms {ddd} {ddd,} or = {ddd,ddd} > where the ddds are digits. > */ >=20 > I suppose the goal of Perl compatibility means this magical behaviour > needs to be preserved? I'm not so sure about this one; the $ behaviour is documented in Perl, but this isn't (as far as I can tell, at least). and since it's detected by the parser, it's probably better to change the sysconfig module... (fixing this in the sre_parser isn't exactly trivial, either...) From Fredrik Lundh" <01f701bfe374$a661c500$f2a6b5d4@hagrid> Message-ID: <01fd01bfe375$057389c0$f2a6b5d4@hagrid> I wrote: > I'm not so sure about this one; the $ behaviour is documented > in Perl, but this isn't (as far as I can tell, at least). umm. I suppose "If a curly bracket occurs in any other context, it is treated as a regular character" is documentation enough. please ignore me. From bwarsaw@beopen.com Sat Jul 1 17:16:48 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sat, 1 Jul 2000 12:16:48 -0400 (EDT) Subject: [Python-Dev] Re: ML replies (was: CVS: python/dist/src/PCbuild readme.txt,1.5,1.6) References: <14684.43443.919858.897738@anthem.concentric.net> <20000701032438.U29590@lyra.org> Message-ID: <14686.6512.329946.694266@anthem.concentric.net> [Please remove python-dev from followups, I'm sure most of those folks don't care about this... -BAW] MM-Devers: on python-dev there's been some discussion about the Reply-to: munging that you can select on Mailman lists. Say you've got a python-checkins list that receives CVS log messages automatically. But you don't want discussions about the changes on python-checkins, you want them on python-dev. How can Mailman set up the headers on outgoing messages to get this behavior? It can't. So it fakes it by setting Reply-to: to the address of the discussion list. We now join our conversation already in progress... >>>>> "GS" == Greg Stein writes: GS> What about the Mail-Followup-To header? That can be helpful GS> for some newsreaders (e.g. Mutt). Dunno how many observe it. It looks like VM/Emacs doesn't (which is what I use), but I'm sure that'd be easy to add. I would be most interested to know what Outlook and NS do with it. However Mail-Followup-To: isn't in any RFC that I can find, not even 2076. It can be found in a discussion by Dan Bernstein[1], but that document specifically says that list managers should /not/ set it because this defeats the intended purpose. I agree - given Dan's recommendation. So there is clearly no header that will support the functionality we want. And all this crud has been debated ad-nauseum in several working groups, MUA forums, etc. with no agreement. I almost hesitate even bringing it up here. Few of the discussions that I've read (in a morning's worth of archive surfing) even mention the situation we're trying to address. One potential solution for Mailman might be to lie about the To: address. So in the above scenario, the message would have a To: field set to python-dev even though the message would actually be sent to the python-checkins membership. An elaboration on that would be to set Resent-To: to python-checkins. But those are all hacks, nearly as disgusting as what Mailman currently does. -Barry [1] http://cr.yp.to/proto/replyto.html From skip@mojam.com (Skip Montanaro) Sat Jul 1 17:16:31 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sat, 1 Jul 2000 11:16:31 -0500 (CDT) Subject: [Python-Dev] barest beginnings of test coverage results In-Reply-To: <200007011321.IAA09485@cj20424-a.reston1.va.home.com> References: <14685.39060.785993.960514@beluga.mojam.com> <200007011321.IAA09485@cj20424-a.reston1.va.home.com> Message-ID: <14686.6495.370859.13048@beluga.mojam.com> Guido> But there's soooooo much data... How do we find the gems? Guido> Should we just look at one file per day and try to add testcases Guido> that get rid of the ##### comments? Is there a way to sort the Guido> files based on the number or significance of the ##### comments? All I referred you to yesterday (it was late...) was a CVS tree in which I had built the interpreter with the necessary flags, run regrtest.py, then generated coverage files. The next step is to generate one or more pages of coverage summaries. Then you'll be able to browse something like http://www.musi-cal.com/~skip/python/Python/dist/src/lines.html http://www.musi-cal.com/~skip/python/Python/dist/src/branches.html and zero in on those files with lower than desired coverage. Skip From nascheme@enme.ucalgary.ca Sat Jul 1 17:20:37 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Sat, 1 Jul 2000 10:20:37 -0600 Subject: [Python-Dev] barest beginnings of test coverage results In-Reply-To: <200007011321.IAA09485@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Sat, Jul 01, 2000 at 08:21:12AM -0500 References: <14685.39060.785993.960514@beluga.mojam.com> <200007011321.IAA09485@cj20424-a.reston1.va.home.com> Message-ID: <20000701102037.A28228@acs.ucalgary.ca> On Sat, Jul 01, 2000 at 08:21:12AM -0500, Guido van Rossum wrote: > Wow, Skip! Very impressive. But there's soooooo much data... How do > we find the gems? http://www.musi-cal.com/~skip/python/Python/dist/src/summary.html The summary seems pretty good to me. Neil From skip@mojam.com (Skip Montanaro) Sat Jul 1 17:24:18 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sat, 1 Jul 2000 11:24:18 -0500 (CDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <14686.2910.855580.146653@anthem.concentric.net> References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> Message-ID: <14686.6962.530478.967290@beluga.mojam.com> AK> I'm not convinced this delay is wholly a bad thing. Did Barry ever AK> track down the mysterious crashes he was seeing from running the AK> test suite? BAW> No, and Purify didn't help, although it did identify a couple of BAW> small memory leaks. Nothing more serious than that. One possible BAW> source of discrepancy though is that the machine I ran the tests on BAW> apparently didn't have enough memory (at 256MB!) to run the entire BAW> regrtest under a Purify'd Python. I'm going to continue looking BAW> though. My guess is that -tt triggered a SyntaxError (maybe we should create an IndentationError that is a subclass of SyntaxError?) the .pyc file didn't get generated, but the exception was caught by regrtest and execution continued. That would have caused any test that tried to import the tab-challenged file(s) to fail, right? Would that have been sufficient to provoke the symptoms we saw? -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From skip@mojam.com (Skip Montanaro) Sat Jul 1 17:31:43 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sat, 1 Jul 2000 11:31:43 -0500 (CDT) Subject: [Python-Dev] barest beginnings of test coverage results In-Reply-To: <20000701102037.A28228@acs.ucalgary.ca> References: <14685.39060.785993.960514@beluga.mojam.com> <200007011321.IAA09485@cj20424-a.reston1.va.home.com> <20000701102037.A28228@acs.ucalgary.ca> Message-ID: <14686.7407.760808.838286@beluga.mojam.com> >> Wow, Skip! Very impressive. But there's soooooo much data... How >> do we find the gems? Neil> http://www.musi-cal.com/~skip/python/Python/dist/src/summary.html Neil> The summary seems pretty good to me. ;-) I got to the problem after Guido responded but apparently before you surfed... Skip From esr@thyrsus.com Sat Jul 1 17:43:03 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sat, 1 Jul 2000 12:43:03 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <14686.6962.530478.967290@beluga.mojam.com>; from skip@mojam.com on Sat, Jul 01, 2000 at 11:24:18AM -0500 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> Message-ID: <20000701124303.A31955@thyrsus.com> Skip Montanaro : > My guess is that -tt triggered a SyntaxError (maybe we should create an > IndentationError that is a subclass of SyntaxError?) +1! -- Eric S. Raymond The United States is in no way founded upon the Christian religion -- George Washington & John Adams, in a diplomatic message to Malta. From chuqui@plaidworks.com Sat Jul 1 17:34:19 2000 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sat, 1 Jul 2000 09:34:19 -0700 Subject: [Python-Dev] [Mailman-Developers] Re: ML replies (was: CVS: python/dist/src/PCbuild readme.txt,1.5,1.6) In-Reply-To: <14686.6512.329946.694266@anthem.concentric.net> References: <14684.43443.919858.897738@anthem.concentric.net> <20000701032438.U29590@lyra.org> <14686.6512.329946.694266@anthem.concentric.net> Message-ID: At 12:16 PM -0400 7/1/00, Barry A. Warsaw wrote: > GS> What about the Mail-Followup-To header? That can be helpful > GS> for some newsreaders (e.g. Mutt). Dunno how many observe it. > >It looks like VM/Emacs doesn't (which is what I use), but I'm sure >that'd be easy to add. I would be most interested to know what >Outlook and NS do with it. > >However Mail-Followup-To: isn't in any RFC that I can find, not even >2076. It's non-standard, and in fact, arguably non-compliant, since any unofficial header should be in the X-headername form. >So there is clearly no header that will support the functionality we >want. This is a case where Reply-To is the correct header to set, or at least, least incorrect. >One potential solution for Mailman might be to lie about the To: >address. So in the above scenario, the message would have a To: field >set to python-dev even though the message would actually be sent to >the python-checkins membership. um, uh, well... I don't like it. Even if you had Sender: and List-ID set properly, it still seems wrong. For this case, I think the best setup is Reply-to, because that's waht you want: it came FROM this place, but responses go to this other place. The proper answer is setting reply-to, not attempting to rearrange the concept of "from this place". As a strong proponent of "don't use reply-to!" -- this is a case where it's the proper answer. It's not perfect by any means, since reply-to coerces someone away from replying privately, but in this situation, that's better than not doing it. -- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com) And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'" From Fredrik Lundh" when looking through skip's coverage listing, I noted a bug in SRE: #define SRE_UNI_IS_ALNUM(ch) ((ch) < 256 ? isalnum((ch)) : 0) this predicate is used for \w when a pattern is compiled using the "unicode locale" (flag U), and should definitely not use 8-bit locale stuff. however, there's no such thing as a Py_UNICODE_ISALNUM (or even a Py_UNICODE_ISALPHA). what should I do? how about using: Py_UNICODE_ISLOWER || =20 Py_UNICODE_ISUPPER || Py_UNICODE_ISTITLE || Py_UNICODE_ISDIGIT =20 From mal@lemburg.com Sat Jul 1 17:46:52 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 18:46:52 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> Message-ID: <395E207C.91E3A2A5@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > I'm not sure whose fault that is: either __repr__ should accept > > > unicode strings, or minidom.Element.__repr__ should be changed to > > > return a plain string, e.g. by converting tagname to UTF-8. In any > > > case, I believe __repr__ should 'work' for these objects. > > > > Note that __repr__ has to return a string object (and IIRC > > this is checked in object.c or abstract.c). The correct way > > to get there is to simply return str(...) or to have a > > switch on the type of self.tagName and then call .encode(). > > assuming that the goal is to get rid of this restriction in future > versions (a string is a string is a string), how about special- > casing this in PyObject_Repr: > > PyObject *res; > res = (*v->ob_type->tp_repr)(v); > if (res == NULL) > return NULL; > --- > if (PyUnicode_Check(res)) { > PyObject* str; > str = PyUnicode_AsEncodedString(res, NULL, NULL); > if (str) { > Py_DECREF(res); > res = str; > } > } > --- > if (!PyString_Check(res)) { > PyErr_Format(PyExc_TypeError, > "__repr__ returned non-string (type %.200s)", > res->ob_type->tp_name); > Py_DECREF(res); > return NULL; > } > return res; > > in this way, people can "do the right thing" in their code, > and have it work better in future versions... > > (just say "+1", and the mad patcher will update the repository) I'd say +0, since the auto-converion can fail if the default encoding doesn't have room for the tagName characters. Either way, I'd still prefer the DOM code to use an explicit .encode() together with some lossless encoding, e.g. unicode-escape. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov@inrialpes.fr Sat Jul 1 17:52:50 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 18:52:50 +0200 (CEST) Subject: [Python-Dev] test, please ignore Message-ID: <200007011652.SAA05728@python.inrialpes.fr> -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov@inrialpes.fr Sat Jul 1 17:56:49 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 18:56:49 +0200 (CEST) Subject: [Python-Dev] Sorry. No Release. Message-ID: <200007011656.SAA05767@python.inrialpes.fr> Resending... Subject: Re: [Python-Dev] Sorry. No Release. To: guido@beopen.com (Guido van Rossum) Date: Sat, 1 Jul 2000 16:23:16 +0200 (CEST) Cc: python-dev@python.org Guido van Rossum wrote: > > > I'm not convinced this delay is wholly a bad thing. Did Barry ever > > track down the mysterious crashes he was seeing from running the test > > suite? And it's more time to experiment with the garbage collection, > > hunt for SRE bugs, and so forth. > > But that's what beta releases are for, right? The result now is that > fewer people will try out the code than if it were released today, and > the final release will undoubtedly be delayed again. Guido, what about reverting the version number to 2.0a3 ? We're still not in a beta stage, but there *is* a new version ready, which, if not beta, should be an alpha. We're used to see the version bumped a day or two before the release. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal@lemburg.com Sat Jul 1 17:56:12 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 18:56:12 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> Message-ID: <395E22AC.6BB76041@lemburg.com> Fredrik Lundh wrote: > > when looking through skip's coverage listing, I noted a bug in > SRE: > > #define SRE_UNI_IS_ALNUM(ch) ((ch) < 256 ? isalnum((ch)) : 0) > > this predicate is used for \w when a pattern is compiled using > the "unicode locale" (flag U), and should definitely not use 8-bit > locale stuff. > > however, there's no such thing as a Py_UNICODE_ISALNUM > (or even a Py_UNICODE_ISALPHA). what should I do? how > about using: > > Py_UNICODE_ISLOWER || > Py_UNICODE_ISUPPER || > Py_UNICODE_ISTITLE || > Py_UNICODE_ISDIGIT This will give you all cased chars along with all digits; it ommits the non-cased ones. It's a good start, but probably won't cover the full range of letters + numbers. Perhaps we need another table for isalpha in unicodectype.c ? (Or at least one which defines all non-cased letters.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" <395E22AC.6BB76041@lemburg.com> Message-ID: <028301bfe37f$bb349380$f2a6b5d4@hagrid> mal wrote: > > Py_UNICODE_ISLOWER || > > Py_UNICODE_ISUPPER || > > Py_UNICODE_ISTITLE || > > Py_UNICODE_ISDIGIT >=20 > This will give you all cased chars along with all digits; > it ommits the non-cased ones. but of course... > It's a good start, but probably won't cover the full range > of letters + numbers. >=20 > Perhaps we need another table for isalpha in unicodectype.c ? > (Or at least one which defines all non-cased letters.) +1 from me (SRE needs this, and it doesn't really make much sense to add unicode tables to SRE just because the built-in ones are slightly incomplete...) how about this plan: -- you add a Py_UNICODE_ALPHA to unicodeobject.h asap, which does exactly that (or I can do that, if you prefer). (and maybe even a Py_UNICODE_ALNUM) -- I change SRE to use that asap. -- you, I, or someone else add a better implementation, some other day. From skip@mojam.com (Skip Montanaro) Sat Jul 1 19:54:40 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sat, 1 Jul 2000 13:54:40 -0500 (CDT) Subject: [Python-Dev] test coverage summaries - now updated nightly Message-ID: <14686.15984.430156.148785@beluga.mojam.com> I've spent amount as much time on generating automated statement and branch coverage as I can afford for the next few days. At this point I think I have it generating a reasonable facsimile of useful output. A cron job on www.musi-cal.com does the following early each morning (4:45AM Pacific time): make clean cvs update config.status --recheck make python with gcov flags make test > testresults.txt generate coverage pages (lines.html & branches.html) The relevant output files on the web server are http://www.musi-cal.com/~skip/python/Python/dist/src/lines.html http://www.musi-cal.com/~skip/python/Python/dist/src/branches.html http://www.musi-cal.com/~skip/python/Python/dist/src/testresults.txt A couple shell scripts do all the dirty work for now: http://www.musi-cal.com/~skip/python/Python/dist/src/gencoverage http://www.musi-cal.com/~skip/python/Python/dist/src/gencoverage1 I may put an index.html file in there just to provide a little cover for the directory tree. I'll also enable a couple more modules in Modules/Setup. Skip From paul@prescod.net Sat Jul 1 20:00:20 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 14:00:20 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> Message-ID: <395E3FC4.959BB042@prescod.net> "M.-A. Lemburg" wrote: > > ... > > I'd say +0, since the auto-converion can fail if the default > encoding doesn't have room for the tagName characters. > > Either way, I'd still prefer the DOM code to use an explicit > .encode() together with some lossless encoding, e.g. > unicode-escape. If we want to use a hard-coded lossless encoding, we should do so in repr. Rather than having us fix a dozen modules with problems like this, we should fix repr once and for all. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul@prescod.net Sat Jul 1 20:02:37 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 14:02:37 -0500 Subject: [Python-Dev] test coverage summaries - now updated nightly References: <14686.15984.430156.148785@beluga.mojam.com> Message-ID: <395E404D.FBD47947@prescod.net> Skip Montanaro wrote: > > I've spent amount as much time on generating automated statement and branch > coverage as I can afford for the next few days. At this point I think I > have it generating a reasonable facsimile of useful output. I may have missed email about this during my email troubles yesterday, but why aren't we doing coverage testing of Python code too? Or am I missing that link? -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From Fredrik Lundh" <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> Message-ID: <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> paul wrote: =20 > If we want to use a hard-coded lossless encoding, we should do so in > repr. Rather than having us fix a dozen modules with problems like = this, > we should fix repr once and for all. =20 how about allowing str and repr to actually return unicode strings? or in other words: PyObject *res; res =3D (*v->ob_type->tp_repr)(v); if (res =3D=3D NULL) return NULL; if (!PyString_Check(res) && !PyUnicode_Check(res)) { PyErr_Format(PyExc_TypeError, "__repr__ returned non-string (type %.200s)", res->ob_type->tp_name); Py_DECREF(res); return NULL; } return res; (strings are strings are strings, etc) From Fredrik Lundh" <395E404D.FBD47947@prescod.net> Message-ID: <02b601bfe390$774a0a40$f2a6b5d4@hagrid> paul wrote: > Skip Montanaro wrote: > >=20 > > I've spent amount as much time on generating automated statement and = branch > > coverage as I can afford for the next few days. At this point I = think I > > have it generating a reasonable facsimile of useful output. >=20 > I may have missed email about this during my email troubles yesterday, > but why aren't we doing coverage testing of Python code too? Or am I > missing that link? from Skip's original mail: /.../ I would also like to adjust the regrtest.py stuff to generate statement coverage for .py = files using my trace module: = http://www.musi-cal.com/~skip/python/trace.py. From mal@lemburg.com Sat Jul 1 20:22:10 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 21:22:10 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> <028301bfe37f$bb349380$f2a6b5d4@hagrid> Message-ID: <395E44E2.63383BC5@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > Py_UNICODE_ISLOWER || > > > Py_UNICODE_ISUPPER || > > > Py_UNICODE_ISTITLE || > > > Py_UNICODE_ISDIGIT > > > > This will give you all cased chars along with all digits; > > it ommits the non-cased ones. > > but of course... > > > It's a good start, but probably won't cover the full range > > of letters + numbers. > > > > Perhaps we need another table for isalpha in unicodectype.c ? > > (Or at least one which defines all non-cased letters.) > > +1 from me (SRE needs this, and it doesn't really make much > sense to add unicode tables to SRE just because the built-in > ones are slightly incomplete...) > > how about this plan: > > -- you add a Py_UNICODE_ALPHA to unicodeobject.h asap, > which does exactly that (or I can do that, if you prefer). > (and maybe even a Py_UNICODE_ALNUM) Ok, I'll add Py_UNICODE_ISALPHA and Py_UNICODE_ISALNUM (first with approximations of the sort you give above and later with true implementations using tables in unicodectype.c) on Monday... gotta run now. > -- I change SRE to use that asap. > > -- you, I, or someone else add a better implementation, > some other day. > > Nice weekend :) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul@prescod.net Sat Jul 1 20:45:00 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 14:45:00 -0500 Subject: [Python-Dev] Cygwin report Message-ID: <395E4A3C.74A10F74@prescod.net> Here are instructions for compiling on cygwin. If anyone out there wants to make some tweaks to the build process so that this stuff isn't required anymore, it would be appreciated. ---- Threading does not work: I don't know much about posix threading APIs but I note that the standard Cygwin's pthread.h does not seem to define a pthread_cond_t type. I guess cygwin's pthread is incomplete. There seems to be a more complete one here: http://sunsite.org.uk/gnu/MORE_GNU/cygnus/pthreads-win32/ But I don't care enough to download and try it out. If there is an easy way to turn off threads by default when the platform is cygwin, that would make life a little easier for people using it. --- Sockets: gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./socketmodule.c ./socketmodule.c:146: netinet/tcp.h: No such file or directory (I just commented this module out) --- Then I got an error I haven't seen before /python/python/dist/src/Modules/python.c:12: undefined reference to `Py_Main' collect2: ld returned 1 exit status libpython2.0.a was too small to be real so I deleted it and tried "make" again. It worked. Now I have modules/python.exe mv python ../python mv: cannot move `python' to `../python/python': No such file or directory make[1]: *** [link] Error 1 make[1]: Leaving directory `/python/python/dist/src/Modules' make: *** [python] Error 2 Adding "EXE=exe" to Makefile, Modules\Setup.local and Modules\Makefile does not seem to help. For now, I'll move the file myself. (I'm not clear why it is the "Modules" makefile's responsibility to build and move python.exe anyhow!) --- If you compile using cygwin, do not make the mistake of trying to use ^Z as end of term. It hangs cygwin. Use ^D instead. -- Testing: File "./Lib/random.py", line 84, in ? NV_MAGICCONST = 4*exp(-0.5)/sqrt(2.0) OverflowError: math range error (comment out the line that imports random and try again) --- -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From gmcm@hypernet.com Sat Jul 1 20:58:24 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Sat, 1 Jul 2000 15:58:24 -0400 Subject: [Python-Dev] Cygwin report In-Reply-To: <395E4A3C.74A10F74@prescod.net> Message-ID: <1249640994-55813280@hypernet.com> Paul Prescod wrote: > Here are instructions for compiling on cygwin. If anyone out > there wants to make some tweaks to the build process so that this > stuff isn't required anymore, it would be appreciated. ---- > Threading does not work: If you targeted mingw, threading should work. Also should get a smaller, faster exe and one that has a prayer of working with pre-built extensions. last-three-words-optional-ly y'rs - Gordon From skip@mojam.com (Skip Montanaro) Sat Jul 1 22:27:37 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sat, 1 Jul 2000 16:27:37 -0500 (CDT) Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: <395E404D.FBD47947@prescod.net> References: <14686.15984.430156.148785@beluga.mojam.com> <395E404D.FBD47947@prescod.net> Message-ID: <14686.25161.513218.84366@beluga.mojam.com> >> I've spent amount as much time on generating automated statement and >> branch coverage as I can afford for the next few days. At this point >> I think I have it generating a reasonable facsimile of useful output. Paul> I may have missed email about this during my email troubles Paul> yesterday, but why aren't we doing coverage testing of Python code Paul> too? Or am I missing that link? Perhap you did miss it. That's next on my list. I have a trace module that will do line counting, but I haven't worked on this thing long enough to get to it. If anyone's game, take a look at http://www.musi-cal.com/~skip/python/trace.py Shouldn't take an awful lot of effort. I just haven't got the time today. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From martin@loewis.home.cs.tu-berlin.de Sat Jul 1 23:43:17 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 2 Jul 2000 00:43:17 +0200 Subject: [Python-Dev] Copyright notice Message-ID: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> On startup, the current CVS python reports (on my system) Python 2.0b1 (#31, Jul 1 2000, 23:13:39) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) Now that the file copyrights are changed, I expect this message to change as well. May I suggest that, instead of adding another line, the two last lines of this message are removed? People who need to find out who holds the copyright to this software still can print sys.copyright. Regards, Martin From paul@prescod.net Sun Jul 2 01:15:57 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 19:15:57 -0500 Subject: [Python-Dev] test coverage summaries - now updated nightly References: <14686.15984.430156.148785@beluga.mojam.com> <395E404D.FBD47947@prescod.net> <14686.25161.513218.84366@beluga.mojam.com> Message-ID: <395E89BD.62EEC94D@prescod.net> Skip Montanaro wrote: > > ... > Perhap you did miss it. That's next on my list. I have a trace module that > will do line counting, but I haven't worked on this thing long enough to get > to it. > > If anyone's game, take a look at > > http://www.musi-cal.com/~skip/python/trace.py Thanks. It's because I've recently been using your trace module that I originally presumed that the coverage testing would be Python coverage testing. I don't yet completely understand the counting mechanism that the tool uses (some numbers look fishy) but overall it is a great boon for testing. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From mhammond@skippinet.com.au Sun Jul 2 01:21:30 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 2 Jul 2000 10:21:30 +1000 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: <20000701065111.Z29590@lyra.org> Message-ID: > > This is exactly what we do. Trents patches are just for the > functions that > > return the underlying handle value as an integer (which is definately a > > useful thing to be able to do!) > > But I don't understand why you want an integer. From the Python > programmer's > standpoint, they just want a handle, right? Yes - but there _are_ functions that return the integer. This is used mainly so the handles can be passed to external programs, or external API functions wrapped via SWIG, etc. The normal case is a "handle object". The "handle object" has auto-close ability. The "handle object" _also_ has the ability to get the raw underlying handle, should the programmer choose. Im afraid you will never convince me this is wrong :-) > Without using PyCObject, we'd need a complete handle type (like > the one in > win32api or wherever). That is exactly what we have. Sorry - I thought "CObject" was a generic term for any C-implemented PyObject. Mark. From paul@prescod.net Sun Jul 2 01:22:23 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 19:22:23 -0500 Subject: [Python-Dev] test coverage summaries - now updated nightly References: <14686.15984.430156.148785@beluga.mojam.com> <395E404D.FBD47947@prescod.net> <02b601bfe390$774a0a40$f2a6b5d4@hagrid> Message-ID: <395E8B3F.39D5C69A@prescod.net> Fredrik Lundh wrote: > > from Skip's original mail: > > /.../ I would also like to > adjust the regrtest.py stuff to generate statement coverage for .py files > using my trace module: http://www.musi-cal.com/~skip/python/trace.py. Thanks. If anyone sent me private mail yesterday (perhaps Fred about xml.*) they should send it again. My ISP's story is that their ISP went belly up without any warning. Grrr. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul@prescod.net Sun Jul 2 01:27:13 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 19:27:13 -0500 Subject: [Python-Dev] Repr References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> Message-ID: <395E8C61.E30CA40D@prescod.net> Fredrik Lundh wrote: > > ... > > how about allowing str and repr to actually return > unicode strings? What does that mean for the interactive prompt (repr is used in the repl!). -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From gstein@lyra.org Sun Jul 2 01:34:50 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 17:34:50 -0700 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: ; from mhammond@skippinet.com.au on Sun, Jul 02, 2000 at 10:21:30AM +1000 References: <20000701065111.Z29590@lyra.org> Message-ID: <20000701173450.F29590@lyra.org> On Sun, Jul 02, 2000 at 10:21:30AM +1000, Mark Hammond wrote: > > > This is exactly what we do. Trents patches are just for the > > functions that > > > return the underlying handle value as an integer (which is definately a > > > useful thing to be able to do!) > > > > But I don't understand why you want an integer. From the Python > > programmer's > > standpoint, they just want a handle, right? > > Yes - but there _are_ functions that return the integer. This is used > mainly so the handles can be passed to external programs, or external API > functions wrapped via SWIG, etc. All right. I see the usage now. The checkin message didn't have enough context, so I went and look at the darn file. Ignore me :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond@skippinet.com.au Sun Jul 2 01:49:53 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 2 Jul 2000 10:49:53 +1000 Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: <14686.15984.430156.148785@beluga.mojam.com> Message-ID: > I've spent amount as much time on generating automated statement > and branch > coverage as I can afford for the next few days. At this point I think I > have it generating a reasonable facsimile of useful output. This is very cool. It would be great if there was some sort of "multi-platform" support, and a merging of the results. My idea here is so modules such as "mmapmodule" can give a better indication of the true test coverage. Your data shows this test at less than 50% - probably mainly due to the #ifdef MS_WIN32 blocks. If we merged a coverage of a Windows run against this same file, we would have an excellent basis for ensuring that the Python test suite did indeed hit as much as we could make it. This is longer term of course. Along the same vein is the Mozilla "tinderbox". It appears they have a job that starts a complete rebuild and test suite run every time a checkin is made to the CVS tree. A Web page shows the progress of each of the platforms (including some nice flaming images when the build or test suite is broken.) http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey Mark. From fdrake@beopen.com Sun Jul 2 04:34:40 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 1 Jul 2000 23:34:40 -0400 (EDT) Subject: [Python-Dev] Copyright notice In-Reply-To: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> References: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> Message-ID: <14686.47184.792611.628971@cj42289-a.reston1.va.home.com> Martin v. Loewis writes: > Now that the file copyrights are changed, I expect this message to > change as well. May I suggest that, instead of adding another line, > the two last lines of this message are removed? You may! I rather like this idea myself. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tpeters@beopen.com Sun Jul 2 04:42:28 2000 From: tpeters@beopen.com (Tim Peters) Date: Sat, 1 Jul 2000 23:42:28 -0400 Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: <395E8B3F.39D5C69A@prescod.net> Message-ID: [Paul Prescod] > ...If anyone sent me private mail yesterday (perhaps Fred about > xml.*) they should send it again. My ISP's story is that their ISP went > belly up without any warning. Grrr. Ditto! My POP3 server at MSN crapped out a little after midnight, and I appear to have lost all mail sent from then until about 2pm. The pipermail archives on python.org stopped archiving around midnight too. My email .forward from tpeters@beopen.com also seems still to be hosed. Was July 1 some "32-bit day" that slipped thru paranoia's cracks <0.9 wink>? From esr@thyrsus.com Sun Jul 2 12:25:24 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 07:25:24 -0400 Subject: [Python-Dev] I have a patch for shlex... Message-ID: <20000702072524.A5592@thyrsus.com> I have a patch for shlex. There has been a lot of discussion of patch management consequent to the SourceForge relocation here that I haven't followed closely. So what's the current protocol for submitting a patch? (The patch gives input sourcing cpp-like semantics for relative paths, rather than making all inclusions relative to the current working directory. Since the source feature has not yet been in a public production release, there are no backwards-compatibility issues.) -- Eric S. Raymond Everything that is really great and inspiring is created by the individual who can labor in freedom. -- Albert Einstein, in H. Eves Return to Mathematical Circles, Boston: Prindle, Weber and Schmidt, 1988. From Fredrik Lundh" Message-ID: <000e01bfe418$fa3e5400$f2a6b5d4@hagrid> eric wrote: > I have a patch for shlex. There has been a lot of discussion of patch = > management consequent to the SourceForge relocation here that I = haven't=20 > followed closely. So what's the current protocol for submitting a = patch? the patch manager is your friend: http://sourceforge.net/patch/?func=3Daddpatch&group_id=3D5470 bonus points if the summary mentions the module or subsystem name, and you describe/motivate the change either in a comment on the patch details page, or at the top of the patch itself. cheers /F From rob@hooft.net Sun Jul 2 13:02:11 2000 From: rob@hooft.net (Rob W. W. Hooft) Date: Sun, 2 Jul 2000 14:02:11 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml __init__.py,1.1,1.2 In-Reply-To: <200007010458.VAA21264@slayer.i.sourceforge.net> References: <200007010458.VAA21264@slayer.i.sourceforge.net> Message-ID: <14687.12099.151636.943086@temoleh.chem.uu.nl> >>>>> "PP" == Paul Prescod writes: PP> sax -- The Simple API for XML, developed by XML-Dev, led by PP> David Megginson and ported to Python by Lars Marius Garsholm. His name is "Lars Marius Garshol", no m. Rob From esr@thyrsus.com Sun Jul 2 13:26:44 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 08:26:44 -0400 Subject: [Python-Dev] The submit patch form yields a cryptic message Message-ID: <20000702082644.A5758@thyrsus.com> "Patch Uploaded Successfully Added Patch Could Not Send Patch Update" -- Eric S. Raymond The kind of charity you can force out of people nourishes about as much as the kind of love you can buy --- and spreads even nastier diseases. From esr@thyrsus.com Sun Jul 2 13:45:16 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 08:45:16 -0400 Subject: [Python-Dev] Application for developer status Message-ID: <20000702084516.A5777@thyrsus.com> May I have developer status on the SourceForge CVS, please? I maintain two standard-library modules (shlex and netrc) and have been involved with the development of several others (including Cmd, smtp, httplib, and multifile). My only immediate plan for what to do with developer access is to add the browser-launch capability previously discussed on this list. My general interest is in improving the standard class library, especially in the areas of Internet-protocol support (urllib, ftp, telnet, pop, imap, smtp, nntplib, etc.) and mini-language toolkits and frameworks (shlex. netrc, Cmd, ConfigParser). If the Internet-protocol support in the library were broken out as a development category, I would be willing to fill the patch-handler slot for it. -- Eric S. Raymond See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs. -- Dave Barry From fdrake@beopen.com Sun Jul 2 14:51:04 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 2 Jul 2000 09:51:04 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml __init__.py,1.1,1.2 In-Reply-To: <14687.12099.151636.943086@temoleh.chem.uu.nl> References: <200007010458.VAA21264@slayer.i.sourceforge.net> <14687.12099.151636.943086@temoleh.chem.uu.nl> Message-ID: <14687.18632.87208.648581@cj42289-a.reston1.va.home.com> Rob W. W. Hooft writes: > >>>>> "PP" == Paul Prescod writes: > > PP> sax -- The Simple API for XML, developed by XML-Dev, led by > PP> David Megginson and ported to Python by Lars Marius Garsholm. > > His name is "Lars Marius Garshol", no m. Yup! But it looks like Paul was quoting from the xml/__init__.py file docstring, which I wrote. So, I'll have to take credit for the typo. ;( I'll fix it now; thanks for pointing it out! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip@mojam.com (Skip Montanaro) Sun Jul 2 15:42:01 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 2 Jul 2000 09:42:01 -0500 (CDT) Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: References: <14686.15984.430156.148785@beluga.mojam.com> Message-ID: <14687.21689.32691.579185@beluga.mojam.com> Mark> It would be great if there was some sort of "multi-platform" Mark> support, and a merging of the results. Agreed. We could set up a scheme where people run my scripts on other systems and then mail me the generated files. Windows would be kind of tough though, because my stuff currently relies on gcc/gcov. What facilities does Windows have for coverage testing Mark? Mark> Along the same vein is the Mozilla "tinderbox". It appears they Mark> have a job that starts a complete rebuild and test suite run every Mark> time a checkin is made to the CVS tree. That seems a bit extreme to me, and I don't know about you, but I don't have the spare resources available to "burn" on such a project. skip From paul@prescod.net Sun Jul 2 16:07:49 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 10:07:49 -0500 Subject: [Python-Dev] Application for developer status References: <20000702084516.A5777@thyrsus.com> Message-ID: <395F5AC5.FF11284F@prescod.net> "Eric S. Raymond" wrote: > > ... > > My only immediate plan for what to do with developer access is to add > the browser-launch capability previously discussed on this list. My > general interest is in improving the standard class library, > especially in the areas of Internet-protocol support (urllib, ftp, > telnet, pop, imap, smtp, nntplib, etc.) and mini-language toolkits and > frameworks (shlex. netrc, Cmd, ConfigParser). As an aside: I would be pumpld about getting a generic lexer into the Python distribution. Greg Ewing was working on one and there are various others out there. http://www.cosc.canterbury.ac.nz/~greg/python/Plex/ -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm, by David Berlinski From paul@prescod.net Sun Jul 2 16:10:49 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 10:10:49 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml __init__.py,1.1,1.2 References: <200007010458.VAA21264@slayer.i.sourceforge.net> <14687.12099.151636.943086@temoleh.chem.uu.nl> <14687.18632.87208.648581@cj42289-a.reston1.va.home.com> Message-ID: <395F5B79.5310B93D@prescod.net> "Fred L. Drake, Jr." wrote: > > Yup! But it looks like Paul was quoting from the xml/__init__.py > file docstring, which I wrote. So, I'll have to take credit for the > typo. ;( I'll fix it now; thanks for pointing it out! No, I added that typo. You just made the mistake of naming David Megginson but not Lars. I thought that the latter was closer to our hearts. But not close enough to spell his name right. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From esr@thyrsus.com Sun Jul 2 16:52:31 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 11:52:31 -0400 Subject: [Python-Dev] Application for developer status In-Reply-To: <395F5AC5.FF11284F@prescod.net>; from paul@prescod.net on Sun, Jul 02, 2000 at 10:07:49AM -0500 References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> Message-ID: <20000702115231.A6785@thyrsus.com> Paul Prescod : > As an aside: I would be pumpld about getting a generic lexer into the > Python distribution. Greg Ewing was working on one and there are various > others out there. > http://www.cosc.canterbury.ac.nz/~greg/python/Plex/ Yes, this would be a good thing. I'm also talking with John Aycock about his elegant SPARK toolkit for generating Earley-algorithm parsers. Once that comes out of beta, I would consider it a core-library candidate. -- Eric S. Raymond No matter how one approaches the figures, one is forced to the rather startling conclusion that the use of firearms in crime was very much less when there were no controls of any sort and when anyone, convicted criminal or lunatic, could buy any type of firearm without restriction. Half a century of strict controls on pistols has ended, perversely, with a far greater use of this weapon in crime than ever before. -- Colin Greenwood, in the study "Firearms Control", 1972 From Fredrik Lundh" <395F5AC5.FF11284F@prescod.net> Message-ID: <001701bfe440$88beaaa0$f2a6b5d4@hagrid> paul wrote: > As an aside: I would be pumpld about getting a generic lexer into the > Python distribution. how about this quick and dirty proposal: - add a new primitive to SRE: (?P#n), where n is a small integer. this primitive sets the match object's "index" variable to n when the engine stumbles upon it. - given a list of "phrases", combine them into a single regular expression like this: (?:phrase1(?P#1))|(?:phrase2(?P#2))|... - apply match repeatedly to the input string. for each match, use the index attribute to figure out what phrase we matched. see below for a slightly larger example. import sre class Scanner: def __init__(self, lexicon): self.lexicon =3D lexicon p =3D [] for phrase, action in lexicon: p.append("(?:%s)(?P#%d)" % (phrase, len(p))) self.scanner =3D sre.compile("|".join(p)) def scan(self, string): result =3D [] append =3D result.append match =3D self.scanner.match i =3D 0 while 1: m =3D match(string, i) if not m: break j =3D m.end() if i =3D=3D j: break action =3D self.lexicon[m.index][1] if callable(action): self.match =3D match action =3D action(self, m.group()) if action is not None: append(action) i =3D j return result, string[i:] def s_ident(scanner, token): return token def s_operator(scanner, token): return "operator%s" % token def s_float(scanner, token): return float(token) def s_int(scanner, token): return int(token) scanner =3D Scanner([ (r"[a-zA-Z_]\w*", s_ident), (r"\d+\.\d*", s_float), (r"\d+", s_int), (r"=3D|\+|-|\*|/", s_operator), (r"\s+", None), ]) tokens, tail =3D scanner.scan("sum =3D 3*foo + 312.50 + bar") print tokens if tail: print "syntax error at", tail ## prints: ## ['sum', 'operator=3D', 3, 'operator*', 'foo', 'operator+', ## 312.5, 'operator+', 'bar'] From paul@prescod.net Sun Jul 2 17:30:25 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 11:30:25 -0500 Subject: [Python-Dev] Lexing/parsing References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> <20000702115231.A6785@thyrsus.com> Message-ID: <395F6E21.E59ADE6D@prescod.net> "Eric S. Raymond" wrote: > > ... > > Yes, this would be a good thing. I'm also talking with John Aycock about > his elegant SPARK toolkit for generating Earley-algorithm parsers. Once that > comes out of beta, I would consider it a core-library candidate. I pointed one of my co-workers at Spark and he loved the lexer but said that the parser ended up being too slow to be useful. I didn't know enough about the Earley-algorithm to suggest how he could re-organize his grammar to optimize for it. If naive Python programmers cannot generate usable parsers then it may not be appropriate for the standard library. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From fdrake@beopen.com Sun Jul 2 17:33:26 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 2 Jul 2000 12:33:26 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml __init__.py,1.1,1.2 In-Reply-To: <395F5B79.5310B93D@prescod.net> References: <200007010458.VAA21264@slayer.i.sourceforge.net> <14687.12099.151636.943086@temoleh.chem.uu.nl> <14687.18632.87208.648581@cj42289-a.reston1.va.home.com> <395F5B79.5310B93D@prescod.net> Message-ID: <14687.28374.752438.191737@cj42289-a.reston1.va.home.com> Paul Prescod writes: > No, I added that typo. You just made the mistake of naming David > Megginson but not Lars. I thought that the latter was closer to our > hearts. But not close enough to spell his name right. Oops! Ok, typo conceeded. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul@prescod.net Sun Jul 2 17:38:54 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 11:38:54 -0500 Subject: [Python-Dev] Re: A standard lexer? References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> <001701bfe440$88beaaa0$f2a6b5d4@hagrid> Message-ID: <395F701E.621CACD4@prescod.net> Fredrik Lundh wrote: > >... > > - add a new primitive to SRE: (?P#n), where n is a small integer. > this primitive sets the match object's "index" variable to n when > the engine stumbles upon it. How about an interned string instead? > - given a list of "phrases", combine them into a single regular > expression like this: > > (?:phrase1(?P#1))|(?:phrase2(?P#2))|... Will sre do anything about optimizing common prefixes and so forth? Overall, I like your proposal. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From esr@thyrsus.com Sun Jul 2 17:58:39 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 12:58:39 -0400 Subject: [Python-Dev] Lexing/parsing In-Reply-To: <395F6E21.E59ADE6D@prescod.net>; from paul@prescod.net on Sun, Jul 02, 2000 at 11:30:25AM -0500 References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> <20000702115231.A6785@thyrsus.com> <395F6E21.E59ADE6D@prescod.net> Message-ID: <20000702125839.A6935@thyrsus.com> Paul Prescod : > I pointed one of my co-workers at Spark and he loved the lexer but said > that the parser ended up being too slow to be useful. I didn't know > enough about the Earley-algorithm to suggest how he could re-organize > his grammar to optimize for it. If naive Python programmers cannot > generate usable parsers then it may not be appropriate for the standard > library. I'm using a SPARK-generated parser plus shlex in CML2. This does not seem to create a speed problem. -- Eric S. Raymond No kingdom can be secured otherwise than by arming the people. The possession of arms is the distinction between a freeman and a slave. -- "Political Disquisitions", a British republican tract of 1774-1775 From tim_one@email.msn.com Sun Jul 2 17:52:52 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 2 Jul 2000 12:52:52 -0400 Subject: [Python-Dev] Application for developer status In-Reply-To: <20000702084516.A5777@thyrsus.com> Message-ID: [Eric S. Raymond] > May I have developer status on the SourceForge CVS, please? I maintain > two standard-library modules (shlex and netrc) and have been involved > with the development of several others (including Cmd, smtp, httplib, and > multifile). > > My only immediate plan for what to do with developer access is to add > the browser-launch capability previously discussed on this list. My > general interest is in improving the standard class library, > especially in the areas of Internet-protocol support (urllib, ftp, > telnet, pop, imap, smtp, nntplib, etc.) and mini-language toolkits and > frameworks (shlex. netrc, Cmd, ConfigParser). > > If the Internet-protocol support in the library were broken out as a > development category, I would be willing to fill the patch-handler > slot for it. Eric, I just added you -- go nuts! Don't forget your docstrings, and try hard not to add new modules Guido will hate <0.9 wink -- but new modules do merit python-dev discussion first>. Ah, one more: the layout of the "Edit Member Permissions" admin page on SF is completely screwed up for me, so you got whatever the default permissions are. This looked fine to me a few days ago, but we've added several members since then. Would one of the admins using Netscape please check that page for sane display? I can't yet tell whether it's an IE5 or SF problem. From tim_one@email.msn.com Sun Jul 2 18:21:03 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 2 Jul 2000 13:21:03 -0400 Subject: [Python-Dev] A standard lexer? In-Reply-To: <001701bfe440$88beaaa0$f2a6b5d4@hagrid> Message-ID: [Paul Prescod] > As an aside: I would be pumped about getting a generic lexer into the > Python distribution. [Fredrik Lundh] > how about this quick and dirty proposal: > > - add a new primitive to SRE: (?P#n), where n is a small integer. > this primitive sets the match object's "index" variable to n when > the engine stumbles upon it. Note that the lack of "something like this" is one of the real barriers to speeding SPARK's lexing, and the speed of a SPARK lexer now (well, last I looked into this) can be wildly dependent on the order in which you define your lexing methods (partly because there's no way to figure out which lexing method matched without iterating through all the groups to find the first that isn't None). The same kind of irritating iteration is needed in IDLE and pyclbr too (disguised as unrolled if/elif/elif/... chains), and in tokenize.py (there *really* disguised in a convoluted way, by doing more string tests on the matched substring to *infer* which of the regexp pattern chunks must have matched). OTOH, arbitrary small integers are not Pythonic. Your example *generates* them in order to guarantee they're unique, which is a bad sign (it implies users can't do this safely by hand, and I believe that's the truth of it too): > for phrase, action in lexicon: > p.append("(?:%s)(?P#%d)" % (phrase, len(p))) How about instead enhancing existing (?Ppattern) notation, to set a new match object attribute to name if & when pattern matches? Then arbitrary info associated with a named pattern can be gotten at via dicts via the pattern name, & the whole mess should be more readable. On the third hand, I'm really loathe to add more gimmicks to stinking regexps. But, on the fourth hand, no alternative yet has proven popular enough to move away from those suckers. if-you-can't-get-a-new-car-at-least-tune-up-the-old-one-ly y'rs - tim From dan@cgsoftware.com Sun Jul 2 18:40:04 2000 From: dan@cgsoftware.com (Daniel Berlin) Date: Sun, 2 Jul 2000 10:40:04 -0700 (PDT) Subject: [Python-Dev] A standard lexer? In-Reply-To: Message-ID: > > > On the third hand, I'm really loathe to add more gimmicks to stinking > regexps. But, on the fourth hand, no alternative yet has proven popular > enough to move away from those suckers. > > if-you-can't-get-a-new-car-at-least-tune-up-the-old-one-ly y'rs - tim > > > Right. Actually, if it helps, i'm working on porting re2c to python. Because it was written properly, it's rather simple (in fact, i've only needed to modify one file, add some if's to ee if we want python generation, and output the python code instead of c code) The lexers it generates for c/C++ are much faster than flex lexers, because they are directly coded. I haven't benchmarked it against SPARK yet, but i would imagine it would blow it away, for the same reason it blows away flex. --Dan From Fredrik Lundh" Message-ID: <002901bfe44e$af624be0$f2a6b5d4@hagrid> tim wrote: > OTOH, arbitrary small integers are not Pythonic. Your example = *generates* > them in order to guarantee they're unique, which is a bad sign. this feature itself has been on the todo list for quite a while; the = (?P#n) syntax just exposes the inner workings (the "small integer" is simply = some- thing that fits in a SRE_CODE word). as you say, it's probably a good idea to hide it a bit better... > > for phrase, action in lexicon: > > p.append("(?:%s)(?P#%d)" % (phrase, len(p))) >=20 > How about instead enhancing existing (?Ppattern) notation, to = set a > new match object attribute to name if & when pattern matches? Then > arbitrary info associated with a named pattern can be gotten at via = dicts > via the pattern name, & the whole mess should be more readable. good idea. and fairly easy to implement, I think. on the other hand, that means creating more real groups. and groups don't come for free... maybe this functionality should only be available through the scanner class? it can compile the patterns separately, and combine the data structures before passing them to the code generator. a little bit more code to write, but less visible oddities. > On the third hand, I'm really loathe to add more gimmicks to stinking > regexps. But, on the fourth hand, no alternative yet has proven = popular > enough to move away from those suckers. >=20 > if-you-can't-get-a-new-car-at-least-tune-up-the-old-one-ly y'rs - tim hey, SRE is a new car. same old technology, though. only smaller ;-) btw, if someone wants to play with this, I just checked in a new SRE snapshot. a little bit of documentation can be found here: http://hem.passagen.se/eff/2000_07_01_bot-archive.htm#416954 From pingster@ilm.com Sun Jul 2 21:54:58 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Sun, 2 Jul 2000 13:54:58 -0700 (PDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000701124303.A31955@thyrsus.com> Message-ID: Skip Montanaro : > My guess is that -tt triggered a SyntaxError (maybe we should create an > IndentationError that is a subclass of SyntaxError?) Yes! +1! -- ?!ng From paul@prescod.net Sun Jul 2 22:09:24 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 16:09:24 -0500 Subject: [Python-Dev] Sorry. No Release. References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> Message-ID: <395FAF84.87B1FD17@prescod.net> Skip Montanaro wrote: > > ... > > My guess is that -tt triggered a SyntaxError (maybe we should create an > IndentationError that is a subclass of SyntaxError?) +1 That would be great for newbies! -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From Fredrik Lundh" Message-ID: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid> tim wrote: > > for phrase, action in lexicon: > > p.append("(?:%s)(?P#%d)" % (phrase, len(p))) >=20 > How about instead enhancing existing (?Ppattern) notation, to = set a > new match object attribute to name if & when pattern matches? Then > arbitrary info associated with a named pattern can be gotten at via = dicts > via the pattern name, & the whole mess should be more readable. I just added "lastindex" and "lastgroup" attributes to the match object. "lastindex" is the integer index of the last matched capturing group, "lastgroup" the corresponding name (or None, if the group didn't have a name). both attributes are None if no group were matched. From mal@lemburg.com Sun Jul 2 23:44:55 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 00:44:55 +0200 Subject: [Python-Dev] A standard lexer? References: Message-ID: <395FC5E7.DD0251A2@lemburg.com> Daniel Berlin wrote: > > Actually, if it helps, i'm working on porting re2c to python. Pointers ? > Because it was written properly, it's rather simple (in fact, i've only > needed to modify one file, add some if's to ee if we want python > generation, and output the python code instead of c code) > The lexers it generates for c/C++ are much faster than flex lexers, > because they are directly coded. > I haven't benchmarked it against SPARK yet, but i would imagine it would > blow it away, for the same reason it blows away flex. Perhaps you should also look at the tagging engine in mxTextTools (you know where...) ?! It's very low-level, but it makes nice target for optimizing parser generators since it provides a Python interface to raw C speed. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From dberlin@cygnus.com Sun Jul 2 23:49:37 2000 From: dberlin@cygnus.com (Daniel Berlin) Date: 02 Jul 2000 18:49:37 -0400 Subject: [Python-Dev] A standard lexer? In-Reply-To: "M.-A. Lemburg"'s message of "Mon, 03 Jul 2000 00:44:55 +0200" References: <395FC5E7.DD0251A2@lemburg.com> Message-ID: <86zoo0du66.fsf@dan2.cygnus.com> "M.-A. Lemburg" writes: > Daniel Berlin wrote: > > > > Actually, if it helps, i'm working on porting re2c to python. > > Pointers ? http://www.tildeslash.org/re2c/index.html > > > Because it was written properly, it's rather simple (in fact, i've only > > needed to modify one file, add some if's to ee if we want python > > generation, and output the python code instead of c code) > > The lexers it generates for c/C++ are much faster than flex lexers, > > because they are directly coded. > > I haven't benchmarked it against SPARK yet, but i would imagine it would > > blow it away, for the same reason it blows away flex. > > Perhaps you should also look at the tagging engine in > mxTextTools (you know where...) ?! It's very low-level, but > it makes nice target for optimizing parser generators since > it provides a Python interface to raw C speed. > re2c is simply a scanner generator, not a parser. --Dan From tim_one@email.msn.com Mon Jul 3 00:22:31 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 2 Jul 2000 19:22:31 -0400 Subject: [Python-Dev] (harmless?) CVS error on SourceForge Message-ID: Recent commit had an error msg at the end; don't remember enough about CVS to recall whether it matters; anyone else? C:\pysrc>cvs commit python/dist/src/PC/example_nt CVS.EXE commit: Examining python/dist/src/PC/example_nt Password: Checking in python/dist/src/PC/example_nt/example.dsp; /cvsroot/python/python/dist/src/PC/example_nt/example.dsp,v <-- example.dsp new revision: 1.3; previous revision: 1.2 done Checking in python/dist/src/PC/example_nt/example.dsw; /cvsroot/python/python/dist/src/PC/example_nt/example.dsw,v <-- example.dsw new revision: 1.2; previous revision: 1.1 done Removing python/dist/src/PC/example_nt/example.mak; /cvsroot/python/python/dist/src/PC/example_nt/example.mak,v <-- example.mak new revision: delete; previous revision: 1.3 done Checking in python/dist/src/PC/example_nt/readme.txt; /cvsroot/python/python/dist/src/PC/example_nt/readme.txt,v <-- readme.txt new revision: 1.7; previous revision: 1.6 done Running syncmail... Mailing python-checkins@python.org... ...syncmail done. cvs [diff aborted]: no such tag NONE C:\pysrc> From akuchlin@mems-exchange.org Mon Jul 3 01:57:55 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sun, 2 Jul 2000 20:57:55 -0400 Subject: [Python-Dev] A standard lexer? In-Reply-To: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid>; from effbot@telia.com on Mon, Jul 03, 2000 at 12:35:28AM +0200 References: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid> Message-ID: <20000702205755.A7533@newcnri.cnri.reston.va.us> Might it be worth taking the lexer discussion to the String-SIG? The more public the discussion, the better, and it is why the SIG is there... --amk From fdrake@beopen.com Mon Jul 3 07:15:26 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 02:15:26 -0400 (EDT) Subject: [Python-Dev] (harmless?) CVS error on SourceForge In-Reply-To: References: Message-ID: <14688.12158.189752.140235@cj42289-a.reston1.va.home.com> Tim Peters writes: > Recent commit had an error msg at the end; don't remember enough about CVS > to recall whether it matters; anyone else? ... > cvs [diff aborted]: no such tag NONE This is harmless, and only affects the message sent to python-checkins. It is generated by the "cvs diff" executed by the syncmail script. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Mon Jul 3 07:33:37 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 02:33:37 -0400 (EDT) Subject: [Python-Dev] Application for developer status In-Reply-To: References: <20000702084516.A5777@thyrsus.com> Message-ID: <14688.13249.310796.64561@cj42289-a.reston1.va.home.com> Tim Peters writes: > Ah, one more: the layout of the "Edit Member Permissions" admin page on SF > is completely screwed up for me, so you got whatever the default permissions > are. This looked fine to me a few days ago, but we've added several members > since then. > > Would one of the admins using Netscape please check that page for sane > display? I can't yet tell whether it's an IE5 or SF problem. It looks fine to me -- you may be plagued by a slow network connection. ;) I've updated Eric's permissions so he can use the patch manager properly. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mhammond@skippinet.com.au Mon Jul 3 07:28:02 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Mon, 3 Jul 2000 16:28:02 +1000 Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: <14687.21689.32691.579185@beluga.mojam.com> Message-ID: [Skip] > Mark> It would be great if there was some sort of "multi-platform" > Mark> support, and a merging of the results. > Agreed. We could set up a scheme where people run my scripts on other > systems and then mail me the generated files. Windows would be kind of > tough though, because my stuff currently relies on gcc/gcov. What > facilities does Windows have for coverage testing Mark? There is a source-profiler, but Im not sure how deep it lets you into the data. I'll look into this at some stage. Or some people are working towards gcc makefiles for windows - maybe that is a better way to go for this? Mark> Along the same vein is the Mozilla "tinderbox". It ... > That seems a bit extreme to me, and I don't know about you, but > I don't have > the spare resources available to "burn" on such a project. I think that the tinderbox code is open-source too! I agree this is a bit extreme, but I do believe something like it would be useful, and need not be too hard. As more and more checkins happen from different people, the chances of platform-breakage would seem to be quite high. A Python script that periodically scanned CVS for changes, then executed a build and did something pretty simple with the log wouldnt be too hard. However, I do agree we should wait until it is _nearly_ a problem (as opposed to _is_ a problem :-) Mark. From martin@loewis.home.cs.tu-berlin.de Mon Jul 3 08:29:23 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 3 Jul 2000 09:29:23 +0200 Subject: [Python-Dev] Minidom and Unicode Message-ID: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> > the repository has been updated. In what way? Python 2.0b1 (#1, Jul 3 2000, 09:12:07) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> class X: ... def __repr__(self): ... if hasattr(self,"u"): ... return u'\u30b9' ... else: ... return u'hallo' ... >>> x=X() >>> x hallo >>> x.u=1 >>> x Traceback (most recent call last): File "", line 1, in ? TypeError: __repr__ returned non-string (type unicode) > no need to change minidom. The need still appears to exist, both for minidom.Element (KATAKANA LETTER SU is a letter, and thus a valid tag name), as well as minidom.Text. A string is a string is a string. Regards, Martin From mal@lemburg.com Mon Jul 3 09:35:51 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 10:35:51 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> Message-ID: <39605067.DCC2B968@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > I'd say +0, since the auto-converion can fail if the default > > encoding doesn't have room for the tagName characters. > > > > Either way, I'd still prefer the DOM code to use an explicit > > .encode() together with some lossless encoding, e.g. > > unicode-escape. > > If we want to use a hard-coded lossless encoding, we should do so in > repr. Rather than having us fix a dozen modules with problems like this, > we should fix repr once and for all. I think it's ok to auto-convert to the default encoding as intermediate solution, but the applications wanting to return Unicode as __repr__ or __str__ should really use .encode() to make sure the output that is produces matches their (or their user's) expectations. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Mon Jul 3 09:43:59 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 10:43:59 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> Message-ID: <3960524F.F6C2D4A8@lemburg.com> Fredrik Lundh wrote: > > paul wrote: > > > If we want to use a hard-coded lossless encoding, we should do so in > > repr. Rather than having us fix a dozen modules with problems like this, > > we should fix repr once and for all. > > how about allowing str and repr to actually return > unicode strings? > > or in other words: > > PyObject *res; > res = (*v->ob_type->tp_repr)(v); > if (res == NULL) > return NULL; > if (!PyString_Check(res) && !PyUnicode_Check(res)) { > PyErr_Format(PyExc_TypeError, > "__repr__ returned non-string (type %.200s)", > res->ob_type->tp_name); > Py_DECREF(res); > return NULL; > } > return res; > > (strings are strings are strings, etc) -1: This breaks code, since it is expected that PyObject_Str() returns a string object. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@beopen.com Mon Jul 3 09:53:52 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 04:53:52 -0400 (EDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <395FAF84.87B1FD17@prescod.net> References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> Message-ID: <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> Skip Montanaro wrote: > My guess is that -tt triggered a SyntaxError (maybe we should create an > IndentationError that is a subclass of SyntaxError?) Paul Prescod writes: > +1 > > That would be great for newbies! Yes, but the name is confusing, because it isn't raised for every sort of indentation error if it's only used for tab/space problems: try: 1/0 1/0 finally: pass still would raise SyntaxError. Should that raise an IndentationError as well? Or should IndentationError be named something else? (Just adding IndentationError for -tt isn't hard, I have a preliminary patch for that now. Adding it for the case above looks harder.) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr@thyrsus.com Mon Jul 3 10:20:52 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 05:20:52 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <14688.21664.958984.801457@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 03, 2000 at 04:53:52AM -0400 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> Message-ID: <20000703052052.E11175@thyrsus.com> Fred L. Drake, Jr. : > > Skip Montanaro wrote: > > My guess is that -tt triggered a SyntaxError (maybe we should create an > > IndentationError that is a subclass of SyntaxError?) > > Paul Prescod writes: > > +1 > > > > That would be great for newbies! > > Yes, but the name is confusing, because it isn't raised for every > sort of indentation error if it's only used for tab/space problems: > > try: > 1/0 > 1/0 > finally: > pass > > still would raise SyntaxError. Should that raise an IndentationError > as well? Or should IndentationError be named something else? WhitespaceError -- Eric S. Raymond Morality is always the product of terror; its chains and strait-waistcoats are fashioned by those who dare not trust others, because they dare not trust themselves, to walk in liberty. -- Aldous Huxley From Fredrik Lundh" <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> <3960524F.F6C2D4A8@lemburg.com> Message-ID: <004001bfe4d0$f91b2720$f2a6b5d4@hagrid> mal wrote: > > (strings are strings are strings, etc) >=20 > -1: This breaks code, since it is expected that PyObject_Str() > returns a string object. unicode strings are also strings, right? the interesting question here is to figure out who's expecting that, and figure out if that code can be changed. From mal@lemburg.com Mon Jul 3 10:36:18 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 11:36:18 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> <3960524F.F6C2D4A8@lemburg.com> <004001bfe4d0$f91b2720$f2a6b5d4@hagrid> Message-ID: <39605E92.492D1F3E@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > (strings are strings are strings, etc) > > > > -1: This breaks code, since it is expected that PyObject_Str() > > returns a string object. > > unicode strings are also strings, right? Well, I usually refer to them as Unicode objects to make it clear that they are different from the standard notion of a string in Python. If we were to use classes for Python basic type I would make them have the same base class though... > the interesting question here is to figure out who's expecting that, > and figure out if that code can be changed. We might proceed in that direction for Py3K, but I don't think it's a good idea to make such changes just now. IMHO, it's better to provide other means of getting at the Unicode data, e.g. instances could provide a __unicode__ method hook which the builtin unicode() queries and then uses to convert to Unicode. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" Message-ID: <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> martin wrote: > In what way? >=20 > Python 2.0b1 (#1, Jul 3 2000, 09:12:07) [GCC 2.95.2 19991024 = (release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives = (CNRI) > >>> class X: > ... def __repr__(self): > ... if hasattr(self,"u"): > ... return u'\u30b9' > ... else: > ... return u'hallo' > ...=20 > >>> x=3DX() > >>> x > hallo > >>> x.u=3D1 > >>> x > Traceback (most recent call last): > File "", line 1, in ? > TypeError: __repr__ returned non-string (type unicode) >=20 > > no need to change minidom. >=20 > The need still appears to exist, both for minidom.Element (KATAKANA > LETTER SU is a letter, and thus a valid tag name), as well as > minidom.Text. A string is a string is a string. works for me: $ export LANG=3Dposix.utf8 $ python >>> import sys >>> sys.getdefaultencoding() 'utf8' >>> class X: ... def __repr__(self): ... return u"u\30b9" ... >>> x =3D X() >>> x =E3,=B9 (or to put it another way, I'm not sure the repr/str fix is the real culprit here...) From mal@lemburg.com Mon Jul 3 11:38:04 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 12:38:04 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> <028301bfe37f$bb349380$f2a6b5d4@hagrid> <395E44E2.63383BC5@lemburg.com> Message-ID: <39606D0C.CB3F18FD@lemburg.com> "M.-A. Lemburg" wrote: > > Fredrik Lundh wrote: > > how about this plan: > > > > -- you add a Py_UNICODE_ALPHA to unicodeobject.h asap, > > which does exactly that (or I can do that, if you prefer). > > (and maybe even a Py_UNICODE_ALNUM) > > Ok, I'll add Py_UNICODE_ISALPHA and Py_UNICODE_ISALNUM > (first with approximations of the sort you give above and > later with true implementations using tables in unicodectype.c) > on Monday... gotta run now. > > > -- I change SRE to use that asap. > > > > -- you, I, or someone else add a better implementation, > > some other day. I've just looked into this... the problem here is what to consider as being "alpha" and what "numeric". I could add two new tables for the characters with category 'Lo' (other letters, not cased) and 'Lm' (letter modifiers) to match all letters in the Unicode database, but those tables have some 5200 entries (note that there are only 804 lower case letters and 686 upper case ones). Note that there seems to be no definition of what is to be considered alphanumeric in Unicode. The only quote I found was in http://www.w3.org/TR/xslt#convert which says: """ Alphanumeric means any character that has a Unicode category of Nd, Nl, No, Lu, Ll, Lt, Lm or Lo. """ Here's what the glibc has to say about these chars: /* Test for any wide character for which `iswupper' or 'iswlower' is true, or any wide character that is one of a locale-specific set of wide-characters for which none of `iswcntrl', `iswdigit', `iswpunct', or `iswspace' is true. */ extern int iswalpha __P ((wint_t __wc)); Question: Should I go ahead and add the Lo and Lm tables to unicodectype.c ? Pros: standards confrom Cons: huge in size -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From martin@loewis.home.cs.tu-berlin.de Mon Jul 3 14:08:56 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 3 Jul 2000 15:08:56 +0200 Subject: [Python-Dev] Minidom and Unicode In-Reply-To: <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> (effbot@telia.com) References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> Message-ID: <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> > works for me: > > $ export LANG=posix.utf8 [...] > (or to put it another way, I'm not sure the repr/str fix is > the real culprit here...) I think it is. My understanding is that repr always returns something printable - if possible even something that can be passed to eval. I'd certainly expect that a minidom Node can be printed always, no matter what the default encoding is. Consequently, I'd prefer if the conversion uses some fixed, repr-style encoding, eg. unicode-escape (just as repr of a unicode object does). If it is deemed unacceptable to put this into the interpreter proper, I'd prefer if minidom is changed to allow representation of all Nodes on all systems. Regards, Martin From esr@thyrsus.com Mon Jul 3 14:56:00 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 09:56:00 -0400 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? Message-ID: <20000703095600.A12141@thyrsus.com> I have a valid ssh account on SourceForge. I follow the directions on the Python CVS page and get this: Script started on Mon Jul 3 09:50:42 2000 snark:~/WWW/python$ echo $CVS_RSH /usr/bin/ssh snark:~/WWW/python$ cvs -z3 -desr@cvs.python.sourceforge.net:/cvsroot/python co python esr@cvs.python.sourceforge.net's password: cvs checkout: warning: unrecognized response `' from cvs server cvs checkout: warning: unrecognized response `Welcome to cvs1.sourceforge.net' from cvs server cvs checkout: warning: unrecognized response `' from cvs server cvs checkout: warning: unrecognized response `This is a restricted Shell Account' from cvs server cvs checkout: warning: unrecognized response `You cannot execute anything here.' from cvs server cvs checkout: warning: unrecognized response `' from cvs server cvs [checkout aborted]: end of file from server (consult above messages if any) snark:~/WWW/python$ exit Script done on Mon Jul 3 09:51:23 2000 -- Eric S. Raymond Idealism is the noble toga that political gentlemen drape over their will to power. -- Aldous Huxley From root@theporch.com Mon Jul 3 14:46:00 2000 From: root@theporch.com (Phillip Porch) Date: Mon, 3 Jul 2000 08:46:00 -0500 (CDT) Subject: [Python-Dev] Typo in pty.py Message-ID: I was compiling and testing the current snapshot of python (current as of 7:00 AM CDT 7/3/00) and found that test_pty failed. Here is the output of the test. [sco root-tty01 src] ./python Lib/test/test_pty.py Calling master_open() Got master_fd '6', slave_name '/dev/ttyp1' Calling slave_open('/dev/ttyp1') Got slave_fd '7' Writing to slave_fd I wish to buy a fish license. For my pet fish, Eric. calling pty.fork() Traceback (most recent call last): File "Lib/test/test_pty.py", line 50, in ? pid, master_fd = pty.fork() File "./Lib/pty.py", line 95, in fork master_fd, slave_fd = openpty() File "./Lib/pty.py", line 28, in openpty slave_fd = _slave_open(slave_name) NameError: _slave_open I believe there is a typo on line 28 in Lib/pty.py... the call should not be _slave_open but slave_open. I made that change and the test ran fine. -- Phillip P. Porch NIC:PP1573 finger for http://www.theporch.com UTM - 16 514546E 3994565N PGP key From gward@mems-exchange.org Mon Jul 3 14:50:16 2000 From: gward@mems-exchange.org (Greg Ward) Date: Mon, 3 Jul 2000 09:50:16 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000703052052.E11175@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 03, 2000 at 05:20:52AM -0400 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> <20000703052052.E11175@thyrsus.com> Message-ID: <20000703095016.A24655@ludwig.cnri.reston.va.us> [Fred L. Drake, Jr. ] > Yes, but the name is confusing, because it isn't raised for every > sort of indentation error if it's only used for tab/space problems: [Eric S. Raymond] > WhitespaceError How about TabError? Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From esr@thyrsus.com Mon Jul 3 15:04:05 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 10:04:05 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000703095016.A24655@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Mon, Jul 03, 2000 at 09:50:16AM -0400 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> <20000703052052.E11175@thyrsus.com> <20000703095016.A24655@ludwig.cnri.reston.va.us> Message-ID: <20000703100405.B12176@thyrsus.com> Greg Ward : > [Fred L. Drake, Jr. ] > > Yes, but the name is confusing, because it isn't raised for every > > sort of indentation error if it's only used for tab/space problems: > > [Eric S. Raymond] > > WhitespaceError > > How about TabError? Not a big deal to me which gets used. -- Eric S. Raymond The United States is in no way founded upon the Christian religion -- George Washington & John Adams, in a diplomatic message to Malta. From fredrik@pythonware.com Mon Jul 3 15:01:17 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Mon, 3 Jul 2000 16:01:17 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> Message-ID: <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> martin wrote: > > > > $ export LANG=posix.utf8 > [...] > > (or to put it another way, I'm not sure the repr/str fix is > > the real culprit here...) > > I think it is. My understanding is that repr always returns something > printable - if possible even something that can be passed to eval. I'd > certainly expect that a minidom Node can be printed always, no matter > what the default encoding is. > > Consequently, I'd prefer if the conversion uses some fixed, repr-style > encoding, eg. unicode-escape (just as repr of a unicode object does). oh, you're right. repr should of course use unicode-escape, not the default encoding. my fault. I'll update the repository soonish. > If it is deemed unacceptable to put this into the interpreter proper, > I'd prefer if minidom is changed to allow representation of all Nodes > on all systems. the reason for this patch was to avoid forcing everyone to deal with this in their own code, by providing some kind of fallback behaviour. From fdrake@beopen.com Mon Jul 3 15:23:34 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 10:23:34 -0400 (EDT) Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000703095600.A12141@thyrsus.com> References: <20000703095600.A12141@thyrsus.com> Message-ID: <14688.41446.716190.904222@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > I have a valid ssh account on SourceForge. I follow the directions on the > Python CVS page and get this: This looks like SourceForge is having problems. Have you verified that you've installed your public key? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal@lemburg.com Mon Jul 3 16:35:18 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 17:35:18 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> Message-ID: <3960B2B6.9290F932@lemburg.com> Fredrik Lundh wrote: > > martin wrote: > > > > > > $ export LANG=posix.utf8 > > [...] > > > (or to put it another way, I'm not sure the repr/str fix is > > > the real culprit here...) > > > > I think it is. My understanding is that repr always returns something > > printable - if possible even something that can be passed to eval. I'd > > certainly expect that a minidom Node can be printed always, no matter > > what the default encoding is. > > > > Consequently, I'd prefer if the conversion uses some fixed, repr-style > > encoding, eg. unicode-escape (just as repr of a unicode object does). > > oh, you're right. repr should of course use unicode-escape, not > the default encoding. my fault. > > I'll update the repository soonish. I'd rather have some more discussion about this... IMHO, all auto-conversions should use the default encoding. The main point here is not to confuse the user with even more magic happening under the hood. If the programmer knows that he'll have to deal with Unicode then he should make sure that the proper encoding is used and document it that way, e.g. use unicode-escape for Minidom's __repr__ methods. BTW, any takers for __unicode__ to complement __str__ ? > > If it is deemed unacceptable to put this into the interpreter proper, > > I'd prefer if minidom is changed to allow representation of all Nodes > > on all systems. > > the reason for this patch was to avoid forcing everyone to deal with > this in their own code, by providing some kind of fallback behaviour. That's what your patch does; I don't see a reason to change it :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From esr@thyrsus.com Mon Jul 3 16:53:36 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 11:53:36 -0400 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <14688.41446.716190.904222@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 03, 2000 at 10:23:34AM -0400 References: <20000703095600.A12141@thyrsus.com> <14688.41446.716190.904222@cj42289-a.reston1.va.home.com> Message-ID: <20000703115336.C12315@thyrsus.com> Fred L. Drake, Jr. : > > Eric S. Raymond writes: > > I have a valid ssh account on SourceForge. I follow the directions on the > > Python CVS page and get this: > > This looks like SourceForge is having problems. Have you verified > that you've installed your public key? Yes, I can ssh to my SouurceForge account with no problems. -- Eric S. Raymond When all government ...in little as in great things... shall be drawn to Washington as the center of all power; it will render powerless the checks provided of one government on another, and will become as venal and oppressive as the government from which we separated." -- Thomas Jefferson, 1821 Don't think of it as `gun control', think of it as `victim disarmament'. If we make enough laws, we can all be criminals. From Fredrik Lundh" This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BFE518.8CD4DF00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable for the curious: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-07/msg00004.h= tml ------=_NextPart_000_0005_01BFE518.8CD4DF00 Content-Type: application/octet-stream; name="Unicode Handling HOWTO.url" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Unicode Handling HOWTO.url" [DEFAULT] BASEURL=http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-07/msg00004.html [InternetShortcut] URL=http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-07/msg00004.html Modified=60D257A907E5BF01DE ------=_NextPart_000_0005_01BFE518.8CD4DF00-- From paul@prescod.net Mon Jul 3 17:15:46 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 11:15:46 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> Message-ID: <3960BC32.CBBF3D6D@prescod.net> "M.-A. Lemburg" wrote: > > ... > > IMHO, all auto-conversions should use the default encoding. The > main point here is not to confuse the user with even more magic > happening under the hood. I don't see anything confusing about having unicode-escape be the appropriate escape used for repr. Maybe we need to differentiate between lossless and lossy encodings. If the default encoding is lossless then repr could use it. Otherwise it could use unicode-escape. Anyhow, why would it be wrong for Fredrick to hard-code an encoding in repr but right for me to hard-code one in minidom? Users should not need to comb through the hundreds of modules in the library figuring out what kind of Unicode handling they should expect. It should be as centralized as possible. > If the programmer knows that he'll have to deal with Unicode > then he should make sure that the proper encoding is used > and document it that way, e.g. use unicode-escape for Minidom's > __repr__ methods. One of the major goals of our current Unicode auto-conversion "compromise" is that modules like xmllib and minidom should work with Unicode out of the box without any special enhancements. According to Guido, that's the primary reason we have Unicode auto-conversions at all. http://www.python.org/pipermail/i18n-sig/2000-May/000173.html I'm going to fight very hard to make basic Unicode support in Python modules "just work" without a bunch of internationalization knowledge from the programmer. __repr__ is pretty basic. > > the reason for this patch was to avoid forcing everyone to deal with > > this in their own code, by providing some kind of fallback behaviour. > > That's what your patch does; I don't see a reason to change it :-) If you're still proposing that I should deal with it in a particular module's domain-specific code then the patch isn't done yet! -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul@prescod.net Mon Jul 3 17:21:26 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 11:21:26 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <39605067.DCC2B968@lemburg.com> Message-ID: <3960BD86.A10797E3@prescod.net> "M.-A. Lemburg" wrote: > > ... > > I think it's ok to auto-convert to the default encoding > as intermediate solution, but the applications wanting to > return Unicode as __repr__ or __str__ should really > use .encode() to make sure the output that is produces > matches their (or their user's) expectations. If my users have expectations, I don't know them. I could allow them to tell me what encoding to use, but surely they would rather do that in a Python-wide fashion. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul@prescod.net Mon Jul 3 17:24:41 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 11:24:41 -0500 Subject: [Python-Dev] Sorry. No Release. References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> Message-ID: <3960BE49.CAB2776B@prescod.net> "Fred L. Drake, Jr." wrote: > > ... > > (Just adding IndentationError for -tt isn't hard, I have a > preliminary patch for that now. Adding it for the case above looks > harder.) I think that in a perfect world, IndentationError would apply to both of them. Maybe TabError would be a subclass of IndentationError. You could set up the hierarchy that way without actually implementing the code that recognizes "ordinary" indentation errors. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From mal@lemburg.com Mon Jul 3 17:37:12 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 18:37:12 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> <3960BC32.CBBF3D6D@prescod.net> Message-ID: <3960C138.85D9B36A@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > IMHO, all auto-conversions should use the default encoding. The > > main point here is not to confuse the user with even more magic > > happening under the hood. > > I don't see anything confusing about having unicode-escape be the > appropriate escape used for repr. Maybe we need to differentiate between > lossless and lossy encodings. If the default encoding is lossless then > repr could use it. Otherwise it could use unicode-escape. Simply because auto-conversion should use one single encoding throughout the code. > Anyhow, why would it be wrong for Fredrick to hard-code an encoding in > repr but right for me to hard-code one in minidom? Because hardcoding the encoding into the core Python API touches all programs. Hardcoded encodings should be userland options whereever possible. Besides, we're talking about __repr__ which is mainly a debug tool and doesn't affect program flow or interfacing in any way. The format used is a userland decision and the encoding used for it is too. > Users should not need > to comb through the hundreds of modules in the library figuring out what > kind of Unicode handling they should expect. It should be as centralized > as possible. True. > > If the programmer knows that he'll have to deal with Unicode > > then he should make sure that the proper encoding is used > > and document it that way, e.g. use unicode-escape for Minidom's > > __repr__ methods. > > One of the major goals of our current Unicode auto-conversion > "compromise" is that modules like xmllib and minidom should work with > Unicode out of the box without any special enhancements. According to > Guido, that's the primary reason we have Unicode auto-conversions at > all. > > http://www.python.org/pipermail/i18n-sig/2000-May/000173.html > > I'm going to fight very hard to make basic Unicode support in Python > modules "just work" without a bunch of internationalization knowledge > from the programmer. Great :-) The next big project ought to be getting the standard lib to work with Unicode input. A good way to test drive this, is running Python with -U option. > __repr__ is pretty basic. > > > > the reason for this patch was to avoid forcing everyone to deal with > > > this in their own code, by providing some kind of fallback behaviour. > > > > That's what your patch does; I don't see a reason to change it :-) > > If you're still proposing that I should deal with it in a particular > module's domain-specific code then the patch isn't done yet! You don't have too: a user who uses Latin-1 tag names will see the output of __repr__ as Latin-1... pretty straight forward if you ask me. If you want to make sure that __repr__ output is printable everywhere you should use an explicit lossless encoding for your application. Again, this is a userland decision which you'll have to make. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Mon Jul 3 17:39:52 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 18:39:52 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <39605067.DCC2B968@lemburg.com> <3960BD86.A10797E3@prescod.net> Message-ID: <3960C1D8.18C4EA7D@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > I think it's ok to auto-convert to the default encoding > > as intermediate solution, but the applications wanting to > > return Unicode as __repr__ or __str__ should really > > use .encode() to make sure the output that is produces > > matches their (or their user's) expectations. > > If my users have expectations, I don't know them. I could allow them to > tell me what encoding to use, but surely they would rather do that in a > Python-wide fashion. They can choose the encoding by setting their LANG variable or you could make the setting application specific by using .encode where needed. BTW, are tag names using non-ASCII really used in practice ? I can understand values being Unicode, but Unicode tag names don't really make all that much sense to me (ok, that's a personal opinion). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Mon Jul 3 17:44:14 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 18:44:14 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> <028301bfe37f$bb349380$f2a6b5d4@hagrid> <395E44E2.63383BC5@lemburg.com> <39606D0C.CB3F18FD@lemburg.com> Message-ID: <3960C2DE.F7E2FB7A@lemburg.com> FYI, I've added two new macros which allow querying alphabetic and alphanumeric characters: Py_UNICODE_ISALPHA() and Py_UNICODE_ISALNUM() The implementation is currently only experimental -- some 5200 chars are missing from being correctly identified as being alphanumeric (see my other post on the topic). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> <3960BC32.CBBF3D6D@prescod.net> <3960C138.85D9B36A@lemburg.com> Message-ID: <00d201bfe510$573fce20$f2a6b5d4@hagrid> mal wrote: > > Anyhow, why would it be wrong for Fredrick to hard-code an encoding = in > > repr but right for me to hard-code one in minidom?=20 >=20 > Because hardcoding the encoding into the core Python API touches > all programs. Hardcoded encodings should be userland options > whereever possible. the problem is that the existing design breaks peoples expectations: first, minidom didn't work because people expected to be able to return the result of: "8 bit string" + something + "8 bit string" or "8 bit string %s" % something from __repr__. that's a reasonable expectation (just look in the python standard library). after my fix, minidom still didn't work because people expected the conversion to work on all strings, on all platforms. that's also a reasonable expectation (read on). > Besides, we're talking about __repr__ which is mainly a > debug tool and doesn't affect program flow or interfacing > in any way. exactly. this is the whole point: __repr__ is a debug tool, and therefore it must work in all platforms, for all strings. if it's true that repr() cannot be changed to return unicode strings (in which case the conversion will be done on the way out to the user, by a file object or a user-interface library which might actually know what encoding to use), using a lossless encoding is the second best thing. on the other hand, if we can change repr/str, this is a non- issue. maybe someone could tell me exactly what code we'll break if we do that change? From gward@mems-exchange.org Mon Jul 3 18:07:48 2000 From: gward@mems-exchange.org (Greg Ward) Date: Mon, 3 Jul 2000 13:07:48 -0400 Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: <200007010151.DAA00574@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sat, Jul 01, 2000 at 03:51:07AM +0200 References: <200007010151.DAA00574@python.inrialpes.fr> Message-ID: <20000703130748.A31370@ludwig.cnri.reston.va.us> [Ping] > Okay, i just discovered sunau.py. Here's my real shot at > test_linuxaudiodev.py. Can you give this a try? Didn't work -- even after I changed has_key(formats, ...) to formats.has_key(...). Here's what I get: Traceback (most recent call last): File "test_linuxaudiodev-ping.py", line 37, in ? test() File "test_linuxaudiodev-ping.py", line 35, in test play_au_file(findfile('audiotest.au')) File "test_linuxaudiodev-ping.py", line 26, in play_au_file raise "audio format not supported by linuxaudiodev" audio format not supported by linuxaudiodev Sheesh, you'd think that plain old "Sun/NeXT audio data: 8-bit ISDN u-law, mono, 8000 Hz" (this is what "file" reports on "audiotest.au") would be supported. ;-) So I tried Michael Hudson's version. It also failed, but in a more interesting way. There mere traceback is not enough, but it's a start: Traceback (most recent call last): File "test_linuxaudiodev-hudson.py", line 62, in ? test() File "test_linuxaudiodev-hudson.py", line 60, in test play_au_file(findfile('audiotest.au')) File "test_linuxaudiodev-hudson.py", line 55, in play_au_file dsp.write(data) linuxaudiodev.error: (11, 'Resource temporarily unavailable') Here's the sequence of events I get: * run Michael's version of test_linuxaudiodev.py * it *immediately* dumps the above traceback, but does not return me to my shell prompt * Cardinal Fang *does* start his famous proclamation, and it sounds right (same as I get from "play audiotest.au") * but it's truncated about 3/4 of the way through: "Nobody expects the Spani----" * and then Python terminates with exit status 1 (presumably due to the traceback) Very curious! I know next-to-nothing about both Python's exception handling, sound drivers on Linux, and PC audio hardware. Any speculation I might offer would probably be useless, so I will merely comment that this is indeed curious. Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From bckfnn@worldonline.dk Mon Jul 3 18:06:05 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Mon, 03 Jul 2000 17:06:05 GMT Subject: [Python-Dev] unicode alphanumerics In-Reply-To: <39606D0C.CB3F18FD@lemburg.com> References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> <028301bfe37f$bb349380$f2a6b5d4@hagrid> <395E44E2.63383BC5@lemburg.com> <39606D0C.CB3F18FD@lemburg.com> Message-ID: <3960c790.8381401@smtp.worldonline.dk> [M.-A. Lemburg] >"M.-A. Lemburg" wrote: >> >> Fredrik Lundh wrote: >> > how about this plan: >> > >> > -- you add a Py_UNICODE_ALPHA to unicodeobject.h asap, >> > which does exactly that (or I can do that, if you prefer). >> > (and maybe even a Py_UNICODE_ALNUM) >> >> Ok, I'll add Py_UNICODE_ISALPHA and Py_UNICODE_ISALNUM >> (first with approximations of the sort you give above and >> later with true implementations using tables in unicodectype.c) >> on Monday... gotta run now. >> >> > -- I change SRE to use that asap. >> > >> > -- you, I, or someone else add a better implementation, >> > some other day. > >I've just looked into this... the problem here is what to >consider as being "alpha" and what "numeric". > >I could add two new tables for the characters with category 'Lo' >(other letters, not cased) and 'Lm' (letter modifiers) >to match all letters in the Unicode database, but those >tables have some 5200 entries (note that there are only 804 lower >case letters and 686 upper case ones). In JDK1.3, Character.isLetter(..) and Character.isDigit(..) are documented as: http://java.sun.com/j2se/1.3/docs/api/java/lang/Character.html#isLetter(char) http://java.sun.com/j2se/1.3/docs/api/java/lang/Character.html#isDigit(char) http://java.sun.com/j2se/1.3/docs/api/java/lang/Character.html#isLetterOrDigit(char) I guess that java uses the extra huge tables. regards, finn From paul@prescod.net Mon Jul 3 19:38:26 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 13:38:26 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> <3960BC32.CBBF3D6D@prescod.net> <3960C138.85D9B36A@lemburg.com> <00d201bfe510$573fce20$f2a6b5d4@hagrid> Message-ID: <3960DDA2.3C608267@prescod.net> Fredrik Lundh wrote: > > ... > > exactly. this is the whole point: __repr__ is a debug tool, > and therefore it must work in all platforms, for all strings. As a debugging tool, it would probably help rather than hurt things to have repr be consistent on all platforms. If it is going to do a conversion, I vote for unicode-escape everywhere. > on the other hand, if we can change repr/str, this is a non- > issue. maybe someone could tell me exactly what code we'll > break if we do that change? I agree that we want to move to a world where unicode strings and 8-bit strings are accepted equally throughout Python. We do need some information about whether moving there quickly will break code or not. We need to know what Idle, PythonWin, Zope and other such environments do with the results of repr. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From ping@lfw.org Mon Jul 3 22:35:38 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Mon, 3 Jul 2000 16:35:38 -0500 (CDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000703095016.A24655@ludwig.cnri.reston.va.us> Message-ID: Eric S. Raymond wrote: > WhitespaceError Greg Ward wrote: > How about TabError? But what i'd really like is an IndentationError that shows up whenever there's an indentation problem. It doesn't even have to be its own class of error, i suppose, as long as it gets indicated some way ("SyntaxError: invalid indentation" would be fine). This response would be good for all of the following situations: >>> 3 File "", line 1 3 ^ SyntaxError: invalid syntax >>> if 1: ... 3 File "", line 2 3 ^ SyntaxError: invalid syntax >>> if 1: ... 3 ... 4 inconsistent dedent File "", line 3 4 ^ SyntaxError: invalid token >>> if 1: ... if 2: ... 3 File "", line 3 3 ^ SyntaxError: invalid syntax >>> if 1: ... if 2: ... 3 inconsistent dedent File "", line 3 3 ^ SyntaxError: invalid token >>> if 1: ... if 2: ... 3 ... 4 inconsistent dedent File "", line 4 4 ^ SyntaxError: invalid token -- ?!ng From tim_one@email.msn.com Mon Jul 3 22:52:13 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 3 Jul 2000 17:52:13 -0400 Subject: [Python-Dev] Just spotted on SourceForge main page In-Reply-To: <20000628223707.A1168@beelzebub> Message-ID: > Maybe this is what all you Windows folks are looking for. > > SFSetup v1 released > mhearn - 06/28/00 11:00 - SourceForge Setup for Win32 > > SFSetup is a program to automatically setup SSH and WinCVS for > SourceForge projects under the Windows 32 platform. It's now available > for download so if you have not yet set up SSH and WinCVS and want it > done for you, you can use this program. Go to sfsetup.sourceforge.net > to find out how to use it. It's open source and written in Delphi - > the code is in CVS and any improvements are welcome! Thanks -mike Note that this requires WinCVS 1.06 specifically (something like that -- see SFSetup's readme or whatever). I tried using it with a later version of WinCVS, and it left my machine in some state such that the behaviors of both cmdline CVS and WinCVS make no sense to anyone who has seen them actually working correctly. Barry in particular is baffled by how I manage to check in anything at all now. My ssh_keygen doesn't work either (no, I do *not* need even more pointers to purported Windows ssh implementations -- I've got 'em all, and I'll eventually unpack the one that happens to work on my system ). The great thing about all the instructions I've found so far is that they're written by people who apparently have no real understanding of how the underlying components (and/or Windows) work. So they're full of magical incantations that may or may not make sense on your particular setup. They may as well be trying to explain how to get the Microsoft Foundation Classes running under Linux . poke-&-hope-will-win-in-the-end-ly y'rs - tim From paul@prescod.net Mon Jul 3 23:31:57 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 17:31:57 -0500 Subject: [Python-Dev] Just spotted on SourceForge main page References: Message-ID: <3961145D.708AFDB6@prescod.net> Tim Peters wrote: > > .. > > The great thing about all the instructions I've found so far is that they're > written by people who apparently have no real understanding of how the > underlying components (and/or Windows) work. So they're full of magical > incantations that may or may not make sense on your particular setup. I found the same damn thing. I actually emailed one of the guys about an apparent contradiction between his howto and another one and he basically said: "Hey, this is what works for me!" (in his defence, he did justify his interpration based on guesses about what the ssh for Windows porters were thinking) I also found that sfsetup program useless. Worse than useless. I have no idea what it did to my system. Argh. I eventually got it working. I'd love to tell you what I did but I just hacked and hacked until it worked. One time I got those messages that ESR did but who knows what made them go away. I'm not using ssh keys. I just specify my password over and over and over and over and... -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From fdrake@beopen.com Mon Jul 3 23:58:22 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 18:58:22 -0400 (EDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: References: <20000703095016.A24655@ludwig.cnri.reston.va.us> Message-ID: <14689.6798.745740.419095@cj42289-a.reston1.va.home.com> Ka-Ping Yee writes: > But what i'd really like is an IndentationError that shows > up whenever there's an indentation problem. That's what I think of when I hear "IndentationError" -- TabError is a specialized case of that. I think the general IndentationError will be hard to do, since many cases are just another parse error by the time they can be turned into exceptions. Unless I'm misreading that code. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein@lyra.org Tue Jul 4 00:20:43 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 16:20:43 -0700 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <14689.6798.745740.419095@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 03, 2000 at 06:58:22PM -0400 References: <20000703095016.A24655@ludwig.cnri.reston.va.us> <14689.6798.745740.419095@cj42289-a.reston1.va.home.com> Message-ID: <20000703162043.K29590@lyra.org> On Mon, Jul 03, 2000 at 06:58:22PM -0400, Fred L. Drake, Jr. wrote: > > Ka-Ping Yee writes: > > But what i'd really like is an IndentationError that shows > > up whenever there's an indentation problem. > > That's what I think of when I hear "IndentationError" -- TabError is > a specialized case of that. > I think the general IndentationError will be hard to do, since many > cases are just another parse error by the time they can be turned into > exceptions. Unless I'm misreading that code. Speaking out of my butt here, without looking at code, I would suspect that the parser can return specializations "syntax error" to indicate that a problem with indentation occurred. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Tue Jul 4 00:53:05 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 16:53:05 -0700 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000703095600.A12141@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 03, 2000 at 09:56:00AM -0400 References: <20000703095600.A12141@thyrsus.com> Message-ID: <20000703165305.R29590@lyra.org> On Mon, Jul 03, 2000 at 09:56:00AM -0400, Eric S. Raymond wrote: > I have a valid ssh account on SourceForge. I follow the directions on the > Python CVS page and get this: > > Script started on Mon Jul 3 09:50:42 2000 > snark:~/WWW/python$ echo $CVS_RSH > /usr/bin/ssh > snark:~/WWW/python$ cvs -z3 -desr@cvs.python.sourceforge.net:/cvsroot/python co python I used: $ cvs -z3 -d :ext:gstein@cvs.python.sourceforge.net:/cvsroot/python co python The instructions on SF didn't quite work. Adding the :ext: in made it work fine for me. I'm using CVS 1.10.6 Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake@beopen.com Tue Jul 4 00:54:43 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 19:54:43 -0400 (EDT) Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000703165305.R29590@lyra.org> References: <20000703095600.A12141@thyrsus.com> <20000703165305.R29590@lyra.org> Message-ID: <14689.10179.591139.81266@cj42289-a.reston1.va.home.com> Greg Stein writes: > I used: > > $ cvs -z3 -d :ext:gstein@cvs.python.sourceforge.net:/cvsroot/python co python > > The instructions on SF didn't quite work. Adding the :ext: in made it work > fine for me. I'm using CVS 1.10.6 Interesting; using CVS 1.10.7 I was able to check out a tree using my login & SSH (requiring my passphrase, not password), but I didn't need the :ext: part. Sounds like there are some real version dependencies in the instructions. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@beopen.com Tue Jul 4 03:25:33 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 03 Jul 2000 21:25:33 -0500 Subject: [Python-Dev] Copyright notice In-Reply-To: Your message of "Sun, 02 Jul 2000 00:43:17 +0200." <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> References: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> Message-ID: <200007040225.VAA01396@cj20424-a.reston1.va.home.com> > On startup, the current CVS python reports (on my system) > > Python 2.0b1 (#31, Jul 1 2000, 23:13:39) [GCC 2.95.2 19991024 (release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > > Now that the file copyrights are changed, I expect this message to > change as well. May I suggest that, instead of adding another line, > the two last lines of this message are removed? > > People who need to find out who holds the copyright to this software > still can print sys.copyright. I think I recall this was a convention that the GNU folks claim is required from a legal standpoint. E.g. when I start gdb, I get: GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux". (gdb) The Python welcome message is a lot less verbose! But I am not a lawyer (IANAL) and maybe the GNU folks are superstitious about this. On the other hand, why does it bother you? (*NOT* a rhetorical question.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr@thyrsus.com Tue Jul 4 02:48:17 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 21:48:17 -0400 Subject: [Python-Dev] Copyright notice In-Reply-To: <200007040225.VAA01396@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 03, 2000 at 09:25:33PM -0500 References: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> <200007040225.VAA01396@cj20424-a.reston1.va.home.com> Message-ID: <20000703214817.A13791@thyrsus.com> Guido van Rossum : > On the other hand, why does it bother you? (*NOT* a rhetorical question.) Maybe he doesn't like noisy programs. I don't either. Programs should either (a) tell me what I need to hear, (b) tell me what I've asked to hear, or (c) keep their traps shut and refrain from wasting my time and attention. (There are some who would say this atttude makes me old-fashioned in an age of GUIs. Au contraire -- visual gewgaws and noise are so seductive to interface designers that we need to be *less* tolerant of noise than formerly.) -- Eric S. Raymond The men and women who founded our country knew, by experience, that there are times when the free person's answer to oppressive government has to be delivered with a bullet. Thus, the right to bear arms is not just *a* freedom; it's the mother of all freedoms. Don't let them disarm you! From gstein@lyra.org Tue Jul 4 03:02:36 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 19:02:36 -0700 Subject: [Python-Dev] Copyright notice In-Reply-To: <20000703214817.A13791@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 03, 2000 at 09:48:17PM -0400 References: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> <200007040225.VAA01396@cj20424-a.reston1.va.home.com> <20000703214817.A13791@thyrsus.com> Message-ID: <20000703190235.G29590@lyra.org> On Mon, Jul 03, 2000 at 09:48:17PM -0400, Eric S. Raymond wrote: > Guido van Rossum : > > On the other hand, why does it bother you? (*NOT* a rhetorical question.) > > Maybe he doesn't like noisy programs. I don't either. Programs > should either (a) tell me what I need to hear, (b) tell me what I've > asked to hear, or (c) keep their traps shut and refrain from wasting my > time and attention. Agreed. I've prefer not to have several lines of spammage hit my screen whenever I invoked Python. What's the point? And note there isn't a license requirement to print that stuff. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond@skippinet.com.au Tue Jul 4 03:31:11 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Tue, 4 Jul 2000 12:31:11 +1000 Subject: [Python-Dev] Copyright notice In-Reply-To: <20000703214817.A13791@thyrsus.com> Message-ID: > Programs > should either (a) tell me what I need to hear, (b) tell me what I've > asked to hear, or (c) keep their traps shut and refrain from wasting my > time and attention. You have almost described my perfect partner :-) [Not really, of course, but the sexist comparison was just _screaming_ to be made :-] Mark. From gstein@lyra.org Tue Jul 4 03:59:08 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 19:59:08 -0700 Subject: [Python-Dev] Copyright notice In-Reply-To: ; from mhammond@skippinet.com.au on Tue, Jul 04, 2000 at 12:31:11PM +1000 References: <20000703214817.A13791@thyrsus.com> Message-ID: <20000703195908.H29590@lyra.org> On Tue, Jul 04, 2000 at 12:31:11PM +1000, Mark Hammond wrote: > > > Programs > > should either (a) tell me what I need to hear, (b) tell me what I've > > asked to hear, or (c) keep their traps shut and refrain from wasting my > > time and attention. > > You have almost described my perfect partner :-) *rofl* > [Not really, of course, but the sexist comparison was just _screaming_ to > be made :-] Sexist? Not at all. You didn't say whether your perfect partner was a man or a woman. ;-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake@beopen.com Tue Jul 4 05:35:00 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 00:35:00 -0400 (EDT) Subject: [Python-Dev] Making -tt the default Message-ID: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> The recent discussion about the possibility of specialized forms of SyntaxError for indentation and tab/space issues brings up the problem of the -t/-tt options to the interpreter. If a distinct exception is defined for indentation-related errors, that could probably be implemented and tested without regard for the -t/-tt setting, except for the tab/space exception. That exception is only raised when -tt is specified, and there's no way from Python to determine if it is set except for testing to see that the exception is raised when ambiguous tab/space combinations are presented to the tokenizer. This reminds us that most programmers aren't going to bother with the -tt option; it's something extra that they don't really need to get the job done. Life without it, however, is shakey: Python code is harder to share than it needs to be because nobody can rely on non-ambiguous tab/space usage. If -tt were the default, the problem would not be discovered after code is deployed but, rather, before it is otherwise tested by the original developers and maintainers. There are two things that can be done: have distutils always use -tt when compiling code that gets installed (using a child interpreter if needed), and setting -tt as the default in the next Python release. Using -tt in the distutils will cause this setting to be used with Python 1.5.2 installations. Setting -tt to be the default, and not having a way to override it, would lead to some small code simplifications as well. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From DavidA@ActiveState.com Tue Jul 4 05:45:22 2000 From: DavidA@ActiveState.com (David Ascher) Date: Mon, 3 Jul 2000 21:45:22 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: > This reminds us that most programmers aren't going to bother with > the -tt option; it's something extra that they don't really need to > get the job done. Which reminds me that I'd really like the default python-mode.el to use more 'strict' defaults than it currently does. I don't know how, but I routinely generate bad indentations w/ pymode, which I blame on bad defaults in the elisp file. I can fix the config, of course, with enough work, but I believe it should be set to a more strict default. --da From fdrake@beopen.com Tue Jul 4 05:49:53 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 00:49:53 -0400 (EDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000703162043.K29590@lyra.org> References: <20000703095016.A24655@ludwig.cnri.reston.va.us> <14689.6798.745740.419095@cj42289-a.reston1.va.home.com> <20000703162043.K29590@lyra.org> Message-ID: <14689.27889.33072.39039@cj42289-a.reston1.va.home.com> --nSaKzIhbgS Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit Greg Stein writes: > Speaking out of my butt here, without looking at code, I would suspect that > the parser can return specializations "syntax error" to indicate that a > problem with indentation occurred. And I'm sure you'll find the way to do it. ;) Here's a patch that sets up the IndentationError and TabError exceptions, and gets TabError raised when -tt is in effect. If you can figure out how to get IndentationError raised for other indentation-related errors, I'll be interested in seeing it. Essentially, the parser-generator will need to be able to distinguish between INDENT/DEDENT errors and other errors, and I've not dug deep enough to figure that one out. The tab/space errors are easy since they're in the hand-coded lexer. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member --nSaKzIhbgS Content-Type: text/plain Content-Description: SyntaxError specialization Content-Disposition: inline; filename="indentation-error.patch" Content-Transfer-Encoding: 7bit *** cvs-python/Include/pyerrors.h Fri Jun 30 19:58:04 2000 --- python/Include/pyerrors.h Mon Jul 3 19:35:06 2000 *************** *** 54,59 **** --- 54,61 ---- extern DL_IMPORT(PyObject *) PyExc_RuntimeError; extern DL_IMPORT(PyObject *) PyExc_NotImplementedError; extern DL_IMPORT(PyObject *) PyExc_SyntaxError; + extern DL_IMPORT(PyObject *) PyExc_IndentationError; + extern DL_IMPORT(PyObject *) PyExc_TabError; extern DL_IMPORT(PyObject *) PyExc_SystemError; extern DL_IMPORT(PyObject *) PyExc_SystemExit; extern DL_IMPORT(PyObject *) PyExc_TypeError; *** cvs-python/Lib/test/test_exceptions.py Tue Jun 20 14:52:57 2000 --- python/Lib/test/test_exceptions.py Tue Jul 4 00:36:58 2000 *************** *** 86,91 **** --- 86,99 ---- try: exec '/\n' except SyntaxError: pass + r(IndentationError) + + r(TabError) + # can only be tested under -tt, and is the only test for -tt + #try: compile("try:\n\t1/0\n \t1/0\nfinally:\n pass\n", '', 'exec') + #except TabError: pass + #else: raise TestFailed + r(SystemError) print '(hard to reproduce)' *** cvs-python/Lib/test/output/test_exceptions Sun Jun 25 06:44:57 2000 --- python/Lib/test/output/test_exceptions Tue Jul 4 00:43:31 2000 *************** *** 28,33 **** --- 28,37 ---- spam SyntaxError spam + IndentationError + spam + TabError + spam SystemError (hard to reproduce) spam *** cvs-python/Python/exceptions.c Sat Jul 1 00:45:52 2000 --- python/Python/exceptions.c Mon Jul 3 19:34:25 2000 *************** *** 68,73 **** --- 68,78 ---- |\n\ +-- AttributeError\n\ +-- SyntaxError\n\ + | |\n\ + | +-- IndentationError\n\ + | |\n\ + | +-- TabError\n\ + |\n\ +-- TypeError\n\ +-- AssertionError\n\ +-- LookupError\n\ *************** *** 773,778 **** --- 778,789 ---- static char MemoryError__doc__[] = "Out of memory."; + static char + IndentationError__doc__[] = "Improper indentation."; + + static char + TabError__doc__[] = "Improper mixture of spaces and tabs."; + /* module global functions */ *************** *** 807,812 **** --- 818,825 ---- PyObject *PyExc_RuntimeError; PyObject *PyExc_NotImplementedError; PyObject *PyExc_SyntaxError; + PyObject *PyExc_IndentationError; + PyObject *PyExc_TabError; PyObject *PyExc_SystemError; PyObject *PyExc_SystemExit; PyObject *PyExc_UnboundLocalError; *************** *** 868,873 **** --- 881,890 ---- {"AttributeError", &PyExc_AttributeError, 0, AttributeError__doc__}, {"SyntaxError", &PyExc_SyntaxError, 0, SyntaxError__doc__, SyntaxError_methods, SyntaxError__classinit__}, + {"IndentationError", &PyExc_IndentationError, &PyExc_SyntaxError, + IndentationError__doc__}, + {"TabError", &PyExc_TabError, &PyExc_IndentationError, + TabError__doc__}, {"AssertionError", &PyExc_AssertionError, 0, AssertionError__doc__}, {"LookupError", &PyExc_LookupError, 0, LookupError__doc__}, {"IndexError", &PyExc_IndexError, &PyExc_LookupError, *** cvs-python/Python/pythonrun.c Fri Jun 30 19:58:06 2000 --- python/Python/pythonrun.c Mon Jul 3 20:01:33 2000 *************** *** 983,990 **** err_input(err) perrdetail *err; { ! PyObject *v, *w; char *msg = NULL; v = Py_BuildValue("(ziiz)", err->filename, err->lineno, err->offset, err->text); if (err->text != NULL) { --- 983,991 ---- err_input(err) perrdetail *err; { ! PyObject *v, *w, *errtype; char *msg = NULL; + errtype = PyExc_SyntaxError; v = Py_BuildValue("(ziiz)", err->filename, err->lineno, err->offset, err->text); if (err->text != NULL) { *************** *** 1010,1015 **** --- 1011,1017 ---- msg = "unexpected EOF while parsing"; break; case E_INDENT: + errtype = PyExc_TabError; msg = "inconsistent use of tabs and spaces in indentation"; break; case E_OVERFLOW: *************** *** 1022,1028 **** } w = Py_BuildValue("(sO)", msg, v); Py_XDECREF(v); ! PyErr_SetObject(PyExc_SyntaxError, w); Py_XDECREF(w); } --- 1024,1030 ---- } w = Py_BuildValue("(sO)", msg, v); Py_XDECREF(v); ! PyErr_SetObject(errtype, w); Py_XDECREF(w); } --nSaKzIhbgS-- From fdrake@beopen.com Tue Jul 4 05:54:04 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 00:54:04 -0400 (EDT) Subject: [Python-Dev] Making -tt the default In-Reply-To: References: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: <14689.28140.772442.865150@cj42289-a.reston1.va.home.com> David Ascher writes: > Which reminds me that I'd really like the default python-mode.el to use more > 'strict' defaults than it currently does. I don't know how, but I routinely > generate bad indentations w/ pymode, which I blame on bad defaults in the > elisp file. I can fix the config, of course, with enough work, but I > believe it should be set to a more strict default. Recent versions of python-mode all use default indentations of 4 spaces, and I don't think it generates tabs. If it can, it shouldn't. Barry? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Tue Jul 4 06:01:48 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 4 Jul 2000 01:01:48 -0400 Subject: Windows vs SourceForge (was RE: [Python-Dev] Just spotted on SourceForge main page) In-Reply-To: <200007040313.WAA01842@cj20424-a.reston1.va.home.com> Message-ID: [Tim] > The great thing about all the instructions I've found so far is > that they're written by people who apparently have no real understanding > of how the underlying components (and/or Windows) work. [an anonymous Guido replied in pvt] > That was not my impression of Andy's instructions. They were to the > point and effective. Yes, they certainly *looked* that way . I didn't mean to slander Andy! His instructions didn't work for me, but then nobody else's did either, and I've increasingly suspected it's because I've got so many half-broken SSH, CVS, and WinCVS installations on this machine fighting each other. So, without an imminent release busting my homeless balls, I decided to take the time to start over from scratch: + Ran an official uninstaller for everything that left one behind (only WinCVS). + Manually tracked down all the crap WinCVS left behind in the registry anyway, and deleted it. + Deleted all the ssh and cvs .exe's on machine. + Got the crap out of my autoexec.bat (I'm running Win98SE) that various packages had inserted there (I *think* this stuff was left behind by the SourceForge setup tool). + Deleted all the .ssh directories on my machine (and found some in surprising places! e.g., one was hiding under "\My Documents"(!)). + Got rid of an absurd \etc directory (again suspect the SF setup tool, although several goofy sets of instructions demanded you create one of these). + Nuked my entire Python tree. + Rebooted. + Did a full tape backup of the machine . + Retrieved Andy Robinson's instructions and tried them again. Worked great! I'll attach a modified version below, where I filled in blanks and repaired (just a few) typos as I went along. This should get you a functional Windows cmdline CVS running with SourceForge, and I don't want a GUI version anyway. If there's anything here that isn't crystal clear or doesn't work, gripe at me, not Andy ... all's-well-that-ends-ly y'rs - tim Setting up a cmdline CVS to work with SourceForge under Windows --------------------------------------------------------------- 28-Jun-2000 Original by Andy Robinson (andy@reportlab.com) 03-Jul-2000 Modified by Tim Peters (tim_one@msn.com) 1. Get ftp.reportlab.com/tools/cvs-1.10-win.zip ftp.reportlab.com/tools/ssh-1.2.14-win32bin.zip (copied from somewhere obscure for safety, I forget where) 2. Unzip these to a location on your path. Type 'cvs' and 'ssh' from somewhere else to verify. 3. Choose where to keep your CVS projects; let's assume C:\Code 4. Create a subdirectory C:\Code\.ssh (yes, dot-ssh) 5. (see #8 for an alternative) Create two environment variables: HOME=C:\Code CVS_RSH=ssh HOME must point to the directory above your .ssh directory. On Win9x, this can be done in a batch file or autoexec.bat; e.g., set HOME=c:\Code set CVS_RSH=ssh Run the batch file, or reboot if you're using autoexec.bat. On NT or 2000, go to Control Panel | System | Environment and set them at either user or machine level. 6. If not done so, get a Sourceforge account and a project you can log in to. 7. Teach SSH about your project's home, by doing ssh -l $USERNAME $MYPROJECT.sourceforge.net where $USERNAME is your SourceForge login name and $MYPROJECT your SourceForge project name. You'll see Host "$MYPROJECT.sourceforge.net" added to the list of known hosts. and then Creating random seed file ~/.ssh/random_seed. This may take a while. After a while it will prompt for a password. Type your SourceForge password and hit ENTER. After some SourceForge msgs scroll by, you'll be left at a SourceForge shell prompt. Type exit and hit ENTER. Now you're back at the DOS prompt. 8. You will need either a lengthy command line or a batch file for each sourceforge project. I set cvsroot in a batch file in my 'c:\code' directory, and have one such file for each CVS project I use (about ten of them!): set CVSROOT=:ext:$USERNAME@cvs.$MYPROJECT.sourceforge.net:/cvsroot/$DIRNAME where $USERNAME and $MYPROJECT are again your SourceForge login and project names, and $DIRNAME is the top-level directory in the SourceForge CVS tree; a project can have several, but usually there is just one. Note: you can keep HOME and CVS_SSH out of your permanent environment (see #5) by adding those definitions to this batch file instead. 9. Execute this batch file. You can now go to C:\Code and do cvs -z7 checkout $MYPROJECT (z7 means 'compress network traffic', handy over dialup lines) 10. From now on, just use CVS normally, running this batch file first each time you bring up a DOS box you're going to use for CVS work. Note that you'll be asked for your password each time you enter a CVS command. I wouldn't survive without Karl Fogel's book "Open Source Development with CVS", Coriolis Press. The CVS reference material (about 225 printed pages!) from this book is available for free download from http://cvsbook.red-bean.com/ Footnote: for anonymous checkout, I think you just omit the 'my_user_name@' part from the CVSROOT variable. I hope this helps; let me know if people have any problems with the instructions. - Andy Robinson ReportLab From tim_one@email.msn.com Tue Jul 4 06:11:27 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 4 Jul 2000 01:11:27 -0400 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14689.28140.772442.865150@cj42289-a.reston1.va.home.com> Message-ID: [David Ascher] > Which reminds me that I'd really like the default python-mode.el to use > more 'strict' defaults than it currently does. If you can, please be explicit about what exactly in the pymode config you think needs to be changed. I can't tell from your complaint. > I don't know how, But we should be able to guess ? > but I routinely generate bad indentations w/ pymode, which I blame on bad > defaults in the elisp file. I can fix the config, of course, If so, being explicit should be a piece of cake ... > with enough work, but I believe it should be set to a more strict default. I never got bad indentation out of pymode when I was working on it, so I'm at a loss here. It can't prevent you from, e.g., inserting a literal tab character via C-q, if that's what you're doing. I assume you're not doing that, though. More info! From gstein@lyra.org Tue Jul 4 06:17:07 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 22:17:07 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: ; from DavidA@ActiveState.com on Mon, Jul 03, 2000 at 09:45:22PM -0700 References: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: <20000703221706.L29590@lyra.org> On Mon, Jul 03, 2000 at 09:45:22PM -0700, David Ascher wrote: > > This reminds us that most programmers aren't going to bother with > > the -tt option; it's something extra that they don't really need to > > get the job done. > > Which reminds me that I'd really like the default python-mode.el to use more > 'strict' defaults than it currently does. I don't know how, but I routinely > generate bad indentations w/ pymode, which I blame on bad defaults in the > elisp file. I can fix the config, of course, with enough work, but I > believe it should be set to a more strict default. Never seen this happen. Can you watch yourself and discover how you are generating these? I do admit that maybe pymode is generating them for me, too, but that I unconsciously compensate for the problem. I have certainly never consciously went "woah! bad pymode! bad pymode! stop that!" :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one@email.msn.com Tue Jul 4 06:23:29 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 4 Jul 2000 01:23:29 -0400 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > ... > There are two things that can be done: have distutils always use > -tt when compiling code that gets installed (using a child interpreter > if needed), and setting -tt as the default in the next Python > release. +1 from me. Hey, it's 2.0: we can break anything . > .... > Setting -tt to be the default, and not having a way to override it, +1 on that too. > would lead to some small code simplifications as well. and-also-cut-out-one-bogus-source-of-c.l.py-whitespace- flamewars-ly y'rs - tim From DavidA@ActiveState.com Tue Jul 4 06:49:32 2000 From: DavidA@ActiveState.com (David Ascher) Date: Mon, 3 Jul 2000 22:49:32 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: Message-ID: > If you can, please be explicit about what exactly in the pymode config you > think needs to be changed. I can't tell from your complaint. You can't channel me, eh? Loser. Ok, I'll keep an eye out and see if I can reproduce what I'm doing wrong. Sorry for just complaining and not giving people a chance to fix whatever it is I'm doing wrong =). --david From tim_one@email.msn.com Tue Jul 4 07:06:43 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 4 Jul 2000 02:06:43 -0400 Subject: [Python-Dev] Making -tt the default In-Reply-To: Message-ID: [Tim, fails to channel David] [David Ascher] > You can't channel me, eh? Loser. Oh, indeed yes! No more than two hours before, I failed Guido too, by failing to guess one of the passwords I needed to do something he commanded me to do. My myth of omniscience was much easier to maintain at a distance . > Ok, I'll keep an eye out and see if I can reproduce what I'm doing wrong. > Sorry for just complaining and not giving people a chance to fix > whatever it is I'm doing wrong =). It occurs to me that I had Emacs set up (in my own .emacs) to never ever use literal tab characters. That may go a way in explaining why pymode never generated ambiguous indentation for me! I suppose you can also get in trouble by editing *other* peoples' code containing a mix of tabs and spaces. So never do that either. heck-give-up-computers-and-get-an-honest-job-ly y'rs - tim From gstein@lyra.org Tue Jul 4 07:39:38 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 23:39:38 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: ; from tim_one@email.msn.com on Tue, Jul 04, 2000 at 02:06:43AM -0400 References: Message-ID: <20000703233938.N29590@lyra.org> On Tue, Jul 04, 2000 at 02:06:43AM -0400, Tim Peters wrote: >... > > Ok, I'll keep an eye out and see if I can reproduce what I'm doing wrong. > > Sorry for just complaining and not giving people a chance to fix > > whatever it is I'm doing wrong =). > > It occurs to me that I had Emacs set up (in my own .emacs) to never ever use > literal tab characters. That may go a way in explaining why pymode never > generated ambiguous indentation for me! > > I suppose you can also get in trouble by editing *other* peoples' code > containing a mix of tabs and spaces. So never do that either. I use the following tidbit of code in my .emacs: (add-hook 'python-mode-hook (lambda () (setq indent-tabs-mode nil) (setq py-indent-offset 2) (setq py-smart-indentation nil) (define-key py-mode-map "\e\C-h" 'backward-kill-word) )) The indent-tabs-mode is the key to disabling tab characters and using just spaces. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Tue Jul 4 08:35:02 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 4 Jul 2000 00:35:02 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.165,2.166 codecs.c,2.8,2.9 compile.c,2.112,2.113 modsupport.c,2.45 In-Reply-To: <200007040710.JAA16635@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Tue, Jul 04, 2000 at 09:10:08AM +0200 References: <200007032139.OAA29276@slayer.i.sourceforge.net> <200007040710.JAA16635@python.inrialpes.fr> Message-ID: <20000704003502.P29590@lyra.org> Placing it there means everybody and their brother will now have to include it. Personally, I'd rather have the number of headers in my compilation unit minimized. Take the argument of "put it into Python.h" to the extreme: why have any includes in any of the .c files? Put them ALL into Python.h so nobody has to bother with them in their .c files. :-) Cheers, -g On Tue, Jul 04, 2000 at 09:10:08AM +0200, Vladimir Marangozov wrote: > > This HAVE_LIMITS_H define spans over several files already. > Why not putting it in Python.h and cleanup the rest? > > Jack Jansen wrote: > > > > Update of /cvsroot/python/python/dist/src/Python > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv29235/Python > > > > Modified Files: > > bltinmodule.c codecs.c compile.c modsupport.c > > Log Message: > > Include limits.h if we have it. > > > > > > Index: bltinmodule.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v > > retrieving revision 2.165 > > retrieving revision 2.166 > > diff -C2 -r2.165 -r2.166 > > *** bltinmodule.c 2000/06/30 23:58:05 2.165 > > --- bltinmodule.c 2000/07/03 21:39:47 2.166 > > *************** > > *** 24,27 **** > > --- 24,30 ---- > > #include > > #endif > > + #ifdef HAVE_LIMITS_H > > + #include > > + #endif > > > > /* Forward */ > > > > Index: codecs.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Python/codecs.c,v > > retrieving revision 2.8 > > retrieving revision 2.9 > > diff -C2 -r2.8 -r2.9 > > *** codecs.c 2000/06/29 14:50:15 2.8 > > --- codecs.c 2000/07/03 21:39:47 2.9 > > *************** > > *** 11,14 **** > > --- 11,17 ---- > > #include "Python.h" > > #include > > + #ifdef HAVE_LIMITS_H > > + #include > > + #endif > > > > /* --- Globals ------------------------------------------------------------ */ > > > > Index: compile.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v > > retrieving revision 2.112 > > retrieving revision 2.113 > > diff -C2 -r2.112 -r2.113 > > *** compile.c 2000/06/30 23:58:06 2.112 > > --- compile.c 2000/07/03 21:39:47 2.113 > > *************** > > *** 34,37 **** > > --- 34,40 ---- > > > > #include > > + #ifdef HAVE_LIMITS_H > > + #include > > + #endif > > > > /* Three symbols from graminit.h are also defined in Python.h, with > > > > Index: modsupport.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Python/modsupport.c,v > > retrieving revision 2.45 > > retrieving revision 2.46 > > diff -C2 -r2.45 -r2.46 > > *** modsupport.c 2000/06/30 23:58:06 2.45 > > --- modsupport.c 2000/07/03 21:39:47 2.46 > > *************** > > *** 12,15 **** > > --- 12,18 ---- > > > > #include "Python.h" > > + #ifdef HAVE_LIMITS_H > > + #include > > + #endif > > > > #ifdef MPW /* MPW pushes 'extended' for float and double types with varargs */ > > > > > > _______________________________________________ > > Python-checkins mailing list > > Python-checkins@python.org > > http://www.python.org/mailman/listinfo/python-checkins > > > > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 > > _______________________________________________ > Python-checkins mailing list > Python-checkins@python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From fredrik@pythonware.com Tue Jul 4 10:18:40 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 11:18:40 +0200 Subject: [Python-Dev] Re: [ Patch #100719 ] Use '#!/usr/bin/env python' in scripts References: <20000703233938.N29590@lyra.org> Message-ID: <010101bfe598$d88381b0$0900a8c0@SPIFF> (just a heads up, not sure if SF was able to send out the notifications) This patch suggests changing /usr/local/bin/python to /usr/bin/env python in cgi.py and faqwiz.py. Note that both scripts are CGI scripts, and the FAQ has the following to say about that: http://www.python.org/doc/FAQ.html#4.63 Note -- *don't* do this for CGI scripts. The $PATH variable for CGI scripts is often very minimal, so you need to use the actual absolute pathname of the interpreter. -1, in other words (assuming that the FAQ is correct) From mal@lemburg.com Tue Jul 4 10:45:05 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 11:45:05 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! Message-ID: <3961B221.4F7552C3@lemburg.com> There was a discussion about adding a #define _XOPEN_SOURCE to the standard header files in Python (among other things to fix the warning in the timemodule.c on Linux). What happened to that idea ? I think it would be worthwhile to add a #ifdef __GNUC__ # define _GNU_SOURCE #endif to Python.h. This enables all features available for the gcc compiler including _XOPEN_SOURCE and fixes warnings related to missing prototypes. Thoughts ? Would this hurt anybody ? BTW, I'm +1 on adding a mylimits.h to Python.h too. mylimits.h would then either include the system's limits.h file or provide workarounds for platforms which don't have it. Then we could drop the #define INT_MAX which can be found in several Python C files. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Tue Jul 4 10:51:54 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 4 Jul 2000 02:51:54 -0700 Subject: [Python-Dev] Re: [ Patch #100719 ] Use '#!/usr/bin/env python' in scripts In-Reply-To: <010101bfe598$d88381b0$0900a8c0@SPIFF>; from fredrik@pythonware.com on Tue, Jul 04, 2000 at 11:18:40AM +0200 References: <20000703233938.N29590@lyra.org> <010101bfe598$d88381b0$0900a8c0@SPIFF> Message-ID: <20000704025154.W29590@lyra.org> On Tue, Jul 04, 2000 at 11:18:40AM +0200, Fredrik Lundh wrote: > (just a heads up, not sure if SF was able to send > out the notifications) > > This patch suggests changing /usr/local/bin/python to > /usr/bin/env python in cgi.py and faqwiz.py. Note > that both scripts are CGI scripts, and the FAQ has the > following to say about that: > > http://www.python.org/doc/FAQ.html#4.63 > > Note -- *don't* do this for CGI scripts. The $PATH > variable for CGI scripts is often very minimal, so > you need to use the actual absolute pathname of > the interpreter. > > -1, in other words (assuming that the FAQ is correct) I have observed the same behavior in my CGI scripts: you cannot rely on PATH, so the /usr/bin/env thing simply doesn't work. -1 also. Cheers, -g -- Greg Stein, http://www.lyra.org/ From sjoerd@oratrix.nl Tue Jul 4 10:55:41 2000 From: sjoerd@oratrix.nl (Sjoerd Mullender) Date: Tue, 04 Jul 2000 11:55:41 +0200 Subject: [Python-Dev] SRE incompatibility Message-ID: <20000704095542.8697B31047C@bireme.oratrix.nl> >>> regexp = '(([a-z]+):)?([a-z]+)$' >>> import re >>> re.match(regexp, 'smil').group(0,1,2,3) ('smil', None, 's', 'smil') >>> import pre >>> pre.match(regexp, 'smil').group(0,1,2,3) ('smil', None, None, 'smil') Needless to say, I am relying on the third value being None... (My regular expression was actually more like '(?:(?P[a-z]+):)?(?P[a-z]+)$' and I check for result.group('prefix')) -- Sjoerd Mullender From gstein@lyra.org Tue Jul 4 11:01:43 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 4 Jul 2000 03:01:43 -0700 Subject: [Python-Dev] suggest pyportable.h (was: Make _GNU_SOURCE default for gcc ?!) In-Reply-To: <3961B221.4F7552C3@lemburg.com>; from mal@lemburg.com on Tue, Jul 04, 2000 at 11:45:05AM +0200 References: <3961B221.4F7552C3@lemburg.com> Message-ID: <20000704030143.Y29590@lyra.org> On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: >... GNU_SOURCE ... Seems fine, and I can't see how it would hurt. +1 > BTW, I'm +1 on adding a mylimits.h to Python.h too. mylimits.h > would then either include the system's limits.h file or provide > workarounds for platforms which don't have it. Then we could drop > the #define INT_MAX which can be found in several Python C files. Euh... we should probably stop creating myfoo.h every time we want to replace some "foo" header. It would be much nicer to simply create "pyportable.h" and have it include the various pieces when available or to create suitable defaults for them. There would be a companion pyportable.c to define replacement functions. Continuing to litter the Python source area with a bunch of little files for all the edge cases on the planet... just doesn't make much sense to me. It starts to create too much confusion/complexity. Cheers, -g -- Greg Stein, http://www.lyra.org/ From fredrik@pythonware.com Tue Jul 4 11:08:50 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 12:08:50 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> Message-ID: <018a01bfe59f$da814950$0900a8c0@SPIFF> mal wrote: > There was a discussion about adding a #define _XOPEN_SOURCE > to the standard header files in Python (among other things to > fix the warning in the timemodule.c on Linux). > > What happened to that idea ? > > I think it would be worthwhile to add a > > #ifdef __GNUC__ > # define _GNU_SOURCE > #endif > > to Python.h. This enables all features available for the > gcc compiler including _XOPEN_SOURCE and fixes warnings > related to missing prototypes. > > Thoughts ? Would this hurt anybody ? what does "fixes warnings" mean? does it change the compiler's behaviour, or does it just make sure stuff are defined in the right files? how is this different from just a plain (and truly portable) #define _XOPEN_SOURCE? (the only concern I see here is that people on Linux platforms might start churning out code that depends on certain gcc-only features, without noticing...) +1 on _XOPEN_SOURCE +0 on _GNU_SOURCE From mal@lemburg.com Tue Jul 4 11:13:04 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 12:13:04 +0200 Subject: [Python-Dev] suggest pyportable.h (was: Make _GNU_SOURCE default for gcc ?!) References: <3961B221.4F7552C3@lemburg.com> <20000704030143.Y29590@lyra.org> Message-ID: <3961B8B0.96E010C3@lemburg.com> Greg Stein wrote: > > On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: > >... GNU_SOURCE ... > > Seems fine, and I can't see how it would hurt. > > +1 > > > BTW, I'm +1 on adding a mylimits.h to Python.h too. mylimits.h > > would then either include the system's limits.h file or provide > > workarounds for platforms which don't have it. Then we could drop > > the #define INT_MAX which can be found in several Python C files. > > Euh... we should probably stop creating myfoo.h every time we want to > replace some "foo" header. > > It would be much nicer to simply create "pyportable.h" and have it include > the various pieces when available or to create suitable defaults for them. > There would be a companion pyportable.c to define replacement functions. > > Continuing to litter the Python source area with a bunch of little files for > all the edge cases on the planet... just doesn't make much sense to me. It > starts to create too much confusion/complexity. Fine with me... we should probably make it contains all the different myfoo.h header files. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Tue Jul 4 11:43:23 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 12:43:23 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> Message-ID: <3961BFCB.DD7895E1@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > There was a discussion about adding a #define _XOPEN_SOURCE > > to the standard header files in Python (among other things to > > fix the warning in the timemodule.c on Linux). > > > > What happened to that idea ? > > > > I think it would be worthwhile to add a > > > > #ifdef __GNUC__ > > # define _GNU_SOURCE > > #endif > > > > to Python.h. This enables all features available for the > > gcc compiler including _XOPEN_SOURCE and fixes warnings > > related to missing prototypes. > > > > Thoughts ? Would this hurt anybody ? > > what does "fixes warnings" mean? does it change the compiler's > behaviour, or does it just make sure stuff are defined in the right > files? AFAIK, it only makes certain APIs available as prototype. Without the prototypes the usual response from the compiler are warning such as "converted integer to pointer without a cast" and somesuch (the default return value being "int"). > how is this different from just a plain (and truly portable) > #define _XOPEN_SOURCE? _XOPEN_SOURCE would also cure the warning in timemodule. > (the only concern I see here is that people on Linux platforms > might start churning out code that depends on certain gcc-only > features, without noticing...) > > +1 on _XOPEN_SOURCE > +0 on _GNU_SOURCE Ok, so how about adding #define _XOPEN_SOURCE to Python.h ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pf@artcom-gmbh.de Tue Jul 4 11:31:34 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Tue, 4 Jul 2000 12:31:34 +0200 (MEST) Subject: [Python-Dev] Re: [ Patch #100719 ] Use '#!/usr/bin/env python' in scripts In-Reply-To: <010101bfe598$d88381b0$0900a8c0@SPIFF> from Fredrik Lundh at "Jul 4, 2000 11:18:40 am" Message-ID: Hi, Fredrik Lundh : > (just a heads up, not sure if SF was able to send > out the notifications) > > This patch suggests changing /usr/local/bin/python to > /usr/bin/env python in cgi.py and faqwiz.py. Note > that both scripts are CGI scripts, and the FAQ has the > following to say about that: > > http://www.python.org/doc/FAQ.html#4.63 > > Note -- *don't* do this for CGI scripts. The $PATH > variable for CGI scripts is often very minimal, so > you need to use the actual absolute pathname of > the interpreter. > > -1, in other words (assuming that the FAQ is correct) I agree (now). I had submitted a similar patch at the beginning of this year, since such a patch is also part of the diff files usually applied on the major Linux distributions in order to build the Python binary RPMs on these Systems (SuSE Linux, RedHat). But I was conviced, that patching the official source tree would be a bad idea, since this will break these CGI scripts on most traditional Unices (e.g. Slowlaris), where people are unfortunately normally forced to build Python on their own and might forget (or are not allowed) to add /usr/local/bin to the default path. Since all major Linux distributions however come with a properly patched Python package anyway. Python living in /usr/bin on all those boxes is no argument. I believe applying such a patch has to wait until the proposed "world domination" of Linux has become real. ;-) So ---at least today--- the FAQ entry is ---still--- somewhat correct. However may be someone could add a note about prebuild Python RPMs to FAQ 4.63 in the mean time? I believe that otherwise Linux people will keep submitting patches like this one with increasing frequency. At least our customers throw out their Sun Sparc and SGI boxes and replace them with cheap Athlon or PIII boxes running SuSE or RedHat Linux with increasing velocity. Especially those in China, Singapur and Brasil. So in our customer base, Solaris and IRIX is dying out faster than I myself as a strong Linux proposer had believed even at the beginning of this year. YMMV since we are only a small company in a very special market segment. Regards, Peter From mal@lemburg.com Tue Jul 4 12:05:34 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 13:05:34 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> <3960BC32.CBBF3D6D@prescod.net> <3960C138.85D9B36A@lemburg.com> <00d201bfe510$573fce20$f2a6b5d4@hagrid> <3960DDA2.3C608267@prescod.net> Message-ID: <3961C4FE.D71A81B8@lemburg.com> Paul Prescod wrote: > > Fredrik Lundh wrote: > > > > ... > > > > exactly. this is the whole point: __repr__ is a debug tool, > > and therefore it must work in all platforms, for all strings. > > As a debugging tool, it would probably help rather than hurt things to > have repr be consistent on all platforms. If it is going to do a > conversion, I vote for unicode-escape everywhere. Ok, if you provide documentation for this, I'll give in on __repr__. In any case, __str__ should use the default encoding. > > on the other hand, if we can change repr/str, this is a non- > > issue. maybe someone could tell me exactly what code we'll > > break if we do that change? > > I agree that we want to move to a world where unicode strings and 8-bit > strings are accepted equally throughout Python. We do need some > information about whether moving there quickly will break code or not. > We need to know what Idle, PythonWin, Zope and other such environments > do with the results of repr. Anybody care to test this ? I think we should be careful about letting Unicode objects go loose in environments which were not designed to work with them. Let's first start with polishing up the standard lib to work with Unicode. It currently fails badly... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik@pythonware.com Tue Jul 4 12:07:53 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 13:07:53 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> Message-ID: <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> mal wrote: > Ok, so how about adding > > #define _XOPEN_SOURCE > > to Python.h ? digging through my old notes, it should be: /* force susv2 compatibility, where available */ #define _XOPEN_SOURCE 500 IIRC, Guido agreed that this was a good idea, so what are we waiting for? If it doesn't break the build on your Linux box, just go ahead and check it in! From mal@lemburg.com Tue Jul 4 12:10:42 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 13:10:42 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> Message-ID: <3961C632.CFADDC65@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > Ok, so how about adding > > > > #define _XOPEN_SOURCE > > > > to Python.h ? > > digging through my old notes, it should be: > > /* force susv2 compatibility, where available */ > #define _XOPEN_SOURCE 500 > > IIRC, Guido agreed that this was a good idea, so what > are we waiting for? If it doesn't break the build on your > Linux box, just go ahead and check it in! Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Tue Jul 4 12:49:03 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 13:49:03 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> <3961C632.CFADDC65@lemburg.com> Message-ID: <3961CF2F.113EC4F7@lemburg.com> "M.-A. Lemburg" wrote: > > Fredrik Lundh wrote: > > > > mal wrote: > > > > > Ok, so how about adding > > > > > > #define _XOPEN_SOURCE > > > > > > to Python.h ? > > > > digging through my old notes, it should be: > > > > /* force susv2 compatibility, where available */ > > #define _XOPEN_SOURCE 500 > > > > IIRC, Guido agreed that this was a good idea, so what > > are we waiting for? If it doesn't break the build on your > > Linux box, just go ahead and check it in! > > Ok. Hmm, with "#define _XOPEN_SOURCE 500" I get these (new) errors: ./posixmodule.c: In function `posix_tmpnam': ./posixmodule.c:3494: warning: assignment makes pointer from integer without a cast ./signalmodule.c:83: `SIGMAX' undeclared here (not in a function) ./signalmodule.c:83: size of array `Handlers' has non-integer type Both errors can only be fixed using __USE_MISC: __USE_MISC Define things common to BSD and System V Unix. It is defined when either _BSD_SOURCE or _SVID_SOURCE is defined... question is: which to use ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping@lfw.org Tue Jul 4 13:05:38 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Tue, 4 Jul 2000 05:05:38 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: Message-ID: On Mon, 3 Jul 2000, Ka-Ping Yee wrote: > It doesn't even have to be its own class of error, i suppose, > as long as it gets indicated some way ("SyntaxError: invalid > indentation" would be fine). It turns out that this should be quite easy. If it weren't past 4am i would be posting a patch instead of just a verbal suggestion right now -- but here's how to do it. For this kind of thing: > >>> if 1: > ... 3 > ... 4 > inconsistent dedent > File "", line 3 > 4 > ^ > SyntaxError: invalid token ...clearly it's trivial, as the case is already marked in the code (tokenizer.c). Instead of dumping the "inconsistent dedent" message to stderr, return E_INDENT. For this situation: > >>> 3 > File "", line 1 > 3 > ^ > SyntaxError: invalid syntax ...we have an INDENT where none is expected. This is also easy. At the end of PyParser_AddToken, we simply check to see if the token that caused the problem was indent-related: if (type == INDENT || type == DEDENT) return E_INDENT; Finally, the most interesting case: > >>> if 1: > ... 3 > File "", line 2 > 3 > ^ > SyntaxError: invalid syntax ...we expected an INDENT and didn't get one. This is a matter of checking the accelerator table to see what we were expecting. Also not really that hard: int expected; /* at the top of PyParser_AddToken */ ... if (s->s_lower == s->s_upper - 1) /* only one possibility */ { expected = ps->p_grammar->g_ll.ll_label[s->s_lower].lb_type; if (expected == INDENT || expected == DEDENT) return E_INDENT; } I like this last case best, as it means we can produce more useful messages for a variety of syntax errors! When there is a single particular kind of token expected, now Python can tell you what it is. After inserting this: /* Stuck, report syntax error */ fprintf(stderr, "Syntax error: unexpected %s", _PyParser_TokenNames[type]); if (s->s_lower == s->s_upper - 1) { fprintf(stderr, " (wanted %s)", _PyParser_TokenNames[labels[s->s_lower].lb_type]); } fprintf(stderr, "\n"); ... i played around a bit: >>> (3,4] Syntax error: unexpected RSQB (wanted RPAR) File "", line 1 (3,4] ^ SyntaxError: invalid syntax >>> 3.. Syntax error: unexpected NEWLINE (wanted NAME) File "", line 1 3.. ^ SyntaxError: invalid syntax >>> 3.) Syntax error: unexpected RPAR File "", line 1 3.) ^ SyntaxError: invalid syntax >>> a^^ Syntax error: unexpected CIRCUMFLEX File "", line 1 a^^ ^ SyntaxError: invalid syntax >>> if 3: ... 3 Syntax error: unexpected NUMBER (wanted INDENT) File "", line 2 3 ^ SyntaxError: invalid syntax >>> 4,, Syntax error: unexpected COMMA File "", line 1 4,, ^ SyntaxError: invalid syntax >>> [3,) Syntax error: unexpected RPAR (wanted RSQB) File "", line 1 [3,) ^ SyntaxError: invalid syntax >>> if a == 3 and Syntax error: unexpected NEWLINE File "", line 1 if a == 3 and ^ SyntaxError: invalid syntax >>> if a = 3: Syntax error: unexpected EQUAL (wanted COLON) File "", line 1 if a = 3: ^ SyntaxError: invalid syntax This isn't going to cover all cases, but i thought it was pretty cool. So, in summary: - Producing E_INDENT errors is easy, and should require just three small changes (one in tokenizer.c and two in parser.c, specifically PyParser_AddToken) - We can get some info we need to produce better syntax error messages in general, but this requires a little more thought about how to pass the info back out of the parser to pythonrun.c (err_input). -- ?!ng "This code is better ihan any code that doesn't work has any right to be." -- Roger Gregory, on Xanadu From fredrik@pythonware.com Tue Jul 4 13:40:09 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 14:40:09 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> <3961C632.CFADDC65@lemburg.com> <3961CF2F.113EC4F7@lemburg.com> Message-ID: <002a01bfe5b4$fdeb1820$0900a8c0@SPIFF> mal wrote: > Hmm, with "#define _XOPEN_SOURCE 500" I get these (new) errors: > > ./posixmodule.c: In function `posix_tmpnam': > ./posixmodule.c:3494: warning: assignment makes pointer from integer without a cast looks like a bug in the header files; SUSv2 says that this should be defined in stdio.h... > ./signalmodule.c:83: `SIGMAX' undeclared here (not in a function) > ./signalmodule.c:83: size of array `Handlers' has non-integer type but this one is stranger; as far as I can tell, SIGMAX is not part of SUSv2 at all. and what's worse, I cannot find any suitable replacement. does it work better if you just define _XOPEN_SOURCE, without any specific value? or maybe you should just add _GNU_SOURCE to make it work on your box. I promise to play with this on our Unix boxes, but not today... From mal@lemburg.com Tue Jul 4 15:03:37 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 16:03:37 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> <3961C632.CFADDC65@lemburg.com> <3961CF2F.113EC4F7@lemburg.com> <002a01bfe5b4$fdeb1820$0900a8c0@SPIFF> Message-ID: <3961EEB9.413FF4FF@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Hmm, with "#define _XOPEN_SOURCE 500" I get these (new) errors: > > > > ./posixmodule.c: In function `posix_tmpnam': > > ./posixmodule.c:3494: warning: assignment makes pointer from integer > without a cast > > looks like a bug in the header files; SUSv2 says that > this should be defined in stdio.h... The header files on my machine only define tmpnam_r in case __USE_MISC is true. The latter is defined for either BSD or SysV compatibility, yet not by _XOPEN_SOURCE. > > ./signalmodule.c:83: `SIGMAX' undeclared here (not in a function) > > ./signalmodule.c:83: size of array `Handlers' has non-integer type > > but this one is stranger; as far as I can tell, SIGMAX is not > part of SUSv2 at all. and what's worse, I cannot find any > suitable replacement. I guess we should patch signalmodule.c to fall back to _NSIG instead of trying SIGMAX. I'll check in a fix later today. > does it work better if you just define _XOPEN_SOURCE, without any > specific value? Same errors. > or maybe you should just add _GNU_SOURCE to make > it work on your box. I promise to play with this on our Unix boxes, > but not today... Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Tue Jul 4 15:13:47 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 4 Jul 2000 10:13:47 -0400 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <3961B221.4F7552C3@lemburg.com>; from mal@lemburg.com on Tue, Jul 04, 2000 at 11:45:05AM +0200 References: <3961B221.4F7552C3@lemburg.com> Message-ID: <20000704101347.A14382@newcnri.cnri.reston.va.us> On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: >#ifdef __GNUC__ ># define _GNU_SOURCE >#endif Doesn't it make more sense to define _GNU_SOURCE only if the C library is glibc? You could be using GCC on Solaris with Sun's libc, for example, where _GNU_SOURCE would be meaningless. Probably you have to define _XOPEN_SOURCE everywhere, and _GNU_SOURCE if the libc is glibc. --amk From fredrik@pythonware.com Tue Jul 4 15:22:34 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 16:22:34 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> <3961C632.CFADDC65@lemburg.com> <3961CF2F.113EC4F7@lemburg.com> <002a01bfe5b4$fdeb1820$0900a8c0@SPIFF> <3961EEB9.413FF4FF@lemburg.com> Message-ID: <002a01bfe5c3$4c5ed510$0900a8c0@SPIFF> mal wrote: > > looks like a bug in the header files; SUSv2 says that > > this should be defined in stdio.h... > > The header files on my machine only define tmpnam_r in > case __USE_MISC is true. The latter is defined for either > BSD or SysV compatibility, yet not by _XOPEN_SOURCE. oh, sorry. looks like I was off by two here, and thought you were talking about tmpnam. fwiw, SUSv2 seems to say that tmpnam is thread safe, if used in the right way. there is no tmpnam_r in SUSv2. I'll dig into this later (maybe they've added things in SUSv3). > > > ./signalmodule.c:83: `SIGMAX' undeclared here (not in a function) > > > ./signalmodule.c:83: size of array `Handlers' has non-integer type > > > > but this one is stranger; as far as I can tell, SIGMAX is not > > part of SUSv2 at all. and what's worse, I cannot find any > > suitable replacement. > > I guess we should patch signalmodule.c to fall back to _NSIG > instead of trying SIGMAX. sounds reasonable (or rather, I haven't got a clue, so I'll have to trust you on this one ;-) cheers /F From mal@lemburg.com Tue Jul 4 15:22:50 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 16:22:50 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <20000704101347.A14382@newcnri.cnri.reston.va.us> Message-ID: <3961F33A.28E2B980@lemburg.com> Andrew Kuchling wrote: > > On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: > >#ifdef __GNUC__ > ># define _GNU_SOURCE > >#endif > > Doesn't it make more sense to define _GNU_SOURCE only if the C library > is glibc? You could be using GCC on Solaris with Sun's libc, for > example, where _GNU_SOURCE would be meaningless. Probably you have to > define _XOPEN_SOURCE everywhere, and _GNU_SOURCE if the libc is glibc. Good point... it should probably read: #ifdef __GLIBC__ # define _GNU_SOURCE #else # define _XOPEN_SOURCE 500 #endif I'll do some more testing later today. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@beopen.com Tue Jul 4 18:32:41 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 13:32:41 -0400 (EDT) Subject: [Python-Dev] Making -tt the default In-Reply-To: References: Message-ID: <14690.8121.869315.508174@cj42289-a.reston1.va.home.com> Tim Peters writes: > It occurs to me that I had Emacs set up (in my own .emacs) to never ever use > literal tab characters. That may go a way in explaining why pymode never > generated ambiguous indentation for me! I have: (setq-default indent-tabs-mode nil) Perhaps python-mode should include (setq indent-tabs-mode nil) just for python-mode buffers, if it doesn't already. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Tue Jul 4 18:40:56 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 13:40:56 -0400 (EDT) Subject: [Python-Dev] Re: [ Patch #100719 ] Use '#!/usr/bin/env python' in scripts In-Reply-To: <010101bfe598$d88381b0$0900a8c0@SPIFF> References: <20000703233938.N29590@lyra.org> <010101bfe598$d88381b0$0900a8c0@SPIFF> Message-ID: <14690.8616.285301.679626@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > This patch suggests changing /usr/local/bin/python to > /usr/bin/env python in cgi.py and faqwiz.py. Note > that both scripts are CGI scripts, and the FAQ has the > following to say about that: > > http://www.python.org/doc/FAQ.html#4.63 > > Note -- *don't* do this for CGI scripts. The $PATH > variable for CGI scripts is often very minimal, so > you need to use the actual absolute pathname of > the interpreter. > > -1, in other words (assuming that the FAQ is correct) The FAQ is correct. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal@lemburg.com Tue Jul 4 18:45:17 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 19:45:17 +0200 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... Message-ID: <396222AD.8312C32@lemburg.com> While fiddling around with the _GNU_SOURCE define I found that there are several warnings left in the current CVS version which should be removed, I guess. Here's the list I get from compiling the tree using -Wall grouped by C file: bufferobject.c: In function `PyBuffer_New': bufferobject.c:174: warning: value computed is not used classobject.c: In function `instance_dealloc': classobject.c:526: warning: unused variable `_Py_RefTotal' object.c: In function `_PyTrash_deposit_object': object.c:1172: warning: unused variable `hold' object.c:1171: warning: `typecode' might be used uninitialized in this function ceval.c: In function `eval_code2': ceval.c:333: warning: `opcode' might be used uninitialized in this function ceval.c:334: warning: `oparg' might be used uninitialized in this function pystate.c: In function `PyInterpreterState_New': pystate.c:45: warning: value computed is not used ./gcmodule.c: In function `debug_cycle': ./gcmodule.c:295: warning: unsigned int format, long unsigned int arg (arg 5) ./gcmodule.c: In function `collect': ./gcmodule.c:374: warning: int format, long int arg (arg 3) ./gcmodule.c:374: warning: int format, long int arg (arg 4) ./gcmodule.c:374: warning: int format, long int arg (arg 5) ./gcmodule.c:438: warning: int format, long int arg (arg 3) ./gcmodule.c:438: warning: int format, long int arg (arg 4) ./gcmodule.c: In function `collect_generations': ./gcmodule.c:458: warning: `n' might be used uninitialized in this function ./pypcre.c: In function `compile_branch': ./pypcre.c:1222: warning: `c' might be used uninitialized in this function ./pypcre.c: In function `pcre_exec': ./pypcre.c:4524: warning: variable `start_bits' might be clobbered by `longjmp' or `vfork' ./pypcre.c:4525: warning: variable `start_match' might be clobbered by `longjmp' or `vfork' ./posixmodule.c: At top level: ./posixmodule.c:496: warning: `posix_strint' defined but not used _sre.c: In function `pattern_match': _sre.c:819: warning: `mark1' might be used uninitialized in this function _sre.c:819: warning: `mark0' might be used uninitialized in this function ./_sre.c:819: warning: `mark1' might be used uninitialized in this function ./_sre.c:819: warning: `mark0' might be used uninitialized in this function _sre.c: In function `pattern_search': _sre.c:985: warning: `prefix_len' might be used uninitialized in this function _sre.c:819: warning: `mark0' might be used uninitialized in this function [...many more of these... all referencing line 819] In file included from ./mmapmodule.c:24: ../Include/Python.h:18: warning: `_GNU_SOURCE' redefined ./mmapmodule.c:21: warning: this is the location of the previous definition [...looks like someone needed _GNU_SOURCE too ;-)...] ./parsermodule.c: In function `validate_arglist': ./parsermodule.c:2089: warning: `ok' might be used uninitialized in this function -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Tue Jul 4 18:48:35 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 19:48:35 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <20000704101347.A14382@newcnri.cnri.reston.va.us> <3961F33A.28E2B980@lemburg.com> Message-ID: <39622373.7C65C72C@lemburg.com> "M.-A. Lemburg" wrote: > > Andrew Kuchling wrote: > > > > On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: > > >#ifdef __GNUC__ > > ># define _GNU_SOURCE > > >#endif > > > > Doesn't it make more sense to define _GNU_SOURCE only if the C library > > is glibc? You could be using GCC on Solaris with Sun's libc, for > > example, where _GNU_SOURCE would be meaningless. Probably you have to > > define _XOPEN_SOURCE everywhere, and _GNU_SOURCE if the libc is glibc. > > Good point... it should probably read: > > #ifdef __GLIBC__ > # define _GNU_SOURCE > #else > # define _XOPEN_SOURCE 500 > #endif > > I'll do some more testing later today. The testing showed that the above switch doesn't work: __GLIBC__ is defined in features.h which is included by all standard C lib headers in glibc. The following finally made the warnings in timemodule.c go away: /* Enable compiler features including SUSv2 compatibility; switching on C lib defines doesn't work here, because the symbols haven't necessarily been defined yet. */ #define _GNU_SOURCE 1 #define _XOPEN_SOURCE 500 Defining _GNU_SOURCE on non glibc platforms shouldn't hurt, so I simply dropped the switch. Should I check this in ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@beopen.com Tue Jul 4 18:53:15 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 13:53:15 -0400 (EDT) Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <018a01bfe59f$da814950$0900a8c0@SPIFF> References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> Message-ID: <14690.9355.219446.754205@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > what does "fixes warnings" mean? does it change the compiler's > behaviour, or does it just make sure stuff are defined in the right > files? There's a strptime() declaration about halfway down the file in an #if 0 section; this has to be enabled on Linux to get rid of a warning. Defining _GNU_SOURCE at the top of the file also gets rid of the warning, but defining _XOPEN_SOURCE doesn't; in that case I get more: gcc -fpic -g -O2 -I../../Modules/../Include -I.. -DHAVE_CONFIG_H -c ../../Modules/timemodule.c ../../Modules/timemodule.c: In function `inittime': ../../Modules/timemodule.c:652: structure has no member named `tm_gmtoff' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:657: structure has no member named `tm_gmtoff' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' make[1]: *** [timemodule.o] Error 1 make: *** [sharedmods] Error 2 > how is this different from just a plain (and truly portable) > #define _XOPEN_SOURCE? A valid concern, but most of _GNU_SOURCE is just shorthand to make sure just about every non-conflicting declaration is made, so that differences between other platforms "standard" declarations aren't as much of a problem. But I'm not advocating it for general use; the sources are already working well aside from this one warning in timemodule.c; defining _GNU_SOURCE here is sufficient as far as I can tell. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From DavidA@ActiveState.com Tue Jul 4 18:59:25 2000 From: DavidA@ActiveState.com (David Ascher) Date: Tue, 4 Jul 2000 10:59:25 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14690.8121.869315.508174@cj42289-a.reston1.va.home.com> Message-ID: > Tim Peters writes: > > It occurs to me that I had Emacs set up (in my own .emacs) to > never ever use > > literal tab characters. That may go a way in explaining why > pymode never > > generated ambiguous indentation for me! > > I have: > > (setq-default indent-tabs-mode nil) > > Perhaps python-mode should include > > (setq indent-tabs-mode nil) > > just for python-mode buffers, if it doesn't already. +1 --david From fdrake@beopen.com Tue Jul 4 19:25:28 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 14:25:28 -0400 (EDT) Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <39622373.7C65C72C@lemburg.com> References: <3961B221.4F7552C3@lemburg.com> <20000704101347.A14382@newcnri.cnri.reston.va.us> <3961F33A.28E2B980@lemburg.com> <39622373.7C65C72C@lemburg.com> Message-ID: <14690.11288.36303.553802@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > /* Enable compiler features including SUSv2 compatibility; switching > on C lib defines doesn't work here, because the symbols haven't > necessarily been defined yet. */ > #define _GNU_SOURCE 1 > #define _XOPEN_SOURCE 500 ... > Should I check this in ? This works for me; I presume you putting this before all other #includes? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Tue Jul 4 19:43:47 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 14:43:47 -0400 (EDT) Subject: [Python-Dev] Making -tt the default In-Reply-To: References: <14690.8121.869315.508174@cj42289-a.reston1.va.home.com> Message-ID: <14690.12387.705074.991760@cj42289-a.reston1.va.home.com> David Ascher writes: > +1 I've submitted patch #100729 on SourceForge and assigned it to Barry. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Tue Jul 4 19:50:57 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 14:50:57 -0400 (EDT) Subject: [Python-Dev] Making the CVS tree pass the -Wall test... In-Reply-To: <396222AD.8312C32@lemburg.com> References: <396222AD.8312C32@lemburg.com> Message-ID: <14690.12817.194151.569623@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Here's the list I get from compiling the tree using -Wall > grouped by C file: Feel free to fix these! (I agree they should be done, but I need to pull away from email and these little proto-buglets so I can actually get done some of the things on my list. ;) > ./parsermodule.c: In function `validate_arglist': > ./parsermodule.c:2089: warning: `ok' might be used uninitialized in this function Ok, I've fixed this one, since it's probably my fault. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal@lemburg.com Tue Jul 4 20:00:38 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 21:00:38 +0200 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... References: <396222AD.8312C32@lemburg.com> <14690.12817.194151.569623@cj42289-a.reston1.va.home.com> Message-ID: <39623456.E8B0B833@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > Here's the list I get from compiling the tree using -Wall > > grouped by C file: > > Feel free to fix these! (I agree they should be done, but I need to > pull away from email and these little proto-buglets so I can actually > get done some of the things on my list. ;) Same here ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Tue Jul 4 20:05:01 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 21:05:01 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <20000704101347.A14382@newcnri.cnri.reston.va.us> <3961F33A.28E2B980@lemburg.com> <39622373.7C65C72C@lemburg.com> <14690.11288.36303.553802@cj42289-a.reston1.va.home.com> Message-ID: <3962355D.7FD7429@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > /* Enable compiler features including SUSv2 compatibility; switching > > on C lib defines doesn't work here, because the symbols haven't > > necessarily been defined yet. */ > > #define _GNU_SOURCE 1 > > #define _XOPEN_SOURCE 500 > ... > > Should I check this in ? > > This works for me; I presume you putting this before all other > #includes? Right. I've added some ifdefs just to make sure. This is how my Python.h file looks now: ... See the file "Misc/COPYRIGHT" for information on usage and redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES. ******************************************************************/ /* Enable compiler features including SUSv2 compatibility; switching on C lib defines doesn't work here, because the symbols haven't necessarily been defined yet. */ #ifndef _GNU_SOURCE # define _GNU_SOURCE 1 #endif #ifndef _XOPEN_SOURCE # define _XOPEN_SOURCE 500 #endif /* Include nearly all Python header files */ #include "patchlevel.h" #include "config.h" ... Other opinions ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Tue Jul 4 21:58:46 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 22:58:46 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <20000704200730.617431D0CE@dinsdale.python.org> Message-ID: <39625006.A0F7B0C0@lemburg.com> billtut@microsoft.com wrote: > > Full_Name: Bill Tutt > Version: CVS > OS: NT > Submission from: tide70.microsoft.com (131.107.3.70) > > u'\ud800' causes the interpreter to crash > example: > print u'\ud800' > What happens: > The code failes to compile because while adding the constant, the unicode_hash > function is called which for some reason requires the UTF-8 string format. The reasoning at the time was that dictionaries should accept Unicode objects as keys which match their string equivalents as the same key, e.g. 'abc' works just as well as u'abc'. UTF-8 was the default encoding back then. I'm not sure how to fix the hash value given the new strategy w/r to the default encoding... According to the docs, objects comparing equal should have the same hash value, yet this would require the hash value to be calculated using the default encoding and that would not only cause huge performance problems, but could effectively render Unicode useless, because not all default encodings are lossless (ok, one could work around this by falling back to some other way of calculating the hash value in case the conversion fails). Looks like we have a problem here :-/ > The conversion to UTF-8 fails (completly bogus), the compiler only notes that > compilation failed, and cleared the stored exception info. > > When compilatino finishes it remembered that it failed, and returns. > The interpreter then proceeds to crash in PyErr_NormalizeException() because the > UTF-8 conversion exception info isn't there anymore. > > Suggested fix: > Changing the UTF-8 conversion code to emit 4 bytes for surrogate characters. > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping@lfw.org Tue Jul 4 22:40:21 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Tue, 4 Jul 2000 14:40:21 -0700 (PDT) Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) In-Reply-To: <39625006.A0F7B0C0@lemburg.com> Message-ID: On Tue, 4 Jul 2000, M.-A. Lemburg wrote: > > The reasoning at the time was that dictionaries should accept > Unicode objects as keys which match their string equivalents > as the same key, e.g. 'abc' works just as well as u'abc'. [...] > According to the docs, objects comparing equal should have the > same hash value, yet this would require the hash value to be > calculated using the default encoding and that > would not only cause huge performance problems, but could > effectively render Unicode useless, Given the new 7-bit-ASCII-as-default-encoding-for-8-bit-strings convention, shouldn't just hashing the character values work fine? That is, hash('abc') should == hash(u'abc'), no conversion required. -- ?!ng From jack@oratrix.nl Tue Jul 4 22:50:02 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 04 Jul 2000 23:50:02 +0200 Subject: [Python-Dev] PyArg_ParseTuple and 16 bit bitpatterns Message-ID: <20000704215007.957B2E2673@oratrix.oratrix.nl> I've adapted PyArg_ParseTuple (and Py_BuildValue) to understand the H format specifier, which is meant for 16-bit bitpatterns. (in case you didn't follow the discussion last month: the old lowercase h now checks values to be in the range -32768..32767, so constants like 0x8000 are not acceptable anymore). I haven't added an I and L specifier, because (surprise, surprise:-) for 32-bit integers 0x80000000 turns out to be a legal value, unlike for their poor 16-bit brethren. I've currently implemented H as meaning unsigned (i.e. 0..0xffff), but on second thoughts I think allowing -32768..0xffff might be better: there's probably lots of code out there that passes -1 when all 16 flag bits should be set. Please let me know if you have strong opinions on either meaning before I check this in. Note that I'll only adapt PyArg_ParseTuple and the gazzilion mac-specific occurrences of "h" where a 16-bit pattern is needed. I've done only a very cursory check of other occurences of "h", but someone else will have to pick that up if they feel like. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From jack@oratrix.nl Tue Jul 4 22:53:36 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 04 Jul 2000 23:53:36 +0200 Subject: [Python-Dev] Sre tests failing Message-ID: <20000704215342.18235E2673@oratrix.oratrix.nl> Since this weekend lots of test.autotest tests fail on my Mac because sre seems to lack lots of stuff that re did have. And as /F has been rather quiet these last 24 hours: is this a problem only I have and i should investigate, or should I quietly wait for it to be fixed shortly? Failing tests include test_sre, test_xmllib, test_strftime and test_tokenize, to name a few. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From martin@loewis.home.cs.tu-berlin.de Tue Jul 4 23:12:03 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed, 5 Jul 2000 00:12:03 +0200 Subject: [Python-Dev] Copyright notice Message-ID: <200007042212.AAA01334@loewis.home.cs.tu-berlin.de> > I think I recall this was a convention that the GNU folks claim is > required from a legal standpoint. The GPL requires such a message, specifically 2c) c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) So if you modify gdb, you'll have to update the copyright notice it prints. Please note the exception: some programs (e.g. bash) don't "normally" print a message, so you don't have to add one. In any case, I believe this is just a GPL requirement - for Python, you could have it behave in any way you please. > On the other hand, why does it bother you? I don't bother too much, and I hadn't said anything if I didn't expect the message to change anyway. The interactive prompt of Python 2 will be shown on page 1 of the next print of my Python book, and I did not mean to go into Python's history until page 14 :-) Regards, Martin From billtut@microsoft.com Tue Jul 4 23:39:26 2000 From: billtut@microsoft.com (Bill Tutt) Date: Tue, 4 Jul 2000 15:39:26 -0700 Subject: [Python-Dev] RE: \ud800 crashes interpreter (PR#384) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD269@RED-MSG-50> > MAL wrotw: >> Bill wrote: >> u'\ud800' causes the interpreter to crash >> example: >> print u'\ud800' >> What happens: >> The code failes to compile because while adding the constant, the unicode_hash >> function is called which for some reason requires the UTF-8 string format. > The reasoning at the time was that dictionaries should accept > Unicode objects as keys which match their string equivalents > as the same key, e.g. 'abc' works just as well as u'abc'. > UTF-8 was the default encoding back then. I'm not sure how > to fix the hash value given the new strategy w/r to the > default encoding... > According to the docs, objects comparing equal should have the > same hash value, yet this would require the hash value to be > calculated using the default encoding and that > would not only cause huge performance problems, but could > effectively render Unicode useless, because not all default > encodings are lossless (ok, one could work around this by > falling back to some other way of calculating the hash > value in case the conversion fails). Yeah, yeah, yeah. I know all that, just never liked it. :) The current problem is that the UTF-8 can't round trip surrogate characters atm. This is easy to fix, so I'm doing a patch to fix this oversight, unless you beat me to it. Anything else is slightly more annoying to fix. Bill From Fredrik Lundh" Message-ID: <001e01bfe611$c60df820$f2a6b5d4@hagrid> > Since this weekend lots of test.autotest tests fail on my Mac because > sre seems to lack lots of stuff that re did have. And as /F has been > rather quiet these last 24 hours: is this a problem only I have and i > should investigate, or should I quietly wait for it to be fixed > shortly? >=20 > Failing tests include test_sre, test_xmllib, test_strftime and > test_tokenize, to name a few. test_sre.py should work (if you compare the output against the output/test_sre file, that is -- see the repository copy of that file for a list of things that are expected to break...) I think test_tokenize should work too... test_xmllib appears to be broken on my box (possibly caused by SRE). test_strftime complains about tons of stuff on my Win95 box; dunno if it's done that way on purpose... From Fredrik Lundh" Message-ID: <002601bfe612$06e90ec0$f2a6b5d4@hagrid> sjoerd wrote: > >>> re.match(regexp, 'smil').group(0,1,2,3) > ('smil', None, 's', 'smil') > >>> import pre > >>> pre.match(regexp, 'smil').group(0,1,2,3) > ('smil', None, None, 'smil') >=20 > Needless to say, I am relying on the third value being None... I've confirmed this (last night's fix should have solved this, but it didn't). I'll post patches as soon as I have them... From trentm@activestate.com Wed Jul 5 00:42:58 2000 From: trentm@activestate.com (Trent Mick) Date: Tue, 4 Jul 2000 16:42:58 -0700 Subject: [Python-Dev] PyArg_ParseTuple and 16 bit bitpatterns In-Reply-To: <20000704215007.957B2E2673@oratrix.oratrix.nl> References: <20000704215007.957B2E2673@oratrix.oratrix.nl> Message-ID: <20000704164258.B5972@activestate.com> Hi Jack, I am your evil man for this one (but then you already knew that). On Tue, Jul 04, 2000 at 11:50:02PM +0200, Jack Jansen wrote: > I've adapted PyArg_ParseTuple (and Py_BuildValue) to understand the H > format specifier, which is meant for 16-bit bitpatterns. (in case you > didn't follow the discussion last month: the old lowercase h now > checks values to be in the range -32768..32767, so constants like > 0x8000 are not acceptable anymore). I think that the Right Answer is: b = signed byte B = unsigned byte h = signed short H = unsigned short i = signed int I = unsigned int l = signed long L = unsigned long Before my patch we had (no range checking was done so signed vs. unsigned made no difference): b = byte h = short i = int l = long L = LONG_LONG After my patch (i.e. now) we have: b = unsigned byte h = signed short i = signed int l = signed long L = signed LONG_LONG Notes on that: - Choosing signed or unsigned for each was based on the common case (or presuming what the common case was). I.e. unsigned bytes are more common than signed bytes. - unsigned byte is 'b' and not (my ideal) 'B', for backward compatibility reasons - LONG_LONG as 'L' really sucks because that is the blocker to PyArg_ParseTuple nirvana (my first list). It should be 'q' and 'Q' for Quad or something like that. Your patch is adding (right?): H = unsigned short Aside: Now that it will be called 2.0 would we maybe want to go for the Right Answer. I suspect that a *lot* more people would complain of breakage with the use of 'L' changing to 'Q', and that I am asking for a lynching. > > I haven't added an I and L specifier, because (surprise, surprise:-) > for 32-bit integers 0x80000000 turns out to be a legal value, unlike > for their poor 16-bit brethren. I can't see how 'I' allows 0x80000000 (unless, of course, sizeof(int) > 4 on your machine) because the 'I' formatter is not in PyArg_ParseTuple. Yes, 'L' will probably accept 0x80000000 because LONG_LONG is probably 64-bits wide on your machine hence. > > I've currently implemented H as meaning unsigned (i.e. 0..0xffff), but I woudl suggest allowing [0, USHRT_MAX]. Should be defined in limits.h (guessing), I think. > on second thoughts I think allowing -32768..0xffff might be better: > there's probably lots of code out there that passes -1 when all 16 > flag bits should be set. Please let me know if you have strong I think that uses of -1 should use either USHRT_MAX or (unsigned short)-1. > opinions on either meaning before I check this in. > > Note that I'll only adapt PyArg_ParseTuple and the > gazzilion mac-specific occurrences of "h" where a 16-bit pattern is > needed. I've done only a very cursory check of other occurences of > "h", but someone else will have to pick that up if they feel like. > I am sorry to have been the cause of work for you. I just think that the 'security' offered by bounds checking all values converted by PyArg_ParseTuple is important. Trent -- Trent Mick trentm@activestate.com From tim_one@email.msn.com Wed Jul 5 06:51:07 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 01:51:07 -0400 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... In-Reply-To: <396222AD.8312C32@lemburg.com> Message-ID: [M.-A. Lemburg] > While fiddling around with the _GNU_SOURCE define I found > that there are several warnings left in the current CVS > version which should be removed, I guess. > > Here's the list I get from compiling the tree using -Wall > grouped by C file: So long as any warnings remain, would you please repost the list from time to time? There's no need to group them by file. > ./pypcre.c:4524: warning: variable `start_bits' might be > clobbered by `longjmp' or `vfork' > ./pypcre.c:4525: warning: variable `start_match' might be > clobbered by `longjmp' or `vfork' These are often a PITA to fix: gcc does brain-dead flow analysis, and this particular msg is almost always bogus as a result. There are several open bugs filed against gcc on this (I know because one of them is mine ). The others look straightforward to fix (on a first scan). From martin@loewis.home.cs.tu-berlin.de Wed Jul 5 07:50:54 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed, 5 Jul 2000 08:50:54 +0200 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... Message-ID: <200007050650.IAA00972@loewis.home.cs.tu-berlin.de> >> ./pypcre.c:4524: warning: variable `start_bits' might be >> clobbered by `longjmp' or `vfork' >> ./pypcre.c:4525: warning: variable `start_match' might be >> clobbered by `longjmp' or `vfork' > These are often a PITA to fix: gcc does brain-dead flow analysis, and this > particular msg is almost always bogus as a result. There are several open > bugs filed against gcc on this (I know because one of them is mine ). > The others look straightforward to fix (on a first scan). At least for start_match, what exactly is bogus about this message? setjmp is invoked in line 4691 of pypcre, and start_match is modified in line 4737, at the end of the while loop containing the setjmp call. If somebody would invoke longjmp on the jmp_buf after start_match is modified, it would have an indeterminate value, according to 7.13.2.1p3 of C99. Likewise for start_bits, as it may also be modified after setjmp() has been called, since it appears in the same loop. I admit that there wouldn't be too many calls that could actually invoke longjmp() before the next invocation of setjmp, except perhaps for pchars(), but gcc is not supposed to determine potential callers of longjmp: The compiler sees only the calls to `setjmp'. It cannot know where `longjmp' will be called; in fact, a signal handler could call it at any point in the code. As a result, you may get a warning even when there is in fact no problem because `longjmp' cannot in fact be called at the place which would cause a problem. So while I'd admit that gcc "does brain-dead flow analysis", I think this particular msg is not bogus in this specific case. It's more often than not that gcc users fail to understand this message, though. Regards, Martin From rob@hooft.net Wed Jul 5 08:02:53 2000 From: rob@hooft.net (Rob W. W. Hooft) Date: Wed, 5 Jul 2000 09:02:53 +0200 (CEST) Subject: [Python-Dev] Spelling check: more typos Message-ID: <14690.56733.627266.907044@temoleh.chem.uu.nl> I got some positive comments on my previous load of spelling checks, so I spent another evening using some ispell, some spell, and some special python code to look for more spelling errors in the python source code. Base was the CVS on 2 July. There are a few more 'problematic' cases in here: First: American vs. British spelling. Since most text is in American spelling, I "corrected" some words from the British spelling to the American. I haven't done that with everything, especially in modules where British-spelling variable names are used. Then 2 points on distutils: - the word "licence" is used throughout, and "license" is introduced as alternative. The other way around looks more natural to me. - the term "anal retentives" should probably be replaced before 2.0 Furthermore: there is still a lib/stdwin manual. Shouldn't that be removed too? Is "s's" as in "the process's exit code" valid English? I seem to remember that for words in s, the final s should be dropped. Is it "Lance Ellinghouse" or "Ellinghaus"? I uploaded my patch to the patch manager (as unidiff, sorry, but it is large enough in the current form, and for spelling corrections easy enough to follow). Rob Hooft -- ===== rob@hooft.net http://www.hooft.net/people/rob/ ===== ===== R&D, Nonius BV, Delft http://www.nonius.nl/ ===== ===== PGPid 0xFA19277D ========================== Use Linux! ========= From gstein@lyra.org Wed Jul 5 08:52:09 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 5 Jul 2000 00:52:09 -0700 Subject: [Python-Dev] Re: [Patches] Patch 100718 -- LinuxThreads vs. Pth In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jul 05, 2000 at 09:38:13AM +0300 References: Message-ID: <20000705005209.J29590@lyra.org> On Wed, Jul 05, 2000 at 09:38:13AM +0300, Moshe Zadka wrote: > > I'm +1 on this -- LinuxThreads is more-or-less Posix compliant, and is > based on Kernel level support. It seems much closer to the norm in the > Linux world then Pth. This patch is a huge +1. We should *never* prefer Pth over LinuxThreads. Never. Ever. Hell... there isn't really "LinuxThreads" any more -- it is part of glibc. We really shouldn't take an external package over the core C library. Pth is a user-mode thread package. That should not be used by Python unless somebody specifically requests it. Gah. How did that Pth get preferred installation... I'm off to fix this sucker. Big time. There is a separate problem for how somebody can override the selection mechanism. But we're talking defaults here, and we should select the proper default. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Wed Jul 5 08:55:55 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 09:55:55 +0200 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... References: Message-ID: <3962EA0B.2EBED7A8@lemburg.com> Tim Peters wrote: > > [M.-A. Lemburg] > > While fiddling around with the _GNU_SOURCE define I found > > that there are several warnings left in the current CVS > > version which should be removed, I guess. > > > > Here's the list I get from compiling the tree using -Wall > > grouped by C file: > > So long as any warnings remain, would you please repost the list from time > to time? There's no need to group them by file. Ok. Note that the idea behind posting the list was to make module authors/editors aware of warnings in their code... Fred already made his changes -- it would probably be a good idea if the others did the same. > > ./pypcre.c:4524: warning: variable `start_bits' might be > > clobbered by `longjmp' or `vfork' > > ./pypcre.c:4525: warning: variable `start_match' might be > > clobbered by `longjmp' or `vfork' > > These are often a PITA to fix: gcc does brain-dead flow analysis, and this > particular msg is almost always bogus as a result. There are several open > bugs filed against gcc on this (I know because one of them is mine ). > The others look straightforward to fix (on a first scan). That one has been in Python since pcre was adopted -- I don't think there's much we can do about it either... but then: sre is coming on strong so we might as well drop pcre for say 2.1. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Moshe Zadka Wed Jul 5 09:06:06 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 5 Jul 2000 11:06:06 +0300 (IDT) Subject: [Python-Dev] SF Beuracracy again Message-ID: Is there a difference between what SF calls "developers" and what we informally call "poeple with commit access"? Can anyone clear the stati people can have with regard to the Python project? (I've just revived my account on SF because of Python...) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From tim_one@email.msn.com Wed Jul 5 09:14:22 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 04:14:22 -0400 Subject: [Python-Dev] RE: [Patches] Patch 100718 -- LinuxThreads vs. Pth In-Reply-To: Message-ID: [moved from patches to python-dev] [Moshe] > (Question to PythonLabs team: any hope of getting the patch contents in > e-mail? It's much easier to comment that way) Seems really a question for SourceForge at this point. If we could have, we would have by now. From mal@lemburg.com Wed Jul 5 09:34:27 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 10:34:27 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: Message-ID: <3962F313.186B10FB@lemburg.com> Ka-Ping Yee wrote: > > On Tue, 4 Jul 2000, M.-A. Lemburg wrote: > > > > The reasoning at the time was that dictionaries should accept > > Unicode objects as keys which match their string equivalents > > as the same key, e.g. 'abc' works just as well as u'abc'. > [...] > > According to the docs, objects comparing equal should have the > > same hash value, yet this would require the hash value to be > > calculated using the default encoding and that > > would not only cause huge performance problems, but could > > effectively render Unicode useless, > > Given the new 7-bit-ASCII-as-default-encoding-for-8-bit-strings > convention, shouldn't just hashing the character values work > fine? That is, hash('abc') should == hash(u'abc'), no conversion > required. Yes, and it does so already for pure ASCII values. The problem comes from the fact that the default encoding can be changed to a locale specific value (site.py does the lookup for you), e.g. given you have defined LANG to be us_en, Python will default to Latin-1 as default encoding. This results in 'äöü' == u'äöü', but hash('äöü') != hash(u'äöü'), which is in conflict with the general rule about objects having the same hash value if they compare equal. Now, I could go and change the internal cache buffer to hold the default encoding instead of UTF-8, but this would affect not only hash(), but also the 's' and 't' parser markers, etc. ... I wonder why compiling "print u'\uD800'" causes the hash value to be computed ... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Wed Jul 5 09:37:23 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 10:37:23 +0200 Subject: [Python-Dev] RE: \ud800 crashes interpreter (PR#384) References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD269@RED-MSG-50> Message-ID: <3962F3C3.74A7825D@lemburg.com> Bill Tutt wrote: > > > MAL wrotw: > >> Bill wrote: > >> u'\ud800' causes the interpreter to crash > >> example: > >> print u'\ud800' > >> What happens: > >> The code failes to compile because while adding the constant, the > unicode_hash > >> function is called which for some reason requires the UTF-8 string > format. > > > The reasoning at the time was that dictionaries should accept > > Unicode objects as keys which match their string equivalents > > as the same key, e.g. 'abc' works just as well as u'abc'. > > > UTF-8 was the default encoding back then. I'm not sure how > > to fix the hash value given the new strategy w/r to the > > default encoding... > > > According to the docs, objects comparing equal should have the > > same hash value, yet this would require the hash value to be > > calculated using the default encoding and that > > would not only cause huge performance problems, but could > > effectively render Unicode useless, because not all default > > encodings are lossless (ok, one could work around this by > > falling back to some other way of calculating the hash > > value in case the conversion fails). > > Yeah, yeah, yeah. I know all that, just never liked it. :) > The current problem is that the UTF-8 can't round trip surrogate characters > atm. > This is easy to fix, so I'm doing a patch to fix this oversight, unless you > beat me to it. > > Anything else is slightly more annoying to fix. I left out surrogates in the UTF-8 codec on purpose: the Python implementation currently doesn't have support for these, e.g. slicing doesn't care about UTF-16 surrogates, so I made sure that people using these get errors ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one@email.msn.com Wed Jul 5 10:05:16 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 05:05:16 -0400 Subject: [Python-Dev] RE: Making the CVS tree pass the -Wall test... In-Reply-To: <200007050650.IAA00972@loewis.home.cs.tu-berlin.de> Message-ID: >> ./pypcre.c:4524: warning: variable `start_bits' might be >> clobbered by `longjmp' or `vfork' >> ./pypcre.c:4525: warning: variable `start_match' might be >> clobbered by `longjmp' or `vfork' [Tim sez these are almost always bogus wngs, Martin sez these two are legit] The start_bits wng is bogus because start_bit's only definition points precede the do-loop: start_bits will either be NULL or extra->start_bits by the time the "do" is entered, and can never change after that (yes, start_bits "appears" in the loop, but not as an lvalue -- it's only referenced). So the value setjmp tucks away is necessarily the correct value for longjmp to restore. This is a purely local flow question; knowledge of when a longjmp may occur isn't needed. I agree the start_match wng is legit. In my previous life, I tracked down about a hundred of these, and found only one that was legit. So pypcre is as sick as Dragon's half-million lines of speech recognition code . "The usual" way to fix this is to slop "volatile" onto the declarations, as the author already did for three other locals. That's the second reason this warning sucks: it depends on which locals gcc decides to carry in registers, and that varies from release to release. And that's the third reason this warning sucks: gcc is actually complaining about its *own* decision to carry something in a register <0.1 wink -- and if it *knows* it's not safe to carry something in a register, it shouldn't!>. From tim_one@email.msn.com Wed Jul 5 10:07:59 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 05:07:59 -0400 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... In-Reply-To: <3962EA0B.2EBED7A8@lemburg.com> Message-ID: [MAL] > While fiddling around with the _GNU_SOURCE define I found > that there are several warnings left in the current CVS > version which should be removed, I guess. [Tim] > So long as any warnings remain, would you please repost the > list from time to time? There's no need to group them by file. [MAL] > Ok. > > Note that the idea behind posting the list was to make > module authors/editors aware of warnings in their code... Fred > already made his changes -- it would probably be a good idea > if the others did the same. Of course. That's why I'm asking you to repost this list until no wngs remain . one-time-implicit-nags-don't-work-ly y'rs - tim From tim_one@email.msn.com Wed Jul 5 10:11:18 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 05:11:18 -0400 Subject: [Python-Dev] SF Beuracracy again In-Reply-To: Message-ID: [Moshe Zadka] > Is there a difference between what SF calls "developers" and what we > informally call "poeple with commit access"? Not that I know of. > Can anyone clear the stati > people can have with regard to the Python project? Try rephrasing that question in a known language . Ah, plural of "status"? You're a developer or you're not, and if you're a developer you're an admin or you're not. That's it. > (I've just revived my account on SF because of Python...) If you're looking for sympathy, this is the wrong list . From fredrik@pythonware.com Wed Jul 5 10:14:21 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 11:14:21 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> Message-ID: <007f01bfe661$68b26080$0900a8c0@SPIFF> mal wrote: > > Given the new 7-bit-ASCII-as-default-encoding-for-8-bit-strings > > convention, shouldn't just hashing the character values work > > fine? That is, hash('abc') should == hash(u'abc'), no conversion > > required. > > Yes, and it does so already for pure ASCII values. The problem > comes from the fact that the default encoding can be changed to > a locale specific value (site.py does the lookup for you), e.g. > given you have defined LANG to be us_en, Python will default > to Latin-1 as default encoding. footnote: in practice, this is a Unix-only feature. I suggest adding code to the _locale module (or maybe sys is better?) which can be used to dig up a suitable encoding for non-Unix platforms. On Windows, the code page should be "cp%d" % GetACP(). I'll look into this later today. From thomas@xs4all.net Wed Jul 5 10:15:09 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 5 Jul 2000 11:15:09 +0200 Subject: [Python-Dev] python 2.0 and '-tt' Message-ID: <20000705111509.J13469@xs4all.nl> I seem to recall someone claiming that the behaviour of the -tt flag was going to be the default in the next 'major' release of Python. Seeing as how the socket.socket change is back in again, it might be worth looking at this again ? Then again, I'm a newbie, it might be a done deal already, one way or the other ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mwh21@cam.ac.uk Wed Jul 5 10:19:29 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: Wed, 5 Jul 2000 10:19:29 +0100 (BST) Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <14690.56733.627266.907044@temoleh.chem.uu.nl> Message-ID: On Wed, 5 Jul 2000, Rob W. W. Hooft wrote: [schnipp] > Then 2 points on distutils: > - the word "licence" is used throughout, and "license" is introduced as > alternative. The other way around looks more natural to me. Isn't one the noun (licence) and one the verb (license)? (mind you dictionary.com doesn't think so, so I'd say pick one and stick with it). > - the term "anal retentives" should probably be replaced before 2.0 This reminds me of when they took out the swear words from the sources to linuk-kernel :-) > Is "s's" as in "the process's exit code" valid English? I think yes, because "process" is not a plural; it would be "processes' exit codes". but-then-I'm-a-mathematician-ly y'rs Michael From mal@lemburg.com Wed Jul 5 10:27:21 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 11:27:21 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> <007f01bfe661$68b26080$0900a8c0@SPIFF> Message-ID: <3962FF79.B1A773D0@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > Given the new 7-bit-ASCII-as-default-encoding-for-8-bit-strings > > > convention, shouldn't just hashing the character values work > > > fine? That is, hash('abc') should == hash(u'abc'), no conversion > > > required. > > > > Yes, and it does so already for pure ASCII values. The problem > > comes from the fact that the default encoding can be changed to > > a locale specific value (site.py does the lookup for you), e.g. > > given you have defined LANG to be us_en, Python will default > > to Latin-1 as default encoding. > > footnote: in practice, this is a Unix-only feature. > > I suggest adding code to the _locale module (or maybe sys is > better?) which can be used to dig up a suitable encoding for > non-Unix platforms. On Windows, the code page should be > "cp%d" % GetACP(). > > I'll look into this later today. Could you add code to the _locale module which interfaces to GetACP() on win32 ? locale.get_default could then make use of this API to figure out the encoding. Ideal would be another API for win32 which allows querying the active language (it would have to return an RFC 1766 language code or we could add aliasis to the locale_alias database). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik@pythonware.com Wed Jul 5 10:38:55 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 11:38:55 +0200 Subject: [Python-Dev] Spelling check: more typos References: Message-ID: <009501bfe664$d6845ca0$0900a8c0@SPIFF> > Isn't one the noun (licence) and one the verb (license)? (mind you > dictionary.com doesn't think so, so I'd say pick one and stick with it). fwiw, none of the dictionaries I've checked agree with you. and they all seem to prefer "license" over "licence". > > Is "s's" as in "the process's exit code" valid English? > > I think yes, because "process" is not a plural; it would be "processes' > exit codes". according to the only grammar I found: FORMING THE POSSESSIVE WITH 'S AND ' 1.Singular nouns take 's 2.irregular plurals take 's 3.Nouns ending in s (plural or singular) take ' > but-then-I'm-a-mathematician-ly y'rs and we're a bunch of non-native english speakers ;-) From mal@lemburg.com Wed Jul 5 10:53:10 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 11:53:10 +0200 Subject: [Python-Dev] Docs for string methods ? Message-ID: <39630586.A253198A@lemburg.com> I've just checked in new string methods which provide access to the C APIs isalpha and isalnum for both strings and Unicode objects. Question: where should I put the docs ? I haven't found any place in the current CVS tree which document the new string methods -- even though all of them have doc strings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik@pythonware.com Wed Jul 5 11:01:21 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 12:01:21 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> Message-ID: <00d101bfe667$f9099d00$0900a8c0@SPIFF> mal wrote: > I've just checked in new string methods talking about string methods: how about providing an "encode" method for 8-bit strings too? From esr@thyrsus.com Wed Jul 5 11:09:43 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 5 Jul 2000 06:09:43 -0400 Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <009501bfe664$d6845ca0$0900a8c0@SPIFF>; from fredrik@pythonware.com on Wed, Jul 05, 2000 at 11:38:55AM +0200 References: <009501bfe664$d6845ca0$0900a8c0@SPIFF> Message-ID: <20000705060943.A18539@thyrsus.com> Fredrik Lundh : > > Isn't one the noun (licence) and one the verb (license)? (mind you > > dictionary.com doesn't think so, so I'd say pick one and stick with it). > > fwiw, none of the dictionaries I've checked agree with you. > and they all seem to prefer "license" over "licence". > > > > Is "s's" as in "the process's exit code" valid English? > > > > I think yes, because "process" is not a plural; it would be "processes' > > exit codes". > > according to the only grammar I found: > > FORMING THE POSSESSIVE WITH 'S AND ' > 1.Singular nouns take 's > 2.irregular plurals take 's > 3.Nouns ending in s (plural or singular) take ' > > > but-then-I'm-a-mathematician-ly y'rs > > and we're a bunch of non-native english speakers ;-) I am a native speaker, and an expert in the fine points of English grammar and usage (a necessary qualification for editing the New Hacker's Dictionary). Tim's source is correct. Learn these rules; they will mark you out from the vast sea of yahoos who (for example) use "it's" where "its" is correct. (Guido's English is impressively correct, BTW. The rest of you non-native speakers -- and some of you native ones -- could learn from him.) -- Eric S. Raymond You [should] not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harm it would cause if improperly administered -- Lyndon Johnson, former President of the U.S. From mwh21@cam.ac.uk Wed Jul 5 11:06:11 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: Wed, 5 Jul 2000 11:06:11 +0100 (BST) Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <20000705060943.A18539@thyrsus.com> Message-ID: On Wed, 5 Jul 2000, Eric S. Raymond wrote: > Fredrik Lundh : > > > > Is "s's" as in "the process's exit code" valid English? > > > > > > I think yes, because "process" is not a plural; it would be "processes' > > > exit codes". > > > > according to the only grammar I found: > > > > FORMING THE POSSESSIVE WITH 'S AND ' > > 1.Singular nouns take 's > > 2.irregular plurals take 's > > 3.Nouns ending in s (plural or singular) take ' > > > > > but-then-I'm-a-mathematician-ly y'rs > > > > and we're a bunch of non-native english speakers ;-) > > I am a native speaker, and an expert in the fine points of English grammar > and usage (a necessary qualification for editing the New Hacker's > Dictionary). Tim's source is correct. Tim? Do you mean /F? > Learn these rules; they will mark you out from the vast sea of yahoos > who (for example) use "it's" where "its" is correct. Well, the given rules don't account for that one do they? "Process' exit code" just looks wrong to me. Don't know why. Cheers, M. From mal@lemburg.com Wed Jul 5 11:06:21 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 12:06:21 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> Message-ID: <3963089D.8144149C@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > I've just checked in new string methods > > talking about string methods: how about providing an > "encode" method for 8-bit strings too? I've tossed that idea around a few times too... it could have the same interface as the Unicode one (without default encoding though). The only problem is that there are currently no codecs which could deal with strings on input. String codecs would have to be of the form 'latin1_utf8', that is, have implicit knowledge about the input encoding (and not only the output encoding as with Unicode codecs). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik@pythonware.com Wed Jul 5 11:15:54 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 12:15:54 +0200 Subject: [Python-Dev] Spelling check: more typos References: <009501bfe664$d6845ca0$0900a8c0@SPIFF> <20000705060943.A18539@thyrsus.com> Message-ID: <010901bfe66a$017d8b70$0900a8c0@SPIFF> eric wrote: > > > > Is "s's" as in "the process's exit code" valid English? > > > > > > I think yes, because "process" is not a plural; it would be "processes' > > > exit codes". > > > > according to the only grammar I found: > > > > FORMING THE POSSESSIVE WITH 'S AND ' > > 1.Singular nouns take 's > > 2.irregular plurals take 's > > 3.Nouns ending in s (plural or singular) take ' > > > > > but-then-I'm-a-mathematician-ly y'rs > > > > and we're a bunch of non-native english speakers ;-) > > I am a native speaker, and an expert in the fine points of English grammar > and usage (a necessary qualification for editing the New Hacker's > Dictionary). Tim's source is correct. Learn these rules; they will > mark you out from the vast sea of yahoos who (for example) use "it's" > where "its" is correct. what rules? the "tim is always correct" rule, or the grammar rules I quoted? From esr@thyrsus.com Wed Jul 5 11:24:34 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 5 Jul 2000 06:24:34 -0400 Subject: [Python-Dev] Spelling check: more typos In-Reply-To: ; from mwh21@cam.ac.uk on Wed, Jul 05, 2000 at 11:06:11AM +0100 References: <20000705060943.A18539@thyrsus.com> Message-ID: <20000705062434.A18614@thyrsus.com> Michael Hudson : > > > FORMING THE POSSESSIVE WITH 'S AND ' > > > 1.Singular nouns take 's > > > 2.irregular plurals take 's > > > 3.Nouns ending in s (plural or singular) take ' > > > > > I am a native speaker, and an expert in the fine points of English grammar > > and usage (a necessary qualification for editing the New Hacker's > > Dictionary). Tim's source is correct. > > Tim? Do you mean /F? I believe /F was quoting Tim. > > Learn these rules; they will mark you out from the vast sea of yahoos > > who (for example) use "it's" where "its" is correct. > > Well, the given rules don't account for that one do they? Hm, I guess you have to know that pronouns pluralize irregularly to cover that case. What creates the confusion is that "it's" is the correct contraction of "it is", but looks like a possessive inflection of the pronoun "it". -- Eric S. Raymond "You have taught us much. Come with us and join the movement." "This movement of yours, does it have slogans?" inquired the Chink. "Right on!" they cried. And they quoted him some. "Your movement, does it have a flag?" asked the Chink. "You bet!" and they described their emblem. "And does your movement have leaders?" "Great leaders." "Then shove it up your butts," said the Chink. "I have taught you nothing." -- Tom Robbins, "Even Cowgirls Get The Blues" From fredrik@pythonware.com Wed Jul 5 11:20:04 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 12:20:04 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> Message-ID: <011101bfe66a$96d18aa0$0900a8c0@SPIFF> mal wrote: > Fredrik Lundh wrote: > > > > mal wrote: > > > I've just checked in new string methods > > > > talking about string methods: how about providing an > > "encode" method for 8-bit strings too? > > I've tossed that idea around a few times too... it could > have the same interface as the Unicode one (without default > encoding though). The only problem is that there are currently > no codecs which could deal with strings on input. imho, a consistent interface is more important than a truly optimal implementation (string are strings yada yada). or in other words, def encode(self, encoding): if encoding is close enough: return self return unicode(self).encode(encoding) ought to be good enough for now. From mal@lemburg.com Wed Jul 5 11:29:11 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 12:29:11 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> <011101bfe66a$96d18aa0$0900a8c0@SPIFF> Message-ID: <39630DF7.4B7ADB63@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Fredrik Lundh wrote: > > > > > > mal wrote: > > > > I've just checked in new string methods > > > > > > talking about string methods: how about providing an > > > "encode" method for 8-bit strings too? > > > > I've tossed that idea around a few times too... it could > > have the same interface as the Unicode one (without default > > encoding though). The only problem is that there are currently > > no codecs which could deal with strings on input. > > imho, a consistent interface is more important than a truly > optimal implementation (string are strings yada yada). or in > other words, > > def encode(self, encoding): > if encoding is close enough: > return self > return unicode(self).encode(encoding) > > ought to be good enough for now. Ideally str() should have an encoding parameter too. Then I could add generic PyString_Encode|Decode|AsEncodedString APIs to stringobject.c which match the corresponding ones in unicodeobject.c gzippeddata = file.read() # Unzip a data packet (decode part of the codec) data = str(gzippeddata, 'data_gzip') # Zip a data packet (encode part of the codec) gzippeddata = data.encode('data_gzip') Looks cool ;-) Note that 'abc'.encode('utf8') would fail because the UTF-8 codec expects Unicod on input to its encode method (hmm, perhaps I ought to make the method use the 'u' parser marker instead of 'U' -- that way, the method would auto-convert the 'abc' string to Unicode using the default encoding and then proceed to encode it in UTF-8). Other opinions ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Wed Jul 5 11:32:33 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 12:32:33 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> <011101bfe66a$96d18aa0$0900a8c0@SPIFF> <39630DF7.4B7ADB63@lemburg.com> Message-ID: <39630EC1.891DCE8F@lemburg.com> "M.-A. Lemburg" wrote: > > Note that 'abc'.encode('utf8') would fail because the UTF-8 > codec expects Unicod on input to its encode method (hmm, perhaps > I ought to make the method use the 'u' parser marker instead > of 'U' -- that way, the method would auto-convert the 'abc' > string to Unicode using the default encoding and then proceed > to encode it in UTF-8). Uhm, forget that last part... 'u' doesn't do auto-conversion :-( I could add that functionality to the interfaces in _codecmodule.c directly, though. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping@lfw.org Wed Jul 5 11:50:18 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 5 Jul 2000 03:50:18 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: Message-ID: On Tue, 4 Jul 2000, Ka-Ping Yee wrote: > It turns out that this should be quite easy. If it weren't > past 4am i would be posting a patch instead of just a verbal > suggestion right now -- but here's how to do it. Okay, done. Submitted to SourceForge as patch #100734. For the patch itself, see http://sourceforge.net/patch/download.php?id=100734 or http://sourceforge.net/patch/?func=detailpatch&patch_id=100734&group_id=5470 Here is a sample of the resulting behaviour: >>> if 3: ... 3 File "", line 2 3 ^ SyntaxError: expected indent here >>> 3 File "", line 1 3 ^ SyntaxError: unexpected indent >>> if 1: ... 3 ... 4 File "", line 3 4 ^ SyntaxError: dedent does not match any outer indentation level >>> if 1: ... if 2: ... 3 File "", line 3 3 ^ SyntaxError: unexpected dedent >>> if 1: ... if 2: ... 3 File "", line 3 3 ^ SyntaxError: dedent does not match any outer indentation level >>> Also (didn't want to waste pages of text demonstrating it) if you indent more than 100 levels, you get SyntaxError: too many levels of indentation instead of the current message, "invalid token". The internal changes are: 1. Added E_TOODEEP (too many indentation levels) and E_DEDENT (no matching outer block for dedent) to errcode.h. 2. Made PyTokenizer_Get (in tokenizer.c) return E_TOODEEP and E_DEDENT instead of printing messages to stderr; added corresponding error messages in err_input (in pythonrun.c). 3. Renamed E_INDENT to E_TABSPACE. 4. Added int *expected_ret argument to PyParser_AddToken; on a syntax error, PyParser_AddToken (in parser.c) places the expected token type (if any) into this output parameter. 5. Added "token" and "expected" to struct perrdetail; made parsetok (in parsetok.c) copy the current token into "token" and the expected token into "expected" on a syntax error. 6. Added checks in err_input (in pythonrun.c) to print more detailed error messages if err->token or err->expected happens to be INDENT or DEDENT when a syntax error occurs. This leaves the door open for err_input to say more interesting things about the syntax error if it wants, based on the information in err->token and err->expected, though i haven't added any more detailed messages except for the ones about indentation for now. Look good to you? -- ?!ng From gvwilson@nevex.com Wed Jul 5 12:10:33 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Wed, 5 Jul 2000 07:10:33 -0400 (EDT) Subject: [Python-Dev] re: punctuation / spelling Message-ID: The best on-line writing style guide I know of is the one used by the The Economist: http://www.economist.com/editorial/freeforall/library/index_styleguide.html Their advice on possessives is: Use the normal possessive ending 's after singular words or names that end in s: boss's, caucus's, Delors's, St James's, Jones's, Shanks's. Use it after plurals that do not end in s: children's, Frenchmen's, media's. Use the ending s' on plurals that end in s---Danes', bosses', Joneses'---including plural names that take a singular verb, eg, Reuters', Barclays', Stewarts & Lloyds', Salomon Brothers'. Although singular in other respects, the United States, the United Nations, the Philippines, etc, have a plural possessive apostrophe: eg, Who will be the United States' next president? Strunk & White is also a good, pocket-sized resource, but so far as I know there is no up-to-date edition on-line. Greg From esr@thyrsus.com Wed Jul 5 12:32:10 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 5 Jul 2000 07:32:10 -0400 Subject: [Python-Dev] re: punctuation / spelling In-Reply-To: ; from gvwilson@nevex.com on Wed, Jul 05, 2000 at 07:10:33AM -0400 References: Message-ID: <20000705073210.B18933@thyrsus.com> Greg Wilson : > The best on-line writing style guide I know of is the one used by the The > Economist: > > http://www.economist.com/editorial/freeforall/library/index_styleguide.html I enthusiastically second this recommendation. For American use their advice is a touch British-flavored in the orthography department, but their recommendations on grammar and style are impeccable. The Economist is my favorite news magazine in the world. -- Eric S. Raymond "This country, with its institutions, belongs to the people who inhabit it. Whenever they shall grow weary of the existing government, they can exercise their constitutional right of amending it or their revolutionary right to dismember it or overthrow it." -- Abraham Lincoln, 4 April 1861 From fredrik@pythonware.com Wed Jul 5 12:51:56 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 13:51:56 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> <011101bfe66a$96d18aa0$0900a8c0@SPIFF> <39630DF7.4B7ADB63@lemburg.com> Message-ID: <02b501bfe677$6ba38b00$0900a8c0@SPIFF> mal wrote: > > > > talking about string methods: how about providing an > > > > "encode" method for 8-bit strings too? > > > > > > I've tossed that idea around a few times too... it could > > > have the same interface as the Unicode one (without default > > > encoding though). The only problem is that there are currently > > > no codecs which could deal with strings on input. > > > > imho, a consistent interface is more important than a truly > > optimal implementation (string are strings yada yada). or in > > other words, > > > > def encode(self, encoding): > > if encoding is close enough: > > return self > > return unicode(self).encode(encoding) > > > > ought to be good enough for now. /snip/ > Note that 'abc'.encode('utf8') would fail because the UTF-8 > codec expects Unicod on input to its encode method (hmm, perhaps > I ought to make the method use the 'u' parser marker instead > of 'U' -- that way, the method would auto-convert the 'abc' > string to Unicode using the default encoding and then proceed > to encode it in UTF-8). sorry, I wasn't clear: the "def encode" snippet above should be a string method, not a function. "abc".encode("utf8") would be "return self" if the default encoding is "ascii" or "utf8", and "return unicode("abc").encode("utf8")" other- wise. cheers /F From bwarsaw@beopen.com Wed Jul 5 12:56:02 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 07:56:02 -0400 (EDT) Subject: [Python-Dev] Making -tt the default References: <20000703233938.N29590@lyra.org> Message-ID: <14691.8786.180085.468266@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> (add-hook 'python-mode-hook | (lambda () | (setq indent-tabs-mode nil) | (setq py-indent-offset 2) | (setq py-smart-indentation nil) | (define-key py-mode-map "\e\C-h" 'backward-kill-word) | )) GS> The indent-tabs-mode is the key to disabling tab characters GS> and using just spaces. Greg, can you explain why you turn off py-smart-indentation? Its purpose is to give you the correct settings when editing someone else's existing code. With this variable set to t, it tries to guess the existing code's indentation level depth and then sets py-indent-offset to that value, on the assumption that 1) the original author indented their code consistently 2) it is better to be consistent with the existing indentation than impose your own and have mixed indentation Both of these are worthy goals, IMO, so py-smart-indentation should generally remain true. For brand new code, given the fact that pymode's default for py-indent-offset is 4, and Emacs' default for tab-width is 8 (and should not be changed), you'll generally find that indent-tabs-mode will be nil when py-smart-indentation is t. So I think pymode is doing the right thing, and I'm -1 on patch #100729. If the user wants indent-tabs-mode set to nil unconditionally, then setting it in your python-mode-hook, as you've done, is the Emacs way. But if someone can give a good example where this approach is flawed, please let me know. -Barry From fredrik@pythonware.com Wed Jul 5 12:57:40 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 13:57:40 +0200 Subject: [Python-Dev] Better SyntaxError messages References: Message-ID: <02bf01bfe678$3a1baee0$0900a8c0@SPIFF> ?!ng wrote: > Okay, done. Submitted to SourceForge as patch #100734. For the patch > itself, see http://sourceforge.net/patch/download.php?id=100734 or > http://sourceforge.net/patch/?func=detailpatch&patch_id=100734&group_id=5470 +2 on concept. and the patch looks clean. let's get this one in there asap! (marc-andre?) > Look good to you? you bet! From mal@lemburg.com Wed Jul 5 12:59:34 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 13:59:34 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> <011101bfe66a$96d18aa0$0900a8c0@SPIFF> <39630DF7.4B7ADB63@lemburg.com> <02b501bfe677$6ba38b00$0900a8c0@SPIFF> Message-ID: <39632326.9A724C2@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > > > talking about string methods: how about providing an > > > > > "encode" method for 8-bit strings too? > > > > > > > > I've tossed that idea around a few times too... it could > > > > have the same interface as the Unicode one (without default > > > > encoding though). The only problem is that there are currently > > > > no codecs which could deal with strings on input. > > > > > > imho, a consistent interface is more important than a truly > > > optimal implementation (string are strings yada yada). or in > > > other words, > > > > > > def encode(self, encoding): > > > if encoding is close enough: > > > return self > > > return unicode(self).encode(encoding) > > > > > > ought to be good enough for now. > > /snip/ > > > Note that 'abc'.encode('utf8') would fail because the UTF-8 > > codec expects Unicod on input to its encode method (hmm, perhaps > > I ought to make the method use the 'u' parser marker instead > > of 'U' -- that way, the method would auto-convert the 'abc' > > string to Unicode using the default encoding and then proceed > > to encode it in UTF-8). > > sorry, I wasn't clear: the "def encode" snippet above should be > a string method, not a function. > > "abc".encode("utf8") would be "return self" if the default encoding > is "ascii" or "utf8", and "return unicode("abc").encode("utf8")" other- > wise. I've just checked in modifications to the builtin codecs which allow them to accept 8-bit strings too. They will convert the strings to Unicode and then encode them as usual. So given that the .encode() method gets accepted (I haven't heard any other opinions yet), "abc".encode("utf8") will work just like any other builtin codec (the 8-bit string will be interpreted under the default encoding assumption). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Wed Jul 5 13:01:26 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 14:01:26 +0200 Subject: [Python-Dev] Better SyntaxError messages References: <02bf01bfe678$3a1baee0$0900a8c0@SPIFF> Message-ID: <39632396.32E4BA61@lemburg.com> Fredrik Lundh wrote: > > ?!ng wrote: > > Okay, done. Submitted to SourceForge as patch #100734. For the patch > > itself, see http://sourceforge.net/patch/download.php?id=100734 or > > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100734&group_id=5470 > > +2 on concept. > > and the patch looks clean. let's get this one in > there asap! (marc-andre?) I'd rather have someone else with more knowledge about Python's parser check this in... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik@pythonware.com Wed Jul 5 13:19:27 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 14:19:27 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> <007f01bfe661$68b26080$0900a8c0@SPIFF> <3962FF79.B1A773D0@lemburg.com> Message-ID: <02f701bfe67b$43ec51b0$0900a8c0@SPIFF> mal wrote: > Ideal would be another API for win32 which allows querying > the active language (it would have to return an RFC 1766 > language code or we could add aliasis to the locale_alias > database). A quick look indicates that Windows uses "language identifiers": http://msdn.microsoft.com/library/psdk/winbase/nls_8xo3.htm Maybe Bill can dig up some better way to do this (a "language identifier to language code" table would be nice. There's one in Windows 2000 ;-) From Vladimir.Marangozov@inrialpes.fr Wed Jul 5 13:29:36 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 5 Jul 2000 14:29:36 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Ka-Ping Yee" at Jul 05, 2000 03:50:18 AM Message-ID: <200007051229.OAA19526@python.inrialpes.fr> Ka-Ping Yee wrote: > > On Tue, 4 Jul 2000, Ka-Ping Yee wrote: > > It turns out that this should be quite easy. If it weren't > > past 4am i would be posting a patch instead of just a verbal > > suggestion right now -- but here's how to do it. > > Okay, done. Looks fine. +1 on the concept. 2 things about the patch: > > >>> if 3: > ... 3 > File "", line 2 > 3 > ^ > SyntaxError: expected indent here I'd remove the word "here" so that the error msg is self-contained. "expected indent" & "expected dedent" are fine. > The internal changes are: > > 1. Added E_TOODEEP (too many indentation levels) and > E_DEDENT (no matching outer block for dedent) to errcode.h. > > 2. Made PyTokenizer_Get (in tokenizer.c) return E_TOODEEP and > E_DEDENT instead of printing messages to stderr; added > corresponding error messages in err_input (in pythonrun.c). > > 3. Renamed E_INDENT to E_TABSPACE. > > 4. Added int *expected_ret argument to PyParser_AddToken; on > a syntax error, PyParser_AddToken (in parser.c) places the > expected token type (if any) into this output parameter. I'd suggest passing a pointer to the perrdetail structure (to the whole error, that is), instead of a pointer to one of its fields. > > 5. Added "token" and "expected" to struct perrdetail; made > parsetok (in parsetok.c) copy the current token into "token" > and the expected token into "expected" on a syntax error. > > 6. Added checks in err_input (in pythonrun.c) to print more > detailed error messages if err->token or err->expected > happens to be INDENT or DEDENT when a syntax error occurs. > > This leaves the door open for err_input to say more interesting > things about the syntax error if it wants, based on the information > in err->token and err->expected, though i haven't added any more > detailed messages except for the ones about indentation for now. > > > Look good to you? > Yes. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gvwilson@nevex.com Wed Jul 5 13:34:28 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Wed, 5 Jul 2000 08:34:28 -0400 (EDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <200007051229.OAA19526@python.inrialpes.fr> Message-ID: > On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > I'd remove the word "here" so that the error msg is self-contained. > "expected indent" & "expected dedent" are fine. I just did a poll --- only 2 out of 5 programmers in my shouting radius know what "dedent" means. Is there a more accessible way to phrase the error message? Thanks, Greg From Vladimir.Marangozov@inrialpes.fr Wed Jul 5 13:54:50 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 5 Jul 2000 14:54:50 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Greg Wilson" at Jul 05, 2000 08:34:28 AM Message-ID: <200007051254.OAA19572@python.inrialpes.fr> Greg Wilson wrote: > > > On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > > I'd remove the word "here" so that the error msg is self-contained. > > "expected indent" & "expected dedent" are fine. > > I just did a poll --- only 2 out of 5 programmers in my shouting radius > know what "dedent" means. Is there a more accessible way to phrase the > error message? Good point. Here's another suggestion: "expected indent" -> "missing expected indentation" "expected dedent" -> "missing expected closing indentation" ? -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mwh21@cam.ac.uk Wed Jul 5 14:17:49 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: Wed, 5 Jul 2000 14:17:49 +0100 (BST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <200007051254.OAA19572@python.inrialpes.fr> Message-ID: On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > Greg Wilson wrote: > > > > > On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > > > I'd remove the word "here" so that the error msg is self-contained. > > > "expected indent" & "expected dedent" are fine. > > > > I just did a poll --- only 2 out of 5 programmers in my shouting radius > > know what "dedent" means. Is there a more accessible way to phrase the > > error message? > > Good point. > > Here's another suggestion: > > "expected indent" -> "missing expected indentation" +0 - doesn't really change much does it? > "expected dedent" -> "missing expected closing indentation" Eugh. How about "expected decrease in indentation"? Though I think dedent (or mabye outdent) is pretty obvious in context. Also "decrease in indentation does not match any outer level" is a pretty hefty error message. Still, these things are so much better than the status quo that I'm about +1e8 on the general idea... Cheers, Michael From Mike.Da.Silva@uk.fid-intl.com Wed Jul 5 14:27:18 2000 From: Mike.Da.Silva@uk.fid-intl.com (Da Silva, Mike) Date: Wed, 5 Jul 2000 14:27:18 +0100 Subject: [Python-Dev] Better SyntaxError messages Message-ID: Michael Hudson wrote: >On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > > Greg Wilson wrote: > > > > > > > On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > > > > I'd remove the word "here" so that the error msg is self-contained. > > > > "expected indent" & "expected dedent" are fine. > > > > > > I just did a poll --- only 2 out of 5 programmers in my shouting radius > > > know what "dedent" means. Is there a more accessible way to phrase the > > > error message? > > > > Good point. > > > > Here's another suggestion: > > > > "expected indent" -> "missing expected indentation" > +0 - doesn't really change much does it? > > "expected dedent" -> "missing expected closing indentation" > Eugh. How about "expected decrease in indentation"? Though I think > dedent (or mabye outdent) is pretty obvious in context. > Also "decrease in indentation does not match any outer level" > is a pretty hefty error message. How about "expected unindent" ? > Still, these things are so much better than the status quo that I'm about +1e8 on the general idea... > Cheers, > Michael Regards, Mike _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://www.python.org/mailman/listinfo/python-dev From Vladimir.Marangozov@inrialpes.fr Wed Jul 5 14:36:37 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 5 Jul 2000 15:36:37 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Michael Hudson" at Jul 05, 2000 02:17:49 PM Message-ID: <200007051336.PAA19744@python.inrialpes.fr> Michael Hudson wrote: > > [me] > > Here's another suggestion: > > > > "expected indent" -> "missing expected indentation" > > +0 - doesn't really change much does it? It's slightly more explicit. > > > "expected dedent" -> "missing expected closing indentation" > > Eugh. How about "expected decrease in indentation"? Though I think > dedent (or mabye outdent) is pretty obvious in context. I like your correction. The problem is that "dedent" is very context-specific and it would be better if this term is avoided for user-messages, because they generally pop up out of context (i.e. when your head is in another context, so the context switch is painful). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From billtut@microsoft.com Wed Jul 5 16:26:22 2000 From: billtut@microsoft.com (Bill Tutt) Date: Wed, 5 Jul 2000 08:26:22 -0700 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD26A@RED-MSG-50> > MAL wrote: > ... I wonder why compiling "print u'\uD800'" causes the > hash value to be computed ... That's an easy one. Com_addconst() (or something it calls) calls PyObject_Hash() during the compilation process. Re: UTF-8 There's no reason why you can't support surrogates in UTF-8, while still not supporting them in slice notation. It's certainly the easiest way to fix the problem. Bill From mal@lemburg.com Wed Jul 5 16:40:19 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 17:40:19 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD26A@RED-MSG-50> Message-ID: <396356E3.A2F586B5@lemburg.com> Bill Tutt wrote: > > > MAL wrote: > > ... I wonder why compiling "print u'\uD800'" causes the > > hash value to be computed ... > > That's an easy one. Com_addconst() (or something it calls) calls > PyObject_Hash() during the compilation process. Ah ok. > Re: UTF-8 > There's no reason why you can't support surrogates in UTF-8, while still not > supporting them in slice notation. True. > It's certainly the easiest way to fix the problem. Well, it doesn't really fix the problem... your note only made it clear that with the change in default encoding (be it ASCII or whatever the locale defines), has the unwanted side effect of breaking the has/cmp rule for non-ASCII character strings vs. Unicode. Perhaps pushing the default encoding down all the way is the solution (with some trickery this is possible now, since changing the default encoding is only allows in site.py) or simply stating that the hash/cmp rule only works for ASCII contents of the objects. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip@mojam.com (Skip Montanaro) Wed Jul 5 05:57:19 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 4 Jul 2000 23:57:19 -0500 (CDT) Subject: [Python-Dev] SyntaxError/IndentationError/WhitespaceError Message-ID: <14690.49199.153631.236949@beluga.mojam.com> Just back from the annual patriotic revelry... Here are my thoughts on the various kinds of exceptions one might raise to denote various problems with indentation. SyntaxError - the most general form of parsing error WhitespaceError - tells the user something's wrong with the way the whitespace of the line parses - what -tt mode would raise IndentationError - more specific than WhitespaceError, but indicates the lines won't line up properly (without -tt mode) - what the parser would raise for something like: try: 1/0 1/0 except ZeroDivisionError: pass The distinction between WhitespaceError and IndentationError is likely to be a bit subtle for newbies, so I wonder if it's worth the effort to distinguish the two. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From gward@mems-exchange.org Wed Jul 5 18:02:15 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 13:02:15 -0400 Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: ; from Mike.Da.Silva@uk.fid-intl.com on Wed, Jul 05, 2000 at 02:27:18PM +0100 References: Message-ID: <20000705130215.A7564@ludwig.cnri.reston.va.us> On 05 July 2000, Da Silva, Mike said: > > > "expected dedent" -> "missing expected closing indentation" > > > Eugh. How about "expected decrease in indentation"? Though I think > > dedent (or mabye outdent) is pretty obvious in context. > > > Also "decrease in indentation does not match any outer level" > > is a pretty hefty error message. > > How about "expected unindent" ? I was going to suggest "unindent" from the moment I saw Ping's patch, so let me just chime in with a "yes indeed!". Also, along with the rest of the known universe, I strongly favour the proposed change. Haven't tried the patch yet, but I will. Greg From Vladimir.Marangozov@inrialpes.fr Wed Jul 5 18:12:37 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 5 Jul 2000 19:12:37 +0200 (CEST) Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <3962355D.7FD7429@lemburg.com> from "M.-A. Lemburg" at Jul 04, 2000 09:05:01 PM Message-ID: <200007051712.TAA20213@python.inrialpes.fr> M.-A. Lemburg wrote: > > I've added some ifdefs just to make sure. This is how my > Python.h file looks now: > > ... > See the file "Misc/COPYRIGHT" for information on usage and > redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES. > ******************************************************************/ > > /* Enable compiler features including SUSv2 compatibility; switching > on C lib defines doesn't work here, because the symbols haven't > necessarily been defined yet. */ > #ifndef _GNU_SOURCE > # define _GNU_SOURCE 1 > #endif > #ifndef _XOPEN_SOURCE > # define _XOPEN_SOURCE 500 > #endif Typically this should go to a new file -- pyport.h, suggested by Greg, included at the top of Python.h (and which allows to cleanup the HAVE_LIMITS_H define and others). We may introduce subsequently pyport.c if needed. Anything wrong with this? Opinions? -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal@lemburg.com Wed Jul 5 18:12:31 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 19:12:31 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <200007051712.TAA20213@python.inrialpes.fr> Message-ID: <39636C7F.D0A29101@lemburg.com> Vladimir Marangozov wrote: > > M.-A. Lemburg wrote: > > > > I've added some ifdefs just to make sure. This is how my > > Python.h file looks now: > > > > ... > > See the file "Misc/COPYRIGHT" for information on usage and > > redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES. > > ******************************************************************/ > > > > /* Enable compiler features including SUSv2 compatibility; switching > > on C lib defines doesn't work here, because the symbols haven't > > necessarily been defined yet. */ > > #ifndef _GNU_SOURCE > > # define _GNU_SOURCE 1 > > #endif > > #ifndef _XOPEN_SOURCE > > # define _XOPEN_SOURCE 500 > > #endif > > Typically this should go to a new file -- pyport.h, suggested by Greg, > included at the top of Python.h (and which allows to cleanup the > HAVE_LIMITS_H define and others). We may introduce subsequently pyport.c > if needed. > > Anything wrong with this? Opinions? Fine with me... I'd name it pyportability.h like Greg suggested, though. Note that the above is already checked into CVS (and the first bug related to it has shown up too; also fixed in CVS). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" maybe it's just me, but I think it's a bit confusing to have two functions in the same module with very similar names: >>> import locale >>> print locale.setlocale.__doc__ (integer,string=3DNone) -> string. Activates/queries locale = processing. >>> print locale.set_locale.__doc__ Set the locale according to the localetuple (language code, encoding) as returned by get_locale() and get_default(). The given codes are passed through the locale aliasing engine before being given to setlocale() for processing. category may be given as one of the LC_* values. It defaults to LC_ALL. maybe "setlocale" should be changed to accept either a string or a tuple? (from which follows that get_locale should be "getlocale", and get_default "getdefaultlocale". or something...) (btw, maybe both doc strings should mention the arguments? or maybe none of them should? what does the style guide say?) From Fredrik Lundh" <3962F313.186B10FB@lemburg.com> <007f01bfe661$68b26080$0900a8c0@SPIFF> <3962FF79.B1A773D0@lemburg.com> <02f701bfe67b$43ec51b0$0900a8c0@SPIFF> Message-ID: <007f01bfe6aa$28e52d40$f2a6b5d4@hagrid> I wrote: > A quick look indicates that Windows uses "language identifiers": > http://msdn.microsoft.com/library/psdk/winbase/nls_8xo3.htm >=20 > Maybe Bill can dig up some better way to do this (a "language > identifier to language code" table would be nice. There's one > in Windows 2000 ;-) nevermind; I've crafted a piece of code that digs out the RFC 1766 language code (e.g. en-EN) and the code page (e.g. cp1252), on Win98/NT4/2000. unfortunately, Win95 won't give me the language code; it insists on using "language identifiers" (such as 041d). guess we need a table after all. oh well. patch follows. From mal@lemburg.com Wed Jul 5 18:53:43 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 19:53:43 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> <007f01bfe661$68b26080$0900a8c0@SPIFF> <3962FF79.B1A773D0@lemburg.com> <02f701bfe67b$43ec51b0$0900a8c0@SPIFF> <007f01bfe6aa$28e52d40$f2a6b5d4@hagrid> Message-ID: <39637627.BFDA941A@lemburg.com> Fredrik Lundh wrote: > > I wrote: > > > A quick look indicates that Windows uses "language identifiers": > > http://msdn.microsoft.com/library/psdk/winbase/nls_8xo3.htm > > > > Maybe Bill can dig up some better way to do this (a "language > > identifier to language code" table would be nice. There's one > > in Windows 2000 ;-) > > nevermind; I've crafted a piece of code that digs out the RFC 1766 > language code (e.g. en-EN) and the code page (e.g. cp1252), on > Win98/NT4/2000. > > unfortunately, Win95 won't give me the language code; it insists > on using "language identifiers" (such as 041d). guess we need a > table after all. oh well. > > patch follows. Great :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Wed Jul 5 19:02:04 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 20:02:04 +0200 Subject: [Python-Dev] locale.setlocale vs. locale.set_locale References: <006a01bfe6a7$fa696000$f2a6b5d4@hagrid> Message-ID: <3963781C.DD06D0DE@lemburg.com> Fredrik Lundh wrote: > > maybe it's just me, but I think it's a bit confusing to have two > functions in the same module with very similar names: > > >>> import locale > > >>> print locale.setlocale.__doc__ > (integer,string=None) -> string. Activates/queries locale processing. > > >>> print locale.set_locale.__doc__ > Set the locale according to the localetuple (language code, > encoding) as returned by get_locale() and get_default(). > > The given codes are passed through the locale aliasing engine > before being given to setlocale() for processing. > > category may be given as one of the LC_* values. It defaults > to LC_ALL. The new set_locale() is meant to complement get_locale(); both work on tuples (langcode, encoding). setlocale() has a completely different interface: it uses a locale category integer together with a setup string. The reasoning here was to add a higher level interface on top of setlocale() which is the direct interface to the underlying low level C API. The underscore variants provide aliasing support and knows about the formats which the setlocale() API will accept -- at least on Linux setlocale() is very picky about case and layout of the setup string. > maybe "setlocale" should be changed to accept either a > string or a tuple? > > (from which follows that get_locale should be "getlocale", and > get_default "getdefaultlocale". or something...) If you want to change anything here: now is the time ;-) Please also adapt site.py which uses these APIs. > (btw, maybe both doc strings should mention the arguments? or > maybe none of them should? what does the style guide say?) I always thought that the arguments should only be mentioned for C functions... not sure, though. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Wed Jul 5 19:11:08 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 20:11:08 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) Message-ID: <39637A3C.9489CB15@lemburg.com> This is a multi-part message in MIME format. --------------FC351AC889B8145AF245DB36 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The idea is not new: strings and Unicode should have more or less the same methods to enhance their compatibility. The attached patch adds encoding capabilities to normal strings and extends the builtin str() to accept an optional encoding (and error) argument. It also tries to reuse the already available Unicode codecs for the purposes of strings (conversions are done via the default encoding in both directions). With it you can use the existing codecs to easily encode or decode strings and data into string objects: >>> 'abc'.encode('utf16') '\377\376a\000b\000c\000' >>> str(_, 'utf16') 'abc' Since the codec API and registry support more than just Unicode codecs, one could also think of things like: '...long...data...string...'.encode('data_gzip') or other complicated string conversions. The str(obj[, encoding[, errors]]) builtin does the exact opposite: it takes the string representation of obj and then decodes it using the given encoding. What do you think about this ? Should I add it to CVS as experiment ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ --------------FC351AC889B8145AF245DB36 Content-Type: text/plain; charset=us-ascii; name="str.encode.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="str.encode.patch" diff -u -rbP -x *.o -x *.pyc -x Makefile -x *~ -x *.so -x add2lib -x pgen -x buildno -x core -x config.* -x libpython* -x python -x Setup -x Setup.local -x Setup.thread -x Setup.config -x hassignal -x Makefile.pre -x configure -x *.bak -x *.s -x DEADJOE -x *.rej -x *.orig -x Demo -x CVS -x Doc -x *.orig -x .#* -x distutils -x */plat* -x *.py -x ACKS -x *.txt -x README CVS-Python/Include/stringobject.h Python+Unicode/Include/stringobject.h --- CVS-Python/Include/stringobject.h Sat Jul 1 10:30:46 2000 +++ Python+Unicode/Include/stringobject.h Wed Jul 5 18:59:46 2000 @@ -81,6 +81,37 @@ #define PyString_AS_STRING(op) (((PyStringObject *)(op))->ob_sval) #define PyString_GET_SIZE(op) (((PyStringObject *)(op))->ob_size) +/* --- Generic Codecs ----------------------------------------------------- */ + +/* Create a string object by decoding the encoded string s of the + given size. */ + +extern DL_IMPORT(PyObject*) PyString_Decode( + const char *s, /* encoded string */ + int size, /* size of buffer */ + const char *encoding, /* encoding */ + const char *errors /* error handling */ + ); + +/* Encodes a char buffer of the given size and returns a + Python string object. */ + +extern DL_IMPORT(PyObject*) PyString_Encode( + const char *s, /* string char buffer */ + int size, /* number of chars to encode */ + const char *encoding, /* encoding */ + const char *errors /* error handling */ + ); + +/* Encodes a string object and returns the result as Python string + object. */ + +extern DL_IMPORT(PyObject*) PyString_AsEncodedString( + PyObject *str, /* string object */ + const char *encoding, /* encoding */ + const char *errors /* error handling */ + ); + #ifdef __cplusplus } #endif diff -u -rbP -x *.o -x *.pyc -x Makefile -x *~ -x *.so -x add2lib -x pgen -x buildno -x core -x config.* -x libpython* -x python -x Setup -x Setup.local -x Setup.thread -x Setup.config -x hassignal -x Makefile.pre -x configure -x *.bak -x *.s -x DEADJOE -x *.rej -x *.orig -x Demo -x CVS -x Doc -x *.orig -x .#* -x distutils -x */plat* -x *.py -x ACKS -x *.txt -x README CVS-Python/Objects/stringobject.c Python+Unicode/Objects/stringobject.c --- CVS-Python/Objects/stringobject.c Wed Jul 5 11:42:49 2000 +++ Python+Unicode/Objects/stringobject.c Wed Jul 5 19:47:44 2000 @@ -152,6 +152,100 @@ return (PyObject *) op; } +PyObject *PyString_Decode(const char *s, + int size, + const char *encoding, + const char *errors) +{ + PyObject *buffer = NULL, *str; + + if (encoding == NULL) + encoding = PyUnicode_GetDefaultEncoding(); + + /* Decode via the codec registry */ + buffer = PyBuffer_FromMemory((void *)s, size); + if (buffer == NULL) + goto onError; + str = PyCodec_Decode(buffer, encoding, errors); + if (str == NULL) + goto onError; + /* Convert Unicode to a string using the default encoding */ + if (PyUnicode_Check(str)) { + PyObject *temp = str; + str = PyUnicode_AsEncodedString(str, NULL, NULL); + Py_DECREF(temp); + if (str == NULL) + goto onError; + } + if (!PyString_Check(str)) { + PyErr_Format(PyExc_TypeError, + "decoder did not return an string object (type=%.400s)", + str->ob_type->tp_name); + Py_DECREF(str); + goto onError; + } + Py_DECREF(buffer); + return str; + + onError: + Py_XDECREF(buffer); + return NULL; +} + +PyObject *PyString_Encode(const char *s, + int size, + const char *encoding, + const char *errors) +{ + PyObject *v, *str; + + str = PyString_FromStringAndSize(s, size); + if (str == NULL) + return NULL; + v = PyString_AsEncodedString(str, encoding, errors); + Py_DECREF(str); + return v; +} + +PyObject *PyString_AsEncodedString(PyObject *str, + const char *encoding, + const char *errors) +{ + PyObject *v; + + if (!PyString_Check(str)) { + PyErr_BadArgument(); + goto onError; + } + + if (encoding == NULL) + encoding = PyUnicode_GetDefaultEncoding(); + + /* Encode via the codec registry */ + v = PyCodec_Encode(str, encoding, errors); + if (v == NULL) + goto onError; + /* Convert Unicode to a string using the default encoding */ + if (PyUnicode_Check(v)) { + PyObject *temp = v; + v = PyUnicode_AsEncodedString(v, NULL, NULL); + Py_DECREF(temp); + if (v == NULL) + goto onError; + } + if (!PyString_Check(v)) { + PyErr_Format(PyExc_TypeError, + "encoder did not return a string object (type=%.400s)", + v->ob_type->tp_name); + Py_DECREF(v); + goto onError; + } + return v; + + onError: + return NULL; +} + static void string_dealloc(op) PyObject *op; @@ -1686,6 +1780,25 @@ } +static char encode__doc__[] = +"S.encode([encoding[,errors]]) -> string\n\ +\n\ +Return an encoded string version of S. Default encoding is the current\n\ +default string encoding. errors may be given to set a different error\n\ +handling scheme. Default is 'strict' meaning that encoding errors raise\n\ +a ValueError. Other possible values are 'ignore' and 'replace'."; + +static PyObject * +string_encode(PyStringObject *self, PyObject *args) +{ + char *encoding = NULL; + char *errors = NULL; + if (!PyArg_ParseTuple(args, "|ss:encode", &encoding, &errors)) + return NULL; + return PyString_AsEncodedString((PyObject *)self, encoding, errors); +} + + static char expandtabs__doc__[] = "S.expandtabs([tabsize]) -> string\n\ \n\ @@ -2252,6 +2365,7 @@ {"ljust", (PyCFunction)string_ljust, 1, ljust__doc__}, {"rjust", (PyCFunction)string_rjust, 1, rjust__doc__}, {"center", (PyCFunction)string_center, 1, center__doc__}, + {"encode", (PyCFunction)string_encode, 1, encode__doc__}, {"expandtabs", (PyCFunction)string_expandtabs, 1, expandtabs__doc__}, {"splitlines", (PyCFunction)string_splitlines, 1, splitlines__doc__}, #if 0 diff -u -rbP -x *.o -x *.pyc -x Makefile -x *~ -x *.so -x add2lib -x pgen -x buildno -x core -x config.* -x libpython* -x python -x Setup -x Setup.local -x Setup.thread -x Setup.config -x hassignal -x Makefile.pre -x configure -x *.bak -x *.s -x DEADJOE -x *.rej -x *.orig -x Demo -x CVS -x Doc -x *.orig -x .#* -x distutils -x */plat* -x *.py -x ACKS -x *.txt -x README CVS-Python/Python/bltinmodule.c Python+Unicode/Python/bltinmodule.c --- CVS-Python/Python/bltinmodule.c Tue Jul 4 10:30:50 2000 +++ Python+Unicode/Python/bltinmodule.c Wed Jul 5 19:40:14 2000 @@ -2050,18 +2050,39 @@ PyObject *self; PyObject *args; { - PyObject *v; + PyObject *v, *w; + const void *buffer; + int len; + char *encoding = NULL; + char *errors = NULL; - if (!PyArg_ParseTuple(args, "O:str", &v)) + if ( !PyArg_ParseTuple(args, "O|ss:str", &v, &encoding, &errors) ) return NULL; - return PyObject_Str(v); + + /* Get string representation */ + if (PyString_Check(v)) + Py_INCREF(v); + else + v = PyObject_Str(v); + if (encoding == NULL) + return v; + + /* Decode data raw */ + if (PyObject_AsReadBuffer(v, &buffer, &len)) + return NULL; + w = PyString_Decode((const char *)buffer, len, encoding, errors); + Py_DECREF(v); + return w; } static char str_doc[] = -"str(object) -> string\n\ +"str(object [, encoding[, errors]]) -> string\n\ \n\ -Return a nice string representation of the object.\n\ -If the argument is a string, the return value is the same object."; +Return a string representation of the object.\n\ +If the argument is a string, the return value is the same object.\n\ +If encoding is given, the string representation is decoded prior\n\ +to returning it. errors, defining the error handling for the decoding\n\ +process, defaults to 'strict'."; static PyObject * --------------FC351AC889B8145AF245DB36-- From trentm@activestate.com Wed Jul 5 19:12:20 2000 From: trentm@activestate.com (Trent Mick) Date: Wed, 5 Jul 2000 11:12:20 -0700 Subject: [Python-Dev] where did the rest of my traceback go? Message-ID: <20000705111220.A10839@activestate.com> Pardon me if this is a stupid question: Python 2.0b1 (#0, Jul 4 2000, 16:47:31) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> compile('foo=', 'foo.py', 'exec') Traceback (most recent call last): File "", line 1, in ? File "", line 1 foo= ^ SyntaxError: unexpected EOF while parsing >>> import sys, traceback >>> tb = sys.last_traceback >>> traceback.print_tb(tb) File "", line 1, in ? >>> traceback.print_stack() File "", line 1, in ? >>> Where did the rest of the stack trace go (i.e. the File "" block)? Insights appreciated, Trent -- Trent Mick trentm@activestate.com From Fredrik Lundh" Message-ID: <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> mal wrote: > The idea is not new: strings and Unicode should have more > or less the same methods to enhance their compatibility. >=20 > The attached patch adds encoding capabilities to normal > strings and extends the builtin str() to accept an optional > encoding (and error) argument. It also tries to reuse the > already available Unicode codecs for the purposes of strings > (conversions are done via the default encoding in both > directions). ... > What do you think about this ? Should I add it to CVS > as experiment ? +1 on the "encode" part -0 on the "str" part (intuitively, it's -1, but I don't have any good arguments against it right now... maybe later) From mal@lemburg.com Wed Jul 5 19:51:48 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 20:51:48 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> Message-ID: <396383C4.40390E0F@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > The idea is not new: strings and Unicode should have more > > or less the same methods to enhance their compatibility. > > > > The attached patch adds encoding capabilities to normal > > strings and extends the builtin str() to accept an optional > > encoding (and error) argument. It also tries to reuse the > > already available Unicode codecs for the purposes of strings > > (conversions are done via the default encoding in both > > directions). > > ... > > > What do you think about this ? Should I add it to CVS > > as experiment ? > > +1 on the "encode" part > > -0 on the "str" part (intuitively, it's -1, but I don't have > any good arguments against it right now... maybe later) The str() extension complements unicode() which also works as constructor for object given an encoding. Ideally, unicode() should also look for __unicode__() on instances just like str() looks for __str__(). Note that we could also have a .decode() method instead of modifying str(), but this would break symmetry to Unicode, since you can't decode Unicode into anything... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" Here's a tentative version of a mapping between windows identifiers and locale codes. There's probably bugs in here; I've tried to match data from a number of sources with=20 Microsoft's descriptions (as given in the comments). Extra bonus for filling in "??". Most notably, those norwegians caused some problems here (don't they always? ;-). I'm pretty sure one of these should be "no_NO": 0x0414: "nb_NO", # Norwegian (Bokmal) 0x0814: "nn_NO", # Norwegian (Nynorsk) But which one? Same goes for the spaniards: which one should be "es_ES"? 0x040a: "es_??", # Spanish (Traditional Sort) 0x0c0a: "es_??", # Spanish (Modern Sort) thanks /F # # Map Windows language code to ISO 3166/ISO 639 code. This is only # used on older Windows platforms (Windows 95, most notable). # # NOTE: this table isn't complete. If you have time and knowledge, # please fill in the missing mappings (marked with ??) and send to # the Python core team (or directly to effbot@telia.com). # # Thanks /F windows_lang =3D { 0x0436: "af_AF", # Afrikaans 0x041c: "sq_AL", # Albanian 0x0401: "ar_SA", # Arabic (Saudi Arabia) 0x0801: "ar_IQ", # Arabic (Iraq) 0x0c01: "ar_EG", # Arabic (Egypt) 0x1001: "ar_LY", # Arabic (Libya) 0x1401: "ar_DZ", # Arabic (Algeria) 0x1801: "ar_MA", # Arabic (Morocco) 0x1c01: "ar_TN", # Arabic (Tunisia) 0x2001: "ar_OM", # Arabic (Oman) 0x2401: "ar_YE", # Arabic (Yemen) 0x2801: "ar_SY", # Arabic (Syria) 0x2c01: "ar_JO", # Arabic (Jordan) 0x3001: "ar_LB", # Arabic (Lebanon) 0x3401: "ar_KW", # Arabic (Kuwait) 0x3801: "ar_AE", # Arabic (U.A.E.) 0x3c01: "ar_BH", # Arabic (Bahrain) 0x4001: "ar_QA", # Arabic (Qatar) 0x042b: "hy_AM", # Armenian 0x044d: "as_??", # Assamese 0x042c: "az_AZ", # Azeri (Latin) 0x082c: "az_??", # Azeri (Cyrillic) 0x042d: "eu_ES", # Basque 0x0423: "be_BY", # Belarussian 0x0445: "bn_??", # Bengali 0x0402: "bg_BG", # Bulgarian 0x0455: "my_MM", # Burmese 0x0403: "ca_ES", # Catalan 0x0404: "zh_TW", # Chinese (Taiwan) 0x0804: "zh_CN", # Chinese (PRC) 0x0c04: "zh_HK", # Chinese (Hong Kong SAR, PRC) 0x1004: "zh_SG", # Chinese (Singapore) 0x1404: "zh_MO", # Chinese (Macau SAR) 0x041a: "hr_HR", # Croatian (Hrvatska) 0x0405: "cs_CZ", # Czech 0x0406: "da_DK", # Danish 0x0413: "nl_NL", # Dutch (Netherlands) 0x0813: "nl_BE", # Dutch (Belgium) 0x0409: "en_US", # English (United States) 0x0809: "en_UK", # English (United Kingdom) 0x0c09: "en_AU", # English (Australian) 0x1009: "en_CA", # English (Canadian) 0x1409: "en_NZ", # English (New Zealand) 0x1809: "en_IE", # English (Ireland) 0x1c09: "en_ZA", # English (South Africa) 0x2009: "en_JM", # English (Jamaica) 0x2409: "en_??", # English (Caribbean) 0x2809: "en"_BZ, # English (Belize) 0x2c09: "en_TT", # English (Trinidad) 0x3009: "en_ZW", # English (Zimbabwe) 0x3409: "en_PH", # English (Philippines) 0x0425: "et_EE", # Estonian 0x0438: "fo_FO", # Faeroese 0x0429: "fa_IR", # Farsi 0x040b: "fi_FI", # Finnish 0x040c: "fr_FR", # French (Standard) 0x080c: "fr_BE", # French (Belgian) 0x0c0c: "fr_CA", # French (Canadian) 0x100c: "fr_CH", # French (Switzerland) 0x140c: "fr_LU", # French (Luxembourg) 0x180c: "fr_MC", # French (Monaco) 0x0437: "ka_GE", # Georgian 0x0407: "de_DE", # German (Standard) 0x0807: "de_CH", # German (Switzerland) 0x0c07: "de_AT", # German (Austria) 0x1007: "de_LU", # German (Luxembourg) 0x1407: "de_LI", # German (Liechtenstein) 0x0408: "el_GR", # Greek 0x0447: "gu_??", # Gujarati 0x040d: "iw_IL", # Hebrew 0x0439: "hi_IN", # Hindi 0x040e: "hu_HU", # Hungarian 0x040f: "is_IS", # Icelandic 0x0421: "id_ID", # Indonesian 0x0410: "it_IT", # Italian (Standard) 0x0810: "it_CH", # Italian (Switzerland) 0x0411: "ja_JA", # Japanese 0x044b: "kn_??", # Kannada 0x0860: "ks_IN", # Kashmiri (India) 0x043f: "kk_??", # Kazakh 0x0457: "??_??", # Konkani 0x0412: "ko_??", # Korean 0x0812: "ko_??", # Korean (Johab) 0x0426: "lv_LV", # Latvian 0x0427: "lt_LT", # Lithuanian 0x0827: "lt_??", # Lithuanian (Classic) 0x042f: "mk_MK", # Macedonian 0x043e: "ms_MY", # Malay (Malaysian) 0x083e: "ms_??", # Malay (Brunei Darussalam) 0x044c: "ml_??", # Malayalam 0x0458: "??_??", # Manipuri 0x044e: "mr_??", # Marathi 0x0861: "ne_IN", # Nepali (India) 0x0414: "nb_NO", # Norwegian (Bokmal) 0x0814: "nn_NO", # Norwegian (Nynorsk) 0x0448: "or_??", # Oriya 0x0415: "pl_PL", # Polish 0x0416: "pt_BR", # Portuguese (Brazil) 0x0816: "pt_PT", # Portuguese (Standard) 0x0446: "pa_??", # Punjabi 0x0418: "ro_RO", # Romanian 0x0419: "ru_RU", # Russian 0x044f: "sa_??", # Sanskrit 0x0c1a: "sr_??", # Serbian (Cyrillic) 0x081a: "sr_??", # Serbian (Latin) 0x0459: "sd_??", # Sindhi 0x041b: "sk_??", # Slovak 0x0424: "sl_SL", # Slovenian 0x040a: "es_??", # Spanish (Traditional Sort) 0x080a: "es_MX", # Spanish (Mexican) 0x0c0a: "es_??", # Spanish (Modern Sort) 0x100a: "es_GT", # Spanish (Guatemala) 0x140a: "es_??", # Spanish (Costa Rica) 0x180a: "es_PA", # Spanish (Panama) 0x1c0a: "es_DO", # Spanish (Dominican Republic) 0x200a: "es_VE", # Spanish (Venezuela) 0x240a: "es_CO", # Spanish (Colombia) 0x280a: "es_PE", # Spanish (Peru) 0x2c0a: "es_AR", # Spanish (Argentina) 0x300a: "es_EC", # Spanish (Ecuador) 0x340a: "es_CL", # Spanish (Chile) 0x380a: "es_UY", # Spanish (Uruguay) 0x3c0a: "es_PY", # Spanish (Paraguay) 0x400a: "es_BO", # Spanish (Bolivia) 0x440a: "es_SV", # Spanish (El Salvador) 0x480a: "es_HN", # Spanish (Honduras) 0x4c0a: "es_NI", # Spanish (Nicaragua) 0x500a: "es_PR", # Spanish (Puerto Rico) 0x0430: "??_??", # Sutu 0x0441: "sw_KE", # Swahili (Kenya) 0x041d: "sv_SE", # Swedish 0x081d: "sv_FI", # Swedish (Finland) 0x0449: "ta_??", # Tamil 0x0444: "tt_??", # Tatar (Tatarstan) 0x044a: "te_??", # Telugu 0x041e: "th_TH", # Thai 0x041f: "tr_TR", # Turkish 0x0422: "tk_UA", # Ukrainian 0x0420: "ur_PK", # Urdu (Pakistan) 0x0820: "ur_IN", # Urdu (India) 0x0443: "uz_UZ", # Uzbek (Latin) 0x0843: "uz_??", # Uzbek (Cyrillic) 0x042a: "vi_VN", # Vietnamese } From Ka-Ping Yee Wed Jul 5 20:20:41 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Wed, 5 Jul 2000 12:20:41 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <200007051229.OAA19526@python.inrialpes.fr> Message-ID: On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > Looks fine. +1 on the concept. Yay! > > SyntaxError: expected indent here > > I'd remove the word "here" so that the error msg is self-contained. > "expected indent" & "expected dedent" are fine. Fine with me (more on messages below). > > 4. Added int *expected_ret argument to PyParser_AddToken; on > > a syntax error, PyParser_AddToken (in parser.c) places the > > expected token type (if any) into this output parameter. > > I'd suggest passing a pointer to the perrdetail structure (to the > whole error, that is), instead of a pointer to one of its fields. I did consider that; the reason i eventually decided against it is that munging perrdetail appears to be [parsetok.c] parsetok()'s responsibility, not [parser.c] PyParser_AddToken()'s. The latter doesn't mess with any of the other fields of perrdetail -- and it returns an error code which becomes err_ret->error, so passing in perrdetail gives PyParser_AddToken() two ways of returning the same information. The redundancy and possible future confusion didn't seem worth it. Another alternative is to change the return value so it *isn't* an error code (only a success/fail flag) and then rely on the error code in err_ret->error. I guess if you see a compelling reason for this i don't mind doing it. But is there one? Greg Wilson wrote: > I just did a poll --- only 2 out of 5 programmers in my shouting radius > know what "dedent" means. Is there a more accessible way to phrase the > error message? Indeed. Sorry about that -- i should have realized that it's a fairly cryptic term. "Dedent" seems to have become a standard term within the C code; perhaps we can allow "dedent" in the C code and standardize on "unindent" outside? How about this set of messages, then: SyntaxError: unexpected indent SyntaxError: unexpected unindent SyntaxError: expected indent SyntaxError: expected unindent SyntaxError: unindent did not match any outer indentation level SyntaxError: inconsistent use of tabs and spaces in indentation SyntaxError: too many levels of indentation Hmm. For the record, the section of the reference manual about indentation talks about INDENT and DEDENT tokens. In fact i don't think there's any mention of the word "unindent" in the Python documentation. But outside of the Python docs, "unindent" is clearly a commonly used and understood term in general practice, much more so than "dedent". -- ?!ng From Fredrik Lundh" Message-ID: <01ac01bfe6ba$8c1ed680$f2a6b5d4@hagrid> fred wrote: > There are two things that can be done: have distutils always use > -tt when compiling code that gets installed (using a child interpreter > if needed), that's reasonable. > and setting -tt as the default in the next Python release. where "next" is Py3K, I hope. breaking an unknown amount of existing libraries and code samples, just for the sake of it, isn't exactly a great way to promote Python... From Fredrik Lundh" <20000705062434.A18614@thyrsus.com> Message-ID: <01f001bfe6bb$5198bb60$f2a6b5d4@hagrid> eric wrote: > > > Tim's source is correct. =20 > >=20 > > Tim? Do you mean /F? >=20 > I believe /F was quoting Tim. nope. not that it matters much; that economist style guide seem to override it anyway ;-) From martin@loewis.home.cs.tu-berlin.de Wed Jul 5 21:25:17 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed, 5 Jul 2000 22:25:17 +0200 Subject: [Python-Dev] help wanted: windows locales Message-ID: <200007052025.WAA01309@loewis.home.cs.tu-berlin.de> > I'm pretty sure one of these should be "no_NO": > 0x0414: "nb_NO", # Norwegian (Bokmal) > 0x0814: "nn_NO", # Norwegian (Nynorsk) > But which one? Looking at http://lcweb.loc.gov/standards/iso639-2/englangn.html, it seems the answer is "neither". I believe "no_NO" is used for traditional Norwegian on many systems (that would be Bokmål, right?). On a number of Unix systems (Linux, Solaris), Nynorsk is requested by appending "@nynorsk" to $LANG, e.g. no@nynorsk (Linux), no_NO.ISO8859-1@nynorsk (Solaris). The latter also recognizes no_NY for Nynorsk, but that doesn't sound too official. It seems that ISO 639-2:1998 isn't that widely implemented; is anybody actually using nn/nb? Regards, Martin From gstein@lyra.org Wed Jul 5 21:42:30 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 5 Jul 2000 13:42:30 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14691.8786.180085.468266@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 05, 2000 at 07:56:02AM -0400 References: <20000703233938.N29590@lyra.org> <14691.8786.180085.468266@anthem.concentric.net> Message-ID: <20000705134230.C12873@lyra.org> On Wed, Jul 05, 2000 at 07:56:02AM -0400, Barry A. Warsaw wrote: > >>>>> "GS" == Greg Stein writes: > GS> (add-hook 'python-mode-hook > | (lambda () > | (setq indent-tabs-mode nil) > | (setq py-indent-offset 2) > | (setq py-smart-indentation nil) > | (define-key py-mode-map "\e\C-h" 'backward-kill-word) > | )) > > GS> The indent-tabs-mode is the key to disabling tab characters > GS> and using just spaces. > > Greg, can you explain why you turn off py-smart-indentation? Its > purpose is to give you the correct settings when editing someone > else's existing code. With this variable set to t, it tries to guess > the existing code's indentation level depth and then sets > py-indent-offset to that value, on the assumption that > > 1) the original author indented their code consistently > > 2) it is better to be consistent with the existing indentation than > impose your own and have mixed indentation > > Both of these are worthy goals, IMO, so py-smart-indentation should > generally remain true. The goal is fine, and I agree with it. However, it was guessing the wrong tab for me at some point, and so I just turned it off. That's the way I have it; other people probably don't want to do that. *shrug* Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw@beopen.com Wed Jul 5 21:48:41 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 16:48:41 -0400 (EDT) Subject: [Python-Dev] Making -tt the default References: <20000703233938.N29590@lyra.org> <14691.8786.180085.468266@anthem.concentric.net> <20000705134230.C12873@lyra.org> Message-ID: <14691.40745.724265.337058@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> The goal is fine, and I agree with it. However, it was GS> guessing the wrong tab for me at some point, and so I just GS> turned it off. GS> That's the way I have it; other people probably don't want to GS> do that. No problem, 'cause you're already setting indent-tabs-mode in your hook. -Barry From jack@oratrix.nl Wed Jul 5 21:53:26 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 05 Jul 2000 22:53:26 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c Message-ID: <20000705205331.E8BCDE2673@oratrix.oratrix.nl> Is anyone else experiencing problems with the immense new switch in unicodectype.c? Trying to compile it crashes my machine(!)... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From mal@lemburg.com Wed Jul 5 22:09:53 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 23:09:53 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <20000705205331.E8BCDE2673@oratrix.oratrix.nl> Message-ID: <3963A421.35A7F989@lemburg.com> Jack Jansen wrote: > > Is anyone else experiencing problems with the immense new switch in > unicodectype.c? Trying to compile it crashes my machine(!)... It compiles fine on my Linux machine using gcc. The output is a 114k .o file (including debug information). Do you have similar problems with ceval.c ? If yes, I could break the switch in two using the same flag as in ceval.c. If not, please give some compiler details, so that I can switch on those. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one@email.msn.com Wed Jul 5 22:42:37 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 17:42:37 -0400 Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <20000705205331.E8BCDE2673@oratrix.oratrix.nl> Message-ID: [posted & mailed] [Jack Jansen] > Is anyone else experiencing problems with the immense new switch in > unicodectype.c? Trying to compile it crashes my machine(!)... No problem here, but it needs to be fixed for you! There's no future in pushing anyone's compiler limits, and particularly not when Python is attracting more attention on smaller platforms (read feebler compilers, among others gotchas). I believe we also need a way to split unicodedatabase.c into multiple files, as > 64K lines in a source file is unreasonable (Python can't handle a source file that large either, and Python is the *definition* of reasonableness here ), and the MS compiler spits out a warning about its sheer size. Or was Christian's long-threatened compression patch supposed to reduce the line count in that one? From Fredrik Lundh" Message-ID: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> tim wrote: > [Jack Jansen] > > Is anyone else experiencing problems with the immense new switch in > > unicodectype.c? Trying to compile it crashes my machine(!)... >=20 > No problem here, but it needs to be fixed for you! There's no future = in > pushing anyone's compiler limits, and particularly not when Python is > attracting more attention on smaller platforms (read feebler = compilers, > among others gotchas). both modules can be squeezed down to almost nothing. it just takes a little work. fwiw, Tcl's version of the unicodectype file is about 30k, and compiles to an 8k large object file on my win95 box. if nobody else fixes this, I'll do something about it before 2.0 final. promise. cheers /F From mal@lemburg.com Wed Jul 5 23:19:38 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 00:19:38 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: Message-ID: <3963B47A.638A7A82@lemburg.com> Tim Peters wrote: > > [posted & mailed] > > [Jack Jansen] > > Is anyone else experiencing problems with the immense new switch in > > unicodectype.c? Trying to compile it crashes my machine(!)... > > No problem here, but it needs to be fixed for you! There's no future in > pushing anyone's compiler limits, and particularly not when Python is > attracting more attention on smaller platforms (read feebler compilers, > among others gotchas). > > I believe we also need a way to split unicodedatabase.c into multiple files, > as > 64K lines in a source file is unreasonable (Python can't handle a > source file that large either, and Python is the *definition* of > reasonableness here ), and the MS compiler spits out a warning about > its sheer size. > > Or was Christian's long-threatened compression patch supposed to reduce the > line count in that one? Both the line count and the memory consumption... the same can be done for unicodectype.c -- but I don't have the time to look into this, so for now all I can offer is to split the huge switch in two if that helps. BTW, if your compiler supports Unicode (that is provides a working wctype.h file), you can compile Python using the compile time switch --with-wctype-functions. Python will then use the C libs iswXXX() APIs which should return more or less the same values as the Python ones (could be that the C lib is Unicode 2.0 -- so YMMV). Note that this hasn't been tested much yet. Feedback is welcome. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gward@mems-exchange.org Wed Jul 5 23:30:46 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 18:30:46 -0400 Subject: [Python-Dev] ExtensionClass and __radd__()? Message-ID: <20000705183046.A26381@ludwig.cnri.reston.va.us> Hi all -- looks like ExtensionClass doesn't recognize/implement the '__radd__()' protocol. Speculation below; first, a demonstration. Normal case: a regular class Number that knows how to add itself to other number-like things: class Number: def __init__ (self, n): self.n = n def __str__ (self): return str(self.n) def __add__ (self, other): return self.n + other __radd__ = __add__ n = Number(37) print n, n + 5, 5 + n The output of this is exactly what you'd expect: 37 42 42 (I have convinced myself that '__radd__()' is called in the "5 + n" case by writing a separate '__radd__()' with a print statement. Everything is sane!) Now the same thing as an ExtensionClass: from ExtensionClass import Base class ECNumber (Base): def __init__ (self, n): self.n = n def __str__ (self): return str(self.n) def __add__ (self, other): return self.n + other __radd__ = __add__ ecn = ECNumber(37) print ecn, ecn + 5, 5 + ecn The output of this is puzzling, to say the least: 37 42 134883149 IOW, "5 + ecn" evaluates to 134883149 -- that's a plain int, I checked with 'type()' on it. If I put this code: print id(ecn), id(5), id(ECNumber), id(Base), id(ExtensionClass) immediately after the last print, I get 135530536 135220848 135568720 1075195712 1075195488 ... which just tells me that the result of "5 + ecn" looks a lot like an id(), but isn't the id() of anything obvious. (Or 5 + any obvious id().) Happens the same with the ExtensionClass code from Zope 2.1.5 or 2.2beta1, and with Python 1.5.2 and the latest CVS Python. Speculation time: I'm guessing that this is similar to the problem with 'isinstance()' and ExtensionClass that I found several months ago, which was heroically debugged by Barry. To recap, it's a mutual finger-pointing bug: Python (Guido) can claim that it's up to ExtensionClass (Jim) to emulate the full semantics of Python classes/instances, but ExtensionClass can claim that Python should be more relaxed in what it accepts as a "class object" or "instance object". I think the relevant code in Python is in Objects/abstract.c, specifically 'PyNumber_Add()' and the BINOP macro: #define BINOP(v, w, opname, ropname, thisfunc) \ if (PyInstance_Check(v) || PyInstance_Check(w)) \ return PyInstance_DoBinOp(v, w, opname, ropname, thisfunc) [...] PyNumber_Add(v, w) PyObject *v, *w; { PySequenceMethods *m; BINOP(v, w, "__add__", "__radd__", PyNumber_Add); [...] My guess is that PyInstance_Check() returns false for ExtensionClass instances. Two possible fixes: loosen up PyInstance_Check(), or loosen up BINOP. Well, it's a nice theory. It doesn't explain why '__add__()' works for ExtensionClass while '__radd__()' does not; perhaps ExtensionClass implements that much of Python's class semantics, but doesn't go as far as '__radd__()'. Other opinions? Greg From gward@mems-exchange.org Wed Jul 5 23:33:53 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 18:33:53 -0400 Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: ; from pingster@ilm.com on Wed, Jul 05, 2000 at 12:20:41PM -0700 References: <200007051229.OAA19526@python.inrialpes.fr> Message-ID: <20000705183353.B7564@ludwig.cnri.reston.va.us> On 05 July 2000, Ka-Ping Yee said: > How about this set of messages, then: > > SyntaxError: unexpected indent > SyntaxError: unexpected unindent How about "did not expect indent" and "did not expect unindent" -- reads a little easier to my eyes. > SyntaxError: expected indent > SyntaxError: expected unindent > SyntaxError: unindent did not match any outer indentation level > SyntaxError: inconsistent use of tabs and spaces in indentation > SyntaxError: too many levels of indentation Good. > Hmm. For the record, the section of the reference manual about > indentation talks about INDENT and DEDENT tokens. In fact i don't > think there's any mention of the word "unindent" in the Python > documentation. But outside of the Python docs, "unindent" is > clearly a commonly used and understood term in general practice, > much more so than "dedent". I don't think too many newbies read the reference manual (or the parser source, for that matter). Stick to clear, simple, plain-English terms in error messages, even if they are different from (not inconsistent with!) what's in the formal docs. Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From gward@mems-exchange.org Wed Jul 5 23:45:48 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 18:45:48 -0400 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <018a01bfe59f$da814950$0900a8c0@SPIFF>; from fredrik@pythonware.com on Tue, Jul 04, 2000 at 12:08:50PM +0200 References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> Message-ID: <20000705184548.C7564@ludwig.cnri.reston.va.us> On 04 July 2000, Fredrik Lundh said: > > to Python.h. This enables all features available for the > > gcc compiler including _XOPEN_SOURCE and fixes warnings > > related to missing prototypes. > > > > Thoughts ? Would this hurt anybody ? > > what does "fixes warnings" mean? does it change the compiler's > behaviour, or does it just make sure stuff are defined in the right > files? Just like MAL said, it fixes warnings from missing prototypes. Eg. the (I think) on Linux (glibc 2.x, at least) doesn't declare 'strptime()' unless __USE_XOPEN is true. (__USE_XOPEN is defined if _XOPEN_SOURCE is defined, by .) > +1 on _XOPEN_SOURCE > +0 on _GNU_SOURCE Agreed, unless someone can explain a) what _GNU_SOURCE adds that _XOPEN_SOURCE does not, and b) why that's necessary (if so). Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From mal@lemburg.com Wed Jul 5 23:53:08 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 00:53:08 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <20000705184548.C7564@ludwig.cnri.reston.va.us> Message-ID: <3963BC54.5B49AD72@lemburg.com> Greg Ward wrote: > > On 04 July 2000, Fredrik Lundh said: > > > to Python.h. This enables all features available for the > > > gcc compiler including _XOPEN_SOURCE and fixes warnings > > > related to missing prototypes. > > > > > > Thoughts ? Would this hurt anybody ? > > > > what does "fixes warnings" mean? does it change the compiler's > > behaviour, or does it just make sure stuff are defined in the right > > files? > > Just like MAL said, it fixes warnings from missing prototypes. Eg. the > (I think) on Linux (glibc 2.x, at least) doesn't declare > 'strptime()' unless __USE_XOPEN is true. (__USE_XOPEN is defined if > _XOPEN_SOURCE is defined, by .) > > > +1 on _XOPEN_SOURCE > > +0 on _GNU_SOURCE > > Agreed, unless someone can explain a) what _GNU_SOURCE adds that > _XOPEN_SOURCE does not, and b) why that's necessary (if so). It's already checked in, but since you asked: _GNU_SOURCE defines one symbol which is essential on Linux to get at a bunch of BSD/SysV API prototypes which _XOPEN_SOURCE doesn't activate. Time support is one area where this is needed, I found tmpnam_r() to be another one. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip@mojam.com (Skip Montanaro) Thu Jul 6 00:00:33 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 5 Jul 2000 18:00:33 -0500 (CDT) Subject: [Python-Dev] dismantle CVS repository on cvs.python.org? Message-ID: <14691.48657.899199.497977@beluga.mojam.com> Is it time to disable anonymous CVS access from cvs.python.org? On one of my machines I was still referring to it, but only noticed today because the build still said "1.6...". Best would be if there was some way to get it to spit out an error message that referred people to either the python.org web site or the SourceForge repository web site. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From guido@beopen.com Thu Jul 6 01:15:13 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 19:15:13 -0500 Subject: [Python-Dev] dismantle CVS repository on cvs.python.org? In-Reply-To: Your message of "Wed, 05 Jul 2000 18:00:33 EST." <14691.48657.899199.497977@beluga.mojam.com> References: <14691.48657.899199.497977@beluga.mojam.com> Message-ID: <200007060015.TAA06841@cj20424-a.reston1.va.home.com> > Is it time to disable anonymous CVS access from cvs.python.org? On one of > my machines I was still referring to it, but only noticed today because the > build still said "1.6...". Best would be if there was some way to get it to > spit out an error message that referred people to either the python.org web > site or the SourceForge repository web site. Yes -- it was left on by mistake. However CNRI currently doesn't let us modify the python.org site. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Thu Jul 6 00:15:39 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 5 Jul 2000 18:15:39 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... Message-ID: <14691.49563.78765.683762@beluga.mojam.com> Was there a public announcement made about new functionality for 2.0? I had submitted list comprehensions to the old 1.6 cycle, and it was being held to the now never-to-be 1.7. Are we in feature freeze for 2.0 at this point? I can do one of three things: * commit the changes I have currently against the CVS repository * bundle up another patch for people to examine and comment on * shut up and go do something more useful Skip From skip@mojam.com (Skip Montanaro) Thu Jul 6 00:18:51 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 5 Jul 2000 18:18:51 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? Message-ID: <14691.49755.365679.923078@beluga.mojam.com> Along the same lines, I have some pretty simple mods to readline.c and rlcompleter.py that use atexit to automatically save the current history to the file identified by the PYTHONHISTORY environment variable. (If unset, no history read/write is done). If we aren't in feature freeze, I'd like to check it in. Skip From Fredrik Lundh" Message-ID: <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> skip wrote: > Are we in feature freeze for 2.0 at this point? hopefully. > I can do one of three things: >=20 > * commit the changes I have currently against the CVS repository >=20 > * bundle up another patch for people to examine and comment on I'd vote for the second alternative. > * shut up and go do something more useful nope. that's what I'm going to do. cheers /F From jeremy@beopen.com Thu Jul 6 00:41:05 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 5 Jul 2000 19:41:05 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14691.49563.78765.683762@beluga.mojam.com> References: <14691.49563.78765.683762@beluga.mojam.com> Message-ID: <14691.51089.280721.161530@bitdiddle.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> Was there a public announcement made about new functionality for SM> 2.0? I had submitted list comprehensions to the old 1.6 cycle, SM> and it was being held to the now never-to-be 1.7. Are we in SM> feature freeze for 2.0 at this point? SM> I can do one of three things: SM> * commit the changes I have currently against the CVS SM> repository SM> * bundle up another patch for people to examine and comment SM> on SM> * shut up and go do something more useful At lunch today, Guido raised almost the same question! Tim and I argued that we should continue the feature freeze, and spend any extra time wasted while we wait for CNRI to quit stalling to resolve open bugs and do more testing. It's been a long time since the last bug fix release, and there are already a lot of new features. We'd probably be best served by working hard to make 2.0 stable and solid -- and then getting 2.1 released quickly. Jeremy From guido@beopen.com Thu Jul 6 01:42:24 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 19:42:24 -0500 Subject: [Python-Dev] list comprehensions again... In-Reply-To: Your message of "Wed, 05 Jul 2000 18:15:39 EST." <14691.49563.78765.683762@beluga.mojam.com> References: <14691.49563.78765.683762@beluga.mojam.com> Message-ID: <200007060042.TAA06919@cj20424-a.reston1.va.home.com> > Was there a public announcement made about new functionality for > 2.0? Yes, there's something on http://pythonlabs.com/tech/python2.html. We currently can't commit to a release schedule due to the problems with CNRI. > I had > submitted list comprehensions to the old 1.6 cycle, and it was being held to > the now never-to-be 1.7. Are we in feature freeze for 2.0 at this point? That's up for debate. Reversing our usual good-cop-bad-cop roles, Tim Peters is for a feature freeze while I am for adding more features to 2.0 to make it stand apart. :-) > I can do one of three things: > > * commit the changes I have currently against the CVS repository > > * bundle up another patch for people to examine and comment on > > * shut up and go do something more useful It's not wise to commit changes without agreement on whether they should be applied... Anyway, the patches are currently in Tim Peters' court. Are your changes different from what's already in the patch manager for list comprehensions? If so, you should probably upload a revised patch... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Thu Jul 6 01:44:15 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 19:44:15 -0500 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: Your message of "Wed, 05 Jul 2000 18:18:51 EST." <14691.49755.365679.923078@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> Message-ID: <200007060044.TAA08483@cj20424-a.reston1.va.home.com> > Along the same lines, I have some pretty simple mods to readline.c and > rlcompleter.py that use atexit to automatically save the current history to > the file identified by the PYTHONHISTORY environment variable. (If unset, > no history read/write is done). If we aren't in feature freeze, I'd like to > check it in. To ease review of the patch, why don't you upload it? Does the patch also load the history at start time? That would be useful... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gward@mems-exchange.org Thu Jul 6 01:00:44 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 20:00:44 -0400 Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <14690.56733.627266.907044@temoleh.chem.uu.nl>; from rob@hooft.net on Wed, Jul 05, 2000 at 09:02:53AM +0200 References: <14690.56733.627266.907044@temoleh.chem.uu.nl> Message-ID: <20000705200043.D7564@ludwig.cnri.reston.va.us> On 05 July 2000, Rob W. W. Hooft said: > Then 2 points on distutils: > - the word "licence" is used throughout, and "license" is introduced as > alternative. The other way around looks more natural to me. In American English, "license" is both noun and verb. In the rest of the world, "licence" is the noun and "license" the verb. Hence, I might license you to use my software with the GNU General Public Licence. (Except that the FSF is American, so they don't use "licence". Oops.) Alternately: when I moved to the US, I traded in my Canadian driver's licence for an American license. (Except that I lived in Quebec, and had a permis de conduire. Oops again!) I am not American, so I do not use American English in source code or documentation, and strive to avoid it in everyday speech. ;-) If an overwhelming majority insists on American spellings in source code, command-line options, documentation, and the like, then I *might* give in, but only reluctantly. There is more than one way to use the English language, and just because the most populous (and richest, and most heavily-armed, etc.) English-speaking nation does it one way doesn't mean we should all do it that way. Bottom line: when used as a noun, "licence" and "license" should be accepted equally. This is currently the case on the Distutils command-line, but I'm not sure if it holds in the setup script. Will check. > - the term "anal retentives" should probably be replaced before 2.0 Oh c'mon, if it's just in *comments* is anyone really going to be offended? Where is it, anyways? Anyways, why is the guy who combs the source code looking for spelling errors complaining about the use of "anal retentive"? Perhaps it cuts a little close to home? >evil grin< (Sorry, that was uncalled for -- but irresistable. Nothing personal, of course!) Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From fdrake@beopen.com Thu Jul 6 01:21:14 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 20:21:14 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14691.49755.365679.923078@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> Message-ID: <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > Along the same lines, I have some pretty simple mods to readline.c and > rlcompleter.py that use atexit to automatically save the current history to > the file identified by the PYTHONHISTORY environment variable. (If unset, Skip, "bash" doesn't make me set a variable to control saving of history to ~/.bash_history; I'd be perfectly happy if Python wrote ~/.python_history by default, and simply allowed me to turn it off somehow (either from my $PYTHONSTARTUP script or a separate environment variable). There should be a reasonable default size to the history (say, 2000 lines ;), and a way to set that as well. Perhaps this is reasonable: in rlcompleter (or whereever this stuff goes), have a variable history_size that is set based on $PYTHONHISTORYSIZE if set, or 2000 if not. If the variable is set to 0, there is no history saving (or loading), and non-numeric values (like "true" ;) mean "use the default" (which is at least 2000 ;). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Thu Jul 6 01:27:20 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 20:27:20 -0400 (EDT) Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <20000705200043.D7564@ludwig.cnri.reston.va.us> References: <14690.56733.627266.907044@temoleh.chem.uu.nl> <20000705200043.D7564@ludwig.cnri.reston.va.us> Message-ID: <14691.53864.55446.173589@cj42289-a.reston1.va.home.com> Greg Ward writes: > Bottom line: when used as a noun, "licence" and "license" should be > accepted equally. This is currently the case on the Distutils > command-line, but I'm not sure if it holds in the setup script. Will If it's a keyword parameter, use it with exactly one spelling and document it that way. If packagers can't read the distutils documentation, too bad. I'll hold my comments on which is the right way to spell "license". ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@beopen.com Thu Jul 6 02:48:29 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 20:48:29 -0500 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: Your message of "Wed, 05 Jul 2000 20:21:14 -0400." <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> Message-ID: <200007060148.UAA10852@cj20424-a.reston1.va.home.com> > Skip Montanaro writes: > > Along the same lines, I have some pretty simple mods to readline.c and > > rlcompleter.py that use atexit to automatically save the current history to > > the file identified by the PYTHONHISTORY environment variable. (If unset, [Fred] > Skip, > "bash" doesn't make me set a variable to control saving of history > to ~/.bash_history; I'd be perfectly happy if Python wrote > ~/.python_history by default, and simply allowed me to turn it off > somehow (either from my $PYTHONSTARTUP script or a separate > environment variable). There should be a reasonable default size to > the history (say, 2000 lines ;), and a way to set that as well. > Perhaps this is reasonable: in rlcompleter (or whereever this stuff > goes), have a variable history_size that is set based on > $PYTHONHISTORYSIZE if set, or 2000 if not. If the variable is set to > 0, there is no history saving (or loading), and non-numeric values > (like "true" ;) mean "use the default" (which is at least 2000 ;). On the other hand, bash reads .profile and .bashrc and a few other files by default, while Python reads such a file only when $PYTHONSTARTUP is set. I actually like this. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake@beopen.com Thu Jul 6 02:04:41 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 21:04:41 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060148.UAA10852@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> <200007060148.UAA10852@cj20424-a.reston1.va.home.com> Message-ID: <14691.56105.43228.613238@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > On the other hand, bash reads .profile and .bashrc and a few other > files by default, while Python reads such a file only when > $PYTHONSTARTUP is set. I actually like this. Fair enough, though I'd be happy to change that as well. :) So perhaps $PYTHONHISTORY should specify the file name, and the filename and size can also be set from the $PYTHONSTARTUP script if desired, and a function call can be made to load the history? I'd prefer to *only* need to add a line or two to my $PYTHONSTARTUP script, and not set yet more environment variables, if at all possible. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip@mojam.com (Skip Montanaro) Thu Jul 6 00:57:29 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 5 Jul 2000 18:57:29 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007060042.TAA06919@cj20424-a.reston1.va.home.com> References: <14691.49563.78765.683762@beluga.mojam.com> <200007060042.TAA06919@cj20424-a.reston1.va.home.com> Message-ID: <14691.52073.836046.104252@beluga.mojam.com> Guido> Are your changes different from what's already in the patch Guido> manager for list comprehensions? If so, you should probably Guido> upload a revised patch... Nope. I only remembered them today when I executed "cvs update" and saw all those "M"s... Skip From tim_one@email.msn.com Thu Jul 6 02:27:48 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 21:27:48 -0400 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack Message-ID: Twice in ceval.c, and once in object.c, there's code referencing PyOS_CheckStack under the control of the preprocessor symbol USE_STACKCHECK. There's nothing in the std distribution that could possibly define either of those names. Why are they there? If nobody objects, I'll get rid of this code! PS for Jeremy: the mechanism I was thinking of is _ts.recursion_depth, which is used cross-platform in ceval.c, like so: if (++tstate->recursion_depth > MAX_RECURSION_DEPTH) { --tstate->recursion_depth; PyErr_SetString(PyExc_RuntimeError, "Maximum recursion depth exceeded"); tstate->frame = f->f_back; Py_DECREF(f); return NULL; } The effectiveness of this is dependent on guessing a good value (per platform) for MAX_RECURSION_DEPTH (and it's broken under Windows in 1.5.2). From skip@mojam.com (Skip Montanaro) Thu Jul 6 00:58:55 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 5 Jul 2000 18:58:55 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060044.TAA08483@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <200007060044.TAA08483@cj20424-a.reston1.va.home.com> Message-ID: <14691.52159.562929.565934@beluga.mojam.com> Guido> To ease review of the patch, why don't you upload it? Will do. Guido> Does the patch also load the history at start time? That would Guido> be useful... That's the whole idea... ;-) Skip From tim_one@email.msn.com Thu Jul 6 02:37:11 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 21:37:11 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007060042.TAA06919@cj20424-a.reston1.va.home.com> Message-ID: Oh, all right, I'll address this now: > It's not wise to commit changes without agreement on whether they > should be applied... Anyway, the patches are currently in Tim Peters' > court. I think that speaks for itself: immediately after ESR praised Guido's impeccable English, Guido goes and violates the Economist's style guide by not spelling that Tim Peters's court as I and all right-thinking singular grammarians would have done. I grew up in the Peters' house along with the rest of the Peters family, but if I ever get an apartment here it will be Peters's. glad-to-have-settled-*that*-one-ly y'rs - tim From guido@beopen.com Thu Jul 6 04:00:18 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 22:00:18 -0500 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack In-Reply-To: Your message of "Wed, 05 Jul 2000 21:27:48 -0400." References: Message-ID: <200007060300.WAA11066@cj20424-a.reston1.va.home.com> > Twice in ceval.c, and once in object.c, there's code referencing > PyOS_CheckStack under the control of the preprocessor symbol USE_STACKCHECK. > There's nothing in the std distribution that could possibly define either of > those names. Why are they there? If nobody objects, I'll get rid of this > code! They are there for the Mac code, which has its own config.h. The Mac distribution is maintained separately by Jack Jansen. There are occasional compromises in the main source code for the Mac port, and this is one. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Thu Jul 6 01:42:13 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 5 Jul 2000 19:42:13 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060044.TAA08483@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <200007060044.TAA08483@cj20424-a.reston1.va.home.com> Message-ID: <14691.54757.459091.820551@beluga.mojam.com> >> Along the same lines, I have some pretty simple mods to readline.c and >> rlcompleter.py ... Guido> To ease review of the patch, why don't you upload it? Done. It's available for review at https://sourceforge.net/patch/?func=detailpatch&patch_id=100742&group_id=5470 Skip From tim_one@email.msn.com Thu Jul 6 03:14:39 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 22:14:39 -0400 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack In-Reply-To: <200007060300.WAA11066@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > They are there for the Mac code, which has its own config.h. The Mac > distribution is maintained separately by Jack Jansen. There are > occasional compromises in the main source code for the Mac port, and > this is one. Then I would like to a) Add comments to the #ifdef's saying they're for the Mac. "Mystery code" is bad in group-maintained software. I expect Jack will maintain that it isn't really Mac-specific, but a wonderful feature for any platform that cares to #define USE_STACKCHECK and PyOS_CheckStack. Then I preemptively sneer in his general direction . b) Wonder out loud why this code is useful on a Mac but not other platforms. We can get segfaulting recursion while print'ing and repr'ing on all platforms. So shouldn't we work to catch that on all platforms too? Macs shouldn't be something special wrt this. From skip@mojam.com (Skip Montanaro) Thu Jul 6 01:48:19 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 5 Jul 2000 19:48:19 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> Message-ID: <14691.55123.961759.456729@beluga.mojam.com> Fred> "bash" doesn't make me set a variable to control saving of history Fred> to ~/.bash_history; I'd be perfectly happy if Python wrote Fred> ~/.python_history by default ... Fred, I was just following the trend established with PYTHONSTARTUP. It appears Guido did it that way on purpose... It doesn't much matter to me, though I wonder how system-dependent the code might get if you needed it to be available across multiple platforms. Unix, Windows and Mac all have different (sometimes nonexistent) notions of HOME, so it would be difficult to implement one mechanism that worked in a foolproof way. As for limiting the number of lines read or written (where should the truncation take place?), I'll gladly add a size parameter to either read_history or write_history if the underlying readline functions support the capability. Skip From gstein@lyra.org Thu Jul 6 03:27:21 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 5 Jul 2000 19:27:21 -0700 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14691.49755.365679.923078@beluga.mojam.com>; from skip@mojam.com on Wed, Jul 05, 2000 at 06:18:51PM -0500 References: <14691.49755.365679.923078@beluga.mojam.com> Message-ID: <20000705192721.A29590@lyra.org> On Wed, Jul 05, 2000 at 06:18:51PM -0500, Skip Montanaro wrote: > Along the same lines, I have some pretty simple mods to readline.c and > rlcompleter.py that use atexit to automatically save the current history to > the file identified by the PYTHONHISTORY environment variable. (If unset, > no history read/write is done). If we aren't in feature freeze, I'd like to > check it in. I'm against additional magic environment variables. Can't you just have people put something into their .pythonrc file? Or will it still require some C-level changes? Basically, can you point people at doing: .pythonrc: import rlhistory rlhistory.save_to('/home/gstein/.py_history') Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake@beopen.com Thu Jul 6 03:36:01 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 22:36:01 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <20000705192721.A29590@lyra.org> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> Message-ID: <14691.61585.352105.188917@cj42289-a.reston1.va.home.com> Greg Stein writes: > I'm against additional magic environment variables. > > Can't you just have people put something into their .pythonrc file? Or will > it still require some C-level changes? > > Basically, can you point people at doing: I think this makes the most sense. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip@mojam.com (Skip Montanaro) Thu Jul 6 02:16:05 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 5 Jul 2000 20:16:05 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <20000705192721.A29590@lyra.org> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> Message-ID: <14691.56789.869210.523939@beluga.mojam.com> Greg> I'm against additional magic environment variables. Greg> Can't you just have people put something into their .pythonrc Greg> file? Or will it still require some C-level changes? C-level changes are still required, but just to expose the existing functions in the GNU history library. After responding to Fred's note, I realized that what I'm doing in rlcompleter.py: import os histfile = os.getenv("PYTHONHISTORY") if histfile is not None: try: readline.read_history_file(histfile) except IOError: pass import atexit atexit.register(readline.write_history_file, histfile) del os, histfile could just as easily be done in ~/.pythonrc. Maybe I should retract the rlcompleter mods and just give something like import os histfile = os.path.join(os.environ["HOME"], ".python_history") try: readline.read_history_file(histfile) except IOError: pass import atexit atexit.register(readline.write_history_file, histfile) del os, histfile as an example in a yet-to-be-written libreadline.tex. Skip From fdrake@beopen.com Thu Jul 6 03:55:31 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 22:55:31 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14691.56789.869210.523939@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> <14691.56789.869210.523939@beluga.mojam.com> Message-ID: <14691.62755.609990.761864@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > as an example in a yet-to-be-written libreadline.tex. So when can I expect this to be checked in??? :-) (Surely you didn't expect me not to jump? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw@beopen.com Thu Jul 6 04:40:15 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 23:40:15 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 References: <200007052256.PAA12103@slayer.i.sourceforge.net> Message-ID: <14691.65439.950090.60795@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> Add more "volatile" decls to stop gcc -Wall warnings. TP> Somebody w/ gcc please check that the wngs are gone! The ones in pypcre.c are gone, but there are still a bunch of other -Wall warnings, none of which I have time to look at right now. Here's an excerpt. -Barry -------------------- snip snip -------------------- [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c -o bufferobject.o bufferobject.c: In function `PyBuffer_New': bufferobject.c:174: warning: value computed is not used gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c -o classobject.o classobject.c: In function `instance_dealloc': classobject.c:526: warning: unused variable `_Py_RefTotal' [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c object.c -o object.o object.c: In function `_PyTrash_deposit_object': object.c:1172: warning: unused variable `hold' [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c pystate.c -o pystate.o pystate.c: In function `PyInterpreterState_New': pystate.c:45: warning: value computed is not used [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./gcmodule.c ./gcmodule.c: In function `debug_cycle': ./gcmodule.c:295: warning: unsigned int format, long unsigned int arg (arg 5) ./gcmodule.c: In function `collect': ./gcmodule.c:374: warning: int format, long int arg (arg 3) ./gcmodule.c:374: warning: int format, long int arg (arg 4) ./gcmodule.c:374: warning: int format, long int arg (arg 5) ./gcmodule.c:438: warning: int format, long int arg (arg 3) ./gcmodule.c:438: warning: int format, long int arg (arg 4) [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c ./posixmodule.c:496: warning: `posix_strint' defined but not used [...] gcc -fpic -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./linuxaudiodev.c ./linuxaudiodev.c: In function `newladobject': ./linuxaudiodev.c:68: warning: unused variable `opendev' ./linuxaudiodev.c:67: warning: unused variable `ctldev' ./linuxaudiodev.c: At top level: ./linuxaudiodev.c:406: warning: `ins' defined but not used [...] gcc -fpic -DWITH_APPINIT -I/usr/X11R6/include -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./_tkinter.c ./_tkinter.c: In function `Sleep': ./_tkinter.c:270: warning: unused variable `frac' ./_tkinter.c: In function `Tkapp_DeleteFileHandler': ./_tkinter.c:1595: warning: unused variable `data' gcc -fpic -DWITH_APPINIT -I/usr/X11R6/include -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./tkappinit.c ./tkappinit.c: In function `Tcl_AppInit': ./tkappinit.c:22: warning: `main' is usually a function [...] gcc -fpic -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./_cursesmodule.c ./_cursesmodule.c: In function `PyCurses_UngetMouse': ./_cursesmodule.c:1646: warning: unused variable `rtn' ./_cursesmodule.c: In function `PyCurses_MouseMask': ./_cursesmodule.c:1950: warning: unused variable `rtn' ./_cursesmodule.c: In function `PyCurses_TypeAhead': ./_cursesmodule.c:2162: warning: unused variable `err' ./_cursesmodule.c: At top level: ./_cursesmodule.c:1478: warning: `PyCurses_resetty' defined but not used ./_cursesmodule.c:1479: warning: `PyCurses_savetty' defined but not used From bwarsaw@beopen.com Thu Jul 6 04:46:56 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 23:46:56 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> Message-ID: <14692.304.49138.508128@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> At lunch today, Guido raised almost the same question! Tim JH> and I argued that we should continue the feature freeze, and JH> spend any extra time wasted while we wait for CNRI to quit JH> stalling to resolve open bugs and do more testing. It's been JH> a long time since the last bug fix release, and there are JH> already a lot of new features. We'd probably be best served JH> by working hard to make 2.0 stable and solid -- and then JH> getting 2.1 released quickly. I'm really quite torn. The more rational side of my brain agrees with this position. OTOH, it just doesn't make much sense to me to add list comprehensions and augmented assignments (and a raft of other new features) in a 2.1 release. Seems like 2.0 is where all the new stuff should go, with 2.x's as bug fix releases. Think of all the new features added in 1.5.2 (a /micro/ release for gawds' sake). In retrospect, that was nutty. ah-hell-let's-release-a-1.6-after-all-ly y'rs, -Barry From tim_one@email.msn.com Thu Jul 6 04:45:36 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 23:45:36 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 In-Reply-To: <14691.65439.950090.60795@anthem.concentric.net> Message-ID: [Barry, quotes Tim's checkin comment] > TP> Add more "volatile" decls to stop gcc -Wall warnings. > TP> Somebody w/ gcc please check that the wngs are gone! > The ones in pypcre.c are gone, Since pypcre.c is the only file I changed, that's actually good news . Thank you for checking. > but there are still a bunch of other > -Wall warnings, none of which I have time to look at right now. > > Here's an excerpt. > ... Also good! If we keep posting this relentlessly, it *may* eventually shame the authors into cleaning up their code . From bwarsaw@beopen.com Thu Jul 6 04:47:50 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 23:47:50 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? References: <14691.49755.365679.923078@beluga.mojam.com> Message-ID: <14692.358.213728.411981@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> Along the same lines, I have some pretty simple mods to SM> readline.c and rlcompleter.py that use atexit to automatically SM> save the current history to the file identified by the SM> PYTHONHISTORY environment variable. (If unset, no history SM> read/write is done). If we aren't in feature freeze, I'd like SM> to check it in. +1 And +10000...000 if you can make it properly record multi-line input. -Barry From guido@beopen.com Thu Jul 6 05:52:09 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 23:52:09 -0500 Subject: [Python-Dev] list comprehensions again... In-Reply-To: Your message of "Wed, 05 Jul 2000 23:46:56 -0400." <14692.304.49138.508128@anthem.concentric.net> References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> Message-ID: <200007060452.XAA11841@cj20424-a.reston1.va.home.com> > I'm really quite torn. The more rational side of my brain agrees with > this position. OTOH, it just doesn't make much sense to me to add > list comprehensions and augmented assignments (and a raft of other new > features) in a 2.1 release. Seems like 2.0 is where all the new stuff > should go, with 2.x's as bug fix releases. That was my reasoning too -- which is why I was quite torn too at lunch (not just by the menu choices). I believe earlier we discussed how in particular list comprehensions don't affect much else, so even if they are broken, that shouldn't affect the stability of all the other new code that we put in, and I don't see how they could hold up the 2.0final release much. I'm much less sure about augmented assignments -- that's one big sucker of a patch! > Think of all the new features added in 1.5.2 (a /micro/ release for > gawds' sake). In retrospect, that was nutty. Yesh... > ah-hell-let's-release-a-1.6-after-all-ly y'rs, That's an in-joke :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Thu Jul 6 04:52:28 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 5 Jul 2000 22:52:28 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14692.358.213728.411981@anthem.concentric.net> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> Message-ID: <14692.636.850060.295979@beluga.mojam.com> BAW> And +10000...000 if you can make it properly record multi-line BAW> input. I take it there's an implicit smiley in there somewhere. All I do is expose the read_history and write_history in the GNU history library. The rest is up to readline & Python. Skip From tim_one@email.msn.com Thu Jul 6 04:51:53 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 23:51:53 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.304.49138.508128@anthem.concentric.net> Message-ID: OK, I'll be serious this time: if "the next release" is next week, damn straight I want to stick to the feature freeze. But if it becomes predictably delayed for months, sure, open the floodgates again. Unfortunately, the stuff holding up the release isn't technical in nature, so there's nothing most of us can do to affect the outcome either way. From fdrake@beopen.com Thu Jul 6 04:53:12 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 23:53:12 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.304.49138.508128@anthem.concentric.net> References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> Message-ID: <14692.680.483792.544003@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > Think of all the new features added in 1.5.2 (a /micro/ release for > gawds' sake). In retrospect, that was nutty. Are you saying we should re-label that 1.6? That may prove... convenient. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip@mojam.com (Skip Montanaro) Thu Jul 6 05:03:30 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 5 Jul 2000 23:03:30 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: References: <14692.304.49138.508128@anthem.concentric.net> Message-ID: <14692.1298.368572.533393@beluga.mojam.com> Well, how about taking a baseline snapshot now and branching the tree (I can almost hear Barry groaning all the way in Chicago...)? If the CNRI stuff gets cleared up quickly, the baseline + bug fixes becomes the 2.0 release and the other branch becomes 2.1 or something later. If it takes several weeks or a month (or more?), the snapshot gets forgotten and the branch becomes 2.0. I know branching is a struggle, probably not helped by the addition of the SourceForge stuff to the mix, but it might work out here. Skip From guido@beopen.com Thu Jul 6 06:04:19 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 00:04:19 -0500 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: Your message of "Wed, 05 Jul 2000 22:52:28 EST." <14692.636.850060.295979@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> Message-ID: <200007060504.AAA11934@cj20424-a.reston1.va.home.com> > BAW> And +10000...000 if you can make it properly record multi-line > BAW> input. > > I take it there's an implicit smiley in there somewhere. All I do is expose > the read_history and write_history in the GNU history library. The rest is > up to readline & Python. Barry was serious. IDLE does this right -- it remembers and lets you recall and edit entire multi-line commands. It's understood that readline doesn't support this, but at the same time it's a severe limitation that means that readline will never be good enough for the E in CP4E. This doesn't mean it's not an improvement over no line editing at all! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From tim_one@email.msn.com Thu Jul 6 05:14:48 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 00:14:48 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007060042.TAA06919@cj20424-a.reston1.va.home.com> Message-ID: > ... > Anyway, the patches are currently in Tim Peters' court. Forgot to say this before: among moving, bug-fixing, general testing, and the O'Reilly conference, I don't believe I'll find time to look at these patches for at least 2-- and more likely 3 --weeks. So if somebody is especially keen to get this in soon, feel encouraged to reassign the patch to yourself. From tim_one@email.msn.com Thu Jul 6 05:14:50 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 00:14:50 -0400 Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <01f001bfe6bb$5198bb60$f2a6b5d4@hagrid> Message-ID: Time to clear this one up too : Eric was taken in by a faux (i.e., not mine) "-ly y'rs" signoff. And if we're talking about one process, it's the process's exit code; if more than one, the processes' exit codes. "process exit code" also works for me. english-is-what-we-make-it-ly y'rs - tim From tim_one@email.msn.com Thu Jul 6 05:25:58 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 00:25:58 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.1298.368572.533393@beluga.mojam.com> Message-ID: [Skip Montanaro] > Well, how about taking a baseline snapshot now and branching the > tree (I can almost hear Barry groaning all the way in Chicago...)? > ... > I know branching is a struggle, probably not helped by the addition of the > SourceForge stuff to the mix, but it might work out here. That's exactly the kind of redirection of effort that a feature freeze is imposed to prevent. Even talking about it takes time away from work that *needs* to be completed for the release. OTOH, if the release is months away anyway, there's no need for a fork . From skip@mojam.com (Skip Montanaro) Thu Jul 6 05:27:38 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 5 Jul 2000 23:27:38 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060504.AAA11934@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> <200007060504.AAA11934@cj20424-a.reston1.va.home.com> Message-ID: <14692.2746.526025.335108@beluga.mojam.com> Guido> Barry was serious. IDLE does this right -- it remembers and lets Guido> you recall and edit entire multi-line commands. Yeah, but readline isn't a command editor, just a line editor and history. If I execute the following interactively: for i in range(10): print i I can use C-p to retrieve the lines and re-execute them. It's no better or worse than what bash does. In fact, with some versions of bash, it does recall entire multiline commands, for example, taking for f in `ls *.c` ; do echo $f done and returning for f in `ls *.c` ; do echo $f ; done instead when you retrieve it from the history. I find this particularly annoying and would much rather have the line-by-line recall that older versions of bash (and now Python) support. I've never used IDLE. What does it do to facilitate command recall and editing that's much different than Python or bash? Would it pop up the above Python for loop into a text editor widget and execute it when the widget is closed? Skip From fdrake@beopen.com Thu Jul 6 05:35:30 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 00:35:30 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14692.2746.526025.335108@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> <200007060504.AAA11934@cj20424-a.reston1.va.home.com> <14692.2746.526025.335108@beluga.mojam.com> Message-ID: <14692.3218.271993.100946@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > instead when you retrieve it from the history. I find this particularly > annoying and would much rather have the line-by-line recall that older > versions of bash (and now Python) support. This is something where you'd really want to be able to select which you prefer and toggle back and forth. I usually want a whole block, but sometimes I want to construct a new block from pieces of previous blocks. > I've never used IDLE. What does it do to facilitate command recall and > editing that's much different than Python or bash? Would it pop up the > above Python for loop into a text editor widget and execute it when the > widget is closed? No; it retrieves the whole multi-line block and inserts is at the prompt, allowing you to edit any part of it before type to execute. It's better than the bash behavior because it doesn't replace the actual newlines with semicolon separators (which wouldn't be sufficient for arbitrary Python code anyway). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw@beopen.com Thu Jul 6 05:44:09 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 00:44:09 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> Message-ID: <14692.3737.500081.892301@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: BAW> And +10000...000 if you can make it properly record BAW> multi-line input. SM> I take it there's an implicit smiley in there somewhere. Well, would classify a wistful, dreamy sort of smile as "implicit"? :) -Barry From skip@mojam.com (Skip Montanaro) Thu Jul 6 05:47:10 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 5 Jul 2000 23:47:10 -0500 (CDT) Subject: [Python-Dev] grumble, grumble - makesetup prepends leading $(srcdir) - why? Message-ID: <14692.3918.493708.366779@beluga.mojam.com> Here's one that's bugged me for awhile that I'm tired of working around. Perhaps someone can explain why makesetup does what it does. In my Modules/Setup.local file I have TOP=$(HOME)/src/python EDIR=$(TOP)/PyExtensions1.5 llop $(EDIR)/llopmodule.c # helper function(s) for latlong.py This gets converted into llopmodule.o: $(srcdir)/$(EDIR)/llopmodule.c; $(CC) $(CCSHARED) $(CFLAGS) -c $(srcdir)/$(EDIR)/llopmodule.c llopmodule$(SO): llopmodule.o; $(LDSHARED) llopmodule.o -o llopmodule$(SO) in Modules/Makefile. Is there a good reason why is $(srcdir)/ prepended to the source file reference, thus breaking my local module references? It seems the culprit is case $src in glmodule.c) ;; /*) ;; *) src='$(srcdir)/'$src;; esac around about line 193. I think this should be changed to case $src in glmodule.c) ;; /*) ;; \$*) ;; *) src='$(srcdir)/'$src;; esac or something similar that protects paths that begin with a Make variable. That fix works for me. Any objections to me checking it in? Also, who died and made glmodule.c king? Skip From bwarsaw@beopen.com Thu Jul 6 05:54:36 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 00:54:36 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> <200007060504.AAA11934@cj20424-a.reston1.va.home.com> <14692.2746.526025.335108@beluga.mojam.com> Message-ID: <14692.4364.272173.857069@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> I can use C-p to retrieve the lines and re-execute them. It's SM> no better or worse than what bash does. In fact, with some SM> versions of bash, it does recall entire multiline commands, SM> for example, taking | for f in `ls *.c` ; do | echo $f | done SM> and returning SM> for f in `ls *.c` ; do echo $f ; done SM> instead when you retrieve it from the history. I find this SM> particularly annoying and would much rather have the SM> line-by-line recall that older versions of bash (and now SM> Python) support. Not me. I love this particular feature of bash. I'm using 2.03. And it's one killer (IMO) feature of IDLE. -Barry From skip@mojam.com (Skip Montanaro) Thu Jul 6 05:58:11 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 5 Jul 2000 23:58:11 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14692.4364.272173.857069@anthem.concentric.net> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> <200007060504.AAA11934@cj20424-a.reston1.va.home.com> <14692.2746.526025.335108@beluga.mojam.com> <14692.4364.272173.857069@anthem.concentric.net> Message-ID: <14692.4579.624873.898969@beluga.mojam.com> SM> for f in `ls *.c` ; do echo $f ; done SM> ... I find this particularly annoying and would much rather have the SM> line-by-line recall that older versions of bash (and now Python) SM> support. BAW> Not me. I love this particular feature of bash. I'm using 2.03. BAW> And it's one killer (IMO) feature of IDLE. My main (error) reason for recalling a multiline command in bash is to insert a command I forgot to include, which is probably why I detest the way bash 2.x does command recall. Does IDLE allow new lines to be inserted into multiline commands or is it restricted to editing the existing lines? ESR is probably pretty damn good at curses in Python by now. Perhaps he can blend readline and curses together into a "simple" multiline command recall editor... ;-) Skip From Mark.Favas@per.dem.csiro.au Thu Jul 6 06:01:59 2000 From: Mark.Favas@per.dem.csiro.au (Favas, Mark (EM, Floreat)) Date: Thu, 6 Jul 2000 13:01:59 +0800 Subject: [Python-Dev] Defining _XOPEN_SOURCE in Python.h breaks 2.0b1 on Tru64 Unix Message-ID: This change results in mathmodule.c failing to compile (rint is undefined) due to an interaction between defining _XOPEN_SOURCE and the use of _XOPEN_SOURCE_EXTENDED in the system includes (/usr/include/math.h). Yes, configure correctly defines HAVE_RINT. This change also results in a number of errors and warnings in timemodule.c, and probably further modules down the compilation chain. From tim_one@email.msn.com Thu Jul 6 06:18:43 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 01:18:43 -0400 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14692.4579.624873.898969@beluga.mojam.com> Message-ID: [Skip Montanaro] > ... > Does IDLE allow new lines to be inserted into multiline commands or > is it restricted to editing the existing lines? Insertion is easy. In fact, it's sometimes surprising! The deal is that ENTER means two things in the IDLE shell: it may mean "insert a new line", or it may mean "I'm done with my edits, so run this block again". Which action IDLE performs depends on where the cursor is at the time ENTER is hit (whether or not at the end of the copied block). Lovely as the feature is, I think it gets in my way more often than not, as, e.g., I'm very likely to copy a multiline for-loop down and change just the limit on a range; then hitting ENTER doesn't do what I expect. there's-nothing-about-a-ui-somebody-won't-hate-ly y'rs - tim From guido@beopen.com Thu Jul 6 08:00:49 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 02:00:49 -0500 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: Your message of "Wed, 05 Jul 2000 20:16:05 EST." <14691.56789.869210.523939@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> <14691.56789.869210.523939@beluga.mojam.com> Message-ID: <200007060700.CAA01658@cj20424-a.reston1.va.home.com> > C-level changes are still required, but just to expose the existing > functions in the GNU history library. After responding to Fred's note, I > realized that what I'm doing in rlcompleter.py: > > import os > histfile = os.getenv("PYTHONHISTORY") > if histfile is not None: > try: > readline.read_history_file(histfile) > except IOError: > pass > import atexit > atexit.register(readline.write_history_file, histfile) > del os, histfile > > could just as easily be done in ~/.pythonrc. Maybe I should retract the > rlcompleter mods and just give something like > > import os > histfile = os.path.join(os.environ["HOME"], ".python_history") > try: > readline.read_history_file(histfile) > except IOError: > pass > import atexit > atexit.register(readline.write_history_file, histfile) > del os, histfile > > as an example in a yet-to-be-written libreadline.tex. Yes, much better. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal@lemburg.com Thu Jul 6 08:52:14 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 09:52:14 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> Message-ID: <39643AAE.B8448E4@lemburg.com> "M.-A. Lemburg" wrote: > > Fredrik Lundh wrote: > > > > mal wrote: > > > > > The idea is not new: strings and Unicode should have more > > > or less the same methods to enhance their compatibility. > > > > > > The attached patch adds encoding capabilities to normal > > > strings and extends the builtin str() to accept an optional > > > encoding (and error) argument. It also tries to reuse the > > > already available Unicode codecs for the purposes of strings > > > (conversions are done via the default encoding in both > > > directions). > > > > ... > > > > > What do you think about this ? Should I add it to CVS > > > as experiment ? > > > > +1 on the "encode" part > > > > -0 on the "str" part (intuitively, it's -1, but I don't have > > any good arguments against it right now... maybe later) > > The str() extension complements unicode() which also works > as constructor for object given an encoding. > > Ideally, unicode() should also look for __unicode__() on instances > just like str() looks for __str__(). > > Note that we could also have a .decode() method instead of > modifying str(), but this would break symmetry to Unicode, > since you can't decode Unicode into anything... Anybody else have an opinion on this idea ? I'd like to get this done before the release of 2.0b1. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut@microsoft.com Thu Jul 6 09:53:47 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 6 Jul 2000 01:53:47 -0700 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Objects unicodeobject. c,2.33,2.34 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD276@RED-MSG-50> ! if (c1 > (1<<11) * 26) ! c1 += utf16Fixup[c1>>11]; ! if (c2 > (1<<11) * 26) ! c2 += utf16Fixup[c2>>11]; ! This change from the patch is kind of silly. You've made the code flow more complicated for no particularly good reason, esp. considering the size of utf16Fixup[]. That is, the cost in the CPU of handling the branch prediction is likely to be much higher than the array lookup for every character. Bill From fredrik@pythonware.com Thu Jul 6 10:02:45 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 11:02:45 +0200 Subject: [Python-Dev] Spelling check: more typos References: <14690.56733.627266.907044@temoleh.chem.uu.nl> <20000705200043.D7564@ludwig.cnri.reston.va.us> Message-ID: <006b01bfe728$f4dcc380$0900a8c0@SPIFF> greg wrote: > In American English, "license" is both noun and verb. In the rest of > the world, "licence" is the noun and "license" the verb. should have realized that all dictionaries I consulted happened to be american. when I saw your post, I looked it up in the dictionaries I have at home (all British), and they all pointed out that the americans have it all mixed up. Just like those "Original Swedish Apfelstrudel" I found in Palo Alto... From jack@oratrix.nl Thu Jul 6 10:05:12 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 06 Jul 2000 11:05:12 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: Message by "M.-A. Lemburg" , Thu, 06 Jul 2000 00:19:38 +0200 , <3963B47A.638A7A82@lemburg.com> Message-ID: <20000706090512.EF3EC37186E@snelboot.oratrix.nl> > BTW, if your compiler supports Unicode (that is provides > a working wctype.h file), you can compile Python using > the compile time switch --with-wctype-functions. Python > will then use the C libs iswXXX() APIs which should return > more or less the same values as the Python ones (could be that > the C lib is Unicode 2.0 -- so YMMV). Note that this hasn't > been tested much yet. Feedback is welcome. Unfortunately the native wctype implementation is apparently different enough that it makes test_unicode fail. But I've solved the problem by splitting the 5000-entry switch statement into multiple switches with 1000 entries each. That's good enough for the CodeWarrior compiler (which doesn't have the least problem with the tiny 256-case switch in ceval.c). It may not be good enough for people who have compilers with really low limits on the number of cases in a switch, though. I'll check it in shortly. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Thu Jul 6 10:12:10 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 06 Jul 2000 11:12:10 +0200 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack In-Reply-To: Message by "Tim Peters" , Wed, 5 Jul 2000 22:14:39 -0400 , Message-ID: <20000706091210.443F537186E@snelboot.oratrix.nl> > a) Add comments to the #ifdef's saying they're for the Mac. "Mystery code" > is bad in group-maintained software. I expect Jack will maintain that it > isn't really Mac-specific, but a wonderful feature for any platform that > cares to #define USE_STACKCHECK and PyOS_CheckStack. Then I preemptively > sneer in his general direction . Hehheh:-) But I think it actually is used by some of the other ports. Any platform that doesn't guarantee a vm-hole between the stack and everything else should use a stack check, and this'll probably include all the handhelds and such. > b) Wonder out loud why this code is useful on a Mac but not other platforms. > We can get segfaulting recursion while print'ing and repr'ing on all > platforms. So shouldn't we work to catch that on all platforms too? Macs > shouldn't be something special wrt this. Well, a segfault is bad, but silently pushing the stack into the heap or into other random data is worse. And as the stackcheck isn't free it isn't used on other platforms. Moreover, I'm not even sure you can determine the stack limit on all platforms... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From thomas@xs4all.net Thu Jul 6 10:46:32 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 6 Jul 2000 11:46:32 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007060452.XAA11841@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 05, 2000 at 11:52:09PM -0500 References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> <200007060452.XAA11841@cj20424-a.reston1.va.home.com> Message-ID: <20000706114632.H13478@xs4all.nl> On Wed, Jul 05, 2000 at 11:52:09PM -0500, Guido van Rossum wrote: > I'm much less sure about augmented assignments -- that's one big > sucker of a patch! Ah, but it fits so nicely with the rest of Python ! :) The changes to support the new grammar, the new bytecodes and the __overload_ab__ methods are pretty teensy, but there's a lot of code to support the in-place operators in builtin and extension types, keeping the current API's semantics regarding conversion and such. In fact, test_augassign is just as large as the changes to ceval.c, and larger than those to compile.c ;) I agree though, that it's a big sucker of a patch to take in at once. I haven't found any bugs lately, but I don't use it that much. But it should run perfectly with old code, even if you just change all occurances of 'x = x + y' into 'x += y'. The worst thing that happens is that spam[something()] += other() is not entirely the same as: idx = something() spam[idx] = spam[idx] + other() but rather val = other() idx = something() spam[idx] = val because of the order of argument evaluation. But this shouldn't come as a suprise to anyone who has ever looked at the order of argument evaluation (I hadn't, before this) because it is exactly the same order as: spam[something()] = other() Would it help if I delivered it one piece at a time ? ;) I would suggest against adding augmented assignment in 2.0 if it went by the by-now-old schedule of the first beta at july 1st, because this patch can certainly use a full beta cycle to find out if any bugs lurk, but if 2.0 is months away, 2.1 is even more months away. But then, I have no idea about the problems which delay the 2.0 beta cycle, so I shouldn't be making assumptions ;P Advocating-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Thu Jul 6 10:48:56 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 11:48:56 +0200 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.33,2.34 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD276@RED-MSG-50> Message-ID: <39645608.9612520B@lemburg.com> Bill Tutt wrote: > > ! if (c1 > (1<<11) * 26) > ! c1 += utf16Fixup[c1>>11]; > ! if (c2 > (1<<11) * 26) > ! c2 += utf16Fixup[c2>>11]; > ! > > > > This change from the patch is kind of silly. You've made the code flow more > complicated for no particularly good reason, The reason was that it avoids the fixup lookup for all non-surrogate characters -- the vast majority of all chars processed. > esp. considering the size of > utf16Fixup[]. That is, the cost in the CPU of handling the branch prediction > is likely to be much higher than the array lookup for every character. Note that the lookup also involves a shift operation for every character. But if you insist, I'll do some benchmarking and check which version is faster. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 6 10:52:17 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 11:52:17 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <20000706090512.EF3EC37186E@snelboot.oratrix.nl> Message-ID: <396456D1.1D5EE0A5@lemburg.com> Jack Jansen wrote: > > > BTW, if your compiler supports Unicode (that is provides > > a working wctype.h file), you can compile Python using > > the compile time switch --with-wctype-functions. Python > > will then use the C libs iswXXX() APIs which should return > > more or less the same values as the Python ones (could be that > > the C lib is Unicode 2.0 -- so YMMV). Note that this hasn't > > been tested much yet. Feedback is welcome. > > Unfortunately the native wctype implementation is apparently different enough > that it makes test_unicode fail. But I've solved the problem by splitting the > 5000-entry switch statement into multiple switches with 1000 entries each. > That's good enough for the CodeWarrior compiler (which doesn't have the least > problem with the tiny 256-case switch in ceval.c). It may not be good enough > for people who have compilers with really low limits on the number of cases in > a switch, though. > > I'll check it in shortly. It might also be a good idea to add if (ch < 0x100) switch... statements. Most Unicode chars will be in the Latin-1 range anyway and this should improve performance. I'll add these to the other switches in unicodectype.c too after you've made your changes. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 6 11:03:28 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 12:03:28 +0200 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.33,2.34 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD276@RED-MSG-50> <39645608.9612520B@lemburg.com> Message-ID: <39645970.18CC2B9F@lemburg.com> "M.-A. Lemburg" wrote: > > Bill Tutt wrote: > > > > ! if (c1 > (1<<11) * 26) > > ! c1 += utf16Fixup[c1>>11]; > > ! if (c2 > (1<<11) * 26) > > ! c2 += utf16Fixup[c2>>11]; > > ! > > > > > > > > This change from the patch is kind of silly. You've made the code flow more > > complicated for no particularly good reason, > > The reason was that it avoids the fixup lookup for all non-surrogate > characters -- the vast majority of all chars processed. > > > esp. considering the size of > > utf16Fixup[]. That is, the cost in the CPU of handling the branch prediction > > is likely to be much higher than the array lookup for every character. > > Note that the lookup also involves a shift operation for every > character. > > But if you insist, I'll do some benchmarking and check which > version is faster. Your version: 0.98 sec. Fixed version: 0.96 sec. I don't think it's worth discussing this ;-) What's more interesting is that string compares are twice as fast: Same test: 0.46 sec. This is probably due to the compiler optimizing the memcmp() call which is used in string compares. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik@pythonware.com Thu Jul 6 11:21:05 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 12:21:05 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> <39643AAE.B8448E4@lemburg.com> Message-ID: <010101bfe733$e84a8750$0900a8c0@SPIFF> mal wrote: > > > > > > > What do you think about this ? Should I add it to CVS > > > > as experiment ? > > > > > > +1 on the "encode" part > > > > > > -0 on the "str" part (intuitively, it's -1, but I don't have > > > any good arguments against it right now... maybe later) > > > > The str() extension complements unicode() which also works > > as constructor for object given an encoding. > > > > Ideally, unicode() should also look for __unicode__() on instances > > just like str() looks for __str__(). > > > > Note that we could also have a .decode() method instead of > > modifying str(), but this would break symmetry to Unicode, > > since you can't decode Unicode into anything... > > Anybody else have an opinion on this idea ? I'd like to get > this done before the release of 2.0b1. Having thought this over, I'm -1 on the str fix. You're changing "str" from being a converter ("convert this to a string") to a string constructor ("create a new 8-bit string"). This is against the "strings are strings" spirit. Cannot you check the rest in, and leave "str" alone for now? From mal@lemburg.com Thu Jul 6 12:08:43 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 13:08:43 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> <39643AAE.B8448E4@lemburg.com> <010101bfe733$e84a8750$0900a8c0@SPIFF> Message-ID: <396468BB.EEC3D6F7@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > > > > > > > What do you think about this ? Should I add it to CVS > > > > > as experiment ? > > > > > > > > +1 on the "encode" part > > > > > > > > -0 on the "str" part (intuitively, it's -1, but I don't have > > > > any good arguments against it right now... maybe later) > > > > > > The str() extension complements unicode() which also works > > > as constructor for object given an encoding. > > > > > > Ideally, unicode() should also look for __unicode__() on instances > > > just like str() looks for __str__(). > > > > > > Note that we could also have a .decode() method instead of > > > modifying str(), but this would break symmetry to Unicode, > > > since you can't decode Unicode into anything... > > > > Anybody else have an opinion on this idea ? I'd like to get > > this done before the release of 2.0b1. > > Having thought this over, I'm -1 on the str fix. > > You're changing "str" from being a converter ("convert this to a > string") to a string constructor ("create a new 8-bit string"). This > is against the "strings are strings" spirit. Um, that was my motivation behind extending str() -- to make the two (str() and unicode()) aliases for the same function in some future Python version. Note that str() is in fact a constructor: you pass it an object and it creates a string from it for you. unicode() does the same thing (except that there's currently no __unicode__() check for instances). > Cannot you check the rest in, and leave "str" alone for now? I'll do that -- you won't be able to decode anything though, because there's no Python interface to PyString_Decode(). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip@mojam.com (Skip Montanaro) Thu Jul 6 12:52:56 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 6 Jul 2000 06:52:56 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060700.CAA01658@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> <14691.56789.869210.523939@beluga.mojam.com> <200007060700.CAA01658@cj20424-a.reston1.va.home.com> Message-ID: <14692.29464.106980.766555@beluga.mojam.com> >>>>> "Guido" == Guido van Rossum writes: >> ... could just as easily be done in ~/.pythonrc. Maybe I should >> retract the rlcompleter mods and just give something like [ ... brilliant example elided ... ] >> as an example in a yet-to-be-written libreadline.tex. Guido> Yes, much better. Okay, so the rlcompleter mods are out. That leaves two measly new methods in readline.c that won't bother anyone. Skip From guido@beopen.com Thu Jul 6 13:53:39 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 07:53:39 -0500 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) In-Reply-To: Your message of "Thu, 06 Jul 2000 12:21:05 +0200." <010101bfe733$e84a8750$0900a8c0@SPIFF> References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> <39643AAE.B8448E4@lemburg.com> <010101bfe733$e84a8750$0900a8c0@SPIFF> Message-ID: <200007061253.HAA02450@cj20424-a.reston1.va.home.com> > Subject: Re: [Python-Dev] 'abc'.encode() and str(obj, encoding) > From: "Fredrik Lundh" > To: "M.-A. Lemburg" , > "Python Developers @ python.org" > Date: Thu, 6 Jul 2000 12:21:05 +0200 > Delivery-Date: Thu Jul 6 06:22:40 2000 > > mal wrote: > > > > > > > > > What do you think about this ? Should I add it to CVS > > > > > as experiment ? > > > > > > > > +1 on the "encode" part > > > > > > > > -0 on the "str" part (intuitively, it's -1, but I don't have > > > > any good arguments against it right now... maybe later) > > > > > > The str() extension complements unicode() which also works > > > as constructor for object given an encoding. > > > > > > Ideally, unicode() should also look for __unicode__() on instances > > > just like str() looks for __str__(). > > > > > > Note that we could also have a .decode() method instead of > > > modifying str(), but this would break symmetry to Unicode, > > > since you can't decode Unicode into anything... > > > > Anybody else have an opinion on this idea ? I'd like to get > > this done before the release of 2.0b1. [/F] > Having thought this over, I'm -1 on the str fix. > > You're changing "str" from being a converter ("convert this to a > string") to a string constructor ("create a new 8-bit string"). This > is against the "strings are strings" spirit. I almost voted with you, except that int() also has an extra argument: int("100", 8) yields 64. In one of my proposals for a type system I've also used the str function and others as a constructor. Since I haven't seen the patch (too much other stuff going on you don't want to know about :-( ), I vote 0; that's neither +0 nor -0. > Cannot you check the rest in, and leave "str" alone for now? That would certainly be safe. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr@thyrsus.com Thu Jul 6 13:18:04 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 08:18:04 -0400 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000703165305.R29590@lyra.org>; from gstein@lyra.org on Mon, Jul 03, 2000 at 04:53:05PM -0700 References: <20000703095600.A12141@thyrsus.com> <20000703165305.R29590@lyra.org> Message-ID: <20000706081804.A24401@thyrsus.com> Greg Stein : > I used: > > $ cvs -z3 -d :ext:gstein@cvs.python.sourceforge.net:/cvsroot/python co python > > The instructions on SF didn't quite work. Adding the :ext: in made it work > fine for me. I'm using CVS 1.10.6 snark:~/WWW/python$ cvs -z3 -d :ext:esr@cvs.python.sourceforge.net:/cvsroot/python co python esr@cvs.python.sourceforge.net's password: cvs checkout: warning: unrecognized response `' from cvs server cvs checkout: warning: unrecognized response `Welcome to cvs1.sourceforge.net' from cvs server cvs checkout: warning: unrecognized response `' from cvs server cvs checkout: warning: unrecognized response `This is a restricted Shell Account' from cvs server cvs checkout: warning: unrecognized response `You cannot execute anything here.' from cvs server cvs checkout: warning: unrecognized response `' from cvs server cvs [checkout aborted]: end of file from server (consult above messages if any) That didn't work either. Anyone got any other ideas? I seem to have CVS 1.10.7. -- Eric S. Raymond See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs. -- Dave Barry From mal@lemburg.com Thu Jul 6 13:09:53 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 14:09:53 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> <39643AAE.B8448E4@lemburg.com> <010101bfe733$e84a8750$0900a8c0@SPIFF> <200007061253.HAA02450@cj20424-a.reston1.va.home.com> Message-ID: <39647711.6BDF96C@lemburg.com> Guido van Rossum wrote: > > [/F] > > Having thought this over, I'm -1 on the str fix. > > > > You're changing "str" from being a converter ("convert this to a > > string") to a string constructor ("create a new 8-bit string"). This > > is against the "strings are strings" spirit. > > I almost voted with you, except that int() also has an extra argument: > int("100", 8) yields 64. In one of my proposals for a type system > I've also used the str function and others as a constructor. I've always thought of str() being a constructor, just like int(), float(), complex() and all the others. The reasoning for adding optionla arguments to str() was to make it match the unicode() signature. > Since I haven't seen the patch (too much other stuff going on you > don't want to know about :-( ), I vote 0; that's neither +0 nor -0. > > > Cannot you check the rest in, and leave "str" alone for now? > > That would certainly be safe. I've checked in the .encode() method and the C APIs that go with it. There's currently no way to access the codec decode methods though (that was part of the str() patch). Anyway, it's cool having the ability to use the codecs for strings too, e.g. you can now do conversions from the current default encoding to say UTF-16 by simply writing: setenv LANG de_DE # Latin-1 encoding python -c "print 'Wünsch dir was...'.encode('utf16')" -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 6 13:17:28 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 14:17:28 +0200 Subject: [Python-Dev] SRE's match objects are missing .regs ?! Message-ID: <396478D8.26CBD0FA@lemburg.com> Is this intended ? I've often used .regs directly to enhance performance, but it looks as if SRE doesn't support this: Traceback (most recent call last): File "", line 1, in ? File "/home/lemburg/lib/hack.py", line 76, in docs showdocstring(obj.__doc__,2) File "/home/lemburg/lib/hack.py", line 145, in showdocstring sp = m.regs[1][1] AttributeError: regs -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Thu Jul 6 13:27:32 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 6 Jul 2000 14:27:32 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 In-Reply-To: <14691.65439.950090.60795@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 05, 2000 at 11:40:15PM -0400 References: <200007052256.PAA12103@slayer.i.sourceforge.net> <14691.65439.950090.60795@anthem.concentric.net> Message-ID: <20000706142731.K13478@xs4all.nl> On Wed, Jul 05, 2000 at 11:40:15PM -0400, Barry A. Warsaw wrote: > >>>>> "TP" == Tim Peters writes: > TP> Add more "volatile" decls to stop gcc -Wall warnings. > TP> Somebody w/ gcc please check that the wngs are gone! > The ones in pypcre.c are gone, but there are still a bunch of other > -Wall warnings, none of which I have time to look at right now. I actually looked at most of these a couple of weeks back, and most are harmless. For instance: > -------------------- snip snip -------------------- > [...] > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c -o bufferobject.o > bufferobject.c: In function `PyBuffer_New': > bufferobject.c:174: warning: value computed is not used PyObject_INIT((PyObject *)b, &PyBuffer_Type); The 'value computed' is useless. The value computed is computed by the ',' operator, but the only things in there are sideffect operators. The last operation in the string of ',''s is either a void-returning function or an assignment, so I'd classify this one as a cosmetic bug in gcc ;) adding a '(void)' cast to the PyObject_INIT() macro or the calls to it would fix the warning. > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c -o classobject.o > classobject.c: In function `instance_dealloc': > classobject.c:526: warning: unused variable `_Py_RefTotal' Can be fixed by a surrounding #ifdef Py_TRACE_REFS. > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c object.c -o object.o > object.c: In function `_PyTrash_deposit_object': > object.c:1172: warning: unused variable `hold' Can be removed, seems to be left over from before Christians' trash hauling. > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c pystate.c -o pystate.o > pystate.c: In function `PyInterpreterState_New': > pystate.c:45: warning: value computed is not used Similar to PyObject_INIT(), but even sillier ;) Can be fixed in the same manner. > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c > ./posixmodule.c:496: warning: `posix_strint' defined but not used Looks like an obsoleted helper function, for calling string-int-functions. (Like posix_strintint, which is called in exactly one place.) Unsure if these are leftover or intended for future use ;) If they are just leftover, shouldn't we just make chown do the work posix_strintint does, and remove those two functions ? I also get a few others, by the way (redhat-6.1 supplied egcs-1.1.2): ceval.c: In function `eval_code2': ceval.c:333: warning: `opcode' might be used uninitialized in this function ceval.c:334: warning: `oparg' might be used uninitialized in this function The second one is fairly obvious: oparg is only initialized if opcode has an argument, but gcc doesn't know when that is. So as far as gcc is concerned it is possible to enter a branch that uses oparg without initializing it. The opcode one is because it's possible as far as gcc is concerned, to jump to on_error on the first iteration of the large for(;;) loop, before opcode is initialized. This might actually be possible, I think, if a signal arrives before the first time through the loop. ./pypcre.c: In function `compile_branch': ./pypcre.c:1222: warning: `c' might be used uninitialized in this function Just looking at this one gave me a headache. This code can definately use a good indent run, or better yet, replacement! I can't figure out why gcc complains about this one. ./socketmodule.c: In function `newSSLObject': ./socketmodule.c:1963: warning: unused variable `str' ./socketmodule.c: At top level: ./socketmodule.c:358: warning: `SSL_setattr' declared `static' but never defined As you can see, I compile the socket module with SSL ;) Both of these can be just removed, but I'm not sure howmuch of the SSL part is still 'work in progress'. And then there's some warnings in _cursesmodule.c, _tkinter.c, gcmodule.c, linuxaudiodev.c and tkappinit.c that the module maintainers should look at. (nudge nudge.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fredrik@pythonware.com Thu Jul 6 13:31:42 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 14:31:42 +0200 Subject: [Python-Dev] SRE's match objects are missing .regs ?! References: <396478D8.26CBD0FA@lemburg.com> Message-ID: <01bc01bfe746$25940d90$0900a8c0@SPIFF> mal wrote: > Is this intended ? I've often used .regs directly to enhance > performance, but it looks as if SRE doesn't support this: if you can figure out where (in the 1.5.2 docs) they're documented, I'll add them ;-) (I'd rather add a "spans" method, but that's me...) From akuchlin@mems-exchange.org Thu Jul 6 13:32:23 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 6 Jul 2000 08:32:23 -0400 Subject: [Python-Dev] SRE's match objects are missing .regs ?! In-Reply-To: <396478D8.26CBD0FA@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 02:17:28PM +0200 References: <396478D8.26CBD0FA@lemburg.com> Message-ID: <20000706083223.A29375@newcnri.cnri.reston.va.us> On Thu, Jul 06, 2000 at 02:17:28PM +0200, M.-A. Lemburg wrote: >Is this intended ? I've often used .regs directly to enhance >performance, but it looks as if SRE doesn't support this: .regs was never documented in the library reference, nor in the docstrings in libre.tex; it was an underlying implementation detail some people happened to take advantage of. If /F wants to add it in order to be nice, fine; I certainly wouldn't bother to do that. -amk From pavlos@gaaros.com Thu Jul 6 13:46:50 2000 From: pavlos@gaaros.com (Pavlos Christoforou) Date: Thu, 6 Jul 2000 08:46:50 -0400 (EDT) Subject: [Python-Dev] Re: [Zope-dev] ExtensionClass and __radd__()? In-Reply-To: <20000705183046.A26381@ludwig.cnri.reston.va.us> Message-ID: On Wed, 5 Jul 2000, Greg Ward wrote: > > Well, it's a nice theory. It doesn't explain why '__add__()' works for > ExtensionClass while '__radd__()' does not; perhaps ExtensionClass > implements that much of Python's class semantics, but doesn't go as far > as '__radd__()'. > A quick note which you probably already know: grep add ExtensionClass.c gives: static PyObject *py__add__, *py__sub__, *py__mul__, *py__div__, INIT_PY_NAME(__add__); BINOP(add,Add) FILLENTRY(nm->nb, add, add, METH_VARARGS, "Add to another"); FILLENTRY(sm->sq, concat, add, METH_VARARGS, SET_SPECIAL(add,add); subclass_add(PyObject *self, PyObject *v) UNLESS(m=subclass_getspecial(self,py__add__)) return NULL; && AsCMethod(m)->meth==(PyCFunction)add_by_name ASSIGN(m,AsCMethod(m)->type->tp_as_number->nb_add(self,v)); (binaryfunc)subclass_add, /*nb_add*/ (binaryfunc)subclass_add, /*sq_concat*/ return; /* we added a reference; don't delete now */ whereas grep radd ExtensionClass.c returns nothing Pavlos From gstein@lyra.org Thu Jul 6 14:21:52 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 06:21:52 -0700 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000706081804.A24401@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 06, 2000 at 08:18:04AM -0400 References: <20000703095600.A12141@thyrsus.com> <20000703165305.R29590@lyra.org> <20000706081804.A24401@thyrsus.com> Message-ID: <20000706062152.P29590@lyra.org> On Thu, Jul 06, 2000 at 08:18:04AM -0400, Eric S. Raymond wrote: > Greg Stein : > > I used: > > > > $ cvs -z3 -d :ext:gstein@cvs.python.sourceforge.net:/cvsroot/python co python > > > > The instructions on SF didn't quite work. Adding the :ext: in made it work > > fine for me. I'm using CVS 1.10.6 > > snark:~/WWW/python$ cvs -z3 -d :ext:esr@cvs.python.sourceforge.net:/cvsroot/python co python > esr@cvs.python.sourceforge.net's password: > cvs checkout: warning: unrecognized response `' from cvs server > cvs checkout: warning: unrecognized response `Welcome to cvs1.sourceforge.net' from cvs server > cvs checkout: warning: unrecognized response `' from cvs server > cvs checkout: warning: unrecognized response `This is a restricted Shell Account' from cvs server > cvs checkout: warning: unrecognized response `You cannot execute anything here.' from cvs server > cvs checkout: warning: unrecognized response `' from cvs server > cvs [checkout aborted]: end of file from server (consult above messages if any) > > That didn't work either. Anyone got any other ideas? > > I seem to have CVS 1.10.7. The response looks like the bare text you get when you "ssh" directly to the server. It prints some stuff then closes the connection. This would indicate to me that your CVS isn't passing the command over to the SF machine. Put this file into, say, /tmp/ssh-verbose: #!/bin/bash echo COMMAND: $@ exec /usr/bin/ssh -v $@ then do: $ export CVS_RSH=/tmp/ssh-verbose $ cvs ... same as above You should get a long stream of debug output. Right after you enter your password, you should see a couple lines like: debug: Sending command: cvs server debug: Entering interactive session. If not, then I'd suspect the CVS is invoking SSH incorrectly. The first line of output should look like: cvs log: warning: unrecognized response `COMMAND: cvs.python.sourceforge.net -l gstein cvs server' from cvs server That `... cvs server' in the command string is the key. I suspect those two words aren't in your command string, so SSH is just opening an interactive shell. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gward@mems-exchange.org Thu Jul 6 14:23:41 2000 From: gward@mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 09:23:41 -0400 Subject: [Python-Dev] Re: [Zope-dev] ExtensionClass and __radd__()? In-Reply-To: ; from pavlos@gaaros.com on Thu, Jul 06, 2000 at 08:46:50AM -0400 References: <20000705183046.A26381@ludwig.cnri.reston.va.us> Message-ID: <20000706092340.B1539@ludwig.cnri.reston.va.us> On 06 July 2000, Pavlos Christoforou said: > A quick note which you probably already know: > > grep add ExtensionClass.c gives: [...lots...] > whereas grep radd ExtensionClass.c returns nothing Yep, did the same myself shortly after posting. It's not really clear what 'py__add__' is and how it works, though, so it's not obvious if 'py__radd__' is the right thing to add, and if so how to add it. Greg If it's just a matter of adding radd (and rsub, rmul, and rdiv) in all those places -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From skip@mojam.com (Skip Montanaro) Thu Jul 6 14:54:40 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 6 Jul 2000 08:54:40 -0500 (CDT) Subject: [Python-Dev] how do I release a cvs lock? Message-ID: <14692.36768.23073.781592@beluga.mojam.com> Sjoerd & Fred both let me know that I am locking the Modules directory. How do I unlock it? The "cvs admin" command looks potentially promising, but very low-level. Skip From Moshe Zadka Thu Jul 6 14:55:12 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 6 Jul 2000 16:55:12 +0300 (IDT) Subject: Viewing Patches on UNIX Machines (was Re: [Python-Dev] oh, and any interest in my readline history stuff?) In-Reply-To: <14691.54757.459091.820551@beluga.mojam.com> 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. ---559023410-33463914-962891712=:21283 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Jul 2000, Skip Montanaro wrote: > https://sourceforge.net/patch/?func=detailpatch&patch_id=100742&group_id=5470 I'm using the attached program to watch patches. run like python patch.py 100742 (UNIX only currently, sorry) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. ---559023410-33463914-962891712=:21283 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="patch.py" Content-ID: Content-Description: Content-Disposition: attachment; filename="patch.py" Content-Transfer-Encoding: BASE64 ZGVmIGdldF9wYXRjaChudW1iZXIpOg0KCWltcG9ydCB1cmxsaWINCglyZXR1 cm4gdXJsbGliLnVybG9wZW4oImh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcGF0 Y2gvZG93bmxvYWQucGhwP2lkPSVzIg0KCSAgICAgICAgICAgICAgICAgICAg ICAlIG51bWJlcikNCg0KZGVmIHNob3dfZmlsZShmaWxlKToNCglpbXBvcnQg b3MNCglsZXNzID0gb3MucG9wZW4oImxlc3MiLCAndycpDQoJdHJ5Og0KCQl3 aGlsZSAxOg0KCQkJYnVmID0gZmlsZS5yZWFkKDQwOTYpDQoJCQlpZiBub3Qg YnVmOg0KCQkJCWJyZWFrDQoJCQlsZXNzLndyaXRlKGJ1ZikNCglmaW5hbGx5 Og0KCQlsZXNzLmNsb3NlKCkNCg0KZGVmIHNob3dfcGF0Y2gobnVtYmVyKToN Cgl0cnk6DQoJCXBhdGNoID0gZ2V0X3BhdGNoKG51bWJlcikNCgkJc2hvd19m aWxlKHBhdGNoKQ0KCWZpbmFsbHk6DQoJCXBhdGNoLmNsb3NlKCkNCg0KZGVm IG1haW4oKToNCglpbXBvcnQgc3lzDQoJc2hvd19wYXRjaChzeXMuYXJndlsx XSkNCg0KaWYgX19uYW1lX18gPT0gJ19fbWFpbl9fJzoNCgltYWluKCkNCg== ---559023410-33463914-962891712=:21283-- From fdrake@beopen.com Thu Jul 6 15:03:38 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 10:03:38 -0400 (EDT) Subject: [Python-Dev] Bogus lock in Modules directory Message-ID: <14692.37306.880611.330267@cj42289-a.reston1.va.home.com> There's a bogus read lock in dist/src/Modules from last night; I've confirmed that it's bogus with Skip (whose lock it is), and filed a support request with SourceForge (#103231) to have it removed. I'll let everyone know when this is cleared. You should still be able to pick up updates without problems, but you can't check anything in in the Modules/ directory until this is cleared (because CVS won't let you). The link to the support request is: http://sourceforge.net/support/?func=detailsupport&support_id=103231&group_id=1 -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein@lyra.org Thu Jul 6 15:06:28 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 07:06:28 -0700 Subject: [Python-Dev] how do I release a cvs lock? In-Reply-To: <14692.36768.23073.781592@beluga.mojam.com>; from skip@mojam.com on Thu, Jul 06, 2000 at 08:54:40AM -0500 References: <14692.36768.23073.781592@beluga.mojam.com> Message-ID: <20000706070628.X29590@lyra.org> On Thu, Jul 06, 2000 at 08:54:40AM -0500, Skip Montanaro wrote: > Sjoerd & Fred both let me know that I am locking the Modules directory. How > do I unlock it? The "cvs admin" command looks potentially promising, but > very low-level. If it is an adminstrative-lock, then yes: cvs admin is the trick. But I don't think you can do that on a directory. So... it is probably a bungled directory-lock (e.g. it didn't get cleaned up). If so... then we probably need some SF admins to clean it up. Hmm. I just did a "cvs update" in the Modules directory. No problem. Sjoerd, Fred? What exactly are you referring to? I see nothing... (maybe Skip cleared it already?) Cheers, -g -- Greg Stein, http://www.lyra.org/ From fredrik@pythonware.com Thu Jul 6 15:11:38 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 16:11:38 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> Message-ID: <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> I wrote: > > both modules can be squeezed down to almost nothing. > it just takes a little work. > > fwiw, Tcl's version of the unicodectype file is about 30k, > and compiles to an 8k large object file on my win95 box. Just noticed that _sre.c takes ages to compile on my linux box, and comes out as a 450k object module. it's under 30k on Windows. Methinks gcc expands recursive inlined functions a bit more than visual C. I'll try do get it down under 100k before the final release... From guido@beopen.com Thu Jul 6 16:15:53 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 10:15:53 -0500 Subject: [Python-Dev] how do I release a cvs lock? In-Reply-To: Your message of "Thu, 06 Jul 2000 08:54:40 EST." <14692.36768.23073.781592@beluga.mojam.com> References: <14692.36768.23073.781592@beluga.mojam.com> Message-ID: <200007061515.KAA13255@cj20424-a.reston1.va.home.com> > Sjoerd & Fred both let me know that I am locking the Modules directory. How > do I unlock it? The "cvs admin" command looks potentially promising, but > very low-level. I doubt that cvs admin can help you -- it interfaces to rcs, which doesn't do per-directory locking. More likely a lock file used when you made a checkin or checkout is accidentally left behind. I believe you cannot remove this yourself nor can I help you with it ([re]moving files in the CVS repository tree is not for mere mortals). Submit a service request, they usually take care of it within a few hours. (Click in the "Request Support" entry in the SourceForge section of the left sidebar.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jim@digicool.com Thu Jul 6 15:25:10 2000 From: jim@digicool.com (Jim Fulton) Date: Thu, 06 Jul 2000 10:25:10 -0400 Subject: [Python-Dev] Comparison inconsistency with ExtensionClass References: <20000501184017.A1171@mems-exchange.org> Message-ID: <396496C6.82804F84@digicool.com> Greg Ward wrote: > > Hi all -- > > I seem to have discovered an inconsistency in the semantics of object > comparison between plain old Python instances and ExtensionClass > instances. (I've cc'd python-dev because it looks as though one *could* > blame Python for the inconsistency, but I don't really understand the > guts of either Python or ExtensionClass enough to know.) (demonstration snipped) > The first one and the last two are obvious, but the second one only > works thanks to a trick in PyObject_Compare(): > > if (PyInstance_Check(v) || PyInstance_Check(w)) { > ... > if (!PyInstance_Check(v)) > return -PyObject_Compare(w, v); > ... > } > > However, if I make Simple an ExtensionClass: > > from ExtensionClass import Base > > class Simple (Base): > > Then the "swap v and w and use w's comparison method" no longer works. > Here's the output of the script with Simple as an ExtensionClass: > > v1 == v2? no > v2 == v1? Simple.__cmp__: self=, other=36 > yes > v1 == v2.data? yes > v2.data == v1? yes > > It looks as though ExtensionClass would have to duplicate the trick in > PyObject_Compare() that I quoted, since Python has no idea that > ExtensionClass instances really should act like instances. This smells > to me like a bug in ExtensionClass. Comments? Technically, this *is* a bug in ExtensionClass, however, Python *does* deserve some of the blame. The intepreter actually uses the following rule: Instances of two different "python types" are not compared using type-supplied comparison methods unless: - At least one of the types is InstanceType or - Both of the types are numeric. This rule is rather inconvenient for ExtensionClass. It's also pretty inconvenient for non-ExtensionClass non-numeric extension types that want to be comparable with other things. You can work around this by making your ExtensionClass a numeric type. This should be possible by providing a numeric method. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From tismer@appliedbiometrics.com Thu Jul 6 15:33:59 2000 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Thu, 06 Jul 2000 16:33:59 +0200 Subject: [Python-Dev] how do I release a cvs lock? References: <14692.36768.23073.781592@beluga.mojam.com> <200007061515.KAA13255@cj20424-a.reston1.va.home.com> Message-ID: <396498D7.97ABB543@appliedbiometrics.com> Guido van Rossum wrote: > > > Sjoerd & Fred both let me know that I am locking the Modules directory. How > > do I unlock it? The "cvs admin" command looks potentially promising, but > > very low-level. > > I doubt that cvs admin can help you -- it interfaces to rcs, which > doesn't do per-directory locking. > > More likely a lock file used when you made a checkin or checkout is > accidentally left behind. I believe you cannot remove this yourself > nor can I help you with it ([re]moving files in the CVS repository > tree is not for mere mortals). Submit a service request, they usually > take care of it within a few hours. (Click in the "Request Support" > entry in the SourceForge section of the left sidebar.) Do we really want to live on with SourceForge(t) ? It seems to be pleasant for small projects, but maybe it would be more convenient to have a CVS that we control directly? The new starship is very powerful and could stand a couple of CVS repositories easily. While one might argue that this would give to much of Python to BeOpen (they got it already:), I think this could work smoothly. ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From guido@beopen.com Thu Jul 6 16:32:32 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 10:32:32 -0500 Subject: [Python-Dev] Comparison inconsistency with ExtensionClass In-Reply-To: Your message of "Thu, 06 Jul 2000 10:25:10 -0400." <396496C6.82804F84@digicool.com> References: <20000501184017.A1171@mems-exchange.org> <396496C6.82804F84@digicool.com> Message-ID: <200007061532.KAA13361@cj20424-a.reston1.va.home.com> [JimF] > Technically, this *is* a bug in ExtensionClass, however, Python > *does* deserve some of the blame. The intepreter actually uses the > following rule: > > Instances of two different "python types" are not compared > using type-supplied comparison methods unless: > > - At least one of the types is InstanceType or > > - Both of the types are numeric. > > This rule is rather inconvenient for ExtensionClass. > It's also pretty inconvenient for non-ExtensionClass > non-numeric extension types that want to be comparable with > other things. > > You can work around this by making your ExtensionClass a numeric > type. This should be possible by providing a numeric method. Without having investigated all the details of this thread, I suspect that all of this ought to be rethought when we do rich comparisons and revamp coercions. I'd say that would be a good project for Python 2.1... (Which most of the Zopers probably still know as 1.7. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake@beopen.com Thu Jul 6 15:33:23 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 10:33:23 -0400 (EDT) Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> Message-ID: <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > Just noticed that _sre.c takes ages to compile on my linux > box, and comes out as a 450k object module. > > it's under 30k on Windows. Wow! Maybe try turning off optimizations? I think there's an option to just turn off inlining, bt I don't know if you can limit the number of recursive inlines. A simpler option: surround the "inline" directive with #ifndef __GNUC__ / #endif. > Methinks gcc expands recursive inlined functions a bit more > than visual C. I'll try do get it down under 100k before the > final release... Now, if we could do that for unicodedata and ucnhash, a lot more people would be happy! Marc-Andre, Bill: Would it be reasonable to have perfect_hash.py actually compress the text strings used for the character names? Since there's such a limited alphabet in use, something special purpose would probably be easy and do a lot of good. When checking the lookup, you could easily decode the string in the table to do the comparison. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@beopen.com Thu Jul 6 16:37:42 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 10:37:42 -0500 Subject: [Python-Dev] how do I release a cvs lock? In-Reply-To: Your message of "Thu, 06 Jul 2000 16:33:59 +0200." <396498D7.97ABB543@appliedbiometrics.com> References: <14692.36768.23073.781592@beluga.mojam.com> <200007061515.KAA13255@cj20424-a.reston1.va.home.com> <396498D7.97ABB543@appliedbiometrics.com> Message-ID: <200007061537.KAA13448@cj20424-a.reston1.va.home.com> > Do we really want to live on with SourceForge(t) ? > It seems to be pleasant for small projects, but > maybe it would be more convenient to have a CVS > that we control directly? > The new starship is very powerful and could stand a couple of > CVS repositories easily. > > While one might argue that this would give to much of Python > to BeOpen (they got it already:), I think this could work > smoothly. In my experience, maintaining the repository, with both anonymous and privileged (commit) access, is a lot of work -- managing user accounts for the privileged, keeping the machine up and running, etc. I'm really quite happy with the level of support we get from SF. In the long run, BeOpen might be interested in running this kind of service for the Python and other communities; but for now, it would just be a burden. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Thu Jul 6 16:40:00 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 10:40:00 -0500 Subject: [Python-Dev] grumble, grumble - makesetup prepends leading $(srcdir) - why? In-Reply-To: Your message of "Wed, 05 Jul 2000 23:47:10 EST." <14692.3918.493708.366779@beluga.mojam.com> References: <14692.3918.493708.366779@beluga.mojam.com> Message-ID: <200007061540.KAA13487@cj20424-a.reston1.va.home.com> > Here's one that's bugged me for awhile that I'm tired of working around. > Perhaps someone can explain why makesetup does what it does. > > In my Modules/Setup.local file I have > > TOP=$(HOME)/src/python > EDIR=$(TOP)/PyExtensions1.5 > llop $(EDIR)/llopmodule.c # helper function(s) for latlong.py > > This gets converted into > > llopmodule.o: $(srcdir)/$(EDIR)/llopmodule.c; $(CC) $(CCSHARED) $(CFLAGS) -c $(srcdir)/$(EDIR)/llopmodule.c > llopmodule$(SO): llopmodule.o; $(LDSHARED) llopmodule.o -o llopmodule$(SO) > > in Modules/Makefile. Is there a good reason why is $(srcdir)/ prepended to > the source file reference, thus breaking my local module references? It > seems the culprit is > > case $src in > glmodule.c) ;; > /*) ;; > *) src='$(srcdir)/'$src;; > esac > > around about line 193. I think this should be changed to > > case $src in > glmodule.c) ;; > /*) ;; > \$*) ;; > *) src='$(srcdir)/'$src;; > esac > > or something similar that protects paths that begin with a Make variable. > That fix works for me. Any objections to me checking it in? Good idea. Go ahead. > Also, who died and made glmodule.c king? It was Jack & me. We're not dead yet! The reason is that glmodule.c is actually generated by a script that is run automatically from the Makefile. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas@xs4all.net Thu Jul 6 15:41:23 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 6 Jul 2000 16:41:23 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <14692.39091.731830.389350@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 10:33:23AM -0400 References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> Message-ID: <20000706164123.A26534@xs4all.nl> On Thu, Jul 06, 2000 at 10:33:23AM -0400, Fred L. Drake, Jr. wrote: > Fredrik Lundh writes: > > Just noticed that _sre.c takes ages to compile on my linux > > box, and comes out as a 450k object module. > > it's under 30k on Windows. > Wow! Maybe try turning off optimizations? I think there's an > option to just turn off inlining, bt I don't know if you can limit the > number of recursive inlines. A simpler option: surround the "inline" > directive with #ifndef __GNUC__ / #endif. gcc tries to inline functions itself, too, depending on optimization level, and it might be that the heuristics to determine wether it's worth it or not are broken. You can use -fno-inline to see if that's the case. But it might even be that gcc is right, that the larger code is faster, in spite of being larger. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake@beopen.com Thu Jul 6 15:49:25 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 10:49:25 -0400 (EDT) Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <20000706164123.A26534@xs4all.nl> References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> <20000706164123.A26534@xs4all.nl> Message-ID: <14692.40053.417868.570920@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > even be that gcc is right, that the larger code is faster, in spite of being > larger. It may be faster, but that doesn't mean the tradeoff is right. ;) Ideally, this shouldn't take a lot of space, simply because we don't want to exclude platforms with substantial *memory* constraints. But we can let benchmarkers decide what the right tradeoff it; the size isn't that big of a concern for me. (I made the right tradeoff -- I traded empty memory slots for filled ones! 512MB is a nice start. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw@beopen.com Thu Jul 6 15:53:22 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 10:53:22 -0400 (EDT) Subject: [Python-Dev] how do I release a cvs lock? References: <14692.36768.23073.781592@beluga.mojam.com> <200007061515.KAA13255@cj20424-a.reston1.va.home.com> <396498D7.97ABB543@appliedbiometrics.com> Message-ID: <14692.40290.628899.363800@anthem.concentric.net> >>>>> "CT" == Christian Tismer writes: CT> Do we really want to live on with SourceForge(t) ? It seems CT> to be pleasant for small projects, but maybe it would be more CT> convenient to have a CVS that we control directly? The new CT> starship is very powerful and could stand a couple of CVS CT> repositories easily. CT> While one might argue that this would give to much of Python CT> to BeOpen (they got it already:), I think this could work CT> smoothly. I think for now SF is our home. Trying to move anything at this point would burn much more time than we have. We really want to get releases out asap! At some point we might look at a couple of alternatives, such as: create our own site based on the SF code base; help SF improve their s/w more directly; roll our own using better Python-based tools. -Barry From bwarsaw@beopen.com Thu Jul 6 15:55:36 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 10:55:36 -0400 (EDT) Subject: [Python-Dev] Comparison inconsistency with ExtensionClass References: <20000501184017.A1171@mems-exchange.org> <396496C6.82804F84@digicool.com> Message-ID: <14692.40424.736713.740441@anthem.concentric.net> >>>>> "JF" == Jim Fulton writes: JF> Instances of two different "python types" are not compared JF> using type-supplied comparison methods unless: JF> - At least one of the types is InstanceType or JF> - Both of the types are numeric. JF> This rule is rather inconvenient for ExtensionClass. JF> It's also pretty inconvenient for non-ExtensionClass JF> non-numeric extension types that want to be comparable with JF> other things. I ran into this problem when trying to translate a simple Boolean class into a built-in type. I basically could not get the comparisons to work correctly when I moved to C. So I'm +1 on fixing this at some point (probably as Guido points out, when we add rich comparisons). -Barry From gward@mems-exchange.org Thu Jul 6 16:03:26 2000 From: gward@mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 11:03:26 -0400 Subject: [Python-Dev] help wanted: windows locales In-Reply-To: <00fa01bfe6b5$a8400460$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jul 05, 2000 at 09:17:20PM +0200 References: <00fa01bfe6b5$a8400460$f2a6b5d4@hagrid> Message-ID: <20000706110326.A9547@ludwig.cnri.reston.va.us> On 05 July 2000, Fredrik Lundh said: > windows_lang = { [...] > 0x042d: "eu_ES", # Basque Isn't Basque also spoken in France? > 0x0445: "bn_??", # Bengali Bangladesh I think; possibly India as well. Don't know the country code for Bangladesh. > 0x2809: "en"_BZ, # English (Belize) ^ ^ typo? > 0x0447: "gu_??", # Gujarati I think this is an Indian language too. > 0x043f: "kk_??", # Kazakh If I had to hazard a guess, I'd say Kazakhstan. ;-) > 0x0446: "pa_??", # Punjabi Probably India and Pakistan both. Would it be overkill to allow mapping one Windows hex code to two locale codes, eg. 0x0446 -> ("pa_IN", "pa_PK")? Better not bring up Kashmiri -- if you thought the politics of spelling English was touchy... ;-) Greg From jim@digicool.com Thu Jul 6 16:06:49 2000 From: jim@digicool.com (Jim Fulton) Date: Thu, 06 Jul 2000 11:06:49 -0400 Subject: [Python-Dev] ExtensionClass and __radd__()? References: <20000705183046.A26381@ludwig.cnri.reston.va.us> Message-ID: <3964A089.A8347970@digicool.com> Greg Ward wrote: > > Hi all -- > > looks like ExtensionClass doesn't recognize/implement the '__radd__()' > protocol. Speculation below; first, a demonstration. Normal case: a > regular class Number that knows how to add itself to other number-like > things: (demonstration snipped) > Speculation time: I'm guessing that this is similar to the problem with > 'isinstance()' and ExtensionClass that I found several months ago, which > was heroically debugged by Barry. To recap, it's a mutual > finger-pointing bug: Python (Guido) can claim that it's up to > ExtensionClass (Jim) to emulate the full semantics of Python > classes/instances, but ExtensionClass can claim that Python should be > more relaxed in what it accepts as a "class object" or "instance > object". > > I think the relevant code in Python is in Objects/abstract.c, > specifically 'PyNumber_Add()' and the BINOP macro: > > #define BINOP(v, w, opname, ropname, thisfunc) \ > if (PyInstance_Check(v) || PyInstance_Check(w)) \ > return PyInstance_DoBinOp(v, w, opname, ropname, thisfunc) > > [...] > PyNumber_Add(v, w) > PyObject *v, *w; > { > PySequenceMethods *m; > > BINOP(v, w, "__add__", "__radd__", PyNumber_Add); > [...] > > My guess is that PyInstance_Check() returns false for ExtensionClass > instances. Two possible fixes: loosen up PyInstance_Check(), or loosen > up BINOP. > > Well, it's a nice theory. It doesn't explain why '__add__()' works for > ExtensionClass while '__radd__()' does not; perhaps ExtensionClass > implements that much of Python's class semantics, but doesn't go as far > as '__radd__()'. I'd love to see __radd__ added. ;) I don't remember why it's not there. Maybe I was just lazy. It may be fairly hard to add. I haven't looked in quite a while. As anyone whos looked at ExtensionClass sources may be able to tell, ExtensionClass has to play quite a few tricks to: - Try to sanely bridge the quite different semantics of Python "types" and "classes" (e.g. there's no radd for "types"). - Try to overcome the fact that the interpreter special-cases InstanceType and ClassType pretty liberally. To (try to and mostly succeed to) provide instance semantics I have to do alot of weird indirection. This is especially hard for numeric things. Your analysis of the code demonstrates this issue. ExtensionClass instances are not of type InstanceType. In fact, each ExtensionClass is a separate type and instances of different ExtensionClasses have different types. Note that I just got around to responding to your earlier post "Comparison inconsistency with ExtensionClass". This has a similar root cause: the special-case treatment of InstanceType. I think that the *real* solution to this problem is to get rid of ExtensionClass. ;) To do this, I need to get the features I have in ExtensionClass into Python. I guess there's some hope for that in Python 3K (love that name :). In the mean time, I don't have time to fix the radd problem myself, but would be willing to advise someone who wanted to try to take it on, especially if we could work out some phone or face-to-face sessions. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From fredrik@pythonware.com Thu Jul 6 16:09:42 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 17:09:42 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid><00c801bfe754$1a6f8ad0$0900a8c0@SPIFF><14692.39091.731830.389350@cj42289-a.reston1.va.home.com><20000706164123.A26534@xs4all.nl> <14692.40053.417868.570920@cj42289-a.reston1.va.home.com> Message-ID: <013901bfe75c$37eed630$0900a8c0@SPIFF> fred wrote: > Thomas Wouters writes: > > even be that gcc is right, that the larger code is faster, in spite of being > > larger. > > It may be faster, but that doesn't mean the tradeoff is right. ;) > Ideally, this shouldn't take a lot of space, simply because we don't > want to exclude platforms with substantial *memory* constraints. yeah, but people porting SRE to small platforms can switch off inlining completely. if I do that on windows, the resulting DLL is less than 20k. which is pretty okay, I think, if you consider that the DLL contains two separate regular expression engines, a scanner framework, and lots of other stuff... cheers /F From paul@prescod.net Thu Jul 6 16:12:30 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 06 Jul 2000 10:12:30 -0500 Subject: [Python-Dev] list comprehensions again... References: <14691.49563.78765.683762@beluga.mojam.com> <200007060042.TAA06919@cj20424-a.reston1.va.home.com> Message-ID: <3964A1DE.F0878306@prescod.net> Guido van Rossum wrote: > > > Was there a public announcement made about new functionality for > > 2.0? > > Yes, there's something on http://pythonlabs.com/tech/python2.html. We > currently can't commit to a release schedule due to the problems with > CNRI. Between now and the release, someone needs to add something there about the XML support. In general, it is in the interest of the Python community (and of course, my personal interest!) to emphasize Python's XML sophistication. From a marketing point of view, the new XML support could be pushed as sufficient reason for a major version release all by itself. For instance, Even the Guido is impressed when he reads vacuous XML-related press releases from the TCL guys.[1] :) :) Python 2 could be the first language with support for SAX and DOM in the class libraries (though Java is catching fast) and the first to ship Expat as a standard module (on some platforms, anyhow). If the feature freeze "melts", we could probably add SOAP support in a month or so also. [1]http://www.python.org/pipermail/xml-sig/1999-October/003167.html (to be fair, I don't know that the TCL stuff is vacuous, I just presume that any "B2B integration server" is likely to be vacuous...) -- Paul Prescod - Not encumbered by corporate consensus The distinction between the real twentieth century (1914-1999) and the calenderical one (1900-2000) is based on the convincing idea that the century's bouts of unprecented violence, both within nations and between them, possess a definite historical coherence -- that they constitute, to put it simply, a single story. - The Unfinished Twentieth Century, Jonathan Schell Harper's Magazine, January 2000 From esr@thyrsus.com Thu Jul 6 16:27:21 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 11:27:21 -0400 Subject: [Python-Dev] help wanted: windows locales In-Reply-To: <20000706110326.A9547@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Thu, Jul 06, 2000 at 11:03:26AM -0400 References: <00fa01bfe6b5$a8400460$f2a6b5d4@hagrid> <20000706110326.A9547@ludwig.cnri.reston.va.us> Message-ID: <20000706112721.B25443@thyrsus.com> Greg Ward : > > 0x0447: "gu_??", # Gujarati > > I think this is an Indian language too. > > > 0x043f: "kk_??", # Kazakh > > If I had to hazard a guess, I'd say Kazakhstan. ;-) > > > 0x0446: "pa_??", # Punjabi > > Probably India and Pakistan both. Correct on all counts. -- Eric S. Raymond Love your country, but never trust its government. -- Robert A. Heinlein. From fdrake@beopen.com Thu Jul 6 16:50:47 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 11:50:47 -0400 (EDT) Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <013901bfe75c$37eed630$0900a8c0@SPIFF> References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> <20000706164123.A26534@xs4all.nl> <14692.40053.417868.570920@cj42289-a.reston1.va.home.com> <013901bfe75c$37eed630$0900a8c0@SPIFF> Message-ID: <14692.43735.835843.916140@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > yeah, but people porting SRE to small platforms can switch off > inlining completely. if I do that on windows, the resulting DLL > is less than 20k. So don't worry about the 100K for Linux/x86 unless you just want to test that -fno-inline (or whatever) is passed from the Setup file to the Makefile without makesetup barfing on it. (Not unusual for less common flags, but I think -f* is passed along.) > which is pretty okay, I think, if you consider that the DLL contains > two separate regular expression engines, a scanner framework, and > lots of other stuff... 20K -- 40K I'm not worried about. I'm less worried about the people with *no* RAM, who will run into problems before they try to start python, than about the guys with only a little RAM (say, 128MB ;). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Thu Jul 6 17:00:44 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 12:00:44 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <3964A1DE.F0878306@prescod.net> References: <14691.49563.78765.683762@beluga.mojam.com> <200007060042.TAA06919@cj20424-a.reston1.va.home.com> <3964A1DE.F0878306@prescod.net> Message-ID: <14692.44332.771745.446084@cj42289-a.reston1.va.home.com> Paul Prescod writes: > Between now and the release, someone needs to add something there about > the XML support. In general, it is in the interest of the Python > community (and of course, my personal interest!) to emphasize Python's > XML sophistication. From a marketing point of view, the new XML support > could be pushed as sufficient reason for a major version release all by > itself. For instance, Even the Guido is impressed when he reads vacuous > XML-related press releases from the TCL guys.[1] :) :) I've written a bit of text for Guido about this, but it's fairly short. If you, Lars, Andrew or anyone else from the XML gang would like to take a crack at it, here's what I've sent Guido: ------------------------------------------------------------------------ XML Support ........... Python 2.0 introduces new XML tools developed by the XML Special Interest Group (http://www.python.org/sigs/xml-sig/). The widely-accepted Expat XML parser from James Clark is used to provide a high-performance, non-validating parser to Python applications. This parser provides full Unicode support in compliance with the XML 1.0 specification. Interfaces are provided to work with the most widely accepted interfaces defined by the XML community: SAX, the Simple API for XML (http://www.megginson.com/SAX/) and DOM, the Document Object Model Level 1 (http://www.w3.org/TR/REC-DOM-Level-1/). ------------------------------------------------------------------------ > Python 2 could be the first language with support for SAX and DOM in the > class libraries (though Java is catching fast) and the first to ship > Expat as a standard module (on some platforms, anyhow). If the feature An excellent point we'd do well to capitalize on -- a lot of people interested in using XML would switch from other langs for this reason, I suspect. > [1]http://www.python.org/pipermail/xml-sig/1999-October/003167.html > (to be fair, I don't know that the TCL stuff is vacuous, I just presume > that any "B2B integration server" is likely to be vacuous...) That's a reasonable presumption, but I wouldn't make large bets on it either. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From akuchlin@mems-exchange.org Thu Jul 6 17:12:31 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 6 Jul 2000 12:12:31 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.680.483792.544003@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Wed, Jul 05, 2000 at 11:53:12PM -0400 References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> <14692.680.483792.544003@cj42289-a.reston1.va.home.com> Message-ID: <20000706121231.A14042@kronos.cnri.reston.va.us> On Wed, Jul 05, 2000 at 11:53:12PM -0400, Fred L. Drake, Jr. wrote: >Barry A. Warsaw writes: > > Think of all the new features added in 1.5.2 (a /micro/ release for > > gawds' sake). In retrospect, that was nutty. > Are you saying we should re-label that 1.6? That may prove... >convenient. ;) I've been privately wondering about making a new tarball of 1.5.2 that simply adds the Lib/distutils/ subdirectory and installs it, so people who don't want to risk the jump to 2.0 can still get the nice Distutils features. The problem is that it would take substantial willpower to only make that change; the temptation would be great to fix just this one really annoying bug, oh, and this little feature wouldn't break anything, and ... --amk From esr@thyrsus.com Thu Jul 6 17:21:22 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 12:21:22 -0400 Subject: [Python-Dev] urllib.browse() issues Message-ID: <20000706122122.A25613@thyrsus.com> Having finally wrestled CVS into at least temporary submission, I'm in the process of generating a patch to add a browser-launcher function to the standard library. There are a couple of issues connected to this. One: location. I still think, after meditating on it, that urllib and not os is the right place for this. Yes, it launches a process -- but that's implementation. It's a way to fetch the contents of an URL. In the potential *user's* view of the Python library, it belongs with other ways to fetch URLs. Two: cross-platform capability is a Good Thing. I rummaged around after a half-forgotten bit of lore in my files and discovered an allegation that under Windows, os.system("start %s" % url) is supposed to launch your default browser on the specified URL. Now here's what I'd like to write: if os.environ.has_key("BROWSER"): _browsers = string.split(os.environ["BROWSER"], ":") elif os.name == 'posix': _browsers = ["mozilla %s &", "netscape -remote 'openURL(%s)'", "netscape %s &", "lynx %s &", "w3m %s &"] elif os.name == 'nt': _browsers = ["start %s"] def urlbrowse(url): """Launch a browser, in background, pointed at the given URL. Accept either a string or a parsed URL tuple. Interpret the BROWSER environment variable, if it exists, as a colon-separated list of browser commands to try. """ from urlparse import urlunparse if type(url) == (): url = urlunparse(url) for browser in _browsers: if iscommand(string.split(browser)[0]): if os.system((browser % url)) == 0: return 1 return 0 The missing piece of implementation is the function iscommand(). I know how to write this under Unix: def iscommand(cmd): return os.system('which 1>/dev/null 2>&1 ' + cmd) == 0 So my question is this: is there any analogous way to check for the existence of a command under Windows? If so... Three: I'd like to add a cross-platform iscommand() function to os. -- Eric S. Raymond There's a truism that the road to Hell is often paved with good intentions. The corollary is that evil is best known not by its motives but by its *methods*. From akuchlin@mems-exchange.org Thu Jul 6 17:13:42 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 6 Jul 2000 12:13:42 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.44332.771745.446084@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 12:00:44PM -0400 References: <14691.49563.78765.683762@beluga.mojam.com> <200007060042.TAA06919@cj20424-a.reston1.va.home.com> <3964A1DE.F0878306@prescod.net> <14692.44332.771745.446084@cj42289-a.reston1.va.home.com> Message-ID: <20000706121342.B14042@kronos.cnri.reston.va.us> >On Thu, Jul 06, 2000 at 12:00:44PM -0400, Fred L. Drake, Jr. wrote: > I've written a bit of text for Guido about this, but it's fairly >short. If you, Lars, Andrew or anyone else from the XML gang would >like to take a crack at it, here's what I've sent Guido: That looks fine for the README or Misc/NEWS file. I want to write a section of the "What's New" article that goes into greater detail, shows some simple examples of parsing things, etc., but haven't gotten around to it yet. --amk From mal@lemburg.com Thu Jul 6 17:17:26 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 18:17:26 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> Message-ID: <3964B116.44E1606E@lemburg.com> "Fred L. Drake, Jr." wrote: > > Now, if we could do that for unicodedata and ucnhash, a lot more > people would be happy! > Marc-Andre, Bill: Would it be reasonable to have perfect_hash.py > actually compress the text strings used for the character names? > Since there's such a limited alphabet in use, something special > purpose would probably be easy and do a lot of good. When checking > the lookup, you could easily decode the string in the table to do the > comparison. I don't have the time to look into this, sorry. Other things are more important now, like changing the handling of the 's' and 't' parser markers for Unicode from UTF-8 to default encoding. This will complete the move from a fixed internal encoding to a locale dependent setting and should fix most problems people have noticed on their platforms. BTW, does the XML package already use the builtin Unicode support ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 6 17:28:12 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 18:28:12 +0200 Subject: [Python-Dev] Hash values and comparing objects Message-ID: <3964B39C.7E0CD312@lemburg.com> There currently is a problem with the Unicode objects which I'd like to resolve: Since Unicode object are comparable to strings, they should have the same hash value as their string correspondents (the 8-bit strings which compare equal -- this can depend on the default encoding which again depends on the locale setting). Previously, Unicode used UTF-8 as basis for calculating the hash value (the Unicode object created a UTF-8 string object and delegated the hash value calculation to it, caching the result and the string for future use). Since I would like to make the internal encoding cache use the default encoding instead, I have two problems to solve: 1. It is sometimes not possible to encode the Unicode value using the default encoding. A different strategy for calculating the hash value would have to be used. 2. In some locales 'äöü' == u'äöü' is true, while in others this is not the case. If they do compare equal, the hash values must match. How serious is the need for objects which compare equal to have the same hash value ? (I would much prefer to calculate the hash value using the internal UTF-16 buffer rather than first creating an encoded string.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 6 17:33:55 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 18:33:55 +0200 Subject: [Python-Dev] urllib.browse() issues References: <20000706122122.A25613@thyrsus.com> Message-ID: <3964B4F3.5EE72F14@lemburg.com> "Eric S. Raymond" wrote: > > Having finally wrestled CVS into at least temporary submission, > I'm in the process of generating a patch to add a browser-launcher > function to the standard library. There are a couple of issues > connected to this. Eric, please have a look at Tools/idle/BrowserControl.py... it has all you need and can easily be extended to support more browsers. Might be a good candidate for the std lib if you ask me -- after a rename to say "browser.py". -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@beopen.com Thu Jul 6 17:51:51 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 12:51:51 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964B4F3.5EE72F14@lemburg.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> Message-ID: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Might be a good candidate for the std lib if you ask me -- > after a rename to say "browser.py". Agh! That was my original name for it! Guido wanted me to change it since that didn't describe it well (there's not a single browser implementation in there ;). browsercntl seems... ugly. I'd welcome suggestions for short, lower-case names, though. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Thu Jul 6 17:53:19 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 12:53:19 -0400 (EDT) Subject: [Python-Dev] forwarded message from noreply@sourceforge.net Message-ID: <14692.47487.15354.645423@cj42289-a.reston1.va.home.com> --uplAv6Ykhx Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit The bogus CVS lock in Modules/ is now fixed! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member --uplAv6Ykhx Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit Return-Path: Received: from lists.sourceforge.net ([198.186.203.35]) by mailhost.beopen.com (8.9.3/8.9.3) with ESMTP id JAA16350 for ; Thu, 6 Jul 2000 09:42:56 -0700 Received: from delerium.i.sourceforge.net (sourceforge.net [198.186.203.33]) by lists.sourceforge.net (8.9.3/8.9.3) with ESMTP id JAA24688; Thu, 6 Jul 2000 09:49:01 -0700 Received: (from nobody@localhost) by delerium.i.sourceforge.net (8.9.3/8.9.3) id JAA27494; Thu, 6 Jul 2000 09:44:04 -0700 Message-Id: <200007061644.JAA27494@delerium.i.sourceforge.net> X-Authentication-Warning: delerium.i.sourceforge.net: nobody set sender to noreply@sourceforge.net using -f From: noreply@sourceforge.net To: noreply@sourceforge.net Subject: [ 103231 ] bogus directory lock Date: Thu, 6 Jul 2000 09:44:04 -0700 Support Request #103231, was updated on 2000-Jul-06 23:54 You can respond by visiting: http://sourceforge.net/support/?func=detailsupport&support_id=103231&group_id=1 Category: CVS Status: Closed Priority: 5 Summary: bogus directory lock By: aphzen Date: 2000-Jul-07 02:44 Message: Logged In: YES user_id=171 Browser: Mozilla/4.7 [en]C-monwin/012 (Win98; I) Fixed. ---------------------------------------------------------------------- By: fdrake Date: 2000-Jul-06 23:54 Message: Logged In: YES user_id=3066 Browser: Mozilla/4.72 [en] (X11; U; Linux 2.2.14-15mdk i686) Project: Python (Unix name: python). There is a bogus directory lock in /cvsroot/python/python/dist/src/Modules; the user (Skip Montanaro, Unix name: montanaro) has confirmed that this lock should not be held. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/support/?func=detailsupport&support_id=103231&group_id=1 --uplAv6Ykhx-- From ping@lfw.org Thu Jul 6 18:30:05 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 6 Jul 2000 10:30:05 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <20000705183353.B7564@ludwig.cnri.reston.va.us> Message-ID: On Wed, 5 Jul 2000, Greg Ward wrote: > > SyntaxError: expected indent > > SyntaxError: expected unindent The "expected indent" message seems a little abrupt to me (does it mean there's a problem because an indent is expected, or a problem with an indent that was expected, or a problem because an expected indent isn't there?) so i have changed it to SyntaxError: expected an indented block The latter case, "expected unindent", never occurs -- it is always okay to continue an indented block, so a DEDENT is never absolutely required. The rest of the messages now say "unindent" instead of "dedent". I've updated the patch. -- ?!ng "To be human is to continually change. Your desire to remain as you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From esr@thyrsus.com Thu Jul 6 18:39:57 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 13:39:57 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964B4F3.5EE72F14@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 06:33:55PM +0200 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> Message-ID: <20000706133957.C25726@thyrsus.com> M.-A. Lemburg : > "Eric S. Raymond" wrote: > > > > Having finally wrestled CVS into at least temporary submission, > > I'm in the process of generating a patch to add a browser-launcher > > function to the standard library. There are a couple of issues > > connected to this. > > Eric, please have a look at Tools/idle/BrowserControl.py... > it has all you need and can easily be extended to support > more browsers. It's kind of sideways to what I'm trying to accomplish in some ways -- but yes, I see some useful tricks in there. Perhapsa I'll try to clean this up into a browser.py. -- Eric S. Raymond The difference between death and taxes is death doesn't get worse every time Congress meets -- Will Rogers From mal@lemburg.com Thu Jul 6 18:37:31 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 19:37:31 +0200 Subject: [Python-Dev] urllib.browse() issues References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> Message-ID: <3964C3DB.B57E95F9@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > Might be a good candidate for the std lib if you ask me -- > > after a rename to say "browser.py". > > Agh! That was my original name for it! Guido wanted me to change > it since that didn't describe it well (there's not a single browser > implementation in there ;). Um, there's not a single OS implementation in os.py either ;-) I think it describes things well enough if you write browser.open('http://www.python.org/') Perhaps the interface should be a bit more RPC like, though... something like: b = browser.connect() b.open(http://www.python.org/') b.close() > browsercntl seems... ugly. I'd welcome suggestions for short, > lower-case names, though. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping@lfw.org Thu Jul 6 18:44:43 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 6 Jul 2000 10:44:43 -0700 (PDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> Message-ID: On Thu, 6 Jul 2000, Fred L. Drake, Jr. wrote: > browsercntl seems... ugly. I'd welcome suggestions for short, > lower-case names, though. browsing.py? -- ?!ng From esr@thyrsus.com Thu Jul 6 18:56:03 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 13:56:03 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: ; from ping@lfw.org on Thu, Jul 06, 2000 at 10:44:43AM -0700 References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> Message-ID: <20000706135603.A26040@thyrsus.com> Ka-Ping Yee : > On Thu, 6 Jul 2000, Fred L. Drake, Jr. wrote: > > browsercntl seems... ugly. I'd welcome suggestions for short, > > lower-case names, though. > > browsing.py? I like it. -- Eric S. Raymond "...The Bill of Rights is a literal and absolute document. The First Amendment doesn't say you have a right to speak out unless the government has a 'compelling interest' in censoring the Internet. The Second Amendment doesn't say you have the right to keep and bear arms until some madman plants a bomb. The Fourth Amendment doesn't say you have the right to be secure from search and seizure unless some FBI agent thinks you fit the profile of a terrorist. The government has no right to interfere with any of these freedoms under any circumstances." -- Harry Browne, 1996 USA presidential candidate, Libertarian Party From fdrake@beopen.com Thu Jul 6 18:58:00 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 13:58:00 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964C3DB.B57E95F9@lemburg.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> Message-ID: <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Um, there's not a single OS implementation in os.py either ;-) Good point; we should fix that. ;) > I think it describes things well enough if you write > > browser.open('http://www.python.org/') > > Perhaps the interface should be a bit more RPC like, though... > something like: > > b = browser.connect() > b.open(http://www.python.org/') > b.close() How about: b = browser.get() b.open("http://www.python.org/") That has the advantage of working with the existing code. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas@xs4all.net Thu Jul 6 19:09:24 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 6 Jul 2000 20:09:24 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 In-Reply-To: <20000706142731.K13478@xs4all.nl>; from thomas@xs4all.net on Thu, Jul 06, 2000 at 02:27:32PM +0200 References: <200007052256.PAA12103@slayer.i.sourceforge.net> <14691.65439.950090.60795@anthem.concentric.net> <20000706142731.K13478@xs4all.nl> Message-ID: <20000706200924.B26534@xs4all.nl> On Thu, Jul 06, 2000 at 02:27:32PM +0200, Thomas Wouters wrote: > PyObject_INIT((PyObject *)b, &PyBuffer_Type); > > The 'value computed' is useless. The value computed is computed by the ',' > operator, but the only things in there are sideffect operators. The last > operation in the string of ',''s is either a void-returning function or an > assignment, so I'd classify this one as a cosmetic bug in gcc ;) adding a > '(void)' cast to the PyObject_INIT() macro or the calls to it would fix the > warning. Er, ignore that. The value computed isn't useless, it's just the first argument. I overlooked that, sorry :P The return value is used in a couple of places. That leaves only one option to squench this warning, a (void) cast at the one spot that causes a warning. Or is there a better way ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip@mojam.com (Skip Montanaro) Thu Jul 6 17:47:15 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 6 Jul 2000 11:47:15 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc/templates module.tex,1.20,1.21 In-Reply-To: <200007061612.JAA11764@slayer.i.sourceforge.net> References: <200007061612.JAA11764@slayer.i.sourceforge.net> Message-ID: <14692.47123.218360.100174@beluga.mojam.com> Fred> *** 130,135 **** Fred> % detailed list of functions.) Fred> ! \subsection{Example} Fred> ! \nodename{Spam Example} Fred> The following example demonstrates how to open a can of spam using the Fred> --- 132,136 ---- Fred> % detailed list of functions.) Fred> ! \subsection{Example \label{spam-example}} Fred, I pulled the incorrect usage from libsocket.tex. Should all examples be changed to match? Skip From fdrake@beopen.com Thu Jul 6 19:25:52 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 14:25:52 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc/templates module.tex,1.20,1.21 In-Reply-To: <14692.47123.218360.100174@beluga.mojam.com> References: <200007061612.JAA11764@slayer.i.sourceforge.net> <14692.47123.218360.100174@beluga.mojam.com> Message-ID: <14692.53040.729280.724075@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > I pulled the incorrect usage from libsocket.tex. Should all examples be > changed to match? I'll go ahead and fix the socket documentation (I've made the changes already), but I wouldn't spend time looking for more instances. They can be fixed on an as-needed basis I think; there's enough real work to be done! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Moshe Zadka Thu Jul 6 19:42:40 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 6 Jul 2000 21:42:40 +0300 (IDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964B4F3.5EE72F14@lemburg.com> Message-ID: On Thu, 6 Jul 2000, M.-A. Lemburg wrote: > "Eric S. Raymond" wrote: > > > > Having finally wrestled CVS into at least temporary submission, > > I'm in the process of generating a patch to add a browser-launcher > > function to the standard library. There are a couple of issues > > connected to this. > > Eric, please have a look at Tools/idle/BrowserControl.py... > it has all you need and can easily be extended to support > more browsers. > > Might be a good candidate for the std lib if you ask me -- > after a rename to say "browser.py". It can easily be transformed into the standard library for free: just declare IDLE a standard library package. Even better would be to divorce all those parts of IDLE which are Tkinter independent and put those in a seperate package, whose name is TBD. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From mal@lemburg.com Thu Jul 6 19:58:45 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 20:58:45 +0200 Subject: [Python-Dev] urllib.browse() issues References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> Message-ID: <3964D6E5.536C0D93@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > Um, there's not a single OS implementation in os.py either ;-) > > Good point; we should fix that. ;) > > > I think it describes things well enough if you write > > > > browser.open('http://www.python.org/') > > > > Perhaps the interface should be a bit more RPC like, though... > > something like: > > > > b = browser.connect() > > b.open(http://www.python.org/') > > b.close() > > How about: > > b = browser.get() > b.open("http://www.python.org/") > > That has the advantage of working with the existing code. ;) Ok, fine with me. +1 for adding it to the standard lib from me. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From esr@thyrsus.com Thu Jul 6 20:44:34 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 15:44:34 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964D6E5.536C0D93@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 08:58:45PM +0200 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> Message-ID: <20000706154434.A26357@thyrsus.com> M.-A. Lemburg : > Ok, fine with me. > > +1 for adding it to the standard lib from me. Who's going to do the cut and fit? Me, or the IDLE maintainer? -- Eric S. Raymond Society in every state is a blessing, but government even in its best state is but a necessary evil; in its worst state an intolerable one; for when we suffer, or are exposed to the same miseries *by a government*, which we might expect in a country *without government*, our calamities is heightened by reflecting that we furnish the means by which we suffer." -- Thomas Paine From fdrake@beopen.com Thu Jul 6 20:41:08 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 15:41:08 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706154434.A26357@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> Message-ID: <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Who's going to do the cut and fit? Me, or the IDLE maintainer? If Guido doesn't object to moving this module, the task falls to me since I wrote it. Were there any requirements you had that the existing BrowserControl doesn't support? If so, please tell us from the requirements side. I'll write the documentation as well, if we move it. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Thu Jul 6 20:41:27 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 15:41:27 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: [moved from patches to Python-Dev] >> Patch #100745 has been updated. >> Visit SourceForge.net for more info. > http://sourceforge.net/patch/?func=detailpatch&patch_id=100745&group_id=5470 [Moshe] > -1: Since when have we stopped supporting machines without 4-byte integral > types? Or even non-standard 4 byte integral types? This looks extremely > dangerous. Indeed, Python *does* run on machines that don't have any 4-byte integral types -- or at least it used to . It doesn't run on any without an integral type *at least* 32-bits wide, though. Wouldn't the latter be good enough for this patch? That is, what's the requirement here for *exactly* 32 bits? BTW, a sane collection of typedefs would be another good candidate for pyport.h. From barry@scottb.demon.co.uk Thu Jul 6 20:58:22 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Thu, 6 Jul 2000 20:58:22 +0100 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack In-Reply-To: Message-ID: <000001bfe784$89f69080$060210ac@private> > The effectiveness of this is dependent on guessing a good value (per > platform) for MAX_RECURSION_DEPTH (and it's broken under Windows in 1.5.2). For embedding Python into other apps you need to control the value of MAX_RECURSION_DEPTH at run time. I can then adjust the value to: * take account of my app's impact on the stack usage * limit the depth to get a faster failure from buggy .py modules * work around any bug that gets the value wrong Having a pair of functions to Set/Get the value would be very nice. BArry From esr@thyrsus.com Thu Jul 6 21:35:11 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 16:35:11 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.57556.241282.594629@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 03:41:08PM -0400 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> Message-ID: <20000706163511.A26475@thyrsus.com> Fred L. Drake, Jr. : > If Guido doesn't object to moving this module, the task falls to me > since I wrote it. Were there any requirements you had that the > existing BrowserControl doesn't support? If so, please tell us from > the requirements side. Frankly, what's there strikes me as overly complex and tied to the heavyweight IDLE environment. Here's the latest version of my code for comparison. Comment and critique follows. # Support for launching a browser _browsers = None def iscommand(cmd): # I'd still like to put a cross-platform version of this in the library if os.name == 'posix': return os.system('which 1>/dev/null 2>&1 ' + cmd) == 0 else: return 1 def urlbrowse(url): """Launch a browser, in background if possible, pointed at the given URL. Accept either a string or a parsed URL tuple. Interpret the BROWSER environment variable, if it exists, as a colon-separated list of browser commands to try. """ from urlparse import urlunparse if type(url) == (): url = urlunparse(url) global _browsers if os.environ.has_key("BROWSER"): _browsers = string.split(os.environ["BROWSER"], ":") elif os.name == 'posix': _browsers = ["mozilla %s &", "netscape -remote 'openURL(%s)'", "netscape %s &", "lynx %s", "w3m %s"] elif os.name == 'nt': _browsers = ['start %s'] for browser in _browsers: if _iscommand(string.split(browser)[0]): if os.system((browser % url)) == 0: return 1 return 0 One significant difference is that my code gets the user preference for a browser from an environment variable, rather than a profile. This is appropriate for a preference that will be shared across multiple applications, and follows the pattern of well-known Unix envirinment variables like EDITOR. Another difference is that my code tries harder to have smart default behavior. Notice the order of attempts -- X browsers are tried first in background, then character browsers in the foreground. This means you are more likely to get some reasonable behavior independent of whether the calling Python program is launched from within X, from an Xterm, or on an X-less console. The register() calls seem kind of overelaborate. Why not just update a global dictionary directly? Things I like about the IDLE code, on the other hand...the distinction between open() and open_new() methods is good. It's also clearly smarter about the actual mechanics of browser invocation. I think what I'd like to see is a merged version that starts with your class organization, discards the .ini profile cruft in favor of an environment-variable check, uses my logic for hunting up a browser, and uses your incantations for actually invoking the browser. -- Eric S. Raymond Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their consciences. -- C. S. Lewis From mal@lemburg.com Thu Jul 6 21:28:47 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 22:28:47 +0200 Subject: [Python-Dev] Collection of typedefs for integral types References: Message-ID: <3964EBFF.69202D79@lemburg.com> Tim Peters wrote: > > [moved from patches to Python-Dev] > > >> Patch #100745 has been updated. > >> Visit SourceForge.net for more info. > > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100745&group_id=5470 > > [Moshe] > > -1: Since when have we stopped supporting machines without 4-byte integral > > types? Or even non-standard 4 byte integral types? This looks extremely > > dangerous. > > Indeed, Python *does* run on machines that don't have any 4-byte integral > types -- or at least it used to . It doesn't run on any without an > integral type *at least* 32-bits wide, though. Wouldn't the latter be good > enough for this patch? That is, what's the requirement here for *exactly* > 32 bits? > > BTW, a sane collection of typedefs would be another good candidate for > pyport.h. Good idea. The only problem with typedefs is that they tend to cause conflicts when different definitions are encountered. We'd have to use e.g. Py_UINT4, Py_UINT2, etc... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@beopen.com Thu Jul 6 21:32:36 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 16:32:36 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <3964EBFF.69202D79@lemburg.com> References: <3964EBFF.69202D79@lemburg.com> Message-ID: <14692.60644.899402.407317@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > The only problem with typedefs is that they tend to cause conflicts > when different definitions are encountered. > We'd have to use e.g. Py_UINT4, Py_UINT2, etc... Yes, we'd have to have our own names (unfortunate, but only matters for API functions, not locals). How bad that is depends on what you call "sane". And I'm not going to predict Tim on this! ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Thu Jul 6 21:33:22 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 16:33:22 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: [moved from patches to python-dev] [Bill Tutt] > Code currently in unicodeobject.c needs to do 32-bit arithmetic in > order to work. Additionally, UCS-4 characters (aka UTF-16 surrogate > characters) require 32 bits to represent the true unicode code point of a > surrogate pair. But is the requirement really for *exactly* 32 bits, or for *at least* 32 bits? The problem isn't with feebler machines, it's with higher-end ones: on some Python platforms, even sizeof(short) == 8. As is, your patch will prevent Python from compiling on those. From tim_one@email.msn.com Thu Jul 6 21:42:14 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 16:42:14 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <3964EBFF.69202D79@lemburg.com> Message-ID: >> BTW, a sane collection of typedefs would be another good candidate for >> pyport.h. [M.-A. Lemburg] > Good idea. > > The only problem with typedefs is that they tend to cause conflicts > when different definitions are encountered. > We'd have to use e.g. Py_UINT4, Py_UINT2, etc... Yes, but that's a hell of a lot better than the path the patch in question started going down, w/ its Unicode-specific _PyUnicode_Int32 and (! probably a bug) _PyUNICODE_Int32. From esr@thyrsus.com Thu Jul 6 21:59:31 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 16:59:31 -0400 Subject: [Python-Dev] Dangling locks again Message-ID: <20000706165931.A26662@thyrsus.com> Grrrrr...I can't commit my test patch. Skip has a dangling lock on the Lib directory. -- Eric S. Raymond What, then is law [government]? It is the collective organization of the individual right to lawful defense." -- Frederic Bastiat, "The Law" From fdrake@beopen.com Thu Jul 6 21:51:15 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 16:51:15 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706163511.A26475@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> Message-ID: <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Frankly, what's there strikes me as overly complex and tied to the > heavyweight IDLE environment. Here's the latest version of my code Actually, the code didn't originate in IDLE, but it did originate in a GUI program (never tested on Windows, but it used GTK+, so it might have worked there). > One significant difference is that my code gets the user preference > for a browser from an environment variable, rather than a profile. > This is appropriate for a preference that will be shared across multiple > applications, and follows the pattern of well-known Unix envirinment > variables like EDITOR. Which is great for Unix users, but otherwise stinks. I wasn't real happy with the .ini file thing, but wanted a way to configure it independent of the hosting application. > Another difference is that my code tries harder to have smart default > behavior. Notice the order of attempts -- X browsers are tried first > in background, then character browsers in the foreground. This means > you are more likely to get some reasonable behavior independent of > whether the calling Python program is launched from within X, from an > Xterm, or on an X-less console. I agree that this is good; I'll try and incorporate this. It would require that open/open_new could block (consoles, etc.), but that would be apporopriate in those contexts. > The register() calls seem kind of overelaborate. Why not just > update a global dictionary directly? Perhaps that's the right way to do it, but I'm not completely convinced either. If a GUI library uses this to provide help, and an application like Grail uses that library, Grail should be able to register itself as a help viewer. The exact mechanics are certainly open to debate; I'm not terribly enamored of the machinery there now. > Things I like about the IDLE code, on the other hand...the > distinction between open() and open_new() methods is good. It's also > clearly smarter about the actual mechanics of browser invocation. And I'd like to be able to support several more browsers, especially on Windows. I have no idea how any of this should be done for MacOS machines, either, which should be supportable. > I think what I'd like to see is a merged version that starts with your > class organization, discards the .ini profile cruft in favor of an > environment-variable check, uses my logic for hunting up a browser, > and uses your incantations for actually invoking the browser. I'll see if I can throw something together later today, and send it to python-dev for comments before checking it in. I guess the documentation falls in the category of "Internet Protocols *and Support*"... I don't think it fits anywhere else! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From rassilon@list.org Thu Jul 6 21:53:47 2000 From: rassilon@list.org (Bill Tutt) Date: Thu, 6 Jul 2000 13:53:47 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Tim Peters wrote: > [moved from patches to python-dev] > > [Bill Tutt] > > Code currently in unicodeobject.c needs to do 32-bit arithmetic in > > order to work. Additionally, UCS-4 characters (aka UTF-16 surrogate > > characters) require 32 bits to represent the true unicode code point of a > > surrogate pair. > > But is the requirement really for *exactly* 32 bits, or for *at least* 32 > bits? The problem isn't with feebler machines, it's with higher-end ones: > on some Python platforms, even sizeof(short) == 8. As is, your patch will > prevent Python from compiling on those. Its definately for at least 32 bits. Having a 32 bit specific type lets me not worry about all the issues relating to: What happens if sizeof(int) | sizeof(long) > 32 bits and I failed to compensate for that somehow. Now, the code that I changed to use the typedef might not care about this, but other code using the typedef might. Just color me a paranoid SOB. :) I'd rather always have a 32 bit type for something I know will always require just 32 bits. Bill From tim_one@email.msn.com Thu Jul 6 21:50:50 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 16:50:50 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <14692.60644.899402.407317@cj42289-a.reston1.va.home.com> Message-ID: >> Py_UINT4, Py_UINT2, etc... [Fred Drake] > Yes, we'd have to have our own names (unfortunate, but only matters > for API functions, not locals). How bad that is depends on what you > call "sane". And I'm not going to predict Tim on this! ;) I'm in favor of (as Trent Mick once suggested) getting exactly as insane as C9X: they thought hard about this, and came up with a whole slew of new symbolic names for the roles integral types play. We make typedefs of the same names (well, for as many as we actually *need*) but with Py_ in front of them. In time, as C9X takes over the world, the platform-#ifdef infested section of pyport.h declaring them actually *shrinks*, as more & more platforms support typedef'ing to the std C9X-defined names. From guido@beopen.com Thu Jul 6 22:53:19 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 16:53:19 -0500 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Your message of "Thu, 06 Jul 2000 16:42:14 -0400." References: Message-ID: <200007062153.QAA01183@cj20424-a.reston1.va.home.com> > >> BTW, a sane collection of typedefs would be another good candidate for > >> pyport.h. > > [M.-A. Lemburg] > > Good idea. > > > > The only problem with typedefs is that they tend to cause conflicts > > when different definitions are encountered. > > We'd have to use e.g. Py_UINT4, Py_UINT2, etc... > > Yes, but that's a hell of a lot better than the path the patch in question > started going down, w/ its Unicode-specific _PyUnicode_Int32 and (! probably > a bug) _PyUNICODE_Int32. C already *has* a sane collection of typedefs: short, int, long, maybe combined with unsigned. Plus size_t and so on. There should be only relatively few places where these aren't sufficient: the most common case being when you need the smallest type that's at least 32 bits, which on some systems is spelled as long, on others as int. When you need exactly 32 bits, you're out of luck (e.g. on Crays, it seems, if Tim is right). So it would be better not to write code that depends on exactly 32 (or 16, or 64, or 27) bits. Places where you just *have* to have exactly 32 bits are rare -- perhaps the calculation of 32-bit checksums is commonly done this way, but even there I would expect that it's possible to write the code to be correct for larger int sizes as well. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From rassilon@list.org Thu Jul 6 21:57:10 2000 From: rassilon@list.org (Bill Tutt) Date: Thu, 6 Jul 2000 13:57:10 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Bill Tutt wrote: > > > Its definately for at least 32 bits. > Having a 32 bit specific type lets me not worry about all the issues > relating to: > What happens if sizeof(int) | sizeof(long) > 32 bits and I failed to > compensate for that somehow. > > Now, the code that I changed to use the typedef might not care about this, > but other code using the typedef might. Just color me a paranoid SOB. :) > I'd rather always have a 32 bit type for something I know will always > require just 32 bits. > In any event, having the typedef is still useful since it clarifies the meaning behind the code. Bill From fdrake@beopen.com Thu Jul 6 21:56:21 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 16:56:21 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: References: <14692.60644.899402.407317@cj42289-a.reston1.va.home.com> Message-ID: <14692.62069.784802.306695@cj42289-a.reston1.va.home.com> Tim Peters writes: > I'm in favor of (as Trent Mick once suggested) getting exactly as insane as > C9X: they thought hard about this, and came up with a whole slew of new > symbolic names for the roles integral types play. We make typedefs of the > same names (well, for as many as we actually *need*) but with Py_ in front > of them. In time, as C9X takes over the world, the platform-#ifdef infested > section of pyport.h declaring them actually *shrinks*, as more & more > platforms support typedef'ing to the std C9X-defined names. Hey, if you're happy with C9X, I am too. What I've read about it made me almost think C had a future. But I'd still rather hack in Python. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@beopen.com Thu Jul 6 22:57:09 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 16:57:09 -0500 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Your message of "Thu, 06 Jul 2000 16:50:50 -0400." References: Message-ID: <200007062157.QAA01227@cj20424-a.reston1.va.home.com> > I'm in favor of (as Trent Mick once suggested) getting exactly as insane as > C9X: they thought hard about this, and came up with a whole slew of new > symbolic names for the roles integral types play. We make typedefs of the > same names (well, for as many as we actually *need*) but with Py_ in front > of them. In time, as C9X takes over the world, the platform-#ifdef infested > section of pyport.h declaring them actually *shrinks*, as more & more > platforms support typedef'ing to the std C9X-defined names. Great idea. (Is a summary of these names online somewhere?) It's always good to reuse hard-won knowledge that someone else gathered. (Python is an example of this -- it encodes a lot of hard-won knowledge that I gathered, and more recently also that many other gathered. This rule is also self-referential.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From pingster@ilm.com Thu Jul 6 22:01:49 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Thu, 6 Jul 2000 14:01:49 -0700 (PDT) Subject: [Python-Dev] Hash values and comparing objects In-Reply-To: <3964B39C.7E0CD312@lemburg.com> Message-ID: On Thu, 6 Jul 2000, M.-A. Lemburg wrote: > Previously, Unicode used UTF-8 as basis for calculating the > hash value Right, and i was trying to suggest (in a previous message) that the hash value should be calculated from the actual Unicode character values themselves. Then for any case where it's possible for an 8-bit string to be =3D=3D to a Unicode string, they will have the same hash. Doesn't this solve the problem? Have i misunderstood? > How serious is the need for objects which compare equal to > have the same hash value ? For basic, immutable types like strings -- quite serious indeed, i would imagine. > 2. In some locales '=E4=F6=FC' =3D=3D u'=E4=F6=FC' is true, while in othe= rs this is > not the case. If they do compare equal, the hash values > must match. This sounds very bad. I thought we agreed that attempting to compare (or add) a Unicode string and an 8-bit string containing non-ASCII characters (as in your example) should raise an exception. Such an attempt constitutes an ambiguous request -- you haven't specified how to turn the 8-bit bytes into Unicode, and it's better to be explicit than to have the interpreter guess (and guess differently depending on the environment!!) -- ?!ng From tim_one@email.msn.com Thu Jul 6 22:02:38 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 17:02:38 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: [Bill Tutt] > Its definately for at least 32 bits. > Having a 32 bit specific type lets me not worry about all the issues > relating to: > What happens if sizeof(int) | sizeof(long) > 32 bits and I failed to > compensate for that somehow. Provided you're sticking to unsigned types, there should be few issues here: the behavior of C's unsigned ints is well-defined across platforms. > Now, the code that I changed to use the typedef might not care about this, > but other code using the typedef might. Just color me a paranoid SOB. :) > I'd rather always have a 32 bit type for something I know will always > require just 32 bits. Understood, but you can't have that, not in Python source. I'm -1 on the patch so long as it requires something that can't be had . From esr@thyrsus.com Thu Jul 6 22:16:08 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 17:16:08 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.61763.530974.492605@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 04:51:15PM -0400 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> Message-ID: <20000706171608.A26696@thyrsus.com> Fred L. Drake, Jr. : > > One significant difference is that my code gets the user preference > > for a browser from an environment variable, rather than a profile. > > This is appropriate for a preference that will be shared across multiple > > applications, and follows the pattern of well-known Unix envirinment > > variables like EDITOR. > > Which is great for Unix users, but otherwise stinks. I wasn't real > happy with the .ini file thing, but wanted a way to configure it > independent of the hosting application. Environment variables work for Windows users, too -- and I believe there's a functionally similar name/value pair facility available through system resource forks on the Mac. I really think a profile file is excessively heavyweight here. Environment variables or X resources are a better medium for this kind of shared preference. I've actually been seriously thinking, once this is in the Python library, of going to the Perl and Tcl people and giving them code that would make *their* standard libraries do the right thing with the BROWSER variable. It shouldn't only be portable across Python applications, but across scripting languages as well -- something that would be much harder to do with an .ini file. > And I'd like to be able to support several more browsers, especially > on Windows. I have no idea how any of this should be done for MacOS > machines, either, which should be supportable. I certainly agree with that goal. -- Eric S. Raymond Such are a well regulated militia, composed of the freeholders, citizen and husbandman, who take up arms to preserve their property, as individuals, and their rights as freemen. -- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" referred to in the Second Amendment to the Constitution. From fdrake@beopen.com Thu Jul 6 22:08:55 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:08:55 -0400 (EDT) Subject: [Python-Dev] C9X information Message-ID: <14692.62823.198578.969389@cj42289-a.reston1.va.home.com> http://lglwww.epfl.ch/~wolf/c/c9x_changes.html This contains a summary of changes. Of particular note regarding today's discussion is item #38. GCC (at least recent versions) include the required header. The types are actually defined in for GCC; take a look there for the actual type names. In my installation, it includes things like this: /* Exact integral types. */ /* Signed. */ /* There is some amount of overlap with as known by inet code */ #ifndef __int8_t_defined # define __int8_t_defined typedef signed char int8_t; typedef short int int16_t; typedef int int32_t; # if __WORDSIZE == 64 typedef long int int64_t; # else __extension__ typedef long long int int64_t; # endif #endif /* Unsigned. */ typedef unsigned char uint8_t; typedef unsigned short int uint16_t; typedef unsigned int uint32_t; #if __WORDSIZE == 64 typedef unsigned long int uint64_t; #else __extension__ typedef unsigned long long int uint64_t; #endif /* Small types. */ /* Signed. */ typedef signed char int_least8_t; typedef short int int_least16_t; typedef int int_least32_t; #if __WORDSIZE == 64 typedef long int int_least64_t; #else __extension__ typedef long long int int_least64_t; #endif /* Unsigned. */ typedef unsigned char uint_least8_t; typedef unsigned short int uint_least16_t; typedef unsigned int uint_least32_t; #if __WORDSIZE == 64 typedef unsigned long int uint_least64_t; #else __extension__ typedef unsigned long long int uint_least64_t; #endif /* Fast types. */ /* Signed. */ typedef signed char int_fast8_t; #if __WORDSIZE == 64 typedef long int int_fast16_t; typedef long int int_fast32_t; typedef long int int_fast64_t; #else typedef int int_fast16_t; typedef int int_fast32_t; __extension__ typedef long long int int_fast64_t; #endif /* Unsigned. */ typedef unsigned char uint_fast8_t; #if __WORDSIZE == 64 typedef unsigned long int uint_fast16_t; typedef unsigned long int uint_fast32_t; typedef unsigned long int uint_fast64_t; #else typedef unsigned int uint_fast16_t; typedef unsigned int uint_fast32_t; __extension__ typedef unsigned long long int uint_fast64_t; #endif -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From akuchlin@mems-exchange.org Thu Jul 6 22:11:59 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 6 Jul 2000 17:11:59 -0400 Subject: [Python-Dev] Adding poll() system call Message-ID: <20000706171159.A25398@kronos.cnri.reston.va.us> For work-related reasons I'm looking at Medusa, and noticed that someone in that community wrote a wrapper for the poll() system call: http://www.nightmare.com/medusa/pollmodule.c The Medusa Web page says: The latest version of asyncore.py includes support for this module. poll(2) is much like select(2), but uses an array of structures rather than a bitmap. A major design problem with select(2) is that an fd_set is usually of a fixed maximum size, on many operating systems the kernel needs to rebuilt to raise this limit; even on those that have dynamically adjustable limits, you still need to recompile your application (because FD_SETSIZE is a macro). I'd suggest adding poll() to 2.0, and will submit a patch if given the go-ahead. But where should it go? A whole module for it seems excessive; should it go in posixmodule, or maybe select? (I can't figure out the POSIX status of poll(), though the Open Group does have a man page for it: http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html). --amk From guido@beopen.com Thu Jul 6 23:04:25 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 17:04:25 -0500 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Your message of "Thu, 06 Jul 2000 13:57:10 MST." References: Message-ID: <200007062204.RAA01266@cj20424-a.reston1.va.home.com> > In any event, having the typedef is still useful since it clarifies the > meaning behind the code. Actually, the typedef doesn't clarify the "== 32" vs ">= 32" issue at all! Many people appear to be thinking that an uint32 is guaranteed to be exactly 32 bits while this is in fact not guaranteed if you want full portability. Sometimes there *is* no 32-bit data type. The native data types don't have this problem -- but they have other problems because there's no native data type guaranteed to be "the smalles type >= 32 bits". Let's wait for what C9X does here. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From rassilon@list.org Thu Jul 6 22:16:50 2000 From: rassilon@list.org (Bill Tutt) Date: Thu, 6 Jul 2000 14:16:50 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: <200007062204.RAA01266@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 6 Jul 2000, Guido van Rossum wrote: > > In any event, having the typedef is still useful since it clarifies the > > meaning behind the code. > How about this: /* * Use this typedef when you need to represent a UTF-16 surrogate pair * as single unsigned integer. */ #if SIZEOF_INT >= 4 typedef unsigned int Py_UCS4; #else #if SIZEOF_LONG >= 4 typedef unsigned long Py_UCS4; #else #error "can't find integral type that can contain 32 bits" #endif /* SIZEOF_LONG */ #endif /* SIZEOF_INT */ Bill From guido@beopen.com Thu Jul 6 23:16:54 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 17:16:54 -0500 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: Your message of "Thu, 06 Jul 2000 17:16:08 -0400." <20000706171608.A26696@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> Message-ID: <200007062216.RAA01333@cj20424-a.reston1.va.home.com> [ESR] > Environment variables work for Windows users, too -- and I believe > there's a functionally similar name/value pair facility available > through system resource forks on the Mac. I really think a profile > file is excessively heavyweight here. Environment variables or X > resources are a better medium for this kind of shared preference. > > I've actually been seriously thinking, once this is in the Python > library, of going to the Perl and Tcl people and giving them code that > would make *their* standard libraries do the right thing with the > BROWSER variable. It shouldn't only be portable across Python > applications, but across scripting languages as well -- something that > would be much harder to do with an .ini file. But on Windows, there is already a registry setting to choose the browser. No native Windows user (as opposed to transplanted Unix users like you & me :-) is going to understand why they have to set an environment variable (something they believe is old-fashioned and mostly needed for the obscure and -- in their eyes -- equally obscure "DOS box") to change a preference that the system already knows perfectly well. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From pingster@ilm.com Thu Jul 6 22:16:07 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Thu, 6 Jul 2000 14:16:07 -0700 (PDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <20000706171159.A25398@kronos.cnri.reston.va.us> Message-ID: On Thu, 6 Jul 2000, Andrew Kuchling wrote: > > I'd suggest adding poll() to 2.0, and will submit a patch if given the > go-ahead. But where should it go? A whole module for it seems > excessive; should it go in posixmodule, or maybe select? posix would make sense to me. Actually, is there any good reason why select isn't in posix also? -- ?!ng "There's no point in being grown up if you can't be childish sometimes." -- Dr. Who From fdrake@beopen.com Thu Jul 6 22:23:08 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:23:08 -0400 (EDT) Subject: [Python-Dev] Re: forwarded message from Eric S. Raymond In-Reply-To: <14692.62818.835847.439551@beluga.mojam.com> References: <14692.61900.716303.447956@cj42289-a.reston1.va.home.com> <14692.62818.835847.439551@beluga.mojam.com> Message-ID: <14692.63676.527282.630370@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > Eric, my apologies. It would be real nice if SF could/would list locks that > are older than a few seconds (minutes?) when browsing the CVS repository. I think this is a good idea! I just filed the following bug report/ feature request: http://sourceforge.net/bugs/?func=detailbug&bug_id=108997&group_id=1 Feel free to add a comments explaining why this would be such a good idea! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@beopen.com Thu Jul 6 23:25:46 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 17:25:46 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Thu, 06 Jul 2000 14:16:07 MST." References: Message-ID: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> > > I'd suggest adding poll() to 2.0, and will submit a patch if given the > > go-ahead. But where should it go? A whole module for it seems > > excessive; should it go in posixmodule, or maybe select? > > posix would make sense to me. Yes, definitely. (The posix module contains lots of non-Posix stuff -- it was a way of saying Unix without pronouncing it.) > Actually, is there any good reason why select isn't in posix also? Yes -- select also works on Windows and DOS. (Ditto for socket.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From akuchlin@mems-exchange.org Thu Jul 6 22:28:31 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 6 Jul 2000 17:28:31 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007062225.RAA01376@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 05:25:46PM -0500 References: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> Message-ID: <20000706172831.B25398@kronos.cnri.reston.va.us> On Thu, Jul 06, 2000 at 05:25:46PM -0500, Guido van Rossum wrote: >> Actually, is there any good reason why select isn't in posix also? >Yes -- select also works on Windows and DOS. (Ditto for socket.) I don't know if poll() is available on Windows; anyone got a clue? poll() for DOS is almost certainly out of the question, and who cares these days? --amk From gstein@lyra.org Thu Jul 6 22:31:13 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 14:31:13 -0700 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706122122.A25613@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 06, 2000 at 12:21:22PM -0400 References: <20000706122122.A25613@thyrsus.com> Message-ID: <20000706143113.I29590@lyra.org> On Thu, Jul 06, 2000 at 12:21:22PM -0400, Eric S. Raymond wrote: > Having finally wrestled CVS into at least temporary submission, Eric, For the record, can you state what was wrong and how you fixed it? If/when others run into the same problem, then it will be great to know. thx! -g -- Greg Stein, http://www.lyra.org/ From fdrake@beopen.com Thu Jul 6 22:29:38 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:29:38 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062216.RAA01333@cj20424-a.reston1.va.home.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> Message-ID: <14692.64066.241359.276620@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > But on Windows, there is already a registry setting to choose the > browser. No native Windows user (as opposed to transplanted Unix > users like you & me :-) is going to understand why they have to set an > environment variable (something they believe is old-fashioned and Exactly. On Windows, the existing code does the right thing and uses the registry settings. Or rather, it uses the Windows calls that make use of the registry settings, just like if you double-click on an HTML file directly. Which doesn't mean that BROWSER is the wrong thing on Unix; I'll take that into consideration (which does *not* mean I'll agree! Haven't decided yet, but it has clear merit). If someone "native" in the MacOS world can describe the right thing there, or provide a patch, that would be wonderful! I know about Internet Config, I just don't know what to do with it. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Thu Jul 6 22:31:18 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:31:18 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> References: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> Message-ID: <14692.64166.938741.169194@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > Yes -- select also works on Windows and DOS. (Ditto for socket.) That doesn't answer the question. Why select.select() instead of os.select()? I've never understood that one myself. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Thu Jul 6 22:37:56 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 17:37:56 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <200007062153.QAA01183@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > C already *has* a sane collection of typedefs: short, int, long, maybe > combined with unsigned. Those aren't typedefs, they're types, and the direct use of them was the cause of almost all of Trent Mick's Win64 porting pains. The std makes very weak promises about the std integral types, and Python (like all other C code that uses them directly!) accumulated lots of unwarranted assumptions. Rather than fix this with sane typedefs, we're now getting increasing amounts of ugly and brittle #ifdef'ed code keying off preprocessor symbols (like SIZEOF_LONG etc). > Plus size_t and so on. Those are typedefs. C9X adds more of that ilk, like "integral type big enough to hold a casted pointer", which current C doesn't address at all beyond guaranteeing there's *some* (unnamed) suitable type (and the lack of a typedef for which in Python accounted for maybe half of Trent's patches). > There should be only relatively few places where these aren't > sufficient: the most common case being when you need the smallest type > that's at least 32 bits, which on some systems is spelled as long, on > others as int. Agreed, and that's specifically what this patch needs (provided Bill gets over his paranoia ). > When you need exactly 32 bits, you're out of luck (e.g. on Crays, it > seems, if Tim is right). That sizeof(short) == 8 is in part why Python's long ints are currently broken on the J90 (the other reason is that the J90 has the only compiler I know of that does not generate code to sign-extend right shifts of signed integral types). > So it would be better not to write code that depends on exactly 32 (or > 16, or 64, or 27) bits. Places where you just *have* to have exactly > 32 bits are rare -- perhaps the calculation of 32-bit checksums is > commonly done this way, but even there I would expect that it's > possible to write the code to be correct for larger int sizes as well. Absolutely: the new crc32 checksum in Python was written this way (to require ints at least 32 bits, but tolerate ints larger than that). It is not, however, good that the code *spells* that requirement "unsigned long"! As obscure as can be. My position remains the same: adopt the C9X names for as many of the new integral synonyms as we *need*, but stick "Py_" in front of them. the-committee-wasn't-just-jerking-off-the-last-10-years-ly y'rs - tim From fdrake@beopen.com Thu Jul 6 22:41:43 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:41:43 -0400 (EDT) Subject: [Python-Dev] forwarded message from noreply@sourceforge.net Message-ID: <14692.64791.704062.354485@cj42289-a.reston1.va.home.com> --ELh5iOC7in Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit Skip, Looks like the bug manager works much like we wish the patch manager did! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member --ELh5iOC7in Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit Return-Path: Received: from delerium.i.sourceforge.net (sourceforge.net [198.186.203.33]) by mailhost.beopen.com (8.9.3/8.9.3) with ESMTP id OAA20677 for ; Thu, 6 Jul 2000 14:33:37 -0700 Received: (from nobody@localhost) by delerium.i.sourceforge.net (8.9.3/8.9.3) id OAA04044; Thu, 6 Jul 2000 14:34:48 -0700 Message-Id: <200007062134.OAA04044@delerium.i.sourceforge.net> From: noreply@sourceforge.net To: fdrake@beopen.com, 0@delerium.i.sourceforge.net Subject: [Bug #108997] CVS browsing should show old locks Date: Thu, 6 Jul 2000 14:34:48 -0700 Bug #108997, was updated on 2000-Jul-06 17:21 Here is a current snapshot of the bug. Project: SourceForge Category: User Interface Status: Open Resolution: None Bug Group: None Priority: 5 Summary: CVS browsing should show old locks Details: Browsing the CVS repository of a project should show locks files older than a couple of minutes. This can help diagnose problems, such as (fairly common) read locks that weren't properly removed. Follow-Ups: Date: 2000-Jul-06 17:34 By: montanaro Comment: Agreed. As someone who has somehow left two locks laying about in the Python repository (and caused a fair amount of needless grief in the process), I would like to have this information. I suggest adding an extra column to the CVS browse listings. It would be great if you gave a way for developers to remove their own stale locks (perhaps by highlighting those locks with a link as appropriate). Skip Montanaro skip@mojam.com ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=108997&group_id=1 --ELh5iOC7in-- From mal@lemburg.com Thu Jul 6 22:42:08 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 23:42:08 +0200 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode References: Message-ID: <3964FD30.BB0F14D1@lemburg.com> Bill Tutt wrote: > > On Thu, 6 Jul 2000, Guido van Rossum wrote: > > > > In any event, having the typedef is still useful since it clarifies the > > > meaning behind the code. > > > > How about this: > /* > * Use this typedef when you need to represent a UTF-16 surrogate pair > * as single unsigned integer. > */ > #if SIZEOF_INT >= 4 > typedef unsigned int Py_UCS4; > #else > #if SIZEOF_LONG >= 4 > typedef unsigned long Py_UCS4; > #else > #error "can't find integral type that can contain 32 bits" > #endif /* SIZEOF_LONG */ > #endif /* SIZEOF_INT */ I like the name... Py_UCS4 is indeed what we're talking about here. What I don't understand is why you raise a compile error; AFAIK, unsigned long is at least 32 bits on all platforms and that's what the Unicode implementation would need to support UCS4 -- more bits don't do any harm since the storage type is fixed at 16-bit UTF-16 values. Ideal would be combining the above with the C9X typedefs, e.g. typedef uint4_t Py_UCS4; -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip@mojam.com (Skip Montanaro) Thu Jul 6 22:47:32 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 6 Jul 2000 16:47:32 -0500 (CDT) Subject: [Python-Dev] Problems with 2.0b1 and GCC Message-ID: <14692.65140.525706.197488@beluga.mojam.com> I thought I had this fixed, but apparently not. On my Linux (Mandrake 6.1 with some stuff from 7.1), I'm getting the following traceback in certain situations when running an oldish version of Zope (2.0.0): (gdb) bt #0 0x400712e8 in sigsuspend () from /lib/libc.so.6 #1 0x401471a0 in __DTOR_END__ () from /lib/libc.so.6 Yesterday I removed pgcc and egcs (both were installed for some reason) and upgraded the compilation environment to the following: gcc-c++-2.95.2-7mdk gcc-cpp-2.95.2-7mdk binutils-2.9.5.0.31-1mdk glibc-devel-2.1.1-15mdk glibc-2.1.1-15mdk compat-glibc-5.3-2.0.7.5mdk gcc-2.95.2-7mdk (Am I missing an important package that needs updating in the list above?) I had noticed the same traceback in test_fork1.py after I removed pgcc and installed gcc 2.95 and friends, but before I realized I had egcs installed. Deleting egcs cured the problem in at least some situations, but apparently not all. Anybody seen this? I suspect it has something to do with threading (which Zope requires). My Python directory tree is up-to-date wrt the CVS repository and was configured as ./configure --with-threads --with-cycle-gc --prefix=/usr and compiled as make OPT=-g I will try turning off cycle-gc. Any other thoughts from the assembled compilation gurus? Thx, Skip From guido@beopen.com Thu Jul 6 23:54:36 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 17:54:36 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Thu, 06 Jul 2000 17:31:18 -0400." <14692.64166.938741.169194@cj42289-a.reston1.va.home.com> References: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> <14692.64166.938741.169194@cj42289-a.reston1.va.home.com> Message-ID: <200007062254.RAA01617@cj20424-a.reston1.va.home.com> > That doesn't answer the question. Why select.select() instead of > os.select()? I've never understood that one myself. Different platform dependencies. The select module works on Windows, Mac and Unix. The posix module only runs on Unix and (under the name "nt", but using the same source file) on Win32. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gmcm@hypernet.com Thu Jul 6 22:55:20 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 6 Jul 2000 17:55:20 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> References: <20000706163511.A26475@thyrsus.com> Message-ID: <1249201972-6842244@hypernet.com> Fred L. Drake, Jr. wrote: > And I'd like to be able to support several more browsers, > especially > on Windows. That's what "start %s" % url does. The intent is the same as $EDITOR, though the mechanics make Rube Goldberg look boringly practical. - Gordon From mal@lemburg.com Thu Jul 6 22:53:59 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 23:53:59 +0200 Subject: [Python-Dev] Hash values and comparing objects References: Message-ID: <3964FFF7.A2D8AFFF@lemburg.com> Ka-Ping Yee wrote: > > On Thu, 6 Jul 2000, M.-A. Lemburg wrote: > > Previously, Unicode used UTF-8 as basis for calculating the > > hash value > > Right, and i was trying to suggest (in a previous message) > that the hash value should be calculated from the actual > Unicode character values themselves. Then for any case where > it's possible for an 8-bit string to be == to a Unicode > string, they will have the same hash. Doesn't this solve the > problem? Have i misunderstood? Not really, since the default encoding doesn't necessarily need to have anything to do with a Unicode subset, e.g. take one of the many Windows code pages. > > How serious is the need for objects which compare equal to > > have the same hash value ? > > For basic, immutable types like strings -- quite serious indeed, > i would imagine. What I meant was: would it do much harm if hash(unicode)==hash(string) would only be guaranteed for ASCII only values -- even though unicode may compare equal to string. > > 2. In some locales 'äöü' == u'äöü' is true, while in others this is > > not the case. If they do compare equal, the hash values > > must match. > > This sounds very bad. I thought we agreed that attempting to > compare (or add) a Unicode string and an 8-bit string containing > non-ASCII characters (as in your example) should raise an exception. Only if the default encoding is ASCII. If Python runs in a different locale environment that encoding can change, e.g. to Latin-1 or one of the available code pages (this is to enhance Python's compatibility with the underlying environment). > Such an attempt constitutes an ambiguous request -- you haven't > specified how to turn the 8-bit bytes into Unicode, and it's better > to be explicit than to have the interpreter guess (and guess > differently depending on the environment!!) The interpreter doesn't guess, it uses the locale setting as defined by the user. If the programmer wants to be sure about what encoding is actually used, he will have to be explicit about it. That's what I would recommend for most applications, BTW. The auto-conversion magic is mainly meant for simplifying intergration of Unicode into existing systems. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From esr@thyrsus.com Thu Jul 6 23:04:51 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 18:04:51 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062216.RAA01333@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 05:16:54PM -0500 References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> Message-ID: <20000706180451.D26696@thyrsus.com> Guido van Rossum : > But on Windows, there is already a registry setting to choose the > browser. No native Windows user (as opposed to transplanted Unix > users like you & me :-) is going to understand why they have to set an > environment variable (something they believe is old-fashioned and > mostly needed for the obscure and -- in their eyes -- equally obscure > "DOS box") to change a preference that the system already knows > perfectly well. In my design the environment variable is only there as an optional override. Most of the time, the smart defaults do the right thing. -- Eric S. Raymond The most foolish mistake we could possibly make would be to permit the conquered Eastern peoples to have arms. History teaches that all conquerors who have allowed their subject races to carry arms have prepared their own downfall by doing so. -- Hitler, April 11 1942, revealing the real agenda of "gun control" From skip@mojam.com (Skip Montanaro) Thu Jul 6 22:56:40 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 6 Jul 2000 16:56:40 -0500 (CDT) Subject: [Python-Dev] Problems with 2.0b1 and GCC In-Reply-To: <14692.65140.525706.197488@beluga.mojam.com> References: <14692.65140.525706.197488@beluga.mojam.com> Message-ID: <14693.152.401254.99695@beluga.mojam.com> Skip> I will try turning off cycle-gc. Did not help. (Neil, you can go home if you like... ;-) *sigh* Skip From tim_one@email.msn.com Thu Jul 6 22:55:10 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 17:55:10 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: [Bill Tutt] > How about this: > /* > * Use this typedef when you need to represent a UTF-16 surrogate pair > * as single unsigned integer. > */ > #if SIZEOF_INT >= 4 > typedef unsigned int Py_UCS4; > #else > #if SIZEOF_LONG >= 4 > typedef unsigned long Py_UCS4; > #else > #error "can't find integral type that can contain 32 bits" > #endif /* SIZEOF_LONG */ > #endif /* SIZEOF_INT */ Much better! In the future (when the infrastructure is in place), I expect we'll replace the #if stuff here with typedef Py_uint_least32_t UCS4; instead (where Py_uint_least32_t is defined in pyfort.h, and uint_least32_t is the C9X spelling of the true requirement). BTW, why not use #elif instead of nested #ifs? #elif is clearer and shorter. From gstein@lyra.org Thu Jul 6 23:00:42 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:00:42 -0700 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: <3964FD30.BB0F14D1@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 11:42:08PM +0200 References: <3964FD30.BB0F14D1@lemburg.com> Message-ID: <20000706150042.K29590@lyra.org> On Thu, Jul 06, 2000 at 11:42:08PM +0200, M.-A. Lemburg wrote: > Bill Tutt wrote: > > > > On Thu, 6 Jul 2000, Guido van Rossum wrote: > > > > > > In any event, having the typedef is still useful since it clarifies the > > > > meaning behind the code. > > > > > > > How about this: > > /* > > * Use this typedef when you need to represent a UTF-16 surrogate pair > > * as single unsigned integer. > > */ > > #if SIZEOF_INT >= 4 > > typedef unsigned int Py_UCS4; > > #else > > #if SIZEOF_LONG >= 4 > > typedef unsigned long Py_UCS4; > > #else > > #error "can't find integral type that can contain 32 bits" > > #endif /* SIZEOF_LONG */ > > #endif /* SIZEOF_INT */ > > I like the name... Py_UCS4 is indeed what we're talking about > here. > > What I don't understand is why you raise a compile error; AFAIK, > unsigned long is at least 32 bits on all platforms and that's > what the Unicode implementation would need to support UCS4 -- more > bits don't do any harm since the storage type is fixed at > 16-bit UTF-16 values. Agreed. Some logic is still desirable (picking "int" over "long" is goodness), but the error is not needed. Python simply does not work if a long is not at least 32 bits. Period. No reason for an error. > Ideal would be combining the above with the C9X typedefs, > e.g. typedef uint4_t Py_UCS4; Actually, uint_fast32_t Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Jul 6 23:02:10 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:02:10 -0700 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: ; from tim_one@email.msn.com on Thu, Jul 06, 2000 at 05:37:56PM -0400 References: <200007062153.QAA01183@cj20424-a.reston1.va.home.com> Message-ID: <20000706150210.L29590@lyra.org> On Thu, Jul 06, 2000 at 05:37:56PM -0400, Tim Peters wrote: >... > My position remains the same: adopt the C9X names for as many of the new > integral synonyms as we *need*, but stick "Py_" in front of them. Why should we insert the Py_ prefix? We can just use autoconf to test for the types. If present, then we use them. If not, then we define our own replacements. I see no particular reason to complicate it with Py_. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido@beopen.com Fri Jul 7 00:00:33 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 18:00:33 -0500 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: Your message of "Thu, 06 Jul 2000 18:04:51 -0400." <20000706180451.D26696@thyrsus.com> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> <20000706180451.D26696@thyrsus.com> Message-ID: <200007062300.SAA01689@cj20424-a.reston1.va.home.com> > In my design the environment variable is only there as an optional override. > Most of the time, the smart defaults do the right thing. Ah. I came in on the tail end of the discussion. This makes sense. BTW, Eric, do you happen to know the folks at SF who wrote the Patch Manager? I and some of the others here at PythonLabs would love to get together with them at the O'Reilly conference (if they are going there) or at some other time to discuss how to kmake the PM better. We've got a lot of experience now! (And obviously we also have some suggestions for the CVS feature regarding cleaning up of locks.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake@beopen.com Thu Jul 6 23:01:28 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 18:01:28 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <1249201972-6842244@hypernet.com> References: <20000706163511.A26475@thyrsus.com> <1249201972-6842244@hypernet.com> Message-ID: <14693.440.602599.536953@cj42289-a.reston1.va.home.com> Gordon McMillan writes: > That's what "start %s" % url does. The intent is the same as > $EDITOR, though the mechanics make Rube Goldberg look > boringly practical. No, that supports "Whatever the user set as their default browser," and is the right default for Windows. It doesn't let me use a drop-down box in a GUI to say "This application should Opera for help, even though Navigator is the default." *That's* what I'd like to be able to do, because then there's a chance of being able to separate open() and open_new(). (And just 'cause I'm a little anal about allowing this kind of configurability that no more than one in a thousand will care about. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@beopen.com Fri Jul 7 00:03:42 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 18:03:42 -0500 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Your message of "Thu, 06 Jul 2000 15:02:10 MST." <20000706150210.L29590@lyra.org> References: <200007062153.QAA01183@cj20424-a.reston1.va.home.com> <20000706150210.L29590@lyra.org> Message-ID: <200007062303.SAA01719@cj20424-a.reston1.va.home.com> > Why should we insert the Py_ prefix? We can just use autoconf to test for > the types. If present, then we use them. If not, then we define our own > replacements. > > I see no particular reason to complicate it with Py_. Defensive coding. If the names are somehow present on the system but somehow not detected by configure, Python.h would run into trouble when it tries to define them when they are in fact already defined by some 3rd party extensiom module that includes the necessary magic to reveal the system definitinons for these names... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas@xs4all.net Thu Jul 6 23:04:07 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 7 Jul 2000 00:04:07 +0200 Subject: [Python-Dev] Grammar help. Message-ID: <20000707000407.E26534@xs4all.nl> Argh, my head hurts ! :P I need some help with the Python Grammar. Or rather, the Parser. I'm trying to add some new syntax to the current CVS snapshot, something Guido said he would like to see: built-in 'range'-like list creation, so that '[1:10]' is the same as 'range(1,10)'. The code isn't the problem, that's all done and it all works, but the problem is that it somehow broke normal list literals ! :-P Here's what I did. The current definition of 'atom' is: atom: '(' [testlist] ')' | '[' [testlist] ']' | << ... >> testlist: test (',' test)* [','] I tried adding it like this: atom: '(' [testlist] ')' | '[' [listmaker] ']' | << ... >> testlist: test (',' test)* [','] listmaker: testlist | rangemaker rangemaker: [test] ':' test And as I said, it works -- for the new syntax. But not for the old one. When I start the interpreter, here's what I see: XXX ambiguity! [snip] XXX ambiguity! 'import site' failed; traceback: File "./Lib/site.py", line 93 prefixes = [sys.prefix] ^ >>> [2:20] [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] >>> [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] File "", line 1 [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] ^ SyntaxError: invalid syntax So, for some reason it doesn't recognize the old list literals als valid syntax. And it probably has to do with ambiguity ;) But I can't, for the life of me, figure out what's so ambiguous about it. As far as I can tell, a bare 'test' can't be a ':', and 'rangemaker' always needs a ':'. Is this some kind of limitation in the Parser that I need to work around ? I tried reading the parser code, and I'm glad my head is reattached ;P Hints-greatly-appreciated-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip@mojam.com (Skip Montanaro) Thu Jul 6 23:06:05 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 6 Jul 2000 17:06:05 -0500 (CDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062300.SAA01689@cj20424-a.reston1.va.home.com> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> <20000706180451.D26696@thyrsus.com> <200007062300.SAA01689@cj20424-a.reston1.va.home.com> Message-ID: <14693.717.789360.222392@beluga.mojam.com> Guido> BTW, Eric, do you happen to know the folks at SF who wrote the Guido> Patch Manager? .... We've got a lot of experience now! Python was #19 on the top projects list a few days ago and is #14 now. Not bad at all for software rated as mature... (is that sort of like PG-13?) Skip From esr@thyrsus.com Thu Jul 6 23:15:57 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 18:15:57 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062300.SAA01689@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 06:00:33PM -0500 References: <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> <20000706180451.D26696@thyrsus.com> <200007062300.SAA01689@cj20424-a.reston1.va.home.com> Message-ID: <20000706181557.A26994@thyrsus.com> Guido van Rossum : > BTW, Eric, do you happen to know the folks at SF who wrote the Patch > Manager? I and some of the others here at PythonLabs would love to > get together with them at the O'Reilly conference (if they are going > there) or at some other time to discuss how to kmake the PM better. > We've got a lot of experience now! (And obviously we also have some > suggestions for the CVS feature regarding cleaning up of locks.) I don't know who they are, but I can find out. -- Eric S. Raymond Idealism is the noble toga that political gentlemen drape over their will to power. -- Aldous Huxley From gmcm@hypernet.com Thu Jul 6 23:11:46 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 6 Jul 2000 18:11:46 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.440.602599.536953@cj42289-a.reston1.va.home.com> References: <1249201972-6842244@hypernet.com> Message-ID: <1249200987-6901559@hypernet.com> Fred L. Drake, Jr. wrote: > > Gordon McMillan writes: > > That's what "start %s" % url does. The intent is the same as > > $EDITOR, though the mechanics make Rube Goldberg look > boringly > practical. > > No, that supports "Whatever the user set as their default > browser," > and is the right default for Windows. It doesn't let me use a > drop-down box in a GUI to say "This application should Opera for > help, even though Navigator is the default." *That's* what I'd > like to be able to do, because then there's a chance of being > able to separate open() and open_new(). (And just 'cause I'm a > little anal about allowing this kind of configurability that no > more than one in a thousand will care about. ;) No, Fred, you're not one in a thousand, you're *completely* unique. What 999/1000 Windows users will want is to have the help in a .chm. - Gordon From Vladimir.Marangozov@inrialpes.fr Thu Jul 6 23:18:02 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 7 Jul 2000 00:18:02 +0200 (CEST) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jul 06, 2000 12:51:51 PM Message-ID: <200007062218.AAA02492@python.inrialpes.fr> Fred L. Drake, Jr. wrote: > > [MAL] > > Might be a good candidate for the std lib if you ask me -- > > after a rename to say "browser.py". > > Agh! That was my original name for it! Guido wanted me to change > it since that didn't describe it well (there's not a single browser > implementation in there ;). It this is gonna be a standalone library module, and from what I've seen in this thread, I think that "browser.py" is too generic as a term. The module addresses web browsers (not text browsers, info browsers, file browsers...), so it would be nice to clarify this distinction unless the module is intended to supports any kind of browsers. Here are more options: webbrowser.py, wwwbrowser.py, webclient.py ... -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From fdrake@beopen.com Thu Jul 6 23:15:53 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 18:15:53 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.717.789360.222392@beluga.mojam.com> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> <20000706180451.D26696@thyrsus.com> <200007062300.SAA01689@cj20424-a.reston1.va.home.com> <14693.717.789360.222392@beluga.mojam.com> Message-ID: <14693.1305.576040.512179@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > Python was #19 on the top projects list a few days ago and is #14 now. Not > bad at all for software rated as mature... (is that sort of like PG-13?) "Top projects" seems to be measured in downloads of released files; we're in the "Most active" list, and I'm not sure what those numbers represent... percentiles? (I.e., we've made more checkins than 99.36% of the projects at SF, using the number right now.) The "Most active ..." header should be a link to a explanation! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Thu Jul 6 23:21:37 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 18:21:37 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062218.AAA02492@python.inrialpes.fr> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <200007062218.AAA02492@python.inrialpes.fr> Message-ID: <14693.1649.220462.187258@cj42289-a.reston1.va.home.com> Vladimir Marangozov writes: > Here are more options: webbrowser.py, wwwbrowser.py, webclient.py ... Excellent! I'll take "webbrowser.py". -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gward@mems-exchange.org Thu Jul 6 23:22:56 2000 From: gward@mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 18:22:56 -0400 Subject: [Python-Dev] Grammar help. In-Reply-To: <20000707000407.E26534@xs4all.nl>; from thomas@xs4all.net on Fri, Jul 07, 2000 at 12:04:07AM +0200 References: <20000707000407.E26534@xs4all.nl> Message-ID: <20000706182256.A15938@ludwig.cnri.reston.va.us> On 07 July 2000, Thomas Wouters said: > Argh, my head hurts ! :P Yeah, but try writing your *own* parser-generator. >grin< > Here's what I did. The current definition of 'atom' is: > > atom: '(' [testlist] ')' | '[' [testlist] ']' | << ... >> > testlist: test (',' test)* [','] > > I tried adding it like this: > > atom: '(' [testlist] ')' | '[' [listmaker] ']' | << ... >> > testlist: test (',' test)* [','] > listmaker: testlist | rangemaker > rangemaker: [test] ':' test I think the problem is this: * one possible candidate for atom is: '[' listmaker * two candidates for listmaker: testlist or rangemaker * but both of these start with a test; the fact that one of them is optional is probably beside the point * the parser needs to see ',' or ':' to know if it's got a testlist or a rangemaker: but because a test could be any number of tokens, it would need infinite lookahead. (I think.) Since this is a recursive-descent parser, it is most likely LL(1) -- at most one token of lookahead. Not good enough. Another, entirely hypothetical way of looking at it (based on experience with a completely different recursive descent parser generator (PCCTS/ANTLR) and dim recollections of the Dragon Book): * parser sees a '[' token and enters the 'atom' state (ie. calls a subroutine 'atom()') * swallows the '[' and immediately enters 'listmaker' (no other option) * now it wants to enter either 'testlist' or 'rangemaker': but the FIRST(testlist) == FIRST(test) (testlist can only start with a test), and FIRST(rangemaker) == FIRST(test) + ':' (rangemaker can start with a test or the ':' token) * I suspect this is the ambiguity: overlap in the FIRST sets of testlist and rangemaker The fix? Hmmm, I dunno. Never hacked on the Python grammar myself, and it's been a while since I hacked seriously on any grammar. Maybe the people (person?) who really understands this stuff will have an idea... Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From fdrake@beopen.com Thu Jul 6 23:24:57 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 18:24:57 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <1249200987-6901559@hypernet.com> References: <1249201972-6842244@hypernet.com> <1249200987-6901559@hypernet.com> Message-ID: <14693.1849.276233.217728@cj42289-a.reston1.va.home.com> Gordon McMillan writes: > No, Fred, you're not one in a thousand, you're *completely* > unique. What 999/1000 Windows users will want is to have > the help in a .chm. Dabnarbit, those Windows users are gettin' smart again... I'll havta put a few in their place! Harrumph! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr@thyrsus.com Thu Jul 6 23:33:32 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 18:33:32 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.1649.220462.187258@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 06:21:37PM -0400 References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <200007062218.AAA02492@python.inrialpes.fr> <14693.1649.220462.187258@cj42289-a.reston1.va.home.com> Message-ID: <20000706183332.B27129@thyrsus.com> Fred L. Drake, Jr. : > > Vladimir Marangozov writes: > > Here are more options: webbrowser.py, wwwbrowser.py, webclient.py ... > > Excellent! I'll take "webbrowser.py". That works for me, too. -- Eric S. Raymond Live free or die; death is not the worst of evils. -- General George Stark. From gward@mems-exchange.org Thu Jul 6 23:38:10 2000 From: gward@mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 18:38:10 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706163511.A26475@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 06, 2000 at 04:35:11PM -0400 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> Message-ID: <20000706183810.B15938@ludwig.cnri.reston.va.us> On 06 July 2000, Eric S. Raymond said: > def iscommand(cmd): > # I'd still like to put a cross-platform version of this in the library > if os.name == 'posix': > return os.system('which 1>/dev/null 2>&1 ' + cmd) == 0 > else: > return 1 Speaking of heavyweight, this strikes me as excessive: N * 2 fork/execs, each of which will scan PATH anew, just to determine if a command exists? (OK, only N if 'which' is a shell built-in.) Why not scan PATH once yourself if you really need to determine a priori which command will fail? Easy to do since this will only be done on Unix. Alternately: > def urlbrowse(url): [...] > for browser in _browsers: > if _iscommand(string.split(browser)[0]): > if os.system((browser % url)) == 0: > return 1 > return 0 Rearrange this loop so it tries os.system() on each one in turn, and completes (successfully) when it finds one that works. (think think think) Ooh, that may not work so well because of the need to background X browsers. Ick. One could dream up a wild scheme that forks and forks and does the backgrounding itself, but what the hell: we're launching a big fat hairy *web browser* here, what does it matter if a shell is involved to parse the "&"? Maybe iscommand() is useful after all; I still think it should do its own PATH-scanning, though. Also, the wild variability of "which" across platforms and shells makes me wonder if, somewhere out there, there isn't a "which" that fails to return true/false on success. (check check check). Yes, there is: with bash 2.0.3 on Solaris 2.6: $ if which ls 1>/dev/null 2>&1 ; then echo yes ; fi yes $ if which skdfhjkjahdfs 1>/dev/null 2>&1 ; then echo yes ; fi yes ... so much for trusting "which" (I never did, anyways). Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From bwarsaw@beopen.com Thu Jul 6 23:44:50 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 18:44:50 -0400 (EDT) Subject: [Python-Dev] Dangling locks again References: <20000706165931.A26662@thyrsus.com> Message-ID: <14693.3042.926389.117529@anthem.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> Grrrrr...I can't commit my test patch. Skip has a dangling ESR> lock on the Lib directory. I already put in an SF request to get this cleaned. From gward@mems-exchange.org Thu Jul 6 23:47:18 2000 From: gward@mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 18:47:18 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000706121231.A14042@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Jul 06, 2000 at 12:12:31PM -0400 References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> <14692.680.483792.544003@cj42289-a.reston1.va.home.com> <20000706121231.A14042@kronos.cnri.reston.va.us> Message-ID: <20000706184718.C15938@ludwig.cnri.reston.va.us> On 06 July 2000, Andrew Kuchling said: > I've been privately wondering about making a new tarball of 1.5.2 that > simply adds the Lib/distutils/ subdirectory and installs it, so people > who don't want to risk the jump to 2.0 can still get the nice > Distutils features. The problem is that it would take substantial > willpower to only make that change; the temptation would be great to > fix just this one really annoying bug, oh, and this little feature > wouldn't break anything, and ... Gee, is it really that hard to install the Distutils into a 1.5.2 installation? I do it a couple times a week and it it usually works for me. ;-) Greg From gstein@lyra.org Thu Jul 6 23:49:57 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:49:57 -0700 Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: <200007061855.LAA05178@slayer.i.sourceforge.net>; from montanaro@users.sourceforge.net on Thu, Jul 06, 2000 at 11:55:14AM -0700 References: <200007061855.LAA05178@slayer.i.sourceforge.net> Message-ID: <20000706154956.U29590@lyra.org> On Thu, Jul 06, 2000 at 11:55:14AM -0700, Skip Montanaro wrote: >... > + /* Exported function to load a readline history file */ > + > + static PyObject * > + read_history_file(self, args) > + PyObject *self; > + PyObject *args; > + { > + char *s = NULL; > + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) This allows somebody to pass read_history_file(None). That doesn't feel right. I'd suggest using the 's' format code. (if they want the default, then pass nothing at all) >... > + static PyObject * > + write_history_file(self, args) > + PyObject *self; > + PyObject *args; > + { > + char *s = NULL; > + if (!PyArg_ParseTuple(args, "|z:write_history_file", &s)) > + return NULL; Same here. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido@beopen.com Fri Jul 7 00:53:51 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 18:53:51 -0500 Subject: [Python-Dev] Grammar help. In-Reply-To: Your message of "Thu, 06 Jul 2000 18:22:56 -0400." <20000706182256.A15938@ludwig.cnri.reston.va.us> References: <20000707000407.E26534@xs4all.nl> <20000706182256.A15938@ludwig.cnri.reston.va.us> Message-ID: <200007062353.SAA01958@cj20424-a.reston1.va.home.com> > On 07 July 2000, Thomas Wouters said: > > Argh, my head hurts ! :P Greg Ward replies: > Yeah, but try writing your *own* parser-generator. >grin< > > > Here's what I did. The current definition of 'atom' is: > > > > atom: '(' [testlist] ')' | '[' [testlist] ']' | << ... >> > > testlist: test (',' test)* [','] > > > > I tried adding it like this: > > > > atom: '(' [testlist] ')' | '[' [listmaker] ']' | << ... >> > > testlist: test (',' test)* [','] > > listmaker: testlist | rangemaker > > rangemaker: [test] ':' test > > I think the problem is this: > * one possible candidate for atom is: '[' listmaker > * two candidates for listmaker: testlist or rangemaker > * but both of these start with a test; the fact that one of them > is optional is probably beside the point > * the parser needs to see ',' or ':' to know if it's got a > testlist or a rangemaker: but because a test could be any number > of tokens, it would need infinite lookahead. (I think.) Since > this is a recursive-descent parser, it is most likely LL(1) -- > at most one token of lookahead. Not good enough. > > Another, entirely hypothetical way of looking at it (based on experience > with a completely different recursive descent parser generator > (PCCTS/ANTLR) and dim recollections of the Dragon Book): > * parser sees a '[' token and enters the 'atom' state > (ie. calls a subroutine 'atom()') > * swallows the '[' and immediately enters 'listmaker' (no other option) > * now it wants to enter either 'testlist' or 'rangemaker': but the > FIRST(testlist) == FIRST(test) (testlist can only start with a > test), and FIRST(rangemaker) == FIRST(test) + ':' (rangemaker > can start with a test or the ':' token) > * I suspect this is the ambiguity: overlap in the FIRST sets of > testlist and rangemaker Greg's got it right. It's a recursive descent a.k.a. LL(1) parser. The solution? Try to rewrite the grammar to avoid the ambiguities. So we have [testlist | rangemaker] for listmaker, where testlist is test(','test)* and rangemaker is [test]':'[test]. (Note that you'll have to add [':'[test]] to support [lo:hi:step], but tht's not the problem here.) Rewrite this as listmaker: [rangetail | test((','test)* | rangetail)] rangetail: ':' [test] [':' [test]] Now the two alternatives have different FIRST sets. The disadvantage is that you have to change the code generator to work withthis mess -- that's why people like LALR(1) and other parsers. But LL(1) was all I could create myself (Python uses a homegrown parser generator). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein@lyra.org Thu Jul 6 23:57:32 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:57:32 -0700 Subject: [Python-Dev] internal value (was: Hash values and comparing objects) In-Reply-To: <3964B39C.7E0CD312@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 06:28:12PM +0200 References: <3964B39C.7E0CD312@lemburg.com> Message-ID: <20000706155732.W29590@lyra.org> On Thu, Jul 06, 2000 at 06:28:12PM +0200, M.-A. Lemburg wrote: >... > Previously, Unicode used UTF-8 as basis for calculating the > hash value (the Unicode object created a UTF-8 string object > and delegated the hash value calculation to it, caching the > result and the string for future use). Since I would like > to make the internal encoding cache use the default encoding > instead, I have two problems to solve: Woah... are you saing that the "t#" marker could now return arbitrary encodings? That C code cannot depend on any particular encoding? Why? This is a pretty big semantic change. Cheers, -g -- Greg Stein, http://www.lyra.org/ From esr@thyrsus.com Fri Jul 7 00:04:10 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 19:04:10 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706183810.B15938@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Thu, Jul 06, 2000 at 06:38:10PM -0400 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <20000706183810.B15938@ludwig.cnri.reston.va.us> Message-ID: <20000706190410.B27191@thyrsus.com> Greg Ward : > Ooh, that may not work so well because of the need to background X > browsers. Ick. Bingo. You got it. That code is a lot smarter than it looks... > One could dream up a wild scheme that forks and forks > and does the backgrounding itself, but what the hell: we're launching a > big fat hairy *web browser* here, what does it matter if a shell is > involved to parse the "&"? My thinking exactly. A couple extra parses and forks are nothing. > Also, the wild variability of "which" across platforms and shells makes > me wonder if, somewhere out there, there isn't a "which" that fails to > return true/false on success. (check check check). Yes, there is: with > bash 2.0.3 on Solaris 2.6: Ugh... -- Eric S. Raymond In recent years it has been suggested that the Second Amendment protects the "collective" right of states to maintain militias, while it does not protect the right of "the people" to keep and bear arms. If anyone entertained this notion in the period during which the Constitution and the Bill of Rights were debated and ratified, it remains one of the most closely guarded secrets of the eighteenth century, for no known writing surviving from the period between 1787 and 1791 states such a thesis. -- Stephen P. Halbrook, "That Every Man Be Armed", 1984 From gstein@lyra.org Thu Jul 6 23:59:40 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:59:40 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 In-Reply-To: <20000706200924.B26534@xs4all.nl>; from thomas@xs4all.net on Thu, Jul 06, 2000 at 08:09:24PM +0200 References: <200007052256.PAA12103@slayer.i.sourceforge.net> <14691.65439.950090.60795@anthem.concentric.net> <20000706142731.K13478@xs4all.nl> <20000706200924.B26534@xs4all.nl> Message-ID: <20000706155940.X29590@lyra.org> On Thu, Jul 06, 2000 at 08:09:24PM +0200, Thomas Wouters wrote: > On Thu, Jul 06, 2000 at 02:27:32PM +0200, Thomas Wouters wrote: > > PyObject_INIT((PyObject *)b, &PyBuffer_Type); > > > > The 'value computed' is useless. The value computed is computed by the ',' > > operator, but the only things in there are sideffect operators. The last > > operation in the string of ',''s is either a void-returning function or an > > assignment, so I'd classify this one as a cosmetic bug in gcc ;) adding a > > '(void)' cast to the PyObject_INIT() macro or the calls to it would fix the > > warning. > > Er, ignore that. The value computed isn't useless, it's just the first > argument. I overlooked that, sorry :P The return value is used in a couple > of places. That leaves only one option to squench this warning, a (void) > cast at the one spot that causes a warning. Or is there a better way ? I would say: make PyObject_INIT() a void "function". Since it is just returning the first argument, then the code can just use that explicitly. Having a return value seems to indicate that what you pass and what comes back might actually change. Eek! Not true. If you don't want to make it a void function, then you'll need to add (void) casts to a few places. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido@beopen.com Fri Jul 7 00:58:17 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 18:58:17 -0500 Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: Your message of "Thu, 06 Jul 2000 15:49:57 MST." <20000706154956.U29590@lyra.org> References: <200007061855.LAA05178@slayer.i.sourceforge.net> <20000706154956.U29590@lyra.org> Message-ID: <200007062358.SAA02001@cj20424-a.reston1.va.home.com> > On Thu, Jul 06, 2000 at 11:55:14AM -0700, Skip Montanaro wrote: > >... > > + /* Exported function to load a readline history file */ > > + > > + static PyObject * > > + read_history_file(self, args) > > + PyObject *self; > > + PyObject *args; > > + { > > + char *s = NULL; > > + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) > > This allows somebody to pass read_history_file(None). That doesn't feel > right. I'd suggest using the 's' format code. > > (if they want the default, then pass nothing at all) Hm, I actually like this style and would recommend it. There are often times where it's useful to pass an explicit parameter that says "use the default". For example when writing a Python wrapper: def my_read_hist(file=None): ...do-something... readline.read_history_file(file) ...do-something-else... With what you propose, you'd have to write def my_read_hist(file=None): ...do-something... if file is None: readline.read_history_file() else: readline.read_history_file(file) ...do-something-else... I don't see how forcing users to do that would be considered elegant. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein@lyra.org Fri Jul 7 00:05:40 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 16:05:40 -0700 Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: <200007062358.SAA02001@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 06:58:17PM -0500 References: <200007061855.LAA05178@slayer.i.sourceforge.net> <20000706154956.U29590@lyra.org> <200007062358.SAA02001@cj20424-a.reston1.va.home.com> Message-ID: <20000706160540.Y29590@lyra.org> Good point! Ignore me, then :-) Cheers, -g On Thu, Jul 06, 2000 at 06:58:17PM -0500, Guido van Rossum wrote: > > On Thu, Jul 06, 2000 at 11:55:14AM -0700, Skip Montanaro wrote: > > >... > > > + /* Exported function to load a readline history file */ > > > + > > > + static PyObject * > > > + read_history_file(self, args) > > > + PyObject *self; > > > + PyObject *args; > > > + { > > > + char *s = NULL; > > > + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) > > > > This allows somebody to pass read_history_file(None). That doesn't feel > > right. I'd suggest using the 's' format code. > > > > (if they want the default, then pass nothing at all) > > Hm, I actually like this style and would recommend it. There are > often times where it's useful to pass an explicit parameter that says > "use the default". For example when writing a Python wrapper: > > def my_read_hist(file=None): > ...do-something... > readline.read_history_file(file) > ...do-something-else... > > With what you propose, you'd have to write > > def my_read_hist(file=None): > ...do-something... > if file is None: > readline.read_history_file() > else: > readline.read_history_file(file) > ...do-something-else... > > I don't see how forcing users to do that would be considered elegant. > > --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) -- Greg Stein, http://www.lyra.org/ From barry@scottb.demon.co.uk Thu Jul 6 23:58:17 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Thu, 6 Jul 2000 23:58:17 +0100 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe Message-ID: <000001bfe79d$ac720ae0$060210ac@private> os.popen fails to work if pythonw.exe is used to start python. This is true for 1.5.2 and 1.6a2. The root cause of the problem is in the Microsoft C RTL implementation of _popen(). _popen() will fail if there is not a valid file descriptor for stdin or stdout. The following replacement for WinMain.c works around the problem. I also ensure a valid descriptor for stderr for completeness. This was compiled and test under VC++ 6.0 SP3 on Windows 2000. BArry -------------------------------- WinMain.c ------------------------- /* Minimal main program -- everything is loaded from the library. */ #include #include "Python.h" #include #include extern int Py_Main(); int WINAPI WinMain( HINSTANCE hInstance, // handle to current instance HINSTANCE hPrevInstance, // handle to previous instance LPSTR lpCmdLine, // pointer to command line int nCmdShow // show state of window ) { /* * make sure that the C RTL has valid file descriptors for * stdin, stdout, stderr. Use the NUL device. * This allows popen to work under pythonw. * * When pythonw.exe starts the C RTL function _ioinit is called * first. WinMain is called later hence the need to check for * invalid handles. * * Note: FILE stdin, stdout, stderr do not use the file descriptors * setup here. They are already initialised before WinMain was called. */ int null_file; null_file = open( "NUL", _O_RDWR ); /* check for STDIN is invalid */ if( _get_osfhandle( 0 ) == -1 ) { dup2( null_file, 0 ); } /* check for STDOUT is invalid */ if( _get_osfhandle( 1 ) == -1 ) { dup2( null_file, 1 ); } /* check for STDERR is invalid */ if( _get_osfhandle( 2 ) == -1 ) { dup2( null_file, 2 ); } close( null_file ); return Py_Main(__argc, __argv); } From pingster@ilm.com Fri Jul 7 00:09:21 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Thu, 6 Jul 2000 16:09:21 -0700 (PDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007062254.RAA01617@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 6 Jul 2000, Guido van Rossum wrote: > > That doesn't answer the question. Why select.select() instead of > > os.select()? I've never understood that one myself. > > Different platform dependencies. The select module works on Windows, > Mac and Unix. The posix module only runs on Unix and (under the name > "nt", but using the same source file) on Win32. Okay, then can select() be exposed in the os module by the posix, nt, and mac modules? -- ?!ng From fdrake@beopen.com Fri Jul 7 00:16:05 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 19:16:05 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: References: <200007062254.RAA01617@cj20424-a.reston1.va.home.com> Message-ID: <14693.4917.776799.332729@cj42289-a.reston1.va.home.com> Ka-Ping Yee writes: > Okay, then can select() be exposed in the os module by the > posix, nt, and mac modules? I don't think changing the interface is reasonable. There's too much legacy, and it's not like any of this is broken. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From rassilon@list.org Fri Jul 7 00:28:02 2000 From: rassilon@list.org (Bill Tutt) Date: Thu, 6 Jul 2000 16:28:02 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: <3964FD30.BB0F14D1@lemburg.com> Message-ID: On Thu, 6 Jul 2000, M.-A. Lemburg wrote: > Bill Tutt wrote: > > > > On Thu, 6 Jul 2000, Guido van Rossum wrote: > > > > > > In any event, having the typedef is still useful since it clarifies the > > > > meaning behind the code. > > > > > > > How about this: > > /* > > * Use this typedef when you need to represent a UTF-16 surrogate pair > > * as single unsigned integer. > > */ > > #if SIZEOF_INT >= 4 > > typedef unsigned int Py_UCS4; > > #else > > #if SIZEOF_LONG >= 4 > > typedef unsigned long Py_UCS4; > > #else > > #error "can't find integral type that can contain 32 bits" > > #endif /* SIZEOF_LONG */ > > #endif /* SIZEOF_INT */ > > I like the name... Py_UCS4 is indeed what we're talking about > here. > > What I don't understand is why you raise a compile error; AFAIK, > unsigned long is at least 32 bits on all platforms and that's > what the Unicode implementation would need to support UCS4 -- more > bits don't do any harm since the storage type is fixed at > 16-bit UTF-16 values. > Loud and obnoxious failures are much better than silent, and hard to debug failures. :) If unsigned long is big enough on all of the platforms we care about, then they won't ever see the compile error. :) Bill From guido@beopen.com Fri Jul 7 02:06:03 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 20:06:03 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Thu, 06 Jul 2000 16:09:21 MST." References: Message-ID: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> > On Thu, 6 Jul 2000, Guido van Rossum wrote: > > > That doesn't answer the question. Why select.select() instead of > > > os.select()? I've never understood that one myself. > > > > Different platform dependencies. The select module works on Windows, > > Mac and Unix. The posix module only runs on Unix and (under the name > > "nt", but using the same source file) on Win32. > > Okay, then can select() be exposed in the os module by the > posix, nt, and mac modules? What's the point? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From pingster@ilm.com Fri Jul 7 01:20:53 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Thu, 6 Jul 2000 17:20:53 -0700 (PDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 6 Jul 2000, Guido van Rossum wrote: > > Okay, then can select() be exposed in the os module by the > > posix, nt, and mac modules? > > What's the point? It's an operating system function, like all the others. select() belongs in os for the same reason that we don't import chdir, import wait, import fork, etc. etc. It's not an earth-shattering thing; i'm just pretty sure most people look for os.select() first and wonder why it's missing before discovering select.select(). -- ?!ng From klm@digicool.com Fri Jul 7 01:22:05 2000 From: klm@digicool.com (Ken Manheimer) Date: Thu, 6 Jul 2000 20:22:05 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Tim Peters wrote: > the-committee-wasn't-just-jerking-off-the-last-10-years-ly y'rs - > tim (The obvious question is, where they doing those other things at the same time, or during breaks?) Ken klm@digicool.com From fdrake@beopen.com Fri Jul 7 01:24:47 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 20:24:47 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: References: Message-ID: <14693.9039.56927.20039@cj42289-a.reston1.va.home.com> Ken Manheimer writes: > (The obvious question is, where they doing those other things at the same > time, or during breaks?) I'd rather not find out! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Vladimir.Marangozov@inrialpes.fr Fri Jul 7 01:34:09 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 7 Jul 2000 02:34:09 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Ka-Ping Yee" at Jul 05, 2000 12:20:41 PM Message-ID: <200007070034.CAA02914@python.inrialpes.fr> Ka-Ping Yee wrote: > > > [Ping] > > > 4. Added int *expected_ret argument to PyParser_AddToken; on > > > a syntax error, PyParser_AddToken (in parser.c) places the > > > expected token type (if any) into this output parameter. > > [me] > > I'd suggest passing a pointer to the perrdetail structure (to the > > whole error, that is), instead of a pointer to one of its fields. > [Ping] > I did consider that; the reason i eventually decided against it > is that munging perrdetail appears to be [parsetok.c] parsetok()'s > responsibility, not [parser.c] PyParser_AddToken()'s. The latter > doesn't mess with any of the other fields of perrdetail -- and it > returns an error code which becomes err_ret->error, so passing in > perrdetail gives PyParser_AddToken() two ways of returning the same > information. The redundancy and possible future confusion didn't > seem worth it. > > Another alternative is to change the return value so it *isn't* > an error code (only a success/fail flag) and then rely on the error > code in err_ret->error. I guess if you see a compelling reason for > this i don't mind doing it. But is there one? Okay. Since you've already altered the error list in errcode.h, I think that the best thing to do is to re-introduce E_INDENT but for the "missing indentation" case (reported to the user as "expected an indented block"), then return E_INDENT from AddToken() and revert back its signature. Thus all additional error cases you've detected so far would be handled fine in pythonrun.c. Does this sound good for you? I share most of your thoughts -- after another look at the updated patch, I don't think I like the augmented perrdetail and the redundant communication interface with PyParser_AddToken(). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From jeremy@beopen.com Fri Jul 7 02:05:23 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 6 Jul 2000 21:05:23 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706190410.B27191@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <20000706183810.B15938@ludwig.cnri.reston.va.us> <20000706190410.B27191@thyrsus.com> Message-ID: <14693.11475.243489.826433@bitdiddle.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> Greg Ward : >> Ooh, that may not work so well because of the need to background >> X browsers. Ick. ESR> Bingo. You got it. That code is a lot smarter than it ESR> looks... A comment is in order then. If the code is smarter than it looks, most people aren't going to think it looks very smart. Jeremy From fdrake@beopen.com Fri Jul 7 02:09:35 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 21:09:35 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706171608.A26696@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> Message-ID: <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> --wbCaznGdGX Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit Eric S. Raymond writes: > there's a functionally similar name/value pair facility available > through system resource forks on the Mac. I really think a profile > file is excessively heavyweight here. Environment variables or X I still haven't heard from any MacOS users what the "right" way to do this sort of thing is. Jack, Sjoerd, Just... are you listening? > I've actually been seriously thinking, once this is in the Python > library, of going to the Perl and Tcl people and giving them code that > would make *their* standard libraries do the right thing with the > BROWSER variable. It shouldn't only be portable across Python > applications, but across scripting languages as well -- something that > would be much harder to do with an .ini file. I don't buy that using a config file is harder for those languages, but I think providing similar functionality for all is a great idea. Ok, here's a version that keeps the idea of a register() function, but simplifies the machinery quite a bit. Instead of using a config file, the BROWSER environment variable is used. If not set, the default on Windows is to use the Windows default setting. On Unix, the default is Netscape if $DISPLAY is set, otherwise it's the "command line browser", which tries, in order: netscape, mosaic(!), lync, and w3m. I left out Mozilla since I couldn't get it to work at all last time I tried it (though I've had better results previously). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member --wbCaznGdGX Content-Type: text/x-python Content-Description: web browser controller module Content-Disposition: inline; filename="webbrowser.py" Content-Transfer-Encoding: 7bit """Remote-control interfaces to some browsers.""" import os import sys PROCESS_CREATION_DELAY = 4 class Error(Exception): pass _browsers = {} def register(name, klass, instance=None): """Register a browser connector and, optionally, connection.""" _browsers[name.lower()] = [klass, instance] def get(name=None): """Retrieve a connection to a browser by type name, or the default browser.""" name = name or DEFAULT_BROWSER try: L = _browsers[name.lower()] except KeyError: raise ValueError, "unknown browser type: " + `name` if L[1] is None: L[1] = L[0]() return L[1] def open(url, new=0): get().open(url, new) def open_new(url): get().open_new(url) def _iscommand(cmd): """Return true if cmd can be found on the executable search path.""" path = os.environ.get("PATH") if not path: return 0 for d in path.split(os.pathsep): exe = os.path.join(d, cmd) if os.path.isfile(exe): return 1 return 0 class CommandLineBrowser: _browsers = [] if os.environ.get("DISPLAY"): _browsers.extend([ ("netscape", "netscape %s >/dev/null &"), ("mosaic", "mosaic %s >/dev/null &"), ]) _browsers.extend([ ("lynx", "lynx %s"), ("w3m", "w3m %s"), ]) def open(self, url, new=0): for exe, cmd in self._browsers: if _iscommand(exe): os.system(cmd % url) return raise Error("could not locate runnable browser") def open_new(self, url): self.open(url) register("command-line-browser", CommandLineBrowser) class Netscape: autoRaise = 1 def _remote(self, action): raise_opt = ("-noraise", "-raise")[self.autoRaise] cmd = "netscape %s -remote '%s' >/dev/null 2>&1" % (raise_opt, action) rc = os.system(cmd) if rc: import time os.system("netscape -no-about-splash &") time.sleep(PROCESS_CREATION_DELAY) rc = os.system(cmd) return not rc def open(self, url, new=0): if new: self.open_new(url) else: self._remote("openURL(%s)" % url) def open_new(self, url): self._remote("openURL(%s, new-window)" % url) register("netscape", Netscape) class Grail: # There should be a way to maintain a connection to Grail, but the # Grail remote control protocol doesn't really allow that at this # point. It probably never will! def _find_grail_rc(self): import glob import pwd import socket import tempfile tempdir = os.path.join(tempfile.gettempdir(), ".grail-unix") user = pwd.getpwuid(_os.getuid())[0] filename = os.path.join(tempdir, user + "-*") maybes = glob.glob(filename) if not maybes: return None s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) for fn in maybes: # need to PING each one until we find one that's live try: s.connect(fn) except socket.error: # no good; attempt to clean it out, but don't fail: try: os.unlink(fn) except IOError: pass else: return s def _remote(self, action): s = self._find_grail_rc() if not s: return 0 s.send(action) s.close() return 1 def open(self, url, new=0): if new: self.open_new(url) else: self._remote("LOAD " + url) def open_new(self, url): self._remote("LOADNEW " + url) register("grail", Grail) class WindowsDefault: def open(self, url, new=0): import win32api, win32con win32api.ShellExecute(0, "open", url, None, ".", win32con.SW_SHOWNORMAL) def open_new(self, url): self.open(url) if sys.platform[:3] == "win": register("windows-default", WindowsDefault) DEFAULT_BROWSER = "windows-default" elif not os.environ.get("DISPLAY"): DEFAULT_BROWSER = "command-line-browser" else: DEFAULT_BROWSER = "netscape" # If the $BROWSER environment variable is set and true, let that be # the name of the browser to use: # DEFAULT_BROWSER = os.environ.get("BROWSER") or DEFAULT_BROWSER --wbCaznGdGX-- From fdrake@beopen.com Fri Jul 7 02:14:38 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 21:14:38 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> Message-ID: <14693.12030.937901.65835@cj42289-a.reston1.va.home.com> Fred L. Drake, Jr. writes: > lync, and w3m. I left out Mozilla since I couldn't get it to work at > all last time I tried it (though I've had better results previously). I just pulled downthe M16 release of Mozilla - again - and it still doesn't know how to run. I can cd to the installation directory and run it directly, but it just doesn't do the right thing for normal use -- type "mozilla" isn't enough. I'm actually pretty surprised no one has fixed that. Their wrapper shell scripts look pretty screwed up. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gmcm@hypernet.com Fri Jul 7 02:42:28 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 6 Jul 2000 21:42:28 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: References: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> Message-ID: <1249188344-7661966@hypernet.com> Ka-Ping Yee wrote: [wants select in os] > It's an operating system function, like all the others. > select() belongs in os for the same reason that we don't > import chdir, import wait, import fork, etc. etc. > > It's not an earth-shattering thing; i'm just pretty sure > most people look for os.select() first and wonder why it's > missing before discovering select.select(). Actually Windows users probably first look in socket, since it's a socket-only thing on Windows. - Gordon From jeremy@beopen.com Fri Jul 7 03:02:32 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 6 Jul 2000 22:02:32 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> References: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> Message-ID: <14693.14904.827148.290679@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> Okay, then can select() be exposed in the os module by the posix, >> nt, and mac modules? GvR> What's the point? Exactly. I don't see much point to moving it. Jeremy From esr@thyrsus.com Fri Jul 7 03:20:45 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 22:20:45 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.11727.410675.928619@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 09:09:35PM -0400 References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> Message-ID: <20000706222045.C27688@thyrsus.com> Fred L. Drake, Jr. : > Ok, here's a version that keeps the idea of a register() function, > but simplifies the machinery quite a bit. Instead of using a config > file, the BROWSER environment variable is used. If not set, the > default on Windows is to use the Windows default setting. On Unix, > the default is Netscape if $DISPLAY is set, otherwise it's the > "command line browser", which tries, in order: netscape, mosaic(!), > lync, and w3m. I left out Mozilla since I couldn't get it to work at > all last time I tried it (though I've had better results previously). Looks pretty good...though I have to wonder how much point there is in Grail support at this point. Having something like this in the standard library will be a real boon for on-line documentation and Web-aware programs. (I got M16 to run without difficulty, BTW. I have not switched yet because the UI still has a lot of sharp edges.) -- Eric S. Raymond The world is filled with violence. Because criminals carry guns, we decent law-abiding citizens should also have guns. Otherwise they will win and the decent people will lose. -- James Earl Jones From rassilon@list.org Fri Jul 7 03:15:01 2000 From: rassilon@list.org (Bill Tutt) Date: Thu, 6 Jul 2000 19:15:01 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Tim Peters wrote: > [Bill Tutt] > > How about this: > > /* > > * Use this typedef when you need to represent a UTF-16 surrogate pair > > * as single unsigned integer. > > */ > > #if SIZEOF_INT >= 4 > > typedef unsigned int Py_UCS4; > > #else > > #if SIZEOF_LONG >= 4 > > typedef unsigned long Py_UCS4; > > #else > > #error "can't find integral type that can contain 32 bits" > > #endif /* SIZEOF_LONG */ > > #endif /* SIZEOF_INT */ > > Much better! In the future (when the infrastructure is in place), I expect > we'll replace the #if stuff here with > > typedef Py_uint_least32_t UCS4; > > instead (where Py_uint_least32_t is defined in pyfort.h, and uint_least32_t > is the C9X spelling of the true requirement). > > BTW, why not use #elif instead of nested #ifs? #elif is clearer and > shorter. > I've updated both of these patches on SF. Comments welcome, Bill From skip@mojam.com (Skip Montanaro) Fri Jul 7 03:13:57 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 6 Jul 2000 21:13:57 -0500 (CDT) Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: <20000706154956.U29590@lyra.org> References: <200007061855.LAA05178@slayer.i.sourceforge.net> <20000706154956.U29590@lyra.org> Message-ID: <14693.15589.244326.670660@beluga.mojam.com> Greg> On Thu, Jul 06, 2000 at 11:55:14AM -0700, Skip Montanaro wrote: >> ... >> + /* Exported function to load a readline history file */ >> + >> + static PyObject * >> + read_history_file(self, args) >> + PyObject *self; >> + PyObject *args; >> + { >> + char *s = NULL; >> + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) Greg> This allows somebody to pass read_history_file(None). That doesn't Greg> feel right. I'd suggest using the 's' format code. Thanks, I'll fix it tomorrow. I basically cloned read_init_file's code. That probably needs a tweak as well. Skip From skip@mojam.com (Skip Montanaro) Fri Jul 7 03:15:55 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 6 Jul 2000 21:15:55 -0500 (CDT) Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: <20000706160540.Y29590@lyra.org> References: <200007061855.LAA05178@slayer.i.sourceforge.net> <20000706154956.U29590@lyra.org> <200007062358.SAA02001@cj20424-a.reston1.va.home.com> <20000706160540.Y29590@lyra.org> Message-ID: <14693.15707.301363.371690@beluga.mojam.com> Greg> Good point! Greg> Ignore me, then :-) No problem... ;-) Skip From Vladimir.Marangozov@inrialpes.fr Fri Jul 7 03:38:48 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 7 Jul 2000 04:38:48 +0200 (CEST) Subject: [Python-Dev] list comprehensions again... In-Reply-To: from "Tim Peters" at Jul 05, 2000 11:51:53 PM Message-ID: <200007070238.EAA03292@python.inrialpes.fr> Tim Peters wrote: > > OK, I'll be serious this time: if "the next release" is next week, damn > straight I want to stick to the feature freeze. > > But if it becomes predictably delayed for months, sure, open the floodgates > again. All this sounds reasonable. > > Unfortunately, the stuff holding up the release isn't technical in nature, > so there's nothing most of us can do to affect the outcome either way. So? To be or not to be? Make up your mind guys and we'll follow . You're the ones who have the best approximation of the set of all possible predictions. At least it should be better than mine. Since the release schedule was already revisited a number of times, and since we're moving to a major 2.0 version, I'm inclined to think that it would be fine to: 1) delay the release for september, or have a long beta-cycle until then (most people are going to spend their vacation in august anyway a) we won't get a solid feedback during a short beta in august, b) people will be pleased to see the major release ready on their return 2) Try finalizing at best & ASAP (say, next week) the pending issues with the big chunks that are already in -- SRE and Unicode. 3) Consider for inclusion in 2.0 the features we _already_know_ for sure have been delayed for 2.1 (a.k.a. -- 1.7) due to lack of time. 4) Emphasize the "quantum leap" with the 2.0 release by underlining the XML stuff Paul talked about + the major features considered in 3) I believe that staying in an undetermined Z-state for more than a week without a set of clearly defined options is not really what we all want, but maybe you have some additional considerations that may explain the ongoing patience about this lag... back-to-the-future-ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From fdrake@beopen.com Fri Jul 7 03:37:31 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 22:37:31 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706222045.C27688@thyrsus.com> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> <20000706222045.C27688@thyrsus.com> Message-ID: <14693.17003.16089.319857@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Looks pretty good...though I have to wonder how much point there is in > Grail support at this point. Having something like this in the standard That was the first browser I supported! (Which might indicate the age of some of the code a bit. ;) On the other hand, I don't see any real reason to discard it. I wouldn't mind a class to support Mosaic's CCI control interface either. ;) > library will be a real boon for on-line documentation and Web-aware > programs. Right. I originally wrote this (for Grail & Netscape) for a bookmark handling tool I never finished; this was the start of the browser controller; each class was supposed to be, essentially, a device driver for a Web-display abstract device. > (I got M16 to run without difficulty, BTW. I have not switched yet > because the UI still has a lot of sharp edges.) Interesting. I just re-installed it as root on Mandrake 7.0, and get the following as Joe User with all the default installation settings: cj42289-a(~/projects/python); PATH=/usr/local/mozilla:$PATH mozilla /dist/bin/run-mozilla.sh ./mozilla-bin /usr/local/mozilla/mozilla: /dist/bin/run-mozilla.sh: No such file or directory [127] cj42289-a(~/projects/python); (The "127" was the exit code, thanks to a bashlet from Ken Manheimer.) M12 did much better at this stuff, though the browser itself seems to have improved. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip@mojam.com (Skip Montanaro) Fri Jul 7 04:22:35 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 6 Jul 2000 22:22:35 -0500 (CDT) Subject: [Python-Dev] Re: [Patches] [Patch #100752] Make atoi work for negative bases, a useful generalization In-Reply-To: <200007070309.UAA12927@bush.i.sourceforge.net> References: <200007070309.UAA12927@bush.i.sourceforge.net> Message-ID: <14693.19707.553522.523595@beluga.mojam.com> Alex, I looked at your patch. Can you provide a little motivation for those of us who are base challenged? I've never even heard of negative bases. Thx, -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From fdrake@beopen.com Fri Jul 7 04:40:33 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 23:40:33 -0400 (EDT) Subject: [Python-Dev] webbrowser module Message-ID: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> --av8WMY8/pQ Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit Ok, I've checked in the documentation for the webbrowser documentation. The implementation can go in as soon as SF clears a bogus read lock (support request files 6.5 hours ago). Well, I said I knew about InternetConfig for MacOS, but I clearly hadn't read the documentation! Getting this module working on MacOS is a trivial matter, if the docs are to be believed. If someone with a Mac could test it with a script like: import webbrowser webbrowser.open("http://www.python.org/") and let me know what happens, I'd really appreciate it! I've attached the version with Mac support below. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member --av8WMY8/pQ Content-Type: text/x-python Content-Description: web browser controller module Content-Disposition: inline; filename="webbrowser.py" Content-Transfer-Encoding: 7bit """Remote-control interfaces to some browsers.""" import os import sys PROCESS_CREATION_DELAY = 4 class Error(Exception): pass _browsers = {} def register(name, klass, instance=None): """Register a browser connector and, optionally, connection.""" _browsers[name.lower()] = [klass, instance] def get(name=None): """Retrieve a connection to a browser by type name, or the default browser.""" name = name or DEFAULT_BROWSER try: L = _browsers[name.lower()] except KeyError: raise ValueError, "unknown browser type: " + `name` if L[1] is None: L[1] = L[0]() return L[1] def open(url, new=0): get().open(url, new) def open_new(url): get().open_new(url) def _iscommand(cmd): """Return true if cmd can be found on the executable search path.""" path = os.environ.get("PATH") if not path: return 0 for d in path.split(os.pathsep): exe = os.path.join(d, cmd) if os.path.isfile(exe): return 1 return 0 class CommandLineBrowser: _browsers = [] if os.environ.get("DISPLAY"): _browsers.extend([ ("netscape", "netscape %s >/dev/null &"), ("mosaic", "mosaic %s >/dev/null &"), ]) _browsers.extend([ ("lynx", "lynx %s"), ("w3m", "w3m %s"), ]) def open(self, url, new=0): for exe, cmd in self._browsers: if _iscommand(exe): os.system(cmd % url) return raise Error("could not locate runnable browser") def open_new(self, url): self.open(url) register("command-line", CommandLineBrowser) class Netscape: autoRaise = 1 def _remote(self, action): raise_opt = ("-noraise", "-raise")[self.autoRaise] cmd = "netscape %s -remote '%s' >/dev/null 2>&1" % (raise_opt, action) rc = os.system(cmd) if rc: import time os.system("netscape -no-about-splash &") time.sleep(PROCESS_CREATION_DELAY) rc = os.system(cmd) return not rc def open(self, url, new=0): if new: self.open_new(url) else: self._remote("openURL(%s)" % url) def open_new(self, url): self._remote("openURL(%s, new-window)" % url) register("netscape", Netscape) class Grail: # There should be a way to maintain a connection to Grail, but the # Grail remote control protocol doesn't really allow that at this # point. It probably never will! def _find_grail_rc(self): import glob import pwd import socket import tempfile tempdir = os.path.join(tempfile.gettempdir(), ".grail-unix") user = pwd.getpwuid(_os.getuid())[0] filename = os.path.join(tempdir, user + "-*") maybes = glob.glob(filename) if not maybes: return None s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) for fn in maybes: # need to PING each one until we find one that's live try: s.connect(fn) except socket.error: # no good; attempt to clean it out, but don't fail: try: os.unlink(fn) except IOError: pass else: return s def _remote(self, action): s = self._find_grail_rc() if not s: return 0 s.send(action) s.close() return 1 def open(self, url, new=0): if new: self.open_new(url) else: self._remote("LOAD " + url) def open_new(self, url): self._remote("LOADNEW " + url) register("grail", Grail) class WindowsDefault: def open(self, url, new=0): import win32api, win32con win32api.ShellExecute(0, "open", url, None, ".", win32con.SW_SHOWNORMAL) def open_new(self, url): self.open(url) if sys.platform[:3] == "win": register("windows-default", WindowsDefault) DEFAULT_BROWSER = "windows-default" elif not os.environ.get("DISPLAY"): DEFAULT_BROWSER = "command-line-browser" else: DEFAULT_BROWSER = "netscape" # If the $BROWSER environment variable is set and true, let that be # the name of the browser to use: # DEFAULT_BROWSER = os.environ.get("BROWSER") or DEFAULT_BROWSER # Now try to support the MacOS world. This is the only supported # controller on that platform, so don't mess with the default! try: import ic except ImportError: pass else: class InternetConfig: def open(self, url, new=0): ic.launcurl(url) def open_new(self, url): self.open(url) _browsers.clear() register("internet-config", InternetConfig) DEFAULT_BROWSER = "internet-config" --av8WMY8/pQ-- From Moshe Zadka Fri Jul 7 05:25:40 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 7 Jul 2000 07:25:40 +0300 (IDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Bill Tutt wrote: > How about this: > /* > * Use this typedef when you need to represent a UTF-16 surrogate pair > * as single unsigned integer. > */ > #if SIZEOF_INT >= 4 > typedef unsigned int Py_UCS4; > #else > #if SIZEOF_LONG >= 4 > typedef unsigned long Py_UCS4; > #else > #error "can't find integral type that can contain 32 bits" > #endif /* SIZEOF_LONG */ > #endif /* SIZEOF_INT */ +0 from me, except (and this is really a nit, since I don't know real machines like that) what if sizeof(long) == 2 and sizeof(long long) == 4? long long is "almost standard", and I'm sure a configure test could make sure it is really there, so you can add #else #if HAVE_LONG_LONG and SIZEOF_LONG_LONG >= 4 .... #endif -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From mal@lemburg.com Fri Jul 7 09:16:09 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 10:16:09 +0200 Subject: [Python-Dev] Re: internal value (was: Hash values and comparing objects) References: <3964B39C.7E0CD312@lemburg.com> <20000706155732.W29590@lyra.org> Message-ID: <396591C9.C3533427@lemburg.com> Greg Stein wrote: > > On Thu, Jul 06, 2000 at 06:28:12PM +0200, M.-A. Lemburg wrote: > >... > > Previously, Unicode used UTF-8 as basis for calculating the > > hash value (the Unicode object created a UTF-8 string object > > and delegated the hash value calculation to it, caching the > > result and the string for future use). Since I would like > > to make the internal encoding cache use the default encoding > > instead, I have two problems to solve: > > Woah... are you saing that the "t#" marker could now return arbitrary > encodings? That C code cannot depend on any particular encoding? Right. If C code needs a particular encoding other than the locale dependent default encoding, it'll have to use "es#". > Why? This is a pretty big semantic change. It completes the switch from the fixed UTF-8 encoding to the locale dependent default encoding which we decided on a couple of weeks ago. Note that this change will make enhance compatibility with existing C extensions since they will now get the encoding that is default for them anyway... well, at least they stand a good chance ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From sjoerd@oratrix.nl Fri Jul 7 10:03:39 2000 From: sjoerd@oratrix.nl (Sjoerd Mullender) Date: Fri, 07 Jul 2000 11:03:39 +0200 Subject: [Python-Dev] forwarded message from noreply@sourceforge.net In-Reply-To: Your message of Thu, 06 Jul 2000 12:53:19 -0400. <14692.47487.15354.645423@cj42289-a.reston1.va.home.com> References: <14692.47487.15354.645423@cj42289-a.reston1.va.home.com> Message-ID: <20000707090340.7D00931047C@bireme.oratrix.nl> On Thu, Jul 6 2000 "Fred L. Drake, Jr." wrote: > The bogus CVS lock in Modules/ is now fixed! That's very nice and much appreciated, but I had (and still have) a problem with a lock in Lib... -- Sjoerd Mullender From sjoerd@oratrix.nl Fri Jul 7 10:40:34 2000 From: sjoerd@oratrix.nl (Sjoerd Mullender) Date: Fri, 07 Jul 2000 11:40:34 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines Message-ID: <20000707094036.AA22C31047C@bireme.oratrix.nl> The new defines in Python.h for SUSv2 compatibility seriously hamper compilation on SGI IRIX. The problem is that defining _XOPEN_SOURCE causes a number of common but non-standard features to be removed. In particular, ctermid_r and altzone are no longer defined. The former causes a warning (assignment of int-returning function to char *), the latter causes an error (altzone not defined). Something needs to be done about this but I don't know what since I don't know why the defines were necessary. -- Sjoerd Mullender From fredrik@pythonware.com Fri Jul 7 10:58:31 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 11:58:31 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines References: <20000707094036.AA22C31047C@bireme.oratrix.nl> Message-ID: <018301bfe7f9$e85c9dc0$0900a8c0@SPIFF> sjoerd wrote: > The new defines in Python.h for SUSv2 compatibility seriously hamper > compilation on SGI IRIX. > Something needs to be done about this but I don't know what since I > don't know why the defines were necessary. It was an attempt to make sure certain features were correctly defined. Some platforms add more stuff when you define this one, but others obviously remove stuff... I suggest removing it for now (it solves problems on Linux, but causes problems on at least Irix and tru64), and adding SUSv2 compliance as a possible design goal for Py3K... I've attached a patch (for some reason, I cannot check things in from any of my work machines. sigh.) [fredrik@brain src]$ cvs diff -u Include/Python.h Index: Include/Python.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Include/Python.h,v retrieving revision 2.20 diff -u -r2.20 Python.h --- Include/Python.h 2000/07/05 08:53:18 2.20 +++ Include/Python.h 2000/07/07 09:55:53 @@ -12,14 +12,17 @@ redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES. ******************************************************************/ -/* Enable compiler features including SUSv2 compatibility; switching - on C lib defines doesn't work here, because the symbols haven't - necessarily been defined yet. */ +/* Enable compiler features; switching on C lib defines doesn't work + here, because the symbols haven't necessarily been defined yet. */ + #ifndef _GNU_SOURCE # define _GNU_SOURCE 1 #endif + +#if 0 /* not yet. breaks stuff on too many platforms */ #ifndef _XOPEN_SOURCE # define _XOPEN_SOURCE 500 +#endif #endif /* Include nearly all Python header files */ From tismer@appliedbiometrics.com Fri Jul 7 11:21:07 2000 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 07 Jul 2000 12:21:07 +0200 Subject: [Python-Dev] how do I release a cvs lock? References: <14692.36768.23073.781592@beluga.mojam.com> <200007061515.KAA13255@cj20424-a.reston1.va.home.com> <396498D7.97ABB543@appliedbiometrics.com> <200007061537.KAA13448@cj20424-a.reston1.va.home.com> Message-ID: <3965AF13.C595B561@appliedbiometrics.com> Guido van Rossum wrote: > > > Do we really want to live on with SourceForge(t) ? > > It seems to be pleasant for small projects, but > > maybe it would be more convenient to have a CVS > > that we control directly? > > The new starship is very powerful and could stand a couple of > > CVS repositories easily. > > > > While one might argue that this would give to much of Python > > to BeOpen (they got it already:), I think this could work > > smoothly. > > In my experience, maintaining the repository, with both anonymous and > privileged (commit) access, is a lot of work -- managing user accounts > for the privileged, keeping the machine up and running, etc. I'm > really quite happy with the level of support we get from SF. Sure, if you have many projects and many users. > In the long run, BeOpen might be interested in running this kind of > service for the Python and other communities; but for now, it would > just be a burden. I was thinking of creating this service on the starship machine, and just for the couple of projects that we need, without help from BeOpen. I could initiate such a service, since it was one of our goals when we have a more powerful machine, and now we have it. But without interest I can save the time. - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From jack@oratrix.nl Fri Jul 7 11:33:03 2000 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 07 Jul 2000 12:33:03 +0200 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: Message by "Eric S. Raymond" , Thu, 6 Jul 2000 12:21:22 -0400 , <20000706122122.A25613@thyrsus.com> Message-ID: <20000707103308.8074FE2673@oratrix.oratrix.nl> I would suggest not putting it into urllib but in a "launch" module. First, the actual implementation is going to be completely different for the various platforms, so if you put it into urllib it'll probably have to happen with an intermedeate module anyway, and by putting it in a separate module it's probably easier to extend to to various other things you might want to launch (fileviewers, editors, etc). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Fri Jul 7 11:46:56 2000 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 07 Jul 2000 12:46:56 +0200 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: Message by "Eric S. Raymond" , Thu, 6 Jul 2000 17:16:08 -0400 , <20000706171608.A26696@thyrsus.com> Message-ID: <20000707104701.0D3EBE2673@oratrix.oratrix.nl> Recently, "Eric S. Raymond" said: > Environment variables work for Windows users, too -- and I believe > there's a functionally similar name/value pair facility available > through system resource forks on the Mac. I really think a profile > file is excessively heavyweight here. Environment variables or X > resources are a better medium for this kind of shared preference. On the Mac life is easy: Internet Config keeps all this knowledge (and much more) in a database, and Python has an interface to it. So the code is simply import ic ic_instance = ic.IC() ic_instance.launchurl(url) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From mal@lemburg.com Fri Jul 7 11:54:48 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 12:54:48 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines References: <20000707094036.AA22C31047C@bireme.oratrix.nl> Message-ID: <3965B6F8.72742A2E@lemburg.com> Sjoerd Mullender wrote: > > The new defines in Python.h for SUSv2 compatibility seriously hamper > compilation on SGI IRIX. > > The problem is that defining _XOPEN_SOURCE causes a number of common > but non-standard features to be removed. In particular, ctermid_r and > altzone are no longer defined. The former causes a warning > (assignment of int-returning function to char *), the latter causes an > error (altzone not defined). > Something needs to be done about this but I don't know what since I > don't know why the defines were necessary. I think Fredrik is right. I'll remove the _XOPEN_SOURCE for now, but leave the _GNU_SOURCE define in (on Linux, Python compiles just fine using _GNU_SOURCE). Perhaps you could figure out which defines are needed to reenable the missing APIs on IRIX when _XOPEN_SOURCE is defined... it would be helpful to help pin-point the weak spots w/r to SUSv2 compatibility. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@beopen.com Fri Jul 7 13:29:27 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 07:29:27 -0500 Subject: [Python-Dev] Toby Dickenson's Unicode experience Message-ID: <200007071229.HAA03626@cj20424-a.reston1.va.home.com> He's got a point... Maybe add ustr(x) with the semantics below? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------- Forwarded Message Date: Fri, 07 Jul 2000 10:53:39 +0100 From: Toby Dickenson To: I18n-sig@python.org Subject: [I18n-sig] Unicode experience I'm just nearing the end of getting Zope to play well with unicode data. Most of the changes involved replacing a call to str, in situations where either a unicode or narrow string would be acceptable. My best alternative is: def convert_to_something_stringlike(x): if type(x)==type(u''): return x else: return str(x) This seems like a fundamental operation - would it be worth having something similar in the standard library? Toby Dickenson tdickenson@geminidataloggers.com _______________________________________________ I18n-sig mailing list I18n-sig@python.org http://www.python.org/mailman/listinfo/i18n-sig ------- End of Forwarded Message From guido@beopen.com Fri Jul 7 13:44:03 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 07:44:03 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: Your message of "Fri, 07 Jul 2000 13:15:49 +0200." <3965BBE5.D67DD838@lemburg.com> References: <3965BBE5.D67DD838@lemburg.com> Message-ID: <200007071244.HAA03694@cj20424-a.reston1.va.home.com> > Toby Dickenson wrote: > > > > I'm just nearing the end of getting Zope to play well with unicode > > data. Most of the changes involved replacing a call to str, in > > situations where either a unicode or narrow string would be > > acceptable. > > > > My best alternative is: > > > > def convert_to_something_stringlike(x): > > if type(x)==type(u''): > > return x > > else: > > return str(x) > > > > This seems like a fundamental operation - would it be worth having > > something similar in the standard library? Marc-Andre Lemburg replied: > You mean: for Unicode return Unicode and for everything else > return strings ? > > It doesn't fit well with the builtins str() and unicode(). I'd > say, make this a userland helper. I think this would be helpful to have in the std library. Note that in JPython, you'd already use str() for this, and in Python 3000 this may also be the case. At some point in the design discussion for the current Unicode support we also thought that we wanted str() to do this (i.e. allow 8-bit and Unicode string returns), until we realized that there were too many places that would be very unhappy if str() returned a Unicode string! The problem is similar to a situation you have with numbers: sometimes you want a coercion that converts everything to float except it should leave complex numbers complex. In other words it coerces up to float but it never coerces down to float. Luckily you can write that as "x+0.0" while converts int and long to float with the same value while leaving complex alone. For strings there is no compact notation like "+0.0" if you want to convert to string or Unicode -- adding "" might work in Perl, but not in Python. I propose ustr(x) with the semantics given by Toby. Class support (an __ustr__ method, with fallbacks on __str__ and __unicode__) would also be handy. > BTW, could you elaborate a bit on your experience with adding > Unicode support to Zope ? Such a report would certainly make > a nice complement to the Unicode tutorial and help other > people adding Unicode support to their apps. Yes, that's what we need. Thanks to Toby for pioneering this! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas@xs4all.net Fri Jul 7 12:56:41 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 7 Jul 2000 13:56:41 +0200 Subject: [Python-Dev] _sre.c's compiled size Message-ID: <20000707135641.F26534@xs4all.nl> --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii For the record ;) I've compiled _sre with -fno-inline, on a RH6.2 egcs-1.1.2 system, and I have to admit compilation is going a lot faster. About 1/10th of the time, compared to without -fno-inline, which means it's about 1/100th of the annoyance when compiling a lot ;-) Also, the resulting object file is only 71K, instead of 440K, on my machine. Overall speed of python, as measured by pybench, doesn't really change, but pybench does not measure regexp speed at all, and I don't have a suitable testpackage for that. I've attached a teensy patch that allows '-f' flags to be used in Setup files, to be able to easily switch between the two. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="makesetup.patch" *** src/Modules/makesetup Thu Jul 6 13:58:06 2000 --- src-rangemaker/Modules/makesetup Fri Jul 7 13:23:25 2000 *************** *** 140,146 **** srcs) srcs="$srcs $arg"; skip=; continue;; esac case $arg in ! -[IDUC]*) cpps="$cpps $arg";; -Xlinker) libs="$libs $arg"; skip=libs;; -rpath) libs="$libs $arg"; skip=libs;; -[A-Zl]*) libs="$libs $arg";; --- 140,146 ---- srcs) srcs="$srcs $arg"; skip=; continue;; esac case $arg in ! -[IDUCf]*) cpps="$cpps $arg";; -Xlinker) libs="$libs $arg"; skip=libs;; -rpath) libs="$libs $arg"; skip=libs;; -[A-Zl]*) libs="$libs $arg";; --5vNYLRcllDrimb99-- From sjoerd@oratrix.nl Fri Jul 7 13:01:48 2000 From: sjoerd@oratrix.nl (Sjoerd Mullender) Date: Fri, 07 Jul 2000 14:01:48 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines In-Reply-To: Your message of Fri, 07 Jul 2000 12:54:48 +0200. <3965B6F8.72742A2E@lemburg.com> References: <20000707094036.AA22C31047C@bireme.oratrix.nl> <3965B6F8.72742A2E@lemburg.com> Message-ID: <20000707120149.6B39631047C@bireme.oratrix.nl> On Fri, Jul 7 2000 "M.-A. Lemburg" wrote: > Perhaps you could figure out which defines are needed to > reenable the missing APIs on IRIX when _XOPEN_SOURCE is > defined... it would be helpful to help pin-point the > weak spots w/r to SUSv2 compatibility. It looks like there is no way of doing this. The relevant bits of code are: In time.h (as an example): #if _SGIAPI && _NO_ANSIMODE extern time_t altzone; #endif /* _SGIAPI */ So _SGIAPI and _NO_ANSIMODE should both be defined and != 0. The definition of _SGIAPI is #define _SGIAPI ((defined(_SGI_SOURCE) && \ _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5) || \ (_ANSIMODE && _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5)) So, if _NO_XOPEN5 is 0, _SGIAPI is 0. The definition of _NO_XOPEN5 is #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || \ (defined(_XOPEN_SOURCE) && \ (_XOPEN_SOURCE+0 < 500))) So _NO_XOPEN5 is 0 since _XOPEN_SOURCE is defined and >= 500. All of this on IRIX 6.5.2. I can't check other versions of IRIX. -- Sjoerd Mullender From thomas@xs4all.net Fri Jul 7 13:08:56 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 7 Jul 2000 14:08:56 +0200 Subject: [Python-Dev] Grammar help. In-Reply-To: <200007062353.SAA01958@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 06:53:51PM -0500 References: <20000707000407.E26534@xs4all.nl> <20000706182256.A15938@ludwig.cnri.reston.va.us> <200007062353.SAA01958@cj20424-a.reston1.va.home.com> Message-ID: <20000707140856.G26534@xs4all.nl> --OwLcNYc0lM97+oe1 Content-Type: text/plain; charset=us-ascii On Thu, Jul 06, 2000 at 06:53:51PM -0500, Guido van Rossum wrote: > Greg's got it right. It's a recursive descent a.k.a. LL(1) parser. > The solution? Try to rewrite the grammar to avoid the ambiguities. > So we have [testlist | rangemaker] for listmaker, where testlist is > test(','test)* and rangemaker is [test]':'[test]. (Note that you'll > have to add [':'[test]] to support [lo:hi:step], but tht's not the > problem here.) > listmaker: [rangetail | test((','test)* | rangetail)] > rangetail: ':' [test] [':' [test]] Right, that's what I realized, too, after Greg told me what the problem was :) I basically did this, though the first 'test' in rangetail isn't optional, and I don't think it would make sense to have the 2nd test optional relative to the colon. But if you insist, it's a 2-character change ;) > The disadvantage is that you have to change the code generator to work > withthis mess -- that's why people like LALR(1) and other parsers. > But LL(1) was all I could create myself (Python uses a homegrown > parser generator). Actually, it turned out not to be that much of a mess. There's one 'if' statement that might look a bit strange, but the rest is pretty straightforward. I've attached the patch, it works ;) but it isn't finished yet: I'll try to get rid of the code duplication, add some comments and submit one relative to the list comprehension patch, so that when that one goes in, this one can, too ;) Don't forget to re-make Grammar if you test this patch out. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! --OwLcNYc0lM97+oe1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rangemaker.patch" diff -crN --exclude=CVS src/Grammar/Grammar src-rangemaker/Grammar/Grammar *** src/Grammar/Grammar Tue Mar 28 18:49:00 2000 --- src-rangemaker/Grammar/Grammar Fri Jul 7 10:32:19 2000 *************** *** 74,80 **** term: factor (('*'|'/'|'%') factor)* factor: ('+'|'-'|'~') factor | power power: atom trailer* ('**' factor)* ! atom: '(' [testlist] ')' | '[' [testlist] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ lambdef: 'lambda' [varargslist] ':' test trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME subscriptlist: subscript (',' subscript)* [','] --- 74,80 ---- term: factor (('*'|'/'|'%') factor)* factor: ('+'|'-'|'~') factor | power power: atom trailer* ('**' factor)* ! atom: '(' [testlist] ')' | '[' [listmaker] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ lambdef: 'lambda' [varargslist] ':' test trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME subscriptlist: subscript (',' subscript)* [','] diff -crN --exclude=CVS src/Include/opcode.h src-rangemaker/Include/opcode.h *** src/Include/opcode.h Fri Jun 30 19:58:04 2000 --- src-rangemaker/Include/opcode.h Fri Jul 7 13:05:13 2000 *************** *** 67,73 **** #define RETURN_VALUE 83 #define EXEC_STMT 85 ! #define POP_BLOCK 87 #define END_FINALLY 88 #define BUILD_CLASS 89 --- 67,73 ---- #define RETURN_VALUE 83 #define EXEC_STMT 85 ! #define BUILD_RANGE 86 #define POP_BLOCK 87 #define END_FINALLY 88 #define BUILD_CLASS 89 diff -crN --exclude=CVS src/Python/ceval.c src-rangemaker/Python/ceval.c *** src/Python/ceval.c Fri Jun 30 19:58:05 2000 --- src-rangemaker/Python/ceval.c Fri Jul 7 13:05:40 2000 *************** *** 65,70 **** --- 65,71 ---- static PyObject *cmp_outcome Py_PROTO((int, PyObject *, PyObject *)); static int import_from Py_PROTO((PyObject *, PyObject *, PyObject *)); static PyObject *build_class Py_PROTO((PyObject *, PyObject *, PyObject *)); + static PyObject *build_range Py_PROTO((PyObject *, PyObject *, PyObject *)); static int exec_statement Py_PROTO((PyFrameObject *, PyObject *, PyObject *, PyObject *)); static PyObject *find_from_args Py_PROTO((PyFrameObject *, int)); *************** *** 1110,1115 **** --- 1111,1127 ---- Py_DECREF(w); break; + case BUILD_RANGE: + w = POP(); + v = POP(); + u = POP(); + x = build_range(u, v, w); + PUSH(x); + Py_DECREF(u); + Py_DECREF(v); + Py_DECREF(w); + break; + case POP_BLOCK: { PyTryBlock *b = PyFrame_BlockPop(f); *************** *** 2801,2806 **** --- 2813,2897 ---- } } return PyClass_New(bases, methods, name); + } + + /* Stolen from bltinmodule.c */ + static long + get_len_of_range(lo, hi, step) + long lo; + long hi; + long step; /* must be > 0 */ + { + /* ------------------------------------------------------------- + If lo >= hi, the range is empty. + Else if n values are in the range, the last one is + lo + (n-1)*step, which must be <= hi-1. Rearranging, + n <= (hi - lo - 1)/step + 1, so taking the floor of the RHS gives + the proper value. Since lo < hi in this case, hi-lo-1 >= 0, so + the RHS is non-negative and so truncation is the same as the + floor. Letting M be the largest positive long, the worst case + for the RHS numerator is hi=M, lo=-M-1, and then + hi-lo-1 = M-(-M-1)-1 = 2*M. Therefore unsigned long has enough + precision to compute the RHS exactly. + ---------------------------------------------------------------*/ + long n = 0; + if (lo < hi) { + unsigned long uhi = (unsigned long)hi; + unsigned long ulo = (unsigned long)lo; + unsigned long diff = uhi - ulo - 1; + n = (long)(diff / (unsigned long)step + 1); + } + return n; + } + + static PyObject * + build_range(starto, endo, stepo) + PyObject *starto; + PyObject *endo; + PyObject *stepo; + { + long ilow = 0, ihigh = 0, istep = 1; + long bign; + int i, n; + PyObject * v; + + ilow = PyInt_AsLong(starto); + if (ilow == -1 && PyErr_Occurred()) + return NULL; + ihigh = PyInt_AsLong(endo); + if (ihigh == -1 && PyErr_Occurred()) + return NULL; + istep = PyInt_AsLong(stepo); + if (istep == -1 && PyErr_Occurred()) + return NULL; + + if (istep == 0) { + PyErr_SetString(PyExc_ValueError, "zero step for builtin range"); + return NULL; + } + if (istep > 0) + bign = get_len_of_range(ilow, ihigh, istep); + else + bign = get_len_of_range(ihigh, ilow, -istep); + n = (int)bign; + if (bign < 0 || (long)n != bign) { + PyErr_SetString(PyExc_OverflowError, + "too many items in builin range"); + return NULL; + } + v = PyList_New(n); + if (v == NULL) + return NULL; + for (i = 0; i < n; i++) { + PyObject *w = PyInt_FromLong(ilow); + if (w == NULL) { + Py_DECREF(v); + return NULL; + } + PyList_SET_ITEM(v, i, w); + ilow += istep; + } + return v; } static int diff -crN --exclude=CVS src/Python/compile.c src-rangemaker/Python/compile.c *** src/Python/compile.c Mon Jul 3 17:39:47 2000 --- src-rangemaker/Python/compile.c Fri Jul 7 13:05:41 2000 *************** *** 1018,1026 **** { int len; int i; ! if (TYPE(n) != testlist) ! REQ(n, exprlist); ! /* exprlist: expr (',' expr)* [',']; likewise for testlist */ len = (NCH(n) + 1) / 2; for (i = 0; i < NCH(n); i += 2) com_node(c, CHILD(n, i)); --- 1018,1025 ---- { int len; int i; ! REQ(n, listmaker); ! /* listmaker: test (',' test)* [',']; rangetail ommited */ len = (NCH(n) + 1) / 2; for (i = 0; i < NCH(n); i += 2) com_node(c, CHILD(n, i)); *************** *** 1029,1034 **** --- 1028,1081 ---- } static void + com_rangetail(c, n) + struct compiling *c; + node *n; + { + REQ(n, rangetail); + com_node(c, CHILD(n, 1)); + if (NCH(n) > 3) { + com_node(c, CHILD(n, 3)); + } else { + PyObject *v = PyInt_FromLong(1L); + if (!v) + c->c_errors++; + com_addoparg(c, LOAD_CONST, com_addconst(c, v)); + com_push(c, 1); + Py_XDECREF(v); + } + com_addbyte(c, BUILD_RANGE); + com_pop(c, 3); + } + + static void + com_listmaker(c, n) + struct compiling *c; + node *n; + { + if (TYPE(CHILD(n, 0)) != rangetail && (NCH(n) == 1 || + TYPE(CHILD(n, 1)) != rangetail)) { + /* '[' test (',' test)* [','] ']' */ + com_list_constructor(c, n); + return; + } + if (NCH(n) == 1) { + /* '[' rangetail ']' */ + PyObject *v = PyInt_FromLong(0L); + if (!v) + c->c_errors++; + com_addoparg(c, LOAD_CONST, com_addconst(c, v)); + com_push(c, 1); + Py_XDECREF(v); + com_rangetail(c, CHILD(n, 0)); + } else { + com_node(c, CHILD(n, 0)); + com_rangetail(c, CHILD(n, 1)); + } + } + + + static void com_dictmaker(c, n) struct compiling *c; node *n; *************** *** 1073,1079 **** com_push(c, 1); } else ! com_list_constructor(c, CHILD(n, 1)); break; case LBRACE: /* '{' [dictmaker] '}' */ com_addoparg(c, BUILD_MAP, 0); --- 1120,1126 ---- com_push(c, 1); } else ! com_listmaker(c, CHILD(n, 1)); break; case LBRACE: /* '{' [dictmaker] '}' */ com_addoparg(c, BUILD_MAP, 0); --OwLcNYc0lM97+oe1-- From fredrik@pythonware.com Fri Jul 7 13:30:51 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 14:30:51 +0200 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> Message-ID: <020001bfe80f$3b23ab10$0900a8c0@SPIFF> guido wrote: > I propose ustr(x) with the semantics given by Toby. +1 on concept. not sure about the name and the semantics. maybe a better name would be "unistr" (to match "unistr"). or maybe that's backwards? how about "String" (!). (the perfect name is "string", but that appears to be reserved by someone else...) as for the semantics, note that __str__ is allowed to return a unicode string in the current code base ("str" converts it to 8- bit using the default encoding). ustr/unistr/String should pass that one right through: def ustr(s): if type(s) in (type(""), type(u"")): return s s = s.__str__() if type(s) in (type(""), type(u"")): return s raise "__str__ returned wrong type" > Class support (an __ustr__ method, with fallbacks on __str__ > and __unicode__) would also be handy. -0 on this one (__str__ can already return either type, and if the goal is to get rid of both unichr and unistr in the future, we shouldn't add more hooks if we can avoid it. it's easier to remove stuff if you don't add them in the first place ;-) From thomas@xs4all.net Fri Jul 7 13:31:30 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 7 Jul 2000 14:31:30 +0200 Subject: [Python-Dev] Grammar help. In-Reply-To: <20000707140856.G26534@xs4all.nl>; from thomas@xs4all.net on Fri, Jul 07, 2000 at 02:08:56PM +0200 References: <20000707000407.E26534@xs4all.nl> <20000706182256.A15938@ludwig.cnri.reston.va.us> <200007062353.SAA01958@cj20424-a.reston1.va.home.com> <20000707140856.G26534@xs4all.nl> Message-ID: <20000707143130.H26534@xs4all.nl> On Fri, Jul 07, 2000 at 02:08:56PM +0200, Thomas Wouters wrote: > Don't forget to re-make Grammar if you test this patch out. Hm, something went wrong with the diff. Damned context diffs ;) > diff -crN --exclude=CVS src/Grammar/Grammar src-rangemaker/Grammar/Grammar > *** src/Grammar/Grammar Tue Mar 28 18:49:00 2000 > --- src-rangemaker/Grammar/Grammar Fri Jul 7 10:32:19 2000 > *************** > *** 74,80 **** > term: factor (('*'|'/'|'%') factor)* > factor: ('+'|'-'|'~') factor | power > power: atom trailer* ('**' factor)* > ! atom: '(' [testlist] ')' | '[' [testlist] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ > lambdef: 'lambda' [varargslist] ':' test > trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME > subscriptlist: subscript (',' subscript)* [','] > --- 74,80 ---- > term: factor (('*'|'/'|'%') factor)* > factor: ('+'|'-'|'~') factor | power > power: atom trailer* ('**' factor)* > ! atom: '(' [testlist] ')' | '[' [listmaker] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ > lambdef: 'lambda' [varargslist] ':' test > trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME > subscriptlist: subscript (',' subscript)* [','] If you want to try this patch out, you should add listmaker: rangetail | test ( rangetail | (',' test)* [',']) rangetail: ':' test [':' test] somewhere in Grammar/Grammar. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From pf@artcom-gmbh.de Fri Jul 7 13:26:38 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Fri, 7 Jul 2000 14:26:38 +0200 (MEST) Subject: [Python-Dev] webbrowser module In-Reply-To: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at "Jul 6, 2000 11:40:33 pm" Message-ID: Hi, Fred L. Drake, Jr.: > Ok, I've checked in the documentation for the webbrowser > documentation. The implementation can go in as soon as SF clears a > bogus read lock (support request files 6.5 hours ago). [...] May I suggest the patch below? It add's support for the Linux KDE file manager KFM (aka Konquerer) as the default web browser. This esspecially makes sense on smaller Linux machines, where users don't want to spend the huge amount of memory needed by a browser bloated to no avail with trashy stuff like Java / Javascript .... Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) ---- 8< ---- 8< ---- cut here ---- 8< ---- schnipp ---- 8< ---- schnapp ---- *** webbrowser.py.orig Fri Jul 7 10:28:05 2000 --- webbrowser.py Fri Jul 7 14:08:32 2000 *************** *** 1,4 **** ! """Remote-control interfaces to some browsers.""" import os import sys --- 1,4 ---- ! """webbrowser -- Remote-control interfaces to some browsers.""" import os import sys *************** *** 30,35 **** --- 30,36 ---- L[1] = L[0]() return L[1] + # Please note: the following definition hides a builtin function. def open(url, new=0): get().open(url, new) *************** *** 56,61 **** --- 57,63 ---- if os.environ.get("DISPLAY"): _browsers.extend([ ("netscape", "netscape %s >/dev/null &"), + ("kfmclient", "kfmclient openURL %s"), ("mosaic", "mosaic %s >/dev/null &"), ]) _browsers.extend([ *************** *** 102,107 **** --- 104,131 ---- register("netscape", Netscape) + class Konquerer: + """see http://developer.kde.org/documentation/other/kfmclient.html""" + def _remote(self, action): + cmd = "kfmclient %s >/dev/null 2>&1" % action + rc = os.system(cmd) + if rc: + import time + os.system("kfm -d &") + time.sleep(PROCESS_CREATION_DELAY) + rc = os.system(cmd) + return not rc + + def open(self, url, new=1): + # XXX currently I know no way to prevent KFM from opening a new win. + self.open_new(url) + + def open_new(self, url): + self._remote("openURL %s" % url) + + register("kfm", Konquerer) + + class Grail: # There should be a way to maintain a connection to Grail, but the # Grail remote control protocol doesn't really allow that at this *************** *** 167,172 **** --- 191,208 ---- DEFAULT_BROWSER = "windows-default" elif not os.environ.get("DISPLAY"): DEFAULT_BROWSER = "command-line-browser" + elif sys.platform == "linux2": + def small_ram(): + """returns True on machines with less than 128 MB Ram""" + import string, __builtin__ + memtotal = long(string.split( + __builtin__.open("/proc/meminfo").readlines()[1])[1]) + return memtotal < 128L * 1024 * 1024 # less than 128 MB + + if small_ram(): + DEFAULT_BROWSER = "kfm" + else: + DEFAULT_BROWSER = "netscape" else: DEFAULT_BROWSER = "netscape" From esr@thyrsus.com Fri Jul 7 14:03:22 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 7 Jul 2000 09:03:22 -0400 Subject: [Python-Dev] webbrowser module In-Reply-To: ; from pf@artcom-gmbh.de on Fri, Jul 07, 2000 at 02:26:38PM +0200 References: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> Message-ID: <20000707090322.A29880@thyrsus.com> Peter Funk : > May I suggest the patch below? It add's support for the > Linux KDE file manager KFM (aka Konquerer) as the default > web browser. This esspecially makes sense on smaller Linux > machines, where users don't want to spend the huge amount of > memory needed by a browser bloated to no avail with trashy > stuff like Java / Javascript .... Good patch! -- Eric S. Raymond The American Republic will endure, until politicians realize they can bribe the people with their own money. -- Alexis de Tocqueville From mal@lemburg.com Fri Jul 7 13:56:37 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 14:56:37 +0200 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <020001bfe80f$3b23ab10$0900a8c0@SPIFF> Message-ID: <3965D385.68D97C31@lemburg.com> Fredrik Lundh wrote: > > guido wrote: > > I propose ustr(x) with the semantics given by Toby. > > +1 on concept. > > not sure about the name and the semantics. Uhm, what's left then ;-) ? > maybe a better name would be "unistr" (to match "unistr"). > or maybe that's backwards? > > how about "String" (!). > > (the perfect name is "string", but that appears to be reserved > by someone else...) > > as for the semantics, note that __str__ is allowed to return a > unicode string in the current code base ("str" converts it to 8- > bit using the default encoding). ustr/unistr/String should pass > that one right through: > > def ustr(s): > if type(s) in (type(""), type(u"")): > return s > s = s.__str__() > if type(s) in (type(""), type(u"")): > return s > raise "__str__ returned wrong type" > > > Class support (an __ustr__ method, with fallbacks on __str__ > > and __unicode__) would also be handy. > > -0 on this one (__str__ can already return either type, and if the > goal is to get rid of both unichr and unistr in the future, we shouldn't > add more hooks if we can avoid it. it's easier to remove stuff if you > don't add them in the first place ;-) Agreed. I'm just adding coercion support for instances using that technique: instance defining __str__ can return Unicode objects which will then be used by the implementation whereever coercion to Unicode takes place. I'll add a similar hook to unicode(). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From alexwg@MIT.EDU Fri Jul 7 14:31:52 2000 From: alexwg@MIT.EDU (Alexander D Wissner-Gross) Date: Fri, 7 Jul 2000 09:31:52 -0400 (EDT) Subject: [Python-Dev] Re: [Patches] [Patch #100752] Make atoi work for negative bases, a useful generalization In-Reply-To: <14693.19707.553522.523595@beluga.mojam.com> Message-ID: Skip, Built-in support for negative bases would encourage further use of Python in math research (specifically, representation theory). For reference, Mathematica recently added support for negative base conversions. Negative bases allow the unique representation of both positive and negative integers without use of a sign. For example, "-3" in decimal equals, in base -2, "1101" (-3 = 1*(-2)^3 + 1*(-2)^2 + 0*(-2)^1 + 1*(-2)^0). It has been suggested that this property makes negative bases a more natural representation for integers than positive bases. There is more detailed information on the subject in The Art of Computer Programming Vol. 2. This functionality is not already in Python, as someone suggested on patches@python.org. Alex From guido@beopen.com Fri Jul 7 15:38:39 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 09:38:39 -0500 Subject: [Python-Dev] Re: [Patches] [Patch #100752] Make atoi work for negative bases, a useful generalization In-Reply-To: Your message of "Fri, 07 Jul 2000 09:31:52 -0400." References: Message-ID: <200007071438.JAA04100@cj20424-a.reston1.va.home.com> > Built-in support for negative bases would encourage further use of Python > in math research (specifically, representation theory). For reference, > Mathematica recently added support for negative base conversions. > > Negative bases allow the unique representation of both positive and > negative integers without use of a sign. For example, "-3" in decimal > equals, in base -2, "1101" (-3 = 1*(-2)^3 + 1*(-2)^2 + 0*(-2)^1 + 1*(-2)^0). > It has been suggested that this property makes negative bases a more natural > representation for integers than positive bases. There is more detailed > information on the subject in The Art of Computer Programming Vol. 2. Only a mathematician could call this "more natural"... For most of us, this is difficult to understand (e.g. the suggestion was made that int(s,x) == -int(s,-x), which isn't true) and there are no practical uses. As most of Python's users lack the sophistication to understand this, I'd rather not introduce this patch -- when I see a negative base somewhere, it's much more likely that it's a bug in the code than an advanced use of negative bases... That's a polite but firm -1. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal@lemburg.com Fri Jul 7 15:17:34 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 16:17:34 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines References: <20000707094036.AA22C31047C@bireme.oratrix.nl> <3965B6F8.72742A2E@lemburg.com> <20000707120149.6B39631047C@bireme.oratrix.nl> Message-ID: <3965E67E.CE81253D@lemburg.com> Sjoerd Mullender wrote: > > On Fri, Jul 7 2000 "M.-A. Lemburg" wrote: > > > Perhaps you could figure out which defines are needed to > > reenable the missing APIs on IRIX when _XOPEN_SOURCE is > > defined... it would be helpful to help pin-point the > > weak spots w/r to SUSv2 compatibility. > > It looks like there is no way of doing this. The relevant bits of > code are: > > In time.h (as an example): > #if _SGIAPI && _NO_ANSIMODE > extern time_t altzone; > #endif /* _SGIAPI */ > > So _SGIAPI and _NO_ANSIMODE should both be defined and != 0. > The definition of _SGIAPI is > #define _SGIAPI ((defined(_SGI_SOURCE) && \ > _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5) || \ > (_ANSIMODE && _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5)) > So, if _NO_XOPEN5 is 0, _SGIAPI is 0. The definition of _NO_XOPEN5 is > #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || \ > (defined(_XOPEN_SOURCE) && \ > (_XOPEN_SOURCE+0 < 500))) > So _NO_XOPEN5 is 0 since _XOPEN_SOURCE is defined and >= 500. Hmm, would that mean that altzone is not part of SUSv2 (in that case we'd have to change Python) ? Or are the SGI header files wrong here (which means we'd have to work around those bugs) ? > All of this on IRIX 6.5.2. I can't check other versions of IRIX. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik@pythonware.com Fri Jul 7 15:40:40 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 16:40:40 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines References: <20000707094036.AA22C31047C@bireme.oratrix.nl> <3965B6F8.72742A2E@lemburg.com> <20000707120149.6B39631047C@bireme.oratrix.nl> <3965E67E.CE81253D@lemburg.com> Message-ID: <02d201bfe821$52c4b090$0900a8c0@SPIFF> mal wrote: > Hmm, would that mean that altzone is not part of SUSv2 as far as I can tell, altzone is not part of SUSv2. the time.h file declares the following variables: extern int daylight; extern long int timezone; extern char *tzname[]; does anyone know what standard (if any) altzone is defined by? From sjoerd@oratrix.nl Fri Jul 7 16:05:53 2000 From: sjoerd@oratrix.nl (Sjoerd Mullender) Date: Fri, 07 Jul 2000 17:05:53 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines In-Reply-To: Your message of Fri, 07 Jul 2000 16:40:40 +0200. <02d201bfe821$52c4b090$0900a8c0@SPIFF> References: <20000707094036.AA22C31047C@bireme.oratrix.nl> <3965B6F8.72742A2E@lemburg.com> <20000707120149.6B39631047C@bireme.oratrix.nl> <3965E67E.CE81253D@lemburg.com> <02d201bfe821$52c4b090$0900a8c0@SPIFF> Message-ID: <20000707150554.37E2031047C@bireme.oratrix.nl> One of the big problems with configure is that the defines that are used to test features are not necessarily the same as the defines that are used when those features are actually used in the program being configured. Python's configure script tests for altzone, and if the defines in effect there were the same as the ones in effect during compilation, altzone would not have been found and the compilation would have gone smoothly. I don't have a solution for this problem, but a problem it is. -- Sjoerd Mullender From fdrake@beopen.com Fri Jul 7 17:22:16 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 12:22:16 -0400 (EDT) Subject: [Python-Dev] _sre.c's compiled size In-Reply-To: <20000707135641.F26534@xs4all.nl> References: <20000707135641.F26534@xs4all.nl> Message-ID: <14694.952.281470.320804@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > I've attached a teensy patch that allows '-f' flags to be used in > Setup files, to be able to easily switch between the two. This is checked in; thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Fri Jul 7 17:40:26 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 12:40:26 -0400 (EDT) Subject: [Python-Dev] webbrowser module In-Reply-To: References: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> Message-ID: <14694.2042.320980.231242@cj42289-a.reston1.va.home.com> Peter Funk writes: > May I suggest the patch below? It add's support for the > Linux KDE file manager KFM (aka Konquerer) as the default > web browser. This esspecially makes sense on smaller Linux Peter, Thanks for the Konquerer class! I'll add that. What I'm not sure about is using it as a default value if the use isn't running KDE. I just tried to play with kfm while Gnome was running, and it tried to load docklets and the like, which wasn't useful since the KDE panel wasn't running. (On the other hand, kfm *did* start up with the -d option, and kfmclient worked.) But that means that kfm was putting icons on my "desktop", and that's something I definately don't want. So I'm hesitant. Is there a reasonably reliable way to determine if the user is running KDE, and only make this the default in that case? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip@mojam.com (Skip Montanaro) Fri Jul 7 17:53:19 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 7 Jul 2000 11:53:19 -0500 (CDT) Subject: [Python-Dev] webbrowser module In-Reply-To: <14694.2042.320980.231242@cj42289-a.reston1.va.home.com> References: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> <14694.2042.320980.231242@cj42289-a.reston1.va.home.com> Message-ID: <14694.2815.308486.875411@beluga.mojam.com> Fred> What I'm not sure about is using it as a default value if the use Fred> isn't running KDE. Fred, I'm running kde. From bash I see an environment variable named KDEDIR whose value is "/usr". Would that be a possible extra test to assure that kde is running before deciding to launch kfm? Skip From fdrake@beopen.com Fri Jul 7 18:05:09 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 13:05:09 -0400 (EDT) Subject: [Python-Dev] webbrowser module In-Reply-To: <14694.2815.308486.875411@beluga.mojam.com> References: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> <14694.2042.320980.231242@cj42289-a.reston1.va.home.com> <14694.2815.308486.875411@beluga.mojam.com> Message-ID: <14694.3525.845782.579413@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > I'm running kde. From bash I see an environment variable named KDEDIR whose > value is "/usr". Would that be a possible extra test to assure that kde is > running before deciding to launch kfm? Sounds good! How about this for the non-MacOS portion of the default-browser determination: DEFAULT_BROWSER = "command-line" if sys.platform[:3] == "win": del _browsers["kfm"] register("windows-default", WindowsDefault) DEFAULT_BROWSER = "windows-default" elif os.environ.get("DISPLAY"): if os.environ.get("KDEDIR"): DEFAULT_BROWSER = "kfm" elif _iscommand("netscape"): DEFAULT_BROWSER = "netscape" -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pf@artcom-gmbh.de Fri Jul 7 19:02:41 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Fri, 7 Jul 2000 20:02:41 +0200 (MEST) Subject: [Python-Dev] webbrowser module In-Reply-To: <14694.3525.845782.579413@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at "Jul 7, 2000 1: 5: 9 pm" Message-ID: Hi, Fred L. Drake, Jr. : > > Skip Montanaro writes: > > I'm running kde. From bash I see an environment variable named KDEDIR whose > > value is "/usr". Would that be a possible extra test to assure that kde is > > running before deciding to launch kfm? Clever idea, Skip! This will also work on SuSE Linux, where I have KDEDIR=/opt/kde > Sounds good! How about this for the non-MacOS portion of the > default-browser determination: > > DEFAULT_BROWSER = "command-line" > > if sys.platform[:3] == "win": > del _browsers["kfm"] > register("windows-default", WindowsDefault) > DEFAULT_BROWSER = "windows-default" > elif os.environ.get("DISPLAY"): > if os.environ.get("KDEDIR"): > DEFAULT_BROWSER = "kfm" > elif _iscommand("netscape"): > DEFAULT_BROWSER = "netscape" I believe there might be some people using KDE on a luxury computer (like the rolls royce alike that Fred has) and because they don't have to bother about RAM usage, they still may want to use Netscape as their default browser under KDE. I muust admit that Netscape provides more features and nice bookmark handling, although the differences might become smaller with KDE 2.x. That however again will burn more RAM. :-( Testing for available RAM will only work on Linux on the other hand, because most other unices lack '/proc/meminfo'. Using something more portable like the famous 'wc -c /dev/mem' unix tool abuse hack will not work due to the obvious lack of read permissions on /dev/mem for simple user processes. Adding the proposed AI (heuristic, hack, rule-of-thumb whatever you want to call it) to choose the default browser dependent on the amount of installed RAM is quite unpythonic, or what? However it is so simple, since Linux and Python are really powerful here: def small_ram(): """returns True on machines with less than 128 MB Ram""" import string, __builtin__ memtotal = long(string.split( __builtin__.open("/proc/meminfo").readlines()[1])[1]) return memtotal < 128L * 1024 * 1024 # less than 128 MB May be the best solution would be to test if any of the _browsers, which support a remote protocol is already running and only fire up a new browser, if no browser process can be identified. This however will break the current class hierarchy. So this should be delayed until Python 2.1? Finally: I like your proposed solution. Regards, Peter From paul@prescod.net Fri Jul 7 19:08:47 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 07 Jul 2000 13:08:47 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> Message-ID: <39661CAF.9252D734@prescod.net> Guido van Rossum wrote: > > ... > > For strings there is no compact notation like "+0.0" if you want to > convert to string or Unicode -- adding "" might work in Perl, but not > in Python. Actually, these days, foo+"" works in a LOT of languages. Perl, Java and JavaScript for sure. C++, depending on the type. Python's strictness about this issue has never caught a bug for me. It has only caused errors. Okay, some newbie may think that "5"+"5"=="10". But they could also expect [5]+[5]==[10]. There are limits to the extent that we can protect them from incorrect mental models. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From akuchlin@mems-exchange.org Fri Jul 7 19:15:05 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 07 Jul 2000 14:15:05 -0400 Subject: [Python-Dev] c.l.py.a revival Message-ID: While waiting for word of a 2.0b1 release, what about continuing to attempt to revive c.l.python.announce? Last I remember, it was suggested to add Guido as a moderator so he could in turn delegate handling of messages to someone else. Was any progress ever made with this? --amk From fdrake@beopen.com Fri Jul 7 19:19:16 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 14:19:16 -0400 (EDT) Subject: [Python-Dev] c.l.py.a revival In-Reply-To: References: Message-ID: <14694.7972.264112.121727@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > While waiting for word of a 2.0b1 release, what about continuing to > attempt to revive c.l.python.announce? Last I remember, it was > suggested to add Guido as a moderator so he could in turn delegate > handling of messages to someone else. Was any progress ever made with I think the problem was that the current moderators had to add Guido as a moderator; once that's done Guido can delegate as desired. Can you prod Markus for us on this one? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal@lemburg.com Fri Jul 7 19:20:53 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 20:20:53 +0200 Subject: [Python-Dev] c.l.py.a revival References: Message-ID: <39661F85.B87EDB2E@lemburg.com> Andrew Kuchling wrote: > > While waiting for word of a 2.0b1 release, what about continuing to > attempt to revive c.l.python.announce? Last I remember, it was > suggested to add Guido as a moderator so he could in turn delegate > handling of messages to someone else. Was any progress ever made with > this? How about reviving the announcement mailing list first -- messages posted to that list result in an error return mail and don't show up anywhere. If that works, I'd suggest adding support for forwarding the messages to the moderated list via the hack that was described last time we discussed this. I think Barry is already working on this one, right ;-) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy@beopen.com Fri Jul 7 19:23:41 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 14:23:41 -0400 (EDT) Subject: [Python-Dev] c.l.py.a revival In-Reply-To: References: Message-ID: <14694.8237.260813.999821@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> While waiting for word of a 2.0b1 release, what about AMK> continuing to attempt to revive c.l.python.announce? Last I AMK> remember, it was suggested to add Guido as a moderator so he AMK> could in turn delegate handling of messages to someone else. AMK> Was any progress ever made with this? I believe the desired solution was actually to use the python-announce mailing list to moderate the newsgroup. The current moderator sketched the desired setup, which involved setting up the mailing list moderation software to add the headers that indicated it was approved by the newsgroup moderators. I believe this is still on Barry's plate -- along with too many other things for me to count, but at least not bibimbap or doji bulgogi. Jeremy From fredrik@pythonware.com Fri Jul 7 20:05:01 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 21:05:01 +0200 Subject: [Python-Dev] where did httplib.HTTPS go? Message-ID: <000701bfe846$41b8ad40$0900a8c0@SPIFF> [fredrik@brain src]$ ./python Python 2.0b1 (#4, Jul 7 2000, 12:23:15) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 >>> import httplib >>> httplib.HTTPS Traceback (most recent call last): File "", line 1, in ? AttributeError: HTTPS urllib and the test code in httplib.py uses HTTPS, but I cannot find it. and neither can grep: Lib/httplib.py:HTTPS_PORT = 443 Lib/httplib.py:class HTTPSConnection(HTTPConnection): Lib/httplib.py: default_port = HTTPS_PORT Lib/httplib.py: hs = HTTPS() Lib/urllib.py: """Use HTTPS protocol.""" Lib/urllib.py: h = httplib.HTTPS(host, 0, where is it? what am I missing? From jeremy@beopen.com Fri Jul 7 20:13:13 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 15:13:13 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <000701bfe846$41b8ad40$0900a8c0@SPIFF> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> Message-ID: <14694.11209.999476.330370@bitdiddle.concentric.net> Looks like Greg didn't add it before he checked in the new implementation. I thought he was going to. I also thought he was going to change the indentation to four spaces. Is that a standard for Python code in the library, or am I just being fussy? Jeremy From fredrik@pythonware.com Fri Jul 7 20:13:27 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 21:13:27 +0200 Subject: [Python-Dev] bogus LANG setting results in "import site failed" message Message-ID: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> [fredrik@brain src]$ export LANG=foobar [fredrik@brain src]$ ./python 'import site' failed; use -v for traceback Python 2.0b1 (#4, Jul 7 2000, 12:23:15) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> that "import site" is a bit disturbing. maybe the locale-checking code should handle this case a bit more gracefully? (like, say, printing a more explicit warning message). From fdrake@beopen.com Fri Jul 7 20:14:14 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 15:14:14 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.11209.999476.330370@bitdiddle.concentric.net> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> Message-ID: <14694.11270.542014.447760@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > I also thought he was going to change the indentation to four spaces. > Is that a standard for Python code in the library, or am I just being > fussy? All new code should use four-space indents, but we've never gone through and agressively converted old code. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy@beopen.com Fri Jul 7 20:19:45 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 15:19:45 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.11270.542014.447760@cj42289-a.reston1.va.home.com> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <14694.11270.542014.447760@cj42289-a.reston1.va.home.com> Message-ID: <14694.11601.611455.4339@bitdiddle.concentric.net> >>>>> "FLD" == Fred L Drake, writes: FLD> Jeremy Hylton writes: >> I also thought he was going to change the indentation to four >> spaces. Is that a standard for Python code in the library, or am >> I just being fussy? FLD> All new code should use four-space indents, but we've never FLD> gone through and agressively converted old code. Why is it that a reply from you in particular doesn't make me feel confident that I am not being fussy? :-) Jeremy From fdrake@beopen.com Fri Jul 7 20:19:39 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 15:19:39 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.11601.611455.4339@bitdiddle.concentric.net> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <14694.11270.542014.447760@cj42289-a.reston1.va.home.com> <14694.11601.611455.4339@bitdiddle.concentric.net> Message-ID: <14694.11595.370101.739327@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > Why is it that a reply from you in particular doesn't make me feel > confident that I am not being fussy? :-) I didn't say you *weren't* being fussy. ;) I will say that you *should* be fusy, which may be about what you expect. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw@beopen.com Fri Jul 7 20:33:55 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 7 Jul 2000 15:33:55 -0400 (EDT) Subject: [Python-Dev] c.l.py.a revival References: <14694.8237.260813.999821@bitdiddle.concentric.net> Message-ID: <14694.12451.606319.130358@anthem.concentric.net> Yup, it's still on my plate and I'll try to spend some time on it this weekend. From mal@lemburg.com Fri Jul 7 20:37:35 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 21:37:35 +0200 Subject: [Python-Dev] bogus LANG setting results in "import site failed" message References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> Message-ID: <3966317F.4A39E6A2@lemburg.com> Fredrik Lundh wrote: > > [fredrik@brain src]$ export LANG=foobar > [fredrik@brain src]$ ./python > 'import site' failed; use -v for traceback > Python 2.0b1 (#4, Jul 7 2000, 12:23:15) [GCC egcs-2.91.66 19990314/Linux > (egcs-1.1.2 release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> > > that "import site" is a bit disturbing. maybe the locale-checking > code should handle this case a bit more gracefully? > > (like, say, printing a more explicit warning message). Here's the patch (Skip's locking the Lib dir ... grrr ;-): --- CVS-Python/Lib/site.py Wed Jun 28 17:30:57 2000 +++ Python+Unicode/Lib/site.py Fri Jul 7 21:30:54 2000 @@ -124,11 +124,16 @@ del exit # encoding used by the default locale of this system. If the default # encoding cannot be determined or is unknown, it defaults to 'ascii'. # def locale_aware_defaultencoding(): import locale - code, encoding = locale.get_default() + try: + code, encoding = locale.get_default() + except ValueError, why: + sys.stderr.write('Error setting default encoding (%s), using ASCII.\n' + % why) + encoding = None if encoding is None: encoding = 'ascii' try: sys.setdefaultencoding(encoding) except LookupError: -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Fri Jul 7 20:44:49 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 12:44:49 -0700 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.11209.999476.330370@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jul 07, 2000 at 03:13:13PM -0400 References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> Message-ID: <20000707124449.E29590@lyra.org> On Fri, Jul 07, 2000 at 03:13:13PM -0400, Jeremy Hylton wrote: > Looks like Greg didn't add it before he checked in the new > implementation. I thought he was going to. Yah, my fault. I'll get the changes back in there later tonite. > I also thought he was going to change the indentation to four spaces. > Is that a standard for Python code in the library, or am I just being > fussy? I think you're being fussy, but I can change this. I'll do a separate commit that just changes white space (and possibly reflow some comments). Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Fri Jul 7 20:46:07 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 12:46:07 -0700 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <000701bfe846$41b8ad40$0900a8c0@SPIFF>; from fredrik@pythonware.com on Fri, Jul 07, 2000 at 09:05:01PM +0200 References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> Message-ID: <20000707124606.F29590@lyra.org> On Fri, Jul 07, 2000 at 09:05:01PM +0200, Fredrik Lundh wrote: > [fredrik@brain src]$ ./python > Python 2.0b1 (#4, Jul 7 2000, 12:23:15) [GCC egcs-2.91.66 19990314/Linux > (egcs-1.1.2 release)] on linux2 > >>> import httplib > >>> httplib.HTTPS > Traceback (most recent call last): > File "", line 1, in ? > AttributeError: HTTPS > > urllib and the test code in httplib.py uses HTTPS, > but I cannot find it. and neither can grep: > > Lib/httplib.py:HTTPS_PORT = 443 > Lib/httplib.py:class HTTPSConnection(HTTPConnection): > Lib/httplib.py: default_port = HTTPS_PORT > Lib/httplib.py: hs = HTTPS() > Lib/urllib.py: """Use HTTPS protocol.""" > Lib/urllib.py: h = httplib.HTTPS(host, 0, > > where is it? what am I missing? Oh... one more comment: I'll be updating urllib.py at some point to *not* use HTTPS. It should be using HTTPSConnection instead. (and HTTPConnection rather than HTTP) ... dunno if other libraries use httplib, but I'll look and update those, too. Maybe in the Demo/ area. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one@email.msn.com Fri Jul 7 20:47:50 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 15:47:50 -0400 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <20000707124449.E29590@lyra.org> Message-ID: [Jeremy Hylton] > I also thought he was going to change the indentation to four spaces. > Is that a standard for Python code in the library, or am I just being > fussy? It is a std for distributed Python code, and so deciding whether it's fussy is irrelevant. [Greg Stein] > I think you're being fussy, Irrelevant. > but I can change this. Almost the right answer. > I'll do a separate commit that just changes white space (and possibly > reflow some comments). Bingo! life-is-so-much-easier-when-you-don't-think-too-much-ly y'rs - tim From fredrik@pythonware.com Fri Jul 7 20:48:43 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 21:48:43 +0200 Subject: [Python-Dev] repository locks References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> <3966317F.4A39E6A2@lemburg.com> Message-ID: <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> > Here's the patch (Skip's locking the Lib dir ... grrr ;-): tonight's stupid question: What's causing all these stale locks? I'm a totally clueless CVS user, and I've managed to check at least 114 things into the repository without leaving any locks behind me. Is it just sheer luck, or is there some flaw in CVS waiting for me to stumble upon? From tim_one@email.msn.com Fri Jul 7 20:55:39 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 15:55:39 -0400 Subject: [Python-Dev] repository locks In-Reply-To: <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> Message-ID: [/F] > What's causing all these stale locks? Best I can tell, Skip. > I'm a totally clueless CVS user, You don't want to fight me on that one . > and I've managed to check at least 114 things into the repository > without leaving any locks behind me. I think I've lucked out too. > Is it just sheer luck, or is there some flaw in CVS waiting > for me to stumble upon? There are many links in the chain from one of our machines to CVS on SourceForge. My bet is that if it's working for you, it will continue to work; and that we'll continue to see locks left behind by Skip until he manages to replace the link in his chain that's damaged. Also betting there's a 50-50 chance we'll never know which link it was. it's-software-it-sucks-it's-par-for-the-course-ly y'rs - tim From guido@beopen.com Fri Jul 7 22:02:16 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:02:16 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: Your message of "Fri, 07 Jul 2000 13:08:47 EST." <39661CAF.9252D734@prescod.net> References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <39661CAF.9252D734@prescod.net> Message-ID: <200007072102.QAA05114@cj20424-a.reston1.va.home.com> [me] > > For strings there is no compact notation like "+0.0" if you want to > > convert to string or Unicode -- adding "" might work in Perl, but not > > in Python. [PaulPrescod] > Actually, these days, foo+"" works in a LOT of languages. Perl, Java and > JavaScript for sure. Really? Does 3+"" really convert the 3 to a string in Java? > C++, depending on the type. Python's strictness > about this issue has never caught a bug for me. It has only caused > errors. Are you sure? This is the kind of error where you immediately see what's wrong and move on to the next bug. > Okay, some newbie may think that "5"+"5"=="10". But they could > also expect [5]+[5]==[10]. There are limits to the extent that we can > protect them from incorrect mental models. I won't argue with you there :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Fri Jul 7 22:02:49 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:02:49 -0500 Subject: [Python-Dev] c.l.py.a revival In-Reply-To: Your message of "Fri, 07 Jul 2000 14:15:05 -0400." References: Message-ID: <200007072102.QAA05127@cj20424-a.reston1.va.home.com> > While waiting for word of a 2.0b1 release, what about continuing to > attempt to revive c.l.python.announce? Last I remember, it was > suggested to add Guido as a moderator so he could in turn delegate > handling of messages to someone else. Was any progress ever made with > this? Not that I know of -- it's as dead as ever. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein@lyra.org Fri Jul 7 21:08:15 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 13:08:15 -0700 Subject: [Python-Dev] CVS: python/dist/src/Objects longobject.c,1.60,1.61 In-Reply-To: <200007071553.IAA06685@slayer.i.sourceforge.net>; from tim_one@users.sourceforge.net on Fri, Jul 07, 2000 at 08:53:31AM -0700 References: <200007071553.IAA06685@slayer.i.sourceforge.net> Message-ID: <20000707130815.I29590@lyra.org> On Fri, Jul 07, 2000 at 08:53:31AM -0700, Tim Peters wrote: >... > --- 1693,1709 ---- > sizeof(PyLongObject) - sizeof(digit), > sizeof(digit), > ! (destructor)long_dealloc, /*tp_dealloc*/ > ! 0, /*tp_print*/ > ! 0, /*tp_getattr*/ > ! 0, /*tp_setattr*/ > ! (int (*) (PyObject *, PyObject *)) > ! (cmpfunc)long_compare, /*tp_compare*/ > ! (reprfunc)long_repr, /*tp_repr*/ > ! &long_as_number, /*tp_as_number*/ > ! 0, /*tp_as_sequence*/ > ! 0, /*tp_as_mapping*/ > ! (long (*) (PyObject *)) > ! (hashfunc)long_hash, /*tp_hash*/ > ! 0, /*tp_call*/ > ! (reprfunc)long_str, /*tp_str*/ > }; What is with those double casts for tp_compare and tp_hash? The prototypes match cmpfunc and hashfunc, so I think they ought to just be dropped. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido@beopen.com Fri Jul 7 22:11:29 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:11:29 -0500 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: Your message of "Fri, 07 Jul 2000 12:44:49 MST." <20000707124449.E29590@lyra.org> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <20000707124449.E29590@lyra.org> Message-ID: <200007072111.QAA05197@cj20424-a.reston1.va.home.com> > > I also thought he was going to change the indentation to four spaces. > > Is that a standard for Python code in the library, or am I just being > > fussy? > > I think you're being fussy, but I can change this. I'll do a separate commit > that just changes white space (and possibly reflow some comments). To my eyes, 2-space indents are unreadable. Please make it 4 spaces, like all other new code. There's no excuse for arguing about whitespace in Python. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake@beopen.com Fri Jul 7 21:13:03 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 16:13:03 -0400 (EDT) Subject: [Python-Dev] repository locks In-Reply-To: <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> <3966317F.4A39E6A2@lemburg.com> <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> Message-ID: <14694.14799.389933.276211@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > I'm a totally clueless CVS user, and I've managed to check > at least 114 things into the repository without leaving any > locks behind me. The checkins aren't causing the problem -- these are read locks on the directories. > Is it just sheer luck, or is there some flaw in CVS waiting > for me to stumble upon? I think there's probably a bug in the CVS server, but not sure, and I haven't dug into the CVS code to figure it out. It looks like some operation is locking the directory (update, or a diff), and then the connection to the client disappears, and the server exits without cleaning up the lock. As long as we're reading from the repository, that doesn't matter -- the problem is when we go to write to the repository, the CVS server talking to us still thinks there's a reader, so we're denied access. Another possibility is that there's a stuck CVS server (with a dead connection) holding the lock, and it hasn't exited at all. But that's less likely. The problem is likely because we're a very active project with lots of simulataneous repository access on an overloaded service. I've noticed that the other services at SourceForge (message forums, support managers, etc.) have been really slow the past 36 hours as well. Clearly, we van blame it all on Skip. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Fri Jul 7 21:16:08 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 16:16:08 -0400 Subject: [Python-Dev] CVS: python/dist/src/Objects longobject.c,1.60,1.61 In-Reply-To: <20000707130815.I29590@lyra.org> Message-ID: [Greg Stein] > >... > > --- 1693,1709 ---- > > sizeof(PyLongObject) - sizeof(digit), > > sizeof(digit), > > ! (destructor)long_dealloc, /*tp_dealloc*/ > > ! 0, /*tp_print*/ > > ! 0, /*tp_getattr*/ > > ! 0, /*tp_setattr*/ > > ! (int (*) (PyObject *, PyObject *)) > > ! (cmpfunc)long_compare, /*tp_compare*/ > > ! (reprfunc)long_repr, /*tp_repr*/ > > ! &long_as_number, /*tp_as_number*/ > > ! 0, /*tp_as_sequence*/ > > ! 0, /*tp_as_mapping*/ > > ! (long (*) (PyObject *)) > > ! (hashfunc)long_hash, /*tp_hash*/ > > ! 0, /*tp_call*/ > > ! (reprfunc)long_str, /*tp_str*/ > > }; > > What is with those double casts for tp_compare and tp_hash? The > prototypes match cmpfunc and hashfunc, so I think they ought to > just be dropped. The patch in this area just normalized the whitespace for easier reading (although thanks to stinking hard tab characters, it may not *look* that way!) -- the double casts were there before. I'll be making more changes to the file "soon", and will look into what you suggest -- suspect you're right that it's just confusingly redundant. From guido@beopen.com Fri Jul 7 22:16:26 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:16:26 -0500 Subject: [Python-Dev] repository locks In-Reply-To: Your message of "Fri, 07 Jul 2000 21:48:43 +0200." <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> <3966317F.4A39E6A2@lemburg.com> <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> Message-ID: <200007072116.QAA05244@cj20424-a.reston1.va.home.com> > tonight's stupid question: > > What's causing all these stale locks? > > I'm a totally clueless CVS user, and I've managed to check > at least 114 things into the repository without leaving any > locks behind me. > > Is it just sheer luck, or is there some flaw in CVS waiting > for me to stumble upon? These locks are read-locks caused by checkouts that are aborted. Somehow the CVS server doesn't always catch this. I suppose there are also write-locks by commits that could be left around, but you typically don't abort a commit -- but it's common to hit ^C when an update takes a bit long. Not defending CVS (I think it should catch SIGPIPE since that's probably what it's getting since this is done remotely) but just setting the record straight. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From martin@loewis.home.cs.tu-berlin.de Fri Jul 7 21:24:03 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Fri, 7 Jul 2000 22:24:03 +0200 Subject: [Python-Dev] Encodings Message-ID: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> >> This sounds very bad. I thought we agreed that attempting to >> compare (or add) a Unicode string and an 8-bit string containing >> non-ASCII characters (as in your example) should raise an exception. > >Only if the default encoding is ASCII. That is not my understanding of the agreement, and I think the whole idea of a default encoding is a stupid one. I strongly suggest that the behaviour that Ping just explained and that Guido had suggested originally is implemented: Mixing unicode and string objects is only allowed if the string objects are ASCII. Everything else (including a "default" encoding of some kind) is an application issue. Otherwise, you'll just go on and ask questions endlessly how things should behave, and change the interpreter forwards and backwards. The meaning of mixing both kinds of objects is very easy to explain, and also allows for efficient implementation - which you won't get if you have to invoke a character conversion just to get the hash value of a unicode value (!) Regards, Martin From jeremy@beopen.com Fri Jul 7 21:31:35 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 16:31:35 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <200007072111.QAA05197@cj20424-a.reston1.va.home.com> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <20000707124449.E29590@lyra.org> <200007072111.QAA05197@cj20424-a.reston1.va.home.com> Message-ID: <14694.15911.109077.944657@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> To my eyes, 2-space indents are unreadable. Please make it 4 GvR> spaces, like all other new code. There's no excuse for arguing GvR> about whitespace in Python. :-) imputil.py also needs to be fixed. Jeremy From gstein@lyra.org Fri Jul 7 21:39:15 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 13:39:15 -0700 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.15911.109077.944657@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jul 07, 2000 at 04:31:35PM -0400 References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <20000707124449.E29590@lyra.org> <200007072111.QAA05197@cj20424-a.reston1.va.home.com> <14694.15911.109077.944657@bitdiddle.concentric.net> Message-ID: <20000707133915.L29590@lyra.org> On Fri, Jul 07, 2000 at 04:31:35PM -0400, Jeremy Hylton wrote: > >>>>> "GvR" == Guido van Rossum writes: > > GvR> To my eyes, 2-space indents are unreadable. Please make it 4 > GvR> spaces, like all other new code. There's no excuse for arguing > GvR> about whitespace in Python. :-) > > imputil.py also needs to be fixed. Damn. I just can't win! ;-) -- Greg Stein, http://www.lyra.org/ From tim_one@email.msn.com Fri Jul 7 21:39:00 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 16:39:00 -0400 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: <200007072102.QAA05114@cj20424-a.reston1.va.home.com> Message-ID: [Guido] >>> For strings there is no compact notation like "+0.0" if you want to >>> convert to string or Unicode -- adding "" might work in Perl, but not >>> in Python. BTW, "+0.0" is not a correct way to "boundedly coerce" to float under 754 arithmetic; "*1.0" is safer (the former does not always preserve the sign bit of a float zero correctly, but the latter does). [Paul Prescod] >> Actually, these days, foo+"" works in a LOT of languages. Perl, Java and >> JavaScript for sure. [Guido] > Really? Does 3+"" really convert the 3 to a string in Java? I don't remember about that specifically, but believe ""+3 does. OTOH, in *Perl* 3+"" converts "" to the *number* 0 and leaves 3 alone. >> Python's strictness about this issue has never caught a bug for me. It >> has only caused errors. > Are you sure? This is the kind of error where you immediately see > what's wrong and move on to the next bug. It's certainly caught errors for me, and especially when introducing Perl programmers to Python, where "they expect" string+number to convert the string to a number, apparently the opposite of the arbitrary choice Paul prefers. It's ambiguous as hell -- screw it. From bwarsaw@beopen.com Fri Jul 7 21:52:50 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 7 Jul 2000 16:52:50 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? References: <20000707124449.E29590@lyra.org> Message-ID: <14694.17186.868952.214837@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: >> I'll do a separate commit that just changes white space (and >> possibly reflow some comments). TP> Bingo! TP> life-is-so-much-easier-when-you-don't-think-too-much-ly TP> y'rs - tim Oh, and while you're at it, please untabify the file. I don't know if your module has tabs in it, but if so please convert all tabs to spaces. -Barry From pingster@ilm.com Fri Jul 7 21:50:32 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Fri, 7 Jul 2000 13:50:32 -0700 (PDT) Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: Message-ID: On Fri, 7 Jul 2000, Tim Peters wrote: > > Are you sure? This is the kind of error where you immediately see > > what's wrong and move on to the next bug. > > It's certainly caught errors for me, and especially when introducing Perl > programmers to Python, where "they expect" string+number to convert the > string to a number, apparently the opposite of the arbitrary choice Paul > prefers. It's not arbitrary -- the decision is made according to the type of the *operator* rather than the type of the operands. anything + anything returns a number anything . anything returns a string So "34"+0 converts to a number and 34."" converts to a string (i've seen both idioms fairly often). Anyway, i still agree that it's best to avoid automatic coercion between numbers and strings -- since it's now very easy to say int("3") as opposed to import string; string.atoi("3"), there's really no excuse for not being explicit. -- ?!ng "Things are more like they are now than they ever were before." -- Dwight D. Eisenhower From martin@loewis.home.cs.tu-berlin.de Fri Jul 7 21:53:37 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Fri, 7 Jul 2000 22:53:37 +0200 Subject: [Python-Dev] Unicode experience Message-ID: <200007072053.WAA02470@loewis.home.cs.tu-berlin.de> > Really? Does 3+"" really convert the 3 to a string in Java? Yes. It is one of my favorite Java features... If a binary + has one argument of type java.lang.String, then the other object is coerced to string as well (unless the other operand is also a string), using the following procedure: If it is a primitive type, an instance of the appopriate helper is created, in this case java.lang.Integer, so we only have java.lang.Object specializations now (*). Then, .toString() is invoked for the object, and the strings are concatenated. This allows to write things like System.out.println("Name:"+name" Age:"+age); so they did not have to copy the printf(3C) family of function, nor to introduce operator overloading for iostream-style output. Teaching this stuff to students, it turns out that there are two major sources of confusion: a) System.out.println("abc"+3+3) prints "abc33", whereas System.out.println(3+3+"abc") prints "6abc", so the binary + is not commutative. b) Both System.out.println("result "+myobj) and System.out.println(myobj) work, but for different reasons. In the first case, it works because of the magic binary '+'. In the second case, it works because println is overloaded for all types, i.e. println(int); println(double); ... println(Object); // invokes println(o.toString()); println(String); // does the real work Regards, Martin (*) Implementations don't have to create those temporaries; the usual as-if rule applies. From guido@beopen.com Fri Jul 7 22:58:56 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:58:56 -0500 Subject: [Python-Dev] Encodings In-Reply-To: Your message of "Fri, 07 Jul 2000 22:24:03 +0200." <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> Message-ID: <200007072158.QAA05483@cj20424-a.reston1.va.home.com> > That is not my understanding of the agreement, and I think the whole > idea of a default encoding is a stupid one. I strongly suggest that > the behaviour that Ping just explained and that Guido had suggested > originally is implemented: Mixing unicode and string objects is only > allowed if the string objects are ASCII. Everything else (including a > "default" encoding of some kind) is an application issue. > > Otherwise, you'll just go on and ask questions endlessly how things > should behave, and change the interpreter forwards and backwards. > > The meaning of mixing both kinds of objects is very easy to explain, > and also allows for efficient implementation - which you won't get if > you have to invoke a character conversion just to get the hash value > of a unicode value (!) I agree with this point. It can be implemented easily by deleting the locale specific guessing from site.py. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein@lyra.org Fri Jul 7 22:05:39 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 14:05:39 -0700 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.17186.868952.214837@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Jul 07, 2000 at 04:52:50PM -0400 References: <20000707124449.E29590@lyra.org> <14694.17186.868952.214837@anthem.concentric.net> Message-ID: <20000707140539.N29590@lyra.org> On Fri, Jul 07, 2000 at 04:52:50PM -0400, Barry A. Warsaw wrote: > >>>>> "TP" == Tim Peters writes: > > >> I'll do a separate commit that just changes white space (and > >> possibly reflow some comments). > > TP> Bingo! > > TP> life-is-so-much-easier-when-you-don't-think-too-much-ly > TP> y'rs - tim > > Oh, and while you're at it, please untabify the file. I don't know if > your module has tabs in it, but if so please convert all tabs to > spaces. I haven't had tabs in my Python files for years :-) (C code is a different matter...) Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one@email.msn.com Fri Jul 7 22:01:09 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 17:01:09 -0400 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: Message-ID: [Tim] > It's certainly caught errors for me, and especially when > introducing Perl programmers to Python, where "they expect" > string+number to convert the string to a number, apparently > the opposite of the arbitrary choice Paul prefers. [Ping] > It's not arbitrary -- the decision is made according to the > type of the *operator* rather than the type of the operands. > > anything + anything returns a number > anything . anything returns a string Of the languages discussed, this is true only in Perl. The other languages map "+" to the string meaning, so it's arbitrary wrt the universe under discussion. Toss Icon into the Perl camp on this one, btw. Within Perl, that "+" means numeric addition and "." string catenation is also abitrary -- it could just as well have been the other way around. Perl simply aped Awk's arbitrary choice for what "+" means. > So "34"+0 converts to a number and 34."" converts to a string > (i've seen both idioms fairly often). Yes, & about as often as you see explicit str() or int() calls in Python. It's not a question of not needing the functionality, but of how to spell it (both!). > ... > there's really no excuse for not being explicit. i-think-that's-what-i-said-the-first-time-ly y'rs - tim From skip@mojam.com (Skip Montanaro) Fri Jul 7 22:07:15 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 7 Jul 2000 16:07:15 -0500 (CDT) Subject: [Python-Dev] repository locks In-Reply-To: <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> <3966317F.4A39E6A2@lemburg.com> <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> Message-ID: <14694.18051.422859.570782@beluga.mojam.com> >> Here's the patch (Skip's locking the Lib dir ... grrr ;-): Fredrik> What's causing all these stale locks? To the best of my knowledge there were two stale locks, both caused by me (*sigh*) as the result of a single failed cvs diff command. The SF folks released the lock on Modules but apparently failed badly to respond to two separate requests (from Barry and me) to release the lock on Lib. Here's what I think happened (I'm not going to test my theory on the Python tree lest I bollux up more directories!). I wanted to create a single context diff containing just the changes I had made to Modules/readline.c and Lib/rlcompleter.py. I changed directory to my Python top-level directory and executed cvs diff -C Modules/readline.c Lib/rlcompleter.py This failed, as did a couple other permutations I tried shortly after that. My theory is that "cvs diff" fiddles things a bit then calls the local diff command. Diff's -C flag is supposed to have a number as an argument (the number of context lines to display - I should have used "-c", which is the same as "-C2" I think). Diff exited with a nonzero status. Either rcsdiff or cvs diff failed to recover properly and we're left with a read lock on both Modules and Lib. On a repository here I just tried: cvs diff -C www/dbserve.py which gave me the following output: cvs diff: Diffing GNIS cvs diff: Diffing conferences cvs diff: Diffing www Index: www/Makefile =================================================================== RCS file: /home/dolphin/projects/www-python/Makefile,v retrieving revision 1.51 diff -Cwww/dbserve.py -r1.51 Makefile cvs diff: invalid context length argument Segmentation fault And it left the following file in my repository: -rw-rw-r-- 1 skip users 0 Jul 7 15:54 #cvs.rfl.dolphin.25030 When I try to check in a changed file to that repository I get: cvs server: [15:57:27] waiting for skip's lock in /home/dolphin/projects/www-python Delete the lock file and after a short pause I get: cvs server: [15:58:57] obtained lock in /home/dolphin/projects/www-python Checking in fsm.py; /home/dolphin/projects/www-python/fsm.py,v <-- fsm.py new revision: 1.4; previous revision: 1.3 done Cute, huh? So, this confirms what I suspected. There would appear to be a bug in cvs (I'm using 1.10.7). I will look and see if this is a reported bug and/or see if there is a newer version of cvs. Note that this doesn't let SourceForge off the hook. In theory, anyone with read access to any (or all?!?) CVS repositories at sourceforge.net could bring them to a screeching halt (at least for a bit) by performing the same trick on lots of repositories. my-fortune-cookie-quote-takes-on-new-meaning-ly y'rs, -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From bwarsaw@beopen.com Fri Jul 7 22:11:59 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 7 Jul 2000 17:11:59 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? References: <20000707124449.E29590@lyra.org> <14694.17186.868952.214837@anthem.concentric.net> <20000707140539.N29590@lyra.org> Message-ID: <14694.18335.738567.420313@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> I haven't had tabs in my Python files for years :-) Cool! GS> (C code is a different matter...) Yup. From fredrik@pythonware.com Fri Jul 7 22:26:42 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 23:26:42 +0200 Subject: [Python-Dev] what's dos-8x3/rfc822-n.py? Message-ID: <01a401bfe85a$0c1819f0$0900a8c0@SPIFF> more stupid questions: jeremy wrote: > rfc822-n.py > Log Message: > fix inconsistent use of tabs and spaces is that really a valid module name? shouldn't DOS users be able to use the standard rfc822 module? why are they different? (not sure, but the one in the dos-8x3 directory looks newer). (btw, why is there a Lib/dos-8x3 and a Lib/dos_8x3 directory in the repository?) From fredrik@pythonware.com Fri Jul 7 22:28:21 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 23:28:21 +0200 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <200007072158.QAA05483@cj20424-a.reston1.va.home.com> Message-ID: <01b501bfe85a$475f6cc0$0900a8c0@SPIFF> guido wrote: > > The meaning of mixing both kinds of objects is very easy to explain, > > and also allows for efficient implementation - which you won't get if > > you have to invoke a character conversion just to get the hash value > > of a unicode value (!) > > I agree with this point. It can be implemented easily by deleting the > locale specific guessing from site.py. as an aside, Jack reported that: if u" " in tuple(string.whitespace): ... bombs on the macintosh (this is from SRE). the reason? the default encoding is set to "ascii", but C's isspace predicate thinks that some characters in the 128-255 range are whitespace characters. tricky. PS. I'll post the Windows get_locale code tomorrow. hopefully, Jack can whip up something similar for the Mac. From guido@beopen.com Fri Jul 7 23:36:00 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 17:36:00 -0500 Subject: [Python-Dev] what's dos-8x3/rfc822-n.py? In-Reply-To: Your message of "Fri, 07 Jul 2000 23:26:42 +0200." <01a401bfe85a$0c1819f0$0900a8c0@SPIFF> References: <01a401bfe85a$0c1819f0$0900a8c0@SPIFF> Message-ID: <200007072236.RAA05766@cj20424-a.reston1.va.home.com> > more stupid questions: > > jeremy wrote: > > > rfc822-n.py > > Log Message: > > fix inconsistent use of tabs and spaces > > is that really a valid module name? No -- my mistake. I'll delete it. > shouldn't DOS users be able to use the standard rfc822 > module? why are they different? (not sure, but the > one in the dos-8x3 directory looks newer). That's a red herring. > (btw, why is there a Lib/dos-8x3 and a Lib/dos_8x3 > directory in the repository?) The dos_8x3 one was a mistake, but CVS won't let you really delete directories. Use "cvs update -P" to delete empty directories. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Fri Jul 7 22:31:13 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 7 Jul 2000 16:31:13 -0500 (CDT) Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: References: Message-ID: <14694.19489.449195.619187@beluga.mojam.com> Ping> So "34"+0 converts to a number and 34."" converts to a string Ping> (i've seen both idioms fairly often). Halleluhah! Never thought I'd get Perl programming help here! We have this nagging problem with our XML-RPC stuff. When a band or venue name consisting of all digits (like "311") name comes into our concert database server from a Perl client, it comes in as a number instead of a string. The only workaround so far was to check at all server interfaces where this might occur and call str() when we found a number. Now it looks like I can toss the problem back into the client and save a few cpu cycles on the server (and more to the point, not pay the cost of the test all the time)... Ka-Ping> Anyway, i still agree that it's best to avoid automatic Ka-Ping> coercion between numbers and strings Amen to that! Skip From guido@beopen.com Fri Jul 7 23:41:57 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 17:41:57 -0500 Subject: [Python-Dev] Python release delay Message-ID: <200007072241.RAA05873@cj20424-a.reston1.va.home.com> CNRI's Bob Kahn has this message for the Python user community: > "As a result of the recent transition of the Core Python development > activity from CNRI to BeOpen, a number of issues have arisen that CNRI and > BeOpen are in the process of working out. As soon as these are resolved, > which we hope will be very shortly, we plan to have the final version of > Python 1.6 available for download. We apologize for this delay, but > hopefully, it will not last long and will ultimately put the future python > evolution on a more solid foundation. In the meantime, BeOpen and CNRI will > also be working together on updates to the python.org website, and bug > reports, patches and other contributions to Python 1.6 should continue to > be submitted to CNRI following the procedures posted at the python.org site." --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas@xs4all.net Fri Jul 7 23:01:53 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 8 Jul 2000 00:01:53 +0200 Subject: [Python-Dev] Python release delay In-Reply-To: <200007072241.RAA05873@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 07, 2000 at 05:41:57PM -0500 References: <200007072241.RAA05873@cj20424-a.reston1.va.home.com> Message-ID: <20000708000153.J26534@xs4all.nl> On Fri, Jul 07, 2000 at 05:41:57PM -0500, Guido van Rossum wrote: > CNRI's Bob Kahn has this message for the Python user community: > > "As a result of the recent transition of the Core Python development > > activity from CNRI to BeOpen, a number of issues have arisen that CNRI and > > BeOpen are in the process of working out. As soon as these are resolved, > > which we hope will be very shortly, we plan to have the final version of > > Python 1.6 available for download. We apologize for this delay, but > > hopefully, it will not last long and will ultimately put the future python > > evolution on a more solid foundation. In the meantime, BeOpen and CNRI will > > also be working together on updates to the python.org website, and bug > > reports, patches and other contributions to Python 1.6 should continue to > > be submitted to CNRI following the procedures posted at the python.org site." Uuhmm... So... - The next version will be Python 1.6, not 2.0 - All patch submissions since PythonLabs started and everyone promptly forgot about the CNRI-required Disclaimer should be resubmitted with disclaimer (or perhaps disclaimer posted seperately) - This goes for all future versions of Python as well - CNRI, not Guido, BeOpen or PythonLabs , controls the future of Python, for everything from bugfixes to new features. When will we get your (Guido), PythonLabs' or BeOpen's official statement(s) on this ? :) Please-correct-me-if-I'm-wrong-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy@beopen.com Fri Jul 7 23:07:48 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 18:07:48 -0400 (EDT) Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: <14694.19489.449195.619187@beluga.mojam.com> References: <14694.19489.449195.619187@beluga.mojam.com> Message-ID: <14694.21684.395468.753641@bitdiddle.concentric.net> >>>>> "SM" == Skip Montanaro writes: Ping> So "34"+0 converts to a number and 34."" converts to a string Ping> (i've seen both idioms fairly often). SM> Halleluhah! Never thought I'd get Perl programming help here! Talk about a low signal-to-noise ratio! You get insights into a lot more than Python on python-dev. Jeremy From pingster@ilm.com Fri Jul 7 23:26:13 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Fri, 7 Jul 2000 15:26:13 -0700 (PDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000707103308.8074FE2673@oratrix.oratrix.nl> Message-ID: On Fri, 7 Jul 2000, Jack Jansen wrote: > I would suggest not putting it into urllib but in a "launch" module. [...] > in a separate module it's probably easier to extend to to various > other things you might want to launch (fileviewers, editors, etc). Hmm, i rather like this idea. Actually, i like it enough to suggest that "launch" would be a good interface to external applications -- launch.filebrowser("/home") launch.webbrowser("http://www.python.org/", newwindow=1) launch.mailreader() launch.mailcomposer("python-dev@python.org", subject="Spam") launch.textviewer("README") launch.texteditor("spam.py") launch.shell("/usr") launch.remoteshell("unseen.python.org", port=23) On Unix this would take advantage of (and formalize) the PAGER, EDITOR, BROWSER, etc. environment variables; on Windows they could look at registry settings, and for Mac, they could use IC. The webbrowser() function would be based on ESR's webbrowser.py; the others shouldn't be too hard to toss off... -- ?!ng From jeremy@beopen.com Fri Jul 7 23:31:40 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 18:31:40 -0400 (EDT) Subject: [Python-Dev] Python release delay In-Reply-To: <20000708000153.J26534@xs4all.nl> References: <200007072241.RAA05873@cj20424-a.reston1.va.home.com> <20000708000153.J26534@xs4all.nl> Message-ID: <14694.23116.916187.841812@bitdiddle.concentric.net> This isn't an official statement, but I hope it will clarify our plans and how they relate to CNRI's plans. CNRI plans to issue a 1.6 release. PythonLabs is still planning to issue a Python 2.0 release, almost surely following the 1.6 release. The current CVS repository contains what will be the 2.0 release. Please use the current mechanisms for contributing to our release -- the SF patch manager, the old Python bug database, etc. I'm not sure how you can contribute to Python 1.6, since CNRI is ultimately responsible for it. We will probably assist them, but I'm not sure how. You may want to inquire about the license that Python 1.6 will be released under. In the absence of a better place to direct inquires, you could try webmaster@python.org. This address will reach someone at CNRI, who can probably direct you to the right person. Jeremy From paul@prescod.net Sat Jul 8 00:04:20 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 07 Jul 2000 18:04:20 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <39661CAF.9252D734@prescod.net> <200007072102.QAA05114@cj20424-a.reston1.va.home.com> Message-ID: <396661F4.6541AB42@prescod.net> Guido van Rossum wrote: > > Really? Does 3+"" really convert the 3 to a string in Java? class foo{ void foo(){ System.err.println( 5+"" ); } } > > C++, depending on the type. Python's strictness > > about this issue has never caught a bug for me. It has only caused > > errors. > > Are you sure? This is the kind of error where you immediately see > what's wrong and move on to the next bug. I am sure that 99% of the time when I get an error message trying to add a string to something, it is because I expect the thing to be automatically coerced to the string. This probably comes from the other languages I have used. > > It's certainly caught errors for me, and especially when introducing Perl > programmers to Python, where "they expect" string+number to convert the > string to a number, apparently the opposite of the arbitrary choice Paul > prefers. > > It's ambiguous as hell -- screw it. I don't see the choice as arbitrary. Perl's choice is just insane. :) According to the definition used in Java, Javascript and C++ (sometimes) x+y If y is a string then x+y is well-defined no matter what the type of x or the content of y. Under the Perl definition, it totally depends on the type of y and the contents of x. Insane! I advocate special casing of strings (which are already special cased in various ways) whereas Perl special cases particular string values. Insane! -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From paul@prescod.net Sat Jul 8 00:24:13 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 07 Jul 2000 18:24:13 -0500 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> Message-ID: <3966669D.B436CD39@prescod.net> "Martin v. Loewis" wrote: > > > ... > >Only if the default encoding is ASCII. > > That is not my understanding of the agreement, and I think the whole > idea of a default encoding is a stupid one. Let me be more tactful and say that I am not really comfortable with my code changing behavior subtly because of an environment variable. A default encoding might be interesting at I/O boundaries like print, raw_input() and read(), but I would rather it didn't work pervasively through the code. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From paul@prescod.net Sat Jul 8 00:28:13 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 07 Jul 2000 18:28:13 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: Message-ID: <3966678D.677F199F@prescod.net> Ka-Ping Yee wrote: > > ... > > Anyway, i still agree that it's best to avoid automatic coercion > between numbers and strings -- since it's now very easy to say > int("3") as opposed to import string; string.atoi("3"), there's > really no excuse for not being explicit. I want to be clear that I'm not asking for automatic coercion between numbers and strings but rather automatic coercion of any type to string. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From thomas@xs4all.net Sat Jul 8 00:32:16 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 8 Jul 2000 01:32:16 +0200 Subject: [Python-Dev] [OffTopic] Re: Unicode experience In-Reply-To: <396661F4.6541AB42@prescod.net>; from paul@prescod.net on Fri, Jul 07, 2000 at 06:04:20PM -0500 References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <39661CAF.9252D734@prescod.net> <200007072102.QAA05114@cj20424-a.reston1.va.home.com> <396661F4.6541AB42@prescod.net> Message-ID: <20000708013216.M26534@xs4all.nl> On Fri, Jul 07, 2000 at 06:04:20PM -0500, Paul Prescod wrote: > According to the definition used in Java, Javascript and C++ (sometimes) > x+y > If y is a string then x+y is well-defined no matter what the type of x > or the content of y. The right hand side of the operation determines what the result is ? Somehow I find that confusing and counter-intuitive, but perhaps I'm too used to __add__ vs. __radd__ ;) Anyway, I've tried to learn C++ and Java both twice now, buying books by *good* authors (like Peter v/d Linden) and I still manage to run screaming after reading a single page of feature listings ;) > Under the Perl definition, it totally depends on the type of y and the > contents of x. Insane! Nono, absolutely not. Perl is weirdly-typed: the type is determined by the *operator*, not the operands. If you do '$x + $y', and both $x and $y are strings, they will both be converted to numbers (ending up 0 if it fails) and added as numbers, and the result is a number. (But since perl is weirdly-typed, if you need it to result in a string, the number will be converted to a string as necessary.) If you want string-concatenation, use '.', which will turn numbers into strings. But Perl wouldn't be Perl if it hadn't *some* exceptions to this kind of rule ;) '$x++', where $x is a string, can return a string. The 'string-auto-increment' operator is Magic(tm): if the string matches /^[a-zA-Z]*[0-9]*$/, that is, something like 'spam001', the ++ operator adds one to the number at the end of the string. so 'spam001' would become 'spam002'. If you do it to 'spam999', it'll be incremented to 'span000', 'spaz999' becomes 'spba000', and so on. However, Perl wouldn't be Perl if it hadn't some excpetion to *this* too ;) Well, not really an exception, but... The string *must* exactly match the regexp above, or the '++' operator will turn it into a number '1' instead. So your string cannot be '-spam01', or 'sp0m01', or anything like that. Rendering this magic behaviour pretty useless in general, because it's easier, more readable and less buggy to do the work the magic ++ does by hand. (We actually had some database 'corruption' in our old user-database because of this... a tool accepted a 'template' username and tried to create a specified number of accounts with a name in sequence to that template... The original code had a safeguard (the above regexp) but it got removed somehow, and eventually someone used a wrong template, and we ended up with accounts named '1' through '8' ;P) > I advocate special casing of strings (which are already special cased in > various ways) whereas Perl special cases particular string values. > Insane! Well, yes. But Perl special cases about everything and their dog. Not Good. (Okay, I promise to stay on-topic for a while now ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From DavidA@ActiveState.com Sat Jul 8 00:40:15 2000 From: DavidA@ActiveState.com (David Ascher) Date: Fri, 7 Jul 2000 16:40:15 -0700 (Pacific Daylight Time) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.17186.868952.214837@anthem.concentric.net> Message-ID: > >>>>> "TP" == Tim Peters writes: > > >> I'll do a separate commit that just changes white space (and > >> possibly reflow some comments). > > TP> Bingo! > > TP> life-is-so-much-easier-when-you-don't-think-too-much-ly > TP> y'rs - tim > > Oh, and while you're at it, please untabify the file. I don't know if > your module has tabs in it, but if so please convert all tabs to > spaces. IMO, with the right python-mode settings, all of us using emacs should never have to have this discussion! (going to have to do something about that in Komodo ! =). --david From fdrake@beopen.com Sat Jul 8 00:49:20 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 19:49:20 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: References: <14694.17186.868952.214837@anthem.concentric.net> Message-ID: <14694.27776.620365.621524@cj42289-a.reston1.va.home.com> David Ascher writes: > IMO, with the right python-mode settings, all of us using emacs should > never have to have this discussion! I people didn't screw up their settings we wouldn't! Barry: Perhaps the right solution is to hard-code python-mode to always set indent-tabs-mode to nil, the indentation to 4, and retabify when it loads a file? ;) Oh, and do it again when it saves, so nobody can screw up their modules. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Sat Jul 8 00:48:04 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 19:48:04 -0400 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: Message-ID: [David Ascher] > IMO, with the right python-mode settings, all of us using emacs should > never have to have this discussion! If Unix weenies would just *accept* the damned defaults, these discussions would never arise. You can tell a Unix user from across the room: they're the ones who attach leeches to their eyeballs and then complain about blurry vision . > (going to have to do something about that in Komodo ! =). Make it a Windows-only app. Windows users do whatever they're told, and then *pay* you, over & over, for punishing them . From pingster@ilm.com Sat Jul 8 00:59:16 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Fri, 7 Jul 2000 16:59:16 -0700 (PDT) Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: <3966678D.677F199F@prescod.net> Message-ID: On Fri, 7 Jul 2000, Paul Prescod wrote: > > I want to be clear that I'm not asking for automatic coercion between > numbers and strings but rather automatic coercion of any type to string. As it stands, with both 8-bit strings and Unicode strings, i think this would result in too much hidden complexity -- thinking about this can wait until we have only one string type. We could consider this after we unify strings, but even then it would take some arguing to convince me that automatic coercion is desirable. -- ?!ng From gstein@lyra.org Sat Jul 8 02:32:13 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 18:32:13 -0700 Subject: [Python-Dev] Encodings In-Reply-To: <3966669D.B436CD39@prescod.net>; from paul@prescod.net on Fri, Jul 07, 2000 at 06:24:13PM -0500 References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> Message-ID: <20000707183213.P29590@lyra.org> On Fri, Jul 07, 2000 at 06:24:13PM -0500, Paul Prescod wrote: > "Martin v. Loewis" wrote: > > > > > ... > > >Only if the default encoding is ASCII. > > > > That is not my understanding of the agreement, and I think the whole > > idea of a default encoding is a stupid one. > > Let me be more tactful and say that I am not really comfortable with my > code changing behavior subtly because of an environment variable. A > default encoding might be interesting at I/O boundaries like print, > raw_input() and read(), but I would rather it didn't work pervasively > through the code. Agreed. When this whole thing started, I thought there was going to be a fixed default encoding. Then the "changeable default" snuck into the code under the guise of "experimental work". Now that changeable default seems ingrained into the code and is introducing exactly the problems that we feared last fall -- unpredictability. Please... toss the changeable default. If everybody knows the default encoding is "ascii" and they want something else, then they know what to do. But when the default can change, then it can't be relied on. The coder is going to have to do an explicit encoding anyways. So why have a default? Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake@beopen.com Sat Jul 8 05:11:45 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 00:11:45 -0400 (EDT) Subject: [Python-Dev] HAVE_OLD_CPP and the token-pasting operator Message-ID: <14694.43521.924155.15736@cj42289-a.reston1.va.home.com> operator.c includes a couple of macros that are defined to either use the ANSI token-pasting operator (##) or the old /**/ trick. Since I know macros in other source files are just using the token-pasting operator, and I've not heard anyone scream, should I just remove the old style macros since we're requiring ANSI C now? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Sat Jul 8 05:31:27 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 00:31:27 -0400 Subject: [Python-Dev] Include/pyport.h now exists Message-ID: Checkin comment below. Would someone who understands (& can test! I can't yet) autoconfig please follow up on the last part? The stuff I checked in "fails safe", i.e. the lack of autoconfig support should not cause problems on any of your platforms. figured-it-was-best-to-just-do-it-and-apologize-later-ly y'rs - tim Cray J90 fixes for long ints. This was a convenient excuse to create the pyport.h file recently discussed! Please use new Py_ARITHMETIC_RIGHT_SHIFT when right-shifting signed int and you *need* sign-extension. This is #define'd in pyport.h, keying off new config symbol SIGNED_RIGHT_SHIFT_ZERO_FILLS. If you're running on a platform that needs that symbol #define'd, the std tests never would have worked for you (in particular, at least test_long would have failed). The autoconfig stuff got added to Python after my Unix days, so I don't know how that works. Would someone please look into doing & testing an auto-config of the SIGNED_RIGHT_SHIFT_ZERO_FILLS symbol? It needs to be defined if & only if, e.g., (-1) >> 3 is not -1. From tim_one@email.msn.com Sat Jul 8 05:33:42 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 00:33:42 -0400 Subject: [Python-Dev] HAVE_OLD_CPP and the token-pasting operator In-Reply-To: <14694.43521.924155.15736@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > operator.c includes a couple of macros that are defined to either > use the ANSI token-pasting operator (##) or the old /**/ trick. Since > I know macros in other source files are just using the token-pasting > operator, and I've not heard anyone scream, should I just remove the > old style macros since we're requiring ANSI C now? Yes! We should at least pretend we're living in the 1900's by now . From tim_one@email.msn.com Sat Jul 8 08:01:37 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 03:01:37 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <200007062157.QAA01227@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > ... (Is a summary of these [C9X] names online somewhere?) ISO refuses to put current stds online, so I'll reword an anonymous source (shhh! & some of this may be a little out of date): Exact-width typedefs: int8_t int16_t int32_t int64_t uint8_t uint16_t uint32_t uint64_t It's allowed that a given platform not define *any* of these. Therefore portable code can never rely on having exactly N bits regardless of N. Minimum-width typedefs: int_least8_t int_least16_t int_least32_t int_least64_t uint_least8_t uint_least16_t uint_least32_t uint_least64_t *All* of these must be defined (so even teensy platforms have to fake at least 64 bits). Fastest minimum-width typedefs: int_fast8_t int_fast16_t int_fast32_t int_fast64_t uint_fast8_t uint_fast16_t uint_fast32_t uint_fast64_t All of these must exist. What's the difference between these and minimum-width? For example, on a Cray J90 the least8_t will be a char, but since the HW supports no byte operations, the fast8_t will likely be 64 bits wide. Pointer<->int casting intptr_t uintptr_t These are signed & unsigned int types such that a valid void* p can be cast to them and back again, yielding a result == p. Very curiously, the last draft std I saw allowed for neither to be defined! Fattest types intmax_t uintmax_t The biggest int type (note that this may be fatter than "long long"!). Must be defined. Limit macros The names of these match the regexp (re.VERBOSE): U? INT (8|16|32|64) _ (MIN|MAX) | U? INT_ (LEAST|FAST) (8|16|32|64) _ (MIN|MAX) | INTPTR_ (MIN|MAX) | UINTPTR_MAX | INTMAX_ (MIN|MAX) | UINTMAX_MAX Macros for literals The names match the regexp: U? INT (8|16|32|64) _C Each of these 8 macros takes an integer literal argument, and expands it to whatever gibberish the platform needs to make a valid literal of at least the specified width. Also INTMAX_C(lit) and UINTMAX_C(lit), to do likewise for the fattest type (intmax_t or uintmax_t) supported by the platform. Macros for format specifiers There are many dozens of these! They address the problem that it's great you can now ask for, e.g., an int_fast32_t, but you still have no idea how big it is so also no idea what to stick in printf or scanf formats to do correct I/O on values of that type. Other limits ptrdiff_t: PTRDIFF_MIN PTRDIFF_MAX sig_atomic_t: SIG_ATOMIC_MIN SIG_ATOMIC_MAX size_t: SIZE_MAX wchar_t: WCHAR_MIN WCHAR_MAX wint_t: WINT_MIN WINT_MAX I don't expect Python needs more than half a dozen of these, but haven't given it sufficient thought. If somebody else beats me to it, I would be pleased . the-very-need-for-names-like-intmax_max-is-a-strong-argument- for-euthanasia-ly y'rs - tim From tim_one@email.msn.com Sat Jul 8 08:09:36 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 03:09:36 -0400 Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: <20000708064203.D7FBC1CD45@dinsdale.python.org> Message-ID: [various patches from Fred Drake, w/ the comment > ANSI-fied sources, converted to four-space indentation. ] Fred, you appear to be 4-space indenting C source. Is that allowed? Last I think I heard, Guido was still clinging to his schizophrenia on this topic (4-space for .py and no hard tabs, 8-space for .c/.h and hard tabs). god-knows-i'd-like-'em-to-be-the-same-ly y'rs - tim From Moshe Zadka Sat Jul 8 09:07:30 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 8 Jul 2000 11:07:30 +0300 (IDT) Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: Message-ID: On Sat, 8 Jul 2000, Tim Peters wrote: > [various patches from Fred Drake, w/ the comment > > ANSI-fied sources, converted to four-space indentation. > ] > > Fred, you appear to be 4-space indenting C source. Is that allowed? Last I > think I heard, Guido was still clinging to his schizophrenia on this topic > (4-space for .py and no hard tabs, 8-space for .c/.h and hard tabs). I have never seen a formal statement from Guido about it, but I always assumed Python's C sources are linux kernel style...No? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From thomas@xs4all.net Sat Jul 8 09:28:47 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 8 Jul 2000 10:28:47 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules linuxaudiodev.c,2.2,2.3 In-Reply-To: <200007080606.XAA22987@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Fri, Jul 07, 2000 at 11:06:01PM -0700 References: <200007080606.XAA22987@slayer.i.sourceforge.net> Message-ID: <20000708102847.N26534@xs4all.nl> On Fri, Jul 07, 2000 at 11:06:01PM -0700, Fred L. Drake wrote: > Modified Files: > linuxaudiodev.c > Log Message: > Add method names to PyArg_ParseTuple() calls for better error messages. > Convert to four-space indents. Aren't tabs preferred as C-source indents, instead of 4-spaces ? At least, that's what I see in Python/*.c and Object/*.c, but I only vaguely recall it from the style document... -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From ping@lfw.org Sat Jul 8 10:35:05 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Sat, 8 Jul 2000 02:35:05 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <200007070034.CAA02914@python.inrialpes.fr> Message-ID: On Fri, 7 Jul 2000, Vladimir Marangozov wrote: > Okay. Since you've already altered the error list in errcode.h, > I think that the best thing to do is to re-introduce E_INDENT > but for the "missing indentation" case (reported to the user as > "expected an indented block"), then return E_INDENT from AddToken() > and revert back its signature. Thus all additional error cases you've > detected so far would be handled fine in pythonrun.c. I think i'd rather leave the patch as it is. I can see that what you're suggesting would eliminate the need for the expected_ret argument to PyParser_AddToken(), but i think there's more value in exposing the expected token to pythonrun -- it leaves open the possibility for further more detailed and helpful messages in the future, without having to create separate error codes for each. It seems right that these situations should fall under the E_SYNTAX error code (otherwise we'd have to say that E_SYNTAX means "syntax error except for missing-indentation errors" etc.). E_SYNTAX is the general error code for "we got a token but the parser wouldn't accept it". (E_TABSPACE, E_TOODEEP, and E_DEDENT are errors at the token level.) And i don't see a lot of motivation to *avoid* passing back the expected token. There isn't anyone else depending on the interface to PyParser_AddToken (parser.h is a private header file). Hmm. Is that sufficiently convincing? -- ?!ng "To be human is to continually change. Your desire to remain as you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From Vladimir.Marangozov@inrialpes.fr Sat Jul 8 10:43:41 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sat, 8 Jul 2000 11:43:41 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Ka-Ping Yee" at Jul 08, 2000 02:35:05 AM Message-ID: <200007080943.LAA09790@python.inrialpes.fr> Ka-Ping Yee wrote: > > And i don't see a lot of motivation to *avoid* passing back the > expected token. There isn't anyone else depending on the interface > to PyParser_AddToken (parser.h is a private header file). > > Hmm. Is that sufficiently convincing? Yes. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein@lyra.org Sat Jul 8 10:55:07 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 8 Jul 2000 02:55:07 -0700 Subject: [Python-Dev] CVS: python/dist/src/Include pyport.h,NONE,2.1 Python.h,2.21,2.22 longintrepr.h,2.8,2.9 In-Reply-To: <200007080417.VAA05755@slayer.i.sourceforge.net>; from tim_one@users.sourceforge.net on Fri, Jul 07, 2000 at 09:17:24PM -0700 References: <200007080417.VAA05755@slayer.i.sourceforge.net> Message-ID: <20000708025506.A29590@lyra.org> On Fri, Jul 07, 2000 at 09:17:24PM -0700, Tim Peters wrote: >... > #ifndef Py_PYPORT_H > #define Py_PYPORT_H 1 > > /************************************************************************** > Symbols and macros to supply platform-independent interfaces to basic > C-language operations whose spellings vary across platforms. > > Please try to make documentation here as clear as possible: by definition, > the stuff here is trying to illuminate C's darkest corners. > > Config #defines referenced here: > > SIGNED_RIGHT_SHIFT_ZERO_FILLS > Meaning: To be defined iff i>>j does not extend the sign bit when i is a > signed integral type and i < 0. > Used in: Py_ARITHMETIC_RIGHT_SHIFT > **************************************************************************/ Note that it would be nice for pyport.h to *also* contain all the Include/my* stuff. i.e. it isn't just about C-language operations, but also about the (un)available libraries. IOW, stop the propagation of my* and drop those tweaky things into pyport. Cheers, -g -- Greg Stein, http://www.lyra.org/ From skip@mojam.com (Skip Montanaro) Sat Jul 8 11:32:40 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sat, 8 Jul 2000 05:32:40 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> References: <14691.49563.78765.683762@beluga.mojam.com> <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> Message-ID: <14695.840.448508.397722@beluga.mojam.com> --w4MOZK6GnZ Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Regarding list comprehensions I recently proposed this as a possible option: >> * bundle up another patch for people to examine and comment on to which Fredrik replied /F> I'd vote for [that] Since Fredrik's voice is the only one I heard, and on the off-chance that the CNRI/BeOpen discussions and resulting 1.6 release push things out a bit (allowing a feature thaw) I'll oblige. The attached patch to add list comprehensions affects the following files: Doc/ref/ref5.tex Doc/tut/tut.tex Grammar/Grammar Include/graminit.h Lib/test/test_grammar.py Lib/test/output/test_grammar Python/compile.c Python/graminit.c About half the patch is the change to the (generated) graminit.c. The rest is actually fairly simple. i-really-hate-seeing-those-M's-when-i-cvs-update-ly y'rs, Skip --w4MOZK6GnZ Content-Type: text/plain Content-Description: list comprehensions patch for Python Content-Disposition: inline; filename="listcomp.patch" Content-Transfer-Encoding: 7bit Index: Doc/ref/ref5.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/ref/ref5.tex,v retrieving revision 1.29 diff -c -r1.29 ref5.tex *** Doc/ref/ref5.tex 2000/04/25 21:09:10 1.29 --- Doc/ref/ref5.tex 2000/07/08 11:55:44 *************** *** 152,164 **** square brackets: \begin{verbatim} ! list_display: "[" [expression_list] "]" \end{verbatim} A list display yields a new list object. If it has no expression list, the list object has no items. Otherwise, the elements of the expression list are evaluated from left to right and inserted in the ! list object in that order. \obindex{list} \indexii{empty}{list} --- 152,169 ---- square brackets: \begin{verbatim} ! list_display: "[" [expression_list [list_iter]] "]" ! list_iter: list_for | list_if ! list_for: "for" expression_list "in" testlist [list_iter] ! list_if: "if" test [list_iter] \end{verbatim} A list display yields a new list object. If it has no expression list, the list object has no items. Otherwise, the elements of the expression list are evaluated from left to right and inserted in the ! list object in that order. List comprehensions define conditional ! expressions used to define lists. ! \obindex{list} \indexii{empty}{list} Index: Doc/tut/tut.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/tut/tut.tex,v retrieving revision 1.109 diff -c -r1.109 tut.tex *** Doc/tut/tut.tex 2000/07/08 05:18:54 1.109 --- Doc/tut/tut.tex 2000/07/08 11:55:45 *************** *** 1753,1758 **** --- 1753,1779 ---- 0 \end{verbatim} + \subsection{List Comprehensions} + + List comprehensions provide a concise way to create lists without resorting + to use of the \func{map()} or \func{filter()} functions. The resulting + construct tends often to be clearer than use of those functions. + + \begin{verbatim} + >>> spcs = [" Apple", " Banana ", "Coco nut "] + >>> print [s.strip() for s in spcs] + ['Apple', 'Banana', 'Coco nut'] + >>> vec = [2, 4, 6] + >>> print [3*x for x in vec] + [6, 12, 18] + >>> vec1 = [2, 4, 6] + >>> vec2 = [4, 3, -9] + >>> print [x*y for x in vec1 for y in vec2] + [8, 6, -18, 16, 12, -36, 24, 18, -54] + >>> print [x+y for x in vec1 for y in vec2] + [6, 5, -7, 8, 7, -5, 10, 9, -3] + \end{verbatim} + \section{The \keyword{del} statement \label{del}} There is a way to remove an item from a list given its index instead Index: Grammar/Grammar =================================================================== RCS file: /cvsroot/python/python/dist/src/Grammar/Grammar,v retrieving revision 1.35 diff -c -r1.35 Grammar *** Grammar/Grammar 2000/03/28 23:49:00 1.35 --- Grammar/Grammar 2000/07/08 11:55:45 *************** *** 74,80 **** term: factor (('*'|'/'|'%') factor)* factor: ('+'|'-'|'~') factor | power power: atom trailer* ('**' factor)* ! atom: '(' [testlist] ')' | '[' [testlist] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ lambdef: 'lambda' [varargslist] ':' test trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME subscriptlist: subscript (',' subscript)* [','] --- 74,80 ---- term: factor (('*'|'/'|'%') factor)* factor: ('+'|'-'|'~') factor | power power: atom trailer* ('**' factor)* ! atom: '(' [testlist] ')' | '[' [testlist [list_iter]] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ lambdef: 'lambda' [varargslist] ':' test trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME subscriptlist: subscript (',' subscript)* [','] *************** *** 88,90 **** --- 88,96 ---- arglist: (argument ',')* (argument [',']| '*' test [',' '**' test] | '**' test) argument: [test '='] test # Really [keyword '='] test + + # + list_iter: list_for | list_if + list_for: 'for' exprlist 'in' testlist [list_iter] + list_if: 'if' test [list_iter] + # Index: Include/graminit.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Include/graminit.h,v retrieving revision 2.13 diff -c -r2.13 graminit.h *** Include/graminit.h 1997/04/02 05:23:10 2.13 --- Include/graminit.h 2000/07/08 11:55:45 *************** *** 55,57 **** --- 55,60 ---- #define classdef 310 #define arglist 311 #define argument 312 + #define list_iter 313 + #define list_for 314 + #define list_if 315 Index: Lib/test/test_grammar.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_grammar.py,v retrieving revision 1.13 diff -c -r1.13 test_grammar.py *** Lib/test/test_grammar.py 2000/03/28 23:51:13 1.13 --- Lib/test/test_grammar.py 2000/07/08 11:55:45 *************** *** 542,544 **** --- 542,579 ---- def meth1(self): pass def meth2(self, arg): pass def meth3(self, a1, a2): pass + + ### list comprehensions... + nums = [1, 2, 3, 4, 5] + strs = ["Apple", "Banana", "Coconut"] + spcs = [" Apple", " Banana ", "Coco nut "] + + print [s.strip() for s in spcs] + print [3 * x for x in nums] + print [x for x in nums if x > 2] + print [i, s for i in nums for s in strs] + print [i, s for i in nums for s in [f for f in strs if "n" in f]] + + suppliers = [ + (1, "Boeing"), + (2, "Ford"), + (3, "Macdonalds") + ] + + parts = [ + (10, "Airliner"), + (20, "Engine"), + (30, "Cheeseburger") + ] + + suppart = [ + (1, 10), (1, 20), (2, 20), (3, 30) + ] + + print [ + (sname, pname) + for (sno, sname) in suppliers + for (pno, pname) in parts + for (sp_sno, sp_pno) in suppart + if sno == sp_sno and pno == sp_pno + ] Index: Lib/test/output/test_grammar =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_grammar,v retrieving revision 1.3 diff -c -r1.3 test_grammar *** Lib/test/output/test_grammar 2000/03/28 23:53:22 1.3 --- Lib/test/output/test_grammar 2000/07/08 11:55:45 *************** *** 45,47 **** --- 45,53 ---- atoms classdef + ['Apple', 'Banana', 'Coco nut'] + [3, 6, 9, 12, 15] + [3, 4, 5] + [(1, 'Apple'), (1, 'Banana'), (1, 'Coconut'), (2, 'Apple'), (2, 'Banana'), (2, 'Coconut'), (3, 'Apple'), (3, 'Banana'), (3, 'Coconut'), (4, 'Apple'), (4, 'Banana'), (4, 'Coconut'), (5, 'Apple'), (5, 'Banana'), (5, 'Coconut')] + [(1, 'Banana'), (1, 'Coconut'), (2, 'Banana'), (2, 'Coconut'), (3, 'Banana'), (3, 'Coconut'), (4, 'Banana'), (4, 'Coconut'), (5, 'Banana'), (5, 'Coconut')] + [('Boeing', 'Airliner'), ('Boeing', 'Engine'), ('Ford', 'Engine'), ('Macdonalds', 'Cheeseburger')] Index: Python/compile.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v retrieving revision 2.113 diff -c -r2.113 compile.c *** Python/compile.c 2000/07/03 21:39:47 2.113 --- Python/compile.c 2000/07/08 11:55:45 *************** *** 311,316 **** --- 311,317 ---- #ifdef PRIVATE_NAME_MANGLING char *c_private; /* for private name mangling */ #endif + int c_tmpname; /* temp local name counter */ /*LISTCOMP*/ }; *************** *** 394,399 **** --- 395,410 ---- static void com_list Py_PROTO((struct compiling *, node *, int)); static int com_argdefs Py_PROTO((struct compiling *, node *)); static int com_newlocal Py_PROTO((struct compiling *, char *)); + /**/ + static void com_list_for Py_PROTO((struct compiling *, + node *, node *, char *)); + static void com_list_if Py_PROTO((struct compiling *, + node *, node *, char *)); + static void com_list_iter Py_PROTO((struct compiling *, + node *, int, node *, char *)); + static void com_list_comprehension Py_PROTO((struct compiling *, node *)); + static void com_assign Py_PROTO((struct compiling *, node *, int)); + /**/ static PyCodeObject *icompile Py_PROTO((struct _node *, struct compiling *)); static PyCodeObject *jcompile Py_PROTO((struct _node *, char *, struct compiling *)); *************** *** 445,450 **** --- 456,462 ---- c->c_last_addr = 0; c->c_last_line = 0; c-> c_lnotab_next = 0; + c->c_tmpname = 0; return 1; fail: *************** *** 1011,1016 **** --- 1023,1143 ---- return NULL; } + /**/ + + static void + com_list_for(c, n, e, t) + struct compiling *c; + node *n, *e; + char *t; + { + PyObject *v; + int anchor = 0; + int save_begin = c->c_begin; + + /*com_addfwref(c, SETUP_LOOP, &break_anchor);*/ + /*block_push(c, SETUP_LOOP);*/ + /* list_iter: for v in expr [list_iter] */ + com_node(c, CHILD(n, 3)); /* expr */ + v = PyInt_FromLong(0L); + if (v == NULL) + c->c_errors++; + com_addoparg(c, LOAD_CONST, com_addconst(c, v)); + com_push(c, 1); + Py_XDECREF(v); + c->c_begin = c->c_nexti; + com_addoparg(c, SET_LINENO, n->n_lineno); + com_addfwref(c, FOR_LOOP, &anchor); + com_push(c, 1); + com_assign(c, CHILD(n, 1), OP_ASSIGN); + c->c_loops++; + com_list_iter(c, n, 4, e, t); + c->c_loops--; + com_addoparg(c, JUMP_ABSOLUTE, c->c_begin); + c->c_begin = save_begin; + com_backpatch(c, anchor); + com_pop(c, 2); /* FOR_LOOP has popped these */ + /*com_addbyte(c, POP_BLOCK);*/ + /*block_pop(c, SETUP_LOOP);*/ + /*com_backpatch(c, break_anchor);*/ + } + + static void + com_list_if(c, n, e, t) + struct compiling *c; + node *n, *e; + char *t; + { + int anchor = 0; + int a = 0; + /* list_iter: 'if' test [list_iter] */ + com_addoparg(c, SET_LINENO, n->n_lineno); + com_node(c, CHILD(n, 1)); + com_addfwref(c, JUMP_IF_FALSE, &a); + com_addbyte(c, POP_TOP); + com_pop(c, 1); + com_list_iter(c, n, 2, e, t); + com_addfwref(c, JUMP_FORWARD, &anchor); + com_backpatch(c, a); + /* We jump here with an extra entry which we now pop */ + com_addbyte(c, POP_TOP); + com_backpatch(c, anchor); + } + + static void + com_list_iter(c, p, i, e, t) + struct compiling *c; + node *p; /* parent of list_iter node */ + int i; /* child no. in p of list_iter node */ + node *e; /* element expression */ + char *t; /* name of result list temp local */ + { + if (i < NCH(p)) { + node *n = CHILD(p, i); + n = CHILD(n, 0); + switch (TYPE(n)) { + case list_for: + com_list_for(c, n, e, t); + break; + case list_if: + com_list_if(c, n, e, t); + break; + default: + com_error(c, PyExc_SystemError, "invalid list_iter node type"); + } + } + else { + com_addopnamestr(c, LOAD_NAME, t); + com_push(c, 1); + com_addopnamestr(c, LOAD_ATTR, "append"); + com_node(c, e); + com_addoparg(c, CALL_FUNCTION, 1); + com_addbyte(c, POP_TOP); + com_pop(c, 2); + } + } + + static void + com_list_comprehension(c, n) + struct compiling *c; + node *n; + { + /* atom: '[' test list_iter ']' */ + char tmpname[8]; + sprintf(tmpname, "%d", ++c->c_tmpname); + com_addoparg(c, BUILD_LIST, 0); + com_push(c, 1); + com_addopnamestr(c, STORE_NAME, tmpname); + com_pop(c, 1); + com_list_iter(c, n, 2, CHILD(n, 1), tmpname); + com_addopnamestr(c, LOAD_NAME, tmpname); + com_push(c, 1); + com_addopnamestr(c, DELETE_NAME, tmpname); + --c->c_tmpname; + } + + /**/ + static void com_list_constructor(c, n) struct compiling *c; *************** *** 1023,1029 **** /* exprlist: expr (',' expr)* [',']; likewise for testlist */ len = (NCH(n) + 1) / 2; for (i = 0; i < NCH(n); i += 2) ! com_node(c, CHILD(n, i)); com_addoparg(c, BUILD_LIST, len); com_pop(c, len-1); } --- 1150,1156 ---- /* exprlist: expr (',' expr)* [',']; likewise for testlist */ len = (NCH(n) + 1) / 2; for (i = 0; i < NCH(n); i += 2) ! com_node(c, CHILD(n, i)); com_addoparg(c, BUILD_LIST, len); com_pop(c, len-1); } *************** *** 1072,1079 **** com_addoparg(c, BUILD_LIST, 0); com_push(c, 1); } ! else com_list_constructor(c, CHILD(n, 1)); break; case LBRACE: /* '{' [dictmaker] '}' */ com_addoparg(c, BUILD_MAP, 0); --- 1199,1208 ---- com_addoparg(c, BUILD_LIST, 0); com_push(c, 1); } ! else if (TYPE(CHILD(n, 2)) == RSQB) /*LISTCOMP*/ com_list_constructor(c, CHILD(n, 1)); + else /*LISTCOMP*/ + com_list_comprehension(c, n); /*LISTCOMP*/ break; case LBRACE: /* '{' [dictmaker] '}' */ com_addoparg(c, BUILD_MAP, 0); Index: Python/graminit.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/graminit.c,v retrieving revision 2.23 diff -c -r2.23 graminit.c *** Python/graminit.c 2000/03/28 23:49:17 2.23 --- Python/graminit.c 2000/07/08 11:55:45 *************** *** 896,906 **** static arc arcs_45_0[7] = { {16, 1}, {109, 2}, ! {111, 3}, ! {114, 4}, {12, 5}, ! {115, 5}, ! {116, 6}, }; static arc arcs_45_1[2] = { {9, 7}, --- 896,906 ---- static arc arcs_45_0[7] = { {16, 1}, {109, 2}, ! {112, 3}, ! {115, 4}, {12, 5}, ! {116, 5}, ! {117, 6}, }; static arc arcs_45_1[2] = { {9, 7}, *************** *** 908,918 **** }; static arc arcs_45_2[2] = { {9, 8}, ! {110, 5}, }; static arc arcs_45_3[2] = { ! {112, 9}, ! {113, 5}, }; static arc arcs_45_4[1] = { {9, 10}, --- 908,918 ---- }; static arc arcs_45_2[2] = { {9, 8}, ! {111, 5}, }; static arc arcs_45_3[2] = { ! {113, 9}, ! {114, 5}, }; static arc arcs_45_4[1] = { {9, 10}, *************** *** 921,942 **** {0, 5}, }; static arc arcs_45_6[2] = { ! {116, 6}, {0, 6}, }; static arc arcs_45_7[1] = { {18, 5}, }; ! static arc arcs_45_8[1] = { ! {110, 5}, }; static arc arcs_45_9[1] = { ! {113, 5}, }; static arc arcs_45_10[1] = { ! {114, 5}, }; ! static state states_45[11] = { {7, arcs_45_0}, {2, arcs_45_1}, {2, arcs_45_2}, --- 921,946 ---- {0, 5}, }; static arc arcs_45_6[2] = { ! {117, 6}, {0, 6}, }; static arc arcs_45_7[1] = { {18, 5}, }; ! static arc arcs_45_8[2] = { ! {110, 11}, ! {111, 5}, }; static arc arcs_45_9[1] = { ! {114, 5}, }; static arc arcs_45_10[1] = { ! {115, 5}, }; ! static arc arcs_45_11[1] = { ! {111, 5}, ! }; ! static state states_45[12] = { {7, arcs_45_0}, {2, arcs_45_1}, {2, arcs_45_2}, *************** *** 945,956 **** {1, arcs_45_5}, {2, arcs_45_6}, {1, arcs_45_7}, ! {1, arcs_45_8}, {1, arcs_45_9}, {1, arcs_45_10}, }; static arc arcs_46_0[1] = { ! {117, 1}, }; static arc arcs_46_1[2] = { {17, 2}, --- 949,961 ---- {1, arcs_45_5}, {2, arcs_45_6}, {1, arcs_45_7}, ! {2, arcs_45_8}, {1, arcs_45_9}, {1, arcs_45_10}, + {1, arcs_45_11}, }; static arc arcs_46_0[1] = { ! {118, 1}, }; static arc arcs_46_1[2] = { {17, 2}, *************** *** 978,988 **** {52, 3}, }; static arc arcs_47_1[2] = { ! {118, 4}, {18, 5}, }; static arc arcs_47_2[1] = { ! {119, 6}, }; static arc arcs_47_3[1] = { {12, 5}, --- 983,993 ---- {52, 3}, }; static arc arcs_47_1[2] = { ! {119, 4}, {18, 5}, }; static arc arcs_47_2[1] = { ! {120, 6}, }; static arc arcs_47_3[1] = { {12, 5}, *************** *** 994,1000 **** {0, 5}, }; static arc arcs_47_6[1] = { ! {110, 5}, }; static state states_47[7] = { {3, arcs_47_0}, --- 999,1005 ---- {0, 5}, }; static arc arcs_47_6[1] = { ! {111, 5}, }; static state states_47[7] = { {3, arcs_47_0}, *************** *** 1006,1019 **** {1, arcs_47_6}, }; static arc arcs_48_0[1] = { ! {120, 1}, }; static arc arcs_48_1[2] = { {22, 2}, {0, 1}, }; static arc arcs_48_2[2] = { ! {120, 1}, {0, 2}, }; static state states_48[3] = { --- 1011,1024 ---- {1, arcs_47_6}, }; static arc arcs_48_0[1] = { ! {121, 1}, }; static arc arcs_48_1[2] = { {22, 2}, {0, 1}, }; static arc arcs_48_2[2] = { ! {121, 1}, {0, 2}, }; static state states_48[3] = { *************** *** 1035,1048 **** }; static arc arcs_49_3[3] = { {21, 5}, ! {121, 6}, {0, 3}, }; static arc arcs_49_4[1] = { {52, 6}, }; static arc arcs_49_5[2] = { ! {121, 6}, {0, 5}, }; static arc arcs_49_6[1] = { --- 1040,1053 ---- }; static arc arcs_49_3[3] = { {21, 5}, ! {122, 6}, {0, 3}, }; static arc arcs_49_4[1] = { {52, 6}, }; static arc arcs_49_5[2] = { ! {122, 6}, {0, 5}, }; static arc arcs_49_6[1] = { *************** *** 1129,1135 **** {2, arcs_53_4}, }; static arc arcs_54_0[1] = { ! {122, 1}, }; static arc arcs_54_1[1] = { {12, 2}, --- 1134,1140 ---- {2, arcs_53_4}, }; static arc arcs_54_0[1] = { ! {123, 1}, }; static arc arcs_54_1[1] = { {12, 2}, *************** *** 1164,1170 **** {1, arcs_54_7}, }; static arc arcs_55_0[3] = { ! {123, 1}, {23, 2}, {24, 3}, }; --- 1169,1175 ---- {1, arcs_54_7}, }; static arc arcs_55_0[3] = { ! {124, 1}, {23, 2}, {24, 3}, }; *************** *** 1179,1185 **** {21, 6}, }; static arc arcs_55_4[4] = { ! {123, 1}, {23, 2}, {24, 3}, {0, 4}, --- 1184,1190 ---- {21, 6}, }; static arc arcs_55_4[4] = { ! {124, 1}, {23, 2}, {24, 3}, {0, 4}, *************** *** 1222,1235 **** {2, arcs_56_1}, {1, arcs_56_2}, {1, arcs_56_3}, }; ! static dfa dfas[57] = { {256, "single_input", 0, 3, states_0, ! "\004\030\001\000\140\341\153\202\034\200\000\000\060\242\074\004"}, {257, "file_input", 0, 2, states_1, ! "\204\030\001\000\140\341\153\202\034\200\000\000\060\242\074\004"}, {258, "eval_input", 0, 3, states_2, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\242\074\000"}, {259, "funcdef", 0, 6, states_3, "\000\010\000\000\000\000\000\000\000\000\000\000\000\000\000\000"}, {260, "parameters", 0, 4, states_4, --- 1227,1297 ---- {2, arcs_56_1}, {1, arcs_56_2}, {1, arcs_56_3}, + }; + static arc arcs_57_0[2] = { + {125, 1}, + {126, 1}, + }; + static arc arcs_57_1[1] = { + {0, 1}, + }; + static state states_57[2] = { + {2, arcs_57_0}, + {1, arcs_57_1}, + }; + static arc arcs_58_0[1] = { + {67, 1}, + }; + static arc arcs_58_1[1] = { + {39, 2}, }; ! static arc arcs_58_2[1] = { ! {56, 3}, ! }; ! static arc arcs_58_3[1] = { ! {9, 4}, ! }; ! static arc arcs_58_4[2] = { ! {110, 5}, ! {0, 4}, ! }; ! static arc arcs_58_5[1] = { ! {0, 5}, ! }; ! static state states_58[6] = { ! {1, arcs_58_0}, ! {1, arcs_58_1}, ! {1, arcs_58_2}, ! {1, arcs_58_3}, ! {2, arcs_58_4}, ! {1, arcs_58_5}, ! }; ! static arc arcs_59_0[1] = { ! {63, 1}, ! }; ! static arc arcs_59_1[1] = { ! {21, 2}, ! }; ! static arc arcs_59_2[2] = { ! {110, 3}, ! {0, 2}, ! }; ! static arc arcs_59_3[1] = { ! {0, 3}, ! }; ! static state states_59[4] = { ! {1, arcs_59_0}, ! {1, arcs_59_1}, ! {2, arcs_59_2}, ! {1, arcs_59_3}, ! }; ! static dfa dfas[60] = { {256, "single_input", 0, 3, states_0, ! "\004\030\001\000\140\341\153\202\034\200\000\000\060\042\171\010"}, {257, "file_input", 0, 2, states_1, ! "\204\030\001\000\140\341\153\202\034\200\000\000\060\042\171\010"}, {258, "eval_input", 0, 3, states_2, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\042\171\000"}, {259, "funcdef", 0, 6, states_3, "\000\010\000\000\000\000\000\000\000\000\000\000\000\000\000\000"}, {260, "parameters", 0, 4, states_4, *************** *** 1241,1253 **** {263, "fplist", 0, 3, states_7, "\000\020\001\000\000\000\000\000\000\000\000\000\000\000\000\000"}, {264, "stmt", 0, 2, states_8, ! "\000\030\001\000\140\341\153\202\034\200\000\000\060\242\074\004"}, {265, "simple_stmt", 0, 4, states_9, ! "\000\020\001\000\140\341\153\002\000\200\000\000\060\242\074\000"}, {266, "small_stmt", 0, 2, states_10, ! "\000\020\001\000\140\341\153\002\000\200\000\000\060\242\074\000"}, {267, "expr_stmt", 0, 2, states_11, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\242\074\000"}, {268, "print_stmt", 0, 3, states_12, "\000\000\000\000\040\000\000\000\000\000\000\000\000\000\000\000"}, {269, "del_stmt", 0, 3, states_13, --- 1303,1315 ---- {263, "fplist", 0, 3, states_7, "\000\020\001\000\000\000\000\000\000\000\000\000\000\000\000\000"}, {264, "stmt", 0, 2, states_8, ! "\000\030\001\000\140\341\153\202\034\200\000\000\060\042\171\010"}, {265, "simple_stmt", 0, 4, states_9, ! "\000\020\001\000\140\341\153\002\000\200\000\000\060\042\171\000"}, {266, "small_stmt", 0, 2, states_10, ! "\000\020\001\000\140\341\153\002\000\200\000\000\060\042\171\000"}, {267, "expr_stmt", 0, 2, states_11, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\042\171\000"}, {268, "print_stmt", 0, 3, states_12, "\000\000\000\000\040\000\000\000\000\000\000\000\000\000\000\000"}, {269, "del_stmt", 0, 3, states_13, *************** *** 1275,1281 **** {280, "assert_stmt", 0, 5, states_24, "\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\000"}, {281, "compound_stmt", 0, 2, states_25, ! "\000\010\000\000\000\000\000\200\034\000\000\000\000\000\000\004"}, {282, "if_stmt", 0, 8, states_26, "\000\000\000\000\000\000\000\200\000\000\000\000\000\000\000\000"}, {283, "while_stmt", 0, 8, states_27, --- 1337,1343 ---- {280, "assert_stmt", 0, 5, states_24, "\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\000"}, {281, "compound_stmt", 0, 2, states_25, ! "\000\010\000\000\000\000\000\200\034\000\000\000\000\000\000\010"}, {282, "if_stmt", 0, 8, states_26, "\000\000\000\000\000\000\000\200\000\000\000\000\000\000\000\000"}, {283, "while_stmt", 0, 8, states_27, *************** *** 1287,1345 **** {286, "except_clause", 0, 5, states_30, "\000\000\000\000\000\000\000\000\200\000\000\000\000\000\000\000"}, {287, "suite", 0, 5, states_31, ! "\004\020\001\000\140\341\153\002\000\200\000\000\060\242\074\000"}, {288, "test", 0, 4, states_32, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\242\074\000"}, {289, "and_test", 0, 2, states_33, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\242\034\000"}, {290, "not_test", 0, 3, states_34, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\242\034\000"}, {291, "comparison", 0, 2, states_35, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\242\034\000"}, {292, "comp_op", 0, 4, states_36, "\000\000\000\000\000\000\000\001\000\200\374\003\000\000\000\000"}, {293, "expr", 0, 2, states_37, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\242\034\000"}, {294, "xor_expr", 0, 2, states_38, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\242\034\000"}, {295, "and_expr", 0, 2, states_39, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\242\034\000"}, {296, "shift_expr", 0, 2, states_40, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\242\034\000"}, {297, "arith_expr", 0, 2, states_41, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\242\034\000"}, {298, "term", 0, 2, states_42, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\242\034\000"}, {299, "factor", 0, 3, states_43, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\242\034\000"}, {300, "power", 0, 4, states_44, ! "\000\020\001\000\000\000\000\000\000\000\000\000\000\240\034\000"}, ! {301, "atom", 0, 11, states_45, ! "\000\020\001\000\000\000\000\000\000\000\000\000\000\240\034\000"}, {302, "lambdef", 0, 5, states_46, ! "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\040\000"}, {303, "trailer", 0, 7, states_47, "\000\000\001\000\000\000\020\000\000\000\000\000\000\040\000\000"}, {304, "subscriptlist", 0, 3, states_48, ! "\000\120\001\000\000\000\020\000\000\200\000\000\060\242\074\000"}, {305, "subscript", 0, 7, states_49, ! "\000\120\001\000\000\000\020\000\000\200\000\000\060\242\074\000"}, {306, "sliceop", 0, 3, states_50, "\000\100\000\000\000\000\000\000\000\000\000\000\000\000\000\000"}, {307, "exprlist", 0, 3, states_51, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\242\034\000"}, {308, "testlist", 0, 3, states_52, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\242\074\000"}, {309, "dictmaker", 0, 5, states_53, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\242\074\000"}, {310, "classdef", 0, 8, states_54, ! "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\004"}, {311, "arglist", 0, 8, states_55, ! "\000\020\201\001\000\000\000\000\000\200\000\000\060\242\074\000"}, {312, "argument", 0, 4, states_56, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\242\074\000"}, }; ! static label labels[124] = { {0, "EMPTY"}, {256, 0}, {4, 0}, --- 1349,1413 ---- {286, "except_clause", 0, 5, states_30, "\000\000\000\000\000\000\000\000\200\000\000\000\000\000\000\000"}, {287, "suite", 0, 5, states_31, ! "\004\020\001\000\140\341\153\002\000\200\000\000\060\042\171\000"}, {288, "test", 0, 4, states_32, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\042\171\000"}, {289, "and_test", 0, 2, states_33, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\042\071\000"}, {290, "not_test", 0, 3, states_34, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\042\071\000"}, {291, "comparison", 0, 2, states_35, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\042\071\000"}, {292, "comp_op", 0, 4, states_36, "\000\000\000\000\000\000\000\001\000\200\374\003\000\000\000\000"}, {293, "expr", 0, 2, states_37, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\042\071\000"}, {294, "xor_expr", 0, 2, states_38, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\042\071\000"}, {295, "and_expr", 0, 2, states_39, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\042\071\000"}, {296, "shift_expr", 0, 2, states_40, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\042\071\000"}, {297, "arith_expr", 0, 2, states_41, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\042\071\000"}, {298, "term", 0, 2, states_42, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\042\071\000"}, {299, "factor", 0, 3, states_43, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\042\071\000"}, {300, "power", 0, 4, states_44, ! "\000\020\001\000\000\000\000\000\000\000\000\000\000\040\071\000"}, ! {301, "atom", 0, 12, states_45, ! "\000\020\001\000\000\000\000\000\000\000\000\000\000\040\071\000"}, {302, "lambdef", 0, 5, states_46, ! "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\100\000"}, {303, "trailer", 0, 7, states_47, "\000\000\001\000\000\000\020\000\000\000\000\000\000\040\000\000"}, {304, "subscriptlist", 0, 3, states_48, ! "\000\120\001\000\000\000\020\000\000\200\000\000\060\042\171\000"}, {305, "subscript", 0, 7, states_49, ! "\000\120\001\000\000\000\020\000\000\200\000\000\060\042\171\000"}, {306, "sliceop", 0, 3, states_50, "\000\100\000\000\000\000\000\000\000\000\000\000\000\000\000\000"}, {307, "exprlist", 0, 3, states_51, ! "\000\020\001\000\000\000\000\000\000\000\000\000\060\042\071\000"}, {308, "testlist", 0, 3, states_52, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\042\171\000"}, {309, "dictmaker", 0, 5, states_53, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\042\171\000"}, {310, "classdef", 0, 8, states_54, ! "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\010"}, {311, "arglist", 0, 8, states_55, ! "\000\020\201\001\000\000\000\000\000\200\000\000\060\042\171\000"}, {312, "argument", 0, 4, states_56, ! "\000\020\001\000\000\000\000\000\000\200\000\000\060\042\171\000"}, ! {313, "list_iter", 0, 2, states_57, ! "\000\000\000\000\000\000\000\200\010\000\000\000\000\000\000\000"}, ! {314, "list_for", 0, 6, states_58, ! "\000\000\000\000\000\000\000\000\010\000\000\000\000\000\000\000"}, ! {315, "list_if", 0, 4, states_59, ! "\000\000\000\000\000\000\000\200\000\000\000\000\000\000\000\000"}, }; ! static label labels[127] = { {0, "EMPTY"}, {256, 0}, {4, 0}, *************** *** 1450,1455 **** --- 1518,1524 ---- {301, 0}, {303, 0}, {9, 0}, + {313, 0}, {10, 0}, {26, 0}, {309, 0}, *************** *** 1464,1473 **** {306, 0}, {1, "class"}, {312, 0}, }; grammar _PyParser_Grammar = { ! 57, dfas, ! {124, labels}, 256 }; --- 1533,1544 ---- {306, 0}, {1, "class"}, {312, 0}, + {314, 0}, + {315, 0}, }; grammar _PyParser_Grammar = { ! 60, dfas, ! {127, labels}, 256 }; --w4MOZK6GnZ-- From Fredrik Lundh" Message-ID: <005801bfe8dc$9ef3f320$f2a6b5d4@hagrid> barry scott wrote: > os.popen fails to work if pythonw.exe is used to start python. This is > true for 1.5.2 and 1.6a2. >=20 > The root cause of the problem is in the Microsoft C RTL implementation > of _popen(). _popen() will fail if there is not a valid file = descriptor > for stdin or stdout. >=20 > The following replacement for WinMain.c works around the problem. > I also ensure a valid descriptor for stderr for completeness. >=20 > This was compiled and test under VC++ 6.0 SP3 on Windows 2000. +1 from me. unless mark|bill|trent|.+ objects, I'll check it in later. cheers /F PS. I've uploaded it to the SF patch manager: http://sourceforge.net/patch/index.php?patch_id=3D100764&group_id=3D5470 From gstein@lyra.org Sat Jul 8 14:14:18 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 8 Jul 2000 06:14:18 -0700 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe In-Reply-To: <005801bfe8dc$9ef3f320$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jul 08, 2000 at 03:01:21PM +0200 References: <000001bfe79d$ac720ae0$060210ac@private> <005801bfe8dc$9ef3f320$f2a6b5d4@hagrid> Message-ID: <20000708061417.E29590@lyra.org> Bill has done a ton of stuff with popen() on Windows. I'm CC'ing him to make sure that he sees this. Cheers, -g On Sat, Jul 08, 2000 at 03:01:21PM +0200, Fredrik Lundh wrote: > barry scott wrote: > > os.popen fails to work if pythonw.exe is used to start python. This is > > true for 1.5.2 and 1.6a2. > > > > The root cause of the problem is in the Microsoft C RTL implementation > > of _popen(). _popen() will fail if there is not a valid file descriptor > > for stdin or stdout. > > > > The following replacement for WinMain.c works around the problem. > > I also ensure a valid descriptor for stderr for completeness. > > > > This was compiled and test under VC++ 6.0 SP3 on Windows 2000. > > +1 from me. > > unless mark|bill|trent|.+ objects, I'll check it in later. > > cheers /F > > PS. I've uploaded it to the SF patch manager: > http://sourceforge.net/patch/index.php?patch_id=100764&group_id=5470 > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From fdrake@beopen.com Sat Jul 8 14:29:34 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 09:29:34 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: References: <200007062157.QAA01227@cj20424-a.reston1.va.home.com> Message-ID: <14695.11454.283571.492775@cj42289-a.reston1.va.home.com> Tim Peters writes: > ISO refuses to put current stds online, so I'll reword an anonymous source > (shhh! & some of this may be a little out of date): The URL I posted has a pointer to a copy of the "Final Committee Draft," which is probably sufficient. PDF and PostScript were both available. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Sat Jul 8 14:32:55 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 09:32:55 -0400 (EDT) Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: References: <20000708064203.D7FBC1CD45@dinsdale.python.org> Message-ID: <14695.11655.433199.734714@cj42289-a.reston1.va.home.com> Tim Peters writes: > Fred, you appear to be 4-space indenting C source. Is that allowed? Last I > think I heard, Guido was still clinging to his schizophrenia on this topic > (4-space for .py and no hard tabs, 8-space for .c/.h and hard tabs). I seem to recall that Guido had caved on this, mostly because he received enough complaints about too much code getting shoved way over to the right, in a column a dozen of fewer characters wide (which is seriously hard to decode). I don't remember if this was on the list or in a meeting. If I'm mis-remembering, then we should presure him on this until he does cave. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul@prescod.net Sat Jul 8 14:32:03 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 08 Jul 2000 08:32:03 -0500 Subject: [Python-Dev] String coercion References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <39661CAF.9252D734@prescod.net> <200007072102.QAA05114@cj20424-a.reston1.va.home.com> <396661F4.6541AB42@prescod.net> <20000708013216.M26534@xs4all.nl> Message-ID: <39672D53.899D4BEB@prescod.net> Thomas Wouters wrote: > > ... > > The right hand side of the operation determines what the result is ? No, either side determines what the result is. This is not magic. It's just like floating point coercion or complex number coercion. > Somehow > I find that confusing and counter-intuitive, but perhaps I'm too used to > __add__ vs. __radd__ ;) This can be easily defined in terms of add and radd: class PaulsString: def __init__( self, str ): self.str=str def __add__( self, foo ): return self.str + str( foo ) def __radd__( self, bar ): return str( bar ) + self.str print PaulsString("abcdef")+5 print open+PaulsString("ghijkl") abcdef5 ghijkl Here's an even simpler definition: class PaulsString: def __init__( self, str ): self.str=str def __coerce__( self, other ): return (self.str, str( other )) Ping says: > As it stands, with both 8-bit strings and Unicode strings, i think > this would result in too much hidden complexity -- thinking about this > can wait until we have only one string type. I don't see any hidden complexity. Python has features specifically designed to allow this sort of thing on a per-type basis. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From guido@beopen.com Sat Jul 8 15:34:14 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 09:34:14 -0500 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe In-Reply-To: Your message of "Thu, 06 Jul 2000 23:58:17 +0100." <000001bfe79d$ac720ae0$060210ac@private> References: <000001bfe79d$ac720ae0$060210ac@private> Message-ID: <200007081434.JAA07087@cj20424-a.reston1.va.home.com> > os.popen fails to work if pythonw.exe is used to start python. This is > true for 1.5.2 and 1.6a2. > > The root cause of the problem is in the Microsoft C RTL implementation > of _popen(). _popen() will fail if there is not a valid file descriptor > for stdin or stdout. > > The following replacement for WinMain.c works around the problem. > I also ensure a valid descriptor for stderr for completeness. > > This was compiled and test under VC++ 6.0 SP3 on Windows 2000. Let's also test it on Windows 98, 95 and NT. If it works for all, I'm +1. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake@beopen.com Sat Jul 8 14:35:08 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 09:35:08 -0400 (EDT) Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: References: Message-ID: <14695.11788.491744.539193@cj42289-a.reston1.va.home.com> Moshe Zadka writes: > I have never seen a formal statement from Guido about it, but I always > assumed Python's C sources are linux kernel style...No? Python's sources are Guido's style. Any similarities with the Linux kernel are coincidental. I've seen a comparison, but don't remember much about it. Most developers don't even know where to look to find out the rules for Linux kernel style. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@beopen.com Sat Jul 8 15:39:51 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 09:39:51 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules linuxaudiodev.c,2.2,2.3 In-Reply-To: Your message of "Sat, 08 Jul 2000 10:28:47 +0200." <20000708102847.N26534@xs4all.nl> References: <200007080606.XAA22987@slayer.i.sourceforge.net> <20000708102847.N26534@xs4all.nl> Message-ID: <200007081439.JAA07139@cj20424-a.reston1.va.home.com> > Aren't tabs preferred as C-source indents, instead of 4-spaces ? At least, > that's what I see in Python/*.c and Object/*.c, but I only vaguely recall it > from the style document... Yes, you're right. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From Fredrik Lundh" <14695.11655.433199.734714@cj42289-a.reston1.va.home.com> Message-ID: <039f01bfe8e2$deb32ac0$f2a6b5d4@hagrid> fred wrote: =20 > Tim Peters writes: > > Fred, you appear to be 4-space indenting C source. Is that = allowed? Last I > > think I heard, Guido was still clinging to his schizophrenia on = this topic > > (4-space for .py and no hard tabs, 8-space for .c/.h and hard = tabs). >=20 > I seem to recall that Guido had caved on this, mostly because he > received enough complaints about too much code getting shoved way over > to the right, in a column a dozen of fewer characters wide (which is > seriously hard to decode). I don't remember if this was on the list > or in a meeting. > If I'm mis-remembering, then we should presure him on this until he > does cave. ;) guido? I think we need an official BDFL statement here... From guido@beopen.com Sat Jul 8 16:08:48 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 10:08:48 -0500 Subject: [Python-Dev] Encodings In-Reply-To: Your message of "Fri, 07 Jul 2000 18:32:13 MST." <20000707183213.P29590@lyra.org> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> Message-ID: <200007081508.KAA07351@cj20424-a.reston1.va.home.com> > Please... toss the changeable default. If everybody knows the default > encoding is "ascii" and they want something else, then they know what to do. > But when the default can change, then it can't be relied on. The coder is > going to have to do an explicit encoding anyways. So why have a default? I couldn't have said it better. It's okay for now to have it changeable at the C level -- with endless caveats that it should be set only once before any use, and marked as an experimental feature. But the Python access and the reliance on the environment should go. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Sat Jul 8 16:14:06 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 10:14:06 -0500 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: Your message of "Fri, 07 Jul 2000 19:49:20 -0400." <14694.27776.620365.621524@cj42289-a.reston1.va.home.com> References: <14694.17186.868952.214837@anthem.concentric.net> <14694.27776.620365.621524@cj42289-a.reston1.va.home.com> Message-ID: <200007081514.KAA07398@cj20424-a.reston1.va.home.com> > Barry: Perhaps the right solution is to hard-code python-mode to > always set indent-tabs-mode to nil, the indentation to 4, and retabify > when it loads a file? ;) Oh, and do it again when it saves, so > nobody can screw up their modules. ;) That would be fine if it weren't for triple-quoted strings... At the very least someone should run Lib/tabnanny.py on the Lib tree and fix all complaints! There are still complaints about mailbox.py and shlex.py. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake@beopen.com Sat Jul 8 15:26:27 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 10:26:27 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <200007081514.KAA07398@cj20424-a.reston1.va.home.com> References: <14694.17186.868952.214837@anthem.concentric.net> <14694.27776.620365.621524@cj42289-a.reston1.va.home.com> <200007081514.KAA07398@cj20424-a.reston1.va.home.com> Message-ID: <14695.14867.517707.59800@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > At the very least someone should run Lib/tabnanny.py on the Lib tree > and fix all complaints! There are still complaints about mailbox.py > and shlex.py. I'll do this. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw@beopen.com Sat Jul 8 16:00:33 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sat, 8 Jul 2000 11:00:33 -0400 (EDT) Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs References: <20000708064203.D7FBC1CD45@dinsdale.python.org> Message-ID: <14695.16913.984694.3842@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> Fred, you appear to be 4-space indenting C source. Is that TP> allowed? Last I think I heard, Guido was still clinging to TP> his schizophrenia on this topic (4-space for .py and no hard TP> tabs, 8-space for .c/.h and hard tabs). Emacs CC Mode has a "python" style which defines 8-space hard-tab indentation. This was the blessed style for Python's C code. I distinctly remember Guido agreeing to 4 space indents for Python 1.7 (or new code) but that it wasn't worth going back and changing existing code at this time. If Fred's doing a code cleansing then it's probably okay that he also adjust the indentation. Most important is consistency within the file. -Barry From tim_one@email.msn.com Sat Jul 8 16:17:49 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 11:17:49 -0400 Subject: [Python-Dev] CVS: python/dist/src/Include pyport.h ... In-Reply-To: <20000708025506.A29590@lyra.org> Message-ID: [Greg Stein] > Note that it would be nice for pyport.h to *also* contain all the > Include/my* stuff. i.e. it isn't just about C-language > operations, but also about the (un)available libraries. > > IOW, stop the propagation of my* and drop those tweaky things > into pyport. Sounds good to me, but I'm not going to make A Project out of that for myself. Kinda like getting rid of Py_PROTO and ANSI-fying, I'm just going to chip away at it as it's convenient when working on other things. pyproto.h isn't "my" file! Everyone have at it. best-way-to-get-everyone-on-the-same-page-is-to-have-everyone- write-part-of-it-ly y'rs - tim From tim_one@email.msn.com Sat Jul 8 16:29:06 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 11:29:06 -0400 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe In-Reply-To: <005801bfe8dc$9ef3f320$f2a6b5d4@hagrid> Message-ID: [/F] > +1 from me. > > unless mark|bill|trent|.+ objects, I'll check it in later. > > cheers /F > > PS. I've uploaded it to the SF patch manager: > http://sourceforge.net/patch/index.php?patch_id=100764&group_id=5470 Where I assigned it to you, but didn't accept it for sytle reasons: Assigned to effbot. I would have changed the status to accepted, except the coding style is one Guido won't accept: uses C++ comments in places, "if" braces in the wrong places, "extra" whitespace at each end of arglists, "if(" instead of "if (". I expect that arguing about style is futile. not-to-mention-a-waste-of-time-ly y'rs - tim From paul@prescod.net Sat Jul 8 16:34:16 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 08 Jul 2000 10:34:16 -0500 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] Message-ID: <396749F8.F98D2F8C@prescod.net> For those that don't read comp.lang.python. -------- Original Message -------- Subject: Re: Splitting c.l.py... Date: Sat, 08 Jul 2000 03:52:44 GMT From: "Neil Hodgson" Organization: BigPond Internet Services (http://www.bigpond.net.au) To: python-list@python.org Newsgroups: comp.lang.python References: <3dituj9cdi.fsf@kronos.cnri.reston.va.us> <39661DE1.A409330C@roguewave.com> <20000707140442.B4771@kronos.cnri.reston.va.us> > Beats me. Hmm... here's a possibility: ... Essentially the newsgroup would > be a read-only view of the python-dev mailing list. But would it be of interest to anyone? python-dev has a much worse signal-to-noise ratio than comp.lang.python IMHO. One morning this week I opened up my mailer in the morning to see over 100 messages in python-dev and less than 80 in c.l.py. The traffic in python-dev alternates between checkin chat (there's a CVS lock here, that patch breaks on X, when will you finish Y?) and language/library design issues. I can see a reason for some of the detailed design issues to be decided on the same forum as the checkin chat with a limited group of people, but some of the larger issues should be debated in a wider forum. Was there any reason for "urllib.browse() issues" to be on python-dev? Possibly comp.lang.python is also a bad forum for discussing future changes to Python and should concentrate on solving peoples current problems and avoiding long winded discussions on new functionality. So a comp.lang.python.future (or similar mailing list) could provide a way for /all/ Pythoneers to be involved in the evolution of the language. Neil -- http://www.python.org/mailman/listinfo/python-list From tim_one@email.msn.com Sat Jul 8 16:36:32 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 11:36:32 -0400 Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: <14695.11655.433199.734714@cj42289-a.reston1.va.home.com> Message-ID: [Tim] > Fred, you appear to be 4-space indenting C source. Is that > allowed? Last I think I heard, Guido was still clinging to > his schizophrenia on this topic (4-space for .py and no hard > tabs, 8-space for .c/.h and hard tabs). [Fred] > I seem to recall that Guido had caved on this, mostly because he > received enough complaints about too much code getting shoved way over > to the right, in a column a dozen of fewer characters wide (which is > seriously hard to decode). I don't remember if this was on the list > or in a meeting. > If I'm mis-remembering, then we should presure him on this until he > does cave. ;) Guido, you need to Pronounce on this! I personally prefer 4-space no-hard-tabs everywhere, but given the way most editors work, the most important thing is that there's no variation within a given file type (e.g., that all .c files do the same, and all .py files do the same, but it's bearable for .c and .py files to differ -- which latter has been the case until now). From peter@schneider-kamp.de Sat Jul 8 18:39:55 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 08 Jul 2000 17:39:55 +0000 Subject: indentation in .c files (was Re: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules linuxaudiodev.c,2.2,2.3) Message-ID: <3967676B.41E1CC5C@stud.ntnu.no> [Guido on a mail from Thomas Wouters] > > > Aren't tabs preferred as C-source indents, instead of 4-spaces ? At least, > > that's what I see in Python/*.c and Object/*.c, but I only vaguely recall it > > from the style document... > > Yes, you're right. Does that mean I should load up a revised version of my ANSI-fying patches for posixmodule and mmapmodule? Assuming Fred knew what he did, I also changed to -s 4 -t 8 ... Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From fdrake@beopen.com Sat Jul 8 17:01:39 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 12:01:39 -0400 (EDT) Subject: indentation in .c files (was Re: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules linuxaudiodev.c,2.2,2.3) In-Reply-To: <3967676B.41E1CC5C@stud.ntnu.no> References: <3967676B.41E1CC5C@stud.ntnu.no> Message-ID: <14695.20579.776070.898183@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > Does that mean I should load up a revised version of my > ANSI-fying patches for posixmodule and mmapmodule? ANSI-fication is clearly good. Whether or not 4-space indents go in is appearantly dependent on who checks in the patch. So leave them in if you've already done the work. ;) > Assuming Fred knew what he did, I also changed to -s 4 -t 8 ... Now, if we could get the rest of PythonLabs to make that assumption, we'd be in pretty good shape! ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal@lemburg.com Sat Jul 8 17:05:16 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 08 Jul 2000 18:05:16 +0200 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> Message-ID: <3967513C.BAF459FB@lemburg.com> Guido van Rossum wrote: > > > Please... toss the changeable default. If everybody knows the default > > encoding is "ascii" and they want something else, then they know what to do. > > But when the default can change, then it can't be relied on. The coder is > > going to have to do an explicit encoding anyways. So why have a default? > > I couldn't have said it better. It's okay for now to have it > changeable at the C level -- with endless caveats that it should be > set only once before any use, and marked as an experimental feature. > But the Python access and the reliance on the environment should go. Sorry, but I'm really surprised now: I've put many hours of work into this, hacked up encoding support for locale.py, went through endless discussions, proposed the changable default as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy ... and now all it takes is one single posting to render all that work useless ??? Instead of tossing things we should be *constructive* and come up with a solution to the hash value problem, e.g. I would like to make the hash value be calculated from the UTF-16 value in a way that is compatible with ASCII strings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@beopen.com Sat Jul 8 17:13:12 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 12:13:12 -0400 (EDT) Subject: [Python-Dev] SourceForge administration Message-ID: <14695.21272.269311.720751@cj42289-a.reston1.va.home.com> I was just browsing the SourceForge support requests, and it looks like no CVS-related requests have been dealt with for about 48 hours. So it's not that they're ignoring us, it's that they're ignoring support requests. If anyone knows anyone there, can ou ping them and ask if the company picnic has been going on all this time? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Sat Jul 8 17:24:08 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 12:24:08 -0400 (EDT) Subject: [Python-Dev] Encodings In-Reply-To: <3967513C.BAF459FB@lemburg.com> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> Message-ID: <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Sorry, but I'm really surprised now: I've put many hours of > work into this, hacked up encoding support for locale.py, > went through endless discussions, proposed the changable default > as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy My recollection was that the purpose of the changable default was so that we could experiment with different defaults more easily, not that we'd keep it changable. I'm not an expert on these issues and have tried to stay out of the way on the discussion, but the idea of a changable default just seems like we're asking for trouble. I'm sorry that you feel your efforts have been wasted; I don't think anyone tried to spend your time without careful consideration, but it is important that we all understand what we have gained from this experiment. Before you implemented the changable default, we all had the opportunity to presume to know how things would work with it, and could bitch or plead about it as we felt appropriate. Now that it's been tried, we have a little more real experiance with it, and can point to the evidence that's been presented here as we each make our arguments on the topic. So I'd have to say that your efforts have *not* been wasted; we now have a very good idea of what's involved and whether "it works." I, for one, am glad that the experiment was done (and expecially that it was done by someone who knows more about this than me!). > Instead of tossing things we should be *constructive* and come > up with a solution to the hash value problem, e.g. I would > like to make the hash value be calculated from the UTF-16 > value in a way that is compatible with ASCII strings. This may be the right thing for the hash value; I don't know. But I think this is in some ways separate from the changable defaults question. This approach can be taken for getting hash values right without having a changable default encoding. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Fredrik Lundh" <20000706083223.A29375@newcnri.cnri.reston.va.us> Message-ID: <002a01bfe8fb$e0834d80$f2a6b5d4@hagrid> amk wrote: > .regs was never documented in the library reference, nor in the > docstrings in libre.tex; it was an underlying implementation detail > some people happened to take advantage of. If /F wants to add it in > order to be nice, fine; I certainly wouldn't bother to do that. I'm feel nice today. it'll be in the next release. From tim_one@email.msn.com Sat Jul 8 18:02:06 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 13:02:06 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <14695.11454.283571.492775@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > The URL I posted has a pointer to a copy of the "Final Committee > Draft," [for C9X] which is probably sufficient. PDF and PostScript > were both available. Worth repeating: http://lglwww.epfl.ch/~wolf/c/c9x_changes.html PDF and plain-text versions can be gotten from http://wwwold.dkuug.dk/jtc1/sc22/open/n2794/ These are much better than the things I was working from (don't tell, but since I knew some of the people on the committee, I went rummaging around their home pages looking for committee working docs). "whatever-it-takes"-is-pythonic-ly y'rs - tim From paul@prescod.net Sat Jul 8 18:01:24 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 08 Jul 2000 12:01:24 -0500 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> Message-ID: <39675E64.305A6B8@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Sorry, but I'm really surprised now: I've put many hours of > work into this, hacked up encoding support for locale.py, > went through endless discussions, proposed the changable default > as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy > ... and now all it takes is one single posting to render all that > work useless ??? I thought that the compromise was ASCII. Having the default be changable could lead to defacto forks in that language. I, for one, am sorry I didn't say something earlier but as Greg said, the changable default sort of drifted from something that was useful for testing to something we started making design decisions based upon. I thought I had missed a decision somewhere along the line to make it a permanent feature. Also, as I said, a changable default is probably worth considering for I/O boundaries. If 90% of the text on a Japanese user's computer is in Shift-JIS, then things like .rc and .ini files should be in that encoding. Or they could be in XML and the XML parser could handle encoding issues for you... Here's the central point: How can we write code if we don't know whether "..."+u"..." is going to trigger a UnicodeException because of some environment variable a user has set? To be safe, we need to specify the encoding explicitly....which renders auto-coercion useless. I am trying to be constructive, but I see the hash value problem as being unrelated to this very basic point. First and foremost, coercion has to be predictable. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From fdrake@beopen.com Sat Jul 8 18:11:03 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 13:11:03 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: References: <14695.11454.283571.492775@cj42289-a.reston1.va.home.com> Message-ID: <14695.24743.906316.151151@cj42289-a.reston1.va.home.com> Tim Peters writes: > Worth repeating: > > http://lglwww.epfl.ch/~wolf/c/c9x_changes.html ... > These are much better than the things I was working from (don't tell, but > since I knew some of the people on the committee, I went rummaging around > their home pages looking for committee working docs). And to think that first link was just the first thing that Google listed. ;) It is nice -- I found that before and it was nicer than a lot of the other C9X pages I looked at. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gmcm@hypernet.com Sat Jul 8 18:19:13 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Sat, 8 Jul 2000 13:19:13 -0400 Subject: [Python-Dev] C coding style In-Reply-To: References: <14695.11655.433199.734714@cj42289-a.reston1.va.home.com> Message-ID: <1249045739-16239476@hypernet.com> > [Tim] > > Fred, you appear to be 4-space indenting C source. Is that > > allowed? Last I think I heard, Guido was still clinging to his > > schizophrenia on this topic (4-space for .py and no hard tabs, > > 8-space for .c/.h and hard tabs). Blah blah blah. Jeez, guys. The following options will make indent produce something that's so close to Guido's style, he'd probably never notice that it's not exactly his style: -br -bap -nce -ss -i8 -ci8 -lp -ts8 -psl -npcs -nbc -ip8 -ncs -nfca why-be-anal-when-the-computer-can-do-it-for-you-ly y'rs - Gordon From peter@schneider-kamp.de Sat Jul 8 20:27:50 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 08 Jul 2000 19:27:50 +0000 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix Message-ID: <396780B6.67247E2C@stud.ntnu.no> This is a multi-part message in MIME format. --------------EA0D50E02DA38B730060AB92 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am trying to fix the duplicate argument bug in the compiler. [example] >>> def f(a,a): print a ... >>> f(1,2) 2 [/example] My problem is that I get a segfault whenever I try to raise an com_error from com_arglist. I have attached a very short patch. Thanks for any hint, Peter P.S.: Is this on topic for python-dev? If not, where should I send such a request? -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de --------------EA0D50E02DA38B730060AB92 Content-Type: text/plain; charset=us-ascii; name="compile_funcdef.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="compile_funcdef.patch" diff -c -d -T --recursive python/dist/src/Python/compile.c python-mod/dist/src/Python/compile.c *** python/dist/src/Python/compile.c Mon Jul 3 21:39:47 2000 --- python-mod/dist/src/Python/compile.c Sat Jul 8 19:13:42 2000 *************** *** 3102,3109 **** name = nbuf; sprintf(nbuf, ".%d", i); complex = 1; } ! com_newlocal(c, name); c->c_argcount++; if (++i >= nch) break; --- 3103,3120 ---- name = nbuf; sprintf(nbuf, ".%d", i); complex = 1; + } + + nameval = PyString_InternFromString(name); + if (nameval == NULL) { + c->c_errors++; } ! if (PyDict_GetItem(c->c_locals, nameval)) { ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); ! } ! com_newlocal_o(c, nameval); ! Py_DECREF(nameval); ! c->c_argcount++; if (++i >= nch) break; --------------EA0D50E02DA38B730060AB92-- From fdrake@beopen.com Sat Jul 8 18:37:21 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 13:37:21 -0400 (EDT) Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix In-Reply-To: <396780B6.67247E2C@stud.ntnu.no> References: <396780B6.67247E2C@stud.ntnu.no> Message-ID: <14695.26321.650518.552363@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > P.S.: Is this on topic for python-dev? If not, where should > I send such a request? *I* think this is a good place for this. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Fredrik Lundh" http://sourceforge.net/patch/index.php?func=3Ddetailpatch&patch_id=3D1007= 65&group_id=3D5470 Patch #100765 tightens up the new parts of the locale.py interface, and adds support for platform-dependent locale mechanisms. Here's a summary of the changes: - merged setlocale and set_locale. the internal setlocale function is overridden by a python version which accepts *either* a string (old behaviour) or a locale tuple. - renamed a few methods (for consistency): get_locale =3D> getlocale get_default_locale =3D> getdefaultlocale set_to_default =3D> resetlocale (!) - the _locale implementation module can now implement an optional _getdefaultlocale function. if that function isn't available, a POSIX-based approach is used (check LANG and other environment variables). comments? From thomas@xs4all.net Sat Jul 8 20:21:50 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 8 Jul 2000 21:21:50 +0200 Subject: [Python-Dev] Include/pyport.h now exists In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 08, 2000 at 12:31:27AM -0400 References: Message-ID: <20000708212149.P26534@xs4all.nl> --GPJrCs/72TxItFYR Content-Type: text/plain; charset=us-ascii On Sat, Jul 08, 2000 at 12:31:27AM -0400, Tim Peters wrote: > Would someone who understands (& can test! I can't yet) autoconfig please > follow up on the last part? The stuff I checked in "fails safe", i.e. the > lack of autoconfig support should not cause problems on any of your > platforms. Can't say I understand all of autoconf but I read enough of the info pages to be able to do this ! :-) I couldn't find an existing test that covers this, so I used your example to make one; patch attached. It detects my linux box properly as 'doesn't zero-fill when right-shifting a negative number', but I haven't a Cray J90 handy to test the opposite ;) Feel free to change the wording to something a bit less... wordy, though ;) Oh, and don't forget to run autoheader & automake before checking in. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! --GPJrCs/72TxItFYR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="autoconf.patch" *** src-lm+rm/configure.in Wed Jul 5 12:38:09 2000 --- src/configure.in Sat Jul 8 20:18:35 2000 *************** *** 1136,1141 **** --- 1136,1154 ---- # check for endianness AC_C_BIGENDIAN + # Check whether signed-right-shift fills the left hand bits with the sign + # bit, or with zero (like the Cray J90 does, according to Tim Peters.) + signed_rshift_0fills="unknown" + AC_MSG_CHECKING(whether right-shift of negative number pads with zeros) + AC_TRY_RUN([ + int main() + { + exit(((-1)>>3 == -1) ? 1 : 0); + } + ],AC_DEFINE(SIGNED_RIGHT_SHIFT_ZERO_FILLS) signed_rshift_0fills="yes", + signed_rshift_0fills="no") + AC_MSG_RESULT($signed_rshift_0fills) + # THIS MUST BE LAST, IT CAN BREAK OTHER TESTS! # Add sys/socket.h to confdefs.h cat >> confdefs.h <<\EOF --GPJrCs/72TxItFYR-- From barry@scottb.demon.co.uk Sat Jul 8 20:31:37 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Sat, 8 Jul 2000 20:31:37 +0100 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe In-Reply-To: Message-ID: <000801bfe913$224c9d40$060210ac@private> The C++ comments are in the original source. I'm happy to use any style if that makes it easier to get patches accepted. BArry > -----Original Message----- > From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On > Behalf Of Tim Peters > Sent: 08 July 2000 16:29 > To: Fredrik Lundh; Barry Scott; PythonDev > Subject: RE: [Python-Dev] Fix to allow os.popen to work from pythonw.exe > > > [/F] > > +1 from me. > > > > unless mark|bill|trent|.+ objects, I'll check it in later. > > > > cheers /F > > > > PS. I've uploaded it to the SF patch manager: > > http://sourceforge.net/patch/index.php?patch_id=100764&group_id=5470 > > Where I assigned it to you, but didn't accept it for sytle reasons: > > Assigned to effbot. I would have changed the status to > accepted, except the coding style is one Guido won't accept: > uses C++ comments in places, "if" braces in the wrong places, > "extra" whitespace at each end of arglists, "if(" instead of > "if (". > > I expect that arguing about style is futile. > > not-to-mention-a-waste-of-time-ly y'rs - tim > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev > From billtut@microsoft.com Sat Jul 8 21:03:17 2000 From: billtut@microsoft.com (Bill Tutt) Date: Sat, 8 Jul 2000 13:03:17 -0700 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD296@RED-MSG-50> Ah, yes, the dreaded popen bug. A) If you really want to fix the problem everywhere then create a patch to popen for windows only that uses the code from the win32popen.cpp code. It includes code to handle Windows 9x as well. Not to mention the fact that this patch doesn't fix os.popen() in the following case: C/C++/whatever language binary that is a GUI app (windows subsystem) that embeds Python. (aka PythonWin.exe) The win32popen.cpp code works for all platforms and all cases, so a big -1 on this patch since it isn't doesn't handle all cases for the platforms the patch does work on. B) The -1's below really should be: INVALID_HANDLE_VALUE ! if (_get_osfhandle(0) == -1) ! dup2(null_file, 0); ! ! if (_get_osfhandle(1) == -1) ! dup2(null_file, 1); ! ! if (_get_osfhandle(2) == -1) ! dup2(null_file, 2); ! ! close(null_file); ! ! return Py_Main(__argc, __argv); } Wishing he could throttle the person who wrote popen in the CRT, Bill p.s. Just to clarify: Win32popen.cpp is all of the real work. Win32popenWin9x.* is the Win9x helper .exe so that you can use popen. <> <> <> begin 600 win32popen.cpp M(VEN8VQU9&4@(G=I;F1O=W,N:"(-"@T*+R\@0&1O8PT*#0HC:6YC;'5D92`B M4'ET:&]N+F@B#0HC:6YC;'5D92`B;6%L;&]C+F@B#0HC:6YC;'5D92`B:6\N M:"(-"B-I;F-L=61E(")F8VYT;"YH(@T*(VEN8VQU9&4@(E!Y5VEN5'EP97,N M:"(-"@T*(V1E9FEN92!$;&Q%>'!O'1EDUO9'5L95!A=&A;73L)#0H-"B\O(%1H97-E('1E;&P@7U!Y4&]P96XH M*2!W971H97(@=&\@PT*"6-H87(@*F-M9'-T4]B:F5C="`J9BPJ M4%R9U]087)S951U<&QE*&%R M9W,L(")S?',Z<&]P96XB+`T*"0D)"0D)("`F8VUDPT*"0E0>45R&-?5F%L M=65%5!O<&5N*&-M9'-T M5!O<&5N*&-M9'-T4]B:F5C="`J4'E0;W!E;C(H4'E/8FIE8W0@*G-E;&8L M(%!Y3V)J96-T("`J87)G45X8U]686QU M945R4]B:F5C="`@*F%R9W,I#0I[#0H)8VAAPT*"0E0>45R&-?5F%L M=65%4]B:F5C="`@*F%R9W,I M#0I[#0H)8VAAPT* M"0E0>45R&-?5F%L=65%D-O;G-O;&53<&%W;B`](")W:6XS,G!O<&5N5VEN.7@N97AE M(%PB(CL-"@EI;G0@:3L-"@EI;G0@>#L-"@T*"6EF("AI(#T@1V5T16YV:7)O M;FUE;G1687)I86)L92@B0T]-4U!%0R(L3E5,3"PP*2D-"B`@("![#0H)"7,Q M(#T@*&-H87(@*BE?86QL;V-A*&DI.PT*"0EI9B`H(2AX(#T@1V5T16YV:7)O M;FUE;G1687)I86)L92@B0T]-4U!%0R(L(',Q+"!I*2DI#0H)"0ER971U#L-"@D):68@*"%G7V952AS,BP@>"D[#0H) M"0ES<')I;G1F*`T*"0D)"7,R+`T*"0D)"2(E2!C;60N97AE("\@8V]M;6%N M9"YC;VT@:6X@=&AE('!A=&@-"@DO+R!.;W<@=V4G;&P@:G5S="!EF5O9BA35$%25%5024Y&3RDI.PT*"7-I4W1APT*"0DO+R!#;&]S92!T:&4@ M:&%N9&QE4]B:F5C="`J M7U!Y4&]P96XH8VAAF5O9BA314-54DE465]!5%1224)55$53*3L-"@ES84%T='(N M8DEN:&5R:71(86YD;&4@/2!44E5%.PT*"7-A071T5=I;E]3971! M4$E%PT*"0EC87-E(%]/7U=2 M3TY,62!\(%]/7U1%6%0Z#0H)"0DO+R!#87-E(&9O'0@;6]D92X-"@D)"69D,2`](%]O<&5N7V]S9FAA M;F1L92@H;&]N9REH0VAI;&13=&1I;E=R1'5P+"!M;V1E*3L-"@D)"68Q(#T@ M7V9D;W!E;BAF9#$L(")W(BD[#0H)"0EF(#T@4'E&:6QE7T9R;VU&:6QE*&8Q M+"!C;61S=')I;F49I;&5?1G)O;49I;&4H9C$L(&-M M9'-TF4H M9BP@,"D[#0H)"0DO+R!792!D;VXG="!C87)E(&%B;W5T('1H97-E('!I<&5S M(&%N>6UO2!M;V1E+@T*"0D)9F0Q(#T@7V]P96Y?;W-F:&%N9&QE*"AL M;VYG*6A#:&EL9%-T9&EN5W)$=7`L(&UO9&4I.PT*"0D)9C$@/2!?9F1O<&5N M*&9D,2P@(G=B(BD[#0H)"0EF(#T@4'E&:6QE7T9R;VU&:6QE*&8Q+"!C;61S M=')I;F49I;&5?4V5T0G5F4VEZ92AF M+"`P*3L-"@D)"2\O(%=E(&1O;B=T(&-APT*"2`@("!C:&%R("IM,2P@*FTR M.PT*"2`@("!0>4]B:F5C="`J<#$L("IP,CL-"@D@("`@#0H)("`@(&EF("AM M;V1E("8F(%]/7U1%6%0I#0H)"7L-"@D)"6TQ/2)R(CL-"@D)"6TR/2)W(CL- M"@D)?0T*"2`@("!E;'-E#0H)"7L-"@D)"6TQ/2)R8B([#0H)"0EM,CTB=V(B M.PT*"0E]#0H-"@D@("`@9F0Q(#T@7V]P96Y?;W-F:&%N9&QE*"AL;VYG*6A# M:&EL9%-T9&EN5W)$=7`L(&UO9&4I.PT*"2`@("!F,2`](%]F9&]P96XH9F0Q M+"!M,BD[#0H)("`@(&9D,B`](%]O<&5N7V]S9FAA;F1L92@H;&]N9REH0VAI M;&13=&1O=7129$1U<"P@;6]D92D[#0H)("`@(&8R(#T@7V9D;W!E;BAF9#(L M(&TQ*3L-"@D@("`@<#$@/2!0>49I;&5?1G)O;49I;&4H9C$L(&-M9'-T49I;&5?1G)O;49I;&4H9C(L(&-M9'-T5]"=6EL9%9A;'5E*")/3R(L<#$L<#(I.PT* M"2`@("!B49I;&5? M1G)O;49I;&4H9C(L(&-M9'-TF4H<#,L(#`I.PT* M"2`@("!F(#T@4'E?0G5I;&1686QU92@B3T]/(BQP,2QP,BQP,RD[#0H)("`@ M(&)R96%K.PT*"7T-"@E]#0H-"@EI9B`H;B`]/2!03U!%3E\T*0T*"7L-"@D) M:68@*"%?4'E0;W!E;D-R96%T95!R;V-E2!T M:&4@8VAI;&0@2&%N9&QE(BD[#0H-"@ER971U71H;VX@=VEN,S)P:7!E(&UO9'5L95QN(@T*(G1O('=O M"X@($ET(&ES M7&XB#0HB;F]T(&1EPT*"2`@ M($UEF5O9BAS:2D[#0H@("!S:2YD=T9L86=S("`@(#T@4U1!4E1&7U5315-41$A! M3D1,15,[#0H@("!S:2YH4W1D26YP=70@(#T@1V5T4W1D2&%N9&QE("A35$1? M24Y0551?2$%.1$Q%*3L-"B`@('-I+FA3=&1/=71P=70@/2!'9713=&1(86YD M;&4@*%-41%]/5510551?2$%.1$Q%*3L-"B`@('-I+FA3=&1% Ah, yes, the dreaded popen bug. A) If you really want to fix the problem everywhere then create a patch to popen for windows only that uses the code from the win32popen.cpp code. It includes code to handle Windows 9x as well. Not to mention the fact that this patch doesn't fix os.popen() in the following case: C/C++/whatever language binary that is a GUI app (windows subsystem) that embeds Python. (aka PythonWin.exe) The win32popen.cpp code works for all platforms and all cases, so a big -1 on this patch since it isn't doesn't handle all cases for the platforms the patch does work on. B) The -1's below really should be: INVALID_HANDLE_VALUE ! if (_get_osfhandle(0) == -1) ! dup2(null_file, 0); ! ! if (_get_osfhandle(1) == -1) ! dup2(null_file, 1); ! ! if (_get_osfhandle(2) == -1) ! dup2(null_file, 2); ! ! close(null_file); ! ! return Py_Main(__argc, __argv); } Wishing he could throttle the person who wrote popen in the CRT, Bill p.s. Just to clarify: Win32popen.cpp is all of the real work. Win32popenWin9x.* is the Win9x helper .exe so that you can use popen. <> <> <> begin 600 win32popen.cpp M(VEN8VQU9&4@(G=I;F1O=W,N:"(-"@T*+R\@0&1O8PT*#0HC:6YC;'5D92`B M4'ET:&]N+F@B#0HC:6YC;'5D92`B;6%L;&]C+F@B#0HC:6YC;'5D92`B:6\N M:"(-"B-I;F-L=61E(")F8VYT;"YH(@T*(VEN8VQU9&4@(E!Y5VEN5'EP97,N M:"(-"@T*(V1E9FEN92!$;&Q%>'!O'1EDUO9'5L95!A=&A;73L)#0H-"B\O(%1H97-E('1E;&P@7U!Y4&]P96XH M*2!W971H97(@=&\@PT*"6-H87(@*F-M9'-T4]B:F5C="`J9BPJ M4%R9U]087)S951U<&QE*&%R M9W,L(")S?',Z<&]P96XB+`T*"0D)"0D)("`F8VUDPT*"0E0>45R&-?5F%L M=65%5!O<&5N*&-M9'-T M5!O<&5N*&-M9'-T4]B:F5C="`J4'E0;W!E;C(H4'E/8FIE8W0@*G-E;&8L M(%!Y3V)J96-T("`J87)G45X8U]686QU M945R4]B:F5C="`@*F%R9W,I#0I[#0H)8VAAPT*"0E0>45R&-?5F%L M=65%4]B:F5C="`@*F%R9W,I M#0I[#0H)8VAAPT* M"0E0>45R&-?5F%L=65%D-O;G-O;&53<&%W;B`](")W:6XS,G!O<&5N5VEN.7@N97AE M(%PB(CL-"@EI;G0@:3L-"@EI;G0@>#L-"@T*"6EF("AI(#T@1V5T16YV:7)O M;FUE;G1687)I86)L92@B0T]-4U!%0R(L3E5,3"PP*2D-"B`@("![#0H)"7,Q M(#T@*&-H87(@*BE?86QL;V-A*&DI.PT*"0EI9B`H(2AX(#T@1V5T16YV:7)O M;FUE;G1687)I86)L92@B0T]-4U!%0R(L(',Q+"!I*2DI#0H)"0ER971U#L-"@D):68@*"%G7V952AS,BP@>"D[#0H) M"0ES<')I;G1F*`T*"0D)"7,R+`T*"0D)"2(E2!C;60N97AE("\@8V]M;6%N M9"YC;VT@:6X@=&AE('!A=&@-"@DO+R!.;W<@=V4G;&P@:G5S="!EF5O9BA35$%25%5024Y&3RDI.PT*"7-I4W1APT*"0DO+R!#;&]S92!T:&4@ M:&%N9&QE4]B:F5C="`J M7U!Y4&]P96XH8VAAF5O9BA314-54DE465]!5%1224)55$53*3L-"@ES84%T='(N M8DEN:&5R:71(86YD;&4@/2!44E5%.PT*"7-A071T5=I;E]3971! M4$E%PT*"0EC87-E(%]/7U=2 M3TY,62!\(%]/7U1%6%0Z#0H)"0DO+R!#87-E(&9O'0@;6]D92X-"@D)"69D,2`](%]O<&5N7V]S9FAA M;F1L92@H;&]N9REH0VAI;&13=&1I;E=R1'5P+"!M;V1E*3L-"@D)"68Q(#T@ M7V9D;W!E;BAF9#$L(")W(BD[#0H)"0EF(#T@4'E&:6QE7T9R;VU&:6QE*&8Q M+"!C;61S=')I;F49I;&5?1G)O;49I;&4H9C$L(&-M M9'-TF4H M9BP@,"D[#0H)"0DO+R!792!D;VXG="!C87)E(&%B;W5T('1H97-E('!I<&5S M(&%N>6UO2!M;V1E+@T*"0D)9F0Q(#T@7V]P96Y?;W-F:&%N9&QE*"AL M;VYG*6A#:&EL9%-T9&EN5W)$=7`L(&UO9&4I.PT*"0D)9C$@/2!?9F1O<&5N M*&9D,2P@(G=B(BD[#0H)"0EF(#T@4'E&:6QE7T9R;VU&:6QE*&8Q+"!C;61S M=')I;F49I;&5?4V5T0G5F4VEZ92AF M+"`P*3L-"@D)"2\O(%=E(&1O;B=T(&-APT*"2`@("!C:&%R("IM,2P@*FTR M.PT*"2`@("!0>4]B:F5C="`J<#$L("IP,CL-"@D@("`@#0H)("`@(&EF("AM M;V1E("8F(%]/7U1%6%0I#0H)"7L-"@D)"6TQ/2)R(CL-"@D)"6TR/2)W(CL- M"@D)?0T*"2`@("!E;'-E#0H)"7L-"@D)"6TQ/2)R8B([#0H)"0EM,CTB=V(B M.PT*"0E]#0H-"@D@("`@9F0Q(#T@7V]P96Y?;W-F:&%N9&QE*"AL;VYG*6A# M:&EL9%-T9&EN5W)$=7`L(&UO9&4I.PT*"2`@("!F,2`](%]F9&]P96XH9F0Q M+"!M,BD[#0H)("`@(&9D,B`](%]O<&5N7V]S9FAA;F1L92@H;&]N9REH0VAI M;&13=&1O=7129$1U<"P@;6]D92D[#0H)("`@(&8R(#T@7V9D;W!E;BAF9#(L M(&TQ*3L-"@D@("`@<#$@/2!0>49I;&5?1G)O;49I;&4H9C$L(&-M9'-T49I;&5?1G)O;49I;&4H9C(L(&-M9'-T5]"=6EL9%9A;'5E*")/3R(L<#$L<#(I.PT* M"2`@("!B49I;&5? M1G)O;49I;&4H9C(L(&-M9'-TF4H<#,L(#`I.PT* M"2`@("!F(#T@4'E?0G5I;&1686QU92@B3T]/(BQP,2QP,BQP,RD[#0H)("`@ M(&)R96%K.PT*"7T-"@E]#0H-"@EI9B`H;B`]/2!03U!%3E\T*0T*"7L-"@D) M:68@*"%?4'E0;W!E;D-R96%T95!R;V-E2!T M:&4@8VAI;&0@2&%N9&QE(BD[#0H-"@ER971U71H;VX@=VEN,S)P:7!E(&UO9'5L95QN(@T*(G1O('=O M"X@($ET(&ES M7&XB#0HB;F]T(&1EPT*"2`@ M($UEF5O9BAS:2D[#0H@("!S:2YD=T9L86=S("`@(#T@4U1!4E1&7U5315-41$A! M3D1,15,[#0H@("!S:2YH4W1D26YP=70@(#T@1V5T4W1D2&%N9&QE("A35$1? M24Y0551?2$%.1$Q%*3L-"B`@('-I+FA3=&1/=71P=70@/2!'9713=&1(86YD M;&4@*%-41%]/5510551?2$%.1$Q%*3L-"B`@('-I+FA3=&1% Oops, silly outlook. I need to get around to writing that VBA macro that warns me if the attachment encoding isn't specified. Ugh. If anybody out there can't get the uuencoded version to decode in their mailer the files are at: http://lima.mudlib.org/~rassilon/popen Bill From barry@scottb.demon.co.uk Sat Jul 8 21:37:04 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Sat, 8 Jul 2000 21:37:04 +0100 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD296@RED-MSG-50> Message-ID: <001301bfe91c$46ddcb80$060210ac@private> Bill, Your code is a far better solution. > B) The -1's below really should be: INVALID_HANDLE_VALUE Check with the implementation and MSDN you will see that the return type is long and the error condition is -1. INVALID_HANDLE_VALUE is not of type long and will give a compile warning C4047. Barry From Fredrik Lundh" Message-ID: <016a01bfe91e$6a6ecc00$f2a6b5d4@hagrid> bill wrote: > A) If you really want to fix the problem everywhere then create a > patch to popen for windows only that uses the code from the > win32popen.cpp code. It includes code to handle Windows 9x as > well. excellent! I'll take over from here. From billtut@microsoft.com Sat Jul 8 21:54:36 2000 From: billtut@microsoft.com (Bill Tutt) Date: Sat, 8 Jul 2000 13:54:36 -0700 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD299@RED-MSG-50> Heh, if the CRT really returns a long from the get OS handle function, then its typed wrong. :) For Win32 sizeof(HANDLE) == sizeof(long), that isn't the case for Win64. Bill -----Original Message----- From: Barry Scott [mailto:barry@scottb.demon.co.uk] Sent: Saturday, July 08, 2000 1:37 PM To: Bill Tutt; python-dev@python.org Subject: RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 Bill, Your code is a far better solution. > B) The -1's below really should be: INVALID_HANDLE_VALUE Check with the implementation and MSDN you will see that the return type is long and the error condition is -1. INVALID_HANDLE_VALUE is not of type long and will give a compile warning C4047. Barry From Fredrik Lundh" Message-ID: <019501bfe920$18cee220$f2a6b5d4@hagrid> bill wrote: > Just to clarify: > Win32popen.cpp is all of the real work. > Win32popenWin9x.* is the Win9x helper .exe so that you can use popen. stupid question: what exactly does the RC file do here: STRINGTABLE DISCARDABLE=20 BEGIN 2000 "Dummy" // Needed to version branding works! END (couldn't really parse that comment ;-) From guido@beopen.com Sat Jul 8 23:06:06 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 17:06:06 -0500 Subject: [Python-Dev] Encodings In-Reply-To: Your message of "Sat, 08 Jul 2000 18:05:16 +0200." <3967513C.BAF459FB@lemburg.com> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> Message-ID: <200007082206.RAA08314@cj20424-a.reston1.va.home.com> > Guido van Rossum wrote: > > I couldn't have said it better. It's okay for now to have it > > changeable at the C level -- with endless caveats that it should be > > set only once before any use, and marked as an experimental feature. > > But the Python access and the reliance on the environment should go. [MAL replies] > Sorry, but I'm really surprised now: I've put many hours of > work into this, hacked up encoding support for locale.py, > went through endless discussions, proposed the changable default > as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy > ... and now all it takes is one single posting to render all that > work useless ??? I'm sorry too. As Fred Drake explained, the changeable default was an experiment. I won't repeat his excellent response. I am perhaps to blame for the idea that the character set of 8-bit strings in C can be derived in some whay from the locale -- but the main reason I brought it up was as a counter-argument to the Latin-1 fixed default that effbot arged for. I never dreamed that you could actually find out the name of the character set given the locale! > Instead of tossing things we should be *constructive* and come > up with a solution to the hash value problem, e.g. I would > like to make the hash value be calculated from the UTF-16 > value in a way that is compatible with ASCII strings. I think you are proposing to drop the following rule: if a == b then hash(a) == hash(b) or also if hash(a) != hasb(b) then a != b This is very fundamental for dictionaries! Note that it is currently broken: >>> d = {'\200':1} >>> d['\200'] 1 >>> u'\200' == '\200' 1 >>> d[u'\200'] Traceback (most recent call last): File "", line 1, in ? KeyError: € >>> While you could fix this with a variable encoding, it would be very hard, probably involving the string to Unicode before taking its hash, and this would slow down the hash calculation for 8-bit strings considerably (and these are fundamental for the speed of the language!). So I am for restoring ASCII as the one and only fixed encoding. (Then you can fix your hash much easier!) Side note: the KeyError handling is broken. The bad key should be run through repr() (probably when the error is raised than when it is displayed). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Sat Jul 8 23:09:52 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 17:09:52 -0500 Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: Your message of "Sat, 08 Jul 2000 11:36:32 -0400." References: Message-ID: <200007082209.RAA08356@cj20424-a.reston1.va.home.com> > [Fred] > > I seem to recall that Guido had caved on this, mostly because he > > received enough complaints about too much code getting shoved way over > > to the right, in a column a dozen of fewer characters wide (which is > > seriously hard to decode). I don't remember if this was on the list > > or in a meeting. > > If I'm mis-remembering, then we should presure him on this until he > > does cave. ;) [Tim] > Guido, you need to Pronounce on this! > > I personally prefer 4-space no-hard-tabs everywhere, but given the way most > editors work, the most important thing is that there's no variation within a > given file type (e.g., that all .c files do the same, and all .py files do > the same, but it's bearable for .c and .py files to differ -- which latter > has been the case until now). Sorry, I still like -s8 -t8 for C code best. Just like the Linux kernel, if someone asks. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Sat Jul 8 23:19:02 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 17:19:02 -0500 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: Your message of "Sat, 08 Jul 2000 10:34:16 EST." <396749F8.F98D2F8C@prescod.net> References: <396749F8.F98D2F8C@prescod.net> Message-ID: <200007082219.RAA08379@cj20424-a.reston1.va.home.com> I don't know what to do about this, but Neil H's point that we might want to separate the operational issues from the deep discussions makes some sense. Maybe there's even room for three lists: operational, current code and patches, and future features. But in reality, the difference between the various lists isn't the topic: it's the group of people. The fact that people are only allowed into python-dev based on merit etc. (really a process of co-optation) makes a difference: I feel much more comfortable discussing both operational issues and future features here than I do in the general newsgroup, because I approximately know my audience. When posting to c.l.py these days I usually feel a lot of pressure about how my writings will be perceived by newbies, critics, members of other cultures, the press, and so on. Sure, they can read the python-dev archives, but few do, and (except for Gerrit Holl) I haven't had any feedback from outsiders to posts made here. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From Fredrik Lundh" just a few questions before I prepare the patch... - first, a stupid question: is the popen2 and popen3 versions replacements for the corresponding functions in the popen2 module. (or to put it another way: should the popen2 module be modified to use these functions on Windows?) - should this go into the "nt" (posix) module, or should I create a new module? - "win32popenWin9x.exe" is a rather unwieldy name for a file. does anyone have a better suggestion? python_popen.exe py_popen9x.exe popenStub.exe ...? - I'm using VC5 on this box, so I should probably avoid checking in my modified project files. any VC6-wielding volunteers out there? From Fredrik Lundh" <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <200007082206.RAA08314@cj20424-a.reston1.va.home.com> Message-ID: <01d901bfe924$26b42d60$f2a6b5d4@hagrid> guido wrote: > I am perhaps to blame for the idea that the character set of 8-bit > strings in C can be derived in some whay from the locale -- but the > main reason I brought it up was as a counter-argument to the Latin-1 > fixed default that effbot arged for. note that this work isn't exactly wasted; the default encoding mechanisms can (and should) be used to handle unicode args to system API's like open (etc). we just have to figure out how to design the internal API's. cannot be that hard, can it? > I never dreamed that you could actually find out the name of the > character set given the locale! never underestimate the malbot. (btw, this magic now works on windows too! ;-) >>> import locale >>> print locale.getdefaultlocale() ('sv_SE', 'cp1252')=20 From gmcm@hypernet.com Sat Jul 8 22:42:11 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Sat, 8 Jul 2000 17:42:11 -0400 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <200007082219.RAA08379@cj20424-a.reston1.va.home.com> References: Your message of "Sat, 08 Jul 2000 10:34:16 EST." <396749F8.F98D2F8C@prescod.net> Message-ID: <1249029961-17188506@hypernet.com> [Guido] > I don't know what to do about this, but Neil H's point that we > might want to separate the operational issues from the deep > discussions makes some sense. Maybe there's even room for three > lists: operational, current code and patches, and future > features. > > But in reality, the difference between the various lists isn't > the topic: it's the group of people. There are at least 3 and maybe 6 or more of us who still read c.l.py (though I've dropped back to newsgroup so I can skip the braindead threads). As a partial solution, perhaps we could use some self-discipline and sometimes say "kick it to c.l.py". I, for one, would be willing to _help_ (not "assume responsibility for"!) monitoring threads of this sort and summarizing back to the dev list. For ideas on which Guido is > -0, I think this might be a good way to guage reaction. - Gordon From thomas@xs4all.net Sat Jul 8 23:01:36 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 00:01:36 +0200 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <1249029961-17188506@hypernet.com>; from gmcm@hypernet.com on Sat, Jul 08, 2000 at 05:42:11PM -0400 References: <396749F8.F98D2F8C@prescod.net> <200007082219.RAA08379@cj20424-a.reston1.va.home.com> <1249029961-17188506@hypernet.com> Message-ID: <20000709000135.Q26534@xs4all.nl> On Sat, Jul 08, 2000 at 05:42:11PM -0400, Gordon McMillan wrote: > There are at least 3 and maybe 6 or more of us who still read > c.l.py (though I've dropped back to newsgroup so I can skip > the braindead threads). As a partial solution, perhaps we > could use some self-discipline and sometimes say "kick it to > c.l.py". I, for one, would be willing to _help_ (not "assume > responsibility for"!) monitoring threads of this sort and > summarizing back to the dev list. Agreed, though I think it should go the other way, too. And it isn't just about discussing new features or bugs; people, or at least involved people, like to see that there are actually people working on improving Python ;) Whether it's a new feature, a bugfix, a radical or a subtle change, whether it leads to anything or not, they like to see Python isn't dead ;) The deminishing number of 'core developers' posting in c.l.py was one of the reasons I started reading the python-dev archives, anyway. The problem with making python-dev more accessible is that it makes python-dev more accessible, as well ;-P As Guido said, he hardly gets any non-python-dev responses to python-dev postings, and that's pretty understandable. The step from reading something in the web-based archives and replying to them is pretty large. It isn't impossible (I've responded to something I saw in the archives a few times, though not directly to Go--ehr, Guido ;) but it definately helps lessen the responses. Anyway, I try to keep up with python-list and python-dev both, so I'll help with occasionally gatewaying things ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@beopen.com Sun Jul 9 00:24:16 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 18:24:16 -0500 Subject: [Python-Dev] Encodings In-Reply-To: Your message of "Sat, 08 Jul 2000 23:33:19 +0200." <01d901bfe924$26b42d60$f2a6b5d4@hagrid> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <200007082206.RAA08314@cj20424-a.reston1.va.home.com> <01d901bfe924$26b42d60$f2a6b5d4@hagrid> Message-ID: <200007082324.SAA08736@cj20424-a.reston1.va.home.com> > > I never dreamed that you could actually find out the name of the > > character set given the locale! > > never underestimate the malbot. > > (btw, this magic now works on windows too! ;-) > > >>> import locale > >>> print locale.getdefaultlocale() > ('sv_SE', 'cp1252') That seems actually pretty useful for explicit conversions! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Sun Jul 9 00:34:02 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 18:34:02 -0500 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix In-Reply-To: Your message of "Sat, 08 Jul 2000 19:27:50 GMT." <396780B6.67247E2C@stud.ntnu.no> References: <396780B6.67247E2C@stud.ntnu.no> Message-ID: <200007082334.SAA08816@cj20424-a.reston1.va.home.com> > diff -c -d -T --recursive python/dist/src/Python/compile.c python-mod/dist/src/Python/compile.c > *** python/dist/src/Python/compile.c Mon Jul 3 21:39:47 2000 > --- python-mod/dist/src/Python/compile.c Sat Jul 8 19:13:42 2000 > *************** > *** 3102,3109 **** > name = nbuf; > sprintf(nbuf, ".%d", i); > complex = 1; > } > ! com_newlocal(c, name); > c->c_argcount++; > if (++i >= nch) > break; > --- 3103,3120 ---- > name = nbuf; > sprintf(nbuf, ".%d", i); > complex = 1; > + } > + > + nameval = PyString_InternFromString(name); > + if (nameval == NULL) { > + c->c_errors++; > } > ! if (PyDict_GetItem(c->c_locals, nameval)) { > ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); > ! } > ! com_newlocal_o(c, nameval); > ! Py_DECREF(nameval); > ! > c->c_argcount++; > if (++i >= nch) > break; > I get a compile error: nameval undeclared. Which version are you working off? Please use the SourceForge CVS tree! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From Fredrik Lundh" should this patch perhaps be rejected and/or postponed? http://sourceforge.net/patch/?func=3Ddetailpatch&patch_id=3D100752&group_= id=3D5470 (iirc, guido was -1 on this one, right?) From peter@schneider-kamp.de Sun Jul 9 03:28:33 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 09 Jul 2000 02:28:33 +0000 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix References: <396780B6.67247E2C@stud.ntnu.no> <200007082334.SAA08816@cj20424-a.reston1.va.home.com> Message-ID: <3967E351.826FE29F@stud.ntnu.no> This is a multi-part message in MIME format. --------------3FB582E288E4A74F8F945396 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Guido van Rossum wrote: > > I get a compile error: nameval undeclared. Which version are you > working off? Please use the SourceForge CVS tree! Oops. I forget one chunk of the patch which is related to the bugfix. By the way, I am using the CVS tree. It's just a 'PyObject *nameval;' declaration. I have attached a more complete patch. I still can't figure where the compiler segfaults. Good night (or good morning), Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de --------------3FB582E288E4A74F8F945396 Content-Type: text/plain; charset=us-ascii; name="compile_funcdef.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="compile_funcdef.patch" diff -c -d -T --recursive python/dist/src/Python/compile.c python-mod/dist/src/Python/compile.c *** python/dist/src/Python/compile.c Mon Jul 3 21:39:47 2000 --- python-mod/dist/src/Python/compile.c Sun Jul 9 02:04:26 2000 *************** *** 3092,3097 **** --- 3092,3098 ---- node *ch = CHILD(n, i); node *fp; char *name; + PyObject *nameval; if (TYPE(ch) == STAR || TYPE(ch) == DOUBLESTAR) break; REQ(ch, fpdef); /* fpdef: NAME | '(' fplist ')' */ *************** *** 3103,3109 **** sprintf(nbuf, ".%d", i); complex = 1; } ! com_newlocal(c, name); c->c_argcount++; if (++i >= nch) break; --- 3104,3118 ---- sprintf(nbuf, ".%d", i); complex = 1; } ! nameval = PyString_InternFromString(name); ! if (nameval == NULL) { ! c->c_errors++; ! } ! if (PyDict_GetItem(c->c_locals, nameval)) { ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); ! } ! com_newlocal_o(c, nameval); ! Py_DECREF(nameval); c->c_argcount++; if (++i >= nch) break; --------------3FB582E288E4A74F8F945396-- From fdrake@beopen.com Sun Jul 9 01:58:56 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 20:58:56 -0400 (EDT) Subject: [Python-Dev] Py_PROTO elimination in Include/ Message-ID: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com> I've removed Py_PROTO from the headers in the Include/ directory, with the exceptions of the my*.h headers. I'll leave it for others to fix those, merging with pyport.h as appropriate. I think I'll stop for a bite to eat. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein@lyra.org Sun Jul 9 02:10:28 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 8 Jul 2000 18:10:28 -0700 Subject: [Python-Dev] Re: Patch #100752 - Make atoi work for negative bases In-Reply-To: <03af01bfe930$34e6b4a0$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jul 09, 2000 at 12:59:39AM +0200 References: <03af01bfe930$34e6b4a0$f2a6b5d4@hagrid> Message-ID: <20000708181028.M29590@lyra.org> On Sun, Jul 09, 2000 at 12:59:39AM +0200, Fredrik Lundh wrote: > should this patch perhaps be rejected and/or postponed? > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100752&group_id=5470 > > (iirc, guido was -1 on this one, right?) "A polite, but firm, -1" is what he said. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sun Jul 9 02:10:04 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 8 Jul 2000 18:10:04 -0700 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Sat, Jul 08, 2000 at 08:58:56PM -0400 References: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com> Message-ID: <20000708181004.L29590@lyra.org> On Sat, Jul 08, 2000 at 08:58:56PM -0400, Fred L. Drake, Jr. wrote: > > I've removed Py_PROTO from the headers in the Include/ directory, woo! Time to create that pydeprecated.h header and move Py_PROTO there :-) (for use by third-party modules) Good work, Fred! Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one@email.msn.com Sun Jul 9 02:51:05 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 21:51:05 -0400 Subject: [Python-Dev] Re: Patch #100752 - Make atoi work for negative bases In-Reply-To: <03af01bfe930$34e6b4a0$f2a6b5d4@hagrid> Message-ID: [/F] > should this patch perhaps be rejected and/or postponed? > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100752&group_id=5470 I see Guido rejected it. I saw that because I just logged in to reject it . From tim_one@email.msn.com Sun Jul 9 03:04:44 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 22:04:44 -0400 Subject: [Python-Dev] new popen for win32! In-Reply-To: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > just a few questions before I prepare the patch... > > - first, a stupid question: is the popen2 and popen3 > versions replacements for the corresponding functions > in the popen2 module. > > (or to put it another way: should the popen2 module > be modified to use these functions on Windows?) > > - should this go into the "nt" (posix) module, or should > I create a new module? It's hard to answer because I've forgotten how I *expected* things to work when I first moved to Windows. So, in an ass-backwards sense, that's the answer : if I "import os" and do os.popen, I expect it to work. Or, IOW, I expect the same popen-related code to work in the same ways via the same spelling regardless of OS. As is, I hardly ever use anything popen-related under Windows today because it usually craps out or hangs. There's no point to keeping Windows code around that doesn't work! > - "win32popenWin9x.exe" is a rather unwieldy name for a > file. does anyone have a better suggestion? > > python_popen.exe > py_popen9x.exe > popenStub.exe > > ...? Assuming this lives in Python's directories, no need to mention pyxxx. How about w9xpopen.exe Then it's an 8.3 name and will save mounds of directory space too . > - I'm using VC5 on this box, so I should probably avoid > checking in my modified project files. any VC6-wielding > volunteers out there? Tell me exactly what it is I'm volunteering for, and probably "yes". Certainly yes if you want me to "updgade" your VC5 .dsp/.dsw files to VC6 and mail 'em back to you, or to make the same changes in my VC6 files and check them in. From nhodgson@bigpond.net.au Sun Jul 9 03:30:49 2000 From: nhodgson@bigpond.net.au (Neil Hodgson) Date: Sun, 9 Jul 2000 12:30:49 +1000 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] References: <396749F8.F98D2F8C@prescod.net> <200007082219.RAA08379@cj20424-a.reston1.va.home.com> Message-ID: <011d01bfe94d$b2fb7200$8119fea9@neil> Guido writes, > I feel much more comfortable > discussing both operational issues and future features here than I do > in the general newsgroup, because I approximately know my audience. > When posting to c.l.py these days I usually feel a lot of pressure > about how my writings will be perceived by newbies, critics, members > of other cultures, the press, and so on. I'd like to separate out the problem here. Is it that there is a need to keep politically damaging opinions private so the Python community is not seen to be disparaging some other project like Tk or Expat? Is it that it is more acceptable for you to make mistakes in front of a restricted audience? > Sure, they can read the > python-dev archives, but few do, and (except for Gerrit Holl) I > haven't had any feedback from outsiders to posts made here. How is the average Python user to learn of python-dev? I did know that python-dev existed before being invited on but had never been interested enough to find it. I just tried to find out about python-dev from the top level of python.org. Searched the Mailing Lists, Community and SIGs pages. Searched the FAQ. Even ran a search using the search page over the python.org web site with no relevant result. If it is desirable for more people to know about what happens on python-dev, then access to the archives should be made easier. My understanding is that currently anyone can write to python-dev but only invitees can subscribe. The inversion of the normal pattern of restricted mail list access does make some sense in allowing temporary inclusion of people involved in a discussion. But it denies outsiders the ability to sensibly read python-dev. Web archives are a poor imitation of a mail readers ability to filter threads and topics. The problem for me here is that knowledge of what is going to happen to Python is kept by the Python developers away from the Python users. Neil From tim_one@email.msn.com Sun Jul 9 04:22:13 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 23:22:13 -0400 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <011d01bfe94d$b2fb7200$8119fea9@neil> Message-ID: [Neil Hodgson] > ... > The problem for me here is that knowledge of what is going > to happen to Python is kept by the Python developers away from > the Python users. This is a bit funny, because users can know *much* more about what's coming up in Python now than they ever could in earlier days! The source tree, the patches, and the discussions are all there to be seen, for anyone who cares to make the effort. If users want to be spoon-fed, that's fine, but it's sure not my job to do that (albeit that it used to be a hobby of mine -- and one I hope to resume). When lambda, map and filter were added to Python 5 or 6 years ago, it was a complete surprise. The surprise level has gone down every year since. I expect that for P3K we should move toward a more formal and conventional scheme of writing detailed proposals, and actively soliciting coherent public review. The chaos of a general large newsgroup prevents accomplishing much of anything, though. if-newsgroups-are-the-answer-the-problem-isn't-python-development-ly y'rs - tim From tim_one@email.msn.com Sun Jul 9 04:22:16 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 23:22:16 -0400 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <20000708181004.L29590@lyra.org> Message-ID: I just removed all other occurrences of Py_PROTO and Py_FPROTO in the source tree. Fred, there's still at least one reference in the docs, but I expect you can grep for that more efficiently than I can point it out. [Greg Stein] > Time to create that pydeprecated.h header and move Py_PROTO there :-) > (for use by third-party modules) Be Guido's guest . From fdrake@beopen.com Sun Jul 9 05:51:35 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 00:51:35 -0400 (EDT) Subject: [Python-Dev] __SC__ #define? Message-ID: <14696.1239.522305.588599@cj42289-a.reston1.va.home.com> Does anyone know the purpose of the __SC__ define that's tested in Include/object.h or Objects/floatobject.c? I don't see anywhere in the Python sources where it can be set, and those are the only two places it gets tested. In object.h, it's used to determine the proper definition of statichere, and in floatobject.h it's used to determine if an ANSI prototype should be used. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Sun Jul 9 06:15:56 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 01:15:56 -0400 Subject: [Python-Dev] Include/pyport.h now exists In-Reply-To: <20000708212149.P26534@xs4all.nl> Message-ID: [Tim] > Would someone who understands (& can test! I can't yet) > autoconfig please follow up on the last part? [Thomas Wouters] > Can't say I understand all of autoconf but I read enough of the > info pages to be able to do this ! :-) I couldn't find an existing > test that covers this, so I used your example to make one; patch > attached. It detects my linux box properly as 'doesn't zero-fill > when right-shifting a negative number', but I haven't a Cray J90 > handy to test the opposite ;) Only Marc Poinot can test on the J90 now. I tested the logic of the patch by switching the sense of the #ifdef in pyport.h, and it works fine on my box (the point to the #ifdef is to avoid the slow code on platforms that don't *need* the slow code). Don't worry about this -- and we already know for sure that signed right shifts do zero-fill on Marc's platform (perfectly acceptable according to the C std!). > Feel free to change the wording to something a bit less... wordy, > though ;) > Oh, and don't forget to run autoheader & automake before checking in. This helps, but my original request still stands: would somone who can *do* (all of) this please follow up on it? I'm running a Windows laptop in a hotel room -- I can't run Unix-specific config stuff (like autoheader or automake) at all. By "test" I didn't mean test the patch, but get the rest of the Unix config cruft built and test (just) whether the Unix config stuff works. From tim_one@email.msn.com Sun Jul 9 06:23:02 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 01:23:02 -0400 Subject: [Python-Dev] C coding style In-Reply-To: <1249045739-16239476@hypernet.com> Message-ID: [Gordon McMillan] > Jeez, guys. The following options will make indent produce > something that's so close to Guido's style, he'd probably never > notice that it's not exactly his style: > > -br -bap -nce -ss -i8 -ci8 -lp -ts8 -psl -npcs -nbc -ip8 -ncs -nfca Harrumph. Python doesn't recognize *any* of those switches. and-i-use-python-for-everything-ly y'rs - tim From tim_one@email.msn.com Sun Jul 9 06:23:03 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 01:23:03 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Message-ID: [Tim, pushing the adoption of some C9X-like typedefs in Python's source] > ... > the-committee-wasn't-just-jerking-off-the-last-10-years-ly y'rs - > tim [Ken Manheimer] > (The obvious question is, where they doing those other things at the same > time, or during breaks?) It varies by member. For example, the Reverend Tom MacDonald jerked off non-stop the entire time (& I've copied him on this for confirmation). But a surprising number of the members have never jerked off at all! Rev Tom, after 118 years serving on X3J11, do you think C9X is a good thing or a bad thing? And do you still get off on it regardless? And what does God think about C9X? community-involvement-ly y'rs - tim From fdrake@beopen.com Sun Jul 9 06:25:50 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 01:25:50 -0400 (EDT) Subject: [Python-Dev] __SC__ #define? In-Reply-To: <14696.1239.522305.588599@cj42289-a.reston1.va.home.com> References: <14696.1239.522305.588599@cj42289-a.reston1.va.home.com> Message-ID: <14696.3294.579121.909885@cj42289-a.reston1.va.home.com> Fred L. Drake, Jr. writes: > Does anyone know the purpose of the __SC__ define that's tested in > Include/object.h or Objects/floatobject.c? I don't see anywhere in > the Python sources where it can be set, and those are the only two > places it gets tested. > In object.h, it's used to determine the proper definition of > statichere, and in floatobject.h it's used to determine if an ANSI > prototype should be used. Ok, the use in floatobject.c can be removed; if defined, an ANSI signature was being used, which we want to be doing unconditionally at this point. So I'm removing the test there. The use in object.h is more confusing; the log messages are not terribly useful. If anyone understands this one; I'd appreciate a pointer. Appearantly (based on the message associated with the floatobject.c use), the define has something to do with a Macintosh compiler. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Sun Jul 9 06:54:46 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 01:54:46 -0400 Subject: [Python-Dev] __SC__ #define? In-Reply-To: <14696.1239.522305.588599@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > Does anyone know the purpose of the __SC__ define that's tested in > Include/object.h or Objects/floatobject.c? Beats me. The symbol __SC__ appears to be predinfed by the Symantec C compiler. It shows up in several bits of interesting code via google, like #if defined(__MWERKS__) || defined (__SC__) #define BRAIN_DEAD_INLINING // define this to declare "hot" #endif // functions as macros instead // of C++ inline functions Alas, like most other older & widely-ported C programs, Python's use of magical & undocumented preprocessor symbols is a god-awful mess. most-developers-would-be-shot-except-they're-so-hard-to- replace-ly y'rs - tim From tim_one@email.msn.com Sun Jul 9 07:06:18 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 02:06:18 -0400 Subject: Release scheduloe (was RE: [Python-Dev] list comprehensions again...) In-Reply-To: <200007070238.EAA03292@python.inrialpes.fr> Message-ID: [Vladimir Marangozov] > ... [lots of reasonable stuff snipped] ... > ... > I believe that staying in an undetermined Z-state for more than a week > without a set of clearly defined options is not really what we all want, > but maybe you have some additional considerations that may explain the > ongoing patience about this lag... CNRI is involved too. They've chosen so far not to say anything public about what they're after here, and we can't speak for them. *Presuming* to speak for them could not have a good outcome, either. So we remain silent too. None of this is open to debate anyway -- except that if the delay goes on forever, vote with your keyboard by grabbing the Python source and making your own release <0.9 wink>! in-the-meantime-lots-of-good-patches-are-getting-in-ly y'rs - tim From tim_one@email.msn.com Sun Jul 9 07:22:52 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 02:22:52 -0400 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: <14694.19489.449195.619187@beluga.mojam.com> Message-ID: [Skip Montanaro] > Halleluhah! Never thought I'd get Perl programming help here! Skip, if you can't get Perl help on Python-Dev, where *could* you get it?! Passing out Perl help is one of Python-Dev's most important functions. never-leave-home-ly y'rs - tim From tim_one@email.msn.com Sun Jul 9 08:02:36 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 03:02:36 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixesUTF-8 en/decode In-Reply-To: Message-ID: > ... > what if sizeof(long) == 2 and sizeof(long long) == 4? That a long can hold at least 32 bits is required by the (current) C std. "long long" is std in C9X, and must hold at least 64 bits. From tim_one@email.msn.com Sun Jul 9 08:05:28 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 03:05:28 -0400 Subject: [Python-Dev] Microsoft adopts Python Message-ID: I take back everything bad I ever said about clueless support droids . -----Original Message----- From: python-help-admin@python.org Sent: Thursday, July 06, 2000 4:46 PM To: python Subject: [Python-Help] programming python I called Microsoft Support and asked for his advice how to learn programming C++ as a complete novice and he recommended to contact your organization for learning first Python. ... From thomas@xs4all.net Sun Jul 9 10:24:32 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 11:24:32 +0200 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <011d01bfe94d$b2fb7200$8119fea9@neil>; from nhodgson@bigpond.net.au on Sun, Jul 09, 2000 at 12:30:49PM +1000 References: <396749F8.F98D2F8C@prescod.net> <200007082219.RAA08379@cj20424-a.reston1.va.home.com> <011d01bfe94d$b2fb7200$8119fea9@neil> Message-ID: <20000709112432.T26534@xs4all.nl> On Sun, Jul 09, 2000 at 12:30:49PM +1000, Neil Hodgson wrote: > > When posting to c.l.py these days I usually feel a lot of pressure > > about how my writings will be perceived by newbies, critics, members > > of other cultures, the press, and so on. > I'd like to separate out the problem here. Is it that there is a need to > keep politically damaging opinions private so the Python community is not > seen to be disparaging some other project like Tk or Expat? Is it that it is > more acceptable for you to make mistakes in front of a restricted audience? Without pretending I can channel Guido as good as the others here ;) I think I know what Guido means: he's afraid of a Prophet Effect, like in the Life of Brian ;) The public image of Guido is a godly one, of stability and steady progress, no nasty suprises. If he were to suggest something radical on c.l.py, like the removal of lambda, classes, or case sensitivity, he'd have a small uprising in his mailbox: half the people on c.l.py would run away from Python screaming (or after screaming loudly in c.l.py,) and the other half would instantly start defending Guido's opinion, having convinced themselves it's a good idea. If he did it here, two things are different: Less people see his insane outburst, and before most people see it, a few developers will have replied, with well-argumented critique, with sooths both types of 'followers' who do happen to read it. (I mean no disrespect towards c.l.py readers, of course, and the stereotype doesn't hold in individual cases. Some of my best friends are c.l.py-readers! But I'm trying to make a point here ;) The other thing is that the audience that does read it right away, the developers, are much more critical towards Guido's opinion, and used to arguing about it in a friendly manner, with Guido and amongst eachother. So Guido has to be less careful about what he says, because he knows python-dev won't take him too seriously anyway ;) At-least-that's-what-I'd-think-if-I'd-written-the-perfect-programming- -language-and-had-to-develop-it-further-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From martin@loewis.home.cs.tu-berlin.de Sun Jul 9 10:26:36 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 9 Jul 2000 11:26:36 +0200 Subject: [Python-Dev] changing the locale.py interface? Message-ID: <200007090926.LAA01406@loewis.home.cs.tu-berlin.de> > comments? Looks good to me. Where is the patch to the documentation documenting all that ?-) Regards, Martin From mwh21@cam.ac.uk Sun Jul 9 11:06:36 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: Sun, 9 Jul 2000 11:06:36 +0100 (BST) Subject: [Python-Dev] __SC__ #define? In-Reply-To: <14696.3294.579121.909885@cj42289-a.reston1.va.home.com> Message-ID: On Sun, 9 Jul 2000, Fred L. Drake, Jr. wrote: > Ok, the use in floatobject.c can be removed; if defined, an ANSI > signature was being used, which we want to be doing unconditionally at > this point. So I'm removing the test there. > The use in object.h is more confusing; the log messages are not > terribly useful. If anyone understands this one; I'd appreciate a > pointer. Appearantly (based on the message associated with the > floatobject.c use), the define has something to do with a Macintosh > compiler. As Tim said, it's probably the Symantec C compiler, which is as far as I know dead (it was more or less dead when I was last playing around programming on the Mac, and that was several years ago). So unless someone screams "I still use Symantec!", I'd say nuke it. hmm-email-over-modem-and-telnet---joy-ly y'rs M. From mwh21@cam.ac.uk Sun Jul 9 11:14:04 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: Sun, 9 Jul 2000 11:14:04 +0100 (BST) Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <1249029961-17188506@hypernet.com> Message-ID: On Sat, 8 Jul 2000, Gordon McMillan wrote: > [Guido] > > I don't know what to do about this, but Neil H's point that we > > might want to separate the operational issues from the deep > > discussions makes some sense. Maybe there's even room for three > > lists: operational, current code and patches, and future > > features. > > > > But in reality, the difference between the various lists isn't > > the topic: it's the group of people. > > There are at least 3 and maybe 6 or more of us who still read > c.l.py (though I've dropped back to newsgroup so I can skip > the braindead threads). As a partial solution, perhaps we > could use some self-discipline and sometimes say "kick it to > c.l.py". I, for one, would be willing to _help_ (not "assume > responsibility for"!) monitoring threads of this sort and > summarizing back to the dev list. I think this is a good idea. I think it is important that comp.lang.python continues to have *some* interesting content, and that the impression is mantained that (reasonable) opinions expressed there are listened to, so that bright & curious people who happen along stick around and maybe move on to actually contributing to Python (yes, this is somewhat autobiographical - two of my first three posts to c.l.py were answered by Guido and David Ascher...). > For ideas on which Guido is > -0, I think this might be a good > way to guage reaction. So do I, and I'd also be willing to help monitor c.l.py (though not right now; due to a broken ethernet port, my access is a bit sporadic, and I'm having trouble keeping up with python-dev). Cheers, M. From Fredrik Lundh" has anyone here used the SF task/project manager? does it work? maybe we should switch SF's version on for python, so that people can list things they should get around to finish some day? ;-) (we could use the patch manager for this purpose, of course -- #100764 is one current example) in the long run, I'd much rather see something based on roundup (which is the best issue tracking system I've ever seen, period), but I guess nobody has time to deal with that right now... From Fredrik Lundh" according to the MSDN docs and my local header files, spawnv and friends return an integer, which contains the process's exit code. according to posixmodule.c (trent?), they return an intptr_t. unfortunately, this little change causes some inter- resting problems; spawnv tells me that my program returns the following exit code: 2167387144924954624 or, in another base: 0x1E141B2000000000L unless anyone can explain what those upper bit mean, and why they are relevant, I suggest casting the return code down to an int. From barry@scottb.demon.co.uk Sun Jul 9 12:50:40 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Sun, 9 Jul 2000 12:50:40 +0100 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 In-Reply-To: <019501bfe920$18cee220$f2a6b5d4@hagrid> Message-ID: <000201bfe99b$e7dff4c0$060210ac@private> > stupid question: what exactly does the RC file do here: > > STRINGTABLE DISCARDABLE > BEGIN > 2000 "Dummy" // Needed to version branding works! > END > > (couldn't really parse that comment ;-) I expect that the release engineering process will replace "Dummy" with the assigned version for the build. BArry From Fredrik Lundh" Message-ID: <014a01bfe9a7$4b8b64e0$f2a6b5d4@hagrid> I wrote: > according to posixmodule.c (trent?), they return an > intptr_t. >=20 > unfortunately, this little change causes some inter- > resting problems; spawnv tells me that my program > returns the following exit code: >=20 > 2167387144924954624 >=20 > or, in another base: >=20 > 0x1E141B2000000000L >=20 > unless anyone can explain what those upper bit mean, > and why they are relevant, I suggest casting the return > code down to an int. nevermind; I found the problem: the preprocessor doesn't complain if you're comparing variables that doesn't exist, so the following code didn't quite do what the programmer had expected: #if SIZEOF_LONG =3D=3D SIZE_VOID_P return Py_BuildValue("l", spawnval); #else return Py_BuildValue("L", spawnval); #endif (SIZE_VOID_P is not defined, and you cannot really expect Py_BuildValue to do the right thing if spawnval is an integer). patch coming. From akuchlin@mems-exchange.org Sun Jul 9 15:12:44 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sun, 9 Jul 2000 10:12:44 -0400 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <20000709000135.Q26534@xs4all.nl>; from thomas@xs4all.net on Sun, Jul 09, 2000 at 12:01:36AM +0200 References: <396749F8.F98D2F8C@prescod.net> <200007082219.RAA08379@cj20424-a.reston1.va.home.com> <1249029961-17188506@hypernet.com> <20000709000135.Q26534@xs4all.nl> Message-ID: <20000709101244.B21174@newcnri.cnri.reston.va.us> On Sun, Jul 09, 2000 at 12:01:36AM +0200, Thomas Wouters wrote: >Agreed, though I think it should go the other way, too. And it isn't just >about discussing new features or bugs; people, or at least involved people, >like to see that there are actually people working on improving Python ;) People *do* report problems, suggest new features, or provide bugfixes on comp.lang.python, and it would be a pity to miss them; we just have to encourage people to submit through the appropriate channels. python-list is, I think, no longer a language hacking list, and that's probably a good thing. (Remember the person who once said they were shy about posting to python-list because all the discussion was so advanced?) Note for 2.0 final: the docs should mention how to submit patches, the existence of python-dev, etc. I can write a Misc/HACKING file. I'm not sure how to prevent people from inadvertently duplicating ongoing python-dev work, such as the recent case where someone mentioned adding history support to the readline module, which Skip was already doing. A summary of python-dev/CVS activity might be nice. --amk From fdrake@beopen.com Sun Jul 9 15:20:43 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 10:20:43 -0400 (EDT) Subject: [Python-Dev] __SC__ #define? In-Reply-To: References: <14696.3294.579121.909885@cj42289-a.reston1.va.home.com> Message-ID: <14696.35387.635950.631415@cj42289-a.reston1.va.home.com> Michael Hudson writes: > As Tim said, it's probably the Symantec C compiler, which is as far as I > know dead (it was more or less dead when I was last playing around > programming on the Mac, and that was several years ago). > > So unless someone screams "I still use Symantec!", I'd say nuke it. How about "If someone screams, we can add it back." I checking in the change now. Thanks, Michael & Tim! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@beopen.com Sun Jul 9 16:23:10 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 10:23:10 -0500 Subject: [Python-Dev] __SC__ #define? In-Reply-To: Your message of "Sun, 09 Jul 2000 11:06:36 +0100." References: Message-ID: <200007091523.KAA10316@cj20424-a.reston1.va.home.com> > So unless someone screams "I still use Symantec!", I'd say nuke it. Wait till Jack Jansen reads his email. In fact, he can nuke it himself if he doesn't need it... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Sun Jul 9 16:26:28 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 10:26:28 -0500 Subject: [Python-Dev] what about the SF task manager? In-Reply-To: Your message of "Sun, 09 Jul 2000 12:34:48 +0200." <010b01bfe991$53af7280$f2a6b5d4@hagrid> References: <010b01bfe991$53af7280$f2a6b5d4@hagrid> Message-ID: <200007091526.KAA10343@cj20424-a.reston1.va.home.com> [effbot] > has anyone here used the SF task/project manager? Not me. > does it work? Dunno. > maybe we should switch SF's version on for python, so > that people can list things they should get around to > finish some day? ;-) It's an idea. Currently these are hidden in the old TODO wizard and the "request" category in the Jitterbug-based bugs list on python.org... > (we could use the patch manager for this purpose, of > course -- #100764 is one current example) :-) > in the long run, I'd much rather see something based > on roundup (which is the best issue tracking system > I've ever seen, period), but I guess nobody has time > to deal with that right now... I've never seen roundup, either, but it is sure getting good press... Maybe one of my fellow PythonLabs employees can set it up on pythonlabs.com? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake@beopen.com Sun Jul 9 15:34:48 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 10:34:48 -0400 (EDT) Subject: [Python-Dev] __SC__ #define? In-Reply-To: <200007091523.KAA10316@cj20424-a.reston1.va.home.com> References: <200007091523.KAA10316@cj20424-a.reston1.va.home.com> Message-ID: <14696.36232.876446.324645@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > > So unless someone screams "I still use Symantec!", I'd say nuke it. > > Wait till Jack Jansen reads his email. In fact, he can nuke it > himself if he doesn't need it... Er, too late. I can add it back if he needs it. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@beopen.com Sun Jul 9 16:35:07 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 10:35:07 -0500 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: Your message of "Sat, 08 Jul 2000 23:22:16 -0400." References: Message-ID: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> > I just removed all other occurrences of Py_PROTO and Py_FPROTO in the source > tree. Great work, Tim! There's one problem: several large patches that are waiting for us in the SF patch manager won't work any more because they reference context that you ripped out. I'm thinking of the augmented assignment and the list comprehensions patch, and I think Thomas Wouters' patch for [a:b:c] meaning range(a,b,c) is also broken now. I think your patch status guidelines suggest that these patches should be labeled out of date until the author uploads a new version... BTW, the more delay 2.0 incurs because of the negotiations between CNRI and BeOpen, the more sense it makes to me to add those language features! Last night I changed the status of the list comprehensions and augmented assignment patches to Open. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From barry@scottb.demon.co.uk Sun Jul 9 15:56:31 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Sun, 9 Jul 2000 15:56:31 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python Message-ID: <000001bfe9b5$de7168f0$060210ac@private> I read in the archives the problem with import of a 1.5 extension into newer Python release crashing say new Python. A solution that works is to use a new naming scheme for the initialisation entry point. Currently it is "init" + module-name with "_d" appended if it is debug image. Change "init" to "init16", "init20" and you can import the old 1.5 linked extension without a crash, you get an error reported instead. BArry From skip@mojam.com (Skip Montanaro) Sun Jul 9 15:17:41 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 9 Jul 2000 09:17:41 -0500 (CDT) Subject: [Python-Dev] Microsoft adopts Python In-Reply-To: References: Message-ID: <14696.35205.331898.137663@beluga.mojam.com> [ MS recommending Python before C++ ] Tim> I take back everything bad I ever said about clueless support Tim> droids . Maybe it was Bill Tutt on the phone! ;-) Skip From skip@mojam.com (Skip Montanaro) Sun Jul 9 15:23:41 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 9 Jul 2000 09:23:41 -0500 (CDT) Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: References: <1249029961-17188506@hypernet.com> Message-ID: <14696.35565.198655.899292@beluga.mojam.com> >> As a partial solution, perhaps we could use some self-discipline and >> sometimes say "kick it to c.l.py". Michael> .... I think it is important that comp.lang.python continues Michael> to have *some* interesting content, and that the impression is Michael> mantained that (reasonable) opinions expressed there are Michael> listened to, .... Whatever happened to the c.l.py weekly summary? David Ascher, Aaron Watters & Fredrik Lundh I think were doing it for a long time. It seems that with the python-dev archives on the web that perhaps the weekly editor could occasionally point toward specific threads to provide a high-signal intersection of the two lists. To expose interesting c.l.py threads to python-dev folks who may not track the group closely any more, perhaps the weekly summary could be posted here as well. Skip From fdrake@beopen.com Sun Jul 9 16:54:38 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 11:54:38 -0400 (EDT) Subject: [Python-Dev] Objects/ ANSI-fied Message-ID: <14696.41022.709280.192971@cj42289-a.reston1.va.home.com> Ok, the Objects/ directory has been ANSI-fied, and I've noticed /F slaving away in the Modules/ directory, so I'll get out of the way for a little bit. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip@mojam.com (Skip Montanaro) Sun Jul 9 15:33:19 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 9 Jul 2000 09:33:19 -0500 (CDT) Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> References: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> Message-ID: <14696.36143.297072.353525@beluga.mojam.com> Guido> There's one problem: several large patches that are waiting for Guido> us in the SF patch manager won't work any more because they Guido> reference context that you ripped out. I'm thinking of the Guido> augmented assignment and the list comprehensions patch ... I will do a cvs update and generate a new patch today. Skip From Fredrik Lundh" <14696.35565.198655.899292@beluga.mojam.com> Message-ID: <003001bfe9c0$46517780$f2a6b5d4@hagrid> skip wrote: >=20 > >> As a partial solution, perhaps we could use some = self-discipline and > >> sometimes say "kick it to c.l.py". >=20 > Michael> .... I think it is important that comp.lang.python = continues > Michael> to have *some* interesting content, and that the = impression is > Michael> mantained that (reasonable) opinions expressed there are > Michael> listened to, .... >=20 > Whatever happened to the c.l.py weekly summary? David Ascher, Aaron = Watters > & Fredrik Lundh I think were doing it for a long time. I'm still doing the daily edition: http://hem.passagen.se/eff/url.htm http://hem.passagen.se/eff/url-archive.htm Andrew took over the weekly edition a while ago (the latest issue is june 27, I think). For the daily edition, most of the interesting material comes from other sources (oreillynet, linuxdev.net, etc). comp.lang.python varies wildly; some weeks, there are lots of good stuff. Other weeks, I cannot find anything relevant at all... From skip@mojam.com (Skip Montanaro) Sun Jul 9 15:38:21 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 9 Jul 2000 09:38:21 -0500 (CDT) Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) Message-ID: <14696.36445.834366.510392@beluga.mojam.com> --ymrB+0GKDT Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Interesting feature request from c.l.py... Skip --ymrB+0GKDT Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit X-Digest: Python-list digest, Vol 1 #2829 - 6 msgs Message: 6 Return-Path: Delivered-To: python-list@python.org In-Reply-To: <8ka50r$82n$1@nntp9.atl.mindspring.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk List-Id: General discussion list for the Python programming language From: Olmy Sender: python-list-admin@python.org To: python-list@python.org Subject: Feature Request: IPv6 support built into 1.6/2.0 Date: Sun, 9 Jul 2000 10:47:03 -0500 (CDT) Good morning, Has there been any consideration of rolling the KAME IPv6 patches to Python into the official release? It would be quite interesting to start using python to code some small ipv6 utilities here and there. Any thoughts? Are there more appropriate methods to submit feature requests? jeff -- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: RN7/dw97SSxgWUT2asyiONlPRzbOe0JQ iQCVAwUANofqRKxB/KiL2JNNAQEwxwP/VJQamtcDOlt9h3fQ9KqyuiBzBKcXQQMo Fahl3o4HjqI1qh5mv5Mac1G0YKJp+rkhp64GOKG6jDu46aPIgZ9xTc204wQ+wLyO mqw8/EEc3PKtGM57vPkkVJraxHZMdZV45wMnno21Gx03k+d7MWbpd85tjYhrXMFJ TwUCFSAG8/4= =TRCD -----END PGP SIGNATURE----- --ymrB+0GKDT-- From Fredrik Lundh" Message-ID: <004b01bfe9c1$b9354820$f2a6b5d4@hagrid> fred wrote: > Ok, the Objects/ directory has been ANSI-fied, and I've noticed /F > slaving away in the Modules/ directory, so I'll get out of the way for > a little bit. ;) well, I've been checking in Peter Schneider-Kamp's patches. but most of the remaining modules are Unix-only, and I'm on a Win95 box right now. so if anyone wants to make a stab at the patches in the 100768-100787 range, please go ahead. (fred, to give you more things to do, I just assigned Rob's big spelling patch to you, since large parts of it affect the documentation) cheers /F From Fredrik Lundh" Message-ID: <005901bfe9c2$9232e740$f2a6b5d4@hagrid> > Interesting feature request from c.l.py... checking the eff-bot archive. wait a sec... yes, here it is: ftp://ftp.kame.net/pub/kame/misc/ has patches for 1.5.2 netbsd (and iirc, debian?) folks has also been working on this; here's one note: http://mail-index.netbsd.org/netbsd-bugs/2000/01/19/0017.html "of course, need to submit IPv6 support patch to original author (did in the past but he looked busy)" are they talking about guido, perhaps? From thomas@xs4all.net Sun Jul 9 17:25:03 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 18:25:03 +0200 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <14696.36143.297072.353525@beluga.mojam.com>; from skip@mojam.com on Sun, Jul 09, 2000 at 09:33:19AM -0500 References: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> <14696.36143.297072.353525@beluga.mojam.com> Message-ID: <20000709182503.X26534@xs4all.nl> On Sun, Jul 09, 2000 at 09:33:19AM -0500, Skip Montanaro wrote: > Guido> There's one problem: several large patches that are waiting for > Guido> us in the SF patch manager won't work any more because they > Guido> reference context that you ripped out. I'm thinking of the > Guido> augmented assignment and the list comprehensions patch ... > I will do a cvs update and generate a new patch today. Same here. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Fredrik Lundh" Message-ID: <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> current status: > - should this go into the "nt" (posix) module, or should > I create a new module? I just checked in a new version of posixmodule.c, which uses Bill's implementation instead of _popen. works just fine, on the boxes I've tested it on. > - "win32popenWin9x.exe" is a rather unwieldy name for a > file. does anyone have a better suggestion? >=20 > python_popen.exe > py_popen9x.exe > popenStub.exe >=20 > ...? tim suggested "w9xpopen.exe", which as good as it gets. I've checked in the PC/w9xpopen.c file, but I haven't up- dated the build files (see below): > - I'm using VC5 on this box, so I should probably avoid > checking in my modified project files. any VC6-wielding > volunteers out there? tim will fix this. > - first, a stupid question: is the popen2 and popen3 > versions replacements for the corresponding functions > in the popen2 module. >=20 > (or to put it another way: should the popen2 module > be modified to use these functions on Windows?) the new posix code exports popen2, popen3, and popen4 on windows. I'll provide patches for popen2.py later (gotta do some more testing first). cheers /F From Fredrik Lundh" <005901bfe9c2$9232e740$f2a6b5d4@hagrid> Message-ID: <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid> I wrote: > ftp://ftp.kame.net/pub/kame/misc/ has patches for 1.5.2 the patch looks fairly clean to to me. if anyone wants to check with the original author, and update the patch for 2.0, I'm definitely +1 on this one. From jeremy@alum.mit.edu Sun Jul 9 17:42:22 2000 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Sun, 9 Jul 2000 12:42:22 -0400 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <20000709101244.B21174@newcnri.cnri.reston.va.us> Message-ID: >I'm not sure how to prevent people from inadvertently duplicating >ongoing python-dev work, such as the recent case where someone >mentioned adding history support to the readline module, which Skip >was already doing. A summary of python-dev/CVS activity might be >nice. This sounds very good! In the Perl world, there is a weekly summary of discussion on the perl5-porters list. It seems to be written by Mark-Jason Dominus most (all?) of the time. We could do the same thing if we could find people to do it. Perhaps a weekly Python-dev URL? If we had enough reporters, it might not be too much work. Volunteers? I'd be happy to coordinate. Jeremy From fdrake@beopen.com Sun Jul 9 17:48:56 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 12:48:56 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib webbrowser.py,NONE,1.1 In-Reply-To: <200007091645.JAA26779@slayer.i.sourceforge.net> References: <200007091645.JAA26779@slayer.i.sourceforge.net> Message-ID: <14696.44280.536157.31030@cj42289-a.reston1.va.home.com> Fred L. Drake writes: > Update of /cvsroot/python/python/dist/src/Lib The bogus lock in the Lib/ directory is clear; one of the SF guys was out of town for a few days. (Don't know about the others.) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Sun Jul 9 18:01:23 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 13:01:23 -0400 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> Message-ID: [Tim] > I just removed all other occurrences of Py_PROTO and Py_FPROTO > in the source tree. [Guido] > Great work, Tim! If I have demacrofied more than others, it is because I've stood on the throat of Fred Drake . > There's one problem: several large patches that are waiting for us > in the SF patch manager won't work any more because they reference > context that you ripped out. Revolution, eggs, break, sorry. > I'm thinking of the augmented assignment and the list comprehensions > patch, and I think Thomas Wouters' patch for [a:b:c] meaning > range(a,b,c) is also broken now. > > I think your patch status guidelines suggest that these patches should > be labeled out of date until the author uploads a new version... Yes. > BTW, the more delay 2.0 incurs because of the negotiations between > CNRI and BeOpen, the more sense it makes to me to add those language > features! Last night I changed the status of the list comprehensions > and augmented assignment patches to Open. That makes sense to me, and not just because I've been keen on augmented assignment since before Python 1.0, and keen on listcomps since they first came up. Perhaps the person assigned to these patches would care to keep their statuses up to date? Not naming any names here , but if patch ownership means anything, it means owning the next step in the patch process. resisting-a-bad-precedent-ly y'rs - tim From tim_one@email.msn.com Sun Jul 9 18:04:42 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 13:04:42 -0400 Subject: [Python-Dev] new popen for win32! [status update] In-Reply-To: <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> Message-ID: [/F] > I just checked in a new version of posixmodule.c, which > uses Bill's implementation instead of _popen. works just > fine, on the boxes I've tested it on. > ... Thank you, Frederik! This stuff looks great. I believe I've got everything I need now to update the MSVC6 project files and installer and assorted readmes, and I'll do that later today (several hours from now). have-to-pause-once-a-week-to-eat-ly y'rs - tim From Fredrik Lundh" <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> Message-ID: <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> following up on myself: > > - first, a stupid question: is the popen2 and popen3 > > versions replacements for the corresponding functions > > in the popen2 module. > >=20 > > (or to put it another way: should the popen2 module > > be modified to use these functions on Windows?) >=20 > the new posix code exports popen2, popen3, and popen4 > on windows. I'll provide patches for popen2.py later (gotta > do some more testing first). the current api is: popen2.popen2(command, bufsize=3Ddefault) popen2.popen3(command, bufsize=3Ddefault) vs. nt.popen2(command, mode=3D"t") nt.popen3(command, mode=3D"t") the perfect compromise would of course be popen2(command, mode=3D"t", bufsize=3Ddefault) (similar to plain open). I suggest the popen2 api's to: def popen2.popen2(command, mode=3D"t", bufsize=3D-1): if type(mode) is type(0) and bufsize=3D=3D-1: bufsize =3D mode mode =3D "t" ... def nt.popen2(command, mode, bufsize=3D-1): if bufsize !=3D -1: raise ValueError, "cannot set buffer size on windows" =20 comments? From skip@mojam.com (Skip Montanaro) Sun Jul 9 17:03:00 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 9 Jul 2000 11:03:00 -0500 (CDT) Subject: [Python-Dev] patch for os.path.commonprefix (changes semantics - pls review) Message-ID: <14696.41524.306876.462534@beluga.mojam.com> os.path.commonprefix seems broken to me. If you ask it to return the common prefix of "/home/swen/spam" and "/home/swan/eggs", it returns "/home/sw". Since we are talking file paths, not strings, I think the common prefix should be "/home". Since my patch changes the semantics of the function, I submitted a patch via SF that implements what I believe to be the correct behavior instead of just checking in the change, so people could comment on it. Also, since the version in ntpath.py was the same as the version in posixpath.py I modified both, replacing "/" with os.sep (is that correct?). Note that I can't check that it returns something useful on NT, though I suspect it will. There is no commonprefix function in macpath.py. Is this a function that would have no meaning on the Mac? The patch is available for review at http://sourceforge.net/patch/?func=detailpatch&patch_id=100788&group_id=5470 Skip From Fredrik Lundh" Message-ID: <015e01bfe9cd$ee090800$f2a6b5d4@hagrid> skip wrote: > Also, since the version in ntpath.py was the same as the version in > posixpath.py I modified both, replacing "/" with os.sep (is that = correct?). see my comment on the site (in short: you should split on either os.sep or os.altsep, or normalize before splitting. and don't forget UNC names: \\machine\directory...). From thomas@xs4all.net Sun Jul 9 19:49:21 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 20:49:21 +0200 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 09, 2000 at 01:01:23PM -0400 References: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> Message-ID: <20000709204921.Y26534@xs4all.nl> On Sun, Jul 09, 2000 at 01:01:23PM -0400, Tim Peters wrote: > Perhaps the person assigned to these patches would care to keep > their statuses up to date? Not naming any names here , [..] Well, augmented assignment isn't assigned to anyone yet, so I guess I'll keep it up to date ;) Besides, it can be tricky to keep a patch up to date if you didn't write it yourself: you might fail to notice tiny details the original author had in the back of his head. Not that this particular clash was hard to resolve, of course, it was mostly context-clash, plus the issue of writing the patch ANSI style itself ;) Unless of course being assigned to a patch means you have to know it as well as the author(s), in which case I hush up and wait for Guido to assign you to the augassign patch ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Sun Jul 9 19:54:01 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 20:54:01 +0200 Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) In-Reply-To: <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jul 09, 2000 at 06:44:24PM +0200 References: <14696.36445.834366.510392@beluga.mojam.com> <005901bfe9c2$9232e740$f2a6b5d4@hagrid> <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid> Message-ID: <20000709205401.Z26534@xs4all.nl> On Sun, Jul 09, 2000 at 06:44:24PM +0200, Fredrik Lundh wrote: > I wrote: > > ftp://ftp.kame.net/pub/kame/misc/ has patches for 1.5.2 > the patch looks fairly clean to to me. > if anyone wants to check with the original author, and update > the patch for 2.0, I'm definitely +1 on this one. Out of curiousity, what does the patch rely on ? I toyed around with IPv6 a while back (err, make that 3 years back. Gosh, does time fly!) and setting it up was pretty involved, getting the right client libraries and stuff. Is there anything like a standard interface, nowadays, or will the socket (or is that 'socket6' ?) library have to worry about all kinds of different interfaces ? I'd check the patch out, had I the time ;P I might get it late next week or so. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake@beopen.com Sun Jul 9 20:04:20 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 15:04:20 -0400 (EDT) Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) In-Reply-To: <20000709205401.Z26534@xs4all.nl> References: <14696.36445.834366.510392@beluga.mojam.com> <005901bfe9c2$9232e740$f2a6b5d4@hagrid> <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid> <20000709205401.Z26534@xs4all.nl> Message-ID: <14696.52404.703807.177420@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > Out of curiousity, what does the patch rely on ? I toyed around with IPv6 a > while back (err, make that 3 years back. Gosh, does time fly!) and setting > it up was pretty involved, getting the right client libraries and stuff. > Is there anything like a standard interface, nowadays, or will the socket > (or is that 'socket6' ?) library have to worry about all kinds of different There's a standard API for both "normal" and advanced features of IPv6 sockets defined in some IETF documents; I'm not sure of their current state, but they've been in development for a while, so they might even be RFCs by now. > I'd check the patch out, had I the time ;P I might get it late next week or > so. I may look at them in a few days as well. Multiple opinions may be very valuable on a topic as detailed and pervasive as this! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From peter@schneider-kamp.de Sun Jul 9 22:13:15 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 09 Jul 2000 21:13:15 +0000 Subject: [Python-Dev] PROTO_LIST in Modules/md5.h Message-ID: <3968EAEB.A06D9A38@stud.ntnu.no> Is this still needed with ANSI? Thanks, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From thomas@xs4all.net Sun Jul 9 20:16:42 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 21:16:42 +0200 Subject: [Python-Dev] PROTO_LIST in Modules/md5.h In-Reply-To: <3968EAEB.A06D9A38@stud.ntnu.no>; from petersc@stud.ntnu.no on Sun, Jul 09, 2000 at 09:13:15PM +0000 References: <3968EAEB.A06D9A38@stud.ntnu.no> Message-ID: <20000709211641.B26534@xs4all.nl> On Sun, Jul 09, 2000 at 09:13:15PM +0000, Peter Schneider-Kamp wrote: > Is this still needed with ANSI? No, and it isn't necessary with K&R C either, just if you wish to use both at the same time ;) It's the same as the Py_PROTO macro, and should be removed, yes. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake@beopen.com Sun Jul 9 20:19:29 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 15:19:29 -0400 (EDT) Subject: [Python-Dev] PROTO_LIST in Modules/md5.h In-Reply-To: <3968EAEB.A06D9A38@stud.ntnu.no> References: <3968EAEB.A06D9A38@stud.ntnu.no> Message-ID: <14696.53313.296096.777677@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > Is this still needed with ANSI? No, but this is imported code, so perhaps it makes sense to leave that in. (Both md5.c and md5.h are imported, and are the only places that have this.) I won't object to ANSI-fying these two files, but I'm not sure it makes sense, either. These may as well be an external library. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Sun Jul 9 20:21:41 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 15:21:41 -0400 (EDT) Subject: [Python-Dev] Out of loop... Message-ID: <14696.53445.235099.144979@cj42289-a.reston1.va.home.com> Ok, it's been a busy week, and my wife & kids are just about back. I'll be largely out of touch here for about 24 hours. It's time to play with the kids! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Sun Jul 9 20:38:05 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 15:38:05 -0400 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <20000709204921.Y26534@xs4all.nl> Message-ID: [Tim] > Perhaps the person assigned to these patches would care to keep > their statuses up to date? Not naming any names here , [..] [Thomas Wouters, with his heart in the right place but on the wrong track] > Well, augmented assignment isn't assigned to anyone yet, so I guess > I'll keep it up to date ;) Keeping a patch up to date is different than keeping the patch *status* up to date. I was talking about the latter. When Guido (or anyone else) notices that a patch is out of date, I am gently suggesting that they change the SourceForge Patch Manager Status field to "Out of date" themself (rather than, e.g., leaving the status "Open" and posting to Python-Dev that the status is wrong now -- the latter is an instance of the "active mailing list write-only black hole" we moved to SF to get away from). From thomas@xs4all.net Sun Jul 9 20:40:59 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 21:40:59 +0200 Subject: [Python-Dev] Out of loop... In-Reply-To: <14696.53445.235099.144979@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Sun, Jul 09, 2000 at 03:21:41PM -0400 References: <14696.53445.235099.144979@cj42289-a.reston1.va.home.com> Message-ID: <20000709214058.D26534@xs4all.nl> On Sun, Jul 09, 2000 at 03:21:41PM -0400, Fred L. Drake, Jr. wrote: > Ok, it's been a busy week, and my wife & kids are just about back. > I'll be largely out of touch here for about 24 hours. It's time to > play with the kids! Damn, this scares me. Even at my real-life job we don't warn eachother when we're out of the loop for a day or so. We've had a colleague go on a vacation, and not be missed for like a week before anyone started wondering where he was ;-) And here is Fred apologizing for spending a day with his family. Is it too late for me to opt out ?!? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake@beopen.com Sun Jul 9 20:47:37 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 15:47:37 -0400 (EDT) Subject: [Python-Dev] Out of loop... In-Reply-To: <20000709214058.D26534@xs4all.nl> References: <14696.53445.235099.144979@cj42289-a.reston1.va.home.com> <20000709214058.D26534@xs4all.nl> Message-ID: <14696.55001.491151.543374@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > Damn, this scares me. Even at my real-life job we don't warn eachother when > we're out of the loop for a day or so. We've had a colleague go on a > vacation, and not be missed for like a week before anyone started wondering > where he was ;-) And here is Fred apologizing for spending a day with his > family. Is it too late for me to opt out ?!? You have to realize -- right now, email is the *primary* communications mechanism for PythonLabs, both internally and with the community. If we don't know that someone is away from their mail, we expect rapid response. Given my past week, there've been very few hours I've been away from my mail. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Sun Jul 9 21:03:06 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 16:03:06 -0400 Subject: [Python-Dev] Out of loop... In-Reply-To: <20000709214058.D26534@xs4all.nl> Message-ID: [Fred L. Drake, Jr.] > Ok, it's been a busy week, and my wife & kids are just about back. > I'll be largely out of touch here for about 24 hours. It's time to > play with the kids! [Thomas Wouters, understandly terrified by the implications] > ... > And here is Fred apologizing for spending a day with his family. Is it > too late for me to opt out ?!? Far too late, yes. Your ours for life now (and probably longer, if CNRI has any say in the matter <0.9 wink>). [Fred again, rationalizing] > You have to realize -- right now, email is the *primary* communications > mechanism for PythonLabs, both internally and with the community. Actually, the community may not realize that we don't have an office, Jeremy and Barry live in a different state than Guido and Fred, and Tim is living in a hotel (although I think I've been careful to whine about the latter often enough here ). The *important* thing to notice, though, is that Fred is still replying to email instantly even after swearing on all that is holy that he'd be out of touch for 24 hours. pythonlabs-has-zero-tolerance-for-wimps-ly y'rs - tim From guido@beopen.com Sun Jul 9 22:52:13 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 16:52:13 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Sun, 09 Jul 2000 15:56:31 +0100." <000001bfe9b5$de7168f0$060210ac@private> References: <000001bfe9b5$de7168f0$060210ac@private> Message-ID: <200007092152.QAA14143@cj20424-a.reston1.va.home.com> > I read in the archives the problem with import of a 1.5 extension > into newer Python release crashing say new Python. > > A solution that works is to use a new naming scheme for the > initialisation entry point. Currently it is "init" + module-name > with "_d" appended if it is debug image. > > Change "init" to "init16", "init20" and you can import the old > 1.5 linked extension without a crash, you get an error reported > instead. Nice idea... Unfortunately it means that every module must be changed. If we want to do this, we'd best introduce a macro! E.g. (untested): #define Py_INIT(modname) DL_EXPORT(void) init20##modname() --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Sun Jul 9 22:53:42 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 16:53:42 -0500 Subject: [Python-Dev] Objects/ ANSI-fied In-Reply-To: Your message of "Sun, 09 Jul 2000 11:54:38 -0400." <14696.41022.709280.192971@cj42289-a.reston1.va.home.com> References: <14696.41022.709280.192971@cj42289-a.reston1.va.home.com> Message-ID: <200007092153.QAA14165@cj20424-a.reston1.va.home.com> > Ok, the Objects/ directory has been ANSI-fied, and I've noticed /F > slaving away in the Modules/ directory, so I'll get out of the way for > a little bit. ;) Great! Sounds like everybody is getting the hint that 2.0 needs to have some distinguishing characteristics compared to 1.6... :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From tim_one@email.msn.com Sun Jul 9 21:55:52 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 16:55:52 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <20000628010407.T29590@lyra.org> Message-ID: [Tim] > OTOH, we're also interested in *helping* SF get better! SF is > as much an Open Source project as Python, and it could become > an incredible resource for the entire OS community. [Greg Stein [mailto:gstein@lyra.org] Sent: Wednesday, June 28, 2000 4:04 AM] > This last statement is (unfortunately) not quite true. SourceForge is > developed in a closed, cathedral environment. There is no CVS > access to it, and all the developers work at VA Linux. Strictly speaking, > the *output* of this closed development is GPL'd. But it isn't what you > would expect. Ah! You were reading my stmt as a claim about SF, rather than as a warning about the new status of Python . Just kidding. I was talking out of my ass there, and appreciate the correction. From tim_one@email.msn.com Sun Jul 9 21:55:45 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 16:55:45 -0400 Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: <20000627101658.E7257@activestate.com> Message-ID: [Trent Mick Sent: Tuesday, June 27, 2000 1:17 PM] > What are the chances of getting other meta data fields on patches, i.e. > changes to the patch manager? A question for SourceForge. > Categorizing patches could really help as a filter. For instance, I > may be a Unicode genius and would like to see the patches associated > with it. There's already a "Category" field on SF patches, but the main view doesn't show it (you have to look at an individual patch to see it) and there's apparently no way to filter on it either. Also think you have to be an admin to create a new category. I'll confess in advance, though, that I expect each additional field will just be one more field set incorrectly on the vast minority of patches. > ... > Perhaps ownership (i.e. 'assigned to') of the patch should transfer > to the person responsible for later taking to patch out of 'postponed' > status. Yes; thank you; I'll post a revision later today. The intent was always that "assigned to" be the most likely person to take action next. From guido@beopen.com Sun Jul 9 23:02:37 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 17:02:37 -0500 Subject: [Python-Dev] new popen for win32! [status update] In-Reply-To: Your message of "Sun, 09 Jul 2000 19:37:35 +0200." <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> Message-ID: <200007092202.RAA14221@cj20424-a.reston1.va.home.com> > the current api is: > > popen2.popen2(command, bufsize=default) > popen2.popen3(command, bufsize=default) > > vs. > > nt.popen2(command, mode="t") > nt.popen3(command, mode="t") Not commenting on the question here, but on the return tuple: should it be (i,o,e) or (o,i,e)? The popen2 module uses the latter, but that's hard to remember for Unix-droids: it corresponds to (1,0,2) in file descriptors. So if it's not too late, let's do (i,o,e). (I tried to read the posixmodule.c source but got lost...) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From tim_one@email.msn.com Sun Jul 9 22:07:40 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 17:07:40 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr. Sent: Wednesday, June 28, 2000 9:30 AM] > ... > the only problem I've had with IE5 is accessing a project's anonymous > FTP area from the project page (IE5 just froze completely). This happens to me too. And a new problem popped up early this weekend (maybe Friday already): when I click the "Browse CVS Repository" link near the bottom right of http://sourceforge.net/cvs/?group_id=5470 IE5 pops up a box asking me whether I really want to download file "cvsweb". Useless! This used to work fine, and I sure haven't changed my IE setup. Clearing the browser caches didn't help. The link resolves to http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi?cvsroot=python today, and I don't know whether it resolved to something different last week. Also have no idea how browsers decide what to do -- it's not simple & straightforward, like e.g. floating-point arithmetic . .cgi is not an extension registered on my machine either. From peter@schneider-kamp.de Mon Jul 10 00:17:44 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 09 Jul 2000 23:17:44 +0000 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix References: <396780B6.67247E2C@stud.ntnu.no> <200007082334.SAA08816@cj20424-a.reston1.va.home.com> Message-ID: <39690818.917030DE@stud.ntnu.no> This is a multi-part message in MIME format. --------------EDF4EC1E815749A45E1B5A7C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit While "slaving away" on the Modules/ directory (thanks for the term - it made my day ), I still haven't got a clue why Python crashes on me when I throw an error on duplicate arguments like in: [example] >>> def f(a, a): print a segfault [/example] Any help is again appreciated. Or should I just load up that mini patch to SF and wait for some unlucky guy that assigns it on himself <0.5 wink>? okay, back to Modules/r* - z* Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de --------------EDF4EC1E815749A45E1B5A7C Content-Type: text/plain; charset=us-ascii; name="compile_funcdef.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="compile_funcdef.patch" diff -c -d -T --recursive python/dist/src/Python/compile.c python-mod/dist/src/Python/compile.c *** python/dist/src/Python/compile.c Mon Jul 3 21:39:47 2000 --- python-mod/dist/src/Python/compile.c Sun Jul 9 02:04:26 2000 *************** *** 3092,3097 **** --- 3092,3098 ---- node *ch = CHILD(n, i); node *fp; char *name; + PyObject *nameval; if (TYPE(ch) == STAR || TYPE(ch) == DOUBLESTAR) break; REQ(ch, fpdef); /* fpdef: NAME | '(' fplist ')' */ *************** *** 3103,3109 **** sprintf(nbuf, ".%d", i); complex = 1; } ! com_newlocal(c, name); c->c_argcount++; if (++i >= nch) break; --- 3104,3118 ---- sprintf(nbuf, ".%d", i); complex = 1; } ! nameval = PyString_InternFromString(name); ! if (nameval == NULL) { ! c->c_errors++; ! } ! if (PyDict_GetItem(c->c_locals, nameval)) { ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); ! } ! com_newlocal_o(c, nameval); ! Py_DECREF(nameval); c->c_argcount++; if (++i >= nch) break; --------------EDF4EC1E815749A45E1B5A7C-- From guido@beopen.com Sun Jul 9 23:27:33 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 17:27:33 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib popen2.py,1.9,1.10 In-Reply-To: Your message of "Sun, 09 Jul 2000 10:59:34 MST." <200007091759.KAA04874@slayer.i.sourceforge.net> References: <200007091759.KAA04874@slayer.i.sourceforge.net> Message-ID: <200007092227.RAA14284@cj20424-a.reston1.va.home.com> > - changed nt.popen2/popen3/popen4 return values > to match the popen2 module (stdout first, not > stdin). Really? Isn't that a horrid order? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Sun Jul 9 23:31:58 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 17:31:58 -0500 Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) In-Reply-To: Your message of "Sun, 09 Jul 2000 15:04:20 -0400." <14696.52404.703807.177420@cj42289-a.reston1.va.home.com> References: <14696.36445.834366.510392@beluga.mojam.com> <005901bfe9c2$9232e740$f2a6b5d4@hagrid> <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid> <20000709205401.Z26534@xs4all.nl> <14696.52404.703807.177420@cj42289-a.reston1.va.home.com> Message-ID: <200007092231.RAA14305@cj20424-a.reston1.va.home.com> I remember that someone from Japan (the KAME folks?) submitted IPv6 patches before -- maybe a year ago. Unfortunately, they had only tested it on one platform (*bsd?), and the porting instructions they gave didn't work at all on any platform I had access to (Solaris, Linux). If the portability of the new patches is up to snuff, I'd be all for integrating this. Ideally, it would detect at configure time whether IPv6 support is available and do the right thing. I suppose there's a POSIX standard for IPv6 socket extensions etc. somewhere? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas@xs4all.net Sun Jul 9 22:35:26 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 23:35:26 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14695.840.448508.397722@beluga.mojam.com>; from skip@mojam.com on Sat, Jul 08, 2000 at 05:32:40AM -0500 References: <14691.49563.78765.683762@beluga.mojam.com> <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> <14695.840.448508.397722@beluga.mojam.com> Message-ID: <20000709233525.E26534@xs4all.nl> On Sat, Jul 08, 2000 at 05:32:40AM -0500, Skip Montanaro wrote: > Since Fredrik's voice is the only one I heard, and on the off-chance that > the CNRI/BeOpen discussions and resulting 1.6 release push things out a bit > (allowing a feature thaw) I'll oblige. I have a couple of questions regarding this patch, if you don't mind. I didn't appoint myself arbiter of new code, and I'm certainly not a kind of spanish inquisition, but I really have to scratch my head when reading this patch (and the resulting code.) I hope you don't take it personal ;P Also, I'm not criticising the new feature, just wondering about the implementation. For one, the Grammar for list comprehensions: '[' [testlist [list_iter]] ']' Should that really be 'testlist' ? As far as I can see, it should be 'test' rather than 'testlist'. This is kind of nit-picky, but the presence of the list_iter part completely changes the meaning of the testlist in front of it: [1,2,3,4,5] is a list of 5 elements, but [1,2,3,4,5 if 1] is a list of one element, which is a 5-element tuple. I'd say the Grammar would be more like this: atom: '(' [testlist] ')' | '[' [listmaker] ']' | '{' [dictmaker] '}' | '' testlist '' | NAME | NUMBER | STRING+ listmaker: test ( list_iter | (',' test)* [',']) list_iter: list_for | list_if list_for: 'for' exprlist 'in' testlist [list_iter] list_if: 'if' test [list_iter] And by coincidence this is also fits very nicely with what the 'range-literal' patch does ;-) Another issue is the code- and logic-duplication of the patch to compile.c: it looks like a large part was just copied from com_for_node, and the block-stuff commented out. Why is it commented out, by the way ? Don't exceptions or something need the block setup ? If the block-setup was kept in, it might be easier to split the com_for_node into a function that compiles the header, and one that compiles the suite, and make com_list_for compile its own 'suite'. I'm hoping that's possible, because it would keep the code a lot cleaner, and it would make it easier for me to implement 'for i in x;j in y' and have it work for list comprehensions too ;-) Also, the patch creates a list, stores it locally, and calls append() to it inside the inner loop. Isn't it possible for the patch to build the list on the stack, pushing individual elements on the stack and calling BUILD_LIST at the end ? The for loops counts the number of loops anyway ;) and it would get rid of the fairly ugly tmpname thing altogether, I think. However, the logic of when to ROT_THREE and ROT_TWO and what not might run away from under us ;-P (But I'm facing that anyway, with the parallel-forloop) Alternatively, it would be nice to store the lists' append() in a local vrbl, to reduce the number of lookups ;-P Oh, and lastly, the patch is just screaming for a re-indent all over, and of some wel-placed comments... some of it was quite difficult to follow, compared to the rest of the code. Just-showing-I-care-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@beopen.com Sun Jul 9 23:34:52 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 17:34:52 -0500 Subject: [Python-Dev] PROTO_LIST in Modules/md5.h In-Reply-To: Your message of "Sun, 09 Jul 2000 15:19:29 -0400." <14696.53313.296096.777677@cj42289-a.reston1.va.home.com> References: <3968EAEB.A06D9A38@stud.ntnu.no> <14696.53313.296096.777677@cj42289-a.reston1.va.home.com> Message-ID: <200007092234.RAA14334@cj20424-a.reston1.va.home.com> > Peter Schneider-Kamp writes: > > Is this still needed with ANSI? > > No, but this is imported code, so perhaps it makes sense to leave > that in. (Both md5.c and md5.h are imported, and are the only places > that have this.) > I won't object to ANSI-fying these two files, but I'm not sure it > makes sense, either. These may as well be an external library. I'd say ANSIfy them. While they are derived from external code, they have been hacked enough, and the MD5 algorithm isn't going to change any time soon, so we might as well reformat them and generally clean them up according to our current taste. Of course, it's not high priority stuff, but sometimes it helps putting our "mark" on code. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jack@oratrix.nl Sun Jul 9 22:50:52 2000 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 09 Jul 2000 23:50:52 +0200 Subject: [Python-Dev] Venting some steam on current developments Message-ID: <20000709215057.95047E2673@oratrix.oratrix.nl> I'm getting pretty depressed at the way Python development is proceeding at the moment. I spent all evening tonight on what seemed to be an almost trivial task: fixing the default unicode conversion on the Mac. All the machinery is there, the MacOS API has some nice conversion routines so I thought it'd be a question of putting in a few hooks and be done, but that turned out not to be so. The first problem (for which I can't blame the Python community, I guess:-) is that the names mac_roman and such are not official IANA names for the Mac encodings. Actually, it turns out there _are_ no official names, so the Mac APIs to turn encodings into names work wonderful for things including all ISO encodings, windows encodings, etc, but not for the native mac encodings. Sigh. Okay, we do this ourselves. Then I spent an hour recompiling Python because this *&^^$%&*^%$ setdefaultencoding didn't show up in sys for no conceivable reason. It turns out it is *deleted* in site.py after using it once. A comment in sysmodule.c would have been rather nice here... And then I found out that locale uses only environment variables to obtain all the basic encoding info in the first place, so that also has to be fixed up seriously. So many things are changing at the moment, and there seems to be so little thought of any platform that isn't linux or windows, that I think Python's portability to minority platforms is being seriously threatened. And at least I follow closely what is happening, I really don't want to think of the poor people who do BeOS or WinCE or Palm Python. Or even some of the lesser-used Unix ports. I'm fed up, I'll continue hacking tomorrow, if I don't have to spend yet another evening trying to get Python to compile again:-( -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From thomas@xs4all.net Sun Jul 9 22:55:47 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 23:55:47 +0200 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 09, 2000 at 05:07:40PM -0400 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Message-ID: <20000709235547.F26534@xs4all.nl> On Sun, Jul 09, 2000 at 05:07:40PM -0400, Tim Peters wrote: > And a new problem popped up early this weekend (maybe Friday already): when > I click the "Browse CVS Repository" link near the bottom right of > > http://sourceforge.net/cvs/?group_id=5470 > > IE5 pops up a box asking me whether I really want to download file "cvsweb". > Useless! This used to work fine, and I sure haven't changed my IE setup. > Clearing the browser caches didn't help. The link resolves to > > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi?cvsroot=python > > today, and I don't know whether it resolved to something different last > week. Also have no idea how browsers decide what to do -- it's not simple & > straightforward, like e.g. floating-point arithmetic . .cgi is not an > extension registered on my machine either. Actually, it's supposed to be simple and straightforward. Unfortunately, certain Windows programs decided not to play along ;) HTTP responses contain a header 'Content-Type', which should be a mimetype for the file the HTTP response accompanies. They may also contain a 'Content-Disposition' header, which contains a suggested filename for when writing the file to disk. Now, the Content-Type thing is working okay nowadays, even though you can override it (sometimes) using the 'helpers' or 'applications' settings in your browser ;) But the Content-Disposition header creates a ton of confusion on IE. Some versions of IE seem to think that when it's present, a file should *always* be saved to disk, instead of shown, regardless of mimetype and/or helper applications. Also, some versions of IE go completely bananas if the Content-Disposition header is listed before the Content-Type header, and gives a very strange response: a 'page not found' error without saying which page it was trying to download ;) I know all this for a fact, because we provide our customers with 'Secure Webmail', a web interface to their email (next to normal interfaces, of course.) And for a long while our helpdesk was forced to tell our IE-using users to switch to Netscape, because IE was giving the above errors, and more. Eventually, my boss and I spent two days with a couple of windows boxes trying to figure out why this was happening. by tcpdumping and tracing exactly what was being sent and received. (Not that easy, given that it was 1) a switched network on our side, 2) a special load-balancing-switch on the server side, and 3) 'Secure' Webmail, using SSL ;) We managed to track the above bugs when using non-SSL connections, but a few bugs remained in SSL only, and we never figured out how or why :P The bugs are really obscure: IE sometimes giving an error when clicking on 'new mailbox', but usually it went fine. IE giving a popup with some unclear error message out of the blue. Sometimes showing images, sometimes offering them for download. All in all, I'm no longer suprised when something dynamic (CGI scripts, php/asp/jsp pages, whatever) refuses to work properly with IE ;) Quite a depressing thing to know, this, but you can't always blame the website-owners or the software developers. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one@email.msn.com Sun Jul 9 23:08:21 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 18:08:21 -0400 Subject: [Python-Dev] Revision 2 of Patch Manager guidelines Message-ID: I believe the attached addresses all questions (but no "new feature requests") that were raised. Note especially the new threat to do "random assignment" of incoming patches, the new request that you comment on patches assigned to you at least weekly, and the new request that you take yourself off of patches you're assigned to but not actively pursuing. We already have patches just sitting there without action or comment for no apparent reason, and *something* has to force those to move along. at-least-now-we-can-see-which-patches-those-are-ly y'rs - tim Intended use of SourceForge patch status & "assigned to" fields --------------------------------------------------------------- revision 2 09-Jul-2000 In general, the status field should be close to self-explanatory, and the "assigned to" field should be the person responsible for taking the next step in the patch process. Both fields are expected to change value over the life of a patch; the normal workflow is detailed below. When you've got the time and the ability, feel free to move any patch that catches your eye along, whether or not it's been assigned to you. And if you're assigned to a patch but aren't going to take reasonably quick action (for whatever reason), please assign it to someone else ASAP: at those times you can't actively help, actively get out of the way. If you're an expert in some area and know that a patch in that area is both needed and non-controversial, just commit your changes directly -- no need then to get the patch mechanism involved in it. You should add a comment to every patch assigned to you at least once a week, if only to say that you realize it's still on your plate. This rule is meant to force your attention periodically: patches get harder & harder to deal with the longer they sit. Open The initial status of all patches. The patch is under consideration, but has not been reviewed yet. The status will normally change to Accepted or Rejected next. The person submitting the patch should (if they can) assign it to the person they most want to review it. Else the patch will be assigned via [xxx a list of expertise areas should be developed] [xxx but since this hasn't happened and volunteers are too few, random assignment is better than nothing: if you're a Python developer, expect to get assigned out of the blue!] Discussion of major patches is carried out on the Python-Dev mailing list. For simple patches, the SourceForge comment mechanism should be sufficient. [xxx an email gateway would be great, ditto Ping's Roundup] Accepted The powers that be accepted the patch, but it hasn't been applied yet. [xxx flesh out -- Guido Bottleneck avoidable here?] The status will normally change to Closed next. The person changing the status to Accepted should, at the same time, assign the patch to whoever they believe is most likely to be able & willing to apply it (the submitter if possible). Closed The patch has been accepted and applied. The previous status was Accepted, or possibly Open if the submitter was Guido (or moral equivalent in some particular area of expertise). Rejected The patch has been reviewed and rejected. When the objections are addressed, the status may change to Open again. The person changing the status to Rejected should assign the patch back to the submitter, or if it's clear the patch will never be accepted, assign it to None. Note that SourceForge allows the submitter to overwrite the patch with a new version. Out of date Previous status was Open or Accepted or Postponed, but the patch no longer works. Please enter a comment when changing the status to "Out of date", to record the nature of the problem and the previous status. Also assign it back to the submitter, as they need to upload a new version (note that SourceForge will not allow anyone other than the original submitter to update the patch). Postponed The previous status was Open or Accepted, but for some reason (e.g., pending release) the patch should not be reviewed or applied until further notice. The status will normally change to Open or Accepted next. Please enter a comment when changing the status to Postponed, to record the reason, the previous status, and the conditions under which the patch should revert to Open or Accepted. Also assign the patch to whoever is most likely able and willing to decide when the status should change again. Deleted Bit bucket. Use only if it's OK for the patch and its SourceForge history to disappear. As of 09-July-2000, SF does not actually throw away Deleted patches, but that may change. From thomas@xs4all.net Sun Jul 9 23:26:44 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 00:26:44 +0200 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix In-Reply-To: <39690818.917030DE@stud.ntnu.no>; from petersc@stud.ntnu.no on Sun, Jul 09, 2000 at 11:17:44PM +0000 References: <396780B6.67247E2C@stud.ntnu.no> <200007082334.SAA08816@cj20424-a.reston1.va.home.com> <39690818.917030DE@stud.ntnu.no> Message-ID: <20000710002644.G26534@xs4all.nl> On Sun, Jul 09, 2000 at 11:17:44PM +0000, Peter Schneider-Kamp wrote: > While "slaving away" on the Modules/ directory (thanks for > the term - it made my day ), I still haven't got a > clue why Python crashes on me when I throw an error on > duplicate arguments like in: > >>> def f(a, a): print a > segfault > Any help is again appreciated. Hm, strange. It works fine here. Do you get the segfault every time ? Anyway, a possible problem is that PyString_InternFromString might return NULL, and you later PyDict_GetItem() with it (not sure if that's a problem), and you pass it to com_newlocal_o (not sure if that's a problem either), and then you Py_DECREF it. And if you pass NULL to that macro you do have a problem :) You should use Py_XDECREF() if you aren't sure wether the object is NULL or not. If your python left a corefile, you can easily find out if that was the problem by using gdb on it. 'gdb ./python core', wait 'till it finishes loading, and type 'bt'. It should give you reversed (from a python point of view) backtrace from the time of the crash. > ! nameval = PyString_InternFromString(name); > ! if (nameval == NULL) { > ! c->c_errors++; > ! } > ! if (PyDict_GetItem(c->c_locals, nameval)) { > ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); > ! } > ! com_newlocal_o(c, nameval); > ! Py_DECREF(nameval); -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one@email.msn.com Sun Jul 9 23:33:21 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 18:33:21 -0400 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <20000709215057.95047E2673@oratrix.oratrix.nl> Message-ID: Random question: why isn't the Mac code checked into the main CVS tree? I don't know anything about Mac development, and because the code for it is invisible to me too, have no idea how any change may affect your life (e.g., if Guido hadn't remembered its Mac connection, I would have deleted the USE_STACKCHECK stuff -- for which there is no conceivable use via staring at every file in the CVS true -- not even a doc like "stuff you shouldn't screw with because it's important on the Mac" ). BTW, I heartily agree that the lack of official IANA names for Mac encodings is not my fault. sympathetic-but-too-ignorant-to-help-ly y'rs - tim From paul@prescod.net Sun Jul 9 23:38:24 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 09 Jul 2000 17:38:24 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> Message-ID: <3968FEE0.E1345788@prescod.net> Guido van Rossum wrote: > > ... > Nice idea... Unfortunately it means that every module must be > changed. If we want to do this, we'd best introduce a macro! > E.g. (untested): > > #define Py_INIT(modname) DL_EXPORT(void) init20##modname() Why is it that the init function names has to change for each module? Why not PyModuleMain or something? -- Paul Prescod - Not encumbered by corporate consensus "Computer Associates is expected to come in with better than expected earnings." Bob O'Brien, quoted in - http://www.fool.com/news/2000/foth000316.htm From dberlin@redhat.com Sun Jul 9 23:45:08 2000 From: dberlin@redhat.com (Daniel Berlin+list.python-dev) Date: 09 Jul 2000 18:45:08 -0400 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: "Tim Peters"'s message of "Sun, 9 Jul 2000 18:33:21 -0400" References: Message-ID: <86d7kmly8b.fsf@dan2.cygnus.com> "Tim Peters" writes: > Random question: why isn't the Mac code checked into the main CVS tree? I > don't know anything about Mac development, and because the code for it is > invisible to me too, have no idea how any change may affect your life (e.g., > if Guido hadn't remembered its Mac connection, I would have deleted the > USE_STACKCHECK stuff -- for which there is no conceivable use via staring at > every file in the CVS true -- not even a doc like "stuff you shouldn't screw > with because it's important on the Mac" ). Also, Jack, you said you pity those on lesser known platforms like BeOS. Well, on BeOS, most stuff is posix compliant enough that things like Unicode will work (besides that BeOS has native support for unicode in it's own API's) the way they are written. The only stuff we worry about is dynamic loading of shared libs, and threading. WinCE is probably going to run into the same issues Windows does, more or less. I'm gonna say that Macs are mainly the oddball here, and that mou are running into issues mainly because nobody has had to deal with them, cause it doesn't take that much work to make it work on our favorite platform. > > BTW, I heartily agree that the lack of official IANA names for Mac encodings > is not my fault. > I'll take the blame for this one. I've got broad shoulders. > sympathetic-but-too-ignorant-to-help-ly y'rs - tim > > > From Fredrik Lundh" <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> <200007092202.RAA14221@cj20424-a.reston1.va.home.com> Message-ID: <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> guido wrote: > > the current api is: > >=20 > > popen2.popen2(command, bufsize=3Ddefault) > > popen2.popen3(command, bufsize=3Ddefault) > >=20 > > vs. > >=20 > > nt.popen2(command, mode=3D"t") > > nt.popen3(command, mode=3D"t") >=20 > Not commenting on the question here, but on the return tuple: should > it be (i,o,e) or (o,i,e)? The popen2 module uses the latter, but > that's hard to remember for Unix-droids: it corresponds to (1,0,2) in > file descriptors. So if it's not too late, let's do (i,o,e). >=20 > (I tried to read the posixmodule.c source but got lost...) oh, I just changed things around the other way (assuming that "popen2" was some kind of standard). changing things is trivial, decided what's the right way to do it is harder. here's another idea: one way to solve this would be to deprecate "popen2", and move that functionality into the os module -- with the return values sorted out. that is, let's introduce: f =3D os.popen(cmd, mode, bufsize) w, r =3D os.popen2(cmd, mode, bufsize) w, r, e =3D os.popen3(cmd, mode, bufsize) w, r =3D os.popen4(cmd, mode, bufsize) # windows only, at the moment and mark popen2 as obsolete. whaddayathink? From alex_c@MIT.EDU Sun Jul 9 23:54:44 2000 From: alex_c@MIT.EDU (Alexander S Coventry) Date: Sun, 9 Jul 2000 18:54:44 -0400 (EDT) Subject: [Python-Dev] Problem with 'import site' on Linux In-Reply-To: <20000709221002.A1FB71CF57@dinsdale.python.org> (python-dev-request@python.org) References: <20000709221002.A1FB71CF57@dinsdale.python.org> Message-ID: <200007092254.SAA289432@w20-575-115.mit.edu> The function _locale._getdefaultlocale seems to only be defined if python is compiled for windows, but an attempt is made to call it regardless of the OS in locale.getdefaultlocale. This is causing 'import site' to fail when I start python. I am not sure what ought to be called instead; in my version, for now, I am going to amend the try: except: block that this code is wrapped in so that it catches AttributeError's, as well. The code I'm referring to is around line 262 in Lib/locale.py, and line 343 in Modules/_localemodule.c Alex. From Fredrik Lundh" <200007092254.SAA289432@w20-575-115.mit.edu> Message-ID: <033001bfe9fb$09a16b20$f2a6b5d4@hagrid> alexander wrote: > The function _locale._getdefaultlocale seems to only be defined if > python is compiled for windows, but an attempt is made to call it > regardless of the OS in locale.getdefaultlocale. This is causing > 'import site' to fail when I start python. I am not sure what ought = to > be called instead; in my version, for now, I am going to amend the = try: > except: block that this code is wrapped in so that it catches > AttributeError's, as well. >=20 > The code I'm referring to is around line 262 in Lib/locale.py, and = line > 343 in Modules/_localemodule.c I'll fix this in the repository. the except clause should catch AttributeError, not NameError. sorry /F From Fredrik Lundh" Message-ID: <033301bfe9fb$209d3520$f2a6b5d4@hagrid> jack wrote: > The first problem (for which I can't blame the Python community, I > guess:-) is that the names mac_roman and such are not official IANA > names for the Mac encodings. Actually, it turns out there _are_ no > official names, so the Mac APIs to turn encodings into names work > wonderful for things including all ISO encodings, windows encodings, > etc, but not for the native mac encodings. Sigh. Okay, we do this > ourselves.=20 > Then I spent an hour recompiling Python because this *&^^$%&*^%$ > setdefaultencoding didn't show up in sys for no conceivable reason. It = > turns out it is *deleted* in site.py after using it once. A comment in = > sysmodule.c would have been rather nice here... mail problems? didn't I send you a couple of mails discussing what needed to be done, including where you could reach me over the weekend? did you see my changes to the locale module? I rewrote the darn thing to make it easier to deal with this on non-posix platforms, and posted the locale.py patch to the patch manager (the CVS repository had a stale lock, so I couldn't check it in before today). heck, I even sent you some pseudocode that showed one way to implement parts of _getdefaultlocale for the mac, and still you claim that we're ignoring non unix/windows platforms? you could have asked for help a little earlier, you know... From billtut@microsoft.com Mon Jul 10 00:06:50 2000 From: billtut@microsoft.com (Bill Tutt) Date: Sun, 9 Jul 2000 16:06:50 -0700 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC Wi nMain.c,1.3,1.4 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD29A@RED-MSG-50> Heh. Part of the win32 extension building process is to stamp version resources into binaries. That's what the rc file is for. Bill From barry@scottb.demon.co.uk Mon Jul 10 00:15:49 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Mon, 10 Jul 2000 00:15:49 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007092152.QAA14143@cj20424-a.reston1.va.home.com> Message-ID: <000401bfe9fb$9e5050b0$060210ac@private> The key problem here is that the python engine needs to verify the version of python that the extension supports before allowing the extension to do anything dangerous. Maybe the solution is a pair of functions and a bit of protocol. The first function is used for version checking. int check_version_##module_name(); The second function will do the init as today. init init##module_name(); Based on the outcome of calling the check_version function python can decide if it should call the init function. Issues with the check_version function that I can think of are: * how is a python version represented? * should the check_version function be passed the calling python's version? This would allow smart extensions to adapt to the invoking python's version dependent features. Barry From mhammond@skippinet.com.au Mon Jul 10 00:48:49 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 9 Jul 2000 19:48:49 -0400 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 In-Reply-To: <019501bfe920$18cee220$f2a6b5d4@hagrid> Message-ID: > stupid question: what exactly does the RC file do here: > > STRINGTABLE DISCARDABLE > BEGIN > 2000 "Dummy" // Needed to version branding works! > END > > (couldn't really parse that comment ;-) The "to" should be "so" - that will make it parse better, but probably still doesnt answer your question :-) Greg wrote a script that I use to brand .DLL/.EXE files with a version resource - eg, I brand the win32all package _after_ the final build - the version strings are written after it has been built and tested. However, this code fails for .DLL/.EXE files without any resources at all. This dummy resource gets around that problem. It can safely be ignored for inclusion into the core... Mark. From mhammond@skippinet.com.au Mon Jul 10 00:48:52 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 9 Jul 2000 19:48:52 -0400 Subject: [Python-Dev] new popen for win32! In-Reply-To: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> Message-ID: > - first, a stupid question: is the popen2 and popen3 > versions replacements for the corresponding functions > in the popen2 module. I believe Bill was first :-) Note that the param order may be different, and should be made the same. > (or to put it another way: should the popen2 module > be modified to use these functions on Windows?) IMO, yes. > - should this go into the "nt" (posix) module, or should > I create a new module? for no good reason, I would lean towards the NT module, but a seperate source file. > - "win32popenWin9x.exe" is a rather unwieldy name for a > file. does anyone have a better suggestion? I think the name can be unwieldy, as no one will ever execute this directly. The name should reflect its purpose, so no one says "hey - I never run this .exe, so I can remove it. > py_popen9x.exe I agree with Tim that "popen9x.exe" is fine. > - I'm using VC5 on this box, so I should probably avoid > checking in my modified project files. any VC6-wielding > volunteers out there? If its not done by the time I return to Oz, I will be happy to do it. However, I bet Bill beats me too it (unless someone explains to Tim what is expected of him, and off he goes :-) Mark. From peter@schneider-kamp.de Mon Jul 10 03:14:05 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 02:14:05 +0000 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix References: <396780B6.67247E2C@stud.ntnu.no> <200007082334.SAA08816@cj20424-a.reston1.va.home.com> <39690818.917030DE@stud.ntnu.no> <20000710002644.G26534@xs4all.nl> Message-ID: <3969316D.467C85FA@stud.ntnu.no> Thomas Wouters wrote: > > Hm, strange. It works fine here. Do you get the segfault every time ? What system? Which version (I guess this day's CVS)? I get the segfault every time the error should be thrown. > Anyway, a possible problem is that PyString_InternFromString might return > NULL, and you later PyDict_GetItem() with it (not sure if that's a problem), > and you pass it to com_newlocal_o (not sure if that's a problem either), and > then you Py_DECREF it. And if you pass NULL to that macro you do have a > problem :) You should use Py_XDECREF() if you aren't sure wether the object > is NULL or not. No, that does not seem to be the problem. The segfault happens in PyErr_NormalizeException where PyClass_Check(type) accesses type->ob_type. I'm giving up for today. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From esr@thyrsus.com Mon Jul 10 01:40:09 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sun, 9 Jul 2000 20:40:09 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: ; from pingster@ilm.com on Fri, Jul 07, 2000 at 03:26:13PM -0700 References: <20000707103308.8074FE2673@oratrix.oratrix.nl> Message-ID: <20000709204009.A4566@thyrsus.com> Ka-Ping Yee : > Hmm, i rather like this idea. Actually, i like it enough to > suggest that "launch" would be a good interface to external > applications -- > > launch.filebrowser("/home") > launch.webbrowser("http://www.python.org/", newwindow=1) > launch.mailreader() > launch.mailcomposer("python-dev@python.org", subject="Spam") > launch.textviewer("README") > launch.texteditor("spam.py") > launch.shell("/usr") > launch.remoteshell("unseen.python.org", port=23) > > On Unix this would take advantage of (and formalize) the PAGER, > EDITOR, BROWSER, etc. environment variables; on Windows they > could look at registry settings, and for Mac, they could use IC. I like it. -- Eric S. Raymond ..every Man has a Property in his own Person. This no Body has any Right to but himself. The Labour of his Body, and the Work of his Hands, we may say, are properly his. .... The great and chief end therefore, of Mens uniting into Commonwealths, and putting themselves under Government, is the Preservation of their Property. -- John Locke, "A Treatise Concerning Civil Government" From guido@beopen.com Mon Jul 10 02:49:26 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 20:49:26 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Sun, 09 Jul 2000 17:38:24 EST." <3968FEE0.E1345788@prescod.net> References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> Message-ID: <200007100149.UAA16917@cj20424-a.reston1.va.home.com> > Guido van Rossum wrote: > > > > ... > > Nice idea... Unfortunately it means that every module must be > > changed. If we want to do this, we'd best introduce a macro! > > E.g. (untested): > > > > #define Py_INIT(modname) DL_EXPORT(void) init20##modname() Paul Prescod replies: > Why is it that the init function names has to change for each module? > Why not PyModuleMain or something? Because Python supports a configuration time option to link modules statically. BArry Scott replies: > The key problem here is that the python engine needs to > verify the version of python that the extension supports > before allowing the extension to do anything dangerous. > > Maybe the solution is a pair of functions and a bit of > protocol. > > The first function is used for version checking. > > int check_version_##module_name(); > > The second function will do the init as today. > > init init##module_name(); > > Based on the outcome of calling the check_version function > python can decide if it should call the init function. > > Issues with the check_version function that I can think of > are: > > * how is a python version represented? > * should the check_version function be passed the calling > python's version? This would allow smart extensions to > adapt to the invoking python's version dependent features. There are endless variations on this theme. What's missing at the moment is a bit of requirements analysis. What's the problem we're trying to solve here? So far, the only problem that came up was that on Windows, you get an obscure crash when trying to load an extension built for Python 1.5(.x). Do we really need a whole new version negotiating architecture? You can already get the version string by looking at Py_GetVersion() -- this also answers the question of how a version is represented. On Windows, link-time compatibility is broken whenever we change the second digit of the version number, e.g. 15, 16, 20. On Unix, there's also a different version (the API version, see modsupport.h) which is checked when the module initializes itself (it's hidden in the call to Py_InitModule() that the module makes). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Mon Jul 10 03:09:04 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 21:09:04 -0500 Subject: [Python-Dev] new popen for win32! [status update] In-Reply-To: Your message of "Mon, 10 Jul 2000 00:57:16 +0200." <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> <200007092202.RAA14221@cj20424-a.reston1.va.home.com> <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> Message-ID: <200007100209.VAA16999@cj20424-a.reston1.va.home.com> > oh, I just changed things around the other way (assuming that > "popen2" was some kind of standard). > > changing things is trivial, decided what's the right way to do it > is harder. here's another idea: > > one way to solve this would be to deprecate "popen2", and move > that functionality into the os module -- with the return values > sorted out. that is, let's introduce: > > f = os.popen(cmd, mode, bufsize) > w, r = os.popen2(cmd, mode, bufsize) > w, r, e = os.popen3(cmd, mode, bufsize) > w, r = os.popen4(cmd, mode, bufsize) # windows only, at the moment > > and mark popen2 as obsolete. > > whaddayathink? Ah, I finally see the problem here. Sigh... Both orders are equally logical -- depending on your point of view! This is of course because pipes have a read end and a write end. So stdin is read by the child but written by the parent, and stdout is written by the child and read by the parent. From the parent's point of view, it almost makes sense to put stdout first and stdin second, because this is the familiar order (read, write). I believe this was the original reasoning when popen2 was created (and there was no popen3). Unfortunately it doesn't extend for popen3. So the best order to keep our sanity is really to return (stdin,stdout,stderr), with the understanding that, as this is the parent, stdin must be *written* and stdout/stderr must be *read*. I still can't figure out whether this is what your latest patch does (wouldn't it make sense if os.popen2 and os.popen3 were also available on Unix?) but that's how it should be. Sorry if I confused you more. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake@beopen.com Mon Jul 10 03:38:01 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 22:38:01 -0400 (EDT) Subject: [Python-Dev] PROTO_LIST in Modules/md5.h In-Reply-To: <200007092234.RAA14334@cj20424-a.reston1.va.home.com> References: <3968EAEB.A06D9A38@stud.ntnu.no> <14696.53313.296096.777677@cj42289-a.reston1.va.home.com> <200007092234.RAA14334@cj20424-a.reston1.va.home.com> Message-ID: <14697.14089.167736.898381@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > Of course, it's not high priority stuff, but sometimes it helps > putting our "mark" on code. :-) Hey, we should talk to my dog. She knows all about marking her territory. ;-) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tmacd@eintelligence-inc.com Mon Jul 10 04:27:05 2000 From: tmacd@eintelligence-inc.com (Tom MacDonald) Date: Sun, 9 Jul 2000 22:27:05 -0500 (CDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: from "Tim Peters" at Jul 09, 2000 01:23:03 AM Message-ID: <200007100327.e6A3R5F25974@sundeva.eintelligence-inc.com> > [Tim, pushing the adoption of some C9X-like typedefs in Python's source] > > ... > > the-committee-wasn't-just-jerking-off-the-last-10-years-ly y'rs - > > tim > > [Ken Manheimer] > > (The obvious question is, where they doing those other things at the same > > time, or during breaks?) > > It varies by member. For example, the Reverend Tom MacDonald jerked off > non-stop the entire time (& I've copied him on this for confirmation). But > a surprising number of the members have never jerked off at all! You know me Tim. Ever since you showed me the pictures of mad dog and butcher vachon I can't stop. Interesting question but the committee never took a role call vote on that question. > Rev Tom, after 118 years serving on X3J11, do you think C9X is a good thing > or a bad thing? And do you still get off on it regardless? And what does > God think about C9X? If I have to boil C99 down to either good or bad, I'll pick good. It cleans up a lot of fuzzy words from C89, addresses some missing features that should be there (e.g., variable length arrays, long long, hex floating constants, // comments, , intmax_t, mixed declarations and code, designated initializers). There are features, though, that I wish were not there. The biggest being the complex type. This seems a tad ironic since I pushed for complex early on in the C99 process. I didn't realize that IEEE arithmetic made a complex type grow like the blob - even an imaginary type is there for those that want everything IEEE arithmetic has to offer. I18N was added (I think). I never could figure out if we made everybody that spoke their own language happy or not. It sure made C99 a lot bigger. Almost all of it in the library - though an implementation can support identifiers containing international characters. I don't like the following features: flexible array members, the number of new functions and operators required to support IEEE arithmetic, the LIA compatibility annex, and C99 style boolean support. I like the rest of it. However, no matter what I think, I don't see any vendors rushing to implement C99. Instead vendors are picking some C99 features and implementing those. So, perhaps the the answer to the question of whether C99 is good or bad is only interesting if someone actually implements it. Actually, you need several vendors to implement it. One reason C89 was so successful is that all vendors implemented it. I still like C. In my new job I'm using C++ all the time. I'm probably getting old and can't appreciate all this stuff C++ does for me under the covers, but I can never figure out which overloaded function or operator is actually instantiated by template such-n-such. With C, I can always see what's going on. So yes, I sill got off on it. I asked God what he thought about C99 and he said he didn't have an opinion on C99 cause he always uses python. Rev. Tom From fdrake@beopen.com Mon Jul 10 04:59:26 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 23:59:26 -0400 (EDT) Subject: [Python-Dev] ANSI-fication patches Message-ID: <14697.18974.492954.234194@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp recently submitted a large number of patches to make the C sources in the Modules/ directory ANSI compliant. I've passed most of these back to him for checkin, but for a number of them he commented that he had not tested them (presumably because he doesn't have SGI hardware, or some of the esoteric libraries shipped with IRIX). If someone could look at the ones that are still unassigned and comment on their passing tests, that would be great. Just add a comment to the patch or mark it accepted and pass it back to Peter ("nowonder" on SF). Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Moshe Zadka Mon Jul 10 06:04:05 2000 From: Moshe Zadka (Moshe Zadka) Date: Mon, 10 Jul 2000 08:04:05 +0300 (IDT) Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: Message-ID: On Sun, 9 Jul 2000, Jeremy Hylton wrote: > In the Perl world, there is a weekly summary of discussion on the > perl5-porters list. It seems to be written by Mark-Jason Dominus most > (all?) of the time. We could do the same thing if we could find people to > do it. Perhaps a weekly Python-dev URL? If we had enough reporters, it > might not be too much work. > > Volunteers? I'd be happy to coordinate. I can volunteer, but I'd like to know a week in advance (and not every week, obviously) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From Moshe Zadka Mon Jul 10 06:15:21 2000 From: Moshe Zadka (Moshe Zadka) Date: Mon, 10 Jul 2000 08:15:21 +0300 (IDT) Subject: [Python-Dev] Out of loop... In-Reply-To: <20000709214058.D26534@xs4all.nl> Message-ID: On Sun, 9 Jul 2000, Thomas Wouters wrote: > On Sun, Jul 09, 2000 at 03:21:41PM -0400, Fred L. Drake, Jr. wrote: > > > Ok, it's been a busy week, and my wife & kids are just about back. > > I'll be largely out of touch here for about 24 hours. It's time to > > play with the kids! > > Damn, this scares me. Even at my real-life job we don't warn eachother when > we're out of the loop for a day or so. We've had a colleague go on a > vacation, and not be missed for like a week before anyone started wondering > where he was ;-) And here is Fred apologizing for spending a day with his > family. Is it too late for me to opt out ?!? Fred does it only out of courtesy. The PSU keeps track of all Python-Dev members, in case on of them is needed. If you need to find some Python-Dev member, just contact your local PSU representative. if-you-don't-know-who-he-is-you-got-a-*big*-problem-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From peter@schneider-kamp.de Mon Jul 10 08:47:44 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 07:47:44 +0000 Subject: [Python-Dev] CVS read/write access Message-ID: <39697FA0.ADD1BB17@stud.ntnu.no> Thanks to Fred I now have 35 of my own patches assigned to me. Unfortunately trying to checkout read/write in order to be able to commit later I get this: nowonder@mobility:~/python > export CVS_RSH=ssh nowonder@mobility:~/python > export CVSROOT=nowonder@cvs.python.sourceforge.net:/cvsroot/python nowonder@mobility:~/python > cvs co python nowonder@cvs.python.sourceforge.net's password: Sorry, you don't have read/write access to the history file /cvsroot/python/CVSROOT/history Permission denied nowonder@mobility:~/python > As I also see no way to change the status of my patches, maybe some UserPermissions still need to be set. Maybe something like ? CVS write: yes ? Patch Manager: Tech & Admin But then I don't really know that much about sourceforge. For my own pet project (LegoVision) I just got one developer ;-) Thanks anyway, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From tim_one@email.msn.com Mon Jul 10 07:14:56 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 02:14:56 -0400 Subject: [Python-Dev] CVS read/write access In-Reply-To: <39697FA0.ADD1BB17@stud.ntnu.no> Message-ID: [Peter Schneider-Kamp] > Thanks to Fred I now have 35 of my own patches assigned to me. > Unfortunately trying to checkout read/write in order to be > able to commit later I get this: > > nowonder@mobility:~/python > export CVS_RSH=ssh > nowonder@mobility:~/python > export > CVSROOT=nowonder@cvs.python.sourceforge.net:/cvsroot/python Perhaps CVSROOT should have :ext: at the start? Here's mine: set CVSROOT=:ext:tim_one@cvs.python.sourceforge.net:/cvsroot/python Monkey see, monkey do, usually works best for software written by apes . > nowonder@mobility:~/python > cvs co python > nowonder@cvs.python.sourceforge.net's password: > Sorry, you don't have read/write access to the history file > /cvsroot/python/CVSROOT/history > Permission denied > nowonder@mobility:~/python > > As I also see no way to change the status of my patches, maybe > some UserPermissions still need to be set. > Maybe something like > > ? CVS write: yes > ? Patch Manager: Tech & Admin Bingo on this one: your Patch Manager permissions were set to "Tech only". I think that's the default. I've changed them to "Tech & Admin" for nowonder, so that problem should be solved now. > But then I don't really know that much about sourceforge. For my own > pet project (LegoVision) I just got one developer ;-) Ya, but at least you can release it when you want to . grass-is-greener-ly y'rs - tim From peter@schneider-kamp.de Mon Jul 10 09:27:47 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 08:27:47 +0000 Subject: [Python-Dev] CVS read/write access References: Message-ID: <39698903.1EFDBFBA@stud.ntnu.no> Tim Peters wrote: > > Perhaps CVSROOT should have > > :ext: > > at the start? Here's mine: > > set CVSROOT=:ext:tim_one@cvs.python.sourceforge.net:/cvsroot/python No, doesn't change a thing. Unfortunately. > Monkey see, monkey do, usually works best for software written by apes > . Just what I did. Just that I looked at the CVS Howto. But I think the problem is somewhere else. > Bingo on this one: your Patch Manager permissions were set to "Tech only". > I think that's the default. I've changed them to "Tech & Admin" for > nowonder, so that problem should be solved now. Yes, thanx alot! Wasn't there something about CVS write access though? > > But then I don't really know that much about sourceforge. For my own > > pet project (LegoVision) I just got one developer ;-) > > Ya, but at least you can release it when you want to . Ooh, where is the point in the license telling me I cannot release Python, too <1.5 wink>? just-joking-but-wait-a-month-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From tim_one@email.msn.com Mon Jul 10 08:02:39 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 03:02:39 -0400 Subject: [Python-Dev] CVS read/write access In-Reply-To: <39698903.1EFDBFBA@stud.ntnu.no> Message-ID: >> Perhaps CVSROOT should have >> >> :ext: >> >> at the start? Here's mine: >> >> set CVSROOT=:ext:tim_one@cvs.python.sourceforge.net:/cvsroot/python [Peter S-K] > No, doesn't change a thing. Unfortunately. I was well beyond my area of competence with the first suggestion . You could get a real OS like me (Win98SE), or hope that one of your Unixish compatriots helps out. Maybe it would help if you told them other stuff about your setup (OS, version, CVS version, whether CVS works in other contexts for you, etc). > ... Wasn't there something about CVS write access though? *Everyone* on the Member Admin page has "Yes" under "CVS write", and there are no controls there even to change that to "No". Maybe it's one of these 4-hour SourceForge delay thingies? Doubt it, but it's a darned good excuse for me to go to sleep now . > Ooh, where is the point in the license telling me I cannot > release Python, too <1.5 wink>? > > just-joking-but-wait-a-month-ly y'rs > Peter Indeed, if we still haven't released Python after another month, I'm going to leave BeOpen PythonLabs and go to work somewhere I can <0.6 wink>. From Fredrik Lundh" Message-ID: <004201bfea3f$17b154c0$f2a6b5d4@hagrid> Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv16446 >=20 > Modified Files: > md5.h md5c.c=20 > Log Message: >=20 > Guido said include these in the Great ANSI-fication, so here they are! weren't you supposed to drop out of sight for a while? besides, I'd assigned these patches to myself, and applied them locally. just thought I'd get some sleep before I checked them in again. (iow, please check the patch archive before hacking along. someone else might be working on the same thing) From peter@schneider-kamp.de Mon Jul 10 10:27:49 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 09:27:49 +0000 Subject: [Python-Dev] CVS read/write access References: Message-ID: <39699715.E3368F53@stud.ntnu.no> Tim Peters wrote: > > I was well beyond my area of competence with the first suggestion . > You could get a real OS like me (Win98SE), or hope that one of your Unixish > compatriots helps out. Maybe it would help if you told them other stuff > about your setup (OS, version, CVS version, whether CVS works in other > contexts for you, etc). No, this is a python/sourceforge thing. cvs/ssh/sourceforge works just fine: nowonder@mobility:~/python > export CVS_RSH=ssh nowonder@mobility:~/python > export CVSROOT=nowonder@cvs.legovision.sourceforge.net:/cvsroot/legovision nowonder@mobility:~/python > cvs co legovision nowonder@cvs.legovision.sourceforge.net's password: cvs server: Updating legovision U legovision/LICENSE.txt U legovision/README.html cvs server: Updating legovision/LookingLego U legovision/LookingLego/ImageProcessing.cpp U legovision/LookingLego/ImageProcessing.h U legovision/LookingLego/InfraRed.cpp U legovision/LookingLego/InfraRed.h [cut - that's enough] > *Everyone* on the Member Admin page has "Yes" under "CVS write", and there > are no controls there even to change that to "No". Maybe it's one of these > 4-hour SourceForge delay thingies? Doubt it, but it's a darned good excuse > for me to go to sleep now . 6 hours that is, but possible. Hadn't thought of that one. I'll just wait some hours and try again (sounds like "okay, I'll reinstall Windows 98SE and try again" :}). I'll save some bandwidth until then, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Fredrik Lundh" I wrote: > besides, I'd assigned these patches to myself, and applied > them locally. just thought I'd get some sleep before I checked > them in again. >=20 > (iow, please check the patch archive before hacking along. > someone else might be working on the same thing) oh, I see. these patches were marked as "accepted", so they didn't show up on the main page. this is clearly a drawback of the "open =3D> accepted =3D> closed" scheme; you have to check several places before you know if something is being worked on... (having an "all except closed, rejected, delete" selection would be nice. roundup can do that, of course ;-) From gstein@lyra.org Mon Jul 10 09:32:50 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 01:32:50 -0700 Subject: [Python-Dev] CVS: python/dist/src/Modules posixmodule.c,2.143,2.144 In-Reply-To: <200007091310.GAA27888@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Sun, Jul 09, 2000 at 06:10:48AM -0700 References: <200007091310.GAA27888@slayer.i.sourceforge.net> Message-ID: <20000710013250.P29590@lyra.org> hmm. should that be PyLong_FromVoidPtr() ? It will return the appropriate object type based on the size of a void*. Cheers, -g On Sun, Jul 09, 2000 at 06:10:48AM -0700, Fredrik Lundh wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv27646/Modules > > Modified Files: > posixmodule.c > Log Message: > > > - fixed pointer size test in spawn functions. also added > cast to make sure Py_BuildValue gets the right thing. > > this change eliminates bogus return codes from successful > spawn calls (e.g. 2167387144924954624 instead of 0). > > Index: posixmodule.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v > retrieving revision 2.143 > retrieving revision 2.144 > diff -C2 -r2.143 -r2.144 > *** posixmodule.c 2000/07/08 22:48:53 2.143 > --- posixmodule.c 2000/07/09 13:10:40 2.144 > *************** > *** 1541,1548 **** > return posix_error(); > else > ! #if SIZEOF_LONG == SIZE_VOID_P > ! return Py_BuildValue("l", spawnval); > #else > ! return Py_BuildValue("L", spawnval); > #endif > } > --- 1541,1548 ---- > return posix_error(); > else > ! #if SIZEOF_LONG == SIZEOF_VOID_P > ! return Py_BuildValue("l", (long) spawnval); > #else > ! return Py_BuildValue("L", (LONG_LONG) spawnval); > #endif > } > *************** > *** 1649,1656 **** > (void) posix_error(); > else > ! #if SIZEOF_LONG == SIZE_VOID_P > ! res = Py_BuildValue("l", spawnval); > #else > ! res = Py_BuildValue("L", spawnval); > #endif > > --- 1649,1656 ---- > (void) posix_error(); > else > ! #if SIZEOF_LONG == SIZEOF_VOID_P > ! res = Py_BuildValue("l", (long) spawnval); > #else > ! res = Py_BuildValue("L", (LONG_LONG) spawnval); > #endif > > > > _______________________________________________ > Python-checkins mailing list > Python-checkins@python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Mon Jul 10 09:43:29 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 01:43:29 -0700 Subject: [Python-Dev] CVS read/write access In-Reply-To: <39699715.E3368F53@stud.ntnu.no>; from petersc@stud.ntnu.no on Mon, Jul 10, 2000 at 09:27:49AM +0000 References: <39699715.E3368F53@stud.ntnu.no> Message-ID: <20000710014329.Q29590@lyra.org> I lost the original note, but I recall that it said you couldn't write the "history" file. If so, then it is a problem that the SF Admins must solve. It means that you haven't been placed into the appropriate group or somesuch on SF. Log a support request with the copy of your output. Cheers, -g On Mon, Jul 10, 2000 at 09:27:49AM +0000, Peter Schneider-Kamp wrote: > Tim Peters wrote: > > > > I was well beyond my area of competence with the first suggestion . > > You could get a real OS like me (Win98SE), or hope that one of your Unixish > > compatriots helps out. Maybe it would help if you told them other stuff > > about your setup (OS, version, CVS version, whether CVS works in other > > contexts for you, etc). > > No, this is a python/sourceforge thing. cvs/ssh/sourceforge works just > fine: > > nowonder@mobility:~/python > export CVS_RSH=ssh > nowonder@mobility:~/python > export > CVSROOT=nowonder@cvs.legovision.sourceforge.net:/cvsroot/legovision > nowonder@mobility:~/python > cvs co legovision > nowonder@cvs.legovision.sourceforge.net's password: > cvs server: Updating legovision > U legovision/LICENSE.txt > U legovision/README.html > cvs server: Updating legovision/LookingLego > U legovision/LookingLego/ImageProcessing.cpp > U legovision/LookingLego/ImageProcessing.h > U legovision/LookingLego/InfraRed.cpp > U legovision/LookingLego/InfraRed.h > [cut - that's enough] > > > *Everyone* on the Member Admin page has "Yes" under "CVS write", and there > > are no controls there even to change that to "No". Maybe it's one of these > > 4-hour SourceForge delay thingies? Doubt it, but it's a darned good excuse > > for me to go to sleep now . > > 6 hours that is, but possible. Hadn't thought of that one. I'll > just wait some hours and try again (sounds like "okay, I'll > reinstall Windows 98SE and try again" :}). > > I'll save some bandwidth until then, > Peter > -- > Peter Schneider-Kamp ++47-7388-7331 > Herman Krags veg 51-11 mailto:peter@schneider-kamp.de > N-7050 Trondheim http://schneider-kamp.de > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Mon Jul 10 10:09:31 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:09:31 -0700 Subject: [Python-Dev] Re: CVS: python/dist/src/Lib locale.py,1.7,1.8 In-Reply-To: <200007091713.KAA02613@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Sun, Jul 09, 2000 at 10:13:00AM -0700 References: <200007091713.KAA02613@slayer.i.sourceforge.net> Message-ID: <20000710020930.T29590@lyra.org> This checkin was *very* hard to review. In fact, I just gave up. The problem is that you did functional changes *AND* white space changes. A bunch of lines appear changed, but they're just whitespace change. The *real* changes are hidden in there somewhere. Can I request (from everyone) to do white space changes *only*, or to do functional changes *only*. It will make it a lot easier on the people who are reviewing the checkins. thx! -g On Sun, Jul 09, 2000 at 10:13:00AM -0700, Fredrik Lundh wrote: > Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2501/Lib > > Modified Files: > locale.py > Log Message: > > > - merged setlocale and set_locale. the internal setlocale > function is overridden by a python version which accepts > *either* a string (old behaviour) or a locale tuple. > > - renamed a few methods (for consistency): > > get_locale => getlocale > get_default_locale => getdefaultlocale > set_to_default => resetlocale (!) > > - the _locale implementation module can now implement > an optional _getdefaultlocale function. if that function > isn't available, a POSIX-based approach is used (checking > LANG and other environment variables, as usual). -- Greg Stein, http://www.lyra.org/ From Fredrik Lundh" <20000710020930.T29590@lyra.org> Message-ID: <00b901bfea4f$7f24d720$f2a6b5d4@hagrid> greg wrote: > This checkin was *very* hard to review. In fact, I just gave up. >=20 > The problem is that you did functional changes *AND* white space = changes. A > bunch of lines appear changed, but they're just whitespace change. The > *real* changes are hidden in there somewhere. my current editor setup strips bogus trailing whitespace all by itself. once they're gone, it's a bit hard to put them back... the important changes are in getdefaultlocale and the overriding setlocale function. From gstein@lyra.org Mon Jul 10 10:20:48 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:20:48 -0700 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007100149.UAA16917@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Sun, Jul 09, 2000 at 08:49:26PM -0500 References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> Message-ID: <20000710022047.V29590@lyra.org> On Sun, Jul 09, 2000 at 08:49:26PM -0500, Guido van Rossum wrote: > > Guido van Rossum wrote: > > > > > > ... > > > Nice idea... Unfortunately it means that every module must be > > > changed. If we want to do this, we'd best introduce a macro! > > > E.g. (untested): > > > > > > #define Py_INIT(modname) DL_EXPORT(void) init20##modname() > > Paul Prescod replies: > > > Why is it that the init function names has to change for each module? > > Why not PyModuleMain or something? > > Because Python supports a configuration time option to link modules > statically. Not to mention that the .so is loaded into the process' address space. I don't think that you can have two symbols in the space with the same name. But hey... even if you can: the static link option Guido mentions is definitely the kicker. Cheers, -g -- Greg Stein, http://www.lyra.org/ From peter@schneider-kamp.de Mon Jul 10 12:29:29 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 11:29:29 +0000 Subject: [Python-Dev] file closed! (was Re: CVS read/write access) References: <39699715.E3368F53@stud.ntnu.no> <20000710014329.Q29590@lyra.org> Message-ID: <3969B399.FC5E1AC2@stud.ntnu.no> Greg Stein wrote: > > If so, then it is a problem that the SF Admins must solve. It means that you > haven't been placed into the appropriate group or somesuch on SF. Log a ----- It was the group. But 20 minutes after I found out I checked again and suddenly python had appeared. Must have been this cron delay. Sorry-for-wasting-your-time Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gstein@lyra.org Mon Jul 10 10:35:24 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:35:24 -0700 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 09, 2000 at 05:07:40PM -0400 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Message-ID: <20000710023523.Y29590@lyra.org> bah. just file feature requests for them to use ViewCVS. cvsweb is a piece of crap anyways :-) Cheers, -g On Sun, Jul 09, 2000 at 05:07:40PM -0400, Tim Peters wrote: > [Fred L. Drake, Jr. > Sent: Wednesday, June 28, 2000 9:30 AM] > > ... > > the only problem I've had with IE5 is accessing a project's anonymous > > FTP area from the project page (IE5 just froze completely). > > This happens to me too. > > And a new problem popped up early this weekend (maybe Friday already): when > I click the "Browse CVS Repository" link near the bottom right of > > http://sourceforge.net/cvs/?group_id=5470 > > IE5 pops up a box asking me whether I really want to download file "cvsweb". > Useless! This used to work fine, and I sure haven't changed my IE setup. > Clearing the browser caches didn't help. The link resolves to > > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi?cvsroot=python > > today, and I don't know whether it resolved to something different last > week. Also have no idea how browsers decide what to do -- it's not simple & > straightforward, like e.g. floating-point arithmetic . .cgi is not an > extension registered on my machine either. -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Mon Jul 10 10:40:58 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:40:58 -0700 Subject: [Python-Dev] [OT] IE5 weirdness (was: Sourceforge Interface Concerns) In-Reply-To: <20000709235547.F26534@xs4all.nl>; from thomas@xs4all.net on Sun, Jul 09, 2000 at 11:55:47PM +0200 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> <20000709235547.F26534@xs4all.nl> Message-ID: <20000710024058.Z29590@lyra.org> On Sun, Jul 09, 2000 at 11:55:47PM +0200, Thomas Wouters wrote: >... >... Content-Type and Content-Disposition discussion ... >... > All in all, I'm no longer suprised when something dynamic (CGI scripts, > php/asp/jsp pages, whatever) refuses to work properly with IE ;) Quite a > depressing thing to know, this, but you can't always blame the > website-owners or the software developers. No doubt. I'm there with you. While working on the DAV stuff, I found that it totally bombs on a GET on a DAV resource when the Last-Modified header is not returned. (!!) Of course, dynamic scripts practically never return that, so I had to insert the following in my httpd.conf: Header set Last-Modified "Fri, 03 Mar 2000 06:32:31 GMT" Pretty fuggin broken, if you ask me :-) Oh. Even more broken: it makes you send the time. It doesn't display it in the Windows Explorer / Web Folder like you would expect. The "Modified" column is simply blank. *boggle* Cheers, -g -- Greg Stein, http://www.lyra.org/ From jack@oratrix.nl Mon Jul 10 10:45:41 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 10 Jul 2000 11:45:41 +0200 Subject: [Python-Dev] Symantec C compiler Message-ID: <20000710094541.9A02C37186D@snelboot.oratrix.nl> Folks, there are talks in python-dev of cleaning out ifdefs for the Symantec C compiler (__SC__). So, if anyone still uses it: scream loudly now or remain forever silent. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From gstein@lyra.org Mon Jul 10 10:49:05 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:49:05 -0700 Subject: [Python-Dev] [OT] version branding (was: CVS: python/dist/src/PC WinMain.c,1.3,1.4) In-Reply-To: ; from mhammond@skippinet.com.au on Sun, Jul 09, 2000 at 07:48:49PM -0400 References: <019501bfe920$18cee220$f2a6b5d4@hagrid> Message-ID: <20000710024905.A29590@lyra.org> On Sun, Jul 09, 2000 at 07:48:49PM -0400, Mark Hammond wrote: > > stupid question: what exactly does the RC file do here: > > > > STRINGTABLE DISCARDABLE > > BEGIN > > 2000 "Dummy" // Needed to version branding works! > > END > > > > (couldn't really parse that comment ;-) > > The "to" should be "so" - that will make it parse better, but probably > still doesnt answer your question :-) > > Greg wrote a script that I use to brand .DLL/.EXE files with a version > resource - eg, I brand the win32all package _after_ the final build - the > version strings are written after it has been built and tested. Heh. I wrote that after going through gyration after frustrating gyration with the Site Server "Build Team". Those guys had their little fiefdom and were responsible for building the product. You had to conform to their idiotic concepts and tools. Well, one of the worst was this complicated set of include files, macros, and other small tools to construct a version resource in the .rc file. Well, during the build process, you had to make sure that the "write the current version into so it can be picked up by the version.rc include stuff" actually got run. Of course, when you're developing code, what is the "current version"? etc etc. It was a horrible mess. So I ripped it all out and post-processed the DLL/EXE files. "ah. it built fine, passes the initial test suite, let's brand it and release for full testing." Slick as hell. Of course, the Build Team sure didn't like that. Much too easy. Might put them out of a job... :-) -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Mon Jul 10 11:00:36 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 12:00:36 +0200 Subject: [Python-Dev] Unicode maintainer wanted (was: Encodings) References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> Message-ID: <39699EC4.C4B30FC8@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > Sorry, but I'm really surprised now: I've put many hours of > > work into this, hacked up encoding support for locale.py, > > went through endless discussions, proposed the changable default > > as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy > > My recollection was that the purpose of the changable default was so > that we could experiment with different defaults more easily, not that > we'd keep it changable. That was the original idea -- noone actually did test this, though, after the hooks were in place... Then Guido (or was it someone else?) came up with the idea of making the default encoding depend on the default locale active at Python startup time and it turned out to satisfy proponents of all three encodings. Guido gave his OK in private mail, Fredrik was satisfied, a few people supported the decision in private mail and the rest made their agreement clear via collective silence. I then tried to hack up ways of extracting the encoding information from the locale settings -- not exactly an easy task and one which involved much research, two or three design cycles (in public on python-dev) and much refinement on the locale name mappings. All this took quite a lot of my time which I felt was worth investing to get all proponents happy. I, for one, still think that the fixed UTF-8 encoding was the best choice of all possibilities. Coding the locale stuff was meant as signal for compromise from my part and now the whole idea get's marked as failed experiment... > I'm not an expert on these issues and have tried to stay out of the > way on the discussion, but the idea of a changable default just seems > like we're asking for trouble. > I'm sorry that you feel your efforts have been wasted; I don't think > anyone tried to spend your time without careful consideration, but it > is important that we all understand what we have gained from this > experiment. > Before you implemented the changable default, we all had the > opportunity to presume to know how things would work with it, and > could bitch or plead about it as we felt appropriate. Now that it's > been tried, we have a little more real experiance with it, and can > point to the evidence that's been presented here as we each make our > arguments on the topic. > So I'd have to say that your efforts have *not* been wasted; we now > have a very good idea of what's involved and whether "it works." I, > for one, am glad that the experiment was done (and expecially that it > was done by someone who knows more about this than me!). Thanks, Fred, but your words won't change my decision to leave Unicode support to someone else. I don't support the recent decisions that were made and don't feel strong enough for Unicode to take all the blame for things which don't work like some people expect them to. Here's a TODO list for my successor(s): * change hash value calculation to work on the Py_UNICODE data instead of creating a default encoded cached object (what now is .utf8str) * change .utf8str to hold a default encoded string instead of an UTF-8 string (+ rename .utf8str to .defencstr) * document the new stuff in locale.py and TeX the codecs.py APIs (the docstrings are there -- they just need to be converted to the Python TeX style) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Mon Jul 10 10:14:41 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 11:14:41 +0200 Subject: [Python-Dev] Venting some steam on current developments References: <20000709215057.95047E2673@oratrix.oratrix.nl> Message-ID: <39699401.790447E8@lemburg.com> Jack Jansen wrote: > > I'm getting pretty depressed at the way Python development is > proceeding at the moment. You're not the only one. > I spent all evening tonight on what seemed > to be an almost trivial task: fixing the default unicode conversion on > the Mac. All the machinery is there, the MacOS API has some nice > conversion routines so I thought it'd be a question of putting in a > few hooks and be done, but that turned out not to be so. > > The first problem (for which I can't blame the Python community, I > guess:-) is that the names mac_roman and such are not official IANA > names for the Mac encodings. Actually, it turns out there _are_ no > official names, so the Mac APIs to turn encodings into names work > wonderful for things including all ISO encodings, windows encodings, > etc, but not for the native mac encodings. Sigh. Okay, we do this > ourselves. What exactly is your problem here ? The Python codec engine does know about the Mac encodings and even provides mapping tables for them. > Then I spent an hour recompiling Python because this *&^^$%&*^%$ > setdefaultencoding didn't show up in sys for no conceivable reason. It > turns out it is *deleted* in site.py after using it once. A comment in > sysmodule.c would have been rather nice here... There are lots of comments about it in site.py. sys.setdefaultencoding() is meant to be used *only* in site.py-- that's why it gets removed after having made the final decision on the default encoding. > And then I found out that locale uses only environment variables to > obtain all the basic encoding info in the first place, so that also > has to be fixed up seriously. That's not because we don't like Macs, it's simply because the people hacking on the code don't have Macs around to hack something up. But we did politely ask for someone with Mac-knowledge to add the needed support to locale.py. I did the Unix stuff, Fredrik added Windows support and we hoped that Just or you would add Mac support. Note that site.py will simply choose ASCII as default encoding in case it can't figure out what the current default encoding on the platform is -- there's no breakage there... Since all this support is written in Python there should be really no problem adding new hooks to it. > So many things are changing at the moment, and there seems to be so > little thought of any platform that isn't linux or windows, that I > think Python's portability to minority platforms is being seriously > threatened. And at least I follow closely what is happening, I really > don't want to think of the poor people who do BeOS or WinCE or Palm > Python. Or even some of the lesser-used Unix ports. > > I'm fed up, I'll continue hacking tomorrow, if I don't have to spend > yet another evening trying to get Python to compile again:-( -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jack@oratrix.nl Mon Jul 10 11:08:36 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 10 Jul 2000 12:08:36 +0200 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: Message by "Tim Peters" , Sun, 9 Jul 2000 18:33:21 -0400 , Message-ID: <20000710100837.6232337186D@snelboot.oratrix.nl> > Random question: why isn't the Mac code checked into the main CVS tree? The number one problem at the moment is that cvs-over-ssh doesn't work on the mac. So I currently do a diff on the mac, send the patches to unix, patch, submit. This is okay for the once in a while I have a patch to the core, but not for normal mac development. It'll also fail for non-text files. There's a very good free ssh for the Mac, but it's console-only, and there's a pretty abysmal commercial ssh which could possibly be beaten into forwarding connections, but it's expensive (and it doesn't work:-). I hope the situation will become better shortly. > BTW, I heartily agree that the lack of official IANA names for Mac encodings > is not my fault. Ok, fair enough. Who shall we blame then? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From mal@lemburg.com Mon Jul 10 11:19:21 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 12:19:21 +0200 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <200007082206.RAA08314@cj20424-a.reston1.va.home.com> Message-ID: <3969A329.E4D870DD@lemburg.com> Guido van Rossum wrote: > > > Instead of tossing things we should be *constructive* and come > > up with a solution to the hash value problem, e.g. I would > > like to make the hash value be calculated from the UTF-16 > > value in a way that is compatible with ASCII strings. > > I think you are proposing to drop the following rule: > > if a == b then hash(a) == hash(b) > > or also > > if hash(a) != hasb(b) then a != b > > This is very fundamental for dictionaries! The rule is fine for situations where a and b have the same type, but you can't expect coercion to be consistent with it. > Note that it is currently > broken: > > >>> d = {'\200':1} > >>> d['\200'] > 1 > >>> u'\200' == '\200' > 1 > >>> d[u'\200'] > Traceback (most recent call last): > File "", line 1, in ? > KeyError: ? > >>> That's because hash(unicode) currently get's calculated using the UTF-8 encoding as basis, while the compare uses the default encoding -- this needs to be changed, of course. > While you could fix this with a variable encoding, it would be very > hard, probably involving the string to Unicode before taking its hash, > and this would slow down the hash calculation for 8-bit strings > considerably (and these are fundamental for the speed of the > language!). > > So I am for restoring ASCII as the one and only fixed encoding. (Then > you can fix your hash much easier!) > > Side note: the KeyError handling is broken. The bad key should be run > through repr() (probably when the error is raised than when it is > displayed). Agreed. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jack@oratrix.nl Mon Jul 10 11:25:16 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 10 Jul 2000 12:25:16 +0200 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: Message by "Fredrik Lundh" , Mon, 10 Jul 2000 01:12:16 +0200 , <033301bfe9fb$209d3520$f2a6b5d4@hagrid> Message-ID: <20000710102516.7732437186E@snelboot.oratrix.nl> > did you see my changes to the locale module? I rewrote the darn > thing to make it easier to deal with this on non-posix platforms, and > posted the locale.py patch to the patch manager (the CVS repository > had a stale lock, so I couldn't check it in before today). > = > heck, I even sent you some pseudocode that showed one way to > implement parts of _getdefaultlocale for the mac, and still you claim > that we're ignoring non unix/windows platforms? You're absolutely right, the tone of my previous message was a bit over t= he = top. I hadn't seen your most recent fixes to _locale (which would have sh= own = me the right way to do this for the Mac) nor the discussion on python-dev= over = the weekend (which would have made me aware of the = site.py/sys.setdefaultencoding interaction). Sorry, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++= Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig = ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.= htm = From fredrik@pythonware.com Mon Jul 10 11:48:22 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 12:48:22 +0200 Subject: [Python-Dev] CVS: python/dist/src/Modules posixmodule.c,2.143,2.144 References: <200007091310.GAA27888@slayer.i.sourceforge.net> <20000710013250.P29590@lyra.org> Message-ID: <00a201bfea5c$5ee72280$0900a8c0@SPIFF> greg wrote: > --- posixmodule.c 2000/07/09 13:10:40 2.144 > --- 1541,1548 ---- > return posix_error(); > else > ! #if SIZEOF_LONG == SIZEOF_VOID_P > ! return Py_BuildValue("l", (long) spawnval); > #else > ! return Py_BuildValue("L", (LONG_LONG) spawnval); > #endif > } > hmm. should that be PyLong_FromVoidPtr() ? It will return the appropriate > object type based on the size of a void*. I have no idea; I just fixed the typo... the spawn return value is an int according to the docs and my copy of the header files, so I'll leave it to trent to sort this one out. (it's probably a win64 oddity, and he's the only one here with a win64 box). cheers /F From fredrik@pythonware.com Mon Jul 10 13:10:07 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 14:10:07 +0200 Subject: [Python-Dev] new popen for win32! [status update] References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> <200007092202.RAA14221@cj20424-a.reston1.va.home.com> <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> <200007100209.VAA16999@cj20424-a.reston1.va.home.com> Message-ID: <00de01bfea67$cb12c800$0900a8c0@SPIFF> guido wrote: > So the best order to keep our sanity is really to return > (stdin,stdout,stderr), with the understanding that, as this is the > parent, stdin must be *written* and stdout/stderr must be *read*. ok. > I still can't figure out whether this is what your latest patch does that's what it's supposed to do, at least ;-) the popen2 module now assumes that if the os module exports a popen2 function, it returns the file descriptors in a "sane" order. (same goes for popen3 and popen4, of course). > (wouldn't it make sense if os.popen2 and os.popen3 were also available > on Unix?) definitely. I suggest moving the bulk of popen2.py to os.py (alternatively, to a separate "posixpopen.py" module which is imported from os.py on posix platforms). the popen2 module itself is then reduced to a thin wrapper, and marked as deprecated. comments? From guido@beopen.com Mon Jul 10 14:29:41 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 08:29:41 -0500 Subject: [Python-Dev] non-integer arguments to simple slices in 1.6? Message-ID: <200007101329.IAA18009@cj20424-a.reston1.va.home.com> I got the following email from Scott Johnston which suggests an interesting idea (for 2.0, of course, as that's what we're all working on now). basically, Scott proposes to deprecate __getslice__ (and its friends, __setslice__ and __delslice__) in favor of passing the slice arguments unadorned to __getitem__ if __getslice__ is not defined. On the surface, this seems reasonable to me, except that it doesn't help for extension classes... Any other comments? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------- Forwarded Message (reformatted) Date: Mon, 10 Jul 2000 00:03:07 -0700 From: "Scott F. Johnston" To: guido@python.org Subject: non-integer arguments to simple slices in 1.6? For python 1.6/2.0, have you considered unifying the slice operations? I'd like to be able to use simple "[:]" slice syntax on a class using non-integer indices, and without having negative indices automatically "wrapped". I can do this with the complex slice "[::]" syntax, but adding the extra colon and having two different slicing methods seems inconsistent. (One trapped in __getitem__ receiving unmutated objects in a slice object, the other in __getslice__ receiving mutated ints only.) There is an easy way of unifying this: Allow single-colon slices to be passed unmutated to a __getitem__ method as a slice object IF AND ONLY IF the class doesn't provide a __getslice__ method. (And allow the args to be any object as in the current [::] syntax.) Currently, trying to slice an object without a getslice method raises an error. If my __getitem__ handler is set to handle a [::] slice, why not let it handle [:] slices as well? This would be a good way of slowly depricating the __*slice__ operations. Optimally, I shouldn't have to test for SliceType in my __*item__ methods, and all slices would go unmutated to __*slice__ with an additional step term, but that would break a lot of legacy code. Thanks, - --S ------- End of Forwarded Message From Moshe Zadka Mon Jul 10 13:52:58 2000 From: Moshe Zadka (Moshe Zadka) Date: Mon, 10 Jul 2000 15:52:58 +0300 (IDT) Subject: [Python-Dev] non-integer arguments to simple slices in 1.6? In-Reply-To: <200007101329.IAA18009@cj20424-a.reston1.va.home.com> Message-ID: On Mon, 10 Jul 2000, Guido van Rossum wrote: > I got the following email from Scott Johnston which suggests an > interesting idea (for 2.0, of course, as that's what we're all working > on now). basically, Scott proposes to deprecate __getslice__ (and its > friends, __setslice__ and __delslice__) in favor of passing the slice > arguments unadorned to __getitem__ if __getslice__ is not defined. > > On the surface, this seems reasonable to me, except that it doesn't > help for extension classes... +1. Solving extension classes can be done similarily to the way "in" is solved. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From guido@beopen.com Mon Jul 10 15:08:43 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 09:08:43 -0500 Subject: [Python-Dev] new popen for win32! [status update] In-Reply-To: Your message of "Mon, 10 Jul 2000 14:10:07 +0200." <00de01bfea67$cb12c800$0900a8c0@SPIFF> References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> <200007092202.RAA14221@cj20424-a.reston1.va.home.com> <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> <200007100209.VAA16999@cj20424-a.reston1.va.home.com> <00de01bfea67$cb12c800$0900a8c0@SPIFF> Message-ID: <200007101408.JAA18274@cj20424-a.reston1.va.home.com> > > (wouldn't it make sense if os.popen2 and os.popen3 were also available > > on Unix?) > > definitely. I suggest moving the bulk of popen2.py to os.py (alternatively, > to a separate "posixpopen.py" module which is imported from os.py on > posix platforms). > > the popen2 module itself is then reduced to a thin wrapper, and marked > as deprecated. > > comments? Sounds good to me. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy@beopen.com Mon Jul 10 14:31:38 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 09:31:38 -0400 (EDT) Subject: [Python-Dev] Re: CVS: python/dist/src/Lib locale.py,1.7,1.8 In-Reply-To: <20000710020930.T29590@lyra.org> References: <200007091713.KAA02613@slayer.i.sourceforge.net> <20000710020930.T29590@lyra.org> Message-ID: <14697.53306.858387.422925@bitdiddle.concentric.net> >>>>> "GS" == Greg Stein writes: GS> Can I request (from everyone) to do white space changes *only*, GS> or to do functional changes *only*. It will make it a lot easier GS> on the people who are reviewing the checkins. Only if you checkin in your own whitespaces changes! <0.7 wink> Jeremy From thomas@xs4all.net Mon Jul 10 15:32:33 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 16:32:33 +0200 Subject: [Python-Dev] parallel for-loops. Message-ID: <20000710163233.I26534@xs4all.nl> --mSxgbZZZvrAyzONB Content-Type: text/plain; charset=us-ascii I've attached a patch that adds yet another new feature to Python ;P It's the 'parallel for loop' thing that's come past here and on python-list a few times. Guido sent me the suggested Grammar patch and I went from there, so if I got any of the details wrong, please yell at me, loudly. Here's how it works: >>> for x in [1,2,3,4,5]; y in ['a','b','c','d','e','f','g']: ... print x, y ... 1 a 2 b 3 c 4 d 5 e >>> The two loops are traversed in parallel, like in for x, y in map(None, [1,2,3,4,5], ['a','b','c','d','e','f','g']) *except* that the first IndexError of any of the lists terminates the loop. The syntax is not limited to two lists in parallel, of course! There is no specific limit forced by this patch, so the limit is either the available memory, or the max number of child nodes (32k or so) whichever comes first ;) The patch works internally by passing a tuple of sequences as argument to FOR_LOOP, instead of just a single sequence as before. Likewise, the result of the FOR_LOOP operation is a tuple, which is then unpacked into the proper variables. This is done for all for loops, even single-list ones, so all for-loops take a slight performance hit with this patch. (A tuple-build on entering the loop, and a few iterations, a tuple build and a tuple unpack, even for the common case. I didn't measure it, though.) If this is deemed undesirable, it would be trivial to add a new bytcode, FORMORE_LOOP or such, that handles the multiple-list type of for loop. I almost went ahead and did that, but decided I'd try for a patch that *doesn't* add bytecodes for a change ;) Unfortunately, the patch is binary incompatible, so the bytecode magic does have to be changed. Don't forget to type 'make' inside 'Grammar' after applying it. I'll do some more testing on this, write some docs and some tests, and if noone here has convinced me otherwise, upload it to sourceforge ;) The patch is really suprisingly small and elegant, thanks to Python's extreme simplicity! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! --mSxgbZZZvrAyzONB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="parallelfor.patch" Index: Grammar/Grammar =================================================================== RCS file: /cvsroot/python/python/dist/src/Grammar/Grammar,v retrieving revision 1.35 diff -c -r1.35 Grammar *** Grammar/Grammar 2000/03/28 23:49:00 1.35 --- Grammar/Grammar 2000/07/10 14:06:26 *************** *** 54,60 **** compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | funcdef | classdef if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] while_stmt: 'while' test ':' suite ['else' ':' suite] ! for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite] try_stmt: ('try' ':' suite (except_clause ':' suite)+ #diagram:break ['else' ':' suite] | 'try' ':' suite 'finally' ':' suite) # NB compile.c makes sure that the default except clause is last --- 54,60 ---- compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | funcdef | classdef if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] while_stmt: 'while' test ':' suite ['else' ':' suite] ! for_stmt: 'for' exprlist 'in' testlist (';' exprlist 'in' testlist)* ':' suite ['else' ':' suite] try_stmt: ('try' ':' suite (except_clause ':' suite)+ #diagram:break ['else' ':' suite] | 'try' ':' suite 'finally' ':' suite) # NB compile.c makes sure that the default except clause is last Index: Python/ceval.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/ceval.c,v retrieving revision 2.183 diff -c -r2.183 ceval.c *** Python/ceval.c 2000/07/09 03:09:56 2.183 --- Python/ceval.c 2000/07/10 14:06:28 *************** *** 1473,1481 **** continue; case FOR_LOOP: ! /* for v in s: ... ! On entry: stack contains s, i. ! On exit: stack contains s, i+1, s[i]; but if loop exhausted: s, i are popped, and we jump */ w = POP(); /* Loop index */ --- 1473,1481 ---- continue; case FOR_LOOP: ! /* for v1 in s1; v2 in s2: ... ! On entry: stack contains t(s), i. ! On exit: stack contains t(s), i+1, t(s[i]); but if loop exhausted: s, i are popped, and we jump */ w = POP(); /* Loop index */ *************** *** 2548,2566 **** loop_subscript(v, w) PyObject *v, *w; { ! PySequenceMethods *sq = v->ob_type->tp_as_sequence; ! int i; ! if (sq == NULL || sq->sq_item == NULL) { ! PyErr_SetString(PyExc_TypeError, "loop over non-sequence"); return NULL; } i = PyInt_AsLong(w); ! v = (*sq->sq_item)(v, i); ! if (v) ! return v; ! if (PyErr_ExceptionMatches(PyExc_IndexError)) ! PyErr_Clear(); ! return NULL; } /* Extract a slice index from a PyInt or PyLong, the index is bound to --- 2548,2585 ---- loop_subscript(v, w) PyObject *v, *w; { ! PyObject *res; ! long i; ! int j, len; ! ! if (!PyTuple_Check(v)) { ! PyErr_SetString(PyExc_SystemError, "bad (internal) arg to for loop"); return NULL; } + + len = PyTuple_Size(v); + res = PyTuple_New(len); i = PyInt_AsLong(w); ! ! for (j = 0; j < len; j++) { ! PyObject *u = PyTuple_GET_ITEM(v, j); ! PySequenceMethods *sq = u->ob_type->tp_as_sequence; ! if (sq == NULL || sq->sq_item == NULL) { ! Py_DECREF(res); ! PyErr_SetString(PyExc_TypeError, "loop over non-sequence"); ! return NULL; ! } ! u = (*sq->sq_item)(u, i); ! if (u) { ! PyTuple_SET_ITEM(res, j, u); ! continue; ! } ! if (PyErr_ExceptionMatches(PyExc_IndexError)) ! PyErr_Clear(); ! Py_DECREF(res); ! return NULL; ! } ! return res; } /* Extract a slice index from a PyInt or PyLong, the index is bound to Index: Python/compile.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v retrieving revision 2.114 diff -c -r2.114 compile.c *** Python/compile.c 2000/07/09 03:09:56 2.114 --- Python/compile.c 2000/07/10 14:06:29 *************** *** 2433,2443 **** int break_anchor = 0; int anchor = 0; int save_begin = c->c_begin; REQ(n, for_stmt); ! /* 'for' exprlist 'in' exprlist ':' suite ['else' ':' suite] */ com_addfwref(c, SETUP_LOOP, &break_anchor); block_push(c, SETUP_LOOP); ! com_node(c, CHILD(n, 3)); v = PyInt_FromLong(0L); if (v == NULL) c->c_errors++; --- 2433,2457 ---- int break_anchor = 0; int anchor = 0; int save_begin = c->c_begin; + int inum, i; + REQ(n, for_stmt); ! /* 'for' exprlist 'in' exprlist (';' exprlist 'in' testlist)* ! ':' suite ['else' ':' suite] */ ! ! if (NCH(n) % 2) { ! /* Uneven number of children, so it includes 'else' clause */ ! inum = ((NCH(n) - 5) / 4); ! } else { ! /* No 'else' clause */ ! inum = ((NCH(n) - 2) / 4); ! } com_addfwref(c, SETUP_LOOP, &break_anchor); block_push(c, SETUP_LOOP); ! for (i = 1; i <= inum; i++) ! com_node(c, CHILD(n, i*4 - 1)); ! com_addoparg(c, BUILD_TUPLE, inum); ! com_pop(c, inum-1); v = PyInt_FromLong(0L); if (v == NULL) c->c_errors++; *************** *** 2448,2456 **** com_addoparg(c, SET_LINENO, n->n_lineno); com_addfwref(c, FOR_LOOP, &anchor); com_push(c, 1); ! com_assign(c, CHILD(n, 1), OP_ASSIGN); c->c_loops++; ! com_node(c, CHILD(n, 5)); c->c_loops--; com_addoparg(c, JUMP_ABSOLUTE, c->c_begin); c->c_begin = save_begin; --- 2462,2473 ---- com_addoparg(c, SET_LINENO, n->n_lineno); com_addfwref(c, FOR_LOOP, &anchor); com_push(c, 1); ! com_addoparg(c, UNPACK_TUPLE, inum); ! com_push(c, inum-1); ! for (i = 1; i <= inum; i++) ! com_assign(c, CHILD(n, i*4 - 3), OP_ASSIGN); c->c_loops++; ! com_node(c, CHILD(n, inum*4 + 1)); c->c_loops--; com_addoparg(c, JUMP_ABSOLUTE, c->c_begin); c->c_begin = save_begin; *************** *** 2458,2465 **** com_pop(c, 2); /* FOR_LOOP has popped these */ com_addbyte(c, POP_BLOCK); block_pop(c, SETUP_LOOP); ! if (NCH(n) > 8) ! com_node(c, CHILD(n, 8)); com_backpatch(c, break_anchor); } --- 2475,2483 ---- com_pop(c, 2); /* FOR_LOOP has popped these */ com_addbyte(c, POP_BLOCK); block_pop(c, SETUP_LOOP); ! if (NCH(n) % 2) { ! com_node(c, CHILD(n, inum*4 + 3)); ! } com_backpatch(c, break_anchor); } Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.140 diff -c -r2.140 import.c *** Python/import.c 2000/07/09 03:09:56 2.140 --- Python/import.c 2000/07/10 14:06:31 *************** *** 65,71 **** /* XXX Perhaps the magic number should be frozen and a version field added to the .pyc file header? */ /* New way to come up with the magic number: (YEAR-1995), MONTH, DAY */ ! #define MAGIC (50428 | ((long)'\r'<<16) | ((long)'\n'<<24)) /* Magic word as global; note that _PyImport_Init() can change the value of this global to accommodate for alterations of how the --- 65,71 ---- /* XXX Perhaps the magic number should be frozen and a version field added to the .pyc file header? */ /* New way to come up with the magic number: (YEAR-1995), MONTH, DAY */ ! #define MAGIC (50710 | ((long)'\r'<<16) | ((long)'\n'<<24)) /* Magic word as global; note that _PyImport_Init() can change the value of this global to accommodate for alterations of how the --mSxgbZZZvrAyzONB-- From guido@beopen.com Mon Jul 10 16:32:44 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 10:32:44 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure Message-ID: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> I decided to build the simple embedding demo in Demo/embed/. After fixing the Makefile (checkins coming), I ended up with one problem: the 'import site.py' failed error. When using -v I get this traceback: 'import site' failed; traceback: Traceback (most recent call last): File "/usr/local/lib/python2.0/site.py", line 146, in ? sys.setdefaultencoding('ascii') LookupError: no codec search functions registered: can't find encoding Is there some part of the initialization that I'm forgetting? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas@xs4all.net Mon Jul 10 15:38:40 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 16:38:40 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Demo/embed Makefile,1.3,1.4 In-Reply-To: <200007101435.HAA09733@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Mon, Jul 10, 2000 at 07:35:15AM -0700 References: <200007101435.HAA09733@slayer.i.sourceforge.net> Message-ID: <20000710163840.J26534@xs4all.nl> On Mon, Jul 10, 2000 at 07:35:15AM -0700, Guido van Rossum wrote: > Log Message: > Adapted for Python 2.0 under RH Linux. [..] > # XXX edit LIBS (in particular) to match $(blddir)/Modules/Makefile > ! LIBS= -lnsl -ldl -lreadline -ltermcap -lieee -lpthread -lutil You probably want -lcrypt in there, too, just in case. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm@hypernet.com Mon Jul 10 15:41:37 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Mon, 10 Jul 2000 10:41:37 -0400 Subject: [Python-Dev] non-integer arguments to simple slices in 1.6? In-Reply-To: <200007101329.IAA18009@cj20424-a.reston1.va.home.com> Message-ID: <1248882392-26064718@hypernet.com> [Guido] > I got the following email from Scott Johnston which suggests an > interesting idea (for 2.0, of course, as that's what we're all > working on now). basically, Scott proposes to deprecate > __getslice__ (and its friends, __setslice__ and __delslice__) in > favor of passing the slice arguments unadorned to __getitem__ if > __getslice__ is not defined. > > On the surface, this seems reasonable to me, except that it > doesn't help for extension classes... We have a problem here, but I think it's in the fact that currently certain slices end up in __getitem__ and some in __getslice__. IOW, I think that __getitem__ should return an item, and this fix (while clever) just compounds a mistake. - Gordon From guido@beopen.com Mon Jul 10 16:43:26 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 10:43:26 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Demo/embed Makefile,1.3,1.4 In-Reply-To: Your message of "Mon, 10 Jul 2000 16:38:40 +0200." <20000710163840.J26534@xs4all.nl> References: <200007101435.HAA09733@slayer.i.sourceforge.net> <20000710163840.J26534@xs4all.nl> Message-ID: <200007101543.KAA25995@cj20424-a.reston1.va.home.com> > > ! LIBS= -lnsl -ldl -lreadline -ltermcap -lieee -lpthread -lutil > > You probably want -lcrypt in there, too, just in case. No, I put *shared* at the earliest convenience in Setup (in fact there's one commented out that I enabled). I recommend everyone else to do the same. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal@lemburg.com Mon Jul 10 15:47:06 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 16:47:06 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> Message-ID: <3969E1EA.27E7F508@lemburg.com> Guido van Rossum wrote: > > I decided to build the simple embedding demo in Demo/embed/. After > fixing the Makefile (checkins coming), I ended up with one problem: > the 'import site.py' failed error. When using -v I get this traceback: > > 'import site' failed; traceback: > Traceback (most recent call last): > File "/usr/local/lib/python2.0/site.py", line 146, in ? > sys.setdefaultencoding('ascii') > LookupError: no codec search functions registered: can't find encoding > > Is there some part of the initialization that I'm forgetting? Looks like the 'import encodings' failed. Could you check this with -vv ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@beopen.com Mon Jul 10 16:50:49 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 10:50:49 -0500 Subject: [Python-Dev] non-integer arguments to simple slices in 1.6? In-Reply-To: Your message of "Mon, 10 Jul 2000 10:41:37 -0400." <1248882392-26064718@hypernet.com> References: <1248882392-26064718@hypernet.com> Message-ID: <200007101550.KAA26343@cj20424-a.reston1.va.home.com> > We have a problem here, but I think it's in the fact that > currently certain slices end up in __getitem__ and some in > __getslice__. > > IOW, I think that __getitem__ should return an item, and this > fix (while clever) just compounds a mistake. Agreed in an ideal world, but it's done like this for backwards compatibility. The proper solution would be for __getslice__ to always get the raw values given to the slice, but so that __getslice__ takes an optional third argument which gets the 3rd slice value if present. So x[i:j] results in x.__getslice__(i,j) while x[i:j:k] results in x.__getslice__(i,j,k). Missing values are replaced with None, so that x[:] results in x.__getslice__(None, None) and x[::] in x.__getslice__(None, None, None). This is pretty backwards incompatible! Perhaps to the devil with b/w compat? Note that C extensions also get too much service for slicing. It seems a somewhat tedious project to clean all of this up... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas@xs4all.net Mon Jul 10 15:52:53 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 16:52:53 +0200 Subject: [Python-Dev] parallel for-loops. In-Reply-To: <20000710163233.I26534@xs4all.nl>; from thomas@xs4all.net on Mon, Jul 10, 2000 at 04:32:33PM +0200 References: <20000710163233.I26534@xs4all.nl> Message-ID: <20000710165253.K26534@xs4all.nl> On Mon, Jul 10, 2000 at 04:32:33PM +0200, Thomas Wouters wrote: > I'll do some more testing on this, write some docs and some tests, And already found a bug ;) If anyone is testing this, and can't get 'else' clauses to work, change this: > ! com_node(c, CHILD(n, inum*4 + 3)); into this: > ! com_node(c, CHILD(n, inum*4 + 4)); -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Moshe Zadka Mon Jul 10 15:56:56 2000 From: Moshe Zadka (Moshe Zadka) Date: Mon, 10 Jul 2000 17:56:56 +0300 (IDT) Subject: [Python-Dev] parallel for-loops. In-Reply-To: <20000710163233.I26534@xs4all.nl> Message-ID: On Mon, 10 Jul 2000, Thomas Wouters wrote: > Here's how it works: > > >>> for x in [1,2,3,4,5]; y in ['a','b','c','d','e','f','g']: > ... print x, y > ... > 1 a > 2 b > 3 c > 4 d > 5 e > >>> +1 on the concept anyway > If this is deemed undesirable, it would be trivial to add a new bytcode, > FORMORE_LOOP or such, that handles the multiple-list type of for loop. I > almost went ahead and did that, but decided I'd try for a patch that > *doesn't* add bytecodes for a change ;) Unfortunately, the patch is binary > incompatible, so the bytecode magic does have to be changed. It's all right, any patch would be binary incompatible > I'll do some more testing on this, write some docs and some tests, and if > noone here has convinced me otherwise, upload it to sourceforge ;) The patch > is really suprisingly small and elegant, thanks to Python's extreme > simplicity! Hmmmm... I still think there should be a FOR_MORELOOP, but I think this specific patch should be uploaded to SF so we can play with this a bit. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From guido@beopen.com Mon Jul 10 17:22:40 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 11:22:40 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: Your message of "Mon, 10 Jul 2000 08:00:35 MST." <200007101500.IAA13372@slayer.i.sourceforge.net> References: <200007101500.IAA13372@slayer.i.sourceforge.net> Message-ID: <200007101622.LAA01140@cj20424-a.reston1.va.home.com> > Moves some test code into the scope of if __name__ == '__main__', where it > won't get loaded when we're using the classes in this module. Eric, I believe you are mistaken, or at least expressing yourself unclearly in the checkin comment. While the test function *objects* indeed aren't created in your new version, it doesn't actually save any time when loading the module: all the code in a module is parsed, or all the bytecode is unmarshalled, regardless of whether it is executed. All you save in performance is a LOAD_CONST, a MAKE_FUNCTION, and a STORE_NAME -- all of which don't really do any work. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Mon Jul 10 17:30:57 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 11:30:57 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 16:47:06 +0200." <3969E1EA.27E7F508@lemburg.com> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> Message-ID: <200007101630.LAA01307@cj20424-a.reston1.va.home.com> (There's a linux question at the bottom.) > > I decided to build the simple embedding demo in Demo/embed/. After > > fixing the Makefile (checkins coming), I ended up with one problem: > > the 'import site.py' failed error. When using -v I get this traceback: > > > > 'import site' failed; traceback: > > Traceback (most recent call last): > > File "/usr/local/lib/python2.0/site.py", line 146, in ? > > sys.setdefaultencoding('ascii') > > LookupError: no codec search functions registered: can't find encoding > > > > Is there some part of the initialization that I'm forgetting? > > Looks like the 'import encodings' failed. Could you check this > with -vv ? Thanks for the hint. Seems I've got it nailed down: it's looking for the struct module: [...] import codecs # precompiled from /usr/local/lib/python2.0/codecs.pyc # trying /usr/local/lib/python2.0/struct.so # trying /usr/local/lib/python2.0/structmodule.so # trying /usr/local/lib/python2.0/struct.py # trying /usr/local/lib/python2.0/struct.pyc # trying /usr/local/lib/python2.0/plat-linux2/struct.so # trying /usr/local/lib/python2.0/plat-linux2/structmodule.so # trying /usr/local/lib/python2.0/plat-linux2/struct.py # trying /usr/local/lib/python2.0/plat-linux2/struct.pyc # trying /usr/local/lib/python2.0/lib-tk/struct.so # trying /usr/local/lib/python2.0/lib-tk/structmodule.so # trying /usr/local/lib/python2.0/lib-tk/struct.py # trying /usr/local/lib/python2.0/lib-tk/struct.pyc # trying /usr/local/lib/python2.0/lib-dynload/struct.so # trying /usr/local/lib/python2.0/lib-dynload/structmodule.so 'import site' failed; traceback: Traceback (most recent call last): File "/usr/local/lib/python2.0/site.py", line 146, in ? sys.setdefaultencoding('ascii') LookupError: no codec search functions registered: can't find encoding [...] But the bizarre thing is that the last file it tries (/usr/local/lib/python2.0/lib-dynload/structmodule.so) actually exists!!! OK, so there's code masking the ImportError in import_encodings() in codecs.c. I disabled that (hmm, maybe this should be disabled automatically when -v is used!). Now I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.0/site.py", line 146, in ? sys.setdefaultencoding('ascii') File "/usr/local/lib/python2.0/encodings/__init__.py", line 30, in ? import codecs,aliases File "/usr/local/lib/python2.0/codecs.py", line 10, in ? import struct,types,__builtin__ ImportError: /usr/local/lib/python2.0/lib-dynload/structmodule.so: undefined symbol: PyString_Type OK, I've managed to fix it by a change to the way I build Python: I'm now linking the struct module (and everything in Setup up to and including _codecs) statically. But I guess what's really missing is some kind of flag that tells the linker to export all symbols in the libpython2.0.a file... Is there a way? (I feel so stupid!) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal@lemburg.com Mon Jul 10 16:44:39 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 17:44:39 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> Message-ID: <3969EF67.29B9DC05@lemburg.com> Guido van Rossum wrote: > > (There's a linux question at the bottom.) > > > > I decided to build the simple embedding demo in Demo/embed/. After > > > fixing the Makefile (checkins coming), I ended up with one problem: > > > the 'import site.py' failed error. When using -v I get this traceback: > > > > > > 'import site' failed; traceback: > > > Traceback (most recent call last): > > > File "/usr/local/lib/python2.0/site.py", line 146, in ? > > > sys.setdefaultencoding('ascii') > > > LookupError: no codec search functions registered: can't find encoding > > > > > > Is there some part of the initialization that I'm forgetting? > > > > Looks like the 'import encodings' failed. Could you check this > > with -vv ? > > Thanks for the hint. Seems I've got it nailed down: it's looking for > the struct module: > > [...] > import codecs # precompiled from /usr/local/lib/python2.0/codecs.pyc > # trying /usr/local/lib/python2.0/struct.so > # trying /usr/local/lib/python2.0/structmodule.so > # trying /usr/local/lib/python2.0/struct.py > # trying /usr/local/lib/python2.0/struct.pyc > # trying /usr/local/lib/python2.0/plat-linux2/struct.so > # trying /usr/local/lib/python2.0/plat-linux2/structmodule.so > # trying /usr/local/lib/python2.0/plat-linux2/struct.py > # trying /usr/local/lib/python2.0/plat-linux2/struct.pyc > # trying /usr/local/lib/python2.0/lib-tk/struct.so > # trying /usr/local/lib/python2.0/lib-tk/structmodule.so > # trying /usr/local/lib/python2.0/lib-tk/struct.py > # trying /usr/local/lib/python2.0/lib-tk/struct.pyc > # trying /usr/local/lib/python2.0/lib-dynload/struct.so > # trying /usr/local/lib/python2.0/lib-dynload/structmodule.so > 'import site' failed; traceback: > Traceback (most recent call last): > File "/usr/local/lib/python2.0/site.py", line 146, in ? > sys.setdefaultencoding('ascii') > LookupError: no codec search functions registered: can't find encoding > [...] > > But the bizarre thing is that the last file it tries > (/usr/local/lib/python2.0/lib-dynload/structmodule.so) actually > exists!!! > > OK, so there's code masking the ImportError in import_encodings() in > codecs.c. I disabled that (hmm, maybe this should be disabled > automatically when -v is used!). Hard to do since the setting of the verbosity flag is not available to Python code. > Now I get this traceback: > > Traceback (most recent call last): > File "/usr/local/lib/python2.0/site.py", line 146, in ? > sys.setdefaultencoding('ascii') > File "/usr/local/lib/python2.0/encodings/__init__.py", line 30, in ? > import codecs,aliases > File "/usr/local/lib/python2.0/codecs.py", line 10, in ? > import struct,types,__builtin__ > ImportError: /usr/local/lib/python2.0/lib-dynload/structmodule.so: undefined symbol: PyString_Type > > OK, I've managed to fix it by a change to the way I build Python: I'm > now linking the struct module (and everything in Setup up to and > including _codecs) statically. > > But I guess what's really missing is some kind of flag that tells the > linker to export all symbols in the libpython2.0.a file... Is there a > way? (I feel so stupid!) From man ld: -E -export-dynamic When creating an ELF file, add all symbols to the dynamic symbol table. Normally, the dynamic symbol table contains only symbols which are used by a dy­ namic object. This option is needed for some uses of dlopen. (Not sure whether this is what you're looking for, though.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pf@artcom-gmbh.de Mon Jul 10 16:44:13 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Mon, 10 Jul 2000 17:44:13 +0200 (MEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_userstring,1.1,1.2 In-Reply-To: <200007101414.HAA08212@slayer.i.sourceforge.net> from Jeremy Hylton at "Jul 10, 2000 7:14:43 am" Message-ID: Hi, Jeremy Hylton: > Modified Files: > test_userstring > Log Message: > expect message "no regression test case for method 'encode' [...] > test_userstring > + no regression test case for method 'encode' > + no regression test case for method 'isalnum' > + no regression test case for method 'isalpha' Hmmmm..... Wouldn't it be better to actually write some simple test cases for these methods and add them to 'Lib/test/test_string.py' (if not already done)? My initial idea to put this check into 'test_userstring.py' was to discover missing test cases for new methods that should be copied from test_string.py in order to keep UserString in sync with new functionality added to the builtin string types. Regards, Peter From thomas@xs4all.net Mon Jul 10 16:56:42 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 17:56:42 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <3969EF67.29B9DC05@lemburg.com>; from mal@lemburg.com on Mon, Jul 10, 2000 at 05:44:39PM +0200 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> Message-ID: <20000710175642.L26534@xs4all.nl> On Mon, Jul 10, 2000 at 05:44:39PM +0200, M.-A. Lemburg wrote: > Guido van Rossum wrote: > > import struct,types,__builtin__ > > ImportError: /usr/local/lib/python2.0/lib-dynload/structmodule.so: undefined symbol: PyString_Type [...] > > But I guess what's really missing is some kind of flag that tells the > > linker to export all symbols in the libpython2.0.a file... Is there a > > way? (I feel so stupid!) > >From man ld: > -export-dynamic > When creating an ELF file, add all symbols to the > dynamic symbol table. Normally, the dynamic symbol > table contains only symbols which are used by a dy­ > namic object. This option is needed for some uses > of dlopen. > (Not sure whether this is what you're looking for, though.) I think it is. The funny bit is that it should be included in LDFLAGS by default, on Linux. BSDI and some other operating systems need it too (at least newer versions) and gave the same error with shared libraries if the flag was omitted (old BSDI was COFF with fake-shared-libraries, new BSDI is ELF) I didn't bother to check, but does the embed Makefile include python's Makefile* stuff from $prefix/config ? Does it contain -export-dynamic ? If so, very pecurliar... ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy@beopen.com Mon Jul 10 17:14:09 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 12:14:09 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_userstring,1.1,1.2 In-Reply-To: References: <200007101414.HAA08212@slayer.i.sourceforge.net> Message-ID: <14697.63057.193077.537823@bitdiddle.concentric.net> >>>>> "PF" == Peter Funk writes: PF> Hmmmm..... Wouldn't it be better to actually write some simple PF> test cases for these methods and add them to PF> 'Lib/test/test_string.py' (if not already done)? PF> My initial idea to put this check into 'test_userstring.py' was PF> to discover missing test cases for new methods that should be PF> copied from test_string.py in order to keep UserString in sync PF> with new functionality added to the builtin string types. That sounds like a good testing strategy, but I'm not sure I agree with a test that fails because it has failed to track a new feature. The current test suite does a mediocre job of testing all features or achieving code coverage. It's annoying that this test is reported as a failure when the module is, in fact, working properly. In the long term, a revision of the testing setup so that different classes of errors can be reported might be useful. The failure to test an encode method could be reported as a warning (non-fatal) instead of an error (fatal). I also don't like the implementation strategy, which causes code to be duplicated in test_string.py and test_userstring.py. I'll add a third module that can be loaded by either test module to perform the specific tests. Finally, test_string doesn't test encode either. Someone want to add a test for that? Jeremy From thomas@xs4all.net Mon Jul 10 17:15:54 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 18:15:54 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules posixmodule.c,2.148,2.149 In-Reply-To: <200007101559.IAA22393@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Mon, Jul 10, 2000 at 08:59:33AM -0700 References: <200007101559.IAA22393@slayer.i.sourceforge.net> Message-ID: <20000710181554.M26534@xs4all.nl> On Mon, Jul 10, 2000 at 08:59:33AM -0700, Fredrik Lundh wrote: > Modified Files: > posixmodule.c > Log Message: > -- get rid of a compiler warning on unix. (as reported > for #100836, but implemented in a different way) > - static PyObject * > - posix_strintint(PyObject *args, char *format, > - int (*func)(const char *, int, int)) [..] Why not get rid of posix_strint() in the same manner ? posix_strint() isn't used at all, currently. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@beopen.com Mon Jul 10 18:22:36 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 12:22:36 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 17:44:39 +0200." <3969EF67.29B9DC05@lemburg.com> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> Message-ID: <200007101722.MAA01227@cj20424-a.reston1.va.home.com> > > OK, so there's code masking the ImportError in import_encodings() in > > codecs.c. I disabled that (hmm, maybe this should be disabled > > automatically when -v is used!). > > Hard to do since the setting of the verbosity flag is not > available to Python code. Actually, it is: see pydebug.h, included by Python.h: extern DL_IMPORT(int) Py_VerboseFlag; > >From man ld: > > -E > > -export-dynamic > When creating an ELF file, add all symbols to the > dynamic symbol table. Normally, the dynamic symbol > table contains only symbols which are used by a dy­ > namic object. This option is needed for some uses > of dlopen. > > (Not sure whether this is what you're looking for, though.) Thanks -- yes, that did it! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Mon Jul 10 18:25:12 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 12:25:12 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 17:56:42 +0200." <20000710175642.L26534@xs4all.nl> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> Message-ID: <200007101725.MAA01255@cj20424-a.reston1.va.home.com> > I didn't bother to check, but does the embed Makefile include python's > Makefile* stuff from $prefix/config ? Does it contain -export-dynamic ? If > so, very pecurliar... ;-P Makefile includes are notoriously unportable, aren't they? The embed/Makefile is a lame excuse for a Makefile -- it has XXX comments all over the place telling you to edit things to match the Python main Makefile... :-( My fault -- feel free to fix! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr@thyrsus.com Mon Jul 10 17:35:50 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 12:35:50 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101622.LAA01140@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 11:22:40AM -0500 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> Message-ID: <20000710123550.A8478@thyrsus.com> Guido van Rossum : > I believe you are mistaken, or at least expressing yourself unclearly > in the checkin comment. While the test function *objects* indeed > aren't created in your new version, it doesn't actually save any time > when loading the module: all the code in a module is parsed, or all > the bytecode is unmarshalled, regardless of whether it is executed. > All you save in performance is a LOAD_CONST, a MAKE_FUNCTION, and a > STORE_NAME -- all of which don't really do any work. OK, correction accepted. But this is still a good idea for documentation purposes, no? -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. From Fredrik Lundh" from Modules/Setup.in: # The modules listed here can't be built as shared libraries for # various reasons; therefore they are listed here instead of in the # normal order. # Some modules that are normally always on: regex regexmodule.c regexpr.c # Regular expressions, GNU Emacs style pcre pcremodule.c pypcre.c # Regular expressions, Perl style (for = re.py) posix posixmodule.c # posix (UNIX) system calls signal signalmodule.c # signal(2) _sre _sre.c # Fredrik Lundh's new regular expressions possibly a stupid question, but what exactly is SRE doing in there? From jim@interet.com Mon Jul 10 17:43:03 2000 From: jim@interet.com (James C. Ahlstrom) Date: Mon, 10 Jul 2000 12:43:03 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> Message-ID: <3969FD17.487DA96A@interet.com> I just got back from vacation, so I am catching up. The following concerns Windows only, not *.so files on Unix. Background: Existing foo.pyd Windows extensions will crash the new Python because foo.pyd will load python15.dll, and python.exe will load python20.dll. MarkH explained why: [Mark] > The 1.5 module is linked against Python15.dll. When Python.exe (linked > against Python16.dll) starts up, it initializes the Python data structures > in Python16.dll. When Python then imports foo.pyd (linked against > Python15.dll), it immediately tries to call the functions in that DLL (such > as getting the thread state). As Python has not been initialized in that > DLL, we immediately die. This is really bad. Normally under Windows, DLL names do not change unless the API exported is changed in a major way. For example, there have been several versions of mfc42.dll without changing the name. [Mark continues] > Ironically, if Python1x.dll was simply named "Python.dll", there is a > _reasonable_ chance it would work fine. The cost of doing this tho, is > that you can not have Python 1.5 and Python 1.6 "side by side" on the same > machine. What this means is that if the new Python 2.0 (1.6?) simply names its DLL python15.dll just as before, everything Just Works almost. That is, it Just Works provided that foo.pyd only calls Python C functions whose interface has not changed. You can support Python 1.5 and 1.6 by removing the python*.dll from the Windows directories, and putting it in the directory of python.exe so it goes with the proper executable. Guido van Rossum wrote: > There are endless variations on this theme. What's missing at the > moment is a bit of requirements analysis. What's the problem we're > trying to solve here? So far, the only problem that came up was that > on Windows, you get an obscure crash when trying to load an extension > built for Python 1.5(.x). Yes, and this is a major problem, and is un-Windows-like. > Do we really need a whole new version > negotiating architecture? No, just keep the old name "python15.dll". Old foo.pyd will still work if they use only Python C functions with the same interface. Individual *.pyd authors will have to advise users whether they need to upgrade to new *.pyd versions or not. > You can already get the version string by > looking at Py_GetVersion() -- this also answers the question of how a > version is represented. True. And on Windows, there is a standard Version resource string which gives the DLL version, and can be read without loading the DLL. This string is referenced by the Wise (and other) installers to decide whether a DLL is newer and should be replaced. > On Windows, link-time compatibility is broken whenever we change the > second digit of the version number, e.g. 15, 16, 20. Yikes, lets not let that happen! JimA From Fredrik Lundh" <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> Message-ID: <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> mal wrote: > * change hash value calculation to work on the Py_UNICODE data > instead of creating a default encoded cached object (what > now is .utf8str) it this what you had in mind? static long unicode_hash(PyUnicodeObject *self) { register int len; register Py_UNICODE *p; register long x; if (self->hash !=3D -1) return self->hash; len =3D PyUnicode_GET_SIZE(self); p =3D PyUnicode_AS_UNICODE(self); x =3D *p << 7; while (--len >=3D 0) x =3D (1000003*x) ^ *p++; x ^=3D a->ob_size; if (x =3D=3D -1) x =3D -2; self->hash =3D x; return x; } From jeremy@beopen.com Mon Jul 10 18:24:27 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 13:24:27 -0400 (EDT) Subject: [Python-Dev] string.join and bad sequences In-Reply-To: <200007101708.KAA08018@slayer.i.sourceforge.net> References: <200007101708.KAA08018@slayer.i.sourceforge.net> Message-ID: <14698.1739.660431.756932@bitdiddle.concentric.net> I added a test case to Lib/test/string_tests.py that uses a sequence that returns the wrong answer from __len__. I've used this test in a number of places to make sure the interpreter doesn't dump core when it hits a bad user-defined sequence. class Sequence: def __init__(self): self.seq = 'wxyz' def __len__(self): return len(self.seq) def __getitem__(self, i): return self.seq[i] class BadSeq2(Sequence): def __init__(self): self.seq = ['a', 'b', 'c'] def __len__(self): return 8 The test of string.join and " ".join don't dump core, but they do raise an IndexError. I wonder if that's the right thing to do, because the other places where it is handled no exception is raised. The question boils down to the semantics of the sequence protocol. The string code defintion is: if __len__ returns X, then the length is X thus, __getitem__ should succeed for range(0, X) if it doesn't, raise an IndexError The other code (e.g. PySequence_Tuple) definition is: if __len__ return X, then the length is <= X if __getitem__ succeeds for range(0, X), then length is indeed X if it does not, then length is Y + 1 for highest Y where Y is greatest index that actually works The definition in PySequence_Tuple seemed quite clever when I first saw it, but I like it less now. If a user-defined sequence raises IndexError when len indicates it should not, the code is broken. The attempt to continue anyway is masking an error in user code. I vote for fixing PySequence_Tuple and the like to raise an IndexError. Jeremy From tim_one@email.msn.com Mon Jul 10 18:26:36 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 13:26:36 -0400 Subject: [Python-Dev] file closed! (was Re: CVS read/write access) In-Reply-To: <3969B399.FC5E1AC2@stud.ntnu.no> Message-ID: [Peter Schneider-Kamp] > ... > It was the group. But 20 minutes after I found out I checked again > and suddenly python had appeared. Must have been this cron delay. Yes, this sure fits the symptoms described at: http://sourceforge.net/docs/site/delay.php ... Updates to these other systems happen via cron 4 times per day, so changes made on the web site will appear to be live, but will not take effect until the next cron update. ... This includes all functions relating to mail aliases, shell passwords, user additions, group member changes, cvs repository creation, etc a-fine-art-to-knowing-when-sitting-on-your-ass-is-the-solution-ly y'rs - tim From mal@lemburg.com Mon Jul 10 18:30:20 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 19:30:20 +0200 Subject: [Python-Dev] new unicode hash calculation References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> Message-ID: <396A082C.77B4D71D@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > * change hash value calculation to work on the Py_UNICODE data > > instead of creating a default encoded cached object (what > > now is .utf8str) > > it this what you had in mind? > > static long > unicode_hash(PyUnicodeObject *self) > { > register int len; > register Py_UNICODE *p; > register long x; > > if (self->hash != -1) > return self->hash; > len = PyUnicode_GET_SIZE(self); > p = PyUnicode_AS_UNICODE(self); > x = *p << 7; > while (--len >= 0) > x = (1000003*x) ^ *p++; > x ^= a->ob_size; > if (x == -1) > x = -2; > self->hash = x; > return x; > } > > Well, sort of. It should be done in such a way that Unicode strings which only use the lower byte produce the same hash value as normal 8-bit strings -- is this the case for the above code ? My first idea was to apply a kind of two pass scan which first only uses the lower byte and then the higher byte to calculate a hash value. Both passes would use the same algorithm as the one for 8-bit strings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Mon Jul 10 18:32:31 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 19:32:31 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <200007101722.MAA01227@cj20424-a.reston1.va.home.com> Message-ID: <396A08AF.655B4836@lemburg.com> Guido van Rossum wrote: > > > > OK, so there's code masking the ImportError in import_encodings() in > > > codecs.c. I disabled that (hmm, maybe this should be disabled > > > automatically when -v is used!). > > > > Hard to do since the setting of the verbosity flag is not > > available to Python code. > > Actually, it is: see pydebug.h, included by Python.h: > > extern DL_IMPORT(int) Py_VerboseFlag; Yes... I meant: it is not available from Python. (mx.Tools publishes an interface to this flag: sys.verbosity() which also allows setting the value at runtime.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@beopen.com Mon Jul 10 19:38:46 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 13:38:46 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: Your message of "Mon, 10 Jul 2000 12:35:50 -0400." <20000710123550.A8478@thyrsus.com> References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> Message-ID: <200007101838.NAA01448@cj20424-a.reston1.va.home.com> > From: "Eric S. Raymond" > Guido van Rossum : > > I believe you are mistaken, or at least expressing yourself unclearly > > in the checkin comment. While the test function *objects* indeed > > aren't created in your new version, it doesn't actually save any time > > when loading the module: all the code in a module is parsed, or all > > the bytecode is unmarshalled, regardless of whether it is executed. > > All you save in performance is a LOAD_CONST, a MAKE_FUNCTION, and a > > STORE_NAME -- all of which don't really do any work. > > OK, correction accepted. But this is still a good idea for documentation > purposes, no? Actually, it makes manual testing of the module a little harder: from inside Python, I used to be able to say >>> import urllib >> urllib.test() With your change that doesn't work any more, so I'd rather see you revert it back... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Mon Jul 10 19:43:29 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 13:43:29 -0500 Subject: [Python-Dev] why isn't SRE a shared module? In-Reply-To: Your message of "Mon, 10 Jul 2000 18:45:27 +0200." <007901bfea8e$8ee9b600$f2a6b5d4@hagrid> References: <007901bfea8e$8ee9b600$f2a6b5d4@hagrid> Message-ID: <200007101843.NAA01635@cj20424-a.reston1.va.home.com> > from Modules/Setup.in: > > # The modules listed here can't be built as shared libraries for > # various reasons; therefore they are listed here instead of in the > # normal order. > > # Some modules that are normally always on: > > regex regexmodule.c regexpr.c # Regular expressions, GNU Emacs style > pcre pcremodule.c pypcre.c # Regular expressions, Perl style (for re.py) > posix posixmodule.c # posix (UNIX) system calls > signal signalmodule.c # signal(2) > _sre _sre.c # Fredrik Lundh's new regular expressions > > possibly a stupid question, but what exactly is SRE doing > in there? I think the comments are confusing. The first comment has it right -- I think posix and signal *must* be static. I'm not so sure about the rest... It's just recommended to link them statically because you'll end up loading them into 99% of all Python processes anyway. Of course, that's no longer true fo regex or pcre so they should be moved down anyway. It's up to you if you want to suggest special status for _sre.c... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Mon Jul 10 19:51:05 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 13:51:05 -0500 Subject: [Python-Dev] new unicode hash calculation In-Reply-To: Your message of "Mon, 10 Jul 2000 19:07:15 +0200." <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> Message-ID: <200007101851.NAA01792@cj20424-a.reston1.va.home.com> > mal wrote: > > > * change hash value calculation to work on the Py_UNICODE data > > instead of creating a default encoded cached object (what > > now is .utf8str) [effbot] > it this what you had in mind? > > static long > unicode_hash(PyUnicodeObject *self) > { > register int len; > register Py_UNICODE *p; > register long x; > > if (self->hash != -1) > return self->hash; > len = PyUnicode_GET_SIZE(self); > p = PyUnicode_AS_UNICODE(self); > x = *p << 7; > while (--len >= 0) > x = (1000003*x) ^ *p++; > x ^= a->ob_size; > if (x == -1) > x = -2; > self->hash = x; > return x; > } You mean this (fixed a->ob_size, restored comment): static long unicode_hash(PyUnicodeObject *self) { /* Since Unicode objects compare equal to their ASCII string counterparts, they should also use the ASCII strings as basis for their hash value. This is needed to assure that strings and Unicode objects behave in the same way as dictionary keys. */ register int len; register Py_UNICODE *p; register long x; if (self->hash != -1) return self->hash; len = PyUnicode_GET_SIZE(self); p = PyUnicode_AS_UNICODE(self); x = *p << 7; while (--len >= 0) x = (1000003*x) ^ *p++; x ^= PyUnicode_GET_SIZE(self); if (x == -1) x = -2; self->hash = x; return x; } --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Mon Jul 10 19:58:07 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 13:58:07 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Mon, 10 Jul 2000 12:43:03 -0400." <3969FD17.487DA96A@interet.com> References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> <3969FD17.487DA96A@interet.com> Message-ID: <200007101858.NAA01814@cj20424-a.reston1.va.home.com> [James Ahlstrom makes a plea for keeping the DLL name unchanged (python15.dll) so that existing extensions don't have to be rebuilt if they don't make calls to API functions that changed.] The problem with this is that it's hard to say whether this is the case. We haven't made an effort to keep the APIs compatible, because we were planning to change the DLL name to be incompatible. I guess we'd need a Microsoft style testing department that collects a large set of existing 1.5 style extensions, builds a Python 2.0 DLL named python15.dll, and tests whether all those 1.5 style extensions work correctly. Seems a lot of work to me. Plus, we'd have to check whether we didn't change any of the object lay-outs that are accessible via macros... Frankly, I'd rather declare incompatibility than do all the work. What's it good for? We're not forcing people to upgrade if their favorite DLLs haven't been upgraded yet... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Mon Jul 10 20:02:37 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 14:02:37 -0500 Subject: [Python-Dev] new unicode hash calculation In-Reply-To: Your message of "Mon, 10 Jul 2000 19:30:20 +0200." <396A082C.77B4D71D@lemburg.com> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> <396A082C.77B4D71D@lemburg.com> Message-ID: <200007101902.OAA01883@cj20424-a.reston1.va.home.com> > Well, sort of. It should be done in such a way that Unicode > strings which only use the lower byte produce the same hash > value as normal 8-bit strings -- is this the case for the > above code ? I already checked it -- it does, for ASCII or Latin-1 as the default encoding. Good enough for me. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr@thyrsus.com Mon Jul 10 19:25:19 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 14:25:19 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101838.NAA01448@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 01:38:46PM -0500 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> Message-ID: <20000710142519.A8794@thyrsus.com> Guido van Rossum : > With your change that doesn't work any more, so I'd rather see you > revert it back... How do I do that in CVS-land? BTW, this patch was mostly just a test to verify that my CVS access mechanics work. So I'm not miffed at being asked to back it out. Also BTW, my access mechanics are a Python script called `forgetool' that automates away a bunch of CVS housekeeping -- setting CVSROOT properly on a per-project basis is one of the things it does. I'll write some docs and release it shortly. -- Eric S. Raymond The conclusion is thus inescapable that the history, concept, and wording of the second amendment to the Constitution of the United States, as well as its interpretation by every major commentator and court in the first half-century after its ratification, indicates that what is protected is an individual right of a private citizen to own and carry firearms in a peaceful manner. -- Report of the Subcommittee On The Constitution of the Committee On The Judiciary, United States Senate, 97th Congress, second session (February, 1982), SuDoc# Y4.J 89/2: Ar 5/5 From Fredrik Lundh" <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> <396A082C.77B4D71D@lemburg.com> <200007101902.OAA01883@cj20424-a.reston1.va.home.com> Message-ID: <012f01bfea9d$0a1cfc20$f2a6b5d4@hagrid> mal wrote: > It should be done in such a way that Unicode strings which > only use the lower byte produce the same hash value as > normal 8-bit strings -- is this the case for the above code ? yup. it's the same algorithm as for 8-bit strings, but using larger characters. as long as the high bits are zero, it (obviously) gives the same result. guido: > Good enough for me. I'll interpret that as a "okay, check it in". From guido@beopen.com Mon Jul 10 20:26:25 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 14:26:25 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: Your message of "Mon, 10 Jul 2000 14:25:19 -0400." <20000710142519.A8794@thyrsus.com> References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> Message-ID: <200007101926.OAA02072@cj20424-a.reston1.va.home.com> > How do I do that in CVS-land? cvs admin -o Or you could retrieve the previous version and check it in on top, with a comment such as "eating my words". :-) > BTW, this patch was mostly just a test to verify that my CVS access > mechanics work. So I'm not miffed at being asked to back it out. Thanks. > Also BTW, my access mechanics are a Python script called `forgetool' > that automates away a bunch of CVS housekeeping -- setting CVSROOT > properly on a per-project basis is one of the things it does. I'll > write some docs and release it shortly. I thought that you almost never have to set the CVSROOT variable once you've established your project work tree -- it's all stored in CVS/Root anyway. I believe CVSROOT is only used when you do a "cvs checkout" and that doesn't happen very often... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Mon Jul 10 20:36:05 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 14:36:05 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 19:32:31 +0200." <396A08AF.655B4836@lemburg.com> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <200007101722.MAA01227@cj20424-a.reston1.va.home.com> <396A08AF.655B4836@lemburg.com> Message-ID: <200007101936.OAA02180@cj20424-a.reston1.va.home.com> > Yes... I meant: it is not available from Python. (mx.Tools > publishes an interface to this flag: sys.verbosity() which > also allows setting the value at runtime.) It would make a lot of sense for the sys module to allow access to the values of all the Python command line options, and perhaps to allow changing them. Anybody interested in designing an API here? Some requirements would be platform independence, extensibility, and necessarily the ability to work even in an environment without command line flags (since it still has the corresponding internal flags). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr@thyrsus.com Mon Jul 10 19:50:32 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 14:50:32 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101926.OAA02072@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 02:26:25PM -0500 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> <200007101926.OAA02072@cj20424-a.reston1.va.home.com> Message-ID: <20000710145031.A8888@thyrsus.com> Guido van Rossum : > I thought that you almost never have to set the CVSROOT variable once > you've established your project work tree -- it's all stored in > CVS/Root anyway. I believe CVSROOT is only used when you do a "cvs > checkout" and that doesn't happen very often... It's also needed when you login for anonymous access. Forgetool is intended for people like me who need to manage access to multiple SourceForge projects, some as a developer and some anonymously. It manages some local state about which projects you have developer access to and uses that to set CVSROOT and CVS_RSH correctly. Forgetool also supplies boilerplate for commands to copy files to the project HTTP directory. Things it will do soon: 1) Manage shared session keys so you don't have to type a password on each command. 2) Remote scripting of module releases. The basic idea is to make forgetool a Swiss-army knife for SourceForge developers who need to remote-script various common operations. This capability is not a big deal when you are active in one or two projects -- but I run thirty-five (yes, that's 35) projects that are waiting to move to SourceForge the day I can script the release process. -- Eric S. Raymond Every election is a sort of advance auction sale of stolen goods. -- H.L. Mencken From gstein@lyra.org Mon Jul 10 19:50:14 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 11:50:14 -0700 Subject: [Python-Dev] Re: CVS: python/dist/src/Lib locale.py,1.7,1.8 In-Reply-To: <14697.53306.858387.422925@bitdiddle.concentric.net>; from jeremy@beopen.com on Mon, Jul 10, 2000 at 09:31:38AM -0400 References: <200007091713.KAA02613@slayer.i.sourceforge.net> <20000710020930.T29590@lyra.org> <14697.53306.858387.422925@bitdiddle.concentric.net> Message-ID: <20000710115014.G29590@lyra.org> On Mon, Jul 10, 2000 at 09:31:38AM -0400, Jeremy Hylton wrote: > >>>>> "GS" == Greg Stein writes: > > GS> Can I request (from everyone) to do white space changes *only*, > GS> or to do functional changes *only*. It will make it a lot easier > GS> on the people who are reviewing the checkins. > > Only if you checkin in your own whitespaces changes! <0.7 wink> hehe... I will! I will! :-) [ just been busy folding mod_dav into Apache 2.0. that is pretty much done now... ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul@prescod.net Mon Jul 10 19:54:05 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 10 Jul 2000 13:54:05 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> <20000710022047.V29590@lyra.org> Message-ID: <396A1BCD.E08FB64D@prescod.net> Greg Stein wrote: > > > Because Python supports a configuration time option to link modules > > statically. Of course. I wasn't thinking. But here's another naive question, on what platforms is it significantly better to statically link and how is it significantly better? > Not to mention that the .so is loaded into the process' address space. I > don't think that you can have two symbols in the space with the same name. I've never been clear on that issue. It seems like an unreasonably strict constraint. Adding a function called "doit" to one library could break another dynamically library that happens to have the same name defined? I'd call that a bug in the dynamic loading infrastructure (and certainly not a problem on Windows!)! -- Paul Prescod - Not encumbered by corporate consensus "Computer Associates is expected to come in with better than expected earnings." Bob O'Brien, quoted in - http://www.fool.com/news/2000/foth000316.htm From paul@prescod.net Mon Jul 10 20:00:19 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 10 Jul 2000 14:00:19 -0500 Subject: [Python-Dev] file closed! (was Re: CVS read/write access) References: <39699715.E3368F53@stud.ntnu.no> <20000710014329.Q29590@lyra.org> <3969B399.FC5E1AC2@stud.ntnu.no> Message-ID: <396A1D43.A0F8FF50@prescod.net> Peter Schneider-Kamp wrote: > > Greg Stein wrote: > > > > If so, then it is a problem that the SF Admins must solve. It means that you > > haven't been placed into the appropriate group or somesuch on SF. Log a > ----- > > It was the group. But 20 minutes after I found out I checked again > and suddenly python had appeared. Must have been this cron delay. I had the same symptoms and the same solution (wait a few hours) when I joined pyxml. We should remember it in the future. -- Paul Prescod - Not encumbered by corporate consensus "Computer Associates is expected to come in with better than expected earnings." Bob O'Brien, quoted in - http://www.fool.com/news/2000/foth000316.htm From guido@beopen.com Mon Jul 10 21:14:50 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 15:14:50 -0500 Subject: [Python-Dev] string.join and bad sequences In-Reply-To: Your message of "Mon, 10 Jul 2000 13:24:27 -0400." <14698.1739.660431.756932@bitdiddle.concentric.net> References: <200007101708.KAA08018@slayer.i.sourceforge.net> <14698.1739.660431.756932@bitdiddle.concentric.net> Message-ID: <200007102014.PAA02382@cj20424-a.reston1.va.home.com> > I added a test case to Lib/test/string_tests.py that uses a sequence > that returns the wrong answer from __len__. I've used this test in a > number of places to make sure the interpreter doesn't dump core when > it hits a bad user-defined sequence. > > class Sequence: > def __init__(self): self.seq = 'wxyz' > def __len__(self): return len(self.seq) > def __getitem__(self, i): return self.seq[i] > > class BadSeq2(Sequence): > def __init__(self): self.seq = ['a', 'b', 'c'] > def __len__(self): return 8 > > The test of string.join and " ".join don't dump core, but they do > raise an IndexError. I wonder if that's the right thing to do, > because the other places where it is handled no exception is raised. > > The question boils down to the semantics of the sequence protocol. > > The string code defintion is: > if __len__ returns X, then the length is X > thus, __getitem__ should succeed for range(0, X) > if it doesn't, raise an IndexError > > The other code (e.g. PySequence_Tuple) definition is: > if __len__ return X, then the length is <= X > if __getitem__ succeeds for range(0, X), then length is indeed X > if it does not, then length is Y + 1 for highest Y > where Y is greatest index that actually works > > The definition in PySequence_Tuple seemed quite clever when I first > saw it, but I like it less now. If a user-defined sequence raises > IndexError when len indicates it should not, the code is broken. The > attempt to continue anyway is masking an error in user code. > > I vote for fixing PySequence_Tuple and the like to raise an > IndexError. I'm not sure I agree. When Steve Majewski proposed variable-length sequences, we ended up conceding that __len__ is just a hint. The actual length can be longer or shorter. The map and filter functions allow this, and so do min/max and others that go over sequences, and even (of course) the for loop. (In fact, the preferred behavior is not to call __len__ at all but just try x[0], x[1], x[2], ... until IndexError is hit.) If I read your description of PySequence_Tuple(), it accepts a __len__ that overestimates but not one that understestimates. That's wrong. (In Majewski's example, a tar file wrapper would claim to have 0 items but iterating over it in ascending order would access all the items in the file. Claiming some arbitrary integer as __len__ would be wrong.) So string.join(BadSeq2(), "") or "".join(BadSeq2()) should return "abc". --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas@xs4all.net Mon Jul 10 20:55:55 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 21:55:55 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <396A1BCD.E08FB64D@prescod.net>; from paul@prescod.net on Mon, Jul 10, 2000 at 01:54:05PM -0500 References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> <20000710022047.V29590@lyra.org> <396A1BCD.E08FB64D@prescod.net> Message-ID: <20000710215555.Q26534@xs4all.nl> On Mon, Jul 10, 2000 at 01:54:05PM -0500, Paul Prescod wrote: [Quoting Guido, IIRC] > > > Because Python supports a configuration time option to link modules > > > statically. > Of course. I wasn't thinking. But here's another naive question, on what > platforms is it significantly better to statically link and how is it > significantly better? Well, platforms that do not support dynamic linking/loading, for one ! :-) Not that frequent nowadays, but still something to take into account. Also, some platforms, like BSDI until not that long ago, use a binary format like COFF, which doesn't support shared libraries all that well. It's more of a hack (and a slightly insecure one, at that) than a structural solution. Which is why BSDI moved to ELF, thankfully :-) Also, shared libraries are an aditional performance hit, because of the extra layer of indirection (sometimes more than one) and on some architectures different memory layout. So people might choose to link (some) modules static for that reason. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From barry@scottb.demon.co.uk Mon Jul 10 21:09:20 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Mon, 10 Jul 2000 21:09:20 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007100149.UAA16917@cj20424-a.reston1.va.home.com> Message-ID: <000701bfeaaa$bb8dde40$060210ac@private> > There are endless variations on this theme. What's missing at the > moment is a bit of requirements analysis. What's the problem we're > trying to solve here? So far, the only problem that came up was that > on Windows, you get an obscure crash when trying to load an extension > built for Python 1.5(.x). Do we really need a whole new version > negotiating architecture? You can already get the version string by > looking at Py_GetVersion() -- this also answers the question of how a > version is represented. I post the first mail as I think it reflects poorly on Python if it crashes for this preventable reason. How important this problem is depends on how many users it will affect. Is it only a few .pyd that fail or all of them? Will a few users see this or lots of them? I'd hope one requirement is not to look bad in the eyes of the python users. When the old extension calls Py_GetVersion() it will be the python15.dll:Py_GetVersion(). Not the new one. Integer version values would be nicer to handle then hacking a string up. Barry From esr@thyrsus.com Mon Jul 10 21:28:55 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 16:28:55 -0400 Subject: [Python-Dev] Changes to ConfigParser Message-ID: <20000710162855.A9245@thyrsus.com> Earlier today, I committed a patch to ConfigParser that adds three new methods to the class. Here is the documentation: \begin{methoddesc}{has_option}{section, option} If the given section exists, and contains the given option. return 1; otherwise return 0. (New in 1.6) \end{methoddesc} \begin{methoddesc}{set}{section, option, value} If the given section exists, set the given option to the specified value; otherwise raise \exception{NoSectionError}. (New in 1.6) \end{methoddesc} \begin{methoddesc}{write}{fileobect} Write a representation of the configuration to the specified file object. This representation can be parsed by a future \method{read()} call. (New in 1.6) \end{methoddesc} These new methods are additions to the class, and do not change any existing code. Nevertheless Guido sent me a heads-up that I had committed a marginal violation of Python etiquette by changing the module without the explicit sign-off of the maintainers. For this I apologize, specifically to Andrew Kuchling and Barry Warsaw. Please note that I specifically refrained from fixing a bug in the existing code that was exposed by the new methods, in order to avoid the risk of breaking compatibility. Now I want to explain what I'm doing, specifically the next steps in my plan, and make sure there is a consensus to support it. I am working on a program called `forgetool' that is intended as a front end to SourceForge. It will keep your CVSROOT set properly as you hop between multiple projects, make it easy to do uploads to project HTTP directories without remembering a lot of boilerplate, enable remote scripting of releases, and in general serve as a SourceForge developer's Swiss-army knife. To do these things, forgetool needs to maintain some local state that is conveniently represented in the format of a Windows .ini file. More, it needs to be able to *update* .ini files as well as parse them. Accordingly, forgetool subclasses ConfigParser into EnhancedConfigParser adding the above methods. After testing them, I copied this code into ConfigParser for others to use. Two more things remain to be done: First, for completeness there ought to be remove_section and remove_option methods (though forgetool does not yet use them). I have documented these as follows: \begin{methoddesc}{remove_option}{section, option} Remove the specified \var{option} from the specified \var{section}. If the section does not exist, raise \exception{NoSectionError}. If the option existed to be removed, return 1; otherwise return 0. (New in 1.6) \end{methoddesc} \begin{methoddesc}{remove_section}{section} Remove the specified \var{section} from the configuration. If the section in fact existed, return 1. Otherwise return 0. \end{methoddesc} Second, the new methods expose a bug in the existing code. Because the case of section and option names is folded on input, the new write() method emits edited configurations with their case smashed. I think the existing code should be fixed to preserve case, with string.lower() being applied at key lookup time. Does anybody have a problem with these changes? Barry? Andrew? Again, I apologize for offending the local norms. I'm still learning... -- Eric S. Raymond If gun laws in fact worked, the sponsors of this type of legislation should have no difficulty drawing upon long lists of examples of criminal acts reduced by such legislation. That they cannot do so after a century and a half of trying -- that they must sweep under the rug the southern attempts at gun control in the 1870-1910 period, the northeastern attempts in the 1920-1939 period, the attempts at both Federal and State levels in 1965-1976 -- establishes the repeated, complete and inevitable failure of gun laws to control serious crime. -- Senator Orrin Hatch, in a 1982 Senate Report From akuchlin@mems-exchange.org Mon Jul 10 21:29:55 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon, 10 Jul 2000 16:29:55 -0400 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162855.A9245@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 10, 2000 at 04:28:55PM -0400 References: <20000710162855.A9245@thyrsus.com> Message-ID: <20000710162955.C7313@kronos.cnri.reston.va.us> On Mon, Jul 10, 2000 at 04:28:55PM -0400, Eric S. Raymond wrote: >Does anybody have a problem with these changes? Barry? Andrew? *blink* I've never even touched the ConfigParser module, so I don't know why Guido thought I had any interest in it. The first check-in comment for the module is "This was originally written by Ken and later revamped by Barry." --amk From esr@thyrsus.com Mon Jul 10 21:43:04 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 16:43:04 -0400 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162955.C7313@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Mon, Jul 10, 2000 at 04:29:55PM -0400 References: <20000710162855.A9245@thyrsus.com> <20000710162955.C7313@kronos.cnri.reston.va.us> Message-ID: <20000710164304.B9337@thyrsus.com> Andrew Kuchling : > *blink* I've never even touched the ConfigParser module, so I don't > know why Guido thought I had any interest in it. The first check-in > comment for the module is "This was originally written by Ken and > later revamped by Barry." Doh. Sorry. My bad. It is Ken, not Andrew. -- Eric S. Raymond A ``decay in the social contract'' is detectable; there is a growing feeling, particularly among middle-income taxpayers, that they are not getting back, from society and government, their money's worth for taxes paid. The tendency is for taxpayers to try to take more control of their finances .. -- IRS Strategic Plan, (May 1984) From fdrake@beopen.com Mon Jul 10 22:00:37 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:00:37 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules md5.h,2.5,2.6 md5c.c,2.3,2.4 In-Reply-To: <004201bfea3f$17b154c0$f2a6b5d4@hagrid> References: <200007100421.VAA16454@slayer.i.sourceforge.net> <004201bfea3f$17b154c0$f2a6b5d4@hagrid> Message-ID: <14698.14709.491272.693396@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > weren't you supposed to drop out of sight for a while? I did; I just poked my head round the corner when they were all asleep! ;-) But I've been out of touch for most of the day, so they've had as much of my time as they can handle for a couple of hours. Maybe I can get some of this email deleted! > besides, I'd assigned these patches to myself, and applied > them locally. just thought I'd get some sleep before I checked > them in again. > > (iow, please check the patch archive before hacking along. > someone else might be working on the same thing) Ah, I'd checked the open patches, but was in too much of a rush. Sorry! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Mon Jul 10 22:05:48 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:05:48 -0400 (EDT) Subject: [Python-Dev] CVS: python/dist/src/Modules posixmodule.c,2.143,2.144 In-Reply-To: <20000710013250.P29590@lyra.org> References: <200007091310.GAA27888@slayer.i.sourceforge.net> <20000710013250.P29590@lyra.org> Message-ID: <14698.15020.771347.741561@cj42289-a.reston1.va.home.com> Greg Stein writes: > hmm. should that be PyLong_FromVoidPtr() ? It will return the appropriate > object type based on the size of a void*. Greg, I see that the PyLong_FromVoidPtr() isn't documented -- are you volunteering? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy@beopen.com Mon Jul 10 22:12:31 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 17:12:31 -0400 (EDT) Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length Message-ID: <14698.15423.878220.203259@bitdiddle.concentric.net> Tuple, List, String, and Dict have a PyXXX_Size method. The abstract object interface uses PySequence_Length. This is inconsistent and hard to remember. Can we add PySequence_Size and mark Length as deprecated? Jeremy From gstein@lyra.org Mon Jul 10 22:16:38 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 14:16:38 -0700 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <200007101725.MAA01255@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 12:25:12PM -0500 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> Message-ID: <20000710141638.R29590@lyra.org> On Mon, Jul 10, 2000 at 12:25:12PM -0500, Guido van Rossum wrote: > > I didn't bother to check, but does the embed Makefile include python's > > Makefile* stuff from $prefix/config ? Does it contain -export-dynamic ? If > > so, very pecurliar... ;-P > > Makefile includes are notoriously unportable, aren't they? The > embed/Makefile is a lame excuse for a Makefile -- it has XXX comments > all over the place telling you to edit things to match the Python main > Makefile... :-( My fault -- feel free to fix! We're using includes in the Apache 2.0 makefiles. I'm not sure whether this is going to make Apache 2.0 less portable or not. There haven't been any issues yet, though. (I think the makefile organization came from PHP; assuming that is as portable as Apache 1.3, then makefile includes are pretty darn portable) IMO, I say "start using makefile includes" and see who screams. VPATH is not portable, though. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Fredrik Lundh" Message-ID: <025001bfeab4$f07251e0$f2a6b5d4@hagrid> jeremy wrote: > Tuple, List, String, and Dict have a PyXXX_Size method. The abstract > object interface uses PySequence_Length. This is inconsistent and > hard to remember. Can we add PySequence_Size and mark Length as > deprecated? don't forget PyObject_Length and PyMapping_Length... From fdrake@beopen.com Mon Jul 10 22:20:04 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:20:04 -0400 (EDT) Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <20000710023523.Y29590@lyra.org> References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> <20000710023523.Y29590@lyra.org> Message-ID: <14698.15876.760261.661549@cj42289-a.reston1.va.home.com> Greg Stein writes: > bah. just file feature requests for them to use ViewCVS. cvsweb is a piece > of crap anyways :-) I've heard you say this before, but I've never had any problems with cvsweb. The display seems fine and I've never missed a feature. If you're being serious and not just plugging your own code, you need to be specific about the problems, and how ViewCVS is better. The problem with had with ViewCVS at python.org was the use of a single file for the script; parsing the whole thing for every run was just too slow. Part of that is the machine, part was configuration, and part was an overly high cost to the convenient installation. The last of those is in your court (possibly fixed by a more recent version; I don't know). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein@lyra.org Mon Jul 10 22:29:54 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 14:29:54 -0700 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <14698.15876.760261.661549@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 10, 2000 at 05:20:04PM -0400 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> <20000710023523.Y29590@lyra.org> <14698.15876.760261.661549@cj42289-a.reston1.va.home.com> Message-ID: <20000710142954.S29590@lyra.org> On Mon, Jul 10, 2000 at 05:20:04PM -0400, Fred L. Drake, Jr. wrote: > > Greg Stein writes: > > bah. just file feature requests for them to use ViewCVS. cvsweb is a piece > > of crap anyways :-) > > I've heard you say this before, but I've never had any problems with > cvsweb. The display seems fine and I've never missed a feature. If > you're being serious and not just plugging your own code, you need to > be specific about the problems, and how ViewCVS is better. From the ViewCVS web page: - colorization of files - Bonsai-like query facilities - Annotation/blame support against read-only repositories - per-virtual-host configuration - some bug fixes / robustness > The problem with had with ViewCVS at python.org was the use of a > single file for the script; parsing the whole thing for every run was > just too slow. Part of that is the machine, part was configuration, > and part was an overly high cost to the convenient installation. The > last of those is in your court (possibly fixed by a more recent > version; I don't know). Yup. Known issue. The installation process is getting a bit more complicated now that we have Bonsai functionality in there, too. As a result, I'm going to be fixing the parse/compile time issue. And note that it was also your box, in a big way. I haven't experienced it on my own box or on apache.org. But that doesn't excuse the parse/compile step that is caused by the one-big-script thing. Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake@beopen.com Mon Jul 10 22:29:00 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:29:00 -0400 (EDT) Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <39699401.790447E8@lemburg.com> References: <20000709215057.95047E2673@oratrix.oratrix.nl> <39699401.790447E8@lemburg.com> Message-ID: <14698.16412.396383.814694@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > There are lots of comments about it in site.py. > sys.setdefaultencoding() is meant to be used *only* in site.py-- > that's why it gets removed after having made the final decision The fact that it gets removed and is only provided as a hook for site.py needs to be documented in comments in sysmodule.c. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Fredrik Lundh" <20000710023523.Y29590@lyra.org> <14698.15876.760261.661549@cj42289-a.reston1.va.home.com> Message-ID: <027801bfeab6$aa6115e0$f2a6b5d4@hagrid> fred drake: > I've heard you say this before, but I've never had any problems with > cvsweb. The display seems fine and I've never missed a feature. If > you're being serious and not just plugging your own code, you need to > be specific about the problems, and how ViewCVS is better. it works with MSIE5, for a start. and it's written by greg, in python. that's all I need to know ;-) the IE problem could be a configuration problem, of course. unless tim beats me to it, I'll submit a support request some day... From fdrake@beopen.com Mon Jul 10 22:34:04 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:34:04 -0400 (EDT) Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <20000710100837.6232337186D@snelboot.oratrix.nl> References: <20000710100837.6232337186D@snelboot.oratrix.nl> Message-ID: <14698.16716.343786.196699@cj42289-a.reston1.va.home.com> Jack Jansen writes: > pretty abysmal commercial ssh which could possibly be beaten into > forwarding connections, but it's expensive (and it doesn't work:-). And port-forwarding isn't likely to help, either. ;( The remote CVS protocol can be used directly over a socket, but the standard CVS client isn't written to work that way with authentication. It really wants to talk to another process via a pipe (such as rsh or ssh); I have no idea how feasible this is on the Mac (because of my ignorance, not because I don't think the Mac can do it). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas@xs4all.net Mon Jul 10 22:34:16 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 23:34:16 +0200 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <027801bfeab6$aa6115e0$f2a6b5d4@hagrid>; from effbot@telia.com on Mon, Jul 10, 2000 at 11:34:41PM +0200 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com><20000710023523.Y29590@lyra.org> <14698.15876.760261.661549@cj42289-a.reston1.va.home.com> <027801bfeab6$aa6115e0$f2a6b5d4@hagrid> Message-ID: <20000710233416.S26534@xs4all.nl> On Mon, Jul 10, 2000 at 11:34:41PM +0200, Fredrik Lundh wrote: > the IE problem could be a configuration problem, of course. unless > tim beats me to it, I'll submit a support request some day... I seriously doubt it, unless cvsweb has an option 'break IE5'. (Or 'unbreak IE5', if you so wish ;) The symptoms Tim described exactly match one of the known bugs in IE. It might be fixed in a newer version of cvsweb, of course. If anyone is going to submit a support request, feel free to pass them my email for information on that bug ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip@mojam.com (Skip Montanaro) Mon Jul 10 13:34:33 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Mon, 10 Jul 2000 07:34:33 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000709233525.E26534@xs4all.nl> References: <14691.49563.78765.683762@beluga.mojam.com> <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> <14695.840.448508.397722@beluga.mojam.com> <20000709233525.E26534@xs4all.nl> Message-ID: <14697.49881.701839.36716@beluga.mojam.com> Thomas> I have a couple of questions regarding this patch, if you don't Thomas> mind.... Thomas, I don't mind at all. I will remind folks that I am more the messenger than the messiah on this one, however. Greg Ewing (greg@cosc.canterbury.ac.nz) is the author of the change, so will be much better equipped than me to reply to your comments. I'm more a fan of the construct who happened to be in the right place at the right time. All I did was update Greg's patch to work with 1.5.2+ (which became 1.6alpha, which became 2.0beta). Thomas> For one, the Grammar for list comprehensions: Thomas> '[' [testlist [list_iter]] ']' Thomas> Should that really be 'testlist'? Thomas> [1,2,3,4,5] Thomas> is a list of 5 elements, but Thomas> [1,2,3,4,5 if 1] Thomas> is a list of one element, which is a 5-element tuple. I'll take a look at it. I'm not much of a parser person and my reading of the grammar is hampered by the fact that Grammar/Grammar and the grammar in the language reference manual no longer mesh very well. (Is that something that can be remedied?) I notice that in the comment at the top of com_list_comprehension Greg said: atom: '[' test list_iter ']' which suggests that you are onto something and that the 'testlist' variant is either a typo or a mistake that wasn't corrected in a later version of Greg's thinking ... Thomas> I'd say the Grammar would be more like this: Thomas> atom: '(' [testlist] ')' | '[' [listmaker] ']' | '{' [dictmaker] '}' | '' testlist '' | NAME | NUMBER | STRING+ Thomas> listmaker: test ( list_iter | (',' test)* [',']) Thomas> list_iter: list_for | list_if Thomas> list_for: 'for' exprlist 'in' testlist [list_iter] Thomas> list_if: 'if' test [list_iter] Thomas> And by coincidence this is also fits very nicely with what the Thomas> 'range-literal' patch does ;-) If we're going to have both we should probably have them work together, I agree. Thomas> Another issue is the code- and logic-duplication of the patch to Thomas> compile.c: it looks like a large part was just copied from Thomas> com_for_node, and the block-stuff commented out. Why is it Thomas> commented out, by the way ? Don't exceptions or something need Thomas> the block setup ? If the block-setup was kept in, it might be Thomas> easier to split the com_for_node into a function that compiles Thomas> the header, and one that compiles the suite, and make Thomas> com_list_for compile its own 'suite'. I'm hoping that's Thomas> possible, because it would keep the code a lot cleaner, and it Thomas> would make it easier for me to implement 'for i in x;j in y' and Thomas> have it work for list comprehensions too ;-) Come up with an alternate patch that does what you want. I think very few people have actually looked at Greg's patch closely and that his original patch was more a proof of concept than a ready-for-primetime chunk of code. Thomas> Also, the patch creates a list, stores it locally, and calls Thomas> append() to it inside the inner loop. Isn't it possible for the Thomas> patch to build the list on the stack, pushing individual Thomas> elements on the stack and calling BUILD_LIST at the end ? The Thomas> for loops counts the number of loops anyway ;) and it would get Thomas> rid of the fairly ugly tmpname thing altogether, I Thomas> think. However, the logic of when to ROT_THREE and ROT_TWO and Thomas> what not might run away from under us ;-P (But I'm facing that Thomas> anyway, with the parallel-forloop) Dunno. Thomas> Alternatively, it would be nice to store the lists' append() in Thomas> a local vrbl, to reduce the number of lookups ;-P Oh, and Thomas> lastly, the patch is just screaming for a re-indent all over, Thomas> and of some wel-placed comments... some of it was quite Thomas> difficult to follow, compared to the rest of the code. Yes, it does need to be reindented. Greg, can you give us some feedback on Thomas's comments when you get a chance? -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From gstein@lyra.org Mon Jul 10 23:11:07 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 15:11:07 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101926.OAA02072@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 02:26:25PM -0500 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> <200007101926.OAA02072@cj20424-a.reston1.va.home.com> Message-ID: <20000710151106.U29590@lyra.org> On Mon, Jul 10, 2000 at 02:26:25PM -0500, Guido van Rossum wrote: > > How do I do that in CVS-land? > > cvs admin -o I don't think the use of "cvs admin" should ever be encouraged. > Or you could retrieve the previous version and check it in on top, > with a comment such as "eating my words". :-) This is usually best, and it tracks what is actually occurring. Note that Eric's use of "cvs admin" did not generate a checkin email. Only by going and looking at the file, did I see that he has actually reverted the change. Committing over the top would generate a checkin message, so people can track the state of things. >... > > Also BTW, my access mechanics are a Python script called `forgetool' > > that automates away a bunch of CVS housekeeping -- setting CVSROOT > > properly on a per-project basis is one of the things it does. I'll > > write some docs and release it shortly. > > I thought that you almost never have to set the CVSROOT variable once > you've established your project work tree -- it's all stored in > CVS/Root anyway. I believe CVSROOT is only used when you do a "cvs > checkout" and that doesn't happen very often... This is correct. CVSROOT never needs to be set or to be changed once you have a working directory. In fact, with Python, I usually do the following: $ cvs ... co python $ mv python x $ mv x/dist/src python $ rm -r x The extra "dist/src" in the local filesystem is just annoying :-) Point is: CVS knows that my new python/ directory actually corresponds to python/dist/src/ in the CVS repository because of the CVS/* files. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Mon Jul 10 23:16:41 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 15:16:41 -0700 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <14698.16412.396383.814694@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 10, 2000 at 05:29:00PM -0400 References: <20000709215057.95047E2673@oratrix.oratrix.nl> <39699401.790447E8@lemburg.com> <14698.16412.396383.814694@cj42289-a.reston1.va.home.com> Message-ID: <20000710151641.V29590@lyra.org> On Mon, Jul 10, 2000 at 05:29:00PM -0400, Fred L. Drake, Jr. wrote: > > M.-A. Lemburg writes: > > There are lots of comments about it in site.py. > > sys.setdefaultencoding() is meant to be used *only* in site.py-- > > that's why it gets removed after having made the final decision > > The fact that it gets removed and is only provided as a hook for > site.py needs to be documented in comments in sysmodule.c. Um. I thought the current consensus was to remove setdefaultencoding() altogether and just stick with an ASCII default encoding. I don't think we should let people change the default if that is going to break other parts of the Python interpreter. It could also seriously mess up code that is expecting that hard-coded ASCII default. Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw@beopen.com Mon Jul 10 23:20:54 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Mon, 10 Jul 2000 18:20:54 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection (I think) Message-ID: <14698.19526.232315.802728@anthem.concentric.net> --ADeQU47/Is Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit While running through the test suite with Purify, I ran across the following script which core dumps the current CVS snapshot. You need to have gc enabled to trigger this. I'm running on Solaris 2.6, using gcc 2.8.1. It also cores my Linux build of Python from CVS using egcs-2.91.66. -Barry --ADeQU47/Is Content-Type: text/plain Content-Disposition: inline; filename="core.py" Content-Transfer-Encoding: 7bit import sre assert sre.sub('.', lambda m: r"\n", 'x') == '\\n' assert sre.sub('.', r"\n", 'x') == '\n' s = r"\1\1" assert sre.sub('(.)', s, 'x') == 'xx' assert sre.sub('(.)', sre.escape(s), 'x') == s assert sre.sub('(.)', lambda m: s, 'x') == s assert sre.sub('(?Px)', '\g\g', 'xx') == 'xxxx' assert sre.sub('(?Px)', '\g\g<1>', 'xx') == 'xxxx' assert sre.sub('(?Px)', '\g\g', 'xx') == 'xxxx' assert sre.sub('(?Px)', '\g<1>\g<1>', 'xx') == 'xxxx' assert sre.sub('a', r'\t\n\v\r\f\a\b\B\Z\a\A\w\W\s\S\d\D', 'a') == '\t\n\v\r\f\a\b\\B\\Z\a\\A\\w\\W\\s\\S\\d\\D' assert sre.sub('a', '\t\n\v\r\f\a', 'a') == '\t\n\v\r\f\a' assert sre.sub('a', '\t\n\v\r\f\a', 'a') == (chr(9)+chr(10)+chr(11)+chr(13)+chr(12)+chr(7)) assert sre.sub('^\s*', 'X', 'test') == 'Xtest' --ADeQU47/Is Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit -------------------- snip snip -------------------- Program received signal SIGSEGV, Segmentation fault. 0x18659c in gc_list_remove (node=0x48028c) at ./gcmodule.c:86 86 node->gc_prev->gc_next = node->gc_next; (gdb) where #0 0x18659c in gc_list_remove (node=0x48028c) at ./gcmodule.c:86 #1 0x186fb4 in visit_reachable (op=0x480298, roots=0xefffe648) at ./gcmodule.c:194 #2 0x1227b0 in list_traverse (o=0x494ae4, visit=0x186f08 , arg=0xefffe648) at listobject.c:1339 #3 0x18710c in move_root_reachable (reachable=0xefffe648) at ./gcmodule.c:212 #4 0x187dc8 in collect (young=0x4026c0, old=0x4026cc) at ./gcmodule.c:390 #5 0x1883fc in collect_generations () at ./gcmodule.c:481 #6 0x1884e4 in _PyGC_Insert (op=0x4d48fc) at ./gcmodule.c:500 #7 0x147220 in PyTuple_New (size=1) at tupleobject.c:96 #8 0x148348 in tupleslice (a=0x4e40d4, ilow=1, ihigh=2) at tupleobject.c:294 #9 0xfbc80 in PySequence_GetSlice (s=0x4e40d4, i1=1, i2=2) at abstract.c:897 #10 0x8a100 in Exception__init__ (self=0x4d736c, args=0x4e40d4) at exceptions.c:217 #11 0xb0754 in call_builtin (func=0x445ce0, arg=0x4e40d4, kw=0x0) at ceval.c:2404 #12 0xb03fc in PyEval_CallObjectWithKeywords (func=0x445ce0, arg=0x4e40d4, kw=0x0) at ceval.c:2369 #13 0xb0e9c in call_function (func=0x445ce0, arg=0x4e40d4, kw=0x0) at ceval.c:2484 #14 0xb03bc in PyEval_CallObjectWithKeywords (func=0x44ad34, arg=0x4e46bc, kw=0x0) at ceval.c:2367 #15 0x101988 in PyInstance_New (class=0x44f8ec, arg=0x4e46bc, kw=0x0) at classobject.c:472 #16 0xb07b8 in call_builtin (func=0x44f8ec, arg=0x4e46bc, kw=0x0) at ceval.c:2407 #17 0xb03fc in PyEval_CallObjectWithKeywords (func=0x44f8ec, arg=0x4e46bc, kw=0x0) at ceval.c:2369 #18 0xc6c30 in PyErr_NormalizeException (exc=0xefffedf8, val=0xefffedfc, tb=0xefffee00) at errors.c:190 #19 0xaba18 in eval_code2 (co=0x4b5c08, globals=0x4a5b94, locals=0x0, args=0x462a1c, argcount=2, kws=0x462a24, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1846 #20 0xa7f3c in eval_code2 (co=0x4b7eb0, globals=0x466824, locals=0x0, args=0x4e4b78, argcount=4, kws=0x4e4b88, kwcount=0, defs=0x4dcec8, defcount=1, owner=0x0) at ceval.c:1587 #21 0xa7f3c in eval_code2 (co=0x47d1f8, globals=0x466824, locals=0x0, args=0x4bac00, argcount=4, kws=0x0, kwcount=0, defs=0x4dcd18, defcount=1, owner=0x0) at ceval.c:1587 #22 0xb13c0 in call_function (func=0x4dcc2c, arg=0x4babf4, kw=0x0) at ceval.c:2529 #23 0xb03bc in PyEval_CallObjectWithKeywords (func=0x4dcc2c, arg=0x4babf4, kw=0x0) at ceval.c:2367 #24 0xfe284 in PyObject_CallObject (o=0x4dcc2c, a=0x4babf4) at abstract.c:1360 #25 0x1c42f4 in call (function=0x2cdbe0 "_sub", args=0x4babf4) at ./_sre.c:1458 #26 0x1c4514 in pattern_sub (self=0x4ea2a0, args=0x4e605c) at ./_sre.c:1474 #27 0xb0754 in call_builtin (func=0x4d42b0, arg=0x4e605c, kw=0x0) at ceval.c:2404 #28 0xb03fc in PyEval_CallObjectWithKeywords (func=0x4d42b0, arg=0x4e605c, kw=0x0) at ceval.c:2369 #29 0xa90f0 in eval_code2 (co=0x479378, globals=0x466824, locals=0x0, args=0x45d600, argcount=3, kws=0x45d60c, kwcount=0, defs=0x48e598, defcount=1, owner=0x0) at ceval.c:1688 #30 0xa7f3c in eval_code2 (co=0x47a6e8, globals=0x45b14c, locals=0x45b14c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1587 #31 0x8e71c in PyEval_EvalCode (co=0x47a6e8, globals=0x45b14c, locals=0x45b14c) at ceval.c:298 #32 0xe6f9c in run_node (n=0x4644f8, filename=0xeffffb26 "/tmp/core.py", globals=0x45b14c, locals=0x45b14c) at pythonrun.c:895 #33 0xe6eac in run_err_node (n=0x4644f8, filename=0xeffffb26 "/tmp/core.py", globals=0x45b14c, locals=0x45b14c) at pythonrun.c:880 #34 0xe6df0 in PyRun_File (fp=0x42e728, filename=0xeffffb26 "/tmp/core.py", start=257, globals=0x45b14c, locals=0x45b14c) at pythonrun.c:868 #35 0xe5218 in PyRun_SimpleFile (fp=0x42e728, filename=0xeffffb26 "/tmp/core.py") at pythonrun.c:578 #36 0xe4804 in PyRun_AnyFile (fp=0x42e728, filename=0xeffffb26 "/tmp/core.py") at pythonrun.c:459 #37 0x85584 in Py_Main (argc=3, argv=0xeffff9fc) at main.c:271 #38 0x84848 in main (argc=3, argv=0xeffff9fc) at python.c:10 --ADeQU47/Is-- From bwarsaw@beopen.com Mon Jul 10 23:24:58 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Mon, 10 Jul 2000 18:24:58 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> <200007101926.OAA02072@cj20424-a.reston1.va.home.com> <20000710151106.U29590@lyra.org> Message-ID: <14698.19770.699007.508033@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: | $ cvs ... co python | $ mv python x | $ mv x/dist/src python | $ rm -r x GS> The extra "dist/src" in the local filesystem is just annoying GS> :-) GS> Point is: CVS knows that my new python/ directory actually GS> corresponds to python/dist/src/ in the CVS repository because GS> of the CVS/* files. cvs ... co -d python python/dist/src will do the same thing, much more easily! -Barry From gstein@lyra.org Mon Jul 10 23:33:14 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 15:33:14 -0700 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162855.A9245@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 10, 2000 at 04:28:55PM -0400 References: <20000710162855.A9245@thyrsus.com> Message-ID: <20000710153314.W29590@lyra.org> On Mon, Jul 10, 2000 at 04:28:55PM -0400, Eric S. Raymond wrote: > Earlier today, I committed a patch to ConfigParser that adds three new > methods to the class. Here is the documentation: Excellent! I have a few subclasses of ConfigParser that do these things, too. Glad to see it in the standard distro :-) >... > These new methods are additions to the class, and do not change any > existing code. Nevertheless Guido sent me a heads-up that I had > committed a marginal violation of Python etiquette by changing the > module without the explicit sign-off of the maintainers. API changes probably ought to be discussed on this list (which includes the maintainers of any code). Basic point: the "maintainer(s)" is usually quite unclear since we avoid attribution within the source if at all possible. Posing the suggested change here allows for changing maintainers (note that Fred has done a tone of work on ConfigParser, and I've submitted a few changes myself, too!), and it allows for broader input. However, bug fixes and minor reworking should probably be allowed regardless of the maintainer. I'd hate to end up at a point where the Python interpreter is partitioned into a bunch of little fiefdoms, where you must pay a toll to enter. >... > Two more things remain to be done: > > First, for completeness there ought to be remove_section and remove_option > methods (though forgetool does not yet use them). I have documented these > as follows: +1 >... > Second, the new methods expose a bug in the existing code. Because > the case of section and option names is folded on input, the new > write() method emits edited configurations with their case smashed. I > think the existing code should be fixed to preserve case, with > string.lower() being applied at key lookup time. +1 The string.lower() at lookup time shifts the performance response, but I don't really see config state as performance-intensive. Cheers, -g -- Greg Stein, http://www.lyra.org/ From m.favas@per.dem.csiro.au Mon Jul 10 23:44:20 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Tue, 11 Jul 2000 06:44:20 +0800 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? Message-ID: <396A51C4.894E1550@per.dem.csiro.au> No problems (apart from the usual test failures) with the CVS from 10 July, but with CVS from 11 July I get core dumps at random points in "make test" which seem to point to a problem with the GC code. Sample dbx output: (Platform is DEC (Compaq) Alpha, Compaq C T6.3-125 (dtk) on Digital UNIX V4.0F (Rev. 1229)) dbx version 3.11.10 Type 'help' for help. Core file created by program "python" thread 0xb signal Segmentation fault at >*[__nxm_thread_kill, 0x3ff805c7ca8] ret r31, (r26), 1 (dbx) where > 0 __nxm_thread_kill(0x3ffc01b3c10, 0x1200f47dc, 0x0, 0x11fffeed0, 0x3ff8059c724) [0x3ff805c7ca8] 1 pthread_kill(0x1200ea970, 0x1, 0x0, 0x11fffeee0, 0x3ffc01b36c0) [0x3ff805ad6f4] 2 (unknown)() [0x3ff8059712c] 3 (unknown)() [0x3ff807e370c] 4 exc_unwind(0x11fffaf28, 0xabadabad00beed00, 0x3ff80592b90, 0x11fffb1c8, 0x3ff807e3acc) [0x3ff807e380c] 5 exc_raise_signal_exception(0x86, 0x0, 0x120159490, 0x1, 0x1) [0x3ff807e3ac8] 6 (unknown)() [0x3ff805af254] 7 (unknown)() [0x12015948c] 8 (unknown)() [0x12014f36c] 9 (unknown)() [0x120159844] 10 _PyGC_Insert(0x7f, 0x6f, 0x120111690, 0x2, 0x140155e20) [0x120159d04] This _PyGC_Insert always appears here in the trace - sometimes called from PyTuple_New, sometimes from PyMethod_New... -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From peter@schneider-kamp.de Tue Jul 11 02:05:10 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 11 Jul 2000 01:05:10 +0000 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? References: <396A51C4.894E1550@per.dem.csiro.au> Message-ID: <396A72C6.6810C95E@stud.ntnu.no> Mark Favas wrote: > > No problems (apart from the usual test failures) with the CVS from 10 > July, but with CVS from 11 July I get core dumps at random points in > "make test" which seem to point to a problem with the GC code. Sample > dbx output: I wouldn't bet my life on it, but I don't think the GC code is responsible. The only changes checked in during the last days were the "long n = 0;" initialization and my ANSI-fication (which I just reviewed and which should be harmless). don't-have-a-clue-though-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From tim_one@email.msn.com Tue Jul 11 00:10:19 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 19:10:19 -0400 Subject: [Python-Dev] Messy gc death Message-ID: With the latest CVS (as of 6:30pm EDT), the std test suite blows up under Windows release & debug builds, like so (this is debug): Adding parser accelerators ... Done. test_grammar test_opcodes test_operations test_builtin test_exceptions test_types test_MimeWriter test_al test test_al skipped -- an optional feature could not be imported test_array test_atexit with a memory error. However, test_atexit works fine in isolation, so this isn't a nice little local bug. The death is in this function from gcmodule.c: static int visit_decref(PyObject *op, void *data) { if (op && PyObject_IS_GC(op)) { ***********this line************** PyObject_AS_GC(op)->gc_refs--; } return 0; } data is NULL at this point, and op appears to be a legit memory address, but the fields in op make no sense: _ob_next is 0x24, _ob_prev is 1, and ob_type is the MS "landfill" value 0xfdfdfdfd (MS debug libraries set malloc'ed memory to that). Chasing the bogus ob_type address is the cause of the meltdown. Here's the traceback: visit_decref(_object * 0x0082ad60, void * 0x00000000) line 151 + 12 bytes list_traverse(PyListObject * 0x0082af7c, int (_object *, void *)* 0x1e14ee2d visit_decref(_object *, void *), void * 0x00000000) line 1339 + 11 bytes subtract_refs(_gc_head * 0x1e1dae18 generation0) line 167 + 17 bytes collect(_gc_head * 0x1e1dae18 generation0, _gc_head * 0x1e1dae28 generation1) line 383 + 9 bytes collect_generations() line 481 + 15 bytes _PyGC_Insert(_object * 0x0082ca6c) line 501 PyDict_New() line 111 + 9 bytes PyModule_New(char * 0x0063f160) line 29 + 5 bytes PyImport_AddModule(char * 0x0063f160) line 449 + 9 bytes PyImport_ExecCodeModuleEx(char * 0x0063f160, _object * 0x0082b4c0, char * 0x0063eea8) line 482 + 9 bytes load_source_module() line 758 + 17 bytes load_module(char * 0x0063f160, _iobuf * 0x1025a908, char * 0x0063f004, int 1) line 1240 + 17 bytes import_submodule(_object * 0x1e1e5bc0 __Py_NoneStruct, char * 0x0063f160, char * 0x0063f160) line 1793 + 33 bytes load_next(_object * 0x1e1e5bc0 __Py_NoneStruct, _object * 0x1e1e5bc0 __Py_NoneStruct, char * * 0x0063f274, char * 0x0063f160, int * 0x0063f15c) line 1641 + 17 bytes import_module_ex() line 1483 + 35 bytes PyImport_ImportModuleEx(char * 0x007d0eec, _object * 0x007e541c, _object * 0x007e541c, _object * 0x1e1e5bc0 __Py_NoneStruct) line 1527 + 21 bytes builtin___import__() line 47 + 21 bytes call_builtin(_object * 0x00761fd0, _object * 0x008033ac, _object * 0x00000000) line 2404 + 11 bytes PyEval_CallObjectWithKeywords(_object * 0x00761fd0, _object * 0x008033ac, _object * 0x00000000) line 2369 + 17 bytes eval_code2(PyCodeObject * 0x007e34f0, _object * 0x007e541c, _object * 0x007e541c, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * 0x00000000) line 1425 + 15 bytes PyEval_EvalCode(PyCodeObject * 0x007e34f0, _object * 0x007e541c, _object * 0x007e541c) line 303 + 31 bytes PyImport_ExecCodeModuleEx(char * 0x0063f75c, _object * 0x007e34f0, char * 0x0063f4a4) line 506 + 17 bytes load_source_module() line 758 + 17 bytes load_module(char * 0x0063f75c, _iobuf * 0x1025a8e8, char * 0x0063f600, int 1) line 1240 + 17 bytes import_submodule(_object * 0x1e1e5bc0 __Py_NoneStruct, char * 0x0063f75c, char * 0x0063f75c) line 1793 + 33 bytes load_next(_object * 0x1e1e5bc0 __Py_NoneStruct, _object * 0x1e1e5bc0 __Py_NoneStruct, char * * 0x0063f870, char * 0x0063f75c, int * 0x0063f758) line 1641 + 17 bytes import_module_ex() line 1483 + 35 bytes PyImport_ImportModuleEx(char * 0x007da7dc, _object * 0x0076edbc, _object * 0x0079f59c, _object * 0x0079942c) line 1527 + 21 bytes builtin___import__() line 47 + 21 bytes call_builtin(_object * 0x00761fd0, _object * 0x007e987c, _object * 0x00000000) line 2404 + 11 bytes PyEval_CallObjectWithKeywords(_object * 0x00761fd0, _object * 0x007e987c, _object * 0x00000000) line 2369 + 17 bytes eval_code2(PyCodeObject * 0x00854060, _object * 0x0076edbc, _object * 0x00000000, _object * * 0x0084cee4, int 4, _object * * 0x0084cef4, int 0, _object * * 0x0084a3e0, int 1, _object * 0x00000000) line 1690 + 26 bytes eval_code2(PyCodeObject * 0x00854fb0, _object * 0x0076edbc, _object * 0x00000000, _object * * 0x00771e6c, int 0, _object * * 0x00771e6c, int 0, _object * * 0x008493d0, int 8, _object * 0x00000000) line 1590 + 88 bytes eval_code2(PyCodeObject * 0x00854990, _object * 0x0076edbc, _object * 0x0076edbc, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * 0x00000000) line 1590 + 88 bytes PyEval_EvalCode(PyCodeObject * 0x00854990, _object * 0x0076edbc, _object * 0x0076edbc) line 303 + 31 bytes run_node(_node * 0x007d25d0, char * 0x00760dd9, _object * 0x0076edbc, _object * 0x0076edbc) line 895 + 17 bytes run_err_node(_node * 0x007d25d0, char * 0x00760dd9, _object * 0x0076edbc, _object * 0x0076edbc) line 880 + 21 bytes PyRun_File(_iobuf * 0x1025a888, char * 0x00760dd9, int 257, _object * 0x0076edbc, _object * 0x0076edbc) line 869 + 38 bytes PyRun_SimpleFile(_iobuf * 0x1025a888, char * 0x00760dd9) line 578 + 26 bytes PyRun_AnyFile(_iobuf * 0x1025a888, char * 0x00760dd9) line 459 + 13 bytes Py_Main(int 2, char * * 0x00760da0) line 273 + 34 bytes main(int 2, char * * 0x00760da0) line 10 + 13 bytes mainCRTStartup() line 338 + 17 bytes No wonder Python needs Stackless to run on a Palm . anyone-got-a-clue?-ly y'rs - tim From m.favas@per.dem.csiro.au Tue Jul 11 01:07:09 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Tue, 11 Jul 2000 08:07:09 +0800 Subject: [Python-Dev] Messy gc death (Was: Core dump in garbage collection: PyGC_Insert???) Message-ID: <396A652D.254B7FE8@per.dem.csiro.au> Throwing a -g flag at the compilation and poking at the resultant core, I get two different traces, depending on where it crashed during "make test". The first is the the same trace as Tim, viz: Core file created by program "python" thread 0x11 signal Segmentation fault at >*[__nxm_thread_kill, 0x3ff805c7ca8] ret r31, (r26), 1 (dbx) where > 0 __nxm_thread_kill(0x3ffc01b3c10, 0x1200f4ccc, 0x0, 0x11fffeed0, 0x3ff8059c724) [0x3ff805c7ca8] 1 pthread_kill(0x1200ea6b0, 0x1, 0x0, 0x11fffeee0, 0x3ffc01b36c0) [0x3ff805ad6f4] 2 (unknown)() [0x3ff8059712c] 3 (unknown)() [0x3ff807e370c] 4 exc_unwind(0x11fffc568, 0xabadabad00beed00, 0x4f, 0x11fffc808, 0x3ff807e3acc) [0x3ff807e380c] 5 exc_raise_signal_exception(0x86, 0x0, 0x12015bdf0, 0x1, 0x1) [0x3ff807e3ac8] 6 (unknown)() [0x3ff805af254] 7 visit_decref(op = 0x1405f0d40, data = (nil)) ["./gcmodule.c":151, 0x12015bdec] 8 list_traverse(o = 0x1405e0818, visit = 0x12015bde0, arg = (nil)) ["listobject.c":1339, 0x120151c10] 9 subtract_refs(containers = 0x140019b30) ["./gcmodule.c":165, 0x12015be54] 10 collect(young = 0x140019b30, old = 0x140019b48) ["./gcmodule.c":383, 0x12015c53c] 11 collect_generations() ["./gcmodule.c":481, 0x12015c84c] 12 _PyGC_Insert(op = 0x140430158) ["./gcmodule.c":500, 0x12015c8c0] and the second is: Core file created by program "python" thread 0xb signal Segmentation fault at >*[__nxm_thread_kill, 0x3ff805c7ca8] ret r31, (r26), 1 (dbx) where > 0 __nxm_thread_kill(0x3ffc01b3c10, 0x1200f4ccc, 0x0, 0x11fffeed0, 0x3ff8059c724) [0x3ff805c7ca8] 1 pthread_kill(0x1200ea6b0, 0x1, 0x0, 0x11fffeee0, 0x3ffc01b36c0) [0x3ff805ad6f4] 2 (unknown)() [0x3ff8059712c] 3 (unknown)() [0x3ff807e370c] 4 exc_unwind(0x11fffbea8, 0xabadabad00beed00, 0x3ff80592b90, 0x11fffc148, 0x3ff807e3acc) [0x3ff807e380c] 5 exc_raise_signal_exception(0x86, 0x0, 0x12015bce0, 0x1, 0x1) [0x3ff807e3ac8] 6 (unknown)() [0x3ff805af254] 7 gc_list_remove(node = 0x140472728) ["./gcmodule.c":86, 0x12015bcdc] 8 visit_reachable(op = 0x140472740, roots = 0x11fffcaa0) ["./gcmodule.c":194, 0x12015bf04] 9 list_traverse(o = 0x140447518, visit = 0x12015bed0, arg = 0x11fffcaa0) ["listobject.c":1339, 0x120151c10] 10 move_root_reachable(reachable = 0x11fffcaa0) ["./gcmodule.c":212, 0x12015bf6c] 11 collect(young = 0x140019b60, old = 0x140019b60) ["./gcmodule.c":390, 0x12015c558] 12 collect_generations() ["./gcmodule.c":466, 0x12015c76c] 13 _PyGC_Insert(op = 0x140449b98) ["./gcmodule.c":500, 0x12015c8c0] -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From esr@thyrsus.com Tue Jul 11 01:34:35 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 20:34:35 -0400 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710153314.W29590@lyra.org>; from gstein@lyra.org on Mon, Jul 10, 2000 at 03:33:14PM -0700 References: <20000710162855.A9245@thyrsus.com> <20000710153314.W29590@lyra.org> Message-ID: <20000710203435.A9793@thyrsus.com> Greg Stein : > The string.lower() at lookup time shifts the performance response, but I > don't really see config state as performance-intensive. That's my thinking as well. -- Eric S. Raymond The common argument that crime is caused by poverty is a kind of slander on the poor. -- H. L. Mencken From greg@cosc.canterbury.ac.nz Tue Jul 11 01:31:55 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Tue, 11 Jul 2000 12:31:55 +1200 (NZST) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14697.49881.701839.36716@beluga.mojam.com> Message-ID: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> Thomas> '[' [testlist [list_iter]] ']' Thomas> Should that really be 'testlist'? I can't remember my exact thinking at the time, but probably I decided that, for consistency with the rest of the language, the most general form of expression possible, without making the grammar ambiguous, should be allowed. Personally, I don't mind very much either way, but if it were changed I expect you'd get complaints that things like [x,y for x in (1,2,3) for y in (4,5,6)] didn't do what the programmer expected. Thomas> And by coincidence this is also fits very nicely with what the Thomas> 'range-literal' patch does ;-) I'm not familiar with that one, so I can't comment. Thomas> it looks like a large part was just copied from Thomas> com_for_node, and the block-stuff commented out. As Skip said, it was a proof-of-concept, and I wanted to get it working with as few changes to existing code as possible, both because I wasn't sure I understood it well enough to mess with it, and to minimise the chance of conflict with other patches. Thomas> Why is it Thomas> commented out, by the way ? Don't exceptions or something need Thomas> the block setup ? If the block-setup was kept in, it might be The block setup is used to handle breaking out of the for loop. Since it's impossible to put a 'break' inside a list constructor, the block setup is not needed -- or at least that's what I decided at the time. I don't *think* that leaving it out will upset the exception mechanism, but I'm not absolutely sure. Can anyone who knows more about how it works comment? In any case, I agree that the two for-loop compiling procedures could and should be refactored somehow. Thomas> Isn't it possible for the Thomas> patch to build the list on the stack, pushing individual Thomas> elements on the stack and calling BUILD_LIST at the end ? Unfortunately, no. The compiler needs to know the maximum amount of stack used by the procedure, and in the case of a list comprehension, the list size is not known until run time. However, things could still be improved greatly. My recommendation would be to define a new opcode such as LIST_APPEND which would take an item off the top of the stack, reach down stack items and append it to the list found there. That would get rid of the temporary variable as well. Thomas> lastly, the patch is just screaming for a re-indent all over, I sort of hoped that, with it becoming an official feature, someone would go over the code manually afterwards, rather than just applying the patch and leaving it at that. If it's deemed that "someone" should be me, let me know and I'll see what I can do. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From fdrake@beopen.com Tue Jul 11 01:47:58 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 20:47:58 -0400 (EDT) Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <20000710151641.V29590@lyra.org> References: <20000709215057.95047E2673@oratrix.oratrix.nl> <39699401.790447E8@lemburg.com> <14698.16412.396383.814694@cj42289-a.reston1.va.home.com> <20000710151641.V29590@lyra.org> Message-ID: <14698.28350.493348.220791@cj42289-a.reston1.va.home.com> Greg Stein writes: > Um. I thought the current consensus was to remove setdefaultencoding() > altogether and just stick with an ASCII default encoding. I'm most happy with this. My comment was really that it did need a comment there, even in it's temporary existence. But ripping the whole mess out is definately the best solution. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Tue Jul 11 01:50:40 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 20:50:40 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <20000710151106.U29590@lyra.org> References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> <200007101926.OAA02072@cj20424-a.reston1.va.home.com> <20000710151106.U29590@lyra.org> Message-ID: <14698.28512.30573.289668@cj42289-a.reston1.va.home.com> Greg Stein writes: > $ cvs ... co python > $ mv python x > $ mv x/dist/src python > $ rm -r x Try: cvs ... co -d python python/dist/src > The extra "dist/src" in the local filesystem is just annoying :-) Agreed! I've never used that form in my work area. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr@thyrsus.com Tue Jul 11 02:10:00 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 21:10:00 -0400 Subject: [Python-Dev] Re: SourceForge In-Reply-To: <396A6F7D.66D5F085@valinux.com>; from dbressler@valinux.com on Mon, Jul 10, 2000 at 05:51:09PM -0700 References: <20000707133533.E17746@valinux.com> <20000707182448.A31259@thyrsus.com> <39667D29.1A4FB1BB@valinux.com> <20000709214138.I4566@thyrsus.com> <396A4CFC.CEE2419A@valinux.com> <20000710203719.B9793@thyrsus.com> <396A6F7D.66D5F085@valinux.com> Message-ID: <20000710211000.A10068@thyrsus.com> Dan Bressler : > I'm trying to sync schedules -- If we could set it for Tuesday evening, July > 18th, that would work best. OK. Python folks who will be at the Monterey conference; Dan Bressler, one of the managers of SourceForge, is amenable to an evening meeting with this gang on Tuesday the 18th. I gather Tim Purdue, currently the lead programmer on the project, will be there. The exact time is still to be worked out. Anybody got a proposal? -- Eric S. Raymond "I hold it, that a little rebellion, now and then, is a good thing, and as necessary in the political world as storms in the physical." -- Thomas Jefferson, Letter to James Madison, January 30, 1787 From nascheme@enme.ucalgary.ca Tue Jul 11 02:15:37 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Mon, 10 Jul 2000 19:15:37 -0600 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <396A72C6.6810C95E@stud.ntnu.no>; from Peter Schneider-Kamp on Tue, Jul 11, 2000 at 01:05:10AM +0000 References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> Message-ID: <20000710191537.A5853@keymaster.enme.ucalgary.ca> On Tue, Jul 11, 2000 at 01:05:10AM +0000, Peter Schneider-Kamp wrote: > I wouldn't bet my life on it, but I don't think the GC code is > responsible. Its hard to say. The GC code will probably pick up on a lot of problems because it touches many objects. On the other hand, it could be my bug. I'm prettly limited here as my computer is somewhere between Calgary and Reston as I type this. I will try to find the problem though. Neil From nascheme@enme.ucalgary.ca Tue Jul 11 02:28:33 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Mon, 10 Jul 2000 19:28:33 -0600 Subject: [Python-Dev] GC core dump caused by stringobject changes? Message-ID: <20000710192833.B5853@keymaster.enme.ucalgary.ca> These seem to be the changes that trigger the bug. My problem or someone elses? No time to look in detail right now. :( Neil diff -ru py-old/dist/src/Objects/stringobject.c py/dist/src/Objects/stringobject.c --- py-old/dist/src/Objects/stringobject.c Mon Jul 10 17:25:54 2000 +++ py/dist/src/Objects/stringobject.c Mon Jul 10 21:18:35 2000 @@ -744,106 +744,66 @@ int seqlen = 0; int sz = 100; int i, slen; - PyObject *seq; + PyObject *orig, *seq, *item; - if (!PyArg_ParseTuple(args, "O:join", &seq)) + if (!PyArg_ParseTuple(args, "O:join", &orig)) return NULL; - seqlen = PySequence_Length(seq); - if (seqlen < 0 && PyErr_Occurred()) + seq = PySequence_Fast(orig, ""); + if (seq == NULL) { + if (PyErr_ExceptionMatches(PyExc_TypeError)) + PyErr_Format(PyExc_TypeError, + "sequence expected, %.80s found", + orig->ob_type->tp_name); return NULL; + } + seqlen = PySequence_Length(seq); if (seqlen == 1) { - /* Optimization if there's only one item */ - PyObject *item = PySequence_GetItem(seq, 0); - if (item == NULL) - return NULL; - if (!PyString_Check(item) && - !PyUnicode_Check(item)) { - PyErr_SetString(PyExc_TypeError, - "first argument must be sequence of strings"); - Py_DECREF(item); - return NULL; - } + item = PySequence_Fast_GET_ITEM(seq, 0); + Py_INCREF(item); return item; } + if (!(res = PyString_FromStringAndSize((char*)NULL, sz))) return NULL; p = PyString_AsString(res); - /* optimize for lists. all others (tuples and arbitrary sequences) - * just use the abstract interface. - */ - if (PyList_Check(seq)) { - for (i = 0; i < seqlen; i++) { - PyObject *item = PyList_GET_ITEM(seq, i); - if (!PyString_Check(item)){ - if (PyUnicode_Check(item)) { - Py_DECREF(res); - return PyUnicode_Join( - (PyObject *)self, - seq); - } - PyErr_Format(PyExc_TypeError, - "sequence item %i not a string", - i); - goto finally; - } - slen = PyString_GET_SIZE(item); - while (reslen + slen + seplen >= sz) { - if (_PyString_Resize(&res, sz*2)) - goto finally; - sz *= 2; - p = PyString_AsString(res) + reslen; - } - if (i > 0) { - memcpy(p, sep, seplen); - p += seplen; - reslen += seplen; + for (i = 0; i < seqlen; i++) { + item = PySequence_Fast_GET_ITEM(seq, i); + if (!PyString_Check(item)){ + if (PyUnicode_Check(item)) { + Py_DECREF(res); + Py_DECREF(item); + return PyUnicode_Join((PyObject *)self, + seq); } - memcpy(p, PyString_AS_STRING(item), slen); - p += slen; - reslen += slen; + PyErr_Format(PyExc_TypeError, + "sequence item %i: expected string, %.80s found", + i, item->ob_type->tp_name); + Py_DECREF(item); + Py_DECREF(seq); + goto finally; } - } - else { - for (i = 0; i < seqlen; i++) { - PyObject *item = PySequence_GetItem(seq, i); - if (!item) - goto finally; - if (!PyString_Check(item)){ - if (PyUnicode_Check(item)) { - Py_DECREF(res); - Py_DECREF(item); - return PyUnicode_Join( - (PyObject *)self, - seq); - } + slen = PyString_GET_SIZE(item); + while (reslen + slen + seplen >= sz) { + if (_PyString_Resize(&res, sz*2)) { Py_DECREF(item); - PyErr_Format(PyExc_TypeError, - "sequence item %i not a string", - i); + Py_DECREF(seq); goto finally; } - slen = PyString_GET_SIZE(item); - while (reslen + slen + seplen >= sz) { - if (_PyString_Resize(&res, sz*2)) { - Py_DECREF(item); - goto finally; - } - sz *= 2; - p = PyString_AsString(res) + reslen; - } - if (i > 0) { - memcpy(p, sep, seplen); - p += seplen; - reslen += seplen; - } - memcpy(p, PyString_AS_STRING(item), slen); - Py_DECREF(item); - p += slen; - reslen += slen; + sz *= 2; + p = PyString_AsString(res) + reslen; + } + if (i > 0) { + memcpy(p, sep, seplen); + p += seplen; + reslen += seplen; } + memcpy(p, PyString_AS_STRING(item), slen); + Py_DECREF(item); + p += slen; + reslen += slen; } if (_PyString_Resize(&res, reslen)) goto finally; From tim_one@email.msn.com Tue Jul 11 02:47:12 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 21:47:12 -0400 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <20000710191537.A5853@keymaster.enme.ucalgary.ca> Message-ID: [Peter Schneider-Kamp] > I wouldn't bet my life on it, but I don't think the GC code is > responsible. [Neil Schemenauer] > Its hard to say. I'll second that . > The GC code will probably pick up on a lot of problems because it touches > many objects. On the other hand, it could be my bug. I'm prettly > limited here as my computer is somewhere between Calgary and > Reston as I type this. I will try to find the problem though. I also doubt it's gc's fault: the recent patches to the gc code were absolutely vanilla, this all worked fine (at least for me) yesterday, and it's failing for multiple people on multiple platforms today. (BTW, Barry, your core.py does not fail under my Windows build.) I haven't had more time tonight to look at it, though, and won't tomorrow either. "Somehow or other" the list of objects it's crawling over is totally hosed (length 3, first one is a legit string object, last two seemingly random trash). If I remembered how to do this with CVS, I'd just do a mindless binary search over the last day's patches, rebuilding until the problem goes away ... OK, if back out *only* Jeremy's patch to stringobject.c: http://www.python.org/pipermail/python-checkins/2000-July/006424.html all my Windows gc failures go away. I picked on that patch because it's the only non-trivial patch that's gone in recently to a popular part of the code. Jeremy, want to double-check your refcounts ? suggestive-but-not-yet-proven-ly y'rs - tim From tim_one@email.msn.com Tue Jul 11 03:00:47 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 22:00:47 -0400 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <20000710191537.A5853@keymaster.enme.ucalgary.ca> Message-ID: [Peter Schneider-Kamp] > I wouldn't bet my life on it, but I don't think the GC code is > responsible. [Neil Schemenauer] > Its hard to say. I'll second that . > The GC code will probably pick up on a lot of problems because it touches > many objects. On the other hand, it could be my bug. I'm prettly > limited here as my computer is somewhere between Calgary and > Reston as I type this. I will try to find the problem though. I also doubt it's gc's fault: the recent patches to the gc code were absolutely vanilla, this all worked fine (at least for me) yesterday, and it's failing for multiple people on multiple platforms today. (BTW, Barry, your core.py does not fail under my Windows build.) I haven't had more time tonight to look at it, though, and won't tomorrow either. "Somehow or other" the list of objects it's crawling over is totally hosed (length 3, first one is a legit string object, last two seemingly random trash). If I remembered how to do this with CVS, I'd just do a mindless binary search over the last day's patches, rebuilding until the problem goes away ... OK, if I back out *only* Jeremy's very recent patch to stringobject.c: http://www.python.org/pipermail/python-checkins/2000-July/006424.html all my Windows gc failures go away. I picked on that patch because it's the only non-trivial patch that's gone in recently to a popular part of the code. Jeremy, want to double-check your refcounts ? suggestive-but-not-yet-proven-ly y'rs - tim From akuchlin@mems-exchange.org Tue Jul 11 03:34:04 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon, 10 Jul 2000 22:34:04 -0400 Subject: [Python-Dev] GC core dump caused by stringobject changes? In-Reply-To: <20000710192833.B5853@keymaster.enme.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Mon, Jul 10, 2000 at 07:28:33PM -0600 References: <20000710192833.B5853@keymaster.enme.ucalgary.ca> Message-ID: <20000710223404.A3195@newcnri.cnri.reston.va.us> On Mon, Jul 10, 2000 at 07:28:33PM -0600, Neil Schemenauer wrote: >These seem to be the changes that trigger the bug. My problem or >someone elses? No time to look in detail right now. :( >+ seq = PySequence_Fast(orig, ""); ... >+ item = PySequence_Fast_GET_ITEM(seq, i); ... >+ Py_DECREF(item); I think item shouldn't be DECREF'ed at all. Looking at what PySequence_Fast does, it either INCREF's its argument if it's a list or tuple and returns it, or coerces it to a tuple. It doesn't look like PySequence_Fast increments the refcount of what it returns. seq does need to be DECREF'ed, though: >>> import sys >>> L=['a', 'b', 'c'] >>> sys.getrefcount(L) 2 >>> for i in range(1000): a = ' '.join(L) ... >>> sys.getrefcount(L) 1002 >>> --amk From jeremy@beopen.com Tue Jul 11 04:19:32 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 23:19:32 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <20000710191537.A5853@keymaster.enme.ucalgary.ca> References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> Message-ID: <14698.37444.952060.876122@bitdiddle.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> On Tue, Jul 11, 2000 at 01:05:10AM +0000, Peter Schneider-Kamp NS> wrote: >> I wouldn't bet my life on it, but I don't think the GC code is >> responsible. NS> Its hard to say. The GC code will probably pick up on a lot of NS> problems because it touches many objects. On the other hand, it NS> could be my bug. My first guess would be something other than the GC. When I was working on the string_join fix this afternoon, a couple of my interim versions had refcount problems that lead to core dumps in the garbage collector. The GC catches lots of memory problems because it's touching all the objects; that doesn't mean its to blame for all those problems. Which leads me to ask, Barry, did you run purify on an interpreter with the latest stringobject.c? Jeremy From tim_one@email.msn.com Tue Jul 11 04:25:15 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 23:25:15 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <027801bfeab6$aa6115e0$f2a6b5d4@hagrid> Message-ID: [/F, on ViewCVS's virtues] > it works with MSIE5, for a start. > > and it's written by greg, in python. that's all I need to know ;-) > > the IE problem could be a configuration problem, of course. unless > tim beats me to it, I'll submit a support request some day... And I will unless you beat me to it . In the meantime, I downloaded stinking Netscape last night. Works fine. IE5 was having major problems displaying the SF Member Options page too (large table). And SF ftp access froze. And the new thing with displaying the CVS repository. They all work OK under NS. Surprised me, as my previous experiences with NS were a bloody nightmare of crashes and corruption! BTW, I'm certain I didn't do anything to change my IE5 config (& the SF CVS access worked fine on Friday). From jeremy@beopen.com Tue Jul 11 04:31:33 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 23:31:33 -0400 (EDT) Subject: [Python-Dev] GC core dump caused by stringobject changes? In-Reply-To: <20000710223404.A3195@newcnri.cnri.reston.va.us> References: <20000710192833.B5853@keymaster.enme.ucalgary.ca> <20000710223404.A3195@newcnri.cnri.reston.va.us> Message-ID: <14698.38165.629676.33065@bitdiddle.concentric.net> Right on both counts and now fixed! Jeremy From ping@lfw.org Mon Jul 10 10:23:55 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Mon, 10 Jul 2000 02:23:55 -0700 (PDT) Subject: [Python-Dev] String coercion In-Reply-To: <39672D53.899D4BEB@prescod.net> Message-ID: On Sat, 8 Jul 2000, Paul Prescod wrote: > Ping says: > > As it stands, with both 8-bit strings and Unicode strings, i think > > this would result in too much hidden complexity -- thinking about this > > can wait until we have only one string type. > > I don't see any hidden complexity. Python has features specifically > designed to allow this sort of thing on a per-type basis. Well... what happens when the other operand is a Unicode string? Do you also do automatic coercion when adding something to a Unicode string? When you add one to an arbitrary object, how do you convert the other object into a Unicode string? When you add an 8-bit string and Unicode together, what do you get? It's not that i don't think you might be able to come up with consistent rules. I just suspect that when you do, it might amount to more hidden stuff than i'm comfortable with. Of course you could also just use Itpl.py :) or a built-in version of same (Am i half-serious? Half-kidding? Well, let's just throw it out there...). Instead of: print PaulsString("abcdef")+5 print open+PaulsString("ghijkl") with Itpl.py it would just be: printpl("abcdef${5}") printpl("${open}ghijkl") A built-in Itpl-like operator might almost be justifiable, actually... i mean, we already have "%(open)sghijkl" % globals() Well, i don't know. Perhaps it looks too frighteningly like Perl. Anyway, the rules as implemented (see http://www.lfw.org/python/ for the actual Itpl.py module) are: 1. $$ becomes $ 2. ${ } around any expression evaluates the expression 3. $ followed by identifier, followed by zero or more of: a. .identifier b. [identifier] c. (identifier) evaluates the expression What i'm getting at with this approach is that you are clear from the start that the goal is a string: you have this string thing, and you're going to insert some stringified expressions and objects into it. I think it's clearer & less error-prone for interpolation to be its own operation, rather than overloading +. It also means you could start with a Unicode string with $s in it, and you would be assured of ending up with a Unicode string, for example. -- ?!ng From bwarsaw@beopen.com Tue Jul 11 05:07:54 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 00:07:54 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> <14698.37444.952060.876122@bitdiddle.concentric.net> Message-ID: <14698.40346.841864.110547@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> Which leads me to ask, Barry, did you run purify on an JH> interpreter with the latest stringobject.c? Yes. And I did get other memory errors before the core, which I should have looked at more carefully. Looks like that might have been it. My fault for encouraging you to check your changes in without looking at them, and then I had to disappear for a few hours. I've got them now and am looking at the code (I see a missing decref, but that should only leak memory). Will Purify shortly. -Barry From Moshe Zadka Tue Jul 11 05:36:11 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 11 Jul 2000 07:36:11 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101500.IAA13372@slayer.i.sourceforge.net> Message-ID: On Mon, 10 Jul 2000, Eric S. Raymond wrote: > Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv11503/dist/src/Lib > > Modified Files: > urllib.py > Log Message: > Moves some test code into the scope of if __name__ == '__main__', where it > won't get loaded when we're using the classes in this module. Why? It's only parsed once (under usual conditions) per installation, it's cost in memory is not so high, and it's cool to be able to test via ''' import urllib urllib.main() ''' -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From bwarsaw@beopen.com Tue Jul 11 05:56:54 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 00:56:54 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> <14698.37444.952060.876122@bitdiddle.concentric.net> Message-ID: <14698.43286.502470.136885@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: >>>>> "NS" == Neil Schemenauer writes: NS> Its hard to say. The GC code will probably pick up on a lot NS> of problems because it touches many objects. On the other NS> hand, it could be my bug. It also appears to mask many problems. I just compiled out the gcmodule (which is sadly undocumented, I believe) and I've just gotten a number of new memory leaks. This is basically running a very simple Python script: -------------------- snip snip -------------------- '-'.join(('one',)) '-'.join((u'one',)) -------------------- snip snip -------------------- Will investigate further, but at first blush, they might be real cycles created in the exception initialization code. But anyway... JH> Which leads me to ask, Barry, did you run purify on an JH> interpreter with the latest stringobject.c? ...I'd actually expect the above script to leak *seq twice in the current CVS string_join(). It doesn't, but then neither does including the missing decrefs cause the objects to be decref'd extra times. Interesting. Still I think string_join() needs to be patched in two places to decref *seq (first, in the seqlen==1 clause, and later just before the return PyUnicode_Join()). I'll check in a patch, but would appreciate a proofread. -Barry From fdrake@beopen.com Tue Jul 11 06:52:33 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 01:52:33 -0400 (EDT) Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: References: <027801bfeab6$aa6115e0$f2a6b5d4@hagrid> Message-ID: <14698.46625.240075.125009@cj42289-a.reston1.va.home.com> Tim Peters writes: > OK under NS. Surprised me, as my previous experiences with NS were a bloody > nightmare of crashes and corruption! BTW, I'm certain I didn't do anything > to change my IE5 config (& the SF CVS access worked fine on Friday). You have to realize that they probably test with Netscape, but rarely if ever with IE. That's a function of audience. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Moshe Zadka Tue Jul 11 06:55:13 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 11 Jul 2000 08:55:13 +0300 (IDT) Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162855.A9245@thyrsus.com> Message-ID: On Mon, 10 Jul 2000, Eric S. Raymond wrote: > First, for completeness there ought to be remove_section and remove_option > methods (though forgetool does not yet use them). I have documented these > as follows: > > \begin{methoddesc}{remove_option}{section, option} > Remove the specified \var{option} from the specified \var{section}. > If the section does not exist, raise \exception{NoSectionError}. > If the option existed to be removed, return 1; otherwise return 0. Ummm..encoding success/failure as return values is not usually a good idea. Why not raise KeyError if there is no such option in the section? > \begin{methoddesc}{remove_section}{section} > Remove the specified \var{section} from the configuration. > If the section in fact existed, return 1. Otherwise return 0. Ditto. Raise a NoSectionError. IF someone wants to ignore the error, they can either check if it exists, or trap the error. > Does anybody have a problem with these changes? I'm +0 -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From fdrake@beopen.com Tue Jul 11 06:58:02 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 01:58:02 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <14698.43286.502470.136885@anthem.concentric.net> References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> <14698.37444.952060.876122@bitdiddle.concentric.net> <14698.43286.502470.136885@anthem.concentric.net> Message-ID: <14698.46954.479303.841718@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > It also appears to mask many problems. I just compiled out the > gcmodule (which is sadly undocumented, I believe) and I've just gotten Neil, Can you provide something for this module? Plain text is fine if you prefer; I can add the LaTeX markup. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pf@artcom-gmbh.de Tue Jul 11 08:12:29 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Tue, 11 Jul 2000 09:12:29 +0200 (MEST) Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162855.A9245@thyrsus.com> from "Eric S. Raymond" at "Jul 10, 2000 4:28:55 pm" Message-ID: Hi, Eric S. Raymond: > Earlier today, I committed a patch to ConfigParser that adds three new > methods to the class. Here is the documentation: [...] Applying the well known dictionary API to config info can help to to avoid reinventing a new API to deal with configuration info. What I would love to see, is a class 'ConfigDict' derived from 'UserDict.UserDict', which contains the section-names as keys and section-objects as values, where section-objects are also dictionaries containing the option-names as keys. The new class 'ConfigDict' should then provide a 'read()' or 'parse()' method (or take an optional filename as constructor argument) and would also provide 'write' and/or 'save' method(s). Hypothecical examples of use: rcfilename = os.path.join(os.environ.get("HOME", "."), ".myFoorc") cnf = ConfigParser.ConfigDict(rcfilename) # or alternatively: cnf = ConfigParser.ConfigDict() cnf.read(open(rcfilename, "r")) # ... accessing the configuration if cnf.has_key("FONT_SETTINGS"): try: size = int(cnf["FONT_SETTINGS"]["size"]) except KeyError: size = 10 # ... adding a section: cnf["new_section"] = {} # ... adding an option to the default section: cnf["screensize"] = "%dx%d" % (width, height) # ... cnf["FONT_SETTINGS"]["size"] = 10 # removing an option: del cnf["FONT_SETTINGS"]["fontname"] # removing a section or an option from the default section: del cnf["old_section"] del cnf["foo_bar"] # ... cnf.save() # only if instantiated using a filename argument # or alternatively: cnf.write(open(".myrc", "w")) [...] > To do these things, forgetool needs to maintain some local state that is > conveniently represented in the format of a Windows .ini file. More, > it needs to be able to *update* .ini files as well as parse them. This is a very common need. I agree, that this functionality should be provided by the standard library. Recently we had some discussion about a 'userpref' module, which should fill another related gap: provide a portable way to determine the rcfilename. a dot-rc file is the unix way to store this kind of information, on Windows a application specific ini file probaly belongs into another local directory (there is no $HOME) and on the Mac it probably belongs into a preferences folder ... still a lot of work to do. :-( Regards, Peter From gstein@lyra.org Tue Jul 11 10:08:18 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 02:08:18 -0700 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 11, 2000 at 08:55:13AM +0300 References: <20000710162855.A9245@thyrsus.com> Message-ID: <20000711020817.V29590@lyra.org> On Tue, Jul 11, 2000 at 08:55:13AM +0300, Moshe Zadka wrote: > On Mon, 10 Jul 2000, Eric S. Raymond wrote: > > First, for completeness there ought to be remove_section and remove_option > > methods (though forgetool does not yet use them). I have documented these > > as follows: > > > > \begin{methoddesc}{remove_option}{section, option} > > Remove the specified \var{option} from the specified \var{section}. > > If the section does not exist, raise \exception{NoSectionError}. > > If the option existed to be removed, return 1; otherwise return 0. > > Ummm..encoding success/failure as return values is not usually a good > idea. Why not raise KeyError if there is no such option in the section? Eric is defining it as "okay" to remove a non-existent option. If you want to know whether it was there, then check the return code. In most cases, you just want to say "just make sure it isn't there any more." IOW, I much prefer Eric's behavior spec over something that will generate an exception. > > \begin{methoddesc}{remove_section}{section} > > Remove the specified \var{section} from the configuration. > > If the section in fact existed, return 1. Otherwise return 0. > > Ditto. Raise a NoSectionError. IF someone wants to ignore the error, they > can either check if it exists, or trap the error. Same as above. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Tue Jul 11 10:10:09 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 02:10:09 -0700 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: ; from pf@artcom-gmbh.de on Tue, Jul 11, 2000 at 09:12:29AM +0200 References: <20000710162855.A9245@thyrsus.com> Message-ID: <20000711021008.W29590@lyra.org> On Tue, Jul 11, 2000 at 09:12:29AM +0200, Peter Funk wrote: > Hi, > > Eric S. Raymond: > > Earlier today, I committed a patch to ConfigParser that adds three new > > methods to the class. Here is the documentation: > [...] > Applying the well known dictionary API to config info can help to > to avoid reinventing a new API to deal with configuration info. > > What I would love to see, is a class 'ConfigDict' derived from > 'UserDict.UserDict', which contains the section-names as keys and > section-objects as values, where section-objects are also dictionaries > containing the option-names as keys. Then go ahead and code it. I guarantee that you'll have your wish if you code it. Otherwise, I'll lay very low odds on all the new module suggestions in your email. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov@inrialpes.fr Tue Jul 11 10:32:44 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Tue, 11 Jul 2000 11:32:44 +0200 (CEST) Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length In-Reply-To: <025001bfeab4$f07251e0$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 10, 2000 11:22:22 PM Message-ID: <200007110932.LAA14002@python.inrialpes.fr> Fredrik Lundh wrote: > > jeremy wrote: > > > Tuple, List, String, and Dict have a PyXXX_Size method. The abstract > > object interface uses PySequence_Length. This is inconsistent and > > hard to remember. Can we add PySequence_Size and mark Length as > > deprecated? > > don't forget PyObject_Length and PyMapping_Length... Why deprecate? There's nothing wrong with these names. However, for conveniency, it would make sense to have PyXXX_Size macros, synonyms for the PyXXX_Length functions. Or vice versa. Have _Length macros, synonyms for _Size functions. However, this is not backwards (binary) compatible, which I believe is harmless for a new release, but the recent Windows DLL thread reminds that bin compatibility accross versions is somewhat important. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein@lyra.org Tue Jul 11 11:10:36 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 03:10:36 -0700 Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length In-Reply-To: <200007110932.LAA14002@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Tue, Jul 11, 2000 at 11:32:44AM +0200 References: <025001bfeab4$f07251e0$f2a6b5d4@hagrid> <200007110932.LAA14002@python.inrialpes.fr> Message-ID: <20000711031036.E29590@lyra.org> On Tue, Jul 11, 2000 at 11:32:44AM +0200, Vladimir Marangozov wrote: > Fredrik Lundh wrote: > > > > jeremy wrote: > > > > > Tuple, List, String, and Dict have a PyXXX_Size method. The abstract > > > object interface uses PySequence_Length. This is inconsistent and > > > hard to remember. Can we add PySequence_Size and mark Length as > > > deprecated? > > > > don't forget PyObject_Length and PyMapping_Length... > > Why deprecate? There's nothing wrong with these names. > However, for conveniency, it would make sense to have > PyXXX_Size macros, synonyms for the PyXXX_Length functions. Because having both names is even worse than having inconsistent names. The question will always arise "what is the difference? why should I use one over the other?" You can tell people they are the same until you're blue in the face -- the question will still come up. Maybe after a while, the question won't come up any more. But then you have to answer, "okay. so they're exactly the same. why have two of them, then?" :-) > Or vice versa. Have _Length macros, synonyms for _Size functions. > However, this is not backwards (binary) compatible, which I > believe is harmless for a new release, but the recent Windows > DLL thread reminds that bin compatibility accross versions > is somewhat important. Binary compatibility in Open Source software is a pipe dream. There is absolutely no sense in trying to worry about it, and even more sense to explicitly bail out with "that doesn't work." Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Tue Jul 11 11:35:34 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 03:35:34 -0700 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: ; from pf@artcom-gmbh.de on Tue, Jul 11, 2000 at 12:10:41PM +0200 References: <20000711021008.W29590@lyra.org> Message-ID: <20000711033534.K29590@lyra.org> On Tue, Jul 11, 2000 at 12:10:41PM +0200, Peter Funk wrote: > Greg Stein : > > On Tue, Jul 11, 2000 at 09:12:29AM +0200, Peter Funk wrote: > > > Hi, > > > > > > Eric S. Raymond: > > > > Earlier today, I committed a patch to ConfigParser that adds three new > > > > methods to the class. Here is the documentation: > > > [...] > > > Applying the well known dictionary API to config info can help to > > > to avoid reinventing a new API to deal with configuration info. > > > > > > What I would love to see, is a class 'ConfigDict' derived from > > > 'UserDict.UserDict', which contains the section-names as keys and > > > section-objects as values, where section-objects are also dictionaries > > > containing the option-names as keys. > > > > Then go ahead and code it. I guarantee that you'll have your wish if you > > code it. Otherwise, I'll lay very low odds on all the new module suggestions > > in your email. > > Okay: I just had a look into the implementation of ConfigParser and > stumbled over the '%(foo)' macro expansion features. If I go ahead and > implement these within (below) my ConfigDict.__getitem__ method, this > will lead to the problem, that > cnf['some_section']['foo'] = 'feeble' > cnf['some_section']['bar'] = 'baz' > cnf['some_section']['some_option'] = '%(foo)/paf/%(bar)' > print cnf['some_section']['some_option'] > might surprise users with the dictionary model in their head. > They might expect this to print '%(foo)/paf/%(bar)' instead of > 'feeble/paf/baz'. > > Any suggestions? It is a configuration dictionary. Users can simply deal with it :-) I'm not sure it is a big problem to worry about. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov@inrialpes.fr Tue Jul 11 13:41:18 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Tue, 11 Jul 2000 14:41:18 +0200 (CEST) Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length In-Reply-To: <20000711031036.E29590@lyra.org> from "Greg Stein" at Jul 11, 2000 03:10:36 AM Message-ID: <200007111241.OAA21491@python.inrialpes.fr> Greg Stein wrote: > > > Why deprecate? There's nothing wrong with these names. > > However, for conveniency, it would make sense to have > > PyXXX_Size macros, synonyms for the PyXXX_Length functions. > > Because having both names is even worse than having inconsistent names. The > question will always arise "what is the difference? why should I use one > over the other?" You can tell people they are the same until you're blue in > the face -- the question will still come up. Maybe after a while, the > question won't come up any more. But then you have to answer, "okay. so > they're exactly the same. why have two of them, then?" :-) Okay, then deprecate them if there are no other objections. But binary compatibility aside, if we don't provide _Length macros, this would break tons of legacy source code, so both must be there for some (long) time. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gward@mems-exchange.org Tue Jul 11 13:39:44 2000 From: gward@mems-exchange.org (Greg Ward) Date: Tue, 11 Jul 2000 08:39:44 -0400 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <200007101725.MAA01255@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 12:25:12PM -0500 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> Message-ID: <20000711083943.A27423@ludwig.cnri.reston.va.us> On 10 July 2000, Guido van Rossum said: > Makefile includes are notoriously unportable, aren't they? The > embed/Makefile is a lame excuse for a Makefile -- it has XXX comments > all over the place telling you to edit things to match the Python main > Makefile... :-( My fault -- feel free to fix! I think the mere existence of an "include" directive is pretty well-established. What's not portable, in my experience, is relying in neat-o semantics supplied by GNU make and (maybe? can't remember) SGI's decent make (smake I think? plain make under IRIX 4 and 5 was hopelessly brain-damaged). Specifically, GNU make will treat a missing include file not as an error, but something that should be rebuilt using the usual dependency rules. Apparently this is useful for including header dependency info in the Makefile, but of course it ties you right to GNU make. If you believe the "Recursive Make Considered Harmful" paper, it's probably better to rely on the ability to include Makefile fragments than to invoke make recursively. (It sound plausible to me, but I haven't tried out the ideas from that paper seriously yet.) Greg From guido@beopen.com Tue Jul 11 14:48:15 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 08:48:15 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 14:16:38 MST." <20000710141638.R29590@lyra.org> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> <20000710141638.R29590@lyra.org> Message-ID: <200007111348.IAA04699@cj20424-a.reston1.va.home.com> > We're using includes in the Apache 2.0 makefiles. I'm not sure whether this > is going to make Apache 2.0 less portable or not. There haven't been any > issues yet, though. > > (I think the makefile organization came from PHP; assuming that is as > portable as Apache 1.3, then makefile includes are pretty darn portable) > > IMO, I say "start using makefile includes" and see who screams. VPATH is not > portable, though. The difference is that Apache and PHP only need to be portable to server-class machines. Python also runs on (1) very ancient hardware; (2) some Cray-class machines; (3) non-Unix hardware with enough Unix emulation to be able to run the configure script (I believe the BeOS port falls in this category, and of course cygwin). Call me conservative, --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy@beopen.com Tue Jul 11 13:59:44 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 08:59:44 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <14698.40346.841864.110547@anthem.concentric.net> References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> <14698.37444.952060.876122@bitdiddle.concentric.net> <14698.40346.841864.110547@anthem.concentric.net> Message-ID: <14699.6720.758571.615919@bitdiddle.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "JH" == Jeremy Hylton writes: JH> Which leads me to ask, Barry, did you run purify on an BAW> Looks like that might have been it. My fault for encouraging BAW> you to check your changes in without looking at them, and then BAW> I had to disappear for a few hours. I was in a rush, too. I should have waited until after my softball game. Jeremy From esr@thyrsus.com Tue Jul 11 14:08:17 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 11 Jul 2000 09:08:17 -0400 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <200007111348.IAA04699@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 08:48:15AM -0500 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> <20000710141638.R29590@lyra.org> <200007111348.IAA04699@cj20424-a.reston1.va.home.com> Message-ID: <20000711090817.A11533@thyrsus.com> Guido van Rossum : > > IMO, I say "start using makefile includes" and see who screams. VPATH is > > not portable, though. > > [No,] Call me conservative, I'm -1 on this also. I've had too many bad experiences dealing with variance in the semantics of inclusion. -- Eric S. Raymond What is a magician but a practicing theorist? -- Obi-Wan Kenobi, 'Return of the Jedi' From thomas@xs4all.net Tue Jul 11 14:17:41 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 15:17:41 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <200007111348.IAA04699@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 08:48:15AM -0500 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> <20000710141638.R29590@lyra.org> <200007111348.IAA04699@cj20424-a.reston1.va.home.com> Message-ID: <20000711151740.T26534@xs4all.nl> On Tue, Jul 11, 2000 at 08:48:15AM -0500, Guido van Rossum wrote: > > IMO, I say "start using makefile includes" and see who screams. VPATH is not > > portable, though. > The difference is that Apache and PHP only need to be portable to > server-class machines. Python also runs on (1) very ancient hardware; > (2) some Cray-class machines; (3) non-Unix hardware with enough Unix > emulation to be able to run the configure script (I believe the BeOS > port falls in this category, and of course cygwin). Actually, I was referring to the trick PIL and other extension modules use to build their own Makefile based on Python's. I'm not sure how portable that particular Makefile is, however. I'm one of those types that use 'gmake' on systems that do not have GNU make as the default make ;-) And forgive me for saying this, but I think providing a good, self-configuring but slightly unportable Makefile.pre.in *and* a README (and/or example) that shows how to do it by hand on old/incapacitated systems, is preferable over just providing a completely unportable Makefile and a README that shows how to do it on other systems :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@beopen.com Tue Jul 11 15:40:32 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 09:40:32 -0500 Subject: [Python-Dev] list comprehensions again... In-Reply-To: Your message of "Tue, 11 Jul 2000 12:31:55 +1200." <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> Message-ID: <200007111440.JAA05205@cj20424-a.reston1.va.home.com> > [x,y for x in (1,2,3) for y in (4,5,6)] Hm, I suppose the programmer meant the same as [(x,y) for x in (1,2,3) for y in (4,5,6)] Would it be really bad if we forced them to write it that way? Side note: the suggested syntax here (for i in seq1 for j in seq2) looks like a potential alternative for the currently proposed parallel for loop syntax (for i in seq1; j in seq2). Only problem: the for-for variant could be mistaken by someone used to see nested loops as meaning the same as for i in seq1: for j in seq2: ... Undecided and unhelpful, --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From akuchlin@mems-exchange.org Tue Jul 11 14:54:43 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 11 Jul 2000 09:54:43 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: ; from pingster@ilm.com on Thu, Jul 06, 2000 at 02:16:07PM -0700 References: <20000706171159.A25398@kronos.cnri.reston.va.us> Message-ID: <20000711095443.D27228@kronos.cnri.reston.va.us> On Thu, Jul 06, 2000 at 02:16:07PM -0700, Ka-Ping Yee quoted me: >> I'd suggest adding poll() to 2.0, and will submit a patch if given the >> go-ahead. But where should it go? A whole module for it seems >> excessive; should it go in posixmodule, or maybe select? I've completed a patch, SF#100852, to add os.poll() based on Sam Rushing's code with various modifications; I'd like a reviewer to look it over, after which I'll check it in. http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 I'm not happy with the interface -- you pass in a list of (file descriptor, event mask) 2-tuples -- but it seems the only way to expose all of poll()'s functionality. I thought about allowing a lone file descriptor as well as a tuple, in which you'd assume an event mask of POLLIN | POLLPRI | POLLOUT (all the common events), but it seemed like too much magic. Also, is there a C utility function to handle the "pass an integer or an object with a fileno() method" protocol for me? Should there be one? --amk From guido@beopen.com Tue Jul 11 15:58:46 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 09:58:46 -0500 Subject: [Python-Dev] Re: SourceForge In-Reply-To: Your message of "Mon, 10 Jul 2000 21:10:00 -0400." <20000710211000.A10068@thyrsus.com> References: <20000707133533.E17746@valinux.com> <20000707182448.A31259@thyrsus.com> <39667D29.1A4FB1BB@valinux.com> <20000709214138.I4566@thyrsus.com> <396A4CFC.CEE2419A@valinux.com> <20000710203719.B9793@thyrsus.com> <396A6F7D.66D5F085@valinux.com> <20000710211000.A10068@thyrsus.com> Message-ID: <200007111458.JAA05267@cj20424-a.reston1.va.home.com> > Dan Bressler : > > I'm trying to sync schedules -- If we could set it for Tuesday evening, July > > 18th, that would work best. > > OK. Python folks who will be at the Monterey conference; Dan > Bressler, one of the managers of SourceForge, is amenable to an > evening meeting with this gang on Tuesday the 18th. I gather Tim > Purdue, currently the lead programmer on the project, will be there. > > The exact time is still to be worked out. Anybody got a proposal? I'm not sure what time we'll be arriving in Monterey -- we have our plane tickets to San Jose and I know we're going to spend Tuesday daytime at the BeOpen headquarters in Santa Clara, but I don't know yet what mode of transportation we're going to take to Monterey and at what time. Given that Dan prefers Tuesday evening I'll try to press for leaving early enough so that there's some evening left! Looking forward to this meeting, --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas@xs4all.net Tue Jul 11 15:04:06 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 16:04:06 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111440.JAA05205@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 09:40:32AM -0500 References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> <200007111440.JAA05205@cj20424-a.reston1.va.home.com> Message-ID: <20000711160406.D25805@xs4all.nl> On Tue, Jul 11, 2000 at 09:40:32AM -0500, Guido van Rossum wrote: > > [x,y for x in (1,2,3) for y in (4,5,6)] > Hm, I suppose the programmer meant the same as > > [(x,y) for x in (1,2,3) for y in (4,5,6)] > Would it be really bad if we forced them to write it that way? Actually, the change in Grammar wouldn't enforce that. (At least, I think not.) Because the 'for' splits and disambiguates before the ',' in the first tuple, the parser will always see it as such, and it's probably pretty hard to convince the parser not to :-) Because of the way 'testlist' and 'test' are defined, it's easy to use them interchangeably. I think, anyway. I'm still new at this parsing thing :-) But the Gramar uses 'testlist' to mean the contents of the list itself, so it seems logical to me that this should be the case wether or not 'testlist' is followed by 'list_iter' -- currently, the presense of list_iter changes (the interpretation of) it from the contents of a list to a tuple. Like I said, it was nit-picky ;) > Side note: the suggested syntax here (for i in seq1 for j in seq2) > looks like a potential alternative for the currently proposed parallel > for loop syntax (for i in seq1; j in seq2). > Only problem: the for-for variant could be mistaken by someone used to > see nested loops as meaning the same as > > for i in seq1: > for j in seq2: ... I personally prefer 'for i in seq1; j in seq2' because it's a lot less ambiguous. More importantly, however, the meaning in the cited list-comprehension example is different ! [x,y for x in (1,2,3) for y in (4,5,6)] is actually turned into a pair of nested loops: tmp = [] for x in (1,2,3): for y in (4,5,6): tmp.append(x,y) (Quite literally so, in fact ;) So it's *not* the same as the parallel-loop-for: tmp = [] for x in (1,2,3); y in (4,5,6): tmp.append(x,y) For that reason alone, I'd go for the 2nd syntax ;) Unless, of course, you have a proposed new syntax for the nested-for-loop in list comprehensions :-) > Undecided and unhelpful, Helpfully deciding-ly'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From peter@schneider-kamp.de Tue Jul 11 17:16:16 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 11 Jul 2000 16:16:16 +0000 Subject: merging my*.h into pyport.h (was: Re: [Python-Dev] Py_PROTO elimination in Include/) References: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com> Message-ID: <396B4850.A3D1A1A2@stud.ntnu.no> "Fred L. Drake, Jr." wrote: > > I've removed Py_PROTO from the headers in the Include/ directory, > with the exceptions of the my*.h headers. I'll leave it for others to > fix those, merging with pyport.h as appropriate. What do you think would be appropriate? I have been toying around with the my*.h headers a bit and loaded up a "proof of concept" patch that makes all my*.h obsolete. concerns with the patch: - messing around with a lot if non-linux #ifdef sections (can somebody have a look at that?) - possibly including unneeded headers (is that a problem?) - undocumented (I can take care of that when the time comes) hoping-for-feedback-ly y'rs Peter P.S.: What's the status of sre? I just ask because test_re keeps nagging all the time. :-] -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From peter@schneider-kamp.de Tue Jul 11 17:19:40 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 11 Jul 2000 16:19:40 +0000 Subject: merging my*.h into pyport.h (was: Re: [Python-Dev] Py_PROTO elimination in Include/) References: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com> <396B4850.A3D1A1A2@stud.ntnu.no> Message-ID: <396B491C.C3ABFFE2@stud.ntnu.no> Peter Schneider-Kamp wrote: > > - messing around with a lot if non-linux #ifdef sections make that: a lot of non-linux #ifdef sections sorry, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From guido@beopen.com Tue Jul 11 16:23:45 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 10:23:45 -0500 Subject: [Python-Dev] Python License may be discussed at Python Consortium Meeting Message-ID: <200007111523.KAA05408@cj20424-a.reston1.va.home.com> While there still isn't much to report regarding the negotiations between BeOpen and CNRI about Python releases and licenses, I thought I should point out that there is some progress. BeOpen is taking a stance that all Python users should appreciate -- I'd summarize it as "keep the old Python license or bust". CNRI is trying to argue for a new license that is identical to the JPython license (http://www.jpython.org/jplicense.html) with removal of paragraph 3 (requirement to prominent display changes w.r.t. CNRI's version) and paragraph 4 (trademark restrictions). In our views, this license is unusable for several reasons -- it's not GPL-compatible, it's not Open Source compliant, and on previous occasions members of the Python community have reacted strongly against it. I promise that BeOpen won't accept CNRI's current proposal. It's impossible to say whether CNRI will accept BeOpen's position; as a precaution, assuming the issue is still open next week, we've added discussion of the license to the agenda of the Python Consortium meeting in Monterey (see below). I can't say what will happen if the negotiations break off -- but I hope that the discussion at the meeting will open CNRI's eyes. I hope that employees of consortium member companies will do everything they can to ensure that their company is represented at the meeting for this important discussion! Feel free to write me for more background information. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------- Forwarded Message Date: Mon, 10 Jul 2000 15:09:29 -0400 From: Albert Vezza To: consortium-members@python.org cc: rkahn@cnri.reston.va.us, Barbara Fuller Subject: [Py-Consortium] Python Consortium Meeting Python Consortium Members, There will be an important Python Consortium meeting on the July 21st following the O'Reilly Open Source Conference in Monterey, California. The meeting will be held at the Marriott which is adjacent to the Monterey Convention center. This is a discussion meeting and all items on the agenda will be fully explored along with any other important items that are brought to the table. If any member has an important issue they would like to see explored please let me know. Please RSVP to bfuller@foretec.com with the name of the attendees. Best regards, Al ---------------------------------------------------------- Proposed Agenda 8:00 Continental Breakfast 9:00 Python Consortium and Its Continuing Role 10:00 Transition of the Python Development Activity 12:00 Lunch 1:00 Management of the Python.Org Site 3:00 The future Python license 4:00 The desired development path for Python 2.0 5:00 Adjourn Albert Vezza Vice President Corporation for National Research Initiatives 1895 Preston White Drive Suite 100 Reston, VA 20191-5434 Internet mail: avezza@cnri.reston.va.us Tel: (703) 620-8990 Fax: (703) 620-0913 Natick, MA Office Tel: (508) 650 4020 Fax: (508) 650 4639 ------- End of Forwarded Message From gvwilson@nevex.com Tue Jul 11 15:42:55 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 10:42:55 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111440.JAA05205@cj20424-a.reston1.va.home.com> Message-ID: > > [x,y for x in (1,2,3) for y in (4,5,6)] > Hm, I suppose the programmer meant the same as > [(x,y) for x in (1,2,3) for y in (4,5,6)] > Would it be really bad if we forced them to write it that way? Strongly prefer the latter, as it permits: [[x,y] for x in (1,2,3) for y in (4,5,6)] (either now or in future). Would it also permit: [{x:y} for x in (1,2,3) for y in (4,5,6)] i.e. dict construction using list comprehension? I'd use this in quite a few places. > Side note: the suggested syntax here (for i in seq1 for j in seq2) > looks like a potential alternative for the currently proposed parallel > for loop syntax (for i in seq1; j in seq2). > > Only problem: the for-for variant could be mistaken by someone used to > see nested loops as meaning the same as > > for i in seq1: > for j in seq2: ... Until yesterday's posting, I assumed that this is what for-for loops would do, i.e. that they'd deliver a cross-product rather than one-from-each. Was going to ask whether: for i in seq1 and j in seq2: foo would be clearer, but then realized that people might assume it implied that: for i in seq1 or j in seq2: foo would also work, meaning either "while either list is non-empty" or "cross-product". Random thoughts, Greg From guido@beopen.com Tue Jul 11 16:57:10 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 10:57:10 -0500 Subject: [Python-Dev] Bug fixing policy (was Re: Changes to ConfigParser) In-Reply-To: Your message of "Mon, 10 Jul 2000 15:33:14 MST." <20000710153314.W29590@lyra.org> References: <20000710162855.A9245@thyrsus.com> <20000710153314.W29590@lyra.org> Message-ID: <200007111557.KAA05666@cj20424-a.reston1.va.home.com> Greg Stein writes: > > > API changes probably ought to be discussed on this list (which includes the > maintainers of any code). Basic point: the "maintainer(s)" is usually quite > unclear since we avoid attribution within the source if at all possible. > Posing the suggested change here allows for changing maintainers (note that > Fred has done a tone of work on ConfigParser, and I've submitted a few > changes myself, too!), and it allows for broader input. > > However, bug fixes and minor reworking should probably be allowed regardless > of the maintainer. I'd hate to end up at a point where the Python > interpreter is partitioned into a bunch of little fiefdoms, where you must > pay a toll to enter. > > Excellent summary. I would add that if a maintainer is actively maintaining their code, it's not polite to check in changes to their code. It's better to give them a chance to fix it first. (The maintainer them should attribute the fix to whoever first mailed it to them, if they use the fix.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Tue Jul 11 17:09:16 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 11:09:16 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Tue, 11 Jul 2000 09:54:43 -0400." <20000711095443.D27228@kronos.cnri.reston.va.us> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> Message-ID: <200007111609.LAA05816@cj20424-a.reston1.va.home.com> > >> I'd suggest adding poll() to 2.0, and will submit a patch if given the > >> go-ahead. But where should it go? A whole module for it seems > >> excessive; should it go in posixmodule, or maybe select? > > I've completed a patch, SF#100852, to add os.poll() based on Sam > Rushing's code with various modifications; I'd like a reviewer to look > it over, after which I'll check it in. > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 > > I'm not happy with the interface -- you pass in a list of (file > descriptor, event mask) 2-tuples -- but it seems the only way to > expose all of poll()'s functionality. I thought about allowing a lone > file descriptor as well as a tuple, in which you'd assume an event > mask of POLLIN | POLLPRI | POLLOUT (all the common events), but it > seemed like too much magic. I haven't read the patch in detail, but this approach seems reasonable. Somehow I don't understand why we need poll() when we have select(), however. Select() is portable, poll() is Unix specific, but it seems to provide the same functionality. What am I missing? > Also, is there a C utility function to handle the "pass an integer or > an object with a fileno() method" protocol for me? Should there be > one? This is a nice refactoring opportunity. The code probably exists in many places, e.g. selectmodule.c. It should be a function in fileobject.c, I suppose. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fredrik@pythonware.com Tue Jul 11 16:15:06 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 11 Jul 2000 17:15:06 +0200 Subject: [Python-Dev] Adding poll() system call References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> Message-ID: <000701bfeb4a$cbf101e0$0900a8c0@SPIFF> guido wrote: > Somehow I don't understand why we need poll() when we have select(), > however. Select() is portable, poll() is Unix specific, but it seems > to provide the same functionality. What am I missing? quoting from http://www.nightmare.com/medusa/ A major design problem with select(2) is that an fd_set is usually of a fixed maximum size, on many operating systems the kernel needs to rebuilt to raise this limit; even on those that have dynamically adjustable limits, you still need to re- compile your application (because FD_SETSIZE is a macro). From skip@mojam.com (Skip Montanaro) Tue Jul 11 03:48:42 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Mon, 10 Jul 2000 21:48:42 -0500 (CDT) Subject: [Python-Dev] More Symantec symbols Message-ID: <14698.35594.999203.707698@beluga.mojam.com> Picking up where the __SC__ thread left off, I noticed the following other Symantec symbols in the Python sources just now: ./Include/Python.h:48:#ifdef SYMANTEC__CFM68K__ ./Include/Python.h:65:#ifdef SYMANTEC__CFM68K__ ./Include/mymalloc.h:47:#ifdef SYMANTEC__CFM68K__ ./Include/mymath.h:8:#ifdef SYMANTEC__CFM68K__ ./Include/mymath.h:27:#ifdef SYMANTEC__CFM68K__ ./Python/dynload_mac.c:18:#ifdef SYMANTEC__CFM68K__ /* Really an older version of Universal Headers */ ./Python/errors.c:15:#ifdef SYMANTEC__CFM68K__ Should these be zapped as well or is this something wholely unrelated to the old Symantec compiler issue? Skip From akuchlin@mems-exchange.org Tue Jul 11 16:28:47 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 11 Jul 2000 11:28:47 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007111609.LAA05816@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 11:09:16AM -0500 References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> Message-ID: <20000711112847.G27228@kronos.cnri.reston.va.us> On Tue, Jul 11, 2000 at 11:09:16AM -0500, Guido van Rossum wrote: >Somehow I don't understand why we need poll() when we have select(), >however. Select() is portable, poll() is Unix specific, but it seems >to provide the same functionality. What am I missing? In addition to /F's quote, poll() also scales better since it only lists the file descriptors of interest, while select() builds a bitmap, turns on bits for the fds of interest, and then afterward you have to scan the whole bitmap again. It's O(maximum fd), while poll is O(# of fds), making it more useful for writing more scalable network servers that service thousands of clients at the same time. (At the very highest end, even poll() begins to scale badly since you list "all the open fds", not "all the open fds which have activity". At that point you're supposed to switch to async I/O, but probably you'd have switched from Python to C long before that point.) >This is a nice refactoring opportunity. The code probably exists in >many places, e.g. selectmodule.c. It should be a function in >fileobject.c, I suppose. OK; I'll write up a separate patch to do this and submit it first. (Looks like only select, _tkinter, and poll need this functionality.) --amk From skip@mojam.com (Skip Montanaro) Tue Jul 11 15:05:03 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 11 Jul 2000 09:05:03 -0500 (CDT) Subject: [Python-Dev] once enabled gc won't go away until explicitly disabled? Message-ID: <14699.10639.15423.982767@beluga.mojam.com> I had been running with --with-cycle-gc, then the mystery bug hit yesterday, so last night I was working on other stuff and wanted to disable it. I tried removing config.cache and then executing configure as ./configure --with-threads but gc was still there. Then I explicitly commented out the gc line in Modules/Setup.config. Still no luck. Finally, I configured as ./configure --with-threads --without-cycle-gc and then it went away. Is this the correct behavior? Skip From bwarsaw@beopen.com Tue Jul 11 16:38:55 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 11:38:55 -0400 (EDT) Subject: [Python-Dev] once enabled gc won't go away until explicitly disabled? References: <14699.10639.15423.982767@beluga.mojam.com> Message-ID: <14699.16271.147279.134444@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> I had been running with --with-cycle-gc, then the mystery bug SM> hit yesterday, so last night I was working on other stuff and SM> wanted to disable it. I tried removing config.cache and then SM> executing configure as SM> ./configure --with-threads SM> but gc was still there. Then I explicitly commented out the SM> gc line in Modules/Setup.config. Still no luck. Finally, I SM> configured as SM> ./configure --with-threads --without-cycle-gc SM> and then it went away. SM> Is this the correct behavior? Yes, although both gc and threads are enabled by default in the current betas (so you don't need --with-threads). Whether they'll be enabled for the final release is still TBD. -Barry From guido@beopen.com Tue Jul 11 17:48:47 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 11:48:47 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Tue, 11 Jul 2000 17:15:06 +0200." <000701bfeb4a$cbf101e0$0900a8c0@SPIFF> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <000701bfeb4a$cbf101e0$0900a8c0@SPIFF> Message-ID: <200007111648.LAA06034@cj20424-a.reston1.va.home.com> > guido wrote: > > Somehow I don't understand why we need poll() when we have select(), > > however. Select() is portable, poll() is Unix specific, but it seems > > to provide the same functionality. What am I missing? > > quoting from http://www.nightmare.com/medusa/ > > A major design problem with select(2) is that an fd_set is > usually of a fixed maximum size, on many operating systems > the kernel needs to rebuilt to raise this limit; even on those > that have dynamically adjustable limits, you still need to re- > compile your application (because FD_SETSIZE is a macro). OK. +1 from me. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy@beopen.com Tue Jul 11 16:52:05 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 11:52:05 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <20000711112847.G27228@kronos.cnri.reston.va.us> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> Message-ID: <14699.17061.139324.335138@bitdiddle.concentric.net> If we're adding poll to enhance scalability, I'd like to see a more efficient interface that generates the poll_fd* separately from calling poll. The interface would be something like this: obj = poll.new() # generate a new pollfd array obj.register(f1, POLLIN | POLLOUT) obj.register(f2, POLLOUT) obj.poll() obj.unregister(f2) obj.poll() I think this would be a lot more efficient when the files being polled don't change very often. Jeremy From thomas@xs4all.net Tue Jul 11 16:52:31 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 17:52:31 +0200 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <14699.17061.139324.335138@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 11, 2000 at 11:52:05AM -0400 References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> Message-ID: <20000711175231.V26534@xs4all.nl> On Tue, Jul 11, 2000 at 11:52:05AM -0400, Jeremy Hylton wrote: > The interface would be something like this: > obj = poll.new() # generate a new pollfd array I would suggest 'poll.Poller()' or some such, for similarity with pickle and such. 'new()' looks a bit C++ish to me ;) Definately +1 on the idea tho ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake@beopen.com Tue Jul 11 16:53:14 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 11:53:14 -0400 (EDT) Subject: [Python-Dev] SyntaxError patches Message-ID: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> Ping has a really nice patch to generate better error messages for SyntaxError on SourceForge (#100734). This provides better messages, but keeps all these errors as plain SyntaxError exceptions. At one point, we were discussing having specializations of SyntaxError, and I posted a patch that defined IndentationError and TabError. With Ping's changes, using these instead of plain SyntaxError is trivial. Should I include that, or only change the error messages using Ping's patch? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Tue Jul 11 16:56:42 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 11:56:42 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <20000711175231.V26534@xs4all.nl> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> <20000711175231.V26534@xs4all.nl> Message-ID: <14699.17338.219363.10153@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > I would suggest 'poll.Poller()' or some such, for similarity with pickle and > such. 'new()' looks a bit C++ish to me ;) Definately +1 on the idea tho ;) Both have precedents in the standard library; the MD5 and SHA hash modules both provide a new() function to create the objects. It's not clear that the class-like name is terribly appropriate since a C type could not be subclassed. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip@mojam.com (Skip Montanaro) Tue Jul 11 15:35:53 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 11 Jul 2000 09:35:53 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111440.JAA05205@cj20424-a.reston1.va.home.com> References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> <200007111440.JAA05205@cj20424-a.reston1.va.home.com> Message-ID: <14699.12489.875905.520781@beluga.mojam.com> Guido> [(x,y) for x in (1,2,3) for y in (4,5,6)] Guido> Would it be really bad if we forced them to write it that way? For that matter, perhaps requiring parens for all tuple definitions in Py3k wouldn't be a bad idea. Skip From thomas@xs4all.net Tue Jul 11 16:09:05 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 17:09:05 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from gvwilson@nevex.com on Tue, Jul 11, 2000 at 10:42:55AM -0400 Message-ID: <20000711181021.G25805@xs4all.nl> [Note: removing known python-dev members from CC: line. I apologize if that's inconvenient, but otherwise Mailman might not let the posting through. Also, Greg Ewing already received this msg, which had a typo in the To: line. Sorry, Greg ;-P] On Tue, Jul 11, 2000 at 10:42:55AM -0400, Greg Wilson wrote: > > > [x,y for x in (1,2,3) for y in (4,5,6)] > > Hm, I suppose the programmer meant the same as > > [(x,y) for x in (1,2,3) for y in (4,5,6)] > > Would it be really bad if we forced them to write it that way? Oh, yeah, I forgot to say why I disliked it, asside from it being hard to do: Isn't the idea that ()'s do not create tuples, ','s do ? To make something clear, though, '[x,y for x in (1,2,3) for y in (4,5,6)]' creates [(1, 4), (1, 5), (1, 6), (2, 4), (2, 5), (2, 6), (3, 4), (3, 5), (3, 6)] and *not* '[1, 4, 2, 5, 3, 6]', in case anyone was thinking that ! That would be the only reason I'd go for forcing '(x,y)' somehow: disambiguation. But then, tuple-creation is slightly ambiguous already, so allowing the ()'s to be left out here as well, seems pretty natural to me. > Strongly prefer the latter, as it permits: > [[x,y] for x in (1,2,3) for y in (4,5,6)] > (either now or in future). Would it also permit: > [{x:y} for x in (1,2,3) for y in (4,5,6)] > i.e. dict construction using list comprehension? I'd use this in quite a > few places. The first is a good example, though it creates a list of lists, not a single list. The second would create a list of dicts, not a single dict. If you want to create a single dict, this would be better syntax: {x:y for x in (1,2,3) for y in (4,5,6)} AKA dict-comprehensions ;) Unless '[' .. ']' is changed from list-creator to comprehensions-function, and the resulting object is determined by the first expression within the listcomp... That makes it a lot less logical, to me :P > Until yesterday's posting, I assumed that this is what for-for loops would > do, i.e. that they'd deliver a cross-product rather than one-from-each. Well, what would be the use ? You can do that using nested for-loops already. So it looks a tad different, so what ;) (Or are you talking about for-for-loops in list comprehensions instead ?) > Was going to ask whether: > > for i in seq1 and j in seq2: > foo > would be clearer, but then realized that people might assume it implied > that: > for i in seq1 or j in seq2: > foo > would also work, meaning either "while either list is non-empty" or > "cross-product". Well, the problem with *that* syntax is that it's already valid ! Imagine seq1 being a sequence, and seq2.__contains__ returning a sequence. Also, the parser would have a hard time figuring out what version of the for loop to use: is this 'for' exprlist 'in' testlist where 'testlist' contains 'and' and/or 'in', or 'for' exprlist 'in' testlist ('and' exprlist 'in' testlist)* ? I'm not sure if it's possible to use the 2nd form at all! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From akuchlin@mems-exchange.org Tue Jul 11 17:18:17 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 11 Jul 2000 12:18:17 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <14699.17061.139324.335138@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 11, 2000 at 11:52:05AM -0400 References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> Message-ID: <20000711121817.J27228@kronos.cnri.reston.va.us> On Tue, Jul 11, 2000 at 11:52:05AM -0400, Jeremy Hylton wrote: >obj = poll.new() # generate a new pollfd array >obj.register(f1, POLLIN | POLLOUT) >obj.register(f2, POLLOUT) >obj.poll() >obj.unregister(f2) >obj.poll() Very interesting, and probably worth doing because all that list parsing *is* a silly waste of CPU. But could poll still live in the posixmodule, then, or be a module of its own? [1] As a side issue, is posixmodule.c getting ungainly, at 5333 lines of source code? Should something be done about this? (Splitting it into several C files that get #included, or get linked together, for example.) --amk [1] Ironic footnote: Sam mentioned that Egroups doesn't actually use the pollmodule.c in the Medusa distribution, because they already have a module named "poll" that does something completely different. From fdrake@beopen.com Tue Jul 11 17:22:43 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 12:22:43 -0400 (EDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> References: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> Message-ID: <14699.18899.148734.462266@cj42289-a.reston1.va.home.com> --GVPtp1TfAH Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit I wrote: > At one point, we were discussing having specializations of > SyntaxError, and I posted a patch that defined IndentationError and > TabError. With Ping's changes, using these instead of plain > SyntaxError is trivial. Should I include that, or only change the > error messages using Ping's patch? I've attached a combined patch, in case any is interested. This does not include updated documentation, and could use additional tests. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member --GVPtp1TfAH Content-Type: text/plain Content-Description: combined SyntaxError patch Content-Disposition: inline; filename="indentation-error.patch" Content-Transfer-Encoding: 7bit *** cvs-python/Include/errcode.h Fri Jun 30 19:58:04 2000 --- python/Include/errcode.h Tue Jul 11 11:06:11 2000 *************** *** 30,37 **** #define E_NOMEM 15 /* Ran out of memory */ #define E_DONE 16 /* Parsing complete */ #define E_ERROR 17 /* Execution error */ ! #define E_INDENT 18 /* Invalid indentation detected */ ! #define E_OVERFLOW 19 /* Node had too many children */ #ifdef __cplusplus } --- 30,39 ---- #define E_NOMEM 15 /* Ran out of memory */ #define E_DONE 16 /* Parsing complete */ #define E_ERROR 17 /* Execution error */ ! #define E_TABSPACE 18 /* Invalid indentation detected */ ! #define E_OVERFLOW 19 /* Node had too many children */ ! #define E_TOODEEP 20 /* Too many indentation levels */ ! #define E_DEDENT 21 /* No matching outer block for dedent */ #ifdef __cplusplus } *** cvs-python/Include/parsetok.h Tue Jul 11 12:15:31 2000 --- python/Include/parsetok.h Tue Jul 11 11:04:40 2000 *************** *** 22,27 **** --- 22,29 ---- int lineno; int offset; char *text; + int token; + int expected; } perrdetail; extern DL_IMPORT(node *) PyParser_ParseString(char *, grammar *, int, *** cvs-python/Lib/test/test_exceptions.py Tue Jun 20 14:52:57 2000 --- python/Lib/test/test_exceptions.py Tue Jul 4 00:36:58 2000 *************** *** 86,91 **** --- 86,99 ---- try: exec '/\n' except SyntaxError: pass + r(IndentationError) + + r(TabError) + # can only be tested under -tt, and is the only test for -tt + #try: compile("try:\n\t1/0\n \t1/0\nfinally:\n pass\n", '', 'exec') + #except TabError: pass + #else: raise TestFailed + r(SystemError) print '(hard to reproduce)' *** cvs-python/Lib/test/output/test_exceptions Sun Jun 25 06:44:57 2000 --- python/Lib/test/output/test_exceptions Tue Jul 4 00:43:31 2000 *************** *** 28,33 **** --- 28,37 ---- spam SyntaxError spam + IndentationError + spam + TabError + spam SystemError (hard to reproduce) spam *** cvs-python/Parser/parser.c Tue Jul 11 12:15:34 2000 --- python/Parser/parser.c Tue Jul 11 11:11:19 2000 *************** *** 205,215 **** } int ! PyParser_AddToken(ps, type, str, lineno) register parser_state *ps; register int type; char *str; int lineno; { register int ilabel; int err; --- 205,216 ---- } int ! PyParser_AddToken(ps, type, str, lineno, expected_ret) register parser_state *ps; register int type; char *str; int lineno; + int *expected_ret; { register int ilabel; int err; *************** *** 285,290 **** --- 286,300 ---- /* Stuck, report syntax error */ D(printf(" Error.\n")); + if (expected_ret) { + if (s->s_lower == s->s_upper - 1) { + /* Only one possible expected token */ + *expected_ret = ps->p_grammar-> + g_ll.ll_label[s->s_lower].lb_type; + } + else + *expected_ret = -1; + } return E_SYNTAX; } } *** cvs-python/Parser/parser.h Tue Jul 11 12:15:34 2000 --- python/Parser/parser.h Tue Jul 11 11:13:02 2000 *************** *** 38,44 **** parser_state *PyParser_New(grammar *g, int start); void PyParser_Delete(parser_state *ps); ! int PyParser_AddToken(parser_state *ps, int type, char *str, int lineno); void PyGrammar_AddAccelerators(grammar *g); #ifdef __cplusplus --- 38,45 ---- parser_state *PyParser_New(grammar *g, int start); void PyParser_Delete(parser_state *ps); ! int PyParser_AddToken(parser_state *ps, int type, char *str, int lineno, ! int *expected_ret); void PyGrammar_AddAccelerators(grammar *g); #ifdef __cplusplus *** cvs-python/Parser/parsetok.c Tue Jul 11 12:15:34 2000 --- python/Parser/parsetok.c Tue Jul 11 11:15:03 2000 *************** *** 139,146 **** strncpy(str, a, len); str[len] = '\0'; if ((err_ret->error = ! PyParser_AddToken(ps, (int)type, str, ! tok->lineno)) != E_OK) { if (err_ret->error != E_DONE) PyMem_DEL(str); break; --- 139,146 ---- strncpy(str, a, len); str[len] = '\0'; if ((err_ret->error = ! PyParser_AddToken(ps, (int)type, str, tok->lineno, ! &(err_ret->expected))) != E_OK) { if (err_ret->error != E_DONE) PyMem_DEL(str); break; *** cvs-python/Parser/tokenizer.c Tue Jul 11 12:15:34 2000 --- python/Parser/tokenizer.c Tue Jul 11 11:32:37 2000 *************** *** 412,424 **** struct tok_state *tok; { if (tok->alterror) { ! tok->done = E_INDENT; tok->cur = tok->inp; return 1; } if (tok->altwarning) { ! PySys_WriteStderr("%s: inconsistent tab/space usage\n", ! tok->filename); tok->altwarning = 0; } return 0; --- 412,424 ---- struct tok_state *tok; { if (tok->alterror) { ! tok->done = E_TABSPACE; tok->cur = tok->inp; return 1; } if (tok->altwarning) { ! PySys_WriteStderr("%s: inconsistent use of tabs and spaces " ! "in indentation\n", tok->filename); tok->altwarning = 0; } return 0; *************** *** 484,492 **** else if (col > tok->indstack[tok->indent]) { /* Indent -- always one */ if (tok->indent+1 >= MAXINDENT) { ! PySys_WriteStderr( ! "excessive indent\n"); ! tok->done = E_TOKEN; tok->cur = tok->inp; return ERRORTOKEN; } --- 484,490 ---- else if (col > tok->indstack[tok->indent]) { /* Indent -- always one */ if (tok->indent+1 >= MAXINDENT) { ! tok->done = E_TOODEEP; tok->cur = tok->inp; return ERRORTOKEN; } *************** *** 506,514 **** tok->indent--; } if (col != tok->indstack[tok->indent]) { ! PySys_WriteStderr( ! "inconsistent dedent\n"); ! tok->done = E_TOKEN; tok->cur = tok->inp; return ERRORTOKEN; } --- 504,510 ---- tok->indent--; } if (col != tok->indstack[tok->indent]) { ! tok->done = E_DEDENT; tok->cur = tok->inp; return ERRORTOKEN; } *** cvs-python/Python/exceptions.c Tue Jul 11 12:15:34 2000 --- python/Python/exceptions.c Sun Jul 9 22:59:18 2000 *************** *** 68,73 **** --- 68,78 ---- |\n\ +-- AttributeError\n\ +-- SyntaxError\n\ + | |\n\ + | +-- IndentationError\n\ + | |\n\ + | +-- TabError\n\ + |\n\ +-- TypeError\n\ +-- AssertionError\n\ +-- LookupError\n\ *************** *** 783,788 **** --- 788,799 ---- static char MemoryError__doc__[] = "Out of memory."; + static char + IndentationError__doc__[] = "Improper indentation."; + + static char + TabError__doc__[] = "Improper mixture of spaces and tabs."; + /* module global functions */ *************** *** 817,822 **** --- 828,835 ---- PyObject *PyExc_RuntimeError; PyObject *PyExc_NotImplementedError; PyObject *PyExc_SyntaxError; + PyObject *PyExc_IndentationError; + PyObject *PyExc_TabError; PyObject *PyExc_SystemError; PyObject *PyExc_SystemExit; PyObject *PyExc_UnboundLocalError; *************** *** 878,883 **** --- 891,900 ---- {"AttributeError", &PyExc_AttributeError, 0, AttributeError__doc__}, {"SyntaxError", &PyExc_SyntaxError, 0, SyntaxError__doc__, SyntaxError_methods, SyntaxError__classinit__}, + {"IndentationError", &PyExc_IndentationError, &PyExc_SyntaxError, + IndentationError__doc__}, + {"TabError", &PyExc_TabError, &PyExc_IndentationError, + TabError__doc__}, {"AssertionError", &PyExc_AssertionError, 0, AssertionError__doc__}, {"LookupError", &PyExc_LookupError, 0, LookupError__doc__}, {"IndexError", &PyExc_IndexError, &PyExc_LookupError, *** cvs-python/Python/pythonrun.c Tue Jul 11 12:15:34 2000 --- python/Python/pythonrun.c Tue Jul 11 12:10:33 2000 *************** *** 14,19 **** --- 14,20 ---- #include "grammar.h" #include "node.h" + #include "token.h" #include "parsetok.h" #include "errcode.h" #include "compile.h" *************** *** 983,990 **** err_input(err) perrdetail *err; { ! PyObject *v, *w; char *msg = NULL; v = Py_BuildValue("(ziiz)", err->filename, err->lineno, err->offset, err->text); if (err->text != NULL) { --- 984,992 ---- err_input(err) perrdetail *err; { ! PyObject *v, *w, *errtype; char *msg = NULL; + errtype = PyExc_SyntaxError; v = Py_BuildValue("(ziiz)", err->filename, err->lineno, err->offset, err->text); if (err->text != NULL) { *************** *** 993,999 **** } switch (err->error) { case E_SYNTAX: ! msg = "invalid syntax"; break; case E_TOKEN: msg = "invalid token"; --- 995,1011 ---- } switch (err->error) { case E_SYNTAX: ! errtype = PyExc_IndentationError; ! if (err->expected == INDENT) ! msg = "expected an indented block"; ! else if (err->token == INDENT) ! msg = "unexpected indent"; ! else if (err->token == DEDENT) ! msg = "unexpected unindent"; ! else { ! errtype = PyExc_SyntaxError; ! msg = "invalid syntax"; ! } break; case E_TOKEN: msg = "invalid token"; *************** *** 1009,1020 **** case E_EOF: msg = "unexpected EOF while parsing"; break; ! case E_INDENT: msg = "inconsistent use of tabs and spaces in indentation"; break; case E_OVERFLOW: msg = "expression too long"; break; default: fprintf(stderr, "error=%d\n", err->error); msg = "unknown parsing error"; --- 1021,1041 ---- case E_EOF: msg = "unexpected EOF while parsing"; break; ! case E_TABSPACE: ! errtype = PyExc_TabError; msg = "inconsistent use of tabs and spaces in indentation"; break; case E_OVERFLOW: msg = "expression too long"; break; + case E_DEDENT: + errtype = PyExc_IndentationError; + msg = "unindent does not match any outer indentation level"; + break; + case E_TOODEEP: + errtype = PyExc_IndentationError; + msg = "too many levels of indentation"; + break; default: fprintf(stderr, "error=%d\n", err->error); msg = "unknown parsing error"; *************** *** 1022,1028 **** } w = Py_BuildValue("(sO)", msg, v); Py_XDECREF(v); ! PyErr_SetObject(PyExc_SyntaxError, w); Py_XDECREF(w); } --- 1043,1049 ---- } w = Py_BuildValue("(sO)", msg, v); Py_XDECREF(v); ! PyErr_SetObject(errtype, w); Py_XDECREF(w); } --GVPtp1TfAH-- From guido@beopen.com Tue Jul 11 18:52:43 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 12:52:43 -0500 Subject: [Python-Dev] list comprehensions again... In-Reply-To: Your message of "Tue, 11 Jul 2000 17:09:05 +0200." <20000711181021.G25805@xs4all.nl> References: <20000711181021.G25805@xs4all.nl> Message-ID: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Oops. I was simply mistaken on what the for-for syntax in list comprehensions did! Ideally, list comprehensions should support both parallel and nested for loops, but I'm not sure how to decide to parse them if they both occur. E.g. what is this? [(x,y+z) for x in (1,2,3,4,5,6); for y in "abc" for z in "de"] For me, the semicolon separates much stronger than the for, so (to me) this feels like (applying parentheses to show grouping): (for x); (for y for z) and would yield: [(1, "ad"), (2, "ae"), (3, "bd"), (4, "be"), (5, "cd"), (6, "ce")] But is that the most useful? And how do you write the other grouping? I mean: (for x; for y) (for z) which could yield: [(1, "ad"), (1, "ae"), (2, "bd"), (2, "be"), (3, "cd"), (3, "ce")] A more practical question: if we're going to introduce [::], list comprehensions, and parallel for loops, what would be the best way to introduce the patches so that each patch changes as little as possible of the code introduced by the previous patch? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From dbressler@valinux.com Tue Jul 11 18:03:09 2000 From: dbressler@valinux.com (Dan Bressler) Date: Tue, 11 Jul 2000 10:03:09 -0700 Subject: [Python-Dev] Re: SourceForge References: <20000707133533.E17746@valinux.com> <20000707182448.A31259@thyrsus.com> <39667D29.1A4FB1BB@valinux.com> <20000709214138.I4566@thyrsus.com> <396A4CFC.CEE2419A@valinux.com> <20000710203719.B9793@thyrsus.com> <396A6F7D.66D5F085@valinux.com> <20000710211000.A10068@thyrsus.com> <200007111458.JAA05267@cj20424-a.reston1.va.home.com> Message-ID: <396B534D.3C4A4E3A@valinux.com> If you're going to be in Santa Clara during the day, do you want to stay in the area and meet us in the evening? (Our offices are right in the neighborhood.) Guido van Rossum wrote: > > Dan Bressler : > > > I'm trying to sync schedules -- If we could set it for Tuesday evening, July > > > 18th, that would work best. > > > > OK. Python folks who will be at the Monterey conference; Dan > > Bressler, one of the managers of SourceForge, is amenable to an > > evening meeting with this gang on Tuesday the 18th. I gather Tim > > Purdue, currently the lead programmer on the project, will be there. > > > > The exact time is still to be worked out. Anybody got a proposal? > > I'm not sure what time we'll be arriving in Monterey -- we have our > plane tickets to San Jose and I know we're going to spend Tuesday > daytime at the BeOpen headquarters in Santa Clara, but I don't know > yet what mode of transportation we're going to take to Monterey and at > what time. Given that Dan prefers Tuesday evening I'll try to press > for leaving early enough so that there's some evening left! > > Looking forward to this meeting, > > --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy@beopen.com Tue Jul 11 18:09:07 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 13:09:07 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <20000711121817.J27228@kronos.cnri.reston.va.us> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> <20000711121817.J27228@kronos.cnri.reston.va.us> Message-ID: <14699.21683.305409.97490@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Tue, Jul 11, 2000 at 11:52:05AM -0400, Jeremy Hylton wrote: >obj = poll.new() # generate a new pollfd array >obj.register(f1, POLLIN | POLLOUT) >obj.register(f2, POLLOUT) >obj.poll() >obj.unregister(f2) >obj.poll() AMK> Very interesting, and probably worth doing because all that AMK> list parsing *is* a silly waste of CPU. But could poll still AMK> live in the posixmodule, then, or be a module of its own? [1] The select module has exactly the same problem and could use the same interface. They could both live in their own module. I'm not sure what to call it. Possibilities include: - add it to the current select module - new name, e.g. asyncio, fileevent - call it _asyncore and expose it through the asyncore module Jeremy From gvwilson@nevex.com Tue Jul 11 18:09:11 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 13:09:11 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz Message-ID: I sent the message below to the 11 developers here in the office this morning. They all have 10+ years experience with C, and 2-3 years with C++, Java, or both. None have used Python (I'm working on it :-), but two have extensive Perl experience, and one worked on and with functional languages in grad school. The question was: OK, folks, language question. Given the statement: for x in [10, 20, 30]; y in [1, 2]: print x+y (note that the second list is shorter than the first), would you expect to see: (A) 'x' and 'y' move forward at the same rate: 11 22 (B) 'y' goes through the second list once for each value of 'x': 11 12 21 22 31 32 (C) an error message because the two lists are not the same length? Votes to me, please. Thanks, Greg *Everyone* voted (B). As useful as this capability is, I therefore think the proposed syntax is likely to mislead. Hope it's helpful, Greg From thomas@xs4all.net Tue Jul 11 18:22:03 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 19:22:03 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111752.MAA06413@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 12:52:43PM -0500 References: <20000711181021.G25805@xs4all.nl> <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Message-ID: <20000711192202.B7340@xs4all.nl> On Tue, Jul 11, 2000 at 12:52:43PM -0500, Guido van Rossum wrote: > Ideally, list comprehensions should support both parallel and nested > for loops, but I'm not sure how to decide to parse them if they both > occur. E.g. what is this? > > [(x,y+z) for x in (1,2,3,4,5,6); for y in "abc" for z in "de"] Well, listcomprehensions are currently almost a simple rewrite, so this is fairly easy to parse: the ; binds more tightly than the last 'for', and 'for' loops and 'if' branches parse left-to-right without possibilities of 'else'. [..] > But is that the most useful? And how do you write the other grouping? > I mean: > (for x; for y) (for z) > which could yield: > [(1, "ad"), (1, "ae"), (2, "bd"), (2, "be"), (3, "cd"), (3, "ce")] This might be a problem. Also, even providing the 'nested for' in listcomprehensions might be a problem, for exactly the reason you yourself showed: it's not that easy to see what it actually does. Can we get away with not including the nested-for syntax ? I mean, "don't do that then" is something that really appeals to me, and I think it applies here: If you want nested-for loops in creating a list, use a real for loop :P Also, on 4th or 5th pass, I'm still not sure about the whole list comprehensions syntax... I know what problem they are supposed to solve, and I think they succeed in that. But the syntax is pretty ambiguous, and not too pythonic at that. For instance, the endless mixing possibilities of 'for' and 'if' without delimiters or ways to group them can be pretty confusing. Some documentation on that might help, though. Also, it would be nice if list comprehensions could be used to initialize *part* of a list, something like this: ['a', 'b', c for c in ['C', 'D', 'E'], 'f', 'g'] (which would create ['a', 'b', 'C', 'D', 'E', 'f', 'g']) But that creates a legion of other confusalities... Perhaps adding a new/different delimiter to list comprehensions would be a good idea ? :P Disclaimer, though: I didn't follow the list-comprehension discussions on python-list, last year, that closely. I noticed the syntax and thought "that cool.", but that's about it. Was any other syntax proposed ? > A more practical question: if we're going to introduce [::], list > comprehensions, and parallel for loops, what would be the best way to > introduce the patches so that each patch changes as little as possible > of the code introduced by the previous patch? parallel-for-loops -> list comprehensions -> range-literals Unless list comprehensions do not adopt the parallel for loop syntax, in which case the order isn't that important. They don't really touch in that much places, not even the range-literals and list comprehensions patch. The Grammar and a single line in compile.c, if I recall correctly. The rest is just offset and fluff. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@beopen.com Tue Jul 11 19:24:05 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 13:24:05 -0500 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: Your message of "Tue, 11 Jul 2000 13:09:11 -0400." References: Message-ID: <200007111824.NAA06758@cj20424-a.reston1.va.home.com> > I sent the message below to the 11 developers here in the office this > morning. They all have 10+ years experience with C, and 2-3 years with > C++, Java, or both. None have used Python (I'm working on it :-), but two > have extensive Perl experience, and one worked on and with functional > languages in grad school. The question was: > > OK, folks, language question. Given the statement: > > for x in [10, 20, 30]; y in [1, 2]: > print x+y > > (note that the second list is shorter than the first), would you > expect to see: > > (A) 'x' and 'y' move forward at the same rate: > > 11 > 22 > > (B) 'y' goes through the second list once for each value of 'x': > > 11 > 12 > 21 > 22 > 31 > 32 > > (C) an error message because the two lists are not the same length? > > Votes to me, please. > > Thanks, > Greg > > *Everyone* voted (B). As useful as this capability is, I therefore think > the proposed syntax is likely to mislead. Thanks for user testing! I just wished you had shown it to them with two lists of the same length. That's the normal case, and I believe that the different length must have tricked them into believing that it couldn't possibly be (A). I'd like to run the experiment with that change. Do you have another set of guinea pigs around? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Tue Jul 11 17:07:39 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 11 Jul 2000 11:07:39 -0500 (CDT) Subject: [Python-Dev] once enabled gc won't go away until explicitly disabled? In-Reply-To: <14699.16271.147279.134444@anthem.concentric.net> References: <14699.10639.15423.982767@beluga.mojam.com> <14699.16271.147279.134444@anthem.concentric.net> Message-ID: <14699.17995.992200.367742@beluga.mojam.com> BAW> Yes, although both gc and threads are enabled by default in the BAW> current betas (so you don't need --with-threads). Whether they'll BAW> be enabled for the final release is still TBD. Ah, yes, now I remember. I don't suppose there's any way to coax 'configure --help' into dumping out the default values, is there? I think it would be a very useful feature. Skip From skip@mojam.com (Skip Montanaro) Tue Jul 11 17:09:58 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 11 Jul 2000 11:09:58 -0500 (CDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> References: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> Message-ID: <14699.18134.550769.266956@beluga.mojam.com> Fred> At one point, we were discussing having specializations of Fred> SyntaxError, and I posted a patch that defined IndentationError Fred> and TabError. I think you should go for it. As long as they are subclasses of SyntaxError no existing code should break. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From gvwilson@nevex.com Tue Jul 11 19:45:51 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 14:45:51 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007111824.NAA06758@cj20424-a.reston1.va.home.com> Message-ID: [Greg's list comprehension experiment deleted] > Guido: > I just wished you had shown it to them with two lists of the same > length. That's the normal case, and I believe that the different > length must have tricked them into believing that it couldn't possibly > be (A). > I'd like to run the experiment with that change. Do you have another > set of guinea pigs around? Yes, I'll have a roomful of people Thursday morning (practicing my talk for Monterey). If someone would like to rephrase the example, I'd be happy to do a show-of-hands poll. Thanks, Greg From guido@beopen.com Tue Jul 11 21:03:12 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 15:03:12 -0500 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: Your message of "Tue, 11 Jul 2000 14:45:51 -0400." References: Message-ID: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> > Yes, I'll have a roomful of people Thursday morning (practicing my talk > for Monterey). If someone would like to rephrase the example, I'd be > happy to do a show-of-hands poll. Suppose this code: for i in (1, 2, 3): print i prints this: 1 2 3 What do you think the following code would print? for i in (10, 20, 30); j in (1, 2, 3): print i+j A. 11 22 33 B. 11 12 13 21 22 23 31 32 33 I'm afraid the answer will be the same, if these are again numerical analysts -- these people live by nested DO loops. :-( --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Tue Jul 11 18:38:23 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 11 Jul 2000 12:38:23 -0500 (CDT) Subject: [Python-Dev] patch assignments? Message-ID: <14699.23439.483525.515059@beluga.mojam.com> I just noticed a patch assignment made to me on June 30th: http://sourceforge.net/patch/?func=detailpatch&patch_id=100688&group_id=5470 with a comment from Tim on July 10th about it having been assigned to me. In the flood of patch submissions and updates I guess I missed this. The SF patch change mails say *nothing* as far as I can tell about what the nature of the change of status of a patch is. With all changes going through the patches mailing list, more interesting stuff can get lost in the sea of stuff I'm not particularly interested in. Consequently, I would have hit 'd' seeing a subject like "Add 'isatty(fd)' to posixmodule". Has anyone asked SF for a more complete patch mailing? If not, I will probably unsubscribe from patches@python.org so I can be assured that those notices I get are actually for me. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From Ka-Ping Yee Tue Jul 11 20:11:58 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Tue, 11 Jul 2000 12:11:58 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> Message-ID: On Tue, 11 Jul 2000, Greg Ewing wrote: > Thomas> '[' [testlist [list_iter]] ']' > Thomas> Should that really be 'testlist'? > [...] > if it were changed I expect > you'd get complaints that things like > > [x,y for x in (1,2,3) for y in (4,5,6)] Well, i imagine this would yield [x, 4, 5, 6, 4, 5, 6, 4, 5, 6] right? I think i vote for "produce parens only if i write parens". Hmm, another question. When someone writes: [x, y for x in 1, 2, 3 for y in 4, 5, 6] ...what should they get? (a) SyntaxError (b) [(1, 4), (1, 5), (1, 6), (2, 4), (2, 5), (2, 6), (3, 4), (3, 5), (3, 6)] (c) [x, 4, 5, 6, 4, 5, 6, 4, 5, 6] (d) [x, y, 2, 3, 5, 6] If we go with above rule of "produce parens only if i write parens", then the answer has to be (d). That is, commas bind last in a list (which seems consistent with normal practice...). Does this make sense or seem confusing to you? If it's too confusing, we can choose (a) and require that the first part of a list comprehension has to be a single test. -- ?!ng From pingster@ilm.com Tue Jul 11 20:15:26 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 12:15:26 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: Message-ID: On Tue, 11 Jul 2000, Greg Wilson wrote: > (either now or in future). Would it also permit: > > [{x:y} for x in (1,2,3) for y in (4,5,6)] > > i.e. dict construction using list comprehension? I'd use this in quite a > few places. The above would produce [{1: 4}, {1: 5}, {1: 6}, {2: 4}, {2: 5}, {2: 6}, {3: 4}, {3: 5}, {3: 6}] If, on the other hand, you tried to make a single dictionary with {x: y for x in (1, 2, 3) for y in (4, 5, 6)} it doesn't make a lot of sense (multiple y's for the same x?). The only thing i could imagine it producing, perhaps, is {1: 6, 2: 6, 3: 6} -- ?!ng From bwarsaw@beopen.com Tue Jul 11 20:29:43 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 15:29:43 -0400 (EDT) Subject: [Python-Dev] Memory leak tracking Message-ID: <14699.30119.262274.258429@anthem.concentric.net> Folks, I've been doing a fair bit of Purify-cation on the Python source tree. Things are looking pretty good in general, but I have a question for you all. When I compile out gc, I get more leaks in the core, namely in exceptions.c. Turning on gc clears all of these up; e.g. all the memory gets freed eventually. My suspicion therefore is that there are a number of cycles created during the initialization of the built-in exceptions. How important is it to fix these problems when gc is disabled? It's not a lot of memory (like <5000 bytes or so for running one of the regr tests) and it'll take some time to track them down and figure out what the right fix is. Given everything all the other more interesting work to do, it doesn't seem worth it. So far we haven't seen any showstopping gc bugs reported yet, so I'm hopeful it'll remain enabled by default in 2.0. Please let me know what you think. If the concensus is to fix them, I keep working on them. I do still plan on looking at the few memory problems still left even with gc turned on. -Barry From Ka-Ping Yee Tue Jul 11 20:26:54 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Tue, 11 Jul 2000 12:26:54 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 11 Jul 2000, Guido van Rossum wrote: > [(x,y+z) for x in (1,2,3,4,5,6); for y in "abc" for z in "de"] > > For me, the semicolon separates much stronger than the for, so (to me) > this feels like (applying parentheses to show grouping): > > (for x); (for y for z) When written like the above, i agree that the semicolon separates more strongly. Perhaps we should rearrange the syntax to make the semicolon more interior? This also addresses Greg's poll: > > for x in [10, 20, 30]; y in [1, 2]: > print x+y [...] > *Everyone* voted (B). How about writing this as: for x; y in [10, 20, 30]; [1, 2]: print x + y > And how do you write the other grouping? As a result, this provides a way to write parallel loops within list comprehensions, although it might not be very clear until you're familiar with the way it's written above. At least it's possible: [(x, y+z) for x; y in (1, 2, 3, 4, 5, 6); "abc" for z in "de"] If colons were introduced, would that help keep things clear? [(x, y+z): for x; y in (1, 2, 3, 4, 5, 6); "abc": for z in "de"] This would then be directly reminiscent of for x; y in (1, 2, 3, 4, 5, 6); "abc": for z in "de": list.append((x, y+z)) which provides the appropriate meaning. I don't like extra punctuation, but i'm not sure what else to do here since "for" alone is a very weak separator. -- ?!ng From pingster@ilm.com Tue Jul 11 20:40:22 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 12:40:22 -0700 (PDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: Message-ID: On Tue, 11 Jul 2000, Greg Wilson wrote: > for x in [10, 20, 30]; y in [1, 2]: > print x+y [...] > (A) 'x' and 'y' move forward at the same rate: > (B) 'y' goes through the second list once for each value of 'x': > (C) an error message because the two lists are not the same length? [...] > *Everyone* voted (B). Okay, i just thought of another answer to this. Scream at me if you find this hideous. for x in [10, 20, 30] while y in [1, 2]: print x+y My previous message proposed colons to separate the clauses of a list comprehension, which i now realize makes dict comprehensions impossible (or at least a little strange-looking). If we use "while", the lack of semicolons means that we can do parallel loops in list-comps without colons, which in turn enables dict-comps. -- ?!ng From thomas@xs4all.net Tue Jul 11 20:51:00 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 21:51:00 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from pingster@ilm.com on Tue, Jul 11, 2000 at 12:26:54PM -0700 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Message-ID: <20000711215100.C7340@xs4all.nl> On Tue, Jul 11, 2000 at 12:26:54PM -0700, Ka-Ping Yee wrote: > This would then be directly reminiscent of > > for x; y in (1, 2, 3, 4, 5, 6); "abc": > for z in "de": > list.append((x, y+z)) > > which provides the appropriate meaning. > I don't like extra punctuation, but i'm not sure what else to do > here since "for" alone is a very weak separator. Agreed, though I think ';' is the wrong punctuation for this... It's always been a statement-seperator, and now it's used to seperate parts of a statement, like a normal comma. I still think 'for x in a; y in b' is better than this, but I'm not sure how to liase it with list comprehensions' "nested for". But then, I'm not sure about any of the list comp syntax right now :-) To paraphrase Guido, I got myself in quite a mess ;-) Anyone object if I pull this discussion into c.l.py ? I'm not sure if any new ideas pop up, but it might give some more data to work with ;-P And I don't think any of this is urgent in any way, I doubt anything more will get done until after ORA OSCON, anyway. And maybe some of you guys that are actually going there can discuss it face to face ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw@beopen.com Tue Jul 11 20:54:16 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 15:54:16 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Message-ID: <14699.31592.410628.754071@anthem.concentric.net> Sorry, but I'm being to think that both the list comprehensions and parallel for loops are looking pretty dodgy. I wonder what newbies are going to think when they see this stuff? If the semantics aren't obvious to us, they definitely will not be to them. Range literals I can see as being worth it. I wonder if parallel for loops can't be handled more gracefully with a function -- isn't it just a nice wrapper around a specific call to map() anyway? List comprehensions do seem to need more syntactic support, but the ambiguity of the semantics bothers me. monkey-wretched-ly y'rs, -Barry From gvwilson@nevex.com Tue Jul 11 20:59:52 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 15:59:52 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711215100.C7340@xs4all.nl> Message-ID: > Thomas wrote: > Anyone object if I pull this discussion into c.l.py? Rather than asking for suggestions, would it make sense to prepare one or more examples of multi-loops and output, then ask people to vote on which ones they would expect to match up with which? Likely to be lower bandwidth, and it'd be an interesting experiment in language design procedures in its own right :-). Greg From fdrake@beopen.com Tue Jul 11 21:11:54 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 16:11:54 -0400 (EDT) Subject: [Python-Dev] Showing stale locks under cvsweb Message-ID: <14699.32650.73594.921249@cj42289-a.reston1.va.home.com> I've just received a response to my "bug report" at SourceForge about stale locks needing to be visible in cvsweb. They categorized it as "Irrelevant" and said the cvsweb people were the ones to contact (seems reasonable; now I know that there *are* cvsweb people!). I've found the right people and sent a note to them, with a copy to Greg Stein as well, noting that ViewCVS should support a similar feature. I'll let everyone know what happens regarding this if/when I get a response. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy@beopen.com Tue Jul 11 21:20:36 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 16:20:36 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> References: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> Message-ID: <14699.33172.319800.354377@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> I'm afraid the answer will be the same, if these are again GvR> numerical analysts -- these people live by nested DO loops. :-( If we end up calling this new feature list comprehensions, we might create the expectation that they behave like list comprehensions in other languages. Haskell is one language with comprehensions and they behave the way that the numerical analysts expect them to behave. Maybe we should chalk it up to numerical analysts and funtional programmers being weird, but they may be on to something. Here's a short excerpt from the Gentle Introduction to Haskell: http://www.haskell.org/tutorial/goodies.html (Sec. 2.4.1) >[ f x | x <- xs ] >This expression can intuitively be read as "the list of all f x such >that x is drawn from xs." The similarity to set notation is not a >coincidence. The phrase x <- xs is called a generator, of which more >than one is allowed, as in: > >[ (x,y) | x <- xs, y <- ys ] > >This list comprehension forms the cartesian product of the two lists >xs and ys. The elements are selected as if the generators were >"nested" from left to right (with the rightmost generator varying >fastest); thus, if xs is [1,2] and ys is [3,4], the result is >[(1,3),(1,4),(2,3),(2,4)]. Jeremy From rushing@nightmare.com Tue Jul 11 21:26:53 2000 From: rushing@nightmare.com (Sam Rushing) Date: Tue, 11 Jul 2000 13:26:53 -0700 (PDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <26950820@toto.iv> Message-ID: <14699.33549.656358.89869@seattle.nightmare.com> Andrew Kuchling writes: > (At the very highest end, even poll() begins to scale badly since you > list "all the open fds", not "all the open fds which have activity". > At that point you're supposed to switch to async I/O, but probably > you'd have switched from Python to C long before that point.) Lots of good info on these issues is available here: http://www.kegel.com/c10k.html Linux and FreeBSD are growing new kernel-event-delivery mechanisms that promise better scalability and efficiency. Win32's had it from the beginning. For the eGroups coroutine scheduler ( http://www.egroups.com/group/python-coro ) I wrote a more efficient poll wrapper, but it's also very bare. Might be a starting point. This stuff hasn't been used yet, so the driver module has fallen way behind. Compare coro2.py to 'coro.py' in the egroups coro dist. http://www.nightmare.com/stuff/coro_poll.c http://www.nightmare.com/stuff/coro2.py In coro_poll.c, there's a single struct pollfd array, that should probably be PyObject-ified. -Sam From klm@digicool.com Tue Jul 11 21:33:01 2000 From: klm@digicool.com (Ken Manheimer) Date: Tue, 11 Jul 2000 16:33:01 -0400 (EDT) Subject: [Python-Dev] Objects/ ANSI-fied In-Reply-To: <200007092153.QAA14165@cj20424-a.reston1.va.home.com> Message-ID: On Sun, 9 Jul 2000, Guido van Rossum wrote: > > Ok, the Objects/ directory has been ANSI-fied, and I've noticed /F > > slaving away in the Modules/ directory, so I'll get out of the way for > > a little bit. ;) > > Great! Sounds like everybody is getting the hint that 2.0 needs to > have some distinguishing characteristics compared to 1.6... :-) Hmm. I just realized an interesting take on 2.0's "distinguishing features". Check out the volume of python-dev traffic - reflecting what's to me, at least, incredibly high pace and high fiber collaboration. Python 2.0 could be about a new process, as much as it is about the license policy changes that better enable it, or the productivity it seems to be promoting. (I'm not silly enough to suggest that the version change could happen solely on the basis of a new process - there really do seem to be genuine results, here...) (And if BeOpen happens to be looking for a product, and you can bottle this, they might like to have it.-) Seriously, maybe BeOpen should concentrate on helping teams to better employ available resources - look at how good they're doing with you guys. Well, ok, what they're doing right is leaving you guys mostly alone - maybe your payoff for them would be to clue them into what works, and they can do some work to deliver it to others. Might could help you all, too, in solidifying what's going on...) Ken klm@digicool.com From paul@prescod.net Tue Jul 11 21:44:06 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 15:44:06 -0500 Subject: [Python-Dev] list comprehensions again... References: Message-ID: <396B8716.C1C9EE3C@prescod.net> I'm sorry to muddy the waters, but perhaps a solution is to try and stay as close to regular Python syntax as possible. I am thinking of a nested comprehension as a regular nested for-loop that has an expression rather than a suite as its body: Nested (List): [for x in (0,10,20,30): for y in (0,1,2,3): x+y] [0,11,22,33] Parallel (Tuple): (for x in (0,10,20,30) and y in (0,1,2,3): x+y) (0,11,22,33) Parallel (Dict): {for x in (0,10,20,30) and y in range (0,1,2,3): x,y} The dict one needs a little explaining. A dict comprehension is a comprehension where the delimiters are curly braces and the generated items are required to be pairs. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From thomas@xs4all.net Tue Jul 11 21:47:49 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 22:47:49 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from gvwilson@nevex.com on Tue, Jul 11, 2000 at 03:59:52PM -0400 References: <20000711215100.C7340@xs4all.nl> Message-ID: <20000711224749.C7345@xs4all.nl> On Tue, Jul 11, 2000 at 03:59:52PM -0400, Greg Wilson wrote: > > Thomas wrote: > > Anyone object if I pull this discussion into c.l.py? > Rather than asking for suggestions, would it make sense to prepare one or > more examples of multi-loops and output, then ask people to vote on which > ones they would expect to match up with which? Likely to be lower > bandwidth, and it'd be an interesting experiment in language design > procedures in its own right :-). That's exactly what I had in mind, yes ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul@prescod.net Tue Jul 11 21:49:44 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 15:49:44 -0500 Subject: [Python-Dev] list comprehensions again... References: <396B8716.C1C9EE3C@prescod.net> Message-ID: <396B8868.B58F3F0C@prescod.net> Paul Prescod wrote: > > ... > (for x in (0,10,20,30) and y in (0,1,2,3): > x+y) > (0,11,22,33) Sorry, replace the "and" with ";" or "while" to resolve the ambiguity: Nested (List): [for x in (0,10,20,30): for y in (0,1,2,3): x+y] [0,11,22,33] Parallel (Tuple): (for x in (0,10,20,30) ; y in (0,1,2,3): x+y) (0,11,22,33) Parallel (Dict): {for x in (0,10,20,30) ; y in range (0,1,2,3): x,y} -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Fredrik Lundh" Message-ID: <021201bfeb7d$515c3520$f2a6b5d4@hagrid> tim wrote: =20 > I believe we also need a way to split unicodedatabase.c into multiple = files, > as > 64K lines in a source file is unreasonable (Python can't handle a > source file that large either, and Python is the *definition* of > reasonableness here ), and the MS compiler spits out a warning = about > its sheer size. just a heads-up: I've been hacking a little on a new unicode database. the results this far are quite promising: CTYPE: is*, to* functions 118k =3D> 13k CNAME: code <=3D> name mappings (\N{name}) 440k =3D> 160k CINFO: remaining unicode properties 590k =3D> 42k (approximate code size with the old and new code, on Windows) on the source side, 3300k source files are replaced with about 600k (generated by a script, directly from the uni- code.txt data file). note that the CNAME and CINFO parts are optional; you only need CTYPE to build a working Python interpreter. integrating this with 2.0 should be relatively straightforward, but don't expect it to happen before next week or so... cheers /F From fdrake@beopen.com Tue Jul 11 22:20:38 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 17:20:38 -0400 (EDT) Subject: [Python-Dev] O'Reilly conference Message-ID: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> So who's going to the O'Reilly conference next week? The PythonLabs crew expects to be there, and we just might have some goodies. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pingster@ilm.com Tue Jul 11 22:31:24 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 14:31:24 -0700 (PDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 11 Jul 2000, Guido van Rossum wrote: > What do you think the following code would print? > > for i in (10, 20, 30); j in (1, 2, 3): > print i+j [...] > I'm afraid the answer will be the same, if these are again numerical > analysts -- these people live by nested DO loops. :-( What do you think the answer would be for for i; j in (10, 20, 30); (1, 2, 3): print i+j ? Would you consider posing this question? -- ?!ng From Fredrik Lundh" Message-ID: <025201bfeb80$829976e0$f2a6b5d4@hagrid> fred wrote: > So who's going to the O'Reilly conference next week? Portions of the Secret Labs crew expects to be there, and they just might have some goodies. ;) cheers /F From DavidA@ActiveState.com Tue Jul 11 22:48:52 2000 From: DavidA@ActiveState.com (David Ascher) Date: Tue, 11 Jul 2000 14:48:52 -0700 (Pacific Daylight Time) Subject: [Python-Dev] O'Reilly conference In-Reply-To: <025201bfeb80$829976e0$f2a6b5d4@hagrid> Message-ID: On Tue, 11 Jul 2000, Fredrik Lundh wrote: > fred wrote: > > > So who's going to the O'Reilly conference next week? A bunch of ActiveState folks, naturally. We'll have an _early_ demo of Komodo and friends, will be recruiting, etc. If anyone wants to guarantee that they talk to me about anything, it's best to let me know early. --david PS: Anyone who'se going w/ young kids who might want to do fun things w/ mine (& my wife =) should let me know. It's easier to deal w/ lots of kids than w/ a few, somehow... Andy Robinson's family will be there. From thomas@xs4all.net Tue Jul 11 22:47:38 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 23:47:38 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.31592.410628.754071@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Jul 11, 2000 at 03:54:16PM -0400 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> Message-ID: <20000711234737.D7340@xs4all.nl> On Tue, Jul 11, 2000 at 03:54:16PM -0400, Barry A. Warsaw wrote: > Sorry, but I'm being to think that both the list comprehensions and > parallel for loops are looking pretty dodgy. I wonder what newbies > are going to think when they see this stuff? If the semantics aren't > obvious to us, they definitely will not be to them. > Range literals I can see as being worth it. I wonder if parallel for > loops can't be handled more gracefully with a function -- isn't it > just a nice wrapper around a specific call to map() anyway? Well, not really. It doesn't create a new list, only a tuple to hold lists to iter over (in order to pass it to the opcode as a single PyObject) and similar for the resulting objects. It's definately more efficient than the map() solution (and different, see below ;) I agree that all this together looks dodgy, but I think there is a simple way to view it... I still think 'for x in a; y in b:' is the right syntax for parallel for loops. It's almost "only" syntactic sugar for 'for x,y in map(None, a, b)' but it's fairly straightforward, and in large blocks of code it might look a lot better. It also has the benifit of not padding the shortest list to the size of the longest one: getting that behaviour with a map requires an aditional 'filter' or such. Whether it does or doesn't do what people actually expect I don't know, but with all due respect to Greg for doing the usability test, I don't think it carries that much meaning: We should be testing Python newbies, not people who haven't tried Python at all, yet. Unfortunately, I don't have such a batch at hand either ;) (My colleagues either refuse to learn Python, or haven't stayed newbie for more than a few hours :-) Given that you can already do the nested-for-loop with a nested for loop, and it doesn't suffer (much) in way of readability or pythonity, I think most people will realize that the parallel for loop does actually do a parallel for-each. A number of Python features, like (the lack of) nested namespaces and the way assignment works, seem counter-intuitive (or at least lesser-intuitive) at first, but there simply isn't a better way to handle them and maintain Python's simplicity. I think this is one of those cases. Note that this doesn't include list comprehensions ! I find the syntax confusing myself, but it doesn't look like we can fix it by stealing the best syntax of parallel-for loops for it ;) Also, list comprehensions don't add *that* much. They provide an easier way to create a list, but they don't eradicate the need for map, reduce or filter, because there is no way to comprehend an already created list. I like Paul's proposal that makes list comprehensions look more like normal 'for' loops, requiring indentation and all, but I'm not sure if they're going to work... This definately requires more thought ;-) I think I'll post a (very) short summary of the entire discussion and some examples for people to vote about, and perhaps express their opinion, on c.l.py. Sometime tomorrow ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm@hypernet.com Tue Jul 11 22:47:56 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 11 Jul 2000 17:47:56 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.31592.410628.754071@anthem.concentric.net> Message-ID: <1248770416-32799859@hypernet.com> Barry A. Warsaw wrote: > Sorry, but I'm being to think that both the list comprehensions > and parallel for loops are looking pretty dodgy. I'm with Barry here (despite the public humiliation the association involves). My expectations (from examples) correlates to accompanying explanations no better than random choice. I *thought* I liked Greg Ewing's original proposal, but at this point I see syntactic salts of ammonia around one very clear idiom (nested fors) and one less intuitive but unambiguous idiom (map). I like the set notation, but there's a big impedance mismatch to Python. I'd be tempted to spell "cartesian product" as a product. To put it another way: - syntactic sugar for nested "for" loops would be nice, but there's no crying need for it - the current spelling of parallel loops is awkward and probably does warrant syntactic sugar (despite Greg Wilson's experiment that it's not what's expected). If list comprehensions are going to do *both*, the difference in how they're spelled will have to be obvious and intuitive, or we might as well just keep explaining how to use map. - Gordon From gstein@lyra.org Tue Jul 11 22:53:29 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 14:53:29 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from pingster@ilm.com on Tue, Jul 11, 2000 at 12:11:58PM -0700 References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> Message-ID: <20000711145329.T29590@lyra.org> On Tue, Jul 11, 2000 at 12:11:58PM -0700, Ka-Ping Yee wrote: >... > Does this make sense or seem confusing to you? > > If it's too confusing, we can choose (a) and require that the first > part of a list comprehension has to be a single test. If it is too confusing, then drop the darn feature. We're adding syntax that is sure to make Python programs a lot less readable when they are used. People will always say "now, what exactly does that do?" Adding new, complex features does not equate with positive forward progress. This whole notion of list comprehensions seems rather dubious, especially given the wildly varying ideas of what the different syntaxes mean. Sure, maybe we can decide on what it *should* mean, but people will continue to be confused by what they *think* it would mean. Drop the dumb thing altogether. What's the motivation? Bleh. -1 Cheers, -g -- Greg Stein, http://www.lyra.org/ From thomas@xs4all.net Tue Jul 11 22:54:01 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 23:54:01 +0200 Subject: [Python-Dev] O'Reilly conference In-Reply-To: <025201bfeb80$829976e0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jul 11, 2000 at 11:39:22PM +0200 References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> <025201bfeb80$829976e0$f2a6b5d4@hagrid> Message-ID: <20000711235401.E7340@xs4all.nl> On Tue, Jul 11, 2000 at 11:39:22PM +0200, Fredrik Lundh wrote: > fred wrote: > > So who's going to the O'Reilly conference next week? > Portions of the Secret Labs crew expects to be there, and > they just might have some goodies. ;) Goodies!? Argh! Can I send a colleague over to gather some of the goodies for me ? I'm not important enough to go to OSCON, only our resident Perl guru is... But we'd need him back or our company stops functioning, so I'll only send him over if you promise not to hurt him :) Otherwise, I'll have to stay Python-goodieless until the next IPC... -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw@beopen.com Tue Jul 11 22:55:56 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 17:55:56 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> Message-ID: <14699.38892.155046.60218@anthem.concentric.net> >>>>> "Gordo" == Gordon McMillan writes: Gordo> I'm with Barry here (despite the public humiliation the Gordo> association involves). For both of us, of course. :) -Barry From jack@oratrix.nl Tue Jul 11 22:55:12 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 11 Jul 2000 23:55:12 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Message by "James C. Ahlstrom" , Mon, 10 Jul 2000 12:43:03 -0400 , <3969FD17.487DA96A@interet.com> Message-ID: <20000711215517.E9C71E2673@oratrix.oratrix.nl> Excuse my ignorance, but isn't the whole problem that the python 1.6 DLL is in the system search path even when you are running Python 1.7? MacPython solves this problem by keeping the PythonCore dll in the application directory, so it'll be found by a Python executable in the same directory but not by a python executable living elsewhere. And even if you import a dynamic module that was meant for and older or newer version of Python you'll get a decent error message: because all PythonCore's have the same name the imported module will link against the one already loaded and complain bitterly about missing externals (all assuming the current PythonCore and the module aren't compatible). This is a bit of a simplification, because MacOS doesn't really use the dll filename for matching the library, and there are extreme cases where you can end up with two PythonCore's in one process (but they don't happen to the average user), but this is the general idea.... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From gstein@lyra.org Tue Jul 11 23:03:11 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 15:03:11 -0700 Subject: [Python-Dev] O'Reilly conference In-Reply-To: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jul 11, 2000 at 05:20:38PM -0400 References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <20000711150311.V29590@lyra.org> On Tue, Jul 11, 2000 at 05:20:38PM -0400, Fred L. Drake, Jr. wrote: > > So who's going to the O'Reilly conference next week? The PythonLabs > crew expects to be there, and we just might have some goodies. ;) I'll be there Tue, Wed, Thu. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Ka-Ping Yee Tue Jul 11 23:02:17 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Tue, 11 Jul 2000 15:02:17 -0700 (PDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <14699.33172.319800.354377@bitdiddle.concentric.net> Message-ID: On Tue, 11 Jul 2000, Jeremy Hylton wrote: > If we end up calling this new feature list comprehensions, we might > create the expectation that they behave like list comprehensions in > other languages. Good point. > >[ f x | x <- xs ] [...] > >[ (x,y) | x <- xs, y <- ys ] The closest translations for these i can imagine are [ f(x), for x in xs ] [ (x,y), for x in xs, for y in ys ] I'd say the above has to be about my favourite for ease of reading. I think the following grammar would work: listmaker: test [',' (list_iter | [test (',' test)* [',']])] list_iter: list_for | list_if list_for: 'for' exprlist 'in' testlist [',' list_iter] list_if: 'if' test [',' list_iter] -- ?!ng From paul@prescod.net Tue Jul 11 23:11:29 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 17:11:29 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> Message-ID: <396B9B91.E33D8C58@prescod.net> Thomas Wouters wrote: > > .... They provide an easier way to create a list, but they don't > eradicate the need for map, reduce or filter, because there is no way to > comprehend an already created list. What do you mean? I think I see examples of list comprehensions working on existing lists on this page: http://www.cosc.canterbury.ac.nz/~greg/python/listcomp/ numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] evens = [x for x in numbers if x % 2 == 0] # filter mult3 = [3 * x for x in numbers] # map Reduce is somewhat of a different beast... -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gstein@lyra.org Tue Jul 11 23:29:52 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 15:29:52 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.38892.155046.60218@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Jul 11, 2000 at 05:55:56PM -0400 References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> <14699.38892.155046.60218@anthem.concentric.net> Message-ID: <20000711152951.X29590@lyra.org> On Tue, Jul 11, 2000 at 05:55:56PM -0400, Barry A. Warsaw wrote: > > >>>>> "Gordo" == Gordon McMillan writes: > > Gordo> I'm with Barry here (despite the public humiliation the > Gordo> association involves). > > For both of us, of course. :) Looks like all of us scrappy long-hairs are in this together. :-) As I posted in another note: this stuff introduces too much confusion and unknowns, for a small benefit. Create parallel() or product() or whatever to munge the lists. Not new syntax. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Tue Jul 11 23:30:46 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 15:30:46 -0700 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <20000711215517.E9C71E2673@oratrix.oratrix.nl>; from jack@oratrix.nl on Tue, Jul 11, 2000 at 11:55:12PM +0200 References: <20000711215517.E9C71E2673@oratrix.oratrix.nl> Message-ID: <20000711153046.Y29590@lyra.org> On Tue, Jul 11, 2000 at 11:55:12PM +0200, Jack Jansen wrote: > Excuse my ignorance, but isn't the whole problem that the python 1.6 > DLL is in the system search path even when you are running Python 1.7? Yes, and as has been discussed endlessly before: it needs to be there. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one@email.msn.com Tue Jul 11 23:26:12 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 11 Jul 2000 18:26:12 -0400 Subject: [Python-Dev] patch assignments? In-Reply-To: <14699.23439.483525.515059@beluga.mojam.com> Message-ID: [Skip Montanaro] > I just noticed a patch assignment made to me on June 30th: > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100688&group_id=5470 > > with a comment from Tim on July 10th about it having been assigned to me. Correction: My comment was made on July 9th, which is also the day it got assigned to you (look at the topmost line of the Patch History section at the bottom). This is one of those patches that had just sat there since June 30th without anyone picking it up. On July 9th I went thru those and assigned (most of) them "at random". > In the flood of patch submissions and updates I guess I missed > this. Na, you noticed it within 48 hours > > The SF patch change mails say *nothing* as far as I can tell about what > the nature of the change of status of a patch is. That's right. It sucks. Best clue is whether you're *explicitly* listed on the "To" line. > With all changes going through the patches mailing list, more interesting > stuff can get lost in the sea of stuff I'm not particularly interested in. > Consequently, I would have hit 'd' seeing a subject like "Add 'isatty(fd)' > to posixmodule". I hit 'd' (well, my mailer's equivalent) for almost all patch mail coming from SF. Feel free to do the same! What I suggest instead: if you're a Python developer on SF, patches *will* eventually get assigned to you. So log on at least once a week, and view the patches filtering on your "Unix name" via the "User" dropdown list. Then you'll know exactly what's on your plate. And if you're not going to do it, take yourself off. Do the latter too often, though, and you'll probably get threatening email from Guido . > Has anyone asked SF for a more complete patch mailing? Dunno, but there's some hope we can discuss this w/ them in person in CA next week. The SF patch manager has more problems than just that for a project with as many active developers as Python. > If not, I will probably unsubscribe from patches@python.org so I can be > assured that those notices I get are actually for me. I wouldn't hold my breath waiting for large changes to SF's software. From jack@oratrix.nl Tue Jul 11 23:30:57 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 00:30:57 +0200 Subject: [Python-Dev] More Symantec symbols In-Reply-To: Message by Skip Montanaro , Mon, 10 Jul 2000 21:48:42 -0500 (CDT) , <14698.35594.999203.707698@beluga.mojam.com> Message-ID: <20000711223102.84CA0E2673@oratrix.oratrix.nl> Recently, Skip Montanaro said: > > Picking up where the __SC__ thread left off, I noticed the following other > Symantec symbols in the Python sources just now: > > ./Include/Python.h:48:#ifdef SYMANTEC__CFM68K__ > [...] > Should these be zapped as well or is this something wholely unrelated to the > old Symantec compiler issue? Yes, go ahead and zap them. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paul@prescod.net Tue Jul 11 23:48:05 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 17:48:05 -0500 Subject: [Python-Dev] list comprehensions again... References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> <14699.38892.155046.60218@anthem.concentric.net> <20000711152951.X29590@lyra.org> Message-ID: <396BA425.2EF3B11F@prescod.net> Greg Stein wrote: > > Looks like all of us scrappy long-hairs are in this together. :-) > > As I posted in another note: this stuff introduces too much confusion and > unknowns, for a small benefit. Create parallel() or product() or whatever to > munge the lists. Not new syntax. Parallel iteration and list comprehensions are separate. I do prefer a parallel() (merge?) builtin to the semicolon syntax, myself. You could even define xparallel which is the lazy version (as in xrange). There's no way you are going to invent functions that do everything that list comprehensions do, however. And compared to map and filter, list comprehensions are positively crystal clear. Would it help to think of list comprehensions not so much as a vote for a new idea as a vote AGAINST lambda, map and filter? numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] mult3 = [3 * x for x in numbers] evens = [x for x in numbers if x % 2 == 0] numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] mult3 = map( lambda x: 3 * x, numbers) evens = filter( lambda x: x%2==0, numbers) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From bwarsaw@beopen.com Wed Jul 12 00:02:06 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 19:02:06 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> Message-ID: <14699.42862.320480.372351@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> I agree that all this together looks dodgy, but I think there TW> is a simple way to view it... I still think TW> 'for x in a; y in b:' TW> is the right syntax for parallel for loops. It's almost "only" TW> syntactic sugar for TW> 'for x,y in map(None, a, b)' But wouldn't some variation on for x, y in a, b: invoke resonance with the classic idiom? Okay, now I'm reduced to arguing syntax (and syntax which I haven't thought out much :). TW> but it's fairly straightforward, and in large blocks of code TW> it might look a lot better. It also has the benifit of not TW> padding the shortest list to the size of the longest one: TW> getting that behaviour with a map requires an aditional TW> 'filter' or such. So I guess if that's the behavior I want, I'd use map, right? There's probably no good way to spell both. -Barry From Vladimir.Marangozov@inrialpes.fr Wed Jul 12 00:35:54 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 01:35:54 +0200 (CEST) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.18899.148734.462266@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jul 11, 2000 12:22:43 PM Message-ID: <200007112335.BAA23181@python.inrialpes.fr> Fred L. Drake, Jr. wrote: > > I've attached a combined patch, in case any is interested. This > does not include updated documentation, and could use additional > tests. +1. Go ahaid. I'd make TabError -> TabSpaceError (like the C preprocessor symbol) though. > + static char > + TabError__doc__[] = "Improper mixture of spaces and tabs."; TabSpaceError__doc__[] = "Improper mixture of tabs and spaces."; -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein@lyra.org Wed Jul 12 00:54:06 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 16:54:06 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.42862.320480.372351@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Jul 11, 2000 at 07:02:06PM -0400 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> <14699.42862.320480.372351@anthem.concentric.net> Message-ID: <20000711165406.A29590@lyra.org> On Tue, Jul 11, 2000 at 07:02:06PM -0400, Barry A. Warsaw wrote: > > >>>>> "TW" == Thomas Wouters writes: > > TW> I agree that all this together looks dodgy, but I think there > TW> is a simple way to view it... I still think > > TW> 'for x in a; y in b:' > > TW> is the right syntax for parallel for loops. It's almost "only" > TW> syntactic sugar for > > TW> 'for x,y in map(None, a, b)' > > But wouldn't some variation on > > for x, y in a, b: > > invoke resonance with the classic idiom? Okay, now I'm reduced to > arguing syntax (and syntax which I haven't thought out much :). for x, y in a, b: won't work. "a, b" is a tuple constructor. The for-loop will iterate over a two-item tuple, and unpack each item (a and b) into the x,y variables. Try again or punt :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From skip@mojam.com (Skip Montanaro) Tue Jul 11 23:28:04 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 11 Jul 2000 17:28:04 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.31592.410628.754071@anthem.concentric.net> References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> Message-ID: <14699.40820.255217.346654@beluga.mojam.com> BAW> Range literals I can see as being worth it. I wonder if parallel BAW> for loops can't be handled more gracefully with a function -- isn't BAW> it just a nice wrapper around a specific call to map() anyway? I believe Thomas proposed range literals to avoid calling the range() function... Regarding a wrapper around map(), you will need a pretty hairy wrapper, since you can do some pretty complex things with Greg's version of list comprehensions. Here's the list comprehensions code from test_grammar.py: nums = [1, 2, 3, 4, 5] strs = ["Apple", "Banana", "Coconut"] spcs = [" Apple", " Banana ", "Coco nut "] print [s.strip() for s in spcs] print [3 * x for x in nums] print [x for x in nums if x > 2] print [i, s for i in nums for s in strs] print [i, s for i in nums for s in [f for f in strs if "n" in f]] suppliers = [ (1, "Boeing"), (2, "Ford"), (3, "Macdonalds") ] parts = [ (10, "Airliner"), (20, "Engine"), (30, "Cheeseburger") ] suppart = [ (1, 10), (1, 20), (2, 20), (3, 30) ] print [ (sname, pname) for (sno, sname) in suppliers for (pno, pname) in parts for (sp_sno, sp_pno) in suppart if sno == sp_sno and pno == sp_pno ] and what it produces: ['Apple', 'Banana', 'Coco nut'] [3, 6, 9, 12, 15] [3, 4, 5] [(1, 'Apple'), (1, 'Banana'), (1, 'Coconut'), (2, 'Apple'), (2, 'Banana'), (2, 'Coconut'), (3, 'Apple'), (3, 'Banana'), (3, 'Coconut'), (4, 'Apple'), (4, 'Banana'), (4, 'Coconut'), (5, 'Apple'), (5, 'Banana'), (5, 'Coconut')] [(1, 'Banana'), (1, 'Coconut'), (2, 'Banana'), (2, 'Coconut'), (3, 'Banana'), (3, 'Coconut'), (4, 'Banana'), (4, 'Coconut'), (5, 'Banana'), (5, 'Coconut')] [('Boeing', 'Airliner'), ('Boeing', 'Engine'), ('Ford', 'Engine'), ('Macdonalds', 'Cheeseburger')] Here's my equivalent code: 1. map(string.strip, spcs) 2. newnums = [] for n in nums: newnums.append(3*n) return newnums 3. newnums = [] for n in nums: if n > 2: newnums.append(n) return newnums 4. l = [] for i in nums: for s in strs: l.append((i,s)) return l 5. l = [] fl = [] for f in strs: if "n" in f: fl.append(f) for i in nums: for s in fl: l.append((i,s)) return l 6. ... the join is left as an exercise for the reader ... ;-) It seems like fairly powerful stuff and generally tends to reduce the amount of code the user writes. Is it more or less understandable than the current alternatives? That's the $64K question. I think in most cases it is. I think map and filter are more difficult to use and understand than the example list comprehensions from the test suite, but perhaps that's just my bias. I was never much of a Lisper, so it took me a good year or two before I got comfortable with anything more than the simplest uses of map. I probably still can't locate more than two or three instances in my own code where I've used filter. The nested for loops like the fourth and fifth examples seem to stretch out vertically and require the use of temporary variables that add complexity to the constructs. Skip From skip@mojam.com (Skip Montanaro) Tue Jul 11 23:30:43 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 11 Jul 2000 17:30:43 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.42862.320480.372351@anthem.concentric.net> References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> <14699.42862.320480.372351@anthem.concentric.net> Message-ID: <14699.40979.693147.384500@beluga.mojam.com> BAW> So I guess if that's the behavior I want, I'd use map, right? BAW> There's probably no good way to spell both. Yes, but you probably map() and filter() in your sleep with your Lisp experience... ;-) S From pingster@ilm.com Wed Jul 12 01:01:24 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 17:01:24 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711165406.A29590@lyra.org> Message-ID: On Tue, 11 Jul 2000, Greg Stein wrote: > On Tue, Jul 11, 2000 at 07:02:06PM -0400, Barry A. Warsaw wrote: [...] > > But wouldn't some variation on > > > > for x, y in a, b: > > > > invoke resonance with the classic idiom? Okay, now I'm reduced to > > arguing syntax (and syntax which I haven't thought out much :). > > for x, y in a, b: > > won't work. "a, b" is a tuple constructor. The for-loop will iterate over a > two-item tuple, and unpack each item (a and b) into the x,y variables. That's why i suggested the above, with semicolons instead of commas. Other ideas for a separator symbol are welcomed... but i think the semicolon may be the only reasonable option left. -- ?!ng "We're going to turn this team around 360 degrees." -- Jason Kidd, upon being drafted by the Dallas Mavericks From skip@mojam.com (Skip Montanaro) Tue Jul 11 23:36:32 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 11 Jul 2000 17:36:32 -0500 (CDT) Subject: [Python-Dev] O'Reilly conference In-Reply-To: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <14699.41328.521867.559541@beluga.mojam.com> Fred> So who's going to the O'Reilly conference next week? The Fred> PythonLabs crew expects to be there, and we just might have some Fred> goodies. ;) I wish I had known about it sooner (or realized the confluence of different streams in my life). Turns out I'm in San Francisco this week... Skip From Vladimir.Marangozov@inrialpes.fr Wed Jul 12 01:11:06 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 02:11:06 +0200 (CEST) Subject: [Python-Dev] Memory leak tracking In-Reply-To: <14699.30119.262274.258429@anthem.concentric.net> from "Barry A. Warsaw" at Jul 11, 2000 03:29:43 PM Message-ID: <200007120011.CAA23273@python.inrialpes.fr> Barry A. Warsaw wrote: > > How important is it to fix these problems when gc is disabled? > ... > Please let me know what you think. If the concensus is to fix them, I > keep working on them. I do still plan on looking at the few memory > problems still left even with gc turned on. I think that if we start relaxing our attention w.r.t. refcount policies, cyclic refs and the resulting mem leaks _in_the_core_, just because gc helps in hiding bad practice, we'll suffer more than you would in the attempt to fix these things. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein@lyra.org Wed Jul 12 01:09:31 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 17:09:31 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from pingster@ilm.com on Tue, Jul 11, 2000 at 05:01:24PM -0700 References: <20000711165406.A29590@lyra.org> Message-ID: <20000711170930.E29590@lyra.org> On Tue, Jul 11, 2000 at 05:01:24PM -0700, Ka-Ping Yee wrote: > On Tue, 11 Jul 2000, Greg Stein wrote: > > On Tue, Jul 11, 2000 at 07:02:06PM -0400, Barry A. Warsaw wrote: > [...] > > > But wouldn't some variation on > > > > > > for x, y in a, b: > > > > > > invoke resonance with the classic idiom? Okay, now I'm reduced to > > > arguing syntax (and syntax which I haven't thought out much :). > > > > for x, y in a, b: > > > > won't work. "a, b" is a tuple constructor. The for-loop will iterate over a > > two-item tuple, and unpack each item (a and b) into the x,y variables. > > That's why i suggested the above, with semicolons instead of commas. > Other ideas for a separator symbol are welcomed... but i think the > semicolon may be the only reasonable option left. hehe... I have another "reasonable option" :-) -- Greg Stein, http://www.lyra.org/ From nascheme@enme.ucalgary.ca Wed Jul 12 01:13:52 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 11 Jul 2000 18:13:52 -0600 Subject: [Python-Dev] Memory leak tracking In-Reply-To: <200007120011.CAA23273@python.inrialpes.fr>; from Vladimir Marangozov on Wed, Jul 12, 2000 at 02:11:06AM +0200 References: <14699.30119.262274.258429@anthem.concentric.net> <200007120011.CAA23273@python.inrialpes.fr> Message-ID: <20000711181352.A13655@keymaster.enme.ucalgary.ca> Perhaps gc.set_debug(gc.DEBUG_LEAK) would be helpful. Yes, real docs are coming. :) Neil From bwarsaw@beopen.com Wed Jul 12 01:20:44 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 20:20:44 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> <14699.38892.155046.60218@anthem.concentric.net> <20000711152951.X29590@lyra.org> <396BA425.2EF3B11F@prescod.net> Message-ID: <14699.47580.918825.55340@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Would it help to think of list comprehensions not so much as a PP> vote for a new idea as a vote AGAINST lambda, map and filter? If you mean specifically map/filter with lambda, yes. But map/filter with are pretty straightforward I think. It's the lambda that's confusing. -Barry From Vladimir.Marangozov@inrialpes.fr Wed Jul 12 01:26:07 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 02:26:07 +0200 (CEST) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 11, 2000 03:03:12 PM Message-ID: <200007120026.CAA23349@python.inrialpes.fr> Guido van Rossum wrote: > > What do you think the following code would print? May I answer this? :-) > > for i in (10, 20, 30); j in (1, 2, 3): > print i+j > > A. > > 11 > 22 > 33 > > B. > 11 > 12 > 13 > 21 > 22 > 23 > 31 > 32 > 33 > > I'm afraid the answer will be the same, if these are again numerical > analysts -- these people live by nested DO loops. :-( Without being a numerical analyst, I would respond B. That's what this syntax suggests to me. Someone proposed `for ... while ...' which clearly suggests something different than nested loops, and in that case, if I don't know what it is, I'll read the docs. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From skip@mojam.com (Skip Montanaro) Tue Jul 11 23:57:25 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 11 Jul 2000 17:57:25 -0500 (CDT) Subject: [Python-Dev] os.path.commonprefix testers needed for DOS, NT and Mac Message-ID: <14699.42581.843754.542783@beluga.mojam.com> Those of you with DOS, Windows/NT or Mac boxes, please take a look at the following patch: https://sourceforge.net/patch/?func=detailpatch&patch_id=100788&group_id=5470 It fixes posixpath.commonprefix to chunk its input by path components instead of by characters, so the prefix it returns should be a valid path. I can only check on Linux (I sort of expect other Unix variants will work as well). I corrected ntpath.py (which was the same as the version in posixpath.py) and added it to dospath.py and macpath.py. I can't really test any of them. Would those of you who can, please try it out and get back to me with a "yea" or a "nay" (with corrections, if possible)? Thanks, -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From paul@prescod.net Wed Jul 12 01:35:13 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 19:35:13 -0500 Subject: [Python-Dev] list comprehensions again... References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> <14699.38892.155046.60218@anthem.concentric.net> <20000711152951.X29590@lyra.org> <396BA425.2EF3B11F@prescod.net> <14699.47580.918825.55340@anthem.concentric.net> Message-ID: <396BBD41.A68E4477@prescod.net> "Barry A. Warsaw" wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> Would it help to think of list comprehensions not so much as a > PP> vote for a new idea as a vote AGAINST lambda, map and filter? > > If you mean specifically map/filter with lambda, yes. But map/filter > with are pretty straightforward I think. It's the lambda that's > confusing. Okay, but at least half of the time I want to use map/filter I want to do: map( lambda x: x.foo(), lst ) Python is an OO-ish language after all! Anyhow, with list comprehensions we could dump map/filter and probably lambda. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Wed Jul 12 01:44:10 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 19:44:10 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> Message-ID: <396BBF5A.B22837C@prescod.net> Thomas Wouters wrote: > > ... > > Well, not really. It doesn't create a new list, only a tuple to hold lists > to iter over (in order to pass it to the opcode as a single PyObject) and > similar for the resulting objects. It's definately more efficient than the > map() solution (and different, see below ;) Nevertheless, I think it is worth asking whether a parallel() or merge() function can do the same thing. It's not like the semicolon syntax screams out the right answer. The parallel function could return an iteratable object that generates tuples on demand. A function can be used in contexts other than a for loop. If we make functions like parallel and range not only builtin but non-overridable, we can do all sorts of optimizations in the bytecode compiler (and other compilers). In other words we can "inline" them when they are used in simple contexts. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gstein@lyra.org Wed Jul 12 01:50:56 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 17:50:56 -0700 Subject: [Python-Dev] Memory leak tracking In-Reply-To: <200007120011.CAA23273@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Wed, Jul 12, 2000 at 02:11:06AM +0200 References: <14699.30119.262274.258429@anthem.concentric.net> <200007120011.CAA23273@python.inrialpes.fr> Message-ID: <20000711175056.I29590@lyra.org> On Wed, Jul 12, 2000 at 02:11:06AM +0200, Vladimir Marangozov wrote: > Barry A. Warsaw wrote: > > > > How important is it to fix these problems when gc is disabled? > > ... > > Please let me know what you think. If the concensus is to fix them, I > > keep working on them. I do still plan on looking at the few memory > > problems still left even with gc turned on. > > I think that if we start relaxing our attention w.r.t. refcount policies, > cyclic refs and the resulting mem leaks _in_the_core_, just because gc > helps in hiding bad practice, we'll suffer more than you would in the > attempt to fix these things. Agreed. The core should never create refcount problems. With or without GC, that is just bad policy. Cheers, -g -- Greg Stein, http://www.lyra.org/ From pingster@ilm.com Wed Jul 12 01:47:00 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 17:47:00 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396BBD41.A68E4477@prescod.net> Message-ID: On Tue, 11 Jul 2000, Paul Prescod wrote: > > map( lambda x: x.foo(), lst ) > > Python is an OO-ish language after all! Anyhow, with list comprehensions > we could dump map/filter and probably lambda. Yeah, that would be quite nice. [x.foo(), for x in lst] What beauty! -- ?!ng From petrilli@amber.org Wed Jul 12 01:57:37 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Tue, 11 Jul 2000 20:57:37 -0400 Subject: [Python-Dev] O'Reilly conference In-Reply-To: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jul 11, 2000 at 05:20:38PM -0400 References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <20000711205737.A20771@trump.amber.org> Fred L. Drake, Jr. [fdrake@beopen.com] wrote: > > So who's going to the O'Reilly conference next week? The PythonLabs > crew expects to be there, and we just might have some goodies. ;) A good number of the Digicool people will be there, including: - Me, and who else really matters, ya' know? :-) - Jim Fulton - Paul Everitt - Gary Graham And I think one or two other people are going :-) Chris -- | Christopher Petrilli | petrilli@amber.org From Ka-Ping Yee Wed Jul 12 02:05:10 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Tue, 11 Jul 2000 18:05:10 -0700 (PDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396BA425.2EF3B11F@prescod.net> Message-ID: On Tue, 11 Jul 2000, Paul Prescod wrote: > > Parallel iteration and list comprehensions are separate. I do prefer a > parallel() (merge?) builtin to the semicolon syntax, myself. You could > even define xparallel which is the lazy version (as in xrange). I like this idea. This whole parallel iteration thing could be solved with a single built-in and no syntax changes. for x, y in parallel([10, 20, 30], [1, 2]): Or "zip", since you're zipping the lists together (i foresee potential geometric or concurrency-related interpretations of "parallel"): for x, y in zip([10, 20, 30], [1, 2]): [(x, y+z), for (x, y) in zip((1, 2, 3, 4, 5, 6), "abc"), for z in "de"] Taking this all together provides one coherent solution: - zip() built-in produces a lazy list-zipper object - list-comps are written [, , , ...] where each is "for x in y" or "if z" Advantages: - no semicolons; semicolons remain solely statement separators - no possible confusion between parallel and nested iteration - comma remains the top-level separator within lists, so grouping of list-comp clauses is clear - dict-comp is possible and straightforward if we really want it - looks much prettier than map/lambda :) How's that for a serious proposal? -- ?!ng From akuchlin@mems-exchange.org Wed Jul 12 02:29:23 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 11 Jul 2000 21:29:23 -0400 Subject: [Python-Dev] O'Reilly conference In-Reply-To: <14699.41328.521867.559541@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 11, 2000 at 05:36:32PM -0500 References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> <14699.41328.521867.559541@beluga.mojam.com> Message-ID: <20000711212923.A15998@newcnri.cnri.reston.va.us> On a related note, is anyone else from python-dev going to be going to the Ottawa Linux Symposium nex week? --amk From gmcm@hypernet.com Wed Jul 12 02:58:02 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 11 Jul 2000 21:58:02 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396B8868.B58F3F0C@prescod.net> Message-ID: <1248755410-33702453@hypernet.com> Paul Prescod wrote: > Nested (List): > > [for x in (0,10,20,30): > for y in (0,1,2,3): > x+y] > [0,11,22,33] Not what I'd expect at all. - Gordon From gmcm@hypernet.com Wed Jul 12 02:58:02 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 11 Jul 2000 21:58:02 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: References: <20000711165406.A29590@lyra.org> Message-ID: <1248755408-33702560@hypernet.com> Ka-Ping Yee wrote: > On Tue, 11 Jul 2000, Greg Stein wrote: > > for x, y in a, b: > > > > won't work. "a, b" is a tuple constructor. The for-loop will > > iterate over a two-item tuple, and unpack each item (a and b) > > into the x,y variables. > > That's why i suggested the above, with semicolons instead of > commas. Other ideas for a separator symbol are welcomed... but i > think the semicolon may be the only reasonable option left. for x, y in a, b: for x, y in a; b: speechless-ly y'rs - Gordon From gmcm@hypernet.com Wed Jul 12 02:58:02 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 11 Jul 2000 21:58:02 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396BBD41.A68E4477@prescod.net> Message-ID: <1248755407-33702623@hypernet.com> Paul Prescod wrote: > Python is an OO-ish language after all! Anyhow, with list > comprehensions we could dump map/filter and probably lambda. I see more lambdas used in Tkinter code than anywhere else. Not a list in sight. - Gordon From esr@thyrsus.com Wed Jul 12 03:44:01 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Tue, 11 Jul 2000 22:44:01 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: References: <200007111440.JAA05205@cj20424-a.reston1.va.home.com> Message-ID: <20000711224401.A1107@thyrsus.com> Greg Wilson : > > Side note: the suggested syntax here (for i in seq1 for j in seq2) > > looks like a potential alternative for the currently proposed parallel > > for loop syntax (for i in seq1; j in seq2). > > > > Only problem: the for-for variant could be mistaken by someone used to > > see nested loops as meaning the same as > > > > for i in seq1: > > for j in seq2: ... > > Until yesterday's posting, I assumed that this is what for-for loops would > do, i.e. that they'd deliver a cross-product rather than one-from-each. This seems like the natural interpretation to me, also. I therefore prefer the semicolon sequence. -- Eric S. Raymond To stay young requires the unceasing cultivation of the ability to unlearn old falsehoods. -- Lazarus Long From esr@thyrsus.com Wed Jul 12 04:17:51 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Tue, 11 Jul 2000 23:17:51 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.12489.875905.520781@beluga.mojam.com> References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> <200007111440.JAA05205@cj20424-a.reston1.va.home.com> <14699.12489.875905.520781@beluga.mojam.com> Message-ID: <20000711231751.A1265@thyrsus.com> Skip Montanaro : > > Guido> [(x,y) for x in (1,2,3) for y in (4,5,6)] > Guido> Would it be really bad if we forced them to write it that way? > > For that matter, perhaps requiring parens for all tuple definitions in Py3k > wouldn't be a bad idea. +1. IMO, naked tuples assignments are Perlish -- initially cute, but confusing. Syntactic junk food. -- Eric S. Raymond The common argument that crime is caused by poverty is a kind of slander on the poor. -- H. L. Mencken From tim_one@email.msn.com Wed Jul 12 03:59:41 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 11 Jul 2000 22:59:41 -0400 Subject: [Python-Dev] Windows build broken in exceptions.c Message-ID: exceptions.c(93) : error C2026: string too big, trailing characters truncated Error executing cl.exe. The platform (MSVC6) docs for C2026: After adjacent strings are concatenated, a string cannot be longer than 2048 characters. However, those docs aren't accurate: if I break the giant docstring into two pieces, like so (implicitly concatenated): "sub-giant piece one" "sub-giant piece two" everything is fine. The compiler only gripes about a single string literal > 2K. I guessed that might be true because it seems more of a "catch runaway string" gimmick than a reasonable compiler limit. Anyway, I hesitate to check in that MSVC6 workaround if the same problem is just going to crop up on other platforms. Has it popped up for anyone else? One alternative is to keep strings short and paste them together at runtime in the module init fnc. From greg@cosc.canterbury.ac.nz Wed Jul 12 04:02:09 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 12 Jul 2000 15:02:09 +1200 (NZST) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711192202.B7340@xs4all.nl> Message-ID: <200007120302.PAA06664@s454.cosc.canterbury.ac.nz> Thomas Wouters wrote: > But the syntax is pretty ambiguous, and not > too pythonic at that. For instance, the endless mixing possibilities of > 'for' and 'if' without delimiters or ways to group them can be pretty > confusing. I don't think it's so confusing if you think about LCs the right way. You're meant to be able to think of them as a declarative construct, e.g. [(x, y) for x in a for y in b if y > 3] means "a list of all tuples (x, y) such that x is in a and y is in b and y > 3". Assuming no side effects, the result doesn't depend on what order the loops and tests are nested in, so (unless you're concerned about speed) you don't need to think in terms of loops at all, just a set of conditions. The syntax I chose was the most pythonic one I could think of that worked. It would probably look better with some sort of separator, but I wouldn't like to use anything stronger than a comma (semicolons inside a statement just don't look right to me), which means something like [(x, y) for x in a, for y in b, if y > 3] But then it looks a bit redundant having to repeat the 'for' each time, so you'd really want it to be more like [(x, y) for x in a, y in b, y > 3] which is hopelessly ambiguous. So I gave up on commas altogether. > it would be nice if list comprehensions could be used to initialize > *part* of a list, It would, but would the greatly increased implementation complexity be worth it? (And don't forget to allow range-literals the same privilege!-) > Can we get away with not including the nested-for syntax? I'd be really disappointed if LCs only made it in in such an emasculated form. It would remove a huge amount of their power, and I would have serious doubts that what was left would be worth bothering with. Heavens, next thing you know, someone will suggest adding a lambda without nested scoping... :-) > parallel-for-loops -> list comprehensions -> range-literals That's sensible, but I wouldn't like to see LCs get held up waiting for a consensus on PFLs to emerge. I think that if we just make sure that LCs and normal FLs share the same piece of compiler code, whatever is done to FLs later will get inherited by LCs automatically... sort of... Concerning PFLs, it seems to me that earlier language design decisions have pretty well scuttled any hope of coming up with a natural-looking and compatible PFL syntax. So we're going to have to settle for (a) an incompatible one, (b) an unnatural looking one, or (c) none at all. In category (b), my suggestion of the day is: for {var, ...} in expr e.g. for {x, y} in a, b Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From Vladimir.Marangozov@inrialpes.fr Wed Jul 12 04:11:12 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 05:11:12 +0200 (CEST) Subject: [Python-Dev] Include/pyport.h now exists In-Reply-To: <20000708212149.P26534@xs4all.nl> from "Thomas Wouters" at Jul 08, 2000 09:21:50 PM Message-ID: <200007120311.FAA10295@python.inrialpes.fr> Thomas Wouters wrote: > > [Tim] > > Would someone who understands (& can test! I can't yet) autoconfig please > > follow up on the last part? The stuff I checked in "fails safe", i.e. the > > lack of autoconfig support should not cause problems on any of your > > platforms. > > Can't say I understand all of autoconf but I read enough of the info pages > to be able to do this ! :-) I couldn't find an existing test that covers > this, so I used your example to make one; patch attached. It detects my > linux box properly as 'doesn't zero-fill when right-shifting a negative > number', but I haven't a Cray J90 handy to test the opposite ;) > > Feel free to change the wording to something a bit less... wordy, though ;) > Oh, and don't forget to run autoheader & automake before checking in. I've checked this in, but I haven't figured out whether and how I could assign an open (non assigned) patch to myself and close it. If I am missing something, please let me know. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw@beopen.com Wed Jul 12 04:23:00 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 23:23:00 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> Message-ID: <14699.58516.791911.405213@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: BAW> Range literals I can see as being worth it. I wonder if BAW> parallel for loops can't be handled more gracefully with a BAW> function -- isn't it just a nice wrapper around a specific BAW> call to map() anyway? SM> I believe Thomas proposed range literals to avoid calling the SM> range() function... Right, and that seems totally cool to me. Simple syntax, clear semantics. SM> Regarding a wrapper around map(), you will need a pretty hairy SM> wrapper, since you can do some pretty complex things with SM> Greg's version of list comprehensions. I meant the parallel for loops as a shortcut for map(). List comprehensions do seem more powerful, however: | print [s.strip() for s in spcs] | print [3 * x for x in nums] Cool so far. | print [x for x in nums if x > 2] Uh oh, starting to look like Perl... | print [i, s for i in nums for s in strs] | print [i, s for i in nums for s in [f for f in strs if "n" in f]] Yow! No one will accuse Python of only having one way to do it anymore! Even without the curse-word-symbols, I fear excessive scalp exposing head-scratching when I see this in code. -Barry From bwarsaw@beopen.com Wed Jul 12 04:25:01 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 23:25:01 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <20000711165406.A29590@lyra.org> Message-ID: <14699.58637.724595.543978@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> That's why i suggested the above, with semicolons instead of KY> commas. Other ideas for a separator symbol are KY> welcomed... but i think the semicolon may be the only KY> reasonable option left. vertical bar? From jeremy@beopen.com Wed Jul 12 04:29:36 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 23:29:36 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.58516.791911.405213@anthem.concentric.net> References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> Message-ID: <14699.58912.789947.837917@bitdiddle.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: BAW> | print [i, s for i in nums for s in strs] BAW> | print [i, s for i in nums for s in [f for f in strs if "n" in f]] BAW> Yow! No one will accuse Python of only having one way to do it BAW> anymore! Even without the curse-word-symbols, I fear excessive BAW> scalp exposing head-scratching when I see this in code. I think these examples demonstrate the need for some punctuation, though perhaps not curse-word-symbols. I really like the vertical bar that Haskell uses to separate the variables being assigned to from the generator expression. It's a very familiar notation from mathematics. There also needs to be some punctuation to separate each generator expression when there is more than one. Commas and semicolons both seem reasonable viewed in isolation; commas are problematic because they are already used for tuple creation. Jeremy From akuchlin@mems-exchange.org Wed Jul 12 04:29:04 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 11 Jul 2000 23:29:04 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.58516.791911.405213@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Jul 11, 2000 at 11:23:00PM -0400 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> Message-ID: <20000711232904.A16338@newcnri.cnri.reston.va.us> On Tue, Jul 11, 2000 at 11:23:00PM -0400, Barry A. Warsaw wrote: >Yow! No one will accuse Python of only having one way to do it >anymore! Even without the curse-word-symbols, I fear excessive scalp >exposing head-scratching when I see this in code. Agreed; unless some clearer phrasing emerges, I'll vote -1 on list comprehensions, since they offer too much potential for obfuscation. --amk From bwarsaw@beopen.com Wed Jul 12 04:32:41 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 23:32:41 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> <396BBF5A.B22837C@prescod.net> Message-ID: <14699.59097.346202.496529@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Nevertheless, I think it is worth asking whether a parallel() PP> or merge() function can do the same thing. It's not like the PP> semicolon syntax screams out the right answer. The parallel PP> function could return an iteratable object that generates PP> tuples on demand. A function can be used in contexts other PP> than a for loop. Right. I think I'm beginning to like an explicit function (builtin or not) better than the syntax change. -Barry From gvwilson@nevex.com Wed Jul 12 04:33:51 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 23:33:51 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711234737.D7340@xs4all.nl> Message-ID: > Thomas Wouters wrote: > I still think > > 'for x in a; y in b:' > > is the right syntax for parallel for loops. It's almost "only" > syntactic sugar for > > 'for x,y in map(None, a, b)' > > but it's fairly straightforward, and in large blocks of code it might > look a lot better. Is there a built-in function in Python to combine sequences elementwise? If I can write: for x,y in pairwise(a, b): foo(x,y) and if the compiler is smart enough to avoid actually constructing the pairwise list, then perhaps new syntax is unnecessary? > Given that you can already do the nested-for-loop with a nested for > loop, and it doesn't suffer (much) in way of readability or pythonity, > I think most people will realize that the parallel for loop does > actually do a parallel for-each. I disagree. That doesn't mean people can't be taught/won't remember that multi-loops are executed in step, rather that by cross product, but I believe most people will guess wrong the first time they see the current notation. Thanks, Greg From fdrake@beopen.com Wed Jul 12 04:41:59 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 23:41:59 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure.in,1.134,1.135 In-Reply-To: <200007120302.UAA13467@slayer.i.sourceforge.net> References: <200007120302.UAA13467@slayer.i.sourceforge.net> Message-ID: <14699.59655.736149.252369@cj42289-a.reston1.va.home.com> Vladimir Marangozov writes: > Closes patch #100832 > (but I can't assign it to myself, nor close it -- sorry) Vladimir, I just checked your permissions for the patch manager, and everything is enabled. You should just be able to set the status and assignment in the pull-down menus at the top of the form, and the values are updated when you click on "Submit Changes" at the bottom of the page. Did this not work for you, or was it not clear that that's the way to do it? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw@beopen.com Wed Jul 12 04:44:47 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 23:44:47 -0400 (EDT) Subject: [Python-Dev] zip() and list-comprehension with commas References: <396BA425.2EF3B11F@prescod.net> Message-ID: <14699.59823.710880.896491@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> I like this idea. This whole parallel iteration thing could KY> be solved with a single built-in and no syntax changes. KY> for x, y in parallel([10, 20, 30], [1, 2]): KY> Or "zip", since you're zipping the lists together (i foresee KY> potential geometric or concurrency-related interpretations of KY> "parallel"): Definitely +1 on concept. The nice bit is that parallel() or zip() can return objects that iterate efficiently. -0 on zip(), +0 on parallel(), +0 on making them builtins. Alternatives (as Greg I think brought up): pairwise(), maybe zipper() for zip() since it's more evocative. -Barry From Vladimir.Marangozov@inrialpes.fr Wed Jul 12 04:53:30 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 05:53:30 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure.in,1.134,1.135 In-Reply-To: <14699.59655.736149.252369@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jul 11, 2000 11:41:59 PM Message-ID: <200007120353.FAA25150@python.inrialpes.fr> Fred L. Drake, Jr. wrote: > > Vladimir Marangozov writes: > > Closes patch #100832 > > (but I can't assign it to myself, nor close it -- sorry) > > Vladimir, > I just checked your permissions for the patch manager, and > everything is enabled. You should just be able to set the status and > assignment in the pull-down menus at the top of the form, and the > values are updated when you click on "Submit Changes" at the bottom of > the page. > Did this not work for you, or was it not clear that that's the way > to do it? The latter. Thanks for the clarification. I'll check this out. Besides, I think I screwed the logic of this patch as now I get a "no" answer while it should be "yes" on my combo. So I definitely need to assign this patch to myself and fix it! -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido@beopen.com Wed Jul 12 06:50:27 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 00:50:27 -0500 Subject: [Python-Dev] Memory leak tracking In-Reply-To: Your message of "Tue, 11 Jul 2000 15:29:43 -0400." <14699.30119.262274.258429@anthem.concentric.net> References: <14699.30119.262274.258429@anthem.concentric.net> Message-ID: <200007120550.AAA12465@cj20424-a.reston1.va.home.com> Barry Warsaw: > When I compile out gc, I get more leaks in the core, namely in > exceptions.c. Turning on gc clears all of these up; e.g. all the > memory gets freed eventually. My suspicion therefore is that there > are a number of cycles created during the initialization of the > built-in exceptions. Vladimir Marangozov: > I think that if we start relaxing our attention w.r.t. refcount policies, > cyclic refs and the resulting mem leaks _in_the_core_, just because gc > helps in hiding bad practice, we'll suffer more than you would in the > attempt to fix these things. Let me explain something about the new GC code. It does *not* hide missed DECREFs. If you miss a DECREF, the GC code thinks there's a global pointer to the object that keeps it alive, and will not release the object. I don't know what Barry found, but I suspect they are genuine cycles created during the exception initialization. It's easy enough to create cycles, e.g. form module -> class -> function -> module, or module -> function -> module, when defining classes or functions. The new GC code is *intended* to clean up exactly such cycles! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From bwarsaw@beopen.com Wed Jul 12 06:05:52 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 01:05:52 -0400 (EDT) Subject: [Python-Dev] Memory leak tracking References: <14699.30119.262274.258429@anthem.concentric.net> <200007120550.AAA12465@cj20424-a.reston1.va.home.com> Message-ID: <14699.64688.697935.541901@anthem.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> I don't know what Barry found, but I suspect they are genuine GvR> cycles created during the exception initialization. It's GvR> easy enough to create cycles, e.g. form module -> class -> GvR> function -> module, or module -> function -> module, when GvR> defining classes or functions. GvR> The new GC code is *intended* to clean up exactly such GvR> cycles! I suspect this is exactly what's happening. I'd have to spend more time to know exactly what's happening, but this jives with the observed behavior. If so, the only thing we could do is try to break the cycles manually at shutdown time and have the normal decrefs free all the memory. I'm not sure it's worth the effort. 1) it isn't much memory; 2) it only leaks when gc is disabled; 3) it's a one time cost, not e.g. a leak every time you spawn a thread. That last is interesting, because I believe at least on Solaris, there /is/ a leak for each new thread, but I haven't had time to find it yet. That one's worth tracking down. For the others, it's actually quite nice to see gc doing it's job! Other than that, running the test suite, the current CVS seems to have a very clean bill of health memory usage-wise. -Barry From Moshe Zadka Wed Jul 12 06:22:06 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 12 Jul 2000 08:22:06 +0300 (IDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: Message-ID: On Tue, 11 Jul 2000, Ka-Ping Yee wrote: > On Tue, 11 Jul 2000, Paul Prescod wrote: > > > > Parallel iteration and list comprehensions are separate. I do prefer a > > parallel() (merge?) builtin to the semicolon syntax, myself. You could > > even define xparallel which is the lazy version (as in xrange). > > I like this idea. This whole parallel iteration thing could be solved > with a single built-in and no syntax changes. > > for x, y in parallel([10, 20, 30], [1, 2]): > > Or "zip", since you're zipping the lists together (i foresee potential > geometric or concurrency-related interpretations of "parallel"): +1 on prefering a builtin to a syntax change > for x, y in zip([10, 20, 30], [1, 2]): > > [(x, y+z), for (x, y) in zip((1, 2, 3, 4, 5, 6), "abc"), for z in "de"] +1 on that too...really clear -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Vladimir.Marangozov@inrialpes.fr Wed Jul 12 06:38:13 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 07:38:13 +0200 (CEST) Subject: [Python-Dev] Memory leak tracking In-Reply-To: <200007120550.AAA12465@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 12, 2000 12:50:27 AM Message-ID: <200007120538.HAA23814@python.inrialpes.fr> Guido van Rossum wrote: > > Let me explain something about the new GC code. It does *not* hide > missed DECREFs. If you miss a DECREF, the GC code thinks there's a > global pointer to the object that keeps it alive, and will not release > the object. > Sure. > I don't know what Barry found, but I suspect they are genuine cycles > created during the exception initialization. It's easy enough to > create cycles, e.g. form module -> class -> function -> module, or > module -> function -> module, when defining classes or functions. > > The new GC code is *intended* to clean up exactly such cycles! My point is that it is better not to rely on the GC code for the core if we're not crystal clear when and why cycles are created. And even if we spot them all (and mark these locations in the source), it is always better to try breaking the cycles explicitely. It's a fact that we're not crystal clear where all these cycles are created (be they genuine, easily introduced or not). This is not a good thing and I don't want to support the idea of tolerating this situation. I wish I had Purify to help Barry cleaning this up... -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Moshe Zadka Wed Jul 12 07:00:53 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 12 Jul 2000 09:00:53 +0300 (IDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711231751.A1265@thyrsus.com> Message-ID: On Tue, 11 Jul 2000 esr@thyrsus.com wrote: > Skip Montanaro : > > > > Guido> [(x,y) for x in (1,2,3) for y in (4,5,6)] > > Guido> Would it be really bad if we forced them to write it that way? > > > > For that matter, perhaps requiring parens for all tuple definitions in Py3k > > wouldn't be a bad idea. > > +1. IMO, naked tuples assignments are Perlish -- initially cute, but > confusing. Syntactic junk food. I disagree. That would make the readable def fib(n): a, b = 0, 1 for i in range(n): a, b = b, a+b return a, b old_rabbits, young_rabbits = fib(100) (Ditto for GCD) A mess of parenthesis. Commas build tuples. Parenthesis fix precedence. Never the two shall mix. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Moshe Zadka Wed Jul 12 07:09:11 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 12 Jul 2000 09:09:11 +0300 (IDT) Subject: [Python-Dev] File Object Copy Message-ID: I've found a need for the following function: def copyfile(fin, fout): while 1: buf = fin.read(4096) if not buf: break fout.write(buf) In several different places (modules I've written, SimpleHTTPServer uses it, urllib has that code inlined somewhere, etc.) (Of course, 4096 should be a parameter, but that's nits) Can anyone suggest a module in which this function would belong? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From andy@reportlab.com Wed Jul 12 07:52:05 2000 From: andy@reportlab.com (Andy Robinson) Date: Wed, 12 Jul 2000 07:52:05 +0100 Subject: [Python-Dev] zlib not compiled by default Message-ID: At present, zlib is available in Win32, but users need to uncomment the line in Modules/Setup and recompile on Unix. ReportLab now has 100+ subscribed users in our user group (so I presume at least 5x more users), and we use zlib heavily to compress images and PDF files. It can run without it, but at the expense of bloated output. Are there many other applications which use compression? If so, would it do be feasible to include it by default from version 1.6? Andy Robinson p.s. I can submit a patch if needed :-) From pf@artcom-gmbh.de Wed Jul 12 08:13:32 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Wed, 12 Jul 2000 09:13:32 +0200 (MEST) Subject: [Python-Dev] File Object Copy In-Reply-To: from Moshe Zadka at "Jul 12, 2000 9: 9:11 am" Message-ID: Hi, Moshe Zadka: > I've found a need for the following function: > > def copyfile(fin, fout): > while 1: > buf = fin.read(4096) > if not buf: > break > fout.write(buf) > > In several different places (modules I've written, SimpleHTTPServer uses > it, urllib has that code inlined somewhere, etc.) > > (Of course, 4096 should be a parameter, but that's nits) > > Can anyone suggest a module in which this function would belong? A very similar function lives at a somewhat hidden flat in the third floor of the standard library building. ;-) It is called 'shutil.copyfile'. See '......html/lib/module-shutil.html' for more information. 'shutil.copyfile' however takes filenames as arguments and contains the loop sketched above as inline code. I see two possibilities: 1. It would be easy to skip the open and close operations in 'shutil.copyfile', if either 'src' or 'dst' are already open file objects instead of strings. 2. Or you factor out the copy loop operation above and rename it into 'copycontent' or 'copybytes' or whatever. Regards, Peter From Moshe Zadka Wed Jul 12 08:21:08 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 12 Jul 2000 10:21:08 +0300 (IDT) Subject: [Python-Dev] File Object Copy In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Peter Funk wrote: > 'shutil.copyfile' however takes filenames as arguments and contains > the loop sketched above as inline code. I see two possibilities: > 1. It would be easy to skip the open and close operations in > 'shutil.copyfile', if either 'src' or 'dst' are already open > file objects instead of strings. -0: Too much Perl-like DWIM magic > 2. Or you factor out the copy loop operation above and rename it into > 'copycontent' or 'copybytes' or whatever. Of course it should be factored out: but the question remains, why shell utils? Do you really think copybytes belongs there? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas@xs4all.net Wed Jul 12 08:26:02 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 09:26:02 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure.in,1.134,1.135 In-Reply-To: <200007120353.FAA25150@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Wed, Jul 12, 2000 at 05:53:30AM +0200 References: <14699.59655.736149.252369@cj42289-a.reston1.va.home.com> <200007120353.FAA25150@python.inrialpes.fr> Message-ID: <20000712092602.F7340@xs4all.nl> On Wed, Jul 12, 2000 at 05:53:30AM +0200, Vladimir Marangozov wrote: > Besides, I think I screwed the logic of this patch as now I get a "no" > answer while it should be "yes" on my combo. So I definitely need to > assign this patch to myself and fix it! Actually, almost everyone should see 'no' in response to the statement 'checking if signed-right-shift zero-fills', except for Cray J90's and possibly other strange hardware. In any case, if 'test_long' succeeds for you, all is well. If you want it to say 'yes' instead of 'no' and still mean the same thing, swap the logic, and change the question to 'whether right-shift pads with sign bit' or some such. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From ping@lfw.org Tue Jul 11 18:31:59 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Tue, 11 Jul 2000 10:31:59 -0700 (PDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> Message-ID: On Tue, 11 Jul 2000, Fred L. Drake, Jr. wrote: > At one point, we were discussing having specializations of > SyntaxError, and I posted a patch that defined IndentationError and > TabError. I guess the question is, will we ever want to catch or distinguish just IndentationError or TabError exceptions in particular from within a Python program? I can't personally think of any situations where i would need more detail than SyntaxError (whatever the error is, i'll just want to say "syntax error" and show the message)... unless... should the expected token type be passed *all* the way back to the user level so that e.g. an IDE can provide a UI hint as to how to correct the syntax error? -- ?!ng From pf@artcom-gmbh.de Wed Jul 12 08:52:42 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Wed, 12 Jul 2000 09:52:42 +0200 (MEST) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <14699.59823.710880.896491@anthem.concentric.net> from "Barry A. Warsaw" at "Jul 11, 2000 11:44:47 pm" Message-ID: Hi, Barry A. Warsaw: > >>>>> "KY" == Ka-Ping Yee writes: > > > KY> I like this idea. This whole parallel iteration thing could > KY> be solved with a single built-in and no syntax changes. > > KY> for x, y in parallel([10, 20, 30], [1, 2]): > > KY> Or "zip", since you're zipping the lists together (i foresee > KY> potential geometric or concurrency-related interpretations of > KY> "parallel"): > > Definitely +1 on concept. The nice bit is that parallel() or zip() > can return objects that iterate efficiently. -0 on zip(), +0 on > parallel(), +0 on making them builtins. +1 on the concept. -1 on calling it 'zip' (I was first thinking of Info ZIP and zlib). -0 on calling it 'parallel' (makes me thinking of threads and processes). What about calling this function 'permute()'? Here is a strawman to play with: def permute(*args): """takes several sequences as arguments and returns a list of tuples, where each tuple contains an element of each sequence permutated through all possible combinations.""" if len(args) == 1: return map(lambda x:(x,), args[0]) else: res = []; cdr = apply(permute, args[1:]) for left in args[0]: for right in cdr: res.append((left,) + right) return res for x, y in permute([10, 20, 30], [1, 2]): print "x, y =", x, y BTW: How comes, that Ping very often invents or introduces very clever ideas and concepts, but also very often chooses unclear names for them? Is it just me not being a native english speaker? Regards, Peter From peter@schneider-kamp.de Wed Jul 12 11:00:33 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 12 Jul 2000 10:00:33 +0000 Subject: [Python-Dev] zip() and list-comprehension with commas References: Message-ID: <396C41C1.5A1C7652@schneider-kamp.de> Ka-Ping Yee wrote: > > Taking this all together provides one coherent solution: > > - zip() built-in produces a lazy list-zipper object +1 on this. no performance hit (probably a small gain), "zip" is imho the right name (see e.g. haskell). also answers on c.l.py could be shorter, saving considerable bandwidth > > - list-comps are written [, , , ...] > where each is "for x in y" or "if z" +0.5 on the concept, some questions: -------------------------------------------------------------------- I know special character are evil, but in this case I think [ | , , ...] would be on order of magnitude easier to read. Why not? -------------------------------------------------------------------- Would [x,y , for x in list1, if x > 1, if y > 2, for y in list2] be allowed? In other words: Should there be some rules of ordering? What would the above list comprehension produce for list1 = list2 = [1, 2, 3]? -------------------------------------------------------------------- Would the following be allowed (and desirable)? y = 3 [ x + y , for x in [1, 2, 3], if x > 1] producing [5, 6] -------------------------------------------------------------------- I don't know Python's parser, so I am sorry if this is a non-issue: How does it resolve the ambiguity between [, , ...] and [, , , ...]? Especially something like [x, y, z, for x in l1, for y in l2, for z in l3] concerns me. -------------------------------------------------------------------- that's it for now, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Fredrik Lundh" Message-ID: <00ba01bfebd9$3cfb5c80$f2a6b5d4@hagrid> ping wrote: > On Tue, 11 Jul 2000, Fred L. Drake, Jr. wrote: > > At one point, we were discussing having specializations of > > SyntaxError, and I posted a patch that defined IndentationError and > > TabError. >=20 > I guess the question is, will we ever want to catch or distinguish > just IndentationError or TabError exceptions in particular from > within a Python program? TabError maybe (retabify and try again -- but if you'll implement that, you might as well untabify before compiling), but I cannot see any reason to handle IndentationError. Also sucks from a documentation perspective... I'm -1 (on this part of the patch). > I can't personally think of any situations where i would need more > detail than SyntaxError (whatever the error is, i'll just want to > say "syntax error" and show the message)... unless... should the > expected token type be passed *all* the way back to the user level > so that e.g. an IDE can provide a UI hint as to how to correct the > syntax error? and in that case, the IDE won't be interested in actually showing the exception type to anyone... It's probably better to add extra info to the exception object, such as an "error tag" which is guaranteed to stay the same, no matter what the message is changed into (I'd love to have this in Python- Works, for example). guess it's time to grep for SyntaxError exceptions... From Fredrik Lundh" Message-ID: <00c401bfebd9$e6d347e0$f2a6b5d4@hagrid> tim wrote: > exceptions.c(93) : error C2026: string too big, trailing characters > truncated=20 and incidentally, I just got: SyntaxError: expression too long from python. but back to the original topic: what does the ANSI standard say about this? what is, for example, the limits for integer arrays? (my unicode database experiments results in a couple of big ones. and for best performance, they really have to be that big...) From peter@schneider-kamp.de Wed Jul 12 11:16:54 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 12 Jul 2000 10:16:54 +0000 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: Message-ID: <396C4596.C64D4EE6@schneider-kamp.de> Peter Funk wrote: > > What about calling this function 'permute()'? -1 on this: We are not looking for all possible pairings but for the (possibly lazy) equivalent of map(None, list1, list2, ...). > BTW: How comes, that Ping very often invents or introduces very clever > ideas and concepts, but also very often chooses unclear names for them? > Is it just me not being a native english speaker? I still think "zip" is okay, but that's probably my Haskell background. And no, I don't think it has to do something with not being a native English speaker. It's probably more the context you associate with "zip". I can't comment on earlier cases, though. heading-to-work-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mwh21@cam.ac.uk Wed Jul 12 09:27:50 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: Wed, 12 Jul 2000 09:27:50 +0100 (BST) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Peter Funk wrote: > BTW: How comes, that Ping very often invents or introduces very > clever ideas and concepts, but also very often chooses unclear names > for them? Is it just me not being a native english speaker? In this case it's you not being a functional programmer; `zip' seems perfectly natural to the part of my brain that speaks Haskell. Think zip as in "zipper"; this more sense to me than naming a compression algorithm "zip"... Cheers, M. From pf@artcom-gmbh.de Wed Jul 12 09:27:01 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Wed, 12 Jul 2000 10:27:01 +0200 (MEST) Subject: [Python-Dev] SyntaxError patches In-Reply-To: from Ka-Ping Yee at "Jul 11, 2000 10:31:59 am" Message-ID: > On Tue, 11 Jul 2000, Fred L. Drake, Jr. wrote: > > At one point, we were discussing having specializations of > > SyntaxError, and I posted a patch that defined IndentationError and > > TabError. Ka-Ping Yee: > I guess the question is, will we ever want to catch or distinguish > just IndentationError or TabError exceptions in particular from > within a Python program? I don't believe this. > I can't personally think of any situations where i would need more > detail than SyntaxError (whatever the error is, i'll just want to > say "syntax error" and show the message)... unless... should the > expected token type be passed *all* the way back to the user level > so that e.g. an IDE can provide a UI hint as to how to correct the > syntax error? That sounds rather complicated anyway, but it would certainly be nice for people using (or should I say needing?) an IDE. BTW: The following mistake has happened to me to in the past (I'm using the VI improved editor unter X11): If cut'n'pasting methods around between classes, sometimes I unintentionally copy a space character too much, so that the 'def' of the copied method is intended one blank to much to the right. Hmmmm... I should make this clearer using an example: ### class Foo(Bar): def pasted_method(self, ....) #---^ note this additional blank here (resulting in a 5 space indent). # ...a screenful of indented code snipped here... def another_method(self, baz, bang): #--------------------------------------^ # Python 1.5.2 barfs here with "SyntaxError: invalid token" ### This is not very intuitive and hard to see. The first time I stumbled about this it has taken me quite some time to discover my mistake. I wonder, if the error message could be improved. That would be a very valuable improvement for newbies. However this example might proove that the idea an IDE would be able to provide UI-hints for fixing errors is doomed to fail in the general case. Regards, Peter. From ping@lfw.org Wed Jul 12 09:36:25 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 01:36:25 -0700 (PDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C41C1.5A1C7652@schneider-kamp.de> Message-ID: On Wed, 12 Jul 2000, Peter Schneider-Kamp wrote: > +1 on this. no performance hit (probably a small gain), > "zip" is imho the right name (see e.g. haskell). Indeed, a nice coincidence. :) > -------------------------------------------------------------------- > > I know special character are evil, but in this case I think > [ | , , ...] > would be on order of magnitude easier to read. Why not? Alas, the vertical bar is already a bitwise-or operator, and couldn't safely be placed next to the . Hmm. How much of that "order of magnitude" comes from "|" looking like the math notation, and how much from the mere fact that "|" is distinguished from ","? Semicolon might be worth considering here, actually: [f(x); for x in l] > -------------------------------------------------------------------- > > Would [x,y , for x in list1, if x > 1, if y > 2, for y in list2] > be allowed? In other words: Should there be some rules of ordering? > What would the above list comprehension produce for > list1 = list2 = [1, 2, 3]? I would say raise SyntaxError on this example. Also, the way you've written the example would depend on an existing variable named 'y' because you put "if y > 2" outside of "for y in list2". If the existing variable was <= 2, you'd get an empty list. For the following, i'm assuming you intended to put "if y > 2" last. As for the SyntaxError, i think it's a good idea because the example could be ambiguous. You would have to either say [(x, y), for x in list1, if x > 1, for y in list2, if y > 2] or [x] + [y, for x in list1, if x > 1, for y in list2, if y > 2] The first would produce [(2, 3), (3, 3)], and the second would depend on the initial value of x and look like [x, 3, 3]. > -------------------------------------------------------------------- > > Would the following be allowed (and desirable)? > y = 3 > [ x + y , for x in [1, 2, 3], if x > 1] > producing [5, 6] Absolutely. > -------------------------------------------------------------------- > > I don't know Python's parser, so I am sorry if this is a non-issue: > How does it resolve the ambiguity between > [, , ...] and [, , , ...]? > Especially something like > [x, y, z, for x in l1, for y in l2, for z in l3] concerns me. I guess it depends how the argument about parens-around-tuples finally resolves, but personally i'd say that more than one expr before an attempted iteration clause should cause a SyntaxError. It would have to be written: [(x, y, z), for x in l1, for y in l2, for z in l3] -- ?!ng From mal@lemburg.com Wed Jul 12 09:32:00 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 12 Jul 2000 10:32:00 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: <396C4596.C64D4EE6@schneider-kamp.de> Message-ID: <396C2D00.BDA23AF2@lemburg.com> Peter Schneider-Kamp wrote: > > Peter Funk wrote: > > > > What about calling this function 'permute()'? > > -1 on this: We are not looking for all possible pairings but for the > (possibly lazy) equivalent of map(None, list1, list2, ...). > > > BTW: How comes, that Ping very often invents or introduces very clever > > ideas and concepts, but also very often chooses unclear names for them? > > Is it just me not being a native english speaker? > > I still think "zip" is okay, but that's probably my Haskell background. > And no, I don't think it has to do something with not being a native > English speaker. It's probably more the context you associate with > "zip". > I can't comment on earlier cases, though. Just for completeness: mx.Tools already has these APIs: tuples(sequence) Returns much the same as apply(map,(None,)+tuple(sequence)) does, except that the resulting list will always have the length of the first sub-sequence in sequence. The function returns a list of tuples (a[0], b[0], c[0],...), (a[1], b[1], c[1],...), ... with missing elements being filled in with None. Note that the function is of the single argument type meaning that calling tuples(a,b,c) is the same as calling tuples((a,b,c)). tuples() can be used as inverse to lists(). lists(sequence) Same as tuples(sequence), except that a tuple of lists is returned. Can be used as inverse to tuples(). and these have also proven useful: dict(items) Constructs a dictionary from the given items sequence. The sequence items must contain sequence entries with at least two values. The first one is interpreted as key, the second one as associated object. Remaining values are ignored. irange(object[,indices]) Builds a tuple of tuples (index,object[index]). If a sequence indices is given, the indices are read from it. If not, then the index sequence defaults to trange(len(object)). Note that object can be any object that can handle object[index], e.g. lists, tuples, string, dictionaries, even your own objects, if they provide a __getitem__-method. This makes very nifty constructions possible and extracting items from another sequence becomes a piece of cake. Give it a try ! You'll soon love this little function. indices(object) Returns the same as tuple(range(len(object))) -- a tad faster and a lot easier to type. I'm sure Python could steal a few of those ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Wed Jul 12 09:37:53 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 01:37:53 -0700 Subject: [Python-Dev] Memory leak tracking In-Reply-To: <14699.64688.697935.541901@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 12, 2000 at 01:05:52AM -0400 References: <14699.30119.262274.258429@anthem.concentric.net> <200007120550.AAA12465@cj20424-a.reston1.va.home.com> <14699.64688.697935.541901@anthem.concentric.net> Message-ID: <20000712013753.P29590@lyra.org> On Wed, Jul 12, 2000 at 01:05:52AM -0400, Barry A. Warsaw wrote: >... > I suspect this is exactly what's happening. I'd have to spend more > time to know exactly what's happening, but this jives with the > observed behavior. If so, the only thing we could do is try to break > the cycles manually at shutdown time and have the normal decrefs free > all the memory. > > I'm not sure it's worth the effort. 1) it isn't much memory; 2) it > only leaks when gc is disabled; 3) it's a one time cost, not > e.g. a leak every time you spawn a thread. > > That last is interesting, because I believe at least on Solaris, there > /is/ a leak for each new thread, but I haven't had time to find it > yet. That one's worth tracking down. For the others, it's actually > quite nice to see gc doing it's job! > > Other than that, running the test suite, the current CVS seems to have > a very clean bill of health memory usage-wise. Please try to consider the embedded case, too. If Python interpreters are created/destroyed, or modules are loaded/thrown out, or whatever... are there leaks? Any leak can be a disaster in embedded cases. Now... no need to be defensive :-) ... just pointing out there is another consideration when thinking about leaks. Cheers, -g -- Greg Stein, http://www.lyra.org/ From ping@lfw.org Wed Jul 12 09:40:55 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 01:40:55 -0700 (PDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Peter Funk wrote: > ### > class Foo(Bar): > def pasted_method(self, ....) > #---^ note this additional blank here (resulting in a 5 space indent). > # ...a screenful of indented code snipped here... > def another_method(self, baz, bang): > #--------------------------------------^ > # Python 1.5.2 barfs here with "SyntaxError: invalid token" > ### > > This is not very intuitive and hard to see. The first time I stumbled > about this it has taken me quite some time to discover my mistake. Gee. Well, with the SyntaxError patch, at least the error message is much better (even though the arrow still points to the wrong place): >>> class foo: ... def foo(self): ... pass ... def foo(bar): File "", line 4 def foo(bar): ^ SyntaxError: dedent does not match any outer indentation level Not sure why the arrow points there... i would have expected it to point at the beginning of the line, since it did successfully detect that the indentation was wrong. Maybe i'll investigate. -- ?!ng From Fredrik Lundh" Message-ID: <00fc01bfebdd$05eed060$f2a6b5d4@hagrid> michael wrote: > > In this case it's you not being a functional programmer; `zip' seems > perfectly natural to the part of my brain that speaks Haskell. >=20 > Think zip as in "zipper"; this more sense to me than naming a = compression > algorithm "zip"... >=20 footnote: merriam webster says: ... 1. to move, act, or function with speed and vigor ... 5. to close or open with or as if with a zipper ... I also checked two british dictionaries; the older only mentioned the first sense, the newer only the second. fwiw, the newer claims to be based on a "detailed ana- lysis of how modern English is really used". go figure. From mal@lemburg.com Wed Jul 12 09:36:38 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 12 Jul 2000 10:36:38 +0200 Subject: [Python-Dev] APIs for internal flags References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <200007101722.MAA01227@cj20424-a.reston1.va.home.com> <396A08AF.655B4836@lemburg.com> <200007101936.OAA02180@cj20424-a.reston1.va.home.com> Message-ID: <396C2E16.38DAAE58@lemburg.com> Guido van Rossum wrote: > > > Yes... I meant: it is not available from Python. (mx.Tools > > publishes an interface to this flag: sys.verbosity() which > > also allows setting the value at runtime.) > > It would make a lot of sense for the sys module to allow access to the > values of all the Python command line options, and perhaps to allow > changing them. > > Anybody interested in designing an API here? Some requirements would > be platform independence, extensibility, and necessarily the ability > to work even in an environment without command line flags (since it > still has the corresponding internal flags). For starters, here's what mx.Tools defines: sys.verbosity([level]) If level is given, the value of the interpreter's verbosity flag is set to level and the previous value of that flag is returned. Otherwise, the current value is returned. You can use this function to e.g. enable verborse lookup output to stderr for import statements even when the interpreter was not invoked with '-v' or '-vv' switch or to force verbosity to be switched off. sys.debugging([level]) If level is given, the value of the interpreter's debugging flag is set to level and the previous value of that flag is returned. Otherwise, the current value is returned. You can use this function to check whether the interpreter was called with '-d' flag or not. Some extensions use this flag to enable/disable debugging log output (e.g. all the mx Extensions). sys.optimization([level]) If level is given, the value of the interpreter's optimization flag is set to level and the previous value of that flag is returned. Otherwise, the current value is returned. You can use this function to e.g. compile Python scripts in optimized mode even though the interpreter was not started with -O. Perhaps a more generic interface would be nicer, but given that not all flags are really useful and some of them may not be altered after initialization, I find the per flag interfaces fit rather well (they also have the advantage of being able to add code on a per flag basis, which may become useful for future additions). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Wed Jul 12 09:43:38 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 01:43:38 -0700 Subject: [Python-Dev] File Object Copy In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jul 12, 2000 at 10:21:08AM +0300 References: Message-ID: <20000712014338.Q29590@lyra.org> On Wed, Jul 12, 2000 at 10:21:08AM +0300, Moshe Zadka wrote: > On Wed, 12 Jul 2000, Peter Funk wrote: > > 'shutil.copyfile' however takes filenames as arguments and contains > > the loop sketched above as inline code. I see two possibilities: > > 1. It would be easy to skip the open and close operations in > > 'shutil.copyfile', if either 'src' or 'dst' are already open > > file objects instead of strings. > > -0: Too much Perl-like DWIM magic > > > 2. Or you factor out the copy loop operation above and rename it into > > 'copycontent' or 'copybytes' or whatever. > > Of course it should be factored out: but the question remains, why shell > utils? Do you really think copybytes belongs there? Add shutil.copyfileob(src_file_ob, dst_file_ob). shutil.copyfile() can call it after opening the files. Does that function make absolute sense there? Tough question. It sure happens to work well, considered the dependent function copyfile(). I imagine there are a bazillion functions that could be re-factored. No sense getting overly concerned. Put the bugger in shutil for now. Step two: propose a new organization. Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul@prescod.net Wed Jul 12 09:52:41 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 03:52:41 -0500 Subject: [Python-Dev] list comprehensions again... References: <1248755410-33702453@hypernet.com> Message-ID: <396C31D9.4658CFD7@prescod.net> Gordon McMillan wrote: > > Paul Prescod wrote: > > > Nested (List): > > > > [for x in (0,10,20,30): > > for y in (0,1,2,3): > > x+y] > > [0,11,22,33] > > Not what I'd expect at all. No, I'm just an idiot. What you expect is what I meant. No excuse. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Fredrik Lundh" <20000712014338.Q29590@lyra.org> Message-ID: <011401bfebe0$2f388c60$f2a6b5d4@hagrid> moshe wrote: > > > 1. It would be easy to skip the open and close operations in=20 > > > 'shutil.copyfile', if either 'src' or 'dst' are already open=20 > > > file objects instead of strings. =20 > >=20 > > -0: Too much Perl-like DWIM magic footnote: it's definitely an accepted pydiom: aifc.py: if type(f) =3D=3D type(''): f =3D __builtin__.open(f, 'rb') binhex.py: if type(ofp) =3D=3D type(''): ofname =3D ofp ofp =3D open(ofname, 'w') mimify.py: if type(infile) =3D=3D type(''): ifile =3D open(infile) pstats.py: elif type(arg) =3D=3D type(""): f =3D open(arg, 'rb') etc. it's a reasonable way to make your code a bit more reusable (it's rude to expect every chunk of potentially usable data to have a filename...). From peter@schneider-kamp.de Wed Jul 12 11:59:09 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 12 Jul 2000 10:59:09 +0000 Subject: [Python-Dev] zip() and list-comprehension with commas References: Message-ID: <396C4F7D.288B561D@schneider-kamp.de> Ka-Ping Yee wrote: > > On Wed, 12 Jul 2000, Peter Schneider-Kamp wrote: > > +1 on this. no performance hit (probably a small gain), > > "zip" is imho the right name (see e.g. haskell). > > Indeed, a nice coincidence. :) off-topic: I am still thinking about higher order functions in Python: e.g.: map(+ 1, [1, 2, 3]) instead of map(lambda x: x + 1, [1, 2, 3]) don't have a clue how to do that yet. > Alas, the vertical bar is already a bitwise-or operator, and > couldn't safely be placed next to the . [...] > Semicolon might be worth considering here, actually: [f(x); for x in l] Better than just a comma anyway. Okay for me. > [(x, y), for x in list1, if x > 1, for y in list2, if y > 2] [...] > The first would produce [(2, 3), (3, 3)], and the second would > It would have to be written: > > [(x, y, z), for x in l1, for y in l2, for z in l3] but that's loosing some of it's beauty for me. if we'd use the semicolon [ x, y, z; for x in l1, for y in l2, for z in l3] looks better to me. okay, really heading off to work now, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Moshe Zadka Wed Jul 12 10:06:06 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 12 Jul 2000 12:06:06 +0300 (IDT) Subject: [Python-Dev] File Object Copy In-Reply-To: <20000712014338.Q29590@lyra.org> Message-ID: On Wed, 12 Jul 2000, Greg Stein wrote: > Add shutil.copyfileob(src_file_ob, dst_file_ob). shutil.copyfile() can call > it after opening the files. Done. Can someone who is able to checkin assign it to themselves? > Does that function make absolute sense there? Tough question. It sure > happens to work well, considered the dependent function copyfile(). I > imagine there are a bazillion functions that could be re-factored. No sense > getting overly concerned. > > Put the bugger in shutil for now. Step two: propose a new organization. Hmmmm...orthogonal to new organization, urllib and BaseHTTPServer need to be modified to call it. I'll do it as soon as the patch is accepted (100868) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Moshe Zadka Wed Jul 12 10:08:26 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 12 Jul 2000 12:08:26 +0300 (IDT) Subject: [Python-Dev] File Object Copy In-Reply-To: <011401bfebe0$2f388c60$f2a6b5d4@hagrid> Message-ID: On Wed, 12 Jul 2000, Fredrik Lundh wrote: > footnote: it's definitely an accepted pydiom: Yes, but one I personally do not like > > aifc.py: > if type(f) == type(''): > f = __builtin__.open(f, 'rb') > > binhex.py: > if type(ofp) == type(''): > ofname = ofp > ofp = open(ofname, 'w') > > mimify.py: > if type(infile) == type(''): > ifile = open(infile) > > pstats.py: > elif type(arg) == type(""): > f = open(arg, 'rb') > > etc. > > it's a reasonable way to make your code a bit more reusable > (it's rude to expect every chunk of potentially usable data to > have a filename...). Of course -- that's why I think most code should use file-like objects. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul@prescod.net Wed Jul 12 10:25:33 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:25:33 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> Message-ID: <396C398D.9F85F8A8@prescod.net> "Barry A. Warsaw" wrote: > [Python is becoming Perl] > | print [i, s for i in nums for s in strs] Let me try my syntax on this example: print [for i in nums: for s in strs: i, s] I don't see that as being any worse than the procedural syntax. > | print [i, s for i in nums for s in [f for f in strs if "n" in f]] I don't see this as being a realistic example. First, let me ask whether you think that reasonable programmers are actually going to come up with this. Why wouldn't they use a temporary variable for s? When nesting gets deep, reasonable programmers try to unroll it, whether it is in a.b.c.d.e or a(b(c(d(e())))) or list comps. In fact, we know that most UNreasonable programmers can be swayed with arguments from efficiency. You are computing the value of s over and over again "num" times. It makes no sense to do it that way. I think that my syntax would make this clearer (of course I would!): print [ for i in nums: for s in [for f in strs: if "n" in f: f] (i,s)] You can see that nothing from the outer loop is being used in the inner one, so what's the point in having it there? Better: s=[for f in strs: if "n" in f: f] print [for i in nums: (i,s)] Which to me is a nicer way of saying what we today say as: map( None, nums, [s]*len(nums)] If you want to confuse a newbie, I'll claim that the "map" version will do it more than the list comp. version. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From ping@lfw.org Wed Jul 12 10:35:21 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 02:35:21 -0700 (PDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Peter Funk wrote: > > BTW: How comes, that Ping very often invents or introduces very clever > ideas and concepts, Gee, thanks. :) I feel a group hug coming on. > but also very often chooses unclear names for them? > Is it just me not being a native english speaker? I don't know. Perhaps my florx bignal zupkin isn't very moognacious? Shlarp mixon ru, but tralorping weefibbledon groxit zanquar bladu. Bladu bladu. Woom! Greefon sip habligor? (Chalar icko neevour, & blafare ort lirriless.) Bladiblipifiribble a wompy idea: >>> def klaatu(): # Verata nikto. ... phwee File "", line 2 phwee ^ HolyGrailError: see the violence inherent in the system Ruinon flast. Elninfrawok? - Glidimon. - Fip milang freebik. Ip nane (varblig nane) refilk ruzzin. - Zom plut 'klaatu()' ix 'klaatu(spam)' etc. - Hilliban dreef? Neems 'ploo' girdar oioizoik: >>> 3 3 >>> 4 4 >>> 5 HolyGrailError: five is right out >>> [1:4] [1, 2, 5] Jodinat greidar fablo! Ruinon flast; ruinon flast. Thorvon whananadak yum, onk triplation is dortiful. <0.5 wink> Ecky-ecky-ecky-ecky-pikang-zoop-boing? -- ?!ng From paul@prescod.net Wed Jul 12 10:29:30 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:29:30 -0500 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: Message-ID: <396C3A7A.75CA43B3@prescod.net> Peter Funk wrote: > > ... > > +1 on the concept. > -1 on calling it 'zip' (I was first thinking of Info ZIP and zlib). > -0 on calling it 'parallel' (makes me thinking of threads and processes). > > What about calling this function 'permute()'? But zip is not permute! zip( [0,1,2,3,4],[0,10,20,30,40])=[0,11,22,33,44] Anyhow, I kind of like the names tuples() and lists(), as proposed by MAL. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From ping@lfw.org Wed Jul 12 10:47:16 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 02:47:16 -0700 (PDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <396C3A7A.75CA43B3@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > > But zip is not permute! > > zip( [0,1,2,3,4],[0,10,20,30,40])=[0,11,22,33,44] You mean zip([0,1,2,3,4], [0,10,20,30,40]) -> [(0,0), (1,10), (2,20), (3,30), (4,40)] (It's late... maybe we all need some sleep.) :) -- ?!ng From paul@prescod.net Wed Jul 12 10:41:43 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:41:43 -0500 Subject: [Python-Dev] zip() and list-comprehension with commas References: <396C41C1.5A1C7652@schneider-kamp.de> Message-ID: <396C3D57.61328C2D@prescod.net> Peter Schneider-Kamp wrote: > > > Would [x,y , for x in list1, if x > 1, if y > 2, for y in list2] > be allowed? In other words: Should there be some rules of ordering? Would this syntax make the answer clearer: [for x in list1: if x > 1: if y > 2: for y in list2: x,y] I don't think that makes sense unless y is externally bound. > Would the following be allowed (and desirable)? > y = 3 > [ x + y , for x in [1, 2, 3], if x > 1] > producing [5, 6] y = 3 [for x in [1, 2, 3]: if x > 1: x + y] Sure, getting around Python's name binding "issues" is one of the (side) benefits of list comprehensions. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From jack@oratrix.nl Wed Jul 12 10:44:46 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 11:44:46 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message by Michael Hudson , Wed, 12 Jul 2000 09:27:50 +0100 (BST) , Message-ID: <20000712094447.2275337186D@snelboot.oratrix.nl> parallel()/zip() have an other advantage: it would be easy to extend to let the loop continue until the longest of the items, with a keyword argument: parallel((1, 2), (3, 4, 5), missing=None) # or extend, or some other name would return ((1, 3), (2, 4), (None, 5)) By the way: -1 on the name zip() and -0 on the name parallel(), but +1 on the concept. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paul@prescod.net Wed Jul 12 10:44:07 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:44:07 -0500 Subject: [Python-Dev] zip() and list-comprehension with commas References: Message-ID: <396C3DE7.367B569D@prescod.net> Ka-Ping Yee wrote: > > > As for the SyntaxError, i think it's a good idea because the > example could be ambiguous. You would have to either say > > [(x, y), for x in list1, if x > 1, for y in list2, if y > 2] > > or > > [x] + [y, for x in list1, if x > 1, for y in list2, if y > 2] The easy way to avoid the ambiguity is to dump the comma and use colons as Guido intended. [for x in list1: if x > 1: for y in list2: if y > 2: (x,y)] -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From jack@oratrix.nl Wed Jul 12 10:49:56 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 11:49:56 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message by Ka-Ping Yee , Wed, 12 Jul 2000 02:35:21 -0700 (PDT) , Message-ID: <20000712094956.A456437186D@snelboot.oratrix.nl> > Ecky-ecky-ecky-ecky-pikang-zoop-boing? > > > -- ?!ng Shouldn't that be "Ecky-ecky-ecky-ecky-pikang-zoop-boing'ly yours," ? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paul@prescod.net Wed Jul 12 10:55:11 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:55:11 -0500 Subject: [Python-Dev] New builtins References: <396C4596.C64D4EE6@schneider-kamp.de> <396C2D00.BDA23AF2@lemburg.com> Message-ID: <396C407F.CAB2584A@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Just for completeness: mx.Tools already has these APIs: > > tuples(sequence) > Returns much the same as apply(map,(None,)+tuple(sequence)) does, Like it. > lists(sequence) > Same as tuples(sequence), except that a tuple of lists is returned. Like it. > dict(items) > Constructs a dictionary from the given items sequence. Like it. In my opinion, these are naturals for built-in functions. Cool! These I'm not as sure about: > irange(object[,indices]) > Builds a tuple of tuples (index,object[index]). Isn't this just tuples( indices( object ), object ) > indices(object) > Returns the same as tuple(range(len(object))) -- Could be obsoleted by the range-building syntax: [0..len(object)] would do the same thing. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gstein@lyra.org Wed Jul 12 11:01:56 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:01:56 -0700 Subject: [Python-Dev] File Object Copy In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jul 12, 2000 at 12:06:06PM +0300 References: <20000712014338.Q29590@lyra.org> Message-ID: <20000712030156.U29590@lyra.org> On Wed, Jul 12, 2000 at 12:06:06PM +0300, Moshe Zadka wrote: > On Wed, 12 Jul 2000, Greg Stein wrote: > > > Add shutil.copyfileob(src_file_ob, dst_file_ob). shutil.copyfile() can call > > it after opening the files. > > Done. Can someone who is able to checkin assign it to themselves? Checked in, and the patch is now closed. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Wed Jul 12 11:05:56 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:05:56 -0700 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: ; from ping@lfw.org on Wed, Jul 12, 2000 at 02:35:21AM -0700 References: Message-ID: <20000712030556.V29590@lyra.org> All right. Now this is just whacked. "Step *away* from the drugs and nobody will get hurt." Damn, Ping. You rock. -g On Wed, Jul 12, 2000 at 02:35:21AM -0700, Ka-Ping Yee wrote: > On Wed, 12 Jul 2000, Peter Funk wrote: > > > > BTW: How comes, that Ping very often invents or introduces very clever > > ideas and concepts, > > Gee, thanks. :) I feel a group hug coming on. > > > but also very often chooses unclear names for them? > > Is it just me not being a native english speaker? > > I don't know. Perhaps my florx bignal zupkin isn't very moognacious? > > Shlarp mixon ru, but tralorping weefibbledon groxit zanquar bladu. > Bladu bladu. Woom! Greefon sip habligor? (Chalar icko neevour, & > blafare ort lirriless.) > > Bladiblipifiribble a wompy idea: > > >>> def klaatu(): # Verata nikto. > ... phwee > File "", line 2 > phwee > ^ > HolyGrailError: see the violence inherent in the system > > Ruinon flast. Elninfrawok? > > - Glidimon. > - Fip milang freebik. Ip nane (varblig nane) refilk ruzzin. > - Zom plut 'klaatu()' ix 'klaatu(spam)' etc. > - Hilliban dreef? > > Neems 'ploo' girdar oioizoik: > > >>> 3 > 3 > >>> 4 > 4 > >>> 5 > HolyGrailError: five is right out > >>> [1:4] > [1, 2, 5] > > Jodinat greidar fablo! Ruinon flast; ruinon flast. Thorvon > whananadak yum, onk triplation is dortiful. <0.5 wink> > > Ecky-ecky-ecky-ecky-pikang-zoop-boing? > > > -- ?!ng > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Wed Jul 12 11:10:48 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:10:48 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396C398D.9F85F8A8@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 04:25:33AM -0500 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> <396C398D.9F85F8A8@prescod.net> Message-ID: <20000712031048.W29590@lyra.org> On Wed, Jul 12, 2000 at 04:25:33AM -0500, Paul Prescod wrote: >... > If you want to confuse a newbie, I'll claim that the "map" version will > do it more than the list comp. version. Just because map() might confuse people doesn't mean it is now okay to introduce *more* confusion. "Gee, officer... there isn't a law against driving stoned. So I figured driving all whacked out on heroin is okay, too." Cheers, -g -- Greg Stein, http://www.lyra.org/ From ping@lfw.org Wed Jul 12 11:14:54 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 03:14:54 -0700 (PDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C3DE7.367B569D@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > > The easy way to avoid the ambiguity is to dump the comma and use colons > as Guido intended. > > [for x in list1: > if x > 1: > for y in list2: > if y > 2: > (x,y)] Does indentation matter, and are you proposing blocks of "real" code in there? I suspect that writing it this way is going to tempt people to include more code, maybe expect to be able to write "else" clauses, put in "break", etc. I think if you do it this way, the above is so close to how you'd write it without list comprehensions that it largely eliminates the succinctness that motivated list comprehensions in the first place. -- ?!ng From gstein@lyra.org Wed Jul 12 11:13:58 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:13:58 -0700 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: ; from andy@reportlab.com on Wed, Jul 12, 2000 at 07:52:05AM +0100 References: Message-ID: <20000712031358.X29590@lyra.org> On Wed, Jul 12, 2000 at 07:52:05AM +0100, Andy Robinson wrote: >... > Are there many other applications which > use compression? If so, would it do > be feasible to include it by default > from version 1.6? I believe the correct approach would be to have ./configure look for zlib. If present, then it should include the module into the build. [ this auto-build style could apply to many modules, actually ] There would need to be a way to override this auto-build of a module. >... > p.s. I can submit a patch if needed :-) This would be great. I'd recommend a patch against configure.in and associated files. (Modules/Setup.* ?) Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Wed Jul 12 11:18:03 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 12 Jul 2000 12:18:03 +0200 Subject: [Python-Dev] New builtins References: <396C4596.C64D4EE6@schneider-kamp.de> <396C2D00.BDA23AF2@lemburg.com> <396C407F.CAB2584A@prescod.net> Message-ID: <396C45DB.B58D9B51@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > Just for completeness: mx.Tools already has these APIs: > > > > tuples(sequence) > > Returns much the same as apply(map,(None,)+tuple(sequence)) does, > > Like it. > > > lists(sequence) > > Same as tuples(sequence), except that a tuple of lists is returned. > > Like it. > > > dict(items) > > Constructs a dictionary from the given items sequence. > > Like it. > > In my opinion, these are naturals for built-in functions. Cool! > > These I'm not as sure about: > > > irange(object[,indices]) > > Builds a tuple of tuples (index,object[index]). > > Isn't this just tuples( indices( object ), object ) Yep, but less to write... > > indices(object) > > Returns the same as tuple(range(len(object))) -- > > Could be obsoleted by the range-building syntax: > > [0..len(object)] > > would do the same thing. True, except that I find indices(obj) more intuitive (and its just one function call). Technical note: tuples build faster than lists. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Moshe Zadka Wed Jul 12 11:19:07 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 12 Jul 2000 13:19:07 +0300 (IDT) Subject: [Python-Dev] SF again: Patch assignments Message-ID: Can anyone send me a clear explanation how to assign a patch to someone? I've spent 10 minutes roomaging around SF to no avail. sf-can-be-frustrating-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From pf@artcom-gmbh.de Wed Jul 12 11:16:24 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Wed, 12 Jul 2000 12:16:24 +0200 (MEST) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: from Ka-Ping Yee at "Jul 12, 2000 2:36:33 am" Message-ID: > On Wed, 12 Jul 2000, Peter Funk wrote: > > BTW: How comes, that Ping very often invents or introduces very clever > > ideas and concepts, but also very often chooses unclear names for them? > > Is it just me not being a native english speaker? > Ka-Ping Yee schrieb: > Sorry for the silly reply. :) Honestly, i'm curious, though. > What kinds of things have been unclear to you before? It would > be instructive for me to know... Sorry: I take that back. It was just me. I've justed browsed through your articles in the 2000 python-dev archive and the only thing I found is your 'Notifier' class proposal containing method names like 'denotify'. (http://www.python.org/pipermail/python-dev/2000-April/010367.html http://www.python.org/pipermail/python-dev/2000-April/010368.html) Obviously my memory was blurred. Regards, Peter From gstein@lyra.org Wed Jul 12 11:41:31 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:41:31 -0700 Subject: [Python-Dev] SF again: Patch assignments In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jul 12, 2000 at 01:19:07PM +0300 References: Message-ID: <20000712034131.B29590@lyra.org> On Wed, Jul 12, 2000 at 01:19:07PM +0300, Moshe Zadka wrote: > > Can anyone send me a clear explanation how to assign a patch to someone? > I've spent 10 minutes roomaging around SF to no avail. I just click on the patch itself. In the screen that comes up, there is a drop-box for "Assigned To:" where I can select a person. After selecting the appropriate victim, I hit the "Submit Changes" button at the bottom of the page. Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul@prescod.net Wed Jul 12 11:48:35 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 05:48:35 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> <396C398D.9F85F8A8@prescod.net> <20000712031048.W29590@lyra.org> Message-ID: <396C4D03.D4F1F8E7@prescod.net> Greg Stein wrote: > > On Wed, Jul 12, 2000 at 04:25:33AM -0500, Paul Prescod wrote: > >... > > If you want to confuse a newbie, I'll claim that the "map" version will > > do it more than the list comp. version. > > Just because map() might confuse people doesn't mean it is now okay to > introduce *more* confusion. But the map version is a very common convention! If we can make a common convention more readable, that's a net win. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From peter@schneider-kamp.de Wed Jul 12 14:09:12 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 12 Jul 2000 13:09:12 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules flmodule.c,1.40,1.41 fmmodule.c,1.14,1.15 References: <200007121043.DAA27255@slayer.i.sourceforge.net> Message-ID: <396C6DF8.42C314E1@schneider-kamp.de> Sjoerd Mullender wrote: > > Fixed up some ANSIfications. oops. One typo and one wrong replace. I was probably getting tired ,-) Thnx Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gstein@lyra.org Wed Jul 12 12:15:14 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 04:15:14 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396C4D03.D4F1F8E7@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 05:48:35AM -0500 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> <396C398D.9F85F8A8@prescod.net> <20000712031048.W29590@lyra.org> <396C4D03.D4F1F8E7@prescod.net> Message-ID: <20000712041513.C29590@lyra.org> On Wed, Jul 12, 2000 at 05:48:35AM -0500, Paul Prescod wrote: > Greg Stein wrote: > > > > On Wed, Jul 12, 2000 at 04:25:33AM -0500, Paul Prescod wrote: > > >... > > > If you want to confuse a newbie, I'll claim that the "map" version will > > > do it more than the list comp. version. > > > > Just because map() might confuse people doesn't mean it is now okay to > > introduce *more* confusion. > > But the map version is a very common convention! If we can make a common > convention more readable, that's a net win. Agreed, to a point. The counter-point is: "let's introduce syntax to make FOO more readable. great. now lets introduce syntax to make BAR more readable. sweet. how about BAZ?" There are a lot of common idioms in Python. How many do you want to add *syntax* for? Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido@beopen.com Wed Jul 12 13:19:14 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 07:19:14 -0500 Subject: [Python-Dev] APIs for internal flags In-Reply-To: Your message of "Wed, 12 Jul 2000 10:36:38 +0200." <396C2E16.38DAAE58@lemburg.com> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <200007101722.MAA01227@cj20424-a.reston1.va.home.com> <396A08AF.655B4836@lemburg.com> <200007101936.OAA02180@cj20424-a.reston1.va.home.com> <396C2E16.38DAAE58@lemburg.com> Message-ID: <200007121219.HAA13436@cj20424-a.reston1.va.home.com> [me] > > Anybody interested in designing an API here? Some requirements would > > be platform independence, extensibility, and necessarily the ability > > to work even in an environment without command line flags (since it > > still has the corresponding internal flags). [MAL] > For starters, here's what mx.Tools defines: > > sys.verbosity([level]) > sys.debugging([level]) > sys.optimization([level]) [...] +1 on the concept. All the other routines in sys seem to have 'set' or 'get' in their name (e.g. get/setdefaultencoding). Maybe we should conform to that? You could argue over names, e.g. get/setverbosity, get/setdebuglevel, get/setoptlevel. Are there any other flags that you might want to know about? -i,-c,-x irrelevant -S possibly -t yes --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul@prescod.net Wed Jul 12 12:21:56 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 06:21:56 -0500 Subject: [Python-Dev] zip() and list-comprehension with commas References: Message-ID: <396C54D4.A7855CC4@prescod.net> Ka-Ping Yee wrote: > > ... > > Does indentation matter, I'd say no. It is an expression in parens. Arguably, we could make the actual line breaks optional also: [for x in list1: if x > 1: for y in list2: if y > 2: (x,y)] > and are you proposing blocks of "real" code in there? No. Just expressions. > I suspect that writing it this way > is going to tempt people to include more code, maybe expect > to be able to write "else" clauses, put in "break", etc. Miscomprehensions of this sort will not last long. It won't fail silently! else might be a useful extension. (future version!) abs=[for x in nums: if x>0: x else: -x] There is the danger of introducing the ambiguous else. > I think if you do it this way, the above is so close to how > you'd write it without list comprehensions that it largely > eliminates the succinctness that motivated list comprehensions > in the first place. It sounds like you are saying that the real benefit of list comprehensions is that they allow you to avoid newlines! Anyhow, if you don't like the newlines, I think we can make them optional without losing anything. Then this syntax is as compact as the original. The colon syntax is very clear about the fact that the lists are not evaluated in parallel. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Wed Jul 12 12:27:44 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 06:27:44 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> <396C398D.9F85F8A8@prescod.net> <20000712031048.W29590@lyra.org> <396C4D03.D4F1F8E7@prescod.net> <20000712041513.C29590@lyra.org> Message-ID: <396C5630.AEB894B5@prescod.net> Greg Stein wrote: > > ... > > Agreed, to a point. > > The counter-point is: "let's introduce syntax to make FOO more readable. > great. now lets introduce syntax to make BAR more readable. sweet. how about > BAZ?" > > There are a lot of common idioms in Python. How many do you want to add > *syntax* for? In this case, we're replacing four conventions: map( None, a, [b]*len(a)) map( lambda x: ... ) filter( lambda x: ...) a=[] for i in j: a.append( something( i )) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From akuchlin@mems-exchange.org Wed Jul 12 12:59:15 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 12 Jul 2000 07:59:15 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <20000712031358.X29590@lyra.org>; from gstein@lyra.org on Wed, Jul 12, 2000 at 03:13:58AM -0700 References: <20000712031358.X29590@lyra.org> Message-ID: <20000712075915.A17856@newcnri.cnri.reston.va.us> On Wed, Jul 12, 2000 at 03:13:58AM -0700, Greg Stein wrote: >[ this auto-build style could apply to many modules, actually ] I'm working on a patch for using a setup.py file and the Distutils to build the standard library; Setup.in then contains only those few modules needed to run the Distutils, and you'd never need to modify it. Not done yet, though... --amk From thomas@xs4all.net Wed Jul 12 13:07:37 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 14:07:37 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396B9B91.E33D8C58@prescod.net>; from paul@prescod.net on Tue, Jul 11, 2000 at 05:11:29PM -0500 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> <396B9B91.E33D8C58@prescod.net> Message-ID: <20000712140737.G7340@xs4all.nl> On Tue, Jul 11, 2000 at 05:11:29PM -0500, Paul Prescod wrote: > Thomas Wouters wrote: > > .... They provide an easier way to create a list, but they don't > > eradicate the need for map, reduce or filter, because there is no way to > > comprehend an already created list. > What do you mean? I think I see examples of list comprehensions working > on existing lists on this page: > http://www.cosc.canterbury.ac.nz/~greg/python/listcomp/ > numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] > evens = [x for x in numbers if x % 2 == 0] # filter > mult3 = [3 * x for x in numbers] # map Yes, sorry, I don't know what posessed me to say that, I was obviously mistaken. What can I say, it was late, I was exhausted ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul@prescod.net Wed Jul 12 13:06:29 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 07:06:29 -0500 Subject: [Python-Dev] List comp. sci fi Message-ID: <396C5F45.A8267A96@prescod.net> There is this idea on the edge of my brain that has to get out. I'm afraid of overloading the idea too much while people are still uncomfortable with the basics but at the same time I think that it is exciting that there could be more power in list comprehensions than pure syntactic sugar. What if list comprehensions were lazy? They would be objects that generate the items one at a time. Does this kill two birds with one stone? Or just conflate two separate ideas? Consider: naturals=[for num in [0:sys.maxint]] # does not construct list!! evens=[for num in naturals: if num%2==0: num ] # ditto!! chunks=[for chunk in file.read( 2048 ): chunk] # ditto!! databaseRecords=[for rec in SQL.Execute( "..." ): rec ] ditto!! Let's presume that name bindings are lexical and cyclic garbage collection works as we expect it to. Converting lazy behavior to eager is easy: chunkList=tuple( chunks ) I'm not up to it right now, but I'm sure that there is a nice way to combine sre and lazy comprehensions to get objects that return "hits" in a string one at a time. How to implement this? Stackless Python. As my friend Joy says: Go for the big one or stay at home. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gvwilson@nevex.com Wed Jul 12 13:10:52 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Wed, 12 Jul 2000 08:10:52 -0400 (EDT) Subject: [Python-Dev] second experiment Message-ID: I'm giving a talk at the U. of Toronto tomorrow, and would like to re-run the "what does it do?" experiment with list comprehensions and simultaneous loops. I propose asking the following: The program: for x in [10, 20, 30]: print x prints: 10 20 30 and the program: for x in [10, 20, 30]: for y in [1, 2, 3]: print x+y prints: 11 12 13 21 22 23 31 32 33 Match each of the following: (A) for x in [10, 20, 30]; y in [1, 2, 3]: print x+y (B) for (x,y) in zip([10, 20, 30], [1, 2, 3]): print x+y (C) for (x in [10, 20, 30]) and (y in [1, 2, 3]): print x+y (D) something else to their output: (1) 11 22 33 (2) 11 12 13 21 22 23 31 32 33 (3) "Run-Time Error" Questions: 1. What should option (D) be? 2. Should the lists be the same length, or different lengths? I think the latter is the trickier case (equally reasonable to say "iterate for length of shortest" and "error if lists' lengths unequal") --- is that worth testing? 3. Can someone provide a couple of list comprehension alternatives as well? Reactions? Greg From guido@beopen.com Wed Jul 12 14:18:04 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 08:18:04 -0500 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: Your message of "Wed, 12 Jul 2000 03:13:58 MST." <20000712031358.X29590@lyra.org> References: <20000712031358.X29590@lyra.org> Message-ID: <200007121318.IAA14063@cj20424-a.reston1.va.home.com> > On Wed, Jul 12, 2000 at 07:52:05AM +0100, Andy Robinson wrote: > >... > > Are there many other applications which > > use compression? If so, would it do > > be feasible to include it by default > > from version 1.6? > > I believe the correct approach would be to have ./configure look for zlib. > If present, then it should include the module into the build. > [ this auto-build style could apply to many modules, actually ] > > There would need to be a way to override this auto-build of a module. > > >... > > p.s. I can submit a patch if needed :-) > > This would be great. I'd recommend a patch against configure.in and > associated files. (Modules/Setup.* ?) Greg subtly points out the difficulty with your proposal: this requires an external library that may not be available. In the past we've had enough complaints from people who failed to realize that if the build failed because of a missing external library, they could just disable the module that needs it. So I'm not for simply having it enabled in Setup.in by default. I would love to have a mechanism (run by configure or maybe better by makesetup) that automatically determines if a particular external library package is available. Come to think of it, in first approximation, makesetup could easily parse the -I, -L and -l options you specify for a particular extension and only build it if it can find all those... But it's a bit of work! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Wed Jul 12 14:21:18 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 08:21:18 -0500 Subject: [Python-Dev] File Object Copy In-Reply-To: Your message of "Wed, 12 Jul 2000 12:08:26 +0300." References: Message-ID: <200007121321.IAA14098@cj20424-a.reston1.va.home.com> > > footnote: it's definitely an accepted pydiom: > > Yes, but one I personally do not like > > > aifc.py: > > if type(f) == type(''): > > f = __builtin__.open(f, 'rb') > > etc. > > > > it's a reasonable way to make your code a bit more reusable > > (it's rude to expect every chunk of potentially usable data to > > have a filename...). > > Of course -- that's why I think most code should use file-like objects. Agreed. The quoted examples are all kludges in my book. (The API designer initially accepted only a filename, then realized this was a bad choice, and fixed it in a backwards compatible way instead of fixing it right. There are just as many examples where it's done right, I just can't think of any. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy@beopen.com Wed Jul 12 13:24:19 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 12 Jul 2000 08:24:19 -0400 (EDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: References: Message-ID: <14700.25459.555611.544163@bitdiddle.concentric.net> >>>>> "KPY" == Ka-Ping Yee writes: KPY> Gee. Well, with the SyntaxError patch, at least the error KPY> message is much better (even though the arrow still points to KPY> the wrong place): >>> class foo: ... def foo(self): ... pass ... def foo(bar): File "", line 4 def foo(bar): ^ SyntaxError: dedent does not match any outer indentation level The error message is different and given a little phrasebook that translates between the exception and English, it may actually be better <0.3 wink>. I don't know what a dedent is. Nor do I know what "outer indentation levels" are or how they might apply to the line "def foo(bar):". I think the error message is trying to say "indentation does not match surrounding context," but other than "does not match" the words are obscure. Jeremy From jeremy@beopen.com Wed Jul 12 13:29:59 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 12 Jul 2000 08:29:59 -0400 (EDT) Subject: [Python-Dev] Windows build broken in exceptions.c In-Reply-To: <00c401bfebd9$e6d347e0$f2a6b5d4@hagrid> References: <00c401bfebd9$e6d347e0$f2a6b5d4@hagrid> Message-ID: <14700.25799.891112.727921@bitdiddle.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> tim wrote: >> exceptions.c(93) : error C2026: string too big, trailing >> characters truncated FL> and incidentally, I just got: FL> SyntaxError: expression too long FL> from python. Hey! That's cool. In earlier versions, you would have gotten a core dump. Jeremy From guido@beopen.com Wed Jul 12 14:27:51 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 08:27:51 -0500 Subject: [Python-Dev] SF again: Patch assignments In-Reply-To: Your message of "Wed, 12 Jul 2000 03:41:31 MST." <20000712034131.B29590@lyra.org> References: <20000712034131.B29590@lyra.org> Message-ID: <200007121327.IAA14145@cj20424-a.reston1.va.home.com> > > Can anyone send me a clear explanation how to assign a patch to someone? > > I've spent 10 minutes roomaging around SF to no avail. > > I just click on the patch itself. In the screen that comes up, there is a > drop-box for "Assigned To:" where I can select a person. After selecting the > appropriate victim, I hit the "Submit Changes" button at the bottom of the > page. Moshe didn't see the drop-box because his permissions didn't include assigning patches. I've fixed this (as a policy, we give everyone with checkin permissions tech&admin permissions for the patch manager, but that's not the SF default, so it must be done manually). This is the second or third post from a new SF developer asking about this. We really need to set up our own SF FAQ soon! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas@xs4all.net Wed Jul 12 13:44:00 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 14:44:00 +0200 Subject: [Python-Dev] second experiment In-Reply-To: ; from gvwilson@nevex.com on Wed, Jul 12, 2000 at 08:10:52AM -0400 References: Message-ID: <20000712144400.H7340@xs4all.nl> On Wed, Jul 12, 2000 at 08:10:52AM -0400, Greg Wilson wrote: > (A) for x in [10, 20, 30]; y in [1, 2, 3]: > print x+y > > (B) for (x,y) in zip([10, 20, 30], [1, 2, 3]): > print x+y > > (C) for (x in [10, 20, 30]) and (y in [1, 2, 3]): > print x+y Hm, grouping them... Hadn't thought of that. That's going to be gruesome to implement, but it might just be possible. It isn't possible to use this 'and'-syntax without parentheses, in any case. > (D) something else for x in [10, 20, 30] while y in [1, 2, 3]: print x+y for x; y in [10, 20, 20]; [1, 2, 3]: print x+y > to their output: I'd suggest additional output, too: 4) 1 2 3 5) 10 20 30 And tell them they can match more than one construct to the same output ;-) > 2. Should the lists be the same length, or different lengths? I think the > latter is the trickier case (equally reasonable to say "iterate for > length of shortest" and "error if lists' lengths unequal") --- is that > worth testing? Probably... I'm not sure howmuch time you want to keep them busy. This is supposed to be intuitive, which means they shouldn't be pressured to find the right answer. > 3. Can someone provide a couple of list comprehension alternatives as > well? I'm not going there for a while. I'm dazed and confused about list comprehensions, that's for sure. Well, you can try seeing whether they think one of these should be zipped or cartesian product: [ x,y for x in [1, 2, 3] for y in [10, 20, 30] ] [ x;y for x in [1, 2, 3]; for y in [10, 20, 30] ] No use checking for commas, we'd have to re-write Pythons' parser or Grammar entirely to allow that. See my upcoming post on the various proposed alterantive syntaxes and why they aren't going to work ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw@beopen.com Wed Jul 12 14:05:40 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 09:05:40 -0400 (EDT) Subject: [Python-Dev] File Object Copy References: <200007121321.IAA14098@cj20424-a.reston1.va.home.com> Message-ID: <14700.27940.592190.150292@anthem.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> Of course -- that's why I think most code should use file-like >> objects. GvR> Agreed. The quoted examples are all kludges in my book. GvR> (The API designer initially accepted only a filename, then GvR> realized this was a bad choice, and fixed it in a backwards GvR> compatible way instead of fixing it right. There are just as GvR> many examples where it's done right, I just can't think of GvR> any. :-) rfc822.Message() -Barry From fredrik@pythonware.com Wed Jul 12 14:13:40 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 15:13:40 +0200 Subject: [Python-Dev] File Object Copy References: <200007121321.IAA14098@cj20424-a.reston1.va.home.com> Message-ID: <007a01bfec02$ffb5af90$0900a8c0@SPIFF> guido wrote: > > > it's a reasonable way to make your code a bit more reusable > > > (it's rude to expect every chunk of potentially usable data to > > > have a filename...). > > > > Of course -- that's why I think most code should use file-like objects. > > Agreed. The quoted examples are all kludges in my book. (The API > designer initially accepted only a filename, then realized this was a > bad choice, and fixed it in a backwards compatible way instead of > fixing it right. There are just as many examples where it's done > right, I just can't think of any. :-) really? personally, I think that inventing new method names just because the language doesn't happen to support method overloading is a much bigger kludge ;-) (just like multiple inheritance, overloading can surely be abused by overambitious designers, but *not* having it is way too limiting) otoh, unless someone wants to remove overloading emulation from the modules I mentioned, this is probably a bit off-topic... cheers /F From jack@oratrix.nl Wed Jul 12 14:19:59 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 15:19:59 +0200 Subject: [Python-Dev] second experiment In-Reply-To: Message by Greg Wilson , Wed, 12 Jul 2000 08:10:52 -0400 (EDT) , Message-ID: <20000712131959.D823037186D@snelboot.oratrix.nl> > 1. What should option (D) be? for (x, y) in [(10, 1), (20, 2), (30, 3)]: print x+y And I think it should be the first question, being the currently existing idiom. If non-pythoneers understand the current semantics but not the new ones there's a problem. Oh yes, maybe you should add an answer 4: I haven't the faintest idea. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From gvwilson@nevex.com Wed Jul 12 14:26:13 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Wed, 12 Jul 2000 09:26:13 -0400 (EDT) Subject: [Python-Dev] second experiment In-Reply-To: <20000712131959.D823037186D@snelboot.oratrix.nl> Message-ID: > > 1. What should option (D) be? > > for (x, y) in [(10, 1), (20, 2), (30, 3)]: > print x+y > > And I think it should be the first question, being the currently > existing idiom. Very good point --- thanks. Greg From bwarsaw@beopen.com Wed Jul 12 14:35:09 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 09:35:09 -0400 (EDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: <20000712094447.2275337186D@snelboot.oratrix.nl> Message-ID: <14700.29709.259658.864250@anthem.concentric.net> >>>>> "JJ" == Jack Jansen writes: JJ> parallel()/zip() have an other advantage: it would be easy to JJ> extend to let the loop continue until the longest of the JJ> items, with a keyword argument: parallel((1, 2), (3, 4, 5), JJ> missing=None) # or extend, or some other name would return JJ> ((1, 3), (2, 4), (None, 5)) Yes, yes, yes! JJ> By the way: -1 on the name zip() and -0 on the name JJ> parallel(), but +1 on the concept. Is weave() perhaps a better name? -Barry From jack@oratrix.nl Wed Jul 12 14:57:35 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 15:57:35 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message by bwarsaw@beopen.com (Barry A. Warsaw) , Wed, 12 Jul 2000 09:35:09 -0400 (EDT) , <14700.29709.259658.864250@anthem.concentric.net> Message-ID: <20000712135736.2DA9737186D@snelboot.oratrix.nl> > JJ> By the way: -1 on the name zip() and -0 on the name > JJ> parallel(), but +1 on the concept. > > Is weave() perhaps a better name? My mental model tends to be transpose(), but that will definitely throw off mathematicians. Maybe we need an anti?!ng to come up with a good name:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From skip@mojam.com (Skip Montanaro) Wed Jul 12 04:59:28 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 11 Jul 2000 22:59:28 -0500 (CDT) Subject: [Python-Dev] Really dumb test observation Message-ID: <14699.60704.857942.610871@beluga.mojam.com> I was working on Python module coverage test generation tonight (sample results in the morning!). I noticed that coverage of the random module wasn't very good (30%-40% lines executed). There was no regression test case for that module, but I saw there was a random.test() function, so I created the following simple regression test: import random random.test() Statement coverage jumped immediately to nearly 90%. Seems to me that if a module defines a test() function and we have no regression test file for the module, that the above trick may increase code coverage significantly. (Actually, perhaps in these cases the test() function and related bits should be copied to the relevant regression test file to avoid invisible coupling between the module and its regression test output.) Skip From thomas@xs4all.net Wed Jul 12 15:13:28 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 16:13:28 +0200 Subject: [Python-Dev] listcomp / par-for (summary) Message-ID: <20000712161328.I7340@xs4all.nl> I'm gonna try and summarize all the opinions and suggestions in the listcomprehensions thread-from-hell (mutt's thread-sorted view was going bananas ;) but I'm certain I missed some suggestions and opinions, so I apologize in advance ;) Basically, what's been said is that list comprehensions as they are, are too confusing. I haven't hear that many people say that, but not many people objected to those that did say it, and plenty of alternative syntaxes were proposed. The same goes for parallel-for. It isn't terribly obvious whether the proposed syntax implements a cartesian product (as a nested for loop does) or a cross-section. There seem to be less divergent thoughts about this, though. A builtin (zip() or such) is preferred by a number of people, but not that many alternative syntaxes came along. As said, the currently implemented list-comprehension syntax was too unclear, especially when nesting the 'for's and 'if's too deeply. One of the proposals was to enforce the use of ()'s and add commas to make the 'for's and 'if's more readable: [(x,y) for x in a, y in b, if y > 3] That is not going to work. Enforcing the parentheses is possible, but only if you *always* enforce them, even if they don't create a tuple: [([x,y]) for x in a] (which would create a list of lists, not a list of tuples of lists.) And the problem with enforcing it is that we have to split open a *lot* of the Grammar, in order to disambiguate the syntax. Ain't a recursive descent parser great ? :) Secondly, the use of commas to seperate the for and if statements is not possible. The parser will see the commas as part of the iter-list of the previous for statement. The same goes for all other seperators that already have a meaning inside a 'testlist': commas, vertical bars, ampersands, circumflexes, etc. About the only character that already had a meaning inside Python that's usable at this point is the semi-colon, because it's only used as a statement seperator, not part of an expression list. Of course, using a new character that hasn't a meaning yet also works. And the same also goes for keywords in the same place. 'and' won't work, for instance, because it's already part of 'exprlist' and 'testlist', but 'while' does work, because it's currently only valid as a statement, not in an expression. So we end up with the following possibly syntaxes: [ <...> ] and [ ; ; ; <...> ] and perhaps the use of Python blocks and such: [ : : <....> ] Though I think that is a bit of a far cry from the original proposal. All the other proposals simply won't work without a massive re-ordering of the Grammar or rewriting the entire parser into something more versatile (and complicated) than a simple recursive descent parser. And the exact same story can be told for the parallel-for loop: for x in a and y in b: will not work because the 'exprlist' in 'for' will eat up 'a and y in b'. Likewise for for x in a | y in b: for x|y in a|b: for x,y in a|b: etc. The unnatural for {x,y} in a, b: would work, but it'd require special-casing the use of {}'s, and might suggest 'dict-unpacking' to people. for x;y in a;b: probably will work, too. Actually, yes, this will work, even though I haven't tested it... It also makes seeing howmany lists you are looping over pretty easy. Hmm, I might even like this more than the currently implemented syntax, even if it's slightly less readable. The range-literal thing ([:10:2] -> [0,2,4,6,8]) seems to be acceptable, I believe ? It might 'merely' be syntactic sugar for a builtin, but it's such pretty sugar ! :-) And it's not possible to shadow the builtin like with range. (Though I have one possible addition to the range syntax: range tuples, like so: (20:10:3) They could just generate a rangeobject, like xrange does... That could be a fair bit of memory savings ;) But I have to admit the syntax isn't as obvious as [19:15:-1]) If I were to tally votes, I'd say the general consensus (for as far as there is one ;-) is rougly like this: list comprehensions: -1/-0 parallel for: -0 range literal: +0 Correct me if I'm wrong ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip@mojam.com (Skip Montanaro) Wed Jul 12 15:19:47 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 12 Jul 2000 09:19:47 -0500 (CDT) Subject: [Python-Dev] Re: test_posixpath fails In-Reply-To: <14699.58277.811263.365468@bitdiddle.concentric.net> References: <14699.58277.811263.365468@bitdiddle.concentric.net> Message-ID: <14700.32387.330444.979191@beluga.mojam.com> Jeremy> If I run the new test on my Linux box, I get two errors. The Jeremy> second error looks innocuous, but the first one looks like a Jeremy> real bug. Jeremy, Mea culpa. I wrote the commonprefix test assuming the adoption of my new (corrected) semantics. Looks like you are using the stock version that examines prefixes character-by-character, which can return path prefixes that don't exist. Try applying this patch: https://sourceforge.net/patch/?func=detailpatch&patch_id=100788&group_id=5470 Skip Jeremy> Jeremy >> python Lib/test/test_posixpath.py Jeremy> error! Jeremy> evaluated: posixpath.commonprefix(["/home/swenson/spam", "/home/swen/spam"]) Jeremy> should be: /home Jeremy> returned: /home/swen Jeremy> error! Jeremy> evaluated: posixpath.commonprefix(["/home/swen/spam", "/home/swen/eggs"]) Jeremy> should be: /home/swen Jeremy> returned: /home/swen/ Jeremy> 2 errors. From fdrake@beopen.com Wed Jul 12 15:20:28 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 12 Jul 2000 10:20:28 -0400 (EDT) Subject: [Python-Dev] Re: CVS: python/dist/src/Include abstract.h,2.21,2.22 In-Reply-To: <200007121256.FAA00462@slayer.i.sourceforge.net> References: <200007121256.FAA00462@slayer.i.sourceforge.net> Message-ID: <14700.32428.442840.683994@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > change abstract size functions PySequence_Size &c. > add macros for backwards compatibility with C source ... > + #define PyObject_Length(O) PyObject_Size((O)) Jeremy, This should probably be: #define PyObject_Length PyObject_Size without the parameters. This form can be used in the all the places where it can now, including passing a function reference. Seems like a good idea to offer as little potential breakage as possible. Are you planning to update the API reference, or should I do that? I'll be glad to do it; I've never liked the difference in the naming either! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip@mojam.com (Skip Montanaro) Wed Jul 12 15:24:31 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 12 Jul 2000 09:24:31 -0500 (CDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <14699.59823.710880.896491@anthem.concentric.net> References: <396BA425.2EF3B11F@prescod.net> <14699.59823.710880.896491@anthem.concentric.net> Message-ID: <14700.32671.461502.666561@beluga.mojam.com> BAW> Alternatives (as Greg I think brought up): pairwise(), maybe BAW> zipper() for zip() since it's more evocative. "zip" already has a lot of compression connotations. How about "stitch", as in "stitch two lists together"? Skip From nhodgson@bigpond.net.au Wed Jul 12 15:30:08 2000 From: nhodgson@bigpond.net.au (Neil Hodgson) Date: Thu, 13 Jul 2000 00:30:08 +1000 Subject: [Python-Dev] Proxy settings for urllib on Win32 Message-ID: <004501bfec0d$ae1bca10$8119fea9@neil> Is there any reason why urllib uses environment variables for proxy settings on Win32? Its quite unlikely they will be set up and there is a standard registry location for this information. I've added retrieval of registry settings to my copy of urllib and it seems to work OK athough I'm not running off CVS and I recall the winreg module has changed recently. Here is the code going just after the "if os.name == 'mac'" proxy handling. elif os.name == 'nt': def getproxies(): """Return a dictionary of scheme -> proxy server URL mappings. Win32 uses the registry to store proxies. """ proxies = {} try: import winreg internetSettings = winreg.OpenKey(winreg.HKEY_CURRENT_USER, "Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings"); proxyEnable = winreg.QueryValueEx(internetSettings, "ProxyEnable")[0] if proxyEnable: # Returned as Unicode but problems occur if not converted to ASCII proxyServer = str(winreg.QueryValueEx(internetSettings, "ProxyServer")[0]) if ";" in proxyServer: # Individual per-protocol settings for p in string.split(proxyServer,";"): protocol, address = string.split(p, "=") proxies[protocol] = '%s://%s' % (protocol, address) else: # Use one setting for all protocols proxies['http'] = 'http://%s' % proxyServer proxies['ftp'] = 'ftp://%s' % proxyServer internetSettings.Close() except: # proxies already set up to be empty so nothing to do pass return proxies Neil From esr@thyrsus.com Wed Jul 12 15:56:31 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Wed, 12 Jul 2000 10:56:31 -0400 Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.18134.550769.266956@beluga.mojam.com> References: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> <14699.18134.550769.266956@beluga.mojam.com> Message-ID: <20000712105631.A1472@thyrsus.com> Skip Montanaro : > Fred> At one point, we were discussing having specializations of > Fred> SyntaxError, and I posted a patch that defined IndentationError > Fred> and TabError. > > I think you should go for it. As long as they are subclasses of SyntaxError > no existing code should break. For whatever it's worth, I agree. -- Eric S. Raymond According to the National Crime Survey administered by the Bureau of the Census and the National Institute of Justice, it was found that only 12 percent of those who use a gun to resist assault are injured, as are 17 percent of those who use a gun to resist robbery. These percentages are 27 and 25 percent, respectively, if they passively comply with the felon's demands. Three times as many were injured if they used other means of resistance. -- G. Kleck, "Policy Lessons from Recent Gun Control Research," From skip@mojam.com (Skip Montanaro) Wed Jul 12 15:40:23 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 12 Jul 2000 09:40:23 -0500 (CDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: References: Message-ID: <14700.33623.201717.133682@beluga.mojam.com> Michael> Think zip as in "zipper"; this more sense to me than naming a Michael> compression algorithm "zip"... Unfortunately, regardless of your background or mine, most of the unwashed masses who will be (and are being) attracted to Python have only seen "zip" in computer contexts as it relates to file compression. To add weight to the connection, Python now has a "zipfile" module... Skip From MarkH@ActiveState.com Wed Jul 12 15:42:43 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Wed, 12 Jul 2000 10:42:43 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <3969FD17.487DA96A@interet.com> Message-ID: Sorry for the delay in responding to this stuff - Im at the MS PDC, and demoing a new Python compiler that I'm suddenly allowed to talk about - but that isnt the point of this mail :-] > This is really bad. Normally under Windows, DLL names do not change > unless the API exported is changed in a major way. For example, > there have been several versions of mfc42.dll without changing the > name. Yes, and each of these versions has broken various programs. Of all people, Im surprised to see you falling for the MS hype, Jim. MS have openly admitted, on a number of occasions, that Windows has "DLL hell", and has made a huge effort to address this in the .NET framework. The Python community has itself been bitten by "bogus" MFC42.dll files that MS profess to be compatible. If MS can't get it right with their resources, I don't like our chances! > What this means is that if the new Python 2.0 (1.6?) simply names > its DLL python15.dll just as before, everything Just Works almost. > That is, it Just Works provided that foo.pyd only calls Python > C functions whose interface has not changed. IMO, this constrains us too much. We can't afford this - we simply dont have the resources. > You can support Python 1.5 and 1.6 by removing the python*.dll > from the Windows directories, and putting it in the directory > of python.exe so it goes with the proper executable. We have discussed this over and over and over, ad nauseum. If you believe the earlier discussions were bunk, please refute them. Otherwise, simply re-asserting something that we have previously proven to be incorrect doesnt help anyone. > > trying to solve here? So far, the only problem that came up was that > > on Windows, you get an obscure crash when trying to load an extension > > built for Python 1.5(.x). > > Yes, and this is a major problem, and is un-Windows-like. :-) "Major Crashes" are un-Windows like? What is happening to this group - It amusing that this statement could be made without the Linux geeks making smart-arsed comments :-) Looks like Billy Boy really _is_ taking over the world :-) > No, just keep the old name "python15.dll". Old foo.pyd will > still work if they use only Python C functions with the same > interface. And as long as we go to extraordinary efforts to maintain binary compatibility. We are under resourced as it is - I dont believe we can do this. > Individual *.pyd authors will have to advise users whether > they need to upgrade to new *.pyd versions or not. This is where we are now. I agree that we should not crash, but it seems to me you havent solved anything - individual .pyd authors needing to tell users about each individual .pyd isnt a solution. > > You can already get the version string by > > looking at Py_GetVersion() -- this also answers the question of how a > > version is represented. > > True. And on Windows, there is a standard Version resource > string which gives the DLL version, and can be read without > loading the DLL. This string is referenced by the Wise (and > other) installers to decide whether a DLL is newer and should > be replaced. Im not sure how this helps us. Do you mean that "initfoo" should use the Windows resource/version APIs to determine if it can load? > > On Windows, link-time compatibility is broken whenever we change the > > second digit of the version number, e.g. 15, 16, 20. > > Yikes, lets not let that happen! Ideally, I agree. However, Im not sure how we can make this happen! Any ideas on how we can achieve this? And I mean in a practical sense, rather than with a hand-waving abstract theory - ie, specifically what developement practices should change, or be put in place, to ensure this? Mark. From bwarsaw@beopen.com Wed Jul 12 15:45:38 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 10:45:38 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> Message-ID: <14700.33938.765976.193911@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> I believe the correct approach would be to have ./configure GS> look for zlib. If present, then it should include the module GS> into the build. [ this auto-build style could apply to many GS> modules, actually ] It would have to check the libz version number. Older versions will core Python. -Barry From bwarsaw@beopen.com Wed Jul 12 15:46:19 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 10:46:19 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> <20000712075915.A17856@newcnri.cnri.reston.va.us> Message-ID: <14700.33979.832366.278311@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> I'm working on a patch for using a setup.py file and the AK> Distutils to build the standard library; Setup.in then AK> contains only those few modules needed to run the Distutils, AK> and you'd never need to modify it. Not done yet, though... +10 From MarkH@ActiveState.com Wed Jul 12 15:47:40 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Wed, 12 Jul 2000 10:47:40 -0400 Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length In-Reply-To: <14698.15423.878220.203259@bitdiddle.concentric.net> Message-ID: > Tuple, List, String, and Dict have a PyXXX_Size method. The abstract > object interface uses PySequence_Length. This is inconsistent and > hard to remember. Can we add PySequence_Size and mark Length as > deprecated? I definately prefer "length" - for example, with Unicode, PyUnicode_Size() implies the number of bytes (the size of the data structure) while PyUnicode_Length() implies the number of characters. Mark. From skip@mojam.com (Skip Montanaro) Wed Jul 12 15:50:54 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 12 Jul 2000 09:50:54 -0500 (CDT) Subject: [Python-Dev] no test_posix, test_os or test_sys? Message-ID: <14700.34254.159786.213828@beluga.mojam.com> I decided I better examine the posix.isatty patch assigned to me before Guido kicks me out... I was a little annoyed it didn't include a new test case. I figured, "oh well, I'll just add one to test_posix.py". Oh Lord! No test_posix.py or test_os.py! (No test_sys.py either!) These are some of the most heavily used modules in Python. They deserve test cases... Unless someone has strenuous objections, I'm going to post something on c.l.py asking for volunteers to write test cases for each of these three. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From thomas@xs4all.net Wed Jul 12 15:58:52 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 16:58:52 +0200 Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: <14700.34254.159786.213828@beluga.mojam.com>; from skip@mojam.com on Wed, Jul 12, 2000 at 09:50:54AM -0500 References: <14700.34254.159786.213828@beluga.mojam.com> Message-ID: <20000712165852.J7340@xs4all.nl> On Wed, Jul 12, 2000 at 09:50:54AM -0500, Skip Montanaro wrote: > I decided I better examine the posix.isatty patch assigned to me before > Guido kicks me out... I was a little annoyed it didn't include a new test > case. I wasn't entirely certain how to test this. Can we rely on stdin/stdout being a terminal, inside tests ? I think not. It can be tested by test_pty and/or test_openpty, but then failure can mean two things: pty.openpty() failed, or isatty() failed. Or we can open an fd and make sure os.isatty() returns 0 for that. None of it seemed very sensible. (I did write the test_pty/test_openpty modules with this in mind, though: ## # Please uncomment these if os.isatty() is added. ## if not os.isatty(master_fd): ## raise TestFailed, "master_fd is not a tty" ## if not os.isatty(slave_fd): ## raise TestFailed, "slave_fd is not a tty" So if you accept the patch, please uncomment those lines ;) However, isatty() is a *very* simple wrapper around a very basic C function, so I didn't think it warranted a test case. (Like you pointed out, none of the other functions in posixmodule have test cases.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip@mojam.com (Skip Montanaro) Wed Jul 12 16:01:46 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 12 Jul 2000 10:01:46 -0500 (CDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14700.25459.555611.544163@bitdiddle.concentric.net> References: <14700.25459.555611.544163@bitdiddle.concentric.net> Message-ID: <14700.34906.286143.800770@beluga.mojam.com> SyntaxError: dedent does not match any outer indentation level Isn't something like "line indented incorrectly" sufficient to alert the programmer to an indentation on that line? Perhaps Python doesn't need to tell which direction to push the line. Skip From akuchlin@mems-exchange.org Wed Jul 12 16:06:37 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 12 Jul 2000 11:06:37 -0400 Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: <14700.34254.159786.213828@beluga.mojam.com>; from skip@mojam.com on Wed, Jul 12, 2000 at 09:50:54AM -0500 References: <14700.34254.159786.213828@beluga.mojam.com> Message-ID: <20000712110637.E1363@kronos.cnri.reston.va.us> On Wed, Jul 12, 2000 at 09:50:54AM -0500, Skip Montanaro wrote: >No test_posix.py or test_os.py! (No test_sys.py either!) These are some of >the most heavily used modules in Python. They deserve test cases... Note that you might want to break it up into subtests; for example, test_fork.py tests os.fork() already. So you could have one test case for file-related operations, another for uid-related, etc. A full test_os.py would be huge and ungainly. (I've speculated about adding a unit testing framework, similar to the one we use internally at the MEMS Exchange; the discipline of using it makes writing a test more time-consuming, but the tests also wind up being more comprehensive.) --amk From skip@mojam.com (Skip Montanaro) Wed Jul 12 16:11:44 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 12 Jul 2000 10:11:44 -0500 (CDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C4F7D.288B561D@schneider-kamp.de> References: <396C4F7D.288B561D@schneider-kamp.de> Message-ID: <14700.35504.551569.956243@beluga.mojam.com> Peter> off-topic: Peter> I am still thinking about higher order functions in Python: Peter> e.g.: map(+ 1, [1, 2, 3]) instead of map(lambda x: x + 1, [1, 2, 3]) Peter> don't have a clue how to do that yet. That would be [x + 1 for x in [1,2,3]] of course... ;-) Skip From jack@oratrix.nl Wed Jul 12 16:16:19 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 17:16:19 +0200 Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: Message by Andrew Kuchling , Wed, 12 Jul 2000 11:06:37 -0400 , <20000712110637.E1363@kronos.cnri.reston.va.us> Message-ID: <20000712151620.1C31437186D@snelboot.oratrix.nl> > Note that you might want to break it up into subtests; for example, > test_fork.py tests os.fork() already. So you could have one test case > for file-related operations, another for uid-related, etc. A full > test_os.py would be huge and ungainly. +1. If the tests would also do the import in the right way, i.e. test_os_symlink would do a "from os import symlink", then on each platform it would only try the tests that are relevant to the platform, while the others would be skipped with an "optional feature couldn't be imported", in stead of crashing the whole test_os. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido@beopen.com Wed Jul 12 17:26:58 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 11:26:58 -0500 Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: Your message of "Wed, 12 Jul 2000 09:50:54 EST." <14700.34254.159786.213828@beluga.mojam.com> References: <14700.34254.159786.213828@beluga.mojam.com> Message-ID: <200007121626.LAA14732@cj20424-a.reston1.va.home.com> > Unless someone has strenuous objections, I'm going to post something on > c.l.py asking for volunteers to write test cases for each of these three. +10 --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Wed Jul 12 16:30:48 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 12 Jul 2000 10:30:48 -0500 (CDT) Subject: [Python-Dev] Basic Python statement coverage results Message-ID: <14700.36648.674422.519358@beluga.mojam.com> I added Python statement coverage using my trace module to the stuff that is run nightly on my web site. When you get a chance, please visit http://www.musi-cal.com/~skip/python/Python/dist/src/ From there you will be able to browse both C and Python statement coverage results. Let me know which summary format (browse-by-directory or all-in-one) you like better. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From esr@thyrsus.com Wed Jul 12 16:49:45 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Wed, 12 Jul 2000 11:49:45 -0400 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> References: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> Message-ID: <20000712114945.F1607@thyrsus.com> Guido van Rossum : > What do you think the following code would print? > > for i in (10, 20, 30); j in (1, 2, 3): > print i+j I think thre confusion over ambiguous syntax is telling us that what we need here is to bite the bullet and add a keyword to the language so there is a clear distinction from existing concepts. I make so bold as to sugest this: for i in (10, 20, 30) with j in (1, 2, 3): print i+j However, I have to say that having meditated on this design problem at some length I now think proliferating new control structures is the wrong answer. Instead, I propose that we look for ways to make smarter data structures drive control. Concretely. this approach would make `with' a data contructor, throw out the parallel-loop syntax, and write the following: >>> [2] with [3] [(2, 3)] >>> (10, 20, 30) with (1, 2, 3) ((10, 1), (20, 2), (30, 3)) >>> for (i, j) in (10, 20, 30) with (1, 2, 3): print i + j This doesn't instantly give us a way to interpret for (i, j) in (10, 20, 30, 40) with (1, 2): print i + j But suppose that the semantics of `with' were that it joins parallel arguments as far as it can and stops whenever it runs out of elements in any one argument. Then, >>> (10, 20, 30, 40) with (1, 2) ((10, 1), (20,2)) Problem solved. Now let's make life easier. The `with' keyword can actually become an n-adic intrinsic function, analogous to `range'. Now we write >>> for (i, j) in with((10, 20, 30, 40), (1, 2)): print i + j Presto! All need for parallel loops has now disappeared. If anyone doubts this, I will cheerfully produce source code for with(). -- Eric S. Raymond It is proper to take alarm at the first experiment on our liberties. We hold this prudent jealousy to be the first duty of citizens and one of the noblest characteristics of the late Revolution. The freemen of America did not wait till usurped power had strengthened itself by exercise and entangled the question in precedents. They saw all the consequences in the principle, and they avoided the consequences by denying the principle. We revere this lesson too much ... to forget it -- James Madison. From esr@thyrsus.com Wed Jul 12 16:55:07 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Wed, 12 Jul 2000 11:55:07 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.31592.410628.754071@anthem.concentric.net> References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> Message-ID: <20000712115507.G1607@thyrsus.com> Barry A. Warsaw : > Range literals I can see as being worth it. I wonder if parallel for > loops can't be handled more gracefully with a function -- isn't it > just a nice wrapper around a specific call to map() anyway? > > List comprehensions do seem to need more syntactic support, but the > ambiguity of the semantics bothers me. I agree with both evaluations, and have just posted a proposal to replace parallel for-loops with a new data constructor. (I still like list comprehensions. But they need to be cleaner.) -- Eric S. Raymond Question with boldness even the existence of a God; because, if there be one, he must more approve the homage of reason, than that of blindfolded fear.... Do not be frightened from this inquiry from any fear of its consequences. If it ends in the belief that there is no God, you will find incitements to virtue in the comfort and pleasantness you feel in its exercise... -- Thomas Jefferson, in a 1787 letter to his nephew From Fredrik Lundh" here are a bunch of other syntax error subclasses that might be useful: class StatementError(SyntaxError): "you cannot use this statement here" class AssignmentError(StatementError): "you cannot assign to this target" class CompilerError(SyntaxError): "sorry, this is a compiler restriction, not really a language = restriction" class LimitError(CompilerError): "exceeded compiler limit" class TokenError(SyntaxError): "you cannot use this token here" class FunctionError(SyntaxError): "there's something wrong with this function/method declaration" class ArgumentError(FunctionError): "the argument declaration isn't correct" here's how they're used in the current interpreter (before the TabError/IndentationError patches): =20 ArgumentError: "duplicate keyword argument" ArgumentError: "keyword can't be an expression" ArgumentError: "non-default argument follows default argument" ArgumentError: "non-keyword arg after keyword arg" AssignmentError: "can't assign to ()" AssignmentError: "can't assign to []" AssignmentError: "can't assign to function call" AssignmentError: "can't assign to lambda" AssignmentError: "can't assign to literal" AssignmentError: "can't assign to operator" LimitError: "expression too long" LimitError: "more than 255 arguments" StatementError: "'break' outside loop" StatementError: "'continue' not properly in loop" StatementError: "'return' outside function" StatementError: "default 'except:' must be last" StatementError: "name is local and global" SyntaxError: "invalid syntax" SyntaxError: "unexpected EOF while parsing" SyntaxError: "unknown parsing error" TabError: "inconsistent use of tabs and spaces in indentation" TokenError: "invalid token" comments? (I'm extra interested in arguments from people who think TabError and IndentationError is a good idea, but that this one sucks. I'm not sure I want to hear from people who thinks that this one is a great idea ;-) ... on a more serious note, I think it would be great to add a distinct attribute to the SyntaxError instance (an error number, most likely). this could be used by an IDE to provide concise info without having to parse the error message. I'll post a more complete proposal later... cheers /F From Fredrik Lundh" Message-ID: <009901bfec17$f7bb1860$f2a6b5d4@hagrid> neil wrote: > Is there any reason why urllib uses environment variables for proxy > settings on Win32? Its quite unlikely they will be set up and there is = a > standard registry location for this information. probably only laziness -- winreg is a recent addition, after all. > I've added retrieval of registry settings to my copy of urllib and = it > seems to work OK athough I'm not running off CVS and I recall the = winreg > module has changed recently. Here is the code going just after the "if > os.name =3D=3D 'mac'" proxy handling. +1 from here. cheers /F From paul@prescod.net Wed Jul 12 16:39:51 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 10:39:51 -0500 Subject: [Python-Dev] listcomp / par-for (summary) References: <20000712161328.I7340@xs4all.nl> Message-ID: <396C9147.F4A4BE4F@prescod.net> Thanks for the summary. Here's my 1p. Thomas Wouters wrote: > >... > > Basically, what's been said is that list comprehensions as they are, are too > confusing. I haven't hear that many people say that, but not many people > objected to those that did say it, and plenty of alternative syntaxes were > proposed. I think that a lot of the confusion came with the conflation with parallel-for. Any concept is hard to follow when the syntax is changing hourly. -- Re: alternatives for listcomp: Another option is: [ : : <....>: ] -- RE: parallel for: Are there any arguments AGAINST using something like zip for a parallel for-loop a function? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Wed Jul 12 16:40:11 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 10:40:11 -0500 Subject: [Python-Dev] listcomp / par-for (summary) References: <20000712161328.I7340@xs4all.nl> Message-ID: <396C915B.8B1A3A1B@prescod.net> Here's my other 1p. > The range-literal thing ([:10:2] -> [0,2,4,6,8]) seems to be acceptable, I > believe ? It might 'merely' be syntactic sugar for a builtin, but it's > such pretty sugar ! :-) Let me play devil's advocate to make sure this is fleshed out enough. How's this for obfuscation: [0:10][0:10][0:10] --- And arguing from analogy, shouldn't range(0:bignum)[0:10:2] be [0:10:2] > And it's not possible to shadow the builtin like with range. You probably shouldn't be able to shadow most builtins period. > (Though I have one possible addition to the range syntax: range tuples, like > so: > > (20:10:3) I presume you meant (10:20:3). Right? > They could just generate a rangeobject, like xrange does... That could be a > fair bit of memory savings ;) But I have to admit the syntax isn't as > obvious as [19:15:-1]) I don't follow you here. Anyhow, I like the idea that there should be a syntax that does the rangeobject thing and it makes sense that it needs to be immutable. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Fredrik Lundh" using my latest Python 2.0 build, the interpreter bombs if I type the following two commands: >>> def a(b): ... global b ... (1.5.2 says "name is local and global"). From paul@prescod.net Wed Jul 12 16:44:45 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 10:44:45 -0500 Subject: [Python-Dev] Unit testing... References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> Message-ID: <396C926D.F223E686@prescod.net> Andrew Kuchling wrote: > > ... > > (I've speculated about adding a unit testing framework, similar to the > one we use internally at the MEMS Exchange; the discipline of using it > makes writing a test more time-consuming, but the tests also wind up > being more comprehensive.) I think PyUnit/JUnit and friends are in vogue these days. There is some virtue in having a framework that could be used also by extension module writers so that there is some consistency about finding and invoking tests. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Wed Jul 12 17:01:37 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 11:01:37 -0500 Subject: [Python-Dev] zip() and list-comprehension with commas References: <396BA425.2EF3B11F@prescod.net> <14699.59823.710880.896491@anthem.concentric.net> <14700.32671.461502.666561@beluga.mojam.com> Message-ID: <396C9661.3EF03755@prescod.net> Skip Montanaro wrote: > > BAW> Alternatives (as Greg I think brought up): pairwise(), maybe > BAW> zipper() for zip() since it's more evocative. > > "zip" already has a lot of compression connotations. How about "stitch", as > in "stitch two lists together"? "Stitch" and "with" are okay, but I'd like to hear someone debunk the names used today by MAL. They seemed very logical to me. I'd just change the semantics to be lazy in a couple of cases. >>> tuple([1,2,3]) (1,2,3) >>> tuples([1,2,3],[4,5,6]) >>> list((1,2,3)) [1,2,3] >>> lists((1,2,3),(4,5,6)) >>> dict([(1,2),(3,4),(5,6)]) {1:2,3:4,5:6} -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov@inrialpes.fr Wed Jul 12 17:13:19 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 18:13:19 +0200 (CEST) Subject: [Python-Dev] Re: merging my*.h into pyport.h In-Reply-To: <396B4850.A3D1A1A2@stud.ntnu.no> from "Peter Schneider-Kamp" at Jul 11, 2000 04:16:16 PM Message-ID: <200007121613.SAA29910@python.inrialpes.fr> Peter Schneider-Kamp wrote: > > What do you think would be appropriate? I have been toying around > with the my*.h headers a bit and loaded up a "proof of concept" patch > that makes all my*.h obsolete. Where's the patch? ... Ah, found it - assigned to / postponed by nowonder. This include business is tricky. I for one am against seeing mymalloc.h moved to pyport.h. It doesn't belong there and deserves a file on its own. If my*.[ch] files really disturb you, you can make them obsolete by renaming them to py*.[ch] :-). ~/python/dev> ls Include/my* Include/mymalloc.h Include/myproto.h Include/mytime.h Include/mymath.h Include/myselect.h - feel free to move to pyport.h both myproto.h and mymath.h (as you did) - mymalloc.h shouldn't be touched. You may eventyally want to rename it to pymalloc.h - not sure what to do with mytime.h and myselect.h - not sure whether it's worth renaming my*.c to py*.c > > P.S.: What's the status of sre? I just ask because test_re > keeps nagging all the time. :-] The problem is that /F has no idea where this bug comes from, and the suspicions he had about memory glitches in the SRE code haven't been confirmed by Barry's Purify analyses so far. I did some testing too, but found only unrelated buglets. I second Barry's opinion that the memory picture of the CVS snapshot is good enough. So this seems to be a bug related with the logic of the code, in an area where Barry and I have already publicly qualified ourselves as clueless. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From skip@mojam.com (Skip Montanaro) Wed Jul 12 17:25:57 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 12 Jul 2000 11:25:57 -0500 (CDT) Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: <20000712165852.J7340@xs4all.nl> References: <14700.34254.159786.213828@beluga.mojam.com> <20000712165852.J7340@xs4all.nl> Message-ID: <14700.39957.204774.928368@beluga.mojam.com> Thomas> (I did write the test_pty/test_openpty modules with this in Thomas> mind, though: Thomas> ## # Please uncomment these if os.isatty() is added. Thomas> ## if not os.isatty(master_fd): Thomas> ## raise TestFailed, "master_fd is not a tty" Thomas> ## if not os.isatty(slave_fd): Thomas> ## raise TestFailed, "slave_fd is not a tty" Thomas> So if you accept the patch, please uncomment those lines ;) Will do. Thomas> However, isatty() is a *very* simple wrapper around a very basic Thomas> C function, so I didn't think it warranted a test case. (Like Thomas> you pointed out, none of the other functions in posixmodule have Thomas> test cases.) My message wasn't motivated so much with the missing test case for isatty, but that there are no regression tests at all for os, posix or sys. Skip From thomas@xs4all.net Wed Jul 12 17:26:56 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 18:26:56 +0200 Subject: [Python-Dev] listcomp / par-for (summary) In-Reply-To: <396C915B.8B1A3A1B@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 10:40:11AM -0500 References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> Message-ID: <20000712182656.K7340@xs4all.nl> On Wed, Jul 12, 2000 at 10:40:11AM -0500, Paul Prescod wrote: > > The range-literal thing ([:10:2] -> [0,2,4,6,8]) seems to be acceptable, > > I believe ? It might 'merely' be syntactic sugar for a builtin, but it's > > such pretty sugar ! :-) > Let me play devil's advocate to make sure this is fleshed out enough. > > How's this for obfuscation: > [0:10][0:10][0:10] Sure, but it's not more obfuscated than a long line of map(lambda ... reduce(filter(map(lambda ... ))) -- it's definately easier to parse for humans ! The parser won't have any trouble with it, if that's what you mean: >>> [:200:2][0:20] [0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38] >>> [:200:2][0:20][10:20] [20, 22, 24, 26, 28, 30, 32, 34, 36, 38] > --- > And arguing from analogy, shouldn't > > range(0:bignum)[0:10:2] be [0:10:2] Yes, it should, but there is no way to enforce it, currently, because range can be shadowed by a local or global variable. And it doesn't have to be unintended, either. With range literals, that's no longer possible. > > And it's not possible to shadow the builtin like with range. > You probably shouldn't be able to shadow most builtins period. Why not ? It would introduce a number of problems: adding new builtin functions would be as cagey as adding new reserved words (in effect, all builtins *become* reserved words.) So it would break a ton of code. It would make extending the builtins practically impossible. It would be very confusing for current Python programmers. Etcetera. > > (Though I have one possible addition to the range syntax: range tuples, > > like so: > > > > (20:10:3) > I presume you meant (10:20:3). Right? Yes, sorry. > > They could just generate a rangeobject, like xrange does... That could be a > > fair bit of memory savings ;) But I have to admit the syntax isn't as > > obvious as [19:15:-1]) > I don't follow you here. Anyhow, I like the idea that there should be a > syntax that does the rangeobject thing and it makes sense that it needs > to be immutable. Well, when I look at '(10:20:3)', it doesn't look like a range, to me. Mostly because it has no precedent in Python: ()'s are used for grouping, and for function calls. They do not create tuples! :) In fact, the '(10:20:3)' syntax reminds me more of dates or machine-addresses than it does of ranges. For that reason I think it's better to live with xrange() ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From DavidA@ActiveState.com Wed Jul 12 17:32:43 2000 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 12 Jul 2000 09:32:43 -0700 (Pacific Daylight Time) Subject: [Python-Dev] more SyntaxError subclasses! In-Reply-To: <009a01bfec17$f7fe3be0$f2a6b5d4@hagrid> Message-ID: On Wed, 12 Jul 2000, Fredrik Lundh wrote: > here are a bunch of other syntax error subclasses that > might be useful: +1. > (I'm extra interested in arguments from people who think TabError > and IndentationError is a good idea, but that this one sucks. I'm > not sure I want to hear from people who thinks that this one is a > great idea ;-) Sorry. =) > on a more serious note, I think it would be great to add a distinct > attribute to the SyntaxError instance (an error number, most likely). > this could be used by an IDE to provide concise info without having > to parse the error message. Indeed. From DavidA@ActiveState.com Wed Jul 12 17:34:36 2000 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 12 Jul 2000 09:34:36 -0700 (Pacific Daylight Time) Subject: [Python-Dev] ! Message-ID: Keeping up w/ python dev, patches and checkins is getting to be a huge amount of work! Should we _thank_ lawyers for turning what was a small intense rush in getting things done before a release into a long intense rush? Perish the thought... +1 on the new python-dev community! --david From mwh21@cam.ac.uk Wed Jul 12 17:48:16 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 12 Jul 2000 17:48:16 +0100 Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: "Fredrik Lundh"'s message of "Wed, 12 Jul 2000 17:31:10 +0200" References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> Message-ID: "Fredrik Lundh" writes: > using my latest Python 2.0 build, the interpreter > bombs if I type the following two commands: > > >>> def a(b): > ... global b > ... Hmm. Mine doesn't. What platform, stack, etc? > (1.5.2 says "name is local and global"). That's what mine says. "ConflictingScopeError" anyone? It's not a syntax error in my book... Cheers, M. From thomas@xs4all.net Wed Jul 12 17:59:20 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 18:59:20 +0200 Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: ; from mwh21@cam.ac.uk on Wed, Jul 12, 2000 at 05:48:16PM +0100 References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> Message-ID: <20000712185920.M7340@xs4all.nl> On Wed, Jul 12, 2000 at 05:48:16PM +0100, Michael Hudson wrote: > "Fredrik Lundh" writes: > > using my latest Python 2.0 build, the interpreter > > bombs if I type the following two commands: > > > > >>> def a(b): > > ... global b > > ... > Hmm. Mine doesn't. What platform, stack, etc? Mine does crash. The crash seems to be caused by a refcounting bug: the error gets detected, com_error() gets called, creates the appropriate error object, control flows back the way it was supposed to, but between com_error and PyErr_PrintEx() the error gets eradicated, resulting in a segmentation fault. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul@prescod.net Wed Jul 12 17:57:57 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 11:57:57 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: Message-ID: <396CA395.D43D9570@prescod.net> Mark Hammond wrote: > > ... > > > On Windows, link-time compatibility is broken whenever we change the > > > second digit of the version number, e.g. 15, 16, 20. > > > > Yikes, lets not let that happen! > > Ideally, I agree. However, Im not sure how we can make this happen! Any > ideas on how we can achieve this? And I mean in a practical sense, rather > than with a hand-waving abstract theory - ie, specifically what > developement practices should change, or be put in place, to ensure this? Someone who is very interested in this backwards compatibility issue could make a stub Python15.dll that exposes the old API with the exact same (old) semantics. If it turns out to be easy, great. If it turns out to be difficult then we know that the APIs changed too much for it to be practical. If programs start crashing, we blame the person who promised backwads compatibility. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From mwh21@cam.ac.uk Wed Jul 12 18:01:47 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 12 Jul 2000 18:01:47 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: "Mark Hammond"'s message of "Wed, 12 Jul 2000 10:42:43 -0400" References: Message-ID: "Mark Hammond" writes: > Sorry for the delay in responding to this stuff - Im at the MS PDC, and > demoing a new Python compiler that I'm suddenly allowed to talk about - but > that isnt the point of this mail :-] ? I'm curious now! [snip] > > > trying to solve here? So far, the only problem that came up was that > > > on Windows, you get an obscure crash when trying to load an extension > > > built for Python 1.5(.x). > > > > Yes, and this is a major problem, and is un-Windows-like. > > :-) "Major Crashes" are un-Windows like? What is happening to this > group - It amusing that this statement could be made without the Linux > geeks making smart-arsed comments :-) Looks like Billy Boy really _is_ > taking over the world :-) I was tempted, it has to be said. I did point a friend at it and giggle. nothing-useful-to-say-ly y'rs M. From thomas@xs4all.net Wed Jul 12 18:04:44 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 19:04:44 +0200 Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: <20000712185920.M7340@xs4all.nl>; from thomas@xs4all.net on Wed, Jul 12, 2000 at 06:59:20PM +0200 References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> <20000712185920.M7340@xs4all.nl> Message-ID: <20000712190444.N7340@xs4all.nl> On Wed, Jul 12, 2000 at 06:59:20PM +0200, Thomas Wouters wrote: > On Wed, Jul 12, 2000 at 05:48:16PM +0100, Michael Hudson wrote: > > "Fredrik Lundh" writes: > > Hmm. Mine doesn't. What platform, stack, etc? > > Mine does crash. Eh, Linux (RedHat 6.1), both 2.0b1-CVS-tree (recent) and python 1.6a2 (couple of weeks old) that is. Traceback of the exception is: #0 PyErr_NormalizeException (exc=0xbffff718, val=0xbffff71c, tb=0xbffff720) at errors.c:170 #1 0x8065501 in PyErr_PrintEx (set_sys_last_vars=1) at pythonrun.c:686 #2 0x80654d6 in PyErr_Print () at pythonrun.c:676 #3 0x80652fa in PyRun_SimpleString (command=0x821fc58 "def a(b): global b\n") at pythonrun.c:601 #4 0x8052a01 in Py_Main (argc=3, argv=0xbffff7d4) at main.c:256 #5 0x8052606 in main (argc=3, argv=0xbffff7d4) at python.c:10 though I doubt it's really helpful, as the actual bug is elsewhere. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mwh21@cam.ac.uk Wed Jul 12 18:21:14 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 12 Jul 2000 18:21:14 +0100 Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: Thomas Wouters's message of "Wed, 12 Jul 2000 19:04:44 +0200" References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> <20000712185920.M7340@xs4all.nl> <20000712190444.N7340@xs4all.nl> Message-ID: Thomas Wouters writes: > On Wed, Jul 12, 2000 at 06:59:20PM +0200, Thomas Wouters wrote: > > On Wed, Jul 12, 2000 at 05:48:16PM +0100, Michael Hudson wrote: > > > "Fredrik Lundh" writes: > > > Hmm. Mine doesn't. What platform, stack, etc? > > > > Mine does crash. > > Eh, Linux (RedHat 6.1), both 2.0b1-CVS-tree (recent) and python 1.6a2 > (couple of weeks old) that is. Oh yeah; the same. Python built from a checkout about half an hour ago (so there's probably only been twenty or so checkins since then...). Next question: gc or not gc? My not crashing one had gc on, am now building one with gc off ... [just got to _sre.c] ... Nope. Steady as a rock. I'll leave this one to someone who has a problem! Cheers, M. From Moshe Zadka Wed Jul 12 18:26:34 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 12 Jul 2000 20:26:34 +0300 (IDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <20000712114945.F1607@thyrsus.com> Message-ID: On Wed, 12 Jul 2000 esr@thyrsus.com wrote: > Presto! All need for parallel loops has now disappeared. If anyone > doubts this, I will cheerfully produce source code for with(). Ummm.....you mean def with(*args): apply(map, (None,)+args) ;-) (Actually, this isn't right, since map() adds None's instead of stopping. But that should be a considered a design bug in map() anyway) What would people think about xmap(), which acts anologously to xrange(), IOW calculate lazilly instead of eagerly? Or even, calculate "on demand", without caching: class xmap: def __init__(self, func, *args): self.func = func self.args = args def __getitem__(self, i): arg = [None]*len(self.args) for j in range(len(self.args)): arg[j] = self.args[j][i] return apply(self.func, arg) Wouldn't this solve the parallel iteration problem? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul@prescod.net Wed Jul 12 18:25:36 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 12:25:36 -0500 Subject: [Python-Dev] Ranges References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> Message-ID: <396CAA0F.FE42AFD0@prescod.net> Thomas Wouters wrote: > > > How's this for obfuscation: > > > [0:10][0:10][0:10] > > Sure, but it's not more obfuscated than a long line of map(lambda ... > reduce(filter(map(lambda ... ))) I'm just commenting on the overloaded syntax of list construction and truncation. No big deal. > > And arguing from analogy, shouldn't > > > > range(0:bignum)[0:10:2] be [0:10:2] > > Yes, it should, but there is no way to enforce it, currently, because range > can be shadowed by a local or global variable. And it doesn't have to be > unintended, either. With range literals, that's no longer possible. That's not what I mean. Ignore the range. My point is, if list construction and truncation are going to be parallel, they should be really parallel. [0,1,2,3,4,5,6,7,8,10][0:5:2]==[0:5:2] I don't understand "extended slicing" so I don't know why the former doesn't work today. > > You probably shouldn't be able to shadow most builtins period. > > Why not ? It would introduce a number of problems: adding new builtin > functions would be as cagey as adding new reserved words (in effect, all > builtins *become* reserved words.) I said "most", not "all". Over time they could migrate from being builtin to being non-overridable. No one should define a function (not method, but function) called "map" or "dir". In practice, I haven't seen such a thing. If we make a "tuples" function then for a year or two it is fair game for overriding, the it becomes frozen. > For that reason I think it's better to live with xrange() ;) You could also use a lazy list comprehension (if we made list comprehensions lazy): [for x in [0:10:20]: x] That would make people think twice about using xrange (as it should...xrange isn't usually as efficient as they think!) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Moshe Zadka Wed Jul 12 18:32:06 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 12 Jul 2000 20:32:06 +0300 (IDT) Subject: [Python-Dev] listcomp / par-for (summary) In-Reply-To: <396C915B.8B1A3A1B@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > > And it's not possible to shadow the builtin like with range. > > You probably shouldn't be able to shadow most builtins period. I vehemently disagree. One reason we can add builtins to our hearts contents is that builtins do not interfere with current code base in a way that keywords do. OTOH, I see no reason to reward this behaviour: I'm currently considering an optimization to the interpreter which would mean that most code would run faster, but code that shadows builtins would run slower. (This ideas is bouncing around my head for a long while. I'll post here when I have some semblence of design ready) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Vladimir.Marangozov@inrialpes.fr Wed Jul 12 20:29:43 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 21:29:43 +0200 (CEST) Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: <009101bfec16$35495fe0$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 12, 2000 05:31:10 PM Message-ID: <200007121929.VAA09996@python.inrialpes.fr> Fredrik Lundh wrote: > > using my latest Python 2.0 build, the interpreter > bombs if I type the following two commands: > > >>> def a(b): > ... global b > ... > > (1.5.2 says "name is local and global"). > > > Yes. This is because PyErr_PrintEx() is invoked with a NULL exception. And the exception has been cleared cleared in get_inprogress_dict(). The appended patch should fix it. Let me know whether it works for you. Jeremy, what's the point of calling PyErr_Clear() in get_inprogress_dict()? -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 ------------------------------[ cut here ]---------------------------- *** CVS/Objects/object.c Wed Jul 12 17:27:41 2000 --- dev/Objects/object.c Wed Jul 12 21:21:52 2000 *************** *** 356,362 **** } inprogress = PyDict_GetItem(tstate_dict, _PyCompareState_Key); if (inprogress == NULL) { - PyErr_Clear(); inprogress = PyDict_New(); if (inprogress == NULL) return NULL; --- 356,361 ---- From pingster@ilm.com Wed Jul 12 20:26:51 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 12:26:51 -0700 (PDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14700.25459.555611.544163@bitdiddle.concentric.net> Message-ID: On Wed, 12 Jul 2000, Jeremy Hylton wrote: > File "", line 4 > def foo(bar): > ^ > SyntaxError: dedent does not match any outer indentation level [...] > I don't know what a dedent is. Nor do I know what "outer indentation > levels" are or how they might apply to the line "def foo(bar):". Sorry, this is a transcript from my locally compiled Python. The actual patch says "unindent" rather than "dedent". (In this situation Python 1.5 prints a line to stderr saying "inconsistent dedent" but the SyntaxError only says "invalid syntax".) The intended meaning is "this line is less indented than the previous one, but i can't determine what block it goes with because there's no surrounding block indented at the same level". In short form, this became: "unindent does not match any outer indentation level". -- ?!ng From pingster@ilm.com Wed Jul 12 20:31:01 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 12:31:01 -0700 (PDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <396C2D00.BDA23AF2@lemburg.com> Message-ID: tuples(), lists(), dict(), and indices() look pretty generally useful to me. I agree that they look like good candidates for builtins. On Wed, 12 Jul 2000, M.-A. Lemburg wrote: > irange(object[,indices]) > Builds a tuple of tuples (index, object[index]). If a sequence > indices is given, the indices are read from it. If not, then > the index sequence defaults to trange(len(object)). This one in particular looks really fabulous. +1 to put this in builtins. In order of usefulness (just imho of course): irange +1 tuples +0.5 indices +0.5 dict +0 lists +0 -- ?!ng From thomas@xs4all.net Wed Jul 12 20:40:03 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 21:40:03 +0200 Subject: [Python-Dev] SyntaxError patches In-Reply-To: ; from pingster@ilm.com on Wed, Jul 12, 2000 at 12:26:51PM -0700 References: <14700.25459.555611.544163@bitdiddle.concentric.net> Message-ID: <20000712214003.P7340@xs4all.nl> On Wed, Jul 12, 2000 at 12:26:51PM -0700, Ka-Ping Yee wrote: > On Wed, 12 Jul 2000, Jeremy Hylton wrote: > > File "", line 4 > > def foo(bar): > > SyntaxError: dedent does not match any outer indentation level > [...] > > I don't know what a dedent is. Nor do I know what "outer indentation > > levels" are or how they might apply to the line "def foo(bar):". > The intended meaning is "this line is less indented than the previous > one, but i can't determine what block it goes with because there's > no surrounding block indented at the same level". In short form, this > became: "unindent does not match any outer indentation level". If the objective is to make error messages more accessible understandable to newbies, how about: Can't figure out where this statement belongs or Can't figure out what block this statement belongs to or Can't figure out where you wanted to place this line or There seems to be something wrong with the indentation of this line etc. Or they could be more Monty Python-esque. Anyone use the unix util 'screen', and its 'nethack' mode ? Excellent tool, both ways :-) Since these are syntax errors, not runtime errors, I'd say it's safe to use a more accusing stance to the viewer (that is, they're very likely to be the cause !) and I don't really see why all error messages should be mathematically correct, and thus phrased in some kind of lawyerese ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From pingster@ilm.com Wed Jul 12 20:48:54 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 12:48:54 -0700 (PDT) Subject: [Python-Dev] Ranges In-Reply-To: <396CAA0F.FE42AFD0@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > That's not what I mean. Ignore the range. My point is, if list > construction and truncation are going to be parallel, they should be > really parallel. > > [0,1,2,3,4,5,6,7,8,10][0:5:2]==[0:5:2] Did you think they were different? I thought they *were* parallel. I would expect: >>> range(0, 5, 2) [0, 2, 4] >>> [0:5:2] [0, 2, 4] >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] [0, 2, 4] >>> range(1000)[0:5:2] [0, 2, 4] Right? Am i misunderstanding how [x:y:z] should work? -- ?!ng From paul@prescod.net Wed Jul 12 21:03:29 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 15:03:29 -0500 Subject: [Python-Dev] Ranges References: Message-ID: <396CCF11.B5593E2C@prescod.net> Ka-Ping Yee wrote: > > >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] > [0, 2, 4] Well, today this is syntactically correct but it doesn't work as you (or I) predict. I don't know if that's because nobody has implemented it yet or if extended slices mean something other than what I think you and I think they should mean: Python 2.0b1 (#12, Jul 1 2000, 13:14:33) Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] Traceback (most recent call last): File "", line 1, in ? TypeError: sequence index must be integer The documentation on extended slicing is very thin, but if it doesn't do this, I'm not sure what it does! -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Ka-Ping Yee Wed Jul 12 21:22:07 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Wed, 12 Jul 2000 13:22:07 -0700 (PDT) Subject: [Python-Dev] Ranges In-Reply-To: <396CCF11.B5593E2C@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > Python 2.0b1 (#12, Jul 1 2000, 13:14:33) > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] > Traceback (most recent call last): > File "", line 1, in ? > TypeError: sequence index must be integer Yeah. At the moment, [:] calls __getslice__ but [::] calls __getitem__ (ick). The list object is getting a call to __getitem__(slice(0, 5, 2)) and __getitem__ wants an integer. I was assuming this would get cleaned up along with the introduction of [x:y:z]-style range-makers (i recall Guido posting a suggestion for how to do so a little while back). Ah, yes: http://www.python.org/pipermail/python-dev/2000-July/012681.html The issues were - handling [:] and [::] consistently - allowing non-integer indices - letting user-defined objects do their own handling of negative indices I believe the two possibilities were __getitem__ gets either an index or a special slice object __getslice__ is deprecated (when missing, __getitem__ gets the slice args) and __getitem__ always gets an index __getslice__ gets three arguments, all optional, defaulting to None The latter isn't backward-compatible, but it makes a heckuva lot more sense. -- ?!ng From barry@scottb.demon.co.uk Wed Jul 12 21:30:45 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Wed, 12 Jul 2000 21:30:45 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Message-ID: <000001bfec40$0eb3a6e0$060210ac@private> > This is where we are now. I agree that we should not crash, but it seems > to me you havent solved anything - individual .pyd authors needing to tell > users about each individual .pyd isnt a solution. At least if Python can detect that a .PYD is out of date you know to ask for a newer .PYD or build it yourself. A crash is bad PR for the .PYD and Python. > > > You can already get the version string by > > > looking at Py_GetVersion() -- this also answers the question of how a > > > version is represented. > > > > True. And on Windows, there is a standard Version resource > > string which gives the DLL version, and can be read without > > loading the DLL. This string is referenced by the Wise (and > > other) installers to decide whether a DLL is newer and should > > be replaced. > > Im not sure how this helps us. Do you mean that "initfoo" should use the > Windows resource/version APIs to determine if it can load? As I pointed out you cannot use Py calls from a .PYD to find out the version as the .PYD calls the function in the old PYTHON15.DLL not the new one. BArry From paul@prescod.net Wed Jul 12 18:44:29 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 12:44:29 -0500 Subject: [Python-Dev] re: list comprehension / pop quiz References: Message-ID: <396CAE7D.B85AA3FB@prescod.net> Moshe Zadka wrote: > > What would people think about xmap(), which acts anologously to xrange(), > IOW calculate lazilly instead of eagerly? Or even, calculate "on demand", > without caching: > .... > Wouldn't this solve the parallel iteration problem? I don't think that using a function called "xmap" to build tuples is very intuitive to start with. What's so wrong with a builtin called "tuples()"? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Wed Jul 12 19:10:56 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 13:10:56 -0500 Subject: [Python-Dev] Par-for/range References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> Message-ID: <396CB4B0.EE284A39@prescod.net> Thomas Wouters wrote: > > ... > > For that reason I think it's better to live with xrange() ;) Thinking some more... If we had first class range syntax then it would be relatively easy to recognize the pattern for i in [x:y:z]: .... Then we could generate a special FOR_INTS bytecode. I've heard that "C" has a pretty efficient implementation of that construct. That would wipe out 96.3% of the need for xrange or tuplerange or whatever you want to call it. We could probably deprecate both functions and let the rare person who really wants an xrange use a class or math.xrange() or mxtools.xrange() or a lazy list comprehension (if we invent those!). Plus, if your loops are so large that they need xrange, you would probably get an interesting speedup from using a real C for-loop instead of an object! I mean for small values xrange is slower than range and when you think about what range is doing under the covers. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gvwilson@nevex.com Wed Jul 12 21:47:44 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Wed, 12 Jul 2000 16:47:44 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <396CAE7D.B85AA3FB@prescod.net> Message-ID: > Paul Prescod wrote: > I don't think that using a function called "xmap" to build tuples is > very intuitive to start with. What's so wrong with a builtin called > "tuples()"? I'm nervous about the readability of "tuple/tuples" and "map/xmap", having sometimes misread "xrange" for "range". (We take marks off student assignments that contain functions whose names only differ by one letter, don't we?) Greg From mwh21@cam.ac.uk Wed Jul 12 22:03:53 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 12 Jul 2000 22:03:53 +0100 Subject: [Python-Dev] Par-for/range In-Reply-To: Paul Prescod's message of "Wed, 12 Jul 2000 13:10:56 -0500" References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> <396CB4B0.EE284A39@prescod.net> Message-ID: Paul Prescod writes: > Thinking some more... > > If we had first class range syntax then it would be relatively easy to > recognize the pattern > > for i in [x:y:z]: > .... > > Then we could generate a special FOR_INTS bytecode. I've heard that "C" > has a pretty efficient implementation of that construct. Hmm, yes, but how on earth would you implement that in ceval.c? You'd need another eval loop inside the code for FOR_INTS! (unless I'm being dense, of course). > That would wipe out 96.3% of the need for xrange or tuplerange or > whatever you want to call it. We could probably deprecate both functions > and let the rare person who really wants an xrange use a class or > math.xrange() or mxtools.xrange() or a lazy list comprehension (if we > invent those!). > > Plus, if your loops are so large that they need xrange, you would > probably get an interesting speedup from using a real C for-loop instead > of an object! I mean for small values xrange is slower than range and > when you think about what range is doing under the covers. To invent more statistics on the spot, I'll declare that loop overhead is a problem in about 3.4% of all interesting loops; what we need is a way to execute the body quicker... Cheers, M. From thomas@xs4all.net Wed Jul 12 22:19:42 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 23:19:42 +0200 Subject: [Python-Dev] Par-for/range In-Reply-To: <396CB4B0.EE284A39@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 01:10:56PM -0500 References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> <396CB4B0.EE284A39@prescod.net> Message-ID: <20000712231942.Q7340@xs4all.nl> On Wed, Jul 12, 2000 at 01:10:56PM -0500, Paul Prescod wrote: > Thomas Wouters wrote: > > For that reason I think it's better to live with xrange() ;) > If we had first class range syntax then it would be relatively easy to > recognize the pattern > > for i in [x:y:z]: > .... > > Then we could generate a special FOR_INTS bytecode. I've heard that "C" > has a pretty efficient implementation of that construct. Yes. This was one of the reasons Guido was interested in this. (We talked about this in private email before I implemented it ;) > Plus, if your loops are so large that they need xrange, you would > probably get an interesting speedup from using a real C for-loop instead > of an object! I mean for small values xrange is slower than range and > when you think about what range is doing under the covers. Well, with the new 'sq_contains' PySequenceMethods member, the operation: number in xrange(19,23578294,3)*393 # for instance ;) also gets very efficient. A *lot* more efficient than using the equivalent [ra::ge] syntax in any case. That would be one reason to add at least a 'BUILD_XRANGE' bytecode, so when the compiler is made sufficiently intelligent, it could issue 'BUILD_XRANGE' opcodes instead of BUILD_RANGE opcodes for if x in [:y:z]: and other instances where the resulting list isn't stored anywhere, so will never be modified. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Wed Jul 12 22:28:26 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 23:28:26 +0200 Subject: [Python-Dev] Par-for/range In-Reply-To: ; from mwh21@cam.ac.uk on Wed, Jul 12, 2000 at 10:03:53PM +0100 References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> <396CB4B0.EE284A39@prescod.net> Message-ID: <20000712232826.R7340@xs4all.nl> On Wed, Jul 12, 2000 at 10:03:53PM +0100, Michael Hudson wrote: > Paul Prescod writes: > > Thinking some more... > > > > If we had first class range syntax then it would be relatively easy to > > recognize the pattern > > > > for i in [x:y:z]: > > .... > > > > Then we could generate a special FOR_INTS bytecode. I've heard that "C" > > has a pretty efficient implementation of that construct. > Hmm, yes, but how on earth would you implement that in ceval.c? You'd > need another eval loop inside the code for FOR_INTS! (unless I'm > being dense, of course). Nah. We can't use the C for-loop for this, unless the bytecode interpreter is entirely rewritten. The FOR_INT opcode would be something like: on entry, stack contains r, i where r is range-object specifying (start/)step/end, i is loop counter i is incremented by step, checked against end, and if loop hasn't ended yet, r, new 'i' and old 'i' are pushed on the stack, so it contains: r, i+step, i and the rest of the bytecode can remain the same (assign top value to name, etc.) > To invent more statistics on the spot, I'll declare that loop overhead > is a problem in about 3.4% of all interesting loops; what we need is a > way to execute the body quicker... define 'problem' ;) If we can speed things up while keeping the functionality the same, the syntax clearer and the code only slightly more complicated, why not ? :-) Granted, though, if the issue is overall code speed, this isn't going to cut it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gward@mems-exchange.org Wed Jul 12 22:43:39 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 12 Jul 2000 17:43:39 -0400 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <20000711151740.T26534@xs4all.nl>; from thomas@xs4all.net on Tue, Jul 11, 2000 at 03:17:41PM +0200 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> <20000710141638.R29590@lyra.org> <200007111348.IAA04699@cj20424-a.reston1.va.home.com> <20000711151740.T26534@xs4all.nl> Message-ID: <20000712174339.A5836@ludwig.cnri.reston.va.us> On 11 July 2000, Thomas Wouters said: > Actually, I was referring to the trick PIL and other extension modules use > to build their own Makefile based on Python's. I'm not sure how portable > that particular Makefile is, however. I'm one of those types that use > 'gmake' on systems that do not have GNU make as the default make ;-) Makefile.pre.in is obsolete. See http://www.python.org/sigs/distutils-sig/ > And forgive me for saying this, but I think providing a good, > self-configuring but slightly unportable Makefile.pre.in *and* a README > (and/or example) that shows how to do it by hand on old/incapacitated > systems, is preferable over just providing a completely unportable Makefile > and a README that shows how to do it on other systems :-) Agreed, but of course the instructions are different (and much easier!) now. Greg From jack@oratrix.nl Wed Jul 12 22:51:17 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 23:51:17 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib dospath.py,1.13,1.14 macpath.py,1.22,1.23 ntpath.py,1.24,1.25 posixpath.py,1.31,1.32 In-Reply-To: Message by Skip Montanaro , Wed, 12 Jul 2000 09:56:00 -0700 , <200007121656.JAA09687@slayer.i.sourceforge.net> Message-ID: <20000712215122.B4E13E2679@oratrix.oratrix.nl> Skip, one bug in posixpath.commonprefix already: you use os.sep where you should use '/'. The pathname-manging routines in xxxpath have always worked on different platforms too (so you can interpret, say, a tarfile on MSDOS), and if I remember correctly this is especially important for posixpath because it's used in some of the url modules. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From bckfnn@worldonline.dk Wed Jul 12 22:48:11 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Wed, 12 Jul 2000 21:48:11 GMT Subject: [Python-Dev] Ranges In-Reply-To: References: Message-ID: <396ce4b5.20282194@smtp.worldonline.dk> [Paul Prescod] >Ka-Ping Yee wrote: >> >> >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] >> [0, 2, 4] > >Well, today this is syntactically correct but it doesn't work as you (or >I) predict. I don't know if that's because nobody has implemented it yet >or if extended slices mean something other than what I think you and I >think they should mean In current JPython: JPython 1.1+07 on java1.3.0 (JIT: null) Copyright (C) 1997-1999 Corporation for National Research Initiatives >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] [0, 2, 4] [Ka-Ping Yee} >Ah, yes: http://www.python.org/pipermail/python-dev/2000-July/012681.html > >The issues were > > - handling [:] and [::] consistently > - allowing non-integer indices > - letting user-defined objects do their own handling of negative indices > >I believe the two possibilities were > > __getitem__ gets either an index or a special slice object > __getslice__ is deprecated (when missing, __getitem__ gets the slice args) > >and > > __getitem__ always gets an index > __getslice__ gets three arguments, all optional, defaulting to None > >The latter isn't backward-compatible, but it makes a heckuva lot >more sense. AFAICT JPython already follows the first of the two possibilities. (I'm not suggesting what python-the-language should do but I too find the current behaviour of item/slice is IMO confusing). regards, finn JPython 1.1+07 on java1.3.0 (JIT: null) Copyright (C) 1997-1999 Corporation for National Research Initiatives >>> >>> class S1: ... def __getitem__(self, i): ... print "s1.__getitem__", i ... >>> a = S1() >>> >>> a[1] s1.__getitem__ 1 >>> a[:] s1.__getitem__ None:None:1 >>> a[1:2] s1.__getitem__ 1:2:1 >>> a[1:2:3] s1.__getitem__ 1:2:3 >>> a['a':'z'] s1.__getitem__ 'a':'z':1 >>> a['a':'z':2] s1.__getitem__ 'a':'z':2 >>> >>> >>> class S2: ... def __getslice__(self, i, a): ... print "s2.__getslice__", i, a ... def __len__(self): ... return 10 ... >>> a = S2() >>> >>> a[1] Traceback (innermost last): File "", line 1, in ? AttributeError: __getitem__ >>> a[:] s2.__getslice__ 0 2147483647 >>> a[1:2] s2.__getslice__ 1 2 >>> a[1:2:3] Traceback (innermost last): File "", line 1, in ? AttributeError: __getitem__ >>> a['a':'z'] s2.__getslice__ a z >>> a['a':'z':2] Traceback (innermost last): File "", line 1, in ? AttributeError: __getitem__ >>> a[-1:4] s2.__getslice__ -1 4 >>> >>> class S3: ... def __getitem__(self, i): ... print "s3.__getitem__", i ... def __getslice__(self, i, a): ... print "s3.__getslice__", i, a ... >>> a = S3() >>> >>> a[1] s3.__getitem__ 1 >>> a[:] s3.__getslice__ 0 2147483647 >>> a[1:2] s3.__getslice__ 1 2 >>> a[1:2:3] s3.__getitem__ 1:2:3 >>> a['a':'z'] s3.__getslice__ a z >>> a['a':'z':2] s3.__getitem__ 'a':'z':2 >>> From MarkH@ActiveState.com Wed Jul 12 23:11:58 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Wed, 12 Jul 2000 18:11:58 -0400 Subject: [Python-Dev] Python .NET (was Preventing 1.5 extensions crashing under 1.6/2.0 Python) In-Reply-To: Message-ID: > "Mark Hammond" writes: > > > Sorry for the delay in responding to this stuff - Im at the MS PDC, and > > demoing a new Python compiler that I'm suddenly allowed to > talk about - but > > that isnt the point of this mail :-] > > ? I'm curious now! There is a Python compiler available for the Microsoft .NET framework. Much of the press will have details on this emerging. A CNET article can be found at http://news.cnet.com/news/0-1003-200-2240702.html?tag=st.ne.1430735..ni This new compiler could be compared, conceptually, with JPython - it is a completely new implementation of Python. It has a compiler that generates native Windows .DLL/.EXE files. It uses a runtime that consists of a few thousand lines of C# (C-Sharp) code. The Python programs can be debugged at the source level with Visual Studio 7, as well as stand-alone debuggers for this environment. Python can sub-class VB or C# classes, and vice-versa. Unfortunately, there will not be a public release of their SDK for a couple of months - so the only people able to use this compiler are people who attended the PDC, and hence have the pre-beta SDK on their conference CDs. The compiler is looking pretty reasonable. pystone.py (amongst others, of course) compiles and runs. Im not going to tell you the results yet, 'cos they arent too good ;-) However, this should be quite exciting for the Python community. The general feel of the conference here is that the MS .NET technology is exciting and a good thing. I predict that the Windows community will embrace this technology, and having Python be a first-class citizen is a good thing! It _is_ a radical change, so I predict it wont be really significant on windows for a couple of years yet. Future work on this compiler will be under the ActiveState banner. However, the compiler and the runtime are all open source. The compiler is written in CPython, and uses win32com to get at the Reflection::Emit APIs provided by .NET. All the existing work has been done mainly by me, with some code and advice from Greg. Now the NDA is lifted, I hope (some of) the Python community will get behind this, and take advantage of the open-sourceness of the compiler and runtime, and help us turn this into an excellent language for this environment. All good stuff! Mark. From MarkH@ActiveState.com Wed Jul 12 23:14:13 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Wed, 12 Jul 2000 18:14:13 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <000001bfec40$0eb3a6e0$060210ac@private> Message-ID: > > This is where we are now. I agree that we should not crash, > > but it seems to me you havent solved anything - individual > > .pyd authors needing to tell users about each individual > > .pyd isnt a solution. > At least if Python can detect that a .PYD is out of date you know > to ask for a newer .PYD or build it yourself. A crash is bad PR for > the .PYD and Python. We all agree on this - hence this discussion. My point was that I'm not clear how the proposal moved us closer to this goal. > > > True. And on Windows, there is a standard Version resource > > > string which gives the DLL version, and can be read without > > > loading the DLL. This string is referenced by the Wise (and > > > other) installers to decide whether a DLL is newer and should > > > be replaced. > > > > Im not sure how this helps us. Do you mean that "initfoo" > > should use the Windows resource/version APIs to determine > > if it can load? > As I pointed out you cannot use Py calls from a .PYD to find out > the version as the .PYD calls the function in the old PYTHON15.DLL > not the new one. Firstly, this doesn't answer my question, so I'm not sure why you needed to restate this assertion. I can only assume that the answer to my question, in your opinion, is "yes"? Secondly, I'm not sure why this is a problem. Sure, we can't use the version number, but the extension could, for example, call Py_IsInitialized() - this is likely to be a good indication if our linked DLL is the "correct" one for this process. The problem is not intractable - someone who cares enough should put together a patch, test it, and submit it. Talk-is-cheap-ly, Mark. From gward@mems-exchange.org Wed Jul 12 23:18:53 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 12 Jul 2000 18:18:53 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007121318.IAA14063@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 12, 2000 at 08:18:04AM -0500 References: <20000712031358.X29590@lyra.org> <200007121318.IAA14063@cj20424-a.reston1.va.home.com> Message-ID: <20000712181853.A7355@ludwig.cnri.reston.va.us> On 12 July 2000, Guido van Rossum said: > I would love to have a mechanism (run by configure or maybe better by > makesetup) that automatically determines if a particular external > library package is available. Come to think of it, in first > approximation, makesetup could easily parse the -I, -L and -l options > you specify for a particular extension and only build it if it can > find all those... The Distutils "config" command is *achingly* close to supporting this kind of trickery. (Yes, I finally buckled and started implementing Autoconf in Python. Turned out not to be too hard.) I promised I'll think really hard about how to get it working really well next week, when I'm on holiday... ;-) Greg From peter@schneider-kamp.de Thu Jul 13 01:42:28 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 13 Jul 2000 00:42:28 +0000 Subject: [Python-Dev] simple syntax error bombs interpreter References: <200007121929.VAA09996@python.inrialpes.fr> Message-ID: <396D1074.48F7554A@schneider-kamp.de> Vladimir Marangozov wrote: > > Fredrik Lundh wrote: > > > > using my latest Python 2.0 build, the interpreter > > bombs if I type the following two commands: > > > > >>> def a(b): > > ... global b > > ... > > > > (1.5.2 says "name is local and global"). > > > > That's the same kind of situation I had with my >>> def f(a,a): ... print a segfault > The appended patch should fix it. Let me know whether it works for you. The appended patch works for me. Now my "duplicate arguments" error also works fine. Is there an issue with removing the PyErr_Clear()? Does it serve any just purpose? if-not-please-get-rid-of-it-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul@prescod.net Wed Jul 12 23:52:56 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 17:52:56 -0500 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators for matrix computation] Message-ID: <396CF6C8.94B84B9B@prescod.net> You can guess my instinctive reaction...still, I feel for these guys competing with pricy domain-specific software. -------- Original Message -------- Subject: Discussion: Introducing new operators for matrix computation Date: Wed, 12 Jul 2000 19:32:32 GMT From: hzhu@knowledgetrack.com (Huaiyu Zhu) Reply-To: hzhu@users.sourceforge.net Organization: Giganews.Com - Premium News Outsourcing To: python-list@python.org Newsgroups: comp.lang.python We are at a crucial juncture concerning introduction of new operators into Python for matrix computation, 1. Experiences with Matlab show that different operators for matrix and elementwise operators are very important 2. It is difficult to add .* and ./ as . is already a valid token. It seems that next candidate on the standard keyboard is @. 3. Gregory Lielens has just implemented a patch that could parse additional operators containing @ a@b is equivalent to a*b, overloaded using __mmul__ and __rmmul__ a@/b a/b __mrdiv__ and __rmrdiv__ a/@b b/a __mldiv__ and __rmldiv__ a@@b a**b __mpow__ and __rmpow__ He indicates similar constructions can be added easily. We intend to add these operators together with Thomas Wouters's augmented assignment operators (+=,*=, etc) to MatPy, but before that several decisions need to be made. First, the main choices: 1. Use a*b as matrix mul, and a@*b as elementwise mul. Pros: - Consistent with Matlab. - Consistent with current MatPy. - Convenient for matrix computations. Cons: - Inconsistent with NumPy - How to differentiate left and right div (matlab a\b and a/b)? 2. Use a@*b as matrix mul, and a*b as elementwise mul. Pros: - Consistent with NumPy - Can use a@/b and a/@b as matlab a/b and a\b. - Can use a@b as inner product so that a@b works irrespective of whether a and b are row or col operators. Cons: - Inconsistent with current MatPy. Need great effort to switch. - Using two symbol operator for matrix mul is cumbersome for long formulas. - It kind of looks ugly. 3. Use a@b as matrix mul, and a*b as elementwise mul. This has most of the pros and cons of choice 2, except Pros: - Single symbol operators for matrix mul and element mul. Cons: - Can't use a@b as inner product. Just to add to the agony, here are a few contrary views: 1. Consistency with Matlab is not necessarily good. In Matlab operators default to matrix (cf * and .*) but functions default to elementwise (cf exp and expm). In Python ** is defined by __pow__. Should it be consistent with pow the function or ** the operator? 2. Consistency with NumPy is not necessarily good. Currently one can use MatPy and NumPy at the same time. a*b will be matrixwise for MatPy and elementwise for NumPy. This is convenient when each usage is dominant in some part of a program. Removing this difference and MatPy will lose a lot of appeal when it is needed. 3. Although it is relatively difficult to switch the usage in MatPy, it is still a good time if we deem this to be A Good Thing. When the status is changed to beta from alpha it would be next to impossible to switch. To throw you completely off the track, here is one additional feature request that would great please mathematicians and greatly annoy computer scientists: Use ^ and @^ for matrix power. Currently ^ is defined as xor which is of sufficiently low level that is unlikely to occur with matrix computations. Note that this is not in our plan right now. One other thing that will be of great efficiency value (whenver somebody comes forward to do it) is to parse := as assignment. This way we can let a=b be simple reference assignment without creating a new Matrix object. The implementors of both previous patches have cautioned that Guido is unlikely to adopt the patch for the .* or @* operators. But I'm quite confident that he can be persuaded. There is a large number of users of Matlab and Octave (maybe even more than users of Python), and there is no fundamental reason they cannot use Python for doing the same thing, provided that we are allowed to add this little additional operator. :-) What other incentives are needed to persuade Guido? Here's a quote from Gregory, > they make a huge difference in readability of code dealing with linear > algebra, in particular when using small matrices. Such operators explain > partly the popularity of Matlab-like tools, imho. I can argue that linear algebra is very important for Python, perhaps even more important than complex numbers, but this is off topic. So all your comments, suggestions and flames a invited. I just have a small request: As this is getting too long, please reply separately to different parts of this article, so that the discussion threads remain manageable. -- Huaiyu Zhu hzhu@users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net -- http://www.python.org/mailman/listinfo/python-list From esr@thyrsus.com Thu Jul 13 00:23:25 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 19:23:25 -0400 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: ; from ping@lfw.org on Wed, Jul 12, 2000 at 02:35:21AM -0700 References: Message-ID: <20000712192325.F799@thyrsus.com> Ka-Ping Yee : > Jodinat greidar fablo! Ruinon flast; ruinon flast. Thorvon > whananadak yum, onk triplation is dortiful. <0.5 wink> > > Ecky-ecky-ecky-ecky-pikang-zoop-boing? > > > -- ?!ng :pingspeak: n. [Python development list] Attractive but incomprehensible babble. Pingspeak is distinguished from lower-quality nonsense by being at least phonotactically plausible, as if the author is writing in a language you don't know. -- Eric S. Raymond Every election is a sort of advance auction sale of stolen goods. -- H.L. Mencken From esr@thyrsus.com Thu Jul 13 00:26:55 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 19:26:55 -0400 Subject: [Python-Dev] File Object Copy In-Reply-To: <20000712014338.Q29590@lyra.org>; from gstein@lyra.org on Wed, Jul 12, 2000 at 01:43:38AM -0700 References: <20000712014338.Q29590@lyra.org> Message-ID: <20000712192655.G799@thyrsus.com> Greg Stein : > Put the bugger in shutil for now. Step two: propose a new organization. I agree. -- Eric S. Raymond Everything you know is wrong. But some of it is a useful first approximation. From esr@thyrsus.com Thu Jul 13 00:40:53 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 19:40:53 -0400 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <14700.29709.259658.864250@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 12, 2000 at 09:35:09AM -0400 References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> Message-ID: <20000712194053.J799@thyrsus.com> Barry A. Warsaw : > Is weave() perhaps a better name? I *like* it. Better than the `with()' I independently invented. I think the fact that three people indeoendently invented with()/parallel()/weave()/zip() in responmse to the syntax discussion is in itself pretty good evidence that a generator builtin would be better than new syntax. -- Eric S. Raymond In recent years it has been suggested that the Second Amendment protects the "collective" right of states to maintain militias, while it does not protect the right of "the people" to keep and bear arms. If anyone entertained this notion in the period during which the Constitution and the Bill of Rights were debated and ratified, it remains one of the most closely guarded secrets of the eighteenth century, for no known writing surviving from the period between 1787 and 1791 states such a thesis. -- Stephen P. Halbrook, "That Every Man Be Armed", 1984 From esr@thyrsus.com Thu Jul 13 00:42:52 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 19:42:52 -0400 Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C9661.3EF03755@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 11:01:37AM -0500 References: <396BA425.2EF3B11F@prescod.net> <14699.59823.710880.896491@anthem.concentric.net> <14700.32671.461502.666561@beluga.mojam.com> <396C9661.3EF03755@prescod.net> Message-ID: <20000712194252.K799@thyrsus.com> Paul Prescod : > "Stitch" and "with" are okay, but I'd like to hear someone debunk the > names used today by MAL. They seemed very logical to me. I'd just change > the semantics to be lazy in a couple of cases. I would be happy with weave(), with(), or MAL's names. I think zip is best avoided for reasons already discussed. -- Eric S. Raymond "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), From klm@digicool.com Thu Jul 13 00:54:59 2000 From: klm@digicool.com (Ken Manheimer) Date: Wed, 12 Jul 2000 19:54:59 -0400 (EDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C9661.3EF03755@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > Skip Montanaro wrote: > > > > BAW> Alternatives (as Greg I think brought up): pairwise(), maybe > > BAW> zipper() for zip() since it's more evocative. > > > > "zip" already has a lot of compression connotations. How about "stitch", as > > in "stitch two lists together"? > > "Stitch" and "with" are okay, but I'd like to hear someone debunk the > names used today by MAL. They seemed very logical to me. I'd just change > the semantics to be lazy in a couple of cases. > > >>> tuple([1,2,3]) > (1,2,3) > > >>> tuples([1,2,3],[4,5,6]) > > > >>> list((1,2,3)) > [1,2,3] > > >>> lists((1,2,3),(4,5,6)) > > > >>> dict([(1,2),(3,4),(5,6)]) > {1:2,3:4,5:6} How about this different name, with a somewhat different approach: Name is "furl", with inverse "unfurl". First argument is the target-type of the result: >>> furl([], (1, 2, 3), [4, 5, 6,]) [[1,4], [2,5], [3,6]] >>> furl((), [1,2,3],(4,5,6)) ((1,4), (2,5), (3,6)) >>> furl({}, (1,2,3), "abc") {1:'a', 2:'b', 3:'c'} >>> unfurl([], [1,4], [2,5], [3,6]) [[1, 2, 3], [4, 5, 6]] >>> unfurl((), [1,4], [2,5], [3,6]) ((1, 2, 3), (4, 5, 6)) >>> unfurl((), {1:'a', 2:'b', 3:'c'}) ((1, 2, 3), ('a', 'b', 'c')) Being explicit about the type of the result, rather than keying on the type of both arguments, means you're not surprised by an exception when one of your vars had a tuple and the other had a list. Better explicit than implicit, ay? I'm not at all opposed yielding generators, like in skip's example. Seems like comprehensions and simple notations for infinite generators - "[1..]" - would deliver the benefits of concise, arbitrarily elaborate stream sources where xrange, alone, falls way short. I really like "furl" - it may help to appreciate the charm if you say it out loud a few times: "furl". "furl". "furl". Ahhh. :-) Ken From akuchlin@mems-exchange.org Thu Jul 13 01:13:44 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 12 Jul 2000 20:13:44 -0400 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators for matrix computation] In-Reply-To: <396CF6C8.94B84B9B@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 05:52:56PM -0500 References: <396CF6C8.94B84B9B@prescod.net> Message-ID: <20000712201344.A1974@newcnri.cnri.reston.va.us> On Wed, Jul 12, 2000 at 05:52:56PM -0500, Paul Prescod quoted: >From: hzhu@knowledgetrack.com (Huaiyu Zhu) >The implementors of both previous patches have cautioned that Guido is >unlikely to adopt the patch for the .* or @* operators. But I'm quite >confident that he can be persuaded. There is a large number of users of Why not simply write a new parser for this application that generates the desired semantics? Maintaining a complete fork of the Python source might not be necessary if Jeremy's Python parsing/compiling framework could be easily modified to implement the new operators. (While a Python variant isn't something I'm enthused about, one language can't be all things to all people, and I don't see why matrix operations are so important as to get extra specialized operators; lots of people use Python for text processing or for COM, so why shouldn't special syntax be added for *those* applications? Having a special parser also means that other matrix-specific language changes could be made.) --amk From guido@beopen.com Thu Jul 13 02:38:28 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 20:38:28 -0500 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Your message of "Wed, 12 Jul 2000 19:40:53 -0400." <20000712194053.J799@thyrsus.com> References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> <20000712194053.J799@thyrsus.com> Message-ID: <200007130138.UAA01580@cj20424-a.reston1.va.home.com> > Barry A. Warsaw : > > Is weave() perhaps a better name? [ESR] > I *like* it. Better than the `with()' I independently invented. > > I think the fact that three people indeoendently invented > with()/parallel()/weave()/zip() in responmse to the syntax discussion > is in itself pretty good evidence that a generator builtin would be better > than new syntax. Yes, I agree. Main reason: it's trivial to combine this with list comprehensions, while the ';' notation had real problems there. My bid for a name: splice(). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr@thyrsus.com Thu Jul 13 02:06:57 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 21:06:57 -0400 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <200007130138.UAA01580@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 12, 2000 at 08:38:28PM -0500 References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> <20000712194053.J799@thyrsus.com> <200007130138.UAA01580@cj20424-a.reston1.va.home.com> Message-ID: <20000712210657.Q799@thyrsus.com> Guido van Rossum : > Yes, I agree. Main reason: it's trivial to combine this with list > comprehensions, while the ';' notation had real problems there. Perhaps this frees up semicolon for use in the list-comprehension constructor syntax. BTW, I think whoever it was that suggested lazy eval for comprehensions was right on -- but that ties into the larger issue of generators and continuations. Really, a list comprehension ought to be syntactic sugar for an Icon-like generator object. > My bid for a name: splice(). Wearing my English-usage-pedant hat, I must regretfully judge this inferior to weave(). The reason has to do with the spatial geometry implied by the verbs. You *splice* two ropes together end-to-end; the proper data-structure analogy is with concatenation, and indeed splice() in Perl is a sort of generalized slice'n'dicer for sequences. On the other hand, you *weave* two threads together side by side to form a parallel bundle. Much closer image. OTOH, MAL's group of related constructors is pretty cool. -- Eric S. Raymond The real point of audits is to instill fear, not to extract revenue; the IRS aims at winning through intimidation and (thereby) getting maximum voluntary compliance -- Paul Strassel, former IRS Headquarters Agent Wall St. Journal 1980 From pingster@ilm.com Thu Jul 13 02:07:33 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 18:07:33 -0700 (PDT) Subject: [Python-Dev] co_lnotab and SET_LINENO Message-ID: Now that we have co_lnotab, why do we still generate SET_LINENO opcodes? -- ?!ng From Vladimir.Marangozov@inrialpes.fr Thu Jul 13 02:26:23 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 03:26:23 +0200 (CEST) Subject: [Python-Dev] co_lnotab and SET_LINENO In-Reply-To: from "Ka-Ping Yee" at Jul 12, 2000 06:07:33 PM Message-ID: <200007130126.DAA10951@python.inrialpes.fr> Ka-Ping Yee wrote: > > Now that we have co_lnotab, why do we still generate > SET_LINENO opcodes? It has been discussed before. To summarize: - because these opcodes generate the callbacks from C to Python - the debugger relies on them - I haven't had the time to look seriously at the debugger and make it work without them. (this relates with breakpoints setting which requires generating callbacks for every source line) And this is where we are. If you're volunteering to look into this, I'll spend some time summarizing the pointers about this thread + the existing code in the area. Otherwise, I won't bother -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one@email.msn.com Thu Jul 13 02:38:00 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 12 Jul 2000 21:38:00 -0400 Subject: [Python-Dev] ! In-Reply-To: Message-ID: [David Ascher] > Keeping up w/ python dev, patches and checkins is getting to be a huge > amount of work! > > Should we _thank_ lawyers for turning what was a small intense rush in > getting things done before a release into a long intense rush? Perish the > thought... > > +1 on the new python-dev community! Except it's largely still the same python-dev community: the perceived zoom in productivity is entirely due to my forcing patch management onto SourceForge -- well, either that, or that the laywers keep Guido so busy that he can't take time to interfere with progress anymore . whatever-the-cause-don't-jinx-it-ly y'rs - tim From guido@beopen.com Thu Jul 13 03:41:06 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 21:41:06 -0500 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Your message of "Wed, 12 Jul 2000 21:06:57 -0400." <20000712210657.Q799@thyrsus.com> References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> <20000712194053.J799@thyrsus.com> <200007130138.UAA01580@cj20424-a.reston1.va.home.com> <20000712210657.Q799@thyrsus.com> Message-ID: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> > > My bid for a name: splice(). > > Wearing my English-usage-pedant hat, I must regretfully judge this > inferior to weave(). The reason has to do with the spatial geometry > implied by the verbs. > > You *splice* two ropes together end-to-end; the proper data-structure > analogy is with concatenation, and indeed splice() in Perl is a sort > of generalized slice'n'dicer for sequences. > > On the other hand, you *weave* two threads together side by side to > form a parallel bundle. Much closer image. Oops. I see now that splice isn't the right thing. But the first meaning of weave that comes to me suggest a 2D interlacing of threads that gives the wrong impression here (I know there are others but I'm much less familiar with them). I looked in a thesaurus and found a few potential alternatives: twine entwine intertwine interweave interlace interspeerse If none of these appeal, I say let's use zip and end this impossibly long thread. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From DavidA@ActiveState.com Thu Jul 13 02:44:13 2000 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 12 Jul 2000 18:44:13 -0700 (Pacific Daylight Time) Subject: [Python-Dev] ! In-Reply-To: Message-ID: > > +1 on the new python-dev community! > > Except it's largely still the same python-dev community: It's the same group of people, behaving differently. Social change in action. It's a new community. =) > the perceived zoom > in productivity is entirely due to my forcing patch management onto > SourceForge -- well, either that, or that the laywers keep Guido so busy > that he can't take time to interfere with progress anymore . Actually, it's decentralization of responsibilities and power, and more people having full-time jobs doing the stuff. The lawyers help too =). --david From klm@digicool.com Thu Jul 13 02:47:33 2000 From: klm@digicool.com (Ken Manheimer) Date: Wed, 12 Jul 2000 21:47:33 -0400 (EDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: Guido: > I looked in a thesaurus and found a few potential alternatives: > > twine > entwine > intertwine > interweave > interlace > interspeerse > > If none of these appeal, I say let's use zip and end this impossibly > long thread. I have real doubts about using zip because of the extremely prominent "compression" connotations - it's one of the few things that neophyte as well as experienced computer users are exposed to, with winzip etc. I actually like interlace a lot. I also like "furl" - especially when you say it: "Furl. Furl. Furl." :-) Ken klm@digicool.com From bwarsaw@beopen.com Thu Jul 13 02:49:44 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 21:49:44 -0400 (EDT) Subject: [Python-Dev] zip() and list-comprehension with commas References: <396BA425.2EF3B11F@prescod.net> <14699.59823.710880.896491@anthem.concentric.net> <14700.32671.461502.666561@beluga.mojam.com> <396C9661.3EF03755@prescod.net> Message-ID: <14701.8248.42404.797966@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> "Stitch" and "with" are okay, but I'd like to hear someone PP> debunk the names used today by MAL. They seemed very logical PP> to me. I'd just change the semantics to be lazy in a couple of PP> cases. I don't like the fact that this will give you two pairs of built-ins that differ only by the last letter. It seems too easy to mistype or misread. OTOH, I've argued for a dict() built-in before. -Barry From bwarsaw@beopen.com Thu Jul 13 02:58:49 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 21:58:49 -0400 (EDT) Subject: [Python-Dev] Python .NET (was Preventing 1.5 extensions crashing under 1.6/2.0 Python) References: Message-ID: <14701.8793.942357.20599@anthem.concentric.net> >>>>> "MH" == Mark Hammond writes: MH> This new compiler could be compared, conceptually, with MH> JPython - it is a completely new implementation of Python. All this sounds very cool Mark, thanks for giving us an initial rundown! So what are you calling this particular Python interpreter? #Python? Naw... NPython? Naw... :) -Barry From Vladimir.Marangozov@inrialpes.fr Thu Jul 13 03:03:14 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 04:03:14 +0200 (CEST) Subject: [Python-Dev] co_lnotab and SET_LINENO In-Reply-To: <200007130126.DAA10951@python.inrialpes.fr> from "Vladimir Marangozov" at Jul 13, 2000 03:26:23 AM Message-ID: <200007130203.EAA11217@python.inrialpes.fr> Vladimir Marangozov wrote: > > Ka-Ping Yee wrote: > > > > Now that we have co_lnotab, why do we still generate > > SET_LINENO opcodes? > > It has been discussed before. To summarize: > > - because these opcodes generate the callbacks from C to Python > - the debugger relies on them > - I haven't had the time to look seriously at the debugger and > make it work without them. (this relates with breakpoints setting > which requires generating callbacks for every source line) > > And this is where we are. If you're volunteering to look into this, > I'll spend some time summarizing the pointers about this thread + > the existing code in the area. Otherwise, I won't bother OK, if someone wants to play with this, see: http://starship.python.net/~vlad/lineno/ for (working at the time) patches Discussions on python-dev: - http://www.python.org/pipermail/python-dev/2000-April/subject.html Subject: "Why do we need Traceback Objects?" - http://www.python.org/pipermail/python-dev/1999-August/002252.html I'd be happy to discuss the topic again, offline, with any volunteer(s) willing to take over (and to look closely at the debugger issue -- I don't use the debugger and I can't make the time for it). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From skip@mojam.com (Skip Montanaro) Thu Jul 13 03:14:37 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 12 Jul 2000 21:14:37 -0500 (CDT) Subject: [Python-Dev] Python .NET (was Preventing 1.5 extensions crashing under 1.6/2.0 Python) In-Reply-To: <14701.8793.942357.20599@anthem.concentric.net> References: <14701.8793.942357.20599@anthem.concentric.net> Message-ID: <14701.9741.273410.914425@beluga.mojam.com> BAW> So what are you calling this particular Python interpreter? BAW> #Python? Naw... NPython? Naw... :) How about McPython? 95-billion-served-ly y'rs, Skip From esr@thyrsus.com Thu Jul 13 03:54:09 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 22:54:09 -0400 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <200007130241.VAA01765@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 12, 2000 at 09:41:06PM -0500 References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> <20000712194053.J799@thyrsus.com> <200007130138.UAA01580@cj20424-a.reston1.va.home.com> <20000712210657.Q799@thyrsus.com> <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: <20000712225409.W799@thyrsus.com> Guido van Rossum : > twine > entwine Not bad. > intertwine > interweave Too long. > interlace Nah. Interlace is something you do with video. > interspeerse Too long. > If none of these appeal, I say let's use zip and end this impossibly > long thread. zip() has known problems -- people *will* associate it with compression. Which is too bad, it's a great image. -- Eric S. Raymond In every country and in every age, the priest has been hostile to liberty. He is always in alliance with the despot, abetting his abuses in return for protection to his own. -- Thomas Jefferson, 1814 From Vladimir.Marangozov@inrialpes.fr Thu Jul 13 04:04:04 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 05:04:04 +0200 (CEST) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <20000712225409.W799@thyrsus.com> from "Eric S. Raymond" at Jul 12, 2000 10:54:09 PM Message-ID: <200007130304.FAA11483@python.inrialpes.fr> Eric S. Raymond wrote: > > Guido van Rossum : > > twine > > entwine > > Not bad. Ugh. Never heard about these <0.8 wink>. Make it simple and explicit for non-english speakers too, please. I'm-about-to-whine-so-I-propose-"combine()"-ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From pingster@ilm.com Thu Jul 13 04:01:59 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 20:01:59 -0700 (PDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: These verbs have the following meanings to me: >>> splice([1, 2, 3], [4, 5, 6]) [1, 2, 3, 4, 5, 6] >>> weave([1, 2, 3], [4, 5, 6]) [1, 4, 2, 5, 3, 6] >>> interlace([1, 2, 3], [4, 5, 6]) [1, 4, 2, 5, 3, 6] I also did a little surveying. I got opinions that "interlace" was especially misleading; "zip" was deemed to evoke compression too strongly; and "parallel" evoked concurrency too strongly. The people i asked generally agreed with the interpretations i used above, though one thought that weave() would produce [[1, 4], [2, 5], [3, 6]]. I'm afraid i have to say that "with" is a horrible name for a function, as it's a preposition. Verbs work best for function names, and nouns are next best. Prepositions are very awkward. One person i asked even said that of all the various options, he still liked "map(None, ...)" best because all the others had potentially conflicting connotations. I personally still like "zip", but i must defer to empirical results. "tuples" may be the clearest option. "twine" seems plausible (though it makes me think of twisting and rotation). (By the way, let's not forget irange. Go, irange, go!) -- ?!ng From Ka-Ping Yee Thu Jul 13 04:09:09 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Wed, 12 Jul 2000 20:09:09 -0700 (PDT) Subject: [Python-Dev] Re: Iterating in parallel In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Ka-Ping Yee wrote: > One person i asked even said that of all the various options, > he still liked "map(None, ...)" best because all the others had > potentially conflicting connotations. I forgot to add: when i said "map(None, ...)" was ugly, this person suggested "munge()", indicating that he'd prefer a completely obscure name to a name that might risk an alternate interpretation. He liked "munge()" and "twine()" best, considered "tuples()" acceptable, and declared "zip()" unacceptable but "zipper()" acceptable. -- ?!ng From Ka-Ping Yee Thu Jul 13 04:37:32 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Wed, 12 Jul 2000 20:37:32 -0700 (PDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Ken Manheimer wrote: > > I also like "furl" - especially when you say it: > "Furl. Furl. Furl." But furling is like rolling something up. *sigh* More words: marry knit stitch merge weld meld ladder Considered but rejected: adhere, braid, mesh, lash, crosslink, bind, conjoin, unite, tie, squeeze. Hm. None really beat "zip" for me in terms of the visualization (except perhaps "marry"). -- ?!ng From bwarsaw@beopen.com Thu Jul 13 04:45:29 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 23:45:29 -0400 (EDT) Subject: [Python-Dev] Iterating in parallel References: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: <14701.15193.695315.549635@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> I personally still like "zip", but i must defer to empirical KY> results. "tuples" may be the clearest option. "twine" seems KY> plausible (though it makes me think of twisting and rotation). Let me throw one more out, in honor of our fearless leader's recent life change: marry(). Usually only done in pairs, and with two big sequences, I get the image of a big Unification Church event :) -Barry From bwarsaw@beopen.com Thu Jul 13 04:54:34 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 23:54:34 -0400 (EDT) Subject: [Python-Dev] Iterating in parallel References: Message-ID: <14701.15738.293596.60350@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> Hm. None really beat "zip" for me in terms of the KY> visualization (except perhaps "marry"). You and I think too much alike ?!ng. And if that doesn't scare you now, you should have a talk with Gordon. -Barry From esr@thyrsus.com Thu Jul 13 05:09:29 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 00:09:29 -0400 Subject: [Python-Dev] Re: Iterating in parallel In-Reply-To: ; from pingster@ilm.com on Wed, Jul 12, 2000 at 08:37:32PM -0700 References: Message-ID: <20000713000929.B3212@thyrsus.com> Ka-Ping Yee : > On Wed, 12 Jul 2000, Ken Manheimer wrote: > > > > I also like "furl" - especially when you say it: > > "Furl. Furl. Furl." > > But furling is like rolling something up. > > *sigh* More words: > > marry > knit > stitch > merge > weld > meld > ladder > > Considered but rejected: adhere, braid, mesh, lash, crosslink, bind, > conjoin, unite, tie, squeeze. > > Hm. None really beat "zip" for me in terms of the visualization > (except perhaps "marry"). `knit' would work for me. -- Eric S. Raymond Whether the authorities be invaders or merely local tyrants, the effect of such [gun control] laws is to place the individual at the mercy of the state, unable to resist. -- Robert Anson Heinlein, 1949 From paul@prescod.net Thu Jul 13 05:02:28 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 23:02:28 -0500 Subject: [Python-Dev] Iterating in parallel References: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> <14701.15193.695315.549635@anthem.concentric.net> Message-ID: <396D3F54.39DD165F@prescod.net> "Barry A. Warsaw" wrote: > > ... > > Let me throw one more out, in honor of our fearless leader's recent > life change: marry(). Usually only done in pairs, and with two big > sequences, I get the image of a big Unification Church event :) Isn't it somewhat of a political statement to allow marriages of three or more items? I always presumed that this function was n-ary, like map. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From esr@thyrsus.com Thu Jul 13 05:26:00 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 00:26:00 -0400 Subject: [Python-Dev] Iterating in parallel In-Reply-To: <396D3F54.39DD165F@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 11:02:28PM -0500 References: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> <14701.15193.695315.549635@anthem.concentric.net> <396D3F54.39DD165F@prescod.net> Message-ID: <20000713002600.E3212@thyrsus.com> Paul Prescod : > > Let me throw one more out, in honor of our fearless leader's recent > > life change: marry(). Usually only done in pairs, and with two big > > sequences, I get the image of a big Unification Church event :) > > Isn't it somewhat of a political statement to allow marriages of three > or more items? I always presumed that this function was n-ary, like map. Perhaps we should call it "menage()"? :-) (Eric looks back on some fond memories. And no, you *don't* get the details.) -- Eric S. Raymond Let us hope our weapons are never needed --but do not forget what the common people knew when they demanded the Bill of Rights: An armed citizenry is the first defense, the best defense, and the final defense against tyranny. If guns are outlawed, only the government will have guns. Only the police, the secret police, the military, the hired servants of our rulers. Only the government -- and a few outlaws. I intend to be among the outlaws. -- Edward Abbey, "Abbey's Road", 1979 From DavidA@ActiveState.com Thu Jul 13 05:24:19 2000 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 12 Jul 2000 21:24:19 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Iterating in parallel In-Reply-To: <20000713002600.E3212@thyrsus.com> Message-ID: > Perhaps we should call it "menage()"? :-) > > (Eric looks back on some fond memories. And no, you *don't* get the details.) ObJoke: A friend of mine in college was walking through a supermarket with her girlfriend (they were both highschool students at the time) and her girlfriend's mom. As she is walking down the aisle, the girlfriend had a sudden feeling of reliving a past experience, as if life was repeating itself and she was seeing things over again. She turned to her mom down the aisle and shouted: Hey, mom, I just had a 'maynage a troah!' I love misunderstood French. --david From paul@prescod.net Thu Jul 13 05:26:15 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 23:26:15 -0500 Subject: [Python-Dev] List comprehensions Message-ID: <396D44E7.F87983AB@prescod.net> I want to summarize my feelings on the list-comp syntax issue. There is no syntax for list comprehensions that will inherently scream "cartesian product, not parallel". The only way to do it is by analogy to what they already know: Python. [for x: if y(x): for z: (x,y,z)] -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Moshe Zadka Thu Jul 13 05:44:40 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 13 Jul 2000 07:44:40 +0300 (IDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <396CAE7D.B85AA3FB@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > Moshe Zadka wrote: > > > > What would people think about xmap(), which acts anologously to xrange(), > > IOW calculate lazilly instead of eagerly? Or even, calculate "on demand", > > without caching: > > .... > > Wouldn't this solve the parallel iteration problem? > > I don't think that using a function called "xmap" to build tuples is > very intuitive to start with. What's so wrong with a builtin called > "tuples()"? The name isn't so important -- what is more important is the lazy aspect of the thing. (And anyway, map/xmap is more general then tuples: def tuples(*lists): apply(map, (None,)+lists) ) and I see no reason not to support the stronger construct -- tuples could be build above it. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul@prescod.net Thu Jul 13 05:31:06 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 23:31:06 -0500 Subject: [Python-Dev] re: list comprehension / pop quiz References: Message-ID: <396D460A.96CCC807@prescod.net> Moshe Zadka wrote: > > ... > > The name isn't so important -- what is more important is the lazy aspect > of the thing. Names are always important. Is an xmap like an x-man? > (And anyway, map/xmap is more general then tuples: > > def tuples(*lists): > apply(map, (None,)+lists) > ) and I see no reason not to support the stronger construct -- tuples > could be build above it. I agree. I just think that the stronger construct should be called "lazy list comprehension". list comps. are much more general than maps and also easier to read. As you've pointed out, making them lazy also makes them more powerful. I don't think that there is any need for the eager equivalent because it is so easy to resolve a lazy one to an eager one in the rare case that that's what you need. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From klm@digicool.com Thu Jul 13 07:25:30 2000 From: klm@digicool.com (Ken Manheimer) Date: Thu, 13 Jul 2000 02:25:30 -0400 (EDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Ken Manheimer wrote: > Guido: > > > I looked in a thesaurus and found a few potential alternatives: > > [...] > > interlace > > [...] > > If none of these appeal, I say let's use zip and end this impossibly > > long thread. > > I actually like interlace a lot. Huh - how about "lace"? I like that even more than "interlace" - shorter, and with a particular, visceral appeal when thinking about laces that tie clothing together, like shoelaces. Lacing shoes means interleaving the laces, and unlacing them means un-interleaving them. Extraordinarily close visceral/physical analogue for the interlacing of the list/tuple arguments. For those that didn't see my posting in the thread "Re: zip() and list-comprehension with commas", i think it's a good idea to be explicit about the type of the results, rather than inferring them from the types of the arguments. Seem like there are so many contexts where lists and tuples are interchangeable that it's too easy for a variable to contain one when you expect the other - and the reorganizing routine would wind up raising unexpected errors, or unpredictable results, too often. Better to be explicit. And dictionaries seem like reasonable targets for lacing. >>> lace([], (1, 2, 3), [4, 5, 6,]) Lace [[1,4], [2,5], [3,6]] -%- \ / >>> lace((), [1,2,3],(4,5,6)) X ((1,4), (2,5), (3,6)) / \ \ / >>> lace({}, (1,2,3), "abc") X {1:'a', 2:'b', 3:'c'} (_) >>> unlace([], [1,4], [2,5], [3,6]) unlace [[1, 2, 3], [4, 5, 6]] \ / | | >>> unlace((), [1,4], [2,5], [3,6]) | | ((1, 2, 3), (4, 5, 6)) | | | | >>> unlace((), {1:'a', 2:'b', 3:'c'}) | | ((1, 2, 3), ('a', 'b', 'c')) |__| Also, i like having generators as the results of lacing things... I wonder whether this will have any inherent meaning for non-english speakers? Then again, i'm not sure 'tuple' had a lot of meaning for a lot of english or non-english speakers - people get used to it, as long as it's not using a word commonly known to have a *different* meaning in context (eg, "zip"). Ken From paul@prescod.net Thu Jul 13 07:07:30 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 01:07:30 -0500 Subject: [Python-Dev] strncpy Message-ID: <396D5CA2.DBBBDC2C@prescod.net> Tim, Re: Patch #100874 Thanks for the quick disposition. I'll fix the style errors. It's just so hard to concentrate on style when you're trying to fit code into the 5 character margin left by Guido's indentation style. Grrrr. ceval reminds me of old BBS messages written on a Commodore-64, but read on a 17" monitor. About this: > char buf[500]; > ... followed by an unchecked sprintf into buf. > > This is a security hole: Python doesn't restrict identifiers to > being no longer than 500 chars, so a hacker can easily trick this > code into overwriting the buffer bounds. I was prepared to be paranoid about this but then I saw this comment: /* XXX There are several unchecked sprintf or strcat calls in this file. XXX The only way these can become a danger is if some C code in the XXX Python source (or in an extension) uses ridiculously long names XXX or riduculously deep nesting in format strings. */ I interpreted that as "Python enforces reasonable identifier lengths, and only C code can violate it. I'm surprised to learn that Python doesn't have a max identifier length #defined somewhere. Especially since there is a defacto (probably undocumented) length limit for names in C extensions (according to the comment above). > Easy but tedious to > fix (e.g., #define the buf length, and use runtime code in > conjunction with strncpy to guarantee buf's bounds are respected). Let me suggest two non-tedious solutions so you can shoot them down: 1. sprintf(buf, "Local variable referenced " "before assignment: %.128s", namestr); Rationale: if you don't know what variable I'm talking about after 128 characters, you've got bigger problems than I can help with. I see this solution elsewhere in the code. 2. Add an implementation of snprintf to our code and fix the other hundred or so sprintf occurrences to use it. Most of them are safe but it couldn't hurt to pass cleanly through those heuristic security checkers Here's one: http://www.ijs.si/software/snprintf/ And there is one in Apache. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Thu Jul 13 07:09:50 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 01:09:50 -0500 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> Message-ID: <396D5D2E.4844F7FF@prescod.net> Paul Prescod wrote: > > Re: Patch #100874 Also, the LOAD_FAST and DELETE_FAST cases are identical when an exception is thrown. Should I make a small function as I would usually do or is that "bad style" in ceval. Moving code out of the switch probably helps keep commonly used code local and uncommon code "unlocal". -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From bwarsaw@beopen.com Thu Jul 13 08:00:17 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 03:00:17 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) Message-ID: <14701.26881.172217.870049@anthem.concentric.net> At our Pythonlabs meeting today, we decided we needed a more formal and organized way to track all the language and other changes being discussed on python-dev. Someone else (I don't remember who) suggested an IETF-like approach. I like that as a model, but am not sure how much of that formalism we need to adopt (or is even appropriate for us). Since my finger was slowest reaching my nose, I got elected Editor. On the positive side of that, I get to make the early decisions that will be cursed for generations of Python hackers to come. In any event, here's what I've just checked in. These things are called PEPs or Python Enhancement Proposals. Each has a number assigned to it by the Editor (me) which never changes over the lifetime of the proposal. The format is very loosely defined right now, but I'm sure will undergo formalization itself over time. Essentially, each PEP starts with a bunch of RFC822 style headers. Required headers are PEP: the number assigned by the editor Title: the title as given by the owner of the PEP Version: usually $Revision$ Owner: the owner/champion/shepherd of the PEP Status: the status as chosen from a currently very ill-defined set Optional headers are Python-Version: what version of Python this pertains to PEP 0 (zero) is the index of PEPs. PEP 1 will be the PEP Guidelines document (essentially this email message when it reflects back to my mailbox). I'll continue to own both these for the time being. PEP 200 is the Python 2.0 release schedule. Jeremy Hylton will own this one. PEP 201 discusses the parallel iteration feature. I currently own this one, and have fleshed this out completely based on my understanding of the issues as of 2:45am 13-Jul-2000. Use this as an example of the PEP format until PEP 1 is completed. PEP 202 will cover list comprehensions. I think Tim Peters volunteered to own this one. PEP 203 will cover augmented assignments. Thomas Wouters, we were thinking about you owning this one. My thoughts for these documents are that they will be almost completely self-contained, so that someone freshly coming on the issue can read the PEP, understand what the problem is, how the proposed solution works, and where to go to find more information. Wading through, or even following, the python-dev mailing list or archives should not be necessary. Another advantage is that these things will live in the Python CVS tree, so they will be diff-able, modifiable by anybody with check-in privileges, and will have the complete history in their CVS logs. What I don't want to do: argue about meta issues, such as whether PEPs are a good acronym, or whether we should use plain text or XML, or whether I've had enough sleep lately. They probably aren't, but I couldn't think of anything better; plain text is readable and writable by everybody and I didn't want to waste time trying to write a DTD; I haven't, so what's new? You can find the current set of documents under nondist/peps in the CVS tree. Please take a look, especially at pep-0201.txt which is nearest to being complete. Time for sleep. -Barry From paul@prescod.net Thu Jul 13 07:12:57 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 01:12:57 -0500 Subject: permuting several lists (was Re: [Python-Dev] zip() andlist-comprehension with commas) References: Message-ID: <396D5DE9.A0990F3F@prescod.net> Ken Manheimer wrote: > > ... > > Seem like there are so many contexts > where lists and tuples are interchangeable that it's too easy for a > variable to contain one when you expect the other - and the > reorganizing routine would wind up raising unexpected errors, or > unpredictable results, too often. Well, we (at least you and I) agree that we should use a generator, so you don't really have any control over the outer data structure without using a cast. I think it is safe to default the inner data structure to tuple. Tuples are safe because errors involving them cause TypeErrors whereas accidental writes to shared lists cause weird mutation bugs. Here are some variants you can get using recently proposed features: List of tuples: >>> list( lace( a, b, c )) A tuple of tuples: >>> tuple( lace( a, b, c)) A tuple of lists: >>> tuple( [for x in lace( a, b, c)]: list(x) ) A list of lists: >>> list( [for x in lace( a, b, c)]: list(x) ) A dictionary: >>> dict( lace( a, b, c )) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Thu Jul 13 07:13:52 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 01:13:52 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <396D5E20.69F228EC@prescod.net> I'm not clear on the role of opinions in this process. Do all of the opinions about a proposal go in the PEP: * "I hate this, here's why" * "I have a minor enhancement proposal" * "Here is my competing proposal" -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From fredrik@pythonware.com Thu Jul 13 08:09:57 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 09:09:57 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <013601bfec99$5a9af780$0900a8c0@SPIFF> barry wrote: > You can find the current set of documents under nondist/peps in the > CVS tree. Please take a look, especially at pep-0201.txt which is > nearest to being complete. can you perhaps post these somewhere on the python.org and/or pythonlabs.com sites? hiding them down in the CVS tree isn't optimal, especially when SF's CVS viewer doesn't work for roughly 86% of all web users... cheers /F From bwarsaw@beopen.com Thu Jul 13 08:11:07 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 03:11:07 -0400 (EDT) Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> Message-ID: <14701.27531.782443.22776@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Add an implementation of snprintf to our code and fix the PP> other hundred or so sprintf occurrences to use it. Most of PP> them are safe but it couldn't hurt to pass cleanly through PP> those heuristic security checkers PP> Here's one: PP> http://www.ijs.si/software/snprintf/ PP> And there is one in Apache. And one in Mailman, ripped from GNU screen. Because it's GPL'd it's not appropriate for Python, but could serve as another source of inspiration. So far, of the platforms people try to run Mailman on, I've only found it necessary for Solaris 2.5. -Barry From tim_one@email.msn.com Thu Jul 13 09:28:34 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 13 Jul 2000 04:28:34 -0400 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <013601bfec99$5a9af780$0900a8c0@SPIFF> Message-ID: [Barry] > You can find the current set of documents under nondist/peps in the > CVS tree. Please take a look, especially at pep-0201.txt which is > nearest to being complete. [/F] > can you perhaps post these somewhere on the python.org > and/or pythonlabs.com sites? In time, yes. For now we're just trying to get it started. Note that we can't currently change anything on python.org, and I'm not sure we're yet able to get at pythonlabs.com most days either <0.9 wink>. > hiding them down in the CVS tree isn't optimal, especially > when SF's CVS viewer doesn't work for roughly 86% of all > web users... Plus me ! Barry didn't say so, but he could have: the things for which he created PEPs are, as far as Guido is concerned, all going to be in the 2.0 release (yup! augmented assignments and list comprehensions and ... that other thing ). So we have a crucial need to make sense out of their respective Python-Dev messes *now* (as the "list comprehension guy", who was out of the loop yesterday for moving, out most of today for a mtg, and will be out tomorrow again for personal reasons, I despair of ever making coherent sense out of the 100+ msgs I haven't got to on the topic yet, inexplicably splintered along multiple Subject lines). So, like with the move to the SF patch manager, we're just moving to *something* we aren't yet certain is totally broken. It will work if all of us do . btw-the-truly-*new*-content-in-all-these-msgs-could-probably-fit-in-a- paragraph-ly y'rs - python's collective memory for lack of a pep From ping@lfw.org Thu Jul 13 08:35:29 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 00:35:29 -0700 (PDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: <396D3F54.39DD165F@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > > Isn't it somewhat of a political statement to allow marriages of three > or more items? I always presumed that this function was n-ary, like map. I *knew* someone was going to make a comment like this. ...which is why it was so much fun to propose it. :) -- ?!ng From Moshe Zadka Thu Jul 13 08:36:09 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 13 Jul 2000 10:36:09 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: On Thu, 13 Jul 2000, Barry A. Warsaw wrote: > You can find the current set of documents under nondist/peps in the > CVS tree. Please take a look, especially at pep-0201.txt which is > nearest to being complete. Personally, I'm +1 on pop-0201 as it stands. Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] Otherwise user-code will probably have to special case more often. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From ping@lfw.org Thu Jul 13 08:48:54 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 00:48:54 -0700 (PDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: On Thu, 13 Jul 2000, Barry A. Warsaw wrote: > > These things are called PEPs or Python Enhancement Proposals. Excellent. I think having these things documented in a persistent way is a fabulous idea. > PEP 201 discusses the parallel iteration feature. I currently own > this one, and have fleshed this out completely based on my > understanding of the issues as of 2:45am 13-Jul-2000. Use this as an > example of the PEP format until PEP 1 is completed. Great. Thanks for doing all this work! May i suggest small edits? pep-0201.txt says: | exhausted. The for-loop can also be explicitly exited with a | `break' statement, and for-loops can have else: clauses, but these | is has no bearing on this PEP. These is has no sensible sentence, either. :) Barry is has no sleep lately too? | should raise an IndexError when the sequence is exhausted. This | protocol is current undocumented -- a defect in Python's | documentation hopefully soon corrected. "current undocumented" -> "currently undocumented" | For loops are described in the language reference manual here | http://www.python.org/doc/devel/ref/for.html | | An example for-loop Colons after "here" and "for-loop". | class _Marriage: | def __init__(self, args, kws): Shouldn't that be "_Mawwage"? I apologize... i'm having way too much fun at your expense. -- ?!ng From Moshe Zadka Thu Jul 13 08:46:31 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 13 Jul 2000 10:46:31 +0300 (IDT) Subject: [Python-Dev] Ranges In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Ka-Ping Yee wrote: > I believe the two possibilities were > > __getitem__ gets either an index or a special slice object > __getslice__ is deprecated (when missing, __getitem__ gets the slice args) > > and > > __getitem__ always gets an index > __getslice__ gets three arguments, all optional, defaulting to None > > The latter isn't backward-compatible, but it makes a heckuva lot > more sense. Right. I'd be +1 on the latter if we didn't have to be backwards compatible. OTOH: How many people do you know who deal with slices in __getitem__, besides the numpy people? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From ping@lfw.org Thu Jul 13 08:52:17 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 00:52:17 -0700 (PDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: Message-ID: On Thu, 13 Jul 2000, Moshe Zadka wrote: > > Personally, I'm +1 on pop-0201 as it stands. Sure, looks great. Me too. > Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] > Otherwise user-code will probably have to special case more often. Yes, i agree with this stance on the issue. -- ?!ng From Moshe Zadka Thu Jul 13 08:56:16 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 13 Jul 2000 10:56:16 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007121318.IAA14063@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 12 Jul 2000, Guido van Rossum wrote: > Greg subtly points out the difficulty with your proposal: this > requires an external library that may not be available. In the past > we've had enough complaints from people who failed to realize that if > the build failed because of a missing external library, they could > just disable the module that needs it. So I'm not for simply having > it enabled in Setup.in by default. Currently there are two external libraries one needs to build a "good" Python interpreter: zlib, and expat. Well, now that Python releases from BeOpen, and not CNRI, perhaps it will be deemed all right to put them in the source distribution, and by default have a Setup.in that builds on them? Perhaps even include a "last known good" Tcl/Tk? Rational: There are several kinds of people who build Python interpreters. Let me divide them into two groups, jokingly called "users" and "pushers". "Users" build Python interpreter for self consumption (or for consumption of a relatively small group of people). They sometimes don't know C, have a flaky internet connection, and do not have too much time. For them, Python should build out of the box. "Pushers", or packagers, are people who build a python interpreter on a platform and distribute it. Examples include BeOpen for the Windows installer, the nice folks at Red Hat for rpms, and some Debian packager for debs. These people usually configure the Python interpreter, and decided what needs to be built, so it's all right to let them edit Setup. addicted-to-python-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From ping@lfw.org Thu Jul 13 09:21:41 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 01:21:41 -0700 (PDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: Message-ID: On Thu, 13 Jul 2000, Ka-Ping Yee wrote: > > Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] > > Otherwise user-code will probably have to special case more often. > > Yes, i agree with this stance on the issue. Oh -- alternatively: >>> marry([0, 1, 2]) TypeError: marry() requires at least two arguments Notice, by the way, that marry() neither limits its arguments to only two, nor does it place any restrictions on the gender of its arguments. Indeed, this has truly far-reaching implications, as PEP 201 would then make Python the first programming language in the history of computing to directly acknowledge freedom of sexual orientation in its standard library. The excellent PR alone would clearly make this one a winner. -- ?!ng From gstein@lyra.org Thu Jul 13 09:54:25 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 01:54:25 -0700 Subject: [Python-Dev] strncpy In-Reply-To: <396D5CA2.DBBBDC2C@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 01:07:30AM -0500 References: <396D5CA2.DBBBDC2C@prescod.net> Message-ID: <20000713015424.X29590@lyra.org> On Thu, Jul 13, 2000 at 01:07:30AM -0500, Paul Prescod wrote: >... > > Easy but tedious to > > fix (e.g., #define the buf length, and use runtime code in > > conjunction with strncpy to guarantee buf's bounds are respected). > > Let me suggest two non-tedious solutions so you can shoot them down: > > 1. > > sprintf(buf, "Local variable referenced " > "before assignment: %.128s", > namestr); > > Rationale: if you don't know what variable I'm talking about after 128 > characters, you've got bigger problems than I can help with. I see this > solution elsewhere in the code. > > 2. > > Add an implementation of snprintf to our code and fix the other hundred > or so sprintf occurrences to use it. Most of them are safe but it > couldn't hurt to pass cleanly through those heuristic security checkers > > Here's one: > > http://www.ijs.si/software/snprintf/ > > And there is one in Apache. Actually, I looked into this a few months ago. There isn't a need to bulk up Python with a complete snprintf() solution. We really only use a couple format codes for generating error strings. Please see my note at: http://www.python.org/pipermail/python-dev/2000-April/010051.html Cheers, -g -- Greg Stein, http://www.lyra.org/ From Moshe Zadka Thu Jul 13 09:52:06 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 13 Jul 2000 11:52:06 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: Message-ID: On Thu, 13 Jul 2000, Ka-Ping Yee wrote: [about what marry() should do with one argument] > Oh -- alternatively: > > >>> marry([0, 1, 2]) > TypeError: marry() requires at least two arguments Ummmmm......this seems a bit of an arbitrary restriction.... (Though I suppose this could be argued for from "the face of ambiguity refuse to guess") -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul@prescod.net Thu Jul 13 08:50:13 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 02:50:13 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: Message-ID: <396D74B5.5110A26D@prescod.net> Ka-Ping Yee wrote: > > ... > > Indeed, this has truly far-reaching implications, as PEP 201 would > then make Python the first programming language in the history of > computing to directly acknowledge freedom of sexual orientation in > its standard library. If Larry Wall can blatantly court the Christian vote, and Javasoft can go after the Asians, we'll have to build some coalitions of our own! Seriously though: I have some concern with implying that it works for only two lists. Our users may still be stuck in that 20th century point of view that, when stretched, might accept two lists of the same type but never three. Compare marry to "zip". The first time you see "zip", you figure out that it has nothing to do with zipping files, just by looking at the usage. But you could see, and use, "marry" over and over and over again and never realize that it works for three+ lists. How big of a problem is this? You decide. funny-how-whimsical-names-are--so-annoying-in-Perl -ly 'yrs -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Thu Jul 13 08:53:07 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 02:53:07 -0500 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> Message-ID: <396D7563.9DB73E1E@prescod.net> Greg Stein wrote: > > Actually, I looked into this a few months ago. >... Oh yeah? Where is the Python Enhancment Proposal? If we don't care about floating point, I think that there are about a dozen snprintf's we could steal (legally) around the Web. The author of the one I found says: > In retrospect, it appears that a lot of effort was wasted by > many people for not being aware of what others are doing. Sigh. Greg proposes: > %.###s -- switch to %s Isn't %.###s useful? If some yahoo gives us a 200 character variable name, is it really useful to quote it all back? For NameErrors and UnboundLocalErrors in ceval, I'm just going to use PyString_Format. If that's not solid, we're in big trouble. Okay, it isn't so fast but we're talking about relatively rare exceptions -- not IndexError or AttributeError. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gstein@lyra.org Thu Jul 13 10:31:59 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 02:31:59 -0700 Subject: [Python-Dev] strncpy In-Reply-To: <396D7563.9DB73E1E@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 02:53:07AM -0500 References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> Message-ID: <20000713023159.B29590@lyra.org> On Thu, Jul 13, 2000 at 02:53:07AM -0500, Paul Prescod wrote: > Greg Stein wrote: > > > > Actually, I looked into this a few months ago. >... > If we don't care about floating point, I think that there are about a > dozen snprintf's we could steal (legally) around the Web. The author of > the one I found says: We don't care about anything except for %d, %s, possibly %c and %x. > > In retrospect, it appears that a lot of effort was wasted by > > many people for not being aware of what others are doing. Sigh. IMO, there is a complexity tradeoff. A short formatter for a few codes, or pick up a complete implementation? And we *do* have some specific requirements. We need to format into a PyStringObject rather than a user-provided buffer/len like snprintf() does. > Greg proposes: > > %.###s -- switch to %s > > Isn't %.###s useful? If some yahoo gives us a 200 character variable > name, is it really useful to quote it all back? They did it, we can send it back. No biggy. The *reason* the %.###s is in there is to prevent buffer overruns. It isn't there for "nice output / truncation." Logically, it doesn't need to be there. > For NameErrors and UnboundLocalErrors in ceval, I'm just going to use > PyString_Format. If that's not solid, we're in big trouble. Okay, it > isn't so fast but we're talking about relatively rare exceptions -- not > IndexError or AttributeError. PyString_Format() requires Python objects for arguments. That is a completely different beast from PyErr_Format() (or the PyErr_SafeFormat that I described in that email). If you're going to create a PyStringObject for the format and one for the argument, then pass it to PyString_Format, then toast those temporaries... then you're going about it wrong. :-) A simple, *safe* string formatter for C types is needed within the core. Cheers, -g -- Greg Stein, http://www.lyra.org/ From jack@oratrix.nl Thu Jul 13 10:52:36 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 13 Jul 2000 11:52:36 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message by Guido van Rossum , Wed, 12 Jul 2000 21:41:06 -0500 , <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: <20000713095237.5570E37186D@snelboot.oratrix.nl> > twine > entwine > intertwine > interweave > interlace > interspeerse intertwine() and interlace() both give me the right feeling. Although with interlace I might be tempted to pass it two 320x480 bitmaps and assume an NTSC image will come out:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paul@prescod.net Thu Jul 13 09:01:24 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 03:01:24 -0500 Subject: [Python-Dev] Exceptions References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> Message-ID: <396D7754.96D6CCE7@prescod.net> Greg Stein wrote: > > If you're going to create a PyStringObject for the format and one for the > argument, then pass it to PyString_Format, then toast those temporaries... > then you're going about it wrong. :-) You're right. It's too late... Anyhow, this whole process seems wrong. Shouldn't the exceptions know what their appropriate error messages are and take the arguments for their format strings as arguments? There shouldn't be duplicated error messages spread throughout the code. It's brutal for consistency. You probably discussed this six months ago also. Anyhow, I think that that's the answer to Fredrik's (implicit) question about how decide when to make new exceptions. If it requires a new docstring or message string/format then it should be a new exception. We had relatively few exceptions before because they were just strings. Now that they are objects we should expect them to proliferate as they tend to in other languages where objects are exceptions. We should start tightening up the parameters we expect them to take for their constructors too. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From ping@lfw.org Thu Jul 13 11:19:59 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 03:19:59 -0700 (PDT) Subject: [Python-Dev] listcomp / par-for (summary) In-Reply-To: <20000712161328.I7340@xs4all.nl> Message-ID: On Wed, 12 Jul 2000, Thomas Wouters wrote: > As said, the currently implemented list-comprehension syntax was too > unclear, especially when nesting the 'for's and 'if's too deeply. One of the > proposals was to enforce the use of ()'s and add commas to make the 'for's > and 'if's more readable: > > [(x,y) for x in a, y in b, if y > 3] > > That is not going to work. Actually, it will (read on). > Enforcing the parentheses is possible, but only > if you *always* enforce them, even if they don't create a tuple: > > [([x,y]) for x in a] They don't always have to be enforced (read on). > Secondly, the use of commas to seperate the for and if statements is not > possible. The parser will see the commas as part of the iter-list of the > previous for statement. No, this really can be done. I was kinda suspicious when i read the above statements, so i proceeded to hack the grammar to see if i could implement the syntax i proposed. It is possible, and it turns out it's quite easy and straightforward. (No personal attack intended, Thomas -- sorry -- just wanted to show that it *is* possible.) All of the following syntaxes are possible (i've tried and tested a Python capable of each one): 1. [ <...> ] 2. [ , , , <...> ] 3. [ ; , , <...> ] 4. [ ; ; ; <...> ] For example, using a Python with "comma-comma" syntax (number 2), i get: >>> a = range(5) >>> b = range(10, 50, 10) >>> a [0, 1, 2, 3, 4] >>> b [10, 20, 30, 40] >>> [x*2, for x in a] [0, 2, 4, 6, 8] >>> [x, y, for x in a, for y in b, if y > 3] File "", line 1 [x, y, for x in a, for y in b, if y > 3] ^ SyntaxError: invalid syntax >>> [(x, y), for x in a, for y in b, if y > 3] [(0, 10), (0, 20), (0, 30), (0, 40), (1, 10), (1, 20), (1, 30), (1, 40), (2, 10), (2, 20), (2, 30), (2, 40), (3, 10), (3, 20), (3, 30), (3, 40), (4, 10), (4, 20), (4, 30), (4, 40)] >>> [[x, y], for x in a] [[0, 40], [1, 40], [2, 40], [3, 40], [4, 40]] >>> [([x, y]), for x in a] [[0, 40], [1, 40], [2, 40], [3, 40], [4, 40]] >>> [([x, y],), for x in a] [([0, 40],), ([1, 40],), ([2, 40],), ([3, 40],), ([4, 40],)] >>> def marry(*args): return apply(map, (None,)+args)[:min(map(len, args))] ... >>> [x + y, for x in a, for y in b] [10, 20, 30, 40, 11, 21, 31, 41, 12, 22, 32, 42, 13, 23, 33, 43, 14, 24, 34, 44] >>> [x + y, for x, y in marry(a, b)] [10, 21, 32, 43] >>> The above shows that we can indeed enforce parentheses around the initial test, while not requiring extra parentheses when no tuple is being constructed. Similarly, as you would expect, using a comma between clauses requires you to add parens if the expression after "in" contains bare commas. Otherwise everything works normally. I also tested stuff like [] [1] [1,] [1,,] [1,2] [1,2,] [1,2,,] and the modified Pythons behaved fine. The grammar rules for comma-comma syntax are: atom: '(' [testlist] ')' | '[' [test [',' (testlist | list_iter)]] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ list_iter: (list_for | list_if) list_for: 'for' exprlist 'in' test [',' list_iter] list_if: 'if' test [',' list_iter] Or for semicolon-comma syntax (number 3 above): atom: '(' [testlist] ')' | '[' [testlist [';' list_iter]] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ list_iter: (list_for | list_if) list_for: 'for' exprlist 'in' test [',' list_iter] list_if: 'if' test [',' list_iter] I won't post the changes to Python/compile.c for each case here, but they were pretty minor changes from Greg Ewing's original patch. Comma-comma syntax is my current favourite, with semicolon-comma a close second (but definitely second). -- ?!ng From mal@lemburg.com Thu Jul 13 11:16:56 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 12:16:56 +0200 Subject: [Python-Dev] Re: New builtins References: Message-ID: <396D9717.25E82B0B@lemburg.com> Ka-Ping Yee wrote: > > tuples(), lists(), dict(), and indices() look pretty generally useful > to me. I agree that they look like good candidates for builtins. > > On Wed, 12 Jul 2000, M.-A. Lemburg wrote: > > irange(object[,indices]) > > Builds a tuple of tuples (index, object[index]). If a sequence > > indices is given, the indices are read from it. If not, then > > the index sequence defaults to trange(len(object)). > > This one in particular looks really fabulous. +1 to put this in builtins. > > In order of usefulness (just imho of course): > > irange +1 > tuples +0.5 > indices +0.5 > dict +0 > lists +0 If you want these in the standard dist, just go ahead and steal them from mx.Tools -- I don't have time to look into this right now (and of course I already have them as builtins ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 13 11:30:19 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 12:30:19 +0200 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <396D5D2E.4844F7FF@prescod.net> Message-ID: <396D9A3B.B6985C97@lemburg.com> Paul Prescod wrote: > > Paul Prescod wrote: > > > > Re: Patch #100874 > > Also, the LOAD_FAST and DELETE_FAST cases are identical when an > exception is thrown. Should I make a small function as I would usually > do or is that "bad style" in ceval. Moving code out of the switch > probably helps keep commonly used code local and uncommon code > "unlocal". Before going down this road you should do some serious performance testing. ceval is *very* touchy about the order of the opcodes and adding indirection doesn't necessarily help (the compiler inlines the code again ;-). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 13 11:37:21 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 12:37:21 +0200 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <14701.27531.782443.22776@anthem.concentric.net> Message-ID: <396D9BE1.843BA74@lemburg.com> "Barry A. Warsaw" wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> Add an implementation of snprintf to our code and fix the > PP> other hundred or so sprintf occurrences to use it. Most of > PP> them are safe but it couldn't hurt to pass cleanly through > PP> those heuristic security checkers > > PP> Here's one: > > PP> http://www.ijs.si/software/snprintf/ > > PP> And there is one in Apache. > > And one in Mailman, ripped from GNU screen. Because it's GPL'd it's > not appropriate for Python, but could serve as another source of > inspiration. So far, of the platforms people try to run Mailman on, > I've only found it necessary for Solaris 2.5. Isn't there one in FreeBSD which we could use (Python's license being very BSDish, this should be possible, I guess). Anyway, I think most platforms have their own snprintf() in the C lib, so the code would hardly ever be needed -- perhaps its even safe to revert to sprintf() on those platforms via a macro snprintf(). The reasoning here is simple: if the platform doesn't provide it, it's quite possibly unsafe in a network environment anyway, because many programs will use sprintf() instead of snprintf() and thus won't do much buffer overflow checking. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping@lfw.org Thu Jul 13 11:41:45 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 03:41:45 -0700 (PDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: <20000713095237.5570E37186D@snelboot.oratrix.nl> Message-ID: On Thu, 13 Jul 2000, Jack Jansen wrote: > > intertwine() and interlace() both give me the right feeling. Although with > interlace I might be tempted to pass it two 320x480 bitmaps and assume an NTSC > image will come out:-) Sorry for flip-flopping on this -- to Paul especially -- but parallel() is looking better and better as i compare it with these other alternatives. It seems clear that the most common use of this thing is in a parallel-iteration idiom, and that it would be quite rarely used as part of an expression elsewhere. Given that, consider: for x, y, z in marry(a, b, c): print x + y + z for x, y, z in twine(a, b, c): print x + y + z for x, y, z in lace(a, b, c): print x + y + z for x, y, z in zip(a, b, c): print x + y + z for x, y, z in parallel(a, b, c): print x + y + z Which one makes its behaviour most obvious to you? For me, parallel() really stands out. It's so strong that it could outweigh the potential connotation of concurrency. (In fact, it *is* sort of concurrent. If each list were a generator, they would all be running concurrently to produce the triplets we're requesting.) (If "parallel" disturbs you too much, the concept of parallel *movement* inspires me to suggest "march", which has all of that good walking-together-in-lock-step feeling, with none of the twisty feeling i get from "twine" or "lace" or the alternating-back-and-forth feeling i get from "weave" or "interlace".) -- ?!ng From paul@prescod.net Thu Jul 13 09:08:08 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 03:08:08 -0500 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <396D5D2E.4844F7FF@prescod.net> <396D9A3B.B6985C97@lemburg.com> Message-ID: <396D78E8.70926D96@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Before going down this road you should do some serious > performance testing. ceval is *very* touchy about the order > of the opcodes and adding indirection doesn't necessarily > help (the compiler inlines the code again ;-). I'm not changing the order of the opcodes, just error handling. Anyhow, would performance results on my single computer be meaningful? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Thu Jul 13 09:09:11 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 03:09:11 -0500 Subject: [Python-Dev] Iterating in parallel References: Message-ID: <396D7927.EC241464@prescod.net> Ka-Ping Yee wrote: > > ... > > (If "parallel" disturbs you too much, the concept of parallel > *movement* inspires me to suggest "march", which has all of that > good walking-together-in-lock-step feeling, with none of the > twisty feeling i get from "twine" or "lace" or the > alternating-back-and-forth feeling i get from "weave" or "interlace".) If only as much thought had gone into choosing the name for "lambda"....or was that an earlier gay-pride statement? (yes, I know where it comes from) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov@inrialpes.fr Thu Jul 13 12:10:15 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 13:10:15 +0200 (CEST) Subject: [Python-Dev] Re: Iterating in parallel In-Reply-To: <20000713000929.B3212@thyrsus.com> from "Eric S. Raymond" at Jul 13, 2000 12:09:29 AM Message-ID: <200007131110.NAA12470@python.inrialpes.fr> Eric S. Raymond wrote: > > [Ping] > > Hm. None really beat "zip" for me in terms of the visualization > > (except perhaps "marry"). > > `knit' would work for me. I was thinking also about cross(), xcross() stop-that-noise-about-Marry-'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov@inrialpes.fr Thu Jul 13 12:40:33 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 13:40:33 +0200 (CEST) Subject: [Python-Dev] Iterating in parallel In-Reply-To: from "Ka-Ping Yee" at Jul 13, 2000 03:41:45 AM Message-ID: <200007131140.NAA12523@python.inrialpes.fr> Ka-Ping Yee wrote: > > ... Given that, consider: > > for x, y, z in marry(a, b, c): print x + y + z > > for x, y, z in twine(a, b, c): print x + y + z > > for x, y, z in lace(a, b, c): print x + y + z > > for x, y, z in zip(a, b, c): print x + y + z > > for x, y, z in parallel(a, b, c): print x + y + z > > Which one makes its behaviour most obvious to you? None. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From esr@thyrsus.com Thu Jul 13 13:01:13 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 08:01:13 -0400 Subject: [Python-Dev] Re: Iterating in parallel In-Reply-To: <200007131110.NAA12470@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Thu, Jul 13, 2000 at 01:10:15PM +0200 References: <20000713000929.B3212@thyrsus.com> <200007131110.NAA12470@python.inrialpes.fr> Message-ID: <20000713080113.A4157@thyrsus.com> Vladimir Marangozov : > > > Hm. None really beat "zip" for me in terms of the visualization > > > (except perhaps "marry"). > > > > `knit' would work for me. > > I was thinking also about cross(), xcross() Now that really sounds like a Cartesian-product operator. -- Eric S. Raymond The abortion rights and gun control debates are twin aspects of a deeper question --- does an individual ever have the right to make decisions that are literally life-or-death? And if not the individual, who does? From gvwilson@nevex.com Thu Jul 13 13:07:29 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Thu, 13 Jul 2000 08:07:29 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: Message-ID: > > I don't think that using a function called "xmap" to build tuples is > > very intuitive to start with. What's so wrong with a builtin called > > "tuples()"? 1. Trailing single-character difference between "tuple()" and "tuples()". (We'd take marks off students for naming things this way, wouldn't we?) 2. Need separate functions for creating tuples, lists, dicts, etc. I liked Ken M.'s idea of one function that took a type argument, and stitched/married/wove/welded/whatever'd its arguments to create something of that type, as it would require only one new function. Greg From gvwilson@nevex.com Thu Jul 13 13:13:41 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Thu, 13 Jul 2000 08:13:41 -0400 (EDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: Message-ID: > Ka-Ping Yee wrote: > Sorry for flip-flopping on this -- to Paul especially -- but > parallel() is looking better and better as i compare it with these > other alternatives. Strong -1 on parallel() unless it really performs concurrent execution. I'd take any of the other suggestions (except "zip()") over this. Greg From m.favas@per.dem.csiro.au Thu Jul 13 13:28:24 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Thu, 13 Jul 2000 20:28:24 +0800 Subject: [Python-Dev] re: list comprehension / pop quiz Message-ID: <396DB5E8.6F12ACA4@per.dem.csiro.au> Greg Wilson wrote: 2. Need separate functions for creating tuples, lists, dicts, etc. I liked Ken M.'s idea of one function that took a type argument, and stitched/married/wove/welded/whatever'd its arguments to create something of that type, as it would require only one new function. I'd like to endorse Ken's idea very strongly - and suggest the name "plait" (which can clearly operate on 2, 3, 4, or more strands - and can produce beautiful effects... -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From esr@thyrsus.com Thu Jul 13 14:15:46 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 09:15:46 -0400 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <396DB5E8.6F12ACA4@per.dem.csiro.au>; from m.favas@per.dem.csiro.au on Thu, Jul 13, 2000 at 08:28:24PM +0800 References: <396DB5E8.6F12ACA4@per.dem.csiro.au> Message-ID: <20000713091546.A5094@thyrsus.com> Mark Favas : > I'd like to endorse Ken's idea very strongly - and suggest the name > "plait" (which can clearly operate on 2, 3, 4, or more strands - and can > produce beautiful effects... plait() is *good*. -- Eric S. Raymond No one is bound to obey an unconstitutional law and no courts are bound to enforce it. -- 16 Am. Jur. Sec. 177 late 2d, Sec 256 From Vladimir.Marangozov@inrialpes.fr Thu Jul 13 14:16:04 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 15:16:04 +0200 (CEST) Subject: [Python-Dev] co_lnotab and SET_LINENO (fwd) Message-ID: <200007131316.PAA12706@python.inrialpes.fr> Maybe I should foward this to c.l.py as a CFP, detailing somewhat the issue and ask for contributions from people who are using the debugger? Guido? I won't do it if there's no a serious intent of including it, though. The contributions would require inspection, testing & possibly further improvements. I do volunteer for championing discussions and testing of this (relatively minor, but delicate) feature. > > Vladimir Marangozov wrote: > > > > Ka-Ping Yee wrote: > > > > > > Now that we have co_lnotab, why do we still generate > > > SET_LINENO opcodes? > > > > It has been discussed before. To summarize: > > > > - because these opcodes generate the callbacks from C to Python > > - the debugger relies on them > > - I haven't had the time to look seriously at the debugger and > > make it work without them. (this relates with breakpoints setting > > which requires generating callbacks for every source line) > > > > And this is where we are. If you're volunteering to look into this, > > I'll spend some time summarizing the pointers about this thread + > > the existing code in the area. Otherwise, I won't bother > > OK, if someone wants to play with this, see: > > http://starship.python.net/~vlad/lineno/ for (working at the time) patches > > Discussions on python-dev: > > - http://www.python.org/pipermail/python-dev/2000-April/subject.html > Subject: "Why do we need Traceback Objects?" > - http://www.python.org/pipermail/python-dev/1999-August/002252.html > > I'd be happy to discuss the topic again, offline, with any volunteer(s) > willing to take over (and to look closely at the debugger issue -- > I don't use the debugger and I can't make the time for it). > -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov@inrialpes.fr Thu Jul 13 14:29:04 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 15:29:04 +0200 (CEST) Subject: [Python-Dev] more SyntaxError subclasses! In-Reply-To: <009a01bfec17$f7fe3be0$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 12, 2000 05:43:45 PM Message-ID: <200007131329.PAA12745@python.inrialpes.fr> Fredrik Lundh wrote: > > here are a bunch of other syntax error subclasses that > might be useful: Fredrik, I don't want to let this thread die, since I'm firmly +1 on your proposal and the recent patches about more detailed syntax errors are ... well, recent . That said, what's your next proposal about making more progress on this? :-) > > I'll post a more complete proposal later... > Ah, okay. I'll be waiting for it. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas@xs4all.net Thu Jul 13 14:26:27 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 15:26:27 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.26881.172217.870049@anthem.concentric.net>; from bwarsaw@beopen.com on Thu, Jul 13, 2000 at 03:00:17AM -0400 References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <20000713152627.T7340@xs4all.nl> On Thu, Jul 13, 2000 at 03:00:17AM -0400, Barry A. Warsaw wrote: > PEP 203 will cover augmented assignments. Thomas Wouters, we were > thinking about you owning this one. Fine by me, though if it's a ploy to try and make me less involved with the other issues, it's bound to fail! :-) I'll see if my girlfriend lets me flesh out a PEP tonight. Where should I send it, by the way ? SF PM ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw@beopen.com Thu Jul 13 14:34:27 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 09:34:27 -0400 (EDT) Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <14701.27531.782443.22776@anthem.concentric.net> <396D9BE1.843BA74@lemburg.com> Message-ID: <14701.50531.652359.831584@anthem.concentric.net> >>>>> "M" == M writes: M> Anyway, I think most platforms have their own snprintf() in the M> C lib, so the code would hardly ever be needed -- perhaps its M> even safe to revert to sprintf() on those platforms via a macro M> snprintf(). Perhaps, but i think you're right, most platforms should have their own snprintf() by now. For those that don't, why re-invent the wheel? Find one with an acceptable license and drop it in. -Barry From thomas@xs4all.net Thu Jul 13 14:34:34 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 15:34:34 +0200 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <20000713091546.A5094@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 13, 2000 at 09:15:46AM -0400 References: <396DB5E8.6F12ACA4@per.dem.csiro.au> <20000713091546.A5094@thyrsus.com> Message-ID: <20000713153434.U7340@xs4all.nl> On Thu, Jul 13, 2000 at 09:15:46AM -0400, Eric S. Raymond wrote: > Mark Favas : > > I'd like to endorse Ken's idea very strongly - and suggest the name > > "plait" (which can clearly operate on 2, 3, 4, or more strands - and can > > produce beautiful effects... > plait() is *good*. Hmm... 'plait'. I don't even know what that means. I've read it before, but don't know what it means... something like 'cloth' or 'plaid' ?. And it sounds like 'plate'. I seriously prefer 'marry()', because it's widely known what marriage is. Also, it is more descriptive of what it should do: it shouldn't produce [1,4,2,5,3,6], but [(1,4),(2,5),(3,6)], or it's useless for tuple-unpacking in for-loops. And to hell with religious objections<1.1 wink> Actually, I try to respect other people's religions, having none myself, but I seriously think religion has no place in language design. A UNIX machine has processes, and those processes have children. But those child-processes have only a single parent! Did anyone ever question that ? Marry() is descriptive, and a common term, and if people refuse to marry() more than two lists, that's their choice. It's perfect. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fredrik@pythonware.com Thu Jul 13 14:54:27 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 15:54:27 +0200 Subject: [Python-Dev] re: list comprehension / pop quiz References: Message-ID: <002b01bfecd1$dcf7ca90$0900a8c0@SPIFF> (hmm. doesn't python-dev look a whole lot like python-list these days? maybe this thread, and its cousins, could be moved over to comp.lang.python for a while?) greg wrote: > 2. Need separate functions for creating tuples, lists, dicts, etc. I > liked Ken M.'s idea of one function that took a type argument, and > stitched/married/wove/welded/whatever'd its arguments to create > something of that type, as it would require only one new function. fwiw, I think it's about as unpythonish as it can be... what other function takes an instance of an object to figure out what object factory to call? and why force people to make a decision (list or tuple) that shouldn't matter in 99.9% of all cases? and wasn't this supposed to return a generator, not a sequence object? and "zip" is a pretty good name... in most cases, it will be perfectly clear from the context that it's not being used to compress things (sure, "zip" is a command name that happens to do something that this "zip" function won't do -- but the same thing applies to "dir", "del", "copy", "type", just to name a few...) btw, doesn't numpy provide something like this? reshape? From Vladimir.Marangozov@inrialpes.fr Thu Jul 13 15:53:44 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 16:53:44 +0200 (CEST) Subject: [Python-Dev] GC paper Message-ID: <200007131453.QAA12964@python.inrialpes.fr> FYI (Neil et al.) You may want to read an interesting paper from the ECOOP'95 proceedings, entitled: "Incremental Mature Garbage Collection Using the Train Algorithm" I've put it here: http://sirac.inrialpes.fr/~marangoz/tmp/09520235.pdf Combined with an object malloc of ours, the GC scheme may benefit from the idea(s). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw@beopen.com Thu Jul 13 15:51:17 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 10:51:17 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <396D5E20.69F228EC@prescod.net> Message-ID: <14701.55141.272357.604260@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> I'm not clear on the role of opinions in this process. Do all PP> of the opinions about a proposal go in the PEP: | * "I hate this, here's why" | * "I have a minor enhancement proposal" | * "Here is my competing proposal" In some sense yes, but it's the job of the owner/shepherd to follow the various threads, and include debate about the proposal as open issues. This would all lead to one of these conclusions: - we've reached consensus and now need just implement the proposal - we've reached an impasse and the BDFL will rule by decree - the proposal is hopeless flawed and the idea should be dropped - we need more information or research - we're defering the proposal to a future release -Barry From akuchlin@mems-exchange.org Thu Jul 13 15:59:49 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 13 Jul 2000 10:59:49 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <14699.21683.305409.97490@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 11, 2000 at 01:09:07PM -0400 References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> <20000711121817.J27228@kronos.cnri.reston.va.us> <14699.21683.305409.97490@bitdiddle.concentric.net> Message-ID: <20000713105949.B14938@kronos.cnri.reston.va.us> On Tue, Jul 11, 2000 at 01:09:07PM -0400, Jeremy Hylton wrote: > AMK> Very interesting, and probably worth doing because all that > AMK> list parsing *is* a silly waste of CPU. But could poll still > AMK> live in the posixmodule, then, or be a module of its own? [1] > >The select module has exactly the same problem and could use the same >interface. They could both live in their own module. >I'm not sure what to call it. Possibilities include: > >- add it to the current select module >- new name, e.g. asyncio, fileevent >- call it _asyncore and expose it through the asyncore module I want to finish off the patch to add poll(), but don't know how to proceed. The decision to use Jeremy's more efficient API seems clear; my only question at this point is where to put it. I'd argue for adding it to the select module. Any strenuous objections? --amk From bwarsaw@beopen.com Thu Jul 13 16:07:01 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 11:07:01 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <14701.56085.908913.979451@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> Great. Thanks for doing all this work! Sure thing! KY> May i suggest small edits? No. ...oh wait. As editor my first response should always be an automatic `no' (isn't that right Jeremy?). But if you insist :) KY> These is has no sensible sentence, either. :) Barry is has no KY> sleep lately too? Point good making nawpli gatch sensible snooperscope. Rewritten for stop making sense lessly. Thanks! KY> "current undocumented" -> "currently undocumented" Fixed. KY> Colons after "here" and "for-loop". Fixed. | | class _Marriage: | | def __init__(self, args, kws): KY> Shouldn't that be "_Mawwage"? Be glad I didn't include the _Consummate class. KY> I apologize... i'm having way too much fun at your expense. It's a dirty job, but somebody needs to do it. And Gordon's been too quietly lately. -Barry From billtut@microsoft.com Thu Jul 13 16:08:10 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 13 Jul 2000 08:08:10 -0700 Subject: [Python-Dev] Unicode character name hashing Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CB@RED-MSG-50> I just had a rather unhappy epiphany this morning. F1, and f2 in ucnhash.c might not work on machines where sizeof(long) != 32 bits. When sizeof(long) != 32 bits, x will probably not overflow like it did on my IA-32 box thereby possibly giving the code fits. If some kind soul could test the ucnhash.c stuff running on the Cray Tim's always talking about, and an Alpha running Unix that'd be awesome. Thanks, Bill From jeremy@beopen.com Thu Jul 13 16:14:47 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 11:14:47 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.26881.172217.870049@anthem.concentric.net> References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <14701.56551.680037.481536@bitdiddle.concentric.net> At our meeting yesterday Tim suggested that each enhancement or language feature have two documents -- a specification and a rationale. It looks like Barry did not adopt that suggestion explicitly, but I think it's still a good approach for writing a single PEP. Each PEP should have a brief technical specification of the new feature. For a feature like augmented assignment, it would need to specify the syntax and semantics of each operation on each type and on the overloading mechanism for classes, e.g. is "a += b += c" valid syntactically and what does it mean. The PEP should also have a rationale that describes why the specification is the way it is. It should discuss alternatives that were considered and why there were not adopted. Other topics appropriate for the rationale might be motivation (why do we want this feature at all?) and comparison (what do other languages do?). The Scheme language has a similar mechanism called Scheme Requests for Implementation (SRFI), . It is not exactly the same, because Scheme seems to have no end of proposals that include specification and rationale; they just can't agree on a standard set <0.2 wink>. We might adopt some of their processes for the PEPs. Two things that each SRFI that PEPs don't yet have are: - a mail archive attached to the PEP that contains relevant discussion. A mail archive seems valuable for people interested in the next level of detail, but I'm not sure what mechanism to use to create one. (It also seems valuable because the old "search dejanews" certainly isn't stable in the long-term.) Maybe PEP authors could maintain their own archives. - a copyright notice. As a strawman, I propose that the owner/author of each PEP retains copyright, but must publish it under the OpenContent license, . Jeremy From bwarsaw@beopen.com Thu Jul 13 16:24:38 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 11:24:38 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <20000713152627.T7340@xs4all.nl> Message-ID: <14701.57142.361876.857890@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: >> PEP 203 will cover augmented assignments. Thomas Wouters, we >> were thinking about you owning this one. TW> Fine by me, though if it's a ploy to try and make me less TW> involved with the other issues, it's bound to fail! :-) Not at all! Tim practically bum rushed me to gain control of PEP202, and Jeremy all but begged for PEP200. I figured PEP201 was the one that I understood the best (not saying much :) and I needed one to flesh out as an example. BTW, PEP204 is up for grabs too. It's titled "Range Literals". TW> Where should I send it, by the way ? SF PM ? Well, you've got checkin privs so I'd say just write it and check it in. If people without checkin privs want to submit new PEPs, feel free to send them directly to me. Changes to existing PEPs should be sent to the owner, who can either make the changes themselves or send me context diffs. TW> I'll see if my girlfriend lets me flesh out a PEP TW> tonight. witty-but-crud-remark-omitted...-ba-dum-dum-ly y'rs, -Barry From jeremy@beopen.com Thu Jul 13 16:29:20 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 11:29:20 -0400 (EDT) Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: <200007121929.VAA09996@python.inrialpes.fr> References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> <200007121929.VAA09996@python.inrialpes.fr> Message-ID: <14701.57424.510413.580401@bitdiddle.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> Fredrik Lundh wrote: >> using my latest Python 2.0 build, the interpreter bombs if I >> type the following two commands: >> >> >>> def a(b): ... global b ... >> >> (1.5.2 says "name is local and global"). >> >> >> VM> Yes. This is because PyErr_PrintEx() is invoked with a NULL VM> exception. And the exception has been cleared cleared in VM> get_inprogress_dict(). VM> The appended patch should fix it. Let me know whether it works VM> for you. VM> Jeremy, what's the point of calling PyErr_Clear() in VM> get_inprogress_dict()? Looks like it was just a bug. Jeremy From guido@beopen.com Thu Jul 13 17:28:54 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 13 Jul 2000 11:28:54 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Thu, 13 Jul 2000 10:59:49 -0400." <20000713105949.B14938@kronos.cnri.reston.va.us> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> <20000711121817.J27228@kronos.cnri.reston.va.us> <14699.21683.305409.97490@bitdiddle.concentric.net> <20000713105949.B14938@kronos.cnri.reston.va.us> Message-ID: <200007131628.LAA09799@cj20424-a.reston1.va.home.com> > I want to finish off the patch to add poll(), but don't know how to > proceed. The decision to use Jeremy's more efficient API seems clear; > my only question at this point is where to put it. I'd argue for > adding it to the select module. Any strenuous objections? +1 --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Thu Jul 13 15:08:52 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 13 Jul 2000 09:08:52 -0500 (CDT) Subject: [Python-Dev] List comprehensions In-Reply-To: <396D44E7.F87983AB@prescod.net> References: <396D44E7.F87983AB@prescod.net> Message-ID: <14701.52596.651140.884121@beluga.mojam.com> >>>>> "Paul" == Paul Prescod writes: Paul> I want to summarize my feelings on the list-comp syntax Paul> issue. There is no syntax for list comprehensions that will Paul> inherently scream "cartesian product, not parallel". The only way Paul> to do it is by analogy to what they already know: Python. Paul> [for x: if y(x): for z: (x,y,z)] Agreed, however, your use of colons connotes the following to me l = [] for x in something: if y(x): for z in something_else: l.append((x,y,z)) return l Skip From skip@mojam.com (Skip Montanaro) Thu Jul 13 15:22:32 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 13 Jul 2000 09:22:32 -0500 (CDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: References: <20000713095237.5570E37186D@snelboot.oratrix.nl> Message-ID: <14701.53416.577920.628245@beluga.mojam.com> Ping> It seems clear that the most common use of this thing is in a Ping> parallel-iteration idiom, and that it would be quite rarely used Ping> as part of an expression elsewhere. Given that, consider: Ping> for x, y, z in marry(a, b, c): print x + y + z Ping> for x, y, z in twine(a, b, c): print x + y + z Ping> for x, y, z in lace(a, b, c): print x + y + z Ping> for x, y, z in zip(a, b, c): print x + y + z Ping> for x, y, z in parallel(a, b, c): print x + y + z Ping> Which one makes its behaviour most obvious to you? for x, y, z in stitch(a, b, c): print x + y + z ;-) -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From bwarsaw@beopen.com Thu Jul 13 16:53:38 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 11:53:38 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: <14701.58882.943772.897826@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> At our meeting yesterday Tim suggested that each enhancement JH> or language feature have two documents -- a specification and JH> a rationale. It looks like Barry did not adopt that JH> suggestion explicitly, but I think it's still a good approach JH> for writing a single PEP. Agreed. I think a single document can contain both spec and rationale. JH> Each PEP should have a brief technical specification of the JH> new feature. For a feature like augmented assignment, it JH> would need to specify the syntax and semantics of each JH> operation on each type and on the overloading mechanism for JH> classes, e.g. is "a += b += c" valid syntactically and what JH> does it mean. Yes. JH> The PEP should also have a rationale that describes why the JH> specification is the way it is. It should discuss JH> alternatives that were considered and why there were not JH> adopted. Other topics appropriate for the rationale might be JH> motivation (why do we want this feature at all?) and JH> comparison (what do other languages do?). Yes. JH> The Scheme language has a similar mechanism called Scheme JH> Requests for Implementation (SRFI), JH> . It is not exactly the same, JH> because Scheme seems to have no end of proposals that include JH> specification and rationale; they just can't agree on a JH> standard set <0.2 wink>. We might adopt some of their JH> processes for the PEPs. Great pointer, thanks. Would you like to co-own PEP001 and help me flesh out the guidelines? There are lots of good ideas in the SRFI's, but we should tailor them toward the Python community. JH> Two things that each SRFI that PEPs don't yet have are: JH> - a mail archive attached to the PEP that contains relevant JH> discussion. A mail archive seems valuable for people JH> interested in the next level of detail, but I'm not sure what JH> mechanism to use to create one. (It also seems valuable JH> because the old "search dejanews" certainly isn't stable in JH> the long-term.) Maybe PEP authors could maintain their own JH> archives. One thing mentioned in teh SRFI's is that each gets its own mailing list. That might not be a bad idea. I definitely had the notion that a PEP would contain URLs to other information (a References section). JH> - a copyright notice. As a strawman, I propose that the JH> owner/author JH> of each PEP retains copyright, but must publish it under the JH> OpenContent license, . Looks good to me. -Barry From thomas@xs4all.net Thu Jul 13 16:55:03 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 17:55:03 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.56551.680037.481536@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 11:14:47AM -0400 References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: <20000713175503.V7340@xs4all.nl> On Thu, Jul 13, 2000 at 11:14:47AM -0400, Jeremy Hylton wrote: > - a mail archive attached to the PEP that contains relevant > discussion. A mail archive seems valuable for people interested in > the next level of detail, but I'm not sure what mechanism to use to > create one. (It also seems valuable because the old "search > dejanews" certainly isn't stable in the long-term.) Maybe PEP > authors could maintain their own archives. Oh, good idea ! It'll also give me a good place to dump the two/three threads I have been saving in my inbox ;) Barry, Tim, I was also keeping the discussions on parallel-iteration and list-comprehensions. If you need those, I can send them as a nice little (hee hee) mailbox. > - a copyright notice. As a strawman, I propose that the owner/author > of each PEP retains copyright, but must publish it under the > OpenContent license, . Is there any reason not to include them in the standard Python licence, the same as the documentation ? It is documentation, after all, even if it's about unimplemented features ;) But then, I'm not a bloody lawyer, so what do I know. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one@email.msn.com Thu Jul 13 18:04:30 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 13 Jul 2000 13:04:30 -0400 Subject: [Python-Dev] more SyntaxError subclasses! In-Reply-To: <200007131329.PAA12745@python.inrialpes.fr> Message-ID: [Vladimir Marangozov] > Fredrik, I don't want to let this thread die, since I'm firmly +1 > on your proposal and the recent patches about more detailed syntax > errors are ... well, recent . That said, what's your next > proposal about making more progress on this? :-) PEP! Unless someone picks up on a thread instantly and implements it, it *always* fades away, doomed to reincarnate as if it were a new idea year after year after year, all the same arguments, all the same rebuttals, all the same greatness and noise . [/F] > I'll post a more complete proposal later... PEP it. Barry will be delighted to give it a Unique Global Identifier so that next year I can just say RTFPEP207-ly y'rs - tim. RTFPEP201-ly y'rs - tim From mal@lemburg.com Thu Jul 13 17:07:36 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 18:07:36 +0200 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <396D5D2E.4844F7FF@prescod.net> <396D9A3B.B6985C97@lemburg.com> <396D78E8.70926D96@prescod.net> Message-ID: <396DE948.F73C5C76@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > Before going down this road you should do some serious > > performance testing. ceval is *very* touchy about the order > > of the opcodes and adding indirection doesn't necessarily > > help (the compiler inlines the code again ;-). > > I'm not changing the order of the opcodes, just error handling. > > Anyhow, would performance results on my single computer be meaningful? Sure. If your changes cause a performance drop of more than 10% in pystone then this would be a sign of having to rethink the restructuring. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@beopen.com Thu Jul 13 17:10:19 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 12:10:19 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <20000713175503.V7340@xs4all.nl> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713175503.V7340@xs4all.nl> Message-ID: <14701.59883.957987.423016@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > Is there any reason not to include them in the standard Python licence, the > same as the documentation ? It is documentation, after all, even if it's In the IETF world, the Internet Society gets copyright of everything, so there's precedent for this. I don't think the author-based model isn't exactly what we're looking for. For specifications, there's usually an editor (the shephard, not the PEP Editor, in this case) who's name goes on there, with the copyright belonging to the organization under whose auspices the specification was written. For the W3C, the editors are named, and the copyright belongs to MIT, Inria, and Keio U. For us, the shephard is the editor and copyright should belong to the Python community (somehow; IANAL, so don't ask me how to do *that*). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy@beopen.com Thu Jul 13 17:12:59 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 12:12:59 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.55141.272357.604260@anthem.concentric.net> References: <14701.26881.172217.870049@anthem.concentric.net> <396D5E20.69F228EC@prescod.net> <14701.55141.272357.604260@anthem.concentric.net> Message-ID: <14701.60043.481087.545575@bitdiddle.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "PP" == Paul Prescod writes: PP> I'm not clear on the role of opinions in this process. Do all of PP> the opinions about a proposal go in the PEP: PP> | * "I hate this, here's why" PP> | * "I have a minor enhancement proposal" PP> | * "Here is my competing proposal" BAW> In some sense yes, but it's the job of the owner/shepherd to BAW> follow the various threads, and include debate about the BAW> proposal as open issues. This would all lead to one of these BAW> conclusions: BAW> - we've reached consensus and now need just implement the BAW> proposal BAW> - we've reached an impasse and the BDFL will rule by decree BAW> - the proposal is hopeless flawed and the idea should be BAW> dropped BAW> - we need more information or research BAW> - we're defering the proposal to a future release This is the reason I suggested maintaining a separate mail archive of discussion. The PEP ought to represent a coherent proposal. It should discuss alternatives, but it should not be a compendium of all discussion and every possible idea. I would like to see something like the IETF model -- "rough consensus and running code" -- adopted. Python will be differently clearly, because the whole slogan is "We don't believe in kings, presidents, or voting. We believe in rough consensus and running code."[1] In the Python community, we do believe in at least one benevolent dictator for life. I propose the following guidlines: The PEP author is responsible for developing what he or she believes is a complete and coherent proposal. To be adopted, the PEP must constitute either the consensus opinion of the community (as determined by the PEP editor, Barry "Jon Postel" Warsaw) *or* be endorsed by Guido. It seems possible that we could have two different proposals for the same feature, which suggests we might want to have some notation about the final status of a PEP, e.g. accepted, rejected, etc., or that we have something like Internet drafts that will become PEPs only if adopted. Jeremy Note 1: People have suggested that it's actually the opposite: running consensus and rough code. From fdrake@beopen.com Thu Jul 13 17:15:41 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 12:15:41 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.60043.481087.545575@bitdiddle.concentric.net> References: <14701.26881.172217.870049@anthem.concentric.net> <396D5E20.69F228EC@prescod.net> <14701.55141.272357.604260@anthem.concentric.net> <14701.60043.481087.545575@bitdiddle.concentric.net> Message-ID: <14701.60205.465686.14824@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > Note 1: People have suggested that it's actually the opposite: running > consensus and rough code. When you have rough code, consensus tens to involve running competing ideas into the ground, right? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul@prescod.net Thu Jul 13 13:25:48 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 07:25:48 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: <396DB54C.71F9332D@prescod.net> Jeremy Hylton wrote: > > ... > > - a mail archive attached to the PEP that contains relevant > discussion. A mail archive seems valuable for people interested in > the next level of detail, but I'm not sure what mechanism to use to > create one. (It also seems valuable because the old "search > dejanews" certainly isn't stable in the long-term.) Maybe PEP > authors could maintain their own archives. Here's a low-tech solution to get us started: Set up a mailbox for each PEP at pythonlabs or python.org and have people "CC:" that mail address, e.g. CC: pep202@python.org. Run the changed ones through one of the mail to Web gateways daily. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Thu Jul 13 13:27:02 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 07:27:02 -0500 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> Message-ID: <396DB596.6F7C2C76@prescod.net> Skip Montanaro wrote: > > Paul> [for x: if y(x): for z: (x,y,z)] > > Agreed, however, your use of colons connotes the following to me > > l = [] > for x in something: > if y(x): > for z in something_else: > l.append((x,y,z)) > return l Yes, that's right. I forgot the "in something" and "in something_else" parts but your interpretation was still correct (a fault tolerant notation!!). [for x in something: if y(x): for z in something_else: (x,y,z)] -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From akuchlin@mems-exchange.org Thu Jul 13 17:44:12 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 13 Jul 2000 12:44:12 -0400 Subject: [Python-Dev] Unicode character name hashing In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CB@RED-MSG-50>; from billtut@microsoft.com on Thu, Jul 13, 2000 at 08:08:10AM -0700 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CB@RED-MSG-50> Message-ID: <20000713124412.D14938@kronos.cnri.reston.va.us> On Thu, Jul 13, 2000 at 08:08:10AM -0700, Bill Tutt wrote: >If some kind soul could test the ucnhash.c stuff running on the Cray Tim's >always talking about, and an Alpha running Unix that'd be awesome. If you want to test it on an Alpha, you could sign up for the Compaq test drive I posted about a while back; you get a 30-day account on your choice of Alphas running Tru64 4/5 or Linux. --amk From mal@lemburg.com Thu Jul 13 18:03:08 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 19:03:08 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <396DF64C.23833C61@lemburg.com> "Barry A. Warsaw" wrote: > > At our Pythonlabs meeting today, we decided we needed a more formal > and organized way to track all the language and other changes being > discussed on python-dev. Someone else (I don't remember who) > suggested an IETF-like approach. I like that as a model, but am not > sure how much of that formalism we need to adopt (or is even > appropriate for us). Someone on the reportlab list recently mentioned that SF supports subprojects via the task manager... wouldn't this be the ideal platform for managing PEPs ? > Wading > through, or even following, the python-dev mailing list or archives > should not be necessary. How about adding a PEP number to the subject line, e.g. "Re: [Python-Dev]:PEP999 Python Enhancement Proposals (PEPs)" ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> Message-ID: <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> greg wrote: > We don't care about anything except for %d, %s, possibly %c and %x. how about: PyObject * PyErr_SafeFormat(PyObject *exception, const char *format, ...) { va_list vargs; int n; const char* p; char* s; PyObject* string; /* figure out how large buffer we need */ va_start(vargs, format); n =3D 0; for (p =3D format; *p; p++) { if (*p =3D=3D '%') { while (*++p && *p !=3D '%' && !isalpha(*p)) ; switch (*p) { case 'c': va_arg(vargs, int); /* fall through... */ case '%': n++; break; case 'd': case 'i': case 'x': va_arg(vargs, int); n =3D n + 20; break; case 's': s =3D va_arg(vargs, char*); n =3D n + strlen(s); break; default: n =3D n + strlen(p); goto expand; } } else n =3D n + 1; } expand: string =3D PyString_FromStringAndSize(NULL, n); if (!string) return NULL; /* fill it in */ va_start(vargs, format); s =3D PyString_AsString(string); p =3D format; for (p =3D format; *p; p++) { if (*p =3D=3D '%') { while (*++p && *p !=3D '%' && !isalpha(*p)) ; switch (*p) { case 'c': *s++ =3D va_arg(vargs, int); break; case 'd': case 'i': itoa(va_arg(vargs, int), s, 10); s =3D s + strlen(s); break; case 'x': itoa(va_arg(vargs, int), s, 16); s =3D s + strlen(s); break; case 's': strcpy(s, va_arg(vargs, char*)); s =3D s + strlen(s); break; case '%': *s++ =3D '%'; break; default: strcpy(s, p-1); s =3D s + strlen(s); goto end; } } else *s++ =3D *p; } end: _PyString_Resize(&string, s - PyString_AsString(string)); PyErr_SetObject(exception, string); Py_XDECREF(string); return NULL; } From Fredrik Lundh" Message-ID: <011b01bfecf2$15952580$f2a6b5d4@hagrid> barry wrote: > I like that as a model, but am not sure how much of that formalism > we need to adopt (or is even appropriate for us). I hope PEPs won't replace the existing "small proposal, >0, patch, >0, commit" fast-track mechanism... (FTPEPs) From Fredrik Lundh" Message-ID: <011c01bfecf2$17838800$f2a6b5d4@hagrid> tim wrote: > > I'll post a more complete proposal later... >=20 > PEP it. I hope to FTPEP this one (the error tag part, not the "tons of syntaxerror variants" part) more later. From fdrake@beopen.com Thu Jul 13 18:44:51 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 13:44:51 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <011b01bfecf2$15952580$f2a6b5d4@hagrid> References: <14701.26881.172217.870049@anthem.concentric.net> <011b01bfecf2$15952580$f2a6b5d4@hagrid> Message-ID: <14702.19.539033.987227@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > I hope PEPs won't replace the existing "small proposal, >0, > patch, >0, commit" fast-track mechanism... (FTPEPs) The PEP process is not meant for small enhancements, but for things like list comprehensions, where there are real issues with determining the appropriate syntax and semantics. For small stuff, submit a patch using SF. For fixing a bug, either submit a patch or just fix it, depending on whether its within your pervue & how confident you are that your patch is appropriately portable. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw@beopen.com Thu Jul 13 19:12:50 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 14:12:50 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <011b01bfecf2$15952580$f2a6b5d4@hagrid> Message-ID: <14702.1698.288014.78586@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: >> I like that as a model, but am not sure how much of that >> formalism we need to adopt (or is even appropriate for us). FL> I hope PEPs won't replace the existing "small proposal, >0, FL> patch, >0, commit" fast-track mechanism... (FTPEPs) I agree. PEPs are for those proposals that Tim's already seen 5 times before and never got any agreement on. :) From HZhu@knowledgetrack.com Thu Jul 13 19:33:04 2000 From: HZhu@knowledgetrack.com (Huaiyu Zhu) Date: Thu, 13 Jul 2000 11:33:04 -0700 (PDT) Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators for matrix computation] In-Reply-To: <20000712201344.A1974@newcnri.cnri.reston.va.us> Message-ID: On Wed, 12 Jul 2000, Andrew Kuchling wrote: > Why not simply write a new parser for this application that generates > the desired semantics? Maintaining a complete fork of the Python > source might not be necessary if Jeremy's Python parsing/compiling > framework could be easily modified to implement the new operators. I wonder how orthogonal would this be against the main development? Would it require a rebuild for each new release. Would it also require a patch each time? > > (While a Python variant isn't something I'm enthused about, one > language can't be all things to all people, and I don't see why matrix > operations are so important as to get extra specialized operators; > lots of people use Python for text processing or for COM, so why > shouldn't special syntax be added for *those* applications? Having a > special parser also means that other matrix-specific language changes > could be made.) Well, linear algebra is not just another special domain. It is almost as elementary as arithmetic. Vectors and matrices are fundamental concepts in mathematics that underlies almost all of "scientific computation". They distill centuries of research in science and engineering, especially computation techniques. It is unlikely that adding linear algebra support would open up a flood gate for similar constructs. Look it this way. Text processing do have their special syntaxes. A string is written as "string" instead of ['s','t','r','i','n','g']. There is even the new sep.join(list). There are also lists and dicts for to build structures for discrete maths. If we had requested that new syntax for Fourier analysis or fractal generation that would be comparable to text processing or COM. Python actually has the chance of being all things to most people. The other half of the computing crowd only needs a few very basic asistance to come across. This crowd consists of people who design bridges and missiles, figure out weather patterns or DNA structures, detect credit card fraud or defects on a microchip, design speach recognition systems or network traffic balance algorithms and machines that learn to play games. Science and technology have great power to penatrate many aspects of life. And imagine if most of that is implemented in a laguage that can also be taught in schools. Huaiyu PS. I suppose I am allowed to post to python-dev without invitation, but not subscribing to it? I find this rather strange. From Fredrik Lundh" Message-ID: <01c601bfecf9$90cc8e80$f2a6b5d4@hagrid> ?!ng wrote: > > Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] > > Otherwise user-code will probably have to special case more often. as in=20 # normal case for (x,) in zip([0, 1, 2]): ... vs. # special case for x in zip([0, 1, 2]): ... ? From jim@interet.com Thu Jul 13 19:34:03 2000 From: jim@interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 14:34:03 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: Message-ID: <396E0B9B.DD74EF5@interet.com> Mark Hammond wrote: > Yes, and each of these versions has broken various programs. Of all > people, Im surprised to see you falling for the MS hype, Jim. My experience is that it often works. I have also (who hasn't?) had the experience that mysterious bugs disappear by installing the newest DLLs. > > What this means is that if the new Python 2.0 (1.6?) simply names > > its DLL python15.dll just as before, everything Just Works almost. > > That is, it Just Works provided that foo.pyd only calls Python > > C functions whose interface has not changed. > > IMO, this constrains us too much. We can't afford this - we simply dont > have the resources. I guess I haven't made myself clear. I am not proposing that we freeze the C interface. I am not proposing that we scrutinize any *.pyd's for incompatabilities. I am proposing that we leave the "python15.dll" name the same. I am proposing that the various *.pyd authors themselves either provide newer versions, or declare that their *.pyd needs no newer version of python15.dll. It is a matter of odds. If we necessarily rename python15.dll for each version release, Python has a 100% chance of failing with an obscure error or crashing if it uses any *.pyd at all unless all *.pyd are replaced with new versions. If we do not rename python15.dll, then a *.pyd may or may not fail. My guess (only a guess) is that many will work OK. > > You can support Python 1.5 and 1.6 by removing the python*.dll > > from the Windows directories, and putting it in the directory > > of python.exe so it goes with the proper executable. > > We have discussed this over and over and over, ad nauseum. If you believe > the earlier discussions were bunk, please refute them. Otherwise, simply > re-asserting something that we have previously proven to be incorrect > doesnt help anyone. Putting python15.dll in with python.exe works fine for just using the interpreter python.exe, and it works fine for Python extensions. It fails when the client for python15.dll is not python.exe, but is some other client such as COM. That is, it fails to support Python embedding in general. I proposed that someone who needed multiple Python versions could use this solution provided that he/she had no use for embedding. Not as a general policy. > > Yes, and this is a major problem, and is un-Windows-like. > > :-) "Major Crashes" are un-Windows like? What is happening to this > group - It amusing that this statement could be made without the Linux > geeks making smart-arsed comments :-) Looks like Billy Boy really _is_ > taking over the world :-) I am a Linux geek myself. And Windows is more and more stable all the time. And yes, Bill is taking over the world and I doubt DoJ can stop him. JimA From tim_one@email.msn.com Thu Jul 13 20:34:07 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 13 Jul 2000 15:34:07 -0400 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14702.1698.288014.78586@anthem.concentric.net> Message-ID: [Barry] > I agree. PEPs are for those proposals that Tim's already seen 5 times > before and never got any agreement on. :) Boost that to 50 and I'll agree . Also for proposals not necessarily originated by developers: we also have a history of losing "good ideas", just because the person fighting for them is not a developer, can't really address how to implement it, and no developer at the time "adopts" it. It's no good asking for examples, because *we've* all forgotten them <0.9 wink>. From jim@interet.com Thu Jul 13 19:38:39 2000 From: jim@interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 14:38:39 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <20000711215517.E9C71E2673@oratrix.oratrix.nl> Message-ID: <396E0CAF.DA3A8740@interet.com> Jack Jansen wrote: > > Excuse my ignorance, but isn't the whole problem that the python 1.6 > DLL is in the system search path even when you are running Python 1.7? Yes, but it is necessary to put the DLL in the system search path to support Python embedding. That is, to support an arbitrary client of the DLL, such as another DLL, COM object, etc. JimA From jim@interet.com Thu Jul 13 19:43:38 2000 From: jim@interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 14:43:38 -0400 Subject: [Python-Dev] O'Reilly conference References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <396E0DDA.530ADB62@interet.com> "Fred L. Drake, Jr." wrote: > > So who's going to the O'Reilly conference next week? The PythonLabs Sorry, can't make it. High air fares, gone too much already. JimA From mal@lemburg.com Thu Jul 13 19:44:27 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 20:44:27 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <01c601bfecf9$90cc8e80$f2a6b5d4@hagrid> Message-ID: <396E0E0B.C8D446BC@lemburg.com> Fredrik Lundh wrote: > > ?!ng wrote: > > > Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] > > > Otherwise user-code will probably have to special case more often. > > as in > > # normal case > for (x,) in zip([0, 1, 2]): > ... > > vs. > > # special case > for x in zip([0, 1, 2]): > ... > > ? Uhm, why should marry() be defined for a single argument ? IMHO, this only masks program errors. BTW: >>> from mx.Tools import NewBuiltins >>> marry = tuples >>> john = lists >>> marry([0,1,2]) Traceback (innermost last): File "", line 1, in ? TypeError: sequence elements must be sequences >>> marry([0,1,2],[3,4,5]) [(0, 3), (1, 4), (2, 5)] >>> john([0,1,2],[3,4,5]) ([0, 3], [1, 4], [2, 5]) ... the code is there. I'd say: use it :-) (Who invented those silly function names ?) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy@beopen.com Thu Jul 13 19:50:04 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 14:50:04 -0400 (EDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14700.34906.286143.800770@beluga.mojam.com> References: <14700.25459.555611.544163@bitdiddle.concentric.net> <14700.34906.286143.800770@beluga.mojam.com> Message-ID: <14702.3932.157846.676297@bitdiddle.concentric.net> >>>>> "SM" == Skip Montanaro writes: SyntaxError: dedent does not match any outer indentation level SM> Isn't something like "line indented incorrectly" sufficient to SM> alert the programmer to an indentation on that line? Perhaps SM> Python doesn't need to tell which direction to push the line. I like this error message best. It may not provided as much information as possible, but it seems to provide as much information as is really needed and as much as can be reasonably understood. Jeremy From jim@interet.com Thu Jul 13 19:49:40 2000 From: jim@interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 14:49:40 -0400 Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> Message-ID: <396E0F44.59B63956@interet.com> Greg Stein wrote: > > On Wed, Jul 12, 2000 at 07:52:05AM +0100, Andy Robinson wrote: > >... > > Are there many other applications which > > use compression? If so, would it do > > be feasible to include it by default > > from version 1.6? > > I believe the correct approach would be to have ./configure look for zlib. > If present, then it should include the module into the build. I think that what Andy wants is to have zlib always distributed with Python, and always available. JimA From bwarsaw@beopen.com Thu Jul 13 19:53:25 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 14:53:25 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> <396E0F44.59B63956@interet.com> Message-ID: <14702.4133.886431.381684@anthem.concentric.net> >>>>> "JCA" == James C Ahlstrom writes: JCA> I think that what Andy wants is to have zlib always JCA> distributed with Python, and always available. We've argued about that before, although I'm not sure if we did so on python-dev. I argued for this, in the context of distutils, but I think Guido doesn't want to maintain this external library. We'd have to do that if we distribute it with Python. -Barry From jeremy@beopen.com Thu Jul 13 20:00:54 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 15:00:54 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: References: <200007121318.IAA14063@cj20424-a.reston1.va.home.com> Message-ID: <14702.4582.530066.817107@bitdiddle.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> On Wed, 12 Jul 2000, Guido van Rossum wrote: >> Greg subtly points out the difficulty with your proposal: this >> requires an external library that may not be available. In the >> past we've had enough complaints from people who failed to >> realize that if the build failed because of a missing external >> library, they could just disable the module that needs it. So >> I'm not for simply having it enabled in Setup.in by default. MZ> Currently there are two external libraries one needs to build a MZ> "good" Python interpreter: zlib, and expat. Well, now that MZ> Python releases from BeOpen, and not CNRI, perhaps it will be MZ> deemed all right to put them in the source distribution, and by MZ> default have a Setup.in that builds on them? Perhaps even MZ> include a "last known good" Tcl/Tk? I don't see the need to include the source code from other projects or libraries in a regular Python release. Rather, I'd like to see something like the Windows installer, which packages up third-party software like Tcl/Tk. I'm working on a nightly build system for Python that will produce a tar ball and some Linux RPMs, based in part on the very good work that Oliver Andrich did. One of the first things I discovered is that Expat isn't packaged very well for Linux systems, but that seemed easy to fix: http://www.pythonlabs.com/download/misc/rpm/expat-1.1-1.i386.rpm http://www.pythonlabs.com/download/misc/rpm/expat-1.1-1.src.rpm I'm sure there are other platforms and Linux distributions with different packaging mechanisms, but Windows and Linuxes-supporting-RPM seems like a good start. Jeremy From jeremy@beopen.com Thu Jul 13 20:10:28 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 15:10:28 -0400 (EDT) Subject: [Python-Dev] Unit testing... In-Reply-To: <396C926D.F223E686@prescod.net> References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> Message-ID: <14702.5156.863478.268256@bitdiddle.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Andrew Kuchling wrote: >> ... >> >> (I've speculated about adding a unit testing framework, similar >> to the one we use internally at the MEMS Exchange; the discipline >> of using it makes writing a test more time-consuming, but the >> tests also wind up being more comprehensive.) PP> I think PyUnit/JUnit and friends are in vogue these days. There PP> is some virtue in having a framework that could be used also by PP> extension module writers so that there is some consistency about PP> finding and invoking tests. I think there are several unit testing frameworks for Python. Would you be willing to survey the state of these projects and suggest one for adoption? I think the current regrtest script is a bit krufty; it's certainly hard to read. Two features I'd like to see in an improved testing framework are the ability to test syntax errors, e.g. check that def foo(a): global a raises a syntax error and does not dump core. It would also be good to include tests for modules like httplib that might fail for reasons that have nothing to do with the code itself. (Perhaps one could finesse the issue by building a test suite using the SimpleHTTPServer.) I don't think there's a good way to report a non-fatal error like, "couldn't run the httplib test because the network appears to be down." Jeremy From DavidA@ActiveState.com Thu Jul 13 20:16:14 2000 From: DavidA@ActiveState.com (David Ascher) Date: Thu, 13 Jul 2000 12:16:14 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Unit testing... In-Reply-To: <14702.5156.863478.268256@bitdiddle.concentric.net> Message-ID: > I think there are several unit testing frameworks for Python. Would > you be willing to survey the state of these projects and suggest one > for adoption? I think the current regrtest script is a bit krufty; > it's certainly hard to read. doctest.py! From gvwilson@nevex.com Thu Jul 13 20:17:41 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Thu, 13 Jul 2000 15:17:41 -0400 (EDT) Subject: [Python-Dev] multi-loop quiz results Message-ID: I gave 20+ grad students in computer engineering and computer science (plus a couple of profs) the questionnaire below. A summary of results is: * Everyone understood the existing syntax (A). * Most assumed that that the 'zip()' function version would yield cross-product iteration (B). This surprised me a lot, particularly as I think we all agree that 'zip()' is the most suggestive possible name for this function. * Versions (D), (F), and (H) show that semi-colon separated targets imply cross-product iteration, but 'and' and 'while' imply simultaneous iteration. * Version (G) shows that using 'and' suggests that the sequences being iterated over must have the same length. The questionnaire and a table of responses are included below (100 characters wide). Greg ---------------------------------------------------------------------- The single and double loop below print the output shown: for x in [10, 20, 30]: for x in [10, 20, 30]: print x for y in [1, 2, 3]: print x+y 10 11 20 12 30 13 21 22 23 31 32 33 Match each of the following to its output. (Note that several examples may print the same thing.) (1) (2) (3) (4) (5) (6) 11 11 11 11 error ?? 22 12 22 12 33 13 21 21 22 22 31 23 32 31 32 33 (A) for (x, y) in [[10, 1], [20, 2], [30, 3]]: 11 0 0 0 0 0 print x+y (B) for [x, y] in zip([10, 20, 30], [1, 2, 3]): 2 6 0 0 0 3 print x+y (C) for [x, y] in zip([10, 20, 30], [1, 2]): 0 0 1 4 4 2 print x+y (D) for x in [10, 20, 30]; y in [1, 2, 3]: 3 7 0 0 1 0 print x+y (E) for x in [10, 20, 30]; y in [1, 2]: 1 0 2 6 2 0 print x+y (F) for (x in [10, 20, 30]) and (y in [1, 2, 3]): 7 4 0 0 0 0 print x+y (G) for (x in [10, 20, 30]) and (y in [1, 2]): 0 0 1 2 6 2 print x+y (H) for x in [10, 20, 30] while y in [1, 2, 3]: 2 7 0 0 1 1 print x+y (I) for x in [10, 20, 30] while y in [1, 2]: 0 1 0 7 2 1 print x+y (J) for x; y in [10, 20, 30]; [1, 2, 3]: 2 3 0 1 3 2 print x+y (K) for x; y in [10, 20, 30]; [1, 2]: 0 1 0 3 5 2 print x+y From paul@prescod.net Thu Jul 13 18:27:07 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:27:07 -0500 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> <396E08E0.7536A665@lemburg.com> Message-ID: <396DFBEB.2363922C@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Is it really necessary to have all the "code" inside the square > brackets ? That's what a list comprehension is! Check the defacto PEP: http://www.cosc.canterbury.ac.nz/~greg/python/listcomp/ I take it you are against list comprehensions. > I always thought of list comprehension as a fast way to > just throw together a list, not as a way to "program" the > list contents. IMHO, that should be done using explicit > statements in the way Skip describes above. > > I would be completely satisfied with e.g. [0..10], [0..10:2] > and [10..0]. Those are not list comprehensions but "range literals." Actually, the syntax we are using is [0:10], [0:10:2], [10:0]. I prefer dotdot, but Guido chose the colon a decade ago. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From akuchlin@mems-exchange.org Thu Jul 13 20:25:14 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 13 Jul 2000 15:25:14 -0400 Subject: [Python-Dev] Unit testing... In-Reply-To: <14702.5156.863478.268256@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 03:10:28PM -0400 References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> <14702.5156.863478.268256@bitdiddle.concentric.net> Message-ID: <20000713152514.G14938@kronos.cnri.reston.va.us> On Thu, Jul 13, 2000 at 03:10:28PM -0400, Jeremy Hylton wrote: >I think there are several unit testing frameworks for Python. Would >you be willing to survey the state of these projects and suggest one >for adoption? I'm not particularly interested in looking at other tools, since I'm quite content with mems.tools.unittest, the one that Greg wrote. Earlier this week Neil S. added code coverage support for it using Skip's coverage code, so we can see which lines of code aren't getting exercised. --amk From gvwilson@nevex.com Thu Jul 13 20:26:15 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Thu, 13 Jul 2000 15:26:15 -0400 (EDT) Subject: [Python-Dev] Unit testing... In-Reply-To: <14702.5156.863478.268256@bitdiddle.concentric.net> Message-ID: On Thu, 13 Jul 2000, Jeremy Hylton wrote: >>> Andrew Kuchling wrote: >>> (I've speculated about adding a unit testing framework... >> Paul Prescod writes: >> I think PyUnit/JUnit and friends are in vogue these days. > Jeremy Hylton wrote: > I think there are several unit testing frameworks for Python. Would > you be willing to survey the state of these projects and suggest one > for adoption? Greg Wilson writes: We (Software Carpentry judges, plus a few invited others) are trying to select a narrower set of requirements for the "test tool" category. The current front runner is some sort of unit testing framework based on Kent Beck's xUnit, combined with coverage analysis so that you get a measure of code coverage. We'd be very interested in input from anyone on this list who has experience with either Steve Purcell or Cayte Lindner's PyUnit frameworks, or has worked with tools that do this double task, or has ideas about what they'd like --- the more input we get, the more likely we are to build what you want. Please contact me (gvwilson@nevex.com) or Alex Samuel (samuel@codesourcery.com). Thanks, Greg p.s. Purcell's version is http://pyunit.sourceforge.net/ Lindner's is ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip From Fredrik Lundh" <01c601bfecf9$90cc8e80$f2a6b5d4@hagrid> <396E0E0B.C8D446BC@lemburg.com> Message-ID: <026c01bfed02$2188e380$f2a6b5d4@hagrid> mal wrote: > Uhm, why should marry() be defined for a single argument ? because map is defined for a single argument? > ... the code is there. I'd say: use it :-) well, yes. if zip/marry/whatever is just a map without the first argument, that's definitely true ;-) in case someone wants to play: Index: Python/bltinmodule.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v retrieving revision 2.170 diff -u -r2.170 bltinmodule.c --- Python/bltinmodule.c 2000/07/12 13:03:02 2.170 +++ Python/bltinmodule.c 2000/07/13 19:32:37 @@ -963,9 +963,10 @@ =20 =20 static PyObject * -builtin_map(self, args) +mapzip(self, args, zip) PyObject *self; PyObject *args; + int zip; { typedef struct { PyObject *seq; @@ -977,20 +978,31 @@ sequence *seqs =3D NULL, *sqp; int n, len; register int i, j; + int first_seq; =20 n =3D PyTuple_Size(args); - if (n < 2) { - PyErr_SetString(PyExc_TypeError, - "map() requires at least two args"); - return NULL; + if (zip) { + if (n < 1) { + PyErr_SetString(PyExc_TypeError, + "zip() requires at least one arg"); + return NULL; + } + func =3D Py_None; + first_seq =3D 0; + } else { + if (n < 2) { + PyErr_SetString(PyExc_TypeError, + "map() requires at least two args"); + return NULL; + } + func =3D PyTuple_GetItem(args, 0); + first_seq =3D 1; + n--; } =20 - func =3D PyTuple_GetItem(args, 0); - n--; - if (func =3D=3D Py_None && n =3D=3D 1) { /* map(None, S) is the same as list(S). */ - return PySequence_List(PyTuple_GetItem(args, 1)); + return PySequence_List(PyTuple_GetItem(args, first_seq)); } =20 if ((seqs =3D PyMem_NEW(sequence, n)) =3D=3D NULL) { @@ -1002,20 +1014,15 @@ int curlen; PySequenceMethods *sqf; =20 - if ((sqp->seq =3D PyTuple_GetItem(args, i + 1)) =3D=3D NULL) + if ((sqp->seq =3D PyTuple_GetItem(args, i + first_seq)) =3D=3D NULL) goto Fail_2; =20 sqp->sqf =3D sqf =3D sqp->seq->ob_type->tp_as_sequence; if (sqf =3D=3D NULL || sqf->sq_length =3D=3D NULL || - sqf->sq_item =3D=3D NULL) - { - static char errmsg[] =3D - "argument %d to map() must be a sequence object"; - char errbuf[sizeof(errmsg) + 25]; - - sprintf(errbuf, errmsg, i+2); - PyErr_SetString(PyExc_TypeError, errbuf); + sqf->sq_item =3D=3D NULL) { + PyErr_Format(PyExc_TypeError, + "argument %d to map() must be a sequence object", i+2); goto Fail_2; } =20 @@ -1118,6 +1125,16 @@ return NULL; } =20 + +static PyObject * +builtin_map(self, args) + PyObject *self; + PyObject *args; +{ + return mapzip(self, args, 0); +} + + static char map_doc[] =3D "map(function, sequence[, sequence, ...]) -> list\n\ \n\ @@ -1130,6 +1147,22 @@ =20 =20 static PyObject * +builtin_zip(self, args) + PyObject *self; + PyObject *args; +{ + return mapzip(self, args, 1); +} + + +static char zip_doc[] =3D +"zip(sequence[, sequence, ...]) -> list\n\ +\n\ +Return a list of the items of the sequence (or a list of tuples if = more\n\ +than one sequence)."; + + +static PyObject * builtin_setattr(self, args) PyObject *self; PyObject *args; @@ -2327,6 +2360,7 @@ {"unichr", builtin_unichr, 1, unichr_doc}, {"vars", builtin_vars, 1, vars_doc}, {"xrange", builtin_xrange, 1, xrange_doc}, + {"zip", builtin_zip, 1, zip_doc}, {NULL, NULL}, }; From jeremy@beopen.com Thu Jul 13 20:37:39 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 15:37:39 -0400 (EDT) Subject: [Python-Dev] Unit testing... In-Reply-To: <20000713152514.G14938@kronos.cnri.reston.va.us> References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> <14702.5156.863478.268256@bitdiddle.concentric.net> <20000713152514.G14938@kronos.cnri.reston.va.us> Message-ID: <14702.6787.986976.271026@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Thu, Jul 13, 2000 at 03:10:28PM -0400, Jeremy Hylton wrote: >> I think there are several unit testing frameworks for Python. >> Would you be willing to survey the state of these projects and >> suggest one for adoption? AMK> I'm not particularly interested in looking at other tools, I didn't mean that I wanted you to do it :-). Are you saying that you personally aren't interested or that the rest of us shouldn't be interested in either? AMK> since I'm quite content with mems.tools.unittest, the one that AMK> Greg wrote. Earlier this week Neil S. added code coverage AMK> support for it using Skip's coverage code, so we can see which AMK> lines of code aren't getting exercised. I'm not at all familiar with this code. Has it been released? Is it open source? Could it be used for the Python test suite? Jeremy From mal@lemburg.com Thu Jul 13 20:51:59 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 21:51:59 +0200 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> <396E08E0.7536A665@lemburg.com> <396DFBEB.2363922C@prescod.net> Message-ID: <396E1DDF.1861EE80@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > Is it really necessary to have all the "code" inside the square > > brackets ? > > That's what a list comprehension is! Check the defacto PEP: > > http://www.cosc.canterbury.ac.nz/~greg/python/listcomp/ > > I take it you are against list comprehensions. If it means writing code in square brackets: yes -- I don't see any real benefit other than confusing the reader... it doesn't even gain any performance (I would have thought that constant ranges like [0:10] would generate [0,1,2,3,4,5,6,7,8,9] and make this a constant, but that doesn't seem to be the case). > > I always thought of list comprehension as a fast way to > > just throw together a list, not as a way to "program" the > > list contents. IMHO, that should be done using explicit > > statements in the way Skip describes above. > > > > I would be completely satisfied with e.g. [0..10], [0..10:2] > > and [10..0]. > > Those are not list comprehensions but "range literals." Oh, so I won't get these with list comprehension ? Hmm, then I'm posting on the wrong thread, I guess ;-) > Actually, the > syntax we are using is [0:10], [0:10:2], [10:0]. I prefer dotdot, but > Guido chose the colon a decade ago. Say, wouldn't it make more sense to have these notations generate tuples (which are immutable and could thus be stored as constants) rather than lists ?! for x in (0:10): print x Hmm, looks strange, perhaps not such a good notation.... for x in (0..10): print x or even: for x in 0..10: print x Oh, now this looks much better :-) The for-loop opcode could even make some use of this by not generating a tuple at all (it could use a special mutable counter like the one available in my speedup patch for 1.5: http://starship.python.net/~lemburg/mxPython-1.5.patch.gz [see the ceval part of the patch -- it uses the counter object the patch also contains which provides a mutable integer implementation for just this purpose] The patch also includes some other performance enhancements such as a small dictionary enhancement and many other things which have already made it into 2.0) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul@prescod.net Thu Jul 13 18:34:44 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:34:44 -0500 Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> <396E0F44.59B63956@interet.com> <14702.4133.886431.381684@anthem.concentric.net> Message-ID: <396DFDB4.A257245C@prescod.net> "Barry A. Warsaw" wrote: > > ... > > We've argued about that before, although I'm not sure if we did so on > python-dev. I argued for this, in the context of distutils, but I > think Guido doesn't want to maintain this external library. We'd have > to do that if we distribute it with Python. I don't understand the last sentence???? Distributing a library with Python requires no more than "cp". Do we maintain TK on Windows? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Thu Jul 13 18:35:01 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:35:01 -0500 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <396DFDC5.6780A710@prescod.net> Huaiyu Zhu wrote: > > ... > > I wonder how orthogonal would this be against the main development? Would > it require a rebuild for each new release. Would it also require a patch > each time? I think that the idea is that you could install new syntaxes in the same way you install new modules...of course only after careful consideration!!! > Look it this way. Text processing do have their special syntaxes. Okay, but probably 90% of Python programmers do text processing at some point. Not so for matrix calculation. You believe that the Python world would grow greatly if we did matrices natively. I don't know if I believe that. I'm not entirely against your proposal but you've got to expect major pushback on such large-scale syntax and semantic changes. > PS. I suppose I am allowed to post to python-dev without invitation, but not > subscribing to it? I find this rather strange. Yes, it is rather strange. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From m.favas@per.dem.csiro.au Thu Jul 13 21:15:34 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Fri, 14 Jul 2000 04:15:34 +0800 Subject: [Python-Dev] Unicode character name hashing Message-ID: <396E2366.66F62B24@per.dem.csiro.au> [Bill has epiphany] >I just had a rather unhappy epiphany this morning. >F1, and f2 in ucnhash.c might not work on machines where sizeof(long) >!= 32 bits. I get the following from test_ucn on an Alpha running Tru64 Unix: python Lib/test/test_ucn.py UnicodeError: Unicode-Escape decoding error: Invalid Unicode Character Name This is with the current CVS - and it's been failing this test for some time now. I'm happy to test any fixes... -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From mal@lemburg.com Thu Jul 13 19:22:24 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 20:22:24 +0200 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> Message-ID: <396E08E0.7536A665@lemburg.com> Paul Prescod wrote: > > Skip Montanaro wrote: > > > > Paul> [for x: if y(x): for z: (x,y,z)] > > > > Agreed, however, your use of colons connotes the following to me > > > > l = [] > > for x in something: > > if y(x): > > for z in something_else: > > l.append((x,y,z)) > > return l > > Yes, that's right. I forgot the "in something" and "in something_else" > parts but your interpretation was still correct (a fault tolerant > notation!!). > > [for x in something: if y(x): for z in something_else: (x,y,z)] Is it really necessary to have all the "code" inside the square brackets ? I always thought of list comprehension as a fast way to just throw together a list, not as a way to "program" the list contents. IMHO, that should be done using explicit statements in the way Skip describes above. I would be completely satisfied with e.g. [0..10], [0..10:2] and [10..0]. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Thu Jul 13 21:46:42 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 13 Jul 2000 16:46:42 -0400 Subject: [Python-Dev] Unit testing... In-Reply-To: <14702.6787.986976.271026@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 03:37:39PM -0400 References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> <14702.5156.863478.268256@bitdiddle.concentric.net> <20000713152514.G14938@kronos.cnri.reston.va.us> <14702.6787.986976.271026@bitdiddle.concentric.net> Message-ID: <20000713164642.A15987@kronos.cnri.reston.va.us> On Thu, Jul 13, 2000 at 03:37:39PM -0400, Jeremy Hylton wrote: >I didn't mean that I wanted you to do it :-). Are you saying that you >personally aren't interested or that the rest of us shouldn't be >interested in either? I'm personally not interested in doing the work, that's all. Someone should definitely do this, though; a better standard testing framework would be very useful. >I'm not at all familiar with this code. Has it been released? Is it >open source? Could it be used for the Python test suite? Not formally released, no; an old version is hiding inside Quixote (http://www.mems-exchange.org/exchange/software/files/quixote/) as test.unittest.py, because it was used to write the included test suites. I could go try to get a licence for it, but you know what that'll be like. (My, aren't I sounding bitter today...) --amk From thomas@xs4all.net Thu Jul 13 22:07:00 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 23:07:00 +0200 Subject: [Python-Dev] multi-loop quiz results In-Reply-To: ; from gvwilson@nevex.com on Thu, Jul 13, 2000 at 03:17:41PM -0400 References: Message-ID: <20000713230659.W7340@xs4all.nl> On Thu, Jul 13, 2000 at 03:17:41PM -0400, Greg Wilson wrote: > I gave 20+ grad students in computer engineering and computer science > (plus a couple of profs) the questionnaire below. A summary of > results is: > * Versions (D), (F), and (H) show that semi-colon separated targets > imply cross-product iteration, but 'and' and 'while' imply > simultaneous iteration. Really ? Looking at it, it looks like 'while' also implies cross-product: > (H) > for x in [10, 20, 30] while y in [1, 2, 3]: 2 7 0 0 1 1 > print x+y > > (I) > for x in [10, 20, 30] while y in [1, 2]: 0 1 0 7 2 1 > print x+y 'and' does seem to be the 'right' thing, but mostly in the awkward extra-grouped variant... Apparently using a builtin instead of a syntax change is a good thing. Hopefully it will at least get people thinking, instead of assuming. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul@prescod.net Thu Jul 13 18:40:25 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:40:25 -0500 Subject: [Python-Dev] Unit testing... References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> <14702.5156.863478.268256@bitdiddle.concentric.net> Message-ID: <396DFF09.191A04EE@prescod.net> Jeremy Hylton wrote: > > ... > > I think there are several unit testing frameworks for Python. No, not the right guy. I'm pretty low-tech when it comes to testing. I just write long scripts that use many methods and then check coverage. I was hoping that someone else would jump in and point out the many virtues of the trendy XUnit testing framework. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Thu Jul 13 18:51:04 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:51:04 -0500 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> <396E08E0.7536A665@lemburg.com> <396DFBEB.2363922C@prescod.net> <396E1DDF.1861EE80@lemburg.com> Message-ID: <396E0188.33861CC7@prescod.net> "M.-A. Lemburg" wrote: > > If it means writing code in square brackets: yes -- > I don't see any real benefit other than confusing the reader... > it doesn't even gain any performance We've discussed making them lazy, which would improve performance in some cases...especially with infinite lists. :) > Oh, so I won't get these with list comprehension ? Hmm, then > I'm posting on the wrong thread, I guess ;-) Well, I didn't want to say it, but... > Say, wouldn't it make more sense to > have these notations generate tuples (which are immutable and > could thus be stored as constants) rather than lists ?! I think that the notation should create a generator. > The for-loop opcode could even make some use of this by not generating > a tuple at all (it could use a special mutable counter like the > one available in my speedup patch for 1.5: We discussed this yesterday. Anyhow, you don't need to use tuples to get the speedup. You just have to recognize the pattern in a peephole optimizer. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From jim@interet.com Thu Jul 13 22:42:11 2000 From: jim@interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 17:42:11 -0400 Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> <396E0F44.59B63956@interet.com> <14702.4133.886431.381684@anthem.concentric.net> Message-ID: <396E37B3.39C9BEC7@interet.com> "Barry A. Warsaw" wrote: > > >>>>> "JCA" == James C Ahlstrom writes: > > JCA> I think that what Andy wants is to have zlib always > JCA> distributed with Python, and always available. > > We've argued about that before, although I'm not sure if we did so on > python-dev. I argued for this, in the context of distutils, but I > think Guido doesn't want to maintain this external library. We'd have > to do that if we distribute it with Python. I don't think distributing zlib means we have to maintain it. Well, I guess we would have to get the new zlib version before each release, and re-write the interface functions if they change. Hmmm... Actually, I thought the issue was the megabyte size of the distribution. JimA From esr@thyrsus.com Thu Jul 13 22:54:29 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 17:54:29 -0400 Subject: [Python-Dev] List comprehensions In-Reply-To: <396E0188.33861CC7@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 12:51:04PM -0500 References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> <396E08E0.7536A665@lemburg.com> <396DFBEB.2363922C@prescod.net> <396E1DDF.1861EE80@lemburg.com> <396E0188.33861CC7@prescod.net> Message-ID: <20000713175429.A6605@thyrsus.com> Paul Prescod : > > Say, wouldn't it make more sense to > > have these notations generate tuples (which are immutable and > > could thus be stored as constants) rather than lists ?! > > I think that the notation should create a generator. I heartily agree. -- Eric S. Raymond To stay young requires the unceasing cultivation of the ability to unlearn old falsehoods. -- Lazarus Long From billtut@microsoft.com Thu Jul 13 22:44:34 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 13 Jul 2000 14:44:34 -0700 Subject: [Python-Dev] RE: Unicode character name hashing Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CF@RED-MSG-50> Does this patch happen to fix it? I'm afraid my skills relating to signed overflow is a bit rusty... :( Bill =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/ucnhash.c,v retrieving revision 1.2 diff -u -r1.2 ucnhash.c --- ucnhash.c 2000/06/29 00:06:39 1.2 +++ ucnhash.c 2000/07/13 21:41:07 @@ -30,12 +30,12 @@ len = cch; p = (unsigned char *) key; - x = 1694245428; + x = (long)0x64fc2234; while (--len >= 0) - x = (1000003*x) ^ toupper(*(p++)); + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); x ^= cch + 10; - if (x == -1) - x = -2; + if (x == (long)0xFFFFFFFF) + x = (long)0xfffffffe; x %= k_cHashElements; /* ensure the returned value is positive so we mimic Python's % operator */ if (x < 0) @@ -52,12 +52,12 @@ len = cch; p = (unsigned char *) key; - x = -1917331657; + x = (long)0x8db7d737; while (--len >= 0) - x = (1000003*x) ^ toupper(*(p++)); + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); x ^= cch + 10; - if (x == -1) - x = -2; + if (x == (long)0xFFFFFFFF) + x = (long)0xfffffffe; x %= k_cHashElements; /* ensure the returned value is positive so we mimic Python's % operator */ if (x < 0) -----Original Message----- From: Mark Favas [mailto:m.favas@per.dem.csiro.au] Sent: Thursday, July 13, 2000 1:16 PM To: python-dev@python.org; Bill Tutt Subject: Unicode character name hashing [Bill has epiphany] >I just had a rather unhappy epiphany this morning. >F1, and f2 in ucnhash.c might not work on machines where sizeof(long) >!= 32 bits. I get the following from test_ucn on an Alpha running Tru64 Unix: python Lib/test/test_ucn.py UnicodeError: Unicode-Escape decoding error: Invalid Unicode Character Name This is with the current CVS - and it's been failing this test for some time now. I'm happy to test any fixes... -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From thomas@xs4all.net Thu Jul 13 22:53:56 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 23:53:56 +0200 Subject: [Python-Dev] [PEP204] Range Literals Message-ID: <20000713235356.X7340@xs4all.nl> On Thu, Jul 13, 2000 at 11:24:38AM -0400, Barry A. Warsaw wrote: > BTW, PEP204 is up for grabs too. It's titled "Range Literals". As I already wrote Barry, I'll do this one -- but only if it's a no-brainer. The patch is already written and I hadn't heard complaints about the syntax, but now I hear some rumbling about how it should be a generator instead of a list constructor. I don't feel like digging into that particular dungball, though, having no experience what so ever with iterators, generators or languages that implement those. (So I'm a C and Python programmar by heart. Sue me.) That isn't to say I think it's a bad idea, not at all. I just don't want to do it :-) But if anyone else wants to implement it, and do so before 2.0, yell now, and you can take over the entire range-literal thing as well. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Moshe Zadka Thu Jul 13 22:56:53 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 00:56:53 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <01c601bfecf9$90cc8e80$f2a6b5d4@hagrid> Message-ID: On Thu, 13 Jul 2000, Fredrik Lundh wrote: > as in > > # normal case > for (x,) in zip([0, 1, 2]): > ... > > vs. > > # special case > for x in zip([0, 1, 2]): > ... > I'm sorry, I don't buy that. # "special case" for x in [0, 1, 2]: ... # "special case" do_something_that_requires_a_list_of_tuples(zip(*lists)) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From fdrake@beopen.com Thu Jul 13 23:01:22 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 18:01:22 -0400 (EDT) Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: <20000713235356.X7340@xs4all.nl> References: <20000713235356.X7340@xs4all.nl> Message-ID: <14702.15410.306511.372250@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > As I already wrote Barry, I'll do this one -- but only if it's a no-brainer. > The patch is already written and I hadn't heard complaints about the syntax, > but now I hear some rumbling about how it should be a generator instead of a > list constructor. I don't feel like digging into that particular dungball, > though, having no experience what so ever with iterators, generators or Don't confuse being the PEP shephard with being the implementor, though *having* an implementation is important. Who does it is secondary. Can't the implementation be to create an xrange object instead of a list? Seems easy enough on first glance. But then, I've been carefully ignoring that whole discussion. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Moshe Zadka Thu Jul 13 23:03:54 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 01:03:54 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: On Thu, 13 Jul 2000, Jeremy Hylton wrote: > I don't see the need to include the source code from other projects or > libraries in a regular Python release. Rather, I'd like to see > something like the Windows installer, which packages up third-party > software like Tcl/Tk. But I'm exactly concerned with minority platforms here: people who have packagers can manage without our help. Are you going to make an installer for Solaris? AIX? Then at least help these people build Python from source -- with "known compatible versions". I *don't* think it should be done for beta versions, only as an alternative release -- a "rich source release". (If I have some time, I might try to build something like that for 2.0 final, at any rate.) I'm currently drawing a list for extensions to include: -- zlib -- Tcl/Tk -- expat -- PIL -- Anything else? I really want something with "everything" in it. My motivation: I work on quite a few Unixes at work (AIX, Solaris, HP and probably more to come). Installing Python on any of these is a pain -- exactly because of the need to download 5-6 packages, and install them iteratively. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From guido@beopen.com Fri Jul 14 00:05:12 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 13 Jul 2000 18:05:12 -0500 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: Your message of "Thu, 13 Jul 2000 23:53:56 +0200." <20000713235356.X7340@xs4all.nl> References: <20000713235356.X7340@xs4all.nl> Message-ID: <200007132305.SAA11276@cj20424-a.reston1.va.home.com> > As I already wrote Barry, I'll do this one -- but only if it's a no-brainer. > The patch is already written and I hadn't heard complaints about the syntax, > but now I hear some rumbling about how it should be a generator instead of a > list constructor. I don't feel like digging into that particular dungball, > though, having no experience what so ever with iterators, generators or > languages that implement those. (So I'm a C and Python programmar by heart. > Sue me.) It should be sweet and simple. Make it return a list, just like range(). The whole point is that an optimizer can recognize that you are doing "for i in [0:10]: ...", and use a generator anyway -- but that's a thing for later to implement. Also, don't bother with (::) to return an xrange as has been proposed. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From Moshe Zadka Thu Jul 13 23:13:49 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 01:13:49 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: On Thu, 13 Jul 2000, Jeremy Hylton wrote: > Two things that each SRFI that PEPs don't yet have are: > > - a mail archive attached to the PEP that contains relevant > discussion. A mail archive seems valuable for people interested in > the next level of detail, but I'm not sure what mechanism to use to > create one. (It also seems valuable because the old "search > dejanews" certainly isn't stable in the long-term.) Maybe PEP > authors could maintain their own archives. I'm sure Roundup is up to this > - a copyright notice. As a strawman, I propose that the owner/author > of each PEP retains copyright, but must publish it under the > OpenContent license, . F**k licenses, they're more trouble then they're worth. Why not simply decree that it must be put in the public domain? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From esr@thyrsus.com Thu Jul 13 23:32:20 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 18:32:20 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: ; from moshez@math.huji.ac.il on Fri, Jul 14, 2000 at 01:03:54AM +0300 References: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: <20000713183220.A6899@thyrsus.com> Moshe Zadka : > I'm currently drawing a list for extensions to include: > > -- zlib > -- Tcl/Tk > -- expat > -- PIL > -- Anything else? > > I really want something with "everything" in it. > > My motivation: I work on quite a few Unixes at work (AIX, Solaris, HP and > probably more to come). Installing Python on any of these is a pain -- > exactly because of the need to download 5-6 packages, and install them > iteratively. I'm with Moshe on this one -- and I'll go further: I think the `rich' distribution ought to be the default mode, and would be willing to take on substantial work to help it happen. I agree with his choice of initial modules, too, and would certainly add ncurses, and would be sorely tempted to add libpng. Moshe's desire is a logical consequence of the "batteries are included" philosophy which is one of Python's central strengths. A good language *ought* to guarantee all its developers and users fuss-free access to a rich kit of state-of-the-art open source tools and libraries. If this means taking on the complexities of tracking several auxiliary libraries and making sure there is a consistent Python API to them as they evolve, so be it. That's our job, gentlemen. -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. From gstein@lyra.org Thu Jul 13 23:27:25 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 15:27:25 -0700 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.56551.680037.481536@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 11:14:47AM -0400 References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: <20000713152725.Z29590@lyra.org> On Thu, Jul 13, 2000 at 11:14:47AM -0400, Jeremy Hylton wrote: >... > - a copyright notice. As a strawman, I propose that the owner/author > of each PEP retains copyright, but must publish it under the > OpenContent license, . All right. This just gets me. Why must we assert copyrights on these things? Come on, people. Aren't we seeing Python 2.0 release problems because of copyrights? It isn't like this stuff is Intellectual Property or anything. It's just a summary of where the discussion is! It's a communication mechanism to bring people up to speed on the issues, concerns, and approaches. But something that needs to be copyrighted? Geez. That's just a bit much. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Moshe Zadka Thu Jul 13 23:31:35 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 01:31:35 +0300 (IDT) Subject: [Python-Dev] Re: extra packages (was: zlib not compiled by default) In-Reply-To: <20000713153251.A29590@lyra.org> Message-ID: On Thu, 13 Jul 2000, Greg Stein wrote: > On Fri, Jul 14, 2000 at 01:03:54AM +0300, Moshe Zadka wrote: > >... > > I'm currently drawing a list for extensions to include: > > > > -- zlib > > -- Tcl/Tk > > -- expat > > -- PIL > > -- Anything else? > > > > I really want something with "everything" in it. > > Don't forget pure-Python packages. > > I'd also add: mx*, and PyXML Right. The list goes on and on, but I think we can change the world with only 10 packages. and-i'm-forgetting-numpy-which-i-always-wanted-to-be-in-the-core-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Moshe Zadka Thu Jul 13 23:33:19 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 01:33:19 +0300 (IDT) Subject: [Python-Dev] Re: extra packages (was: zlib not compiled by default) In-Reply-To: <20000713153251.A29590@lyra.org> Message-ID: On Fri, Jul 14, 2000 at 01:03:54AM +0300, Moshe Zadka wrote: > I'm currently drawing a list for extensions to include: > > -- zlib > -- Tcl/Tk > -- expat > -- PIL > -- Anything else? > > I really want something with "everything" in it. Question to PythonLabs team: should I PEP this, or is this considered non-PEPable? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gstein@lyra.org Thu Jul 13 23:32:51 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 15:32:51 -0700 Subject: [Python-Dev] extra packages (was: zlib not compiled by default) In-Reply-To: ; from moshez@math.huji.ac.il on Fri, Jul 14, 2000 at 01:03:54AM +0300 References: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: <20000713153251.A29590@lyra.org> On Fri, Jul 14, 2000 at 01:03:54AM +0300, Moshe Zadka wrote: >... > I'm currently drawing a list for extensions to include: > > -- zlib > -- Tcl/Tk > -- expat > -- PIL > -- Anything else? > > I really want something with "everything" in it. Don't forget pure-Python packages. I'd also add: mx*, and PyXML Cheers, -g -- Greg Stein, http://www.lyra.org/ From jeremy@beopen.com Fri Jul 14 00:09:12 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 19:09:12 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <20000713152725.Z29590@lyra.org> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> Message-ID: <14702.19480.746784.235766@bitdiddle.concentric.net> >>>>> "GS" == Greg Stein writes: GS> It isn't like this stuff is Intellectual Property or GS> anything. It's just a summary of where the discussion is! It's a GS> communication mechanism to bring people up to speed on the GS> issues, concerns, and approaches. This may not be material to the discussion: It's not just a summary of discussion. It's a real proposal, including specification for the feature and rationale for the spec. GS> But something that needs to be copyrighted? Geez. That's just a GS> bit much. I think it stinks, but I'd hate to see distribution of these documents hampered because someone comes along and denies us the right to use it. I'd be satisfied with a statement of copyright or the notice "placed in the public domain" attached to each of them. My only concern is that without some explicit expression of rights, some party might try to prevent us from distributing a PEP. Jeremy From fdrake@beopen.com Fri Jul 14 00:07:21 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 19:07:21 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <20000713152725.Z29590@lyra.org> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> Message-ID: <14702.19369.605446.28207@cj42289-a.reston1.va.home.com> Greg Stein writes: > Why must we assert copyrights on these things? Come on, people. Aren't we > seeing Python 2.0 release problems because of copyrights? No. *Licensing* is distinct from copyright, and that's where we see problems. The copyrights are indisputable, but are not a problem. > It isn't like this stuff is Intellectual Property or anything. It's just a Let's not get into that one! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Fri Jul 14 00:11:27 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 19:11:27 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14702.19480.746784.235766@bitdiddle.concentric.net> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> <14702.19480.746784.235766@bitdiddle.concentric.net> Message-ID: <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > I think it stinks, but I'd hate to see distribution of these documents > hampered because someone comes along and denies us the right to use > it. I'd be satisfied with a statement of copyright or the notice > "placed in the public domain" attached to each of them. The copyright and license are both required to ensure permission to use, distribute, etc. There are a few "open content" licenses, and a reference to one of those should be sufficient. I don't know which one to recommend, however; that would require spending a little time reading them. > My only concern is that without some explicit expression of rights, > some party might try to prevent us from distributing a PEP. You hit that nail! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From m.favas@per.dem.csiro.au Fri Jul 14 00:22:48 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Fri, 14 Jul 2000 07:22:48 +0800 Subject: [Python-Dev] Re: extra packages (was: zlib not compiled by default) Message-ID: <396E4F48.71AD4103@per.dem.csiro.au> I'd like to see Pmw in there as well - and definitely numpy. Whatever _did_ happen to the proposal that it become part of the core...? -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From peter@schneider-kamp.de Fri Jul 14 03:38:33 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 14 Jul 2000 02:38:33 +0000 Subject: [Python-Dev] Pythonb at SourceForge FAQ Message-ID: <396E7D29.7AC68EA6@schneider-kamp.de> This is a multi-part message in MIME format. --------------EB3DB050B397AB4D7BEE882A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I started a small FAQ. Where should I put this? HTML file attached. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de --------------EB3DB050B397AB4D7BEE882A Content-Type: text/html; charset=us-ascii; name="sf-faq.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sf-faq.html"

Python at SourceForge - Frequently Asked Questions

0. Contents

1. General

  1. What is SourceForge?
  2. Where do I find Python there?

2. CVS

  1. How do I check out a CVS version of Python?
  2. What settings should I use?
  3. Troubleshooting: "Permission Denied"
  4. Where can I learn more about CVS?

3. Patches

  1. How to make a patch?
  2. How to submit patches?
  3. How to change the status of a patch?

A. Appendix

  1. Patch Manager Guidelines [09.07.2000]
  2. Python Patch Submission Guidelines [29.06.2000]

1. General

1.1.:

Q: What is SourceForge?

A:

SourceForge is a free hosting service for OpenSource projects. The main website is found at
http://sourceforge.net

1.2.:

Q: Where can I find Python on SourceForge?

A:

The Python project page can be found at
http://sourceforge.net/projects/python

2. CVS

2.1.:

Q: How do I check out a CVS version of Python?

A:

If  you are not a SourceForge-recognized Python developer you can still check out an anonymous CVS version (read-only) of Python:
export CVSROOT=:pserver:anonymous@cvs.python.sourceforge.net:/cvsroot/python
cvs login
cvs -z3 co python
If you are indeed a developer you can check out a read/write version with ssh:
export CVS_RSH=ssh
export CVSROOT=sf_username@cvs.python.sourceforge.net:/cvsroot/python
cvs -z3 co python

2.2.:

Q:  What setting should I use?

A:

That is, of course, hard to answer in the general case. I use the following .cvsrc file:
diff -c
update -d
This defaults diff to context diffs (almost a requirement as everything else is harder to read) and tells update to automatically checkout new subdirectories.

2.3.:

Q: I get the following error message:

Sorry, you don't have read/write access to the history file /cvsroot/python/CVSROOT/history
Permission denied

A:

If you are not a developer, you don't have read/write access. You have to check out an anonymous copy. If you are a developer you have to be in the SourceForge group "python". You can check this with the following commands:
ssh -l sf_username shell.sourceforge.net
groups
If you have just recently (< 6 hours) been added to the Python project, you probably have to wait for the SourceForge servers to synch up. This can take up to 6 hours.

2.4.:

Q: Where can I learn more about CVS?

A:

For SourceForge specific information consult their CVS documentation at
http://sfdocs.sourceforge.net/sfdocs
For general (and more advanced) information consult the free CVS Book at
http://cvsbook.red-bean.com/cvsbook.html#Introduction

3. Patches

3.1.:

Q: How to make a patch?

A:

If you are using CVS (anonymous or developer) you can use CVS to make the patches for you. Just edit your local copy and enter the following command:
cvs diff | tee ~/name_of_the_patch.diff
Else you can use the diff util which comes with most operating systems (a Windows version is available as part of the cygwin tools).
 

3.2.:

Q: How to submit a patch?

A:

Please read the Patch Submission Guidelines at
http://www.python.org/patches
A recent copy can be found in the Appendix of this FAQ.
 

3.3.:

Q: How to change the status of a patch?

A:

To change the status of a patch or assign it to somebody else you have to be a) a SourceForge-recognized Python developer and b) a patch administrator. Unfortunately the SourceForge default for developers is not to be patch administrators. Contact one of the project administrators if the following does not work for you.

Click on the patch itself. In the screen that comes up, there is a drop-box for "Assigned To:" and a drop-box for "Status:" where you can select a new responsible developer or a new status respectively. After selecting the appropriate victim and status, hit the "Submit Changes" button at the bottom of the page.

For more information about the use of the "Status:" and "Assigned To:" fields consult the Patch Manager Guidelines. A recent copy can be found in the Appendix of this FAQ.
 

A. Appendix

A.1.: Patch Manager Guidelines

Intended use of SourceForge patch status & "assigned to" fields

revision 2                                          09-Jul-2000

In general, the status field should be close to self-explanatory, and the "Assigned to:" field should be the person responsible for taking the next step in the patch process.  Both fields are expected to change value over the life of a patch; the normal workflow is detailed below.

When you've got the time and the ability, feel free to move any patch that catches your eye along, whether or not it's been assigned to you.  And if you're assigned to a patch but aren't going to take reasonably quick action (for whatever reason), please assign it to someone else ASAP:  at those times you can't actively help, actively get out of the way.

If you're an expert in some area and know that a patch in that area is both needed and non-controversial, just commit your changes directly -- no need then to get the patch mechanism involved in it.

You should add a comment to every patch assigned to you at least once a week, if only to say that you realize it's still on your plate.  This rule is meant to force your attention periodically:  patches get harder & harder to deal with the longer they sit.
 

Open

The initial status of all patches.
The patch is under consideration, but has not been reviewed yet.
The status will normally change to Accepted or Rejected next.
The person submitting the patch should (if they can) assign it to the person they most want to review it.
Else the patch will be assigned via [xxx a list of expertise areas should be developed] [xxx but since this hasn't happened and volunteers are too few, random assignment is better than nothing:  if you're a Python developer, expect to get assigned out of the blue!]
Discussion of major patches is carried out on the Python-Dev mailing list.  For simple patches, the SourceForge comment mechanism should be sufficient. [xxx an email gateway would be great, ditto Ping's Roundup]

Accepted

The powers that be accepted the patch, but it hasn't been applied yet. [xxx flesh out -- Guido Bottleneck avoidable here?]
The status will normally change to Closed next.
The person changing the status to Accepted should, at the same time, assign the patch to whoever they believe is most likely to be able & willing to apply it (the submitter if possible).

Closed

The patch has been accepted and applied.
The previous status was Accepted, or possibly Open if the submitter was Guido (or moral equivalent in some particular area of expertise).

Rejected

The patch has been reviewed and rejected.
When the objections are addressed, the status may change to Open again.
The person changing the status to Rejected should assign the patch back to the submitter, or if it's clear the patch will never be accepted, assign it to None.
Note that SourceForge allows the submitter to overwrite the patch with a new version.

Out of date

Previous status was Open or Accepted or Postponed, but the patch no longer works.
Please enter a comment when changing the status to "Out of date", to record the nature of the problem and the previous status.
Also assign it back to the submitter, as they need to upload a new version (note that SourceForge will not allow anyone other than the original submitter to update the patch).

Postponed

The previous status was Open or Accepted, but for some reason (e.g., pending release) the patch should not be reviewed or applied until further notice.
The status will normally change to Open or Accepted next.
Please enter a comment when changing the status to Postponed, to record the reason, the previous status, and the conditions under which the patch should revert to Open or Accepted.  Also assign the patch to whoever is most likely able and willing to decide when the status should change again.

Deleted

Bit bucket.
Use only if it's OK for the patch and its SourceForge history to disappear.
As of 09-July-2000, SF does not actually throw away Deleted patches, but that may change.

A.2.: Python Patch Submission Guidelines

New: CNRI is no longer involved in Python patches. We no longer request legal disclaimers. Also, We're now using the SourceForge Patch Manager (a single mailing list became unmanageable).

Many people contribute patches to Python. We've set up a new system to deal with these. Here are the main guidelines:

  • Submit your patch to the patch manager interface at SourceForge. We strongly recommend that you register with SourceForge before submitting a patch. If you send patches directly to Guido you introduce an extra delay. Ditto for the "patches@python.org" mailing list address; this address should no longer be used for patch submission. The patch manager is for patches only; if you have a problem or suggestion but don't know how to write the code for it, use the Python Bugs List instead. The bugs list is searchable; if you have a problem and you're not sure if it has been reported or fixed already, this is the first place to look. (There used to be a separate TODO list; we now prefer that you use the bugs list for suggestions and requests too.)

    •  

     

    Submit documentation patches the same way. When adding the patch, be sure to set the "Category" field to "documentation". For documentation errors without patches, please use the Python Bugs List instead.

  • We like context diffs. We grudgingly accept unified diffs. Straight ("ed-style") diffs are right out! If you don't know how to generate context diffs, you're probably not qualified to produce high-quality patches anyway <0.5 wink>.
  • We appreciate it if you send patches relative to the current CVS tree. These are our latest sources. It's almost a year since Python 1.5.2 was released, and many source files have been touched in more or less significant ways; a patch relative to Python 1.5.2 can cause a lot of extra pain to apply right. Even a patch relative to the latest alpha or beta release may be way out of date.
  • Please add a succinct message to your SourceForge entry that explains what the patch is about that we can use directly as a checkin message. Ideally, such a message explains the problem and describes the fix in a few lines.
  • For patches that add or change functionality: please also update the documentation and the testcases (the Lib/test subdirectory). For new modules, we appreciate a new test module (typically test/test_spam.py). In this case, there's no need to mail the documentation to a different address (in fact, in order to verify that the bundle is complete, it's easier to mail everything together).
  • There are a variety of additional style requirements. Please have a look at these before writing new code. Also have a look at the general Python Style Guide.
--------------EB3DB050B397AB4D7BEE882A-- From gstein@lyra.org Fri Jul 14 01:45:54 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 17:45:54 -0700 Subject: [Python-Dev] Pythonb at SourceForge FAQ In-Reply-To: <396E7D29.7AC68EA6@schneider-kamp.de>; from peter@schneider-kamp.de on Fri, Jul 14, 2000 at 02:38:33AM +0000 References: <396E7D29.7AC68EA6@schneider-kamp.de> Message-ID: <20000713174554.R29590@lyra.org> Since we don't have ready access to python.org, I would suggest turning on the Python web pages at SF and placing it there. (of course, with obvious links from python.sourceforge.net to python.org) Having a FAQ about Python/SF at SF makes sense to me :-) Cheers, -g On Fri, Jul 14, 2000 at 02:38:33AM +0000, Peter Schneider-Kamp wrote: > I started a small FAQ. Where should I put this? > > HTML file attached. > > Peter > -- > Peter Schneider-Kamp ++47-7388-7331 > Herman Krags veg 51-11 mailto:peter@schneider-kamp.de > N-7050 Trondheim http://schneider-kamp.de > > Python at SourceForge - Frequently Asked Questions > > 0. Contents > > [1]1. General > > 1. [2]What is SourceForge? > 2. [3]Where do I find Python there? > > [4]2. CVS > > 1. [5]How do I check out a CVS version of Python? > 2. [6]What settings should I use? > 3. [7]Troubleshooting: "Permission Denied" > 4. [8]Where can I learn more about CVS? > > [9]3. Patches > > 1. [10]How to make a patch? > 2. [11]How to submit patches? > 3. [12]How to change the status of a patch? > > [13]A. Appendix > > 1. [14]Patch Manager Guidelines [09.07.2000] > 2. [15]Python Patch Submission Guidelines [29.06.2000] > > 1. General > > 1.1.: > > Q: What is SourceForge? > > A: > > [16]SourceForge is a free hosting service for [17]OpenSource projects. > The main website is found at > > [18]http://sourceforge.net > > 1.2.: > > Q: Where can I find Python on SourceForge? > > A: > > The [19]Python project page can be found at > > [20]http://sourceforge.net/projects/python > > 2. CVS > > 2.1.: > > Q: How do I check out a CVS version of Python? > > A: > > If you are not a SourceForge-recognized Python developer you can > still check out an anonymous CVS version (read-only) of Python: > > export > CVSROOT=:pserver:anonymous@cvs.python.sourceforge.net:/cvsroot/pyth > on > cvs login > cvs -z3 co python > > If you are indeed a developer you can check out a read/write version > with ssh: > > export CVS_RSH=ssh > export > CVSROOT=sf_username@cvs.python.sourceforge.net:/cvsroot/python > cvs -z3 co python > > 2.2.: > > Q: What setting should I use? > > A: > > That is, of course, hard to answer in the general case. I use the > following .cvsrc file: > > diff -c > update -d > > This defaults diff to context diffs (almost a requirement as > everything else is harder to read) and tells update to automatically > checkout new subdirectories. > > 2.3.: > > Q: I get the following error message: > > Sorry, you don't have read/write access to the history file > /cvsroot/python/CVSROOT/history > Permission denied > > A: > > If you are not a developer, you don't have read/write access. You have > to check out an anonymous copy. If you are a developer you have to be > in the SourceForge group "python". You can check this with the > following commands: > > ssh -l sf_username shell.sourceforge.net > groups > > If you have just recently (< 6 hours) been added to the Python > project, you probably have to wait for the SourceForge servers to > synch up. This can take up to 6 hours. > > 2.4.: > > Q: Where can I learn more about CVS? > > A: > > For SourceForge specific information consult their CVS documentation > at > > [21]http://sfdocs.sourceforge.net/sfdocs > > For general (and more advanced) information consult the free CVS Book > at > > [22]http://cvsbook.red-bean.com/cvsbook.html#Introduction > > 3. Patches > > 3.1.: > > Q: How to make a patch? > > A: > > If you are using CVS (anonymous or developer) you can use CVS to make > the patches for you. Just edit your local copy and enter the following > command: > > cvs diff | tee ~/name_of_the_patch.diff > > Else you can use the diff util which comes with most operating systems > (a Windows version is available as part of the cygwin tools). > > > 3.2.: > > Q: How to submit a patch? > > A: > > Please read the [23]Patch Submission Guidelines at > > [24]http://www.python.org/patches > > A [25]recent copy can be found in the Appendix of this FAQ. > > > 3.3.: > > Q: How to change the status of a patch? > > A: > > To change the status of a patch or assign it to somebody else you have > to be a) a SourceForge-recognized Python developer and b) a patch > administrator. Unfortunately the SourceForge default for developers is > not to be patch administrators. Contact one of the project > administrators if the following does not work for you. > > Click on the patch itself. In the screen that comes up, there is a > drop-box for "Assigned To:" and a drop-box for "Status:" where you can > select a new responsible developer or a new status respectively. After > selecting the appropriate victim and status, hit the "Submit Changes" > button at the bottom of the page. > > For more information about the use of the "Status:" and "Assigned To:" > fields consult the [26]Patch Manager Guidelines. A recent copy can be > found in the Appendix of this FAQ. > > A. Appendix > > A.1.: Patch Manager Guidelines > > Intended use of SourceForge patch status & "assigned to" fields > > revision 2 09-Jul-2000 > > In general, the status field should be close to self-explanatory, and > the "Assigned to:" field should be the person responsible for taking > the next step in the patch process. Both fields are expected to > change value over the life of a patch; the normal workflow is detailed > below. > > When you've got the time and the ability, feel free to move any patch > that catches your eye along, whether or not it's been assigned to > you. And if you're assigned to a patch but aren't going to take > reasonably quick action (for whatever reason), please assign it to > someone else ASAP: at those times you can't actively help, actively > get out of the way. > > If you're an expert in some area and know that a patch in that area is > both needed and non-controversial, just commit your changes directly > -- no need then to get the patch mechanism involved in it. > > You should add a comment to every patch assigned to you at least once > a week, if only to say that you realize it's still on your plate. > This rule is meant to force your attention periodically: patches get > harder & harder to deal with the longer they sit. > > Open > > The initial status of all patches. > The patch is under consideration, but has not been reviewed yet. > The status will normally change to Accepted or Rejected next. > The person submitting the patch should (if they can) assign it to > the person they most want to review it. > Else the patch will be assigned via [xxx a list of expertise areas > should be developed] [xxx but since this hasn't happened and > volunteers are too few, random assignment is better than nothing: > if you're a Python developer, expect to get assigned out of the > blue!] > Discussion of major patches is carried out on the Python-Dev > mailing list. For simple patches, the SourceForge comment > mechanism should be sufficient. [xxx an email gateway would be > great, ditto Ping's Roundup] > > Accepted > > The powers that be accepted the patch, but it hasn't been applied > yet. [xxx flesh out -- Guido Bottleneck avoidable here?] > The status will normally change to Closed next. > The person changing the status to Accepted should, at the same > time, assign the patch to whoever they believe is most likely to be > able & willing to apply it (the submitter if possible). > > Closed > > The patch has been accepted and applied. > The previous status was Accepted, or possibly Open if the submitter > was Guido (or moral equivalent in some particular area of > expertise). > > Rejected > > The patch has been reviewed and rejected. > When the objections are addressed, the status may change to Open > again. > The person changing the status to Rejected should assign the patch > back to the submitter, or if it's clear the patch will never be > accepted, assign it to None. > Note that SourceForge allows the submitter to overwrite the patch > with a new version. > > Out of date > > Previous status was Open or Accepted or Postponed, but the patch no > longer works. > Please enter a comment when changing the status to "Out of date", > to record the nature of the problem and the previous status. > Also assign it back to the submitter, as they need to upload a new > version (note that SourceForge will not allow anyone other than the > original submitter to update the patch). > > Postponed > > The previous status was Open or Accepted, but for some reason > (e.g., pending release) the patch should not be reviewed or applied > until further notice. > The status will normally change to Open or Accepted next. > Please enter a comment when changing the status to Postponed, to > record the reason, the previous status, and the conditions under > which the patch should revert to Open or Accepted. Also assign the > patch to whoever is most likely able and willing to decide when the > status should change again. > > Deleted > > Bit bucket. > Use only if it's OK for the patch and its SourceForge history to > disappear. > As of 09-July-2000, SF does not actually throw away Deleted > patches, but that may change. > > A.2.: Python Patch Submission Guidelines > > New: CNRI is no longer involved in Python patches. We no longer > request legal disclaimers. Also, We're now using the SourceForge Patch > Manager (a single mailing list became unmanageable). > > Many people contribute patches to Python. We've set up a new system to > deal with these. Here are the main guidelines: > * Submit your patch to the [27]patch manager interface at > [28]SourceForge. We strongly recommend that you [29]register with > SourceForge before submitting a patch. If you send patches > directly to Guido you introduce an extra delay. Ditto for the > "patches@python.org" mailing list address; this address should no > longer be used for patch submission. The patch manager is for > patches only; if you have a problem or suggestion but don't know > how to write the code for it, use the [30]Python Bugs List > instead. The bugs list is searchable; if you have a problem and > you're not sure if it has been reported or fixed already, this is > the first place to look. (There used to be a separate TODO list; > we now prefer that you use the bugs list for suggestions and > requests too.) > > > Submit documentation patches the same way. When adding the patch, > be sure to set the "Category" field to "documentation". For > documentation errors without patches, please use the [31]Python > Bugs List instead. > * We like context diffs. We grudgingly accept unified diffs. > Straight ("ed-style") diffs are right out! If you don't know how > to generate context diffs, you're probably not qualified to > produce high-quality patches anyway <0.5 wink>. > * We appreciate it if you send patches relative to the [32]current > CVS tree. These are our latest sources. It's almost a year since > Python 1.5.2 was released, and many source files have been touched > in more or less significant ways; a patch relative to Python 1.5.2 > can cause a lot of extra pain to apply right. Even a patch > relative to the latest alpha or beta release may be way out of > date. > * Please add a succinct message to your SourceForge entry that > explains what the patch is about that we can use directly as a > checkin message. Ideally, such a message explains the problem and > describes the fix in a few lines. > * For patches that add or change functionality: please also update > the documentation and the testcases (the Lib/test subdirectory). > For new modules, we appreciate a new test module (typically > test/test_spam.py). In this case, there's no need to mail the > documentation to a different address (in fact, in order to verify > that the bundle is complete, it's easier to mail everything > together). > * There are a variety of additional [33]style requirements. Please > have a look at these before writing new code. Also have a look at > the general [34]Python Style Guide. > > References > > 1. file://localhost/tmp/sf-faq.html#general > 2. file://localhost/tmp/sf-faq.html#g1 > 3. file://localhost/tmp/sf-faq.html#g2 > 4. file://localhost/tmp/sf-faq.html#cvs > 5. file://localhost/tmp/sf-faq.html#c1 > 6. file://localhost/tmp/sf-faq.html#c2 > 7. file://localhost/tmp/sf-faq.html#c3 > 8. file://localhost/tmp/sf-faq.html#c4 > 9. file://localhost/tmp/sf-faq.html#patches > 10. file://localhost/tmp/sf-faq.html#p1 > 11. file://localhost/tmp/sf-faq.html#p2 > 12. file://localhost/tmp/sf-faq.html#p3 > 13. file://localhost/tmp/sf-faq.html#appendix > 14. file://localhost/tmp/sf-faq.html#a1 > 15. file://localhost/tmp/sf-faq.html#a2 > 16. http://sourceforge.net/ > 17. http://opensource.org/ > 18. http://sourceforge.net/ > 19. http://sourceforge.net/projects/python > 20. http://sourceforge.net/projects/python > 21. http://sfdocs.sourceforge.net/sfdocs > 22. http://cvsbook.red-bean.com/cvsbook.html#Introduction > 23. http://www.python.org/patches > 24. http://www.python.org/patches > 25. file://localhost/tmp/sf-faq.html#a2 > 26. file://localhost/tmp/sf-faq.html#a1 > 27. http://sourceforge.net/patch/?group_id=5470 > 28. http://sourceforge.net/project/?group_id=5470 > 29. http://sourceforge.net/account/register.php > 30. http://www.python.org/search/search_bugs.html > 31. http://www.python.org/search/search_bugs.html > 32. http://sourceforge.net/cvs/?group_id=5470 > 33. http://www.python.org/patches/style.html > 34. http://www.python.org/doc/essays/styleguide.html -- Greg Stein, http://www.lyra.org/ From jeremy@beopen.com Fri Jul 14 01:59:40 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 20:59:40 -0400 (EDT) Subject: [Python-Dev] Pythonb at SourceForge FAQ In-Reply-To: <396E7D29.7AC68EA6@schneider-kamp.de> References: <396E7D29.7AC68EA6@schneider-kamp.de> Message-ID: <14702.26108.53369.420712@bitdiddle.concentric.net> You could check it into the Python distribution under Misc. I can arrange for it to be displayed at pythonlabs.com. Jeremy From peter@schneider-kamp.de Fri Jul 14 04:26:04 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 14 Jul 2000 03:26:04 +0000 Subject: http://python.sourceforge.net (was: Re: [Python-Dev] Pythonb at SourceForge FAQ) References: <396E7D29.7AC68EA6@schneider-kamp.de> <20000713174554.R29590@lyra.org> Message-ID: <396E884C.B55E4737@schneider-kamp.de> Hi Greg! I made a small link page (to python.org, sourceforge.net/projects/python and sf-faq.html) and loaded it up together with the faq (sf-faq.html). Anyone with a bit more feeling for design than me should feel free to improve it. Peter Greg Stein wrote: > > Since we don't have ready access to python.org, I would suggest turning on > the Python web pages at SF and placing it there. > > (of course, with obvious links from python.sourceforge.net to python.org) > > Having a FAQ about Python/SF at SF makes sense to me :-) > > Cheers, > -g -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From huaiyu_zhu@yahoo.com Fri Jul 14 02:30:02 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Thu, 13 Jul 2000 18:30:02 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] Message-ID: Paul Prescod wrote: > I think that the idea is that you could install new syntaxes in the same > way you install new modules...of course only after careful > consideration!!! This is much more than I has bargained for. Separting syntax with sematics is really the way to go. > I'm not entirely against your proposal but you've got to expect major > pushback on such large-scale syntax and semantic changes. Well, I was only asking for some additional operators, which wouldn't affect a single line of existing code. Everyone says no you can't get it, that's too much, but on the other hand you should get a parser to change the syntax anyway you want. So if I ask more I shall get the bit I wanted. When would this wonderful new parser be available so that I can change the syntax beyond recognition? :-) > > Look it this way. Text processing do have their special syntaxes. > > Okay, but probably 90% of Python programmers do text processing at some > point. Not so for matrix calculation. You believe that the Python world > would grow greatly if we did matrices natively. I don't know if I > believe that. I don't believe python should be bond to this heritage as much as perl does. Maybe those who do matrix have not joined yet. To justify support by the number of existing users sounds like a self-fulfilling prophacy. Think about how many users would do text precessing if they have to write regular expressions as layers of composite functions? How many would use arithmetic if they have to write add(mul(1,2),div(2.,3.))? Now compare what's written in matlab/octave (X'*X)\(X'*y) with what's written in python matrixmultiply(inverse(matrixmultiply(transpose(X), X)), (matrixmultiply(transpose(X), y[:,NewAxis]))) Now look at the total number of users of matlab/octave, and ask: Is python really so inferior that most of them wouldn't switch to python? To change this status does not even need native support of matrix. The only thing required is that there be enough binary operators to be overridden by applications - any application that needs additional binary operators. > > PS. I suppose I am allowed to post to python-dev without invitation, but > > not subscribing to it? I find this rather strange. > > Yes, it is rather strange. But I can see its use now. I have to get your reply from web and cut and paste in order to reply again. :-( Huaiyu From peter@schneider-kamp.de Fri Jul 14 04:29:59 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 14 Jul 2000 03:29:59 +0000 Subject: [Python-Dev] Pythonb at SourceForge FAQ References: <396E7D29.7AC68EA6@schneider-kamp.de> <14702.26108.53369.420712@bitdiddle.concentric.net> Message-ID: <396E8937.6FA299D2@schneider-kamp.de> Jeremy Hylton wrote: > > You could check it into the Python distribution under Misc. I can > arrange for it to be displayed at pythonlabs.com. Been there, done that. Following Greg's advice I put it up on http://python.sourceforge.net. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul@prescod.net Thu Jul 13 23:44:29 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 17:44:29 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> <14702.19480.746784.235766@bitdiddle.concentric.net> <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> Message-ID: <396E464D.F6D841ED@prescod.net> "Fred L. Drake, Jr." wrote: > > ... > > The copyright and license are both required to ensure permission to > use, distribute, etc. There are a few "open content" licenses, and a > reference to one of those should be sufficient. I don't know which > one to recommend, however; that would require spending a little time > reading them. Let me recommend my favorite: "Placed in the public domain." -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Thu Jul 13 23:48:38 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 17:48:38 -0500 Subject: [Python-Dev] [PEP204] Range Literals References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> Message-ID: <396E4746.DE25EFD4@prescod.net> Guido van Rossum wrote: > > ... > It should be sweet and simple. Make it return a list, just like > range(). The whole point is that an optimizer can recognize that you > are doing "for i in [0:10]: ...", and use a generator anyway -- but > that's a thing for later to implement. > > Also, don't bother with (::) to return an xrange as has been proposed. If Guido has decided that the design that has already been implemented is the right one, what's the point of the PEP? Someone just needs to review the patch and check it in! -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Thu Jul 13 23:48:39 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 17:48:39 -0500 Subject: [Python-Dev] [PEP204] Range Literals References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> Message-ID: <396E4747.9D055A96@prescod.net> Guido van Rossum wrote: > > .. > > It should be sweet and simple. Make it return a list, just like > range(). The whole point is that an optimizer can recognize that you > are doing "for i in [0:10]: ...", and use a generator anyway -- but > that's a thing for later to implement. Why disallow this: fives=[0:maxint:5] As Fred points out, we've already got the underlying object implementation in the src! MAL also pointed out that immutable objects (like xranges) can be safely precomputed and reused. Finally, whatever the answer is, it should probably be the same as list comprehensions. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Thu Jul 13 23:49:12 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 17:49:12 -0500 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <396E4768.A77473AA@prescod.net> Huaiyu Zhu wrote: > > ... > > So if I ask more I shall get the bit I wanted. When would this wonderful > new parser be available so that I can change the syntax beyond recognition? > :-) It all depends on who works on it and how hard they work. I really can't predict. There some Python features that I thought were years away and appeared from nowhere (cyclic gc) and others that seem perpetually on the verge of being available (e.g. a compiler that achieves order of magnitude performance improvements). If I had to pick a version number out of the wind I would say 2.1 or 2.2. I would predict the same timeline for any new operators. By the way, there is already a language specifically designed to allow people with particular interests to extend the syntax fairly arbitrarily. It is called REBOL. I think TCL is also a little more forgiving about syntactic variance. There may be others. > I don't believe python should be bond to this heritage as much as perl does. > Maybe those who do matrix have not joined yet. To justify support by the > number of existing users sounds like a self-fulfilling prophacy. It isn't the existing users. It's the users that we see around us. I don't remember anyone ever asking me for help using Python for matrices, at any company I have ever worked at. Obviously you live in a different world. Either of our perceptions could be skewed. Perhaps the best bet would be for you to make a matrix variant of Python so popular that we could see the audience in terms of downloads and discussions. > Now compare what's written in matlab/octave > > (X'*X)\(X'*y) > > with what's written in python > > matrixmultiply(inverse(matrixmultiply(transpose(X), X)), > (matrixmultiply(transpose(X), y[:,NewAxis]))) There must be a more compact syntax! Even without knowing the semantics: from matrix import tickmult, backslash backslash( tickmult( X, X ), tickmult( X, y )) > Now look at the total number of users of matlab/octave, and ask: Is python > really so inferior that most of them wouldn't switch to python? I have no idea. If the primary difference between expensive matrix packages and Python is syntax, perhaps you and I should incorporate and exploit that market inefficiency. :) > To change this status does not even need native support of matrix. The only > thing required is that there be enough binary operators to be overridden by > applications - any application that needs additional binary operators. Michael Hudson has a tagline that made me laugh out loud: I saw `cout' being shifted "Hello world" times to the left and stopped right there. -- Steve Gonedes He's talking about the random-seeming overloadings you get in C++ because there are so many overloadable operators and they are so poorly defined. Anyhow, what if I want a different syntax for the XML operators. "->" and "<-" might be useful. I am half-tempted to suggest a system where anyone could add new operators, perhaps in quotes or back-ticks or something but I am very afraid of what happens when the people who evented "cout shifting" get their hands on it! > But I can see its use now. I have to get your reply from web and cut and > paste in order to reply again. :-( How long until some enterprising Python programmer makes a utility that polls the website, and generates an email version of each message as it appears? :) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From jeremy@beopen.com Fri Jul 14 03:28:10 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 22:28:10 -0400 (EDT) Subject: [Python-Dev] urllib vs. cgi Message-ID: <14702.31418.483935.810948@bitdiddle.concentric.net> I was doing a little Web programming this evening and discovered an annoying asymmetry. The urllib module has a urlencode function that translates a dictionary of form entries into a URL query string. I wanted the inverse "urldecode" that turns the query string into the dictionary. There isn't one. But I guessed that CGI programmers had to have a function to do this! It seems there is one called cgi.parse_qs. This wasn't an obvious place to look, because I wasn't doing CGI programming at all. (I was writing a screen-scraped for SourceForge.) Any opinions on adding a symmetrical urldecode to urllib? I'm not thrilled by duplicating code, but the cgi module is big and hairy and urllib seems like the obvious place for it. Jeremy From esr@thyrsus.com Fri Jul 14 03:44:10 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 22:44:10 -0400 Subject: [Python-Dev] urllib vs. cgi In-Reply-To: <14702.31418.483935.810948@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 10:28:10PM -0400 References: <14702.31418.483935.810948@bitdiddle.concentric.net> Message-ID: <20000713224410.A7548@thyrsus.com> Jeremy Hylton : > Any opinions on adding a symmetrical urldecode to urllib? I'm not > thrilled by duplicating code, but the cgi module is big and hairy and > urllib seems like the obvious place for it. +0. It doesn't thrill me, but I can't argue with your analysis either. -- Eric S. Raymond The two pillars of `political correctness' are, a) willful ignorance, and b) a steadfast refusal to face the truth -- George MacDonald Fraser From esr@snark.thyrsus.com Fri Jul 14 03:46:37 2000 From: esr@snark.thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 22:46:37 -0400 Subject: [Python-Dev] ConfigParser changes Message-ID: <200007140246.WAA07574@snark.thyrsus.com> I've seen a couple plus responses to my proposed ConfigParser enhancements, no minuses, and the thread has petered out. If nobody hands me a -1, I'm going to merge them in in a day or so. Speak now... -- Eric S. Raymond "The state calls its own violence `law', but that of the individual `crime'" -- Max Stirner From bwarsaw@beopen.com Fri Jul 14 04:57:09 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 23:57:09 -0400 (EDT) Subject: [Python-Dev] Re: extra packages (was: zlib not compiled by default) References: <20000713153251.A29590@lyra.org> Message-ID: <14702.36757.14686.842685@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> Question to PythonLabs team: should I PEP this, or is this MZ> considered non-PEPable? I think it /is/ worth a PEP and have assigned #206 to you Moshe. -Barry From bwarsaw@beopen.com Fri Jul 14 04:59:38 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 23:59:38 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: <14702.36906.418249.461209@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I'm currently drawing a list for extensions to include: | -- zlib For sure. | -- Tcl/Tk I've always wanted it in every Python distribution I build, and this one in particular is a pain to add. | -- expat | -- PIL | -- Anything else? readline. My fear is that these extension modules might end up like pcre though. We start with the standard stuff and then start to slowly fork it as we find we need extras. Then we're stuck maintaining our version separately and folding in patches as the original moves forward. Yuck. Does distutils come to the rescue here? Am I being overly paranoid? -Barry From Moshe Zadka Fri Jul 14 05:05:05 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 07:05:05 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14702.36906.418249.461209@anthem.concentric.net> Message-ID: On Thu, 13 Jul 2000, Barry A. Warsaw wrote: [about libraries to distribute with Python] > | -- Anything else? > > readline. -1 on that. I just thought of that before I got out of bed, and decided putting something GPLed there might be trouble. > My fear is that these extension modules might end up like pcre > though. We start with the standard stuff and then start to slowly > fork it as we find we need extras. Then we're stuck maintaining our > version separately and folding in patches as the original moves > forward. Yuck. Well, we managed writing Tcl/Tk wrappers without changing Tcl/Tk. Why should it be different if it's in the source distribution? The temptation? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From bwarsaw@beopen.com Fri Jul 14 05:06:43 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 14 Jul 2000 00:06:43 -0400 (EDT) Subject: [Python-Dev] [PEP204] Range Literals References: <20000713235356.X7340@xs4all.nl> Message-ID: <14702.37331.302346.67441@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> As I already wrote Barry, I'll do this one -- but only if it's TW> a no-brainer. The patch is already written and I hadn't heard TW> complaints about the syntax, but now I hear some rumbling TW> about how it should be a generator instead of a list TW> constructor. I don't feel like digging into that particular TW> dungball, though, having no experience what so ever with TW> iterators, generators or languages that implement those. (So TW> I'm a C and Python programmar by heart. Sue me.) TW> That isn't to say I think it's a bad idea, not at all. I just TW> don't want to do it :-) But if anyone else wants to implement TW> it, and do so before 2.0, yell now, and you can take over the TW> entire range-literal thing as well. Thomas, it would be wonderful if you could write up what you already know about range literals. Feel free to sprinkle `TBD's (to be done, or to be decided) in places you're uncomfortable about. We'll worry about filling those in or re-assigning later. -Barry P.S. I'd rather use TBD than XXX as is the Dutch convention. The USA is much more prudish than the Europeans, and I'd hate for our PEPs to get blocked from all those Python 8 year olds accessing our documents from the public libraries. :) From bwarsaw@beopen.com Fri Jul 14 05:09:48 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 14 Jul 2000 00:09:48 -0400 (EDT) Subject: [Python-Dev] [PEP204] Range Literals References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> <396E4747.9D055A96@prescod.net> Message-ID: <14702.37516.832386.689911@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Why disallow this: PP> fives=[0:maxint:5] PP> As Fred points out, we've already got the underlying object PP> implementation in the src! PP> MAL also pointed out that immutable objects (like xranges) can PP> be safely precomputed and reused. PP> Finally, whatever the answer is, it should probably be the PP> same as list comprehensions. This is why you want a PEP, Paul! -Barry From bwarsaw@beopen.com Fri Jul 14 05:37:27 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 14 Jul 2000 00:37:27 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <14702.36906.418249.461209@anthem.concentric.net> Message-ID: <14702.39175.2260.890343@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> -1 on that. I just thought of that before I got out of bed, MZ> and decided putting something GPLed there might be trouble. Ah, good point. I keep forgetting about that :) -Barry From paul@prescod.net Fri Jul 14 05:06:52 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 23:06:52 -0500 Subject: [Python-Dev] Request for Opinions Message-ID: <396E91DC.D767EF6F@prescod.net> I don't want to PEP this, I want to discuss it. In fact, I think we are supposed to discuss it four more times before I PEP it. And Tim has to participate in each discussion, right? There is a language called "XPath" for navigating XML trees. It makes your life a lot easier. XPath is to XML trees as SQL is to relational databases. Imagine working with relational databases by looping over records with no query language! I think that some portion of XPath should go into Python 2. 4Thought has a large, sophisticated implementation of the entire XPath language. They use Bison (not PyBison!) and FLEX for parsing performance. I guess there is about 2000 lines of C/yacc. The resulting binary is XXX. There is also about 2000 lines of Python code. On the one hand, this strikes me as a lot of code for one subpackage (xpath) of a package (xml). On the other hand, XPath is pretty stable so once the code is done, it is pretty stable and also self contained. It wasn't something we invented and will be tweaking forever. Rather it is a simple API to something relatively static. (XPath has extension mechanisms so it can solve new problems without growing syntactically) Is this an appropriate extension to Python, like pyexpat? We have three options: 1. use the relatively large 4XPath as is 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) that can be implemented in a couple of hundred lines of Python code (this code is mostly done already, in a module called TinyXPath) 3. try to scale 4XPath back by moving its parser to SRE, and making some of its features "options" that can be added separately (not clear how easy this is) What do you think? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov@inrialpes.fr Fri Jul 14 05:47:43 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 14 Jul 2000 06:47:43 +0200 (CEST) Subject: [Python-Dev] test_extcall Message-ID: <200007140447.GAA28593@python.inrialpes.fr> test_extcall.py contains the following code generating a cycle that cannot be broken explicitely: ... # what about willful misconduct? def saboteur(**kw): kw['x'] = locals() <-- yields cyclic kw: {'x': {'kw': {...}}, 'a': 1} d = {} saboteur(a=1, **d) ... Whoever wrote this test: is locals() absolutely necessary? Also, is there a good reason for not implementing GC for module objects? They are containers after all... -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov@inrialpes.fr Fri Jul 14 06:16:32 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 14 Jul 2000 07:16:32 +0200 (CEST) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396E91DC.D767EF6F@prescod.net> from "Paul Prescod" at Jul 13, 2000 11:06:52 PM Message-ID: <200007140516.HAA28633@python.inrialpes.fr> Paul Prescod wrote: > > We have three options: > > 1. use the relatively large 4XPath as is > > 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) > that can be implemented in a couple of hundred lines of Python code > (this code is mostly done already, in a module called TinyXPath) > > 3. try to scale 4XPath back by moving its parser to SRE, and making > some of its features "options" that can be added separately (not clear > how easy this is) > > What do you think? Well, I think that the code you're talking about fits best the 4Suite and, for the moment, as a user I would download and install the whole suite from FourThought. You're talking about XPath, but there are also XLink, XPointer, XML Base and other incoming X'es. What's the motivation behind decoupling 4XPath from the 4Suite and making a second (eventually smaller) version of it for the Python lib? I don't really see the point (note: I haven't followed the XML-SIG lately). I'd like to see this discussion focusing on more ambitious goals, like including and providing support for a complete, rich and up to date XML package, which is what the 4Suite basically is. I'm not sure we're ready to discuss this right now, though, so I'd suggest to PEP it anyway. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Mark.Favas@per.dem.csiro.au Fri Jul 14 06:18:42 2000 From: Mark.Favas@per.dem.csiro.au (Favas, Mark (EM, Floreat)) Date: Fri, 14 Jul 2000 13:18:42 +0800 Subject: [Python-Dev] FW: Unicode character name hashing Message-ID: Forgot to copy Python-Dev... -----Original Message----- From: Mark Favas [mailto:m.favas@per.dem.csiro.au] Sent: Friday, 14 July 2000 7:00 AM To: Bill Tutt Subject: Re: Unicode character name hashing Just tried it, and got the same message: test_ucn test test_ucn crashed -- exceptions.UnicodeError : Unicode-Escape decoding error: Invalid Unicode Character Name Cheers, Mark Bill Tutt wrote: > > Does this patch happen to fix it? > I'm afraid my skills relating to signed overflow is a bit rusty... :( > > Bill > > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/ucnhash.c,v > retrieving revision 1.2 > diff -u -r1.2 ucnhash.c > --- ucnhash.c 2000/06/29 00:06:39 1.2 > +++ ucnhash.c 2000/07/13 21:41:07 > @@ -30,12 +30,12 @@ > > len = cch; > p = (unsigned char *) key; > - x = 1694245428; > + x = (long)0x64fc2234; > while (--len >= 0) > - x = (1000003*x) ^ toupper(*(p++)); > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); > x ^= cch + 10; > - if (x == -1) > - x = -2; > + if (x == (long)0xFFFFFFFF) > + x = (long)0xfffffffe; > x %= k_cHashElements; > /* ensure the returned value is positive so we mimic Python's % > operator */ > if (x < 0) > @@ -52,12 +52,12 @@ > > len = cch; > p = (unsigned char *) key; > - x = -1917331657; > + x = (long)0x8db7d737; > while (--len >= 0) > - x = (1000003*x) ^ toupper(*(p++)); > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); > x ^= cch + 10; > - if (x == -1) > - x = -2; > + if (x == (long)0xFFFFFFFF) > + x = (long)0xfffffffe; > x %= k_cHashElements; > /* ensure the returned value is positive so we mimic Python's % > operator */ > if (x < 0) > > -----Original Message----- > From: Mark Favas [mailto:m.favas@per.dem.csiro.au] > Sent: Thursday, July 13, 2000 1:16 PM > To: python-dev@python.org; Bill Tutt > Subject: Unicode character name hashing > > [Bill has epiphany] > >I just had a rather unhappy epiphany this morning. > >F1, and f2 in ucnhash.c might not work on machines where sizeof(long) >!= > 32 bits. > > I get the following from test_ucn on an Alpha running Tru64 Unix: > > python Lib/test/test_ucn.py > UnicodeError: Unicode-Escape decoding error: Invalid Unicode Character > Name > > This is with the current CVS - and it's been failing this test for some > time now. I'm happy to test any fixes... > > -- > Email - m.favas@per.dem.csiro.au Mark C Favas > Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining > Fax - +61 8 9383 9891 Private Bag No 5, Wembley > WGS84 - 31.95 S, 115.80 E Western Australia 6913 -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From huaiyu_zhu@yahoo.com Fri Jul 14 06:53:38 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Thu, 13 Jul 2000 22:53:38 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <396E4768.A77473AA@prescod.net> Message-ID: On Thu, 13 Jul 2000, Paul Prescod wrote: > It all depends on who works on it and how hard they work. I really can't So can some one answer this question for sure: Is it definitely possible to introduce .* ./ etc without much more difficulty than introducing @* and @/ and so on? If this is the case we do not need a new symbol. > Perhaps the best bet would be for you to make a matrix variant of Python > so popular that we could see the audience in terms of downloads and > discussions. That's exact what I'm doing. By far the largest hurdle to MatPy was the lack of binary operators. 2/3 of user discussions is on the the most economic usage of existing symbols. 1/3 of discussion is on how to make it work on Windows, because of relative imports and case insensitivity. To attract users I really need to let octave users know its existence, but this would be futile before we get symbols for both matrix and element operations. Here are a few indications of user support. Some Windows users have enthusiastically followed it for more than a month despite having to rename several files and change module names for each release. It was only fixed last weekend. I'd regard this as a testament of its usefulness and potential. People have also hacked the python parser and the interactive interpreter to support additional features. Some have also promised to supply additional C implementations of numerical procedures. All I had promised for this was to make an easy interface for matrix computation that works with Python, for my own use. Right now the only remaining hurdle to this goal is the lack of suitable symbols, and we are on the verge of overcoming it. > There must be a more compact syntax! Even without knowing the semantics: > > from matrix import tickmult, backslash > backslash( tickmult( X, X ), tickmult( X, y )) You are almost there. :-) The current MatPy expression is solve (X.H() * X, X.H() * y) > > Now look at the total number of users of matlab/octave, and ask: Is python > > really so inferior that most of them wouldn't switch to python? > > I have no idea. If the primary difference between expensive matrix > packages and Python is syntax, perhaps you and I should incorporate and > exploit that market inefficiency. :) The market is efficient. Matlab does worth that much (or even more). It does take that much human labor to get to that stage, so sadly we can't get rich by following them. On the other hand, open source may beat them easily, as long as 1. we are using a better language which has more potential 2. users have incentive to contribute because it's already useful 3. there's no big hurdle beyond what's already in Numerical Recipe I'm sure I can recruit enough developers to solve any numerical problem, as long as you don't ask them to hack the python parser! That's what I ask the python developers for. > Michael Hudson has a tagline that made me laugh out loud: > > I saw `cout' being shifted "Hello world" times to the left and > stopped right there. > -- Steve Gonedes If this was a notation used in a century's worth of mathemetical papers, it might not seem that strange. Could C++ stream IO ever make into just one mainstream math paper? > How long until some enterprising Python programmer makes a utility that > polls the website, and generates an email version of each message as it > appears? :) The same length of time that takes an enterprising Python programmer to find the principal axes of a set of data using eigen decomposition. :-) think-domain-specific-ly y'rs Huaiyu From tim_one@email.msn.com Fri Jul 14 07:15:27 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 14 Jul 2000 02:15:27 -0400 Subject: [Python-Dev] Windows build broken in exceptions.c In-Reply-To: <00c401bfebd9$e6d347e0$f2a6b5d4@hagrid> Message-ID: >> exceptions.c(93) : error C2026: string too big, trailing characters >> truncated [Fredrik Lundh Sent: Wednesday, July 12, 2000 4:19 AM] > but back to the original topic: what does the ANSI standard > say about this? A conforming C compiler isn't required to accept string literals longer than 509 characters (and that's *after* concatenating adjacent strings). An excellent summary (although not a rationale) can be found here: http://www-ccs.ucsd.edu/c/portable.html Read it carefully, and my bet is you'll realize you've never seen a portable C program! For example, ever #include a file whose basename was longer than 6 characters or used mixed case? Then you're in the unsupported fast lane . > what is, for example, the limits for integer arrays? There are (small!) limits both on physical source lines and on the size of initialized objects. See the above and *you* try to figure it out . > (my unicode database experiments results in a couple of big > ones. and for best performance, they really have to be that > big...) The std guarantees only the feeblest of compile-time abilities, so you're (the generic "you", i.e. "us") very unlikely to write this stuff in a way the std guarantees will work. But it's not worth worrying about (within reason), until we hit an actual compiler that complains. The only way to be completely sure is to stick to tiny compile-time entities and paste them together at runtime. and-even-then-it's-not-really-sure-ly y'rs - tim From mwh21@cam.ac.uk Fri Jul 14 07:21:13 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 14 Jul 2000 07:21:13 +0100 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: bwarsaw@beopen.com's message of "Fri, 14 Jul 2000 00:37:27 -0400 (EDT)" References: <14702.36906.418249.461209@anthem.concentric.net> <14702.39175.2260.890343@anthem.concentric.net> Message-ID: bwarsaw@beopen.com (Barry A. Warsaw) writes: > >>>>> "MZ" == Moshe Zadka writes: > > MZ> -1 on that. I just thought of that before I got out of bed, > MZ> and decided putting something GPLed there might be trouble. > > Ah, good point. I keep forgetting about that :) It's been one of those things that "I will get round to sometime" for a long while now to write a (PD) replacement line editor in Python (thinking partly that it would be nice not to be "encumbered" by the GPL and that if it was written in a suitable style it might be possible to make it more "hookable" and provide eg. fancier completion). Unfortunately I know nothing about any of the issues involved, so I'd have to do a lot of reading first... Anyone else think this is a good idea/crazy? Cheers, M. From Mark.Favas@per.dem.csiro.au Fri Jul 14 07:30:13 2000 From: Mark.Favas@per.dem.csiro.au (Favas, Mark (EM, Floreat)) Date: Fri, 14 Jul 2000 14:30:13 +0800 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators for matrix comput ation] Message-ID: Speaking as a research scientist with my computational chemistry/visualization hat down around my ears, I'd certainly welcome such operators, as would a couple of my colleagues to whom I introduced Python. One was a heavy user of Sather until the steam went out of it, then C++ for a time, now Python+NumPy - and loving it! A set of matrix operators would expand Python's sphere of use - scientists process numbers as well as text... From fdrake@beopen.com Fri Jul 14 07:52:28 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 02:52:28 -0400 (EDT) Subject: [Python-Dev] ConfigParser changes In-Reply-To: <200007140246.WAA07574@snark.thyrsus.com> References: <200007140246.WAA07574@snark.thyrsus.com> Message-ID: <14702.47276.262761.585951@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > I've seen a couple plus responses to my proposed ConfigParser > enhancements, no minuses, and the thread has petered out. I don't see the patch on SourceForge, so go ahead and check them in. I think everyone agrees that the basic functionality is useful, and has been requested before. +1 from me. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein@lyra.org Fri Jul 14 08:15:39 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 00:15:39 -0700 Subject: [Python-Dev] Request for Opinions In-Reply-To: <396E91DC.D767EF6F@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 11:06:52PM -0500 References: <396E91DC.D767EF6F@prescod.net> Message-ID: <20000714001539.T29590@lyra.org> On Thu, Jul 13, 2000 at 11:06:52PM -0500, Paul Prescod wrote: >... > We have three options: > > 1. use the relatively large 4XPath as is > > 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) > that can be implemented in a couple of hundred lines of Python code > (this code is mostly done already, in a module called TinyXPath) > > 3. try to scale 4XPath back by moving its parser to SRE, and making > some of its features "options" that can be added separately (not clear > how easy this is) > > What do you think? I think this is for the XML SIG. I don't know why it is here. SIGs discuss and design, then roll up their final decisions. I haven't seen a clear consensus or decision from the XML SIG yet. You've got your TinyXPath module, but (forget who) has another module for much the same thing. There was a discussion of APIs. A discussion of how/where SRE could play into the game. IMO, these are all a bunch of points for the XML SIG, not python-dev. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Moshe Zadka Fri Jul 14 08:13:46 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 10:13:46 +0300 (IDT) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396E91DC.D767EF6F@prescod.net> Message-ID: On Thu, 13 Jul 2000, Paul Prescod wrote: > There is a language called "XPath" for navigating XML trees. It makes > your life a lot easier. XPath is to XML trees as SQL is to relational > databases. Imagine working with relational databases by looping over > records with no query language! I think that some portion of XPath > should go into Python 2. I agree -- XPath would be cool to work with. > 4Thought has a large, sophisticated implementation of the entire XPath > language. They use Bison (not PyBison!) and FLEX for parsing > performance. The output of Bison is covered by the GPL, and flex requires a runtime library. We want a rich Python, but there's no reason for a billionaire > 1. use the relatively large 4XPath as is This seems to have a significant cost for the Python distribution > 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) > that can be implemented in a couple of hundred lines of Python code > (this code is mostly done already, in a module called TinyXPath) +0 on that. > 3. try to scale 4XPath back by moving its parser to SRE, and making > some of its features "options" that can be added separately (not clear > how easy this is) If you think someone will do this, this is great. If not, there isn't much point in discussing it, is there? <0.9 wink> -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gstein@lyra.org Fri Jul 14 08:19:37 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 00:19:37 -0700 Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: ; from Mark.Favas@per.dem.csiro.au on Fri, Jul 14, 2000 at 02:30:13PM +0800 References: Message-ID: <20000714001937.U29590@lyra.org> On Fri, Jul 14, 2000 at 02:30:13PM +0800, Favas, Mark (EM, Floreat) wrote: > Speaking as a research scientist with my computational > chemistry/visualization hat down around my ears, I'd certainly welcome such > operators, as would a couple of my colleagues to whom I introduced Python. > One was a heavy user of Sather until the steam went out of it, then C++ for > a time, now Python+NumPy - and loving it! A set of matrix operators would > expand Python's sphere of use - scientists process numbers as well as > text... We can always gain new users by adding domain-specific operators. Take that to the extreme, though, and you'll have a mess of complicated operators that don't create a unified whole, that don't work well across various types, and are hard to understand for the majority of users. What then? Well, you *lose* users. Gain the domain-specific, lose the rest. New users are great. Adding complexity to gain them is counter-productive from a longer term viewpoint. Cheers, -g p.s. and allowing user-programmable syntax? you're truly kidding, right? -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Fri Jul 14 08:27:41 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 00:27:41 -0700 Subject: [Python-Dev] Re: CVS: python/dist/src/Misc sf-faq.html,1.2,1.3 In-Reply-To: <200007140622.XAA32744@slayer.i.sourceforge.net>; from marangoz@users.sourceforge.net on Thu, Jul 13, 2000 at 11:22:57PM -0700 References: <200007140622.XAA32744@slayer.i.sourceforge.net> Message-ID: <20000714002740.V29590@lyra.org> Um. Why did you go and do this? Looking at the original HTML, it appears that Peter was using the Mozilla editor to create the page. With your revamping, will he continue to be able to do that? When he next edits the page, will it just revert back to the original? Did you discuss doing this big change with Peter? We just got done with a discussion about how/where people should feel free to make changes and what kinds of changes. Something drastic like this should have at least been run by the author. Otherwise, it is a bit disrespectful. In this case, it may also break his continued maintenance of it (need to check w/ Peter tho). -g On Thu, Jul 13, 2000 at 11:22:57PM -0700, Vladimir Marangozov wrote: > Update of /cvsroot/python/python/dist/src/Misc > In directory slayer.i.sourceforge.net:/tmp/cvs-serv32383 > > Modified Files: > sf-faq.html > Log Message: > Gosh - clean up that messy HTML; make it valid XHTML instead. > > > Index: sf-faq.html > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Misc/sf-faq.html,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -C2 -r1.2 -r1.3 > *** sf-faq.html 2000/07/14 01:43:31 1.2 > --- sf-faq.html 2000/07/14 06:22:54 1.3 > *************** > *** 1,406 **** > ! > ! > > ! > ! > ... > ! > ! ! "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > ! > > ! Python at SourceForge - Frequently Asked Questions > ! > -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov@inrialpes.fr Fri Jul 14 08:36:06 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 14 Jul 2000 09:36:06 +0200 (CEST) Subject: [Python-Dev] Re: http://python.sourceforge.net In-Reply-To: <396E884C.B55E4737@schneider-kamp.de> from "Peter Schneider-Kamp" at Jul 14, 2000 03:26:04 AM Message-ID: <200007140736.JAA29096@python.inrialpes.fr> Peter Schneider-Kamp wrote: > > Hi Greg! > > I made a small link page (to python.org, sourceforge.net/projects/python > and sf-faq.html) and loaded it up together with the faq (sf-faq.html). > > Anyone with a bit more feeling for design than me should feel free to > improve it. Thanks! You'd have to chmod g+w the new files first, though. I can't Mr Proper them. In a moment of great annoyance I'll also try to enhance the pages. BTW, please make a HTML Tidy pass (http://www.w3.org/People/Raggett/tidy/) over the HTML files, at least, if they're edited with your favorite editor. Or you may want to use Amaya for editing HTML (http://www.w3.org/Amaya/) but it still core dumps from time to time . It's improving though... -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas@xs4all.net Fri Jul 14 08:44:12 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 09:44:12 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: ; from huaiyu_zhu@yahoo.com on Thu, Jul 13, 2000 at 10:53:38PM -0700 References: <396E4768.A77473AA@prescod.net> Message-ID: <20000714094412.Z7340@xs4all.nl> On Thu, Jul 13, 2000 at 10:53:38PM -0700, Huaiyu Zhu wrote: > On Thu, 13 Jul 2000, Paul Prescod wrote: > > It all depends on who works on it and how hard they work. I really can't > So can some one answer this question for sure: > Is it definitely possible to introduce .* ./ etc without much more > difficulty than introducing @* and @/ and so on? No, I don't think it's possible without significantly restructuring the Grammar. However, Vladimir may prove me wrong, he has before ! :-) The problem is the recursive-descent parser Python is using, I don't think it can see the difference between 2. / 2 and 2 ./ 2 or a. / b and a ./ b Because the dot is already a pretty overloaded character: it does float-creation, rendering the first example ambiguous, and it does attribute-lookup, rendering the second ambiguous. However, I haven't tried it, it might be possible to make it work even with the current parser. > If this is the case we do not need a new symbol. Actually, you do need a new symbol, several in fact. You don't need to introduce a new *character*, but you get several new symbols: ./, .*, etc. I'm not sure if using the dot for this, too, is such a good idea, even if it's possible: yet another possible meaning for '.' ? I think using '@' is preferable. At least non-matrix people will know when to run screaming, when they see that ! :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov@inrialpes.fr Fri Jul 14 08:49:17 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 14 Jul 2000 09:49:17 +0200 (CEST) Subject: [Python-Dev] Re: CVS: python/dist/src/Misc sf-faq.html,1.2,1.3 In-Reply-To: <20000714002740.V29590@lyra.org> from "Greg Stein" at Jul 14, 2000 12:27:41 AM Message-ID: <200007140749.JAA29121@python.inrialpes.fr> Greg Stein wrote: > > Um. Why did you go and do this? Looking at the original HTML, it appears > that Peter was using the Mozilla editor to create the page. With your > revamping, will he continue to be able to do that? When he next edits the > page, will it just revert back to the original? This shouldn't be a problem for Peter. He can revert that with the editor of his choice; if its not conformant to the standards, I'll clean the files occasionally if you don't mind. Sorry for being sensible on this topic, working next to the W3C people and being an INRIA webmaster. I'm just trying to give the example about the culture. Unfortunately, I must reckon that the tools are following slowly, but everybody will jump in sooner or later... -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas@xs4all.net Fri Jul 14 08:46:18 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 09:46:18 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <396E4768.A77473AA@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 05:49:12PM -0500 References: <396E4768.A77473AA@prescod.net> Message-ID: <20000714094618.A7340@xs4all.nl> On Thu, Jul 13, 2000 at 05:49:12PM -0500, Paul Prescod wrote: > Huaiyu Zhu wrote: > > But I can see its use now. I have to get your reply from web and cut and > > paste in order to reply again. :-( > How long until some enterprising Python programmer makes a utility that > polls the website, and generates an email version of each message as it > appears? :) You can already download the email version: the archives in mbox format. You'll have to download the entire month of conversation, possibly again and again if you're following a running converstation, and you'll lose the threading information (In-Reply-To: headers) but 'reply' should work fine. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein@lyra.org Fri Jul 14 09:02:20 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 01:02:20 -0700 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <20000714094412.Z7340@xs4all.nl>; from thomas@xs4all.net on Fri, Jul 14, 2000 at 09:44:12AM +0200 References: <396E4768.A77473AA@prescod.net> <20000714094412.Z7340@xs4all.nl> Message-ID: <20000714010220.Y29590@lyra.org> On Fri, Jul 14, 2000 at 09:44:12AM +0200, Thomas Wouters wrote: > On Thu, Jul 13, 2000 at 10:53:38PM -0700, Huaiyu Zhu wrote: > > On Thu, 13 Jul 2000, Paul Prescod wrote: > > > > It all depends on who works on it and how hard they work. I really can't > > > So can some one answer this question for sure: > > > Is it definitely possible to introduce .* ./ etc without much more > > difficulty than introducing @* and @/ and so on? > > No, I don't think it's possible without significantly restructuring the > Grammar. However, Vladimir may prove me wrong, he has before ! :-) The > problem is the recursive-descent parser Python is using, I don't think it > can see the difference between The issue isn't with recursive-descent, and this would be a relatively easy change. You would introduce a new token "./" to accomplish this (call it DOTSLASH). Thus, . / maps to (DOT, SLASH,) while ./ maps to (DOTSLASH,). Python already does this to differentiate between < and <<. Most languages do, actually. What is really weird is that Python sees the ellipsis value/operator/ whatever-the-heck-it-is as three individual DOT tokens rather than a single token. Thus, the following two statements are equal: a[...] a[. . .] Whacky :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one@email.msn.com Fri Jul 14 09:06:42 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 14 Jul 2000 04:06:42 -0400 Subject: Copyright & licenses (was RE: [Python-Dev] Python Enhancement Proposals (PEPs)) In-Reply-To: <14702.19369.605446.28207@cj42289-a.reston1.va.home.com> Message-ID: [Greg Stein] > Why must we assert copyrights on these things? Come on, people. Aren't > we seeing Python 2.0 release problems because of copyrights? [Fred L. Drake, Jr.] > No. *Licensing* is distinct from copyright, and that's where we see > problems. The question of who is to be the next copyright holder will become a bone of contention too before this is over, don't you think? What to do with all the current copyright notices is already a point of negotiation (e.g., should CWI really have a notice in files that didn't even exist yet under their tenure? etc. Note that when I added pyport.h to the project, I put in only a BeOpen copyright: *someone* is bound to gripe about that too, provided I ever admit to it in public ). I personally would like to get Python out of the copyright *and* license games forever, by releasing Python to the public domain (as, e.g., Ralph Griswold did with the Icon language from the start -- and enjoyed a hassle-free life ever after; yes, at least one closed-source copyrighted commercial version of Icon did appear, but that was no skin off Prof. Griswold's nose; he kept working on the PD one, and the commercial version eventually gave up -- heck, rather than see their work wasted, they contributed most of what they did back to the PD Icon Project!). I don't believe there's any real downside to PD in America so long as you're not afraid to compete on merit alone. Don't know about international law, though. > The copyrights are indisputable, but are not a problem. Pshaw -- everything's disputable . and-everything's-a-problem-ly y'rs - tim From tim_one@email.msn.com Fri Jul 14 09:06:44 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 14 Jul 2000 04:06:44 -0400 Subject: [Python-Dev] Request for Opinions In-Reply-To: <396E91DC.D767EF6F@prescod.net> Message-ID: [Paul Prescod] > I don't want to PEP this, I want to discuss it. In fact, I think we are > supposed to discuss it four more times before I PEP it. And Tim has to > participate in each discussion, right? No to the latter. I read everything. That's why I never have time to respond anymore <0.5 wink>. Discussions are great! Just be aware that if the discussion doesn't flow directly to a patch that's applied to the distribution, and you're still keen on the idea, without a PEP it will be *worse* for you than if the discussion had never occurred. That's because the people who *did* read the discussion the first time around are exponentially less likely to say anything (or even pay attention!) on each of the next 500 times the topic pops up again. So if this discussion doesn't reach a conclusion you like, PEP it or you may as well forget it forever (well, maybe not that long -- augmented assignments appear to be getting in after a mere 9 years of thrice-yearly strident from-scratch endlessly redundant advocacy ). From fredrik@pythonware.com Fri Jul 14 09:21:46 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 10:21:46 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <010401bfed6c$8d905300$0900a8c0@SPIFF> Huaiyu Zhu wrote: > Look it this way. Text processing do have their special syntaxes. what special syntax? regular expressions are a *sublanguage* in Python. everything else is done through methods and ordinary sequence operators. From peter@schneider-kamp.de Fri Jul 14 11:44:40 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 14 Jul 2000 10:44:40 +0000 Subject: [Python-Dev] Re: http://python.sourceforge.net References: <200007140736.JAA29096@python.inrialpes.fr> Message-ID: <396EEF18.163475CD@schneider-kamp.de> Vladimir Marangozov wrote: > > Thanks! You'd have to chmod g+w the new files first, though. > I can't Mr Proper them. In a moment of great annoyance I'll > also try to enhance the pages. Done that. > BTW, please make a HTML Tidy pass (http://www.w3.org/People/Raggett/tidy/) > over the HTML files, at least, if they're edited with your favorite editor. Ok, I did. Unfortunately before reading the checkins ... > Or you may want to use Amaya for editing HTML (http://www.w3.org/Amaya/) > but it still core dumps from time to time . It's improving though... Is that what you used for sf-faq.html? There is one thing I don't like about all this xml*, meta and other special tags. I used to write .html files with my favorite text editor: my little home page

My Little Home Page

Here goes the content. With XHTML I'll probably end up with something like this: my little home page

My Little Home Page

Here goes the content. Talk about readability and maintainability. I know the header is worst, but the generated sources (from Page Composer, Frontpage, Amaya or your favorite tool) are always a pain in the ass if it comes to reading them. And yes, I am one of those who used to do their html in . compiling-amaya-though-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gstein@lyra.org Fri Jul 14 09:51:17 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 01:51:17 -0700 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <396E0B9B.DD74EF5@interet.com>; from jim@interet.com on Thu, Jul 13, 2000 at 02:34:03PM -0400 References: <396E0B9B.DD74EF5@interet.com> Message-ID: <20000714015117.C29590@lyra.org> On Thu, Jul 13, 2000 at 02:34:03PM -0400, James C. Ahlstrom wrote: > Mark Hammond wrote: >... > I guess I haven't made myself clear. I am not proposing > that we freeze the C interface. I am not proposing that we > scrutinize any *.pyd's for incompatabilities. > > I am proposing that we leave the "python15.dll" name the same. > I am proposing that the various *.pyd authors themselves either > provide newer versions, or declare that their *.pyd needs no > newer version of python15.dll. As a .pyd part-time author, I'm going to punt *every* time and suggest people upgrade. I don't have time or inclination to piss around to figure out whether my PYD is compatible forwards/backwards across revisions. > It is a matter of odds. If we necessarily rename python15.dll > for each version release, Python has a 100% chance of failing > with an obscure error or crashing if it uses any *.pyd at all > unless all *.pyd are replaced with new versions. > > If we do not rename python15.dll, then a *.pyd may or may not > fail. My guess (only a guess) is that many will work OK. This is completely untenable. *) change the python DLL name failure mode: old modules simply won't load, or they'll fail drastically *) don't change the name failure mode: old modules may work, may have *subtle* bugs, or they may fail miserably As a user, I want complete guaranteed success or guaranteed failure. That half-way ground where my application may silently be broken is simply unacceptable. You're free to start creating releases in this way. Personally, I don't want to spend this kind of time and effort, for dubious benefit. I'm also not going to try to impose that upon PYD authors. And yes: this is all just IMO. One more vote in the crowd.. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gregory.lielens@fft.be Fri Jul 14 10:57:37 2000 From: gregory.lielens@fft.be (Gregory Lielens) Date: Fri, 14 Jul 2000 11:57:37 +0200 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators formatrix computation] References: <396DFDC5.6780A710@prescod.net> Message-ID: <396EE411.B3CB33A9@fft.be> Paul Prescod wrote: > > Huaiyu Zhu wrote: > > > > ... > > > > I wonder how orthogonal would this be against the main development? Would > > it require a rebuild for each new release. Would it also require a patch > > each time? > > I think that the idea is that you could install new syntaxes in the same > way you install new modules...of course only after careful > consideration!!! It seems potentially more dangerous than statically adding a new operator, no? If two modules install incompatible changes of syntax, for exmaple if they demand both @ as operator, they will be considered as incompatible? On the other hand, if @ is buil-in, it can be overloaded depending on the type of the operands, which seems safer...I am not sure, but it seems that if syntax is module-dependent, things becomes really complex... > > Look it this way. Text processing do have their special syntaxes. > > Okay, but probably 90% of Python programmers do text processing at some > point. Not so for matrix calculation. You believe that the Python world > would grow greatly if we did matrices natively. I don't know if I > believe that. Well, that kind of change could potentially attract all the numeric community...which is probably a minority (and becoming smaller, based on the evolution of the number of science students in belgium) compared to the rest of the comp world, but still a significant minority. At least, it will attract one person for sure: me :-) Anyway, it seems that that audience (numeric people) was targeted by python since the beginning, because why the hell include complex numbers as built-in type if not? They are of a less general usefullness than matrices, imho, the last can at least be used for graphic stuff... Greg. From ping@lfw.org Fri Jul 14 11:09:10 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Fri, 14 Jul 2000 03:09:10 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: Message-ID: On Thu, 13 Jul 2000, Huaiyu Zhu wrote: > > You are almost there. :-) The current MatPy expression is > solve (X.H() * X, X.H() * y) I was about to suggest something similar, but you beat me to it. I think that expression looks great. If you can say it that concisely, i don't think you need to throw in extra operators at all (let alone a half-dozen of them that are incomprehensible to anyone outside of the Matlab community). I actually believe solve(X.H()*X, X.H()*y) is *clearer* than (X'*X)\(X'*y) (What does the backslash mean? What does the tick mark mean? At least solve() is clear, and if i understood what H() stood for, it would mean more than a tick mark.) -- ?!ng From m.favas@per.dem.csiro.au Fri Jul 14 11:55:44 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Fri, 14 Jul 2000 18:55:44 +0800 Subject: [Python-Dev] Introducing new operators for matrix computation Message-ID: <396EF1B0.8CB53FD3@per.dem.csiro.au> Greg Stein wrote: >New users are great. Adding complexity to gain them is >counter-productive from a longer term viewpoint. > >Cheers, >-g > >p.s. and allowing user-programmable syntax? you're truly kidding, >right? The p.s. is one of the reasons I support putting useful matrix operators into the core - user-programmable syntax will only lead to even more complexity/confusion/fragmentation, and should be resisted strongly... -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From Fredrik Lundh" Message-ID: <009501bfed89$e415ce40$f2a6b5d4@hagrid> moshe wrote: > > # normal case > > for (x,) in zip([0, 1, 2]): > > ... > >=20 > > # special case > > for x in zip([0, 1, 2]): > > ... > > I'm sorry, I don't buy that. >=20 > # "special case" > for x in [0, 1, 2]: > ... >=20 > # "special case" > do_something_that_requires_a_list_of_tuples(zip(*lists)) we sure have a major disconnect here -- wasn't the source of this discussion the need to be able to loop over multiple sequences in parallel? isn't "for" what you'd usually use when looping over things? From billtut@microsoft.com Fri Jul 14 13:30:35 2000 From: billtut@microsoft.com (Bill Tutt) Date: Fri, 14 Jul 2000 05:30:35 -0700 Subject: [Python-Dev] RE: Unicode character name hashing Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2D5@RED-MSG-50> After making use of the test drive Alphas by Compaq, I just uploaded a patch to SF that should fix this nasty issue. Ugh. Not fun.... If anybody else cares about identical string hash values across 32 v. 64 bit architectures, check out the patch. Bill -----Original Message----- From: Mark Favas [mailto:m.favas@per.dem.csiro.au] Sent: Thursday, July 13, 2000 4:00 PM To: Bill Tutt Subject: Re: Unicode character name hashing Just tried it, and got the same message: test_ucn test test_ucn crashed -- exceptions.UnicodeError : Unicode-Escape decoding error: Invalid Unicode Character Name Cheers, Mark Bill Tutt wrote: > > Does this patch happen to fix it? > I'm afraid my skills relating to signed overflow is a bit rusty... :( > > Bill > > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/ucnhash.c,v > retrieving revision 1.2 > diff -u -r1.2 ucnhash.c > --- ucnhash.c 2000/06/29 00:06:39 1.2 > +++ ucnhash.c 2000/07/13 21:41:07 > @@ -30,12 +30,12 @@ > > len = cch; > p = (unsigned char *) key; > - x = 1694245428; > + x = (long)0x64fc2234; > while (--len >= 0) > - x = (1000003*x) ^ toupper(*(p++)); > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); > x ^= cch + 10; > - if (x == -1) > - x = -2; > + if (x == (long)0xFFFFFFFF) > + x = (long)0xfffffffe; > x %= k_cHashElements; > /* ensure the returned value is positive so we mimic Python's % > operator */ > if (x < 0) > @@ -52,12 +52,12 @@ > > len = cch; > p = (unsigned char *) key; > - x = -1917331657; > + x = (long)0x8db7d737; > while (--len >= 0) > - x = (1000003*x) ^ toupper(*(p++)); > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); > x ^= cch + 10; > - if (x == -1) > - x = -2; > + if (x == (long)0xFFFFFFFF) > + x = (long)0xfffffffe; > x %= k_cHashElements; > /* ensure the returned value is positive so we mimic Python's % > operator */ > if (x < 0) > > -----Original Message----- > From: Mark Favas [mailto:m.favas@per.dem.csiro.au] > Sent: Thursday, July 13, 2000 1:16 PM > To: python-dev@python.org; Bill Tutt > Subject: Unicode character name hashing > > [Bill has epiphany] > >I just had a rather unhappy epiphany this morning. > >F1, and f2 in ucnhash.c might not work on machines where sizeof(long) >!= > 32 bits. > > I get the following from test_ucn on an Alpha running Tru64 Unix: > > python Lib/test/test_ucn.py > UnicodeError: Unicode-Escape decoding error: Invalid Unicode Character > Name > > This is with the current CVS - and it's been failing this test for some > time now. I'm happy to test any fixes... > > -- > Email - m.favas@per.dem.csiro.au Mark C Favas > Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining > Fax - +61 8 9383 9891 Private Bag No 5, Wembley > WGS84 - 31.95 S, 115.80 E Western Australia 6913 -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From paul@prescod.net Fri Jul 14 11:07:43 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:07:43 -0500 Subject: [Python-Dev] Request for Opinions References: <200007140516.HAA28633@python.inrialpes.fr> Message-ID: <396EE66F.59D0D45F@prescod.net> Vladimir Marangozov wrote: > >... > > Well, I think that the code you're talking about fits best the 4Suite > and, for the moment, as a user I would download and install the whole suite > from FourThought. Why? 4XPath is entirely separable and compatible with Python's current XML support. > You're talking about XPath, but there are also XLink, XPointer, XML Base > and other incoming X'es. Sure, there are a million XML-world specs. XPath is the one that makes navigating XML trees easy. We've put an XML tree package (miniDOM) in Python 2.0. Therefore XPath is the one that makes our XML tree package easy to navigate. > ... > I'd like to see this discussion focusing on more ambitious goals, like > including and providing support for a complete, rich and up to date XML > package, which is what the 4Suite basically is. Well, it's not very ambitious to propose projects that are already pretty much done! 4Suite is great and its mostly done. Now we're talking about making *Python* more complete. > I'm not sure we're ready > to discuss this right now, though, so I'd suggest to PEP it anyway. Why aren't we ready to dicuss it? -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Fri Jul 14 11:08:51 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:08:51 -0500 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> Message-ID: <396EE6B3.B86BED76@prescod.net> Greg Stein wrote: > > ... > > I think this is for the XML SIG. I don't know why it is here. SIGs discuss > and design, then roll up their final decisions. Okay, so we can agree in the XML SIG that we love XPath and then "check in" 4K of Bison/FLEX/C/Python code without consulting anyone else? I don't see any harm in consulting PythonDev....it's not like every string decision is entirely settled in string-sig and every internationalization feature in il8n-sig. There are also integration issues. Adopting a large package is one such. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From guido@beopen.com Fri Jul 14 15:07:29 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:07:29 -0500 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: Your message of "Fri, 14 Jul 2000 00:06:43 -0400." <14702.37331.302346.67441@anthem.concentric.net> References: <20000713235356.X7340@xs4all.nl> <14702.37331.302346.67441@anthem.concentric.net> Message-ID: <200007141407.JAA12817@cj20424-a.reston1.va.home.com> > P.S. I'd rather use TBD than XXX as is the Dutch convention. The USA > is much more prudish than the Europeans, and I'd hate for our PEPs to > get blocked from all those Python 8 year olds accessing our documents > from the public libraries. :) XXX is not a Dutch invention -- I picked up the habit from the X11 source code base. I believe it's fairly common in open source projects, and there are so many XXX'es throughout Python already that it's better not to try and change. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Fri Jul 14 15:13:29 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:13:29 -0500 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: Your message of "Fri, 14 Jul 2000 00:37:27 -0400." <14702.39175.2260.890343@anthem.concentric.net> References: <14702.36906.418249.461209@anthem.concentric.net> <14702.39175.2260.890343@anthem.concentric.net> Message-ID: <200007141413.JAA12883@cj20424-a.reston1.va.home.com> I just want to make it crystal clear that I'm *against* (that's a -999, only overridable by a bus) inclusion of 3rd party library source code in the Python source distribution. Exceptions can only be made if the particular 3rd party code needs to be modified before it is usable from Python (e.g. some checksum algorithms, and PCRE) or if there is no reasonably accessible distribution available on the web. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Fri Jul 14 15:17:53 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:17:53 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: Your message of "Thu, 13 Jul 2000 19:11:27 -0400." <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> <14702.19480.746784.235766@bitdiddle.concentric.net> <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> Message-ID: <200007141417.JAA12935@cj20424-a.reston1.va.home.com> > > My only concern is that without some explicit expression of rights, > > some party might try to prevent us from distributing a PEP. According to a discussion I just had with Tim about a different issue, putting it in the public domain is just as good a safeguard against this particular problem. But we have an additional requirement here: we want to prevent others from distributing mutilated versions of our standard documents. I believe some form of open copyright is the best protection against that. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul@prescod.net Fri Jul 14 11:10:56 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:10:56 -0500 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators formatrix computation] References: <396DFDC5.6780A710@prescod.net> <396EE411.B3CB33A9@fft.be> Message-ID: <396EE730.6183423F@prescod.net> Gregory Lielens wrote: > > ... > > It seems potentially more dangerous than statically adding a new > operator, no? If two modules > install incompatible changes of syntax, for exmaple if they demand both > @ as operator, they will be considered as incompatible? I think that the idea is that one module would be in the Matrix sublanguage and another would be in an XML sublanguage. That way your context shifts are clear. Presumably the first or second line of the file says what sublanguage you are using. > Anyway, it seems that that audience (numeric people) was targeted by > python since the beginning, because why the hell include complex numbers > as built-in type if not? They are of a less general usefullness than > matrices, imho, the last can at least be used for graphic stuff... Okay, but look at the syntactic support complex numbers needed. Just "j". The same for string processing. We just reused most of the existing operators. If you guys made a really kick-ass matrix package that everyone loved and didn't need any new syntax, Guido might be tempted to make matrices a built-in type also! The funny thing is that most of the Python syntax that I don't use today is ALREADY for matrix operations: foo[x,y:a,b] foo()[...] -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Fri Jul 14 11:11:45 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:11:45 -0500 Subject: [Python-Dev] Re: http://python.sourceforge.net References: <200007140736.JAA29096@python.inrialpes.fr> <396EEF18.163475CD@schneider-kamp.de> Message-ID: <396EE761.9ADE5325@prescod.net> Peter Schneider-Kamp wrote: > >... > > With XHTML I'll probably end up with something like this: I don't know what you mean by probably, but about half of the stuff in your document is optional. Here's a fairly minimal XHTML representation: > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > > > my little home page > > >

My Little Home Page

> Here goes the content. > > Other than the first three lines, it is almost the same as your original HTML. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From esr@thyrsus.com Fri Jul 14 14:35:08 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 09:35:08 -0400 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: <200007141407.JAA12817@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 09:07:29AM -0500 References: <20000713235356.X7340@xs4all.nl> <14702.37331.302346.67441@anthem.concentric.net> <200007141407.JAA12817@cj20424-a.reston1.va.home.com> Message-ID: <20000714093508.A8842@thyrsus.com> Guido van Rossum : > XXX is not a Dutch invention -- I picked up the habit from the X11 > source code base. I believe it's fairly common in open source > projects, and there are so many XXX'es throughout Python already that > it's better not to try and change. Guido is correct. XXX as a to-be-done marker was already known to me and well established in the U.S. in 1990, when I collected the following entry: @hd{XXX} @pr{X-X-X} @g{n.} @p{} A marker that attention is needed. Commonly used in program comments to indicate areas that are kluged up or need to be. Some hackers liken `XXX' to the notional heavy-porn movie rating. Compare @es{FIXME}. @comment from Bob Page , 16 Dec 1990 -- Eric S. Raymond No matter how one approaches the figures, one is forced to the rather startling conclusion that the use of firearms in crime was very much less when there were no controls of any sort and when anyone, convicted criminal or lunatic, could buy any type of firearm without restriction. Half a century of strict controls on pistols has ended, perversely, with a far greater use of this weapon in crime than ever before. -- Colin Greenwood, in the study "Firearms Control", 1972 From esr@thyrsus.com Fri Jul 14 14:39:31 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 09:39:31 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007141413.JAA12883@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 09:13:29AM -0500 References: <14702.36906.418249.461209@anthem.concentric.net> <14702.39175.2260.890343@anthem.concentric.net> <200007141413.JAA12883@cj20424-a.reston1.va.home.com> Message-ID: <20000714093931.B8842@thyrsus.com> Guido van Rossum : > I just want to make it crystal clear that I'm *against* (that's a > -999, only overridable by a bus) inclusion of 3rd party library source > code in the Python source distribution. Exceptions can only be made > if the particular 3rd party code needs to be modified before it is > usable from Python (e.g. some checksum algorithms, and PCRE) or if > there is no reasonably accessible distribution available on the web. OK, I'm confused now. Moshe, are we talking about including 3rd-party code, or simply changing the build process so that RPMs and Debian packages have some additional requires and possibly include some unmodified binary libraries from third parties? -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. From paul@prescod.net Fri Jul 14 11:13:24 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:13:24 -0500 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> Message-ID: <396EE7C4.17DEF722@prescod.net> Greg Stein wrote: > > ... > > I haven't seen a clear consensus or decision from the XML SIG yet. By the way, one of the major reasons there is no clear consensus from the XML SIG yet is because we are hung up on an issue of fact. Is it technically and politically feasible to put 4XPath into the Python distribution. Our discussions over there will be radically different if everybody over here says "sure, that's no problem." -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From guido@beopen.com Fri Jul 14 15:37:46 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:37:46 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Thu, 13 Jul 2000 14:34:03 -0400." <396E0B9B.DD74EF5@interet.com> References: <396E0B9B.DD74EF5@interet.com> Message-ID: <200007141437.JAA13178@cj20424-a.reston1.va.home.com> Ignoring most that's been said in this thread, would it be possible for the installer to detect the presence of python15.dll in the system directory and offer to delete it? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul@prescod.net Fri Jul 14 14:42:50 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 08:42:50 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> <14702.19480.746784.235766@bitdiddle.concentric.net> <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> <200007141417.JAA12935@cj20424-a.reston1.va.home.com> Message-ID: <396F18DA.A3EE25BF@prescod.net> Guido van Rossum wrote: > > ... > > But we have an additional requirement here: we want to prevent others > from distributing mutilated versions of our standard documents. What about the Annotated Python Enhancement Proposals? I don't see what the big deal is. People can find the real ones the same way they find the real Python distribution. Mutilated ones do not hurt us much and are not that likely in the first place. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From guido@beopen.com Fri Jul 14 15:52:16 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:52:16 -0500 Subject: [Python-Dev] ConfigParser changes In-Reply-To: Your message of "Thu, 13 Jul 2000 22:46:37 -0400." <200007140246.WAA07574@snark.thyrsus.com> References: <200007140246.WAA07574@snark.thyrsus.com> Message-ID: <200007141452.JAA13252@cj20424-a.reston1.va.home.com> > I've seen a couple plus responses to my proposed ConfigParser > enhancements, no minuses, and the thread has petered out. > > If nobody hands me a -1, I'm going to merge them in in a day or so. > Speak now... Cool. One possible suggestion (just for your contemplation): if you're only adding methods, would it make sense to make a subclass, so that from the class one uses it is clear whether one intends to modify the options or just to read them? That would enable future optimizations. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gvwilson@nevex.com Fri Jul 14 14:59:18 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 09:59:18 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <200007141417.JAA12935@cj20424-a.reston1.va.home.com> Message-ID: > Guido (on copyrights, public domain, etc.): > But we have an additional requirement here: we want to prevent others > from distributing mutilated versions of our standard documents. I > believe some form of open copyright is the best protection against > that. We're using the Open Publication License for Software Carpentry for exactly this reason. I once had to get the IEEE's copyright lawyer involved in a dispute where some material I had written had been slightly modified and then posted on the web under someone else's name --- still occasionally have to deal with fallout from copies of copies of copies of the distorted version. Greg From jeremy@beopen.com Fri Jul 14 15:03:58 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 10:03:58 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: References: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: <14703.7630.267201.436909@bitdiddle.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I'm currently drawing a list for extensions to include: MZ> -- zlib -- Tcl/Tk -- expat -- PIL -- Anything else? MZ> I really want something with "everything" in it. Then your list is much too short. Everything is a lot. You also need OpenSSL, NumPy, PyXML, and kjBuckets. And that's just getting started. My worry about the list of things to include is where exactly to cut the list short. The crucial modules are going to be different for every person. You mentioned PIL as one of your first four extensions. I've used PIL exactly once, and then only as a brief experiment. When I took a poll on c.l.py about the RADIUS authentication module, I got one response saying it was vitally important and everyone needs it. (I think that respondents definition of everyone was "everyone who operates an ISP or campus network.") So add radius to your list. Jeremy From guido@beopen.com Fri Jul 14 16:05:39 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:05:39 -0500 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: Your message of "Thu, 13 Jul 2000 17:48:38 EST." <396E4746.DE25EFD4@prescod.net> References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> <396E4746.DE25EFD4@prescod.net> Message-ID: <200007141505.KAA13385@cj20424-a.reston1.va.home.com> > If Guido has decided that the design that has already been implemented > is the right one, what's the point of the PEP? Someone just needs to > review the patch and check it in! Right! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr@thyrsus.com Fri Jul 14 15:22:56 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 10:22:56 -0400 Subject: [Python-Dev] ConfigParser changes In-Reply-To: <200007141452.JAA13252@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 09:52:16AM -0500 References: <200007140246.WAA07574@snark.thyrsus.com> <200007141452.JAA13252@cj20424-a.reston1.va.home.com> Message-ID: <20000714102256.A9019@thyrsus.com> Guido van Rossum : > One possible suggestion (just for your contemplation): if you're only > adding methods, would it make sense to make a subclass, so that from > the class one uses it is clear whether one intends to modify the > options or just to read them? That would enable future optimizations. Yes, and I even know what I'd call the class: ConfigEditor. Unfortunately this plan it trips on a historical fact; one (1) of the write methods, add_section(), already existed in ConfigParser. Moving it to a ConfigEditor subclass would break backward compatibility. And I think it would be just too ugly to move all but one of the write methods into ConfigEditor and leave add_section() in the base class. If not for this problem I would be more than happy to do as you suggest. -- Eric S. Raymond "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy From Moshe Zadka Fri Jul 14 15:14:11 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 17:14:11 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <009501bfed89$e415ce40$f2a6b5d4@hagrid> Message-ID: On Fri, 14 Jul 2000, Fredrik Lundh wrote: > we sure have a major disconnect here -- wasn't the source > of this discussion the need to be able to loop over multiple > sequences in parallel? Yes > isn't "for" what you'd usually use when looping over things? Yes. The thing is, you don't need to cater to people who want to iterate over one sequence -- you can already do that easily in current day Python. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas@xs4all.net Fri Jul 14 15:20:17 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 16:20:17 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: ; from ping@lfw.org on Fri, Jul 14, 2000 at 03:09:10AM -0700 References: Message-ID: <20000714162017.B7340@xs4all.nl> On Fri, Jul 14, 2000 at 03:09:10AM -0700, Ka-Ping Yee wrote: > I actually believe > solve(X.H()*X, X.H()*y) > is *clearer* than > (X'*X)\(X'*y) > (What does the backslash mean? What does the tick mark mean? > At least solve() is clear, and if i understood what H() stood > for, it would mean more than a tick mark.) More importantly, how are they grouped ? Is '* a single operator, or is ' a binary operator and * an unary operator ? Or is ' a postfix unary operator and * the binary operator ? Does the backslash escape the opening paren for some reason, or is it an operator on its own ? Oh, wait, I see it now ! It's a string literal of the new 'X' type, containing '*X)\(X', multiplied by y! I wonder what that 'X' type string is... Maybe a built-in regular expression ? Confusing-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Moshe Zadka Fri Jul 14 15:20:11 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 17:20:11 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14703.7630.267201.436909@bitdiddle.concentric.net> Message-ID: On Fri, 14 Jul 2000, Jeremy Hylton wrote: > MZ> I really want something with "everything" in it. > > Then your list is much too short. Everything is a lot. "Everything" is different from everything. <"wink"> > You also need OpenSSL, NumPy, PyXML, and kjBuckets. And that's just > getting started. I want to aim for "top 10 packages". And anyway, having distutils should make this a snap -- the only thing we have to do is match versions. > My worry about the list of things to include is where exactly to cut > the list short. The crucial modules are going to be different for > every person. You mentioned PIL as one of your first four extensions. > I've used PIL exactly once, and then only as a brief experiment. When > I took a poll on c.l.py about the RADIUS authentication module, I got > one response saying it was vitally important and everyone needs it. > (I think that respondents definition of everyone was "everyone who > operates an ISP or campus network.") So add radius to your list. My list is of course tentative, but once my PEP hits the CVS archive, I intend to poll c.l.py for opinions on what packages to include. I've seen quite a few questions in c.l.py over PIL, and only one about RADIUS, but that's just anecdotal evidence. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gvwilson@nevex.com Fri Jul 14 15:24:14 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 10:24:14 -0400 (EDT) Subject: [Python-Dev] request for minor enhancement Message-ID: I would like 'min' and 'max' to be in-fix binary operators, with '__min__' and '__max__' as the associated overloadable method names, and 'min=' and 'max=' as the in-place forms. I find myself re-defining them in almost every module I write, and believe that their semantics and implementation would be unproblematic? Reactions? Thanks, Greg From guido@beopen.com Fri Jul 14 16:29:02 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:29:02 -0500 Subject: [Python-Dev] Request for Opinions In-Reply-To: Your message of "Fri, 14 Jul 2000 05:13:24 EST." <396EE7C4.17DEF722@prescod.net> References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE7C4.17DEF722@prescod.net> Message-ID: <200007141529.KAA13625@cj20424-a.reston1.va.home.com> > By the way, one of the major reasons there is no clear consensus from > the XML SIG yet is because we are hung up on an issue of fact. Is it > technically and politically feasible to put 4XPath into the Python > distribution. Our discussions over there will be radically different if > everybody over here says "sure, that's no problem." I have no idea what 4XPath is. Assuming it is a separately maintained and distributed 3rd party library, the answer is no for the source distribution and yes for binary distributions. I know you've argued about this before but it's pointless, I don't want to have 3rd party code checked in as part of the Python CVS tree or distributed as part of a Python source distribution. However, one thing we *could* do is collect convenient links to the source code of the latest versions of all the necessary or popular 3rd party libraries -- or even redistribute copies from our website if their license allows it. We could also create a "sumo" (meaning so big it contains everything) source distribution that contains Python and all needed 3rd party libraries. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Fri Jul 14 16:33:16 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:33:16 -0500 Subject: [Python-Dev] Pythonb at SourceForge FAQ In-Reply-To: Your message of "Thu, 13 Jul 2000 17:45:54 MST." <20000713174554.R29590@lyra.org> References: <396E7D29.7AC68EA6@schneider-kamp.de> <20000713174554.R29590@lyra.org> Message-ID: <200007141533.KAA13655@cj20424-a.reston1.va.home.com> > > 3.3.: > > > > Q: How to change the status of a patch? > > > > A: > > > > To change the status of a patch or assign it to somebody else you have > > to be a) a SourceForge-recognized Python developer and b) a patch > > administrator. Unfortunately the SourceForge default for developers is > > not to be patch administrators. Contact one of the project > > administrators if the following does not work for you. > > > > Click on the patch itself. In the screen that comes up, there is a > > drop-box for "Assigned To:" and a drop-box for "Status:" where you can > > select a new responsible developer or a new status respectively. After > > selecting the appropriate victim and status, hit the "Submit Changes" > > button at the bottom of the page. Note: if are sure that you have the right permissions and a drop-box does not appear, check that you are actually logged in to SF! > > For more information about the use of the "Status:" and "Assigned To:" > > fields consult the [26]Patch Manager Guidelines. A recent copy can be > > found in the Appendix of this FAQ. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Fri Jul 14 16:38:52 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:38:52 -0500 Subject: [Python-Dev] urllib vs. cgi In-Reply-To: Your message of "Thu, 13 Jul 2000 22:44:10 -0400." <20000713224410.A7548@thyrsus.com> References: <14702.31418.483935.810948@bitdiddle.concentric.net> <20000713224410.A7548@thyrsus.com> Message-ID: <200007141538.KAA13713@cj20424-a.reston1.va.home.com> > Jeremy Hylton : > > Any opinions on adding a symmetrical urldecode to urllib? I'm not > > thrilled by duplicating code, but the cgi module is big and hairy and > > urllib seems like the obvious place for it. [ESR] > +0. It doesn't thrill me, but I can't argue with your analysis either. +0. Ditto. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gregory.lielens@fft.be Fri Jul 14 15:43:51 2000 From: gregory.lielens@fft.be (Gregory Lielens) Date: Fri, 14 Jul 2000 16:43:51 +0200 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators formatrix computation] References: <396DFDC5.6780A710@prescod.net> <396EE411.B3CB33A9@fft.be> <396EE730.6183423F@prescod.net> Message-ID: <396F2727.E301FBB4@fft.be> > Okay, but look at the syntactic support complex numbers needed. Just > "j". The same for string processing. We just reused most of the existing > operators. If you guys made a really kick-ass matrix package that > everyone loved and didn't need any new syntax, Guido might be tempted to > make matrices a built-in type also! Right, but I think that making a kick-ass matrix package without syntax modification is not possible... Indeed, what characterize the numeric languages around (e.g. matlab, octave, yorick, r-lab, ...) is precisely the presence of a syntax able to naturrally express linear algebra expression. All of them introduce easy matrix concatenation, multiplication, division and bloc-adressing...By the way, all matrix package are more or less cloning the matlab way, with minor differences (except for yorick, which have a more general syntax able to deal with multidimensional arrays cleanly, but probably make things less easy with 2D matrix). I think that such convergence comes probably from the fact that the Matlab way is the good way for numeric stuff... > The funny thing is that most of the Python syntax that I don't use today > is ALREADY for matrix operations: > > foo[x,y:a,b] > foo()[...] This is inevitable, I agree that numeric stuff is completely off-topic for a lot of peoples...But unicode support is also an excess-feature for numerical code. Of course, when you write something which must compute linear regressions and you want to ask input to a user which only speek japanese...In fact, what attracts me in Python the first time I've heard of it (3 weeks ago, so do not take my words too seriously...) is that it seems to be able to do numeric stuff quite well, except for matrix...the Python+NumPy package improve that, but not to the point of beeing matlab-like. Python+NumPy+MatPy is better in that sense, but still lack some operators to be THE solution...I tried to implement those operators as a way to check how python is extensible (a must, as the intended use of this - or anoteher numeric language) is to serve as command tools for c++ Finite element software, and I was surprise how easy it was...So here they are! I do not really see a problem in adding new operators, except when - it slows down the old ones, and I do not think it could be noticed in the present case...more ifs in the source code is certainly not something to worry about... - it makes python code unintelligible, and this is not relevant either: No numeric -> do not use them, but if you do numeric stuff, everything becomes clearer. - it makes python source more complex: true, but so little than I think it makes no practical difference. It is really a small change, after all I was able to implement it in a matter of day after looking for the fist time in the code...Arguably, this change is of the same order of magnitude as the 1.0j stuff...perhaps smaller - It is a hole which will unleash the craziest operators , and makes python look like binary with expressions soup like k=(a*$$^b)%/(@~c): That's the only risk I would be affraid of, but as already mentioned, linear algebra is a well established field , used almost everywhere in numerics and we have a bunch of languages which already support these kind of operators... From guido@beopen.com Fri Jul 14 16:45:08 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:45:08 -0500 Subject: [Python-Dev] PyErr_SafeFormat In-Reply-To: Your message of "Thu, 13 Jul 2000 19:29:30 +0200." <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> Message-ID: <200007141545.KAA13821@cj20424-a.reston1.va.home.com> > greg wrote: > > We don't care about anything except for %d, %s, possibly %c and %x. > > how about: I would suggest to build this into PyErr_Format, which is what everybody already uses. Instant safety. Need some more analysis of what format codes are actually used, and support for %.200s which is currently used often. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr@thyrsus.com Fri Jul 14 16:05:04 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 11:05:04 -0400 Subject: [Python-Dev] request for minor enhancement In-Reply-To: ; from gvwilson@nevex.com on Fri, Jul 14, 2000 at 10:24:14AM -0400 References: Message-ID: <20000714110504.A9206@thyrsus.com> Greg Wilson : > I would like 'min' and 'max' to be in-fix binary operators, with '__min__' > and '__max__' as the associated overloadable method names, and 'min=' and > 'max=' as the in-place forms. I find myself re-defining them in almost > every module I write, and believe that their semantics and implementation > would be unproblematic? > > Reactions? +0 -- Eric S. Raymond "As to the species of exercise, I advise the gun. While this gives [only] moderate exercise to the body, it gives boldness, enterprise, and independence to the mind. Games played with the ball and others of that nature, are too violent for the body and stamp no character on the mind. Let your gun, therefore, be the constant companion to your walks." -- Thomas Jefferson, writing to his teenaged nephew. From guido@beopen.com Fri Jul 14 16:58:28 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:58:28 -0500 Subject: [Python-Dev] request for minor enhancement In-Reply-To: Your message of "Fri, 14 Jul 2000 10:24:14 -0400." References: Message-ID: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> > I would like 'min' and 'max' to be in-fix binary operators, with '__min__' > and '__max__' as the associated overloadable method names, and 'min=' and > 'max=' as the in-place forms. I find myself re-defining them in almost > every module I write, and believe that their semantics and implementation > would be unproblematic? You seem to propose two independent things. 1. in-fix min and max: you want to write "x min y" instead min(x, y). Why? It's not a notation I'm familiar with. Plus it's incompatible, since min would have to be a reserved word and it would break all existing code using min(). 2. __min__ and __max__ to override the semantics. Sure, this can be added regardless of (1). But do you want to override min(a, b) or min(sequence)? Note that min() and max() are variadic functions -- you can write min(a,b,c,d,e) which is the same as min([a,b,c,d,e]). 3. min= and max=? Ah, I see, like += and -=. Since I don't see much hope for (1) this is irrelevant. (But it's a good proposal for a generic syntax for other operators that are spelled with a reserved word.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy@beopen.com Fri Jul 14 16:01:43 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 11:01:43 -0400 (EDT) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396EE6B3.B86BED76@prescod.net> References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE6B3.B86BED76@prescod.net> Message-ID: <14703.11095.264917.268373@bitdiddle.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Greg Stein wrote: >> ... >> >> I think this is for the XML SIG. I don't know why it is >> here. SIGs discuss and design, then roll up their final >> decisions. PP> Okay, so we can agree in the XML SIG that we love XPath and then PP> "check in" 4K of Bison/FLEX/C/Python code without consulting PP> anyone else? Yes. You've got it exactly. How do you think lambda made its way into the language? Seriously -- you've already seen Guido's response. I think there's no chance of adding third-party code to the Python CVS repository or source distribution. The only way I could imagine it happening is if there was strong consensus from the XML SIG. So Greg's suggestion is a good one. Jeremy From Moshe Zadka Fri Jul 14 16:08:28 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 18:08:28 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007141413.JAA12883@cj20424-a.reston1.va.home.com> Message-ID: On Fri, 14 Jul 2000, Guido van Rossum wrote: > I just want to make it crystal clear that I'm *against* (that's a > -999, only overridable by a bus) inclusion of 3rd party library source > code in the Python source distribution. Exceptions can only be made > if the particular 3rd party code needs to be modified before it is > usable from Python (e.g. some checksum algorithms, and PCRE) or if > there is no reasonably accessible distribution available on the web. I took it that you're alright with a "sumo" distribution, which is core Python with + lots of goodies. I think it would be neat if the sumo distribution would be released together with the thin distribution from PythonLabs, and that Python-Dev would help support it. I *don't* think we need to maintain any such thing in the CVS tree -- only in the .tar.gz we let the world download. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gvwilson@nevex.com Fri Jul 14 16:17:17 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 11:17:17 -0400 (EDT) Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> Message-ID: > > Greg Wilson wrote: > > I would like 'min' and 'max' to be in-fix binary operators, with '__min__' > > and '__max__' as the associated overloadable method names, and 'min=' and > > 'max=' as the in-place forms. > On Fri, 14 Jul 2000, Guido van Rossum wrote: > > 1. in-fix min and max: you want to write "x min y" instead min(x, y). > Why? It's not a notation I'm familiar with. Plus it's incompatible, > since min would have to be a reserved word and it would break all > existing code using min(). I got there by working backwards to make things consistent. I want overloadable '__min__' and 'min=', and everything else that has these forms is binary infix (I think). > 2. __min__ and __max__ to override the semantics. Sure, this can be > added regardless of (1). But do you want to override min(a, b) or > min(sequence)? Note that min() and max() are variadic functions -- > you can write min(a,b,c,d,e) which is the same as min([a,b,c,d,e]). '+', '*', and the bitwise operators are equally variadic --- is confusion avoided by using punctuation for the infix binary form, and a named function for the general form? If the answer is 'yes', then my crystal ball predicts the following exchange: Greg: So let's adopt the notation '?' for 'min' and 'max', as used in C* and other parallel languages. We can then use '?=' for the infix forms, and reserve 'min()' and 'max()' as built-ins for the variadic forms. After all, it's just an historical accident that 'min' and 'max' aren't treated with the same respect as '+' and 'or'. Someone: Uck! I've never seen that before! It looks like line noise! It's not worth complexifying the core language with new operators for this special case. Greg: ...which is exactly the response I've twice typed in, and deleted, on the "linear algebra operators" thread. If 'min' and 'max' (which are used for strings as well as numbers) aren't worth new operators, I don't think matrices are either (and I probably do more matrix algebra than most people on this list). > 3. min= and max=? Ah, I see, like += and -=. Since I don't see much > hope for (1) this is irrelevant. (But it's a good proposal for a > generic syntax for other operators that are spelled with a reserved > word.) Thanks, Greg p.s. if min(a,b,c,d,e) is the same as min([a,b,c,d,e]), then what is the meaning of min([a,b,c,d,e], [g,h,i,j,k])? From Moshe Zadka Fri Jul 14 16:18:31 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 18:18:31 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <20000714093931.B8842@thyrsus.com> Message-ID: On Fri, 14 Jul 2000, Eric S. Raymond wrote: > Guido van Rossum : > > I just want to make it crystal clear that I'm *against* (that's a > > -999, only overridable by a bus) inclusion of 3rd party library source > > code in the Python source distribution. Exceptions can only be made > > if the particular 3rd party code needs to be modified before it is > > usable from Python (e.g. some checksum algorithms, and PCRE) or if > > there is no reasonably accessible distribution available on the web. > > OK, I'm confused now. > > Moshe, are we talking about including 3rd-party code, or simply > changing the build process so that RPMs and Debian packages have some > additional requires and possibly include some unmodified binary > libraries from third parties? Neither. Let me explain: I *don't* care about RPM and Debian packages, nor about windows installers. Those who create such packages have time on their hands, and usually a pretty good Python and C knowledge. What I do care about, is that when building a complete Python interpreter from source on a UNIX system, one has the option of downloading the sumo package, type "./configure;make;make install", drink a cup of coffee, and have a Python installation which does what he needs. Take me, for example. I've decided to write a GUI in Python, and I need to -- download Tcl 8.0 (because that's what Python 1.5.2 works with), and compile it -- download Tk 8.0 and compile it -- Edit the Modules/Setup file to point to my Tcl/Tk installation -- Compile Python Now, if I find out later (as I have) that PIL would make my life easier, I need to download PIL, edit *it* so it builds against my Tcl/Tk, and install it. (Eventually, I decided to go without PIL because I don't have the time) Then I want to prototype some XML manipulation in Python. So I have to find out where expat lives, compile it, and only then I can get PyExpat to work. Now, if I were using Debian, I'd simply spend some quality time with apt-get and get over this. But I'm using Solaris, and later I might need to port to AIX. So I'm using source distributions, and it is simply painful. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From akuchlin@mems-exchange.org Fri Jul 14 16:20:02 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 14 Jul 2000 11:20:02 -0400 Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: ; from gvwilson@nevex.com on Fri, Jul 14, 2000 at 11:17:17AM -0400 References: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> Message-ID: <20000714112002.E28819@kronos.cnri.reston.va.us> On Fri, Jul 14, 2000 at 11:17:17AM -0400, Greg Wilson wrote: >I want overloadable '__min__' and 'min=', and everything else that has these >forms is binary infix (I think). One exception to the binary infix form: 'if foo' will call foo.__nonzero__. --amk From MarkH@ActiveState.com Fri Jul 14 16:21:29 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Fri, 14 Jul 2000 11:21:29 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007141437.JAA13178@cj20424-a.reston1.va.home.com> Message-ID: > Ignoring most that's been said in this thread, would it be possible > for the installer to detect the presence of python15.dll in the system > directory and offer to delete it? This should only be done if the installer can be very sure that the user _tried_ to uninstall 1.5, but this DLL remains. This could be done in a number of ways, none of which are foolproof (eg, you could check for a 1.5 registry key, but of the user has added their own PythonPath entries, for example, the installer wont remove them (as it didnt add them) - meaning you end up with a partial 1.5 registry tree remaining. A big of experimentation could provide something that works in a majority of cases. IMO, it is very important 1.5 and x.x can coexist on the same machine; especially in the light of this thread, where it should be obvious that many extension wont be available for post 1.5 releases until quite some time after that core release hits the street... Mark. \ From akuchlin@mems-exchange.org Fri Jul 14 16:23:15 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 14 Jul 2000 11:23:15 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14703.7630.267201.436909@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jul 14, 2000 at 10:03:58AM -0400 References: <14702.4582.530066.817107@bitdiddle.concentric.net> <14703.7630.267201.436909@bitdiddle.concentric.net> Message-ID: <20000714112315.F28819@kronos.cnri.reston.va.us> On Fri, Jul 14, 2000 at 10:03:58AM -0400, Jeremy Hylton wrote: >the list short. The crucial modules are going to be different for >every person. You mentioned PIL as one of your first four extensions. That's why I think this is a mug's game; people have wildly differing needs, and you can't meet them all. The correct fix is to make it easy to automatically download & install packages automatically; distributions then become simple lists. "You want to do Web development? Grab Cookie.py, wizard.py, DocumentTemplate, ..." "Numeric work? NumPy, PhysicalValue, Snow, ..." --amk From guido@beopen.com Fri Jul 14 17:24:56 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 11:24:56 -0500 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: Your message of "Fri, 14 Jul 2000 18:08:28 +0300." References: Message-ID: <200007141624.LAA14130@cj20424-a.reston1.va.home.com> > I took it that you're alright with a "sumo" distribution, which is core > Python with + lots of goodies. I think it would be neat if the sumo > distribution would be released together with the thin distribution from > PythonLabs, and that Python-Dev would help support it. Yes, we here at PythonLabs don't know enough about all the different 3rd party packages to know what to add and how to ensure that it builds easily. I suppose it should also have a top-level super-Makefile and a suggested Modules/Setup file (with all the 3rd packages enabled and correct pointers to source directories). > I *don't* think we need to maintain any such thing in the CVS tree -- only > in the .tar.gz we let the world download. Agreed. I have to add that I'm +0 on this idea -- it would seem that if we distribute a sumo RPM distribution we'd help way more people. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Fri Jul 14 17:26:49 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 11:26:49 -0500 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: Your message of "Fri, 14 Jul 2000 18:18:31 +0300." References: Message-ID: <200007141626.LAA14154@cj20424-a.reston1.va.home.com> > Neither. Let me explain: I *don't* care about RPM and Debian packages, nor > about windows installers. Those who create such packages have time on > their hands, and usually a pretty good Python and C knowledge. What I do > care about, is that when building a complete Python interpreter from > source on a UNIX system, one has the option of downloading the sumo > package, type "./configure;make;make install", drink a cup of coffee, and > have a Python installation which does what he needs. > > Take me, for example. I've decided to write a GUI in Python, and I need to > -- download Tcl 8.0 (because that's what Python 1.5.2 works with), and > compile it > -- download Tk 8.0 and compile it > -- Edit the Modules/Setup file to point to my Tcl/Tk installation > -- Compile Python > > Now, if I find out later (as I have) that PIL would make my life easier, > I need to download PIL, edit *it* so it builds against my Tcl/Tk, and > install it. (Eventually, I decided to go without PIL because I don't have > the time) > > Then I want to prototype some XML manipulation in Python. So I have to > find out where expat lives, compile it, and only then I can get PyExpat > to work. > > Now, if I were using Debian, I'd simply spend some quality time with > apt-get and get over this. But I'm using Solaris, and later I might need > to port to AIX. So I'm using source distributions, and it is simply > painful. Bah, Solaris. Who still uses that old crap? :-) Or you could wait for ActivePython, which promises a binary distribution of Python 2.0 for Solaris. http://www.activestate.com/Products/ActivePython.html --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr@thyrsus.com Fri Jul 14 16:39:26 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 11:39:26 -0400 Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: ; from gvwilson@nevex.com on Fri, Jul 14, 2000 at 11:17:17AM -0400 References: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> Message-ID: <20000714113926.B9381@thyrsus.com> Greg Wilson : > Greg: So let's adopt the notation '?' for 'min' and > 'max', as used in C* and other parallel languages. We can > then use '?=' for the infix forms, and reserve > 'min()' and 'max()' as built-ins for the variadic forms. > After all, it's just an historical accident that 'min' and > 'max' aren't treated with the same respect as '+' and 'or'. I would support something like this. What's really going on here, IMO, is that you're groping towards giving Python a complete set of notations for lattice algebra. My ma\thematician head likes this idea. -- Eric S. Raymond Men trained in arms from their infancy, and animated by the love of liberty, will afford neither a cheap or easy conquest. -- From the Declaration of the Continental Congress, July 1775. From jeremy@beopen.com Fri Jul 14 16:36:00 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 11:36:00 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007141624.LAA14130@cj20424-a.reston1.va.home.com> References: <200007141624.LAA14130@cj20424-a.reston1.va.home.com> Message-ID: <14703.13152.88286.674722@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> I *don't* think we need to maintain any such thing in the CVS >> tree -- only in the .tar.gz we let the world download. GvR> Agreed. GvR> I have to add that I'm +0 on this idea -- it would seem that if GvR> we distribute a sumo RPM distribution we'd help way more GvR> people. I think it's significantly harder to create a .tar.gz file with a configure script and a makefile that builds Python and all the third-party libraries it depends on. Does the zlib source belong in the .tar.gz? How about OpenSSL? Tcl/Tk? libc? There are at least two problems with putting anything other than Python in a .tar.gz that we distribute. First, the user who grabs it may already have some of the third-party extensions installed. Second, we have a version-skew nightmare because each library is updated at its own pace. This is why Andrew is still correct! >>>>> "AMK" == Andrew Kuchling writes: AMK> The correct fix is to make it easy to AMK> automatically download & install packages automatically; AMK> distributions then become simple lists. "You want to do Web AMK> development? Grab Cookie.py, wizard.py, DocumentTemplate, ..." AMK> "Numeric work? NumPy, PhysicalValue, Snow, AMK> ..." The distutils plus platform-specific package management like RPM and Debian packages are the right solution. We can produce a Python package that indicates its dependence on readline, Tcl/Tk, or anything else. We can also provide a collection of Python packages via distutils that addresses the needs of particular audiences -- Web slingers, numerical analysts, etc. Jeremy From Fredrik Lundh" Message-ID: <00f001bfeda9$a7d0d400$f2a6b5d4@hagrid> paul wrote: > We have three options: >=20 > 1. use the relatively large 4XPath as is >=20 > 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) > that can be implemented in a couple of hundred lines of Python code > (this code is mostly done already, in a module called TinyXPath) >=20 > 3. try to scale 4XPath back by moving its parser to SRE, and making > some of its features "options" that can be added separately (not clear > how easy this is) >=20 > What do you think? if there's a migration path from (2) to (1) (interface-wise, at least), I'd vote for (2). or (2)+(3), if that makes sense. (I know I've promised to look at (1)+(3), but I haven't quite gotten there yet...) From Fredrik Lundh" Message-ID: <00ef01bfeda9$a753b4c0$f2a6b5d4@hagrid> greg wrote: > p.s. if min(a,b,c,d,e) is the same as min([a,b,c,d,e]), then what is = the > meaning of min([a,b,c,d,e], [g,h,i,j,k])? same as min([[a,b,c,d,e], [g,h,i,j,k]]), of course. From thomas@xs4all.net Fri Jul 14 16:33:43 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 17:33:43 +0200 Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: <20000714112002.E28819@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Fri, Jul 14, 2000 at 11:20:02AM -0400 References: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> <20000714112002.E28819@kronos.cnri.reston.va.us> Message-ID: <20000714173343.C7340@xs4all.nl> On Fri, Jul 14, 2000 at 11:20:02AM -0400, Andrew Kuchling wrote: > On Fri, Jul 14, 2000 at 11:17:17AM -0400, Greg Wilson wrote: > >I want overloadable '__min__' and 'min=', and everything else that has > >these forms is binary infix (I think). > One exception to the binary infix form: 'if foo' will call > foo.__nonzero__. And another: int(foo) (and other, implicit conversions) call foo.__int__. However, I think overloading 'min' and 'max' should fall under the rich comparisons PEP. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From uche.ogbuji@fourthought.com Fri Jul 14 16:38:59 2000 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Fri, 14 Jul 2000 09:38:59 -0600 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE7C4.17DEF722@prescod.net> <200007141529.KAA13625@cj20424-a.reston1.va.home.com> Message-ID: <396F3413.608AF907@fourthought.com> Even though I'm one of the 4XPath developers, I've largely stayed on the sidelines because I've never been on python-dev, and I don't know how such matters are usually considered. Guido's response gives good guidance, and my ideas are expressed in-line. Guido van Rossum wrote: > > > By the way, one of the major reasons there is no clear consensus from > > the XML SIG yet is because we are hung up on an issue of fact. Is it > > technically and politically feasible to put 4XPath into the Python > > distribution. Our discussions over there will be radically different if > > everybody over here says "sure, that's no problem." > > I have no idea what 4XPath is. Assuming it is a separately maintained > and distributed 3rd party library, the answer is no for the source > distribution and yes for binary distributions. Paul did suggest a couple of other options. One was to make 4XPath easier to integrate into Python (by moving to SRE or otherwise removing the lex/yacc dependencuy), and this is a possibility. However, I don't know how you gauge what a "third-party" module is. My guess would be that it's a matter of copyright. If so, that might be an obstacle, but maybe not an insurmountable one. The other solution was to write an XPath-lite, probably all in Python to go with minidom in the Python distro. This would be the path of least resistance, but we are still discussion on xml-sig the useful subset of XPath. Is there any clear statement of policiy for including modules? Even a mailing-list archive entry? I don't expect one because this is open-source/BDFL world where the policy usually lies in a highly-respectable head, but it could certainly guide this conversation either here or on xml-sig. > We could also create a "sumo" (meaning so big it contains everything) > source distribution that contains Python and all needed 3rd party > libraries. Not a bad idea as a stop-gap answer to CPAN. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +01 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python From guido@beopen.com Fri Jul 14 17:47:03 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 11:47:03 -0500 Subject: [Python-Dev] Request for Opinions In-Reply-To: Your message of "Fri, 14 Jul 2000 09:38:59 CST." <396F3413.608AF907@fourthought.com> References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE7C4.17DEF722@prescod.net> <200007141529.KAA13625@cj20424-a.reston1.va.home.com> <396F3413.608AF907@fourthought.com> Message-ID: <200007141647.LAA14305@cj20424-a.reston1.va.home.com> > Even though I'm one of the 4XPath developers, I've largely stayed on the > sidelines because I've never been on python-dev, and I don't know how > such matters are usually considered. Guido's response gives good > guidance, and my ideas are expressed in-line. Thanks for responding! > Guido van Rossum wrote: > > > > > By the way, one of the major reasons there is no clear consensus from > > > the XML SIG yet is because we are hung up on an issue of fact. Is it > > > technically and politically feasible to put 4XPath into the Python > > > distribution. Our discussions over there will be radically different if > > > everybody over here says "sure, that's no problem." > > > > I have no idea what 4XPath is. Assuming it is a separately maintained > > and distributed 3rd party library, the answer is no for the source > > distribution and yes for binary distributions. > > Paul did suggest a couple of other options. One was to make 4XPath > easier to integrate into Python (by moving to SRE or otherwise removing > the lex/yacc dependencuy), and this is a possibility. However, I don't > know how you gauge what a "third-party" module is. My guess would be > that it's a matter of copyright. If so, that might be an obstacle, but > maybe not an insurmountable one. The other solution was to write an > XPath-lite, probably all in Python to go with minidom in the Python > distro. This would be the path of least resistance, but we are still > discussion on xml-sig the useful subset of XPath. > > Is there any clear statement of policiy for including modules? Even a > mailing-list archive entry? I don't expect one because this is > open-source/BDFL world where the policy usually lies in a > highly-respectable head, but it could certainly guide this conversation > either here or on xml-sig. My policy for including modules is that Python becomes the only distribution point of the code, and the code is maintained through the Python CVS tree (possibly by the original author). This places restrictions on the copyright notice. There are exceptions (e.g. cPickle.c has a life of its own in the Zope world, although the modules frequently get re-sync'ed), but they are rare and must serve very special purposes. Unless I'm mistaken, 4XPath leads a separate life so can't be included. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gvwilson@nevex.com Fri Jul 14 16:49:12 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 11:49:12 -0400 (EDT) Subject: [Python-Dev] Re: request for minor enhancement / linear algebra In-Reply-To: <20000714113926.B9381@thyrsus.com> Message-ID: > > Greg: So let's adopt the notation '?' for 'min' and > > 'max', as used in C* and other parallel languages. We can > > then use '?=' for the infix forms, and reserve > > 'min()' and 'max()' as built-ins for the variadic forms. > > After all, it's just an historical accident that 'min' and > > 'max' aren't treated with the same respect as '+' and 'or'. > Eric Raymond: > I would support something like this. What's really going on here, > IMO, is that you're groping towards giving Python a complete set of > notations for lattice algebra. My mathematician head likes this > idea. Greg: I was actually trying to convince people that adding operators one by one (even well-defined ones that lots of people would use) would be a bad idea. Our two main reasons for choosing Python for Software Carpentry were its simplicity (it can be taught quickly) and its availability (widely portable, open source). I (and my customers) would enjoy doing matrix algebra using mathematical notation in Python, but one-at-a-time extensions are going to reduce the chances of people choosing Python for their projects. Saying, "But you don't have to use these new operators if you don't want to," is a red herring --- if I want to understand/modify other people's code, I'll have to learn 'em (just as I've had to learn most of Perl's syntax, one painful special case at a time, in order to use the LDAP, XML, CGI, and imaging libraries). So: I would like this (linear algebra, min/max, other notation) to happen, but only if there's an extensible, scalable framework for user-defined libraries to add operators to Python, in the same way that they can now add new classes. "Extend, or extend not --- there is no special case." Thanks, Greg From Fredrik Lundh" <396E0B9B.DD74EF5@interet.com> <200007141437.JAA13178@cj20424-a.reston1.va.home.com> Message-ID: <01b201bfedac$12353d20$f2a6b5d4@hagrid> guido wrote: > Ignoring most that's been said in this thread, would it be possible > for the installer to detect the presence of python15.dll in the system > directory and offer to delete it? would the average user know when to click "Yes" ? From Moshe Zadka Fri Jul 14 16:50:55 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 18:50:55 +0300 (IDT) Subject: [Python-Dev] request for minor enhancement In-Reply-To: Message-ID: On Fri, 14 Jul 2000, Greg Wilson wrote: > I would like 'min' and 'max' to be in-fix binary operators, with '__min__' > and '__max__' as the associated overloadable method names, and 'min=' and > 'max=' as the in-place forms. I find myself re-defining them in almost > every module I write, and believe that their semantics and implementation > would be unproblematic? I'm -1 on that. I'm a mathematician by schooling, and I must say max(1,2) reads much more naturally to me then 1 max 2 And "max=" just looks..... i max= 5? Come on, isn't i = max(i, 5) much more readable? Re: overloading: it is useful only for lattices, as any linear order can just use the definition max(i,j) == k iff (i==k or j==k) and i<=k and j<=k Until Python recognizes the fact that not everything is linearly ordered (AKA, rich comparisons, which should be done as a PEP really), it would be futile to deal with lattices. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From fdrake@beopen.com Fri Jul 14 16:56:00 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 11:56:00 -0400 (EDT) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396EE66F.59D0D45F@prescod.net> References: <200007140516.HAA28633@python.inrialpes.fr> <396EE66F.59D0D45F@prescod.net> Message-ID: <14703.14352.411905.934970@cj42289-a.reston1.va.home.com> [Note that I've simplified the headers, but cross-posted to python-dev and xml-sig. *Please* follow up to xml-sig!] Paul Prescod writes: > Why aren't we ready to dicuss it? I think the XML crew should discuss these things first. PyXML has generally been treated as a catch all for various neat XML stuff, but looking at it as a careful extension of the core XML support means we need to think about it that way, including the line between what's in the core and what isn't. I think it's very valuable to listen to the experts on this topic (which I think is predominantly you, the FourThought crew, and Lars, with Sean playing a secondary role since he's usually too busy to participate in the discussions). I'd like to see this discussed in the SIG with an eye to creating two non-experimental packages: 1. XML support for the Python standard library, and 2. an XML extension package that adds support for more recommendations and candidate recommendations. There should still be something like the current PyXML, which contains all the neat stuff that doesn't fall in one of the other two categories. I think a PEP and further discussions in the XML-SIG are in order before we add more material into the standard library. I'm firmly committed to getting the "right stuff" in there, but I don't want to rush headlong into adding things before they're ready and agreed upon. I'd love to see you or one of the other Python+XML leaders be editor for a PEP on this topic. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul@prescod.net Fri Jul 14 16:57:26 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 10:57:26 -0500 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE7C4.17DEF722@prescod.net> <200007141529.KAA13625@cj20424-a.reston1.va.home.com> Message-ID: <396F3866.97D1752@prescod.net> Guido van Rossum wrote: > >... > > I have no idea what 4XPath is. Assuming it is a separately maintained > and distributed 3rd party library, the answer is no for the source > distribution and yes for binary distributions. 4XPath is currently separately maintained. If it became part of the Python source, I would expect that to become the canonical version. The issue here isn't third party libraries its quantity of source and the fact that it is a mix of Bison/FLEX/C/Python. If it were six hundred lines of pure Python I think we would have checked it in already! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Fredrik Lundh" <20000713091546.A5094@thyrsus.com> <20000713153434.U7340@xs4all.nl> Message-ID: <01ed01bfedac$f5f81fa0$f2a6b5d4@hagrid> thomas wrote: > > plait() is *good*. >=20 > Hmm... 'plait'. I don't even know what that means. it's yoghurt, right? From Moshe Zadka Fri Jul 14 17:04:41 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 19:04:41 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14703.13152.88286.674722@bitdiddle.concentric.net> Message-ID: On Fri, 14 Jul 2000, Jeremy Hylton wrote: > I think it's significantly harder to create a .tar.gz file with a > configure script and a makefile that builds Python and all the > third-party libraries it depends on. Does the zlib source belong in > the .tar.gz? How about OpenSSL? Tcl/Tk? libc? Yes to all popular ones but "libc". > There are at least two problems with putting anything other than > Python in a .tar.gz that we distribute. First, the user who grabs it > may already have some of the third-party extensions installed. And I'm not suggesting to install any third-party extension publicly! Everything should be installled in Python's tree. > Second, we have a version-skew nightmare because each library is > updated at its own pace. No, we release a known-good version. Users who need more sophistication can build their own. > This is why Andrew is still correct! For well packaged platforms, like, well, Linux and FreeBSD. But on Solaris, it's much harder to find the readline library in an already packaged form, and the dependancy mechanism there sucks anyway. > AMK> The correct fix is to make it easy to > AMK> automatically download & install packages automatically; > AMK> distributions then become simple lists. "You want to do Web > AMK> development? Grab Cookie.py, wizard.py, DocumentTemplate, ..." > AMK> "Numeric work? NumPy, PhysicalValue, Snow, > AMK> ..." > > The distutils plus platform-specific package management like RPM and > Debian packages are the right solution. For Linux, plus add ports to cover FreeBSD. Anyone using any other UNIX is SOL right now. I agree that a "web-oriented sumo distribution", "numeric-oriented sumo distribution", .... etc. would be cool. If we had infinite resources, I'd be +10 on that -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Fredrik Lundh" <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> Message-ID: <02c701bfedae$7db6fd20$f2a6b5d4@hagrid> guido wrote: > > > We don't care about anything except for %d, %s, possibly %c and = %x. > >=20 > > how about: >=20 > I would suggest to build this into PyErr_Format, which is what > everybody already uses. Instant safety. Need some more analysis of > what format codes are actually used greg's original mail mentioned %d, %i, %s, %c and %x, which is what I implemented. (if my code stumbles upon any other formatting code, it simply copies the rest of the formatting string to the output = string.) it also looks as if PyErr_Format is undocumented, so we could solve this by simply writing some documentation ;-) > and support for %.200s which is currently used often. note that the code intentionally ignores the .200 part; as greg pointed out, they're only used today to make sure the message doesn't overflow PyErr_Format's buffer... but it's easy to fix. patch coming. From esr@thyrsus.com Fri Jul 14 17:21:40 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 12:21:40 -0400 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <01ed01bfedac$f5f81fa0$f2a6b5d4@hagrid>; from effbot@telia.com on Fri, Jul 14, 2000 at 06:02:48PM +0200 References: <396DB5E8.6F12ACA4@per.dem.csiro.au> <20000713091546.A5094@thyrsus.com> <20000713153434.U7340@xs4all.nl> <01ed01bfedac$f5f81fa0$f2a6b5d4@hagrid> Message-ID: <20000714122140.A9722@thyrsus.com> Fredrik Lundh : > thomas wrote: > > > plait() is *good*. > > > > Hmm... 'plait'. I don't even know what that means. > > it's yoghurt, right? No, *I* wrote `plait() is *good*.' In English, `plait' is a slightly unusual word with a meaning almost indistinguishable from `braid'. The difference is that the primary use of `braid' has to do with hair, while `plait' is associated with ribbons or other forms of ornament. -- Eric S. Raymond [W]hat country can preserve its liberties, if its rulers are not warned from time to time that [the] people preserve the spirit of resistance? Let them take arms...The tree of liberty must be refreshed from time to time, with the blood of patriots and tyrants. -- Thomas Jefferson, letter to Col. William S. Smith, 1787 From guido@beopen.com Fri Jul 14 18:14:44 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 12:14:44 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Fri, 14 Jul 2000 17:56:26 +0200." <01b201bfedac$12353d20$f2a6b5d4@hagrid> References: <396E0B9B.DD74EF5@interet.com> <200007141437.JAA13178@cj20424-a.reston1.va.home.com> <01b201bfedac$12353d20$f2a6b5d4@hagrid> Message-ID: <200007141714.MAA14470@cj20424-a.reston1.va.home.com> > > Ignoring most that's been said in this thread, would it be possible > > for the installer to detect the presence of python15.dll in the system > > directory and offer to delete it? > > would the average user know when to click "Yes" ? Whenever they don't have a 1.5 installation that they are interested in preserving. Hm, the registry probably points to where that would live if it existed, so the installer (or a custom program run automatically by it) can do more probing if it needs to. I guess the user should think about whether they want their Python COM things to use 1.5 or 2.0. Only the one they choose should install its DLL in the system directory; the other one should have its DLL in its own directory. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Fri Jul 14 17:15:49 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 14 Jul 2000 11:15:49 -0500 Subject: [Python-Dev] A bit of a delay on stuff on my plate... Message-ID: <200007141615.LAA11548@dolphin.mojam.com> I ran into a little snag yesterday on the way to making a few changes (particularly the *path.commonprefix stuff). I mislaid my computer. Actually, I left it (in its briefcase, with my cell phone and Palm - in short, essentially my entire electronic existence) in a meeting in Los Altos and didn't realize it until I got to the SF airport. Fortunately, it was retrieved, but I am sans electronica for a day or two until it gets shipped out to me. I'll take care of everything that's on my plate when I get my electronic life reassembled. I've already assigned some tasks to volunteers who are helping with regression test writing for the posix, *path and sys modules. Hopefully they'll make some progress in my absence... Skip From huaiyu_zhu@yahoo.com Fri Jul 14 17:29:17 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 09:29:17 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <010401bfed6c$8d905300$0900a8c0@SPIFF> Message-ID: On Fri, 14 Jul 2000, Fredrik Lundh wrote: > Huaiyu Zhu wrote: > > Look it this way. Text processing do have their special syntaxes. > > what special syntax? > > regular expressions are a *sublanguage* in Python. everything else > is done through methods and ordinary sequence operators. Following is the quote of my previous post: > > (While a Python variant isn't something I'm enthused about, one > language can't be all things to all people, and I don't see why matrix > operations are so important as to get extra specialized operators; > lots of people use Python for text processing or for COM, so why > shouldn't special syntax be added for *those* applications? Having a > special parser also means that other matrix-specific language changes > could be made.) Well, linear algebra is not just another special domain. It is almost as elementary as arithmetic. Vectors and matrices are fundamental concepts in mathematics that underlies almost all of "scientific computation". They distill centuries of research in science and engineering, especially computation techniques. It is unlikely that adding linear algebra support would open up a flood gate for similar constructs. Look it this way. Text processing do have their special syntaxes. A string is written as "string" instead of ['s','t','r','i','n','g']. There is even the new sep.join(list). There are also lists and dicts for to build structures for discrete maths. If we had requested that new syntax for Fourier analysis or fractal generation that would be comparable to text processing or COM. Python actually has the chance of being all things to most people. The other half of the computing crowd only needs a few very basic asistance to come across. This crowd consists of people who design bridges and missiles, figure out weather patterns or DNA structures, detect credit card fraud or defects on a microchip, design speach recognition systems or network traffic balance algorithms and machines that learn to play games. Science and technology have great power to penatrate many aspects of life. And imagine if most of that is implemented in a laguage that can also be taught in schools. Huaiyu From ping@lfw.org Fri Jul 14 17:31:49 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Fri, 14 Jul 2000 09:31:49 -0700 (PDT) Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: Message-ID: On Fri, 14 Jul 2000, Greg Wilson wrote: > > p.s. if min(a,b,c,d,e) is the same as min([a,b,c,d,e]), then what is the > meaning of min([a,b,c,d,e], [g,h,i,j,k])? Why, [(a,g), (b,h), (c,i), (d,j), (e,k)], of course. killing two birds with one (planet-sized) stone, -- ?!ng From huaiyu_zhu@yahoo.com Fri Jul 14 17:51:59 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 09:51:59 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <20000714162017.B7340@xs4all.nl> Message-ID: > > (X'*X)\(X'*y) > > > (What does the backslash mean? What does the tick mark mean? > > At least solve() is clear, and if i understood what H() stood > > for, it would mean more than a tick mark.) > > More importantly, how are they grouped ? Is '* a single operator, or is ' a > binary operator and * an unary operator ? Or is ' a postfix unary operator > and * the binary operator ? Does the backslash escape the opening paren for > some reason, or is it an operator on its own ? > > Oh, wait, I see it now ! It's a string literal of the new 'X' type, > containing '*X)\(X', multiplied by y! I wonder what that 'X' type string > is... Maybe a built-in regular expression ? What does this mean? s = 1.2; g = 4.4; t = 6. a = s/2 + t/3 + 1/g Ah, that means a is the operation that globally substitute '2' followed by one or more space followed by ' t' with string '3 + 1'. :-) It seems many in this list visually parse an expression in the following order, arithmetic, structure, user defined. However, for anyone who's done any numerical computation, matrix is part of arithmetic, with as much justification as complex numbers (theoretically even more justification). Whether it's user defined or built in, it has the same precedence as arithmetic. Imagine if users are forced to write the above as a = add(add(div(s,2), div(t,3)), div(1,g)) to avoid confusion with regular expression! When we talk about CP4E, don't forget math 4E. And matrix is pivotal to that goal. As to the original expression in matlab, ' is a postfix operator and \ is an ordinary binary operator, as in undergraduate math books. Huaiyu From paul@prescod.net Fri Jul 14 17:51:12 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 11:51:12 -0500 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE6B3.B86BED76@prescod.net> <14703.11095.264917.268373@bitdiddle.concentric.net> Message-ID: <396F4500.E80ABB39@prescod.net> Jeremy Hylton wrote: > > ... > > Seriously -- you've already seen Guido's response. I think there's no > chance of adding third-party code to the Python CVS repository or > source distribution. The only way I could imagine it happening is if > there was strong consensus from the XML SIG. So Greg's suggestion is > a good one. I don't see the XML SIG overriding/convincing Guido on that issue, so it wasn't really the issue I was asking about. I need to know what sorts of packages Python's maintainers are willing to adopt. As extreme examples, if I write a 50,000 line persistence package that many people asked for, would it go into Python? If I write an extension module in Pascal, could that go into Python? Obviously the 4XPath example is not that extreme so I'm trying to get opinions. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Fri Jul 14 17:51:21 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 11:51:21 -0500 Subject: [Python-Dev] linear algebra References: Message-ID: <396F4509.30069096@prescod.net> Greg Wilson wrote: > > .... Saying, "But you don't have to use these new operators if > you don't want to," is a red herring --- if I want to understand/modify > other people's code, I'll have to learn 'em (just as I've had to learn > most of Perl's syntax, one painful special case at a time, in order to use > the LDAP, XML, CGI, and imaging libraries). > > So: I would like this (linear algebra, min/max, other notation) to happen, > but only if there's an extensible, scalable framework for user-defined > libraries to add operators to Python, in the same way that they can now > add new classes. I don't want to come to someone else's code and have to learn a bunch of operators that they invented, for the same reason that you don't want to learn all of Perl's built-in special cases. I would support a framework to compile and load well-defined, independent, Python-based languages (PyMatrix, XSLPy) onto a shared Python virtual machine. OTOH, I would freak out if I loaded a module that proported to be Python and found it had a bunch of operators not defined in the Python specification. I'll leave that experiment to REBOL and see what happens. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Fri Jul 14 17:56:54 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 11:56:54 -0500 Subject: [Python-Dev] Request for Opinions References: <200007140516.HAA28633@python.inrialpes.fr> <396EE66F.59D0D45F@prescod.net> <14703.14352.411905.934970@cj42289-a.reston1.va.home.com> Message-ID: <396F4656.6396D7C8@prescod.net> "Fred L. Drake, Jr." wrote: > > I think a PEP and further discussions in the XML-SIG are in order > before we add more material into the standard library. I'm firmly > committed to getting the "right stuff" in there, but I don't want to > rush headlong into adding things before they're ready and agreed > upon. My impression was that we discussed this in the SIG last week but the discussion petered out when we realized that none of us knew whether it was even feasible to add something the size of 4XPath to Python. Nobody could say it would or would not be a problem which makes planning impossible and further discussion a useless cycle of "wouldn't it be nice, but it may or may not be possible, but wouldn't it be nice, but it may or may not be ...". -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From fdrake@beopen.com Fri Jul 14 18:06:43 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 13:06:43 -0400 (EDT) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396F4656.6396D7C8@prescod.net> References: <200007140516.HAA28633@python.inrialpes.fr> <396EE66F.59D0D45F@prescod.net> <14703.14352.411905.934970@cj42289-a.reston1.va.home.com> <396F4656.6396D7C8@prescod.net> Message-ID: <14703.18595.926991.596182@cj42289-a.reston1.va.home.com> Paul Prescod writes: > My impression was that we discussed this in the SIG last week but the > discussion petered out when we realized that none of us knew whether it > was even feasible to add something the size of 4XPath to Python. Nobody > could say it would or would not be a problem which makes planning Then this falls into the "Fred's falling behind on his email again" category, and my remarks can be safely ignored until I've done my homework. Sorry for the confusion. ;( But I still think a PEP documenting the rationale for any decision is valuable. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From huaiyu_zhu@yahoo.com Fri Jul 14 18:11:29 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 10:11:29 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: Message-ID: On Fri, 14 Jul 2000, Ka-Ping Yee wrote: > > You are almost there. :-) The current MatPy expression is > > solve (X.H() * X, X.H() * y) > > I was about to suggest something similar, but you beat me to it. > > I think that expression looks great. If you can say it that > concisely, i don't think you need to throw in extra operators > at all (let alone a half-dozen of them that are incomprehensible > to anyone outside of the Matlab community). Well, the Matlab community includes most scientists and enginears and educators and students of science and engineering who can afford Matlab, or who has enough computer literacy to know how to install Octave (or to install Linux so that Octave comes with it). Many are learning Linux just for this purpose alone. At least several of my former students did. Back to topic. Here's the quote from my c.l.py post: This is not a call for a special language for matrix only. But we do need enough binary operators to override with. The additional operators might be useful at other places as well. In matlab the following operations are all different from each other a+b a.+b a-b a.-b a*b a.*b a/b a./b a\b a.\b a^b a.^b What python operators can we override for them all? Just one additional symbol for so many new binary operators is a good bargain, IMO. I think cleanness is one of the main virtue of python, but it is lacking in numerical computation. To give an example of the difference it makes, I'll quote from my original post asking for matrix in python (with corrections) [example of matlab and python codes you've seen. end quote] So why do we need new operators? Because we are using * as matrixmultiply so we need .* as elementwise multiply. From esr@thyrsus.com Fri Jul 14 18:36:20 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 13:36:20 -0400 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: ; from huaiyu_zhu@yahoo.com on Fri, Jul 14, 2000 at 10:11:29AM -0700 References: Message-ID: <20000714133620.A10054@thyrsus.com> Huaiyu Zhu : > This is not a call for a special language for matrix only. But we do need > enough binary operators to override with. The additional operators might be > useful at other places as well. > > In matlab the following operations are all different from each other > > a+b a.+b > a-b a.-b > a*b a.*b > a/b a./b > a\b a.\b > a^b a.^b > > What python operators can we override for them all? Just one additional > symbol for so many new binary operators is a good bargain, IMO. Put this way, I'm more inclined to support it. I might even be tempted to add .| and .& for lattice algebras. I agree that supporting user-defined syntax threatens to fragment the language. To avoid that, perhaps it would be best to leave what are in effect user-definable hooks in Python's lexical space. This could address Greg's desire for an infix max and min as well. The design question becomes: what undefined binary tokens do we want to add the the language core? With what precedence? What is the compiler to assume about associativity? -- Eric S. Raymond Ideology, politics and journalism, which luxuriate in failure, are impotent in the face of hope and joy. -- P. J. O'Rourke From Fredrik Lundh" Message-ID: <036101bfedba$048fdbe0$f2a6b5d4@hagrid> before this goes out of hand, let me just say that there might be good reasons for adding more operators for Python, but your "why cannot I have special syntax when everyone else got it" approach doesn't really work: > What does this mean? >=20 > s =3D 1.2; g =3D 4.4; t =3D 6. > a =3D s/2 + t/3 + 1/g >=20 > Ah, that means a is the operation that globally substitute '2' = followed by > one or more space followed by ' t' with string '3 + 1'. :-) huh? Python doesn't support the s/// syntax (you're thinking about Perl or awk, right?) ...and: > a\b a.\b huh? Python doesn't have a backslash operator. ...and: > Look it this way. Text processing do have their special syntaxes. A = string > is written as "string" instead of ['s','t','r','i','n','g']. huh? Python doesn't have a character type (C, C++) > There is even the new sep.join(list). huh? that's a method call, not special syntax... > If we had requested that new syntax for Fourier analysis or fractal > generation that would be comparable to text processing or COM. huh? Python doesn't have special syntax for text processing (Perl, Icon) or COM (C#, Visual Basic) if you cannot get your Python facts right, why should I trust you when you say that "Python needs this or that"? From Fredrik Lundh" <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> Message-ID: <038101bfedbc$983c81c0$f2a6b5d4@hagrid> guido wrote: > Need some more analysis of what format codes are actually used, > and support for %.200s which is currently used often. possibly stupid idea: would it make sense to add custom formatting codes, like: %S =3D> char*, string, clip if excessively long %T =3D> PyObject*, show name of type, clip if excessively long where "clip" means: truncate at 80 characters, and add "..." to indicate that the string was truncated. this covers most of the places where %.\d+s are used (in the Python core, at least...) From gvwilson@nevex.com Fri Jul 14 18:48:50 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 13:48:50 -0400 (EDT) Subject: [Python-Dev] Re: linear algebra In-Reply-To: <396F4509.30069096@prescod.net> Message-ID: > > Greg Wilson wrote: > > > > .... Saying, "But you don't have to use these new operators if > > you don't want to," is a red herring --- if I want to understand/modify > > other people's code, I'll have to learn 'em (just as I've had to learn > > most of Perl's syntax, one painful special case at a time, in order to use > > the LDAP, XML, CGI, and imaging libraries). > > > > So: I would like this (linear algebra, min/max, other notation) to happen, > > but only if there's an extensible, scalable framework for user-defined > > libraries to add operators to Python, in the same way that they can now > > add new classes. > Paul Prescod wrote: > > I don't want to come to someone else's code and have to learn a bunch > of operators that they invented, for the same reason that you don't > want to learn all of Perl's built-in special cases. Greg Wilson writes: I strongly agree. If there isn't a "new operator definition" mechanism that maintains Python's simplicity, then I believe we should stick to functions and methods, rather than introducing "just a few" new operators for linear algebra (or regular expressions, or [your favorite topic goes here]). > Eric Raymond wrote: > > I agree that supporting user-defined syntax threatens to fragment the > language. To avoid that, perhaps it would be best to leave what are in > effect user-definable hooks in Python's lexical space. > > The design question becomes: what undefined binary tokens do we want > to add the the language core? With what precedence? What is the > compiler to assume about associativity? This is an interesting alternative I hadn't thought of --- add operators, with associated special methods and in-place assignment forms, but do not provide a "standard" definition (i.e. leave all functionality open to the user). Thanks, Greg From paul@prescod.net Fri Jul 14 19:02:09 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 13:02:09 -0500 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: <20000714133620.A10054@thyrsus.com> Message-ID: <396F55A1.10828D06@prescod.net> "Eric S. Raymond" wrote: > > ... > > I agree that supporting user-defined syntax threatens to fragment the language. > To avoid that, perhaps it would be best to leave what are in effect > user-definable hooks in Python's lexical space. I really don't see how it is better to fragment the semantic space by encouraging people to project random meanings onto operators with no intrinsic meanings. Given the choice, I would prefer to have the language explicitly fragment into domain-specific variants with their own grammars. At least then I know that I'm really dealing with a new language that is Pythonic, but not Python. DTML, a Python XSL and this matrix Python are examples of languages that might benefit from an easy way to be hosted on the Python VM and interact with pure Python modules. Also a statically typed Python variant might be intersting. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From akuchlin@mems-exchange.org Fri Jul 14 19:02:36 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 14 Jul 2000 14:02:36 -0400 Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: <20000714133620.A10054@thyrsus.com>; from esr@thyrsus.com on Fri, Jul 14, 2000 at 01:36:20PM -0400 References: <20000714133620.A10054@thyrsus.com> Message-ID: <20000714140236.H28819@kronos.cnri.reston.va.us> On Fri, Jul 14, 2000 at 01:36:20PM -0400, Eric S. Raymond wrote: >Huaiyu Zhu : >> This is not a call for a special language for matrix only. But we do need >> enough binary operators to override with. The additional operators might be >> useful at other places as well. > >I agree that supporting user-defined syntax threatens to fragment the language. >To avoid that, perhaps it would be best to leave what are in effect >user-definable hooks in Python's lexical space. Huaiyu Zhu thinks that better matrix operators will attract a significant new of new users; I'm doubtful of this claim. We're both just guessing, since neither of us has actual evidence to support our respective points of view. Given that uncertainty, there seems little impetus for adding new operators; Python will have to live with them for a long time, even if the matrix work withers after a short time, or never really catches on. It should be possible to try out new operators *right now*, with no core changes. I believe Jeremy's compiler code, written in pure Python, can parse a module and generate the corresponding bytecodes. Therefore, you could take that code and hack it to support 'a .| b', by generating equivalent code to a.__dotbar__(b), or whatever. The only visible difference is that some error messages would be obscure; 2 .| 1 would get a '2 has no attribute __dotbar__' exception; this isn't significant. So, rather than add a whole bunch of new operators to the core, I'd first want to see the alternative syntax implemented through a hacked parser and *in use by a significant community*, and then we can consider what bits from it to add to the core. --amk From esr@thyrsus.com Fri Jul 14 19:47:12 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 14:47:12 -0400 Subject: [Python-Dev] Re: linear algebra In-Reply-To: ; from gvwilson@nevex.com on Fri, Jul 14, 2000 at 01:48:50PM -0400 References: <396F4509.30069096@prescod.net> Message-ID: <20000714144712.A10278@thyrsus.com> Greg Wilson : > This is an interesting alternative I hadn't thought of --- add operators, > with associated special methods and in-place assignment forms, but do not > provide a "standard" definition (i.e. leave all functionality open to the > user). Yes. This steers a Pythonic middle path between user-definable syntax (too big a can of worms) and doing nothing at all to help out constituencies like the MatLab people. Overloading otherwise undefined special method names for operators is a well-understood way to add functionality to classes. Lrt's use it. -- Eric S. Raymond Rapists just *love* unarmed women. And the politicians who disarm them. From jeremy@beopen.com Fri Jul 14 19:40:43 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 14:40:43 -0400 (EDT) Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: <20000714140236.H28819@kronos.cnri.reston.va.us> References: <20000714133620.A10054@thyrsus.com> <20000714140236.H28819@kronos.cnri.reston.va.us> Message-ID: <14703.24235.5194.840166@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> It should be possible to try out new operators *right now*, AMK> with no core changes. I believe Jeremy's compiler code, AMK> written in pure Python, can parse a module and generate the AMK> corresponding bytecodes. Therefore, you could take that code AMK> and hack it to support 'a .| b', by generating equivalent code AMK> to a.__dotbar__(b), or whatever. The only visible difference AMK> is that some error messages would be obscure; 2 .| 1 would get AMK> a '2 has no attribute __dotbar__' exception; this isn't AMK> significant. There is one hitch. There is a corresponding bytecode op for each of the builtin operators. When Python sees 'm * x + b', it generates BINARY_MULTIPLY and BINARY_ADD opcode. If you wanted to add a new binary operator, you couldn't add a new opcode for it. Instead, you'd have to generate explicit instructions to check for the attr and then call it. This isn't a big problem, although the resulting interpreter is probably slower than one with builtin opcodes. Not sure how much slower. AMK> So, rather than add a whole bunch of new operators to the core, AMK> I'd first want to see the alternative syntax implemented AMK> through a hacked parser and *in use by a significant AMK> community*, and then we can consider what bits from it to add AMK> to the core. This seems like a reasonable approach to me. You basically build a frontend that compiles the Python+extensions into standard Python bytecode. Jeremy From Moshe Zadka Fri Jul 14 19:41:27 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 14 Jul 2000 21:41:27 +0300 (IDT) Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: <14703.24235.5194.840166@bitdiddle.concentric.net> Message-ID: On Fri, 14 Jul 2000, Jeremy Hylton wrote: > AMK> So, rather than add a whole bunch of new operators to the core, > AMK> I'd first want to see the alternative syntax implemented > AMK> through a hacked parser and *in use by a significant > AMK> community*, and then we can consider what bits from it to add > AMK> to the core. > > This seems like a reasonable approach to me. You basically build a > frontend that compiles the Python+extensions into standard Python > bytecode. Wouldn't it be better to compile the Python+extensions into standard Python? Something that would work at the parse tree level? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From jeremy@beopen.com Fri Jul 14 19:49:24 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 14:49:24 -0400 (EDT) Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: References: <14703.24235.5194.840166@bitdiddle.concentric.net> Message-ID: <14703.24756.648338.160796@bitdiddle.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> On Fri, 14 Jul 2000, Jeremy Hylton wrote: AMK> So, rather than add a whole bunch of new operators to the core, AMK> I'd first want to see the alternative syntax implemented AMK> through a hacked parser and *in use by a significant AMK> community*, and then we can consider what bits from it to add AMK> to the core. >> This seems like a reasonable approach to me. You basically >> build a frontend that compiles the Python+extensions into >> standard Python bytecode. MZ> Wouldn't it be better to compile the Python+extensions into MZ> standard Python? Something that would work at the parse tree MZ> level? That's a lot of work! I'm not aware of any tools that generate Python source code from a parser tree. The Python bytecode is so high-level that it is pretty easy to understand. The parse tree generated by Python's builtin parser is really hard to work with. So it definitely makes sense to use the transformer that Greg & Bill wrote to get a decent abstract syntax. At that point, you can either generate bytecode directly or write a new code generate that generates source from the AST. Jeremy From alex_c@MIT.EDU Fri Jul 14 21:30:14 2000 From: alex_c@MIT.EDU (Alex Coventry) Date: Fri, 14 Jul 2000 16:30:14 -0400 (EDT) Subject: [Python-Dev] posixpath module. Message-ID: <200007142030.QAA156803@w20-575-116.mit.edu> (Cc'd to python-dev, this time, since you're incommunicado.) I have a preliminary version of test_posixpath.py. You can see it at http://puffin.lcs.mit.edu:8080/Lib/test/test_posixpath.py I don't have any negative tests with garbage input. I'm thinking that that's not so important anyway, because in python programs tend to break with garbage input, but of course I'm really punting mainly out of temporary boredom. :) Should posixpath.normpath resolve '/..' to '/'? My linux box does. Alex. From thomas@xs4all.net Fri Jul 14 21:36:08 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 22:36:08 +0200 Subject: [Python-Dev] posixpath module. In-Reply-To: <200007142030.QAA156803@w20-575-116.mit.edu>; from alex_c@MIT.EDU on Fri, Jul 14, 2000 at 04:30:14PM -0400 References: <200007142030.QAA156803@w20-575-116.mit.edu> Message-ID: <20000714223607.D7340@xs4all.nl> On Fri, Jul 14, 2000 at 04:30:14PM -0400, Alex Coventry wrote: > Should posixpath.normpath resolve '/..' to '/'? My linux box does. Yes. At least, every UNIX box I ever heard of does that, and I'm sure it's listed in some standard or other. (the '.' and '..' directories on UNIX filesystems aren't magic, they are just hard links to the appropriate directory. '..' on '/' simply points to the same directory as '.' on '/', and '/' itself.) I think the same goes for URLs, though I'm not as sure on that. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy@beopen.com Fri Jul 14 21:48:45 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 16:48:45 -0400 (EDT) Subject: [Python-Dev] Patch Manager screen scraper Message-ID: <14703.31917.642280.604366@bitdiddle.concentric.net> --TOjet6/crW Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit I wrote a small script to extract patch meta data from the SourceForge patch manager and install them in a local Postgres database. This code might be useful for other folks, although the second half (the Postgres half) depends on having PyGreSQL installed. I'm posting the current source here in case anyone else wants to fiddle. It's definitely rough. Attached is the code and the DB schema. Jeremy --TOjet6/crW Content-Type: text/plain Content-Description: python script Content-Disposition: inline; filename="patchtool.py" Content-Transfer-Encoding: 7bit """Screen scraper for Patch Manager interface The patch form URL is http://www.sourceforge.net/patch/index.php. GET method If I'm lucky, it can be used without authentication. the input fields are: (* means hidden field) *group_id=5470 *custom=set _assigned_to=None _status=None This script produces the following HTML for each entry: 100518 fix bltinmodule.c for 64-bit platforms 2000-Jun-07 03:21 gvanrossum tmick If there are more than 50 patches, the following HTML is produced:   Next 50 --> Future plans: support authentication command-line interface for modifying patches """ import cgi import re import types from urllib import urlencode from urlparse import urljoin from urllib2 import urlopen import pg VERBOSE = 0 DATABASE = 'jeremy' class PatchListParser: """Minimal re-based parsed that grabs relevant URLs from summary""" rx_href = re.compile('HREF="([?/=&_A-Za-z0-9]+)"') def parse_hrefs(self, buf): hrefs = [] offset = 0 while 1: mo = self.rx_href.search(buf, offset) if mo is None: break offset = mo.end(1) hrefs.append(mo.group(1)) return hrefs def get_query_hrefs(self, buf): queries = [] for href in self.parse_hrefs(buf): if href[0] == '?': queries.append(href) return queries class PatchParser: """Minimal re-based parser that pulls key-values from patch page""" rx_entry = re.compile(']*>(.+):
(.+)') def parse(self, buf): entries = {} offset = 0 while 1: mo = self.rx_entry.search(buf, offset) if mo is None: break offset = mo.end(2) k, v = mo.group(1, 2) entries[k] = v return entries class SQLMapping: """Decode a simple mapping from an SQL table Assumes that the keys and values are disjoint, so that a single interface can resolve in either direction. """ def __init__(self, db, table, fields="*"): self.dict1 = {} self.dict2 = {} r = db.query("SELECT %s FROM %s" % (fields, table)).getresult() for key, val in r: assert None not in (key, val) self.dict1[key] = val self.dict2[val] = key def lookup(self, kv): r = self.dict1.get(kv) if r is None: r = self.dict2.get(kv) return r def urldecode(query): d = cgi.parse_qs(query) for k, v in d.items(): if len(v) != 1: raise ValueError, "unexpected duplicate entry" d[k] = v[0] return d class PatchManager: url = "http://www.sourceforge.net/patch/index.php" group_id = 5470 list_parser = PatchListParser() patch_parser = PatchParser() # XXX to get the right numeric values for assigned_to and status, # would need to scrape them out of the form... def get_patches(self, assigned_to='100', status='100'): assert type(assigned_to) == types.StringType assert type(status) == types.StringType url = self._get_initial_query(assigned_to, status) patch_list = self._load_patch_summary(url) patches = {} for patch_id, p in patch_list: patches[patch_id] = self._load_patch_detail(p) return patches def _get_initial_query(self, assigned_to, status): dict = {'group_id': self.group_id, 'set': 'custom', 'SUBMIT': 'Browse', '_assigned_to': assigned_to, '_status': status, } query = urlencode(dict) return "%s?%s" % (self.url, query) def _load_patch_summary(self, url): todo = [(url, 0)] patches = [] offset = 0 while todo: url, offset = todo[0] del todo[0] buf = urlopen(url).read() for href in self.list_parser.get_query_hrefs(buf): d = urldecode(href[1:]) if d['func'] == 'detailpatch': patches.append((int(d['patch_id']), urljoin(self.url, href))) elif d['func'] == 'browse': new_offset = int(d['offset']) if new_offset > offset: todo.append((urljoin(self.url, href), new_offset)) return patches def _load_patch_detail(self, url): buf = urlopen(url).read() return self.patch_parser.parse(buf) class PatchDBInterface: """Interface between the PatchManager and the SQL database Scheme for the patches table is: CREATE TABLE patches_t ( patch_id int PRIMARY KEY, summary text, status int REFERENCES status_t, category text, date text, submitted_by int REFERENCES users_t, assigned_to int REFERENCES users_t, summary_url text ); """ def __init__(self, db): self.db = db self.users = SQLMapping(db, 'users_t') self.status = SQLMapping(db, 'status_t') self.num_deletes = 0 def update(self, patch_id, attrs): # resolve REFERENCES status = self.status.lookup(attrs['Status']) submitted_by = self.users.lookup(attrs['Submitted By']) if submitted_by is None: submitted_by = 0 assigned_to = self.users.lookup(attrs['Assigned To']) if assigned_to is None: assigned_to = 100 # delete old version if necessary if self.has_patch(patch_id): q = "DELETE FROM patches_t WHERE patch_id = %(patch_id)d" self.db.query(q % locals()) self.num_deletes = self.num_deletes + 1 d = locals() del d['attrs'] # just to make debugging prints clearer for k, v in attrs.items(): d[k] = pg._quote(v, 0) q = "INSERT INTO patches_t VALUES (%(patch_id)d," \ " %(Summary)s, %(status)d, %(Category)s, %(Date)s," \ " %(submitted_by)d, %(assigned_to)d)" self.db.query(q % d) def has_patch(self, patch_id): r = self.db.query("SELECT * FROM patches_t" \ " WHERE patch_id = %d" % patch_id).getresult() if r: return 1 else: return 0 if __name__ == "__main__": import sys import getopt opts, args = getopt.getopt(sys.argv[1:], 'vd:') assert len(args) == 0 for k, v in opts: if k == '-v': VERBOSE = 1 elif k == '-d': DATABASE = v pmgr = PatchManager() if VERBOSE: print "Loading patches" p = pmgr.get_patches() if VERBOSE: print "Retrieved %d patches" % len(p) if VERBOSE: print "Inserting into local database" db = pg.connect(DATABASE) pdbi = PatchDBInterface(db) for p_id, attrs in p.items(): pdbi.update(p_id, attrs) if VERBOSE: new = len(p) - pdbi.num_deletes print "Found %d new patches" % new print "Updated %d existing patches" % pdbi.num_deletes --TOjet6/crW Content-Type: text/plain Content-Description: database schema Content-Disposition: inline; filename="patch-schema.txt" Content-Transfer-Encoding: 7bit CREATE TABLE users_t ( user_id int PRIMARY KEY, username text NOT NULL ); CREATE TABLE status_t ( status_id int PRIMARY KEY, name text NOT NULL ); CREATE TABLE patches_t ( patch_id int PRIMARY KEY, summary text, status int REFERENCES status_t, category text, date text, submitted_by int REFERENCES users_t, assigned_to int REFERENCES users_t, summary_url text ); --TOjet6/crW-- From paul@prescod.net Fri Jul 14 21:56:52 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 15:56:52 -0500 Subject: [Python-Dev] posixpath module. References: <200007142030.QAA156803@w20-575-116.mit.edu> Message-ID: <396F7E94.FF4D4C0B@prescod.net> Alex Coventry wrote: > > (Cc'd to python-dev, this time, since you're incommunicado.) Skip is having computer problems. Lost computer problems. :) -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Fredrik Lundh" <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> <02c701bfedae$7db6fd20$f2a6b5d4@hagrid> Message-ID: <000d01bfedd7$122db480$f2a6b5d4@hagrid> > patch coming. not quite ready to be checked in, but good enough to take on a test drive: http://sourceforge.net/patch/?func=3Ddetailpatch&patch_id=3D100895&group_= id=3D5470 From gstein@lyra.org Fri Jul 14 22:18:02 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 14:18:02 -0700 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007141714.MAA14470@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 12:14:44PM -0500 References: <396E0B9B.DD74EF5@interet.com> <200007141437.JAA13178@cj20424-a.reston1.va.home.com> <01b201bfedac$12353d20$f2a6b5d4@hagrid> <200007141714.MAA14470@cj20424-a.reston1.va.home.com> Message-ID: <20000714141801.T29590@lyra.org> On Fri, Jul 14, 2000 at 12:14:44PM -0500, Guido van Rossum wrote: > > > Ignoring most that's been said in this thread, would it be possible > > > for the installer to detect the presence of python15.dll in the system > > > directory and offer to delete it? > > > > would the average user know when to click "Yes" ? > > Whenever they don't have a 1.5 installation that they are interested > in preserving. Hm, the registry probably points to where that would > live if it existed, so the installer (or a custom program run > automatically by it) can do more probing if it needs to. Who says they have a 1.5 installation on their system? Maybe the DLL arrived through some third-party application that happens to use/embed Python. Any python*.dll probably should be ignored. Cheers, -g -- Greg Stein, http://www.lyra.org/ From huaiyu_zhu@yahoo.com Fri Jul 14 22:28:09 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 14:28:09 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <036101bfedba$048fdbe0$f2a6b5d4@hagrid> Message-ID: On Fri, 14 Jul 2000, Fredrik Lundh wrote: > before this goes out of hand, let me just say that there might be good > reasons for adding more operators for Python, but your "why cannot I > have special syntax when everyone else got it" approach doesn't really > work: > Well, these quotings are getting out of hand. Please read the c.l.py thread and see where all this comes from. My posts have been repeatedly forwarded here out of context. Note that the (X'*X)\(X'*y) syntax is Matlab, not python. I mentioned text processing and COM because it was claimed that requesting additional binary operators for matrix is similar to requesting special syntax for text processing and COM. I have repeatedly stated here and elsewhere, that I do NOT want special syntax. I only want a few more binary operators that bear resemblance to the existing ones. I want them in such a way that as long as you do not use them, NOTHING would be changed. However several people continuously said: you cannot get that because that's too much of a request, however you should get your own complete parser so that you can make any syntax as you want, even if it is incompatible. I find this very strange. Maybe the audience here do not appreciate it, but "matrix people" are not some aliens, and matrix computation need to be compatible with everything else in python. If I'm only going to do matrix but nothing else, why wouldn't I just stick with octave? > if you cannot get your Python facts right, why should I trust you > when you say that "Python needs this or that"? Maybe if you read all the original posts you would find these "wrong facts" just disappears. You might also find that many people did not get the fact right about what is being asked in these threads. One sure way to get the facts right is to get MatPy, unar, type make install, and see what you get. It's not that difficult, at least easier than writing these emails. Huaiyu -- Huaiyu Zhu hzhu@users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net From huaiyu_zhu@yahoo.com Fri Jul 14 23:04:52 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 15:04:52 -0700 (PDT) Subject: [Fwd: Re: [Python-Dev] Introducing new operators for matrix computation] In-Reply-To: <396F5819.D3C20E40@prescod.net> Message-ID: I like this idea as well. I only need to clarify two things: 1. Is this available right now? Where to get it? 2. Will this be guaranteed to be compatible with future development of python? My doubt is: If this is the case why the augmented assinment needs to be a patch? The development of MatPy has been quite rapid since it started over a month ago. Right now we are ready to go into feature addition phase that will be even faster. The only uncertainty is what operators we will have. We got our own patch yesterday. We'd like to settle on this very quickly. Once these are settled, we'll just included it in the MatPy distribution. After we get enough usage the whole NumPy-MatPy packages might be included in core python just as string or re. Given that there is a conference next week, perhaps we can't fix it in a week. But we'll decide soon after that. I will not argue any more here about how many new users python may attract with matrix. With proper tools I would be able to prove by fact. Although we seek the core developer opinions here, we do not really need approval to go ahead. But the danger is that a bad choice may stuck with python for ever when this thing gets incorporated into main distribution. Switching the meaning of the operators would be almost completely impossible, unlike the regex and re case. So even if you don't make use of matrix now, you might still want to give a thought on how it should be done. Huaiyu On Fri, 14 Jul 2000, Paul Prescod wrote: > I like this idea! > > -------- Original Message -------- > Subject: Re: [Python-Dev] Introducing new operators for matrix > computation > Date: Fri, 14 Jul 2000 14:02:36 -0400 > From: Andrew Kuchling > Reply-To: akuchlin@mems-exchange.org > To: python-dev@python.org > References: > > <20000714133620.A10054@thyrsus.com> > > On Fri, Jul 14, 2000 at 01:36:20PM -0400, Eric S. Raymond wrote: > >Huaiyu Zhu : > >> This is not a call for a special language for matrix only. But we do need > >> enough binary operators to override with. The additional operators might be > >> useful at other places as well. > > > >I agree that supporting user-defined syntax threatens to fragment the language. > >To avoid that, perhaps it would be best to leave what are in effect > >user-definable hooks in Python's lexical space. > > Huaiyu Zhu thinks that better matrix operators will attract a > significant new of new users; I'm doubtful of this claim. We're both > just guessing, since neither of us has actual evidence to support our > respective points of view. Given that uncertainty, there seems little > impetus for adding new operators; Python will have to live with them > for a long time, even if the matrix work withers after a short time, > or never really catches on. > > It should be possible to try out new operators *right now*, with no > core changes. I believe Jeremy's compiler code, written in pure > Python, can parse a module and generate the corresponding bytecodes. > Therefore, you could take that code and hack it to support 'a .| b', > by generating equivalent code to a.__dotbar__(b), or whatever. The > only visible difference is that some error messages would be obscure; > 2 .| 1 would get a '2 has no attribute __dotbar__' exception; this > isn't significant. > > So, rather than add a whole bunch of new operators to the core, I'd > first want to see the alternative syntax implemented through a hacked > parser and *in use by a significant community*, and then we can > consider what bits from it to add to the core. > > --amk > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev > From alex_c@MIT.EDU Fri Jul 14 23:08:39 2000 From: alex_c@MIT.EDU (Alex Coventry) Date: Fri, 14 Jul 2000 18:08:39 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <396F7E94.FF4D4C0B@prescod.net> (message from Paul Prescod on Fri, 14 Jul 2000 15:56:52 -0500) References: <200007142030.QAA156803@w20-575-116.mit.edu> <396F7E94.FF4D4C0B@prescod.net> Message-ID: <200007142208.SAA157802@w20-575-116.mit.edu> > Skip is having computer problems. Lost computer problems. :) Yeah, sorry, that's what I meant. :) Alex. From fdrake@beopen.com Fri Jul 14 23:26:49 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 18:26:49 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <200007142030.QAA156803@w20-575-116.mit.edu> References: <200007142030.QAA156803@w20-575-116.mit.edu> Message-ID: <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> Alex Coventry writes: > I don't have any negative tests with garbage input. I'm thinking that > that's not so important anyway, because in python programs tend to break > with garbage input, but of course I'm really punting mainly out of > temporary boredom. :) If an exception is expected, it should test that it gets the right failure. This is especially important in a regression test, so that failing cases don't silently becoming non-failing cases. > Should posixpath.normpath resolve '/..' to '/'? My linux box does. I don't understand; in what context? "/" on my box contains "..", which is itself. There's nothing special about it in the "path algebra," but it may be a useful reduction. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From huaiyu_zhu@yahoo.com Fri Jul 14 23:44:20 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 15:44:20 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <20000714133620.A10054@thyrsus.com> Message-ID: On Fri, 14 Jul 2000, Eric S. Raymond wrote: > Huaiyu Zhu : > > This is not a call for a special language for matrix only. But we do need > > enough binary operators to override with. The additional operators > > might be useful at other places as well. > > > > In matlab the following operations are all different from each other > > > > a+b a.+b > > a-b a.-b > > a*b a.*b > > a/b a./b > > a\b a.\b > > a^b a.^b > > > > What python operators can we override for them all? Just one additional > > symbol for so many new binary operators is a good bargain, IMO. > > Put this way, I'm more inclined to support it. I might even be tempted > to add .| and .& for lattice algebras. > > I agree that supporting user-defined syntax threatens to fragment the > language. To avoid that, perhaps it would be best to leave what are in > effect user-definable hooks in Python's lexical space. Completely agree. That's what the issue is about. More information is given below in my quote from c.l.p. > This could address Greg's desire for an infix max and min as well. > > The design question becomes: what undefined binary tokens do we > want to add the the language core? With what precedence? What is > the compiler to assume about associativity? Given what's quoted below, would you think . is the best choice? Not to say its attractiveness to all the matlab crowd. ------------------------ start quote ----------------------------- On Thu, 13 Jul 2000 16:35:57 -0600, Bjorn Pettersen wrote: >I fully understand your desire to make the syntax for your domain >specific notation as intuitive as possible. For people who don't know >matlab however, .+ et. al. have no pre-defined meaning. Since + has a >predefined meaning of addition, most people when overloading it will do >"additive" things with it, e.g. concatenating to sequences. Since .+ >doesn't have a pre-defined meaning I'm afraid people will override it >with random semantics... > >If you want to do matlab syntax, perhaps a better approach would be to >write your own expression parser? > Hmm, I see what you mean: If a certain syntax is not meaningful to all the users, don't expose it to all of them lest they came up with random incompatible usages. Sounds reasonable, but ... Point 1. We _can_ assign a universal meaning to dot operators, as "componentwise operators". For example [1, 2] + [3, 4] # [1, 2, 3, 4] [1, 2] .+ [3, 4] # [4, 6] ['a','b'] * 2 # ['a','b','a','b'] ["a","b"] .* 2 # ['aa', 'bb'] {'a':1, 'b':1} .+ {'a':1, 'c':1} # {'a':2, 'b':1, 'c': 1} 'abc' .+ 'def' # exception: you must define string.__dot_add__ This could be useful in all sorts of situations. Of course people can still override it with incompatible meanings at their own discretion, just as they could do to anything else. Point 2. If users in completely disjoint domains override a certain type of binary operators with incompatible meanings, is there great harm? Providing a few operators for user adoptation might even prevent grotesque overriding of more core operators. After all, there is almost endless supply of names for classes, modules, function and so on, but there is almost no binary operators free for adoption. Point 3. A special parser could work, (and if the patch under discussion is not accepted we'll just keep it around for use with matrix computation), as long as it is made quite orthogonal to other parts of the language. This way people using it will not be left behind other developments of the language. However, I still think a unified parser with overridable operators present a smaller risk of fragmentation. Huaiyu From alex_c@MIT.EDU Fri Jul 14 23:42:49 2000 From: alex_c@MIT.EDU (Alex Coventry) Date: Fri, 14 Jul 2000 18:42:49 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> (fdrake@beopen.com) References: <200007142030.QAA156803@w20-575-116.mit.edu> <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> Message-ID: <200007142242.SAA12205@mint-square.mit.edu> > If an exception is expected, it should test that it gets the right > failure. This is especially important in a regression test, so that > failing cases don't silently becoming non-failing cases. You're right, of course. I'll get back to them at some point. > in what context? "/" on my box contains "..", which is itself. > There's nothing special about it in the "path algebra," but it may > be a useful reduction. For instance: >>> import posixpath >>> posixpath.normpath('/..') '/..' I would have thought '/' would be a better result to return. My impression was that normpath is used to tell whether two paths are actually the same, and if that's the case, its current behaviour is going to give false negatives. On the other hand, the code seems to explicitly ignore multiple leading /'s, and that will also give some false mismatches, so I must be confused somewhere... Alex. From Fredrik Lundh" Message-ID: <000901bfede8$2d0103a0$f2a6b5d4@hagrid> Huaiyu Zhu wrote: > Given what's quoted below, would you think . is the best choice? if what you're saying means that: >>> 1.+2. 3.0 becomes: >>> 1.+2. Traceback (innermost last): File "", line 1, in ? TypeError: __dotadd__ nor __rdotadd__ defined for these operands it's clearly not a good choice. From huaiyu_zhu@yahoo.com Sat Jul 15 00:33:13 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 16:33:13 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <000901bfede8$2d0103a0$f2a6b5d4@hagrid> Message-ID: On Sat, 15 Jul 2000, Fredrik Lundh wrote: > Huaiyu Zhu wrote: > > Given what's quoted below, would you think . is the best choice? > > if what you're saying means that: > > >>> 1.+2. > 3.0 > > becomes: > > >>> 1.+2. > Traceback (innermost last): > File "", line 1, in ? > TypeError: __dotadd__ nor __rdotadd__ defined for these operands > > it's clearly not a good choice. > > > To quote from my c.l.py post: On Fri, 14 Jul 2000 11:38:51 -0600, Bjorn Pettersen wrote: > >Well, this could actually be generally useful, but not with the .+ >syntax (since the dot would interfer with methods on the sequence >object). My impression from the python-dev list is that this is not the case. Some say it is easy to distinguish a. + b a .+ b Some say it is difficult. But the first is a syntax error anyway. The only real danger is 3. + a 3 .+ a But in this case pointwise operation does not make sense. So I suppose the following rules would resolve all the ambiguities: Dot binds with preceding number. Otherwise it binds with following operator. Otherwise it is a member indicator. Otherwise it is syntax error. Examples: 2.+b a.+b <-- only this is new a.b a.3 Huaiyu From fdrake@beopen.com Sat Jul 15 00:52:50 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 19:52:50 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <200007142242.SAA12205@mint-square.mit.edu> References: <200007142030.QAA156803@w20-575-116.mit.edu> <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> <200007142242.SAA12205@mint-square.mit.edu> Message-ID: <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> Alex Coventry writes: > I would have thought '/' would be a better result to return. My I agree, feel free to propose a patch! > impression was that normpath is used to tell whether two paths are > actually the same, and if that's the case, its current behaviour is > going to give false negatives. On the other hand, the code seems to > explicitly ignore multiple leading /'s, and that will also give some > false mismatches, so I must be confused somewhere... I'd call that a bug until someone can justify the current behavior. I'd love to see a patch for that as well. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From huaiyu_zhu@yahoo.com Sat Jul 15 01:09:20 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 17:09:20 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <036101bfedba$048fdbe0$f2a6b5d4@hagrid> Message-ID: On Fri, 14 Jul 2000, Fredrik Lundh wrote: > > is written as "string" instead of ['s','t','r','i','n','g']. > > huh? Python doesn't have a character type (C, C++) Likewise, matlab doesn't have a number type, only matrices. Generalization from number to matrix is definitely a smaller step than generalization from character to string. Matrix is more suitable for a builtin type than complex number is, because it is conceptually much simpler. The whole field of linear algebra is built on eight statements, two of them can be derived from the other. You can't even define all the concepts like upper or lower case, white space, tab, symbol, character and number and identifier and concatenation and so on in just eight statements, let alone to state all the rules of text processing. The issue arises because one generalization is more familiar to one group of people but the other is to other people. And people tend to regard what they are not familiar with as "specific domain". Huaiyu From Moshe Zadka Sat Jul 15 01:43:42 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 15 Jul 2000 03:43:42 +0300 (IDT) Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: <14703.24756.648338.160796@bitdiddle.concentric.net> Message-ID: On Fri, 14 Jul 2000, Jeremy Hylton wrote: > I'm not aware of any tools that generate Python > source code from a parser tree. Sounds like an interesting project. Hmmmm....another item on the todo list. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From HZhu@knowledgetrack.com Sat Jul 15 02:42:11 2000 From: HZhu@knowledgetrack.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 18:42:11 -0700 (PDT) Subject: [Python-Dev] List comprehension syntax Message-ID: I just read the whole thread on list comprehension. Here's my proposed syntax, given by examples. This notation is very safe as it has been used in mathematics for years. a = [1, 2, 3]; b = [4, 5, 6] #---------------------------------------------------- # Parallel loops: c = tuples(a,b) # c = [(1,4), (2,5), (3,6)] c = lists(a,b) # c = [[1,4], [2,5], [3,6]] c = xtuples(a,b) # c = ((1,4), (2,5), (3,6)) c = xlists(a,b) # c = ([1,4], [2,5], [3,6]) #---------------------------------------------------- # prefix x has the same effect as in xrange in loops for pair in xtuples(a,b): print pair # print (1,4); print (2,5); print (3,6) for pair in xtuples(a,b): print pair # print [1,4]; print [2,5]; print [3,6] for i, j in xlists(a,b): pass #---------------------------------------------------- # list comprehension - all elements that satisfy conditions c = [x*2, y: x, y in xtuples(a,b)] # c = [(2,4), (4,5), (6,6)] c = [[x, y]: x, y in xtuples(a,b)] # c = [[1,4], [2,5], [3,6]] c = [x: x in a+b; x%2=0] # c = [2, 4, 6] c = [x in a+b: x%2=0] # ditto c = [x,y: x, y in xtuples(a,b); x>1; x+y<8] # c = [(2,5)] c = [x,y in xtuples(a,b): x>1; x+y<8] # ditto #---------------------------------------------------- # Corresponding to old syntax c = [x in a: f(x)] # c = filter(f, x) c = [f(x): x in a] # c = map(f, a) #---------------------------------------------------- # Iterated loops (all elements that satisfy condition): c = [x, y: x in a; y in b] # c = [(1,4), (1,5), (1,6), (2,4), (2,5), ...] c = [[x,y]: x in a; y in b] # c = [[1,4], [1,5], [1,6], [2,4], [2,5], ...] for i, j in [i, j: i in a; j in b]: print i, j # print 1,4; print 1,5; ... for i in a; j in b: print i, j # ditto -- Huaiyu Zhu hzhu@users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net From Fredrik Lundh" Message-ID: <001e01bfee39$2b738200$f2a6b5d4@hagrid> Huaiyu Zhu wrote: > The only real danger is=20 >=20 > 3. + a > 3 .+ a >=20 > But in this case pointwise operation does not make sense.=20 really? what if "a" is a froob? class froob: def __add__(self, other): return other + 1.0 def __dotadd__(self, other): return other + 1.0 >>> a =3D froob() >>> print 3+a() 4.0 >>> print 3.+a() SyntaxError: sorry, that doesn't make sense. try inserting a space. >>> print 3. + a() 4.0 >>> print 3.0+a() 4.0 From Fredrik Lundh" Message-ID: <004101bfee39$aa2d3820$f2a6b5d4@hagrid> moshe wrote: =20 > Jeremy: >=20 > > I'm not aware of any tools that generate Python > > source code from a parser tree. >=20 > Sounds like an interesting project. Hmmmm....another item on the todo > list. http://bicyclerepair.sourceforge.net/ From huaiyu_zhu@yahoo.com Sat Jul 15 10:54:13 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Sat, 15 Jul 2000 02:54:13 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <001e01bfee39$2b738200$f2a6b5d4@hagrid> Message-ID: On Sat, 15 Jul 2000, Fredrik Lundh wrote: > > The only real danger is > > > > 3. + a > > 3 .+ a > > > > But in this case pointwise operation does not make sense. > > really? what if "a" is a froob? Really. Because 3 is a single point. It doesn't matter what a is. > >>> print 3.+a() > SyntaxError: sorry, that doesn't make sense. try inserting a space. Why isn't this 3. + a()? Hmm, I can see my bad habit of writing long posts so that they are often quoted only partially. Here's the missing half: So I suppose the following rules would resolve all the ambiguities: Dot binds with preceding number. Otherwise it binds with following operator. Otherwise it is a member indicator. Otherwise it is syntax error. Examples: 2.+b a.+b <-- only this is new a.b a.3 Huaiyu From Fredrik Lundh" Message-ID: <007e01bfee45$1a581ec0$f2a6b5d4@hagrid> > On Sat, 15 Jul 2000, Fredrik Lundh wrote: >=20 > > > The only real danger is=20 > > >=20 > > > 3. + a > > > 3 .+ a > > >=20 > > > But in this case pointwise operation does not make sense.=20 > >=20 > > really? what if "a" is a froob? >=20 > Really. Because 3 is a single point. It doesn't matter what a is. you're inventing an entirely new language here. > > >>> print 3.+a() > > SyntaxError: sorry, that doesn't make sense. try inserting a = space. >=20 > Why isn't this 3. + a()? yeah, why? the answer is in the python documentation. > Hmm, I can see my bad habit of writing long posts so that they are = often > quoted only partially. Here's the missing half: sure, I read the missing half. doesn't change a thing. please move further discussion to comp.lang.python. this discussion doesn't belong on python-dev. From paul@prescod.net Sat Jul 15 12:00:58 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 06:00:58 -0500 Subject: [Python-Dev] Re: linear algebra References: <396F4509.30069096@prescod.net> <20000714144712.A10278@thyrsus.com> Message-ID: <3970446A.318FDF4E@prescod.net> "Eric S. Raymond" wrote: > > ... > > > Overloading otherwise undefined special method names for operators is > a well-understood way to add functionality to classes. Lrt's use it. I don't know why you think that this is well-understood. Nevertheless, let's propose we add some fixed list of operators: .+ .* ./ .\ Would you propose that: "abc" .+ "c" => "abc".find( "c") "def" .* ".e." => re.match( "def", ".e." ) " " / ["a","b","c","d","e"] => " ".join( [...] ) "a b c" .\ " " => "a b c d e".split( " " ) To me, these bindings look like the kind of things I'd expect in P3rL, because the relationship between the syntax and the behavior is mostly random. In other words, you can't just invent a bunch of operators and THEN figure out how they are going to be used in various domains. You need to invent the operators *for* the domains. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Fredrik Lundh" <20000714144712.A10278@thyrsus.com> <3970446A.318FDF4E@prescod.net> Message-ID: <000701bfee4f$01960820$f2a6b5d4@hagrid> paul wrote: > To me, these bindings look like the kind of things I'd expect in P3rL, > because the relationship between the syntax and the behavior is mostly > random. I saw cout being shifted "Hello world" times to the left and stopped right there. -- Steve Gonedes (which is the last I'm going to say on this topic. at least in public; I'll save the "over my dead body" stuff for guido's private mailbox). cheers /F From gstein@lyra.org Sat Jul 15 12:22:38 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 15 Jul 2000 04:22:38 -0700 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <007e01bfee45$1a581ec0$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jul 15, 2000 at 12:11:53PM +0200 References: <007e01bfee45$1a581ec0$f2a6b5d4@hagrid> Message-ID: <20000715042238.K29590@lyra.org> On Sat, Jul 15, 2000 at 12:11:53PM +0200, Fredrik Lundh wrote: >... > please move further discussion to comp.lang.python. this > discussion doesn't belong on python-dev. Fredrik -- I've been reading your notes a bit, and you're being antagonistic, belligerent, and unfair. I'm not sure it is called for. As for the discussion being here? It isn't his fault. Somebody *else* brought it here, and he is merely trying to respond to the questions and concerns that have been brought up in this forum. I think he has got every right to do that. You should chill out and back off. Cheers, -g -- Greg Stein, http://www.lyra.org/ From martin@loewis.home.cs.tu-berlin.de Sat Jul 15 13:32:59 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 15 Jul 2000 14:32:59 +0200 Subject: [Python-Dev] request for minor enhancement / linear algebra Message-ID: <200007151232.OAA18450@loewis.home.cs.tu-berlin.de> > I got there by working backwards to make things consistent. I want > overloadable '__min__' and 'min=', and everything else that has > these forms is binary infix (I think). If min was overloadable, it would fall in the same category as cmp, divmod, getattr, hasattr, hash, hex, int, len, long, oct, pow, repr, setattr, str the category being "overloadable builtins". Of those, cmp, divmod, getattr, hasattr, pow and setattr take more than one argument. divmod and pow are truly binary in the sense that both __foo__ and __rfoo__ are tried. So if min was overloadable, there would be no need for it being infix; it should attempt both __min__ and __rmin__, though. Actually, it shouldn't - instead, it should invoke __min__ on every argument. > '+', '*', and the bitwise operators are equally variadic --- is > confusion avoided by using punctuation for the infix binary form, > and a named function for the general form? An infix operator, by nature, cannot be variadic. 1+2+3 is not a single operation returning 6, but two operation invocations. Likewise, >>> import operator >>> operator.add(1,2,3) Traceback (most recent call last): File "", line 1, in ? TypeError: function requires exactly 2 arguments; 3 given Unlike that, min(1,2,3) *is* an atomic operation. If it was overloadable, I would *not* expect that first __min__(1,2) is computed, and then __min__(1,3). Instead, I'd expect it to be done as a whole. Now, the question is: if the first argument does not provide __min__, how exactly should __min__ be invoked on the other arguments? One solution would be that min(a,b,c) does a.__min__([a,b,c]) b.__min__([a,b,c]) c.__min__([a,b,c]) Regards, Martin From Fredrik Lundh" as tim pointed out in an earlier thread (on SRE), the \xnn escape code is something of a kludge. I just noted that the unicode string type supports \x as well as \u, with slightly different semantics: \u -- exactly four hexadecimal characters are read. \x -- 1 or more hexadecimal characters are read, and the result is casted to a Py_UNICODE character. I'm pretty sure this is an optimal design, but I'm not sure how it should be changed: 1. treat \x as a hexadecimal byte, not a hexadecimal character. or in other words, make sure that ord("\xabcd") =3D=3D ord(u"\xabcd") fwiw, this is how it's done in SRE's parser (see the python-dev archives for more background). 2. ignore \x. after all, \u is much cleaner. u"\xabcd" =3D=3D "\\xabcd" u"\u0061" =3D=3D "\x61" =3D=3D "\x0061" =3D=3D "\x00000061" 3. treat \x as an encoding error. 4. read no more than 4 characters. (a comment in the code says that \x reads 0-4 characters, but the code doesn't match that comment) u"\x0061bcd" =3D=3D "abcd" 5. leave it as it is (just fix the comment). comments? From Fredrik Lundh" with the locale aware encoding mechanisms switched off (sys.getdefaultencoding() =3D=3D "ascii"), I stumbled upon some interesting behaviour: first something that makes sense: >>> u"abc" =3D=3D "abc" 1 >>> u"=E5=E4=F6" =3D=3D "abc" 0 but how about this one: >>> u"abc" =3D=3D "=E5=E4=F6" Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII decoding error: ordinal not in range(128) or this one: >>> u"=E5=E4=F6" =3D=3D "=E5=E4=F6" Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII decoding error: ordinal not in range(128) ignoring implementation details for a moment, is this really the best we can do? From gmcm@hypernet.com Sat Jul 15 15:17:20 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Sat, 15 Jul 2000 10:17:20 -0400 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: References: <036101bfedba$048fdbe0$f2a6b5d4@hagrid> Message-ID: <1248451855-51961207@hypernet.com> Huaiyu Zhu wrote: > The whole field of linear algebra is built on eight statements, > two of them can be derived from the other. You can't even define > all the concepts like upper or lower case, white space, tab, > symbol, character and number and identifier and concatenation and > so on in just eight statements, let alone to state all the rules > of text processing. You claimed elsewhere that these arguments were quoted out of context, yet you bring them up again. So let's nail this, alright? Text processing doesn't use any new operators. It reuses some arithmetic operators. Everything else is done with methods or functions. If that's what a linear algebra extension used, there would be nothing to discuss. Or you could take something like the regex route: pyLinearAlgebra.evaluate(r'(X`*X)\(X`*y)', X=X, y=y) ... and there would be nothing to discuss. But you want new operators, and that's a can of worms. They need to be spelled sensibly and in a way that doesn't conflict with current Python punctuation / operators. They need precedence rules built into the grammar. If the precedence rules aren't right, the operators are damn near useless, because it will take so many parens to get the right result, you might as well be using one of the above techniques. > The issue arises because one generalization is more familiar to > one group of people but the other is to other people. And people > tend to regard what they are not familiar with as "specific > domain". Python isn't a matrix manipulation language. Like any language that does in-fix, adding operators is a tricky business and affects everybody, whether they know it or not. - Gordon From Fredrik Lundh" (except for the unicode object module, that is). as I've mentioned earlier, I'm working on an alternative unicode database, which includes a ucnhash replacement. my first thought was to emulate the existing api, but it has two small problems: -- it returns pointers into the database. this means that you cannot compress the names at all, if you want to be thread- safe (which you have to be, in this case). -- it exposes low-level implementation details, such as the hash table size, etc. I'm not sure if I can emulate that in any sane way under the new database design. so if nobody uses this, I'd rather change the unicodeobject.c file to use the new API directly... From thomas@xs4all.net Sat Jul 15 17:01:30 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 15 Jul 2000 18:01:30 +0200 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: <200007141505.KAA13385@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 10:05:39AM -0500 References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> <396E4746.DE25EFD4@prescod.net> <200007141505.KAA13385@cj20424-a.reston1.va.home.com> Message-ID: <20000715180130.H7340@xs4all.nl> On Fri, Jul 14, 2000 at 10:05:39AM -0500, Guido van Rossum wrote: > > If Guido has decided that the design that has already been implemented > > is the right one, what's the point of the PEP? Someone just needs to > > review the patch and check it in! > Right! Well, uhm, what now, then ? Should I finish PEP204 ? It's about half done, but throwing it away isn't a problem. I used it to get used to writing PEPs, anyway ;) I still have a question regarding the range literals patch, though, as I noted in the comment on SF: [...] the patch contains some code duplication (about the entire build_range function, plus get_len_of_range()) I'm not sure how to properly solve that: is it okay for compile.c to rely on something from bltinmodule.c ? If not, should I move the common functionality into listobject.c ? There is also the question regarding (::) and generators. Should I finish the PEP for the sake of that ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Moshe Zadka Sat Jul 15 17:10:03 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 15 Jul 2000 19:10:03 +0300 (IDT) Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: <20000715180130.H7340@xs4all.nl> Message-ID: On Sat, 15 Jul 2000, Thomas Wouters wrote: > There is also the question regarding (::) and generators. Should I finish > the PEP for the sake of that ? I think we decided we don't need those. The only reason people need generators is for extra efficiency in for i in range(10^6): if i==5: break But the compiler can do that for the [::] version, since it's non-overridable. About the refactoring: my advice is to refactor first, and ask questions later <0.6 wink> -- after you mess with the code, just moving a function around takes about 3 seconds. (I'd put it in listobject.c first -- but just pick a place) From mal@lemburg.com Sat Jul 15 17:58:45 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 18:58:45 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> Message-ID: <39709844.595B84F6@lemburg.com> Fredrik Lundh wrote: > > as tim pointed out in an earlier thread (on SRE), the > \xnn escape code is something of a kludge. > > I just noted that the unicode string type supports \x > as well as \u, with slightly different semantics: > > \u -- exactly four hexadecimal characters are read. > > \x -- 1 or more hexadecimal characters are read, and > the result is casted to a Py_UNICODE character. \x is there in Unicode for compatibility with the 8-bit string implementation and in sync with ANSI C. Guido wanted these semantics when I asked him about it during the implementation phase. > I'm pretty sure this is an optimal design, but I'm not sure > how it should be changed: > > 1. treat \x as a hexadecimal byte, not a hexadecimal > character. or in other words, make sure that > > ord("\xabcd") == ord(u"\xabcd") > > fwiw, this is how it's done in SRE's parser (see the > python-dev archives for more background). > > 2. ignore \x. after all, \u is much cleaner. > > u"\xabcd" == "\\xabcd" > u"\u0061" == "\x61" == "\x0061" == "\x00000061" > > 3. treat \x as an encoding error. > > 4. read no more than 4 characters. (a comment in the > code says that \x reads 0-4 characters, but the code > doesn't match that comment) > > u"\x0061bcd" == "abcd" > > 5. leave it as it is (just fix the comment). I'd suggest 5 -- makes converting 8-bit strings using \x to Unicode a tad easier. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat Jul 15 18:03:30 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 19:03:30 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> Message-ID: <39709962.1C0A576E@lemburg.com> Fredrik Lundh wrote: > > (except for the unicode object module, that is). I don't think so... it's very new and the C API isn't documented. > as I've mentioned earlier, I'm working on an alternative unicode > database, which includes a ucnhash replacement. > > my first thought was to emulate the existing api, but it has two > small problems: > > -- it returns pointers into the database. this means that you > cannot compress the names at all, if you want to be thread- > safe (which you have to be, in this case). > > -- it exposes low-level implementation details, such as the hash > table size, etc. I'm not sure if I can emulate that in any sane > way under the new database design. > > so if nobody uses this, I'd rather change the unicodeobject.c > file to use the new API directly... Please don't drop the idea of an on-demand loadable module though. The current design used by Bill Tutt is to load the ucnhash module (which contains the mappings) only when it is needed -- most code won't need it. BTW, does you database use the on-demand loading feature ? I don't think that having the Unicode database linked statically in the Python interpreter is a good idea -- at least not until Unicode takes over ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip@mojam.com (Skip Montanaro) Sat Jul 15 16:37:01 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sat, 15 Jul 2000 10:37:01 -0500 (CDT) Subject: [Python-Dev] what to call this zip() function? In-Reply-To: References: Message-ID: <14704.34077.358194.82087@beluga.mojam.com> Nothing has really jumped out as the "right" way to express the proposed builtin that does map(None, l1, l2, l3, l4) How about collate? What we're doing is effectively what a copy machine does when it collates multiple copies of its input... Skip From mal@lemburg.com Sat Jul 15 18:15:05 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 19:15:05 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> Message-ID: <39709C19.A9A27625@lemburg.com> Fredrik Lundh wrote: > > with the locale aware encoding mechanisms switched off > (sys.getdefaultencoding() == "ascii"), I stumbled upon some > interesting behaviour: > > first something that makes sense: > > >>> u"abc" == "abc" > 1 > > >>> u"åäö" == "abc" > 0 > > but how about this one: > > >>> u"abc" == "åäö" > Traceback (most recent call last): > File "", line 1, in ? > UnicodeError: ASCII decoding error: ordinal not in range(128) > > or this one: > > >>> u"åäö" == "åäö" > Traceback (most recent call last): > File "", line 1, in ? > UnicodeError: ASCII decoding error: ordinal not in range(128) > > ignoring implementation details for a moment, is this really the > best we can do? This is merely due to the fact that on your Latin-1 platform, "ä" and u"ä" map to the same ordinals. The unicode-escape codec (which is used by the Python parser) takes single characters in the whole 8-bit range as Unicode ordinals, so u"ä" really maps to unichr(ord("ä")). The alternative would be forcing usage of escapes for non-ASCII Unicode character literals and issuing an error for all non-ASCII ones. BTW, I have a feeling that we should mask the decoding errors during compares in favour of returning 0... ...otherwise the current dictionary would bomb (it doesn't do any compare error checking !) in case a Unicode string happens to have the same hash value as an 8-bit string key. (Can't test this right now, but this is what should happen according to the C sources.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul@prescod.net Sat Jul 15 18:24:56 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 12:24:56 -0500 Subject: [Python-Dev] decoding errors when comparing strings References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> Message-ID: <39709E68.820634C6@prescod.net> Fredrik Lundh wrote: > > ... > > but how about this one: > > >>> u"åäö" == "åäö" > Traceback (most recent call last): > File "", line 1, in ? > UnicodeError: ASCII decoding error: ordinal not in range(128) As soon as you find a character out of the ASCII range in one of the strings, I think that you should report that the two strings are unequal. We can't have exceptions popping out of dictionaries and other "blind compare" situations. Is there any precedent for throwing an exception on cmp? Also, is it really necessary to allow raw non-ASCII characters in source code though? We know that they aren't portable across editing environments, so one person's happy face will be another person's left double-dagger. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Fredrik Lundh" <39709962.1C0A576E@lemburg.com> Message-ID: <005c01bfee83$4bafc480$f2a6b5d4@hagrid> mal wrote: > > (except for the unicode object module, that is). >=20 > I don't think so... it's very new and the C API isn't > documented. great. I'll just pretend it doesn't exist. =20 > > so if nobody uses this, I'd rather change the unicodeobject.c > > file to use the new API directly... >=20 > Please don't drop the idea of an on-demand loadable module > though. The current design used by Bill Tutt is to load the > ucnhash module (which contains the mappings) only when it > is needed -- most code won't need it. > > BTW, does you database use the on-demand loading feature ? > I don't think that having the Unicode database linked statically > in the Python interpreter is a good idea -- at least not until > Unicode takes over ;-) but of course... everything except the "ctype" info is loaded from PYD/SO's, just as before. the only difference is that the files are slightly smaller :-) -rw-r--r-- 1 500 everyone 443392 Jul 15 18:55 ucnhash.pyd -rw-r--r-- 1 500 everyone 161280 Jul 15 18:53 uninames.pyd -rw-r--r-- 1 500 everyone 594944 Jul 11 23:03 unicodedata.pyd -rw-r--r-- 1 500 everyone 42496 Jul 15 15:25 unidata.pyd -rw-r--r-- 1 500 everyone 118329 Jul 13 21:01 unicodectype.obj -rw-r--r-- 1 500 everyone 10961 Jul 15 15:23 unictype.obj (names and sizes may change slightly before the final patch, but you get the idea). cheers /F From Fredrik Lundh" my unicode database compression project has resulted in its first patch: https://sourceforge.net/patch/index.php?func=3Ddetailpatch&patch_id=3D100= 899&group_id=3D5470 this patch replaces "ucnhash" (sorry bill!) with a new module called "uninames". on my windows box, the new module is about 1/3 of the old one (about 160k). YMMV, as usual. From Fredrik Lundh" Message-ID: <007401bfee86$9dd566e0$f2a6b5d4@hagrid> > my unicode database compression project has resulted in its first > patch: >=20 > = https://sourceforge.net/patch/index.php?func=3Ddetailpatch&patch_id=3D100= 899&group_id=3D5470 two additional comments: first, the patch was too large for sourceforge (>512000 bytes), so I've uploaded it to the secret effbot site instead: http://w1.132.telia.com/~u13208596/uninames-patch.txt second, the uninames module provides two public Python functions: getname(code) returns the character name corresponding to the given character code, or None if the name is not known. getcode(name) returns the character code for the given character name. again, it returns None if the code is not known. Q: should I raise exceptions instead of returning None? Q: what other functions would be useful? getallnames()? anything else? cheers /F From mal@lemburg.com Sat Jul 15 18:57:45 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 19:57:45 +0200 Subject: [Python-Dev] Linker problems on Linux Message-ID: <3970A619.D2CA39AA@lemburg.com> I just tried to compile the current CVS version on Linux. The compile went fine, but when I started Python, I got: 'import site' failed; use -v for traceback Python 2.0b1 (#1, Jul 15 2000, 19:22:33) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) Traceback (most recent call last): File "/home/lemburg/bin/pyinteractive.py", line 7, in ? import mx.Tools File "/home/lemburg/projects/mx/Tools/__init__.py", line 24, in ? from Tools import * File "/home/lemburg/projects/mx/Tools/Tools.py", line 10, in ? from mxTools import * File "/home/lemburg/projects/mx/Tools/mxTools/__init__.py", line 1, in ? from mxTools import * ImportError: /home/lemburg/projects/mx/Tools/mxTools/mxTools.so: undefined symbol: PyObject_Length >>> Why isn't PyObject_Length being exported anymore ??? I hve the funny feeling that the API name cosmetics applied to xxx_Length() got someone carried away a bit ;-) We shouldn't drop binary compatibility on *all* platforms just for the sake of style... I remember very well how Guido opposed to any binary incompatible changes in earlier versions of Python and can't really believe that this strategy has suddenly changed for 2.0. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat Jul 15 18:59:56 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 19:59:56 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709C19.A9A27625@lemburg.com> Message-ID: <3970A69C.3361B209@lemburg.com> "M.-A. Lemburg" wrote: > > BTW, I have a feeling that we should mask the decoding errors > during compares in favour of returning 0... > > ...otherwise the current dictionary would bomb (it doesn't do any > compare error checking !) in case a Unicode string happens to have > the same hash value as an 8-bit string key. (Can't test this right now, > but this is what should happen according to the C sources.) Here's the test: >>> s = 'ä' >>> u = u'ä' >>> hash(s) -880683291 >>> hash(u) -880683291 >>> d = {s:1} >>> d[s] 1 >>> d[u] Traceback (most recent call last): File "", line 1, in ? KeyError>>> >>> Looks strange, doesn't it... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat Jul 15 19:02:31 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 20:02:31 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> <39709962.1C0A576E@lemburg.com> <005c01bfee83$4bafc480$f2a6b5d4@hagrid> Message-ID: <3970A737.6B13B543@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > so if nobody uses this, I'd rather change the unicodeobject.c > > > file to use the new API directly... > > > > Please don't drop the idea of an on-demand loadable module > > though. The current design used by Bill Tutt is to load the > > ucnhash module (which contains the mappings) only when it > > is needed -- most code won't need it. > > > > BTW, does you database use the on-demand loading feature ? > > I don't think that having the Unicode database linked statically > > in the Python interpreter is a good idea -- at least not until > > Unicode takes over ;-) > > but of course... > > everything except the "ctype" info is loaded from PYD/SO's, just as > before. the only difference is that the files are slightly smaller :-) > > -rw-r--r-- 1 500 everyone 443392 Jul 15 18:55 ucnhash.pyd > -rw-r--r-- 1 500 everyone 161280 Jul 15 18:53 uninames.pyd > > -rw-r--r-- 1 500 everyone 594944 Jul 11 23:03 unicodedata.pyd > -rw-r--r-- 1 500 everyone 42496 Jul 15 15:25 unidata.pyd > > -rw-r--r-- 1 500 everyone 118329 Jul 13 21:01 unicodectype.obj > -rw-r--r-- 1 500 everyone 10961 Jul 15 15:23 unictype.obj > > (names and sizes may change slightly before the final patch, but you > get the idea). Cool :-) (I'd suggest keeping the original names, BTW) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" <14704.34077.358194.82087@beluga.mojam.com> Message-ID: <007d01bfee87$eb2c2e00$f2a6b5d4@hagrid> skip wrote: > Nothing has really jumped out as the "right" way to express the = proposed > builtin that does=20 >=20 > map(None, l1, l2, l3, l4) >=20 > How about collate? What we're doing is effectively what a copy = machine does=20 > when it collates multiple copies of its input... let's see: merriam webster has the following to say: collate: ... to assemble in proper order; especially : to assemble (as printed sheets) in order for binding ... "binding"? sounds familiar. let's take a look at the language reference: ... Assignment statements are used to (re)bind names to values ... The for statement is used to iterate over the elements of a sequence ... Each item in turn is assigned to the target list using the standard rules for assignments ... +1 from here. From mal@lemburg.com Sat Jul 15 19:09:49 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 20:09:49 +0200 Subject: [Python-Dev] [patch #100889] a smaller unicode name database References: <006a01bfee85$c787f3a0$f2a6b5d4@hagrid> <007401bfee86$9dd566e0$f2a6b5d4@hagrid> Message-ID: <3970A8ED.28CEC0FE@lemburg.com> Fredrik Lundh wrote: > > > my unicode database compression project has resulted in its first > > patch: > > > > https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100899&group_id=5470 > > two additional comments: > > first, the patch was too large for sourceforge (>512000 bytes), so > I've uploaded it to the secret effbot site instead: > > http://w1.132.telia.com/~u13208596/uninames-patch.txt > > second, the uninames module provides two public Python functions: I'd name this: unicodenames (we shouldn't be afraid of long module names ;-). > getname(code) returns the character name corresponding to > the given character code, or None if the name is not known. > > getcode(name) returns the character code for the given character > name. again, it returns None if the code is not known. > > Q: should I raise exceptions instead of returning None? Yes... getname() with an unkown code means that an unassigned code is being requested: this is a ValueError. getcode(name) should raise a ValueError exception too, since the requested name may be unsupported by Python's version of the Unicode lib (vers. 3.0). BTW, did you make the lookups case insensitive ? (Would be useful, IMHO.) > Q: what other functions would be useful? getallnames()? anything > else? Perhaps a dictionary like interface written on top of the above two APIs (in Python, of course). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Moshe Zadka Sat Jul 15 19:14:19 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 15 Jul 2000 21:14:19 +0300 (IDT) Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: On Sat, 15 Jul 2000, Skip Montanaro wrote: > > Nothing has really jumped out as the "right" way to express the proposed > builtin that does > > map(None, l1, l2, l3, l4) > > How about collate? What we're doing is effectively what a copy machine does > when it collates multiple copies of its input... Collate is great! +0 on that. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Fredrik Lundh" <39709962.1C0A576E@lemburg.com> <005c01bfee83$4bafc480$f2a6b5d4@hagrid> <3970A737.6B13B543@lemburg.com> Message-ID: <008b01bfee89$8e731460$f2a6b5d4@hagrid> mal wrote: > Cool :-) oh, just wait until I've gotten my head around Christian's superoptimizations ;-) > (I'd suggest keeping the original names, BTW) unicodedata and unicodectype are okay, but frankly, isn't "ucnhash" overly cryptic? how about "unicodenames"? From Fredrik Lundh" <39709E68.820634C6@prescod.net> Message-ID: <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> paul wrote: > As soon as you find a character out of the ASCII range in one of the > strings, I think that you should report that the two strings are > unequal. sounds reasonable -- but how do you flag "unequal" in cmp? which value is "larger" if all that we know is that they're different... > We can't have exceptions popping out of dictionaries and other "blind > compare" situations. Is there any precedent for throwing an exception > on cmp? not really. it's a bit amusing that "a" =3D=3D x works for all built-in types, except unicode strings... (not to mention that "a" < x works, in a way...) > Also, is it really necessary to allow raw non-ASCII characters in = source > code though? We know that they aren't portable across editing > environments, so one person's happy face will be another person's left > double-dagger. I suppose changing that would break code. maybe it's time to reopen the "pragma encoding" thread? (I'll dig up my old proposal, and post it under a new subject). From ping@lfw.org Sat Jul 15 19:34:57 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Sat, 15 Jul 2000 11:34:57 -0700 (PDT) Subject: [Python-Dev] what to call this zip() function? Message-ID: Skip Montanaro wrote: > How about collate? The analogy with a photocopying machine is pretty good, but i'm afraid this will play havoc with those who see "collate" in terms of determining sort order. * * * With me acting as the user and a willing guinea pig playing the part of the Python interpreter, i got the following results: >>> a = [1, 2, 3] >>> b = [4, 5, 6] >>> c = [7, 8, 9] >>> for x, y, z in twine(a, b, c): ... print x, y, z 1 5 9 2 6 7 3 4 8 >>> for x, y, z in weave(a, b, c): ... print x, y, z 1 5 7 2 4 8 3 None 9 None 6 None >>> for x, y, z in parallel(a, b, c): ... print x, y, z 1 4 7 2 5 8 3 6 9 * * * On Fri, 14 Jul 2000, Eric S. Raymond wrote: > No, *I* wrote `plait() is *good*.' > > In English, `plait' is a slightly unusual word with a meaning almost > indistinguishable from `braid'. ...which is almost entirely the *wrong* meaning, imho. Here are the pictures i get from the words suggested so far. splice furl _______ --> <-- / _____ \ --------= =------- / / \ \ \_______/ / ___________/ twine /|\ lace -%- \|/ \ / \ X /|\ / \ \|/ \ / \ X /|\ (_) \|/ braid / \ / plait | | plait | / (sense 2) | _______|_ (sense 1) \ / \ |/| | \ | | _______|_ / \ / |/| | | / | | \ / \ | | \ | / \ / weave -|-----|-----|- interlace -----------> interweave | | | | | interleave <----------- knit ----|-----|---- -----------> | | | | | <----------- -|-----|-----|- -----------> | | | | | <----------- ----|-----|---- -----------> | | | | | <----------- -|-----|-----|- parallel --------------- march ------ o-> - - - --------------- ------ o-> - - - --------------- ------ o-> - - - --------------- ------ o-> - - - zip o o merge | | | marry o o (herd?) | | | o o \ | / o-o \|/ o-o | o-o | o-o | o-o v * * * It's fairly clear to me that, of the names that evoke images of some sort, only "parallel", "march", and "merge" are actually accurate. "zip" and "marry" are nearly accurate except that they usually give the impression that only two things are being joined. Of these five options, "zip" and "parallel" have potentially misleading meanings. "merge" sounds the most neutral to me. "tuples" is also very neutral (though it doesn't really suggest *how* the tuples are obtained). Therefore, i'm down to "merge", "tuples", or "march" (maybe "herd"); i'd be quite happy with "parallel" or "zip" but others have already come out strongly against those two. * * * Finally, on the lighter side... more ideas from my twisted mind. for x, y, z in rearrange(a, b, c)? for x, y, z in herd(a, b, c)? for x, y, z in mutilate(a, b, c)? for x, y, z in harass(a, b, c)? for x, y, z in abuse(a, b, c)? for x, y, z in torture(a, b, c)? A friend also suggested a name reminiscent of our discussion. for x, y, z in flamewar(a, b, c): print x, y, z You want an argument? Oh, this is abuse. Arguments are down the hall. -- ?!ng From ping@lfw.org Sat Jul 15 19:36:48 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Sat, 15 Jul 2000 11:36:48 -0700 (PDT) Subject: [Python-Dev] Re: what to call this zip() function? In-Reply-To: Message-ID: On Sat, 15 Jul 2000, Ka-Ping Yee wrote: > zip o o merge | | | > marry o o (herd?) | | | > o o \ | / > o-o \|/ > o-o | > o-o | > o-o | > o-o v Oh yes. "meld" also falls in the "merge"/"herd" category. -- ?!ng From alex_c@MIT.EDU Sat Jul 15 19:32:00 2000 From: alex_c@MIT.EDU (Alex Coventry) Date: Sat, 15 Jul 2000 14:32:00 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> (fdrake@beopen.com) References: <200007142030.QAA156803@w20-575-116.mit.edu> <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> <200007142242.SAA12205@mint-square.mit.edu> <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> Message-ID: <200007151832.OAA63801@w20-575-115.mit.edu> Should posixpath.expandvars throw a SyntaxError if it encounters unbalanced curly braces? >>> import posixpath >>> posixpath.expandvars('/dir1/dir${DIR_NUM/dir2') '/dir1/dir${DIR_NUM/dir2' >>> Alex. From paul@prescod.net Sat Jul 15 19:37:43 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 13:37:43 -0500 Subject: [Python-Dev] what to call this zip() function? References: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: <3970AF77.385853E0@prescod.net> Skip Montanaro wrote: > > Nothing has really jumped out as the "right" way to express the proposed > builtin that does > > map(None, l1, l2, l3, l4) > > How about collate? What we're doing is effectively what a copy machine does > when it collates multiple copies of its input... +1 on collate! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From thomas@xs4all.net Sat Jul 15 19:44:10 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 15 Jul 2000 20:44:10 +0200 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <3970A619.D2CA39AA@lemburg.com>; from mal@lemburg.com on Sat, Jul 15, 2000 at 07:57:45PM +0200 References: <3970A619.D2CA39AA@lemburg.com> Message-ID: <20000715204410.I7340@xs4all.nl> On Sat, Jul 15, 2000 at 07:57:45PM +0200, M.-A. Lemburg wrote: > I just tried to compile the current CVS version on Linux. > The compile went fine, but when I started Python, I got: > 'import site' failed; use -v for traceback > Python 2.0b1 (#1, Jul 15 2000, 19:22:33) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > Traceback (most recent call last): > File "/home/lemburg/bin/pyinteractive.py", line 7, in ? > import mx.Tools > File "/home/lemburg/projects/mx/Tools/__init__.py", line 24, in ? > from Tools import * > File "/home/lemburg/projects/mx/Tools/Tools.py", line 10, in ? > from mxTools import * > File "/home/lemburg/projects/mx/Tools/mxTools/__init__.py", line 1, in ? > from mxTools import * > ImportError: /home/lemburg/projects/mx/Tools/mxTools/mxTools.so: undefined symbol: PyObject_Length > Why isn't PyObject_Length being exported anymore ??? PyObject_Length is changed into a #define, to PyObject_Size. This preserves the API but not the ABI ;) GCC has a construct to make one function an alias for another: PyObject * PyObject_Length() __attribute__((alias("PyObject_Size"))); But this is not likely to work in other compilers, and not on all architectures to start with. The most portable solution is probably to make PyObject_Length() a wrapper for PyObject_Size, and hope the compiler knows how to handle that most efficiently. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm@hypernet.com Sat Jul 15 19:44:48 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Sat, 15 Jul 2000 14:44:48 -0400 Subject: [Python-Dev] what to call this zip() function? In-Reply-To: Message-ID: <1248435790-52927448@hypernet.com> Ka-Ping Yee wrote: > You want an argument? Oh, this is abuse. Arguments are down the > hall. Now that's my kind of company! Drop in anytime, Barry. No appointment necessary.... - Gordon From paul@prescod.net Sat Jul 15 19:48:20 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 13:48:20 -0500 Subject: [Python-Dev] Pre-PEP Idea Message-ID: <3970B1F4.D4D8BAE9@prescod.net> Hopefully this transcript will speak for itself...mostly. >>> help | The help function allows you to read help on Python's various | functions, objects, instructions and modules. You have two options: | | 1. Use help( obj ) to browse the help attached to some function, | module, class or other object. e.g. help( dir ) | | 2. Use help( "somestring" ) to browse help on one of the predefined | help topics, unassociated with any particular object: | | help( "intro" ) - What is Python? | help( "keywords" ) - What are the keywords? | help( "syntax" ) - What is the overall syntax? | help( "operators" ) - What operators are available? | help( "types" ) - What types are built-in (not extension types)? | help( "exceptions" ) - What exceptions can be raised? | help( "modules" ) - What modules are in the standard library? | help( "copyright" ) - Who owns Python? | help( "moreinfo" ) - Where is there more information? | help( "changes" ) - What changed in Python 2.0? | help( "extensions" ) - What extensions are installed? | help( "faq" ) - What questions are frequently asked? | help( "ack" ) - Who has done work on Python lately? | help( "language" ) - Change the language of the help function >>> >>> help( "keywords" ) | "if" - Conditional execution | "while" - Loop while a condition is true | "for" - Loop over a sequence of values (often numbers) | "try" - Set up an exception handler | "def" - Define a named function | "class" - Define a class | "assert" - Check that some code is working as you expect it to. | "pass" - Do nothing | "del" - Delete a data value | "print" - Print a value | "return" - Return information from a function | "raise" - Raise an exception | "break" - Terminate a loop | "continue" - Skip to the next loop statement | "import" - Import a module | "global" - Declare a variable global | "exec" - Execute some dynamically generated code | "lambda" - Define an unnamed function | For more information, type e.g. help("assert") >>> >>> help( dir ) | dir([object]) -> list of strings | Return an alphabetized list of names comprising (some of) the attributes | of the given object. Without an argument, the names in the current scope | are listed. With an instance argument, only the instance attributes are | returned. With a class argument, attributes of the base class are not | returned. For other types or arguments, this may list members or methods. >>> >>> import pickle >>> help( pickle ) | create portable serialized representations of Python objects. | See module cPickle for a (much) faster implementation. | See module copy_reg for a mechanism for registering custom picklers. | Classes: | Pickler | Unpickler | Functions: | dump(object, file) | dumps(object) -> string | load(file) -> object | loads(string) -> object | Misc variables: | __version__ | format_version | compatible_formats >>> -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Moshe Zadka Sat Jul 15 19:50:55 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 15 Jul 2000 21:50:55 +0300 (IDT) Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> Message-ID: On Sat, 15 Jul 2000, Fredrik Lundh wrote: > paul wrote: > > As soon as you find a character out of the ASCII range in one of the > > strings, I think that you should report that the two strings are > > unequal. > > sounds reasonable -- but how do you flag "unequal" in cmp? which > value is "larger" if all that we know is that they're different... We can say something like "beyond the ASCII range, every unicode character is larger then any regular 8-bit character", and compare lexicographically. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Moshe Zadka Sat Jul 15 19:55:07 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 15 Jul 2000 21:55:07 +0300 (IDT) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B1F4.D4D8BAE9@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Hopefully this transcript will speak for itself...mostly. > > >>> help +0. Here's what I think would make it +1: -- have all that wonderful stuff in help.py -- have the startup code of the *interactive interpreter only* do "from help import help" at the beginning. by-all-means-PEP-it-*i've*-seen-it-a-gazillion-times-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Fredrik Lundh" Message-ID: <010e01bfee90$224df960$f2a6b5d4@hagrid> paul wrote: > Hopefully this transcript will speak for itself...mostly. >=20 > >>> help > | The help function allows you to read help on Python's various=20 > | functions, objects, instructions and modules. heh. so that's why I'm having a slight headache; paul is in there stealing my ideas? ;-) ... I got stuck on whether this is best implemented as a true builtin, or just patched into the builtins dictionary by site.py... why not just post a site.py patch, and forget about the PEP for now? 1) plus a sys.sethelphook function which allow the environ- ment to override the default behaviour; for example, if you're typing help("intro") in PythonWorks' console window, you pro- bably want to get nicely formatted help in the "info" panel, not in the console window itself. From Vladimir.Marangozov@inrialpes.fr Sat Jul 15 20:13:04 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sat, 15 Jul 2000 21:13:04 +0200 (CEST) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B1F4.D4D8BAE9@prescod.net> from "Paul Prescod" at Jul 15, 2000 01:48:20 PM Message-ID: <200007151913.VAA03550@python.inrialpes.fr> Paul Prescod wrote: > > Hopefully this transcript will speak for itself...mostly. > Very nice, Paul! PEP it without hesitation. I'm all for it! We'll discuss subsequently what's the best way to implement interactive help screens. don't-forget-to-add-man()-for-Tom-Christiansen-<0.8 wink>'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul@prescod.net Sat Jul 15 20:13:55 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 14:13:55 -0500 Subject: [Python-Dev] Pre-PEP Idea References: Message-ID: <3970B7F3.28F64A3E@prescod.net> Moshe Zadka wrote: > > ... > > -- have all that wonderful stuff in help.py > -- have the startup code of the *interactive interpreter only* do > "from help import help" at the beginning. Sorry, that's a part I should have explanied more. help is not a magical function/statement but an instance with a repr that does the right thing. And yes, it will probably only be loaded at the repl. Or it could be a 10-line instance that loads its content when it is actually used. That might allow python -c "import help" Here's a sample definition. class helploader: def __repr__( self ): global help from helptext import help return repr( help ) def __call__( self ): global help from helptext import help return repr( help ) help=helploader() -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Fredrik Lundh" <14703.37801.644447.63587@cj42289-a.reston1.va.home.com><200007142242.SAA12205@mint-square.mit.edu> <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> <200007151832.OAA63801@w20-575-115.mit.edu> Message-ID: <012f01bfee92$0e21df40$f2a6b5d4@hagrid> alex wrote: > > Should posixpath.expandvars throw a SyntaxError if it encounters > unbalanced curly braces? >=20 > >>> import posixpath > >>> posixpath.expandvars('/dir1/dir${DIR_NUM/dir2') > '/dir1/dir${DIR_NUM/dir2' > >>>=20 probably not; code using it might not be prepared to handle an exception... what does the Unix shell do in this case? (intuitively, I'd treat ${FOO as $FOO, say: _varprog =3D re.compile(r'\$(\{[^{}$]*\}|{?\w+|)') but that's me...) From Moshe Zadka Sat Jul 15 20:19:11 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 15 Jul 2000 22:19:11 +0300 (IDT) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B7F3.28F64A3E@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Moshe Zadka wrote: > > > > ... > > > > -- have all that wonderful stuff in help.py > > -- have the startup code of the *interactive interpreter only* do > > "from help import help" at the beginning. > > Sorry, that's a part I should have explanied more. > > help is not a magical function/statement but an instance with a repr > that does the right thing. And yes, it will probably only be loaded at > the repl. Or it could be a 10-line instance that loads its content when > it is actually used. That might allow > > python -c "import help" > > Here's a sample definition. > > class helploader: > def __repr__( self ): > global help > from helptext import help > return repr( help ) > def __call__( self ): > global help > from helptext import help > return repr( help ) > help=helploader() BTW, that should probably be CCed to the doc-sig, because that information has to come from somewhere. doc-sig traffic kind of died after the initial IPC8-induced burst. Fred, any plans on seriously reviving doc-sig? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul@prescod.net Sat Jul 15 20:19:41 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 14:19:41 -0500 Subject: [Python-Dev] Pre-PEP Idea References: <3970B1F4.D4D8BAE9@prescod.net> <010e01bfee90$224df960$f2a6b5d4@hagrid> Message-ID: <3970B94D.40F5032A@prescod.net> Fredrik Lundh wrote: > > ... > > heh. so that's why I'm having a slight headache; paul is > in there stealing my ideas? ;-) I should have just let you invent it! > I got stuck on whether this is best implemented as a true > builtin, or just patched into the builtins dictionary by site.py... six of one, half dozen of the other. * builtin means a little more consistency across environments * ptach means a little less code on startup What do you think of my ten-line bootstrapper idea. I weigh the former slightly higher then the latter. Plus, I could perhaps put a helpful message in the bootstrapper to help people debug site.py and PYTHONPATH problems. :) > 1) plus a sys.sethelphook function which allow the environ- > ment to override the default behaviour; for example, if you're > typing help("intro") in PythonWorks' console window, you pro- > bably want to get nicely formatted help in the "info" panel, > not in the console window itself. Good idea. And eventually some way for extensions to register themselves...and a pager. Do we have pager code hanging around? Some docstrings are already long and we have no mechanism for breaking them up .... -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From alex_c@MIT.EDU Sat Jul 15 20:23:55 2000 From: alex_c@MIT.EDU (Alex Coventry) Date: Sat, 15 Jul 2000 15:23:55 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <012f01bfee92$0e21df40$f2a6b5d4@hagrid> (effbot@telia.com) References: <200007142030.QAA156803@w20-575-116.mit.edu><14703.37801.644447.63587@cj42289-a.reston1.va.home.com><200007142242.SAA12205@mint-square.mit.edu> <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> <200007151832.OAA63801@w20-575-115.mit.edu> <012f01bfee92$0e21df40$f2a6b5d4@hagrid> Message-ID: <200007151923.PAA64675@w20-575-115.mit.edu> > > Should posixpath.expandvars throw a SyntaxError if it encounters > > unbalanced curly braces? > > probably not; code using it might not be prepared > to handle an exception... > > what does the Unix shell do in this case? It gives an error: athena% echo ${HOME Missing }. athena% echo ${HOME} /afs/athena.mit.edu/user/a/l/alex_c athena% You're probably right about backwards compatibility being worth more than compatibility with Unix in this case, though. Alex. From paul@prescod.net Sat Jul 15 20:24:21 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 14:24:21 -0500 Subject: [Python-Dev] Pre-PEP Idea References: <3970B1F4.D4D8BAE9@prescod.net> <010e01bfee90$224df960$f2a6b5d4@hagrid> Message-ID: <3970BA65.5DBFB39A@prescod.net> Fredrik Lundh wrote: > > ... > > why not just post a site.py patch, and forget about the > PEP for now? Also, how should I include a new module in a patch? Do I do a directory diff? Or just checkin the stupid thing? -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Moshe Zadka Sat Jul 15 20:41:13 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 15 Jul 2000 22:41:13 +0300 (IDT) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B94D.40F5032A@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Good idea. And eventually some way for extensions to register > themselves...and a pager. Do we have pager code hanging around? Some > docstrings are already long and we have no mechanism for breaking them > up .... Do you mean this: import sys def pager(lines, length=23): while lines: sys.stdout.writelines(lines[:length]) lines = lines[length:] if lines: raw_input("--more--") def main(): pager(open(sys.argv[1]).readlines()) if __name__ == '__main__': main() -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Fredrik Lundh" <010e01bfee90$224df960$f2a6b5d4@hagrid> <3970BA65.5DBFB39A@prescod.net> Message-ID: <016001bfee97$0b67fd20$f2a6b5d4@hagrid> paul wrote: > Also, how should I include a new module in a patch? Do I do a = directory > diff? Or just checkin the stupid thing? I had the same problem for the "uninames" patch. I ended up using "diff -N" on local, empty files. hopefully, someone out there might have a better solution? (the docs imply that "cvs -N" might work, but it sure didn't work for me...) From paul@prescod.net Sat Jul 15 21:03:15 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 15:03:15 -0500 Subject: [Python-Dev] Pre-PEP Idea References: Message-ID: <3970C383.9D844BF3@prescod.net> Moshe Zadka wrote: > > Do you mean this: > > import sys > > def pager(lines, length=23): > while lines: > sys.stdout.writelines(lines[:length]) > lines = lines[length:] > if lines: > raw_input("--more--") > > def main(): > pager(open(sys.argv[1]).readlines()) > Okay, okay, it didn't turn out so hard. :) I was just about to write it myself. Is there a way to get a single key portably, rather than requiring a return? Not a biggee. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Sat Jul 15 21:04:30 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 15:04:30 -0500 Subject: [Python-Dev] Pre-PEP Idea References: <200007151913.VAA03550@python.inrialpes.fr> Message-ID: <3970C3CE.804A8BF@prescod.net> Vladimir Marangozov wrote: > > Paul Prescod wrote: > > > > Hopefully this transcript will speak for itself...mostly. > > > > Very nice, Paul! > PEP it without hesitation. I'm all for it! We'll discuss subsequently > what's the best way to implement interactive help screens. > > don't-forget-to-add-man()-for-Tom-Christiansen-<0.8 wink>'ly y'rs No joke, in the interactive environment I am going to add apropos and man as aliases. Or at least messages that say: "try help". -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Sat Jul 15 21:16:16 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 15:16:16 -0500 Subject: [Python-Dev] Pre-PEP Idea References: Message-ID: <3970C690.42CA22FF@prescod.net> Moshe Zadka wrote: > > BTW, that should probably be CCed to the doc-sig, because that information > has to come from somewhere. True enough. Let me get some infrastructure in place and sic them on it. It may also be good to ask for volunteers in c.l.py. Here are my ideas about content: 1. There is the list of hardcoded strings that are probably just triple-quoted strings. 2. There are docstrings. 3. If you happen to know a filename, you can reach into the HTML docs like this: help( "docs:lib/module-grp.html") 4. Docstrings can "redirect" to the HTML docs like this: def myfunc(): """No docs here! Please see """ ... Here's what the HTML-converted output will look like (not perfect but not bad): next[1] up[2] previous[3] Python Library Reference contents[4] modules[5] index[6] Next: 8.1 posix [7] Up: Python Library Reference[8] Previous: 7.15.1 Completer Objects[9] ------------------------------------------------------------------------ 8. Unix Specific Services The modules described in this chapter provide interfaces to features that are unique to the Unix operating system, or in some cases to some or many variants of it. Here's an overview: posix[10] The most common POSIX system calls (normally used via module os[11]). pwd[12] The password database (getpwnam() and friends). grp[13] The group database (getgrnam() and friends). crypt[14] The crypt() function used to check Unix passwords. dl[15] Call C functions in shared objects. dbm[16] The standard ``database'' interface, based on ndbm. gdbm[17] GNU's reinterpretation of dbm. termios[18] POSIX style tty control. ------------------------------------------------------------------------ next[30] up[31] previous[32] Python Library Reference contents[33] modules[34] index[35] Next: 8.1 posix [36] Up: Python Library Reference[37] Previous: 7.15.1 Completer Objects[38] ------------------------------------------------------------------------ See About this document...[39] for information on suggesting changes. [1] docs:lib/module-posix.html [2] docs:lib/lib.html [3] docs:lib/completer-objects.html ... Thanks Fred and Guido. The htmllib code is pretty close for what I need! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Moshe Zadka Sat Jul 15 21:21:14 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 15 Jul 2000 23:21:14 +0300 (IDT) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970C383.9D844BF3@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Is there a way to get a single key portably, rather than > requiring a return? Not that I know of. coding-during-commercials-is-fun-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Fredrik Lundh" <007401bfee86$9dd566e0$f2a6b5d4@hagrid> <3970A8ED.28CEC0FE@lemburg.com> Message-ID: <018c01bfee9b$5ce953c0$f2a6b5d4@hagrid> mal wrote: > > second, the uninames module provides two public Python functions: >=20 > I'd name this: unicodenames (we shouldn't be afraid of long > module names ;-). ok. > getname() with an unkown code means that an unassigned > code is being requested: this is a ValueError. >=20 > getcode(name) should raise a ValueError exception too, since the > requested name may be unsupported by Python's version of the > Unicode lib (vers. 3.0). ok. > BTW, did you make the lookups case insensitive ? (Would be > useful, IMHO.) sure. both getcode and \N are case insensitive. > Perhaps a dictionary like interface written on top of > the above two APIs (in Python, of course). sounds like something for a "unicodeutils.py" module ;-) maybe later... ... if anyone would like to play with this, I just updated the patch at: http://w1.132.telia.com/~u13208596/uninames-patch.txt (the module is renamed, the patch isn't...) note: the patch doesn't update the build files. Should be pretty obvious how to do that... From huaiyu_zhu@yahoo.com Sat Jul 15 21:30:31 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Sat, 15 Jul 2000 13:30:31 -0700 (PDT) Subject: [Python-Dev] More discussion on new infix operators In-Reply-To: <1248451855-51961207@hypernet.com> Message-ID: I would like to redirect this discussion to deal with solvable problems, rather than going on at several fronts, not all of them immediately resolvable. I'll provide some background, summarize what I've learned in these discussions, and finally present some options and comments. The issue arises from the attempt to introduce matrix operations into python. This may be an unfamiliar subject here, and we can't hope to agree upon how fundamental or useful it is. So let's just regard it as some mysterious thing that engineers like to do [1]. It happens that in this domain the familiar arithmetic operators split into two personalities, matrix-wise and element-wise. Both are used frequently, often within the same formula. There are several successful commercial and free languages for numerical computation. Many of them use the Matlab approach: ordinary operators for matrix operation, dot-operators for element-wise operation. These languages are very elegant and powerful within the domain of their applications. The problem is, many of them are not object oriented. Most people do not use matrix as part of a math course, but as a method for solving real problems. So they are forced to use Perl, shell scripts or embedded or embedding C/C++ to integrate these calculations into their applications. There is no need to explain here why people would want to use Python as the glue language. You may also agree that calling other languages within Python cannot beat using native Python modules written in C. A great deal of work has been done to build the Numerical package. Although the situation improves tremendously, it still do not appeal to most users of the dedicated matrix languages, for two reasons. One is that NumPy emphasizes on multi-array rather than matrix [2]. The other is the lack of support to distinguish the two personalities of operators. The MatPy project was started to solve these problems. It defines matrix classes that wrap around the Numeric classes, so that ordinary operators default to matrix-wise operations, solving the first problem. The second problem cannot be solved without any change to Python syntax, because there simply isn't enough binary operators available. It is necessary to add new operators. They can all live in the area of current "invalid syntax" so they would not interfere with existing code. We made a patch to the parser to add new operators, and I started a discussion on the best allocation of these operators, when the discussion was also brought here. So much for the background. From these discussions I believe the following is clear (please correct me). 1. It is not much more difficult to add .* style operators than to add @* style operators, even though . is overused and @ is unused. 2. There already exists some facilities for changing syntax within pure python. But I don't remember any mention of where it is, and it seems people do not agree on its usability status at the moment. 3. Most here do not want additional operators in the core language until they see it successfully used in at least one domain. There is also an argument that operators that are only meaningful in one domain would acquire completely incomprehensible semantics in all other domains. 4. There are three types of suggestion for matrix computation: 1) Do not make any syntax change. This includes two proposals: 1.a) Use function calls like dotmul(a,b). 1.b) Define Element and Matrix classes in parallel, with methods for casting. Use a.Element()*b.Element() in place of a.*b. 2) Add additional operators. These operators have fixed precedence as their original counterparts but their semantics can be overridden in applications. They are encouraged to preserve the object-wise and element-wise distinctions. 2.a) Add @* type operators. 2.b) Add .* type operators. 3) User a patched parser. This also allows additional syntactic changes: 3.a) Only as a temporary measure until it is accepted to core language. 3.b) Each application can have their own syntax with some marker on each module to indicate which is which. 3.c) Just develop a different language. 5. Will introducing dot operators conflict with any existing language structures? It does not affect member indicators, because that's always between two names. It may interfere with a trailing decimal point, but that can be fixed by a simple rule (3.*a means 3. * a). Now to the options with my own comments. 1.a) is unacceptable because infix operators improve readability tremendously compared with prefix operators. 1.b) is unacceptable because it is too long and involves at least two method calls and object initialization for each operation. 2.a) was our original plan, and we have a patch for doing so. It is less than optimal aesthetically, and we were not sure to use it for matrix or element-wise operations. It is not intended to be submitted to the core language until the matrix package itself is ready to do so, although it couldn't possibly be changed at that time. 2.b) is my personal favorite. As ESR pointed out, there are also potential applications in other areas. To prevent incompatible semantics, it could be encouraged to be used only in "dual personality" situations. Whenever possible, the dot operators default to "element-wise operation" for any composite objects. For example [1,2] + [10,20] == [1,2,10,20] [1,2] .+ [10,20] == [11,22] 3) is not a good option in this case. First, it is overkill. Linear algebra is a very mature field and only a handful of well-known operators are called for. These operations are written in science and engineering books for years and are very unlikely to change anytime soon. Second, it presents greater danger of incompatibility and fragmentation. Unlike different semantics, different syntax cannot even live within the same module. Third, the very reason people would want to use python for matrix computation is because it is an integral part of their application that need to work with everything else smoothly. The situation now is that MatPy project has to move on, no matter what. It will introduce some kind of binary infix operators just to be viable (unless some entirely new argument comes along). But there do not seem to be additional big hurdles on either algorithm or man power to impede its further development. I hope, and I do believe personally, that it will acquire wide-spread usage once such basic facilities are provided, and will eventually be integrated into the core language. It would be next to impossible to change operators at that moment. Therefore I am most interested in hearing any thoughts on whether there exist any mortal danger for introducing the dot operators. For example, will it be confused with any planned new language features? Arguments on whether this would open the floodgate for other feature requests is unlikely to change the course of MatPy development because we agreed not to talk about how specific the domain is [1]. That's all I could think of at this moment. I'd like to thank your patience for reading so far. I am grateful for all the rational and very helpful opinions I heard here, and I eagerly expect more. Huaiyu [1] I'd be glad to provide easy introduction to numerical computation through email to anyone who would spend half an hour experimenting. [2] The easiest (but not quite accurate) way to describe the difference is to compare with lists and strings: If you are doing text processing you want a dedicated string type, rather than a list of characters, although theoretically the latter can do just about everything the former can. From thomas@xs4all.net Sat Jul 15 22:52:27 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 15 Jul 2000 23:52:27 +0200 Subject: [Python-Dev] More discussion on new infix operators In-Reply-To: ; from huaiyu_zhu@yahoo.com on Sat, Jul 15, 2000 at 01:30:31PM -0700 References: <1248451855-51961207@hypernet.com> Message-ID: <20000715235226.J7340@xs4all.nl> On Sat, Jul 15, 2000 at 01:30:31PM -0700, Huaiyu Zhu wrote: > 1.a) is unacceptable because infix operators improve readability > tremendously compared with prefix operators. Where's the usability study to prove that ? Seriously, though, claiming it is 'unacceptable' without providing arguments ? Why is it unacceptable ? This solution has proven perfectly acceptable for regular expressions, amongst other things. We have Perl gurus, addicted to perl's builtin regexp syntax, join us all the time. And you bet those perl people are addicted to short and confusing notations! > 1.b) is unacceptable because it is too long and involves at least two method > calls and object initialization for each operation. Not necessarily, it depends on your implementation. I would suggest something as follows (probably highly inaccurate because I know didley squat about matrices, but I'll give it a try): class Matrix: "A container class to hold matrices." def __init__(self, ): self.matrix = self.elementwise = ElementwiseMatrix(self.matrix) def __mul__(self, val): return self.matrix.normalmultiply(val) <...> class ElementwiseMatrix: "A container class to hold matrices, implementing elementwise operators." def __init__(self, matrix): self.matrix = matrix def __mul__(self, val): return self.matrix.elementwisemultiply(val) <...> This will allow you to do something like this, given that 'a' and 'b' are Matrices: a.elementwise * b.elementwise to yield a new Matrix (or whatever would be most convenient.) With the Cycle-GC patch, which is in 2.0, you can rewrite them a bit and add some circular references (or you can do that now, if you don't mind having a manual '.destroy()' method) so you can retrieve 'a' if you only have 'a.elementwise'. (Though I would suggest making the front-ends for the real matrix as small as possible, not containing any data themselves, and just create a new one whenever necessary. You just need to be sure not to use 'is' on the front-ends, then, but that's all.) And like this, you can use 'ae = a.elementwise' and pass 'ae' around and operate on it. And this also works immediately with augmented assignment, which might be in 2.0. As for performance, two method calls and an object initialization aren't really a problem, are they ? If you're looking for speed in many little calculations, Python is the wrong language. If you're looking for speed in large calculations, you won't notice this extra overhead. And in the proposal above, the overhead is reduced anyway. And like this, I'd say the whole thing is a lot more Pythonic! And it clearly reflects the 'dual personality' of matrices. > I hope, and I do believe personally, that it will acquire wide-spread usage > once such basic facilities are provided, and will eventually be integrated > into the core language. It would be next to impossible to change operators > at that moment. Therefore I am most interested in hearing any thoughts on > whether there exist any mortal danger for introducing the dot operators. > For example, will it be confused with any planned new language features? Well, I can (and will!) only speak for myself, but in my opinion, the addition of the 'dot' operators would conflict more with the core of the language than any specific feature. The entire philosophy of Python is to keep it as clear and simple and easy to understand as possible. In that light, even the use of the '%' symbol as the printf-operator is a mistake, and I actually agree with that -- even though it's extremely useful. It will be hard to explain to people who have no notion of strings, let alone printf() ;-) The 'dot' operators, though, remind me of the stories about ANSI C and how Microsoft tried to convince the ANSI committee in charge of C to include keywords specifically for the intel architecture. ('near', 'far', and two others, I forget. They are (were?) necessary to deal with the way DOS (and Windows ?) handles Intel's segmented memory model.) Even at that time, the PC was the most used computer around, but the committee decided against including these keywords. The PC might have have been the most used C programming platform, but the committee argued that no single platform should have that much impact on the programming language. (*) I think the 'dot' operators are in the same position. It might bring a lot of people to see the light if it had special matrix syntax, and that syntax might even be applicable in a few other areas without causing too much confusions. And I'd be happy for those people if they did see the light ;) But it stays a single domain, and Python isn't just about drawing as many people to Python as possible. At least, not in my humble opinion. In short, I'm -0 on this idea. If the BDFL is indeed benificial in your case, I won't put up a fight, but I wouldn't add it myself. But-then-I'm-only-+0-on-augmented-assignment-myself<0.3 wink>-ly y'rs, (* This story comes from Peter v.d. Linden's Deep C Secrets. I'm sure Tim, having sat on that committee under one alias or another, can tell this story much more accurately ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Sat Jul 15 23:01:56 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 00:01:56 +0200 Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970BA65.5DBFB39A@prescod.net>; from paul@prescod.net on Sat, Jul 15, 2000 at 02:24:21PM -0500 References: <3970B1F4.D4D8BAE9@prescod.net> <010e01bfee90$224df960$f2a6b5d4@hagrid> <3970BA65.5DBFB39A@prescod.net> Message-ID: <20000716000155.K7340@xs4all.nl> On Sat, Jul 15, 2000 at 02:24:21PM -0500, Paul Prescod wrote: > Fredrik Lundh wrote: > > why not just post a site.py patch, and forget about the > > PEP for now? > Also, how should I include a new module in a patch? Do I do a directory > diff? Or just checkin the stupid thing? You can supposedly use 'cvs add' to add the name, and then *not* commit ;) If you then use cvs diff, it should show up. Alternatively, and this is probably best, checkout a new copy of the tree (or simply do a 'cp -pPR') and diff between those two. In franctic times, it can be a hassle to get them both up to date, but if you're just going for a diff that adds a new file, that doesn't matter. (I remember trying to create a good patch in the weekend of July 1st. It was horrible, by the time an update had finished, things it had updated at the start were already changed again :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Sat Jul 15 23:20:49 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 00:20:49 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> <39709962.1C0A576E@lemburg.com> <005c01bfee83$4bafc480$f2a6b5d4@hagrid> <3970A737.6B13B543@lemburg.com> <008b01bfee89$8e731460$f2a6b5d4@hagrid> Message-ID: <3970E3C1.B8718924@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Cool :-) > > oh, just wait until I've gotten my head around Christian's > superoptimizations ;-) BTW, I didn't see your generator script in the patch... could you explain what the tables contain and how they are built ? > > (I'd suggest keeping the original names, BTW) > > unicodedata and unicodectype are okay, but frankly, isn't > "ucnhash" overly cryptic? True. > how about "unicodenames"? Sounds ok to me :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat Jul 15 23:27:16 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 00:27:16 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: Message-ID: <3970E544.ED8C7213@lemburg.com> Moshe Zadka wrote: > > On Sat, 15 Jul 2000, Fredrik Lundh wrote: > > > paul wrote: > > > As soon as you find a character out of the ASCII range in one of the > > > strings, I think that you should report that the two strings are > > > unequal. > > > > sounds reasonable -- but how do you flag "unequal" in cmp? which > > value is "larger" if all that we know is that they're different... > > We can say something like "beyond the ASCII range, every unicode character > is larger then any regular 8-bit character", and compare > lexicographically. The usual method in the Python compare logic is to revert to the type name for compares in case coercion fails... I think this is the right description in this case: decoding fails and thus coercion becomes impossible. PyObject_Compare() has the logic, we'd just have to reenable it for Unicode which currently is handled as special case to pass through the decoding error. Note that Unicode objects which don't coerce would then always compare larger than 8-bit strings ("unicode" > "string"). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat Jul 15 23:56:33 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 00:56:33 +0200 Subject: [Python-Dev] Linker problems on Linux References: <3970A619.D2CA39AA@lemburg.com> <20000715204410.I7340@xs4all.nl> Message-ID: <3970EC21.1112C71@lemburg.com> Thomas Wouters wrote: > > On Sat, Jul 15, 2000 at 07:57:45PM +0200, M.-A. Lemburg wrote: > > > I just tried to compile the current CVS version on Linux. > > The compile went fine, but when I started Python, I got: > > > 'import site' failed; use -v for traceback > > Python 2.0b1 (#1, Jul 15 2000, 19:22:33) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > > Traceback (most recent call last): > > File "/home/lemburg/bin/pyinteractive.py", line 7, in ? > > import mx.Tools > > File "/home/lemburg/projects/mx/Tools/__init__.py", line 24, in ? > > from Tools import * > > File "/home/lemburg/projects/mx/Tools/Tools.py", line 10, in ? > > from mxTools import * > > File "/home/lemburg/projects/mx/Tools/mxTools/__init__.py", line 1, in ? > > from mxTools import * > > ImportError: /home/lemburg/projects/mx/Tools/mxTools/mxTools.so: undefined symbol: PyObject_Length > > > Why isn't PyObject_Length being exported anymore ??? > > PyObject_Length is changed into a #define, to PyObject_Size. This preserves > the API but not the ABI ;) GCC has a construct to make one function an alias > for another: > > PyObject * PyObject_Length() __attribute__((alias("PyObject_Size"))); > > But this is not likely to work in other compilers, and not on all > architectures to start with. The most portable solution is probably to make > PyObject_Length() a wrapper for PyObject_Size, and hope the compiler knows > how to handle that most efficiently. Right, there will have to be an exported API PyObject_Length() which then does nothing other than to call PyObject_Size(). There's an example of how this can be done in ceval.c (see the PyEval_CallObject() API). Why hasn't anyone objected to simply dropping such an important API without proper backwards compatibility workaround ? The situation on Windows is already bad enough with extensions compiled against 1.5 causing a segfault... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one@email.msn.com Sun Jul 16 00:09:01 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 15 Jul 2000 19:09:01 -0400 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <3970EC21.1112C71@lemburg.com> Message-ID: [M.-A. Lemburg] > ... > Why hasn't anyone objected to simply dropping such an important > API without proper backwards compatibility workaround ? If I knew it was happening, I would have whined. And I expect Guido would have screamed. So let's fix it, and move on. I expect patch review isn't as good as it used to be because of the clumsy SourceForge interface, so nobody noticed. > The situation on Windows is already bad enough with extensions > compiled against 1.5 causing a segfault... Hey, your now-buggy old extensions aren't our fault . it's-windows-segfaults-are-a-feature-ly y'rs - tim From thomas@xs4all.net Sun Jul 16 00:53:44 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 01:53:44 +0200 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <3970EC21.1112C71@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 12:56:33AM +0200 References: <3970A619.D2CA39AA@lemburg.com> <20000715204410.I7340@xs4all.nl> <3970EC21.1112C71@lemburg.com> Message-ID: <20000716015344.M7340@xs4all.nl> On Sun, Jul 16, 2000 at 12:56:33AM +0200, M.-A. Lemburg wrote: > Right, there will have to be an exported API PyObject_Length() which > then does nothing other than to call PyObject_Size(). There's an > example of how this can be done in ceval.c (see the PyEval_CallObject() > API). Agreed. I've uploaded a patch that does this to SF. Someone please review it and apply it if desired. I need to head to bed or I won't get breakfast in bed tomorrow ;) > Why hasn't anyone objected to simply dropping such an important > API without proper backwards compatibility workaround ? I claim naivete for myself ;-) I remember seeing the patch go past, and wondering briefly if that wouldn't break binary compatibility. And I remember thinking "Naah, they wouldn't have approved it if that was an issue." :) Green-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bckfnn@worldonline.dk Sun Jul 16 01:02:04 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Sun, 16 Jul 2000 00:02:04 GMT Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <14704.34077.358194.82087@beluga.mojam.com> References: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: <3970fb6d.33279713@smtp.worldonline.dk> On Sat, 15 Jul 2000 10:37:01 -0500 (CDT), you wrote: > >Nothing has really jumped out as the "right" way to express the proposed >builtin that does > > map(None, l1, l2, l3, l4) How about paste? Properly only makes any sense to users who know the unix command tho. regards, finn From paul@prescod.net Sun Jul 16 02:14:30 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 20:14:30 -0500 Subject: [Python-Dev] Help command Message-ID: <39710C75.A7DB127F@prescod.net> Okay, I wrote the help command today. The transcript before was just a Microsoft-style "Technology Preview." I'm pretty happy with the extent to which I can pull in HTML and get lots of content from Fred's HTML distribution immediately. The only trick is finding out where the documentation is. I know that Unix users have a variety of installation patterns and I have no idea if this works at all on the Macintosh. Please help! Here's my current scheme: if os.environ.has_key("PYTHONDOCS"): self.docdir=os.environ["PYTHONDOCS"] else: if os.environ.has_key("PYTHONHOME"): pyhome=os.environ["PYTHONHOME"] else: pyhome=os.path.split( sys.executable )[0] self.docdir=os.path.join( pyhome, "doc" ) testfile=os.path.join( os.path.join( self.docdir, "lib" ), "index.html") if not os.path.exists( testfile ): raise EnvironmentError, ("Cannot find documentation directory" + self.docdir ) -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Sun Jul 16 02:44:55 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 20:44:55 -0500 Subject: [Python-Dev] Help command Message-ID: <39711397.1D3F38A1@prescod.net> Would anyone scream if I just checked this help module in? You can play with it without a site.py patch. Just import it "by hand". A patch is somewhat cumbersome for a new module and a lot less people would try it if they had to hunt down and install a particular patch. I could check it in, we could try it out for a week and then just as easily I could delete it if people don't like it. There is no impact on any other code. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From tim_one@email.msn.com Sun Jul 16 02:52:19 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 15 Jul 2000 21:52:19 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CB@RED-MSG-50> Message-ID: [Bill Tutt] > I just had a rather unhappy epiphany this morning. > F1, and f2 in ucnhash.c might not work on machines where > sizeof(long) != 32 bits. If "not work" means "may not return the same answer as when a long does have exactly 32 bits", then yes, it's certain not to work. Else I don't know -- I don't understand the (undocumented) postconditions (== what does "work" mean, exactly?) for these functions. If getting the same bits is what's important, f1 can be repaired by inserting this new block: /* cut back to 32 bits */ x &= 0xffffffffL; if (x & 0x80000000L) { /* if negative as a 32-bit thing, extend sign bit to full precision */ x -= 0x80000000L; /* subtract 2**32 in a portable way */ x -= 0x80000000L; /* by subtracting 2**31 twice */ } between the existing x ^= cch + 10; and if (x == -1) This assumes that negative numbers are represented in 2's-complement, but should deliver the same bits in the end on any machine for which that's true (I don't know of any Python platform for which it isn't). The same shoe work for f2 after replacing its negative literal with a 0x...L bit pattern too. The assumption about 2's-comp, and the new "if" block, could be removed by making these functions compute with and return unsigned longs instead. I don't know why they're using signed longs now (the bits produced are exactly the same either way, up until the "%" operation, at which point C is ill-defined when using signed long). BTW, you can test stuff like this on Win32 by cloning the function and using _int64 instead of long in the copy, then see whether they get the same results. From gstein@lyra.org Sun Jul 16 04:47:10 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 15 Jul 2000 20:47:10 -0700 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 15, 2000 at 07:09:01PM -0400 References: <3970EC21.1112C71@lemburg.com> Message-ID: <20000715204710.B29590@lyra.org> On Sat, Jul 15, 2000 at 07:09:01PM -0400, Tim Peters wrote: > [M.-A. Lemburg] > > ... > > Why hasn't anyone objected to simply dropping such an important > > API without proper backwards compatibility workaround ? > > If I knew it was happening, I would have whined. And I expect Guido would > have screamed. So let's fix it, and move on. I expect patch review isn't > as good as it used to be because of the clumsy SourceForge interface, so > nobody noticed. That has nothing to do with it. A full discussion occurred here on what to do. The consensus was reached and the code was changed. I knew it was happening, and I hardly ever look at the Patch Manager. In other words, you can't place the blame there. Personally, I had no issue with it at all. Python 1.5 extensions are not compatible with Python 1.6. We knew that already. So if they have to recompile anyways, then they are going to pick up the macro redefinition. No big deal. > > The situation on Windows is already bad enough with extensions > > compiled against 1.5 causing a segfault... Unrelated FUD. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sun Jul 16 04:55:40 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 15 Jul 2000 20:55:40 -0700 Subject: [Python-Dev] Help command In-Reply-To: <39711397.1D3F38A1@prescod.net>; from paul@prescod.net on Sat, Jul 15, 2000 at 08:44:55PM -0500 References: <39711397.1D3F38A1@prescod.net> Message-ID: <20000715205540.C29590@lyra.org> On Sat, Jul 15, 2000 at 08:44:55PM -0500, Paul Prescod wrote: > Would anyone scream if I just checked this help module in? You can play > with it without a site.py patch. Just import it "by hand". A patch is > somewhat cumbersome for a new module and a lot less people would try it > if they had to hunt down and install a particular patch. I could check > it in, we could try it out for a week and then just as easily I could > delete it if people don't like it. There is no impact on any other code. +1. check the sucker in. I would doubt that anybody has a problem with the *idea*. We can quibble over details much easier with it actually part of the distro. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Moshe Zadka Sun Jul 16 05:59:06 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 16 Jul 2000 07:59:06 +0300 (IDT) Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <3970fb6d.33279713@smtp.worldonline.dk> Message-ID: On Sun, 16 Jul 2000, Finn Bock wrote: > On Sat, 15 Jul 2000 10:37:01 -0500 (CDT), you wrote: > > > > >Nothing has really jumped out as the "right" way to express the proposed > >builtin that does > > > > map(None, l1, l2, l3, l4) > > How about paste? Properly only makes any sense to users who know the > unix command tho. I've been using UNIX for the past 5 years, and have only a dim recollection on paste (when I start doing things that require "cut" and "paste" I usually rich for my big guns like Python (and Perl before that)) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Moshe Zadka Sun Jul 16 06:02:27 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 16 Jul 2000 08:02:27 +0300 (IDT) Subject: [Python-Dev] Help command In-Reply-To: <39710C75.A7DB127F@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Okay, I wrote the help command today. The transcript before was just a > Microsoft-style "Technology Preview." I'm pretty happy with the extent > to which I can pull in HTML and get lots of content from Fred's HTML > distribution immediately. The only trick is finding out where the > documentation is. I know that Unix users have a variety of installation > patterns and I have no idea if this works at all on the Macintosh. > Please help! In a Red Hat installation, they don't install the HTML docs at all. But then, you don't want to know what I think of Red Hat (demonstrating Python on Red Hat systems usually requires me to resort to slight-of-hand tricks every now and then) In a Debian installation, they live in /usr/doc/python/... (In short, have it a compiled in default. Whoever packages it will decide) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Moshe Zadka Sun Jul 16 06:03:32 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 16 Jul 2000 08:03:32 +0300 (IDT) Subject: [Python-Dev] Help command In-Reply-To: <39711397.1D3F38A1@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Would anyone scream if I just checked this help module in? You can play > with it without a site.py patch. Just import it "by hand". A patch is > somewhat cumbersome for a new module and a lot less people would try it > if they had to hunt down and install a particular patch. I'm +1, as long as the module says on the top ''' # experimental module -- might change interface or die without notice ''' Or something to that effect -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From tim_one@email.msn.com Sun Jul 16 06:24:15 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 01:24:15 -0400 Subject: [Python-Dev] Help command In-Reply-To: <39711397.1D3F38A1@prescod.net> Message-ID: [Paul Prescod] > Would anyone scream if I just checked this help module in? Sure, but who cares? I won't scream at you, and I've been so bitchy lately nobody will even respond to me anymore . Do it! Agree with Moshe that a disclaimer about its experimental nature be prominently displayed at the top, lest we get locked into supporting its initial flawlets forever. From tim_one@email.msn.com Sun Jul 16 06:49:27 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 01:49:27 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2D5@RED-MSG-50> Message-ID: [Bill Tutt] > After making use of the test drive Alphas by Compaq, I just > uploaded a patch to SF that should fix this nasty issue. > Ugh. Not fun.... Ah, I replied earlier before seeing this. Please see my earlier response for a simpler change that will actually work . Briefly, > > len = cch; > > p = (unsigned char *) key; > > - x = 1694245428; > > + x = (long)0x64fc2234; No point to this change (although there *is* for the *negative* literal in f2). And (for f2) note that the way to spell a long literal is with "L" at the end, not via casting an int literal to long. > > while (--len >= 0) > > - x = (1000003*x) ^ toupper(*(p++)); > > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); No point to either of the changes here (you're effectively doing a mod 2**32 on each step, but that isn't necessary -- doing just one at the end (after the loop) is equivalent). > > x ^= cch + 10; > > - if (x == -1) > > - x = -2; > > + if (x == (long)0xFFFFFFFF) > > + x = (long)0xfffffffe; This is wrong in too many ways to count . But your tests won't show the failure unless x *does* happen to equal -1 at the end of the preceding, and you're extremely unlikely to bump into that in a small batch of test cases. Short course: on the 32-bit long machine, x will be -2 after this block then. But on the 64-bit long machine, x will be 2**32-2 (a large and unrelated positive long). The change I suggested is simpler & avoids all those problems; alas, like the above, it also assumes 2's-complement representation of negative longs. From esr@thyrsus.com Sun Jul 16 07:27:38 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Sun, 16 Jul 2000 02:27:38 -0400 Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <14704.34077.358194.82087@beluga.mojam.com> References: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: <20000716022738.B1517@thyrsus.com> Skip Montanaro : > Nothing has really jumped out as the "right" way to express the proposed > builtin that does > > map(None, l1, l2, l3, l4) > > How about collate? What we're doing is effectively what a copy machine does > when it collates multiple copies of its input... At least as good as "knit" and "plait". Better than "weave" (sorry, Barry) and without the unhelpful connotations of "marry" and "zip". A bit long, though. -- Eric S. Raymond Everything you know is wrong. But some of it is a useful first approximation. From esr@thyrsus.com Sun Jul 16 07:40:25 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Sun, 16 Jul 2000 02:40:25 -0400 Subject: [Python-Dev] what to call this zip() function? In-Reply-To: References: Message-ID: <20000716024025.C1517@thyrsus.com> Ka-Ping Yee : > The analogy with a photocopying machine is pretty good, but > i'm afraid this will play havoc with those who see "collate" in > terms of determining sort order. *ouch* Damn. Ping is right. He just blew "collate" out of the water, folks. > It's fairly clear to me that, of the names that evoke images > of some sort, only "parallel", "march", and "merge" are actually > accurate. "zip" and "marry" are nearly accurate except that they > usually give the impression that only two things are being joined. Well argued (and cool pictures, too!). I think parallel, zip, and marry are out for various reasons of connotative overload, so we're down to "merge", "meld", and "knit". -- Eric S. Raymond The end move in politics is always to pick up a gun. -- R. Buckminster Fuller From Fredrik Lundh" <20000716024025.C1517@thyrsus.com> Message-ID: <004b01bfeeff$59f28380$f2a6b5d4@hagrid> eric: > ping: > > The analogy with a photocopying machine is pretty good, but > > i'm afraid this will play havoc with those who see "collate" in > > terms of determining sort order. >=20 > *ouch* >=20 > Damn. Ping is right. He just blew "collate" out of the water, folks. is this the end of Python development? just imagine what this crowd would have done if guido had asked you *before* he added things like: dir ("hey, dir should give you a list of filenames") cgi ("the computer graphics crowd won't like that") del ("removes files, right?") compile ("but people will think that it generates machine code") global ("but it's not truly global. how about regional or domestic?") hash ("that's a data type, right?") ("or perhaps something from the The Amsterdam Aloha Seed Bank?") hex ("now wait. it's not clear from the name if it con- verts a hex string to an integer, or the other way around. oh, it's the latter. sorry, but that will confuse perl pro- grammers") type ("is that some variation of print, or?") copy ("I'd say most people expect it to copy entire files") and so on... ... maybe something completely random? how about: ymr116c ("sorry, this will confuse the hell out of yeast researchers") ... how about a new rule: if the group fails to reach consensus on a name, especially if they're not discussion the semantics at all, just pick the original name. "zip", in other words. simple zip patches has already been posted to this list. why not take them on a test drive, and see if the *semantics* are what you want them to be? (in the meantime, maybe someone could run the zip/collate/etc thing by comp.lang.python. maybe people are smarter than we think?) From Fredrik Lundh" Message-ID: <005f01bfef00$75fcbf40$f2a6b5d4@hagrid> tim wrote: > If "not work" means "may not return the same answer as when a long = does have > exactly 32 bits", then yes, it's certain not to work. Else I don't = know -- > I don't understand the (undocumented) postconditions (=3D=3D what does = "work" > mean, exactly?) for these functions. he's using the hash function to look things up in a static table... fwiw, "ucnhash" might be slightly obsolete (see my "unicodenames" patch for a smaller replacement). as far as I can tell, my hash function = should work on a 64-bit machine... ...on the other hand, it currently assumes that an "int" is at least 32 = bits. should I change this? do we still pretend to support 16-bit computers? From Moshe Zadka Sun Jul 16 09:29:42 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 16 Jul 2000 11:29:42 +0300 (IDT) Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <004b01bfeeff$59f28380$f2a6b5d4@hagrid> Message-ID: On Sun, 16 Jul 2000, Fredrik Lundh wrote: > how about a new rule: if the group fails to reach consensus > on a name, especially if they're not discussion the semantics > at all, just pick the original name. > > "zip", in other words. +1. The dir() example shows that pkzip is a non-issue. (After all, we have a dircache module which has no connection to the builtin dir(), and no one seems to have any problems with that) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From billtut@microsoft.com Sun Jul 16 09:35:56 2000 From: billtut@microsoft.com (Bill Tutt) Date: Sun, 16 Jul 2000 01:35:56 -0700 Subject: [Python-Dev] RE: Unicode character name hashing Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2DE@RED-MSG-50> Not that any of this is terribly important given F bot's new patch, except for wrt to the perfect hash generation code. But... > Tim wrote: > [Bill Tutt] > > I just had a rather unhappy epiphany this morning. > > F1, and f2 in ucnhash.c might not work on machines where > > sizeof(long) != 32 bits. > If "not work" means "may not return the same answer as when a long does have > exactly 32 bits", then yes, it's certain not to work. Else I don't know -- > I don't understand the (undocumented) postconditions (== what does "work" > mean, exactly?) for these functions. "Works" means that f1, and f2 must always generate the same bits no matter what platform they're executed on > If getting the same bits is what's important, f1 can be repaired by > inserting this new block: > /* cut back to 32 bits */ > x &= 0xffffffffL; > if (x & 0x80000000L) { > /* if negative as a 32-bit thing, extend sign bit to full precision */ > x -= 0x80000000L; /* subtract 2**32 in a portable way */ > x -= 0x80000000L; /* by subtracting 2**31 twice */ > } > between the existing > x ^= cch + 10; > and > if (x == -1) > This assumes that negative numbers are represented in 2's-complement, but > should deliver the same bits in the end on any machine for which that's true > (I don't know of any Python platform for which it isn't). The same shoe > work for f2 after replacing its negative literal with a 0x...L bit pattern > too. > The assumption about 2's-comp, and the new "if" block, could be removed by > making these functions compute with and return unsigned longs instead. I > don't know why they're using signed longs now (the bits produced are exactly > the same either way, up until the "%" operation, at which point C is > ill-defined when using signed long). The SF patch does indeed use unsigned longs. Bill From thomas@xs4all.net Sun Jul 16 10:01:51 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 11:01:51 +0200 Subject: [Python-Dev] Help command In-Reply-To: ; from moshez@math.huji.ac.il on Sun, Jul 16, 2000 at 08:02:27AM +0300 References: <39710C75.A7DB127F@prescod.net> Message-ID: <20000716110151.N7340@xs4all.nl> On Sun, Jul 16, 2000 at 08:02:27AM +0300, Moshe Zadka wrote: > On Sat, 15 Jul 2000, Paul Prescod wrote: > > Okay, I wrote the help command today. The transcript before was just a > > Microsoft-style "Technology Preview." I'm pretty happy with the extent > > to which I can pull in HTML and get lots of content from Fred's HTML > > distribution immediately. The only trick is finding out where the > > documentation is. I know that Unix users have a variety of installation > > patterns and I have no idea if this works at all on the Macintosh. > > Please help! > In a Red Hat installation, they don't install the HTML docs at all. > But then, you don't want to know what I think of Red Hat (demonstrating > Python on Red Hat systems usually requires me to resort to slight-of-hand > tricks every now and then) Don't forget that RedHat isn't impervious to outside influence. Adding this help thing might make them realize installing the HTML docs is a good idea ;-) And who knows, they might even add documentation for their snackmodule. +1 on the whole idea from me, too. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Fredrik Lundh" <39709962.1C0A576E@lemburg.com> <005c01bfee83$4bafc480$f2a6b5d4@hagrid> <3970A737.6B13B543@lemburg.com> <008b01bfee89$8e731460$f2a6b5d4@hagrid> <3970E3C1.B8718924@lemburg.com> Message-ID: <007d01bfef07$4e53fd80$f2a6b5d4@hagrid> mal wrote: > BTW, I didn't see your generator script in the patch... could > you explain what the tables contain and how they are built ? I'm working on the ctype/data portions right now; I'll update the patch along the way, including the generator script when it's ready. (in other words, treat this patch as experimental until it includes the entire database). From mal@lemburg.com Sun Jul 16 10:29:44 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 11:29:44 +0200 Subject: [Python-Dev] Linker problems on Linux References: <3970EC21.1112C71@lemburg.com> <20000715204710.B29590@lyra.org> Message-ID: <39718088.A4172516@lemburg.com> Greg Stein wrote: > > On Sat, Jul 15, 2000 at 07:09:01PM -0400, Tim Peters wrote: > > [M.-A. Lemburg] > > > ... > > > Why hasn't anyone objected to simply dropping such an important > > > API without proper backwards compatibility workaround ? > > > > If I knew it was happening, I would have whined. And I expect Guido would > > have screamed. So let's fix it, and move on. I expect patch review isn't > > as good as it used to be because of the clumsy SourceForge interface, so > > nobody noticed. > > That has nothing to do with it. A full discussion occurred here on what to > do. The consensus was reached and the code was changed. I don't believe that Guido reached any consensus on this... he has always tried to make releases as binary compatible as possible (which is a very user friendly way of designing software). > I knew it was happening, and I hardly ever look at the Patch Manager. In > other words, you can't place the blame there. > > Personally, I had no issue with it at all. Python 1.5 extensions are not > compatible with Python 1.6. We knew that already. So if they have to > recompile anyways, then they are going to pick up the macro redefinition. Sure they are... what makes you think that 1.5 extensions won't work with 1.6 ? Ok, you get annoying warnings, but it's still better as temporary solution than putting out a new version of Python which won't work together with most existing extensions simply due to linker problems. > No big deal. Ok, Greg, you pay the support bill ;-) > > > The situation on Windows is already bad enough with extensions > > > compiled against 1.5 causing a segfault... > > Unrelated FUD. Why unrelated ? Why FUD ? The problem is real (until we check in the fix). Anyway, enough ranting ;-) ... I'll review Thomas Wouters patch and then check it in. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Sun Jul 16 10:34:50 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 11:34:50 +0200 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <39718088.A4172516@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 11:29:44AM +0200 References: <3970EC21.1112C71@lemburg.com> <20000715204710.B29590@lyra.org> <39718088.A4172516@lemburg.com> Message-ID: <20000716113449.P7340@xs4all.nl> On Sun, Jul 16, 2000 at 11:29:44AM +0200, M.-A. Lemburg wrote: > Anyway, enough ranting ;-) ... I'll review Thomas Wouters patch > and then check it in. Wait a couple of minutes. I didn't follow your instructions closely enough, the new patch does ;-) (old patch just added back the functions as wrappers, but didn't #define them as the PyEval_CallObject one did.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Sun Jul 16 10:43:39 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 11:43:39 +0200 Subject: [Python-Dev] SF login names Message-ID: <397183CB.6415C6BC@lemburg.com> Is there a login name to real name mapping available on SF ? I'm just asking because login names such as "VizNut" or "nowonder" don't carry enough information to identify the person behind it and I think it would be nice to know who you are talking to in patch dicsussions ;-) Perhaps the initial submission comment should include the full name of the patch author ?! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut@microsoft.com Sun Jul 16 10:47:57 2000 From: billtut@microsoft.com (Bill Tutt) Date: Sun, 16 Jul 2000 02:47:57 -0700 Subject: [Python-Dev] [patch #100889] a smaller unicode name database] Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2DF@RED-MSG-50> From: "Fredrik Lundh" > > my unicode database compression project has resulted in its first > > patch: > > > > https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100899&gro up_id=5470 > two additional comments: > first, the patch was too large for sourceforge (>512000 bytes), so > I've uploaded it to the secret effbot site instead: > http://w1.132.telia.com/~u13208596/uninames-patch.txt > second, the uninames module provides two public Python functions: > getname(code) returns the character name corresponding to > the given character code, or None if the name is not known. > > getcode(name) returns the character code for the given character > name. again, it returns None if the code is not known. Getcode/getname need to use Py_UCS4 instead of int. Smaller data sizes are definitely cool, but as MAL mentioned you didn't include the genration code, nor an explanation about how the stuff works. Looking good so far! Bill From thomas@xs4all.net Sun Jul 16 10:51:31 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 11:51:31 +0200 Subject: [Python-Dev] SF login names In-Reply-To: <397183CB.6415C6BC@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 11:43:39AM +0200 References: <397183CB.6415C6BC@lemburg.com> Message-ID: <20000716115131.Q7340@xs4all.nl> On Sun, Jul 16, 2000 at 11:43:39AM +0200, M.-A. Lemburg wrote: > Is there a login name to real name mapping available on SF ? There's the search engine: the input field with a selector above it, in the bottom left corner. You can type in 'BigBrassBalz' and select 'people', hit 'search', and it'll tell you that's Tim Peters, and provide a link with more information. > I'm just asking because login names such as "VizNut" or > "nowonder" don't carry enough information to identify the person > behind it and I think it would be nice to know who you are > talking to in patch dicsussions ;-) Well, sometimes the realname isn't even that much help ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Fredrik Lundh" Message-ID: <00c101bfef0c$dad680c0$f2a6b5d4@hagrid> mal wrote: > Is there a login name to real name mapping available on SF ? use the search box in the lower left; just change "software/group" to "people", and type the login name... > I'm just asking because login names such as "VizNut" or > "nowonder" don't carry enough information to identify the > person behind it here's a few: viznut =3D randall hopper nowonder =3D peter schneider-kamp flight =3D gregor hoffleit effbot =3D dunno htrd =3D toby dickenson=20 ...and the "what the heck does that mean" award goes to: nyamatongwe =3D neil hodgson cheers /F From mal@lemburg.com Sun Jul 16 11:07:32 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 12:07:32 +0200 Subject: [Python-Dev] SF login names References: <397183CB.6415C6BC@lemburg.com> <00c101bfef0c$dad680c0$f2a6b5d4@hagrid> Message-ID: <39718964.1679361C@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Is there a login name to real name mapping available on SF ? > > use the search box in the lower left; just change "software/group" > to "people", and type the login name... Thanks for the hint. > > I'm just asking because login names such as "VizNut" or > > "nowonder" don't carry enough information to identify the > > person behind it > > here's a few: > > viznut = randall hopper > nowonder = peter schneider-kamp > flight = gregor hoffleit > effbot = dunno > htrd = toby dickenson > > ...and the "what the heck does that mean" award goes to: > > nyamatongwe = neil hodgson :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" <39709844.595B84F6@lemburg.com> Message-ID: <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> mal wrote: > > 1. treat \x as a hexadecimal byte, not a hexadecimal > > character. or in other words, make sure that > >=20 > > ord("\xabcd") =3D=3D ord(u"\xabcd") > >=20 > > fwiw, this is how it's done in SRE's parser (see the > > python-dev archives for more background). ... > > 5. leave it as it is (just fix the comment). >=20 > I'd suggest 5 -- makes converting 8-bit strings using \x > to Unicode a tad easier. if that's the main argument, you really want alternative 1. with alternative 5, the contents of the string may change if you add a leading "u". alternative 1 is also the only reasonable way to make ordinary strings compatible with SRE (see the earlier discussion for why SRE has to be strict on this one...) so let's change the question into a proposal: for maximum compatibility with 8-bit strings and SRE, let's change "\x" to mean "binary byte" in unicode string literals too. From Fredrik Lundh" <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> <02c701bfedae$7db6fd20$f2a6b5d4@hagrid> <000d01bfedd7$122db480$f2a6b5d4@hagrid> Message-ID: <00ff01bfef18$f3914260$f2a6b5d4@hagrid> I wrote: > not quite ready to be checked in, but good enough to take > on a test drive: >=20 > = http://sourceforge.net/patch/?func=3Ddetailpatch&patch_id=3D100895&group_= id=3D5470 anyone looked at this? should I check it in, and see what happens? From Moshe Zadka Sun Jul 16 12:27:21 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 16 Jul 2000 14:27:21 +0300 (IDT) Subject: [Python-Dev] PyErr_SafeFormat In-Reply-To: <00ff01bfef18$f3914260$f2a6b5d4@hagrid> Message-ID: On Sun, 16 Jul 2000, Fredrik Lundh wrote: > anyone looked at this? I did. It looked all right, except for the "default" in the switch statements. or-maybe-i-didn't-understand-it-at-all-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Fredrik Lundh" Message-ID: <011501bfef1a$40495880$f2a6b5d4@hagrid> moshe wrote: > On Sun, 16 Jul 2000, Fredrik Lundh wrote: >=20 > > anyone looked at this? >=20 > I did. It looked all right, except for the "default" in the switch > statements. what's wrong with the default clause? the idea is that if it stumbles upon a formatting code it doesn't understand, it copies the rest of the format string to the output string (it cannot just skip unknown codes, since there's no way to know what's in the argument list...) if you can think of a better approach, let me know asap. cheers /F From Moshe Zadka Sun Jul 16 12:55:18 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 16 Jul 2000 14:55:18 +0300 (IDT) Subject: [Python-Dev] PyErr_SafeFormat In-Reply-To: <011501bfef1a$40495880$f2a6b5d4@hagrid> Message-ID: On Sun, 16 Jul 2000, Fredrik Lundh wrote: > what's wrong with the default clause? That it wasn't clear... > the idea is that if it stumbles upon a formatting code it doesn't > understand, it copies the rest of the format string to the output > string (it cannot just skip unknown codes, since there's no way > to know what's in the argument list...) Seems reasonable. I'm +1 on that as long as you take the above paragraph and stick it in a comment somewhere in the patch. aw-to-hel-with-documentation-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From mal@lemburg.com Sun Jul 16 13:13:57 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 14:13:57 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> Message-ID: <3971A705.B23AD7D3@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > > 1. treat \x as a hexadecimal byte, not a hexadecimal > > > character. or in other words, make sure that > > > > > > ord("\xabcd") == ord(u"\xabcd") > > > > > > fwiw, this is how it's done in SRE's parser (see the > > > python-dev archives for more background). > ... > > > 5. leave it as it is (just fix the comment). > > > > I'd suggest 5 -- makes converting 8-bit strings using \x > > to Unicode a tad easier. > > if that's the main argument, you really want alternative 1. > > with alternative 5, the contents of the string may change > if you add a leading "u". Ah ok, now I understand what you meant "\xfffe" will turn out as "\xfe", while u"\xfffe" results in u"\ufffe". > alternative 1 is also the only reasonable way to make ordinary > strings compatible with SRE (see the earlier discussion for why > SRE has to be strict on this one...) > > so let's change the question into a proposal: > > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. Hmm, this is probably not in sync with C9X (see section 6.4.4.4), but then perhaps we should depreciate usage of \xXX in the context of Unicode objects altogether. Our \uXXXX notation is far superior to what C9X tries to squeeze into \x (IMHO at least). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sun Jul 16 13:25:12 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 14:25:12 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> <02c701bfedae$7db6fd20$f2a6b5d4@hagrid> <000d01bfedd7$122db480$f2a6b5d4@hagrid> <00ff01bfef18$f3914260$f2a6b5d4@hagrid> Message-ID: <3971A9A8.705AA86E@lemburg.com> Fredrik Lundh wrote: > > I wrote: > > > not quite ready to be checked in, but good enough to take > > on a test drive: > > > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 > > anyone looked at this? > > should I check it in, and see what happens? The patch needs some docs which go into api.tex. Right now, all formatting codes supported by printf() are allowed. Your patch changes this into a useful, but far more limited set of codes. In the end, I would prefer the solution I mentioned a few days ago: add checks to configure which determine the availability of snprintf() and then put a macro def into pyport.h which either uses snprintf() (if available) or simply drops the length argument and sticks with sprintf(). Since snprintf() will become a standard anyway, why try to emulate its behaviour ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Moshe Zadka Sun Jul 16 13:45:02 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 16 Jul 2000 15:45:02 +0300 (IDT) Subject: [Python-Dev] PyErr_SafeFormat In-Reply-To: <3971A9A8.705AA86E@lemburg.com> Message-ID: On Sun, 16 Jul 2000, M.-A. Lemburg wrote: > In the end, I would prefer the solution I mentioned a few days > ago: add checks to configure which determine the availability > of snprintf() and then put a macro def into pyport.h which > either uses snprintf() (if available) or simply drops the > length argument and sticks with sprintf(). > > Since snprintf() will become a standard anyway, why try to > emulate its behaviour ? I'm -1 on that approach. Python tries to cater to low-end C compilers as well, and even when snprintf() will become a standard, it will take time to become a widely available standard. /F's patch works *right* *now* on almost every C compiler. python-turned-ansi-only-when-c9x-is-on-the-brink-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From barry@scottb.demon.co.uk Sun Jul 16 13:46:56 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Sun, 16 Jul 2000 13:46:56 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <20000714141801.T29590@lyra.org> Message-ID: <000001bfef23$ec90ce30$060210ac@private> I've been looking at the code to see how hard it is to implement my two function solution to the mismatched extensions crash. I can do the work to generate a patch if the following analysis and design is acceptable. Requirements as I see it are: 1. Python extensions must match the python core to work correctly 2. Python must only load an extension that is compatible with its API 3. Extensions written against python15 do not have to work against python16 etc. 4. No Python Core resources available for implementing backward compatibility for API changes. 5. Extension writers prefer new version of Python to refuse to load old extensions rather the risk subtle bugs through compatibility code in core. I'll use XXX to stand in for the extension name. The changes require that pointers to two functions are returned rather the one to initXXX. The function prefixes "init" and "APIversion" might be made more python specific rather then generic. I propose: - PythonExtensionInitModuleXXX - PythonExtenaionApiVersionXXX The current code calls _PyImport_GetDynLoadFunc that is implemented once for each OS. There are 9 implemented currently. Each does the prepend of "init" to the "shortname" function name. If two function pointers are to be returned then the single function _PyImport_GetDynLoadFunc will need to change into a pair of functions to prevent the possiblity of loading the shared lib twice. _PyImport_GetDynLoadModule return a handle to a dynamically loaded module _PyImport_GetDynLoadFunction return a pointer to a function from a module _PyImport_LoadDynamicModule would call _PyImport_GetDynLoadModule once to load the module and then call _PyImport_GetDynLoadFunction twice to get the pair of function pointers. [Q: _PyImport_LoadDynamicModule may still crash if the Python cannot catch failures in the OS load mechanism.] _PyImport_GetDynLoadFunction will no longer prefix the "init" as that is part of the algorithm of _PyImport_LoadDynamicModule. _PyImport_GetDynLoadFunction would do any name manging that the OS requires to load find the symbol. Prefixing of "_" for example on some unixes. Each extension module implements PythonExtensionInitModuleXXX and PythonExtensionApiVersionXXX. PythonExtensionInitModuleXXX is implemented as before. PythonExtensionApiVersionXXX returns the value PYTHON_API_VERSION as defined in modsupport.h. [Q: Is PYTHON_API_VERSION the corrent symbol?] int PythonExtensionApiVersionXXX() { return PYTHON_API_VERSION; } void PythonExtensionInitModuleXXX() { /* init stuff for module XXX */ } _PyImport_LoadDynamicModule will: 1. Try to load the module - on failure reports an error 2. Try to find PythonExtensionInitModuleXXX from module - on failure report not a python extension - no initXXX function 3. Try to find PythonExtensionApiVersionXXX from module - on failure report its an old extension - please upgrade 4. Call PythonExtensionApiVersionXXX and compare to PYTHON_API_VERSION - if not equal report its an old extension - please upgrade 5. Call PythonExtensionInitModuleXXX Comments please? BArry From bckfnn@worldonline.dk Sun Jul 16 13:42:01 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Sun, 16 Jul 2000 12:42:01 GMT Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> Message-ID: <39719b4f.12749973@smtp.worldonline.dk> [Fredrik Lundh] >mal wrote: > >> > 1. treat \x as a hexadecimal byte, not a hexadecimal >> > character. or in other words, make sure that >> >=20 >> > ord("\xabcd") =3D=3D ord(u"\xabcd") >> >=20 >> > fwiw, this is how it's done in SRE's parser (see the >> > python-dev archives for more background). >... >> > 5. leave it as it is (just fix the comment). >>=20 >> I'd suggest 5 -- makes converting 8-bit strings using \x >> to Unicode a tad easier. > >if that's the main argument, you really want alternative 1. > >with alternative 5, the contents of the string may change >if you add a leading "u". > >alternative 1 is also the only reasonable way to make ordinary >strings compatible with SRE (see the earlier discussion for why >SRE has to be strict on this one...) > >so let's change the question into a proposal: > > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. This would potentially break JPython where the \x is already used to introduce 16-bit chars in ordinary strings. OTOH the implementation of \x in JPython is so full of bugs and inconsistencies that I'm +1 on your proposal. regards, finn From gmcm@hypernet.com Sun Jul 16 14:07:55 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Sun, 16 Jul 2000 09:07:55 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007141437.JAA13178@cj20424-a.reston1.va.home.com> References: Your message of "Thu, 13 Jul 2000 14:34:03 -0400." <396E0B9B.DD74EF5@interet.com> Message-ID: <1248369603-56908500@hypernet.com> There seems to be some confusion about this subject. Clarification: An extension compiled for 1.5 will, when loaded by 1.6 / 2.0 either: - fail to load (python15.dll not found) - crash (python15.dll found) This is because the typical way of building an extension on Windows has you link against the import lib for the current version of Python. An import lib is nothing like a static lib - it's a bit of stub code (which gets statically linked in) which automatically does the dynamic load of the associated dll. In other words, python15.lib (the import lib) automatically loads python15.dll at runtime. 1) One proposed solution was to remove the version number from the python dll, and rely on binary compatibility. As Mark said, this would "probably" work. The problem being that moving from "probably" to "certainly" is very difficult. And a failure would be every bit as messy as the current situation (crash - except you've removed any easy way of diagnosing the situation). 2) Another was to stop putting pythonxx.dll in the system directory - that breaks COM support. 3) Another is to have the 1.6 / 2.0 installer remove any other versions of the python dll from the system directory. But that breaks having multiple versions of python installed (which *does* work). 4) Another would be to build extensions with the version number in the name (eg, kjbuckets15.dll), with some added magic to the c-extension import code (so "import kjbuckets" evaluates to loading "kjbuckets" + sys.winver-with-the-dot- removed + ['.dll' | '.pyd']). I don't think this would break anything (but it would tax the capabilities of your typical Windows developer ). 5) The last "solution" I can think of is the Tcl stubs mechanism. In this scenario, the extension would not link against any import lib for python at all. It would rely on getting a pointer to a (large) table of pointers to python-exported functions and symbols in the initmodule call. There's a lot of drudge work involved in setting this up. It does mean that binary compatibility can always be maintained, or if it's decided to break binary compatibility, failure can be made "graceful" . (It also means that embedders could statically link in python, and still dynamically load extensions). Unfortunately, this solution still doesn't help with the transition from 1.5 to 1.6 / 2.0. 6) Of course, we can also do nothing. This is not as bad as it has been painted. Extensions on Windows are supposed to live in the DLLs subdirectory (although certain package writers don't follow this convention); and since this is a new install, it's a new directory. So we tell users not to move extensions from their old install into the new one. Extension writers who don't follow this convention (you know who you are) can figure out their own responses. In an ideal world, I rather like #5 (stubs), but I vote for #4 (version number in the extension module name) or #6 (get a life). - Gordon From nhodgson@bigpond.net.au Sun Jul 16 14:24:23 2000 From: nhodgson@bigpond.net.au (Neil Hodgson) Date: Sun, 16 Jul 2000 23:24:23 +1000 Subject: [Python-Dev] SF login names References: <397183CB.6415C6BC@lemburg.com> <00c101bfef0c$dad680c0$f2a6b5d4@hagrid> Message-ID: <038501bfef29$295f9210$8119fea9@neil> > ...and the "what the heck does that mean" award goes to: > > nyamatongwe = neil hodgson About as off-topic as possible ;) nyama="meat" and ngwe="piece of land" so maybe place with good hunting. Its a hill in South-East Zimbabwe and I haven't managed to get there yet. Place names make good account and password names as they can be fairly obscure but still memorable. I expected to fix SourceForge up with a more obvious name once the account was working but its a pain to change stuff on SF so haven't done so. Neil From paul@prescod.net Sun Jul 16 14:49:45 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 08:49:45 -0500 Subject: [Python-Dev] Help command References: Message-ID: <3971BD79.D4F378CD@prescod.net> Moshe Zadka wrote: > > ... > > In a Red Hat installation, they don't install the HTML docs at all. What docs are installed? As I recall, "man Python" was similarly useless on my last Red Hat machine. Hopefully that's been fixed but of course we don't deliver our docs in man format. It was very frustrating to find Python "hidden" like that when I knew that Red Hat uses it extensively themselves. I also wanted it to have an icon in their little start menu thing. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Sun Jul 16 14:51:06 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 08:51:06 -0500 Subject: [Python-Dev] htmllib Message-ID: <3971BDCA.1D69F1CB@prescod.net> I'm having a problem with htmllib. It worked fine in the alpha but not now. I presume it is either sre or unicode. Before I "dig in", is htmllib supposed to work or is someone still working on incompatibilities between it and sre/unicode. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Sun Jul 16 15:04:43 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 09:04:43 -0500 Subject: [Python-Dev] what to call this zip() function? References: <20000716024025.C1517@thyrsus.com> <004b01bfeeff$59f28380$f2a6b5d4@hagrid> Message-ID: <3971C0FB.9EDDF76@prescod.net> Fredrik Lundh wrote: > > ... > > (in the meantime, maybe someone could run the zip/collate/etc > thing by comp.lang.python. maybe people are smarter than we > think?) Agree that the universe will not collapse no matter what name we choose. Unless it has a totally backwards name, people will see it in use and figure it out. We could just do a straight-up vote and be done with it. There is clearly no right or wrong answer, just answers that appeal to various people. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Moshe Zadka Sun Jul 16 15:08:58 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 16 Jul 2000 17:08:58 +0300 (IDT) Subject: [Python-Dev] Help command In-Reply-To: <3971BD79.D4F378CD@prescod.net> Message-ID: On Sun, 16 Jul 2000, Paul Prescod wrote: > > In a Red Hat installation, they don't install the HTML docs at all. > > What docs are installed? The LaTeX files. Did I say how much I enjoy working on Red Hat machines yet? linux-users-should-use-a-real-distribution-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas@xs4all.net Sun Jul 16 15:09:47 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 16:09:47 +0200 Subject: [Python-Dev] Help command In-Reply-To: <3971BD79.D4F378CD@prescod.net>; from paul@prescod.net on Sun, Jul 16, 2000 at 08:49:45AM -0500 References: <3971BD79.D4F378CD@prescod.net> Message-ID: <20000716160947.T7340@xs4all.nl> On Sun, Jul 16, 2000 at 08:49:45AM -0500, Paul Prescod wrote: > Moshe Zadka wrote: > > In a Red Hat installation, they don't install the HTML docs at all. > What docs are installed? As I recall, "man Python" was similarly useless > on my last Red Hat machine. Hopefully that's been fixed but of course we > don't deliver our docs in man format. It was very frustrating to find > Python "hidden" like that when I knew that Red Hat uses it extensively > themselves. I also wanted it to have an icon in their little start menu > thing. Last I checked, the documentation came in a seperate RPM apckage, And it was just the TeX files, not HTML. And it was just the Library Reference in /usr/doc/python-docs-1.5.2/Doc/, not Doc/lib as one would expect. Oh, there seems to be the Language Reference as well, in /usr/doc/python-docs-1.5.2/Doc/ref/, but those are in FrameMaker format (ref*.doc files. Never heard of FrameMaker myself.) In short, ferget it ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From dberlin@redhat.com Sun Jul 16 15:21:11 2000 From: dberlin@redhat.com (Daniel Berlin+list.python-dev) Date: 16 Jul 2000 10:21:11 -0400 Subject: [Python-Dev] Help command In-Reply-To: Moshe Zadka's message of "Sun, 16 Jul 2000 17:08:58 +0300 (IDT)" References: Message-ID: Moshe Zadka writes: > On Sun, 16 Jul 2000, Paul Prescod wrote: > > > > In a Red Hat installation, they don't install the HTML docs at all. > > > > What docs are installed? > > The LaTeX files. Did I say how much I enjoy working on Red Hat machines > yet? > Yeah, and we love you too. J/K. If you like, I can yell at the people responsible for this, but i'm sure they'll just flame me. --Dan From gmcm@hypernet.com Sun Jul 16 15:57:45 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Sun, 16 Jul 2000 10:57:45 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <000001bfef23$ec90ce30$060210ac@private> References: <20000714141801.T29590@lyra.org> Message-ID: <1248363013-57304903@hypernet.com> Barry Scott wrote: > I've been looking at the code to see how hard it is to > implement my two function solution to the mismatched > extensions crash. > > I can do the work to generate a patch if the following > analysis and design is acceptable. > > Requirements as I see it are: > > 1. Python extensions must match the python core to work correctly Not necessarily. > 2. Python must only load an extension that is compatible with its > API > 3. Extensions written against python15 do not have to work > against python16 etc. > 4. No Python Core resources available for implementing backward > compatibility for API changes. > 5. Extension writers prefer new version of Python to refuse to > load > old extensions rather the risk subtle bugs through > compatibility code in core. > > I'll use XXX to stand in for the extension name. > > The changes require that pointers to two functions are > returned rather the one to initXXX. You may be making things more complex than they need to be. On (most?) *nixen, a dynamic load is basically a runtime link. If the link fails (a symbol has disappeared), the module won't load. IOW, I think it's really only when an API call has changed semantics that you need to worry. [Some unixen still don't support dynamic loading; others, eg AIX, do it sufficiently differently to cause havoc with portability; but I think it's fair to say it's a "runtime link".] Further, it's now common practice to have xxx.so be a link to xxx.major.minor.shoesize.so, so diagnosis is relatively easy. In other words, aren't we *only* worried about Windows? If not, then: > int PythonExtensionApiVersionXXX() > { > return PYTHON_API_VERSION; > } is rather restrictive, since you can't write a module at 2.1 time that declares itself compatible with 2.0. Better to pass in the running version, and return yes / no. Now on Windows, since a good chunk of the "link" was done at compile time, the only possible answer is return arg == PYTHON_API_VERSION; But if we're only worried about Windows, I think hacking the Windows load code to turn import kjbuckets into a LoadLibraryEx of kjbuckets+2digitversion+extension does the same thing with less pain. OTOH, I'm willing to live with a procedural solution: - the installer creates a fresh DLLs subdirectory - users are warned not to move extensions into the new DLLs directory, but to get new ones - extension writers who don't use the DLLs directory can - be glad they coded defensively - be sorry they didn't. - Gordon From paul@prescod.net Sun Jul 16 15:20:29 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 09:20:29 -0500 Subject: [Python-Dev] Help command References: Message-ID: <3971C4AD.74EFAD90@prescod.net> Moshe Zadka wrote: > > On Sun, 16 Jul 2000, Paul Prescod wrote: > > > > In a Red Hat installation, they don't install the HTML docs at all. > > > > What docs are installed? > > The LaTeX files. Did I say how much I enjoy working on Red Hat machines > yet? > > linux-users-should-use-a-real-distribution-ly y'rs, Z. Does "man python" work yet? Or maybe my installation was just messed up. As an aside, I think that there are three reasons that it would be nice if we delivered the Python documentation in man format: 1. man(1) die-hards (blow-hards!) would be happy 2. man open() etc. would return Python information which is a way of advertising Python 3. documenting every function in every programming language in a common namespace is a ridiculous idea and by contributing to the problem we can do our part to kill a tool that has lived long past its time. :) -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Sun Jul 16 16:33:13 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 10:33:13 -0500 Subject: [Python-Dev] Help command References: Message-ID: <3971D5B9.A39DA465@prescod.net> "Daniel Berlin+list.python-dev" wrote: > > ... > > If you like, I can yell at the people responsible for this, but i'm > sure they'll just flame me. Wouldn't it make sense for the people packaging the software to talk directly to the people creating the software? I want to put an interactive intepreter dependency on the HTML documentation. I need a guarantee that future Red Hats will install the help files properly. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From thomas@xs4all.net Sun Jul 16 16:58:35 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 17:58:35 +0200 Subject: [Python-Dev] Help command In-Reply-To: <3971C4AD.74EFAD90@prescod.net>; from paul@prescod.net on Sun, Jul 16, 2000 at 09:20:29AM -0500 References: <3971C4AD.74EFAD90@prescod.net> Message-ID: <20000716175835.Y7340@xs4all.nl> On Sun, Jul 16, 2000 at 09:20:29AM -0500, Paul Prescod wrote: > Does "man python" work yet? Or maybe my installation was just messed up. Nope. > As an aside, I think that there are three reasons that it would be nice > if we delivered the Python documentation in man format: > 1. man(1) die-hards (blow-hards!) would be happy Hey, I resemble that remark ! I actually use the Perl manpages every now and then, because it's hard to find stuff about operators and special variables in perldoc. But then, there is hardly any need for that in Python ;) > 2. man open() etc. would return Python information which is a way of > advertising Python 'man open()' would probably return the 'open' command (catagory 1) from the 'open' package, at least on Linux :-) On other systems, it would most likely show the 'open' system call, not the python call. You'd have to fix manpath to search python paths before system paths for that ;) I'm not against supplying the Python library reference in man-form, I'm just not very sure what form it would have or how useful it would be. > 3. documenting every function in every programming language in a common > namespace is a ridiculous idea and by contributing to the problem we can > do our part to kill a tool that has lived long past its time. :) Say what you will, man(1) is a great tool for what it does. Info sucks for that, so does HTML. Info is a nice way to bundle a package's information, and to supply introductions and extended manuals in a way that 'man' cannot, but man stays the quickest quick-ref, man! (But I agree, adding TCL and Perl (and Python!) functions in the common manpath is a silly idea. Lets keep it for the C/POSIX API, commands and the system files ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Fredrik Lundh" Message-ID: <001d01bfef40$9383d860$f2a6b5d4@hagrid> paul wrote: > I'm having a problem with htmllib. It worked fine in the alpha but not > now. I presume it is either sre or unicode. Before I "dig in", is > htmllib supposed to work or is someone still working on > incompatibilities between it and sre/unicode. probably SRE. try replacing "import re" with "import pre; re =3D pre" in htmllib.py, and see if the problem goes away. From tim_one@email.msn.com Sun Jul 16 17:49:51 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 12:49:51 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2DE@RED-MSG-50> Message-ID: [Bill Tutt] > Not that any of this is terribly important given F bot's new patch ... Ack! Nevermind. Old and in the way. From tim_one@email.msn.com Sun Jul 16 17:49:53 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 12:49:53 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <005f01bfef00$75fcbf40$f2a6b5d4@hagrid> Message-ID: [/F] > fwiw, "ucnhash" might be slightly obsolete (see my "unicodenames" patch > for a smaller replacement). as far as I can tell, my hash function should > work on a 64-bit machine... Will look at it once I find it . > ...on the other hand, it currently assumes that an "int" is at > least 32 bits. > > should I change this? Absolutely! "long" is the only way current C has to spell "at least 32". A natural opportunity to put some C9X-derived typedefs into pyport.h, like typedef long Py_int_fast32_t; typedef unsigned long Py_uint_fast32_t; That may be a lie on some 64-bit machines, but it's a benign lie (i.e., will still *work*), and people working on those machines can slop in the #ifdef's they need to cut those back to int (or even short) when appropriate. > do we still pretend to support 16-bit computers? I don't, but we're interested in minimizing the amount of telepathy needed to understand the code regardless. Guido most often used "long" to mean "at least 32" elsewhere in the codebase (this is why the Reference Manual guarantees that a Python int is at least 32 bits, i.e. because C guarantees "long" is) -- in accord with good C practice at the time, and, as it turned out, with what ISO/ANSI standardized. "int" doesn't mean anything to me when I see it except "huh -- this code is probably going to break someday" <0.5 wink>. The C9X typedefs allow to remove all guessing about intent. From Fredrik Lundh" <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> Message-ID: <004101bfef49$e2c0cb00$f2a6b5d4@hagrid> > so let's change the question into a proposal: >=20 > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. I've prepared a small patch. If nobody objects, I'll check it in next weekend, or so... http://sourceforge.net/patch/index.php?func=3Ddetailpatch&patch_id=3D1009= 12&group_id=3D5470 From mal@lemburg.com Sun Jul 16 18:58:23 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 19:58:23 +0200 Subject: [Python-Dev] RE: Unicode character name hashing References: Message-ID: <3971F7BF.321997AA@lemburg.com> Tim Peters wrote: > [hash function in unicodename] > > ...on the other hand, it currently assumes that an "int" is at > > least 32 bits. > > > > should I change this? > > Absolutely! "long" is the only way current C has to spell "at least 32". Note that Unicode code which needs enough bits to hold a UCS4 value should always use the Py_UCS4 type (see unicodeobject.h)... any changes needed to assure the 32-bit nature should then be made to the Py_UCS4 typedef. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sun Jul 16 18:59:33 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 19:59:33 +0200 Subject: [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> <004101bfef49$e2c0cb00$f2a6b5d4@hagrid> Message-ID: <3971F805.D6937139@lemburg.com> Fredrik Lundh wrote: > > > so let's change the question into a proposal: > > > > for maximum compatibility with 8-bit strings and SRE, > > let's change "\x" to mean "binary byte" in unicode string > > literals too. > > I've prepared a small patch. If nobody objects, I'll check > it in next weekend, or so... > > http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100912&group_id=5470 There were objections from Finn Bock and myself: \xXXXX is defined to mean "read all hex chars until the next non-hex char and then cast to the underlying type (char or wchar_t)" in C9X. Don't know about Java... Finn ? Not that this definition is optimal, but we should stick to what the standard says and only depreciate usage of \xXXXX in favour of \uXXXX. Code using escapes like "\xABCD" which then results in "\xCD" is broken anyway -- having u"\xABCD" return "\uABCD" wouldn't make much of a difference (+ the bug would become pretty obvious if viewed in a Unicode aware viewer: Asian characters are very easy to recognize in ASCII text ;-) Would it be hard to make JPython support \uXXXX ? (Or does it already ?) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From DavidA@ActiveState.com Sun Jul 16 19:15:17 2000 From: DavidA@ActiveState.com (David Ascher) Date: Sun, 16 Jul 2000 11:15:17 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B7F3.28F64A3E@prescod.net> Message-ID: > help is not a magical function/statement but an instance with a repr > that does the right thing. And yes, it will probably only be loaded at > the repl. Or it could be a 10-line instance that loads its content when > it is actually used. That might allow Geez, guys, that's one of the first things I did for Python! The URL is long dead, but i think there's a version in the contrib ftp directory. I think I called it ihelp. I used the emacs info files, so is way out of date. --david PS: Then again, these days I'd rather work out an API for a help lookup mechanims that the twelve IDEs could all use, rather than encourage people to stick with glass tty's =). From tim_one@email.msn.com Sun Jul 16 19:14:02 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 14:14:02 -0400 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: <3971A705.B23AD7D3@lemburg.com> Message-ID: [/F] > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. [MAL] > Hmm, this is probably not in sync with C9X (see section 6.4.4.4), The behavior of \x in C9X is nearly incomprehensible -- screw it. > but then perhaps we should depreciate usage of \xXX in the context > of Unicode objects altogether. Our \uXXXX notation is far > superior to what C9X tries to squeeze into \x (IMHO at least). \x is a hack inherited from the last version of C, put in back when they knew they had to do *something* to support "big characters" but had no real idea what. C9X was not allowed to break anything in the std it built on, so they kept all the old implementation-defined \x behavior, and made it even more complicated so it would make some kind sense with the new C9X character gimmicks. Python is stuck trying to make sense out of its ill-considered adoption of old-C's \x notation too. Letting it mean "a byte" regardless of context should make it useless enough that people will eventually learn to avoid it . Note that C9X also has \u and \U notations, and \u in C9X means what it does in Python, except that C9X explicitly punts on what happens for \u values in these (inclusive) ranges: \u0000 - \u0020 \u007f - \u009f \ud800 - \udfff \U is used in C9X for 8-digit (hex) characters, deferring to ISO 10646. If C9X didn't *have* to keep \x around, I'm sure they would have tossed it. From jeremy@beopen.com Sun Jul 16 19:24:20 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Sun, 16 Jul 2000 14:24:20 -0400 (EDT) Subject: [Python-Dev] Linker problems on Linux In-Reply-To: References: <3970EC21.1112C71@lemburg.com> Message-ID: <14705.64980.579728.132423@bitdiddle.concentric.net> >>>>> "TP" == Tim Peters writes: TP> [M.-A. Lemburg] >> ... Why hasn't anyone objected to simply dropping such an >> important API without proper backwards compatibility workaround ? TP> If I knew it was happening, I would have whined. And I expect TP> Guido would have screamed. Actually, I wasn't sure we had reached consensus on the list before I checked it in, so I got an explicit okay from Guido before I made the changes. I know I didn't think about binary compatibility, and suspect that Guido overlooked it as well. TP> So let's fix it, and move on. I TP> expect patch review isn't as good as it used to be because of TP> the clumsy SourceForge interface, so nobody noticed. We got reviews of the patch, too. Fred suggested a small cleanup of the original patch. That said, I don't object to binary compatibility. I'm +0 on the patch. Jeremy From dberlin@redhat.com Sun Jul 16 19:23:43 2000 From: dberlin@redhat.com (Daniel Berlin+list.python-dev) Date: 16 Jul 2000 14:23:43 -0400 Subject: [Python-Dev] Help command In-Reply-To: Paul Prescod's message of "Sun, 16 Jul 2000 10:33:13 -0500" References: <3971D5B9.A39DA465@prescod.net> Message-ID: Paul Prescod writes: > "Daniel Berlin+list.python-dev" wrote: > > > > ... > > > > If you like, I can yell at the people responsible for this, but i'm > > sure they'll just flame me. > > Wouldn't it make sense for the people packaging the software to talk > directly to the people creating the software? Let me find out who owns that RPM. I'm just on the same mailing lists as the development department and whatnot. (I'm a GDB engineer, Cygnus was bought by redhat) > I want to put an > interactive intepreter dependency on the HTML documentation. I need a > guarantee that future Red Hats will install the help files properly. From tim_one@email.msn.com Sun Jul 16 19:24:56 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 14:24:56 -0400 Subject: [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? In-Reply-To: <3971F805.D6937139@lemburg.com> Message-ID: [/F] > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. > > I've prepared a small patch. If nobody objects, I'll check > it in next weekend, or so... > > [patch 100912] [MAL] > There were objections from Finn Bock and myself: \xXXXX is > defined to mean "read all hex chars until the next non-hex char > and then cast to the underlying type (char or wchar_t)" in C9X. Python and C9X are different languages -- Python isn't obligated to ape C9X's backward-compatibility hacks. > Don't know about Java... Finn ? Java doesn't have \x notation, period -- Java isn't insane . Finn was talking about JPython's attempts to make sense of Python's \x notation. > Not that this definition is optimal, but we should stick to what > the standard says ... Why? It's a standard for a different language. Most of what C9X says about \x boils down to "implementation-defined" anyway, and that's unPythonic on the face of it. From Fredrik Lundh" <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> <004101bfef49$e2c0cb00$f2a6b5d4@hagrid> <3971F805.D6937139@lemburg.com> Message-ID: <007701bfef54$848a2300$f2a6b5d4@hagrid> mal wrote: > There were objections from Finn Bock and myself: \xXXXX is > defined to mean "read all hex chars until the next non-hex char > and then cast to the underlying type (char or wchar_t)" in C9X. finn wrote:=20 "the implementation of \x in JPython is so full of bugs and inconsistencies that I'm +1 on your proposal." since when is +1 an objection? ;-) > Not that this definition is optimal, but we should stick to what > the standard says and only depreciate usage of \xXXXX in favour > of \uXXXX. Code using escapes like "\xABCD" which then results > in "\xCD" is broken anyway -- having u"\xABCD" return "\uABCD" > wouldn't make much of a difference (+ the bug would become pretty > obvious if viewed in a Unicode aware viewer: Asian characters are > very easy to recognize in ASCII text ;-) as Tim pointed out in the SRE thread, the only standard that means something here is Python 1.5.2. And in Python 1.5.2, \u means read as many hex digits as you can, and cast the result to a character. I'd say it's more important to be compatible with Python (1.5.2 string literals, SRE regular expression literals), than to be com- patible with C9X... From tim_one@email.msn.com Sun Jul 16 19:29:46 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 14:29:46 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <3971F7BF.321997AA@lemburg.com> Message-ID: [MAL] > Note that Unicode code which needs enough bits to hold a UCS4 > value should always use the Py_UCS4 type (see unicodeobject.h)... > any changes needed to assure the 32-bit nature should then > be made to the Py_UCS4 typedef. That's fine. The Py_UCS4 typedef should in turn be defined by direct reference to a C9X-derived typedef from pyport.h: the latter is where 32-bitness "should be" defined. Then the only changes ever needed will be to pyport.h (where people will *expect* such changes to get made). From mal@lemburg.com Sun Jul 16 19:33:45 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 20:33:45 +0200 Subject: [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> <004101bfef49$e2c0cb00$f2a6b5d4@hagrid> <3971F805.D6937139@lemburg.com> <007701bfef54$848a2300$f2a6b5d4@hagrid> Message-ID: <39720009.970A7159@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > There were objections from Finn Bock and myself: \xXXXX is > > defined to mean "read all hex chars until the next non-hex char > > and then cast to the underlying type (char or wchar_t)" in C9X. > > finn wrote: > > "the implementation of \x in JPython is so full of bugs > and inconsistencies that I'm +1 on your proposal." > > since when is +1 an objection? ;-) Ooops, I must have overlooked that one. > > Not that this definition is optimal, but we should stick to what > > the standard says and only depreciate usage of \xXXXX in favour > > of \uXXXX. Code using escapes like "\xABCD" which then results > > in "\xCD" is broken anyway -- having u"\xABCD" return "\uABCD" > > wouldn't make much of a difference (+ the bug would become pretty > > obvious if viewed in a Unicode aware viewer: Asian characters are > > very easy to recognize in ASCII text ;-) > > as Tim pointed out in the SRE thread, the only standard that > means something here is Python 1.5.2. And in Python 1.5.2, > \u means read as many hex digits as you can, and cast the > result to a character. > > I'd say it's more important to be compatible with Python (1.5.2 > string literals, SRE regular expression literals), than to be com- > patible with C9X... Ok, ok, go ahead :-) (please also update the docs, if there are any on this subject -- a grep didn't show anything up on \xXXX) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" Message-ID: <00b301bfef55$ba8992a0$f2a6b5d4@hagrid> bill wrote: > Smaller data sizes are definitely cool, but as MAL mentioned you = didn't > include the genration code, nor an explanation about how the stuff = works.=20 brute force ;-) seriously, it's a pretty simple design. here's an overview: The unicodenames database consists of two parts: a name database which maps character codes to names, and a code database, mapping names to codes. * The Name Database (getname) First, the 10538 text strings are split into 42193 words, and combined into a 4949-word lexicon (a 29k byte array). Each word is given a unique index number (common words get lower numbers), and there's a "lexicon offset" table mapping from numbers to words (10k). To get back to the original text strings, I use a "phrase book". For each original string, the phrase book stores a a list of word numbers. Numbers 0-127 are stored in one byte, higher numbers (less common words) use two bytes. At this time, about 65% of the words can be represented by a single byte. The result is a 56k array. The final data structure is an offset table, which maps code points to phrase book offsets. Instead of using one big table, I split each code point into a "page number" and a "line number" on that page. offset =3D line[ (page[code>>SHIFT]< From peter@schneider-kamp.de Sun Jul 16 22:11:25 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 16 Jul 2000 21:11:25 +0000 Subject: [Python-Dev] [PEP204] Range Literals References: Message-ID: <397224FD.B30D1368@schneider-kamp.de> Moshe Zadka wrote: > > I think we decided we don't need those. The only reason people need > generators is for extra efficiency in >From following the recent discussion here (and from my Haskell brain part) I thought that generators are also useful for stuff like: even = (0:sys.maxint:2) first20even = even[:20] Having spend the weekend falling into cold mountain lakes, I may of course be mistaken about this. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From jack@oratrix.nl Sun Jul 16 21:03:44 2000 From: jack@oratrix.nl (Jack Jansen) Date: Sun, 16 Jul 2000 22:03:44 +0200 Subject: [Python-Dev] ascii default encoding Message-ID: <20000716200349.BD9A059214@oratrix.oratrix.nl> Now that the default encoding for 8-bit strings has gone back to "ascii", shouldn't the initialization of strop.whitespace and friends only range over 0..128 in stead of 0..256? On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but the \312 causes problems because it can't be converted from/to unicode as long as the default encoding is ascii... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From paul@prescod.net Sun Jul 16 21:05:53 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 15:05:53 -0500 Subject: [Python-Dev] [PEP204] Range Literals References: <397224FD.B30D1368@schneider-kamp.de> Message-ID: <397215A1.5ED50D9@prescod.net> Peter Schneider-Kamp wrote: > > ... > > I thought that generators are also useful for stuff like: > > even = (0:sys.maxint:2) > first20even = even[:20] Yes but I doubt Guido would take that usage scenariou very seriously. He's been fairly disinterested in lazy behavior for a long time. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gvwilson@nevex.com Sun Jul 16 21:08:30 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Sun, 16 Jul 2000 16:08:30 -0400 (EDT) Subject: [Python-Dev] More discussion on new infix operators In-Reply-To: <20000715235226.J7340@xs4all.nl> Message-ID: > > On Sat, Jul 15, 2000 at 01:30:31PM -0700, Huaiyu Zhu wrote: > > > 1.a) is unacceptable because infix operators improve readability > > tremendously compared with prefix operators. > On Sat, 15 Jul 2000, Thomas Wouters wrote: > > Where's the usability study to prove that ? I'm with Huaiyu on this one --- scientists and engineers have had Lisp-style prefix notation thrown at them many times, and have always resisted it (just as most computer science departments have :-). Greg From mal@lemburg.com Sun Jul 16 21:10:08 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 22:10:08 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib onlinehelp.py,NONE,1.1 References: <200007161953.MAA30130@slayer.i.sourceforge.net> Message-ID: <397216A0.EE5BB26E@lemburg.com> [New onlinehelp module] Great work ! Wouldn't it make sense to hook the new [whatever it is called now... browser.py] into the module as standard way of displaying the help text provided PYTHONHELPBROWSER is set to one of the supported browsers ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sun Jul 16 21:14:54 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 22:14:54 +0200 Subject: [Python-Dev] ascii default encoding References: <20000716200349.BD9A059214@oratrix.oratrix.nl> Message-ID: <397217BE.29F69C28@lemburg.com> Jack Jansen wrote: > > Now that the default encoding for 8-bit strings has gone back to > "ascii", shouldn't the initialization of strop.whitespace and friends > only range over 0..128 in stead of 0..256? > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but > the \312 causes problems because it can't be converted from/to unicode > as long as the default encoding is ascii... string.py is depreciated -- please use string methods instead. Note that the 8-bit string methods are locale aware in case the C lib APIs isspace() and isalpha() support locales. You may have to adjust the locale setting to POSIX for these APIs to return ASCII only values. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul@prescod.net Sun Jul 16 21:18:42 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 15:18:42 -0500 Subject: [Python-Dev] Checked in... Message-ID: <397218A2.A90BCAB3@prescod.net> onlinehelp.py is checked in. Here's the docstring: This module is experimental and could be removed or radically changed at any time. It is intended specifically for the standard interpreter command line but is intended to be compatible with and useful for other (e.g. GUI, handheld) environments. Help with those other environments is appreciated. Please remember to set PYTHONDOCS to the location of your HTML files: e.g. set PYTHONDOCS=c:\python\docs PYTHONDOCS=/python/docs The docs directory should have a lib subdirectory with "index.html" in it. If it has *.tex then you have the documentation *source* distribution, not the runtime distribution. The module exposes one object: "help". "help" has a repr that does something useful if you just type: >>> from onlinehelp import help >>> help Of course one day the first line will be done automatically by site.py or something like that. help can be used as a function. The function takes the following forms of input: help( "string" ) -- built-in topic or global help( ) -- docstring from object or type help( "doc:filename" ) -- filename from Python documentation Type help to get the rest of the instructions. You can also use the module as a command line program: python onlinehelp.py "if" -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From martin@loewis.home.cs.tu-berlin.de Sun Jul 16 21:57:47 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 16 Jul 2000 22:57:47 +0200 Subject: [Python-Dev] Linker problems on Linux Message-ID: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> >> Why hasn't anyone objected to simply dropping such an important >> API without proper backwards compatibility workaround ? > If I knew it was happening, I would have whined. And I expect Guido > would have screamed. Although I ran into this as well, I don't think it is as bad as it sounds. The API has not been changed; only modules compiled for 1.5 (*) won't run in current CVS python - you have to recompile. Even if you restore the PySequence_Length as a Python entry point, you still get a warning that the ABI version mismatches. I haven't thoroughly checked, yet, but I believe that there is no way that Python 2 can guarantee binary compatibility for all 1.5.x modules. For example, if you have a 1.5.2-compiled type in an extension module, and that type happens to implement PySequenceMethods, then applying 'a in b' will likely crash: Python 2 will check for the sq_contains field, but that is past the end of the function table in the old module. So I think it is actually a good thing if an important ABI is not supported anymore. Instead of getting random crashes, you get an error on import. I wish there was a better way to gracefully fail when importing 1.5 modules on Windows. The approach of calling the entry not 'initxxx' but 'init2xxx' would work, but is quite inconvenient. Regards, Martin (*) modules compiled with last week's CVS python won't work, either, but if you have any of these, you know how to recompile things :-) From paul@prescod.net Sun Jul 16 21:58:22 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 15:58:22 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib onlinehelp.py,NONE,1.1 References: <200007161953.MAA30130@slayer.i.sourceforge.net> <397216A0.EE5BB26E@lemburg.com> Message-ID: <397221EE.D248C6D3@prescod.net> "M.-A. Lemburg" wrote: > > [New onlinehelp module] > > Great work ! > > Wouldn't it make sense to hook the new [whatever it is called > now... browser.py] into the module as standard way of displaying > the help text provided PYTHONHELPBROWSER is set to one of > the supported browsers ? Not for me. I would prefer to see the raw text rather than having a new window pop up. I would be happy to provide a mode that does this but I would rather it wasn't the default. Also, some of the text is docstrings. Presumably I wouldn't launch a browser for those, so the interface becomes somewhat inconsistent. How about this: if I taught urllib (or something) to translate doc: URLs into real URLs then you could do something like: browser.browse( "doc:lib/lambda" ) Maybe that would help...more thought needed. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From mhammond@skippinet.com.au Sun Jul 16 22:14:38 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 16 Jul 2000 17:14:38 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007141714.MAA14470@cj20424-a.reston1.va.home.com> Message-ID: > I guess the user should think about whether they want their Python COM > things to use 1.5 or 2.0. Only the one they choose should install its > DLL in the system directory; the other one should have its DLL in its > own directory. This may be a good idea - however, it is not necessary. Whatever version of Python was used to register the COM object is also used to execute it. Thus, you can have different objects on the same machine, each of which uses different Python versions. Indeed, the same process could potentially load 2 seperate versions of Python - this should work fine (although it has never been tested by me!) Mark. From mhammond@skippinet.com.au Sun Jul 16 22:14:40 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 16 Jul 2000 17:14:40 -0400 Subject: [Python-Dev] Help command In-Reply-To: <39710C75.A7DB127F@prescod.net> Message-ID: > Okay, I wrote the help command today. The transcript before was just a > Microsoft-style "Technology Preview." I'm pretty happy with the extent > to which I can pull in HTML and get lots of content from Fred's HTML ... > Here's my current scheme: Note that on Windows, there is a help key in the registry that points to the various help files. The core installer uses this, as does the win32all installer. Pythonwin reads this key to populate the "Help" menu. Mark. From gstein@lyra.org Sun Jul 16 22:19:22 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 14:19:22 -0700 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 16, 2000 at 02:14:02PM -0400 References: <3971A705.B23AD7D3@lemburg.com> Message-ID: <20000716141921.K29590@lyra.org> To me, this says punt the \x construct from Unicode objects altogether. If it is broken, then why try to retain it? I *do* find it useful in the regular string objects. For Unicode, I would totally understand needing to use \u instead. Cheers, -g On Sun, Jul 16, 2000 at 02:14:02PM -0400, Tim Peters wrote: > [/F] > > for maximum compatibility with 8-bit strings and SRE, > > let's change "\x" to mean "binary byte" in unicode string > > literals too. > > [MAL] > > Hmm, this is probably not in sync with C9X (see section 6.4.4.4), > > The behavior of \x in C9X is nearly incomprehensible -- screw it. > > > but then perhaps we should depreciate usage of \xXX in the context > > of Unicode objects altogether. Our \uXXXX notation is far > > superior to what C9X tries to squeeze into \x (IMHO at least). > > \x is a hack inherited from the last version of C, put in back when they > knew they had to do *something* to support "big characters" but had no real > idea what. C9X was not allowed to break anything in the std it built on, so > they kept all the old implementation-defined \x behavior, and made it even > more complicated so it would make some kind sense with the new C9X character > gimmicks. > > Python is stuck trying to make sense out of its ill-considered adoption of > old-C's \x notation too. Letting it mean "a byte" regardless of context > should make it useless enough that people will eventually learn to avoid it > . > > Note that C9X also has \u and \U notations, and \u in C9X means what it does > in Python, except that C9X explicitly punts on what happens for \u values in > these (inclusive) ranges: > > \u0000 - \u0020 > \u007f - \u009f > \ud800 - \udfff > > \U is used in C9X for 8-digit (hex) characters, deferring to ISO 10646. > > If C9X didn't *have* to keep \x around, I'm sure they would have tossed it. > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From thomas@xs4all.net Sun Jul 16 22:19:08 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 23:19:08 +0200 Subject: [Python-Dev] ascii default encoding In-Reply-To: <397217BE.29F69C28@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 10:14:54PM +0200 References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> Message-ID: <20000716231908.A7340@xs4all.nl> On Sun, Jul 16, 2000 at 10:14:54PM +0200, M.-A. Lemburg wrote: > Jack Jansen wrote: > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but > > the \312 causes problems because it can't be converted from/to unicode > > as long as the default encoding is ascii... > string.py is depreciated -- please use string methods instead. You mean 'deprecated'. And please wait with deprecating string.py until all functionality is indeed available through string methods. And please don't do that :) I don't think " ".letters really makes sense... Besides, 'string.join' is a good compromise for the people who don't like " ".join() :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Sun Jul 16 22:25:53 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 23:25:53 +0200 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Sun, Jul 16, 2000 at 10:57:47PM +0200 References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> Message-ID: <20000716232553.B7340@xs4all.nl> On Sun, Jul 16, 2000 at 10:57:47PM +0200, Martin v. Loewis wrote: > For example, if you have a 1.5.2-compiled type in an extension module, > and that type happens to implement PySequenceMethods, then applying 'a > in b' will likely crash: Python 2 will check for the sq_contains > field, but that is past the end of the function table in the old > module. Nope. This is specifically fixed by the new tp_flags structmember (which was 'unused' before, so reading *that* will work ok) and the PyType_HasFeature macro. All code that wants to access one of the really new struct members (currently, bf_getcharbuffer, sq_contains and the cycle-gc stuff. And my augmented assignment patch adds another 13 ;) should check tp_flags first. See the comment in Include/object.h regarding this. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From martin@loewis.home.cs.tu-berlin.de Sun Jul 16 22:26:45 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 16 Jul 2000 23:26:45 +0200 Subject: [Python-Dev] onlinehelp unforgiving Message-ID: <200007162126.XAA25108@loewis.home.cs.tu-berlin.de> After installing the current Python CVS, I tried to do >>> from onlinehelp import help Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.0/onlinehelp.py", line 323, in ? help=Help(sys.stdout,24) File "/usr/local/lib/python2.0/onlinehelp.py", line 216, in __init__ raise EnvironmentError, error EnvironmentError: Cannot find documentation directory /usr/local/bin/doc. Set the PYTHONDOCS environment variable to point to a "doc" directory. It should have a subdirectory "Lib" with a file named "index.html". I was mainly interested in seeing the doc string retriever in real life. To do so, I'm in the process of obtaining a set of html files (hopefully typing make in the Doc directory will give me those). Still, I think that module should work without HTML help installed, and only fail if somebody tries to access the documentation. Or, there should be a function doc() in addition to help() for retrieving and printing doc strings. I'd actually prefer the second option: >>> doc(xml) Core XML support for Python. This package contains three sub-packages: dom -- The W3C Document Object Model. This supports DOM Level 1 + Namespaces. parser -- Python wrappers for XML parsers (currently only supports Expat). sax -- The Simple API for XML, developed by XML-Dev, led by David Megginson and ported to Python by Lars Marius Garshol. This supports the SAX 2 API. should work even without any documentation installed. In any case, I think this (or the help function) should be builtin. Regards, Martin From thomas@xs4all.net Sun Jul 16 22:33:17 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 23:33:17 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: <20000716141921.K29590@lyra.org>; from gstein@lyra.org on Sun, Jul 16, 2000 at 02:19:22PM -0700 References: <3971A705.B23AD7D3@lemburg.com> <20000716141921.K29590@lyra.org> Message-ID: <20000716233317.C7340@xs4all.nl> On Sun, Jul 16, 2000 at 02:19:22PM -0700, Greg Stein wrote: > To me, this says punt the \x construct from Unicode objects altogether. If > it is broken, then why try to retain it? > I *do* find it useful in the regular string objects. For Unicode, I would > totally understand needing to use \u instead. Don't forget the -U option to python, which turns all strings into Unicode strings. So it's broken now, that's no reason to break it some more ;) I also thought the long-term idea was to make all strings unicode strings. Making the two strings different in more than implementation is probably a bad idea. I'm with Tim here: screw the retarded compatibility. Make \x make sense in normal strings and unicode strings both, but in a way that breaks as little as possible: if it always results in one byte in 8bit strings, it should do the same, IMHO, in unicode strings. I'm also for making \x take at most four bytes, like the documentation states, instead of hassling with a perl-like construct such as C has. I would be very, very suprised if anyone was using \x29E8F28DA727 and expects it to work like \x27. We can use the beta cycle to see if it breaks anything. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Sun Jul 16 22:34:00 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 23:34:00 +0200 Subject: [Python-Dev] ascii default encoding References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> Message-ID: <39722A48.B8DADEB5@lemburg.com> Thomas Wouters wrote: > > On Sun, Jul 16, 2000 at 10:14:54PM +0200, M.-A. Lemburg wrote: > > Jack Jansen wrote: > > > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but > > > the \312 causes problems because it can't be converted from/to unicode > > > as long as the default encoding is ascii... > > > string.py is depreciated -- please use string methods instead. > > You mean 'deprecated'. Hmm, my Webster says "to lessen in value" -- that's what I had in mind... > And please wait with deprecating string.py until all > functionality is indeed available through string methods. And please don't > do that :) I don't think " ".letters really makes sense... "Depreciated" means that you should not use it in new code -- perhaps someday string.py will disappear, even though I doubt that. > Besides, 'string.join' is a good compromise for the people who > don't like " ".join() Tim Peters will have to take the blame for this one ;-) I don't find delimiter.join(sequence) awkward or funny -- using methods for this has added value: it defines an interface which other objects could support as well and thus makes your code polymorph. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Sun Jul 16 22:42:29 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 23:42:29 +0200 Subject: [Python-Dev] ascii default encoding In-Reply-To: <39722A48.B8DADEB5@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 11:34:00PM +0200 References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> <39722A48.B8DADEB5@lemburg.com> Message-ID: <20000716234228.E7340@xs4all.nl> On Sun, Jul 16, 2000 at 11:34:00PM +0200, M.-A. Lemburg wrote: > "Depreciated" means that you should not use it in new code -- > perhaps someday string.py will disappear, even though I doubt > that. The common term for that is 'deprecated', not 'depreciated'. Really :) There once was someone who posted a patch to linux-kernel to fix all those bloody typos everyone made. Almost all instances of 'depreciated' where spelled 'deprecated' ! Deprecate: 1.To express disapproval of; deplore. 2.To belittle; depreciate. Deprecate \Dep"re*cate\: To pray against, as an evil; to seek to avert by prayer; to desire the removal of; to seek deliverance from; to express deep regret for; to disapprove of strongly. The difference is minor, but there really is one. Come on Eric, show us the hackers dictionary on this ;) > > Besides, 'string.join' is a good compromise for the people who > > don't like " ".join() > Tim Peters will have to take the blame for this one ;-) I don't > find delimiter.join(sequence) awkward or funny -- using methods > for this has added value: it defines an interface which other > objects could support as well and thus makes your code polymorph. Indeed. And is there any harm in providing conveniency functions for those that prefer more obvious code ? There is hardly any doubt what string.join(s, sep) does. And some people prefer it that way. They don't care that it's really 'return sep.join(s)' behind their backs. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein@lyra.org Sun Jul 16 23:00:48 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:00:48 -0700 Subject: [Python-Dev] onlinehelp unforgiving In-Reply-To: <200007162126.XAA25108@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Sun, Jul 16, 2000 at 11:26:45PM +0200 References: <200007162126.XAA25108@loewis.home.cs.tu-berlin.de> Message-ID: <20000716150048.N29590@lyra.org> +1 with Martin. There is more to online help than the HTML stuff. Cheers, -g On Sun, Jul 16, 2000 at 11:26:45PM +0200, Martin v. Loewis wrote: > After installing the current Python CVS, I tried to do > > >>> from onlinehelp import help > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/local/lib/python2.0/onlinehelp.py", line 323, in ? > help=Help(sys.stdout,24) > File "/usr/local/lib/python2.0/onlinehelp.py", line 216, in __init__ > raise EnvironmentError, error > EnvironmentError: Cannot find documentation directory /usr/local/bin/doc. > Set the PYTHONDOCS environment variable to point to a "doc" directory. > It should have a subdirectory "Lib" with a file named "index.html". > > I was mainly interested in seeing the doc string retriever in real > life. To do so, I'm in the process of obtaining a set of html files > (hopefully typing make in the Doc directory will give me those). > > Still, I think that module should work without HTML help installed, > and only fail if somebody tries to access the documentation. Or, there > should be a function doc() in addition to help() for retrieving and > printing doc strings. > > I'd actually prefer the second option: > > >>> doc(xml) > Core XML support for Python. > > This package contains three sub-packages: > > dom -- The W3C Document Object Model. This supports DOM Level 1 + > Namespaces. > > parser -- Python wrappers for XML parsers (currently only supports Expat). > > sax -- The Simple API for XML, developed by XML-Dev, led by David > Megginson and ported to Python by Lars Marius Garshol. This > supports the SAX 2 API. > > should work even without any documentation installed. In any case, I > think this (or the help function) should be builtin. > > Regards, > Martin > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sun Jul 16 23:04:10 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:04:10 -0700 Subject: [Python-Dev] urllib and doc: (was: CVS: python/dist/src/Lib onlinehelp.py,NONE,1.1) In-Reply-To: <397221EE.D248C6D3@prescod.net>; from paul@prescod.net on Sun, Jul 16, 2000 at 03:58:22PM -0500 References: <200007161953.MAA30130@slayer.i.sourceforge.net> <397216A0.EE5BB26E@lemburg.com> <397221EE.D248C6D3@prescod.net> Message-ID: <20000716150410.O29590@lyra.org> On Sun, Jul 16, 2000 at 03:58:22PM -0500, Paul Prescod wrote: >... > How about this: if I taught urllib (or something) to translate doc: URLs > into real URLs then you could do something like: > > browser.browse( "doc:lib/lambda" ) > > Maybe that would help...more thought needed. urllib should NOT try to parse a "doc:" scheme. Any scheme in urllib should ONLY be IANA-registered schemes, and the resulting URL should follow the appropriate RFCs. If doc: is ever registered, then go ahead and teach it to urllib. Until then, I'll scream and shout and be very annoying :-) Big -1 on this from me. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Sun Jul 16 23:01:48 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 00:01:48 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49 References: <200007162139.OAA18443@slayer.i.sourceforge.net> Message-ID: <397230CC.D8380547@lemburg.com> Greg Stein wrote: > > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv18430 > > Modified Files: > unicodeobject.c > Log Message: > stop messing around with goto and just write the macro correctly. > > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.48 > retrieving revision 2.49 > diff -C2 -r2.48 -r2.49 > *** unicodeobject.c 2000/07/16 18:47:43 2.48 > --- unicodeobject.c 2000/07/16 21:39:49 2.49 > *************** > *** 632,640 **** > } > > ! #define UTF8_ERROR(details) do { \ > ! if (utf8_decoding_error(&s, &p, errors, details)) \ > ! goto onError; \ > ! goto nextChar; \ > ! } while (0) > > PyObject *PyUnicode_DecodeUTF8(const char *s, > --- 632,641 ---- > } > > ! #define UTF8_ERROR(details) \ > ! if (1) { \ > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > ! goto onError; \ > ! continue; \ > ! } else Greg, this doesn't work... UTF8_ERROR is used in if-clauses and the above may alter the else-branches in subtle ways which are just as hard to detect as the original bug. The goto may not be the greatest in style, but it doesn't have the above caveats. Please revert the checkin. > > PyObject *PyUnicode_DecodeUTF8(const char *s, > *************** > *** 732,737 **** > } > s += n; > - nextChar: > - /* empty */; > } > > --- 733,736 ---- > > _______________________________________________ > Python-checkins mailing list > Python-checkins@python.org > http://www.python.org/mailman/listinfo/python-checkins -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Sun Jul 16 23:09:25 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:09:25 -0700 Subject: [Python-Dev] ascii default encoding In-Reply-To: <20000716234228.E7340@xs4all.nl>; from thomas@xs4all.net on Sun, Jul 16, 2000 at 11:42:29PM +0200 References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> <39722A48.B8DADEB5@lemburg.com> <20000716234228.E7340@xs4all.nl> Message-ID: <20000716150925.Q29590@lyra.org> Thomas is quite correct. "Deprecated" is the proper term. -g On Sun, Jul 16, 2000 at 11:42:29PM +0200, Thomas Wouters wrote: > On Sun, Jul 16, 2000 at 11:34:00PM +0200, M.-A. Lemburg wrote: > > > "Depreciated" means that you should not use it in new code -- > > perhaps someday string.py will disappear, even though I doubt > > that. > > The common term for that is 'deprecated', not 'depreciated'. Really :) There > once was someone who posted a patch to linux-kernel to fix all those bloody > typos everyone made. Almost all instances of 'depreciated' where spelled > 'deprecated' ! > > Deprecate: > > 1.To express disapproval of; deplore. > 2.To belittle; depreciate. > > Deprecate \Dep"re*cate\: > To pray against, as an evil; to seek to avert by prayer; to desire the > removal of; to seek deliverance from; to express deep regret for; to > disapprove of strongly. > > The difference is minor, but there really is one. Come on Eric, show us the > hackers dictionary on this ;) > > > > Besides, 'string.join' is a good compromise for the people who > > > don't like " ".join() > > > Tim Peters will have to take the blame for this one ;-) I don't > > find delimiter.join(sequence) awkward or funny -- using methods > > for this has added value: it defines an interface which other > > objects could support as well and thus makes your code polymorph. > > Indeed. And is there any harm in providing conveniency functions for those > that prefer more obvious code ? There is hardly any doubt what > > string.join(s, sep) > > does. And some people prefer it that way. They don't care that it's really > 'return sep.join(s)' behind their backs. > > -- > Thomas Wouters > > Hi! I'm a .signature virus! copy me into your .signature file to help me spread! > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From guido@beopen.com Mon Jul 17 00:10:20 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:10:20 -0500 Subject: [Python-Dev] Checked in... In-Reply-To: Your message of "Sun, 16 Jul 2000 15:18:42 EST." <397218A2.A90BCAB3@prescod.net> References: <397218A2.A90BCAB3@prescod.net> Message-ID: <200007162310.SAA05749@cj20424-a.reston1.va.home.com> > onlinehelp.py is checked in. Here's the docstring: Sorry Paul, but checking things in is not the appropriate way to start a discussion. Without a prior discussion of requirements and design alternatives I don't think that it should be checked in, even labeled experimental. The proper thing to do if you want feedback on the source code is to post the source code somewhere (here). There are simply too many people with too many ideas for this to work -- Python would become a work designed by committee. I'm on my way to Monterey and don't have time to comment on the contents right now, but please follow the procedure! (And I *know* that the procedure isn't carefully documented -- that's one more reason to be conservative in your checkins.) Annoyed, --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal@lemburg.com Sun Jul 16 23:13:39 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 00:13:39 +0200 Subject: [Python-Dev] ascii default encoding References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> <39722A48.B8DADEB5@lemburg.com> <20000716234228.E7340@xs4all.nl> Message-ID: <39723393.BD32D592@lemburg.com> Thomas Wouters wrote: > > On Sun, Jul 16, 2000 at 11:34:00PM +0200, M.-A. Lemburg wrote: > > > "Depreciated" means that you should not use it in new code -- > > perhaps someday string.py will disappear, even though I doubt > > that. > > The common term for that is 'deprecated', not 'depreciated'. Really :) There > once was someone who posted a patch to linux-kernel to fix all those bloody > typos everyone made. Almost all instances of 'depreciated' where spelled > 'deprecated' ! > > Deprecate: > > 1.To express disapproval of; deplore. > 2.To belittle; depreciate. ^^^^^^^^^^ This is what I was referring to :-) > Deprecate \Dep"re*cate\: > To pray against, as an evil; to seek to avert by prayer; to desire the > removal of; to seek deliverance from; to express deep regret for; to > disapprove of strongly. I wouldn't want to pray against string.py ;-) Here's what my Merriam-Webster has to say: Depreciate: 1. to lessen in price or value 2. undervalue, belittle, disparage > The difference is minor, but there really is one. Come on Eric, show us the > hackers dictionary on this ;) It seems that one is stronger than the other. I'll stick with the weaker one ;-) > > > Besides, 'string.join' is a good compromise for the people who > > > don't like " ".join() > > > Tim Peters will have to take the blame for this one ;-) I don't > > find delimiter.join(sequence) awkward or funny -- using methods > > for this has added value: it defines an interface which other > > objects could support as well and thus makes your code polymorph. > > Indeed. And is there any harm in providing conveniency functions for those > that prefer more obvious code ? There is hardly any doubt what > > string.join(s, sep) > > does. And some people prefer it that way. They don't care that it's really > 'return sep.join(s)' behind their backs. Fine... but it'll cause a performance hit when used in tight loops (function call + method lookup). They should use somehting like: spacejoin = ' '.join spacejoin(sequence) instead. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Sun Jul 16 23:17:50 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:17:50 -0700 Subject: [Python-Dev] binary incompatibility and tp_flags (was: Linker problems on Linux) In-Reply-To: <20000716232553.B7340@xs4all.nl>; from thomas@xs4all.net on Sun, Jul 16, 2000 at 11:25:53PM +0200 References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> Message-ID: <20000716151750.R29590@lyra.org> On Sun, Jul 16, 2000 at 11:25:53PM +0200, Thomas Wouters wrote: > On Sun, Jul 16, 2000 at 10:57:47PM +0200, Martin v. Loewis wrote: > > > For example, if you have a 1.5.2-compiled type in an extension module, > > and that type happens to implement PySequenceMethods, then applying 'a > > in b' will likely crash: Python 2 will check for the sq_contains > > field, but that is past the end of the function table in the old > > module. > > Nope. This is specifically fixed by the new tp_flags structmember (which was > 'unused' before, so reading *that* will work ok) and the PyType_HasFeature > macro. All code that wants to access one of the really new struct members > (currently, bf_getcharbuffer, sq_contains and the cycle-gc stuff. And my > augmented assignment patch adds another 13 ;) should check tp_flags first. > > See the comment in Include/object.h regarding this. Actually, those flags should only be used if you are attempting to maintain binary compatibility. At the point where you say "okay. binary compatibility is hereby broken.", then we go and remove the flags for the new structure members. The concept is pretty simple: *) if an extension was compiled before the addition of the new member, then the core should not attempt to access it. to detect this case, the core looks at the flag bit, which will be zero. *) when the extension is recompiled, the struct grows according to the new definition. -) The extension may still have zero in there, so Python still won't look, even though it could -) The extension added Py_TPFLAGS_DEFAULT and picks up the bit that says the new struct member is there. It is probably NULL, unless the author has filled in a value. The last API bump was to 1009 for "Unicode API added". I'm not sure why Guido bumped it since the *addition* of an API shouldn't create binary incompatibility. Regardless, I think we have introduced several semantic incompatibilities or even signature changes in the APIs. We should do a bump for safety's sake and we should toss the two Py_TPFLAGS_HAVE_* macros (and the corresponding tests within the core interpreter). Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido@beopen.com Mon Jul 17 00:14:57 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:14:57 -0500 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: Your message of "Sun, 16 Jul 2000 23:33:17 +0200." <20000716233317.C7340@xs4all.nl> References: <3971A705.B23AD7D3@lemburg.com> <20000716141921.K29590@lyra.org> <20000716233317.C7340@xs4all.nl> Message-ID: <200007162314.SAA05833@cj20424-a.reston1.va.home.com> > I'm with Tim here: screw the retarded compatibility. Make \x make sense in > normal strings and unicode strings both, but in a way that breaks as little > as possible: if it always results in one byte in 8bit strings, it should do > the same, IMHO, in unicode strings. I'm also for making \x take at most four > bytes, like the documentation states, instead of hassling with a perl-like > construct such as C has. I would be very, very suprised if anyone was using > \x29E8F28DA727 and expects it to work like \x27. Haven't read Tim's post, but I agree to screw compatibility here, and I see two reasonable ways out: (1) \x takes up to 2 hex chars in 8-bit strings and up to 4 hex chars in Unicode. (2) \x takes up to 4 hex chars in all strings. The presence of -U and ease of JPython compatibility both suggest that (2) is best. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From Fredrik Lundh" <200007162310.SAA05749@cj20424-a.reston1.va.home.com> Message-ID: <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> guido wrote: > > > onlinehelp.py is checked in. Here's the docstring: >=20 > Sorry Paul, but checking things in is not the appropriate way to start > a discussion. Without a prior discussion of requirements and design > alternatives I don't think that it should be checked in, even labeled > experimental. in paul's defence, note that tim, greg stein, and moshe all told paul to go ahead and check it in... (you'll find their posts in the "help command" thread) cheers /F From Fredrik Lundh" <20000716141921.K29590@lyra.org> <20000716233317.C7340@xs4all.nl> <200007162314.SAA05833@cj20424-a.reston1.va.home.com> Message-ID: <004d01bfef75$34bd5a60$f2a6b5d4@hagrid> guido wrote: > Haven't read Tim's post, but I agree to screw compatibility here, and > I see two reasonable ways out: I think tim and thomas both meant "screw C9X compatibility", not "screw 1.5.2 compatibility". (maybe we should continue this discussion when you're back from OSCON? it's not that critical...) From Fredrik Lundh" Message-ID: <008501bfef76$362902e0$f2a6b5d4@hagrid> jack wrote: > Now that the default encoding for 8-bit strings has gone back to > "ascii", shouldn't the initialization of strop.whitespace and friends > only range over 0..128 in stead of 0..256? >=20 > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but = > the \312 causes problems because it can't be converted from/to unicode = > as long as the default encoding is ascii... on windows and unix boxes, the default locale is "posix" (aka "C"), which in practice means "plain ascii". the only way to end up with non-ascii characters in whitespace/uppercase/lowercase/etc is to explicitly change the locale (by calling locale.setlocale). how does this work on the mac? do the mac libraries use another default locale? one slightly radical way to solve this would be to modify the loops in stropmodule.c/initstrop (changing 256 to 128). From guido@beopen.com Mon Jul 17 00:32:27 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:32:27 -0500 Subject: [Python-Dev] Checked in... In-Reply-To: Your message of "Mon, 17 Jul 2000 00:25:39 +0200." <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> Message-ID: <200007162332.SAA06030@cj20424-a.reston1.va.home.com> > in paul's defence, note that tim, greg stein, and moshe > all told paul to go ahead and check it in... > > (you'll find their posts in the "help command" thread) Sigh. Sorry Paul. Now I'm annoyed at Tim, Greg & Moshe. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein@lyra.org Sun Jul 16 23:37:36 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:37:36 -0700 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) In-Reply-To: <397230CC.D8380547@lemburg.com>; from mal@lemburg.com on Mon, Jul 17, 2000 at 12:01:48AM +0200 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> Message-ID: <20000716153736.T29590@lyra.org> On Mon, Jul 17, 2000 at 12:01:48AM +0200, M.-A. Lemburg wrote: > Greg Stein wrote: >... > > ! #define UTF8_ERROR(details) \ > > ! if (1) { \ > > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > > ! goto onError; \ > > ! continue; \ > > ! } else > > Greg, this doesn't work... UTF8_ERROR is used in if-clauses > and the above may alter the else-branches in subtle ways which > are just as hard to detect as the original bug. The goto may > not be the greatest in style, but it doesn't have the above > caveats. Nope. It *does* work. Note the "else" on the end there. That creates the proper binding. All uses of the UTF8_ERROR() macro have a semicolon after them (like any normal statement does(!)). This expands the macro to: if (1) { ... } else ; /* this is the semicolon I referred to */ Therefore, it creates a complete if/else statement, and any surrounding if/else statements will bind as expected. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sun Jul 16 23:41:38 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:41:38 -0700 Subject: [Python-Dev] Checked in... In-Reply-To: <200007162310.SAA05749@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Sun, Jul 16, 2000 at 06:10:20PM -0500 References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> Message-ID: <20000716154138.U29590@lyra.org> To defend Paul here a bit, we did start some discussion here, and at least some of us said "the concept is fine, so check it in. we can totally revamp as necessary." CVS is a much better communication/testing vehicle than the damn Patch Manager or posting modules at some private web site. And we can always "cvs rm" a module. Another alternative would be to create /nondist/sandbox/ and have people toss modules-for-discussion or modules-in-progress into that area. We can dork around as much as needed. When the module is "ready", then we add it into the /dist/ branch. CVS is a great tool for this. Let's not try to create roadblocks that prevent effective work. Cheers, -g On Sun, Jul 16, 2000 at 06:10:20PM -0500, Guido van Rossum wrote: > > onlinehelp.py is checked in. Here's the docstring: > > Sorry Paul, but checking things in is not the appropriate way to start > a discussion. Without a prior discussion of requirements and design > alternatives I don't think that it should be checked in, even labeled > experimental. > > The proper thing to do if you want feedback on the source code is to > post the source code somewhere (here). There are simply too many > people with too many ideas for this to work -- Python would become a > work designed by committee. > > I'm on my way to Monterey and don't have time to comment on the > contents right now, but please follow the procedure! (And I *know* > that the procedure isn't carefully documented -- that's one more > reason to be conservative in your checkins.) > > Annoyed, > > --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From guido@beopen.com Mon Jul 17 00:39:03 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:39:03 -0500 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: Your message of "Mon, 17 Jul 2000 00:28:43 +0200." <004d01bfef75$34bd5a60$f2a6b5d4@hagrid> References: <3971A705.B23AD7D3@lemburg.com> <20000716141921.K29590@lyra.org> <20000716233317.C7340@xs4all.nl> <200007162314.SAA05833@cj20424-a.reston1.va.home.com> <004d01bfef75$34bd5a60$f2a6b5d4@hagrid> Message-ID: <200007162339.SAA06110@cj20424-a.reston1.va.home.com> > guido wrote: > > Haven't read Tim's post, but I agree to screw compatibility here, and > > I see two reasonable ways out: > > I think tim and thomas both meant "screw C9X compatibility", > not "screw 1.5.2 compatibility". Oops again. > (maybe we should continue this discussion when you're back > from OSCON? it's not that critical...) Yes please! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr@thyrsus.com Mon Jul 17 00:00:46 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Sun, 16 Jul 2000 19:00:46 -0400 Subject: [Python-Dev] ascii default encoding In-Reply-To: <20000716234228.E7340@xs4all.nl> References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> <39722A48.B8DADEB5@lemburg.com> <20000716234228.E7340@xs4all.nl> Message-ID: <20000716190046.A3833@thyrsus.com> Thomas Wouters : > Deprecate: > > 1.To express disapproval of; deplore. > 2.To belittle; depreciate. > > Deprecate \Dep"re*cate\: > To pray against, as an evil; to seek to avert by prayer; to desire the > removal of; to seek deliverance from; to express deep regret for; to > disapprove of strongly. > > The difference is minor, but there really is one. Come on Eric, show us the > hackers dictionary on this ;) Your wish is my command... @hd{deprecated} @g{adj.} @p{} Said of a program or feature that is considered obsolescent and in the process of being phased out, usually in favor of a specified replacement. Deprecated features can, unfortunately, linger on for many years. This term appears with distressing frequency in standards documents when the committees writing the documents realize that large amounts of extant (and presumably happily working) code depend on the feature(s) that have passed out of favor. See also @es{dusty deck}. @comment ESR 1983 -- Eric S. Raymond This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. From tim_one@email.msn.com Sun Jul 16 23:46:35 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 18:46:35 -0400 Subject: [Python-Dev] Checked in... In-Reply-To: <200007162310.SAA05749@cj20424-a.reston1.va.home.com> Message-ID: [Paul Prescod] >> onlinehelp.py is checked in. Here's the docstring: [Guido] > Sorry Paul, but checking things in is not the appropriate way to start > a discussion. There was a discussion, overwhelmingly positive, and then to make further progress Paul asked here whether it wouldn't be easier to just check something in so we could all kick the tires. At least three of us (four if you count me twice, as I tend to do ) said "sure!". > ... > Annoyed, I can understand that too . But as Paul said, it's a self-contained module that "can't" break anything else, and he did ask first, so maybe you could look on it a bit more kindly this once. From guido@beopen.com Mon Jul 17 00:53:41 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:53:41 -0500 Subject: [Python-Dev] Checked in... In-Reply-To: Your message of "Sun, 16 Jul 2000 15:41:38 MST." <20000716154138.U29590@lyra.org> References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <20000716154138.U29590@lyra.org> Message-ID: <200007162353.SAA06185@cj20424-a.reston1.va.home.com> [Greg] > To defend Paul here a bit, we did start some discussion here, and at least > some of us said "the concept is fine, so check it in. we can totally revamp > as necessary." I can't even go away for a weekend and they start checking stuff in behind my back. ;-) > CVS is a much better communication/testing vehicle than the damn Patch > Manager or posting modules at some private web site. > > And we can always "cvs rm" a module. Actually, this leaves a turd in the Attic directory. Adding something to the CVS repository gives it a false legitimacy -- not everybody reads the "experimental feature" comment. > Another alternative would be to create /nondist/sandbox/ and have people > toss modules-for-discussion or modules-in-progress into that area. We can > dork around as much as needed. When the module is "ready", then we add it > into the /dist/ branch. I like this much better! > CVS is a great tool for this. Let's not try to create roadblocks that > prevent effective work. Sure. But let's be careful with what we check in, especially into the "dist" source tree. This is not a place for random experiments. I've seen a few examples recently where it seemed some kind of discussion was being carried out by checkins. Regardless of who's right or wrong, that's the wrong medium for such a process. [Tim] > There was a discussion, overwhelmingly positive, and then to make further > progress Paul asked here whether it wouldn't be easier to just check > something in so we could all kick the tires. At least three of us (four if > you count me twice, as I tend to do ) said "sure!". > > > ... > > Annoyed, > > I can understand that too . But as Paul said, it's a self-contained > module that "can't" break anything else, and he did ask first, so maybe you > could look on it a bit more kindly this once. Sure. I recommend the use of the nondist CVS tree for experiments. But to me the dist subtree is sacred and should only contain code we believe we agree on. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul@prescod.net Mon Jul 17 00:06:24 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:06:24 -0500 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> Message-ID: <39723FF0.D6BFD9F1@prescod.net> This is a multi-part message in MIME format. --------------037F6DFEA584BB427405A1E5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Okay, I've removed it and attached it to this email but I still think that's a pretty cumbersome way to proceed. I've already made one modification. Future ones will need to be distributed as email patches. As a new module that won't be the basis of anything, and with significant interest, I don't see the danger in a checkin. Anyhow, this version should not require the PYTHONDOCS environment variable unless you try to refer to a help topic that requires the online help. Still, in the future, I don't see the benefit in duplicating the documentation for all of the statements and operators. If you want that documentation, you'll probably need the HTML installed. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html --------------037F6DFEA584BB427405A1E5 Content-Type: text/plain; charset=us-ascii; name="onlinehelp.py" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="onlinehelp.py" """ Online help module. This module is experimental and could be removed or radically changed at any time. It is intended specifically for the standard interpreter command line but is intended to be compatible with and useful for other (e.g. GUI, handheld) environments. Help with those other environments is appreciated. Please remember to set PYTHONDOCS to the location of your HTML files: e.g. set PYTHONDOCS=c:\python\docs PYTHONDOCS=/python/docs The docs directory should have a lib subdirectory with "index.html" in it. If it has *.tex then you have the documentation *source* distribution, not the runtime distribution. The module exposes one object: "help". "help" has a repr that does something useful if you just type: >>> from onlinehelp import help >>> help Of course one day the first line will be done automatically by site.py or something like that. help can be used as a function. The function takes the following forms of input: help( "string" ) -- built-in topic or global help( ) -- docstring from object or type help( "doc:filename" ) -- filename from Python documentation Type help to get the rest of the instructions. You can also use the module as a command line program: python onlinehelp.py if """ # todo: consider following links: # help( 3 ) -> follows link 3 in the last-displayed doc # help( 4 ) -> follows link 4 in the last-displayed doc # ... import htmllib # todo: add really basic tr/td support import formatter import os, sys import re prompt="--more-- (enter for more, q to quit) " topics={} # all built-in (non-HTML, non-docstring) topics go in here commands="" # only used at the top level def topLevelCommand( name, description, text ): """ this function is just for use at the top-level to make sure that every advertised top-level topic has a description and every description has text. Maybe we can generalize it later.""" global commands topics[name]=text if description[0]=="[": placeholder="(dummy)" elif description[0]=="<": placeholder="link" else: placeholder="" commands=commands+'help( "%s" ) %s - %s\n' % \ (name, placeholder, description ) topLevelCommand( "intro", "What is Python? Read this first!", """Welcome to Python, the easy to learn, portable, object oriented programming language. [info on how to use help] [info on intepreter]""" ) topLevelCommand( "keywords", "What are the keywords?", "") topLevelCommand( "syntax", "What is the overall syntax?", "[placeholder]") topLevelCommand( "operators", "What operators are available?", "" ) topLevelCommand( "builtins", "What functions, types, etc. are built-in?", "") topLevelCommand( "modules", "What modules are in the standard library?", "") topLevelCommand( "copyright", "Who owns Python?", "[who knows]") topLevelCommand( "moreinfo", "Where is there more information?", "[placeholder]") topLevelCommand( "changes", "What changed in Python 2.0?", "[placeholder]" ) topLevelCommand( "extensions", "What extensions are installed?", "[placeholder]") topLevelCommand( "faq", "What questions are frequently asked?", "[placeholder]") topLevelCommand( "ack", "Who has done work on Python lately?", "[placeholder for list of people who contributed patches]") topics[ "prompt" ]="""""" topics[ "types" ]="""""" topics["everything"]= \ """
The help function allows you to read help on Python's various 
functions, objects, instructions and modules. You have two options:

1. Use help( obj ) to browse the help attached to some function, module
class or other object. e.g. help( dir )

2. Use help( "somestring" ) to browse help on one of the predefined 
help topics, unassociated with any particular object:

%s
""" % commands topics[ "keywords" ]=\ """
"if"       - Conditional execution
"while"    - Loop while a condition is true
"for"      - Loop over a sequence of values (often numbers)
"try"      - Set up an exception handler
"def"      - Define a named function
"class"    - Define a class
"assert"   - Check that some code is working as you expect it to.
"pass"     - Do nothing
"del"      - Delete a data value
"print"    - Print a value
"return"   - Return information from a function
"raise"    - Raise an exception
"break"    - Terminate a loop
"continue" - Skip to the next loop statement
"import"   - Import a module
"global"   - Declare a variable global
"exec"     - Execute some dynamically generated code
"lambda"   - Define an unnamed function

For more information, type e.g. help("assert")
""" topics[ "if" ]="""""" topics[ "while" ]="""""" topics[ "for" ]="""""" topics[ "try" ]="""""" topics[ "def" ]="""""" topics[ "class" ]="""""" topics[ "assert" ]="""""" topics[ "pass" ]="""""" topics[ "del" ]="""""" topics[ "print" ]="""""" topics[ "return" ]="""""" topics[ "raise" ]="""""" topics[ "break" ]="""""" topics[ "continue" ]="""""" topics[ "import" ]="""""" topics[ "global" ]="""""" topics[ "exec" ]="""""" topics[ "lambda" ]="""""" envir_var="PYTHONDOCS" class Help: def __init__( self, out, line_length, docdir=None ): self.out=out self.line_length=line_length self.Parser=htmllib.HTMLParser self.Formatter=formatter.AbstractFormatter self.Pager=Pager self.Writer=formatter.DumbWriter self.docdir=docdir def initDocDir( self ): if os.environ.has_key(envir_var): self.docdir=os.environ[envir_var] else: if os.environ.has_key("PYTHONHOME"): pyhome=os.environ["PYTHONHOME"] else: pyhome=os.path.split( sys.executable )[0] self.docdir=os.path.join( pyhome, "doc" ) testfile=os.path.join( os.path.join( self.docdir, "lib" ), "index.html") if not os.path.exists( testfile ): error = \ """Cannot find documentation directory %s. Set the %s environment variable to point to a "doc" directory. It should have a subdirectory "Lib" with a file named "index.html". """ % (self.docdir, envir_var ) raise EnvironmentError, error def __repr__( self ): self( "everything" ) return "" def __call__( self, ob, out=None ): try: self.call( ob, out ) return 1 except (KeyboardInterrupt, EOFError): return 0 def call( self, ob, out ): self.pager=out or self.Pager( self.out, self.line_length ) if type( ob ) in (type(""),type(u"")): if ob.startswith( "<" ): ob=ob[1:] if ob.endswith( ">" ): ob=ob[:-1] self.write( 'Topic: help( "%s" )\n' % ob ) if ob.startswith("doc:"): path=ob[4:] if not self.docdir: self.initDocDir() fullpath=os.path.join( self.docdir, path ) data=open( fullpath ).read() index=ob.rfind( "/" ) self.writeHTML( ob[:index], data ) else: try: info=topics[ob] docrlmatch=re.search( "(]+>)", info.split("\n")[0] ) if docrlmatch: # a first-line redirect self( docrlmatch.group(1) ) else: self.writeHTML( "", info ) except KeyError: glo=__builtins__.__dict__.get( ob, 0 ) if glo: self( glo ) else: sys.stderr.write( "No such topic "+`ob` ) return None else: self.write( 'Topic: help( %s )\n' % ob ) if hasattr( ob, "__doc__" ): self.writeText(ob.__doc__) else: self.writeText( type( ob ).__doc__ ) def writeHTML( self, base, str ): parser=self.Parser(self.Formatter( self.Writer( self ))) parser.feed( str ) # calls self.write automatically for i in range( len( parser.anchorlist) ): self.pager.write( "[%s] %s/%s\n" %(i+1, base,parser.anchorlist[i] )) self.pager.flush() self.out.write( "\n" ) def writeText( self, str ): self.pager.write( str ) self.pager.flush() self.out.write( "\n" ) def write( self, str ): self.pager.write( str ) from cStringIO import StringIO class Pager: numlines=1 def __init__(self, out, pagesize=24, linestart="" ): self.out=out self.pagesize=pagesize self.buf=StringIO() self.linestart=linestart def close(self ): self.flush() def flush(self ): data=self.buf.getvalue().rstrip() # dump trailing ws while data.endswith( "\n|" ): # dump trailing lines data=data[:-2] self.out.write( data ) self.buf=StringIO() def write(self, str ): lines=str.split( "\n" ) self.buf.write( lines[0] ) for line in lines[1:]: self.buf.write( "\n| " ) self.buf.write( line ) if self.numlines and not self.numlines%(self.pagesize): dat=self.buf.getvalue().strip() self.out.write( "| " ) self.out.write( dat ) self.out.write( "\n" ) j=raw_input(prompt) if j and j[0]=="q": raise EOFError self.buf=StringIO() self.numlines=self.numlines+1 help=Help(sys.stdout,24) def test(): rc = 1 rc = rc and help( "everything" ) rc = rc and help( "exec" ) rc = rc and help( "doc:lib/unix.html" ) rc = rc and help( "doc:lib/module-tty.html" ) rc = rc and help( "doc:ref/print.html" ) rc = rc and help( "faq" ) rc = rc and help( dir ) repr( help ) if __name__=="__main__": if len( sys.argv )!=2: print "Usage: %s or %s test" % ( sys.argv[0], sys.argv[0] ) sys.exit(0) elif sys.argv[1]=="test": test() else: help( sys.argv[1] ) --------------037F6DFEA584BB427405A1E5-- From paul@prescod.net Mon Jul 17 00:11:07 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:11:07 -0500 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <20000716154138.U29590@lyra.org> <200007162353.SAA06185@cj20424-a.reston1.va.home.com> Message-ID: <3972410B.4847D37B@prescod.net> Okay, everybody seems to like the nondist idea, should it be nondist/src/onlinehelp.py # simple nondist/src/help/onlinehelp.py # its own directory -- in case it splits into two modules nondist/src/Lib/onlinehelp.py # code proposed for standard library -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From tim_one@email.msn.com Mon Jul 17 00:12:48 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 19:12:48 -0400 Subject: [Python-Dev] Checked in... In-Reply-To: <200007162353.SAA06185@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > I recommend the use of the nondist CVS tree for experiments. But to me > the dist subtree is sacred and should only contain code we believe we > agree on. That's easy to agree with too, but I need to make a confession here: my belief is that consensus will *never* be reached on anything having to do with doc presentation. Whether it's "structured text", or just what to put in a docstring, the Python community has an unbroken string of failures to agree on anything. Against that, Python has had an obvious need for better online help since the first day I used it, and anticipating that Paul's approach would never reach consensus, my vote to "sure! check it in!" was secretly based on "better anything than (10 more years of) poke-and-hope 'print thing.__doc__'". So this was a very special case to me. I don't cheat often, but when I do I make sure you're not looking <0.9 wink>. at-least-you're-annoyed-at-the-right-person-now-ly y'rs - tim From paul@prescod.net Mon Jul 17 00:22:08 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:22:08 -0500 Subject: [Python-Dev] Checked in... References: Message-ID: <397243A0.5F4AEE4F@prescod.net> Tim Peters wrote: > > ... > > That's easy to agree with too, but I need to make a confession here: my > belief is that consensus will *never* be reached on anything having to do > with doc presentation. Whether it's "structured text", or just what to put > in a docstring, the Python community has an unbroken string of failures to > agree on anything. I'm not quite as pessimistic as you but part of my rationale was anything, no matter how crappy, would be better than nothing, which is what we have years of. I don't care if its: help=""" Try http://www.python.org. Have a nice day! """ help=NameError is just rude! I am optimistic that having a user-friendly way to find out about objects will get the ball rolling for more docstrings, along with Ka Ping's code to put docstrings on the Web and some IDE's docstring reporting. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov@inrialpes.fr Mon Jul 17 00:43:41 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Mon, 17 Jul 2000 01:43:41 +0200 (CEST) Subject: [Python-Dev] intallation & help system Message-ID: <200007162343.BAA23397@python.inrialpes.fr> I've just installed the latest Gnome release (http://www.gnome.org) and I must say that I was really pleased (not to say, impressed) by two things: 1. Installation All I had to type was: ~> lynx -source http://go-gnome.com | sh This went on downloading and executing an installation script, which figured out automatically the system I am running on (RedHat 6.2), then asked me to select the nearest mirror and downloaded and installed the right set of packages for RH-6.2. Very cool! I'd like to see something similar for Python. 2. Integrated Help System You guys should definitely try out the Gnome help browser, if you haven't seen it already. This is a very good source of inspiration for implementing and integrated help for Python. The gnome-help browser is a unified interface to man, info and HTML docs. It introduces some 'magic' naming schemes (explained in ghelp:help-browser) For instance: a) http: ... The usual http: naming conventions for accessing documents through HTTP b) file: ... The usual file naming scheme for accessing local files) c) whatis: ... Do a substring search of document names Examples - whatis:ls whatis:xman d) toc: ... Load a table of contents of available documents Examples - toc: toc:man toc:info toc:ghelp e) man: ... Load a manual page Examples - man:ls man:ls(1) f) info: ... Load a GNU info page Examples - info:emacs info:emacs#Top g) ghelp: ... Load a Gnome help page for an application Examples - ghelp:help-browser If you're still unclear on how to implement an integrated help system for Python, replace 'ghelp' by 'python' or 'pyhelp' and steal everything else from the Gnome help system <0.5 wink>. happy-with-open-source'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul@prescod.net Mon Jul 17 00:39:03 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:39:03 -0500 Subject: [Python-Dev] Pre-PEP Idea References: Message-ID: <39724797.21AC2263@prescod.net> David Ascher wrote: > > ... > > Geez, guys, that's one of the first things I did for Python! I guess I'm cleaning up your unfinished project then. :) Anyhow, we can't expect Windows and Mac Python users to have info installed. > PS: Then again, these days I'd rather work out an API for a help lookup > mechanims that the twelve IDEs could all use, rather than encourage people > to stick with glass tty's =). I think that's the long-term goal. But the interpreter is the canonical Python user interface. Once we get information flowing into there, it will be easier to repurpose the information for the GUIs. Anyhow, I find this pretty useful: $ python onlinehelp.py dir Topic: help( ) | dir([object]) -> list of strings | | Return an alphabetized list of names comprising (some of) the attributes | of the given object. Without an argument, the names in the current scope | are listed. With an instance argument, only the instance attributes are | returned. With a class argument, attributes of the base class are not | returned. For other types or arguments, this may list members or methods. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Mon Jul 17 00:48:01 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:48:01 -0500 Subject: [Python-Dev] intallation & help system References: <200007162343.BAA23397@python.inrialpes.fr> Message-ID: <397249B1.7FD6EFF6@prescod.net> Vladimir Marangozov wrote: > >.. > > 2. Integrated Help System > > ... > > If you're still unclear on how to implement an integrated help system > for Python, replace 'ghelp' by 'python' or 'pyhelp' and steal everything > else from the Gnome help system <0.5 wink>. Okay, but Python needs a help system that is tty compatible. More advanced help systems should of course be provided by the IDEs. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov@inrialpes.fr Mon Jul 17 01:02:43 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Mon, 17 Jul 2000 02:02:43 +0200 (CEST) Subject: [Python-Dev] intallation & help system In-Reply-To: <397249B1.7FD6EFF6@prescod.net> from "Paul Prescod" at Jul 16, 2000 06:48:01 PM Message-ID: <200007170002.CAA23476@python.inrialpes.fr> Paul Prescod wrote: > > Vladimir Marangozov wrote: > > > >.. > > > > 2. Integrated Help System > > > > ... > > > > If you're still unclear on how to implement an integrated help system > > for Python, replace 'ghelp' by 'python' or 'pyhelp' and steal everything > > else from the Gnome help system <0.5 wink>. > > Okay, but Python needs a help system that is tty compatible. This is not a problem. I can get all this info on a tty instead of in a window. BTW, part of the Gnome installation process is tty-based. If there's a problem of some kind, ESR would solve them in no time, being an ncurses expert :-). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul@prescod.net Mon Jul 17 01:03:21 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 19:03:21 -0500 Subject: [Python-Dev] intallation & help system References: <200007170002.CAA23476@python.inrialpes.fr> Message-ID: <39724D49.135F0684@prescod.net> Vladimir Marangozov wrote: > > ... > > This is not a problem. I can get all this info on a tty instead of > in a window. BTW, part of the Gnome installation process is tty-based. > If there's a problem of some kind, ESR would solve them in no time, > being an ncurses expert :-). I still think that there is something important in not requiring anything beyond a command line, stdin and stdout for the basic help system. Curses won't run on the palm pilot! It should also be possible to plug in more sophisticated UIs where they are available. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gmcm@hypernet.com Mon Jul 17 01:08:48 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Sun, 16 Jul 2000 20:08:48 -0400 Subject: [Python-Dev] ascii default encoding In-Reply-To: <39723393.BD32D592@lemburg.com> Message-ID: <1248329948-59293691@hypernet.com> M.-A. Lemburg, > Thomas Wouters wrote: [deprecate / depreciate] > It seems that one is stronger than the other. I'll stick with the > weaker one ;-) One is passive. Your new car depreciates in value, whether Guido says it should or not. > > > > Besides, 'string.join' is a good compromise for the people > > > > who don't like " ".join() > Fine... but it'll cause a performance hit when used in tight > loops (function call + method lookup). They should use somehting > like: > > spacejoin = ' '.join > spacejoin(sequence) > > instead. It's become very obvious that you haven't read c.l.py in quite awhile. - Gordon From paul@prescod.net Mon Jul 17 02:32:34 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 20:32:34 -0500 Subject: [Python-Dev] urllib and doc: (was: CVS: python/dist/src/Lib onlinehelp.py,NONE,1.1) References: <200007161953.MAA30130@slayer.i.sourceforge.net> <397216A0.EE5BB26E@lemburg.com> <397221EE.D248C6D3@prescod.net> <20000716150410.O29590@lyra.org> Message-ID: <39726232.BE95113@prescod.net> Greg Stein wrote: > > ... > > urllib should NOT try to parse a "doc:" scheme. Any scheme in urllib should > ONLY be IANA-registered schemes, and the resulting URL should follow the > appropriate RFCs. > > If doc: is ever registered, then go ahead and teach it to urllib. Until > then, I'll scream and shout and be very annoying :-) Actually, the URL specs are specifically designed to be extensible and to allow local, community-oriented URL (or URN) prefixes. It is a deficiency of urllib that it cannot be taught to deal with new URLs without changing its code. You can extend Java's URL handler or Windows URL handler "externally." Anyhow, I am light years ahead from doing anything in that vein. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From mhammond@skippinet.com.au Mon Jul 17 02:42:36 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 16 Jul 2000 21:42:36 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <1248369603-56908500@hypernet.com> Message-ID: [Gordon, responding to Barry] > In an ideal world, I rather like #5 (stubs), but I vote for #4 > (version number in the extension module name) or #6 (get a > life). #6 sounds good. But as I'm still experiencing a life in Orlando (with a couple of teenage girls dragging a couple of grumpy old Dads around Universal studios), I'll throw something in :-) Barry's idea sounds reasonable - although a little more elaborate than is necessary. Barry calls for all extension authors to modify their extension code. I can't see a simple solution that avoids this. However, the solution seems a little over-elaborate. If we are asking them to change their code, can we investigate whether asking them to insert a simple: if (!Py_IsInitialized()) Py_FatalError("Bad Python version"); /* Never returns */ works OK? I believe it will, as long as Python's fatal error handler doesnt make thread-state assumptions. Too-much-of-a-life-to-check-ly, Mark. From skip@mojam.com (Skip Montanaro) Mon Jul 17 02:24:26 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 16 Jul 2000 20:24:26 -0500 (CDT) Subject: [Python-Dev] Help command In-Reply-To: <20000716175835.Y7340@xs4all.nl> References: <3971C4AD.74EFAD90@prescod.net> <20000716175835.Y7340@xs4all.nl> Message-ID: <14706.24650.876236.67230@beluga.mojam.com> Thomas> On Sun, Jul 16, 2000 at 09:20:29AM -0500, Paul Prescod wrote: >> Does "man python" work yet? Or maybe my installation was just messed >> up. Thomas> Nope. It does on Mandrake 6.1 (a RH derivative). Skip From ping@lfw.org Mon Jul 17 06:28:24 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Sun, 16 Jul 2000 22:28:24 -0700 (PDT) Subject: [Python-Dev] Checked in... In-Reply-To: <200007162332.SAA06030@cj20424-a.reston1.va.home.com> Message-ID: On Sun, 16 Jul 2000, Guido van Rossum wrote: > > in paul's defence, note that tim, greg stein, and moshe > > all told paul to go ahead and check it in... > > Sigh. Sorry Paul. Now I'm annoyed at Tim, Greg & Moshe. Uh, i'm afraid you'll have to add me to the list. I wanted to encourage Paul to proceed at full speed (even though i didn't get around to it before seeing the messages from the others). I've felt similarly: anything that works reasonably is better than nothing, even if it's not perfect. That said, i have been doing some stuff in this area -- check out http://www.lfw.org/python/ for inspect.py and htmldoc.py. The former in particular is useful for extracting docstrings and argument specs in a nice way. My plan was to complete htmldoc.py and try to get in into the distribution so that anyone could browse documentation on the standard library. It would include an option to start a little webserver with a one-line command so that doc pages could be automatically generated on your own modules as you work on them. The next step in the plan was to provide text output so you could ask about modules from the shell prompt (like a "man" command specific to Python) and a function call you could use from inside the interpreter to get quick help as well. -- ?!ng From martin@loewis.home.cs.tu-berlin.de Mon Jul 17 07:48:50 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 17 Jul 2000 08:48:50 +0200 Subject: [Python-Dev] Compiling the online documentation In-Reply-To: <20000716233459.D7340@xs4all.nl> (message from Thomas Wouters on Sun, 16 Jul 2000 23:34:59 +0200) References: <200007162126.XAA25108@loewis.home.cs.tu-berlin.de> <20000716233459.D7340@xs4all.nl> Message-ID: <200007170648.IAA00903@loewis.home.cs.tu-berlin.de> Thomas Wouters wrote: > Only if you have TeX/LaTeX *and* latex2html installed :P I've failed to find > an RPM for latex2html up til now, and I'm too lazy to hunt down the sources > and compile it myself. I found one at ftp://ftp.cs.tu-berlin.de/pub/linux/Mirrors/contrib.redhat.com/noarch/noarch/latex2html-99.1-1.noarch.rpm This, in turn, needs giftrans-1.12.2-4.i386.rpm. With both packages installed, I tried to run make in Doc/html again, only to get PAPER=letter ../tools/mkhtml.sh api -html_version 4.0 latex2html -init_file /usr/src/python/Doc/perl/l2hinit.perl -dir api -html_version 4.0 /usr/src/python/Doc/api/api.tex Too many arguments for undef operator at /usr/bin/latex2html line 2771, near "$trans)" Too many arguments for undef operator at /usr/bin/latex2html line 3076, near "$etmp)" BEGIN not safe after errors--compilation aborted at /usr/bin/latex2html line 4404. This is with perl 5.6; which perl version is required for latex2html? Regards, Martin From mal@lemburg.com Mon Jul 17 08:55:02 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 09:55:02 +0200 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> Message-ID: <3972BBD6.A81B2577@lemburg.com> Greg Stein wrote: > > On Mon, Jul 17, 2000 at 12:01:48AM +0200, M.-A. Lemburg wrote: > > Greg Stein wrote: > >... > > > ! #define UTF8_ERROR(details) \ > > > ! if (1) { \ > > > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > > > ! goto onError; \ > > > ! continue; \ > > > ! } else > > > > Greg, this doesn't work... UTF8_ERROR is used in if-clauses > > and the above may alter the else-branches in subtle ways which > > are just as hard to detect as the original bug. The goto may > > not be the greatest in style, but it doesn't have the above > > caveats. > > Nope. It *does* work. Note the "else" on the end there. That creates the > proper binding. Greg, I did see the "else", but that does two things: it breaks the code if there's no semicolon after the UT8F_ERROR() macro and it produces warnings which relate to the fact that the "else" part is ambiguous: if (condition) UTF8_ERROR(); else {...} expands to: if (condition) if (1) {...} else ; else {...} And gcc doesn't like it: unicodeobject.c: In function `PyUnicode_FromEncodedObject': unicodeobject.c:424: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:429: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c: In function `PyUnicode_DecodeUTF8': unicodeobject.c:673: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:687: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:698: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:710: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:716: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c: In function `PyUnicode_EncodeUTF8': unicodeobject.c:829: warning: suggest parentheses around arithmetic in operand of | unicodeobject.c: At top level: unicodeobject.c:755: warning: `utf8_encoding_error' defined but not used > All uses of the UTF8_ERROR() macro have a semicolon after them (like any > normal statement does(!)). This expands the macro to: > > if (1) { > ... > } else > ; /* this is the semicolon I referred to */ > > Therefore, it creates a complete if/else statement, and any surrounding > if/else statements will bind as expected. The goto solution is much cleaner and also easier to understand. Please revert the change you made (or I will ;-). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" Message-ID: <003f01bfefc6$64840540$f2a6b5d4@hagrid> mark wrote: > If we are asking them to change their code, can we investigate whether > asking them to insert a simple: >=20 > if (!Py_IsInitialized()) > Py_FatalError("Bad Python version"); /* Never returns */ >=20 > works OK? I believe it will, as long as Python's fatal error handler > doesnt make thread-state assumptions. I'm probably missing something here, but is there any reason you cannot add this code to Py_InitModule4 instead: PyObject *m, *d, *v; PyMethodDef *ml; + if (!Py_IsInitialized()) + Py_FatalError("Bad Python version"); /* Never returns */ if (module_api_version !=3D PYTHON_API_VERSION) fprintf(stderr, api_version_warning, From mal@lemburg.com Mon Jul 17 09:06:50 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 10:06:50 +0200 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> Message-ID: <3972BE9A.3C09AC97@lemburg.com> > Okay, I've removed it and attached it to this email but I still think > that's a pretty cumbersome way to proceed. I've already made one > modification. Future ones will need to be distributed as email patches. > As a new module that won't be the basis of anything, and with > significant interest, I don't see the danger in a checkin. The standard procedure has always been to put the code and the docs somewhere up on the web to support future developments. You only have to publish the pointers every now and then. It was worked great in the past. I don't see any reason it shouldn't work now. I agree with Guido that dist/ shouldn't be used for developing new software, but also agree with Paul et al. that this is a valueable addition to the standard lib. > Anyhow, this version should not require the PYTHONDOCS environment > variable unless you try to refer to a help topic that requires the > online help. Still, in the future, I don't see the benefit in > duplicating the documentation for all of the statements and operators. > If you want that documentation, you'll probably need the HTML installed. You may want to have a look at my hack.py utility which already provides a convenient way of printing the doc strings *and* the published interface: http://starship.python.net/·lemburg/hack.py It needs to be modified a bit to work with SRE since it uses the old regs array (the tool was written for regex which had this array, then ported to re, which also had the array, but didn't document it; SRE doesn't have it anymore... sigh). Here's an example: >>> hack.docs(os) Module : _exit : _exit(status) Exit to the system with specified status, without normal exit processing. chdir : chdir(path) -> None Change the current working directory to the specified path. chmod : chmod(path, mode) -> None Change the access permissions of a file. chown : chown(path, uid, gid) -> None Change the owner and group id of path to the numeric uid and gid. close : close(fd) -> None Close a file descriptor (for low level IO). dup : dup(fd) -> fd2 Return a duplicate of a file descriptor. dup2 : dup2(fd, fd2) -> None Duplicate file descriptor. execv : execv(path, args) Execute an executable path with arguments, replacing current process. path: path of executable file args: tuple or list of strings execve : execve(path, args, env) Execute a path with arguments and environment, replacing current process. path: path of executable file args: tuple or list of arguments env: dictonary of strings mapping to strings fdopen : fdopen(fd, [, mode='r' [, bufsize]]) -> file_object Return an open file object connected to a file descriptor. fork : fork() -> pid Fork a child process. Return 0 to child process and PID of child to parent process. fstat : fstat(fd) -> (mode, ino, dev, nlink, uid, gid, size, atime, mtime, ctime) Like stat(), but for an open file descriptor. ftruncate : ftruncate(fd, length) -> None Truncate a file to a specified length. getcwd : getcwd() -> path Return a string representing the current working directory. getegid : getegid() -> egid Return the current process's effective group id. geteuid : geteuid() -> euid Return the current process's effective user id. getgid : getgid() -> gid Return the current process's group id. getpgrp : getpgrp() -> pgrp Return the current process group id. getpid : getpid() -> pid Return the current process id getppid : getppid() -> ppid Return the parent's process id. getuid : getuid() -> uid Return the current process's user id. kill : kill(pid, sig) -> None Kill a process with a signal. link : link(src, dst) -> None Create a hard link to a file. listdir : listdir(path) -> list_of_strings Return a list containing the names of the entries in the directory. path: path of directory to list The list is in arbitrary order. It does not include the special entries '.' and '..' even if they are present in the directory. lseek : lseek(fd, pos, how) -> newpos Set the current position of a file descriptor. lstat : lstat(path) -> (mode,ino,dev,nlink,uid,gid,size,atime,mtime,ctime) Like stat(path), but do not follow symbolic links. mkdir : mkdir(path [, mode=0777]) -> None Create a directory. mkfifo : mkfifo(file, [, mode=0666]) -> None Create a FIFO (a POSIX named pipe). nice : nice(inc) -> new_priority Decrease the priority of process and return new priority. open : open(filename, flag [, mode=0777]) -> fd Open a file (for low level IO). Module path : Common pathname manipulations, Posix version. Instead of importing this module directly, import os and refer to this module as os.path. pipe : pipe() -> (read_end, write_end) Create a pipe. popen : popen(command [, mode='r' [, bufsize]]) -> pipe Open a pipe to/from a command returning a file object. putenv : putenv(key, value) -> None Change or add an environment variable. read : read(fd, buffersize) -> string Read a file descriptor. readlink : readlink(path) -> path Return a string representing the path to which the symbolic link points. remove : remove(path) -> None Remove a file (same as unlink(path)). rename : rename(old, new) -> None Rename a file or directory. rmdir : rmdir(path) -> None Remove a directory. setgid : setgid(gid) -> None Set the current process's group id. setpgid : setpgid(pid, pgrp) -> None Call the system call setpgid(). setpgrp : setpgrp() -> None Make this process a session leader. setsid : setsid() -> None Call the system call setsid(). setuid : setuid(uid) -> None Set the current process's user id. stat : stat(path) -> (mode,ino,dev,nlink,uid,gid,size,atime,mtime,ctime) Perform a stat system call on the given path. strerror : strerror(code) -> string Translate an error code to a message string. symlink : symlink(src, dst) -> None Create a symbolic link. system : system(command) -> exit_status Execute the command (a string) in a subshell. tcgetpgrp : tcgetpgrp(fd) -> pgid Return the process group associated with the terminal given by a fd. tcsetpgrp : tcsetpgrp(fd, pgid) -> None Set the process group associated with the terminal given by a fd. times : times() -> (utime, stime, cutime, cstime, elapsed_time) Return a tuple of floating point numbers indicating process times. umask : umask(new_mask) -> old_mask Set the current numeric umask and return the previous umask. uname : uname() -> (sysname, nodename, release, version, machine) Return a tuple identifying the current operating system. unlink : unlink(path) -> None Remove a file (same as remove(path)). utime : utime(path, (atime, utime)) -> None Set the access and modified time of the file to the given values. wait : wait() -> (pid, status) Wait for completion of a child process. waitpid : waitpid(pid, options) -> (pid, status) Wait for completion of a give child process. write : write(fd, string) -> byteswritten Write a string to a file descriptor. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Mon Jul 17 09:11:37 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 10:11:37 +0200 Subject: [Python-Dev] ascii default encoding References: <1248329948-59293691@hypernet.com> Message-ID: <3972BFB9.180C9502@lemburg.com> Gordon McMillan wrote: > > M.-A. Lemburg, > > > Thomas Wouters wrote: > > [deprecate / depreciate] > > > It seems that one is stronger than the other. I'll stick with the > > weaker one ;-) > > One is passive. Your new car depreciates in value, whether > Guido says it should or not. Ok ok... :-) I'll remove the "i" from "depreciated" and will instead try to add the "n" to "unkown" -- promised ;-) > > > > > Besides, 'string.join' is a good compromise for the people > > > > > who don't like " ".join() > > > Fine... but it'll cause a performance hit when used in tight > > loops (function call + method lookup). They should use somehting > > like: > > > > spacejoin = ' '.join > > spacejoin(sequence) > > > > instead. > > It's become very obvious that you haven't read c.l.py in quite > awhile. That's true -- don't have time for that anymore. I usually only scan the newsgroup for articles related to my mx stuff and database/datetime related things. For me, python-dev has become the new home. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> Message-ID: <007501bfefc7$8aff9800$f2a6b5d4@hagrid> mal wrote: > It needs to be modified a bit to work with SRE since it > uses the old regs array (the tool was written for regex > which had this array, then ported to re, which also had the > array, but didn't document it; SRE doesn't have it anymore... > sigh). the next SRE checkin has it... coming later today, assuming that I can find the new little bug I just introduced... while you're waiting, feel free to use "pre" instead. From mal@lemburg.com Mon Jul 17 09:15:50 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 10:15:50 +0200 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> <007501bfefc7$8aff9800$f2a6b5d4@hagrid> Message-ID: <3972C0B6.2C80DF9C@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > It needs to be modified a bit to work with SRE since it > > uses the old regs array (the tool was written for regex > > which had this array, then ported to re, which also had the > > array, but didn't document it; SRE doesn't have it anymore... > > sigh). > > the next SRE checkin has it... coming later today, assuming > that I can find the new little bug I just introduced... Cool :-) > while you're waiting, feel free to use "pre" instead. Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Mon Jul 17 09:26:54 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 10:26:54 +0200 Subject: [Python-Dev] binary incompatibility and tp_flags (was: Linker problems on Linux) References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> Message-ID: <3972C34E.A470B748@lemburg.com> Greg Stein wrote: > > On Sun, Jul 16, 2000 at 11:25:53PM +0200, Thomas Wouters wrote: > > On Sun, Jul 16, 2000 at 10:57:47PM +0200, Martin v. Loewis wrote: > > > > > For example, if you have a 1.5.2-compiled type in an extension module, > > > and that type happens to implement PySequenceMethods, then applying 'a > > > in b' will likely crash: Python 2 will check for the sq_contains > > > field, but that is past the end of the function table in the old > > > module. > > > > Nope. This is specifically fixed by the new tp_flags structmember (which was > > 'unused' before, so reading *that* will work ok) and the PyType_HasFeature > > macro. All code that wants to access one of the really new struct members > > (currently, bf_getcharbuffer, sq_contains and the cycle-gc stuff. And my > > augmented assignment patch adds another 13 ;) should check tp_flags first. > > > > See the comment in Include/object.h regarding this. > > Actually, those flags should only be used if you are attempting to maintain > binary compatibility. > > At the point where you say "okay. binary compatibility is hereby broken.", > then we go and remove the flags for the new structure members. I can't remember anyone saying something in that direction. > The last API bump was to 1009 for "Unicode API added". I'm not sure why > Guido bumped it since the *addition* of an API shouldn't create binary > incompatibility. He bumped it so that extensions can switch on the API number and then decide whether to use the new API or not... there are extensions out there which want to be compatible to 1.5.2 *and* 2.0. E.g. my mx stuff has a special portability file (mxpyapi.h) which is meant to achieve exactly this... > Regardless, I think we have introduced several semantic incompatibilities or > even signature changes in the APIs. We should do a bump for safety's sake > and we should toss the two Py_TPFLAGS_HAVE_* macros (and the corresponding > tests within the core interpreter). I can only speak for my mx stuff, but that still works greats with the 2.0 API -- except for the missing PyObject_Length() API, but that'll go back in as soon as Thomas has modified his patch on SF. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Mon Jul 17 09:40:33 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 10:40:33 +0200 Subject: [Python-Dev] binary incompatibility and tp_flags (was: Linker problems on Linux) In-Reply-To: <3972C34E.A470B748@lemburg.com>; from mal@lemburg.com on Mon, Jul 17, 2000 at 10:26:54AM +0200 References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> <3972C34E.A470B748@lemburg.com> Message-ID: <20000717104033.F7340@xs4all.nl> On Mon, Jul 17, 2000 at 10:26:54AM +0200, M.-A. Lemburg wrote: > I can only speak for my mx stuff, but that still works greats > with the 2.0 API -- except for the missing PyObject_Length() > API, but that'll go back in as soon as Thomas has modified > his patch on SF. I already did that ;) About 5 minutes after you added the comment about it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein@lyra.org Mon Jul 17 10:05:32 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:05:32 -0700 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) In-Reply-To: <3972BBD6.A81B2577@lemburg.com>; from mal@lemburg.com on Mon, Jul 17, 2000 at 09:55:02AM +0200 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> Message-ID: <20000717020531.X29590@lyra.org> On Mon, Jul 17, 2000 at 09:55:02AM +0200, M.-A. Lemburg wrote: > Greg Stein wrote: >... > > Nope. It *does* work. Note the "else" on the end there. That creates the > > proper binding. > > Greg, I did see the "else", but that does two things: it breaks > the code if there's no semicolon after the UT8F_ERROR() macro The current *and* the previous macro would break if there was no semicolon. No difference here. > and it produces warnings which relate to the fact that the "else" > part is ambiguous: > > if (condition) UTF8_ERROR(); > else {...} > > expands to: > > if (condition) > if (1) {...} > else ; > else {...} That is not ambiguous. > And gcc doesn't like it: > > unicodeobject.c: In function `PyUnicode_FromEncodedObject': > unicodeobject.c:424: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:429: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c: In function `PyUnicode_DecodeUTF8': > unicodeobject.c:673: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:687: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:698: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:710: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:716: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c: In function `PyUnicode_EncodeUTF8': > unicodeobject.c:829: warning: suggest parentheses around arithmetic in operand of | > unicodeobject.c: At top level: > unicodeobject.c:755: warning: `utf8_encoding_error' defined but not used Agreed. It produces warnings. gcc is being stupid here because there is no ambiguity. It is saying "well, gee golly, you might have a problem" but we really don't. gcc is trying to be too smart. But hey... if it wants to produce warnings... then fine. We can work around the dumb thing. > > All uses of the UTF8_ERROR() macro have a semicolon after them (like any > > normal statement does(!)). This expands the macro to: > > > > if (1) { > > ... > > } else > > ; /* this is the semicolon I referred to */ > > > > Therefore, it creates a complete if/else statement, and any surrounding > > if/else statements will bind as expected. > > The goto solution is much cleaner and also easier to understand. Arguable. > Please revert the change you made (or I will ;-). I will, but only to shut gcc up. It is flat out wrong. -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Mon Jul 17 10:16:56 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:16:56 -0700 Subject: [Python-Dev] Checked in... In-Reply-To: <3972410B.4847D37B@prescod.net>; from paul@prescod.net on Sun, Jul 16, 2000 at 06:11:07PM -0500 References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <20000716154138.U29590@lyra.org> <200007162353.SAA06185@cj20424-a.reston1.va.home.com> <3972410B.4847D37B@prescod.net> Message-ID: <20000717021656.Z29590@lyra.org> On Sun, Jul 16, 2000 at 06:11:07PM -0500, Paul Prescod wrote: > Okay, everybody seems to like the nondist idea, should it be > > nondist/src/onlinehelp.py > # simple > nondist/src/help/onlinehelp.py > # its own directory -- in case it splits into two modules > nondist/src/Lib/onlinehelp.py > # code proposed for standard library There isn't any need for organization. The area is not going to be heavily trafficked. If somebody comes along with something "big", then they can place it into a subdir. Even then, it could be questionable. The audience for this stuff is python-dev. nondist/src/ is still a bit official. As I mentioned in my note, /nondist/sandbox/ is a good candidate -- it is very clear that we are talking about stuff that is just messing around. Therefore, I'd suggest /nondist/sandbox/onlinehelp.py Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Mon Jul 17 10:15:53 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 11:15:53 +0200 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> Message-ID: <3972CEC9.1842AD7F@lemburg.com> Greg Stein wrote: > > > The goto solution is much cleaner and also easier to understand. > > Arguable. > > > Please revert the change you made (or I will ;-). > > I will, but only to shut gcc up. It is flat out wrong. Thank you :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Mon Jul 17 10:17:41 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 11:17:41 +0200 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) In-Reply-To: <20000717020531.X29590@lyra.org>; from gstein@lyra.org on Mon, Jul 17, 2000 at 02:05:32AM -0700 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> Message-ID: <20000717111741.H7340@xs4all.nl> On Mon, Jul 17, 2000 at 02:05:32AM -0700, Greg Stein wrote: > On Mon, Jul 17, 2000 at 09:55:02AM +0200, M.-A. Lemburg wrote: > > and it produces warnings which relate to the fact that the "else" > > part is ambiguous: > > > > if (condition) UTF8_ERROR(); > > else {...} > > > > expands to: > > > > if (condition) > > if (1) {...} > > else ; > > else {...} > > That is not ambiguous. Nope. The example was flawed. *this* is ambiguous: if (condition) UTF8_ERROR(); And that's exactly what gcc is whining about: if (s + n > e) UTF8_ERROR("unexpected end of data"); It's very clearly defined what happens, here, but gcc can't see the macro as is, and mis-placing 'else's is a very common error. Especially combined with macros :) In absense of a standard-defined error-reporting tool, gcc -Wall does a very good job. And don't start about lint, the versions of lint I've seen were much more picky ;) > > The goto solution is much cleaner and also easier to understand. > Arguable. Even more arguable is the coding style issue ;) I haven't seen this 'if (1) {} else' trick used in macros elsewhere, not in Python and not in other code. Granted, those pieces of code didn't need to call continue, but I personally prefer the goto over the weird macro. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Mon Jul 17 10:23:26 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 11:23:26 +0200 Subject: [Python-Dev] binary incompatibility and tp_flags (was: Linker problems on Linux) References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> <3972C34E.A470B748@lemburg.com> <20000717104033.F7340@xs4all.nl> Message-ID: <3972D08E.B2F38679@lemburg.com> Thomas Wouters wrote: > > On Mon, Jul 17, 2000 at 10:26:54AM +0200, M.-A. Lemburg wrote: > > > I can only speak for my mx stuff, but that still works greats > > with the 2.0 API -- except for the missing PyObject_Length() > > API, but that'll go back in as soon as Thomas has modified > > his patch on SF. > > I already did that ;) About 5 minutes after you added the comment about it. Checked in. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Mon Jul 17 10:30:02 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:30:02 -0700 Subject: [Python-Dev] binary incompatibility and tp_flags In-Reply-To: <3972C34E.A470B748@lemburg.com>; from mal@lemburg.com on Mon, Jul 17, 2000 at 10:26:54AM +0200 References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> <3972C34E.A470B748@lemburg.com> Message-ID: <20000717023002.C29590@lyra.org> On Mon, Jul 17, 2000 at 10:26:54AM +0200, M.-A. Lemburg wrote: > Greg Stein wrote: >... > > Actually, those flags should only be used if you are attempting to maintain > > binary compatibility. > > > > At the point where you say "okay. binary compatibility is hereby broken.", > > then we go and remove the flags for the new structure members. > > I can't remember anyone saying something in that direction. Never said anyone did :-) ... just said, "*when* it happens, then we have some stuff that we can clean out." > > The last API bump was to 1009 for "Unicode API added". I'm not sure why > > Guido bumped it since the *addition* of an API shouldn't create binary > > incompatibility. > > He bumped it so that extensions can switch on the API number > and then decide whether to use the new API or not... there are > extensions out there which want to be compatible to 1.5.2 *and* > 2.0. E.g. my mx stuff has a special portability file (mxpyapi.h) > which is meant to achieve exactly this... Hrm. This is a bit weird then. Modules will produce errors when they really don't need to. I understand that it would be handy to say "hey, does the Unicode stuff exist", but that same mechanism is going to produce errors at module-init time when stuff is loaded. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Mon Jul 17 10:39:50 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:39:50 -0700 Subject: [Python-Dev] if/else and macros In-Reply-To: <20000717111741.H7340@xs4all.nl>; from thomas@xs4all.net on Mon, Jul 17, 2000 at 11:17:41AM +0200 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> Message-ID: <20000717023950.E29590@lyra.org> On Mon, Jul 17, 2000 at 11:17:41AM +0200, Thomas Wouters wrote: > On Mon, Jul 17, 2000 at 02:05:32AM -0700, Greg Stein wrote: > > On Mon, Jul 17, 2000 at 09:55:02AM +0200, M.-A. Lemburg wrote: > > > > and it produces warnings which relate to the fact that the "else" > > > part is ambiguous: > > > > > > if (condition) UTF8_ERROR(); > > > else {...} > > > > > > expands to: > > > > > > if (condition) > > > if (1) {...} > > > else ; > > > else {...} > > > > That is not ambiguous. > > Nope. The example was flawed. *this* is ambiguous: > > if (condition) UTF8_ERROR(); > > And that's exactly what gcc is whining about: > > if (s + n > e) > UTF8_ERROR("unexpected end of data"); Oh come on. This is getting silly. Neither of those examples are ambiguous. C has a very strict definition of what happens. In your examples, it expands to: if (condition) if (1) { ... } else ; GCC spits out a warning to tell the person "oh hey... I'm associating that else with the second 'if' command... but I'm going to spit out a warning just in case that isn't want you really meant." There is no ambiguity. Zero. I repeat: none. GCC is simply *assuming* that you may have messed up, so it spits out a warning. But ambiguity? Not at all. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Fredrik Lundh" <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> Message-ID: <000d01bfefd3$b924d540$f2a6b5d4@hagrid> thomas wrote: > Even more arguable is the coding style issue ;) I haven't seen this = 'if (1) > {} else' trick used in macros elsewhere, not in Python and not in = other > code hey, it's saving a whopping ten lines of code, or so ;-) If I'd written that code, I'd spelled it out... and come to think of it, I *did* write the original version of that code! FYI, I don't like that macro. Instead of arguing about how it should look, just get rid of it. here's how the original code looked: if (ch < 0x80) goto bogus; /* illegal UTF-8 encoding */ ... bogus: PyErr_SetString( PyExc_ValueError, "invalid UTF-8 code" ); ... I would have implemented the changes like this: if (ch < 0x80) { detail =3D "illegal encoding"; goto bogus; } ... bogus: if (!utf8_decoding_error(&s, &p, errors, detail)) goto ignore; ... This solution gets rids of the macro mess, and what's more important, it moves exception handling out of the inner loop. (yes, it's using goto's, but it's a decoding loop, and it should be as fast as it possibly can -- especially if you're feeding it valid data!) The result is smaller source, smaller code, a smaller inner loop, faster decoding, and less discussion on this list. From gstein@lyra.org Mon Jul 17 10:57:56 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:57:56 -0700 Subject: [Python-Dev] if/else and macros In-Reply-To: <000d01bfefd3$b924d540$f2a6b5d4@hagrid>; from effbot@telia.com on Mon, Jul 17, 2000 at 11:45:18AM +0200 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> Message-ID: <20000717025756.G29590@lyra.org> On Mon, Jul 17, 2000 at 11:45:18AM +0200, Fredrik Lundh wrote: >... > This solution gets rids of the macro mess, and what's more > important, it moves exception handling out of the inner loop. > > (yes, it's using goto's, but it's a decoding loop, and it should > be as fast as it possibly can -- especially if you're feeding it > valid data!) > > The result is smaller source, smaller code, a smaller inner loop, > faster decoding, and less discussion on this list. Can't just out of the loop. One of the possible results of the error is to ignore it and continue. Or to insert a particular character and continue. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Mon Jul 17 11:04:12 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 12:04:12 +0200 Subject: [Python-Dev] binary incompatibility and tp_flags References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> <3972C34E.A470B748@lemburg.com> <20000717023002.C29590@lyra.org> Message-ID: <3972DA1C.E273F9C7@lemburg.com> Greg Stein wrote: > > On Mon, Jul 17, 2000 at 10:26:54AM +0200, M.-A. Lemburg wrote: > > Greg Stein wrote: > >... > > > Actually, those flags should only be used if you are attempting to maintain > > > binary compatibility. > > > > > > At the point where you say "okay. binary compatibility is hereby broken.", > > > then we go and remove the flags for the new structure members. > > > > I can't remember anyone saying something in that direction. > > Never said anyone did :-) ... just said, "*when* it happens, then we have > some stuff that we can clean out." Ah, ok :) > > > The last API bump was to 1009 for "Unicode API added". I'm not sure why > > > Guido bumped it since the *addition* of an API shouldn't create binary > > > incompatibility. > > > > He bumped it so that extensions can switch on the API number > > and then decide whether to use the new API or not... there are > > extensions out there which want to be compatible to 1.5.2 *and* > > 2.0. E.g. my mx stuff has a special portability file (mxpyapi.h) > > which is meant to achieve exactly this... > > Hrm. This is a bit weird then. Modules will produce errors when they really > don't need to. > > I understand that it would be handy to say "hey, does the Unicode stuff > exist", but that same mechanism is going to produce errors at module-init > time when stuff is loaded. The modules produce API warnings at startup, but they still continue to work like before and this is important since there are many people out there which are used to updating their software via RPM (or other packagers) and don't know how to compile source files. My comment about the API number bump was referring to using added functionality if available -- there could be #ifdef sections in the source files to enable/disable e.g. Unicode support. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul@prescod.net Mon Jul 17 11:42:59 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 05:42:59 -0500 Subject: [Python-Dev] Checked in... References: Message-ID: <3972E333.363CD227@prescod.net> Ka-Ping Yee wrote: > >... > > My plan was to complete htmldoc.py and try to get in into the > distribution so that anyone could browse documentation on the > standard library. +1 > It would include an option to start a little > webserver with a one-line command so that doc pages could be > automatically generated on your own modules as you work on them. +0 > The next step in the plan was to provide text output so you > could ask about modules from the shell prompt (like a "man" > command specific to Python) and a function call you could use > from inside the interpreter to get quick help as well. Not sure how to interpret this. If it depends on the aforementioned web server, I'm -1. If it calls the htmldoc code directly, I'm +1. I'd love to have the interpreter build on your docstring-formatting heuristics and that docstring-language plugin feature we discussed to allow people to experiment with semi-structured docstring formats. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Mon Jul 17 12:17:00 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 06:17:00 -0500 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> Message-ID: <3972EB2C.66EAB279@prescod.net> "M.-A. Lemburg" wrote: > > ... > > You may want to have a look at my hack.py utility which already > provides a convenient way of printing the doc strings *and* > the published interface: > > http://starship.python.net/·lemburg/hack.py Yes, that's got some pretty nice ideas. I may get the same features from Ka-Ping's htmldoc so that we don't have two pieces of code doing the same thing. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From peter@schneider-kamp.de Mon Jul 17 14:36:35 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 17 Jul 2000 13:36:35 +0000 Subject: [Python-Dev] SourceForge down? Message-ID: <39730BE3.B1A83A59@schneider-kamp.de> Since yesterday evening I cannot get to the Python pages at SourceForge. That is sometimes I cannot even log in to SourceForge. Other times it just takes minutes to load a page. Do you experience something similar? Or is it just me? Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mal@lemburg.com Mon Jul 17 12:40:50 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 13:40:50 +0200 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> <3972EB2C.66EAB279@prescod.net> Message-ID: <3972F0C2.E0266A0C@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > You may want to have a look at my hack.py utility which already > > provides a convenient way of printing the doc strings *and* > > the published interface: > > > > http://starship.python.net/~lemburg/hack.py > > Yes, that's got some pretty nice ideas. I may get the same features from > Ka-Ping's htmldoc so that we don't have two pieces of code doing the > same thing. Do you have a pointer for it ? (I'm always interested in new tools which support auto-documentation.) Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Mon Jul 17 12:44:55 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 13:44:55 +0200 Subject: [Python-Dev] SourceForge down? In-Reply-To: <39730BE3.B1A83A59@schneider-kamp.de>; from peter@schneider-kamp.de on Mon, Jul 17, 2000 at 01:36:35PM +0000 References: <39730BE3.B1A83A59@schneider-kamp.de> Message-ID: <20000717134455.J7340@xs4all.nl> On Mon, Jul 17, 2000 at 01:36:35PM +0000, Peter Schneider-Kamp wrote: > Since yesterday evening I cannot get to the Python pages at > SourceForge. That is sometimes I cannot even log in to > SourceForge. Other times it just takes minutes to load > a page. I had similar problems yesterday during the day. I've reported it to staff@sourceforge.net, and they confirmed something looked messed up. Sometime during the (european) evening things started working properly again. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Mon Jul 17 12:46:26 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 13:46:26 +0200 Subject: [Python-Dev] SourceForge down? References: <39730BE3.B1A83A59@schneider-kamp.de> Message-ID: <3972F212.5E5A7E4B@lemburg.com> Peter Schneider-Kamp wrote: > > Since yesterday evening I cannot get to the Python pages at > SourceForge. That is sometimes I cannot even log in to > SourceForge. Other times it just takes minutes to load > a page. > > Do you experience something similar? Or is it just me? Works fine for me... you sometimes just have to wait a few minutes for the response :-( -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul@prescod.net Mon Jul 17 12:52:14 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 06:52:14 -0500 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> <3972EB2C.66EAB279@prescod.net> <3972F0C2.E0266A0C@lemburg.com> Message-ID: <3972F36E.4A03E71B@prescod.net> "M.-A. Lemburg" wrote: > > > Do you have a pointer for it ? (I'm always interested in new > tools which support auto-documentation.) http://www.lfw.org/python/ -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From mal@lemburg.com Mon Jul 17 13:09:42 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 14:09:42 +0200 Subject: [Python-Dev] htmldoc.py + inspect.py References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> <3972EB2C.66EAB279@prescod.net> <3972F0C2.E0266A0C@lemburg.com> <3972F36E.4A03E71B@prescod.net> Message-ID: <3972F786.42FA2BE1@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > > > Do you have a pointer for it ? (I'm always interested in new > > tools which support auto-documentation.) > > http://www.lfw.org/python/ The output looks cool given that none of the standard lib Python module doc-strings were explicitely written to be rendered by this tool. But what I particularly like is the inspect.py module. That would make a great addition to the standard lib ! Note to Ping: your files are missing a clear license notice. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From infoez@macauweb.com Mon Jul 17 14:30:16 2000 From: infoez@macauweb.com (Sin Hang Kin) Date: Mon, 17 Jul 2000 21:30:16 +0800 Subject: [Python-Dev] Will Python die? Message-ID: <003f01bfeff3$26ac9840$770da8c0@bbs> This is a multi-part message in MIME format. ------=_NextPart_000_003A_01BFF036.32F0B800 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable See subject. I am really worry, before putting more effort to it, can any body = explain the current status of python 2?=20 Unicode is a must for my work, without it, python is useless. So I need = python 2, if 2.0 will die, I better switch beforehand. Sorry!!! but it is very important. Rgs, Kent Sin --------------------------------- kentsin.weblogs.com kentsin.imeme.net ------=_NextPart_000_003A_01BFF036.32F0B800 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
See subject.
I am really worry, before putting more effort to it, = can any=20 body explain the current status of python 2?
 
Unicode is a must for my work, without it, python is = useless.=20 So I need python 2, if 2.0 will die, I better switch = beforehand.
 
Sorry!!! but it is very important.
 
 
Rgs,
 
Kent=20 Sin
---------------------------------
kentsin.weblogs.com
kentsi= n.imeme.net
------=_NextPart_000_003A_01BFF036.32F0B800-- From jeremy@beopen.com Mon Jul 17 14:44:53 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 17 Jul 2000 09:44:53 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory In-Reply-To: <200007171050.DAA28047@slayer.i.sourceforge.net> References: <200007171050.DAA28047@slayer.i.sourceforge.net> Message-ID: <14707.3541.488523.886708@bitdiddle.concentric.net> Paul, You created a nondist subdirectory in the nondist tree. I don't think this is what you intended. Jeremy From mal@lemburg.com Mon Jul 17 14:43:51 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 15:43:51 +0200 Subject: [Python-Dev] Will Python die? References: <003f01bfeff3$26ac9840$770da8c0@bbs> Message-ID: <39730D97.323ADC08@lemburg.com> > Sin Hang Kin wrote: > > See subject. > I am really worry, before putting more effort to it, can any body explain the current status of python 2? In short: no way ;-) For the long story read on here: http://www.pythonlabs.com/tech/python2.html http://www.pythonlabs.com/tech/ http://www.pythonlabs.com/plans.html > Unicode is a must for my work, without it, python is useless. So I need python 2, if 2.0 will die, I better switch beforehand. Python2 has native Unicode support -- probably one of the most advanced there currently is among scripting languages. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Mon Jul 17 14:50:48 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 15:50:48 +0200 Subject: [Python-Dev] Will Python die? In-Reply-To: <003f01bfeff3$26ac9840$770da8c0@bbs>; from infoez@macauweb.com on Mon, Jul 17, 2000 at 09:30:16PM +0800 References: <003f01bfeff3$26ac9840$770da8c0@bbs> Message-ID: <20000717155048.K7340@xs4all.nl> On Mon, Jul 17, 2000 at 09:30:16PM +0800, Sin Hang Kin wrote: > I am really worry, before putting more effort to it, can any body explain > the current status of python 2? > Unicode is a must for my work, without it, python is useless. So I need > python 2, if 2.0 will die, I better switch beforehand. > Sorry!!! but it is very important. You betcha it's important ! What do those five people at PythonLabs do when Python dies ? They'd be out of a job ! Can't have that, now can we ;) Seriously, though: Python is not dead. Python 2 is not dead. CNRI and BeOpen are trying to resolve some 'issues', and the last news is that CNRI is going to release Python 1.6. I assume it'll be based off the 1.6 alphas, and those included unicode. BeOpen / PythonLabs will probably start by releasing Python 2.0. This'll likely have to wait until 1.6 is released, but the python dev team is working hard to make 2.0 a complete release on its own. It will include unicode, probably with less bugs and problems than 1.6 ;-) It will also include a ton of other things, which are being worked on right now. (Some of the things that might be included in 2.0 are list comprehensions (a way to replace map, filter and reduce), augmented assignment (x += y and such), online help() facility for the interpreter, possibly some new library modules, and many enhancements to the current standard library.) However, because of the issues between CNRI and BeOpen, it's completely unclear when Python 2.0 will be released. (Or, indeed, when CNRI's Python 1.6 will be released.) If you need the unicode support now, I'd suggest grabbing the CVS tree and see how it suits your needs. If it doesn't, give people here some feedback, so they can fix the problems or suggest ways to work around it. There are likely to be some changes to unicode (the functionality of '\x' and '\u' for instance) but the code is pretty solid as it is. Hope that helps ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one@email.msn.com Mon Jul 17 15:13:52 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 17 Jul 2000 10:13:52 -0400 Subject: [Python-Dev] SourceForge down? In-Reply-To: <39730BE3.B1A83A59@schneider-kamp.de> Message-ID: [Peter Schneider-Kamp] > Since yesterday evening I cannot get to the Python pages at > SourceForge. That is sometimes I cannot even log in to > SourceForge. Other times it just takes minutes to load > a page. > > Do you experience something similar? Or is it just me? Was true for me too all day, via the web interface. cmdline CVS worked fine, though. Couldn't get at patches. Off to CA for a week! If anyone wants to make progress on the patches assigned to me, be my guest ; from tim_one@email.msn.com on Mon, Jul 17, 2000 at 10:13:52AM -0400 References: <39730BE3.B1A83A59@schneider-kamp.de> Message-ID: <20000717163829.L7340@xs4all.nl> On Mon, Jul 17, 2000 at 10:13:52AM -0400, Tim Peters wrote: > Off to CA for a week! If anyone wants to make progress on the patches > assigned to me, be my guest myself (at least temporarily) off them!). I would take you off the patches, but I doubt anyone else would pick them up anyway ;) Some need an executive decision, I think, like the EXTENDED_ARG patch (which isn't assigned to you, yet) and the array.pop/count/etc patch. Some just need some discussion, and there isn't likely to be a lot of decision-making-discussion while almost all of PythonLabs and undoubtly the most of python-dev are at OSCON. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From peter@schneider-kamp.de Mon Jul 17 17:59:25 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 17 Jul 2000 16:59:25 +0000 Subject: [Python-Dev] SourceForge down? References: <39730BE3.B1A83A59@schneider-kamp.de> <20000717163829.L7340@xs4all.nl> Message-ID: <39733B6D.E4B83607@schneider-kamp.de> Thomas Wouters wrote: > > I would take you off the patches, but I doubt anyone else would pick them up > anyway ;) Some need an executive decision, I think, like the EXTENDED_ARG > patch (which isn't assigned to you, yet) and the array.pop/count/etc patch. And the {l,r}just with pad character patch (which isn't assigned to Tim either). > Some just need some discussion, and there isn't likely to be a lot of > decision-making-discussion while almost all of PythonLabs and undoubtly the > most of python-dev are at OSCON. Not if we want to keep our heads <0.99 wink>. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul@prescod.net Mon Jul 17 16:56:51 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 10:56:51 -0500 Subject: [Python-Dev] Will Python die? References: <003f01bfeff3$26ac9840$770da8c0@bbs> Message-ID: <39732CC3.4E1620C5@prescod.net> Python cannot die while its license permits anyone to improve it and there are still thousands of users. If Python were in any danger, there are dozens of people who could take over its advancement, including its current maintainer, Guido, at his new job! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Mon Jul 17 17:17:55 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 11:17:55 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> Message-ID: <397331B3.E12E9F31@prescod.net> Jeremy Hylton wrote: > > Paul, > > You created a nondist subdirectory in the nondist tree. I don't think > this is what you intended. Yeah, I know. Working in the middle of the night. I tried to remove it immediately but obviously didn't succeed. If its still there, maybe someone can enlighten me on how to dump it. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Fredrik Lundh" <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> <20000717025756.G29590@lyra.org> Message-ID: <009501bff00e$3d3bc980$f2a6b5d4@hagrid> greg wrote: > > The result is smaller source, smaller code, a smaller inner loop, > > faster decoding, and less discussion on this list. >=20 > Can't just out of the loop. One of the possible results of the error = is to > ignore it and continue. Or to insert a particular character and = continue. of course -- if you decide not to break the loop, just jump back in. I just fixed the UTF8 decoder: before: source: 5108 lines object size: 173,151 bytes after: source: 5106 lines object size: 171,630 bytes=20 just give me four more months ;-) From ping@lfw.org Mon Jul 17 17:48:50 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Mon, 17 Jul 2000 09:48:50 -0700 (PDT) Subject: [Python-Dev] htmldoc.py + inspect.py In-Reply-To: <3972F786.42FA2BE1@lemburg.com> Message-ID: On Mon, 17 Jul 2000, M.-A. Lemburg wrote: > > But what I particularly like is the inspect.py module. That > would make a great addition to the standard lib ! Yes, i consider inspect.py pretty much done, and hoped it would be considered for the standard library. I proposed it a little while ago (http://www.python.org/pipermail/python-dev/2000-May/011031.html); but it was set aside during the feature freeze. If we are in a position to consider it again now, then yes, i'd like to suggest it for the standard library. > Note to Ping: your files are missing a clear license notice. I thought we didn't have to add the contribution release form anymore because that was for CNRI? Anyway, i added a comment. Is it sufficient? # I, Ka-Ping Yee, the author of this contribution, hereby grant to anyone and # everyone a nonexclusive, irrevocable, royalty-free, worldwide license to # reproduce, distribute, perform and/or display publicly, prepare derivative # versions, and otherwise use this contribution as part of the Python software # and its related documentation, or any derivative versions thereof, at no cost # to anyone, and to authorize others to do so. -- ?!ng From bwarsaw@beopen.com Mon Jul 17 18:16:22 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 13:16:22 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> Message-ID: <14707.16230.872435.656875@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Yeah, I know. Working in the middle of the night. I tried to PP> remove it immediately but obviously didn't succeed. If its PP> still there, maybe someone can enlighten me on how to dump it. You can't. Somebody with access to the repository will have to remove it, but even then, if someone else has already done and update and gotten the new dir, it'll mess up their working directories. Best to just leave it empty and let "cvs up -P" prune it out. -Barry From ping@lfw.org Mon Jul 17 18:31:21 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Mon, 17 Jul 2000 10:31:21 -0700 (PDT) Subject: [Python-Dev] Checked in... In-Reply-To: <3972E333.363CD227@prescod.net> Message-ID: On Mon, 17 Jul 2000, Paul Prescod wrote: > Ka-Ping Yee wrote: > > My plan was to complete htmldoc.py and try to get in into the > > distribution so that anyone could browse documentation on the > > standard library. > > +1 Yay. :) > > It would include an option to start a little > > webserver with a one-line command so that doc pages could be > > automatically generated on your own modules as you work on them. > > +0 I'd like Python to come packaged in such a way that people can easily deploy it in an organization along with whatever stuff they develop. So being able to very easily generate and see docs on their own modules, integrated with the view of docs for the rest of the standard library, would be a nice thing. It makes a Python environment easier to support. > > The next step in the plan was to provide text output so you > > could ask about modules from the shell prompt (like a "man" > > command specific to Python) and a function call you could use > > from inside the interpreter to get quick help as well. > > Not sure how to interpret this. If it depends on the aforementioned web > server, I'm -1. If it calls the htmldoc code directly, I'm +1. Did you mean you wanted it to generate HTML and then use htmllib, like you did, to turn it into text? I hadn't thought of that. The way i imagined it, it wouldn't depend on htmldoc or the web server at all. It would call inspect.py to get its info and just format some text on its own. Before you posted onlineHelp (great work, by the way!), i was thinking of calling it "pydoc", and envisioning something like: >>> import pydoc # or have site.py take care of this >>> pydoc.doc(urllib) ---- module urllib: Open an arbitrary URL. See the following document for more info on URLs: "Names and Addresses, URIs, URLs, URNs, URCs", at http://www.w3.org/pub/WWW/Addressing/Overview.html . . . ---- functions: urlopen(url, data=None) urlretrieve(url, filename=None, reporthook=Nne) . . . ---- classes: class URLopener: Class to open URLs. . . . etc. and also the same output from the shell command % pydoc urllib ---- module urllib: Open an arbitrary URL. See the following document for more info on URLs: "Names and Addresses, URIs, URLs, URNs, URCs", at http://www.w3.org/pub/WWW/Addressing/Overview.html . . . etc. This is basically identical to how you were describing the onlinehelp/help commands. I didn't think of using the external (TeX/HTML) documentation though... that's a clever idea. So: - use doc pages only? - use internal info only? - separate scripts for each? - use both? - use doc pages if installed, then fall back to internal info? One other note: how about leaving the job of listing the text to to an external app like "less"/"more", as determined by the PAGER environment variable, allowing customization? The code we use to figure out what program to run should eventually move into launch.textviewer. Perhaps this would then provide interactive apps (e.g. IDLE) the opportunity to simply replace (or hook into) launch.textviewer. > I'd love > to have the interpreter build on your docstring-formatting heuristics > and that docstring-language plugin feature we discussed to allow people > to experiment with semi-structured docstring formats. Sure. Not a high priority for me, but once we have the module, it's easy to extend and experiment. -- ?!ng From peter@schneider-kamp.de Mon Jul 17 20:45:44 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 17 Jul 2000 19:45:44 +0000 Subject: [Python-Dev] Will Python die? References: <003f01bfeff3$26ac9840$770da8c0@bbs> <39732CC3.4E1620C5@prescod.net> Message-ID: <39736268.306B8DF0@schneider-kamp.de> Paul Prescod wrote: > > Python cannot die while its license permits anyone to improve it and > there are still thousands of users. If Python were in any danger, there > are dozens of people who could take over its advancement, including its > current maintainer, Guido, at his new job! Tim once (0.9-winking-ly) mentioned the possibility of voting with the "keyboard by grabbing the Python source and making your own release". I don't wanna do this on my own (and get zapped from a lightning bolt thrown by the powers that are), but what would be the pros and cons of an inofficial (maybe 1.8?) alpha-in-between-release? I think the CVS tree is in a relative stable state, so if this is going to take another 1 1/2 months, this might be a good time. just-thinking-and-winking-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mal@lemburg.com Mon Jul 17 18:46:01 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 19:46:01 +0200 Subject: [Python-Dev] htmldoc.py + inspect.py References: Message-ID: <39734659.16D327D9@lemburg.com> Ka-Ping Yee wrote: > > On Mon, 17 Jul 2000, M.-A. Lemburg wrote: > > > > But what I particularly like is the inspect.py module. That > > would make a great addition to the standard lib ! > > Yes, i consider inspect.py pretty much done, and hoped it would be > considered for the standard library. I proposed it a little while ago > (http://www.python.org/pipermail/python-dev/2000-May/011031.html); > but it was set aside during the feature freeze. > > If we are in a position to consider it again now, then yes, i'd like > to suggest it for the standard library. Don't know if we are in such a position, but it's worth putting on the list of candidates. Perhaps you should simply put up a patch to SF which includes the module -- this will give it some more exposure and assure that the idea is not lost. > > Note to Ping: your files are missing a clear license notice. > > I thought we didn't have to add the contribution release form > anymore because that was for CNRI? Sure, but there may be others who would like to use it, right ;-) As long as there's no license on a file, you bascially cannot legally copy it without first getting the authors permission. > Anyway, i added a comment. Is it sufficient? > > # I, Ka-Ping Yee, the author of this contribution, hereby grant to anyone and > # everyone a nonexclusive, irrevocable, royalty-free, worldwide license to > # reproduce, distribute, perform and/or display publicly, prepare derivative > # versions, and otherwise use this contribution as part of the Python software > # and its related documentation, or any derivative versions thereof, at no cost > # to anyone, and to authorize others to do so. This only gives the right to use the module in case it becomes part of the standard lib :-( I usually put the old Python license into the files (with changed names of course). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping@lfw.org Mon Jul 17 19:01:58 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Mon, 17 Jul 2000 11:01:58 -0700 (PDT) Subject: [Python-Dev] htmldoc.py + inspect.py In-Reply-To: <39734659.16D327D9@lemburg.com> Message-ID: On Mon, 17 Jul 2000, M.-A. Lemburg wrote: > This only gives the right to use the module in case it becomes > part of the standard lib :-( Fixed. # I, Ka-Ping Yee, the author of this contribution, hereby grant to anyone and # everyone a nonexclusive, irrevocable, royalty-free, worldwide license to # reproduce, distribute, perform and/or display publicly, prepare derivative # versions, and otherwise use this contribution in any fashion, or any # derivative versions thereof, at no cost to anyone, and to authorize others # to do so. This software is provided "as is", with NO WARRANTY WHATSOEVER, # not even a warranty of merchantability or fitness for any particular purpose. Geez. Is that enough words yet? All i wanted to say was "go play". :) -- ?!ng From thomas@xs4all.net Mon Jul 17 19:01:16 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 20:01:16 +0200 Subject: [Python-Dev] 'shadowing' builtins Message-ID: <20000717200116.P7340@xs4all.nl> This is probably the wrong time, given that most of y'all are likely on their way to OSCON ;) But the perl-hugging hippy colleague of mine that is currently at OSCON gave (as in 'handed') me this idea on shadowing builtins. He decided to go to David Beazly's python introduction, and he was suprised at how you can do 'None = 4'. And when I explained it's harmless (because it's local, not global) he was suprised it didn't generate a warning. And, well, why doesn't it generate a warning ? Only with an, uhm, '-w' option or so, of course, or perhaps add it to the '-t' option. It would be also a compile-time-check. It might require a seperate lookup table (haven't looked at it at all, yet) that duplicates the 'builtin' namespace, but I'd think it's worth it. Or is this an old and already-shot-down idea ? :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Mon Jul 17 19:04:19 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 20:04:19 +0200 Subject: [Python-Dev] if/else and macros References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> <20000717025756.G29590@lyra.org> <009501bff00e$3d3bc980$f2a6b5d4@hagrid> Message-ID: <39734AA3.7B33EE44@lemburg.com> Fredrik Lundh wrote: > > greg wrote: > > > The result is smaller source, smaller code, a smaller inner loop, > > > faster decoding, and less discussion on this list. > > > > Can't just out of the loop. One of the possible results of the error is to > > ignore it and continue. Or to insert a particular character and continue. > > of course -- if you decide not to break the loop, just > jump back in. This is getting silly, really ;-) Jumping out of loops is ok, but jumping back in is not: you can never know whether the optimizer rearranges the loop code, so jumping *into* loop constructs is not going to be portable. I'll remove the macro completely and also fix the UTF16 codec which has the same continue problem. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul@prescod.net Mon Jul 17 19:04:22 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 13:04:22 -0500 Subject: [Python-Dev] Checked in... References: Message-ID: <39734AA5.C6ACA757@prescod.net> Ka-Ping Yee wrote: > > ... > > I'd like Python to come packaged in such a way that people can > easily deploy it in an organization along with whatever stuff > they develop. So being able to very easily generate and see docs > on their own modules, integrated with the view of docs for the > rest of the standard library, would be a nice thing. It makes a > Python environment easier to support. Agreed. I'm just not sure if it requires a webserver. You could set up a makefile to recognize when an HTML doc is out of sync with its Python. > The way i imagined it, it wouldn't depend on htmldoc or the web > server at all. It would call inspect.py to get its info and just > format some text on its own. I didn't know about the clean separation of htmldoc and inspect when I wrote that. You're right, it should call inspect directly. > This is basically identical to how you were describing the > onlinehelp/help commands. I didn't think of using the external > (TeX/HTML) documentation though... that's a clever idea. So: > > - use doc pages only? That's not doable unless there is a process to get docstrings into doc pages -- which is a great idea but probably some ways away. > - use internal info only? Where do I get information on statements and "topics" (like slicing, as a topic). > - separate scripts for each? Maybe internally. Ideally not at the user interface layer. > - use doc pages if installed, then fall back to internal info? My model, which you may or may not have noticed yet, is to use docstrings for objects that have docstrings, but the docstrings can point to HTML documentation in the circumstance where the canonical doc is maintained in HTML. In that case, I magically go to the HTML, rather than showing the reference. My personal feeling is that over time a lot of the library documentation should move inline for ease of maintenance and reduction of duplication. But that won't happen until we integrate inspect.py and latex2html. I have some ideas about that too. It's the opposite of the current scheme. We should put pointers from the LaTeX into the modules. A preprocessor would use inspect.py to generate a combined LaTeX that merges inline (LaTeX) and out-of-line (docstring) information. Then we start moving bits of the documentation into docstrings a little at a time. Anything that uses LaTeX features that are "funky" can stay in LaTeX until we invent a structured docstring syntax (whenever). > One other note: how about leaving the job of listing the text to > to an external app like "less"/"more", as determined by the PAGER > environment variable, allowing customization? The code we use to > figure out what program to run should eventually move into > launch.textviewer. I'm happy to do this on platforms that support it. I'm somewhat nervous about popen on non-Unix systems...maybe I should write a text file and then launch the pager on that. > Perhaps this would then provide interactive apps (e.g. IDLE) the > opportunity to simply replace (or hook into) launch.textviewer. Good idea. One tricky issue is what format to use, though. troff/man is great for Unix TTY, HTML is great for GUIs and raw text is the lowest common denominiator. Do I want to get into n*m translations? Maybe, maybe not. Or maybe HTML is the lowest common denominator and Unix TTY users should use lynx? -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Mon Jul 17 19:18:44 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 13:18:44 -0500 Subject: [Python-Dev] 'shadowing' builtins References: <20000717200116.P7340@xs4all.nl> Message-ID: <39734E04.C7D29873@prescod.net> Thomas Wouters wrote: > > ... > > He decided to go to David Beazly's python introduction, and he was suprised > at how you can do 'None = 4'. And when I explained it's harmless (because > it's local, not global) he was suprised it didn't generate a warning. And, > well, why doesn't it generate a warning ? Only with an, uhm, '-w' option or > so, of course, or perhaps add it to the '-t' option. It would be also a > compile-time-check. It might require a seperate lookup table (haven't looked > at it at all, yet) that duplicates the 'builtin' namespace, but I'd think > it's worth it. A few thoughts: * None, map and other such long-term, ancient built-ins should not be directly overridable. I don't think we need a warning mode. Just outlaw it. We can do this with a semantic check in the compiler. * Those with a good reason to shadow them would do it by assignment to the module's dict or __builtins__. The "feature" would still be there if you need it, but it would be syntactically distinct. Or maybe we need to disallow it entirely to allow optimizers to attack this important special case. * Python badly needs a warning infrastructure. If I had time, that would be my first PEP. I'd rather the former tightening up was not hostage to a warning infrastructure that nobody gets around to implementing, though. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Mon Jul 17 19:21:25 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 13:21:25 -0500 Subject: [Python-Dev] Will Python die? References: <003f01bfeff3$26ac9840$770da8c0@bbs> <39732CC3.4E1620C5@prescod.net> <39736268.306B8DF0@schneider-kamp.de> Message-ID: <39734EA5.BBF96453@prescod.net> Peter Schneider-Kamp wrote: > > ... > > Tim once (0.9-winking-ly) mentioned the possibility of voting with the > "keyboard by grabbing the Python source and making your own release". As long as Tim and Guido are thinking about this possibility, I don't want to waste my brain cells considering it. I don't have as much information as they do and I'm only a little bit smarter than them anyhow. :) Seriously, I don't know enough about the licensing issues. I don't know exactly what CNRI "owns" and what we need from them to proceed. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Mon Jul 17 19:23:34 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 13:23:34 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> Message-ID: <39734F26.5799F13D@prescod.net> "Barry A. Warsaw" wrote: > > ... > > You can't. Gah. That sucks. > Somebody with access to the repository will have to remove > it, You mean an SF employee? > but even then, if someone else has already done and update and > gotten the new dir, it'll mess up their working directories. Best to > just leave it empty and let "cvs up -P" prune it out. Not in the long run. It's just messy. There's a mistake I won't make again (this week). -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Fredrik Lundh" <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> <20000717025756.G29590@lyra.org> <009501bff00e$3d3bc980$f2a6b5d4@hagrid> <39734AA3.7B33EE44@lemburg.com> Message-ID: <003101bff01f$193c5520$f2a6b5d4@hagrid> mal wrote: > This is getting silly, really ;-) indeed. > Jumping out of loops is ok, but jumping back in is not: you can > never know whether the optimizer rearranges the loop code, so > jumping *into* loop constructs is not going to be portable. sorry, but that's bullshit. if the optimizer cannot figure out where basic blocks start and end, it's broken beyond repair. quoting the ANSI C rationale: "The Committee considered proposals for forbidding a goto into a block from outside, since such a restriction would make possible much easier flow optimization and would avoid the whole issue of initializing auto storage (see =A73.1.2.4). The Committee rejected such a ban out of fear of invalidating working code (however un- disciplined) and out of concern for those producing machine- generated C." From bwarsaw@beopen.com Mon Jul 17 19:54:11 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 14:54:11 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> Message-ID: <14707.22099.762232.325117@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: >> You can't. PP> Gah. That sucks. Welcome to CVS. What did Greg Wilson say at IPC8? Paraphrasing: CVS is the worst tool everybody uses. :) >> Somebody with access to the repository will have to remove it, PP> You mean an SF employee? Yup, you need to make an admin request to do anything with the repository, like remove directories, move files, or clear locks. >> but even then, if someone else has already done and update and >> gotten the new dir, it'll mess up their working directories. >> Best to just leave it empty and let "cvs up -P" prune it out. PP> Not in the long run. It's just messy. PP> There's a mistake I won't make again (this week). Been there, done that. :) -Barry From bwarsaw@beopen.com Mon Jul 17 20:06:13 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 15:06:13 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration Message-ID: <14707.22821.945571.314619@anthem.concentric.net> I've made a final pass through PEP 201, Parallel Iteration. For those of you without easy access to the CVS tree, I'm including it below. You can also access it through the web at http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/python/nondist/peps/pep-0201.txt?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=python High bit: Guido strongly prefers zip() as the name of the built-in. All the suggestions so far have pluses and minuses, and in the absence of a clear winner, he'd just as soon go with the Haskell name. I agree. Please see the new reference implementation, which includes a __len__() method, and the discussion of the rejected elaborations. There's still the open issue of what zip(sequence_a) should return. I'd like to reach closure on this sometime soon after the guys get back from California. -Barry -------------------- snip snip -------------------- PEP: 201 Title: Parallel Iteration Version: $Revision: 1.2 $ Owner: bwarsaw@beopen.com (Barry A. Warsaw) Python-Version: 2.0 Status: Draft Introduction This PEP describes the `parallel iteration' proposal for Python 2.0, previously known as `parallel for loops'. This PEP tracks the status and ownership of this feature, slated for introduction in Python 2.0. It contains a description of the feature and outlines changes necessary to support the feature. This PEP summarizes discussions held in mailing list forums, and provides URLs for further information, where appropriate. The CVS revision history of this file contains the definitive historical record. Standard For-Loops Motivation for this feature has its roots in a concept described as `parallel for loops'. A standard for-loop in Python iterates over every element in the sequence until the sequence is exhausted. A `break' statement inside the loop suite causes an explicit loop exit. For-loops also have else: clauses which get executed when the loop exits normally (i.e. not by execution of a break). For-loops can iterate over built-in types such as lists and tuples, but they can also iterate over instance types that conform to an informal sequence protocol. This protocol states that the instance should implement the __getitem__() method, expecting a monotonically increasing index starting at 0, and this method should raise an IndexError when the sequence is exhausted. This protocol is currently undocumented -- a defect in Python's documentation hopefully soon corrected. For-loops are described in the Python language reference manual[1]. An example for-loop: >>> for i in (1, 2, 3): print i ... 1 2 3 In this example, the variable `i' is called the `target', and is assigned the next element of the list, each time through the loop. Parallel For-Loops Parallel for-loops are non-nested iterations over two or more sequences, such that at each pass through the loop, one element from each sequence is taken to compose the target. This behavior can already be accomplished in Python through the use of the map() built-in function: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> for i in map(None, a, b): print i ... (1, 4) (2, 5) (3, 6) Here, map() returns a list of N-tuples, where N is the number of sequences in map()'s argument list (after the initial `None'). Each tuple is constructed of the i-th elements from each of the argument lists, specifically in this example: >>> map(None, a, b) [(1, 4), (2, 5), (3, 6)] The for-loop simply iterates over this list as normal. While the map() idiom is a common one in Python, it has several disadvantages: - It is non-obvious to programmers without a functional programming background. - The use of the magic `None' first argument is non-obvious. - It has arbitrary, often unintended, and inflexible semantics when the lists are not of the same length: the shorter sequences are padded with `None'. >>> c = (4, 5, 6, 7) >>> map(None, a, c) [(1, 4), (2, 5), (3, 6), (None, 7)] For these reasons, several proposals were floated in the Python 2.0 beta time frame for providing a better spelling of parallel for-loops. The initial proposals centered around syntactic changes to the for statement, but conflicts and problems with the syntax were unresolvable, especially when parallel for-loops were combined with another proposed feature called `list comprehensions' (see pep-0202.txt). The Proposed Solution The proposed solution is to introduce a new built-in sequence generator function, available in the __builtin__ module. This function is to be called `zip' and has the following signature: zip(seqa, [seqb, [...]], [pad=]) zip() takes one or more sequences and weaves their elements together, just as map(None, ...) does with sequences of equal length. The optional keyword argument `pad', if supplied, is a value used to pad all shorter sequences to the length of the longest sequence. If `pad' is omitted, then weaving stops when the shortest sequence is exhausted. It is not possible to pad short lists with different pad values, nor will zip() ever raise an exception with lists of different lengths. To accomplish either behavior, the sequences must be checked and processed before the call to zip(). Lazy Execution For performance purposes, zip() does not construct the list of tuples immediately. Instead it instantiates an object that implements a __getitem__() method and conforms to the informal for-loop protocol. This method constructs the individual tuples on demand. Examples Here are some examples, based on the reference implementation below. >>> a = (1, 2, 3, 4) >>> b = (5, 6, 7, 8) >>> c = (9, 10, 11) >>> d = (12, 13) >>> zip(a, b) [(1, 5), (2, 6), (3, 7), (4, 8)] >>> zip(a, d) [(1, 12), (2, 13)] >>> zip(a, d, pad=0) [(1, 12), (2, 13), (3, 0), (4, 0)] >>> zip(a, d, pid=0) Traceback (most recent call last): File "", line 1, in ? File "/usr/tmp/python-iKAOxR", line 11, in zip TypeError: unexpected keyword arguments >>> zip(a, b, c, d) [(1, 5, 9, 12), (2, 6, 10, 13)] >>> zip(a, b, c, d, pad=None) [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)] >>> map(None, a, b, c, d) [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)] Reference Implementation Here is a reference implementation, in Python of the zip() built-in function and helper class. These would ultimately be replaced by equivalent C code. class _Zipper: def __init__(self, args, kws): # Defaults self.__padgiven = 0 if kws.has_key('pad'): self.__padgiven = 1 self.__pad = kws['pad'] del kws['pad'] # Assert no unknown arguments are left if kws: raise TypeError('unexpected keyword arguments') self.__sequences = args self.__seqlen = len(args) def __getitem__(self, i): ret = [] exhausted = 0 for s in self.__sequences: try: ret.append(s[i]) except IndexError: if not self.__padgiven: raise exhausted = exhausted + 1 if exhausted == self.__seqlen: raise ret.append(self.__pad) return tuple(ret) def __len__(self): # If we're padding, then len is the length of the longest sequence, # otherwise it's the length of the shortest sequence. if not self.__padgiven: shortest = -1 for s in self.__sequences: slen = len(s) if shortest < 0 or slen < shortest: shortest = slen return shortest longest = 0 for s in self.__sequences: slen = len(s) if slen > longest: longest = slen return longest def __str__(self): ret = [] i = 0 while 1: try: ret.append(self[i]) except IndexError: break i = i + 1 return str(ret) __repr__ = __str__ def zip(*args, **kws): return _Zipper(args, kws) Rejected Elaborations Some people have suggested that the user be able to specify the type of the inner and outer containers for the zipped sequence. This would be specified by additional keyword arguments to zip(), named `inner' and `outer'. This elaboration is rejected for several reasons. First, there really is no outer container, even though there appears to be an outer list container the example above. This is simply an artifact of the repr() of the zipped object. User code can do its own looping over the zipped object via __getitem__(), and build any type of outer container for the fully evaluated, concrete sequence. For example, to build a zipped object with lists as an outer container, use >>> list(zip(sequence_a, sequence_b, sequence_c)) for tuple outer container, use >>> tuple(zip(sequence_a, sequence_b, sequence_c)) This type of construction will usually not be necessary though, since it is expected that zipped objects will most often appear in for-loops. Second, allowing the user to specify the inner container introduces needless complexity and arbitrary decisions. You might imagine that instead of the default tuple inner container, the user could prefer a list, or a dictionary, or instances of some sequence-like class. One problem is the API. Should the argument to `inner' be a type or a template object? For flexibility, the argument should probably be a type object (i.e. TupleType, ListType, DictType), or a class. For classes, the implementation could just pass the zip element to the constructor. But what about built-in types that don't have constructors? They would have to be special-cased in the implementation (i.e. what is the constructor for TupleType? The tuple() built-in). Another problem that arises is for zips greater than length two. Say you had three sequences and you wanted the inner type to be a dictionary. What would the semantics of the following be? >>> zip(sequence_a, sequence_b, sequence_c, inner=DictType) Would the key be (element_a, element_b) and the value be element_c, or would the key be element_a and the value be (element_b, element_c)? Or should an exception be thrown? This suggests that the specification of the inner container type is needless complexity. It isn't likely that the inner container will need to be specified very often, and it is easy to roll your own should you need it. Tuples are chosen for the inner container type due to their (slight) memory footprint and performance advantages. Open Issues - What should "zip(a)" do? Given a = (1, 2, 3); zip(a) three outcomes are possible. 1) Returns [(1,), (2,), (3,)] Pros: no special casing in the implementation or in user code, and is more consistent with the description of it's semantics. Cons: this isn't what map(None, a) would return, and may be counter to user expectations. 2) Returns [1, 2, 3] Pros: consistency with map(None, a), and simpler code for for-loops, e.g. for i in zip(a): instead of for (i,) in zip(a): Cons: too much complexity and special casing for what should be a relatively rare usage pattern. 3) Raises TypeError Pros: None Cons: needless restriction Current scoring seems to generally favor outcome 1. - The name of the built-in `zip' may cause some initial confusion with the zip compression algorithm. Other suggestions include (but are not limited to!): marry, weave, parallel, lace, braid, interlace, permute, furl, tuples, lists, stitch, collate, knit, plait, and with. All have disadvantages, and there is no clear unanimous choice, therefore the decision was made to go with `zip' because the same functionality is available in other languages (e.g. Haskell) under the name `zip'[2]. References [1] http://www.python.org/doc/devel/ref/for.html [2] http://www.haskell.org/onlinereport/standard-prelude.html#$vzip TBD: URL to python-dev archives Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: From thomas@xs4all.net Mon Jul 17 20:38:04 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 21:38:04 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net>; from bwarsaw@beopen.com on Mon, Jul 17, 2000 at 03:06:13PM -0400 References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <20000717213804.Q7340@xs4all.nl> On Mon, Jul 17, 2000 at 03:06:13PM -0400, Barry A. Warsaw wrote: > There's still the open issue of what zip(sequence_a) should return. I'd vote for [(a,), (b,), (c,)], that is, still return tuples. It's consistent with the use in the case of multiple sequences. We already have map(None, sequence_a) that does it the non-obvious way ;) In the map case it's easily explained: it turns the sequence into a list. In the case of zip(), that isn't necessary (and not the point of the function, anyway.) I-still-wish-it-were-marry()-ly y'rs, ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Mon Jul 17 20:39:14 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 21:39:14 +0200 Subject: [Python-Dev] Will Python die? In-Reply-To: <39734EA5.BBF96453@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 01:21:25PM -0500 References: <003f01bfeff3$26ac9840$770da8c0@bbs> <39732CC3.4E1620C5@prescod.net> <39736268.306B8DF0@schneider-kamp.de> <39734EA5.BBF96453@prescod.net> Message-ID: <20000717213914.R7340@xs4all.nl> On Mon, Jul 17, 2000 at 01:21:25PM -0500, Paul Prescod wrote: > Peter Schneider-Kamp wrote: > I don't have as much information as they do and I'm only a little bit > smarter than them anyhow. :) Yeah, I'm only a little bit smarter than Guido divided by Tim, too. Or-is-that-Guido-minus-Tim-ly y'rs, ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Fredrik Lundh" <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> <20000717025756.G29590@lyra.org> <009501bff00e$3d3bc980$f2a6b5d4@hagrid> <39734AA3.7B33EE44@lemburg.com> <003101bff01f$193c5520$f2a6b5d4@hagrid> Message-ID: <007201bff02a$46f02860$f2a6b5d4@hagrid> I wrote: > sorry, but that's bullshit. or in slightly fewer words: "goto !=3D longjmp" From Vladimir.Marangozov@inrialpes.fr Mon Jul 17 21:15:40 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Mon, 17 Jul 2000 22:15:40 +0200 (CEST) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net> from "Barry A. Warsaw" at Jul 17, 2000 03:06:13 PM Message-ID: <200007172015.WAA25033@python.inrialpes.fr> Barry A. Warsaw wrote: > > > I've made a final pass through PEP 201, Parallel Iteration. Nice! I think that a broader audience needs to read this. Why not asking for reactions on c.l.py? > High bit: Guido strongly prefers zip() as the name of the built-in. > All the suggestions so far have pluses and minuses, and in the absence > of a clear winner, he'd just as soon go with the Haskell name. I > agree. I don't feel comfortable with it. Period. You might want to see what http://www.dict.org has to say about it. Looking at the examples for this builtin function, and without thinking too much about the name, I'd call it - fold(). zip-gun'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gmcm@hypernet.com Mon Jul 17 21:22:45 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Mon, 17 Jul 2000 16:22:45 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <1248257113-63674673@hypernet.com> Barry A. Warsaw wrote: [PEP 201, Parallel Iteration] > Open Issues > > - What should "zip(a)" do? Given > > a = (1, 2, 3); zip(a) > > three outcomes are possible. How about a fourth: zip(a) is the same as zip(a, []) ? Look at it this way: what should zip(a, pad=None) return? Obviously: [(1, None), (2, None), (3, None)] So what should zip(a) return? Don't special case it, just return []. With only one arg, zip has clearly lost meaning. That is, it's clearly a degenerate case, and not worth a bunch of special casing. although-we-do-special-case-Barry-ly y'rs - Gordon From esr@thyrsus.com Mon Jul 17 22:01:15 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Mon, 17 Jul 2000 17:01:15 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net> References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <20000717170114.B7624@thyrsus.com> Barry A. Warsaw : > High bit: Guido strongly prefers zip() as the name of the built-in. > All the suggestions so far have pluses and minuses, and in the absence > of a clear winner, he'd just as soon go with the Haskell name. I agree. Grumble. Not too happy with the conclusion, but can't argue with the logic. I somewhat reluctantly agree. -- Eric S. Raymond Gun Control: The theory that a woman found dead in an alley, raped and strangled with her panty hose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound. -- L. Neil Smith From skip@mojam.com (Skip Montanaro) Mon Jul 17 20:58:11 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Mon, 17 Jul 2000 14:58:11 -0500 (CDT) Subject: [Python-Dev] 'shadowing' builtins In-Reply-To: <20000717200116.P7340@xs4all.nl> References: <20000717200116.P7340@xs4all.nl> Message-ID: <14707.25939.889361.800800@beluga.mojam.com> Thomas> He decided to go to David Beazly's python introduction, and he Thomas> was suprised at how you can do 'None = 4'. And when I explained Thomas> it's harmless (because it's local, not global) he was suprised Thomas> it didn't generate a warning. And, well, why doesn't it generate Thomas> a warning? I wrote a script some time ago to print these warnings. Search http://www.musi-cal.com/~skip/python/ for the string "hiding builtin names"... Skip From peter@schneider-kamp.de Tue Jul 18 00:39:31 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 17 Jul 2000 23:39:31 +0000 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <200007172015.WAA25033@python.inrialpes.fr> Message-ID: <39739933.DFFAAFD9@schneider-kamp.de> Vladimir Marangozov wrote: > > I don't feel comfortable with it. Period. > You might want to see what http://www.dict.org has to say about it. > > Looking at the examples for this builtin function, and without thinking > too much about the name, I'd call it - fold(). Please, don't!!! As far as I can remember, fold is the "reduce of the functional languages". At least it is that in Haskell. Here's a quote from the Journal of Functional Programming (July 1999): "In functional programming, fold is a standard operator that encapsulates a simple pattern of recursion for processing lists." BTW: I still like zip() and as someone said: dir and del have the same problem/not-a-problem Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Vladimir.Marangozov@inrialpes.fr Mon Jul 17 23:05:06 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Tue, 18 Jul 2000 00:05:06 +0200 (CEST) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <39739933.DFFAAFD9@schneider-kamp.de> from "Peter Schneider-Kamp" at Jul 17, 2000 11:39:31 PM Message-ID: <200007172205.AAA25258@python.inrialpes.fr> Peter Schneider-Kamp wrote: > > [me] > > Looking at the examples for this builtin function, and without thinking > > too much about the name, I'd call it - fold(). > > Please, don't!!! As far as I can remember, fold is the "reduce of the > functional languages". At least it is that in Haskell. > > Here's a quote from the Journal of Functional Programming (July 1999): > "In functional programming, fold is a standard operator that > encapsulates a simple pattern of recursion for processing lists." Okay, but weren't we paying less attention to historical facts in language design? Guido regrets map() that slipped through, for instance. My opinion is a newbie opinion. I just can't believe that we can't find a more intuitive name for this function! From what I read in the PEP, several sequences are folded element-wise into one sequence, with optional padding. And that's all! Since it's a builtin function, it should make sense in contexts other than parallel iterations. What's the problem with `folding' sequences element-wise in Python? What's the problem with `zipping' sequences element-wise in Python? Which one of the 2 questions above makes more sense? let's-stay-rational'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From peter@schneider-kamp.de Tue Jul 18 01:11:03 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 00:11:03 +0000 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <3973A097.B85D6775@schneider-kamp.de> "Barry A. Warsaw" wrote: > > I've made a final pass through PEP 201, Parallel Iteration. For those > of you without easy access to the CVS tree, I'm including it below. > You can also access it through the web at Great work. It's a pleasure to read. > High bit: Guido strongly prefers zip() as the name of the built-in. > All the suggestions so far have pluses and minuses, and in the absence > of a clear winner, he'd just as soon go with the Haskell name. I > agree. I agree (giving +1 would be blasphemy, right?). One important remark: What about unzip()? Shouldn't there be the reverse function? One example (which I really wrote not so long ago in an ANN context): def normalize(seq): # scale to values in 0..1 return map(lambda x, max=max(seq), min=min(seq): (x-min)/(max-min), seq) # from file with: x1 y1 z1\nx2 y2 z2\n etc. data = [[1.0, 2.0, 3.0], [-1.0, 1.0, -1.0], [-1.0, -2.0, -3.0], [2.0, 3.0, 1.0]] # zip related data fields, normalize that field, unzip data = unzip(map(normalize,zip(data))) > Please see the new reference implementation, which includes a > __len__() method, and the discussion of the rejected elaborations. > There's still the open issue of what zip(sequence_a) should return. I think zip([1, 2, 3]) should give ((1), (2), (3)). My reasons? 1) It feels right to me. 2) It is the way Lisp (or Scheme, don't remember) deals with it. [Haskell's zip-unzip is limited to two lists] By the way, yet another example for unzip(): mylist = [(1,), (2,), (3,)] What looks better? a) newlist = map(lambda x:x[0], mylist) b) newlist = unzip(mylist) advocating-unzip-as-an-overridable-builtin-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Fredrik Lundh" Message-ID: <006f01bff03d$c1f20c00$f2a6b5d4@hagrid> > I just can't believe that we can't find a more intuitive name > for this function! ...and I cannot believe that you're trying to reopen this discussion once again :-( (or is this a trick by Guido to make sure we don't do any real work while he's on the conference? ;-) "After consultation with Guido, zip() is chosen as the name of this built-in." -- seen on the python-checkins list. From peter@schneider-kamp.de Tue Jul 18 01:21:16 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 00:21:16 +0000 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <200007172205.AAA25258@python.inrialpes.fr> Message-ID: <3973A2FC.2CD26F44@schneider-kamp.de> Vladimir Marangozov wrote: > > What's the problem with `folding' sequences element-wise in Python? > > What's the problem with `zipping' sequences element-wise in Python? > > Which one of the 2 questions above makes more sense? The first. But it gives me the wrong impression: fold the list [1, 2, 3]: \ / f(1,f(2,f(3))) for some function f fold the lists [1, 2, 3] and [4, 5, 6] elementwise: \ / f(f(3,f(6)),f(f(2,f(5)),f(1,f(4)))) for some function f I'd just wonder what to fold the lists with. Even if my judgement is biased by my Haskell organ, I still think that taking the name of an important list operator from different languages for a completely different list operation is way worse than using the name of a file compression utility as a list operator. just-my-cents(0.02)-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Vladimir.Marangozov@inrialpes.fr Mon Jul 17 23:38:32 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Tue, 18 Jul 2000 00:38:32 +0200 (CEST) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <006f01bff03d$c1f20c00$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 18, 2000 12:24:21 AM Message-ID: <200007172238.AAA25374@python.inrialpes.fr> Fredrik Lundh wrote: > > > I just can't believe that we can't find a more intuitive name > > for this function! > > ...and I cannot believe that you're trying to reopen this discussion > once again :-( :-) Sorry, but it was discussed during a short period of time (despite the huge number of posts in that time slice) and I wasn't really available for participating seriously in the discussion. So now I'm taking the opportunity to read the PEP without much external pression, as well as to say what I think and to think what I say. Note that I suggested Barry to sumbit this PEP to a broader audience for collection external opinions on all aspects of the PEP. If there are several people with CS background that don't feel good with this name, there's something wrong with it. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gmcm@hypernet.com Mon Jul 17 23:44:44 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Mon, 17 Jul 2000 18:44:44 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <200007172238.AAA25374@python.inrialpes.fr> References: <006f01bff03d$c1f20c00$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 18, 2000 12:24:21 AM Message-ID: <1248248594-64187019@hypernet.com> Vladimir.Marangozov wrote: > Fredrik Lundh wrote: > > > > > I just can't believe that we can't find a more intuitive name > > > for this function! > > > > ...and I cannot believe that you're trying to reopen this > > discussion once again :-( > > :-) Sorry, but it was discussed during a short period of time > (despite the huge number of posts in that time slice) and I > wasn't really available for participating seriously in the > discussion. So now I'm taking the opportunity to read the PEP > without much external pression, as well as to say what I think > and to think what I say. > > Note that I suggested Barry to sumbit this PEP to a broader > audience for collection external opinions on all aspects of the > PEP. If there are several people with CS background that don't > feel good with this name, there's something wrong with it. To me, "zip" in the context of computers means compress. But it's a stupid name for compress. And one look at the args makes it obvious it's not a compress. So I expect that your typical newbie will do one, and only one "Huh??? Oh - zip as in zipper, not zip as in PKZIP" and never have to post again. wishfully-y'rs - Gordon From Vladimir.Marangozov@inrialpes.fr Tue Jul 18 00:11:47 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Tue, 18 Jul 2000 01:11:47 +0200 (CEST) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248248594-64187019@hypernet.com> from "Gordon McMillan" at Jul 17, 2000 06:44:44 PM Message-ID: <200007172311.BAA25445@python.inrialpes.fr> Gordon McMillan wrote: > > To me, "zip" in the context of computers means compress. > But it's a stupid name for compress. And one look at the args > makes it obvious it's not a compress. So I expect that your > typical newbie will do one, and only one "Huh??? Oh - zip as > in zipper, not zip as in PKZIP" and never have to post again. Right. > > wishfully-y'rs My wish is to add fold() as one of the suggested names in the PEP, then let this PEP spend some time in c.l.py. Give people a chance to catch up, please. That's how the PEP process is intended to work. The name hasn't been cast in stone. It's in the PEP, not in CVS. end-of-story-ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul@prescod.net Tue Jul 18 00:10:53 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 18:10:53 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <3973927D.D2D37DE0@prescod.net> I would say that you should make the ambiguous single-param case illegal. For one of the examples you say: > for i in zip(a): Why would you ever do that??? The only way that would make sense to me if zip([[1],[2]])==zip([1],[2]), which I would dislike. Use zip(*[[1],[2]]) instead. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Tue Jul 18 00:11:17 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 18:11:17 -0500 Subject: [Python-Dev] Votes Message-ID: <39739295.4AEB5195@prescod.net> I'm going to wait for four positive votes or one from Guido before I take the following action cd nondist cvs add sandbox cd sandbox cvs add onlinehelp.py cvs add inspect.py -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From peter@schneider-kamp.de Tue Jul 18 02:19:33 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 01:19:33 +0000 Subject: [Python-Dev] Votes References: <39739295.4AEB5195@prescod.net> Message-ID: <3973B0A5.AE63E45F@schneider-kamp.de> Paul Prescod wrote: > > I'm going to wait for four positive votes or one from Guido before I > take the following action Don't know if my one counts, but you can have it anyway: +1 on nondist/sandbox Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From akuchlin@mems-exchange.org Tue Jul 18 00:57:32 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon, 17 Jul 2000 19:57:32 -0400 (EDT) Subject: [Python-Dev] Python-dev summary: Jul 1-15 Message-ID: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Note: this is an experiment in whether I can make a useful, interesting, somewhat coherent summary of python-dev activity. Things I'm not sure of: * Accuracy. I skipped past some threads such as the list comprehensions one, and may be unaware of a resolution. * How many links are needed? Should I try to link to several posts per thread, SF patches, etc.? That makes more work for me, but also makes the summary more useful. * Bi-weekly OK? I think it's a reasonable frequency. I'll check my e-mail tomorrow; if no one screams loudly, I'll post it. (My connectivity is poor enough that I don't want to do major editing on it, or be able to respond to many e-mails in detail.) ================== Python-dev summary, July 1-15, 2000: The 2-week period started with reactions to Guido's June 30 announcement that the 2.0b1 release would be delayed for an indefinite period due to legal wrangling. This gave everyone a second chance to contribute more patches while waiting for the release, and the activity level remained high. Two dominant issues for this time period were Unicode-related issues, and list comprehensions. The Unicode issues, as usual, turned on the question of where strings and Unicode strings should be interchangeable. A discussion in the thread "Minidom and Unicode" considered whether it's legal to return a Unicode string from __repr__. The consensus was that it should be legal, despite fears of breaking code that expects only an 8-bit string, and the CVS tree was patched accordingly. Python's interpreter mode uses repr() to display the results of expressions, and it will convert Unicode strings to ASCII, using the unicode-escape encoding. The following code, typed into the interpreter, will print 'abc\u3456'. class C: def __repr__(self): return u'abc\u3456' print repr( C() ) Hashing also presented a problem. As M.-A. Lemburg explained in http://www.python.org/pipermail/python-dev/2000-July/012150.html: The problem comes from the fact that the default encoding can be changed to a locale specific value (site.py does the lookup for you), e.g. given you have defined LANG to be us_en, Python will default to Latin-1 as default encoding. This results in 'äöü' == u'äöü', but hash('äöü') != hash(u'äöü'), which is in conflict with the general rule about objects having the same hash value if they compare equal. The resolution seems to be simply removing the ability to change the default encoding and adopt ASCII as the fixed default; if you want to use other encodings, you must specify them explicitly. List comprehensions originated as a patch from Greg Ewing that's now being kept up-to-date versus the CVS tree by Skip Montanaro. Originally they weren't on the roadmap for 1.6, but with the greater version number jump to 2.0, GvR is more willing to incorporate larger changes. List comprehensions provide a more concise way to create lists in situations where map() and filter() would currently be used. To take some examples from the patched-for-list-comphrensions version of the Python Tutorial: >>> spcs = [" Apple", " Banana ", "Coco nut "] >>> print [s.strip() for s in spcs] ['Apple', 'Banana', 'Coco nut'] >>> vec1 = [2, 4, 6] >>> vec2 = [4, 3, -9] >>> print [x*y for x in vec1 for y in vec2] [8, 6, -18, 16, 12, -36, 24, 18, -54] A lengthy subthread about intuitiveness sprang from the second example, and from a patch from Thomas Wouters that implements parallel 'for' loops. The patch makes "for x in [1,2]; y in ['a','b']" cause x,y to be 1,'a', and then 2,'b'. The thread circulated around whether people would expect this syntax to produce the Cartesian product of the two lists: (1,'a'), (1, 'b'), (2, 'a'), (2, 'b'). No clear answer or final syntax has emerged yet, though Greg Wilson has been trying out syntaxes on Python-unaware people and asking them what they'd expect: http://www.python.org/pipermail/python-dev/2000-July/012810.html It was also suggested to add a new built-in function for parallel 'for' loops instead of new syntax, so you would code 'for x,y in zip([1,2], ['a','b']):'. A lengthy and very dull discussion ensued about the name 'zip': should it be 'plait', 'knit', 'parallel', or even 'marry'? Some new procedures for Python development were set out: Tim Peters wrote some guidelines for using SourceForge's patch manager: http://www.python.org/pipermail/python-dev/2000-July/012635.html Barry Warsaw announced a series of Python Extension Proposal (PEP) documents, which play the role of RFCs for significant changes to Python: http://www.python.org/pipermail/python-dev/2000-July/013059.html Mark Hammond gave the first glimpse of a fourth Python implementation: "This new compiler could be compared, conceptually, with JPython - it is a completely new implementation of Python. It has a compiler that generates native Windows .DLL/.EXE files. It uses a runtime that consists of a few thousand lines of C# (C-Sharp) code. The Python programs can be debugged at the source level with Visual Studio 7, as well as stand-alone debuggers for this environment. Python can sub-class VB or C# classes, and vice-versa." http://www.python.org/pipermail/python-dev/2000-July/013019.html Other bits: Skip Montanaro experimented with using code coverage tools to measure the effectiveness of the Python test suite, by seeing which lines of code (both C and Python) that are exercised by the tests. A summary of the results is at: http://www.musi-cal.com/~skip/python/Python/dist/src/summary.html Skip also added support to the readline module for saving and loading command histories. ESR suggested adding a standard lexer to the core, and /F suggested an extension to regular expressions that would make them more useful for tokenizing: http://www.python.org/pipermail/python-dev/2000-July/012032.html CVS problems were briefly a distraction, with dangling locks preventing commits to the Lib/ and Modules/ subdirectories for a few days. Despite such glitches, the move to SourceForge has accelerated development overall, as more people can make check-ins and review them. For some time Tim Peters has been suggesting removing the Py_PROTO macro and making the sources require ANSI C; mostly this is because the macro breaks the C cross-referencing support in Tim's editor. :) The ball finally started rolling on this, and snowballed into a massive set of patches to use ANSI C prototypes everywhere. Fred Drake and Peter Schneider-Kamp rose to the occasion and edited the prototypes in dozens of files. Jeremy Hylton pointed out that "Tuple, List, String, and Dict have a Py*_Size method. The abstract object interface uses PySequence_Length. This is inconsistent and hard to remember," and suggested that *_Size be made the standard form, and *_Length will be deprecated. Just before the cutoff date, Paul Prescod proposed a new help() function for interactive use, and began implementing it: http://www.python.org/pipermail/python-dev/2000-July/013346.html Huaiyu Zhu suggested adding new operators to support matrix math: http://www.python.org/pipermail/python-dev/2000-July/013364.html A slew of minor patches and bugfixes were made, too. Some highlights: * Ka-Ping Yee improved the syntax error messages. * ESR made various changes to ConfigParser.py * Some of Sam Rushing's patches from Medusa were applied to add os.setreuid() and friends; AMK is working on adding the poll() system call. * /F was his usual "patching machine" self, integrating PythonWin's win32popen function so that os.popen will now work correctly on Windows as well as Unix, writing PyErr_SafeFormat() to prevent buffer overflows, and proposing some patches to reduce the 600K size of the Unicode character database. Some fun posts came up during the near-endless zip()/plait()/whatever naming thread: http://www.python.org/pipermail/python-dev/2000-July/012920.html: "BTW: How comes, that Ping very often invents or introduces very clever ideas and concepts, but also very often chooses unclear names for them? Is it just me not being a native english speaker?" "I don't know. Perhaps my florx bignal zupkin isn't very moognacious?" -- Peter Funk and Ka-Ping Yee, 12 Jul 2000 http://www.python.org/pipermail/python-dev/2000-July/013050.html, while everyone was trying to think up alternative names for zip(): "Let me throw one more out, in honor of our fearless leader's recent life change: marry(). Usually only done in pairs, and with two big sequences, I get the image of a big Unification Church event :)" "Isn't it somewhat of a political statement to allow marriages of three or more items? I always presumed that this function was n-ary, like map." -- Barry Warsaw and Paul Prescod From bwarsaw@beopen.com Tue Jul 18 01:04:02 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 20:04:02 -0400 (EDT) Subject: [Python-Dev] Votes References: <39739295.4AEB5195@prescod.net> Message-ID: <14707.40690.705582.995282@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> I'm going to wait for four positive votes or one from Guido PP> before I take the following action | cd nondist | cvs add sandbox | cd sandbox | cvs add onlinehelp.py | cvs add inspect.py +1 And since I'm the only one left minding the store, while everyone else goes off galavanting in sunny California, you can read that as +1000 :) nothing-like-a-dose-of-al-haig-to-make-you-feel-important-til-the-boss-comes- home-ly y'rs, -Barry From gstein@lyra.org Tue Jul 18 01:13:17 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 17:13:17 -0700 Subject: [Python-Dev] htmldoc.py + inspect.py In-Reply-To: ; from ping@lfw.org on Mon, Jul 17, 2000 at 11:01:58AM -0700 References: <39734659.16D327D9@lemburg.com> Message-ID: <20000717171317.P29590@lyra.org> On Mon, Jul 17, 2000 at 11:01:58AM -0700, Ka-Ping Yee wrote: > On Mon, 17 Jul 2000, M.-A. Lemburg wrote: > > This only gives the right to use the module in case it becomes > > part of the standard lib :-( > > Fixed. > > # I, Ka-Ping Yee, the author of this contribution, hereby grant to anyone and > # everyone a nonexclusive, irrevocable, royalty-free, worldwide license to > # reproduce, distribute, perform and/or display publicly, prepare derivative > # versions, and otherwise use this contribution in any fashion, or any > # derivative versions thereof, at no cost to anyone, and to authorize others > # to do so. This software is provided "as is", with NO WARRANTY WHATSOEVER, > # not even a warranty of merchantability or fitness for any particular purpose. > > Geez. Is that enough words yet? All i wanted to say was "go play". :) Here is short for you: # Written by Ka-Ping Yee. Public Domain. No warranties. Can't get any easier than that. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Tue Jul 18 01:21:23 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 17:21:23 -0700 Subject: [Python-Dev] Votes In-Reply-To: <39739295.4AEB5195@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 06:11:17PM -0500 References: <39739295.4AEB5195@prescod.net> Message-ID: <20000717172123.Q29590@lyra.org> On Mon, Jul 17, 2000 at 06:11:17PM -0500, Paul Prescod wrote: > I'm going to wait for four positive votes or one from Guido before I > take the following action > > cd nondist > cvs add sandbox > cd sandbox > cvs add onlinehelp.py > cvs add inspect.py Considering that I suggested /nondist/sandbox/ it probably stands to reason that you had my +1 all along :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul@prescod.net Tue Jul 18 01:27:46 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 19:27:46 -0500 Subject: [Python-Dev] Python-dev summary: Jul 1-15 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: <3973A482.48023039@prescod.net> I like it. I don't see anything about range literals, though. Probably buried in the list comp. discussion. I can't remember anything else you might have missed off the top of my head. I liked the part where someone asked: "What causes these CVS locks?" and Tim replied: "Skip, apparently." Luckily you cut off before I get zapped with a lightening bolt for checking in inappropriately. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul@prescod.net Tue Jul 18 01:30:08 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 19:30:08 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> Message-ID: <3973A510.86D2AF54@prescod.net> "Barry A. Warsaw" wrote: > > >>>>> "PP" == Paul Prescod writes: > > >> You can't. > > PP> Gah. That sucks. > > Welcome to CVS. What did Greg Wilson say at IPC8? Paraphrasing: CVS > is the worst tool everybody uses. :) Okay, but it isn't entirely CVS' fault. Not *entirely*. Shouldn't out CVS space be writeable by one of us. Okay, that person could royally screw everything up but hey, that's the whole point of Unix, isn't it? -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From klm@digicool.com Tue Jul 18 01:40:33 2000 From: klm@digicool.com (Ken Manheimer) Date: Mon, 17 Jul 2000 20:40:33 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <3973A097.B85D6775@schneider-kamp.de> Message-ID: On Tue, 18 Jul 2000, Peter Schneider-Kamp wrote: > One important remark: > What about unzip()? Shouldn't there be the reverse function? > One example (which I really wrote not so long ago in an ANN context): Evan Simpson (a colleague here at digicool, who'd be a good addition to python-dev) noticed that unzip is unnecessary - zip is its own inverse. Since this is a worthwhile observation, i'll indulge a bit and present it in evan's terms - particularly noting a different packaging that i think is pretty cool, as methods on sequences. > From evan@digicool.com Mon Jul 17 20:17:30 2000 > Date: Mon, 17 Jul 2000 14:36:18 -0400 > From: Evan Simpson > To: Ken Manheimer > Subject: Next Braid > > How's this: > > ([1, 2, 3], ['a', 'b', 'c']).braid() == ((1, 'a'), (2, 'b'), (3, 'c')) > [[1, 2, 3], ['a', 'b', 'c']].braid() == [(1, 'a'), (2, 'b'), (3, 'c')] > > and > > [[1,2,3], ['a']].braid(None) == [(1, 'a'), (2, None), (3, None)] > > Also, notice that if 's' is a rectangular sequence of sequences, then for > all 'a' and 'b': > > s.braid()[a][b] == s[b][a] by definition, so > > s.braid().braid()[a][b] == s.braid()[b][a] == s[a][b] and therefore, > > braid is its own inverse, and we don't need unbraid. > > Cheers, > > Evan @ digicool & 4-am I can't do better than that, but i have one further elaboration i'd like to see. If the subject sequence already contains some elements, the result sequence is a copy of the originals with the new braided, whoops zipped elements appended - this way, braids can be cumulative. >>> [(1, 3), (2, 4)].braid(('a', 'b'), ('x', 'y')) [(1, 3, 'a', 'x'), (2, 4, 'b', 'y')] Anyway, we don't need an unzip/unbraid. ! Ken klm@digicool.com From klm@digicool.com Tue Jul 18 01:43:38 2000 From: klm@digicool.com (Ken Manheimer) Date: Mon, 17 Jul 2000 20:43:38 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: Message-ID: Whoops, i got my section wrong. Disregard the last part. On Mon, 17 Jul 2000, Ken Manheimer wrote: > On Tue, 18 Jul 2000, Peter Schneider-Kamp wrote: > > > One important remark: > > What about unzip()? Shouldn't there be the reverse function? > > One example (which I really wrote not so long ago in an ANN context): > > Evan Simpson (a colleague here at digicool, who'd be a good addition > to python-dev) noticed that unzip is unnecessary - zip is its own > inverse. Since this is a worthwhile observation, i'll indulge a bit > and present it in evan's terms - particularly noting a different > packaging that i think is pretty cool, as methods on sequences. > > > From evan@digicool.com Mon Jul 17 20:17:30 2000 > > Date: Mon, 17 Jul 2000 14:36:18 -0400 > > From: Evan Simpson > > To: Ken Manheimer > > Subject: Next Braid > > > > How's this: > > > > ([1, 2, 3], ['a', 'b', 'c']).braid() == ((1, 'a'), (2, 'b'), (3, 'c')) > > [[1, 2, 3], ['a', 'b', 'c']].braid() == [(1, 'a'), (2, 'b'), (3, 'c')] > > > > and > > > > [[1,2,3], ['a']].braid(None) == [(1, 'a'), (2, None), (3, None)] > > > > Also, notice that if 's' is a rectangular sequence of sequences, then for > > all 'a' and 'b': > > > > s.braid()[a][b] == s[b][a] by definition, so > > > > s.braid().braid()[a][b] == s.braid()[b][a] == s[a][b] and therefore, > > > > braid is its own inverse, and we don't need unbraid. > > > > Cheers, > > > > Evan @ digicool & 4-am > > I can't do better than that, but i have one further elaboration i'd > like to see. If the subject sequence already contains some elements, > the result sequence is a copy of the originals with the new braided, > whoops zipped elements appended - this way, braids can be cumulative. > > >>> [(1, 3), (2, 4)].braid(('a', 'b'), ('x', 'y')) > [(1, 3, 'a', 'x'), (2, 4, 'b', 'y')] > > Anyway, we don't need an unzip/unbraid. ! > > Ken > klm@digicool.com > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev > From mhammond@skippinet.com.au Tue Jul 18 03:16:51 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Mon, 17 Jul 2000 22:16:51 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <003f01bfefc6$64840540$f2a6b5d4@hagrid> Message-ID: [Fredrik] > I'm probably missing something here, but is there any reason > you cannot add this code to Py_InitModule4 instead: > > PyObject *m, *d, *v; > PyMethodDef *ml; > + if (!Py_IsInitialized()) > + Py_FatalError("Bad Python version"); /* Never returns */ Py_InitModule4() is inside Pythonxx.dll - so it _will_ be initialized. The point of putting this code inside the .pyd is that the .pyd will be calling the Py_IsInitialized() from Python15.dll - and this DLL has never been initialized. Putting it inside Py_InitModule4() will never trigger an error... Mark. From pingster@ilm.com Tue Jul 18 03:37:08 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Mon, 17 Jul 2000 19:37:08 -0700 (PDT) Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: On Mon, 17 Jul 2000, Andrew Kuchling wrote: > Note: this is an experiment in whether I can make a useful, > interesting, somewhat coherent summary of python-dev activity. Very nice job! Well done. Thanks for doing all the work! > * Accuracy. I skipped past some threads such as the list > comprehensions one, and may be unaware of a resolution. As Paul mentioned, there was some talk about range literals. There was some stuff about augmented assignment too, i believe? Thomas Wouters tried to summarize the list-comp, parallel-iteration, and range-literal threads, to which i responded with an alternative proposal. Huaiyu Zhu also presented a fairly complete list-comp proposal (though i think the syntax is not quite implementable). Eric suggested adding a cross-platform "browse" routine to urllib. Some discussion ensued; some names for a separate module were proposed including "webbrowser.py"; some people suggested using the "start" command on Windows instead; i suggested a "launch" module for launching other kinds of external applications as well as web browsers; i don't remember if any resolution was reached. Paul started a small thread on automatic coercion of any type to string. There was some discussion of rearranging newsgroup and mailing list traffic, choosing more distinct purposes for comp.lang.python and python-dev, etc. A suggestion to make string.atoi work for negative bases was politely but quickly squashed. There were random gripes about SourceForge. Moshe suggested a file-copy routine that accepted objects; Greg Stein checked it in. Paul raised the issue of bringing an XPath implementation into Python. Paul made a fairly detailed proposal for an online help mechanism (this happened on July 15 at the end of your time window; more discussion ensued). -- ?!ng "Smoking kills. If you're killed, you've lost a very important part of your life." -- Brooke Shields From gmcm@hypernet.com Tue Jul 18 03:38:37 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Mon, 17 Jul 2000 22:38:37 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: References: <003f01bfefc6$64840540$f2a6b5d4@hagrid> Message-ID: <1248234561-65031149@hypernet.com> Mark Hammond wrote: > [Fredrik] > > I'm probably missing something here, but is there any reason > > you cannot add this code to Py_InitModule4 instead: > > > > PyObject *m, *d, *v; > > PyMethodDef *ml; > > + if (!Py_IsInitialized()) > > + Py_FatalError("Bad Python version"); /* Never returns */ > > Py_InitModule4() is inside Pythonxx.dll - so it _will_ be > initialized. The point of putting this code inside the .pyd is > that the .pyd will be calling the Py_IsInitialized() from > Python15.dll - and this DLL has never been initialized. Putting > it inside Py_InitModule4() will never trigger an error... Florida sun getting to you? Or the teenage girls? Or just being in the wrong hemisphere (so all the blood rushes to your feet)? initXXX() (normally) calls Py_InitModule4, so it would be the one in whatever XXXmodule loaded. - Gordon From gmcm@hypernet.com Tue Jul 18 03:38:37 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Mon, 17 Jul 2000 22:38:37 -0400 Subject: [Python-Dev] Votes In-Reply-To: <14707.40690.705582.995282@anthem.concentric.net> Message-ID: <1248234559-65031252@hypernet.com> Barry A. Warsaw wrote: > +1 > > And since I'm the only one left minding the store, while everyone > else goes off galavanting in sunny California, you can read that > as +1000 :) > > nothing-like-a-dose-of-al-haig-to-make-you-feel-important-til-the > -boss-comes- home-ly y'rs, -Barry C'mon Barry, you didn't verb a single noun! - Gordon From mhammond@skippinet.com.au Tue Jul 18 03:42:49 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Mon, 17 Jul 2000 22:42:49 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <1248234561-65031149@hypernet.com> Message-ID: > Florida sun getting to you? Or the teenage girls? Or just being > in the wrong hemisphere (so all the blood rushes to your feet)? > > initXXX() (normally) calls Py_InitModule4, so it would be the > one in whatever XXXmodule loaded. Doh! All of the above - plus an unshakable belief that while on vacation I never need to check my facts before spouting off. But-fortunately-that-all-ends-tomorrow-ly, Mark. From bwarsaw@beopen.com Tue Jul 18 04:27:21 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 23:27:21 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> Message-ID: <14707.52889.135983.472187@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Okay, but it isn't entirely CVS' fault. Not PP> *entirely*. Shouldn't out CVS space be writeable by one of PP> us. Okay, that person could royally screw everything up but PP> hey, that's the whole point of Unix, isn't it? Yeah, but it's only necessary because CVS doesn't let you do those tasks through it's interface. Well, kind of a pointless argument because it probably won't change on SF any time soon, and who among us is actively hacking on CVS? :) -Barry From esr@thyrsus.com Tue Jul 18 05:06:44 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Tue, 18 Jul 2000 00:06:44 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: References: <3973A097.B85D6775@schneider-kamp.de> Message-ID: <20000718000644.A8911@thyrsus.com> Ken Manheimer : > > ([1, 2, 3], ['a', 'b', 'c']).braid() == ((1, 'a'), (2, 'b'), (3, 'c')) > > [[1, 2, 3], ['a', 'b', 'c']].braid() == [(1, 'a'), (2, 'b'), (3, 'c')] > > > > and > > > > [[1,2,3], ['a']].braid(None) == [(1, 'a'), (2, None), (3, None)] This is rather cool -- I especially like the implied feature of deriving the type of the result from the type of the outermost level of the object. I would be +1 on making zip/braid a sequence method rather than a function. -- Eric S. Raymond I don't like the idea that the police department seems bent on keeping a pool of unarmed victims available for the predations of the criminal class. -- David Mohler, 1989, on being denied a carry permit in NYC From gstein@lyra.org Tue Jul 18 04:55:50 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 20:55:50 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory In-Reply-To: <14707.52889.135983.472187@anthem.concentric.net>; from bwarsaw@beopen.com on Mon, Jul 17, 2000 at 11:27:21PM -0400 References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> <14707.52889.135983.472187@anthem.concentric.net> Message-ID: <20000717205550.Z29590@lyra.org> On Mon, Jul 17, 2000 at 11:27:21PM -0400, Barry A. Warsaw wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> Okay, but it isn't entirely CVS' fault. Not > PP> *entirely*. Shouldn't out CVS space be writeable by one of > PP> us. Okay, that person could royally screw everything up but > PP> hey, that's the whole point of Unix, isn't it? > > Yeah, but it's only necessary because CVS doesn't let you do those > tasks through it's interface. Well, kind of a pointless argument > because it probably won't change on SF any time soon, and who among us > is actively hacking on CVS? :) I'm actively involved with CVS's successor. Does that count? :-) -- Greg Stein, http://www.lyra.org/ From bwarsaw@beopen.com Tue Jul 18 04:56:42 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 23:56:42 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> <14707.52889.135983.472187@anthem.concentric.net> <20000717205550.Z29590@lyra.org> Message-ID: <14707.54650.959052.870977@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> I'm actively involved with CVS's successor. Does that count? GS> :-) Only if I get to play with it! From esr@thyrsus.com Tue Jul 18 05:15:51 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Tue, 18 Jul 2000 00:15:51 -0400 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: <20000718001551.C8911@thyrsus.com> Ka-Ping Yee : > Eric suggested adding a cross-platform "browse" routine to urllib. > Some discussion ensued; some names for a separate module were > proposed including "webbrowser.py"; some people suggested using > the "start" command on Windows instead; i suggested a "launch" > module for launching other kinds of external applications as well > as web browsers; i don't remember if any resolution was reached. Fred Drake coded up a new version after I critiqued the original. He and I agreed it was good, and we didn't see any -1s on adding it to the library. Fred, did you ever commit that sucker? -- Eric S. Raymond The possession of arms by the people is the ultimate warrant that government governs only with the consent of the governed. -- Jeff Snyder From paul@prescod.net Tue Jul 18 05:00:36 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 23:00:36 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> <14707.52889.135983.472187@anthem.concentric.net> Message-ID: <3973D664.747D3886@prescod.net> "Barry A. Warsaw" wrote: > > ... > > Yeah, but it's only necessary because CVS doesn't let you do those > tasks through it's interface. Well, kind of a pointless argument > because it probably won't change on SF any time soon, and who among us > is actively hacking on CVS? :) I mean CVS stores our information as a bunch of files on a hard disk. Those files use the Unix UGO security model. You are some one trusted (one or the other) should be in the PythonAdmins Unix group and you or that person should be able to physically change files in our directories using your shell account. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From gstein@lyra.org Tue Jul 18 05:17:17 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 21:17:17 -0700 Subject: [Python-Dev] CVS: python/nondist/nondist - New directory In-Reply-To: <3973D664.747D3886@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 11:00:36PM -0500 References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> <14707.52889.135983.472187@anthem.concentric.net> <3973D664.747D3886@prescod.net> Message-ID: <20000717211717.C29590@lyra.org> On Mon, Jul 17, 2000 at 11:00:36PM -0500, Paul Prescod wrote: > "Barry A. Warsaw" wrote: > > > > ... > > > > Yeah, but it's only necessary because CVS doesn't let you do those > > tasks through it's interface. Well, kind of a pointless argument > > because it probably won't change on SF any time soon, and who among us > > is actively hacking on CVS? :) > > I mean CVS stores our information as a bunch of files on a hard disk. > Those files use the Unix UGO security model. You are some one trusted > (one or the other) should be in the PythonAdmins Unix group and you or > that person should be able to physically change files in our directories > using your shell account. "should" != "current state of things" :-) The CVS repositories aren't opened up like that on SF, AFAIK. So yes, "should" is quite true, but that doesn't help us now :-( As Barry said... unless SF changes that policy, then we just deal with it. We could make an SF admin request to torch the nondist/nondist directory from the repository. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Moshe Zadka Tue Jul 18 06:54:15 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 18 Jul 2000 08:54:15 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: On Mon, 17 Jul 2000, Barry A. Warsaw wrote: [On the builtin that resembles lambda *args: map(None, *args)] > High bit: Guido strongly prefers zip() as the name of the built-in. > All the suggestions so far have pluses and minuses, and in the absence > of a clear winner, he'd just as soon go with the Haskell name. I > agree. > > Please see the new reference implementation, which includes a > __len__() method, and the discussion of the rejected elaborations. > There's still the open issue of what zip(sequence_a) should return. I'm +1 on that. One thing that bugs me is that we're adding a builtin type. Why not stick with the Python implementation? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas@xs4all.net Tue Jul 18 07:11:58 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 08:11:58 +0200 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: <200007172357.TAA16970@newcnri.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Mon, Jul 17, 2000 at 07:57:32PM -0400 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: <20000718081158.T7340@xs4all.nl> On Mon, Jul 17, 2000 at 07:57:32PM -0400, Andrew Kuchling wrote: > List comprehensions originated as a patch from Greg Ewing that's now > being kept up-to-date versus the CVS tree by Skip Montanaro. > Originally they weren't on the roadmap for 1.6, but with the greater > version number jump to 2.0, GvR is more willing to incorporate larger > changes. It may be worth mentioning that augmented assignment is also being considered for 2.0, and possibly other operators (we still haven't heard from Guido on that, I believe, and there was at least one +1 from Eric.) Also, maybe the outcome of small CNRI/BeOpen thread would be nice to mention? CNRI says they will release python 1.6, and python 2.0 will probably (possibly ?) be released by BeOpen after that ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From klm@digicool.com Tue Jul 18 07:16:07 2000 From: klm@digicool.com (Ken Manheimer) Date: Tue, 18 Jul 2000 02:16:07 -0400 (EDT) Subject: [Python-Dev] pdbtrack.el - alt approach to emacs-based python debugging Message-ID: <14707.63015.14103.987843@korak.digicool.com> You emacs inhabitants out there may be interested in pdbtrack.el, a little alternative for source-file python debugging in emacs: http://www.zope.org/Wikis/klm/PDBTrack With pdbtrack, whenever you run pdb, emacs tracks (*) the current source file line, centered in another emacs window. It keys on the process output, cuing on the stack trace format and the pdb prompt, so it's pretty unlikely to misfire. That's all it does - it lacks a lot of GUD features, like putting highlighting glyphs on the current line, providing debugging commands from inside the source file buffer, etc. On the other hand, it's also very trim, code-lines-wise - a total of 122 lines, without any GUD connection, and that includes 59 lines that are only for working around a bug in mainline emacs' make-local-hook. (Incorporating the GUD-style features may not be too hard - since it touches the buffer where the debugging was started, as well as the source file buffers, it could set up the necessary state and bindings per session. But i'm not particularly driven to pursue that - tracking the current line in the source file seems to be most of what i need...) The fundamental difference between pdbtrack and GUD/pdb.el is that pdbtrack doesn't require you to launch the debugging session from a particular buffer - it tracks from any comint buffers where you run python. This fits the way i tend to use the debugger - generally, i do more-or-less elaborate interactions with my application *before* i go into the debugger, to set up the context and/or explore my way to the debugging start point. With GUD i have to start the session directly in the debugger. And then, when i finish a GUD session, (i believe) the context is lost. When debugging in a regular shell buffer (and the python-mode py-shell, etc), i drop back into python, wander around, and often launch back into the debugger, with the accumulated state. pdbtrack tracks wherever and whenver you're running pdb in emacs. (I posted more description yesterday to the python and the zope lists: http://www.python.org/pipermail/python-list/2000-July/108654.html ) If this proves to be of general interest and acceptance, i'd love to see it considered for inclusion with python-mode... Ken klm@digicool.com ((*) "whenever you run *pdb*, emacs *tracks*" - that's why i almost called it "zip":->) From thomas@xs4all.net Tue Jul 18 07:16:18 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 08:16:18 +0200 Subject: [Python-Dev] Votes In-Reply-To: <39739295.4AEB5195@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 06:11:17PM -0500 References: <39739295.4AEB5195@prescod.net> Message-ID: <20000718081618.U7340@xs4all.nl> On Mon, Jul 17, 2000 at 06:11:17PM -0500, Paul Prescod wrote: > I'm going to wait for four positive votes or one from Guido before I > take the following action > cd nondist > cvs add sandbox > cd sandbox > cvs add onlinehelp.py > cvs add inspect.py +1. There. You have it ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Moshe Zadka Tue Jul 18 07:31:52 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 18 Jul 2000 09:31:52 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248257113-63674673@hypernet.com> Message-ID: (assume a = [1, 2, 3]) On Mon, 17 Jul 2000, Gordon McMillan wrote: > How about a fourth: zip(a) is the same as zip(a, []) ? Huh??????????????????? > Look at it this way: what should zip(a, pad=None) return? [(1,), (2,), (3,)], of course > Obviously: [(1, None), (2, None), (3, None)] Why? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Moshe Zadka Tue Jul 18 07:56:01 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 18 Jul 2000 09:56:01 +0300 (IDT) Subject: [Python-Dev] Votes In-Reply-To: <39739295.4AEB5195@prescod.net> Message-ID: On Mon, 17 Jul 2000, Paul Prescod wrote: > I'm going to wait for four positive votes or one from Guido before I > take the following action > > cd nondist > cvs add sandbox > cd sandbox > cvs add onlinehelp.py > cvs add inspect.py Here's one -- +1 -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From mal@lemburg.com Tue Jul 18 08:48:04 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 18 Jul 2000 09:48:04 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration References: Message-ID: <39740BB3.C80C7CA8@lemburg.com> Moshe Zadka wrote: > > (assume a = [1, 2, 3]) > > On Mon, 17 Jul 2000, Gordon McMillan wrote: > > > How about a fourth: zip(a) is the same as zip(a, []) ? > > Huh??????????????????? I think he meant: zip((a,[])) > > Look at it this way: what should zip(a, pad=None) return? > > [(1,), (2,), (3,)], of course > > > Obviously: [(1, None), (2, None), (3, None)] > > Why? Good question ;-) Here's another one: why should zip() have this special case at all ? I mean, have you ever seen a zipper with only one part ? Ok, there is one-hand clapping, but I wouldn't consider this the normal mode of operation ;-) IMHO, all the special casing does is mask programming errors. And another one: zip() as defined is an operation which is -- in some respects -- the inverse of itself, yet the name does not carry this information. You can't zip a zipper twice. The mathematical operation behind it is called transposition (you view the sequence of sequences as matrix), so in that light the natural name would be transpose()... tranpose(transpose(matrix))) has the same structure as matrix itself. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" <1248234561-65031149@hypernet.com> Message-ID: <00cd01bff08e$c0849580$f2a6b5d4@hagrid> gordon wrote: > initXXX() (normally) calls Py_InitModule4, so it would be the=20 > one in whatever XXXmodule loaded. exactly my point... so, would this work? =20 Index: Python/modsupport.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/python/python/dist/src/Python/modsupport.c,v retrieving revision 2.48 diff -u -r2.48 modsupport.c --- Python/modsupport.c 2000/07/09 03:09:56 2.48 +++ Python/modsupport.c 2000/07/18 07:55:03 @@ -51,6 +51,8 @@ { PyObject *m, *d, *v; PyMethodDef *ml; + if (!Py_IsInitialized()) + Py_FatalError("Interpreter not initialized (version = mismatch?)"); if (module_api_version !=3D PYTHON_API_VERSION) fprintf(stderr, api_version_warning, name, PYTHON_API_VERSION, name, = module_api_version); "Fatal Python error: Interpreter not initialized" might not be too = helpful, but it's surely better than "PyThreadState_Get: no current thread"... From tim_one@email.msn.com Tue Jul 18 09:00:18 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 18 Jul 2000 04:00:18 -0400 Subject: [Python-Dev] Will Python die? In-Reply-To: <39736268.306B8DF0@schneider-kamp.de> Message-ID: [Peter Schneider-Kamp] > Tim once (0.9-winking-ly) mentioned the possibility of voting with the > "keyboard by grabbing the Python source and making your own release". > > I don't wanna do this on my own (and get zapped from a lightning bolt > thrown by the powers that are), but what would be the pros and cons > of an inofficial (maybe 1.8?) alpha-in-between-release? I don't see any pros at this time, although I'm typing on my laptop while sitting on the sidewalk in the dark in front of a Howard Johnson's with my hair dripping wet, so Guido can sleep in peace in the room we're sharing, and this after a hellish 12-hour trip to get to the God-forsaken State of California, so I'm not seeing many pros of any kind at the moment . The Python Consortium meeting is this Friday, and the license hassles are on the agenda. While not privy to all the details myself, I can't imagine that any side in this debate can afford to *allow* the impasse to continue longer than that. So I'd advise a bit more patience. I intend to stay all up night, listening for secrets Guido may spill in his sleep. the-con-is-making-a-confused-release-even-more-confused-ly y'rs - tim From mal@lemburg.com Tue Jul 18 09:07:24 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 18 Jul 2000 10:07:24 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <003f01bfefc6$64840540$f2a6b5d4@hagrid> <1248234561-65031149@hypernet.com> <00cd01bff08e$c0849580$f2a6b5d4@hagrid> Message-ID: <3974103C.AE2D2320@lemburg.com> Fredrik Lundh wrote: > > gordon wrote: > > initXXX() (normally) calls Py_InitModule4, so it would be the > > one in whatever XXXmodule loaded. > > exactly my point... > > so, would this work? Hmm, as I see it this patch would have to be in 1.5.2 to be of any use for the problem mentioned in the subject line: the 1.5 extension links against python15.dll and thus calls the Py_InitModule() of that DLL, not the one in python20.dll which would have the logic below. Anyway, it's a good start for future versions of Python. > Index: Python/modsupport.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Python/modsupport.c,v > retrieving revision 2.48 > diff -u -r2.48 modsupport.c > --- Python/modsupport.c 2000/07/09 03:09:56 2.48 > +++ Python/modsupport.c 2000/07/18 07:55:03 > @@ -51,6 +51,8 @@ > { > PyObject *m, *d, *v; > PyMethodDef *ml; > + if (!Py_IsInitialized()) > + Py_FatalError("Interpreter not initialized (version mismatch?)"); > if (module_api_version != PYTHON_API_VERSION) > fprintf(stderr, api_version_warning, > name, PYTHON_API_VERSION, name, module_api_version); > > "Fatal Python error: Interpreter not initialized" might not be too helpful, > but it's surely better than "PyThreadState_Get: no current thread"... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Moshe Zadka Tue Jul 18 09:09:59 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 18 Jul 2000 11:09:59 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory In-Reply-To: <14707.54650.959052.870977@anthem.concentric.net> Message-ID: On Mon, 17 Jul 2000, Barry A. Warsaw wrote: > > >>>>> "GS" == Greg Stein writes: > > GS> I'm actively involved with CVS's successor. Does that count? > > GS> :-) > > Only if I get to play with it! Yeah, Greg, what's up with davlib.py? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gstein@lyra.org Tue Jul 18 09:38:25 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 01:38:25 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 18, 2000 at 11:09:59AM +0300 References: <14707.54650.959052.870977@anthem.concentric.net> Message-ID: <20000718013825.F29590@lyra.org> On Tue, Jul 18, 2000 at 11:09:59AM +0300, Moshe Zadka wrote: > On Mon, 17 Jul 2000, Barry A. Warsaw wrote: > > >>>>> "GS" == Greg Stein writes: > > > > GS> I'm actively involved with CVS's successor. Does that count? > > > > GS> :-) > > > > Only if I get to play with it! > > Yeah, Greg, what's up with davlib.py? Euh. What about it? It is moving along fine. I wouldn't call it stable enough for inclusion into the standard distro, though. What is there is fine, but I think more APIs will be needed to pick up stuff from the new/upcoming DAV extension specs. Cheers, -g p.s. http://subversion.tigris.org/ is the CVS successor I'm talking about -- Greg Stein, http://www.lyra.org/ From peter@schneider-kamp.de Tue Jul 18 11:37:25 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 10:37:25 +0000 Subject: [Python-Dev] Will Python die? References: Message-ID: <39743365.73CC983E@schneider-kamp.de> Tim Peters wrote: > > I don't see any pros at this time, although I'm typing on my laptop while > sitting on the sidewalk in the dark in front of a Howard Johnson's with my > hair dripping wet, so Guido can sleep in peace in the room we're sharing, > and this after a hellish 12-hour trip to get to the God-forsaken State of > California, so I'm not seeing many pros of any kind at the moment . > The Python Consortium meeting is this Friday, and the license hassles are on > the agenda. While not privy to all the details myself, I can't imagine that > any side in this debate can afford to *allow* the impasse to continue longer > than that. Okay, that sounds better than nothing. Meanwhile the question "what happened to 1.6?" starts popping up in c.l.py more often. > So I'd advise a bit more patience. I intend to stay all up night, listening > for secrets Guido may spill in his sleep. Be sure to write a secret transcript of *everything*. We might use it the next time we want to add some special syntax to Python being-more-patient-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Moshe Zadka Tue Jul 18 10:02:30 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 18 Jul 2000 12:02:30 +0300 (IDT) Subject: [Python-Dev] Will Python die? In-Reply-To: Message-ID: On Tue, 18 Jul 2000, Tim Peters wrote: > [Peter Schneider-Kamp] > > Tim once (0.9-winking-ly) mentioned the possibility of voting with the > > "keyboard by grabbing the Python source and making your own release". > > > > I don't wanna do this on my own (and get zapped from a lightning bolt > > thrown by the powers that are), but what would be the pros and cons > > of an inofficial (maybe 1.8?) alpha-in-between-release? > > I don't see any pros at this time I agree with Tim -- your 1.8 would face backwards- and forwards- compatabilitiy issues CVS versions do not have to face. >, although I'm typing on my laptop while > sitting on the sidewalk in the dark in front of a Howard Johnson's with my > hair dripping wet, so Guido can sleep in peace in the room we're sharing, > and this after a hellish 12-hour trip to get to the God-forsaken State of > California, so I'm not seeing many pros of any kind at the moment . Sounds like loads of fun....next you should get into the room and wake up Guido. That should be even more fun. > So I'd advise a bit more patience. I intend to stay all up night, listening > for secrets Guido may spill in his sleep. I don't think you should. there-are-some-things-bots-were-not-meant-to-know-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From peter@schneider-kamp.de Tue Jul 18 12:23:38 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 11:23:38 +0000 Subject: [Python-Dev] PEP 201 - Parallel iteration References: Message-ID: <39743E3A.249212D5@schneider-kamp.de> Ken Manheimer wrote: > > Evan Simpson (a colleague here at digicool, who'd be a good addition > to python-dev) noticed that unzip is unnecessary - zip is its own > inverse. Since this is a worthwhile observation, i'll indulge a bit > and present it in evan's terms - particularly noting a different > packaging that i think is pretty cool, as methods on sequences. Yeah, but this is only true if we let zip() be a sequence method (or a function taking a sequence): for x,y in [[1, 2, 3], [4, 5, 6]].zip(): for x,y in zip([[1, 2, 3], [4, 5, 6]]): for x,y in zip([1, 2, 3], [4, 5, 6]): To be fair I'll do second one: a = [1, 2, 3] b = [4, 5, 6] c = [7, 8, 9] for x,y,z in [a, b, c].zip(): for x,y,z in zip([a, b, c]): for x,y,z in zip(a, b, c): I still think the third form is more explicit, but I am +0 on making zip() a sequence method. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From fredrik@pythonware.com Tue Jul 18 10:46:27 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 18 Jul 2000 11:46:27 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <39743E3A.249212D5@schneider-kamp.de> Message-ID: <011701bff09d$0bc5b020$0900a8c0@SPIFF> peter wrote: > I still think the third form is more explicit, but I am > +0 on making zip() a sequence method. Remember the "string join" debate? There is no sequence base class in Python (it's an informal inter- face, not a type), so where would you put that method? As specified, "zip" has a *single* implementation which takes any number of objects implementing the sequence interface, and return an object implementing the same interface. Can it be much simpler? -1 on a method. Python is moving towards more genericness (if you accept an integer/sequence/string, you should be able to deal with any kind of integer/sequence/string). Adding a method would be a move in the opposite direction. From jack@oratrix.nl Tue Jul 18 10:54:26 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 18 Jul 2000 11:54:26 +0200 Subject: [Python-Dev] ascii default encoding In-Reply-To: Message by "Fredrik Lundh" , Mon, 17 Jul 2000 00:35:56 +0200 , <008501bfef76$362902e0$f2a6b5d4@hagrid> Message-ID: <20000718095427.0F3CE37186D@snelboot.oratrix.nl> > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', bu= t = > > the \312 causes problems because it can't be converted from/to unicod= e = > > as long as the default encoding is ascii... > = > on windows and unix boxes, the default locale is "posix" (aka "C"), > which in practice means "plain ascii". the only way to end up with > non-ascii characters in whitespace/uppercase/lowercase/etc is to > explicitly change the locale (by calling locale.setlocale). On the Mac, under CodeWarrior, the default locale (and, actually, the onl= y = locale) is "C", and it uses the mac-roman charset, so including the upper= 128 = characters. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++= Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig = ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.= htm = From thomas@xs4all.net Tue Jul 18 10:59:47 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 11:59:47 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <39743E3A.249212D5@schneider-kamp.de>; from peter@schneider-kamp.de on Tue, Jul 18, 2000 at 11:23:38AM +0000 References: <39743E3A.249212D5@schneider-kamp.de> Message-ID: <20000718115947.Y7340@xs4all.nl> On Tue, Jul 18, 2000 at 11:23:38AM +0000, Peter Schneider-Kamp wrote: > Ken Manheimer wrote: > > Evan Simpson (a colleague here at digicool, who'd be a good addition > > to python-dev) noticed that unzip is unnecessary - zip is its own > > inverse. Since this is a worthwhile observation, i'll indulge a bit > > and present it in evan's terms - particularly noting a different > > packaging that i think is pretty cool, as methods on sequences. > for x,y,z in [a, b, c].zip(): -1. Completely counter-intuitive, in my opinion... It would be nice if having a list of lists to marry() is a common operation, but I doubt it is. Having to create one just for the sake of zip() looks silly to me. > for x,y,z in zip([a, b, c]): -1. What's the point ? What's the difference ? What would 'zip([a,b,c],[d,e,f])' do ? > for x,y,z in zip(a, b, c): Still +0 on this. I still prefer the altered syntax 'for' loop :-) And marry() over zip(). But I can live with this. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Tue Jul 18 11:18:31 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 12:18:31 +0200 Subject: [Python-Dev] PEP 204 - Range Literals Message-ID: <20000718121831.A7340@xs4all.nl> --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii I've attached the first draft of PEP 204, Range Literals, which I just uploaded to CVS as well. If anyone finds time to review it, or the proposed implementation (patch #100902 on SourceForge) please do. I'm not sure what to do with the patch... Guido said as much as 'apply it'(*), but I doubt anyone really looked at it yet ;) I wrote this using 'joe', which is still my favorite editor, because despite many, many minutes of effort, xemacs simply refused to do what I wanted it to do. How do you 're-flow' a paragraph, for instance, or enable word wrapping, or better yet: word wrapping with autoindentation ? If anyone has a quick-and-dirty howto on [x]emacs, feel free to share ;) (* In http://www.python.org/pipermail/python-dev/2000-July/013234.html) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! --2oS5YaxWCcQjTEyO Content-Type: text/plain Content-Disposition: attachment; filename="pep-0204.txt" PEP: 204 Title: Range Literals Version: $Revision: 1.2 $ Owner: thomas@xs4all.net (Thomas Wouters) Python-Version: 2.0 Status: Draft Introduction This PEP describes the `range literal' proposal for Python 2.0. This PEP tracks the status and ownership of this feature, slated for introduction in Python 2.0. It contains a description of the feature and outlines changes necessary to support the feature. This PEP summarizes discussions held in mailing list forums, and provides URLs for further information, where appropriate. The CVS revision history of this file contains the definitive historical record. List ranges Ranges are sequences of numbers of a fixed stepping, often used in for-loops. The Python for-loop is designed to iterate over a sequence directly: >>> l = ['a', 'b', 'c', 'd'] >>> for item in l: ... print item a b c d However, this solution is not always prudent. Firstly, problems arise when altering the sequence in the body of the for-loop, resulting in the for-loop skipping items. Secondly, it is not possible to iterate over, say, every second element of the sequence. And thirdly, it is sometimes necessary to process an element based on its index, which is not readily available in the above construct. For these instances, and others where a range of numbers is desired, Python provides the `range' builtin function, which creates a list of numbers. The `range' function takes three arguments, `start', `end' and `step'. `start' and `step' are optional, and default to 0 and 1, respectively. The `range' function creates a list of numbers, starting at `start', with a step of `step', up to, but not including `end', so that `range(10)' produces a list that has exactly 10 items, the numbers 0 through 9. Using the `range' function, the above example would look like this: >>> for i in range(len(l)): ... print l[i] a b c d Or, to start at the second element of `l' and processing only every second element from then on: >>> for i in range(1, len(l), 2): ... print l[i] b d There are several disadvantages with this approach: - Clarity of purpose: Adding another functioncall, possibly with extra arithmatic to determine the desired length and step of the list, does not improve readability of the code. Also, it is possible to `shadow' the builtin `range' function by supplying a local or global variable with the same name, effectively replacing it. This may or may not be a desired effect. - Efficiency: because the `range' function can be overridden, the Python compiler cannot make assumptions about the for-loop, and has to maintain a seperate loop counter. - Consistency: There already is a syntax that is used to denote ranges, as shown below. This syntax uses the exact same arguments, though all optional, in the exact same way. It seems logical to extend this syntax to ranges, to form `range literals'. Slice Indices In Python, a sequence can be indexed in one of two ways: retrieving a single item, or retrieving a range of items. Retrieving a range of items results in a new object of the same type as the original sequence, containing zero or more items from the original sequence. This is done using a `range notation': >>> l[2:4] ['c', 'd'] This range notation consists of zero, one or two indices seperated by a colon. The first index is the `start' index, the second the `end'. When either is left out, they default to respectively the start and the end of the sequence. There is also an extended range notation, which incorporates `step' as well. Though this notation is not currently supported by most builtin types, if it were, it would work as follows: >>> l[1:4:2] ['b', 'd'] The third `argument' to the slice syntax is exactly the same as the `step' argument to range(). The underlying mechanisms of standard and these extended slices are sufficiently different and inconsistent that many classes and extensions outside of mathematical packages do not implement support for the extended variant, and this should definately be resolved, but this is beyond the scope of this PEP. Extended slices do show, however, that there is already a perfectly valid and applicable syntax to denote ranges in a way that solve all of the earlier stated disadvantages of the use of the range() function: - It is clearer, more concise syntax, which has already proven to be both intuitive and easy to learn. - It is consistent with the other use of ranges in Python (slices.) - Because it is built-in syntax, instead of a builtin function, it cannot be overridden. This means both that a viewer can be certain about what the code does, and that an optimizer will not have to worry about range() being `shadowed'. The Proposed Solution The proposed implementation of range-literals combines the syntax for list literals with the syntax for (extended) slices, to form range literals: >>> [1:10] [1, 2, 3, 4, 5, 6, 7, 8, 9] >>> [:5] [0, 1, 2, 3, 4] >>> [5:1:-1] [5, 4, 3, 2] There is one minor difference between range literals and the slice syntax: though it is possible to omit all of `start', `end' and `step' in slices, it does not make sense to omit `end' in range literals. In slices, `end' would default to the end of the list, but this has no meaning in range literals. Reference Implementation The proposed implementation can be found on SourceForge[1]. It adds a new bytecode, BUILD_RANGE, that takes three arguments from the stack and builds a list on the bases of those. The list is pushed back on the stack. The use of a new bytecode is necessary to be able to build ranges based on other calculations, whose outcome is not known at compile time. The code introduces two new functions to listobject.c, which are currently hovering between private functions and full-fledged API calls. PyObject * PyList_FromRange(long start, long end, long step) builds a list from start, end and step, returning NULL if an error occurs. long PyList_GetLenOfRange(long start, long end, long step) is a helper function to determine the length of a range. It was previously a static function in bltinmodule.c, but is now necessary in both listobject.c and bltinmodule.c (for xrange). It is made non-static solely to avoid code duplication. Open issues One possible solution to the discrepancy of requiring the `end' argument in range literals is to allow the range syntax to create a `generator', rather than a list, such as the `xrange' builtin function does. However, a generator would not be a list, and it would be impossible, for instance, to assign to items in the generator, or append to it. The range syntax could conceivably be extended to include tuples, immutable lists, which could then be safely implemented as generators. Especially for large number arrays, this may be a desirable solution: generators require very little in the way of storage and initialization, and there is only a small performance impact in calculating and creating the appropriate number on request. (TBD: is there any at all ? Cursory testing suggests equal performance even in the case of ranges of length 1.) However, even if idea was adopted, would it be wise to `special case' the second argument, making it optional in one instance of the syntax, and non-optional in other cases ? Should it be possible to mix range syntax with normal list literals, creating a single list, like so: >>> [5, 6, 1:6, 7, 9] to create [5, 6, 1, 2, 3, 4, 5, 7, 9] How should range literals interact with another proposed new feature, `list comprehensions', PEP-202 ? In specific, should it be possible to create lists in list comprehensions, like so: >>> [x:y for x in (1,2) y in (3, 4)] Should this example return a single list with multiple ranges: [1, 2, 1, 2, 3, 2, 2, 3] Or a list of lists, like so: [[1, 2], [1, 2, 3], [2], [2, 3]] However, as the syntax and semantics of list comprehensions are still subject of hot debate, these issues are probably best addressed by the `list comprehensions' PEP. Range literals accept objects other than integers: it performs PyInt_AsLong() on the objects passed in, so as long as the objects can be coerced into integers, they will be accepted. The resulting list, however, is always composed of standard integers. Should range literals create a list of the passed-in type ? It might be desirable in the cases of other builtin types, such as longs and strings: >>> [ 1L : 2L<<64 : 2<<32L ] >>> ["a":"z":"b"] >>> ["a":"z":2] However, this might be too much `magic' to be obvious. It might also present problems with user-defined classes: even if the base class can be found and a new instance created, the instance may require additional arguments to __init__, causing the creation to fail. The PyList_FromRange() and PyList_GetLenOfRange() functions need to be classified: are they part of the API, or should they be made private functions ? References: [1] http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 Local Variables: mode: indented-text indent-tabs-mode: nil End: --2oS5YaxWCcQjTEyO-- From fredrik@pythonware.com Tue Jul 18 11:21:54 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 18 Jul 2000 12:21:54 +0200 Subject: [Python-Dev] ascii default encoding References: <20000718095427.0F3CE37186D@snelboot.oratrix.nl> Message-ID: <013501bff0a1$ff35cca0$0900a8c0@SPIFF> jack wrote: > On the Mac, under CodeWarrior, the default locale (and, actually, the only > locale) is "C", and it uses the mac-roman charset, so including the upper 128 > characters. I could have sworn that the "C" locale only included characters in the ASCII range [1], but a more careful reading of the specification indicates that the behaviour is only *defined* for characters in the ASCII range... two alternatives: -- limit the string constants to the portable range (0..127). if you want more characters, you have to explicitly call locale.setlocale(..., "C"). -- leave it as it is. this means that code that does things like "if char in string.whitespace" will break if char is unicode, and you're running on a mac. on second thought, it's probably better to just fix mixed string com- parisions... (so that instead of throwing an exception, unichr(202) will simply be != chr(202)...) 1) not quite true: the portable character set only lists all characters in the ASCII character set, it doesn't define what code points they should use. From thomas@xs4all.net Tue Jul 18 12:00:59 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 13:00:59 +0200 Subject: [Python-Dev] Patches Message-ID: <20000718130059.B7340@xs4all.nl> Now that everyone of importance is off to sunny California, how about we put some of the patches that have been idling on the SF PM to the vote ? If Barry objects we can always organize some gigs for him away from the 'office' ;) I'd personally like to hear some votes/opinions on the range literal patch, but it seems to me there are others that only require some voting and second opinions: - Add 'isatty(fd)' to posixmodule. Do Macs and Windows machines have an isatty() function that makes sense to include ? - Better error message with UnboundLocalError Patch looks okay to me, and Tim already said he liked the idea. - arraymodule: adding count, extend, index, pop, remove I believe there was some discussion about this before, don't know the outcome. - new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Probably needs Guido and/or Tim decreeing whether the change is worth it - safe version of PyErr_Format +0 on that, but what do I know. Don't know if it's actually safe ;) - Optional pad character for rjust, ljust Definately +1, but I have a nagging feeling there is a better way to do it: Why wasn't this implemented before ? What are people using instead of string.rjust(string, padchar) ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm@hypernet.com Tue Jul 18 13:26:02 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 18 Jul 2000 08:26:02 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <39740BB3.C80C7CA8@lemburg.com> Message-ID: <1248199317-67151042@hypernet.com> M.-A. Lemburg wrote: > Moshe Zadka wrote: > > > > (assume a = [1, 2, 3]) > > > > On Mon, 17 Jul 2000, Gordon McMillan wrote: > > > > > How about a fourth: zip(a) is the same as zip(a, []) ? > > > > Huh??????????????????? > > I think he meant: zip((a,[])) No I didn't. Sigh. >>pad([1,2,3], [1], pad=None) [(1,1), (2,None), (3,None)] >>pad([1,2,3], [], pad=None) [(1,None), (2,None), (3,None)] (If you don't agree with that, you don't agree with the PEP). So I'm proposing that the 2nd positional arg, if not present, be treated as []. That makes: >>zip([1,2,3], pad=None) [(1,None), (2,None), (3,None) >>zip([1,2,3]) [] The other possibility is to make Evan Simpson's dream come true, so >>zip([(1,None), (2,None), (3,None)]) [[1,2,3],[None,None,None]] But then you'd have to throw an exception if the (single) arg wasn't a rectangular sequence of sequences. Also, since lately Guido's on a kick to get rid of auto-tupling/untupling of args, I think you need to use apply(zip, tuple(...)) or the *args syntax to accomplish this. > Here's another one: why should zip() have this special case > at all ? I mean, have you ever seen a zipper with only one > part ? Ok, there is one-hand clapping, but I wouldn't consider > this the normal mode of operation ;-) IMHO, all the special > casing does is mask programming errors. Which doesn't answer the question posed in the PEP. All of the proposed responses are special cases. The one I've seen mentioned most often: >>zip([1,2,3]) [(1,),(2,),(3,)] is very much as special case, as you can see if you ask "what happens when I add a pad arg?". However, if the dev list is having so much trouble deciding how it should decay, I'll vote for throwing an exception. > And another one: zip() as defined is an operation which is -- in > some respects -- the inverse of itself, yet the name does not > carry this information. You can't zip a zipper twice. The > mathematical operation behind it is called transposition (you > view the sequence of sequences as matrix), so in that light the > natural name would be transpose()... tranpose(transpose(matrix))) > has the same structure as matrix itself. But zip takes some number of sequences, not necessarily of the same length. That's not a matrix. I think if you go that route, the user has to first insure they're all the same length and then package them into a sequence. It might have its uses, but not as a replacement for map(None, ...). - Gordon From gmcm@hypernet.com Tue Jul 18 13:26:02 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 18 Jul 2000 08:26:02 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: References: <1248257113-63674673@hypernet.com> Message-ID: <1248199315-67151142@hypernet.com> Moshe Zadka wrote: > (assume a = [1, 2, 3]) > > On Mon, 17 Jul 2000, Gordon McMillan wrote: > > > How about a fourth: zip(a) is the same as zip(a, []) ? > > Huh??????????????????? > > > Look at it this way: what should zip(a, pad=None) return? > > [(1,), (2,), (3,)], of course Then why does the PEP say: >>> zip(a, b, c, d, pad=None) [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)] >>> map(None, a, b, c, d) [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)] If you want no padding, you don't specify a pad arg. pad=None means "pad with None". > > Obviously: [(1, None), (2, None), (3, None)] > > Why? To be consistent. - Gordon From Moshe Zadka Tue Jul 18 14:18:03 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 18 Jul 2000 16:18:03 +0300 (IDT) Subject: [Python-Dev] Patches In-Reply-To: <20000718130059.B7340@xs4all.nl> Message-ID: On Tue, 18 Jul 2000, Thomas Wouters wrote: > Now that everyone of importance is off to sunny California, how about we put > some of the patches that have been idling on the SF PM to the vote ? If > Barry objects we can always organize some gigs for him away from the > 'office' ;) Or we can unleash Gordon upon him...seems to be the only thing which strikes terror into his heart (after meeting Gordon, I can understand why) > I'd personally like to hear some votes/opinions on the range literal patch, Didn't Guido urge you to check it in? > - Add 'isatty(fd)' to posixmodule. +1 on that > - Better error message with UnboundLocalError > Patch looks okay to me, and Tim already said he liked the idea. But it seems he had a quibble with the style -- so it's better to wait until he approves. I think we *should* assign it to him, and bug him about it. Any other opinions? > - arraymodule: adding count, extend, index, pop, remove > I believe there was some discussion about this before, don't know the > outcome. I'm +1, but I remember Tim and Guido had something to say about it, so it's safest to wait for them > - new EXTENDED_ARG opcode, elimiate 16-bit oparg limit > Probably needs Guido and/or Tim decreeing whether the change is worth it Agreed > - safe version of PyErr_Format > +0 on that, but what do I know. Don't know if it's actually safe ;) I'm +1. As far as I could read, it is safe. That's the safest we can get without serious stress-tests. This, again, brings up the problem of regression testing for APIs, which is a different topic. (Anyone wants to PEP it?) > - Optional pad character for rjust, ljust > Definately +1, but I have a nagging feeling there is a better way to do it: > Why wasn't this implemented before ? What are people using instead of > string.rjust(string, padchar) ? Probably hand calculations: l = len(s) return s+'p'*(just-l) It's possible.... In fact, putting an implementation of pad() like that in the string.py module would be wonderful, because it would work with both regular strings and unicode. However, string.py is looking as though as it's going to be deprecated. In short, I'd want Guido/Tim/effbot/MAL opinions here before we make a move. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From peter@schneider-kamp.de Tue Jul 18 15:21:59 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 14:21:59 +0000 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> Message-ID: <39746807.DFA2B329@schneider-kamp.de> Thomas Wouters wrote: > > Now that everyone of importance is off to sunny California, how about we put > some of the patches that have been idling on the SF PM to the vote ? If > Barry objects we can always organize some gigs for him away from the > 'office' ;) I am +0 on voting. I don't like the silence on the checkins mailing list. > I'd personally like to hear some votes/opinions on the range literal patch, > but it seems to me there are others that only require some voting and second > opinions: Wasn't there a decision from the BDFL? > - arraymodule: adding count, extend, index, pop, remove > I believe there was some discussion about this before, don't know the > outcome. Guido said something like (hope I got it right): count, index and remove should be implemented in a faster way, but that would take a lot more code and not be worth it. who would use index, count and remove on arrays anyway? so better leave them out, pop is okay though. extend would be worth adding. Tim said something like (hope I got this one right, too): better to have count, index and remove at all than not to have them. I would use them. I interpret that as a -0 from Guido and a +1 from Tim, but - as always - YMMV. My opinion is that an array is only really useful if it supports as much of the list interface as possible. As I understand things arrays are lists where you trade the ability to store any element against some increase in speed. For the slow count, index and remove functions I have three proposals (in order of decreasing appeal to me): 1) just put em in, they are in any case not slower than the Python code you would use to emulate them. +1 2) put them in and add some warnings to the docs that say they are slow. +0 3) do it the fast way. that would be a lot of work and - as Guido pointed out - probably not worth it. I'd do it if it was neccessary though. -0 > - safe version of PyErr_Format > +0 on that, but what do I know. Don't know if it's actually safe ;) -0 on that, I'd rather use snprintf when available, sprintf when not. > - Optional pad character for rjust, ljust > Definately +1, but I have a nagging feeling there is a better way to do it: > Why wasn't this implemented before ? What are people using instead of > string.rjust(string, padchar) ? +1 in any case, but I think we should wait for the new version which supports padstrings, too. also I think there is still no docs/test cases. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Moshe Zadka Tue Jul 18 13:34:38 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 18 Jul 2000 15:34:38 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248199315-67151142@hypernet.com> Message-ID: On Tue, 18 Jul 2000, Gordon McMillan wrote: [about zip(a, pad=None) ] > > > Obviously: [(1, None), (2, None), (3, None)] > > > > Why? > > To be consistent. But when there is only one list, all lists are of the same size, so the pad argument is moot. (Consistent with all other cases where all lists are the same size) Or maybe we're talking about a different situation? Can you show a fake Python session which demonstrates your point? confused-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas@xs4all.net Tue Jul 18 14:33:48 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 15:33:48 +0200 Subject: [Python-Dev] Patches In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 18, 2000 at 04:18:03PM +0300 References: <20000718130059.B7340@xs4all.nl> Message-ID: <20000718153348.B7345@xs4all.nl> On Tue, Jul 18, 2000 at 04:18:03PM +0300, Moshe Zadka wrote: > On Tue, 18 Jul 2000, Thomas Wouters wrote: > > I'd personally like to hear some votes/opinions on the range literal patch, > Didn't Guido urge you to check it in? I have *no* idea :) The 'Right!' seemed to imply that, but I doubt he'd let me check it in without *someone* reviewing it ;) > > - Better error message with UnboundLocalError > > Patch looks okay to me, and Tim already said he liked the idea. > But it seems he had a quibble with the style -- so it's better to wait > until he approves. I think we *should* assign it to him, and bug him > about it. Any other opinions? The style issue is history. The new version is style-conforming, I think, asside from a small bug in the definition of the helper function (see the comment, Paul ;) That doesn't mean Tim shouldn't check it first, though. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Moshe Zadka Tue Jul 18 14:44:01 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 18 Jul 2000 16:44:01 +0300 (IDT) Subject: [Python-Dev] posixpath.normpath Message-ID: Simple question: what should a) posixpath.normpath("..") b) posixpath.normpath("/..") return? Anyone? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From peter@schneider-kamp.de Tue Jul 18 16:44:04 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 15:44:04 +0000 Subject: [Python-Dev] Will Python die? References: Message-ID: <39747B44.4284A38B@schneider-kamp.de> Moshe Zadka wrote: > > I agree with Tim -- your 1.8 would face backwards- and forwards- > compatabilitiy issues CVS versions do not have to face. I basically agree. An official release would be a Bad Thing(TM). But at least some information should leak to the masses to prevent slashdot threads like that: http://slashdot.org/comments.pl?sid=00/07/17/0312221&threshold=-1&commentsort=0&mode=flat&cid=41 Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Moshe Zadka Tue Jul 18 14:46:07 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 18 Jul 2000 16:46:07 +0300 (IDT) Subject: [Python-Dev] Will Python die? In-Reply-To: <39747B44.4284A38B@schneider-kamp.de> Message-ID: On Tue, 18 Jul 2000, Peter Schneider-Kamp wrote: > But at least some information should leak to the masses to prevent > slashdot threads like that: > > http://slashdot.org/comments.pl?sid=00/07/17/0312221&threshold=-1&commentsort=0&mode=flat&cid=41 My fault -- I stopped reading /. Can you summarize the thread? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From peter@schneider-kamp.de Tue Jul 18 17:06:37 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 16:06:37 +0000 Subject: [Python-Dev] Will Python die? References: Message-ID: <3974808D.5D49575D@schneider-kamp.de> Moshe Zadka wrote: > > My fault -- I stopped reading /. Can you summarize the thread? The thread is about if Visual Python is an alternative for Visual Basic or, if not, it can be used as that. A subthread of this thread dealt with Pythons release schedule: "Speaking of Python, does anyone know what's up with Python 1.6^H^H2.0? A while back, python.org had said that version 1.6 would be out on June 1. Then there was an announcement, mid-June that it would be delayed. Then at the end of June, this link was placed on python.org, and it was stated that the Python interpreter, version 1.6, was renamed to 2.0, and the first beta would be available on July 1. Now, on July 17, that link has been removed from python.org (although the webpage still exists), and the release schedule is gone!" Quoting from relevant replies: "python 1.6 will be out in august check the downloads page of www.python.org or checkout the pythonlabs at www.beopen.com where most of the core python developers opened shop" "Yeah, the Python 1.6 download page says that Python 1.6 beta1 will be done on July 1, and beta 2 on July 14. It's July 17 now, and the only available download is alpha 2...." read-what-you-want-from-that-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gvwilson@nevex.com Tue Jul 18 15:11:30 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 18 Jul 2000 10:11:30 -0400 (EDT) Subject: [Python-Dev] Re: PEP 201 - Parallel iteration In-Reply-To: <200007172015.WAA25033@python.inrialpes.fr> Message-ID: I realize it's late in the day, but could the name of the concept (not the function) be changed from "parallel iteration" to something that doesn't imply concurrent execution quite so strongly? I think the use of "parallel" is very likely to mislead, particularly scientists and engineers who actually have parallel loops in their jumped-up Fortran and C++ systems. Thanks, Greg From akuchlin@mems-exchange.org Tue Jul 18 15:13:21 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 18 Jul 2000 10:13:21 -0400 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: ; from pingster@ilm.com on Mon, Jul 17, 2000 at 07:37:08PM -0700 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: <20000718101321.D21354@newcnri.cnri.reston.va.us> Thanks to everyone who made some suggestions. The more minor edits have been made, but I haven't added any of the threads I missed because doing a long stretch of Emacs editing in this lame Windows terminal program will drive me insane, so I just posted the summary to python-list. How is it possible for Microsoft to not get a VT100-compatible terminal program working correctly? VT100s have been around since, when, the 1970s? Can anyone suggest a Windows terminal program that *doesn't* suck dead bunnies through a straw? --amk From skip@mojam.com (Skip Montanaro) Tue Jul 18 15:18:31 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 18 Jul 2000 09:18:31 -0500 (CDT) Subject: [Python-Dev] Patches In-Reply-To: <20000718130059.B7340@xs4all.nl> References: <20000718130059.B7340@xs4all.nl> Message-ID: <14708.26423.536040.581684@beluga.mojam.com> Thomas> Now that everyone of importance is off to sunny California, how Thomas> about we put some of the patches that have been idling on the SF Thomas> PM to the vote ? As someone who has been assigned some patches that are still open (isatty, normpath fix, history functions for readline), I'm still pretty much in the dark about what my rights and responsibilities are. Am I supposed to eyeball a patch and check it in if it looks okay (compiles, doesn't break "make test", etc)? Am I supposed to bring it up for discussion on python-dev? Something entirely different (blow up a bush, perhaps)? I just submitted a feature request for the patch manager at SF. I asked for the following: 1. better selection/exclusion predicates for the filtering function 2. filtering based on assignee/submitter 3. display of a patch's state in the table If you'd like to review it and add your own two cents, it's at https://sourceforge.net/forum/message.php?msg_id=41288 Skip From gvwilson@nevex.com Tue Jul 18 15:36:02 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 18 Jul 2000 10:36:02 -0400 (EDT) Subject: [Python-Dev] CVS / Subversion / language choice In-Reply-To: <3973A510.86D2AF54@prescod.net> Message-ID: > > Welcome to CVS. What did Greg Wilson say at IPC8? Paraphrasing: CVS > > is the worst tool everybody uses. :) "CVS is the suckiest tool that developers have to use on a daily basis." (It was actually one of my students at Los Alamos --- and it was one of the few times there's been a round of applause in a class I've taught :-). BTW, if you haven't seen Subversion: http://subversion.tigris.org It's worth checking out (if only to see what's keeping Greg Stein off the streets and out of trouble). The project's aim is to produce a "better CVS", i.e. fix some of the known warts, and web-enable it using WebDAV. I like their goals (fairly conservative, but therefore also fairly likely to be accepted), and their use of ASCII art in PDFs :-). The thing that surprised me was their decision to do their first implementation in C, rather than getting something together quickly in a scripting language, and then re-writing modules for performance when/as necessary. I asked Brian Behlendorf about this; he said the reasons were: > ...we're focusing on C in the short run is to take away any religious > wars concerning python vs java vs perl - C, as crappy as it is, is > still a pretty neutral language when it comes to deployment, as > everyone has a C compiler but not everyone wants to install python. > Also, the server side will mostly consist of an Apache plugin and a > driver for the actual database format, so keeping it all in C and all > in the same process is attractive. > > Also, the developers I've got working on it are very comfortable in C, > and I'm trusting that they considered it and elected to just write in > C directly. These were pretty much the same reasons Larry McVoy gave me when I asked him why BitKeeper was using C rather than a scripting language. I'd be interested in knowing whether this attitude is still the norm, or whether there is evidence of a general shift toward the prototyping/filling-in model. I have a progress report to write for Software Carpentry, and... (In the interests of conserving bandwidth, please reply directly; I'll summarize and re-post if there's sufficient interest.) Thanks, Greg From thomas@xs4all.net Tue Jul 18 15:42:24 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 16:42:24 +0200 Subject: [Python-Dev] Patches In-Reply-To: <14708.26423.536040.581684@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 18, 2000 at 09:18:31AM -0500 References: <20000718130059.B7340@xs4all.nl> <14708.26423.536040.581684@beluga.mojam.com> Message-ID: <20000718164224.D7345@xs4all.nl> On Tue, Jul 18, 2000 at 09:18:31AM -0500, Skip Montanaro wrote: > Thomas> Now that everyone of importance is off to sunny California, how > Thomas> about we put some of the patches that have been idling on the SF > Thomas> PM to the vote ? > As someone who has been assigned some patches that are still open (isatty, > normpath fix, history functions for readline), Don't forget: you can assign them to someone else if you feel you have too much, or if you aren't the right person, or just don't feel like dealing with that patch. > I'm still pretty much in the dark about what my rights and > responsibilities are. Am I supposed to eyeball a patch and check it in if > it looks okay (compiles, doesn't break "make test", etc)? Yes, at the least. Also whether it complies to coding style, includes a test (when necessary), etc. > Am I supposed to bring it up for discussion on > python-dev? Possibly. I donno. That used to be done on patches, I gather, but that list is kind of defunct, now. That's partly why I wrote the first posting in this thread, to bring some of those patches to attention. I don't think you're intended to be the Guardian Angel of those patches, though, just the one checking them out. If you aren't sure, post here (or patches@python.org), I guess. If you can't figure out what to do, assign it to Tim. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From esr@thyrsus.com Tue Jul 18 17:36:31 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Tue, 18 Jul 2000 12:36:31 -0400 Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <20000718171739.F7345@xs4all.nl> References: <20000718121831.A7340@xs4all.nl> <20000718110823.B10480@thyrsus.com> <20000718171739.F7345@xs4all.nl> Message-ID: <20000718123631.B10741@thyrsus.com> Thomas Wouters : > Well, I guess I agree. The above was just a bit of 'Red Red Wine' induced > brainstorm, but on reflection it does seem logical. The one-dimensionality > of range and xrange always bothered me ;) The biggest problem is, however, > how to create a 'range' of a specific type of object, given a start, step > and end object. A new PyNumberMethods member 'int_range' ? Or some kind of > 'newobject_fromnumber' protocol ? Let's worry about that later. For now, throwing an exception is OK. > How about we checkin the current patch, which does what the PEP describes, > and continue the PEP for the sake of these issues ? :) +1. -- Eric S. Raymond If I were to select a jack-booted group of fascists who are perhaps as large a danger to American society as I could pick today, I would pick BATF [the Bureau of Alcohol, Tobacco, and Firearms]. -- U.S. Representative John Dingell, 1980 From skip@mojam.com (Skip Montanaro) Tue Jul 18 19:55:01 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 18 Jul 2000 13:55:01 -0500 (CDT) Subject: [Python-Dev] what happened with the python-list addresses? Message-ID: <14708.43013.274067.569324@beluga.mojam.com> I don't want to create a storm on c.l.py, so I post here. I noticed a bunch of "email addresses" that look like "aahz@netcom.com.bbs@openbazaar.net" in recent digests. Is there some sort of runaway gateway? Who is openbazaar.net? Sounds like something ESR would be involved with, though I can't reach an obvious web site in that domain and they appear to be located in Taiwan. Skip From skip@mojam.com (Skip Montanaro) Tue Jul 18 15:19:51 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 18 Jul 2000 09:19:51 -0500 (CDT) Subject: [Python-Dev] Patches In-Reply-To: <20000718130059.B7340@xs4all.nl> References: <20000718130059.B7340@xs4all.nl> Message-ID: <14708.26503.552322.616643@beluga.mojam.com> Thomas> - Optional pad character for rjust, ljust Thomas> Definately +1, but I have a nagging feeling there is a better Thomas> way to do it: Why wasn't this implemented before ? What are Thomas> people using instead of string.rjust(string, padchar) ? Perhaps it's just obscure (to me). I don't believe I've ever used [lr]just. Skip From esr@thyrsus.com Tue Jul 18 16:08:23 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Tue, 18 Jul 2000 11:08:23 -0400 Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <20000718121831.A7340@xs4all.nl> References: <20000718121831.A7340@xs4all.nl> Message-ID: <20000718110823.B10480@thyrsus.com> Thomas Wouters : > I wrote this using 'joe', which is still my favorite editor, because despite > many, many minutes of effort, xemacs simply refused to do what I wanted it > to do. How do you 're-flow' a paragraph, Esc-g > for instance, or enable word > wrapping, or better yet: word wrapping with autoindentation ? Esc-x set-variable auto-fill 1 To always enable it in text mode, add (setq text-mode-hook '(lambda () (auto-fill-mode 1))) to your .emacs file. Emacs will detect your indent level and honor it. > One possible solution to the discrepancy of requiring the `end' > argument in range literals is to allow the range syntax to create > a `generator', rather than a list, such as the `xrange' builtin > function does. However, a generator would not be a list, and it > would be impossible, for instance, to assign to items in the > generator, or append to it. Not so. Appending to the generator object, or assigning to it, would simply force eager rather than lazy evaluation of the generator. This would have to throw an exception on infinite generators. But all this is academic until Python has continuations, really. For finite cases eager vs. lazy only makes a difference in the timing of computations, not their result. While this could be semantically significant for some list comprehensions, it won't be for range literals. (You might want to go look at Haskell or Icon to learn more about how lazy and eager evaluation interact.) > Should it be possible to mix range syntax with normal list > literals, creating a single list, like so: > > >>> [5, 6, 1:6, 7, 9] > to create > [5, 6, 1, 2, 3, 4, 5, 7, 9] I'm completely neutral on this. > However, as the syntax and semantics of list comprehensions are > still subject of hot debate, these issues are probably best > addressed by the `list comprehensions' PEP. Agreed. > Range literals accept objects other than integers: it performs > PyInt_AsLong() on the objects passed in, so as long as the objects > can be coerced into integers, they will be accepted. The > resulting list, however, is always composed of standard integers. > > Should range literals create a list of the passed-in type ? It > might be desirable in the cases of other builtin types, such as > longs and strings: > > >>> [ 1L : 2L<<64 : 2<<32L ] > >>> ["a":"z":"b"] > >>> ["a":"z":2] > > However, this might be too much `magic' to be obvious. It might > also present problems with user-defined classes: even if the base > class can be found and a new instance created, the instance may > require additional arguments to __init__, causing the creation to > fail. +1. Whenever possible, builtins ought to do something intuitive with any type that is passed in, and range literals have an obvious and intuitive definition for any well-ordered base type. I think it would be more surprising if this did *not* work for well-ordered scalar types. I don't view the issue for user-defined classes as a showstopper; it would be OK, and semantically reasonable, to throw an exception in this case. > The PyList_FromRange() and PyList_GetLenOfRange() functions need > to be classified: are they part of the API, or should they be made > private functions ? No opinion. -- Eric S. Raymond ...the Federal Judiciary...an irresponsible body, working like gravity by night and by day, gaining a little today and a little tomorrow, and advancing its noiseless step like a thief over the field of jurisdiction until all shall be usurped from the States; and the government of all be consolidated into one. From esr@thyrsus.com Tue Jul 18 16:11:57 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Tue, 18 Jul 2000 11:11:57 -0400 Subject: [Python-Dev] Patches In-Reply-To: <20000718130059.B7340@xs4all.nl> References: <20000718130059.B7340@xs4all.nl> Message-ID: <20000718111157.C10480@thyrsus.com> Thomas Wouters : > I'd personally like to hear some votes/opinions on the range literal patch, > but it seems to me there are others that only require some voting and second > opinions: I just posted a detailed response on that. > - Add 'isatty(fd)' to posixmodule. > Do Macs and Windows machines have an isatty() function that makes sense to > include ? Unknown to me. I'm +1 on adding this anyway. > - Better error message with UnboundLocalError > Patch looks okay to me, and Tim already said he liked the idea. +0. > - arraymodule: adding count, extend, index, pop, remove > I believe there was some discussion about this before, don't know the > outcome. Is there a PEP? I suspect from looking at the names that I would be +0 on this, but I wonder why pop() and no push()? > - new EXTENDED_ARG opcode, elimiate 16-bit oparg limit > Probably needs Guido and/or Tim decreeing whether the change is worth it > > - safe version of PyErr_Format > +0 on that, but what do I know. Don't know if it's actually safe ;) > > - Optional pad character for rjust, ljust > Definately +1, but I have a nagging feeling there is a better way to do it: > Why wasn't this implemented before ? What are people using instead of > string.rjust(string, padchar) ? No opinion on these. -- Eric S. Raymond He that would make his own liberty secure must guard even his enemy from oppression: for if he violates this duty, he establishes a precedent that will reach unto himself. -- Thomas Paine From thomas@xs4all.net Tue Jul 18 15:59:46 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 16:59:46 +0200 Subject: [Python-Dev] Patches In-Reply-To: <20000718111157.C10480@thyrsus.com>; from esr@thyrsus.com on Tue, Jul 18, 2000 at 11:11:57AM -0400 References: <20000718130059.B7340@xs4all.nl> <20000718111157.C10480@thyrsus.com> Message-ID: <20000718165945.E7345@xs4all.nl> On Tue, Jul 18, 2000 at 11:11:57AM -0400, esr@thyrsus.com wrote: > > - arraymodule: adding count, extend, index, pop, remove > > I believe there was some discussion about this before, don't know the > > outcome. > > Is there a PEP? I suspect from looking at the names that I would > be +0 on this, but I wonder why pop() and no push()? No PEP, it's pre-PEP. The methods names are not in question, because they mirror the current *list* method names ;) and push() is spelled 'append()' in Python. Here's what pop() does: >>> x = [1,2,3,4,5] >>> x.pop() 5 >>> x [1, 2, 3, 4] The question is mostly whether count(), index() and maybe remove() are worth adding to the arrayobject, given their inefficient implementation. (An efficient implementation would require a fair bit of code, but on the plus side, that same code could then be used for 'sq_contains', which currently is appallingly inefficient.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Moshe Zadka Tue Jul 18 17:00:31 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 18 Jul 2000 19:00:31 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248199317-67151042@hypernet.com> Message-ID: On Tue, 18 Jul 2000, Gordon McMillan wrote: > (If you don't agree with that, you don't agree with the PEP). I agree with that. Luckily, I've snipped it, so it's not valid as evidence > So I'm proposing that the 2nd positional arg, if not present, be > treated as []. That makes: That's a special case! > Which doesn't answer the question posed in the PEP. All of > the proposed responses are special cases. The one I've seen > mentioned most often: > >>zip([1,2,3]) > [(1,),(2,),(3,)] > is very much as special case, as you can see if you ask > "what happens when I add a pad arg?". I disagree: you agree that if you add a pad argument when the lists are all the same size it doesn't matter (if you don't agree with this, you don't agree with the PEP). Now, when there is only one list, the lists are all the same size. QED. > However, if the dev list is having so much trouble deciding how > it should decay, I'll vote for throwing an exception. I'm starting to agree -- I'm thinking like a mathematician, which not everyone in the world are (sadly) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas@xs4all.net Tue Jul 18 16:17:39 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 17:17:39 +0200 Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <20000718110823.B10480@thyrsus.com>; from esr@thyrsus.com on Tue, Jul 18, 2000 at 11:08:23AM -0400 References: <20000718121831.A7340@xs4all.nl> <20000718110823.B10480@thyrsus.com> Message-ID: <20000718171739.F7345@xs4all.nl> On Tue, Jul 18, 2000 at 11:08:23AM -0400, esr@thyrsus.com wrote: > Thomas Wouters : > > One possible solution to the discrepancy of requiring the `end' > > argument in range literals is to allow the range syntax to create > > a `generator', rather than a list, such as the `xrange' builtin > > function does. However, a generator would not be a list, and it > > would be impossible, for instance, to assign to items in the > > generator, or append to it. > Not so. Appending to the generator object, or assigning to it, would > simply force eager rather than lazy evaluation of the generator. This > would have to throw an exception on infinite generators. > (You might want to go look at Haskell or Icon to learn more about > how lazy and eager evaluation interact.) Well, I had an xrange() like generator in mind. There currently isn't a very good way for a generator to turn itself into a list, unless it's some kind of polymorphic object that behaves one way until it gets assigned to... In which case I wouldn't want to meet it in a dark alley, alone, at night, without my language reference printout. I don't have the human resources to do an in-depth study of generators (or other languages) right now. The idiots I have to cooperate with at work (from our parent company) are sucking all life out of me, in a bad way ;P > > Should range literals create a list of the passed-in type ? It > > might be desirable in the cases of other builtin types, such as > > longs and strings: [..] > > However, this might be too much `magic' to be obvious. It might > > also present problems with user-defined classes: even if the base > > class can be found and a new instance created, the instance may > > require additional arguments to __init__, causing the creation to > > fail. > +1. Whenever possible, builtins ought to do something intuitive with > any type that is passed in, and range literals have an obvious and > intuitive definition for any well-ordered base type. I think it > would be more surprising if this did *not* work for well-ordered > scalar types. Well, I guess I agree. The above was just a bit of 'Red Red Wine' induced brainstorm, but on reflection it does seem logical. The one-dimensionality of range and xrange always bothered me ;) The biggest problem is, however, how to create a 'range' of a specific type of object, given a start, step and end object. A new PyNumberMethods member 'int_range' ? Or some kind of 'newobject_fromnumber' protocol ? How about we checkin the current patch, which does what the PEP describes, and continue the PEP for the sake of these issues ? :) > I don't view the issue for user-defined classes as a showstopper; > it would be OK, and semantically reasonable, to throw an exception > in this case. Agreed. And thanx for the emacs pointers ! :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip@mojam.com (Skip Montanaro) Tue Jul 18 19:07:58 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 18 Jul 2000 13:07:58 -0500 (CDT) Subject: [Python-Dev] Patches In-Reply-To: References: <20000718130059.B7340@xs4all.nl> Message-ID: <14708.40190.852802.966575@beluga.mojam.com> Moshe> In fact, putting an implementation of pad() like that in the Moshe> string.py module would be wonderful, because it would work with Moshe> both regular strings and unicode. However, string.py is looking Moshe> as though as it's going to be deprecated. In short, I'd want Moshe> Guido/Tim/effbot/MAL opinions here before we make a move. Don't know about the powers that be, but I don't see how you can realistically deprecate string.py until you deprecate map(). My most frequent use of map() is the simple newlist = map(string.strip, oldlist) where oldlist is a list of strings. (Replace "strip" by "upper", "lower", etc, depending on your needs.) As far as I'm aware, there's no clean way to do that with string methods. Skip From Fredrik Lundh" <39746807.DFA2B329@schneider-kamp.de> Message-ID: <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> > > - safe version of PyErr_Format > > +0 on that, but what do I know. Don't know if it's actually safe ;) >=20 > -0 on that, I'd rather use snprintf when available, sprintf when not. strange argument. why is it okay to crash Python on Windows, pure SUSv2 platforms, pure ANSI C platforms, etc? besides, snprintf doesn't do the same thing as my PyErr_Format replacement... From gstein@lyra.org Tue Jul 18 20:41:44 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 12:41:44 -0700 Subject: [Python-Dev] Terminal programs (was: Python-dev summary: Jul 1-15) In-Reply-To: <20000718101321.D21354@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Tue, Jul 18, 2000 at 10:13:21AM -0400 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> Message-ID: <20000718124144.M29590@lyra.org> On Tue, Jul 18, 2000 at 10:13:21AM -0400, Andrew Kuchling wrote: > Thanks to everyone who made some suggestions. The more minor > edits have been made, but I haven't added any of the threads I missed > because doing a long stretch of Emacs editing in this lame Windows terminal > program will drive me insane, so I just posted the summary to python-list. > > How is it possible for Microsoft to not get a VT100-compatible > terminal program working correctly? VT100s have been around since, > when, the 1970s? Can anyone suggest a Windows terminal program that > *doesn't* suck dead bunnies through a straw? yes. I use "Tera Term Pro" with the SSH extensions. That gives me an excellent Telnet app, and it gives me SSH. I have never had a problem with it. [ initially, there is a little tweakiness with creating the "known_hosts" file, but you just hit "continue" and everything is fine after that. ] Tera Term Pro can be downloaded from some .jp address. I think there is a 16-bit vs 32-bit program. I use the latter. The SSL stuff is located in Oz, me thinks. I've got it on the laptop. Great stuff. Cheers, -g -- Greg Stein, http://www.lyra.org/ From nascheme@enme.ucalgary.ca Tue Jul 18 21:37:03 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 18 Jul 2000 14:37:03 -0600 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: <20000718101321.D21354@newcnri.cnri.reston.va.us>; from Andrew Kuchling on Tue, Jul 18, 2000 at 10:13:21AM -0400 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> Message-ID: <20000718143703.A15498@keymaster.enme.ucalgary.ca> On Tue, Jul 18, 2000 at 10:13:21AM -0400, Andrew Kuchling wrote: > Can anyone suggest a Windows terminal program that *doesn't* suck dead > bunnies through a straw? I like putty. You can do a google search for it or grab it off my website: http://www.enme.ucalgary.ca/~nascheme/putty.exe http://www.enme.ucalgary.ca/~nascheme/pscp.exe http://www.enme.ucalgary.ca/~nascheme/putty.zip It's a single exectutable that does telnet, SSH and raw TCP connections (very nice when your away from home). It sucks much less than the Windows telnet. Hmm, I wonder if MS was motivated to make logging into a Unix machine as painful as possible? Neil From paul@prescod.net Tue Jul 18 21:50:57 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 18 Jul 2000 15:50:57 -0500 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> Message-ID: <3974C331.4FAFD48D@prescod.net> Thomas Wouters wrote: > >... > > .... > > - Better error message with UnboundLocalError > Patch looks okay to me, and Tim already said he liked the idea. Tim might as well look at it. I'm a little paranoid about changing ceval. I fixed the static typo you pointed out. Re: range literal: I think you need to assign it to some "core" to look at. Yes, Guido likes the idea but nobody has verified the implementation. Maybe it isn't an issue of core/non-core but more just a requirement for a second opinion. I would advise against checking in without it. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From thomas@xs4all.net Tue Jul 18 22:28:33 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 23:28:33 +0200 Subject: [Python-Dev] 'shadowing' builtins In-Reply-To: <39734E04.C7D29873@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 01:18:44PM -0500 References: <20000717200116.P7340@xs4all.nl> <39734E04.C7D29873@prescod.net> Message-ID: <20000718232833.F4283@xs4all.nl> On Mon, Jul 17, 2000 at 01:18:44PM -0500, Paul Prescod wrote: > Thomas Wouters wrote: > > He decided to go to David Beazly's python introduction, and he was suprised > > at how you can do 'None = 4'. And when I explained it's harmless (because > > it's local, not global) he was suprised it didn't generate a warning. And, > > well, why doesn't it generate a warning ? Only with an, uhm, '-w' option or > > so, of course, or perhaps add it to the '-t' option. It would be also a > > compile-time-check. It might require a seperate lookup table (haven't looked > > at it at all, yet) that duplicates the 'builtin' namespace, but I'd think > > it's worth it. > * None, map and other such long-term, ancient built-ins should not be > directly overridable. I don't think we need a warning mode. Just outlaw > it. We can do this with a semantic check in the compiler. My first reaction was 'Ack, eek, argh, nonono'. So I decided to sleep over it. And my reaction is still 'Ack. eek, argh, nonono' ;) If it's optional, like a '-ww' option, sure. But by default ? Please don't. One of python's great features is that it's so damned consistent. Having some builtins overridable and others not would not only break a lot of code, it would also confuse a lot of people. There is no particular reason to disallow assigning to map() for programs where map() is not used, for instance. I often find myself doing 'list = <...>' for small scripts, eventhough I realize while I'm typing that 'list' is a builtin function. Part of the reasons is that 'list' is an incredibly descriptive name, and my code often gets read by colleagues who still need to get infected by the Python virus. (Though, I have to admit, it *is* slowly spreading ;) Nevertheless, I wouldn't do that in large projects, and that's where I invision the '-w' option would be best used. 'This might become a problem'. > * Those with a good reason to shadow them would do it by assignment to > the module's dict or __builtins__. The "feature" would still be there if > you need it, but it would be syntactically distinct. Or maybe we need to > disallow it entirely to allow optimizers to attack this important > special case. Perhaps, as an option. With an optimizer. I wouldn't do it for the sake of it; only do it if the user asks for it. > * Python badly needs a warning infrastructure. If I had time, that > would be my first PEP. I'd rather the former tightening up was not > hostage to a warning infrastructure that nobody gets around to > implementing, though. I might be tempted to suggest a compile-only command line switch, too. Doing it through a small script is a tad cumbersome, especially if you just want a compile-run with (for instance) -w or -t, to see if you have any obvious problems. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul@prescod.net Tue Jul 18 22:45:19 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 18 Jul 2000 16:45:19 -0500 Subject: [Python-Dev] 'shadowing' builtins References: <20000717200116.P7340@xs4all.nl> <39734E04.C7D29873@prescod.net> <20000718232833.F4283@xs4all.nl> Message-ID: <3974CFEF.C55AC9B@prescod.net> Thomas Wouters wrote: > > ... > > My first reaction was 'Ack, eek, argh, nonono'. So I decided to sleep over > it. And my reaction is still 'Ack. eek, argh, nonono' ;) If it's optional, > like a '-ww' option, sure. But by default ? Please don't. One of python's > great features is that it's so damned consistent. Having some builtins > overridable and others not would not only break a lot of code, it would also > confuse a lot of people. Most people probably do not even know that the built-in functions can be shadowed. That's precisely the problem. I don't think that enforcing a rule that they expect to already be enforced will confuse them. As your friend pointed out, NOT enforcing the rule confuses them. > There is no particular reason to disallow assigning to map() for programs > where map() is not used, for instance. I often find myself doing 'list = > <...>' for small scripts, eventhough I realize while I'm typing that 'list' > is a builtin function. Part of the reasons is that 'list' is an incredibly > descriptive name, and my code often gets read by colleagues who still need > to get infected by the Python virus. Using the same word for two different things is more likely to confuse them than help them. Anyhow, constructor functions and type names need to be unified (for consistency) and type names and class names need to be unified (for consistency). And class names start with an upper case letter. So the need to override list() is scheduled to go away (eventually!) > Nevertheless, I wouldn't do that in large projects, and that's where I > invision the '-w' option would be best used. 'This might become a problem'. It is just as likely a problem in a small project than ina a big one. The shadowing is local, after all. It isn't a problem that "gets worse" as the program grows. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From esr@thyrsus.com Tue Jul 18 23:11:48 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Tue, 18 Jul 2000 18:11:48 -0400 Subject: [Python-Dev] what happened with the python-list addresses? In-Reply-To: <14708.43013.274067.569324@beluga.mojam.com> References: <14708.43013.274067.569324@beluga.mojam.com> Message-ID: <20000718181148.F1283@thyrsus.com> Skip Montanaro : > > I don't want to create a storm on c.l.py, so I post here. I noticed a bunch > of "email addresses" that look like "aahz@netcom.com.bbs@openbazaar.net" in > recent digests. Is there some sort of runaway gateway? Who is > openbazaar.net? Sounds like something ESR would be involved with, though I > can't reach an obvious web site in that domain and they appear to be located > in Taiwan. > > Skip I know nothing about it. -- Eric S. Raymond What, then is law [government]? It is the collective organization of the individual right to lawful defense." -- Frederic Bastiat, "The Law" From peter@schneider-kamp.de Wed Jul 19 01:04:00 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 00:04:00 +0000 Subject: [Python-Dev] PEP 204 - Range Literals References: <20000718121831.A7340@xs4all.nl> Message-ID: <3974F070.CC18BED0@schneider-kamp.de> Thomas Wouters wrote: > > I've attached the first draft of PEP 204, Range Literals, which I just > uploaded to CVS as well. If anyone finds time to review it, or the proposed > implementation (patch #100902 on SourceForge) please do. I'm not sure what > to do with the patch... Guido said as much as 'apply it'(*), but I doubt > anyone really looked at it yet ;) Well, I can't say I really looked at it (the patch touches areas where I would deny me all too much expertise), but as far as I could understand it, it looks fine to me. This considered, I am still +1 on it. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From jack@oratrix.nl Tue Jul 18 23:09:39 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 19 Jul 2000 00:09:39 +0200 Subject: [Python-Dev] posixpath.normpath In-Reply-To: Message by Moshe Zadka , Tue, 18 Jul 2000 16:44:01 +0300 (IDT) , Message-ID: <20000718220944.ECF41126BD4@oratrix.oratrix.nl> Recently, Moshe Zadka said: > Simple question: what should > > a) posixpath.normpath("..") .. What else could it return? > b) posixpath.normpath("/..") This I'm a bit less sure about. Does anyone remember the Newcastle Connection a.k.a Unix United? It was a distributed filesystem where other hosts were reachable through /.. . Think of something analogous to going from foo.bar.nl to the root of bletch.bar.nl by doing /../bletch/ . The newcastle connection is long dead (at least, I assume it is) but unless the Posix standard unequivocally specifies that /.. == /. I think I'd keep it as-is. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Tue Jul 18 23:13:35 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 19 Jul 2000 00:13:35 +0200 Subject: [Python-Dev] what happened with the python-list addresses? In-Reply-To: Message by Skip Montanaro , Tue, 18 Jul 2000 13:55:01 -0500 (CDT) , <14708.43013.274067.569324@beluga.mojam.com> Message-ID: <20000718221340.50A58126BD4@oratrix.oratrix.nl> Recently, Skip Montanaro said: > openbazaar.net? Sounds like something ESR would be involved with, [...] On the premise that anything with "bazaar" has to do with ESR? Hmm, then I could try asking him for a refund on that overpriced and leaky teapot I got in Egypt last year... :-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From peter@schneider-kamp.de Wed Jul 19 01:13:52 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 00:13:52 +0000 Subject: [Python-Dev] PEP 206 - NumPy Message-ID: <3974F2C0.F028CE48@schneider-kamp.de> I know this has probably been discussed many times, but a) I haven't been around that long and b) there is a TBD in nondist/peps/pep-206.txt :-] What would it take to include NumPy with the "Batteries included" release of Python? BTW: What about kjBuckets and some other modules that have been proposed? They are not in the PEP. ducking-behind-a-shuttle-style-ceramic-tile-heat-absorber-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From barry@scottb.demon.co.uk Tue Jul 18 23:15:10 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Tue, 18 Jul 2000 23:15:10 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Message-ID: <000601bff105$a3770500$060210ac@private> mark commenting on Gordon commenting on Barry... > If we are asking them to change their code, can we investigate whether > asking them to insert a simple: > > if (!Py_IsInitialized()) > Py_FatalError("Bad Python version"); /* Never returns */ > > works OK? I believe it will, as long as Python's fatal error handler > doesnt make thread-state assumptions. I think this code will crash. 1. Python20.dll loads and is initialised. 2. python20.dll loads old_extension.pyd 3. old_extension.pyd causes python15.dll to load At this point we have two copies of python in memory. 4. old_extension.pyd calls Py_IsInitialized() which is bound to the function in python15.dll. 5. FALSE is return as python15.dll has not been initialised. 6. Py_FatalError which is bound in python15.dll is called. May well crash, certainly does not communicate to python20.dll You could just: if (!Py_IsInitialized()) return; Which prevents the module being created and hence gets an already implemented error message. The down side is that does not work for .PYD that have already been shipped for 1.5. Also if we wish to solve this class of problem for unix as well this does not work. Barry From barry@scottb.demon.co.uk Tue Jul 18 23:36:15 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Tue, 18 Jul 2000 23:36:15 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python Message-ID: <000701bff108$950ec9f0$060210ac@private> Mark's comment about what I'd come up with being too complex inspired this simpler solution. Change the init function name to a new name PythonExtensionInit_ say. Pass in the API version for the extension writer to check. If the version is bad for this extension returns without calling any python functions. Add a return code that is true if compatible, false if not. If compatible the extension can use python functions and report and problems it wishes. int PythonExtensionInit_XXX( int invoking_python_api_version ) { if( invoking_python_api_version != PYTHON_API_VERSION ) { /* python will report that the module is incompatible */ return 0; } /* setup module for XXX ... */ /* say this extension is compatible with the invoking python */ return 1; } All 1.5 extensions fail to load on later python 2.0 and later. All 2.0 extensions fail to load on python 1.5. All new extensions work only with python of the same API version. Document that failure to setup a module could mean the extension is incompatible with this version of python. Small code change in python core. But need to tell extension writers what the new interface is and update all extensions within the python CVS tree. Barry From Fredrik Lundh" <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> Message-ID: <016501bff10a$d09bc660$f2a6b5d4@hagrid> > [paul] > > Also, is it really necessary to allow raw non-ASCII characters in = source > > code though? We know that they aren't portable across editing > > environments, so one person's happy face will be another person's = left > > double-dagger. > > [me] > I suppose changing that would break code. maybe it's time > to reopen the "pragma encoding" thread? >=20 > (I'll dig up my old proposal, and post it under a new subject). as brief as I can make it: 1. add support for "compiler directives". I suggest the following syntax, loosely based on XML: #?python key=3Dvalue [, key=3Dvalue ...] (note that "#?python" will be treated as a token after this change. if someone happens to use comments that start with #?python, they'll get a "SyntaxError: bad #?python compiler directive"...) 2. for now, only accept compiler directives if they appear before the first "real" statement. 3. keys are python identifiers (NAME tokens), values are simple literals (STRING, NUMBER) 4. key/value pairs are collected in a dictionary. 5. for now, we only support the "encoding" key. it is used to determine how string literals (STRING tokens) are converted to string or unicode string objects. 6. the encoding value can be any of: "undefined" or not defined at all: plain string: copy source characters as is unicode string: expand 8-bit source characters to unicode characters (i.e. treat them as ISO Latin 1) "ascii" plain string: characters in the 128-255 range gives a SyntaxError (illegal character in string literal). unicode string: same as for plain string any other ascii-compatible encoding (the ISO 8859 series, Mac Roman, UTF-8, and others): plain string: characters in the 128-255 range gives a SyntaxError (illegal character in string literal). unicode string: characters in the 128-255 range are decoded, according to the given encoding. string has been decoded,=20 any other encoding (UCS-2, UTF-16) undefined (or SyntaxError: illegal encoding) to be able to flag this as a SyntaxError, I assume we can add an "ASCII compatible" flag to the encoding files. 7. only the contents of string literals can be encoded. the tokenizer still works on 7-bit ASCII (hopefully, this will change in future versions). 8. encoded string literals are decoded before Python looks for backslash escape codes. I think that's all. Comments? I've looked at the current implementation rather carefully, and it shouldn't be that hard to come up with patches that implement this scheme. From Vladimir.Marangozov@inrialpes.fr Wed Jul 19 00:37:09 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 19 Jul 2000 01:37:09 +0200 Subject: [Python-Dev] [Fwd: Python-dev summary: July 1-15] Message-ID: <3974EA25.EF4B86C7@inrialpes.fr> Forgot to cc: the list. Vladimir Marangozov wrote: > > David Bolen wrote: > > > > Andrew Kuchling writes: > > > > > This is a first experiment in whether I can make a useful, > > > interesting, somewhat coherent summary of python-dev activity. > > > If reaction is favorable, and time permits, it may become a biweekly > > > posting. > > > > This seems quite useful - is there any "proper" way to send feedback > > on mail on python-dev without actually being on the list? > > > > Yes. It's the comp.lang.python newsgroup. Pick up an issue, give it > a meaningful subject line (eg. Subject: Re: PEP 201 - Parallel iteration) > and discuss it. Most people on python-dev read the newsgroup regularly > and forward to the python-dev list some of the issues that have been > brought here. So there's feedback from the group to python-dev > and there's a natural selection of the topics that need python-dev's > attention. This "selection" is a matter of experience -- some topics > are recurrent in Python's life and not all posters in c.l.py are aware > that they have been discussed extensively in the past. > > The reverse wasn't true and the python-dev summary documents are intended > to inform a broader audience, notably the Python community, on its > current activities. The natural place for discussing all topics brought > on python-dev is the comp.lang.python newsgroup. This is also the place > where the python-dev members are looking for feedback. For instance, > read the PEP documents -- they summarize recent and past proposals for > various enhancements. All python-dev members are interested in seeing > them discussed by the community. So don't hesitate to take a stance on > a PEP if you think that you could share an educated opinion. > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw@beopen.com Wed Jul 19 00:34:17 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 19:34:17 -0400 (EDT) Subject: [Python-Dev] what happened with the python-list addresses? References: <14708.43013.274067.569324@beluga.mojam.com> Message-ID: <14708.59769.955591.282115@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> I don't want to create a storm on c.l.py, so I post here. I SM> noticed a bunch of "email addresses" that look like SM> "aahz@netcom.com.bbs@openbazaar.net" in recent digests. Is SM> there some sort of runaway gateway? Who is openbazaar.net? SM> Sounds like something ESR would be involved with, though I SM> can't reach an obvious web site in that domain and they appear SM> to be located in Taiwan. No clue from me, unfortunately. Thomas Wouters noticed the same thing and the postmaster identified in the headers has been notified. -Barry From gstein@lyra.org Wed Jul 19 01:26:13 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 17:26:13 -0700 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: <20000718143703.A15498@keymaster.enme.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Tue, Jul 18, 2000 at 02:37:03PM -0600 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> <20000718143703.A15498@keymaster.enme.ucalgary.ca> Message-ID: <20000718172613.I7033@lyra.org> On Tue, Jul 18, 2000 at 02:37:03PM -0600, Neil Schemenauer wrote: > On Tue, Jul 18, 2000 at 10:13:21AM -0400, Andrew Kuchling wrote: > > Can anyone suggest a Windows terminal program that *doesn't* suck dead > > bunnies through a straw? > > I like putty. You can do a google search for it or grab it off my > website: > > http://www.enme.ucalgary.ca/~nascheme/putty.exe > http://www.enme.ucalgary.ca/~nascheme/pscp.exe > http://www.enme.ucalgary.ca/~nascheme/putty.zip > > It's a single exectutable that does telnet, SSH and raw TCP connections > (very nice when your away from home). It sucks much less than the > Windows telnet. Hmm, I wonder if MS was motivated to make logging into > a Unix machine as painful as possible? Well it also sucks when you're trying to connect to a MUD. Has nothing to do with Unix :-) Face it: their telnet just blows chunks... hehe... Cheers, -g -- Greg Stein, http://www.lyra.org/ From alex_c@MIT.EDU Wed Jul 19 01:22:45 2000 From: alex_c@MIT.EDU (Alex Coventry) Date: Tue, 18 Jul 2000 20:22:45 -0400 (EDT) Subject: [Python-Dev] PEP 206 - NumPy In-Reply-To: <3974F2C0.F028CE48@schneider-kamp.de> (message from Peter Schneider-Kamp on Wed, 19 Jul 2000 00:13:52 +0000) References: <3974F2C0.F028CE48@schneider-kamp.de> Message-ID: <200007190022.UAA107087@w20-575-115.mit.edu> > BTW: What about kjBuckets and some other modules that have > been proposed? They are not in the PEP. I used to use kjbuckets.kjSet a lot, but when I switched to bleeding-edge python, I decided to try a roll-your-own using python dictionaries because I expected (for no good reason -- I've never looked at the python source for this :) the hashing implementation had improved. I haven't done any formal benchmarking, but for the one application where I decided to do this, that one change made for a tremendous speed up. The class I used instead of kjbuckets.kjSet is at http://puffin.lcs.mit.edu:8080/cgi-bin/cvsweb/mouse/tools/Set.py?rev=1.6&content-type=text/x-cvsweb-markup Alex. From gstein@lyra.org Wed Jul 19 01:48:03 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 17:48:03 -0700 Subject: [Python-Dev] uPEP: encoding directive In-Reply-To: <016501bff10a$d09bc660$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jul 19, 2000 at 12:52:11AM +0200 References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> Message-ID: <20000718174803.L7033@lyra.org> On Wed, Jul 19, 2000 at 12:52:11AM +0200, Fredrik Lundh wrote: >... > as brief as I can make it: Sounds reasonable to me. PEP it, and let's see what the BDFL has to say about the general direction. Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake@beopen.com Wed Jul 19 02:09:24 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 18 Jul 2000 21:09:24 -0400 (EDT) Subject: [Python-Dev] posixpath.normpath In-Reply-To: References: Message-ID: <14708.65476.123678.27693@beowolf.beopen.com> Moshe Zadka writes: > Simple question: what should > > a) posixpath.normpath("..") ".." > b) posixpath.normpath("/..") "/" -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul@prescod.net Wed Jul 19 02:45:24 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 18 Jul 2000 20:45:24 -0500 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> <14708.40190.852802.966575@beluga.mojam.com> Message-ID: <39750834.B068CA61@prescod.net> Skip Montanaro wrote: > > ... > newlist = map(string.strip, oldlist) > > As far as I'm aware, there's no clean way to do that with string methods. Once we have list comprehensions, there will be: newlist = [for x in oldlist: x.strip()] I think the list-comp version is much more readable and "generic". -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From gmcm@hypernet.com Tue Jul 18 20:11:37 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 18 Jul 2000 15:11:37 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: References: <1248199317-67151042@hypernet.com> Message-ID: <1248148993-1712008@hypernet.com> Moshe wrote: > I disagree: you agree that if you add a pad argument when the > lists are all the same size it doesn't matter (if you don't agree > with this, you don't agree with the PEP). Now, when there is only > one list, the lists are all the same size. QED. I would agree if we were talking about transpose(matrix, [pad]). Then: transpose([(1,2,3)]) -> [(1,), (2,), (3,)] and transpose([(1,), (2,), (3,)]) -> [(1,2,3)] That is, a 3X1 transposes to a 1X3 and vice versa. But zip doesn't take a matrix, it takes some number of sequences. Oh heck, I'll agree anyway. But I dread explaining why 1) it doesn't behave like map(None, [1,2,3]) 2) why zip(((1,2),(3,4))) doesn't yield [(1,3), (2,4)] but [((1,2),), ((3,4),)] instead! So: document zip as taking 2 or more sequences, and throw an exception if fed only one. - Gordon From bwarsaw@beopen.com Wed Jul 19 04:42:53 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:42:53 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> Message-ID: <14709.9149.395757.2952@anthem.concentric.net> >>>>> "Gordo" == Gordon McMillan writes: Gordo> How about a fourth: zip(a) is the same as zip(a, []) ? I don't like it. The way I view zip() is that the length of the elements returned by __getitem__() should always be equal to the number of sequences passed in as parameters. Thus it seems most natural to me that >>> zip((1, 2, 3)) [(1,), (2,), (3,)] >>> zip((1, 2, 3), pad=None) [(1,), (2,), (3,)] When I talk about "special casing", there's two ways to look at it. One possibility is that the implementation of zip has to explicitly check that the number of sequences is 1 and then `do something special' if so. To support Gordon's proposal, or the map()-equivalent, or the raise-an-exception proposal, that would be the case. The second possibility is that user code must `appear' to special case the situation when the number of sequences is exactly 1. I.e. >>> for (i,) in zip((1, 2, 3)): instead of the more natural (because it's less to type and because of the map() heritage): >>> for i in zip((1, 2, 3)): The first example isn't really special casing though. Personally, I think this is going to come up so infrequently that it's not worth it. -Barry From bwarsaw@beopen.com Wed Jul 19 04:44:16 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:44:16 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <1248199317-67151042@hypernet.com> Message-ID: <14709.9232.893964.219712@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I disagree: you agree that if you add a pad argument when the MZ> lists are all the same size it doesn't matter (if you don't MZ> agree with this, you don't agree with the PEP). Now, when MZ> there is only one list, the lists are all the same size. QED. Bingo. -Barry From bwarsaw@beopen.com Wed Jul 19 04:47:32 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:47:32 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <1248248594-64187019@hypernet.com> <200007172311.BAA25445@python.inrialpes.fr> Message-ID: <14709.9428.832622.474548@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> My wish is to add fold() as one of the suggested names in the VM> PEP Done. VM> then let this PEP spend some time in c.l.py. Will do. I just updated the reference implementation. I want to finish going through the comments in this forum and then I'll post to c.l.py. -Barry From bwarsaw@beopen.com Wed Jul 19 04:58:28 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:58:28 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <3973A097.B85D6775@schneider-kamp.de> Message-ID: <14709.10084.225732.826719@anthem.concentric.net> >>>>> "KM" == Ken Manheimer writes: KM> Evan Simpson (a colleague here at digicool, who'd be a good KM> addition to python-dev) noticed that unzip is unnecessary - KM> zip is its own inverse. Only if the sequences are of the same length. I've added this to the PEP, using the extended call syntax. Note that when the sequences are of the same length, zip() is reversible: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> x = zip(a, b) >>> y = zip(*x) # alternatively, apply(zip, x) >>> z = zip(*y) # alternatively, apply(zip, y) >>> x [(1, 4), (2, 5), (3, 6)] >>> y [(1, 2, 3), (4, 5, 6)] >>> z [(1, 4), (2, 5), (3, 6)] >>> x == z 1 It is not possible to reverse zip this way when the sequences are not all the same length. -Barry From bwarsaw@beopen.com Wed Jul 19 04:59:03 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:59:03 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <39743E3A.249212D5@schneider-kamp.de> <011701bff09d$0bc5b020$0900a8c0@SPIFF> Message-ID: <14709.10119.28590.73144@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> Remember the "string join" debate? Yup! FL> -1 on a method. Agreed. -Barry From bwarsaw@beopen.com Wed Jul 19 05:00:17 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 00:00:17 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <14709.10193.715558.561239@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I'm +1 on that. One thing that bugs me is that we're adding a MZ> builtin type. Why not stick with the Python implementation? I've been thinking a little bit about the other generators, especially irange(). I wonder if we shouldn't just be putting zip() and friends in their own Python module and not make them builtins? -Barry From peter@schneider-kamp.de Wed Jul 19 07:17:49 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 06:17:49 +0000 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> Message-ID: <3975480D.29F6A89C@schneider-kamp.de> Fredrik Lundh wrote: > > > -0 on that, I'd rather use snprintf when available, sprintf when not. > > strange argument. why is it okay to crash Python on Windows, > pure SUSv2 platforms, pure ANSI C platforms, etc? I was assuming that most modern systems have a sprintf function available. If this is not the case, my argument is indeed void. I was extrapolating from the fact that it's available on the systems I work on (linux, sunos, solaris). > besides, snprintf doesn't do the same thing as my PyErr_Format > replacement... Yes, but it would by possible to use snprintf in PyErr_Format. +1 on the patch. We cannot neglect Windows (unfortunately). Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Moshe Zadka Wed Jul 19 05:28:00 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 19 Jul 2000 07:28:00 +0300 (IDT) Subject: [Python-Dev] posixpath.normpath In-Reply-To: <20000718220944.ECF41126BD4@oratrix.oratrix.nl> Message-ID: On Wed, 19 Jul 2000, Jack Jansen wrote: > > Recently, Moshe Zadka said: > > Simple question: what should > > > > a) posixpath.normpath("..") > > .. > > What else could it return? > > > b) posixpath.normpath("/..") > > This I'm a bit less sure about. Does anyone remember the Newcastle > Connection a.k.a Unix United? It was a distributed filesystem where > other hosts were reachable through /.. . Think of something analogous > to going from foo.bar.nl to the root of bletch.bar.nl by doing > /../bletch/ . > > The newcastle connection is long dead (at least, I assume it is) but > unless the Posix standard unequivocally specifies that /.. == /. I > think I'd keep it as-is. Reason I'm asking: I don't like the posixpath.normpath patch, and thinking of rewriting it into a competitor. Those two sound reasonable, but I'll wait for more opinions... -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Moshe Zadka Wed Jul 19 05:32:00 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 19 Jul 2000 07:32:00 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248148993-1712008@hypernet.com> Message-ID: On Tue, 18 Jul 2000, Gordon McMillan wrote: > So: document zip as taking 2 or more sequences, and throw > an exception if fed only one. Agreed: it seems too much ambiguos. I mean, I didn't think it ambiguous, and neither did Gordon and /F -- only each of us saw a different unambiguouity which show it is. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Moshe Zadka Wed Jul 19 05:37:29 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 19 Jul 2000 07:37:29 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.10193.715558.561239@anthem.concentric.net> Message-ID: On Wed, 19 Jul 2000, Barry A. Warsaw wrote: > >>>>> "MZ" == Moshe Zadka writes: > > MZ> I'm +1 on that. One thing that bugs me is that we're adding a > MZ> builtin type. Why not stick with the Python implementation? > > I've been thinking a little bit about the other generators, especially > irange(). I wonder if we shouldn't just be putting zip() and friends > in their own Python module and not make them builtins? I'm +1. def-irange(seq):-zip(xrange(len(seq)), seq)-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas@xs4all.net Wed Jul 19 07:02:19 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 08:02:19 +0200 Subject: [Python-Dev] 'shadowing' builtins In-Reply-To: <3974CFEF.C55AC9B@prescod.net>; from paul@prescod.net on Tue, Jul 18, 2000 at 04:45:19PM -0500 References: <20000717200116.P7340@xs4all.nl> <39734E04.C7D29873@prescod.net> <20000718232833.F4283@xs4all.nl> <3974CFEF.C55AC9B@prescod.net> Message-ID: <20000719080218.G4283@xs4all.nl> On Tue, Jul 18, 2000 at 04:45:19PM -0500, Paul Prescod wrote: > Thomas Wouters wrote: > > My first reaction was 'Ack, eek, argh, nonono'. So I decided to sleep over > > it. And my reaction is still 'Ack. eek, argh, nonono' ;) If it's optional, > > like a '-ww' option, sure. But by default ? Please don't. One of python's > > great features is that it's so damned consistent. Having some builtins > > overridable and others not would not only break a lot of code, it would also > > confuse a lot of people. > Most people probably do not even know that the built-in functions can be > shadowed. That's precisely the problem. I don't think that enforcing a > rule that they expect to already be enforced will confuse them. As your > friend pointed out, NOT enforcing the rule confuses them. No. He didn't know the scoping rules, and that was all he was worried about. He was only confused because it didn't generate a warning when he thought it should. Making it impossible to shadow builtins by default would confuse a lot more people, because suddenly they can't use the variable names they want, and they can't figure out why. "list" is a builtin ?? > Using the same word for two different things is more likely to confuse > them than help them. Anyhow, constructor functions and type names need > to be unified (for consistency) and type names and class names need to > be unified (for consistency). And class names start with an upper case > letter. So the need to override list() is scheduled to go away > (eventually!) My code never does that. My code simply does not use 'list'. As for the other style issues, There also wasn't a *need* to override list, it was merely convenience. And Python is a very, very convenient language... let's not change that :P > > Nevertheless, I wouldn't do that in large projects, and that's where I > > invision the '-w' option would be best used. 'This might become a problem'. > It is just as likely a problem in a small project than ina a big one. > The shadowing is local, after all. It isn't a problem that "gets worse" > as the program grows. Actually, no, it depends on where and how you use it. In large programs, my functions get larger too, on average. I'm talking 10 lines -> 100 lines here. Also don't forget the global namespace, which affects a lot more code in large programs. And lastly, small programs are only edited by me, or sometimes quick-fixed by a colleague. Large programs get edited by a fair group of people, over a number of years. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Wed Jul 19 07:13:00 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 08:13:00 +0200 Subject: [Python-Dev] posixpath.normpath In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 18, 2000 at 04:44:01PM +0300 References: Message-ID: <20000719081300.H4283@xs4all.nl> On Tue, Jul 18, 2000 at 04:44:01PM +0300, Moshe Zadka wrote: > a) posixpath.normpath("..") '..'. > b) posixpath.normpath("/..") '/'. I *think* this is POSIXly defined, but I'm not sure. However, this is the behaviour on all UNIX machines I've ever seen, and also in protocols like HTTP that take a URL with forward slashes and possibly '..'s. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Moshe Zadka Wed Jul 19 07:14:52 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 19 Jul 2000 09:14:52 +0300 (IDT) Subject: [Python-Dev] posixpath.normpath In-Reply-To: <20000719081300.H4283@xs4all.nl> Message-ID: On Wed, 19 Jul 2000, Thomas Wouters wrote: > On Tue, Jul 18, 2000 at 04:44:01PM +0300, Moshe Zadka wrote: > > > a) posixpath.normpath("..") > > '..'. > > > b) posixpath.normpath("/..") > > '/'. I *think* this is POSIXly defined, but I'm not sure. However, this is > the behaviour on all UNIX machines I've ever seen, and also in protocols > like HTTP that take a URL with forward slashes and possibly '..'s. OK. I've posted a patch which corrects posixpath.normpath and competes with 100900. Now Skip gets to decide which of them he likes better... -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From mwh21@cam.ac.uk Wed Jul 19 07:19:42 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 19 Jul 2000 07:19:42 +0100 Subject: [Python-Dev] what happened with the python-list addresses? In-Reply-To: bwarsaw@beopen.com's message of "Tue, 18 Jul 2000 19:34:17 -0400 (EDT)" References: <14708.43013.274067.569324@beluga.mojam.com> <14708.59769.955591.282115@anthem.concentric.net> Message-ID: bwarsaw@beopen.com (Barry A. Warsaw) writes: > >>>>> "SM" == Skip Montanaro writes: > > SM> I don't want to create a storm on c.l.py, so I post here. I > SM> noticed a bunch of "email addresses" that look like > SM> "aahz@netcom.com.bbs@openbazaar.net" in recent digests. Is > SM> there some sort of runaway gateway? Who is openbazaar.net? > SM> Sounds like something ESR would be involved with, though I > SM> can't reach an obvious web site in that domain and they appear > SM> to be located in Taiwan. > > No clue from me, unfortunately. Thomas Wouters noticed the same thing > and the postmaster identified in the headers has been notified. It's stopped now, it seems; killfiling on Organization: OpenBazaar was an effective stop gap measure. Cheers, M. From mwh21@cam.ac.uk Wed Jul 19 07:30:54 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 19 Jul 2000 07:30:54 +0100 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: Andrew Kuchling's message of "Tue, 18 Jul 2000 10:13:21 -0400" References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> Message-ID: Andrew Kuchling writes: > Thanks to everyone who made some suggestions. The more minor > edits have been made, but I haven't added any of the threads I missed > because doing a long stretch of Emacs editing in this lame Windows terminal > program will drive me insane, so I just posted the summary to python-list. > > How is it possible for Microsoft to not get a VT100-compatible > terminal program working correctly? VT100s have been around since, > when, the 1970s? Can anyone suggest a Windows terminal program that > *doesn't* suck dead bunnies through a straw? Windows 2000's is (much!) better. Putty is also good; it lives at http://www.chiark.greenend.org.uk/~sgtatham/putty/ Cheers, M. From Moshe Zadka Wed Jul 19 07:38:45 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 19 Jul 2000 09:38:45 +0300 (IDT) Subject: [Python-Dev] PEP 206 - NumPy In-Reply-To: <3974F2C0.F028CE48@schneider-kamp.de> Message-ID: On Wed, 19 Jul 2000, Peter Schneider-Kamp wrote: > I know this has probably been discussed many times, but > a) I haven't been around that long and > b) there is a TBD in nondist/peps/pep-206.txt :-] > > What would it take to include NumPy with the "Batteries included" > release of Python? Well, as maintainer of 206, I'd like to answer that: user requests. I haven't done any numeric programming for some time now, so I'm out of touch with this world. I'm planning of preparing 206 for c.l.py discussion this weekend. > BTW: What about kjBuckets and some other modules that have > been proposed? They are not in the PEP. Well, my usual rule is that anyone proposing a new module must do the web research necessary to find out where is the official place to download a known working version from. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gstein@lyra.org Wed Jul 19 07:53:17 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 23:53:17 -0700 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.10193.715558.561239@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 19, 2000 at 12:00:17AM -0400 References: <14707.22821.945571.314619@anthem.concentric.net> <14709.10193.715558.561239@anthem.concentric.net> Message-ID: <20000718235317.A7561@lyra.org> On Wed, Jul 19, 2000 at 12:00:17AM -0400, Barry A. Warsaw wrote: > >>>>> "MZ" == Moshe Zadka writes: > > MZ> I'm +1 on that. One thing that bugs me is that we're adding a > MZ> builtin type. Why not stick with the Python implementation? > > I've been thinking a little bit about the other generators, especially > irange(). I wonder if we shouldn't just be putting zip() and friends > in their own Python module and not make them builtins? Which are you proposing: 1) implement in a Python module. clients use some_module.zip() 2) implement in a Python module. insert into builtins. clients use zip(). ?? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Wed Jul 19 07:55:59 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 23:55:59 -0700 Subject: [Python-Dev] Patches In-Reply-To: <3975480D.29F6A89C@schneider-kamp.de>; from peter@schneider-kamp.de on Wed, Jul 19, 2000 at 06:17:49AM +0000 References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> Message-ID: <20000718235559.B7561@lyra.org> On Wed, Jul 19, 2000 at 06:17:49AM +0000, Peter Schneider-Kamp wrote: > Fredrik Lundh wrote: > > > > > -0 on that, I'd rather use snprintf when available, sprintf when not. Falling back to sprintf() is just untenable. > > strange argument. why is it okay to crash Python on Windows, > > pure SUSv2 platforms, pure ANSI C platforms, etc? > > I was assuming that most modern systems have a sprintf function (I presume you meant snprintf here) Yes, most do, but it isn't quite the same... > available. If this is not the case, my argument is indeed void. > > I was extrapolating from the fact that it's available on the > systems I work on (linux, sunos, solaris). > > > besides, snprintf doesn't do the same thing as my PyErr_Format > > replacement... > > Yes, but it would by possible to use snprintf in PyErr_Format. still not quite the same. /F's PyErr_Format returns an arbitrary length string. snprintf() would be cut at some pre-specified limit. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Fredrik Lundh" <20000718101321.D21354@newcnri.cnri.reston.va.us> Message-ID: <008001bff156$7b503a00$f2a6b5d4@hagrid> michael hudson: > > How is it possible for Microsoft to not get a VT100-compatible > > terminal program working correctly? VT100s have been around since, > > when, the 1970s? Can anyone suggest a Windows terminal program that > > *doesn't* suck dead bunnies through a straw? >=20 > Windows 2000's is (much!) better. much better, but still not good enough. fwiw, I'm using CRT ($35, big deal), which is about as good as it can get: http://www.vandyke.com/products/crt/ From tim_one@email.msn.com Wed Jul 19 06:12:11 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 19 Jul 2000 01:12:11 -0400 Subject: [Python-Dev] RE: Discussion: Introducing new operators for matrix computation In-Reply-To: Message-ID: Sleeping in the same room with Guido for a night did not make it easier to channel him, but it did make it easier to cloud his mind: Guido is not opposed to adding new operator symbols to core Python. As of breakfast Tuesday, anyway, and there are witnesses, so he'll have trouble changing his mind (well, it will be clumsy for him to *admit* it if he changes his mind ...). But but but (you knew it wouldn't be *that* easy!): + Everybody concerned that new operators are "not Pythonic" please swallow it -- it is Pythonic, cuz Guido said it is <0.9 wink -- but see following points too>. Contribute by helping to come up with a complete and Pythonically beautiful implementation instead. + Please keep this off of Python-Dev. Doesn't belong there (at least not yet). Interested parties can form a mailing list, or try to discuss it on comp.lang.python (my personal hope is that you try the latter, and stick to one Subject line). + There *must* be a PEP for this. Guido won't read any more of the debate -- it's too voluminous, repetitive and contentious. He'll eventually read a PEP, though, *after* some sort of consensus is reached. A PEP requires a champion. I hope Huaiyu Zhu volunteers for this, as he's argued his case eloquently and rationally. The champion doesn't need to know how to implement it, but does need to summarize sometimes-opposing positions dispassionately. + There are things Guido will & won't tolerate. Guessing which is an interesting & educational challenge . For example, adding a new operator like .+ is fine, as the maximal-munch rule for lexing can resolve formal ambiguities easily. OTOH, *any* new operator symbol containing a backslash is dead before arrival -- backslash has purely "meta" meanings in Python today. If the goal is to make Python look exactly like some other language, forget it. It's still Python, with some light syntactic sugar to make life in special domains sweeter. + This one is from me, but it's a safe bet you can view at as precognitive channeling if you oppose it: anyone suggesting to, e.g., make ".+" mean something new and exciting for ints or floats or strings or ... will be shot. There are probably no operations on the builtin types used frequently enough to merit new syntactic shorthands (excepting, perhaps, that if P3K changes the meaning of integer division, a new "//" operator for flooring division was looked upon kindly in the past). The new operators are for convenience in special domains (where the case for them is indeed very strong), not an excuse to turn current Python into a cryptic mess. + Also from me: forget about user-defined precedence and associativity. The PEP must define these once & for all, and that's that. + The set of new operator symbols cannot be open-ended (as it is in, e.g., Haskell). There are at least 4 variants of Python tranlators already in existence, and Guido wants the set of operator symbols fixed so that a variety of parsing techniques can be used in their natural forms without trickery. IOW, the full set of operator symbols must-- as it is today --be a fixed finite set known in advance. + If the numerical folk can't reach consensus on the set of operators and what they should mean, my bet is that Guido will let this die rather than get sucked into Pronouncing on each of the points in dispute. After all, he has little personal use for this stuff: if the people who *do* want it can't agree, it's not worth having. how's-that-for-a-mysterious-announcement?-ly y'rs - tim From tim_one@email.msn.com Wed Jul 19 06:12:14 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 19 Jul 2000 01:12:14 -0400 Subject: [Python-Dev] Patches In-Reply-To: <14708.26423.536040.581684@beluga.mojam.com> Message-ID: [Skip Montanaro] > As someone who has been assigned some patches that are still open (isatty, > normpath fix, history functions for readline), I'm still pretty > much in the dark about what my rights and responsibilities are. You have responsibility for keeping Python in perfect condition, and the right to be as confused as you like . > Am I supposed to eyeball a patch and check it in if it looks okay > (compiles, doesn't break "make test", etc)? Am I supposed to bring > it up for discussion on python-dev? Something entirely different > (blow up a bush, perhaps)? You're responsible for "taking the next step". What that step is depends on *your* good judgment: if you feel confident that the patch is fine, sure, check it in and close it. If you're confident that the patch sucks, reject it, explain why in a comment, and assign it back to the submitter. If you're uncertain, do neither of those: bring it up on Python-Dev, or if you think you know who *can* resolve your uncertainties, make a comment and assign it to them. > I just submitted a feature request for the patch manager at SF. > I asked for the following: > > 1. better selection/exclusion predicates for the filtering function > 2. filtering based on assignee/submitter > 3. display of a patch's state in the table > > If you'd like to review it and add your own two cents, it's at > > https://sourceforge.net/forum/message.php?msg_id=41288 We (PythonLabs) met with three of the Source Forge developers late Tuesday afternoon. They're perfectly reasonable and perfectly overburdened too. The one & only thing we got them to promise to implement Real Soon Now is a new checkbox on the Project Admin page, saying to send *all* patch email to the patches email address. By itself, this doesn't help anything. What it does do is enable *us* to build on the SF patch pages via automated "screen scraper" programs. Ka-Ping Yee wrote one of those but didn't post it here, to generate *useful* email when a msg from SourceForge tickles it. Jeremy Hylton posted a program here to scrape the SF pages and download the info into a local database. We can build better display and filtering tools (likely cmdline) ourselves on top of these. The SF people would be happy to too, but they appear not to have the bandwidth for it now. forthrightly y'rs - tim From python@horizon.com Wed Jul 19 09:22:40 2000 From: python@horizon.com (python@horizon.com) Date: 19 Jul 2000 08:22:40 -0000 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] Message-ID: <20000719082240.17706.qmail@science.horizon.com> ESR was kind enough to suggest that this idea was worthy of a larger audience, so here is my Very Humble Opinion Indeed... (My knowledge of Python is limited to buying the O'Reilly book and meaning to read it one of these days, so I may be missing something REALLY elementary here.) But if you want extensible infix operators without burdening people trying to read the code too much, consider this: For each existing operator #, there is an infinite family of user-definable operators @#, @@#, etc. These get progressivley less readable, so I don't think you'd *want* to go past @@, but hey, it's there if you want. Each one has the same precedence and associativity as the bare operator #, so there are no new rules for anyone to learn. "a @* b * c @@* d" would associate to the left as usual, producing "((a @* b) * c) @@* d". You should probably extend this to unary operators, so someone could, for example, define unary @- to be complex conjugate. An alternative precednece rule would put * > @* > @@* > ... > + > @+ > ..., which also avoids requiring people to learn much of anything new, but I think people trying to write parsers would object strenuously to an infinite number of precedence levels. You need some way to define all of these functions, but I assume that's just a Small Matter of Programming for the uber-studly programmers here, leaping from tree to tree in the mighty forests of British Columbia... Oh wait a minute, I'm sorry. That's just getting silly. A language I worked on a Long Time Ago used backquotes to turn operators into normal functions so a + b was `+`(a,b), and the syntax was also used when defining such functions, but I'm sure Python has some existing scheme for referring to built-in operators that could be extended. Anyway, just food for thought. (If that isn't enough extra operators, you can also add *@. And then even @*@. @@*@ and @*@@ are for the terminally masochistic, and anyone who'd go beyond that should be kept away from computers and sharp objects until they're feeling better.) "Better get a bu.}}}}NO CARRIER From jack@oratrix.nl Wed Jul 19 09:37:26 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 19 Jul 2000 10:37:26 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/sf-html sf-faq.html,1.4,1.5 In-Reply-To: Message by Peter Schneider-Kamp , Tue, 18 Jul 2000 14:43:26 -0700 , <200007182143.OAA02155@slayer.i.sourceforge.net> Message-ID: <20000719083726.9343137186E@snelboot.oratrix.nl> Peter, could you add a Macintosh section saying that it's currently quite impossible to use cvs over ssh, at least: as far as we know, and that any reports of getting it to work and/or pointers to more info would be appreciated? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From Fredrik Lundh" Message-ID: <018301bff15f$1f1acb20$f2a6b5d4@hagrid> tim wrote: > + There are things Guido will & won't tolerate. Guessing which is an > interesting & educational challenge . For example, adding a new > operator like >=20 > .+ >=20 > is fine, as the maximal-munch rule for lexing can resolve formal = ambiguities > easily. Only if you're thinking as a compiler... ;-) Besides, the proposed way to resolve "3.+x" means that the meaning of an operator would change depending on the preceeding operand (and the other way around). Sure sounds like Perl to me... > This one is from me, but it's a safe bet you can view at as = precognitive > channeling if you oppose it: anyone suggesting to, e.g., make ".+" = mean > something new and exciting for ints or floats or strings=20 Why not strings? As Perl has showed, *everyone* is doing string processing. If we're gonna add stuff, why not cater to the masses? For a start, how about: match =3D string .~ pattern I'm sure we can do something fun with ?, the sre scanner, and list comprehensions too... > There are at least 4 variants of Python translators=20 Fwiw, a recent sunworld article says six. And don't forget syntax checking development environments (afaik, at least two of them does that, or will in a near future). > Please keep this off of Python-Dev. Okay, okay. Last time I tried to say that, everyone shouted at me. On the other hand, now that Python has dropped from spot 10 down to 15 on the sourceforge top activity list, it's about time python-dev went back to actually doing things, instead of just talking about what could = be done... ;-) =20 From thomas@xs4all.net Wed Jul 19 12:25:55 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 13:25:55 +0200 Subject: [Python-Dev] ANSIfication ? Message-ID: <20000719132554.B9897@xs4all.nl> Is there any particular reason the ANSIfication stopped before it reached Python/, other than time issues ? If not, good, because I'm busy ANSIfying that directory ;) I'll post some patches later today, except for ceval.c and compile.c: the work I'm doing is relative to the range-literal patch, so I'm gonna wait until that one's accepted before uploading those ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From peter@schneider-kamp.de Wed Jul 19 14:43:47 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 13:43:47 +0000 Subject: [Python-Dev] ANSIfication ? References: <20000719132554.B9897@xs4all.nl> Message-ID: <3975B093.C2F125BD@schneider-kamp.de> Thomas Wouters wrote: > > Is there any particular reason the ANSIfication stopped before it reached > Python/, other than time issues ? If not, good, because I'm busy ANSIfying I don't think so. After ANSIfying the whole Module/ directory I was fed up. I'd guess the same applies to Fred who slaved away in Objects/ ... Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From bwarsaw@beopen.com Wed Jul 19 13:29:53 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 08:29:53 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <14709.10193.715558.561239@anthem.concentric.net> <20000718235317.A7561@lyra.org> Message-ID: <14709.40769.935694.167265@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: >> other generators, especially irange(). I wonder if we >> shouldn't just be putting zip() and friends in their own Python >> module and not make them builtins? GS> Which are you proposing: GS> 1) implement in a Python module. clients use some_module.zip() Yes. GS> 2) implement in a Python module. insert into builtins. clients GS> use zip(). No. -Barry From bwarsaw@beopen.com Wed Jul 19 13:50:56 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 08:50:56 -0400 (EDT) Subject: [Python-Dev] RE: Discussion: Introducing new operators for matrix computation References: Message-ID: <14709.42032.689117.684055@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> + There *must* be a PEP for this. There already is: PEP 211, Adding New Operators to Python. And it's been assigned to Greg Wilson, although he may want to re-assign it. It's currently just boilerplate. -Barry From alex_c@MIT.EDU Wed Jul 19 14:36:59 2000 From: alex_c@MIT.EDU (Alex Coventry) Date: Wed, 19 Jul 2000 09:36:59 -0400 (EDT) Subject: [Python-Dev] posixpath.normpath In-Reply-To: (message from Moshe Zadka on Wed, 19 Jul 2000 07:28:00 +0300 (IDT)) References: Message-ID: <200007191336.JAA18516@nerd-xing.mit.edu> FWIW, I vote for Moshe's patch. Alex. From paul@prescod.net Wed Jul 19 01:37:29 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 18 Jul 2000 19:37:29 -0500 Subject: [Python-Dev] PEP 204 - Range Literals References: <20000718121831.A7340@xs4all.nl> Message-ID: <3974F849.A83AC7CB@prescod.net> Should range literals create a list of the passed-in type ? It might be desirable in the cases of other builtin types, such as longs and strings: >>> [ 1L : 2L<<64 : 2<<32L ] >>> ["a":"z":"b"] >>> ["a":"z":2] However, this might be too much `magic' to be obvious. Well the step argument is of debatable utility for strings but ["0":"9"] seems mildly useful. Also, it makes sense to create a range of floating point numbers. If we were going to do this, we would probably have an overloadable operator: string.__range__( start=None, end=None, step=None ) It could return a sequence of whatever kind. I'm not clear why we can't implement it as a function call to __builtins__.range . -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From thomas@xs4all.net Wed Jul 19 13:55:28 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 14:55:28 +0200 Subject: [Python-Dev] HAVE_STDARG_PROTOTYPES Message-ID: <20000719145528.C9897@xs4all.nl> I'm currently assuming HAVE_STDARG_PROTOTYPES, as defined by configure comes implicitly with ANSI C compilers. (It defines the way to handle variable-argument functions, and I think the '...' method is standard ANSI C. Please correct me if I'm wrong.) However, I'm not sure what the ANSI standard says on the subject of va_list: there is a define that checks whether va_list is an array of some sort, or not. Is that K&R-C compatibility we can throw out, or should I keep it ? (it's not that much, so I'm keeping it for now.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Wed Jul 19 15:39:50 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 16:39:50 +0200 Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <3974F849.A83AC7CB@prescod.net>; from paul@prescod.net on Tue, Jul 18, 2000 at 07:37:29PM -0500 References: <20000718121831.A7340@xs4all.nl> <3974F849.A83AC7CB@prescod.net> Message-ID: <20000719163950.D9897@xs4all.nl> On Tue, Jul 18, 2000 at 07:37:29PM -0500, Paul Prescod wrote: > I'm not clear why we can't implement it as a function call to > __builtins__.range . I did that mostly because of the error messages. Giving the range() error messages when using [1:100] is a bit confusing. Can't think of any other reason, though. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip@mojam.com (Skip Montanaro) Wed Jul 19 16:43:13 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 19 Jul 2000 10:43:13 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_openpty.py,1.1,1.2 test_pty.py,1.2,1.3 In-Reply-To: <200007191451.HAA13863@slayer.i.sourceforge.net> References: <200007191451.HAA13863@slayer.i.sourceforge.net> Message-ID: <14709.52369.695950.390400@beluga.mojam.com> Thomas, Thanks for ANSIfying isatty and uncommenting it isatty tests. I had uncommented the tests here, but forgot to check them in... Skip From paul@prescod.net Wed Jul 19 17:09:05 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 11:09:05 -0500 Subject: [Python-Dev] uPEP: encoding directive References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> Message-ID: <3975D2A1.5DDA10E6@prescod.net> I'd prefer if you would separate out the compile directives PEP from the encoding PEP. I'm +1 on compiler directives. I'm -0 on literal encodings. It seems like more effort than is necessary. If we're going to restrict people to ASCII-like encodings, we could just restrict them to ASCII and get it over with. Also, I don't like that the default mode is non-portable. The default should be ASCII. Yes, this could cause backwards-compatibility problems. Maybe problems should be reported with warning. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul@prescod.net Wed Jul 19 17:09:45 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 11:09:45 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> Message-ID: <3975D2C9.66FE16C2@prescod.net> "Barry A. Warsaw" wrote: > >... > > > The second possibility is that user code must `appear' to special case > the situation when the number of sequences is exactly 1. I.e. > > >>> for (i,) in zip((1, 2, 3)): > > instead of the more natural (because it's less to type and because of > the map() heritage): > > >>> for i in zip((1, 2, 3)): Why are you using zip in this case? If you *know* that you are going to get back 1-tuples then you must know that the input is a single list (i.e. you aren't using "apply"). So why are you using zip at all? -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul@prescod.net Wed Jul 19 17:10:34 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 11:10:34 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <14709.10193.715558.561239@anthem.concentric.net> Message-ID: <3975D2FA.74795C3@prescod.net> "Barry A. Warsaw" wrote: > > ... > > I've been thinking a little bit about the other generators, especially > irange(). I wonder if we shouldn't just be putting zip() and friends > in their own Python module and not make them builtins? I prefer builtins (or in some cases methods) for this type of slice and dice functionality. It's not related to some particular datatype or domain. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul@prescod.net Wed Jul 19 17:11:39 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 11:11:39 -0500 Subject: [Python-Dev] PEP 204 - Range Literals References: <20000718121831.A7340@xs4all.nl> Message-ID: <3975D33B.6F4F0C8C@prescod.net> Should range literals create a list of the passed-in type ? It might be desirable in the cases of other builtin types, such as longs and strings: >>> [ 1L : 2L<<64 : 2<<32L ] >>> ["a":"z":"b"] >>> ["a":"z":2] However, this might be too much `magic' to be obvious. Well the step argument is of debatable utility for strings but ["0":"9"] seems mildly useful. Also, it makes sense to create a range of floating point numbers. If we were going to do this, we would probably have an overloadable operator: string.__range__( start=None, end=None, step=None ) It could return a sequence of whatever kind. I'm not clear why we can't implement it as a function call to __builtins__.range . -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From ping@lfw.org Wed Jul 19 17:46:39 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 19 Jul 2000 09:46:39 -0700 (PDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.10193.715558.561239@anthem.concentric.net> Message-ID: On Wed, 19 Jul 2000, Barry A. Warsaw wrote: > > I've been thinking a little bit about the other generators, especially > irange(). I wonder if we shouldn't just be putting zip() and friends > in their own Python module and not make them builtins? I'd say put both zip() and irange() in builtins. They're useful enough. (Ideally range(), zip(), and irange() would all make generators one day, and xrange() could be deprecated.) I would prefer zip() and irange() to make generators now -- because this means you could *pass* them generators, and they wouldn't force their arguments to enumerate everything first! For example, make readlines() a generator too and you've got for lnum, line in irange(file.readlines()): print "%5d: %s" % (lnum, line), How pretty is that? There's no issue with using generators in place of lists, as far as i can tell, since (as has already been suggested) you just turn the generator into a real list if somebody calls one of the methods on it or uses it where a tuple is expected. -- ?!ng From ping@lfw.org Wed Jul 19 17:58:56 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 19 Jul 2000 09:58:56 -0700 (PDT) Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <3974F849.A83AC7CB@prescod.net> Message-ID: On Tue, 18 Jul 2000, Paul Prescod wrote: > Should range literals create a list of the passed-in type ? It > might be desirable in the cases of other builtin types, such as > longs and strings: > > >>> [ 1L : 2L<<64 : 2<<32L ] > >>> ["a":"z":"b"] > >>> ["a":"z":2] > > However, this might be too much `magic' to be obvious. Too much magic. Remember the analogy is with the slice operator: lst[start:end]. Only integers work there, and only integers are acceptable to range() now, so it's simpler and happier all around to keep the range literals to just integers too. > Well the step argument is of debatable utility for strings but ["0":"9"] > seems mildly useful. Also, it makes sense to create a range of floating > point numbers. Not useful enough, i think, to be worth it. If you need to do a range check, you can still say "a" <= x <= "z". When working with ranges or regions on the number line, you probably want something more specifically designed for that. (For example, you might want to talk about open, closed, or half-open intervals.) If we're going to consider the feature, E's CoordinateSpaces and Regions are worth a serious look. Hmm. I don't have a good reference on that. I'll post one when i find it. -- ?!ng From Moshe Zadka Wed Jul 19 17:56:51 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 19 Jul 2000 19:56:51 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: Message-ID: On Wed, 19 Jul 2000, Ka-Ping Yee wrote: > On Wed, 19 Jul 2000, Barry A. Warsaw wrote: > > > > I've been thinking a little bit about the other generators, especially > > irange(). I wonder if we shouldn't just be putting zip() and friends > > in their own Python module and not make them builtins? > > I'd say put both zip() and irange() in builtins. They're useful enough. One of the things I love about Python is the clean namespaces. Each builtin function takes away some of the cleanliness. It's a tradeof, but I think we should be wary of tossing stuff into builtins just because we can't find a good place for them. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Fredrik Lundh" <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> <3975D2A1.5DDA10E6@prescod.net> Message-ID: <001801bff1a4$ed941a20$f2a6b5d4@hagrid> paul wrote: > If we're going to restrict people to ASCII-like encodings, we > could just restrict them to ASCII and get it over with. Sorry, you lost me there... in what part(s) of the source file should we restrict users to pure ASCII? (in string literals? unicode string literals? the entire script?) From peter@schneider-kamp.de Wed Jul 19 20:27:37 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 19:27:37 +0000 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> Message-ID: <39760129.9BA42B7E@schneider-kamp.de> Bjorn Pettersen wrote: > > I think the PEPs are a great idea, but it would be even better if they > were more accessible... How about putting them up on the beopen or > python.org site? (That way the faq can refer to them for recurring > discussions with all the arguments archived in the PEP...) How about putting them on sourceforge? python.sourceforge.net/peps/pep-0206.txt and friends What do you think? Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul@prescod.net Wed Jul 19 18:32:38 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 12:32:38 -0500 Subject: [Python-Dev] uPEP: encoding directive References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> <3975D2A1.5DDA10E6@prescod.net> <001801bff1a4$ed941a20$f2a6b5d4@hagrid> Message-ID: <3975E636.4FCF61ED@prescod.net> Fredrik Lundh wrote: > > paul wrote: > > If we're going to restrict people to ASCII-like encodings, we > > could just restrict them to ASCII and get it over with. > > Sorry, you lost me there... in what part(s) of the source file > should we restrict users to pure ASCII? > > (in string literals? unicode string literals? the entire script?) The entire script. If we're going to require a Japanse user to use 3 bytes to encode some character then we might as well require them to use backslash syntax. I mean if we're going to be revolutionary, then we could take the XML route. * require the encoding pragma to be the first line * auto-detect one-byte, two-byte based on #? * figure out precise encoding from directive Otherwise, I'm not sure if we're making enough progress. Westerners probably won't bother to put in the directive as long as their code works fine without it. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul@prescod.net Wed Jul 19 18:36:10 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 12:36:10 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: Message-ID: <3975E70A.F9F8BE42@prescod.net> Moshe Zadka wrote: > > ... > > One of the things I love about Python is the clean namespaces. Each > builtin function takes away some of the cleanliness. It's a tradeof, but I > think we should be wary of tossing stuff into builtins just because we > can't find a good place for them. I feel the same way, but I hate importing basic functionality necessary for every single script, no matter what the domain. I wish there weren't so many exceptions directly in builtins. They should go in a sub-module __builtins__.exceptions . -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From Fredrik Lundh" <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> Message-ID: <00b801bff1a9$248f4780$f2a6b5d4@hagrid> greg wrote: > > Yes, but it would by possible to use snprintf in PyErr_Format. >=20 > still not quite the same. /F's PyErr_Format returns an arbitrary = length > string. snprintf() would be cut at some pre-specified limit. if I understood GvR correctly, the only remaining issue here is whether we need more formatting codes (PyErr_Format is undocumented, so I'm not sure we need to be backwards compatible with code outside the interpreter...) in an earlier post, I suggested adding a couple of PyErr_Format- specific formatting codes: possibly stupid idea: would it make sense to add custom formatting codes, like: %S =3D> char*, string, clip if excessively long %T =3D> PyObject*, show name of type, clip if excessively long where "clip" means: truncate at 80 characters, and add "..." to indicate that the string was truncated. this covers most of the places where %.\d+s are used (in the Python core, at least...) comments? From bwarsaw@beopen.com Wed Jul 19 19:46:13 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 14:46:13 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> <3975D2C9.66FE16C2@prescod.net> Message-ID: <14709.63349.415183.336374@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Why are you using zip in this case? If you *know* that you are PP> going to get back 1-tuples then you must know that the input PP> is a single list (i.e. you aren't using "apply"). So why are PP> you using zip at all? It was just an example, but I agree, you probably wouldn't use zip in this situation. My question is, why would you ever use zip with one parameter? To me, that's an argument for letting zip(a) return 1-tuples, not raising an exception. -Barry From bwarsaw@beopen.com Wed Jul 19 19:48:20 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 14:48:20 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14709.10193.715558.561239@anthem.concentric.net> Message-ID: <14709.63476.37009.258626@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> (Ideally range(), zip(), and irange() would all make KY> generators one day, and xrange() could be deprecated.) I agree! So maybe what we need is a general generator type written in C. Could the xrange type be subverted to this purpose? -Barry From thomas@xs4all.net Wed Jul 19 20:13:06 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 21:13:06 +0200 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <39760129.9BA42B7E@schneider-kamp.de>; from peter@schneider-kamp.de on Wed, Jul 19, 2000 at 07:27:37PM +0000 References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> Message-ID: <20000719211306.F9897@xs4all.nl> On Wed, Jul 19, 2000 at 07:27:37PM +0000, Peter Schneider-Kamp wrote: > Bjorn Pettersen wrote: > > I think the PEPs are a great idea, but it would be even better if they > > were more accessible... How about putting them up on the beopen or > > python.org site? (That way the faq can refer to them for recurring > > discussions with all the arguments archived in the PEP...) > How about putting them on sourceforge? > python.sourceforge.net/peps/pep-0206.txt and friends +1 if we can do it automatically. +0 if it has to be done by whoever commits new versions ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Wed Jul 19 20:17:37 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 21:17:37 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.63476.37009.258626@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 19, 2000 at 02:48:20PM -0400 References: <14709.10193.715558.561239@anthem.concentric.net> <14709.63476.37009.258626@anthem.concentric.net> Message-ID: <20000719211736.G9897@xs4all.nl> On Wed, Jul 19, 2000 at 02:48:20PM -0400, Barry A. Warsaw wrote: > >>>>> "KY" == Ka-Ping Yee writes: > KY> (Ideally range(), zip(), and irange() would all make > KY> generators one day, and xrange() could be deprecated.) > I agree! So maybe what we need is a general generator type written in > C. Could the xrange type be subverted to this purpose? Not likely. You'd have to write the assignment functions (changing the object into a list-type if that is done) and most of the other stuff has to be rewritten: almost all of xrange() is specific for PyInt's. It stores step, start, end and repeater (for 'xrange * 10') as longs, and calculates return values for getitem and repr and the like from those. Other than a standard object boilerplate, it's pretty useless for more generic generators. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul@prescod.net Wed Jul 19 20:47:42 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 14:47:42 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> <3975D2C9.66FE16C2@prescod.net> <14709.63349.415183.336374@anthem.concentric.net> Message-ID: <397605DE.C0DF661C@prescod.net> Barry A. Warsaw" wrote: >... > > It was just an example, but I agree, you probably wouldn't use zip in > this situation. My question is, why would you ever use zip with one > parameter? To me, that's an argument for letting zip(a) return > 1-tuples, not raising an exception. Your logic is impeccable. Also, consider this: zip( "mybigfile.xml" ) -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From bwarsaw@beopen.com Wed Jul 19 21:12:57 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 16:12:57 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14709.10193.715558.561239@anthem.concentric.net> <14709.63476.37009.258626@anthem.concentric.net> <20000719211736.G9897@xs4all.nl> Message-ID: <14710.3017.560649.169558@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> Other than a standard object boilerplate, it's pretty useless TW> for more generic generators. Urg. Oh well. From bwarsaw@beopen.com Wed Jul 19 21:14:59 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 16:14:59 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> <3975D2C9.66FE16C2@prescod.net> <14709.63349.415183.336374@anthem.concentric.net> <397605DE.C0DF661C@prescod.net> Message-ID: <14710.3139.869652.473413@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> zip( "mybigfile.xml" ) Newbie: "Why doesn't this compress my file for me?" Paul: "!" :) -Barry From thomas@xs4all.net Wed Jul 19 21:24:08 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 22:24:08 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <397605DE.C0DF661C@prescod.net>; from paul@prescod.net on Wed, Jul 19, 2000 at 02:47:42PM -0500 References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> <3975D2C9.66FE16C2@prescod.net> <14709.63349.415183.336374@anthem.concentric.net> <397605DE.C0DF661C@prescod.net> Message-ID: <20000719222408.L9897@xs4all.nl> On Wed, Jul 19, 2000 at 02:47:42PM -0500, Paul Prescod wrote: > Also, consider this: > zip( "mybigfile.xml" ) That's kinda like 'dir()', isn't it ? "I don't have those files in my directory!!?" Nevertheless, yet another reason to use marry() No confusion there! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Moshe Zadka Wed Jul 19 21:40:16 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 19 Jul 2000 23:40:16 +0300 (IDT) Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) In-Reply-To: <00b801bff1a9$248f4780$f2a6b5d4@hagrid> Message-ID: On Wed, 19 Jul 2000, Fredrik Lundh wrote: > possibly stupid idea: would it make sense to add custom > formatting codes, like: > > %S => char*, string, clip if excessively long > %T => PyObject*, show name of type, clip if excessively long > > where "clip" means: > > truncate at 80 characters, and add "..." to indicate > that the string was truncated. I'm +0 on those. Seems like useful things. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Moshe Zadka Wed Jul 19 21:47:41 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 19 Jul 2000 23:47:41 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.63349.415183.336374@anthem.concentric.net> Message-ID: On Wed, 19 Jul 2000, Barry A. Warsaw wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> Why are you using zip in this case? If you *know* that you are > PP> going to get back 1-tuples then you must know that the input > PP> is a single list (i.e. you aren't using "apply"). So why are > PP> you using zip at all? > > It was just an example, but I agree, you probably wouldn't use zip in > this situation. My question is, why would you ever use zip with one > parameter? Or, in other words, anyone using zip() with one parameter is plain nuts or made a bug. > To me, that's an argument for letting zip(a) return > 1-tuples, not raising an exception. I fail to see the logic. To me, that points at the exception route: if it's probably a bug, yell loudly. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas@xs4all.net Wed Jul 19 21:49:55 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 22:49:55 +0200 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) In-Reply-To: <00b801bff1a9$248f4780$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jul 19, 2000 at 07:45:23PM +0200 References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> Message-ID: <20000719224955.M9897@xs4all.nl> On Wed, Jul 19, 2000 at 07:45:23PM +0200, Fredrik Lundh wrote: > possibly stupid idea: would it make sense to add custom > formatting codes, like: > > %S => char*, string, clip if excessively long > %T => PyObject*, show name of type, clip if excessively long > > where "clip" means: > > truncate at 80 characters, and add "..." to indicate > that the string was truncated. > > this covers most of the places where %.\d+s are used (in > the Python core, at least...) +0, but I haven't enough experience with this kind of thing to have a real opinion. I guess it's better than nothing ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw@beopen.com Wed Jul 19 22:10:34 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 17:10:34 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14709.63349.415183.336374@anthem.concentric.net> Message-ID: <14710.6474.635823.308717@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I fail to see the logic. To me, that points at the exception MZ> route: if it's probably a bug, yell loudly. Hmm, thinking about the ambiguity your brought up with zip-with-no-args, which I agree with more than zip-with-one-arg, I might be willing to concede the exception for anything less than 2 sequences provided. At the very least, I will work this into the PEP so Guido can rule by (informed) decree. -Barry From jack@oratrix.nl Wed Jul 19 23:03:19 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 20 Jul 2000 00:03:19 +0200 Subject: [Python-Dev] PyArg_ParseTuple format specifiers again Message-ID: <20000719220324.73E3E191AA8@oratrix.oratrix.nl> Of course, after I added the H specifier to PyArg_ParseTuple it turns out that solved ninetysomething% of my problems, but it turns out that what I really need is not an "unsigned short" converter but a "16 bit" converter, i.e. something that will happily accept anything from -32768 to 65535 without complaints. (The old "h" format, in other words). I need this because all the MacOS API modules are machine generated, both the C modules and the .py files with all the constants in it, and some header file authors use -1 to mean "16 1 bits", some use 0xffff. And I really don't want to hand-massage 40K lines of C and 6K lines of Python everytime a new MacOS release comes out.... And I also need such a format char for 8 bit values. Does anyone mind if I change the H specifier to do no value checking other than making sure it fits in 16 bits, and add a B specifier for unchecked bytes? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From paul@prescod.net Wed Jul 19 23:53:42 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 17:53:42 -0500 Subject: [Python-Dev] Perl rewrite Message-ID: <39763176.47254BEF@prescod.net> Interesting.... http://www.perl.org/ http://slashdot.org/article.pl?sid=00/07/19/203221&mode=nested -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From petrilli@amber.org Thu Jul 20 01:41:58 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Wed, 19 Jul 2000 20:41:58 -0400 Subject: [Python-Dev] Perl rewrite In-Reply-To: <39763176.47254BEF@prescod.net>; from paul@prescod.net on Wed, Jul 19, 2000 at 05:53:42PM -0500 References: <39763176.47254BEF@prescod.net> Message-ID: <20000719204158.A20244@trump.amber.org> Paul Prescod [paul@prescod.net] wrote: > Interesting.... > > http://www.perl.org/ > http://slashdot.org/article.pl?sid=00/07/19/203221&mode=nested I must say that Larry Wall's "keynote" was um... interesting. :-) Perhaps Guido will summarize it :-) Chris -- | Christopher Petrilli | petrilli@amber.org From paul@prescod.net Thu Jul 20 02:06:47 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 20:06:47 -0500 Subject: [Python-Dev] Perl rewrite References: <39763176.47254BEF@prescod.net> <20000719204158.A20244@trump.amber.org> Message-ID: <397650A7.9A32E3B@prescod.net> Christopher Petrilli wrote: > >... > > I must say that Larry Wall's "keynote" was um... interesting. :-) > Perhaps Guido will summarize it :-) Then we'll have to wait a week! What are the high points? -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From petrilli@amber.org Thu Jul 20 07:20:06 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Thu, 20 Jul 2000 02:20:06 -0400 Subject: [Python-Dev] Perl rewrite In-Reply-To: <397650A7.9A32E3B@prescod.net>; from paul@prescod.net on Wed, Jul 19, 2000 at 08:06:47PM -0500 References: <39763176.47254BEF@prescod.net> <20000719204158.A20244@trump.amber.org> <397650A7.9A32E3B@prescod.net> Message-ID: <20000720022005.B20244@trump.amber.org> Paul Prescod [paul@prescod.net] wrote: > Christopher Petrilli wrote: > > > >... > > > > I must say that Larry Wall's "keynote" was um... interesting. :-) > > Perhaps Guido will summarize it :-) > > Then we'll have to wait a week! What are the high points? He knows how to snap, and beat sticks together... :-) Chris -- | Christopher Petrilli | petrilli@amber.org From paul@prescod.net Thu Jul 20 07:35:28 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 01:35:28 -0500 Subject: [Python-Dev] PEP-able Message-ID: <39769DB0.BCE7FB38@prescod.net> PEP: ??? Title: Computed Attributes Version: $Revision: 1.0 $ Owner: paul@prescod.net Python-Version: 2.0 Status: Incomplete Introduction This PEP describes a feature to make it easier to use Python attribute set/get/del syntax to fetch the results of a computation or to invoke computation. This feature has been emulated using __getattr__/__setattr__/__delattr__ but this approach suffers severe usability and performance concerns. Syntax Special methods should declare themselves with declarations of the following form: class x: def __get_foo__(self ): ... def __set_foo__(self, value ): ... def __del_foo__(self ): ... They are used like this: fooval=x.foo x.foo=fooval+5 del x.foo Semantics References of the sort x.y should be taken, if x is an instance type of a class with a __get_y__ method as being equivalent to a call to that method. Code that assigns to y should instead call __set_y__ if that method is defined on x's class. Code that deletes x.y should call __del_y__ if that method is defined on x's class. It is disallowed to actually have an attribute named y in the dictionary for reasons that will become clear when we discuss the implementation. It is not required that every special method have two more matching special methods. If one is declared then the other two operations are effectively prohibited and will raise an exception. This is an easy way to make read-only (or even write-only or delete-only) attributes. An implementation of __get_y__ takes precedence over an implementation of __getattr__ based on the principle that __getattr__ is supposed to be invoked only after finding an appropriate attribute has failed. This is important for acceptable performance. An implementation of __set_y__ takes precedence over an implementation of __setattr__ in order to be consistent. The opposite choice seems fairly feasible also, however. The same goes for __del_y__. Proposed Implementation There is a new object called a computed attribute object. It has three attributes: get, set, delete. In PyClass_New, methods of the appropriate form will be detected and converted into objects (just like unbound method objects). Matching methods go in the same computed attribute object and missing methods are replaced with a stub that throws the TypeError. If there are any computed attributes at all, a flag is set. Let's call it "I_have_computed_attributes" for now. A get proceeds as usual until just before the object is returned. In addition to the current check whether the returned object is a method it would also check whether a returned object is a computed attribute. If so, it would invoke the getter method and return the value. To remove a computed attribute object you could directly fiddle with the dictionary. A set proceeds by checking the "I_have_computed_attributes" flag. If it is not set, everything proceeds as it does today. If it is set then we must do a dictionary get on the requested object name. If it returns a computed method attribute then we call the setter function with the value. If it returns any other object then we discard the result and continue as we do today. The I_have_computed_attributes flag is intended to eliminate the performance degradation of an extra "get" per "set" for objects not using this feature. You might note that I have not proposed any logic to keep this flag up to date as attributes are added and removed from the instance's dictionary. This is consistent with current Python. If you add a __setattr__ method to an object after it is in use, that method will not behave as it would if it were available at "compile" time. The implementation of delete is analogous to the implementation of set. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul@prescod.net Thu Jul 20 07:51:33 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 01:51:33 -0500 Subject: [Python-Dev] Consistency questions Message-ID: <3976A175.12D4DB53@prescod.net> #1. Why does can I overwrite the "standard output object" with assignment syntax sys.stdout=mystdoutobj But I have to add a profile function with function syntax: sys.setprofile( myprofilefunc ) #2. Why doesn't dir( obj ) return inherited methods? -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From peter@schneider-kamp.de Thu Jul 20 09:53:11 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 20 Jul 2000 08:53:11 +0000 Subject: [Python-Dev] questionnaire about zip and for loops Message-ID: <3976BDF7.82FB6C56@schneider-kamp.de> This is a slightly reduced version of a questionnaire run by Greg Wilson on some CS grad students. I'd like to use the readers of comp.lang.python as guinea pigs this time. PLEASE SEND THE RESULTS TO mailto:peter@schneider-kamp.de - DON'T SEND THEM TO THE LIST Thanks for your time, Peter ----------------------------------------------------------------------------------------- The single and double loop below print the output shown: for x in [10, 20, 30]: for x in [10, 20, 30]: print x for y in [1, 2, 3]: print x+y 10 11 20 12 30 13 21 22 23 31 32 33 Match each of the following example for-loops to an output. Only make one cross per line. Please consider each example on its own. (Note that several examples may print the same thing.) (1) (2) (3) (4) (5) (6) 11 11 11 11 error ?? 22 12 22 12 33 13 21 21 22 22 31 23 32 31 32 33 (A) for (x, y) in [[10, 1], [20, 2], [30, 3]]: o o o o o o print x+y (B) for [x, y] in zip([10, 20, 30], [1, 2, 3]): o o o o o o print x+y (C) for [x, y] in zip([10, 20, 30], [1, 2]): o o o o o o print x+y (D) for x; y in [10, 20, 30]; [1, 2, 3]: o o o o o o print x+y (E) for x; y in [10, 20, 30]; [1, 2]: o o o o o o print x+y (F) for x in [10, 20, 30]; y in [1, 2, 3]: o o o o o o print x+y (G) for x in [10, 20, 30]; y in [1, 2]: o o o o o o print x+y -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mwh21@cam.ac.uk Thu Jul 20 08:00:26 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 20 Jul 2000 08:00:26 +0100 Subject: [Python-Dev] PEP-able In-Reply-To: Paul Prescod's message of "Thu, 20 Jul 2000 01:35:28 -0500" References: <39769DB0.BCE7FB38@prescod.net> Message-ID: Paul Prescod writes: > PEP: ??? > Title: Computed Attributes > Version: $Revision: 1.0 $ > Owner: paul@prescod.net > Python-Version: 2.0 > Status: Incomplete +1! (you beat me to it...) M. -- On the other hand, the following areas are subject to boycott in reaction to the rampant impurity of design or execution, as determined after a period of study, in no particular order: ... http://www.naggum.no/profile.html From peter@schneider-kamp.de Thu Jul 20 10:44:31 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 20 Jul 2000 09:44:31 +0000 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> Message-ID: <3976C9FF.A7799738@schneider-kamp.de> Thomas Wouters wrote: > > On Wed, Jul 19, 2000 at 07:27:37PM +0000, Peter Schneider-Kamp wrote: > > > > How about putting them on sourceforge? > > python.sourceforge.net/peps/pep-0206.txt and friends > > +1 if we can do it automatically. +0 if it has to be done by whoever commits > new versions ;) I can do it (and keep up with the changes) for now. But in the long run this probably should be automated. I only see the password barrier: scp pep-*.txt nowonder@shell.sourceforge.net:/home/groups/python/htdocs/peps will make me enter my password/passphrase. How would one go about doing something like that? One "solution" I can think of is to checkout a copy of nondist/peps from the CVS to htdocs/peps. Then the peps could be held up to date by running cvs up in that directory once a day (or 4 times a day). But this would require some action of SF to add it to their cron, wouldn't it?! Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From thomas@xs4all.net Thu Jul 20 09:35:46 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 10:35:46 +0200 Subject: [Python-Dev] Consistency questions In-Reply-To: <3976A175.12D4DB53@prescod.net>; from paul@prescod.net on Thu, Jul 20, 2000 at 01:51:33AM -0500 References: <3976A175.12D4DB53@prescod.net> Message-ID: <20000720103546.N9897@xs4all.nl> On Thu, Jul 20, 2000 at 01:51:33AM -0500, Paul Prescod wrote: > #1. Why does can I overwrite the "standard output object" with > assignment syntax > sys.stdout=mystdoutobj > But I have to add a profile function with function syntax: > sys.setprofile( myprofilefunc ) There is a slight difference in semantics: sys.stdout is occasionally read by a function or stmt that wants to write to stdout. Changing it doesn't actually change something in the interpreter. sys.setprofile(), however, has to change something in the current threadstate. It's not something that's read from the sys module every time it's used, but rather an accompanying variable that has to be set as well. > #2. Why doesn't dir( obj ) return inherited methods? Because inherited methods (and other inherited attributes) aren't stored in an instance's __dict__. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm@hypernet.com Thu Jul 20 14:43:33 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 20 Jul 2000 09:43:33 -0400 Subject: [Python-Dev] PEP-able In-Reply-To: <39769DB0.BCE7FB38@prescod.net> Message-ID: <1248021882-9357610@hypernet.com> Paul Prescod wrote: [Title: Computed Attributes] > Semantics > It is disallowed to actually have an attribute named y in the > dictionary for reasons that will become clear when we discuss > the implementation. What happens here (and when): class A: y = None class B(A): def __XXX_y__(self): ... > An implementation of __get_y__ takes precedence over an > implementation of __getattr__ based on the principle that > __getattr__ is supposed to be invoked only after finding an > appropriate attribute has failed. This is important for > acceptable performance. Hmmm. Current Python: search for y fails, try __getattr__. Proposed: search for y fails, try the __get_y__, then __getattr__. We've still done the same work before trying the hook, so how is performance affected? Or are you proposing to try the hook first, thus improving performance for hooked attributes at the price of degrading performance for all non- hooked attributes? > Proposed Implementation > > There is a new object called a computed attribute object. It > has three attributes: get, set, delete. In PyClass_New, > methods of the appropriate form will be detected and > converted into objects (just like unbound method objects). > Matching methods go in the same computed attribute object and > missing methods are replaced with a stub that throws the > TypeError. If there are any computed attributes at all, a > flag is set. Let's call it "I_have_computed_attributes" for > now. class A: def __get_y__(self): ... class B(A): def __set_y__(self, value): .... Notice a problem here? Is it B's author's intent to make a read- only attribute read-write (in which case the accessor object probably needs to get copied from A.__dict__ to B.__dict__ so as not to interfere with other derived classes)? Or do we assume he wants to make it write-only, and to make it read- write does he need to do: class B(A): def __set_y__(self, value): .... def __get_y__(self): return A.__get_y__(self) (which involves another wrinkle, because there is no attribute "__get_y__" in class A). - Gordon From skip@mojam.com (Skip Montanaro) Thu Jul 20 15:12:02 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 20 Jul 2000 09:12:02 -0500 (CDT) Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <3976C9FF.A7799738@schneider-kamp.de> References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> Message-ID: <14711.2226.242735.766934@beluga.mojam.com> Peter> But in the long run this probably should be automated. I only see Peter> the password barrier: Peter> scp pep-*.txt nowonder@shell.sourceforge.net:/home/groups/python/htdocs/peps Peter> will make me enter my password/passphrase. Peter> How would one go about doing something like that? Assuming you are running on some Unix flavor, use ssh-agent to start your X session: ssh-agent startx and in your .xinitrc file (or equivalent) execute ssh-add References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> Message-ID: <14711.2370.880455.337906@beluga.mojam.com> >> #2. Why doesn't dir( obj ) return inherited methods? Thomas> Because inherited methods (and other inherited attributes) Thomas> aren't stored in an instance's __dict__. dir() *could* be smarter and walk up the chain starting at __class__ looking for useful stuff to include. Unfortunately, dir() is written in C so it's harder to modify than it ought to be... Skip From guido@beopen.com Thu Jul 20 15:52:00 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 20 Jul 2000 07:52:00 -0700 Subject: [Python-Dev] Fw: CVS commit backout trivia Message-ID: <008601bff25a$0f770520$3e2c4fce@beopen.com> I haven't tried the suggestion below but seems like a good idea, and could be added to our SF FAQ... --Guido ----- Original Message ----- From: "Mitchell Morris" To: Sent: Wednesday, July 19, 2000 3:52 PM Subject: CVS commit backout trivia > I was reading through the python-dev archives today and saw a message from > you dated 2000-07-10 about backing out a CVS commit with "cvs admin -o" and > wanted to point out that there is a more history-friendly mechanism: "cvs > update -j -j filename". The update > command will apply the diffs between and in reverse > order. That way you don't branch or set sticky tags that have to be cleaned > up after. > > hoping-this-is-of-some-miniscule-help-ly y'rs > +Mitchell From paul@prescod.net Thu Jul 20 16:12:38 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 10:12:38 -0500 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> Message-ID: <397716E6.F19E25BE@prescod.net> Gordon McMillan wrote: > > What happens here (and when): > class A: > y = None > class B(A): > def __XXX_y__(self): > ... I would say that the latter would just take precedence over the former as if you had typed: class B(A): __XXX_y__=ComputedAttribute( foo, bar, baz ) > Hmmm. Current Python: search for y fails, try __getattr__. > Proposed: search for y fails, try the __get_y__, then > __getattr__. We've still done the same work before trying the > hook, so how is performance affected? Actually, I was justifying Python's current behavior as much as I was the current behavior. A truly general __getattr__ would access all attribute tests, not just non-existent attributes and thus be symmetric with setattr. But that would also be slow as hell. > class A: > def __get_y__(self): > ... > class B(A): > def __set_y__(self, value): > .... My first instinct is just to disallow this and figure it out after we have some more usage information/implementation resources. We could just say that all methods must be defined in the same class and if not. In other words, the methods "shadow each other" as a group. This is no more messy than inherited __getattr__ s. My second thought is to have the constructor for computed attributes objects look for a computed attribute higher in the tree and copy in the appropriate fields. Prohibiting it might be clearest for all concerned. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From thomas@xs4all.net Thu Jul 20 16:21:08 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 17:21:08 +0200 Subject: [Python-Dev] Consistency questions In-Reply-To: <14711.2370.880455.337906@beluga.mojam.com>; from skip@mojam.com on Thu, Jul 20, 2000 at 09:14:26AM -0500 References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> Message-ID: <20000720172108.S9897@xs4all.nl> On Thu, Jul 20, 2000 at 09:14:26AM -0500, Skip Montanaro wrote: > >> #2. Why doesn't dir( obj ) return inherited methods? > Thomas> Because inherited methods (and other inherited attributes) > Thomas> aren't stored in an instance's __dict__. > dir() *could* be smarter and walk up the chain starting at __class__ looking > for useful stuff to include. Unfortunately, dir() is written in C so it's > harder to modify than it ought to be... I would suggest adding a second, optional argument to dir(), 'recurse' or such, to add that behaviour. I think I can add that code to dir() if it's deemed a good idea ;) Turning it on by default would probably break too much code. Opinions ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From trentm@ActiveState.com Thu Jul 20 16:29:37 2000 From: trentm@ActiveState.com (Trent Mick) Date: Thu, 20 Jul 2000 08:29:37 -0700 Subject: [Python-Dev] PyArg_ParseTuple format specifiers again In-Reply-To: <20000719220324.73E3E191AA8@oratrix.oratrix.nl> References: <20000719220324.73E3E191AA8@oratrix.oratrix.nl> Message-ID: <20000720082937.A22151@ActiveState.com> On Thu, Jul 20, 2000 at 12:03:19AM +0200, Jack Jansen wrote: > Of course, after I added the H specifier to PyArg_ParseTuple it turns > out that solved ninetysomething% of my problems, but it turns out that > what I really need is not an "unsigned short" converter but a "16 bit" > converter, i.e. something that will happily accept anything from > -32768 to 65535 without complaints. (The old "h" format, in other > words). > That is too bad that the unsigned OR signed decision could not be made. > I need this because all the MacOS API modules are machine generated, > both the C modules and the .py files with all the constants in it, and > some header file authors use -1 to mean "16 1 bits", some use > 0xffff. And I really don't want to hand-massage 40K lines of C and 6K > lines of Python everytime a new MacOS release comes out.... Very fair. > > And I also need such a format char for 8 bit values. > > Does anyone mind if I change the H specifier to do no value checking > other than making sure it fits in 16 bits, and add a B specifier for > unchecked bytes? Now I think that the best answer is to have a separate PyArg_UncheckedParseTuple() that gives you what you want Jack. Or, maybe more easily, PyArg_ParseTuple could revert to the 1.5.2 form and not do bounds checking and a new PyArg_CheckedParseTuple could do bounds checking. Actually, yes, the latter is a better idea. It would allow us to clean up the L as unsigned long rather than LONG_LONG issue if we wanted. Thereafter PyArg_CheckedParseTuple would be the preferred method if possible. Hence, PyArg_ParseTuple(): b - byte h - short i - int l - long L - LONG_LONG Pros: - This is as in 1.5.2. All the values are either not bounds checked at all or (maybe a little better) checked to be within [XXX_MIN, UXXX_MAX], i.e. in the range of the union of the signed and unsigned ranges. This will be backward compatible and only break code that had an overflow bug in it anyway. - It should make Jack happy, except that he would now have to go change all his 'H's back to 'h's. :( PyArg_CheckedParseTuple(): b - signed byte B - unsigned byte h - signed short H - unsigned short i - signed int I - unsigned int l - signed long L - unsigned long q - signed LONG_LONG Q - unsigned LONG_LONG Pros: - b,h,i,l and the capital equivs are the same as the formatters in the struct module for consistency - the use of capital for unsigned version of all the variables is intuitive (or at least straight forward and consistent) - q,Q for a 'quad' or long long is better than the current 'L' Cons: - New function may raise questions of "which do I use PyArg_ParseTuple or PyArg_CheckedParseTuple?" This is a documentation issue. - New function may require parallel maintenance in both functions. Or maybe not if one is made to use the other (efficiency prob?) - 'L' has changed meaning from one function to the other. I would propose just leaving is as is for 2.0 (unless the code breakage is okay) and then change 'L' in PyArg_ParseTuple to mean 'unsigned long' in Py3k. I can code this up after the O'Reilly conference if people (Jack, Guido, Tim, others?) think that this is a good idea. Trent -- Trent Mick TrentM@ActiveState.com From mal@lemburg.com Thu Jul 20 16:33:54 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 17:33:54 +0200 Subject: [Python-Dev] Will Python die? References: <3974808D.5D49575D@schneider-kamp.de> Message-ID: <39771BE2.A80ADD92@lemburg.com> Peter Schneider-Kamp wrote: > > Moshe Zadka wrote: > > > > My fault -- I stopped reading /. Can you summarize the thread? > > The thread is about if Visual Python is an alternative for > Visual Basic or, if not, it can be used as that. > > A subthread of this thread dealt with Pythons release schedule: > "Speaking of Python, does anyone know what's up with Python 1.6^H^H2.0? > A while back, python.org had said that version 1.6 would be out on > June 1. Then there was an announcement, mid-June that it would be > delayed. Then at the end of June, this link was placed on python.org, > and it was stated that the Python interpreter, version 1.6, was > renamed to 2.0, and the first beta would be available on July 1. Now, > on July 17, that link has been removed from python.org (although the > webpage still exists), and the release schedule is gone!" > > Quoting from relevant replies: > "python 1.6 will be out in august > check the downloads page of www.python.org > or checkout the pythonlabs at www.beopen.com > where most of the core python developers opened shop" > > "Yeah, the Python 1.6 download page says that Python 1.6 beta1 will be > done on July 1, and beta 2 on July 14. It's July 17 now, and the only > available download is alpha 2...." You may not have noticed, but the 2.0beta1 is already available to the public: just download the most recent CVS version (or the tarball from David Ascher's starship page). About the schedule: I think we'll know more after the Python Consortium Meeting. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 20 16:37:50 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 17:37:50 +0200 Subject: [Python-Dev] map() for methods References: <20000718130059.B7340@xs4all.nl> <14708.40190.852802.966575@beluga.mojam.com> Message-ID: <39771CCE.F70A48D4@lemburg.com> Skip Montanaro wrote: > > Moshe> In fact, putting an implementation of pad() like that in the > Moshe> string.py module would be wonderful, because it would work with > Moshe> both regular strings and unicode. However, string.py is looking > Moshe> as though as it's going to be deprecated. In short, I'd want > Moshe> Guido/Tim/effbot/MAL opinions here before we make a move. > > Don't know about the powers that be, but I don't see how you can > realistically deprecate string.py until you deprecate map(). My most > frequent use of map() is the simple > > newlist = map(string.strip, oldlist) > > where oldlist is a list of strings. (Replace "strip" by "upper", "lower", > etc, depending on your needs.) > > As far as I'm aware, there's no clean way to do that with string methods. True, we'll need somthing like this for methods too... e.g. like the following API in mx.Tools: method_mapply(objects,methodname[,args=(),kw={}]) Creates a tuple of values by applying the given arguments to each object's method. The objects are processed as given in the sequence objects. A simple application is e.g. method_mapply([a,b,c],'method', (x,y)) resulting in a tuple (a.method(x,y), b.method(x,y), c.method(x,y)). Thanks to Aaron Waters for suggesting this function. The name is clumsy... suggestions welcome :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 20 16:49:20 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 17:49:20 +0200 Subject: [Python-Dev] Coercion (RE: Discussion: Introducing new operators for matrix computation) References: Message-ID: <39771F80.90DD0C99@lemburg.com> [Adding new operators] Just a side note before everyone forgets: I think we'll need to carefully redefine coercion *before* adding any new slots/operators/etc. to Python. The current model where coercion is centralized won't scale well with the new operators. My (old) proposal for this (see my Python Pages) was to decentralize coercion and make the coercion process part of the operators task. Thoughts ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip@mojam.com (Skip Montanaro) Thu Jul 20 16:50:58 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 20 Jul 2000 10:50:58 -0500 (CDT) Subject: [Python-Dev] Consistency questions In-Reply-To: <20000720172108.S9897@xs4all.nl> References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> <20000720172108.S9897@xs4all.nl> Message-ID: <14711.8162.800169.884936@beluga.mojam.com> Thomas> I would suggest adding a second, optional argument to dir(), Thomas> 'recurse' or such, to add that behaviour. I think I can add that Thomas> code to dir() if it's deemed a good idea ;) Turning it on by Thomas> default would probably break too much code. I don't think so. I suspect most people use dir() interactively to see what attributes an object supports and would appreciate the improved functionality. Besides, we are talking 2.0 here. Nothing wrong with a little breakage... ;-) Skip From jack@oratrix.nl Thu Jul 20 16:51:39 2000 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 20 Jul 2000 17:51:39 +0200 Subject: [Python-Dev] PyArg_ParseTuple format specifiers again In-Reply-To: Message by Trent Mick , Thu, 20 Jul 2000 08:29:37 -0700 , <20000720082937.A22151@ActiveState.com> Message-ID: <20000720155140.73BA837186E@snelboot.oratrix.nl> Hmm. I think that having separate PyArg_ParseTuple and PyArg_UncheckedParseTuple is absolute overkill. Also, I think the functionality of having the checks is a fine one, I was at the time grumbling about it being a backward-incompatible change, and moreover one that caused me a lot of work at a time that I had more than enough other things to do. But now that the work is done I see no reason to revert it. If we'd want to do a complete set of arguments for each of 8, 16 and 32 bit integers we would have 3 specifiers: signed, unsigned and bitpattern. As it stands now we have: signed unsign bitpattern 8bit - b - 16bit h H - 32bit - - l (note the last one: 32bit values are in essence not checked because the parser happily stuffs 0xffffffff into a long). What I would be happy with is to have "natural" (unsigned for char, signed for other types) and bitpattern, so natural bitpattern 8bit b B 16bit h H 32bit l L I agree about breaking L: it's there but in the standard distribution it isn't used a single time. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From mal@lemburg.com Thu Jul 20 16:58:39 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 17:58:39 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <14709.10193.715558.561239@anthem.concentric.net> <20000718235317.A7561@lyra.org> Message-ID: <397721AF.9F6D023E@lemburg.com> Greg Stein wrote: > > On Wed, Jul 19, 2000 at 12:00:17AM -0400, Barry A. Warsaw wrote: > > >>>>> "MZ" == Moshe Zadka writes: > > > > MZ> I'm +1 on that. One thing that bugs me is that we're adding a > > MZ> builtin type. Why not stick with the Python implementation? > > > > I've been thinking a little bit about the other generators, especially > > irange(). I wonder if we shouldn't just be putting zip() and friends > > in their own Python module and not make them builtins? > > Which are you proposing: > > 1) implement in a Python module. clients use some_module.zip() > 2) implement in a Python module. insert into builtins. clients use zip(). FYI, mx.Tools implements 1) + 2). I usually put the "rom mx.Tools import NewBuiltins" at the top of the module source file so that it becomes clear that the module uses the set of new builtins available through mx.Tools. YMMV. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 20 17:07:11 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 18:07:11 +0200 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> Message-ID: <397723AF.4B11379A@lemburg.com> Fredrik Lundh wrote: > > greg wrote: > > > > Yes, but it would by possible to use snprintf in PyErr_Format. > > > > still not quite the same. /F's PyErr_Format returns an arbitrary length > > string. snprintf() would be cut at some pre-specified limit. > > if I understood GvR correctly, the only remaining issue here > is whether we need more formatting codes > > (PyErr_Format is undocumented, so I'm not sure we need to > be backwards compatible with code outside the interpreter...) > > comments? How about this: You add your new PyErr_Format() replacement with the existing subset of codes, but instead of bailing out when the function sees a format code it doesn't understand, you use sprintf() or snprintf() (where available) to format the unkown code ?! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Donald Beaudry Thu Jul 20 17:11:38 2000 From: Donald Beaudry (Donald Beaudry) Date: Thu, 20 Jul 2000 12:11:38 -0400 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> <397716E6.F19E25BE@prescod.net> Message-ID: <200007201611.MAA26587@zippy.init.com> Paul Prescod wrote, > My first instinct is just to disallow this and figure it out after > we have some more usage information/implementation resources. We > could just say that all methods must be defined in the same class > and if not. In other words, the methods "shadow each other" as a > group. One way of doing that, which I feel also makes things a bit more obvious, is to allow only a single routine per attribute: __attr_XXX__. Here's an example: def __attr_foo__(self, op, value=None): if op is 'get': return self.compute() elif op is 'set': self.adjust(value) else: self.do_the_del_thing() String interning makes the op tests quite fast. > My second thought is to have the constructor for computed attributes > objects look for a computed attribute higher in the tree and copy in > the appropriate fields. That sounds fragile and would create "book keeping" problems if maintaining the current level of dynamic attribute magic is desired. > Prohibiting it might be clearest for all concerned. I agree that prohibiting it is the right idea. The question is how. Permitting only one routine per attribute lets the traditional attribute lookup rules work and thus prevents head scratching when trying to find the code that actually maintains an attribute. The cost is some additional burden on the writer of the __attr_XXX method (and some magic to distinguish the del case). -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb@init.com Lexington, MA 02421 ...Will hack for sushi... From peter@schneider-kamp.de Thu Jul 20 19:51:21 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 20 Jul 2000 18:51:21 +0000 Subject: [Python-Dev] PEPs on the web Message-ID: <39774A29.86E469BB@schneider-kamp.de> I have put up the PEPs on http://python.sourceforge.net/peps/ Three questions remain: 1) Is that okay? No one cried out aloud and I got some agreement. 2) Should I put a link from http://python.sourceforge.net ? 3) What about making those PEPs xhtml (or something like that)? Pros: - links from pep-000.txt - links from the other peps Cons: - harder to read in checkins - harder to edit (maybe we could use as little markup as possible?) Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gmcm@hypernet.com Thu Jul 20 18:03:13 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 20 Jul 2000 13:03:13 -0400 Subject: [Python-Dev] Consistency questions In-Reply-To: <14711.8162.800169.884936@beluga.mojam.com> References: <20000720172108.S9897@xs4all.nl> Message-ID: <1248009902-10078204@hypernet.com> Skip Montanaro wrote: > > Thomas> I would suggest adding a second, optional argument to > dir(), Thomas> 'recurse' or such, to add that behaviour. I > think I can add that Thomas> code to dir() if it's deemed a > good idea ;) Turning it on by Thomas> default would probably > break too much code. > > I don't think so. I suspect most people use dir() interactively > to see what attributes an object supports and would appreciate > the improved functionality. Besides, we are talking 2.0 here. > Nothing wrong with a little breakage... ;-) In the std lib: cmd.py (already looks in __class__ and __bases__), rlcompleter (doesn't), rexec (only invoked on modules?). It seems a gratuitous breakage, since it's additional behavior, not fixed behavior. - Gordon From gmcm@hypernet.com Thu Jul 20 18:03:13 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 20 Jul 2000 13:03:13 -0400 Subject: [Python-Dev] Computed-attributes In-Reply-To: <397716E6.F19E25BE@prescod.net> Message-ID: <1248009900-10078307@hypernet.com> Paul Prescod wrote: > Gordon McMillan wrote: > > > > What happens here (and when): > > class A: > > y = None > > class B(A): > > def __XXX_y__(self): > > ... > > I would say that the latter would just take precedence over the > former as if you had typed: > > class B(A): > __XXX_y__=ComputedAttribute( foo, bar, baz ) OK. I gather that the ComputedAttribute is actually named after the attribute. So in this situation, "y" is found in B.__dict__, and is a ComputedAttribute which hides A's (normal) attribute. Then: class A: def __init__(self): self.y = class B(A): def __set_y__(self, value): ... def __init__(self): A.__init__(self) means that the hook in B will be invoked when A.__init__ runs. I wonder what "gotchas" lie in wait ;-). > > Hmmm. Current Python: search for y fails, try __getattr__. > > Proposed: search for y fails, try the __get_y__, then > > __getattr__. We've still done the same work before trying the > > hook, so how is performance affected? I hadn't realized when I wrote that that the ComputedAttribute would have the attribute's name. That does make getattr faster. But: > Actually, I was justifying Python's current behavior as much as I > was the current behavior. A truly general __getattr__ would > access all attribute tests, not just non-existent attributes and > thus be symmetric with setattr. But that would also be slow as > hell. I use __getattr__ most often to do lazy evaluation. So: def __getattr__(self, nm): if nm == 'doohickies': rslt = self.doohickies = return rslt Yes, you can do this either way, but I rather like the fact that it's a last resort hook. > > class A: > > def __get_y__(self): > > ... > > class B(A): > > def __set_y__(self, value): > > .... > > My first instinct is just to disallow this and figure it out > after we have some more usage information/implementation > resources. We could just say that all methods must be defined in > the same class and if not. In other words, the methods "shadow > each other" as a group. > > This is no more messy than inherited __getattr__ s. Not at all. The complexity of doing __getattr__ and __setattr__ hooks is all in the class you implement them in. There's no *new* complexity in going to base class implementations - you just chain as usual. The only surprise might be that if the hapless subclasser doesn't realize that some base class has a __setattr__ hook set. I'm not against this proposal. But I think there are *no* "safe" ways of doing attr hacks; and simply getting to "safer" may be a whole lot of work. [I also note that there are quite a few Python developers who want their users to say "x = obj.getx()", but want Python to create the accessor method "getx(self)" (if they haven't written one) and outlaw "x = obj.x". I have no sympathy for them, but they exist.] - Gordon From gmcm@hypernet.com Thu Jul 20 18:03:13 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 20 Jul 2000 13:03:13 -0400 Subject: [Python-Dev] Consistency questions In-Reply-To: <20000720172108.S9897@xs4all.nl> References: <14711.2370.880455.337906@beluga.mojam.com>; from skip@mojam.com on Thu, Jul 20, 2000 at 09:14:26AM -0500 Message-ID: <1248009898-10078427@hypernet.com> Thomas Wouters wrote: [ Why doesn't dir( obj ) return inherited methods? ] > I would suggest adding a second, optional argument to dir(), > 'recurse' or such, to add that behaviour. I think I can add that > code to dir() if it's deemed a good idea ;) Turning it on by > default would probably break too much code. I strongly agree with the last sentence. I'm only +0 on the enhancement (Mark's got that in PythonWin, and I hardly ever use it). - Gordon From mal@lemburg.com Thu Jul 20 18:05:37 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 19:05:37 +0200 Subject: [Python-Dev] PEP-able References: <39769DB0.BCE7FB38@prescod.net> Message-ID: <39773161.1DA45DE6@lemburg.com> Paul Prescod wrote: > > PEP: ??? > Title: Computed Attributes > Version: $Revision: 1.0 $ > Owner: paul@prescod.net > Python-Version: 2.0 > Status: Incomplete > > Introduction > > This PEP describes a feature to make it easier to use Python > attribute set/get/del syntax to fetch the results of a computation > or to invoke computation. This feature has been emulated using > __getattr__/__setattr__/__delattr__ but this approach suffers > severe usability and performance concerns. > > Syntax > > Special methods should declare themselves with declarations of the > following form: > > class x: > def __get_foo__(self ): ... def __set_foo__(self, value ): ... > def __del_foo__(self ): ... > > They are used like this: > > fooval=x.foo > x.foo=fooval+5 > del x.foo I don't get the point: how is this better than defining explicit access methods ? get_foo(self) set_foo(self, value) del_foo(self) These not only define a distinct interface, but also provide more flexibility, e.g. get_foo() could have a default argument. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 20 18:13:23 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 19:13:23 +0200 Subject: [Python-Dev] Consistency questions References: <3976A175.12D4DB53@prescod.net> Message-ID: <39773333.ABFDD65D@lemburg.com> Paul Prescod wrote: > > #1. Why does can I overwrite the "standard output object" with > assignment syntax > > sys.stdout=mystdoutobj > > But I have to add a profile function with function syntax: > > sys.setprofile( myprofilefunc ) .set/get APIs usually interface to C flags or variables which are not meant to be used directly (often due to performance reasons). > #2. Why doesn't dir( obj ) return inherited methods? Maybe because inherited methods are not local to the object. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mwh21@cam.ac.uk Thu Jul 20 18:17:54 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 20 Jul 2000 18:17:54 +0100 Subject: [Python-Dev] Consistency questions In-Reply-To: "Gordon McMillan"'s message of "Thu, 20 Jul 2000 13:03:13 -0400" References: <20000720172108.S9897@xs4all.nl> <1248009902-10078204@hypernet.com> Message-ID: "Gordon McMillan" writes: > Skip Montanaro wrote: > > > > > Thomas> I would suggest adding a second, optional argument to > > dir(), Thomas> 'recurse' or such, to add that behaviour. I > > think I can add that Thomas> code to dir() if it's deemed a > > good idea ;) Turning it on by Thomas> default would probably > > break too much code. > > > > I don't think so. I suspect most people use dir() interactively > > to see what attributes an object supports and would appreciate > > the improved functionality. Besides, we are talking 2.0 here. > > Nothing wrong with a little breakage... ;-) > > In the std lib: > cmd.py (already looks in __class__ and __bases__), > rlcompleter (doesn't), Yes it does! (at least in CVS; that was my first patch to Python...) > rexec (only invoked on modules?). > > It seems a gratuitous breakage, since it's additional behavior, > not fixed behavior. Gentle agreement. Cheers, M. -- After a heavy night, I travelled on, my face toward home - the comma being by no means guaranteed. -- paraphrased from cam.misc From paul@prescod.net Thu Jul 20 18:21:07 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:21:07 -0500 Subject: [Python-Dev] map() for methods References: <20000718130059.B7340@xs4all.nl> <14708.40190.852802.966575@beluga.mojam.com> <39771CCE.F70A48D4@lemburg.com> Message-ID: <39773503.8738E2F5@prescod.net> "M.-A. Lemburg" wrote: > > > True, we'll need somthing like this for methods too... e.g. > like the following API in mx.Tools: > > method_mapply(objects,methodname[,args=(),kw={}]) > ... > > The name is clumsy... suggestions welcome :-) How about this name: "list comprehension." -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From thomas@xs4all.net Thu Jul 20 19:36:17 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 20:36:17 +0200 Subject: [Python-Dev] Coercion (RE: Discussion: Introducing new operators for matrix computation) In-Reply-To: <39771F80.90DD0C99@lemburg.com>; from mal@lemburg.com on Thu, Jul 20, 2000 at 05:49:20PM +0200 References: <39771F80.90DD0C99@lemburg.com> Message-ID: <20000720203617.U9897@xs4all.nl> On Thu, Jul 20, 2000 at 05:49:20PM +0200, M.-A. Lemburg wrote: > [Adding new operators] > Just a side note before everyone forgets: I think we'll > need to carefully redefine coercion *before* adding any > new slots/operators/etc. to Python. > The current model where coercion is centralized won't > scale well with the new operators. My (old) proposal for this > (see my Python Pages) was to decentralize coercion and > make the coercion process part of the operators task. > Thoughts ? Agreed. I also think, but that's a personal opinion, that adding new operators should be done carefully, and I'm not sure if 2.0 is the right time for it. It depends on how far away 2.0 is, of course, not just to make sure the operators are implemented right, with clear semantics and everything, but also to give everyone a chance to accept the idea of new operators ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Thu Jul 20 19:40:35 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 20:40:35 +0200 Subject: [Python-Dev] PEPs on the web In-Reply-To: <39774A29.86E469BB@schneider-kamp.de>; from peter@schneider-kamp.de on Thu, Jul 20, 2000 at 06:51:21PM +0000 References: <39774A29.86E469BB@schneider-kamp.de> Message-ID: <20000720204034.V9897@xs4all.nl> On Thu, Jul 20, 2000 at 06:51:21PM +0000, Peter Schneider-Kamp wrote: > I have put up the PEPs on http://python.sourceforge.net/peps/ > 1) Is that okay? No one cried out aloud and I got some agreement. I don't see why not. It certainly seems the right place for it ! And it's not like they were a corporate secret before. > 2) Should I put a link from http://python.sourceforge.net ? I'd say so, yeah. > 3) What about making those PEPs xhtml (or something like that)? > Pros: > - links from pep-000.txt > - links from the other peps > Cons: > - harder to read in checkins > - harder to edit > (maybe we could use as little markup as possible?) Definate -1 from here. I like plaintext. It also works just fine for RFCs. I don't mind if the reference section (which should be the only place that contains URIs ;) is written in a markup language to facilitate HTMLization, or maybe just straight HTML, but I don't feel like escaping all those '>'s in there. However, if they can be converted to HTML automatically, based on minor clues and/or whitespace-layout, fine by me ;) I wouldn't mind adding things like paragraph markers and such, I just dont like to edit HTML newer than 1.1 ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul@prescod.net Thu Jul 20 18:27:19 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:27:19 -0500 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> <397723AF.4B11379A@lemburg.com> Message-ID: <39773677.B3543269@prescod.net> "M.-A. Lemburg" wrote: > >... > > You add your new PyErr_Format() replacement with the existing > subset of codes, but instead of bailing out when the function > sees a format code it doesn't understand, you use sprintf() > or snprintf() (where available) to format the unkown code ?! I think its too magical and could hide security holes under too many levels of conditional behavior. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul@prescod.net Thu Jul 20 18:49:09 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:49:09 -0500 Subject: [Python-Dev] PEP-able References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> Message-ID: <39773B95.2B70EBBC@prescod.net> "M.-A. Lemburg" wrote: > > .. > > I don't get the point: how is this better than defining > explicit access methods ? > > get_foo(self) > set_foo(self, value) > del_foo(self) It's more verbose for the client programmer and it forces them to "know" that there is magical processing going on under the covers. I'm going to provide examples of where we do or would use a feature like this in extension modules so that you can see that I'm just trying to extend the fun to Python programmers (not just extension writers). There are about a million places in Python's implementation where extension modules do computation like: def __setattr__( name, val ): if attribute_to_set=="__class__": assert PyClass_Check( val ): elif attribute_to_set=="__dict__": assert PyDict_Check( val ): One could imagine a circumstance in which we decide to "trap" sys.stdin=o so that if it HASN'T been set we could use a more efficient stdout writing protocol internal to the interpreter implementation. In general, it is useful when you want to migrate from an attribute-setting situation to a computational situation without changing existing code. You can also think of the various places where the interpreter traps when you try to write to a read-only attribute. In pyexpat, when you assign to certain variables we "push" that information down to expat itself (set variables in expat). Imagine trying to read or write an attribute over COM or CORBA. Why should Python programmers have to use foo.set("a", 5) when VB programmers just say foo.a=5? Mark Hammond currently does this with __getattr__ I believe. It would be more efficient better to auto-generate getter and setter methods. In general, its useful for proxy situations where the set of attribute you want to proxy are known in advance. It's just a cleaner, Pythonic way to do something that is already common either using __getattr__ hacks or in extension modules. > These not only define a distinct interface, but also provide > more flexibility, e.g. get_foo() could have a default argument. I'm not taking away anyone's right to use methods. The logical extension of your argument is that we should always use getter/setter methods in case we need to add arguments to them later. That's the Java stance but I think we can differentiate ourselves from Java with clearer code. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul@prescod.net Thu Jul 20 18:52:28 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:52:28 -0500 Subject: [Python-Dev] Computed-attributes References: <1248009900-10078307@hypernet.com> Message-ID: <39773C5C.D9C07572@prescod.net> Gordon McMillan wrote: > > ... > Then: > > class A: > def __init__(self): > self.y = > class B(A): > def __set_y__(self, value): > ... > def __init__(self): > A.__init__(self) > > means that the hook in B will be invoked when A.__init__ > runs. I wonder what "gotchas" lie in wait ;-). Python is full of these gotchas. (__setattr__ has the same problem, for example). It's amazing that anything ever works. :) For any lurkers: my tongue is firmly in my cheek! > [I also note that there are quite a few Python developers who > want their users to say "x = obj.getx()", but want Python to > create the accessor method "getx(self)" (if they haven't written > one) and outlaw "x = obj.x". I have no sympathy for them, but > they exist.] Java-heads. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul@prescod.net Thu Jul 20 18:56:27 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:56:27 -0500 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> <397716E6.F19E25BE@prescod.net> <200007201611.MAA26587@zippy.init.com> Message-ID: <39773D4B.495E1C4B@prescod.net> Don Beaudry! The master returns to check on the upstarts. Donald Beaudry wrote: > > ... > > One way of doing that, which I feel also makes things a bit more > obvious, is to allow only a single routine per attribute: __attr_XXX__. My first reaction was negative but it does simplify a bunch of stuff. Inheritance is straightforward, calling a base class is straightforward, implementation is simpler. Overall, I like it! > I agree that prohibiting it is the right idea. The question is how. > Permitting only one routine per attribute lets the traditional > attribute lookup rules work and thus prevents head scratching when > trying to find the code that actually maintains an attribute. The > cost is some additional burden on the writer of the __attr_XXX method > (and some magic to distinguish the del case). Don't follow that. Why not just have "get"/"set"/"del" opcodes? -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From Moshe Zadka Thu Jul 20 19:58:54 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 20 Jul 2000 21:58:54 +0300 (IDT) Subject: [Python-Dev] Coercion (RE: Discussion: Introducing new operators for matrix computation) In-Reply-To: <39771F80.90DD0C99@lemburg.com> Message-ID: On Thu, 20 Jul 2000, M.-A. Lemburg wrote: > The current model where coercion is centralized won't > scale well with the new operators. My (old) proposal for this > (see my Python Pages) was to decentralize coercion and > make the coercion process part of the operators task. > > Thoughts ? > Yes. Coercion should be PEPed. It definitely qualifies for PEPing. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul@prescod.net Thu Jul 20 19:57:10 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 13:57:10 -0500 Subject: [Python-Dev] Computed-attributes References: <1248009900-10078307@hypernet.com> Message-ID: <39774B86.2D6317AB@prescod.net> Gordon McMillan wrote: > > ... > Then: > > class A: > def __init__(self): > self.y = > class B(A): > def __set_y__(self, value): > ... > def __init__(self): > A.__init__(self) > > means that the hook in B will be invoked when A.__init__ > runs. I wonder what "gotchas" lie in wait ;-). Python is full of these gotchas. (__setattr__ has the same problem, for example). It's amazing that anything ever works. :) For any lurkers: my tongue is firmly in my cheek! > [I also note that there are quite a few Python developers who > want their users to say "x = obj.getx()", but want Python to > create the accessor method "getx(self)" (if they haven't written > one) and outlaw "x = obj.x". I have no sympathy for them, but > they exist.] Java-heads. What do you think of Don B's idea. It simplifies things somewhat. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul@prescod.net Thu Jul 20 18:27:19 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:27:19 -0500 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> <397723AF.4B11379A@lemburg.com> Message-ID: <39773677.B3543269@prescod.net> "M.-A. Lemburg" wrote: > >... > > You add your new PyErr_Format() replacement with the existing > subset of codes, but instead of bailing out when the function > sees a format code it doesn't understand, you use sprintf() > or snprintf() (where available) to format the unkown code ?! I think its too magical and could hide security holes under too many levels of conditional behavior. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul@prescod.net Thu Jul 20 18:56:27 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:56:27 -0500 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> <397716E6.F19E25BE@prescod.net> <200007201611.MAA26587@zippy.init.com> Message-ID: <39773D4B.495E1C4B@prescod.net> Don Beaudry! The master returns to check on the upstarts. Donald Beaudry wrote: > > ... > > One way of doing that, which I feel also makes things a bit more > obvious, is to allow only a single routine per attribute: __attr_XXX__. My first reaction was negative but it does simplify a bunch of stuff. Inheritance is straightforward, calling a base class is straightforward, implementation is simpler. Overall, I like it! > I agree that prohibiting it is the right idea. The question is how. > Permitting only one routine per attribute lets the traditional > attribute lookup rules work and thus prevents head scratching when > trying to find the code that actually maintains an attribute. The > cost is some additional burden on the writer of the __attr_XXX method > (and some magic to distinguish the del case). Don't follow that. Why not just have "get"/"set"/"del" opcodes? -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul@prescod.net Thu Jul 20 18:58:19 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:58:19 -0500 Subject: [Python-Dev] Consistency questions References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> <20000720172108.S9897@xs4all.nl> <14711.8162.800169.884936@beluga.mojam.com> Message-ID: <39773DBB.9480F7BF@prescod.net> Skip Montanaro wrote: > > ... > > I don't think so. I suspect most people use dir() interactively to see what > attributes an object supports and would appreciate the improved > functionality. Besides, we are talking 2.0 here. Nothing wrong with a > little breakage... ;-) I think that Thomas is right that there is going to be a fair bit of code that manually worked around this limitation in dir and now will get two copies of some attributes. What do you think about attrs( foo ) It's more descriptive anyhow. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From Moshe Zadka Thu Jul 20 20:04:15 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 20 Jul 2000 22:04:15 +0300 (IDT) Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) In-Reply-To: <39773677.B3543269@prescod.net> Message-ID: [M.-A. Lemburg] > You add your new PyErr_Format() replacement with the existing > subset of codes, but instead of bailing out when the function > sees a format code it doesn't understand, you use sprintf() > or snprintf() (where available) to format the unkown code ?! [Paul Prescod] > I think its too magical and could hide security holes under too many > levels of conditional behavior. FWIW, I agree with Paul -- if an unknown format code is used, it will be plainly seen in the exception, so we will know *exactly* what popular format codes we forgot to add. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Moshe Zadka Thu Jul 20 20:09:06 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 20 Jul 2000 22:09:06 +0300 (IDT) Subject: [Python-Dev] PEPs on the web In-Reply-To: <39774A29.86E469BB@schneider-kamp.de> Message-ID: On Thu, 20 Jul 2000, Peter Schneider-Kamp wrote: > 2) Should I put a link from http://python.sourceforge.net ? +1 and more! > 3) What about making those PEPs xhtml (or something like that)? > Pros: > - links from pep-000.txt > - links from the other peps > Cons: > - harder to read in checkins > - harder to edit > (maybe we could use as little markup as possible?) -1. RFCs got to rule the 'net with text alone. If it's good enough for the IETF, it's good enough for us. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Fredrik Lundh" Message-ID: <008901bff283$2d55d2a0$f2a6b5d4@hagrid> peter wrote: > 3) What about making those PEPs xhtml (or something like that)? > Pros: > - links from pep-000.txt > - links from the other peps > Cons: > - harder to read in checkins > - harder to edit > (maybe we could use as little markup as possible?) please stick to plain text sources. here's a little script that converts text PEP's to HTML. feel free to add it to your uploading scripts. # convert PEP's to (X)HTML import cgi, glob, os, re fixpat =3D = re.compile("((http|ftp):[-_a-zA-Z0-9/.+?~:]+)|(pep-\d+(.txt)?|.") def fixanchor(match): text =3D match.group(0) link =3D None if text[:5] =3D=3D "http:" or text[:4] =3D=3D "ftp:": link =3D text elif text[:3] =3D=3D "pep": link =3D os.path.splitext(text)[0] + ".html" if link: return "%s" % (link, cgi.escape(text)) return cgi.escape(match.group(0)) def fixfile(infile, outfile): # convert plain text pep to minimal XHTML markup fi =3D open(infile) fo =3D open(outfile, "w") fo.write("\n") # head header =3D [] fo.write("\n") while 1: line =3D fi.readline() if not line or ":" not in line: break key, value =3D line.split(":", 1) value =3D value.strip() header.append((key, value)) if key.lower() =3D=3D "title": fo.write("%s\n" % cgi.escape(value)) fo.write("\n") # body fo.write("\n") fo.write("
\n")
    for k, v in header:
        fo.write("%s: %s\n" % (cgi.escape(k), cgi.escape(v)))
    title =3D 0
    while 1:
        line =3D fi.readline()
        if not line:
            break
        if line[:1] =3D=3D "\f":
            fo.write("
\n")
            title =3D 1
        else:
            line =3D fixpat.sub(fixanchor, line)
            if title:
                fo.write("
%s
\n" % line)
            else:
                fo.write(line)
            title =3D 0
    fo.write("
\n") fo.write("\n") fo.write("\n") for file in glob.glob("pep-*.txt"): print file, "..." fixfile(file, os.path.splitext(file)[0] + ".html") cheers /F From huaiyu_zhu@yahoo.com Thu Jul 20 20:42:44 2000 From: huaiyu_zhu@yahoo.com (Huaiyu Zhu) Date: Thu, 20 Jul 2000 12:42:44 -0700 (PDT) Subject: [Python-Dev] Coercion (RE: Discussion: Introducing new operators for matrix computation) In-Reply-To: <20000720203617.U9897@xs4all.nl> Message-ID: On Thu, 20 Jul 2000, Thomas Wouters wrote: > On Thu, Jul 20, 2000 at 05:49:20PM +0200, M.-A. Lemburg wrote: > > [Adding new operators] > > > Just a side note before everyone forgets: I think we'll > > need to carefully redefine coercion *before* adding any > > new slots/operators/etc. to Python. > > > The current model where coercion is centralized won't > > scale well with the new operators. My (old) proposal for this > > (see my Python Pages) was to decentralize coercion and > > make the coercion process part of the operators task. > > > Thoughts ? > Just a note. The additional operators for numerical computation have exactly the same properties as the conventional math operators. Their default on numbers are identical. Don't know if this is relevant, though. > Agreed. I also think, but that's a personal opinion, that adding new > operators should be done carefully, and I'm not sure if 2.0 is the right > time for it. It depends on how far away 2.0 is, of course, not just to make > sure the operators are implemented right, with clear semantics and > everything, but also to give everyone a chance to accept the idea of new > operators ;P Any timeline? Huaiyu From Donald Beaudry Thu Jul 20 20:48:45 2000 From: Donald Beaudry (Donald Beaudry) Date: Thu, 20 Jul 2000 15:48:45 -0400 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> <397716E6.F19E25BE@prescod.net> <200007201611.MAA26587@zippy.init.com> <39773D4B.495E1C4B@prescod.net> Message-ID: <200007201948.PAA29206@zippy.init.com> Paul Prescod wrote, > Donald Beaudry wrote: > > The cost is some additional burden on the writer of the __attr_XXX > > method (and some magic to distinguish the del case). > > Don't follow that. Why not just have "get"/"set"/"del" opcodes? Sorry about that... it was an editing problem. At first I was going to propose that the __attr_XXX method take just one optional argument: the set value. If it was there do a set, if not do a get. The problem was how to do the del (magic?). Then I had the bright idea of using the op parameter but never removed my "magic" comment. The "additional burden" I was refering to was that of writing a method which must first decide what to do. Personally, I call this a feature since it forces all maintenance of a given attribute into a single place. Others might argue that the code in a single purpose setter, getter, or deller would read better. -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb@init.com Lexington, MA 02421 ...So much code, so little time... From thomas@xs4all.net Thu Jul 20 21:13:00 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 22:13:00 +0200 Subject: [Python-Dev] ANSIfication again ;) Message-ID: <20000720221300.W9897@xs4all.nl> I just went over all of the Python source, using this little program (which I called findkrc.py): import sys, string for file in sys.argv[1:] d = open(file).read() if string.find(d, ";\n{") <> -1 or string.find(d, "()\n{") <> -1: print file (using find -name '*.[ch]' -print | xargs ./findkrc.py) And I fixed almost all of the instances of K&R C syntax. However, I found a lot of instances of the 2nd type: empty argument list. However, as far as I remember, ANSI C states that should be written as '(void)'. Is that a non-issue, and should I not bother fixing those ? (Most of the files in Modules/ has one or more instances of those.) I also found a number of files which were already converted to ANSI syntax, but with one function leftover. Should I bother uploading a patch for those, or can I just commit them ? They're only a few lines per file, after all. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Thu Jul 20 21:49:30 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 22:49:30 +0200 Subject: [Python-Dev] __set_foo__ et al. (PEP-able) References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> <39773B95.2B70EBBC@prescod.net> Message-ID: <397765DA.133518A2@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > .. > > > > I don't get the point: how is this better than defining > > explicit access methods ? > > > > get_foo(self) > > set_foo(self, value) > > del_foo(self) > > It's more verbose for the client programmer and it forces them to "know" > that there is magical processing going on under the covers. Magical processing is usually not a very good design, IMHO (no, I don't like the Unicode auto-conversions ;-). > I'm going to > provide examples of where we do or would use a feature like this in > extension modules so that you can see that I'm just trying to extend the > fun to Python programmers (not just extension writers). > > There are about a million places in Python's implementation where > extension modules do computation like: > > def __setattr__( name, val ): > if attribute_to_set=="__class__": > assert PyClass_Check( val ): > elif attribute_to_set=="__dict__": > assert PyDict_Check( val ): But that's just an implementation detail (you either do the lookup via a mapping, e.g. the instance dict, or by switching on the attribute name)... in C and with only a few cases, the switching technique is faster than the lookup. > One could imagine a circumstance in which we decide to "trap" > sys.stdin=o so that if it HASN'T been set we could use a more efficient > stdout writing protocol internal to the interpreter implementation. > > In general, it is useful when you want to migrate from an > attribute-setting situation to a computational situation without > changing existing code. > > You can also think of the various places where the interpreter traps > when you try to write to a read-only attribute. > > In pyexpat, when you assign to certain variables we "push" that > information down to expat itself (set variables in expat). > > Imagine trying to read or write an attribute over COM or CORBA. Why > should Python programmers have to use foo.set("a", 5) when VB > programmers just say foo.a=5? Mark Hammond currently does this with > __getattr__ I believe. It would be more efficient better to > auto-generate getter and setter methods. > > In general, its useful for proxy situations where the set of attribute > you want to proxy are known in advance. > > It's just a cleaner, Pythonic way to do something that is already common > either using __getattr__ hacks or in extension modules. It's also *much* slower: you'd have to check objects for e.g. obj.__set_foo__ prior to every obj.foo=1 assignment. I think that these techniques are better implemented by writing a special proxy which then does your proposed mapping for a predefined set of attributes. mx.Proxy would be a good code base for these kind of experiments, but a simple Python prototype would do as well. > > These not only define a distinct interface, but also provide > > more flexibility, e.g. get_foo() could have a default argument. > > I'm not taking away anyone's right to use methods. The logical extension > of your argument is that we should always use getter/setter methods in > case we need to add arguments to them later. That's the Java stance but > I think we can differentiate ourselves from Java with clearer code. Well, you can't really say what is best in the general case. I usually use the direct attribute access method for information containers and the method access for more elaborate objects (ones which care about the data format, apply extra checks, depend on state, etc.). Very often these methods set more than just one attribute, so using __set_foo__ wouldn't work here. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" <008901bff283$2d55d2a0$f2a6b5d4@hagrid> Message-ID: <015101bff28f$6dad9200$f2a6b5d4@hagrid> minor nit: - fo.write("
\n") + fo.write("
\n") From paul@prescod.net Thu Jul 20 22:18:08 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 16:18:08 -0500 Subject: [Python-Dev] __set_foo__ et al. (PEP-able) References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> <39773B95.2B70EBBC@prescod.net> <397765DA.133518A2@lemburg.com> Message-ID: <39776C90.67FAFFD8@prescod.net> "M.-A. Lemburg" wrote: > > > def __setattr__( name, val ): > > if attribute_to_set=="__class__": > > assert PyClass_Check( val ): > > elif attribute_to_set=="__dict__": > > assert PyDict_Check( val ): > > But that's just an implementation detail (you either do the > lookup via a mapping, e.g. the instance dict, or by switching > on the attribute name)... in C and with only a few cases, the > switching technique is faster than the lookup. That's not the case. In this case, Guido is doing type checking on sets. You can only do that in Python with an __setattr__ hack. > > It's just a cleaner, Pythonic way to do something that is already common > > either using __getattr__ hacks or in extension modules. > > It's also *much* slower: you'd have to check objects for > e.g. obj.__set_foo__ prior to every obj.foo=1 assignment. It's much, much faster for than __getattr__ for gets. It's probably no slower than __setattr__ for sets because you aren't switching on the attribute name in Python. Anyhow gets are much more common than sets so speeding them up is a big win. > I think that these techniques are better implemented by > writing a special proxy which then does your proposed > mapping for a predefined set of attributes. Proxies are slow and introduce a host of their own "issues." In practice, I've never seen anyone implement this pattern with proxies unless the proxies were doing something else already (e.g. COM). They always use a direct __getattr__/__setattr__. > I usually use the direct attribute access method for > information containers and the method access for more > elaborate objects (ones which care about the data format, > apply extra checks, depend on state, etc.). Very often > these methods set more than just one attribute, so using > __set_foo__ wouldn't work here. Don't follow. Here's an example that: * cares about data format * applies extra checks * is state dependent * sets more than one attribute internally def __set_enddate__( self, val ): if len(val)==3 and val>self.start_date self.endday, self.endmonth, self.endyear=val else: raise TypeError def __get_enddate__(self, val): return self.endday, self.endmonth, self.endyear obj.enddate=(15, 12, 2000) print obj.endday print obj.endmonth print obj.endyear d,m,y=obj.enddate -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From mal@lemburg.com Thu Jul 20 22:42:32 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 23:42:32 +0200 Subject: [Python-Dev] __set_foo__ et al. (PEP-able) References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> <39773B95.2B70EBBC@prescod.net> <397765DA.133518A2@lemburg.com> <39776C90.67FAFFD8@prescod.net> Message-ID: <39777248.9FE80D68@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > > def __setattr__( name, val ): > > > if attribute_to_set=="__class__": > > > assert PyClass_Check( val ): > > > elif attribute_to_set=="__dict__": > > > assert PyDict_Check( val ): > > > > But that's just an implementation detail (you either do the > > lookup via a mapping, e.g. the instance dict, or by switching > > on the attribute name)... in C and with only a few cases, the > > switching technique is faster than the lookup. > > That's not the case. In this case, Guido is doing type checking on sets. > You can only do that in Python with an __setattr__ hack. Huh ? "if attribute_to_set == ..." looks like a switch on attribute name to me. > > > It's just a cleaner, Pythonic way to do something that is already common > > > either using __getattr__ hacks or in extension modules. > > > > It's also *much* slower: you'd have to check objects for > > e.g. obj.__set_foo__ prior to every obj.foo=1 assignment. > > It's much, much faster for than __getattr__ for gets. It's probably no > slower than __setattr__ for sets because you aren't switching on the > attribute name in Python. Anyhow gets are much more common than sets so > speeding them up is a big win. __get_foo__ causes a Python function call and this is about the most costly activity there is in Python's internals. > > I think that these techniques are better implemented by > > writing a special proxy which then does your proposed > > mapping for a predefined set of attributes. > > Proxies are slow and introduce a host of their own "issues." In > practice, I've never seen anyone implement this pattern with proxies > unless the proxies were doing something else already (e.g. COM). They > always use a direct __getattr__/__setattr__. Sure, I meant proxies as good starting point for meta classes which deal with your proposed technique. BTW, proxies written in C are fast -- __getattr__ in C is within practical range. > > I usually use the direct attribute access method for > > information containers and the method access for more > > elaborate objects (ones which care about the data format, > > apply extra checks, depend on state, etc.). Very often > > these methods set more than just one attribute, so using > > __set_foo__ wouldn't work here. > > Don't follow. Here's an example that: (Note: I described my personal style -- not as general rule or guideline.) > * cares about data format > * applies extra checks > * is state dependent > * sets more than one attribute internally > > def __set_enddate__( self, val ): > if len(val)==3 and val>self.start_date > self.endday, self.endmonth, self.endyear=val > else: > raise TypeError > > def __get_enddate__(self, val): > return self.endday, self.endmonth, self.endyear > > obj.enddate=(15, 12, 2000) > print obj.endday > print obj.endmonth > print obj.endyear > > d,m,y=obj.enddate Well, yes. It works. But tell me: how are you going to debug this ? Assignments will suddenly raise exceptions and the traceback won't be of any use for programmers to find the true error location. Too much magic and too many possibilities for overloading dots ;-) (I've never understood why Javascript causes a new URL to be shown when your assign to top.window.location.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From peter@schneider-kamp.de Fri Jul 21 00:49:02 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 20 Jul 2000 23:49:02 +0000 Subject: [Python-Dev] ANSIfication again ;) References: <20000720221300.W9897@xs4all.nl> Message-ID: <39778FEE.88427388@schneider-kamp.de> Thomas Wouters wrote: > > And I fixed almost all of the instances of K&R C syntax. However, I found a > lot of instances of the 2nd type: empty argument list. However, as far as I > remember, ANSI C states that should be written as '(void)'. Is that a > non-issue, and should I not bother fixing those ? (Most of the files in > Modules/ has one or more instances of those.) Yes, I think that's right. I just looked at them and thought: Oh, no parameters - no work ;-) But then even "gcc -pedantic -ansi" doesn't care about this. Take that as a +0. > I also found a number of files which were already converted to ANSI syntax, > but with one function leftover. Should I bother uploading a patch for those, > or can I just commit them ? They're only a few lines per file, after all. I'd guess that if you feel that it's right and there is no functional change involved no one will object. not-feeling-competent-enough-for-a-straight-"just-do-it"-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mal@lemburg.com Thu Jul 20 22:56:07 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 23:56:07 +0200 Subject: [Python-Dev] uPEP: encoding directive References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> Message-ID: <39777577.316F1B9@lemburg.com> Fredrik Lundh wrote: > > > [paul] > > > Also, is it really necessary to allow raw non-ASCII characters in source > > > code though? We know that they aren't portable across editing > > > environments, so one person's happy face will be another person's left > > > double-dagger. > > > > [me] > > I suppose changing that would break code. maybe it's time > > to reopen the "pragma encoding" thread? > > > > (I'll dig up my old proposal, and post it under a new subject). > > as brief as I can make it: > 1. add support for "compiler directives". I suggest the following > syntax, loosely based on XML: > > #?python key=value [, key=value ...] > > (note that "#?python" will be treated as a token after this change. > if someone happens to use comments that start with #?python, > they'll get a "SyntaxError: bad #?python compiler directive"...) > > 2. for now, only accept compiler directives if they appear before > the first "real" statement. > > 3. keys are python identifiers (NAME tokens), values are simple > literals (STRING, NUMBER) > > 4. key/value pairs are collected in a dictionary. > > [...] I like the proposal, but how would you implement this ? Note that strings are decoded in compiler.c after having run the source through the tokenizer (which eliminates the comments). You'd have to carry the encoding information through to the compiler somehow. There's also a different problem to this: dynamic compilation. What encoding should eval() and exec use or expect ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" <008901bff283$2d55d2a0$f2a6b5d4@hagrid> Message-ID: <003901bff296$377cb880$f2a6b5d4@hagrid> I've hacked a little more on the conversion script. here's the resulting HTML files: http://w1.132.telia.com/~u13208596/peps/ and here's the script itself: http://w1.132.telia.com/~u13208596/peps/pepfixup.py enjoy /F From Fredrik Lundh" <39778FEE.88427388@schneider-kamp.de> Message-ID: <004901bff297$0f4c37e0$f2a6b5d4@hagrid> peter wrote: > thomas wrote: > > However, as far as I remember, ANSI C states that should be written > > as '(void)'. Is that a non-issue, and should I not bother fixing = those ? > > (Most of the files in Modules/ has one or more instances of those.) >=20 > Yes, I think that's right. I just looked at them and thought: Oh, no > parameters - no work ;-) >=20 > But then even "gcc -pedantic -ansi" doesn't care about this. > Take that as a +0. strictly speaking, (void) and () are two different things: "If the function does not expect any arguments, you write only the keyword void void reset(void); no arguments, no return ... "You can also declare a function and not provide information about the number or types of its arguments. Do not write declarations within the parentheses of the function decoration. double bessel(); no argument information (from http://www-ccs.ucsd.edu/c/function.html) but I guess it's up to you if you want to be more pedantic than -pedantic... From paul@prescod.net Thu Jul 20 23:03:34 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 17:03:34 -0500 Subject: [Python-Dev] __set_foo__ et al. (PEP-able) References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> <39773B95.2B70EBBC@prescod.net> <397765DA.133518A2@lemburg.com> <39776C90.67FAFFD8@prescod.net> <39777248.9FE80D68@lemburg.com> Message-ID: <39777736.EB18917E@prescod.net> "M.-A. Lemburg" wrote: > > Paul Prescod wrote: > > > > "M.-A. Lemburg" wrote: > > > > > > > def __setattr__( name, val ): > > > > if attribute_to_set=="__class__": > > > > assert PyClass_Check( val ): > > > > elif attribute_to_set=="__dict__": > > > > assert PyDict_Check( val ): > > > > > That's not the case. In this case, Guido is doing type checking on sets. > > You can only do that in Python with an __setattr__ hack. > > Huh ? "if attribute_to_set == ..." looks like a switch on > attribute name to me. But he's doing the switch not for performance reasons but to check the data value before allowing the assignment! In Python you might do it for the same basic reason. > __get_foo__ causes a Python function call and this is about > the most costly activity there is in Python's internals. You wouldn't use __get_foo__ unless you *needed to do some computation*. Therefore you shouldn't compare it to anything OTHER than a Python function call. The appropriate comparision is to __getattr__ with a big switch statement or code. > Well, yes. It works. But tell me: how are you going to debug > this ? Assignments will suddenly raise exceptions and the > traceback won't be of any use for programmers to find the > true error location. Assignments can raise exceptions today. Try assigning to tuple slot. The traceback will go through the code that did the assignment. It won't be at the bottom of the traceback but it will appear. The traceback will be MORE useful than the altenatives of either a proxy or __getattr__. > Too much magic and too many possibilities for overloading > dots ;-) Python already gives you the ability to do this magic and we do it all over the place. The question is whether to make it a little more reliable, performant and consistent or not. > (I've never understood why Javascript causes a new URL to be shown > when your assign to top.window.location.) Well a Python web-browser could implement the same poor design decision *today*. I am going to make it easier but I'm not going to force people to use it! -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From skip@mojam.com (Skip Montanaro) Thu Jul 20 23:05:04 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 20 Jul 2000 17:05:04 -0500 (CDT) Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <39778FEE.88427388@schneider-kamp.de> References: <20000720221300.W9897@xs4all.nl> <39778FEE.88427388@schneider-kamp.de> Message-ID: <14711.30608.650773.223155@beluga.mojam.com> [ () vs. (void) in ANSI C ] Peter> But then even "gcc -pedantic -ansi" doesn't care about this. I doubt it should. "()" is perfectly valid ANSI C isn't it? As I recall it means "I know nothing about this function's input parameters, so I won't check it." On the other hand, "(void)" means "This function takes precisely zero input args". Skip From pingster@ilm.com Thu Jul 20 23:09:30 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Thu, 20 Jul 2000 15:09:30 -0700 (PDT) Subject: [Python-Dev] realpath? Message-ID: We have normpath() and readlink(), but how about realpath()? Seems like a good thing to have in the posixmodule. The man page for the C routine says: char *realpath (const char *file_name, char *resolved_name); DESCRIPTION realpath resolves all links, symbolic links, and references to ``.'' and ``..'' in file_name and stores it in resolved_name. It can handle both relative and absolute path names. For absolute path names and the relative names whose resolved name cannot be expressed relatively (for example, ../../reldir), it returns the resolved absolute name. resolved_name should point to a buffer (MAXPATHLEN) bytes in length to contain the fully resolved path name. -- ?!ng From Fredrik Lundh" this patch by Pekka Pessi adds support for "0" and "-1" to gethostbyname: "0" (a string, not an integer) is the same thing as "" (INADDR_ANY) "-1" is the same thing as "". (INADDR_BROADCAST) Pekka hasn't followed up on my comments on the patch page, so I thought I'd take the question to this forum in- stead: -- why is gethostbyname "broken" if it doesn't support the magic strings "0" and "-1"? I'm tempted to reject the patch, but I'm probably missing something here... From gstein@lyra.org Thu Jul 20 23:26:33 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 20 Jul 2000 15:26:33 -0700 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <14711.2226.242735.766934@beluga.mojam.com>; from skip@mojam.com on Thu, Jul 20, 2000 at 09:12:02AM -0500 References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> Message-ID: <20000720152633.H8820@lyra.org> On Thu, Jul 20, 2000 at 09:12:02AM -0500, Skip Montanaro wrote: > > Peter> But in the long run this probably should be automated. I only see > Peter> the password barrier: > > Peter> scp pep-*.txt nowonder@shell.sourceforge.net:/home/groups/python/htdocs/peps > Peter> will make me enter my password/passphrase. > > Peter> How would one go about doing something like that? > > ... ssh-agent ... Easier than ssh-agent is to create an "authorized_keys" file. Log onto the shell box and type "mkdir .ssh". Next, copy the .ssh/identity.pub file from your local machine to .ssh/authorized_keys on shell.sourceforge.net. From then on, SF will used the auth'd key rather than asking for your password. In the Account Maintenance pages on SF, there is a box for entering keys. I haven't tried it yet (I entered my key, but had to wait for the cron job and never went back to check). That should allow you to do CVS work without entering a password either. It might also update the authorized_keys file on the shell machine, too (i.e. obviate the step above) Cheers, -g -- Greg Stein, http://www.lyra.org/ From Fredrik Lundh" Message-ID: <006b01bff29a$3ca51380$f2a6b5d4@hagrid> ?!ng wrote: > We have normpath() and readlink(), but how about realpath()? >=20 > Seems like a good thing to have in the posixmodule. it's in SUSv2, so +1 from me. but don't forget #if defined(HAVE_REALPATH). what's the best way to emulate this one on Windows, btw? From peter@schneider-kamp.de Fri Jul 21 01:53:25 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 21 Jul 2000 00:53:25 +0000 Subject: [Python-Dev] [ANNOUNCE] Python Enhancement Proposals on the Web Message-ID: <39779F05.3181C5E5@schneider-kamp.de> The so called PEPs (Python Enhancement Proposals) are now available on the web at http://python.sourceforge.net/peps Thanks to /F who hacked up a small pep2html converter you can browse them as hypertext rather than as the plain text they are. PEPs that already carry some content include: 0201 Parallel Iteration bwarsaw 0203 Augmented Assignments twouters 0204 Range Literals twouters 0206 2.0 Batteries Included moshez Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gstein@lyra.org Thu Jul 20 23:54:52 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 20 Jul 2000 15:54:52 -0700 Subject: [Python-Dev] Re: [patch #100895 ] PyErr_Format In-Reply-To: ; from moshez@math.huji.ac.il on Thu, Jul 20, 2000 at 10:04:15PM +0300 References: <39773677.B3543269@prescod.net> Message-ID: <20000720155451.K8820@lyra.org> On Thu, Jul 20, 2000 at 10:04:15PM +0300, Moshe Zadka wrote: > > [M.-A. Lemburg] > > You add your new PyErr_Format() replacement with the existing > > subset of codes, but instead of bailing out when the function > > sees a format code it doesn't understand, you use sprintf() > > or snprintf() (where available) to format the unkown code ?! > > [Paul Prescod] > > I think its too magical and could hide security holes under too many > > levels of conditional behavior. > > FWIW, I agree with Paul -- if an unknown format code is used, it will be > plainly seen in the exception, so we will know *exactly* what popular > format codes we forgot to add. Agreed. Just punt on unknown codes. The "failure mode" is obvious and the fix is easy. We don't need complexity to resolve something which is obvious and easy. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Jul 20 23:57:41 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 20 Jul 2000 15:57:41 -0700 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) In-Reply-To: <00b801bff1a9$248f4780$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jul 19, 2000 at 07:45:23PM +0200 References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> Message-ID: <20000720155741.L8820@lyra.org> On Wed, Jul 19, 2000 at 07:45:23PM +0200, Fredrik Lundh wrote: >... > if I understood GvR correctly, the only remaining issue here > is whether we need more formatting codes I would say "no. let's wait and implement when a need is discovered." > (PyErr_Format is undocumented, so I'm not sure we need to > be backwards compatible with code outside the interpreter...) > > in an earlier post, I suggested adding a couple of PyErr_Format- > specific formatting codes: > > possibly stupid idea: would it make sense to add custom > formatting codes, like: > > %S => char*, string, clip if excessively long > %T => PyObject*, show name of type, clip if excessively long > > where "clip" means: > > truncate at 80 characters, and add "..." to indicate > that the string was truncated. > > this covers most of the places where %.\d+s are used (in > the Python core, at least...) > > comments? Punt. Keep it clean and simple. If a long value goes in, then so be it. There isn't a need for us to clean up after somebody's horrendous long-identifier code. The only reason stuff like %.300s exists is to prevent buffer overflows. It isn't because we are parents looking after little children :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From Donald Beaudry Fri Jul 21 01:33:11 2000 From: Donald Beaudry (Donald Beaudry) Date: Thu, 20 Jul 2000 20:33:11 -0400 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> Message-ID: <200007210033.UAA31657@zippy.init.com> Greg Stein wrote, > Easier than ssh-agent is to create an "authorized_keys" file. Log onto the > shell box and type "mkdir .ssh". Next, copy the .ssh/identity.pub file from > your local machine to .ssh/authorized_keys on shell.sourceforge.net. > > From then on, SF will used the auth'd key rather than asking for your > password. That's mostly correct, but... you are assuming that the private side of the key (.ssh/identity on the local host) has not been encrypted with a passphrase. If it has, the scp command will prompt for it instead of the remote password. When using an encrypted private key ssh-agent is the answer. Personally, I am pretty paranoid about my private keys so (now ;) I always encrypt them. As a loose rule, I wont give anyone access to my systems (accept a public key) unless they at least tell me that their private key has been encrypted. How much trouble could could be caused by unauthorized access to your SF account? How secure is your private key? -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb@init.com Lexington, MA 02421 ...Will hack for sushi... From Moshe Zadka Fri Jul 21 05:21:02 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 21 Jul 2000 07:21:02 +0300 (IDT) Subject: [Python-Dev] [patch #100927] Fix for broken gethostbyname("0") In-Reply-To: <005d01bff298$d2fcd900$f2a6b5d4@hagrid> Message-ID: On Fri, 21 Jul 2000, Fredrik Lundh wrote: > this patch by Pekka Pessi adds support for "0" and "-1" > to gethostbyname: > > "0" (a string, not an integer) is the same thing as "" > (INADDR_ANY) > > "-1" is the same thing as "". > (INADDR_BROADCAST) > > Pekka hasn't followed up on my comments on the patch > page, so I thought I'd take the question to this forum in- > stead: > > -- why is gethostbyname "broken" if it doesn't > support the magic strings "0" and "-1"? > > I'm tempted to reject the patch, but I'm probably missing > something here... I'm -1 on the patch too. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas@xs4all.net Fri Jul 21 06:59:15 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 21 Jul 2000 07:59:15 +0200 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <200007210033.UAA31657@zippy.init.com>; from donb@init.com on Thu, Jul 20, 2000 at 08:33:11PM -0400 References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> Message-ID: <20000721075915.Y9897@xs4all.nl> On Thu, Jul 20, 2000 at 08:33:11PM -0400, Donald Beaudry wrote: > Greg Stein wrote, > > Easier than ssh-agent is to create an "authorized_keys" file. Log onto the > > shell box and type "mkdir .ssh". Next, copy the .ssh/identity.pub file from > > your local machine to .ssh/authorized_keys on shell.sourceforge.net. > > > > From then on, SF will used the auth'd key rather than asking for your > > password. > That's mostly correct, but... you are assuming that the private side > of the key (.ssh/identity on the local host) has not been encrypted > with a passphrase. If it has, the scp command will prompt for it > instead of the remote password. When using an encrypted private key > ssh-agent is the answer. > Personally, I am pretty paranoid about my private keys so (now ;) I > always encrypt them. As a loose rule, I wont give anyone access to my > systems (accept a public key) unless they at least tell me that their > private key has been encrypted. And that's perfectly sensible. I'm not a crypto-junkie in any way, but using ssh with non-passphrase-protected is dangerous stuff. We do use it, at XS4ALL, actually, for scripts to execute commands on remote machines, but we do it with seperate keysets, and restricted per host. Nevertheless, if one of those private keys ever gets stolen, it's very likely the thief can get access to semi-sensitive parts of our system. Using a authorized_keys scheme with an unencrypted private key makes your private key, something you 'have', your password, without coupling it to something you 'know'. So anyone who steals your private key can pretend to be you ;) For more security, I'd suggest a cronjob that connects to your ssh-agent first, and just bails out if you haven't an ssh-agent running. (That means a private key is only useful on a machine that also has an accompanying ssh-agent running, and the 'hacker' can assume your privileges. This is the case for the common root access hole, but not so if the machine is rebooted, for instance, to gain that root access, or if it's only a file-stealing hole instead of a full-access hole ;) Then again, I'm a system administrator for a high-profile ISP. I might be a tad paranoid myself ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Fri Jul 21 07:13:54 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 21 Jul 2000 08:13:54 +0200 Subject: [Python-Dev] [patch #100927] Fix for broken gethostbyname("0") In-Reply-To: <005d01bff298$d2fcd900$f2a6b5d4@hagrid>; from effbot@telia.com on Fri, Jul 21, 2000 at 12:21:08AM +0200 References: <005d01bff298$d2fcd900$f2a6b5d4@hagrid> Message-ID: <20000721081354.Z9897@xs4all.nl> On Fri, Jul 21, 2000 at 12:21:08AM +0200, Fredrik Lundh wrote: > Pekka hasn't followed up on my comments on the patch > page, so I thought I'd take the question to this forum in- > stead: > > -- why is gethostbyname "broken" if it doesn't > support the magic strings "0" and "-1"? > I'm tempted to reject the patch, but I'm probably missing > something here... Well, '0' is a valid ipaddress. Strange, but valid. An ipaddress needn't contain any dots ;) it's just a 32bit value, after all. The dot-notation is for convenience, mostly: centurion:~ > ping 0 PING 0 (0.0.0.0) from 127.0.0.1 : 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.1 ms (This is also the reason '127.0.0.1' can be written as '127.1') You can also type things like 'http://2224488794' in most browsers. Go ahead, try it ;) So I'd say: accept "0". It's valid behaviour. However, -1 is something else: centurion:~ > ping -- -1 ping: unknown host -1 I can see where it comes from, as it should be interpreted as 0xFFFFFFFF, but it's not a convention I'm aware of. And it's also not 'an ipaddress in dot notation', because there can't be negative values in an ipaddress even if you leave out the dots. All in all, I'm +1 on the first, -1 on the second. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Fri Jul 21 07:18:08 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 21 Jul 2000 08:18:08 +0200 Subject: [Python-Dev] Consistency questions In-Reply-To: <39773DBB.9480F7BF@prescod.net>; from paul@prescod.net on Thu, Jul 20, 2000 at 12:58:19PM -0500 References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> <20000720172108.S9897@xs4all.nl> <14711.8162.800169.884936@beluga.mojam.com> <39773DBB.9480F7BF@prescod.net> Message-ID: <20000721081808.A9897@xs4all.nl> On Thu, Jul 20, 2000 at 12:58:19PM -0500, Paul Prescod wrote: > I think that Thomas is right that there is going to be a fair bit of > code that manually worked around this limitation in dir and now will get > two copies of some attributes. What do you think about > attrs( foo ) Hm, "methods and attributes are different things, right ?" I catch my newbie colleagues thinking that all the time ;P How about 'ls' ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov@inrialpes.fr Fri Jul 21 13:27:45 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 21 Jul 2000 14:27:45 +0200 (CEST) Subject: [Python-Dev] object allocator Message-ID: <200007211227.OAA04028@python.inrialpes.fr> I've spent some time recently in reviving the pymalloc project, and now that Python has GC and is fairly clean w.r.t. its allocators, I think I'm going to suggest the inclusion of pymalloc as an object allocator (i.e. obmalloc). Three main reasons motivate this suggestion: 1. obmalloc keeps under control the memory allocated for most objects; 2. it compensates for the space overhead induced by GC; 3. it gives worthy speedups. To give it a try, see: http://starship.beopen.com/crew/vlad/pymalloc/ It's basically a VMM aware, generalized free list implementation which handles dynamically small mem blocks (small = under 64 bytes for combos with 4-byte pointers). This accounts for > 95% of all object structs allocated by Python. Thread safety is disabled (just like the other object-specific allocators). There's no profiling for the moment. I'm going to rewrite entirely the stats code, but still, give it a try in the meantime. I have only rough numbers, but my preliminary tests indicate that for memory consuming scripts, GC increases the peak mem usage by more than 5% (5 to 15% and up) compared to no-GC, and obmalloc decreases that to something in between GC and no-GC. Sometimes also below no-GC. This is due to the fact that obmalloc does not introduce per block overhead for every allocation, as standard libc mallocs do. I consistently get speedups of 3%-20% for long-enough running scripts (on Linux, Solaris and AIX). Regarding space, for low-mem consuming scripts, obmalloc increases the mem usage (reservation) as it preallocates & suballocates 256k blocks, but I'm not interested in low-mem consuming scripts. Things start to be interesting for higher mem consumptions. Just an example with regrtest.py on my setup: The (peak) requested memory is about 4 MB. GC adds 150 KB more compared to no-GC. With GC and with obmalloc, I sometimes get 100k less compared to no-GC. This is optimistic, but I won't argue more about it, because these are all virtual memory numbers. All this needs to be pursued, probably PEP'ed, but I think I can already emit my opinion about a compromise: If obmalloc.c gets in 2.0, I am okay to leave GC enabled for 2.0 final. Probably obmalloc needs to go in pair with GC. And Neil & al. can make use of it as a basis for further enhancements of the GC code (note that most of the object mem is now under Python's control). That said, it would be nice if you could test this code on your combos and report some results and impressions back here. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From nascheme@enme.ucalgary.ca Fri Jul 21 14:32:22 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 21 Jul 2000 07:32:22 -0600 Subject: [Python-Dev] object allocator In-Reply-To: <200007211227.OAA04028@python.inrialpes.fr>; from Vladimir Marangozov on Fri, Jul 21, 2000 at 02:27:45PM +0200 References: <200007211227.OAA04028@python.inrialpes.fr> Message-ID: <20000721073222.B25293@keymaster.enme.ucalgary.ca> Nice work Vladimir. I will definately check this out in more detail when I get my home computer back. I'm hoping we can group objects with gc_prev and gc_next pointers and reduce the memory overhead. Neil From skip@mojam.com (Skip Montanaro) Fri Jul 21 15:36:31 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 21 Jul 2000 09:36:31 -0500 (CDT) Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <200007210033.UAA31657@zippy.init.com> References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> Message-ID: <14712.24559.935141.849089@beluga.mojam.com> Donald> That's mostly correct, but... you are assuming that the private Donald> side of the key (.ssh/identity on the local host) has not been Donald> encrypted with a passphrase. If it has, the scp command will Donald> prompt for it instead of the remote password. When using an Donald> encrypted private key ssh-agent is the answer. Okay, someone has to admit ignorance. Might as well be me. ;-) 1. How can I tell if my .ssh/identity file has been encrypted? 2. If it hasn't, how do I encrypt it? When I run ssh-add, it prompts me for my passphrase. Is that sufficient to suggest I have an encrypted identity file? Skip From Donald Beaudry Fri Jul 21 15:44:47 2000 From: Donald Beaudry (Donald Beaudry) Date: Fri, 21 Jul 2000 10:44:47 -0400 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> <14712.24559.935141.849089@beluga.mojam.com> Message-ID: <200007211444.KAA04701@zippy.init.com> Skip Montanaro wrote, > Okay, someone has to admit ignorance. Might as well be me. ;-) > > 1. How can I tell if my .ssh/identity file has been encrypted? > 2. If it hasn't, how do I encrypt it? > > When I run ssh-add, it prompts me for my passphrase. Is that > sufficient to suggest I have an encrypted identity file? Yes. You will only be asked for a passphrase if your identity is encrypted. I dont know the answer to your first two questions. -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb@init.com Lexington, MA 02421 ...So much code, so little time... From peter@schneider-kamp.de Fri Jul 21 18:19:37 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 21 Jul 2000 17:19:37 +0000 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> <14712.24559.935141.849089@beluga.mojam.com> Message-ID: <39788629.85DE5CD7@schneider-kamp.de> Skip Montanaro wrote: > > Okay, someone has to admit ignorance. Might as well be me. ;-) > > 1. How can I tell if my .ssh/identity file has been encrypted? If you are prompted for a passphrase and giving that passphrase let's you work, then everything should be fine with your identity. > 2. If it hasn't, how do I encrypt it? You choose the passphrase when you generate the key with ssh-keygen. To change it call: ssh-keygen -p Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul@prescod.net Fri Jul 21 17:25:39 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 11:25:39 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 Message-ID: <39787983.9682ABC5@prescod.net> I don't have a PEP number for this yet but I wanted to go through another round of comments after changing the mechanism according to Don Beaudry's suggestions. The name has been changed because every attribute is computed at some point or another. The important thing is that we are defining methods that trap sets/gets to attributes. PEP: ??? Title: Attribute Access Handlers Version: $Revision: 1.0 $ Owner: paul@prescod.net Python-Version: 2.0 Status: Incomplete Introduction It is possible (and even relatively common) in Python code and in extension modules to "trap" when an instance's client code attempts to set an attribute and execute code instead. In other words it is possible to allow users to use attribute assignment/ retrieval/deletion syntax even though the underlying implementation is doing some computation rather than directly modifying a binding. This PEP describes a feature that makes it easier, more efficient and safer to implement these handlers in Python than it is today. Justification Scenario 1: You have a deployed class that works on an attribute named "stdout". After a while, you think it would be better to check that stdout is really an object with a "write" method at the moment of assignment. Rather than change to a setstdout method (which would be incompatible with deployed code) you would rather trap the assignment and check the object's type. Scenario 2: You want to be as compatible as possible with an object model that has a concept of attribute assignment. It could be the W3C Document Object Model or a particular COM interface (e.g. the PowerPoint interface). In that case you may well want attributes in the model to show up as attributes in the Python interface, even though the underlying implementation may not use attributes at all. Scenario 3: A user wants to make an attribute read-only. In short, this feature allows programmers to separate the interface of their module from the underlying implementation for whatever purpose. Again, this is not a new feature but merely a new syntax for an existing convention. Syntax Special methods should declare themselves with declarations of the following form: class x: def __attr_XXX__(self, op, val ): if op=="get": return someComputedValue(self.internal) elif op=="set": self.internal=someComputedValue(val) elif op=="del": del self.internal Client code looks like this: fooval=x.foo x.foo=fooval+5 del x.foo Semantics Attribute references of all three kinds should call the method. The op parameter can be "get"/"set"/"del". Of course this string will be interned so the actual checks for the string will be very fast. It is disallowed to actually have an attribute named XXX in the same instance as a method named __attr_XXX__. An implementation of __attr_XXX__ takes precedence over an implementation of __getattr__ based on the principle that __getattr__ is supposed to be invoked only after finding an appropriate attribute has failed. An implementation of __attr_XXX__ takes precedence over an implementation of __setattr__ in order to be consistent. The opposite choice seems fairly feasible also, however. The same goes for __del_y__. Proposed Implementation There is a new object called a computed attribute object. It has three attributes: get, set, delete. In PyClass_New, methods of the appropriate form will be detected and converted into objects (just like unbound method objects). Matching methods go in the same computed attribute object and missing methods are replaced with a stub that throws the TypeError. If there are any computed attributes at all, a flag is set. Let's call it "I_have_computed_attributes" for now. A get proceeds as usual until just before the object is returned. In addition to the current check whether the returned object is a method it would also check whether a returned object is a computed attribute. If so, it would invoke the getter method and return the value. To remove a computed attribute object you could directly fiddle with the dictionary. A set proceeds by checking the "I_have_computed_attributes" flag. If it is not set, everything proceeds as it does today. If it is set then we must do a dictionary get on the requested object name. If it returns a computed method attribute then we call the setter function with the value. If it returns any other object then we discard the result and continue as we do today. Note that having a computed attribute will affect attribute setting performance for all sets on a particular instance, but no more so than today. Gets are more efficient than they are today with __getattr__. The I_have_computed_attributes flag is intended to eliminate the performance degradation of an extra "get" per "set" for objects not using this feature. You might note that I have not proposed any logic to keep this flag up to date as attributes are added and removed from the instance's dictionary. This is consistent with current Python. If you add a __setattr__ method to an object after it is in use, that method will not behave as it would if it were available at "compile" time. The dynamism is arguably not worth the extra implementation effort. The implementation of delete is analogous to the implementation of set. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From nascheme@enme.ucalgary.ca Fri Jul 21 18:19:54 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 21 Jul 2000 11:19:54 -0600 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <39787983.9682ABC5@prescod.net>; from Paul Prescod on Fri, Jul 21, 2000 at 11:25:39AM -0500 References: <39787983.9682ABC5@prescod.net> Message-ID: <20000721111954.A27901@keymaster.enme.ucalgary.ca> On Fri, Jul 21, 2000 at 11:25:39AM -0500, Paul Prescod wrote: > PEP: ??? > Title: Attribute Access Handlers > Version: $Revision: 1.0 $ > Owner: paul@prescod.net > Python-Version: 2.0 > Status: Incomplete So far I'm a strong +1. I dislike the all or nothing approach of __setattr__ and the performance cost associated with it. Support for "attribute access handlers" should largely eliminate the need for writing attribute access wrappers (getters and setters). The benefits are that code is simpler (you can use object attributes directly for outside the class), performance is better, and you always have the option of computing the value in the future without changing code that uses the object. Neil From Vladimir.Marangozov@inrialpes.fr Fri Jul 21 18:26:15 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 21 Jul 2000 19:26:15 +0200 (CEST) Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <39787983.9682ABC5@prescod.net> from "Paul Prescod" at Jul 21, 2000 11:25:39 AM Message-ID: <200007211726.TAA04540@python.inrialpes.fr> Paul Prescod wrote: > > I don't have a PEP number for this yet but I wanted to go through > another round of comments after changing the mechanism according to Don > Beaudry's suggestions. > > The name has been changed because every attribute is computed at some > point or another. The important thing is that we are defining methods > that trap sets/gets to attributes. Paul, this is clearly unclear <0.1 wink>. I for one don't get it. The whole point of __getattr__, __setattr__ is to trap attribute accesses and assignment. Python lets you trap the attribute binding process through these two functions. At yes, it is common case, because people want to specialize the binding rules in an object's namespace. However, this is defined only for Python's instance objects. If this is intended to generalize the concept for builtin objects, then you reach the object model deficiencies (metacalass, type dochotomy, etc.) which is not a trivial problem. If you're running after performance, because this programmable trapping occurs only in Python, well, state it explicitely in your writing. I believe that you're running after the generalization. I am not sure that what's in this per-PEP is a generic solution though. Because you're discussing handlers written in Pythonland (and this is also unclear in your writing). Simply put, these handlers would be invoked by hooks taken into account by the C code. Except hooking dict lookups with Python or C handlers, I don't see the point of this PEP. If the handlers are written in Python, this is what you get with __getattr__ and __setattr__. If you think C handlers, well, tell us about it explicitely. or-I-am-missing-the-point-completely y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gmcm@hypernet.com Fri Jul 21 18:45:27 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Fri, 21 Jul 2000 13:45:27 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <39787983.9682ABC5@prescod.net> Message-ID: <1247920968-15427430@hypernet.com> > I don't have a PEP number for this yet but I wanted to go through > another round of comments after changing the mechanism according > to Don Beaudry's suggestions. [snip] > Proposed Implementation > > There is a new object called a computed attribute object. It > has three attributes: get, set, delete. raise InternalInconsistencyError - Gordon From Fredrik Lundh" Message-ID: <001a01bff341$f63119a0$f2a6b5d4@hagrid> some comments: > + * SyntaxError enhancements - Fredrik Lundh > + = http://www.python.org/pipermail/python-dev/2000-July/012981.html ouch. what part of this "proposal" has been accepted? hopefully the latter part (the "error number" part). > + * snprintf - owner??? > + Use snprintf to avoid buffer overflows. Need configure = hackery > + to discovery if it is available on the current platform and a > + default implementation if it is not. > + = http://www.python.org/pipermail/python-dev/2000-April/010051.html > + This function is expected to be part of C9X (check). patch #100895, I hope. note that snprintf and this implementation are not equivalent (the safe version of PyErr_Format allocates a buffer large enough to hold the message). ... btw, don't forget patch #100941 (a bug fix to the new windows popen code). I'm working on a slightly modified version of David's patch -- should be ready for check in on monday... From paul@prescod.net Fri Jul 21 19:39:19 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 13:39:19 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <200007211726.TAA04540@python.inrialpes.fr> Message-ID: <397898D7.1D16A2B@prescod.net> Vladimir Marangozov wrote: > >... > Paul, this is clearly unclear <0.1 wink>. I for one don't get it. > The whole point of __getattr__, __setattr__ is to trap attribute > accesses and assignment. Sure, but ALL attribute accesses and assignment. What if you just want to trap one or two or ten? > However, this is defined only for Python's instance objects. If this > is intended to generalize the concept for builtin objects, then you > reach the object model deficiencies (metacalass, type dochotomy, etc.) > which is not a trivial problem. This feature has nothing to do with built-in types. Built-in types *always* use the getattr convention anyhow. > If you're running after performance, because this programmable trapping > occurs only in Python, well, state it explicitely in your writing. I mentioned performance explicitly in the introduction: > This PEP describes a feature that makes it easier, more efficient > and safer to implement these handlers in Python than it is today. Performance is only one of the goals. Clarity is the more major one. Safety is another. When you start combining __getattr__ with multiply inherited base class __getattr__ and so forth you get into a real mess. This proposal does not have that problem. > If the handlers are written in Python, this is what you get with __getattr__ > and __setattr__. If you think C handlers, well, tell us about it explicitely. The proposal explicitly says that the propsal allows nothing that getattr and setattr do not already allow. If you're looking for something that they do that this doesn't, you won't find it. Rather: > This PEP describes a feature that makes it easier, more efficient > and safer to implement these handlers in Python than it is today. Not a new ability, just a more structured way to exercise it. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul@prescod.net Fri Jul 21 19:49:23 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 13:49:23 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <1247920968-15427430@hypernet.com> Message-ID: <39789B33.4C01AC03@prescod.net> Gordon McMillan wrote: > > [snip] > > > Proposed Implementation > > > > There is a new object called a computed attribute object. It > > has three attributes: get, set, delete. > > raise InternalInconsistencyError Good point. Here's a fix for that and something else I left out before. There is a new object type called a computed attribute object. Objects of this type have the following attributes: name (e.g. XXX, not __attr__XXX__ method (pointer to a method object In PyClass_New, methods of the appropriate form will be detected and converted into objects (just like unbound method objects). If there are any computed attributes in an instance at all, a flag is set. Let's call it "I_have_computed_attributes" for now. Derived classes inherit the flag from base classes. Instances inherit the flag from classes. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From Donald Beaudry Fri Jul 21 19:54:13 2000 From: Donald Beaudry (Donald Beaudry) Date: Fri, 21 Jul 2000 14:54:13 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <200007211726.TAA04540@python.inrialpes.fr> Message-ID: <200007211854.OAA06814@zippy.init.com> Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) wrote, > Paul, this is clearly unclear <0.1 wink>. I for one don't get it. > The whole point of __getattr__, __setattr__ is to trap attribute > accesses and assignment. Python lets you trap the attribute binding > process through these two functions. At yes, it is common case, > because people want to specialize the binding rules in an object's > namespace. The __getattr__ and __setattr__ mechanism is useful but hard to use. Paul's proposal suggests makeing it easier to override access for a single attribute.... or am I unclear on what you are unclear about? > However, this is defined only for Python's instance objects. If this > is intended to generalize the concept for builtin objects, then you > reach the object model deficiencies (metacalass, type dochotomy, etc.) > which is not a trivial problem. Whoa.... where did that come from. While the idea behind Paul's proposal could easily be applied to builtin objects (I've been using the technique for years) he's not even mentioning them in the proposal. It would still be up to the extension writer to decide how best to implement tp_setattr and tp_getattr. Only the instanceobject's tp_setattr and tp_getattr would need to change. > If you're running after performance, because this programmable > trapping occurs only in Python, well, state it explicitely in your > writing. I dont see performance as the big issue here. What I do see is a tidying up of a common usage of the current __setattr__/__getattr__ mechanism. For better or worse, it will make it much easier to write code which controls access to an attribute. > I believe that you're running after the generalization. I am not > sure that what's in this per-PEP is a generic solution > though. Because you're discussing handlers written in Pythonland > (and this is also unclear in your writing). Simply put, these > handlers would be invoked by hooks taken into account by the C > code. Except hooking dict lookups with Python or C handlers, I don't > see the point of this PEP. Wow! What does Paul's proposal have to do with hooking dict lookups? ...or is that what you are wondering? If that's what you are wondering, wonder no more. There is no connection. > If the handlers are written in Python, this is what you get with > __getattr__ and __setattr__. If you think C handlers, well, tell us > about it explicitely. Ah... now I see where *you* think Paul is going. To implement this, I would write up a little object called attrobject which would be very similar to a instancemethod. When the class is created I would check for methods whos names matched the __attr__XXX pattern. For each of these methods I would create an attrobject to wrap it then stick that back in the class dictionary under the name XXX. The tp_getattr method would then go through it's normal lookup procedure. But, before returning the result it would check the type of the object. If the object is an attrobject, the associated method would be called. The result of that call would be return from tp_getattr. The tp_setattr changes are where Paul's proposal loses. To make this work it becomes necessary to first attempt a "modified" getattr to determine if an attrobject exist for this attribute. I say "modified" getattr because in this case we dont really want to evaluate the attrobject. If no attrobject exists for the named attribute the set operation proceed as usual. If one does exist, it's associated method is called with the specified value. What hurts here is that it is now necessary to do that "modified" getattr on each set operation. If this is what you mean by "C handlers", then that's what Paul (in my opinion) is saying. Otherwise... -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb@init.com Lexington, MA 02421 ...Will hack for sushi... From Donald Beaudry Fri Jul 21 20:00:00 2000 From: Donald Beaudry (Donald Beaudry) Date: Fri, 21 Jul 2000 15:00:00 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <1247920968-15427430@hypernet.com> Message-ID: <200007211900.PAA06902@zippy.init.com> try: "Gordon McMillan" wrote, > > Proposed Implementation > > > > There is a new object called a computed attribute object. It > > has three attributes: get, set, delete. > > raise InternalInconsistencyError except InternalInconsistencyError: see_previous_posts_suggesting_get_set_del_all_be_moved_to_a_single_method() -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb@init.com Lexington, MA 02421 ...So much code, so little time... From bwarsaw@beopen.com Fri Jul 21 20:17:57 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 21 Jul 2000 15:17:57 -0400 (EDT) Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> <20000721075915.Y9897@xs4all.nl> Message-ID: <14712.41445.595701.546261@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> And that's perfectly sensible. I'm not a crypto-junkie in any TW> way, but using ssh with non-passphrase-protected is dangerous TW> stuff. We do use it, at XS4ALL, actually, for scripts to TW> execute commands on remote machines, but we do it with TW> seperate keysets, and restricted per host. Right, that's the way to do it. Remember that you can have multiple keypairs associated with your shell account, so if you /really/ wanted to do this (and I don't suggest it), then generate a new keypair, leave the new private key unpassphrase protected, and upload the new keypair to SF. Use this keypair only for SF so if it's cracked your exposure is minimized. As paranoid as I am, I usually generate new keypairs when I travel with my ssh client. I use that keypair only for that trip and discard it when I get back. -Barry From bwarsaw@beopen.com Fri Jul 21 20:30:33 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 21 Jul 2000 15:30:33 -0400 (EDT) Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> Message-ID: <14712.42201.725616.586420@anthem.concentric.net> >>>>> "PS" == Peter Schneider-Kamp writes: PS> I have put up the PEPs on http://python.sourceforge.net/peps/ Very cool, thanks! And thanks to /F for his conversion script PS> 1) Is that okay? No one cried out aloud and I got some PS> agreement. Yes, but I would make a couple of suggestions. 1) Let's change the project homepage to point to python.sourceforge.net with a prominent link back to www.python.org. Otherwise, /finding/ these peps and the other useful information isn't as convenient. 2) I'm not crazy about the front page for python.sourceforge.net. Do the links go with the blue box above or below the link? The first box say "On this site..." Which is this site? python.sourceforge.net or the site pointed to by the link above (or below :)? Do the blue boxes serve any real purpose? PS> 2) Should I put a link from http://python.sourceforge.net ? Which of course you did, so thanks! PS> 3) What about making those PEPs xhtml (or something like PS> that)? | Pros: | - links from pep-000.txt | - links from the other peps | Cons: | - harder to read in checkins | - harder to edit | (maybe we could use as little markup as possible?) Definitely -1 as other have said. PEPs should be plain text. /F's conversion script is perfect. -Barry From paul@prescod.net Fri Jul 21 20:36:47 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 14:36:47 -0500 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> Message-ID: <3978A64F.249C22F3@prescod.net> "Barry A. Warsaw" wrote: > > 2) I'm not crazy about the front page for python.sourceforge.net. > Do the links go with the blue box above or below the link? The > first box say "On this site..." Which is this site? > python.sourceforge.net or the site pointed to by the link above (or > below :)? Do the blue boxes serve any real purpose? A clear title at the top would be good. The other titles don't need to be in all caps. The blue tables are not necessary. Keep it simple Schneider-Kamp :) Still, what is there is so much better than what was there before that I feel bad complaining. It's definately an important development! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gmcm@hypernet.com Fri Jul 21 20:58:20 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Fri, 21 Jul 2000 15:58:20 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <397898D7.1D16A2B@prescod.net> Message-ID: <1247912995-15907044@hypernet.com> Paul Prescod wrote: > Performance is only one of the goals. Clarity is the more major > one. Safety is another. When you start combining __getattr__ with > multiply inherited base class __getattr__ and so forth you get > into a real mess. This proposal does not have that problem. You're doing some obsfucating here. Overriding a method with multiple base class implementations of that method with the desire to chain to one or more of the base class implementations of that method is a mess. It's not more of a mess because the method is named __getattr__. The obvious solution has nothing to do with the language - it's to use has-a instead of is-a. This proposal changes those semantics. Hooking an attribute masks anything in a base class with that name. That's probably a good thing, but it should be made explicit since that's not the way __getattr__ behaves. Similarly, there's a difference from __setattr__. If you assign to the instance.__dict__, the hook will no longer apply for that instance / attribute. Also note that while this is *safer* than __xxxattr__, it's still not *safe*. Infinite recursion is less likely, but still easily achieved. Truth-in-PEPs-ly y'rs - Gordon From paul@prescod.net Fri Jul 21 21:38:25 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 15:38:25 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <1247912995-15907044@hypernet.com> Message-ID: <3978B4C1.99BDD4CF@prescod.net> Gordon McMillan wrote: > > ... > > You're doing some obsfucating here. Overriding a method with > multiple base class implementations of that method with the > desire to chain to one or more of the base class > implementations of that method is a mess. It's not more of a > mess because the method is named __getattr__. > ... Solving the particular problem I am trying to solve is extremely messy in a deep hiearchy with one or more __getattr__ implementations. You must know about all of the parent getattrs and understand their semantics enough to to decide what order to call them in. If you think of getattr as "just another method" then there is no problem but it isn't just another method. It's a method that is used to implement a variety of radically different patterns. > This proposal changes those semantics. Hooking an attribute > masks anything in a base class with that name. That's > probably a good thing, but it should be made explicit since > that's not the way __getattr__ behaves. I don't see the difference. def __attr_XXX__( self, op, va ): Parent.__attr_XXX__( self, op, val ) You can still chain if you want. > Similarly, there's a difference from __setattr__. If you assign to > the instance.__dict__, the hook will no longer apply for that > instance / attribute. That's true. > Also note that while this is *safer* than __xxxattr__, it's still > not *safe*. Infinite recursion is less likely, but still easily > achieved. The ability to recurse infinitely is a property of methods in general, not this method in particular. Okay, it is a little more likely because of a logic flaw but I don't see that as being unsafe. I see the current __getattr__ hacks as being unsafe because in a deep inheritance hierarchy a seemingly insignicant addition in one place will break code somewhere else. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From gmcm@hypernet.com Fri Jul 21 22:27:29 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Fri, 21 Jul 2000 17:27:29 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <3978B4C1.99BDD4CF@prescod.net> Message-ID: <1247907646-16228779@hypernet.com> Paul Prescod wrote: > Gordon McMillan wrote: > > This proposal changes those semantics. Hooking an attribute > > masks anything in a base class with that name. That's probably > > a good thing, but it should be made explicit since that's not > > the way __getattr__ behaves. > > I don't see the difference. > > def __attr_XXX__( self, op, va ): > Parent.__attr_XXX__( self, op, val ) > > You can still chain if you want. You can? Your proposal only specified that when the class object is being created, method names of the form __attr_XXX__ would cause stuff to happen in the way the class is built. You never said that accesses to things named __YYY_XXX__ on another object would also get transformed into something else. Also, what if the base class just has "attr" - not a hook at all? It will be masked by the hook (which is the difference in behavior I was pointing out). > > Similarly, there's a difference from __setattr__. If you assign > > to the instance.__dict__, the hook will no longer apply for > > that instance / attribute. > > That's true. > > > Also note that while this is *safer* than __xxxattr__, it's > > still not *safe*. Infinite recursion is less likely, but still > > easily achieved. > > The ability to recurse infinitely is a property of methods in > general, not this method in particular. Okay, it is a little more > likely because of a logic flaw but I don't see that as being > unsafe. And earlier I said: > > Overriding a method with > > multiple base class implementations of that method with the > > desire to chain to one or more of the base class > > implementations of that method is a mess. It's not more of a > > mess because the method is named __getattr__. ... So I guess we're even, since we've used the same argument both ways. > I see the current __getattr__ hacks as being unsafe because in a > deep inheritance hierarchy a seemingly insignicant addition in > one place will break code somewhere else. Deep inheritance hierarchies are unpythonic <0.001 wink>. - Gordon From paul@prescod.net Fri Jul 21 22:54:24 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 16:54:24 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <1247907646-16228779@hypernet.com> Message-ID: <3978C690.ED273B22@prescod.net> Gordon McMillan wrote: > > You can? Your proposal only specified that when the class > object is being created, method names of the form > __attr_XXX__ would cause stuff to happen in the way the class > is built. You never said that accesses to things named > __YYY_XXX__ on another object would also get transformed > into something else. I would say that __attr_XXX__ causes two things to go into the __dict__: __attr_XXX___ = XXX = So you can call __attr_XXX__ directly just as you can call __getattr__ directly or __init__ etc. > Deep inheritance hierarchies are unpythonic <0.001 wink>. I'm told that in Zope even shallow hiearchies that use __getattr__ cause problems. I proposed this idea about three years ago. I'm only bringing it up again now because of a problem getting the DOM to work with Zope because of Zope's use of __getattr__. I'm told this has gotten better recently but I still see it as a symptom of a problem. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From bckfnn@worldonline.dk Fri Jul 21 22:59:53 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Fri, 21 Jul 2000 21:59:53 GMT Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <39787983.9682ABC5@prescod.net> References: <39787983.9682ABC5@prescod.net> Message-ID: <3978c7bf.10449886@smtp.worldonline.dk> [Paul Prescod on computed attributes] I'm not sure how well this is connected, but I would like to describe an existing feature of JPython that allow for computed attributes. The implementation of every python object have three methods (a little simplified): public PyObject _doget(PyObject container) { return this; } public boolean _doset(PyObject container, PyObject value) { return false; } public boolean _dodel(PyObject container) { return false; } As part of the implementation of __getattr__, the _doget method is always called: public PyObject __findattr__(String name) { ... PyObject ret = __class__.lookup(name, false); if (ret != null) return ret._doget(this); return null; } This way each computed attribute get controll when accessed, modified and deleted. The hooks primary purpose is to support JPythons use of java bean properties, fields and methods. It is currently not available from within python, so it is not possible to define "def _doget(..)" in a python class. All this is just a datapoint. regards, finn From bwarsaw@beopen.com Sat Jul 22 01:16:37 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 21 Jul 2000 20:16:37 -0400 (EDT) Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <39787983.9682ABC5@prescod.net> <3978c7bf.10449886@smtp.worldonline.dk> Message-ID: <14712.59365.265600.645342@anthem.concentric.net> >>>>> "FB" == Finn Bock writes: FB> This way each computed attribute get controll when accessed, FB> modified and deleted. The hooks primary purpose is to support FB> JPythons use of java bean properties, fields and methods. It FB> is currently not available from within python, so it is not FB> possible to define "def _doget(..)" in a python class. FB> All this is just a datapoint. But a good one, and perhaps one to model CPython on. There are also similarities here with the Zope Acquisition model, which uses __of__ instead. So this is clearly a functionality that is very useful in some contexts. JPython's __findattr__ hook might also be useful because it allows interposition on the lookup of all names, i.e. not just missing names. In any event, we should look to JPython as an example of how it might be done, but once a formal mechanism is adopted for CPython, we'll add it to the language spec and update JPython to support the same mechanism. -Barry From NO_SPAM_hzhu@knowledgetrack_dot_com.python.org Sat Jul 22 03:08:22 2000 From: NO_SPAM_hzhu@knowledgetrack_dot_com.python.org (Huaiyu Zhu) Date: Fri, 21 Jul 2000 19:08:22 -0700 Subject: [Python-Dev] Re: questionnaire about zip and for loops In-Reply-To: <3976BDF7.82FB6C56@schneider-kamp.de> References: <3976BDF7.82FB6C56@schneider-kamp.de> Message-ID: <200007220208.TAA00997@rocket.knowledgetrack.com> You need to add a Reply-To: line so people wouldn't send to the list by mistake. It is also difficult for many editors and mailers to deal with long lines. Huaiyu In comp.lang.python, you wrote: >This is a slightly reduced version of a questionnaire run by Greg Wilson on some CS >grad students. > >I'd like to use the readers of comp.lang.python as guinea pigs this time. > >PLEASE SEND THE RESULTS TO mailto:peter@schneider-kamp.de - DON'T SEND THEM TO THE LIST > >Thanks for your time, >Peter > >----------------------------------------------------------------------------------------- > >The single and double loop below print the output shown: > >for x in [10, 20, 30]: for x in [10, 20, 30]: > print x for y in [1, 2, 3]: > print x+y >10 11 >20 12 >30 13 > 21 > 22 > 23 > 31 > 32 > 33 > >Match each of the following example for-loops to an output. Only make one cross per line. >Please consider each example on its own. >(Note that several examples may print the same thing.) > > > (1) (2) (3) (4) (5) (6) > > 11 11 11 11 error ?? > 22 12 22 12 > 33 13 21 > 21 22 > 22 31 > 23 32 > 31 > 32 > 33 > >(A) >for (x, y) in [[10, 1], [20, 2], [30, 3]]: x o o o o o > print x+y > >(B) >for [x, y] in zip([10, 20, 30], [1, 2, 3]): x o o o o o > print x+y > >(C) >for [x, y] in zip([10, 20, 30], [1, 2]): o o x o o o > print x+y > >(D) >for x; y in [10, 20, 30]; [1, 2, 3]: o o o o x o > print x+y > >(E) >for x; y in [10, 20, 30]; [1, 2]: o o o o x o > print x+y > >(F) >for x in [10, 20, 30]; y in [1, 2, 3]: o x o o o o > print x+y > >(G) >for x in [10, 20, 30]; y in [1, 2]: o o o x o o > print x+y > > >-- >Peter Schneider-Kamp ++47-7388-7331 >Herman Krags veg 51-11 mailto:peter@schneider-kamp.de >N-7050 Trondheim http://schneider-kamp.de > From peter@schneider-kamp.de Sat Jul 22 05:59:38 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 04:59:38 +0000 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> Message-ID: <39792A39.B5C71052@schneider-kamp.de> "Barry A. Warsaw" wrote: > > >>>>> "PS" == Peter Schneider-Kamp writes: > > PS> I have put up the PEPs on http://python.sourceforge.net/peps/ > > Very cool, thanks! And thanks to /F for his conversion script > > PS> 1) Is that okay? No one cried out aloud and I got some > PS> agreement. > > Yes, but I would make a couple of suggestions. > > 1) Let's change the project homepage to point to > python.sourceforge.net with a prominent link back to > www.python.org. Otherwise, /finding/ these peps and the other > useful information isn't as convenient. > > 2) I'm not crazy about the front page for python.sourceforge.net. > Do the links go with the blue box above or below the link? The > first box say "On this site..." Which is this site? > python.sourceforge.net or the site pointed to by the link above (or > below :)? Do the blue boxes serve any real purpose? I'm no big bad designer guy. I didn't like it either, but I figured that (as it is in the CVS) someone would come around and put something nicer there. Well, I've tried my luck once again. Hope this one is better: http://python.sourceforge.net feedback-appreciating-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From peter@schneider-kamp.de Sat Jul 22 06:03:39 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 05:03:39 +0000 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> Message-ID: <39792B2B.DA3D36DC@schneider-kamp.de> "Barry A. Warsaw" wrote: > > 1) Let's change the project homepage to point to > python.sourceforge.net with a prominent link back to > www.python.org. Otherwise, /finding/ these peps and the other > useful information isn't as convenient. Ah yes. If this is considered to be a Wise Idea(TM), then could someone with admin rights change this? ain't-no-project-admin-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul@prescod.net Sat Jul 22 04:07:48 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 22:07:48 -0500 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> <39792A39.B5C71052@schneider-kamp.de> Message-ID: <39791004.95AA6994@prescod.net> Peter Schneider-Kamp wrote: > >... > > Well, I've tried my luck once again. Hope this one is better: > http://python.sourceforge.net It's a beaut! Uncluttered and clean. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From bwarsaw@beopen.com Sat Jul 22 04:48:12 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 21 Jul 2000 23:48:12 -0400 (EDT) Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> <39792A39.B5C71052@schneider-kamp.de> Message-ID: <14713.6524.705655.958481@anthem.concentric.net> >>>>> "PS" == Peter Schneider-Kamp writes: PS> I'm no big bad designer guy. I didn't like it either, but I PS> figured that (as it is in the CVS) someone would come around PS> and put something nicer there. PS> Well, I've tried my luck once again. Hope this one is better: PS> http://python.sourceforge.net Perfect! >> 1) Let's change the project homepage to point to >> python.sourceforge.net with a prominent link back to >> www.python.org. Otherwise, /finding/ these peps and the other >> useful information isn't as convenient. PS> Ah yes. If this is considered to be a Wise Idea(TM), then PS> could someone with admin rights change this? Done. Thanks, -Barry From bwarsaw@beopen.com Sat Jul 22 05:47:32 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sat, 22 Jul 2000 00:47:32 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP Message-ID: <14713.10084.165489.836569@anthem.concentric.net> I've long wanted to make the print statement able to handle alternative output files in a more convenient syntax. Yes you can rebind sys.stdout, but that is often very clumsy to get right in the face of exceptions. All the talk about extra operators has made me giddy (no, not geddy :) so my proposal is to allow `@' after the print keyword using syntax such as: print @ sys.stderr, 'hello' The thing between the @ and the , must be an expression yeilding an object with a write() method, otherwise you'd get a runtime exception (probably TypeError). Thus, these two are equivalent: print @ sys.stdout, 'wassup?' print 'wassup?' It makes it quite convenient to do things like: f = open('log, 'w') print @ f, 'starting' do_something_that_expects_to_print_to_stdout() print @ f, 'ending' etc., etc. I started hacking on the grammar to play with this, but haven't gotten very far, and I'm way too tired to continue tonight. I'd continue though if there's positive feedback. Thoughts? -Barry From Moshe Zadka Sat Jul 22 07:49:57 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 22 Jul 2000 09:49:57 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.10084.165489.836569@anthem.concentric.net> Message-ID: On Sat, 22 Jul 2000, Barry A. Warsaw wrote: > I've long wanted to make the print statement able to handle > alternative output files in a more convenient syntax. Yes you can > rebind sys.stdout, but that is often very clumsy to get right in the > face of exceptions. Then why not go the other way, and get sys.stdout-rebinding easier to get right? something like sys.push_stdout(fileobj) try: print and stuff finally: sys.pop_stdout() > Thoughts? Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating Python way too much. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From tim_one@email.msn.com Sat Jul 22 08:06:59 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 03:06:59 -0400 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <20000720221300.W9897@xs4all.nl> Message-ID: [posted & mailed] [Thomas Wouters] > ... > However, I found a lot of instances of the 2nd type: empty argument > list. However, as far as I remember, ANSI C states that should be > written as '(void)'. Yes. > I also found a number of files which were already converted to > ANSI syntax, but with one function leftover. Should I bother' uploading > a patch for those, or can I just commit them ? Commit. hard-not-to-make-the-sig-look-concise-after-that!-ly y'rs - tim From mhammond@skippinet.com.au Sat Jul 22 08:18:13 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sat, 22 Jul 2000 17:18:13 +1000 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: Message-ID: > Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating > Python way too much. I've gotta agree here - I really am quite concerned about all the cool-but-not-really-necessary stuff being proposed. I fear that Python will no longer be the small, simple to understand system that drew many of us to it in the first place. OTOH, I have great faith that Guido will simply reject most of these ideas, regardless of the huge amount of work being spent on their PEPs, etc. At least, I _hope_ he does! Our-simple-Python-is-turning-into-Medusa-ly, Mark. From tim_one@email.msn.com Sat Jul 22 08:30:00 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 03:30:00 -0400 Subject: [Python-Dev] map() for methods In-Reply-To: <39771CCE.F70A48D4@lemburg.com> Message-ID: [Skip Montanaro] > Don't know about the powers that be, but I don't see how you can > realistically deprecate string.py until you deprecate map(). My most > frequent use of map() is the simple > > newlist = map(string.strip, oldlist) > > where oldlist is a list of strings. (Replace "strip" by > "upper", "lower", etc, depending on your needs.) > > As far as I'm aware, there's no clean way to do that with > string methods. Sorry if someone pointed this out already (2K+ msgs backed up!): newlist = [s.strip() for s in oldlist] Not that that's a reason to deprecate string.py, but this use of "map" is not a reason not to deprecate it either. Ditto for "map". From gstein@lyra.org Sat Jul 22 09:27:48 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 22 Jul 2000 01:27:48 -0700 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.10084.165489.836569@anthem.concentric.net>; from bwarsaw@beopen.com on Sat, Jul 22, 2000 at 12:47:32AM -0400 References: <14713.10084.165489.836569@anthem.concentric.net> Message-ID: <20000722012748.E10086@lyra.org> On Sat, Jul 22, 2000 at 12:47:32AM -0400, Barry A. Warsaw wrote: >... > All the talk about extra operators has made me giddy (no, not geddy :) > so my proposal is to allow `@' after the print keyword using syntax > such as: > > print @ sys.stderr, 'hello' Ick. -1 Use sys.stderr.write('hello\n') Cheers, -g -- Greg Stein, http://www.lyra.org/ From thomas@xs4all.net Sat Jul 22 09:32:05 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 10:32:05 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.10084.165489.836569@anthem.concentric.net>; from bwarsaw@beopen.com on Sat, Jul 22, 2000 at 12:47:32AM -0400 References: <14713.10084.165489.836569@anthem.concentric.net> Message-ID: <20000722103204.G9897@xs4all.nl> On Sat, Jul 22, 2000 at 12:47:32AM -0400, Barry A. Warsaw wrote: > I've long wanted to make the print statement able to handle > alternative output files in a more convenient syntax. Yes you can > rebind sys.stdout, but that is often very clumsy to get right in the > face of exceptions. > print @ sys.stderr, 'hello' No offense, but I'd rather deprecate 'print' than see this. For me, 'print' is for debugging purposes only (and possibly very teensy scripts.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From peter@schneider-kamp.de Sat Jul 22 11:33:29 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 10:33:29 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.7,1.8 References: <200007212003.NAA02595@slayer.i.sourceforge.net> Message-ID: <39797879.C63724A8@schneider-kamp.de> Barry Warsaw wrote: > > + 212 pep-0212.txt Additional Builtin Generators bwarsaw Whatever happened to 212? If you don't have anything ready yet I can commit an empty version. Just tell me. BTW: I cannot ssh to shell.sourceforge.net. It worked fine 5 hours ago. CVS over ssh works fine though. I sent a support request. I tried from different machines from different countries, with password or key identification (it never got so far). Is anyone experiencing similar problems? eating-breakfast-soon-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From thomas@xs4all.net Sat Jul 22 09:47:13 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 10:47:13 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 22, 2000 at 03:06:59AM -0400 References: <20000720221300.W9897@xs4all.nl> Message-ID: <20000722104713.H9897@xs4all.nl> On Sat, Jul 22, 2000 at 03:06:59AM -0400, Tim Peters wrote: > > I also found a number of files which were already converted to > > ANSI syntax, but with one function leftover. Should I bother' uploading > > a patch for those, or can I just commit them ? > Commit. Well, I already did that ;) I've also ANSIfied everything in Python/ and Parser/, and the couple of declarations in PC/ that were still using empty argument lists. The changes fall in two categories: those I can test (and have tested and seem to work fine) and those that I can't test because I haven't such expensive hardware. I'll upload the latter category, and I'm perfectly willing to upload the former one, too, but I wonder if anyone is actually going to review them ? If not, well, there's not much use in uploading them, is there ? Also, there is an issue with extern function declarations: should we change all those to full prototypes ? Some aren't too obvious (like the ^*@#$&** readline functions, which don't have prototypes to start with, and the info pages are not very helpful) and in one spot a function of the wrong type is passed to PyAddCallback, resulting in a new warning during -Wall ;) A cast can fix that, though. And then there is the question whether all those externs are really necessary. They seem to be put in because one OS or another was missing them in a header file, but giving them prototypes from a Linux system might give more warnings on other platforms: a 'const char **' is not the same pointer as a 'char **', even though a 'const char *' is the same as a 'char *'. Perhaps these prototyped function declarations should be put in pyport.h, instead, surrounded by platform #ifdefs ? Make-me-checkin-all-these-changes-and-I'll-end-up-next-to-Guido-on-the- -SourceForge-CVS-stats-ly y'rs, ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Fredrik Lundh" Message-ID: <00d601bff3ba$8300d640$f2a6b5d4@hagrid> mark wrote: > I've gotta agree here - I really am quite concerned about all the > cool-but-not-really-necessary stuff being proposed. I fear that = Python > will no longer be the small, simple to understand system that drew = many of > us to it in the first place. that's only because you're a lazy guy, and don't want to have to implement one weird thing after another in your compiler, just be- cause someone submitted a patch to CPython ;-) (seriously, I *strongly* agree with what you're saying, but you already knew that, of course... or maybe that's just because I'm a lazy guy, and don't want to implement one weird thing after an- other in my tools) > OTOH, I have great faith that Guido will simply reject most of these = ideas, > regardless of the huge amount of work being spent on their PEPs, etc. = At > least, I _hope_ he does! well, if he doesn't, we can always join the Perl6 project... > Our-simple-Python-is-turning-into-Medusa-ly, hey, what's wrong with Sam's Medusa server? ;-) From thomas@xs4all.net Sat Jul 22 09:51:58 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 10:51:58 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.7,1.8 In-Reply-To: <39797879.C63724A8@schneider-kamp.de>; from peter@schneider-kamp.de on Sat, Jul 22, 2000 at 10:33:29AM +0000 References: <200007212003.NAA02595@slayer.i.sourceforge.net> <39797879.C63724A8@schneider-kamp.de> Message-ID: <20000722105158.I9897@xs4all.nl> On Sat, Jul 22, 2000 at 10:33:29AM +0000, Peter Schneider-Kamp wrote: > Barry Warsaw wrote: > > + 212 pep-0212.txt Additional Builtin Generators bwarsaw > Whatever happened to 212? If you don't have anything ready yet > I can commit an empty version. Just tell me. 'Whatever happened' is that Barry assigned himself to that PEP just yesterday, and has been too busy with all those other things to check even the template in ;) > BTW: I cannot ssh to shell.sourceforge.net. It worked fine 5 hours > ago. CVS over ssh works fine though. I sent a support request. > Is anyone experiencing similar problems? Ayup: centurion:~/python/python-anon/dist/src/Python > ssh -v shell.sourceforge.net SSH Version 1.2.27 [i586-unknown-linux], protocol version 1.5. Standard version. Does not use RSAREF. centurion.xs4all.nl: Reading configuration data /home/thomas/.ssh/config centurion.xs4all.nl: Applying options for * centurion.xs4all.nl: Reading configuration data /etc/ssh/ssh_config centurion.xs4all.nl: Applying options for * centurion.xs4all.nl: ssh_connect: getuid 500 geteuid 0 anon 0 centurion.xs4all.nl: Connecting to shell.sourceforge.net [198.186.203.36] port 22. centurion.xs4all.nl: Allocated local port 1013. centurion.xs4all.nl: Connection established. Connection closed by foreign host. 'ssh' is broken, or they have nameserver difficulties and a fascist-loggingly sshd, or the machines is just overtaxed or so. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Fredrik Lundh" <20000722104713.H9897@xs4all.nl> Message-ID: <00fd01bff3bb$c2f47da0$f2a6b5d4@hagrid> thomas wrote: > = Make-me-checkin-all-these-changes-and-I'll-end-up-next-to-Guido-on-the- > -SourceForge-CVS-stats-ly y'rs, ;-) don't worry -- after the consortium meeting yesterday, he'll probably change the copyright on all files again... From Fredrik Lundh" Message-ID: <010701bff3bc$6be16cc0$f2a6b5d4@hagrid> peter wrote: > GIF89aT looks like you checked them in as text files... From peter@schneider-kamp.de Sat Jul 22 12:04:30 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 11:04:30 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.7,1.8 References: <200007212003.NAA02595@slayer.i.sourceforge.net> <39797879.C63724A8@schneider-kamp.de> <20000722105158.I9897@xs4all.nl> Message-ID: <39797FBE.A91CAFC6@schneider-kamp.de> Thomas Wouters wrote: > > 'Whatever happened' is that Barry assigned himself to that PEP just > yesterday, and has been too busy with all those other things to check even > the template in ;) I guessed so. I have checked in an empty template. > > Is anyone experiencing similar problems? > > Ayup: glad-it's-not-just-me-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From peter@schneider-kamp.de Sat Jul 22 12:28:34 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 11:28:34 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/sf-html at.gif,NONE,1.1 py.gif,NONE,1.1 sf.gif,NONE,1.1 index.html,1.2,1.3 References: <200007220253.TAA12076@slayer.i.sourceforge.net> <010701bff3bc$6be16cc0$f2a6b5d4@hagrid> Message-ID: <39798562.CEF75D2D@schneider-kamp.de> Fredrik Lundh wrote: > > looks like you checked them in as text files... oops. i removed them and added them as binary files. having-put-this-in-the-faq-so-I-can-remember-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From tim_one@email.msn.com Sat Jul 22 10:29:47 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 05:29:47 -0400 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <20000722104713.H9897@xs4all.nl> Message-ID: [Thomas Wouters] > ... > I've also ANSIfied everything in Python/ and Parser/, and the couple of > declarations in PC/ that were still using empty argument lists. > > The changes fall in two categories: those I can test (and have tested and > seem to work fine) and those that I can't test because I haven't such > expensive hardware. Didn't we go thru this before? If "expensive hardware" means SGI, Guido said commit SGI ANSIfication patches. > I'll upload the latter category, and I'm perfectly willing to upload > the former one, too, Does "upload" mean "submit a patch" or "commit"? Commit. > but I wonder if anyone is actually going to review them ? Don't want a patch for this. Commit. > ... > Also, there is an issue with extern function declarations: should > we change all those to full prototypes ? Every function call should have a prototype in scope. That's the answer to the question you meant to ask . > Some aren't too obvious (like the ^*@#$&** readline functions, which > don't have prototypes to start with, and the info pages are not very > helpful) and in one spot a function of the wrong type is passed to > PyAddCallback, resulting in a new warning during -Wall ;) A cast > can fix that, though. > > > And then there is the question whether all those externs are really > necessary. ... Every function call should have a prototype in scope. There is no other goal here -- ANSIfication is for a reason, not just to say "it's been ANSIfied". If this causes warnings, good! It's turning up bugs in the code then. Casts are rarely the correct way to fix those, though (e.g., *why* is a function of the wrong type being passed? don't cast the warning away without understanding that fully). > ... [...] ... Too much detail for me. Fix them or don't, but I don't think it needs this much discussion. If you don't know how to fix some particular one, try posting a focused single-issue msg about that particular one. > ... > Make-me-checkin-all-these-changes-and-I'll-end-up-next-to-Guido-on-the- > -SourceForge-CVS-stats-ly y'rs, ;-) Heh -- nothing would please him more! From thomas@xs4all.net Sat Jul 22 10:30:28 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 11:30:28 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <00fd01bff3bb$c2f47da0$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jul 22, 2000 at 11:03:51AM +0200 References: <20000720221300.W9897@xs4all.nl> <20000722104713.H9897@xs4all.nl> <00fd01bff3bb$c2f47da0$f2a6b5d4@hagrid> Message-ID: <20000722113028.J9897@xs4all.nl> On Sat, Jul 22, 2000 at 11:03:51AM +0200, Fredrik Lundh wrote: > > Make-me-checkin-all-these-changes-and-I'll-end-up-next-to-Guido-on-the- > > -SourceForge-CVS-stats-ly y'rs, ;-) > don't worry -- after the consortium meeting yesterday, he'll > probably change the copyright on all files again... Yeah, about the consortium meeting... any idea when the general public and grunts like us (well, me, in any case) get to hear the results ? The subject is pretty dear to us, you see ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Sat Jul 22 10:38:16 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 11:38:16 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 22, 2000 at 05:29:47AM -0400 References: <20000722104713.H9897@xs4all.nl> Message-ID: <20000722113816.K9897@xs4all.nl> On Sat, Jul 22, 2000 at 05:29:47AM -0400, Tim Peters wrote: > [Thomas Wouters] > > The changes fall in two categories: those I can test (and have tested and > > seem to work fine) and those that I can't test because I haven't such > > expensive hardware. > Didn't we go thru this before? If "expensive hardware" means SGI, Guido > said commit SGI ANSIfication patches. OS/2, NT, etc, are quite a bit different from SGI. SGI is UNIX, which I grok. I can't claim the same for NT ;P > Does "upload" mean "submit a patch" or "commit"? Commit. upload means submit a patch. I was nearly done uploading them, too! I guess I'll mark them as 'accepted' and commit them instead. > > but I wonder if anyone is actually going to review them ? > Don't want a patch for this. Commit. Will do. I'll need to generate new ones for compile.c and ceval.c, though, because these were done relative to the range-literals patch. > Every function call should have a prototype in scope. That's the answer to > the question you meant to ask . Each time you post one of these 'go ahead and do it' messages, I go ahead and do it, thinking to myself, "he said that before". And then the next time I see something I'm not quite sure about, I think "he said to go ahead and do it... but that was not about 'this', it was about the slightly different 'that' instead." ;P Simply-trying-not-to-overstep-my-bounds-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Fredrik Lundh" tcl: http://dev.ajubasolutions.com/community/coreteam/ perl: http://www.perl.org/perl6/ http://www.news.perl.org/perl-news.cgi?item=3D964033768%7C25110 From tim_one@email.msn.com Sat Jul 22 11:15:43 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 06:15:43 -0400 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <20000722113816.K9897@xs4all.nl> Message-ID: [Tim] >> Didn't we go thru this before? If "expensive hardware" means SGI, Guido >> said commit SGI ANSIfication patches. [Thomas Wouters] > OS/2, NT, etc, are quite a bit different from SGI. SGI is UNIX, which I > grok. I can't claim the same for NT ;P NT is expensive hardware? That MS .NET project is more ambitious than I thought . >> commit ... commit ... commit > Will do. Excellent. > ... > Each time you post one of these 'go ahead and do it' messages, I go > ahead and do it, thinking to myself, "he said that before". And then > the next time I see something I'm not quite sure about, I think "he > said to go ahead and do it... but that was not about 'this', it was > about the slightly different 'that' instead." ;P > > Simply-trying-not-to-overstep-my-bounds-ly y'rs, There's no way to find out your bounds *except* by going beyond them -- which, happily enough, is also the way to expand your bounds. If we didn't think you were a perfectly wonderful human being, you wouldn't have gotten commit access to begin with. Do note that Guido has yelled at people only a few times here so far, and all of those on the receiving end are still here -- including me. But then he was surely wrong to yell at me . an-exaggerated-sense-of-one's-own-importance-is-a-virtue- in-this-field-ly y'rs - tim From tim_one@email.msn.com Sat Jul 22 11:15:45 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 06:15:45 -0400 Subject: Consortium mtg non-news (was RE: [Python-Dev] ANSIfication again ;)) In-Reply-To: <20000722113028.J9897@xs4all.nl> Message-ID: [Thomas Wouters] > ... about the consortium meeting... any idea when the general public and > grunts like us (well, me, in any case) get to hear the results ? > The subject is pretty dear to us, you see ;-P Me too! Guido went to the consortium mtg on Friday, but Fred, Jeremy and I are not consortium members, so didn't attend -- we spent 12+ hours fighting to get home from California instead (Jeremy, you missed some delightful midnight freeway gridlock heading into VA), and haven't heard from Guido either. There was some good reason for optimism before the mtg. The only email Guido sent after the mtg was some bad news about PythonLabs office space, so I assume he didn't think good news was worth mentioning <0.9 wink>. may-as-well-study-the-entrails-of-a-pigeon-ly y'rs - tim From esr@thyrsus.com Sat Jul 22 11:55:46 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Sat, 22 Jul 2000 06:55:46 -0400 Subject: Consortium mtg non-news (was RE: [Python-Dev] ANSIfication again ;)) In-Reply-To: References: <20000722113028.J9897@xs4all.nl> Message-ID: <20000722065546.A18263@thyrsus.com> Tim Peters : > [Thomas Wouters] > > ... about the consortium meeting... any idea when the general public and > > grunts like us (well, me, in any case) get to hear the results ? > > The subject is pretty dear to us, you see ;-P > > Me too! Guido went to the consortium mtg on Friday, but Fred, Jeremy and I > are not consortium members, so didn't attend -- we spent 12+ hours fighting > to get home from California instead (Jeremy, you missed some delightful > midnight freeway gridlock heading into VA), and haven't heard from Guido > either. There was some good reason for optimism before the mtg. The only > email Guido sent after the mtg was some bad news about PythonLabs office > space, so I assume he didn't think good news was worth mentioning <0.9 > wink>. I won't steal Guido's thunder, but I will say that the meeting went well in all important respects (aside from being boring for long periods :-)). I think all the surprises will be pleasant ones. -- Eric S. Raymond Power concedes nothing without a demand. It never did, and it never will. Find out just what people will submit to, and you have found out the exact amount of injustice and wrong which will be imposed upon them; and these will continue until they are resisted with either words or blows, or with both. The limits of tyrants are prescribed by the endurance of those whom they oppress. -- Frederick Douglass, August 4, 1857 From Fredrik Lundh" Message-ID: <022601bff3d8$551ccea0$f2a6b5d4@hagrid> first this: > http://dev.ajubasolutions.com/community/coreteam/ ...new, larger, "batteries included" releases... and then I stumbled upon this little quote on comp.lang.tcl: > > IMO, it's obvious: Tcl needs to go where people are going. = Glueing to > > each and every technology under the sun, and that includes = Python and > > Perl. Closing the door out of fear of being overtaken by others = would > > be a big mistake. >=20 > And let us not forget that Guido himself posted a message to c.l.t > suggesting that python and tcl pool their work at the lower level > implementation. hmm. what exactly am I missing here? ;-) From akuchlin@mems-exchange.org Sat Jul 22 14:25:30 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat, 22 Jul 2000 09:25:30 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: ; from mhammond@skippinet.com.au on Sat, Jul 22, 2000 at 05:18:13PM +1000 References: Message-ID: <20000722092530.A24247@newcnri.cnri.reston.va.us> On Sat, Jul 22, 2000 at 05:18:13PM +1000, Mark Hammond quoted: >> Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating >> Python way too much. and then wrote: >I've gotta agree here - I really am quite concerned about all the >cool-but-not-really-necessary stuff being proposed. I fear that Python Seconded from me. IMHO it's only worth adding a new feature if it multiplies power by a significant amount; if it just adds a tiny increment, it's not worth adding a small bit of extra complexity, extra code, and having to resync JPython and Python# (does that project have a name yet?). The urge to add little tiny things that make microtask X convenient is what made Perl -- and Sendmail, and DTML, and ... -- what they are today. --amk From guido@python.org Sat Jul 22 14:35:38 2000 From: guido@python.org (Guido van Rossum) Date: Sat, 22 Jul 2000 06:35:38 -0700 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722113028.J9897@xs4all.nl> <20000722065546.A18263@thyrsus.com> Message-ID: <003301bff3e1$bd5dde60$360bfea9@beopen.com> This is a multi-part message in MIME format. ------=_NextPart_000_0030_01BFF3A7.0CC52D40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The meeting went well. Some major conclusions: - The latest license proposed by CNRI (attached) is acceptable to the consortium members and to OSI (the Open Source Initiative); Eric Raymond (who is on the OSI board) believes there will be no trouble getting it approved as Open Source at the next board meeting, which happens to be next Friday. There are remaining lingering grumblings from Richard Stallman, but these all seem to hinge on slight misreadings on his side; we believe the license is GPL compatible. We will work this out with Stallman over the next few weeks. - The python.org website will be hosted at SourceForge. As a community resource, it will be run in a way that does not advantage any one party (read: no banner ads). We will expedite transformation to Zope (Digital Creations has offered to help!), but the first priority is to get the existing site moved. Pending the move, the PythonLabs folks will be able to maintain the site as it currently exists at CNRI, like before. - Python 1.6 (a CNRI release with PythonLabs' help) will come out with CNRI's Open Source License in two phases: a beta around August 1st, and a final release mid-August (of course this schedule is subject to the usual qualifications). This will release all of the work on Python done at CNRI since 1.5.2 was released to the public -- a significant step. - Python 2.0 (a BeOpen PythonLabs release) will start with a beta release 1-2 weeks after 1.6 final is released; we're striving for a short beta cycle. New language features will include list comprehensions, range literals, the zip() function, and augmented assignment. I would like to thank all who helped reaching this conclusion: CNRI's Bob Kahn for traveling out west to discuss these issues in person, Eric Raymond and Bruce Perens for their useful contributions to the negotiations, BeOpen's Bob Weiner for taking care of the bulk of the negotiations, and the consortium member representatives for making the meeting a success! --Guido van Rossum [Note that I'm cc'ing Kahn, Perens and the consortium mailing list; please take these off your CC list when replying to this message in the python-dev list!!!] ------=_NextPart_000_0030_01BFF3A7.0CC52D40 Content-Type: application/msword; name="PYTHON1.6revised.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="PYTHON1.6revised.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKAAAAAAAAAAA EAAAKgAAAAEAAAD+////AAAAACcAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEATSAJBAAA8BK/AAAAAAAAEAAAAAAABAAAtxIAAA4AYmpiauI94j0AAAAAAAAAAAAAAAAAAAAA AAAJBBYAHhwAAIBXAACAVwAAtw4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAKAAAAAAAAAAoAAAAKAA AAAAAAAAoAAAAAAAAACgAAAAAAAAAKAAAAAAAAAAoAAAABQAAAAAAAAAAAAAALQAAAAAAAAApAMA AAAAAACkAwAAAAAAAKQDAAAAAAAApAMAAAwAAACwAwAAFAAAALQAAAAAAAAAewYAALYAAADQAwAA AAAAANADAAAAAAAA0AMAAAAAAADQAwAAAAAAANADAAAAAAAA0AMAAAAAAADQAwAAAAAAANADAAAA AAAAzAUAAAIAAADOBQAAAAAAAM4FAAAAAAAAzgUAAAAAAADOBQAAAAAAAM4FAAAAAAAAzgUAACQA AAAxBwAAIAIAAFEJAAB2AAAA8gUAABUAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAAAAAADQAwAAAAAA AAAAAAAAAAAAAAAAAAAAAADQAwAAAAAAANADAAAAAAAA0AMAAAAAAADQAwAAAAAAAPIFAAAAAAAA FgQAAAAAAACgAAAAAAAAAKAAAAAAAAAA0AMAAAAAAAAAAAAAAAAAANADAAAAAAAABwYAADgAAAAW BAAAAAAAABYEAAAAAAAAFgQAAAAAAADQAwAARgAAAKAAAAAAAAAA0AMAAAAAAACgAAAAAAAAANAD AAAAAAAAzAUAAAAAAAAAAAAAAAAAABYEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA0AMAAAAAAADMBQAAAAAAABYEAACqAQAAFgQAAAAAAAAAAAAA AAAAAMAFAAAAAAAAoAAAAAAAAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAUAAAAAAADQAwAAAAAAAMQDAAAMAAAAQLTSurDy vwG0AAAA8AIAAKQDAAAAAAAAFgQAAAAAAADABQAAAAAAAAAAAAAAAAAAwAUAAAwAAAA/BgAAPAAA AHsGAAAAAAAAwAUAAAAAAADHCQAAAAAAABYEAAAAAAAAxwkAAAAAAADABQAAAAAAABYEAAAAAAAA tAAAAAAAAAC0AAAAAAAAAKAAAAAAAAAAoAAAAAAAAACgAAAAAAAAAKAAAAAAAAAAAgDZAAAAUFlU SE9OIDEuNiwgQmV0YSAxDShub3RlOiB0aGlzIGlzIGEgcmV2aXNpb24gb2YgNy8xOS8wMCCWIEmS bGwgc3Vic3RpdHV0ZSBpdCBmb3IgdGhlIHByZXZpb3VzIHZlcnNpb24pDQ1DTlJJIExJQ0VOU0Ug QUdSRUVNRU5UDQ0NDUlNUE9SVEFOVDogUExFQVNFIFJFQUQgVEhFIEZPTExPV0lORyBBR1JFRU1F TlQgQ0FSRUZVTExZLg0NQlkgQ0xJQ0tJTkcgT04gVEhFICJBQ0NFUFQiIEJVVFRPTiBXSEVSRSBJ TkRJQ0FURUQsIE9SIEJZIENPUFlJTkcsIElOU1RBTExJTkcgT1IgT1RIRVJXSVNFIFVTSU5HIFRI RSBTT0ZUV0FSRSwgWU9VIEFSRSBERUVNRUQgVE8gSEFWRSBBR1JFRUQgVE8gVEhFIFRFUk1TIEFO RCBDT05ESVRJT05TIE9GIFRISVMgQUdSRUVNRU5ULg0NDQ0xLiBUaGlzIExJQ0VOU0UgQUdSRUVN RU5UIGlzIGJldHdlZW4gdGhlIENvcnBvcmF0aW9uIGZvciBOYXRpb25hbCBSZXNlYXJjaCBJbml0 aWF0aXZlcywgaGF2aW5nIGFuIG9mZmljZSBhdCAxODk1IFByZXN0b24gV2hpdGUgRHJpdmUsIFJl c3RvbiwgVkEgMjAxOTEgKCJDTlJJIiksIGFuZCB0aGUgSW5kaXZpZHVhbCBvciBPcmdhbml6YXRp b24gKCJMaWNlbnNlZSIpIGFjY2Vzc2luZyBhbmQgb3RoZXJ3aXNlIHVzaW5nIFB5dGhvbiAxLjYs IGJldGEgMSBzb2Z0d2FyZSBpbiBzb3VyY2Ugb3IgYmluYXJ5IGZvcm0gYW5kIGl0cyBhc3NvY2lh dGVkIGRvY3VtZW50YXRpb24sIGFzIHJlbGVhc2VkIGF0IHRoZSB3d3cucHl0aG9uLm9yZyBJbnRl cm5ldCBzaXRlIG9uIEp1bHkgX18sIDIwMDAgKCJTb2Z0d2FyZSIpLg0NMi4gU3ViamVjdCB0byB0 aGUgdGVybXMgYW5kIGNvbmRpdGlvbnMgb2YgdGhpcyBMaWNlbnNlIEFncmVlbWVudCwgQ05SSSBo ZXJlYnkgZ3JhbnRzIExpY2Vuc2VlIGEgbm9uLWV4Y2x1c2l2ZSwgcm95YWx0eS1mcmVlLCB3b3Js ZC13aWRlIGxpY2Vuc2UgdG8gcmVwcm9kdWNlLCBhbmFseXplLCB0ZXN0LCBwZXJmb3JtIGFuZC9v ciBkaXNwbGF5IHB1YmxpY2x5LCBwcmVwYXJlIGRlcml2YXRpdmUgd29ya3MsIGRpc3RyaWJ1dGUs IGFuZCBvdGhlcndpc2UgdXNlIHRoZSBTb2Z0d2FyZSBhbG9uZSBvciBpbiBhbnkgZGVyaXZhdGl2 ZSB2ZXJzaW9uLCBwcm92aWRlZCwgaG93ZXZlciwgdGhhdCBDTlJJknMgTGljZW5zZSBBZ3JlZW1l bnQgYW5kIENOUkmScyBub3RpY2Ugb2YgY29weXJpZ2h0LCBpLmUuLCAiQ29weXJpZ2h0IKkgMTk5 NSAtIDIwMDAgQ29ycG9yYXRpb24gZm9yIE5hdGlvbmFsIFJlc2VhcmNoIEluaXRpYXRpdmVzOyBB bGwgUmlnaHRzIHJlc2VydmVkIiBhcmUgYm90aCByZXRhaW5lZCBpbiB0aGUgU29mdHdhcmUsIGFs b25lIG9yIGluIGFueSBkZXJpdmF0aXZlIHZlcnNpb24gcHJlcGFyZWQgYnkgTGljZW5zZWUuDQ1B bHRlcm5hdGVseSwgaW4gbGlldSBvZiBDTlJJknMgTGljZW5zZSBBZ3JlZW1lbnQsIExpY2Vuc2Vl IG1heSBzdWJzdGl0dXRlIHRoZSBmb2xsb3dpbmcgdGV4dCAob21pdHRpbmcgdGhlIHF1b3Rlcyk6 ICJQeXRob24gMS42LCBiZXRhIDEsIGlzIG1hZGUgYXZhaWxhYmxlIHN1YmplY3QgdG8gdGhlIHRl cm1zIGFuZCBjb25kaXRpb25zIGluIENOUkmScyBMaWNlbnNlIEFncmVlbWVudC4gVGhpcyBBZ3Jl ZW1lbnQgbWF5IGJlIGxvY2F0ZWQgb24gdGhlIEludGVybmV0IHVzaW5nIHRoZSBmb2xsb3dpbmcg dW5pcXVlLCBwZXJzaXN0ZW50IGlkZW50aWZpZXIgKGtub3duIGFzIGEgaGFuZGxlKTogMTg5NS4y Mi8xMDExLiBUaGlzIEFncmVlbWVudCBtYXkgYWxzbyBiZSBvYnRhaW5lZCBmcm9tIGEgcHJveHkg c2VydmVyIG9uIHRoZSBJbnRlcm5ldCB1c2luZyB0aGUgZm9sbG93aW5nIFVSTDogaHR0cDovL2hk bC5oYW5kbGUubmV0LzE4OTUuMjIvMTAxMSIuDSANMy4gSW4gdGhlIGV2ZW50IExpY2Vuc2VlIHBy ZXBhcmVzIGEgZGVyaXZhdGl2ZSB3b3JrIHRoYXQgaXMgYmFzZWQgb24gb3IgaW5jb3Jwb3JhdGVz IHRoZSBTb2Z0d2FyZSBvciBhbnkgcGFydCB0aGVyZW9mLCBhbmQgd2FudHMgdG8gbWFrZSB0aGUg ZGVyaXZhdGl2ZSB3b3JrIGF2YWlsYWJsZSB0byB0aGUgcHVibGljIGFzIHByb3ZpZGVkIGhlcmVp biwgdGhlbiBMaWNlbnNlZSBoZXJlYnkgYWdyZWVzIHRvIGluZGljYXRlIGluIGFueSBzdWNoIHdv cmssIGluIGEgcHJvbWluZW50bHkgdmlzaWJsZSB3YXksIHRoZSBuYXR1cmUgb2YgdGhlIG1vZGlm aWNhdGlvbnMgbWFkZSB0byBDTlJJknMgU29mdHdhcmUuDQ00LiBDTlJJIGlzIG1ha2luZyB0aGUg U29mdHdhcmUgYXZhaWxhYmxlIHRvIExpY2Vuc2VlIG9uIGFuICJBUyBJUyIgYmFzaXMuIENOUkkg TUFLRVMgTk8gUkVQUkVTRU5UQVRJT05TIE9SIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElF RC4gQlkgV0FZIE9GIEVYQU1QTEUsIEJVVCBOT1QgTElNSVRBVElPTiwgQ05SSSBNQUtFUyBOTyBB TkQgRElTQ0xBSU1TIEFOWSBSRVBSRVNFTlRBVElPTiBPUiBXQVJSQU5UWSBPRiBNRVJDSEFOVEFC SUxJVFkgT1IgRklUTkVTUyBGT1IgQU5ZIFBBUlRJQ1VMQVIgUFVSUE9TRSBPUiBUSEFUIFRIRSBV U0UgT0YgVEhFIFNPRlRXQVJFIFdJTEwgTk9UIElORlJJTkdFIEFOWSBUSElSRCBQQVJUWSBSSUdI VFMuDQ01LiBDTlJJIFNIQUxMIE5PVCBCRSBMSUFCTEUgVE8gTElDRU5TRUUgT1IgQU5ZIE9USEVS IFVTRVJTIE9GIFRIRSBTT0ZUV0FSRSBGT1IgQU5ZIElOQ0lERU5UQUwsIFNQRUNJQUwsIE9SIENP TlNFUVVFTlRJQUwgREFNQUdFUyBPUiBMT1NTIEFTIEEgUkVTVUxUIE9GIFVTSU5HLCBNT0RJRllJ TkcgT1IgRElTVFJJQlVUSU5HIFRIRSBTT0ZUV0FSRSwgT1IgQU5ZIERFUklWQVRJVkUgVEhFUkVP RiwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBUSEVSRU9GLiBTT01FIFNUQVRF UyBETyBOT1QgQUxMT1cgVEhFIExJTUlUQVRJT04gT1IgRVhDTFVTSU9OIE9GIExJQUJJTElUWSBT TyBUSEUgQUJPVkUgRElTQ0xBSU1FUiBNQVkgTk9UIEFQUExZIFRPIExJQ0VOU0VFLg0NNi4gVGhp cyBMaWNlbnNlIEFncmVlbWVudCB3aWxsIGF1dG9tYXRpY2FsbHkgdGVybWluYXRlIHVwb24gYSBt YXRlcmlhbCBicmVhY2ggb2YgaXRzIHRlcm1zIGFuZCBjb25kaXRpb25zLg0NNy4gVGhpcyBMaWNl bnNlIEFncmVlbWVudCBzaGFsbCBiZSBnb3Zlcm5lZCBieSBhbmQgaW50ZXJwcmV0ZWQgaW4gYWxs IHJlc3BlY3RzIGJ5IHRoZSBsYXcgb2YgdGhlIFN0YXRlIG9mIFZpcmdpbmlhLCBleGNsdWRpbmcg Y29uZmxpY3Qgb2YgbGF3IHByb3Zpc2lvbnMuIE5vdGhpbmcgaW4gdGhpcyBMaWNlbnNlIEFncmVl bWVudCBzaGFsbCBiZSBkZWVtZWQgdG8gY3JlYXRlIGFueSByZWxhdGlvbnNoaXAgb2YgYWdlbmN5 LCBwYXJ0bmVyc2hpcCwgb3Igam9pbnQgdmVudHVyZSBiZXR3ZWVuIENOUkkgYW5kIExpY2Vuc2Vl LiBMaWNlbnNlZSBtYXkgbm90IHVzZSBDTlJJIHRyYWRlbWFya3Mgb3IgdHJhZGUgbmFtZSBpbiBh IHRyYWRlbWFyayBzZW5zZSB0byBlbmRvcnNlIG9yIHByb21vdGUgcHJvZHVjdHMgb3Igc2Vydmlj ZXMgb2YgTGljZW5zZWUsIG9yIGFueSB0aGlyZCBwYXJ0eS4NDTguIEJ5IGNsaWNraW5nIG9uIHRo ZSAiQUNDRVBUIiBidXR0b24gd2hlcmUgaW5kaWNhdGVkLCBvciBieSBjb3B5aW5nLCAgaW5zdGFs bGluZyBvciBvdGhlcndpc2UgdXNpbmcgdGhlIHNvZnR3YXJlLCBMaWNlbnNlZSBhZ3JlZXMgdG8g YmUgYm91bmQgYnkgdGhlIHRlcm1zIGFuZCBjb25kaXRpb25zIG9mIHRoaXMgTGljZW5zZSBBZ3Jl ZW1lbnQuDQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBQ0NFUFQN DQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAA/CwAAQAsA AEIMAABEDAAAYQwAAAESAAADEgAABBIAALcSAAAA+ADx6gDj3AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQAIgWNIAQBkaMujR4YNAQiBBEgBAAVoy6NH hg0ACIFjSAEAZGjHo0eGDQAIgWNIAQBkaMijR4YNAQiBBEgBAAVoh6RHhgAJAAQAABMEAABnBAAA aAQAAH8EAACABAAAgQQAAIIEAAC8BAAAvQQAAHkFAAB6BQAAewUAAHwFAAARBwAAEgcAAFkJAABa CQAAPwsAAEELAACbDAAAnAwAAAwOAAANDgAAkA8AAJEPAAD8DwAA/Q8AALwRAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABAAAAyQBYSQBABwABAAAtxIAAP4AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBAbwRAAC9EQAAgxIAAIQS AAC1EgAAthIAALcSAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAGHAAfsNAvILDgPSGwCAci sAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAA8ACgABAGkADwADAAAA AAAAAAAAMAAAQPH/AgAwAAwABgBOAG8AcgBtAGEAbAAAAAIAAAAQAF9IAQRtSAkEc0gJBHRICQQA AAAAAAAAAAAAAAAAAAAAAAA8AEFA8v+hADwADAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcA cgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAAAAAAALcOAAAEAAAcAAAFAP////8AAAAAEwAA AGcAAABoAAAAfwAAAIAAAACBAAAAggAAALwAAAC9AAAAeQEAAHoBAAB7AQAAfAEAABEDAAASAwAA WQUAAFoFAAA/BwAAQQcAAJsIAACcCAAADAoAAA0KAACQCwAAkQsAAPwLAAD9CwAAvA0AAL0NAACD DgAAhA4AALUOAAC2DgAAuQ4AAJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgA AAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAA AAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAA AAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAA AACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACA AAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgA AAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAA AAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAA AAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAAAAAAAAA AACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJoAAAAAAAAAAAAAAACA AAAAgAAEAAC3EgAACgAAAAAEAAC8EQAAtxIAAAsAAAANAAAAAAQAALcSAAAMAAAAAAAAAGEEAABn BAAAfgQAAIQEAAByBQAAeAUAABwGAAAiBgAAiggAAJAIAAC5DgAABwAcAAcAHAAHABwABwAcAAcA HAAHAP//BgAAAA4AUgBvAGIAZQByAHQAIABFAC4AIABLAGEAaABuACcAQwA6AFwAVwBJAE4ARABP AFcAUwBcAEQARQBTAEsAVABPAFAAXABQAFkAVABIAE8ATgAxAC4ANgByAGUAdgBpAHMAZQBkAC4A ZABvAGMAEABHAHUAaQBkAG8AIAB2AGEAbgAgAFIAbwBzAHMAdQBtACcAQwA6AFwAVwBJAE4ARABP AFcAUwBcAEQAZQBzAGsAdABvAHAAXABQAFkAVABIAE8ATgAxAC4ANgByAGUAdgBpAHMAZQBkAC4A ZABvAGMAEABHAHUAaQBkAG8AIAB2AGEAbgAgAFIAbwBzAHMAdQBtAFAAQwA6AFwAVwBJAE4ARABP AFcAUwBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYA dABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABQ AFkAVABIAE8ATgAxAC4ANgByAGUAdgBpAHMAZQBkAAAAAAC5DgAAAQAAAP9AA4ABAEAHAABABwAA jJdkAAEAAQBABwAAAAAAAD8HAAAAAAAAAhAAAAAAAAAAtw4AAEAAAAgAQAAA//8CAAAABwBVAG4A awBuAG8AdwBuABAARwB1AGkAZABvACAAdgBhAG4AIABSAG8AcwBzAHUAbQD//wIACAAAAAAAAAAA AAAAAAAAAAAAAAABAP//AgAAAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAADAAAARxaQAQAA AgIGAwUEBQIDBIc6AAAAAAAAAAAAAAAAAAD/AAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBv AG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIA bwBsAAAAMyaQAQAAAgsGBAICAgICBIc6AAAAAAAAAAAAAAAAAAD/AAAAAAAAAEEAcgBpAGEAbAAA ACIABABxiIgAAPDQAgAAaAEAAAAA8qFHhoykR4YAAAAABgA4AAAAIAIAACIMAAABAAYAAAAEAAMQ GQAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAAAkAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAClBsAHtAC0AIAAMjAAABAAGQBkAAAAGQAAAOYOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA/BwAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAygxEA8BAA 3wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAACABQAFkAVABIAE8ATgAg ADEAAAAAAAAADgBSAG8AYgBlAHIAdAAgAEUALgAgAEsAYQBoAG4AEABHAHUAaQBkAG8AIAB2AGEA bgAgAFIAbwBzAHMAdQBtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAA AQAAAOCFn/L5T2gQq5EIACsns9kwAAAAhAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAKwAAAAE AAAAuAAAAAUAAADQAAAABgAAANwAAAAHAAAA6AAAAAgAAAD8AAAACQAAABgBAAASAAAAJAEAAAoA AABAAQAADAAAAEwBAAANAAAAWAEAAA4AAABkAQAADwAAAGwBAAAQAAAAdAEAABMAAAB8AQAAAgAA AOQEAAAeAAAACQAAAFBZVEhPTiAxAAAgAB4AAAABAAAAAFlUSB4AAAAPAAAAUm9iZXJ0IEUuIEth aG4AAB4AAAABAAAAAG9iZR4AAAABAAAAAG9iZR4AAAALAAAATm9ybWFsLmRvdABhHgAAABEAAABH dWlkbyB2YW4gUm9zc3VtAABkAB4AAAACAAAANgBpZB4AAAATAAAATWljcm9zb2Z0IFdvcmQgOS4w AABAAAAAAFC30gcAAABAAAAAAFxWx1nyvwFAAAAAAHDKq7DyvwEDAAAAAQAAAAMAAAAgAgAAAwAA ACIMAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3V nC4bEJOXCAArLPmuMAAAAPQAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACAAAAABgAAAIgAAAAR AAAAkAAAABcAAACYAAAACwAAAKAAAAAQAAAAqAAAABMAAACwAAAAFgAAALgAAAANAAAAwAAAAAwA AADVAAAAAgAAAOQEAAAeAAAABQAAAENOUkkAADEAAwAAABkAAAADAAAABgAAAAMAAADmDgAAAwAA AO0OCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAACQAAAFBZVEhPTiAx AAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAA CwAAAAwAAAANAAAADgAAAP7///8QAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAA/v///xgAAAAZ AAAAGgAAABsAAAAcAAAAHQAAAB4AAAD+////IAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAAP7/ ///9////KQAAAP7////+/////v////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAA AAAAAAAAAAAAAEC00rqw8r8BKwAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAAAAABAAAAAAAABXAG8AcgBkAEQAbwBj AHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUA AAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeHAAAAAAA AAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAFwAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAfAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAA bwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAABAtNK6sPK/AUC00rqw8r8BAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdv cmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA ------=_NextPart_000_0030_01BFF3A7.0CC52D40-- From paul@prescod.net Sat Jul 22 15:54:17 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 09:54:17 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> Message-ID: <3979B599.7274105C@prescod.net> "Barry A. Warsaw" wrote: > > I've long wanted to make the print statement able to handle > alternative output files in a more convenient syntax. Yes you can > rebind sys.stdout, but that is often very clumsy to get right in the > face of exceptions. Why not use outputfile.write directly? print is such a hack already. What are we trying to get at, really? What are the virtues of print, what are the virtues of "outputfile.write" and how can we combine them? -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul@prescod.net Sat Jul 22 16:37:29 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 10:37:29 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <20000722092530.A24247@newcnri.cnri.reston.va.us> Message-ID: <3979BFB9.419EC323@prescod.net> Andrew Kuchling wrote: > > On Sat, Jul 22, 2000 at 05:18:13PM +1000, Mark Hammond quoted: > >> Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating > >> Python way too much. > and then wrote: > >I've gotta agree here - I really am quite concerned about all the > >cool-but-not-really-necessary stuff being proposed. I fear that Python > > Seconded from me. I think that this class vague complaints are a little unfair. We've had a wide range of proposals from extra functions to minor new syntax to new magical methods to radically new control flow features. It isn't helpful to lump them altogether and condemn them because Barry broke the cardinal rule of never using an at-symbol in a feature syntax. (shame on you Barry!) List which proposed features you like and don't like and why! That's the only way your concerns could really be addressed. > IMHO it's only worth adding a new feature if it > multiplies power by a significant amount; I think it is also worthwhile to recognize "conventions" that could be made clearer with first-class syntax. List comprehensions replace the map/lambda convention (and would IMHO, allow map/filter, at-least, to be deprecated). Range literals replace the for i in range(...) convention and so forth. Those of us who have already internalized the conventions are more likely to see new syntax as an intrusion rather than as a long-term clarification. > The urge to add little tiny things that make microtask X convenient is > what made Perl -- and Sendmail, and DTML, and ... -- what they are > today. Many languages (including some of the ones you mention) also suffer from the syndrome where a first-class feature has been left out so you have to memorize some stupid and non-intuitive "convention" rather than doing things in a straightforward way. I strongly feel that map/lambda and in fact most uses of map fall into this category. The concept is fine but the syntax sucks. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul@prescod.net Sat Jul 22 16:39:30 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 10:39:30 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <20000722092530.A24247@newcnri.cnri.reston.va.us> Message-ID: <3979C032.357FCAF4@prescod.net> Andrew Kuchling wrote: > > On Sat, Jul 22, 2000 at 05:18:13PM +1000, Mark Hammond quoted: > >> Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating > >> Python way too much. > and then wrote: > >I've gotta agree here - I really am quite concerned about all the > >cool-but-not-really-necessary stuff being proposed. I fear that Python > > Seconded from me. I think that this class vague complaints are a little unfair. We've had a wide range of proposals from extra functions to minor new syntax to new magical methods to radically new control flow features. It isn't helpful to lump them altogether and condemn them because Barry broke the cardinal rule of never using an at-symbol in a feature syntax. (shame on you Barry!) List which proposed features you like and don't like and why! That's the only way your concerns could really be addressed. > IMHO it's only worth adding a new feature if it > multiplies power by a significant amount; I think it is also worthwhile to recognize "conventions" that could be made clearer with first-class syntax. List comprehensions replace the map/lambda convention (and would IMHO, allow map/filter, at-least, to be deprecated). Range literals replace the for i in range(...) convention and so forth. Those of us who have already internalized the conventions are more likely to see new syntax as an intrusion rather than as a long-term clarification. > The urge to add little tiny things that make microtask X convenient is > what made Perl -- and Sendmail, and DTML, and ... -- what they are > today. Many languages (including some of the ones you mention) also suffer from the syndrome where a first-class feature has been left out so you have to memorize some stupid and non-intuitive "convention" rather than doing things in a straightforward way. I strongly feel that map/lambda and in fact most uses of map fall into this category. The concept is fine but the syntax sucks. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From gmcm@hypernet.com Sat Jul 22 17:00:23 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Sat, 22 Jul 2000 12:00:23 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <3979B599.7274105C@prescod.net> Message-ID: <1247840871-20245181@hypernet.com> Paul Prescod wrote: > print is such a hack already. > > What are we trying to get at, really? What are the virtues of > print, what are the virtues of "outputfile.write" and how can we > combine them? The answer to that is contained in the answer to "Why did Guido make print a keyword?". occaisionally-encumbered-by-bouts-of-rationality-ly y'rs -Gordon From paul@prescod.net Sat Jul 22 17:20:52 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 11:20:52 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <20000722092530.A24247@newcnri.cnri.reston.va.us> Message-ID: <3979C9E4.E66FE451@prescod.net> Andrew Kuchling wrote: > > .... > > The urge to add little tiny things that make microtask X convenient is > what made Perl -- and Sendmail, and DTML, and ... -- what they are > today. I also wanted to say that Perl and Sendmail (don't know about DTML) suffer much more from poor design than from feature creep. It isn't just about quantity of features -- quality also matters. The group of people who spent a week arguing about the name "zip" would never allow "eval" to mean "evaluate string" and "catch exceptions" nor make unadorned variable name mean "file handle" nor make :0:c a "command". Common Lisp and Linux are victims of feature creep. Perl and Sendmail just suck. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul@prescod.net Sat Jul 22 17:29:48 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 11:29:48 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> Message-ID: <3979CBFC.2EED0234@prescod.net> Gordon McMillan wrote: > > ... > > The answer to that is contained in the answer to "Why did > Guido make print a keyword?". I would guess that he invented print before sys.stdout. :) The main reason I use print (for debugging) is because a) it doesn't require me to coerce variables to strings explicitly. That's why I want autocoercion everywhere. b) it doesn't require me to import sys. That's an argument for making stdout (or sys!) a builtin c) it just seems less technical for newbies than the unpronouncable string of consonants "std". Overall, I think the language would be better off if print were gone. There are more generalized ways to do what it does. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From akuchlin@mems-exchange.org Sat Jul 22 17:36:03 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat, 22 Jul 2000 12:36:03 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <003301bff3e1$bd5dde60$360bfea9@beopen.com>; from guido@python.org on Sat, Jul 22, 2000 at 06:35:38AM -0700 References: <20000722113028.J9897@xs4all.nl> <20000722065546.A18263@thyrsus.com> <003301bff3e1$bd5dde60$360bfea9@beopen.com> Message-ID: <20000722123603.A24658@newcnri.cnri.reston.va.us> On Sat, Jul 22, 2000 at 06:35:38AM -0700, Guido van Rossum wrote: >- Python 1.6 (a CNRI release with PythonLabs' help) will come out with >CNRI's Open Source License in two phases: a beta around August 1st, and a >final release mid-August (of course this schedule is subject to the usual >qualifications). This will release all of the work on Python done at CNRI >since 1.5.2 was released to the public -- a significant step. Glad there's some resolution to this, and apparently a favorable one! (I haven't read the licence yet -- no way to read Word on this Linux laptop.) So, what version does the current CVS tree represent? Is it what will become 1.6, or will some things be removed from the CVS tree in order to make the 1.6 release? From reading the feature lists, it looks like none of the 2.0 features are checked in yet, so I'd wager that the CVS tree is 1.6. I guess what I'm wondering is how 1.6/2.0 development will be organized; finishing 1.6, and postponing augmented assignment/list comprehensions/whatever until 2.0, seems like the best course, since it means we won't have to wrestle with 2 development branches. --amk From thomas@xs4all.net Sat Jul 22 18:34:45 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 19:34:45 +0200 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000722123603.A24658@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jul 22, 2000 at 12:36:03PM -0400 References: <20000722113028.J9897@xs4all.nl> <20000722065546.A18263@thyrsus.com> <003301bff3e1$bd5dde60$360bfea9@beopen.com> <20000722123603.A24658@newcnri.cnri.reston.va.us> Message-ID: <20000722193445.M9897@xs4all.nl> On Sat, Jul 22, 2000 at 12:36:03PM -0400, Andrew Kuchling wrote: > On Sat, Jul 22, 2000 at 06:35:38AM -0700, Guido van Rossum wrote: > >- Python 1.6 (a CNRI release with PythonLabs' help) will come out with > >CNRI's Open Source License in two phases: a beta around August 1st, and a > >final release mid-August (of course this schedule is subject to the usual > >qualifications). This will release all of the work on Python done at CNRI > >since 1.5.2 was released to the public -- a significant step. > So, what version does the current CVS tree represent? Is it what will > become 1.6, or will some things be removed from the CVS tree in order > to make the 1.6 release? From reading the feature lists, it looks > like none of the 2.0 features are checked in yet, so I'd wager that > the CVS tree is 1.6. How I read it, and what I understood from Jeremy's unofficial response last week, is that 1.6 will be everything that was included while Guido (and Barry, Jeremy and Fred) worked at CNRI. That can probably be seen as everything before the CVS tree moved to SourceForge, plus a bit. I'd suspect some of the half-developed features and most of the bugfixes will move into 1.6 as well, but that's just because that makes sense to me -- so it might not be what CNRI wants ;) > I guess what I'm wondering is how 1.6/2.0 development will be > organized; finishing 1.6, and postponing augmented assignment/list > comprehensions/whatever until 2.0, seems like the best course, since > it means we won't have to wrestle with 2 development branches. In the above interpretation, the current CVS tree is 2.0-to-be. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one@email.msn.com Sat Jul 22 18:41:03 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 13:41:03 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000722123603.A24658@newcnri.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > ... > (I haven't read the licence yet -- no way to read Word on this > Linux laptop.) Plain text below, or see http://hdl.handle.net/1895.22/1011. I like the old Python license better -- but then I'm relatively sane . > So, what version does the current CVS tree represent? Is it what will > become 1.6, or will some things be removed from the CVS tree in order > to make the 1.6 release? From reading the feature lists, it looks > like none of the 2.0 features are checked in yet, so I'd wager that > the CVS tree is 1.6. Guido said "This [1.6] will release all of the work on Python done at CNRI since 1.5.2 was released to the public". The great recent burst of Python-Dev activity in the CVS tree was not done at CNRI, or the bulk of it even by people with any connection present or past to CNRI. > I guess what I'm wondering is how 1.6/2.0 development will be > organized; finishing 1.6, and postponing augmented assignment/list > comprehensions/whatever until 2.0, seems like the best course, since > it means we won't have to wrestle with 2 development branches. I *expect* that only BeOpen PythonLabs, and perhaps CNRI, will wrestle with 1.6, working from a snapshot of the CVS tree as of the day after Guido et alia left. As Guido also said, 1.6 will be "a CNRI release with PythonLabs' help". There's no technical argument behind any of this, so don't even try to start a fruitful discussion . For example, consider all the patches added since then that did not come with CNRI's disclaimer -- mucking with that retroactively would slow everything (both 1.6 and 2.0!) down. And that's not the only artificial hassle: you should know better than most the nature of the issues involved in a CNRI release. Python-Dev should focus on 2.0! At heart, it's specifically Guido who owes CNRI a 1.6 release. No loss to Python-Dev, as by now he's forgotten how to write code anyway . birthing-pains-ly y'rs - tim PYTHON 1.6, Beta 1 CNRI LICENSE AGREEMENT IMPORTANT: PLEASE READ THE FOLLOWING AGREEMENT CAREFULLY. BY CLICKING ON THE "ACCEPT" BUTTON WHERE INDICATED, OR BY COPYING, INSTALLING OR OTHERWISE USING THE SOFTWARE, YOU ARE DEEMED TO HAVE AGREED TO THE TERMS AND CONDITIONS OF THIS AGREEMENT. 1. This LICENSE AGREEMENT is between the Corporation for National Research Initiatives, having an office at 1895 Preston White Drive, Reston, VA 20191 ("CNRI"), and the Individual or Organization ("Licensee") accessing and otherwise using Python 1.6, beta 1 software in source or binary form and its associated documentation, as released at the www.python.org Internet site on July __, 2000 ("Software"). 2. Subject to the terms and conditions of this License Agreement, CNRI hereby grants Licensee a non-exclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use the Software alone or in any derivative version, provided, however, that CNRI's License Agreement and CNRI's notice of copyright, i.e., "Copyright (c) 1995 - 2000 Corporation for National Research Initiatives; All Rights reserved" are both retained in the Software, alone or in any derivative version prepared by Licensee. Alternately, in lieu of CNRI's License Agreement, Licensee may substitute the following text (omitting the quotes): "Python 1.6, beta 1, is made available subject to the terms and conditions in CNRI's License Agreement. This Agreement may be located on the Internet using the following unique, persistent identifier (known as a handle): 1895.22/1011. This Agreement may also be obtained from a proxy server on the Internet using the following URL: http://hdl.handle.net/1895.22/1011". 3. In the event Licensee prepares a derivative work that is based on or incorporates the Software or any part thereof, and wants to make the derivative work available to the public as provided herein, then Licensee hereby agrees to indicate in any such work the nature of the modifications made to CNRI's Software. 4. CNRI is making the Software available to Licensee on an "AS IS" basis. CNRI MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, CNRI MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 5. CNRI SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF THE SOFTWARE FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. SOME STATES DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY SO THE ABOVE DISCLAIMER MAY NOT APPLY TO LICENSEE. 6. This License Agreement will automatically terminate upon a material breach of its terms and conditions. 7. This License Agreement shall be governed by and interpreted in all respects by the law of the State of Virginia, excluding conflict of law provisions. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between CNRI and Licensee. Licensee may not use CNRI trademarks or trade name in a trademark sense to endorse or promote products or services of Licensee, or any third party. 8. By clicking on the "ACCEPT" button where indicated, or by copying, installing or otherwise using the software, Licensee agrees to be bound by the terms and conditions of this License Agreement. ACCEPT From Fredrik Lundh" Message-ID: <031101bff407$b05879c0$f2a6b5d4@hagrid> gordon wrote: > The answer to that is contained in the answer to "Why did=20 > Guido make print a keyword?". from the archives: http://www.egroups.com/message/python-list/20 Date: Sat Dec 7, 1991 11:00pm =20 From: Guido van Rossum Subject: Why print is a built-in statement =20 From thomas@xs4all.net Sat Jul 22 19:36:10 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 20:36:10 +0200 Subject: [Python-Dev] SF Patch Manager Message-ID: <20000722203610.N9897@xs4all.nl> I noticed the SF PM was updated to send out comment-summaries and patch status along with the notification something was changed (and it's lovely, yay!) However, at roughly the same time, the PM stopped sending mail to patches@python.org when a new patch was submitted. Was the patches-notification-address changed, or is that feature disabled now ? (Or perhaps the PM update zapped the old address ?) Never-satisfied-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul@prescod.net Sat Jul 22 20:45:01 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 14:45:01 -0500 Subject: [Python-Dev] onlinehelp.py Message-ID: <3979F9BD.EE44A896@prescod.net> I've updated onlinehelp.py with some nice new features built on cool code other people wrote. It's checked in. 1. Richard Chamberlain's wrote textdoc.py which builds on Ka-Ping Yee's inspect.py. Together, they allow me to get a lot more introspective information from modules and clsses even though they may not have docstrings. It will even use comments as docstrings. Thanks to Richard who wrote textdoc.py specifically for this purpose. >>> help( foo.__init__ ) | __init__(self, qName, namespaceURI='', localName=None) | no doc string 2. If you ask for help on a string that it doesn't "know about", it will attempt to import it. >>> help( "profile" ) | profile | Class for profiling Python code. | | Modules: | | marshal, os, sys, time | | Classes: | | class HotProfile(Profile): | | The fastest derived profile example. It does not calculate | caller-callee relationships, and does not calculate cumulative ... 3. It will also try to find the string as a sub-attr of a module. This part is really cool: >>> help( "xml.dom.minidom.AttributeList.items" ) (note that xml.dom.minidom is a package, AttributeList is a class, items, is a method) All features are available from the Unix or Windows command line: python onlinehelp.py xml.dom.minidom.AttributeList.items Have fun! The rest of the message is an example transcript. >>> help( "xml" ) Topic: help( ) | xml | Core XML support for Python. | | This package contains three sub-packages: | | dom -- The W3C Document Object Model. This supports DOM Level 1 + | Namespaces. | | parser -- Python wrappers for XML parsers (currently only supports Expat ). | | sax -- The Simple API for XML, developed by XML-Dev, led by David | Megginson and ported to Python by Lars Marius Garshol. This | supports the SAX 2 API. | | Modules: | | dom, sax >>> help( "xml.dom" ) Topic: help( ) | xml.dom | W3C Document Object Model implementation for Python. | | The Python mapping of the Document Object Model is documented in <...>. | | This package contains the following modules: | | minidom -- A simple implementation of the Level 1 DOM with namespace | support added (based on the Level 2 specification). | | Modules: | | minidom, pulldom >>> help( "xml.dom.minidom" ) | Topic: help( ) | xml.dom.minidom | no doc string | | Modules: | | pulldom, string, types | | Classes: | | class Attr(Node): | | no doc string | | Methods: | | __init__(self, qName, namespaceURI='', localName=None, prefix=None) | no doc string | | __setattr__(self, name, value) | no doc string | | class AttributeList: | | the attribute list is a transient interface to the underlying --more-- (enter for more, q to quit) q 0 >>> help( "xml.dom.minidom.AttributeList" ) | Topic: help( xml.dom.minidom.AttributeList ) | class AttributeList: | | the attribute list is a transient interface to the underlying | dictionaries. mutations here will change the underlying element's | dictionary | | Methods: | | __cmp__(self, other) | no doc string | | __delitem__(self, attname_or_tuple) | no doc string | | __getitem__(self, attname_or_tuple) | #FIXME: is it appropriate to return .value? | | __init__(self, attrs, attrsNS) | no doc string | | __len__(self) | no doc string | | __setitem__(self, attname, value) --more-- (enter for more, q to quit) q >>> help( "xml.dom.minidom.AttributeList.items" ) Topic: help( ) | items(self) | no doc string | 1 >>> -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From bwarsaw@beopen.com Sat Jul 22 21:02:21 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sat, 22 Jul 2000 16:02:21 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> Message-ID: <14713.64973.585633.87443@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Why not use outputfile.write directly? Because it's less readable. log.write('post to %s from %s, size=%d\n' % (listname, sender, len(msg))) vs print 'post to', listname, 'from', sender, 'size=', len(msg) With the former, you have to know about the rules for string interpolation, you have to make sure you've got your tuple is the right length, you have to remember to add the trailing newline. PP> print is such a hack already. Maybe, but how often do /you/ use it? It's an incredibly convenient hack. PP> What are we trying to get at, really? What are the virtues of PP> print, what are the virtues of "outputfile.write" and how can PP> we combine them? Some one else outlined these: print autoconverts to string, it adds the trailing newline, it's easy for newbies to learn and it's very readable. I have no problem with the print statement, but it doesn't matter because it's never going away. I know all about the idiom for temporarily binding sys.stdout around print statements. /That/ is a hack because you're making a non-local change to the system, potentially affecting code you're not even aware of. So my extended print suggestion doesn't add any new keywords or operators (forget about `@' specifically -- it's a red herring) and I don't think it makes the statement any less readable, and in fact improves usability for little extra cognitive or code complexity costs. -Barry From bwarsaw@beopen.com Sat Jul 22 21:07:08 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sat, 22 Jul 2000 16:07:08 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> <3979CBFC.2EED0234@prescod.net> Message-ID: <14713.65260.762631.233327@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Overall, I think the language would be better off if print PP> were gone. There are more generalized ways to do what it PP> does. Really? We can start by fixing the nearly 5000 occurances of it in the Python distribution or the 230 occurances in Mailman. How often does print show up in your own code? print is incredibly convenient; I'd hate to write CGI scripts without it. Why not make it just a little more so? -Barry From paul@prescod.net Sat Jul 22 21:13:51 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 15:13:51 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> Message-ID: <397A007F.CF8DEBE2@prescod.net> "Barry A. Warsaw" wrote: > > ... > Because it's less readable. > > log.write('post to %s from %s, size=%d\n' % (listname, sender, len(msg))) > > vs > > print 'post to', listname, 'from', sender, 'size=', len(msg) Okay, how about log.writeln("Post to ", listname, " from ", sender, " size=", len( msg )) or (with auto string-coercion): log.writeln("Post to "+listname+" from "+sender+" size="+len( msg )) > With the former, you have to know about the rules for string > interpolation, you have to make sure you've got your tuple is the > right length, you have to remember to add the trailing newline. Nevertheless, every Python programmer needs to learn the ".write" way in order to do reasonable text processing. So print's idiosyncracies are just one more thing to learn. In the long run, print hurts newbies more than it helps them because it confuses them into thinking its useful and then frustrates them when they learn its a hack that always appends trailing whitespace. > So my extended print suggestion doesn't add any new keywords or > operators (forget about `@' specifically -- it's a red herring) and I > don't think it makes the statement any less readable, and in fact > improves usability for little extra cognitive or code complexity > costs. I don't see what proposal you are promoting that doesn't have "@" in it? -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul@prescod.net Sat Jul 22 21:25:34 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 15:25:34 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> <3979CBFC.2EED0234@prescod.net> <14713.65260.762631.233327@anthem.concentric.net> Message-ID: <397A033E.40CF8DA1@prescod.net> "Barry A. Warsaw" wrote: > > ... > Really? We can start by fixing the nearly 5000 occurances of it in > the Python distribution or the 230 occurances in Mailman. How often > does print show up in your own code? Print almost never shows up in my production code because I always want to allow the option of redirecting the output and assigning sys.stdout is a hack for all of the reasons you've pointed out. I do use print constantly for debug output but the whole point there is that I don't have to set up a file object. I wouldn't use it even there if Python auto-coerced strings and moved stdout into __builtins__. Or else stdout.println could auto-coerce a list of objects. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From tim_one@email.msn.com Sat Jul 22 23:06:29 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 18:06:29 -0400 Subject: [Python-Dev] SF Patch Manager In-Reply-To: <20000722203610.N9897@xs4all.nl> Message-ID: [Thomas Wouters] > I noticed the SF PM was updated to send out comment-summaries and > patch status along with the notification something was changed > (and it's lovely, yay!) However, at roughly the same time, the PM > stopped sending mail to patches@python.org when a new patch was > submitted. That's not it -- the last email in the patches archive from SourceForge was at Thu, 20 Jul 2000 15:40:33 -0700: http://www.python.org/pipermail/patches/2000-July/001221.html and is one of the new-style, more-informative msgs. > Was the patches-notification-address changed, No. > or is that feature disabled now ? No. > (Or perhaps the PM update zapped the old address ?) No. Good guesses, but everything we can affect on the SF end looks good. Just a few *hours* ago, I enabled another new SF feature: email should be sent to patches@python.org for *every* change to patch status now. Doesn't appear to be happening, though. From mhammond@skippinet.com.au Sat Jul 22 23:36:57 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 23 Jul 2000 08:36:57 +1000 Subject: [Python-Dev] Feature bloat in Python (was some PEP thing!) In-Reply-To: <3979BFB9.419EC323@prescod.net> Message-ID: [Paul] > I think that this class vague complaints are a little unfair. That is why we have these lists - so people _can_ disagree. > We've had > a wide range of proposals from extra functions to minor new syntax to > new magical methods to radically new control flow features. Yep - and I still lump them _all_ in the same category. I don't believe I have seen a _single_ PEP I would support (except maybe the "batteries included" one, as it doesn't change the language, just the distribution.) Is that specific enough? > It isn't helpful to lump them altogether and condemn them because Barry > broke the cardinal rule of never using an at-symbol in a feature syntax. Why do you believe I did? Where on earth did you get the impression this has anything to do with the "@" symbol? You seem to be the only one constantly raising this. Even when Barry says it is a red-herring, you wont let it die. I apologize to Barry for picking on his mail; this was not a reflection on the proposal as such, it was just the unfortunate straw that broke the serpent's back. I have changed the subject line to reflect this. > List which proposed features you like and don't > like and why! That's the only way your concerns could really be > addressed. Please re-read my original mail. I said "cool-but-not-really-necessary" features; other people have followed up and clearly understood that I was talking about code-bloat, and not that the features themselves necessarily suck. Each feature, in isolation, could possibly be bashed into something I support. When these are all combined I start having serious reservations. An example of the sum of the parts being significantly greater than the value added to the whole. > I think it is also worthwhile to recognize "conventions" that could be > made clearer with first-class syntax. List comprehensions replace the > map/lambda convention (and would IMHO, allow map/filter, at-least, to be > deprecated). Range literals replace the for i in range(...) convention > and so forth. Hrm - but in a later mail, you state: > Common Lisp and Linux are victims of feature creep. Perl and Sendmail > just suck. If we ignore the obvious bigotry in your statement (Perl and Sendmail "just suck" ?? Tell that to the orders of magnitude more people who use them than Python!) you have just addressed my concerns fairly succinctly. Maybe if you had made them in the same email you could have seen the conundrum? > Those of us who have already internalized the conventions are more > likely to see new syntax as an intrusion rather than as a long-term > clarification. Agreed - hence this debate is useful. However, I will state that the reason I skipped Perl and went for Python all those years ago was that the intent of Python code, even before I knew the language, was clear. This is a key feature of Python, and a selling point I always in my own advocacy efforts. Most of these proposals are watering that down, IMO. But I happily admit that neither you or I are able to make meaningful statements about that - we are too close it. > things in a straightforward way. I strongly feel that map/lambda and in > fact most uses of map fall into this category. The concept is fine but > the syntax sucks. Agreed. So when someone presents a solution that is obvious to the readers of this list, we will be well on our way. This hasn't happened yet. If you can't quickly and quietly win this friendly audience over, IMO the proposal has failed. If any proposal causes even a small thread on this forum that boils down to "but its not clear to me what this should do", then I would have thought it self-evident that the proposal sucks. Convincing us that it _should_ be obvious if only we were all a little brighter and more willing to accept change for changes sake doesn't help anyone, least of all the person making these statements. (Let me be clear that this last statement is not directed personally at Paul!) Standing-by-everything-I-said-ly, Mark. From thomas@xs4all.net Sun Jul 23 01:24:53 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 02:24:53 +0200 Subject: [Python-Dev] ANSIfication. Message-ID: <20000723022452.Q9897@xs4all.nl> I'm done checking in the ansification patches. It doesn't fix everything, for a couple of reasons: - Some function-declarations and function-pointers store functions I don't have access to, like the 'sv' and 'gl' modules, and the 'gl' module seems half auto-generated. - the 'dl' module does some nasty things which I don't feel deserve a prototype. (loading a function using dl_sym, and calling it with 10 char* arguments.) - Some prototypes aren't standardized. This is only really a problem with getopt(), called from Modules/main.c. On some systems, it's 'char **', on some it's 'const char **', and those two pointers are not compatible. (Or did they fix that in C9X ? Somehow I doubt it.) - Readline is a mess. I can start adding prototypes, but the standard readline include files don't do that either, and I'm not terribly sure on some of the prototypes, having never worked with readline myself. The infopages try to be as vague as possible on what kind of function the second argument to 'rl_bind' is, for instance ;) I've fixed the passing of 'PyErr_CheckSignals(void)' to Py_AddPendingCall (which wants a function that takes a void* argument instead) by passing a static wrapper function instead, in both instances (Modules/signalmodule.c and Parser/intrcheck.c.) I'm also tempted to suggest to remove most of the 'extern's, and possibly add them to pyport.h if they are still an issue. Most of the current externs for library functions seem to me like old cruft, though I have no way of telling how old they are. The getopt() prototype would be solved that way, in any case, by removing it and relying on the appropriate include file defining it. Here's an example of what I think is old cruft: posixmodule.c: /* XXX These are for SunOS4.1.3 but shouldn't hurt elsewhere */ extern int rename(const char *, const char *); extern int pclose(FILE *); extern int lstat(const char *, struct stat *); extern int symlink(const char *, const char *); extern int fsync(int fd); There are a couple of more things that might be candidate for cleanup or removal now, by the way. The 'ANY' #define in Include/mymalloc.h, and the type(s) derived from it, for instance. I'm not sure how 'standard' the void* type is, but I thought it was ANSI mandated ? If anyone wants to look at one or more of the above problems, here's how you can find them: find . -name '*.[ch]' | xargs fgrep extern | fgrep '()' find . -name '*.[ch]' | xargs fgrep ')()' Night-night-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake@beopen.com Sun Jul 23 03:42:29 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 22 Jul 2000 22:42:29 -0400 (EDT) Subject: [Python-Dev] ANSIfication ? In-Reply-To: <3975B093.C2F125BD@schneider-kamp.de> References: <20000719132554.B9897@xs4all.nl> <3975B093.C2F125BD@schneider-kamp.de> Message-ID: <14714.23445.744869.80794@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > I don't think so. After ANSIfying the whole Module/ directory I was fed > up. > I'd guess the same applies to Fred who slaved away in Objects/ ... I was also tired & had more important things to do. ;) If this hasn't already been done (I'm still several hundreds of messages behind), then feel free to barge ahead! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nhodgson@bigpond.net.au Sun Jul 23 04:26:43 2000 From: nhodgson@bigpond.net.au (Neil Hodgson) Date: Sun, 23 Jul 2000 13:26:43 +1000 Subject: [Python-Dev] Python Consortium Meeting News References: Message-ID: <01e601bff455$d31d3f10$8119fea9@neil> I don't like this new license as it is much more complex than the old license. Its about 4 times longer and appears to me to attempt to claim a licensing relationship with third parties who use software written in Python. Is Python going to use this license forever, or is it just for 1.6? Neil From Moshe Zadka Sun Jul 23 06:09:15 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 23 Jul 2000 08:09:15 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397A007F.CF8DEBE2@prescod.net> Message-ID: On Sat, 22 Jul 2000, Paul Prescod wrote: > "Barry A. Warsaw" wrote: > > > > ... > > Because it's less readable. > > > > log.write('post to %s from %s, size=%d\n' % (listname, sender, len(msg))) > > > > vs > > > > print 'post to', listname, 'from', sender, 'size=', len(msg) > > Okay, how about > > log.writeln("Post to ", listname, " from ", sender, " size=", len( msg > )) Better yet, have writeln auto put spaces, and you have log.writeln("Post to", listname, "from", sender, "size=%s" % len(msg)) But I'm -0 on that, preferring a new sys function, called writeln writeln("......") writeln(file=logfile, "fffffff", "ffff") and of course writeln(nl=0, "ffffff") to simulate print "ffffff", That would be extremely readable, require no new syntax and no additional builtins. Reference implementation: def writeln(*args, **kw): import sys file = sys.stdout end = '\n' if kw.has_key("file"): file = kw['file'] del kw['file'] if kw.has_key("nl"): if not kw['nl']: end = ' ' del kw['nl'] file.write(" ".join(map(str, args))+end) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From tim_one@email.msn.com Sun Jul 23 06:25:14 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 01:25:14 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <01e601bff455$d31d3f10$8119fea9@neil> Message-ID: [Neil Hodgson] > I don't like this new license as it is much more complex than > the old license. Then I'd say you're normal! The principals on "our side" of the negotiation view this license as something of a triumph, simply because it's so much less obnoxious than the proposals that preceded it. Not speaking for my employer, I think we lost. OTOH, python.org will no longer be held hostage. > Its about 4 times longer and appears to me to attempt to claim a > licensing relationship with third parties who use software written in > Python. > > Is Python going to use this license forever, or is it just for 1.6? Who knows? It's all hifalutin legalese. Note that the text Guido sent out is not the same as the text it references at http://hdl.handle.net/1895.22/1011 either. I believe it's the latter that's out of date, and the text Guido sent is friendlier to users. Still, one way to read the Guido version is that 2.0 and everything after is a "derivative work", so must (paragraph 2) include the 1.6 CNRI license, and (paragraph 3) "indicate in any such work the nature of the modifications made to CNRI’s Software". OTOH, I can see at least two other ways to read it! Perhaps a consortium member who already paid a lawyer would care to pass on their confusion . looks-infectious-to-me-ly y'rs - tim From paul@prescod.net Sun Jul 23 07:13:50 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 01:13:50 -0500 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: Message-ID: <397A8D1E.CB6F140D@prescod.net> Mark Hammond wrote: > > [Paul] > > I think that this class vague complaints are a little unfair. > > That is why we have these lists - so people _can_ disagree. I didn't mean to say otherwise. > > > It isn't helpful to lump them altogether and condemn them because Barry > > broke the cardinal rule of never using an at-symbol in a feature syntax. > > Why do you believe I did? Where on earth did you get the impression this > has anything to do with the "@" symbol? It was a joke. Obviously all of your concern does not stem from one character. On the other hand, I don't think that it is a coincidence that you jumped on the one recent proposal with a syntax that adds a character to the Python repertoire. It's ugly so its an easy target. Or to put it another way, it was *likely* to be the straw that broke the camel's back because it could change the look of Python most radically. > You seem to be the only one > constantly raising this. Even when Barry says it is a red-herring, you > wont let it die. I don't see how a fundamental element of the proposed syntax can be a red-herring! You might as well claim that the new matrix operators are a red herring in the discussion of new matrix operators. If Barry has proposed another syntax I haven't seen it. > Please re-read my original mail. I said "cool-but-not-really-necessary" > features; other people have followed up and clearly understood that I was > talking about code-bloat, and not that the features themselves necessarily > suck. Each feature, in isolation, could possibly be bashed into something > I support. When these are all combined I start having serious > reservations. An example of the sum of the parts being significantly > greater than the value added to the whole. So your opinion is that no new syntax should be added to Python unless it offers massive new functionality. But any syntax that offers massive new functionality (e.g. static type declarations, multimethods, meta-object-protocol) is going to be considered too severe of a change and/or un-Pythonic. > > I think it is also worthwhile to recognize "conventions" that could be > > made clearer with first-class syntax. List comprehensions replace the > > map/lambda convention (and would IMHO, allow map/filter, at-least, to be > > deprecated). Range literals replace the for i in range(...) convention > > and so forth. > > Hrm - but in a later mail, you state: > > Common Lisp and Linux are victims of feature creep. Perl and Sendmail > > just suck. > > If we ignore the obvious bigotry in your statement (Perl and Sendmail "just > suck" ?? Are we now in a society where it is inappropriate to criticize technologies? > Tell that to the orders of magnitude more people who use them > than Python!) I do and have. > you have just addressed my concerns fairly succinctly. Maybe > if you had made them in the same email you could have seen the conundrum? Not at all. There are lots of cool technologies that have grown far beyond their original incarnations: * Unix/Linux * Apache * Zope * EMACS * Common Lisp The important thing isn't the size of the system but the consistency and quality of its design. I was not attracted to Python because it was small but because it was self-consistent. The requirement that every new feature be consistent with the others *makes* it small. TCL is pretty small too, but I have no interest in using it. Scheme is extremely small and I had to give up on it despite my initial attraction. > Agreed - hence this debate is useful. However, I will state that the > reason I skipped Perl and went for Python all those years ago was that the > intent of Python code, even before I knew the language, was clear. This is > a key feature of Python, and a selling point I always in my own advocacy > efforts. Agreed. And do you see code with heavy map/filter/reduce usage as clear? How about code with long getattr functions, doing a dozen tricks at once? My attribute access function proposal (to take one at random :) ) could significantly clarify the code generated by makepy, which I often use as "template code" for COM programming. You talk about clarity and minimalism as if they were the same thing. It is *exactly my point* that sometimes you *trade* clarity for minimalism. On the one end of the spectrum is Common Lisp and on the other is the lambda calculus. I agree that we want to stay close to the middle. > Most of these proposals are watering that down, IMO. But I happily admit > that neither you or I are able to make meaningful statements about that - > we are too close it. If we can't make meaningful statements about usability, Python is doomed. > Agreed. So when someone presents a solution that is obvious to the readers > of this list, we will be well on our way. This hasn't happened yet. If > you can't quickly and quietly win this friendly audience over, IMO the > proposal has failed. If any proposal causes even a small thread on this > forum that boils down to "but its not clear to me what this should do", > then I would have thought it self-evident that the proposal sucks. There is no construct in the Python programming language that is self-evident *in its entirety* including all corner cases. There are a few which you can "feel around" based on knowledge from other programming languages but even those have many Pythonic twists that you can only learn by reading the documentation. Even the "for" statement would have taken a long, complicated, intricate debate on python-dev to work out the current semantics, including IndexError, else:, and mutability. The try statement is even more complex. I can't even believe that something like a=[2:30] is comparable to the various complexities *already in the language*. If Python were half as big as it is today (e.g. no classes, no exception handling), we would be having a big debate about whether to add the missing features. In other words, you have raised the bar on adding features to Python so high that it can never be met. Nothing non-trivial is ever intuitively obvious, including every edge condition and interaction. It just doesn't happen. > Convincing us that it _should_ be obvious if only we were all a little > brighter and more willing to accept change for changes sake doesn't help > anyone, least of all the person making these statements. I don't know what you are talking about. Which of these proposals require you to be a little brighter? a=[1:50] # Range literals a+=[51:60] # Augmented assignment j=[for k in a: if k%2: k*2] # list comprehensions k=zip( [1,2,3,4], [5,6,7,8] ) # parallel iteration d = dict( k ) # new builtin function Which proposals require too much intelligence? Which ones would you not be able to "sight read" coming from Java or Perl? And how do they really compare (for sight-reading) to the contemporary equivalents: a=range(1,50) a=a+range(51,60) j=[] for k in a: if k%2: j.append( k*2 ) array1=[1,2,3,4] array2=[5,6,7,8] k=[] k=map(None, array1, array2 ) d={} for name,val in k: d[name]=val Is this latter code really clearer and easier to read -- even for a newbie -- than the former? Okay, Pep 207, 208, 209 and 213 are likely to be more complex. That's because they are cleaning up parts of the language that are already relatively complex. They aren't adding significant new functionality nor syntax. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From peter@schneider-kamp.de Sun Jul 23 09:21:33 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 23 Jul 2000 08:21:33 +0000 Subject: [Python-Dev] extended print statement, uPre-PEP References: Message-ID: <397AAB0D.1803F60C@schneider-kamp.de> First I want to say, that I use the print statement mainly for debugging and for "print func.__doc__" in the shell, but I would be very unhappy to see it go away. quasi patch for readline: Moshe Zadka wrote: > > Reference implementation: > > def writeln(*args, **kw): > import sys > file = sys.stdout > end = '\n' + joinstring = ' ' > if kw.has_key("file"): > file = kw['file'] > del kw['file'] + if kw.has_key("join"): + joinstring = kw['join'] + del kw['join'] > if kw.has_key("nl"): > if not kw['nl']: ! end = joinstring > del kw['nl'] ! file.write(joinstring.join(map(str, args))+end) Or this one : def writeln(*args, **kw): import sys file = sys.stdout end = '' if kw.has_key("file"): sys.stdout = kw['file'] del kw['file'] if kw.has_key("nl"): if not kw['nl']: end = ',' del kw['nl'] exec("print "+", ".join(map(repr,args))+end) having-slept-for-three-hours-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Moshe Zadka Sun Jul 23 07:29:21 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 23 Jul 2000 09:29:21 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397AAB0D.1803F60C@schneider-kamp.de> Message-ID: On Sun, 23 Jul 2000, Peter Schneider-Kamp wrote: > First I want to say, that I use the print statement mainly > for debugging and for "print func.__doc__" in the shell, > but I would be very unhappy to see it go away. Nobody is suggesting it it went away (though writeln(func.__doc__) is not much longer) -- just that we don't add more craft for that... -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From nhodgson@bigpond.net.au Sun Jul 23 07:29:49 2000 From: nhodgson@bigpond.net.au (Neil Hodgson) Date: Sun, 23 Jul 2000 16:29:49 +1000 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: <397A8D1E.CB6F140D@prescod.net> Message-ID: <00c601bff46f$67f6fbd0$8119fea9@neil> > I don't know what you are talking about. Which of these proposals > require you to be a little brighter? > ... *** This one. > j=[for k in a: if k%2: k*2] # list comprehensions > ... > Which proposals require too much intelligence? Which ones would you not > be able to "sight read" coming from Java or Perl? And how do they really > compare (for sight-reading) to the contemporary equivalents: Maybe I'm trapped in my past here but my "sight reading" of list comprehensions brings back memories of BCPL which would have propagated the result of the loop (IIRC, the last expression evaluated within the loop) as the result of the expression. Its hardly obvious what this does based on experience with most current languages including C++, Java or VB. The counter-example given for this in current Python is much more readable to users of these languages. OTOH list comprehensions would be a more significant capability upgrade than the other changes to me and is thus worthy of a larger syntax change. Neil From paul@prescod.net Sun Jul 23 07:34:36 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 01:34:36 -0500 Subject: [Python-Dev] Consistency questions References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> <20000720172108.S9897@xs4all.nl> <14711.8162.800169.884936@beluga.mojam.com> <39773DBB.9480F7BF@prescod.net> <20000721081808.A9897@xs4all.nl> Message-ID: <397A91FC.AEB8DA7B@prescod.net> Thomas Wouters wrote: > >.... > Hm, "methods and attributes are different things, right ?" I catch > my newbie colleagues thinking that all the time ;P How about if we added a function that would help them to see the error of their ways? We could call it "attrs". -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul@prescod.net Sun Jul 23 07:36:32 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 01:36:32 -0500 Subject: [Python-Dev] [Fwd: Re: merge (Re: zip or marry etc)] Message-ID: <397A9270.3340DE88@prescod.net> This is the first name I've seen that is clearly self-descriptive: maketuples. It is a little bit wordy but it is also pretty darn clear about what is going on! -------- Original Message -------- Subject: Re: merge (Re: zip or marry etc) Date: 20 Jul 2000 11:53:49 -0400 From: Dan Schmidt Organization: Harmonix Musick Systems To: python-list@python.org Newsgroups: comp.lang.python References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <39763FF4.2CA5BF75@schneider-kamp.de> <8l59pa$6ff$1@slb1.atl.mindspring.net> <8l6vc5$c07$1@slb6.atl.mindspring.net> <+MLEAgA0Lxd5EwDd@jessikat.fsnet.co.uk> ... zip is fine with me, but if we were to choose a brand-new name, I like the make_pairs that someone proposed, or, since I guess it can work on more than two lists, make_tuples. Or how about tuple_up? :) -- Dan Schmidt | http://www.dfan.org Honest Bob CD now available! | http://www.dfan.org/honestbob/cd.html -- http://www.python.org/mailman/listinfo/python-list From bwarsaw@beopen.com Sun Jul 23 08:07:18 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 03:07:18 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> Message-ID: <14714.39334.615638.738713@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> I don't see what proposal you are promoting that doesn't have PP> "@" in it? Forget about @, let's use >> instead. What I mean by "red herring" is that it doesn't much matter what the token after print is -- we can argue about that all we want later. As long as the token can't appear in that position with any other meaningful semantics, you're fine. I've got a very rough set of patches that implement this, and here's an example that really works. I'll flesh the patches out and post them to SF. -Barry -------------------- snip snip --------------------print.py import sys from StringIO import StringIO listname = 'mylist' sender = 'barry@beopen.com' msg = 'x' * 1000 print 'post to', listname, 'from', sender, 'size=', len(msg) print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg) log = StringIO() print >> log, 'post to', listname, 'from', sender, 'size=', len(msg) print log.getvalue(), -------------------- snip snip -------------------- % ./python /tmp/print.py post to mylist from barry@beopen.com size= 1000 post to mylist from barry@beopen.com size= 1000 post to mylist from barry@beopen.com size= 1000 From mhammond@skippinet.com.au Sun Jul 23 08:08:56 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 23 Jul 2000 17:08:56 +1000 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <397A8D1E.CB6F140D@prescod.net> Message-ID: > > > It isn't helpful to lump them altogether and condemn them > > > because Barry broke the cardinal rule of never using an > > > at-symbol in a feature syntax. > > Why do you believe I did? Where on earth did you get the > > impression this has anything to do with the "@" symbol? > It was a joke. What exactly was the joke? You sound quite serious to me! > Obviously all of your concern does not stem from one > character. On the other hand, I don't think that it is a coincidence > that you jumped on the Sorry, but I don't think you are in a position to make statements about my thought processes. > It's ugly so its an easy target. You should notice that I have not made a single specific comment about this proposal. You have no clue as to my feelings on Barry's proposal. > I don't see how a fundamental element of the proposed syntax can be a > red-herring! I thought your comments on this were a joke? > So your opinion is that no new syntax should be added to Python unless > it offers massive new functionality. But any syntax that offers massive > new functionality (e.g. static type declarations, multimethods, > meta-object-protocol) is going to be considered too severe of a change > and/or un-Pythonic. Where have I made comment on "too severe" or "too un-Pythonic"? I do agree that changes to Python should offer significant benefits, as another contributor to this thread has already stated. > > If we ignore the obvious bigotry in your statement (Perl and > > Sendmail "just suck" ?? > Are we now in a society where it is inappropriate to criticize > technologies? Are we now in a society where "just suck" is a learned and reasonable critisism of a technology? Or one where bigotry, in any form, is acceptable? > > Tell that to the orders of magnitude more people who use them > > than Python!) > > I do and have. *sigh* Telling people their preferred tools "just suck" is unlikely to be effective advocacy. > Agreed. And do you see code with heavy map/filter/reduce usage as clear? Nope. Proposals to clean this up are clearly good. I have avoided making specific comments about specific proposals in these diatribes. However, the existing proposals to "solve" this, IMO, don't. > How about code with long getattr functions, doing a dozen tricks at > once? I have never seen a getattr function doing many tricks. Many attributes for sure, but almost always using the same trick. > My attribute access function proposal (to take one at random :) ) > could significantly clarify the code generated by makepy, which I often > use as "template code" for COM programming. I dont think this is a good example. makepy generated code is not meant to be readable. The fact it often is (and that I often recommend it be read) is a necessity caused by lack of reasonable documentation or alternative tools. I agree your proposal could make makepy generated code more readable; but as the point of makepy generated code is functional, I would probably keep it just as it is! makepy is, IMO, a perfect example of where getattr would still be preferred over your proposal. This is not to say I dont see merit in your proposal; I just don't think makepy is a good example. > > Most of these proposals are watering that down, IMO. But I > > happily admit that neither you or I are able to make > > meaningful statements about that - we are too close it. > If we can't make meaningful statements about usability, Python is > doomed. Im confused. You asserted that we are probably too familiar with Python to make meaningful statements about how newbies will find these syntax changes. I simply agreed, but pointed out that you are also in no position to make the counter claim. Now you are asserting we can make such statements? > I can't even believe that something like > > a=[2:30] > > is comparable to the various complexities *already in the language*. If > Python were half as big as it is today (e.g. no classes, no exception > handling), we would be having a big debate about whether to add the > missing features. I respectfully disagree. To me: a = range(2,30) is just as good, and much clearer. To compare this syntactic sugar to the language having no classes or exceptions is absurd. > I don't know what you are talking about. Which of these proposals > require you to be a little brighter? Neil has already answered. But I must concede - I am not bright enough for many of these. > a=[1:50] # Range literals I admit I _could_ guess at this. > a+=[51:60] # Augmented assignment IMO, a poor example. a+=1 _is_ obvious. a+=[51:60] is, IMO, clearly not. a += range(51,60) is better. > j=[for k in a: if k%2: k*2] # list comprehensions Yep - I admit it - I'm not bright enough. > k=zip( [1,2,3,4], [5,6,7,8] ) # parallel iteration Ditto - I have "winzip", and even zip.exe. I fully understand that the only zips I have encountered on the computer relate to compression. So presumably this is something related to list compression? > d = dict( k ) # new builtin function NFI about this? Is this a copy operation? What is the type of "k" in this example? > Which proposals require too much intelligence? Fortunately, I'm not insecure about my intelligence. [OTOH, I'm also not delusional about it ;-] I suggest most of them. > And how do they really compare (for sight-reading) to > the contemporary equivalents: > a=range(1,50) Worse. > a=a+range(51,60) Worse. > j=[] > for k in a: > if k%2: > j.append( k*2 ) Worse. > > array1=[1,2,3,4] > array2=[5,6,7,8] > k=[] > k=map(None, array1, array2 ) Better. Replace map with a loop, and it goes back to worse. > d={} > for name,val in k: > d[name]=val Worse. > Is this latter code really clearer and easier to read -- even for a > newbie -- than the former? IMO, yes. But as you earlier asserted, to which I agreed, but you then recanted, I dont believe either of us can speak for newbies. Anyway, I believe we have both made our points, and in the interests of preventing this from becoming a real flame-fest, I will refrain from further comments in this vein, and simply place my faith in the benevolent dictator. Thanking-God-Python-isnt-being-designed-by-this-committee-ly Mark. From peter@schneider-kamp.de Sun Jul 23 10:13:19 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 23 Jul 2000 09:13:19 +0000 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> Message-ID: <397AB72F.FC51AEDE@schneider-kamp.de> "Barry A. Warsaw" wrote: > > print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg) I saw `cout' being shifted "Hello world" times to the left and stopped right there. -- Steve Gonedes BTW: I think "print >> sys.stdout" is counter-intuitive, as it looks like something is flowing from print to sys.stdout. This would confuse C++-aware folk heavily. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From peter@schneider-kamp.de Sun Jul 23 10:31:39 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 23 Jul 2000 09:31:39 +0000 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: Message-ID: <397ABB7B.7867860@schneider-kamp.de> Mark Hammond wrote: > > Anyway, I believe we have both made our points, and in the interests of > preventing this from becoming a real flame-fest, I will refrain from > further comments in this vein, and simply place my faith in the benevolent > dictator. I don't want put oil in the fire. That said, I wouldn't place to much faith in the BDFL rejecting those features. Not after this statement: "- Python 2.0 (a BeOpen PythonLabs release) will start with a beta release 1-2 weeks after 1.6 final is released; we're striving for a short beta cycle. New language features will include list comprehensions, range literals, the zip() function, and augmented assignment." of-course-maybe-I-should-read-"will"-as-"could"-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From m.favas@per.dem.csiro.au Sun Jul 23 08:34:00 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Sun, 23 Jul 2000 15:34:00 +0800 Subject: [Python-Dev] _cursesmodule linking, and portability Message-ID: <397A9FE8.DC1EBB6@per.dem.csiro.au> Earlier today I uploaded a patch to SF for _cursesmodule.c so that it would link on Tru64 Unix (Version 4.0F). The problem was that the function has_key() is not present on this platform (nor, apparently, on SGI or Sun). Moshe queried whether this patch was required to link against ncurses on Tru64. ncurses does not exist on Tru64. Access to the functionality of V 4 of the X/Open curses API spec is enabled by the macro _XOPEN_SOURCE_EXTENDED - neither the header file nor the (only) curses library have any reference to has_key(). I am not a curses person (except when... ), so I do not know whether has_key() is part of the _standard_ (new?) curses, but I am concerned that the _cursesmodule.c code exposes this interface for all but SGI, Sun and Tru64 systems. What happens when Python code is written that uses this function? It will fail on at least these three platforms... Should the has_key() function be removed, or a wrapper written for those systems that don't support this function? -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From Moshe Zadka Sun Jul 23 08:40:20 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 23 Jul 2000 10:40:20 +0300 (IDT) Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: <397A9FE8.DC1EBB6@per.dem.csiro.au> Message-ID: On Sun, 23 Jul 2000, Mark Favas wrote: > Earlier today I uploaded a patch to SF for _cursesmodule.c so that it > would link on Tru64 Unix (Version 4.0F). The problem was that the > function has_key() is not present on this platform (nor, apparently, on > SGI or Sun). Moshe queried whether this patch was required to link > against ncurses on Tru64. ncurses does not exist on Tru64. I see. I think ESR (who is the new curses maintainer) decided to support only ncurses. You might convince him a) to support Tru64 curses too b) to tell you how to compile ncurses for the Tru64 At any rate, thank you for the quick response. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From Fredrik Lundh" <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> Message-ID: <005901bff47e$3ffa7b20$f2a6b5d4@hagrid> paul wrote: > Nevertheless, every Python programmer needs to learn the ".write" way = in > order to do reasonable text processing. So print's idiosyncracies are > just one more thing to learn. ...and since people need to learn how to write classes to write larger programs, we can disallow statements and functions on the module level... ...and since people need to learn how to balance parentheses to write larger data structures, we might as well reintroduce braces... ...and since people need to learn C++ and Java anyway, to solve performance problems or interface with low-level stuff, we might as well give up the whole project. >>> usability_guidelines.index("they have to learn it anyway") Traceback (most recent call last): ValueError: list.index(x): x not in list (fwiw, this is related to why adding TabError and IndentationError was a rather lousy idea...) From Fredrik Lundh" Message-ID: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> mark wrote: > If you can't quickly and quietly win this friendly audience over, IMO = the > proposal has failed. If any proposal causes even a small thread on = this > forum that boils down to "but its not clear to me what this should = do", > then I would have thought it self-evident that the proposal sucks. > Convincing us that it _should_ be obvious if only we were all a little > brighter and more willing to accept change for changes sake doesn't > help anyone, least of all the person making these statements from the new Tcl Code Team rules: "A project can also be proposed by someone outside the Tcl Core Team, but it can't be approved without an advocate on the Tcl Core Team who will take personal responsibility for it. A project must have support from at least 2 members of the Tcl Core Team (including the proposer); if anyone in the Tcl Core Team objects to the proposal, then there must be at least 4 members in favor (including the proposer). If there are two or more "no" votes then the proposal is rejected, regardless of the number of people in favor. "The idea here is that the Tcl Core Team can only work effectively if it is highly collegial; any project that generates significant = contro- versy should not go into the Tcl core." and for the record, I'm fully prepared to vote "no" on list = comprehensions, augumented assignments, range literals, and every trace of a new = operator that changes how python code is tokenized and parsed. not that it will change anything: > Thanking-God-Python-isnt-being-designed-by-this-committee-ly ...with two major releases with only a few weeks in between, I'm afraid = we'll see the usual "do we really need this?" rule being replaced with "what = can we add to make sure people know there's really a difference?". obviously, = things with fancy names and existing patches are on the top of that list :-( From m.favas@per.dem.csiro.au Sun Jul 23 09:10:35 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Sun, 23 Jul 2000 16:10:35 +0800 Subject: [Python-Dev] _cursesmodule linking, and portability] Message-ID: <397AA87B.7B00DEF@per.dem.csiro.au> This is a multi-part message in MIME format. --------------E81781852A126E47754F48FE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Should have included python-dev on this one - must be a Sunday afternoon... It's still the case that, under the current implementation, Sun and SGI platforms do not expose the has_key() function. My patch just adds Tru64 (nee Digital Unix, nee OSF/1) to that group... -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 --------------E81781852A126E47754F48FE Content-Type: message/rfc822 Content-Disposition: inline Message-ID: <397AA576.5E7548E8@per.dem.csiro.au> Date: Sun, 23 Jul 2000 15:57:42 +0800 From: Mark Favas Organization: CSIRO Exploration & Mining X-Mailer: Mozilla 4.73 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Moshe Zadka , esr@thyrsus.com Subject: Re: [Python-Dev] _cursesmodule linking, and portability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Moshe Zadka wrote: > > On Sun, 23 Jul 2000, Mark Favas wrote: > > > Earlier today I uploaded a patch to SF for _cursesmodule.c so that it > > would link on Tru64 Unix (Version 4.0F). The problem was that the > > function has_key() is not present on this platform (nor, apparently, on > > SGI or Sun). Moshe queried whether this patch was required to link > > against ncurses on Tru64. ncurses does not exist on Tru64. > > I see. I think ESR (who is the new curses maintainer) decided to support > only ncurses. You might convince him > > a) to support Tru64 curses too > b) to tell you how to compile ncurses for the Tru64 > This problem exists for Sun and SGI in exactly the same way as for Tru64. And they are supported in the _cursesmodule code in exactly the same way as I proposed for Tru64. I just checked on Solaris 8 - it also has no ncurses lib, and its curses lib does not implement has_key()... Sun and SGI are supported, without the need for anyone to ask Eric how to compile ncurses for those platforms . -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 --------------E81781852A126E47754F48FE-- From Fredrik Lundh" <397A8D1E.CB6F140D@prescod.net> <00c601bff46f$67f6fbd0$8119fea9@neil> Message-ID: <007601bff47f$b1191c20$f2a6b5d4@hagrid> neil wrote: > > > j=3D[for k in a: if k%2: k*2] # list comprehensions >=20 > Maybe I'm trapped in my past here but my "sight reading" of list > comprehensions brings back memories of BCPL which would have = propagated the > result of the loop (IIRC, the last expression evaluated within the = loop) as > the result of the expression. Its hardly obvious what this does based = on > experience with most current languages including C++, Java or VB. and my "sight reading" of this is that j is an anonymous function with a rather meaningless for-loop in it... From Moshe Zadka Sun Jul 23 09:20:54 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 23 Jul 2000 11:20:54 +0300 (IDT) Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> Message-ID: On Sun, 23 Jul 2000, Fredrik Lundh wrote: > and for the record, I'm fully prepared to vote "no" on list comprehensions, > augumented assignments, range literals, and every trace of a new operator > that changes how python code is tokenized and parsed. I wouldn't go that far, but I'd vote "not until after 2.0" on everything except range literals. The idea being that range literals is something that has discussed since before I knew of Python (which is an objective measurement of course), and we've known what form they'll take for that long. List comprehensions, augmented assignments and new operators are something with an effect on the language that I personally cannot appreciate without more testing. > ...with two major releases with only a few weeks in between, I'm afraid we'll > see the usual "do we really need this?" rule being replaced with "what can we > add to make sure people know there's really a difference?". Well, I'm less cynical -- I do believe that we won't put any features without careful thought about the side effects of usability and readability. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From thomas@xs4all.net Sun Jul 23 10:00:18 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 11:00:18 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14714.39334.615638.738713@anthem.concentric.net>; from bwarsaw@beopen.com on Sun, Jul 23, 2000 at 03:07:18AM -0400 References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> Message-ID: <20000723110018.R9897@xs4all.nl> On Sun, Jul 23, 2000 at 03:07:18AM -0400, Barry A. Warsaw wrote: > Forget about @, let's use >> instead. What I mean by "red herring" is > that it doesn't much matter what the token after print is -- we can > argue about that all we want later. As long as the token can't appear > in that position with any other meaningful semantics, you're fine. > print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg) Eventhough I said I'd prefer deprecating 'print' over doing something like this, I can actually see this work. '>>' on files has two meanings: the C++ one, and the UNIX one. I'm still not sure if it's a good idea, but given this example and the arguments for it, I'm not violently opposed anymore. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Sun Jul 23 10:01:41 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 11:01:41 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397AB72F.FC51AEDE@schneider-kamp.de>; from peter@schneider-kamp.de on Sun, Jul 23, 2000 at 09:13:19AM +0000 References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397AB72F.FC51AEDE@schneider-kamp.de> Message-ID: <20000723110141.S9897@xs4all.nl> On Sun, Jul 23, 2000 at 09:13:19AM +0000, Peter Schneider-Kamp wrote: > "Barry A. Warsaw" wrote: > > print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg) > BTW: I think "print >> sys.stdout" is counter-intuitive, as it looks > like something is flowing from print to sys.stdout. This would > confuse C++-aware folk heavily. Nonsense. This isn't C++, it's Python, and the step for this isn't as great as for other 'strange' features in Python. Furthermore, their observation is true. Something *is* flowing from print to sys.stdout. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov@inrialpes.fr Sat Jul 22 19:20:39 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sat, 22 Jul 2000 20:20:39 +0200 (CEST) Subject: [Python-Dev] object allocator In-Reply-To: <20000721073222.B25293@keymaster.enme.ucalgary.ca> from "Neil Schemenauer" at Jul 21, 2000 07:32:22 AM Message-ID: <200007221820.UAA01386@python.inrialpes.fr> Neil Schemenauer wrote: > > Nice work Vladimir. I will definately check this out in more detail > when I get my home computer back. I'm hoping we can group objects with > gc_prev and gc_next pointers and reduce the memory overhead. I am hoping for more. The major problem with the existing GC algorithm is related with the big number of objects landing in the older generation, which atomic traversal may cause dalays. That's why I mentioned the GC paper discussing this same problem. As for obmalloc, hey python-dev, make some time to check this out! We get more control, more speed and a priori less memory consumption. This is the only small piece of code that I have seen for a while that can boost the overall speed so much, given the current state of CPython. On my Linux, Pentium III 550, regrtest.py drops from 45 secs to 40 secs. I am particularly interested in feedback from Windows users -- the only popular setup I haven't tested so far... The malloc algorithm has been rewritten. Everything is incremental now, even the free list preallocation in an object's pool. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov@inrialpes.fr Sat Jul 22 18:56:03 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sat, 22 Jul 2000 19:56:03 +0200 (CEST) Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <200007211726.TAA04540@python.inrialpes.fr> from "Vladimir Marangozov" at Jul 21, 2000 07:26:15 PM Message-ID: <200007221756.TAA01359@python.inrialpes.fr> [me] > > Paul Prescod wrote: > > > > I don't have a PEP number for this yet but I wanted to go through > > another round of comments after changing the mechanism according to Don > > Beaudry's suggestions. > > ... > > Paul, this is clearly unclear <0.1 wink>. Thanks (Paul, Don, Gordon) for clarifying this pre-PEP. As I see it, this aims at providing builtin support for the following (simplified & quickly hacked) __getattr__ version: def new_getattr(self, name, rec=0): hookname = "__get_%s__" % name if not rec and hasattr(self, hookname): hook = new_getattr(self, hookname, rec=1) return hook(self) # builtin __getattr__ follows ... if self.__dict__.has_key(name): return self.__dict__[name] if self.__class__.__dict__.has_key(name): return self.__class__.__dict__[name] # ... return class_lookup(self, name) raise AttributeError, name class C: def __get_hi__(self): return "coucou" def __getattr__(self, name): return new_getattr(self, name) >>> c = C() >>> c.hi "coucou" and its setattr, delattr counterparts. But people are already massively using __getattr__ as method dispatchers, so as I understand it, this is not just about "Attribute Access Handlers". You're looking for a "Normative Naming Scheme and Builtin Support for Attribute Access Handlers", no more, no less. Okay, so make this clear in the PEP. The presented scenarios don't make this clear, IMO. I asked myself what's the enhancement here... Also, it would be useful if you could include a Python implementation of the concept, stating explicitely where the existing functionality ends, and where the proposed enhancement starts, so that people can play with it. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From esr@thyrsus.com Sun Jul 23 13:10:58 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sun, 23 Jul 2000 08:10:58 -0400 Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: <397A9FE8.DC1EBB6@per.dem.csiro.au>; from m.favas@per.dem.csiro.au on Sun, Jul 23, 2000 at 03:34:00PM +0800 References: <397A9FE8.DC1EBB6@per.dem.csiro.au> Message-ID: <20000723081058.D9463@thyrsus.com> Mark Favas : > Earlier today I uploaded a patch to SF for _cursesmodule.c so that it > would link on Tru64 Unix (Version 4.0F). The problem was that the > function has_key() is not present on this platform (nor, apparently, on > SGI or Sun). Moshe queried whether this patch was required to link > against ncurses on Tru64. ncurses does not exist on Tru64. Access to the > functionality of V 4 of the X/Open curses API spec is enabled by the > macro _XOPEN_SOURCE_EXTENDED - neither the header file nor the (only) > curses library have any reference to has_key(). I am not a curses person > (except when... ), so I do not know whether has_key() is part of > the _standard_ (new?) curses, but I am concerned that the > _cursesmodule.c code exposes this interface for all but SGI, Sun and > Tru64 systems. What happens when Python code is written that uses this > function? It will fail on at least these three platforms... Should the > has_key() function be removed, or a wrapper written for those systems > that don't support this function? OK. The story is this: 1. has_key() is unique to ncurses. It's not specified in the X/Open curses API. 2. We added it for a reason :-). It's hard to write programs that adapt to different numbers of function keys without it -- and this is still an issue. because that number still varies even though all the world is a VT100 emulator these days. So I recommend trying to add has_key to the curses module interface in Python, conditionalized on whether you can pick it out of the local curses headers. You can use the implementation in ncurses as a model. -- Eric S. Raymond You know why there's a Second Amendment? In case the government fails to follow the first one. -- Rush Limbaugh, in a moment of unaccustomed profundity 17 Aug 1993 From Moshe Zadka Sun Jul 23 13:21:31 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 23 Jul 2000 15:21:31 +0300 (IDT) Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: <20000723081058.D9463@thyrsus.com> Message-ID: On Sun, 23 Jul 2000, Eric S. Raymond wrote: > OK. The story is this: > > 1. has_key() is unique to ncurses. It's not specified in the > X/Open curses API. > > 2. We added it for a reason :-). It's hard to write programs that adapt to > different numbers of function keys without it -- and this is still an issue. > because that number still varies even though all the world is a VT100 > emulator these days. > > So I recommend trying to add has_key to the curses module interface in Python, > conditionalized on whether you can pick it out of the local curses headers. This sounds just like what Mark did. Or maybe I'm reading you wrong. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mal@lemburg.com Sun Jul 23 13:28:36 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 23 Jul 2000 14:28:36 +0200 Subject: [Python-Dev] ANSIfication. References: <20000723022452.Q9897@xs4all.nl> Message-ID: <397AE4F4.E1A9DDE0@lemburg.com> Thomas Wouters wrote: > > I'm also tempted to suggest to remove most of the 'extern's, and possibly > add them to pyport.h if they are still an issue. Most of the current externs > for library functions seem to me like old cruft, though I have no way of > telling how old they are. The getopt() prototype would be solved that way, > in any case, by removing it and relying on the appropriate include file > defining it. > > Here's an example of what I think is old cruft: > posixmodule.c: > /* XXX These are for SunOS4.1.3 but shouldn't hurt elsewhere */ > extern int rename(const char *, const char *); > extern int pclose(FILE *); > extern int lstat(const char *, struct stat *); > extern int symlink(const char *, const char *); > extern int fsync(int fd); I'd suggest doing this in two steps: 1. move the externs to pyport.h (which is the right place for these platform dependent defines and includes) and add #if 0 ... #endif around them 2. check whether these are still needed during the beta phase and if no one complains remove the cruft completely Alternatively, you could also add specific platform dependent #ifdefs to pyport.h which only enable the externs on those platforms where they are needed. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sun Jul 23 13:34:41 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 23 Jul 2000 14:34:41 +0200 Subject: [Python-Dev] Python Consortium Meeting News References: Message-ID: <397AE661.17E19867@lemburg.com> Tim Peters wrote: > > [Neil Hodgson] > > I don't like this new license as it is much more complex than > > the old license. > > Then I'd say you're normal! The principals on "our side" of the negotiation > view this license as something of a triumph, simply because it's so much > less obnoxious than the proposals that preceded it. Not speaking for my > employer, I think we lost. OTOH, python.org will no longer be held hostage. > > > Its about 4 times longer and appears to me to attempt to claim a > > licensing relationship with third parties who use software written in > > Python. > > > > Is Python going to use this license forever, or is it just for 1.6? > > Who knows? It's all hifalutin legalese. Note that the text Guido sent out > is not the same as the text it references at > http://hdl.handle.net/1895.22/1011 either. I believe it's the latter that's > out of date, and the text Guido sent is friendlier to users. Still, one way > to read the Guido version is that 2.0 and everything after is a "derivative > work", so must (paragraph 2) include the 1.6 CNRI license, and (paragraph 3) > "indicate in any such work the nature of the modifications made to CNRI?s > Software". OTOH, I can see at least two other ways to read it! Perhaps a > consortium member who already paid a lawyer would care to pass on their > confusion . Looks like we're going to have a license bloat here ;-) BTW, what happened to the CWI copyright ? It seems to be missing completely from the CNRI text... could be that we'll have to fight with three different license texts which all apply to 2.0 in the future. Why not simply make Python public-domain instead ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Sun Jul 23 14:16:12 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 15:16:12 +0200 Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: ; from moshez@math.huji.ac.il on Sun, Jul 23, 2000 at 03:21:31PM +0300 References: <20000723081058.D9463@thyrsus.com> Message-ID: <20000723151612.T9897@xs4all.nl> On Sun, Jul 23, 2000 at 03:21:31PM +0300, Moshe Zadka wrote: > On Sun, 23 Jul 2000, Eric S. Raymond wrote: > > So I recommend trying to add has_key to the curses module interface in > > Python, conditionalized on whether you can pick it out of the local > > curses headers. > This sounds just like what Mark did. Or maybe I'm reading you wrong. I think what Eric means is moving the ncurses 'has_key' function into the cursesmodule directly, so that there is an implementation for it on all platforms. (Unsure if that's feasible, though.) Or if he doesn't, he doesn't realize that it's already conditional, and hence not too useful in cursesmodule -- you can't rely on it being there. How about a fake has_key for systems that have strict XPG4 or SVr4 curses, that assumes the terminal in question has a minimal set of function keys ? I'm thinking 'vt100' here, given the abundance of vt100(-derived) terminals, but a smaller set would be fine, too, I think. Oh, and perhaps an autoconf test on has_key is a better idea than a platform specific #ifdef -- if people port ncurses to that platform, they'd get has_key after all. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul@prescod.net Sun Jul 23 16:10:00 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 10:10:00 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> Message-ID: <397B0AC8.C6780D33@prescod.net> "Barry A. Warsaw" wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> I don't see what proposal you are promoting that doesn't have > PP> "@" in it? > > Forget about @, let's use >> instead. Okay, but we're still inventing a new token that doesn't exist otherwise in the language. There are two reasons I oppose this. 1. On the one hand, we are making the print statement even more of a special "syntax region" than it already is. In my opinion that's newbie *unfriendly*. They learn how ">>" works in one place and then when they look around for somewhere else to use it, they won't find it. I think that that is profoundly unpythonic. 2. On the other hand, I oppose special case hacks *in general* because when you solve a problem in one place, it doesn't solve it elsewhere. The benefits of print are: * no requirement for parens * newline by default * easy string coercion and interpolation * less thinking about whitepspace Okay, but what about when I want these features elsewhere in the Python language? At least the last three should should be available everywhere in Python. In fact, we can do better than print: Yours: print >> sys.stdout, 'post to', listname, 'from', sender, \ 'size=', len(msg) My proposal: writeln( $"post to ${listname} from ${sender} size=${len(msg)}" ) (or) log.writeln( $"post to ${listname} from ${sender} size=${len(msg)}") Note that I have more control over whitespace than in your example. I am also reusing conventions from other popular languages. The interpolation is available *wherever* string processing is done and it uses standard Python features to redirect the output. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul@prescod.net Sun Jul 23 16:31:03 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 10:31:03 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <005901bff47e$3ffa7b20$f2a6b5d4@hagrid> Message-ID: <397B0FB7.56982655@prescod.net> Fredrik Lundh wrote: > > paul wrote: > > Nevertheless, every Python programmer needs to learn the ".write" way in > > order to do reasonable text processing. So print's idiosyncracies are > > just one more thing to learn. > > ...and since people need to learn how to write classes to write > larger programs, we can disallow statements and functions on the > module level... My first reaction was: "Great, you've demonstrated that any argument can be extended and parodied into meaningless. Big deal." But on second thought, you haven't even done that. Everything you learn about statements and functions is directly useful when you learn classes. It builds naturally. There is no conflict. Print is a magical syntax zone where everything works differently: * "," means concatenate, * objects are automatically coerced to strings, * newlines appear out of nowhere * parentheses change the behavior radically * (soon maybe) ">>" is used to redirect object invocations Nothing you learn there will help you to learn stderr.write(...) which works completely differently. > >>> usability_guidelines.index("they have to learn it anyway") > Traceback (most recent call last): > ValueError: list.index(x): x not in list Oh really? I thought that this was in the guidelines: "There should be one-- and preferably only one --obvious way to do it.." Of course it must be balanced with everything else in the guidelines, but it should be a factor. Also: "Special cases aren't special enough to break the rules." What could be more special than a unique syntax zone for writing out text to a stream? -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From m.favas@per.dem.csiro.au Sun Jul 23 16:39:52 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Sun, 23 Jul 2000 23:39:52 +0800 Subject: [Python-Dev] _cursesmodule linking, and portability References: <20000723081058.D9463@thyrsus.com> <20000723151612.T9897@xs4all.nl> Message-ID: <397B11C8.8377D2A7@per.dem.csiro.au> Thomas Wouters wrote: > > On Sun, Jul 23, 2000 at 03:21:31PM +0300, Moshe Zadka wrote: > > On Sun, 23 Jul 2000, Eric S. Raymond wrote: > > > > So I recommend trying to add has_key to the curses module interface in > > > Python, conditionalized on whether you can pick it out of the local > > > curses headers. > > > This sounds just like what Mark did. Or maybe I'm reading you wrong. > > I think what Eric means is moving the ncurses 'has_key' function into the > cursesmodule directly, so that there is an implementation for it on all > platforms. (Unsure if that's feasible, though.) Or if he doesn't, he doesn't > realize that it's already conditional, and hence not too useful in > cursesmodule -- you can't rely on it being there. > > How about a fake has_key for systems that have strict XPG4 or SVr4 curses, > that assumes the terminal in question has a minimal set of function keys ? > I'm thinking 'vt100' here, given the abundance of vt100(-derived) terminals, > but a smaller set would be fine, too, I think. > > Oh, and perhaps an autoconf test on has_key is a better idea than a platform > specific #ifdef -- if people port ncurses to that platform, they'd get > has_key after all. This seems to be the way to go. In a nutshell: from what Eric says, has_key() is a needed functionality in the curses module/package. This function is not supplied by the standard curses libraries on the Sun, SGI and Compaq/DEC Unix platforms (and, I guess, any other platforms that implement only the X/Open curses API). The code in _cursesmodule.c as it currently stands has specific support for Sun and SGI, (and compilation support for Compaq/DEC). For Sun and SGI, exposure of this has_key() function at the Python level is #ifdef'ed out (and my patch just adds Compaq/DEC to this set). If this functionality is indeed vital, there should either be an equivalent written in Python present (inside a try: - except: clause) in the curses package for those platforms not providing it natively, or code for has_key() provided in the _cursesmodule.c itself. And an autoconf test does indeed seem the best way to determine whether has_key() exists, rather than platform #ifdefs. Alternatively, support for Sun, SGI, etc should be dropped from the _cursesmodule.c code and a comment to that effect made in Setup.in. The current comment specifies only that the System V version of curses ("often supplied by the ncurses library") is required. -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From akuchlin@mems-exchange.org Sun Jul 23 16:56:27 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sun, 23 Jul 2000 11:56:27 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.65260.762631.233327@anthem.concentric.net>; from bwarsaw@beopen.com on Sat, Jul 22, 2000 at 04:07:08PM -0400 References: <1247840871-20245181@hypernet.com> <3979CBFC.2EED0234@prescod.net> <14713.65260.762631.233327@anthem.concentric.net> Message-ID: <20000723115627.B27195@newcnri.cnri.reston.va.us> On Sat, Jul 22, 2000 at 04:07:08PM -0400, Barry A. Warsaw wrote: >print is incredibly convenient; I'd hate to write CGI scripts without >it. Why not make it just a little more so? Bad example; quick-and-dirty CGI scripts may get away with using print. However, if you want decent error handling, such as not outputting a partial page if you get an exception, you need to either not use print, or replace sys.stdout to trap output from 'print' and only send the output once it's all been generated. --amk From Fredrik Lundh" <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <005901bff47e$3ffa7b20$f2a6b5d4@hagrid> <397B0FB7.56982655@prescod.net> Message-ID: <002601bff4c1$0c179200$f2a6b5d4@hagrid> paul wrote: > Oh really? I thought that this was in the guidelines: >=20 > "There should be one-- and preferably only one --obvious way to do = it.." >=20 > Of course it must be balanced with everything else in the guidelines, > but it should be a factor. Also: >=20 > "Special cases aren't special enough to break the rules." you obviously didn't read the 10-year old post I pointed to: "...everything else I could think of had other disadvantages. Perhaps printing is one of these things that are important enough to warrant more than one way to do things, even in Python..." ::: I don't know if your recent campaign to remove things from Python is an attempt to compensate for all the PEP stuff, or if you really think Python will become easier to use if we start removing the stuff that makes it easy to use... ...but instead of speculating, I'm just going to quote someone else: "I will refrain from further comments in this vein, and simply place my faith in the benevolent dictator." ::: now back to PEP200. From akuchlin@mems-exchange.org Sun Jul 23 17:07:53 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sun, 23 Jul 2000 12:07:53 -0400 Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: <397B11C8.8377D2A7@per.dem.csiro.au>; from m.favas@per.dem.csiro.au on Sun, Jul 23, 2000 at 11:39:52PM +0800 References: <20000723081058.D9463@thyrsus.com> <20000723151612.T9897@xs4all.nl> <397B11C8.8377D2A7@per.dem.csiro.au> Message-ID: <20000723120753.C27195@newcnri.cnri.reston.va.us> On Sun, Jul 23, 2000 at 11:39:52PM +0800, Mark Favas wrote: >just adds Compaq/DEC to this set). If this functionality is indeed >vital, there should either be an equivalent written in Python present Indeed; this week I'll look at translating the ncurses has_key() to Python code. Dropping support for Solaris/IRIX/Tru64 would be excessively harsh. --amk From m.favas@per.dem.csiro.au Sun Jul 23 17:58:54 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Mon, 24 Jul 2000 00:58:54 +0800 Subject: [Python-Dev] ANSIfication breaks socketmodule compile... Message-ID: <397B244E.24ADFEE1@per.dem.csiro.au> The recent bout of ANSIfication seems to have raised a couple of issues with socketmodule: 1) It now won't compile on Tru64, because the declaration of "gethostname" on line 114 conflicts with that in the system unistd.h header file. 114 declares the second parameter as size_t, unistd.h declares it as int (unless the macro _XOPEN_SOURCE_EXTENDED is defined, but that's another can of worms...). The simple fix here is to add another !(defined(__osf__) to the preceding #if line. 2) There'll be an issue on those platforms where the second parameter _is_ declared as type size_t, because the gethostname function is called at line 1402 with the second parameter cast to an int, rather than a size_t... -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From Fredrik Lundh" file signalmodule.c, line 146: #if RETSIGTYPE !=3D void return 0; #endif is that really a valid preprocessor expression? if I understand the ANSI specification correctly, it should be = interpreted as "0 !=3D 0" (in other words, it doesn't quite do what the author = expected), but MSVC 5.0 thinks that this is fatal error. From Fredrik Lundh" file signalmodule.c, line 146: #if RETSIGTYPE !=3D void return 0; #endif is that really a valid preprocessor expression? if I understand the ANSI specification correctly, it should be = interpreted as "0 !=3D 0" (in other words, it doesn't quite do what the author = expected), but MSVC 5.0 thinks that this is fatal error. I suggest removing it -- if people are using ANSI C compilers on = non-POSIX platforms, they might as well live with a warning... Index: Modules/signalmodule.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/python/python/dist/src/Modules/signalmodule.c,v retrieving revision 2.48 diff -c -r2.48 signalmodule.c *** Modules/signalmodule.c 2000/07/22 23:49:30 2.48 --- Modules/signalmodule.c 2000/07/23 18:02:02 *************** *** 94,100 **** static RETSIGTYPE (*old_siginthandler)(int) =3D SIG_DFL; - =0C static PyObject * signal_default_int_handler(PyObject *self, PyObject *args) --- 94,99 ---- *************** *** 143,151 **** siginterrupt(sig_num, 1); #endif signal(sig_num, signal_handler); ! #if RETSIGTYPE !=3D void ! return 0; ! #endif } --- 142,148 ---- siginterrupt(sig_num, 1); #endif signal(sig_num, signal_handler); ! return; } From paul@prescod.net Sun Jul 23 19:06:51 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 13:06:51 -0500 Subject: [Python-Dev] print References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <005901bff47e$3ffa7b20$f2a6b5d4@hagrid> <397B0FB7.56982655@prescod.net> <002601bff4c1$0c179200$f2a6b5d4@hagrid> Message-ID: <397B343B.B00F2A67@prescod.net> Lest this get (more) out of hand, I'm not proposing that print could be deprecated in the forseeable future. We can, however, make it easier to write to file objects (and cstring objects, and...) rather than making print *more* of a special syntax zone than it already is. If we do our jobs well then people may see the writeln function/method as a simpler, more flexible alternative to print and use it of their own accord. Fredrik Lundh wrote: > > ... > > you obviously didn't read the 10-year old post I pointed to: > > "...everything else I could think of had other disadvantages. > Perhaps printing is one of these things that are important > enough to warrant more than one way to do things, even > in Python..." I absolutely did, that's why I said: > > Of course it must be balanced with everything else in the guidelines, > > but it should be a factor. Do you disagree???? To put it another way: you can tell me that you disagree with my conclusions about print without stating that the guidelines I am using to argue it are somehow inappropriate. So you balance the various guidelines differently than I do. Fine! We can agree to that without claiming that the other person's arguments are invalid. Having a single, obvious way to do something is *one factor we should keep in mind*. Do you disagree???? In the same message you quoted, Guido admitted that his weightings are questionable. Maybe he still stands by them. Maybe he doesn't. He sure isn't going to get mad at me (as you are) merely for raising the question! > I don't know if your recent campaign to remove things from Python is > an attempt to compensate for all the PEP stuff, or if you really think > Python will become easier to use if we start removing the stuff that > makes it easy to use... > > ...but instead of speculating, I'm just going to quote someone else: Funny, it looks like you have already speculated! I happen to think that the print special syntax zone does not make Python easier to use *in the long run* and I offer the following frequently asked questions as evidence: "How do I make print not put a newline at the end?" "Okay, now how do I make it not put whitespace at the end?" "Why is print a statement at all?" and the following infrequently asked questions: "Why can't I have a method named print?" "Why is the syntax for writing to stdout so different from the syntax for writing to stderr?" "Why are the arguments to print automatically coerced but not those for (e.g.) write?" "Why does (e.g.) dir take parentheses but print doesn't?" "I just want to append a few variables to a string. Why isn't it as easy to glue them together as it is to print them out? Shouldn't the comma insert a space?" In REXX, the print statement would print out the names of variables that weren't assigned yet. That made it really easy to do: print hello world The question is whether it made things easier for new programmers *in the long run*. I claim no there and here. (I'm told the Amiga had the string "Hello World" hardcoded in ROM some where :) ). > "I will refrain from further comments in this vein, and simply > place my faith in the benevolent dictator." Two adults should be able to disagree about a Python keyword without getting freaked out. I happen to think that part of what makes Guido a good BDFL is that he listens to people's opinions and he isn't going to get that if every language change proposal is shouted down as heresy, nor if those opposed just don't contribute on principle. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From Fredrik Lundh" w_byte is a macro that either calls C's putc, or w_more. putc takes an int, and all calls to w_byte make sure they're passing the right thing. however, w_more is defined to take a char, which results in warnings from MSVC5. quick fix: change w_more to take an integer too: Index: Python/marshal.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/python/python/dist/src/Python/marshal.c,v retrieving revision 1.53 diff -c -r1.53 marshal.c *** Python/marshal.c 2000/07/22 18:47:25 1.53 --- Python/marshal.c 2000/07/23 18:07:07 *************** *** 55,61 **** else w_more(c, p) static void ! w_more(char c, WFILE *p) { int size, newsize; if (p->str =3D=3D NULL) --- 55,61 ---- else w_more(c, p) static void ! w_more(int c, WFILE *p) { int size, newsize; if (p->str =3D=3D NULL) *************** *** 69,75 **** p->ptr =3D PyString_AS_STRING((PyStringObject *)p->str) = + size; p->end =3D PyString_AS_STRING((PyStringObject *)p->str) + = newsize; ! *p->ptr++ =3D c; } } --- 69,75 ---- p->ptr =3D PyString_AS_STRING((PyStringObject *)p->str) = + size; p->end =3D PyString_AS_STRING((PyStringObject *)p->str) + = newsize; ! *p->ptr++ =3D (char) c; } } From Moshe Zadka Sun Jul 23 19:27:16 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 23 Jul 2000 21:27:16 +0300 (IDT) Subject: [Python-Dev] ANSIfication breaks socketmodule compile... In-Reply-To: <397B244E.24ADFEE1@per.dem.csiro.au> Message-ID: On Mon, 24 Jul 2000, Mark Favas wrote: > The recent bout of ANSIfication seems to have raised a couple of issues > with socketmodule: > > 1) It now won't compile on Tru64, because the declaration of > "gethostname" on line 114 conflicts with that in the system unistd.h > header file. 114 declares the second parameter as size_t, unistd.h > declares it as int (unless the macro _XOPEN_SOURCE_EXTENDED is defined, > but that's another can of worms...). The simple fix here is to add > another !(defined(__osf__) to the preceding #if line. Hmmmm....gethostname() prototype should probably be left to system includes, and not defined at all (except maybe in pyport.h under heavy #ifdef guard) > 2) There'll be an issue on those platforms where the second parameter > _is_ declared as type size_t, because the gethostname function is called > at line 1402 with the second parameter cast to an int, rather than a > size_t... This is plain wrong! The cast should probably be deleted. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From tim_one@email.msn.com Sun Jul 23 19:29:56 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 14:29:56 -0400 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: <006c01bff4d1$67022800$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > file signalmodule.c, line 146: > > #if RETSIGTYPE != void > return 0; > #endif > > is that really a valid preprocessor expression? No. Checked in a fix a few minutes ago. > if I understand the ANSI specification correctly, it should be > interpreted as "0 != 0" (in other words, it doesn't quite do what > the author expected), No, it's simply not C. "void" has no meaning at all in a constant integer expression (which is what must appear after #if). > but MSVC 5.0 thinks that this is fatal error. Ditto 6.0, and they're both right . From thomas@xs4all.net Sun Jul 23 20:40:06 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 21:40:06 +0200 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: <006c01bff4d1$67022800$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jul 23, 2000 at 08:07:31PM +0200 References: <006c01bff4d1$67022800$f2a6b5d4@hagrid> Message-ID: <20000723214006.U9897@xs4all.nl> On Sun, Jul 23, 2000 at 08:07:31PM +0200, Fredrik Lundh wrote: > file signalmodule.c, line 146: > #if RETSIGTYPE != void > return 0; > #endif > is that really a valid preprocessor expression? According to how I interpreted gcc's documentation, yes. And it works, too, with gcc. I'll readily admit gcc isn't the perfect example of ANSIness though. > if I understand the ANSI specification correctly, it should be interpreted > as "0 != 0" (in other words, it doesn't quite do what the author expected), > but MSVC 5.0 thinks that this is fatal error. I guess I should've mentioned this seperately, in my posting last night ;) Ohwell, I doubt I would've come up with something as good as Tim's solution even if I knew the above wasn't valid. As for the other point, I'd say drop the support for 'int'-returning systems altogether. If such systems are still in use, they would've been generating warnings for a long time now. Apparently noone noticed. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one@email.msn.com Sun Jul 23 20:43:33 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 15:43:33 -0400 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: <008b01bff4d2$1a1ed140$f2a6b5d4@hagrid> Message-ID: > w_byte is a macro that either calls C's putc, or w_more. > > putc takes an int, and all calls to w_byte make sure they're > passing the right thing. > > however, w_more is defined to take a char, which results in > warnings from MSVC5. > > quick fix: change w_more to take an integer too: > ... And I see you checked that in. Good! I later replaced part of it, via a new mini-subsystem that may tick somebody off, so I'll explain that here so people can yell at me now: 1. asserts are a fundamental tool of good C practice, but are very rarely used in Python source. To encourage their use, I added an include of to Python.h, so that assert is always available. 2. Added a new Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) macro to pyport.h, which is also always available. This casts VALUE from type WIDE to type NARROW, but assert-fails if info is lost due to the cast and Py_DEBUG is #define'd (when we're not in Py_DEBUG mode, it just expands to (NARROW)(VALUE)). Note: this kind of thing is much easier to do in C++, because of inline functions and being able to templatize those on the types involved (i.e., the compiler can figure out which specific checker to expand at compile-time, rather than making you redundantly-- and hence possibly incorrectly --name the types "by hand" again). 3. It's nice that eyeballing every call to marshal's w_byte allows one to infer that the derived calls to w_more are safe, but it's much better to let the compiler check that. So I replaced the raw cast with an invocation of Py_SAFE_DOWNCAST. Doesn't cost anything except in Py_DEBUG mode. From tim_one@email.msn.com Sun Jul 23 20:55:17 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 15:55:17 -0400 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: <20000723214006.U9897@xs4all.nl> Message-ID: [Thomas Wouters] > ... > As for the other point, I'd say drop the support for > 'int'-returning systems altogether. If such systems are still > in use, they would've been generating warnings for a long time > now. Apparently noone noticed. The Unix(tm)-ish autoconfigure stuff came after my Unixish days, and I still don't have a Unixish system available so I've got scant idea how it works. From what I can dope out, RETSIGTYPE isn't mentioned in configure.in at all, but gets pulled out of thin air by magic anyway by the time "configure" is built: echo "$ac_t""$ac_cv_type_signal" 1>&6 cat >> confdefs.h <; from tim_one@email.msn.com on Sun, Jul 23, 2000 at 03:55:17PM -0400 References: <20000723214006.U9897@xs4all.nl> Message-ID: <20000723221635.V9897@xs4all.nl> On Sun, Jul 23, 2000 at 03:55:17PM -0400, Tim Peters wrote: > [Thomas Wouters] > > As for the other point, I'd say drop the support for > > 'int'-returning systems altogether. If such systems are still > > in use, they would've been generating warnings for a long time > > now. Apparently noone noticed. > > The Unix(tm)-ish autoconfigure stuff came after my Unixish days, and I still > don't have a Unixish system available so I've got scant idea how it works. > >From what I can dope out, RETSIGTYPE isn't mentioned in configure.in at all, > but gets pulled out of thin air by magic anyway by the time "configure" is > built: > echo "$ac_t""$ac_cv_type_signal" 1>&6 > cat >> confdefs.h < #define RETSIGTYPE $ac_cv_type_signal > EOF Autoconf consists of standard and user-defined rules. The standard ones are things like checking the availability of ANSI types, and usually consist of a single m4 macro: # Type availability checks AC_TYPE_MODE_T AC_TYPE_OFF_T AC_TYPE_PID_T AC_TYPE_SIGNAL AC_TYPE_SIZE_T AC_TYPE_UID_T 'AC_TYPE_SIGNAL' expands in those 40 lines of code in configure that check the return type of signal handlers. User-defined rules are like the one I wrote for right-shifting-zero-fills, and are a tad longer: there are a few 'component' macros that check for headers, functions or libraries, and you can write your own little test-program to switch on. All the macros get expanded into a shell script that compiles (and executes, when necessary) test programs. > This *suggests* it's "still an issue" under Unixy things, but beats me. > void is ANSI, int isn't. If any Unixoid swears it's OK to nuke RETSIGTYPE, > I'd be delighted to do it. configure is also built to run on any system with an almost-working K&R C compiler and something remotely resembling proto-UNIX ;) It doesn't care much about standards, because it's build in order to easily support systems that *aren't* following the standards. All in all, if the ANSI standard says signal-handlers should return void, by all means, remove the switch altogether. I removed the whole HAVE_STDARG_PROTOTYPES switch for ANSI variable-arg lists for exactly the same reason. I just wasn't sure if the return type of signal handers was defined by ANSI C. In fact, we can probably remove a lot more checks from configure.in and the code that #ifdefs on the result, if we decide to really eradicate every trace of non-ANSI code. However, it's not winning anything more than a few seconds of 'configure' time and a few milliseconds of 'cpp' time, so it's probably not worth it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Sun Jul 23 21:31:47 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 22:31:47 +0200 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 23, 2000 at 03:43:33PM -0400 References: <008b01bff4d2$1a1ed140$f2a6b5d4@hagrid> Message-ID: <20000723223147.W9897@xs4all.nl> On Sun, Jul 23, 2000 at 03:43:33PM -0400, Tim Peters wrote: > Note: this kind of thing is much easier to do in C++, because of > inline functions and being able to templatize those on the types > involved (i.e., the compiler can figure out which specific checker to > expand at compile-time, rather than making you redundantly-- and hence > possibly incorrectly --name the types "by hand" again). Is that a veiled suggestion to compile Python as C++ ? ;) I actually tried to do that, and it almost worked. Some of the current code uses a few C++ reserved words ('new', 'class') that need to be renamed, and a couple of expressions need some additional parentheses. (The Py_INCREF/DECREF macros, for instance, produced some incomprehensible g++ error.) (I tried compiling with g++ to find any lingering K&R C prototypes. And it worked, it found a few for me I hadn't realized were wrong.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one@email.msn.com Sun Jul 23 21:32:10 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 16:32:10 -0400 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: <20000723221635.V9897@xs4all.nl> Message-ID: [Thomas Wouters] > ... > All in all, if the ANSI standard says signal-handlers should > return void, by all means, remove the switch altogether. I removed > the whole HAVE_STDARG_PROTOTYPES switch for ANSI variable-arg lists > for exactly the same reason. I just wasn't sure if the return type > of signal handers was defined by ANSI C. Yes, it is. Almost nothing *else* about signals is defined to work in a portable way, but handlers are defined to return void. > In fact, we can probably remove a lot more checks from > configure.in and the code that #ifdefs on the result, if we decide > to really eradicate every trace of non-ANSI code. However, it's not > winning anything more than a few seconds of 'configure' time and a few > milliseconds of 'cpp' time, so it's probably not worth it. I don't really care about extra crap in the configure scripts, except to the extent that they baffle people porting to new platforms (the Talmudic distinctions drawn to support 197 incompatible flavors of Unix leave people on other systems scratching their heads until the earlier of wearing their fingernails away or passing out from blood loss ). What I *really* care about is getting RETSIGTYPE out of our *source* code. Macros do damage! They're hard to figure out, hard to write safely, full of surprises even so, and frustrate the heck out of single-stepping in the debugger. Unforunately, they're necessary to write robust cross-platform C code. But every one we can nuke is one less knife in the heart. Hmm ... I'll leave the Unix config stuff alone, but get rid of RETSIGTYPE in the rest of the tree. Objections? From thomas@xs4all.net Sun Jul 23 21:41:07 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 22:41:07 +0200 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 23, 2000 at 04:32:10PM -0400 References: <20000723221635.V9897@xs4all.nl> Message-ID: <20000723224107.R9892@xs4all.nl> On Sun, Jul 23, 2000 at 04:32:10PM -0400, Tim Peters wrote: > What I *really* care about is getting RETSIGTYPE out of our *source* code. > Macros do damage! They're hard to figure out, hard to write safely, full of > surprises even so, and frustrate the heck out of single-stepping in the > debugger. Unforunately, they're necessary to write robust cross-platform C > code. But every one we can nuke is one less knife in the heart. Agreed. And each one makes it harder to port to new systems ;) (I wish I had access to such a hard-to-do new system... I like a little challenge ;) > Hmm ... I'll leave the Unix config stuff alone, but get rid of RETSIGTYPE in > the rest of the tree. Objections? Sounds like a good idea to me. Does config.h get exported to extention code, by the way ? If it is, keeping it in is probably a good idea. It doesn't look like it is, though, so I'm tempted to remote the autoconf check anyway. All your reasons for removing the macros from the source go for configure.in, too, especially when porting to new systems. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one@email.msn.com Sun Jul 23 22:11:30 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 17:11:30 -0400 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: <20000723223147.W9897@xs4all.nl> Message-ID: [Tim] > Note: this kind of thing is much easier to do in C++ ... [Thomas Wouters] > Is that a veiled suggestion to compile Python as C++ ? ;) Na, just a data point. If P3K is a reimplementation from the ground up, C++ is certainly worth considering. At the O'Reilly conference, it was announced that the Perl rewrite in C++ (codenamed Topaz) has been abandoned. I didn't attend that session, but my impression from others is that they attempted to model Perl objects directly by C++ objects, and were frustrated by the consequent lack of low-level control. That's more ambitious than I would have tried. Using C++ just as "a better C" actually works, keeping the OO stuff simple and internal (e.g., I'd still expose a plain-C interface, and ignore the last 5 years of new C++ features <0.5 wink -- whether any given compiler handles them correctly is still too much of a crap shoot>). So not really C++, but maybe C++--. > I actually tried to do that, and it almost worked. Some of the current > code uses a few C++ reserved words ('new', 'class') that need to be > renamed, and a couple of expressions need some additional parentheses. > (The Py_INCREF/DECREF macros, for instance, produced some > incomprehensible g++ error.) It would be good to clean that stuff up, to ease future experiments. I haven't used C since 1994, *except* when working on Python, so stuff like "new" and "class" used in non-C++ ways bothers my eyeballs. mutual-back-scratching-ly y'rs - tim From tim_one@email.msn.com Sun Jul 23 23:23:48 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 18:23:48 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.64973.585633.87443@anthem.concentric.net> Message-ID: [Barry A. Warsaw] > ... > log.write('post to %s from %s, size=%d\n' % (listname, > sender, len(msg))) > > vs > > print 'post to', listname, 'from', sender, 'size=', len(msg) > > With the former, you have to know about the rules for string > interpolation, you have to make sure you've got your tuple is the > right length, you have to remember to add the trailing newline. OTOH, they don't produce the same output! The comma after "from %s" is missing in the latter, and the latter adds an extra space after "size=". These very much relate to the endlessly repeated newcomer questions Paul sketched, such as "how can I get rid of the trailing newline?", "how can I print to a different file?", and (IIRC, Paul missed this one) "how can I get *rid* of the space between two items?". The uncomfortable truth is that getting the output you want, to the destination you want, is usually a lot less hassle in Perl. Paul latched on to the heart of Perl's convenience with his [Paul] > log.writeln($"post to ${listname} from ${sender}, size=${len(msg)}") where I've put back the comma from Barry's original. Perhaps Barry will counter with print >> log, $"post to ${listname} from ${sender}, size=${len(msg)}" Then I'd counter-counter with print >> log, $"post to $listname from $sender, size=${len(msg)}" But there's not a new suggestion in this whole thing -- even ">>" specifically was suggested long ago for this purpose. I can't say whether Guido ever read those suggestions, but I don't recall him ever responding. ABC *did* have auto-stringifying expression interpolation in its strings, so presumably he didn't like it there. I know I didn't like it in ABC, but for an avoidable reason: it used the same character for both "interpolate this" left and right brackets, which often made it hard to see exactly what was being interpolated. I've always been surprised that Guido retained that latter property in Python's shorthand for repr (a function that doesn't *merit* a shorthand if ever there was one ): >>> print ``1+2`+`3+4`` '37' >>> I'm not sure how Python's parser manages to get that straight! In Precodese, it would be (except that $(x) is presumably str(x) rather than repr(x)): print $"$($(1+2)+$(3+4))" which at least makes the grouping clear. I'm all for it. in-principle-if-not-in-every-detail-ly y'rs - tim From tim_one@email.msn.com Mon Jul 24 01:55:10 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 20:55:10 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <397AE661.17E19867@lemburg.com> Message-ID: [M.-A. Lemburg] > BTW, what happened to the CWI copyright ? It seems to be missing > completely from the CNRI text... could be that we'll have > to fight with three different license texts which all apply > to 2.0 in the future. > > Why not simply make Python public-domain instead ? CNRI wanted a new licence, and CNRI wrote the new license text. Their motivations and reasoning were-- and remain --a mystery to me (not in the sense that I didn't understand them, but in the plainer sense that I was never told -- everything they said on the subject consisted of the single msg Guido forwarded to c.l.py, which said nothing specific -- perhaps they said more at the consortium mtg? don't know). Can only suggest you direct questions to the people Guido named in his announcement (Dr. Kahn at CNRI, Bob Weiner at BeOpen). From bwarsaw@beopen.com Mon Jul 24 03:07:40 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 22:07:40 -0400 (EDT) Subject: [Python-Dev] Evolving Python (was Re: Feature bloat in Python ...) References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> Message-ID: <14715.42220.655527.947800@anthem.concentric.net> I think we're going about this all wrong. We all have our pet peeves, syntax gripes, missing functionality, etc. about Python. We're all so quick to identify these problems and expect everybody else to agree with us. We proposal solutions or enhancements to the language that of course, everybody should immediately agree on. But we never get consensus. Given the size of the developer community, and the diversity of applications and experience, we never will on any of these features. If we put each PEP and pre-PEP up for a vote here, I'll bet every one would fail. The Perl6 and Tcl crews should take a lesson here. You cannot design a language by committee. I'm beginning to think that our role on python-dev is different than we thought. I think for a particular proposal for a new language feature, or core language functionality, it is our job to explore the details and ramifications as much as possible. These should be summarized in a PEP, and it must have running code or a working patch. Guido can't possibly follow every thread in this mailing list and he shouldn't have to. But he can read a PEP, apply a patch, play with the new feature and decide yeah, nay, lukewarm-but-needs-more-work. We need to make Guido's job as language designer and BDFL easier, not harder. Sniping at each other means he has to get involved in petty crap among his advisors. This is what I'd hoped the PEPs and python-dev would be for: to encourage people to explore ways to improve the language and for people to work together to write good proposals and build good code. Even if it's eventually rejected. If you have a language feature that you're willing to champion, then I encourage you to write a PEP and develop a patch. Post the patch to SF so others can play with it. Without working code, a language proposal should by default be considered incomplete. Tired-and-venting-ly, -Barry From paul@prescod.net Mon Jul 24 03:11:57 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 21:11:57 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: Message-ID: <397BA5ED.D3C33699@prescod.net> Tim Peters wrote: > > ... > > I'm not sure how Python's parser manages to get that straight! In > Precodese, it would be (except that $(x) is presumably str(x) rather than > repr(x)): > > print $"$($(1+2)+$(3+4))" > > which at least makes the grouping clear. I'm all for it. Egad. It's enough to make me think twice about my own proposal. :) Nevertheless, I agree it's clearer than your tick-example which almost made me run for my plotted plant. As happy as I am to have it called Prescod-ese, I admit to influence from some languages that (otherwise) suck. :) credit-where-due 'ly yrs -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul@prescod.net Mon Jul 24 03:42:48 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 21:42:48 -0500 Subject: [Python-Dev] pep-dev References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> Message-ID: <397BAD28.E4BF7E54@prescod.net> "Barry A. Warsaw" wrote: > > ... > > I'm beginning to think that our role on python-dev is different than > we thought. I think for a particular proposal for a new language > feature, or core language functionality, it is our job to explore the > details and ramifications as much as possible. These should be > summarized in a PEP, and it must have running code or a working patch. This isn't directly a followup but you've touched on something I've been thinking. I have been thinking for several days that PEPs give us a clear dividing line between what could go on in Python-dev and what could go on in a theoretical "other mailing list" with an open subscription. I called this once "Python syntax" but instead we could call it pep-dev. If we make a pep-dev mailing list where anyone could contribute then we could have a lot more input from the Python community but the list could still be focused enough that current python-dev'ers would feel like they weren't wading through a million TKinter and curses questions. Python-dev itself could be reserved for final implementation questions once a feature has been accepted. Guido wouldn't need to read every message in PEP-dev because the whole point is to come up with a PEP that he *could* read. In fact, nobody would read every message of PEP-dev (well, maybe Thomas Wouters, he seems to have infinite energy). Each message could be clearly labelled as relating to this PEP or that one and if you aren't interested, you could just ignore that thread. Messages that are not about a PEP would be strongly frowned upon. Discussing curly-brace delimiters is fine -- as long as the end result is a PEP that ensures that we never, ever have to discuss it again because it clearly states all of the arguments for and against. (okay, maybe I'm dreaming) Even if you hate the features being proposed in PEPs, it seems really useful to describe each of them once so that we have something to point at and say: "Yeah, we've thought about it in detail and Guido decided against it. Raising it again won't help." There are also some issues that really should be worked out somewhere, like our standard package hierarchy (if any) and the class hierarchy we will use after type/class unification. And a formal definition of some of our implicit interfaces...etc. etc. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From bwarsaw@beopen.com Mon Jul 24 03:49:47 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 22:49:47 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> Message-ID: <14715.44747.65722.305555@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> log.writeln("Post to ", listname, " from ", sender, " size=", PP> len( msg )) That could work, if we added writeln() to all file-like objects. One advantage of extending print is that the write() method is already a documented (and existing) interface. PP> or (with auto string-coercion): PP> log.writeln("Post to "+listname+" from "+sender+" size="+len( PP> msg )) Isn't adding auto string-coercion a more radical suggestion than extending print? -Barry From tim_one@email.msn.com Mon Jul 24 03:55:36 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 22:55:36 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397BA5ED.D3C33699@prescod.net> Message-ID: [Tim] > ... > I'm not sure how Python's parser manages to get that [``1+2`+`3+4``] > straight! In Prescodese, it would be (except that $(x) is presumably > str(x) rather than repr(x)): > > print $"$($(1+2)+$(3+4))" > > which at least makes the grouping clear. I'm all for it. [Paul Prescod] > Egad. It's enough to make me think twice about my own proposal. :) > > Nevertheless, I agree it's clearer than your tick-example which almost > made me run for my plotted plant. Yes, both examples suck, but distinct left & right bracketing characters at least make the extremes tractable. They also make the usual cases obvious, as some of us have learned from languages that suck . > As happy as I am to have it called Prescod-ese, I admit to influence > from some languages that (otherwise) suck. :) Indeed, if Perl got the philosophy wrong but many details right, then Python may be open to the opposite critique. BTW, triple-quoted strings got added to Python after I whined (& whined, & whined) on c.l.py that I was writing some block-output generating programs in Perl because pasting screen-width strings with explicit newlines together was driving me nuts in Python. Wouldn't be the first time we stole the heart of a decent detail from Perl! Python's "%(name)format" % dict is great (& better than Perl) for fine-grained control of formatting, but we're missing Perl's ease in the vast area between that and what plain "print" can do. Perl's got nothing to be ashamed of here: Larry looked at the mass of insanely convoluted quoting and interpolation rules from the Unix shells and from Tcl, and came up with something downright Pythonic in its uniformity and simplicity. Except he couldn't resist pushing it too far (e.g., trying to *guess* whether "[]" are literal characters or an indexing operator in "$a[$b]"). BTW, at the time, half the people on c.l.py complained that triple-quoted strings were unnecessary feature bloat too. Jeez, if I cared about what was *necessary*, I'd program in Scheme <0.3 wink>. BTW too, in "There should be one-- and preferably only one --obvious way to do it", "obvious" doesn't mean instantly understandable to someone from Mars. Nothing in computer languages is obvious in that sense. It means more "easy to learn and hard to forget once you know it", and that the vast majority of people who know the language are likely to spell it the same way. Sequence slicing is the perfect example: newbies are routinely baffled by it, but once they get it they never lose it, and all of us use it. Pushing and popping sys.stdout doesn't qualify as obvious that way, ditto the twenty ways to paste the output you want together by hand now (note that whenever this pops up on c.l.py, about as many alternatives are suggested as there are responses -- unPythonic). we-can-leave-python-alone-when-it-finishes-becoming-python-ly y'rs - tim From bwarsaw@beopen.com Mon Jul 24 04:01:42 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:01:42 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <397A007F.CF8DEBE2@prescod.net> Message-ID: <14715.45462.695712.12998@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> But I'm -0 on that, preferring a new sys function, called MZ> writeln MZ> That would be extremely readable, require no new syntax and no MZ> additional builtins. MZ> Reference implementation: Add a `sep' keyword, check for residual keyword arguments, and I might be +0 on that. Of course, now you're in the realm of... so-easy-i'll-just-cut-and-paste-this-into-my-own-app-ly y'rs, -Barry -------------------- snip snip -------------------- def writeln(*args, **kws): import sys file = sys.stdout sep = ' ' end = '\n' if kws.has_key('file'): file = kws['file'] del kws['file'] if kws.has_key('nl'): if not kws['nl']: end = ' ' del kws['nl'] if kws.has_key('sep'): sep = kws['sep'] del kws['sep'] if kws: raise TypeError('unexpected keywords') file.write(sep.join(map(str, args)) + end) From bwarsaw@beopen.com Mon Jul 24 04:02:54 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:02:54 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> Message-ID: <14715.45534.435629.993813@anthem.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: BAW> I've got a very rough set of patches that implement this, and BAW> here's an example that really works. I'll flesh the patches BAW> out and post them to SF. I've now done this, so at least there's working code you can play with. -Barry From bwarsaw@beopen.com Mon Jul 24 04:10:07 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:10:07 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> Message-ID: <14715.45967.555713.668818@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: >> have PP> "@" in it? Forget about @, let's use >> instead. PP> Okay, but we're still inventing a new token that doesn't exist PP> otherwise in the language. No we're not! From token.h: #define RIGHTSHIFT 35 PP> There are two reasons I oppose this. PP> 1. On the one hand, we are making the print statement even PP> more of a special "syntax region" than it already is. In my PP> opinion that's newbie *unfriendly*. They learn how ">>" works PP> in one place and then when they look around for somewhere else PP> to use it, they won't find it. I think that that is profoundly PP> unpythonic. Where would people look to use >> in this sense elsewhere? PP> 2. On the other hand, I oppose special case hacks *in general* PP> because when you solve a problem in one place, it doesn't PP> solve it elsewhere. The benefits of print are: | * no requirement for parens | * newline by default | * easy string coercion and interpolation | * less thinking about whitepspace PP> Okay, but what about when I want these features elsewhere in PP> the Python language? At least the last three should should be PP> available everywhere in Python. Don't these things mostly crop up in printing, in one form or another. I can imagine you might want to use something like #3.5 or #4 when, e.g. building a string to be used as a regex, but in that case, you already have #3.5 and #4, and probably don't want #2. (We won't even touch #1 in that context :). -Barry From bwarsaw@beopen.com Mon Jul 24 04:12:33 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:12:33 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> <3979CBFC.2EED0234@prescod.net> <14713.65260.762631.233327@anthem.concentric.net> <20000723115627.B27195@newcnri.cnri.reston.va.us> Message-ID: <14715.46113.795737.74175@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> Bad example; quick-and-dirty CGI scripts may get away with AK> using print. However, if you want decent error handling, such AK> as not outputting a partial page if you get an exception, you AK> need to either not use print, or replace sys.stdout to trap AK> output from 'print' and only send the output once it's all AK> been generated. You're right, of course. I think extended print would make writing stuff like this more readable. -Barry From bwarsaw@beopen.com Mon Jul 24 04:21:59 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:21:59 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.64973.585633.87443@anthem.concentric.net> Message-ID: <14715.46679.547126.183981@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: | [Paul] | log.writeln($"post to ${listname} from ${sender}, size=${len(msg)}") TP> where I've put back the comma from Barry's original. Perhaps TP> Barry will counter with | print >> log, $"post to ${listname} from ${sender}, size=${len(msg)}" Actually, I'd counter with something quite similar, but much more Pythonic. print >> log, 'post to %(listname)s from %(sender)s, size=%(msglen)s' % { 'listname': listname, 'sender' : sender, 'msglen' : len(msg), } variants of which I use all the time! TP> But there's not a new suggestion in this whole thing -- even TP> ">>" specifically was suggested long ago for this purpose. :) -Barry From bwarsaw@beopen.com Mon Jul 24 04:29:21 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:29:21 -0400 (EDT) Subject: [Python-Dev] pep-dev References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> <397BAD28.E4BF7E54@prescod.net> Message-ID: <14715.47121.177301.678752@anthem.concentric.net> I think this is a very good idea Paul. -Barry From tim_one@email.msn.com Mon Jul 24 04:40:18 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 23:40:18 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14715.46679.547126.183981@anthem.concentric.net> Message-ID: [Paul] > log.writeln($"post to ${listname} from ${sender}, size=${len(msg)}") [Tim] > where I've put back the comma from Barry's original. Perhaps > Barry will counter with > > print >> log, $"post to $listname from $sender, size=$(len(msg))" [Barry] > Actually, I'd counter with something quite similar, but much more > Pythonic. > > print >> log, 'post to %(listname)s from %(sender)s, > size=%(msglen)s' % { > 'listname': listname, > 'sender' : sender, > 'msglen' : len(msg), > } > > variants of which I use all the time! Me too, but because there's nothing better: Perl people think it's *entirely* Pythonic to, e.g., need to type "listname" three times where they only need to type it once <1/3 wink>. That much redundancy on a single line of code is not helpful at all. This is simply an area where Perl is friendlier & easier. As I mentioned in another msg, Python's %(name)format shines when format is non-trivial; alas, plain unqualified %s formats account for the vast bulk of uses in my experience. From paul@prescod.net Mon Jul 24 04:41:39 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 22:41:39 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> <14715.45967.555713.668818@anthem.concentric.net> Message-ID: <397BBAF3.683DE578@prescod.net> "Barry A. Warsaw" wrote: > > No we're not! From token.h: > > #define RIGHTSHIFT 35 Okay, okay, you're inventing a new semantic for an existing token. > Where would people look to use >> in this sense elsewhere? You've got me. Maybe nowhere. Maybe they'll just ask why >> is a binary operator except in print. Maybe they'll see a=j>>k and think it has something to do with string printing. That's reasonable if you don't have the C-family background. Maybe they just look back after six months and say: "Why the hell did I learn that >> hack if it is never going to be used anywhere else in the language?" Maybe they'll just be sitting in the front row of my Python class and say: "that looks like somewhat of a hack and it reminds me of one of the ugliest features of C++" and I won't have any answer except to say: "yes its a hack, but believe me Python isn't really a hacky language...there are just a few." We all have different design aesthetics. I would rather see a hundred clean features added to Python's syntax rather than one hack. You'll recall that when you announced the addition of string methods I told you that you had cleaned up one of my two big Python embarrassments. print is the other. Renumbering: > 1 no requirement for parens > 2 newline by default > 3 easy string coercion > 4 easy string interpolation > 5 less thinking about whitespace > > Don't these things mostly crop up in printing, in one form or > another. I can imagine you might want to use something like #4 or > #5 when, e.g. building a string to be used as a regex, but in that > case, you already have #4 and #5, and probably don't want #2. (We > won't even touch #1 in that context :). I don't follow. Consider: I'm building up a string to be used to search my phones database. (Prescod, Paul): phone=555-1211, fax=555-2121 Don't I want 3, 4 and 5? Why do you say I "already have them?" def lookup( query ) regex=$"${person.lastname},${person.firstname}: .*${query}=(\w+)" .... lookup( "phone" ) lookup( "fax" ) Sure, I could set up a tuple or a dict but you pointed out yesterday that that is inconvenient. If it's too inconvenient for people who are printing things then I think it's too inconvenient for everyone. (yes, I'm confident that there is a bug in my regexp logic -- you get the picture!) -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From skip@mojam.com (Skip Montanaro) Mon Jul 24 05:12:17 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 23 Jul 2000 23:12:17 -0500 (CDT) Subject: [Python-Dev] map() for methods In-Reply-To: References: <39771CCE.F70A48D4@lemburg.com> Message-ID: <14715.49697.141824.636846@beluga.mojam.com> A couple people have responded to my comment about deprecating the string without deprecating map(). Most recently, Tim stated: >> As far as I'm aware, there's no clean way to do that with string >> methods. Tim> Sorry if someone pointed this out already (2K+ msgs backed up!): Tim> newlist = [s.strip() for s in oldlist] I realized that list comprehensions were possible, but they aren't yet in the language, so I didn't think them a fair substitute for map(string.strip, oldlist) If you get list comprehensions in there in some guise, then sure, deprecate away... Skip From skip@mojam.com (Skip Montanaro) Mon Jul 24 05:24:16 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 23 Jul 2000 23:24:16 -0500 (CDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <3979C032.357FCAF4@prescod.net> References: <20000722092530.A24247@newcnri.cnri.reston.va.us> <3979C032.357FCAF4@prescod.net> Message-ID: <14715.50416.423999.54454@beluga.mojam.com> Paul> I think it is also worthwhile to recognize "conventions" that Paul> could be made clearer with first-class syntax. List comprehensions Paul> replace the map/lambda convention (and would IMHO, allow Paul> map/filter, at-least, to be deprecated). Range literals replace Paul> the for i in range(...) convention and so forth. Range literals would also allow compilers such as Python2C to optimize Python ints to C ints. It can't do this today without assuming that range() and xrange return a sequence of ints. I guess I'll stick my neck way out there with Barry and say I rather like his "print @" proposal. Most new Python programmers learn about print earlier than a combination of somefile.write() + the "%" operator. While it might mostly be syntactic sugar, it is generally easier for new folks to understand. I suspect (though won't bother to check) that most of the I/O in the Python tutorial uses print instead of sys.stdout.write as well. Extending print's semantics to other file-like objects makes sense to me. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From skip@mojam.com (Skip Montanaro) Mon Jul 24 05:34:53 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 23 Jul 2000 23:34:53 -0500 (CDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <3979C9E4.E66FE451@prescod.net> References: <20000722092530.A24247@newcnri.cnri.reston.va.us> <3979C9E4.E66FE451@prescod.net> Message-ID: <14715.51053.852304.213936@beluga.mojam.com> Paul> Common Lisp and Linux are victims of feature creep. Perl and Paul> Sendmail just suck. Whoa there! Not to get into an off-topic shouting match of tit-for-tat, but Sendmail's syntax dates from a time when things were a lot less uniform than they are today. Machines were a helluva lot slower, had lots less memory and faced a decidedly less uniform email environment than later tools did. I don't believe early versions of Sendmail had "frozen" config files either, so parsing fast (probably with a very crude, ad hoc parser) was important. The universe of email possibilities -- both in addressing and connectivity -- was much broader than it is today. You had !-paths, Bitnet, SMTP, CSNet, direct connections, store-and-forward and fewer standards (like RFC-822 and its descendants). Unlike more recent tools, Sendmail did it all. That very few people ever have to stare at a raw sendmail.cf file anymore is a big credit to the Sendmail gang in my opinion... Skip From Moshe Zadka Mon Jul 24 06:02:32 2000 From: Moshe Zadka (Moshe Zadka) Date: Mon, 24 Jul 2000 08:02:32 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14715.45462.695712.12998@anthem.concentric.net> Message-ID: On Sun, 23 Jul 2000, Barry A. Warsaw wrote: > Add a `sep' keyword, check for residual keyword arguments, and I might > be +0 on that. Of course, now you're in the realm of... > > so-easy-i'll-just-cut-and-paste-this-into-my-own-app-ly y'rs, Well, I know Python, being very quick to write in, makes this awfully easy. But I still thing people would use import sys sys.writeln("hello", first_name, last_name+",") rather then def writeln(*args, **kws): ... writeln(...) Actually, I'm beginning to think we need a utils.py module for this, and the cool generator stuff. If we decide we need this in the builtins, the builtin module could do the equivalent of "from utils import *" or-we-could-just-make-python-harder-to-write-in-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From Moshe Zadka Mon Jul 24 06:21:03 2000 From: Moshe Zadka (Moshe Zadka) Date: Mon, 24 Jul 2000 08:21:03 +0300 (IDT) Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: Message-ID: On Sun, 23 Jul 2000, Tim Peters wrote: > At the O'Reilly conference, it was announced that the Perl rewrite in C++ > (codenamed Topaz) has been abandoned. I didn't attend that session, but my > impression from others is that they attempted to model Perl objects directly > by C++ objects, and were frustrated by the consequent lack of low-level > control. As another data-point, I've heard from reliable sources that Topaz was written to use bleeding edge C++, including all manners of weird templates. C++ I might be able to live with, but a very least common denominator C++ -- otherwise you hurt the well-known Python portability, which is a major strength. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From klm@digicool.com Mon Jul 24 06:29:36 2000 From: klm@digicool.com (Ken Manheimer) Date: Mon, 24 Jul 2000 01:29:36 -0400 (EDT) Subject: [Python-Dev] aargh Message-ID: <14715.54336.634634.776495@korak.digicool.com> I'm feeling some dismay reading over recent postings to python-dev. Particularly some of the rancor in the print discussion, and "Thank god guido is still in charge, and not going to go crazy", countered by "but guido said he was going to do this or that, ha" - i found myself thinking that (1) i'm glad i'm not in guido's place, and (2) geeze, aren't we making guido job harder, not easier? What the heck is going on? I think people are sounding off too much, posing features and opinions when they don't *need* to do so. People should think twice before posing new python features - and hold off, a lot more of the time. Treat every single thing you propose as if it costs something significant - because it does! Not only does it take bandwidth - which could be concentrated on crucial ideas - but if the feature does fly, it means sacrificing some established familiarity, a valuable commodity in the language business. Change costs, and usually needs to be worth a lot to be worth the while! Those of you offering lots of clever changes - what are you doing? Do you really think they're all so important, or are you just pleased to be finding neat little ideas? Everyone needs to hold out for what they at least consider outstandingly important. Ken klm@digicool.com From thomas@xs4all.net Mon Jul 24 06:36:02 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 24 Jul 2000 07:36:02 +0200 Subject: [Python-Dev] pep-dev In-Reply-To: <397BAD28.E4BF7E54@prescod.net>; from paul@prescod.net on Sun, Jul 23, 2000 at 09:42:48PM -0500 References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> <397BAD28.E4BF7E54@prescod.net> Message-ID: <20000724073602.Y9897@xs4all.nl> On Sun, Jul 23, 2000 at 09:42:48PM -0500, Paul Prescod wrote: > "Barry A. Warsaw" wrote: > > I'm beginning to think that our role on python-dev is different than > > we thought. I think for a particular proposal for a new language > > feature, or core language functionality, it is our job to explore the > > details and ramifications as much as possible. These should be > > summarized in a PEP, and it must have running code or a working patch. For the record, this has always been how I saw PEPs, with the slight distinction that sometimes Guido would come along and offer divine guidance, and the PEP would reflect Guido's opinion in the end. There is nothing wrong with it reflecting the community's opinion, though, as long as the champion is able to grasp all of it. Guido's 'guidance' could just be his judgement of the final result ;) Though on some subjects, this might require a fair ammount of Guido-channeling on the side of the champion, in order not to waste too much time on things Guido will not allow anyway. Things like user-defined syntax in the core language. > Guido wouldn't need to read every message in PEP-dev because the whole > point is to come up with a PEP that he *could* read. In fact, nobody > would read every message of PEP-dev (well, maybe Thomas Wouters, he > seems to have infinite energy). Not at all ! I have been purposely ignoring most of the numerous messages on python-list about new operators, user-defined operators and multimethods. I even have trouble following python-dev sometimes ;) especially in the longer-posted threads. I seem to have near-endless energy discussing the finer points of coding style and standards, and actually toying with code, merely because programming is one of my great passions, and the only one I can't really relieve at work or with my girlfriend ;) > Each message could be clearly labelled as relating to this PEP or that one > and if you aren't interested, you could just ignore that thread. Excellent idea. We should have realized before that python-list and python-dev are too much 'involved' fora for proto-ideas: everyone worries (on both lists) that what someone else proposes is going to be accepted without counterword, so everyone has something to add or counter. I would suggest plenty of drafts before a PEP is accepted, though, and give everyone on python-list and python-dev time to get their own comments added to the PEP. If python.org is still being held hostage, I can create a couple of lists for this purpose (but Barry already knows that ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From esr@thyrsus.com Mon Jul 24 06:55:00 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 01:55:00 -0400 Subject: [Python-Dev] aargh In-Reply-To: <14715.54336.634634.776495@korak.digicool.com>; from klm@digicool.com on Mon, Jul 24, 2000 at 01:29:36AM -0400 References: <14715.54336.634634.776495@korak.digicool.com> Message-ID: <20000724015500.A14548@thyrsus.com> Ken Manheimer : > I think people are sounding off too much, posing features and opinions > when they don't *need* to do so. People should think twice before > posing new python features - and hold off, a lot more of the time. OK, the recent discussion has been chaotic. But it's had two results I think are valuable. 1. We killed off a bad syntax (for parallel iterations) and replaced it with a clean builtin function that will genuinely add to the language without adding undue complications (zip). 2. The PEPs will direct, and perhaps make unnecessary, a lot of future discussion on language extensions. Even failed PEPs will be valuable if they show that certain propositions that look initially attractive can't be well defined or can't justify their complexity overhead. Personally, I also think the case for range literals has been made even if the other PEPs fail on various grounds. -- Eric S. Raymond A ``decay in the social contract'' is detectable; there is a growing feeling, particularly among middle-income taxpayers, that they are not getting back, from society and government, their money's worth for taxes paid. The tendency is for taxpayers to try to take more control of their finances .. -- IRS Strategic Plan, (May 1984) From bwarsaw@beopen.com Mon Jul 24 06:45:18 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Mon, 24 Jul 2000 01:45:18 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> <14715.45967.555713.668818@anthem.concentric.net> <397BBAF3.683DE578@prescod.net> Message-ID: <14715.55278.925626.187181@anthem.concentric.net> | def lookup( query ) | regex=$"${person.lastname},${person.firstname}: .*${query}=(\w+)" | .... So let me try to guess what you mean here. I really have no idea if I'm right. $"..." is some new type of syntax that says to do magic name lookup and interpolation when creating the string. person.lastname must be an attribute on some object bound to the variable `person'. Where does `person' come from? I guess you'd use the normal namespace rules, so if I saw this function in your code I'd have to assume that person appears in the globals (because putting it in builtins is bad form and I don't see it in the function's locals). But you really don't need any of that new magic stuff or new syntax (or is it a new string type?). The nugget of interesting new functionality here is that your doing attribute lookup inside a string interpolation, and /that/ might be a cool thing to have. E.g. def lookup(query): regex = '%(person.lastname)s,%(person.firstname)s: .*%(query)s=(\w+)' \ % vars() seems reasonable to me, and doesn't add nearly as much new or magical stuff as your example above. -Barry From tim_one@email.msn.com Mon Jul 24 07:18:55 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 24 Jul 2000 02:18:55 -0400 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > ... > ...with two major releases with only a few weeks in between, I'm > afraid we'll see the usual "do we really need this?" rule being > replaced with "what can we add to make sure people know there's > really a difference?". FWIW, and as I understand it, at one point in the negotiations with CNRI, the idea was raised (by them) that the only way to release Python 2.0 with a different license than CNRI's new 1.6 license was indeed to make major changes so that "people know there's really a difference". I don't know whether that still applies, but at the time it sure seemed to intensify Guido's sense of urgency about these proposals <0.9 wink>. > obviously, things with fancy names and existing patches are on > the top of that list :-( And, in most cases, not only fancy names and patches, but also years of favorable preceding discussion. In particular, none of the things you mentioned (list comprehensions, augumented assignments, range literals) is in any sense new, or has escaped being debated to death multiple times. The only new thing in the debates this year was a convincing argument that the syntax for lockstep "for" loops probably sucked. the-"do-we-need-this?"-parts-were-decided-before-ly y'rs - tim From Moshe Zadka Mon Jul 24 07:38:12 2000 From: Moshe Zadka (Moshe Zadka) Date: Mon, 24 Jul 2000 09:38:12 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14715.44747.65722.305555@anthem.concentric.net> Message-ID: On Sun, 23 Jul 2000, Barry A. Warsaw wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> log.writeln("Post to ", listname, " from ", sender, " size=", > PP> len( msg )) > > That could work, if we added writeln() to all file-like objects. One > advantage of extending print is that the write() method is already a > documented (and existing) interface. No, this is an advantage for having "writeln" as a function rather then a method. > Isn't adding auto string-coercion a more radical suggestion than > extending print? Well, I'm not sure which one I fear more -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From paul@prescod.net Mon Jul 24 08:01:18 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 02:01:18 -0500 Subject: [Python-Dev] aargh References: <14715.54336.634634.776495@korak.digicool.com> Message-ID: <397BE9BE.14517764@prescod.net> Ken Manheimer wrote: > > ... > > Those of you offering lots of clever changes - what are you doing? Do > you really think they're all so important, or are you just pleased to > be finding neat little ideas? Everyone needs to hold out for what > they at least consider outstandingly important. Why? When did sharing ideas hurt anyone? If Guido likes them, he'll put them in. If he doesn't, we're wasting our own time. I think that trying to improve Python is a pretty good way to waste my time. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul@prescod.net Mon Jul 24 08:23:30 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 02:23:30 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> <14715.45967.555713.668818@anthem.concentric.net> <397BBAF3.683DE578@prescod.net> <14715.55278.925626.187181@anthem.concentric.net> Message-ID: <397BEEF2.AF9E1C74@prescod.net> "Barry A. Warsaw" wrote: > > ... > The nugget of interesting new > functionality here is that your doing attribute lookup inside a string > interpolation, and /that/ might be a cool thing to have. Attribute lookup is just a special case of expressions. What if I needed to do a function call? *You* were the one that prompted me to think up this syntax (actually I probably remembered some it from some work Ping did years ago...) The original example had a function call in it. There is no nice way to integrate a function call (or method call) into ""%vars(). That's what gave rise this this: print >> log, 'post to %(listname)s from %(sender)s, size=%(msglen)s' % { 'listname': listname, 'sender' : sender, 'msglen' : len(msg), } It seems we're going around in circles, though. You were the one that said that the percent operator is inconvenient way back here: http://www.python.org/pipermail/python-dev/2000-July/013837.html I think you were right back then! Also, I agree with Tim that what we have is great for all kinds of corner cases but a pain for a lot of the common ones. Other minor problems include: 1. "Why do I have to say the s in %()s when I'm using the s formatting code 97.68% of the time?" I shouldn't need to. To me, the s looks like a pluralization of listname and sender. A template should have clear delimiters so that it is straightforward to read. 2. "Why do I have to tell it what namespace to evaluate in when 93.5% of the time, it's vars()?" Anyhow, you may be right that a less severe change is possible. I went with the dollar sign syntax because a) it is very much like many other languages that many programmers have used and b) because it didn't have the backwards compatibility issues of trying to stay compatible with printf (especially that trailing-s thing). -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From ping@lfw.org Mon Jul 24 10:13:42 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Mon, 24 Jul 2000 02:13:42 -0700 (PDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397BA5ED.D3C33699@prescod.net> Message-ID: On Sun, 23 Jul 2000, Paul Prescod wrote: > As happy as I am to have it called Prescod-ese, I admit to influence > from some languages that (otherwise) suck. :) I agree that formatting and interpolation is one area where Perl is much stronger, and it should be easy to do such things in Python. > credit-where-due 'ly yrs I kind of hate to do this, but i can't restrain myself from pointing out that i *did* propose just this solution quite recently, in: http://www.python.org/pipermail/python-dev/2000-July/012764.html I wrote a module to do this a few years ago (1996, i think). It supported attribute lookup, item lookup, and expressions. (No one has yet mentioned the issue of escaping the dollar sign, which i handled by doubling it.) See the exact rules described, with examples, at http://www.lfw.org/python/Itpl.html If you want to play, just download http://www.lfw.org/python/Itpl15.py and try the itpl() function in the module. I would be quite pleased if (for example) $"" performed the equivalent of a function call to itpl() on the enclosed string. Apologetically (& only *gently* indignant), -- ?!ng From fredrik@pythonware.com Mon Jul 24 10:18:33 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Mon, 24 Jul 2000 11:18:33 +0200 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: Message-ID: <00cd01bff550$244f9f90$0900a8c0@SPIFF> tim wrote: > > obviously, things with fancy names and existing patches are on > > the top of that list :-( > > And, in most cases, not only fancy names and patches, but also years of > favorable preceding discussion. In particular, none of the things you > mentioned (list comprehensions, augumented assignments, range literals) is > in any sense new, or has escaped being debated to death multiple times. yeah, but what concerns me here is that we're talking about a release within 4-6 weeks, but we don't even have all the PEPs in place... ::: I cannot really comment on the list comprehension syntax since the PEP isn't there yet, but if I remember the syntax correctly, maybe "list confusions" is a better name than "list comprehensions". I surely don't understand them... "execute a piece of code and do something magic with the result of the last expression"? The lambda syntax is bad enough (it should really support an optional "return"), and I'd rather not see more of that... makes me think of nasty C bugs (and Perl, but that's another story). I'm somewhere between -1 and -0 on this one; I would very much prefer if we left that one out for 2.1, and considered adding real blocks instead. ::: The augumented assignment proposal is okay. I've never seen this as a real problem -- if I find myself writing: somethingverylong = somethingverylong + 1 there's probably a design flaw somewhere. But they're easy to read and grok -- even if you haven't used C or Java before, it's pretty clear from context what they're doing. I'm +0 on this one. ::: The range literal syntax is questionable; the proposal claims that the advantages are: "clarity of purpose" -- really? I'd say it's far from clear that slices really are the same thing as integer lists. They're also somewhat hard to read... "efficiency" -- sorry, but this a bogus argument. it's perfectly possible to do this optimization in the interpreter (a method caching interpreter could for example treat for/in/range as a method of the local namespace) "consistency" -- this is basically the first argument once again, claiming that it's "logical" that ranges and slices are the same thing. I'm not so sure... I'm -0 on this one. Changing it to require a "subject" for the slicing (e.g. int[0:10]) would make me +0. ::: I'm also beginning to like Barry's ">> file" proposal. It's like the augumented assignment syntax -- it's easy to understand what it's doing when you see it in context. (it really should be "print #file", of course ;-) ::: finally, based on the title along, I'm totally +1 on PEP-209. From nhodgson@bigpond.net.au Mon Jul 24 11:13:00 2000 From: nhodgson@bigpond.net.au (Neil Hodgson) Date: Mon, 24 Jul 2000 20:13:00 +1000 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: <00cd01bff550$244f9f90$0900a8c0@SPIFF> Message-ID: <039101bff557$bf947280$8119fea9@neil> > The augumented assignment proposal is okay. I've never seen this > as a real problem -- if I find myself writing: This is the third time I've seen this misspelling on the list. Is the collective Python subconscious trying to morph "augmented assignments" into "argumented assignments"? Neil From peter@schneider-kamp.de Mon Jul 24 13:40:31 2000 From: peter@schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 24 Jul 2000 12:40:31 +0000 Subject: [Python-Dev] Re: Variables in strings.. References: <81324605608.20000724121203@buz.ch> Message-ID: <397C393F.E4AFEBB4@schneider-kamp.de> Gabriel Ambuehl wrote: > > print "Hello $name" > would do the job. Now the only solution I could find in Python was > this awful > print "Hello %(name)s" % var() There is of course: print "Hello", name print "Hello", name[1] But that is probably not what you ask for. There is a thread about extending the print statement right now at the python-dev mailing list: http://www.python.org/pipermail/python-dev/2000-July/thread.html Part of this thread deals with what you are looking for. You may want to read the whole thread, but a good point to start is Tim's first post in that subthread: http://www.python.org/pipermail/python-dev/2000-July/013895.html > syntax which, after all, doesn't even seem to support lists as > print "Hello %(name[1])s" % var() > just raises a KeyError. May anyone point me to some more comfortable > ways than just endless concatenation of strings and lists which doesn't really > help for readibility (which is one of the main points why I'm > switching from Perl to Python)? As far as I have understood matters, the $name $(name[1]) syntax woul be able to do what you want. But then I have not really followed that thread closely. Peter P.S.: To python-dev: Wouldn't it be better to discuss this on python-list (or pep-dev)? -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mal@lemburg.com Mon Jul 24 11:53:27 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 12:53:27 +0200 Subject: [Python-Dev] string formatting (extended print statement, uPre-PEP) References: Message-ID: <397C2027.CE8D411B@lemburg.com> Ka-Ping Yee wrote: > > On Sun, 23 Jul 2000, Paul Prescod wrote: > > As happy as I am to have it called Prescod-ese, I admit to influence > > from some languages that (otherwise) suck. :) > > I agree that formatting and interpolation is one area where Perl is > much stronger, and it should be easy to do such things in Python. > > > credit-where-due 'ly yrs > > I kind of hate to do this, but i can't restrain myself from pointing > out that i *did* propose just this solution quite recently, in: > > http://www.python.org/pipermail/python-dev/2000-July/012764.html > > I wrote a module to do this a few years ago (1996, i think). It > supported attribute lookup, item lookup, and expressions. (No one > has yet mentioned the issue of escaping the dollar sign, which i > handled by doubling it.) > > See the exact rules described, with examples, at > > http://www.lfw.org/python/Itpl.html > > If you want to play, just download > > http://www.lfw.org/python/Itpl15.py > > and try the itpl() function in the module. > > I would be quite pleased if (for example) $"" performed the > equivalent of a function call to itpl() on the enclosed string. Any reason this can't be emulated using the existing "..." % mapping syntax ? You'd just have to provide a smart mapping which evaluates the %(something)s tags in the format string to a string ready for insertion... something may even contain balanced parenthesis, so even function calls are within range. Note that a = 1 b = 2 print "We have %(a)s apples and %(b)s oranges" % locals() is already possible today without any additional magic. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Mon Jul 24 11:57:40 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 24 Jul 2000 03:57:40 -0700 Subject: [Python-Dev] Re: Feature bloat in Python In-Reply-To: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jul 23, 2000 at 10:12:38AM +0200 References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> Message-ID: <20000724035739.J10898@lyra.org> On Sun, Jul 23, 2000 at 10:12:38AM +0200, Fredrik Lundh wrote: > mark wrote: > > If you can't quickly and quietly win this friendly audience over, IMO the > > proposal has failed. If any proposal causes even a small thread on this > > forum that boils down to "but its not clear to me what this should do", > > then I would have thought it self-evident that the proposal sucks. > > Convincing us that it _should_ be obvious if only we were all a little > > brighter and more willing to accept change for changes sake doesn't > > help anyone, least of all the person making these statements > > from the new Tcl Code Team rules: > > "A project can also be proposed by someone outside the Tcl Core > Team, but it can't be approved without an advocate on the Tcl > Core Team who will take personal responsibility for it. A project > must have support from at least 2 members of the Tcl Core Team > (including the proposer); if anyone in the Tcl Core Team objects > to the proposal, then there must be at least 4 members in favor > (including the proposer). If there are two or more "no" votes then > the proposal is rejected, regardless of the number of people in > favor. > > "The idea here is that the Tcl Core Team can only work effectively > if it is highly collegial; any project that generates significant contro- > versy should not go into the Tcl core." Compare/contrast to Apache: Big changes / non-bug fixes "require consensus approval before the change can be committed." "An action item requiring consensus approval must receive at least 3 binding +1 votes and no vetos." Apache requires at least one maintainer for any code in the distro (sounds like Tcl will also require one). Changes require (3) people to agree/approve them (Tcl appears to say 2, unless a veto arrives and makes it 4). Vetos are very harsh in Apache and can be made and held (forever) by a *single* person. Most vetos occur simply because a particular patch/commit has some repercussion that the author didn't see, or there is an obviously "better" (for your particular definition of "better") way to do the thing. But a veto is also quite permanent, binding, and respected. As a result, Apache does tend to be cooperative to avoid vetoes on designs, but they do happen. Something that Mark didn't seem to make clear (but I believe he intended): If we have problems understanding how something will work, then how can we possibly expect it will be understood by Python users who (almost by definition of their absence on this list) have less experience with Python than we do? or: If it isn't obvious to us, then it will be opaque to the majority of users. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido@beopen.com Mon Jul 24 13:51:02 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 07:51:02 -0500 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: Your message of "Sun, 23 Jul 2000 20:55:10 -0400." References: Message-ID: <200007241251.HAA14668@cj20424-a.reston1.va.home.com> All questions asked in this thread so far were answered correctly by Tim Peters. I'm only happy with the new license insofar as it represents a consensus between CNRI, the members of the Python Consortium and OSI that was very hard to reach. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas@xs4all.net Mon Jul 24 13:48:39 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 24 Jul 2000 14:48:39 +0200 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: ; from moshez@math.huji.ac.il on Mon, Jul 24, 2000 at 08:21:03AM +0300 References: Message-ID: <20000724144839.B266@xs4all.nl> On Mon, Jul 24, 2000 at 08:21:03AM +0300, Moshe Zadka wrote: > On Sun, 23 Jul 2000, Tim Peters wrote: > > At the O'Reilly conference, it was announced that the Perl rewrite in C++ > > (codenamed Topaz) has been abandoned. I didn't attend that session, but my > > impression from others is that they attempted to model Perl objects directly > > by C++ objects, and were frustrated by the consequent lack of low-level > > control. > As another data-point, I've heard from reliable sources that Topaz was > written to use bleeding edge C++, including all manners of weird > templates. > C++ I might be able to live with, but a very least common denominator C++ > -- otherwise you hurt the well-known Python portability, which is a major > strength. Tim himself stated that himself, in the very mail you half-quoted ;) C++ has some nice features, and it has a lot of (IMHO) not very nice features. Though I have to admit I'm not that up to speed in C++ features, I have seen C++ code do things that scared me shitless. They also have me wondering how efficient the generated code can be. Using C++ will hurt portability regardless, though. Not only because there are less C++ compilers than C compilers, but also because less people know C++ than C, and the *act* of porting gets harder. However, I do see some merit in making the current code compilable for a C++ compiler, and perhaps offering some extentions in the form of templates or such like Tim suggested. I haven't looked at that CXX thing, though, and I don't know if it (or direct extention code written C++) would benifit from a C++-compilable Python. In the mean time, it helps finding old prototype-less functions ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fredrik@pythonware.com Mon Jul 24 14:02:04 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Mon, 24 Jul 2000 15:02:04 +0200 Subject: [Python-Dev] Evolving Python (was Re: Feature bloat in Python ...) References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> Message-ID: <01c201bff56f$5daf0770$0900a8c0@SPIFF> barry wrote: > I'm beginning to think that our role on python-dev is different than > we thought. I think for a particular proposal for a new language > feature, or core language functionality, it is our job to explore the > details and ramifications as much as possible. if this is true, I really want a separate list for those of us who'd rather work on improving the implementation and the standard library. after all, adding more syntactic fl^H^Hstuff isn't the only way to improve Python... (and I'm pretty sure it's not the best way to improve it, either) From skip@mojam.com (Skip Montanaro) Mon Jul 24 14:50:22 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Mon, 24 Jul 2000 08:50:22 -0500 (CDT) Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <00cd01bff550$244f9f90$0900a8c0@SPIFF> References: <00cd01bff550$244f9f90$0900a8c0@SPIFF> Message-ID: <14716.18846.944097.966109@beluga.mojam.com> Fredrik> I cannot really comment on the list comprehension syntax since Fredrik> the PEP isn't there yet, but if I remember the syntax Fredrik> correctly, maybe "list confusions" is a better name than "list Fredrik> comprehensions". I surely don't understand them... Let me take a crack at explaining list comprehensions one more time. There is a patch available to play with, btw: https://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470 As current implemented (which is probably not precisely what people have been talking about), a list comprehension is simply a create a new list from one or more other lists to new using a series of constraint expressions. Working through some simple examples from the modified test_grammar.py: * multiplying a list by a constant... >>> nums = [1,2,3,4,5] >>> print [3*x for x in nums] [3, 6, 9, 12, 15] You can read this as, "for all values 3x such that x is in nums". * selecting a subset of a list... >>> print [x for x in nums if x > 2] [3, 4, 5] You can read this as, "for all values x such that x is in nums and x is greater than 2". * combining two lists... >>> strs = ["Apple", "Banana", "Coconut"] >>> print [i, s for i in nums for s in strs] [(1, 'Apple'), (1, 'Banana'), (1, 'Coconut'), (2, 'Apple'), (2, 'Banana'), (2, 'Coconut'), (3, 'Apple'), (3, 'Banana'), (3, 'Coconut'), (4, 'Apple'), (4, 'Banana'), (4, 'Coconut'), (5, 'Apple'), (5, 'Banana'), (5, 'Coconut')] You can read this as, "for all pairs (i,s) such that i is in nums and s is in strs". * nesting list comprehensions ... >>> print [i, s for i in nums for s in [f for f in strs if "n" in f]] [(1, 'Banana'), (1, 'Coconut'), (2, 'Banana'), (2, 'Coconut'), (3, 'Banana'), (3, 'Coconut'), (4, 'Banana'), (4, 'Coconut'), (5, 'Banana'), (5, 'Coconut')] You can read this as, "for all pairs (i,s) such that is is in nums as s is in the subset of nums that contains the letter 'n'". I don't think it's so different than the notation mathematicians use to describe and build sets. We don't have the luxury of convenient glyphs that mean "there exists" and "for all", however. As has been pointed out, the syntax is constrained by the demands of the current parser and preexisting expression syntax. For instance, we can't currently put "and" between the different clauses to clearly indicate that we are not nesting for statements without creating ambiguities. I don't know, perhaps that's simply an argument for stronger parsing technology for Python. If so, and a stronger parser would allow a more readable implementation of list comprehensions, I'd be in favor of delaying their introduction until such a parser was in place. I'm not the person to make the decisions about a new parser. Would (for example) a yacc/bison and lex/flex based parser be completely out of the question in the 2.1 to 2.2 timeframe? Would it allow a more expressive grammar? What portability issues would be involved? Skip From skip@mojam.com (Skip Montanaro) Mon Jul 24 15:09:45 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Mon, 24 Jul 2000 09:09:45 -0500 (CDT) Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <14716.18846.944097.966109@beluga.mojam.com> References: <00cd01bff550$244f9f90$0900a8c0@SPIFF> <14716.18846.944097.966109@beluga.mojam.com> Message-ID: <14716.20009.223815.39832@beluga.mojam.com> me> ... a list comprehension is simply a create a new list ... should be ... a list comprehension is simply a way to create a new list ... Also, in me> We don't have the luxury of convenient glyphs that mean "there me> exists" and "for all", however. I should have included "such that". It has, indeed, been a few years since I cracked a math book of any kind... ;-) Skip From jim@interet.com Mon Jul 24 15:20:16 2000 From: jim@interet.com (James C. Ahlstrom) Date: Mon, 24 Jul 2000 10:20:16 -0400 Subject: [Python-Dev] aargh References: <14715.54336.634634.776495@korak.digicool.com> Message-ID: <397C50A0.F63E7E8D@interet.com> Ken Manheimer wrote: > thinking that (1) i'm glad i'm not in guido's place, and (2) geeze, > aren't we making guido job harder, not easier? > I think people are sounding off too much, posing features and opinions > when they don't *need* to do so. People should think twice before > posing new python features - and hold off, a lot more of the time. > Treat every single thing you propose as if it costs something > significant - because it does! Way to go Ken!! I couldn't agree more!! No one can object to trying to improve Python. But there is insufficient fear and loathing of feature bloat and complexity. Members of this group are smart and can easily handle advanced features, but the same can not be said of c.l.p nor application programmers in general. Excess advanced features will hamper widespread acceptance of Python. JimA From akuchlin@mems-exchange.org Mon Jul 24 15:20:26 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon, 24 Jul 2000 10:20:26 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 22, 2000 at 01:41:03PM -0400 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> Message-ID: <20000724102026.A4196@kronos.cnri.reston.va.us> On Sat, Jul 22, 2000 at 01:41:03PM -0400, Tim Peters wrote: >since 1.5.2 was released to the public". The great recent burst of >Python-Dev activity in the CVS tree was not done at CNRI, or the bulk of it >even by people with any connection present or past to CNRI. The problem there is Unicode support, which has changed quite a bit since that time -- the default encoding, if nothing else. 1.6 will probably need to have Unicode disabled, or have support that's incompatible with 2.0, or someone will have to backport the current code to 1.6. (Better you guys than me, though...) --amk From akuchlin@mems-exchange.org Mon Jul 24 15:25:17 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon, 24 Jul 2000 10:25:17 -0400 Subject: [Python-Dev] Evolving Python In-Reply-To: <01c201bff56f$5daf0770$0900a8c0@SPIFF>; from fredrik@pythonware.com on Mon, Jul 24, 2000 at 03:02:04PM +0200 References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> <01c201bff56f$5daf0770$0900a8c0@SPIFF> Message-ID: <20000724102517.B4196@kronos.cnri.reston.va.us> On Mon, Jul 24, 2000 at 03:02:04PM +0200, Fredrik Lundh wrote: >if this is true, I really want a separate list for those of us who'd >rather work on improving the implementation and the standard >library. Seconded. There's lots of unsexy but useful stuff to be done simply making the core distribution a bit more solid or a bit faster, the demos a bit more up-to-date, the docs a bit more complete, &c. I think that part of my dislike of new language features stems from the redirection of effort away from such basic tasks. Can hardly wait until PEP-related discussion finds its new home, whether on c.l.p or on a pep-dev list. --amk From fdrake@beopen.com Mon Jul 24 15:33:54 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 24 Jul 2000 10:33:54 -0400 (EDT) Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724102026.A4196@kronos.cnri.reston.va.us> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> Message-ID: <14716.21458.361479.350602@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > The problem there is Unicode support, which has changed quite a bit And CNRI did handle the contracting for the Unicode support, so it's reasonable for it to be in there. But I wasn't at the consortium meeting, so don't know if any specific technical decisions were made there (I'd expect not). I was trapped on an airplane high above the earth, locked in battle with a recent version of LaTeX2HTML. ;( -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nowonder@pool.informatik.rwth-aachen.de Mon Jul 24 18:26:06 2000 From: nowonder@pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Mon, 24 Jul 2000 17:26:06 +0000 Subject: [Python-Dev] object allocator References: <200007211227.OAA04028@python.inrialpes.fr> Message-ID: <397C7C2E.44DCBA39@pool.informatik.rwth-aachen.de> Hei Vladimir! I have taken the liberty to submit your obmalloc.c as a patch on SourceForge. I have done this to make it easier for others to try it. It should build out of the box. > All this needs to be pursued, probably PEP'ed, but I think I can > already emit my opinion about a compromise: Let's wait with PEP'ing until there has been at least some discussion. > That said, it would be nice if you could test this code on your combos > and report some results and impressions back here. Right now I can only say that it runs fine on SuSE Linux 6.4. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From bwarsaw@beopen.com Mon Jul 24 16:30:47 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Mon, 24 Jul 2000 11:30:47 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> <14715.45967.555713.668818@anthem.concentric.net> <397BBAF3.683DE578@prescod.net> <14715.55278.925626.187181@anthem.concentric.net> <397BEEF2.AF9E1C74@prescod.net> Message-ID: <14716.24871.915663.693288@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> 1. "Why do I have to say the s in %()s when I'm using the s PP> formatting code 97.68% of the time?" I shouldn't need to. To PP> me, the s looks like a pluralization of listname and sender. A PP> template should have clear delimiters so that it is PP> straightforward to read. PP> 2. "Why do I have to tell it what namespace to evaluate in PP> when 93.5% of the time, it's vars()?" >>>>> "KY" == Ka-Ping Yee writes: KY> I kind of hate to do this, but i can't restrain myself from KY> pointing out that i *did* propose just this solution quite KY> recently, in: KY> http://www.python.org/pipermail/python-dev/2000-July/012764.html KY> I wrote a module to do this a few years ago (1996, i think). KY> It supported attribute lookup, item lookup, and expressions. KY> (No one has yet mentioned the issue of escaping the dollar KY> sign, which i handled by doubling it.) I think I've been lulled into conflating two different issues. As I see it doing the interpolation is separate from where the output goes, however it's clear that ?!ng's printpl() function could grow the optional keyword arguments that Moshe suggested. Still, I think it makes sense for them to be two separate proposals (with cross references if necessary). I've decided to PEP the extended print syntax and would be more than happy to assign a PEP number for a string interpolation proposal, if someone else volunteers to champion it. -Barry From mal@lemburg.com Mon Jul 24 16:28:36 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 17:28:36 +0200 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> Message-ID: <397C60A4.A4A9513C@lemburg.com> Andrew Kuchling wrote: > > On Sat, Jul 22, 2000 at 01:41:03PM -0400, Tim Peters wrote: > >since 1.5.2 was released to the public". The great recent burst of > >Python-Dev activity in the CVS tree was not done at CNRI, or the bulk of it > >even by people with any connection present or past to CNRI. > > The problem there is Unicode support, which has changed quite a bit > since that time -- the default encoding, if nothing else. 1.6 will > probably need to have Unicode disabled, or have support that's > incompatible with 2.0, or someone will have to backport the current > code to 1.6. (Better you guys than me, though...) Hmm, why shouldn't it be possible to use the current version of Unicode support in 1.6 ? AFAIK, most of the patching was done by Fredrik and myself and we were not related to CNRI or BeOpen in any way at the time of the move to BeOpen. Wouldn't it suffice for Fredrik and me to send in a wet-sign for the Unicode patches since that date ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Mon Jul 24 16:39:53 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 17:39:53 +0200 Subject: [Python-Dev] Python CVS License ? Message-ID: <397C6349.7B441A80@lemburg.com> I was wondering what the license terms are for the current CVS snapshot... There's a lot of code in there which carries its own license or copyright, e.g. the Unicode stuff still only has the note "(c) Copyright CNRI, All Rights Reserved. NO WARRANTY." and the SRE modules are "Copyright (c) 1997-2000 by Secret Labs AB. All rights reserved.". As it stands, I guess the current CVS tree is not legally copyable or usable by anyone who wants decent Unicode support. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul@prescod.net Mon Jul 24 21:13:10 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 15:13:10 -0500 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: <00cd01bff550$244f9f90$0900a8c0@SPIFF> Message-ID: <397CA356.4CF1F82B@prescod.net> Fredrik Lundh wrote: > >... > > yeah, but what concerns me here is that we're talking about a > release within 4-6 weeks, but we don't even have all the PEPs > in place... I do not believe it is a goal to implement all PEP-ed features in Python 2.0. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul@prescod.net Mon Jul 24 17:17:47 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 11:17:47 -0500 Subject: [Python-Dev] Sorry Message-ID: <397C6C2B.ED72DF2F@prescod.net> I hate to bring up the zip name thing again but I'm strongly leaning toward something of the form: mktuples maketuples totuples gentuples tupleorama -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From Jasbahr@origin.EA.com Mon Jul 24 18:07:58 2000 From: Jasbahr@origin.EA.com (Asbahr, Jason) Date: Mon, 24 Jul 2000 12:07:58 -0500 Subject: [Python-Dev] Python Consortium Meeting News Message-ID: <11A17AA2B9EAD111BCEA00A0C9B4179305CB54FC@molach.origin.ea.com> Depending on the release schedule for 2.0, we may have to ship our product with Python 1.6, and Unicode is one of the key features we need from this release. I hope Marc is right that the current version of the Unicode support can be incorporated into the 1.6 official release. Cheers, Jason Asbahr Origin Systems, Inc. jasbahr@origin.ea.com -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Monday, July 24, 2000 10:29 AM To: akuchlin@mems-exchange.org Cc: python-dev@python.org Subject: Re: [Python-Dev] Python Consortium Meeting News Andrew Kuchling wrote: > > On Sat, Jul 22, 2000 at 01:41:03PM -0400, Tim Peters wrote: > >since 1.5.2 was released to the public". The great recent burst of > >Python-Dev activity in the CVS tree was not done at CNRI, or the bulk of it > >even by people with any connection present or past to CNRI. > > The problem there is Unicode support, which has changed quite a bit > since that time -- the default encoding, if nothing else. 1.6 will > probably need to have Unicode disabled, or have support that's > incompatible with 2.0, or someone will have to backport the current > code to 1.6. (Better you guys than me, though...) Hmm, why shouldn't it be possible to use the current version of Unicode support in 1.6 ? AFAIK, most of the patching was done by Fredrik and myself and we were not related to CNRI or BeOpen in any way at the time of the move to BeOpen. Wouldn't it suffice for Fredrik and me to send in a wet-sign for the Unicode patches since that date ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://www.python.org/mailman/listinfo/python-dev From guido@beopen.com Mon Jul 24 17:45:30 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 11:45:30 -0500 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: Your message of "Mon, 24 Jul 2000 17:28:36 +0200." <397C60A4.A4A9513C@lemburg.com> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> Message-ID: <200007241645.LAA15974@cj20424-a.reston1.va.home.com> > Hmm, why shouldn't it be possible to use the current > version of Unicode support in 1.6 ? AFAIK, most of the patching > was done by Fredrik and myself and we were not related to > CNRI or BeOpen in any way at the time of the move to BeOpen. I would expect that untangling the patches from the ANSIfication would be too much work. I'm not too interested in doing that. > Wouldn't it suffice for Fredrik and me to send in a wet-sign > for the Unicode patches since that date ? I suppose so (but I can't speak for CNRI any more). One possibility, if there are people interested in helping out with 1.6, would be to create a branch on SF. But since this needs to be a branch relative to an old version, I'm not sure exactly how to do that. (The problem with checking out by date is that CVS gives you all the *deleted* files back, even if they were deleted at the selected date. Sigh.) Regarding incompatibilities between 1.6 and 2.0: we can simply mark the Unicode support in 1.6 as experimental, and announce that relying on the default conversion beyond ASCII in 1.6 causes forward compatibility problems. I plan to release 2.0 pretty soon after 2.0! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Mon Jul 24 17:47:34 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 11:47:34 -0500 Subject: [Python-Dev] Python CVS License ? In-Reply-To: Your message of "Mon, 24 Jul 2000 17:39:53 +0200." <397C6349.7B441A80@lemburg.com> References: <397C6349.7B441A80@lemburg.com> Message-ID: <200007241647.LAA15998@cj20424-a.reston1.va.home.com> > I was wondering what the license terms are for the current > CVS snapshot... > > There's a lot of code in there which carries > its own license or copyright, e.g. the Unicode stuff still > only has the note "(c) Copyright CNRI, All Rights Reserved. > NO WARRANTY." and the SRE modules are "Copyright (c) 1997-2000 by > Secret Labs AB. All rights reserved.". > > As it stands, I guess the current CVS tree is not legally > copyable or usable by anyone who wants decent Unicode support. And that's probably a good thing. It's a development tree -- please don't make releases of it! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul@prescod.net Mon Jul 24 17:09:58 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 11:09:58 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: Message-ID: <397C6A56.389B56CC@prescod.net> Ka-Ping Yee wrote: > > On Sun, 23 Jul 2000, Paul Prescod wrote: > > As happy as I am to have it called Prescod-ese, I admit to influence > > from some languages that (otherwise) suck. :) > > I agree that formatting and interpolation is one area where Perl is > much stronger, and it should be easy to do such things in Python. > > > credit-where-due 'ly yrs > > I kind of hate to do this, but i can't restrain myself from pointing > out that i *did* propose just this solution quite recently, in: > > http://www.python.org/pipermail/python-dev/2000-July/012764.html Sorry, for whatever reason I didn't actually read that message. It's sitting in the middle of a bunch of other messages I have marked as unread. You're right, you definately get credit for the idea and I'll let you take the flames when we introduce it to comp.lang.python. :) Why don't you PEP it? -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From thomas@xs4all.net Mon Jul 24 17:10:49 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 24 Jul 2000 18:10:49 +0200 Subject: [Python-Dev] ANSIfication. In-Reply-To: <397AE4F4.E1A9DDE0@lemburg.com>; from mal@lemburg.com on Sun, Jul 23, 2000 at 02:28:36PM +0200 References: <20000723022452.Q9897@xs4all.nl> <397AE4F4.E1A9DDE0@lemburg.com> Message-ID: <20000724181049.C266@xs4all.nl> On Sun, Jul 23, 2000 at 02:28:36PM +0200, M.-A. Lemburg wrote: [ Me complaining about externs everywhere ] > I'd suggest doing this in two steps: > 1. move the externs to pyport.h (which is the right place for > these platform dependent defines and includes) and > add #if 0 ... #endif around them > 2. check whether these are still needed during the beta phase and > if no one complains remove the cruft completely > Alternatively, you could also add specific platform dependent > #ifdefs to pyport.h which only enable the externs on those > platforms where they are needed. I did a bit of both. Those that already had a proper platform #ifdef or comment, I left in. The others are moved into a #if 0 block. If noone objects to the current setup, I'll start moving around the rest, too. If anyone has access to BeOS, Solaris and/or SGI, please try to see if the decls are really necessary, still :P Those are the 'unchecked' ones I included. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein@lyra.org Mon Jul 24 20:30:54 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 24 Jul 2000 12:30:54 -0700 Subject: [Python-Dev] [jon@latchkey.com: [ANNOUNCE] Jakarta-ORO Project] Message-ID: <20000724123054.W10898@lyra.org> The Java ORO stuff is now under the Apache Software Foundation license. I'm posting here because the licensing of the ORO stuff came up at the Consortium meeting the other day re: its inclusion in JPython. Information is available at The Apache Jakarta project also has a lighter weight regexp engine under the ASF license (depending on how much "stuff" is needed). Info at Please forward to the JPython lists as appropriate. Cheers, -g ----- Forwarded message from Jon Stevens ----- Reply-To: members@apache.org Date: Mon, 24 Jul 2000 12:07:05 -0700 Subject: [ANNOUNCE] Jakarta-ORO Project From: Jon Stevens To: just keeping you all in the loop. push yet another project onto the stack. :-) -jon ---------- From: Jon Stevens Reply-To: general@jakarta.apache.org Date: Mon, 24 Jul 2000 11:49:36 -0700 To: Cc: "Daniel F. Savarese" Subject: [ANNOUNCE] Jakarta-ORO Project Hey All, Thanks to a generous code donation by Daniel F. Savarese, we now have a full featured regex package for Java under a BSD/Apache license. "The Jakarta-ORO Java classes are a set of text-processing Java classes that provide Perl5 compatible regular expressions, AWK-like regular expressions, glob expressions, and utility classes for performing substitutions, splits, filtering filenames, etc. This library is the successor to the OROMatcher, AwkTools, PerlTools, and TextTools libraries from ORO, Inc. (www.oroinc.com). They have been donated to the Jakarta Project by Daniel Savarese (www.savarese.org), the copyright holder of the ORO libraries. Daniel will continue to participate in their development under the Jakarta Project." Come and get it: -jon ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/ From ping@lfw.org Mon Jul 24 19:48:04 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Mon, 24 Jul 2000 11:48:04 -0700 (PDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14716.24871.915663.693288@anthem.concentric.net> Message-ID: On Mon, 24 Jul 2000, Barry A. Warsaw wrote: > Still, I think it makes sense for them to be two separate proposals > (with cross references if necessary). I've decided to PEP the > extended print syntax and would be more than happy to assign a PEP > number for a string interpolation proposal, if someone else volunteers > to champion it. Okay, i'll do it. -- ?!ng From barry@scottb.demon.co.uk Mon Jul 24 21:38:15 2000 From: barry@scottb.demon.co.uk (Barry Scott) Date: Mon, 24 Jul 2000 21:38:15 +0100 Subject: [Python-Dev] if/else and macros In-Reply-To: <20000717023950.E29590@lyra.org> Message-ID: <000001bff5af$17dffb60$060210ac@private> > > > ! #define UTF8_ERROR(details) \ > > > ! if (1) { \ > > > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > > > ! goto onError; \ > > > ! continue; \ > > > ! } else Try defining the macro this way: #define UTF8_ERROR(details) \ do { \ if (utf8_decoding_error(&s, &p, errors, (details))) \ goto onError; \ continue; \ } while(0) BArry From guido@beopen.com Mon Jul 24 21:00:39 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 15:00:39 -0500 Subject: [Python-Dev] "Michael Bryan Becraft": Brainbench Test in Python Message-ID: <200007242000.PAA17136@cj20424-a.reston1.va.home.com> Anyone interested? Please write directly to him. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------- Forwarded Message Date: Fri, 14 Jul 2000 13:31:23 -0400 From: "Michael Bryan Becraft" To: Subject: Brainbench Test in Python Dear sir, I am developing a test in Python 1.5 for assessing the skills of Python programmers, and wonder if anyone within your organisation would be interested in reviewing the test questions for us. I need at least one more reviewer, a task which generally takes 4-6 hours. The pay for the task would be $200 total (I realise that is not much), but would appreciate the input if there are any interested colleagues. If anyone is interested in what we do with online certifications, they can register to take free tests at our site. Thanks for your time, Mike Becraft Michael Bryan Becraft Assessment Development Manager - Brainbench Telephone: (703) 437-7849 Facsimile: (703) 437-7801 http://www.brainbench.com mailto:michael.becraft@brainbench.com ------- End of Forwarded Message From jeremy@beopen.com Mon Jul 24 21:55:26 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 24 Jul 2000 16:55:26 -0400 (EDT) Subject: [Python-Dev] Sorry In-Reply-To: <397C6C2B.ED72DF2F@prescod.net> References: <397C6C2B.ED72DF2F@prescod.net> Message-ID: <14716.44350.785087.111127@bitdiddle.concentric.net> Let's not discuss names on python-dev! Barry is writing the PEP on the subject. If you've got name ideas, send them to him. He can post of a summary of name discussions if it becomes an issue. Jeremy From bwarsaw@beopen.com Mon Jul 24 22:08:15 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Mon, 24 Jul 2000 17:08:15 -0400 (EDT) Subject: [Python-Dev] [jon@latchkey.com: [ANNOUNCE] Jakarta-ORO Project] References: <20000724123054.W10898@lyra.org> Message-ID: <14716.45119.543707.536193@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> The Java ORO stuff is now under the Apache Software Foundation GS> license. I'm posting here because the licensing of the ORO GS> stuff came up at the Consortium meeting the other day re: its GS> inclusion in JPython. Information is available at GS> Excellent. I knew this was going to happen and had been watching the Jakarta pages for it's public announcement. Thanks for posting about it. This and the release of JPython under the same license as CPython will mean an OSD compliant version of JPython without the silly dual licenses. I'm hoping this can all happen soon so we can move JPython development to SourceForge and start working on it again. GS> Please forward to the JPython lists as appropriate. | Cheers, Done, thanks. -Barry From Fredrik Lundh" not sure about the outcome here; should I go ahead and check it in? (properly ANSIfied, of course): http://sourceforge.net/patch/?func=3Ddetailpatch&patch_id=3D100895&group_= id=3D5470 From esr@thyrsus.com Mon Jul 24 22:40:19 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 17:40:19 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <200007241645.LAA15974@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 24, 2000 at 11:45:30AM -0500 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> Message-ID: <20000724174019.E31538@thyrsus.com> Guido van Rossum : > I plan to release 2.0 pretty soon after 2.0! Hm. I take it, then, that your time machine is back from the shop? -- Eric S. Raymond Sometimes the law defends plunder and participates in it. Sometimes the law places the whole apparatus of judges, police, prisons and gendarmes at the service of the plunderers, and treats the victim -- when he defends himself -- as a criminal. -- Frederic Bastiat, "The Law" From guido@beopen.com Mon Jul 24 23:35:53 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 17:35:53 -0500 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: Your message of "Mon, 24 Jul 2000 17:40:19 -0400." <20000724174019.E31538@thyrsus.com> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> Message-ID: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> > Guido van Rossum : > > I plan to release 2.0 pretty soon after 2.0! ESR > Hm. I take it, then, that your time machine is back from the shop? Argh. You know that I meant "after 1.6". Here's my current timeline (I'll post this on the web when we have access): - 1.6beta1 out around August 1 - 1.6final around August 15 - 2.0beta1 around August 30 - various betas - 2.0final around September 30 Obviously not every PEP will be included in 2.0. I plan on including these: zip(); list comprehensions; augmented assignments; range literals. Also whatever's in pep-0200. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal@lemburg.com Mon Jul 24 22:36:19 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 23:36:19 +0200 Subject: [Python-Dev] [ Patch #100895 ] safe version of PyErr_Format References: <014501bff5b5$b4965520$f2a6b5d4@hagrid> Message-ID: <397CB6D3.207B3599@lemburg.com> Fredrik Lundh wrote: > > not sure about the outcome here; should I go ahead > and check it in? (properly ANSIfied, of course): > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 +0 I would still like to see the snprintf() fallback solution somewhere in there, but what the heck... go ahead ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@beopen.com Mon Jul 24 23:47:52 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 17:47:52 -0500 Subject: [Python-Dev] [ Patch #100895 ] safe version of PyErr_Format In-Reply-To: Your message of "Mon, 24 Jul 2000 23:25:30 +0200." <014501bff5b5$b4965520$f2a6b5d4@hagrid> References: <014501bff5b5$b4965520$f2a6b5d4@hagrid> Message-ID: <200007242247.RAA17840@cj20424-a.reston1.va.home.com> > not sure about the outcome here; should I go ahead > and check it in? (properly ANSIfied, of course): > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 I'm for it, but don't know of all the consequences. It would be helpful to create a test suite that triggered all the calls to PyErr_Format() that exist in the core. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal@lemburg.com Mon Jul 24 22:54:38 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 23:54:38 +0200 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> Message-ID: <397CBB1E.D5AE9DF1@lemburg.com> Guido van Rossum wrote: > > Here's my current timeline > (I'll post this on the web when we have access): > > - 1.6beta1 out around August 1 > - 1.6final around August 15 > - 2.0beta1 around August 30 > - various betas > - 2.0final around September 30 > > Obviously not every PEP will be included in 2.0. I plan on including > these: zip(); list comprehensions; augmented assignments; range > literals. Also whatever's in pep-0200. How about adding XML support as the "Big New Feature" to 2.0 instead of 1.6 (if I remember correctly, XML was added after the BeOpen move, right) ? Not that I have anything against XML going into 1.6, but this would make the new version number a little more understandable. BTW, how rock solid is Python's builtin XML support ? I'm asking because I want to make our product XML aware and the various different parser implementations out there gave me a rather unsecure feeling about which one to go after... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Mon Jul 24 23:04:33 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 00:04:33 +0200 Subject: [Python-Dev] if/else and macros In-Reply-To: <000001bff5af$17dffb60$060210ac@private>; from barry@scottb.demon.co.uk on Mon, Jul 24, 2000 at 09:38:15PM +0100 References: <20000717023950.E29590@lyra.org> <000001bff5af$17dffb60$060210ac@private> Message-ID: <20000725000433.D266@xs4all.nl> On Mon, Jul 24, 2000 at 09:38:15PM +0100, Barry Scott wrote: > > > > ! #define UTF8_ERROR(details) \ > > > > ! if (1) { \ > > > > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > > > > ! goto onError; \ > > > > ! continue; \ > > > > ! } else > > Try defining the macro this way: > #define UTF8_ERROR(details) \ > do { \ > if (utf8_decoding_error(&s, &p, errors, (details))) \ > goto onError; \ > continue; \ > } while(0) That isn't going to work, and is the entire reason for the 'if' construction rather than the 'do {} while' one: the 'continue' applies to the innermost loop, the 'do {} while(0)', producing some decidedly unpredicted behaviour. Anyhow, I believe it's fixed more adequately now, or someone is going to ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy@beopen.com Mon Jul 24 23:20:18 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 24 Jul 2000 18:20:18 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python Message-ID: <14716.49442.232191.940532@bitdiddle.concentric.net> I'm starting to work on PEP 200, the release schedule for 2.0. As part of that document, I'd like to write down some rules for contributing code to that release. I've come up with some guidelines based on the discussion we've had on python-dev since moving to SourceForge as well as some offline discussions at PythonLabs. I've included them below for comment and review. Once we have reached some agreement on what the rules should be, I'll add them to PEP 200 and check them in. Jeremy Use good sense when committing changes. You should know what we mean by good sense or we wouldn't have given you commit privileges <0.5 wink>. Some specific examples of good sense include: - Do whatever the dictator tells you. - Discuss any controversial changes on python-dev first. If you get a lot of +1 votes and no -1 votes, make the change. If you get a some -1 votes, think twice; consider asking Guido what he thinks. - If the change is to code you contributed, it probably makes sense for you to fix it. - If the change affects code someone else wrote, it probably makes sense to ask him or her first. - You can use the SF Patch Manager to submit a patch and assign it to someone for review. Any significant new feature must be described in a PEP and approved before it is checked in. Any significant code addition, such as a new module or large patch, MUST include test cases for the regression test and documentation. A patch should not be checked in until the tests and documentation are ready. If you fix a bug, you SHOULD write a test case that would have caught the bug. If you commit a patch from the SF Patch Manager or fix a bug from the Jitterbug database, be sure to reference the patch/bug number in the CVS log message. Also be sure to change the status in the patch manager or bug database. It is not acceptable for any checked in code to cause the regression test to fail. If a checkin causes a failure, it MUST be fixed within 24 hours or it will be backed out. All contributed C code MUST be ANSI C. If possible check it with two different compilers, e.g. gcc and MSVC. All contributed Python code MUST follow Guido's Python style guide. http://www.python.org/doc/essays/styleguide.html It is understood that any code contributed will be released under an Open Source license. Do not contribute code if it can't be released this way. From m.favas@per.dem.csiro.au Mon Jul 24 23:21:34 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Tue, 25 Jul 2000 06:21:34 +0800 Subject: [Python-Dev] Status of re...??? Message-ID: <397CC16E.89E1446B@per.dem.csiro.au> test_re has been failing (and not just failing, but failing incorrectly ) for some time now (test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou"). What's the future for re - is it planned to remove it from 2.0? -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From jeremy@beopen.com Mon Jul 24 23:30:44 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 24 Jul 2000 18:30:44 -0400 (EDT) Subject: [Python-Dev] Status of re...??? In-Reply-To: <397CC16E.89E1446B@per.dem.csiro.au> References: <397CC16E.89E1446B@per.dem.csiro.au> Message-ID: <14716.50068.826877.488769@bitdiddle.concentric.net> Good question! I'm at a complete loss about what's going on with the re module. There is no point in having a test that is supposed to fail, because it's impossible to tell the difference between an expected failure and an unexpected failure. I just proposed some guidelines for contributing code, which probably cross your message in transit, that included a guideline that no checked in code should cause the regression test to fail. If the problem is known SRE bugs, I think the re test should be temporarily changed to eliminate the known bugs. If SRE is later fixed, the test cases can be restored. What is the current schedule for fixing SRE? I need to know for the release schedule. Jeremy From m.favas@per.dem.csiro.au Mon Jul 24 23:36:05 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Tue, 25 Jul 2000 06:36:05 +0800 Subject: [Python-Dev] Failing regression tests... Message-ID: <397CC4D5.D6EC87E@per.dem.csiro.au> [Jeremy Hylton just wrote:] I just proposed some guidelines for contributing code, which probably cross your message in transit, that included a guideline that no checked in code should cause the regression test to fail. I know 64-bit platforms aren't mainstream (yet), but test_ucn has also been failing (test test_ucn crashed -- exceptions.UnicodeError : Unicode-Escape decoding error: Invalid Unicode Character Name) for quite a while now on these beasts. Bill Tutt proposed a patch, which Tim critiqued, while at the same time /F was producing another way of doing it , and... -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From esr@thyrsus.com Tue Jul 25 00:09:35 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 19:09:35 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <200007242235.RAA17731@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 24, 2000 at 05:35:53PM -0500 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> Message-ID: <20000724190935.G31538@thyrsus.com> Guido van Rossum : > > Guido van Rossum : > > > I plan to release 2.0 pretty soon after 2.0! > > ESR > > Hm. I take it, then, that your time machine is back from the shop? > > Argh. You know that I meant "after 1.6". Yes. But the joke was not resistible. > Here's my current timeline > (I'll post this on the web when we have access): > > - 1.6beta1 out around August 1 > - 1.6final around August 15 > - 2.0beta1 around August 30 > - various betas > - 2.0final around September 30 A timetable. Excellent. Now I know when I have to get my stuff done (curses docs, enhanced Berkeley DB support). > Obviously not every PEP will be included in 2.0. I plan on including > these: zip(); list comprehensions; augmented assignments; range > literals. Also whatever's in pep-0200. All this makes me happy, except that I'm a touch dubious about list comprehensions now. Still like the idea, still think the syntax ought to be clearer somehow. -- Eric S. Raymond "As to the species of exercise, I advise the gun. While this gives [only] moderate exercise to the body, it gives boldness, enterprise, and independence to the mind. Games played with the ball and others of that nature, are too violent for the body and stamp no character on the mind. Let your gun, therefore, be the constant companion to your walks." -- Thomas Jefferson, writing to his teenaged nephew. From mal@lemburg.com Tue Jul 25 00:05:20 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 25 Jul 2000 01:05:20 +0200 Subject: [Python-Dev] Failing regression tests... References: <397CC4D5.D6EC87E@per.dem.csiro.au> Message-ID: <397CCBB0.A8D7F6DC@lemburg.com> Mark Favas wrote: > > [Jeremy Hylton just wrote:] > I just proposed some guidelines for contributing code, which probably > cross your message in transit, that included a guideline that no > checked in code should cause the regression test to fail. > > I know 64-bit platforms aren't mainstream (yet), but test_ucn has also > been failing (test test_ucn crashed -- exceptions.UnicodeError : > Unicode-Escape decoding error: Invalid Unicode Character Name) for quite > a while now on these beasts. Bill Tutt proposed a patch, which Tim > critiqued, while at the same time /F was producing another way of doing > it , and... The patch is there on SF... but AFAIK, Fredrik has not yet finished work on it. I would rather like to see /Fs new module in the distribution because of its reduced size. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip@mojam.com (Skip Montanaro) Tue Jul 25 00:05:39 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Mon, 24 Jul 2000 18:05:39 -0500 (CDT) Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724190935.G31538@thyrsus.com> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> Message-ID: <14716.52163.222710.772833@beluga.mojam.com> Eric> A timetable. Excellent. Now I know when I have to get my stuff Eric> done (curses docs, enhanced Berkeley DB support). Eric, you are aware that there is a libdb 2.0 module floating around already, right? >> Obviously not every PEP will be included in 2.0. I plan on including >> these: zip(); list comprehensions; augmented assignments; range >> literals. Also whatever's in pep-0200. Skip From jeremy@beopen.com Tue Jul 25 00:57:10 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 24 Jul 2000 19:57:10 -0400 (EDT) Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> Message-ID: <14716.55254.609098.924791@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> Obviously not every PEP will be included in 2.0. I plan on GvR> including these: zip(); list comprehensions; augmented GvR> assignments; range literals. Also whatever's in pep-0200. Given the release schedule you mentioned, we need to start making progress on the PEPs. I suggest we aim for completed design documents for these features by Aug. 9; that leaves three weeks between completion of design document and first beta release. Jeremy From esr@thyrsus.com Tue Jul 25 01:07:17 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 20:07:17 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <14716.52163.222710.772833@beluga.mojam.com>; from skip@mojam.com on Mon, Jul 24, 2000 at 06:05:39PM -0500 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> Message-ID: <20000724200717.A32163@thyrsus.com> Skip Montanaro : > > Eric> A timetable. Excellent. Now I know when I have to get my stuff > Eric> done (curses docs, enhanced Berkeley DB support). > > Eric, you are aware that there is a libdb 2.0 module floating around > already, right? I'm in touch with the authors, Robin Dunn and Greg Smith. Robin wrote the 2.0 module; Greg updated it for the latest version of libdn, 3.1.55. They both recommend using Greg's version. We've discussed the following plan: 1. Import Greg's 3.x module into the Python core. 2. Adapt Robin's dbShelve stuff to work with Greg's code. (My high-level goal in all this is to give shelves many-readers/one-writer locking so they can be used as session databases by Python CGI scripts). 3. Document it all. Both Greg and Robin are enthusiastic about having this code in the core and are willing to put it under the distribution's license. Yes, there is a test suite. The only problem with this plan is that I don't understand the Python distribution's module build system and step 1 looks kind of hairy. Is this stuff documented anywhere? -- Eric S. Raymond The price of liberty is, always has been, and always will be blood. The person who is not willing to die for his liberty has already lost it to the first scoundrel who is willing to risk dying to violate that person's liberty. Are you free? -- Andrew Ford From akuchlin@mems-exchange.org Tue Jul 25 01:17:21 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon, 24 Jul 2000 20:17:21 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724200717.A32163@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 24, 2000 at 08:07:17PM -0400 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> Message-ID: <20000724201721.A9990@newcnri.cnri.reston.va.us> On Mon, Jul 24, 2000 at 08:07:17PM -0400, Eric S. Raymond wrote: >1. Import Greg's 3.x module into the Python core. ... >The only problem with this plan is that I don't understand the Python >distribution's module build system and step 1 looks kind of hairy. Is >this stuff documented anywhere? Try reading the comments at the top of Modules/Setup.in. For a very simple module that's only a file or two, like posixmodule.c or the md5 module, you can simply add an appropriate line to Setup.in. But I vaguely recall that the 3.x bsddb module is a bunch of files -- if that's the case, I'm not sure what to do. For PCRE, I wrote a script which munges several source files into one big pypcre.c, but this is messy and probably was a mistake. I'm not sure what's involved in extending the system to support building in subdirectories of Modules/. (Maybe a line like "pcre pcre/pcre.c pcre/compile.c pcre/study.c ..." in Setup.in would just magically work?) --amk From nowonder@pool.informatik.rwth-aachen.de Tue Jul 25 08:02:51 2000 From: nowonder@pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Tue, 25 Jul 2000 07:02:51 +0000 Subject: [Python-Dev] guidelines for contributing to Python References: <14716.49442.232191.940532@bitdiddle.concentric.net> Message-ID: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Jeremy Hylton wrote: > > If you fix a bug, you SHOULD write a test case that would have caught > the bug. Two questions: - Where should a test for a bug in Python/compile.c go? - Do we really need to carry around a test for (almost) every bug? > If you commit a patch from the SF Patch Manager or fix a bug from the > Jitterbug database, be sure to reference the patch/bug number in the > CVS log message. Also be sure to change the status in the patch > manager or bug database. "Be sure to have access to the bug database." I don't think I have. BTW: Is there some reason why we don't switch to the SF bug stuff? [Disclaimer: I have no experience with that part of SF, I am just plain curious] Peter P.S.: I don't like this SHOUTING should, must etc. -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From fdrake@beopen.com Tue Jul 25 06:15:35 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 01:15:35 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: <14717.8823.421584.948836@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > P.S.: I don't like this SHOUTING should, must etc. I don't either, but I think I know where it came from. There's an IETF RFC that carefully defines these terms as they relate to standards compliance, and IETF documents use them this way (capitalized). I think we should follow the W3C lead on this one: they adopt the IETF RFC but state that the terms are not specially cased; they are shown as normal English words. (I think the RFC doesn't actually require the capitalization, but I'm not certain offhand.) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Tue Jul 25 06:19:44 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 01:19:44 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: <14717.9072.475757.832530@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > Two questions: > - Where should a test for a bug in Python/compile.c go? > - Do we really need to carry around a test for (almost) every bug? I'd rather carry around the test cases than lose them. These are important for regression tests where a large part of the point is that the implementation doesn't regress and allow an old bug (or it's symptoms) to resurface without being detected. > "Be sure to have access to the bug database." I don't think I have. This sort of thing is a serious problem. > BTW: Is there some reason why we don't switch to the SF bug stuff? > [Disclaimer: I have no experience with that part of SF, I am > just plain curious] I think the SourceForge developers may be looking into importing a Jitterbug database; once that's possible we should definately move that service over. Jitterbug *really* sucks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From dan@cgsoftware.com Tue Jul 25 06:26:13 2000 From: dan@cgsoftware.com (Daniel Berlin) Date: Mon, 24 Jul 2000 22:26:13 -0700 (PDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: On Tue, 25 Jul 2000, Peter Schneider-Kamp wrote: > Jeremy Hylton wrote: > > > > If you fix a bug, you SHOULD write a test case that would have caught > > the bug. > > Two questions: > - Where should a test for a bug in Python/compile.c go? > - Do we really need to carry around a test for (almost) every bug? Yes. It's the only way to make sure it doesn't happen again. GCC has about 6000 regression tests currently, fer instance. Each came about as part of a bug reported (usually what happens is someone takes the preprocessed source sent in with the bug report, and distills it down to about 100-1024 bytes worth of code that demonstrate the bug.). --Dan From bwarsaw@beopen.com Tue Jul 25 06:35:46 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 01:35:46 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python References: <14716.49442.232191.940532@bitdiddle.concentric.net> Message-ID: <14717.10034.65655.779012@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> All contributed Python code MUST follow Guido's Python style JH> guide. http://www.python.org/doc/essays/styleguide.html I'd like to create two new PEPs, one which would be a Python coding style guide, based on Guido's seminal essay, but updated, and a C coding style guide for modules and core C code. I'd probably eventually like to add one for Java code in the JPython core as well. Any objections to PEPing these, even though it may be a little while before they're fleshed out? Anybody else care to champion them? If not, I will do it. -Barry From bwarsaw@beopen.com Tue Jul 25 06:38:26 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 01:38:26 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python References: <14716.49442.232191.940532@bitdiddle.concentric.net> <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.9072.475757.832530@cj42289-a.reston1.va.home.com> Message-ID: <14717.10194.305692.8974@anthem.concentric.net> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> I think the SourceForge developers may be looking into Fred> importing a Jitterbug database; once that's possible we Fred> should definately move that service over. Jitterbug Fred> *really* sucks! I've been using the SF bug tracker for Mailman and it definitely sucks less than Jitterbug. Not perfect, but very usable. One thing I'd like to see (and I've made a request for this), is the ability to link bugs and patches. Very often a Mailman user will post a bug report and a dever will post a patch to fix the bug. It'd be nice if there could be a direct crosslink between the two. And if SF can import a Jitterbug database, that'd be a huge win! -Barry From bwarsaw@beopen.com Tue Jul 25 06:40:32 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 01:40:32 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: <14717.10320.356127.243997@anthem.concentric.net> >>>>> "DB" == Daniel Berlin writes: DB> Yes. It's the only way to make sure it doesn't happen again. DB> GCC has about 6000 regression tests currently, fer instance. DB> Each came about as part of a bug reported (usually what DB> happens is someone takes the preprocessed source sent in with DB> the bug report, and distills it down to about 100-1024 bytes DB> worth of code that demonstrate the bug.). Absolutely agreed. I can't even count the number of times that my regression test suite saved much embarrassment with CC Mode. Python is a big complex system with many interacting pieces. A butterfly change here can cause a hurricane breakage elsewhere. It's exactly this kind of thing the regression tests will catch. -Barry From paul@prescod.net Tue Jul 25 08:15:10 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 25 Jul 2000 02:15:10 -0500 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <397CBB1E.D5AE9DF1@lemburg.com> Message-ID: <397D3E7E.520C7440@prescod.net> "M.-A. Lemburg" wrote: > > ... > > BTW, how rock solid is Python's builtin XML support ? I'm asking > because I want to make our product XML aware and the various > different parser implementations out there gave me a rather > unsecure feeling about which one to go after... If by "rock solid" you mean "doesn't crash and doesn't leak memory" then yeah, I think its pretty rock solid but someone like you should kick PyExpat's Unicode tires more forcefully than they have been kicked. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul@prescod.net Tue Jul 25 08:19:43 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 25 Jul 2000 02:19:43 -0500 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <397CBB1E.D5AE9DF1@lemburg.com> Message-ID: <397D3F8F.44EB162A@prescod.net> "M.-A. Lemburg" wrote: > > ... > > BTW, how rock solid is Python's builtin XML support ? I'm asking > because I want to make our product XML aware and the various > different parser implementations out there gave me a rather > unsecure feeling about which one to go after... If by "rock solid" you mean "doesn't crash and doesn't leak memory" then yeah, I think its pretty rock solid but someone like you should kick PyExpat's Unicode tires more forcefully than they have been kicked. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From Moshe Zadka Tue Jul 25 08:30:53 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 25 Jul 2000 10:30:53 +0300 (IDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <14717.9072.475757.832530@cj42289-a.reston1.va.home.com> Message-ID: On Tue, 25 Jul 2000, Fred L. Drake, Jr. wrote: > I think the SourceForge developers may be looking into importing a > Jitterbug database; once that's possible we should definately move > that service over. Jitterbug *really* sucks! In the mean time, could anyone send an explanation about Jitterbug? (where it is, what should we look for, etc.) -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From tim_one@email.msn.com Tue Jul 25 09:16:50 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 04:16:50 -0400 Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: Message-ID: [Moshe Zadka] > In the mean time, could anyone send an explanation about > Jitterbug? (where it is, what should we look for, etc.) Jitterbug is the bug-tracking system Python currently uses (at python.org). That's why it would be keen if SourceForge could import all its info by magic. From mal@lemburg.com Tue Jul 25 09:54:15 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 25 Jul 2000 10:54:15 +0200 Subject: [Python-Dev] Python's new builtin XML support (Python Consortium Meeting News) References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <397CBB1E.D5AE9DF1@lemburg.com> <397D3F8F.44EB162A@prescod.net> Message-ID: <397D55B7.4C7B664C@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > BTW, how rock solid is Python's builtin XML support ? I'm asking > > because I want to make our product XML aware and the various > > different parser implementations out there gave me a rather > > unsecure feeling about which one to go after... > > If by "rock solid" you mean "doesn't crash and doesn't leak memory" then > yeah, I think its pretty rock solid but someone like you should kick > PyExpat's Unicode tires more forcefully than they have been kicked. I will once I find time to look into these things :-) My concern was basically about design changes (I always assume that code going into the core doesn't crash and tries not to leak memory ;-) -- before trying to come up with an integration scheme I wan't to be sure that the backend will remain functional across at least two Python versions. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Moshe Zadka Tue Jul 25 09:59:46 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 25 Jul 2000 11:59:46 +0300 (IDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: Message-ID: On Tue, 25 Jul 2000, Tim Peters wrote: > [Moshe Zadka] > > In the mean time, could anyone send an explanation about > > Jitterbug? (where it is, what should we look for, etc.) > > Jitterbug is the bug-tracking system Python currently uses (at python.org). > That's why it would be keen if SourceForge could import all its info by > magic. No, I meant something along the lines of "the jitterbug database is at the following URL:, to get a list of the currently-open bugs, do this, to get a list of the bugs which are related to some area do that" and so on. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From nowonder@pool.informatik.rwth-aachen.de Tue Jul 25 12:36:56 2000 From: nowonder@pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Tue, 25 Jul 2000 11:36:56 +0000 Subject: [Python-Dev] guidelines for contributing to Python References: Message-ID: <397D7BD8.9584187F@pool.informatik.rwth-aachen.de> Moshe Zadka wrote: > > No, I meant something along the lines of "the jitterbug database is at the > following URL:, to get a list of the currently-open bugs, do this, to get > a list of the bugs which are related to some area do that" and so on. Non-authoritative answer: the jitterbug database is at the following URL: http://www.python.org/python-bugs [parrot.python.org at 132.151.19.90] to get a list of the currently-open bugs, click on open (between the second last and the last horizontal ruler) to get a list of the bugs which are related to some area, enter an appropriate regular expression and press "Select Messages", then select open (or whatever category you'd like to view) hope-that-helps-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From nowonder@pool.informatik.rwth-aachen.de Tue Jul 25 12:39:11 2000 From: nowonder@pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Tue, 25 Jul 2000 11:39:11 +0000 Subject: [Python-Dev] guidelines for contributing to Python References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> Message-ID: <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> Okay, so where do I put that test for Python/compile.c? BTW: Someone with the right permissions might want to close open bug 81 (duplicate keyword args) Peter "Barry A. Warsaw" wrote: > > Absolutely agreed. I can't even count the number of times that my > regression test suite saved much embarrassment with CC Mode. Python > is a big complex system with many interacting pieces. A butterfly > change here can cause a hurricane breakage elsewhere. It's exactly > this kind of thing the regression tests will catch. -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From fdrake@beopen.com Tue Jul 25 12:32:30 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 07:32:30 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <14717.10034.65655.779012@anthem.concentric.net> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> Message-ID: <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > I'd like to create two new PEPs, one which would be a Python coding > style guide, based on Guido's seminal essay, but updated, and a C > coding style guide for modules and core C code. I'd probably > eventually like to add one for Java code in the JPython core as well. Why would these be PEPs? I know some of us had discussed that a style guide should be written as part of the standard documentation. The PEPs exist largely for developers of Python's interpreters and standard library. The style guide is for a larger audience, so needs to be part of the standard documentation. I stated at some point that I would convert Guido's "essay"; perhaps that should move up the list of priorities so that the other people interested can work with it; I seem to recall that you, Greg Wilson, and possibly Jeremy were interested. > Any objections to PEPing these, even though it may be a little while > before they're fleshed out? Anybody else care to champion them? If > not, I will do it. I'm willing if this is part of the standard documentation. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@beopen.com Tue Jul 25 13:38:19 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 07:38:19 -0500 Subject: [Python-Dev] ANSIfication. In-Reply-To: Your message of "Sun, 23 Jul 2000 02:24:53 +0200." <20000723022452.Q9897@xs4all.nl> References: <20000723022452.Q9897@xs4all.nl> Message-ID: <200007251238.HAA19158@cj20424-a.reston1.va.home.com> > I'm done checking in the ansification patches. It doesn't fix everything, > for a couple of reasons: Thanks for doing all this work, Thomas! Frankly, I think that for *any* functions that are in some external library (e.g. libc), Python should never provide a function prototype at all. The standard headers should provide the prototypes! There used to be a bunch of systems out there where the standard headers were inadequate for one reason or another -- e.g. some systems didn't bother to declare int functions, and Python was taking pointers to such functions. But this should all long be gone... I don't mind breaking some ports in a minor way by removing *all* prototypes for standard library functions. (Ditto for non-standard external libraries like readline.) I recall that more recently there were also some cases where a prototype wasn't in scope because the right combination of magical #defines wasn't present, especially for functions that weren't in the old POSIX or C standards. Adding prototypes for these is wrong: we should figure out the right #defines and define these in Python.h or config.h! > There are a couple of more things that might be candidate for cleanup or > removal now, by the way. The 'ANY' #define in Include/mymalloc.h, and the > type(s) derived from it, for instance. I'm not sure how 'standard' the void* > type is, but I thought it was ANSI mandated ? Yes, void* is ANSI. Get rid of all references to ANY. (Ages ago, on K&R systems ANY had to defined as char *.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Tue Jul 25 13:49:03 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 07:49:03 -0500 Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: Your message of "Tue, 25 Jul 2000 07:32:30 -0400." <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> Message-ID: <200007251249.HAA19269@cj20424-a.reston1.va.home.com> > Why would these be PEPs? I know some of us had discussed that a > style guide should be written as part of the standard documentation. > The PEPs exist largely for developers of Python's interpreters and > standard library. The style guide is for a larger audience, so needs > to be part of the standard documentation. Good point. But... > I stated at some point that I would convert Guido's "essay"; perhaps > that should move up the list of priorities so that the other people > interested can work with it; I seem to recall that you, Greg Wilson, > and possibly Jeremy were interested. The issue is that a new PEP feels much more lightweight than a new manual section. > > Any objections to PEPing these, even though it may be a little while > > before they're fleshed out? Anybody else care to champion them? If > > not, I will do it. > > I'm willing if this is part of the standard documentation. The Python style guide should probably go into the standard docs. The C style guide might as well be one of the meta-PEPs, like the index (maybe call it PEP 0100). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake@beopen.com Tue Jul 25 12:57:49 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 07:57:49 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <200007251249.HAA19269@cj20424-a.reston1.va.home.com> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> <200007251249.HAA19269@cj20424-a.reston1.va.home.com> Message-ID: <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > The issue is that a new PEP feels much more lightweight than a new > manual section. There are a number of smaller manuals now (doc, dist, inst). > The C style guide might as well be one of the meta-PEPs, like the > index (maybe call it PEP 0100). Should it? I would expect it to be part of a single style guide or a chapter in the Extending & Embedding manual. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas@xs4all.net Tue Jul 25 13:21:20 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 14:21:20 +0200 Subject: [Python-Dev] ANSIfication. In-Reply-To: <200007251238.HAA19158@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 07:38:19AM -0500 References: <20000723022452.Q9897@xs4all.nl> <200007251238.HAA19158@cj20424-a.reston1.va.home.com> Message-ID: <20000725142120.G266@xs4all.nl> On Tue, Jul 25, 2000 at 07:38:19AM -0500, Guido van Rossum wrote: > Thanks for doing all this work, Thomas! I can't take all the credit, Fred and Peter did a lot of it, too. Also, my girlfriend's decision to spend the weekend catching up on her sleep mattered a lot ;) > Frankly, I think that for *any* functions that are in some external > library (e.g. libc), Python should never provide a function prototype > at all. The standard headers should provide the prototypes! Impeccable timing, Guido ! I competely agree, and this is why: I was just trying to figure out how to solve that problem on the one Solaris box we have. (An aging old beast, probably with a messed-up installation -- all SunOS experience we had has fled in horror when we moved to BSDI and Linux ;) I was encountering a lot of undeclared functions, and was dutifuly adding them to the SOLARIS block in pyport.h, when I found out that SOLARIS isn't defined :P I spent half an hour looking for a reliable way to detect the SunOS version, or even whether it's some Sun product at all, and failed. I'm not sure if that's a problem with Solaris or with that specific installation of it (Solaris 2.5.6, by the way,) but it convinced me to just forget about auto-detecting these cases. Dropping the prototypes altogether, and merely keeping the prototype-pyport-section for *real* problems, rather than warnings caused by missing declarations, would suit me fine ! > Yes, void* is ANSI. Get rid of all references to ANY. (Ages ago, > on K&R systems ANY had to defined as char *.) Okidoki. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip@mojam.com (Skip Montanaro) Tue Jul 25 13:21:24 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 25 Jul 2000 07:21:24 -0500 (CDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> Message-ID: <14717.34372.437370.172614@beluga.mojam.com> Peter> Okay, so where do I put that test for Python/compile.c? I suggest Lib/test/test_compile.py, with a corresponding output file in Lib/test/output/test_compile, assuming it's a test that can be written in Python. (If not, the group (or someone in it) probably needs to figure out a C-based testing framework.) I wouldn't worry that it's a lone test for the time being. It will likely gain friends as time goes on. Skip From Moshe Zadka Tue Jul 25 13:36:34 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 25 Jul 2000 15:36:34 +0300 (IDT) Subject: [Python-Dev] Features for Python 2.0 Message-ID: Earlier today (from my prespective ), Guido said that Python 2.0 is supposed to include zip(), list comprehensions, range literals and augmented assignments. In private mail, Guido said the list is open to downwards debate, so I'm opening it. Would anyone feel really bad if we postpone list comprehensions and augmented assignments to a later version? I'm a bit afraid of those features, since they are quite large, and it is yet uncertain how programs which use those features will look. (OTOH, zip will simply replace some map(None) and iterating in parallel by index, and [0:10:2] will replace range(0, 10, 2), so we have a pretty good idea about their effects) -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido@beopen.com Tue Jul 25 14:43:58 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 08:43:58 -0500 Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: Your message of "Tue, 25 Jul 2000 07:57:49 -0400." <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> <200007251249.HAA19269@cj20424-a.reston1.va.home.com> <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> Message-ID: <200007251343.IAA19755@cj20424-a.reston1.va.home.com> > There are a number of smaller manuals now (doc, dist, inst). OK. Since you've offered to do this, I have no objection. > > The C style guide might as well be one of the meta-PEPs, like the > > index (maybe call it PEP 0100). > > Should it? I would expect it to be part of a single style guide or > a chapter in the Extending & Embedding manual. E&E is for writing 3rd party modules. This is for the core code. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From Moshe Zadka Tue Jul 25 13:51:56 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 25 Jul 2000 15:51:56 +0300 (IDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> Message-ID: On Tue, 25 Jul 2000, Fred L. Drake, Jr. wrote: > Should it? I would expect it to be part of a single style guide or > a chapter in the Extending & Embedding manual. Definitely not a chapter in the extending and embedding manual: the average Python extender doesn't give a hoot about what Guido thinks about C programming, even though he should -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido@beopen.com Tue Jul 25 14:53:05 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 08:53:05 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:36:34 +0300." References: Message-ID: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> > Would anyone feel really bad if we postpone list comprehensions and > augmented assignments to a later version? I'm a bit afraid of those > features, since they are quite large, and it is yet uncertain how programs > which use those features will look. (OTOH, zip will simply replace some > map(None) and iterating in parallel by index, and [0:10:2] will replace > range(0, 10, 2), so we have a pretty good idea about their effects) If you folks hadn't wasted so much time discussion augmented print statements and new operators, we could have had the augmented assignments and list comprehensions checked in already! If you have a specific objection, raise it. Drop the meta issues. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From Moshe Zadka Tue Jul 25 14:00:07 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 25 Jul 2000 16:00:07 +0300 (IDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 25 Jul 2000, Guido van Rossum wrote: > > Would anyone feel really bad if we postpone list comprehensions and > > augmented assignments to a later version? I'm a bit afraid of those > > features, since they are quite large, and it is yet uncertain how programs > > which use those features will look. (OTOH, zip will simply replace some > > map(None) and iterating in parallel by index, and [0:10:2] will replace > > range(0, 10, 2), so we have a pretty good idea about their effects) > > If you folks hadn't wasted so much time discussion augmented print > statements and new operators, we could have had the augmented > assignments and list comprehensions checked in already! > > If you have a specific objection, raise it. Drop the meta issues. OK, here's a possible confusion point in augmented assignments: Sometimes c = a a += b assert a is c fails, and sometimes not, depending on a's type. This is just begging for trouble. Maybe it will cause massive confusion, maybe it won't. I know I'll usually be wary of using it. List comprehensions' problems is that we cannot find a syntax that we all agree is readable. Perhaps the answer is not list comprehensions, but lexical scoping combined with steroid versions of map and filter, together with zip to bind things together. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From thomas@xs4all.net Tue Jul 25 14:20:44 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 15:20:44 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 25, 2000 at 04:00:07PM +0300 References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: <20000725152044.H266@xs4all.nl> On Tue, Jul 25, 2000 at 04:00:07PM +0300, Moshe Zadka wrote: > OK, here's a possible confusion point in augmented assignments: > Sometimes > c = a > a += b > assert a is c > fails, and sometimes not, depending on a's type. This is just begging > for trouble. Maybe it will cause massive confusion, maybe it won't. I know > I'll usually be wary of using it. In my very honest opinion, that's overstating it a bit. It isn't much more confusing than the failure of c = a + b assert c is a + b for some types, but not for others. Not to mention that a + b can produce an entirely different object than b + a depending on the types. Now, how's that for confusing ! Has anyone ever seen a problem caused by that ? I haven't, and I doubt the augmented assignment is going to cause such problems. I *have* seen something like this: c = a.extend(b) Though that was a real silly mistake on the programmers part, and hasn't repeated itself. All in all, the only way we are really going to spot these pitfalls, realistic or not, is by *using* the new syntax, and letting 'newbies' use it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@beopen.com Tue Jul 25 15:24:08 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:24:08 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 16:00:07 +0300." References: Message-ID: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> > Sometimes > > c = a > a += b > assert a is c > > fails, and sometimes not, depending on a's type. This is just begging > for trouble. Maybe it will cause massive confusion, maybe it won't. I know > I'll usually be wary of using it. Don't worry about this. Python doesn't guarantee the semantics for 'is' independent on the type anyway. E.g.: a = b[:] assert a is b may fail or succeed depending on the type (try it with strings, tuples and lists). > List comprehensions' problems is that we cannot find a syntax that we all > agree is readable. Perhaps the answer is not list comprehensions, but > lexical scoping combined with steroid versions of map and filter, together > with zip to bind things together. I'm about 3000 messages behind in that particular discussion. I still really like Greg Ewing's original syntax: [x for x in seq] with extensions to [x+y for x in seq1 for y in seq2] [x for x in seq if pred(x)] [x, x*2 for x in seq] (General meta-comment on PEPs: these long intros explaining the problem are a detriment to finding the actual proposal. Perhaps we could have a one-paragraph explanation for the need, then a concrete proposal, then motivation and rationale and background, and then raised objections plus responses? Currently the rationale seems to be coming up front, which distracts from the proposal.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas@xs4all.net Tue Jul 25 14:28:37 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 15:28:37 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251353.IAA19818@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 08:53:05AM -0500 References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: <20000725152837.I266@xs4all.nl> On Tue, Jul 25, 2000 at 08:53:05AM -0500, Guido van Rossum wrote: > If you folks hadn't wasted so much time discussion augmented print > statements and new operators, we could have had the augmented > assignments and list comprehensions checked in already! I don't think the augmented assignment patch is ready to be checked in, though ! There are a number of crude hacks that might be solved better: the 2-argument opcodes, for instance, could posisbly be avoided by abusing the proposed 'extended_arg' opcode. And the patch re-uses the binary opcodes as augmented-assignment opcodes, merely because those #defines were already available in both ceval.c and compile.c: this would 'break' if we wanted to incorporate a new operator in augmented-assignment without adding a new 'normal' opcode for that operator. I'm still working on the PEP, really :) It's just a pretty long one, trying to explain all the intricate details and the simple elegance of the solution . Perhaps it'll inspire some discussion in the details of the patch, too. Humb-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Moshe Zadka Tue Jul 25 14:30:16 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 25 Jul 2000 16:30:16 +0300 (IDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 25 Jul 2000, Guido van Rossum wrote: > > List comprehensions' problems is that we cannot find a syntax that we all > > agree is readable. Perhaps the answer is not list comprehensions, but > > lexical scoping combined with steroid versions of map and filter, together > > with zip to bind things together. > > I'm about 3000 messages behind in that particular discussion. I still > really like Greg Ewing's original syntax: > > [x for x in seq] I think the main problem with this syntax was that there is no seperator between the expression and the "for". Not a parser issue, but a human one: the same reason there is a colon after the "if" keyword. Now, [x; for x in seq] and [x: for x in seq] each had their objections. These will all probably be in the PEP, so I'll shut up now. > [x+y for x in seq1 for y in seq2] > [x for x in seq if pred(x)] > [x, x*2 for x in seq] And what about [x+y for x in seq1 for y in seq2 if y>2 if x<3] or [x+y for x in seq1 if x<3 for y in seq2 if y>2] What is allowed? Aren't we being a bit too TIMTOWTDIish here? (From there on, the discussion diverged) -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From skip@mojam.com (Skip Montanaro) Tue Jul 25 14:33:42 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 25 Jul 2000 08:33:42 -0500 (CDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: <14717.38710.261186.468871@beluga.mojam.com> Guido> If you folks hadn't wasted so much time discussion augmented Guido> print statements and new operators, we could have had the Guido> augmented assignments and list comprehensions checked in already! I hate to play the role of Obvious Man, but I will point out that the list comprehensions patch was assigned to Guido on July 8, who promptly postponed it... ;-) Skip From jeremy@beopen.com Tue Jul 25 14:39:58 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 09:39:58 -0400 (EDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: <14717.39086.748350.672470@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> Would anyone feel really bad if we postpone list comprehensions >> and augmented assignments to a later version? I'm a bit afraid of >> those features, since they are quite large, and it is yet >> uncertain how programs which use those features will look. (OTOH, >> zip will simply replace some map(None) and iterating in parallel >> by index, and [0:10:2] will replace range(0, 10, 2), so we have a >> pretty good idea about their effects) GvR> If you folks hadn't wasted so much time discussion augmented GvR> print statements and new operators, we could have had the GvR> augmented assignments and list comprehensions checked in GvR> already! Not so fast Mr. Van Rossum! We need to get the specifications for these features written first. Barry should be updating the PEP guidelines today, and Tim and Thomas have been assigned PEPs on the two most controversial features. Yesterday, I proposed we set Aug. 9 as the deadline for completing the specs. Until we have the specs, I don't think we need to have lots of long-winded debates about whether the features scare people :-). Jeremy From thomas@xs4all.net Tue Jul 25 14:37:30 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 15:37:30 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251424.JAA19917@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 09:24:08AM -0500 References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> Message-ID: <20000725153730.J266@xs4all.nl> On Tue, Jul 25, 2000 at 09:24:08AM -0500, Guido van Rossum wrote: > (General meta-comment on PEPs: these long intros explaining the > problem are a detriment to finding the actual proposal. Perhaps we > could have a one-paragraph explanation for the need, then a concrete > proposal, then motivation and rationale and background, and then > raised objections plus responses? Currently the rationale seems to be > coming up front, which distracts from the proposal.) You can put Barry in Cardinal Fang's chair for that one ! :) He suggested to use his PEP201, Parallel Iteration, as a working example of a PEP. And PEP201 starts with a relatively long introduction of how for-loops and the current map(None, seq1, seq2) work. I've been meaning to ask people about the format, layout and style of the PEPs, but kept deferring it until after PEP-203 ;P Jeremy and Tim mentioned a Rationale section, but didn't give any clues as to what it should look like, and where and/or how it should be placed in the rest of the PEP. It's also hard to keep the PEP both concise and easy to read for those not initiated in the confusing ways of the Python ;-) Who are we writing PEPs for ? For you, Guido ? For the python-dev team as a whole ? For python-list ? For the whole of the Python community ? A collection of parts of one or more of the above ? Answer that question and the faults in all current PEPs become obvious ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From esr@thyrsus.com Tue Jul 25 01:35:55 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 20:35:55 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724201721.A9990@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Mon, Jul 24, 2000 at 08:17:21PM -0400 References: <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> Message-ID: <20000724203555.A32412@thyrsus.com> --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Andrew Kuchling : > Try reading the comments at the top of Modules/Setup.in. For a very > simple module that's only a file or two, like posixmodule.c or the md5 > module, you can simply add an appropriate line to Setup.in. But I > vaguely recall that the 3.x bsddb module is a bunch of files -- if > that's the case, I'm not sure what to do. Looks like just one to me, though there is some auxiliary called config.c to me that I don't understand. Here, I'll enclose the stuff; it's not large. -- Eric S. Raymond ...Virtually never are murderers the ordinary, law-abiding people against whom gun bans are aimed. Almost without exception, murderers are extreme aberrants with lifelong histories of crime, substance abuse, psychopathology, mental retardation and/or irrational violence against those around them, as well as other hazardous behavior, e.g., automobile and gun accidents." -- Don B. Kates, writing on statistical patterns in gun crime --k1lZvvs/B4yU6o8G Content-Type: application/octet-stream Content-Disposition: attachment; filename="py-bsddb3-2.1.0.tar.gz" Content-Transfer-Encoding: base64 H4sIADNHQDkAA+xceXPbRrL3v8KnmJXlMqkVQR0+NnLkp4u2lUi2nqjkxRVntUNgKOIZBLg4 RDGp7Gd//es5AIKUnbelJLWVoBITx0zPTN/d06PJrDPIw3Cw033wq12bm0+2nz9/Sr+bW8+f btZ/7fVg8/nWNrXbefJs58Hm1tbO5rMH4umvN6XqKvNCZkI8uM7U9afafe77f+g1cfQ/kx/V MIqVP8mUHyX3OMbm1ubms2dP7qD/9pOd7ecN+j/ZerLzQGze4xzuvP7g9H8ovkmiG5XlMsbd rbBsIIZpJs5nxShNhLotVJJHaZJ7D8Xe/+fyqEN/lGaFOEnyIiuDwkDpLFxouuWLwzKKQyGT UETUQ8axnURry38qaE6Jmqqs7VPrbV+sjmm6ojMUDe4VgzQtVqnNjmmD+/dpKfJRWhL8JJ2K kbxRQtIbmalQxNEgk9nMxzRO0+T6sxNGQz3Z9dps10UxUmIg8yiwE8e8w4iARYMS0Hwh+kqh HUEwbS56B8dnPcZ5VBuXmrYuR1EuQCF6IdKFlRKMNIlnYhoVo5z/rY27IWQ8GUmx4xDntzHv o0zJAotnSvdVUU6ANAw/S8usIjhNgMc3HBHH6TQ3M6fGY1lgRljxWRqWscq7FSzq8ULkeqFz i8ILmjqBeEXjEQGi8YSgjxmCCAiJRI7VfCLHq7Q0PTQ/6hZ+sLohooIaYu1BmhSShgOY5Jpa xlGidumDEOgi6v0MC1BHMdBclouxTGZm6BzPtHwxlUlBM+aJ53KsiHqZCoo0mxEXEJD/JZ3h uEdNZAZcYlxGoJLByGBlbKHMYYVZ7GRYDVWkZj7zuMd0muy5AUwqEidJMHhIgwBavJ4XT5p4 LblmJKzr/uv0IPXHIp1gejzW4rzepgUoZtrqaU2yNFB5TkNNIsKS60Tz5vsNFldqn4hpmn2E tDAf6oZCnBQiTFWePCZuIUaeZlFhUCKm6OQAEqMFI5lcq3BD5CnAjEB8murjTFlc2tnQGkI1 KK+vsfTF1WwwfsdyBjAGyyokvtEDgyGVDPXUaWEzsNRABh/dqgAoJspm4NTWASmiApJA/4Up 4T1PeQAwkxNu1aSgIj1AskljEIw8HSv0VHGuuF+uYmIrXpTlQLqn5kFRkhTMGtwxmDG/j8cq KbDmtCyYBfI5LjOLBwHQAEtGYy2zaRYRumRMROmZDwYdxGoxLanMiddoxHyigmg4Iz0JtZaE MsMK4jSQWoS1ogriMlRQLYY7eezcqBjgtHC6o3UW5UHTx2hjKMy8ErCKnQlGQxcB7EWZfEbp W5UVsI7LXSNQkXgnLAMsu96VeYAWngdZNCkgdlFCdB8T7iDZvKi2ISLNbxhd+wEEMUizSUrC b/ArbmRcKo2bfJYD8jC63eB7dauCK/0Ckojx6K3V6sMsHTs1qfWf0eEDohYZJcGqkrFJGIOQ bRAYloZ6OzGGBhgoqE3G3UQWIwjg0FBCRnG+IYpsxrrhLjQ6F+Db3kX/5N3bPVgwMzWi1N6X eiEvWUBJlQv7AmykRRSPjpkahtwaOQ0NZAE+JmmeRwNiejIHUUwuGetSoK0+cg2PL9tOYe0a lmD6C5gT6Cn9LojTwUBlq6S6IeIyz8sxCxqpONY+hCgCg64kxXJi1YZW8EYdiQlpAhi8HHJP YDI1JlUGoYmx2psoLaH2SOImJHRaDGpqnlSwFmKnqz6p5UULbeA61TWagKdaGBtv9Xp7Q2RW JFYhinrV+itplRyOj1MhbBzmh9JzFUtnKjFkEcEkz7S9+dhkTdECTPZA8jRm/8ZZF4s0q/2h A8vJBN7g3CSIWFoPQ0MWEchDaA9JJc8ZSepe07QVE/GqMpWXMUvi3PTq6KH+WlpWa4zTg7XG mDwSG4imOKSZNXPMGhAxgkkQNKpt81USPFqtwkc2x5omPNYbUii7jeVAPMS35weXbzacJWEK Q53TvRpPihmjbFCpR8YSMWdL+dd+e3dOjH2/qV+Zq0WeBZAd39ej0Y3naT9eHDquvyEyyAFM UAtIgOCOsrS8HtVFqy2MS3/ZEPLBzDSDTbBkIeJKc78KngiAHE0BrybTK90yz7owLbEFXZNy B986Y15TJ6y1qge2PH3ivaBuU4A0XjowG8hcLScD23k4iNOIZs/ib30GGpxaFdPUGFywN1nv IZQKe7PQfAk4VJZFOobMOFaXWic6pcotC3GtEgXH0dl1tiuQtxIW1BBtZcX3NNVwZ6j2raMV azGrsOyCAuLQdBz9SEaXhEvFM0e2Vp/FuW21gcyuVeFdHly87l3SAIY2UFvODs3blxZTg6Wd SMLcpYG0vfP3l2/IVNShHIQhOTaEnM4J06BzLNKJ9h+AM+/o1enB6z51WWu9O79sU7O11snb o9Nvjnvn7/Vj77veUe3VWuu496rfNnxiSFKxLnv2xCaKZUh7NoSQsaIp1oJYnzUr3khEHt9v 7/zge4cH/d7pyeEe3/R7l9+c7y3iG5Bp4WD1nKEzYs/eHb87/IoWcmXurvCKgJlXuLuywI6J C5JIY0GGoWbuBsDmsOwfaA4pCZ0tK5rOZzEUtvZ6Zd/c7XtHR4Tf/aOjfe/05O3X+knf7Xv9 1ydXB4cn1Nzc7XtEB7SgH+pwbOizb+7w6vSgzy303b4HeuAZvxjjsK9HONRPZ+bpjJ/M6Ic0 9sXBW2CbnvXdvnd2cPSGqEzDmTua4Ds06L/DwP03Bxe9Y56MvsXa3Et7q5f56t1F1bz+vO89 3CfaXh1h+RWfW10Gl0NmwYj0H7ngmepESagmiv5JjFH3dEua1rzW+hygJpiahtsj9td3bUv5 V9Et8UVY4xSXSlE0iFWJrHFbMJo2P5CjkyRDaB3rOCV/n6wtddtANEXGjvTPQIZtr/+md3qK hZBsd/MRwPduJySnGNroTrLM3uHJ2+OTC5bShuptoyvoOvfdrKVL6p9o6vrWu1HQ7Rmp5s/z X01c4fWPLk7OL02DOlSa6bGiKCFmJOVk9Tkqac4aE+uBW9daeo7trtZNay0jHm2v1sYNt6SZ U0FoWM18Scs5hbW3DGdmeUvncr4czbToxeaYt+XytVa13nY3J7brTCiWldeECYZ7yoBx1+5q ReIZja1FVn875aGaI/mSVNzB10YpVk2d0uKvr05Oe7WPLuo6evf21cnro9onG0LZTydvl3xE ZssMWH1kje55/ff92qzPYBagVEh8Do6NJnZd9GL81BrYFNxzTnYZmtV5kCbya1U61iYsZDyV s1xcl0g5UPQ8KsAN/csDyI4bxcDp5CPRCVhO591bF5hVAR578aB0qadCvjrHbSzOFBwWapy/ IFDkI5CxhKVHFEBzs6E/Wa+gQJIAUk3Crdxcoxuls08N8LB7BxTlb0BzmKB1TJ6zDDvagVc0 JgcLyGxdp2koolBJnxxGs+Qrx3A/mTc/i85YPH36dF51ZZzMMErr2Kok9hRseM4uSL4QCLBz 4RkttrtSxTFVulWRsiOqIkVAqNxdWdFBiljWdgE8m9L5AMzkXryq/y7UAa+UrLd2N0xa2gRE jRioloO7AzT32gUra2+r7bk7DGb4to2J+pL4uZLNduU5kpRrJ6XtaaGAGWfu1/ZZC0LN3LXF B2opPgPftEFPeJrt2jh0a/wXI2T8a+TP9Oykwq2F5wLHgHBmWH2OhisrFAMVpLLFX0QnZHfO KrG2eKFTiAC6Mv5Iim/hO2fOiqxUdD+MqF2Hcwlw9r4TcyR7QQKsIdkB19Yi8Zc98d0L/ZqH gi6v83WbW82N2qU3psvQ3CD9V7EEW1kTS3+WDxj9zAbGUwQlOxQhU/jG3+hRZiLIHKHq7dZa 2lcyZNReMIkSBZx5zYVcL6ZRoNZtbIMJOp+25lRoUdAq1Wpdx2u7K3MJMu1Ka75gOMwZ1iZo dqweDV+M55NsnYD6OJXfNjA7SRNsA2S7nqEiqnaioiOvCcva7SpUlsjY6BYsGeF+hYshp80Q EtASQw70vRqM3V9j5jSvM848GYtTpfccmnVuct71t0RId1echcTstIgfGQmnubivNkHEeXPk 5sMaTRH+r0OZriPvEFUp+JmC7YjywuN2QEEA2uqIs13t4Bhra1aj05O1tOgcinjc5s5U/Xl3 Ia3igheaABxaInOVg62m0+z2sv7CbS+SmWPLNbZTBUTiiRLJchgVgcw7gnfvfM/kYXt79azs m73XLiJ3QTxn4ZetDZRzs/W90705vTuHNMzErMomRDX5fwEG3RC7hk3hZZFsML5YVYqOEo+3 8q6/3t2KPnzoTh67t9v5I3/90UOx9uZR7W337zZK7ObV/fdi5Yf1Dy1//QO5j49s+Pj9/g+P Pmw96s51pxgSPemn0eno6I72tkOzh4vF0A+fF/qamBXdzW1jTP126bgIZdERv41e9GppFxvx 8njmvjmgfr20O8fC6Ms3jY54t3xQuLJ6hYeLw9G7u3qd2V5nS3qd3dXLYvNwCS4Pl2PSxOro Z24bPfXbpX1tVI/O9r7R27xe2r3/jnvST6NT/90dFDQeqiaheVigoX5/B7vWILiHBVb/BIS1 U+5LP41ea6fL22vs0I9rigeSXbxaaN3TrXv11j1u3au3rukL8bKma1UwSsVq9+9VIqQbroqX y5rUkqw0CoZohOqP7ujYTNHa3ouh7V0QTPrTDbviDMJdPXSWtN6B39zZ3rq79aU5F/iuTjZJ WOtjXeVPddGBbKOT9hYa3eBWupy8yc8izUo+gd7H8lasyv6H9eLZKViNxnpjZZa/EBMKEov6 DuP3uzs/rP6D3dcaWX4RBG0eTecmYX8RhJqVNWBqnt3dhl4T1JLR7mK49uyqWVysrZk7flvf HFirHvjbwu7BWuMNt3LZC+zd8FZUzcHkrb8lW8Sc40YJQTnJvSBWkt1L492vkx+4/i/6mcwC EQ6upkRg7cLdAb+KcnWWn3w8U02QKbd34BmuAHvQePXhJIG8zsUlGSux4N6zx1FFbXVXzAHI U/wTizy9cvv+3i+bMHYkKEoiZ9PuSVQbdx5uNXYqnrajOj9f+7WuONGn0fzrHz3e9NZFGMA/ 5yp1vgKFJVkUhgqennG2x2NQBE7fhqChuStBQK2Dzm6YNIMvOqju8/r/c/J6L58iN+YoJHaJ Wn4EkhHAiSyIgHgoRsib0ANx80/o+LPoUKAbplPRMXsmnTANdCWO6PTN3mAnTOCIAiThklY1 QIhsJ+Kt7OvA1y2c3pBz3hQNUy3mPPWrK8R0V1d6bjxbM83lc6aHwKcx6RexsX7DeaK8fm+/ OaosiQkda7khDd4qX35uNSi27AQ/DhdoO9cK3JAN516xPl3oZAMpTrgTJxJf5Shk+r3LKv9j rqr+VzPVrzHGp+t/N58+2XrWqP/d3nr2/M/639/i0lT3i9vC+6okzfS3DUF02BSiI4QRtXAg brb9LX/TAw72xzLs5EGEIjRSD6RgRFfwB65my6Igk1GC917vJooFRdURxb05VzAdiENVkN0U l+k4zbJ06n1vRhGjdKwm8ppUpBgVxWS3223C62IUk9DvGqYVP3iLlcT//uV5nFAzpaiTLL2J Qhh2m+9loz+UAVcGHKrsI81xdnwodvwt0fqYpFOU83iwOuomjW9sQgbmaJVmTOpxtZ7qHoo0 Dtu+qIMiEyVvZBRz1p57G3RMp1Myx0qRAyEZ713Sc2bfka2zN194veULV8yQKG0oddFqDDMw q+1F2Do0Woa/9cQUr3q1SdniaCGORgo1kqj/kCg4jpK5elDsvmP7JGKHhavDPK4FIgghMpqt 1Nx3MFietrXXZIYiBIkRTY44xLhUmdJVhyqk1W77osdbGuozNYDzFU/OfnGCqAhGekqOphUK aYwdv6oxrMHhHmQ2LW8sqdqizk9qnVEAojL2dBgO35HFtBVLeVEOhzVXiWkkkxkqJgjUU19c 8t7mNWGdk0lyvhTIFEoP0xTVW5q0KK0lt0hvIrGXGAUezDgTyln7F7rONOBSeOLygUThHdFu oKUTztKsKpbX+0oedoUGGotIsla+g6s1JYnOUEvWx/CmMFyPjsqMghfhcU2vdchoFlwvDT8l VgUX+ZYJ6C/FOEq40CsR45k4IvbIwKI7OyKWkyKdEI6e+VwudHB+YhK9lexKWsh4YpKCESam E+HzMnv017966I1C8JKmQb+mDlHxPhUqe8CCUgzVFOUanDmXMT1K7OvnopXrfh6gV8U/FL8l ueR697bZd58CWCDJS0UJzQ1YHNJ9kQ5ozcdlkjzOvVqZf1UVTDP5xuTx+1b+6wuhyIpAJ6SU yN8tZezZpPcA+x5Rogv1CSyTnZxF8kuvrkyRuBaxoYyyeOao4EMPKucHmnnM6RenZt4CMazL jPcFY7HpP7e1oHXH0q3npOAqTaWzs9IzRwD0VuVAIr0ZSnoCOLjzumSd1+RskgFGOpB5n6MN w/6o6edVxyRbAeeADQJG6RRxiihxWoC0FIq5A4sKVtxN57cmBzUBMLvE4HoAMfN35sHXdqTq h9gI6d9hGbuqUx0cufMPevH6mATBDj2HAYiK1hFxZJLK4B8oSl18Hagk1/YEKzeYihGgZV7/ v08rXNqiAMLavZpNv3GJC+KFGywPCQEuTDGzshXoJobZFc2u/j0b9JqDs7Xd+aqMZ52tL774 wssgd/uI+Un02F2533FRXpp7RkiMeuaDA0nKOhH8xzUAF72jt++0ucOpB1Llkjflc4oUWS+z QbVHMsieQmCd0s7BzoTOQUmiHJeZ3dfPWMwM25izKmxhoBxqQ3rjGQoZN3h7COwzSMPZXG0k igT+i+uDUTlA6kGQcv/IB6jofzL017pn6J08JtOG4nR9bOfW1sVjbsRxbzCLYZmwxf9Iioyr XGcs4cbHgS+ej6KJn3+cgXP8RBVdplRoHT8swCsnIWr775uN/4BhYxX/WTfu/sf4TPy3ub3d PP+7/Xz7z/Ofv8n1ULw25UIi5Jo6o6krTypP551oU2QLt7jw3PEyD75x52Ttp8Pexde90977 48Or45OLn225Wy0z1DldbEUutOjE4eAPKIG/71XJfy2JeM9jfE7+tzab5793nmxt/in/v8Vl SojI4+SDuTjd6CJMcmdTchuM08hue44K55yDDRQeqX+W1JpC8997GX9e/+ZVyT82Dn6dMT4p /9s7Wzs7C/Z/88n2n/L/W1zd9Xu6PDF/4fwv10uLVtAWFHI9R83UZVpQsHKUJkWWxqKfDosp +Q/NvtWFY9cXgJJTSJmr7Ibi4vtz9/UfLRBv5VjtYjS9LXes9MYVha38Frt7tcyv++MYS/JJ VSaQ/8ICUjnHEscMxd+6211CwdPdze3drc3zM897iD80oUP3Xb3YS7O1OcwU3C6NG1K7780B Lx2NIa9gvultr0Sf5q1fkzKbpLkyR7QRh5EzFw0jvY3bJZVd+3sUHHXG+JMXMl+AxOOZlGym xjjQB1zIoDCH/s0BtDDlU21BLKPx0illmorIeU8TxVEekheypKjOPA3nV2cqxRcgudWPZE6e qEo4nsbfDECihMJr+phRADvjPfNbGCw+tZYtQNInhZFZfmhOrBuOPWrrXRDi2F+yifGQ6/2y YES99P4Jv0IOTQ6wN25SNEJO+Ggyh+aIb/mYJVdvhsrG25alUDnPXOXfihayWQopuh1/079t 2z9fAJxt+8/9W8YV0vqgdXXIFuknHG52mV3+SwG1vydiDidex+mA5DJOg4/arnMmLxShPm5w fIizzRPUHNjzcwJHH8VrUorwFM590R8jmfHl0p2gl4QO774UTdfzHpnQhOKFRz95D22I8SXJ 7+il9+hnamHfFbMJce0kh2B3u/elOlh7dLviW4PGpBwPCLvzkZP3kIutkXE16L66Equ8k7bK vY++7QucHccn1zi4yaNQrK79H3vv2tDGkTSM7tfwKyY4iSUsZMCXZHGcdzHINk8A8YKInZPN 0TOSBpi1pNFqJNts1ue3n7r1dWZ0wYJckHZjpJnu6u7q6qrq6uqq/Q57HlTeB5vVrU2iqocb Tx4+2gg2nm4/2dp+8pSO3fDSVvDV6uJGhz17GQ/TUYWPEexraBwsg0JCjFyfY0Q9cwN11tSK EBKOriUMkxhpInZvPn1Be98KzhF6I4z7aXzRjzCWzogWevyfqDl6llOgfYkyOxjDlmX0HRZR JVKKNWSt8P5o86ldQIOQkgTCLSKt2zAebeXCkJIEg4uYMuqZAIHt7+Cin0CZIHi4FhzjSadQ DVapBkDXTl3sk6kb9zsfnbrJ+TleRtV1JzUM+jy3DJVPonYy7Exu2qoN+/OD+u6Pz/A71K63 /oURS4YR7hfYf514Ri/sQ6eG3BOc9sMkVaGBUj5CYfLu8DkU0ArZPoXogXu9QesoX0jiU5eU rIPQTwQHAoqIhw4z1aWG9KrXSoCzBn2M0WNxRDo6CdvDhCNyVBECydbBMMELmSmAgH1NKx6p 41mUlRK9gyI+KOMs2vd7V2Tt7EYd2AMBuWKfgt+0ygIYEt+z5uHO/9RPKrlv9o8K3hzvNHZf 5745bZzsH72qrNjvDnfeQo1XtdOK//Sktls/2Tt1i++9aEDxk8b+zoH74u1Oc/ekttOouY/V M+vRUf3wcOfYedR4jTZ1t+b+0X6jubv3opJ5iOST9/RV9uHhcb1+kH3ceHvkPMShApLynjVf 7jR2XBBQGwZx+vPRrvP47LTWrB39tH9SPyp63jyp1xvuMHEwe/U3bpXjk/2fMqjEZjONcl/e 7Ow3nMcv6ye7XvXa2113GCd79aODn11oJ2dHu5mGsYvQCLyrZB7v1V7unB00si/qB3jlKfv8 ZOdor36Yff5z/ezoFdWwX71onNRc6nm9c/ran6ejuovwox+PCKMO4Z65JAe/T+snjQyos0Pv ETx5kSGNn06PD/Yb9ZcvneenRzvHp6/9Gd552fDq7xwf1472nEcvajBl7kh3X9d2fzyu7x+5 ndytH52eHXpFz04OTo/8R9B3jyr2T7wpeXlw5qHzVa3RfFFvZB9m8fw/0LfmfqPmYuzH2s/Z duAh3uFzp91/cFR7m32QmTh6eFTPPK7jan1zsp/hNpk1c1w/3W/s1/0lV/sps/5P9naBLN1O ndYyv5GoX9WyTzMYo+7BzJwi67Zf1I/pDgjw3VOXtZ0cvvHZ4m798Pig5g0TEFw7PG78nHn4 dj9vFe4Bu82wUVnnjVcwnEZtz0Nj4yWgwn0Ia1zJFrfTZ0fCPaE/K5+erSxWldzpc7RF0iV3 9U7nMuoOWAdAaY0nA7C9SEkdBJWeT8HRVaHVHH3sP1PdBXgksS1NHx6NMCgC6Qew2xpLlDut zLG6UVLivDOGLVibg3aBAkAnqgADNdsL2CNx2KNhZN2TBI2CeTf5R8Dufxi8CYd4y7MMNb9G 7aPEBcpBpuMyHLk0zPrTGnSphi4pelxqcOzn02dPGh3YREJhtaOBOGFLK4dXKCmOfhJthH8g 8GbUf/9MPYN+rZFnSgN9UvixUnHPu+FFmulFGpLnGr6T+9KDqF8qOzXD0Ul0vtsfufDaXdCk Os+IiqxO6g6uOU11WlzbG84aqFx6AAZn/KFXSetfz6in6m2waq7ertL8875bgXQ6qT7W4KcM mowj1gc3Js9yYdoIUDs6Eg2giyHTKPWuOq0KNVNWdUpBiR6X13/g5r+B/T4WKAf//a95RyPP Fik7mN7VqN51cN1ptTO4XmN8qlmYNBRQ/XvsgtaP25GQZ8KoR3ewME6FSsUFDPYBGaJHCHtM +CVsDMqWpbvSq9+oE8gintEWbw2W9kfYt3wSuL/8Gjy3VO/fPBarnq86j7eD06t+O+jEHXSF wFWdXq4GnyouGM2SDQJWrcfbZMx5F109RF+aYBDGw+BDiOFW0F+K3HDwZ5+ci8QpPb8RYvHZ RvBxXiPKWZNu7KZZkK6A0CCdx9vBAWzSoGPvYnIZpDsbKfqnQv/DDu7gCgBb8sUGbB4zaNgR a5/VCnD79Q8hsFbYn2bBatHkokA93g5+dIaPNsXzZAzMuVSrvyxn4dlSzYJnPd4O6uPRenK+ ji4jyvCVBWSLQQuQ9Xg7ON452t/9MiAfT9hUJ+zVNYq7ICgif3LW//53a5B6sKLvBrWTk/rJ l19+qWt9yi7DmB/xUuAPLITGx1G2KGxKaWWlsEKQPSXnJV4z5eCh++CXjV/Lz1hLic8DfBh8 H2yUrXWFC7kUP994FsTfa7jw48EDu5TpDTQpoONfq7RinUKqled2MVzk5aAFxP3OlP60Yv6l WA+mNd0SsAqCgiDLz6QC/WGrBDCcJkVm+An386XVUpyWVytYvyJAoBbrDWdyHXsQpql0LeCI YczQjMhlZ1CkaFYQ+h3WO9iNS5n9tLzucYBgUGn6EsKWr96ws2UnTrEUNo1QMHwkBoZSRTjY F9+MQujoH5ugR9f9VA2RTRVVxWKRDoCht5o0UzRuQNSGJYJwhAB/TAWCYH3ru2+3SOq9ffsW mDrBo7WmQktZ5xrM1fuJgXZSa5ydwGbiZROIuFQmas+2D5Weqbkvq54fnR0cAD/3QR3vnJ4i oDw4Tt+fTQF0VD+qISAgApAAJ7WXJfh2lPSj8jOLPvABSrWH2jIUqsjWvg2dfdr1zTu86dYh czxGkcXqvQTwRtXgBQfcEaURHb1J3VVGdzYLo7//G1Z8pTEEE/WJJiragx4aRg2EHc+t6QAl IB4mffacJTdWrK7NMgFJIVBfO1+qmJ4YO5n9Xe1rBhgyu4chM6UfCAWmWkVXtppx+oSe3+zW 21SyQzjgFZ6w6JFYvtC6XCdC6xu52TPq98m1O/oIqn9MPgV4IgEaethdbw/GQSv5qINpYifN MqLe4/LjBZRcDMNeUNIe6WXeWTiHcxvVJ08qARoktDsshhlF83X07zEME0GprirXBmzZHilT g+5TgmrmcCSR1toYHBW98lOyOJI1xGoLFBBaYsgWwqG+jYGenN2ol6pLiIAZRdOHP+tphcUX n+N+xn7mlHtRewUb/J2Dg/obeX9KrDD7+JlbsXa0l62WeQiVkCOv3PvAW59g9SWvgYIFsDq9 d79N6wes7qjfic9XaKOHOD1GTr33ooFKEm3ZSFMQyy1eHSAyl/uXyqsb6pVo/anwGy3xxAXC g61gjEG06PIqBzNmGEptJQILgbyAdod8AIL2FehDeeVrOVwqcYMVDGgNL9ZK2EMgRiUtezC9 0aj0DTyqBBsVJY6xhEgwZJNfpRy3FMSk4lmW/IPCVRrsc2Z9zgsEyByfxCHLToT55fHVzvCi eRwO00g1UAlW03sgEb9RIOUrAinbTR5fActtnkajU0IkcNLax3azAWMmVlxxhDzpNj/KrOxZ s6JDUp/TnlxmBVkNDrG6WjZDsVm7pQl8JVeNn1M/SXjjrJyOoReoGSKfPR/3ibPw+kMJ1saL SsoDmTkvCFA56CRhT8dTfEDwNYt6mUiFhIcP6RL7eWn13r17QQ09AADgdvAVbvn/2Vdd/0o1 LpUyMowvHFPLz+zjVqFTXjxykALYUmAAaZdR17pCRmGK+WYVnf1IFFD7FeApleNwBUZ8wfli WxT2UwdhMkGItoJlaLpDN5ixJKJVBO5aiYO441WTb6RbkYNmxrGCEp/LrR/aKPEVpiIOUdVr I6MVeGqBTbZIGhJpv61iqTuETCTqKB66bq4WVUyeZqH5Fb987qrUOVQhFovU2HskuqynXmXX I3OmkhiRKs7G2mulbC2vOQeXswQOovC9vwI+LdJeSAtbtmilsmgJJxF7J4LEH+NFGeAkvfBf NPC4j38ofDze69NXkPh4U106QSB0qax7xd4Mxk8HWmADnjRals0WCH3VDRj+WtBo1s8ax2cN DPtf/LO8SOOpYAT63u6i2Gt87AfrwU5fiy1zrce6bSY4s4tZb9XOBONXAKPY37NlIK4oFpC4 hAFLIPMuE1IMiavqNB9DxQn6qM+0Iq9mJ6a2MCBeGoOKyX5QwKtGGDubdKM6K5G0raFY7xUJ oy3O5RQ1mkJe2nLaGQn+oTAcbL29opJKe8W8NP02n/yWfrZvMqaJfY2rF3800HF0uTf4MB63 7BVgDtjsxVs5FX6AdQZCW6vWf18dfew3W9FFDEQsWBSVl4kNwGRMxcAsJr6k5fh12OkwvFQ9 Eu4CtUrUdgXVFVBnn6N4ZUtj+nyjbJW1q+2J21ao0puw92+XrvriQ4K5/oM1oDxIqp+lfFNu xR/Pmu4k8BtaRLqjnoVBDIWuRSEDDU3tvmEC+JvptRhP2TSuUASKD5QQHJVdAB4Tdl8Ks3Ra /eRPR5X2Bvn4UttOS20h9zIg+LDV55uLGF5GRTZWd2kNTbJFwgbYTS5QMxh0w6uI49CAqt5h lRXXRz/CpYGrUpuujEtXYHthopjGsw++da2eGkOuDGyWmTLzwJXwrtk8mHa29ZOQPRhiIqao EN0qBYrNQiiKjNzTpx2liVLTcQpyON6KDW/kTJ+56CkqB+0yLiQvz+hDsj64REaNMWniUR5O df/zsSpIVKVuDI3cwdIUruHSLuzRUp88KzJUxRY5j0oqIsKGpYRYHlKkN/OyB4MvAcA3HOde 5pOx9mmxZ6Us7gm5IkWMfLeMMawMkFpgmTfyShrdhqCV/WO2KTJFFZttnWf4fj/6gKx24BZT T2F6MqKi3EMjXLsku2PvddmbG9rdKnB+F5mK8navhxGoFleiN69yi5QWKeqsei1YFMC7BPf1 pxySY/HSZK2g9I3qnpE7G/OQn6nOR3HQwGZRCX2+m7EPeOXk2NZV/t0yfMKYKSBCLzuxFhf5 /4qpBucL16EaTd6c8XtGlpQr2c+yCMQPLAXbLh7EFyBBxdMwYjLC2dYJplphp1qt/p8Js4kO +D6PdXklHQ6LKQP6hsFrSI2JLjCuAzEau3gQ1KHCQ5aqXbTWkKKcs2rz2CA1pvclui1pp1Bg uNjkHjvI1MAI0JzUac9lllj4raIkPmmfXyIxBXiY3MWHoqzmMcjWFc0fb/SvyLJP8WPozBMN YKkLj3yaAaaqYO0U03FLIvHnSifu3SzsMY/6pQtroIPjwTQ9dzY+7QiP0QPvkze3s66UiROa M6mbk1jeTDOYRqMmzlIT9hV6vWCeJmcKTsVshCGF6OTEuoTI9loy3cplBRWNUO3u3dls0waQ BZohEJXlDNP+2HIzaVO+PhcGTUJHZRjBACp50+8MTVZnPJx1ObqIcZdlPFy4bofNdS8mz0Lj WjMA2w5yl5acd/l4kqavhSXV7VvB0ag3uAkkYSyixEq3V4Am1fq18KS7fiuIaoftywhVtdJF 62oUgWpeCfSXPr0t3j+o9U7nFur0XK3V+zopSI+UtaA1Pj8HqTpIkq6zBYurUbXCuwtsroJz wJ0JLuKLkL8NuuOUO1b1N8xUy9q6uT3C83Dah2NAE6IFPNRAE22W7dC1Lp5tzrwqWVxQvwzC XjLuUy0TP8quLKNEp4txf5yOock0Ho3lqlVQwkAyPEzVE8pv5kgxtOHobMVCf+ZOElnhRmE/ SsYpnWJLvCi0msKmzEEqJRjUKPn3OKY00XhVguMJfVkOCojXUARSqaGKmGSy9UNTxxzEbYC7 5M3NCOkpwrsp7tlSo0Mtb3baRiPluswyGmmYnhEXQpjFTFO3GKgfc3LOVg7ONKgbQlMv/Dgr kqAo0GZPI0tn8eZMiX2Vw8xCFohvMpbZ4PZaB6nkSOV7UWyd1fe0Hq9jXTmRrEhWhpFsF/Bm LawfG15LRc9iVczuaS7MCTMoyAj465yzh5Uzc4dgbko9IAeNWSaPj/F81w5MxpMaJwmKdEYH fSGfbmKwYGCUDq6Tdns8VPlfJes0B8xzLHBWBDa+NyvEgek8HXAklqVbHB6QoeJNRZlwnSRZ L1DObI+8tRuno22Htty7M642gB8Vm09l3hvgnbQr5MKm4daV7UZSzYPPV3Cy4He0h0nSxe2s YwTOA8R3dooAhQFU7+CBsm0Itayg9rTmwld3fyZ19QpE3kVhZ71F8s6iu0D/mmupaBDeatHA bmLBgL7Vw6vFBUIhmMTwOJ8z1DScrSJBrFWkUjwGQ1+hDsdh8VQOfdLV6eD9dqA1DDuIZu5+ ouwgFgVWKAMQUyit0M2NwxdFM+INLLB+zzMrNhh3XmyAC56ZRRhhLTQ3nFUiISAcSiAz/44y v81nOae6dOqzuqMPHq0mq6sBnuTqQ0kbknMW6uQrktXMfh76GFc8Y0xECN8OP/HUtgKCbxR3 fTM/Z55CGzsHWLDgCZ/WYVTbZNPgMLPIeXNPWjn19ZWibgce8i50c6noIJ598nORgamT47AT 6dMXPS3ksWsB4z5br4eR8vhEMRGHVlDVNqrvHIaXxqRrOXsRsjmK4i1uwVSRnROAbih5vNxM Geaa+TxKmvfUA21MvMyMkdfzQlEf/3TUXZ18JvuNwFL9yT8/sZZl/pp1bUZe/x5kTEwzMV93 GgqP/Egc8fnnEOR7uo5nojwF7DuQS4KFB55Wg9ebjskzYc5HLaQXmugm2/tzUJ2x0FrYnmXm ZpoYOZ6cPjX751PnYeLpbBEjlIPaeU5nHVCzH9TeMDXYB72T6WHRc+ixxmseBU+aWe9s2Gnc OSae4Wz4+uzSWx/rGVZ0LX5qHTgvmncWz55Dwpqpz+MG5M4iRkRDxolnfbnOV9XAdjArWoxq n2W8wyjUu2y5tGleLPZK03CgufFkMvsUh6jynNMcEa0iAk13UQtyHNTcfl3TV005quVq8uKz FszlsebIxSLntVkmfai9LI2TG0+AN48h3YYdJa7V8MpA0rOWTp+2akHfKHq2sw8P1pxRKbMN bnyUCzWsM7YJI51529McwryIORQ1MC3VM7KfMjAmqGmQwiut1KqrU9qGJemWAm8UaO7Am2bu AKyh2aOQ0l4XtAVjEPUpaURHbuuS8ZmEpeqDvWi9joTiBpcZEfYqTtNxRPOqjsswCpjbDeM+ VpG7chwXT7EgXpJKt6nIVTiXYcAHw7jJCmlfUs4Oe55Lzi+iLfJf9VY3fDCxLYWDYyYs13Jl H1I2lPY1srU8F0KlDV/XV9HykDAOkeR6pPwNfTHwKcO76drCIIFWSr24P4ljR155swDPu+P0 UjYj1mk2m6Ad1oNHKpQ1gZLcWLCGHCZK5DBarYW99u36dkNQpko3zqDbqLv1k/76f6JhUnEB x5Lh3YJCd3FA2hpGiiA4+0cql6SY9QBRt5mBd8N05DLR6H2cjFOrqaqPLlqo78NuzNf8sSsq +I5YHPFan4cJG4ggBa9rigHUDkLYT5iK8Sac7ujMfTSKjUcFZIBBSpjFTVZpIaa65xRAPvML dYVbkb+LDRxi3N73Wm1xvhbPuHZQ2lO6wy5xx7IUlR083o6hG31x2FXahRAyzyBdCQMOoLyE wuAixjkllUScBdD/WRi17ejdutIXYMj6zNwZwYmVhXJwcE4hutB4rpzpqYvq4mNQM7w9wKCa fBNkkKR0QEixSUzeFour8/GjEyKAPerxLiW5UKjwzNiyI1Ta1nCspSCwR5yeHG9vQ1WCmCdE +PAEF6wxbkuQSIMPCxc8eALHCKCIrlLMcj+mwG540ZbTOxnzvu4SsX4C5CqiL1jfIzYvF8uE /3MoF1dH1I3zbUCCpzEQ5tyVwE0jidbqDCiWuyb2ebB1vYq6qPaMJSWa7I0kCsIB6IODIfpe l4HJMDiT1CWLObqqzpeI1HV15BQdFeOGhmWORAhgyY8QUUa08eaZvCEptw0ezFBwb6HZN5i3 BmEQeabmyjKlbeNrs0hcQ/ScoeiA0egDy+N+StdC3zsrhq/KBhRTlTbsmPSEe5/BszRbsVGr 8usQsE6ctkNgzprKMY6sDnB6xRfvkW5VzKGe3HDQFzdeVGmi7cUsQCkvioYsSpfcygPkQk3b 17bteNqqgCzFNzegRhXUhajbbBbIekK8PfusnFPeFQxphEf8behWRS4HCsFqEOSVuXs9l8yi u3lFBqdOqw3gmq5HWjtn55t/2XDSBni6VyaiMusz6OsBgkW67ELzS4v7KAEFakj7PW37FbmB KM2o4caohCbn3H3MtVwFZ0O4e+YyA8pnQfc8/p7XsdvuUdZZDJgzcX7cADjEhPoj128FxPDI mUmJzOAop+rabNaKVEgTSgAjSNCmyRoF+6vzEZ1hc9/5pHrcEiXDMV/RSQTm+mNw5pItxjho jzwxSXF41DFD6GjWFO4Hi+NFdxKOyJbz1EVB6Lzmr2uTGbRniCxfk1wQrWFoqvUf5G77+nUJ 7iKS6yzzmkH4sqmJKwaPslEHiMo809BUgju0YrFnbJ1KnQptLTZFW5PoSO6O5BxDbRt9CQuy /UDpuqiLRnSs1YpAzeng7obJD+HZwOQypw7uy9v1DBhoCQYtHm1FsCw4RVjArSLGHxlY4XFM AJJItQgyLeql+gycTDTO7tF28dVBe/lCptYaWPdP6fCbPYMkHPEknqDDPkhUOKUPppz2PPoY 4kXJXDcSGxR7HW0XNBSYWJ/eY/y44ipV+dYVz6A2MVS3xzPzHKPpo5ClrKWgvVCFODXTlafn 5oGSOIrErx3XKu4R9QbnTpMm7V0mQUr9fniWYtQ5e4PRFZ/v5EDSq5iWirrSjmEmJmIfY5te D/lohlgo7j8T9dSf3wPzojDPh3cMDpsDa//cE+7ImNC4Z67PwKZD6tMxYQfZZBvvzCY58NT6 QrM+6ncfYpwE1Bc8YcyH9x/NjOYAs+Z4nhnNg2Rtb4pnFH8rmyzrIzQ9OfBcnKm4gUnfEIbY r5STl+p9Lqw4vd6cYmTez5lTrD/bnOKqrc4wo9rstshZ/YNMK7Pa25hXiVCdA/NELsNfQ3Ov TqUUF6K2tUrYzYo9oBxY9hCtYJ7VYnrMAeJQKFa6oBSoFg4pWGCnVeUoLmRgCK2oNy44IIva /tFPOwd5yjwqq9Nu9rl6sATDyj5ErLlPdbDcNUAJdC/XdUTFqgKYdqwq+OnfwNVRrSiElBXW Cn7n3dZ1wuAaDb9iYteV8wwQqIxhfGfr1halcaebu6zXWXc/SxJMKQ3Po3IGFnatqi4l7nF+ hEPcpOxm7RMw4lmKuiaKa++qcOKtXRWjX1A7zxbLKYT7SDrcjlSuezz3ph1RGXcDIfDFYcXm Acqvm3adYWrCr2ZmUwJ6WqFb8y9hZ8IwZspoYtSBGR38+oFA1WcOzwnsr2qFaZ6uXz6kaFQf IoyPiANlPHDwN+rJxK7aMUbTexRRDUmGpwy/kXdvBsTED9EnQ6CvOQ6y2ZFdc11hVdVhDFfF aCEbm3qcM1lYS/fSq6afT+yyUBujctLGnWRbsXMf7szfR32OGykxdoKg9u9xDHAjTl+tjmqQ YxNb1qpgDu+V9gKMQiqdJLupXpsVXb38LKe/qGItvruk5eT0llsLpvQWa+d2FtXcxXcWFfK8 znJr0zqLtXM7ixrc4juLmmaBg9/76Z3F2rmdFa1n8f0VDSzXF061ObHLAqD8LMh4jWHHUZij mC80WuVq1+YYEGVGrgrNPfKNZHzk6uh3edvffB3aB5aj0hbZRlTmRt3+BPuUvwdGt/B2P7F8 19gpgqLFsjM6dpJjtTudxMyEJkC8FXTNOlgmv0nr5FBiyqP8dk4eLOWX9/YyejkJzFVEvf2/ rQxPsIANcWNi2cHE401MIaPhmHza/EC38Cp1NWmaU2VaV4SDKlzE04OJ7HCU4kYHCPr3mHZ+ mWsvDrmpqJYSvBlnFvpKBlPeX43w0ijTII7EARRhvkb78mVm9vsJgxAzPFsOSRuq5GyknE2A DcmbBltlKriAg/Fj17DJTGCbwi3AdG3/rinvViCbW1ffsXmtvnN+oUUfkUxXRTHskFJGB3yO Moc6OoMq+vnKp3Qxq37Ki99XAYUFcoJsY5JU3LfMVB4/1j6R1k1VJSBbI4xmzr5JNjhV0ywN 5nSW/IrTyezTBmdx0qywruC1JOUnU8A3bWAsDLJ802FdjLAl//rL8S/OmrbkYn7VPwUXQ6W1 RKrr9bT7tgQToSBaZGvOU/QdZmGU8DBNkzbFEvW1feP5JZqUCaJT8RU/y49Za99+aHnhqujO P7IiHaPF2AalVG6dfW5PJZMkU1sRZyMkmmy6vBW4aRut+1bba54H31Dz2dfiLqFTDKjulrNF x7DbhKKqVraAx3/OTmsnh7XDO8OIb8G0a+eevH3een1j5eL4avDNN3msMI8GboI7XqiFXcQY rdOtoZM622JrmpHIqZZhbFndzudxszM2G1Yuj7sOYzPjn4WR+dzv2mxuecoknz/OKdOelTh4 0awIJrE9uCqxzKrY3CMrpxaunv1eJxzHV/v9UfPlMOkdJP0LUb8K7+2SnXtMFlhGUCUbRtY1 zxm1iW6ypK52ZXnMaXdEdmkisDYoY9+bw8NtJrc2SqbtPVaf/cJdMfC2yzC9dEN54q1I9gfM d7vADw0eVi+FgcW7FJbxWD1OzAGn45VQANLh6g3yD/pgmqBMXoDpXi/qoCgAXLGvcHEfxVTv OxyjSwL57utkMGhFlXBYUzApZ7aWIGFEJkPGoxYr6kRX5EQBOFt67J0ds+hQjtkWsaCTDkda nuA5MmG22ZTuTLK6wGAhoQCej5ocJHimehl80bTkik7OJi8YUAcC/psiNIZO+CW+TI8YxNsE 3BrfR1IOttMoxzjgomsf2qLdsD9AVrJJE1IVx5UCcNoePbrezJIIelk/qRXNuG0Z09MkJrFR /koqGrm1viQLlazL3KU0sc/Ffkz4qb+PhnQdVjNOC0OWES7j0FS82lN1EuMa4LSTpkyWPwNF qJhlXn6s/VzkUEwzs3jO6xgWbWNljgza1wgtAOamPM64tdEvvRgsZ9cinIWdjonKy0eClvlC /Mv5WDAcTToRtD4NZgQK03yhWDn0teyJNjdPNbcrgKkSBU2Z2gJvZZ5ZNU9zzsgE6Ud3Huad kSLq5XlyZ4RcUxc4IYifW5gP14NQ9oZ5DopRAHqde0Zrw3GPa+1TwmkntNIDCzreEWLM4YVF dZ2SyGGESpBzidQGpa7f6jtPvE4RdDoGHEU6j5CeQzXfNpgMcVUy7qsfwitzz1nlIhdmaoMS CUHh7Cy5l+uwMbZOTCuUgZM6MJieJWFBd6KwBxnzuXThD3dBiv+l6/o3c1/fzqvMz2Byw0FK noip6FDevR1f4hCxdVNKkE3xQUAjBOWG+Abgbv/oZV1dg8Vrt51gFe/Lr3IQlnPOpShB+Prn 8cWYb0vnJHPlzfdgGLPKTZqZlXHL4pKnkWgFSZujwyM05U3i9QkfcwIBfeWfGFRLFfAiuIhW Qxe90aFdIUJ5XHDcMsn5hQd7eH9/dKnvd0sxuuAssBCyXNRWuEgGkutLjXuF1qyw7/NEOif2 K9j99QbdaFtd/6Zl06Ok2J2WfhL131PimyolGaKcjfpFlXKOVKtV81Ss11S+BEXcN1XKitBq UlhyDBv6eOPvT70iBHMVvyLhrFYIFixbdEJRP3ZhPTVqZRfzXoyI0AoCtd6N30UmvmfFjZIZ dKM+Leq0IuTYDEejoUWsafABjUci0IhDaqZWEX09TeML1nX7zMpWlCsPb//2TEgqdzGoyXWi KNkxcWDzigckOgWhiQ2o758qIvwpHNJVCLQqUnZMZxUaclP7E3zV4azcJFElDu1DToBjvNcQ xQwT9iWaYtS06AmkcqxrEiHwPXkMNkDOVSlF6sFWuyHp1lTSFEI7h6w7/hQdLXGmDz6oFu2V AzTQ5U3BudJjDDjuGclCzt2O9D8iH6d6qXtB2AiOygHniVZOYYRy2DcAzRpQJvg+eQ4NMH9B SJc86rDN6yuVmgNWdOhkjXUflKDUj9QAUzcXoR+0MnjNhxR8BuTA+bjbVa5QMXYZyYy5mNJH DKwe3T1lwYt5Y3XzGJACSAz4on5WVr2U2yatiEJZ4NUSr28csAQEdjjERKKwjJDJUVwICkzM KeL/E9rJ3/lzSq/RusZRsmly2OHKNmZlLnPTnQ10prO7Aks87kVWxmSiaokJGXbxaujFpdgY hhHJCp5LyQ3FCUMVqep8yRwZRJMukiGNzKbei2HyYR3ZMuvTGkw6Pj+P2zHfg+khg9euZKIj cm9DJnZqKr0EMle5qw2ovJMCjpOfYqKreIjhOMQ1TRYycBIk4ji9ZCOXhsVyjq4Z4z6c2pZ+ 0F1jEX/6GjrdDzLL+vXO6Wt3VWtLk7eoMSwJEDxhF9jzFUjruE2lKZMFrNCeTU4qzB2ZNEEb Hsb0BDjwBWjH2bg3qkNktnZ7lGNfwsvF72PAlRIDJKjP448SRM1rzyEttNFURISSvQWjyaqI b8AcgULw6mCJsgIADqKwV1aRhF4kNrDC9owpaKg0Im1ggK1bN7kgewqX8nmNu6zYmMgRfpRa E7H/Ku5TPlxisin3QAvJ3Q5laIA53pl6yya1zS0vb1voqhHWHNOWwNKz3G58V6G0ARoXTwlT 34Juo+9oaUhEnhV1fUtZDavBaw4QXeEEYCPMviOXd0Fxgze4qdHYNuBKUfWiWvFbLk+95aUC JtHH2bjZU7KnWJuZBYQLPa8w56Pg7BVtx9P9MDZ3hx0o9iHAYAPi2iZlOpRmyuoP0jvOsgFj xZkqU1zPfIy5raUWTqweFSDHxYmKk+OEyZkhGWXJ+EYMriSl5QybOj/r5RrHQisstEabKy9B 5YTklHhglTmxorA6v39WSjk85RsA5uzU672DCNpYFmwpJ4eAcVP+bWTvoqEZBsXChyi4wOVq 5oT3HRksnr7Zf9V8FY2OR0OY+ZLMeiUovU+Ara2tlVWQck4yPdV9YbXJI2+qhpuD1bJ7flvg dZCTbxc/+bPZAEWY57KwR6uc4FU2gxwcRmLRDS/GtE3Y/KyZB3S/i6JBYAeyh+WcjEEP5auA dg+cqubOnlpm+bYHQDnUhqmWYt6E64yoKhuqMpBUbAhzpEbNO2NFSLnuHRTy6rYiXvkJGPOT L84f8MpEoFbYLrhjuVej+fLKFnXYmrpJoeOpWG6Z+cNyVW8gZZzRNJYZ45YZ4/RSzM8Wd1uZ 4oTUu7SDnjULGm0ZqAbNqdTS5ywSqNR4h0WjkExhrj+Inj+ZjGHE1+gkeRSBZ0uqNMAJh7R+ bgFrxRcYFTumy1idSF86kAYeVx5tbbIxpRuPRt3IL5wx5HO9zcrWo8eUo6irwSIdWtfhAHlM ubBBGTE8G5iss16It7Ii2bzjEytINfSpRak28QQet7+cxZUDfk667abVVdM7lUpajq1pY2Iu uuE2rRV54Z7EdlaY7UpThjQzK01LRUPQUv2GKFibYK+R7pCNVGMJ+n+ZdDs6iJd7OuSeHVlM F6MUU54sNiEhbJiNJ5tbXEbfu5R0WjYcp8bTxz8qqPumb/p1DvE51NbnJFqRxFjT1lDP08RY mYL9h/WgRXFWLTjYHA/L9djQgKk/dMwBs/oBSK8b92ISADBkZ2Hq0cNqGw8GdtHNpz9Ozidp T2mgfsxKfrqyIUAN4oZIsDVqAhm8i65mziYpROMZX8mmpk44hZkmnIqBAxzbsF6QKYxstQVo dLoV8NdZsWjqGjQKhBtC4mXz/DzEzIyzIpEsiShu0Gg3urLjQ5ONbxSSnTQfSIMAcEW2/lE8 Y1ikzqmaN0F0f5eYhaNXtNtjiV5iEmeAatd+hzIC8/oNexyY8YOKj2s6aANC0yyFFmS7KvOC q2QcvOsnH2zzPa3D1PL4cROQ9bWNHmsP6QfJK3W+JhZnjNVJuTDRkBr1L0PvaFuygYWU7GNH junJDDgcU8TJ3mA8Er6iYcV596oxzUhS5IJZUuszWA8ebZUDeCLjbMLQmvTmgRo65yKXZ99N SNtUkF3QH7pebsLiHI8HNgITCwSex9KC7lbHdMpZsO4cSg7k+6wLz1Q2C0+BuLGV10f3tlnW HdJJOsJFYhxt4z6p9UaqTl99ND0j3nEMxYk3QYlSsSqL6Q6ag39B+HkXty6GYTvCEyWaG31W EeHZKHssyikK7Gy68cXlyCZnZ5YjANUJdVKRFgXZiduTJlgjLKBvs08uVzRTy9VvaGKHEQbB jWeaWeaoJKPJMRc1faUY9cIhp6PDBDQUTNUJ5ObI/ZCjrqfAd9py6qNcD06y5xzF7Dnmra1S hwlIwSlERfnUwni5XRuUOnjSPEBrWLp4tgzx0H7ikomLHM9t9nv0AQJV/weMkgekSX4bJYpv u3O6u79vg9r4uBGWiVrpJB92PyP2MgP8rifn64JdRHs0LNSS7Nnl3s1KhrqmoUOuf3N0CDM2 jQpfCpn833E0jnx3a+VGrU847RMoN2SIJg5stIjAXhbT5OTGXNL6GHXWub0KO/AhZQilRJKZ iXs4W7d2yBtOGiMfIj/osj5R71K2EDzoYpBZ7ZvSX2XdrwcMWI5hNEXAY1xkjvkmGUbusUsx KcoE4zDnIEOsZW0Uoe7NkSAMsMT+UNP4IGKIXLLUSmZHrUvKDWVPunXylXGIFzIGAsihsZTd FuExot204+gqNrTvyTshy1wqzF2ApWxtMEvR3FJGkTG+eHOunYmyOcLwPFa80tyth2XDsNzc ETB52xiQdMDv6kpZPZw9nQ0SRI3guEc8Y8bvMy0WyzLHCChYg29z0CHRhqZDqnxzhMhCZ0Za tHbvs8pU3xg8GA8HiX2dRYk9rR/DRIvDAajFMBcCz9O4elY0eKxiBVJSTIntymgx4N0ryDT0 OHDMbOh8QIaIKe7CtniOuh3xD6SbN2qN0MbNtm/kteW6oFBXOYULEbgJmqpS8KALjHJdsGAp 5wNo7WPVv5pQqJlY0sPZoqGTGCZODUXyG82jdWWvUJIlVdc/wYKDyZs6mE3m7Gj/bWB5dLhu cp6aoSL2u4pS8TCsrkLv8jSdwqns65MB8ZYga7bsTz+Q+VfTDHQUr7SMoBQnQHb0L28xuLMq DhGKC9EpF24tCJNXfScfuTq1p2xZxJzK6mLAuhxYtJNBJkRcXlYDr7s5WuUEXiVsAJG4ZmrN wbQUH9F8ywC5IeZFZ+aTk1SoTEV70k8+ZuerFDEmViJcD8WqCVr0FYmZbhRK9oKJkoKAMdvy roBu4HQDdbbiEQbZZsfYFNoDwqqf3Pds36PkIiL3Zboxyp4mRTdHCzr0wrvqnumrBiNJGXhr aRa6YuEvrBBLQpxOPlG+3Wg/QWqiiEjWtVHrQopOXhpFkmHDeEd+8BIjBubuTO79MTo1MDcb MvdrcmAZ31Tyo6BxwT6d7cp0FEB+eudOUP+8IOUEiFwG2YJmgg/ysQeA0AOrAG8QjdgHo5vE jI4jCcLuMtwxc3GdJATvpXhQDKbR7AV8MsX8leK2XJ1wJ7aFLnUuLLmvirqhDnxQzU75af3E vz91Sk7tBm9+vj1DBXqXax3g+kPCtFyc2JW7GuaNzfhrZ0bBKxy60+R6ka5UoSRE4ifWBWpB d0AD3IOUr9zJiLlv+gKBNXhskINUsD+2Scqd6auKIW0y/a3/gHeGdHo6zzU+M1QmDLlCY1XT Fl3rjl3Fvt/l6VCBfbdTOAMpA9o64dEBU4ePFHEKFac3wK12JGZuwnPm+CumrEWQT50Lzdrh oYlYKfMmyoLtUk+ou4gyKZ09LJnQ86k/oweOd6jqHcXn1A735tiyNyZjYD6HoD2Gccw0bI5u tagbC6dmSJPuQwvbzNGonRSX5Igr+dcwLds4Tb27vPjvoaTKtKahjb4S1pLl0UKxYdIZczZX cv8f+9f8OB8tDJNyTPZ5ntA3sXtlTgq7iUrTZM6as0osfKQb4VAdMVVdLY3tfKN4KJxcyVk8 K8xcxZcUUMjjDPZT9/ZCJYjO0cueZLFXn4+11jlKiTqZYB9vko6kxukUklWLG2QXlQSQaZNF BH39cUYFo7bt1zH4nmdSVpN7i5O8UZ+nALfLUPNkxj8Tqz+p/XR6fLDfqL986QFvoOtYco4E zvcd0kFX4iAKtRIRVYMd+3QCXWLjzFQRzbnXHe19vFCjeytD/GvTbHiDdhKCuG1zY1fSON0J uYwvgADXu9Djrn4uEhteo7NfkdKA+yD2K0r1RQdCHZ2X4haNrzXQhZlgFPcifzYa6krBJaxQ Z9Ljvjup5MrUvmp3iRflXAXuRFCRt3C0Y/QyeppVpjcIfHyX5Ytymod+LuRxgVcv7A0drK52 iCqIPR8onH0+AMgUvDr5wsS3IOBXzCfY2b1Nvu6ZkakOQ9EtNUWwUQcNnIN1agf6cOSSTTY5 0+bGhnhasXtVYpeWHOjo9DYc92mHFPJcyomRT1Qh7g8REynSe6RzweqzU74EgtMWGXVH8Z2M zL+I+856fR2mtip2bY39dSb0wFJhJ2B/HoV9qW0vte240CxNtvtiToFHKmTstNxeBTphrZBx +HBnOgwlhXQRbCtHs/X5ltKPJ5FFVpFmpi1BMty7Xy4cpeszHYlqz5KDqQkJwrlbps7AshPr XEq05bAnXOVgO3IvceV2LHisRqL6oKPJPqFO6vtlCecNVa8zS/1D/wNaZYFTbRJrMOlHw2xQ CftS2ePMUtLHK2oQZAGXBBJ2ikeUjB4wP7NafM7OZOZSmUoBYYI6WRsnr+OZbYkeBlf2Gp/Y 98wwQUeIzykqi0LepkdLFdr/xP0xkWFBNI4gMM7i0h/AOAreWAUv8HneWWroWvjUMMOD9JFW at1SBIx7sJxLZ6zKjLxLhDqVrM5Xm5eHc/KNx7yLjsOLKM07twiCSTcfnaWi79pK61vf+QRk XXgMtp4wNUvWQtmMzpG/kZHEqFTI2OK7jFvf2iJi6zvY4RRuRfTNPwWD3SiRS6tgadQRRGLY 70dDtXhwj5izSVJbObm5UxziBv/lJSLNqGHLLc+R7TPjIAIdCQsox7lDaa9pJbadw/wMEM2w xgOLA2UYok2QYSEdG/b3XSFj/C7LGGfs1CxsMZ9Nf4crVDVpcRlLuYwtR1pmLB4o6crMTEaz lXxMTWMy4m9Cd5nRizKtmF2aPm+l/dGJFw0wzpiPc0WwEfci/4kj4FX+KOyTlSVN/QXoBRqQ q+ZZG+Tp0c7x6eu6rx5zPnK7cXUSjDJG98dzsyLBGeZYJ+JRKoYndOZFRmMcCrQbAevZqt04 L1Ki5+zpNS/YoePfbvifuHtVdETHh13TAjNlDua4muW8mRNW6ZoHct6JHAWYwUGhLbBCYU2e w2ydHf14VH9zJC3jzaRe0omebzx9WnhnzY7RilBT17ChL+jw5ks7IJCFSyx3jlYLHAGPRtlX Tm1NqkHA9704XXsvMdHUvDgywGlscBx3SS72oGBHptX37zUElDUyfSdxJbKkcTEOhyGMgcIT 7XTTpKKzlykiC42P8xVddu3jCaLZgDgLo9SQdqzYM4jprmUb2ntxeEomr9TsGvlkHpt0oFEw NPbZQstWAC1e6kRTEiKJFOVuohSWHjYahaDM/XscDa+qxdPLQW/MnV3v8FTi5proRBI5o2Ii VljgSD1SZCZxEhE6oMImP4eEqEExRtiwSP2kcdEcEM8e0eUlZUNA/Yj5kwoyrrvpsSnssXSO +jz9JJlsizBlGjGp3p1fJh9kpnLO/SUYFlR/iN7zKiSr7E6vMLzV/ZFre5GQWDZZW4fZsecB kgzvswDKPaa2oeSdWBfGOtYRpzyWGQS7EncDOLd/X4jCRvUjXKHh8ErHxcyAYGxJ9Atn7PoW lG5fse8MEGMg0QwcFylPAgYaKIywSNnKDg93fMMbvOEusW/Hei8ciASJix3UiYb26kcHP2eg 1QeRq9YSK1TnFxJYxwtOoSO1ZqBpIFZULJcZ6pFDGxegspDRLHtPlz5he4R3bCldEh1Lpcwr s5M6aeB84TtLIno7s/ciAK7U6Vqpn5SdD5GjbVk6g4B/0YU+UEXvhfgAyLawkcqC+/8hjpe8 HyvqWnSOkhkEq3i9W06Sos7qxAGenB3t5q2C1cYQ+g4LYdWdYWZBaqvMvSAjF8ml3A2cNbW0 FfkXMkAdrgwPDmEumadfmczvcsJXOD07SAvs2eWlY3SJJrQ2P3TSQVwO/3FkDh72ti/hcVmx Qs2B6GBxmCDU+8G4F6bvhFWFmfC6JK7w2EE2FRJm7WKYjAcB7OajIajgA10CbTY0BEt0+hxN LinSyRsohHj7ResRuQ7xpAux56fRiFBFy2hFWqFTd7aNdnRToTdZi7V1Qt1FjFmQH30DOy46 HGtw1wjNKfmvy3MEgJghmqeOq7IxKa4K/b2eq9l4gAe0ykOWsKW12bK7zs64KF3NszwHOCxi pE0QrLIK1hEtRp4VwRtKlEqMZddFPwPlyw9vKTgLaIZA6Wd9CslI5xQuKCtDhznCrgRj1YLt bk0tkQbJlO9CMlG5sffo5bmub8k75hy32tpa8CJsvxsPUivsQQ/aVntm19NCOtb5EipmVliw pt7nrjI1OTPskfTk5qyGBe6VXIrCxVSYOUerx0kmNL/rBlKieKSy++mFozJFbxx5JqkiZdpR TdXumTybZU8qPvc2LKMFj7xOaunCttdQmavIHC66tGs5GGV2AaL9W8q8Lq9YZ266ndF1WOLI oQLQa5sEXz26BndTqdsmzDtzuxzW4QhV9rBh81XoqC/n3TEe9YKIFr9l2xMIXeBxw2nDYs9j ugOMc8DmLVj15xy2/oquELfFWsh2CTk6p5ruLjpHbQOCi9Ea5UWdZF9m6aFouk6/UIEUkxb6 QxumaFJCKZ9pei8Uj5SZNZSisaYPqkoK+hClKsGQf+nIRg50tPTGnNZJ+Kb7jsJvbGvkk4Q6 NKXz/E80TCpWn5QTljICVShJ9VUytoEJhwOVpUW7dwngTZuHDChSxuI+ue9T1N98wjAbxcLM M7TrOP35aJfMGrATt0xhzkrGHQhTUzElVXV0eIapjVzO2XYHD8qGqC1yjEfOyCLjVwKF4uhk jqS9HVcnQZLoJhcX+LdEpCBB8RLAsB27t4yuHfo+nGI+DlGwcRhvaZPbjrAl0eTQuGH1oz0M 08sKPs0qz3bgVJnFC9hu8/0DYm8pVB8BrqUNtDaqVpwF5DdYpFUToWb2InyZypwNqT2Psdt2 ryqEcKdRtXWRzFu4gjQRWkCIHLPuCEajZdY1k3DdyGp9Cwwe5gtwX4PME9q6hbnCiM2je84a RD4jEYgjl0Yf+8+PQFLn6pV2FTaMSG52EjhoyttrtVVMPHVTTl2g4qs1lKM4m7RhZPtHTbn/ pC4ls0ePjrJKIsFem9jyKGpr702nvY99N11O6NTc3zM7eFpZ5DNFIbnd+DLKC4fZsonbXeIT 5bKOWsTWIdOEDcX0E4tHFEkCD1xYRvqR5rVM7IhVwNdlaK/8kaOP2U1WtLkJRh93rPFr3pxR iyycKLBxXzg6tcXHVJaiNsm4+HuY9lBqvDnZb9R2z05O69kMXKf+nWad8cd4AyF5jgedcIqt qmqf/GTFju2ks3+032ju7r3IGguxsnOFnoQghVjk7bJB8Nd4CmqFAt1dk86r+KBNDMUPk70W 0LLGLfUMuxI//SOA7bTaheFWd/GSVjbTLTFbaLZMa03xSQkZqRfKImwIasya8UKDmBQRE3nc SO4OnZe15KChOMLsrh+klSFQshEKsdnOf43pQWSo+QWKLA5u9tTA+QClHQA1YmjWgErFI3ZQ Dk1gUXMvMLNzYPciznKohMUkPdH1wszLueokOiI3STYCukfTOe5M6rIpH8LxjQfj3YjAmDdk 3Aq0J1VObzB60kVfZSTQbED36a8onCZMH0+3m/xoYpjoo3rjZf3saA8YQMZ46Uw0+gRw+LaY Nx0KfXlKn1CdlSSokMXNxNVujztBz33WxAPwDYwLSik0bzIhb3ljgllnbU9VBO0zcrlYQGGH aCfPHkjd3NXbkJ82MKakNmZDHST9juzMsSJHPRAOoeh/wvXq2RgDXscSryeVJdphOhSBwWSo Ux6jLpOoBnuuO7A4Ars5SSUFHxsoTThKOhDHQ1x6rtOPJZLHkG5RO3CUZ7d1++dEX3dzndGH oHLHQ3FAHWeuKWQh3R3etu9ZC8XJwXExUuoyojFKlUSQ0y4bGJpdKDsp3s6w41H6h1HWxluc uzA6nrM5d/LOmduC01ivs4wtt7wgqBtU6XBQ9njiFM/ks/cW3CtRdk9kt3dEKUVUDScj+UyM +jq6aF4qcmOK14pZNuI1DOjt27cBX9s09v02aeljmmzO24UD1U6tPgj24mrj2rXj8OLaHqFR g7ZcfDqDhj5kF/3kQ8UHw72AVodIM7JNHvP249HWeos1MoGMmpkPQA6A5LhCeetA191Y+EWp 1wGPeVm65xWIuZm9/4h52j8/+ToZ5vPl+Dd2ru/ZRLo/nZFEyTxm/RvTmpEgLusbIxWFlqOE PX9GctdJZYQ+T8bWTQA1OzSI57ZaVhB/XvIFwDfS57NGK720pIiH4CDqwhrKgp6osGRj5atW VM7231hyngcfovt0sWQkeEByl55M6ipndaAU7vx1p985xRi4HF2kbOWx5+x12WC42U5Oo/lv vsnLP5+H+PlT0vs77Tz97SRqc6766Ru0E+UiHirlvG08mMWDV5JKWYobJkPypQUlme3b2XzV zknLcwqwMwLtRLZu+uqr59Y4MgplxT93dP3mWpH2fWvxJUFOzWdDo4LkkUJ6VX6acLogTUnC /8oakCOikUpAIhOhNEeBEMzn7apQPgMhXEdou29RqZZEk99Qz7KvZZ8jEs2MpJwtOu5GKNJU rWwBT4ScndZODmuHbrkiWUorN0eY/gkF4+1tinOE6Te06xT0om+9CrJxY9Y7kB8vxnG38xMi tLSa3kvvrVY06VU0vUxPS+TifbI8+cNLkPNOoUPIiT7nIUYIu+D2MB6MyM1TPOHDETmG+w4j eRsLdAfNAcRn3+p4kTx75EA+426sGSXqyPBW/PLUdQs6XgTOoL0+XIg2JOX6oUz4Xq/U1VFY bN0rPhLgRByqnsPg2WBx3u6PupKpN2m/U6EJrJSuEuTRbSqb5EW5ZMUU0dm1WJJDRcY7h90I sZvOLjXHI3KiK3jHuHzQOYaVebedhMM0Wr+AXWmfb9L2OO8GjdHxt9qxo0PIsYhymCXE9MJ+ iFsdP5GngmHEFpLmTNY9TpnSPO8sglmd2yEwv2G4N8CUcHEeX+33R6SuHiT9i1Kmrcxixbzl xDiZ6cxstNtRm3mdqdNznMmmgsx6t2tlTBOGsT2xVmJltg87nVRf3cs3++VcDNRGO5C9f2nd bHJMv9s5KwUa3jk+BjK2H9IH1nAkxjD3PEd4Xc5dTk4emoGk21AxE9w7DRNU/QwopfqT4lfV KWOt68HGp0zHoJSLqBlg0yzKtIWu/1Q7obPkTPVaX90SR/J2cUS809qy64AXOdd+6BMCtsNh ZglOoBXxAM8EmLDWH0ezjex+evs302W0NqBvr++G370y+YTJdOiQmhcToxOnkhaE/JlGFBQC N5J6TUNnhlOACASY3Rqa/wWLlvndGGuxZJoPCuOAsK8R29nszZ81q3JyH2Vv4tM1E2sKM9Fj Zpwpc1Iyw0ka2nDf7p82clzB8vpNTgORuVNU2E9nYAXnbShXLBsufcXhLdaee3sbDhxPrvVO BnUjfgITD+TyPmKkBrSwhZivOohuEKbKKJyvOXibGd7KDGDAajMz4L5MjGV71W9PcAc35Ese m+T9NckDOPcGMTVxczdKCH7xNY7PntSZHOrWr/Nx5iImjQOT4Im+PkwwpZDjonW9VnLmpIn5 BprN2aZlDiPP3ovdYE1OGfMOZehSr6wPP92wSZ1KBb4PNsgcrBCEkhyzLGXNv8pQQ2rxxDMP u/QMRyT4+QzvUN9LKZ/ZwQ6DS14/BS1+JpIwfviueWkzz6ig0D+3CUt9hI+N5J4l27BYoGMU RIq3Ep2fx+3Y3jr7nxzLHLScNWLZnzzD18RKn3Kfzj7N+OGpdmK8ltQk+mato9rbRs506EZn mFv8qMOdL2HhZM1/6tMC6f/OW1fqw5nCMv7C+Ti5NjVgRW3MVYYstlqpxwXYwJpZG9hkg1dx 5xFXwELQsiZom3Imhh+dHJz5ZKnTkgTvvfBdtMc/6BphwRAMRbBrOP8uKDwhMXj+sBztImvX zpp2pfkMoJm6mW+gMH0oEIW2jIFlgQdDIGcsPfPqx8Lciws8W3BeFwgITOGYdyh+fLUzvGge o72rRN2tBKxefWNMxd8oW3HuQpiWZD5YBaj6REs7EMydPj53lDOe/f8JjysWcfRQKIRttn0d HVLfMM5iruBgfiYWxKQD5CKUw+snR/voplnNKA/gPDxtduJb7BH8VPr8jAMT8S2WS4hMvvc7 DvFOGeiUQxWbA6aaA+burf3+CnD0IG+qDay3by2i3438XZ7dGcyg43VmUgfEA9fuQ37jUyUB pqS8ya1GvjBYC7pxOip6h5jwxAQWJwo+gC/No+hDyecDSJdcSvurzMj7D+kiquL+pgkyNEWd uTm//Wv2/c8cImJBNzPm3vNca7vuvJ200bm2Wvv5G5x5NzdzbWyyyuK8+9bP2szMupGho3BR x2tH9cPaIXNyvbEpQr/sa7LDzjaBnkiziKHssX/OwLDDDLF4wePn+Kq5VyOHOmQPBQr/dM5Q uK/Dz6oak4lZWcw88CP8LGuFUZ+LBM12Gd8+/GQJSngWHwzRMCuE7JzGDTZyCmS3KXNv1T5H pZk6UxOxVoAxMyZ8t50Z4dws53q76OvsoN3pmGlnOIsUnFl4icbhimrvsvIafDB4GbqtnydD ctjGWPMlDtbEZ5ylcrVazdM+LsMUs6cXKz1zeJ5PEaBOWeXYKPFimd/pgNlyqKyviHZadBVE znEcQDR14tLmXfszs51HsXkiRLu63drOynGavo64z7dEqB2VkiP//a/eZG2UHZWU//0EQ76m Bb3Irv71YBhe9MIS36Isq1hLz1fxoIy2v9XB1erEYpSbYETFFtY76Bjm8gy+ZjIX7pgvFEur 6kBSSZHjKzyKQO66D2tMSnUqq1yoosBB6a9xmS6u0yt/W35m+gyu1ltpp9N69BDmbnB1I21s bG5sPH36+G8bGxub3z7ZsP/CtydbT7ee/G3j282tjY3Hjx4/fQTlt7aePPpbsHEjvfE+43QU DoPgbxfD6GJSuWnv/6Sfe5bLIvoAKA93N7l564pufFdX4h5lyOu02ivtbpimQeNj/3g0DFhN 6UTnQbOJ/KLZZNUEhVbZ6DD4rEqC7DnJs+yL5ANJJg0ubEF7ouasNcMhhu1bW2u++4BfLcir q6vwL/SmyjXQIIYveXTKEVHEJ7petjhBbsCRwHTYdi9uhYkv200oZtCgG+LdVExNi5HOOYIJ Gn906DsVr+fKuhqpUtxzWmSKBQ4d1p1naxfe77sC/bNdhWE0aRgVHnk5eBDI2NXIdV1ja9I4 GwwxsXA0F9ZUHYU3FRDcdmDDuMz990n3PcfDCvGUHlh6a0w+UlZBjhtEO5CRg38TMI9jTrEG c6EyNX1I1geX6I4DkqwXj6YjSXp9PTRxI3NhSapY7pFZGoMdTeqTUUUaU37JOslPolxqjPfP tDEzpOsNudlEV2tZnNYIpejq97s4TLqQSOndQhD86Q+rwdd8mk4rtFI2S7/Ey18gMZ70y2A9 2Onr+6xW/jInjg3WtIvZdGRu32AU+/09+3LsIExT45q390J8SxAc0laq49UM1TXHPnrNtSKv Zsf4SqQx3aTDlpW/BPmg1Jk8+YYnRppSyZYlD7ibRCR3JCEFtpREYeR23deBYBHLCWCb2ir9 nIzVMgm7KSn4FPkLj0fijwY68R3FpJ2gYlVNlzAHHE7JDV1rhd9q1frvqyOgKlqFsAcyjt0r GCIm7EU4x2Xfbwt2PYpOs0xf1lLBUrLp25YHhsr70YcmNFphMBm69mTF5gp+mOpoPDcqj8jy raBBZ5/DfxZA2M66VaF/gbuHxxGyObxJ3eW1qBvQMW1n4UlcmA05MDGXiUQOpcu/dkJxDK/9 kKVPlzI+2rfXYZMVD5M+3WCYyH6ov3Qh4pocV8c4m2VwXFoA7lJkN5qqvH5TAoVhFCmf05x4 kAzHjvXvhYJMxy0WXOksWKDeXQ8NlHAOBtHsxMOZseFWkimP1YE8xUtFl90Qgw2ek2xWAZ51 vPCOimyrsto6Ac/doKwmDLsKkBlF9mltBy3WOs0rccBONCITIvnyzYJCe0jXx2T3Ym48qio+ FhvXwqCK9CgR4GcbN3fh+qMe9QZzD1vXWcy4MQ5/MkTBOdfIpRfXHzp5jKKtbK7Bm1oXGOqZ 4pTrL316azQ6tZzIPyY5d/nOfbyIFOIdZ44IG7TG5+fAbwdJ0iWdV+LpX0rwWAqtz40GF/FF yN8G3XHKHaiqLQaVtnRktwd4gZ12LB+S4Tt1xUFlP5FVbIUIqbBTOOVdlvS/PYoHi3Os8yti JRkFhpsY98fpmLLIjsYqPEyJ08tgB1TLFAaVGCqqVPpanEomw9cnoB1SqECTjNj7X0em7Uhy 2xVhyGbI/x5jSocwwCAWlGpp+GU5mJGw9Ax/Fi9pzU1ZupII3mIiQgVwXdCN+0kmHJTYQgmz M4/WZw+0F36cd5hYpWCQKluyGqwO2MoXqySdXnJhDRbECe3HEcxe6yDtS8Kh83PMCM6BYvt4 VQPo5fE61tGBlwit0DK7B+H9SslKpDJ0WTn8VM9yYc2BcYDzGfh+18Sg4+3Zt5tKSHCtHKzr 2yyczDngknQHVB0MjDm3K8UVCvm6ZDvpnwOLIGQlbTySkRTTEshSgnPam3m9OMkkYaL/tyVU MQsN6QZfSzXXzWSGVLyFvl4J5loZHtfQ6PdeNA/qeLZVe7lzdmDyogVnqcp3yReVBgkM4SoI vXttoAHrbtjw6gd7tVML3A6Og7d0XUw74Bh87IonO0d79UO/YhhA8Q5GJLNtI5ZhxJ4WB97P 9bOjVwVduQLmfJHpzIzUqajr+gQKQrnXCwdzMz+7nkWkubyBljfxLc0EKgEn6KJXkr8WL7B1 OHSRiDW9Ubbz1lDSun6Sc8eR8hSqtCYIdXPj8MWsuLQGdD1s0k56Rx1ZzYxMr9pEExPnYEcz 5uqONgE0LLpZJZuKNg+QIc62RjjGXSFdTvahDSlsRZHzJSt59mR7CeYfH8Vd3/5FUebJboV5 aWjTIMyEDaxiS1HxbpFN5No2OJPolSIIgoMLEnPlVDC5GLG6Pocn4wEoGw0m6FDWRo1mlQCZ +2Y9HkYmb2PwPg79qPocoovGoGuR6nfRT1TIPOwGeViQ2oVMVgc4pHu9WHkWqnS7fD2idHs6 M1F61RQ1EteS4N3AxtN1NIdLeACyc+VO3ixjdRv8LPP3/KPNVHSM4ZMHN9E47q8/sY/PYxwn EHPZxxmh/pg+x1Q+P0b9erMZzifh2bOk0+J1jOkzWtLFiOP273rIMebTWdFiauDc9EfZqAtZ 7OAxJQXPwCvieTbmqmNH90lOaWDG+E0ZLjNpb7LXBSkYiooz2Ioymk5ejHjH5k58kd0UZrG4 59nbuR/XNLkre7ujSYjJfT6DO8mbKTZ3Z9JMagNji2eEevMRcobShHfEV1a2HIX9dDr6xWpP +WAlTMOa00u1U0IFCmtTRg6VeQ/pQeg0h3AuCI8ditUgLdOen4HwxBdBsDJykS0JVHUvn0c1 kN7qrAVOR60h2L2V0tLktEQHVpv2opGGMXQBJY32e469iNN0zC7+ygIa6OD7dhIyictLcX7V EucloQ90xaNYR5lDPy2h1Da86bjzVXJ+ES3QcZjJwXsVjSQ0HbEy1q+UclWehQfqns7A/WDP CUC2BRIf/pXgRzl4hs+cU5kpHLN9GbXfUYaoudimVa0X921mGXnvzRpS1829ECFsiCGugJY7 TidK4YkMDAn5IaIFbTbC4eggzwYM7zjMTS/uc5rk/jqnXHIAYqxmyW3TkWCchpdhVfhvjN2g eRbukMYqVXo3TEfMx1RqSw26qtBAaw3QHXd0piPYgL6sn+zWZHsPBNr2RroS6KTrkYmVgR7p KqY0bLWIUOPRlelQYV9moztT48bOs6mxGU+0+TxOHSI6p9r20UfO+RNS4c0eiFKvrnUk2v4z HYi2vePQ+Y4MoX7VHBuqBSExBOzcEJQ1HTjEkHQMvbkTJRJ3q1q0uEkeq/ZM5xN3+3POBp2L UrMNWKrYI3ZDCOm8WrYFXuK5GdwMgR2+571KNt5+FpuDJI3VxgcYLengHZ2fTBI/kGVx3JLk TaSs06YcsCxgdDw7SgzfNh4y/BoKmp13SEzXiSFkJbCeNincpevNinJOnnVKsLw+fp+kFlJA W0qOFMaci96NhcvGLZwPUYEzU3JI2YVVhDxvDxR0xkOGauXPSlGHtuIhAoK7gHmjUmIB1rN0 rhNOP4BkE4EqhYGYrERHCER8ayxf9LgbZavHlEpTTqF8GFZ9NTqUp34GOSQ+HapR8iKQC7+2 GZJqSiLWPsXWGfjY/0WiDVbkunFKxkI+dIApj61O8PGoiuvGPvBewsLoI8jG7lWugXuFCVJC pwm1oETeP7FNwR6rEsCG+jlKHWaU8AKEufGdzKDVbgxEHhW0M1/kZb+xQeSmuzA9MHGaFcnQ MWQehNRvN5s6AfO5X1VceROY1WJn2FBZAwwWD3bmRSLqUAvB4TVRSO3fBgbFkDsZf3gLz6oj wA0KcWFfUVYD5TzU0bf3yOjVQbbSRk/axIKj6NtNIYESxmPvbCn9aGbEAmLNzTwzYkOYmsNF BTtTez2WZIRmC46LExUYLembCVXBAd1gbhUHhomANXlOjk9qP11nTrDe5DnB1VKdYUa0Tr+I WfmdpoVZ1SLnZffs5KR2ZC+XE534Z26dq1o4wy4kvQGzcrvoDlsw7K67OVyK6Meq7FASFrYy tjBgjDiYH3DQAgPTWds/+mnnYLo6Bg1cTxejaZ1LG+Ma+vAC1S3Y4sZEgOLvGgS1f49jaIZM QImdFIXHqvnZ1IFRa9cbGjKSuUZGFT57YMQUpo4L27resJC9zzUsqvDZw0IJNX1Y2Na1z5ne zzUsqvDZw0ImP31Y2NY1z3qYc82355Y6nz044bDTxyctXtvhYa7hpZzWTo3uMF9mugkKcwUk 90Vt5XRSOsPt85TKfAmpgOQIrqKdgso/p9u1dlm+Rjl/OrNFpDFz0pelc6Uvs0WetW8botpg 7d7k/Eg2BqPhmE6IXjROajUrsRfGNWf5SHOhTB1qotGdMmL0Bhc0OvE3g64Bekjv0s4rDllU xRTA8YZpRqBvtC1nbWfUvlRpsbHnBCAKh/jUmq1+wkXFDML7VkriVMlRZxzRjRAmJN6cvvLS 6wpuqHiCY5p36XEla/3tW+qtRyn6DMbyUVNLkZL8WNnD7SRB2m7hrpg4nTzhCMaa8ywbqKDP B57L4EwVzDTZYIhMzUzPMAmEluvPBK7uuWeCKhFjmI0XZvNB5bHFFdNLYhAmS4XHGzEmvEPf xkFdB+OfOd2TZHvyUjyRjXJalqdZZocyIl3X2Dj/7OhKamKsnYkX1j4nbbHsSAyCzfrwcTw7 ghFGLo4/H8EXn4VgEw1tRr3NTZORNewKpigVRuoSrWWUtHIboGQiMAjCCKc5jIq5FsWdl42a yVHPn/1CRghTA3vLS/fiDx6ws0nV3bET7nBQIKHpwhXlY7Oi8cvjxIS5dza+HiiH6BqXnPhA g6YMBoC5Xi/qIKVi6ppzST3gARI90D+VwF0vHbaCUGaVAUW6+DgXYCrOZMJhRCVDxpOmdpU1 UcjYA2MT9d7ZMVO0OpVx84Owt2DHMjJMmDXWx5zJIkdXd5AeHH/IOYP09DwZnI/m3BULC/YF wOQRKi3Sf+OjJ3Q8dUOV8oJcRLkVyrhu0qwXzLw5U0ArKqV7cNxagSxE9giJiY3DA6OVoNFs M0SxbV7WT2r+jNlKiUa3aCOjfAr3R2TRuyRnlXWSS+JTTFP4qUseaHPh0xqppedkbFTZVZYq tdvVcbQduxrk0rg/xDx8gt7un4UQRhfHuRydzNbvcnjzvkaQB2Ry2g4WjpooLfu+j4Ow0zEX 6nifZmlFcpTFe7VwZG/TrE+DF5rCHDt6KFupnRjHyl2juYcHy7nybabEO1jhGVH4nROjOdx/ eiKUHIz61MT4dTFK1vjPQCiOe4H4dI2voorl2XSdfDu84aUtsbPn9TO82Nvd/UzWHjwY55Gj 7xrgOpWsVehNOtKryvg6qKyr+kCf1wOCTMcw1kgHPNG4V/OD1TOTX8lY6D+EsFtVLIzRqZmP 2m8Dp6RrCRZ/n8HgNb5JH6L2zB5E7RJ73OTExIAXivCI3ABqaU/J3V2OjidFdU4069xeuJ2T jIppjxRPcTtn4w5NgJx7wxzuilulHQWidaUtcC4RKOrBI3orFkiixDt3Ua+hmvHEhBUTkyeD mWIEb+d2Mb6YfHHVVZb5TCTHBOa6gLat4VjebgKbRpP0R3ioKCeqea6fTJuoW1vSjN0lLKI1 uODBEzhGQLADi0WKWaF+1BqKPkbtsX1dTneJ+BABct23X7DMJ+dN7AbAFa9O9uFwPa1141au Ro2BMCeQCl4sIIfY3NN/D8VKhtrWOoJCmbCoi3JHIigph1Pr4gRtDwaDYTIYokJTVnm6rIyT WcyJlQ+1WVKbaJxxv0Pt07TQZR91tY4AlsylwZ09/FJGtPEFC+J/Y6SRNulQRsa9wUiJKqUm np/30eUb2DDeS6YXTFxDDGnQJ7eX0Qf2sgWuBNNK/rpmxZBXk22fULw2zuJZ+51YqFWpLZkp sZOaoXJ4myR9kW9XnB4N6VapY6h77VpLee8FO8HZi1mASs4lgSyu0uLuBciFmisTPRmnuQva fod/JrdDz+vwemEGMAXW50caMNJzGWjgjxVoYGFRBih3/bxkJbUK7t/TlXYqQfiVUlqnFg3B GOyAsVFE1xVRRgSXgiCdkJllJIHllMUCmO/tRh/D3qDLzhSt+AIvh8R0CtKJtO1cAD+uPNra 5EOwLgi0buQX1sofl9+sbD16TFd8uxoc0oB1roQHEVTlMkGNH0uRPZ5puBfi8UgkeYHxiXV3 A/rQosglFPIw6Q04bo1Jq6rQovVt0wvZwqqtPQXdNSdHyJwph6xlSJ6mvDbN9F6fqIjQr8Gt dL0ZoldQWb7DA5zmMul2tOOlq/bzZsDiOnitge6Ak4AlmIDKJ5tbXEafLspVcTaLWiWfPv5R Qds3fdGvcyiDSKHPF8Mj8W/FvnWUe5Cf8ZpVhv2H9aCltAsEz913TUsaILVPV3gCzDQ6BLoC dQ3RBUOjVaFHB6QOOr1dZPPpj7OF/Wja83R9CmmNmjALGL16ThIxFYuCf8jkGoZMh5KkUih1 WDhQwtfxWB1HGC/IpIOjmwkNui/Xx8Nl8/w8xEgZ8+LBVCzAA2aWJTYb9VO8JmNtSMheNQol NbliL6og23BJYQb6d4KRejiVlLbqqiAotnSD0r7nCGpC+x3yRowJgcFNkcR1bHDTEQRwMcRj aNSYL2Hn846X11UyDt71kw98Gvce9HNZaqllPUyVTGUbSx9rDekH8WX4R/vyn7OTPgUnwfP3 qH8ZynZfbsSHdBdzR9Rmun45HJNjPGZplCWqYcT2AT3e+kzUMUhJrZJgPXi0VQ4eBiXpP0Zt b3LWOjUkjj0mz76z7noXBJXwh6IpW7gBWWuu+mFPuASwBWaYdDgf45XumUhck9nnkHgfTc3z EzhXyyFvnLZ0hLRpzqLiPmlwRj5kiZywOWLlcSjnWgnyyopVWPbMAB7+BTYuR8IXw7AdnY8F ldrNgZJQ8yEBuvNfoCdD2o0vLkc2NdFkRACiE+qrnC26OBm3Z54Hwsb1Z2EYUZqkuadB1ytk MyRD6IQK1T4lkHvhkKMwSEL10HV+JXkU8p6XYyLytQjlFnSSPWAyvCrmPYTSkajS+xA297hW u1H/ArYAYpKqqEMmGAe3gyA4DpS1oLQk18WyZYjB9BOeTHfQ3jnS92g0BH3vB/QUBsIZofJb ojssO6e7+/sIYuPjRlgmGkLEDkHFHbHZGPC1npyvC7YQjdFwNqmspuqziKQ7R8RPQyJYyyOQ lzKT/3ccjSP/qFAdBbJxyFgQ2YpG5hk9jwi86gHNIY/JQHnWP0addYZbYWM6Tp5MZiQXx7kH +c3v9K8MULLz+3ec2Cw0RDJMSenoCwijgNHt+uwR4YABAvLRaLL+g2AWHqvQlnQ317JfTr1R 3TSz81k0AX24Bk1QLYru6PMMHCoFo1Grg1YwbPfwTro9SxrZwhYQiNATzFQOEaRVJTQRbwa+ IzwRyvcUtim7QCu8QmF5bm3w8tQcRnqtd6neJNEyBlkZZWMMoH9p0j+PL8ZMiPbmzzpbRYBo BbNAUZYVFtZGUeNjOjM4EXhsbJd4mvrwJJ1RwPAoPotMmHFeg1JUxVxisYPizigolGlpMB4O EttpQfF2rVHBzICa+z7uAEA8qhM4IvR71nVGSgRvfDLVMmfrFG7DeEsBDPy8ywZ1MrBLNFLn UMyWMVG3I3fDyH9CESmp4Pam0IbpXiSkrrCVlyjNCqwsVnrM3CYriaxXrMTHAP1j1T/YLhSj 3jEPBaXCaD6hiC0n+J21NIi7Volx2xYaPMfpoGH57Gj/LfNhmP4o5MBsOlKWJxvV1dG2ivVX 0F2ra9CbPHGsp6Sv7YIV3peQTU12Eh/IAKXnGDqEDgwjKMVBphJlKMrzQ6PZKUXVCzGLIlLI FI7aJ2Hoqt9mUySxLj4Qo9VeVsfNKkBnOxlkvLjta7Net3JUmVmZAFe5Ph8gT7J5eQBXcnzZ 1BnCXotJiW+68vl6jEceKu49WVxAA6MIwe1uFMqtWIdjUmU3/KP4tW3gbACRtOIRXkLj4EAp wIf5rp/cF+PZKLmIsDl2fxuyKC5wg5OGX4jboe6DLiaXdnkTYNaN4mgvLNdgoQ0VkXLv7FgQ eEyevJbPm+VdoIPxRJHcnObjazrylGghgXF8yHXCIbOhOfbOOEdYMKi7ev85pn7DToltVWRI pPPDc+cSqX0JjwBgQAQxERj3fLZzQlU9AIzpJ6qVqq6bwHAmI7lM6PKjcRo5l7zxkFBqGwxS xqphnGKQFrnuW53guNeCtgSGONehTqKdR6tmyk7rJ8p55ZQS1hg8+CfQZhb1jsQ63VBdTqJU AhJxV8K8vpvMCrqXvJKgec7OhZYAKVyho0wKUlkBXvqRfMcMUIHgKhUyIu6DPhK1BocNsMNu yrELdXA03adWdBm+jxOtw2Af0cFDH8Qi1/+AybnD1BmKyefnFtemJcshqWI704hoD2xHNVmR JNP0jlDmj2dTDZY9IZD3DeMImaiOTsGrlnHu+DinLPyQYwgUS4VH25RS/pqvag1qrs4ePzqb COWjczru5DTVqq+8PkguaPrcXtDNEuqjez7QG5PZw12RpHvClOgtu2IfMBA6pqS1cWq6nudk KWwoR0FznDDOKfAGxz7Bg+FxmqrQt/A5FCcOC60UwtJaOjwqKDZMOmMOJQTdxQvDAoODHSXn 7PXQZ7xjNpHulbHeq2DyqXVIY3SmIFDNEpGQrld1lQe2dYzioXBEJWfQfq/9csWnA3mHwSrb 5BVeMXTX+XlEYbi6yu2PTdTrHHVCmTKpGZYapFVo54WqtSoNsYtTe5u2pBhhAmdIMGVbqxxT lc6qwGeqjpuANrhiiGw1YZMZ5kRWeVL76fT4YL9Rf/lSgDVQw0jOkRDfAw3j8uyKB4pQF01+ NdixzZsYgCDWKOf4l44PmL3/EupBxRS9YYXpjDCfAMXr1bMfgthpM/AraYxczDBLcjSEDStM l34ukgtev4uigS8sUV3mw2nyTUpjXICIEjq7oJQoWIxv4FA8WYXdBufd7AeXsGKcSYv77uTQ OXj7qt0lXmD5K3YiqMAaPW0cPN8PQ/1az2S7vOE/Yp7Hg1k6Uuxeufo9UD3FUnfwjEJLrUdA kuDLiXuiQjPzK16v7G/cvqLxqRGojkGRLYVy2HeB5seXo3TA9XDkTr8JarG5sSHH8XwWn9il JLYdejwMx31SqEOeG7ExK6IIJYsbTNX7aGgCbetDDvYox2mIjHhX617LQAygjDP8Okwvr6Mx vs74Hy8Vxt9JYVxqfX96rW9FbIxmJaKtlmw9lg+R1Ob4qUULU8HJPcggxeg6yz1Ho1LrXelh edOUVdRUCkp813W0RqmvdEcJhs+qInNMnlWcINt0r43iBuHiVZ4Tx80VGnKYFKnz5pyOBI9V j1Wb+kbnE+qUvg4ruajVa72EPvQxUSau8E1aaibsV5j1BLcvKj7WpKvNtaqzZLiTK+92aCfk /B4QFeklPmfHg3FbmazU5XVzw8hStL2OarVWd5creY1N7KseDsi4+JyuNCjkbHq0UCG9Oe6P iYw8F3lh6eQJJ+0DJlHQxB3pgOIZZybTn1rvw8ya1qZvjstH84mYFBhq3gndLHrJeonlhG50 iDYd782Op+XiCK9LOsGbnQv0tCzQHS8deVsBHU/H8zXySJq7ZXYuW98pAiCGpZ4+YeqTKEey KZkhjhMjgVGkBrv1lBbC1rc2C936DjTkjEorm1hTl11kIsstnxpGJIX9fjRURI57B0u5Vqq+ GASz90HwwyQsYNWwWJ7JYZ2cEzsDRQ8Tb+YNl/TWmBJTzqmarqwZxXhgcYAMA7IJKczQnWE3 3xUyou+yjGhKJ2ZhQy4b/A5XjmrCWuWW0hNbzk68wAWEND3zItfL28VE0SKXA9o0EveZtGK0 +JF1ayQUKWYZs7U5LVdUGTEocpFWJiyWXhT2aXecpmphaGcMvpGqk2co7ez0aOf49HVdqWcc D9NuRB3wII/W7XquASRgQmuXiWlh2QCA3la4wM2Bnj7G07mMVTRkc73V8+7xmpNR0ylPN/xP DJuuWSz6pEpcz5o/V/LPvVaVymNf0bRSobv3zwHZZ0c/HtXfHOmMAhjmrRM933j6dCPv3jpC Sd39p3YAZt1cH/+RQUEMIqRkwcLDgxB2y1CabZVj0Ktg573E3Mhzj44DSf9F8JVXN8o1vnvk uWii82AnTt9JjBMzkxfjcBhCX+lqy043TSr6apOihdD4ll1RqNk+HjgYfZaT7zYErnYUDQlz XWuLvvfi8JQsDKnZTPD5GTZFUDilEUf0j1FIh2RpY4kHhTj3qMlDCm972BjFtP/3OBpeWekE Io6oABQwpqvD3lmKxAbAW8kYw4Y08Nc7p68rytZTRzAk9RVZyB1XhMqhwTW5OCRADcmeEmGQ tkT9JpwSqxuR87PaEqLY5+Wv4kDobgkXwJ5JZ6hv2QMjMskAyvWAU735ukw+CKatUzgT7f8h eheqa+qyObnCizL3R+7W2OR0t8+oYu88NRneZ76cewq1IjyzMB4D7nlOajsNc018l7UGL+ks DagSUNwkSSCv7yDrqjzqTsKy2x6LdpzW7Skupyub/avmc3SHywqdbPp8VD883DnWdfe4ST4R Xe+FA2GksfHwo7ncqx8d/KxrYbJhl5bOSVdhMyq6aVTZr0dsfkjH+pa6hqIrm3TVHvPQIwDY FyBhyebghXIN2yO8Z0JReMjKnTJvyU6CPaDGa8Dlnpk6rfXuvaCEJF0rYpAyg+CgTdoOFTRF OdrSB4pmohn7ySmcHGcq24Wt0wD7x0zHYpiOOqtOx0/OjnZtqlttDKFPQHir7ozwUlU7IG6F bATEh+Pz/KkgTfVfdA1QhWqQi2Uqn7JJBsCGf41WvCwpfgZePDB3Uu0rqmRQJW6A/xBvxbOb 9iX8LCtWoVcsnStwYOj7wbgXpu9kaYc6JACxY7Ryis4pQQsuhsl4EMBmDDbel/FAl8AtNHXZ Eglq5ct9ATLI64S5KuncVD3h+jm0xwM8KZjL5UdXYT8lHJKTbAg+Z1yEc8CZ0ypJ26O3Q6wH iL6BVGKYlg9HXVKEmoNu2I60ox9mXMRc8iB+Af1n/W78TnL9MAgr04KdW2WsINuuXtQCiWme DoZgwlRgL9HRZV1fYXK2jlx8bS14EbbfjQepF+tf6fnu6Z10pPMlVJw2zVL2mnmlQILOM81U PqM4JJmAL+65YAnnRel3sIkrV8UPjPasReqFI8SVOk+eVaI0ixPeCo1F6Qcjr1MmuKCkDRAs kN1KtAzeoowyepDoP5ZaM20ysP5t5K2HqeAKXj6vHT4V5S1q6MgKSiTDV3PZFco+rUUvONR6 EQY7M9FFD0SPXOSF1cxxUXIT31dMLiRW2XNkH8w5pXTxYlexe5T0SNQA6gdKXdm2okuVYQ4m pJhyu6L3QmxIHMaYgRu4Pt6oBiFEsaOGoDSnI3vwmKDrjbE0Swqt+6TdeCkZUcGgkHqcdcf0 QR2Aqw1hhUJVXiVjBCIrHuRGi7YGEqGCNKQMCJJ8cZ8896pVR0lnVbIwlBepVqc/H+1WJAWP te2lRYJqFlNBMQVUdZgShqU3tHRO0kHj8BBFbzIwIbBkfIphpiZxsH2zn9XFTsJ5ETidfYmm UgKPYNoEO0BAGY/vtNO3Wsc0qWygwSs2dMQqK1vEJe6MrHbbwzC9rOBTo3E4UUh5Ni5Ax2fX QuIMKVQbAQ4FNloMFHQicL8BpYIQIWUUMHY4NnZSpeAZG0r3qqKTNnmJy4iiNbFYlYlszBHV FNb0GQljmAXMxZy4xuhjPz/vIG9UUitgLW51MVqJJLBTDtbKjTcTo4Q4tn2863njqnsefIDJ ddBE16cDfCtuBbSAaY2VswfB/dh3Q3Q5cTGC/T2jmROx0FEvZ3ckgTbSoe9pEeiUryU+ICjr W8DcWwMaa5v+OFEjdNa6KSnolCSzQoH4UT1kOwejjDvWODW70MLQGrMCF/dV+u5LE7/EiGN7 s32TW19kUG9O9hu13bOT07qJsnfq3xWx0r/YfvvjQScs2AtWbcNhlrPZZ5L7R/uN5q5O08cj dm8NEV9tNaP+e7YZTl+m1OG58+RxQKBr5MmbOxmUygVF0SrVAi9ODJUXCtSNYm3nzCK5nz1R nDlitTpZ0IeXOa3jDdqLvor9qknD5O36EzISC/2SFmu2qNZ2WGaJn5OdIDwO4NvvcTqyt2lT ifn28mFROiyHJPNz3QpadJZsqEJ6LJ+ZdXOJryE/VwIVyrGNQVgHSb8j+ilW0BHPncQkK/o+ wmz0y4HqnTjrtCa8lEjKZ8Cl5Wqw5zpsiKsGh0aVyIW8TTWRJcjmjPZUeq6jxiUS1pGuH1D9 TDClKgYAFodZ160HA7jHKkf5WDtoZSH8eZfaHzOe/cW149k7OZT05Vq733GKZm7jseU6X9ot i0LHyW2msIhr52jh+MxzsgisQZOUFV0n6tw8LI4sTpQT2rzhRcJSBSE4WfVomSrZokkv1An5 WKhpf1I5pLICj88ZCbsicbARyryhsP+Ei3A6VcFUXzP5z1y3YqG0Gw4dB004BN7cHsaDEZ1L yFFnSFHdMvYyeznhuUUOALZDqC0kWR3FGGIlWRTc4r4InpoMhqQO0xayw3Zhz36JkGjnKZYv pQN7vVCua+E5ntCTLs0Rm1Q92ZQRGbVhU0s0eY6uszoSnk7GWZVLr24TJhKXMvvGFJvBVeOs EH++mUkHKswz/TtngR1jHiMFX8fDRA/McJhG6xdDjsyHqoIVVo9sujvZyHqBOsGhAffCfniB 3jUkYpU/+FTKPb/mZd35As778eYLlaYdK0Q/3Y/Ihp7P6OpZM4tGrdERMuFow04n1c4/rrqV 40qklSfYk/0pGVj+LcbFbpMxRPjxce3InDIC1UailLjbNFm1Od5aHHJSQ9AwlTewe+w7QV5p EEpukSAW/drLH6EtzE4kWvvI2dewaSNT/6l2QmYBXazWV36XEgPezsiJqz42Udm1K7blkUAf DqWeIXVn00WHchkXaIu++Vp6ZPdHlAbTpQpKim7Y9k86u1duSmLeqXne2bCBlchNZO0ckVuz m0ChPxoWVJaamEDLpGa3txdGqaW0Qi4ISkBPFsqEhmxrGtasiFElMr6qdLJuTcHkaN1OqJjZ N7io477dP21YBuC8fpHdJjLuDoX94Q3ZDLz82vGi8TxjrsvWWD5vn0vm/iidcuwz3eUM4F83 8nU36qsYqtMGM6UXAuu6HQEWikr5wjqj4V23Q+mCO5R+bocwqMMiO6ThXa9DGI5rIT1BQNfr wmWYNmeOZjilFwLrBiPIzxxAvkSRk3PDx9tMhJ/BtiMcpBQBMFVHUG40DD9HBrlhdFM6dLzk HUIEcp0ukZDZ/GVdnfOgk0cnWEWmtGpi8qjIfiq8jr4wpXWzVLYWdCI6jFne2W7engqjLjV3 kja7qBATFyua16dzug49wsQGtowH/EoB7wxGXDhoU0JamvIzkmgnykdYuQSS3jG61LespBg5 mggs5cLJMWQ4UvvAXM/VeZ1EQCL6pHMSIVzc363cTZj7hW65d1r6SdR/D1QKsnOvVetz3lD9 gh1/5QiaP6SnSPkSFHHfUMgP2F/qaK+PN/7+1CtCMFfxKxLOaoVgaccP/sE+hmUX817KAtBq YlLJw+HVOnn36BsmFfEoUltljJJFrKQi5NgMR6OhRazOnTS22+hj/4pk/oHN2wVn1elzPFpt eeNT8D3dG9/XTEe8eZ9034uXk3XILbZVy/9Q7xnMTllQ8VPIl7pReU7VBUO9Cg25Kbc5y8PY ijxAFIgmAJ0yVfnxkCZoe5fStOgJpHItHWsgYBer8VBsn2xrxla7IYXF5svOuhDuHs3FdfgU 5eAjTxHJUij5dtg9y7lO714dhU/L3D+lvAUJ0j8HLa2XuheEjeCoLPtxZbMllHOsTgPKi4eK EXUpeGwQ1M9HUV8lAeL8CZ1IRb3mi+PUDytfC/uiUH/5TrMOMnUZds/XMfik8m7yrqsrW7yB pV0RKRLju0g3X6J43HyZXp6Vrdu+OMpWRJkVnLzk3De5d98HnGPAOlhGyOQ4+DF6iAbjUdyN /6N92E39U3qNjkEdds3HyeE9im0jyByqkF892rztrsASj3v2jUITMrni3/0YRiQrfNuKRaqk A4f91BwFt4QgE441a1MvXoVfF6dhO5NQOj4/j9sxXwrrIYPXIUKd+48hEzs1xdfo3du6QX7O SGWpoJi+fAdzpCIBtEisIhHH6WXkprfTF9D4HjoHjOB+pFhXxJ/eMtpJ5sW5zl3VOvect6gx S8YIrzFQ3yTwLJWmuG2wQns2OZE3jjYU+UG8smlYVIf0HQLTo5xMdMoXRIsBjjGCcQWJNXjt OaTFwc5YhHLMrxDDdyDREnMccQi2khWxrKwS27xIbGCF7bkXZpXVia2Q8TD/Iq7mNe6y4mAb nHDGXJfUoVY/UFyQyVceDbCcu4/mCuKEK4+Z2G78IacKS89yu/Fdxb4DmQZ8bfFbda/gKrKS /hF5VvR1QblvWA1eJx+QNVTY19C47+uLjdb9WovPSkg2r+VyXn7ivLMw/uSkvJIXirWZWUC4 0POKdSmpom8D5l9sNPAU+xBgEh7UXI6L+45myurPuRtwKHBiDpWzFx40xtzWUgsnVo+mWFAY J8VpW2RzNMPeyM7EYnZIwMmae60KQ8lsibwkLZsr/Lm37nyCl2dHu439+lHw5gStlCenwXrm s7KCnUdZCVgrFe3peFekSmWPeOgQjy4mh/9KgFh7cT8Zso4yIM/BIeAcmby6bG8ujViiwKSJ cJLi+LtH6UYecqy9Yg4+fto52d95cVCbjI9mUxpoNkm9b1etJyvt9ynwIX5O31eAIn4CWIDn 5uHO/9RP5KX/2Cm3f5RbDh/b5Y53Gruvs+XosV3utHGyf/QqW5CfY8nDnbdQ7VXt1BTSj9R7 EDz1kz2vhDzEMnsvGlDhpLG/c2DKWA+xzNsddStKl9CPVsyVKf3SvOGLUOaNXIzSd4PMG7kr ZLmcmXfaCU19xwxV3mt8ZL1/lXn9Sr89PK7XD7z39EyXaLw98t7DkxUW42hSNS/lgfWu+XKn YePSeUwjf3ukPI/N6PUzLHF2WmvWjn7aP6lb3bAeemWaJ/V6I7cgvVmR3F579TcWOPUE3x6f 7P/kTKA8UL3N9lX1lPv9Zme/4Y8Fn2GJl/WTXQsy/cTntbe7FpLw14q+Amchj6/EWVeyrHbU JS2VuwzW2Zk3Qn6mS+zVXu6cHTS8MvJUl6of7NVO/UL8UJc52Tnaqx96ZfihLvNz/ezoVRaS eryitp/mPe9G1eUQ/Zi0WaVEOpQFOqW5umGRAD9Y4Xg+1ro+O5ZnGOPHeU5Bf4zXhNPI2eGK LbitdxKzZc8JgWYXMHHR9sztdVNA32ffU6l+9SvOLW3O4swLPu/bUxmELfRxRmHkQK9ruz8e 1/ePrLbMMypRPzo9O7SZFj+gd2cnB6cWOvm3vKEAPPYrShiMpE0pZA2lUy5e/HJwZk8m/cTn GDTxRb1hvVJP1FtvvvUjfP8/MJDmfqNmTZV+tLJn5bTVr3V+4D0TXch+SZlqkUidF+rpUe2t 9RR/qacuiakn+u1RPfuenrF8MCdUlpAwh5x7LzK80vDJ4/rpPqlChnHJE+ZqtZ9sllb7SXHp k71dWIMNh8jVQ6LTmk2iNfUM1/ermvOGH+n37nyd2vNluXKbErZ/N/ysH7882Hl1CiL61BJv 9lMaweEbq+eHb1hq7dYPjw9qNhrNM5lx0m+dKacn6i2dHzpv8YnFOzkzZIZ58mOLCzdeAVYa tT2vpHnBsyouuda88hPCxMGe0ncsRJiHhIezI5GttsAwD3N0RRCNJwHg5eBsr5ajJoqueK/g zdyflXuWk1FMqTyjvpV74fTN/ivrVk56GXbkcj7dOoLq2h6ADjv993g9BE202losG5m9KOwc JO13b4bhQJkS+A5DO+wDGHUtgDauvfAdh6c2zkGUeJOO053EDnwLB7uRjORmSoYadI7RtLpy D4ruQwNXTnzHUUSXo5X9F/BQCslW2Gnhq+rgioo8Rs8RAMBJaNBZiXOB0aY+RbvhleSYIwNT qxrz6A9/3tPa4z3aeJzHfXWzJnrPwR66o9hEIFW2FdmA7qLNcYy2tXsS6eko2ZNwiIAkPOXR kFSYRDH49cajLt2C0n5oAIMNI44bmzndRxTtJoOrIWXaKe2Wg62NjY2g9j7uBq+ifkyhedAs sRO8iEZo1GgksB8eJh+o6kHcjvpptK2sSBxng64tpsn5CDZNSDo/J2NyZGNnLTxgkXcqiTVA cj8q34A5V7AzCDwcRp0Yz5RaYwn9m0gukDQDidq7xCv1aCDoURZjDITbVl4HIV0aVOYSsojm dokwRHtK60b5ECn0MtH3y53RiY05A0mPXnt+j8jll28wUgj2IQY+Ibf26CP6MdKpwjADCamQ Yu3hXOxQT7aDV8PoAm+tH1eD0x5S5PcX8OQflM5qGLfRwa4KhPvDAvnKCnVADrvoHhNGWk27 UTQwi5rCIeDhI1u40aVRBZsnBxeAsMoeXmmn03pU7bQUxLVVgM82arzpL08J/EqTW3kuPzGq C39DmwMvjuZh3D/FZw2s/TzYrG48fPo4CO6pi4gMAggBzQej4ChII+BunVTnB0arzlVqAQw/ egBpOu6JVznDM8bBQoBkFlFrG5llyQSUnGAlma1GJy0H6x4HlXYRjjUvKmWFFbhVDbW6smKv 7NDp7UAfvAp3RzlArFvM6XTdXhgtB0sDYibXzrh/jpasSHokyWa7FIAn7is0SeTXjGxHSJrR 0+EEGtY6Xoha7Mr2ijkNpTtb3vFqzpGrg90Oum1WgDCTZJU9N5+vtsLhahlnG12X0GWJ3iId 0ys1S/SXhjRiMsmlRyrFAZVKm2UrmTGgxc1sLGYnNlGZWS/yaJDrJmRgrASRCys+D0rRLxu/ Bl8+z2C37GVUprZdwyWC7wKGswV5OZb0sMuZEveQpSV9kd94KIBhqVVCW1o5o7gXZerZmDTf 14KtTEnMEq0L/BDkr9ps1/1GcutllbjPYJs+O7cEcbscbP7979+iobuRjABRuwmGZe8GpyI8 MpXNB2OynLC0OonSaPg+6iyy09DyISkowREw8200Y3M8XFSd6PWeOJcDfW4H11Y5MyPcH9Gd WBLhYXAefTDn9c69ZQyvjnRFPDADhbsat0Bvk1ye1BHMekuCx2hfqBqpY5c96B5pOZtbDze/ fQgz8+32k43tre+OD5eK0B9MEcrRZ2EZzarS4lFo2EreR0GX55SvglE0jX2OFcExEOXgGOMY 8W0iHeMGl8CL4FF1o/qR/MMwogBGWK9+W/0ozh9UrRWB2hPQgXqJ1Bt7JZUBCuKFsusZ3FC0 qehLwgDsIOfQ9vB/C+MCK3xwxftc+s7GjB1lMDXG0hXx6rvUYQ35ysPz++37JoTh00owuEAf JoxrKJlS8Ssl64QvDrvW2dqxBKfYxm+X6iYFM3eQA+SE8/x5cH943zB8dmHjLkqHWaPoOjU+ 5FTZyCmYV84LFOdWaM9boZ/feScqGMpjy0eRDl9F9q9yHRMFScL/AFIq2P0KdgmXMDS0yvoS 6UovxDutQ25mGucl/c1+rV3QeBbtV5Linv/YLzhZ1aXOVqWem4zM8td9ydls6V/1wiKtPRUp kQN2EoE553adBYrwdXW22RpNoW6HflsjHcLTIeVe+BH0SUQl/aKM2PLLqW9WiiL+Jcn/mUhe 5t9+YbKxm2n33xN1lAyR5FO/eHbeGvkT/Q/789D/sJ9P/1m69up1oz6+pVSI+IVjYVHVsLNc BX+uVSBUYL/QObLpX+8NpkZGCvAeq5yn9Md7h5lz4b/8hUJnIbe4UP52e5/B1Tpb0R7aKuVi 29jY3ICV/fhvoF9vfvtkw/6Ln283vt38G/wH+vfjR4+fPoLyj55ubvwt2FhsN/I/oKaHwyD4 GyrDk8pNe/8n/SxtFEsbxdJGsbRRLG0USxvFUlVd2iiWNoolyS9tFEsbxXIVLG0UExfK771x XX4W8nHsP+xpeNv2n8dPN7/17T9Pvv12af+5jc/SZXjpMrx0GV5aoZYuw0uX4aXL8NJleOky /Lu6DN+6/mfr/+0qsIwbaGOK/r+xsbXl6f9bTzYeLfX/2/jU3h7XTxqnKxiuJB4BDSw39nfq Y69/2aEsvA1c/99++6Rg/W/CXn/D3/9vPnmyXP+38bn35cNxOnzYivsPB1egbfUXeLCKJgEV 2C7VAT2NBs5b0QU299nH5YcY2RBqVajmchf6B9uFzu0kwBu7D5fQVge+yOaOf1XoLyBKdn/a ZCKlGvRgRW08ST+ztpBWxFa0BAHOxsOg5BBaORiDTKWhy/yOxTb2Poy7HFMQCSYerWiFXKCe jPu4dHg3hd9eJ71oL0YfBfUKU+Y0+9HHUbMTD5u495WDjl7yr6SJjTb56EWOe5pNaKupauPO ckXU+H1qs4bK/HZ+UYZwL9jTma45UCaNzWyKov77eJj0KRirSq8jcXg5+aE3FNrbgNbL9j18 9xIQE3VKpyOYGthlUp9gzxAMoABaAhb0ob0x9n2z1Gkh6p6v0i/gSo9gK4bf+8nzzQqGWByG yhEj0JtkGTiGU9ShJSlAqJUr+kMyfBe8j0PONUC81QTCVVu4wRAeBasPHjxgiF93AtgvYmxo 7gPvRoNMHOCI95YWOt0IvcF/5aeOPqQeWIGk/msNr6wPzCSCsHPKxEiaEBHYg8V1f7l/GXW7 yf1fAzxfTIbdzpf31Zs3/JNevcZSleD+ijrvxLOxThn3j1uBfxpoqAR2zpryJMwjpvHtRj05 /qN4oDCgKgUrL9vQ8cksDWB+4uGQgmG7cWdhT7kaPAgYMQRBge9Qurv7IWWmoei0QMSjL+9T c5jHZXKLmKtLJfWTXTlWWl3x4DNqCajCLTJrG7VfWrid3Ggr7Eh6Euj1uN8pGh5awMy0CoVI zknVbjlnGjdIEtFvmQx5PLFXOp8lpaIg+ZA/0R1JuK3Whv1LVhjoB0H9x9Wb4CFbDg/ZIh5i 8YoDjIBN3IVTyqHE0lZ8k6JFcQSHK6l1Jwxpy2FIssAJTnllkSO7JwHnxUjxAgThu2jIArHE f3CA95gkzoPhuM+x7635XGiHFKofOah+JOwaNfgROVCMksHzJ6C5WegnDbSbsF5DwW8pIwpl Jadw7WNO6DiMYozsyLZCdLrV0awLeDXnyma4sCI5+PtgDIIZGPhn822LTc/DmtlZzI3VzhbZ JAEAv30iy7QVoJ2O5xBF4QUqjiMpPAzQ2TP4OMSk4iVCcAWxa88wgPzlIzJw0FNLolSVyoFl AP0F33wsYxkubHESlRdljgY182OwxEKkE541M8tLaOaFycEc6q49WFVBblcfWH2U5vSgfgg2 qk+fPvXa0bxPOuQxSv0tuiVO9NhZHo9lecDG/moQPXdktyQ/f/7IXykpHjKEXSv7eaATpeuz Pp0Efa81YXFYJ5EYlZlq67WBc0n9Qtcgq2sWhgXkL/T811XjUeRXpJiD2Xr4WFdLs2L3J6SF mjgX0baGFoKbb447hUubWtHqnUgeIlSx6dK5FP6jqDp3/ZMr0btmJ8L0ZiUegB3MsRyQGZtS i5sDFm0wDriipNxYlB5oPaKDbl1LhMtsDAhnpah5JaWUyOhdMWWUOs87eRxckSioXZwJNDvB VImPnrHkqlXF5lGa7b3rY3ziiyTpePyPvNSHEfF+c6Rzj7JlhSC0++1LZPKYWiK1IM/CsqQP k/kk4QTQlHM2xIylIjDKdu9gnWI2ddx2otSpmAj/PZOCsef09x17IvgtsTLsdvoer4P2ZdR+ 91C0MFJ8abPzIZIEBlHHqQWLE1kp9LaqsvPAVJXelfPOffD6S9wfu6cxHF0520dMRRu8K/ut YXGRAtyQLwrwM10cwF9fEAg4v0FHImzlNJbtuiTatnsvFBxJkuos/bIq2MWc3s+DX351hSQT nF4iztxRnSo735TEhlEC0gT8PVdrznVD5bO957/d79yn39uBV0B97uvuwW4i+FhQiNYBFVij dVxUKhncx7ZKHx9slqnkp8AWoGwtpKM7woI1wssqtVGatfS/krhf0qzHlcu27CI2HnXDQRp1 tnE2DD8P1g2nvyVZ/sSR5U+UZcKX247Yd1nxc1slVBUVyawEi+/yU6fLT29HO2cCEz8AO3kP S3ScQ+fQPEdREdONXXvROnyxiNVhv50HGMf7ekK42ECTI4kxpepzGBD8bVK6VO0rjTloV4F/ wwSuEpdcpUS0ZVWtGrYSWoMT4fwuuw7quys4vb6DwO/FDgNxtyPFw7nGNoXb/qPtVQpm0yBk hg3MQhkI2hBsprYpvWELi/n+yPr+2Pr+xPr+1LX94BVicszUiac6mKcE9yPIX66Qf8eYMgPX EKZZeB7cbzbxIKXZVIYzAdUQlqEPsbYdrhJw1jQ7M4X/jrM02M/Jv5Nf2qkdZFo9W7yZVH0O MJQvpV9WdbdwuKu/lnM3P4hofcrvnP/iniNd/AnwZP+Px/Ayc/77+NHS/+NWPrnnv3zMaflj e4cbAVGKOc2APVLcxZ0z8HU8JAQIeOhxzIce6iIx3iI2dfBET2Uvuf/Vfmc7sAiw8j7YrG5u 0Cnsw40nDx9tBBtPt59sbT95ijmTLoLax0Hw1X08eUvlqEiO11J1YCeZJNWvqzRzxtY+jtvv usLa6Ct0RT0sOhoDQKB+dqLhsPphCDvCkrXmqPd4tInpIbeB2Yy7nf79kdeedPSf/dWy3Rvu geqvOrJUvz92ht24VXBSuaZKDSPESBtIGv21BR8Fbq/m2A27DfoNjrHw4A059PEwOo8/7iaw sRjQV0uPM7l30Bc1JtdJ7QRKqZEw747YjmhmAoah1DI56uiGvVYHilSCwXMusB2kv2zjycEA 7YjPgwF3Bq3q1BVMMAkQc/uie8CbVjyRpH6Iuhj2g9P/exDcP9j/sXYfunUlxMAdrAbBLqXD g41uP4UhvY9IJf06wLzbnEoMQHaCNrrDspIp7gE46SpVH9r845G6tkaHgsoTQlYVaiN0LyGN UldXvRdEaTsc6ONDaLF9GQ5BRwUpQSXwZ9ocJU0pCGupuvagVP7l1/9zX6ssWAi1Fr+wkQmC RNaqcOyc6jxS2K1Q3Upw/5//vP8Av5alf3RRY4gJbVGlQ3QQNlZmA3r/a7y1V12771xVG0ZV vvsQle7/v/cfSOkH97+6jym8qvuvjuontd2d01q5SrPJDuJknKCLHzrJnUlyH41C/AEFm7RK SdKTfSIgWd/APEzNo53D2imKfBgYbSMlV58sbHIjxYyArZVmO+mOe/2U8N3crR+cHR6pmqaB B1QcG7EifSjAAoGIWYEjgwnVx6Un6GBe+0AX4uFCv9LIZDzkUzvcHsWqRjpuGXMljlwyxGKP 93YaO80qdxf6+IBBU38fDJMPccftNQMkDDb5NY37pP5mfw/BCBR6lTvocT/+91jluEeSjMK2 lbfP/twLAIxy2aWGYSGW+olk8Ux5bjtl6UkTSAPvUkKPvqPackAIADBfoErtpXrAvWd6FNwj XIP4Ck5MhcvlTQL14gEWsn5RaYaWUnJUnKs8wLNBdCCFXR9SERCuxlixmi0cCuNCeq8fOI17 wAqhME9WE97E9SY4LqUWZ/6JTZY66+cF8NS+kgedJOLNjYAhFyWsqFavmjau3yMnL1YnIjHe ahXCLH3YHQ91clTDWdGNm5nSeQxCBH3cPcYA+yg8oAZa/aciVL+GLMgZSmJ3ZigmU/WDdzLO GN/MVeb53YaW5iDoRaBLqWwyQLp0p8wFlwn+5SyWaKQZwfagLd/lvrsx2AgGTRvmDvJ88DS0 OiY71pOFQHSySwJlK48d5XxkcsmeMQ/8gGkaw+HFGD2PUr7ZgRc09CU8IClOnpoMq/ZI9Pfe lX0jnS/YqXdAK5Ll091Rmzrq23+9++80x5gckXN5+4m81SvvTCh7IOScB5mjoPB9Enfw2mEW ohiFeDZM95z++xYqzzzl2qYsw1TZxoya39lw49z11x0GrZRuz6jel/3X1jX7Pcr5VeYLVhhw qDMedGPqAUqXGNb+L1oDp/zuoEWOu8GHh5qP/JoB71GxsaBJ59V9er+iqoLn2/LVPqHZh0UX h934P5ERZnxJjbWAWLwp6e4TJgtWC8FGMHJE50BBdVoOWPI4lzsXubXpdMmvWZFdSLUz7g3S 0i+/VoLNsnPo1Kjv1dXJE91BE/Gqen4/1Wj+Px66mtya0Zx++7RizgMpOT0aRDKOJLBMj8lS 4iSpJiWvk4w50XAnao0vLmDO7TUt9pU1+QQEBVnCMPxg5Xm2qweqsIHSHpMGK2iDXylskwyF Zm5SERpF1XIwD1WB0w/TkXuIxdezNnNOkrj///sbQNwmiJ/+N1NmYmvoHFp0Z6vTisym1iI3 eW6ub+l0V7Nc3MJWlfOVmVuKOxeRyBAJZDQiFqDObNvF/YLrAkxl1xY7hEMbK07/1Ab3BW1p cYiwGwu7uIW+4jTHKcpkJIMEoAzxniGhIM2XFCBkccODBywl3S3Yl9KDX361KIOMyEd2vucM sdzjA1Y6hAj7GMLP3nLQdpPbELZB0dWSvgeDC+vEz7TPVZe4xVEuJcWBUrJX/SnPVduUvpc/ 6a7vBHoPGua2bRT/oQRsDCzIqw5E2p7yCHGDKrwh22pRN7lGXj8n9NVC6dTOuuRNFZF3y9Yx Z+PmY3cy73YhFuPbNtKgtwqTh0PFXl+Z/LRC4B9lGOrhvbImuvupmZDzZEZB4g7DEyOCI5Ql curg9SDsdDwBqYJG0BME6w5NPYUBSkvdJOyAcpDXQfIcyEo66AjHzTl8Uy7ng1fH6DkTm9uS OujPbYxUFnGk2KTc6nw1+oN2kVeeoZhhcja0T5HfeiBFqHcgm4Oxcg4hER+bU5ZgzSxB+8dN 6pNH6Eoabf5qqwpNnG1Zek2kUluqeMIkdnWwPE0EjyVtDi9Mmcrb3LeYjY+gGGM+9eWwS4VZ dnG78jmXmYz77BlFHfIywbuo+oV+/OovO2v4zgkiHalFH3hb60p+IIKMW5cW/SLcjckmiDt4 pfs8job2REkBdT0FP6xNoc4sL315+0oi0EAbcino6eP1FqgE2Mz+njo2cCuVACCIChMiFa81 ff/0cQAVycLEoPpRmno12foLPHUA24MR277QY0urn+jpH0Wd9Et3MWDQCbb5V4/D9rto6C2W QXUAj5uoL+N/6rigqg6B17Y2H3/7+LtHTx9/W15UTZgTsvwN6OZRa3x+Tt3yETwO8WZXpExu iBS8ggdMXm/HUXgKh88obfjJLDD8FLLBXNGftYNR94ENItkZ9m+l7HVHO8NyxE/eklQZaE8n qSVuY07YO/XR9L1pkCwGHxrMirvY9skjz11ngAVkb94yk5JSBqeAC60LDFmAbIi1RbFZejrm D5qgH6i7I3jUJE2ComxzUC6Rr1LPoinPthPO4a+zqlQeF8xT02k8MJC4I5o6WrFtEZHX4xw2 qn0jC5VsqZSRczmaiKtBC/Llkk2+Il3QK2HuoAOMgS/MolgXYJCrbgerD/6Xv/6vj0284xTm 83c5HMOwK8kHV3bJwYN03QgWQcqs2q/XF/ZjpanFngglu2Sfz6UM5nkNoX+wPQfkL5w7CbbS TQ1+LrPLOWqgbrFBOb+S6vIfXjEsxIfWtwvOPObSLwOjYO6Jo5RrqpBj7fT5b588dirlMyWR ofI79h03h+D68MOYmXStQA751emXLrJmFyKboeVQB4PHC3L9fI1VNrnYdPZ8nm5g450C6Zh1 1oJMPDSdVCZ2MkywJOIj/VaSdKOwX8DefV6u0MDzlpo1fUp3uBUi0fxoIdNfuLKXwkVLPSa0 hd2uPlm1ixurYzHnyyxu5jhx3+9wMXfNkWSFWHDrZAnc4VvZFaE6OYv1JIM0Pc0wksLSk9Zc YSX8TGNHOQxnljYL17nlyzgRXhEjw8+M6h5+ChmY+kxiZPhh/W8enjnz3lhWUJ6VdTIPc5ee y8PE/zpSl1XbetFpCMbnRvk3YBFuef0H9mTthYMBHfQqrhXbCuGapt/YBiORPZnIiWRBMDPr wbih5xaarPqs41vMQIcj4KoYUMJu+C/BVm9J4YzPfUzn3u2Zk9/OKBNyaHkuC8o0JUA+li1I +TtcRtxH9Ie0CdSmZn+X5ssNVi6dsxE9wGlL1luvuh4u0DNxeyJ/MqIkfkkEJRpIidLAlHNW bB65yyxYBI6lzAAvk25HEbaRwFoc8QEnB000m8AUYyGE5koa+3GQQ57xBjEj/vMv0bn3jddd wjMu36lL11u2kxatq3soIz85MukJVKEeZuVTs25Br739vOdQeGpTYJoE5+jiaAiGLcOprmJP q30oZ5GYJiLexYZsVjTHeIZMsvwOj8P1AKN/AVlGHfttcM+4+8ljakHCOokrpOnjzoCjSOuF QzddHTmKjkcgYflC54ewb45Zppx6C431xz0otb6ZQxQW62LdVBNF/rbYgWj9eBBsepSOjmly +jbZ2Q6Jx9szgAITdcaDbUAa+uh24z5AEJiWqkBelN0kGeQLvsnKdhq+j9CAwSXkbH6TWoc3 LokwJ8mYAmeFukEqPX6ny7rk/YpgU+L+eEd8ull1ogdBGo1O8KZTxeA9q9KyzR1esZ+2KUn+ 2mbC8hXmexzSpK1NMLDl0jvgou2JsgVho+uuI+j2r/k7C+E63srSbFV5SU7YOxEEi6w/gIjQ 4VsC8enWrycAortHUQdvOnY6xCFgLeKpAHMiOnosrC7jMN2gJSc/SuxoWDwK7gBf7eazFjT0 Ks8p2epabGnCOBgUjpm8WuimQIV9KD4ge2ZMY4EpIHgyMUw+Rq9PRzS+S1wrrHB1ZugCujvE yTilXkTpxBp6HTO3cZ0tJ1TSXNbS6GYmH/vjAfmF/vzKImCGfuSwgs9p9xeGg+07W7q8TwFz 8j/eIjMDZGfhz4AOw//sKcALjfmomFh1yqBy687gnuUy/+sfOk04B6beZ86c8KNDMNiC33hw qYf3QD+4jxcqUGMU4YJ+dKBCVYKLcNgKL0jH70aKjfPadzw3EO0eDu0WlBTA2BUcxZJ2HVEa 411YW3FR0sGq7Hjz6a2a6qNhphKUzDhuZ9a+tvvx2RndOchu5IpN+/OY5OJz1YYm4snHLs6U 5b0sNDLiR9qy1nuhp8LnmPfybV5z2NcENfNSuB5mLqUXIyFjrZ24+Z+yxbd29nvDZDDBMeUk 6iV0owylbzxUJ01a9ckcOc17Yjr7EZhlFBbSzbhcTbbLZo9d82y8uXuKPH8w6Q+a72jH42yw 4lTdx5K+0o6cTqo9dzV2jnK3Cjm3aZw6xd64M+rJOTB5UKRzdezTIHWfzD1ZV5/43KjUeiRl WgtmYPkroYXx+jJvMp3mzkzCviiBtK9oXRX1Ng/P/sWhJZInliKJO2ldUm/IM9I9HWRvyd/P Q3JIXGzpIZk5CBfqupYxnvIMFZvN57F3L9wL8/eOV7D8LPaTjf+x+CwQU/I/bD791s//An+X +R9u5XPD+R92OMxTOsZ0XGpzpm7tZKKH6CgVy5wQy5wQN5UT4l7gRJsRdkcRZ76dEnBmYryZ RUWYyY0Hw5FdyEacDetiUlFU9LBuPCkFJZjotJp0S/tPnpXCGwtfr6IQWivqlVzzpciG6+yY h+ENJTSOBCwTPat3xRzuuQlpZK7Ml8xhmVwZfm63oe7QP7f7pC/Ub6oAdWFLdQiRscmWAdAT 5en9dpJ0JWVByoFgHPuA9LBKNgoBJsHCGPm647YmaEXgDeWmgwLk3dnkkfwiHZJLkaqs8T7n Yr9JsW1XN39U3Xy8+eTvqJl/kmHfUyDMbWF5I267z3Ujxm3E64vrBqWbRu1dNQMPOQyts3Xi Jn7Z+NUbFl8ILUmlHwLqtzrzxUff06OtcmARy9bvQywv4mEn/VJTy4YiFbqkAbIYFtF99XIT XyJrxnybwDHOu1f/R7/cwpenePgVKfoihnKO8R5/0b1G/G548/od77Wwhe3gfj+5T9+34Ptx 1L8Yx/37nyoTAaxvFkJojIews5oG4O9O/SsYgQZwerL+7SboAd2w/a4FyLrPJzKy6fqd1tAG 95U7+asJRakC5SjMZ/vmLzWoMc+C2frVINJbNYBTidX1cdtdJx8pgMl3ajHJfWm0sHCbdFua E2tyAGdZVZqc6NhYE4M1KgElVTYzVTKTx7PRndRMps4c7akuSjPO4ZUEH+C6z1crwf/yV3OF n3faq2+GqMLJdCjvRFiiVs6L35VV/G6Efz/E4GAt/KeN/3Twn+i+J0yynbgu1OKBZgQWANkO Vleppsdbfvnt8faTSvB0+9tP8Po8Se7/ytzm/jnW+X+iYbL6qeyT2Ma86CvubGYdexKP+gSc bnPr0f1FdWQyou4/3mKcb9P1+1VCPXzvRdFA4fD+y/F//nMVfOB/ycGyFYVD1cMpDTz5Du0J uhEM8b9Kc4stdkPdYgtXuW7yXDeGYRFmbOo7slnM25Q9utge3BS15p5srTh4oDqN+pDQseaM fJyJPWRiL2Do1Es77h519X65yuZ8qu8W+H9/2Vj/+68PvrovQfg+2cpQltvLaPogsbqYK0fM vHieLIkKeF8KOjyFhNanaC9elFrlTLyrFvFfRP59lxvomzg8eGeMOGEvXkhHZ8BbqPlD676/ iBBfenlYgTF5pu+XJ6Jj035nSaYOyxVjSJ5pcoumFMlQRHR7O2gTxnDJ3b9W31rcN1rAVGTF RG2eHCGZe67iqfuhnef9vvUZ3x9d87s1MnEwAhxMjRh9/djN2i4xUwTnz/sY++9h+C5C1WEx cO3P5PjPW0+ePM7k//72yebS/nsbHxMRoWOyDYXd7hUfNCqiqA6GERpNe/A7BR48qK7MUbNK 0TgDWDdpexgPRlj5rB9jrHPYH8O3j7o4bWwkcHT0cYSRd4GdQfnn83zQ+nV6iTarfQn8J1By LMTwdLMavBhjKN+QUh8CRXS7qhOlzeoTtHj2ow/RsIw936qC7gLdDdbPs6NMktEqlHkkZfA7 2oFFgqP8I8/GEJ6E6NjUjVvDEEMaolkZdwLTOowFubNrVm/XOLVymMZt1XHst20vrgbBKSUr jQCClME4h4c1wnlstYsRV8mqLdHoUUZ7I12Rw3Y8kmWXaatdvHo1uAyDRxpx1TL2W4f3oJk+ JTqKOT70FVoq9YSLDTkQisBAf6n0HLNqhjo07yFbQx8aWFDjmWRljZxB4QOMfnWPbP06prkY QJFyYTpW00HYW8WzCGqafnKJahu0uZisISv3TIxSlQkNXck5IyJWCex6QgJoRmkxlaWcoklM ufgbbfHogK8uzKS4C9MBLwM6S/kX+sYq6onwKs2I29URdbUuJVAcrFTFJKybGiXSHxf3fL3J Jc+KuiYfrtzjJi2fHOoXdZpjpyAS1rj+GvyQWK8cGZ7byvbrKBlFJi4sd2swTDBFAzQ1QOdk XQn6Td8rcpQR9SmsNq4WokMuGAT7I4opi47+CRAyhWvnlxwhVAPEqC6X6FmCmcgSBEMOKtBV dHoUXKre4JUvHS4wO5oK4bcX4kmKwnIESpk0jASJGZjEPji4QpJqhXhHKDGAujCzQ6TUEqWu kPMl9r5MqAEkJr24I38GI+ADsDahDTywgI0+1iQlAuuxAyc7tQkFwnco3h6NiX+71NG6Inrv of0cx4wxF5EEUofKZPA4AVgAhywXYpBTDGNAV9iFSanJC0EHkFoXhqTjdpM7/RXwyb46Z0GC S/gALBVGhYdjESWDZeqktlNhMYjTkeYdpcM4bT/0eFdZB5/RC8yQM8DweBGCBYVtCtNXLIst KqkuhLMItNMZo1u9K0+RBrRMJAd4PBLtAe5wZdOgyjKJ0L/z+KLaJqeYZDhIMKixXDjSiXuH lJ2Aw+ZX6Hv0MWo3+QGuRGwPniqurl2JRIjAHAgPb8V4tQ6G9FJF48Do7rDIKpLaYWCXY699 PFXpM+4G4eiSbufKTIRxN8VQwHy8WIRGrQL8VDs53a8fPUcJJl2DmXr+PQ/kB1qgGAhRPUAy kksA8FMTkyfIlZBjaDgtlLA1SdO4hRkf417cDTn+CKHNbtnC4w9lzbC2hSRo/uVUMpVn7W7S akXDVTydxICTaTruRSp7HnIfQBSAwaqwisOBYhvM4IUdBQPgBCjw8HQVwbC7VUrOeerKA50L jjBXIS8Di83jaSstYs2rJnL5oIRlUHWyORon8BIZr/h6uYK7ENFxcCnyqPktcJUUFR/NQkg4 uE1xX4PcnuIdTKVMsrx555NmUEKYnKoz6Y5HoqQw9QnSFPdHHsjpPN1OxJRrDNcEcEhMFJYC 8vudK9y5WUISqluc1hCROLqnmOUUOu10z0YP1OfVsmoRTg2lNSWcw5ZIQPjLIRkqMUekgUsM YAIERrUqvgoL7xyDycBLEsc8J9TWa2Ao295w6HD3p+OdxuuKliQ0wwGFXA+i3mB0RShrGfZI WALiLEXVi2p521nG1arPX4mqg3TYxrVTrXJr8AXT5KEeH7zQVP8epoG9eUuIBFy4l8NkfHFp Ly00TJBK3/AWOewpuBjKBDUtMLmhfF/lRAtDxa9WrDX9Bfq9KKDW+ra8XVkNW/G5gap4CsTW toUIYonGSq7/ePSci3cS7KgR0mE0rXelJHBWBzTwsYRFekZPQOQipL5yAjDk5TozrKJtibel uaikCrvQmzQR5CRIcIGNUWTKLH3xRXWFpwm/yTT9pCdH+4sgh1ID4jwzGFmxBKsp6l7pecI0 MtC1slr+lH5ypbFz8qrWgAZkMpBPacHjCpQSTQItb5gJIicGUl45/rnxGmSDDWWn0+Fg1Ov7 NAfre0EyYIUBcbay+/Jg59UpVPmqVD9ulKHYV6X9o92Ds73a8c/8s/a2tms9+qq0V3t5Whby kCkxtEqqPN6EoUXDqgwgpBdBF61da5VYKT4Jcavxy9ajX6srL3ZOawf7L55/Qd9Oa42zY/ie wTjCtvfbjNrD+l79xf/AUPAbQIFvX5UO6rs7B/Ibu45w1U8FeA9ooi/3gMNOhyncA27Deb5i QXlO9r7T1zsntT14dIrnT21WHb8qndbLK40fiXS2Yemtj96tvDp4vbP74/P1vXY3CofPm81X B/RN5o7KflXarZ/UzIPyivv7OU7BaYNeQSP7jZp8PdzZfQ2TpF409t7sH8kP7kZ5xSryfBul wbquBn0VqM9XFNDnK3v6GRc7beAMASb3j+AL/i6vmKf6UXbWSKPiJTYGeiwpZqa1PFkiSsP5 AlScld1dIM2LdnvlYP/oR/oByNktr5y+2m/uvNh//sU/5Ns/VoB84fX6RbBe31o52BO6hm8H O6f45h/87R8rSL5Ycu/1zk+15m796OX+q+brFSaZL9a7nW4QrHcHnEoKHx/S4x5+xR6snOwc EZV+MQz7mHlK8Pf8C2BM449bK6d15BSwWzrYY8J4jkMI1kXCrnfbMC71Zv38eH+XhveyfqIf viXBPgzWo4/IwNY7V/2wF2O93ecXDx5Y/EExffKbG7YvY8yTAAhej/udCEP0omsPaRQrXBL6 prj0NBA+AEsUwOL6jb99UlP9Mv4Io+tYq0lbmyJoRMkOEkolSlQqyjYeeZyHoCuovUc3gS0R KCRQrSJRboBjt8IOTPzr2sEBDgG9MlPMb4TuZ8DZsGmRNhhtBMhzb/+E6MWTUWWsinPpvJes XQ95PnVdu1ov7K8IH6TX7lvZeq2c7p7sHzekgA0VeroXjSiPJV7dA8WIQ5J7vZYVRMyL+lgW 59OvSrIyyitWGd1cTjHNtLGg6XlOSYfFP8/DmQwvty/H+WiGQWeLY78VlTtM5GEKZLeO8VfD C3TRQ7gHBBi/lR8y51gRPqn5O5aipvyWqiGIhJ0flRTRRTVjp7cv9w9q1ku9MWWusGu9UrtM 9Wr/KOclGv+kQfOSZODKyunPp1avD1EaIUMBVrmzJ5JLV+HBVBOlkiRIPcfACMQ7mJetbI5L hqkqm07Y/RBepcHFGK0y5KaK1HDa2MG1o1sROMCXgvU2rVN3B6D3rmYPTBsdnOkxdwVzf+DW lpYz7J/xXtEzAAVaFeYLAN0IN0rQN2UdAXnfHqEdBVd1Be+vqL7GHACi54NHTWGnmyYV5Byy r+8FyJvXeY8T4V0m3E+h8Y9S2MedKKyCTi1DbmqC+02efArWe8GTJ09c1jUke48wrT3Fkki3 UhYMUtrSzF6J1LEV4WLbX5itnrFIR8DsrjB4xsUKoHL7iy94Hxfklc2AJ9np7lGVr6upv43s QCsiZQNO7Rm9baJlpiwATbW2kZRZPy2v6G/YmNBtGTtaDYGezdosG12blS54WF7hRYGCnKif ZTQvBEv8lYN/QslgCnwpgzVJs7Haga+Wyqf+yvqTmutJoMdCfUHdAHAmpO7M4RdfxOxuFHwZ rHcC1r5UX5+xlRWBftF7B4wv856Mi6PhOILv5zGUWydzC6rHbwNnyp6hzzlBUg1+9VWMF+7e PuPH1BTycpuuy1TKafUhPJEq5/KlQyfniiRIyoq5YSodEPqJDETHxplcH/Zwh0vv4Gc4DNpD PVF2ua9KrC/JNK6oFKqwJ08tNXtt9CFuR2tqN4gd1JsAS6ngpcAsVXFdTWvbXzg2RN58MF0Q HKIMJROYHM1PoQvvXG+9HaA6Liy/LDDX+z5YD2TZNuLBrK7Ho3V23iC1axQN+2FXeAtF7Rv3 LVzoJJgRei2QLWTFgrF9Ez2n2xzvIi1xjAVUo5nNt+72SE1Csv2FlpCipGPzssKhL/qtsqHR 0QIeX3SsOUULyRoy0zXJRqMk2lU04lweK1QOUdDGueU9etkccom0ldGwBdeyHDsoyjuMXbF/ b2csT3q3Ah1AhXb93DJTm+741X6wH+gTWBBzJLl6qqsI0eRqQ7tdn4+xVo4l5etK7bltuH79 /DMOmg+eO3zXQRr2REalbMYSFGc6BnUT20KmqGXB2iB8EauEfU1wfzN9WF17uBn/858PB/f1 06306+ra1/eCr15/bT19+P+qbeHD1Hz/Jfji17V/lqpr/wT18et/yONf/vHr1//c/PqhUx32 TVgT/niVdncLyqsKfo17/4AV09zlevg6U1f2qlhdvnpt8tPcdnEXixXxr1cLHuVWUXtdak++ +w3y49zqtB3GuvTFq4jP8htFVZZH+CLbHDwrqnWoah3m1DosqqWw+SIHly/yMSm7dKwnX72a /DS3rtrRY2X13astj3Orn9apJvzxKp3WC2ZQNFSeQvmRmUN+XkCuFgT9I0PqEyB8dUB14Y9X 66uD/PKMHfiji+IPWLv4KFO6xqVrdukala7ZpS1+Efxg8dqofZkEq7wcLx48eNhZDX7Ie2+b otOvEb63T/+6oGLGkC21s/vaIghiLdbNfqGlQVENNirbFehJYXml69pD0/pvUSVlU7XqKD15 UhXexXqVWFXwqqFOqc8sxJyNVmlQCPicb+ULxa//V6nwpBGsmtuBz8SP0DqB/WX70a+r/0u6 qzUtM0GQ7Olc2Z/YmSBYIlbAWGpdsZT/SayzPI3qlEeXJz1N4eKrr+QbPbU6CKq7/kHv/BF8 9ZX3hEpp0wWebdFRnaVdcjyd7BE6HQmgi8V4kK6gHZp0S1Ht10AJXPv/4M/gqh10Ws0PMMGs vxXAN1tcPhTBu6rsbTGM9FHLilAFkge0ZzcXAsiLNGiApAoyuj2pG2bLZuthGkCa4D/dIE2a 2i9iZbYO84Vf1DTVEY452FzBr4wdQ9OqVa3ks1KrfUar0Fr14j8rK/e0kwrinwyVbKxAx5th 3OlEqOaJpt3r4YygxsdXf0d8W5j84sm0ITaGarCOTpcrp2/2Xz1PP6BhTM9QgO7X1RinDF3S Q7zCiz/YoA0/gJp/w4qfyCTdST4E63LEtN5J2hLjd/1Uzk7XO33UQhEk4HKEEc1gf6w6svLF P3jXqwcOT0Az95eGeNNpNV2lXea+UW+lm/l9xmOVKnpVd1pyK9n4mFvf1Ts9KzkbQk1auknB m1HkndGgD+x6+z/nmbl1SiE1DM+dR8RPM5XULoqs7UCJQFdpxOe/J+zyRpn1zD6LrfBmgpNt iwXp3j8L9KZrV9kF8Pjutxe1kx9rB7WfMTbM/sknZcl1d2c5AFfcg6ztQGMqeUYWE92Kfg4N HmQbhG1/sN7ttNDm4h2O/d4evpM/Wf9vpKLFtjHF//vxo6dPPP/vR08ebyz9v2/js/TiXnpx L724l17cSy/upRf30ot76cW99OJeenEvvbiXXtxLL+6lF/fSi/uGvbib8q1p3Lmb8q05j+f2 0g156Ya8dENeuiEv3ZCXbshLN+SlG/LSDXnphrx0Q166IS/dkJduyEs35KUb8tINeemGvHRD XrohL92Ql27ISzfkpRvyXXdD/r2dLv9AH+P/SzN2I21M9v/d2Nja2vDjPz/afLr0/72Nz73g lViDgc3gkUmqE7qJT2WauCfScmxKSftWtIcgetJPdMU3a3+S//xyad7yx6x/xasX38aU9f/4 ybe+///Wt1vL/J+38nm4NvkCAGUHNceLm9UnQij2QZwbGT5Ye7gCYNfX1oNd+ndtvs+Kyde5 +fe/b67DP0+whVPo2OWI/S/xYAo6mrYvg92oPxqOe5Vgpwc6ybAT9ior6A10FOG5WBeUPPSm Cwo+6Jp7wjkuT6D/w/egNq8cg+4ep2SYZxt5hbx8K5yO84r9zSx3Mje7Jzn0j9IVUPDIushn z5LzU+f4xFLKz/Y8IkcfdHOBcV5gFsyoU1kZDJP3MSmxyqU6bKEu3db46SeAk4huU4VDcv2C 4YintcrzCTvE0SWDyFakMtD0wIzYh7kirkmIeGdIFd0E9Y1ybKPwyJ+nFZkn9IjbfbNPf5QL rKDniL6GXZoJyrq6jycR8BS9JZPhyu7RyT65Q4H8IVMpjrgDuj20QGcqoBuPW924HY+ucEjq rGWUrNh3KNS1Az1jah7YcTluVwJ0M4cdBO5ToV2DHaCkN+RWjkMQh1U6LglxK0SeZOfK2VaB BzxJHlfosWy5V1C+hiAWddZN5aw2F1JWSoiSsvLO59MO2HeFnc6QUvqNBtsPH8K/VXXMPbyA IZw29ndfN/aPXgWHsHuuwT/7p7uvg93aUePk7DDYOdoLCNV78PhgZx+eHBwEb3ZOTnaOGvu1 0+DNfuP1yknt1c7JXtCoB43X+6fBaf1lA4rUKgF7NyB0rLZ/eHywX9uzq9dfrhzWTnZfw8+d F/sH+42fqcmX+42j2ukpAgiO6kHtJ+hOcPoageR3eEV1uH7C/X1RCw72d14c1IKX8Gjn6Ofg 9Li2u79zgDBBz6jtNqhs/ei09n/PoDK8WtnbOdx5hb3iGurnm9c7jdM6dOIENlSnZwfU+suT +mFwUD/FMQRnpzDYvZ3GDlRdOT6pQ/+h829e16CHJziIHfj/bgPtDlAaGm2cwM9KcFR7dbD/ qna0W8M261h6pVE/gYJnp1IBmNnJ/im2WD9rYO06AQQYRzWGiFMAiK9hL6j92gmM+XCHoL50 pwRmfE4WnPN5uIJM/VDu2YgbBJOpvPvyyy/1f+beD1om2CdUCNycvckO0K4noEx1OTHllcae CrB6Sflcj/W5aRX5Ozrp0U6X3sb9Uhn5A1udQEwR7HtKHV3lA/rqJaZwxXPYYT94n8QdgoA2 lI+l8rPMiwHsKHOfJ2mcWyGNL2Dt4hsSievBzh6eP58BiR7ugAp8EmziU+yaXfX46jAcgmrd beJizwMMwyKofDMqoC0+oCdoHl9x4lyqCU9++TV4Hvy2svLFb6s0LLz/pIb4qYKPcVDyFL/K QxyReorf+TGPR57zD3hRNLYtNbYv1JzKnmK1Syw97q+ym0uPRwubAygNzchvaMfFBLalYQmM EYNQ8ywQ4Kf0Er6ZahHlAx6Rpwfloo4kHTeaIoVumtzJJgs0BqeSOwHMo7ODA0ZGU1Ga9xxg md/U8Cnduom6DG2jEmx8Wvn07I+w2TH6v96gLbyNifr/k81HTx8/8u//bnz77VL/v43Pw7WV YC3AUyCyZSrLMzzD/wwfppyMzvbAdknH5GRA5XR5htScN0PUH4ekIZJWch6CaiQ7DVhuJTSK lrHST3KNabO6GZTYY+a77x6VVQ/QE4/8Vs2moNQu48bgCW4MvuNeRuoiMip+IB/ORuEltY2v TtAiPkqV1ueW3A2hx8mwH4dVas7owTBy0cRdE7V1L43uWuDWpw/jCpS6jnCojGjSw6hHEiwG SdYeVdXI9hJSZfmeEd0UStkpV6Cvr6unKml5N0lHX0LVFeKpK/fIVScKEJW79b0acuF9dFE3 m47tgA9gWPZZ5fkx1FjMB8fz1esIFNrhdvCw/T4dJsnoITYE0/oQjeZNs4dULpfph4vKe7rg DBP594ebmw83ngRbm9uPn2xvPsIMmf/pRlfochx8hfALoLTPLxglQCGiKigXf7pzRFeR6IoY nckEo6tBBJiN2vSmTV6P8+5QCz+2hvE9W/erlz84zzromgXP4OE5GtmbzfagO07xPyXkV3dX QWLfi/qwZ8jXWGCm7XsBKMDexP1O8iF9SPfw2ZUdBwhdgobYqyvqlJpv9o8ebZWD//7XPOJn zWaZLgTZhQ9Pd5ugAMOLLyzaqb09Bm21FJah752o3cVdU6nT7XKjZbpdzDkLoZ4NrvmifnIA mv4utfWFpPjMgg2DJsOCQgKmuCyWYURho/yNK02owuXUFODr5quD+gvYDdiL5LQB+4zdkzPY JxzWsKYDRzUzqYI4g5oWkfqwSVHbfgO9FVY5yJ811Daewc/jq3rrX3izd620dhGNmuFoNCyX UO8r42s8Ni2tpfqFKQ6vP/EiuegmrbALq+BZpkF6D29wZSRc8Ter0ebr2s4e/HbBwPKAf1PV PH36mSe98CM/+5TTitJ/F/FBXd9uoTmMBkPJmPty3G/rrbOctOHroBfB9w4WWUwniKNqX181 ByvZfuVgfO19eQWx/h408/eIQ8lqe3x1Siyj+XKY9PhrafX7VzQN5t7SD6s404vDZwaddgbi YzqnR9sIWpZEgl64PWLLz8JQa2MWGl/J6VsuTiusxaydDypElOfd8CJFRAuRxoDtDcQ2vYAf 9JceENTzEtRc9bEd/Bas0sLjaAKl9+s/IJX/Ev9appXj1v4aFX9TZP0HSkv+jPPBPnjwTCWG dcDYACrS2ievW8Gnf/b5jdDKxiJpIEMCwHiQvawE+IaVQLWwLjB9s76wjiQRGkpAQcsdTPm+ NLC+wLCXKnzf75PrM16sxDsJ95Vqk7CkZkNWJ4T2gXPRvXlObExWPigBKEmgyf641wJpjjs3 jlexIPKbZV0LdorIkBj6Wp/XuEN59GYU9Qa/bG599+uzlUlkhVQCQ2vDPt8nqEqfUjVvqKKa KEprdlEjPYQCP9l0iD9SoTDsUmV1N7Owv+bLp+fJuN+pAm32yyyhasNh8zQaCYuC3x/bzSPo GCWIryA0m1RxI7xAas0QayrTwRzLpdZ0ArVWF0QzExlWOhOtVCxaGzDh+LTikdIN0o1RLga/ L+FsEtUwZslQc3zVAKYgiBJkEptACxdQl6vHNPeP9hulb7hSE/8pBxyiZpupRDm8Y0gMfbOq F7Yv6dY2zGouQECf84FSG5iCfVU6BMMt/KANCvuLs4G/qY00/k+UnOdQSLliV3xBYaGwsKq4 MaElq+I+3hTjavNV3ItA6KNzV4IK6kMcaYknHpZXOUdpqKiarDbIh5osCdPMqSpvKlgRncbw h1UxLayYWhVPMxVnHORowG5QQ43WEuptOc3h44pTkTRLaRH/navVMG2KEJuzu1CxFw4GsILm rHgZppequ2h+xCWjg3llNs3CpVCRxltCFM2IWF12p2NtQuhtsx99EKzxzoU4Wh4L5Mgbiqnp X8dXh1GveVR7k7MqKpvEI6zlX01aTWED9mp/JiM/DkftS4ddiA7BZRn93PT6DxYoqwY2iPyl eXzVPIo+nETnwI767ajE1crQ1B4wE2J6eElS3A77EQabwotfThu0d3LHvP6DbJ/g8dPH9nN5 WMpsycrAqnB5lp4+XrNZiFWmXPYh/bLxq98wjHgYnbf7ehZgjG/3j3ZPai9L9swGaqyGQZv3 9utPeSTCZEDEEXY6ijgsqadlIQqqFdzwT9gJVybsgwflYnKj3dZ7hU3vZTkYPFv5YkUr6DxN PzxHhV7NzvqmEp7v7SnbWjM/n6nXE2ZuyJxVSeiKqT15Kp3NA8py1K2MOFc7hnTUiYbDyiqi G4TdS9Cmu0GEMpZOxPi8Ov6PFfBGotypTQZ+oo/xqLRpaQD4n9ITFHp+zRugpszcsfBIMoBY RUFwTAcGyGjYjfol2kk94P6gfjO4KhXAqOhNV04BRUjQkPpaUDI1JVO3JJVgZSgPHwvdmukP G8NzbJj4YqEtqUNYoh5lNmX7EV58h7eeUekU5vd4NCRmaixazofNW1mptKc2ekoj8qo9tC1M 1gcowoeG4A6i/sXoUgLPoOTCCDK9+D9kDS8zODpC9ZoprcF+dMTMBS1pSnLI4PElLha9rbB6 l4ODtX70cZQz2AMOgdWN05HGqzvYTzYcFtCmD20Ozlg4Db8V4AoV6JzenFLwIOAmwAo65aAV uzVpcPao1PPRIIN5G1d4hIHFTU8NuBzCoIn/ZevJ01+fOeDQK7Vv7AA+eRSCQ80o6rgAAVzt 3+MYBorxVfIoTaN+F7EsyDdbOoWHw/BjwALaHTs+V6fK7GjFPrLt8RDUBIzBcBlhqNeHOTCP EAYyDQ+fu1xXGzrOdQt+z7MwT/GeTQ5MmXI0fEHxTtzm8IMpFp8I8xRDi/mzpGGyYQa9BPg4 As2EgMI0H6azUtQP0jy5x7hHop/WZXm1WiI1jW2ELnyK5qyjAijigYdlkm/u7uy+rp3u/z+1 IPgu583hzumPoEN//NbunqYC8+sXFxjiwUcSldvvd6KPLAS81wfARKgIvyUOi4jn3UecotFa 8Rd3BlB+4hxh9BFgHcykcGlsol+i+2gLtYEvHBx3NlGqOo/KtLJgf+2V3CoouQUlRecT20Jn U4RtZ0tbOVnqnUQXMTpiopEu+mCWMHlpkBePll68oShQFgPWFhW4Q97yiHaAsUgRjtYaow/8 kzHh8fOy5o3xM4+rrdFCqayNNskcB/3f4T0v+8TrU0OOBnPuq/Sojn1pEzE0RfROWpNH3T5m RcExzEUpf1a5spiDuW+vhskHyxNKd0HzEtBWDTilGFrcC1VV8/PZLL1UuqrWy+zylZk6H5As LrHxKoiD7zXze4ZWpRzTld3GL/GvVSI1Nem+FQun8BuvhtJiW9D9d64OS3M2UtWzlVXfHjwQ KCOtm6oe6OfAilA/ZBV15Nj74RcSodpVMRhQDNQDNae7uBIkYGnMeobi9DS/YumT2jauFLJG Su/lRSDoMfjBsrQerD7hH4UjXtm2qQ9LSINqBkd5XMTV8zMzP9rUmJO+qacu3jYtxOEPr4/0 XmHOFiorNlJhBbuvfGEo/IniLoR6ZbNhWG7iTeVGWBlgylpou/x3gLYofsPzQNtQ5uP0+DL6 +Mvmt7hHWMU7To+fPP32u7+HrTZIpVUc6LiPLnWoImIMedgSp/rUgHfXv2w9/rUSrA2f4fhw Z8KPsdQAp8cBAPtZ3rLg/A+CH8ySEZJynkFPAcIg+AaE4bmijLXSEJfnc+p5qhfVgEr+8EPw 2CaaNezQ/eb9Z3YbQ2RJYhrQQNsMFKCvr8tq4S0d0GmF5AMzDo7n85tfYBV3veqcjCfVOfeF jd2II9C6k5w7u4qr8fy+ikbO9PLEOjPL1gVvqpzTHbIgkbZUMef6pJnHFdy5VDhUawXdFTLy KB1UUMWWx0YTWaMNABtfRMAiyA6JrYFiKpYiLvoQBRbj0LAkgbtRSOF5x6CoDFMKq6rFyFob IyDBFCqiwIEjXYkcVZzMYtTtisyG8GRlGVJolRoctlzxkjZvnlEv/zgahrB3AfqSSaJbJ2re bAbYQYppO/yvg8R1fwO6+803WOB7+PX3++WyRaZA5N9/HzwuBw+wwDqVtrpkgQkdMOeTwZSg +PrmRtmC5Qgclv9tc2LiY3KgFiaJov/+VyN0VGmXnz9H9p2DSk/jOCV/G0bIv0lD1PAdIa3F bSXIYdUVrWCWpd++tAZSFkFtNgMxsjEtxt1q6vH6Jtb/geHAUreql2CCy0GunP9l89cyAo89 qFtPngi4TQFnCzirZ+ubvwJns7taZkXXev/ceW+zMVdsbD7LxYi7G7CQw5sFGAnyfSPqidhf xkNYi6T5ynYewfbQPE1RtM9SWK9dlH38lhdEmPLy1fsg2fzKVuIba4ti7zJoTDN12ywogrn+ A3Udl4IhSX5BQloWuvW+rd7z5jujf1hglQ+E095owCK/rFfJWuZVuYTvtHGygM2YGbR3WyXn wYNN6Ly3AzRs7UunbFmjWWPZ5mcE7oE1w8Spe3FKcwozepAk73QsbNr3yMmNrcAzc36eWRwj WAg0iyAmCl4/2KQC6SCjxBLQX9WepgH7lVESwN4XQxRS7xzeyl0AvgdNedp4nykgHYiSiV9A hvk6uKh5qpiaJ9HzuI56OBqokqJf4sfrJarAV2zCGw8pYqVlDaKuayWjNBrQphc7POKWkEkA u6DHmlhA/HzxaeULMR5rQV0ZDbT6+QUNOBzZbx+gxAZg6wIbizkCUJc1OPlC26jd1WlMBL9W ebEAt382U3FC/ogLF5cSrrM5pRjNAGoZdilluvAeZNfKF7wXjUZZ/eqLXEn3BVNT3jrPLvAv clc3zpz02qWbT9bCTweKvxBBm6VpKOBTQPriUfRBDjjXWyEai1Hxk8EoK0yVvQTGKadWUUcl YSslnQXt7nJ0FGsPdzxXdLzkQclSh4UE5D76d9+no2oOeIJQzgMJDsLw0mrBOavgw1ZV661/ WWdfUD9XZ9W7EVM0hbK4o239S+uupPGlZs/wpXZIpD1qCcpqri7VtX8E9GYHxiSeHdiPVRzp qnVs9SXW0WrN6qp2JiFa0G3tpAKEilunjbaCDnUqOEDZK3zKdaf+pN1uXcMfHoBRp+Bvp9X2 3ir78Cq8WrX9uTvst+05h60F3SZn7mheRt1BNDRnohIFp2KVTRT+zKMgSLYsJEmEfDEjuZ8V 9UXC68D0idwz2qx6hRhtHiV9tkjpmvBwr0Znu+r1s2lQ83ri9Ueo5QD2JUIrMgwjIPiToIWR 3z1zXui2BQos0NJG2S0jr3Yod2RJITfZYqbBB9cyOHqo6n1amQghwfp2XcfrSYhP9flTDgGM FkUAzrNHz1b+GlTRGA+60eeTBYNButjM0AW/O41G6OukKWNDiCNLB8mjLMjcIfigk0cMVhU3 gQVyh2B1/zT69xilQHM3IQ0j2QIwj9SOy50E7PUU3FqFH02lV74i2sQgTx/NuenDh7zZLmRs nRb55XlHPg/FgtYXjwLtOMQmzHY0kGBg0u7h1d6LZu3oJ5ly/oHAm1H//TP1rPH2aI1EZ2MY 9sWHQh1msqO234s0fI+HvOTMzUG7YVGXyk7NcHQSne/2Ry68djcBkf+MXKCsTuoOrjlNdVra QmUPZy3oXekB2AsXP/QKRSv1VAvdVXOktWrFc1AgnU6qjzX4KYMmS5T1wa3+s1yYNgKU7APt bvfH5t4LjF5a6l11WhVqRjs7loISPS6v/8DNw/6PCrD1Qr2jkWeLlB1M72pU7zq4BombwfUa 41PNwqShgF7XY+NuH+/dMXmKioaR6MI4FSrFN6xlZYgeIewx4eM+C8uWjQmSztmpE3hz7Bnp TcDm6bz/k8CVG9eqh78hee8f7dYPjw9qjZr21lt1Hm8Hp1f9dtCJO+iRile70svV4FPFBfNj 7efa4XHjZ8vlb9V6vE33Hd9FVw9xqxQMwnhIFzc7UTfCe4wJ/+xjMD4VHC2/kbf7p42cRvBx XiNhF2PHXfEJRpoFeVBH2qrt7OGXigbpPN6G3TIdCb6LKf8BxQ5Mk+57jEwVdrrwsgDwUb3x CmNL1PYqNmDzmEEH476OtlEJ+sn6hzBGd71RFixUfVk/O9rzUKAebwc/OsPXvs5BqVZ/Wc7C qx/sNSUGZcWCZz3eDurj0Xpyvt7Bo0eJEpIFBDuBk9puHSr9bAOyHm8HxztH+7tfBpTtcBi1 MfbhVTAexd14FEf+5Kz//e85/qOrZ0c/HtXfHAW1k5P6yZdffqlrfcouQ7HT8VLgDyyExsdR tmh/3KOVhUcNYonkNVMOHroPftn4tWwpQPAw+N62Nyjb1nO0bH2v4TomrcDpDTQpoGPYAFs7 SBmFtPLcLoaLvGyfIRIKLGlrHVA4LQGrICgIUotnWz6D/KbLzj/hzrm0WorT8moF61cEiJyn P0SrIC2GQZim0rWAM1UxQzMilzJnUEKrkdx6xfqjiA8VVVg3La97nIkWdWGxA3EISI6M0IlT LIVNIxTMU4juKKoIp5jiCJ10ZBm2LxMMuHQ/VUPkA4iq7ckADL3VpJmicYsnhBJBOEKAP6YC QbC+9d23WyT13r59Sx7KWAXXmspv9CIavgPWhrKbuXo/MdBOao2zk6Pm/ssmEHGpTNSebR8q PVNzr/emdGMFJswDdbxzeoqA8uA4fX82BdBR/aiGgIAIxNFWq90WfeADlGoPEf9kighVCuWh HOKorHHsbqwjwGLEVeBFsEIwXSlW7yWAN6oGLzjriwRC4ohRHcmQq0N0lIGY3rDHhjSGYKI+ 0USF8qahbxc0jBoIp2y0pgOUgHiY9Dm4/jiV6qjnvcbwpAFJoQg686VKHolJeqmgDYZyM/cw N6P0A6EkQ53G12rG6RPmeKB7ZK2mkh3CAa8wjpQeiZWAT5frRJiTi2I9Mer3+6B/4JVqoHSy 46ARKOiMw+56ezAOWslHnbURO2mWEfUelx8voORiGPaCko6qWuYDOWu4j6ob1SdPKsHrndPX ZO1E2xTms8S8DbR/IFCqq7jS/j2Oaf3ZI2Vq0H1KUM0cjiTdVxtdENE2leL4gheNk1rNagsU EFpiEv4LKlNqQ+g9oKuXqmC4D42X1eHPelq1FcZ+5pR7UXu1f9TcOTiov5H3p8QKs4+fuRVr R3vZapmHz9Sl7A/hkNNovuQ1ULAAVqf37rdp/fjkXyefdqM/c7uQgm40ReZb1jzMGWnfDIMt XeqbD4K1oMnH62LJE1uefmyEMDwCCBuWVEbLtf9+03u/4RfY8gpsipimDJfP6c8zOiKn1vBg gpv5pB9uqocb9tMt9ZSufbFIRvPBzvCieRwO04h24iVEQmV1W2lIsLfQ0te5b8hoevhQXOJX 7927F9TQTgvUQJFOBILt8h4opFlu6KZkiQZUoRHQv1tKQ8E9sScROIw0+bw/sy9Ny510JkVa jiSHFZhWxK6iOiMMZZeNKcA3JpPUZ0nWK76RiwGZOwoM3pZTebR6UdjnXMPKsC1OAcgECoja dIfiUmNJXEQivtZKnHsbsyZ9I93SA1RGAUCCghKfc2py3nZwdrOi9VbVKl9GxnpC1tbyoJFT SZDeVimwnbuGdDPZEeO6bq5OkktSpMUZm5pf8cvnroKaQxU6mpm2nkiGUE9Zscw8Mgxe7SUx yVScbarXStmi5zkHl7NmDqLwfe6S+WStF3UY4Oi0eBe+qW8F+WxLrIkJ1dvvjyjowUHSvyiV 2HmptEbrTY3Gacm3uJqXZJsTrnKN5jZvt7mtazZnzZ7N/Y1x2rP5kYNsU/0q+Za5NbLaVDKV 8FYkaFYmmoK3sRL7iLuR8qCsBWhz9PdjOMqP/WYruoj7JbEZsUWwEkirIAw+9ivSsAvAWy3u S2UAtVvNWu2V1EW8ND4uQOpmkOcK4AzKbWGcU1fEZCnzqmytV5LBSnaStUp7Qtg9hQLJhln6 /qtN84pkXnPghijwRDs1XCyZ6/+tx9uC1dXKN9y4/N3kv1uFQpthByWuZZObeeodYigtQ221 NJEpNu0dlkqH5Hga0PkNi/XVJqO6qaaoOVjNnFPk32BHrw9my6vkAKJv2qn8YsEm7rQEKVUM aQXoByGVbbJqKyMZ1DApm381UjZzUbWZg6rNeVG16aNq06BKUeUiUbU1GVWmydlRNVkVtDlj oTKYXYYOQ11qhkvN8O5qhtkV9EnzIdH/rME7fvQsayrG1Ucq5POYzNIs0jsZbNmZmN8s1GXM boWA2QhnUDBR67Ilq+o22V6y/ANl6UzqlFGWBBJWnEMdckyONm8sUIgauqXPVomyryapO5MV l/n1kG09Eq2G/KH1jpsQpqR3aDzcijh1Cb9QoFqBJbylwru+pfxcys+7Ij/zlswnMovawkiz 0GsKosEwwp31XKJIJI+ueguyR7X1V5A+Mpal/FGYuF0JJI3OJYMU+S2l0FIK3VEp5Cybxcsh zLwaF+yIyNQ8h63ZiCgFlWTF3Dbj6wgqafH3kVPa8rs5q+V3fhH233jbjNMz5W7eXVHG+Lhd ScZtziXIhDwty+RSmi2l2d2TZvbS+TxhljnCQ7un+lWa52zU3CFAEFH//cAtpp5aJw+6StmL rei+LnuCja7gKHB+F50pc9jhYdRLhlcyeavcYnAexkCrq14L+HFI1X39yfnF8poPepvsgF76 RnXPnAD7F78mym5Tne8CmEv72RL6gomSNkXl5N6IS4FuGZVGwCsgJJSd2Mln0LA6+u8Xdgpt HzPbOsUCzne3dW+v63tlL5tpB25mIGV3tS1l2VKW3RVZll0wCzxfs90d/ujna6Tw82Umwwoy nCLXnkn3z+GFkhJ5spDfsxCSciX7WVYwCbHZFx6C+KIPK5dyE3ci7hySzSBJ07jVvQpaYada rf6fCVLyfBhlbK2FW1FBx83Jj5swjtqd/nNYR2/MK8hGxYJcgyaLX2/9uBLYX1xLM+hS2N4t YZu7PD5xJ/PFWrFIm9U2qhc53ebOFWgVudUBkugSSGC6oVSYsZFnDNsRZwoYA5pz32VL0+w2 iN9mUq1lYM9sciUGyQi6aZNrvvRT12q8OzLWlZiFycc03jbD9S2vd9qH1qDlVmSlszBnMb+6 K3npFrqUpHdXkuYsnoWdJmrYskubaQ+YZ5HN2xjKbGCKbgzGQc+DHtL16BLmIcE7wDoEofnk Cd1ZN5ETJS1+PGnrWTjd/eP1RCt39feRrYvbWVpjueMbSwsTtysrqcm5hCWT3nKvuZSQd1RC Wktm8SISs5dhgIdmJx5O2VzGw1l3ky5Qd1cZD+fZR15PWjnt/1E2hIvbAG5nR/mn8sC5Yalm 4+V2hZvd8lwyziHYpVfOUuDdaYGXXUY3I/e6FwuXegrk7yPzpPW/tMTjMS7lnSvvGCu3L+24 3bllnRDqUtItJd2dl3T2EroZOTfqDRYu6DTM30fSqeb/0qJOBrmUda6sE7TcvrCThueWdopY l+JuKe7uvLhzFtHNyDtKvYZXIAokHrlmXLSugAz5u/W13+bUbrNLQqs1RxZKAwJcAb4V6Wi6 9PvIxwkXECdEpdOvHt3ktcU43s5BVIEfDf95dNclrkbT7ctc3fTcUtcsgoynTYVndSmDlzL4 Tspgb1HdmHW1NU0IqzJzmlhbOeJWg7otS2vrDyFgFywf4+3sGJf7z4yttfX7CEPV8nXsrS1f FC7F31L83U3x5y6jG5N+vfDjFNkHJeaUfATTl3sI5rakHnbgry3zYIRLiZeReICV30XeQbvX kXZIpktZt5R1S1lnLaEbknTvmpwVbaKwU4XmkncGsivyNLDbkXq6G39lwacGuZR9nuxTiPkd xJ9qen4JqEl2KQSXQnApBN2FdDNysDdo9nrhYJrJ0yo2jyx0oDvS0AZ4K/LQ7spfWCJaw1zK RFcmWqi5faloNT63XLRJdykZl5LxzkvGzGJavGykNI47KrbmJNE4e2hvnDaWgiYYpzdrmo96 +SRd4Yk4qwTfCCzVyfwg4fiZKFLdi/Ze/x5k7uVfTwJ76Py9BfCNRhjPG/FSFhtZ7GLmdkWx 2/Zcktgj4aUgXgriOy2I85bS4uUw5Y+aIoevKXwny12TmtASsYVRbCZH4bbKFUbhxs8ccvp6 YtjD5l8jMo47qGWInAxKblfEum3PJWI98lxGz1kK1zsqXPMW0eKFq6TF+j3Eq51/cbKAvXGh mMHCX0Ms+sNaCsYcpNyuaPRbn0s4Zsh0KR6X4vGOisf8hXQDoVgp09aCzcDeTnA9Y2K9lp3Y yha5aJvwNYOveri7AzZfb8hLo68VtNVFzS2Hb3Ubny+Qq0fGS7vvUvbeadmbu5gWkobSygus W7OOQHNlb7YqKgb90QShbKUzVNUkybJUzcjMKZLO9HFRyarsDMkzi7r87Mok9zKvyrbkKQ5u UCAi815tmlcLSMlY/6/2atLY9cRpskwbYiFnQQLVQc5mLso2c1C2OS/KNn2Ubd5squut2VC2 +HzXWUY2LT+otUhzuGAmKsRSCVkqIXdPCfFW0wKTh9rcJ7NMkz9W8tA8kwXZAi6j9rtBAgic 6NMd92fKueZDdDO/VAhOrpnhBjy5vb784WwK8+tS1zE32KqRwcYyq1quemQQdLtGB7ftuWwO HpUvZf5S5i9lfu6C+jy7g598e9cWl7ufkXa7iMqyZnglTdsArummVmvnWO3zl80k4/31Mm+3 F5p3e/fGk263/zyn27s3l2+7XSDhdm8k1fZuYZ7t3eXZ9FJM3TExlV0Yt5BhezebLLRIbOWd RM8mpiLncu8MgmoWITVPHu7PvoHUvsVMoDcm6/Qw7rKo00i4eUlnra9ZN2+7y7SfS+l3J6Vf ZrEs1BdrVzYmOXJuXuera4s86IERePn2zgXJvd5Vp7X+A15uhj6sL0D4CfJ+B+l3a95XapB/ OpermxGRjIzbkpHc2uxCUuhx6Um1lJV3V1bai2bBwhLoeAGScu9FI3gXXWUfYpLTZx6/Uj2A jgLF5l6C7UU9mKPSNwCTjg1RwCXnJfhZLueXxIbsovjbL4v0s/u6tvtjc+/Fy4OdVyUjQyvQ W1kNGQ4rZNWIYOW+iIbvYDIAU7gYe0D2SZsWomCdlmBQEk6ThudROQMLu1Yl3MLYoVnAU/MQ 1+Nu1oYLI56lqGvGvbbeQsRg9BZGv6B2HiXGKQSoi3rjbjiKYO6JD3fi9qiKbZWB110CpePa UusC2QnzLhx88CFMg34yCs6Tcb+TmU0aA2HmqN54WT872subvEln6uqjidGxr2j8+sf06jOH Zzz2V7XCNI+KgrDqD9F9YPk4UMYDck/pycSuOr4F99J7qxUiGZ4y/IbLoZIBMfFD9MkQ6GtO 3LXsyK65rrCq6jDyckYLnUOoxzmThbV0L71q+vnELgu1MSpnVI2RYn9XvXjByjDrwjCqpSIc CCZuSwuGpmZXgZHulvrvUv+9u/qvXi4LVn7P42Gap/4i4xJIlpZMDB8I6OX+yWmj/GyysGDQ f/pDBBrGXT9EICTclmigxmYXDkxny0OEpWC4i4LBWiwLFg3d8BqS4WBnumAgwH96uYCjuOti AXFwW1IB25pdKBCNLWXCUibcRZlglsqCRUI/+ji/SDiqvZ0qEgjwn14k4CjuukhAHNyWSMC2 ZhcJRGNLkbAUCXdRJJilsmCRMBhG7+cWCccntZ+miQQC/KcXCTiKuy4SEAe3JRKwrdlFAtHY UiQsRcJdFAlmqSxYJLTHQwwMNLdU2D07Oakd4V5h2vUEaeBPLx1kIHddQAgabu2SAjc3xzUF obelpFhKirsoKZwFs2BhkeZ7X6Ln5Bq6bw1m9r6c7mjpvv3r+00O1n/43TwnsXntOQkgT2uN Rd//mO4FCAjQfoADviQyhyfgDF6An+/3J13Mev7Jiz+M71/6+/j+MSOY7vynygad1ihbEDqw eV1NjVW11HUSRIB3VFtLF+kkqJlwa+Tw4NZIsWBCGc+fjTEND4ryQvC96PGFXAvbyMhxe7YZ fCVYJbbxjQIoX2nV2w1OQ2Bmva7+CHoQ6iJ72E3i86KNgeYHSB0hwlNWWQDpOMDJaGQUqoti 3xDFz6b6pvN4XaZLr8ul4nunFd/0hrwuAe5J2L/IvaG71Hz/eppv82Tn6FVtqf/6Vf9k+i+v 2butBBMOlppwYKNjqQ7/edVhmsC5dGLmAkvFeKkY32nF2Fo4N6AdR+1+kqcdd1oABN41RwgV vtz05Xz3rb6oC3yGms++Fh6rObfqbzlbdNyN+lBU1coW8HTYs9PayWHt8M4o87dwp1/p57Xd o/rt6+fXv6W+ON08+OabPHU6jwZuQcOmdf87aNg2X7m5m+ZqhMvr5oGNjts6+FftzafuEUku 1b2lune31T2zcBYff6lI3ZtJubNYd45KNofqtwy5JJ8/TsglAPnqptQzmMT24KrEenzF1qiy uvvCzZ6/V7if46v9/qj5EgTNQQIim7dQM+pnF7+jfrZYv8sLXw+7owrYxS0rYBdzK2AXjgK2 VL2WqtcdU70ublL1GoynOF/KV5Qug1uLHU298s9TuQt/qkDSOI4/wmGhebAlAk3F03u0kNNE u1yOuIaCW9c+dhTDCaDSP3PkP1v89NEdFeCAl+Xh4x/28NFC6IaH0Q0fpVvFKN0oxOnGHEjd spG6YWF144+N1i1B68ash7qwJua4ATrOSRhZYZayVDaXyubdUjb10vk8PdPSTYK1fvSBBJK1 9gZXlG92Ji0yk1qYUykXFlpTCoat2K6V2WhWEgZsvSqXvWDdOmNlfhztPMZ4GPWS4ZXM3arY 587DGEh1NceY41DqJJuNyA/WHI348HrvIII02QIddnKeMH6rzH4b2RDmwL3SMfCLD8ANkhEw QD0nCc1rBouemiSzXgksRUlp3pgcO4Mn/5OfBtmpVnBm6SX0VJ+5xZzuCY1Exh1ESv9yVLTP mnlA97soGgCSh9E5sPt+O0KmnIyHSsbYPfB0ShXqXS2z/M0OoJxXthTzJpz3ZbDY2iDLRlHp G7Ujq9gQrMzmXjOZDZfzVtiH2QQwCop2U8hD9loLTbLq76e8PVD+PsbaGLUvw2HAiex/2dz6 7tdr2SJ5XKu8lSk2QhIzlk0JlZyuCimuW6gJOagoaya9NLMtNZ+7pfm4K+WTmiZZKvbASZ4d QgdBoJV46YMwI0YAskwquLt+lFCZ5ZeoLKaOU9BqhUGWnQmx92TFKTyK06NeI623yxpuMam3 QCsZSeMLFQ13rpze2F1X6hWkSNmrEX69skUdtkRoNn2PVyy3zCIyjy9cJt7EkZvu7Z/nvO3m so4X2OtuJOd4YcrxpZxfyvk7Juczy+IWEo6j41SzHbYvI9ySZwUrH6ldtK6AFvm79bVPFQuM JNaZGez33Va0+BTAAlQBnONgbP5TL2/Et3H8NXMOVf1qq/jVo8yrBWZejfEwy8WQ7wnMf/40 p1o3cKjl4ufGpWV2mc56eOCR+vIUYSlj77qMLVpMC3VboQa6ybATDYskKr+dVXQqWFpuSvWb F5TS8u8pJRcs5LSE46H96S663JRAY3TcnjTj9uYSZUKMy5suS9l1p2WXvXQWL7gG4cXEzaB6 P6vwMvC0+NIgbl6A6db/iiJMDW4pxDyE3J4YUy3OJcg0US5F2VKU3WlR5i6fxQuz1qjZi/vv oqsiacZvZ5VlFjgtzATCzYsy0/hfUZbp0S2FmY+R25Nmusm5xJkhzKU8W8qzOy3PvAW0eIF2 2Tw/D9ujpNCyKK9nlWgWPC3RFIibF2mm9b+iSNOjW4o0HyO3J9J0k3OJNEOYS5G2FGl3WqR5 C+gmRFo/6ka9IoFGL2cXZwJLCzOufhuijFv+awoyGttSjLn4uE0hRg3OKcKYIJcCbCnA7rgA sxbP4sXXMEJn97hQftHLWeWXAaYFGNe/eQGmm/4rSjA1uKUI8xByezJMtTiXENNEuZRiSyl2 p6WYu3xuRIx1o36hv2LUn0OEESDjrAh1b0V8YbN/UeEFQ1uKLgcdtyq4oL15xRYS41JoLYXW XRdaeunciMgahJ0ckcU33oEGMve+JwgtAqWF1hpWvhWphe3evtQSFN2E3Eq3ncEt5ZaDjluV W9DevHILyXEpt5Zy667LLb10bkRupcl42M5zsRe+rIvMIcAUTC3DDJBbEWTS/l9WlvH4luLM x8itSjRucl6hJqS5lGtLuXbX5Zq9gBYv2ig6Z6Fr4oTI/BmBJpCMU2JOXP2bEGTc7l/RjEgj W4ovGxu3J7qoubnEFhPiUmQtRdadFlnWwlmsuEoGucddspk4j7tRP+xFLLkwO4Alw+TqWNIp 2p65kug6eWbWf+D+GfmnOkQYzI/8TN2ULnL3cjoyJTIl0hp0pTxH0MsZUtfomN4beW9VTG/6 +9lSnBD3R9iF5oXzKsEMnB39eFR/c1T2SmUje+lXj61XT58uOu5XqgJ/IeYmx/viP4/vpNaA 2LkdhQFbmllXIHK31AQ7tleFZ2upOCwVhzulOJgFtFidYTy4GIadCXZbV22YecOr4eaI+9vY +Kr2/6hS8wYk3rYZdoHIu5NCTlByO3JOGptZ1CkyzUi7pYRbSri7JeGcpfN5Qo4YLgHF/eMM yRWg/Og6O9yRI/NgtUiD8ugam1UZ12g2KUetfbaIY/k0k3BbXIIC6f0dTk8gGLgdwYQtFUol UknMeqHBLwXQUgDdLQFklsgna30keZmD4tWKSlb0bP49l1gfr3Wk6FkbF5wWyN/F+XbSvJ2b bmGuBEHzWFg/Oy+4YPwPlRlhgTkOttUIl0ehChO3I1SpqZn3ekyEy+PPpYi9syLWWjALS3e8 q8XqeJjmRhGTJ81mBzTuj30oD/9Ol7au1IGG1oJOq+1JKqsf6OM6AsrNkdDQXhkb1cJVMrmG 41HSGMICW8Txqhq/ltY4Sszj3s4X3LMI7YlimocbuJlNdyckft71cyczBOxtO3iexa563bvq tBx56BcoOowVGpJ5CZwPrK8DWD0otgIqhWyyD4wpNPl+27NpF4z4RaYF3J1ZxcgSt9Y3Mq/K tvif2yid92rTvFpEdt7/sm8XI9TTZpI7bcVmlCxArXHQsZmLpM0cJG3Oi6RNH0mbBkmKIheJ qK1piDKNLlYHpPZmyfm8qxVB5hdLm/9SH7zr+qC1eBacBnr3z5AH2rcMccLMHBV270UDyryL rgb52uxMKuztqaIwDl8Ppb5nHO0+WwflVlDVhA6sf76lSGbg9k1FPMOW10C+Yrc1VbGboL1h G6Blj7IFod+bxVre1nVtU6DQbWuk2voctic/76Y+xyhZmJmqF/WA9ZdgszeCRVYJZO8FPxX7 JpTxNNsY0/CgaLUTjsLAT5uOL2R9bWSElj3zDL4SrKb3VmnfyQDlK2VHKjtMdTIGHXTjZ/VH EPooePewm6QSiOoBag5gFe33uGpQPgPWcYCT0cgoVNrtN7QwPAV5K5fqtnKobmteqtvyqW7r ZhXkR9Mo74YUZG5vZiupMOClcrxUju+4cmwvnMU6fQIVX0PHnN9i2ghQADzz2JfqizYfuqxF pvPt27cwU7tHdYLRClNg9u1kDOt1DDQR9hMg8yGuR2w8Gp6H7cgHMboMR0HYbkeDEVEBFryI kCvC+gWOAPwwFIEBC7gEyy/oJx8qPhjuBbQ6TIN+BPQO63Ew5oX4aGu9xXZDgYz2Qx+AyCRv gUPXy05JLcNJaBohDnj07abX0eSxzu7r2u6Pzb0XLw92XpVYswVyYHaQETTS+0YErOtFNHwH 5IjEAiNkAy8hQOiOeFBQElabhudROQMLx1VVF2OgWRhX8xAZ0u6kg+LrbUCIwvM2IILdeezh /nRGvXE3HEVAySReOnF7VMX2yjDDl7CAkWWo5Y5cklkyth98CIGEklFwnoz7nczs0CAINUf1 xsv62dFe3pRM2oyqj15azoZUI9jf36rPxJ3Wp0x/VSu8glEREgn0IboPhI4DZTwguUtPJnWV xUfzJchj/rrT75xiUkHa6a+ViYB4/uhrTsLNbCen0fw33wQlDRjlCo0lD/HnwygyRSc27J47 zLTxRAr6E+86J9z5+oNtSOmEAbBdtB2Ve2F3clcKaFluSZdb0tvekuaT3Q3tR6GxmTejyJQL LiIu96PL/ejd2o/qhbPwzehJ1M7Zj8LqH0btftIcIUT48hlHH6hogAJ+nQ2q+xaTl4pM+oY6 lX0tkknLOzWKcrbouBvh9k3Vyhbwtktnp7WTw9qhW65o30haas7G8U+4Cby9k6ucjeM3MBF6 4wgwT2uNJtkEbsyfyj+fvEfqiyK9iqaX/JgZuZ8Z9k5/st0SMo3b3zDZTOlmD+sWtueJ+RCO UZZ/M/iOHsIxShbtVPXXVNDzEXVzOjq0N4+ajtxgeWa01NGXOrpeOItV089z0hLM5nXUJ/oD AIvQz87tlAbfMNwb0MMQL8dX+/0RWaMPEuCZmbYm6Sfnv0cGhIVezj7v3O2r2ee3lNfgfPZ8 Bued5dXspVi7i2Lt/EYyFwzGU9wg+CvuXxfkEnF7dgwaW94BOI/mZi6ETXTGzfuInweghZ0s ONynTGKYKr+KfOns2UjYQjKAASsbyYD7MqPIRoz9AQ5gzYOtSaaFR7OfyNqhNhd2IqvK5UCE glvFZoxH1z66VWe3MFE5Z7fYqjy90zE9ATvLI9w/3hFuBqEbHkY3fJRuFaN0oxCnG3MgdctG 6oaF1Y0/Nlq3BK0bmaPxR7lL+VHOUn4071J+5C/lRzdreXs8cTnfkNkNGpt5M4LisuBofBmj d7lLuYu7FL18FpyF5qqfczx+g3H6ucHC4PifvU24Th4b7NKf3KKGY7jbNjXEwC0lqIGWZs9N g8S1tKwtZdYdlFlmoSxWaDUxTXazeU25NYe7FsXV4DgCuVeJugkQi9kUZcxxls3qe5puM9nD qJ30QKhnLy2ofRx5Bk28qWOXnuFiD03x9cM1+hGg8u2LsMvjklnZrtufIt/xM1HG4+fDZdyN gtKmP+U2+ud2RlMfMR2OkPuBdGFvNFiHwN0u44vL7hVQVnR+HrdjkECFUHJ87KDlrDua/clz YZtY6VPu09mnGT881TxtMNHkmawm0XdQO6q9beRMh250hrnFj7qSRGywEBstkHvvvHWlPrSq HmQCeObj5NrUgBW1W6ZySWP/M/W4ABtYM+vNNtl1rbjziCtgIegjJ2ibcpMLPzPJAwCXxyjw YyiCw0vy74LCjrycZViOQT/roZp10pTmM4Bm6mb+ubvpw4x7BSV6/uTbBRnG3d4xCBJuZ9Mg jc28b1CEttw6LLcOd3Dr4CyXRe8egJDjUdTL20FUrNKDqx+jq5u/AeK8LlD+4WfuNX372IW6 q49djEP/N8qjP1fJmcZE+bBFHa7okAarOSJ+ggbwKX+UM0Yj+BNeKlnEBZHCDZatkl/HgKqT lmYxVxAqYCb1kkkHyEUoh9dPzs4SGNvC9dXZiW+xQQGm0udnXGshQsaHwMavhHzvdxzinTLQ ea++2Lzxd1dxJ6d2918ZF5L5VWLRifXYfReQO6oea3wsSEVWfguEU+O4MEVv1r2YQ3c2VGwd Iy+16KUWfde0aG/xLFqTTido0vm+rj6XkgaNzyzJGsedtEgP2pjZZpP+jkJtuhPmbXlMXkMu imBMiwSj+EbeUfmYLlg+Lp0il06Rf0S0Ok6RM+ls6TV0tjRPZ1vetV1qbndTc0tvVnPrRN0Z NLdJ2prKJ2ApbPma2sxqmunTH0BN+0yt7NpGCI2EpRHCxcdSyfpjaANZJWuKMqBncA5lwLCC pQFnqQbcYTXAWzyLVQNAaqe36kWZfxa6FnTjdFT0DofvnZJicTrAOYAvzaPoQ8k/BkOC4VI6 gHSGR+Yz1cOolwzVEdaqaSI4D2Og9LkPPu1fs7t2znFCuqCEnnO7c17rqobzdpIP57U99j7f d3Nev825fDazfnDzuuR+lp/mrD6aFK9PPA1rR/XD2iEfZGqfzSL0i8tmdtjZJmBdz3QKm41N mDMw7DBDLF7w+AFtbq9GEe6RPRT4Mk7nDLnV1GdVjSloAzZQBZjAPPAj/CzrYK4+FwkoAJ1M sH38ZAlKeNbOYBD1OzTMCiE7p3GDjZwCWQ/Mub1QP+dEf+pMTcRaAcbMmPDddmaEc7Oc6zkI X8c52J2OmZxeZ5GCMwsv0SxcUT1pQ0/axe/uRfB5jrI4hrvtJYsYuB0XWWxp5i0iEdfSOXa5 K7yDu0KzUBa7HbwMU4Q9l0V4juxcU/Y0TlnKsAXrph2OMTkXq6BI7y3lvAnk9eEy6hPVd1oB 9F1lQnIAkTSVUOgbz7Kvcs14+m1RiPQFbMBm8/V0EktdZweWf+9F+Xgq1f6//9Vunxs25U4S 74pa7qytXhCwtNMbXCxt9H9KG73M3szKl1r6S9v8Ugu7s1qYs2g+VxE7jGAtdPaic2BPbf6R /vIrgPlt5QuQA6u2uAl8EVwJDmuN182fdk52Tl6dBp8qug5vXwNnS15c2jl8DvIO5ifVtZwE gzzfy0l1L/LrXsxSV26yBv4d3eI6HCwncAIAFZemkJCBHcqzuCwGtg6sQN3FJVXGjMBLOzKx hle8uCz7ZtjF+UlxDbYf2TWUZbmwBtqdnAr4oLg8ijO7OMdjLSo9HlwMw45TQR4V10kGUd+u gL8nUEE0apJ+75CCeji53jBqpsl42I78uvrF1PqDsJNTGZ5Ordl1R2meTq2J67iXU5eeT659 2ewDBWUqy+Npdc/Pw/bIJS/nxeT6rVGzF/c93ue8mFx/EF5EqK751dXzybW7ybATZbrOTyfX bIfty9yG9YuC+rxYobSuqJ8U1OhHH+zi/LOwd22PqbUncrW2sKZ+4lRRDyfUS/PqpbPVC/sX UaYePpxcz68yoTQwuCHsYZwa8mwS5obRexd18GBC+X700W0CH0wo3w1Ttzw+mFD+PB56FejJ 5Nn0J3JC6YwoaU+TJe2MaGhPlA2atttZci+Wh7X+e4pSCiup/W6QxM5EZl9OhdOKLuJ+Dgh6 PrF2O+n14tGOMtp4MLy3EyEBKQ3CYVQEyn89EVbYSoaFnXJfToRD4y+C476cCAf5Xm/Q7PXC gccSc95OhdR9BzQygm1ADhz9bjqUi2Yv/JgHgl7MUr9VMBj1aiqMPCGReTcVygiQ14mHOTDk zSxjyQfAL6bWR9NIAQT1avIq8niGfjaxlqfyqUfTOA2Uy/IaeDhRutqV9JOCGg1kPrTydRXz aEIdWeJOJXk2oRYtZ6cOPZkwGijjjKXxsQhn76NhGiemtPzOL4375wr9CxvoT89W7sXnHdjT NpvtQXec4n+w670X9Tvx+crDtZVgje0yo7DVJTvROI06aANAIwqx7WhIZrB1YuSYrGHtodo0 i3n4twC9RIK1/uYz9W3rWcAG0NLaoN1/XxZzaPlZ8Cloph9iXNyDAezkZYeN+3MYaTONL/pR p4lR/VYrq/J341NFF+i0mnG/87E5wtdj+D7afIo/CstML5Fe0tQVt9KXXuUUVB3VZbI9VkUK C3R0zkkstveieVDf/XFSERr2o62cQVmFZiiCbG0qkIkdUaOeUg5+DS74h12IbDi1o59WPeM4 PbILqo4WYMe8tpstLJHXFVOgALmmwJTXxThxQHiv3LjvWMZ8zymIaNrFUvLFx+quh1KviEet eetMj7IA59b7IqS7RfKwbpUoQLtVIoM0610Ryu0GCufFgZNdEeOpuBjPgg2/UB4+xrN1eDwR LeO5BlRAzabhWYtkidCjwQISFKbq8NzJBQu4frbgjMVy2PpMkGaAoxtDsaj7/l1hnwSd+VTm FSoktGy5XFrzihUsQL/YTIVyqS4LqJC1KaFQIA2mUMw0Qpkyq7r2BLFv5rywiIX2YqFuShTN plOoWPCbMtNLFIh9B8SkTkzmS995pZjy7WK2lMsIPo8xT5I/U2TPZLkzWeYUInICgSugk+TM JFnlsMrVHJap8VDYc6vEtPd5I3CrFzdeOEKrUAHm3RJFU8ersnCBWyUKlrhVImdp2m8L16/d yAROMJ6hv+NrAZv23hn4bxsV+N8n2O9l3YXIQYXPw9Pc/WD0ETZ5/WB1dzVQO0OsU3t7XD9p 0M6tHMT9eNRptUtlOg41wHuVYK3zDB7ZrcCWjn7CtvZ9OOzG/Xfo1/xFwJcNmvsA6zDpjLtR abVDJkdz4krlOlSOi6BrzV7cHpV69Or4Cn/gGfT+KJLLCqUO6suyK6aDyJwbDaXVrepmdWO1 PBFM+30ad4oAfLXf2YauVuPK+2CzurUZbG1sbDzcePLw0Uaw8XT7ydb2k6fBxTC6QBec4Ksp TcFS+Kl2crpfP2oe7vxP/YRadV3EUC0vB37B2cHuH80IFgvODPZ4p7H7ehawVHBmsKeNk/2j V7PA5ZJTAR/uvIUuvKqdToKpC80E7qS2Wz/ZmwpQik0FiQ6Nxzsnjf2dg0kgrWJTQb7dae6e 1HYatUkAdaGp4KbDmhHQUf3wcOd4EiAuMRUQe+ZMAqSuikwBtH+032juopAtBqXKzAaMJdsU aFhoVnATV4MqMxuww+N6fSKRmVKzAWy8PZoKDspMBYZrBRb2JFhSZFZQzZc7jckLyik4neLe YjKr05+PdidSnS41FeDZaQ13Nfsn9YkotIrNA7J5Uq83ZoRLZacCR5Ldq7+Z2FlVZiqw45P9 n6awFCky08TMMi0zTQrP35ud/Ym4M6WmAnxZP9mdOEwqMBVM7e3uRFrG99NXxl796ODniUuC SkzH0snZ0e6U6VNlZqIrwCYUn0ZZXGo2gHu1lztnBxNn0S43G9D6wV7tdDpMLjYbyJOdo736 4VSQXGw2kD/Xz45ezdJPVXAq2BeNk9rEyaYCU8G83jmdqDHi+1nY+1F9Cls/qk9nlUc/Hk1h ZlJkuv52NlGjgdezgDiFXdYUMFhkJvycTSQoLjEDICj1YppM5jIzAPvp9Phgv1F/+XIyPF1s KsjTo53j09eThZwqMxXYzsvG5JFSgelgjo9rRxPVUi4xfcXVQC5MXnJUYrrqjveoj+v7RxPx ZEpNB1g/Oj07nLwZ4CLTQZ2dHJxOXIJcYhZAQImTR8hFpsvr/ZPJnJMKTAdzcDaZ11GBqWBe 1RrNF/XGREiqzEzApnJPXWgquP8BcmnuN2oTeY0uNBXcj7Wfp+JelZkF2MHOVFhYZLpInQJn JiAYBGTirheDhMwCZJqwUWVmA3ZUnwUclZpha4+bqTcn+5PVQqvYDCCn6fUzbrWO66f7jf3J +yxVZoatS+2nyfuW2k8zbVJP9nZBAZtIF1ax6fKwNlkU1mYCgZrmq4kzqAvNBm4awzmdmeEQ 0QAfP51szrSKTQVZP8b4IqfNw53TiTYbu9z0uT18M3FOD9/MYFvZrR8eH9QmryVTahaGWDs8 bkzc/KkyMwF7uz+VvVKZWXdrO3vT7GZOwVl3lY1XQKqN2kSVzCs6A1viODuTGZPE4plKgQd7 yqI9kQBNsen0d3Ykpq3Je31TTN/6l6t8+dGg8JimSjcE1e3Uok5woYoCB6XJty/uj4KYap5D G6WYbv55joDxr1V0IIwfPDAXDukU6SS6iNNRNDzkgqWcapXss63sM/JExEt/n1b+dpOfwdV6 K+10Wo8eplEnbQ/jwWjhbWxsbmw8ffr4bxsbG5vfPtmw/+Jnc+sxfP92c2tj4/Gjx08fQflH W1ubfws2Ft6TnM84HYXDIPgbnoVNKjft/Z/0sxn/c+Ve8CrqR8MQ7+FjMIkeHsqG3e4VX6Y+ DN9F53E3qg6GUTXuo8OtppXqSvr1P2TJ//KPX7/erD75Gh7d+wcKzN3dXXwGf55fPHiAz//B Ty7abfoFrOxg/wU+GYb9btyih/XjBj5ZvwjW61v05GCP5Bo+pd97tZf0Y33v9c5PNdzIvYSl 95rL7r/gd91ONwjWuwO+L67eHfK7nvq9q4Ee/v/t20FPgzAUwPEzfoodRqImpZ+ARGQkLCZK RI2nJQuw2ATZ0roEY/zutlAnU+96+P9O7WspfQ84EEKS5ouscP1Wdft+OPXKprxRfRydh74V BHJv9DDW9M3wO4+fMO0G87ex9T6sXd64ZSOz9emUeXKbLXwlZsI8rbUtvWgrX6OvcbEplqnf 7PWVfZeeDD26j9WNnomm3231i6hfu/Wzqg6zx1rPT9P0LDyRq8M1uZC17arO3vhtWysdSxO6 BGKfmhwz+2XC57jR1dFxQeSiD0Vyl38Puo0cx130MikzW/2fQbvF+2Ia/uvnAwAAAAAAAAAA AAAAAPjPPgBrI2V4ABgGAA== --k1lZvvs/B4yU6o8G-- From guido@beopen.com Tue Jul 25 15:40:53 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:40:53 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:28:37 +0200." <20000725152837.I266@xs4all.nl> References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> <20000725152837.I266@xs4all.nl> Message-ID: <200007251440.JAA20085@cj20424-a.reston1.va.home.com> > There are a number of crude hacks that might be solved better: the > 2-argument opcodes, for instance, could posisbly be avoided by abusing the > proposed 'extended_arg' opcode. And the patch re-uses the binary opcodes as > augmented-assignment opcodes, merely because those #defines were already > available in both ceval.c and compile.c: this would 'break' if we wanted to > incorporate a new operator in augmented-assignment without adding a new > 'normal' opcode for that operator. > > I'm still working on the PEP, really :) It's just a pretty long one, trying > to explain all the intricate details and the simple elegance of the solution > . Perhaps it'll inspire some discussion in the details of the patch, > too. Suggestion: write the VM spec first, and check that in when you're done. I bet that writing down the VM spec will clarify a lot, since it will specify the semantics (the syntax we all know). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From bwarsaw@beopen.com Tue Jul 25 14:43:05 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 09:43:05 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> <200007251249.HAA19269@cj20424-a.reston1.va.home.com> <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> <200007251343.IAA19755@cj20424-a.reston1.va.home.com> Message-ID: <14717.39273.635728.922559@anthem.concentric.net> Okay Fred, if you want to make them manuals instead of PEPs, I don't object. -Barry From Moshe Zadka Tue Jul 25 14:43:57 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 25 Jul 2000 16:43:57 +0300 (IDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <20000725152044.H266@xs4all.nl> Message-ID: On Tue, 25 Jul 2000, Thomas Wouters wrote: > All in all, the only way we are really going to spot these pitfalls, > realistic or not, is by *using* the new syntax, and letting 'newbies' use > it. Without arguing with the specifics, I'm against this attitude: what will you do if you find newbies always stumble over those issues? You can't take it out, because you're commited to backwards compatability. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From Fredrik Lundh" <200007251424.JAA19917@cj20424-a.reston1.va.home.com> Message-ID: <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> guido wrote: > [x for x in seq] > [x+y for x in seq1 for y in seq2] > [x for x in seq if pred(x)] > [x, x*2 for x in seq] stupid question: does the last one mean that a python parser has to stack an infinite number of tokens before it can figure out if it has a list or a list comprehension? did Python just turn into something that is much harder to parse? From guido@beopen.com Tue Jul 25 15:49:22 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:49:22 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 09:39:58 -0400." <14717.39086.748350.672470@bitdiddle.concentric.net> References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> <14717.39086.748350.672470@bitdiddle.concentric.net> Message-ID: <200007251449.JAA20159@cj20424-a.reston1.va.home.com> > Not so fast Mr. Van Rossum! We need to get the specifications for > these features written first. Barry should be updating the PEP > guidelines today, and Tim and Thomas have been assigned PEPs on the > two most controversial features. Yesterday, I proposed we set Aug. 9 > as the deadline for completing the specs. They are not controversial with *me*, and the complaints about either that were repeated today don't impress me much. The only concerns I have are: - Should we allow [x, y for x in s1 for y in s2] or should we require that to be written as [(x, y) for x in s1 for y in s2]? - What does a += b += c mean? Plus doubts about the cleanliness of the implementations given by the currently proposed patches, e.g. Thomas' doubt about the use of so many new opcodes (which I think is actually fine). > Until we have the specs, I don't think we need to have lots of > long-winded debates about whether the features scare people :-). Agreed. Besides, our priorities should be focused on the 1.6 release first. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Tue Jul 25 15:54:02 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:54:02 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:37:30 +0200." <20000725153730.J266@xs4all.nl> References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <20000725153730.J266@xs4all.nl> Message-ID: <200007251454.JAA20180@cj20424-a.reston1.va.home.com> > Who are we writing PEPs for ? For you, Guido ? For the python-dev team as a > whole ? For python-list ? For the whole of the Python community ? A > collection of parts of one or more of the above ? Answer that question and > the faults in all current PEPs become obvious ;) The PEPs should be written for review of proposed changes for those who are serious about language design and implementation. I consider myself an element of that set but not its only member! For this audience, exactness and conciseness of description count; "selling" the feature to the general audience is not desirable. A rationale is necessary; this should include a motivation for the feature and discussion of (reasonable) alternatives and objections that have been brougt up (if any). A PEP should also be the place to point to when someone starts rehashing an old discussion. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas@xs4all.net Tue Jul 25 14:56:43 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 15:56:43 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 25, 2000 at 04:43:57PM +0300 References: <20000725152044.H266@xs4all.nl> Message-ID: <20000725155642.K266@xs4all.nl> On Tue, Jul 25, 2000 at 04:43:57PM +0300, Moshe Zadka wrote: > On Tue, 25 Jul 2000, Thomas Wouters wrote: > > All in all, the only way we are really going to spot these pitfalls, > > realistic or not, is by *using* the new syntax, and letting 'newbies' use > > it. > Without arguing with the specifics, I'm against this attitude: what will > you do if you find newbies always stumble over those issues? You can't > take it out, because you're commited to backwards compatability. I didn't suggest we turned augmented assignment 'on' in beta phase, and removed it if it turned out too confusing. I was thinking more along the lines of the recent 'usability study' of parallel loops. Urging people to install the patch just to see how it works, and if it works how they expected. The point is we can argue all year long about how will be confusing because of , and too confusing for users of , and this too confusing if you come from language. We probably all are right, too ! But in the end we have to decide whether the new functionality is worth the extra confusion. And part of that is determining how confusing the new syntax and semantics really are, for those used to Python and those new to Python. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@beopen.com Tue Jul 25 15:57:35 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:57:35 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:52:39 +0200." <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> Message-ID: <200007251457.JAA20217@cj20424-a.reston1.va.home.com> > guido wrote: > > > [x for x in seq] > > [x+y for x in seq1 for y in seq2] > > [x for x in seq if pred(x)] > > [x, x*2 for x in seq] > > stupid question: does the last one mean that a python parser has > to stack an infinite number of tokens before it can figure out if it > has a list or a list comprehension? > > did Python just turn into something that is much harder to parse? This is a (minor) open issue; I'd be happy with requiring [(x, x*2) for x in seq] --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Tue Jul 25 15:59:58 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:59:58 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 16:43:57 +0300." References: Message-ID: <200007251459.JAA20243@cj20424-a.reston1.va.home.com> > > All in all, the only way we are really going to spot these pitfalls, > > realistic or not, is by *using* the new syntax, and letting 'newbies' use > > it. > > Without arguing with the specifics, I'm against this attitude: what will > you do if you find newbies always stumble over those issues? You can't > take it out, because you're commited to backwards compatability. Thomas and Moshe, stop worrying (and arguing) about this! For these two proposals that has long been resolved. What I expect from you two is suggestions on how to best implement this. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido@beopen.com Tue Jul 25 16:01:13 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 10:01:13 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:56:43 +0200." <20000725155642.K266@xs4all.nl> References: <20000725152044.H266@xs4all.nl> <20000725155642.K266@xs4all.nl> Message-ID: <200007251501.KAA20258@cj20424-a.reston1.va.home.com> > I didn't suggest we turned augmented assignment 'on' in beta phase, and > removed it if it turned out too confusing. I was thinking more along the > lines of the recent 'usability study' of parallel loops. Urging people to > install the patch just to see how it works, and if it works how they > expected. > > The point is we can argue all year long about how will be confusing > because of , and too confusing for users of , and this > too confusing if you come from language. We probably all are right, > too ! But in the end we have to decide whether the new functionality is > worth the extra confusion. And part of that is determining how confusing the > new syntax and semantics really are, for those used to Python and those new > to Python. Oh please. Augmented assignment is about the most requested feature. Every other language that Python newbies are likely familiar with has it in exactly the same form. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy@beopen.com Tue Jul 25 15:27:40 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 10:27:40 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: <14717.41948.876878.174423@bitdiddle.concentric.net> >>>>> "PSK" == Peter Schneider-Kamp writes: >> If you commit a patch from the SF Patch Manager or fix a bug from >> the Jitterbug database, be sure to reference the patch/bug number >> in the CVS log message. Also be sure to change the status in the >> patch manager or bug database. PSK> "Be sure to have access to the bug database." I don't think I PSK> have. If you don't have access to Jitterbug, you can send me email and I'll make the change. Jeremy From sjoerd@oratrix.nl Tue Jul 25 15:27:18 2000 From: sjoerd@oratrix.nl (Sjoerd Mullender) Date: Tue, 25 Jul 2000 16:27:18 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: Your message of Thu, 20 Jul 2000 22:13:00 +0200. <20000720221300.W9897@xs4all.nl> References: <20000720221300.W9897@xs4all.nl> Message-ID: <20000725142719.0341831047C@bireme.oratrix.nl> On Thu, Jul 20 2000 Thomas Wouters wrote: > > I just went over all of the Python source, using this little program > (which I called findkrc.py): > > import sys, string > > for file in sys.argv[1:] > d = open(file).read() > if string.find(d, ";\n{") <> -1 or string.find(d, "()\n{") <> -1: > print file > > (using find -name '*.[ch]' -print | xargs ./findkrc.py) > > And I fixed almost all of the instances of K&R C syntax. However, I found a > lot of instances of the 2nd type: empty argument list. However, as far as I > remember, ANSI C states that should be written as '(void)'. Is that a > non-issue, and should I not bother fixing those ? (Most of the files in > Modules/ has one or more instances of those.) There is a difference between a function *declaration* and a function *definition*. The former, a function declaration, tells the compiler, this is the type of the function (and its arguments). In a function declaration it is useful to make the distinction between "no arguments" and "unknown arguments". This is done by using the "void" keyword. So int foo(); means that there is a function named "foo" that returns an int and with unknown arguments. int bar(void); means that there is a function named "bar" that returns an int and that doesn't take any arguments. However in a function definition you *must* specify the arguments. So if you define a function int foo() { ... } it is clear that foo doesn't have any arguments. There is no difference with int foo(void) { ... } -- Sjoerd Mullender From Fredrik Lundh" <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> <200007251457.JAA20217@cj20424-a.reston1.va.home.com> Message-ID: <00b401bff646$54389080$f2a6b5d4@hagrid> guido wrote: > This is a (minor) open issue; I'd be happy with requiring >=20 > [(x, x*2) for x in seq] doesn't really change anything, does it? the (x, x*2) could still be a value tuple or an assignment target. I'm no parser expert, but doesn't this mean that we're ruling out certain kinds of parsers? From Fredrik Lundh" <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> <200007251457.JAA20217@cj20424-a.reston1.va.home.com> <00b401bff646$54389080$f2a6b5d4@hagrid> Message-ID: <00dc01bff649$4049ff20$f2a6b5d4@hagrid> I wrote: > guido wrote: > > This is a (minor) open issue; I'd be happy with requiring > >=20 > > [(x, x*2) for x in seq] >=20 > doesn't really change anything, does it? the (x, x*2) could > still be a value tuple or an assignment target. umm. not sure "assignment target" was the right term here; what I'm trying to say is that you cannot tell what you're parsing until you've seen the "for" keyword. or in other words, the "n" in "when you see 'x', you have to read 'n' more tokens before you can tell what 'x' is" suddenly became much larger... (after all, I've successfully parsed Python code with a very simple non-backtracking recursive-descent parser -- and I'm not sure I can teach that one to recognize list comprehensions...) (and yes, I'm sure this can be expressed in [AELRS]+\(\d+\) notation, but I'm not gonna try ;-) From fdrake@beopen.com Tue Jul 25 15:57:25 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 10:57:25 -0400 (EDT) Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724203555.A32412@thyrsus.com> References: <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> Message-ID: <14717.43733.134803.961463@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Looks like just one to me, though there is some auxiliary called config.c > to me that I don't understand. Here, I'll enclose the stuff; it's Don't worry about config.c -- that's generated from the Setup files. As long as the right line appears in Setup.in, that's sufficient. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas@xs4all.net Tue Jul 25 16:02:15 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 17:02:15 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <20000725142719.0341831047C@bireme.oratrix.nl>; from sjoerd@oratrix.nl on Tue, Jul 25, 2000 at 04:27:18PM +0200 References: <20000720221300.W9897@xs4all.nl> <20000725142719.0341831047C@bireme.oratrix.nl> Message-ID: <20000725170215.P224@xs4all.nl> On Tue, Jul 25, 2000 at 04:27:18PM +0200, Sjoerd Mullender wrote: > On Thu, Jul 20 2000 Thomas Wouters wrote: > > for file in sys.argv[1:] > > d = open(file).read() > > if string.find(d, ";\n{") <> -1 or string.find(d, "()\n{") <> -1: > > print file > There is a difference between a function *declaration* and a function > *definition*. The script I included only finds function *definitions*, not declarations, and definitions is what I was talking about. > So if you define a function > int foo() > { > it is clear that foo doesn't have any arguments. There is no difference > with > int foo(void) > { And that was exactly what I was asking :) I know there is no difference between the two, and the question was: should I fix them anyway ? I got at least one (maybe more, I forget) affirmatives, so I fixed them. (The ones I could find, that is.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@beopen.com Tue Jul 25 17:12:05 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 11:12:05 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 17:01:35 +0200." <00dc01bff649$4049ff20$f2a6b5d4@hagrid> References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> <200007251457.JAA20217@cj20424-a.reston1.va.home.com> <00b401bff646$54389080$f2a6b5d4@hagrid> <00dc01bff649$4049ff20$f2a6b5d4@hagrid> Message-ID: <200007251612.LAA20609@cj20424-a.reston1.va.home.com> > > guido wrote: > > > This is a (minor) open issue; I'd be happy with requiring > > > > > > [(x, x*2) for x in seq] [effbot] > > doesn't really change anything, does it? the (x, x*2) could > > still be a value tuple or an assignment target. [effbot again] > umm. not sure "assignment target" was the right term here; what > I'm trying to say is that you cannot tell what you're parsing until > you've seen the "for" keyword. > > or in other words, the "n" in "when you see 'x', you have to read > 'n' more tokens before you can tell what 'x' is" suddenly became > much larger... > > (after all, I've successfully parsed Python code with a very simple > non-backtracking recursive-descent parser -- and I'm not sure I > can teach that one to recognize list comprehensions...) > > (and yes, I'm sure this can be expressed in [AELRS]+\(\d+\) > notation, but I'm not gonna try ;-) Don't worry. Greg Ewing had no problem expressing this in Python's own grammar, which is about as restricted as parsers come. (It's LL(1), which is equivalent to pure recursive descent with one lookahead token, i.e. no backtracking.) Here's Greg's grammar: atom: ... | '[' [testlist [list_iter]] ']' | ... list_iter: list_for | list_if list_for: 'for' exprlist 'in' testlist [list_iter] list_if: 'if' test [list_iter] Note that before, the list syntax was '[' [testlist] ']'. Let me explain it in different terms: The parser parses a series comma-separated expressions. Previously, it was expecting ']' as the sole possible token following this. After the change, 'for' is another possible following token. This is no problem at all for any parser that knows how to parse matching parentheses! If you'd rather not support [x, y for ...] because it's ambiguous (to the human reader, not to the parser!), we can change the grammar to something like: '[' test [',' testlist | list_iter] ']' (Note that | binds less than concatenation, and [...] means an optional part.) To merge with range literals, we'd have to go for: '[' test [':' test [':' test] | ',' testlist | list_iter ] ']' Another modification is needed to support [:x] and [:x:y], but that's a separate path through the parser entirely: atom: ... | '[' range | test [ range | ',' testlist | list_iter ] ']' | ... range: ':' test [':' test] --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jim@interet.com Tue Jul 25 16:24:54 2000 From: jim@interet.com (James C. Ahlstrom) Date: Tue, 25 Jul 2000 11:24:54 -0400 Subject: [Python-Dev] InfoWorld July 17 looks at Zope and Python Message-ID: <397DB146.C68F9CD0@interet.com> See that issue for a review of Zope. Python is mentioned in connection with Zope. JimA From akuchlin@mems-exchange.org Tue Jul 25 16:32:41 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 11:32:41 -0400 Subject: [Python-Dev] Re: Berkeley DB In-Reply-To: <20000724203555.A32412@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 24, 2000 at 08:35:55PM -0400 References: <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> Message-ID: <20000725113241.D32196@kronos.cnri.reston.va.us> On Mon, Jul 24, 2000 at 08:35:55PM -0400, Eric S. Raymond wrote: >Looks like just one to me, though there is some auxiliary called config.c >to me that I don't understand. Here, I'll enclose the stuff; it's >not large. Ah, it looks much simpler than I thought; there's one C file, so adding the C code is just a matter of dropping db_wrap.c into Modules, and adding the single line in the package's Setup.in to Modules/Setup.in. There are a bunch of *.py files, though; might it be worth creating a subpackage for BerkeleyDB in order to keep from cluttering up the library root? db_wrap.c is also an obscure name, and it would be nice to change it. --amk From gvwilson@nevex.com Tue Jul 25 16:39:48 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 25 Jul 2000 11:39:48 -0400 (EDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Message-ID: > Moshe Zadka wrote: > Would anyone feel really bad if we postpone list comprehensions and > augmented assignments to a later version? I would like augmented assignments as soon as possible. I would also like to volunteer to repeat the "simultaneous loop" syntax experiment with list comprehensions, i.e. see whether what's being proposed lines up with people's pre-existing intuitions. Greg From fdrake@beopen.com Tue Jul 25 16:40:42 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 11:40:42 -0400 (EDT) Subject: [Python-Dev] Re: Berkeley DB In-Reply-To: <20000725113241.D32196@kronos.cnri.reston.va.us> References: <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> Message-ID: <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > cluttering up the library root? db_wrap.c is also an obscure name, > and it would be nice to change it. _bsddb seems reasonable. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@beopen.com Tue Jul 25 17:47:18 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 11:47:18 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 11:39:48 -0400." References: Message-ID: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> > I would also like to volunteer to repeat the "simultaneous loop" syntax > experiment with list comprehensions, i.e. see whether what's being > proposed lines up with people's pre-existing intuitions. Please do! Though I have no doubt of the outcome: [x+y for x in [10, 20, 30] for y in [1, 2, 3]] will be almost universally understood to mean [11, 12, 13, 21, 22, 23, 31, 32, 33]. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr@thyrsus.com Tue Jul 25 16:58:47 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 11:58:47 -0400 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: ; from gvwilson@nevex.com on Tue, Jul 25, 2000 at 11:39:48AM -0400 References: Message-ID: <20000725115847.C1785@thyrsus.com> Greg Wilson : > I would also like to volunteer to repeat the "simultaneous loop" syntax > experiment with list comprehensions, i.e. see whether what's being > proposed lines up with people's pre-existing intuitions. I think that's n excellent idea. User testing! bWhat a concept! -- Eric S. Raymond "Rightful liberty is unobstructed action, according to our will, within limits drawn around us by the equal rights of others." -- Thomas Jefferson From Moshe Zadka Tue Jul 25 16:51:54 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 25 Jul 2000 18:51:54 +0300 (IDT) Subject: [Python-Dev] Product iteration Message-ID: A large part of the problem in list comprehensions (I think) is that we need to allow more then one "for" term, so we can iterate over the product of several lists. Why not solve that the same way we solved the parallel iteration problem, by using a function, called, say, "product". Then list comprehensions can limited to be (in pseudo formal grammar): '[' expr 'for' var 'in' seq [ 'if' pred ] ']' Such that "var" can be anything that can today be in a for loop, e.g., (x, (y, z)) Then we wouldn't have the irksome problem of how for's and if's intermix: the predicate at the end can be an and'ed sequence of predicates. Reference implemntation: class _Producter: def __init__(self, lists): if not lists: raise TypeError("must receive at least one list") self.lists = lists self.lengths = map(len, lists) self.n_lists = len(lists) def __getitem__(self, i): if i<0: raise ValueError("only non-negative indices supported") ret = [None] * self.n_lists for j in range(self.n_lists): i, i_j = divmod(i, self.lengths[j]) ret[j] = self.lists[j][i_j] if i != 0: raise IndexError("not that many items") return tuple(ret) def product(*lists): return _Producter(lists) -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From esr@thyrsus.com Tue Jul 25 17:03:27 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 12:03:27 -0400 Subject: [Python-Dev] Re: Berkeley DB In-Reply-To: <14717.46330.703979.141406@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jul 25, 2000 at 11:40:42AM -0400 References: <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> Message-ID: <20000725120327.D1785@thyrsus.com> Fred L. Drake, Jr. : > > Andrew Kuchling writes: > > cluttering up the library root? db_wrap.c is also an obscure name, > > and it would be nice to change it. > > _bsddb seems reasonable. There is already a bsddbmodule.c. Can somebody explain why some module names have a leading underscore and some don't? -- Eric S. Raymond "Extremism in the defense of liberty is no vice; moderation in the pursuit of justice is no virtue." -- Barry Goldwater (actually written by Karl Hess) From esr@thyrsus.com Tue Jul 25 17:07:27 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 12:07:27 -0400 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251647.LAA20899@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 11:47:18AM -0500 References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> Message-ID: <20000725120726.F1785@thyrsus.com> Guido van Rossum : > > I would also like to volunteer to repeat the "simultaneous loop" syntax > > experiment with list comprehensions, i.e. see whether what's being > > proposed lines up with people's pre-existing intuitions. > > Please do! > > Though I have no doubt of the outcome: > > [x+y for x in [10, 20, 30] for y in [1, 2, 3]] > > will be almost universally understood to mean > > [11, 12, 13, 21, 22, 23, 31, 32, 33]. This is my expectation as well. -- Eric S. Raymond The abortion rights and gun control debates are twin aspects of a deeper question --- does an individual ever have the right to make decisions that are literally life-or-death? And if not the individual, who does? From fdrake@beopen.com Tue Jul 25 16:56:05 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 11:56:05 -0400 (EDT) Subject: [Python-Dev] Re: Berkeley DB In-Reply-To: <20000725120327.D1785@thyrsus.com> References: <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> Message-ID: <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > There is already a bsddbmodule.c. Can somebody explain why some module names > have a leading underscore and some don't? I was under the impression that db_wrap was an implementation detail for some Python code; module names with a leading underscore are not intended to be directly used by anything other than a Python wrapper module. The existing bsddb module *is* the public interface; if db_wrap is a direct replacment, it should be called bsddb instead of _bsddb. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From akuchlin@mems-exchange.org Tue Jul 25 17:03:19 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 12:03:19 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <14717.47253.118639.700872@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jul 25, 2000 at 11:56:05AM -0400 References: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> Message-ID: <20000725120319.E32196@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 11:56:05AM -0400, Fred L. Drake, Jr. wrote: >module. The existing bsddb module *is* the public interface; if >db_wrap is a direct replacment, it should be called bsddb instead of >_bsddb. It's not; in fact, db_wrap.c is SWIG-generated code while the old bsddb module was a hand-written extension. Is it OK to add a SWIG-generated module to the core? (I have an irrational dislike SWIG's trick of encoding pointers as strings, because it provides a way to deliberately engineer core dumps; it's just sort of unsettling.) --amk From bwarsaw@beopen.com Tue Jul 25 17:09:50 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 12:09:50 -0400 (EDT) Subject: [Python-Dev] Product iteration References: Message-ID: <14717.48078.888579.564219@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> A large part of the problem in list comprehensions (I think) MZ> is that we need to allow more then one "for" term, so we can MZ> iterate over the product of several lists. All this belongs in PEP 202. Can we please stop discussing it here until that PEP is done? Tim Peters owns it, so until he assigns it to someone else, I suggest that if you have an opinion on list comprehensions, send your comments to him. Let Tim collect all the comments and write the PEP. didn't-mean-to-pick-on-moshe-ly y'rs, -Barry From thomas@xs4all.net Tue Jul 25 17:18:16 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 18:18:16 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251440.JAA20085@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 09:40:53AM -0500 References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> <20000725152837.I266@xs4all.nl> <200007251440.JAA20085@cj20424-a.reston1.va.home.com> Message-ID: <20000725181815.L266@xs4all.nl> On Tue, Jul 25, 2000 at 09:40:53AM -0500, Guido van Rossum wrote: > > I'm still working on the PEP, really :) It's just a pretty long one, trying > > to explain all the intricate details and the simple elegance of the solution > > . Perhaps it'll inspire some discussion in the details of the patch, > > too. > Suggestion: write the VM spec first, and check that in when you're > done. I bet that writing down the VM spec will clarify a lot, since > it will specify the semantics (the syntax we all know). The syntax isn't a problem, the exact semantics are ;) But I'll try the reverse method of the proposal, see where it leads. It'll be a quick and short technical description to start with, though, and I'm not entirely clear on whether that should be the PEP or not ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy@beopen.com Tue Jul 25 17:22:44 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 12:22:44 -0400 (EDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> Message-ID: <14717.48852.392171.944585@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> I would also like to volunteer to repeat the "simultaneous loop" >> syntax experiment with list comprehensions, i.e. see whether >> what's being proposed lines up with people's pre-existing >> intuitions. GvR> Please do! GvR> Though I have no doubt of the outcome: GvR> [x+y for x in [10, 20, 30] for y in [1, 2, 3]] GvR> will be almost universally understood to mean GvR> [11, 12, 13, 21, 22, 23, 31, 32, 33]. For reference, here is the what Haskell does with the same definition. Prelude> [ x+y | x <- [10, 20, 30], y <- [1, 2, 3]] [11,12,13,21,22,23,31,32,33] Jeremy PS I still find the Haskell more readable because it has some simple syntax that identifies what role each part of the expression plays. The producer is to the left of the vertical bar and each generator is identified by a "<-". From thomas@xs4all.net Tue Jul 25 17:22:55 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 18:22:55 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251449.JAA20159@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 09:49:22AM -0500 References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> <14717.39086.748350.672470@bitdiddle.concentric.net> <200007251449.JAA20159@cj20424-a.reston1.va.home.com> Message-ID: <20000725182255.M266@xs4all.nl> On Tue, Jul 25, 2000 at 09:49:22AM -0500, Guido van Rossum wrote: > - What does a += b += c mean? I don't want to start a discussion on this, but I just want to say: the current implementation considers it a syntax error, and I think that's a very reasonable thing to do. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw@beopen.com Tue Jul 25 17:25:07 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 12:25:07 -0400 (EDT) Subject: [Python-Dev] Features for Python 2.0 PEP References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <20000725153730.J266@xs4all.nl> Message-ID: <14717.48995.148454.146372@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> You can put Barry in Cardinal Fang's chair for that one ! :) TW> He suggested to use his PEP201, Parallel Iteration, as a TW> working example of a PEP. And PEP201 starts with a relatively TW> long introduction of how for-loops and the current map(None, TW> seq1, seq2) work. Yes, but as with any `first' it takes a little while to flesh things out. I'll soon have a revision that edits much of that out. PEP 1 is nearly ready so hopefully that'll answer most of the style questions. -Barry From jeremy@beopen.com Tue Jul 25 17:29:34 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 12:29:34 -0400 (EDT) Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725120319.E32196@kronos.cnri.reston.va.us> References: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> Message-ID: <14717.49262.480392.948763@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Tue, Jul 25, 2000 at 11:56:05AM -0400, Fred L. Drake, AMK> Jr. wrote: >> module. The existing bsddb module *is* the public interface; if >> db_wrap is a direct replacment, it should be called bsddb instead >> of _bsddb. AMK> It's not; in fact, db_wrap.c is SWIG-generated code while the AMK> old bsddb module was a hand-written extension. Is it OK to add AMK> a SWIG-generated module to the core? (I have an irrational AMK> dislike SWIG's trick of encoding pointers as strings, because AMK> it provides a way to deliberately engineer core dumps; it's AMK> just sort of unsettling.) Indeed! The stock SWIG produces dangerous code for pointers and inefficient code for returning multiple values. The code it produces is hard to read at least in part because it is indented incorrectly. I don't think any of these features are acceptable for a core module. I have some patches and typemaps for SWIG that do a better job, but it's still not great. If people are interested, I can post to the list. The two primary changes are to use PyCObjects for pointers and to generate better code for returning tuples. (The current code generates a return tuple incrementally; for each value, it creates a new tuple and appends it to the old return value.) Jeremy PS Andrew: The patched version of SWIG might still be installed in the depot at CNRI. You could try it out. From fdrake@beopen.com Tue Jul 25 17:29:02 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 12:29:02 -0400 (EDT) Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725120319.E32196@kronos.cnri.reston.va.us> References: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> Message-ID: <14717.49230.549418.726681@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > It's not; in fact, db_wrap.c is SWIG-generated code while the old > bsddb module was a hand-written extension. Is it OK to add a > SWIG-generated module to the core? (I have an irrational dislike > SWIG's trick of encoding pointers as strings, because it provides a > way to deliberately engineer core dumps; it's just sort of > unsettling.) You're right -- SWIG code stinks for exactly this reason. I think Jeremy did some work to avoid this, but I imagine that's no longer available (it's at CNRI). It seems to me that the right thing is to fix SWIG (probably as part of the next generation of the tool). I'm not sure what Dave's current plans are, or if there's any expectation for the schedule. I don't see anything relevant at www.swig.org, but I might be missing something obvious to SWIG users. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From akuchlin@mems-exchange.org Tue Jul 25 17:46:51 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 12:46:51 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <14717.49262.480392.948763@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 25, 2000 at 12:29:34PM -0400 References: <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> Message-ID: <20000725124651.F32196@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 12:29:34PM -0400, Jeremy Hylton wrote: >I don't think any of these features are acceptable for a core module. So what should we do WRT BerkeleyDB? The existing module in Python only really supports BSDDB 1.85. Robin Dunn's module, and the enhanced version of it by Greg someone-or-other, uses SWIG. Options I can think of: 1) Give up and do nothing 2) Try fixing SWIG. 3) Include the SWIG-generated code as it stands 4) Write a custom new BerkeleyDB extension. (In time for 2.0b1? Iffy...) I think the only solution is to do the job right and do #4, though it might wind up being postponed until Python 2.1, or whatever comes after 2.0. --amk From guido@beopen.com Tue Jul 25 18:51:39 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 12:51:39 -0500 Subject: [Python-Dev] Berkeley DB In-Reply-To: Your message of "Tue, 25 Jul 2000 12:46:51 -0400." <20000725124651.F32196@kronos.cnri.reston.va.us> References: <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> Message-ID: <200007251751.MAA21417@cj20424-a.reston1.va.home.com> > 1) Give up and do nothing > 2) Try fixing SWIG. > 3) Include the SWIG-generated code as it stands > 4) Write a custom new BerkeleyDB extension. (In time for 2.0b1? Iffy...) > > I think the only solution is to do the job right and do #4, though it > might wind up being postponed until Python 2.1, or whatever comes > after 2.0. Is the existing 3rd party BerkeleyDB broken, or just stylistically too bad for inclusion in the core? If the latter, we could remove bsddb from the core and refer to the 3rd party module -- assuming it has a website and all. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake@beopen.com Tue Jul 25 17:55:56 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 12:55:56 -0400 (EDT) Subject: [Python-Dev] Berkeley DB In-Reply-To: <200007251751.MAA21417@cj20424-a.reston1.va.home.com> References: <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> <200007251751.MAA21417@cj20424-a.reston1.va.home.com> Message-ID: <14717.50844.387001.258809@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > Is the existing 3rd party BerkeleyDB broken, or just stylistically too > bad for inclusion in the core? If the latter, we could remove bsddb > from the core and refer to the 3rd party module -- assuming it has a > website and all. Pointing to the new extension from the documentation is certainly reasonable under any circumstance, with a note about why it may be interesting or useful as an alternate implementation. Does anyone have a URL I can use? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal@lemburg.com Tue Jul 25 17:59:55 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 25 Jul 2000 18:59:55 +0200 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> Message-ID: <397DC78B.B31FF0CE@lemburg.com> Guido van Rossum wrote: > > > I would also like to volunteer to repeat the "simultaneous loop" syntax > > experiment with list comprehensions, i.e. see whether what's being > > proposed lines up with people's pre-existing intuitions. > > Please do! > > Though I have no doubt of the outcome: > > [x+y for x in [10, 20, 30] for y in [1, 2, 3]] > > will be almost universally understood to mean > > [11, 12, 13, 21, 22, 23, 31, 32, 33]. Just a note about the syntax: why does the above have the expression and the "for" notation reversed ? Wouldn't it make much more sense to write something more lambda function like, e.g. [for (x,y) in zip([10,20,30], [1,2,3]): x+y] or [for x in range(100): x*2] ? I believe the above would cause much less confusion since it resembles standard Python "for" loop notation (making it intuitive for Python programmers) and is in syntax very similar to what "lambda" uses: lambda : List comprehension would then become something like: [for in : ] -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Tue Jul 25 18:01:35 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 13:01:35 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <200007251751.MAA21417@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 12:51:39PM -0500 References: <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> <200007251751.MAA21417@cj20424-a.reston1.va.home.com> Message-ID: <20000725130135.G32196@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 12:51:39PM -0500, Guido van Rossum wrote: >Is the existing 3rd party BerkeleyDB broken, or just stylistically too >bad for inclusion in the core? If the latter, we could remove bsddb The latter. The existing module still works fine, particularly if you just need a DBM-like file that can also be traversed in sorted-key order, but it's not compatible with the current BerkeleyDB code. --amk From jeremy@beopen.com Tue Jul 25 18:08:30 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 13:08:30 -0400 (EDT) Subject: [Python-Dev] Makefile and dependencies Message-ID: <14717.51598.566139.423603@bitdiddle.concentric.net> The Python Makefiles do not contain enough dependency information to do incremental builds safely. If you change a .h file, none of the .c files that use it will be re-compiled unless they were also changed. This makes it a bit more tedious to test new code, because you need to do a make clean to be sure you're getting everything. I know next-to-nothing about makefiles. Is there anyone with some expertise in this area who could contribute better dependency information? Or is the lack of dependency information a conscious decision? Jeremy From guido@beopen.com Tue Jul 25 19:09:00 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 13:09:00 -0500 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: Your message of "Tue, 25 Jul 2000 13:08:30 -0400." <14717.51598.566139.423603@bitdiddle.concentric.net> References: <14717.51598.566139.423603@bitdiddle.concentric.net> Message-ID: <200007251809.NAA21636@cj20424-a.reston1.va.home.com> > The Python Makefiles do not contain enough dependency information to > do incremental builds safely. If you change a .h file, none of the .c > files that use it will be re-compiled unless they were also changed. > This makes it a bit more tedious to test new code, because you need to > do a make clean to be sure you're getting everything. > > I know next-to-nothing about makefiles. Is there anyone with some > expertise in this area who could contribute better dependency > information? Or is the lack of dependency information a conscious > decision? No, it's gradually been degraded. There's a "make depend" target that's broken beyond repair. I hope someone helps you to fix this! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From nascheme@enme.ucalgary.ca Tue Jul 25 18:29:34 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 25 Jul 2000 11:29:34 -0600 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: <200007251809.NAA21636@cj20424-a.reston1.va.home.com>; from Guido van Rossum on Tue, Jul 25, 2000 at 01:09:00PM -0500 References: <14717.51598.566139.423603@bitdiddle.concentric.net> <200007251809.NAA21636@cj20424-a.reston1.va.home.com> Message-ID: <20000725112934.A23143@keymaster.enme.ucalgary.ca> Guido, would you be interested in a non-recursive Python Makefile? I don't have a patch yet and I'm not sure it is possible to make it portable. Neil From Moshe Zadka Tue Jul 25 18:32:43 2000 From: Moshe Zadka (Moshe Zadka) Date: Tue, 25 Jul 2000 20:32:43 +0300 (IDT) Subject: [Python-Dev] Makefile and dependencies In-Reply-To: <14717.51598.566139.423603@bitdiddle.concentric.net> Message-ID: On Tue, 25 Jul 2000, Jeremy Hylton wrote: > The Python Makefiles do not contain enough dependency information to > do incremental builds safely. If you change a .h file, none of the .c > files that use it will be re-compiled unless they were also changed. > This makes it a bit more tedious to test new code, because you need to > do a make clean to be sure you're getting everything. > > I know next-to-nothing about makefiles. Is there anyone with some > expertise in this area who could contribute better dependency > information? Or is the lack of dependency information a conscious > decision? Well, there could probably be an improvement, but not one that would *ensure* safe incremental builds. The fundamental problems is that it's using recursive make, which tends to have this problem. (Anyone has a URL handy for Recursive Make Considered Harmful?). In the mean time, perhaps running makedepend on the makefiles can improve the situation. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido@beopen.com Tue Jul 25 19:33:38 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 13:33:38 -0500 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: Your message of "Tue, 25 Jul 2000 11:29:34 CST." <20000725112934.A23143@keymaster.enme.ucalgary.ca> References: <14717.51598.566139.423603@bitdiddle.concentric.net> <200007251809.NAA21636@cj20424-a.reston1.va.home.com> <20000725112934.A23143@keymaster.enme.ucalgary.ca> Message-ID: <200007251833.NAA21781@cj20424-a.reston1.va.home.com> > Guido, would you be interested in a non-recursive Python Makefile? I > don't have a patch yet and I'm not sure it is possible to make it > portable. Actually, the recursive version works just fine for me. It's the dependencies that aren't properly set. (Each .c file should depend on most .h files, and that info is missing from the sub-Makefiles; the toplevel Makefile just recurses into directories.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From trentm@ActiveState.com Tue Jul 25 18:37:36 2000 From: trentm@ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 10:37:36 -0700 Subject: C testing framework (was: Re: [Python-Dev] guidelines for contributing to Python) In-Reply-To: <14717.34372.437370.172614@beluga.mojam.com> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> <14717.34372.437370.172614@beluga.mojam.com> Message-ID: <20000725103736.B577@ActiveState.com> On Tue, Jul 25, 2000 at 07:21:24AM -0500, Skip Montanaro wrote: > > assuming it's a test that can be written in > Python. (If not, the group (or someone in it) probably needs to figure out > a C-based testing framework.) I already have a simple starter implementation for this with a couple stupid limitations. Would y'all like to see it? As well, this has been discussed a couple of times before: single email: http://www.python.org/pipermail/python-dev/2000-May/010750.html start of a later thread: http://www.python.org/pipermail/python-dev/2000-June/011622.html Show it? PEP it? Forget it? Trent -- Trent Mick TrentM@ActiveState.com From guido@beopen.com Tue Jul 25 19:42:32 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 13:42:32 -0500 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: Your message of "Tue, 25 Jul 2000 20:32:43 +0300." References: Message-ID: <200007251842.NAA21899@cj20424-a.reston1.va.home.com> > Well, there could probably be an improvement, but not one that would > *ensure* safe incremental builds. I don't believe that at all. The problem is that the submakefiles (in Parser, Objects, Python, and Modules) don't specify all dependencies on the header files in Include. If proper dependencies were added, the recursive make strategy would be totally fine. The toplevel Makefile always descends into each subdirectory to do whatever needs to be done there; there are some tricks so that the subdirectories know what to do and whether the toplevel libpython$(VERSION).a needs to be updated. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From tim_one@email.msn.com Tue Jul 25 18:50:47 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 13:50:47 -0400 Subject: [PEP 202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: <14717.48078.888579.564219@anthem.concentric.net> Message-ID: [Moshe] > A large part of the problem in list comprehensions (I think) > is that we need to allow more then one "for" term, so we can > iterate over the product of several lists. ... [Barry A. Warsaw] > All this belongs in PEP 202. Can we please stop discussing it here > until that PEP is done? But closed discussions are not the way to build a PEP: it's a PEP champion's job to *summarize* significant opposing viewpoints in the rationale, but there's no way to judge "significant" without intense community involvement. Vigorous open discussion is vital to any stds process. > Tim Peters owns it, so until he assigns it to someone else, I suggest > that if you have an opinion on list comprehensions, send your comments > to him. Let Tim collect all the comments and write the PEP. This is not how I want to do it. In the particular case of list comprehensions, everyone (well, everyone both conscious and sane ) is sick of the debate because it's been going on for *years*, and was almost purely repetitive long before Greg Ewing made his first patch. In this case I happen to think Moshe is trying to solve "a problem" likely nobody else sees as a problem, but I can't tell without seeing how others react to his (bizarre ) suggestion. A PEP isn't a dumping ground for every random suggestion that comes along, either -- open discussion is needed to narrow things down to the truly serious alternatives. A PEP writer's job should be more editor than arbiter: Guido is the only BDFL here! All that said, I have an enormous backlog of listcomp msgs still to plow through, and I'm going to flatly ignore any in the future unless they have PEP 202 in the Subject line (as this retitled msg has). A pep-dev mailing list is clearly a very good idea, but until one is set up I'm afraid python-dev is the only natural place to bear the unbearable (to some) pep-dev traffic. From trentm@ActiveState.com Tue Jul 25 19:00:00 2000 From: trentm@ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 11:00:00 -0700 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <397DC78B.B31FF0CE@lemburg.com> References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> Message-ID: <20000725110000.C577@ActiveState.com> On Tue, Jul 25, 2000 at 06:59:55PM +0200, M . -A . Lemburg wrote: > Wouldn't it make much more sense to write something > more lambda function like, e.g. > > [for (x,y) in zip([10,20,30], [1,2,3]): x+y] or [for x in [10,20,30]: for y in [1,2,3]: x+y] > > or > > [for x in range(100): x*2] > > List comprehension would then become something like: > > [for in : ] > For what it is worth, I like that. I can easily digest either though, so I think that this is a question for user testing. Trent -- Trent Mick TrentM@ActiveState.com From skip@mojam.com (Skip Montanaro) Tue Jul 25 19:05:24 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 25 Jul 2000 13:05:24 -0500 (CDT) Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725130135.G32196@kronos.cnri.reston.va.us> References: <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> <200007251751.MAA21417@cj20424-a.reston1.va.home.com> <20000725130135.G32196@kronos.cnri.reston.va.us> Message-ID: <14717.55012.596068.67219@beluga.mojam.com> Andrew> The latter. The existing module still works fine, particularly Andrew> if you just need a DBM-like file that can also be traversed in Andrew> sorted-key order, but it's not compatible with the current Andrew> BerkeleyDB code. The only thing that's needed to use the current bsddb module interface with libdb 2.x is to include db_185.h instead of db.h. You don't get all the 2.x functionality, but you do get the less buggy libdb implementation. I've been using it like that for a couple years. Skip From bwarsaw@beopen.com Tue Jul 25 19:10:52 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 14:10:52 -0400 (EDT) Subject: [Python-Dev] Makefile and dependencies References: <14717.51598.566139.423603@bitdiddle.concentric.net> Message-ID: <14717.55340.327775.690317@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> I know next-to-nothing about makefiles. Is there anyone with JH> some expertise in this area who could contribute better JH> dependency information? Or is the lack of dependency JH> information a conscious decision? makedepend is the way to go and is probably compatible with GNU and non-GNU makes. -Barry From skip@mojam.com (Skip Montanaro) Tue Jul 25 19:09:58 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 25 Jul 2000 13:09:58 -0500 (CDT) Subject: C testing framework (was: Re: [Python-Dev] guidelines for contributing to Python) In-Reply-To: <20000725103736.B577@ActiveState.com> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> <14717.34372.437370.172614@beluga.mojam.com> <20000725103736.B577@ActiveState.com> Message-ID: <14717.55286.1741.361478@beluga.mojam.com> [c-based testing framework] Trent> Show it? PEP it? Forget it? I say show it. I see no reason to make a PEP unless there are a number of potential immediate alternatives. It doesn't affect the functionality of the distribution, only its quality. If something better comes along later, Trent's can be replaced. Skip From jeremy@beopen.com Tue Jul 25 19:25:56 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 14:25:56 -0400 (EDT) Subject: C testing framework (was: Re: [Python-Dev] guidelines for contributing to Python) In-Reply-To: <20000725103736.B577@ActiveState.com> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> <14717.34372.437370.172614@beluga.mojam.com> <20000725103736.B577@ActiveState.com> Message-ID: <14717.56244.101761.909713@bitdiddle.concentric.net> >>>>> "TM" == Trent Mick writes: TM> single email: TM> http://www.python.org/pipermail/python-dev/2000-May/010750.html TM> start of a later thread: TM> http://www.python.org/pipermail/python-dev/2000-June/011622.html TM> Show it? PEP it? Forget it? One or more of the first two. All the feedback first time around was positive, but it was suggested too close to the purported 1.6 feature freeze deadline. Let's put it back on track for 2.0. Jeremy From Fredrik Lundh" <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> Message-ID: <002001bff666$832b18c0$f2a6b5d4@hagrid> mal wrote: > Wouldn't it make much more sense to write something > more lambda function like, e.g. >=20 > [for (x,y) in zip([10,20,30], [1,2,3]): x+y] >=20 > or >=20 > [for x in range(100): x*2] fwiw, I read that as: [ for x in range(100): x * 2 ] which makes no sense at all. From trentm@ActiveState.com Tue Jul 25 19:27:13 2000 From: trentm@ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 11:27:13 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs machine with >= 32bit longs Message-ID: <20000725112713.D577@ActiveState.com> I was assigned this patch a while back to try on some 64-bit systems. Fine, I can do that but I have since seen a number of message on python-dev regarding it: - Fredrik had a new, better replacement? Fredrik? - The name changed to unicodedata? MAL? - Bill, you said that the patch is no longer necessary? Anyway, can someone familiar with the patch tell me if I should check it on 64-bit systems (Win64, Linux64) and then who I should pass the patch on to? OR should I just mark it Out of Date or Rejected? Thanks, Trent -- Trent Mick TrentM@ActiveState.com From skip@mojam.com (Skip Montanaro) Tue Jul 25 19:41:17 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 25 Jul 2000 13:41:17 -0500 (CDT) Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <002001bff666$832b18c0$f2a6b5d4@hagrid> References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> <002001bff666$832b18c0$f2a6b5d4@hagrid> Message-ID: <14717.57165.155081.532709@beluga.mojam.com> >> [for x in range(100): x*2] Fredrik> fwiw, I read that as: Fredrik> [ Fredrik> for x in range(100): Fredrik> x * 2 Fredrik> ] Fredrik> which makes no sense at all. It makes perfect sense. You read it correctly as far as I can tell. Using Greg's patch, I get what you'd expect from a simple for loop: >>> [x*2 for x in range(10)] [0, 2, 4, 6, 8, 10, 12, 14, 16, 18] It occurred to me a little bit ago to suggest that we just allow complete statements within list constructors. The semantics would be that any objects left on the stack at the end of the statements would constitute the elements of the list. Is that too weird? Skip From Fredrik Lundh" <200007251647.LAA20899@cj20424-a.reston1.va.home.com><397DC78B.B31FF0CE@lemburg.com><002001bff666$832b18c0$f2a6b5d4@hagrid> <14717.57165.155081.532709@beluga.mojam.com> Message-ID: <000c01bff66a$2a451540$f2a6b5d4@hagrid> skip wrote: > The semantics would be that any objects left on the stack > at the end of the statements would constitute the elements > of the list. Is that too weird? yes. From billtut@microsoft.com Tue Jul 25 20:08:57 2000 From: billtut@microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 12:08:57 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD329@RED-MSG-50> Well, Fredrik's changes aren't checked in yet, so checking it all in doesn't hurt. The other relevant question is since Fredrik's code will eventually get in, do we want to yank the code that generates it? (Tools/perfecthash) If we keep it, then that part of the patch should go in. If we don't keep it, that's fine too. You'd need to test it on Linux64. Win64's integer types are 32bits, and the C code doesn't use long longs. The easiest way of testing it of course is to apply the ucnhash.c patch to your tree and run test_ucn.py. :) Bill -----Original Message----- From: Trent Mick [mailto:trentm@ActiveState.com] Sent: Tuesday, July 25, 2000 11:27 AM To: Jeremy Hylton; Bill Tutt; M . -A . Lemburg; Mark Favas; Fredrik Lundh Cc: python-dev@python.org Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs machine with >= 32bit longs I was assigned this patch a while back to try on some 64-bit systems. Fine, I can do that but I have since seen a number of message on python-dev regarding it: - Fredrik had a new, better replacement? Fredrik? - The name changed to unicodedata? MAL? - Bill, you said that the patch is no longer necessary? Anyway, can someone familiar with the patch tell me if I should check it on 64-bit systems (Win64, Linux64) and then who I should pass the patch on to? OR should I just mark it Out of Date or Rejected? Thanks, Trent -- Trent Mick TrentM@ActiveState.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://www.python.org/mailman/listinfo/python-dev From esr@thyrsus.com Tue Jul 25 20:28:32 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 15:28:32 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 25, 2000 at 06:51:54PM +0300 References: Message-ID: <20000725152832.A2019@thyrsus.com> Moshe Zadka : > > A large part of the problem in list comprehensions (I think) is that we > need to allow more then one "for" term, so we can iterate over the product > of several lists. Why not solve that the same way we solved the parallel > iteration problem, by using a function, called, say, "product". > > Then list comprehensions can limited to be (in pseudo formal grammar): > > '[' expr 'for' var 'in' seq [ 'if' pred ] ']' > > Such that "var" can be anything that can today be in a for loop, e.g., > > (x, (y, z)) > > Then we wouldn't have the irksome problem of how for's and if's intermix: > the predicate at the end can be an and'ed sequence of predicates. *KLANNGGG!!!* <-- the sound of the sacred two-by-four of enlightenment belatedly whacking Eric upside the head Dammit, I should have seen this sooner; the whole debate about parallel loops and zip() was a flare-lit clue. Gentlemen, we've been going entirely down the wrong path trying to express list comprehensions via a syntax in imperative style. What they want to be is an applicative sublanguage in functional style -- and mostly about data composition rather than the expression of iteration per se. zip() is part of this. Finding a way to handle conditionals ain't hard; in fact, it's already in the language! The right way to say [x**2 for x in range(1, 99) if isprime(x)] is like this: [x**2 for x in filter(isprime, range(1, 99)] Look at the implications: there is no longer any need for special syntax (or for python-dev debates over special syntax, or newbie confusion over special syntax) on the right side of the for. We get all the power of list comprehensions from one simple [for ... in ...] construct exactly parallel to the for ... in that Python programmers already understand. So instead of trying to fix list comprehensions with syntactic hacks, we can extend it by having a properly rich and orthogonal set of constructor functions. filter, zip, product, and lambda are good enough to cover anything the presently proposed comprehension syntax can handle. But there's a difference, because unfreezing and extending a syntax is a heckuva lot harder than inventing new functional constructors. If you notice that this looks a lot like LISP or F or Haskell, you win. These languages got comprehensions right on the basis of a lot of experience in depth. We can learn from their example. -- Eric S. Raymond An armed society is a polite society. Manners are good when one may have to back up his acts with his life. -- Robert A. Heinlein, "Beyond This Horizon", 1942 From skip@mojam.com (Skip Montanaro) Tue Jul 25 20:18:43 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 25 Jul 2000 14:18:43 -0500 (CDT) Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <000c01bff66a$2a451540$f2a6b5d4@hagrid> References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> <002001bff666$832b18c0$f2a6b5d4@hagrid> <14717.57165.155081.532709@beluga.mojam.com> <000c01bff66a$2a451540$f2a6b5d4@hagrid> Message-ID: <14717.59411.881986.179947@beluga.mojam.com> >> The semantics would be that any objects left on the stack at the end >> of the statements would constitute the elements of the list. Is that >> too weird? Fredrik> yes. That was my initial reaction, which was why I didn't post it when I had the idea, only when I saw your interpretation... S From akuchlin@mems-exchange.org Tue Jul 25 20:37:06 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 15:37:06 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725152832.A2019@thyrsus.com>; from esr@thyrsus.com on Tue, Jul 25, 2000 at 03:28:32PM -0400 References: <20000725152832.A2019@thyrsus.com> Message-ID: <20000725153706.B11657@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 03:28:32PM -0400, Eric S. Raymond wrote: >[x**2 for x in filter(isprime, range(1, 99)] ... >filter, zip, product, and lambda are good enough to cover anything the >presently proposed comprehension syntax can handle. ... but not so elegantly, if the filter needs variables from the current scope. Consider removing all numbers in that range that are a multiple of a variable 'n'; you'd have to write: [x**2 for x in filter(lambda x, number = n: (x%n)!=0, range(1,99)) ] This uses the default argument hack to pass the value of 'n' into the scope of the lambda-created function as the parameter 'number'. Icky... I'd rather see extra syntax than more use of this kludge! --amk From skip@mojam.com (Skip Montanaro) Tue Jul 25 20:43:00 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 25 Jul 2000 14:43:00 -0500 (CDT) Subject: [PEP 202] Re: [Python-Dev] Product iteration In-Reply-To: <20000725152832.A2019@thyrsus.com> References: <20000725152832.A2019@thyrsus.com> Message-ID: <14717.60868.260948.186346@beluga.mojam.com> Eric> Dammit, I should have seen this sooner; the whole debate about Eric> parallel loops and zip() was a flare-lit clue. Gentlemen, we've Eric> been going entirely down the wrong path trying to express list Eric> comprehensions via a syntax in imperative style. What they want Eric> to be is an applicative sublanguage in functional style -- and Eric> mostly about data composition rather than the expression of Eric> iteration per se. Part of the motivation for list comprehensions as I recall is that we'd like to get away from such a strong reliance on map, reduce and filter. Although powerful concepts, as implemented in Python they tend to be inefficient in many cases, are not powerful enough (incomplete set of functions perhaps?) for the Lispers and are too confusing for non-Lispers, especially when used in complex ways (more than two of them used in the same expression constitutes complex usage to my feeble brain). (I PEP'd the subject so Guido and Tim can find it easily.) Skip From gmcm@hypernet.com Tue Jul 25 20:56:35 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 25 Jul 2000 15:56:35 -0400 Subject: [PEP 202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: References: <14717.48078.888579.564219@anthem.concentric.net> Message-ID: <1247567499-36688181@hypernet.com> [Tim] > In this case I happen to think Moshe is trying to solve "a > problem" likely nobody else sees as a problem, but I can't tell > without seeing how others react to his (bizarre ) > suggestion. FWIW, I like the original Greg Ewing syntax best. Reason: list comprehensions are declarative, and his syntax *looks* declarative. Procedural syntax inside those [...] is wacko, just as d = { ['one'] = 1, ['two'] = 2 } would be. Also, extra punctuation is just noise. PEP202-now-closed-ly y'rs - Gordon From Fredrik Lundh" <200007251647.LAA20899@cj20424-a.reston1.va.home.com><397DC78B.B31FF0CE@lemburg.com><002001bff666$832b18c0$f2a6b5d4@hagrid><14717.57165.155081.532709@beluga.mojam.com><000c01bff66a$2a451540$f2a6b5d4@hagrid> <14717.59411.881986.179947@beluga.mojam.com> Message-ID: <002101bff67b$7fba7680$f2a6b5d4@hagrid> skip wrote: > Fredrik> yes. >=20 > That was my initial reaction, which was why I didn't post it when I = had the > idea, only when I saw your interpretation... fwiw, the syntax implemented by the patch is the best one I've seen this far. it wasn't that syntax I had in mind when I talked about list confusions... ::: however, I think I prefer=20 [(x, x*2) for x in seq] over [x, x*2 for x in seq] (it doesn't only help me scan it, it also simplifies a piece of code that I happen to have here...) the bot says +0. From guido@beopen.com Tue Jul 25 22:59:43 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 16:59:43 -0500 Subject: [Python-Dev] patches activity In-Reply-To: Your message of "Tue, 25 Jul 2000 16:10:26 EST." <200007252110.QAA24625@server1.lfw.org> References: <200007252110.QAA24625@server1.lfw.org> Message-ID: <200007252159.QAA24008@cj20424-a.reston1.va.home.com> I take it that Ping's script to scrape patches works, and the SF folks have fixed the sending of email on changed patches. So now we get every notification twice. Ping, do you have a better address where we can send the raw email? --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From thomas@xs4all.net Tue Jul 25 22:03:23 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 23:03:23 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment Message-ID: <20000725230322.N266@xs4all.nl> No, this isn't the first full draft of the PEP :P While writing up the proposed VM changes, I came to the conclusion my patch was all wrong, and I would like some input in case I forgot something. The current patch introduces the following bytecodes: GETSET_SUBSCR GETSET_SLICE GETSET_SLICE+1 GETSET_SLICE+2 GETSET_SLICE+3 GETSET_ATTR GETSET_NAME GETSET_FAST GETSET_GLOBAL Each bytecode does the loading of the object, the actual operation it is supposed to perform, and the storing in the original place. All opcodes get an argument to specify which operation should be performed, which is also where the need for 2-argument opcodes comes from: the NAME/FAST/GLOBAL opcodes need both a name-index and an opcode argument. My excuse for this design is similar to Guido's excuse for the current Python parser: I was young, I was foolish, and I didn't know how to reuse things, only how to *add* things ;) I was also intimidated by the whole idea of a stack, having never really programmed in a low-level programming language before. I now realize only 11 new opcodes are necessary, and it can even be reduced to 1, by splitting the operation into seperate LOAD, , and STORE instructions, with a few ROT_TWO and ROT_THREE's mixed in. could be a new bytecode for each operation (11 in total) or a single 'AUGOP' bytecode with an argument to specify the operation. I think it's less elegant from the bytecode point of view, but it does require a lot less changes in ceval/compile. There is only one significant difference between the current version and this, and that's behaviour in the face of threads. I had originally seen augmented assignment as a way to increment a counter 'thread-safe': the load and store operation are done in one bytecode, and can thus not be interrupted by a thread switch. But after thinking about it, it doesn't make that much sense. It only works for builtin types, not for classes defining a __op_ab__, and possibly not for extention types. In fact, there might be some possibility for a thread switch even in builtin types, though I have never looked at that. Opinions ? Is the semi-reliability in the face of threads a good idea ? Did I miss anything important about the current implementation ? Should I forget about this idea and keep the patch as it is (and go back to my PEP) or should I rewrite the patch and then rewrite the PEP ? This alternate implementation would eradicate my next-to-last objection to including the patch, I think, but we'll discuss the last one, the naming of the __hooks__, after I finish the bloody PEP ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mwh21@cam.ac.uk Tue Jul 25 22:12:17 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 25 Jul 2000 22:12:17 +0100 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Thomas Wouters's message of "Tue, 25 Jul 2000 23:03:23 +0200" References: <20000725230322.N266@xs4all.nl> Message-ID: Thomas Wouters writes: [opcodes for augmented assignment] > I now realize only 11 new opcodes are necessary, and it can even be reduced > to 1, by splitting the operation into seperate LOAD, , and STORE > instructions, with a few ROT_TWO and ROT_THREE's mixed in. could > be a new bytecode for each operation (11 in total) or a single 'AUGOP' > bytecode with an argument to specify the operation. Can you really do a[b:c] += d with ROT_THREE & ROT_TWO? I thought one couldn't when I was doing the first patch, but maybe I'm wrong. > I think it's less elegant from the bytecode point of view, but it does > require a lot less changes in ceval/compile. There is only one significant > difference between the current version and this, and that's behaviour in the > face of threads. And size of bytecode! > I had originally seen augmented assignment as a way to increment a counter > 'thread-safe': the load and store operation are done in one bytecode, and > can thus not be interrupted by a thread switch. But after thinking about it, > it doesn't make that much sense. It only works for builtin types, not for > classes defining a __op_ab__, and possibly not for extention types. In fact, > there might be some possibility for a thread switch even in builtin types, > though I have never looked at that. > > Opinions ? Is the semi-reliability in the face of threads a good idea ? IMHO, yes. > Did I miss anything important about the current implementation ? > Should I forget about this idea and keep the patch as it is (and go > back to my PEP) or should I rewrite the patch and then rewrite the > PEP ? For now, I'd just write the PEP. Cheers, M. -- On the other hand, the following areas are subject to boycott in reaction to the rampant impurity of design or execution, as determined after a period of study, in no particular order: ... http://www.naggum.no/profile.html From nascheme@enme.ucalgary.ca Tue Jul 25 22:13:34 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 25 Jul 2000 15:13:34 -0600 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: <200007251833.NAA21781@cj20424-a.reston1.va.home.com>; from Guido van Rossum on Tue, Jul 25, 2000 at 01:33:38PM -0500 References: <14717.51598.566139.423603@bitdiddle.concentric.net> <200007251809.NAA21636@cj20424-a.reston1.va.home.com> <20000725112934.A23143@keymaster.enme.ucalgary.ca> <200007251833.NAA21781@cj20424-a.reston1.va.home.com> Message-ID: <20000725151334.A24845@keymaster.enme.ucalgary.ca> On Tue, Jul 25, 2000 at 01:33:38PM -0500, Guido van Rossum wrote: > Actually, the recursive version works just fine for me. It's the > dependencies that aren't properly set. (Each .c file should depend on > most .h files, and that info is missing from the sub-Makefiles; the > toplevel Makefile just recurses into directories.) Isn't it a lot easier to maintain inter-directory dependencies with a non-recursive Makefile? Also, build times should be quicker. Perhaps it is not worth the effort. Neil From trentm@ActiveState.com Tue Jul 25 22:28:05 2000 From: trentm@ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 14:28:05 -0700 Subject: [Python-Dev] patches activity In-Reply-To: <200007252159.QAA24008@cj20424-a.reston1.va.home.com> References: <200007252110.QAA24625@server1.lfw.org> <200007252159.QAA24008@cj20424-a.reston1.va.home.com> Message-ID: <20000725142804.A7183@ActiveState.com> On Tue, Jul 25, 2000 at 04:59:43PM -0500, Guido van Rossum wrote: > I take it that Ping's script to scrape patches works, and the SF folks > have fixed the sending of email on changed patches. So now we get > every notification twice. As well, would it be possible in your processing to normalize text paragraphs to 80 columns. nit nit nit Thanks, Trent p.s. Thanks for doing this, Ping. It helps a lot. -- Trent Mick TrentM@ActiveState.com From guido@beopen.com Tue Jul 25 23:32:36 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 17:32:36 -0500 Subject: [Python-Dev] patches activity In-Reply-To: Your message of "Tue, 25 Jul 2000 14:28:05 MST." <20000725142804.A7183@ActiveState.com> References: <200007252110.QAA24625@server1.lfw.org> <200007252159.QAA24008@cj20424-a.reston1.va.home.com> <20000725142804.A7183@ActiveState.com> Message-ID: <200007252232.RAA24277@cj20424-a.reston1.va.home.com> > > As well, would it be possible in your processing to normalize text paragraphs > to 80 columns. nit nit nit > Code for that is in IDLE: Tools/idle/FormatParagraph.py, function reformat_paragraph(). > p.s. Thanks for doing this, Ping. It helps a lot. Yes! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From mal@lemburg.com Tue Jul 25 22:45:25 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 25 Jul 2000 23:45:25 +0200 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> <002001bff666$832b18c0$f2a6b5d4@hagrid> Message-ID: <397E0A75.6F49041E@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Wouldn't it make much more sense to write something > > more lambda function like, e.g. > > > > [for (x,y) in zip([10,20,30], [1,2,3]): x+y] > > > > or > > > > [for x in range(100): x*2] > > fwiw, I read that as: > > [ > for x in range(100): > x * 2 > ] > > which makes no sense at all. Why doesn't that make sense ? Is this just a gut feeling or explainable ? IMHO, the meaning of the differen parts is intuitively understandable from the fact that Python's standard "for" notation works in the same way. OTOH, the notation "x*2 for x in range(100)" looks strange to me and probably to others too, because it doesn't make clear what "x" really refers to until you read on... this is Python not Forth or Haskell ! BTW, is it the missing append operator (the one that pushes x*2 onto the list) that's bothering you ? Note that we could also extend the above by allowing multiple such constructs separated by commas: data = (1.3, 1.2, 1.1) l = [for x in data: 3*x, for x in data: x/10] -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one@email.msn.com Tue Jul 25 22:47:05 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 17:47:05 -0400 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <002101bff67b$7fba7680$f2a6b5d4@hagrid> Message-ID: I didn't read this because it doesn't have PEP202 in the Subject line <0.9 wink>. Nevertheless, FWIW, I prefer [(x, x*2) for x in seq] too. > -----Original Message----- > From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On > Behalf Of Fredrik Lundh > Sent: Tuesday, July 25, 2000 5:01 PM > To: Skip Montanaro > Cc: python-dev@python.org > Subject: Re: [Python-Dev] List comprehension syntax (Features for Python > 2.0) > > > skip wrote: > > Fredrik> yes. > > > > That was my initial reaction, which was why I didn't post it > when I had the > > idea, only when I saw your interpretation... > > fwiw, the syntax implemented by the patch is the best > one I've seen this far. it wasn't that syntax I had in mind > when I talked about list confusions... > > ::: > > however, I think I prefer > > [(x, x*2) for x in seq] > > over > > [x, x*2 for x in seq] > > (it doesn't only help me scan it, it also simplifies a piece of > code that I happen to have here...) > > the bot says +0. > > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev From esr@thyrsus.com Tue Jul 25 22:57:59 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 17:57:59 -0400 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <397DC78B.B31FF0CE@lemburg.com>; from mal@lemburg.com on Tue, Jul 25, 2000 at 06:59:55PM +0200 References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> Message-ID: <20000725175759.B2019@thyrsus.com> M.-A. Lemburg : > I believe the above would cause much less confusion since > it resembles standard Python "for" loop notation (making it > intuitive for Python programmers) and is in syntax very > similar to what "lambda" uses: > > lambda : > > List comprehension would then become something like: > > [for in : ] I agree with this proposal. It harmonizes well with the use of applicative or functional notation. -- Eric S. Raymond To make inexpensive guns impossible to get is to say that you're putting a money test on getting a gun. It's racism in its worst form. -- Roy Innis, president of the Congress of Racial Equality (CORE), 1988 From esr@thyrsus.com Tue Jul 25 22:59:37 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 17:59:37 -0400 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <14717.57165.155081.532709@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 25, 2000 at 01:41:17PM -0500 References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> <002001bff666$832b18c0$f2a6b5d4@hagrid> <14717.57165.155081.532709@beluga.mojam.com> Message-ID: <20000725175937.C2019@thyrsus.com> Skip Montanaro : > It occurred to me a little bit ago to suggest that we just allow complete > statements within list constructors. The semantics would be that any > objects left on the stack at the end of the statements would constitute the > elements of the list. Is that too weird? Not only is it non-weird, I think it is finally pushing in the right direction. -- Eric S. Raymond Rapists just *love* unarmed women. And the politicians who disarm them. From esr@thyrsus.com Tue Jul 25 23:08:18 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:08:18 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725153706.B11657@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Tue, Jul 25, 2000 at 03:37:06PM -0400 References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> Message-ID: <20000725180818.D2019@thyrsus.com> Andrew Kuchling : > On Tue, Jul 25, 2000 at 03:28:32PM -0400, Eric S. Raymond wrote: > >[x**2 for x in filter(isprime, range(1, 99)] > ... > >filter, zip, product, and lambda are good enough to cover anything the > >presently proposed comprehension syntax can handle. > > ... but not so elegantly, if the filter needs variables from the > current scope. Consider removing all numbers in that range that are a > multiple of a variable 'n'; you'd have to write: > > [x**2 for x in filter(lambda x, number = n: (x%n)!=0, range(1,99)) ] > > This uses the default argument hack to pass the value of 'n' into the > scope of the lambda-created function as the parameter 'number'. > Icky... I'd rather see extra syntax than more use of this kludge! Wrong answer. The right answer is to fix lambda (or some variant of lambda) to be a true lexical closure. -- Eric S. Raymond Question with boldness even the existence of a God; because, if there be one, he must more approve the homage of reason, than that of blindfolded fear.... Do not be frightened from this inquiry from any fear of its consequences. If it ends in the belief that there is no God, you will find incitements to virtue in the comfort and pleasantness you feel in its exercise... -- Thomas Jefferson, in a 1787 letter to his nephew From akuchlin@mems-exchange.org Tue Jul 25 23:01:16 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 18:01:16 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180818.D2019@thyrsus.com>; from esr@thyrsus.com on Tue, Jul 25, 2000 at 06:08:18PM -0400 References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> Message-ID: <20000725180116.A12239@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond wrote: >Wrong answer. The right answer is to fix lambda (or some variant of lambda) >to be a true lexical closure. Hm... hmmmm... fixing this has been suggested before, but always foundered on the fact that creating a closure required a cycle, which would leak memory. Now we have an optional GC that should handle this, so maybe fixing it can be revisited. (But this would mean that GC is essentially no longer optional -- maybe too radical a thing to do before we're sure about the new GC. 2.1, maybe?) --amk From esr@thyrsus.com Tue Jul 25 23:14:22 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:14:22 -0400 Subject: [PEP 202] Re: [Python-Dev] Product iteration In-Reply-To: <14717.60868.260948.186346@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 25, 2000 at 02:43:00PM -0500 References: <20000725152832.A2019@thyrsus.com> <14717.60868.260948.186346@beluga.mojam.com> Message-ID: <20000725181422.E2019@thyrsus.com> Skip Montanaro : > Part of the motivation for list comprehensions as I recall is that we'd like > to get away from such a strong reliance on map, reduce and filter. In that case, the the lesson is that this is a bad road to go down. The cost of moving away from a functional syntax, in this case, seems to be dubious thickets of syntactic ugliness, Mind you, I'm not a functional-language bigot; I'm not after turning Python into LISP. Python has taught me the limits of the LISP approach to the world. But I think the lesson from this particular debate is that it's not really possible to do better than functional syntax for expressing the kinds of things that want to go on the right side of a comprehension. -- Eric S. Raymond Live free or die; death is not the worst of evils. -- General George Stark. From tim_one@email.msn.com Tue Jul 25 23:08:47 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 18:08:47 -0400 Subject: [PEP202 listcomps] (was RE: [Python-Dev] List comprehension syntax (Features for Python 2.0)) In-Reply-To: <397E0A75.6F49041E@lemburg.com> Message-ID: [MAL, on /F's complaints about [for x in range(100): x*2] ] > ... > IMHO, the meaning of the differen parts is intuitively > understandable from the fact that Python's standard "for" > notation works in the same way. > > OTOH, the notation "x*2 for x in range(100)" looks strange to me > and probably to others too, because it doesn't make clear what "x" > really refers to until you read on... this is Python not Forth or > Haskell ! The feature is taken from Haskell, which in turn adapted it from SETL. Both follow the long-established ordering of mathematical set-builder notation, where the *expression* is leftmost. It's the expression that's important, not the incidental details of the iterators -- there's more than a century of user experience behind that <0.6 wink>. I'll note that everything "looks strange" the first time you see it. It's more important that it feels right after you grasp it. That's the case here! When I see [x**2 for x in range(100)] I (being a left-to-right reader) immediately grasp "ah, it's a list of squares". Write it [for x in range(100): x*2] and it's simply harder to grasp (indeed, *that* "looks strange" to me -- it looks like somebody started to write a "for" loop and made a typo). In any case, this particular point was debated to death more than a year ago, and Guido already Pronounced on it. > ... > Note that we could also extend the above by allowing multiple > such constructs separated by commas: > > data = (1.3, 1.2, 1.1) > l = [for x in data: 3*x, > for x in data: x/10] Sure, and we could write u[...] for Unicode lists too . I see no advantage in the above over the simpler construct, i.e. l = [3*x for x in data] + [x/10 for x in data] except that it may be easier for a dirt-dumb implementation to optimize the former. From jeremy@beopen.com Tue Jul 25 23:15:31 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 18:15:31 -0400 (EDT) Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us> References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: <14718.4483.735535.296724@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond AMK> wrote: >> Wrong answer. The right answer is to fix lambda (or some variant >> of lambda) to be a true lexical closure. AMK> Hm... hmmmm... fixing this has been suggested before, but AMK> always foundered on the fact that creating a closure required a AMK> cycle, which would leak memory. Now we have an optional GC AMK> that should handle this, so maybe fixing it can be revisited. AMK> (But this would mean that GC is essentially no longer optional AMK> -- maybe too radical a thing to do before we're sure about the AMK> new GC. 2.1, maybe?) I was thinking this would be a post 2.0 PEP. Jeremy From esr@thyrsus.com Tue Jul 25 23:26:28 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:26:28 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Tue, Jul 25, 2000 at 06:01:16PM -0400 References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: <20000725182628.H2019@thyrsus.com> Andrew Kuchling : > On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond wrote: > >Wrong answer. The right answer is to fix lambda (or some variant of lambda) > >to be a true lexical closure. > > Hm... hmmmm... fixing this has been suggested before, but always > foundered on the fact that creating a closure required a cycle, which > would leak memory. Now we have an optional GC that should handle > this, so maybe fixing it can be revisited. (But this would mean that > GC is essentially no longer optional -- maybe too radical a thing to > do before we're sure about the new GC. 2.1, maybe?) I think there's enough controversy about comprehensions at this point to warrant not rushing out an implementation we might regret. (Heh. Look at me telling *Guido* to go slow and careful...heh.) -- Eric S. Raymond To make inexpensive guns impossible to get is to say that you're putting a money test on getting a gun. It's racism in its worst form. -- Roy Innis, president of the Congress of Racial Equality (CORE), 1988 From mwh21@cam.ac.uk Tue Jul 25 23:19:05 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 25 Jul 2000 23:19:05 +0100 Subject: [Python-Dev] Product iteration In-Reply-To: "Eric S. Raymond"'s message of "Tue, 25 Jul 2000 18:08:18 -0400" References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> Message-ID: "Eric S. Raymond" writes: > Wrong answer. The right answer is to fix lambda (or some variant of > lambda) to be a true lexical closure. And presumably local functions too? Otherwise that's also the wrong answer... Cheers, M. -- 40. There are two ways to write error-free programs; only the third one works. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html From esr@thyrsus.com Tue Jul 25 23:33:18 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:33:18 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <14717.55012.596068.67219@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 25, 2000 at 01:05:24PM -0500 References: <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> <200007251751.MAA21417@cj20424-a.reston1.va.home.com> <20000725130135.G32196@kronos.cnri.reston.va.us> <14717.55012.596068.67219@beluga.mojam.com> Message-ID: <20000725183318.I2019@thyrsus.com> Skip Montanaro : > The only thing that's needed to use the current bsddb module interface with > libdb 2.x is to include db_185.h instead of db.h. You don't get all the 2.x > functionality, but you do get the less buggy libdb implementation. I've > been using it like that for a couple years. It shouldn't be difficult to write a configure test to autoconfigure this. But I think a previous poster was right to suggest writing a custom interface for the 3.x code instead. -- Eric S. Raymond "Rightful liberty is unobstructed action, according to our will, within limits drawn around us by the equal rights of others." -- Thomas Jefferson From esr@thyrsus.com Tue Jul 25 23:35:22 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:35:22 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725124651.F32196@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Tue, Jul 25, 2000 at 12:46:51PM -0400 References: <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> Message-ID: <20000725183522.J2019@thyrsus.com> Andrew Kuchling : > I think the only solution is to do the job right and do #4, though it > might wind up being postponed until Python 2.1, or whatever comes > after 2.0. I'm inclined to agree...sadly, I don't yet have the chops to do this myself. -- Eric S. Raymond The right to buy weapons is the right to be free. -- A.E. Van Vogt, "The Weapon Shops Of Isher", ASF December 1942 From trentm@ActiveState.com Tue Jul 25 23:39:12 2000 From: trentm@ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 15:39:12 -0700 Subject: [Python-Dev] Summary or failing regression tests... Message-ID: <20000725153912.A21409@ActiveState.com> Here is a list of the regrtests that are currently failing for me on Linux32 and Win32. Is anybody looking at test_mmap, test_userstring, test_winreg, and test_winreg2? Skip, You and Jeremy(?) were talking about test_posixpath on Linux. It looks like the sames errors you were talking about occur on Win32. I didn't look too closely, can you? Fredrik, are you aware of the test_sre failure on Win32? Am I doing something wrong to be getting this? On Linux32: - test_fork1 This fails/hangs/crashes inconsistently because (some little bird told me) the fork stuff and threads are incompatible. Am I right? Now that we are turning threads on by default what is the proper thing to do here? SHould test_fork1 be changed to skip if threads are enabled? On Win32: - test_mmap one liner: test test_mmap crashed -- exceptions.WindowsError : [Errno 6] The handle is invalid full output: Position of foo: 1.0 pages Length of file: 2.0 pages Contents of byte 0: '\000' Contents of first 3 bytes: '\000\000\000' Modifying file's content... Contents of byte 0: '3' Contents of first 3 bytes: '3\000\000' Contents of second page: foobar Regex match on mmap (page start, length of match): 1.0 6 Seek to zeroth byte Seek to 42nd byte Seek to last byte Try to seek to negative position... Try to seek beyond end of mmap... Try to seek to negative position... Attempting resize() Traceback (most recent call last): File "..\Lib\test\test_mmap.py", line 114, in ? test_both() File "..\Lib\test\test_mmap.py", line 100, in test_both m.resize( 512 ) WindowsError: [Errno 6] The handle is invalid - test_posixpath one liner: test test_posixpath failed -- Writing: 'error!', expected: 'No err' full output: error! evaluated: posixpath.commonprefix(["/home/swenson/spam", "/home/swen/spam"]) should be: /home returned: /home/swen error! evaluated: posixpath.commonprefix(["/home/swen/spam", "/home/swen/eggs"]) should be: /home/swen returned: /home/swen/ 2 errors. - test_re one liner: test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou" full output: Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Traceback (most recent call last): File "..\Lib\test\test_re.py", line 122, in ? raise TestFailed, "symbolic reference" test_support.TestFailed: symbolic reference discussion: This has been discussed a litle by Mark Favas and Jeremy with no conclusion. http://www.python.org/pipermail/python-dev/2000-July/013963.html - test_sre one liner: test test_sre failed -- Writing: '=== Failed incorrectly', expected: "===grouping error ('(" full output: Running tests on sre.search and sre.match Running tests on sre.sub Running tests on symbolic references Traceback (most recent call last): File "..\Lib\test\test_sre.py", line 124, in ? raise TestFailed, "symbolic reference" test_support.TestFailed: symbolic reference discussion: This has been discussed a litle by Mark Favas and Jeremy with no conclusion http://www.python.org/pipermail/python-dev/2000-July/013963.html - test_userstring one liner: test test_userstring failed -- Writing: "'a'", expected: '' full output: 'a' <> 'A' <> '\012' <> 'abc' <> 'aBc123' <> 'abc\012' <> 'a' <> 'A' <> '\012' <> '123abc456' <> 'a1b3c' <> 'aBc000 ' <> 'abc\012' <> - test_winreg one liner: test test_winreg failed -- Unread: '\012' full output: (this works when run standalone) - test_winreg2 (crashes) full output: Fatal Python error: PyThreadState_Get: no current thread abnormal program termination Thanks, Trent -- Trent Mick TrentM@ActiveState.com From nowonder@pool.informatik.rwth-aachen.de Wed Jul 26 01:47:21 2000 From: nowonder@pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Wed, 26 Jul 2000 00:47:21 +0000 Subject: [Python-Dev] Summary or failing regression tests... References: <20000725153912.A21409@ActiveState.com> Message-ID: <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> Trent Mick wrote: > > On Linux32: > - test_fork1 > This fails/hangs/crashes inconsistently because (some little bird told me) > the fork stuff and threads are incompatible. Am I right? Now that we are > turning threads on by default what is the proper thing to do here? SHould > test_fork1 be changed to skip if threads are enabled? That works fine to me (--with-threads). Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Fredrik Lundh" = 32bit longs References: <20000725112713.D577@ActiveState.com> Message-ID: <004801bff68b$6e364280$f2a6b5d4@hagrid> trent wrote: > I was assigned this patch a while back to try on some 64-bit systems. = Fine, I > can do that but I have since seen a number of message on python-dev = regarding > it:=20 >=20 > - Fredrik had a new, better replacement? Fredrik? my patch is here: http://w1.132.telia.com/~u13208596/uninames-patch.txt=20 (it's ~600k, which is more than sourceforge can handle) if you have some time to spare, feel tree to try it out on your favourite 64-bit platform (I haven't had time to test it on our alphas, but I'm pretty sure it'll work). the patch doesn't update the build files, so you need to do some manual tweaking to make sure the unicodenames module is built. if everything works as it should, the resulting interpreter should survive test_ucn.py even if ucnhash.pyd (.so) is nowhere to be seen... From Fredrik Lundh" Message-ID: <005601bff68c$340d3b80$f2a6b5d4@hagrid> trent wrote: > Fredrik, are you aware of the test_sre failure on Win32? Am I doing = something > wrong to be getting this? > Traceback (most recent call last): > File "..\Lib\test\test_sre.py", line 124, in ? > raise TestFailed, "symbolic reference" > test_support.TestFailed: symbolic reference hmm. *I* don't get that error (Win32, MSVC 5.0). If everything works as it should, test_re and test_sre should produce what's in output/test_s?re does anyone else see this error on Linux? From trentm@activestate.com Tue Jul 25 23:55:00 2000 From: trentm@activestate.com ('Trent Mick') Date: Tue, 25 Jul 2000 15:55:00 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD329@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD329@RED-MSG-50> Message-ID: <20000725155500.B21409@ActiveState.com> On Tue, Jul 25, 2000 at 12:08:57PM -0700, Bill Tutt wrote: > Well, Fredrik's changes aren't checked in yet, so checking it all in doesn't > hurt. > > The other relevant question is since Fredrik's code will eventually get in, > do we want to yank the code that generates it? > (Tools/perfecthash) If we keep it, then that part of the patch should go in. > If we don't keep it, that's fine too. > > You'd need to test it on Linux64. Win64's integer types are 32bits, and the > C code doesn't use long longs. > The easiest way of testing it of course is to apply the ucnhash.c patch to > your tree and run test_ucn.py. :) Okay. I tried it and with the patch test_ucn.py passes fine. I am going to add a comment to the patch on SourceForge and then assigned it back to.... hmmmm... eenie meenie minie... Bill! Is that alright? Trent -- Trent Mick TrentM@ActiveState.com From billtut@microsoft.com Tue Jul 25 23:53:22 2000 From: billtut@microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 15:53:22 -0700 Subject: [PEP 202] Re: [Python-Dev] Product iteration Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32C@RED-MSG-50> > From: Eric S. Raymond [mailto:esr@thyrsus.com] > Skip Montanaro : > > Part of the motivation for list comprehensions as I recall is that we'd like > > to get away from such a strong reliance on map, reduce and filter. > In that case, the the lesson is that this is a bad road to go down. > The cost of moving away from a functional syntax, in this case, seems > to be dubious thickets of syntactic ugliness, > Mind you, I'm not a functional-language bigot; I'm not after turning Python > into LISP. Python has taught me the limits of the LISP approach to the world. > But I think the lesson from this particular debate is that it's not really > possible to do better than functional syntax for expressing the kinds of things > that want to go on the right side of a comprehension. Amen. I personally liked the Haskell syntax Jeremy posted earlier. It just makes sense visually. Bill From nascheme@enme.ucalgary.ca Tue Jul 25 23:57:28 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 25 Jul 2000 16:57:28 -0600 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us>; from Andrew Kuchling on Tue, Jul 25, 2000 at 06:01:16PM -0400 References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: <20000725165728.A25611@keymaster.enme.ucalgary.ca> On Tue, Jul 25, 2000 at 06:01:16PM -0400, Andrew Kuchling wrote: > On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond wrote: > >Wrong answer. The right answer is to fix lambda (or some variant of lambda) > >to be a true lexical closure. > > Hm... hmmmm... fixing this has been suggested before, but always > foundered on the fact that creating a closure required a cycle, which > would leak memory. Now we have an optional GC that should handle > this, so maybe fixing it can be revisited. (But this would mean that > GC is essentially no longer optional -- maybe too radical a thing to > do before we're sure about the new GC. 2.1, maybe?) I would like to get the memory consumption down before making GC standard. Hopefully Vladimir and I can team up to accomplish this. still-waiting-for-my-home-machine-ly Neil From tim_one@email.msn.com Tue Jul 25 23:57:44 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 18:57:44 -0400 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: <20000725152832.A2019@thyrsus.com> Message-ID: [Eric S. Raymond] > ... > The right way to say > > [x**2 for x in range(1, 99) if isprime(x)] > > is like this: > > [x**2 for x in filter(isprime, range(1, 99)] > ... > If you notice that this looks a lot like LISP or F or Haskell, you win. Win some, lose some: the original looks much more like Haskell, from which Greg Ewing borrowed list comprehensions: [x**2, x <- [1..98], isprime(x)] (Note: that's from memory, as I don't have Haskell on my laptop; while a detail may be wrong (in particular, I don't recall how Haskell spells "square"), the thrust is not: Haskell allows an arbitrary sequence of iterators and predicates, exactly as does the proposal. It's formally defined in terms of expansion to masses of lambdas and applications, but the whole point to the Haskell spelling is to raise the expressiveness above the LISP level] > These languages got comprehensions right on the basis of a lot of > experience in depth. We can learn from their example. Indeed, we're trying to . This is much more a Haskell than a LISP feature, and follows Haskell in using special syntax to relieve the monotony of relentlessly uniform function composition. It derives in turn from SETL, which followed common set-theoretic notation. This "grabbed" Guido; LISP spellings never did, and I bet never will. Indeed, your latter spelling is so close to the current map(lambda x: x**2, filter(isprime, range(1, 99)) as to make little difference. From trentm@activestate.com Wed Jul 26 00:02:59 2000 From: trentm@activestate.com (Trent Mick) Date: Tue, 25 Jul 2000 16:02:59 -0700 Subject: [Python-Dev] Summary or failing regression tests... In-Reply-To: <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> Message-ID: <20000725160259.C21409@ActiveState.com> On Wed, Jul 26, 2000 at 12:47:21AM +0000, Peter Schneider-Kamp wrote: > Trent Mick wrote: > > > > On Linux32: > > - test_fork1 > > This fails/hangs/crashes inconsistently because (some little bird told me) > > the fork stuff and threads are incompatible. Am I right? Now that we are > > turning threads on by default what is the proper thing to do here? SHould > > test_fork1 be changed to skip if threads are enabled? > > That works fine to me (--with-threads). > 'test_fork1' works for me when run as: ./python Lib/test/regrtest.py but hangs when run as: ./python Lib/test/test_fork1.py or ./python Lib/test/regrtest.py test_fork1 I don't know why? Trent -- Trent Mick TrentM@ActiveState.com From tim_one@email.msn.com Wed Jul 26 00:03:59 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 19:03:59 -0400 Subject: Closures (was RE: [Python-Dev] Product iteration) In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > Hm... hmmmm... fixing this has been suggested before, but always > foundered on the fact that creating a closure required a cycle, which > would leak memory. Now we have an optional GC that should handle > this, so maybe fixing it can be revisited. (But this would mean that > GC is essentially no longer optional -- maybe too radical a thing to > do before we're sure about the new GC. 2.1, maybe?) Definitely PEP material: let's please, please, please not have this entire debate again. BTW, I'm having trouble believing the release schedule for 1.6 and 2.0 without this, so definitely post-2.0 on those grounds alone. From billtut@microsoft.com Wed Jul 26 00:03:00 2000 From: billtut@microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 16:03:00 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> Well, I can't check it in, so assigning it back to me would be fairly pointless. Someone should also chime in on the Tools/perfecthash stuff as well. If we want to keep it, I'll see if I can come up with an example using Python's tokens since the data set is way smaller. :) Bill -----Original Message----- From: 'Trent Mick' [mailto:trentm@activestate.com] Sent: Tuesday, July 25, 2000 3:55 PM To: Bill Tutt Cc: Jeremy Hylton; M . -A . Lemburg; Mark Favas; Fredrik Lundh; python-dev@python.org Subject: Re: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs On Tue, Jul 25, 2000 at 12:08:57PM -0700, Bill Tutt wrote: > Well, Fredrik's changes aren't checked in yet, so checking it all in doesn't > hurt. > > The other relevant question is since Fredrik's code will eventually get in, > do we want to yank the code that generates it? > (Tools/perfecthash) If we keep it, then that part of the patch should go in. > If we don't keep it, that's fine too. > > You'd need to test it on Linux64. Win64's integer types are 32bits, and the > C code doesn't use long longs. > The easiest way of testing it of course is to apply the ucnhash.c patch to > your tree and run test_ucn.py. :) Okay. I tried it and with the patch test_ucn.py passes fine. I am going to add a comment to the patch on SourceForge and then assigned it back to.... hmmmm... eenie meenie minie... Bill! Is that alright? Trent -- Trent Mick TrentM@ActiveState.com From trentm@activestate.com Wed Jul 26 00:06:37 2000 From: trentm@activestate.com ('Trent Mick') Date: Tue, 25 Jul 2000 16:06:37 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> Message-ID: <20000725160637.A21687@ActiveState.com> On Tue, Jul 25, 2000 at 04:03:00PM -0700, Bill Tutt wrote: > Well, I can't check it in, so assigning it back to me would be fairly > pointless. Very sneaky. I defaulted to Jeremy. Trent -- Trent Mick TrentM@ActiveState.com From guido@beopen.com Wed Jul 26 01:12:23 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 19:12:23 -0500 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs In-Reply-To: Your message of "Tue, 25 Jul 2000 16:03:00 MST." <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> Message-ID: <200007260012.TAA31561@cj20424-a.reston1.va.home.com> > Well, I can't check it in, so assigning it back to me would be fairly > pointless. Someone should also chime in on the Tools/perfecthash stuff as > well. If we want to keep it, I'll see if I can come up with an example > using Python's tokens since the data set is way smaller. :) I've learned from the sad NumPy experience that it's really bad to generate code and then throw away the generator and start editing the generated code... So please keep the generator up-to-date! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From bwarsaw@beopen.com Wed Jul 26 00:13:56 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 19:13:56 -0400 (EDT) Subject: [PEP202 listcomps] (was RE: [Python-Dev] List comprehension syntax (Features for Python 2.0)) References: <397E0A75.6F49041E@lemburg.com> Message-ID: <14718.7988.542661.35195@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> I'll note that everything "looks strange" the first time you TP> see it. It's more important that it feels right after you TP> grasp it. It's the "Pink Floyd" syndrome. A new band of mine is searching for a name, and all of them seem dumb the first time you say them. 35 years and tens of millions of records later, and even "Pink Floyd" seems like a brilliant name for a band. hoping-to-have-the-same-problem-ly y'rs, -Barry From mhammond@skippinet.com.au Wed Jul 26 00:12:03 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 26 Jul 2000 09:12:03 +1000 Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725120319.E32196@kronos.cnri.reston.va.us> Message-ID: > Is it OK to add a SWIG-generated module to the core? That is a little tricky. Longer term it should be reasonable. However, there are a few reasonable objections that I will have trouble defending (the most obvious one being a more complex build system) > (I have an irrational dislike SWIG's trick of encoding pointers > as strings, I think your fear is completely rational! However, take heart in the fact that I have _many_ SWIG extension modules, and have _never_ had SWIG generate a pointer on me. It often takes some hoop jumping, and requires some hand-coded helpers, but SWIG still saves me time, while providing a rock-solid interface. If SWIG code does end up in the core, I would prefer to see SWIG pointers banned! Mark. From Fredrik Lundh" Message-ID: <007601bff68f$0871dfa0$f2a6b5d4@hagrid> as for your other errors (still on Win95, MSVC 5.0): > - test_mmap > one liner: > test test_mmap crashed -- exceptions.WindowsError : [Errno 6] The = handle is invalid same here (but a different error code?) > - test_posixpath > one liner: > test test_posixpath failed -- Writing: 'error!', expected: 'No = err' nope. > - test_re > one liner: > test test_re failed -- Writing: '=3D=3D=3D Failed incorrectly', = expected: "('abc', 'abc', 0, 'fou" nope. but are you sure you've updated the output directory lately? the "=3D=3D=3D Failed incorrectly" part is expected, the abc stuff is not. > Traceback (most recent call last): > File "..\Lib\test\test_re.py", line 122, in ? > raise TestFailed, "symbolic reference" > test_support.TestFailed: symbolic reference nope. > - test_sre > one liner: > test test_sre failed -- Writing: '=3D=3D=3D Failed incorrectly', = expected: "=3D=3D=3Dgrouping error ('(" nope. but again, the expected stuff looks wrong. > Traceback (most recent call last): > File "..\Lib\test\test_sre.py", line 124, in ? > raise TestFailed, "symbolic reference" > test_support.TestFailed: symbolic reference nope. > - test_userstring > one liner: > test test_userstring failed -- Writing: "'a'", expected: '' nope -- but the output indicates that you're testing against an old copy of UserString.py >=20 > - test_winreg > one liner: > test test_winreg failed -- Unread: '\012' nope. =20 > - test_winreg2 (crashes) > full output:=20 > Fatal Python error: PyThreadState_Get: no current thread >=20 > abnormal program termination almost. I got other interesting errors when I had an old winreg.pyd in the path. if I remove that one, the test runs, prints HKEY_CLASSES_ROOT, and then starts consuming 99.99% CPU (not sure if it terminates; I need my cycles for more important stuff...) From billtut@microsoft.com Wed Jul 26 00:14:03 2000 From: billtut@microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 16:14:03 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> The patch for the generator is up to date. The question is "Should we keep Tools/perfecthash in CVS after Fredrick checks in his new unicode name support?" Bill -----Original Message----- From: Guido van Rossum [mailto:guido@beopen.com] Sent: Tuesday, July 25, 2000 5:12 PM To: Bill Tutt Cc: python-dev@python.org Subject: Re: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs > Well, I can't check it in, so assigning it back to me would be fairly > pointless. Someone should also chime in on the Tools/perfecthash stuff as > well. If we want to keep it, I'll see if I can come up with an example > using Python's tokens since the data set is way smaller. :) I've learned from the sad NumPy experience that it's really bad to generate code and then throw away the generator and start editing the generated code... So please keep the generator up-to-date! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Wed Jul 26 01:19:05 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 19:19:05 -0500 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: Your message of "Tue, 25 Jul 2000 18:57:44 -0400." References: Message-ID: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> > It derives in turn from SETL, which followed common set-theoretic > notation. This "grabbed" Guido; LISP spellings never did, and I bet > never will. I've never used or even seen SETL, but there is a connection: SETL had a profound influence on the designers of ABC, in particular Lambert Meertens, who spent a sabbatical year working with the folks at New York University who wrote the first validated Ada compiler in SETL. (http://www.faqs.org/faqs/computer-lang/Ada/comp-lang-ada/part2/ question 4.2.2, to save you the Google search.) I happen to have a standing invitation to come give a talk there... Since I'm posting in this thread anyway, I am with Tim -- I like Greg Ewing's proposed syntax best, for the reasons Tim stated. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Wed Jul 26 01:23:12 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 19:23:12 -0500 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs In-Reply-To: Your message of "Tue, 25 Jul 2000 16:14:03 MST." <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> Message-ID: <200007260023.TAA31667@cj20424-a.reston1.va.home.com> > The patch for the generator is up to date. The question is "Should we keep > Tools/perfecthash in CVS after Fredrick checks in his new unicode name > support?" Oh, never mind. I'd say keep it around -- it's a cool thing for which eventually someone will find a use! (But it should really be up to Andrew -- if he prefers to have it on his webpage instead, we should honor that.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Fredrik Lundh" = 32bit longs References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> <200007260012.TAA31561@cj20424-a.reston1.va.home.com> Message-ID: <009101bff691$d9b3e700$f2a6b5d4@hagrid> guido wrote: > > Well, I can't check it in, so assigning it back to me would be = fairly > > pointless. Someone should also chime in on the Tools/perfecthash = stuff as > > well. If we want to keep it, I'll see if I can come up with an = example > > using Python's tokens since the data set is way smaller. :) >=20 > I've learned from the sad NumPy experience that it's really bad to > generate code and then throw away the generator and start editing the > generated code... So please keep the generator up-to-date! note that if #100899 goes in instead, Bill's tweak of Andrew's original code won't be needed for anything related to unicode. the perfect hash module is still a useful tool (not that I ever got it to do a decent job on the unicode database. Bill's either very lucky, or he's got a really fast computer... ;-) From akuchlin@mems-exchange.org Wed Jul 26 00:58:28 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 19:58:28 -0400 Subject: [Python-Dev] is this obsolete? In-Reply-To: <200007260023.TAA31667@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 07:23:12PM -0500 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> <200007260023.TAA31667@cj20424-a.reston1.va.home.com> Message-ID: <20000725195828.A19959@newcnri.cnri.reston.va.us> On Tue, Jul 25, 2000 at 07:23:12PM -0500, Guido van Rossum wrote: >Oh, never mind. I'd say keep it around -- it's a cool thing for which >eventually someone will find a use! (But it should really be up to >Andrew -- if he prefers to have it on his webpage instead, we should >honor that.) It seems too esoteric to take up space in the Tools/ directory, so I'd suggest taking it out. I'll look at Bill's changes and grab interesting bits for my copy, though. --amk From Fredrik Lundh" (revisiting an old thread on mixed string comparisions) summary: the current interpreter throws an "ASCII decoding error" exception if you compare 8-bit and unicode strings, and the 8-bit string happen to contain a character in the 128-255 range. this is not only confusing for users, it also confuses the hell out of Python itself. for example: >>> a =3D u"=E4" >>> b =3D "=E4" >>> hash(a) -283818363 >>> hash(b) -283818363 >>> a =3D=3D b Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII decoding error: ordinal not in range(128) >>> d =3D {} >>> d[a] =3D "a" >>> d[b] =3D "b" >>> len(d) UnicodeError: ASCII decoding error: ordinal not in range(128) oops. ::: it's clear that we should do something about this, but it's not entirely clear what do to. quoting from the earlier thread: [paul] > As soon as you find a character out of the ASCII range in one of the > strings, I think that you should report that the two strings are > unequal. [me] > sounds reasonable -- but how do you flag "unequal" in cmp? which > value is "larger" if all that we know is that they're different... [moshe] > We can say something like "beyond the ASCII range, every unicode = character > is larger then any regular 8-bit character", and compare > lexicographically. [mal] > The usual method in the Python compare logic is to revert to > the type name for compares in case coercion fails... I think > this is the right description in this case: decoding fails and > thus coercion becomes impossible. >=20 > PyObject_Compare() has the logic, we'd just have to reenable > it for Unicode which currently is handled as special case to > pass through the decoding error. >=20 > Note that Unicode objects which don't coerce would then always > compare larger than 8-bit strings ("unicode" > "string"). ::: having digested this for a week or two, I'm leaning towards moshe's proposal. even if mal's proposal will give the same result in practice, I'm not entirely happy with the idea that the actual contents of a variable (and not just its type) should determine whether the "last resort" type name comparision should be used. a third alternative would be to keep the exception, and make the dictionary code exception proof. having looked at the code, I'm afraid this might be easier said than done... ::: comments? From billtut@microsoft.com Wed Jul 26 01:27:09 2000 From: billtut@microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 17:27:09 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD330@RED-MSG-50> > From: Fredrik Lundh [mailto:effbot@telia.com] > note that if #100899 goes in instead, Bill's tweak of Andrew's > original code won't be needed for anything related to unicode. > the perfect hash module is still a useful tool (not that I ever > got it to do a decent job on the unicode database. Bill's either > very lucky, or he's got a really fast computer... ;-) The secret to getting it to work is to start with a high step rate, find your initial solution so you can test code. Then you set the code up to search for a smaller solution while you're off doing weekend things. Given the number of Unicode character names there wasn't any other way to do it. Smaller key spaces may not care about finding a smaller multiplier solution. I do like my work computer though. Dual 733Mhz with 512MB of ram. Have to have lots of ram to test a web app that caches 30 MB of data out of the database, while still running DevStudio, VSS, etc.... :) Bill From guido@beopen.com Wed Jul 26 04:02:14 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 22:02:14 -0500 Subject: [Python-Dev] is this obsolete? In-Reply-To: Your message of "Tue, 25 Jul 2000 19:58:28 -0400." <20000725195828.A19959@newcnri.cnri.reston.va.us> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> <200007260023.TAA31667@cj20424-a.reston1.va.home.com> <20000725195828.A19959@newcnri.cnri.reston.va.us> Message-ID: <200007260302.WAA31854@cj20424-a.reston1.va.home.com> > It seems too esoteric to take up space in the Tools/ directory, so I'd > suggest taking it out. I'll look at Bill's changes and grab > interesting bits for my copy, though. OK. Please take it out yourself! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Wed Jul 26 04:11:05 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 22:11:05 -0500 Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: Your message of "Wed, 26 Jul 2000 02:09:48 +0200." <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> Message-ID: <200007260311.WAA31872@cj20424-a.reston1.va.home.com> > (revisiting an old thread on mixed string comparisions) I think it's PEP time for this one... > summary: the current interpreter throws an "ASCII decoding > error" exception if you compare 8-bit and unicode strings, and > the 8-bit string happen to contain a character in the 128-255 > range. Doesn't bother me at all. If I write a user-defined class that raises an exception in __cmp__ you can get the same behavior. The fact that the hashes were the same is a red herring; there are plenty of values with the same hash that aren't equal. I see the exception as a useful warning that the program isn't sufficiently Unicode aware to work correctly. That's a *good* thing in my book -- I'd rather raise an exception than silently fail. Note that it can't break old code unless you try to do new things with the old code: the old code coudn't have supported Unicode because it doesn't exist in Python 1.5.2. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From greg@cosc.canterbury.ac.nz Wed Jul 26 03:49:16 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 14:49:16 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: Message-ID: <200007260249.OAA09513@s454.cosc.canterbury.ac.nz> Moshe Zadka said: > [x; for x in seq] > > and > > [x: for x in seq] Having both the separator and the following 'for' looks somewhat redundant to my eyes. By the way, have people tried looking at some examples in an editor with syntax highlighting? You may find that the various parts stand out more clearly then -- I certainly do. > And what about > > [x+y for x in seq1 for y in seq2 if y>2 if x<3] > > or > > [x+y for x in seq1 if x<3 for y in seq2 if y>2] > > What is allowed? Both are allowed, and both are useful. They produce the same result, but the second one is more efficient. So you can either write declaratively and not worry about the order, or if you're concerned about speed, you can fine-tune the order of the clauses. > Aren't we being a bit too TIMTOWTDIish here? No more than being able to say either x = (a+b); y = (c+d); h = sqrt(x*x + y*y) or h = sqrt((a+b)*(a+b) + (c+d)*(c+d)) Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From greg@cosc.canterbury.ac.nz Wed Jul 26 03:52:31 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 14:52:31 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> Message-ID: <200007260252.OAA09516@s454.cosc.canterbury.ac.nz> > did Python just turn into something that is much harder to parse? Guido has already answered this, but just to make sure, I tried it out on my test implementation: s454% ./python Python 1.5.2 (#11, Sep 11 1999, 16:11:20) [GCC 2.8.1] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> seq = [1,2,3,4,5] >>> [x, x*2 for x in seq] [(1, 2), (2, 4), (3, 6), (4, 8), (5, 10)] >>> Yep, it works! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From greg@cosc.canterbury.ac.nz Wed Jul 26 03:59:14 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 14:59:14 +1200 (NZST) Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <20000725110000.C577@ActiveState.com> Message-ID: <200007260259.OAA09520@s454.cosc.canterbury.ac.nz> Trent Mick suggested: > [for x in [10,20,30]: for y in [1,2,3]: x+y] When designing the syntax, I decided to put the target expression first, because I wanted it to read declaratively. Also I think it's clearer when you can see right up front what it's going to be a list *of*. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From greg@cosc.canterbury.ac.nz Wed Jul 26 04:03:07 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 15:03:07 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: <14717.57165.155081.532709@beluga.mojam.com> Message-ID: <200007260303.PAA09523@s454.cosc.canterbury.ac.nz> Skip Montanaro suggested: > we just allow complete > statements within list constructors. The semantics would be that any > objects left on the stack at the end of the statements would constitute the > elements of the list. Is that too weird? It's too procedural, and too Forth-like. I think it's actually an advantage that the iterator clauses don't look *exactly* like their procedural counterparts, because it's less likely to fool you into thinking that you can put arbitrary statements there. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From greg@cosc.canterbury.ac.nz Wed Jul 26 04:07:10 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 15:07:10 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: <20000725152832.A2019@thyrsus.com> Message-ID: <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> "Eric S. Raymond" said: > What they want to be is an applicative sublanguage in functional > style Um, that might be what *you* want them to be, but it's the complete opposite of what *I* want them to be, which is a way of getting away from all those convoluted combinator constructs! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From gvwilson@nevex.com Wed Jul 26 04:08:49 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 25 Jul 2000 23:08:49 -0400 (EDT) Subject: [Python-Dev] list comprehension quiz Message-ID: Hi, folks. In order to put the list comprehension syntax questionnaire together, I would be grateful if anyone with a favorite syntax could send me their equivalent of the following scraps of Python (or other scraps and their equivalents, if you think there are interesting cases that I'm not covering). In order to save bandwidth, please mail me directly --- I will summarize and post the questionnaire itself. Thanks, Greg -- 1 ---------------------------------------- input = [1, 2, 3, 4, 5] output = [] for num in input: output.append(2 * num) >>> [2, 4, 6, 8, 10] -- 2 ---------------------------------------- input = [1, 2, 3, 4, 5] output = [] for num in input: if is_odd(num): output.append(num) >>> [1, 3, 5] -- 3 ---------------------------------------- input = [1, 2, 3, 4, 5] output = 0 for num in input: output = output + num >>> 15 -- 4 ---------------------------------------- tens = [10, 20, 30] units = [ 1, 2] output = [] for t in tens: for u in units: output.append(u + t) >>> [11, 12, 21, 22, 31, 32] -- 5 ---------------------------------------- tens = [10, 20, 30] units = [ 1, 2, 3, 4, 5] output = [] lim = min(len(tens), len(units)) for i in range(0, lim): output.append(max(tens[i], units[i])) >>> [10, 20, 30] -- 6 ---------------------------------------- phones = {229 : 'Greg', 231 : 'Toni', 268 : 'Jaq', 271 : 'Hassan'} output = [] for p in phones.keys(): if p > 250: output.append(phones[p]) >>> ['Hassan', 'Jaq'] From greg@cosc.canterbury.ac.nz Wed Jul 26 04:12:54 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 15:12:54 +1200 (NZST) Subject: [Python-Dev] Names for things In-Reply-To: <14718.7988.542661.35195@anthem.concentric.net> Message-ID: <200007260312.PAA09530@s454.cosc.canterbury.ac.nz> bwarsaw@beopen.com (Barry A. Warsaw): > 35 years and tens of millions of records later, and even "Pink Floyd" seems > like a brilliant name for a band. And "Monty Python" is such an obviously good name for a comedy show... and "Python" for a programming language! Guido obviously used his time machine to plant the name in our minds a few decades ago to give us time to get used to the idea. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From tim_one@email.msn.com Wed Jul 26 04:11:53 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 23:11:53 -0400 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> Message-ID: [Greg Wilson] > I would also like to volunteer to repeat the "simultaneous loop" syntax > experiment with list comprehensions, i.e. see whether what's being > proposed lines up with people's pre-existing intuitions. [Guido] > Please do! > > Though I have no doubt of the outcome: > > [x+y for x in [10, 20, 30] for y in [1, 2, 3]] > > will be almost universally understood to mean > > [11, 12, 13, 21, 22, 23, 31, 32, 33]. I'm not sure about that! Greg hangs out with functional programmers and old Fortran-heads. Fortran has a handy construct called "implied DO (loops)" in I/O statements, and in those the *innermost* (leftmost) shorthand loop varies fastest. So I expect the Fortran'ers to guess [11, 21, 31, 12, 22, ...] I agree the experiment is worth trying, but I'm not sure we're observing anything other than experienced programmers' prior language-dependent conditioning ... which would also explain why neither Greg's functional nor Fortran guinea pigs had any concept of lockstep iteration across multiple loop controls. BTW, an MxN slice of a 2D array A in Fortran will often show up in an I/O stmt as ... ((A(I,J), I=1,M), J=1,N) ... and the "innermost fastest" rule relates directly to Fortran's oddball decision to use column-major array storage: the natural way to write the I/O using implied DOs caters to varying the first index fastest (== contiguous memory locations under column-major storage). It's not like there's a *profound* reason behind this . From esr@thyrsus.com Wed Jul 26 04:34:26 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 23:34:26 -0400 Subject: [Python-Dev] PEP202 In-Reply-To: <200007260307.PAA09527@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Jul 26, 2000 at 03:07:10PM +1200 References: <20000725152832.A2019@thyrsus.com> <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> Message-ID: <20000725233426.B3540@thyrsus.com> Greg Ewing : > > What they want to be is an applicative sublanguage in functional > > style > > Um, that might be what *you* want them to be, but it's the > complete opposite of what *I* want them to be, which is a > way of getting away from all those convoluted combinator > constructs! So your theory is that non-intuitive procedural syntax so complex that it *needs* usability testing is better. Riiiight... -- Eric S. Raymond "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy From akuchlin@mems-exchange.org Wed Jul 26 04:40:31 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 23:40:31 -0400 Subject: [Python-Dev] Names for things In-Reply-To: <200007260312.PAA09530@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Jul 26, 2000 at 03:12:54PM +1200 References: <14718.7988.542661.35195@anthem.concentric.net> <200007260312.PAA09530@s454.cosc.canterbury.ac.nz> Message-ID: <20000725234031.A20602@newcnri.cnri.reston.va.us> Regarding naming... I would recommend not wasting any more time on the naming issue. (This is a recurring theme in my posts -- remember, I spent about 0.3 microseconds thinking about whether "Python" would be a good name for a programming language, and I've never regretted it.) -- Guido van Rossum, 25 Nov 1998 From greg@cosc.canterbury.ac.nz Wed Jul 26 04:52:25 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 15:52:25 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: <20000725233426.B3540@thyrsus.com> Message-ID: <200007260352.PAA09543@s454.cosc.canterbury.ac.nz> > So your theory is that non-intuitive procedural syntax so complex that > it *needs* usability testing is better. It seems that our brains work in different ways here. What's clear to you is obscure to me, and vice versa. (I'm not the one that thinks it needs usability testing, by the way - that's a different Greg.) Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From jeremy@beopen.com Wed Jul 26 04:57:38 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 23:57:38 -0400 (EDT) Subject: [Python-Dev] PEP202 In-Reply-To: <20000725233426.B3540@thyrsus.com> References: <20000725152832.A2019@thyrsus.com> <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> <20000725233426.B3540@thyrsus.com> Message-ID: <14718.25010.135008.849218@bitdiddle.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> Greg Ewing : [>> ESR wrote:] >> > What they want to be is an applicative sublanguage in >> > functional style >> >> Um, that might be what *you* want them to be, but it's the >> complete opposite of what *I* want them to be, which is a way of >> getting away from all those convoluted combinator constructs! ESR> So your theory is that non-intuitive procedural syntax so ESR> complex that it *needs* usability testing is better. ESR> Riiiight... Wow! There's so much jargon being slung here I don't know what's going on. (For the second time in the last few weeks, I feel like a bit player in a movie where all the major roles are played by Peter Sellers. ) Seriously, I don't understand how to apply terms like "applicative sublanguage in functional style" or "procedural syntax" to a concept like list comprehensions. The basic idea is to express the elements of list using a set-like notation similar to the one used by mathematicians. I don't know whether to call that applicative, functional, or procedural; perhaps none of them applu. Maybe it's just late, but I suspect that these high-level terms don't inform the debate much. I think we can all agree on two things: 1. Greg and Eric have different goals, which is fine. 2. Usability testing is always a good thing. To paraphrase Fred Brooks, even the best language designers aren't so omniscient as to get it right the first time. Jeremy From skip@mojam.com (Skip Montanaro) Wed Jul 26 05:35:20 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 25 Jul 2000 23:35:20 -0500 (CDT) Subject: [Python-Dev] PEP202 In-Reply-To: <14718.25010.135008.849218@bitdiddle.concentric.net> References: <20000725152832.A2019@thyrsus.com> <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> <20000725233426.B3540@thyrsus.com> <14718.25010.135008.849218@bitdiddle.concentric.net> Message-ID: <14718.27272.221884.457831@beluga.mojam.com> Jeremy> 2. Usability testing is always a good thing. To paraphrase Fred Jeremy> Brooks, even the best language designers aren't so omniscient Jeremy> as to get it right the first time. Though Guido came damn close... ;-) S From esr@thyrsus.com Wed Jul 26 05:55:26 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 26 Jul 2000 00:55:26 -0400 Subject: [Python-Dev] PEP202 -- glossary of terms In-Reply-To: <14718.25010.135008.849218@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 25, 2000 at 11:57:38PM -0400 References: <20000725152832.A2019@thyrsus.com> <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> <20000725233426.B3540@thyrsus.com> <14718.25010.135008.849218@bitdiddle.concentric.net> Message-ID: <20000726005526.A3796@thyrsus.com> Jeremy Hylton : > Seriously, I don't understand how to apply terms like "applicative > sublanguage in functional style" or "procedural syntax" to a concept > like list comprehensions. The basic idea is to express the elements > of list using a set-like notation similar to the one used by > mathematicians. I don't know whether to call that applicative, > functional, or procedural; perhaps none of them applu. Maybe it's > just late, but I suspect that these high-level terms don't inform the > debate much. Partly this is my error; I should have said "conventional" or "infix" where I said "procedural". I was writing too fast -- procedural languages are conventional in a different way, but I was referring to conventional syntax. More generally, I guess I have to apologize for excessive use of jargon without enough context. The crowd on this list is so fearsomely competent that I tend to forget that most of you don't have a technical specialty in language design. Here's a brief glossary of relevant language-designer jargon: functional style: Refers to a language in which everything is pure function calls, without side-effects or variables. Backus's F is one of the better-known examples. LISP would be functional if there were no (setq ...). The advantage of functional language is the same as their disadvantage: no side-effects. Makes them easy to reason about, but you have to jump through hoops to do statefulness. procedural style: A procedural language has procedures that operate on variables. Explicit statefulness and side-effects are basic to such languages. applicative sublanguage: This is more about syntax. To say a syntax is applicative is to say that it *looks* like cascaded function calls, as opposed (for example) to using infix syntax or keywords. (This is oversimplifying a little; Haskell combines keywords with a syntax that could be called applicative, but Haskell is weird by design that way.) imperative vs. declarative: In an imperative language, you tell the machine to do stuff. In a declarative language you specify a desired end state and let the language implementation deduce how to generate it. A good example of a declarative sublanguage familiar to most Python programers is Tk widget layout. List comprehensions are declarative in style, even though they analyze down to a series of imperative actions. Most of Python is much more straightforwardly imperative. One of the heuristics of good language design is that boundaries between imperative and declarative sublanguages are always tricky -- users have a strong tendency to try to port concepts across the boundary and get confused. This is behind some of the confusion about comprehensions. conventional: Means different things in different contexts. When speaking of syntax, it means pseudo-algebraic syntax with infix notation and keyords. In other contexts, it can mean procedural rather than functional, or manual memory management rather than garbage collection, or fixed-extent vs. unlimited-extent. The archetypal conventional language is Algol-60. For you young 'uns out there, think Pascal. -- Eric S. Raymond From Moshe Zadka Wed Jul 26 05:54:50 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 26 Jul 2000 07:54:50 +0300 (IDT) Subject: [Python-Dev] Meta: pep-dev (was Re: [PEP 2-0-2 listcomps] (was RE: [Python-Dev] Product iteration)) In-Reply-To: Message-ID: (Added hiphens in 2-0-2 to keep out of the timbot's radar) On Tue, 25 Jul 2000, Tim Peters wrote: > A pep-dev mailing list is clearly a very good idea, but until one is set up > I'm afraid python-dev is the only natural place to bear the unbearable (to > some) pep-dev traffic. It seems that the correct solution is not a big "pep-dev", but rather a "pep-[1-9][0-9]*-dev" lists, one for each pep. So I'll just sit back quietly and wait for ?!in to suggest roundup for this. Then we'll Barry see how he can easily make mailman do this. <202 wink> last-man-coding-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From Moshe Zadka Wed Jul 26 08:09:51 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 26 Jul 2000 10:09:51 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: On Tue, 25 Jul 2000, Andrew Kuchling wrote: > On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond wrote: > >Wrong answer. The right answer is to fix lambda (or some variant of lambda) > >to be a true lexical closure. > > Hm... hmmmm... fixing this has been suggested before, but always > foundered on the fact that creating a closure required a cycle, which > would leak memory. Now we have an optional GC that should handle > this, so maybe fixing it can be revisited. (But this would mean that > GC is essentially no longer optional -- maybe too radical a thing to > do before we're sure about the new GC. 2.1, maybe?) I think I'd rather have this solved by weak references then by building cycles. Cycles are evil even in the face of GC -- you have undetermined finalization. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From nowonder@pool.informatik.rwth-aachen.de Wed Jul 26 09:10:40 2000 From: nowonder@pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Wed, 26 Jul 2000 08:10:40 +0000 Subject: [Python-Dev] Summary or failing regression tests... References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> Message-ID: <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> Trent Mick wrote: > > 'test_fork1' works for me when run as: > ./python Lib/test/regrtest.py > > but hangs when run as: > ./python Lib/test/test_fork1.py > or > ./python Lib/test/regrtest.py test_fork1 On my system there is no problem: nowonder@mobility:~/python/python/dist/src > ./python Lib/test/test_fork1.py nowonder@mobility:~/python/python/dist/src > ./python Lib/test/regrtest.py test_fork1 test_fork1 1 test OK. I am using a (somewhat modified) SuSE 6.4 distribution with an old 2.2.13 kernel. What does your's look like? Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Fredrik Lundh" <200007260311.WAA31872@cj20424-a.reston1.va.home.com> Message-ID: <00a601bff6d6$12f14820$f2a6b5d4@hagrid> guido wrote: > > summary: the current interpreter throws an "ASCII decoding > > error" exception if you compare 8-bit and unicode strings, and > > the 8-bit string happen to contain a character in the 128-255 > > range. >=20 > Doesn't bother me at all. If I write a user-defined class that raises > an exception in __cmp__ you can get the same behavior. The fact that > the hashes were the same is a red herring; there are plenty of values > with the same hash that aren't equal. >=20 > I see the exception as a useful warning that the program isn't > sufficiently Unicode aware to work correctly. That's a *good* thing > in my book -- I'd rather raise an exception than silently fail. I assume that means you're voting for alternative 3: "a third alternative would be to keep the exception, and make the dictionary code exception proof." because the following isn't exactly good behaviour: >>> a =3D "=84" >>> b =3D unicode(a, "iso-8859-1") >>> d =3D {} >>> d[a] =3D "a" >>> d[b] =3D "b" >>> len(d) UnicodeError: ASCII decoding error: ordinal not in range(128) >>> len(d) 2 (in other words, the dictionary implementation misbehaves if items with the same hash value cannot be successfully compared) From tim_one@email.msn.com Wed Jul 26 09:09:27 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 26 Jul 2000 04:09:27 -0400 Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: <00a601bff6d6$12f14820$f2a6b5d4@hagrid> Message-ID: [Guido] > ... > I see the exception as a useful warning that the program isn't > sufficiently Unicode aware to work correctly. That's a *good* thing > in my book -- I'd rather raise an exception than silently fail. [Fredrik Lundh] > I assume that means you're voting for alternative 3: > > "a third alternative would be to keep the exception, and make > the dictionary code exception proof." > > because the following isn't exactly good behaviour: > > >>> a = "„" > >>> b = unicode(a, "iso-8859-1") > >>> d = {} > >>> d[a] = "a" > >>> d[b] = "b" > >>> len(d) > UnicodeError: ASCII decoding error: ordinal not in range(128) > >>> len(d) > 2 > > (in other words, the dictionary implementation misbehaves if items > with the same hash value cannot be successfully compared) Hmm. That's a bug in the dict implementation that's independent of Unicode issues, then -- and I can provoke similar behavior with classes that raise exceptions from __cmp__, without using Unicode anywhere. So, ya, the dict bugs have to be fixed. Nobody needs to vote on *that* part . I'll look into it "soon", unless somebody else does first. From mal@lemburg.com Wed Jul 26 09:11:40 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 26 Jul 2000 10:11:40 +0200 Subject: [Python-Dev] test_fork1.py failing (Summary or failing regression tests...) References: <20000725153912.A21409@ActiveState.com> Message-ID: <397E9D3C.9181A0E0@lemburg.com> Trent Mick wrote: > > Here is a list of the regrtests that are currently failing for me on Linux32 > and Win32. Is anybody looking at test_mmap, test_userstring, test_winreg, > and test_winreg2? > > Skip, You and Jeremy(?) were talking about test_posixpath on Linux. It looks > like the sames errors you were talking about occur on Win32. I didn't look > too closely, can you? > > Fredrik, are you aware of the test_sre failure on Win32? Am I doing something > wrong to be getting this? > > On Linux32: > - test_fork1 > This fails/hangs/crashes inconsistently because (some little bird told me) > the fork stuff and threads are incompatible. Am I right? Now that we are > turning threads on by default what is the proper thing to do here? SHould > test_fork1 be changed to skip if threads are enabled? Does this mean that a stock Python 1.6/2.0 interpreter will not properly do fork() on Linux32 (even when using threads) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Wed Jul 26 09:41:06 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 26 Jul 2000 10:41:06 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> Message-ID: <397EA422.3E785467@lemburg.com> Fredrik Lundh wrote: > > (revisiting an old thread on mixed string comparisions) > > summary: the current interpreter throws an "ASCII decoding > error" exception if you compare 8-bit and unicode strings, and > the 8-bit string happen to contain a character in the 128-255 > range. > > this is not only confusing for users, it also confuses the hell > out of Python itself. for example: > > >>> a = u"ä" > >>> b = "ä" > >>> hash(a) > -283818363 > >>> hash(b) > -283818363 > >>> a == b > Traceback (most recent call last): > File "", line 1, in ? > UnicodeError: ASCII decoding error: ordinal not in range(128) > >>> d = {} > >>> d[a] = "a" > >>> d[b] = "b" > >>> len(d) > UnicodeError: ASCII decoding error: ordinal not in range(128) > > oops. This is due to the fact that the Python dictionary lookup implementation doesn't properly treat exceptions raised during object compares -- this should probably be changed (e.g. the lookup procedure could clear the error just before returning to caller) ?! The Unicode implementation only makes this bug in the core visible because before that raising exceptions during compares was not a common thing to do. > ::: > > it's clear that we should do something about this, but it's > not entirely clear what do to. > > quoting from the earlier thread: > > [paul] > > As soon as you find a character out of the ASCII range in one of the > > strings, I think that you should report that the two strings are > > unequal. > > [me] > > sounds reasonable -- but how do you flag "unequal" in cmp? which > > value is "larger" if all that we know is that they're different... > > [moshe] > > We can say something like "beyond the ASCII range, every unicode character > > is larger then any regular 8-bit character", and compare > > lexicographically. > > [mal] > > The usual method in the Python compare logic is to revert to > > the type name for compares in case coercion fails... I think > > this is the right description in this case: decoding fails and > > thus coercion becomes impossible. > > > > PyObject_Compare() has the logic, we'd just have to reenable > > it for Unicode which currently is handled as special case to > > pass through the decoding error. > > > > Note that Unicode objects which don't coerce would then always > > compare larger than 8-bit strings ("unicode" > "string"). > > ::: > > having digested this for a week or two, I'm leaning towards > moshe's proposal. > > even if mal's proposal will give the same result in practice, I'm > not entirely happy with the idea that the actual contents of a > variable (and not just its type) should determine whether the > "last resort" type name comparision should be used. This has been the standard way of processing for years: if coercion fails (for whatever reason), go ahead and fall back to the type name compare. > a third alternative would be to keep the exception, and make > the dictionary code exception proof. having looked at the code, > I'm afraid this might be easier said than done... Right. Plus we'd have to be *very* careful about not introducing a performance problem here instead (after all, dict lookups are at the heart of what makes Python so cool). Note that we should look into this independent of the Unicode discussion: user code may very well raise exceptions too and the result would be a lingering exception state just like in the example above. > ::: > > comments? I'd say: mask the coercion error during compare in the standard way and remove the special casing for Unicode in PyObject_Compare(). Then as second step: rethink coercion altogether and possibly fix the situation in the compare operator of either strings or Unicode. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mhammond@skippinet.com.au Wed Jul 26 09:45:48 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 26 Jul 2000 18:45:48 +1000 Subject: [Python-Dev] Product iteration In-Reply-To: Message-ID: > I think I'd rather have this solved by weak references then by building > cycles. Cycles are evil even in the face of GC -- you have undetermined > finalization. It's worth pointing out that Python actually guarantees you may have undetermined finalization - it's just not an implementation requirement that it be that way. But-it-phrases-it-a-little-differently-than-that- ly, Mark. From Fredrik Lundh" <200007260019.TAA31620@cj20424-a.reston1.va.home.com> Message-ID: <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> guido wrote: > > It derives in turn from SETL, which followed common set-theoretic > > notation. This "grabbed" Guido; LISP spellings never did, and I bet > > never will. >=20 > I've never used or even seen SETL, but there is a connection: SETL had > a profound influence on the designers of ABC, in particular Lambert > Meertens, who spent a sabbatical year working with the folks at New > York University who wrote the first validated Ada compiler in SETL. found this one: http://www-robotics.eecs.lehigh.edu/~bacon/setlprog.ps.gz interesting reading. SETL sure has a pythonic feel... with a few improvements, of course (like the [start next end] range literals... too late to fix that in python, I suppose...) and personally, I prefer their "tuple former" syntax over the the current PEP202 proposal: [expression : iterator] [n : n in [1:100]] [(x**2, x) : x in [1:5]] [a : a in y if a > 5] (all examples are slightly pythonified; most notably, they use "|" or "st" (such that) instead of "if") the expression can be omitted if it's the same thing as the loop variable, *and* there's at least one "if" clause: [a in y if a > 5] also note that their "for-in" statement can take qualifiers: for a in y if a > 5: ... is there any special reason why we cannot use colon instead of "for"? From mal@lemburg.com Wed Jul 26 10:11:37 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 26 Jul 2000 11:11:37 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> <200007260311.WAA31872@cj20424-a.reston1.va.home.com> Message-ID: <397EAB49.8B5B0505@lemburg.com> Guido van Rossum wrote: > > > (revisiting an old thread on mixed string comparisions) > > I think it's PEP time for this one... > > > summary: the current interpreter throws an "ASCII decoding > > error" exception if you compare 8-bit and unicode strings, and > > the 8-bit string happen to contain a character in the 128-255 > > range. > > Doesn't bother me at all. If I write a user-defined class that raises > an exception in __cmp__ you can get the same behavior. The fact that > the hashes were the same is a red herring; there are plenty of values > with the same hash that aren't equal. > > I see the exception as a useful warning that the program isn't > sufficiently Unicode aware to work correctly. That's a *good* thing > in my book -- I'd rather raise an exception than silently fail. > > Note that it can't break old code unless you try to do new things with > the old code: the old code coudn't have supported Unicode because it > doesn't exist in Python 1.5.2. Hmm, so you do want exceptions to be raised for coercion errors during compare ? For the record: PyObject_Compare() currently only does coercion for number slot compatible types (ok, all Python instances have these slots...). Unicode objects are handled in a special case to allow the PyUnicode_Compare() API to do all necessary conversions and then proceed with the compare. The coercion proposal will have to deal with all this in 2.1. My version of the proposal (see Python Pages) puts all the power into the hands of the operators themselves rather than using a centralized coercion method. In this scenario, the special casing in PyObject_Compare() for Unicode would no longer be necessary, since the Unicode compare slot could then take care of the needed conversions (essentially PyUnicode_Compare() would beceom that slot). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From nowonder@pool.informatik.rwth-aachen.de Wed Jul 26 12:24:44 2000 From: nowonder@pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Wed, 26 Jul 2000 11:24:44 +0000 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> Message-ID: <397ECA7C.E872636C@pool.informatik.rwth-aachen.de> [Fredrik Lundh] > > and personally, I prefer their "tuple former" syntax over the the > current PEP202 proposal: > > [expression : iterator] > > [n : n in [1:100]] > [(x**2, x) : x in [1:5]] > [a : a in y if a > 5] Funny. I send a mail to Tim this morning with a similar proposal: [Peter] > > Not being too happy with the proposed syntaxes I came up > with a new one. > > I think it is much better to parse (for human readers), > but I am open about ';' as the delimiter. ':' would feel > very fine to me, too. > > Syntax: > [; , , ...] > > Example for semantics: > [x+y; x in [1, 2, 3], x <= 2, y in [10, 20, 30], y in [5, 10, 20]] > == [11, 21, 12, 22] > > How to implement this example: > (only a sketch, this will probably be too slow to > really do it like this, but maybe you get the idea > that it is at least possible to do it) > 1) set baselist_for_x and baselist_for_y to > something special (None?) indicating all possible > values for x and y (they are unconstrained) > 2) on encountering "x in [1, 2, 3]" set > baselist_for_x to [1, 2, 3] > 3) on encountering "x <= 2" filter baselist_for_x > and get [1, 2] > 4) on encountering "y in [10, 20, 30]" set > baselist_for_y to [10, 20, 30] > 5) on encountering "y in [5, 10, 20] see that > baselist_for_y != special value (None?) and so > filter baselist_for_y and get [10, 20] > 6) produce cross product of baselist_for_x > and baselist_for_y > 7) apply expression to elements of cross product > > The general idea is to start with lists of all > possible values (represented by a special value) > and use the conditions in the list comprehension > to constrain that list. If we don't want to deal > with infinite lists (and therefore lazy stuff) > we could through an ConstraintError on the following: > > >>> [x; x > 10000] > ConstraintError: missing sequence constraint for x The difference (besides ';' against ':') is the use of commas for seperation and not using if. [Fredrik Lundh] > is there any special reason why we cannot use colon instead > of "for"? There seem to be some reasons, but I am not sure I have understood them. Probably I'll best quote from Tim's reply: [Tim Peters] > That said, I can guarantee Guido will hate that in > > > [x+y; x in [1, 2, 3], x <= 2, y in [10, 20, 30], y in [5, 10, 20]] > > you have > y in [...] > meaning iteration in one position but have it meaning a filter in another. No. I have it mean filter in all cases. That's just implementation. [Tim Peters] > The syntax is also deadly ambiguous: > x <= 2 > is a legit Python expression today, but so is > x <= 2, y > and so is > x <= 2, y in [10, 20, 30] > and so is > x <= 2, y in [10, 20, 30], y > etc. This syntax is simply unparsable given the uses for commas in Python's > existing expression syntax. That's one reason "for" and "if" have been in > every other proposal for at least the last year . Wouldn't it be possible to just parse the first part (before the delimiter - be it ';' or ':') as an expression and allow a tuple of boolean expressions after the delimiter? Picture list comprehensions as list constraints. With [x,y: x in list1, y in list2, x > 10, odd(y)] I say that I want to have all tuples of x and y who satisfy the following constraints: - x is an element of list1 and greater than 10 - y is an element of list2 and odd For the parser the following cases would both be valid: [x+y: x in list1, y in list2] [(x+y): (x in list1, y in list2)] The latter would be what Python sees, but given that parentheses are optional for expressions and tuple building the former would be legal python. [Tim Peters] > Don't mean to be discouraging, but looks like you missed the first year of > this debate! Actually I think I did. But then I didn't even know about Python 4 months ago. newbie-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gmcm@hypernet.com Wed Jul 26 10:32:11 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Wed, 26 Jul 2000 05:32:11 -0400 Subject: [Python-Dev] PEP202 In-Reply-To: <20000725233426.B3540@thyrsus.com> References: <200007260307.PAA09527@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Jul 26, 2000 at 03:07:10PM +1200 Message-ID: <1247518565-39631569@hypernet.com> > So your theory is that non-intuitive procedural syntax ... C'mon Eric. The only intuitive syntax is: - the grunt - the scream - the laugh - "Well Helloooo sailor" -and-3-of-those-are-ambiguous-ly y'rs - Gordon From mal@lemburg.com Wed Jul 26 11:32:32 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 26 Jul 2000 12:32:32 +0200 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> Message-ID: <397EBE40.54E76DF4@lemburg.com> Fredrik Lundh wrote: > > SETL sure has a pythonic feel... > > with a few improvements, of course (like the [start next end] > range literals... too late to fix that in python, I suppose...) > > and personally, I prefer their "tuple former" syntax over the the > current PEP202 proposal: > > [expression : iterator] > > [n : n in [1:100]] > [(x**2, x) : x in [1:5]] > [a : a in y if a > 5] > > (all examples are slightly pythonified; most notably, they > use "|" or "st" (such that) instead of "if") > > the expression can be omitted if it's the same thing as the > loop variable, *and* there's at least one "if" clause: > > [a in y if a > 5] > > also note that their "for-in" statement can take qualifiers: > > for a in y if a > 5: > ... > > is there any special reason why we cannot use colon instead > of "for"? For mathematicians the [ : ] or [ | ] looks natural since it's their every day style of writing sets, but I doubt that CP4E users get the grasp of this. Anyway, whatever syntax you choose, please make sure that the and the parts are very well visibily separated. [ for in ] doesn't fall in that category, IMHO. Hehe, this is starting to get the feel of SQL with their horrible SELECT syntax: SELECT FROM WHERE ORDER BY etc. pp. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From m.favas@per.dem.csiro.au Wed Jul 26 11:40:04 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Wed, 26 Jul 2000 18:40:04 +0800 Subject: [Python-Dev] Sub-package import mechanism now broken? Message-ID: <397EC004.A73F815@per.dem.csiro.au> Have the sub-package import semantics changed, or is import broken in the current CVS? (still works in my last version of 1.6a2, and, yes, /usr/local/lib/python2.0/site-packages Python 2.0b1 (#208, Jul 26 2000, 14:54:31) [C] on osf1V4 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> import Pmw >>> from xml import * >>> from xml.sax import saxlib Traceback (most recent call last): File "", line 1, in ? ImportError: cannot import name saxlib >>> from xml.parsers.xmlproc import xmlproc Traceback (most recent call last): File "", line 1, in ? ImportError: No module named parsers.xmlproc >>> -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From guido@beopen.com Wed Jul 26 13:57:02 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 07:57:02 -0500 Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: Your message of "Wed, 26 Jul 2000 09:49:44 +0200." <00a601bff6d6$12f14820$f2a6b5d4@hagrid> References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> <200007260311.WAA31872@cj20424-a.reston1.va.home.com> <00a601bff6d6$12f14820$f2a6b5d4@hagrid> Message-ID: <200007261257.HAA01308@cj20424-a.reston1.va.home.com> > > I see the exception as a useful warning that the program isn't > > sufficiently Unicode aware to work correctly. That's a *good* thing > > in my book -- I'd rather raise an exception than silently fail. > > I assume that means you're voting for alternative 3: > > "a third alternative would be to keep the exception, and make > the dictionary code exception proof." Yes. > because the following isn't exactly good behaviour: > > >>> a = "„" > >>> b = unicode(a, "iso-8859-1") > >>> d = {} > >>> d[a] = "a" > >>> d[b] = "b" > >>> len(d) > UnicodeError: ASCII decoding error: ordinal not in range(128) > >>> len(d) > 2 > > (in other words, the dictionary implementation misbehaves if items > with the same hash value cannot be successfully compared) Good point. This would happen if you used flakey class instances as keys as well! (Note that the exception really happens on the d[b] = "b" statement; but because the dict implementation doesn't check for exceptions, it gets reported too late. We've seen this kind of bugs before in Python.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Wed Jul 26 14:00:33 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 08:00:33 -0500 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: Your message of "Wed, 26 Jul 2000 10:55:46 +0200." <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> Message-ID: <200007261300.IAA01335@cj20424-a.reston1.va.home.com> > is there any special reason why we cannot use colon instead > of "for"? Would conflict with the proposed syntax for range literals. Both [0:10] and [x : x in seq] have the same syntactical form. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Wed Jul 26 14:02:02 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 08:02:02 -0500 Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: Your message of "Wed, 26 Jul 2000 11:11:37 +0200." <397EAB49.8B5B0505@lemburg.com> References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> <200007260311.WAA31872@cj20424-a.reston1.va.home.com> <397EAB49.8B5B0505@lemburg.com> Message-ID: <200007261302.IAA01353@cj20424-a.reston1.va.home.com> > Hmm, so you do want exceptions to be raised for coercion errors > during compare ? Sure, fine. > For the record: > PyObject_Compare() currently only does coercion for number > slot compatible types (ok, all Python instances have these > slots...). Unicode objects are handled in a special case to > allow the PyUnicode_Compare() API to do all necessary conversions > and then proceed with the compare. > > The coercion proposal will have to deal with all this in 2.1. > > My version of the proposal (see Python Pages) puts all the power > into the hands of the operators themselves rather than using > a centralized coercion method. In this scenario, the special > casing in PyObject_Compare() for Unicode would no longer > be necessary, since the Unicode compare slot could then take > care of the needed conversions (essentially PyUnicode_Compare() > would beceom that slot). This all sounds okay to me -- I've signed off on that design (in principle) years ago... --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Wed Jul 26 14:12:20 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 08:12:20 -0500 Subject: [Python-Dev] Product iteration In-Reply-To: Your message of "Wed, 26 Jul 2000 10:09:51 +0300." References: Message-ID: <200007261312.IAA01454@cj20424-a.reston1.va.home.com> > > Hm... hmmmm... fixing this has been suggested before, but always > > foundered on the fact that creating a closure required a cycle, which > > would leak memory. Now we have an optional GC that should handle > > this, so maybe fixing it can be revisited. (But this would mean that > > GC is essentially no longer optional -- maybe too radical a thing to > > do before we're sure about the new GC. 2.1, maybe?) > > I think I'd rather have this solved by weak references then by building > cycles. Cycles are evil even in the face of GC -- you have undetermined > finalization. But in this case, there aren't any custom finalizers involved in the cycle (although there may be some *hanging off* the cycle). E.g. after: def f(): def g(): pass f() we have (taking some notational liberties and simplifications): globals = {'f': f} f.func_globals = globals locals = {'g': g} g.func_globals = locals # or maybe g.func_parent = locals In other words the cycles are between a dictionary and a function object: globals <--> f locals <--> g I don't see any finalization issues. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Moshe Zadka Wed Jul 26 13:21:00 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 26 Jul 2000 15:21:00 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <200007261312.IAA01454@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 26 Jul 2000, Guido van Rossum wrote: > > I think I'd rather have this solved by weak references then by building > > cycles. Cycles are evil even in the face of GC -- you have undetermined > > finalization. > > But in this case, there aren't any custom finalizers involved in the > cycle (although there may be some *hanging off* the cycle). Yes, but those finalizers hanging off the cycle would occur in some random time in the future, not right now, hence rendering the def f(): fp = open("fff") pass idiom dangerous, since you're not sure how long fp will remain open. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido@beopen.com Wed Jul 26 14:31:29 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 08:31:29 -0500 Subject: [Python-Dev] Product iteration In-Reply-To: Your message of "Wed, 26 Jul 2000 15:21:00 +0300." References: Message-ID: <200007261331.IAA01752@cj20424-a.reston1.va.home.com> > > But in this case, there aren't any custom finalizers involved in the > > cycle (although there may be some *hanging off* the cycle). > > Yes, but those finalizers hanging off the cycle would occur in some random > time in the future, not right now, hence rendering the > > def f(): > fp = open("fff") > pass > > idiom dangerous, since you're not sure how long fp will remain open. Aha. You're complaining about the finalizers being postponed arbitrarily. I thought you were complaining about the issue of finalization order *within* the cycle. Since this is still an improvement over current practice (where a finalizer hanging off a cycle may never be called) and there are no serialization issues, I don't see the problem. If you want to use weak references, please try to specify *in detail* which objects would have weak references to which other objects and how the system would resolve these... I'm never sure that things can be made 100% safe using this technique, so it may help to spell it out for me! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From m.favas@per.dem.csiro.au Wed Jul 26 14:11:11 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Wed, 26 Jul 2000 21:11:11 +0800 Subject: [Python-Dev] Sub-package import mechanism now broken? No, but... Message-ID: <397EE36F.59615826@per.dem.csiro.au> Opps - the import mechanism is not broken, it's just that the xml package in lib/site-packages no longer gets found, because of the new xml package in lib. This will still break existing code, unless the xml package in lib is renamed, has the same functionality as the PyXML package that installs in lib/site-packages, or has a method of handing off to the, um, more extensive site-package version... -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From jack@oratrix.nl Wed Jul 26 14:30:01 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 26 Jul 2000 15:30:01 +0200 Subject: [Python-Dev] ANSIfication. In-Reply-To: Message by Guido van Rossum , Tue, 25 Jul 2000 07:38:19 -0500 , <200007251238.HAA19158@cj20424-a.reston1.va.home.com> Message-ID: <20000726133002.4D95937186E@snelboot.oratrix.nl> > Frankly, I think that for *any* functions that are in some external > library (e.g. libc), Python should never provide a function prototype > at all. The standard headers should provide the prototypes! They should, but what if they don't? That's what I like about the pyport.h: it allows Python to build out of the box but still keeps all the cruft needed because some platforms don't have their act together in a single place. I know that I'm not expected to understand sections of pyport.h that are for platforms I'm not familiar with... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido@beopen.com Wed Jul 26 15:33:18 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 09:33:18 -0500 Subject: [Python-Dev] ANSIfication. In-Reply-To: Your message of "Wed, 26 Jul 2000 15:30:01 +0200." <20000726133002.4D95937186E@snelboot.oratrix.nl> References: <20000726133002.4D95937186E@snelboot.oratrix.nl> Message-ID: <200007261433.JAA02431@cj20424-a.reston1.va.home.com> [Guido] > > Frankly, I think that for *any* functions that are in some external > > library (e.g. libc), Python should never provide a function prototype > > at all. The standard headers should provide the prototypes! [Jack] > They should, but what if they don't? That's what I like about the > pyport.h: it allows Python to build out of the box but still keeps > all the cruft needed because some platforms don't have their act > together in a single place. I know that I'm not expected to > understand sections of pyport.h that are for platforms I'm not > familiar with... Exactly! But the point is that over the last 10 years we've collected an enormous amount of cruft in this area that's not needed any more, because platforms improve. So my proposal is to remove all the cruft for which we don't have positive confirmation that it's needed somewhere, and then add back whatever's necessary to support all esoteric platforms again. Not-saying-what's-considered-esoteric-ly, --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Moshe Zadka Wed Jul 26 14:33:46 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 26 Jul 2000 16:33:46 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <200007261331.IAA01752@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 26 Jul 2000, Guido van Rossum wrote: > Since this is still an improvement over current practice (where a > finalizer hanging off a cycle may never be called) and there are no > serialization issues, I don't see the problem. Today inner functions don't create cycles involving local variables. Lexical scoping would change that. > If you want to use weak references, please try to specify *in detail* > which objects would have weak references to which other objects and > how the system would resolve these... I'm never sure that things can > be made 100% safe using this technique, so it may help to spell it out > for me! OK, how's that: inner functions have weak reference to variables in the same scope def f(): x = 1 def g(): pass g would have only a weak reference to "x". I'm changing "no reference" to "weak reference", so I'm not incrementing effective reference counting. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido@beopen.com Wed Jul 26 15:44:05 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 09:44:05 -0500 Subject: [Python-Dev] Product iteration In-Reply-To: Your message of "Wed, 26 Jul 2000 16:33:46 +0300." References: Message-ID: <200007261444.JAA02518@cj20424-a.reston1.va.home.com> > Today inner functions don't create cycles involving local variables. > Lexical scoping would change that. Fair enough. To resolve this, an inner function should only have a reference to the outer function if it actually references the outer function's locals -- which can be determined at compile time. > > If you want to use weak references, please try to specify *in detail* > > which objects would have weak references to which other objects and > > how the system would resolve these... I'm never sure that things can > > be made 100% safe using this technique, so it may help to spell it out > > for me! > > OK, how's that: inner functions have weak reference to variables in the > same scope > > def f(): > x = 1 > def g(): > pass Insert "print x" in the body of g, and "return g" in the body of f. > > g would have only a weak reference to "x". > > I'm changing "no reference" to "weak reference", so I'm not incrementing > effective reference counting. Ehm, I'm always confused by the semantics of weak references (you could say that I haven't a clue about them), so you'd have to do better than this. In any case, in your proposal the weak reference to x would go away when f returns, so if g is exported from f, it breaks! def f(): x = 1 def g(): print x g() return g gee = f() gee() This would first print 1 (the call to g() inside f()) and then raise a NameError (probably a new subclass e.g. UnboundOuterNameError). This behavior is unacceptable, at least to the people who have been clamoring most for this feature (the Schemers): it is expected that x is kept alive as long as g lives. So, try again! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From fdrake@beopen.com Wed Jul 26 14:44:18 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 26 Jul 2000 09:44:18 -0400 (EDT) Subject: [Python-Dev] Sub-package import mechanism now broken? No, but... In-Reply-To: <397EE36F.59615826@per.dem.csiro.au> References: <397EE36F.59615826@per.dem.csiro.au> Message-ID: <14718.60210.729406.658995@cj42289-a.reston1.va.home.com> Mark Favas writes: > Opps - the import mechanism is not broken, it's just that the xml > package in lib/site-packages no longer gets found, because of the new > xml package in lib. This will still break existing code, unless the xml > package in lib is renamed, has the same functionality as the PyXML I expect we'll be making the package in site-packages an extension provider for the xml package in the standard library. I'm planning to discuss this issue at today's PythonLabs meeting. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Moshe Zadka Wed Jul 26 14:56:12 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 26 Jul 2000 16:56:12 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <200007261444.JAA02518@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 26 Jul 2000, Guido van Rossum wrote: > > OK, how's that: inner functions have weak reference to variables in the > > same scope > > > > def f(): > > x = 1 > > def g(): > > pass > > Insert "print x" in the body of g, and "return g" in the body of f. What are you trying to do, simulate classes via closures? I don't see any reason for this to work. However, this should work def powers_of(n): return map(lambda x: n**x, range(10)) > Ehm, I'm always confused by the semantics of weak references (you > could say that I haven't a clue about them), so you'd have to do > better than this. > > In any case, in your proposal the weak reference to x would go away > when f returns, so if g is exported from f, it breaks! Exactly. But breaks cleanly, of course (what yo suggested works great) > This behavior is unacceptable, at least to the people who have been > clamoring most for this feature (the Schemers): it is expected that > x is kept alive as long as g lives. Ummmm....to put it harshly f**k Schemers (I'm speaking as a latent schemer myself, so I can be harsh): I don't want lexical scoping to simulate classes, Python's got a wonderful object system. I want lexical scoping to make the common case of map(lambda) or def _(...): .... map(_, ....) less horrible (IOW, without the lambda x,n=n,y=y,something=other: hack) The only question about lexical scoping is "what are we trying to do?". I'm trying to have a working map(). You (seem to be) trying to simulate objects via closures. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From trentm@activestate.com Wed Jul 26 17:30:24 2000 From: trentm@activestate.com (Trent Mick) Date: Wed, 26 Jul 2000 09:30:24 -0700 Subject: [Python-Dev] test_fork1 failing --with-threads (for some people)... In-Reply-To: <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> Message-ID: <20000726093024.C26632@ActiveState.com> On Wed, Jul 26, 2000 at 08:10:40AM +0000, Peter Schneider-Kamp wrote: > I am using a (somewhat modified) SuSE 6.4 distribution > with an old 2.2.13 kernel. > > What does your's look like? > [trentm@molotok ~]$ cat /proc/version Linux version 2.2.12-20smp (root@porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Mon Sep 27 10:34:45 EDT 1999 RedHat dist Trent -- Trent Mick TrentM@ActiveState.com From trentm@ActiveState.com Wed Jul 26 17:32:32 2000 From: trentm@ActiveState.com (Trent Mick) Date: Wed, 26 Jul 2000 09:32:32 -0700 Subject: [Python-Dev] test_fork1.py failing (Summary or failing regression tests...) In-Reply-To: <397E9D3C.9181A0E0@lemburg.com> References: <20000725153912.A21409@ActiveState.com> <397E9D3C.9181A0E0@lemburg.com> Message-ID: <20000726093232.D26632@ActiveState.com> On Wed, Jul 26, 2000 at 10:11:40AM +0200, M . -A . Lemburg wrote: > Trent Mick wrote: > > > > On Linux32: > > - test_fork1 > > This fails/hangs/crashes inconsistently because (some little bird told me) > > the fork stuff and threads are incompatible. Am I right? Now that we are > > turning threads on by default what is the proper thing to do here? SHould > > test_fork1 be changed to skip if threads are enabled? > > Does this mean that a stock Python 1.6/2.0 interpreter will > not properly do fork() on Linux32 (even when using threads) ? > As I said: *some little bird told me*. (I think it was David.) I don't know, Marc-Andre. I am just waving a flag. Ignorantly yours, Trent -- Trent Mick TrentM@ActiveState.com From trentm@activestate.com Wed Jul 26 17:37:26 2000 From: trentm@activestate.com (Trent Mick) Date: Wed, 26 Jul 2000 09:37:26 -0700 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <200007260259.OAA09520@s454.cosc.canterbury.ac.nz> References: <20000725110000.C577@ActiveState.com> <200007260259.OAA09520@s454.cosc.canterbury.ac.nz> Message-ID: <20000726093726.E26632@ActiveState.com> On Wed, Jul 26, 2000 at 02:59:14PM +1200, Greg Ewing wrote: > Trent Mick suggested: > > > [for x in [10,20,30]: for y in [1,2,3]: x+y] > > When designing the syntax, I decided to put the target > expression first, because I wanted it to read declaratively. > Also I think it's clearer when you can see right up front > what it's going to be a list *of*. > Yes, I expressed liking someones (MAL's? Skip's?) suggested: [for x in [1,2,3]: x] Over the currently favoured [x for x in [1,2,3]] However, given Tim's response to that thread (list comprehensions are declarative, the important thing is for the synxtax to be memorable after initial familiarity), I am inclined to retract my opinion and support: [x for x in [1,2,3]] and its ilk. Mainly, I don't want to get pulled into the debate. It has been debated and there are too many cooks in the kitchen. Trent -- Trent Mick TrentM@ActiveState.com From nowonder@nowonder.de Wed Jul 26 19:40:07 2000 From: nowonder@nowonder.de (Peter Schneider-Kamp) Date: Wed, 26 Jul 2000 18:40:07 +0000 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> Message-ID: <397F3087.D4E38ED2@nowonder.de> Trent Mick wrote: > > Linux version 2.2.12-20smp (root@porky.devel.redhat.com) (gcc version > egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Mon Sep 27 10:34:45 > EDT 1999 Could SMP be involved? Do you get the same on a non-SMP system? Do others have the same problem with SMP systems? Peter Linux version 2.2.13 (root@mobility) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Fri Mar 3 00:43:36 CET 2000 -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From trentm@activestate.com Wed Jul 26 18:27:13 2000 From: trentm@activestate.com (Trent Mick) Date: Wed, 26 Jul 2000 10:27:13 -0700 Subject: [Python-Dev] testing Fredrik's UCN patch on Linux64 (works! :) In-Reply-To: <004801bff68b$6e364280$f2a6b5d4@hagrid> References: <20000725112713.D577@ActiveState.com> <004801bff68b$6e364280$f2a6b5d4@hagrid> Message-ID: <20000726102713.D27257@ActiveState.com> > > - Fredrik had a new, better replacement? Fredrik? > > my patch is here: > http://w1.132.telia.com/~u13208596/uninames-patch.txt > > (it's ~600k, which is more than sourceforge can handle) > > if you have some time to spare, feel tree to try it out on your > favourite 64-bit platform (I haven't had time to test it on our > alphas, but I'm pretty sure it'll work). Happy to try it.... > > the patch doesn't update the build files, so you need to do some > manual tweaking to make sure the unicodenames module is built. > I.e. just slap a unicodenames line in Modules/Setup? [trentm@nickel src]$ ./python Lib/test/test_ucn.py Testing General Unicode Character Name, and case insensitivity... done. Testing misc. symbols for unicode character name expansion.... done. Testing unicode character name expansion strict error handling.... done. [trentm@nickel src]$ ./python Lib/test/regrtest.py test_ucn test_ucn 1 test OK. It works. Do I need to try it on Win64. It is more of a pain to try it there because the Win64 build system is a big f***ing mess. Trent -- Trent Mick TrentM@ActiveState.com From trentm@activestate.com Wed Jul 26 19:04:52 2000 From: trentm@activestate.com (Trent Mick) Date: Wed, 26 Jul 2000 11:04:52 -0700 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <397F3087.D4E38ED2@nowonder.de> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> Message-ID: <20000726110452.A27966@ActiveState.com> On Wed, Jul 26, 2000 at 06:40:07PM +0000, Peter Schneider-Kamp wrote: > Trent Mick wrote: > > > > Linux version 2.2.12-20smp (root@porky.devel.redhat.com) (gcc version > > egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Mon Sep 27 10:34:45 > > EDT 1999 > > Could SMP be involved? Do you get the same on a non-SMP system? > Do others have the same problem with SMP systems? > Yup, it looks like that is a possibility. I tried test_fork1 a few times on: [trentm@ladder src]$ cat /proc/version Linux version 2.2.14 (root@ladder.ActiveState.com) (gcc version 2.95.2 19991024 (release)) #1 Mon Mar 6 16:49:17 PST 2000 (a Mandrake box)... and it works fine: [trentm@ladder src]$ ./python Lib/test/test_fork1.py [trentm@ladder src]$ ./python Lib/test/regrtest.py test_fork1 test_fork1 1 test OK. [trentm@ladder src]$ So...... who knows more about SMP issues and why we have them? I am inexperienced and clueless here. Trent -- Trent Mick TrentM@ActiveState.com From klm@digicool.com Wed Jul 26 20:16:31 2000 From: klm@digicool.com (Ken Manheimer) Date: Wed, 26 Jul 2000 15:16:31 -0400 (EDT) Subject: [Python-Dev] PEP202 -- glossary of terms In-Reply-To: <20000726005526.A3796@thyrsus.com> Message-ID: On Wed, 26 Jul 2000, Eric S. Raymond wrote: > functional style: > > Refers to a language in which everything is pure function calls, without > side-effects or variables. Backus's F is one of the better-known > examples. LISP would be functional if there were no (setq ...). Typo, i think: that would probably be "FP". Quite cool language, from the guy also primary in bringing us fortran. > The advantage of functional language is the same as their disadvantage: > no side-effects. Makes them easy to reason about, but you have to jump > through hoops to do statefulness. I think "easy to reason about" in this case is mostly in the line of rigorous mathematic reasoning - algebraic/provability - than it is about approachability for novices/non-mathematicians! My impression is that in functional programming, you use functions to manipulate functions to get results - combinators, which are extremely powerful, expressively and mathematically, are also quite difficult to approach for the uninitiated. (I always thought APL presented similar challenges, but in the medium of programs as arrays/matrices.) I think one big advantage of the procedural style is how much easier it is for people to get what loops do, where applicative (map/reduce/apply) and combinatory logic operators are a lot harder. And list comprehensions as proposed capitalize on the greater approachability of loops. However, i do think a function like zip()/pairwise()/whatever can help for the tricky bit where the loop approach breaks down... (And i would be surprised if jeremy, who was steeped in MIT's scheme-based programming fundamentals curriculum, was asking for definitions. ?) Ken klm@digicool.com From bckfnn@worldonline.dk Wed Jul 26 20:42:29 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Wed, 26 Jul 2000 19:42:29 GMT Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <397f38e5.12750954@smtp.worldonline.dk> CPythons unicode compare function contains some code to compare surrogate characters in code-point order (I think). This is properly a very neat feature but is differs from java's way of comparing strings. Python 2.0b1 (#0, Jul 26 2000, 21:29:11) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> print u'\ue000' < u'\ud800' 1 >>> print ord(u'\ue000') < ord(u'\ud800') 0 >>> Java (and JPython) compares the 16-bit characters numericly which result in: JPython 1.1+08 on java1.3.0 (JIT: null) Copyright (C) 1997-1999 Corporation for National Research Initiatives >>> print u'\ue000' < u'\ud800' 0 >>> print ord(u'\ue000') < ord(u'\ud800') 0 >>> I don't think I can come up with a solution that allow JPython to emulate CPython on this type of comparison. regards, finn From thomas@xs4all.net Wed Jul 26 21:02:17 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 26 Jul 2000 22:02:17 +0200 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: <200007261300.IAA01335@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 26, 2000 at 08:00:33AM -0500 References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> <200007261300.IAA01335@cj20424-a.reston1.va.home.com> Message-ID: <20000726220216.O266@xs4all.nl> On Wed, Jul 26, 2000 at 08:00:33AM -0500, Guido van Rossum wrote: > > is there any special reason why we cannot use colon instead > > of "for"? > Would conflict with the proposed syntax for range literals. Both > > [0:10] > > and > [x : x in seq] > have the same syntactical form. Much, much worse: the latter *is* a range literal. It's not likely to produce anything useful, depending on 'x', but it is a valid range literal. (It'll create a range from 'x' to '0', if 'x' is not in 'seq', or '1', if 'x' is in 'seq', using step 1.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Wed Jul 26 21:50:32 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 26 Jul 2000 22:50:32 +0200 Subject: [Python-Dev] ANSIfication. In-Reply-To: <20000726133002.4D95937186E@snelboot.oratrix.nl>; from jack@oratrix.nl on Wed, Jul 26, 2000 at 03:30:01PM +0200 References: <20000726133002.4D95937186E@snelboot.oratrix.nl> Message-ID: <20000726225032.P266@xs4all.nl> On Wed, Jul 26, 2000 at 03:30:01PM +0200, Jack Jansen wrote: > > Frankly, I think that for *any* functions that are in some external > > library (e.g. libc), Python should never provide a function prototype > > at all. The standard headers should provide the prototypes! > They should, but what if they don't? That's what I like about the > pyport.h: it allows Python to build out of the box but still keeps all the > cruft needed because some platforms don't have their act together in a > single place. I know that I'm not expected to understand sections of > pyport.h that are for platforms I'm not familiar with... That's kind-of what I wrote in my reply to Guido. There is only one problem with this, though, and that's finding platform-identifying #defines. I don't have enough experience with portable software to assume anything, and I unable to find anything identifying the platform on the one Solaris 2.6 box we have (and don't use, because it's Solaris ;) I haven't tried finding any on the Linux or BSDI boxes we do use, but I think Linux glibc2 is recognizable -- but that's also the system most likely to be up to date ! If anyone can give some hints on identifying platforms, or finding out whether a given prototype is included in the header files, please do :P Until then, I don't think we can do much else with the *current* prototypes than remove them. And if anyone needs those #defines, they'll have to figure out how to uniquely identify their architecture, first. Actually... I think it's possible for autoconf to find out if a prototype is included by trying to take the address of a function... but that's kind of a severe method, and doesn't say anything about what the prototype should look like. And is there really any danger of real bugs being caused by missing prototypes ? Most (well, at least *some*) testing is done on Linux systems, on which I have yet to find a prototype missing from the std. include files. It'll generate some warnings on some other operating systems, but that's all, I think. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy@beopen.com Wed Jul 26 22:47:12 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 26 Jul 2000 14:47:12 -0700 (PDT) Subject: [Python-Dev] Product iteration In-Reply-To: References: <200007261444.JAA02518@cj20424-a.reston1.va.home.com> Message-ID: <14719.23648.966686.131625@mailhost.beopen.com> Moshe Zadka writes: > On Wed, 26 Jul 2000, Guido van Rossum wrote: > > > > OK, how's that: inner functions have weak reference to variables in the > > > same scope > > > > > > def f(): > > > x = 1 > > > def g(): > > > pass > > > > Insert "print x" in the body of g, and "return g" in the body of f. > > What are you trying to do, simulate classes via closures? I don't see any > reason for this to work. > There's not simulation going on. He's just expecting closures to work. I think that any proposal for changed scoping needs to do lexical scoping properly, including closures. If it doesn't, I vote -1. The argument about finalization is specious. You should not write code that depends on current finalization semantics to do things like closing files. It's relying on an implementation-dependent feature that is not part of the language spec. (Just try it on JPython.) Jeremy From esr@thyrsus.com Wed Jul 26 23:09:59 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 26 Jul 2000 18:09:59 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <14719.23648.966686.131625@mailhost.beopen.com>; from jeremy@beopen.com on Wed, Jul 26, 2000 at 02:47:12PM -0700 References: <200007261444.JAA02518@cj20424-a.reston1.va.home.com> <14719.23648.966686.131625@mailhost.beopen.com> Message-ID: <20000726180959.A6654@thyrsus.com> Jeremy Hylton : > The argument about finalization is specious. You should not write > code that depends on current finalization semantics to do things like > closing files. It's relying on an implementation-dependent feature > that is not part of the language spec. (Just try it on JPython.) I strongly agree. -- Eric S. Raymond Morality is always the product of terror; its chains and strait-waistcoats are fashioned by those who dare not trust others, because they dare not trust themselves, to walk in liberty. -- Aldous Huxley From trentm@ActiveState.com Thu Jul 27 00:01:57 2000 From: trentm@ActiveState.com (Trent Mick) Date: Wed, 26 Jul 2000 16:01:57 -0700 Subject: [Python-Dev] Re: C testing framework In-Reply-To: <14717.55286.1741.361478@beluga.mojam.com> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> <14717.34372.437370.172614@beluga.mojam.com> <20000725103736.B577@ActiveState.com> <14717.55286.1741.361478@beluga.mojam.com> Message-ID: <20000726160157.A26692@ActiveState.com> On Tue, Jul 25, 2000 at 01:09:58PM -0500, Skip Montanaro wrote: > > [c-based testing framework] > > Trent> Show it? PEP it? Forget it? > > I say show it. I see no reason to make a PEP unless there are a number of > potential immediate alternatives. It doesn't affect the functionality of > the distribution, only its quality. If something better comes along later, > Trent's can be replaced. Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp Patch: *** /home/trentm/main/contrib/python/dist/src/Lib/test/test_capi.py Wed Jul 26 15:39:35 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/Lib/test/test_capi.py Wed Jul 26 10:37:31 2000 *************** *** 0 **** --- 1,17 ---- + import sys + import test_support + import _test + + # import and run the _test module tests (tests for the Python/C API) + # + # (any exported function beginning with 'test_') + + for name in dir(_test): + if name.startswith('test_'): + test = getattr(_test, name) + if test_support.verbose: + print "internal", name + try: + test() + except _test.error: + raise test_support.TestFailed, sys.exc_info()[1] *** /home/trentm/main/contrib/python/dist/src/Lib/test/output/test_capi Wed Jul 26 15:39:35 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/Lib/test/output/test_capi Wed Jul 26 10:36:37 2000 *************** *** 0 **** --- 1 ---- + test_capi *** /home/trentm/main/contrib/python/dist/src/Modules/_testmodule.c Wed Jul 26 15:39:35 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/Modules/_testmodule.c Wed Jul 26 15:39:31 2000 *************** *** 0 **** --- 1,64 ---- + //--------------------------------------------------------------------------- + // C Extension module to test Python interpreter C APIs. + // + // The 'test_*' functions exprted by this module are run as part of + // the standard Python regression test (via test_capi.py). + //--------------------------------------------------------------------------- + + #include "Python.h" + #include "marshal.h" + + #define TEST_FILENAME "__test_filename" // filename used for testing + + PyObject *TestError; + + + /* test defines from config.h (particularly the SIZEOF_* defines) + + The ones derived from autoconf on the UNIX-like OSes can be relied + upon, but the Microsoft platform have these hardcoded. Better safe + than sorry. + */ + PyObject* + test_config(PyObject *self, PyObject *args) + { + /*XXX could probably break these out to allow the error message to be + * better, as well could test more config.h settings */ + if (SIZEOF_INT != sizeof(int) || + SIZEOF_LONG != sizeof(long) || + #ifdef HAVE_LONG_LONG + SIZEOF_LONG_LONG != sizeof(LONG_LONG) || + #endif + SIZEOF_VOID_P != sizeof(void*) || + SIZEOF_TIME_T != sizeof(time_t)) { + PyErr_SetString(TestError, + "SIZEOF_* configuration defines are not all correct"); + return NULL; + } + + Py_INCREF(Py_None); + return Py_None; + } + + + + + /* must defined special structure to define methods and attributes to Python */ + static PyMethodDef TestMethods[] = { + {"test_config", test_config, METH_VARARGS}, + {NULL, NULL} /* sentinel */ + }; + + + /* must define intialization function, often 'init' */ + DL_EXPORT(void) + init_test(void) + { + PyObject *m, *d; + + m = Py_InitModule("_test", TestMethods); + + TestError = PyErr_NewException("_test.error", NULL, NULL); + d = PyModule_GetDict(m); + PyDict_SetItemString(d, "error", TestError); + } *** /home/trentm/main/contrib/python/dist/src/Modules/Setup.in Fri Jun 30 09:05:22 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/Modules/Setup.in Wed Jul 26 14:30:37 2000 *************** *** 426,431 **** --- 426,436 ---- #EXPAT_DIR=/usr/local/src/expat #pyexpat pyexpat.c -I$(EXPAT_DIR)/xmlparse -L$(EXPAT_DIR) -lexpat + # internal C API testing module (tests exprted by this module are + # called as part of the test suite) + *shared* + _test _testmodule.c + *static* # Example -- included for reference only: # xx xxmodule.c *** /home/trentm/main/contrib/python/dist/src/PCbuild/_test.dsp Wed Jul 26 15:39:35 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/PCbuild/_test.dsp Wed Jul 26 14:30:03 2000 *************** *** 0 **** --- 1,100 ---- + # Microsoft Developer Studio Project File - Name="_test" - Package Owner=<4> + # Microsoft Developer Studio Generated Build File, Format Version 6.00 + # ** DO NOT EDIT ** + + # TARGTYPE "Win32 (x86) Dynamic-Link Library" 0x0102 + + CFG=_test - Win32 Debug + !MESSAGE This is not a valid makefile. To build this project using NMAKE, + !MESSAGE use the Export Makefile command and run + !MESSAGE + !MESSAGE NMAKE /f "_test.mak". + !MESSAGE + !MESSAGE You can specify a configuration when running NMAKE + !MESSAGE by defining the macro CFG on the command line. For example: + !MESSAGE + !MESSAGE NMAKE /f "_test.mak" CFG="_test - Win32 Debug" + !MESSAGE + !MESSAGE Possible choices for configuration are: + !MESSAGE + !MESSAGE "_test - Win32 Release" (based on "Win32 (x86) Dynamic-Link Library") + !MESSAGE "_test - Win32 Debug" (based on "Win32 (x86) Dynamic-Link Library") + !MESSAGE + + # Begin Project + # PROP AllowPerConfigDependencies 0 + # PROP Scc_ProjName "" + # PROP Scc_LocalPath "" + CPP=cl.exe + MTL=midl.exe + RSC=rc.exe + + !IF "$(CFG)" == "_test - Win32 Release" + + # PROP BASE Use_MFC 0 + # PROP BASE Use_Debug_Libraries 0 + # PROP BASE Output_Dir "Release" + # PROP BASE Intermediate_Dir "Release" + # PROP BASE Target_Dir "" + # PROP Use_MFC 0 + # PROP Use_Debug_Libraries 0 + # PROP Output_Dir "." + # PROP Intermediate_Dir "x86-temp-release\_test" + # PROP Ignore_Export_Lib 0 + # PROP Target_Dir "" + F90=df.exe + # ADD BASE CPP /nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_TEST_EXPORTS" /YX /FD /c + # ADD CPP /nologo /MD /W3 /GX /Zi /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /YX /FD /c + # ADD BASE MTL /nologo /D "NDEBUG" /mktyplib203 /win32 + # ADD MTL /nologo /D "NDEBUG" /mktyplib203 /win32 + # ADD BASE RSC /l 0x409 /d "NDEBUG" + # ADD RSC /l 0x409 /d "NDEBUG" + BSC32=bscmake.exe + # ADD BASE BSC32 /nologo + # ADD BSC32 /nologo + LINK32=link.exe + # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 + # ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /out:"./_test.pyd" /export:init_test + # SUBTRACT LINK32 /pdb:none + + !ELSEIF "$(CFG)" == "_test - Win32 Debug" + + # PROP BASE Use_MFC 0 + # PROP BASE Use_Debug_Libraries 1 + # PROP BASE Output_Dir "Debug" + # PROP BASE Intermediate_Dir "Debug" + # PROP BASE Target_Dir "" + # PROP Use_MFC 0 + # PROP Use_Debug_Libraries 1 + # PROP Output_Dir "." + # PROP Intermediate_Dir "x86-temp-debug\_test" + # PROP Ignore_Export_Lib 0 + # PROP Target_Dir "" + F90=df.exe + # ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_TEST_EXPORTS" /YX /FD /GZ /c + # ADD CPP /nologo /MDd /W3 /Gm /GX /Zi /Od /I "..\Include" /I "..\PC" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /YX /FD /GZ /c + # ADD BASE MTL /nologo /D "_DEBUG" /mktyplib203 /win32 + # ADD MTL /nologo /D "_DEBUG" /mktyplib203 /o "NUL" /win32 + # ADD BASE RSC /l 0x409 /d "_DEBUG" + # ADD RSC /l 0x409 /d "_DEBUG" + BSC32=bscmake.exe + # ADD BASE BSC32 /nologo + # ADD BSC32 /nologo + LINK32=link.exe + # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept + # ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /out:"./_test_d.pyd" /pdbtype:sept /export:init_test + # SUBTRACT LINK32 /pdb:none + + !ENDIF + + # Begin Target + + # Name "_test - Win32 Release" + # Name "_test - Win32 Debug" + # Begin Source File + + SOURCE=..\Modules\_testmodule.c + # ADD CPP /I "..\Include" /I "..\PC" + # End Source File + # End Target + # End Project *** /home/trentm/main/contrib/python/dist/src/PCbuild/pcbuild.dsw Wed Jul 26 15:10:27 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/PCbuild/pcbuild.dsw Wed Jul 26 15:13:22 2000 *************** *** 33,38 **** --- 33,53 ---- ############################################################################### + Project: "_test"=".\_test.dsp" - Package Owner=<4> + + Package=<5> + {{{ + }}} + + Package=<4> + {{{ + Begin Project Dependency + Project_Dep_Name python20 + End Project Dependency + }}} + + ############################################################################### + Project: "_tkinter"=".\_tkinter.dsp" - Package Owner=<4> Package=<5> -- Trent Mick TrentM@ActiveState.com From guido@beopen.com Thu Jul 27 01:38:55 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 19:38:55 -0500 Subject: [Python-Dev] The State of Python Message-ID: <200007270038.TAA03951@cj20424-a.reston1.va.home.com> I've placed the slides of my talk at the O'Reilly Open Source Convention on-line at our BeOpen PythonLabs website: http://www.pythonlabs.com/talks.html We're also very close to announcing news regarding a new Python license, Python 1.6 and 2.0 release schedules, and a transition of the python.org website to hosting by VA Linux. The announcement is waiting for final negotiations about GPL compatibility of the new license; BeOpen's CTO, Bob Weiner, is confident that the issue will be resolved one way or another by Friday. A preview of what we will announce: - A new license for Python 1.6 and later: the "CNRI Open Source License", approved by the Open Source Initiative; - Release plans for Python 1.6: the last CNRI release, to be issued with help from BeOpen; - Release plans for Python 2.0: the first release to be issued by BeOpen; - A transition for the python.org website: it will be hosted by VA Linux (home of SourceForge), under supervision of the Python Consortium and myself, maintained by the Python community. Please hold your breath a little longer! A re-release of JPython using the CNRI Open Source License is possible a little later, pending further negotiations with CNRI. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From m.favas@per.dem.csiro.au Thu Jul 27 02:22:36 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Thu, 27 Jul 2000 09:22:36 +0800 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs machine with >= 32bit longs References: <20000725112713.D577@ActiveState.com> <004801bff68b$6e364280$f2a6b5d4@hagrid> Message-ID: <397F8EDC.328DDF1C@per.dem.csiro.au> Fredrik Lundh wrote: > > trent wrote: > > I was assigned this patch a while back to try on some 64-bit systems. Fine, I > > can do that but I have since seen a number of message on python-dev regarding > > it: > > > > - Fredrik had a new, better replacement? Fredrik? > > my patch is here: > http://w1.132.telia.com/~u13208596/uninames-patch.txt > > (it's ~600k, which is more than sourceforge can handle) > > if you have some time to spare, feel tree to try it out on your > favourite 64-bit platform (I haven't had time to test it on our > alphas, but I'm pretty sure it'll work). > > the patch doesn't update the build files, so you need to do some > manual tweaking to make sure the unicodenames module is built. > > if everything works as it should, the resulting interpreter should > survive test_ucn.py even if ucnhash.pyd (.so) is nowhere to be > seen... > > I've just tried /F's patch on my Alpha (Tru64 Unix, V4.0F), and everything seems fine - compiles, passes test_ucn (and the rest). -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From jeremy@beopen.com Thu Jul 27 04:07:02 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 26 Jul 2000 23:07:02 -0400 (EDT) Subject: [Python-Dev] failures in the regression tests Message-ID: <14719.42838.895374.783407@bitdiddle.concentric.net> I am trying to keep track of failures in the regression test suite. At the moment, all the available tests work correctly on my Linux box. I understand there are still problems with test_fork1 on some SMP Linux boxes. (I believe this error has been around for many months.) And that the test_winreg and test_winreg32 tests are failing on Windows builds. If you are aware of any other tests that are failing, please let me know. (Preferably by private email.) We need to get the tests fixed quickly. As I write in PEP 200 (Python 2.0 release schedule): >Failing test cases need to get fixed > > We need to resolve errors in the regression test suite quickly. > Changes should not be committed to the CVS tree unless the > regression test runs cleanly with the changes applied. If it > fails, there may be bugs lurking in the code. (There may be bugs > anyway, but that's another matter.) If the test cases are known > to fail, they serve no useful purpose. Jeremy From fdrake@beopen.com Thu Jul 27 04:05:21 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 26 Jul 2000 23:05:21 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <397F3087.D4E38ED2@nowonder.de> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> Message-ID: <14719.42737.305992.235671@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > Could SMP be involved? Do you get the same on a non-SMP system? > Do others have the same problem with SMP systems? I mentioned the possibility at our PythonLabs meeting today that this may be related; when I observed problems with test_fork1, it was on an SMP linux box running Mandrake 7.0 with the stock SMP kernel. I have *not* seen the problem pop up on the uniprocessor I have now. I think Barry may have access to an SMP Sparc machine; if so, we'll be checking it out there. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Thu Jul 27 04:09:39 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 26 Jul 2000 23:09:39 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <20000726110452.A27966@ActiveState.com> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> <20000726110452.A27966@ActiveState.com> Message-ID: <14719.42995.823876.5177@cj42289-a.reston1.va.home.com> Trent Mick writes: > So...... who knows more about SMP issues and why we have them? I am > inexperienced and clueless here. Another possible issue is that at one point configure was using GNU Pth instead of LinuxThreads by default. Since Pth is fairly young, there may be issues there as well. Pth is no longer preferred over LinuxThreads. For non-Linux users: LinuxThreads is the default pthreads implementation on Linux, and GNU Pth is a new "portable" implementation that I understand is very young and unstable. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Thu Jul 27 04:23:52 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 26 Jul 2000 23:23:52 -0400 Subject: [Python-Dev] failures in the regression tests In-Reply-To: <14719.42838.895374.783407@bitdiddle.concentric.net> Message-ID: On Win98, with the CVS version as of 11:15pm EDT, in both debug and release builds: 59 tests OK. 3 tests failed: test_mmap test_winreg test_winreg2 26 tests skipped: test_al test_bsddb test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_grp test_gzip test_imgfile test_li nuxaudiodev test_minidom test_nis test_openpty test_popen2 test_pty test_pwd tes t_pyexpat test_signal test_sunaudiodev test_timing test_zlib Seems odd that test_popen2 is still being skipped (I thought we were fixing popen & friends under Windows, but lost track of that). > ... > If you are aware of any other tests that are failing, please let me > know. (Preferably by private email.) Like I'm going to trust you to keep Windows details straight . From thomas@xs4all.net Thu Jul 27 05:04:42 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 06:04:42 +0200 Subject: [Python-Dev] test_fork1 on SMP? In-Reply-To: <14719.42737.305992.235671@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Wed, Jul 26, 2000 at 11:05:21PM -0400 References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> <14719.42737.305992.235671@cj42289-a.reston1.va.home.com> Message-ID: <20000727060442.Q266@xs4all.nl> On Wed, Jul 26, 2000 at 11:05:21PM -0400, Fred L. Drake, Jr. wrote: > > Peter Schneider-Kamp writes: > > Could SMP be involved? Do you get the same on a non-SMP system? > > Do others have the same problem with SMP systems? > I think Barry may have access to an SMP Sparc machine; if so, we'll > be checking it out there. I have also seen test_fork1 failures on BSDI, using a SMP machine, but I haven't tried it on non-SMP (we don't have too many of those). However, all our BSDI kernels are the same, having been built for SMP. Meetings permitting (which is doubtful, today :-() I'll see if I can pin that down. It would, however, be fairly peculiar if test_fork1 breaks on all SMP-supporting systems... I don't really recall a reason for thread semantics to change reliably based on kernel/cpu settings, and it would be silly for them to do so! But I'll admit threads are silly, period ;-) 6-AM-and-preparing-for-a-full-10-hour-day-of-meetings-:-S-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one@email.msn.com Thu Jul 27 05:32:02 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 00:32:02 -0400 Subject: [Python-Dev] test_fork1 on SMP? In-Reply-To: <20000727060442.Q266@xs4all.nl> Message-ID: [Thomas Wouters] > I have also seen test_fork1 failures on BSDI, using a SMP machine, but > I haven't tried it on non-SMP (we don't have too many of those). > However, all our BSDI kernels are the same, having been built for SMP. > Meetings permitting (which is doubtful, today :-() I'll see if I can > pin that down. > > It would, however, be fairly peculiar if test_fork1 breaks on all > SMP-supporting systems... I don't really recall a reason for thread > semantics to change reliably based on kernel/cpu settings, and it would > be silly for them to do so! But I'll admit threads are silly, period ;-) Silly? Without threads your clothes would fall off . I wonder whether the "fork" part is a red herring here. It's extremely rare to see a thread bug that actually requires a multi-headed machine to trigger (in fact, I don't believe I've ever seen one), but the nature of races in flawed threaded code is often such that you're a million times more *likely* to hit a bad timing window on a multi-headed machine than on a time-sliced single-headed box. And this is particularly true under operating systems that are reluctant to switch threads on a singled-headed box. For example, 1.5.2's dreaded invalid_tstate bug had never been reported on a single-headed box until I spent several *hours* hand-crafting an extreme test case to provoke it on one (and that was after I was sure I had located the timing hole "by thought", so knew exactly what I needed to do to trigger it -- 'twas very hard to provoke it on a one-headed box even then!). > 6-AM-and-preparing-for-a-full-10-hour-day-of-meetings-:-S-ly y'rs, So long as you still put in your 18 hours on Python today, we're happy to let you engage in all the recreational activities you like . generously y'rs - tim From Moshe Zadka Thu Jul 27 05:39:54 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 27 Jul 2000 07:39:54 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <14719.23648.966686.131625@mailhost.beopen.com> Message-ID: On Wed, 26 Jul 2000, Jeremy Hylton wrote: > The argument about finalization is specious. You should not write > code that depends on current finalization semantics to do things like > closing files. It's relying on an implementation-dependent feature > that is not part of the language spec. (Just try it on JPython.) I know, and I'm not. But the thing is, there are plenty of users of CPython which do rely on this feature -- so you're going to break people's code. Not nice. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mhammond@skippinet.com.au Thu Jul 27 05:47:07 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu, 27 Jul 2000 14:47:07 +1000 Subject: [Python-Dev] Product iteration In-Reply-To: Message-ID: > I know, and I'm not. But the thing is, there are plenty of users of > CPython which do rely on this feature -- so you're going to break > people's code. Not nice. No - we will simply be pointing out their already broken code. We arent breaking anything! I have no problem with this at all. The sooner we point out the broken code the better. The last thing we want is for obviously and documented broken code to suddenly be considered non-broken simply by the volume of poor code out there... Either way, I think you are overstating the problem. The main scenario is closing resources, and for most users these are unlikely to be so scarce that delaying their finalization will cause problems. If someone is writing a web-server, for example, and assumes that files or sockets are automatically closed, and they open them at such a rate that true GC causes them a problem, then IMO they have got what they deserve ;-) Mark. From bwarsaw@beopen.com Thu Jul 27 05:58:00 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 27 Jul 2000 00:58:00 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> <14719.42737.305992.235671@cj42289-a.reston1.va.home.com> Message-ID: <14719.49496.935765.730596@anthem.concentric.net> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> Barry may have access to an SMP Sparc machine; if so, we'll Fred> be checking it out there. I thought I did, but nope, it's a single processor. What about SF? -Barry From guido@beopen.com Thu Jul 27 06:59:15 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 00:59:15 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Tue, 25 Jul 2000 23:03:23 +0200." <20000725230322.N266@xs4all.nl> References: <20000725230322.N266@xs4all.nl> Message-ID: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> I've been thinking a bit about this myself, and I think it's good idea to show the bytecodes generated for the various cases, just to make sure that we understand the semantics. I'll just use +=, but the same list applies to all 11 binary operators (**, *, /, %, +, -, |, &, ^, <<, >>). I'm making up opcodes -- the different variants of LOAD and STORE don't matter. On the right I'm displaying the stack contents after execution of the opcode (push appends to the end). I'm writing 'result' to indicate the result of the += operator. a += b LOAD a [a] LOAD b [a, b] AUGADD [result] STORE a [] a.attr += b LOAD a [a] DUP [a, a] GETATTR 'attr' [a, a.attr] LOAD b [a, a.attr, b] AUGADD [a, result] SETATTR 'attr' [] a[i] += b LOAD a [a] DUP [a, a] LOAD i [a, a, i] DUP [a, a, i, i] ROT3 [a, i, a, i] GETITEM [a, i, a[i]] LOAD b [a, i, a[i], b] AUGADD [a, i, result] SETITEM [] I'm leaving the slice variant out; I'll get to that in a minute. If the right hand side is more complicated than in the example, the line 'LOAD b' is simply replaced by code that calculates the value of the expression; this always ends up eventually pushing a single value onto the stack, leaving anything below it alone, just like the 'LOAD b' opcode. Ditto for the index expression ('i' in the example). Similarly, for the cases a.attr and a[i], if instead of a there's a more complicated expression (e.g. sys.modules[name].foo().bar += 1) the initial 'LOAD a' is replaced by code that loads the object on the stack -- in this example, sys.modules[name].foo(). Only the final selector (".attr", "[i]") is special. (Terminology: a selector is something that addresses a possibly writable component of a container object, e.g. a[i] or a.attr; a[i:j] is also a selector. f() could be seen as a selector but cannot be used on the left hand side of an assignment.) There are two more forms of potential interest. First, what should happen to a tuple assignment? a, b, c += x (Which is exactly the same as "(a, b, c) += x".) I think this should be a compile-time error. If t and u are tuples, "t += u" means the same as "t = t+u"; but if we apply this rule we would get "(a, b, c) = (a, b, c) + u", which is only valid if u is an empty tuple (or a class instance with unusual coercion behavior). But when u is empty, it's not useful (nothing changes), so it's unlikely that someone would have this intention. More likely, the programmer was hoping that this would be the same as "a+=x; b+=x; c+=x" -- but that's the same misconception as expecting "a, b, c = 0" to mean "a = b = c = 0" so we don't need to cater to it. Second, what should happen to a slice assignment? The basic slice form is: a[i:j] += b but there are others: Python's slice syntax allows an arbitrary comma-separated sequence of single indexes, regular slices (lo:hi), extended slices (lo:hi:step), and "ellipsis" tokens ('...') between the square brackets. Here's an extreme example: a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] += 1 First, let me indicate what code is generated for such a form when it's used in a regular expression or assignment. Any such form *except* basic slices (a[i:j], a[:j], a[i:], and a[:]) is translated into code that uses GETITEM or SETITEM with an index that is formed from a simple translation of the actual expressions. - If there are two or more comma-separated values, the index is a tuple of the translations of the individual values. - An ellipsis ("...") is translated into the builtin object Ellipsis. - A non-slice is translated into itself. - A slice is translated into a "slice object", this is a built-in object representing the lower and upper bounds and step. There is also a built-in function, slice(), taking 1-3 arguments in the same way as range(). Thus: - "lo:hi" is equivalent to slice(lo, hi); - "lo:hi:step" is equivalent to slice(lo, hi, step); - omitted values are replaced with None, so e.g. ":hi" is equivalent to slice(None, hi). So, the extreme example above means exactly the same as a[x], where x is a tuple with the following items: slice(None, None) Ellipsis slice(None, None, None) slice(0, 10, 2) slice(None, 10, None) 1 slice(2, None) slice(None, None, -1) Why all this elaboration? Because I want to use this to give a standardized semantics even to basic slices. If a[lo:hi:step] is translated the same as a[slice(lo, hi, step)], then we can give a[lo:hi] the same translation as a[slice(lo, hi)], and thus the slice case for augmented assignment can generate the same code (apart from the slice-building operations) as the index case. Thus (writing 'slice' to indicate the slice object built from i and j): a[i:j] += b LOAD a [a] DUP [a, a] LOAD i [a, a, i] ** LOAD j [a, a, i, j] ** BUILD_SLICE 2 [a, a, slice] ** DUP [a, a, slice, slice] ROT3 [a, slice, a, slice] GETITEM [a, slice, a[slice]] LOAD b [a, slice, a[slice], b] AUGADD [a, slice, result] SETITEM [] Comparing this to the code for "a[i] += b", only the three lines marked with ** are really different, and all that these do is to push a single object representing the slice onto the stack. I won't show the code for "a[i:j:k] += b" or for "a[i:j, k:l]", but it's clear how these should be done. Postscript (unrelated to augmented assignment) It would be nice if the SLICE bytecodes were removed altogether and instead slice() objects would be created for all slices, even basic ones. (I believe this was proposed in this list at some point.) The original SLICE opcodes were introduced in ancient times, when basic slices were the only accepted slice syntax. This would mean that all objects supporting slices would have to support the *mapping* interface instead of (or in addition to) the sequence interface; the mapping interface would have to determine whether a getitem / setitem call was really a slice call and do the right thing. In particular, for backward compatibility, class instances could have a mapping interface whose internal getitem function checks if the argument is a slice object whose step is None and whose lo and hi are None or integers; then if a __getslice__ method exists, it could call that, in all other cases it could call __getitem__. None of the other built-in objects that support slices would have to be changed; the GETITEM opcode could notice that an object supports the sequence interface but not the mapping interface, and then look for a basic slice or an integer and do the right thing. Problems with this are mostly related to the existing C API for slices, like PySequence_GetSlice(), which propagate the various restrictions. Too-much-rambling-reduces-the-chance-of-useful-responses-ly, --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From bwarsaw@beopen.com Thu Jul 27 06:01:38 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 27 Jul 2000 01:01:38 -0400 (EDT) Subject: [Python-Dev] Product iteration References: <14719.23648.966686.131625@mailhost.beopen.com> Message-ID: <14719.49714.427661.775934@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I know, and I'm not. But the thing is, there are plenty of MZ> users of CPython which do rely on this feature -- so you're MZ> going to break people's code. Not nice. Nope, the code is already broken. They just don't know it yet. -Barry From Moshe Zadka Thu Jul 27 06:06:00 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 27 Jul 2000 08:06:00 +0300 (IDT) Subject: [Python-Dev] was Re: Type inference now simplicity (fwd) Message-ID: I think most of the people here aren't reading c.l.py, so here are some feelings from "the community" -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez ---------- Forwarded message ---------- Date: Wed, 26 Jul 2000 21:14:34 GMT From: Shae Erisson To: python-list@python.org Newsgroups: comp.lang.python Subject: was Re: Type inference now simplicity Neil Hodgson wrote: > I found this article quite depressing. One of the effects of .NET appe= ars > to be the homogenisation of programming languages. When the platform > emphasises compilation, compiler helpful warts like variable declaration = and > "option fast" start appearing. There is a place for languages with option= al > typing but there is also a place for a language that tries to stay very > simple. >=20 > VB has been on a long journey of complexification which has been great > for many but has left some people behind. One of my mates works as a > manager/bureaucrat - programming isn't a significant part of his job but > over the years he's been able to write bits of dBase, Excel macros and HT= ML > with embedded JavaScript. Excel moved from a simple macro language to a > simplified VB variant (OK, so far) to using full VB (getting worse) and t= hen > VB starts gaining C++ features (bad). So this bloke has stopped programmi= ng > in Excel - just too hard now. Adding 'programming in the large' features > appears good to help the more advanced users but it introduces unwanted > complexity for others. JavaScript was the last refuge of simplicity but n= ow > Microsoft (and Netscape) are moving it into the same zone as Python, VB a= nd > C#. I expect a new simple language will appear, gain some users and then > embark on the same journey to complexity. I agree with this. With Python, I'm opposed to the idea of adding autoincrement operators like +=3D etc. I'm opposed to adding the extra for loop stuff like "for [x,y,z] in [a,b,c]." And I'm opposed to it because it seems like sugar to me. I've always loved Python's simplicity, and I hope it stays that way. Adding new operators and new syntax will make Python harder to read, and harder to learn. I don't want that. Simplicity always seems to improve things. Usually, I can improve by removing rather than adding. Concepts like WikiWiki, Refactoring, etc. appeal to me tremendously. --=20 Shae Matijs Erisson - http://www.webwitches.com/~shae/ VirtualPairProgramming Wanted - Linux/Emacs/Python/Speak Freely =2Efi: rakastan ohjelmointia - python kengitt=E4=E4 aasia --=20 http://www.python.org/mailman/listinfo/python-list From guido@beopen.com Thu Jul 27 07:11:28 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 01:11:28 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 00:59:15 EST." <200007270559.AAA04753@cj20424-a.reston1.va.home.com> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> Message-ID: <200007270611.BAA04802@cj20424-a.reston1.va.home.com> I should add something about the assumed pseudo thread-safety of a+=b. I think this assumption is bogus, since we have to load a, do some stuff, and then store a, and we can't guarantee that the stuff we do is atomic -- in face we *know* it's not if it involves a user-defined method. Simply put: a += 1 IS NOT ATOMIC! Note that C doesn't guarantee that a++ is atomic either, even if a is declared volatile. (I believe there's an atomic data type, but I don't think it guarantees atomic ++. That would be very expensive because the VM cache would have to be flushed on multiprocessor machines. The only docs I found are at http://www.gnu.org/manual/glibc-2.0.6/html_node/libc_365.html.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From tim_one@email.msn.com Thu Jul 27 06:17:03 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 01:17:03 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <14719.49496.935765.730596@anthem.concentric.net> Message-ID: > >>>>> "Fred" == Fred L Drake, Jr writes: > > Fred> Barry may have access to an SMP Sparc machine; if so, we'll > Fred> be checking it out there. [Barry] > I thought I did, but nope, it's a single processor. What about SF? In parallel, could someone summarize the symptoms? Exactly how does it fail? Does it fail the same way across all platforms on which it does fail? Does it fail every time on all platforms on which it fails, or fail only some of the time on all platforms on which it fails, or fails some of the time on some of the platforms on which it fails but fails all of the time on the rest of the platforms on which it fails ? If there exists a platform on which it fails but it doesn't fail every time on that platform, that would be strong evidence of a timing hole. Those usually require thought to identify and repair. I'll voluteer to eyeball the code and do some thinking, but not unless the symptoms suggest that's worthwhile. ignorantly y'rs - tim From thomas@xs4all.net Thu Jul 27 08:21:44 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 09:21:44 +0200 Subject: [Python-Dev] test_fork1 on SMP? In-Reply-To: ; from tim_one@email.msn.com on Thu, Jul 27, 2000 at 12:32:02AM -0400 References: <20000727060442.Q266@xs4all.nl> Message-ID: <20000727092144.R266@xs4all.nl> On Thu, Jul 27, 2000 at 12:32:02AM -0400, Tim Peters wrote: > [Thomas Wouters] > > I have also seen test_fork1 failures on BSDI, using a SMP machine, but > > I haven't tried it on non-SMP (we don't have too many of those). > > However, all our BSDI kernels are the same, having been built for SMP. > > Meetings permitting (which is doubtful, today :-() I'll see if I can > > pin that down. > > > > It would, however, be fairly peculiar if test_fork1 breaks on all > > SMP-supporting systems... I don't really recall a reason for thread > > semantics to change reliably based on kernel/cpu settings, and it would > > be silly for them to do so! But I'll admit threads are silly, period ;-) > Silly? Without threads your clothes would fall off . Clothes ? What clothes ? I'm stuck in meetings all day, remember, and those require a suit and tie. And I have suit nor tie ;) > I wonder whether the "fork" part is a red herring here. It's extremely rare > to see a thread bug that actually requires a multi-headed machine to trigger > (in fact, I don't believe I've ever seen one), but the nature of races in > flawed threaded code is often such that you're a million times more *likely* > to hit a bad timing window on a multi-headed machine than on a time-sliced > single-headed box. Actually, I got the impression the 'bug' wasn't only present on multi-headed Linux machines with an SMP kernel, but single-headed Linux machines with an SMP kernel as well. You see, in Linux, the extra logic required for SMP is optional, at compile time. It changes a lot in the scheduler, but I'm not sure if it should be visible from outside. I haven't actually tested it on a UP machine with SMP kernel, though. And anyway, I thought the test_fork1 test tested for fork() behaviour in threads. It spawns a thread, fork()s one of those threads, and tests to see if the other threads still exist after the fork(), in the new child. The entire test is done in Python code, so how the scheduler and/or race conditions come into play isn't too obvious to me. Except of course the whole test if flawed. > > 6-AM-and-preparing-for-a-full-10-hour-day-of-meetings-:-S-ly y'rs, > So long as you still put in your 18 hours on Python today, we're happy to > let you engage in all the recreational activities you like . I'll clock the hours I spend thinking about Python in those meetings, so not to worry ;) Dreaming-Python-makes-it-24h-a-day-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Fredrik Lundh" Message-ID: <005f01bff79c$daa0e6c0$f2a6b5d4@hagrid> moshe wrote: > On Wed, 26 Jul 2000, Jeremy Hylton wrote: >=20 > > The argument about finalization is specious. You should not write > > code that depends on current finalization semantics to do things = like > > closing files. It's relying on an implementation-dependent feature > > that is not part of the language spec. (Just try it on JPython.) >=20 > I know, and I'm not. But the thing is, there are plenty of users of > CPython which do rely on this feature -- so you're going to break > people's code. Not nice. one problem is that there are many places when you don't know if you can close the file or not -- whoever handed you the file handle might expect it to remain open after you've done with it. That's why people use stuff like: self.fp =3D None # close if I'm the last user ::: But wouldn't fp =3D fopen(...); if (!fp && (errno =3D=3D EMFILE || errno =3D=3D ENFILE)) { py_force_gc(); fp =3D fopen(...); } solve this, at least for simple scripts? From Fredrik Lundh" Message-ID: <007b01bff79d$d3f5f120$f2a6b5d4@hagrid> tim wrote: > Seems odd that test_popen2 is still being skipped (I thought we were = fixing > popen & friends under Windows, but lost track of that). well, didn't you volunteer to fix the last few things for Win9X? ;-) (the w9xpopen.exe needs to be built and installed in the proper place, but I'm using VC5 and would really prefer if someone with VC6 took care of that...) From Fredrik Lundh" Message-ID: <008301bff79e$806d3f80$f2a6b5d4@hagrid> finn bock wrote: > Java (and JPython) compares the 16-bit characters numericly which = result in: >=20 > JPython 1.1+08 on java1.3.0 (JIT: null) > Copyright (C) 1997-1999 Corporation for National Research = Initiatives > >>> print u'\ue000' < u'\ud800' > 0 > >>> print ord(u'\ue000') < ord(u'\ud800') > 0 > >>> >=20 > I don't think I can come up with a solution that allow JPython to = emulate > CPython on this type of comparison. since we don't really support surrogates (or anything else related to 32-bit unicode) anywhere else, I'd rather change CPython to emulate JPython here. (just #ifdef out the neat stuff, and don't switch it on again before we've sorted all other 32-bit unicode issues...) From Fredrik Lundh" Message-ID: <009d01bff79f$d0b5cf60$f2a6b5d4@hagrid> tim wrote: > Seems odd that test_popen2 is still being skipped (I thought we were = fixing > popen & friends under Windows, but lost track of that). umm. looks like I forgot to check in my test_popen2.py changes. the original code skipped the test if it couldn't find os.fork... ::: if you don't have w9xpopen in place, the test will "crash": test test_popen2 crashed -- exceptions.OSError : [Errno 2] No such file or directory From mal@lemburg.com Thu Jul 27 08:58:16 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 09:58:16 +0200 Subject: [Python-Dev] test_fork1 on SMP? References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> <14719.42737.305992.235671@cj42289-a.reston1.va.home.com> <20000727060442.Q266@xs4all.nl> Message-ID: <397FEB98.17176FF0@lemburg.com> Thomas Wouters wrote: > > On Wed, Jul 26, 2000 at 11:05:21PM -0400, Fred L. Drake, Jr. wrote: > > > > Peter Schneider-Kamp writes: > > > Could SMP be involved? Do you get the same on a non-SMP system? > > > Do others have the same problem with SMP systems? > > > I think Barry may have access to an SMP Sparc machine; if so, we'll > > be checking it out there. > > I have also seen test_fork1 failures on BSDI, using a SMP machine, but I > haven't tried it on non-SMP (we don't have too many of those). However, all > our BSDI kernels are the same, having been built for SMP. Meetings > permitting (which is doubtful, today :-() I'll see if I can pin that down. > > It would, however, be fairly peculiar if test_fork1 breaks on all > SMP-supporting systems... I don't really recall a reason for thread > semantics to change reliably based on kernel/cpu settings, and it would be > silly for them to do so! But I'll admit threads are silly, period ;-) Could you be more specific about which aspect of test_fork1.py fails ? After looking at the code it seems that it's not the os.fork() itself that is not working, but some particular combination of using os.fork() on a process with multiple threads running. If the latter is the case, then I'd propose to simply switch off threads for SMP machines (is there a compile time switch we could use for this ?) until we have figured out what causes the problem. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 27 09:02:49 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 10:02:49 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> Message-ID: <397FECA9.56BB1C50@lemburg.com> Guido van Rossum wrote: > > I should add something about the assumed pseudo thread-safety of a+=b. > > I think this assumption is bogus, since we have to load a, do some > stuff, and then store a, and we can't guarantee that the stuff we do > is atomic -- in face we *know* it's not if it involves a user-defined > method. > > Simply put: > > a += 1 IS NOT ATOMIC! > > Note that C doesn't guarantee that a++ is atomic either, even if a is > declared volatile. (I believe there's an atomic data type, but I > don't think it guarantees atomic ++. That would be very expensive > because the VM cache would have to be flushed on multiprocessor > machines. The only docs I found are at > http://www.gnu.org/manual/glibc-2.0.6/html_node/libc_365.html.) If that's the case, then why do we need augemented assignments at all ? (I understood the atomicness being the main argument for introducing augmented assigns.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 27 09:22:31 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 10:22:31 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> Message-ID: <397FF146.2D307063@lemburg.com> Finn Bock wrote: > > CPythons unicode compare function contains some code to compare surrogate > characters in code-point order (I think). This is properly a very neat > feature but is differs from java's way of comparing strings. > > Python 2.0b1 (#0, Jul 26 2000, 21:29:11) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> print u'\ue000' < u'\ud800' > 1 > >>> print ord(u'\ue000') < ord(u'\ud800') > 0 > >>> > > Java (and JPython) compares the 16-bit characters numericly which result in: > > JPython 1.1+08 on java1.3.0 (JIT: null) > Copyright (C) 1997-1999 Corporation for National Research Initiatives > >>> print u'\ue000' < u'\ud800' > 0 > >>> print ord(u'\ue000') < ord(u'\ud800') > 0 > >>> > > I don't think I can come up with a solution that allow JPython to emulate > CPython on this type of comparison. The code originally worked the same way as what Java does here. Bill Tutt then added ideas from some IBM Java lib which turns the UTF-16 comparison into a true UCS-4 comparison. This really has nothing to do with being able to support surrogates or not (as Fredrik mentioned), it is the correct behaviour provided UTF-16 is used as encoding for UCS-4 values in Unicode literals which is what Python currently does. BTW, does Java support UCS-4 ? If not, then Java is wrong here ;-) Comparing Unicode strings is not as trivial as one might think: private point areas introduce a great many possibilities of getting things wrong and the fact that many characters can be expressed by combining other characters adds to the confusion. E.g. for sorting, we'd need full normalization support for Unicode and would have to come up with some smart strategy to handle private code point areas. All this is highly non-trivial and will probably not get implemented for a while (other issues are more important right now, e.g. getting the internals to use the default encoding instead of UTF-8). For now I'd suggest leaving Bill's code activated because it does the right thing for Python's Unicode implementation (which is built upon UTF-16). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Thu Jul 27 10:06:23 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 11:06:23 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007270559.AAA04753@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 12:59:15AM -0500 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> Message-ID: <20000727110622.S266@xs4all.nl> On Thu, Jul 27, 2000 at 12:59:15AM -0500, Guido van Rossum wrote: > I'm making up opcodes -- the different variants of LOAD and STORE > don't matter. On the right I'm displaying the stack contents after > execution of the opcode (push appends to the end). I'm writing > 'result' to indicate the result of the += operator. I take it you rather see a 'AUGOP' bytecode than a 'GETSET_' bytecode, that does the loading, operation and storing ? Not that I disagree, not at all, I just want to have that clear ;) > There are two more forms of potential interest. First, what should > happen to a tuple assignment? > > a, b, c += x > > (Which is exactly the same as "(a, b, c) += x".) Here's what happens now: >>> (a, b, c) += 1,2,3 SyntaxError: no augmented assignment to tuple (Isn't a reference implementation a cool thing ? ;) > Second, what should happen to a slice assignment? The basic slice > form is: > a[i:j] += b > but there are others: Python's slice syntax allows an arbitrary [yadah] What's so special about slice assignment ? You yourself (though Tim) suggested the following: x += y is effectively (minus order and number of evaluations) x = x.__add_ab__(y) Where __add_ab__() is the Python method, if 'x' is a python class, or plain '__add__' if 'x' doesn't have an '__add_ab__', or 'y.__radd__' if x doesn't have __add__. Similarly, if 'x' is a builtin, tp_as_number->nb_inplace_add is used, or tp_as_number->nb_add, etc. (Or sq_concat, if it's a seq and the operator is add.) The __add_ab__ method, or the C equivalent, can decide for itself whether it should return 'self', thus making the operation truly in-place, or a new instance of an object. This may seem as a complicated and unexpected way to do things, but it makes it possible to transparently support __add__ and __radd__ too, because they already return new objects. And you (through Tim) literally scolded me for trying to suggest x[1:10] += y being something like x = x.__add_slice_ab__(y, slice(1,10)) Instead, it should become x[1:10] = x[1:10] + y (Or rather, to keep the same order of evaluation:) tmp1 = y # in case of a more complicated expression tmp2 = x[1:10] x[1:10] = tmp2.__add_ab__(tmp1) The whole story about how complicated, convoluted and confusing Python's slicing is, though interesting and correct, is not connected to augmented assignment ;) > a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] += 1 Becomes tmp1 = a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] = tmp1.__add_ab__(1) > It would be nice if the SLICE bytecodes were removed altogether and > instead slice() objects would be created for all slices, even basic > ones. (I believe this was proposed in this list at some point.) The > original SLICE opcodes were introduced in ancient times, when basic > slices were the only accepted slice syntax. Agreed, however! You can't just make all slices use a sliceobject, for two reasons: a C extention type can use both the sequence and the mapping interface, and might not expect basic slices to be turned into a slice object. For instance, it's mapping interface may raise a TypeError, "Slices not supported", when it encounters a slice. Choosing mapping over sequence methods may break all that code. The same goes for Python classes. The other reason is usability. The current __get_slice__(self, start, end) sytnax is very convenient for nearly all uses of slices. Possibly because the builtin types don't handle extended slices currently, and possibly because the slice-object way is not generally known. (Just recently, there was someone asking on python-list on how to use slices. I'm not sure if he got a proper answer, but I've never seen such questions on the subject of basic slices!) If we do get a new __get_slice__ that handles all slices, I suggest doing it like this: class X: def __get_newslice__(self, (start, end, step)): where the type of start, end and step is not defined. This can be done with slice objects and sequence-unpacking, of course, but it makes it a lot more usable. Back-to-my-meetings-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Fredrik Lundh" <397FF146.2D307063@lemburg.com> Message-ID: <002101bff7b3$38232fe0$f2a6b5d4@hagrid> mal wrote: > This really has nothing to do with being able to support > surrogates or not (as Fredrik mentioned), it is the correct > behaviour provided UTF-16 is used as encoding for UCS-4 values > in Unicode literals which is what Python currently does. Really? I could have sworn that most parts of Python use UCS-2, not UTF-16. Built-ins like ord, unichr, len; slicing; string methods; regular expressions, etc. all clearly assume that a Py_UNICODE is a unicode code point. My point is that we shouldn't pretend we're supporting UTF-16 if we don't do that throughout. As far as I can tell, cmp() is the *only* unicode function that thinks the internal storage is UTF-16. Everything else assumes UCS-2. And for Python 2.0, it's surely easier to fix cmp() than to fix everything else. =20 (this is the same problem as 8-bit/unicode comparisions, where the current consensus is that it's better to raise an exception if it looks like the programmer doesn't know what he was doing, rather than pretend it's another encoding). ::: To summarize, here's the "character encoding guidelines" for Python 2.0: In Unicode context, 8-bit strings contain ASCII. Characters in the 0x80-0xFF range are invalid. 16-bit strings contain UCS-2. Characters in the 0xD800-0xDFFF range are invalid. If you want to use any other encoding, use the codecs pro- vided by the Unicode subsystem. If you need to use Unicode characters that cannot be represented as UCS-2, you cannot use Python 2.0's Unicode subsystem. Anything else is just a hack. From pf@artcom-gmbh.de Thu Jul 27 11:08:07 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Thu, 27 Jul 2000 12:08:07 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: from Mark Hammond at "Jul 27, 2000 2:47: 7 pm" Message-ID: Hi all, This rant is about automatically reclaimed resources like file descriptors. First let me cite a few sentences from the ancient book "Programming Python" written by Mark Lutz (p.122). Since this was the very first available book on Python, it could be considered as some kind of Python Programmers Guide. Much existing code today relies on the lessons teached there: """The short answer is that all files in this program are closed automatically: there's no need to call the file object "close" method. [...] More specifically, Python uses a reference count garbage collection strategy to reclaim memory behind the scenes. [...] each time we set 'input' to a new file in the for loop above, its previous value can be reclaimed. [...] When a file object is reclaimed, the file is automatically closed [...] We usually don't need to close such files manually; [...] """ A typical code example (simplified from a real application) : >>> import os, rfc822 >>> posters = {} >>> for arti in os.listdir('/var/spool/news/comp/lang/python'): ... poster = rfc822.Message(open(arti)).get("From") ... posters[poster] = posters.get(poster, 0) + 1 ... >>> for poster, howoften in posters.items(): ... print poster, "posted", howoften, "times to clp." ... I'm in no way convinced to consider code like above as broken. This simple automatic and deterministic behaviour of C-Python is part of the attractive elegance of Python and one of the major advantages over other languages like Java, that IMO suck beans. I've *NOT* tried scripts like the example above with JPython. But if JPython would run out of available file descriptors with such a simple application, then I think JPython or the Java VM are broken. Jeremy Hylton : > The argument about finalization is specious. You should not write > code that depends on current finalization semantics to do things like > closing files. It's relying on an implementation-dependent feature > that is not part of the language spec. (Just try it on JPython.) Eric S. Raymond" : > I strongly agree. Mark Hammond (answering to Moshe): > No - we will simply be pointing out their already broken code. We arent > breaking anything! > > I have no problem with this at all. The sooner we point out the broken > code the better. The last thing we want is for obviously and documented > broken code to suddenly be considered non-broken simply by the volume of > poor code out there... > > Either way, I think you are overstating the problem. The main scenario is > closing resources, and for most users these are unlikely to be so scarce > that delaying their finalization will cause problems. If someone is > writing a web-server, for example, and assumes that files or sockets are > automatically closed, and they open them at such a rate that true GC causes > them a problem, then IMO they have got what they deserve ;-) no no no. This time I have to agree with Moshe and disagree with Mark, Jeremy, Eric. Or I've missed the point. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From thomas@xs4all.net Thu Jul 27 11:22:24 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 12:22:24 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <397FECA9.56BB1C50@lemburg.com>; from mal@lemburg.com on Thu, Jul 27, 2000 at 10:02:49AM +0200 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> Message-ID: <20000727122223.T266@xs4all.nl> On Thu, Jul 27, 2000 at 10:02:49AM +0200, M.-A. Lemburg wrote: > Guido van Rossum wrote: > > I should add something about the assumed pseudo thread-safety of a+=b. > > Simply put: > > > > a += 1 IS NOT ATOMIC! > If that's the case, then why do we need augemented assignments > at all ? > (I understood the atomicness being the main argument for > introducing augmented assigns.) Nah, that was just something that emerged from my implementation, and only stood up in the face of simple builtin objects. I probably shouldn't have mentioned this ;-P I can't say anything about Guido's reasons for augmented assignment, but mine are ease-of-use, ease of use, and the ease of usage. And-python-is-all-about-ease-of-use-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Thu Jul 27 11:30:53 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 12:30:53 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> Message-ID: <39800F5D.C8ECF801@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > This really has nothing to do with being able to support > > surrogates or not (as Fredrik mentioned), it is the correct > > behaviour provided UTF-16 is used as encoding for UCS-4 values > > in Unicode literals which is what Python currently does. > > Really? I could have sworn that most parts of Python use > UCS-2, not UTF-16. The design specifies that Py_UNICODE refers to UTF-16. To make life easier, the implementation currently assumes UCS-2 in many parts, but this is should only be considered a temporary situation. Since supporting UTF-16 poses some real challenges (being a variable length encoding), full support for surrogates was postponed to some future implementation. > Built-ins like ord, unichr, len; slicing; > string methods; regular expressions, etc. all clearly assume > that a Py_UNICODE is a unicode code point. > > My point is that we shouldn't pretend we're supporting > UTF-16 if we don't do that throughout. We should keep that design detail in mind though. > As far as I can tell, cmp() is the *only* unicode function > that thinks the internal storage is UTF-16. > > Everything else assumes UCS-2. True. > And for Python 2.0, it's surely easier to fix cmp() than to > fix everything else. Also true :-) > (this is the same problem as 8-bit/unicode comparisions, where > the current consensus is that it's better to raise an exception > if it looks like the programmer doesn't know what he was doing, > rather than pretend it's another encoding). Perhaps you are right and we should #if 0 the comparison sections related to UTF-16 for now. I'm not sure why Bill needed the cmp() function to support surrogates... Bill ? Still, it will have to be reenabled sometime in the future when full surrogate support is added to Python. > ::: > > To summarize, here's the "character encoding guidelines" for > Python 2.0: > > In Unicode context, 8-bit strings contain ASCII. Characters > in the 0x80-0xFF range are invalid. 16-bit strings contain > UCS-2. Characters in the 0xD800-0xDFFF range are invalid. The latter is not true. In fact, thanks to Bill, the UTF-8 codec supports processing surrogates already and will output correct UTF-8 code even for Unicode strings containing surrogates. > If you want to use any other encoding, use the codecs pro- > vided by the Unicode subsystem. If you need to use Unicode > characters that cannot be represented as UCS-2, you cannot > use Python 2.0's Unicode subsystem. See above. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@beopen.com Thu Jul 27 14:09:37 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 08:09:37 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 10:02:49 +0200." <397FECA9.56BB1C50@lemburg.com> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> Message-ID: <200007271309.IAA06750@cj20424-a.reston1.va.home.com> > > Simply put: > > > > a += 1 IS NOT ATOMIC! > > > If that's the case, then why do we need augemented assignments > at all ? > > (I understood the atomicness being the main argument for > introducing augmented assigns.) Huh? Where did you get that idea? Can you point to a message where this was indicated? The reason for introducing it is that it's been the single-most requested feature ever since Python's inception. I think the reason it's been requested so much is that it's a waste of typing skills as well as (and more importantly) unnecessary extra effort to deduce what's going on in code like a.b.f().x[i] = a.b.f().x[i] + 1 Another important reason is that in cases like a[long_and_expensive_call()] = a[long_and_expensive_call()] + 1 you want to avoid doing the long_and_expensive_call() twice. Introducing a temp variable reduces the readability of the code. Note that my proposed semantics guarantee that in a[long_and_expensive_call()] += 1 the index is computed only once -- but this is not the same as atomicity (which has to do with other threads, signal handlers and similar asynchronous things). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Vladimir.Marangozov@inrialpes.fr Thu Jul 27 13:22:13 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 27 Jul 2000 14:22:13 +0200 (CEST) Subject: [Python-Dev] failures in the regression tests In-Reply-To: from "Tim Peters" at Jul 26, 2000 11:23:52 PM Message-ID: <200007271222.OAA02394@python.inrialpes.fr> Tim Peters wrote: > > On Win98, with the CVS version as of 11:15pm EDT, in both debug and release > builds: > > 59 tests OK. > 3 tests failed: test_mmap test_winreg test_winreg2 Make that 58/4 because of test_re which failure is hidden in output/test_re. /F - do you know at least what's going on? The SRE engine is a already a recurrent theme on this list, so I won't repeat what has been said, but if you can't sched some light on the errors, maybe documenting a little more the SRE code and its design would help the knowledgeable here to look at it and provide some help? -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido@beopen.com Thu Jul 27 14:37:24 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 08:37:24 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 11:06:23 +0200." <20000727110622.S266@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> Message-ID: <200007271337.IAA09101@cj20424-a.reston1.va.home.com> > I take it you rather see a 'AUGOP' bytecode than a 'GETSET_' bytecode, > that does the loading, operation and storing ? Not that I disagree, not at > all, I just want to have that clear ;) Yes, mostly because there are so many variants based on the kind of loading and storing: for each load-type operator you need 11 GETSET operators, and there are many different load operators: local, global, unspecified (== local by dict instead), by attribute, by index, or by slice... I am still neutral on the choice between a single AUGOP with an argument that takes an argument specifying the opcode, and 11 new operators: AUGASS_ADD, ... (Actually, the latter seem the most logical given that we also have BINARY_ADD, ...) > Here's what happens now: > > >>> (a, b, c) += 1,2,3 > SyntaxError: no augmented assignment to tuple > > (Isn't a reference implementation a cool thing ? ;) Very nice. Don't touch that part. > > Second, what should happen to a slice assignment? The basic slice > > form is: > > > a[i:j] += b > > > but there are others: Python's slice syntax allows an arbitrary [yadah] > > What's so special about slice assignment ? The only special thing about slice assignment is that there are 12 extra opcodes to deal with slices in the non-augmented-assignment case. I was making a case for avoiding this explosion, but somehow I got lost in my own train of thought. :( > You yourself (though Tim) > suggested the following: > > x += y > > is effectively (minus order and number of evaluations) > > x = x.__add_ab__(y) > > Where __add_ab__() is the Python method, if 'x' is a python class, or plain > '__add__' if 'x' doesn't have an '__add_ab__', or 'y.__radd__' if x doesn't > have __add__. Similarly, if 'x' is a builtin, tp_as_number->nb_inplace_add is > used, or tp_as_number->nb_add, etc. (Or sq_concat, if it's a seq and the > operator is add.) > > The __add_ab__ method, or the C equivalent, can decide for itself whether it > should return 'self', thus making the operation truly in-place, or a new > instance of an object. This may seem as a complicated and unexpected way to > do things, but it makes it possible to transparently support __add__ and > __radd__ too, because they already return new objects. > > And you (through Tim) literally scolded me for trying to suggest > > x[1:10] += y > > being something like > > x = x.__add_slice_ab__(y, slice(1,10)) > > Instead, it should become > > x[1:10] = x[1:10] + y > > (Or rather, to keep the same order of evaluation:) > > tmp1 = y # in case of a more complicated expression > tmp2 = x[1:10] > x[1:10] = tmp2.__add_ab__(tmp1) > > The whole story about how complicated, convoluted and confusing Python's > slicing is, though interesting and correct, is not connected to augmented > assignment ;) > > > a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] += 1 > > Becomes > > tmp1 = a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] > a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] = tmp1.__add_ab__(1) Yes. I should have realized earlier on that my pseudo code was just spelling out the necessary DUP etc. opcodes to avoid calculating the location of 'a' or the index(es) twice. Looking at my pseudo code for "a[i:j] += b" again, I realize that there's no reason to treat basic slices different than in other contexts -- it can be done with just DUP, ROT3 and ROT4: a[i:j] += b LOAD a [a] DUP [a, a] LOAD i [a, a, i] DUP [a, a, i, i] ROT3 [a, i, a, i] LOAD j [a, i, a, i, j] DUP [a, i, a, i, j, j] ROT4 [a, i, j, a, i, j] GETSLICE [a, i, j, slice] LOAD b [a, i, j, slice, b] AUGADD [a, i, j, result] SETSLICE [] So we need a new opcode ROT4 (or ROT_FOUR to be consistent in the spelling). > > It would be nice if the SLICE bytecodes were removed altogether and > > instead slice() objects would be created for all slices, even basic > > ones. (I believe this was proposed in this list at some point.) The > > original SLICE opcodes were introduced in ancient times, when basic > > slices were the only accepted slice syntax. > > Agreed, however! You can't just make all slices use a sliceobject, for two > reasons: a C extention type can use both the sequence and the mapping > interface, and might not expect basic slices to be turned into a slice > object. For instance, it's mapping interface may raise a TypeError, "Slices > not supported", when it encounters a slice. Choosing mapping over sequence > methods may break all that code. The same goes for Python classes. That's right. The backwards compatibility issues are the most daunting. > The other reason is usability. The current __get_slice__(self, start, end) > sytnax is very convenient for nearly all uses of slices. Possibly because > the builtin types don't handle extended slices currently, and possibly > because the slice-object way is not generally known. (Just recently, there > was someone asking on python-list on how to use slices. I'm not sure if he > got a proper answer, but I've never seen such questions on the subject of > basic slices!) > > If we do get a new __get_slice__ that handles all slices, I suggest doing it > like this: > > class X: > def __get_newslice__(self, (start, end, step)): > > where the type of start, end and step is not defined. This can be done with > slice objects and sequence-unpacking, of course, but it makes it a lot more > usable. Another alternative that tries to preserve compatibility is to call __getslice__(self, start, end) when the step is None, but __getslice__(self, start, end, step) when it isn't. Old code will raise a reasonable exception when a step is specified, while step-aware code can specify the step as a default argument value of 1 or None. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Thu Jul 27 14:41:25 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 08:41:25 -0500 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: Your message of "Thu, 27 Jul 2000 12:12:48 +0200." <002101bff7b3$38232fe0$f2a6b5d4@hagrid> References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> Message-ID: <200007271341.IAA09455@cj20424-a.reston1.va.home.com> > As far as I can tell, cmp() is the *only* unicode function > that thinks the internal storage is UTF-16. > > Everything else assumes UCS-2. > > And for Python 2.0, it's surely easier to fix cmp() than to > fix everything else. Agreed (I think). > (this is the same problem as 8-bit/unicode comparisions, where > the current consensus is that it's better to raise an exception > if it looks like the programmer doesn't know what he was doing, > rather than pretend it's another encoding). > > ::: > > To summarize, here's the "character encoding guidelines" for > Python 2.0: > > In Unicode context, 8-bit strings contain ASCII. Characters > in the 0x80-0xFF range are invalid. 16-bit strings contain > UCS-2. Characters in the 0xD800-0xDFFF range are invalid. > > If you want to use any other encoding, use the codecs pro- > vided by the Unicode subsystem. If you need to use Unicode > characters that cannot be represented as UCS-2, you cannot > use Python 2.0's Unicode subsystem. > > Anything else is just a hack. I wouldn't go so far as raising an exception when a comparison involves 0xD800-0xDFFF; after all we don't raise an exception when an ASCII string contains 0x80-0xFF either (except when converting to Unicode). The invalidity of 0xD800-0xDFFF means that these aren't valid Unicode code points; it doesn't mean that we should trap all attempts to use these values. That ways, apps that need UTF-16 awareness can code it themselves. Why? Because I don't want to proliferate code that explicitly traps 0xD800-0xDFFF throughout the code. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Thu Jul 27 14:44:26 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 08:44:26 -0500 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Your message of "Thu, 27 Jul 2000 12:08:07 +0200." References: Message-ID: <200007271344.IAA09722@cj20424-a.reston1.va.home.com> > This rant is about automatically reclaimed resources like file descriptors. > > First let me cite a few sentences from the ancient book "Programming Python" > written by Mark Lutz (p.122). Since this was the very first available book > on Python, it could be considered as some kind of Python Programmers Guide. > Much existing code today relies on the lessons teached there: > > """The short answer is that all files in this program are closed > automatically: there's no need to call the file object "close" method. > [...] > More specifically, Python uses a reference count garbage collection > strategy to reclaim memory behind the scenes. > [...] > each time we set 'input' to a new file in the for loop above, its > previous value can be reclaimed. > [...] > When a file object is reclaimed, the file is automatically closed > [...] > We usually don't need to close such files manually; > [...] > """ At the time Mark wrote, this was true. When JPython was introduced, I realized that I couldn't guarantee this in all implementations, so I removed that part of the language spec (at least in my head, and in the collective memory of the Python community). In any case, Moshe used this argument to defend weak binding to references to outer variables from inside inner functions; but that breaks closures, which is unacceptable. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From mwh21@cam.ac.uk Thu Jul 27 13:55:19 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: Thu, 27 Jul 2000 13:55:19 +0100 (BST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271337.IAA09101@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 27 Jul 2000, Guido van Rossum wrote: > > Here's what happens now: > > > > >>> (a, b, c) += 1,2,3 > > SyntaxError: no augmented assignment to tuple > > > > (Isn't a reference implementation a cool thing ? ;) > > Very nice. Don't touch that part. I think quite a lot of the code I wrote in compile.c for my augmented assignment patch lives on in Thomas's patch, and I was very conservative; if I couldn't work out what something should mean, I banned it (eg. a += b += c is a syntax error too). On reflection, I think I got this right. The error messages could be imporoved, I suspect. [snip to a very nearly completely different topic] > Another alternative that tries to preserve compatibility is to call > __getslice__(self, start, end) when the step is None, but > __getslice__(self, start, end, step) when it isn't. Old code will > raise a reasonable exception when a step is specified, while > step-aware code can specify the step as a default argument value of > 1 or None. Good idea. Are lists and tuples going to support seq[a:b:c] anytime soon? Patches welcome, I'd guess... Cheers, M. From thomas@xs4all.net Thu Jul 27 14:00:36 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 15:00:36 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271337.IAA09101@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 08:37:24AM -0500 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> Message-ID: <20000727150036.Z224@xs4all.nl> On Thu, Jul 27, 2000 at 08:37:24AM -0500, Guido van Rossum wrote: > > I take it you rather see a 'AUGOP' bytecode than a 'GETSET_' bytecode, > > that does the loading, operation and storing ? Not that I disagree, not at > > all, I just want to have that clear ;) > Yes, mostly because there are so many variants based on the kind of > loading and storing: for each load-type operator you need 11 GETSET > operators, and there are many different load operators: local, global, > unspecified (== local by dict instead), by attribute, by index, or by > slice... Except if you add a new type of bytecode, the 2-argument type. Which is what my implementation currently does. It necessitates just 9 new bytecodes that way: GETSET_SUBSCR, SLICE+0 through SLICE+3, NAME, FAST, GLOBAL and ATTR. The last four need 2 arguments, one for the name-index (or local vrbl number) and one for the actual operation. > I am still neutral on the choice between a single AUGOP with an > argument that takes an argument specifying the opcode, and 11 new > operators: AUGASS_ADD, ... (Actually, the latter seem the most > logical given that we also have BINARY_ADD, ...) Agreed. However, there isn't enough place in the current bytecode ranges for 9 consecutive non-argument opcodes. I'm also not sure how scarce a commodity opcodes are. Then again, it can also be 'undone' later. > > What's so special about slice assignment ? > The only special thing about slice assignment is that there are 12 > extra opcodes to deal with slices in the non-augmented-assignment > case. I was making a case for avoiding this explosion, but somehow I > got lost in my own train of thought. :( There's no explosion in the augmented assignment case, anyhow: either it's just 4 opcodes for handling slices, or it reuses the current opcodes. > So we need a new opcode ROT4 (or ROT_FOUR to be consistent in the > spelling). Yes. How about a ROT_ANY argument opcode while we're at it ? would specify the number to rotate... you could even encode *how* to rotate in that argument. (using the upper byte, imposing a sensible limit of 255 for the number of rotations ;-) > > class X: > > def __get_newslice__(self, (start, end, step)): > > where the type of start, end and step is not defined. This can be done with > > slice objects and sequence-unpacking, of course, but it makes it a lot more > > usable. > Another alternative that tries to preserve compatibility is to call > __getslice__(self, start, end) when the step is None, but > __getslice__(self, start, end, step) when it isn't. Old code will > raise a reasonable exception when a step is specified, while > step-aware code can specify the step as a default argument value of > 1 or None. Yes, that's very reasonable. I would suggest making the error 'special', in this case, though. So that you don't get a TypeError about incorrect number of arguments, but rather a 'object does not support extended slices' or some such TypeError. Actually, it might be worth doing it like this: Try to call __getslice__ with unconverted start, stop and step If it fails with a TypeError, and step is not None, raise the above error Else, convert start and stop to ints like the current normal slice behaviour, and try __getslice__ the old way. Or is that too much magic ? I don't think it'll break anything written in Python code, but I'm not sure what to do with the C API... But it's easier to break the API than Python code, me thinks. Break-over-godda-run-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Thu Jul 27 14:02:05 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 15:02:05 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: ; from mwh21@cam.ac.uk on Thu, Jul 27, 2000 at 01:55:19PM +0100 References: <200007271337.IAA09101@cj20424-a.reston1.va.home.com> Message-ID: <20000727150204.A224@xs4all.nl> On Thu, Jul 27, 2000 at 01:55:19PM +0100, Michael Hudson wrote: > I think quite a lot of the code I wrote in compile.c for my augmented > assignment patch lives on in Thomas's patch, and I was very conservative; > if I couldn't work out what something should mean, I banned it Yup, that's all yours. I wouldn't have known how to ban it anyway, and I wouldn't have known where to start *anything* without your patch, Michael! Gratefully-y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Thu Jul 27 14:01:51 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 15:01:51 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> <200007271309.IAA06750@cj20424-a.reston1.va.home.com> Message-ID: <398032BF.1F9A09ED@lemburg.com> Guido van Rossum wrote: > > > > Simply put: > > > > > > a += 1 IS NOT ATOMIC! > > > > > If that's the case, then why do we need augemented assignments > > at all ? > > > > (I understood the atomicness being the main argument for > > introducing augmented assigns.) > > Huh? Where did you get that idea? Can you point to a message where > this was indicated? It was advertised this way by Thomas: http://www.python.org/pipermail/python-list/2000-June/060680.html And since assignments in Python are thread safe, I thought it would only be natural for augemented assigns to also be thread safe which would have been a real advantage, since a=a+1 is not thread safe. All other uses simply boil down to reducing typing efforts, IMHO. (But that shouldn't keep you from adding it to the language ;-) Some comments: > The reason for introducing it is that it's been the single-most > requested feature ever since Python's inception. I think the reason > it's been requested so much is that it's a waste of typing skills as > well as (and more importantly) unnecessary extra effort to deduce > what's going on in code like > > a.b.f().x[i] = a.b.f().x[i] + 1 This can be written as: result = a.b.f().x result[i] = result[i] + 1 > Another important reason is that in cases like > > a[long_and_expensive_call()] = a[long_and_expensive_call()] + 1 Dito for this one: i = long_and_expensive_call() a[i] = a[i] + 1 > you want to avoid doing the long_and_expensive_call() twice. > Introducing a temp variable reduces the readability of the code. Not really... in fact if the name makes it clear what it refers too, it can augment the readbility. Besdies, a.b.f().x[i] isn't good style to begin with ;-) > Note that my proposed semantics guarantee that in > > a[long_and_expensive_call()] += 1 > > the index is computed only once -- but this is not the same as > atomicity (which has to do with other threads, signal handlers and > similar asynchronous things). Nevermind... I just wanted to hint at the added value of making these assignments atomic operations and not just an optimization of a = a + 1. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@beopen.com Thu Jul 27 15:12:58 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 09:12:58 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 13:55:19 +0100." References: Message-ID: <200007271412.JAA12251@cj20424-a.reston1.va.home.com> > Good idea. Are lists and tuples going to support seq[a:b:c] anytime soon? It's on my wish list, but can't be done for 2.0. > Patches welcome, I'd guess... Yes. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Thu Jul 27 15:22:48 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 09:22:48 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 15:00:36 +0200." <20000727150036.Z224@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> Message-ID: <200007271422.JAA13096@cj20424-a.reston1.va.home.com> > > Yes, mostly because there are so many variants based on the kind of > > loading and storing: for each load-type operator you need 11 GETSET > > operators, and there are many different load operators: local, global, > > unspecified (== local by dict instead), by attribute, by index, or by > > slice... > > Except if you add a new type of bytecode, the 2-argument type. Which is what > my implementation currently does. It necessitates just 9 new bytecodes that > way: GETSET_SUBSCR, SLICE+0 through SLICE+3, NAME, FAST, GLOBAL and ATTR. > The last four need 2 arguments, one for the name-index (or local vrbl > number) and one for the actual operation. But the two-arg opcode format slows down the opcode decoding -- and that's the most time-critical part of all of ceval.c! > > I am still neutral on the choice between a single AUGOP with an > > argument that takes an argument specifying the opcode, and 11 new > > operators: AUGASS_ADD, ... (Actually, the latter seem the most > > logical given that we also have BINARY_ADD, ...) > > Agreed. However, there isn't enough place in the current bytecode ranges for > 9 consecutive non-argument opcodes. I'm also not sure how scarce a commodity > opcodes are. Then again, it can also be 'undone' later. There's no need for them to be consecutive! (The BINARY_* family isn't even consecutive!) I say, just some open ranges, like 54-59 and 73-79. > Yes. How about a ROT_ANY argument opcode while we're at it ? would > specify the number to rotate... you could even encode *how* to rotate in > that argument. (using the upper byte, imposing a sensible limit of 255 for > the number of rotations ;-) No, let's not overgeneralize. > > Another alternative that tries to preserve compatibility is to call > > __getslice__(self, start, end) when the step is None, but > > __getslice__(self, start, end, step) when it isn't. Old code will > > raise a reasonable exception when a step is specified, while > > step-aware code can specify the step as a default argument value of > > 1 or None. > > Yes, that's very reasonable. I would suggest making the error 'special', > in this case, though. So that you don't get a TypeError about incorrect > number of arguments, but rather a 'object does not support extended slices' > or some such TypeError. Yes. > Actually, it might be worth doing it like this: > > Try to call __getslice__ with unconverted start, stop and step > If it fails with a TypeError, and step is not None, raise the above error > Else, convert start and stop to ints like the current normal slice > behaviour, and try __getslice__ the old way. No, trying to call something and retrying if it fails is a bad idea: the code might fail for a very different reason, and retrying it might mask the bug, or execute a side effect twice... There's no reason why we can't check whether the step is None; it's already impossible to find out whether a particular slice was "lo:hi:None" or "lo:hi:" (once extended slice mode is used). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From nascheme@enme.ucalgary.ca Thu Jul 27 14:50:58 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 27 Jul 2000 07:50:58 -0600 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: ; from Tim Peters on Thu, Jul 27, 2000 at 01:17:03AM -0400 References: <14719.49496.935765.730596@anthem.concentric.net> Message-ID: <20000727075058.A25450@keymaster.enme.ucalgary.ca> On Thu, Jul 27, 2000 at 01:17:03AM -0400, Tim Peters wrote: > If there exists a platform on which it fails but it doesn't fail every time > on that platform, that would be strong evidence of a timing hole. Those > usually require thought to identify and repair. I'll voluteer to > eyeball the code and do some thinking, but not unless the symptoms suggest > that's worthwhile. > > ignorantly y'rs - tim Here is some code that seems to hang on Linux UP machines. Sometimes it prints PIDS for a while and other times it stops after only a few. I don't know if that counts. I raised this issue over a month ago. Tim, your getting forgetful. :) Neil import threading import os, sys class MyThread(threading.Thread): def start(self): threading.Thread.start(self) def run(self): while 1: if os.fork() == 0: print os.getpid() os._exit(0) os.wait() MyThread().start() MyThread().start() MyThread().start() From billtut@microsoft.com Thu Jul 27 14:55:59 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 06:55:59 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33A@RED-MSG-50> Fredrik wrote: > since we don't really support surrogates (or anything else > related to 32-bit unicode) anywhere else, I'd rather change > CPython to emulate JPython here. That's not entirely true. UTF-8 encoding supports surrogates. No reason that we couldn't put the code into a unicode helper function module. If I get a chance to finish my port of the simple Unicode compression thing that'll support surrogates as well. We're eventually going to need one of these anyway for additional Unicode related algorithms. Collation, etc... Bill From Fredrik Lundh" <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> <200007271341.IAA09455@cj20424-a.reston1.va.home.com> Message-ID: <006901bff7d3$c06d1e40$f2a6b5d4@hagrid> > [me] > > To summarize, here's the "character encoding guidelines" for > > Python 2.0: > >=20 > > In Unicode context, 8-bit strings contain ASCII. Characters > > in the 0x80-0xFF range are invalid. 16-bit strings contain > > UCS-2. Characters in the 0xD800-0xDFFF range are invalid. > >=20 > > If you want to use any other encoding, use the codecs pro- > > vided by the Unicode subsystem. If you need to use Unicode > > characters that cannot be represented as UCS-2, you cannot > > use Python 2.0's Unicode subsystem. > >=20 > > Anything else is just a hack. [guido] > I wouldn't go so far as raising an exception when a comparison > involves 0xD800-0xDFFF; after all we don't raise an exception when an > ASCII string contains 0x80-0xFF either (except when converting to > Unicode). that's what the "unicode context" qualifier means: 8-bit strings can contain anything, unless you're using them as unicode strings. > The invalidity of 0xD800-0xDFFF means that these aren't valid Unicode > code points; it doesn't mean that we should trap all attempts to use > these values. That ways, apps that need UTF-16 awareness can code it > themselves. >=20 > Why? Because I don't want to proliferate code that explicitly traps > 0xD800-0xDFFF throughout the code. you only need to check "on the way in", and leave it to the decoders to make sure they generate UCS-2 only. the original unicode implementation did just that, but Bill and Marc-Andre recently lowered the shields: the UTF-8 decoder now generates UTF-16 encoded data. (so does \N{}, but that's a non-issue:=20 (oddly enough, the UTF-16 decoder won't accept anything that isn't UCS-2 ;-) my proposal is to tighten this up in 2.0: ifdef out the UTF-16 code in the UTF-8 decoder, and ifdef out the UTF-16 stuff in the compare function. let's wait until 2.1 before we support the full unicode character set (and I'm pretty sure "the right way" is UCS-4 storage and a unified string implementation, but let's discuss that later). patch coming. From jeremy@beopen.com Thu Jul 27 15:06:17 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 27 Jul 2000 10:06:17 -0400 (EDT) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: References: Message-ID: <14720.16857.900370.320050@bitdiddle.concentric.net> >>>>> "PF" == Peter Funk writes: PF> Hi all, This rant is about automatically reclaimed resources PF> like file descriptors. PF> First let me cite a few sentences from the ancient book PF> "Programming Python" written by Mark Lutz (p.122). Since this PF> was the very first available book on Python, it could be PF> considered as some kind of Python Programmers Guide. Feel free to think of it as a guide, but don't think of it as a specification! (It is, as you mention, fairly old.) The only official word on reclaiming externel resource is the Python Language Reference -- http://www.python.org/doc/current/ref/. >Some objects contain references to "external" resources such as open >files or windows. It is understood that these resources are freed when >the object is garbage-collected, but since garbage collection is not >guaranteed to happen, such objects also provide an explicit way to >release the external resource, usually a close() method. Programs are >strongly recommended to explicitly close such objects. The >`try...finally' statement provides a convenient way to do this. If this isn't clear enough, we could revise it for the next release of the documentation. As Guido said, the code is broken, not JPython. Jeremy From Fredrik Lundh" <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> <200007271341.IAA09455@cj20424-a.reston1.va.home.com> <006901bff7d3$c06d1e40$f2a6b5d4@hagrid> Message-ID: <007601bff7d4$60a644e0$f2a6b5d4@hagrid> I wrote: > now generates UTF-16 encoded data. (so does \N{}, but > that's a non-issue:=20 ...because all characters in the current name database have 16-bit codes. From Vladimir.Marangozov@inrialpes.fr Thu Jul 27 14:52:40 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 27 Jul 2000 15:52:40 +0200 (CEST) Subject: [Python-Dev] was Re: Type inference now simplicity (fwd) In-Reply-To: from "Moshe Zadka" at Jul 27, 2000 08:06:00 AM Message-ID: <200007271352.PAA02626@python.inrialpes.fr> Moshe Zadka wrote: > > [c.l.py posting deleted] > > [Moshe, concluding] > > Adding new operators and new syntax will make Python harder to read, and > harder to learn. I don't want that. > To some extent, I share these feelings. But only to some extent, because in my eyes it's all a matter of priority. I'll try to elaborate quickly. Before going into extending Python with features, it's more important to make the current implementation rock solid, a.k.a "commercial quality". Presently, this is not really the case and there are already long-standing known issues that nobody gets excited about. Solving these issues is of paramount importance for the acceptance of Python in .com software and generally speaking, its proliferation. For instance: 1. It is unacceptable that Python blows when a generated code object happens to be greater than 2 bytes. If this doesn't get fixed in the VM, the compiler should at least check for this overflow and refuse to emit the bytecode stream. 2. It is unacceptable that Python leaks memory or happens to core dump, without having optional emergency procedures. In this regard, I highly value robust (commercial) software which, for example, pops up a window on low-memory conditions inviting me to free more mem by quitting other apps and gives me the choice to abort the current execution or resume it. Python core dumps on several known situations, notably those that involve recursive calls. 3. I consider very-high priority the recently discussed integrated help system. 4. I consider high priority the opportunity to get more performance in terms of system resources: memory & execution speed. And this is why I'm working on it as time permits. I find unacceptable the fact that there are already some potential improvements on the table which have not been considered seriously so far: removal of SET_LINENO, GC + malloc integration, etc. 5. I find unwise the whole process of enriching the core, whithout a global vision on a modular and extensible core architecture. Adding 10 additional opcodes for augmented assignment is considered nuts. The addition of opcodes for extended calls is already a fact, although I never use them and I don't need them. Other enhancements have been proposed and they come on top of the system, making it quite heavy. And I don't use Unicode - so why it isn't optional? Because there's no a truly modular architecture in place. I hope that python-dev will eventually realize that all these issues are more important that augmented assignment, zip(), and other recently discussed enhancements. IMO, the latter are crap compared to the concerns above. and-I'm-not-talking-about-types-or-Py3K'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From billtut@microsoft.com Thu Jul 27 15:18:56 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 07:18:56 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33B@RED-MSG-50> > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Fredrik Lundh wrote: > > > > mal wrote: > > > This really has nothing to do with being able to support > > > surrogates or not (as Fredrik mentioned), it is the correct > > > behaviour provided UTF-16 is used as encoding for UCS-4 values > > > in Unicode literals which is what Python currently does. > > > > Really? I could have sworn that most parts of Python use > > UCS-2, not UTF-16. > The design specifies that Py_UNICODE refers to UTF-16. To make > life easier, the implementation currently assumes UCS-2 in > many parts, but this is should only be considered a > temporary situation. Since supporting UTF-16 poses some > real challenges (being a variable length encoding), full > support for surrogates was postponed to some future > implementation. Heh. Now you're being silly. Supporting UTF-16 isn't that difficult. You always know whether the character is a low surrogate or a high surrogate. The interesting question is whether or not you have your builtin Unicode object expose each 16-bit character as is, or you support iterating over Py_UCS4 characters, or you want to have a wrapping object that does the right thing here. This might be the way to go. > > Built-ins like ord, unichr, len; slicing; > > string methods; regular expressions, etc. all clearly assume > > that a Py_UNICODE is a unicode code point. > > > > My point is that we shouldn't pretend we're supporting > > UTF-16 if we don't do that throughout. > We should keep that design detail in mind though. > > As far as I can tell, cmp() is the *only* unicode function > > that thinks the internal storage is UTF-16. > > > Everything else assumes UCS-2. No, its UTF-16, it just doesn't yet handle surrogates in all of the appropriate places. :) The unicodename stuff also needs to support future named surrogate characters now. > > And for Python 2.0, it's surely easier to fix cmp() than to > > fix everything else. > Also true :-) Everything but the regular expressions would be fairly simple to add UTF-16 support to. I'd imagine that adding support for \u10FFFF in the regular expression syntax wouldn't be that hard either. > > (this is the same problem as 8-bit/unicode comparisions, where > > the current consensus is that it's better to raise an exception > > if it looks like the programmer doesn't know what he was doing, > > rather than pretend it's another encoding). > Perhaps you are right and we should #if 0 the comparison > sections related to UTF-16 for now. I'm not sure why Bill > needed the cmp() function to support surrogates... Bill ? I didn't need it to. I happened upon the code on the IBM website, so I figured I'd point it out and see what people thought of sticking it into the Python Unicode stuff. :) (Wishing Python 2.0 would ship with Unicode collation support) See the earlier comment about creating a wrapping class that handles UTF-16 issues better. > Still, it will have to be reenabled sometime in the > future when full surrogate support is added to Python. Bill From Moshe Zadka Thu Jul 27 15:26:04 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 27 Jul 2000 17:26:04 +0300 (IDT) Subject: [Python-Dev] was Re: Type inference now simplicity (fwd) In-Reply-To: <200007271352.PAA02626@python.inrialpes.fr> Message-ID: On Thu, 27 Jul 2000, Vladimir Marangozov wrote: > Before going into extending Python with features, it's more important > to make the current implementation rock solid, a.k.a "commercial quality". > Presently, this is not really the case and there are already long-standing > known issues that nobody gets excited about. Solving these issues is of > paramount importance for the acceptance of Python in .com software and > generally speaking, its proliferation. I agree. > For instance: > > 1. It is unacceptable that Python blows when a generated code object > happens to be greater than 2 bytes. If this doesn't get fixed in > the VM, the compiler should at least check for this overflow and > refuse to emit the bytecode stream. Can you elaborate on that? At least the numeric typo error makes this a guessing job > 2. It is unacceptable that Python leaks memory or happens to core dump, > without having optional emergency procedures. In this regard, I highly > value robust (commercial) software which, for example, pops up a window > on low-memory conditions inviting me to free more mem by quitting other > apps and gives me the choice to abort the current execution or resume it. Personally, I don't. If there is no memory, Python should quit gracefully (throwing MemoryError exception is fine by me -- core dumping is not) > Python core dumps on several known situations, notably those that > involve recursive calls. This doesn't have to do with low-memory conditions, this is because Python uses the C stack. Finally putting in stackless will make this the same as low-memory conditions, and we already covered that 3. I consider very-high priority the recently discussed integrated help > system. I don't. It's in the "useful, but not necessary". What *is* necessary is a good IDE, with integrated help. IDLE is being worked on, as is ActiveState's Komodo and my Bwian vapourware. > 4. I consider high priority the opportunity to get more performance in > terms of system resources: memory & execution speed. And this is why > I'm working on it as time permits. I find unacceptable the fact that > there are already some potential improvements on the table which have > not been considered seriously so far: removal of SET_LINENO, GC + malloc > integration, etc. I totally agree -- and even more so. I hope to have the time to work on serious Python optimization, notable things like method caching, optimizing built-in function calls, etc. > 5. I find unwise the whole process of enriching the core, whithout a > global vision on a modular and extensible core architecture. Adding > 10 additional opcodes for augmented assignment is considered nuts. > The addition of opcodes for extended calls is already a fact, although > I never use them and I don't need them. Other enhancements have been > proposed and they come on top of the system, making it quite heavy. > And I don't use Unicode - so why it isn't optional? Because > there's no a truly modular architecture in place. Ummm.....most of unicode *is* optional: the codec package and various unicode modules are optional. u"" strings have new syntax, which is really needed. > I hope that python-dev will eventually realize that all these issues are > more important that augmented assignment I completely agree. > zip() zip() and friends (irange, product) have been suggested to live in a seperate Python module, hence completely optional. If you're talking about time usage, well, it's not your time -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From Fredrik Lundh" Message-ID: <009801bff7d9$0e90d580$f2a6b5d4@hagrid> bill wrote: > Heh. Now you're being silly. Supporting UTF-16 isn't that difficult. = You > always know whether the character is a low surrogate or a high = surrogate. sorry, but you're being silly. using variable-width encoding for interal storage is difficult, slow, and just plain stupid on modern hardware. (image processing people stopped doing stupid things like that ages ago, and trust me -- a typical image contains many more pixels than a typical text ;-) after all, if variable-width internal storage had been easy to deal with, we could have used UTF-8 from the start... (and just like the Tcl folks, we would have ended up rewriting the whole thing in the next release ;-) From billtut@microsoft.com Thu Jul 27 15:24:48 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 07:24:48 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33C@RED-MSG-50> -----Original Message----- > From: Guido van Rossum [mailto:guido@beopen.com] > The invalidity of 0xD800-0xDFFF means that these aren't valid Unicode > code points; it doesn't mean that we should trap all attempts to use > these values. That ways, apps that need UTF-16 awareness can code it > themselves. 0xD800-0xDFFF are valid code points. They just aren't characters that you normally want to render all on their own. :) > Why? Because I don't want to proliferate code that explicitly traps > 0xD800-0xDFFF throughout the code. Err... I don't think you have much choice in the long term. Its not like the code is all that difficult, and certain cases might be able to use helper functions to help centralize that particular part of code. Bill From Fredrik Lundh" <009801bff7d9$0e90d580$f2a6b5d4@hagrid> Message-ID: <00a601bff7da$12aca9e0$f2a6b5d4@hagrid> I wrote: > (image processing people stopped doing stupid things like that > ages ago, and trust me -- a typical image contains many more > pixels than a typical text ;-) ...contains characters. sorry folks, my thinkahead fifo buffer appears to be broken today. time for a reboot. From billtut@microsoft.com Thu Jul 27 15:43:44 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 07:43:44 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33D@RED-MSG-50> Fredik wrote: > the original unicode implementation did just that, but Bill and > Marc-Andre recently lowered the shields: the UTF-8 decoder > now generates UTF-16 encoded data. (so does \N{}, but > that's a non-issue:=20 > my proposal is to tighten this up in 2.0: ifdef out the UTF-16 > code in the UTF-8 decoder, and ifdef out the UTF-16 stuff in > the compare function. Commenting the UTF-16 stuff out in the compare function is a valid point, given our current Unicode string object. I disagree strongly with disabling the surrogate support in UTF-8, and we should fix the UTF-16 decoder. Since the decoder/encoder support doesn't hurt any other piece of code by emitting surrogate pairs, I don't see why you want to disable the code. > (oddly enough, the UTF-16 decoder won't accept anything > that isn't UCS-2 ;-) Well that's an easy bug to fix. > let's wait until 2.1 before we support the full unicode character > set (and I'm pretty sure "the right way" is UCS-4 storage and a > unified string implementation, but let's discuss that later). I've mentioned this before, but why discuss this later? Indeed why would we want to fix it for 2.1? Esp. if we move to UCS-4 storage in a minor release. Why not just get the Unicode support correct this time around. Save the poor users of the Python Unicode support from going nuts when we make these additional confusing changes later. If you think you want to move to UCS-4 later, don't wait, do it know. Add support for special surrogate handling later if we must, but please oh please don't change the storage mechanism in memory in a later relase. Java and Win32 are all UTF-16 based, and those extra 16-bits are actually wasted for nearly every common Unicode data you'd hope to handle. I think using UTF-16 as an internal storage mechanism actually makes sense. Whether or not you want to have your character type expose an array of 16-bit values, or the appearance of an array of UCS-4 characters is a separate issue. An issue I think should be answered now, instead of fixing it later. Bill From billtut@microsoft.com Thu Jul 27 15:49:06 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 07:49:06 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33E@RED-MSG-50> Fredrik: > sorry, but you're being silly. using variable-width encoding for > interal storage is difficult, slow, and just plain stupid on modern > hardware. So use UCS-4 internal storage now. UTF-16 just seems like a handy internal storage mechanism to pick since Win32 and Java use it for their native string processing. > (image processing people stopped doing stupid things like that > ages ago, and trust me -- a typical image contains many more > pixels than a typical text ;-) > after all, if variable-width internal storage had been easy to deal > with, we could have used UTF-8 from the start... (and just like > the Tcl folks, we would have ended up rewriting the whole thing > in the next release ;-) Oh please, UTF-16 is substantially simpler to deal with than UTF-8. I would go nuts if our internal storage mechanism was UTF-8. Bill From Vladimir.Marangozov@inrialpes.fr Thu Jul 27 16:03:51 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 27 Jul 2000 17:03:51 +0200 (CEST) Subject: [Python-Dev] was Re: Type inference now simplicity (fwd) In-Reply-To: from "Moshe Zadka" at Jul 27, 2000 05:26:04 PM Message-ID: <200007271503.RAA02899@python.inrialpes.fr> Moshe Zadka wrote: > > > For instance: > > > > 1. It is unacceptable that Python blows when a generated code object > > happens to be greater than 2 bytes. If this doesn't get fixed in > > the VM, the compiler should at least check for this overflow and > > refuse to emit the bytecode stream. > > Can you elaborate on that? At least the numeric typo error makes this > a guessing job I won't :-) Of course I meant the case where the size doesn't fit in 2 bytes, i.e. > 32k > > Python core dumps on several known situations, notably those that > > involve recursive calls. > > This doesn't have to do with low-memory conditions, this is because Python > uses the C stack. I know, it has been discussed to death. So what? Live with it (the C stack) and fix the code, as it has been done for recursive comparisons and marshal. The point of my mail isn't in the details, though... As you might guess, I haven't been exhaustive regarding the current state of the (C) implementation. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Fredrik Lundh" Message-ID: <00cb01bff7e0$79e74d80$f2a6b5d4@hagrid> bill wrote: > So use UCS-4 internal storage now. UTF-16 just seems like a handy = internal > storage mechanism to pick since Win32 and Java use it for their native > string processing. umm. the Java docs I have access to doesn't mention surrogates at all (they do point out that a character is 16-bit, and they don't provide an \U escape). on the other hand, MSDN says: Windows 2000 provides support for basic input, output, and simple sorting of surrogates. However, not all Windows 2000 system components are surrogate compatible. Also, surrogates are not supported in Windows 95/98 or in Windows NT 4.0. and then mentions all the usual problems with variable-width encodings... > > after all, if variable-width internal storage had been easy to deal > > with, we could have used UTF-8 from the start... (and just like > > the Tcl folks, we would have ended up rewriting the whole thing > > in the next release ;-) >=20 > Oh please, UTF-16 is substantially simpler to deal with than UTF-8. in what way? as in "one or two words" is simpler than "one, two, three, four, five, or six bytes"? or as in "nobody will notice anyway..." ;-) ::: if UCS-2/BMP was good enough for NT 4.0, Unicode 1.1, and Java 1.0, it's surely good enough for Python 2.0 ;-) (and if I understand things correctly, 2.1 isn't that far away...) From Fredrik Lundh" would it be a good idea to add \UXXXXXXXX (8 hex digits) to 2.0? (only characters in the 0000-ffff range would be accepted in the current version, of course). From thomas@xs4all.net Thu Jul 27 16:48:03 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 17:48:03 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271422.JAA13096@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 09:22:48AM -0500 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> Message-ID: <20000727174803.U266@xs4all.nl> On Thu, Jul 27, 2000 at 09:22:48AM -0500, Guido van Rossum wrote: [about INPLACE_ADD/SUBTRACT/ETC] > There's no need for them to be consecutive! (The BINARY_* family > isn't even consecutive!) I say, just some open ranges, like 54-59 and > 73-79. [and about ROT_ANY] > No, let's not overgeneralize. Roger dodger, wilco dilco, milli vanilli. > > Try to call __getslice__ with unconverted start, stop and step > > If it fails with a TypeError, and step is not None, raise the above error > > Else, convert start and stop to ints like the current normal slice > > behaviour, and try __getslice__ the old way. > > No, trying to call something and retrying if it fails is a bad idea: > the code might fail for a very different reason, and retrying it might > mask the bug, or execute a side effect twice... Yeah, I realized that too, while listening one of my colleagues trying to make some point or other. Hrm... So backwards compatibility is out ? I'm not sure howmany Python code uses slice-objects, but I would consider it a (personal ;) failure if slicing has to be *broken* before it can be fixed. If we can't figure out whether a function supports the 'new syntax' reliably, I don't see how we can transform the error message either. I'll bet inspecting the __getitem__ method to find out whether it supports the one or the other is way too much of a runtime penalty to suffer at each index. So the only workable way to support all combinations of __getitem__ and __getslice__ is by adding a new builtin, __getitems__ ? (too confusing a name... __getanything__ ? :P) Feeble-(after-all-those-meetings)-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@beopen.com Thu Jul 27 18:03:39 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 12:03:39 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 17:48:03 +0200." <20000727174803.U266@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> Message-ID: <200007271703.MAA00802@cj20424-a.reston1.va.home.com> > > No, trying to call something and retrying if it fails is a bad idea: > > the code might fail for a very different reason, and retrying it might > > mask the bug, or execute a side effect twice... > > Yeah, I realized that too, while listening one of my colleagues trying to > make some point or other. Hrm... So backwards compatibility is out ? I'm not > sure howmany Python code uses slice-objects, but I would consider it a > (personal ;) failure if slicing has to be *broken* before it can be fixed. Huh? I thought I proposed a b/w compat solution: IF there is a __getslice__ method: IF the slice step is None: call __getslice__(lo, hi) ELSE: # the slice step is not None call __getslice__(lo, hi, step) What's wrong with that? > If we can't figure out whether a function supports the 'new syntax' > reliably, I don't see how we can transform the error message either. I'll > bet inspecting the __getitem__ method to find out whether it supports the > one or the other is way too much of a runtime penalty to suffer at each > index. No, we don't deal with __getitem__; if *it* doesn't support a tuple containing slice objects, tough luck. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From skip@mojam.com (Skip Montanaro) Thu Jul 27 17:03:29 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 27 Jul 2000 11:03:29 -0500 (CDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <398032BF.1F9A09ED@lemburg.com> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> <200007271309.IAA06750@cj20424-a.reston1.va.home.com> <398032BF.1F9A09ED@lemburg.com> Message-ID: <14720.23889.451562.474003@beluga.mojam.com> >> Another important reason is that in cases like >> >> a[long_and_expensive_call()] = a[long_and_expensive_call()] + 1 M-A> Dito for this one: M-A> i = long_and_expensive_call() M-A> a[i] = a[i] + 1 Only if you know that long_and_expensive_call() has no side effects! Skip From mal@lemburg.com Thu Jul 27 17:09:05 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 18:09:05 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> <200007271309.IAA06750@cj20424-a.reston1.va.home.com> <398032BF.1F9A09ED@lemburg.com> <14720.23889.451562.474003@beluga.mojam.com> Message-ID: <39805EA1.9DA9BEF@lemburg.com> Skip Montanaro wrote: > > > >> Another important reason is that in cases like > >> > >> a[long_and_expensive_call()] = a[long_and_expensive_call()] + 1 > > M-A> Dito for this one: > > M-A> i = long_and_expensive_call() > M-A> a[i] = a[i] + 1 > > Only if you know that long_and_expensive_call() has no side effects! If it does, then you'll have to write the long version anyway, if it doesn't I don't see a problem, if you don't know then you shouldn't use the function anyway ;-)) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Thu Jul 27 17:13:16 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 18:13:16 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271703.MAA00802@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 12:03:39PM -0500 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> Message-ID: <20000727181315.B224@xs4all.nl> On Thu, Jul 27, 2000 at 12:03:39PM -0500, Guido van Rossum wrote: > > So backwards compatibility is out ? I'm not sure howmany Python code > > uses slice-objects, but I would consider it a (personal ;) failure if > > slicing has to be *broken* before it can be fixed. > Huh? I thought I proposed a b/w compat solution: > IF there is a __getslice__ method: > IF the slice step is None: > call __getslice__(lo, hi) > ELSE: # the slice step is not None > call __getslice__(lo, hi, step) > What's wrong with that? Well, what happens if __getslice__ and __getitem__ both exist, and __getitem__ is used to handle extended slices, but __getslice__ isn't (yet)? Currently, if it's a single item, __getitem__ is called. If it's a basic slice, __getslice__ is called. If it's an extended slice, __getitem__ is called. In the above picture, __getslice__ would be called instead, with the 'wrong' number of arguments, and the use of extended slices would break. > > If we can't figure out whether a function supports the 'new syntax' > > reliably, I don't see how we can transform the error message either. I'll > > bet inspecting the __getitem__ method to find out whether it supports the > > one or the other is way too much of a runtime penalty to suffer at each > > index. > No, we don't deal with __getitem__; if *it* doesn't support a tuple > containing slice objects, tough luck. Sorry, that was my feebleness popping up. I was talking about __getslice__. How do we find out if __getslice__ accepts 4 arguments, rather than 3 ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Thu Jul 27 17:22:48 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 18:22:48 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <20000727181315.B224@xs4all.nl>; from thomas@xs4all.net on Thu, Jul 27, 2000 at 06:13:16PM +0200 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> Message-ID: <20000727182248.V266@xs4all.nl> On Thu, Jul 27, 2000 at 06:13:16PM +0200, Thomas Wouters wrote: > Sorry, that was my feebleness popping up. I was talking about __getslice__. > How do we find out if __getslice__ accepts 4 arguments, rather than 3 ? Actually, it wasn't the feebleness as much as the two different things you seem to be wanting, Guido ;) Previously (in another thread, and perhaps in the start of this thread as well) you argued that an index should always call __getitem__, with a slice object if it's a slice of some kind, *even a basic one*. So that we lose __getslice__ and rather teach people to use __getslice__. So now you want to *extend* the 'special case' to extended, 3-argument slices, but *not* Ellipses and tupled-slices (which aren't really tuples, because you can do (1, 2:5, ...)) -- or am I reading this wrong ? :) Don't worry, Guido, it isn't just you, I failed to grasp what those managers were trying to tell me today, too... I may just be too dense, today. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@beopen.com Thu Jul 27 18:25:44 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 12:25:44 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 18:13:16 +0200." <20000727181315.B224@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> Message-ID: <200007271725.MAA17990@cj20424-a.reston1.va.home.com> > > IF there is a __getslice__ method: > > IF the slice step is None: > > call __getslice__(lo, hi) > > ELSE: # the slice step is not None > > call __getslice__(lo, hi, step) > > > What's wrong with that? > > Well, what happens if __getslice__ and __getitem__ both exist, and > __getitem__ is used to handle extended slices, but __getslice__ isn't (yet)? > Currently, if it's a single item, __getitem__ is called. If it's a basic > slice, __getslice__ is called. If it's an extended slice, __getitem__ is > called. > > In the above picture, __getslice__ would be called instead, with the 'wrong' > number of arguments, and the use of extended slices would break. Good point. Sigh. I suppose we could inspect the __getslice__ method's argument count (it *is* available somewher) but that seems a hack (and could still break if default arguments were used for something else). Another solution: require a class variable to indicate the class's awareness: e.g. you must define __getslice_takes_three_args__ when __getslice__(lo, hi, step) is supported, otherwise the call goes to __getitem__(slice(lo, hi, step)). This is a bit like the feature flag bits in the type struct. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Thu Jul 27 18:30:51 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 12:30:51 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 18:22:48 +0200." <20000727182248.V266@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> <20000727182248.V266@xs4all.nl> Message-ID: <200007271730.MAA21788@cj20424-a.reston1.va.home.com> > Actually, it wasn't the feebleness as much as the two different things you > seem to be wanting, Guido ;) Previously (in another thread, and perhaps in > the start of this thread as well) you argued that an index should always > call __getitem__, with a slice object if it's a slice of some kind, *even a > basic one*. So that we lose __getslice__ and rather teach people to use > __getslice__. That would be nice, but it would be b/w incompatible, so now we're trying (again) to figure out how to still support __getslice__. My proposal is to try and be b/w compatible if __getslice__ exists. See my previous mail. > So now you want to *extend* the 'special case' to extended, 3-argument > slices, but *not* Ellipses and tupled-slices (which aren't really tuples, > because you can do (1, 2:5, ...)) -- or am I reading this wrong ? :) Not sure what you mean by that. (1, 2:5, ...) by itself is illegal syntax; the special slice syntax can only occur directly in an indexing context, e.g. a[1, 2:5, ...]. > Don't worry, Guido, it isn't just you, I failed to grasp what those managers > were trying to tell me today, too... I may just be too dense, today. I hope they weren't telling you to stop working on Python! You seem made for this work... --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From tim_one@email.msn.com Thu Jul 27 17:59:04 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 12:59:04 -0400 Subject: Refcount vs GC semantics (was RE: [Python-Dev] Product iteration) In-Reply-To: Message-ID: Plea: could we try to get an accurate subject line on at least 1 msg in 10? Thanks. [Moshe] > I know, and I'm not. But the thing is, there are plenty of users of > CPython which do rely on this feature -- so you're going to break > people's code. Not nice. [Mark Hammond] > No - we will simply be pointing out their already broken code. We > arent breaking anything! > > I have no problem with this at all. The sooner we point out the > broken code the better. The last thing we want is for obviously and > documented broken code to suddenly be considered non-broken simply by > the volume of poor code out there... Spoken like a man who has never maintained a language implementation used by hordes of unhappy users <0.5 wink>. The bitching about "breaking" .append(1,2,3) was nothing compared to what this would stir up, and when the first "important" customer seriously threatens to walk, vendors usually back down out of a healthy sense of self-preservation. Been there so many times it even makes me want to puke . > Either way, I think you are overstating the problem. I agree with that too. I don't think CPython could get away with this, but you have a new implementation and users will see this as a basis on which they compete. The *convenience* of CPython's (accidental but real!) semantics here is undeniable. Still, I don't see it coming up much except wrt temp files, and if that becomes An Issue for you, you can always special-case the snot out of them. users-don't-read-manuals-but-they-do-pay-the-bills-ly y'rs - tim From ping@lfw.org Thu Jul 27 18:10:51 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 27 Jul 2000 10:10:51 -0700 (PDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 27 Jul 2000, Guido van Rossum wrote: > Second, what should happen to a slice assignment? My vote is: nothing! (Read on.) > The basic slice form is: > > a[i:j] += b What does this mean? I don't see how it could be any different from: a[j:j] = b If people want to insert sequences into other sequences, they should use this form; if they want to insert an element into a sequence, they should be encouraged to use an .insert() method. In other words, we already have perfectly good ways of doing this (more importantly, there are already clear and simple ways to implement such behaviour in your own objects). > a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] += 1 What on earth could this mean? And why would anyone want it? I can't even imagine what the simpler case a[i:j:k] += 1 would do... unless you wish to propose element-wise operators (e.g. add 1 to each of the elements that would participate in the slice) and i think that might be a whole new can of worms. It wasn't clear to me that this was your intent, though. It looks to me like going through various contortions to support augmented assignment to slices is not going to be worth the trouble. May i suggest >>> a[i:j] += b SyntaxError: augmented assignment to a slice is not allowed just like >>> (a, b, c) += 1,2,3 SyntaxError: augmented assignment to a tuple is not allowed ? -- ?!ng From Fredrik Lundh" <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> <200007271341.IAA09455@cj20424-a.reston1.va.home.com> <006901bff7d3$c06d1e40$f2a6b5d4@hagrid> Message-ID: <017901bff7ee$eadb9740$f2a6b5d4@hagrid> > my proposal is to tighten this up in 2.0: ifdef out the UTF-16 > code in the UTF-8 decoder, and ifdef out the UTF-16 stuff in > the compare function. > patch coming. http://sourceforge.net/patch/index.php?func=3Ddetailpatch&patch_id=3D1009= 90&group_id=3D5470 From ping@lfw.org Thu Jul 27 18:25:38 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 27 Jul 2000 10:25:38 -0700 (PDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271725.MAA17990@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 27 Jul 2000, Guido van Rossum wrote: > I suppose we could inspect the __getslice__ method's argument count > (it *is* available somewher) but that seems a hack (and could still > break if default arguments were used for something else). Yuck! > Another solution: require a class variable to indicate the class's > awareness: e.g. you must define __getslice_takes_three_args__ when > __getslice__(lo, hi, step) is supported, otherwise the call goes to > __getitem__(slice(lo, hi, step)). Here's another solution: if you're going to revamp the whole item/slice-getting interface, which is what this pretty much amounts to, use a separate interface. Old interface: __getitem__(index) # I get an ITEM. __getitem__(slice-object) # I get a SLICE or an ITEM. (!) __getslice__(lo, hi, step) # I get a SLICE. New interface: __get__(index) # I get an ITEM. __get__(slice-object) # I get a SLICE or an ITEM. (!) To be honest, the whole collision between slices and items makes me rather uncomfortable. I would prefer to separate them: one method for getting *items*, one method for getting *slices*. Neither of the interfaces above handles this correctly for the case of multidimensional arrays. So, how about: __get__(index, ...) # I want an ITEM. __getslice__(slice-object, ...) # I want a SLICE. I think an interface like this would be much easier to program against. The return value is better defined: __get__ always returns a single item; __getslice__ always returns some kind of collection of items (usually, if not always, the same type as the original collection being sliced). This would require detection of whether any of the components of a multidimensional (i.e. tuple) index were slices, but i think the improved consistency is well worth it. __getslice__ is called if any slices are involved; __get__ is called otherwise. Here are some examples for illustration: a[i] a.__get__(i) a[i, j] a.__get__(i, j) a[i:j] a.__getslice__(slice(i, j)) a[i:j:k] a.__getslice__(slice(i, j, k)) a[i, j, k] a.__get__(i, j, k) a[i, j, k:l] a.__getslice__(i, j, slice(k, l)) I can't imagine ever wanting to define custom behaviour for __getslice__ *without* implementing __get__ or __getitem__, so the presence of a __get__ method can be used to detect whether we should use the new interface. -- ?!ng From tim_one@email.msn.com Thu Jul 27 18:17:22 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 13:17:22 -0400 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007270611.BAA04802@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > ... > Note that C doesn't guarantee that a++ is atomic either, even if a is > declared volatile. For people who don't know, or may have forgotten, threads are not a part of std C or C++: those languages say nothing whatsoever about behavior in the presence of threads. And this is still true in C99! ANSI/ISO committees work by consensus, and there are so many goofy thread models out there consensus will never be reached (keep that in mind as you ponder how PEPs should proceed <0.6 wink>). > (I believe there's an atomic data type, but I don't think it > guarantees atomic ++. You may be thinking of sig_atomic_t? That relates to a technical meaning for "atomic" in signal handlers, a meaning that has nothing to do with threads. In effect, sig_atomic_t is simply a volatile integral type small enough so that read and write each take one machine instruction (so, e.g., a 64-bit int would not serve as a suitable sig_atomic_t on a 32-bit machine, as it would have to be read and written "in pieces", and an interrupting signal could cause an interrupted read or write to use inconsistent pieces). From ping@lfw.org Thu Jul 27 18:31:56 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 27 Jul 2000 10:31:56 -0700 (PDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Message-ID: On Thu, 27 Jul 2000, Ka-Ping Yee wrote: > So, how about: > > __get__(index, ...) # I want an ITEM. > __getslice__(slice-object, ...) # I want a SLICE. Addendum: For __set__ and __setslice__, since there may be a variable number of index arguments, it seems the value to set must *precede* the indices. The full interface: __get__(*indices) __set__(value, *indices) __del__(*indices) __getslice__(*slices) __setslice__(value, *slices) __delslice__(*slices) I prefer putting the indices last to passing in a tuple of indices for the following reasons: 1. It would be annoying and slightly slower to have to declare __get__((index,)) instead of __get__(index). 2. I want to encourage prediction of the number of indices. Since most multidimensional types are likely to have a fixed number of dimensions, it's better to have an interface look like, e.g. __get__(x, y, z) # Clearly a 3-dimensional array! instead of __get__(indices) # Don't know how many dimensions. The error is caught earlier, and the expectations of the programmer are more visible. To implement a variable number of dimensions, of course one can always write __get__(*indices) but this would not be the conventional thing to write: it would make clear that there is something special going on here. -- ?!ng From tim_one@email.msn.com Thu Jul 27 18:26:31 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 13:26:31 -0400 Subject: [Python-Dev] test_fork1 on SMP? In-Reply-To: <20000727092144.R266@xs4all.nl> Message-ID: [Thomas Wouters] > ... > And anyway, I thought the test_fork1 test tested for fork() behaviour in > threads. It spawns a thread, Four threads, actually. > fork()s one of those threads, It forks "the main" thread, which is in addition to the four it spawns. > and tests to see if the other threads still exist after the fork(), > in the new child. The entire test is done in Python code, so how > the scheduler and/or race conditions come into play isn't too > obvious to me. Except of course the whole test if flawed. The test uses loops and time.sleep instead of proper synchronization, so its behavior is at best probabilistic, depending entirely on timing accidents (*likely* accidents, but accidents all the same). But I don't have a machine here that supports fork at all, so I can't run it, and I don't know how it fails on the machines it fails on. If it's failing with a thread exiting with a non-zero exit code, then I'd say the timing uncertainties in the *Python* code are irrelevant, and it's the failing platform's fork implementation that's broken. From bckfnn@worldonline.dk Thu Jul 27 19:01:01 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Thu, 27 Jul 2000 18:01:01 GMT Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <397FF146.2D307063@lemburg.com> References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> Message-ID: <398065f3.6724599@smtp.worldonline.dk> [M.-A. Lemburg] >BTW, does Java support UCS-4 ? If not, then Java is wrong >here ;-) Java claims to use unicode 2.1 [*]. I couldn't locate anything describing if this is UCS-2 or UTF-16. I think unicode 2.1 includes UCS-4. The actual level of support for UCS-4 is properly debatable. - The builtin char is 16bit wide and can obviously not support UCS-4. - The Character class can report if a character is a surrogate: >>> from java.lang import Character >>> Character.getType("\ud800") == Character.SURROGATE 1 - As reported, direct string comparison ignore surrogates. - The BreakIterator does not handle surrogates. It does handle combining characters and it seems a natural place to put support for surrogates. - The Collator class offers different levels of normalization before comparing string but does not seem to support surrogates. This class seems a natural place for javasoft to put support for surrogates during string comparison. These findings are gleaned from the sources of JDK1.3 [*] http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#25310 regards, finn From tim_one@email.msn.com Thu Jul 27 19:20:26 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 14:20:26 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <20000727075058.A25450@keymaster.enme.ucalgary.ca> Message-ID: [Neil Schemenauer] > Here is some code that seems to hang on Linux UP machines. > Sometimes it prints PIDS for a while and other times it stops > after only a few. Well, that sucks! Does "UP" mean uniprocessor in this context? > I don't know if that counts. I raised this issue over a month > ago. Tim, your getting forgetful. :) Getting? I'm very old. I think. But even if I had a memory, I usually ignore Unix-specific posts (i.e., I can't run code with a .fork(), so can only sit back & admire the perversity of those who both can & do ). From billtut@microsoft.com Thu Jul 27 19:23:27 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 11:23:27 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD343@RED-MSG-50> > umm. the Java docs I have access to doesn't mention surrogates > at all (they do point out that a character is 16-bit, and they don't > provide an \U escape). When Java does support surrogates, it seems likely that for backward compatibility reasons that they'll start paying attention to surrogates. Altering to a 32-bit int would break too much of their users code. > on the other hand, MSDN says: > Windows 2000 provides support for basic input, output, and > simple sorting of surrogates. However, not all Windows 2000 > system components are surrogate compatible. Also, surrogates > are not supported in Windows 95/98 or in Windows NT 4.0. > and then mentions all the usual problems with variable-width > encodings... Which means it supports UTF-16, and the support can only get better. > > > after all, if variable-width internal storage had been easy to deal > > > with, we could have used UTF-8 from the start... (and just like > > > the Tcl folks, we would have ended up rewriting the whole thing > > > in the next release ;-) > >=20 > > Oh please, UTF-16 is substantially simpler to deal with than UTF-8. > in what way? as in "one or two words" is simpler than "one, two, > three, four, five, or six bytes"? > or as in "nobody will notice anyway..." ;-) As in it's very easy to determine arbitrarily which byte of the surrogate you're dealing with based on its 16-bit value. You can't say that about UTF-8. > if UCS-2/BMP was good enough for NT 4.0, Unicode 1.1, and Java 1.0, > it's surely good enough for Python 2.0 ;-) > > (and if I understand things correctly, 2.1 isn't that far away...) They were, since UTF-16 didn't exist at the time. :) I think we both want Python's unicode support to eventually support surrogate range characters. Let me see if I can reiterate what we're both trying to say. What you're saying: * We might switch to UCS-4 when we support this extra stuff because variable length encodings are annoying. My counter point: Switching to UCS-4 isn't backward compatible. If you want to avoid variable length encoding then start with UCS-4 from the beginning. BUT, keeping in mind that Windows, and Java are either right now, or likely to be UTF-16 systems. What I'm saying: * Just use UTF-16 and be done with it. Windows is using it, and Java if it isn't already is definitely likely to do so. Your counter point: Supporting UTF-16 is complicated, and we don't want to do all of this for Python 2.0. (Especially anything that involves writing a Unicode string object that hides the surrogate as two 16-bit entities) My response: This is true. I've never suggested we do all of the UTF-16 support for Python 2.0. The UTF-16 code point order comparision patch I submitted was just something I noticed online, and submitted the patch more for feedback and comments rather then wanting, or needing the patch to get in. However, that doesn't mean bad things will happen if we allow the UTF-8/16 (en/de)coders handle surrogate characters. The Python code can worry about this variable length encoding on its own. The core should still be able to UTF-8 the unicode string so that it can be pickled however. Did I get what you're saying right, and do you understand what I'm getting at? Bill -----Original Message----- From: Fredrik Lundh [mailto:effbot@telia.com] Sent: Thursday, July 27, 2000 8:35 AM To: Bill Tutt Cc: python-dev@python.org Subject: Re: [Python-Dev] UTF-16 code point comparison This message uses a character set that is not supported by the Internet Service. To view the original message content, open the attached message. If the text doesn't display correctly, save the attachment to disk, and then open it using a viewer that can display the original character set. << File: message.txt >> From billtut@microsoft.com Thu Jul 27 19:29:34 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 11:29:34 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD344@RED-MSG-50> > From: bckfnn@worldonline.dk [mailto:bckfnn@worldonline.dk] > - The BreakIterator does not handle surrogates. It does handle > combining characters and it seems a natural place to put support > for surrogates. > - The Collator class offers different levels of normalization before > comparing string but does not seem to support surrogates. This class > seems a natural place for javasoft to put support for surrogates > during string comparison. Both of these aren't surprising given that there aren't any officially allocated characters in surrogate land (but they're coming fast), and the most likely first allocations are to the combined CJK glyph space which doesn't really have anything to collate. :) Bill From tim_one@email.msn.com Thu Jul 27 19:36:23 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 14:36:23 -0400 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33C@RED-MSG-50> Message-ID: [Guido] >> Why? Because I don't want to proliferate code that explicitly traps >> 0xD800-0xDFFF throughout the code. [Bill Tutt] > Err... I don't think you have much choice in the long term. When the Unicode push started, it was agreed that we would ignore surrogates "for now". I sounded a caution then that I will repeat: the Unicode folks made a bad engineering decision, based on the (Eurocentric) assumption that 64K was a large enough space to meet their stated goals. Don't know how long it will take this half of the world to realize it, but UCS-4 is inevitable. From tim_one@email.msn.com Thu Jul 27 19:41:15 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 14:41:15 -0400 Subject: [Python-Dev] more unicode: \U support? In-Reply-To: <012f01bff7e2$e0443820$f2a6b5d4@hagrid> Message-ID: [/F] > would it be a good idea to add \UXXXXXXXX > (8 hex digits) to 2.0? > > (only characters in the 0000-ffff range would > be accepted in the current version, of course). In which case there seems darned little point to it now . From guido@beopen.com Thu Jul 27 20:44:42 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 14:44:42 -0500 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: Your message of "Thu, 27 Jul 2000 14:36:23 -0400." References: Message-ID: <200007271944.OAA29768@cj20424-a.reston1.va.home.com> > When the Unicode push started, it was agreed that we would ignore surrogates > "for now". I sounded a caution then that I will repeat: the Unicode folks > made a bad engineering decision, based on the (Eurocentric) assumption that > 64K was a large enough space to meet their stated goals. Don't know how > long it will take this half of the world to realize it, but UCS-4 is > inevitable. If we can put it off long enough until RAM and disk space have become twice as cheap, I'm happy. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From billtut@microsoft.com Thu Jul 27 19:52:04 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 11:52:04 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD345@RED-MSG-50> > From: Tim Peters [mailto:tim_one@email.msn.com] > When the Unicode push started, it was agreed that we would ignore surrogates > "for now". I sounded a caution then that I will repeat: the Unicode folks > made a bad engineering decision, based on the (Eurocentric) assumption that > 64K was a large enough space to meet their stated goals. Don't know how > long it will take this half of the world to realize it, but UCS-4 is > inevitable. On new systems perhaps, but important existing systems (Win32, and probably Java) are stuck with that bad decision and have to use UTF-16 for backward compatability purposes. Surrogates aren't as far out as you might think. (The next rev of the Unicode spec) That's certainly sooner than Win32 going away. :) Bill From Fredrik Lundh" Message-ID: <021d01bff7fd$8258afa0$f2a6b5d4@hagrid> fred wrote: > Remove the ugly form-feed characters some people use with Emacs. note that those "ugly" form-feeds become nice
and

in the HTML versions... From Fredrik Lundh" Message-ID: <021e01bff7fd$93c34de0$f2a6b5d4@hagrid> tim wrote: > [/F] > > would it be a good idea to add \UXXXXXXXX > > (8 hex digits) to 2.0? > > > > (only characters in the 0000-ffff range would > > be accepted in the current version, of course). >=20 > In which case there seems darned little point to it now . with Python's approach to escape codes, it's not exactly easy to *add* a new escape code -- you risk breaking code that for some reason (intentional or not) relies on u"\U12345678" to end up as a backslash followed by 9 characters... not very likely, but I've seen stranger things... (btw, can you walk over to Guido's office and tell him why \x should ignore anything but the last two hex digits, no matter what string type we're using...) From bwarsaw@beopen.com Thu Jul 27 20:24:38 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 27 Jul 2000 15:24:38 -0400 (EDT) Subject: [Python-Dev] PEP 201, zip() builtin Message-ID: <14720.35958.632383.574511@anthem.concentric.net> Folks, Here is the latest PEP 201, updated based on conversations with Guido yesterday. Notice that there are no more Open Issues. See instead the BDFL Pronouncements section. Plan on seeing a C-based implementation checked into the CVS devel tree soon. If you want to comment on this PEP, you must include "PEP 201" in the Subject: header. Enjoy, -Barry -------------------- snip snip -------------------- PEP: 201 Title: Parallel Iteration Version: $Revision: 1.10 $ Author: bwarsaw@beopen.com (Barry A. Warsaw) Python-Version: 2.0 Status: Draft Created: 13-Jul-2000 Post-History: 27-Jul-2000 Introduction This PEP describes the `parallel iteration' proposal for Python 2.0, previously known as `parallel for loops'. This PEP tracks the status and ownership of this feature, slated for introduction in Python 2.0. It contains a description of the feature and outlines changes necessary to support the feature. This PEP summarizes discussions held in mailing list forums, and provides URLs for further information, where appropriate. The CVS revision history of this file contains the definitive historical record. Motivation Standard for-loops in Python iterate over every element in a sequence until the sequence is exhausted[1]. However, for-loops iterate over only a single sequence, and it is often desirable to loop over more than one sequence, in a lock-step, "Chinese Menu" type of way. The common idioms used to accomplish this are unintuitive and inflexible. This PEP proposes a standard way of performing such iterations by introducing a new builtin function called `zip'. Parallel For-Loops Parallel for-loops are non-nested iterations over two or more sequences, such that at each pass through the loop, one element from each sequence is taken to compose the target. This behavior can already be accomplished in Python through the use of the map() built-in function: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> for i in map(None, a, b): print i ... (1, 4) (2, 5) (3, 6) >>> map(None, a, b) [(1, 4), (2, 5), (3, 6)] The for-loop simply iterates over this list as normal. While the map() idiom is a common one in Python, it has several disadvantages: - It is non-obvious to programmers without a functional programming background. - The use of the magic `None' first argument is non-obvious. - It has arbitrary, often unintended, and inflexible semantics when the lists are not of the same length: the shorter sequences are padded with `None'. >>> c = (4, 5, 6, 7) >>> map(None, a, c) [(1, 4), (2, 5), (3, 6), (None, 7)] For these reasons, several proposals were floated in the Python 2.0 beta time frame for providing a better spelling of parallel for-loops. The initial proposals centered around syntactic changes to the for statement, but conflicts and problems with the syntax were unresolvable, especially when parallel for-loops were combined with another proposed feature called `list comprehensions' (see pep-0202.txt). The Proposed Solution The proposed solution is to introduce a new built-in sequence generator function, available in the __builtin__ module. This function is to be called `zip' and has the following signature: zip(seqa, [seqb, [...]]) zip() takes one or more sequences and weaves their elements together, just as map(None, ...) does with sequences of equal length. The weaving stops when the shortest sequence is exhausted. Return Value zip() returns a real Python list, the same way map() does. Examples Here are some examples, based on the reference implementation below. >>> a = (1, 2, 3, 4) >>> b = (5, 6, 7, 8) >>> c = (9, 10, 11) >>> d = (12, 13) >>> zip(a, b) [(1, 5), (2, 6), (3, 7), (4, 8)] >>> zip(a, d) [(1, 12), (2, 13)] >>> zip(a, b, c, d) [(1, 5, 9, 12), (2, 6, 10, 13)] Note that when the sequences are of the same length, zip() is reversible: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> x = zip(a, b) >>> y = zip(*x) # alternatively, apply(zip, x) >>> z = zip(*y) # alternatively, apply(zip, y) >>> x [(1, 4), (2, 5), (3, 6)] >>> y [(1, 2, 3), (4, 5, 6)] >>> z [(1, 4), (2, 5), (3, 6)] >>> x == z 1 It is not possible to reverse zip this way when the sequences are not all the same length. Reference Implementation Here is a reference implementation, in Python of the zip() built-in function. These would ultimately be replaced by equivalent C code. def zip(*args): if not args: raise TypeError('zip() expects one or more sequence arguments') ret = [] # find the length of the shortest sequence shortest = min(*map(len, args)) for i in range(shortest): item = [] for s in args: item.append(s[i]) ret.append(tuple(item)) return ret BDFL Pronouncements Note: the BDFL refers to Guido van Rossum, Python's Benevolent Dictator For Life. - The function's name. An earlier version of this PEP included an open issue listing 20+ proposed alternative names to zip(). In the face of no overwhelmingly better choice, the BDFL strongly prefers zip() due to it's Haskell[2] heritage. See version 1.7 of this PEP for the list of alteratives. - zip() shall be a built-in function. - Optional padding. An earlier version of this PEP proposed an optional `pad' keyword argument, which would be used when the argument sequences were not the same length. This is similar behavior to the map(None, ...) semantics except that the user would be able to specify pad object. This has been rejected by the BDFL in favor of always truncating to the shortest sequence. - Lazy evaluation. An earlier version of this PEP proposed that zip() return a built-in object that performed lazy evaluation using __getitem__() protocol. This has been strongly rejected by the BDFL in favor of returning a real Python list. If lazy evaluation is desired in the future, the BDFL suggests an xzip() function be added. - zip() with no arguments. the BDFL strongly prefers this raise a TypeError exception. - zip() with one argument. the BDFL strongly prefers that this return a list of 1-tuples. - Inner and outer container control. An earlier version of this PEP contains a rather lengthy discussion on a feature that some people wanted, namely the ability to control what the inner and outer container types were (they are tuples and list respectively in this version of the PEP). Given the simplified API and implementation, this elaboration is rejected. For a more detailed analysis, see version 1.7 of this PEP. References [1] http://www.python.org/doc/current/ref/for.html [2] http://www.haskell.org/onlinereport/standard-prelude.html#$vzip TBD: URL to python-dev archives Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: From fdrake@beopen.com Thu Jul 27 20:23:27 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 27 Jul 2000 15:23:27 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0160.txt,1.3,1.4 In-Reply-To: <021d01bff7fd$8258afa0$f2a6b5d4@hagrid> References: <200007271846.LAA27298@slayer.i.sourceforge.net> <021d01bff7fd$8258afa0$f2a6b5d4@hagrid> Message-ID: <14720.35887.525712.225755@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > note that those "ugly" form-feeds become nice
and

> in the HTML versions... They are no longer needed for that. I tossed the
because I thought it was ugly and distracting, but that can be changed if people prefer to have them. The

for headings is there. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nascheme@enme.ucalgary.ca Thu Jul 27 20:23:22 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 27 Jul 2000 13:23:22 -0600 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: ; from Tim Peters on Thu, Jul 27, 2000 at 02:20:26PM -0400 References: <20000727075058.A25450@keymaster.enme.ucalgary.ca> Message-ID: <20000727132322.A27400@keymaster.enme.ucalgary.ca> On Thu, Jul 27, 2000 at 02:20:26PM -0400, Tim Peters wrote: > [Neil Schemenauer] > > Here is some code that seems to hang on Linux UP machines. > > Sometimes it prints PIDS for a while and other times it stops > > after only a few. > > Well, that sucks! Does "UP" mean uniprocessor in this context? Yes. Neil From bwarsaw@beopen.com Thu Jul 27 20:27:43 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 27 Jul 2000 15:27:43 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0160.txt,1.3,1.4 References: <200007271846.LAA27298@slayer.i.sourceforge.net> <021d01bff7fd$8258afa0$f2a6b5d4@hagrid> Message-ID: <14720.36143.764784.551163@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: >> Remove the ugly form-feed characters some people use with >> Emacs. | note that those "ugly" form-feeds become nice
and

| in the HTML versions... This was a compromise between Jeremy and I (PEP 1 co-authors). No form-feeds, but section headers start in column 0 while the bodies start indented 4 spaces. -Barry From tim_one@email.msn.com Thu Jul 27 20:26:03 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 15:26:03 -0400 Subject: [Python-Dev] more unicode: \U support? In-Reply-To: <021e01bff7fd$93c34de0$f2a6b5d4@hagrid> Message-ID: [/F] > would it be a good idea to add \UXXXXXXXX > (8 hex digits) to 2.0? > > (only characters in the 0000-ffff range would > be accepted in the current version, of course). [Tim] > In which case there seems darned little point to it now . [/F] > with Python's approach to escape codes, it's not exactly easy > to *add* a new escape code -- you risk breaking code that for > some reason (intentional or not) relies on u"\U12345678" to end > up as a backslash followed by 9 characters... > > not very likely, but I've seen stranger things... Ah! You're right, I'm wrong. +1 on \U12345678 now. > (btw, can you walk over to Guido's office and tell him why \x > should ignore anything but the last two hex digits, no matter > what string type we're using...) No, but I can mail to his office, and am doing so. Guido, are you opposing us on this? If so, it would save time if you explained just the specific point you're wrong about . From esr@thyrsus.com Thu Jul 27 20:56:03 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jul 2000 15:56:03 -0400 Subject: [Python-Dev] PEP 201 In-Reply-To: <14720.35958.632383.574511@anthem.concentric.net>; from bwarsaw@beopen.com on Thu, Jul 27, 2000 at 03:24:38PM -0400 References: <14720.35958.632383.574511@anthem.concentric.net> Message-ID: <20000727155603.D9683@thyrsus.com> Barry A. Warsaw : > Here is the latest PEP 201, updated based on conversations with Guido > yesterday. Notice that there are no more Open Issues. Excellent. I have no remaining issues or hesitations about this PEP and am happy to see it resolved. Three cheers for Guido and everybody else who worked hard to make this fly! -- Eric S. Raymond The right to buy weapons is the right to be free. -- A.E. Van Vogt, "The Weapon Shops Of Isher", ASF December 1942 From tim_one@email.msn.com Thu Jul 27 20:45:47 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 15:45:47 -0400 Subject: [Python-Dev] PEP 201, zip() builtin In-Reply-To: <14720.35958.632383.574511@anthem.concentric.net> Message-ID: [Barry A. Warsaw] > -------------------- snip snip -------------------- > PEP: 201 > Title: Parallel Iteration Could we please change "Parallel" to, e.g., "Lockstep" throughout? Greg Wilson correctly pointed out that "parallel" in the context of loops means something very different to the scientific branch of the Python community. Easier to fix this now that after it's spread to the docs. > ... > However, for-loops iterate over only a single sequence, and it > is often desirable to loop over more than one sequence, in a > lock-step, "Chinese Menu" type of way. Just as you realized how inappropriate "parallel" was right here . > # find the length of the shortest sequence > shortest = min(*map(len, args)) Clearer as > shortest = min(map(len, args)) However, this implies that all sequences must tell the truth about their lengths, but the iteration protocol actually terminates via a sequence raising IndexError. I believe we want zip to follow the iteration protocol, in effect breaking out of the outer loop as soon as some s[i] raises IndexError. This was agreed to by all (incl. the BDFL) in some other year's debates over this. > prefers zip() due to it's Haskell[2] heritage. See version 1.7 "its", not "it's" > - Lazy evaluation. An earlier version of this PEP proposed that > zip() return a built-in object that performed lazy evaluation > using __getitem__() protocol. This has been strongly rejected > by the BDFL in favor of returning a real Python list. If lazy > evaluation is desired in the future, the BDFL suggests an xzip() > function be added. Which he'll then fight tooth and nail . > ... Nice job, Barry! Thank you. From guido@beopen.com Thu Jul 27 21:49:01 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 15:49:01 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 10:10:51 MST." References: Message-ID: <200007272049.PAA30143@cj20424-a.reston1.va.home.com> [Guido] > > Second, what should happen to a slice assignment? [Ping] > My vote is: nothing! (Read on.) > > > The basic slice form is: > > > > a[i:j] += b > > What does this mean? I don't see how it could be any different from: > > a[j:j] = b Apparently you haven't used NumPy arrays (matrices). I haven't either, but I hear they overload + so that A+B is elementwise addition, and you can write A+1 to add 1 to each element of A. Thus, for a NumPy programmer, A += 1 would certainly look like A = A+1, and similar for A += B. > It looks to me like going through various contortions to support > augmented assignment to slices is not going to be worth the trouble. > > May i suggest > > >>> a[i:j] += b > SyntaxError: augmented assignment to a slice is not allowed That's what I thought too until I realized that for NumPy arrays slice+= makes sense. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Vladimir.Marangozov@inrialpes.fr Thu Jul 27 20:55:06 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 27 Jul 2000 21:55:06 +0200 (CEST) Subject: [Python-Dev] PEP 201, zip() builtin In-Reply-To: <14720.35958.632383.574511@anthem.concentric.net> from "Barry A. Warsaw" at Jul 27, 2000 03:24:38 PM Message-ID: <200007271955.VAA03850@python.inrialpes.fr> Barry A. Warsaw wrote: > > > Folks, > > Here is the latest PEP 201, updated based on conversations with Guido > yesterday. Notice that there are no more Open Issues. See instead > the BDFL Pronouncements section. Plan on seeing a C-based > implementation checked into the CVS devel tree soon. > > If you want to comment on this PEP, you must include "PEP 201" in the > Subject: header. Yes! I have a comment: "Long live BDFL!!!" Happy to see the 1st PEP closed! moving-forward'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas@xs4all.net Thu Jul 27 21:05:08 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 22:05:08 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271730.MAA21788@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 12:30:51PM -0500 References: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> <20000727182248.V266@xs4all.nl> <200007271730.MAA21788@cj20424-a.reston1.va.home.com> Message-ID: <20000727220508.C224@xs4all.nl> On Thu, Jul 27, 2000 at 12:30:51PM -0500, Guido van Rossum wrote: > > Actually, it wasn't the feebleness as much as the two different things you > > seem to be wanting, Guido ;) Previously (in another thread, and perhaps in > > the start of this thread as well) you argued that an index should always > > call __getitem__, with a slice object if it's a slice of some kind, *even a > > basic one*. So that we lose __getslice__ and rather teach people to use > > __getslice__. > That would be nice, but it would be b/w incompatible, so now we're > trying (again) to figure out how to still support __getslice__. My > proposal is to try and be b/w compatible if __getslice__ exists. See > my previous mail. Yes. So what we're talking about is a better way to do indexing all together, all types in one shot. ('indexes', 'slices' and 'collections' ? I'm not sure how to name the first and the last one, if not that.) And not just indexing, but setting and deleting at the same time, right ? So the most preferred way is to pass a single argument which is either: - A single object (directly what was passed in) for a single index. - A slice-object if any kind of single-slice was passed in, which holds the zero-to-three objects that the slice was 'created' with. - A tuple of zero or more of either of the above two. While I'm writing this down, I'm not sure if it's such a good idea. Isn't this placing a tad too much into one function ? It might require some severe logic to support this all, especially if you give 'special' meanings to some indexes. And we're inserting a new catch-all method -- a set of them, actually: get, set and del -- and that while Paul is trying to solve the other catch-all Python has, __getattr__/__setattr__. Then again, the use of this method is quite different from __getattr__/__setattr__... Most classes will commit to either a sequence-type or a mapping-type, and not even bother with extended slices or tuple-indexes. And lets not forget the convenience of writing those methods: __getitem__ is intuitive, both in name and semantics. So is __getslice__. The passing of a slice object to __getitem__ is a tad less intuitive, and a tuple of index/slice objects even less. I'm tempted to suggest a single change: when __getslice__ is not defined, pass a slice object (with no step, as if the slice had a trailing ':') to __getitem__, and document it properly. (and make builtin objects accept sliceobjects too !) Perhaps try to slowly deprecate getslice__. Give plenty __of examples of using __getitem__ and slice objects in the standard documentation. Also, I think it makes sense to make slice objects indexable, so that you can do: start, end, step = sliceobj instead of the less intuitive start, end, step = sliceobj.start, sliceobj.end, sliceobj.step But I've never used slice objects myself, so I can't really say whether it's a good idea. I suspect this is all for 2.1 or later, though. (As for what ?!ng suggested, the variable-args __hooks__, I don't see a difference between __getitem__(self, *val) and __getitem__(self, val) where val is a tuple. The same reasoning stands.) > > So now you want to *extend* the 'special case' to extended, 3-argument > > slices, but *not* Ellipses and tupled-slices (which aren't really tuples, > > because you can do (1, 2:5, ...)) -- or am I reading this wrong ? :) > > Not sure what you mean by that. (1, 2:5, ...) by itself is illegal > syntax; the special slice syntax can only occur directly in an > indexing context, e.g. a[1, 2:5, ...]. Exactly my point ;P Ferget it, not important. What I was trying to say was that: x[1, 2, 4:10:2] isn't the same as x[(1, 2, 4:10:2)] So the first isn't really indexing with a tuple -- because you can't do the 2nd. But the result as passed to __getitem__ *is* a tuple, so forget what I said ;) > > Don't worry, Guido, it isn't just you, I failed to grasp what those managers > > were trying to tell me today, too... I may just be too dense, today. > I hope they weren't telling you to stop working on Python! You seem > made for this work... Heh, nono, they don't have any say over what I do with Python. I'd force them to join the Python Consortium before I'd let them have any say over that ;) I don't do any *work* with Python, other than waiting for Barry to bring Mailman 2.0 out of beta so we can start a 'product line' on that, instead of Majordomo. It has nothing to do with Python but everything with my colleagues ;-) In fact, the only people who even know what Python is are my direct colleagues, my co-System-administrators, one of which is my direct boss. I didn't even see those people today, because half the meetings today and yesterday were with a bunch of product developers and the senior VP of technology (that's his translated title), and the other half was with the workers council, the management team and the CEO (sort of) of the company. And besides, even if they did try to tell me to stop with Python, it would go like the first episode of Red Dwarf, where Lister comes out of stasis and Holly, the shipboard computer, tries to tell him everyone's dead and he's been in stasis for 3 million years. "So where is everyone, Hol ?" "They're dead, Dave." "Who, the captain ?" "Everyone, Dave." "What, Petersen ?" "Yes, Dave. Everyone. Everyone is dead." "Not Kochansky!" "Yes, Dave. Everyone is dead. Dead is everyone. Is everyone dead. Dead everyone is." "Wait. What are you trying to tell me here, Hol ?" "You have to quit with Python, even in your free time." "What are you trying to tell me ?" ... And if that failed, I'd quit. I don't work here to get dictated how to do my work, and I certainly don't work here to get dictated how to live my life *outside* of work. I realize that's how PythonLabs operates but it's not how we run things in the old country, Guido ! :) No, all work I did and am doing on and with Python was hobby work. Which is just fine with me, for the moment, because it means I can slow down the pace whenever I want to. (Not that I've had that urge yet.) Can't-imagine-working-full-time-on-or-with-Python---two-week-bliss!- -seven-week-burnout-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Thu Jul 27 21:12:42 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 22:12:42 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: ; from ping@lfw.org on Thu, Jul 27, 2000 at 10:10:51AM -0700 References: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> Message-ID: <20000727221242.W266@xs4all.nl> On Thu, Jul 27, 2000 at 10:10:51AM -0700, Ka-Ping Yee wrote: > On Thu, 27 Jul 2000, Guido van Rossum wrote: > > The basic slice form is: > > > > a[i:j] += b > What does this mean? I don't see how it could be any different from: > a[j:j] = b a[i:j] += b means exactly the same as: a[i:j] = a[i:j] + b Whether it does anything other than raising an exception depends entirely on the types of a and b ! > I can't even imagine what the simpler case > a[i:j:k] += 1 > would do... unless you wish to propose element-wise operators (e.g. > add 1 to each of the elements that would participate in the slice) That's entirely user-defined. Augmented assignment simply extends Pythons extremely liberal (my cultural heritage tempts me to say 'communist';) semantics in these cases. a[i:j:k] += 1 is exactly a[i:j:k] = a[i:j:k] + 1 If 'a' is a Python class, this would turn into (forgetting about order of evaluation, for a second): a.__setitem__(slice(i, j, k), a[slice(i, j, k)].__add_ab__(1)) > It looks to me like going through various contortions to support > augmented assignment to slices is not going to be worth the trouble. > May i suggest > >>> a[i:j] += b > SyntaxError: augmented assignment to a slice is not allowed Sure, but it doesn't make sense unless 'a[i:j] = a[i:j] + b' raises similar problems. Why this arbitrary border ? Because you can't imagine people wanting it ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Thu Jul 27 21:22:09 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 22:22:09 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <398065f3.6724599@smtp.worldonline.dk> Message-ID: <398099F1.B6B1D281@lemburg.com> Finn Bock wrote: > > [M.-A. Lemburg] > > >BTW, does Java support UCS-4 ? If not, then Java is wrong > >here ;-) > > Java claims to use unicode 2.1 [*]. I couldn't locate anything describing if > this is UCS-2 or UTF-16. I think unicode 2.1 includes UCS-4. The actual > level of support for UCS-4 is properly debatable. > > - The builtin char is 16bit wide and can obviously not support UCS-4. > - The Character class can report if a character is a surrogate: > >>> from java.lang import Character > >>> Character.getType("\ud800") == Character.SURROGATE > 1 >>> unicodedata.category(u'\ud800') 'Cs' ... which means the same thing only in Unicode3 standards notation. Make me think: perhaps we should add the Java constants to unicodedata base. Is there a list of those available somewhere ? > - As reported, direct string comparison ignore surrogates. I would guess that this'll have to change as soon as JavaSoft folks realize that they need to handle UTF-16 and not only UCS-2. > - The BreakIterator does not handle surrogates. It does handle > combining characters and it seems a natural place to put support > for surrogates. What is a BreakIterator ? An iterator to scan line/word breaks ? > - The Collator class offers different levels of normalization before > comparing string but does not seem to support surrogates. This class > seems a natural place for javasoft to put support for surrogates > during string comparison. We'll need something like this for 2.1 too: first some standard APIs for normalization and then a few unicmp() APIs to use for sorting. We might even have to add collation sequences somewhere because this is a locale issue as well... sometimes it's even worse with different strategies used for different tasks within one locale, e.g. in Germany we sometimes sort the Umlaut ä as "ae" and at other times as extra character. > These findings are gleaned from the sources of JDK1.3 > > [*] > http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#25310 > Thanks for the infos, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Thu Jul 27 21:23:49 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 22:23:49 +0200 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <200007271944.OAA29768@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 02:44:42PM -0500 References: <200007271944.OAA29768@cj20424-a.reston1.va.home.com> Message-ID: <20000727222349.X266@xs4all.nl> On Thu, Jul 27, 2000 at 02:44:42PM -0500, Guido van Rossum wrote: > > When the Unicode push started, it was agreed that we would ignore surrogates > > "for now". I sounded a caution then that I will repeat: the Unicode folks > > made a bad engineering decision, based on the (Eurocentric) assumption that > > 64K was a large enough space to meet their stated goals. Don't know how > > long it will take this half of the world to realize it, but UCS-4 is > > inevitable. > If we can put it off long enough until RAM and disk space have become > twice as cheap, I'm happy. I think 'speed' is more of an issue than 'price'. (price lowers much faster than speed rises.) However, I have to admit I've been lagging behind on the latest technologies, RAM-bus or SCRAM-jet or whatever they were called, which is supposed to allow a 1Ghz or thereabouts bus-architecture. (Which doesn't make RAM that speed, yet, but at least it evades the current bus bottleneck ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Thu Jul 27 21:29:59 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 22:29:59 +0200 Subject: [Python-Dev] more unicode: \U support? References: Message-ID: <39809BC7.FD8E9C35@lemburg.com> Tim Peters wrote: > > [/F] > > would it be a good idea to add \UXXXXXXXX > > (8 hex digits) to 2.0? > > > > (only characters in the 0000-ffff range would > > be accepted in the current version, of course). I don't really get the point of adding \uXXXXXXXX when the internal format used is UTF-16 with support for surrogates. What should \u12341234 map to in a future implementation ? Two Python (UTF-16) Unicode characters ? > [Tim] > > In which case there seems darned little point to it now . > > [/F] > > with Python's approach to escape codes, it's not exactly easy > > to *add* a new escape code -- you risk breaking code that for > > some reason (intentional or not) relies on u"\U12345678" to end > > up as a backslash followed by 9 characters... > > > > not very likely, but I've seen stranger things... > > Ah! You're right, I'm wrong. +1 on \U12345678 now. See http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#100850 for how Java defines \uXXXX... We're following an industry standard here ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut@microsoft.com Thu Jul 27 21:35:11 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 13:35:11 -0700 Subject: [Python-Dev] more unicode: \U support? Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD347@RED-MSG-50> Actually, it'd be \U10FFFF, no need for 8 digits. Java doesn't support surrogates yet, so what Java does for \u doesn't make any difference. :) \U10FFFF should expand to either one character in UCS-4, or two characters in UTF-16/UCS-2. No particular reason why it can't work for 2.0. This is similar to the UTF-8 issue wrt surrogates. Bill From mwh21@cam.ac.uk Thu Jul 27 21:41:02 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 27 Jul 2000 21:41:02 +0100 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Guido van Rossum's message of "Thu, 27 Jul 2000 09:12:58 -0500" References: <200007271412.JAA12251@cj20424-a.reston1.va.home.com> Message-ID: Guido van Rossum writes: > > Good idea. Are lists and tuples going to support seq[a:b:c] anytime soon? > > It's on my wish list, but can't be done for 2.0. This would involve the list type implementing the mapping API wouldn't it? This would seem to be a little on the silly side. Never mind; here's a quick-hack patch that "seems to work" for lists: Index: listobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/listobject.c,v retrieving revision 2.83 diff -u -c -r2.83 listobject.c *** listobject.c 2000/07/25 12:56:38 2.83 --- listobject.c 2000/07/27 20:38:50 *************** *** 1400,1405 **** --- 1400,1441 ---- (objobjproc)list_contains, /*sq_contains*/ }; + static PyObject* + list_subscript(PyObject* list, PyObject* item) + { + if (PyInt_Check(item)) { + return list_item((PyListObject*)list,PyInt_AS_LONG(item)); + } else if (PySlice_Check(item)) { + int start, stop, step, cur, i; + PyObject* result; + PyObject* it; + + if (PySlice_GetIndices((PySliceObject*)item,PyList_Size(list),&start,&stop,&step) < 0) { + PyErr_SetString(PyExc_TypeError, "slice indices must be integers"); + return NULL; + } + + result = PyList_New((stop-start)/step+1); + + for (cur = start, i = 0; cur < stop; cur += step, i++) { + it = PyList_GET_ITEM(list,cur); + Py_INCREF(it); + PyList_SET_ITEM(result,i,it); + } + + return result; + } else { + PyErr_SetString(PyExc_TypeError, "list indices must be integers"); + return NULL; + } + }; + + static PyMappingMethods list_as_mapping = { + (inquiry)list_length, + (binaryfunc)list_subscript, + (objobjargproc)NULL + }; + PyTypeObject PyList_Type = { PyObject_HEAD_INIT(&PyType_Type) 0, *************** *** 1414,1420 **** (reprfunc)list_repr, /*tp_repr*/ 0, /*tp_as_number*/ &list_as_sequence, /*tp_as_sequence*/ ! 0, /*tp_as_mapping*/ 0, /*tp_hash*/ 0, /*tp_call*/ 0, /*tp_str*/ --- 1450,1456 ---- (reprfunc)list_repr, /*tp_repr*/ 0, /*tp_as_number*/ &list_as_sequence, /*tp_as_sequence*/ ! &list_as_mapping, /*tp_as_mapping*/ 0, /*tp_hash*/ 0, /*tp_call*/ 0, /*tp_str*/ Have I missed anything obvious? I'd upload it to SF, but I don't really want something I've put such little effort into to be seriously considered... Cheers, M. -- 112. Computer Science is embarrassed by the computer. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html From tim_one@email.msn.com Thu Jul 27 21:57:58 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 16:57:58 -0400 Subject: [Python-Dev] more unicode: \U support? In-Reply-To: <39809BC7.FD8E9C35@lemburg.com> Message-ID: [/F] > would it be a good idea to add \UXXXXXXXX > (8 hex digits) to 2.0? > > (only characters in the 0000-ffff range would > be accepted in the current version, of course). [Tim agreed two msgs later; Guido agreed in private] [MAL] > I don't really get the point of adding \uXXXXXXXX No: Fredrik's suggestion is with an uppercase U. He is not proposing to extend the (lowercase) \u1234 notation. > when the internal format used is UTF-16 with support for surrogates. > > What should \u12341234 map to in a future implementation ? > Two Python (UTF-16) Unicode characters ? \U12345678 is C99's ISO 10646 notation; as such, it can't always be mapped to UTF-16. > See > > http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc .html#100850 > > for how Java defines \uXXXX... Which I pushed for from the start, and nobody is seeking to change. > We're following an industry standard here ;-) \U12345678 is also an industry standard, but in a more recent language (than Java) that had more time to consider the eventual implications of Unicode's limitations. We reserve the notation now so that it's possible to outgrow Unicode later. From tim_one@email.msn.com Thu Jul 27 22:01:39 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 17:01:39 -0400 Subject: [Python-Dev] more unicode: \U support? In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD347@RED-MSG-50> Message-ID: [Bill Tutt] > Actually, it'd be \U10FFFF, no need for 8 digits. Nope, \U is taken from the new C standard, and requires exactly 8 hex digits. It's a notation for ISO 10646, not for Unicode. > Java doesn't support surrogates yet, so what Java does for \u doesn't > make any difference. :) \u in Python was meant to mimic Java exactly, if for nothing else then for the sake of JPython. From esr@thyrsus.com Thu Jul 27 22:38:59 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jul 2000 17:38:59 -0400 Subject: [Python-Dev] Request for guidance on documentation Message-ID: <20000727173859.A10337@thyrsus.com> I have now made two passes through the docs for the new curses module, correcting minor errors and adding explanatory material. The question is what to do next, and that turns on whether discursive tutorial sections are are considered fit for inclusion in the library reference. If they are, I'll rewrite the existing curses HOWTO and slide it in there, perhaps adding some stuff from the "Introduction to ncurses" HTML tutorial I wrote lo those many moons ago for the ncurses distribution. Can anybody point me at the TeX source for the curses HOWTO? Also, I'm not sure where the material for curses.textbox should go. New section? Or a subsection in the curses document? -- Eric S. Raymond 'Faith' means not _wanting_ to know what is true. -- Nietzsche, Der Antichrist From trentm@ActiveState.com Thu Jul 27 23:00:56 2000 From: trentm@ActiveState.com (Trent Mick) Date: Thu, 27 Jul 2000 15:00:56 -0700 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: References: <14719.49496.935765.730596@anthem.concentric.net> Message-ID: <20000727150056.B26555@ActiveState.com> On Thu, Jul 27, 2000 at 01:17:03AM -0400, Tim Peters wrote: > In parallel, could someone summarize the symptoms? Exactly how does it > fail? Does it fail the same way across all platforms on which it does fail? > Does it fail every time on all platforms on which it fails, or fail only > some of the time on all platforms on which it fails, or fails some of the > time on some of the platforms on which it fails but fails all of the time on > the rest of the platforms on which it fails ? > > If there exists a platform on which it fails but it doesn't fail every time > on that platform, that would be strong evidence of a timing hole. Those > usually require thought to identify and repair. I'll voluteer to > eyeball the code and do some thinking, but not unless the symptoms suggest > that's worthwhile. > > ignorantly y'rs - tim Here is what I have found: Machine: [trentm@molotok ~/main/contrib/python.build/dist/src]$ cat /proc/version Linux version 2.2.12-20smp (root@porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Mon Sep 27 10:34:45 EDT 1999 Note that this is an SMP machine. General symptoms: test_fork1 did *not* fail for me all the time. In fact it seemed, in this run of testing, to pass fine a number of time in a row and then some magical switch flipped and now it fails every time. I don't know what the 'switch' case is, nor do I know how to flip it on and off. This failing everytime is modulo debugging print statements that I have put in test_fork1.py. This indicates that it is a timing issue. Instumented test_fork1.py: -------------------------------------------------------------------------- import os, sys, time, thread try: os.fork except AttributeError: raise ImportError, "os.fork not defined -- skipping test_fork1" LONGSLEEP = 2 SHORTSLEEP = 0.5 NUM_THREADS = 4 alive = {} stop = 0 def f(id): while not stop: alive[id] = os.getpid() print 'thread %s: pid=%s' % (str(id), str(alive[id])) try: time.sleep(SHORTSLEEP) except IOError: pass def main(): print 'start main' for i in range(NUM_THREADS): thread.start_new(f, (i,)) print 'before sleep' time.sleep(LONGSLEEP) print 'after sleep (threads should be started now)' a = alive.keys() a.sort() assert a == range(NUM_THREADS) prefork_lives = alive.copy() print 'before fork' cpid = os.fork() print 'after fork' if cpid == 0: print 'child: start' # Child time.sleep(LONGSLEEP) n = 0 for key in alive.keys(): if alive[key] != prefork_lives[key]: n = n+1 print 'child: done, exit_value=%d' % n os._exit(n) else: print 'parent: start' # Parent spid, status = os.waitpid(cpid, 0) print 'parent: done waiting for child(pid=%d,status=%d)' %\ (spid, status) assert spid == cpid assert status == 0, "cause = %d, exit = %d" % (status&0xff, status>>8) global stop # Tell threads to die print 'parent: tell threads to die' stop = 1 time.sleep(2*SHORTSLEEP) # Wait for threads to die print 'parent: done (expect threads to be dead by now, hack)' main() -------------------------------------------------------------------------- A couple of test runs: *** This test run passed: [trentm@molotok ~/main/contrib/python.build/dist/src]$ ./python Lib/test/test_fork1.py start main before sleep thread 0: pid=26416 thread 1: pid=26417 thread 2: pid=26418 thread 3: pid=26419 thread 0: pid=26416 thread 1: pid=26417 thread 2: pid=26418 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 thread 3: pid=26419 thread 1: pid=26417 thread 0: pid=26416 after sleep (threads should be started now) before fork after fork thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 parent: start after fork child: start thread 0: pid=26416 thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 child: done, exit_value=0 parent: done waiting for child(pid=26420,status=0) parent: tell threads to die parent: done (expect threads to be dead by now, hack) *** This test run seg faulted but completed: [trentm@molotok ~/main/contrib/python.build/dist/src]$ ./python Lib/test/test_fork1.py start main before sleep thread 0: pid=26546 thread 1: pid=26547 thread 2: pid=26548 thread 3: pid=26549 thread 1: pid=26547 thread 3: pid=26549 thread 2: pid=26548 thread 0: pid=26546 thread 2: pid=26548 thread 0: pid=26546 thread 1: pid=26547 thread 3: pid=26549 thread 3: pid=26549 thread 1: pid=26547 thread 2: pid=26548 thread 0: pid=26546 after sleep (threads should be started now) before fork after fork parent: start after fork child: start Segmentation fault (core dumped) [trentm@molotok ~/main/contrib/python.build/dist/src]$ child: done, exit_value=0 [trentm@molotok ~/main/contrib/python.build/dist/src]$ *** This test hung on the last statement: [trentm@molotok ~/main/contrib/python.build/dist/src]$ ./python Lib/test/test_fork1.py start main before sleep thread 0: pid=26753 thread 1: pid=26754 thread 2: pid=26755 thread 3: pid=26756 thread 2: pid=26755 thread 3: pid=26756 thread 0: pid=26753 thread 1: pid=26754 thread 0: pid=26753 thread 2: pid=26755 thread 3: pid=26756 thread 1: pid=26754 thread 0: pid=26753 thread 3: pid=26756 thread 2: pid=26755 thread 1: pid=26754 after sleep (threads should be started now) before fork thread 0: pid=26753 after fork thread 2: pid=26755 parent: start thread 3: pid=26756 thread 1: pid=26754 after fork child: start thread 0: pid=26753 thread 3: pid=26756 thread 1: pid=26754 thread 2: pid=26755 thread 0: pid=26753 thread 3: pid=26756 thread 1: pid=26754 thread 2: pid=26755 thread 0: pid=26753 thread 3: pid=26756 thread 1: pid=26754 thread 2: pid=26755 thread 0: pid=26753 child: done, exit_value=0 parent: done waiting for child(pid=26757,status=0) Those are the only three run cases that I get. Trent -- Trent Mick TrentM@ActiveState.com From billtut@microsoft.com Thu Jul 27 23:25:01 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 15:25:01 -0700 Subject: [Python-Dev] more unicode: \U support? Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD34A@RED-MSG-50> [Tim stating that we need 8 digits to mimic C99's \U notation due to the ISO 10646 UCS-4 stuff.] Heh, I suppose. ISO has approved the following document for the next rev of 10646 though. "Proposal to restrict the range of code positions to the values up to U-0010FFFF": http://anubis.dkuug.dk/jtc1/sc2/wg2/docs/n2175.htm FYI, Bill From tim_one@email.msn.com Thu Jul 27 23:51:27 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 18:51:27 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <20000727150056.B26555@ActiveState.com> Message-ID: [Trent Mick, rallies to the cry for a summary of symptoms, which I'll summarize as On Linux version 2.2.12-20smp (root@porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP test_fork1 has one of three outcomes, varying across runs: 1. no problem 2. segfault 3. hang ] Thank you! In no case did the test fail on the particular thing it's *trying* to test: that after a fork, spawned threads don't show up in the child. So it's failing in unanticipated ways (when it does fail), and, to my eyes, ways that are very unlikely to be Python's fault. Everyone pursuing the other "fork bug" please note that test_fork1 doesn't import threading or use any mutexes -- it just spawns threads, forks once, and .sleeps() a lot. As with the other bug, would be interesting to recode test_fork1 in C and see whether it still segfaults and/or hangs. Should be easier to do for this test than the other one, since the *only* thread gimmick test_fork1 uses is thread.start_new(). We'll either discover that it still fails, in which case it's clearly not something Python caused and we'll have something pretty simple to pass on to the platform folks; or that it doesn't, in which case it's *really* interesting . Does anyone have test_fork1 failures on other flavors of SMP? From jeremy@beopen.com Fri Jul 28 00:08:33 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 27 Jul 2000 19:08:33 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: References: <20000727150056.B26555@ActiveState.com> Message-ID: <14720.49393.792630.426570@bitdiddle.concentric.net> >>>>> "TP" == Tim Peters writes: TP> unlikely to be Python's fault. Everyone pursuing the other TP> "fork bug" please note that test_fork1 doesn't import threading TP> or use any mutexes -- it just spawns threads, forks once, and TP> .sleeps() a lot. I don't think the "other" "fork bug" uses any more thread gimmicks than the bug you're considering. The test script that Neil posted did use the threading module, but it works just as well with the thread module. It only uses start_new_thread. The big difference between the two bugs is that the one Neil posted results in deadlock rather than a segfault. So they may well be completely different. For both bugs, though, a mutex and a condition variable are being use: The interpreter lock is being acquired and released in both cases. My current theory is that Python isn't dealing with the interpreter lock correctly across a fork. If some thread other than the one calling fork holds the interpreter lock mutex, the lock will be held forever in the child thread. If the child thread isn't making progress, the parent thread won't make progress either. Jeremy Here's a simplified test case: import os import thread def f(): while 1: if os.fork() == 0: print "%s %s" % (thread.get_ident(), os.getpid()) os._exit(0) os.wait() thread.start_new_thread(f, ()) thread.start_new_thread(f, ()) f() From trentm@ActiveState.com Fri Jul 28 00:17:47 2000 From: trentm@ActiveState.com (Trent Mick) Date: Thu, 27 Jul 2000 16:17:47 -0700 Subject: [Python-Dev] failures in the regression tests In-Reply-To: <14719.42838.895374.783407@bitdiddle.concentric.net> References: <14719.42838.895374.783407@bitdiddle.concentric.net> Message-ID: <20000727161747.A27222@ActiveState.com> On Wed, Jul 26, 2000 at 11:07:02PM -0400, Jeremy Hylton wrote: > I am trying to keep track of failures in the regression test suite. > At the moment, all the available tests work correctly on my Linux > box. I understand there are still problems with test_fork1 on some > SMP Linux boxes. (I believe this error has been around for many > months.) And that the test_winreg and test_winreg32 tests are failing > on Windows builds. > > If you are aware of any other tests that are failing, please let me > know. (Preferably by private email.) We need to get the tests fixed > quickly. As I write in PEP 200 (Python 2.0 release schedule): Configuration: WinNT 4.00.1381 IE 5.500.2314.1003 MSVC 6.0 Dual Xeon processors (500Mhz?) Python CVS as of this morning Failures: test_mmap test_winreg test_winreg2 test_popen2 *** test_mmap: C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\test_mmap.py Position of foo: 1.0 pages Length of file: 2.0 pages Contents of byte 0: '\000' Contents of first 3 bytes: '\000\000\000' Modifying file's content... Contents of byte 0: '3' Contents of first 3 bytes: '3\000\000' Contents of second page: foobar Regex match on mmap (page start, length of match): 1.0 6 Seek to zeroth byte Seek to 42nd byte Seek to last byte Try to seek to negative position... Try to seek beyond end of mmap... Try to seek to negative position... Attempting resize() Traceback (most recent call last): File "..\Lib\test\test_mmap.py", line 114, in ? test_both() File "..\Lib\test\test_mmap.py", line 100, in test_both m.resize( 512 ) WindowsError: [Errno 6] The handle is invalid Fredrik (Win65, MSVC 5.0) tells me he gets the same failure but with a different error code. *** test_popen2 C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\test_popen2.py testing popen2... Traceback (most recent call last): File "..\Lib\test\test_popen2.py", line 22, in ? main() File "..\Lib\test\test_popen2.py", line 20, in main popen2._test() File "C:\trentm\tmp\python\dist\src\lib\popen2.py", line 148, in _test assert r.read() == teststr AssertionError I haven't looked at this one. *** test_winreg C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\regrtest.py test_winreg test_winreg test test_winreg failed -- Unread: '\012' 1 test failed: test_winreg This is just failing because Lib/test/output/test_winreg has one blank line at the end that it should not. I am going to checkin a fix soon (if I can remember how, seeing as I let everyone else checkin all my previous patches :) *** test_winreg2 C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\regrtest.py test_winreg2 test_winreg2 test test_winreg2 failed -- Writing: ' ', expected: '' 1 test failed: test_winreg2 C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\test_winreg2.py Test Passed: testKeyDict_Values Test Passed: testKeyDict_Items Test Passed: testGetValueNames Test Passed: testSetDwordBigEndian Test Passed: testGetSubkeyNames Test Passed: testResourceRequirementsListType Test Passed: testLoad Test Passed: testDeleteKey Test Passed: testValueDict_Length Test Passed: testResourceDescriptionType Test Passed: testSetMultiSz Test Passed: testSetFullResourceDescription HKEY_CLASSES_ROOT HKEY_CURRENT_USER HKEY_LOCAL_MACHINE HKEY_USERS HKEY_CURRENT_CONFIG HKEY_DYN_DATA HKEY_PERFORMANCE_DATA Test Passed: testHives Test Passed: testDWordType Test Passed: testRemote Test Passed: testKeyDict_DelItem Test Failed: testSetIntValue Traceback (most recent call last): File "..\Lib\test\test_winreg2.py", line 297, in ? func() File "..\Lib\test\test_winreg2.py", line 178, in testSetIntValue key.deleteKey( "HKLM\\Software\\a\\b") AttributeError: 'RegKey' instance has no attribute 'deleteKey' Test Passed: testResourceLinkType Test Passed: testNoneType Test Passed: testValueDict_Map Test Passed: testSetResourceList Test Passed: testKeyDict_Length Test Passed: testKeyDict_ClearKeys Test Passed: testDWordBigEndianType Test Passed: testOpen Test Passed: testSetBinaryData Test Passed: testStringType Test Failed: testSetBinaryValue Traceback (most recent call last): File "..\Lib\test\test_winreg2.py", line 297, in ? func() File "..\Lib\test\test_winreg2.py", line 183, in testSetBinaryValue key.setValue( "abcd", array.array( 'c', "PPPPPPPPPPPPPPP") ) NameError: array Test Passed: testSetResourceRequirementsList Test Passed: testValueDict_Items Test Passed: testShortcuts Test Passed: testUnicodeValueName Test Passed: testGetValueDataFromEnum Test Passed: testValueDict_Get Test Passed: testValueDict_GetItem Test Passed: testValueDict_Keys Test Passed: testKeyDict_HasKey Test Passed: testExpandStringType Test Passed: testValueDict_HasKey Test Passed: testCreateKey Test Passed: testGetBinaryData Test Passed: testKeyDict_Get Test Passed: testSave Test Passed: testValueDict_ClearKeys Test Passed: testCmp Test Passed: testLinkType Test Passed: testSetExpandString Test Passed: testKeyDict_GetItem Test Passed: testRepr Test Passed: testClose Test Passed: testSetLink Test Passed: testGetValueDataFromName Test Passed: testUnicodeKeyName Test Passed: testKeyDict_Map Test Passed: testGetValueNameDataAndType Test Passed: testOpenFailure Test Passed: testSetDword Test Passed: testOpenKeyWithFlags Test Passed: testSetNone Test Passed: testKeyDict_Keys Test Passed: testMultiStringType Test Passed: testSetStringValue Test Passed: testValueDict_DelItem Test Passed: testNonZero Test Passed: testFlush Test Passed: testGetSubkeys Test Passed: testDeleteValue Test Passed: testSetString Test Passed: testValueDict_Values This is funny I was getting a more serious crash before. So was Fredrik. Trent -- Trent Mick TrentM@ActiveState.com From nhodgson@bigpond.net.au Fri Jul 28 00:21:01 2000 From: nhodgson@bigpond.net.au (Neil Hodgson) Date: Fri, 28 Jul 2000 09:21:01 +1000 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: Message-ID: <013901bff821$55dd02e0$8119fea9@neil> > Getting? I'm very old. I think. But even if I had a memory, I usually > ignore Unix-specific posts (i.e., I can't run code with a .fork(), so can > only sit back & admire the perversity of those who both can & do ). IIRC ActiveState contributed to Perl a version of fork that works on Win32. Has anyone looked at this? Could it be grabbed for Python? This would help heal one of the more difficult platform rifts. Emulating fork for Win32 looks quite difficult to me but if its already done... Neil From trentm@ActiveState.com Fri Jul 28 00:36:01 2000 From: trentm@ActiveState.com (Trent Mick) Date: Thu, 27 Jul 2000 16:36:01 -0700 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) In-Reply-To: <013901bff821$55dd02e0$8119fea9@neil> References: <013901bff821$55dd02e0$8119fea9@neil> Message-ID: <20000727163601.A32039@ActiveState.com> On Fri, Jul 28, 2000 at 09:21:01AM +1000, Neil Hodgson wrote: > IIRC ActiveState contributed to Perl a version of fork that works on > Win32. Has anyone looked at this? Could it be grabbed for Python? This would > help heal one of the more difficult platform rifts. Emulating fork for Win32 > looks quite difficult to me but if its already done... > I just asked Sarathy about this and he direct me to 'perldoc perlfork' (If you have ActivePerl 5.6 installed then you can look it up.) I have attached it here. The emulation of fork() in Win32 is not a perfect solution (e.g. sockets are not dupped, etc.). Trent ------------------- snip --------------------------- NAME perlfork - Perl's fork() emulation SYNOPSIS Perl provides a fork() keyword that corresponds to the Unix system call of the same name. On most Unix-like platforms where the fork() system call is available, Perl's fork() simply calls it. On some platforms such as Windows where the fork() system call is not available, Perl can be built to emulate fork() at the interpreter level. While the emulation is designed to be as compatible as possible with the real fork() at the the level of the Perl program, there are certain important differences that stem from the fact that all the pseudo child "processes" created this way live in the same real process as far as the operating system is concerned. This document provides a general overview of the capabilities and limitations of the fork() emulation. Note that the issues discussed here are not applicable to platforms where a real fork() is available and Perl has been configured to use it. DESCRIPTION The fork() emulation is implemented at the level of the Perl interpreter. What this means in general is that running fork() will actually clone the running interpreter and all its state, and run the cloned interpreter in a separate thread, beginning execution in the new thread just after the point where the fork() was called in the parent. We will refer to the thread that implements this child "process" as the pseudo-process. To the Perl program that called fork(), all this is designed to be transparent. The parent returns from the fork() with a pseudo-process ID that can be subsequently used in any process manipulation functions; the child returns from the fork() with a value of `0' to signify that it is the child pseudo-process. Behavior of other Perl features in forked pseudo-processes Most Perl features behave in a natural way within pseudo-processes. $$ or $PROCESS_ID This special variable is correctly set to the pseudo-process ID. It can be used to identify pseudo-processes within a particular session. Note that this value is subject to recycling if any pseudo-processes are launched after others have been wait()-ed on. %ENV Each pseudo-process maintains its own virtual enviroment. Modifications to %ENV affect the virtual environment, and are only visible within that pseudo-process, and in any processes (or pseudo-processes) launched from it. chdir() and all other builtins that accept filenames Each pseudo-process maintains its own virtual idea of the current directory. Modifications to the current directory using chdir() are only visible within that pseudo-process, and in any processes (or pseudo-processes) launched from it. All file and directory accesses from the pseudo-process will correctly map the virtual working directory to the real working directory appropriately. wait() and waitpid() wait() and waitpid() can be passed a pseudo-process ID returned by fork(). These calls will properly wait for the termination of the pseudo-process and return its status. kill() kill() can be used to terminate a pseudo-process by passing it the ID returned by fork(). This should not be used except under dire circumstances, because the operating system may not guarantee integrity of the process resources when a running thread is terminated. Note that using kill() on a pseudo-process() may typically cause memory leaks, because the thread that implements the pseudo-process does not get a chance to clean up its resources. exec() Calling exec() within a pseudo-process actually spawns the requested executable in a separate process and waits for it to complete before exiting with the same exit status as that process. This means that the process ID reported within the running executable will be different from what the earlier Perl fork() might have returned. Similarly, any process manipulation functions applied to the ID returned by fork() will affect the waiting pseudo-process that called exec(), not the real process it is waiting for after the exec(). exit() exit() always exits just the executing pseudo-process, after automatically wait()-ing for any outstanding child pseudo-processes. Note that this means that the process as a whole will not exit unless all running pseudo-processes have exited. Open handles to files, directories and network sockets All open handles are dup()-ed in pseudo-processes, so that closing any handles in one process does not affect the others. See below for some limitations. Resource limits In the eyes of the operating system, pseudo-processes created via the fork() emulation are simply threads in the same process. This means that any process-level limits imposed by the operating system apply to all pseudo-processes taken together. This includes any limits imposed by the operating system on the number of open file, directory and socket handles, limits on disk space usage, limits on memory size, limits on CPU utilization etc. Killing the parent process If the parent process is killed (either using Perl's kill() builtin, or using some external means) all the pseudo-processes are killed as well, and the whole process exits. Lifetime of the parent process and pseudo-processes During the normal course of events, the parent process and every pseudo-process started by it will wait for their respective pseudo-children to complete before they exit. This means that the parent and every pseudo-child created by it that is also a pseudo-parent will only exit after their pseudo-children have exited. A way to mark a pseudo-processes as running detached from their parent (so that the parent would not have to wait() for them if it doesn't want to) will be provided in future. CAVEATS AND LIMITATIONS BEGIN blocks The fork() emulation will not work entirely correctly when called from within a BEGIN block. The forked copy will run the contents of the BEGIN block, but will not continue parsing the source stream after the BEGIN block. For example, consider the following code: BEGIN { fork and exit; # fork child and exit the parent print "inner\n"; } print "outer\n"; This will print: inner rather than the expected: inner outer This limitation arises from fundamental technical difficulties in cloning and restarting the stacks used by the Perl parser in the middle of a parse. Open filehandles Any filehandles open at the time of the fork() will be dup()-ed. Thus, the files can be closed independently in the parent and child, but beware that the dup()-ed handles will still share the same seek pointer. Changing the seek position in the parent will change it in the child and vice-versa. One can avoid this by opening files that need distinct seek pointers separately in the child. Forking pipe open() not yet implemented The `open(FOO, "|-")' and `open(BAR, "-|")' constructs are not yet implemented. This limitation can be easily worked around in new code by creating a pipe explicitly. The following example shows how to write to a forked child: # simulate open(FOO, "|-") sub pipe_to_fork ($) { my $parent = shift; pipe my $child, $parent or die; my $pid = fork(); die "fork() failed: $!" unless defined $pid; if ($pid) { close $child; } else { close $parent; open(STDIN, "<&=" . fileno($child)) or die; } $pid; } if (pipe_to_fork('FOO')) { # parent print FOO "pipe_to_fork\n"; close FOO; } else { # child while () { print; } close STDIN; exit(0); } And this one reads from the child: # simulate open(FOO, "-|") sub pipe_from_fork ($) { my $parent = shift; pipe $parent, my $child or die; my $pid = fork(); die "fork() failed: $!" unless defined $pid; if ($pid) { close $child; } else { close $parent; open(STDOUT, ">&=" . fileno($child)) or die; } $pid; } if (pipe_from_fork('BAR')) { # parent while () { print; } close BAR; } else { # child print "pipe_from_fork\n"; close STDOUT; exit(0); } Forking pipe open() constructs will be supported in future. Global state maintained by XSUBs External subroutines (XSUBs) that maintain their own global state may not work correctly. Such XSUBs will either need to maintain locks to protect simultaneous access to global data from different pseudo-processes, or maintain all their state on the Perl symbol table, which is copied naturally when fork() is called. A callback mechanism that provides extensions an opportunity to clone their state will be provided in the near future. Interpreter embedded in larger application The fork() emulation may not behave as expected when it is executed in an application which embeds a Perl interpreter and calls Perl APIs that can evaluate bits of Perl code. This stems from the fact that the emulation only has knowledge about the Perl interpreter's own data structures and knows nothing about the containing application's state. For example, any state carried on the application's own call stack is out of reach. Thread-safety of extensions Since the fork() emulation runs code in multiple threads, extensions calling into non-thread-safe libraries may not work reliably when calling fork(). As Perl's threading support gradually becomes more widely adopted even on platforms with a native fork(), such extensions are expected to be fixed for thread-safety. BUGS * Having pseudo-process IDs be negative integers breaks down for the integer `-1' because the wait() and waitpid() functions treat this number as being special. The tacit assumption in the current implementation is that the system never allocates a thread ID of `1' for user threads. A better representation for pseudo-process IDs will be implemented in future. * This document may be incomplete in some respects. AUTHOR Support for concurrent interpreters and the fork() emulation was implemented by ActiveState, with funding from Microsoft Corporation. This document is authored and maintained by Gurusamy Sarathy . SEE ALSO the section on "fork" in the perlfunc manpage, the perlipc manpage -- Trent Mick TrentM@ActiveState.com From mhammond@skippinet.com.au Fri Jul 28 01:11:51 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 28 Jul 2000 10:11:51 +1000 Subject: [Python-Dev] failures in the regression tests In-Reply-To: <20000727161747.A27222@ActiveState.com> Message-ID: > Failures: > test_mmap Im looking at this > test_winreg > test_winreg2 And intend looking at these after. Mark. From billtut@microsoft.com Fri Jul 28 01:15:23 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 17:15:23 -0700 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD34C@RED-MSG-50> [ActivePerl's hack for fork()] Oh gack. I think I'd rather just not go down this road. This is one huge ugly hack. :( Having to maintain separate environments, and separate working directories. *shiver* Bill From tim_one@email.msn.com Fri Jul 28 01:32:00 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 20:32:00 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <14720.49393.792630.426570@bitdiddle.concentric.net> Message-ID: [Jeremy Hylton] > ... > For both bugs, though, a mutex and a condition variable are being use: Oh ya -- now that you mention it, I wrote that code -- but more than 7 years ago! How could a failure have gone undetected for so long? > The interpreter lock is being acquired and released in both cases. > > My current theory is that Python isn't dealing with the interpreter > lock correctly across a fork. If some thread other than the one > calling fork holds the interpreter lock mutex, Let's flesh out the most likely bad case: the main thread gets into posix_fork one of the spawned threads (say, thread 1) tries to acquire the global lock thread 1 gets into PyThread_acquire_lock thread 1 grabs the pthread mutex guarding "the global lock" the main thread executes fork() while thread 1 holds the mutex in the original process, everything's still cool: thread 1 still exists there, and it releases the mutex it acquired (after seeing that the "is it locked?" flag is set), yadda yadda yadda. but in the forked process, things are not cool: the (cloned) mutex guarding the global lock is still held What happens next in the child process is interesting : there is only one thread in the child process, and it's still in posix_fork. There it sets the main_thread and main_pid globals, and returns to the interpreter loop. That the forked pthread_mutex is still locked is irrelevant at this point: the child process won't care about that until enough bytecodes pass that its sole thread offers to yield. It doesn't bash into the already-locked cloned pthread mutex until it executes PyThread_release_lock as part of offering to yield. Then the child hangs. Don't know about this specific implementation, but phtread mutex acquires were usually implemented as busy-loops in my day (which is one reason Python locks were *not* modeled directly as pthread mutexes). So, in this scenario, the child hangs in a busy loop after an accidental amount of time passes after the fork. Matches your symptoms? It doesn't match Trent's segfault, but one nightmare at a time ... From mhammond@skippinet.com.au Fri Jul 28 03:06:10 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 28 Jul 2000 12:06:10 +1000 Subject: [Python-Dev] FW: [Patch #101006] fix mmapmodule test failures Message-ID: Hi all, I just uploaded a patch of mmapmodule to fix the test failures. The patch is not trivial, so I didnt just check it in. However, the patch also isnt _that_ large, so if some Windows people could give it a quick eyeball I would appreciate it. http://sourceforge.net/patch/?func=detailpatch&patch_id=101006&group_id=547 0 [Doh: Just noticed - the clode block that handles the DuplicateHandle() function failing needs to Py_DECREF the new object - Damn! So ignore that particular bug in the patch :-] Thanks, Mark. From greg@cosc.canterbury.ac.nz Fri Jul 28 04:02:29 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Fri, 28 Jul 2000 15:02:29 +1200 (NZST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <20000727150036.Z224@xs4all.nl> Message-ID: <200007280302.PAA09779@s454.cosc.canterbury.ac.nz> > Try to call __getslice__ with unconverted start, stop and step > If it fails with a TypeError, and step is not None, raise the above error > Else, convert start and stop to ints like the current normal slice > behaviour, and try __getslice__ the old way. NO!!! If my __getslice__ method has a bug which results in a type error, I want to get a traceback about it, not have it silently swallowed. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From greg@cosc.canterbury.ac.nz Fri Jul 28 04:10:07 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Fri, 28 Jul 2000 15:10:07 +1200 (NZST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271422.JAA13096@cj20424-a.reston1.va.home.com> Message-ID: <200007280310.PAA09782@s454.cosc.canterbury.ac.nz> Guido van Rossum : > But the two-arg opcode format slows down the opcode decoding -- and > that's the most time-critical part of all of ceval.c! I don't see why that has to be so, as long as you don't try to pre-fetch the extra argument before switching on the opcode. Just leave it up to each branch of the switch to fetch another argument if needed. In fact, why not do that for one-argument opcodes as well? If what you say is true, that should make argument decoding even faster than it is now! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From greg@cosc.canterbury.ac.nz Fri Jul 28 04:52:33 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Fri, 28 Jul 2000 15:52:33 +1200 (NZST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Message-ID: <200007280352.PAA09790@s454.cosc.canterbury.ac.nz> Ka-Ping Yee : > __get__(index, ...) # I want an ITEM. > __getslice__(slice-object, ...) # I want a SLICE. I like this (although it would be safer if the new-style __getslice__ had a new name as well). > This would require detection of whether any of the components > of a multidimensional (i.e. tuple) index were slices Doesn't the parser know this already? By the way, if you're going to make a clear separation between items and slices, then either *none* or *all* of the members of a multidimensional index should be slices, and mixing them should be an error! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From mhammond@skippinet.com.au Fri Jul 28 04:57:44 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 28 Jul 2000 13:57:44 +1000 Subject: [Python-Dev] New winreg module really an improvement? Message-ID: Ive just updated the test suite so that test_winreg2.py actually works. It appears that the new winreg.py module is still in a state of flux, but all work has ceased. The test for this module has lots of placeholders that are not filled in. Worse, the test code was checked in an obviously broken state (presumably "to be done", but guess who the bunny who had to do it was :-( Browsing the source made it clear that the module docstrings are still incomplete (eg "For information on the key API, open a key and look at its docstring."). As far as I can tell, there is no documentation in the library reference for this module (but the underlying _winreg module does have reasonable documentation) This is the first time I have had a serious look at the new winreg module, and the first time I have had to use it. I found it quite unintuitive, and it took me quite some time to update the test suite for what should have been a trivial case: Eg, the specific example I had a problem with was: key[value] Returns a result that includes the key index! This would be similar to a dictionary index _always_ returning the tuple, and the first element of the tuple is _always_ the key you just indexed. Has anyone else actually looked at or played with this, and still believe it is an improvement over _winreg? I personally find it unintuitive, and will personally continue to use _winreg. If we can't find anyone to complete it, document it, and stand up and say they really like it, I suggest we pull it. Still-can't-see-the-added-value-ly, Mark. From fdrake@beopen.com Fri Jul 28 05:49:28 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 28 Jul 2000 00:49:28 -0400 (EDT) Subject: [Python-Dev] New winreg module really an improvement? In-Reply-To: References: Message-ID: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> Mark Hammond writes: > It appears that the new winreg.py module is still in a state of flux, but > all work has ceased. The test for this module has lots of placeholders > that are not filled in. Worse, the test code was checked in an obviously > broken state (presumably "to be done", but guess who the bunny who had to > do it was :-( It was supposed to be Paul Prescod, since it was his module. > This is the first time I have had a serious look at the new winreg module, > and the first time I have had to use it. I found it quite unintuitive, and > it took me quite some time to update the test suite for what should have > been a trivial case: Interesting; I'd understood from Paul that you'd given approval to this module. > Has anyone else actually looked at or played with this, and still believe > it is an improvement over _winreg? I personally find it unintuitive, and > will personally continue to use _winreg. If we can't find anyone to > complete it, document it, and stand up and say they really like it, I > suggest we pull it. Paul, this is very much on your plate to make Mark happy with it, or it goes! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mhammond@skippinet.com.au Fri Jul 28 06:04:53 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 28 Jul 2000 15:04:53 +1000 Subject: [Python-Dev] New winreg module really an improvement? In-Reply-To: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> Message-ID: > Interesting; I'd understood from Paul that you'd given approval to > this module. Actually, it was more more along the lines of me promising to spend some time "over the next few days", and not getting to it. However, I believe it was less than a week before it was just checked in. I also sent a copy of the .NET registry API at that time, suggesting that it may be a better reference API, and one that VB, C# etc programmers will (over time) be familiar with. [Now I can admit it was the .NET API :-] Then the checkin just appeared! The end result was that I was never quite happy, but I felt personally responsible as I didnt find the time to look into this. I felt that I couldn't object, as I had let the team down. I fear this may be a general symptom of the new flurry of activity; no-one with a real job can keep up with this list, meaning valuable feedback on many proposals is getting lost. For example, DigiCool have some obviously smart people, but they are clearly too busy to offer feedback on anything lately. That is a real shame, and a good resource we are missing out on. > Paul, this is very much on your plate to make Mark happy > with it, or it goes! The comments about the documentation etc are easy to fix. I am quite interested to hear from people like Gordon and Bill about their thoughts. I am willing to accept the fact that just because I don't personally like it doesn't mean it sucks ;-) Mark. From bckfnn@worldonline.dk Fri Jul 28 06:15:17 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Fri, 28 Jul 2000 05:15:17 GMT Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <398099F1.B6B1D281@lemburg.com> References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <398065f3.6724599@smtp.worldonline.dk> <398099F1.B6B1D281@lemburg.com> Message-ID: <39811268.1131747@smtp.worldonline.dk> [M.-A. Lemburg] >Finn Bock wrote: >> >> [M.-A. Lemburg] >> >> >BTW, does Java support UCS-4 ? If not, then Java is wrong >> >here ;-) >> >> Java claims to use unicode 2.1 [*]. I couldn't locate anything describing if >> this is UCS-2 or UTF-16. I think unicode 2.1 includes UCS-4. The actual >> level of support for UCS-4 is properly debatable. >> >> - The builtin char is 16bit wide and can obviously not support UCS-4. >> - The Character class can report if a character is a surrogate: >> >>> from java.lang import Character >> >>> Character.getType("\ud800") == Character.SURROGATE >> 1 > >>>> unicodedata.category(u'\ud800') >'Cs' > >... which means the same thing only in Unicode3 standards >notation. > >Make me think: perhaps we should add the Java constants to >unicodedata base. Is there a list of those available >somewhere ? UNASSIGNED = 0 UPPERCASE_LETTER LOWERCASE_LETTER TITLECASE_LETTER MODIFIER_LETTER OTHER_LETTER NON_SPACING_MARK ENCLOSING_MARK COMBINING_SPACING_MARK DECIMAL_DIGIT_NUMBER LETTER_NUMBER OTHER_NUMBER SPACE_SEPARATOR LINE_SEPARATOR PARAGRAPH_SEPARATOR CONTROL FORMAT PRIVATE_USE SURROGATE DASH_PUNCTUATION START_PUNCTUATION END_PUNCTUATION CONNECTOR_PUNCTUATION OTHER_PUNCTUATION MATH_SYMBOL CURRENCY_SYMBOL MODIFIER_SYMBOL OTHER_SYMBOL >> - As reported, direct string comparison ignore surrogates. > >I would guess that this'll have to change as soon as JavaSoft >folks realize that they need to handle UTF-16 and not only >UCS-2. Predicting the future can be difficult, but here is my take: javasoft will never change the way String.compareTo works. String.compareTo is documented as: """ Compares two strings lexicographically. The comparison is based on the Unicode value of each character in the strings. ... """ Instead they will mark it as a very naive string comparison and suggest users to use the Collator classes for anything but the simplest cases. >> - The BreakIterator does not handle surrogates. It does handle >> combining characters and it seems a natural place to put support >> for surrogates. > >What is a BreakIterator ? An iterator to scan line/word breaks ? Yes, as well as character breaks. It already contains the framework for marking two chars next to each other as one. >> - The Collator class offers different levels of normalization before >> comparing string but does not seem to support surrogates. This class >> seems a natural place for javasoft to put support for surrogates >> during string comparison. > >We'll need something like this for 2.1 too: first some >standard APIs for normalization and then a few unicmp() >APIs to use for sorting. > >We might even have to add collation sequences somewhere because >this is a locale issue as well... sometimes it's even worse >with different strategies used for different tasks within one >locale, e.g. in Germany we sometimes sort the Umlaut ä as "ae" >and at other times as extra character. Info: The java Collator class is configured with - a locale and - a strengh parameter IDENTICAL; all difference are significant. PRIMARY (a vs b) SECONDARY (a vs ä) TERTIARY (a vs A) - a decomposition (http://www.unicode.org/unicode/reports/tr15/) NO_DECOMPOSITION CANONICAL_DECOMPOSITION FULL_DECOMPOSITION regards, finn From tim_one@email.msn.com Fri Jul 28 06:24:11 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 28 Jul 2000 01:24:11 -0400 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD345@RED-MSG-50> Message-ID: [Tim] > ... Don't know how long it will take this half of the world to > realize it, but UCS-4 is inevitable. [Bill Tutt] > On new systems perhaps, but important existing systems (Win32, > and probably Java) are stuck with that bad decision and have to > use UTF-16 for backward compatability purposes. Somehow that doesn't strike me as a good reason for Python to mimic them . > Surrogates aren't as far out as you might think. (The next rev of > the Unicode spec) But indeed, that's the *point*: they exhausted their 64K space in just a few years. Now the same experts say that adding 4 bits to the range will suffice for all time; I don't buy it; they picked 4 bits because that's what the surrogate mechanism was defined earlier to support. > That's certainly sooner than Win32 going away. :) I hope it stays around forever -- it's a great object lesson in what optimizing for yesterday's hardware can buy you . From bwarsaw@beopen.com Fri Jul 28 06:50:57 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 28 Jul 2000 01:50:57 -0400 (EDT) Subject: [Python-Dev] PEP 201, zip() builtin References: <14720.35958.632383.574511@anthem.concentric.net> Message-ID: <14721.8001.902979.957977@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> Could we please change "Parallel" to, e.g., "Lockstep" TP> throughout? Greg Wilson correctly pointed out that "parallel" TP> in the context of loops means something very different to the TP> scientific branch of the Python community. Easier to fix this TP> now that after it's spread to the docs. I know, and I guess I never came up with anything better which is why I didn't change it. "Lockstep" it is. TP> Just as you realized how inappropriate "parallel" was right TP> here . Heh. >> # find the length of the shortest sequence shortest = >> min(*map(len, args)) TP> Clearer as >> shortest = min(map(len, args)) A little experimentation leftover. Good catch. TP> However, this implies that all sequences must tell the truth TP> about their lengths, but the iteration protocol actually TP> terminates via a sequence raising IndexError. I believe we TP> want zip to follow the iteration protocol, in effect breaking TP> out of the outer loop as soon as some s[i] raises IndexError. TP> This was agreed to by all (incl. the BDFL) in some other TP> year's debates over this. Yup, I always intended the C implementation to obey the undocumented iteration protocol. But it /is/ better if the PEP's implementation were closer to the eventual C code, so I've swapped in a replacement. >> prefers zip() due to it's Haskell[2] heritage. See version 1.7 TP> "its", not "it's" Good catch. >> - Lazy evaluation. An earlier version of this PEP proposed >> that zip() return a built-in object that performed lazy >> evaluation using __getitem__() protocol. This has been >> strongly rejected by the BDFL in favor of returning a real >> Python list. If lazy evaluation is desired in the future, the >> BDFL suggests an xzip() function be added. TP> Which he'll then fight tooth and nail . :) >> ... TP> Nice job, Barry! Thank you. My pleasure! -Barry From Moshe Zadka Fri Jul 28 06:49:30 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 28 Jul 2000 08:49:30 +0300 (IDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271725.MAA17990@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 27 Jul 2000, Guido van Rossum wrote: > Another solution: require a class variable to indicate the class's > awareness: e.g. you must define __getslice_takes_three_args__ when > __getslice__(lo, hi, step) is supported, otherwise the call goes to > __getitem__(slice(lo, hi, step)). I don't think it can work: what about inheritance? Think of these two cases: class A: __getslice_takes_3_args__ def __getslice__(...): ... class B(A): def __getslice__(...): ... # something completely different and class C(A): def __getslice__(self, *args): # do something apply(A.__getslice__, (self,)+args) > This is a bit like the feature flag bits in the type struct. Which are ugly as hell too.....and only work because builtin types have a flat inheritance. oh-well-python-3000-is-just-around-the-corner-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From nowonder@nowonder.de Fri Jul 28 08:57:53 2000 From: nowonder@nowonder.de (Peter Schneider-Kamp) Date: Fri, 28 Jul 2000 07:57:53 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.13,1.14 References: <200007280549.WAA02159@slayer.i.sourceforge.net> Message-ID: <39813D01.C3680553@nowonder.de> Barry Warsaw wrote: > > Update of /cvsroot/python/python/nondist/peps > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2151 > > Modified Files: > pep-0000.txt Hi Barry! I don't know if it is possible to run pep2html.py on your system (I have only used it on Linux), but it would be nice if you could do that after committing changes to the PEPs. Thanks, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From bwarsaw@beopen.com Fri Jul 28 07:43:34 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 28 Jul 2000 02:43:34 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.13,1.14 References: <200007280549.WAA02159@slayer.i.sourceforge.net> <39813D01.C3680553@nowonder.de> Message-ID: <14721.11158.464598.572935@anthem.concentric.net> >>>>> "PS" == Peter Schneider-Kamp writes: PS> I don't know if it is possible to run pep2html.py on your PS> system (I have only used it on Linux), but it would be nice PS> if you could do that after committing changes to the PEPs. Hmm, I get the following exception when running on Python 2.0b1. Too sleepy to track this down right now. -B -------------------- snip snip -------------------- % python pep2html.py pep-0200.txt ... Traceback (most recent call last): File "pep2html.py", line 132, in ? main() File "pep2html.py", line 113, in main fixfile(file, os.path.splitext(file)[0] + ".html") File "pep2html.py", line 100, in fixfile line = fixpat.sub(lambda x, c=infile: fixanchor(c, x), line) TypeError: function requires exactly 3 arguments; 2 given From trentm@activestate.com Fri Jul 28 08:12:49 2000 From: trentm@activestate.com (Trent Mick) Date: Fri, 28 Jul 2000 00:12:49 -0700 Subject: [Python-Dev] failures in the regression tests In-Reply-To: References: <20000727161747.A27222@ActiveState.com> Message-ID: <20000728001249.A3056@ActiveState.com> On Fri, Jul 28, 2000 at 10:11:51AM +1000, Mark Hammond wrote: > And intend looking at these after. > > test_winreg Mark, you saw that I checked in a patch to Lib/test/output/test_winreg to make test_winreg pass, right? I did not check the test for content I just compared the output file with a newly generated (regrtest.py -g) output file. Trent -- Trent Mick TrentM@ActiveState.com From mal@lemburg.com Fri Jul 28 11:16:09 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 12:16:09 +0200 Subject: [Python-Dev] more unicode: \U support? References: Message-ID: <39815D69.1317A927@lemburg.com> Tim Peters wrote: > > [/F] > > would it be a good idea to add \UXXXXXXXX > > (8 hex digits) to 2.0? > > > > (only characters in the 0000-ffff range would > > be accepted in the current version, of course). > > [Tim agreed two msgs later; Guido agreed in private] > > [MAL] > > I don't really get the point of adding \uXXXXXXXX > > No: Fredrik's suggestion is with an uppercase U. He is not proposing to > extend the (lowercase) \u1234 notation. Ah, ok. So there will be no incompatibility with Java et al. > > when the internal format used is UTF-16 with support for surrogates. > > > > What should \u12341234 map to in a future implementation ? > > Two Python (UTF-16) Unicode characters ? > > \U12345678 is C99's ISO 10646 notation; as such, it can't always be mapped > to UTF-16. Sure it can: you'd have to use surrogates. Whether this should happen is another question, but not one which we'll have to deal with now, since as Fredrik proposed, \UXXXXXXXX will only work for 0-FFFF and raise an exception for all higher values. > > See > > > > http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc > .html#100850 > > > > for how Java defines \uXXXX... > > Which I pushed for from the start, and nobody is seeking to change. > > > We're following an industry standard here ;-) > > \U12345678 is also an industry standard, but in a more recent language (than > Java) that had more time to consider the eventual implications of Unicode's > limitations. We reserve the notation now so that it's possible to outgrow > Unicode later. Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Fri Jul 28 11:21:08 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 12:21:08 +0200 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: <013901bff821$55dd02e0$8119fea9@neil> Message-ID: <39815E94.462F65EF@lemburg.com> Neil Hodgson wrote: > > > Getting? I'm very old. I think. But even if I had a memory, I usually > > ignore Unix-specific posts (i.e., I can't run code with a .fork(), so can > > only sit back & admire the perversity of those who both can & do ). > > IIRC ActiveState contributed to Perl a version of fork that works on > Win32. Has anyone looked at this? Could it be grabbed for Python? This would > help heal one of the more difficult platform rifts. Emulating fork for Win32 > looks quite difficult to me but if its already done... This would indeed be a *very* useful addition and help porting os.fork() applications to Win32. (Ok, in the long run they would have to be converted to multi-threaded apps due to the process creation overhead on Win32, but for short term porting to Win32 this would be a Cool Thing, IMHO.) Can this code be grabbed from somewhere ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@beopen.com Fri Jul 28 12:42:12 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 06:42:12 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Fri, 28 Jul 2000 15:10:07 +1200." <200007280310.PAA09782@s454.cosc.canterbury.ac.nz> References: <200007280310.PAA09782@s454.cosc.canterbury.ac.nz> Message-ID: <200007281142.GAA03952@cj20424-a.reston1.va.home.com> > Guido van Rossum : > > > But the two-arg opcode format slows down the opcode decoding -- and > > that's the most time-critical part of all of ceval.c! > > I don't see why that has to be so, as long as you don't try > to pre-fetch the extra argument before switching on the > opcode. Just leave it up to each branch of the switch to > fetch another argument if needed. Sure. That's not how the patch is currently implemented though -- it adds this to the main opcode decoding: if (HAS_2ARG(opcode)) oparg2 = NEXTARG(); > In fact, why not do that for one-argument opcodes as well? > If what you say is true, that should make argument decoding > even faster than it is now! Yes -- but also would cause about 30-40 copies of the same code (which could be a single macro call). This could easily be tested and timed though. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Fri Jul 28 12:47:29 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 06:47:29 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Fri, 28 Jul 2000 15:52:33 +1200." <200007280352.PAA09790@s454.cosc.canterbury.ac.nz> References: <200007280352.PAA09790@s454.cosc.canterbury.ac.nz> Message-ID: <200007281147.GAA04007@cj20424-a.reston1.va.home.com> > Ka-Ping Yee : > > > __get__(index, ...) # I want an ITEM. > > __getslice__(slice-object, ...) # I want a SLICE. > > I like this (although it would be safer if the new-style > __getslice__ had a new name as well). > > > This would require detection of whether any of the components > > of a multidimensional (i.e. tuple) index were slices > > Doesn't the parser know this already? Yes. > By the way, if you're going to make a clear separation between items > and slices, then either *none* or *all* of the members of a > multidimensional index should be slices, and mixing them should > be an error! Huh? The way I understand this, mixing indices and slices is used all the time to reduce the dimensionality of an array. E.g. if A is a 2-dimensional array, A[0] is a 1-dim vector, and so are A[0, 1:-1] and A[:-1, 1]. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From thomas@xs4all.net Fri Jul 28 11:49:34 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 12:49:34 +0200 Subject: [Python-Dev] Developer activity (Was: New winreg module really an improvement?) In-Reply-To: ; from mhammond@skippinet.com.au on Fri, Jul 28, 2000 at 03:04:53PM +1000 References: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> Message-ID: <20000728124933.A266@xs4all.nl> On Fri, Jul 28, 2000 at 03:04:53PM +1000, Mark Hammond wrote: [ Something about something changing very fast, not giving Mark the chance to react to it ] > I fear this may be a general symptom of the new flurry of activity; no-one > with a real job can keep up with this list, meaning valuable feedback on > many proposals is getting lost. For example, DigiCool have some obviously > smart people, but they are clearly too busy to offer feedback on anything > lately. That is a real shame, and a good resource we are missing out on. Well, the same goes for Guido. Much though I liked the discussion about slices (and about augmented assignment) yesterday, it took me completely by suprise. And I'm not sure what the end result is, either. I don't even know whether it's finished or not, and it's not that easy to find out: it could be restin', pinin' for the fjords, or it could be nailed to its perch, it could be an ex-thread. And if it has ceased to be, well, it didn't amount to much, I think. Some opinions, and a simple (but effective, as far as I can tell) patch from Michael on one of the sub-issues. And I believe that's where PEPs are supposed to come in. They summarise the discussions, so that cool and smart people can look through it, see the proposal, see the pros and cons, and add their own. I'm not sure if it'll *work* like that, given that PEPs take some effort to create, and the format is still not too clear (at least, not to me.) And then there is the stuff that keeps popping up and isn't really PEPable: segfaults, tests failing, problem areas not covered by tests, unexpected behaviour noone has come around to fix or can figure out how to fix, etc. Maybe we need a TODO list, to store these issues ? Noone else is keeping track, I think, unless it's done in the Jitterbug buglist -- and I can't really work with jitterbug, myself. Items on the TODO list that stay on too long and start repetetive discussions are clearly candidates for PEPs, but others are just longstanding bugs that need to be properly investigated and fixed (probably elaborately) and noone disagrees with that. And if the 'fix' is non-obvious and involved, and generates too much discussion, it can always be PEPulated ;-) And if the TODO list needs a maintainer, someone that keeps track of all 'issues' that need closer examination, I'd be happy to volunteer. My idea would be to limit it to python-dev, unless someone forwards c.l.py traffic or other traffic that points out TODO-listable issues. (Or maybe SF has a good tool for this ? Not being a project admin, I've never seen the 'project manager', so I'm not sure if it has anything like a 'wishlist' ?) PS: Mark, I *do* have a real job, honest ;) I just get to be near my mail for about 14 hours a day. (I waste 4 hours to work/home travel, 6 hours to sleep/eating.) You should try working for an ISP, too! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@beopen.com Fri Jul 28 13:06:05 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:06:05 -0500 Subject: [Python-Dev] New winreg module really an improvement? In-Reply-To: Your message of "Fri, 28 Jul 2000 15:04:53 +1000." References: Message-ID: <200007281206.HAA04102@cj20424-a.reston1.va.home.com> I vaguely remember that I wasn't happy with the way this was handled either, but was too busy at the time to look into it. (I can't say whether I'm happy with the module or not, since I've never tried to use it. But I do feel unhappy about the process.) Note that Paul recently updated most of the docstrings, so he can't be blamed alone, and I'm sure fixes to the docstrings are welcome. Mark, could you spend some time explaining what you think should be changed in the module? I think it's not too late to change it -- after all there aren't any real users of the module out. (I note that Greg Ward chose the same route as you -- he uses _winreg, not winreg.) I vaguely remember that Paul Prescod's main gripe with the _winreg API was that it's not object-oriented enough -- but that seems his main gripe about most code these days. :-) Paul, how much experience with using the Windows registry did you have when you designed the new API? --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Fri Jul 28 13:26:07 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:26:07 -0500 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: Your message of "Fri, 28 Jul 2000 05:15:17 GMT." <39811268.1131747@smtp.worldonline.dk> References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <398065f3.6724599@smtp.worldonline.dk> <398099F1.B6B1D281@lemburg.com> <39811268.1131747@smtp.worldonline.dk> Message-ID: <200007281226.HAA04140@cj20424-a.reston1.va.home.com> > Predicting the future can be difficult, but here is my take: > javasoft will never change the way String.compareTo works. > String.compareTo is documented as: > """ > Compares two strings lexicographically. The comparison is based on > the Unicode value of each character in the strings. ... > """ (Noting that their definition of "character" is probably "a 16-bit value of type char", and has only fleeting resemblance to what is or is not defined as a character by the Unicode standard.) > Instead they will mark it as a very naive string comparison and suggest > users to use the Collator classes for anything but the simplest cases. Without having digested the entire discussion, this sounds like a good solution for Python too. The "==" operator should compare strings based on a simple-minded representation-oriented definition, and all the other stuff gets pushed into separate methods or classes. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Vladimir.Marangozov@inrialpes.fr Fri Jul 28 12:34:07 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 13:34:07 +0200 (CEST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007281142.GAA03952@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 28, 2000 06:42:12 AM Message-ID: <200007281134.NAA05764@python.inrialpes.fr> Guido van Rossum wrote: > > > In fact, why not do that for one-argument opcodes as well? > > If what you say is true, that should make argument decoding > > even faster than it is now! > > Yes -- but also would cause about 30-40 copies of the same code (which > could be a single macro call). This could easily be tested and timed > though. > Yes, and we won't be able to conclude anything. This is micro-optimization which doesn't give meaningful results. Actually, when I played last time with the main loop (it was for 1.5.2 I believe) duplicating the second argfetch doesn't give any speedup. Mainly because the code for the 2nd byte fetch is already in the processor's cache. Consequently, testing and fetching the 2nd argbyte (or skipping it) is faster when it's done before the big switch. If it's done per opcode, the cache may be invalidated. Micro-optimization doesn't worth the effort. As to the 2-byte arg limit, I think I'd be happy if the compiler raises an exception if this limit is exceeded. unrelated-with-PEP-203'ly y's -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido@beopen.com Fri Jul 28 13:38:34 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:38:34 -0500 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) In-Reply-To: Your message of "Fri, 28 Jul 2000 12:21:08 +0200." <39815E94.462F65EF@lemburg.com> References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> Message-ID: <200007281238.HAA04294@cj20424-a.reston1.va.home.com> > > IIRC ActiveState contributed to Perl a version of fork that works > > on Win32. Has anyone looked at this? Could it be grabbed for > > Python? This would help heal one of the more difficult platform > > rifts. Emulating fork for Win32 looks quite difficult to me but if > > its already done... > This would indeed be a *very* useful addition and help porting > os.fork() applications to Win32. (Ok, in the long run they would > have to be converted to multi-threaded apps due to the process > creation overhead on Win32, but for short term porting to Win32 > this would be a Cool Thing, IMHO.) I have only one word: yuck! Portable Python code should not rely on fork. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Fri Jul 28 13:41:41 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:41:41 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Fri, 28 Jul 2000 13:34:07 +0200." <200007281134.NAA05764@python.inrialpes.fr> References: <200007281134.NAA05764@python.inrialpes.fr> Message-ID: <200007281241.HAA04335@cj20424-a.reston1.va.home.com> > > Yes -- but also would cause about 30-40 copies of the same code (which > > could be a single macro call). This could easily be tested and timed > > though. > > Yes, and we won't be able to conclude anything. This is micro-optimization > which doesn't give meaningful results. Actually, when I played last time > with the main loop (it was for 1.5.2 I believe) duplicating the second > argfetch doesn't give any speedup. Mainly because the code for > the 2nd byte fetch is already in the processor's cache. Consequently, > testing and fetching the 2nd argbyte (or skipping it) is faster when > it's done before the big switch. If it's done per opcode, the cache may > be invalidated. Fair enough (for one particular CPU at least). > Micro-optimization doesn't worth the effort. As to the 2-byte arg limit, > I think I'd be happy if the compiler raises an exception if this limit > is exceeded. That would be a good first step indeed! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Fri Jul 28 13:53:54 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:53:54 -0500 Subject: [Python-Dev] Developer activity (Was: New winreg module really an improvement?) In-Reply-To: Your message of "Fri, 28 Jul 2000 12:49:34 +0200." <20000728124933.A266@xs4all.nl> References: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> <20000728124933.A266@xs4all.nl> Message-ID: <200007281253.HAA04381@cj20424-a.reston1.va.home.com> [Mark H] > > I fear this may be a general symptom of the new flurry of activity; no-one > > with a real job can keep up with this list, meaning valuable feedback on > > many proposals is getting lost. For example, DigiCool have some obviously > > smart people, but they are clearly too busy to offer feedback on anything > > lately. That is a real shame, and a good resource we are missing out on. [Thomas W] > Well, the same goes for Guido. Not sure what you mean. I'm too busy to offer feedback on anything? Give me a break! I probably spend 4 hours reading and responding to python-dev each day. > Much though I liked the discussion about > slices (and about augmented assignment) yesterday, it took me completely by > suprise. And I'm not sure what the end result is, either. I don't even know > whether it's finished or not, and it's not that easy to find out: it could > be restin', pinin' for the fjords, or it could be nailed to its perch, it > could be an ex-thread. And if it has ceased to be, well, it didn't amount to > much, I think. Some opinions, and a simple (but effective, as far as I can > tell) patch from Michael on one of the sub-issues. It's still open. I was trying to respond to your own post where you considered a redesign of the augmented assignment bytecode. I still think the proposed redesign is a good one (always use LOAD a, LOAD b, AUGASS, STORE b; or LOADSLICE, LOAD b, AUGASS, STORESLICE etc.) > And I believe that's where PEPs are supposed to come in. They summarise the > discussions, so that cool and smart people can look through it, see the > proposal, see the pros and cons, and add their own. I'm not sure if it'll > *work* like that, given that PEPs take some effort to create, and the format > is still not too clear (at least, not to me.) Don't worry too much about the format! Just write in a style that you think works for you. We're specifying the format to ensure that PEPs contain all the necessary information and are easily readable; I hope the rules aren't seen as stifling for PEP authors! > And then there is the stuff > that keeps popping up and isn't really PEPable: segfaults, tests failing, > problem areas not covered by tests, unexpected behaviour noone has come > around to fix or can figure out how to fix, etc. > > Maybe we need a TODO list, to store these issues ? Noone else is keeping > track, I think, unless it's done in the Jitterbug buglist -- and I can't > really work with jitterbug, myself. Items on the TODO list that stay on too > long and start repetetive discussions are clearly candidates for PEPs, but > others are just longstanding bugs that need to be properly investigated and > fixed (probably elaborately) and noone disagrees with that. And if the 'fix' > is non-obvious and involved, and generates too much discussion, it can > always be PEPulated ;-) > > And if the TODO list needs a maintainer, someone that keeps track of all > 'issues' that need closer examination, I'd be happy to volunteer. My idea > would be to limit it to python-dev, unless someone forwards c.l.py traffic > or other traffic that points out TODO-listable issues. Actually, Jeremy is the officially appointed 2.0 release manager, and as far as I can tell he's doing a good job of keeping track of open issues. He's also working on transferring the JitterBug database to the SF Bug Tracker, so we can shut off Jitterbug. > (Or maybe SF has a good tool for this ? Not being a project admin, I've > never seen the 'project manager', so I'm not sure if it has anything like a > 'wishlist' ?) The SF Bug Trackerwould work, I think. > PS: Mark, I *do* have a real job, honest ;) I just get to be near my mail > for about 14 hours a day. (I waste 4 hours to work/home travel, 6 hours to > sleep/eating.) You should try working for an ISP, too! 4 hours travel time? That gets you across the country! This job must be real important for you...! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From skip@mojam.com (Skip Montanaro) Fri Jul 28 13:17:46 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 28 Jul 2000 07:17:46 -0500 (CDT) Subject: [Python-Dev] urllib - {quote,unquote} vs. {quote_plus,unquote_plus} Message-ID: <14721.31210.734864.412520@beluga.mojam.com> I realize there is a symmetry between the functionality of urllib.{quote,unquote} and urllib.{quote_plus,unquote_plus}, but why doesn't unquote function like unquote_plus and map "+" to " "? Skip From thomas@xs4all.net Fri Jul 28 13:24:29 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 14:24:29 +0200 Subject: [Python-Dev] Developer activity (Was: New winreg module really an improvement?) In-Reply-To: <200007281253.HAA04381@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 28, 2000 at 07:53:54AM -0500 References: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> <20000728124933.A266@xs4all.nl> <200007281253.HAA04381@cj20424-a.reston1.va.home.com> Message-ID: <20000728142429.B266@xs4all.nl> On Fri, Jul 28, 2000 at 07:53:54AM -0500, Guido van Rossum wrote: > > Well, the same goes for Guido. > Not sure what you mean. I'm too busy to offer feedback on anything? > Give me a break! I probably spend 4 hours reading and responding to > python-dev each day. Unless I misinterpreted you, *you yourself* said this, Guido. (I can look this up if you wish.) PEPs are there so you (and others, like me) don't have to follow the details of each discussion. I didn't mean to imply you (or anyone else) don't consider python-dev important enough to follow, absolutely not. I just meant that we can't expect you (or anyone) to give feedback on *everything*, given the pace of messages yesterday (or any of the other bursts of activity.) Reading all messages is something else than understanding the issues, considering them and proposing new solutions or new ways of viewing them. > > Much though I liked the discussion about slices (and about augmented > > assignment) yesterday, it took me completely by suprise. And I'm not > > sure what the end result is, either. > I still think the proposed redesign is a good one (always use LOAD a, LOAD > b, AUGASS, STORE b; or LOADSLICE, LOAD b, AUGASS, STORESLICE etc.) So do I. I think thread-safety should be solved differently, even though I think it should be solved, somehow. ThreadSafeDict, with explicit grab/release lock ? :P But that was the other sub-thread. In this particular case, I was referring to the slicing thing, but I'm probably too impatient and urging on these issues. (Actually, I know I am. I'm just a tad worried things like this will go on and on and get lost and etc, etc, etc.) I'll be implementing the seperate AUGMENTED_ADD/SUBTRACT/etc ops this weekend, I think, and removing the 2-argument opcodes etc. > > And if the TODO list needs a maintainer, someone that keeps track of all > > 'issues' that need closer examination, I'd be happy to volunteer. My idea > > would be to limit it to python-dev, unless someone forwards c.l.py traffic > > or other traffic that points out TODO-listable issues. > Actually, Jeremy is the officially appointed 2.0 release manager, and > as far as I can tell he's doing a good job of keeping track of open > issues. He's also working on transferring the JitterBug database to > the SF Bug Tracker, so we can shut off Jitterbug. Ah, yes, hadn't considered the 2.0 release manager, probably because I hadn't figured it as a job for him -- some of these issues go beyond 2.0. Never-saw-a-release-manager-before-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From akuchlin@mems-exchange.org Fri Jul 28 13:29:19 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 28 Jul 2000 08:29:19 -0400 Subject: [Python-Dev] Re: [Patch #100740] gzip: readline(), readlines() patch In-Reply-To: <200007281025.DAA28944@delerium.i.sourceforge.net>; from noreply@sourceforge.net on Fri, Jul 28, 2000 at 03:25:36AM -0700 References: <200007281025.DAA28944@delerium.i.sourceforge.net> Message-ID: <20000728082919.A10938@newcnri.cnri.reston.va.us> On Fri, Jul 28, 2000 at 03:25:36AM -0700, noreply@sourceforge.net wrote: >Patch #100740 has been updated. >gvanrossum wrote: >Almost right. The docs for file objects specifically imply that a >negative arg to readline() or a zero arg to readlines() is the same as >no args; your defaults are sys.maxint so an explicit -1 or 0 won't do >the right thing. (This is important for wrapper classes that want to Which docs say this? I looked at Doc/lib/libstdtypes.tex to get the semantics: \begin{methoddesc}[file]{readline}{\optional{size}} ... If the \var{size} argument is present and non-negative, it is a maximum byte count (including the trailing newline) and an incomplete line may be returned. ... \end{methoddesc} \begin{methoddesc}[file]{readlines}{\optional{sizehint}} ... If the optional \var{sizehint} argument is present, instead of reading up to \EOF{}, whole lines totalling approximately \var{sizehint} bytes (possibly after rounding up to an internal buffer size) are read. \end{methoddesc} Neither text mentions the special cases for -1 and 0 in each function. Fixing the patch to get this right is trivial, but I think the docs need to be updated to mention this. --amk From akuchlin@mems-exchange.org Fri Jul 28 13:34:19 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 28 Jul 2000 08:34:19 -0400 Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <20000727173859.A10337@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 27, 2000 at 05:38:59PM -0400 References: <20000727173859.A10337@thyrsus.com> Message-ID: <20000728083419.B10938@newcnri.cnri.reston.va.us> On Thu, Jul 27, 2000 at 05:38:59PM -0400, Eric S. Raymond wrote: >correcting minor errors and adding explanatory material. The question >is what to do next, and that turns on whether discursive tutorial sections >are are considered fit for inclusion in the library reference. That's up to Fred to decide. I suspect the answer is no, since it would make the library reference too large and ungainly if every section had a tutorial. Regular expressions, socket programming, and XML processing are all sizable topics in their own right that would be covered. I will re-raise the idea of adding the HOWTOs to the documentation subtree, though; Fred & I have discussed it before, and decided not to for reasons that I can't remember. >Can anybody point me at the TeX source for the curses HOWTO? I'l mail it to you privately. >Also, I'm not sure where the material for curses.textbox should go. New >section? Or a subsection in the curses document? Probably a subsection, but again, Fred has final ruling on that. --amk From fdrake@beopen.com Fri Jul 28 14:24:41 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 28 Jul 2000 09:24:41 -0400 (EDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <20000728083419.B10938@newcnri.cnri.reston.va.us> References: <20000727173859.A10337@thyrsus.com> <20000728083419.B10938@newcnri.cnri.reston.va.us> Message-ID: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> On Thu, Jul 27, 2000 at 05:38:59PM -0400, Eric S. Raymond wrote: > correcting minor errors and adding explanatory material. The question > is what to do next, and that turns on whether discursive tutorial sections > are are considered fit for inclusion in the library reference. Andrew Kuchling writes: > That's up to Fred to decide. I suspect the answer is no, since it > would make the library reference too large and ungainly if every Hey, it's large & unweildy now. ;-) But I think you're right. Improving the curses HOWTO separately from the reference documentation makes sense. > I will re-raise the idea of adding the HOWTOs to the documentation > subtree, though; Fred & I have discussed it before, and decided not to > for reasons that I can't remember. I don't recall exactly, but I think it had a bit to do with the release scheduling (perhaps this was when the documentation was release lockstep with CPython?) and editorial control -- as long as you're willing to act as HOWTO editor, you should be able to release regardless of whether there's anything new to release in the standard library. Eric again: > Also, I'm not sure where the material for curses.textbox should go. New > section? Or a subsection in the curses document? curses.textbox should be documented in a \section like any other module. It can be placed in libcurses.tex along with the other curses-related modules. Is curses.wrapper documented, or is it an implementation detail? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@beopen.com Fri Jul 28 15:33:32 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 09:33:32 -0500 Subject: [Python-Dev] Re: [Patch #100740] gzip: readline(), readlines() patch In-Reply-To: Your message of "Fri, 28 Jul 2000 08:29:19 -0400." <20000728082919.A10938@newcnri.cnri.reston.va.us> References: <200007281025.DAA28944@delerium.i.sourceforge.net> <20000728082919.A10938@newcnri.cnri.reston.va.us> Message-ID: <200007281433.JAA04585@cj20424-a.reston1.va.home.com> > >Almost right. The docs for file objects specifically imply that a > >negative arg to readline() or a zero arg to readlines() is the same as > >no args; your defaults are sys.maxint so an explicit -1 or 0 won't do > >the right thing. (This is important for wrapper classes that want to > > Which docs say this? I looked at Doc/lib/libstdtypes.tex to get the > semantics: > > \begin{methoddesc}[file]{readline}{\optional{size}} > ... If the \var{size} argument is present and > non-negative, it is a maximum byte count (including the trailing > newline) and an incomplete line may be returned. ... > \end{methoddesc} I read this that any negative argument has the same effect as an absent argument. I suggested -1 as a typical negative number. The doc could be more explicit though. > \begin{methoddesc}[file]{readlines}{\optional{sizehint}} > ... If the optional \var{sizehint} argument is > present, instead of reading up to \EOF{}, whole lines totalling > approximately \var{sizehint} bytes (possibly after rounding up to an > internal buffer size) are read. > \end{methoddesc} Here you're right -- I got the 0 from the code. It should be documented. > Neither text mentions the special cases for -1 and 0 in each function. > Fixing the patch to get this right is trivial, but I think the docs > need to be updated to mention this. Agreed. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From pf@artcom-gmbh.de Fri Jul 28 14:37:56 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Fri, 28 Jul 2000 15:37:56 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: <14720.16857.900370.320050@bitdiddle.concentric.net> from Jeremy Hylton at "Jul 27, 2000 10: 6:17 am" Message-ID: Hi, Jeremy Hylton wrote: [...] > Feel free to think of it as a guide, but don't think of it as a > specification! (It is, as you mention, fairly old.) The only ------------------------------------------^^^^^^^^^^^ This was my argument to harden Moshes point, that *MUCH* code written until today relies on this advertised behaviour! > official word on reclaiming externel resource is the Python Language > Reference -- http://www.python.org/doc/current/ref/. > > >Some objects contain references to "external" resources such as open > >files or windows. It is understood that these resources are freed when > >the object is garbage-collected, but since garbage collection is not > >guaranteed to happen, such objects also provide an explicit way to > >release the external resource, usually a close() method. Programs are > >strongly recommended to explicitly close such objects. The > >`try...finally' statement provides a convenient way to do this. > > If this isn't clear enough, we could revise it for the next release of > the documentation. As Guido said, the code is broken, not JPython. Thank you: This paragraph is indeed clear enough. :-( And I must admit, that the above cited paragraph is at least as old as Mark Lutz book (I've just restored Python1.2/Doc to check this out, since I couldn't believe that in the first place: damned time machine!) I must have overlooked this particular paragraph in the past and so may many other users of Python (At least Mark Lutz ;-) ?) However I disagree with this paragraph. IMO one of the major strenghts of Python (in its reference implementation C-Python) has today compared to other languages (Java) is this particular behaviour. The argument made in the last sentence of the paragraph cited from the reference manual is bogus: In order to be able to call a close() method you have to keep an explicit reference to the object in question. This usually requires many lines of source code where previously only one line was needed: func(constructor("foo").method()) has to be recoded as try: ref = constructor("foo") func(ref.method()) finally: ref.close() if constructor happens to keep external resources. This is a factor of five (in LOC) of code bloat and is absolutely unacceptable. And in GUI programs you usually have *many* objects, that keep external resources like windows, files and the like. If this kind of coding is required to make existing Python apps running reliable under 'JPython', then this will render 'JPython' (and any other Python implementation without proper reliable reclaiming) pretty useless for me. (and may be to other members of the Python community) For me all those nifty new features currently discussed here (augmented ass., list comprehensions...) are not all *that* useful, compared to this important convience of the current C-Python implementation. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From Moshe Zadka Fri Jul 28 14:45:20 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 28 Jul 2000 16:45:20 +0300 (IDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> Message-ID: On Fri, 28 Jul 2000, Fred L. Drake, Jr. wrote: > I don't recall exactly, but I think it had a bit to do with the > release scheduling (perhaps this was when the documentation was > release lockstep with CPython?) and editorial control -- as long as > you're willing to act as HOWTO editor, you should be able to release > regardless of whether there's anything new to release in the standard > library. Neither of those reasons are enough not to put the HOWTOs in the CVS tree. Editors can keep the version in the CVS current via the patch manager, and release them as they need to. However, people who d/l Python will automatically download the HOWTOs. Think of perldoc lol (lists of lists) -- definitely "HOWTO" material, but in the Perl standard docs. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido@beopen.com Fri Jul 28 15:54:07 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 09:54:07 -0500 Subject: [Python-Dev] Developer activity (Was: New winreg module really an improvement?) In-Reply-To: Your message of "Fri, 28 Jul 2000 14:24:29 +0200." <20000728142429.B266@xs4all.nl> References: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> <20000728124933.A266@xs4all.nl> <200007281253.HAA04381@cj20424-a.reston1.va.home.com> <20000728142429.B266@xs4all.nl> Message-ID: <200007281454.JAA04789@cj20424-a.reston1.va.home.com> > > > Well, the same goes for Guido. > > > Not sure what you mean. I'm too busy to offer feedback on anything? > > Give me a break! I probably spend 4 hours reading and responding to > > python-dev each day. > > Unless I misinterpreted you, *you yourself* said this, Guido. (I can look > this up if you wish.) PEPs are there so you (and others, like me) don't > have to follow the details of each discussion. I didn't mean to imply you > (or anyone else) don't consider python-dev important enough to follow, > absolutely not. I just meant that we can't expect you (or anyone) to give > feedback on *everything*, given the pace of messages yesterday (or any of > the other bursts of activity.) You were commenting on Digital Creation's total absence. I am busy, but I am still very much involved in everything that goes on here, hence my reaction of "no fair!" That said, *nobody* can deal with 500 messages in one weekend, so the creations of PEPs should be received enthusiastically by all. > Reading all messages is something else than understanding the issues, > considering them and proposing new solutions or new ways of viewing them. And believe me, whereever I can, I do! > So do I. I think thread-safety should be solved differently, even though I > think it should be solved, somehow. ThreadSafeDict, with explicit > grab/release lock ? :P Library issue. > But that was the other sub-thread. In this particular case, I was referring > to the slicing thing, but I'm probably too impatient and urging on these > issues. (Actually, I know I am. I'm just a tad worried things like this will > go on and on and get lost and etc, etc, etc.) The slicing reorg is all pie-in-the-sky. Good for a post-2.0 PEP. > I'll be implementing the seperate AUGMENTED_ADD/SUBTRACT/etc ops this > weekend, I think, and removing the 2-argument opcodes etc. Good! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Vladimir.Marangozov@inrialpes.fr Fri Jul 28 15:04:03 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 16:04:03 +0200 (CEST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007281241.HAA04335@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 28, 2000 07:41:41 AM Message-ID: <200007281404.QAA06091@python.inrialpes.fr> Guido van Rossum wrote: > > > [me, on micro-optimizing the main loop] > > Fair enough (for one particular CPU at least). Since we're at it, it's worth mentioning another conclusion we came across at the time: the cache effects in the main loop are significant -- it is more important to try keeping at best the main loop small enough, so that those effects are minimized. An experiment I did at the time which gave some delta-speedup: I folded most of the UNOP & BINOP opcodes since they differ only by the functon they call and they duplicate most of the opcode body. Like this: Original: case BINARY_POWER: w = POP(); v = POP(); x = PyNumber_Power(v, w, Py_None); Py_DECREF(v); Py_DECREF(w); PUSH(x); if (x != NULL) continue; break; case BINARY_MULTIPLY: w = POP(); v = POP(); x = PyNumber_Multiply(v, w); Py_DECREF(v); Py_DECREF(w); PUSH(x); if (x != NULL) continue; break; ... Folded version: case BINARY_POWER: w = POP(); v = POP(); x = PyNumber_Power(v, w, Py_None); goto end_binop; case BINARY_MULTIPLY: w = POP(); v = POP(); x = PyNumber_Multiply(v, w); goto end_binop; ... end_binop: Py_DECREF(v); Py_DECREF(w); PUSH(x); if (x != NULL) continue; break; This reduced the code size of ceval.c, which resulted in less cache effects and gave more speed, despite the additional jumps. It possibly results in less page-faults too, although this is unlikely. Which makes me think that, if we want to do something about cache effects, it is probably not a bad idea to just "reorder" the bytecodes in the big switch by decreasing frequency (we have some stats about this -- I believe Skip and MAL have discussed the opcodes' frequency and the charts lie somewhere in the archives). I remember Marc-Andre had done something in this direction and reported some perf improvements too. Since reordering the opcodes doesn't really hurt, if I'm about to do something with the main loop, it'll be only this. > > > Micro-optimization doesn't worth the effort. As to the 2-byte arg limit, > > I think I'd be happy if the compiler raises an exception if this limit > > is exceeded. > > That would be a good first step indeed! I'll try to have a look, if someone else is not more reactive than me. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido@beopen.com Fri Jul 28 16:05:48 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 10:05:48 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Fri, 28 Jul 2000 16:04:03 +0200." <200007281404.QAA06091@python.inrialpes.fr> References: <200007281404.QAA06091@python.inrialpes.fr> Message-ID: <200007281505.KAA04865@cj20424-a.reston1.va.home.com> > Since we're at it, it's worth mentioning another conclusion we came across > at the time: the cache effects in the main loop are significant -- it is > more important to try keeping at best the main loop small enough, so that > those effects are minimized. Yes, that's what Tim keeps hammering on too. > An experiment I did at the time which gave some delta-speedup: > I folded most of the UNOP & BINOP opcodes since they differ only by the > functon they call and they duplicate most of the opcode body. Like this: [...] > This reduced the code size of ceval.c, which resulted in less cache effects > and gave more speed, despite the additional jumps. It possibly results in > less page-faults too, although this is unlikely. I expect this is wholly attributable to the reduced code size. Most binary operators aren't used frequently enough to make a difference in other ways. If you put the common code at the end of the code for binary '+', that would optimize the most common operator. > Which makes me think that, if we want to do something about cache effects, > it is probably not a bad idea to just "reorder" the bytecodes in the big > switch by decreasing frequency (we have some stats about this -- I believe > Skip and MAL have discussed the opcodes' frequency and the charts lie > somewhere in the archives). I remember Marc-Andre had done something in > this direction and reported some perf improvements too. Since reordering > the opcodes doesn't really hurt, if I'm about to do something with the > main loop, it'll be only this. Go for it -- sounds good! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From fdrake@beopen.com Fri Jul 28 15:06:00 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 28 Jul 2000 10:06:00 -0400 (EDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> Message-ID: <14721.37704.872570.141761@cj42289-a.reston1.va.home.com> Moshe Zadka writes: > Neither of those reasons are enough not to put the HOWTOs in the CVS tree. > Editors can keep the version in the CVS current via the patch manager, > and release them as they need to. However, people who d/l Python will > automatically download the HOWTOs. Think of perldoc lol (lists of lists) > -- definitely "HOWTO" material, but in the Perl standard docs. I'm happy to have them under CVS; I think the big issue is *where*. I'm not convinced they belong in the same portion of the tree as the standard documentation. Here's a thought: we currently have dist/ src/ Doc/ Instead, we could have: dist/ docs/ howto/ standard/ src/ The howto/ tree could be the howto collection Andrew maintains, and standard/ could be the XML version of the documentation once I've converted everything (which just shouldn't been in src/ to begin with). The documentation tools would become a separate component (which I've been thinking about for a while now), used by both the standard documentation and the howtos. Another option would be to simply create a new SourceForge project for HOWTO documents. That would be Andrew's baby, so would have to be his preferred approach. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr@thyrsus.com Fri Jul 28 15:21:09 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 10:21:09 -0400 Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: ; from moshez@math.huji.ac.il on Fri, Jul 28, 2000 at 04:45:20PM +0300 References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> Message-ID: <20000728102109.B14644@thyrsus.com> Moshe Zadka : > Neither of those reasons are enough not to put the HOWTOs in the CVS tree. > Editors can keep the version in the CVS current via the patch manager, > and release them as they need to. However, people who d/l Python will > automatically download the HOWTOs. Think of perldoc lol (lists of lists) > -- definitely "HOWTO" material, but in the Perl standard docs. I agree. There should be a HOWTO directory in the CVS tree. -- Eric S. Raymond Strict gun laws are about as effective as strict drug laws...It pains me to say this, but the NRA seems to be right: The cities and states that have the toughest gun laws have the most murder and mayhem. -- Mike Royko, Chicago Tribune From esr@thyrsus.com Fri Jul 28 15:26:23 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 10:26:23 -0400 Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <14721.37704.872570.141761@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jul 28, 2000 at 10:06:00AM -0400 References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> <14721.37704.872570.141761@cj42289-a.reston1.va.home.com> Message-ID: <20000728102623.D14644@thyrsus.com> Fred L. Drake, Jr. : > I'm happy to have them under CVS; I think the big issue is *where*. > I'm not convinced they belong in the same portion of the tree as the > standard documentation. > Here's a thought: we currently have > > dist/ > src/ > Doc/ > > Instead, we could have: > > dist/ > docs/ > howto/ > standard/ > src/ > > The howto/ tree could be the howto collection Andrew maintains, and > standard/ could be the XML version of the documentation once I've > converted everything (which just shouldn't been in src/ to begin > with). This seems eminently reasonable to me. -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. From akuchlin@mems-exchange.org Fri Jul 28 15:21:32 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 28 Jul 2000 10:21:32 -0400 Subject: [Python-Dev] Howto docs In-Reply-To: <14721.37704.872570.141761@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jul 28, 2000 at 10:06:00AM -0400 References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> <14721.37704.872570.141761@cj42289-a.reston1.va.home.com> Message-ID: <20000728102132.A29083@kronos.cnri.reston.va.us> On Fri, Jul 28, 2000 at 10:06:00AM -0400, Fred L. Drake, Jr. wrote: > Instead, we could have: > dist/ > docs/ > howto/ > standard/ > src/ If you want to do this reorganization, fine, but it seems like it'll be a long way off. Why not just put them in nondist/doc/howto? (Other documentation could be put in nondist/doc -- I could even dig out the grimoire and add it, if someone would be interested in updating and maintaining it.) On the other hand, the documentation maintainers might be a different set of people from code maintainers, and we might not want them checking in code changes, so having the docs as a completely separate project would allow finer control of this. On the third hand, we do have the python-checkins list to keep an eye on what's happening. I'd vote for nondist/doc/howto. --amk From esr@thyrsus.com Fri Jul 28 15:32:56 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 10:32:56 -0400 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007281505.KAA04865@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 28, 2000 at 10:05:48AM -0500 References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> Message-ID: <20000728103256.E14644@thyrsus.com> Guido van Rossum : > > Which makes me think that, if we want to do something about cache effects, > > it is probably not a bad idea to just "reorder" the bytecodes in the big > > switch by decreasing frequency (we have some stats about this -- I believe > > Skip and MAL have discussed the opcodes' frequency and the charts lie > > somewhere in the archives). I remember Marc-Andre had done something in > > this direction and reported some perf improvements too. Since reordering > > the opcodes doesn't really hurt, if I'm about to do something with the > > main loop, it'll be only this. > > Go for it -- sounds good! Allow me to also suggest liberal use of "inline" for small helper functions called from within the main interpreter loop. The nonlocality produced by subroutine calls plays hell with small caches. Side observation: the fact that micro-optimizations are giving us measurable speedups tells us that the higher-level architecture and algoirithms are very well tuned. Take a bow, Guido! -- Eric S. Raymond "Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action." -- George Washington, in a speech of January 7, 1790 From esr@thyrsus.com Fri Jul 28 15:42:23 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 10:42:23 -0400 Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jul 28, 2000 at 09:24:41AM -0400 References: <20000727173859.A10337@thyrsus.com> <20000728083419.B10938@newcnri.cnri.reston.va.us> <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> Message-ID: <20000728104223.G14644@thyrsus.com> Fred L. Drake, Jr. : > curses.textbox should be documented in a \section like any other > module. It can be placed in libcurses.tex along with the other > curses-related modules. Ah! I didn't realize multiple suggestions could live in the same file under our conventions. Guess I'll have to go reread the Documentation HOWTO. > Is curses.wrapper documented, or is it an implementation detail? I'll document it. -- Eric S. Raymond No matter how one approaches the figures, one is forced to the rather startling conclusion that the use of firearms in crime was very much less when there were no controls of any sort and when anyone, convicted criminal or lunatic, could buy any type of firearm without restriction. Half a century of strict controls on pistols has ended, perversely, with a far greater use of this weapon in crime than ever before. -- Colin Greenwood, in the study "Firearms Control", 1972 From mal@lemburg.com Fri Jul 28 15:39:21 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 16:39:21 +0200 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> <200007281238.HAA04294@cj20424-a.reston1.va.home.com> Message-ID: <39819B19.F5624BD0@lemburg.com> Guido van Rossum wrote: > > > > IIRC ActiveState contributed to Perl a version of fork that works > > > on Win32. Has anyone looked at this? Could it be grabbed for > > > Python? This would help heal one of the more difficult platform > > > rifts. Emulating fork for Win32 looks quite difficult to me but if > > > its already done... > > > This would indeed be a *very* useful addition and help porting > > os.fork() applications to Win32. (Ok, in the long run they would > > have to be converted to multi-threaded apps due to the process > > creation overhead on Win32, but for short term porting to Win32 > > this would be a Cool Thing, IMHO.) > > I have only one word: yuck! > > Portable Python code should not rely on fork. I wasn't talking about "portable" code, but about "porting" code to Win32. I happen to use an application which manages a few processes and spawns these using .fork(). It would nice to have a .fork() like API on Win32 to experiment with. Anyway, I would already be happy if I could just look at the code from ActiveState... if it's Perl all the way I probably don't want to look any further into this ;-) BTW, I'm not too familiar with IPC on Win32. What would be the best strategy to this on the Windows platforms ? I remember that Skip once posted a comparison of Unix Domain sockets and TCP Sockets on Unix which showed that UD sockets are much faster than TCP sockets. On Win32 these don't exist and I suppose that TCP sockets are too slow for my server. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Fri Jul 28 15:59:57 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 16:59:57 +0200 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> Message-ID: <39819FED.41C11063@lemburg.com> Guido van Rossum wrote: > > > Since we're at it, it's worth mentioning another conclusion we came across > > at the time: the cache effects in the main loop are significant -- it is > > more important to try keeping at best the main loop small enough, so that > > those effects are minimized. > > Yes, that's what Tim keeps hammering on too. +1 from here ;-) I have done quite a bit of testing with the old 1.5 ceval loop (patch still available in case someone wants to look at it) and found these things: 1. It pays off to special case LOAD_FAST by handling it before going into the switch at all, since this is the one most often used opcode in Python. 2. Reordering the opcodes has some noticable effect on performance too, even though it is very touchy to cache lines. 3. Splitting the big switch in two with the first one holding the most of often used opcodes while the second one takes care of the more esoteric ones helps keeping the inner loop in the CPU cache and thus increases performance. From an old mail: """ Here is a little statistic that I've run over a total of more than 100M opcodes: Opcode frequencies: ------------------------------------------------------------------------ LOAD_FAST(124) : 19323126 ================================ SET_LINENO(127) : 15055591 ======================== LOAD_CONST(100) : 9254683 =============== LOAD_NAME(101) : 8218954 ============= LOAD_GLOBAL(116) : 7174876 =========== STORE_FAST(125) : 5927769 ========= POP_TOP( 1) : 5587424 ========= CALL_FUNCTION(131) : 5404709 ======== JUMP_IF_FALSE(111) : 5289262 ======== COMPARE_OP(106) : 4495179 ======= LOAD_ATTR(105) : 3481878 ===== BINARY_ADD( 23) : 3420811 ===== RETURN_VALUE( 83) : 2221212 === STORE_NAME( 90) : 2176228 === STORE_ATTR( 95) : 2085338 === BINARY_SUBSCR( 25) : 1834612 === JUMP_ABSOLUTE(113) : 1648327 == STORE_SUBSCR( 60) : 1446307 == JUMP_FORWARD(110) : 1014821 = BINARY_SUBTRACT( 24) : 910085 = POP_BLOCK( 87) : 806160 = STORE_GLOBAL( 97) : 779880 = FOR_LOOP(114) : 735245 = SETUP_LOOP(120) : 657432 = BINARY_MODULO( 22) : 610121 = 32( 32) : 530811 31( 31) : 530657 BINARY_MULTIPLY( 20) : 392274 SETUP_EXCEPT(121) : 285523 ... """ These stats were created using an instrumented Python interpreter running real applications (and recording all executed opcodes to a file), so they can be considered close enough to what Python typically does in its inner loop. > > An experiment I did at the time which gave some delta-speedup: > > I folded most of the UNOP & BINOP opcodes since they differ only by the > > functon they call and they duplicate most of the opcode body. Like this: > [...] > > This reduced the code size of ceval.c, which resulted in less cache effects > > and gave more speed, despite the additional jumps. It possibly results in > > less page-faults too, although this is unlikely. > > I expect this is wholly attributable to the reduced code size. Most > binary operators aren't used frequently enough to make a difference in > other ways. If you put the common code at the end of the code for > binary '+', that would optimize the most common operator. > > > Which makes me think that, if we want to do something about cache effects, > > it is probably not a bad idea to just "reorder" the bytecodes in the big > > switch by decreasing frequency (we have some stats about this -- I believe > > Skip and MAL have discussed the opcodes' frequency and the charts lie > > somewhere in the archives). I remember Marc-Andre had done something in > > this direction and reported some perf improvements too. Since reordering > > the opcodes doesn't really hurt, if I'm about to do something with the > > main loop, it'll be only this. > > Go for it -- sounds good! If you need help, I can dig up those old tools and patches... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From esr@thyrsus.com Fri Jul 28 16:26:46 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 11:26:46 -0400 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <39819FED.41C11063@lemburg.com>; from mal@lemburg.com on Fri, Jul 28, 2000 at 04:59:57PM +0200 References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> Message-ID: <20000728112646.A15634@thyrsus.com> M.-A. Lemburg : > LOAD_FAST(124) : 19323126 ================================ > SET_LINENO(127) : 15055591 ======================== > LOAD_CONST(100) : 9254683 =============== > LOAD_NAME(101) : 8218954 ============= > LOAD_GLOBAL(116) : 7174876 =========== > STORE_FAST(125) : 5927769 ========= > POP_TOP( 1) : 5587424 ========= > CALL_FUNCTION(131) : 5404709 ======== > JUMP_IF_FALSE(111) : 5289262 ======== > COMPARE_OP(106) : 4495179 ======= > LOAD_ATTR(105) : 3481878 ===== > BINARY_ADD( 23) : 3420811 ===== > RETURN_VALUE( 83) : 2221212 === > STORE_NAME( 90) : 2176228 === > STORE_ATTR( 95) : 2085338 === > BINARY_SUBSCR( 25) : 1834612 === > JUMP_ABSOLUTE(113) : 1648327 == > STORE_SUBSCR( 60) : 1446307 == > JUMP_FORWARD(110) : 1014821 = > BINARY_SUBTRACT( 24) : 910085 = > POP_BLOCK( 87) : 806160 = > STORE_GLOBAL( 97) : 779880 = > FOR_LOOP(114) : 735245 = > SETUP_LOOP(120) : 657432 = > BINARY_MODULO( 22) : 610121 = > 32( 32) : 530811 > 31( 31) : 530657 > BINARY_MULTIPLY( 20) : 392274 > SETUP_EXCEPT(121) : 285523 Some thoughts: 1. That looks as close to a Poisson distribution as makes no difference. I wonder what that means? 2. Microtuning in the implementations of the top 3 opcodes looks indicated, as they seem to constitute more than 50% of all calls. 3. On the other hand, what do you get when you weight these by average time per opcode? -- Eric S. Raymond "The bearing of arms is the essential medium through which the individual asserts both his social power and his participation in politics as a responsible moral being..." -- J.G.A. Pocock, describing the beliefs of the founders of the U.S. From thomas@xs4all.net Fri Jul 28 16:32:56 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 17:32:56 +0200 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <20000728112646.A15634@thyrsus.com>; from esr@thyrsus.com on Fri, Jul 28, 2000 at 11:26:46AM -0400 References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <20000728112646.A15634@thyrsus.com> Message-ID: <20000728173256.C266@xs4all.nl> On Fri, Jul 28, 2000 at 11:26:46AM -0400, Eric S. Raymond wrote: > > LOAD_FAST(124) : 19323126 ================================ > > SET_LINENO(127) : 15055591 ======================== > 1. That looks as close to a Poisson distribution as makes no difference. > I wonder what that means? It means there's still room for optimization! Other than that, probably not much. I also think that the similarity vanishes if you take into account that SET_LINENO does nothing, and LOAD_FAST is a basic operation and should be grouped with LOAD_NAME and LOAD_GLOBAL. > 2. Microtuning in the implementations of the top 3 opcodes looks indicated, > as they seem to constitute more than 50% of all calls. Actually, I believe there was talk of removing SET_LINENO altogether... or am I mistaken in that ? In any case, you can do it by using -OO. > 3. On the other hand, what do you get when you weight these by average > time per opcode? My guess is that *_NAME moves on up, as they already are pretty high up, and BINARY_* and UNARY_*, go *way* up: imagine all those classes that implement __add__ and __not__. Even if you have but a few of those calls, they effectively are (Python) function calls. In other words, those are pretty meaningless. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov@inrialpes.fr Fri Jul 28 16:47:50 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 17:47:50 +0200 (CEST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <39819FED.41C11063@lemburg.com> from "M.-A. Lemburg" at Jul 28, 2000 04:59:57 PM Message-ID: <200007281547.RAA06456@python.inrialpes.fr> M.-A. Lemburg wrote: > > If you need help, I can dig up those old tools and patches... Yes, please do. I think I'll come up with a patch posted to SF for your collective review. [Eric Reymond, on opcode stats by MAL] > > LOAD_FAST(124) : 19323126 ================================ > > SET_LINENO(127) : 15055591 ======================== > > LOAD_CONST(100) : 9254683 =============== > > LOAD_NAME(101) : 8218954 ============= > > ... > > Some thoughts: > > 1. That looks as close to a Poisson distribution as makes no difference. > I wonder what that means? Well, it's difficult to say what this means without looking at the tools that were used to generate these stats. > > 2. Microtuning in the implementations of the top 3 opcodes looks indicated, > as they seem to constitute more than 50% of all calls. Imagine what will happen if SET_LINENO disappears But this is very tricky business which is more complicated than it looks like... > > 3. On the other hand, what do you get when you weight these by average > time per opcode? I haven't run 100M opcodes, but you may want to have a look at some old micro-profiling I did long time ago: http://starship.python.net/~vlad/tprof/ The relevant file for the main loop is: http://starship.python.net/~vlad/tprof/pybench-0.6/python-151-orig-thr/__t.eval_code2_ceval.c I am not sure this makes any sense by now, though. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal@lemburg.com Fri Jul 28 17:07:21 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 18:07:21 +0200 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <20000728112646.A15634@thyrsus.com> Message-ID: <3981AFB9.26AEB1D1@lemburg.com> "Eric S. Raymond" wrote: > > M.-A. Lemburg : > > LOAD_FAST(124) : 19323126 ================================ > > SET_LINENO(127) : 15055591 ======================== > > LOAD_CONST(100) : 9254683 =============== > > LOAD_NAME(101) : 8218954 ============= > > LOAD_GLOBAL(116) : 7174876 =========== > > STORE_FAST(125) : 5927769 ========= > > POP_TOP( 1) : 5587424 ========= > > CALL_FUNCTION(131) : 5404709 ======== > > JUMP_IF_FALSE(111) : 5289262 ======== > > COMPARE_OP(106) : 4495179 ======= > > LOAD_ATTR(105) : 3481878 ===== > > BINARY_ADD( 23) : 3420811 ===== > > RETURN_VALUE( 83) : 2221212 === > > STORE_NAME( 90) : 2176228 === > > STORE_ATTR( 95) : 2085338 === > > BINARY_SUBSCR( 25) : 1834612 === > > JUMP_ABSOLUTE(113) : 1648327 == > > STORE_SUBSCR( 60) : 1446307 == > > JUMP_FORWARD(110) : 1014821 = > > BINARY_SUBTRACT( 24) : 910085 = > > POP_BLOCK( 87) : 806160 = > > STORE_GLOBAL( 97) : 779880 = > > FOR_LOOP(114) : 735245 = > > SETUP_LOOP(120) : 657432 = > > BINARY_MODULO( 22) : 610121 = > > 32( 32) : 530811 > > 31( 31) : 530657 > > BINARY_MULTIPLY( 20) : 392274 > > SETUP_EXCEPT(121) : 285523 > > Some thoughts: > > 1. That looks as close to a Poisson distribution as makes no difference. > I wonder what that means? I'd say that there are good chances on applying optimizations to the Python byte code -- someone with enough VC should look into this on a serious basis ;-) I think that highly optimized Python byte code compilers/ interpreters would make nice commercial products which complement the targetted Python+Batteries distros. > 2. Microtuning in the implementations of the top 3 opcodes looks indicated, > as they seem to constitute more than 50% of all calls. Separating out LOAD_FAST from the switch shows a nice effect. SET_LINENO is removed by -OO anyway, so there's really no use in optimizing this one. In my hacked up version I've also moved the signal handler into the second switch (along with SET_LINENO). The downside of this is that your program will only "see" signals if it happens to execute one of the less common opcodes, on the plus side you get an additional boost in performance -- if your app doesn't rely on signals to work, this is also a great way to squeeze out a little more performance. > 3. On the other hand, what do you get when you weight these by average > time per opcode? Haven't tested this, but even by simply reordering the cases according to the above stats you get a positive response from pybench and pystone. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Fri Jul 28 17:13:12 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 28 Jul 2000 12:13:12 -0400 Subject: [Python-Dev] Reordering opcodes In-Reply-To: <3981AFB9.26AEB1D1@lemburg.com>; from mal@lemburg.com on Fri, Jul 28, 2000 at 06:07:21PM +0200 References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <20000728112646.A15634@thyrsus.com> <3981AFB9.26AEB1D1@lemburg.com> Message-ID: <20000728121312.E29083@kronos.cnri.reston.va.us> On Fri, Jul 28, 2000 at 06:07:21PM +0200, M.-A. Lemburg wrote: >I'd say that there are good chances on applying optimizations >to the Python byte code -- someone with enough VC should look >into this on a serious basis ;-) At OLS I saw David S. Miller's keynote. Miller's been a Linux kernel hacker for quite a long time, and has been responsible for much of the Sparc and MIPS port, maintains the networking stack, etc. In his talk he mentioned that occasionally he gets really tired of kernel-space work, and has to do something in user-space for a change of pace; in that vein he rewrote GCC's Sparc64 backend, and recently wrote an nVidia driver for XFree86. My first thought when he said that was "Gosh, he should look at ceval.c!" --amk From billtut@microsoft.com Fri Jul 28 17:42:56 2000 From: billtut@microsoft.com (Bill Tutt) Date: Fri, 28 Jul 2000 09:42:56 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD34D@RED-MSG-50> > From: Tim Peters [mailto:tim_one@email.msn.com] > [Tim] > > ... Don't know how long it will take this half of the world to > > realize it, but UCS-4 is inevitable. > > [Bill Tutt] > > On new systems perhaps, but important existing systems (Win32, > > and probably Java) are stuck with that bad decision and have to > > use UTF-16 for backward compatability purposes. > Somehow that doesn't strike me as a good reason for Python to mimic them > . So don't. If you think UTF-16 is yet another bad engineering decision, then take the hit now of making Python's unicode support natively UCS-4 so we don't have a backward compatability problem when the next Unicode or ISO 10646 revision comes out. Just realize and accept the cost of doing so. (constant conversions for a nice big chunk of your users.) > > Surrogates aren't as far out as you might think. (The next rev of > > the Unicode spec) > But indeed, that's the *point*: they exhausted their 64K space in just a > few years. Now the same experts say that adding 4 bits to the range will > suffice for all time; I don't buy it; they picked 4 bits because that's what > the surrogate mechanism was defined earlier to support. I don't think the experts are saying the extra 4 bits will suffice for all time, but it should certainly suffice until we meet aliens form a different planet. :) > > That's certainly sooner than Win32 going away. :) > I hope it stays around forever -- it's a great object lesson in what > optimizing for yesterday's hardware can buy you . Heh. A dev manager from Excel made the exact same comment to me just yesterday. :) Bill From thomas@xs4all.net Fri Jul 28 17:45:12 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 18:45:12 +0200 Subject: [Python-Dev] buglet in unary ops on classes. Message-ID: <20000728184512.D266@xs4all.nl> While poking around looking for something else, I found this little buglet: >>> class X: ... def __getattr__(self, val): ... print "getattr:", val ... raise AttributeError >>> x = X() >>> ~x getattr: __invert__ Traceback (most recent call last): File "", line 1, in ? File "", line 4, in __getattr__ AttributeError The unary ops all do this (raising AttributeError), but the binary ops do not: >>> x+1 getattr: __coerce__ getattr: __add__ Traceback (most recent call last): File "", line 1, in ? TypeError: __add__ nor __radd__ defined for these operands Shouldn't this translation be done for unary ops as well ? Is it safe to assume that instance_getattr() only returns NULL if the attribute is not found ? PyInstance_DoBinOp() takes this assumption wrt. PyObject_GetAttr(), and I don't really see a problem with it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov@inrialpes.fr Fri Jul 28 18:01:31 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 19:01:31 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <3981AFB9.26AEB1D1@lemburg.com> from "M.-A. Lemburg" at Jul 28, 2000 06:07:21 PM Message-ID: <200007281701.TAA06630@python.inrialpes.fr> M.-A. Lemburg wrote: > > Separating out LOAD_FAST from the switch shows a nice effect. > SET_LINENO is removed by -OO anyway, so there's really no > use in optimizing this one. Actually, I think that instead of fighting with SET_LINENO for the standard setup, it would make sense to change the invocation options to something more standard: 1) python - code without SET_LINENO 2) python -g - code for debugging, with SET_LINENO 3) python -O - code without doc-strings. The point is that currently there's no optimization of the code stream at all, in the sense of classic compiler optimization (code block-level optimizations, loop unrolling, etc). And SET_LINENO is actually useful only for debugging (with pdb, etc). What about this as a sane proposal for SET_LINENO? -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From trentm@ActiveState.com Fri Jul 28 18:10:15 2000 From: trentm@ActiveState.com (Trent Mick) Date: Fri, 28 Jul 2000 10:10:15 -0700 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) In-Reply-To: <39815E94.462F65EF@lemburg.com> References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> Message-ID: <20000728101015.A6542@ActiveState.com> On Fri, Jul 28, 2000 at 12:21:08PM +0200, M . -A . Lemburg wrote: > > > > IIRC ActiveState contributed to Perl a version of fork that works on > > Win32. Has anyone looked at this? Could it be grabbed for Python? This would > > help heal one of the more difficult platform rifts. Emulating fork for Win32 > > looks quite difficult to me but if its already done... > > This would indeed be a *very* useful addition and help porting > os.fork() applications to Win32. (Ok, in the long run they would > have to be converted to multi-threaded apps due to the process > creation overhead on Win32, but for short term porting to Win32 > this would be a Cool Thing, IMHO.) > > Can this code be grabbed from somewhere ? > It is all in ActivePerl. You can download the source code: http://www.activestate.com/Products/ActivePerl/Download.html Besides, I would guess (and I *am* guessing, I don't know this) that the Perl fork stuff is fairly closely tied to Perl, i.e. it may not be easy at all to yank it out and plug it into Python. However, I echo the Bill's and Guido's sentiments. Having a hacked emulation of fork encourages people to use it. Once someone has their favorite UNIX app it running on Win32 with the fake-fork they will have little incentive to port it properly using threads. There will then be calls to improve to Win32 fork implementation... and that is the wrong support path. Trent -- Trent Mick TrentM@ActiveState.com From mal@lemburg.com Fri Jul 28 19:12:48 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 20:12:48 +0200 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> <20000728101015.A6542@ActiveState.com> Message-ID: <3981CD20.BD53BFF0@lemburg.com> Trent Mick wrote: > > On Fri, Jul 28, 2000 at 12:21:08PM +0200, M . -A . Lemburg wrote: > > > > > > IIRC ActiveState contributed to Perl a version of fork that works on > > > Win32. Has anyone looked at this? Could it be grabbed for Python? This would > > > help heal one of the more difficult platform rifts. Emulating fork for Win32 > > > looks quite difficult to me but if its already done... > > > > This would indeed be a *very* useful addition and help porting > > os.fork() applications to Win32. (Ok, in the long run they would > > have to be converted to multi-threaded apps due to the process > > creation overhead on Win32, but for short term porting to Win32 > > this would be a Cool Thing, IMHO.) > > > > Can this code be grabbed from somewhere ? > > > > It is all in ActivePerl. You can download the source code: > > http://www.activestate.com/Products/ActivePerl/Download.html Thanks. > Besides, I would guess (and I *am* guessing, I don't know this) that the Perl > fork stuff is fairly closely tied to Perl, i.e. it may not be easy at all to > yank it out and plug it into Python. > > However, I echo the Bill's and Guido's sentiments. Having a hacked > emulation of fork encourages people to use it. Once someone has their > favorite UNIX app it running on Win32 with the fake-fork they will have > little incentive to port it properly using threads. There will then be calls > to improve to Win32 fork implementation... and that is the wrong support > path. You're probably right... :-/ BTW, (pardon my ignorance) what is the most portable way to do the equivalent of a os.system("cmd &") as native OS API call ? [On Unix, "cmd &" starts a new process which runs in the background and detached from the calling process.] I've looked at .execve and .spawnve, but they both replace the current process. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> <20000728101015.A6542@ActiveState.com> <3981CD20.BD53BFF0@lemburg.com> Message-ID: <008d01bff8c2$5c99f240$f2a6b5d4@hagrid> mal wrote: > BTW, (pardon my ignorance) what is the most portable way to > do the equivalent of a os.system("cmd &") as native OS > API call ? [On Unix, "cmd &" starts a new process which runs > in the background and detached from the calling process.] >=20 > I've looked at .execve and .spawnve, but they both replace > the current process. on windows, spawn(P_NOWAIT) does what you want. here's an example from the eff-bot guide: # # os-spawn-example-2.py import os import string def run(program, *args, **kw): # find executable mode =3D kw.get("mode", os.P_WAIT) for path in string.split(os.environ["PATH"], os.pathsep): file =3D os.path.join(path, program) + ".exe" try: return os.spawnv(mode, file, (file,) + args) except os.error: pass raise os.error, "cannot find executable" run("python", "hello.py", mode=3Dos.P_NOWAIT) From Vladimir.Marangozov@inrialpes.fr Fri Jul 28 20:24:36 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 21:24:36 +0200 (CEST) Subject: [Python-Dev] further optimising the micro-optimisations for cache locality (fwd) Message-ID: <200007281924.VAA06918@python.inrialpes.fr> FYI. It would be interesting to collect some feedback on these ideas for popular combos. Who knows... Forwarded message: > From morton@dennisinter.com Fri Jul 28 20:48:29 2000 > From: morton@dennisinter.com (Damien Morton) > To: > Subject: further optimising the micro-optimisations for cache locality > Date: Fri, 28 Jul 2000 14:34:29 -0400 > Message-ID: > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > Importance: Normal > > Folded version: > > case BINARY_ADD: > w = POP(); > v = POP(); > x = PyNumber_Add(v, w); > goto end_binop; > > case BINARY_MULTIPLY: > w = POP(); > v = POP(); > x = PyNumber_Multiply(v, w); > goto end_binop; > > ... > end_binop: > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > > Further folded version: > > > > case BINARY_POWER: > f = PyNumber_Add; > goto do_binop; > > case BINARY_MULTIPLY: > f = PyNumber_Multiply; > goto do_binop; > > ... > do_binop: > w = POP(); > v = POP(); > x = f(v, w); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > > Further Further folded version: > (i havent looked at the mainloop code, but can guess its structure) > > i assume 'op' is the opcode we are swtching on > > // the function to call for this op > (void *)() op_func[] = { ..., PyNumber_Add, PyNumber_Multiply, ... }; > > // the kind of op this func describes > unsigned char op_type[] = { ..., DO_BINOP1, DO_BINOP2, DO_UNOP, ... }; > > // these two tables will be cached because of the frequency the are accessed > // ive used a table of pointers and a table of bytes to reduce the memory > required > // because the tables are small, locality within and between the tables isnt > important > // might be an idea to force the tables into contiguous memory somehow > // i could also have used a table of structs, but alignment would increase > memory usage > > unsigned char op; > > switch(op_type[op]) { > case DO_BINOP1: > w = POP(); > v = POP(); > x = op_func[op](v, w); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > case DO_BINOP2: > w = POP(); > v = POP(); > x = op_func[op](v, w, Py_None); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > case DO_UNOP: > v = POP(); > x = op_func[op](v); > Py_DECREF(v); > PUSH(x); > if (x != NULL) continue; > break; > > ===================== original message ================================= > Guido van Rossum wrote: > > > > > [me, on micro-optimizing the main loop] > > > > Fair enough (for one particular CPU at least). > > Since we're at it, it's worth mentioning another conclusion we came across > at the time: the cache effects in the main loop are significant -- it is > more important to try keeping at best the main loop small enough, so that > those effects are minimized. > > An experiment I did at the time which gave some delta-speedup: > I folded most of the UNOP & BINOP opcodes since they differ only by the > functon they call and they duplicate most of the opcode body. Like this: > > Original: > case BINARY_POWER: > w = POP(); > v = POP(); > x = PyNumber_Power(v, w, Py_None); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > > case BINARY_MULTIPLY: > w = POP(); > v = POP(); > x = PyNumber_Multiply(v, w); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > ... > > > Folded version: > > case BINARY_POWER: > w = POP(); > v = POP(); > x = PyNumber_Power(v, w, Py_None); > goto end_binop; > > case BINARY_MULTIPLY: > w = POP(); > v = POP(); > x = PyNumber_Multiply(v, w); > goto end_binop; > > ... > end_binop: > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > > > This reduced the code size of ceval.c, which resulted in less cache effects > and gave more speed, despite the additional jumps. It possibly results in > less page-faults too, although this is unlikely. > > Which makes me think that, if we want to do something about cache effects, > it is probably not a bad idea to just "reorder" the bytecodes in the big > switch by decreasing frequency (we have some stats about this -- I believe > Skip and MAL have discussed the opcodes' frequency and the charts lie > somewhere in the archives). I remember Marc-Andre had done something in > this direction and reported some perf improvements too. Since reordering > the opcodes doesn't really hurt, if I'm about to do something with the > main loop, it'll be only this. > > > > > > Micro-optimization doesn't worth the effort. As to the 2-byte arg limit, > > > I think I'd be happy if the compiler raises an exception if this limit > > > is exceeded. > > > > That would be a good first step indeed! > > I'll try to have a look, if someone else is not more reactive than me. > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 > -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas@xs4all.net Fri Jul 28 20:41:54 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 21:41:54 +0200 Subject: [Python-Dev] further optimising the micro-optimisations for cache locality (fwd) In-Reply-To: <200007281924.VAA06918@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Fri, Jul 28, 2000 at 09:24:36PM +0200 References: <200007281924.VAA06918@python.inrialpes.fr> Message-ID: <20000728214154.G266@xs4all.nl> On Fri, Jul 28, 2000 at 09:24:36PM +0200, Vladimir Marangozov wrote: > It would be interesting to collect some feedback on these ideas for > popular combos. Who knows... I like these ideas, though I think anything beyond 'further folded' requires a seperate switch for the non-common operators and those that do a tad more than call a function with a certain number of arguments and push the result on the stack. Re-numbering the ops into fast-ops and slow-ops, as well as argument-ops and nonargument-ops. (I hope all non-argument ops fall in the 'fast' category, or it might get tricky ;-P) I'm also wondering whether they really speed things up. The confusion might force the compiler to generate *less* efficient code. Then again, it removes some of the burden from the compiler, too, so it probably depends very heavily on the compiler whether this is going to have a positive effect. > > // the function to call for this op > > (void *)() op_func[] = { ..., PyNumber_Add, PyNumber_Multiply, ... }; > > > > // the kind of op this func describes > > unsigned char op_type[] = { ..., DO_BINOP1, DO_BINOP2, DO_UNOP, ... }; > > > > // these two tables will be cached because of the frequency the are > > // accessed > > // ive used a table of pointers and a table of bytes to reduce the > > // memory required because the tables are small, locality within and > > // between the tables isnt important > > // might be an idea to force the tables into contiguous memory somehow > > // i could also have used a table of structs, but alignment would > > // increase memory usage I'm not so sure about any of these comments, given that we do jump to a function right after accessing these tables. I suggest heavy testing, and I can offer only two architectures myself (linux-i386 and solaris-sparc-gcc.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From trentm@activestate.com Fri Jul 28 21:02:07 2000 From: trentm@activestate.com (Trent Mick) Date: Fri, 28 Jul 2000 13:02:07 -0700 Subject: [Python-Dev] build problems under MSVC 5.0 In-Reply-To: <019e01bfe1ec$728c6c00$f2a6b5d4@hagrid> References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> <20000629095343.B21926@activestate.com> <019e01bfe1ec$728c6c00$f2a6b5d4@hagrid> Message-ID: <20000728130207.A7348@ActiveState.com> On Thu, Jun 29, 2000 at 07:07:02PM +0200, Fredrik Lundh wrote: > trent wrote: > > I think (am I wrong?) to generalize that the intention for both Win32 and > > Win64 is to have _beginthread return an unsigned pointer-sized integer: hence > > uintptr_t. > > > > This would eliminate the #ifdef but would require a typedef for uintptr_t on > > Win32. This can be done in PC/config.h (I already did this for intptr_t, > > because I needed *that* elsewhere.) Does this also need to be generalized to > > typedef uintptr_t whereever it is not defined, i.e. in the autoconf files. > > > > I can look at this this weekend, if that is soon enough. > > I suggest checking in the #ifdef as a stopgap measure, if you > promise to come up with the right thing (whatever that is) in > time for 1.6 final. > > Should I go ahead and check it in? > Fredrik, I have put the "right thing" (I hope) up on SourceForge and assigned it to you: http://sourceforge.net/patch/?func=detailpatch&patch_id=101010&group_id=5470 I explained what I think is the right idea in the preceeding email in this thread: http://www.python.org/pipermail/python-dev/2000-June/011800.html Could you try the patch and then assign it back to me for check in? (Or just check it in yourself) Thanks, Trent -- Trent Mick TrentM@ActiveState.com From Vladimir.Marangozov@inrialpes.fr Fri Jul 28 21:20:02 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 22:20:02 +0200 (CEST) Subject: [Python-Dev] further optimising the micro-optimisations for cache locality (fwd) In-Reply-To: <20000728214154.G266@xs4all.nl> from "Thomas Wouters" at Jul 28, 2000 09:41:54 PM Message-ID: <200007282020.WAA07138@python.inrialpes.fr> Thomas Wouters wrote: > > On Fri, Jul 28, 2000 at 09:24:36PM +0200, Vladimir Marangozov wrote: > > > It would be interesting to collect some feedback on these ideas for > > popular combos. Who knows... > > I like these ideas, though I think anything beyond 'further folded' requires > a seperate switch for the non-common operators and those that do a tad more > than call a function with a certain number of arguments and push the result > on the stack. I agree. Note that all we can get though this game is some dubious percents that we shouldn't ignore, but which persistency in the long term is quite questionable. There's no way that, to pick a guy at random, Tim won't confirm this! And just like Guido, I'm not ready to trade code cleanliness for dubious speed. However, I take the opportunity to invite you again to "heavy test" the object allocator's candidate -- obmalloc.c, which, in my educated understanding of the current C implementation is the only piece of code that is capable of increasing Python's overall performance by > 10% assuming that your script involves object allocations. It is my strong belief that this perfomance comes for free, by instrumenting Python at its most inner internals, not on top of it! Of course, improvements to this code are welcome and I'd be happy to discuss them in this forum. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mwh21@cam.ac.uk Fri Jul 28 21:58:11 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 28 Jul 2000 21:58:11 +0100 Subject: [Python-Dev] extended slicing for lists In-Reply-To: Michael Hudson's message of "27 Jul 2000 21:41:02 +0100" References: <200007271412.JAA12251@cj20424-a.reston1.va.home.com> Message-ID: Michael Hudson writes: > Guido van Rossum writes: > > > > Good idea. Are lists and tuples going to support seq[a:b:c] anytime > > > soon? > > > > It's on my wish list, but can't be done for 2.0. > > This would involve the list type implementing the mapping API wouldn't > it? This would seem to be a little on the silly side. Never mind; > here's a quick-hack patch that "seems to work" for lists: [snip] I've now put this (or a slightly less buggy version) onto sourceforge. Guido said (after I bothered him in private email) that he'd expect that: >>> l = range(10) >>> l[2:10:2] = [0]*5 >>> l [0, 1, 0, 3, 0, 5, 0, 7, 0, 9] >>> And also: >>> l = range(10) >>> l[4:-1:-1] = range(5) >>> l [4, 3, 2, 1, 0, 5, 6, 7, 8, 9] >>> (and presumably del l[a:b:c]) Now I'd expect *that* as well, but I was wondering what should happen if the lengths of the lists don't match up ... just bail? That would be easiest, but it doesn't quite gel well with current behaviour for simple slices. Presuming an error, what about these (assuming d is a list of the wrong length): l[a:b:-1] = d l[a:b:1] = d l[a:b:] = d I think these should probably be errors too, but I'd welcome any opinions people have. Cheers, M. -- A witty saying proves nothing. -- Voltaire From bwarsaw@beopen.com Fri Jul 28 22:24:57 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 28 Jul 2000 17:24:57 -0400 (EDT) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> Message-ID: <14721.64041.139313.716754@anthem.concentric.net> >>>>> "M" == M writes: M> These stats were created using an instrumented Python M> interpreter running real applications (and recording all M> executed opcodes to a file), so they can be considered close M> enough to what Python typically does in its inner loop. M> If you need help, I can dig up those old tools and patches... If you can update them for the current CVS, I'd suggest uploading them to SF. I'd then be willing to run Mailman for a while on an instrumented Python to see what it does. -Barry From guido@beopen.com Sat Jul 29 03:02:38 2000 From: guido@beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 21:02:38 -0500 Subject: [Python-Dev] Python License News Message-ID: <200007290202.VAA05626@cj20424-a.reston1.va.home.com> Bob Weiner (BeOpen's CTO, my boss) told me that he's very close to reaching a compromise with CNRI about the new Python license. There's only one remaining issue before Richard Stallman is willing to declare the license GPL-compatible. We expect that this wrinkle will be worked out with CNRI's president Bob Kahn on Monday. Tim Peters knows more, you just have to ask the right way. :-) Gotta run, --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From mhammond@skippinet.com.au Sat Jul 29 04:07:38 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sat, 29 Jul 2000 13:07:38 +1000 Subject: [Python-Dev] Python License News In-Reply-To: <200007290202.VAA05626@cj20424-a.reston1.va.home.com> Message-ID: [Trimmed to list for the sake of Tim's modesty] > Tim Peters knows more, you just have to ask the right way. :-) Tim - tell us about your testicles again! Is-that-correct-ly, Mark. From fdrake@beopen.com Sat Jul 29 05:05:17 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 29 Jul 2000 00:05:17 -0400 (EDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <20000728104223.G14644@thyrsus.com> References: <20000727173859.A10337@thyrsus.com> <20000728083419.B10938@newcnri.cnri.reston.va.us> <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> <20000728104223.G14644@thyrsus.com> Message-ID: <14722.22525.140359.615231@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Ah! I didn't realize multiple suggestions could live in the same file > under our conventions. Guess I'll have to go reread the Documentation > HOWTO. Multiple sections can live in the same file if they are sufficiently tightly related. For example, curses and curses.ascii, pyexpat and pyexpat.errors, pickle and cPickle, StringIO and cStringIO. I don't know that this is discussed in "Documenting Python," but should be; I'll fix that for Python 2.0. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Sat Jul 29 07:14:18 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 29 Jul 2000 02:14:18 -0400 Subject: [Python-Dev] Python License News In-Reply-To: Message-ID: [Guido] > Tim Peters knows more, you just have to ask the right way. :-) [Mark Hammond] > Tim - tell us about your testicles again! > > Is-that-correct-ly, Works for me. I had thought they were permanently enlarged, but I detect signs that, should the temperature in Virginia ever fall below 80F, and the relative humidity below a gazillion or two percent, they may return to a familiar state. I grew up in a cold climate, and this may just be a bizarre attempt to shed excess heat. I expect to set up a home page soon with a charming and practical photographic essay on this topic . As to the Python license, Guido said > We expect that this wrinkle will be worked out with CNRI's > president Bob Kahn on Monday. and given the history of this I'd rather wait until then to see whether expectations pan out -- and discussing the license before we're allowed to *show* it would be frustrating for everyone anyway. That said, this is certainly a harder license for a non-lawyer to understand than was the CWI license, but I expect CNRI would counter that their license is more likely than CWI's to stand up in court. If such things interest you, feel free to speculate . Some things *everyone* should agree are good: + Eric Raymond informed us that the board of the Open Source Initiative had voted to certify the license as fully Open Source compliant. http://www.opensource.org/osd.html That was a happy day! But it's already become a slightly different license than they voted on, so I bet we have to seek OSI certification again. + I've seen Richard Stallman's remaining objections, and they're of a technical nature (meaning that to BeOpen PythonLabs they don't seem like they *should* be a sticking point; but CNRI may not agree). As many dozens of current Python projects rely on GPL compatibility, BeOpen will not accept a license that RMS rejects (and, I'll add, he's made the *reasons* for his objections clear, and has gone the extra mile to suggest specific changes). + My previous employers used Python in proprietary ("closed source") ways, and I *believe* the proposed license still allows that. But there are new (relative to the CWI Python license) requirements, and I don't understand what some of the license text means, so don't take my guess on that! Anyone who intends using Python 1.6 or beyond in proprietary ways would be well advised to have their lawyers study the license carefully, as no party to this negotiation was in your shoes or visibly (to me) looking out for you. (And, no, I was not a party to any of it) + There is still no clause specifically prohibiting ActiveState from using Python . Or anyone else. ordered-the-champagne-but-not-drinking-it-yet-ly y'rs - tim From ping@lfw.org Sat Jul 29 07:57:22 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Fri, 28 Jul 2000 23:57:22 -0700 (PDT) Subject: [Python-Dev] extended slicing for lists In-Reply-To: Message-ID: On 28 Jul 2000, Michael Hudson wrote: > >>> l = range(10) > >>> l[2:10:2] = [0]*5 > >>> l > [0, 1, 0, 3, 0, 5, 0, 7, 0, 9] > >>> Hmph. I'd be perfectly comfortable with >>> l[2:10:2] = [0]*5 TypeError: lists cannot assign to stepped slices I can't see this being a commonly desired feature. If it were perfectly clear what should happen in all cases, i'd be okay with it -- but the ambiguity you get when the length of the right side doesn't match the length of the indicated slice is sufficient for me to suggest just dropping it: better to avoid confusion altogether. > (and presumably del l[a:b:c]) That seems reasonable and well-defined. A separate question: does l[::-1] return l reversed? That is, are the defaults for omitted start/end exchanged if step is negative? This would seem to be quite useful -- having to say l[len(l)-1:-1:-1] would be a royal pain. -- ?!ng From Moshe Zadka Sat Jul 29 07:51:21 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 29 Jul 2000 09:51:21 +0300 (IDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <14722.22525.140359.615231@cj42289-a.reston1.va.home.com> Message-ID: On Sat, 29 Jul 2000, Fred L. Drake, Jr. wrote: > > Eric S. Raymond writes: > > Ah! I didn't realize multiple suggestions could live in the same file > > under our conventions. Guess I'll have to go reread the Documentation > > HOWTO. > > Multiple sections can live in the same file if they are sufficiently > tightly related. For example, curses and curses.ascii, pyexpat and > pyexpat.errors, pickle and cPickle, StringIO and cStringIO. > I don't know that this is discussed in "Documenting Python," but > should be; I'll fix that for Python 2.0. Let me just say what Fred said in a different way: from the processing engine POV, there's just *one file* with lots of include directives. The division into file is just to make life easier for us -- so if two sections are related, it's easier to keep them in the same file. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From Fredrik Lundh" Message-ID: <002401bff930$8439f340$f2a6b5d4@hagrid> is it worth replacing a couple of lines of obvious code with a reference to a little-used module? and if I want to, how do I tweak the block size? > *** SimpleHTTPServer.py 2000/05/21 16:25:29 1.10 > --- SimpleHTTPServer.py 2000/07/29 05:15:56 1.11 > *************** > *** 16,19 **** > --- 16,20 ---- > import urllib > import cgi > + import shutil > from StringIO import StringIO > =20 > *************** > *** 152,161 **** > =20 > """ > !=20 > ! BLOCKSIZE =3D 8192 > ! while 1: > ! data =3D source.read(BLOCKSIZE) > ! if not data: break > ! outputfile.write(data) > =20 > def guess_type(self, path): > --- 153,157 ---- > =20 > """ > ! shutil.copyfileobj(source, outputfile) > =20 > def guess_type(self, path): >=20 >=20 > _______________________________________________ > Python-checkins mailing list > Python-checkins@python.org > http://www.python.org/mailman/listinfo/python-checkins From Moshe Zadka Sat Jul 29 08:51:00 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 29 Jul 2000 10:51:00 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib SimpleHTTPServer.py,1.10,1.11 In-Reply-To: <002401bff930$8439f340$f2a6b5d4@hagrid> Message-ID: On Sat, 29 Jul 2000, Fredrik Lundh wrote: > is it worth replacing a couple of lines of obvious code > with a reference to a little-used module? I believe so. So did everyone when the thread came up on Python-Dev a couple of weeks ago -- I haven't followed up with the checkin for so long because of technical problems (AKA lack of computer). > and if I want to, how do I tweak the block size? Just like you would in the old days: subclass SimpleHTTPServer, and substitute the copyfile method with a call to shutil.copyfile with a non-default size. (IOW, it's easier then what it was before). From mwh21@cam.ac.uk Sat Jul 29 10:07:43 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 29 Jul 2000 10:07:43 +0100 Subject: [Python-Dev] extended slicing for lists In-Reply-To: Ka-Ping Yee's message of "Fri, 28 Jul 2000 23:57:22 -0700 (PDT)" References: Message-ID: The patch is here, btw: http://sourceforge.net/patch/?func=detailpatch&patch_id=100998&group_id=5470 Ka-Ping Yee writes: > On 28 Jul 2000, Michael Hudson wrote: > > >>> l = range(10) > > >>> l[2:10:2] = [0]*5 > > >>> l > > [0, 1, 0, 3, 0, 5, 0, 7, 0, 9] > > >>> > > Hmph. I'd be perfectly comfortable with > > >>> l[2:10:2] = [0]*5 > TypeError: lists cannot assign to stepped slices > > I can't see this being a commonly desired feature. If it > were perfectly clear what should happen in all cases, i'd > be okay with it -- but the ambiguity you get when the length > of the right side doesn't match the length of the indicated > slice is sufficient for me to suggest just dropping it: > better to avoid confusion altogether. Well, the BDFL spoke. > > (and presumably del l[a:b:c]) > > That seems reasonable and well-defined. Yes. > A separate question: does l[::-1] return l reversed? Yes. All that cleverness is in PySlice_GetIndices, so this patch gets it for free. > That is, are the defaults for omitted start/end exchanged if step is > negative? This would seem to be quite useful -- having to say > l[len(l)-1:-1:-1] would be a royal pain. Well, you could probably always say l[sys.maxint:0:-1] (your example returns the empty list!) but yes, I think l[::-1] is one of the neater bits of new behaviour. Cheers, M. -- "declare"? my bogometer indicates that you're really programming in some other language and trying to force Common Lisp into your mindset. this won't work. -- Erik Naggum, comp.lang.lisp From Moshe Zadka Sat Jul 29 11:17:14 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 29 Jul 2000 13:17:14 +0300 (IDT) Subject: [Python-Dev] test turds? Message-ID: Hi! Recently I patched a bug in whichdb. Following Tim's advice "each bug we find is a bug in the regression testing", I decided to write a test case for whichdb. However, the problem is that I'm not sure where I can create files, which must not be leftovers from the test suite. Does anyone know of a test which creates files, and how it deals with them? Thanks. awake-when-it's-night-in-*civilized*-places-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mwh21@cam.ac.uk Sat Jul 29 11:41:30 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 29 Jul 2000 11:41:30 +0100 Subject: [Python-Dev] extended slicing for lists In-Reply-To: Michael Hudson's message of "29 Jul 2000 10:07:43 +0100" References: Message-ID: Michael Hudson writes: > The patch is here, btw: > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100998&group_id=5470 And has now been updated to support assignments & deletions. I'm happy with deletions, but assignments seem to be a bit counter-intuitive - for example both of Guido's examples: >>> l = range(10) >>> l[2:10:2] = [0]*5 >>> l [0, 1, 0, 3, 0, 5, 0, 7, 0, 9] >>> l = range(10) >>> l[4:-1:-1] = range(5) >>> l [4, 3, 2, 1, 0, 5, 6, 7, 8, 9] are wrong! >>> l[2:10:2] = [0]*5 Traceback (most recent call last): File "", line 1, in ? ValueError: attempt to assign list of size 5 to extended slice of size 4 >>> l[4:-1:-1] = range(5) Traceback (most recent call last): File "", line 1, in ? ValueError: attempt to assign list of size 5 to extended slice of size 0 So I'd really appreciate it if people could play around with the patch and see if (a) they can break it (b) they like the way assignments behave (I am already hooked on the indexing & deletion). now-all-we-need-is-a-slice-expression-for-sorting-ly y'rs M. -- 59. In English every word can be verbed. Would that it were so in our programming languages. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html From mhammond@skippinet.com.au Sat Jul 29 14:13:57 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sat, 29 Jul 2000 23:13:57 +1000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/LibSimpleHTTPServer.py,1.10,1.11 In-Reply-To: Message-ID: > > and if I want to, how do I tweak the block size? [Moshe] > Just like you would in the old days: subclass SimpleHTTPServer, and > substitute the copyfile method with a call to shutil.copyfile with a > non-default size. (IOW, it's easier then what it was before). I think thats a little of an overkill. It requires duplicating the entire method for the sake of one constant. def copyfile(self, source, outputfile): BLOCKSIZE = 8192 to def copyfile(self, source, outputfile, blocksize = 8192): is much more reasonable IMO. Mark. From Moshe Zadka Sat Jul 29 14:26:06 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 29 Jul 2000 16:26:06 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/LibSimpleHTTPServer.py,1.10,1.11 In-Reply-To: Message-ID: On Sat, 29 Jul 2000, Mark Hammond wrote: > and if I want to, how do I tweak the block size? [Moshe] > Just like you would in the old days: subclass SimpleHTTPServer, and > substitute the copyfile method with a call to shutil.copyfile with a > non-default size. (IOW, it's easier then what it was before). [Mark] > I think thats a little of an overkill. It requires duplicating the entire > method for the sake of one constant. But Mark, the "entire method" is simply a call to shutil.copyfileobj (well, that and a docstring). So "duplicating" it is the only thing possible, unless you want to define a class variable "BLOCKSIZE". It can be supported without duplicating the functionality of shutil.copyfileobj, but that sure sounds like an overkill.... -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mhammond@skippinet.com.au Sat Jul 29 14:37:45 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sat, 29 Jul 2000 23:37:45 +1000 Subject: [Python-Dev] Re: [Python-checkins] CVS:python/dist/src/LibSimpleHTTPServer.py,1.10,1.11 In-Reply-To: Message-ID: > But Mark, the "entire method" is simply a call to shutil.copyfileobj OK - I looked at it before I updated CVS! Oops :-) > unless you want to define a class variable "BLOCKSIZE". It can > be supported without duplicating the functionality of shutil.copyfileobj, > but that sure sounds like an overkill.... Huh? Well, shutil.copyfileobj appears to have a "length" param, which is exactly what was being asked for (although possibly a poor choice of a name!). It is still more resonable to add a default param than to require a subclass. The shutil author clearly thought so! Mark. From Moshe Zadka Sat Jul 29 14:52:36 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 29 Jul 2000 16:52:36 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS:python/dist/src/LibSimpleHTTPServer.py,1.10,1.11 In-Reply-To: Message-ID: On Sat, 29 Jul 2000, Mark Hammond wrote: [About SimpleHTTPServer.copyfile always using the default block-size] > It is still more resonable to add a default param than to require a > subclass. The shutil author clearly thought so! Ani Zatar! I'm the shutil.copyfileobj function author, and the circumstances are different. SimpleHTTPServer.copyfile is called by the methods which are not overridable (in the sense of overriding them being supported), so there is no sense in adding a default parameter -- you need to have something persistent in the class for that: and that is either a variable or method. PS. The "Ani Zatar" part is in case some Israeli reads the archive: it's a non-funny joke in Hebrew, and I won't translate it. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mmorris@pop.mindspring.com Sat Jul 29 07:19:59 2000 From: mmorris@pop.mindspring.com (Mitchell Morris) Date: Fri, 28 Jul 2000 23:19:59 -0700 Subject: [Python-Dev] Fire, may I present accellerant. Accellerant, this is fire. Message-ID: <20000729061933.LUNZ24904.mail.rdc1.wa.home.com@finin> In general I try to keep my head down. I recently needed some support for regression testing as part of a stealth Python introduction-cum-advocacy effort. I wound up using Steve Purcell's pyunit testing framework, and thought it was a shame that it wasn't part of the standard distribution. To that end ... PEP: eric-the-half-a-pep Title: Guido-blessed unit/regression test framework Version: 0 Target of Opportunity: mmorris@mindspring.com (Mitchell Morris) Python-Version: 2.0 Status: pre-pre-pre-Draft Introduction This proto-PEP advocates that there should be, in the standard library, a unit/regression test framework. This Guido-blessed framework would provide test semantics both useful and standardized. In addition to being a useful structure in it's own right, it would provide an obvious direction for development projects to prepare and use their own regression test policies. Why Should I Care? Software developers have known for quite some time that the majority of our time is spent identifying and correcting errors. Various suggestions for reducing this burden have been explored and most of them have been rejected. One thing that seems to provide some benefit is writing test plans and running them against the software product. This doesn't necessarily eliminate bugs, but it does allow us to find some of them and insure they don't reoccur as we correct later ones. One variation of this process is to extend the test plan as other defects are identified and corrected. Part of the correction would be updating the test suite to include a test that would have identified and exercised the defect. In this way the test plan grows to verify that correct behavior increases monotonically. This kind of test plan also allows very aggressive refactoring, in that the developer can make sweeping changes to module internals with great confidence that things will either (a) not break elsewhere, or (b) break loudly when the unit tests fail. Given the (relative) success of test plans and Python's general friendliness to rapid development and refactoring, there should be a standard tool in all distributions to encourage this dynamic. But ... Smalltalk and Java are Evil! Kent Beck has recently generated a lot of press by writing about his development methodology which he calls "Extreme Programming"[1]. Aside from the unfortunate connotations to sports which would still be completely anonymous without ESPN2, there are a number of useful tools emerging from the XP camp. One of the prime tenets is that developers write their classes and their unit tests at the same time. According to XP, these unit tests have to run at 100% for the code to be acceptable for integration. The design of the testing framework generated by XP is fairly simple: individual tests check the correct functionality of a single quantum of testable behavior, usually public behavior. These individual tests can be aggregated into suites, which are also runnable. Suites can be aggregated as well. Tools are provided to execute these tests and suites in both text and GUI formats. Kent Beck and Erich Gamma wrote a paper called "Test Infected"[2] to demonstrate how the code and tests are developed in tandem. This paper, written as a script for a pair programming session, shows how the various pieces of the JUnit implementation work together. (JUnit is the XP testing tool for Java.) We've Already Got One, Thanks. The current distribution has a regression testing framework, in Lib/test/regrtest.py, which addresses some of these same issues. The obvious question is why not use the tool which is already there? The current tool presents several issues that make this a less-than-exemplary solution: it doesn't allow for graphical manipulation, it separates test and expected result into separate files stored in separate locations, and it tries to generate the tests as well as run them. The objections to regrtest.py then boil down to the it's philosophy. We've Got More Than We Can Stand, Thanks. Really. Also for our consideration is doctest.py, contributed by the inestimable Tim Peters. doctest.py presents a simple straightforward means to embed the individual tests into the production code itself as commentary. This suggests that the separation of test and result presents a cognitive dissonance in other people besides just me. doctest.py doesn't provide any mechanism, however, for aggregating several modules into a single test run, nor does it provide a GUI. Once again, additional effort could obviously provide the missing functionality. On the other hand, doctest.py isn't currently part of the standard distribution. What's All This Then? The point of this proposal is Steve Purcell's pyunit package[3]. This is a Python implementation of XP's xUnit specification. It provides a means for running individual tests, aggregating individual tests into larger suites, running those tests in both text and GUI modes, and keeps the tests and expected results together in a single source module. You Have A Point? Yes: pyunit should be part of the standard library. pyunit documentation should be included in the distribution. New development should be encouraged to use pyunit. We should all rub pyunit all over our bodies as often as we can. Even if it isn't pyunit, Python should have a documented standard component for unit and regression testing, and we should encourage new development to use it, and we should demand that core development include it. References 1 -- XP Wiki see also: 2 -- Beck, Kent and Gamma, Erich, "Test Infected" 3 -- pyunit project at Source Forge pyromanically y'rs +Mitchell From guido@python.org Sat Jul 29 18:39:01 2000 From: guido@python.org (Guido van Rossum) Date: Sat, 29 Jul 2000 12:39:01 -0500 Subject: [Python-Dev] Bookstand at LA Python conference Message-ID: <200007291739.MAA06848@cj20424-a.reston1.va.home.com> The next Python conference will be in Long Beach (Los Angeles). We're looking for a bookstore to set up a bookstand like we had at the last conference. Does anybody have a suggestion? See http://www.python9.com for conference info! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Sat Jul 29 19:04:41 2000 From: guido@beopen.com (Guido van Rossum) Date: Sat, 29 Jul 2000 13:04:41 -0500 Subject: [Python-Dev] Should repr() of string should observe locale? Message-ID: <200007291804.NAA07155@cj20424-a.reston1.va.home.com> There have been some requests (Francois Pinard, recently Alexander Voinov) that repr() of a string should not use escape sequences for characters that are printable according to the locale. I don't have the time to write a PEP or implement it (although it should be simple enough) but it needs to be recorded as a feature that I think is good (that's at least a +0). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Moshe Zadka Sat Jul 29 18:08:58 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 29 Jul 2000 20:08:58 +0300 (IDT) Subject: [Python-Dev] Should repr() of string should observe locale? In-Reply-To: <200007291804.NAA07155@cj20424-a.reston1.va.home.com> Message-ID: On Sat, 29 Jul 2000, Guido van Rossum wrote: > There have been some requests (Francois Pinard, recently Alexander > Voinov) that repr() of a string should not use escape sequences for > characters that are printable according to the locale. > > I don't have the time to write a PEP or implement it (although it > should be simple enough) but it needs to be recorded as a feature that > I think is good (that's at least a +0). I don't. Most people who are requesting it are requesting it for the purpose of the interactive Python session. I think there is general agreement that there should be a way to better control the REPL from Python (my, now lost, sys.display patch, for example). Wouldn't that solve the problem? -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From fdrake@beopen.com Sat Jul 29 20:01:52 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 29 Jul 2000 15:01:52 -0400 (EDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: References: <14722.22525.140359.615231@cj42289-a.reston1.va.home.com> Message-ID: <14723.10784.479056.30153@cj42289-a.reston1.va.home.com> Moshe Zadka writes: > Let me just say what Fred said in a different way: from the processing > engine POV, there's just *one file* with lots of include directives. > The division into file is just to make life easier for us -- so if > two sections are related, it's easier to keep them in the same file. Almost, but not quite. The division into files allows us to reorganize the sections into chapters differently with simple edits; I've found that very useful a couple of times! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From klm@digicool.com Sat Jul 29 20:53:17 2000 From: klm@digicool.com (Ken Manheimer) Date: Sat, 29 Jul 2000 15:53:17 -0400 (EDT) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <200007281701.TAA06630@python.inrialpes.fr> Message-ID: On Fri, 28 Jul 2000 Vladimir.Marangozov@inrialpes.fr wrote: > M.-A. Lemburg wrote: > > > > Separating out LOAD_FAST from the switch shows a nice effect. > > SET_LINENO is removed by -OO anyway, so there's really no > > use in optimizing this one. > > Actually, I think that instead of fighting with SET_LINENO > for the standard setup, it would make sense to change the > invocation options to something more standard: > > 1) python - code without SET_LINENO > 2) python -g - code for debugging, with SET_LINENO > 3) python -O - code without doc-strings. > > The point is that currently there's no optimization of the > code stream at all, in the sense of classic compiler optimization > (code block-level optimizations, loop unrolling, etc). > > And SET_LINENO is actually useful only for debugging (with pdb, etc). > > What about this as a sane proposal for SET_LINENO? I would be firmly -1 on this proposal. Without a major payoff - say, double or better performance improvements - i think it's a bad idea to disable debugging in the common case. Python already has -o and -oo - aren't they sufficient? (Maybe i'm misremembering, but i recall that removing SET_LINENO didn't yield a whole lot of performance improvement. Actually, i have the impression it's been a canonical example of how casual optimizations don't do what you expect - but i may be off base here.) I see the ability to debug at whim, even when you didn't expect having to do so, as being a major win, part of the incremental development process. For me, it's a virtue up there with "having the source" in making it easier to fix my own and other people's mistakes. (The inconvenience of having to rerun with debugging enabled is magnified greatly when dealing with connecting to longrunning processes, as i tend to do with zope under zeo and medusa. Then i'm really screwed if someone forgot to start with optional debugging enabled.) If you can replace SET_LINENO's functionality with something that doesn't have the same overhead, great! I have the impression from your recent comments along these lines that that isn't happening immediately... Ken klm@digicool.com From akuchlin@mems-exchange.org Sat Jul 29 21:34:57 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat, 29 Jul 2000 16:34:57 -0400 Subject: [Python-Dev] SF most active project listing Message-ID: I was curious about how "most active project" is defined, and took a look at the SF code. It's computed by the util/db_project_weekly_metric.pl script, which sums up a bunch of parameters to get a number. The parameters are: 3 * # of forum postings 4 * # of tasks 3 * # of bugs 10 * # of patches 5 * # of support 1 * # of CVS commits 5 * # of developers 5 * # of file releases .3 * # of downloads All of these numbers seem to be counted over the past week. I suspect the code has a mathematical bug: the queries use, for example, log(4*count(project_task.project_task_id)) for counting things. However, IIRC, log ab = log a + log b, so the multipliers just add a constant to every project's number, and therefore it's a flat sum of all the parameters. IMHO that should be 4*log(count(....)), and will report it. --amk From tim_one@email.msn.com Sat Jul 29 21:05:14 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 29 Jul 2000 16:05:14 -0400 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: Message-ID: [Ken Manheimer] > ... > (Maybe i'm misremembering, but i recall that removing SET_LINENO > didn't yield a whole lot of performance improvement. That's correct, it's rarely more than just a few percent. > Actually, i have the impression it's been a canonical example of > how casual optimizations don't do what you expect - but i may be > off base here.) Well, it did what *I* expected . There are the "state lottery" and "penny saved is a penny earned" schools of optimization. They appeal, respectively, to "no guts, no glory" and "slow and steady wins the race" types. Both are valuable, although the true merits of the latter don't become apparent until after it's been pursued consistently for years. Python hasn't done that (there's been no consistency of effort, just manic "speed it up" bursts), and neither has it pursued any Major Schemes since LOAD_FAST was introduced. The most interesting dropped project "in the middle" was Skip Montanaro's Rattlesnake, which aimed to change the VM from a stack to a register model. > I see the ability to debug at whim, even when you didn't expect having > to do so, as being a major win, part of the incremental development > process. Same here! But I'm a little warped : I worked on optimization for a living for so many years, that one reason I was attracted to Python is that it didn't do *any* optimization to screw up my view of what my code was doing. Any debugger that claims to work well with "for real" optimized code in any language is lying. So the only optimizations I've ever supported in default-mode Python are things the user can't detect via semantics or usability. So I'm also -1 on [Vladimir] > 1) python - code without SET_LINENO > 2) python -g - code for debugging, with SET_LINENO > 3) python -O - code without doc-strings. unless SET_LINENO isn't needed for debugging. The speedup -O yields today is real and consistent, but rarely makes a difference worth worrying about (the only times it's mattered for me were in extremely well-tested CPU-bound programs that I intended to run for days straight, and then I appreciated the few hours it saved). python-the-choice-for-a-slow-generation-ly y'rs - tim From tim_one@email.msn.com Sat Jul 29 21:16:26 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 29 Jul 2000 16:16:26 -0400 Subject: [Python-Dev] SF most active project listing In-Reply-To: Message-ID: [Andrew Kuchling] > I was curious about how "most active project" is defined, and took a > look at the SF code. It's computed by the > util/db_project_weekly_metric.pl script, which sums up a bunch of > parameters to get a number. The parameters are: > > 3 * # of forum postings > 4 * # of tasks > 3 * # of bugs > 10 * # of patches > 5 * # of support > 1 * # of CVS commits > 5 * # of developers > 5 * # of file releases > .3 * # of downloads > > All of these numbers seem to be counted over the past week. Since it's Perl (or PHP?), I hope they remembered to change what "past week" means each week . Hmm: since they weight patches at 10 times the value of a commit, I guess they value projects where lots of people are unhappy but can't agree on what to do about it . > I suspect the code has a mathematical bug: the queries use, for > example, log(4*count(project_task.project_task_id)) for counting > things. However, IIRC, log ab = log a + log b, so the multipliers > just add a constant to every project's number, and therefore it's a > flat sum of all the parameters. IMHO that should be > 4*log(count(....)), and will report it. Ha! *Another* bug they wouldn't have had if they had written it in Python instead! Ya, ya, I'm lying, but if we all agree to say it's the truth, maybe they'll fall for it. agreeing-with-your-analysis-but-unsure-why-they're-taking-a-log- at-all-ly y'rs - tim From ping@lfw.org Sun Jul 30 00:22:50 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Sat, 29 Jul 2000 16:22:50 -0700 (PDT) Subject: [Python-Dev] extended slicing for lists In-Reply-To: Message-ID: Michael Hudson wrote: > Ka-Ping Yee writes: > > [...] sufficient for me to suggest just dropping it: > > better to avoid confusion altogether. > > Well, the BDFL spoke. Hence my mock-indignant "hmph". :) > > having to say l[len(l)-1:-1:-1] would be a royal pain. > > Well, you could probably always say > > l[sys.maxint:0:-1] > > (your example returns the empty list!) Hey, wait a second. To get l[start:end:step], you start with 'start' and keep adding 'step' until you get to -- but not including -- 'end', right? So l[len(l)-1:-1:-1] should return the entire list reversed, not the empty list. range() demonstrates the behaviour nicely: >>> size = 5 >>> range(size-1,-1,-1) [4, 3, 2, 1, 0] Wouldn't l[sys.maxint:0:-1] return all but the first element of l in reverse order? >>> range(size-1,0,-1) [4, 3, 2, 1] Note that we should deprecate the use of sys.maxint (preferring None) in this situation, since if the step is less than -1, the elements you get ought to depend on the value of sys.maxint % step. I'd expect: >>> l = [0, 1, 2, 3, 4, 5] >>> l[5:0:-3] [5, 2] >>> l[6:0:-3] [4, 1] >>> l[7:0:-3] [3, 0] >>> l[8:0:-3] [5, 2] hence >>> l[sys.maxint:0:-3] [???, ???] # depends on sys.maxint % 3 My guiding principle is that the indices should always match what you get from range(), and if start or end are missing, you get the items you would have gotten if you extend the sequence out forever. -- ?!ng From Vladimir.Marangozov@inrialpes.fr Sun Jul 30 03:39:26 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sun, 30 Jul 2000 04:39:26 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: from "Tim Peters" at Jul 29, 2000 04:05:14 PM Message-ID: <200007300239.EAA21825@python.inrialpes.fr> [Tim & Ken voting -1 and arguing about] > [Vladimir] > > 1) python - code without SET_LINENO > > 2) python -g - code for debugging, with SET_LINENO > > 3) python -O - code without doc-strings. > > unless SET_LINENO isn't needed for debugging. To be honest, I was -1 myself shortly after sending the message. The consequences, at least for IDLE, make this truly insane, unless, as you both pointed out, SET_LINENO's functionality is achieved without it. As a matter of fact, its functionality *can* be achieved, at least for debugging purposes. That is, for generating the callbacks from the main loop to a Python function, called on every new source line. This is what basically the patch I ended up with does. To clarify the current state of the challenge to remove SET_LINENO, here's a short summary of the idea we dicussed previously and which I implemented (the patch does look scary without explanation ). Consider the following code sequence diagram (current state), assuming that each position is an opcode, arguments included: 0 1 2 3 01234567890123456780123456780123 co_code -> [#....#......#....#..#....#....] where '.' - an opcode ^ '#' - SET_LINENO IP (instruction pointer) Whenever a sys.settrace function is set, it is called on every # and this is basically how the debugger gets control for each source line. It finds out the source line by reading it from the current frame - f.lineno Now, here's the picture with the patch intended to obviate SET_LINENO: 0 1 2 3 01234567890123456780123456780123 co_code -> [........................] the same co_code w/o SET_LINENO copy of -> [+...+.....+...+.+...+...] '+' is a 1-byte CALL_TRACE opcode co_code ^ overriding the 1st opcode of each internal to IP new source line eval_code2() Whenever a sys.settrace function is set, a copy of the original code stream is created and the IP is redirected to execute the copy before entering the main loop. In this copy, the 1st instruction for each line is set to CALL_TRACE. These locations are computed from the co_lnotab table. CALL_TRACE updates f.lineno and invokes the sys.settrace function. On return from sys.settrace, it reads the opcode byte it has overwritten from the original co_code and jumps directly to the argument fetch before the big switch. All this works like a charm, except that, a priori, it has 2 drawbacks regarding full compatibility with the current state with SET_LINENO: a) f.lineno is not updated on a regular basis like SET_LINENO does; only when sys.settrace is set & CALL_TRACE is called. b) the IP is redirected to the copy of co_code before entering the main loop. In practical terms, this means that only entire code objects are traceable, that is, tracing can't start in the middle of a code object. I am not sure whether these 2 things hurt. If so, probably a) hurts more than b), but this is where I stopped working on this at the time, being short of more ideas... If you have one, you're welcome :-) P!ng?? Florx bignal zupkin moognacious today? If not, this scheme probably looses due to a) and b) and SET_LINENO has to stay, at least, for full backward compatibility. Conclusion: the functionality is achieved, full back/compat is not :-/ -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one@email.msn.com Sun Jul 30 08:53:15 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 03:53:15 -0400 Subject: [Python-Dev] Should repr() of string should observe locale? In-Reply-To: Message-ID: [Guido] > There have been some requests (Francois Pinard, recently Alexander > Voinov) that repr() of a string should not use escape sequences for > characters that are printable according to the locale. > > I don't have the time to write a PEP or implement it (although it > should be simple enough) but it needs to be recorded as a feature > that I think is good (that's at least a +0). [Moshe Zadka] > I don't. Most people who are requesting it are requesting it for the > purpose of the interactive Python session. I think there is general > agreement that there should be a way to better control the REPL from > Python (my, now lost, sys.display patch, for example). Wouldn't that > solve the problem? Because str(list) and str(dict) and str(tuple) end up calling repr() on the items they contain, even simple stmts like e.g. print list_of_goofy_foreign_i.e._not_plain_ascii_strings produce unreadable octal escapes instead of the goofy foreign non-ascii characters goofy foreigners want . That's one of the Lost Pythonic Theses, btw: Goofy is better than unreadable. Hooking the REPL loop doesn't help with that, in part because an explicit print would sidestep the hook, and the rest because it's a real problem in non-interactive mode too. So there are problems other than just Fran\347ois's, including your desire to hook the P in REPL, and including that str(list) and str(dict) and str(tuple) applying repr to their containees causes horrible output for many a user-defined class too (so much so that many classes code __repr__ to do what __str__ is *supposed* to do) -- but they're arguably all distinct problems. That said, I'm -1 too, because Guido once sensibly agreed that strings produced by repr should restrict themselves to the characters C guarantees can be written and read faithfully in text-mode I/O, excluding the tab character (or, iow, each character c in a string produced by repr should have ord(c) in range(32, 128)). Give that up and text-mode pickles (plus anything else repr is used deliberately for in a text file) lose their guarantee of cross-platform portability at the C level (not to mention losing x-platform human readability); etc. The problem isn't that repr sticks in backslash escapes, the problem is that repr gets called when repr is inappropriate. There was extensive debate about that in Python-Dev earlier this year (and the year before, and ...). Thanks to the lack of PEPs in those benighted days, I bet we get to do it all over again . I can't make time for this round, though. In brief: Breaking repr's contract to produce printable ASCII is unacceptable damage to me, no matter what the short-term perceived benefit. A principled solution appeared to require a combination of (at least) making the P in the REPL loop hookable, and making the builtin container types pass on whichever of {str, repr} they were passed *to*; the latter is problematic when the containee is a string, though, because str(string) produces a string without delimiters to say "hey, I'm a string!", making the output pretty unreadable in the context of the containee; further fiddling of some sort is needed. if-the-current-repr-didn't-exist-we'd-have-to-reinvent-it-and- we-still-wouldn't-want-to-invoke-either-repr-much-of-the- time-anyway-ly y'rs - tim From akuchlin@mems-exchange.org Sun Jul 30 13:07:18 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sun, 30 Jul 2000 08:07:18 -0400 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <200007300239.EAA21825@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jul 30, 2000 at 04:39:26AM +0200 References: <200007300239.EAA21825@python.inrialpes.fr> Message-ID: <20000730080718.A22903@newcnri.cnri.reston.va.us> Hasn't backward compatibility already been broken for 2.0? So why not break it a little more? It always seemed odd to me that the current line number is always kept up to date, even though 99.999% of the time, no one will care. Why not just keep a small table that holds the offset in the bytecode at which each line starts, and look it up when it's needed? --amk From guido@beopen.com Sun Jul 30 15:02:38 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 09:02:38 -0500 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: Your message of "Sun, 30 Jul 2000 08:07:18 -0400." <20000730080718.A22903@newcnri.cnri.reston.va.us> References: <200007300239.EAA21825@python.inrialpes.fr> <20000730080718.A22903@newcnri.cnri.reston.va.us> Message-ID: <200007301402.JAA08591@cj20424-a.reston1.va.home.com> > Hasn't backward compatibility already been broken for 2.0? So why not > break it a little more? Sure -- within reason. > It always seemed odd to me that the current line number is always kept > up to date, even though 99.999% of the time, no one will care. Why > not just keep a small table that holds the offset in the bytecode at > which each line starts, and look it up when it's needed? That already exists. Search for co_lnotab, and for PyCode_Addr2Line(). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From m.favas@per.dem.csiro.au Sun Jul 30 14:54:15 2000 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Sun, 30 Jul 2000 21:54:15 +0800 Subject: [Python-Dev] checkins and regression tests Message-ID: <39843387.9F35D544@per.dem.csiro.au> It'd be nice if the newly checked-in test were run through the test framework before being checked in - the latest test_mmap.py fails due to the "inconsistent tab-space" problem... Mark -- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From guido@beopen.com Sun Jul 30 16:34:06 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 10:34:06 -0500 Subject: [Python-Dev] urllib - {quote,unquote} vs. {quote_plus,unquote_plus} In-Reply-To: Your message of "Fri, 28 Jul 2000 07:17:46 EST." <14721.31210.734864.412520@beluga.mojam.com> References: <14721.31210.734864.412520@beluga.mojam.com> Message-ID: <200007301534.KAA12762@cj20424-a.reston1.va.home.com> > I realize there is a symmetry between the functionality of > urllib.{quote,unquote} and urllib.{quote_plus,unquote_plus}, but why doesn't > unquote function like unquote_plus and map "+" to " "? The +/space mapping is unique to CGI query strings. The unquote function is used in a lot of places to decode parts of URLs (e.g. throughout urllib.py itself), e.g. the hostname or (more likely) the pathname can be encoded using %xx, and there a + does *not* mean a space. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Sun Jul 30 16:42:49 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 10:42:49 -0500 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Your message of "Fri, 28 Jul 2000 15:37:56 +0200." References: Message-ID: <200007301542.KAA12794@cj20424-a.reston1.va.home.com> > IMO one of the major strenghts of Python (in its reference implementation > C-Python) has today compared to other languages (Java) is this particular > behaviour. ["this behavior": closing files as soon as they go out of scope] > The argument made in the last sentence of the paragraph cited from > the reference manual is bogus: In order to be able to call a close() > method you have to keep an explicit reference to the object in question. > This usually requires many lines of source code where previously only > one line was needed: > > func(constructor("foo").method()) > has to be recoded as > try: > ref = constructor("foo") > func(ref.method()) > finally: > ref.close() > if constructor happens to keep external resources. This is a factor of > five (in LOC) of code bloat and is absolutely unacceptable. Only if you expect that func() may fail *and* that there may be an outer try/except that keeps the program alive for much longer. Normally it becomes the totally acceptable ref = constructor("foo") func(ref.method()) ref.close() I would recommend the try/finally version only if func() is *expected* to fail for some I/O related reason. And in much Python code (e.g. most scripts and throw-away programming) even the one-liner is totally acceptable. > If this kind of coding is required to make existing Python apps running > reliable under 'JPython', then this will render 'JPython' (and any other > Python implementation without proper reliable reclaiming) pretty useless > for me. (and may be to other members of the Python community) This sounds like a bit of an exaggeration to me. The fact of the matter is that we can't guarantee this, and in fact there are lots of gotcha's with expecting this behavior (e.g. when you catch an exception while a file object is local, the exception handling may easily keep it alive longer than expected. It's also very easy to forget other references to the object. Listen, I'm sorry for causing your worldview on this point to collapse, but it's no big deal, okay?! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Sun Jul 30 16:52:31 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 10:52:31 -0500 Subject: [Python-Dev] Howto docs In-Reply-To: Your message of "Fri, 28 Jul 2000 10:21:32 -0400." <20000728102132.A29083@kronos.cnri.reston.va.us> References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> <14721.37704.872570.141761@cj42289-a.reston1.va.home.com> <20000728102132.A29083@kronos.cnri.reston.va.us> Message-ID: <200007301552.KAA12837@cj20424-a.reston1.va.home.com> > On the other hand, the documentation maintainers might be a different > set of people from code maintainers, and we might not want them > checking in code changes, so having the docs as a completely separate > project would allow finer control of this. On the third hand, we do > have the python-checkins list to keep an eye on what's happening. > > I'd vote for nondist/doc/howto. Short term, definitely. Long term, I feel that making it a separate SF project might be a good idea. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido@beopen.com Sun Jul 30 17:39:57 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 11:39:57 -0500 Subject: [Python-Dev] buglet in unary ops on classes. In-Reply-To: Your message of "Fri, 28 Jul 2000 18:45:12 +0200." <20000728184512.D266@xs4all.nl> References: <20000728184512.D266@xs4all.nl> Message-ID: <200007301639.LAA16514@cj20424-a.reston1.va.home.com> > While poking around looking for something else, I found this little buglet: > > >>> class X: > ... def __getattr__(self, val): > ... print "getattr:", val > ... raise AttributeError > > >>> x = X() > >>> ~x > getattr: __invert__ > Traceback (most recent call last): > File "", line 1, in ? > File "", line 4, in __getattr__ > AttributeError > > The unary ops all do this (raising AttributeError), but the binary ops do > not: > > >>> x+1 > getattr: __coerce__ > getattr: __add__ > Traceback (most recent call last): > File "", line 1, in ? > TypeError: __add__ nor __radd__ defined for these operands > > Shouldn't this translation be done for unary ops as well ? Is it safe to > assume that instance_getattr() only returns NULL if the attribute is not > found ? PyInstance_DoBinOp() takes this assumption wrt. PyObject_GetAttr(), > and I don't really see a problem with it. In general, I'm against changing exceptions. There are situations conceivable where an AttributeError from a custom __getattr__ is caused by a bug in that __getattr__ or in something it calls, and it's important not to destroy the traceback in that case. The TypeError for a binary operator violates this principle. This is because the coercion process has to try several things that may fail with an AttributeError. Saving the tracebacks is just too much work. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From pf@artcom-gmbh.de Sun Jul 30 16:55:39 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Sun, 30 Jul 2000 17:55:39 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: <200007301542.KAA12794@cj20424-a.reston1.va.home.com> from Guido van Rossum at "Jul 30, 2000 10:42:49 am" Message-ID: Hi, Guido van Rossum: > > IMO one of the major strenghts of Python (in its reference implementation > > C-Python) has today compared to other languages (Java) is this particular > > behaviour. > > ["this behavior": closing files as soon as they go out of scope] > > > The argument made in the last sentence of the paragraph cited from > > the reference manual is bogus: In order to be able to call a close() > > method you have to keep an explicit reference to the object in question. > > This usually requires many lines of source code where previously only > > one line was needed: > > > > func(constructor("foo").method()) > > has to be recoded as > > try: > > ref = constructor("foo") > > func(ref.method()) > > finally: > > ref.close() > > if constructor happens to keep external resources. This is a factor of > > five (in LOC) of code bloat and is absolutely unacceptable. > > Only if you expect that func() may fail *and* that there may be an > outer try/except that keeps the program alive for much longer. In a GUI this is usually the case: For example Pmw contains such a default handler, which catches all otherwise uncaught exceptions and prevents the application from bombing. > Normally it becomes the totally acceptable > > ref = constructor("foo") > func(ref.method()) > ref.close() Sigh. This is still a factor of three. But LOCs are not my major point: An application programmer has to know, whether the object in question uses external resources or not, or he has to use the inconvinient 'close()' or 'destroy()' anyway, if he want's to make sure. [...] > And in much Python code (e.g. most scripts and throw-away programming) > even the one-liner is totally acceptable. Only if the "constructor().method()" idiom is not contained in a loop. Ancient Unix systems allowed only 20 files open at the same time. Although this has been increased to 120 or so in the mean time, you will easily ran out of file descriptors with the simple throw-away script posted in my first rant in this thread: >>> import os, rfc822 >>> posters = {} >>> for arti in os.listdir('/var/spool/news/comp/lang/python'): ... poster = rfc822.Message(open(arti)).get("From") ... posters[poster] = posters.get(poster, 0) + 1 ... >>> for poster, howoften in posters.items(): ... print poster, "posted", howoften, "times to clp." ... I believe scripts like this one are very common in the industry, since this idioms were advertised by several books (I still have to look up Martin v.Loewis "Das Pythonbuch", but IRC it contained subsection comparing Pythons garbage collection with Java GC and advertised the advantages of ref count GC) > > If this kind of coding is required to make existing Python apps running > > reliable under 'JPython', then this will render 'JPython' (and any other > > Python implementation without proper reliable reclaiming) pretty useless > > for me. (and may be to other members of the Python community) > > This sounds like a bit of an exaggeration to me. May be. Since Tkinter has been ported to JPython, I theoretically could give this platform at least a try. But now I know in advance, where I've to expect serious problems. I believe a lot of my GUI code based on Tkinter/Pmw makes use of this behaviour which simply works as advertised by Mark Lutz (and possibly others). [...] > Listen, I'm sorry for causing your worldview on this point to > collapse, but it's no big deal, okay?! If it is only *my* worldview: sure. But their might be others, who have learned Python 3 or 4 years ago. May be by using C-Python, may be by using Mark Lutz book "Programming Python". Since C-Python is available on all major platforms and the implementation in fact guarantees this behaviour (Pheeew!), this is indeed no big deal. No need to use 'JPython'. ;-) Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From mwh21@cam.ac.uk Sun Jul 30 17:14:51 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 30 Jul 2000 17:14:51 +0100 Subject: [Python-Dev] extended slicing for lists In-Reply-To: Ka-Ping Yee's message of "Sat, 29 Jul 2000 16:22:50 -0700 (PDT)" References: Message-ID: Ka-Ping Yee writes: > Hey, wait a second. To get l[start:end:step], you start with 'start' > and keep adding 'step' until you get to -- but not including -- 'end', > right? So l[len(l)-1:-1:-1] should return the entire list reversed, > not the empty list. Yes, but "-1" also means the last element of the list, so >>> range(10)[3:-1:2] [3, 5, 7] If you want "to the end" behaviour, use None (or nothing): >>> range(10)[5::-2] [5, 3, 1] >>> range(10)[5:None:-2] [5, 3, 1] (these two are indistinguishable) Also, can I plead my case in that this was not my decision - it's the logic implemented by PySlice_GetIndices. > range() demonstrates the behaviour nicely: > > >>> size = 5 > >>> range(size-1,-1,-1) > [4, 3, 2, 1, 0] > > Wouldn't l[sys.maxint:0:-1] return all but the first element of l in > reverse order? Yes. > >>> range(size-1,0,-1) > [4, 3, 2, 1] > > Note that we should deprecate the use of sys.maxint (preferring None) > in this situation, since if the step is less than -1, the elements > you get ought to depend on the value of sys.maxint % step. I'd expect: > > >>> l = [0, 1, 2, 3, 4, 5] > >>> l[5:0:-3] > [5, 2] > >>> l[6:0:-3] > [4, 1] > >>> l[7:0:-3] > [3, 0] > >>> l[8:0:-3] > [5, 2] Whereas at the moment you get: >>> l[5:0:-3] [5, 2] >>> l[6:0:-3] Traceback (most recent call last): File "", line 1, in ? TypeError: slice indices must be integers >>> l[7:0:-3] Traceback (most recent call last): File "", line 1, in ? TypeError: slice indices must be integers >>> l[8:0:-3] Traceback (most recent call last): File "", line 1, in ? TypeError: slice indices must be integers (which is definitely screwy). Perhaps I shouldn't use PySlice_GetIndices (but then if I don't use it for this patch, what on earth would you use it for?). At any rate PySlice_GetIndices needs mending to accept longs (in the style of PyObject_GetItem). > hence > > >>> l[sys.maxint:0:-3] > [???, ???] # depends on sys.maxint % 3 > > My guiding principle is that the indices should always match what > you get from range(), and if start or end are missing, you get the > items you would have gotten if you extend the sequence out forever. Aside from the interpretation of negative indices, I basically agree. Cheers, M. -- languages shape the way we think, or don't. -- Erik Naggum, comp.lang.lisp From guido@beopen.com Sun Jul 30 18:20:07 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 12:20:07 -0500 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: Your message of "Fri, 28 Jul 2000 18:07:21 +0200." <3981AFB9.26AEB1D1@lemburg.com> References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <20000728112646.A15634@thyrsus.com> <3981AFB9.26AEB1D1@lemburg.com> Message-ID: <200007301720.MAA17682@cj20424-a.reston1.va.home.com> > Separating out LOAD_FAST from the switch shows a nice effect. > SET_LINENO is removed by -OO anyway, so there's really no > use in optimizing this one. I tried this and found about three percent speed increase on pystone, for what that's worth. This is with python -OO on Linux x86. Note that removing the (now redundant) case from the switch seemed to make a small difference too. Alas, I have no time to play with optimizing the main loop in a more rigorous way... :-( Here's the patch I came up with: Index: ceval.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/ceval.c,v retrieving revision 2.187 diff -c -r2.187 ceval.c *** ceval.c 2000/07/25 12:56:38 2.187 --- ceval.c 2000/07/30 16:13:23 *************** *** 608,616 **** f->f_lasti = INSTR_OFFSET(); #endif opcode = NEXTOP(); ! if (HAS_ARG(opcode)) oparg = NEXTARG(); #ifdef DYNAMIC_EXECUTION_PROFILE #ifdef DXPAIRS dxpairs[lastopcode][opcode]++; --- 608,631 ---- f->f_lasti = INSTR_OFFSET(); #endif + get_opcode: opcode = NEXTOP(); ! if (HAS_ARG(opcode)) { oparg = NEXTARG(); + if (opcode == LOAD_FAST) { + x = GETLOCAL(oparg); + if (x != NULL) { + Py_INCREF(x); + PUSH(x); + goto get_opcode; + } + PyErr_SetObject(PyExc_UnboundLocalError, + PyTuple_GetItem(co->co_varnames, + oparg)); + goto on_error; + } + } + #ifdef DYNAMIC_EXECUTION_PROFILE #ifdef DXPAIRS dxpairs[lastopcode][opcode]++; *************** *** 1282,1300 **** } Py_INCREF(x); PUSH(x); - break; - - case LOAD_FAST: - x = GETLOCAL(oparg); - if (x == NULL) { - PyErr_SetObject(PyExc_UnboundLocalError, - PyTuple_GetItem(co->co_varnames, - oparg)); - break; - } - Py_INCREF(x); - PUSH(x); - if (x != NULL) continue; break; case STORE_FAST: --- 1297,1302 ---- From jeremy@beopen.com Sun Jul 30 17:30:18 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Sun, 30 Jul 2000 12:30:18 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <200007301530.KAA12747@cj20424-a.reston1.va.home.com> References: <14719.49496.935765.730596@anthem.concentric.net> <20000727075058.A25450@keymaster.enme.ucalgary.ca> <200007271455.JAA20686@cj20424-a.reston1.va.home.com> <14720.19413.201297.246838@bitdiddle.concentric.net> <200007271616.LAA27700@cj20424-a.reston1.va.home.com> <14720.22377.745878.821529@bitdiddle.concentric.net> <200007271746.MAA29479@cj20424-a.reston1.va.home.com> <14720.27358.569557.671132@bitdiddle.concentric.net> <200007301530.KAA12747@cj20424-a.reston1.va.home.com> Message-ID: <14724.22554.818853.722906@bitdiddle.concentric.net> --EY82Ois84t Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit This message duplicates some of my previous messages about the thread/fork deadlock. (Received report that some of my earlier messages appear to be lost.) I'm running a simpler version of Neil's test program that uses the thread module instead of the threading module. It's attached at the end of the message (test_fork2.py). It spawns five threads; then each thread, including the main thread, go into a while 1: loop that forks. The program locks up after about 100-200 forks. The process structure looks like this: > ps --forest PID TTY TIME CMD 684 pts/0 00:00:00 bash 783 pts/0 00:00:00 python 784 pts/0 00:00:00 \_ python 785 pts/0 00:00:00 | \_ python 786 pts/0 00:00:00 | \_ python 951 pts/0 00:00:00 | | \_ python 787 pts/0 00:00:05 | \_ python 788 pts/0 00:00:04 | \_ python 953 pts/0 00:00:00 | | \_ python 789 pts/0 00:00:00 | \_ python 952 pts/0 00:00:00 | \_ python 950 pts/0 00:00:00 \_ python 964 pts/0 00:00:00 ps top reports the following CPU activity: PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 787 jeremy 19 0 2048 2048 1940 R 0 52.8 0.7 0:06 python 788 jeremy 17 0 2048 2048 1940 R 0 44.2 0.7 0:06 python If I attached to process 787 with gdb, this is the stack trace I can see: #0 pthread_cond_wait (cond=0x80f297c, mutex=0x80f2988) at queue.h:25 #1 0x806fee3 in PyThread_acquire_lock (lock=0x80f2978, waitflag=1) at ../../Python/thread_pthread.h:311 #2 0x8054ec1 in PyEval_RestoreThread (tstate=0x80fb2f0) at ../../Python/ceval.c:171 #3 0x80c1242 in posix_wait (self=0x0, args=0x80f1cac) at ../../Modules/posixmodule.c:2849 #4 0x8059b83 in call_builtin (func=0x8103578, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2369 #5 0x8059a41 in PyEval_CallObjectWithKeywords (func=0x8103578, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2337 #6 0x80583b1 in eval_code2 (co=0x8144ec0, globals=0x80f25d4, locals=0x0, args=0x80f1cb8, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ../../Python/ceval.c:1675 #7 0x805a01d in call_function (func=0x8144cdc, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2491 #8 0x8059a21 in PyEval_CallObjectWithKeywords (func=0x8144cdc, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2335 #9 0x80b03aa in t_bootstrap (boot_raw=0x8142ad8) at ../../Modules/threadmodule.c:193 #10 0x4001ceca in pthread_start_thread (arg=0xbf3ffe60) at manager.c:213 After I collect the stack trace and restart the program, several other processes start running again: PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 786 jeremy 14 0 2048 2048 1928 R 0 24.6 0.7 0:09 python 788 jeremy 15 0 2048 2048 1928 R 0 24.6 0.7 0:34 python 787 jeremy 17 0 2048 2048 1928 R 0 24.4 0.7 0:34 python 783 jeremy 15 0 2048 2048 1928 R 0 23.8 0.7 0:09 python If I run the process again with thread debugging enabled (Py_DEBUG defined at compiel time and THREADDEBUG set to 1), I get the following trace: PyThread_init_thread called PyThread_allocate_lock() -> 0x80f2010 PyThread_acquire_lock(0x80f2010, 1) called PyThread_acquire_lock(0x80f2010, 1) -> 1 PyThread_release_lock(0x80f2010) called PyThread_allocate_lock called PyThread_allocate_lock() -> 0x80f6c58 PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 Adding parser accelerators ... Done. PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_allocate_lock called PyThread_allocate_lock() -> 0x80f6498 PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_start_new_thread called [lots of stuff omitted] 2051 2127 PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 1024 2130 PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_release_lock(0x80f6498) called [blocks] In this case, the deadlock occurs much more quickly. (Perhaps the extra I/O produced by the debugging output exacerbates the problem.) Jeremy PS If you don't have access to a Linux machine, you can use one of the Linux test machines on the SF compile farm. Log into linux.compile.sourceforge.net. --EY82Ois84t Content-Type: text/plain Content-Description: test_fork2.py Content-Disposition: inline; filename="test_fork2.py" Content-Transfer-Encoding: 7bit import os import thread def f(): while 1: if os.fork() == 0: print "%s %s" % (thread.get_ident(), os.getpid()) os._exit(0) os.wait() thread.start_new_thread(f, ()) thread.start_new_thread(f, ()) thread.start_new_thread(f, ()) thread.start_new_thread(f, ()) thread.start_new_thread(f, ()) f() --EY82Ois84t-- From guido@beopen.com Sun Jul 30 18:29:58 2000 From: guido@beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 12:29:58 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 22:05:08 +0200." <20000727220508.C224@xs4all.nl> References: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> <20000727182248.V266@xs4all.nl> <200007271730.MAA21788@cj20424-a.reston1.va.home.com> <20000727220508.C224@xs4all.nl> Message-ID: <200007301729.MAA17698@cj20424-a.reston1.va.home.com> > Yes. So what we're talking about is a better way to do indexing all > together, all types in one shot. ('indexes', 'slices' and 'collections' ? > I'm not sure how to name the first and the last one, if not that.) And not > just indexing, but setting and deleting at the same time, right ? Yes. > So the most preferred way is to pass a single argument which is either: > > - A single object (directly what was passed in) for a single index. > - A slice-object if any kind of single-slice was passed in, which holds the > zero-to-three objects that the slice was 'created' with. > - A tuple of zero or more of either of the above two. (Make that a tuple of two or more!) Indexing like a[] is illegal, and indexing like a[i] passes a non-tuple. > While I'm writing this down, I'm not sure if it's such a good idea. Isn't > this placing a tad too much into one function ? It might require some severe > logic to support this all, especially if you give 'special' meanings to some > indexes. And we're inserting a new catch-all method -- a set of them, > actually: get, set and del -- and that while Paul is trying to solve the > other catch-all Python has, __getattr__/__setattr__. Actually, __getitem__ *already* has to deal with -- the only case it doesn't get currently is the step-less single slice, which gets passed to __getslice__ -- and dies if it's not there. > And lets not forget the convenience of writing those methods: __getitem__ is > intuitive, both in name and semantics. So is __getslice__. The passing of a > slice object to __getitem__ is a tad less intuitive, and a tuple of > index/slice objects even less. Don't worry, that's already the case. > I'm tempted to suggest a single change: when __getslice__ is not defined, > pass a slice object (with no step, as if the slice had a trailing ':') to > __getitem__, and document it properly. Great! That's *exactly* what I've been proposing. > (and make builtin objects accept > sliceobjects too !) That gets a +1 from me too, in general (there's some doubt about the usefulness of things like ``L1[lo:ho:step] = L2''). > Perhaps try to slowly deprecate getslice__. Yes. > Give plenty > __of examples of using __getitem__ and slice objects > in the standard documentation. Sure. > Also, I think it makes sense to make slice > objects indexable, so that you can do: > > start, end, step = sliceobj > > instead of the less intuitive > > start, end, step = sliceobj.start, sliceobj.end, sliceobj.step > > But I've never used slice objects myself, so I can't really say whether it's > a good idea. Maybe that's a good idea. > I suspect this is all for 2.1 or later, though. Actually, the actual change (fall back on __*item__ with a slice object when __*slice__ doesn't exist) should be simple to add for 2.0. Just submit to the SF PM! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From thomas@xs4all.net Sun Jul 30 18:09:41 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 30 Jul 2000 19:09:41 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007301729.MAA17698@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Sun, Jul 30, 2000 at 12:29:58PM -0500 References: <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> <20000727182248.V266@xs4all.nl> <200007271730.MAA21788@cj20424-a.reston1.va.home.com> <20000727220508.C224@xs4all.nl> <200007301729.MAA17698@cj20424-a.reston1.va.home.com> Message-ID: <20000730190941.P13365@xs4all.nl> On Sun, Jul 30, 2000 at 12:29:58PM -0500, Guido van Rossum wrote: > > So the most preferred way is to pass a single argument which is either: > > > > - A single object (directly what was passed in) for a single index. > > - A slice-object if any kind of single-slice was passed in, which holds the > > zero-to-three objects that the slice was 'created' with. > > - A tuple of zero or more of either of the above two. > (Make that a tuple of two or more!) Indexing like a[] is illegal, and > indexing like a[i] passes a non-tuple. No sir: >>> class X: ... def __getitem__(self, val): ... return val ... >>> x = X() >>> x[()] () >>> x[1,] (1,) > > While I'm writing this down, I'm not sure if it's such a good idea. Isn't > > this placing a tad too much into one function ? It might require some severe > > logic to support this all, especially if you give 'special' meanings to some > > indexes. And we're inserting a new catch-all method -- a set of them, > > actually: get, set and del -- and that while Paul is trying to solve the > > other catch-all Python has, __getattr__/__setattr__. > Actually, __getitem__ *already* has to deal with -- the only case it > doesn't get currently is the step-less single slice, which gets passed > to __getslice__ -- and dies if it's not there. It should, but it doesn't, in most cases. God knows the code I wrote that had getitem and getslice didn't take slice objects into account, mostly because I didn't know how they worked ! Not to mention slice-tuples, which I didn't know were possible until you mentioned it ;) > > And lets not forget the convenience of writing those methods: __getitem__ is > > intuitive, both in name and semantics. So is __getslice__. The passing of a > > slice object to __getitem__ is a tad less intuitive, and a tuple of > > index/slice objects even less. > Don't worry, that's already the case. I know, I was arguing for an improvement, here :) > > I'm tempted to suggest a single change: when __getslice__ is not defined, > > pass a slice object (with no step, as if the slice had a trailing ':') to > > __getitem__, and document it properly. > > Great! That's *exactly* what I've been proposing. [snip more approvals] > > I suspect this is all for 2.1 or later, though. > Actually, the actual change (fall back on __*item__ with a slice > object when __*slice__ doesn't exist) should be simple to add for > 2.0. Just submit to the SF PM! That's what I thought. I'll see about that inbetween augmented assignment (which is not easy to do right, in retrospect. I almost uploaded a patch that evaluated 'x' in 'x += 1' twice ;) unless someone beats me to it, of course. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Moshe Zadka Sun Jul 30 19:19:53 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 30 Jul 2000 21:19:53 +0300 (IDT) Subject: [Python-Dev] Should repr() of string should observe locale? In-Reply-To: Message-ID: On Sun, 30 Jul 2000, Tim Peters identified loads of problems with Python, some of which I wish to address: > A principled solution appeared to require a combination of (at least) making > the P in the REPL loop hookable Oh yes. I think I want to PEP on this one. Barry, that's two numbers you owe me. still-commited-to-dumping-work-on-barry-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From tim_one@email.msn.com Sun Jul 30 19:55:09 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 14:55:09 -0400 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Message-ID: [Peter Funk] > ... > Only if the "constructor().method()" idiom is not contained in > a loop. Ancient Unix systems allowed only 20 files open at the > same time. Although this has been increased to 120 or so in > the mean time, you will easily ran out of file descriptors with > the simple throw-away script posted in my first rant in this > thread: > ... > I believe scripts like this one are very common in the industry, > since this idioms were advertised by several books (I still have > to look up Martin v.Loewis "Das Pythonbuch", but IRC it contained > subsection comparing Pythons garbage collection with Java GC and > advertised the advantages of ref count GC) You don't have to dig that deep: they're also common in the standard distribution, including at least two of mine (checkappend.py and tabnanny.py). There's a long copy/paste/modify tradition of not bothering to close file objects in multi-file tools, dating back at least to Guido's 1991 eptags.py . These aren't hard to "fix", but that isn't the point. A lot of code out there would start failing in data- and platform-dependent ways if CPython stopped cleaning up dead file objects "real soon" after they die, and there's no easy way to identify in advance which code that may be. It would piss off a lot of people! But I don't know why we're arguing about it. Nobody (AFAIK) has announced plans to take refcounting out of CPython, but that you can't *rely* on refcounting across Python implementations is ancient news (and a reality in practice since JPython). Guido certainly can't *require* that all implementations use refcounting! The Reference Manual has been clear about this for years, and other implementations already rely on what they were promised there: it's already too late to stop this from being a basis on which implementations will compete. as-if-microsoft-had-the-resources-to-take-on-beopen-anyway-ly y'rs - tim From Vladimir.Marangozov@inrialpes.fr Sun Jul 30 22:45:19 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sun, 30 Jul 2000 23:45:19 +0200 (CEST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007301720.MAA17682@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 30, 2000 12:20:07 PM Message-ID: <200007302145.XAA26775@python.inrialpes.fr> Guido van Rossum wrote: > > > Separating out LOAD_FAST from the switch shows a nice effect. > > SET_LINENO is removed by -OO anyway, so there's really no > > use in optimizing this one. > > I tried this and found about three percent speed increase on pystone, > for what that's worth. This is with python -OO on Linux x86. Note > that removing the (now redundant) case from the switch seemed to make > a small difference too. > > [patch deleted] Some speedup confirmed on my Linux PIII too. But you saved a round-trip around the ticker test. If this is acceptable, then let's do it for the opcodes involving only stack operations (probably not the JUMPs) _and_ which do not contain DECREFs which may trigger an external call. Here's the picture on my machine (I get the same picture with -OO): cvs - the original ceval.c in CVS load_fast - ceval.c with your patch top5 - ceval.c with my patch at SF moving 5 opcodes to the top top5-loadfast - my patch and your patch ~/python/dev>./python-cvs Lib/test/pystone.py Pystone(1.1) time for 120000 passes = 19.85 This machine benchmarks at 6045.34 pystones/second ~/python/dev>./python-load_fast Lib/test/pystone.py Pystone(1.1) time for 120000 passes = 19.61 This machine benchmarks at 6119.33 pystones/second ~/python/dev>./python-top5 Lib/test/pystone.py Pystone(1.1) time for 120000 passes = 18.87 This machine benchmarks at 6359.3 pystones/second ~/python/dev>./python-top5-load_fast Lib/test/pystone.py Pystone(1.1) time for 120000 passes = 19.08 This machine benchmarks at 6289.31 pystones/second Which shows, among others, that important cache effects are still here, bacause "python-top5-load_fast" is slower than "python-top5" alone... no-more-time-for-it-from-me-either'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From pf@artcom-gmbh.de Sun Jul 30 23:31:59 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Mon, 31 Jul 2000 00:31:59 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: from Tim Peters at "Jul 30, 2000 2:55: 9 pm" Message-ID: Hi, Tim Peters: > > [about Class().method()-idiom] [...] > You don't have to dig that deep: they're also common in the standard > distribution, including at least two of mine (checkappend.py and > tabnanny.py). There's a long copy/paste/modify tradition of not bothering > to close file objects in multi-file tools, dating back at least to Guido's > 1991 eptags.py . > > These aren't hard to "fix", but that isn't the point. A lot of code out > there would start failing in data- and platform-dependent ways if CPython > stopped cleaning up dead file objects "real soon" after they die, and > there's no easy way to identify in advance which code that may be. It would > piss off a lot of people! Thank you! Pheew. This applies in particular not only to file descriptors. This hits other limited resources also: color table entries, windows, network connections and so on. > But I don't know why we're arguing about it. Nobody (AFAIK) has announced > plans to take refcounting out of CPython, but that you can't *rely* on > refcounting across Python implementations is ancient news (and a reality in > practice since JPython). This topic was initially raised in the recent discussion about weak references which had a completely different subject line: "Product iteration". Mark Hammond wrote in this thread: MH> I have no problem with this at all. The sooner we point out the broken MH> code the better. The last thing we want is for obviously and documented MH> broken code to suddenly be considered non-broken simply by the volume of MH> poor code out there... Here I would say : "too late!" The volume of code is already there and from my POV this code simply doesn't look broken. I think it is but elegant, because it is usually shorter and was easier to write, because the programmer hasn't to bother too much about any external resources, which may have been used by some temp objects under the hood. > Guido certainly can't *require* that all implementations use refcounting! Okay. But this is "(for language lawyers)" anyway ;-). Anybody who want's to develop a seriously competing Python implementation is well advised to implement a similar "real soon" object recycling strategy regardless of what the Language Reference may tell them and what Guido "require". The existing code requires it. The current reliable automatic recycling behaviour in C-Python is so very very convenient, that I wouldn't want to do without it in practice. This is like having to use the staircase to go upstairs to the 10th floor in a building if there is an elevator with an open door just beside the first step. > The Reference Manual has been clear about this for years, and other > implementations already rely on what they were promised there: it's already > too late to stop this from being a basis on which implementations will > compete. Competing Python implementations? Hmmm.... Hmmm.... there is "stackless" but AFAIK it also uses refcounting... . ;-) Happy with C-Python, Peter From mhammond@skippinet.com.au Sun Jul 30 23:38:34 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Mon, 31 Jul 2000 08:38:34 +1000 Subject: [Python-Dev] checkins and regression tests In-Reply-To: <39843387.9F35D544@per.dem.csiro.au> Message-ID: > It'd be nice if the newly checked-in test were run through the test > framework before being checked in - the latest test_mmap.py fails due to > the "inconsistent tab-space" problem... That would be my fault. Thomas has already fixed it - thanks! However, Im a little confused by the error you saw. It certainly tested OK for me on both Linux and Windows, both when I checked it in, and as soon as I saw your message (but before updaing CVS). It also looks like it should have worked - a tab was used where 8 spaces should have been. I do find it a little ironic that Pythonwin has a number of features to detect this exact problem - but I didnt use Pythonwin to edit that :-( Oh well, all's well that ends well :-) Mark. From tim_one@email.msn.com Sun Jul 30 23:41:42 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 18:41:42 -0400 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007302145.XAA26775@python.inrialpes.fr> Message-ID: [Vladimir Marangozov] > ... > Which shows, among others, that important cache effects are > still here, bacause "python-top5-load_fast" is slower than > "python-top5" alone... I would rather call them "second-order effects" (SOE), as we can actually have no idea what causes them without a whale of a lot of work. They *could* be unfortunate accidents in the data or instruction caches, or *could* be that rearranging the code caused the compiler to spill a variable to memory that would have been better off in a register, or *could* be that the compiler optimizer runs out of steam in a different place than before and so generates sub-optimal code in any number of other respects, or *could* be that the sequence of jumps just happened to change in a way that causes one to get mis-predicted by the HW, or causes the HW prediction cache to flush at a bad moment, or etc etc etc. A gloss: almost all interesting optimizations a compiler performs, from register assignment to instruction scheduling, take exponential time to optimize "for real". No compiler can afford that much time (although there are some platform-specific "superoptimizers" out there that you can run for days over small pieces of code), so in practice compilers string together a long chain of fast but more-or-less fragile heuristic approaches, or even resort to general "mystery schemes" (like simulated annealing). Predicting what pops out the other end generally can't be done easier than by running the optimizer and *seeing* what pops out! So tiny changes can have wonderfully unexpected effects, and in general you cannot out-think them in advance. And as CPU HW has gotten ever-more complex, SOE has spread to cover a much larger territory than it used to (note that Intel doesn't even pretend to document the actual P3 timing rules anymore -- they've gotten too complicated to explain! compilers only work from an *approximation* to HW truth now). That said, there's good cross-platform reason to believe that Vladimir's "top 5" rearrangement is a helpful change, and more helpful than sucking out one popular opcode. It also has less potential to trigger harmful SOE, because it doesn't change the basic-block structure of the code (optimizers crawl over a graph of the basic blocks, and changes to the *topology* of the graph can cause heuristics to "get stuck" in new & exciting places <0.9 wink>; this is important in ceval because the loop is soooooo big -- optimizers are likely to fall into a state of unstable equilibrium when chewing over this much code). +1 on top5 because it's an easy change that's likely to help and unlikely to hurt. -0 on peeing away more time on micro-optimization right now. then-again-if-it's-the-only-way-guido-can-take-time-to-actually- work-on-python...-ly y'rs - tim From Vladimir.Marangozov@inrialpes.fr Mon Jul 31 00:26:12 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 01:26:12 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <200007301402.JAA08591@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 30, 2000 09:02:38 AM Message-ID: <200007302326.BAA05861@python.inrialpes.fr> Guido van Rossum wrote: > > > Hasn't backward compatibility already been broken for 2.0? So why not > > break it a little more? > > Sure -- within reason. Ok folks. I've uploaded an updated patch on SF against CVS if you want to play with it. IDLE, at least, seems to be happy. I'm not sure whether something else relies on f.lineno and whether it is now broken because of the lack of lineno updates. (Note that you need to delete your .pyc files so that the compiler can regenerate the code without SET_LINENO; if SET_LINENO are in the code, you wouldn't see any difference...) -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one@email.msn.com Mon Jul 31 00:26:00 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 19:26:00 -0400 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Message-ID: Peter, what would you say if someone told you your Python programs would run, oh, 30% faster, but in return for that you could no longer rely on refcount semantics? What do you think *most* people would say? I don't know, but I'm certain I'd hear different answers from different people. Don't fall into the trap of believing that refcounting is a pure win! JPython and Vyper and the MS runtime aren't doing "real gc" just because they want to irritate people . There are tradeoffs here, and new Python code is probably more interesting to MS than old Python code. I personally don't think you'd find this a big deal if you had *always* needed to do explicit .close()-like calls in Python, and most programmers (across the world and across languages) have never used a language in which they *didn't* need to do explicit closes. Python has plenty of other attractions for them. MS may very well be delighted to leave the legacy Python market to BeOpen <0.9 wink>. remind-me-to-call-uncle-bill-in-the-morning-ly y'rs - tim From tim_one@email.msn.com Mon Jul 31 00:46:12 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 19:46:12 -0400 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <20000730080718.A22903@newcnri.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > ... > It always seemed odd to me that the current line number is > always kept up to date, even though 99.999% of the time, no > one will care. Why not just keep a small table that holds > the offset in the bytecode at which each line starts, and > look it up when it's needed? As Guido said, we already do -- indeed, that's how Python manages to produce line numbers in tracebacks under -O mode (which inhibits generation of SET_LINENO opcodes). Your next job is to think about how, e.g., you can set a breakpoint on a specific line of code in the debugger. Take a quick peek at the implementation of SET_LINENO in ceval.c, and you'll see that's where the trace hook is implemented. No SET_LINENO, no trace callback. That's what Vladimir has been trying to solve: the trick is arranging to pay something at runtime for it only when you're actually using it. debuggers-always-need-dirty-tricks-ly y'rs - tim From nhodgson@bigpond.net.au Mon Jul 31 00:50:34 2000 From: nhodgson@bigpond.net.au (Neil Hodgson) Date: Mon, 31 Jul 2000 09:50:34 +1000 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) References: Message-ID: <015d01bffa80$f4bbced0$8119fea9@neil> > Don't fall into the trap of believing that refcounting is a pure win! > JPython and Vyper and the MS runtime aren't doing "real gc" just because > they want to irritate people . There are tradeoffs here, and new > Python code is probably more interesting to MS than old Python code. This aspect of GC is, however, irritating some C++ programmers who are an important MS customer group. This can be used to block C# and 'managed' C++ inside .NET with the argument "C# is /less/ safe because it is harder to ensure clean up so you'll leak resources". The base problem is that the only resource GC knows about is memory. There should be a way of attaching other resources such as file handles and data base connections to a similar mechanism. Neil From greg@cosc.canterbury.ac.nz Mon Jul 31 01:05:00 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Mon, 31 Jul 2000 12:05:00 +1200 (NZST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007281134.NAA05764@python.inrialpes.fr> Message-ID: <200007310005.MAA10150@s454.cosc.canterbury.ac.nz> > Yes, and we won't be able to conclude anything. This is micro-optimization > which doesn't give meaningful results. That's why I said "if what you say is true", i.e. if the claimed slowdown from the extra argument decoding step actually exists. There are two possibilities: (1) It really does slow down the execution of all bytescodes. In that case, move it into the handler code for the relevant bytecodes, where it won't affect the speed of anything else. (2) Otherwise, leave it where it is. Either way, I don't see any justification to reject the idea of having 2-arg opcodes because of speed, which is what the original post seemed to be saying. Or maybe I misunderstood. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From Vladimir.Marangozov@inrialpes.fr Mon Jul 31 01:25:08 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 02:25:08 +0200 (CEST) Subject: 2-arg opcodes (was Re: [Python-Dev] PEP 203 Augmented Assignment) In-Reply-To: <200007310005.MAA10150@s454.cosc.canterbury.ac.nz> from "Greg Ewing" at Jul 31, 2000 12:05:00 PM Message-ID: <200007310025.CAA10819@python.inrialpes.fr> Greg Ewing wrote: > > Either way, I don't see any justification to reject the idea of > having 2-arg opcodes because of speed, which is what the > original post seemed to be saying. Or maybe I misunderstood. The latter. I was objecting to Guido's suggestion to time it and see... I'm not opposed to the idea, although it is likely to slow things down. But assuming we don't talk about performance, I don't see a reason for not thinking about a generalized scheme with variable-size arguments, (cf. classical CPU instruction sets) that is, instructions which operate on 1-, 2- or 4-byte arguments. if-you-wanna-fix-it-do-it-like-a-man-'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From greg@cosc.canterbury.ac.nz Mon Jul 31 01:25:55 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Mon, 31 Jul 2000 12:25:55 +1200 (NZST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007281547.RAA06456@python.inrialpes.fr> Message-ID: <200007310025.MAA10154@s454.cosc.canterbury.ac.nz> > Imagine what will happen if SET_LINENO disappears But this is > very tricky business which is more complicated than it looks like... Can someone summarise what the issues are with SET_LINENO? I had the impression that they're not needed for finding the line numbers in tracebacks. So what would we lose if they disappeared? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From mhammond@skippinet.com.au Mon Jul 31 02:45:01 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Mon, 31 Jul 2000 11:45:01 +1000 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007310025.MAA10154@s454.cosc.canterbury.ac.nz> Message-ID: > Can someone summarise what the issues are with SET_LINENO? > I had the impression that they're not needed for finding the > line numbers in tracebacks. So what would we lose if they > disappeared? The debugger (and quite possibly the profiler - I havent checked!) As Tim said only a few hours ago: --- Your next job is to think about how, e.g., you can set a breakpoint on a specific line of code in the debugger. Take a quick peek at the implementation of SET_LINENO in ceval.c, and you'll see that's where the trace hook is implemented. No SET_LINENO, no trace callback. That's what Vladimir has been trying to solve: the trick is arranging to pay something at runtime for it only when you're actually using it. debuggers-always-need-dirty-tricks-ly y'rs - tim --- Mark. From gvwilson@nevex.com Mon Jul 31 03:11:09 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Sun, 30 Jul 2000 22:11:09 -0400 (EDT) Subject: [Python-Dev] re-ordering op-codes / DDJ Message-ID: Hi, folks. Given how popular byte code interpreters are these days, I think "Doctor Dobb's Journal" would be very interested in an article if work is done on re-ordering/re-organizing the Python VM to improve performance. Interested parties please mail me directly... Thanks, Greg From greg@cosc.canterbury.ac.nz Mon Jul 31 03:18:26 2000 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Mon, 31 Jul 2000 14:18:26 +1200 (NZST) Subject: Ditching SET_LINENO (RE: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment)) In-Reply-To: Message-ID: <200007310218.OAA10165@s454.cosc.canterbury.ac.nz> > the trick is arranging to pay something > at runtime for it only when you're actually using it. When tracing is in effect, switch to another copy of ceval2() which contains extra code to do whatever grubby things are needed to detect the start of a line using the line starts table. (Search it before executing each opcode, expand it into a parallel array of flags, or whatever.) The two versions of ceval2() could be generated from the same source file with some #defines. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From Vladimir.Marangozov@inrialpes.fr Mon Jul 31 03:34:08 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 04:34:08 +0200 (CEST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: from "Mark Hammond" at Jul 31, 2000 11:45:01 AM Message-ID: <200007310234.EAA11379@python.inrialpes.fr> Mark Hammond wrote: > > > Can someone summarise what the issues are with SET_LINENO? > > I had the impression that they're not needed for finding the > > line numbers in tracebacks. So what would we lose if they > > disappeared? > > The debugger (and quite possibly the profiler - I havent checked!) Addendum: the debugger in its current state. And the whole point of the solution we were thinking of is to make sure that the debugger (and other objects, like tracebacks) do read the line number only when the main loop fires a "line" event via a hook. Given the state of the art, however, nobody can guarantee that the line number is not fetched in legacy code from the frame directly, through f.lineno (for whatever purpose). Note that we can trap the access to the f.lineno attribute in frameobject.c, but the problem boils down to computing the line number from the current instruction, i.e. from 'f.lasti', because the only thing we have at our disposal is a table (co_lnotab) which maps line number offsets and instruction offsets (through delta increments). Note that the f.lasti attr is not updated as it should in the main loop, because it would infer a lot of overhead (to be up to date, it needs to be updated for every opcode). It is updated only for 'important' events: a trace hook, an exception, a Python function call. So, at the heart of the difficulty here is the fact that we can't figure out precisely where we are in the opcode stream, if we ask that from Python (because the program counter is not stored anywhere regularly). We need to get notified by the main loop. And whenever you ask 'f.lineno' from Python, well, you're asking this information from the Python side (without notification from the C side). Do you follow me up to this point? :-) Now, with SET_LINENO, we are sure that f.lineno is always up to date, because its purpose is to update f.lineno (on one hand) *and* to fire a "line" event from the main loop if a hook is in place. The compiler makes sure to insert SET_LINENO opcodes for each new source line (this is why, BTW, you can end up with 10 SET_LINENO in a row if you have 10 doc strings in a row that describe some Python function). Without SET_LINENO, we have to deal with these two problems: firing "line" events whenever a tracing function is set and updating f.lineno. We can manage to fire a "line" event (through the scheme I've explained previously, or similar), but we still can't (well, I don't see a reliable way so far) update f.lineno permanently. that's-all-'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov@inrialpes.fr Mon Jul 31 03:42:10 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 04:42:10 +0200 (CEST) Subject: Ditching SET_LINENO (RE: [Python-Dev] Reordering opcodes (PEP 203 In-Reply-To: <200007310218.OAA10165@s454.cosc.canterbury.ac.nz> from "Greg Ewing" at Jul 31, 2000 02:18:26 PM Message-ID: <200007310242.EAA11409@python.inrialpes.fr> Greg Ewing wrote: > > > the trick is arranging to pay something > > at runtime for it only when you're actually using it. > > When tracing is in effect, switch to another copy of ceval2() > which contains extra code to do whatever grubby things are > needed to detect the start of a line using the line > starts table. (Search it before executing each opcode, > expand it into a parallel array of flags, or whatever.) > > The two versions of ceval2() could be generated from the same > source file with some #defines. Huh? See my Addendum: to Mark's message that I just posted, which explains the whole story in detail. I forgot to change the subject line which still reads "Opcode reordering". Ah wait... from the archives: http://www.python.org/pipermail/python-dev/2000-July/014395.html If you think your suggestion still holds, then could you elaborate a bit more? -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov@inrialpes.fr Mon Jul 31 04:35:49 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 05:35:49 +0200 (CEST) Subject: [Python-Dev] SET_LINENO = f.lineno + ticker + ... = ? In-Reply-To: <200007310242.EAA11409@python.inrialpes.fr> from "Vladimir Marangozov" at Jul 31, 2000 04:42:10 AM Message-ID: <200007310335.FAA11459@python.inrialpes.fr> [me, on explaining the deal with SET_LINENO] > > See my Addendum: to Mark's message that I just posted, which explains > the whole story in detail. I forgot to change the subject line which > still reads "Opcode reordering". Ah wait... from the archives: > > http://www.python.org/pipermail/python-dev/2000-July/014395.html > Which makes me think about the tstate->ticker. This is the only variable updated for every opcode. If we can manage to involve the ticker in the computation of f.lineno, having f.lasti and interp->checkinterval and whatever variables are logged somewhere, we're about to win. But it's likely to be messy, because thread states and frames would be involved. If this is possible, we'll trap f.lineno's access in frameobject.c and through this magic formula we could get an updated f.lineno on every Python request. Could someone think of a "magic formula" to compute the PC (the index of the current opcode), which is enough for computing f.lineno with PyCode_Addr2Line()? Guido? Tim? Anyone? -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one@email.msn.com Mon Jul 31 05:23:56 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 31 Jul 2000 00:23:56 -0400 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007310234.EAA11379@python.inrialpes.fr> Message-ID: [Vladimir Marangozov] > ... > And the whole point of the solution we were thinking of is to > make sure that the debugger (and other objects, like > tracebacks) do read the line number only when the main loop > fires a "line" event via a hook. > > Given the state of the art, however, nobody can guarantee that > the line number is not fetched in legacy code from the frame > directly, through f.lineno (for whatever purpose). I really don't think we care about that. Guido, do we ? f_lineno is conceptually an internal implementation detail of frame objects, and Guido has often warned that if you access the internals you're on your own (I don't think even Michael's bytecodehacks cares about this one ). So long as all uses of f_lineno in the std distribution can be faked, I think it's fine to just get rid of that member. WRT your later msg, strongly doubt tstate->ticker will help: it's an integer in range(tstate->interp->checkinterval + 1), and wraps around over & over. Besides, the modular base (checkinterval) can be changed by the user at any time. tstate->ticker is thus but the circular shadow of a legion of ghosts. It isn't worth all these brain cells just to preserve an internal detail! OK, it would be worth it if it were easy -- but it's not. From thomas@xs4all.net Mon Jul 31 05:48:49 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 31 Jul 2000 06:48:49 +0200 Subject: [Python-Dev] checkins and regression tests In-Reply-To: ; from mhammond@skippinet.com.au on Mon, Jul 31, 2000 at 08:38:34AM +1000 References: <39843387.9F35D544@per.dem.csiro.au> Message-ID: <20000731064849.J266@xs4all.nl> On Mon, Jul 31, 2000 at 08:38:34AM +1000, Mark Hammond wrote: > > It'd be nice if the newly checked-in test were run through the test > > framework before being checked in - the latest test_mmap.py fails due to > > the "inconsistent tab-space" problem... > That would be my fault. Thomas has already fixed it - thanks! My shadow is still trying to catch up :) > However, Im a little confused by the error you saw. It certainly tested OK > for me on both Linux and Windows, both when I checked it in, and as soon as > I saw your message (but before updaing CVS). It also looks like it should > have worked - a tab was used where 8 spaces should have been. 'make test' runs 'python -tt' on the test scripts, at least on systems using Makefile. And '-tt' means you can't mix spaces and tabs even if you use 8-space tabstops. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Moshe Zadka Mon Jul 31 05:57:41 2000 From: Moshe Zadka (Moshe Zadka) Date: Mon, 31 Jul 2000 07:57:41 +0300 (IDT) Subject: [Python-Dev] RE: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Message-ID: On Sun, 30 Jul 2000, Tim Peters wrote: > But I don't know why we're arguing about it. Nobody (AFAIK) has announced > plans to take refcounting out of CPython, but that you can't *rely* on > refcounting across Python implementations is ancient news (and a reality in > practice since JPython). Well, to bring this back to the original: I proposed a variant of lexical scoping where an inner function has only a weak reference to its surroundin environment, so that def f(x): def g(): return x return g f(1)() Would fail with "UnboundOuterVariable", but the more commonly used def f(x): return map(lambda i,x=x: i*x, range(10)) Would turn into def f(x): return map(lambda i: i*x, range(10)) And work. Guido seemed to want to simulate classes by closures , and I tried to convince him that a) Python has a perfectly good class mechanism <3000 wink> b) non-weak references would cause cycles, which would mean that the currently working code: def f(file): file = open(file) def g(x): print x g(file.read()) Would fail is called in a loop if GC is not called too often. lexical-scoping-is-too-powerful-for-its-own-good-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From Vladimir.Marangozov@inrialpes.fr Mon Jul 31 06:54:08 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 07:54:08 +0200 (CEST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: from "Tim Peters" at Jul 31, 2000 12:23:56 AM Message-ID: <200007310554.HAA11702@python.inrialpes.fr> Tim Peters wrote: > > [Vladimir Marangozov] > > ... > > And the whole point of the solution we were thinking of is to > > make sure that the debugger (and other objects, like > > tracebacks) do read the line number only when the main loop > > fires a "line" event via a hook. > > > > Given the state of the art, however, nobody can guarantee that > > the line number is not fetched in legacy code from the frame > > directly, through f.lineno (for whatever purpose). > > I really don't think we care about that. Guido, do we ? > > f_lineno is conceptually an internal implementation detail of frame objects, > and Guido has often warned that if you access the internals you're on your > own (I don't think even Michael's bytecodehacks cares about this one > ). So long as all uses of f_lineno in the std distribution can be > faked, I think it's fine to just get rid of that member. > > WRT your later msg, strongly doubt tstate->ticker will help: it's an > integer in range(tstate->interp->checkinterval + 1), and wraps around over & > over. Besides, the modular base (checkinterval) can be changed by the user > at any time. tstate->ticker is thus but the circular shadow of a legion of > ghosts. > > It isn't worth all these brain cells just to preserve an internal detail! It is! > OK, it would be worth it if it were easy -- but it's not. It is! I think I found the solution :-) Whenever f.f_lineno is accessed, the compiler generates a LOAD_ATTR relative to f. Therefore, updating f->f_lasti = INSTR_OFFSET() in LOAD_ATTR + trapping "lineno" access in frameobject.c with PyCode_Addr2Line(f->f_lasti) ensures that we'll always get the right line number. Of course, this makes the update of f->f_lasti for every LOAD_ATTR, but given the ranking of SET_LINENO compared to LOAD_ATTR in the DXP and MAL's frequency charts, I think this is a pure win! Et voila . I'll update my patch at SF later. now-back-to-work'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From ping@lfw.org Mon Jul 31 07:38:45 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Sun, 30 Jul 2000 23:38:45 -0700 (PDT) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007310234.EAA11379@python.inrialpes.fr> Message-ID: Mark Hammond wrote: > > > Can someone summarise what the issues are with SET_LINENO? > > I had the impression that they're not needed for finding the > > line numbers in tracebacks. Yes, traceback info comes from c_lnotab and doesn't depend on SET_LINENO. Only tracing and f.lineno depend on SET_LINENO. > > So what would we lose if they disappeared? > > The debugger (and quite possibly the profiler - I havent checked!) I'm still a little puzzled on this one. The only way you can view a running Python program in the debugger is to have started it within the debugger, right? I don't think it's possible to attach a debugger to an already running program. Hence -- if you had to know beforehand that you were going to start the debugger anyway, then you clearly have the opportunity to say -g whenever you want to do debugging. It seems to me that any debugger (or IDLE et al.) can just start with #!/usr/bin/env python -g and we could then drop SET_LINENO by default. Am i missing something? On Mon, 31 Jul 2000, Vladimir Marangozov wrote: > Note that the f.lasti attr is not updated as it should in the main loop, > because it would infer a lot of overhead (to be up to date, it needs to > be updated for every opcode). It is updated only for 'important' events: > a trace hook, an exception, a Python function call. This is okay. The *only* time this is going to make any difference is when a function is trying to inspect the location of the PC within itself. (When the frame is being inspected from anywhere else, f.lasti will be up to date because it will have been set on function call.) I think we don't need to care so much about a function looking at its own f.lineno. Just use PyCode_Addr2Line on f.lasti whenever someone asks for f.lineno, and perhaps document the caveat for anyone weird enough to write navel-gazing functions. :) -- ?!ng From ping@lfw.org Mon Jul 31 07:47:59 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Sun, 30 Jul 2000 23:47:59 -0700 (PDT) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: Message-ID: On Sat, 29 Jul 2000, Ken Manheimer wrote: > On Fri, 28 Jul 2000 Vladimir.Marangozov@inrialpes.fr wrote: > > 1) python - code without SET_LINENO > > 2) python -g - code for debugging, with SET_LINENO > > 3) python -O - code without doc-strings. [...] > I would be firmly -1 on this proposal. Funny -- i was just about to throw in a hearty +1. > I see the ability to debug at whim, even when you didn't expect having to > do so, as being a major win, part of the incremental development process. But you *can't* debug at whim, right? You have to have started the debugger, so it can hook sys.settrace, before you run your program. If you have to start the debugger anyway, then you can surely say -g. If you *didn't* start the debugger beforehand, the best you can get is a detailed traceback with function names and line numbers -- and you don't lose any of that when SET_LINENO goes away. Let's suppose: 1. -g is turned on by default in interactive mode, since we don't know if you're going to feel like tracing today. 2. Programs (like debuggers and IDEs) that know they're going to use sys.settrace, or which contain embedded interactive interpreters, begin with #!/usr/bin/env python -g 3. Other programs begin with the usual #!/usr/bin/env python Given this -- are there any debugging opportunities you're missing out on? I don't see any... -- ?!ng From MarkH@ActiveState.com Mon Jul 31 07:47:17 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Mon, 31 Jul 2000 16:47:17 +1000 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: Message-ID: > I'm still a little puzzled on this one. The only way you can view > a running Python program in the debugger is to have started it > within the debugger, right? Not really. > I don't think it's possible to attach > a debugger to an already running program. IDLE and Pythonwin are able to debug arbitary programs once they have started - and they are both written in Python. In addition, most debuggers have a technique for breaking into the debugger from code - ie, a hard break-point. pdb.set_trace() is how pdb does it. Pythonwin has one. IDLE either does, or will grow one. I can see a number of other problems: * You do not want to debug the IDE itself, just a tiny bit of code running under the IDE. Making the IDE take the full hit simply because it wants to run a debugger occasionally isnt fair. Also, people tend to start these IDEs once, and keep them running during a number of discrete tasks. Only a few of these tasks may involve firing up the debugger. Asking them to restart the IDE simply to enable the debugger would be a pain for the user. Worse, these IDEs are often started from a GUI, rather than from the command line. This would mean we need 2 (in Windows parlance) shortcuts - "IDLE" and "IDLE with debugging". The end result is that all IDEs will run with debugging enabled. * Python often is embedded, for example, in a Web Server, or used for CGI. It should be possible to debug these programs directly. It shouldnt be necessary to (eg) change the CGI settings so Python is invoked with a special flag whenever you want to use a debugger. It can be hard enought to setup CGI as it is, let alone trying to make it's behaviour depend on if a script needs to be debugged or not. * We should not force Python embedders to handle this themselves. For example, asking someone who embeds Python to support a command-line switch to enable debugging Python is a PITA. It may not even be possible. With Active Scripting, for example, the host may not know it is even using Python at all! It all seems to push the problem down to those who can least afford to manage it, and least equipped to understand how it needs to be tweaked for their particular situation. However, I could agree that the debugger itself trigger debuggable behaviour. I just dont believe this should be a startup-only switch. sys.set_debugging(1) would work for me. OTOH, a debugger always announces itself by calling sys.settrace(), so this is really all that is necessary (and debugging can be disabled whenever sys.settrace(None) is called, and no existing frames have their tracer set.) Mark. From pf@artcom-gmbh.de Mon Jul 31 08:43:55 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Mon, 31 Jul 2000 09:43:55 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: from Tim Peters at "Jul 30, 2000 7:26: 0 pm" Message-ID: Good morning Tim, Tim Peters: > Peter, what would you say if someone told you your Python programs would > run, oh, 30% faster, but in return for that you could no longer rely on > refcount semantics? Personally I wouldn't go for that trade. Waiting three or four more months and buying new hardware usually gives the same speedup anyway. What really matters is programmer time, not program run time. At least most of the time. When I started programming (with punch cards 25 yrs ago) the situation was clearly different. But today? Computing power is so incredible cheap today... > What do you think *most* people would say? [...] Hard to say. But I believe people looking at Python are more interested in programmer productivity than in highly optimized performance. And don't having to worry about tedious and clumsy cleanup actions is an undeniable win in programmer productivity. This win is twofold: 1. you don't have to check, whether the objects provide a close() or a destroy() method. 2. you don't have to invent silly names for these otherwise anonymous objects. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From nowonder@nowonder.de Mon Jul 31 11:07:46 2000 From: nowonder@nowonder.de (Peter Schneider-Kamp) Date: Mon, 31 Jul 2000 10:07:46 +0000 Subject: [Python-Dev] TCP socket timeout module? Message-ID: <39854FF2.EC017E60@nowonder.de> How hard would it be to implement a functionality like this in socketmodule.c? Is such a functionality desirable? guess-this-has-been-discussed-a-thousand-times-before-ly y'rs Peter -------- Original Message -------- Subject: [ANN] TCP socket timeout module --> timeoutsocket.py Date: Sun, 30 Jul 2000 20:54:23 -0400 From: "Timothy O'Malley" Organization: Posted via Supernews, http://www.supernews.com To: python-list@python.org Newsgroups: comp.lang.python Numerous times I have seen people request a solution for TCP socket timeouts in conjunction with urllib. Recently, I found myself in the same boat. I wrote a server that would connect to skytel.com and send automated pages. Periodically, the send thread in the server would hang for a long(!) time. Yup -- I was bit by a two hour timeout built into tcp sockets. Thus, I wrote timeoutsocket.py With timeoutsocket.py, you can force *all* TCP sockets to have a timeout. And, this is all accomplished without interfering with the standard python library! Here's how to put a 20 second timeout on all TCP sockets for urllib: import timeoutsock import urllib timeoutsocket.setDefaultSocketTimeout(20) Just like that, any TCP connection made by urllib will have a 20 second timeout. If a connect(), read(), or write() blocks for more than 20 seconds, then a socket.Timeout error will be raised. Want to see how to use this in ftplib? import ftplib import timeoutsocket timeoutsocket.setDefaultSocketTimeout(20) Wasn't that easy! The timeoutsocket.py module acts as a shim on top of the standard socket module. Whenever a TCP socket is requested, an instance of TimeoutSocket is returned. This wrapper class adds timeout support to the standard TCP socket. Where can you get this marvel of modern engineering? http://www.timo-tasi.org/python/timeoutsocket.py And it will very soon be found on the Vaults of Parnassus. Good Luck! -- -- happy daze -tim O -- http://www.python.org/mailman/listinfo/python-list From mal@lemburg.com Mon Jul 31 09:13:46 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 10:13:46 +0200 Subject: [Python-Dev] SET_LINENO and python options References: <200007300239.EAA21825@python.inrialpes.fr> Message-ID: <3985353A.A8E0406C@lemburg.com> [Vladimir on removing SET_LINENO opcodes per default] Is there any reason why we can't just use traceback.tb_lineno() + maybe an equivalent C function instead of adding useless opcodes into the byte code stream ? The line number information is already stored in the co_lnotab table, so SET_LINENO is redundant in some respects. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Mon Jul 31 09:19:01 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 10:19:01 +0200 Subject: [Python-Dev] SPAM from "The Western Web Newsletter" References: <20000731020103.2B91B1CD4C@dinsdale.python.org> Message-ID: <39853675.96EA5731@lemburg.com> Could someone please add a filter to the Mailman lists to prevent these horse back advocates ?! Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Stefan.Debler@bitways.de Mon Jul 31 09:30:53 2000 From: Stefan.Debler@bitways.de (S.Debler (Bitways)) Date: Mon, 31 Jul 2000 10:30:53 +0200 Subject: [Python-Dev] Urgent inquiry for Paper bags! Message-ID: <200007310830.KAA04569@mcqueen.wolfsburg.de> Urgent inquiry for Paper bags, Dear Sirs, We are an international trading company, mainly serving the European industry. The Bitways Group purchases globally on own account and then resells the products to various clients. Our aim is to source globally and to offer our clients the best prices worldwide. From one of our own or rented databases we have retrieved your address as potential supplier of the product(s) we would like to purchase this time. If you can promptly give us your very best quote you might be chosen as the supplier we have been looking for as early as next week. In conclusion I would like to ask you to make us your best quote as this will enable us to work more efficiently. This email is confidential. If you are not the intended recipient, you must not copy, disclose or use its contents. If you have received it in error, please inform us immediately by return email and delete the document. Please check the Specifications: Inquiry for paper bags! Position Product 1 paper bag Quantity: 150 000 pcs. Productpecification: Paper bag with carrying bail. Dimensions: 320mm x 320mm + 220mm Weight : 80g/qm Material : Natronbleached Imprint : 2 colours (Manuscript is on compact or floppy disk) Packaging: In cartons. Item number has to be printed on the carton. Position Product 2 paper bag Quantity: 150 000 pcs. Productspecification: Paper bag without a carrying bail. Dimensions: 220mm x 380mm + 100mm Weight : 50g/qm Material : Natronbleached Imprint : 2 colours (Manuscript is on compact or floppy disk) Packaging: In cartons. Item number has to be printed on the carton. Position Product 3 paper bag (biscuit bag) Quantity: 19 000 000 pcs. Productspecifications: Dimensions: 140mm x 70mm x 280mm Weight : 40g/qm Material : parchment substitute Oxygen bleached Imprint : 2 colours (Manuscript is on compact or floppy disk) Packaging: In cartons. Item number has to be printed on the carton. Yours Sincerely, Stefan Debler Global Sourcing Operator Global Sourcing Team BITWAYS GLOBAL SOURCING GMBH Berliner Brücke, BZO, House 20, InnovationsCampus, D-38448 Wolfsburg, Germany Fon: +49 (0) 5361 275789 Fax: +49 (0) 5361 275799 Email: Stefan.Debler@bitways.de www.bitways.de From tim_one@email.msn.com Mon Jul 31 09:42:50 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 31 Jul 2000 04:42:50 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <14724.22554.818853.722906@bitdiddle.concentric.net> Message-ID: [Jeremy Hylton, with an excellent writeup of what he's found out about his test_fork2.py test] It's a baffler! AFAIK, nobody yet has thought of a way that a fork can screw up the state of the locks in the *parent* process (it must be easy to see how they can get screwed up in a child, because two of us already did ). But your hangs appear to be in parents, as the gdb stacktrace shows that a parent process is (presumably) hanging while trying to reacquire the global lock in the expansion of the Py_END_ALLOW_THREADS macro right after the pid = wait(&status); in posix_wait returns (#2 is from the macro expansion): #0 pthread_cond_wait (cond=0x80f297c, mutex=0x80f2988) at queue.h:25 #1 0x806fee3 in PyThread_acquire_lock (lock=0x80f2978, waitflag=1) at ../../Python/thread_pthread.h:311 #2 0x8054ec1 in PyEval_RestoreThread (tstate=0x80fb2f0) at ../../Python/ceval.c:171 #3 0x80c1242 in posix_wait (self=0x0, args=0x80f1cac) at ../../Modules/posixmodule.c:2849 However, the stacktrace shows that the parent in question is executing pthread_cond_wait, and this is the worst implementation of pthread_cond_wait in existence if it's using a busy loop to wait for the condition variable to get signaled! If this process keeps accumulating cycles, it either *is* the worst implementation in existence, or the process isn't actually hung and you just happened to capture the stack at a misleading time. The debug output may be misleading too: > ... > [lots of stuff omitted] Ouch -- wish you hadn't. Debug output is likely to come out-of-order, so without *all* of it we can't see exactly how far out of balance the acquire and release calls got. > 2051 2127 > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_release_lock(0x80f6498) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > PyThread_release_lock(0x80f6498) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > PyThread_release_lock(0x80f6498) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > 1024 2130 > PyThread_release_lock(0x80f6498) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > PyThread_release_lock(0x80f6498) called > [blocks] It's probably *not* blocking on the release: In this bunch of output, there are 7 calls to acquire, 5 calls to release, and 5 returns from acquire. That the # of release calls == the # of acquire returns suggests this output is "good enough", and if so that leaves two acquire calls waiting forever. Don't know what to do now. Obvious suggestions include putting many prints into test_fork2 so we get a better idea of what's happening, or going back to Trent's print-filled variant of test_fork1 (which I still think is an easier one to study, as it forks only once instead of unboundedly often). BTW, in *my* day, the answer to the question "what happens to a threaded program at a fork?" was to walk away laughing -- and not sure the reality of that has actually changed, regardless of how many more words they may have added to the pthreads docs in the meantime <0.7 wink>. silly-humans-ly y'rs - tim From mal@lemburg.com Mon Jul 31 09:48:51 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 10:48:51 +0200 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <14721.64041.139313.716754@anthem.concentric.net> Message-ID: <39853D73.ACBB54CA@lemburg.com> "Barry A. Warsaw" wrote: > > >>>>> "M" == M writes: > > M> These stats were created using an instrumented Python > M> interpreter running real applications (and recording all > M> executed opcodes to a file), so they can be considered close > M> enough to what Python typically does in its inner loop. > > M> If you need help, I can dig up those old tools and patches... > > If you can update them for the current CVS, I'd suggest uploading them > to SF. I'd then be willing to run Mailman for a while on an > instrumented Python to see what it does. I'll see what I can do... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Mon Jul 31 10:12:48 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 11:12:48 +0200 Subject: [Python-Dev] os.kill() on Win32 ? (Fork on Win32) References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> <20000728101015.A6542@ActiveState.com> <3981CD20.BD53BFF0@lemburg.com> <008d01bff8c2$5c99f240$f2a6b5d4@hagrid> Message-ID: <39854310.4944366@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > BTW, (pardon my ignorance) what is the most portable way to > > do the equivalent of a os.system("cmd &") as native OS > > API call ? [On Unix, "cmd &" starts a new process which runs > > in the background and detached from the calling process.] > > > > I've looked at .execve and .spawnve, but they both replace > > the current process. > > on windows, spawn(P_NOWAIT) does what you want. here's > an example from the eff-bot guide: > > # > # os-spawn-example-2.py > > import os > import string > > def run(program, *args, **kw): > # find executable > mode = kw.get("mode", os.P_WAIT) > for path in string.split(os.environ["PATH"], os.pathsep): > file = os.path.join(path, program) + ".exe" > try: > return os.spawnv(mode, file, (file,) + args) > except os.error: > pass > raise os.error, "cannot find executable" > > run("python", "hello.py", mode=os.P_NOWAIT) Cool, so os.spawnve(os.P_NOWAIT, ...) looks like a portable alternative to os.fork() for the case where you do not rely on the parent process resources being available in the child process. Next, I'll have to find out how to kill a process given its process ID under Windows... wouldn't it be possible to write an emulation of os.kill() for Win32 platforms too ? (there's a SysInfo tool for Windows which says that OpenProcess(PROCESS_TERMINATE, FALSE, pid); will do the trick -- not sure if that works as expected though). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Mon Jul 31 10:16:56 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 11:16:56 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <398065f3.6724599@smtp.worldonline.dk> <398099F1.B6B1D281@lemburg.com> <39811268.1131747@smtp.worldonline.dk> <200007281226.HAA04140@cj20424-a.reston1.va.home.com> Message-ID: <39854408.5D496075@lemburg.com> Guido van Rossum wrote: > > > Predicting the future can be difficult, but here is my take: > > javasoft will never change the way String.compareTo works. > > String.compareTo is documented as: > > """ > > Compares two strings lexicographically. The comparison is based on > > the Unicode value of each character in the strings. ... > > """ > > (Noting that their definition of "character" is probably "a 16-bit > value of type char", and has only fleeting resemblance to what is or > is not defined as a character by the Unicode standard.) > > > Instead they will mark it as a very naive string comparison and suggest > > users to use the Collator classes for anything but the simplest cases. > > Without having digested the entire discussion, this sounds like a good > solution for Python too. The "==" operator should compare strings > based on a simple-minded representation-oriented definition, and all > the other stuff gets pushed into separate methods or classes. This would probably be the best way to go: we'll need collation routines sooner or later anyway. Bill's "true UCS-4" compare could then become part of that lib. Should I #if 0 the current implementation of the UCS-4 compare in CVS ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From MarkH@ActiveState.com Mon Jul 31 10:47:14 2000 From: MarkH@ActiveState.com (Mark Hammond) Date: Mon, 31 Jul 2000 19:47:14 +1000 Subject: [Python-Dev] os.kill() on Win32 ? (Fork on Win32) In-Reply-To: <39854310.4944366@lemburg.com> Message-ID: > Next, I'll have to find out how to kill a process given > its process ID under Windows... wouldn't it be possible to hprocess = OpenProcess( accessFlags, bInherit, pid ); TerminateProcess(hprocess, exitCode); The hard bit on Win32 is finding the PID when you only have the process name (for example) but it sounds like you dont have that specific problem... Mark. From Vladimir.Marangozov@inrialpes.fr Mon Jul 31 11:16:17 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 12:16:17 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <3985353A.A8E0406C@lemburg.com> from "M.-A. Lemburg" at Jul 31, 2000 10:13:46 AM Message-ID: <200007311016.MAA12484@python.inrialpes.fr> M.-A. Lemburg wrote: > > [Vladimir on removing SET_LINENO opcodes per default] > > Is there any reason why we can't just use traceback.tb_lineno() > + maybe an equivalent C function instead of adding useless opcodes > into the byte code stream ? > Yes - you seem to have missed half the story . How would you generate callbacks (fire "line" events) from within the mainloop when a sys.settrace function is set and the PC starts executing opcodes corresponding to a new line number? Note that we don't "add" any new opcodes, and in the scheme I presented CALL_TRACE is also internal to eval_code2(), like the copy of co_code, but I eventually decided to show it in opcodes.h. SET_LINENO is not generated anymore and is reduced to a NOOP in ceval, CALL_TRACE is introduced only for the callbacks. For b/w compatibility (of .pyc files) I think we can't just "get rid" of it. And now that the game is over with finding the solution to f.f_lineno's access, the proposal about "python -g" which preserves SET_LINENO makes sense (at least for visualizing SET_LINENO in a disassembly). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal@lemburg.com Mon Jul 31 11:21:09 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 12:21:09 +0200 Subject: [Python-Dev] os.kill() on Win32 ? (Fork on Win32) References: Message-ID: <39855315.4E14C432@lemburg.com> Mark Hammond wrote: > > > Next, I'll have to find out how to kill a process given > > its process ID under Windows... wouldn't it be possible to > > hprocess = OpenProcess( accessFlags, bInherit, pid ); > TerminateProcess(hprocess, exitCode); Would it make sense to add something like this to posixmodule.c as emulation of the Unix kill() on Win32 ? Here's the manpage for reference: SYNOPSIS #include #include int kill(pid_t pid, int sig); DESCRIPTION The kill system call can be used to send any signal to any process group or process. If pid is positive, then signal sig is sent to pid. If pid equals 0, then sig is sent to every process in the process group of the current process. If pid equals -1, then sig is sent to every process except for the first one, from higher numbers in the process table to lower. If pid is less than -1, then sig is sent to every process in the process group -pid. If sig is 0, then no signal is sent, but error checking is still performed. RETURN VALUE On success, zero is returned. On error, -1 is returned, and errno is set appropriately. > The hard bit on Win32 is finding the PID when you only have the process > name (for example) but it sounds like you dont have that specific > problem... Not really, since my server manages its own set of processes and knows the different PIDs. It keeps track of what the processes currently do and terminates the ones that act in unexpected ways, e.g. due to programming errors. On Unix this results in a high availability bug tolerant server application which allows running user written code. My future goal would be porting it to Win2k, provided the needed APIs are available (or can be emulated in some way). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Mon Jul 31 11:35:36 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 31 Jul 2000 12:35:36 +0200 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <200007311016.MAA12484@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Mon, Jul 31, 2000 at 12:16:17PM +0200 References: <3985353A.A8E0406C@lemburg.com> <200007311016.MAA12484@python.inrialpes.fr> Message-ID: <20000731123536.K266@xs4all.nl> On Mon, Jul 31, 2000 at 12:16:17PM +0200, Vladimir Marangozov wrote: > SET_LINENO is not generated anymore and is reduced to a NOOP in ceval, > CALL_TRACE is introduced only for the callbacks. For b/w compatibility > (of .pyc files) I think we can't just "get rid" of it. Why not, except for the possible desirability of a -g flag that does use it? If you up the bytecode magic, which several other things in the pipeline are going to do anyway (augmented assignment, range literals, list comprehensions) old bytecode will be recompiled, and new bytecode will not be used on old interpreters. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Mon Jul 31 11:35:38 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 12:35:38 +0200 Subject: [Python-Dev] SET_LINENO and python options References: <200007311016.MAA12484@python.inrialpes.fr> Message-ID: <3985567A.2E4FDC79@lemburg.com> Vladimir Marangozov wrote: > > M.-A. Lemburg wrote: > > > > [Vladimir on removing SET_LINENO opcodes per default] > > > > Is there any reason why we can't just use traceback.tb_lineno() > > + maybe an equivalent C function instead of adding useless opcodes > > into the byte code stream ? > > > > Yes - you seem to have missed half the story . How would you > generate callbacks (fire "line" events) from within the mainloop > when a sys.settrace function is set and the PC starts executing > opcodes corresponding to a new line number? Good question :-) You're right: I forgot about the trace function call in the SET_LINENO opcode. > Note that we don't "add" any new opcodes, and in the scheme I presented > CALL_TRACE is also internal to eval_code2(), like the copy of co_code, > but I eventually decided to show it in opcodes.h. With "add" I meant the SET_LINENO opcode... remove the "useless" from my comment above ;-) > SET_LINENO is not generated anymore and is reduced to a NOOP in ceval, > CALL_TRACE is introduced only for the callbacks. For b/w compatibility > (of .pyc files) I think we can't just "get rid" of it. > > And now that the game is over with finding the solution to f.f_lineno's > access, the proposal about "python -g" which preserves SET_LINENO makes > sense (at least for visualizing SET_LINENO in a disassembly). BTW, we already have "python -d" which sets the debugging flag. You could simply use that flag for generating the SET_LINENO opcodes. Still, I think that the SET_LINENO issue is not really all that important: we have "python -O" which removes the opcodes. Perhaps moving the opcode a bit further down in the big switch would help CPU caches for production code (running under "python -O")... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pf@artcom-gmbh.de Mon Jul 31 11:45:53 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Mon, 31 Jul 2000 12:45:53 +0200 (MEST) Subject: doctest.py and testing frameworks (was Re: [Python-Dev] Fire, may I present accellerant. Accellerant, thi...) In-Reply-To: <20000730215059.OSQC24904.mail.rdc1.wa.home.com@finin> from Mitchell Morris at "Jul 30, 2000 2:51:30 pm" Message-ID: Hi, Mitchell Morris wrote to me: > Peter: > > Thanks for reading my post, and I especially appreciate your taking > the time and effort to respond. I also appreciate that you didn't take > me to task for using "it's" instead of "its" as the possessive form. > (I've been completely reeducated now, I assure you). As I'm not > currently a subscriber to python-dev, I don't know if this should > have been replied to the list or directly to you, so I'm sending it to > you only. If you feel it appropriate, please redistribute it as you > wish. [...I wrote to Mitchell:...] > > I've used doctest in my own code and found the idea to integrate > > test cases as sequences of calling code and expected result tuples > > as documentation (exmaples of use) into the doc string of modules, > > classes and methods very appealing. > > > > However this promising approach needs further work: Especially > > GUI parts can't be tested this way and in larger contexts, it > > is indeed very tedious to place *all* test code into doc strings. > > Often you need to prepare a defined starting point for the tests > > of several methods. It is not easy to decide, where to put this. > > I used doctest rather extensively a little while ago, but it was only > the vanilla variant originally posted by Tim. I thought it was really an > excellent work, but ran into similar stumbling blocks. The largest > issue for me was the aggregation of several modules worth of tests > into larger chunks, but I now know (from what I had to build to > complete the test plan I was working with) that I would very shortly > have run into the problems of replicating the test environment: > preparing input files/directories/databases, creating all the > supplementary bits and pieces, etc ad nauseam. > > A secondary issue which none of these tools address yet, but I feel > will be significant eventually, is the explicit naming of inter-test > dependence. If my class B tests require using some functionality > from class A, I would want the A tests to succeed before trying the > B tests at all (assuming I'm going to run both A and B in a single > iteration). I suspect, then, that one of these candidates will require > additional work to be our complete solution; I want to make sure > that I/we are working on the best candidate possible before > spending the effort. > > > > > again, additional effort could obviously provide the missing > > > functionality. On the other hand, doctest.py isn't currently > > > part of the standard distribution. > > > > Yes. :-( > > This, I feel, represents a significant problem. We should have a > testing framework as part of the core distribution. I agree. > We have HTML > tokenizing, mail sending, RFC822 parsing, /bin/sh-like lexing, etc > etc but don't feel that providing test support to our community of > developer is appropriate? Bizarre. Perhaps even more bizarre is > that there is a non-trivial regrtest.py that is part of the distribution, > but it's hidden away and not documented. Perhaps because no one volunteered to write documentation for it. Writing docs is an tedious task especially if you are no native english speaker. > I think we are not > providing all the service to the Python community that we could > and should. You are welcome to do something about this. > One of the strengths of Python, in my experience, has been the > ease with which code is written. This makes it much easier to > convince yourself and others to refactor mercilessly; the kinds of > cruft that grow on C++ solutions are rarely seen in Python code > because we can repartition and rewrite our work much more easily. > Providing a standard means to verify functionality before refactoring > makes it much safer to proceed, since we can "prove" (for a very > loose definition of "prove") that we haven't broken anything that > anybody else cares about. I think this is a direction we should > encourage, both through example and explicit > direction/documentation. > > > > I attach my version of 'doctest' to this email. Do what you want with it. > > Currently I favour 'doctest' over 'pyunit'. > > If you don't mind, could you elaborate why you prefer doctest, or at > least what you find unpleasant about pyunit? I would like to include > this in the document for future reference, and you may even > convince me to change my vote for doctest.py instead. I must admit that I didn't had a look at PyUnit since January. I've just downloaded pyunit-1.2.0 and had a closer look at it. Nevertheless it is very hard to beat the elegance of Tim Peters approach to cut'n'paste test cases from the interpreter prompt. Although you usually get 2 lines for each test case, building the test cases is much easier in the first place. May be both approaches to unit testing can be integrated somehow? Steal the concept of 'fixtures' from PyUnit and steal the idea to define simple test cases in the doc strings from 'doctest'. It shouldn't be that hard to add a semiautomatic import hierarchy traversal tool. Regards, Peter From gvwilson@nevex.com Mon Jul 31 13:54:58 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Mon, 31 Jul 2000 08:54:58 -0400 (EDT) Subject: [Python-Dev] Internet Groupware for Scientific Collaboration Message-ID: [Not strictly related to Python development, but likely to be of interest to many readers of this list.] Jon Udell (architect of www.byte.com and O'Reilly's new Safari site, author of "Practical Internet Groupware", a Python fan) has prepared a report for Software Carpentry called "Internet Groupware for Scientific Collaboration". It is on-line at: http://www.software-carpentry.com/Groupware/report.html Hope you enjoy it, Greg Wilson From fdrake@beopen.com Mon Jul 31 16:01:14 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 31 Jul 2000 11:01:14 -0400 (EDT) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: References: <200007310234.EAA11379@python.inrialpes.fr> Message-ID: <14725.38074.60946.579456@cj42289-a.reston1.va.home.com> Ka-Ping Yee writes: > (or IDLE et al.) can just start with > > #!/usr/bin/env python -g > > and we could then drop SET_LINENO by default. Am i missing something? This #! isn't portable; the program is only guaranteed to get one parameter from the #! line ("python" in this example). Some platforms are more forgiving and just use the rest of the command line (or a maximum of 32 characters), but that means you lose the "-g" on too many platforms. The other concerns that have been brought up are fairly important as well. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Vladimir.Marangozov@inrialpes.fr Mon Jul 31 16:37:16 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 17:37:16 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <3985567A.2E4FDC79@lemburg.com> from "M.-A. Lemburg" at Jul 31, 2000 12:35:38 PM Message-ID: <200007311537.RAA22542@python.inrialpes.fr> M.-A. Lemburg wrote: > > BTW, we already have "python -d" which sets the debugging > flag. You could simply use that flag for generating the SET_LINENO > opcodes. You're right. In case someone is not on the patches list and wants to test this, here's the log message of the latest patch update: Date: 2000-Jul-31 07:57 By: marangoz Comment: Another rewrite, making this whole strategy b/w compatible according to the 1st incompatibility point a) described in: http://www.python.org/pipermail/p ython-dev/2000-July/014364.html Changes: 1. f.f_lineno is computed and updated on f_lineno attribute requests for f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated on *all* attribute accesses (in LOAD_ATTR in the main loop). 2. The standard setup does not generate SET_LINENO, but uses co_lnotab for computing the source line number (e.g. tracebacks) This is equivalent to the actual "python -O". 3. With "python -d", we fall back to the current version of the interpreter (with SET_LINENO) thus making it easy to test whether this patch fully replaces SET_LINENO's behavior. (modulo f->f_lineno accesses from legacy C code, but this is insane). IMO, this version already worths the pain to be truly tested and improved. One improvement is to define a nicer public C API for breakpoints: - PyCode_SetBreakPointAtLine(line) - PyCode_SetBreakPointAtAddr(addr) or similar, which would install a CALL_TRACE opcode in the appropriate location of the copy of co_code. Another idea is to avoid duplicating the entire co_code just for storing the CALL_TRACE opcodes. We can store them in the original and keep a table of breakpoints. Setting the breakpoints would occur whenever the sys.settrace hook is set. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470 -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From jeremy@beopen.com Mon Jul 31 17:48:32 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 31 Jul 2000 12:48:32 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.15,1.16 In-Reply-To: <200007311638.JAA27412@slayer.i.sourceforge.net> References: <200007311638.JAA27412@slayer.i.sourceforge.net> Message-ID: <14725.44512.46379.190368@bitdiddle.concentric.net> Barry, A couple of suggestions on assigning PEP numbers: Let's require at least an abstract before we assign a number. We've got a bunch of PEPs that have been assigned and never touched; all they've got is a title and a name. If we have an abstract, non-experts and non-channelers have a better chance of figuring out what the PEP is. We might also think about a deadline or time limit. If a PEP has no activity for N days (90?), it is automatically changed to status deferred. After it has been deferred, we can assign it to a new author. There's not much point in making a big list of topics that people would like to write about some day if they get the time. It looks like we now have seven PEPs with only a name and title. Jeremy From bwarsaw@beopen.com Mon Jul 31 17:56:03 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Mon, 31 Jul 2000 12:56:03 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.15,1.16 References: <200007311638.JAA27412@slayer.i.sourceforge.net> <14725.44512.46379.190368@bitdiddle.concentric.net> Message-ID: <14725.44963.961828.923053@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> A couple of suggestions on assigning PEP numbers: JH> Let's require at least an abstract before we assign a number. JH> We've got a bunch of PEPs that have been assigned and never JH> touched; all they've got is a title and a name. If we have an JH> abstract, non-experts and non-channelers have a better chance JH> of figuring out what the PEP is. JH> We might also think about a deadline or time limit. If a PEP JH> has no activity for N days (90?), it is automatically changed JH> to status deferred. After it has been deferred, we can assign JH> it to a new author. JH> There's not much point in making a big list of topics that JH> people would like to write about some day if they get the JH> time. It looks like we now have seven PEPs with only a name JH> and title. Strongly agree, and will follow these guidelines in the future. Can you add these to PEP 1? -Barry From jeremy@beopen.com Mon Jul 31 18:31:36 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 31 Jul 2000 13:31:36 -0400 (EDT) Subject: [Python-Dev] SF bug tracker Message-ID: <14725.47096.914241.264282@bitdiddle.concentric.net> Which interface do you like better: the SourceForge bug tracker or Jitterbug? I am leaning towards moving the bug database from Jitterbug at python.org to SF. The advantages of moving to SF are: - bugs, patches, and CVS all managed by the same service - bugs can be assigned to specific people for resolution - cleaner interface for searching bugs - bugs can be assigned a priority The primary disadvantage of SF is email support. Jitterbug can receive comments about a bug via email and add them to its database. The SF bug tracker does not. It works like the patch manager, requiring you to use the Web interface to add more information. The SF bug tracker will send an email message every time a bug entry is updated, but that's it. Please let me know what you think. Jeremy From guido@beopen.com Mon Jul 31 19:43:05 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 31 Jul 2000 13:43:05 -0500 Subject: [Python-Dev] SF bug tracker In-Reply-To: Your message of "Mon, 31 Jul 2000 13:31:36 -0400." <14725.47096.914241.264282@bitdiddle.concentric.net> References: <14725.47096.914241.264282@bitdiddle.concentric.net> Message-ID: <200007311843.NAA22953@cj20424-a.reston1.va.home.com> > Which interface do you like better: the SourceForge bug tracker or > Jitterbug? I am leaning towards moving the bug database from > Jitterbug at python.org to SF. > > The advantages of moving to SF are: > > - bugs, patches, and CVS all managed by the same service > - bugs can be assigned to specific people for resolution > - cleaner interface for searching bugs > - bugs can be assigned a priority > > The primary disadvantage of SF is email support. Jitterbug can > receive comments about a bug via email and add them to its database. > The SF bug tracker does not. It works like the patch manager, > requiring you to use the Web interface to add more information. > > The SF bug tracker will send an email message every time a bug entry > is updated, but that's it. I would like to add that as far as I can tell we've only received a very small number of Jitterbug bug reports via email. In fact, the only one I can find in my email archives that originated via email was PR#110, which was in fact a followup! (We got plenty of followups via email, but that was because with Jitterbug it was actually *easier* to use email than the web I/F.) (Of course, this is not counting the bugs sent directly to guido@python.org -- these are in the hundreds.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From klm@digicool.com Mon Jul 31 19:47:09 2000 From: klm@digicool.com (Ken Manheimer) Date: Mon, 31 Jul 2000 14:47:09 -0400 (EDT) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: Message-ID: On Sun, 30 Jul 2000, Ka-Ping Yee wrote: > On Sat, 29 Jul 2000, Ken Manheimer wrote: > > On Fri, 28 Jul 2000 Vladimir.Marangozov@inrialpes.fr wrote: > > > 1) python - code without SET_LINENO > > > 2) python -g - code for debugging, with SET_LINENO > > > 3) python -O - code without doc-strings. > [...] > > I would be firmly -1 on this proposal. > > Funny -- i was just about to throw in a hearty +1. > > > I see the ability to debug at whim, even when you didn't expect having to > > do so, as being a major win, part of the incremental development process. > > But you *can't* debug at whim, right? You have to have started the > debugger, so it can hook sys.settrace, before you run your program. > If you have to start the debugger anyway, then you can surely say -g. Nope. More often than not, if i'm developing something substantial, then my interpreter sessions will involve developing context, running something then having it fail, doing a pdb.pm() post mortem, and then doing a second run with pdb.run(). My life would be worse if i happened to forget to start python with the '-g' in the first place. This scenario happens even when i don't intend to be "developing", ie when i encounter bugs in random code i'm using. As it stands, i (and anyone) have recourse to poke around at will. This is the kind of thing that makes an interpreted language valuable to me in the first place, and why i'm willing to trade of a lot more than a few percent performance. (This all may be moot if the linenotab-based alternative pans out - then everyone can be happy.) > Let's suppose: > > 1. -g is turned on by default in interactive mode, since we > don't know if you're going to feel like tracing today. This would address my above concerns. > 2. Programs (like debuggers and IDEs) that know they're going > to use sys.settrace, or which contain embedded interactive > interpreters, begin with > > #!/usr/bin/env python -g > > 3. Other programs begin with the usual > > #!/usr/bin/env python > > Given this -- are there any debugging opportunities you're missing > out on? I don't see any... One important one would be connecting with a long-running process, eg something running under medusa via the medusa monitor client. Unfortunately, it looks like the monitor client currently doesn't use a pty, or uses it wrong, or something, so the debugger doesn't work right anyway - which has been a royal pain on many occasions! I could see it being worthwhile to run the server process in an economy mode, if the economy were big. For some definition of big, of course.-) Ken klm@digicool.com From thomas@xs4all.net Mon Jul 31 20:07:25 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 31 Jul 2000 21:07:25 +0200 Subject: [Python-Dev] SF bug tracker In-Reply-To: <14725.47096.914241.264282@bitdiddle.concentric.net>; from jeremy@beopen.com on Mon, Jul 31, 2000 at 01:31:36PM -0400 References: <14725.47096.914241.264282@bitdiddle.concentric.net> Message-ID: <20000731210725.N266@xs4all.nl> On Mon, Jul 31, 2000 at 01:31:36PM -0400, Jeremy Hylton wrote: > Which interface do you like better: the SourceForge bug tracker or > Jitterbug? I am leaning towards moving the bug database from > Jitterbug at python.org to SF. Without having too much experience with Jitterbug, and only the 'read' side at that, and slightly more experience, also only on the 'read' side, with the SF buglist, I can safely say I prefer the SF bug tracker. Jitterbug is totally alien to me, the different catagories boggle me, the overviews of each catagory boggle me, and I'm not sure if I've seen everything even after I browsed through each list. But as said, I have only little experience with Jitterbug. The SF buglist might not make it too clear from the first overview in what catagory a bug belongs, but it's easily selectable, and it's very obvious which bugs are open and how important they are. And it gives people more feedback on sourceforge, in case they don't read their mail ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bckfnn@worldonline.dk Mon Jul 31 20:50:58 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Mon, 31 Jul 2000 19:50:58 GMT Subject: [Python-Dev] SF bug tracker In-Reply-To: <200007311843.NAA22953@cj20424-a.reston1.va.home.com> References: <14725.47096.914241.264282@bitdiddle.concentric.net> <200007311843.NAA22953@cj20424-a.reston1.va.home.com> Message-ID: <3985d87b.12451444@smtp.worldonline.dk> [Guido van Rossum] >I would like to add that as far as I can tell we've only received a >very small number of Jitterbug bug reports via email. In that case you did not include the counts from JPythons jitterbug. Almost everything I have submitted there is through email. But do not take that as an endorsements of jitterbug. If the existing data can be moved then I'm +1 on doing so. regards, finn From trentm@ActiveState.com Mon Jul 31 21:41:26 2000 From: trentm@ActiveState.com (Trent Mick) Date: Mon, 31 Jul 2000 13:41:26 -0700 Subject: [Python-Dev] test turds? In-Reply-To: ; from moshez@math.huji.ac.il on Sat, Jul 29, 2000 at 01:17:14PM +0300 References: Message-ID: <20000731134126.A1683@ActiveState.com> On Sat, Jul 29, 2000 at 01:17:14PM +0300, Moshe Zadka wrote: > Hi! > > Recently I patched a bug in whichdb. Following Tim's advice "each bug we > find is a bug in the regression testing", I decided to write a test case > for whichdb. However, the problem is that I'm not sure where I can create > files, which must not be leftovers from the test suite. Does anyone know test_support.TESTFN is a test filename that is intended to be used by Python test scripts. Currently it is just the file '@test' in the current directory. A better mechanism might be to use the tempfile.mktemp() module and function. > of a test which creates files, and how it deals with them? [.../dist/src/Lib/test]$ grep -l 'open\b' test_*.py test_array.py test_b1.py test_b2.py test_binhex.py test_bsddb.py test_cd.py test_cpickle.py test_dbm.py test_dl.py test_exceptions.py test_fcntl.py test_gdbm.py test_gl.py test_linuxaudiodev.py test_mmap.py test_pkg.py test_popen2.py test_pty.py test_rgbimg.py test_select.py test_sunaudiodev.py test_tokenize.py test_winreg.py test_winreg2.py test_zipfile.py test_zlib.py Trent From jack@oratrix.nl Mon Jul 31 22:01:00 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 31 Jul 2000 23:01:00 +0200 Subject: [Python-Dev] test turds? In-Reply-To: Message by Trent Mick , Mon, 31 Jul 2000 13:41:26 -0700 , <20000731134126.A1683@ActiveState.com> Message-ID: <20000731210105.6F6ADE266F@oratrix.oratrix.nl> Recently, Trent Mick said: > test_support.TESTFN is a test filename that is intended to be used by Python > test scripts. Currently it is just the file '@test' in the current directory. > A better mechanism might be to use the tempfile.mktemp() module and function. test_dbm.py (and possibly a few others) use /tmp/delete_me. This leaves a nasty turd on the Mac if the test fails. (Nasty because a file called /tmp/delete_me in the Python home directory confuses the hell out of cvs:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From skip@mojam.com (Skip Montanaro) Mon Jul 31 22:54:59 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Mon, 31 Jul 2000 16:54:59 -0500 (CDT) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: References: Message-ID: <14725.62899.678602.179470@beluga.mojam.com> Tim> The most interesting dropped project "in the middle" was Skip Tim> Montanaro's Rattlesnake, which aimed to change the VM from a stack Tim> to a register model. 'e's not dead, just restin'... ;-) Skip From jack@oratrix.nl Mon Jul 31 22:59:34 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 31 Jul 2000 23:59:34 +0200 Subject: [Python-Dev] test_re fails with re==pre Message-ID: <20000731215940.28A11E266F@oratrix.oratrix.nl> Test_re now works fine if re is sre, but it still fails if re is pre. Is this an artifact of the test harness or is there still some sort of incompatibility lurking in there? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From skip@mojam.com (Skip Montanaro) Mon Jul 31 23:07:02 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Mon, 31 Jul 2000 17:07:02 -0500 (CDT) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <20000730080718.A22903@newcnri.cnri.reston.va.us> References: <200007300239.EAA21825@python.inrialpes.fr> <20000730080718.A22903@newcnri.cnri.reston.va.us> Message-ID: <14725.63622.190585.197392@beluga.mojam.com> amk> It always seemed odd to me that the current line number is always amk> kept up to date, even though 99.999% of the time, no one will care. amk> Why not just keep a small table that holds the offset in the amk> bytecode at which each line starts, and look it up when it's amk> needed? (I'm probably going to wind up seeming like a fool, responding late to this thread without having read it end-to-end, but...) Isn't that what the code object's co_lnotab is for? I thought the idea was to dispense with SET_LINENO altogether and just compute line numbers using co_lnotab on those rare occasions (debugging, tracebacks, etc) when you needed them. Skip From guido at python.org Sat Jul 1 00:57:45 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 17:57:45 -0500 Subject: [Python-Dev] Idle breakage In-Reply-To: Your message of "Fri, 30 Jun 2000 23:24:06 +0200." <046a01bfe2d9$88302360$f2a6b5d4@hagrid> References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> Message-ID: <200006302257.RAA21104@cj20424-a.reston1.va.home.com> > when's the 2.0 deadline? In a couple of hours. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Sat Jul 1 01:02:50 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 18:02:50 -0500 Subject: [Python-Dev] Idle breakage In-Reply-To: Your message of "Fri, 30 Jun 2000 23:39:26 +0200." <049601bfe2db$acea1380$f2a6b5d4@hagrid> References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> Message-ID: <200006302302.SAA21232@cj20424-a.reston1.va.home.com> > confirmed. SRE implements $ exactly as described in > the library reference, RE doesn't ;-) All this is done to match what Perl does. :-( > patch coming within 30 minutes. Saw it. Thanks! But I still get warnings in IDLE: Failed to load extension 'ParenMatch' Traceback (most recent call last): File "../Tools/idle/EditorWindow.py", line 529, in load_standard_extensions self.load_extension(name) File "../Tools/idle/EditorWindow.py", line 539, in load_extension mod = __import__(name, globals(), locals(), []) File "/projects/python/develop/guido/src/Tools/idle/ParenMatch.py", line 15, in ? import PyParse File "/projects/python/develop/guido/src/Tools/idle/PyParse.py", line 14, in ? _synchre = re.compile(r""" File "./../Lib/sre.py", line 54, in compile return _compile(pattern, flags) File "./../Lib/sre.py", line 86, in _compile p = sre_compile.compile(pattern, flags) File "./../Lib/sre_compile.py", line 217, in compile _compile(code, p.data, flags) File "./../Lib/sre_compile.py", line 121, in _compile emit(ATCODES[AT_MULTILINE[av]]) KeyError: at_boundary --Guido van Rossum (home page: http://www.python.org/~guido/) From effbot at telia.com Sat Jul 1 00:14:49 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 00:14:49 +0200 Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> Message-ID: <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> guido wrote: > > confirmed. SRE implements $ exactly as described in > > the library reference, RE doesn't ;-) > > All this is done to match what Perl does. :-( guess we have to update the docs; I'll take care of that when I've recovered from all this... > emit(ATCODES[AT_MULTILINE[av]]) > KeyError: at_boundary sigh. with ~1000 patterns in my collection of test scripts, one could have hoped I'd seen it all. but that's a new one. patch coming within 30 minutes (when will I ever sleep?) From guido at python.org Sat Jul 1 01:10:30 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 18:10:30 -0500 Subject: [Python-Dev] Oops on AIX In-Reply-To: Your message of "Fri, 30 Jun 2000 19:52:15 +0200." <200006301752.TAA22474@python.inrialpes.fr> References: <200006301752.TAA22474@python.inrialpes.fr> Message-ID: <200006302310.SAA21344@cj20424-a.reston1.va.home.com> > After the CVS commit storm that occurred during the last 3 days, > I wanted to validate the current build on AIX. And I am stalled. > > I am not sure, but it seems like the errors I get relate with the > latest 64-bit support patches, and I don't dare to suggest corrections > in this area, so I welcome any help... let me suggest patches... If these work, please check them in: > xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c > "methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed. Index: methodobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/methodobject.c,v retrieving revision 2.28 diff -c -r2.28 methodobject.c *** methodobject.c 2000/06/30 15:01:00 2.28 --- methodobject.c 2000/06/30 22:09:55 *************** *** 180,186 **** if (x == -1) return -1; } ! y = _Py_HashPointer(a->m_ml->ml_meth); if (y == -1) return -1; x ^= y; --- 180,186 ---- if (x == -1) return -1; } ! y = _Py_HashPointer((void*)(a->m_ml->ml_meth)); if (y == -1) return -1; x ^= y; > xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c > "./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined. > "./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h. > make: 1254-004 The error code from the last command is 1. Index: posixmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v retrieving revision 2.138 diff -c -r2.138 posixmodule.c *** posixmodule.c 2000/06/29 21:12:41 2.138 --- posixmodule.c 2000/06/30 22:10:39 *************** *** 285,290 **** --- 285,291 ---- #endif /* choose the appropriate stat and fstat functions and return structs */ + #undef STAT #ifdef MS_WIN64 # define STAT _stati64 # define FSTAT _fstati64 --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Sat Jul 1 01:14:05 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 18:14:05 -0500 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: Your message of "Fri, 30 Jun 2000 11:43:14 MST." References: Message-ID: <200006302314.SAA21371@cj20424-a.reston1.va.home.com> > Not that I hope to override the heavy -1, but I don't agree with the second > point. It embodies a huge amount of knowledge that is needed to write > portable code. As such, IMO, it _does_ belong in the standard library. How > is it different in its nature from sys.platform, which is only a much weaker > version of the same concept? A more subtle way of stating my opinion could be: if we were to do something in the standard distribution about the problems that this is addressing, I think we would do it in a much more direct fashion, e.g. by making the appropriate enquiry functions directly accessible. --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw at beopen.com Sat Jul 1 00:15:34 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 18:15:34 -0400 (EDT) Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> Message-ID: <14685.7174.668568.445940@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> patch coming within 30 minutes (when will I ever sleep?) When WE say you can :) -Barry From DavidA at ActiveState.com Sat Jul 1 00:20:12 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 30 Jun 2000 15:20:12 -0700 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <200006302314.SAA21371@cj20424-a.reston1.va.home.com> Message-ID: > > Not that I hope to override the heavy -1, but I don't agree > with the second > > point. It embodies a huge amount of knowledge that is needed to write > > portable code. As such, IMO, it _does_ belong in the standard > library. How > > is it different in its nature from sys.platform, which is only > a much weaker > > version of the same concept? > > A more subtle way of stating my opinion could be: if we were to do > something in the standard distribution about the problems that this is > addressing, I think we would do it in a much more direct fashion, > e.g. by making the appropriate enquiry functions directly accessible. > > --Guido van Rossum (home page: http://www.python.org/~guido/) I much prefer that answer, as it leaves the door open to a patch. I don't care about the implementation, just the feature. Thanks. --david From effbot at telia.com Sat Jul 1 00:36:55 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 00:36:55 +0200 Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> Message-ID: <050501bfe2e3$b2517680$f2a6b5d4@hagrid> > > KeyError: at_boundary > > sigh. with ~1000 patterns in my collection of test scripts, > one could have hoped I'd seen it all. but that's a new one. umm. I'm not sure I want to check this one in. of all stupid bugs... I really gotta do something about that regression test suite. (don't worry, the patch is on its way. unfortunately, my setup is botched, so I cannot test drive IDLE myself. or to put it another way, I cannot guarantee that this is the last problem with IDLE+SRE...) From bwarsaw at beopen.com Sat Jul 1 00:37:20 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 18:37:20 -0400 (EDT) Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> <050501bfe2e3$b2517680$f2a6b5d4@hagrid> Message-ID: <14685.8480.389966.608982@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> (don't worry, the patch is on its way. unfortunately, my FL> setup is botched, so I cannot test drive IDLE myself. or FL> to put it another way, I cannot guarantee that this is the FL> last problem with IDLE+SRE...) Go ahead and check it in. I'll run idle and see wot hoppens. -B From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 00:46:37 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 00:46:37 +0200 (CEST) Subject: [Python-Dev] Oops on AIX In-Reply-To: <200006302310.SAA21344@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 30, 2000 06:10:30 PM Message-ID: <200006302246.AAA23519@python.inrialpes.fr> Guido van Rossum wrote: > > let me suggest patches... If these work, please check them in: Yes, they do, thanks! (I can't check them in) There's one error left, occuring at two locations in the signalmodule, but I think the solution would be to have an appropriate cast: "./signalmodule.c", line 359.49: 1506-280 (E) Function argument assignment between types "void*" and "void(*)(int)" is not allowed. "./signalmodule.c", line 363.48: 1506-280 (E) Function argument assignment between types "void*" and "void(*)(int)" is not allowed. > > > xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c > > "methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed. > > > Index: methodobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/methodobject.c,v > retrieving revision 2.28 > diff -c -r2.28 methodobject.c > *** methodobject.c 2000/06/30 15:01:00 2.28 > --- methodobject.c 2000/06/30 22:09:55 > *************** > *** 180,186 **** > if (x == -1) > return -1; > } > ! y = _Py_HashPointer(a->m_ml->ml_meth); > if (y == -1) > return -1; > x ^= y; > --- 180,186 ---- > if (x == -1) > return -1; > } > ! y = _Py_HashPointer((void*)(a->m_ml->ml_meth)); > if (y == -1) > return -1; > x ^= y; > > > > > xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c > > "./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined. > > "./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h. > > make: 1254-004 The error code from the last command is 1. > > Index: posixmodule.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v > retrieving revision 2.138 > diff -c -r2.138 posixmodule.c > *** posixmodule.c 2000/06/29 21:12:41 2.138 > --- posixmodule.c 2000/06/30 22:10:39 > *************** > *** 285,290 **** > --- 285,291 ---- > #endif > > /* choose the appropriate stat and fstat functions and return structs */ > + #undef STAT > #ifdef MS_WIN64 > # define STAT _stati64 > # define FSTAT _fstati64 > > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From fdrake at beopen.com Sat Jul 1 00:46:18 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 18:46:18 -0400 (EDT) Subject: [Python-Dev] Idle breakage In-Reply-To: <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> Message-ID: <14685.9018.355154.468866@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > guess we have to update the docs; I'll take care of that > when I've recovered from all this... The docs are frozen & published for this release, so next week is fine. ** THANKS! ** > patch coming within 30 minutes (when will I ever sleep?) You sleep??? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From effbot at telia.com Sat Jul 1 01:35:49 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 01:35:49 +0200 Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca><046a01bfe2d9$88302360$f2a6b5d4@hagrid><049601bfe2db$acea1380$f2a6b5d4@hagrid><200006302302.SAA21232@cj20424-a.reston1.va.home.com><04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid><050501bfe2e3$b2517680$f2a6b5d4@hagrid> <14685.8480.389966.608982@anthem.concentric.net> Message-ID: <056501bfe2ec$5876c080$f2a6b5d4@hagrid> barry wrote: > Go ahead and check it in. I'll run idle and see wot hoppens. well? can I go to sleep now? please? From guido at python.org Sat Jul 1 02:35:35 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 19:35:35 -0500 Subject: [Python-Dev] Idle breakage In-Reply-To: Your message of "Sat, 01 Jul 2000 01:35:49 +0200." <056501bfe2ec$5876c080$f2a6b5d4@hagrid> References: <20000630143148.A9725@acs.ucalgary.ca><046a01bfe2d9$88302360$f2a6b5d4@hagrid><049601bfe2db$acea1380$f2a6b5d4@hagrid><200006302302.SAA21232@cj20424-a.reston1.va.home.com><04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid><050501bfe2e3$b2517680$f2a6b5d4@hagrid> <14685.8480.389966.608982@anthem.concentric.net> <056501bfe2ec$5876c080$f2a6b5d4@hagrid> Message-ID: <200007010035.TAA22470@cj20424-a.reston1.va.home.com> > barry wrote: > > > Go ahead and check it in. I'll run idle and see wot hoppens. > > well? can I go to sleep now? please? Yes. Thanks! --Guido van Rossum (home page: http://www.python.org/~guido/) From nascheme at enme.ucalgary.ca Sat Jul 1 01:41:54 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 17:41:54 -0600 Subject: [Python-Dev] Updating patches on SF Message-ID: <20000630174154.A18362@acs.ucalgary.ca> WTF is going on? I did successfully update one of my patches but now that feature no longer seems to work. I get the message: Patch Uploaded Successfully Added Patch Could Not Send Patch Update and the old patch remains. Neil From nascheme at enme.ucalgary.ca Sat Jul 1 01:46:43 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 17:46:43 -0600 Subject: [Python-Dev] Updating patches on SF In-Reply-To: <20000630174154.A18362@acs.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Fri, Jun 30, 2000 at 05:41:54PM -0600 References: <20000630174154.A18362@acs.ucalgary.ca> Message-ID: <20000630174643.A18492@acs.ucalgary.ca> Killing the disk and memory cache seemed to fix the problem. Neil From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 02:13:37 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 02:13:37 +0200 (CEST) Subject: [Python-Dev] test_array failure on AIX Message-ID: <200007010013.CAA28135@python.inrialpes.fr> Any advice as to where I should look at and/or how to try fixing this? ~/python/CVS> ./python Lib/test/test_array.py **************************************** array after append: array('c', 'c') char array with 10 bytes of TESTFN appended: array('c', 'cThe quick ') char array with list appended: array('c', 'cThe quick abc') array of c after inserting another: array('c', 'ccThe quick abc') array of c converted to a list: ['c', 'c', 'T', 'h', 'e', ' ', 'q', 'u', 'i', 'c', 'k', ' ', 'a', 'b', 'c'] array of c converted to a string: 'ccThe quick abc' **************************************** array after append: array('b', [1]) array of b after inserting another: array('b', [1, 1]) array of b converted to a list: [1, 1] array of b converted to a string: '\001\001' overflow test: array('b', [-128L]) Traceback (most recent call last): File "Lib/test/test_array.py", line 137, in ? main() File "Lib/test/test_array.py", line 13, in main testtype(type, 1) File "Lib/test/test_array.py", line 132, in testtype testoverflow(type, signedLowerLimit, signedUpperLimit) File "Lib/test/test_array.py", line 25, in testoverflow raise TestFailed, "array(%s) overflowed assigning %s" %\ test_support -- test failed: array('b') overflowed assigning -128L -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at python.org Sat Jul 1 03:19:52 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 20:19:52 -0500 Subject: [Python-Dev] test_array failure on AIX In-Reply-To: Your message of "Sat, 01 Jul 2000 02:13:37 +0200." <200007010013.CAA28135@python.inrialpes.fr> References: <200007010013.CAA28135@python.inrialpes.fr> Message-ID: <200007010119.UAA24318@cj20424-a.reston1.va.home.com> > Any advice as to where I should look at and/or how to try fixing this? > > > ~/python/CVS> ./python Lib/test/test_array.py > **************************************** > array after append: array('c', 'c') > char array with 10 bytes of TESTFN appended: array('c', 'cThe quick ') > char array with list appended: array('c', 'cThe quick abc') > array of c after inserting another: array('c', 'ccThe quick abc') > array of c converted to a list: ['c', 'c', 'T', 'h', 'e', ' ', 'q', 'u', 'i', 'c', 'k', ' ', 'a', 'b', 'c'] > array of c converted to a string: 'ccThe quick abc' > **************************************** > array after append: array('b', [1]) > array of b after inserting another: array('b', [1, 1]) > array of b converted to a list: [1, 1] > array of b converted to a string: '\001\001' > overflow test: array('b', [-128L]) > Traceback (most recent call last): > File "Lib/test/test_array.py", line 137, in ? > main() > File "Lib/test/test_array.py", line 13, in main > testtype(type, 1) > File "Lib/test/test_array.py", line 132, in testtype > testoverflow(type, signedLowerLimit, signedUpperLimit) > File "Lib/test/test_array.py", line 25, in testoverflow > raise TestFailed, "array(%s) overflowed assigning %s" %\ > test_support -- test failed: array('b') overflowed assigning -128L Look at b_setitem() in arraymodule.c. What is CHAR_MIN? Do you perchance have unsigned characters??? If so, let's just replace CHAR_MIN with -128 and CHAR_MAX with 127. --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein at lyra.org Sat Jul 1 02:32:24 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 30 Jun 2000 17:32:24 -0700 Subject: [Python-Dev] proper CVS usage is a must! (was: CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32) In-Reply-To: <395CB46B.34053D3E@lemburg.com>; from mal@lemburg.com on Fri, Jun 30, 2000 at 04:53:31PM +0200 References: <200006301029.DAA25494@slayer.i.sourceforge.net> <20000630142154.968F831047C@bireme.oratrix.nl> <395CB46B.34053D3E@lemburg.com> Message-ID: <20000630173224.O29590@lyra.org> On Fri, Jun 30, 2000 at 04:53:31PM +0200, M.-A. Lemburg wrote: > > Why was the change that occurred in revision 2.31 reverted? Accident? > > > > The change log said: > > Jack Jansen: Use include "" instead of <>; and staticforward declarations > > Accident... I'll revert that change. This is symptomatic of people not being careful with their CVS usage. *ALWAYS* do a "cvs update" before any commits. If the file has changed while you're working on it, CVS will merge the changes in with yours. You will be notified if there were any conflicts. But this is a MUST. We've seen this reversal of changes twice now. Only through the careful eye of some -checkins watchers has that fact turned up. If those people weren't watching, we'd be lost. If you're going to commit changes to Python, then please take the responsibility to use CVS correctly. Thanks! -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jul 1 02:34:10 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 30 Jun 2000 17:34:10 -0700 Subject: [Python-Dev] attribution? (was: CVS: python/dist/src/Objects unicodeobject.c,2.32,2.33) In-Reply-To: <200006301458.HAA12572@slayer.i.sourceforge.net>; from lemburg@users.sourceforge.net on Fri, Jun 30, 2000 at 07:58:23AM -0700 References: <200006301458.HAA12572@slayer.i.sourceforge.net> Message-ID: <20000630173410.P29590@lyra.org> On Fri, Jun 30, 2000 at 07:58:23AM -0700, M.-A. Lemburg wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv12549/Objects > > Modified Files: > unicodeobject.c > Log Message: > Marc-Andre Lemburg : > A previous patch by Jack Jansen was accidently reverted. Is placing your email address into the log message really useful? After all, the checkin is already labeled as yours. I'm all for complete log messages, but scattering emails in there is a bit redundant. Certainly, if you commit somebody *else's* patch, then put their name in. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 02:37:39 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 02:37:39 +0200 (CEST) Subject: [Python-Dev] test_array failure on AIX In-Reply-To: <200007010119.UAA24318@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 30, 2000 08:19:52 PM Message-ID: <200007010037.CAA28255@python.inrialpes.fr> Guido van Rossum wrote: > > Look at b_setitem() in arraymodule.c. > > What is CHAR_MIN? > > Do you perchance have unsigned characters??? This answers your question: /usr/include/sys/limits.h:#define CHAR_MIN (0) /usr/include/sys/limits.h:#define SCHAR_MIN (-SCHAR_MAX - 1) > > If so, let's just replace CHAR_MIN with -128 and CHAR_MAX with 127. Yes! I #undef/define'd them like this in arraymodule.c and the test passes. Thanks! -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Sat Jul 1 02:40:25 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 30 Jun 2000 17:40:25 -0700 Subject: [Python-Dev] Checked in new PC\config.h In-Reply-To: ; from mhammond@skippinet.com.au on Sat, Jul 01, 2000 at 01:48:43AM +1000 References: Message-ID: <20000630174025.Q29590@lyra.org> On Sat, Jul 01, 2000 at 01:48:43AM +1000, Mark Hammond wrote: > Hi all, > I noticed that PC\config.h still had a reference to "Python16.lib". I > simply checked in a new version without submitting a patch or following any > other process. I hope this was appropriate. If this isn't "proper", then the process is broken. IMO, patches are for people without commit access, or when a committer wants some feedback on their patch. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Sat Jul 1 03:10:08 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 1 Jul 2000 11:10:08 +1000 Subject: [Python-Dev] Windows build issues In-Reply-To: <200006302133.QAA20696@cj20424-a.reston1.va.home.com> Message-ID: > > Also, I get a few warnings when compiling. One is about an /IZ > > (I think) option being ignored. There are a few other warnings > > as well which I didn't write down. > > Probably 6.0 flags that 5.0 doesn't have. What can we do? This was probably "/ZI". "/ZI" means "symbolic information for edit-and-continue" and is only VC6. "/Zi" means "symbolic information", and is in _all_ VC versions. /ZI doesnt give us much for Python. Im my experience, changing Pythion binaries while debugging is cute, but pretty useless as often a .py file _also_ needs changing, and Python doesnt really support "edit-and-continue" in the same way. MSVC kindly bumps a "/Zi" option to "/ZI" automatically and silently when doing the VC5->VC6 updgrade So I can see no reason not to use "/Zi" for both. From the GUI, it should be obvious - its the symbolic debug option without edit-and-continue. Mark. From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 03:51:07 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 03:51:07 +0200 (CEST) Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: from "Ka-Ping Yee" at Jun 29, 2000 05:44:35 PM Message-ID: <200007010151.DAA00574@python.inrialpes.fr> Ka-Ping Yee wrote: > > On 30 Jun 2000, Michael Hudson wrote: > > Yup, that works fine. Don't understand the details - and as I have my > > graduation ceremony tomorrow I'm going to go to bed and leave learning > > them until some other occasion! > > Cool. > > Okay, i just discovered sunau.py. Here's my real shot at > test_linuxaudiodev.py. Can you give this a try? > > > ---- test_linuxaudiodev.py ---- > from test_support import verbose, findfile, TestFailed > import linuxaudiodev > import os, sunau Yes, but this uses sunau which assumes the audioop.c module is enabled (imported by readframes(), sunau.py line 259) which might not be the case. Besides, Michael reported that it doesn't work quite right. So I'd blindly vote for Michael Hudson's improved version which uses only linuxaudiodev and plays the test sound without noise: ----------[ test_linuxaudiodev.py posted by Michael Hudson ]----------- from test_support import verbose, findfile, TestFailed import linuxaudiodev import os,struct def play_au_file(path): fp = open(path, "r") # Read the .au file header. header = fp.read(24) hdrsize, length, encoding, rate, channels = \ struct.unpack(">xxxxiiiii", header) fp.read(hdrsize - 24) data = fp.read() fp.close() # Set the data format according to the code in the .au header. if encoding == 1: size, fmt = 8, linuxaudiodev.AFMT_MU_LAW elif encoding == 2: size, fmt = 8, linuxaudiodev.AFMT_S8 elif encoding == 3: size, fmt = 16, linuxaudiodev.AFMT_S16_BE else: raise "audio format not supported" dsp = linuxaudiodev.open("w") dsp.setparameters(rate, size, channels, fmt) dsp.write(data) dsp.close() def test(): play_au_file(findfile('audiotest.au')) test() ---------------------------------------------------------------------- -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at python.org Sat Jul 1 05:35:33 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 22:35:33 -0500 Subject: [Python-Dev] Sorry. No Release. Message-ID: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> I can't say how disappointed I am: at the very last moment I have heard that I am not allowed to release Python 2.0b1 on July 1 as planned. Some last-minute issues have come up regarding the licensing from CNRI. BeOpen is going to resolve these issues as soon as possible, but it could be weeks... In the mean time, I thank everybody who worked very hard to make this release a success. We will continue to work on the SourceForge CVS repository as before. There will be a 2.0 release as soon as possible! --Guido van Rossum (home page: http://www.python.org/~guido/) From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 05:07:28 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 05:07:28 +0200 (CEST) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 30, 2000 10:35:33 PM Message-ID: <200007010307.FAA01904@python.inrialpes.fr> Guido van Rossum wrote: > > I can't say how disappointed I am: at the very last moment I have > heard that I am not allowed to release Python 2.0b1 on July 1 as > planned. Some last-minute issues have come up regarding the licensing > from CNRI. BeOpen is going to resolve these issues as soon as > possible, but it could be weeks... Doh. The premature 2.0 release excitement died prematurely > > In the mean time, I thank everybody who worked very hard to make this > release a success. We will continue to work on the SourceForge CVS > repository as before. There will be a 2.0 release as soon as > possible! Maybe it would be good to think about and define a short-term plan of action, given that we'll have a "major" release and that now we have some more time, cf. the previous discussion on the subject. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw at beopen.com Sat Jul 1 05:13:44 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 23:13:44 -0400 (EDT) Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> <050501bfe2e3$b2517680$f2a6b5d4@hagrid> <14685.8480.389966.608982@anthem.concentric.net> <056501bfe2ec$5876c080$f2a6b5d4@hagrid> Message-ID: <14685.25064.334520.654960@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: >> Go ahead and check it in. I'll run idle and see wot hoppens. FL> well? can I go to sleep now? please? Sorry, I was off-line for a while. I see Guido gave the word, but just to follow up, yes Idle works for me too. Thanks! From mhammond at skippinet.com.au Sat Jul 1 06:56:18 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 1 Jul 2000 14:56:18 +1000 Subject: [Python-Dev] Python for Windows extensions updated for Python 2.0 Message-ID: Hi all, FYI - Ive just finished checking into CVS all the changes necessary for Python 2.0. So if you update the complete Python tree from sourceforge and the Win32 extensions trees from pythonpros, you should get successful builds of everything. I recommend that you seek-and-destroy Py*16* on your machine - this will ensure that if you have missed any extension modules, you get a nice "Python16.dll not found", rather than the thread-state crash that happens if that DLL does indeed still exist. Mark. From petrilli at amber.org Sat Jul 1 07:00:16 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Sat, 1 Jul 2000 01:00:16 -0400 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <14685.1021.870885.796187@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jun 30, 2000 at 04:33:01PM -0400 References: <200006302126.QAA20621@cj20424-a.reston1.va.home.com> <14685.1021.870885.796187@bitdiddle.concentric.net> Message-ID: <20000701010016.A4402@trump.amber.org> Jeremy Hylton [jeremy at beopen.com] wrote: > Perhaps I am too easy-going, but I consider the 2.0 release a > 'dot-release' masquerading as a major revision. It might be a little > silly, but it seems even sillier to preserve a naming scheme that > makes users think that the technology is immature. I have to say I always thought Guido was a bit conservative... 1.3 -> 1.4 would have been a 3.x release from any "other company", and certainly 1.4 to 1.5 has some major new things (exception changes, etc). I think X.Y means X MAY introduce backward incompatibility, but doesn't have to. It just means major new functionality... I've seen a few of our customers go... "But wait, it's only at 1.5"... yeah, so? Chris -- | Christopher Petrilli | petrilli at amber.org From skip at mojam.com Sat Jul 1 09:07:00 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 1 Jul 2000 02:07:00 -0500 (CDT) Subject: [Python-Dev] barest beginnings of test coverage results Message-ID: <14685.39060.785993.960514@beluga.mojam.com> I compiled the Python interpreter with the flags necessary to get statement and branch coverage information then generated coverage files using the GNU coverage tool, gcov. If you'd like a peek at the coverage files, have a look at http://www.musi-cal.com/~skip/python/Python/dist/src/ The statement/branch coverage information is for one run of executing Lib/test/regrtest.py. Anywhere there is a C source file with coverage info the filename will end in ".c.gcov". I will eventually segregate the coverage files into a parallel tree and not mix them with the build tree. I would also like to adjust the regrtest.py stuff to generate statement coverage for .py files using my trace module: http://www.musi-cal.com/~skip/python/trace.py. For an example of how far this sort of thing can go, poke around in VTK's nightly quality dashboard: http://public.kitware.com/vtk/quality/MostRecentResults/ The VTK gang has been doing this for a couple years and now displays the following information: * pass/fail and faster/slower summaries of their nightly regression tests * code coverage information (using gcc/gcov as I'm doing) * all this on eight different Unix platforms each night Skip From martin at loewis.home.cs.tu-berlin.de Sat Jul 1 09:47:20 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 1 Jul 2000 09:47:20 +0200 Subject: [Python-Dev] Minidom and Unicode Message-ID: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> While trying the minidom parser from the current CVS, I found that repr apparently does not work for nodes: Python 2.0b1 (#29, Jun 30 2000, 10:48:11) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from xml.dom.minidom import parse >>> d=parse("/usr/src/python/Doc/tools/sgmlconv/conversion.xml") >>> d.childNodes [Traceback (most recent call last): File "", line 1, in ? TypeError: __repr__ returned non-string (type unicode) The problem here is that __repr__ is computed as def __repr__( self ): return "" and that self.tagName is u'conversion', so the resulting string is a unicode string. I'm not sure whose fault that is: either __repr__ should accept unicode strings, or minidom.Element.__repr__ should be changed to return a plain string, e.g. by converting tagname to UTF-8. In any case, I believe __repr__ should 'work' for these objects. Regards, Martin From effbot at telia.com Sat Jul 1 11:10:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 11:10:45 +0200 Subject: [Python-Dev] Sorry. No Release. References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> Message-ID: <00ab01bfe33c$3fc85620$f2a6b5d4@hagrid> guido wrote: > I can't say how disappointed I am: at the very last moment I have > heard that I am not allowed to release Python 2.0b1 on July 1 as > planned. Some last-minute issues have come up regarding the licensing > from CNRI. BeOpen is going to resolve these issues as soon as > possible, but it could be weeks... what's the legal status of the material on the SF site. can people download and redistribute snapshots of the CVS repository, or is it in some kind of legal limbo at this time? From gstein at lyra.org Sat Jul 1 11:09:23 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 02:09:23 -0700 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: <200006301748.KAA11055@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Fri, Jun 30, 2000 at 10:48:54AM -0700 References: <200006301748.KAA11055@slayer.i.sourceforge.net> Message-ID: <20000701020923.S29590@lyra.org> While I'm very glad that I suggested PyLong_FromVoidPtr() for issues like this, I think that returning an HKEY should probably use a PyCObject. You will then be able to supply a "free" function that can close the HKEY. Cheers, -g On Fri, Jun 30, 2000 at 10:48:54AM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/PC > In directory slayer.i.sourceforge.net:/tmp/cvs-serv11047/PC > > Modified Files: > msvcrtmodule.c _winreg.c > Log Message: > [*** Not tested as I don't have Windows running right now! ***] > > Trent Mick : > > Fix PC/msvcrtmodule.c and PC/winreg.c for Win64. Basically: > > - sizeof(HKEY) > sizeof(long) on Win64, so use PyLong_FromVoidPtr() > instead of PyInt_FromLong() to return HKEY values on Win64 > > - Check for string overflow of an arbitrary registry value (I know > that ensuring that a registry value does not overflow 2**31 characters > seems ridiculous but it is *possible*). > > Closes SourceForge patch #100517. >... -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jul 1 12:24:38 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 03:24:38 -0700 Subject: [Python-Dev] ML replies (was: CVS: python/dist/src/PCbuild readme.txt,1.5,1.6) In-Reply-To: <14684.43443.919858.897738@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Jun 30, 2000 at 10:07:47AM -0400 References: <14684.43443.919858.897738@anthem.concentric.net> Message-ID: <20000701032438.U29590@lyra.org> On Fri, Jun 30, 2000 at 10:07:47AM -0400, Barry A. Warsaw wrote: > > >>>>> "MH" == Mark Hammond writes: > > MH> [I wishing mailing-lists would agree on how they handle > MH> reply-to :-] > > It's fundamentally broken, but the problem is in the mail readers > (MUA). There's no header (that I'm aware of) that portably tells an > MUA - "Hey, for a group follow up, don't go to the original list, go > to THIS one instead, but for an individual followup (i.e. reply) still > address that to the original author." > > This is one reason why munging reply-to is evil. But in this case > we've agreed that following up to python-dev is more important than > preserving the ability to reply to the author. What about the Mail-Followup-To header? That can be helpful for some newsreaders (e.g. Mutt). Dunno how many observe it. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jul 1 12:29:59 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 03:29:59 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml/sax __init__.py,NONE,1.1 In-Reply-To: <200006291933.MAA05055@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Thu, Jun 29, 2000 at 12:33:45PM -0700 References: <200006291933.MAA05055@slayer.i.sourceforge.net> Message-ID: <20000701032959.V29590@lyra.org> Do you really want to import that many items into the xml.sax module? IMO, be specific on what is imported into xml.sax for *convenience*. Don't just import the world. Also note that the import for SAXParseException is redundant. Cheers, -g On Thu, Jun 29, 2000 at 12:33:45PM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Lib/xml/sax > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5045 > > Added Files: > __init__.py > Log Message: > > Package docstring and initialization. > > > --- NEW FILE --- > """Simple API for XML (SAX) implementation for Python. > > This module provides an implementation of the SAX 2 interface; > information about the Java version of the interface can be found at > http://www.megginson.com/SAX/. The Python version of the interface is > documented at <...>. > > This package contains the following modules: > > saxutils -- Implementation of the convenience functions normally used > to work with SAX. > > saxlib -- Implementation of the shared SAX 2 classes. > > drv_pyexpat -- Driver that allows use of the Expat parser with the classes > defined in saxlib. > > """ > > from handler import * > from expatreader import * > from _exceptions import * > from saxutils import * > from _exceptions import SAXParseException > import xmlreader > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From esr at thyrsus.com Sat Jul 1 12:52:22 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 1 Jul 2000 06:52:22 -0400 Subject: [Python-Dev] ML replies (was: CVS: python/dist/src/PCbuild readme.txt,1.5,1.6) In-Reply-To: <20000701032438.U29590@lyra.org>; from gstein@lyra.org on Sat, Jul 01, 2000 at 03:24:38AM -0700 References: <14684.43443.919858.897738@anthem.concentric.net> <20000701032438.U29590@lyra.org> Message-ID: <20000701065222.A31221@thyrsus.com> Greg Stein : > > This is one reason why munging reply-to is evil. But in this case > > we've agreed that following up to python-dev is more important than > > preserving the ability to reply to the author. > > What about the Mail-Followup-To header? That can be helpful for some > newsreaders (e.g. Mutt). Dunno how many observe it. Eudora honors it, too. It's not an official standard, unfortunately; I was on the IETF committee where that battle was fought to a bloody draw. But it's the best you can do. -- Eric S. Raymond "The best we can hope for concerning the people at large is that they be properly armed." -- Alexander Hamilton, The Federalist Papers at 184-188 From mal at lemburg.com Sat Jul 1 13:51:43 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 13:51:43 +0200 Subject: [Python-Dev] proper CVS usage is a must! (was: CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32) References: <200006301029.DAA25494@slayer.i.sourceforge.net> <20000630142154.968F831047C@bireme.oratrix.nl> <395CB46B.34053D3E@lemburg.com> <20000630173224.O29590@lyra.org> Message-ID: <395DDB4F.F9186544@lemburg.com> Greg Stein wrote: > > On Fri, Jun 30, 2000 at 04:53:31PM +0200, M.-A. Lemburg wrote: > > > Why was the change that occurred in revision 2.31 reverted? Accident? > > > > > > The change log said: > > > Jack Jansen: Use include "" instead of <>; and staticforward declarations > > > > Accident... I'll revert that change. > > This is symptomatic of people not being careful with their CVS usage. > > *ALWAYS* do a "cvs update" before any commits. If the file has changed while > you're working on it, CVS will merge the changes in with yours. You will be > notified if there were any conflicts. > > But this is a MUST. We've seen this reversal of changes twice now. Only > through the careful eye of some -checkins watchers has that fact turned up. > If those people weren't watching, we'd be lost. > > If you're going to commit changes to Python, then please take the > responsibility to use CVS correctly. Hey, Greg, stay cool :-) The accident happened because I had to modify Trent's patch to make it apply correctly and I forgot to update the *copy* of the CVS tree in which I edited the changes. I always do a cvs update to my local CVS version before the checkins, in fact, the small script I posted to this list does the checking for me and won't accept the checkins if the local version is out of sync. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jul 1 13:55:02 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 13:55:02 +0200 Subject: [Python-Dev] attribution? (was: CVS: python/dist/src/Objects unicodeobject.c,2.32,2.33) References: <200006301458.HAA12572@slayer.i.sourceforge.net> <20000630173410.P29590@lyra.org> Message-ID: <395DDC16.2768421C@lemburg.com> Greg Stein wrote: > > On Fri, Jun 30, 2000 at 07:58:23AM -0700, M.-A. Lemburg wrote: > > Update of /cvsroot/python/python/dist/src/Objects > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv12549/Objects > > > > Modified Files: > > unicodeobject.c > > Log Message: > > Marc-Andre Lemburg : > > A previous patch by Jack Jansen was accidently reverted. > > Is placing your email address into the log message really useful? After all, > the checkin is already labeled as yours. > > I'm all for complete log messages, but scattering emails in there is a bit > redundant. > > Certainly, if you commit somebody *else's* patch, then put their name in. I wasn't sure whether the person who checks in patches appears in the CVS log, so I added the name and email in front of the message. I'll remove the note in my checkin script. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jul 1 13:56:44 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 13:56:44 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <200006302314.SAA21371@cj20424-a.reston1.va.home.com> Message-ID: <395DDC7C.4285D56A@lemburg.com> Guido van Rossum wrote: > > > Not that I hope to override the heavy -1, but I don't agree with the second > > point. It embodies a huge amount of knowledge that is needed to write > > portable code. As such, IMO, it _does_ belong in the standard library. How > > is it different in its nature from sys.platform, which is only a much weaker > > version of the same concept? > > A more subtle way of stating my opinion could be: if we were to do > something in the standard distribution about the problems that this is > addressing, I think we would do it in a much more direct fashion, > e.g. by making the appropriate enquiry functions directly accessible. platform.py does use the available functions on a couple of platforms... and it itself provides direct enquiry functions for Python programs to use. Perhaps I'm misunderstanding you here. Anyway, it's there for non-core programs to use and so far I think the core lib has managed to switch on sys.platform and do the right thing, so platform.py may not be all that necessary in the core. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jul 1 14:02:55 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 14:02:55 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> Message-ID: <395DDDEF.4ABB5BFC@lemburg.com> "Martin v. Loewis" wrote: > > While trying the minidom parser from the current CVS, I found that > repr apparently does not work for nodes: > > Python 2.0b1 (#29, Jun 30 2000, 10:48:11) [GCC 2.95.2 19991024 (release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> from xml.dom.minidom import parse > >>> d=parse("/usr/src/python/Doc/tools/sgmlconv/conversion.xml") > >>> d.childNodes > [Traceback (most recent call last): > File "", line 1, in ? > TypeError: __repr__ returned non-string (type unicode) > > The problem here is that __repr__ is computed as > > def __repr__( self ): > return "" > > and that self.tagName is u'conversion', so the resulting string is a > unicode string. > > I'm not sure whose fault that is: either __repr__ should accept > unicode strings, or minidom.Element.__repr__ should be changed to > return a plain string, e.g. by converting tagname to UTF-8. In any > case, I believe __repr__ should 'work' for these objects. Note that __repr__ has to return a string object (and IIRC this is checked in object.c or abstract.c). The correct way to get there is to simply return str(...) or to have a switch on the type of self.tagName and then call .encode(). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Sat Jul 1 15:21:12 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 01 Jul 2000 08:21:12 -0500 Subject: [Python-Dev] barest beginnings of test coverage results In-Reply-To: Your message of "Sat, 01 Jul 2000 02:07:00 EST." <14685.39060.785993.960514@beluga.mojam.com> References: <14685.39060.785993.960514@beluga.mojam.com> Message-ID: <200007011321.IAA09485@cj20424-a.reston1.va.home.com> > I compiled the Python interpreter with the flags necessary to get statement > and branch coverage information then generated coverage files using the GNU > coverage tool, gcov. If you'd like a peek at the coverage files, have a > look at > > http://www.musi-cal.com/~skip/python/Python/dist/src/ > > The statement/branch coverage information is for one run of executing > Lib/test/regrtest.py. Wow, Skip! Very impressive. But there's soooooo much data... How do we find the gems? Should we just look at one file per day and try to add testcases that get rid of the ##### comments? Is there a way to sort the files based on the number or significance of the ##### comments? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From akuchlin at cnri.reston.va.us Sat Jul 1 14:28:29 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 1 Jul 2000 08:28:29 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <200007010335.WAA29653@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 10:35:33PM -0500 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> Message-ID: <20000701082829.C2345@newcnri.cnri.reston.va.us> On Fri, Jun 30, 2000 at 10:35:33PM -0500, Guido van Rossum wrote: >I can't say how disappointed I am: at the very last moment I have >heard that I am not allowed to release Python 2.0b1 on July 1 as >planned. Some last-minute issues have come up regarding the licensing I'm not convinced this delay is wholly a bad thing. Did Barry ever track down the mysterious crashes he was seeing from running the test suite? And it's more time to experiment with the garbage collection, hunt for SRE bugs, and so forth. --amk From martin at loewis.home.cs.tu-berlin.de Sat Jul 1 14:22:39 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 1 Jul 2000 14:22:39 +0200 Subject: [Python-Dev] Minidom and Unicode In-Reply-To: <395DDDEF.4ABB5BFC@lemburg.com> (mal@lemburg.com) References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> Message-ID: <200007011222.OAA11088@loewis.home.cs.tu-berlin.de> > Note that __repr__ has to return a string object (and IIRC > this is checked in object.c or abstract.c). The correct way > to get there is to simply return str(...) or to have a > switch on the type of self.tagName and then call .encode(). Ok. I believe tagName will be always a Unicode object (as mandated by the DOM API), so I propose patch 100706 (http://sourceforge.net/patch/?func=detailpatch&patch_id=100706&group_id=5470) Regards, Martin From guido at beopen.com Sat Jul 1 15:46:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 01 Jul 2000 08:46:29 -0500 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: Your message of "Sat, 01 Jul 2000 08:28:29 -0400." <20000701082829.C2345@newcnri.cnri.reston.va.us> References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> Message-ID: <200007011346.IAA09576@cj20424-a.reston1.va.home.com> > I'm not convinced this delay is wholly a bad thing. Did Barry ever > track down the mysterious crashes he was seeing from running the test > suite? And it's more time to experiment with the garbage collection, > hunt for SRE bugs, and so forth. But that's what beta releases are for, right? The result now is that fewer people will try out the code than if it were released today, and the final release will undoubtedly be delayed again. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From effbot at telia.com Sat Jul 1 14:52:51 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 14:52:51 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> Message-ID: <010601bfe35b$46727ae0$f2a6b5d4@hagrid> mal wrote: > > I'm not sure whose fault that is: either __repr__ should accept > > unicode strings, or minidom.Element.__repr__ should be changed to > > return a plain string, e.g. by converting tagname to UTF-8. In any > > case, I believe __repr__ should 'work' for these objects. > > Note that __repr__ has to return a string object (and IIRC > this is checked in object.c or abstract.c). The correct way > to get there is to simply return str(...) or to have a > switch on the type of self.tagName and then call .encode(). assuming that the goal is to get rid of this restriction in future versions (a string is a string is a string), how about special- casing this in PyObject_Repr: PyObject *res; res = (*v->ob_type->tp_repr)(v); if (res == NULL) return NULL; --- if (PyUnicode_Check(res)) { PyObject* str; str = PyUnicode_AsEncodedString(res, NULL, NULL); if (str) { Py_DECREF(res); res = str; } } --- if (!PyString_Check(res)) { PyErr_Format(PyExc_TypeError, "__repr__ returned non-string (type %.200s)", res->ob_type->tp_name); Py_DECREF(res); return NULL; } return res; in this way, people can "do the right thing" in their code, and have it work better in future versions... (just say "+1", and the mad patcher will update the repository) From guido at beopen.com Sat Jul 1 16:13:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 01 Jul 2000 09:13:36 -0500 Subject: [Python-Dev] Minidom and Unicode In-Reply-To: Your message of "Sat, 01 Jul 2000 14:52:51 +0200." <010601bfe35b$46727ae0$f2a6b5d4@hagrid> References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> Message-ID: <200007011413.JAA09667@cj20424-a.reston1.va.home.com> > mal wrote: > > > I'm not sure whose fault that is: either __repr__ should accept > > > unicode strings, or minidom.Element.__repr__ should be changed to > > > return a plain string, e.g. by converting tagname to UTF-8. In any > > > case, I believe __repr__ should 'work' for these objects. > > > > Note that __repr__ has to return a string object (and IIRC > > this is checked in object.c or abstract.c). The correct way > > to get there is to simply return str(...) or to have a > > switch on the type of self.tagName and then call .encode(). [/F] > assuming that the goal is to get rid of this restriction in future > versions (a string is a string is a string), how about special- > casing this in PyObject_Repr: > > PyObject *res; > res = (*v->ob_type->tp_repr)(v); > if (res == NULL) > return NULL; > --- > if (PyUnicode_Check(res)) { > PyObject* str; > str = PyUnicode_AsEncodedString(res, NULL, NULL); > if (str) { > Py_DECREF(res); > res = str; > } > } > --- > if (!PyString_Check(res)) { > PyErr_Format(PyExc_TypeError, > "__repr__ returned non-string (type %.200s)", > res->ob_type->tp_name); > Py_DECREF(res); > return NULL; > } > return res; > > in this way, people can "do the right thing" in their code, > and have it work better in future versions... > > (just say "+1", and the mad patcher will update the repository) +1 --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul at prescod.net Sat Jul 1 15:09:20 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 08:09:20 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> Message-ID: <395DED80.A30FB417@prescod.net> "M.-A. Lemburg" wrote: > > Note that __repr__ has to return a string object (and IIRC > this is checked in object.c or abstract.c). The correct way > to get there is to simply return str(...) or to have a > switch on the type of self.tagName and then call .encode(). > ... I prefer the former solution and unless someone screams I will check that in in a few hours. Why can't repr have a special case that converts Unicode strings to "Python strings" automatically. This case is going to byte other people. > Ok. I believe tagName will be always a Unicode object (as mandated by > the DOM API), so I propose patch 100706 > (http://sourceforge.net/patch/?func=detailpatch&patch_id=100706&group_id=5470) I would like Unicode usage to be a userland option for reasons of performance and backwards compatibility. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Sat Jul 1 15:12:28 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 08:12:28 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> Message-ID: <395DEE3C.E7BAD4C3@prescod.net> Fredrik Lundh wrote: > > ... > > assuming that the goal is to get rid of this restriction in future > versions (a string is a string is a string), how about special- > casing this in PyObject_Repr: This is my prefered solution. +1 from me. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From mhammond at skippinet.com.au Sat Jul 1 15:23:21 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 1 Jul 2000 23:23:21 +1000 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: <20000701020923.S29590@lyra.org> Message-ID: > While I'm very glad that I suggested PyLong_FromVoidPtr() for issues like > this, I think that returning an HKEY should probably use a PyCObject. You > will then be able to supply a "free" function that can close the HKEY. This is exactly what we do. Trents patches are just for the functions that return the underlying handle value as an integer (which is definately a useful thing to be able to do!) Mark. From gstein at lyra.org Sat Jul 1 15:51:11 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 06:51:11 -0700 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: ; from mhammond@skippinet.com.au on Sat, Jul 01, 2000 at 11:23:21PM +1000 References: <20000701020923.S29590@lyra.org> Message-ID: <20000701065111.Z29590@lyra.org> On Sat, Jul 01, 2000 at 11:23:21PM +1000, Mark Hammond wrote: > > While I'm very glad that I suggested PyLong_FromVoidPtr() for issues like > > this, I think that returning an HKEY should probably use a PyCObject. You > > will then be able to supply a "free" function that can close the HKEY. > > This is exactly what we do. Trents patches are just for the functions that > return the underlying handle value as an integer (which is definately a > useful thing to be able to do!) But I don't understand why you want an integer. From the Python programmer's standpoint, they just want a handle, right? The safety of having the "free" function is quite nice. Without it, it would seem to be "easy" to leak handles. Without using PyCObject, we'd need a complete handle type (like the one in win32api or wherever). Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 16:23:16 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 16:23:16 +0200 (CEST) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <200007011346.IAA09576@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 01, 2000 08:46:29 AM Message-ID: <200007011423.QAA05486@python.inrialpes.fr> Guido van Rossum wrote: > > > I'm not convinced this delay is wholly a bad thing. Did Barry ever > > track down the mysterious crashes he was seeing from running the test > > suite? And it's more time to experiment with the garbage collection, > > hunt for SRE bugs, and so forth. > > But that's what beta releases are for, right? The result now is that > fewer people will try out the code than if it were released today, and > the final release will undoubtedly be delayed again. Guido, what about reverting the version number to 2.0a3 ? We're still not in a beta stage, but there *is* a new version ready, which, if not beta, should be an alpha. We're used to see the version bumped a day or two before the release. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From amk1 at erols.com Sat Jul 1 15:22:30 2000 From: amk1 at erols.com (A.M. Kuchling) Date: Sat, 1 Jul 2000 09:22:30 -0400 Subject: [Python-Dev] sysconfig/SRE bug Message-ID: <200007011322.JAA25612@207-172-146-185.s185.tnt3.ann.va.dialup.rcn.com> sysconfig.py contains a pattern that breaks SRE: >>> import re, pre >>> pre.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}") >>> re.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}") Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.0/sre.py", line 54, in compile return _compile(pattern, flags) ... File "/usr/lib/python2.0/sre_parse.py", line 538, in parse p = _parse(source, state) File "/usr/lib/python2.0/sre_parse.py", line 394, in _parse raise error, "bogus range" Escaping the { and } fix this. This is a problem with the {xxx,yyy} notation for ranges; PCRE looks ahead, and treats it as a literal unless it's followed by digits of the right form. From pypcre.c: /* This function is called when a '{' is encountered in a place where it might start a quantifier. It looks ahead to see if it really is a quantifier or not. It is only a quantifier if it is one of the forms {ddd} {ddd,} or {ddd,ddd} where the ddds are digits. */ I suppose the goal of Perl compatibility means this magical behaviour needs to be preserved? --amk From bwarsaw at beopen.com Sat Jul 1 17:16:46 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sat, 1 Jul 2000 11:16:46 -0400 (EDT) Subject: [Python-Dev] Sorry. No Release. References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> Message-ID: <14686.2910.855580.146653@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> I'm not convinced this delay is wholly a bad thing. Did Barry AK> ever track down the mysterious crashes he was seeing from AK> running the test suite? No, and Purify didn't help, although it did identify a couple of small memory leaks. Nothing more serious than that. One possible source of discrepancy though is that the machine I ran the tests on apparently didn't have enough memory (at 256MB!) to run the entire regrtest under a Purify'd Python. I'm going to continue looking though. -Barry From effbot at telia.com Sat Jul 1 17:54:29 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 17:54:29 +0200 Subject: [Python-Dev] sysconfig/SRE bug References: <200007011322.JAA25612@207-172-146-185.s185.tnt3.ann.va.dialup.rcn.com> Message-ID: <01f701bfe374$a661c500$f2a6b5d4@hagrid> andrew wrote: > sysconfig.py contains a pattern that breaks SRE: > > >>> import re, pre > >>> pre.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}") > > >>> re.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}") > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/lib/python2.0/sre.py", line 54, in compile > return _compile(pattern, flags) > ... > File "/usr/lib/python2.0/sre_parse.py", line 538, in parse > p = _parse(source, state) > File "/usr/lib/python2.0/sre_parse.py", line 394, in _parse > raise error, "bogus range" > > Escaping the { and } fix this. This is a problem with the {xxx,yyy} > notation for ranges; PCRE looks ahead, and treats it as a literal > unless it's followed by digits of the right form. From pypcre.c: > > /* This function is called when a '{' is encountered in a place where it might > start a quantifier. It looks ahead to see if it really is a quantifier or not. > It is only a quantifier if it is one of the forms {ddd} {ddd,} or {ddd,ddd} > where the ddds are digits. > */ > > I suppose the goal of Perl compatibility means this magical behaviour > needs to be preserved? I'm not so sure about this one; the $ behaviour is documented in Perl, but this isn't (as far as I can tell, at least). and since it's detected by the parser, it's probably better to change the sysconfig module... (fixing this in the sre_parser isn't exactly trivial, either...) From effbot at telia.com Sat Jul 1 17:57:08 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 17:57:08 +0200 Subject: [Python-Dev] sysconfig/SRE bug References: <200007011322.JAA25612@207-172-146-185.s185.tnt3.ann.va.dialup.rcn.com> <01f701bfe374$a661c500$f2a6b5d4@hagrid> Message-ID: <01fd01bfe375$057389c0$f2a6b5d4@hagrid> I wrote: > I'm not so sure about this one; the $ behaviour is documented > in Perl, but this isn't (as far as I can tell, at least). umm. I suppose "If a curly bracket occurs in any other context, it is treated as a regular character" is documentation enough. please ignore me. From bwarsaw at beopen.com Sat Jul 1 18:16:48 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sat, 1 Jul 2000 12:16:48 -0400 (EDT) Subject: [Python-Dev] Re: ML replies (was: CVS: python/dist/src/PCbuild readme.txt,1.5,1.6) References: <14684.43443.919858.897738@anthem.concentric.net> <20000701032438.U29590@lyra.org> Message-ID: <14686.6512.329946.694266@anthem.concentric.net> [Please remove python-dev from followups, I'm sure most of those folks don't care about this... -BAW] MM-Devers: on python-dev there's been some discussion about the Reply-to: munging that you can select on Mailman lists. Say you've got a python-checkins list that receives CVS log messages automatically. But you don't want discussions about the changes on python-checkins, you want them on python-dev. How can Mailman set up the headers on outgoing messages to get this behavior? It can't. So it fakes it by setting Reply-to: to the address of the discussion list. We now join our conversation already in progress... >>>>> "GS" == Greg Stein writes: GS> What about the Mail-Followup-To header? That can be helpful GS> for some newsreaders (e.g. Mutt). Dunno how many observe it. It looks like VM/Emacs doesn't (which is what I use), but I'm sure that'd be easy to add. I would be most interested to know what Outlook and NS do with it. However Mail-Followup-To: isn't in any RFC that I can find, not even 2076. It can be found in a discussion by Dan Bernstein[1], but that document specifically says that list managers should /not/ set it because this defeats the intended purpose. I agree - given Dan's recommendation. So there is clearly no header that will support the functionality we want. And all this crud has been debated ad-nauseum in several working groups, MUA forums, etc. with no agreement. I almost hesitate even bringing it up here. Few of the discussions that I've read (in a morning's worth of archive surfing) even mention the situation we're trying to address. One potential solution for Mailman might be to lie about the To: address. So in the above scenario, the message would have a To: field set to python-dev even though the message would actually be sent to the python-checkins membership. An elaboration on that would be to set Resent-To: to python-checkins. But those are all hacks, nearly as disgusting as what Mailman currently does. -Barry [1] http://cr.yp.to/proto/replyto.html From skip at mojam.com Sat Jul 1 18:16:31 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 1 Jul 2000 11:16:31 -0500 (CDT) Subject: [Python-Dev] barest beginnings of test coverage results In-Reply-To: <200007011321.IAA09485@cj20424-a.reston1.va.home.com> References: <14685.39060.785993.960514@beluga.mojam.com> <200007011321.IAA09485@cj20424-a.reston1.va.home.com> Message-ID: <14686.6495.370859.13048@beluga.mojam.com> Guido> But there's soooooo much data... How do we find the gems? Guido> Should we just look at one file per day and try to add testcases Guido> that get rid of the ##### comments? Is there a way to sort the Guido> files based on the number or significance of the ##### comments? All I referred you to yesterday (it was late...) was a CVS tree in which I had built the interpreter with the necessary flags, run regrtest.py, then generated coverage files. The next step is to generate one or more pages of coverage summaries. Then you'll be able to browse something like http://www.musi-cal.com/~skip/python/Python/dist/src/lines.html http://www.musi-cal.com/~skip/python/Python/dist/src/branches.html and zero in on those files with lower than desired coverage. Skip From nascheme at enme.ucalgary.ca Sat Jul 1 18:20:37 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Sat, 1 Jul 2000 10:20:37 -0600 Subject: [Python-Dev] barest beginnings of test coverage results In-Reply-To: <200007011321.IAA09485@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Sat, Jul 01, 2000 at 08:21:12AM -0500 References: <14685.39060.785993.960514@beluga.mojam.com> <200007011321.IAA09485@cj20424-a.reston1.va.home.com> Message-ID: <20000701102037.A28228@acs.ucalgary.ca> On Sat, Jul 01, 2000 at 08:21:12AM -0500, Guido van Rossum wrote: > Wow, Skip! Very impressive. But there's soooooo much data... How do > we find the gems? http://www.musi-cal.com/~skip/python/Python/dist/src/summary.html The summary seems pretty good to me. Neil From skip at mojam.com Sat Jul 1 18:24:18 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 1 Jul 2000 11:24:18 -0500 (CDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <14686.2910.855580.146653@anthem.concentric.net> References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> Message-ID: <14686.6962.530478.967290@beluga.mojam.com> AK> I'm not convinced this delay is wholly a bad thing. Did Barry ever AK> track down the mysterious crashes he was seeing from running the AK> test suite? BAW> No, and Purify didn't help, although it did identify a couple of BAW> small memory leaks. Nothing more serious than that. One possible BAW> source of discrepancy though is that the machine I ran the tests on BAW> apparently didn't have enough memory (at 256MB!) to run the entire BAW> regrtest under a Purify'd Python. I'm going to continue looking BAW> though. My guess is that -tt triggered a SyntaxError (maybe we should create an IndentationError that is a subclass of SyntaxError?) the .pyc file didn't get generated, but the exception was caught by regrtest and execution continued. That would have caused any test that tried to import the tab-challenged file(s) to fail, right? Would that have been sufficient to provoke the symptoms we saw? -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From skip at mojam.com Sat Jul 1 18:31:43 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 1 Jul 2000 11:31:43 -0500 (CDT) Subject: [Python-Dev] barest beginnings of test coverage results In-Reply-To: <20000701102037.A28228@acs.ucalgary.ca> References: <14685.39060.785993.960514@beluga.mojam.com> <200007011321.IAA09485@cj20424-a.reston1.va.home.com> <20000701102037.A28228@acs.ucalgary.ca> Message-ID: <14686.7407.760808.838286@beluga.mojam.com> >> Wow, Skip! Very impressive. But there's soooooo much data... How >> do we find the gems? Neil> http://www.musi-cal.com/~skip/python/Python/dist/src/summary.html Neil> The summary seems pretty good to me. ;-) I got to the problem after Guido responded but apparently before you surfed... Skip From esr at thyrsus.com Sat Jul 1 18:43:03 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 1 Jul 2000 12:43:03 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <14686.6962.530478.967290@beluga.mojam.com>; from skip@mojam.com on Sat, Jul 01, 2000 at 11:24:18AM -0500 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> Message-ID: <20000701124303.A31955@thyrsus.com> Skip Montanaro : > My guess is that -tt triggered a SyntaxError (maybe we should create an > IndentationError that is a subclass of SyntaxError?) +1! -- Eric S. Raymond The United States is in no way founded upon the Christian religion -- George Washington & John Adams, in a diplomatic message to Malta. From chuqui at plaidworks.com Sat Jul 1 18:34:19 2000 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Sat, 1 Jul 2000 09:34:19 -0700 Subject: [Python-Dev] [Mailman-Developers] Re: ML replies (was: CVS: python/dist/src/PCbuild readme.txt,1.5,1.6) In-Reply-To: <14686.6512.329946.694266@anthem.concentric.net> References: <14684.43443.919858.897738@anthem.concentric.net> <20000701032438.U29590@lyra.org> <14686.6512.329946.694266@anthem.concentric.net> Message-ID: At 12:16 PM -0400 7/1/00, Barry A. Warsaw wrote: > GS> What about the Mail-Followup-To header? That can be helpful > GS> for some newsreaders (e.g. Mutt). Dunno how many observe it. > >It looks like VM/Emacs doesn't (which is what I use), but I'm sure >that'd be easy to add. I would be most interested to know what >Outlook and NS do with it. > >However Mail-Followup-To: isn't in any RFC that I can find, not even >2076. It's non-standard, and in fact, arguably non-compliant, since any unofficial header should be in the X-headername form. >So there is clearly no header that will support the functionality we >want. This is a case where Reply-To is the correct header to set, or at least, least incorrect. >One potential solution for Mailman might be to lie about the To: >address. So in the above scenario, the message would have a To: field >set to python-dev even though the message would actually be sent to >the python-checkins membership. um, uh, well... I don't like it. Even if you had Sender: and List-ID set properly, it still seems wrong. For this case, I think the best setup is Reply-to, because that's waht you want: it came FROM this place, but responses go to this other place. The proper answer is setting reply-to, not attempting to rearrange the concept of "from this place". As a strong proponent of "don't use reply-to!" -- this is a case where it's the proper answer. It's not perfect by any means, since reply-to coerces someone away from replying privately, but in this situation, that's better than not doing it. -- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui at plaidworks.com) Apple Mail List Gnome (mailto:chuq at apple.com) And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'" From effbot at telia.com Sat Jul 1 18:46:08 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 18:46:08 +0200 Subject: [Python-Dev] unicode alphanumerics Message-ID: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> when looking through skip's coverage listing, I noted a bug in SRE: #define SRE_UNI_IS_ALNUM(ch) ((ch) < 256 ? isalnum((ch)) : 0) this predicate is used for \w when a pattern is compiled using the "unicode locale" (flag U), and should definitely not use 8-bit locale stuff. however, there's no such thing as a Py_UNICODE_ISALNUM (or even a Py_UNICODE_ISALPHA). what should I do? how about using: Py_UNICODE_ISLOWER || Py_UNICODE_ISUPPER || Py_UNICODE_ISTITLE || Py_UNICODE_ISDIGIT From mal at lemburg.com Sat Jul 1 18:46:52 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 18:46:52 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> Message-ID: <395E207C.91E3A2A5@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > I'm not sure whose fault that is: either __repr__ should accept > > > unicode strings, or minidom.Element.__repr__ should be changed to > > > return a plain string, e.g. by converting tagname to UTF-8. In any > > > case, I believe __repr__ should 'work' for these objects. > > > > Note that __repr__ has to return a string object (and IIRC > > this is checked in object.c or abstract.c). The correct way > > to get there is to simply return str(...) or to have a > > switch on the type of self.tagName and then call .encode(). > > assuming that the goal is to get rid of this restriction in future > versions (a string is a string is a string), how about special- > casing this in PyObject_Repr: > > PyObject *res; > res = (*v->ob_type->tp_repr)(v); > if (res == NULL) > return NULL; > --- > if (PyUnicode_Check(res)) { > PyObject* str; > str = PyUnicode_AsEncodedString(res, NULL, NULL); > if (str) { > Py_DECREF(res); > res = str; > } > } > --- > if (!PyString_Check(res)) { > PyErr_Format(PyExc_TypeError, > "__repr__ returned non-string (type %.200s)", > res->ob_type->tp_name); > Py_DECREF(res); > return NULL; > } > return res; > > in this way, people can "do the right thing" in their code, > and have it work better in future versions... > > (just say "+1", and the mad patcher will update the repository) I'd say +0, since the auto-converion can fail if the default encoding doesn't have room for the tagName characters. Either way, I'd still prefer the DOM code to use an explicit .encode() together with some lossless encoding, e.g. unicode-escape. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 18:52:50 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 18:52:50 +0200 (CEST) Subject: [Python-Dev] test, please ignore Message-ID: <200007011652.SAA05728@python.inrialpes.fr> -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 18:56:49 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 18:56:49 +0200 (CEST) Subject: [Python-Dev] Sorry. No Release. Message-ID: <200007011656.SAA05767@python.inrialpes.fr> Resending... Subject: Re: [Python-Dev] Sorry. No Release. To: guido at beopen.com (Guido van Rossum) Date: Sat, 1 Jul 2000 16:23:16 +0200 (CEST) Cc: python-dev at python.org Guido van Rossum wrote: > > > I'm not convinced this delay is wholly a bad thing. Did Barry ever > > track down the mysterious crashes he was seeing from running the test > > suite? And it's more time to experiment with the garbage collection, > > hunt for SRE bugs, and so forth. > > But that's what beta releases are for, right? The result now is that > fewer people will try out the code than if it were released today, and > the final release will undoubtedly be delayed again. Guido, what about reverting the version number to 2.0a3 ? We're still not in a beta stage, but there *is* a new version ready, which, if not beta, should be an alpha. We're used to see the version bumped a day or two before the release. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Sat Jul 1 18:56:12 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 18:56:12 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> Message-ID: <395E22AC.6BB76041@lemburg.com> Fredrik Lundh wrote: > > when looking through skip's coverage listing, I noted a bug in > SRE: > > #define SRE_UNI_IS_ALNUM(ch) ((ch) < 256 ? isalnum((ch)) : 0) > > this predicate is used for \w when a pattern is compiled using > the "unicode locale" (flag U), and should definitely not use 8-bit > locale stuff. > > however, there's no such thing as a Py_UNICODE_ISALNUM > (or even a Py_UNICODE_ISALPHA). what should I do? how > about using: > > Py_UNICODE_ISLOWER || > Py_UNICODE_ISUPPER || > Py_UNICODE_ISTITLE || > Py_UNICODE_ISDIGIT This will give you all cased chars along with all digits; it ommits the non-cased ones. It's a good start, but probably won't cover the full range of letters + numbers. Perhaps we need another table for isalpha in unicodectype.c ? (Or at least one which defines all non-cased letters.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sat Jul 1 19:13:51 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 19:13:51 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> Message-ID: <028301bfe37f$bb349380$f2a6b5d4@hagrid> mal wrote: > > Py_UNICODE_ISLOWER || > > Py_UNICODE_ISUPPER || > > Py_UNICODE_ISTITLE || > > Py_UNICODE_ISDIGIT > > This will give you all cased chars along with all digits; > it ommits the non-cased ones. but of course... > It's a good start, but probably won't cover the full range > of letters + numbers. > > Perhaps we need another table for isalpha in unicodectype.c ? > (Or at least one which defines all non-cased letters.) +1 from me (SRE needs this, and it doesn't really make much sense to add unicode tables to SRE just because the built-in ones are slightly incomplete...) how about this plan: -- you add a Py_UNICODE_ALPHA to unicodeobject.h asap, which does exactly that (or I can do that, if you prefer). (and maybe even a Py_UNICODE_ALNUM) -- I change SRE to use that asap. -- you, I, or someone else add a better implementation, some other day. From skip at mojam.com Sat Jul 1 20:54:40 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 1 Jul 2000 13:54:40 -0500 (CDT) Subject: [Python-Dev] test coverage summaries - now updated nightly Message-ID: <14686.15984.430156.148785@beluga.mojam.com> I've spent amount as much time on generating automated statement and branch coverage as I can afford for the next few days. At this point I think I have it generating a reasonable facsimile of useful output. A cron job on www.musi-cal.com does the following early each morning (4:45AM Pacific time): make clean cvs update config.status --recheck make python with gcov flags make test > testresults.txt generate coverage pages (lines.html & branches.html) The relevant output files on the web server are http://www.musi-cal.com/~skip/python/Python/dist/src/lines.html http://www.musi-cal.com/~skip/python/Python/dist/src/branches.html http://www.musi-cal.com/~skip/python/Python/dist/src/testresults.txt A couple shell scripts do all the dirty work for now: http://www.musi-cal.com/~skip/python/Python/dist/src/gencoverage http://www.musi-cal.com/~skip/python/Python/dist/src/gencoverage1 I may put an index.html file in there just to provide a little cover for the directory tree. I'll also enable a couple more modules in Modules/Setup. Skip From paul at prescod.net Sat Jul 1 21:00:20 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 14:00:20 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> Message-ID: <395E3FC4.959BB042@prescod.net> "M.-A. Lemburg" wrote: > > ... > > I'd say +0, since the auto-converion can fail if the default > encoding doesn't have room for the tagName characters. > > Either way, I'd still prefer the DOM code to use an explicit > .encode() together with some lossless encoding, e.g. > unicode-escape. If we want to use a hard-coded lossless encoding, we should do so in repr. Rather than having us fix a dozen modules with problems like this, we should fix repr once and for all. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Sat Jul 1 21:02:37 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 14:02:37 -0500 Subject: [Python-Dev] test coverage summaries - now updated nightly References: <14686.15984.430156.148785@beluga.mojam.com> Message-ID: <395E404D.FBD47947@prescod.net> Skip Montanaro wrote: > > I've spent amount as much time on generating automated statement and branch > coverage as I can afford for the next few days. At this point I think I > have it generating a reasonable facsimile of useful output. I may have missed email about this during my email troubles yesterday, but why aren't we doing coverage testing of Python code too? Or am I missing that link? -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From effbot at telia.com Sat Jul 1 21:11:34 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 21:11:34 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> Message-ID: <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> paul wrote: > If we want to use a hard-coded lossless encoding, we should do so in > repr. Rather than having us fix a dozen modules with problems like this, > we should fix repr once and for all. how about allowing str and repr to actually return unicode strings? or in other words: PyObject *res; res = (*v->ob_type->tp_repr)(v); if (res == NULL) return NULL; if (!PyString_Check(res) && !PyUnicode_Check(res)) { PyErr_Format(PyExc_TypeError, "__repr__ returned non-string (type %.200s)", res->ob_type->tp_name); Py_DECREF(res); return NULL; } return res; (strings are strings are strings, etc) From effbot at telia.com Sat Jul 1 21:13:35 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 21:13:35 +0200 Subject: [Python-Dev] test coverage summaries - now updated nightly References: <14686.15984.430156.148785@beluga.mojam.com> <395E404D.FBD47947@prescod.net> Message-ID: <02b601bfe390$774a0a40$f2a6b5d4@hagrid> paul wrote: > Skip Montanaro wrote: > > > > I've spent amount as much time on generating automated statement and branch > > coverage as I can afford for the next few days. At this point I think I > > have it generating a reasonable facsimile of useful output. > > I may have missed email about this during my email troubles yesterday, > but why aren't we doing coverage testing of Python code too? Or am I > missing that link? from Skip's original mail: /.../ I would also like to adjust the regrtest.py stuff to generate statement coverage for .py files using my trace module: http://www.musi-cal.com/~skip/python/trace.py. From mal at lemburg.com Sat Jul 1 21:22:10 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 21:22:10 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> <028301bfe37f$bb349380$f2a6b5d4@hagrid> Message-ID: <395E44E2.63383BC5@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > Py_UNICODE_ISLOWER || > > > Py_UNICODE_ISUPPER || > > > Py_UNICODE_ISTITLE || > > > Py_UNICODE_ISDIGIT > > > > This will give you all cased chars along with all digits; > > it ommits the non-cased ones. > > but of course... > > > It's a good start, but probably won't cover the full range > > of letters + numbers. > > > > Perhaps we need another table for isalpha in unicodectype.c ? > > (Or at least one which defines all non-cased letters.) > > +1 from me (SRE needs this, and it doesn't really make much > sense to add unicode tables to SRE just because the built-in > ones are slightly incomplete...) > > how about this plan: > > -- you add a Py_UNICODE_ALPHA to unicodeobject.h asap, > which does exactly that (or I can do that, if you prefer). > (and maybe even a Py_UNICODE_ALNUM) Ok, I'll add Py_UNICODE_ISALPHA and Py_UNICODE_ISALNUM (first with approximations of the sort you give above and later with true implementations using tables in unicodectype.c) on Monday... gotta run now. > -- I change SRE to use that asap. > > -- you, I, or someone else add a better implementation, > some other day. > > Nice weekend :) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Sat Jul 1 21:45:00 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 14:45:00 -0500 Subject: [Python-Dev] Cygwin report Message-ID: <395E4A3C.74A10F74@prescod.net> Here are instructions for compiling on cygwin. If anyone out there wants to make some tweaks to the build process so that this stuff isn't required anymore, it would be appreciated. ---- Threading does not work: I don't know much about posix threading APIs but I note that the standard Cygwin's pthread.h does not seem to define a pthread_cond_t type. I guess cygwin's pthread is incomplete. There seems to be a more complete one here: http://sunsite.org.uk/gnu/MORE_GNU/cygnus/pthreads-win32/ But I don't care enough to download and try it out. If there is an easy way to turn off threads by default when the platform is cygwin, that would make life a little easier for people using it. --- Sockets: gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./socketmodule.c ./socketmodule.c:146: netinet/tcp.h: No such file or directory (I just commented this module out) --- Then I got an error I haven't seen before /python/python/dist/src/Modules/python.c:12: undefined reference to `Py_Main' collect2: ld returned 1 exit status libpython2.0.a was too small to be real so I deleted it and tried "make" again. It worked. Now I have modules/python.exe mv python ../python mv: cannot move `python' to `../python/python': No such file or directory make[1]: *** [link] Error 1 make[1]: Leaving directory `/python/python/dist/src/Modules' make: *** [python] Error 2 Adding "EXE=exe" to Makefile, Modules\Setup.local and Modules\Makefile does not seem to help. For now, I'll move the file myself. (I'm not clear why it is the "Modules" makefile's responsibility to build and move python.exe anyhow!) --- If you compile using cygwin, do not make the mistake of trying to use ^Z as end of term. It hangs cygwin. Use ^D instead. -- Testing: File "./Lib/random.py", line 84, in ? NV_MAGICCONST = 4*exp(-0.5)/sqrt(2.0) OverflowError: math range error (comment out the line that imports random and try again) --- -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From gmcm at hypernet.com Sat Jul 1 21:58:24 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 1 Jul 2000 15:58:24 -0400 Subject: [Python-Dev] Cygwin report In-Reply-To: <395E4A3C.74A10F74@prescod.net> Message-ID: <1249640994-55813280@hypernet.com> Paul Prescod wrote: > Here are instructions for compiling on cygwin. If anyone out > there wants to make some tweaks to the build process so that this > stuff isn't required anymore, it would be appreciated. ---- > Threading does not work: If you targeted mingw, threading should work. Also should get a smaller, faster exe and one that has a prayer of working with pre-built extensions. last-three-words-optional-ly y'rs - Gordon From skip at mojam.com Sat Jul 1 23:27:37 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 1 Jul 2000 16:27:37 -0500 (CDT) Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: <395E404D.FBD47947@prescod.net> References: <14686.15984.430156.148785@beluga.mojam.com> <395E404D.FBD47947@prescod.net> Message-ID: <14686.25161.513218.84366@beluga.mojam.com> >> I've spent amount as much time on generating automated statement and >> branch coverage as I can afford for the next few days. At this point >> I think I have it generating a reasonable facsimile of useful output. Paul> I may have missed email about this during my email troubles Paul> yesterday, but why aren't we doing coverage testing of Python code Paul> too? Or am I missing that link? Perhap you did miss it. That's next on my list. I have a trace module that will do line counting, but I haven't worked on this thing long enough to get to it. If anyone's game, take a look at http://www.musi-cal.com/~skip/python/trace.py Shouldn't take an awful lot of effort. I just haven't got the time today. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From martin at loewis.home.cs.tu-berlin.de Sun Jul 2 00:43:17 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 2 Jul 2000 00:43:17 +0200 Subject: [Python-Dev] Copyright notice Message-ID: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> On startup, the current CVS python reports (on my system) Python 2.0b1 (#31, Jul 1 2000, 23:13:39) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) Now that the file copyrights are changed, I expect this message to change as well. May I suggest that, instead of adding another line, the two last lines of this message are removed? People who need to find out who holds the copyright to this software still can print sys.copyright. Regards, Martin From paul at prescod.net Sun Jul 2 02:15:57 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 19:15:57 -0500 Subject: [Python-Dev] test coverage summaries - now updated nightly References: <14686.15984.430156.148785@beluga.mojam.com> <395E404D.FBD47947@prescod.net> <14686.25161.513218.84366@beluga.mojam.com> Message-ID: <395E89BD.62EEC94D@prescod.net> Skip Montanaro wrote: > > ... > Perhap you did miss it. That's next on my list. I have a trace module that > will do line counting, but I haven't worked on this thing long enough to get > to it. > > If anyone's game, take a look at > > http://www.musi-cal.com/~skip/python/trace.py Thanks. It's because I've recently been using your trace module that I originally presumed that the coverage testing would be Python coverage testing. I don't yet completely understand the counting mechanism that the tool uses (some numbers look fishy) but overall it is a great boon for testing. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From mhammond at skippinet.com.au Sun Jul 2 02:21:30 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 2 Jul 2000 10:21:30 +1000 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: <20000701065111.Z29590@lyra.org> Message-ID: > > This is exactly what we do. Trents patches are just for the > functions that > > return the underlying handle value as an integer (which is definately a > > useful thing to be able to do!) > > But I don't understand why you want an integer. From the Python > programmer's > standpoint, they just want a handle, right? Yes - but there _are_ functions that return the integer. This is used mainly so the handles can be passed to external programs, or external API functions wrapped via SWIG, etc. The normal case is a "handle object". The "handle object" has auto-close ability. The "handle object" _also_ has the ability to get the raw underlying handle, should the programmer choose. Im afraid you will never convince me this is wrong :-) > Without using PyCObject, we'd need a complete handle type (like > the one in > win32api or wherever). That is exactly what we have. Sorry - I thought "CObject" was a generic term for any C-implemented PyObject. Mark. From paul at prescod.net Sun Jul 2 02:22:23 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 19:22:23 -0500 Subject: [Python-Dev] test coverage summaries - now updated nightly References: <14686.15984.430156.148785@beluga.mojam.com> <395E404D.FBD47947@prescod.net> <02b601bfe390$774a0a40$f2a6b5d4@hagrid> Message-ID: <395E8B3F.39D5C69A@prescod.net> Fredrik Lundh wrote: > > from Skip's original mail: > > /.../ I would also like to > adjust the regrtest.py stuff to generate statement coverage for .py files > using my trace module: http://www.musi-cal.com/~skip/python/trace.py. Thanks. If anyone sent me private mail yesterday (perhaps Fred about xml.*) they should send it again. My ISP's story is that their ISP went belly up without any warning. Grrr. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Sun Jul 2 02:27:13 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 19:27:13 -0500 Subject: [Python-Dev] Repr References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> Message-ID: <395E8C61.E30CA40D@prescod.net> Fredrik Lundh wrote: > > ... > > how about allowing str and repr to actually return > unicode strings? What does that mean for the interactive prompt (repr is used in the repl!). -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From gstein at lyra.org Sun Jul 2 02:34:50 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 17:34:50 -0700 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: ; from mhammond@skippinet.com.au on Sun, Jul 02, 2000 at 10:21:30AM +1000 References: <20000701065111.Z29590@lyra.org> Message-ID: <20000701173450.F29590@lyra.org> On Sun, Jul 02, 2000 at 10:21:30AM +1000, Mark Hammond wrote: > > > This is exactly what we do. Trents patches are just for the > > functions that > > > return the underlying handle value as an integer (which is definately a > > > useful thing to be able to do!) > > > > But I don't understand why you want an integer. From the Python > > programmer's > > standpoint, they just want a handle, right? > > Yes - but there _are_ functions that return the integer. This is used > mainly so the handles can be passed to external programs, or external API > functions wrapped via SWIG, etc. All right. I see the usage now. The checkin message didn't have enough context, so I went and look at the darn file. Ignore me :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Sun Jul 2 02:49:53 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 2 Jul 2000 10:49:53 +1000 Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: <14686.15984.430156.148785@beluga.mojam.com> Message-ID: > I've spent amount as much time on generating automated statement > and branch > coverage as I can afford for the next few days. At this point I think I > have it generating a reasonable facsimile of useful output. This is very cool. It would be great if there was some sort of "multi-platform" support, and a merging of the results. My idea here is so modules such as "mmapmodule" can give a better indication of the true test coverage. Your data shows this test at less than 50% - probably mainly due to the #ifdef MS_WIN32 blocks. If we merged a coverage of a Windows run against this same file, we would have an excellent basis for ensuring that the Python test suite did indeed hit as much as we could make it. This is longer term of course. Along the same vein is the Mozilla "tinderbox". It appears they have a job that starts a complete rebuild and test suite run every time a checkin is made to the CVS tree. A Web page shows the progress of each of the platforms (including some nice flaming images when the build or test suite is broken.) http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey Mark. From fdrake at beopen.com Sun Jul 2 05:34:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 1 Jul 2000 23:34:40 -0400 (EDT) Subject: [Python-Dev] Copyright notice In-Reply-To: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> References: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> Message-ID: <14686.47184.792611.628971@cj42289-a.reston1.va.home.com> Martin v. Loewis writes: > Now that the file copyrights are changed, I expect this message to > change as well. May I suggest that, instead of adding another line, > the two last lines of this message are removed? You may! I rather like this idea myself. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sun Jul 2 05:42:28 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 1 Jul 2000 23:42:28 -0400 Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: <395E8B3F.39D5C69A@prescod.net> Message-ID: [Paul Prescod] > ...If anyone sent me private mail yesterday (perhaps Fred about > xml.*) they should send it again. My ISP's story is that their ISP went > belly up without any warning. Grrr. Ditto! My POP3 server at MSN crapped out a little after midnight, and I appear to have lost all mail sent from then until about 2pm. The pipermail archives on python.org stopped archiving around midnight too. My email .forward from tpeters at beopen.com also seems still to be hosed. Was July 1 some "32-bit day" that slipped thru paranoia's cracks <0.9 wink>? From esr at thyrsus.com Sun Jul 2 13:25:24 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 07:25:24 -0400 Subject: [Python-Dev] I have a patch for shlex... Message-ID: <20000702072524.A5592@thyrsus.com> I have a patch for shlex. There has been a lot of discussion of patch management consequent to the SourceForge relocation here that I haven't followed closely. So what's the current protocol for submitting a patch? (The patch gives input sourcing cpp-like semantics for relative paths, rather than making all inclusions relative to the current working directory. Since the source feature has not yet been in a public production release, there are no backwards-compatibility issues.) -- Eric S. Raymond Everything that is really great and inspiring is created by the individual who can labor in freedom. -- Albert Einstein, in H. Eves Return to Mathematical Circles, Boston: Prindle, Weber and Schmidt, 1988. From effbot at telia.com Sun Jul 2 13:30:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 2 Jul 2000 13:30:48 +0200 Subject: [Python-Dev] I have a patch for shlex... References: <20000702072524.A5592@thyrsus.com> Message-ID: <000e01bfe418$fa3e5400$f2a6b5d4@hagrid> eric wrote: > I have a patch for shlex. There has been a lot of discussion of patch > management consequent to the SourceForge relocation here that I haven't > followed closely. So what's the current protocol for submitting a patch? the patch manager is your friend: http://sourceforge.net/patch/?func=addpatch&group_id=5470 bonus points if the summary mentions the module or subsystem name, and you describe/motivate the change either in a comment on the patch details page, or at the top of the patch itself. cheers /F From rob at hooft.net Sun Jul 2 14:02:11 2000 From: rob at hooft.net (Rob W. W. Hooft) Date: Sun, 2 Jul 2000 14:02:11 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml __init__.py,1.1,1.2 In-Reply-To: <200007010458.VAA21264@slayer.i.sourceforge.net> References: <200007010458.VAA21264@slayer.i.sourceforge.net> Message-ID: <14687.12099.151636.943086@temoleh.chem.uu.nl> >>>>> "PP" == Paul Prescod writes: PP> sax -- The Simple API for XML, developed by XML-Dev, led by PP> David Megginson and ported to Python by Lars Marius Garsholm. His name is "Lars Marius Garshol", no m. Rob From esr at thyrsus.com Sun Jul 2 14:26:44 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 08:26:44 -0400 Subject: [Python-Dev] The submit patch form yields a cryptic message Message-ID: <20000702082644.A5758@thyrsus.com> "Patch Uploaded Successfully Added Patch Could Not Send Patch Update" -- Eric S. Raymond The kind of charity you can force out of people nourishes about as much as the kind of love you can buy --- and spreads even nastier diseases. From esr at thyrsus.com Sun Jul 2 14:45:16 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 08:45:16 -0400 Subject: [Python-Dev] Application for developer status Message-ID: <20000702084516.A5777@thyrsus.com> May I have developer status on the SourceForge CVS, please? I maintain two standard-library modules (shlex and netrc) and have been involved with the development of several others (including Cmd, smtp, httplib, and multifile). My only immediate plan for what to do with developer access is to add the browser-launch capability previously discussed on this list. My general interest is in improving the standard class library, especially in the areas of Internet-protocol support (urllib, ftp, telnet, pop, imap, smtp, nntplib, etc.) and mini-language toolkits and frameworks (shlex. netrc, Cmd, ConfigParser). If the Internet-protocol support in the library were broken out as a development category, I would be willing to fill the patch-handler slot for it. -- Eric S. Raymond See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs. -- Dave Barry From fdrake at beopen.com Sun Jul 2 15:51:04 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 2 Jul 2000 09:51:04 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml __init__.py,1.1,1.2 In-Reply-To: <14687.12099.151636.943086@temoleh.chem.uu.nl> References: <200007010458.VAA21264@slayer.i.sourceforge.net> <14687.12099.151636.943086@temoleh.chem.uu.nl> Message-ID: <14687.18632.87208.648581@cj42289-a.reston1.va.home.com> Rob W. W. Hooft writes: > >>>>> "PP" == Paul Prescod writes: > > PP> sax -- The Simple API for XML, developed by XML-Dev, led by > PP> David Megginson and ported to Python by Lars Marius Garsholm. > > His name is "Lars Marius Garshol", no m. Yup! But it looks like Paul was quoting from the xml/__init__.py file docstring, which I wrote. So, I'll have to take credit for the typo. ;( I'll fix it now; thanks for pointing it out! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Sun Jul 2 16:42:01 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 2 Jul 2000 09:42:01 -0500 (CDT) Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: References: <14686.15984.430156.148785@beluga.mojam.com> Message-ID: <14687.21689.32691.579185@beluga.mojam.com> Mark> It would be great if there was some sort of "multi-platform" Mark> support, and a merging of the results. Agreed. We could set up a scheme where people run my scripts on other systems and then mail me the generated files. Windows would be kind of tough though, because my stuff currently relies on gcc/gcov. What facilities does Windows have for coverage testing Mark? Mark> Along the same vein is the Mozilla "tinderbox". It appears they Mark> have a job that starts a complete rebuild and test suite run every Mark> time a checkin is made to the CVS tree. That seems a bit extreme to me, and I don't know about you, but I don't have the spare resources available to "burn" on such a project. skip From paul at prescod.net Sun Jul 2 17:07:49 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 10:07:49 -0500 Subject: [Python-Dev] Application for developer status References: <20000702084516.A5777@thyrsus.com> Message-ID: <395F5AC5.FF11284F@prescod.net> "Eric S. Raymond" wrote: > > ... > > My only immediate plan for what to do with developer access is to add > the browser-launch capability previously discussed on this list. My > general interest is in improving the standard class library, > especially in the areas of Internet-protocol support (urllib, ftp, > telnet, pop, imap, smtp, nntplib, etc.) and mini-language toolkits and > frameworks (shlex. netrc, Cmd, ConfigParser). As an aside: I would be pumpld about getting a generic lexer into the Python distribution. Greg Ewing was working on one and there are various others out there. http://www.cosc.canterbury.ac.nz/~greg/python/Plex/ -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm, by David Berlinski From paul at prescod.net Sun Jul 2 17:10:49 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 10:10:49 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml __init__.py,1.1,1.2 References: <200007010458.VAA21264@slayer.i.sourceforge.net> <14687.12099.151636.943086@temoleh.chem.uu.nl> <14687.18632.87208.648581@cj42289-a.reston1.va.home.com> Message-ID: <395F5B79.5310B93D@prescod.net> "Fred L. Drake, Jr." wrote: > > Yup! But it looks like Paul was quoting from the xml/__init__.py > file docstring, which I wrote. So, I'll have to take credit for the > typo. ;( I'll fix it now; thanks for pointing it out! No, I added that typo. You just made the mistake of naming David Megginson but not Lars. I thought that the latter was closer to our hearts. But not close enough to spell his name right. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From esr at thyrsus.com Sun Jul 2 17:52:31 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 11:52:31 -0400 Subject: [Python-Dev] Application for developer status In-Reply-To: <395F5AC5.FF11284F@prescod.net>; from paul@prescod.net on Sun, Jul 02, 2000 at 10:07:49AM -0500 References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> Message-ID: <20000702115231.A6785@thyrsus.com> Paul Prescod : > As an aside: I would be pumpld about getting a generic lexer into the > Python distribution. Greg Ewing was working on one and there are various > others out there. > http://www.cosc.canterbury.ac.nz/~greg/python/Plex/ Yes, this would be a good thing. I'm also talking with John Aycock about his elegant SPARK toolkit for generating Earley-algorithm parsers. Once that comes out of beta, I would consider it a core-library candidate. -- Eric S. Raymond No matter how one approaches the figures, one is forced to the rather startling conclusion that the use of firearms in crime was very much less when there were no controls of any sort and when anyone, convicted criminal or lunatic, could buy any type of firearm without restriction. Half a century of strict controls on pistols has ended, perversely, with a far greater use of this weapon in crime than ever before. -- Colin Greenwood, in the study "Firearms Control", 1972 From effbot at telia.com Sun Jul 2 18:13:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 2 Jul 2000 18:13:58 +0200 Subject: [Python-Dev] A standard lexer? References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> Message-ID: <001701bfe440$88beaaa0$f2a6b5d4@hagrid> paul wrote: > As an aside: I would be pumpld about getting a generic lexer into the > Python distribution. how about this quick and dirty proposal: - add a new primitive to SRE: (?P#n), where n is a small integer. this primitive sets the match object's "index" variable to n when the engine stumbles upon it. - given a list of "phrases", combine them into a single regular expression like this: (?:phrase1(?P#1))|(?:phrase2(?P#2))|... - apply match repeatedly to the input string. for each match, use the index attribute to figure out what phrase we matched. see below for a slightly larger example. import sre class Scanner: def __init__(self, lexicon): self.lexicon = lexicon p = [] for phrase, action in lexicon: p.append("(?:%s)(?P#%d)" % (phrase, len(p))) self.scanner = sre.compile("|".join(p)) def scan(self, string): result = [] append = result.append match = self.scanner.match i = 0 while 1: m = match(string, i) if not m: break j = m.end() if i == j: break action = self.lexicon[m.index][1] if callable(action): self.match = match action = action(self, m.group()) if action is not None: append(action) i = j return result, string[i:] def s_ident(scanner, token): return token def s_operator(scanner, token): return "operator%s" % token def s_float(scanner, token): return float(token) def s_int(scanner, token): return int(token) scanner = Scanner([ (r"[a-zA-Z_]\w*", s_ident), (r"\d+\.\d*", s_float), (r"\d+", s_int), (r"=|\+|-|\*|/", s_operator), (r"\s+", None), ]) tokens, tail = scanner.scan("sum = 3*foo + 312.50 + bar") print tokens if tail: print "syntax error at", tail ## prints: ## ['sum', 'operator=', 3, 'operator*', 'foo', 'operator+', ## 312.5, 'operator+', 'bar'] From paul at prescod.net Sun Jul 2 18:30:25 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 11:30:25 -0500 Subject: [Python-Dev] Lexing/parsing References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> <20000702115231.A6785@thyrsus.com> Message-ID: <395F6E21.E59ADE6D@prescod.net> "Eric S. Raymond" wrote: > > ... > > Yes, this would be a good thing. I'm also talking with John Aycock about > his elegant SPARK toolkit for generating Earley-algorithm parsers. Once that > comes out of beta, I would consider it a core-library candidate. I pointed one of my co-workers at Spark and he loved the lexer but said that the parser ended up being too slow to be useful. I didn't know enough about the Earley-algorithm to suggest how he could re-organize his grammar to optimize for it. If naive Python programmers cannot generate usable parsers then it may not be appropriate for the standard library. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From fdrake at beopen.com Sun Jul 2 18:33:26 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 2 Jul 2000 12:33:26 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml __init__.py,1.1,1.2 In-Reply-To: <395F5B79.5310B93D@prescod.net> References: <200007010458.VAA21264@slayer.i.sourceforge.net> <14687.12099.151636.943086@temoleh.chem.uu.nl> <14687.18632.87208.648581@cj42289-a.reston1.va.home.com> <395F5B79.5310B93D@prescod.net> Message-ID: <14687.28374.752438.191737@cj42289-a.reston1.va.home.com> Paul Prescod writes: > No, I added that typo. You just made the mistake of naming David > Megginson but not Lars. I thought that the latter was closer to our > hearts. But not close enough to spell his name right. Oops! Ok, typo conceeded. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Sun Jul 2 18:38:54 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 11:38:54 -0500 Subject: [Python-Dev] Re: A standard lexer? References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> <001701bfe440$88beaaa0$f2a6b5d4@hagrid> Message-ID: <395F701E.621CACD4@prescod.net> Fredrik Lundh wrote: > >... > > - add a new primitive to SRE: (?P#n), where n is a small integer. > this primitive sets the match object's "index" variable to n when > the engine stumbles upon it. How about an interned string instead? > - given a list of "phrases", combine them into a single regular > expression like this: > > (?:phrase1(?P#1))|(?:phrase2(?P#2))|... Will sre do anything about optimizing common prefixes and so forth? Overall, I like your proposal. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From esr at thyrsus.com Sun Jul 2 18:58:39 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 12:58:39 -0400 Subject: [Python-Dev] Lexing/parsing In-Reply-To: <395F6E21.E59ADE6D@prescod.net>; from paul@prescod.net on Sun, Jul 02, 2000 at 11:30:25AM -0500 References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> <20000702115231.A6785@thyrsus.com> <395F6E21.E59ADE6D@prescod.net> Message-ID: <20000702125839.A6935@thyrsus.com> Paul Prescod : > I pointed one of my co-workers at Spark and he loved the lexer but said > that the parser ended up being too slow to be useful. I didn't know > enough about the Earley-algorithm to suggest how he could re-organize > his grammar to optimize for it. If naive Python programmers cannot > generate usable parsers then it may not be appropriate for the standard > library. I'm using a SPARK-generated parser plus shlex in CML2. This does not seem to create a speed problem. -- Eric S. Raymond No kingdom can be secured otherwise than by arming the people. The possession of arms is the distinction between a freeman and a slave. -- "Political Disquisitions", a British republican tract of 1774-1775 From tim_one at email.msn.com Sun Jul 2 18:52:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 2 Jul 2000 12:52:52 -0400 Subject: [Python-Dev] Application for developer status In-Reply-To: <20000702084516.A5777@thyrsus.com> Message-ID: [Eric S. Raymond] > May I have developer status on the SourceForge CVS, please? I maintain > two standard-library modules (shlex and netrc) and have been involved > with the development of several others (including Cmd, smtp, httplib, and > multifile). > > My only immediate plan for what to do with developer access is to add > the browser-launch capability previously discussed on this list. My > general interest is in improving the standard class library, > especially in the areas of Internet-protocol support (urllib, ftp, > telnet, pop, imap, smtp, nntplib, etc.) and mini-language toolkits and > frameworks (shlex. netrc, Cmd, ConfigParser). > > If the Internet-protocol support in the library were broken out as a > development category, I would be willing to fill the patch-handler > slot for it. Eric, I just added you -- go nuts! Don't forget your docstrings, and try hard not to add new modules Guido will hate <0.9 wink -- but new modules do merit python-dev discussion first>. Ah, one more: the layout of the "Edit Member Permissions" admin page on SF is completely screwed up for me, so you got whatever the default permissions are. This looked fine to me a few days ago, but we've added several members since then. Would one of the admins using Netscape please check that page for sane display? I can't yet tell whether it's an IE5 or SF problem. From tim_one at email.msn.com Sun Jul 2 19:21:03 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 2 Jul 2000 13:21:03 -0400 Subject: [Python-Dev] A standard lexer? In-Reply-To: <001701bfe440$88beaaa0$f2a6b5d4@hagrid> Message-ID: [Paul Prescod] > As an aside: I would be pumped about getting a generic lexer into the > Python distribution. [Fredrik Lundh] > how about this quick and dirty proposal: > > - add a new primitive to SRE: (?P#n), where n is a small integer. > this primitive sets the match object's "index" variable to n when > the engine stumbles upon it. Note that the lack of "something like this" is one of the real barriers to speeding SPARK's lexing, and the speed of a SPARK lexer now (well, last I looked into this) can be wildly dependent on the order in which you define your lexing methods (partly because there's no way to figure out which lexing method matched without iterating through all the groups to find the first that isn't None). The same kind of irritating iteration is needed in IDLE and pyclbr too (disguised as unrolled if/elif/elif/... chains), and in tokenize.py (there *really* disguised in a convoluted way, by doing more string tests on the matched substring to *infer* which of the regexp pattern chunks must have matched). OTOH, arbitrary small integers are not Pythonic. Your example *generates* them in order to guarantee they're unique, which is a bad sign (it implies users can't do this safely by hand, and I believe that's the truth of it too): > for phrase, action in lexicon: > p.append("(?:%s)(?P#%d)" % (phrase, len(p))) How about instead enhancing existing (?Ppattern) notation, to set a new match object attribute to name if & when pattern matches? Then arbitrary info associated with a named pattern can be gotten at via dicts via the pattern name, & the whole mess should be more readable. On the third hand, I'm really loathe to add more gimmicks to stinking regexps. But, on the fourth hand, no alternative yet has proven popular enough to move away from those suckers. if-you-can't-get-a-new-car-at-least-tune-up-the-old-one-ly y'rs - tim From dan at cgsoftware.com Sun Jul 2 19:40:04 2000 From: dan at cgsoftware.com (Daniel Berlin) Date: Sun, 2 Jul 2000 10:40:04 -0700 (PDT) Subject: [Python-Dev] A standard lexer? In-Reply-To: Message-ID: > > > On the third hand, I'm really loathe to add more gimmicks to stinking > regexps. But, on the fourth hand, no alternative yet has proven popular > enough to move away from those suckers. > > if-you-can't-get-a-new-car-at-least-tune-up-the-old-one-ly y'rs - tim > > > Right. Actually, if it helps, i'm working on porting re2c to python. Because it was written properly, it's rather simple (in fact, i've only needed to modify one file, add some if's to ee if we want python generation, and output the python code instead of c code) The lexers it generates for c/C++ are much faster than flex lexers, because they are directly coded. I haven't benchmarked it against SPARK yet, but i would imagine it would blow it away, for the same reason it blows away flex. --Dan From effbot at telia.com Sun Jul 2 19:55:11 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 2 Jul 2000 19:55:11 +0200 Subject: [Python-Dev] A standard lexer? References: Message-ID: <002901bfe44e$af624be0$f2a6b5d4@hagrid> tim wrote: > OTOH, arbitrary small integers are not Pythonic. Your example *generates* > them in order to guarantee they're unique, which is a bad sign. this feature itself has been on the todo list for quite a while; the (?P#n) syntax just exposes the inner workings (the "small integer" is simply some- thing that fits in a SRE_CODE word). as you say, it's probably a good idea to hide it a bit better... > > for phrase, action in lexicon: > > p.append("(?:%s)(?P#%d)" % (phrase, len(p))) > > How about instead enhancing existing (?Ppattern) notation, to set a > new match object attribute to name if & when pattern matches? Then > arbitrary info associated with a named pattern can be gotten at via dicts > via the pattern name, & the whole mess should be more readable. good idea. and fairly easy to implement, I think. on the other hand, that means creating more real groups. and groups don't come for free... maybe this functionality should only be available through the scanner class? it can compile the patterns separately, and combine the data structures before passing them to the code generator. a little bit more code to write, but less visible oddities. > On the third hand, I'm really loathe to add more gimmicks to stinking > regexps. But, on the fourth hand, no alternative yet has proven popular > enough to move away from those suckers. > > if-you-can't-get-a-new-car-at-least-tune-up-the-old-one-ly y'rs - tim hey, SRE is a new car. same old technology, though. only smaller ;-) btw, if someone wants to play with this, I just checked in a new SRE snapshot. a little bit of documentation can be found here: http://hem.passagen.se/eff/2000_07_01_bot-archive.htm#416954 From pingster at ilm.com Sun Jul 2 22:54:58 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Sun, 2 Jul 2000 13:54:58 -0700 (PDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000701124303.A31955@thyrsus.com> Message-ID: Skip Montanaro : > My guess is that -tt triggered a SyntaxError (maybe we should create an > IndentationError that is a subclass of SyntaxError?) Yes! +1! -- ?!ng From paul at prescod.net Sun Jul 2 23:09:24 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 16:09:24 -0500 Subject: [Python-Dev] Sorry. No Release. References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> Message-ID: <395FAF84.87B1FD17@prescod.net> Skip Montanaro wrote: > > ... > > My guess is that -tt triggered a SyntaxError (maybe we should create an > IndentationError that is a subclass of SyntaxError?) +1 That would be great for newbies! -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From effbot at telia.com Mon Jul 3 00:35:28 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 3 Jul 2000 00:35:28 +0200 Subject: [Python-Dev] A standard lexer? References: Message-ID: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid> tim wrote: > > for phrase, action in lexicon: > > p.append("(?:%s)(?P#%d)" % (phrase, len(p))) > > How about instead enhancing existing (?Ppattern) notation, to set a > new match object attribute to name if & when pattern matches? Then > arbitrary info associated with a named pattern can be gotten at via dicts > via the pattern name, & the whole mess should be more readable. I just added "lastindex" and "lastgroup" attributes to the match object. "lastindex" is the integer index of the last matched capturing group, "lastgroup" the corresponding name (or None, if the group didn't have a name). both attributes are None if no group were matched. From mal at lemburg.com Mon Jul 3 00:44:55 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 00:44:55 +0200 Subject: [Python-Dev] A standard lexer? References: Message-ID: <395FC5E7.DD0251A2@lemburg.com> Daniel Berlin wrote: > > Actually, if it helps, i'm working on porting re2c to python. Pointers ? > Because it was written properly, it's rather simple (in fact, i've only > needed to modify one file, add some if's to ee if we want python > generation, and output the python code instead of c code) > The lexers it generates for c/C++ are much faster than flex lexers, > because they are directly coded. > I haven't benchmarked it against SPARK yet, but i would imagine it would > blow it away, for the same reason it blows away flex. Perhaps you should also look at the tagging engine in mxTextTools (you know where...) ?! It's very low-level, but it makes nice target for optimizing parser generators since it provides a Python interface to raw C speed. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From dberlin at cygnus.com Mon Jul 3 00:49:37 2000 From: dberlin at cygnus.com (Daniel Berlin) Date: 02 Jul 2000 18:49:37 -0400 Subject: [Python-Dev] A standard lexer? In-Reply-To: "M.-A. Lemburg"'s message of "Mon, 03 Jul 2000 00:44:55 +0200" References: <395FC5E7.DD0251A2@lemburg.com> Message-ID: <86zoo0du66.fsf@dan2.cygnus.com> "M.-A. Lemburg" writes: > Daniel Berlin wrote: > > > > Actually, if it helps, i'm working on porting re2c to python. > > Pointers ? http://www.tildeslash.org/re2c/index.html > > > Because it was written properly, it's rather simple (in fact, i've only > > needed to modify one file, add some if's to ee if we want python > > generation, and output the python code instead of c code) > > The lexers it generates for c/C++ are much faster than flex lexers, > > because they are directly coded. > > I haven't benchmarked it against SPARK yet, but i would imagine it would > > blow it away, for the same reason it blows away flex. > > Perhaps you should also look at the tagging engine in > mxTextTools (you know where...) ?! It's very low-level, but > it makes nice target for optimizing parser generators since > it provides a Python interface to raw C speed. > re2c is simply a scanner generator, not a parser. --Dan From tim_one at email.msn.com Mon Jul 3 01:22:31 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 2 Jul 2000 19:22:31 -0400 Subject: [Python-Dev] (harmless?) CVS error on SourceForge Message-ID: Recent commit had an error msg at the end; don't remember enough about CVS to recall whether it matters; anyone else? C:\pysrc>cvs commit python/dist/src/PC/example_nt CVS.EXE commit: Examining python/dist/src/PC/example_nt Password: Checking in python/dist/src/PC/example_nt/example.dsp; /cvsroot/python/python/dist/src/PC/example_nt/example.dsp,v <-- example.dsp new revision: 1.3; previous revision: 1.2 done Checking in python/dist/src/PC/example_nt/example.dsw; /cvsroot/python/python/dist/src/PC/example_nt/example.dsw,v <-- example.dsw new revision: 1.2; previous revision: 1.1 done Removing python/dist/src/PC/example_nt/example.mak; /cvsroot/python/python/dist/src/PC/example_nt/example.mak,v <-- example.mak new revision: delete; previous revision: 1.3 done Checking in python/dist/src/PC/example_nt/readme.txt; /cvsroot/python/python/dist/src/PC/example_nt/readme.txt,v <-- readme.txt new revision: 1.7; previous revision: 1.6 done Running syncmail... Mailing python-checkins at python.org... ...syncmail done. cvs [diff aborted]: no such tag NONE C:\pysrc> From akuchlin at cnri.reston.va.us Mon Jul 3 02:57:55 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 2 Jul 2000 20:57:55 -0400 Subject: [Python-Dev] A standard lexer? In-Reply-To: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid>; from effbot@telia.com on Mon, Jul 03, 2000 at 12:35:28AM +0200 References: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid> Message-ID: <20000702205755.A7533@newcnri.cnri.reston.va.us> Might it be worth taking the lexer discussion to the String-SIG? The more public the discussion, the better, and it is why the SIG is there... --amk From fdrake at beopen.com Mon Jul 3 08:15:26 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 02:15:26 -0400 (EDT) Subject: [Python-Dev] (harmless?) CVS error on SourceForge In-Reply-To: References: Message-ID: <14688.12158.189752.140235@cj42289-a.reston1.va.home.com> Tim Peters writes: > Recent commit had an error msg at the end; don't remember enough about CVS > to recall whether it matters; anyone else? ... > cvs [diff aborted]: no such tag NONE This is harmless, and only affects the message sent to python-checkins. It is generated by the "cvs diff" executed by the syncmail script. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Mon Jul 3 08:33:37 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 02:33:37 -0400 (EDT) Subject: [Python-Dev] Application for developer status In-Reply-To: References: <20000702084516.A5777@thyrsus.com> Message-ID: <14688.13249.310796.64561@cj42289-a.reston1.va.home.com> Tim Peters writes: > Ah, one more: the layout of the "Edit Member Permissions" admin page on SF > is completely screwed up for me, so you got whatever the default permissions > are. This looked fine to me a few days ago, but we've added several members > since then. > > Would one of the admins using Netscape please check that page for sane > display? I can't yet tell whether it's an IE5 or SF problem. It looks fine to me -- you may be plagued by a slow network connection. ;) I've updated Eric's permissions so he can use the patch manager properly. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mhammond at skippinet.com.au Mon Jul 3 08:28:02 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 3 Jul 2000 16:28:02 +1000 Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: <14687.21689.32691.579185@beluga.mojam.com> Message-ID: [Skip] > Mark> It would be great if there was some sort of "multi-platform" > Mark> support, and a merging of the results. > Agreed. We could set up a scheme where people run my scripts on other > systems and then mail me the generated files. Windows would be kind of > tough though, because my stuff currently relies on gcc/gcov. What > facilities does Windows have for coverage testing Mark? There is a source-profiler, but Im not sure how deep it lets you into the data. I'll look into this at some stage. Or some people are working towards gcc makefiles for windows - maybe that is a better way to go for this? Mark> Along the same vein is the Mozilla "tinderbox". It ... > That seems a bit extreme to me, and I don't know about you, but > I don't have > the spare resources available to "burn" on such a project. I think that the tinderbox code is open-source too! I agree this is a bit extreme, but I do believe something like it would be useful, and need not be too hard. As more and more checkins happen from different people, the chances of platform-breakage would seem to be quite high. A Python script that periodically scanned CVS for changes, then executed a build and did something pretty simple with the log wouldnt be too hard. However, I do agree we should wait until it is _nearly_ a problem (as opposed to _is_ a problem :-) Mark. From martin at loewis.home.cs.tu-berlin.de Mon Jul 3 09:29:23 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 3 Jul 2000 09:29:23 +0200 Subject: [Python-Dev] Minidom and Unicode Message-ID: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> > the repository has been updated. In what way? Python 2.0b1 (#1, Jul 3 2000, 09:12:07) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> class X: ... def __repr__(self): ... if hasattr(self,"u"): ... return u'\u30b9' ... else: ... return u'hallo' ... >>> x=X() >>> x hallo >>> x.u=1 >>> x Traceback (most recent call last): File "", line 1, in ? TypeError: __repr__ returned non-string (type unicode) > no need to change minidom. The need still appears to exist, both for minidom.Element (KATAKANA LETTER SU is a letter, and thus a valid tag name), as well as minidom.Text. A string is a string is a string. Regards, Martin From mal at lemburg.com Mon Jul 3 10:35:51 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 10:35:51 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> Message-ID: <39605067.DCC2B968@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > I'd say +0, since the auto-converion can fail if the default > > encoding doesn't have room for the tagName characters. > > > > Either way, I'd still prefer the DOM code to use an explicit > > .encode() together with some lossless encoding, e.g. > > unicode-escape. > > If we want to use a hard-coded lossless encoding, we should do so in > repr. Rather than having us fix a dozen modules with problems like this, > we should fix repr once and for all. I think it's ok to auto-convert to the default encoding as intermediate solution, but the applications wanting to return Unicode as __repr__ or __str__ should really use .encode() to make sure the output that is produces matches their (or their user's) expectations. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 3 10:43:59 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 10:43:59 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> Message-ID: <3960524F.F6C2D4A8@lemburg.com> Fredrik Lundh wrote: > > paul wrote: > > > If we want to use a hard-coded lossless encoding, we should do so in > > repr. Rather than having us fix a dozen modules with problems like this, > > we should fix repr once and for all. > > how about allowing str and repr to actually return > unicode strings? > > or in other words: > > PyObject *res; > res = (*v->ob_type->tp_repr)(v); > if (res == NULL) > return NULL; > if (!PyString_Check(res) && !PyUnicode_Check(res)) { > PyErr_Format(PyExc_TypeError, > "__repr__ returned non-string (type %.200s)", > res->ob_type->tp_name); > Py_DECREF(res); > return NULL; > } > return res; > > (strings are strings are strings, etc) -1: This breaks code, since it is expected that PyObject_Str() returns a string object. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Mon Jul 3 10:53:52 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 04:53:52 -0400 (EDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <395FAF84.87B1FD17@prescod.net> References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> Message-ID: <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> Skip Montanaro wrote: > My guess is that -tt triggered a SyntaxError (maybe we should create an > IndentationError that is a subclass of SyntaxError?) Paul Prescod writes: > +1 > > That would be great for newbies! Yes, but the name is confusing, because it isn't raised for every sort of indentation error if it's only used for tab/space problems: try: 1/0 1/0 finally: pass still would raise SyntaxError. Should that raise an IndentationError as well? Or should IndentationError be named something else? (Just adding IndentationError for -tt isn't hard, I have a preliminary patch for that now. Adding it for the case above looks harder.) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr at thyrsus.com Mon Jul 3 11:20:52 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 05:20:52 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <14688.21664.958984.801457@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 03, 2000 at 04:53:52AM -0400 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> Message-ID: <20000703052052.E11175@thyrsus.com> Fred L. Drake, Jr. : > > Skip Montanaro wrote: > > My guess is that -tt triggered a SyntaxError (maybe we should create an > > IndentationError that is a subclass of SyntaxError?) > > Paul Prescod writes: > > +1 > > > > That would be great for newbies! > > Yes, but the name is confusing, because it isn't raised for every > sort of indentation error if it's only used for tab/space problems: > > try: > 1/0 > 1/0 > finally: > pass > > still would raise SyntaxError. Should that raise an IndentationError > as well? Or should IndentationError be named something else? WhitespaceError -- Eric S. Raymond Morality is always the product of terror; its chains and strait-waistcoats are fashioned by those who dare not trust others, because they dare not trust themselves, to walk in liberty. -- Aldous Huxley From effbot at telia.com Mon Jul 3 11:27:55 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 3 Jul 2000 11:27:55 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> <3960524F.F6C2D4A8@lemburg.com> Message-ID: <004001bfe4d0$f91b2720$f2a6b5d4@hagrid> mal wrote: > > (strings are strings are strings, etc) > > -1: This breaks code, since it is expected that PyObject_Str() > returns a string object. unicode strings are also strings, right? the interesting question here is to figure out who's expecting that, and figure out if that code can be changed. From mal at lemburg.com Mon Jul 3 11:36:18 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 11:36:18 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> <3960524F.F6C2D4A8@lemburg.com> <004001bfe4d0$f91b2720$f2a6b5d4@hagrid> Message-ID: <39605E92.492D1F3E@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > (strings are strings are strings, etc) > > > > -1: This breaks code, since it is expected that PyObject_Str() > > returns a string object. > > unicode strings are also strings, right? Well, I usually refer to them as Unicode objects to make it clear that they are different from the standard notion of a string in Python. If we were to use classes for Python basic type I would make them have the same base class though... > the interesting question here is to figure out who's expecting that, > and figure out if that code can be changed. We might proceed in that direction for Py3K, but I don't think it's a good idea to make such changes just now. IMHO, it's better to provide other means of getting at the Unicode data, e.g. instances could provide a __unicode__ method hook which the builtin unicode() queries and then uses to convert to Unicode. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Mon Jul 3 11:54:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 3 Jul 2000 11:54:25 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> Message-ID: <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> martin wrote: > In what way? > > Python 2.0b1 (#1, Jul 3 2000, 09:12:07) [GCC 2.95.2 19991024 (release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> class X: > ... def __repr__(self): > ... if hasattr(self,"u"): > ... return u'\u30b9' > ... else: > ... return u'hallo' > ... > >>> x=X() > >>> x > hallo > >>> x.u=1 > >>> x > Traceback (most recent call last): > File "", line 1, in ? > TypeError: __repr__ returned non-string (type unicode) > > > no need to change minidom. > > The need still appears to exist, both for minidom.Element (KATAKANA > LETTER SU is a letter, and thus a valid tag name), as well as > minidom.Text. A string is a string is a string. works for me: $ export LANG=posix.utf8 $ python >>> import sys >>> sys.getdefaultencoding() 'utf8' >>> class X: ... def __repr__(self): ... return u"u\30b9" ... >>> x = X() >>> x ?,? (or to put it another way, I'm not sure the repr/str fix is the real culprit here...) From mal at lemburg.com Mon Jul 3 12:38:04 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 12:38:04 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> <028301bfe37f$bb349380$f2a6b5d4@hagrid> <395E44E2.63383BC5@lemburg.com> Message-ID: <39606D0C.CB3F18FD@lemburg.com> "M.-A. Lemburg" wrote: > > Fredrik Lundh wrote: > > how about this plan: > > > > -- you add a Py_UNICODE_ALPHA to unicodeobject.h asap, > > which does exactly that (or I can do that, if you prefer). > > (and maybe even a Py_UNICODE_ALNUM) > > Ok, I'll add Py_UNICODE_ISALPHA and Py_UNICODE_ISALNUM > (first with approximations of the sort you give above and > later with true implementations using tables in unicodectype.c) > on Monday... gotta run now. > > > -- I change SRE to use that asap. > > > > -- you, I, or someone else add a better implementation, > > some other day. I've just looked into this... the problem here is what to consider as being "alpha" and what "numeric". I could add two new tables for the characters with category 'Lo' (other letters, not cased) and 'Lm' (letter modifiers) to match all letters in the Unicode database, but those tables have some 5200 entries (note that there are only 804 lower case letters and 686 upper case ones). Note that there seems to be no definition of what is to be considered alphanumeric in Unicode. The only quote I found was in http://www.w3.org/TR/xslt#convert which says: """ Alphanumeric means any character that has a Unicode category of Nd, Nl, No, Lu, Ll, Lt, Lm or Lo. """ Here's what the glibc has to say about these chars: /* Test for any wide character for which `iswupper' or 'iswlower' is true, or any wide character that is one of a locale-specific set of wide-characters for which none of `iswcntrl', `iswdigit', `iswpunct', or `iswspace' is true. */ extern int iswalpha __P ((wint_t __wc)); Question: Should I go ahead and add the Lo and Lm tables to unicodectype.c ? Pros: standards confrom Cons: huge in size -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From martin at loewis.home.cs.tu-berlin.de Mon Jul 3 15:08:56 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 3 Jul 2000 15:08:56 +0200 Subject: [Python-Dev] Minidom and Unicode In-Reply-To: <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> (effbot@telia.com) References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> Message-ID: <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> > works for me: > > $ export LANG=posix.utf8 [...] > (or to put it another way, I'm not sure the repr/str fix is > the real culprit here...) I think it is. My understanding is that repr always returns something printable - if possible even something that can be passed to eval. I'd certainly expect that a minidom Node can be printed always, no matter what the default encoding is. Consequently, I'd prefer if the conversion uses some fixed, repr-style encoding, eg. unicode-escape (just as repr of a unicode object does). If it is deemed unacceptable to put this into the interpreter proper, I'd prefer if minidom is changed to allow representation of all Nodes on all systems. Regards, Martin From esr at thyrsus.com Mon Jul 3 15:56:00 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 09:56:00 -0400 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? Message-ID: <20000703095600.A12141@thyrsus.com> I have a valid ssh account on SourceForge. I follow the directions on the Python CVS page and get this: Script started on Mon Jul 3 09:50:42 2000 snark:~/WWW/python$ echo $CVS_RSH /usr/bin/ssh snark:~/WWW/python$ cvs -z3 -desr at cvs.python.sourceforge.net:/cvsroot/python co python esr at cvs.python.sourceforge.net's password: cvs checkout: warning: unrecognized response `' from cvs server cvs checkout: warning: unrecognized response `Welcome to cvs1.sourceforge.net' from cvs server cvs checkout: warning: unrecognized response `' from cvs server cvs checkout: warning: unrecognized response `This is a restricted Shell Account' from cvs server cvs checkout: warning: unrecognized response `You cannot execute anything here.' from cvs server cvs checkout: warning: unrecognized response `' from cvs server cvs [checkout aborted]: end of file from server (consult above messages if any) snark:~/WWW/python$ exit Script done on Mon Jul 3 09:51:23 2000 -- Eric S. Raymond Idealism is the noble toga that political gentlemen drape over their will to power. -- Aldous Huxley From root at theporch.com Mon Jul 3 15:46:00 2000 From: root at theporch.com (Phillip Porch) Date: Mon, 3 Jul 2000 08:46:00 -0500 (CDT) Subject: [Python-Dev] Typo in pty.py Message-ID: I was compiling and testing the current snapshot of python (current as of 7:00 AM CDT 7/3/00) and found that test_pty failed. Here is the output of the test. [sco root-tty01 src] ./python Lib/test/test_pty.py Calling master_open() Got master_fd '6', slave_name '/dev/ttyp1' Calling slave_open('/dev/ttyp1') Got slave_fd '7' Writing to slave_fd I wish to buy a fish license. For my pet fish, Eric. calling pty.fork() Traceback (most recent call last): File "Lib/test/test_pty.py", line 50, in ? pid, master_fd = pty.fork() File "./Lib/pty.py", line 95, in fork master_fd, slave_fd = openpty() File "./Lib/pty.py", line 28, in openpty slave_fd = _slave_open(slave_name) NameError: _slave_open I believe there is a typo on line 28 in Lib/pty.py... the call should not be _slave_open but slave_open. I made that change and the test ran fine. -- Phillip P. Porch NIC:PP1573 finger for http://www.theporch.com UTM - 16 514546E 3994565N PGP key From gward at mems-exchange.org Mon Jul 3 15:50:16 2000 From: gward at mems-exchange.org (Greg Ward) Date: Mon, 3 Jul 2000 09:50:16 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000703052052.E11175@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 03, 2000 at 05:20:52AM -0400 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> <20000703052052.E11175@thyrsus.com> Message-ID: <20000703095016.A24655@ludwig.cnri.reston.va.us> [Fred L. Drake, Jr. ] > Yes, but the name is confusing, because it isn't raised for every > sort of indentation error if it's only used for tab/space problems: [Eric S. Raymond] > WhitespaceError How about TabError? Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From esr at thyrsus.com Mon Jul 3 16:04:05 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 10:04:05 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000703095016.A24655@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Mon, Jul 03, 2000 at 09:50:16AM -0400 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> <20000703052052.E11175@thyrsus.com> <20000703095016.A24655@ludwig.cnri.reston.va.us> Message-ID: <20000703100405.B12176@thyrsus.com> Greg Ward : > [Fred L. Drake, Jr. ] > > Yes, but the name is confusing, because it isn't raised for every > > sort of indentation error if it's only used for tab/space problems: > > [Eric S. Raymond] > > WhitespaceError > > How about TabError? Not a big deal to me which gets used. -- Eric S. Raymond The United States is in no way founded upon the Christian religion -- George Washington & John Adams, in a diplomatic message to Malta. From fredrik at pythonware.com Mon Jul 3 16:01:17 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 3 Jul 2000 16:01:17 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> Message-ID: <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> martin wrote: > > > > $ export LANG=posix.utf8 > [...] > > (or to put it another way, I'm not sure the repr/str fix is > > the real culprit here...) > > I think it is. My understanding is that repr always returns something > printable - if possible even something that can be passed to eval. I'd > certainly expect that a minidom Node can be printed always, no matter > what the default encoding is. > > Consequently, I'd prefer if the conversion uses some fixed, repr-style > encoding, eg. unicode-escape (just as repr of a unicode object does). oh, you're right. repr should of course use unicode-escape, not the default encoding. my fault. I'll update the repository soonish. > If it is deemed unacceptable to put this into the interpreter proper, > I'd prefer if minidom is changed to allow representation of all Nodes > on all systems. the reason for this patch was to avoid forcing everyone to deal with this in their own code, by providing some kind of fallback behaviour. From fdrake at beopen.com Mon Jul 3 16:23:34 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 10:23:34 -0400 (EDT) Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000703095600.A12141@thyrsus.com> References: <20000703095600.A12141@thyrsus.com> Message-ID: <14688.41446.716190.904222@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > I have a valid ssh account on SourceForge. I follow the directions on the > Python CVS page and get this: This looks like SourceForge is having problems. Have you verified that you've installed your public key? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Mon Jul 3 17:35:18 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 17:35:18 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> Message-ID: <3960B2B6.9290F932@lemburg.com> Fredrik Lundh wrote: > > martin wrote: > > > > > > $ export LANG=posix.utf8 > > [...] > > > (or to put it another way, I'm not sure the repr/str fix is > > > the real culprit here...) > > > > I think it is. My understanding is that repr always returns something > > printable - if possible even something that can be passed to eval. I'd > > certainly expect that a minidom Node can be printed always, no matter > > what the default encoding is. > > > > Consequently, I'd prefer if the conversion uses some fixed, repr-style > > encoding, eg. unicode-escape (just as repr of a unicode object does). > > oh, you're right. repr should of course use unicode-escape, not > the default encoding. my fault. > > I'll update the repository soonish. I'd rather have some more discussion about this... IMHO, all auto-conversions should use the default encoding. The main point here is not to confuse the user with even more magic happening under the hood. If the programmer knows that he'll have to deal with Unicode then he should make sure that the proper encoding is used and document it that way, e.g. use unicode-escape for Minidom's __repr__ methods. BTW, any takers for __unicode__ to complement __str__ ? > > If it is deemed unacceptable to put this into the interpreter proper, > > I'd prefer if minidom is changed to allow representation of all Nodes > > on all systems. > > the reason for this patch was to avoid forcing everyone to deal with > this in their own code, by providing some kind of fallback behaviour. That's what your patch does; I don't see a reason to change it :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From esr at thyrsus.com Mon Jul 3 17:53:36 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 11:53:36 -0400 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <14688.41446.716190.904222@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 03, 2000 at 10:23:34AM -0400 References: <20000703095600.A12141@thyrsus.com> <14688.41446.716190.904222@cj42289-a.reston1.va.home.com> Message-ID: <20000703115336.C12315@thyrsus.com> Fred L. Drake, Jr. : > > Eric S. Raymond writes: > > I have a valid ssh account on SourceForge. I follow the directions on the > > Python CVS page and get this: > > This looks like SourceForge is having problems. Have you verified > that you've installed your public key? Yes, I can ssh to my SouurceForge account with no problems. -- Eric S. Raymond When all government ...in little as in great things... shall be drawn to Washington as the center of all power; it will render powerless the checks provided of one government on another, and will become as venal and oppressive as the government from which we separated." -- Thomas Jefferson, 1821 Don't think of it as `gun control', think of it as `victim disarmament'. If we make enough laws, we can all be criminals. From effbot at telia.com Mon Jul 3 18:00:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 3 Jul 2000 18:00:19 +0200 Subject: [Python-Dev] FYI: Perl Unicode Handling HOWTO Message-ID: <006401bfe508$9ebf4ee0$f2a6b5d4@hagrid> for the curious: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-07/msg00004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Unicode Handling HOWTO.url Type: application/octet-stream Size: 224 bytes Desc: not available URL: From paul at prescod.net Mon Jul 3 18:15:46 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 11:15:46 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> Message-ID: <3960BC32.CBBF3D6D@prescod.net> "M.-A. Lemburg" wrote: > > ... > > IMHO, all auto-conversions should use the default encoding. The > main point here is not to confuse the user with even more magic > happening under the hood. I don't see anything confusing about having unicode-escape be the appropriate escape used for repr. Maybe we need to differentiate between lossless and lossy encodings. If the default encoding is lossless then repr could use it. Otherwise it could use unicode-escape. Anyhow, why would it be wrong for Fredrick to hard-code an encoding in repr but right for me to hard-code one in minidom? Users should not need to comb through the hundreds of modules in the library figuring out what kind of Unicode handling they should expect. It should be as centralized as possible. > If the programmer knows that he'll have to deal with Unicode > then he should make sure that the proper encoding is used > and document it that way, e.g. use unicode-escape for Minidom's > __repr__ methods. One of the major goals of our current Unicode auto-conversion "compromise" is that modules like xmllib and minidom should work with Unicode out of the box without any special enhancements. According to Guido, that's the primary reason we have Unicode auto-conversions at all. http://www.python.org/pipermail/i18n-sig/2000-May/000173.html I'm going to fight very hard to make basic Unicode support in Python modules "just work" without a bunch of internationalization knowledge from the programmer. __repr__ is pretty basic. > > the reason for this patch was to avoid forcing everyone to deal with > > this in their own code, by providing some kind of fallback behaviour. > > That's what your patch does; I don't see a reason to change it :-) If you're still proposing that I should deal with it in a particular module's domain-specific code then the patch isn't done yet! -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Mon Jul 3 18:21:26 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 11:21:26 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <39605067.DCC2B968@lemburg.com> Message-ID: <3960BD86.A10797E3@prescod.net> "M.-A. Lemburg" wrote: > > ... > > I think it's ok to auto-convert to the default encoding > as intermediate solution, but the applications wanting to > return Unicode as __repr__ or __str__ should really > use .encode() to make sure the output that is produces > matches their (or their user's) expectations. If my users have expectations, I don't know them. I could allow them to tell me what encoding to use, but surely they would rather do that in a Python-wide fashion. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Mon Jul 3 18:24:41 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 11:24:41 -0500 Subject: [Python-Dev] Sorry. No Release. References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> Message-ID: <3960BE49.CAB2776B@prescod.net> "Fred L. Drake, Jr." wrote: > > ... > > (Just adding IndentationError for -tt isn't hard, I have a > preliminary patch for that now. Adding it for the case above looks > harder.) I think that in a perfect world, IndentationError would apply to both of them. Maybe TabError would be a subclass of IndentationError. You could set up the hierarchy that way without actually implementing the code that recognizes "ordinary" indentation errors. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From mal at lemburg.com Mon Jul 3 18:37:12 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 18:37:12 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> <3960BC32.CBBF3D6D@prescod.net> Message-ID: <3960C138.85D9B36A@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > IMHO, all auto-conversions should use the default encoding. The > > main point here is not to confuse the user with even more magic > > happening under the hood. > > I don't see anything confusing about having unicode-escape be the > appropriate escape used for repr. Maybe we need to differentiate between > lossless and lossy encodings. If the default encoding is lossless then > repr could use it. Otherwise it could use unicode-escape. Simply because auto-conversion should use one single encoding throughout the code. > Anyhow, why would it be wrong for Fredrick to hard-code an encoding in > repr but right for me to hard-code one in minidom? Because hardcoding the encoding into the core Python API touches all programs. Hardcoded encodings should be userland options whereever possible. Besides, we're talking about __repr__ which is mainly a debug tool and doesn't affect program flow or interfacing in any way. The format used is a userland decision and the encoding used for it is too. > Users should not need > to comb through the hundreds of modules in the library figuring out what > kind of Unicode handling they should expect. It should be as centralized > as possible. True. > > If the programmer knows that he'll have to deal with Unicode > > then he should make sure that the proper encoding is used > > and document it that way, e.g. use unicode-escape for Minidom's > > __repr__ methods. > > One of the major goals of our current Unicode auto-conversion > "compromise" is that modules like xmllib and minidom should work with > Unicode out of the box without any special enhancements. According to > Guido, that's the primary reason we have Unicode auto-conversions at > all. > > http://www.python.org/pipermail/i18n-sig/2000-May/000173.html > > I'm going to fight very hard to make basic Unicode support in Python > modules "just work" without a bunch of internationalization knowledge > from the programmer. Great :-) The next big project ought to be getting the standard lib to work with Unicode input. A good way to test drive this, is running Python with -U option. > __repr__ is pretty basic. > > > > the reason for this patch was to avoid forcing everyone to deal with > > > this in their own code, by providing some kind of fallback behaviour. > > > > That's what your patch does; I don't see a reason to change it :-) > > If you're still proposing that I should deal with it in a particular > module's domain-specific code then the patch isn't done yet! You don't have too: a user who uses Latin-1 tag names will see the output of __repr__ as Latin-1... pretty straight forward if you ask me. If you want to make sure that __repr__ output is printable everywhere you should use an explicit lossless encoding for your application. Again, this is a userland decision which you'll have to make. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 3 18:39:52 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 18:39:52 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <39605067.DCC2B968@lemburg.com> <3960BD86.A10797E3@prescod.net> Message-ID: <3960C1D8.18C4EA7D@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > I think it's ok to auto-convert to the default encoding > > as intermediate solution, but the applications wanting to > > return Unicode as __repr__ or __str__ should really > > use .encode() to make sure the output that is produces > > matches their (or their user's) expectations. > > If my users have expectations, I don't know them. I could allow them to > tell me what encoding to use, but surely they would rather do that in a > Python-wide fashion. They can choose the encoding by setting their LANG variable or you could make the setting application specific by using .encode where needed. BTW, are tag names using non-ASCII really used in practice ? I can understand values being Unicode, but Unicode tag names don't really make all that much sense to me (ok, that's a personal opinion). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 3 18:44:14 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 18:44:14 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> <028301bfe37f$bb349380$f2a6b5d4@hagrid> <395E44E2.63383BC5@lemburg.com> <39606D0C.CB3F18FD@lemburg.com> Message-ID: <3960C2DE.F7E2FB7A@lemburg.com> FYI, I've added two new macros which allow querying alphabetic and alphanumeric characters: Py_UNICODE_ISALPHA() and Py_UNICODE_ISALNUM() The implementation is currently only experimental -- some 5200 chars are missing from being correctly identified as being alphanumeric (see my other post on the topic). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Mon Jul 3 19:01:27 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 3 Jul 2000 19:01:27 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> <3960BC32.CBBF3D6D@prescod.net> <3960C138.85D9B36A@lemburg.com> Message-ID: <00d201bfe510$573fce20$f2a6b5d4@hagrid> mal wrote: > > Anyhow, why would it be wrong for Fredrick to hard-code an encoding in > > repr but right for me to hard-code one in minidom? > > Because hardcoding the encoding into the core Python API touches > all programs. Hardcoded encodings should be userland options > whereever possible. the problem is that the existing design breaks peoples expectations: first, minidom didn't work because people expected to be able to return the result of: "8 bit string" + something + "8 bit string" or "8 bit string %s" % something from __repr__. that's a reasonable expectation (just look in the python standard library). after my fix, minidom still didn't work because people expected the conversion to work on all strings, on all platforms. that's also a reasonable expectation (read on). > Besides, we're talking about __repr__ which is mainly a > debug tool and doesn't affect program flow or interfacing > in any way. exactly. this is the whole point: __repr__ is a debug tool, and therefore it must work in all platforms, for all strings. if it's true that repr() cannot be changed to return unicode strings (in which case the conversion will be done on the way out to the user, by a file object or a user-interface library which might actually know what encoding to use), using a lossless encoding is the second best thing. on the other hand, if we can change repr/str, this is a non- issue. maybe someone could tell me exactly what code we'll break if we do that change? From gward at mems-exchange.org Mon Jul 3 19:07:48 2000 From: gward at mems-exchange.org (Greg Ward) Date: Mon, 3 Jul 2000 13:07:48 -0400 Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: <200007010151.DAA00574@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sat, Jul 01, 2000 at 03:51:07AM +0200 References: <200007010151.DAA00574@python.inrialpes.fr> Message-ID: <20000703130748.A31370@ludwig.cnri.reston.va.us> [Ping] > Okay, i just discovered sunau.py. Here's my real shot at > test_linuxaudiodev.py. Can you give this a try? Didn't work -- even after I changed has_key(formats, ...) to formats.has_key(...). Here's what I get: Traceback (most recent call last): File "test_linuxaudiodev-ping.py", line 37, in ? test() File "test_linuxaudiodev-ping.py", line 35, in test play_au_file(findfile('audiotest.au')) File "test_linuxaudiodev-ping.py", line 26, in play_au_file raise "audio format not supported by linuxaudiodev" audio format not supported by linuxaudiodev Sheesh, you'd think that plain old "Sun/NeXT audio data: 8-bit ISDN u-law, mono, 8000 Hz" (this is what "file" reports on "audiotest.au") would be supported. ;-) So I tried Michael Hudson's version. It also failed, but in a more interesting way. There mere traceback is not enough, but it's a start: Traceback (most recent call last): File "test_linuxaudiodev-hudson.py", line 62, in ? test() File "test_linuxaudiodev-hudson.py", line 60, in test play_au_file(findfile('audiotest.au')) File "test_linuxaudiodev-hudson.py", line 55, in play_au_file dsp.write(data) linuxaudiodev.error: (11, 'Resource temporarily unavailable') Here's the sequence of events I get: * run Michael's version of test_linuxaudiodev.py * it *immediately* dumps the above traceback, but does not return me to my shell prompt * Cardinal Fang *does* start his famous proclamation, and it sounds right (same as I get from "play audiotest.au") * but it's truncated about 3/4 of the way through: "Nobody expects the Spani----" * and then Python terminates with exit status 1 (presumably due to the traceback) Very curious! I know next-to-nothing about both Python's exception handling, sound drivers on Linux, and PC audio hardware. Any speculation I might offer would probably be useless, so I will merely comment that this is indeed curious. Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From bckfnn at worldonline.dk Mon Jul 3 19:06:05 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Mon, 03 Jul 2000 17:06:05 GMT Subject: [Python-Dev] unicode alphanumerics In-Reply-To: <39606D0C.CB3F18FD@lemburg.com> References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> <028301bfe37f$bb349380$f2a6b5d4@hagrid> <395E44E2.63383BC5@lemburg.com> <39606D0C.CB3F18FD@lemburg.com> Message-ID: <3960c790.8381401@smtp.worldonline.dk> [M.-A. Lemburg] >"M.-A. Lemburg" wrote: >> >> Fredrik Lundh wrote: >> > how about this plan: >> > >> > -- you add a Py_UNICODE_ALPHA to unicodeobject.h asap, >> > which does exactly that (or I can do that, if you prefer). >> > (and maybe even a Py_UNICODE_ALNUM) >> >> Ok, I'll add Py_UNICODE_ISALPHA and Py_UNICODE_ISALNUM >> (first with approximations of the sort you give above and >> later with true implementations using tables in unicodectype.c) >> on Monday... gotta run now. >> >> > -- I change SRE to use that asap. >> > >> > -- you, I, or someone else add a better implementation, >> > some other day. > >I've just looked into this... the problem here is what to >consider as being "alpha" and what "numeric". > >I could add two new tables for the characters with category 'Lo' >(other letters, not cased) and 'Lm' (letter modifiers) >to match all letters in the Unicode database, but those >tables have some 5200 entries (note that there are only 804 lower >case letters and 686 upper case ones). In JDK1.3, Character.isLetter(..) and Character.isDigit(..) are documented as: http://java.sun.com/j2se/1.3/docs/api/java/lang/Character.html#isLetter(char) http://java.sun.com/j2se/1.3/docs/api/java/lang/Character.html#isDigit(char) http://java.sun.com/j2se/1.3/docs/api/java/lang/Character.html#isLetterOrDigit(char) I guess that java uses the extra huge tables. regards, finn From paul at prescod.net Mon Jul 3 20:38:26 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 13:38:26 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> <3960BC32.CBBF3D6D@prescod.net> <3960C138.85D9B36A@lemburg.com> <00d201bfe510$573fce20$f2a6b5d4@hagrid> Message-ID: <3960DDA2.3C608267@prescod.net> Fredrik Lundh wrote: > > ... > > exactly. this is the whole point: __repr__ is a debug tool, > and therefore it must work in all platforms, for all strings. As a debugging tool, it would probably help rather than hurt things to have repr be consistent on all platforms. If it is going to do a conversion, I vote for unicode-escape everywhere. > on the other hand, if we can change repr/str, this is a non- > issue. maybe someone could tell me exactly what code we'll > break if we do that change? I agree that we want to move to a world where unicode strings and 8-bit strings are accepted equally throughout Python. We do need some information about whether moving there quickly will break code or not. We need to know what Idle, PythonWin, Zope and other such environments do with the results of repr. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From ping at lfw.org Mon Jul 3 23:35:38 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 3 Jul 2000 16:35:38 -0500 (CDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000703095016.A24655@ludwig.cnri.reston.va.us> Message-ID: Eric S. Raymond wrote: > WhitespaceError Greg Ward wrote: > How about TabError? But what i'd really like is an IndentationError that shows up whenever there's an indentation problem. It doesn't even have to be its own class of error, i suppose, as long as it gets indicated some way ("SyntaxError: invalid indentation" would be fine). This response would be good for all of the following situations: >>> 3 File "", line 1 3 ^ SyntaxError: invalid syntax >>> if 1: ... 3 File "", line 2 3 ^ SyntaxError: invalid syntax >>> if 1: ... 3 ... 4 inconsistent dedent File "", line 3 4 ^ SyntaxError: invalid token >>> if 1: ... if 2: ... 3 File "", line 3 3 ^ SyntaxError: invalid syntax >>> if 1: ... if 2: ... 3 inconsistent dedent File "", line 3 3 ^ SyntaxError: invalid token >>> if 1: ... if 2: ... 3 ... 4 inconsistent dedent File "", line 4 4 ^ SyntaxError: invalid token -- ?!ng From tim_one at email.msn.com Mon Jul 3 23:52:13 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 3 Jul 2000 17:52:13 -0400 Subject: [Python-Dev] Just spotted on SourceForge main page In-Reply-To: <20000628223707.A1168@beelzebub> Message-ID: > Maybe this is what all you Windows folks are looking for. > > SFSetup v1 released > mhearn - 06/28/00 11:00 - SourceForge Setup for Win32 > > SFSetup is a program to automatically setup SSH and WinCVS for > SourceForge projects under the Windows 32 platform. It's now available > for download so if you have not yet set up SSH and WinCVS and want it > done for you, you can use this program. Go to sfsetup.sourceforge.net > to find out how to use it. It's open source and written in Delphi - > the code is in CVS and any improvements are welcome! Thanks -mike Note that this requires WinCVS 1.06 specifically (something like that -- see SFSetup's readme or whatever). I tried using it with a later version of WinCVS, and it left my machine in some state such that the behaviors of both cmdline CVS and WinCVS make no sense to anyone who has seen them actually working correctly. Barry in particular is baffled by how I manage to check in anything at all now. My ssh_keygen doesn't work either (no, I do *not* need even more pointers to purported Windows ssh implementations -- I've got 'em all, and I'll eventually unpack the one that happens to work on my system ). The great thing about all the instructions I've found so far is that they're written by people who apparently have no real understanding of how the underlying components (and/or Windows) work. So they're full of magical incantations that may or may not make sense on your particular setup. They may as well be trying to explain how to get the Microsoft Foundation Classes running under Linux . poke-&-hope-will-win-in-the-end-ly y'rs - tim From paul at prescod.net Tue Jul 4 00:31:57 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 17:31:57 -0500 Subject: [Python-Dev] Just spotted on SourceForge main page References: Message-ID: <3961145D.708AFDB6@prescod.net> Tim Peters wrote: > > .. > > The great thing about all the instructions I've found so far is that they're > written by people who apparently have no real understanding of how the > underlying components (and/or Windows) work. So they're full of magical > incantations that may or may not make sense on your particular setup. I found the same damn thing. I actually emailed one of the guys about an apparent contradiction between his howto and another one and he basically said: "Hey, this is what works for me!" (in his defence, he did justify his interpration based on guesses about what the ssh for Windows porters were thinking) I also found that sfsetup program useless. Worse than useless. I have no idea what it did to my system. Argh. I eventually got it working. I'd love to tell you what I did but I just hacked and hacked until it worked. One time I got those messages that ESR did but who knows what made them go away. I'm not using ssh keys. I just specify my password over and over and over and over and... -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From fdrake at beopen.com Tue Jul 4 00:58:22 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 18:58:22 -0400 (EDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: References: <20000703095016.A24655@ludwig.cnri.reston.va.us> Message-ID: <14689.6798.745740.419095@cj42289-a.reston1.va.home.com> Ka-Ping Yee writes: > But what i'd really like is an IndentationError that shows > up whenever there's an indentation problem. That's what I think of when I hear "IndentationError" -- TabError is a specialized case of that. I think the general IndentationError will be hard to do, since many cases are just another parse error by the time they can be turned into exceptions. Unless I'm misreading that code. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein at lyra.org Tue Jul 4 01:20:43 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 16:20:43 -0700 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <14689.6798.745740.419095@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 03, 2000 at 06:58:22PM -0400 References: <20000703095016.A24655@ludwig.cnri.reston.va.us> <14689.6798.745740.419095@cj42289-a.reston1.va.home.com> Message-ID: <20000703162043.K29590@lyra.org> On Mon, Jul 03, 2000 at 06:58:22PM -0400, Fred L. Drake, Jr. wrote: > > Ka-Ping Yee writes: > > But what i'd really like is an IndentationError that shows > > up whenever there's an indentation problem. > > That's what I think of when I hear "IndentationError" -- TabError is > a specialized case of that. > I think the general IndentationError will be hard to do, since many > cases are just another parse error by the time they can be turned into > exceptions. Unless I'm misreading that code. Speaking out of my butt here, without looking at code, I would suspect that the parser can return specializations "syntax error" to indicate that a problem with indentation occurred. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jul 4 01:53:05 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 16:53:05 -0700 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000703095600.A12141@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 03, 2000 at 09:56:00AM -0400 References: <20000703095600.A12141@thyrsus.com> Message-ID: <20000703165305.R29590@lyra.org> On Mon, Jul 03, 2000 at 09:56:00AM -0400, Eric S. Raymond wrote: > I have a valid ssh account on SourceForge. I follow the directions on the > Python CVS page and get this: > > Script started on Mon Jul 3 09:50:42 2000 > snark:~/WWW/python$ echo $CVS_RSH > /usr/bin/ssh > snark:~/WWW/python$ cvs -z3 -desr at cvs.python.sourceforge.net:/cvsroot/python co python I used: $ cvs -z3 -d :ext:gstein at cvs.python.sourceforge.net:/cvsroot/python co python The instructions on SF didn't quite work. Adding the :ext: in made it work fine for me. I'm using CVS 1.10.6 Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Tue Jul 4 01:54:43 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 19:54:43 -0400 (EDT) Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000703165305.R29590@lyra.org> References: <20000703095600.A12141@thyrsus.com> <20000703165305.R29590@lyra.org> Message-ID: <14689.10179.591139.81266@cj42289-a.reston1.va.home.com> Greg Stein writes: > I used: > > $ cvs -z3 -d :ext:gstein at cvs.python.sourceforge.net:/cvsroot/python co python > > The instructions on SF didn't quite work. Adding the :ext: in made it work > fine for me. I'm using CVS 1.10.6 Interesting; using CVS 1.10.7 I was able to check out a tree using my login & SSH (requiring my passphrase, not password), but I didn't need the :ext: part. Sounds like there are some real version dependencies in the instructions. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Tue Jul 4 04:25:33 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 03 Jul 2000 21:25:33 -0500 Subject: [Python-Dev] Copyright notice In-Reply-To: Your message of "Sun, 02 Jul 2000 00:43:17 +0200." <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> References: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> Message-ID: <200007040225.VAA01396@cj20424-a.reston1.va.home.com> > On startup, the current CVS python reports (on my system) > > Python 2.0b1 (#31, Jul 1 2000, 23:13:39) [GCC 2.95.2 19991024 (release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > > Now that the file copyrights are changed, I expect this message to > change as well. May I suggest that, instead of adding another line, > the two last lines of this message are removed? > > People who need to find out who holds the copyright to this software > still can print sys.copyright. I think I recall this was a convention that the GNU folks claim is required from a legal standpoint. E.g. when I start gdb, I get: GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux". (gdb) The Python welcome message is a lot less verbose! But I am not a lawyer (IANAL) and maybe the GNU folks are superstitious about this. On the other hand, why does it bother you? (*NOT* a rhetorical question.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Tue Jul 4 03:48:17 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 21:48:17 -0400 Subject: [Python-Dev] Copyright notice In-Reply-To: <200007040225.VAA01396@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 03, 2000 at 09:25:33PM -0500 References: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> <200007040225.VAA01396@cj20424-a.reston1.va.home.com> Message-ID: <20000703214817.A13791@thyrsus.com> Guido van Rossum : > On the other hand, why does it bother you? (*NOT* a rhetorical question.) Maybe he doesn't like noisy programs. I don't either. Programs should either (a) tell me what I need to hear, (b) tell me what I've asked to hear, or (c) keep their traps shut and refrain from wasting my time and attention. (There are some who would say this atttude makes me old-fashioned in an age of GUIs. Au contraire -- visual gewgaws and noise are so seductive to interface designers that we need to be *less* tolerant of noise than formerly.) -- Eric S. Raymond The men and women who founded our country knew, by experience, that there are times when the free person's answer to oppressive government has to be delivered with a bullet. Thus, the right to bear arms is not just *a* freedom; it's the mother of all freedoms. Don't let them disarm you! From gstein at lyra.org Tue Jul 4 04:02:36 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 19:02:36 -0700 Subject: [Python-Dev] Copyright notice In-Reply-To: <20000703214817.A13791@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 03, 2000 at 09:48:17PM -0400 References: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> <200007040225.VAA01396@cj20424-a.reston1.va.home.com> <20000703214817.A13791@thyrsus.com> Message-ID: <20000703190235.G29590@lyra.org> On Mon, Jul 03, 2000 at 09:48:17PM -0400, Eric S. Raymond wrote: > Guido van Rossum : > > On the other hand, why does it bother you? (*NOT* a rhetorical question.) > > Maybe he doesn't like noisy programs. I don't either. Programs > should either (a) tell me what I need to hear, (b) tell me what I've > asked to hear, or (c) keep their traps shut and refrain from wasting my > time and attention. Agreed. I've prefer not to have several lines of spammage hit my screen whenever I invoked Python. What's the point? And note there isn't a license requirement to print that stuff. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Tue Jul 4 04:31:11 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 4 Jul 2000 12:31:11 +1000 Subject: [Python-Dev] Copyright notice In-Reply-To: <20000703214817.A13791@thyrsus.com> Message-ID: > Programs > should either (a) tell me what I need to hear, (b) tell me what I've > asked to hear, or (c) keep their traps shut and refrain from wasting my > time and attention. You have almost described my perfect partner :-) [Not really, of course, but the sexist comparison was just _screaming_ to be made :-] Mark. From gstein at lyra.org Tue Jul 4 04:59:08 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 19:59:08 -0700 Subject: [Python-Dev] Copyright notice In-Reply-To: ; from mhammond@skippinet.com.au on Tue, Jul 04, 2000 at 12:31:11PM +1000 References: <20000703214817.A13791@thyrsus.com> Message-ID: <20000703195908.H29590@lyra.org> On Tue, Jul 04, 2000 at 12:31:11PM +1000, Mark Hammond wrote: > > > Programs > > should either (a) tell me what I need to hear, (b) tell me what I've > > asked to hear, or (c) keep their traps shut and refrain from wasting my > > time and attention. > > You have almost described my perfect partner :-) *rofl* > [Not really, of course, but the sexist comparison was just _screaming_ to > be made :-] Sexist? Not at all. You didn't say whether your perfect partner was a man or a woman. ;-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Tue Jul 4 06:35:00 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 00:35:00 -0400 (EDT) Subject: [Python-Dev] Making -tt the default Message-ID: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> The recent discussion about the possibility of specialized forms of SyntaxError for indentation and tab/space issues brings up the problem of the -t/-tt options to the interpreter. If a distinct exception is defined for indentation-related errors, that could probably be implemented and tested without regard for the -t/-tt setting, except for the tab/space exception. That exception is only raised when -tt is specified, and there's no way from Python to determine if it is set except for testing to see that the exception is raised when ambiguous tab/space combinations are presented to the tokenizer. This reminds us that most programmers aren't going to bother with the -tt option; it's something extra that they don't really need to get the job done. Life without it, however, is shakey: Python code is harder to share than it needs to be because nobody can rely on non-ambiguous tab/space usage. If -tt were the default, the problem would not be discovered after code is deployed but, rather, before it is otherwise tested by the original developers and maintainers. There are two things that can be done: have distutils always use -tt when compiling code that gets installed (using a child interpreter if needed), and setting -tt as the default in the next Python release. Using -tt in the distutils will cause this setting to be used with Python 1.5.2 installations. Setting -tt to be the default, and not having a way to override it, would lead to some small code simplifications as well. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From DavidA at ActiveState.com Tue Jul 4 06:45:22 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 3 Jul 2000 21:45:22 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: > This reminds us that most programmers aren't going to bother with > the -tt option; it's something extra that they don't really need to > get the job done. Which reminds me that I'd really like the default python-mode.el to use more 'strict' defaults than it currently does. I don't know how, but I routinely generate bad indentations w/ pymode, which I blame on bad defaults in the elisp file. I can fix the config, of course, with enough work, but I believe it should be set to a more strict default. --da From fdrake at beopen.com Tue Jul 4 06:49:53 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 00:49:53 -0400 (EDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000703162043.K29590@lyra.org> References: <20000703095016.A24655@ludwig.cnri.reston.va.us> <14689.6798.745740.419095@cj42289-a.reston1.va.home.com> <20000703162043.K29590@lyra.org> Message-ID: <14689.27889.33072.39039@cj42289-a.reston1.va.home.com> Greg Stein writes: > Speaking out of my butt here, without looking at code, I would suspect that > the parser can return specializations "syntax error" to indicate that a > problem with indentation occurred. And I'm sure you'll find the way to do it. ;) Here's a patch that sets up the IndentationError and TabError exceptions, and gets TabError raised when -tt is in effect. If you can figure out how to get IndentationError raised for other indentation-related errors, I'll be interested in seeing it. Essentially, the parser-generator will need to be able to distinguish between INDENT/DEDENT errors and other errors, and I've not dug deep enough to figure that one out. The tab/space errors are easy since they're in the hand-coded lexer. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: indentation-error.patch URL: From fdrake at beopen.com Tue Jul 4 06:54:04 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 00:54:04 -0400 (EDT) Subject: [Python-Dev] Making -tt the default In-Reply-To: References: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: <14689.28140.772442.865150@cj42289-a.reston1.va.home.com> David Ascher writes: > Which reminds me that I'd really like the default python-mode.el to use more > 'strict' defaults than it currently does. I don't know how, but I routinely > generate bad indentations w/ pymode, which I blame on bad defaults in the > elisp file. I can fix the config, of course, with enough work, but I > believe it should be set to a more strict default. Recent versions of python-mode all use default indentations of 4 spaces, and I don't think it generates tabs. If it can, it shouldn't. Barry? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Tue Jul 4 07:01:48 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 4 Jul 2000 01:01:48 -0400 Subject: Windows vs SourceForge (was RE: [Python-Dev] Just spotted on SourceForge main page) In-Reply-To: <200007040313.WAA01842@cj20424-a.reston1.va.home.com> Message-ID: [Tim] > The great thing about all the instructions I've found so far is > that they're written by people who apparently have no real understanding > of how the underlying components (and/or Windows) work. [an anonymous Guido replied in pvt] > That was not my impression of Andy's instructions. They were to the > point and effective. Yes, they certainly *looked* that way . I didn't mean to slander Andy! His instructions didn't work for me, but then nobody else's did either, and I've increasingly suspected it's because I've got so many half-broken SSH, CVS, and WinCVS installations on this machine fighting each other. So, without an imminent release busting my homeless balls, I decided to take the time to start over from scratch: + Ran an official uninstaller for everything that left one behind (only WinCVS). + Manually tracked down all the crap WinCVS left behind in the registry anyway, and deleted it. + Deleted all the ssh and cvs .exe's on machine. + Got the crap out of my autoexec.bat (I'm running Win98SE) that various packages had inserted there (I *think* this stuff was left behind by the SourceForge setup tool). + Deleted all the .ssh directories on my machine (and found some in surprising places! e.g., one was hiding under "\My Documents"(!)). + Got rid of an absurd \etc directory (again suspect the SF setup tool, although several goofy sets of instructions demanded you create one of these). + Nuked my entire Python tree. + Rebooted. + Did a full tape backup of the machine . + Retrieved Andy Robinson's instructions and tried them again. Worked great! I'll attach a modified version below, where I filled in blanks and repaired (just a few) typos as I went along. This should get you a functional Windows cmdline CVS running with SourceForge, and I don't want a GUI version anyway. If there's anything here that isn't crystal clear or doesn't work, gripe at me, not Andy ... all's-well-that-ends-ly y'rs - tim Setting up a cmdline CVS to work with SourceForge under Windows --------------------------------------------------------------- 28-Jun-2000 Original by Andy Robinson (andy at reportlab.com) 03-Jul-2000 Modified by Tim Peters (tim_one at msn.com) 1. Get ftp.reportlab.com/tools/cvs-1.10-win.zip ftp.reportlab.com/tools/ssh-1.2.14-win32bin.zip (copied from somewhere obscure for safety, I forget where) 2. Unzip these to a location on your path. Type 'cvs' and 'ssh' from somewhere else to verify. 3. Choose where to keep your CVS projects; let's assume C:\Code 4. Create a subdirectory C:\Code\.ssh (yes, dot-ssh) 5. (see #8 for an alternative) Create two environment variables: HOME=C:\Code CVS_RSH=ssh HOME must point to the directory above your .ssh directory. On Win9x, this can be done in a batch file or autoexec.bat; e.g., set HOME=c:\Code set CVS_RSH=ssh Run the batch file, or reboot if you're using autoexec.bat. On NT or 2000, go to Control Panel | System | Environment and set them at either user or machine level. 6. If not done so, get a Sourceforge account and a project you can log in to. 7. Teach SSH about your project's home, by doing ssh -l $USERNAME $MYPROJECT.sourceforge.net where $USERNAME is your SourceForge login name and $MYPROJECT your SourceForge project name. You'll see Host "$MYPROJECT.sourceforge.net" added to the list of known hosts. and then Creating random seed file ~/.ssh/random_seed. This may take a while. After a while it will prompt for a password. Type your SourceForge password and hit ENTER. After some SourceForge msgs scroll by, you'll be left at a SourceForge shell prompt. Type exit and hit ENTER. Now you're back at the DOS prompt. 8. You will need either a lengthy command line or a batch file for each sourceforge project. I set cvsroot in a batch file in my 'c:\code' directory, and have one such file for each CVS project I use (about ten of them!): set CVSROOT=:ext:$USERNAME at cvs.$MYPROJECT.sourceforge.net:/cvsroot/$DIRNAME where $USERNAME and $MYPROJECT are again your SourceForge login and project names, and $DIRNAME is the top-level directory in the SourceForge CVS tree; a project can have several, but usually there is just one. Note: you can keep HOME and CVS_SSH out of your permanent environment (see #5) by adding those definitions to this batch file instead. 9. Execute this batch file. You can now go to C:\Code and do cvs -z7 checkout $MYPROJECT (z7 means 'compress network traffic', handy over dialup lines) 10. From now on, just use CVS normally, running this batch file first each time you bring up a DOS box you're going to use for CVS work. Note that you'll be asked for your password each time you enter a CVS command. I wouldn't survive without Karl Fogel's book "Open Source Development with CVS", Coriolis Press. The CVS reference material (about 225 printed pages!) from this book is available for free download from http://cvsbook.red-bean.com/ Footnote: for anonymous checkout, I think you just omit the 'my_user_name@' part from the CVSROOT variable. I hope this helps; let me know if people have any problems with the instructions. - Andy Robinson ReportLab From tim_one at email.msn.com Tue Jul 4 07:11:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 4 Jul 2000 01:11:27 -0400 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14689.28140.772442.865150@cj42289-a.reston1.va.home.com> Message-ID: [David Ascher] > Which reminds me that I'd really like the default python-mode.el to use > more 'strict' defaults than it currently does. If you can, please be explicit about what exactly in the pymode config you think needs to be changed. I can't tell from your complaint. > I don't know how, But we should be able to guess ? > but I routinely generate bad indentations w/ pymode, which I blame on bad > defaults in the elisp file. I can fix the config, of course, If so, being explicit should be a piece of cake ... > with enough work, but I believe it should be set to a more strict default. I never got bad indentation out of pymode when I was working on it, so I'm at a loss here. It can't prevent you from, e.g., inserting a literal tab character via C-q, if that's what you're doing. I assume you're not doing that, though. More info! From gstein at lyra.org Tue Jul 4 07:17:07 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 22:17:07 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: ; from DavidA@ActiveState.com on Mon, Jul 03, 2000 at 09:45:22PM -0700 References: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: <20000703221706.L29590@lyra.org> On Mon, Jul 03, 2000 at 09:45:22PM -0700, David Ascher wrote: > > This reminds us that most programmers aren't going to bother with > > the -tt option; it's something extra that they don't really need to > > get the job done. > > Which reminds me that I'd really like the default python-mode.el to use more > 'strict' defaults than it currently does. I don't know how, but I routinely > generate bad indentations w/ pymode, which I blame on bad defaults in the > elisp file. I can fix the config, of course, with enough work, but I > believe it should be set to a more strict default. Never seen this happen. Can you watch yourself and discover how you are generating these? I do admit that maybe pymode is generating them for me, too, but that I unconsciously compensate for the problem. I have certainly never consciously went "woah! bad pymode! bad pymode! stop that!" :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Tue Jul 4 07:23:29 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 4 Jul 2000 01:23:29 -0400 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > ... > There are two things that can be done: have distutils always use > -tt when compiling code that gets installed (using a child interpreter > if needed), and setting -tt as the default in the next Python > release. +1 from me. Hey, it's 2.0: we can break anything . > .... > Setting -tt to be the default, and not having a way to override it, +1 on that too. > would lead to some small code simplifications as well. and-also-cut-out-one-bogus-source-of-c.l.py-whitespace- flamewars-ly y'rs - tim From DavidA at ActiveState.com Tue Jul 4 07:49:32 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 3 Jul 2000 22:49:32 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: Message-ID: > If you can, please be explicit about what exactly in the pymode config you > think needs to be changed. I can't tell from your complaint. You can't channel me, eh? Loser. Ok, I'll keep an eye out and see if I can reproduce what I'm doing wrong. Sorry for just complaining and not giving people a chance to fix whatever it is I'm doing wrong =). --david From tim_one at email.msn.com Tue Jul 4 08:06:43 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 4 Jul 2000 02:06:43 -0400 Subject: [Python-Dev] Making -tt the default In-Reply-To: Message-ID: [Tim, fails to channel David] [David Ascher] > You can't channel me, eh? Loser. Oh, indeed yes! No more than two hours before, I failed Guido too, by failing to guess one of the passwords I needed to do something he commanded me to do. My myth of omniscience was much easier to maintain at a distance . > Ok, I'll keep an eye out and see if I can reproduce what I'm doing wrong. > Sorry for just complaining and not giving people a chance to fix > whatever it is I'm doing wrong =). It occurs to me that I had Emacs set up (in my own .emacs) to never ever use literal tab characters. That may go a way in explaining why pymode never generated ambiguous indentation for me! I suppose you can also get in trouble by editing *other* peoples' code containing a mix of tabs and spaces. So never do that either. heck-give-up-computers-and-get-an-honest-job-ly y'rs - tim From gstein at lyra.org Tue Jul 4 08:39:38 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 23:39:38 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: ; from tim_one@email.msn.com on Tue, Jul 04, 2000 at 02:06:43AM -0400 References: Message-ID: <20000703233938.N29590@lyra.org> On Tue, Jul 04, 2000 at 02:06:43AM -0400, Tim Peters wrote: >... > > Ok, I'll keep an eye out and see if I can reproduce what I'm doing wrong. > > Sorry for just complaining and not giving people a chance to fix > > whatever it is I'm doing wrong =). > > It occurs to me that I had Emacs set up (in my own .emacs) to never ever use > literal tab characters. That may go a way in explaining why pymode never > generated ambiguous indentation for me! > > I suppose you can also get in trouble by editing *other* peoples' code > containing a mix of tabs and spaces. So never do that either. I use the following tidbit of code in my .emacs: (add-hook 'python-mode-hook (lambda () (setq indent-tabs-mode nil) (setq py-indent-offset 2) (setq py-smart-indentation nil) (define-key py-mode-map "\e\C-h" 'backward-kill-word) )) The indent-tabs-mode is the key to disabling tab characters and using just spaces. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jul 4 09:35:02 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 4 Jul 2000 00:35:02 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.165,2.166 codecs.c,2.8,2.9 compile.c,2.112,2.113 modsupport.c,2.45 In-Reply-To: <200007040710.JAA16635@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Tue, Jul 04, 2000 at 09:10:08AM +0200 References: <200007032139.OAA29276@slayer.i.sourceforge.net> <200007040710.JAA16635@python.inrialpes.fr> Message-ID: <20000704003502.P29590@lyra.org> Placing it there means everybody and their brother will now have to include it. Personally, I'd rather have the number of headers in my compilation unit minimized. Take the argument of "put it into Python.h" to the extreme: why have any includes in any of the .c files? Put them ALL into Python.h so nobody has to bother with them in their .c files. :-) Cheers, -g On Tue, Jul 04, 2000 at 09:10:08AM +0200, Vladimir Marangozov wrote: > > This HAVE_LIMITS_H define spans over several files already. > Why not putting it in Python.h and cleanup the rest? > > Jack Jansen wrote: > > > > Update of /cvsroot/python/python/dist/src/Python > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv29235/Python > > > > Modified Files: > > bltinmodule.c codecs.c compile.c modsupport.c > > Log Message: > > Include limits.h if we have it. > > > > > > Index: bltinmodule.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v > > retrieving revision 2.165 > > retrieving revision 2.166 > > diff -C2 -r2.165 -r2.166 > > *** bltinmodule.c 2000/06/30 23:58:05 2.165 > > --- bltinmodule.c 2000/07/03 21:39:47 2.166 > > *************** > > *** 24,27 **** > > --- 24,30 ---- > > #include > > #endif > > + #ifdef HAVE_LIMITS_H > > + #include > > + #endif > > > > /* Forward */ > > > > Index: codecs.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Python/codecs.c,v > > retrieving revision 2.8 > > retrieving revision 2.9 > > diff -C2 -r2.8 -r2.9 > > *** codecs.c 2000/06/29 14:50:15 2.8 > > --- codecs.c 2000/07/03 21:39:47 2.9 > > *************** > > *** 11,14 **** > > --- 11,17 ---- > > #include "Python.h" > > #include > > + #ifdef HAVE_LIMITS_H > > + #include > > + #endif > > > > /* --- Globals ------------------------------------------------------------ */ > > > > Index: compile.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v > > retrieving revision 2.112 > > retrieving revision 2.113 > > diff -C2 -r2.112 -r2.113 > > *** compile.c 2000/06/30 23:58:06 2.112 > > --- compile.c 2000/07/03 21:39:47 2.113 > > *************** > > *** 34,37 **** > > --- 34,40 ---- > > > > #include > > + #ifdef HAVE_LIMITS_H > > + #include > > + #endif > > > > /* Three symbols from graminit.h are also defined in Python.h, with > > > > Index: modsupport.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Python/modsupport.c,v > > retrieving revision 2.45 > > retrieving revision 2.46 > > diff -C2 -r2.45 -r2.46 > > *** modsupport.c 2000/06/30 23:58:06 2.45 > > --- modsupport.c 2000/07/03 21:39:47 2.46 > > *************** > > *** 12,15 **** > > --- 12,18 ---- > > > > #include "Python.h" > > + #ifdef HAVE_LIMITS_H > > + #include > > + #endif > > > > #ifdef MPW /* MPW pushes 'extended' for float and double types with varargs */ > > > > > > _______________________________________________ > > Python-checkins mailing list > > Python-checkins at python.org > > http://www.python.org/mailman/listinfo/python-checkins > > > > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From fredrik at pythonware.com Tue Jul 4 11:18:40 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 11:18:40 +0200 Subject: [Python-Dev] Re: [ Patch #100719 ] Use '#!/usr/bin/env python' in scripts References: <20000703233938.N29590@lyra.org> Message-ID: <010101bfe598$d88381b0$0900a8c0@SPIFF> (just a heads up, not sure if SF was able to send out the notifications) This patch suggests changing /usr/local/bin/python to /usr/bin/env python in cgi.py and faqwiz.py. Note that both scripts are CGI scripts, and the FAQ has the following to say about that: http://www.python.org/doc/FAQ.html#4.63 Note -- *don't* do this for CGI scripts. The $PATH variable for CGI scripts is often very minimal, so you need to use the actual absolute pathname of the interpreter. -1, in other words (assuming that the FAQ is correct) From mal at lemburg.com Tue Jul 4 11:45:05 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 11:45:05 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! Message-ID: <3961B221.4F7552C3@lemburg.com> There was a discussion about adding a #define _XOPEN_SOURCE to the standard header files in Python (among other things to fix the warning in the timemodule.c on Linux). What happened to that idea ? I think it would be worthwhile to add a #ifdef __GNUC__ # define _GNU_SOURCE #endif to Python.h. This enables all features available for the gcc compiler including _XOPEN_SOURCE and fixes warnings related to missing prototypes. Thoughts ? Would this hurt anybody ? BTW, I'm +1 on adding a mylimits.h to Python.h too. mylimits.h would then either include the system's limits.h file or provide workarounds for platforms which don't have it. Then we could drop the #define INT_MAX which can be found in several Python C files. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Tue Jul 4 11:51:54 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 4 Jul 2000 02:51:54 -0700 Subject: [Python-Dev] Re: [ Patch #100719 ] Use '#!/usr/bin/env python' in scripts In-Reply-To: <010101bfe598$d88381b0$0900a8c0@SPIFF>; from fredrik@pythonware.com on Tue, Jul 04, 2000 at 11:18:40AM +0200 References: <20000703233938.N29590@lyra.org> <010101bfe598$d88381b0$0900a8c0@SPIFF> Message-ID: <20000704025154.W29590@lyra.org> On Tue, Jul 04, 2000 at 11:18:40AM +0200, Fredrik Lundh wrote: > (just a heads up, not sure if SF was able to send > out the notifications) > > This patch suggests changing /usr/local/bin/python to > /usr/bin/env python in cgi.py and faqwiz.py. Note > that both scripts are CGI scripts, and the FAQ has the > following to say about that: > > http://www.python.org/doc/FAQ.html#4.63 > > Note -- *don't* do this for CGI scripts. The $PATH > variable for CGI scripts is often very minimal, so > you need to use the actual absolute pathname of > the interpreter. > > -1, in other words (assuming that the FAQ is correct) I have observed the same behavior in my CGI scripts: you cannot rely on PATH, so the /usr/bin/env thing simply doesn't work. -1 also. Cheers, -g -- Greg Stein, http://www.lyra.org/ From sjoerd at oratrix.nl Tue Jul 4 11:55:41 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Tue, 04 Jul 2000 11:55:41 +0200 Subject: [Python-Dev] SRE incompatibility Message-ID: <20000704095542.8697B31047C@bireme.oratrix.nl> >>> regexp = '(([a-z]+):)?([a-z]+)$' >>> import re >>> re.match(regexp, 'smil').group(0,1,2,3) ('smil', None, 's', 'smil') >>> import pre >>> pre.match(regexp, 'smil').group(0,1,2,3) ('smil', None, None, 'smil') Needless to say, I am relying on the third value being None... (My regular expression was actually more like '(?:(?P[a-z]+):)?(?P[a-z]+)$' and I check for result.group('prefix')) -- Sjoerd Mullender From gstein at lyra.org Tue Jul 4 12:01:43 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 4 Jul 2000 03:01:43 -0700 Subject: [Python-Dev] suggest pyportable.h (was: Make _GNU_SOURCE default for gcc ?!) In-Reply-To: <3961B221.4F7552C3@lemburg.com>; from mal@lemburg.com on Tue, Jul 04, 2000 at 11:45:05AM +0200 References: <3961B221.4F7552C3@lemburg.com> Message-ID: <20000704030143.Y29590@lyra.org> On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: >... GNU_SOURCE ... Seems fine, and I can't see how it would hurt. +1 > BTW, I'm +1 on adding a mylimits.h to Python.h too. mylimits.h > would then either include the system's limits.h file or provide > workarounds for platforms which don't have it. Then we could drop > the #define INT_MAX which can be found in several Python C files. Euh... we should probably stop creating myfoo.h every time we want to replace some "foo" header. It would be much nicer to simply create "pyportable.h" and have it include the various pieces when available or to create suitable defaults for them. There would be a companion pyportable.c to define replacement functions. Continuing to litter the Python source area with a bunch of little files for all the edge cases on the planet... just doesn't make much sense to me. It starts to create too much confusion/complexity. Cheers, -g -- Greg Stein, http://www.lyra.org/ From fredrik at pythonware.com Tue Jul 4 12:08:50 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 12:08:50 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> Message-ID: <018a01bfe59f$da814950$0900a8c0@SPIFF> mal wrote: > There was a discussion about adding a #define _XOPEN_SOURCE > to the standard header files in Python (among other things to > fix the warning in the timemodule.c on Linux). > > What happened to that idea ? > > I think it would be worthwhile to add a > > #ifdef __GNUC__ > # define _GNU_SOURCE > #endif > > to Python.h. This enables all features available for the > gcc compiler including _XOPEN_SOURCE and fixes warnings > related to missing prototypes. > > Thoughts ? Would this hurt anybody ? what does "fixes warnings" mean? does it change the compiler's behaviour, or does it just make sure stuff are defined in the right files? how is this different from just a plain (and truly portable) #define _XOPEN_SOURCE? (the only concern I see here is that people on Linux platforms might start churning out code that depends on certain gcc-only features, without noticing...) +1 on _XOPEN_SOURCE +0 on _GNU_SOURCE From mal at lemburg.com Tue Jul 4 12:13:04 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 12:13:04 +0200 Subject: [Python-Dev] suggest pyportable.h (was: Make _GNU_SOURCE default for gcc ?!) References: <3961B221.4F7552C3@lemburg.com> <20000704030143.Y29590@lyra.org> Message-ID: <3961B8B0.96E010C3@lemburg.com> Greg Stein wrote: > > On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: > >... GNU_SOURCE ... > > Seems fine, and I can't see how it would hurt. > > +1 > > > BTW, I'm +1 on adding a mylimits.h to Python.h too. mylimits.h > > would then either include the system's limits.h file or provide > > workarounds for platforms which don't have it. Then we could drop > > the #define INT_MAX which can be found in several Python C files. > > Euh... we should probably stop creating myfoo.h every time we want to > replace some "foo" header. > > It would be much nicer to simply create "pyportable.h" and have it include > the various pieces when available or to create suitable defaults for them. > There would be a companion pyportable.c to define replacement functions. > > Continuing to litter the Python source area with a bunch of little files for > all the edge cases on the planet... just doesn't make much sense to me. It > starts to create too much confusion/complexity. Fine with me... we should probably make it contains all the different myfoo.h header files. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Jul 4 12:43:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 12:43:23 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> Message-ID: <3961BFCB.DD7895E1@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > There was a discussion about adding a #define _XOPEN_SOURCE > > to the standard header files in Python (among other things to > > fix the warning in the timemodule.c on Linux). > > > > What happened to that idea ? > > > > I think it would be worthwhile to add a > > > > #ifdef __GNUC__ > > # define _GNU_SOURCE > > #endif > > > > to Python.h. This enables all features available for the > > gcc compiler including _XOPEN_SOURCE and fixes warnings > > related to missing prototypes. > > > > Thoughts ? Would this hurt anybody ? > > what does "fixes warnings" mean? does it change the compiler's > behaviour, or does it just make sure stuff are defined in the right > files? AFAIK, it only makes certain APIs available as prototype. Without the prototypes the usual response from the compiler are warning such as "converted integer to pointer without a cast" and somesuch (the default return value being "int"). > how is this different from just a plain (and truly portable) > #define _XOPEN_SOURCE? _XOPEN_SOURCE would also cure the warning in timemodule. > (the only concern I see here is that people on Linux platforms > might start churning out code that depends on certain gcc-only > features, without noticing...) > > +1 on _XOPEN_SOURCE > +0 on _GNU_SOURCE Ok, so how about adding #define _XOPEN_SOURCE to Python.h ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pf at artcom-gmbh.de Tue Jul 4 12:31:34 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 4 Jul 2000 12:31:34 +0200 (MEST) Subject: [Python-Dev] Re: [ Patch #100719 ] Use '#!/usr/bin/env python' in scripts In-Reply-To: <010101bfe598$d88381b0$0900a8c0@SPIFF> from Fredrik Lundh at "Jul 4, 2000 11:18:40 am" Message-ID: Hi, Fredrik Lundh : > (just a heads up, not sure if SF was able to send > out the notifications) > > This patch suggests changing /usr/local/bin/python to > /usr/bin/env python in cgi.py and faqwiz.py. Note > that both scripts are CGI scripts, and the FAQ has the > following to say about that: > > http://www.python.org/doc/FAQ.html#4.63 > > Note -- *don't* do this for CGI scripts. The $PATH > variable for CGI scripts is often very minimal, so > you need to use the actual absolute pathname of > the interpreter. > > -1, in other words (assuming that the FAQ is correct) I agree (now). I had submitted a similar patch at the beginning of this year, since such a patch is also part of the diff files usually applied on the major Linux distributions in order to build the Python binary RPMs on these Systems (SuSE Linux, RedHat). But I was conviced, that patching the official source tree would be a bad idea, since this will break these CGI scripts on most traditional Unices (e.g. Slowlaris), where people are unfortunately normally forced to build Python on their own and might forget (or are not allowed) to add /usr/local/bin to the default path. Since all major Linux distributions however come with a properly patched Python package anyway. Python living in /usr/bin on all those boxes is no argument. I believe applying such a patch has to wait until the proposed "world domination" of Linux has become real. ;-) So ---at least today--- the FAQ entry is ---still--- somewhat correct. However may be someone could add a note about prebuild Python RPMs to FAQ 4.63 in the mean time? I believe that otherwise Linux people will keep submitting patches like this one with increasing frequency. At least our customers throw out their Sun Sparc and SGI boxes and replace them with cheap Athlon or PIII boxes running SuSE or RedHat Linux with increasing velocity. Especially those in China, Singapur and Brasil. So in our customer base, Solaris and IRIX is dying out faster than I myself as a strong Linux proposer had believed even at the beginning of this year. YMMV since we are only a small company in a very special market segment. Regards, Peter From mal at lemburg.com Tue Jul 4 13:05:34 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 13:05:34 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> <3960BC32.CBBF3D6D@prescod.net> <3960C138.85D9B36A@lemburg.com> <00d201bfe510$573fce20$f2a6b5d4@hagrid> <3960DDA2.3C608267@prescod.net> Message-ID: <3961C4FE.D71A81B8@lemburg.com> Paul Prescod wrote: > > Fredrik Lundh wrote: > > > > ... > > > > exactly. this is the whole point: __repr__ is a debug tool, > > and therefore it must work in all platforms, for all strings. > > As a debugging tool, it would probably help rather than hurt things to > have repr be consistent on all platforms. If it is going to do a > conversion, I vote for unicode-escape everywhere. Ok, if you provide documentation for this, I'll give in on __repr__. In any case, __str__ should use the default encoding. > > on the other hand, if we can change repr/str, this is a non- > > issue. maybe someone could tell me exactly what code we'll > > break if we do that change? > > I agree that we want to move to a world where unicode strings and 8-bit > strings are accepted equally throughout Python. We do need some > information about whether moving there quickly will break code or not. > We need to know what Idle, PythonWin, Zope and other such environments > do with the results of repr. Anybody care to test this ? I think we should be careful about letting Unicode objects go loose in environments which were not designed to work with them. Let's first start with polishing up the standard lib to work with Unicode. It currently fails badly... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Tue Jul 4 13:07:53 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 13:07:53 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> Message-ID: <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> mal wrote: > Ok, so how about adding > > #define _XOPEN_SOURCE > > to Python.h ? digging through my old notes, it should be: /* force susv2 compatibility, where available */ #define _XOPEN_SOURCE 500 IIRC, Guido agreed that this was a good idea, so what are we waiting for? If it doesn't break the build on your Linux box, just go ahead and check it in! From mal at lemburg.com Tue Jul 4 13:10:42 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 13:10:42 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> Message-ID: <3961C632.CFADDC65@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > Ok, so how about adding > > > > #define _XOPEN_SOURCE > > > > to Python.h ? > > digging through my old notes, it should be: > > /* force susv2 compatibility, where available */ > #define _XOPEN_SOURCE 500 > > IIRC, Guido agreed that this was a good idea, so what > are we waiting for? If it doesn't break the build on your > Linux box, just go ahead and check it in! Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Jul 4 13:49:03 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 13:49:03 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> <3961C632.CFADDC65@lemburg.com> Message-ID: <3961CF2F.113EC4F7@lemburg.com> "M.-A. Lemburg" wrote: > > Fredrik Lundh wrote: > > > > mal wrote: > > > > > Ok, so how about adding > > > > > > #define _XOPEN_SOURCE > > > > > > to Python.h ? > > > > digging through my old notes, it should be: > > > > /* force susv2 compatibility, where available */ > > #define _XOPEN_SOURCE 500 > > > > IIRC, Guido agreed that this was a good idea, so what > > are we waiting for? If it doesn't break the build on your > > Linux box, just go ahead and check it in! > > Ok. Hmm, with "#define _XOPEN_SOURCE 500" I get these (new) errors: ./posixmodule.c: In function `posix_tmpnam': ./posixmodule.c:3494: warning: assignment makes pointer from integer without a cast ./signalmodule.c:83: `SIGMAX' undeclared here (not in a function) ./signalmodule.c:83: size of array `Handlers' has non-integer type Both errors can only be fixed using __USE_MISC: __USE_MISC Define things common to BSD and System V Unix. It is defined when either _BSD_SOURCE or _SVID_SOURCE is defined... question is: which to use ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping at lfw.org Tue Jul 4 14:05:38 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Tue, 4 Jul 2000 05:05:38 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: Message-ID: On Mon, 3 Jul 2000, Ka-Ping Yee wrote: > It doesn't even have to be its own class of error, i suppose, > as long as it gets indicated some way ("SyntaxError: invalid > indentation" would be fine). It turns out that this should be quite easy. If it weren't past 4am i would be posting a patch instead of just a verbal suggestion right now -- but here's how to do it. For this kind of thing: > >>> if 1: > ... 3 > ... 4 > inconsistent dedent > File "", line 3 > 4 > ^ > SyntaxError: invalid token ...clearly it's trivial, as the case is already marked in the code (tokenizer.c). Instead of dumping the "inconsistent dedent" message to stderr, return E_INDENT. For this situation: > >>> 3 > File "", line 1 > 3 > ^ > SyntaxError: invalid syntax ...we have an INDENT where none is expected. This is also easy. At the end of PyParser_AddToken, we simply check to see if the token that caused the problem was indent-related: if (type == INDENT || type == DEDENT) return E_INDENT; Finally, the most interesting case: > >>> if 1: > ... 3 > File "", line 2 > 3 > ^ > SyntaxError: invalid syntax ...we expected an INDENT and didn't get one. This is a matter of checking the accelerator table to see what we were expecting. Also not really that hard: int expected; /* at the top of PyParser_AddToken */ ... if (s->s_lower == s->s_upper - 1) /* only one possibility */ { expected = ps->p_grammar->g_ll.ll_label[s->s_lower].lb_type; if (expected == INDENT || expected == DEDENT) return E_INDENT; } I like this last case best, as it means we can produce more useful messages for a variety of syntax errors! When there is a single particular kind of token expected, now Python can tell you what it is. After inserting this: /* Stuck, report syntax error */ fprintf(stderr, "Syntax error: unexpected %s", _PyParser_TokenNames[type]); if (s->s_lower == s->s_upper - 1) { fprintf(stderr, " (wanted %s)", _PyParser_TokenNames[labels[s->s_lower].lb_type]); } fprintf(stderr, "\n"); ... i played around a bit: >>> (3,4] Syntax error: unexpected RSQB (wanted RPAR) File "", line 1 (3,4] ^ SyntaxError: invalid syntax >>> 3.. Syntax error: unexpected NEWLINE (wanted NAME) File "", line 1 3.. ^ SyntaxError: invalid syntax >>> 3.) Syntax error: unexpected RPAR File "", line 1 3.) ^ SyntaxError: invalid syntax >>> a^^ Syntax error: unexpected CIRCUMFLEX File "", line 1 a^^ ^ SyntaxError: invalid syntax >>> if 3: ... 3 Syntax error: unexpected NUMBER (wanted INDENT) File "", line 2 3 ^ SyntaxError: invalid syntax >>> 4,, Syntax error: unexpected COMMA File "", line 1 4,, ^ SyntaxError: invalid syntax >>> [3,) Syntax error: unexpected RPAR (wanted RSQB) File "", line 1 [3,) ^ SyntaxError: invalid syntax >>> if a == 3 and Syntax error: unexpected NEWLINE File "", line 1 if a == 3 and ^ SyntaxError: invalid syntax >>> if a = 3: Syntax error: unexpected EQUAL (wanted COLON) File "", line 1 if a = 3: ^ SyntaxError: invalid syntax This isn't going to cover all cases, but i thought it was pretty cool. So, in summary: - Producing E_INDENT errors is easy, and should require just three small changes (one in tokenizer.c and two in parser.c, specifically PyParser_AddToken) - We can get some info we need to produce better syntax error messages in general, but this requires a little more thought about how to pass the info back out of the parser to pythonrun.c (err_input). -- ?!ng "This code is better ihan any code that doesn't work has any right to be." -- Roger Gregory, on Xanadu From fredrik at pythonware.com Tue Jul 4 14:40:09 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 14:40:09 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> <3961C632.CFADDC65@lemburg.com> <3961CF2F.113EC4F7@lemburg.com> Message-ID: <002a01bfe5b4$fdeb1820$0900a8c0@SPIFF> mal wrote: > Hmm, with "#define _XOPEN_SOURCE 500" I get these (new) errors: > > ./posixmodule.c: In function `posix_tmpnam': > ./posixmodule.c:3494: warning: assignment makes pointer from integer without a cast looks like a bug in the header files; SUSv2 says that this should be defined in stdio.h... > ./signalmodule.c:83: `SIGMAX' undeclared here (not in a function) > ./signalmodule.c:83: size of array `Handlers' has non-integer type but this one is stranger; as far as I can tell, SIGMAX is not part of SUSv2 at all. and what's worse, I cannot find any suitable replacement. does it work better if you just define _XOPEN_SOURCE, without any specific value? or maybe you should just add _GNU_SOURCE to make it work on your box. I promise to play with this on our Unix boxes, but not today... From mal at lemburg.com Tue Jul 4 16:03:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 16:03:37 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> <3961C632.CFADDC65@lemburg.com> <3961CF2F.113EC4F7@lemburg.com> <002a01bfe5b4$fdeb1820$0900a8c0@SPIFF> Message-ID: <3961EEB9.413FF4FF@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Hmm, with "#define _XOPEN_SOURCE 500" I get these (new) errors: > > > > ./posixmodule.c: In function `posix_tmpnam': > > ./posixmodule.c:3494: warning: assignment makes pointer from integer > without a cast > > looks like a bug in the header files; SUSv2 says that > this should be defined in stdio.h... The header files on my machine only define tmpnam_r in case __USE_MISC is true. The latter is defined for either BSD or SysV compatibility, yet not by _XOPEN_SOURCE. > > ./signalmodule.c:83: `SIGMAX' undeclared here (not in a function) > > ./signalmodule.c:83: size of array `Handlers' has non-integer type > > but this one is stranger; as far as I can tell, SIGMAX is not > part of SUSv2 at all. and what's worse, I cannot find any > suitable replacement. I guess we should patch signalmodule.c to fall back to _NSIG instead of trying SIGMAX. I'll check in a fix later today. > does it work better if you just define _XOPEN_SOURCE, without any > specific value? Same errors. > or maybe you should just add _GNU_SOURCE to make > it work on your box. I promise to play with this on our Unix boxes, > but not today... Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at cnri.reston.va.us Tue Jul 4 16:13:47 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 4 Jul 2000 10:13:47 -0400 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <3961B221.4F7552C3@lemburg.com>; from mal@lemburg.com on Tue, Jul 04, 2000 at 11:45:05AM +0200 References: <3961B221.4F7552C3@lemburg.com> Message-ID: <20000704101347.A14382@newcnri.cnri.reston.va.us> On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: >#ifdef __GNUC__ ># define _GNU_SOURCE >#endif Doesn't it make more sense to define _GNU_SOURCE only if the C library is glibc? You could be using GCC on Solaris with Sun's libc, for example, where _GNU_SOURCE would be meaningless. Probably you have to define _XOPEN_SOURCE everywhere, and _GNU_SOURCE if the libc is glibc. --amk From fredrik at pythonware.com Tue Jul 4 16:22:34 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 16:22:34 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> <3961C632.CFADDC65@lemburg.com> <3961CF2F.113EC4F7@lemburg.com> <002a01bfe5b4$fdeb1820$0900a8c0@SPIFF> <3961EEB9.413FF4FF@lemburg.com> Message-ID: <002a01bfe5c3$4c5ed510$0900a8c0@SPIFF> mal wrote: > > looks like a bug in the header files; SUSv2 says that > > this should be defined in stdio.h... > > The header files on my machine only define tmpnam_r in > case __USE_MISC is true. The latter is defined for either > BSD or SysV compatibility, yet not by _XOPEN_SOURCE. oh, sorry. looks like I was off by two here, and thought you were talking about tmpnam. fwiw, SUSv2 seems to say that tmpnam is thread safe, if used in the right way. there is no tmpnam_r in SUSv2. I'll dig into this later (maybe they've added things in SUSv3). > > > ./signalmodule.c:83: `SIGMAX' undeclared here (not in a function) > > > ./signalmodule.c:83: size of array `Handlers' has non-integer type > > > > but this one is stranger; as far as I can tell, SIGMAX is not > > part of SUSv2 at all. and what's worse, I cannot find any > > suitable replacement. > > I guess we should patch signalmodule.c to fall back to _NSIG > instead of trying SIGMAX. sounds reasonable (or rather, I haven't got a clue, so I'll have to trust you on this one ;-) cheers /F From mal at lemburg.com Tue Jul 4 16:22:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 16:22:50 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <20000704101347.A14382@newcnri.cnri.reston.va.us> Message-ID: <3961F33A.28E2B980@lemburg.com> Andrew Kuchling wrote: > > On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: > >#ifdef __GNUC__ > ># define _GNU_SOURCE > >#endif > > Doesn't it make more sense to define _GNU_SOURCE only if the C library > is glibc? You could be using GCC on Solaris with Sun's libc, for > example, where _GNU_SOURCE would be meaningless. Probably you have to > define _XOPEN_SOURCE everywhere, and _GNU_SOURCE if the libc is glibc. Good point... it should probably read: #ifdef __GLIBC__ # define _GNU_SOURCE #else # define _XOPEN_SOURCE 500 #endif I'll do some more testing later today. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Tue Jul 4 19:32:41 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 13:32:41 -0400 (EDT) Subject: [Python-Dev] Making -tt the default In-Reply-To: References: Message-ID: <14690.8121.869315.508174@cj42289-a.reston1.va.home.com> Tim Peters writes: > It occurs to me that I had Emacs set up (in my own .emacs) to never ever use > literal tab characters. That may go a way in explaining why pymode never > generated ambiguous indentation for me! I have: (setq-default indent-tabs-mode nil) Perhaps python-mode should include (setq indent-tabs-mode nil) just for python-mode buffers, if it doesn't already. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Jul 4 19:40:56 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 13:40:56 -0400 (EDT) Subject: [Python-Dev] Re: [ Patch #100719 ] Use '#!/usr/bin/env python' in scripts In-Reply-To: <010101bfe598$d88381b0$0900a8c0@SPIFF> References: <20000703233938.N29590@lyra.org> <010101bfe598$d88381b0$0900a8c0@SPIFF> Message-ID: <14690.8616.285301.679626@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > This patch suggests changing /usr/local/bin/python to > /usr/bin/env python in cgi.py and faqwiz.py. Note > that both scripts are CGI scripts, and the FAQ has the > following to say about that: > > http://www.python.org/doc/FAQ.html#4.63 > > Note -- *don't* do this for CGI scripts. The $PATH > variable for CGI scripts is often very minimal, so > you need to use the actual absolute pathname of > the interpreter. > > -1, in other words (assuming that the FAQ is correct) The FAQ is correct. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Tue Jul 4 19:45:17 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 19:45:17 +0200 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... Message-ID: <396222AD.8312C32@lemburg.com> While fiddling around with the _GNU_SOURCE define I found that there are several warnings left in the current CVS version which should be removed, I guess. Here's the list I get from compiling the tree using -Wall grouped by C file: bufferobject.c: In function `PyBuffer_New': bufferobject.c:174: warning: value computed is not used classobject.c: In function `instance_dealloc': classobject.c:526: warning: unused variable `_Py_RefTotal' object.c: In function `_PyTrash_deposit_object': object.c:1172: warning: unused variable `hold' object.c:1171: warning: `typecode' might be used uninitialized in this function ceval.c: In function `eval_code2': ceval.c:333: warning: `opcode' might be used uninitialized in this function ceval.c:334: warning: `oparg' might be used uninitialized in this function pystate.c: In function `PyInterpreterState_New': pystate.c:45: warning: value computed is not used ./gcmodule.c: In function `debug_cycle': ./gcmodule.c:295: warning: unsigned int format, long unsigned int arg (arg 5) ./gcmodule.c: In function `collect': ./gcmodule.c:374: warning: int format, long int arg (arg 3) ./gcmodule.c:374: warning: int format, long int arg (arg 4) ./gcmodule.c:374: warning: int format, long int arg (arg 5) ./gcmodule.c:438: warning: int format, long int arg (arg 3) ./gcmodule.c:438: warning: int format, long int arg (arg 4) ./gcmodule.c: In function `collect_generations': ./gcmodule.c:458: warning: `n' might be used uninitialized in this function ./pypcre.c: In function `compile_branch': ./pypcre.c:1222: warning: `c' might be used uninitialized in this function ./pypcre.c: In function `pcre_exec': ./pypcre.c:4524: warning: variable `start_bits' might be clobbered by `longjmp' or `vfork' ./pypcre.c:4525: warning: variable `start_match' might be clobbered by `longjmp' or `vfork' ./posixmodule.c: At top level: ./posixmodule.c:496: warning: `posix_strint' defined but not used _sre.c: In function `pattern_match': _sre.c:819: warning: `mark1' might be used uninitialized in this function _sre.c:819: warning: `mark0' might be used uninitialized in this function ./_sre.c:819: warning: `mark1' might be used uninitialized in this function ./_sre.c:819: warning: `mark0' might be used uninitialized in this function _sre.c: In function `pattern_search': _sre.c:985: warning: `prefix_len' might be used uninitialized in this function _sre.c:819: warning: `mark0' might be used uninitialized in this function [...many more of these... all referencing line 819] In file included from ./mmapmodule.c:24: ../Include/Python.h:18: warning: `_GNU_SOURCE' redefined ./mmapmodule.c:21: warning: this is the location of the previous definition [...looks like someone needed _GNU_SOURCE too ;-)...] ./parsermodule.c: In function `validate_arglist': ./parsermodule.c:2089: warning: `ok' might be used uninitialized in this function -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Jul 4 19:48:35 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 19:48:35 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <20000704101347.A14382@newcnri.cnri.reston.va.us> <3961F33A.28E2B980@lemburg.com> Message-ID: <39622373.7C65C72C@lemburg.com> "M.-A. Lemburg" wrote: > > Andrew Kuchling wrote: > > > > On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: > > >#ifdef __GNUC__ > > ># define _GNU_SOURCE > > >#endif > > > > Doesn't it make more sense to define _GNU_SOURCE only if the C library > > is glibc? You could be using GCC on Solaris with Sun's libc, for > > example, where _GNU_SOURCE would be meaningless. Probably you have to > > define _XOPEN_SOURCE everywhere, and _GNU_SOURCE if the libc is glibc. > > Good point... it should probably read: > > #ifdef __GLIBC__ > # define _GNU_SOURCE > #else > # define _XOPEN_SOURCE 500 > #endif > > I'll do some more testing later today. The testing showed that the above switch doesn't work: __GLIBC__ is defined in features.h which is included by all standard C lib headers in glibc. The following finally made the warnings in timemodule.c go away: /* Enable compiler features including SUSv2 compatibility; switching on C lib defines doesn't work here, because the symbols haven't necessarily been defined yet. */ #define _GNU_SOURCE 1 #define _XOPEN_SOURCE 500 Defining _GNU_SOURCE on non glibc platforms shouldn't hurt, so I simply dropped the switch. Should I check this in ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Tue Jul 4 19:53:15 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 13:53:15 -0400 (EDT) Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <018a01bfe59f$da814950$0900a8c0@SPIFF> References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> Message-ID: <14690.9355.219446.754205@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > what does "fixes warnings" mean? does it change the compiler's > behaviour, or does it just make sure stuff are defined in the right > files? There's a strptime() declaration about halfway down the file in an #if 0 section; this has to be enabled on Linux to get rid of a warning. Defining _GNU_SOURCE at the top of the file also gets rid of the warning, but defining _XOPEN_SOURCE doesn't; in that case I get more: gcc -fpic -g -O2 -I../../Modules/../Include -I.. -DHAVE_CONFIG_H -c ../../Modules/timemodule.c ../../Modules/timemodule.c: In function `inittime': ../../Modules/timemodule.c:652: structure has no member named `tm_gmtoff' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:657: structure has no member named `tm_gmtoff' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' make[1]: *** [timemodule.o] Error 1 make: *** [sharedmods] Error 2 > how is this different from just a plain (and truly portable) > #define _XOPEN_SOURCE? A valid concern, but most of _GNU_SOURCE is just shorthand to make sure just about every non-conflicting declaration is made, so that differences between other platforms "standard" declarations aren't as much of a problem. But I'm not advocating it for general use; the sources are already working well aside from this one warning in timemodule.c; defining _GNU_SOURCE here is sufficient as far as I can tell. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From DavidA at ActiveState.com Tue Jul 4 19:59:25 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 4 Jul 2000 10:59:25 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14690.8121.869315.508174@cj42289-a.reston1.va.home.com> Message-ID: > Tim Peters writes: > > It occurs to me that I had Emacs set up (in my own .emacs) to > never ever use > > literal tab characters. That may go a way in explaining why > pymode never > > generated ambiguous indentation for me! > > I have: > > (setq-default indent-tabs-mode nil) > > Perhaps python-mode should include > > (setq indent-tabs-mode nil) > > just for python-mode buffers, if it doesn't already. +1 --david From fdrake at beopen.com Tue Jul 4 20:25:28 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 14:25:28 -0400 (EDT) Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <39622373.7C65C72C@lemburg.com> References: <3961B221.4F7552C3@lemburg.com> <20000704101347.A14382@newcnri.cnri.reston.va.us> <3961F33A.28E2B980@lemburg.com> <39622373.7C65C72C@lemburg.com> Message-ID: <14690.11288.36303.553802@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > /* Enable compiler features including SUSv2 compatibility; switching > on C lib defines doesn't work here, because the symbols haven't > necessarily been defined yet. */ > #define _GNU_SOURCE 1 > #define _XOPEN_SOURCE 500 ... > Should I check this in ? This works for me; I presume you putting this before all other #includes? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Jul 4 20:43:47 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 14:43:47 -0400 (EDT) Subject: [Python-Dev] Making -tt the default In-Reply-To: References: <14690.8121.869315.508174@cj42289-a.reston1.va.home.com> Message-ID: <14690.12387.705074.991760@cj42289-a.reston1.va.home.com> David Ascher writes: > +1 I've submitted patch #100729 on SourceForge and assigned it to Barry. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Jul 4 20:50:57 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 14:50:57 -0400 (EDT) Subject: [Python-Dev] Making the CVS tree pass the -Wall test... In-Reply-To: <396222AD.8312C32@lemburg.com> References: <396222AD.8312C32@lemburg.com> Message-ID: <14690.12817.194151.569623@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Here's the list I get from compiling the tree using -Wall > grouped by C file: Feel free to fix these! (I agree they should be done, but I need to pull away from email and these little proto-buglets so I can actually get done some of the things on my list. ;) > ./parsermodule.c: In function `validate_arglist': > ./parsermodule.c:2089: warning: `ok' might be used uninitialized in this function Ok, I've fixed this one, since it's probably my fault. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Tue Jul 4 21:00:38 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 21:00:38 +0200 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... References: <396222AD.8312C32@lemburg.com> <14690.12817.194151.569623@cj42289-a.reston1.va.home.com> Message-ID: <39623456.E8B0B833@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > Here's the list I get from compiling the tree using -Wall > > grouped by C file: > > Feel free to fix these! (I agree they should be done, but I need to > pull away from email and these little proto-buglets so I can actually > get done some of the things on my list. ;) Same here ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Jul 4 21:05:01 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 21:05:01 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <20000704101347.A14382@newcnri.cnri.reston.va.us> <3961F33A.28E2B980@lemburg.com> <39622373.7C65C72C@lemburg.com> <14690.11288.36303.553802@cj42289-a.reston1.va.home.com> Message-ID: <3962355D.7FD7429@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > /* Enable compiler features including SUSv2 compatibility; switching > > on C lib defines doesn't work here, because the symbols haven't > > necessarily been defined yet. */ > > #define _GNU_SOURCE 1 > > #define _XOPEN_SOURCE 500 > ... > > Should I check this in ? > > This works for me; I presume you putting this before all other > #includes? Right. I've added some ifdefs just to make sure. This is how my Python.h file looks now: ... See the file "Misc/COPYRIGHT" for information on usage and redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES. ******************************************************************/ /* Enable compiler features including SUSv2 compatibility; switching on C lib defines doesn't work here, because the symbols haven't necessarily been defined yet. */ #ifndef _GNU_SOURCE # define _GNU_SOURCE 1 #endif #ifndef _XOPEN_SOURCE # define _XOPEN_SOURCE 500 #endif /* Include nearly all Python header files */ #include "patchlevel.h" #include "config.h" ... Other opinions ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Jul 4 22:58:46 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 22:58:46 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <20000704200730.617431D0CE@dinsdale.python.org> Message-ID: <39625006.A0F7B0C0@lemburg.com> billtut at microsoft.com wrote: > > Full_Name: Bill Tutt > Version: CVS > OS: NT > Submission from: tide70.microsoft.com (131.107.3.70) > > u'\ud800' causes the interpreter to crash > example: > print u'\ud800' > What happens: > The code failes to compile because while adding the constant, the unicode_hash > function is called which for some reason requires the UTF-8 string format. The reasoning at the time was that dictionaries should accept Unicode objects as keys which match their string equivalents as the same key, e.g. 'abc' works just as well as u'abc'. UTF-8 was the default encoding back then. I'm not sure how to fix the hash value given the new strategy w/r to the default encoding... According to the docs, objects comparing equal should have the same hash value, yet this would require the hash value to be calculated using the default encoding and that would not only cause huge performance problems, but could effectively render Unicode useless, because not all default encodings are lossless (ok, one could work around this by falling back to some other way of calculating the hash value in case the conversion fails). Looks like we have a problem here :-/ > The conversion to UTF-8 fails (completly bogus), the compiler only notes that > compilation failed, and cleared the stored exception info. > > When compilatino finishes it remembered that it failed, and returns. > The interpreter then proceeds to crash in PyErr_NormalizeException() because the > UTF-8 conversion exception info isn't there anymore. > > Suggested fix: > Changing the UTF-8 conversion code to emit 4 bytes for surrogate characters. > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list at python.org > http://www.python.org/mailman/listinfo/python-bugs-list -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping at lfw.org Tue Jul 4 23:40:21 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Tue, 4 Jul 2000 14:40:21 -0700 (PDT) Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) In-Reply-To: <39625006.A0F7B0C0@lemburg.com> Message-ID: On Tue, 4 Jul 2000, M.-A. Lemburg wrote: > > The reasoning at the time was that dictionaries should accept > Unicode objects as keys which match their string equivalents > as the same key, e.g. 'abc' works just as well as u'abc'. [...] > According to the docs, objects comparing equal should have the > same hash value, yet this would require the hash value to be > calculated using the default encoding and that > would not only cause huge performance problems, but could > effectively render Unicode useless, Given the new 7-bit-ASCII-as-default-encoding-for-8-bit-strings convention, shouldn't just hashing the character values work fine? That is, hash('abc') should == hash(u'abc'), no conversion required. -- ?!ng From jack at oratrix.nl Tue Jul 4 23:50:02 2000 From: jack at oratrix.nl (Jack Jansen) Date: Tue, 04 Jul 2000 23:50:02 +0200 Subject: [Python-Dev] PyArg_ParseTuple and 16 bit bitpatterns Message-ID: <20000704215007.957B2E2673@oratrix.oratrix.nl> I've adapted PyArg_ParseTuple (and Py_BuildValue) to understand the H format specifier, which is meant for 16-bit bitpatterns. (in case you didn't follow the discussion last month: the old lowercase h now checks values to be in the range -32768..32767, so constants like 0x8000 are not acceptable anymore). I haven't added an I and L specifier, because (surprise, surprise:-) for 32-bit integers 0x80000000 turns out to be a legal value, unlike for their poor 16-bit brethren. I've currently implemented H as meaning unsigned (i.e. 0..0xffff), but on second thoughts I think allowing -32768..0xffff might be better: there's probably lots of code out there that passes -1 when all 16 flag bits should be set. Please let me know if you have strong opinions on either meaning before I check this in. Note that I'll only adapt PyArg_ParseTuple and the gazzilion mac-specific occurrences of "h" where a 16-bit pattern is needed. I've done only a very cursory check of other occurences of "h", but someone else will have to pick that up if they feel like. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From jack at oratrix.nl Tue Jul 4 23:53:36 2000 From: jack at oratrix.nl (Jack Jansen) Date: Tue, 04 Jul 2000 23:53:36 +0200 Subject: [Python-Dev] Sre tests failing Message-ID: <20000704215342.18235E2673@oratrix.oratrix.nl> Since this weekend lots of test.autotest tests fail on my Mac because sre seems to lack lots of stuff that re did have. And as /F has been rather quiet these last 24 hours: is this a problem only I have and i should investigate, or should I quietly wait for it to be fixed shortly? Failing tests include test_sre, test_xmllib, test_strftime and test_tokenize, to name a few. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From martin at loewis.home.cs.tu-berlin.de Wed Jul 5 00:12:03 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed, 5 Jul 2000 00:12:03 +0200 Subject: [Python-Dev] Copyright notice Message-ID: <200007042212.AAA01334@loewis.home.cs.tu-berlin.de> > I think I recall this was a convention that the GNU folks claim is > required from a legal standpoint. The GPL requires such a message, specifically 2c) c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) So if you modify gdb, you'll have to update the copyright notice it prints. Please note the exception: some programs (e.g. bash) don't "normally" print a message, so you don't have to add one. In any case, I believe this is just a GPL requirement - for Python, you could have it behave in any way you please. > On the other hand, why does it bother you? I don't bother too much, and I hadn't said anything if I didn't expect the message to change anyway. The interactive prompt of Python 2 will be shown on page 1 of the next print of my Python book, and I did not mean to go into Python's history until page 14 :-) Regards, Martin From billtut at microsoft.com Wed Jul 5 00:39:26 2000 From: billtut at microsoft.com (Bill Tutt) Date: Tue, 4 Jul 2000 15:39:26 -0700 Subject: [Python-Dev] RE: \ud800 crashes interpreter (PR#384) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD269@RED-MSG-50> > MAL wrotw: >> Bill wrote: >> u'\ud800' causes the interpreter to crash >> example: >> print u'\ud800' >> What happens: >> The code failes to compile because while adding the constant, the unicode_hash >> function is called which for some reason requires the UTF-8 string format. > The reasoning at the time was that dictionaries should accept > Unicode objects as keys which match their string equivalents > as the same key, e.g. 'abc' works just as well as u'abc'. > UTF-8 was the default encoding back then. I'm not sure how > to fix the hash value given the new strategy w/r to the > default encoding... > According to the docs, objects comparing equal should have the > same hash value, yet this would require the hash value to be > calculated using the default encoding and that > would not only cause huge performance problems, but could > effectively render Unicode useless, because not all default > encodings are lossless (ok, one could work around this by > falling back to some other way of calculating the hash > value in case the conversion fails). Yeah, yeah, yeah. I know all that, just never liked it. :) The current problem is that the UTF-8 can't round trip surrogate characters atm. This is easy to fix, so I'm doing a patch to fix this oversight, unless you beat me to it. Anything else is slightly more annoying to fix. Bill From effbot at telia.com Wed Jul 5 01:44:15 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 01:44:15 +0200 Subject: [Python-Dev] Sre tests failing References: <20000704215342.18235E2673@oratrix.oratrix.nl> Message-ID: <001e01bfe611$c60df820$f2a6b5d4@hagrid> > Since this weekend lots of test.autotest tests fail on my Mac because > sre seems to lack lots of stuff that re did have. And as /F has been > rather quiet these last 24 hours: is this a problem only I have and i > should investigate, or should I quietly wait for it to be fixed > shortly? > > Failing tests include test_sre, test_xmllib, test_strftime and > test_tokenize, to name a few. test_sre.py should work (if you compare the output against the output/test_sre file, that is -- see the repository copy of that file for a list of things that are expected to break...) I think test_tokenize should work too... test_xmllib appears to be broken on my box (possibly caused by SRE). test_strftime complains about tons of stuff on my Win95 box; dunno if it's done that way on purpose... From effbot at telia.com Wed Jul 5 01:46:07 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 01:46:07 +0200 Subject: [Python-Dev] SRE incompatibility References: <20000704095542.8697B31047C@bireme.oratrix.nl> Message-ID: <002601bfe612$06e90ec0$f2a6b5d4@hagrid> sjoerd wrote: > >>> re.match(regexp, 'smil').group(0,1,2,3) > ('smil', None, 's', 'smil') > >>> import pre > >>> pre.match(regexp, 'smil').group(0,1,2,3) > ('smil', None, None, 'smil') > > Needless to say, I am relying on the third value being None... I've confirmed this (last night's fix should have solved this, but it didn't). I'll post patches as soon as I have them... From trentm at activestate.com Wed Jul 5 01:42:58 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 4 Jul 2000 16:42:58 -0700 Subject: [Python-Dev] PyArg_ParseTuple and 16 bit bitpatterns In-Reply-To: <20000704215007.957B2E2673@oratrix.oratrix.nl> References: <20000704215007.957B2E2673@oratrix.oratrix.nl> Message-ID: <20000704164258.B5972@activestate.com> Hi Jack, I am your evil man for this one (but then you already knew that). On Tue, Jul 04, 2000 at 11:50:02PM +0200, Jack Jansen wrote: > I've adapted PyArg_ParseTuple (and Py_BuildValue) to understand the H > format specifier, which is meant for 16-bit bitpatterns. (in case you > didn't follow the discussion last month: the old lowercase h now > checks values to be in the range -32768..32767, so constants like > 0x8000 are not acceptable anymore). I think that the Right Answer is: b = signed byte B = unsigned byte h = signed short H = unsigned short i = signed int I = unsigned int l = signed long L = unsigned long Before my patch we had (no range checking was done so signed vs. unsigned made no difference): b = byte h = short i = int l = long L = LONG_LONG After my patch (i.e. now) we have: b = unsigned byte h = signed short i = signed int l = signed long L = signed LONG_LONG Notes on that: - Choosing signed or unsigned for each was based on the common case (or presuming what the common case was). I.e. unsigned bytes are more common than signed bytes. - unsigned byte is 'b' and not (my ideal) 'B', for backward compatibility reasons - LONG_LONG as 'L' really sucks because that is the blocker to PyArg_ParseTuple nirvana (my first list). It should be 'q' and 'Q' for Quad or something like that. Your patch is adding (right?): H = unsigned short Aside: Now that it will be called 2.0 would we maybe want to go for the Right Answer. I suspect that a *lot* more people would complain of breakage with the use of 'L' changing to 'Q', and that I am asking for a lynching. > > I haven't added an I and L specifier, because (surprise, surprise:-) > for 32-bit integers 0x80000000 turns out to be a legal value, unlike > for their poor 16-bit brethren. I can't see how 'I' allows 0x80000000 (unless, of course, sizeof(int) > 4 on your machine) because the 'I' formatter is not in PyArg_ParseTuple. Yes, 'L' will probably accept 0x80000000 because LONG_LONG is probably 64-bits wide on your machine hence. > > I've currently implemented H as meaning unsigned (i.e. 0..0xffff), but I woudl suggest allowing [0, USHRT_MAX]. Should be defined in limits.h (guessing), I think. > on second thoughts I think allowing -32768..0xffff might be better: > there's probably lots of code out there that passes -1 when all 16 > flag bits should be set. Please let me know if you have strong I think that uses of -1 should use either USHRT_MAX or (unsigned short)-1. > opinions on either meaning before I check this in. > > Note that I'll only adapt PyArg_ParseTuple and the > gazzilion mac-specific occurrences of "h" where a 16-bit pattern is > needed. I've done only a very cursory check of other occurences of > "h", but someone else will have to pick that up if they feel like. > I am sorry to have been the cause of work for you. I just think that the 'security' offered by bounds checking all values converted by PyArg_ParseTuple is important. Trent -- Trent Mick trentm at activestate.com From tim_one at email.msn.com Wed Jul 5 07:51:07 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 01:51:07 -0400 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... In-Reply-To: <396222AD.8312C32@lemburg.com> Message-ID: [M.-A. Lemburg] > While fiddling around with the _GNU_SOURCE define I found > that there are several warnings left in the current CVS > version which should be removed, I guess. > > Here's the list I get from compiling the tree using -Wall > grouped by C file: So long as any warnings remain, would you please repost the list from time to time? There's no need to group them by file. > ./pypcre.c:4524: warning: variable `start_bits' might be > clobbered by `longjmp' or `vfork' > ./pypcre.c:4525: warning: variable `start_match' might be > clobbered by `longjmp' or `vfork' These are often a PITA to fix: gcc does brain-dead flow analysis, and this particular msg is almost always bogus as a result. There are several open bugs filed against gcc on this (I know because one of them is mine ). The others look straightforward to fix (on a first scan). From martin at loewis.home.cs.tu-berlin.de Wed Jul 5 08:50:54 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed, 5 Jul 2000 08:50:54 +0200 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... Message-ID: <200007050650.IAA00972@loewis.home.cs.tu-berlin.de> >> ./pypcre.c:4524: warning: variable `start_bits' might be >> clobbered by `longjmp' or `vfork' >> ./pypcre.c:4525: warning: variable `start_match' might be >> clobbered by `longjmp' or `vfork' > These are often a PITA to fix: gcc does brain-dead flow analysis, and this > particular msg is almost always bogus as a result. There are several open > bugs filed against gcc on this (I know because one of them is mine ). > The others look straightforward to fix (on a first scan). At least for start_match, what exactly is bogus about this message? setjmp is invoked in line 4691 of pypcre, and start_match is modified in line 4737, at the end of the while loop containing the setjmp call. If somebody would invoke longjmp on the jmp_buf after start_match is modified, it would have an indeterminate value, according to 7.13.2.1p3 of C99. Likewise for start_bits, as it may also be modified after setjmp() has been called, since it appears in the same loop. I admit that there wouldn't be too many calls that could actually invoke longjmp() before the next invocation of setjmp, except perhaps for pchars(), but gcc is not supposed to determine potential callers of longjmp: The compiler sees only the calls to `setjmp'. It cannot know where `longjmp' will be called; in fact, a signal handler could call it at any point in the code. As a result, you may get a warning even when there is in fact no problem because `longjmp' cannot in fact be called at the place which would cause a problem. So while I'd admit that gcc "does brain-dead flow analysis", I think this particular msg is not bogus in this specific case. It's more often than not that gcc users fail to understand this message, though. Regards, Martin From rob at hooft.net Wed Jul 5 09:02:53 2000 From: rob at hooft.net (Rob W. W. Hooft) Date: Wed, 5 Jul 2000 09:02:53 +0200 (CEST) Subject: [Python-Dev] Spelling check: more typos Message-ID: <14690.56733.627266.907044@temoleh.chem.uu.nl> I got some positive comments on my previous load of spelling checks, so I spent another evening using some ispell, some spell, and some special python code to look for more spelling errors in the python source code. Base was the CVS on 2 July. There are a few more 'problematic' cases in here: First: American vs. British spelling. Since most text is in American spelling, I "corrected" some words from the British spelling to the American. I haven't done that with everything, especially in modules where British-spelling variable names are used. Then 2 points on distutils: - the word "licence" is used throughout, and "license" is introduced as alternative. The other way around looks more natural to me. - the term "anal retentives" should probably be replaced before 2.0 Furthermore: there is still a lib/stdwin manual. Shouldn't that be removed too? Is "s's" as in "the process's exit code" valid English? I seem to remember that for words in s, the final s should be dropped. Is it "Lance Ellinghouse" or "Ellinghaus"? I uploaded my patch to the patch manager (as unidiff, sorry, but it is large enough in the current form, and for spelling corrections easy enough to follow). Rob Hooft -- ===== rob at hooft.net http://www.hooft.net/people/rob/ ===== ===== R&D, Nonius BV, Delft http://www.nonius.nl/ ===== ===== PGPid 0xFA19277D ========================== Use Linux! ========= From gstein at lyra.org Wed Jul 5 09:52:09 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 5 Jul 2000 00:52:09 -0700 Subject: [Python-Dev] Re: [Patches] Patch 100718 -- LinuxThreads vs. Pth In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jul 05, 2000 at 09:38:13AM +0300 References: Message-ID: <20000705005209.J29590@lyra.org> On Wed, Jul 05, 2000 at 09:38:13AM +0300, Moshe Zadka wrote: > > I'm +1 on this -- LinuxThreads is more-or-less Posix compliant, and is > based on Kernel level support. It seems much closer to the norm in the > Linux world then Pth. This patch is a huge +1. We should *never* prefer Pth over LinuxThreads. Never. Ever. Hell... there isn't really "LinuxThreads" any more -- it is part of glibc. We really shouldn't take an external package over the core C library. Pth is a user-mode thread package. That should not be used by Python unless somebody specifically requests it. Gah. How did that Pth get preferred installation... I'm off to fix this sucker. Big time. There is a separate problem for how somebody can override the selection mechanism. But we're talking defaults here, and we should select the proper default. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Wed Jul 5 09:55:55 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 09:55:55 +0200 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... References: Message-ID: <3962EA0B.2EBED7A8@lemburg.com> Tim Peters wrote: > > [M.-A. Lemburg] > > While fiddling around with the _GNU_SOURCE define I found > > that there are several warnings left in the current CVS > > version which should be removed, I guess. > > > > Here's the list I get from compiling the tree using -Wall > > grouped by C file: > > So long as any warnings remain, would you please repost the list from time > to time? There's no need to group them by file. Ok. Note that the idea behind posting the list was to make module authors/editors aware of warnings in their code... Fred already made his changes -- it would probably be a good idea if the others did the same. > > ./pypcre.c:4524: warning: variable `start_bits' might be > > clobbered by `longjmp' or `vfork' > > ./pypcre.c:4525: warning: variable `start_match' might be > > clobbered by `longjmp' or `vfork' > > These are often a PITA to fix: gcc does brain-dead flow analysis, and this > particular msg is almost always bogus as a result. There are several open > bugs filed against gcc on this (I know because one of them is mine ). > The others look straightforward to fix (on a first scan). That one has been in Python since pcre was adopted -- I don't think there's much we can do about it either... but then: sre is coming on strong so we might as well drop pcre for say 2.1. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Wed Jul 5 10:06:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 5 Jul 2000 11:06:06 +0300 (IDT) Subject: [Python-Dev] SF Beuracracy again Message-ID: Is there a difference between what SF calls "developers" and what we informally call "poeple with commit access"? Can anyone clear the stati people can have with regard to the Python project? (I've just revived my account on SF because of Python...) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From tim_one at email.msn.com Wed Jul 5 10:14:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 04:14:22 -0400 Subject: [Python-Dev] RE: [Patches] Patch 100718 -- LinuxThreads vs. Pth In-Reply-To: Message-ID: [moved from patches to python-dev] [Moshe] > (Question to PythonLabs team: any hope of getting the patch contents in > e-mail? It's much easier to comment that way) Seems really a question for SourceForge at this point. If we could have, we would have by now. From mal at lemburg.com Wed Jul 5 10:34:27 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 10:34:27 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: Message-ID: <3962F313.186B10FB@lemburg.com> Ka-Ping Yee wrote: > > On Tue, 4 Jul 2000, M.-A. Lemburg wrote: > > > > The reasoning at the time was that dictionaries should accept > > Unicode objects as keys which match their string equivalents > > as the same key, e.g. 'abc' works just as well as u'abc'. > [...] > > According to the docs, objects comparing equal should have the > > same hash value, yet this would require the hash value to be > > calculated using the default encoding and that > > would not only cause huge performance problems, but could > > effectively render Unicode useless, > > Given the new 7-bit-ASCII-as-default-encoding-for-8-bit-strings > convention, shouldn't just hashing the character values work > fine? That is, hash('abc') should == hash(u'abc'), no conversion > required. Yes, and it does so already for pure ASCII values. The problem comes from the fact that the default encoding can be changed to a locale specific value (site.py does the lookup for you), e.g. given you have defined LANG to be us_en, Python will default to Latin-1 as default encoding. This results in '???' == u'???', but hash('???') != hash(u'???'), which is in conflict with the general rule about objects having the same hash value if they compare equal. Now, I could go and change the internal cache buffer to hold the default encoding instead of UTF-8, but this would affect not only hash(), but also the 's' and 't' parser markers, etc. ... I wonder why compiling "print u'\uD800'" causes the hash value to be computed ... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jul 5 10:37:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 10:37:23 +0200 Subject: [Python-Dev] RE: \ud800 crashes interpreter (PR#384) References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD269@RED-MSG-50> Message-ID: <3962F3C3.74A7825D@lemburg.com> Bill Tutt wrote: > > > MAL wrotw: > >> Bill wrote: > >> u'\ud800' causes the interpreter to crash > >> example: > >> print u'\ud800' > >> What happens: > >> The code failes to compile because while adding the constant, the > unicode_hash > >> function is called which for some reason requires the UTF-8 string > format. > > > The reasoning at the time was that dictionaries should accept > > Unicode objects as keys which match their string equivalents > > as the same key, e.g. 'abc' works just as well as u'abc'. > > > UTF-8 was the default encoding back then. I'm not sure how > > to fix the hash value given the new strategy w/r to the > > default encoding... > > > According to the docs, objects comparing equal should have the > > same hash value, yet this would require the hash value to be > > calculated using the default encoding and that > > would not only cause huge performance problems, but could > > effectively render Unicode useless, because not all default > > encodings are lossless (ok, one could work around this by > > falling back to some other way of calculating the hash > > value in case the conversion fails). > > Yeah, yeah, yeah. I know all that, just never liked it. :) > The current problem is that the UTF-8 can't round trip surrogate characters > atm. > This is easy to fix, so I'm doing a patch to fix this oversight, unless you > beat me to it. > > Anything else is slightly more annoying to fix. I left out surrogates in the UTF-8 codec on purpose: the Python implementation currently doesn't have support for these, e.g. slicing doesn't care about UTF-16 surrogates, so I made sure that people using these get errors ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Wed Jul 5 11:05:16 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 05:05:16 -0400 Subject: [Python-Dev] RE: Making the CVS tree pass the -Wall test... In-Reply-To: <200007050650.IAA00972@loewis.home.cs.tu-berlin.de> Message-ID: >> ./pypcre.c:4524: warning: variable `start_bits' might be >> clobbered by `longjmp' or `vfork' >> ./pypcre.c:4525: warning: variable `start_match' might be >> clobbered by `longjmp' or `vfork' [Tim sez these are almost always bogus wngs, Martin sez these two are legit] The start_bits wng is bogus because start_bit's only definition points precede the do-loop: start_bits will either be NULL or extra->start_bits by the time the "do" is entered, and can never change after that (yes, start_bits "appears" in the loop, but not as an lvalue -- it's only referenced). So the value setjmp tucks away is necessarily the correct value for longjmp to restore. This is a purely local flow question; knowledge of when a longjmp may occur isn't needed. I agree the start_match wng is legit. In my previous life, I tracked down about a hundred of these, and found only one that was legit. So pypcre is as sick as Dragon's half-million lines of speech recognition code . "The usual" way to fix this is to slop "volatile" onto the declarations, as the author already did for three other locals. That's the second reason this warning sucks: it depends on which locals gcc decides to carry in registers, and that varies from release to release. And that's the third reason this warning sucks: gcc is actually complaining about its *own* decision to carry something in a register <0.1 wink -- and if it *knows* it's not safe to carry something in a register, it shouldn't!>. From tim_one at email.msn.com Wed Jul 5 11:07:59 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 05:07:59 -0400 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... In-Reply-To: <3962EA0B.2EBED7A8@lemburg.com> Message-ID: [MAL] > While fiddling around with the _GNU_SOURCE define I found > that there are several warnings left in the current CVS > version which should be removed, I guess. [Tim] > So long as any warnings remain, would you please repost the > list from time to time? There's no need to group them by file. [MAL] > Ok. > > Note that the idea behind posting the list was to make > module authors/editors aware of warnings in their code... Fred > already made his changes -- it would probably be a good idea > if the others did the same. Of course. That's why I'm asking you to repost this list until no wngs remain . one-time-implicit-nags-don't-work-ly y'rs - tim From tim_one at email.msn.com Wed Jul 5 11:11:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 05:11:18 -0400 Subject: [Python-Dev] SF Beuracracy again In-Reply-To: Message-ID: [Moshe Zadka] > Is there a difference between what SF calls "developers" and what we > informally call "poeple with commit access"? Not that I know of. > Can anyone clear the stati > people can have with regard to the Python project? Try rephrasing that question in a known language . Ah, plural of "status"? You're a developer or you're not, and if you're a developer you're an admin or you're not. That's it. > (I've just revived my account on SF because of Python...) If you're looking for sympathy, this is the wrong list . From fredrik at pythonware.com Wed Jul 5 11:14:21 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 11:14:21 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> Message-ID: <007f01bfe661$68b26080$0900a8c0@SPIFF> mal wrote: > > Given the new 7-bit-ASCII-as-default-encoding-for-8-bit-strings > > convention, shouldn't just hashing the character values work > > fine? That is, hash('abc') should == hash(u'abc'), no conversion > > required. > > Yes, and it does so already for pure ASCII values. The problem > comes from the fact that the default encoding can be changed to > a locale specific value (site.py does the lookup for you), e.g. > given you have defined LANG to be us_en, Python will default > to Latin-1 as default encoding. footnote: in practice, this is a Unix-only feature. I suggest adding code to the _locale module (or maybe sys is better?) which can be used to dig up a suitable encoding for non-Unix platforms. On Windows, the code page should be "cp%d" % GetACP(). I'll look into this later today. From thomas at xs4all.net Wed Jul 5 11:15:09 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 5 Jul 2000 11:15:09 +0200 Subject: [Python-Dev] python 2.0 and '-tt' Message-ID: <20000705111509.J13469@xs4all.nl> I seem to recall someone claiming that the behaviour of the -tt flag was going to be the default in the next 'major' release of Python. Seeing as how the socket.socket change is back in again, it might be worth looking at this again ? Then again, I'm a newbie, it might be a done deal already, one way or the other ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mwh21 at cam.ac.uk Wed Jul 5 11:19:29 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Wed, 5 Jul 2000 10:19:29 +0100 (BST) Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <14690.56733.627266.907044@temoleh.chem.uu.nl> Message-ID: On Wed, 5 Jul 2000, Rob W. W. Hooft wrote: [schnipp] > Then 2 points on distutils: > - the word "licence" is used throughout, and "license" is introduced as > alternative. The other way around looks more natural to me. Isn't one the noun (licence) and one the verb (license)? (mind you dictionary.com doesn't think so, so I'd say pick one and stick with it). > - the term "anal retentives" should probably be replaced before 2.0 This reminds me of when they took out the swear words from the sources to linuk-kernel :-) > Is "s's" as in "the process's exit code" valid English? I think yes, because "process" is not a plural; it would be "processes' exit codes". but-then-I'm-a-mathematician-ly y'rs Michael From mal at lemburg.com Wed Jul 5 11:27:21 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 11:27:21 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> <007f01bfe661$68b26080$0900a8c0@SPIFF> Message-ID: <3962FF79.B1A773D0@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > Given the new 7-bit-ASCII-as-default-encoding-for-8-bit-strings > > > convention, shouldn't just hashing the character values work > > > fine? That is, hash('abc') should == hash(u'abc'), no conversion > > > required. > > > > Yes, and it does so already for pure ASCII values. The problem > > comes from the fact that the default encoding can be changed to > > a locale specific value (site.py does the lookup for you), e.g. > > given you have defined LANG to be us_en, Python will default > > to Latin-1 as default encoding. > > footnote: in practice, this is a Unix-only feature. > > I suggest adding code to the _locale module (or maybe sys is > better?) which can be used to dig up a suitable encoding for > non-Unix platforms. On Windows, the code page should be > "cp%d" % GetACP(). > > I'll look into this later today. Could you add code to the _locale module which interfaces to GetACP() on win32 ? locale.get_default could then make use of this API to figure out the encoding. Ideal would be another API for win32 which allows querying the active language (it would have to return an RFC 1766 language code or we could add aliasis to the locale_alias database). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Wed Jul 5 11:38:55 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 11:38:55 +0200 Subject: [Python-Dev] Spelling check: more typos References: Message-ID: <009501bfe664$d6845ca0$0900a8c0@SPIFF> > Isn't one the noun (licence) and one the verb (license)? (mind you > dictionary.com doesn't think so, so I'd say pick one and stick with it). fwiw, none of the dictionaries I've checked agree with you. and they all seem to prefer "license" over "licence". > > Is "s's" as in "the process's exit code" valid English? > > I think yes, because "process" is not a plural; it would be "processes' > exit codes". according to the only grammar I found: FORMING THE POSSESSIVE WITH 'S AND ' 1.Singular nouns take 's 2.irregular plurals take 's 3.Nouns ending in s (plural or singular) take ' > but-then-I'm-a-mathematician-ly y'rs and we're a bunch of non-native english speakers ;-) From mal at lemburg.com Wed Jul 5 11:53:10 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 11:53:10 +0200 Subject: [Python-Dev] Docs for string methods ? Message-ID: <39630586.A253198A@lemburg.com> I've just checked in new string methods which provide access to the C APIs isalpha and isalnum for both strings and Unicode objects. Question: where should I put the docs ? I haven't found any place in the current CVS tree which document the new string methods -- even though all of them have doc strings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Wed Jul 5 12:01:21 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 12:01:21 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> Message-ID: <00d101bfe667$f9099d00$0900a8c0@SPIFF> mal wrote: > I've just checked in new string methods talking about string methods: how about providing an "encode" method for 8-bit strings too? From esr at thyrsus.com Wed Jul 5 12:09:43 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Jul 2000 06:09:43 -0400 Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <009501bfe664$d6845ca0$0900a8c0@SPIFF>; from fredrik@pythonware.com on Wed, Jul 05, 2000 at 11:38:55AM +0200 References: <009501bfe664$d6845ca0$0900a8c0@SPIFF> Message-ID: <20000705060943.A18539@thyrsus.com> Fredrik Lundh : > > Isn't one the noun (licence) and one the verb (license)? (mind you > > dictionary.com doesn't think so, so I'd say pick one and stick with it). > > fwiw, none of the dictionaries I've checked agree with you. > and they all seem to prefer "license" over "licence". > > > > Is "s's" as in "the process's exit code" valid English? > > > > I think yes, because "process" is not a plural; it would be "processes' > > exit codes". > > according to the only grammar I found: > > FORMING THE POSSESSIVE WITH 'S AND ' > 1.Singular nouns take 's > 2.irregular plurals take 's > 3.Nouns ending in s (plural or singular) take ' > > > but-then-I'm-a-mathematician-ly y'rs > > and we're a bunch of non-native english speakers ;-) I am a native speaker, and an expert in the fine points of English grammar and usage (a necessary qualification for editing the New Hacker's Dictionary). Tim's source is correct. Learn these rules; they will mark you out from the vast sea of yahoos who (for example) use "it's" where "its" is correct. (Guido's English is impressively correct, BTW. The rest of you non-native speakers -- and some of you native ones -- could learn from him.) -- Eric S. Raymond You [should] not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harm it would cause if improperly administered -- Lyndon Johnson, former President of the U.S. From mwh21 at cam.ac.uk Wed Jul 5 12:06:11 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Wed, 5 Jul 2000 11:06:11 +0100 (BST) Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <20000705060943.A18539@thyrsus.com> Message-ID: On Wed, 5 Jul 2000, Eric S. Raymond wrote: > Fredrik Lundh : > > > > Is "s's" as in "the process's exit code" valid English? > > > > > > I think yes, because "process" is not a plural; it would be "processes' > > > exit codes". > > > > according to the only grammar I found: > > > > FORMING THE POSSESSIVE WITH 'S AND ' > > 1.Singular nouns take 's > > 2.irregular plurals take 's > > 3.Nouns ending in s (plural or singular) take ' > > > > > but-then-I'm-a-mathematician-ly y'rs > > > > and we're a bunch of non-native english speakers ;-) > > I am a native speaker, and an expert in the fine points of English grammar > and usage (a necessary qualification for editing the New Hacker's > Dictionary). Tim's source is correct. Tim? Do you mean /F? > Learn these rules; they will mark you out from the vast sea of yahoos > who (for example) use "it's" where "its" is correct. Well, the given rules don't account for that one do they? "Process' exit code" just looks wrong to me. Don't know why. Cheers, M. From mal at lemburg.com Wed Jul 5 12:06:21 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 12:06:21 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> Message-ID: <3963089D.8144149C@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > I've just checked in new string methods > > talking about string methods: how about providing an > "encode" method for 8-bit strings too? I've tossed that idea around a few times too... it could have the same interface as the Unicode one (without default encoding though). The only problem is that there are currently no codecs which could deal with strings on input. String codecs would have to be of the form 'latin1_utf8', that is, have implicit knowledge about the input encoding (and not only the output encoding as with Unicode codecs). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Wed Jul 5 12:15:54 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 12:15:54 +0200 Subject: [Python-Dev] Spelling check: more typos References: <009501bfe664$d6845ca0$0900a8c0@SPIFF> <20000705060943.A18539@thyrsus.com> Message-ID: <010901bfe66a$017d8b70$0900a8c0@SPIFF> eric wrote: > > > > Is "s's" as in "the process's exit code" valid English? > > > > > > I think yes, because "process" is not a plural; it would be "processes' > > > exit codes". > > > > according to the only grammar I found: > > > > FORMING THE POSSESSIVE WITH 'S AND ' > > 1.Singular nouns take 's > > 2.irregular plurals take 's > > 3.Nouns ending in s (plural or singular) take ' > > > > > but-then-I'm-a-mathematician-ly y'rs > > > > and we're a bunch of non-native english speakers ;-) > > I am a native speaker, and an expert in the fine points of English grammar > and usage (a necessary qualification for editing the New Hacker's > Dictionary). Tim's source is correct. Learn these rules; they will > mark you out from the vast sea of yahoos who (for example) use "it's" > where "its" is correct. what rules? the "tim is always correct" rule, or the grammar rules I quoted? From esr at thyrsus.com Wed Jul 5 12:24:34 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Jul 2000 06:24:34 -0400 Subject: [Python-Dev] Spelling check: more typos In-Reply-To: ; from mwh21@cam.ac.uk on Wed, Jul 05, 2000 at 11:06:11AM +0100 References: <20000705060943.A18539@thyrsus.com> Message-ID: <20000705062434.A18614@thyrsus.com> Michael Hudson : > > > FORMING THE POSSESSIVE WITH 'S AND ' > > > 1.Singular nouns take 's > > > 2.irregular plurals take 's > > > 3.Nouns ending in s (plural or singular) take ' > > > > > I am a native speaker, and an expert in the fine points of English grammar > > and usage (a necessary qualification for editing the New Hacker's > > Dictionary). Tim's source is correct. > > Tim? Do you mean /F? I believe /F was quoting Tim. > > Learn these rules; they will mark you out from the vast sea of yahoos > > who (for example) use "it's" where "its" is correct. > > Well, the given rules don't account for that one do they? Hm, I guess you have to know that pronouns pluralize irregularly to cover that case. What creates the confusion is that "it's" is the correct contraction of "it is", but looks like a possessive inflection of the pronoun "it". -- Eric S. Raymond "You have taught us much. Come with us and join the movement." "This movement of yours, does it have slogans?" inquired the Chink. "Right on!" they cried. And they quoted him some. "Your movement, does it have a flag?" asked the Chink. "You bet!" and they described their emblem. "And does your movement have leaders?" "Great leaders." "Then shove it up your butts," said the Chink. "I have taught you nothing." -- Tom Robbins, "Even Cowgirls Get The Blues" From fredrik at pythonware.com Wed Jul 5 12:20:04 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 12:20:04 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> Message-ID: <011101bfe66a$96d18aa0$0900a8c0@SPIFF> mal wrote: > Fredrik Lundh wrote: > > > > mal wrote: > > > I've just checked in new string methods > > > > talking about string methods: how about providing an > > "encode" method for 8-bit strings too? > > I've tossed that idea around a few times too... it could > have the same interface as the Unicode one (without default > encoding though). The only problem is that there are currently > no codecs which could deal with strings on input. imho, a consistent interface is more important than a truly optimal implementation (string are strings yada yada). or in other words, def encode(self, encoding): if encoding is close enough: return self return unicode(self).encode(encoding) ought to be good enough for now. From mal at lemburg.com Wed Jul 5 12:29:11 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 12:29:11 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> <011101bfe66a$96d18aa0$0900a8c0@SPIFF> Message-ID: <39630DF7.4B7ADB63@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Fredrik Lundh wrote: > > > > > > mal wrote: > > > > I've just checked in new string methods > > > > > > talking about string methods: how about providing an > > > "encode" method for 8-bit strings too? > > > > I've tossed that idea around a few times too... it could > > have the same interface as the Unicode one (without default > > encoding though). The only problem is that there are currently > > no codecs which could deal with strings on input. > > imho, a consistent interface is more important than a truly > optimal implementation (string are strings yada yada). or in > other words, > > def encode(self, encoding): > if encoding is close enough: > return self > return unicode(self).encode(encoding) > > ought to be good enough for now. Ideally str() should have an encoding parameter too. Then I could add generic PyString_Encode|Decode|AsEncodedString APIs to stringobject.c which match the corresponding ones in unicodeobject.c gzippeddata = file.read() # Unzip a data packet (decode part of the codec) data = str(gzippeddata, 'data_gzip') # Zip a data packet (encode part of the codec) gzippeddata = data.encode('data_gzip') Looks cool ;-) Note that 'abc'.encode('utf8') would fail because the UTF-8 codec expects Unicod on input to its encode method (hmm, perhaps I ought to make the method use the 'u' parser marker instead of 'U' -- that way, the method would auto-convert the 'abc' string to Unicode using the default encoding and then proceed to encode it in UTF-8). Other opinions ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jul 5 12:32:33 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 12:32:33 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> <011101bfe66a$96d18aa0$0900a8c0@SPIFF> <39630DF7.4B7ADB63@lemburg.com> Message-ID: <39630EC1.891DCE8F@lemburg.com> "M.-A. Lemburg" wrote: > > Note that 'abc'.encode('utf8') would fail because the UTF-8 > codec expects Unicod on input to its encode method (hmm, perhaps > I ought to make the method use the 'u' parser marker instead > of 'U' -- that way, the method would auto-convert the 'abc' > string to Unicode using the default encoding and then proceed > to encode it in UTF-8). Uhm, forget that last part... 'u' doesn't do auto-conversion :-( I could add that functionality to the interfaces in _codecmodule.c directly, though. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping at lfw.org Wed Jul 5 12:50:18 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 5 Jul 2000 03:50:18 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: Message-ID: On Tue, 4 Jul 2000, Ka-Ping Yee wrote: > It turns out that this should be quite easy. If it weren't > past 4am i would be posting a patch instead of just a verbal > suggestion right now -- but here's how to do it. Okay, done. Submitted to SourceForge as patch #100734. For the patch itself, see http://sourceforge.net/patch/download.php?id=100734 or http://sourceforge.net/patch/?func=detailpatch&patch_id=100734&group_id=5470 Here is a sample of the resulting behaviour: >>> if 3: ... 3 File "", line 2 3 ^ SyntaxError: expected indent here >>> 3 File "", line 1 3 ^ SyntaxError: unexpected indent >>> if 1: ... 3 ... 4 File "", line 3 4 ^ SyntaxError: dedent does not match any outer indentation level >>> if 1: ... if 2: ... 3 File "", line 3 3 ^ SyntaxError: unexpected dedent >>> if 1: ... if 2: ... 3 File "", line 3 3 ^ SyntaxError: dedent does not match any outer indentation level >>> Also (didn't want to waste pages of text demonstrating it) if you indent more than 100 levels, you get SyntaxError: too many levels of indentation instead of the current message, "invalid token". The internal changes are: 1. Added E_TOODEEP (too many indentation levels) and E_DEDENT (no matching outer block for dedent) to errcode.h. 2. Made PyTokenizer_Get (in tokenizer.c) return E_TOODEEP and E_DEDENT instead of printing messages to stderr; added corresponding error messages in err_input (in pythonrun.c). 3. Renamed E_INDENT to E_TABSPACE. 4. Added int *expected_ret argument to PyParser_AddToken; on a syntax error, PyParser_AddToken (in parser.c) places the expected token type (if any) into this output parameter. 5. Added "token" and "expected" to struct perrdetail; made parsetok (in parsetok.c) copy the current token into "token" and the expected token into "expected" on a syntax error. 6. Added checks in err_input (in pythonrun.c) to print more detailed error messages if err->token or err->expected happens to be INDENT or DEDENT when a syntax error occurs. This leaves the door open for err_input to say more interesting things about the syntax error if it wants, based on the information in err->token and err->expected, though i haven't added any more detailed messages except for the ones about indentation for now. Look good to you? -- ?!ng From gvwilson at nevex.com Wed Jul 5 13:10:33 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 5 Jul 2000 07:10:33 -0400 (EDT) Subject: [Python-Dev] re: punctuation / spelling Message-ID: The best on-line writing style guide I know of is the one used by the The Economist: http://www.economist.com/editorial/freeforall/library/index_styleguide.html Their advice on possessives is: Use the normal possessive ending 's after singular words or names that end in s: boss's, caucus's, Delors's, St James's, Jones's, Shanks's. Use it after plurals that do not end in s: children's, Frenchmen's, media's. Use the ending s' on plurals that end in s---Danes', bosses', Joneses'---including plural names that take a singular verb, eg, Reuters', Barclays', Stewarts & Lloyds', Salomon Brothers'. Although singular in other respects, the United States, the United Nations, the Philippines, etc, have a plural possessive apostrophe: eg, Who will be the United States' next president? Strunk & White is also a good, pocket-sized resource, but so far as I know there is no up-to-date edition on-line. Greg From esr at thyrsus.com Wed Jul 5 13:32:10 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Jul 2000 07:32:10 -0400 Subject: [Python-Dev] re: punctuation / spelling In-Reply-To: ; from gvwilson@nevex.com on Wed, Jul 05, 2000 at 07:10:33AM -0400 References: Message-ID: <20000705073210.B18933@thyrsus.com> Greg Wilson : > The best on-line writing style guide I know of is the one used by the The > Economist: > > http://www.economist.com/editorial/freeforall/library/index_styleguide.html I enthusiastically second this recommendation. For American use their advice is a touch British-flavored in the orthography department, but their recommendations on grammar and style are impeccable. The Economist is my favorite news magazine in the world. -- Eric S. Raymond "This country, with its institutions, belongs to the people who inhabit it. Whenever they shall grow weary of the existing government, they can exercise their constitutional right of amending it or their revolutionary right to dismember it or overthrow it." -- Abraham Lincoln, 4 April 1861 From fredrik at pythonware.com Wed Jul 5 13:51:56 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 13:51:56 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> <011101bfe66a$96d18aa0$0900a8c0@SPIFF> <39630DF7.4B7ADB63@lemburg.com> Message-ID: <02b501bfe677$6ba38b00$0900a8c0@SPIFF> mal wrote: > > > > talking about string methods: how about providing an > > > > "encode" method for 8-bit strings too? > > > > > > I've tossed that idea around a few times too... it could > > > have the same interface as the Unicode one (without default > > > encoding though). The only problem is that there are currently > > > no codecs which could deal with strings on input. > > > > imho, a consistent interface is more important than a truly > > optimal implementation (string are strings yada yada). or in > > other words, > > > > def encode(self, encoding): > > if encoding is close enough: > > return self > > return unicode(self).encode(encoding) > > > > ought to be good enough for now. /snip/ > Note that 'abc'.encode('utf8') would fail because the UTF-8 > codec expects Unicod on input to its encode method (hmm, perhaps > I ought to make the method use the 'u' parser marker instead > of 'U' -- that way, the method would auto-convert the 'abc' > string to Unicode using the default encoding and then proceed > to encode it in UTF-8). sorry, I wasn't clear: the "def encode" snippet above should be a string method, not a function. "abc".encode("utf8") would be "return self" if the default encoding is "ascii" or "utf8", and "return unicode("abc").encode("utf8")" other- wise. cheers /F From bwarsaw at beopen.com Wed Jul 5 13:56:02 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 07:56:02 -0400 (EDT) Subject: [Python-Dev] Making -tt the default References: <20000703233938.N29590@lyra.org> Message-ID: <14691.8786.180085.468266@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> (add-hook 'python-mode-hook | (lambda () | (setq indent-tabs-mode nil) | (setq py-indent-offset 2) | (setq py-smart-indentation nil) | (define-key py-mode-map "\e\C-h" 'backward-kill-word) | )) GS> The indent-tabs-mode is the key to disabling tab characters GS> and using just spaces. Greg, can you explain why you turn off py-smart-indentation? Its purpose is to give you the correct settings when editing someone else's existing code. With this variable set to t, it tries to guess the existing code's indentation level depth and then sets py-indent-offset to that value, on the assumption that 1) the original author indented their code consistently 2) it is better to be consistent with the existing indentation than impose your own and have mixed indentation Both of these are worthy goals, IMO, so py-smart-indentation should generally remain true. For brand new code, given the fact that pymode's default for py-indent-offset is 4, and Emacs' default for tab-width is 8 (and should not be changed), you'll generally find that indent-tabs-mode will be nil when py-smart-indentation is t. So I think pymode is doing the right thing, and I'm -1 on patch #100729. If the user wants indent-tabs-mode set to nil unconditionally, then setting it in your python-mode-hook, as you've done, is the Emacs way. But if someone can give a good example where this approach is flawed, please let me know. -Barry From fredrik at pythonware.com Wed Jul 5 13:57:40 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 13:57:40 +0200 Subject: [Python-Dev] Better SyntaxError messages References: Message-ID: <02bf01bfe678$3a1baee0$0900a8c0@SPIFF> ?!ng wrote: > Okay, done. Submitted to SourceForge as patch #100734. For the patch > itself, see http://sourceforge.net/patch/download.php?id=100734 or > http://sourceforge.net/patch/?func=detailpatch&patch_id=100734&group_id=5470 +2 on concept. and the patch looks clean. let's get this one in there asap! (marc-andre?) > Look good to you? you bet! From mal at lemburg.com Wed Jul 5 13:59:34 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 13:59:34 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> <011101bfe66a$96d18aa0$0900a8c0@SPIFF> <39630DF7.4B7ADB63@lemburg.com> <02b501bfe677$6ba38b00$0900a8c0@SPIFF> Message-ID: <39632326.9A724C2@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > > > talking about string methods: how about providing an > > > > > "encode" method for 8-bit strings too? > > > > > > > > I've tossed that idea around a few times too... it could > > > > have the same interface as the Unicode one (without default > > > > encoding though). The only problem is that there are currently > > > > no codecs which could deal with strings on input. > > > > > > imho, a consistent interface is more important than a truly > > > optimal implementation (string are strings yada yada). or in > > > other words, > > > > > > def encode(self, encoding): > > > if encoding is close enough: > > > return self > > > return unicode(self).encode(encoding) > > > > > > ought to be good enough for now. > > /snip/ > > > Note that 'abc'.encode('utf8') would fail because the UTF-8 > > codec expects Unicod on input to its encode method (hmm, perhaps > > I ought to make the method use the 'u' parser marker instead > > of 'U' -- that way, the method would auto-convert the 'abc' > > string to Unicode using the default encoding and then proceed > > to encode it in UTF-8). > > sorry, I wasn't clear: the "def encode" snippet above should be > a string method, not a function. > > "abc".encode("utf8") would be "return self" if the default encoding > is "ascii" or "utf8", and "return unicode("abc").encode("utf8")" other- > wise. I've just checked in modifications to the builtin codecs which allow them to accept 8-bit strings too. They will convert the strings to Unicode and then encode them as usual. So given that the .encode() method gets accepted (I haven't heard any other opinions yet), "abc".encode("utf8") will work just like any other builtin codec (the 8-bit string will be interpreted under the default encoding assumption). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jul 5 14:01:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 14:01:26 +0200 Subject: [Python-Dev] Better SyntaxError messages References: <02bf01bfe678$3a1baee0$0900a8c0@SPIFF> Message-ID: <39632396.32E4BA61@lemburg.com> Fredrik Lundh wrote: > > ?!ng wrote: > > Okay, done. Submitted to SourceForge as patch #100734. For the patch > > itself, see http://sourceforge.net/patch/download.php?id=100734 or > > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100734&group_id=5470 > > +2 on concept. > > and the patch looks clean. let's get this one in > there asap! (marc-andre?) I'd rather have someone else with more knowledge about Python's parser check this in... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Wed Jul 5 14:19:27 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 14:19:27 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> <007f01bfe661$68b26080$0900a8c0@SPIFF> <3962FF79.B1A773D0@lemburg.com> Message-ID: <02f701bfe67b$43ec51b0$0900a8c0@SPIFF> mal wrote: > Ideal would be another API for win32 which allows querying > the active language (it would have to return an RFC 1766 > language code or we could add aliasis to the locale_alias > database). A quick look indicates that Windows uses "language identifiers": http://msdn.microsoft.com/library/psdk/winbase/nls_8xo3.htm Maybe Bill can dig up some better way to do this (a "language identifier to language code" table would be nice. There's one in Windows 2000 ;-) From Vladimir.Marangozov at inrialpes.fr Wed Jul 5 14:29:36 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 5 Jul 2000 14:29:36 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Ka-Ping Yee" at Jul 05, 2000 03:50:18 AM Message-ID: <200007051229.OAA19526@python.inrialpes.fr> Ka-Ping Yee wrote: > > On Tue, 4 Jul 2000, Ka-Ping Yee wrote: > > It turns out that this should be quite easy. If it weren't > > past 4am i would be posting a patch instead of just a verbal > > suggestion right now -- but here's how to do it. > > Okay, done. Looks fine. +1 on the concept. 2 things about the patch: > > >>> if 3: > ... 3 > File "", line 2 > 3 > ^ > SyntaxError: expected indent here I'd remove the word "here" so that the error msg is self-contained. "expected indent" & "expected dedent" are fine. > The internal changes are: > > 1. Added E_TOODEEP (too many indentation levels) and > E_DEDENT (no matching outer block for dedent) to errcode.h. > > 2. Made PyTokenizer_Get (in tokenizer.c) return E_TOODEEP and > E_DEDENT instead of printing messages to stderr; added > corresponding error messages in err_input (in pythonrun.c). > > 3. Renamed E_INDENT to E_TABSPACE. > > 4. Added int *expected_ret argument to PyParser_AddToken; on > a syntax error, PyParser_AddToken (in parser.c) places the > expected token type (if any) into this output parameter. I'd suggest passing a pointer to the perrdetail structure (to the whole error, that is), instead of a pointer to one of its fields. > > 5. Added "token" and "expected" to struct perrdetail; made > parsetok (in parsetok.c) copy the current token into "token" > and the expected token into "expected" on a syntax error. > > 6. Added checks in err_input (in pythonrun.c) to print more > detailed error messages if err->token or err->expected > happens to be INDENT or DEDENT when a syntax error occurs. > > This leaves the door open for err_input to say more interesting > things about the syntax error if it wants, based on the information > in err->token and err->expected, though i haven't added any more > detailed messages except for the ones about indentation for now. > > > Look good to you? > Yes. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gvwilson at nevex.com Wed Jul 5 14:34:28 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 5 Jul 2000 08:34:28 -0400 (EDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <200007051229.OAA19526@python.inrialpes.fr> Message-ID: > On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > I'd remove the word "here" so that the error msg is self-contained. > "expected indent" & "expected dedent" are fine. I just did a poll --- only 2 out of 5 programmers in my shouting radius know what "dedent" means. Is there a more accessible way to phrase the error message? Thanks, Greg From Vladimir.Marangozov at inrialpes.fr Wed Jul 5 14:54:50 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 5 Jul 2000 14:54:50 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Greg Wilson" at Jul 05, 2000 08:34:28 AM Message-ID: <200007051254.OAA19572@python.inrialpes.fr> Greg Wilson wrote: > > > On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > > I'd remove the word "here" so that the error msg is self-contained. > > "expected indent" & "expected dedent" are fine. > > I just did a poll --- only 2 out of 5 programmers in my shouting radius > know what "dedent" means. Is there a more accessible way to phrase the > error message? Good point. Here's another suggestion: "expected indent" -> "missing expected indentation" "expected dedent" -> "missing expected closing indentation" ? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mwh21 at cam.ac.uk Wed Jul 5 15:17:49 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Wed, 5 Jul 2000 14:17:49 +0100 (BST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <200007051254.OAA19572@python.inrialpes.fr> Message-ID: On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > Greg Wilson wrote: > > > > > On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > > > I'd remove the word "here" so that the error msg is self-contained. > > > "expected indent" & "expected dedent" are fine. > > > > I just did a poll --- only 2 out of 5 programmers in my shouting radius > > know what "dedent" means. Is there a more accessible way to phrase the > > error message? > > Good point. > > Here's another suggestion: > > "expected indent" -> "missing expected indentation" +0 - doesn't really change much does it? > "expected dedent" -> "missing expected closing indentation" Eugh. How about "expected decrease in indentation"? Though I think dedent (or mabye outdent) is pretty obvious in context. Also "decrease in indentation does not match any outer level" is a pretty hefty error message. Still, these things are so much better than the status quo that I'm about +1e8 on the general idea... Cheers, Michael From Mike.Da.Silva at uk.fid-intl.com Wed Jul 5 15:27:18 2000 From: Mike.Da.Silva at uk.fid-intl.com (Da Silva, Mike) Date: Wed, 5 Jul 2000 14:27:18 +0100 Subject: [Python-Dev] Better SyntaxError messages Message-ID: Michael Hudson wrote: >On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > > Greg Wilson wrote: > > > > > > > On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > > > > I'd remove the word "here" so that the error msg is self-contained. > > > > "expected indent" & "expected dedent" are fine. > > > > > > I just did a poll --- only 2 out of 5 programmers in my shouting radius > > > know what "dedent" means. Is there a more accessible way to phrase the > > > error message? > > > > Good point. > > > > Here's another suggestion: > > > > "expected indent" -> "missing expected indentation" > +0 - doesn't really change much does it? > > "expected dedent" -> "missing expected closing indentation" > Eugh. How about "expected decrease in indentation"? Though I think > dedent (or mabye outdent) is pretty obvious in context. > Also "decrease in indentation does not match any outer level" > is a pretty hefty error message. How about "expected unindent" ? > Still, these things are so much better than the status quo that I'm about +1e8 on the general idea... > Cheers, > Michael Regards, Mike _______________________________________________ Python-Dev mailing list Python-Dev at python.org http://www.python.org/mailman/listinfo/python-dev From Vladimir.Marangozov at inrialpes.fr Wed Jul 5 15:36:37 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 5 Jul 2000 15:36:37 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Michael Hudson" at Jul 05, 2000 02:17:49 PM Message-ID: <200007051336.PAA19744@python.inrialpes.fr> Michael Hudson wrote: > > [me] > > Here's another suggestion: > > > > "expected indent" -> "missing expected indentation" > > +0 - doesn't really change much does it? It's slightly more explicit. > > > "expected dedent" -> "missing expected closing indentation" > > Eugh. How about "expected decrease in indentation"? Though I think > dedent (or mabye outdent) is pretty obvious in context. I like your correction. The problem is that "dedent" is very context-specific and it would be better if this term is avoided for user-messages, because they generally pop up out of context (i.e. when your head is in another context, so the context switch is painful). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From billtut at microsoft.com Wed Jul 5 17:26:22 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 5 Jul 2000 08:26:22 -0700 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD26A@RED-MSG-50> > MAL wrote: > ... I wonder why compiling "print u'\uD800'" causes the > hash value to be computed ... That's an easy one. Com_addconst() (or something it calls) calls PyObject_Hash() during the compilation process. Re: UTF-8 There's no reason why you can't support surrogates in UTF-8, while still not supporting them in slice notation. It's certainly the easiest way to fix the problem. Bill From mal at lemburg.com Wed Jul 5 17:40:19 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 17:40:19 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD26A@RED-MSG-50> Message-ID: <396356E3.A2F586B5@lemburg.com> Bill Tutt wrote: > > > MAL wrote: > > ... I wonder why compiling "print u'\uD800'" causes the > > hash value to be computed ... > > That's an easy one. Com_addconst() (or something it calls) calls > PyObject_Hash() during the compilation process. Ah ok. > Re: UTF-8 > There's no reason why you can't support surrogates in UTF-8, while still not > supporting them in slice notation. True. > It's certainly the easiest way to fix the problem. Well, it doesn't really fix the problem... your note only made it clear that with the change in default encoding (be it ASCII or whatever the locale defines), has the unwanted side effect of breaking the has/cmp rule for non-ASCII character strings vs. Unicode. Perhaps pushing the default encoding down all the way is the solution (with some trickery this is possible now, since changing the default encoding is only allows in site.py) or simply stating that the hash/cmp rule only works for ASCII contents of the objects. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Wed Jul 5 06:57:19 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 4 Jul 2000 23:57:19 -0500 (CDT) Subject: [Python-Dev] SyntaxError/IndentationError/WhitespaceError Message-ID: <14690.49199.153631.236949@beluga.mojam.com> Just back from the annual patriotic revelry... Here are my thoughts on the various kinds of exceptions one might raise to denote various problems with indentation. SyntaxError - the most general form of parsing error WhitespaceError - tells the user something's wrong with the way the whitespace of the line parses - what -tt mode would raise IndentationError - more specific than WhitespaceError, but indicates the lines won't line up properly (without -tt mode) - what the parser would raise for something like: try: 1/0 1/0 except ZeroDivisionError: pass The distinction between WhitespaceError and IndentationError is likely to be a bit subtle for newbies, so I wonder if it's worth the effort to distinguish the two. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From gward at mems-exchange.org Wed Jul 5 19:02:15 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 13:02:15 -0400 Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: ; from Mike.Da.Silva@uk.fid-intl.com on Wed, Jul 05, 2000 at 02:27:18PM +0100 References: Message-ID: <20000705130215.A7564@ludwig.cnri.reston.va.us> On 05 July 2000, Da Silva, Mike said: > > > "expected dedent" -> "missing expected closing indentation" > > > Eugh. How about "expected decrease in indentation"? Though I think > > dedent (or mabye outdent) is pretty obvious in context. > > > Also "decrease in indentation does not match any outer level" > > is a pretty hefty error message. > > How about "expected unindent" ? I was going to suggest "unindent" from the moment I saw Ping's patch, so let me just chime in with a "yes indeed!". Also, along with the rest of the known universe, I strongly favour the proposed change. Haven't tried the patch yet, but I will. Greg From Vladimir.Marangozov at inrialpes.fr Wed Jul 5 19:12:37 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 5 Jul 2000 19:12:37 +0200 (CEST) Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <3962355D.7FD7429@lemburg.com> from "M.-A. Lemburg" at Jul 04, 2000 09:05:01 PM Message-ID: <200007051712.TAA20213@python.inrialpes.fr> M.-A. Lemburg wrote: > > I've added some ifdefs just to make sure. This is how my > Python.h file looks now: > > ... > See the file "Misc/COPYRIGHT" for information on usage and > redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES. > ******************************************************************/ > > /* Enable compiler features including SUSv2 compatibility; switching > on C lib defines doesn't work here, because the symbols haven't > necessarily been defined yet. */ > #ifndef _GNU_SOURCE > # define _GNU_SOURCE 1 > #endif > #ifndef _XOPEN_SOURCE > # define _XOPEN_SOURCE 500 > #endif Typically this should go to a new file -- pyport.h, suggested by Greg, included at the top of Python.h (and which allows to cleanup the HAVE_LIMITS_H define and others). We may introduce subsequently pyport.c if needed. Anything wrong with this? Opinions? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Wed Jul 5 19:12:31 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 19:12:31 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <200007051712.TAA20213@python.inrialpes.fr> Message-ID: <39636C7F.D0A29101@lemburg.com> Vladimir Marangozov wrote: > > M.-A. Lemburg wrote: > > > > I've added some ifdefs just to make sure. This is how my > > Python.h file looks now: > > > > ... > > See the file "Misc/COPYRIGHT" for information on usage and > > redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES. > > ******************************************************************/ > > > > /* Enable compiler features including SUSv2 compatibility; switching > > on C lib defines doesn't work here, because the symbols haven't > > necessarily been defined yet. */ > > #ifndef _GNU_SOURCE > > # define _GNU_SOURCE 1 > > #endif > > #ifndef _XOPEN_SOURCE > > # define _XOPEN_SOURCE 500 > > #endif > > Typically this should go to a new file -- pyport.h, suggested by Greg, > included at the top of Python.h (and which allows to cleanup the > HAVE_LIMITS_H define and others). We may introduce subsequently pyport.c > if needed. > > Anything wrong with this? Opinions? Fine with me... I'd name it pyportability.h like Greg suggested, though. Note that the above is already checked into CVS (and the first bug related to it has shown up too; also fixed in CVS). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Wed Jul 5 19:39:29 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 19:39:29 +0200 Subject: [Python-Dev] locale.setlocale vs. locale.set_locale Message-ID: <006a01bfe6a7$fa696000$f2a6b5d4@hagrid> maybe it's just me, but I think it's a bit confusing to have two functions in the same module with very similar names: >>> import locale >>> print locale.setlocale.__doc__ (integer,string=None) -> string. Activates/queries locale processing. >>> print locale.set_locale.__doc__ Set the locale according to the localetuple (language code, encoding) as returned by get_locale() and get_default(). The given codes are passed through the locale aliasing engine before being given to setlocale() for processing. category may be given as one of the LC_* values. It defaults to LC_ALL. maybe "setlocale" should be changed to accept either a string or a tuple? (from which follows that get_locale should be "getlocale", and get_default "getdefaultlocale". or something...) (btw, maybe both doc strings should mention the arguments? or maybe none of them should? what does the style guide say?) From effbot at telia.com Wed Jul 5 19:47:55 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 19:47:55 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> <007f01bfe661$68b26080$0900a8c0@SPIFF> <3962FF79.B1A773D0@lemburg.com> <02f701bfe67b$43ec51b0$0900a8c0@SPIFF> Message-ID: <007f01bfe6aa$28e52d40$f2a6b5d4@hagrid> I wrote: > A quick look indicates that Windows uses "language identifiers": > http://msdn.microsoft.com/library/psdk/winbase/nls_8xo3.htm > > Maybe Bill can dig up some better way to do this (a "language > identifier to language code" table would be nice. There's one > in Windows 2000 ;-) nevermind; I've crafted a piece of code that digs out the RFC 1766 language code (e.g. en-EN) and the code page (e.g. cp1252), on Win98/NT4/2000. unfortunately, Win95 won't give me the language code; it insists on using "language identifiers" (such as 041d). guess we need a table after all. oh well. patch follows. From mal at lemburg.com Wed Jul 5 19:53:43 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 19:53:43 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> <007f01bfe661$68b26080$0900a8c0@SPIFF> <3962FF79.B1A773D0@lemburg.com> <02f701bfe67b$43ec51b0$0900a8c0@SPIFF> <007f01bfe6aa$28e52d40$f2a6b5d4@hagrid> Message-ID: <39637627.BFDA941A@lemburg.com> Fredrik Lundh wrote: > > I wrote: > > > A quick look indicates that Windows uses "language identifiers": > > http://msdn.microsoft.com/library/psdk/winbase/nls_8xo3.htm > > > > Maybe Bill can dig up some better way to do this (a "language > > identifier to language code" table would be nice. There's one > > in Windows 2000 ;-) > > nevermind; I've crafted a piece of code that digs out the RFC 1766 > language code (e.g. en-EN) and the code page (e.g. cp1252), on > Win98/NT4/2000. > > unfortunately, Win95 won't give me the language code; it insists > on using "language identifiers" (such as 041d). guess we need a > table after all. oh well. > > patch follows. Great :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jul 5 20:02:04 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 20:02:04 +0200 Subject: [Python-Dev] locale.setlocale vs. locale.set_locale References: <006a01bfe6a7$fa696000$f2a6b5d4@hagrid> Message-ID: <3963781C.DD06D0DE@lemburg.com> Fredrik Lundh wrote: > > maybe it's just me, but I think it's a bit confusing to have two > functions in the same module with very similar names: > > >>> import locale > > >>> print locale.setlocale.__doc__ > (integer,string=None) -> string. Activates/queries locale processing. > > >>> print locale.set_locale.__doc__ > Set the locale according to the localetuple (language code, > encoding) as returned by get_locale() and get_default(). > > The given codes are passed through the locale aliasing engine > before being given to setlocale() for processing. > > category may be given as one of the LC_* values. It defaults > to LC_ALL. The new set_locale() is meant to complement get_locale(); both work on tuples (langcode, encoding). setlocale() has a completely different interface: it uses a locale category integer together with a setup string. The reasoning here was to add a higher level interface on top of setlocale() which is the direct interface to the underlying low level C API. The underscore variants provide aliasing support and knows about the formats which the setlocale() API will accept -- at least on Linux setlocale() is very picky about case and layout of the setup string. > maybe "setlocale" should be changed to accept either a > string or a tuple? > > (from which follows that get_locale should be "getlocale", and > get_default "getdefaultlocale". or something...) If you want to change anything here: now is the time ;-) Please also adapt site.py which uses these APIs. > (btw, maybe both doc strings should mention the arguments? or > maybe none of them should? what does the style guide say?) I always thought that the arguments should only be mentioned for C functions... not sure, though. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jul 5 20:11:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 20:11:08 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) Message-ID: <39637A3C.9489CB15@lemburg.com> The idea is not new: strings and Unicode should have more or less the same methods to enhance their compatibility. The attached patch adds encoding capabilities to normal strings and extends the builtin str() to accept an optional encoding (and error) argument. It also tries to reuse the already available Unicode codecs for the purposes of strings (conversions are done via the default encoding in both directions). With it you can use the existing codecs to easily encode or decode strings and data into string objects: >>> 'abc'.encode('utf16') '\377\376a\000b\000c\000' >>> str(_, 'utf16') 'abc' Since the codec API and registry support more than just Unicode codecs, one could also think of things like: '...long...data...string...'.encode('data_gzip') or other complicated string conversions. The str(obj[, encoding[, errors]]) builtin does the exact opposite: it takes the string representation of obj and then decodes it using the given encoding. What do you think about this ? Should I add it to CVS as experiment ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ -------------- next part -------------- diff -u -rbP -x *.o -x *.pyc -x Makefile -x *~ -x *.so -x add2lib -x pgen -x buildno -x core -x config.* -x libpython* -x python -x Setup -x Setup.local -x Setup.thread -x Setup.config -x hassignal -x Makefile.pre -x configure -x *.bak -x *.s -x DEADJOE -x *.rej -x *.orig -x Demo -x CVS -x Doc -x *.orig -x .#* -x distutils -x */plat* -x *.py -x ACKS -x *.txt -x README CVS-Python/Include/stringobject.h Python+Unicode/Include/stringobject.h --- CVS-Python/Include/stringobject.h Sat Jul 1 10:30:46 2000 +++ Python+Unicode/Include/stringobject.h Wed Jul 5 18:59:46 2000 @@ -81,6 +81,37 @@ #define PyString_AS_STRING(op) (((PyStringObject *)(op))->ob_sval) #define PyString_GET_SIZE(op) (((PyStringObject *)(op))->ob_size) +/* --- Generic Codecs ----------------------------------------------------- */ + +/* Create a string object by decoding the encoded string s of the + given size. */ + +extern DL_IMPORT(PyObject*) PyString_Decode( + const char *s, /* encoded string */ + int size, /* size of buffer */ + const char *encoding, /* encoding */ + const char *errors /* error handling */ + ); + +/* Encodes a char buffer of the given size and returns a + Python string object. */ + +extern DL_IMPORT(PyObject*) PyString_Encode( + const char *s, /* string char buffer */ + int size, /* number of chars to encode */ + const char *encoding, /* encoding */ + const char *errors /* error handling */ + ); + +/* Encodes a string object and returns the result as Python string + object. */ + +extern DL_IMPORT(PyObject*) PyString_AsEncodedString( + PyObject *str, /* string object */ + const char *encoding, /* encoding */ + const char *errors /* error handling */ + ); + #ifdef __cplusplus } #endif diff -u -rbP -x *.o -x *.pyc -x Makefile -x *~ -x *.so -x add2lib -x pgen -x buildno -x core -x config.* -x libpython* -x python -x Setup -x Setup.local -x Setup.thread -x Setup.config -x hassignal -x Makefile.pre -x configure -x *.bak -x *.s -x DEADJOE -x *.rej -x *.orig -x Demo -x CVS -x Doc -x *.orig -x .#* -x distutils -x */plat* -x *.py -x ACKS -x *.txt -x README CVS-Python/Objects/stringobject.c Python+Unicode/Objects/stringobject.c --- CVS-Python/Objects/stringobject.c Wed Jul 5 11:42:49 2000 +++ Python+Unicode/Objects/stringobject.c Wed Jul 5 19:47:44 2000 @@ -152,6 +152,100 @@ return (PyObject *) op; } +PyObject *PyString_Decode(const char *s, + int size, + const char *encoding, + const char *errors) +{ + PyObject *buffer = NULL, *str; + + if (encoding == NULL) + encoding = PyUnicode_GetDefaultEncoding(); + + /* Decode via the codec registry */ + buffer = PyBuffer_FromMemory((void *)s, size); + if (buffer == NULL) + goto onError; + str = PyCodec_Decode(buffer, encoding, errors); + if (str == NULL) + goto onError; + /* Convert Unicode to a string using the default encoding */ + if (PyUnicode_Check(str)) { + PyObject *temp = str; + str = PyUnicode_AsEncodedString(str, NULL, NULL); + Py_DECREF(temp); + if (str == NULL) + goto onError; + } + if (!PyString_Check(str)) { + PyErr_Format(PyExc_TypeError, + "decoder did not return an string object (type=%.400s)", + str->ob_type->tp_name); + Py_DECREF(str); + goto onError; + } + Py_DECREF(buffer); + return str; + + onError: + Py_XDECREF(buffer); + return NULL; +} + +PyObject *PyString_Encode(const char *s, + int size, + const char *encoding, + const char *errors) +{ + PyObject *v, *str; + + str = PyString_FromStringAndSize(s, size); + if (str == NULL) + return NULL; + v = PyString_AsEncodedString(str, encoding, errors); + Py_DECREF(str); + return v; +} + +PyObject *PyString_AsEncodedString(PyObject *str, + const char *encoding, + const char *errors) +{ + PyObject *v; + + if (!PyString_Check(str)) { + PyErr_BadArgument(); + goto onError; + } + + if (encoding == NULL) + encoding = PyUnicode_GetDefaultEncoding(); + + /* Encode via the codec registry */ + v = PyCodec_Encode(str, encoding, errors); + if (v == NULL) + goto onError; + /* Convert Unicode to a string using the default encoding */ + if (PyUnicode_Check(v)) { + PyObject *temp = v; + v = PyUnicode_AsEncodedString(v, NULL, NULL); + Py_DECREF(temp); + if (v == NULL) + goto onError; + } + if (!PyString_Check(v)) { + PyErr_Format(PyExc_TypeError, + "encoder did not return a string object (type=%.400s)", + v->ob_type->tp_name); + Py_DECREF(v); + goto onError; + } + return v; + + onError: + return NULL; +} + static void string_dealloc(op) PyObject *op; @@ -1686,6 +1780,25 @@ } +static char encode__doc__[] = +"S.encode([encoding[,errors]]) -> string\n\ +\n\ +Return an encoded string version of S. Default encoding is the current\n\ +default string encoding. errors may be given to set a different error\n\ +handling scheme. Default is 'strict' meaning that encoding errors raise\n\ +a ValueError. Other possible values are 'ignore' and 'replace'."; + +static PyObject * +string_encode(PyStringObject *self, PyObject *args) +{ + char *encoding = NULL; + char *errors = NULL; + if (!PyArg_ParseTuple(args, "|ss:encode", &encoding, &errors)) + return NULL; + return PyString_AsEncodedString((PyObject *)self, encoding, errors); +} + + static char expandtabs__doc__[] = "S.expandtabs([tabsize]) -> string\n\ \n\ @@ -2252,6 +2365,7 @@ {"ljust", (PyCFunction)string_ljust, 1, ljust__doc__}, {"rjust", (PyCFunction)string_rjust, 1, rjust__doc__}, {"center", (PyCFunction)string_center, 1, center__doc__}, + {"encode", (PyCFunction)string_encode, 1, encode__doc__}, {"expandtabs", (PyCFunction)string_expandtabs, 1, expandtabs__doc__}, {"splitlines", (PyCFunction)string_splitlines, 1, splitlines__doc__}, #if 0 diff -u -rbP -x *.o -x *.pyc -x Makefile -x *~ -x *.so -x add2lib -x pgen -x buildno -x core -x config.* -x libpython* -x python -x Setup -x Setup.local -x Setup.thread -x Setup.config -x hassignal -x Makefile.pre -x configure -x *.bak -x *.s -x DEADJOE -x *.rej -x *.orig -x Demo -x CVS -x Doc -x *.orig -x .#* -x distutils -x */plat* -x *.py -x ACKS -x *.txt -x README CVS-Python/Python/bltinmodule.c Python+Unicode/Python/bltinmodule.c --- CVS-Python/Python/bltinmodule.c Tue Jul 4 10:30:50 2000 +++ Python+Unicode/Python/bltinmodule.c Wed Jul 5 19:40:14 2000 @@ -2050,18 +2050,39 @@ PyObject *self; PyObject *args; { - PyObject *v; + PyObject *v, *w; + const void *buffer; + int len; + char *encoding = NULL; + char *errors = NULL; - if (!PyArg_ParseTuple(args, "O:str", &v)) + if ( !PyArg_ParseTuple(args, "O|ss:str", &v, &encoding, &errors) ) return NULL; - return PyObject_Str(v); + + /* Get string representation */ + if (PyString_Check(v)) + Py_INCREF(v); + else + v = PyObject_Str(v); + if (encoding == NULL) + return v; + + /* Decode data raw */ + if (PyObject_AsReadBuffer(v, &buffer, &len)) + return NULL; + w = PyString_Decode((const char *)buffer, len, encoding, errors); + Py_DECREF(v); + return w; } static char str_doc[] = -"str(object) -> string\n\ +"str(object [, encoding[, errors]]) -> string\n\ \n\ -Return a nice string representation of the object.\n\ -If the argument is a string, the return value is the same object."; +Return a string representation of the object.\n\ +If the argument is a string, the return value is the same object.\n\ +If encoding is given, the string representation is decoded prior\n\ +to returning it. errors, defining the error handling for the decoding\n\ +process, defaults to 'strict'."; static PyObject * From trentm at activestate.com Wed Jul 5 20:12:20 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 5 Jul 2000 11:12:20 -0700 Subject: [Python-Dev] where did the rest of my traceback go? Message-ID: <20000705111220.A10839@activestate.com> Pardon me if this is a stupid question: Python 2.0b1 (#0, Jul 4 2000, 16:47:31) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> compile('foo=', 'foo.py', 'exec') Traceback (most recent call last): File "", line 1, in ? File "", line 1 foo= ^ SyntaxError: unexpected EOF while parsing >>> import sys, traceback >>> tb = sys.last_traceback >>> traceback.print_tb(tb) File "", line 1, in ? >>> traceback.print_stack() File "", line 1, in ? >>> Where did the rest of the stack trace go (i.e. the File "" block)? Insights appreciated, Trent -- Trent Mick trentm at activestate.com From effbot at telia.com Wed Jul 5 20:37:00 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 20:37:00 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> Message-ID: <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> mal wrote: > The idea is not new: strings and Unicode should have more > or less the same methods to enhance their compatibility. > > The attached patch adds encoding capabilities to normal > strings and extends the builtin str() to accept an optional > encoding (and error) argument. It also tries to reuse the > already available Unicode codecs for the purposes of strings > (conversions are done via the default encoding in both > directions). ... > What do you think about this ? Should I add it to CVS > as experiment ? +1 on the "encode" part -0 on the "str" part (intuitively, it's -1, but I don't have any good arguments against it right now... maybe later) From mal at lemburg.com Wed Jul 5 20:51:48 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 20:51:48 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> Message-ID: <396383C4.40390E0F@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > The idea is not new: strings and Unicode should have more > > or less the same methods to enhance their compatibility. > > > > The attached patch adds encoding capabilities to normal > > strings and extends the builtin str() to accept an optional > > encoding (and error) argument. It also tries to reuse the > > already available Unicode codecs for the purposes of strings > > (conversions are done via the default encoding in both > > directions). > > ... > > > What do you think about this ? Should I add it to CVS > > as experiment ? > > +1 on the "encode" part > > -0 on the "str" part (intuitively, it's -1, but I don't have > any good arguments against it right now... maybe later) The str() extension complements unicode() which also works as constructor for object given an encoding. Ideally, unicode() should also look for __unicode__() on instances just like str() looks for __str__(). Note that we could also have a .decode() method instead of modifying str(), but this would break symmetry to Unicode, since you can't decode Unicode into anything... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Wed Jul 5 21:17:20 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 21:17:20 +0200 Subject: [Python-Dev] help wanted: windows locales Message-ID: <00fa01bfe6b5$a8400460$f2a6b5d4@hagrid> Here's a tentative version of a mapping between windows identifiers and locale codes. There's probably bugs in here; I've tried to match data from a number of sources with Microsoft's descriptions (as given in the comments). Extra bonus for filling in "??". Most notably, those norwegians caused some problems here (don't they always? ;-). I'm pretty sure one of these should be "no_NO": 0x0414: "nb_NO", # Norwegian (Bokmal) 0x0814: "nn_NO", # Norwegian (Nynorsk) But which one? Same goes for the spaniards: which one should be "es_ES"? 0x040a: "es_??", # Spanish (Traditional Sort) 0x0c0a: "es_??", # Spanish (Modern Sort) thanks /F # # Map Windows language code to ISO 3166/ISO 639 code. This is only # used on older Windows platforms (Windows 95, most notable). # # NOTE: this table isn't complete. If you have time and knowledge, # please fill in the missing mappings (marked with ??) and send to # the Python core team (or directly to effbot at telia.com). # # Thanks /F windows_lang = { 0x0436: "af_AF", # Afrikaans 0x041c: "sq_AL", # Albanian 0x0401: "ar_SA", # Arabic (Saudi Arabia) 0x0801: "ar_IQ", # Arabic (Iraq) 0x0c01: "ar_EG", # Arabic (Egypt) 0x1001: "ar_LY", # Arabic (Libya) 0x1401: "ar_DZ", # Arabic (Algeria) 0x1801: "ar_MA", # Arabic (Morocco) 0x1c01: "ar_TN", # Arabic (Tunisia) 0x2001: "ar_OM", # Arabic (Oman) 0x2401: "ar_YE", # Arabic (Yemen) 0x2801: "ar_SY", # Arabic (Syria) 0x2c01: "ar_JO", # Arabic (Jordan) 0x3001: "ar_LB", # Arabic (Lebanon) 0x3401: "ar_KW", # Arabic (Kuwait) 0x3801: "ar_AE", # Arabic (U.A.E.) 0x3c01: "ar_BH", # Arabic (Bahrain) 0x4001: "ar_QA", # Arabic (Qatar) 0x042b: "hy_AM", # Armenian 0x044d: "as_??", # Assamese 0x042c: "az_AZ", # Azeri (Latin) 0x082c: "az_??", # Azeri (Cyrillic) 0x042d: "eu_ES", # Basque 0x0423: "be_BY", # Belarussian 0x0445: "bn_??", # Bengali 0x0402: "bg_BG", # Bulgarian 0x0455: "my_MM", # Burmese 0x0403: "ca_ES", # Catalan 0x0404: "zh_TW", # Chinese (Taiwan) 0x0804: "zh_CN", # Chinese (PRC) 0x0c04: "zh_HK", # Chinese (Hong Kong SAR, PRC) 0x1004: "zh_SG", # Chinese (Singapore) 0x1404: "zh_MO", # Chinese (Macau SAR) 0x041a: "hr_HR", # Croatian (Hrvatska) 0x0405: "cs_CZ", # Czech 0x0406: "da_DK", # Danish 0x0413: "nl_NL", # Dutch (Netherlands) 0x0813: "nl_BE", # Dutch (Belgium) 0x0409: "en_US", # English (United States) 0x0809: "en_UK", # English (United Kingdom) 0x0c09: "en_AU", # English (Australian) 0x1009: "en_CA", # English (Canadian) 0x1409: "en_NZ", # English (New Zealand) 0x1809: "en_IE", # English (Ireland) 0x1c09: "en_ZA", # English (South Africa) 0x2009: "en_JM", # English (Jamaica) 0x2409: "en_??", # English (Caribbean) 0x2809: "en"_BZ, # English (Belize) 0x2c09: "en_TT", # English (Trinidad) 0x3009: "en_ZW", # English (Zimbabwe) 0x3409: "en_PH", # English (Philippines) 0x0425: "et_EE", # Estonian 0x0438: "fo_FO", # Faeroese 0x0429: "fa_IR", # Farsi 0x040b: "fi_FI", # Finnish 0x040c: "fr_FR", # French (Standard) 0x080c: "fr_BE", # French (Belgian) 0x0c0c: "fr_CA", # French (Canadian) 0x100c: "fr_CH", # French (Switzerland) 0x140c: "fr_LU", # French (Luxembourg) 0x180c: "fr_MC", # French (Monaco) 0x0437: "ka_GE", # Georgian 0x0407: "de_DE", # German (Standard) 0x0807: "de_CH", # German (Switzerland) 0x0c07: "de_AT", # German (Austria) 0x1007: "de_LU", # German (Luxembourg) 0x1407: "de_LI", # German (Liechtenstein) 0x0408: "el_GR", # Greek 0x0447: "gu_??", # Gujarati 0x040d: "iw_IL", # Hebrew 0x0439: "hi_IN", # Hindi 0x040e: "hu_HU", # Hungarian 0x040f: "is_IS", # Icelandic 0x0421: "id_ID", # Indonesian 0x0410: "it_IT", # Italian (Standard) 0x0810: "it_CH", # Italian (Switzerland) 0x0411: "ja_JA", # Japanese 0x044b: "kn_??", # Kannada 0x0860: "ks_IN", # Kashmiri (India) 0x043f: "kk_??", # Kazakh 0x0457: "??_??", # Konkani 0x0412: "ko_??", # Korean 0x0812: "ko_??", # Korean (Johab) 0x0426: "lv_LV", # Latvian 0x0427: "lt_LT", # Lithuanian 0x0827: "lt_??", # Lithuanian (Classic) 0x042f: "mk_MK", # Macedonian 0x043e: "ms_MY", # Malay (Malaysian) 0x083e: "ms_??", # Malay (Brunei Darussalam) 0x044c: "ml_??", # Malayalam 0x0458: "??_??", # Manipuri 0x044e: "mr_??", # Marathi 0x0861: "ne_IN", # Nepali (India) 0x0414: "nb_NO", # Norwegian (Bokmal) 0x0814: "nn_NO", # Norwegian (Nynorsk) 0x0448: "or_??", # Oriya 0x0415: "pl_PL", # Polish 0x0416: "pt_BR", # Portuguese (Brazil) 0x0816: "pt_PT", # Portuguese (Standard) 0x0446: "pa_??", # Punjabi 0x0418: "ro_RO", # Romanian 0x0419: "ru_RU", # Russian 0x044f: "sa_??", # Sanskrit 0x0c1a: "sr_??", # Serbian (Cyrillic) 0x081a: "sr_??", # Serbian (Latin) 0x0459: "sd_??", # Sindhi 0x041b: "sk_??", # Slovak 0x0424: "sl_SL", # Slovenian 0x040a: "es_??", # Spanish (Traditional Sort) 0x080a: "es_MX", # Spanish (Mexican) 0x0c0a: "es_??", # Spanish (Modern Sort) 0x100a: "es_GT", # Spanish (Guatemala) 0x140a: "es_??", # Spanish (Costa Rica) 0x180a: "es_PA", # Spanish (Panama) 0x1c0a: "es_DO", # Spanish (Dominican Republic) 0x200a: "es_VE", # Spanish (Venezuela) 0x240a: "es_CO", # Spanish (Colombia) 0x280a: "es_PE", # Spanish (Peru) 0x2c0a: "es_AR", # Spanish (Argentina) 0x300a: "es_EC", # Spanish (Ecuador) 0x340a: "es_CL", # Spanish (Chile) 0x380a: "es_UY", # Spanish (Uruguay) 0x3c0a: "es_PY", # Spanish (Paraguay) 0x400a: "es_BO", # Spanish (Bolivia) 0x440a: "es_SV", # Spanish (El Salvador) 0x480a: "es_HN", # Spanish (Honduras) 0x4c0a: "es_NI", # Spanish (Nicaragua) 0x500a: "es_PR", # Spanish (Puerto Rico) 0x0430: "??_??", # Sutu 0x0441: "sw_KE", # Swahili (Kenya) 0x041d: "sv_SE", # Swedish 0x081d: "sv_FI", # Swedish (Finland) 0x0449: "ta_??", # Tamil 0x0444: "tt_??", # Tatar (Tatarstan) 0x044a: "te_??", # Telugu 0x041e: "th_TH", # Thai 0x041f: "tr_TR", # Turkish 0x0422: "tk_UA", # Ukrainian 0x0420: "ur_PK", # Urdu (Pakistan) 0x0820: "ur_IN", # Urdu (India) 0x0443: "uz_UZ", # Uzbek (Latin) 0x0843: "uz_??", # Uzbek (Cyrillic) 0x042a: "vi_VN", # Vietnamese } From pingster at ilm.com Wed Jul 5 21:20:41 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 5 Jul 2000 12:20:41 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <200007051229.OAA19526@python.inrialpes.fr> Message-ID: On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > Looks fine. +1 on the concept. Yay! > > SyntaxError: expected indent here > > I'd remove the word "here" so that the error msg is self-contained. > "expected indent" & "expected dedent" are fine. Fine with me (more on messages below). > > 4. Added int *expected_ret argument to PyParser_AddToken; on > > a syntax error, PyParser_AddToken (in parser.c) places the > > expected token type (if any) into this output parameter. > > I'd suggest passing a pointer to the perrdetail structure (to the > whole error, that is), instead of a pointer to one of its fields. I did consider that; the reason i eventually decided against it is that munging perrdetail appears to be [parsetok.c] parsetok()'s responsibility, not [parser.c] PyParser_AddToken()'s. The latter doesn't mess with any of the other fields of perrdetail -- and it returns an error code which becomes err_ret->error, so passing in perrdetail gives PyParser_AddToken() two ways of returning the same information. The redundancy and possible future confusion didn't seem worth it. Another alternative is to change the return value so it *isn't* an error code (only a success/fail flag) and then rely on the error code in err_ret->error. I guess if you see a compelling reason for this i don't mind doing it. But is there one? Greg Wilson wrote: > I just did a poll --- only 2 out of 5 programmers in my shouting radius > know what "dedent" means. Is there a more accessible way to phrase the > error message? Indeed. Sorry about that -- i should have realized that it's a fairly cryptic term. "Dedent" seems to have become a standard term within the C code; perhaps we can allow "dedent" in the C code and standardize on "unindent" outside? How about this set of messages, then: SyntaxError: unexpected indent SyntaxError: unexpected unindent SyntaxError: expected indent SyntaxError: expected unindent SyntaxError: unindent did not match any outer indentation level SyntaxError: inconsistent use of tabs and spaces in indentation SyntaxError: too many levels of indentation Hmm. For the record, the section of the reference manual about indentation talks about INDENT and DEDENT tokens. In fact i don't think there's any mention of the word "unindent" in the Python documentation. But outside of the Python docs, "unindent" is clearly a commonly used and understood term in general practice, much more so than "dedent". -- ?!ng From effbot at telia.com Wed Jul 5 21:52:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 21:52:23 +0200 Subject: [Python-Dev] Making -tt the default References: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: <01ac01bfe6ba$8c1ed680$f2a6b5d4@hagrid> fred wrote: > There are two things that can be done: have distutils always use > -tt when compiling code that gets installed (using a child interpreter > if needed), that's reasonable. > and setting -tt as the default in the next Python release. where "next" is Py3K, I hope. breaking an unknown amount of existing libraries and code samples, just for the sake of it, isn't exactly a great way to promote Python... From effbot at telia.com Wed Jul 5 21:56:09 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 21:56:09 +0200 Subject: [Python-Dev] Spelling check: more typos References: <20000705060943.A18539@thyrsus.com> <20000705062434.A18614@thyrsus.com> Message-ID: <01f001bfe6bb$5198bb60$f2a6b5d4@hagrid> eric wrote: > > > Tim's source is correct. > > > > Tim? Do you mean /F? > > I believe /F was quoting Tim. nope. not that it matters much; that economist style guide seem to override it anyway ;-) From martin at loewis.home.cs.tu-berlin.de Wed Jul 5 22:25:17 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed, 5 Jul 2000 22:25:17 +0200 Subject: [Python-Dev] help wanted: windows locales Message-ID: <200007052025.WAA01309@loewis.home.cs.tu-berlin.de> > I'm pretty sure one of these should be "no_NO": > 0x0414: "nb_NO", # Norwegian (Bokmal) > 0x0814: "nn_NO", # Norwegian (Nynorsk) > But which one? Looking at http://lcweb.loc.gov/standards/iso639-2/englangn.html, it seems the answer is "neither". I believe "no_NO" is used for traditional Norwegian on many systems (that would be Bokm?l, right?). On a number of Unix systems (Linux, Solaris), Nynorsk is requested by appending "@nynorsk" to $LANG, e.g. no at nynorsk (Linux), no_NO.ISO8859-1 at nynorsk (Solaris). The latter also recognizes no_NY for Nynorsk, but that doesn't sound too official. It seems that ISO 639-2:1998 isn't that widely implemented; is anybody actually using nn/nb? Regards, Martin From gstein at lyra.org Wed Jul 5 22:42:30 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 5 Jul 2000 13:42:30 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14691.8786.180085.468266@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 05, 2000 at 07:56:02AM -0400 References: <20000703233938.N29590@lyra.org> <14691.8786.180085.468266@anthem.concentric.net> Message-ID: <20000705134230.C12873@lyra.org> On Wed, Jul 05, 2000 at 07:56:02AM -0400, Barry A. Warsaw wrote: > >>>>> "GS" == Greg Stein writes: > GS> (add-hook 'python-mode-hook > | (lambda () > | (setq indent-tabs-mode nil) > | (setq py-indent-offset 2) > | (setq py-smart-indentation nil) > | (define-key py-mode-map "\e\C-h" 'backward-kill-word) > | )) > > GS> The indent-tabs-mode is the key to disabling tab characters > GS> and using just spaces. > > Greg, can you explain why you turn off py-smart-indentation? Its > purpose is to give you the correct settings when editing someone > else's existing code. With this variable set to t, it tries to guess > the existing code's indentation level depth and then sets > py-indent-offset to that value, on the assumption that > > 1) the original author indented their code consistently > > 2) it is better to be consistent with the existing indentation than > impose your own and have mixed indentation > > Both of these are worthy goals, IMO, so py-smart-indentation should > generally remain true. The goal is fine, and I agree with it. However, it was guessing the wrong tab for me at some point, and so I just turned it off. That's the way I have it; other people probably don't want to do that. *shrug* Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw at beopen.com Wed Jul 5 22:48:41 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 16:48:41 -0400 (EDT) Subject: [Python-Dev] Making -tt the default References: <20000703233938.N29590@lyra.org> <14691.8786.180085.468266@anthem.concentric.net> <20000705134230.C12873@lyra.org> Message-ID: <14691.40745.724265.337058@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> The goal is fine, and I agree with it. However, it was GS> guessing the wrong tab for me at some point, and so I just GS> turned it off. GS> That's the way I have it; other people probably don't want to GS> do that. No problem, 'cause you're already setting indent-tabs-mode in your hook. -Barry From jack at oratrix.nl Wed Jul 5 22:53:26 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 05 Jul 2000 22:53:26 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c Message-ID: <20000705205331.E8BCDE2673@oratrix.oratrix.nl> Is anyone else experiencing problems with the immense new switch in unicodectype.c? Trying to compile it crashes my machine(!)... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From mal at lemburg.com Wed Jul 5 23:09:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 23:09:53 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <20000705205331.E8BCDE2673@oratrix.oratrix.nl> Message-ID: <3963A421.35A7F989@lemburg.com> Jack Jansen wrote: > > Is anyone else experiencing problems with the immense new switch in > unicodectype.c? Trying to compile it crashes my machine(!)... It compiles fine on my Linux machine using gcc. The output is a 114k .o file (including debug information). Do you have similar problems with ceval.c ? If yes, I could break the switch in two using the same flag as in ceval.c. If not, please give some compiler details, so that I can switch on those. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Wed Jul 5 23:42:37 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 17:42:37 -0400 Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <20000705205331.E8BCDE2673@oratrix.oratrix.nl> Message-ID: [posted & mailed] [Jack Jansen] > Is anyone else experiencing problems with the immense new switch in > unicodectype.c? Trying to compile it crashes my machine(!)... No problem here, but it needs to be fixed for you! There's no future in pushing anyone's compiler limits, and particularly not when Python is attracting more attention on smaller platforms (read feebler compilers, among others gotchas). I believe we also need a way to split unicodedatabase.c into multiple files, as > 64K lines in a source file is unreasonable (Python can't handle a source file that large either, and Python is the *definition* of reasonableness here ), and the MS compiler spits out a warning about its sheer size. Or was Christian's long-threatened compression patch supposed to reduce the line count in that one? From effbot at telia.com Thu Jul 6 00:13:46 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 00:13:46 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: Message-ID: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> tim wrote: > [Jack Jansen] > > Is anyone else experiencing problems with the immense new switch in > > unicodectype.c? Trying to compile it crashes my machine(!)... > > No problem here, but it needs to be fixed for you! There's no future in > pushing anyone's compiler limits, and particularly not when Python is > attracting more attention on smaller platforms (read feebler compilers, > among others gotchas). both modules can be squeezed down to almost nothing. it just takes a little work. fwiw, Tcl's version of the unicodectype file is about 30k, and compiles to an 8k large object file on my win95 box. if nobody else fixes this, I'll do something about it before 2.0 final. promise. cheers /F From mal at lemburg.com Thu Jul 6 00:19:38 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 00:19:38 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: Message-ID: <3963B47A.638A7A82@lemburg.com> Tim Peters wrote: > > [posted & mailed] > > [Jack Jansen] > > Is anyone else experiencing problems with the immense new switch in > > unicodectype.c? Trying to compile it crashes my machine(!)... > > No problem here, but it needs to be fixed for you! There's no future in > pushing anyone's compiler limits, and particularly not when Python is > attracting more attention on smaller platforms (read feebler compilers, > among others gotchas). > > I believe we also need a way to split unicodedatabase.c into multiple files, > as > 64K lines in a source file is unreasonable (Python can't handle a > source file that large either, and Python is the *definition* of > reasonableness here ), and the MS compiler spits out a warning about > its sheer size. > > Or was Christian's long-threatened compression patch supposed to reduce the > line count in that one? Both the line count and the memory consumption... the same can be done for unicodectype.c -- but I don't have the time to look into this, so for now all I can offer is to split the huge switch in two if that helps. BTW, if your compiler supports Unicode (that is provides a working wctype.h file), you can compile Python using the compile time switch --with-wctype-functions. Python will then use the C libs iswXXX() APIs which should return more or less the same values as the Python ones (could be that the C lib is Unicode 2.0 -- so YMMV). Note that this hasn't been tested much yet. Feedback is welcome. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gward at mems-exchange.org Thu Jul 6 00:30:46 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 18:30:46 -0400 Subject: [Python-Dev] ExtensionClass and __radd__()? Message-ID: <20000705183046.A26381@ludwig.cnri.reston.va.us> Hi all -- looks like ExtensionClass doesn't recognize/implement the '__radd__()' protocol. Speculation below; first, a demonstration. Normal case: a regular class Number that knows how to add itself to other number-like things: class Number: def __init__ (self, n): self.n = n def __str__ (self): return str(self.n) def __add__ (self, other): return self.n + other __radd__ = __add__ n = Number(37) print n, n + 5, 5 + n The output of this is exactly what you'd expect: 37 42 42 (I have convinced myself that '__radd__()' is called in the "5 + n" case by writing a separate '__radd__()' with a print statement. Everything is sane!) Now the same thing as an ExtensionClass: from ExtensionClass import Base class ECNumber (Base): def __init__ (self, n): self.n = n def __str__ (self): return str(self.n) def __add__ (self, other): return self.n + other __radd__ = __add__ ecn = ECNumber(37) print ecn, ecn + 5, 5 + ecn The output of this is puzzling, to say the least: 37 42 134883149 IOW, "5 + ecn" evaluates to 134883149 -- that's a plain int, I checked with 'type()' on it. If I put this code: print id(ecn), id(5), id(ECNumber), id(Base), id(ExtensionClass) immediately after the last print, I get 135530536 135220848 135568720 1075195712 1075195488 ... which just tells me that the result of "5 + ecn" looks a lot like an id(), but isn't the id() of anything obvious. (Or 5 + any obvious id().) Happens the same with the ExtensionClass code from Zope 2.1.5 or 2.2beta1, and with Python 1.5.2 and the latest CVS Python. Speculation time: I'm guessing that this is similar to the problem with 'isinstance()' and ExtensionClass that I found several months ago, which was heroically debugged by Barry. To recap, it's a mutual finger-pointing bug: Python (Guido) can claim that it's up to ExtensionClass (Jim) to emulate the full semantics of Python classes/instances, but ExtensionClass can claim that Python should be more relaxed in what it accepts as a "class object" or "instance object". I think the relevant code in Python is in Objects/abstract.c, specifically 'PyNumber_Add()' and the BINOP macro: #define BINOP(v, w, opname, ropname, thisfunc) \ if (PyInstance_Check(v) || PyInstance_Check(w)) \ return PyInstance_DoBinOp(v, w, opname, ropname, thisfunc) [...] PyNumber_Add(v, w) PyObject *v, *w; { PySequenceMethods *m; BINOP(v, w, "__add__", "__radd__", PyNumber_Add); [...] My guess is that PyInstance_Check() returns false for ExtensionClass instances. Two possible fixes: loosen up PyInstance_Check(), or loosen up BINOP. Well, it's a nice theory. It doesn't explain why '__add__()' works for ExtensionClass while '__radd__()' does not; perhaps ExtensionClass implements that much of Python's class semantics, but doesn't go as far as '__radd__()'. Other opinions? Greg From gward at mems-exchange.org Thu Jul 6 00:33:53 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 18:33:53 -0400 Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: ; from pingster@ilm.com on Wed, Jul 05, 2000 at 12:20:41PM -0700 References: <200007051229.OAA19526@python.inrialpes.fr> Message-ID: <20000705183353.B7564@ludwig.cnri.reston.va.us> On 05 July 2000, Ka-Ping Yee said: > How about this set of messages, then: > > SyntaxError: unexpected indent > SyntaxError: unexpected unindent How about "did not expect indent" and "did not expect unindent" -- reads a little easier to my eyes. > SyntaxError: expected indent > SyntaxError: expected unindent > SyntaxError: unindent did not match any outer indentation level > SyntaxError: inconsistent use of tabs and spaces in indentation > SyntaxError: too many levels of indentation Good. > Hmm. For the record, the section of the reference manual about > indentation talks about INDENT and DEDENT tokens. In fact i don't > think there's any mention of the word "unindent" in the Python > documentation. But outside of the Python docs, "unindent" is > clearly a commonly used and understood term in general practice, > much more so than "dedent". I don't think too many newbies read the reference manual (or the parser source, for that matter). Stick to clear, simple, plain-English terms in error messages, even if they are different from (not inconsistent with!) what's in the formal docs. Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From gward at mems-exchange.org Thu Jul 6 00:45:48 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 18:45:48 -0400 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <018a01bfe59f$da814950$0900a8c0@SPIFF>; from fredrik@pythonware.com on Tue, Jul 04, 2000 at 12:08:50PM +0200 References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> Message-ID: <20000705184548.C7564@ludwig.cnri.reston.va.us> On 04 July 2000, Fredrik Lundh said: > > to Python.h. This enables all features available for the > > gcc compiler including _XOPEN_SOURCE and fixes warnings > > related to missing prototypes. > > > > Thoughts ? Would this hurt anybody ? > > what does "fixes warnings" mean? does it change the compiler's > behaviour, or does it just make sure stuff are defined in the right > files? Just like MAL said, it fixes warnings from missing prototypes. Eg. the (I think) on Linux (glibc 2.x, at least) doesn't declare 'strptime()' unless __USE_XOPEN is true. (__USE_XOPEN is defined if _XOPEN_SOURCE is defined, by .) > +1 on _XOPEN_SOURCE > +0 on _GNU_SOURCE Agreed, unless someone can explain a) what _GNU_SOURCE adds that _XOPEN_SOURCE does not, and b) why that's necessary (if so). Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From mal at lemburg.com Thu Jul 6 00:53:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 00:53:08 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <20000705184548.C7564@ludwig.cnri.reston.va.us> Message-ID: <3963BC54.5B49AD72@lemburg.com> Greg Ward wrote: > > On 04 July 2000, Fredrik Lundh said: > > > to Python.h. This enables all features available for the > > > gcc compiler including _XOPEN_SOURCE and fixes warnings > > > related to missing prototypes. > > > > > > Thoughts ? Would this hurt anybody ? > > > > what does "fixes warnings" mean? does it change the compiler's > > behaviour, or does it just make sure stuff are defined in the right > > files? > > Just like MAL said, it fixes warnings from missing prototypes. Eg. the > (I think) on Linux (glibc 2.x, at least) doesn't declare > 'strptime()' unless __USE_XOPEN is true. (__USE_XOPEN is defined if > _XOPEN_SOURCE is defined, by .) > > > +1 on _XOPEN_SOURCE > > +0 on _GNU_SOURCE > > Agreed, unless someone can explain a) what _GNU_SOURCE adds that > _XOPEN_SOURCE does not, and b) why that's necessary (if so). It's already checked in, but since you asked: _GNU_SOURCE defines one symbol which is essential on Linux to get at a bunch of BSD/SysV API prototypes which _XOPEN_SOURCE doesn't activate. Time support is one area where this is needed, I found tmpnam_r() to be another one. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Thu Jul 6 01:00:33 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 18:00:33 -0500 (CDT) Subject: [Python-Dev] dismantle CVS repository on cvs.python.org? Message-ID: <14691.48657.899199.497977@beluga.mojam.com> Is it time to disable anonymous CVS access from cvs.python.org? On one of my machines I was still referring to it, but only noticed today because the build still said "1.6...". Best would be if there was some way to get it to spit out an error message that referred people to either the python.org web site or the SourceForge repository web site. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From guido at beopen.com Thu Jul 6 02:15:13 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 19:15:13 -0500 Subject: [Python-Dev] dismantle CVS repository on cvs.python.org? In-Reply-To: Your message of "Wed, 05 Jul 2000 18:00:33 EST." <14691.48657.899199.497977@beluga.mojam.com> References: <14691.48657.899199.497977@beluga.mojam.com> Message-ID: <200007060015.TAA06841@cj20424-a.reston1.va.home.com> > Is it time to disable anonymous CVS access from cvs.python.org? On one of > my machines I was still referring to it, but only noticed today because the > build still said "1.6...". Best would be if there was some way to get it to > spit out an error message that referred people to either the python.org web > site or the SourceForge repository web site. Yes -- it was left on by mistake. However CNRI currently doesn't let us modify the python.org site. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Thu Jul 6 01:15:39 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 18:15:39 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... Message-ID: <14691.49563.78765.683762@beluga.mojam.com> Was there a public announcement made about new functionality for 2.0? I had submitted list comprehensions to the old 1.6 cycle, and it was being held to the now never-to-be 1.7. Are we in feature freeze for 2.0 at this point? I can do one of three things: * commit the changes I have currently against the CVS repository * bundle up another patch for people to examine and comment on * shut up and go do something more useful Skip From skip at mojam.com Thu Jul 6 01:18:51 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 18:18:51 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? Message-ID: <14691.49755.365679.923078@beluga.mojam.com> Along the same lines, I have some pretty simple mods to readline.c and rlcompleter.py that use atexit to automatically save the current history to the file identified by the PYTHONHISTORY environment variable. (If unset, no history read/write is done). If we aren't in feature freeze, I'd like to check it in. Skip From effbot at telia.com Thu Jul 6 01:27:13 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 01:27:13 +0200 Subject: [Python-Dev] list comprehensions again... References: <14691.49563.78765.683762@beluga.mojam.com> Message-ID: <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> skip wrote: > Are we in feature freeze for 2.0 at this point? hopefully. > I can do one of three things: > > * commit the changes I have currently against the CVS repository > > * bundle up another patch for people to examine and comment on I'd vote for the second alternative. > * shut up and go do something more useful nope. that's what I'm going to do. cheers /F From jeremy at beopen.com Thu Jul 6 01:41:05 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 5 Jul 2000 19:41:05 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14691.49563.78765.683762@beluga.mojam.com> References: <14691.49563.78765.683762@beluga.mojam.com> Message-ID: <14691.51089.280721.161530@bitdiddle.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> Was there a public announcement made about new functionality for SM> 2.0? I had submitted list comprehensions to the old 1.6 cycle, SM> and it was being held to the now never-to-be 1.7. Are we in SM> feature freeze for 2.0 at this point? SM> I can do one of three things: SM> * commit the changes I have currently against the CVS SM> repository SM> * bundle up another patch for people to examine and comment SM> on SM> * shut up and go do something more useful At lunch today, Guido raised almost the same question! Tim and I argued that we should continue the feature freeze, and spend any extra time wasted while we wait for CNRI to quit stalling to resolve open bugs and do more testing. It's been a long time since the last bug fix release, and there are already a lot of new features. We'd probably be best served by working hard to make 2.0 stable and solid -- and then getting 2.1 released quickly. Jeremy From guido at beopen.com Thu Jul 6 02:42:24 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 19:42:24 -0500 Subject: [Python-Dev] list comprehensions again... In-Reply-To: Your message of "Wed, 05 Jul 2000 18:15:39 EST." <14691.49563.78765.683762@beluga.mojam.com> References: <14691.49563.78765.683762@beluga.mojam.com> Message-ID: <200007060042.TAA06919@cj20424-a.reston1.va.home.com> > Was there a public announcement made about new functionality for > 2.0? Yes, there's something on http://pythonlabs.com/tech/python2.html. We currently can't commit to a release schedule due to the problems with CNRI. > I had > submitted list comprehensions to the old 1.6 cycle, and it was being held to > the now never-to-be 1.7. Are we in feature freeze for 2.0 at this point? That's up for debate. Reversing our usual good-cop-bad-cop roles, Tim Peters is for a feature freeze while I am for adding more features to 2.0 to make it stand apart. :-) > I can do one of three things: > > * commit the changes I have currently against the CVS repository > > * bundle up another patch for people to examine and comment on > > * shut up and go do something more useful It's not wise to commit changes without agreement on whether they should be applied... Anyway, the patches are currently in Tim Peters' court. Are your changes different from what's already in the patch manager for list comprehensions? If so, you should probably upload a revised patch... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Thu Jul 6 02:44:15 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 19:44:15 -0500 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: Your message of "Wed, 05 Jul 2000 18:18:51 EST." <14691.49755.365679.923078@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> Message-ID: <200007060044.TAA08483@cj20424-a.reston1.va.home.com> > Along the same lines, I have some pretty simple mods to readline.c and > rlcompleter.py that use atexit to automatically save the current history to > the file identified by the PYTHONHISTORY environment variable. (If unset, > no history read/write is done). If we aren't in feature freeze, I'd like to > check it in. To ease review of the patch, why don't you upload it? Does the patch also load the history at start time? That would be useful... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gward at mems-exchange.org Thu Jul 6 02:00:44 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 20:00:44 -0400 Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <14690.56733.627266.907044@temoleh.chem.uu.nl>; from rob@hooft.net on Wed, Jul 05, 2000 at 09:02:53AM +0200 References: <14690.56733.627266.907044@temoleh.chem.uu.nl> Message-ID: <20000705200043.D7564@ludwig.cnri.reston.va.us> On 05 July 2000, Rob W. W. Hooft said: > Then 2 points on distutils: > - the word "licence" is used throughout, and "license" is introduced as > alternative. The other way around looks more natural to me. In American English, "license" is both noun and verb. In the rest of the world, "licence" is the noun and "license" the verb. Hence, I might license you to use my software with the GNU General Public Licence. (Except that the FSF is American, so they don't use "licence". Oops.) Alternately: when I moved to the US, I traded in my Canadian driver's licence for an American license. (Except that I lived in Quebec, and had a permis de conduire. Oops again!) I am not American, so I do not use American English in source code or documentation, and strive to avoid it in everyday speech. ;-) If an overwhelming majority insists on American spellings in source code, command-line options, documentation, and the like, then I *might* give in, but only reluctantly. There is more than one way to use the English language, and just because the most populous (and richest, and most heavily-armed, etc.) English-speaking nation does it one way doesn't mean we should all do it that way. Bottom line: when used as a noun, "licence" and "license" should be accepted equally. This is currently the case on the Distutils command-line, but I'm not sure if it holds in the setup script. Will check. > - the term "anal retentives" should probably be replaced before 2.0 Oh c'mon, if it's just in *comments* is anyone really going to be offended? Where is it, anyways? Anyways, why is the guy who combs the source code looking for spelling errors complaining about the use of "anal retentive"? Perhaps it cuts a little close to home? >evil grin< (Sorry, that was uncalled for -- but irresistable. Nothing personal, of course!) Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From fdrake at beopen.com Thu Jul 6 02:21:14 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 20:21:14 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14691.49755.365679.923078@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> Message-ID: <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > Along the same lines, I have some pretty simple mods to readline.c and > rlcompleter.py that use atexit to automatically save the current history to > the file identified by the PYTHONHISTORY environment variable. (If unset, Skip, "bash" doesn't make me set a variable to control saving of history to ~/.bash_history; I'd be perfectly happy if Python wrote ~/.python_history by default, and simply allowed me to turn it off somehow (either from my $PYTHONSTARTUP script or a separate environment variable). There should be a reasonable default size to the history (say, 2000 lines ;), and a way to set that as well. Perhaps this is reasonable: in rlcompleter (or whereever this stuff goes), have a variable history_size that is set based on $PYTHONHISTORYSIZE if set, or 2000 if not. If the variable is set to 0, there is no history saving (or loading), and non-numeric values (like "true" ;) mean "use the default" (which is at least 2000 ;). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jul 6 02:27:20 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 20:27:20 -0400 (EDT) Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <20000705200043.D7564@ludwig.cnri.reston.va.us> References: <14690.56733.627266.907044@temoleh.chem.uu.nl> <20000705200043.D7564@ludwig.cnri.reston.va.us> Message-ID: <14691.53864.55446.173589@cj42289-a.reston1.va.home.com> Greg Ward writes: > Bottom line: when used as a noun, "licence" and "license" should be > accepted equally. This is currently the case on the Distutils > command-line, but I'm not sure if it holds in the setup script. Will If it's a keyword parameter, use it with exactly one spelling and document it that way. If packagers can't read the distutils documentation, too bad. I'll hold my comments on which is the right way to spell "license". ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Thu Jul 6 03:48:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 20:48:29 -0500 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: Your message of "Wed, 05 Jul 2000 20:21:14 -0400." <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> Message-ID: <200007060148.UAA10852@cj20424-a.reston1.va.home.com> > Skip Montanaro writes: > > Along the same lines, I have some pretty simple mods to readline.c and > > rlcompleter.py that use atexit to automatically save the current history to > > the file identified by the PYTHONHISTORY environment variable. (If unset, [Fred] > Skip, > "bash" doesn't make me set a variable to control saving of history > to ~/.bash_history; I'd be perfectly happy if Python wrote > ~/.python_history by default, and simply allowed me to turn it off > somehow (either from my $PYTHONSTARTUP script or a separate > environment variable). There should be a reasonable default size to > the history (say, 2000 lines ;), and a way to set that as well. > Perhaps this is reasonable: in rlcompleter (or whereever this stuff > goes), have a variable history_size that is set based on > $PYTHONHISTORYSIZE if set, or 2000 if not. If the variable is set to > 0, there is no history saving (or loading), and non-numeric values > (like "true" ;) mean "use the default" (which is at least 2000 ;). On the other hand, bash reads .profile and .bashrc and a few other files by default, while Python reads such a file only when $PYTHONSTARTUP is set. I actually like this. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Thu Jul 6 03:04:41 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 21:04:41 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060148.UAA10852@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> <200007060148.UAA10852@cj20424-a.reston1.va.home.com> Message-ID: <14691.56105.43228.613238@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > On the other hand, bash reads .profile and .bashrc and a few other > files by default, while Python reads such a file only when > $PYTHONSTARTUP is set. I actually like this. Fair enough, though I'd be happy to change that as well. :) So perhaps $PYTHONHISTORY should specify the file name, and the filename and size can also be set from the $PYTHONSTARTUP script if desired, and a function call can be made to load the history? I'd prefer to *only* need to add a line or two to my $PYTHONSTARTUP script, and not set yet more environment variables, if at all possible. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Thu Jul 6 01:57:29 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 18:57:29 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007060042.TAA06919@cj20424-a.reston1.va.home.com> References: <14691.49563.78765.683762@beluga.mojam.com> <200007060042.TAA06919@cj20424-a.reston1.va.home.com> Message-ID: <14691.52073.836046.104252@beluga.mojam.com> Guido> Are your changes different from what's already in the patch Guido> manager for list comprehensions? If so, you should probably Guido> upload a revised patch... Nope. I only remembered them today when I executed "cvs update" and saw all those "M"s... Skip From tim_one at email.msn.com Thu Jul 6 03:27:48 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 21:27:48 -0400 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack Message-ID: Twice in ceval.c, and once in object.c, there's code referencing PyOS_CheckStack under the control of the preprocessor symbol USE_STACKCHECK. There's nothing in the std distribution that could possibly define either of those names. Why are they there? If nobody objects, I'll get rid of this code! PS for Jeremy: the mechanism I was thinking of is _ts.recursion_depth, which is used cross-platform in ceval.c, like so: if (++tstate->recursion_depth > MAX_RECURSION_DEPTH) { --tstate->recursion_depth; PyErr_SetString(PyExc_RuntimeError, "Maximum recursion depth exceeded"); tstate->frame = f->f_back; Py_DECREF(f); return NULL; } The effectiveness of this is dependent on guessing a good value (per platform) for MAX_RECURSION_DEPTH (and it's broken under Windows in 1.5.2). From skip at mojam.com Thu Jul 6 01:58:55 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 18:58:55 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060044.TAA08483@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <200007060044.TAA08483@cj20424-a.reston1.va.home.com> Message-ID: <14691.52159.562929.565934@beluga.mojam.com> Guido> To ease review of the patch, why don't you upload it? Will do. Guido> Does the patch also load the history at start time? That would Guido> be useful... That's the whole idea... ;-) Skip From tim_one at email.msn.com Thu Jul 6 03:37:11 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 21:37:11 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007060042.TAA06919@cj20424-a.reston1.va.home.com> Message-ID: Oh, all right, I'll address this now: > It's not wise to commit changes without agreement on whether they > should be applied... Anyway, the patches are currently in Tim Peters' > court. I think that speaks for itself: immediately after ESR praised Guido's impeccable English, Guido goes and violates the Economist's style guide by not spelling that Tim Peters's court as I and all right-thinking singular grammarians would have done. I grew up in the Peters' house along with the rest of the Peters family, but if I ever get an apartment here it will be Peters's. glad-to-have-settled-*that*-one-ly y'rs - tim From guido at beopen.com Thu Jul 6 05:00:18 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 22:00:18 -0500 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack In-Reply-To: Your message of "Wed, 05 Jul 2000 21:27:48 -0400." References: Message-ID: <200007060300.WAA11066@cj20424-a.reston1.va.home.com> > Twice in ceval.c, and once in object.c, there's code referencing > PyOS_CheckStack under the control of the preprocessor symbol USE_STACKCHECK. > There's nothing in the std distribution that could possibly define either of > those names. Why are they there? If nobody objects, I'll get rid of this > code! They are there for the Mac code, which has its own config.h. The Mac distribution is maintained separately by Jack Jansen. There are occasional compromises in the main source code for the Mac port, and this is one. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Thu Jul 6 02:42:13 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 19:42:13 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060044.TAA08483@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <200007060044.TAA08483@cj20424-a.reston1.va.home.com> Message-ID: <14691.54757.459091.820551@beluga.mojam.com> >> Along the same lines, I have some pretty simple mods to readline.c and >> rlcompleter.py ... Guido> To ease review of the patch, why don't you upload it? Done. It's available for review at https://sourceforge.net/patch/?func=detailpatch&patch_id=100742&group_id=5470 Skip From tim_one at email.msn.com Thu Jul 6 04:14:39 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 22:14:39 -0400 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack In-Reply-To: <200007060300.WAA11066@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > They are there for the Mac code, which has its own config.h. The Mac > distribution is maintained separately by Jack Jansen. There are > occasional compromises in the main source code for the Mac port, and > this is one. Then I would like to a) Add comments to the #ifdef's saying they're for the Mac. "Mystery code" is bad in group-maintained software. I expect Jack will maintain that it isn't really Mac-specific, but a wonderful feature for any platform that cares to #define USE_STACKCHECK and PyOS_CheckStack. Then I preemptively sneer in his general direction . b) Wonder out loud why this code is useful on a Mac but not other platforms. We can get segfaulting recursion while print'ing and repr'ing on all platforms. So shouldn't we work to catch that on all platforms too? Macs shouldn't be something special wrt this. From skip at mojam.com Thu Jul 6 02:48:19 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 19:48:19 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> Message-ID: <14691.55123.961759.456729@beluga.mojam.com> Fred> "bash" doesn't make me set a variable to control saving of history Fred> to ~/.bash_history; I'd be perfectly happy if Python wrote Fred> ~/.python_history by default ... Fred, I was just following the trend established with PYTHONSTARTUP. It appears Guido did it that way on purpose... It doesn't much matter to me, though I wonder how system-dependent the code might get if you needed it to be available across multiple platforms. Unix, Windows and Mac all have different (sometimes nonexistent) notions of HOME, so it would be difficult to implement one mechanism that worked in a foolproof way. As for limiting the number of lines read or written (where should the truncation take place?), I'll gladly add a size parameter to either read_history or write_history if the underlying readline functions support the capability. Skip From gstein at lyra.org Thu Jul 6 04:27:21 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 5 Jul 2000 19:27:21 -0700 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14691.49755.365679.923078@beluga.mojam.com>; from skip@mojam.com on Wed, Jul 05, 2000 at 06:18:51PM -0500 References: <14691.49755.365679.923078@beluga.mojam.com> Message-ID: <20000705192721.A29590@lyra.org> On Wed, Jul 05, 2000 at 06:18:51PM -0500, Skip Montanaro wrote: > Along the same lines, I have some pretty simple mods to readline.c and > rlcompleter.py that use atexit to automatically save the current history to > the file identified by the PYTHONHISTORY environment variable. (If unset, > no history read/write is done). If we aren't in feature freeze, I'd like to > check it in. I'm against additional magic environment variables. Can't you just have people put something into their .pythonrc file? Or will it still require some C-level changes? Basically, can you point people at doing: .pythonrc: import rlhistory rlhistory.save_to('/home/gstein/.py_history') Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Thu Jul 6 04:36:01 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 22:36:01 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <20000705192721.A29590@lyra.org> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> Message-ID: <14691.61585.352105.188917@cj42289-a.reston1.va.home.com> Greg Stein writes: > I'm against additional magic environment variables. > > Can't you just have people put something into their .pythonrc file? Or will > it still require some C-level changes? > > Basically, can you point people at doing: I think this makes the most sense. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Thu Jul 6 03:16:05 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 20:16:05 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <20000705192721.A29590@lyra.org> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> Message-ID: <14691.56789.869210.523939@beluga.mojam.com> Greg> I'm against additional magic environment variables. Greg> Can't you just have people put something into their .pythonrc Greg> file? Or will it still require some C-level changes? C-level changes are still required, but just to expose the existing functions in the GNU history library. After responding to Fred's note, I realized that what I'm doing in rlcompleter.py: import os histfile = os.getenv("PYTHONHISTORY") if histfile is not None: try: readline.read_history_file(histfile) except IOError: pass import atexit atexit.register(readline.write_history_file, histfile) del os, histfile could just as easily be done in ~/.pythonrc. Maybe I should retract the rlcompleter mods and just give something like import os histfile = os.path.join(os.environ["HOME"], ".python_history") try: readline.read_history_file(histfile) except IOError: pass import atexit atexit.register(readline.write_history_file, histfile) del os, histfile as an example in a yet-to-be-written libreadline.tex. Skip From fdrake at beopen.com Thu Jul 6 04:55:31 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 22:55:31 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14691.56789.869210.523939@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> <14691.56789.869210.523939@beluga.mojam.com> Message-ID: <14691.62755.609990.761864@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > as an example in a yet-to-be-written libreadline.tex. So when can I expect this to be checked in??? :-) (Surely you didn't expect me not to jump? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Thu Jul 6 05:40:15 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 23:40:15 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 References: <200007052256.PAA12103@slayer.i.sourceforge.net> Message-ID: <14691.65439.950090.60795@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> Add more "volatile" decls to stop gcc -Wall warnings. TP> Somebody w/ gcc please check that the wngs are gone! The ones in pypcre.c are gone, but there are still a bunch of other -Wall warnings, none of which I have time to look at right now. Here's an excerpt. -Barry -------------------- snip snip -------------------- [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c -o bufferobject.o bufferobject.c: In function `PyBuffer_New': bufferobject.c:174: warning: value computed is not used gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c -o classobject.o classobject.c: In function `instance_dealloc': classobject.c:526: warning: unused variable `_Py_RefTotal' [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c object.c -o object.o object.c: In function `_PyTrash_deposit_object': object.c:1172: warning: unused variable `hold' [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c pystate.c -o pystate.o pystate.c: In function `PyInterpreterState_New': pystate.c:45: warning: value computed is not used [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./gcmodule.c ./gcmodule.c: In function `debug_cycle': ./gcmodule.c:295: warning: unsigned int format, long unsigned int arg (arg 5) ./gcmodule.c: In function `collect': ./gcmodule.c:374: warning: int format, long int arg (arg 3) ./gcmodule.c:374: warning: int format, long int arg (arg 4) ./gcmodule.c:374: warning: int format, long int arg (arg 5) ./gcmodule.c:438: warning: int format, long int arg (arg 3) ./gcmodule.c:438: warning: int format, long int arg (arg 4) [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c ./posixmodule.c:496: warning: `posix_strint' defined but not used [...] gcc -fpic -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./linuxaudiodev.c ./linuxaudiodev.c: In function `newladobject': ./linuxaudiodev.c:68: warning: unused variable `opendev' ./linuxaudiodev.c:67: warning: unused variable `ctldev' ./linuxaudiodev.c: At top level: ./linuxaudiodev.c:406: warning: `ins' defined but not used [...] gcc -fpic -DWITH_APPINIT -I/usr/X11R6/include -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./_tkinter.c ./_tkinter.c: In function `Sleep': ./_tkinter.c:270: warning: unused variable `frac' ./_tkinter.c: In function `Tkapp_DeleteFileHandler': ./_tkinter.c:1595: warning: unused variable `data' gcc -fpic -DWITH_APPINIT -I/usr/X11R6/include -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./tkappinit.c ./tkappinit.c: In function `Tcl_AppInit': ./tkappinit.c:22: warning: `main' is usually a function [...] gcc -fpic -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./_cursesmodule.c ./_cursesmodule.c: In function `PyCurses_UngetMouse': ./_cursesmodule.c:1646: warning: unused variable `rtn' ./_cursesmodule.c: In function `PyCurses_MouseMask': ./_cursesmodule.c:1950: warning: unused variable `rtn' ./_cursesmodule.c: In function `PyCurses_TypeAhead': ./_cursesmodule.c:2162: warning: unused variable `err' ./_cursesmodule.c: At top level: ./_cursesmodule.c:1478: warning: `PyCurses_resetty' defined but not used ./_cursesmodule.c:1479: warning: `PyCurses_savetty' defined but not used From bwarsaw at beopen.com Thu Jul 6 05:46:56 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 23:46:56 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> Message-ID: <14692.304.49138.508128@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> At lunch today, Guido raised almost the same question! Tim JH> and I argued that we should continue the feature freeze, and JH> spend any extra time wasted while we wait for CNRI to quit JH> stalling to resolve open bugs and do more testing. It's been JH> a long time since the last bug fix release, and there are JH> already a lot of new features. We'd probably be best served JH> by working hard to make 2.0 stable and solid -- and then JH> getting 2.1 released quickly. I'm really quite torn. The more rational side of my brain agrees with this position. OTOH, it just doesn't make much sense to me to add list comprehensions and augmented assignments (and a raft of other new features) in a 2.1 release. Seems like 2.0 is where all the new stuff should go, with 2.x's as bug fix releases. Think of all the new features added in 1.5.2 (a /micro/ release for gawds' sake). In retrospect, that was nutty. ah-hell-let's-release-a-1.6-after-all-ly y'rs, -Barry From tim_one at email.msn.com Thu Jul 6 05:45:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 23:45:36 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 In-Reply-To: <14691.65439.950090.60795@anthem.concentric.net> Message-ID: [Barry, quotes Tim's checkin comment] > TP> Add more "volatile" decls to stop gcc -Wall warnings. > TP> Somebody w/ gcc please check that the wngs are gone! > The ones in pypcre.c are gone, Since pypcre.c is the only file I changed, that's actually good news . Thank you for checking. > but there are still a bunch of other > -Wall warnings, none of which I have time to look at right now. > > Here's an excerpt. > ... Also good! If we keep posting this relentlessly, it *may* eventually shame the authors into cleaning up their code . From bwarsaw at beopen.com Thu Jul 6 05:47:50 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 23:47:50 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? References: <14691.49755.365679.923078@beluga.mojam.com> Message-ID: <14692.358.213728.411981@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> Along the same lines, I have some pretty simple mods to SM> readline.c and rlcompleter.py that use atexit to automatically SM> save the current history to the file identified by the SM> PYTHONHISTORY environment variable. (If unset, no history SM> read/write is done). If we aren't in feature freeze, I'd like SM> to check it in. +1 And +10000...000 if you can make it properly record multi-line input. -Barry From guido at beopen.com Thu Jul 6 06:52:09 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 23:52:09 -0500 Subject: [Python-Dev] list comprehensions again... In-Reply-To: Your message of "Wed, 05 Jul 2000 23:46:56 -0400." <14692.304.49138.508128@anthem.concentric.net> References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> Message-ID: <200007060452.XAA11841@cj20424-a.reston1.va.home.com> > I'm really quite torn. The more rational side of my brain agrees with > this position. OTOH, it just doesn't make much sense to me to add > list comprehensions and augmented assignments (and a raft of other new > features) in a 2.1 release. Seems like 2.0 is where all the new stuff > should go, with 2.x's as bug fix releases. That was my reasoning too -- which is why I was quite torn too at lunch (not just by the menu choices). I believe earlier we discussed how in particular list comprehensions don't affect much else, so even if they are broken, that shouldn't affect the stability of all the other new code that we put in, and I don't see how they could hold up the 2.0final release much. I'm much less sure about augmented assignments -- that's one big sucker of a patch! > Think of all the new features added in 1.5.2 (a /micro/ release for > gawds' sake). In retrospect, that was nutty. Yesh... > ah-hell-let's-release-a-1.6-after-all-ly y'rs, That's an in-joke :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Thu Jul 6 05:52:28 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 22:52:28 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14692.358.213728.411981@anthem.concentric.net> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> Message-ID: <14692.636.850060.295979@beluga.mojam.com> BAW> And +10000...000 if you can make it properly record multi-line BAW> input. I take it there's an implicit smiley in there somewhere. All I do is expose the read_history and write_history in the GNU history library. The rest is up to readline & Python. Skip From tim_one at email.msn.com Thu Jul 6 05:51:53 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 23:51:53 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.304.49138.508128@anthem.concentric.net> Message-ID: OK, I'll be serious this time: if "the next release" is next week, damn straight I want to stick to the feature freeze. But if it becomes predictably delayed for months, sure, open the floodgates again. Unfortunately, the stuff holding up the release isn't technical in nature, so there's nothing most of us can do to affect the outcome either way. From fdrake at beopen.com Thu Jul 6 05:53:12 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 23:53:12 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.304.49138.508128@anthem.concentric.net> References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> Message-ID: <14692.680.483792.544003@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > Think of all the new features added in 1.5.2 (a /micro/ release for > gawds' sake). In retrospect, that was nutty. Are you saying we should re-label that 1.6? That may prove... convenient. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Thu Jul 6 06:03:30 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 23:03:30 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: References: <14692.304.49138.508128@anthem.concentric.net> Message-ID: <14692.1298.368572.533393@beluga.mojam.com> Well, how about taking a baseline snapshot now and branching the tree (I can almost hear Barry groaning all the way in Chicago...)? If the CNRI stuff gets cleared up quickly, the baseline + bug fixes becomes the 2.0 release and the other branch becomes 2.1 or something later. If it takes several weeks or a month (or more?), the snapshot gets forgotten and the branch becomes 2.0. I know branching is a struggle, probably not helped by the addition of the SourceForge stuff to the mix, but it might work out here. Skip From guido at beopen.com Thu Jul 6 07:04:19 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 00:04:19 -0500 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: Your message of "Wed, 05 Jul 2000 22:52:28 EST." <14692.636.850060.295979@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> Message-ID: <200007060504.AAA11934@cj20424-a.reston1.va.home.com> > BAW> And +10000...000 if you can make it properly record multi-line > BAW> input. > > I take it there's an implicit smiley in there somewhere. All I do is expose > the read_history and write_history in the GNU history library. The rest is > up to readline & Python. Barry was serious. IDLE does this right -- it remembers and lets you recall and edit entire multi-line commands. It's understood that readline doesn't support this, but at the same time it's a severe limitation that means that readline will never be good enough for the E in CP4E. This doesn't mean it's not an improvement over no line editing at all! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From tim_one at email.msn.com Thu Jul 6 06:14:48 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 00:14:48 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007060042.TAA06919@cj20424-a.reston1.va.home.com> Message-ID: > ... > Anyway, the patches are currently in Tim Peters' court. Forgot to say this before: among moving, bug-fixing, general testing, and the O'Reilly conference, I don't believe I'll find time to look at these patches for at least 2-- and more likely 3 --weeks. So if somebody is especially keen to get this in soon, feel encouraged to reassign the patch to yourself. From tim_one at email.msn.com Thu Jul 6 06:14:50 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 00:14:50 -0400 Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <01f001bfe6bb$5198bb60$f2a6b5d4@hagrid> Message-ID: Time to clear this one up too : Eric was taken in by a faux (i.e., not mine) "-ly y'rs" signoff. And if we're talking about one process, it's the process's exit code; if more than one, the processes' exit codes. "process exit code" also works for me. english-is-what-we-make-it-ly y'rs - tim From tim_one at email.msn.com Thu Jul 6 06:25:58 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 00:25:58 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.1298.368572.533393@beluga.mojam.com> Message-ID: [Skip Montanaro] > Well, how about taking a baseline snapshot now and branching the > tree (I can almost hear Barry groaning all the way in Chicago...)? > ... > I know branching is a struggle, probably not helped by the addition of the > SourceForge stuff to the mix, but it might work out here. That's exactly the kind of redirection of effort that a feature freeze is imposed to prevent. Even talking about it takes time away from work that *needs* to be completed for the release. OTOH, if the release is months away anyway, there's no need for a fork . From skip at mojam.com Thu Jul 6 06:27:38 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 23:27:38 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060504.AAA11934@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> <200007060504.AAA11934@cj20424-a.reston1.va.home.com> Message-ID: <14692.2746.526025.335108@beluga.mojam.com> Guido> Barry was serious. IDLE does this right -- it remembers and lets Guido> you recall and edit entire multi-line commands. Yeah, but readline isn't a command editor, just a line editor and history. If I execute the following interactively: for i in range(10): print i I can use C-p to retrieve the lines and re-execute them. It's no better or worse than what bash does. In fact, with some versions of bash, it does recall entire multiline commands, for example, taking for f in `ls *.c` ; do echo $f done and returning for f in `ls *.c` ; do echo $f ; done instead when you retrieve it from the history. I find this particularly annoying and would much rather have the line-by-line recall that older versions of bash (and now Python) support. I've never used IDLE. What does it do to facilitate command recall and editing that's much different than Python or bash? Would it pop up the above Python for loop into a text editor widget and execute it when the widget is closed? Skip From fdrake at beopen.com Thu Jul 6 06:35:30 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 00:35:30 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14692.2746.526025.335108@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> <200007060504.AAA11934@cj20424-a.reston1.va.home.com> <14692.2746.526025.335108@beluga.mojam.com> Message-ID: <14692.3218.271993.100946@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > instead when you retrieve it from the history. I find this particularly > annoying and would much rather have the line-by-line recall that older > versions of bash (and now Python) support. This is something where you'd really want to be able to select which you prefer and toggle back and forth. I usually want a whole block, but sometimes I want to construct a new block from pieces of previous blocks. > I've never used IDLE. What does it do to facilitate command recall and > editing that's much different than Python or bash? Would it pop up the > above Python for loop into a text editor widget and execute it when the > widget is closed? No; it retrieves the whole multi-line block and inserts is at the prompt, allowing you to edit any part of it before type to execute. It's better than the bash behavior because it doesn't replace the actual newlines with semicolon separators (which wouldn't be sufficient for arbitrary Python code anyway). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Thu Jul 6 06:44:09 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 00:44:09 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> Message-ID: <14692.3737.500081.892301@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: BAW> And +10000...000 if you can make it properly record BAW> multi-line input. SM> I take it there's an implicit smiley in there somewhere. Well, would classify a wistful, dreamy sort of smile as "implicit"? :) -Barry From skip at mojam.com Thu Jul 6 06:47:10 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 23:47:10 -0500 (CDT) Subject: [Python-Dev] grumble, grumble - makesetup prepends leading $(srcdir) - why? Message-ID: <14692.3918.493708.366779@beluga.mojam.com> Here's one that's bugged me for awhile that I'm tired of working around. Perhaps someone can explain why makesetup does what it does. In my Modules/Setup.local file I have TOP=$(HOME)/src/python EDIR=$(TOP)/PyExtensions1.5 llop $(EDIR)/llopmodule.c # helper function(s) for latlong.py This gets converted into llopmodule.o: $(srcdir)/$(EDIR)/llopmodule.c; $(CC) $(CCSHARED) $(CFLAGS) -c $(srcdir)/$(EDIR)/llopmodule.c llopmodule$(SO): llopmodule.o; $(LDSHARED) llopmodule.o -o llopmodule$(SO) in Modules/Makefile. Is there a good reason why is $(srcdir)/ prepended to the source file reference, thus breaking my local module references? It seems the culprit is case $src in glmodule.c) ;; /*) ;; *) src='$(srcdir)/'$src;; esac around about line 193. I think this should be changed to case $src in glmodule.c) ;; /*) ;; \$*) ;; *) src='$(srcdir)/'$src;; esac or something similar that protects paths that begin with a Make variable. That fix works for me. Any objections to me checking it in? Also, who died and made glmodule.c king? Skip From bwarsaw at beopen.com Thu Jul 6 06:54:36 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 00:54:36 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> <200007060504.AAA11934@cj20424-a.reston1.va.home.com> <14692.2746.526025.335108@beluga.mojam.com> Message-ID: <14692.4364.272173.857069@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> I can use C-p to retrieve the lines and re-execute them. It's SM> no better or worse than what bash does. In fact, with some SM> versions of bash, it does recall entire multiline commands, SM> for example, taking | for f in `ls *.c` ; do | echo $f | done SM> and returning SM> for f in `ls *.c` ; do echo $f ; done SM> instead when you retrieve it from the history. I find this SM> particularly annoying and would much rather have the SM> line-by-line recall that older versions of bash (and now SM> Python) support. Not me. I love this particular feature of bash. I'm using 2.03. And it's one killer (IMO) feature of IDLE. -Barry From skip at mojam.com Thu Jul 6 06:58:11 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 23:58:11 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14692.4364.272173.857069@anthem.concentric.net> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> <200007060504.AAA11934@cj20424-a.reston1.va.home.com> <14692.2746.526025.335108@beluga.mojam.com> <14692.4364.272173.857069@anthem.concentric.net> Message-ID: <14692.4579.624873.898969@beluga.mojam.com> SM> for f in `ls *.c` ; do echo $f ; done SM> ... I find this particularly annoying and would much rather have the SM> line-by-line recall that older versions of bash (and now Python) SM> support. BAW> Not me. I love this particular feature of bash. I'm using 2.03. BAW> And it's one killer (IMO) feature of IDLE. My main (error) reason for recalling a multiline command in bash is to insert a command I forgot to include, which is probably why I detest the way bash 2.x does command recall. Does IDLE allow new lines to be inserted into multiline commands or is it restricted to editing the existing lines? ESR is probably pretty damn good at curses in Python by now. Perhaps he can blend readline and curses together into a "simple" multiline command recall editor... ;-) Skip From Mark.Favas at per.dem.csiro.au Thu Jul 6 07:01:59 2000 From: Mark.Favas at per.dem.csiro.au (Favas, Mark (EM, Floreat)) Date: Thu, 6 Jul 2000 13:01:59 +0800 Subject: [Python-Dev] Defining _XOPEN_SOURCE in Python.h breaks 2.0b1 on Tru64 Unix Message-ID: This change results in mathmodule.c failing to compile (rint is undefined) due to an interaction between defining _XOPEN_SOURCE and the use of _XOPEN_SOURCE_EXTENDED in the system includes (/usr/include/math.h). Yes, configure correctly defines HAVE_RINT. This change also results in a number of errors and warnings in timemodule.c, and probably further modules down the compilation chain. From tim_one at email.msn.com Thu Jul 6 07:18:43 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 01:18:43 -0400 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14692.4579.624873.898969@beluga.mojam.com> Message-ID: [Skip Montanaro] > ... > Does IDLE allow new lines to be inserted into multiline commands or > is it restricted to editing the existing lines? Insertion is easy. In fact, it's sometimes surprising! The deal is that ENTER means two things in the IDLE shell: it may mean "insert a new line", or it may mean "I'm done with my edits, so run this block again". Which action IDLE performs depends on where the cursor is at the time ENTER is hit (whether or not at the end of the copied block). Lovely as the feature is, I think it gets in my way more often than not, as, e.g., I'm very likely to copy a multiline for-loop down and change just the limit on a range; then hitting ENTER doesn't do what I expect. there's-nothing-about-a-ui-somebody-won't-hate-ly y'rs - tim From guido at beopen.com Thu Jul 6 09:00:49 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 02:00:49 -0500 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: Your message of "Wed, 05 Jul 2000 20:16:05 EST." <14691.56789.869210.523939@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> <14691.56789.869210.523939@beluga.mojam.com> Message-ID: <200007060700.CAA01658@cj20424-a.reston1.va.home.com> > C-level changes are still required, but just to expose the existing > functions in the GNU history library. After responding to Fred's note, I > realized that what I'm doing in rlcompleter.py: > > import os > histfile = os.getenv("PYTHONHISTORY") > if histfile is not None: > try: > readline.read_history_file(histfile) > except IOError: > pass > import atexit > atexit.register(readline.write_history_file, histfile) > del os, histfile > > could just as easily be done in ~/.pythonrc. Maybe I should retract the > rlcompleter mods and just give something like > > import os > histfile = os.path.join(os.environ["HOME"], ".python_history") > try: > readline.read_history_file(histfile) > except IOError: > pass > import atexit > atexit.register(readline.write_history_file, histfile) > del os, histfile > > as an example in a yet-to-be-written libreadline.tex. Yes, much better. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Thu Jul 6 09:52:14 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 09:52:14 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> Message-ID: <39643AAE.B8448E4@lemburg.com> "M.-A. Lemburg" wrote: > > Fredrik Lundh wrote: > > > > mal wrote: > > > > > The idea is not new: strings and Unicode should have more > > > or less the same methods to enhance their compatibility. > > > > > > The attached patch adds encoding capabilities to normal > > > strings and extends the builtin str() to accept an optional > > > encoding (and error) argument. It also tries to reuse the > > > already available Unicode codecs for the purposes of strings > > > (conversions are done via the default encoding in both > > > directions). > > > > ... > > > > > What do you think about this ? Should I add it to CVS > > > as experiment ? > > > > +1 on the "encode" part > > > > -0 on the "str" part (intuitively, it's -1, but I don't have > > any good arguments against it right now... maybe later) > > The str() extension complements unicode() which also works > as constructor for object given an encoding. > > Ideally, unicode() should also look for __unicode__() on instances > just like str() looks for __str__(). > > Note that we could also have a .decode() method instead of > modifying str(), but this would break symmetry to Unicode, > since you can't decode Unicode into anything... Anybody else have an opinion on this idea ? I'd like to get this done before the release of 2.0b1. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Thu Jul 6 10:53:47 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 6 Jul 2000 01:53:47 -0700 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Objects unicodeobject. c,2.33,2.34 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD276@RED-MSG-50> ! if (c1 > (1<<11) * 26) ! c1 += utf16Fixup[c1>>11]; ! if (c2 > (1<<11) * 26) ! c2 += utf16Fixup[c2>>11]; ! This change from the patch is kind of silly. You've made the code flow more complicated for no particularly good reason, esp. considering the size of utf16Fixup[]. That is, the cost in the CPU of handling the branch prediction is likely to be much higher than the array lookup for every character. Bill From fredrik at pythonware.com Thu Jul 6 11:02:45 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 11:02:45 +0200 Subject: [Python-Dev] Spelling check: more typos References: <14690.56733.627266.907044@temoleh.chem.uu.nl> <20000705200043.D7564@ludwig.cnri.reston.va.us> Message-ID: <006b01bfe728$f4dcc380$0900a8c0@SPIFF> greg wrote: > In American English, "license" is both noun and verb. In the rest of > the world, "licence" is the noun and "license" the verb. should have realized that all dictionaries I consulted happened to be american. when I saw your post, I looked it up in the dictionaries I have at home (all British), and they all pointed out that the americans have it all mixed up. Just like those "Original Swedish Apfelstrudel" I found in Palo Alto... From jack at oratrix.nl Thu Jul 6 11:05:12 2000 From: jack at oratrix.nl (Jack Jansen) Date: Thu, 06 Jul 2000 11:05:12 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: Message by "M.-A. Lemburg" , Thu, 06 Jul 2000 00:19:38 +0200 , <3963B47A.638A7A82@lemburg.com> Message-ID: <20000706090512.EF3EC37186E@snelboot.oratrix.nl> > BTW, if your compiler supports Unicode (that is provides > a working wctype.h file), you can compile Python using > the compile time switch --with-wctype-functions. Python > will then use the C libs iswXXX() APIs which should return > more or less the same values as the Python ones (could be that > the C lib is Unicode 2.0 -- so YMMV). Note that this hasn't > been tested much yet. Feedback is welcome. Unfortunately the native wctype implementation is apparently different enough that it makes test_unicode fail. But I've solved the problem by splitting the 5000-entry switch statement into multiple switches with 1000 entries each. That's good enough for the CodeWarrior compiler (which doesn't have the least problem with the tiny 256-case switch in ceval.c). It may not be good enough for people who have compilers with really low limits on the number of cases in a switch, though. I'll check it in shortly. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack at oratrix.nl Thu Jul 6 11:12:10 2000 From: jack at oratrix.nl (Jack Jansen) Date: Thu, 06 Jul 2000 11:12:10 +0200 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack In-Reply-To: Message by "Tim Peters" , Wed, 5 Jul 2000 22:14:39 -0400 , Message-ID: <20000706091210.443F537186E@snelboot.oratrix.nl> > a) Add comments to the #ifdef's saying they're for the Mac. "Mystery code" > is bad in group-maintained software. I expect Jack will maintain that it > isn't really Mac-specific, but a wonderful feature for any platform that > cares to #define USE_STACKCHECK and PyOS_CheckStack. Then I preemptively > sneer in his general direction . Hehheh:-) But I think it actually is used by some of the other ports. Any platform that doesn't guarantee a vm-hole between the stack and everything else should use a stack check, and this'll probably include all the handhelds and such. > b) Wonder out loud why this code is useful on a Mac but not other platforms. > We can get segfaulting recursion while print'ing and repr'ing on all > platforms. So shouldn't we work to catch that on all platforms too? Macs > shouldn't be something special wrt this. Well, a segfault is bad, but silently pushing the stack into the heap or into other random data is worse. And as the stackcheck isn't free it isn't used on other platforms. Moreover, I'm not even sure you can determine the stack limit on all platforms... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From thomas at xs4all.net Thu Jul 6 11:46:32 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 6 Jul 2000 11:46:32 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007060452.XAA11841@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 05, 2000 at 11:52:09PM -0500 References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> <200007060452.XAA11841@cj20424-a.reston1.va.home.com> Message-ID: <20000706114632.H13478@xs4all.nl> On Wed, Jul 05, 2000 at 11:52:09PM -0500, Guido van Rossum wrote: > I'm much less sure about augmented assignments -- that's one big > sucker of a patch! Ah, but it fits so nicely with the rest of Python ! :) The changes to support the new grammar, the new bytecodes and the __overload_ab__ methods are pretty teensy, but there's a lot of code to support the in-place operators in builtin and extension types, keeping the current API's semantics regarding conversion and such. In fact, test_augassign is just as large as the changes to ceval.c, and larger than those to compile.c ;) I agree though, that it's a big sucker of a patch to take in at once. I haven't found any bugs lately, but I don't use it that much. But it should run perfectly with old code, even if you just change all occurances of 'x = x + y' into 'x += y'. The worst thing that happens is that spam[something()] += other() is not entirely the same as: idx = something() spam[idx] = spam[idx] + other() but rather val = other() idx = something() spam[idx] = val because of the order of argument evaluation. But this shouldn't come as a suprise to anyone who has ever looked at the order of argument evaluation (I hadn't, before this) because it is exactly the same order as: spam[something()] = other() Would it help if I delivered it one piece at a time ? ;) I would suggest against adding augmented assignment in 2.0 if it went by the by-now-old schedule of the first beta at july 1st, because this patch can certainly use a full beta cycle to find out if any bugs lurk, but if 2.0 is months away, 2.1 is even more months away. But then, I have no idea about the problems which delay the 2.0 beta cycle, so I shouldn't be making assumptions ;P Advocating-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jul 6 11:48:56 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 11:48:56 +0200 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.33,2.34 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD276@RED-MSG-50> Message-ID: <39645608.9612520B@lemburg.com> Bill Tutt wrote: > > ! if (c1 > (1<<11) * 26) > ! c1 += utf16Fixup[c1>>11]; > ! if (c2 > (1<<11) * 26) > ! c2 += utf16Fixup[c2>>11]; > ! > > > > This change from the patch is kind of silly. You've made the code flow more > complicated for no particularly good reason, The reason was that it avoids the fixup lookup for all non-surrogate characters -- the vast majority of all chars processed. > esp. considering the size of > utf16Fixup[]. That is, the cost in the CPU of handling the branch prediction > is likely to be much higher than the array lookup for every character. Note that the lookup also involves a shift operation for every character. But if you insist, I'll do some benchmarking and check which version is faster. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 6 11:52:17 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 11:52:17 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <20000706090512.EF3EC37186E@snelboot.oratrix.nl> Message-ID: <396456D1.1D5EE0A5@lemburg.com> Jack Jansen wrote: > > > BTW, if your compiler supports Unicode (that is provides > > a working wctype.h file), you can compile Python using > > the compile time switch --with-wctype-functions. Python > > will then use the C libs iswXXX() APIs which should return > > more or less the same values as the Python ones (could be that > > the C lib is Unicode 2.0 -- so YMMV). Note that this hasn't > > been tested much yet. Feedback is welcome. > > Unfortunately the native wctype implementation is apparently different enough > that it makes test_unicode fail. But I've solved the problem by splitting the > 5000-entry switch statement into multiple switches with 1000 entries each. > That's good enough for the CodeWarrior compiler (which doesn't have the least > problem with the tiny 256-case switch in ceval.c). It may not be good enough > for people who have compilers with really low limits on the number of cases in > a switch, though. > > I'll check it in shortly. It might also be a good idea to add if (ch < 0x100) switch... statements. Most Unicode chars will be in the Latin-1 range anyway and this should improve performance. I'll add these to the other switches in unicodectype.c too after you've made your changes. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 6 12:03:28 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 12:03:28 +0200 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.33,2.34 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD276@RED-MSG-50> <39645608.9612520B@lemburg.com> Message-ID: <39645970.18CC2B9F@lemburg.com> "M.-A. Lemburg" wrote: > > Bill Tutt wrote: > > > > ! if (c1 > (1<<11) * 26) > > ! c1 += utf16Fixup[c1>>11]; > > ! if (c2 > (1<<11) * 26) > > ! c2 += utf16Fixup[c2>>11]; > > ! > > > > > > > > This change from the patch is kind of silly. You've made the code flow more > > complicated for no particularly good reason, > > The reason was that it avoids the fixup lookup for all non-surrogate > characters -- the vast majority of all chars processed. > > > esp. considering the size of > > utf16Fixup[]. That is, the cost in the CPU of handling the branch prediction > > is likely to be much higher than the array lookup for every character. > > Note that the lookup also involves a shift operation for every > character. > > But if you insist, I'll do some benchmarking and check which > version is faster. Your version: 0.98 sec. Fixed version: 0.96 sec. I don't think it's worth discussing this ;-) What's more interesting is that string compares are twice as fast: Same test: 0.46 sec. This is probably due to the compiler optimizing the memcmp() call which is used in string compares. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Thu Jul 6 12:21:05 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 12:21:05 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> <39643AAE.B8448E4@lemburg.com> Message-ID: <010101bfe733$e84a8750$0900a8c0@SPIFF> mal wrote: > > > > > > > What do you think about this ? Should I add it to CVS > > > > as experiment ? > > > > > > +1 on the "encode" part > > > > > > -0 on the "str" part (intuitively, it's -1, but I don't have > > > any good arguments against it right now... maybe later) > > > > The str() extension complements unicode() which also works > > as constructor for object given an encoding. > > > > Ideally, unicode() should also look for __unicode__() on instances > > just like str() looks for __str__(). > > > > Note that we could also have a .decode() method instead of > > modifying str(), but this would break symmetry to Unicode, > > since you can't decode Unicode into anything... > > Anybody else have an opinion on this idea ? I'd like to get > this done before the release of 2.0b1. Having thought this over, I'm -1 on the str fix. You're changing "str" from being a converter ("convert this to a string") to a string constructor ("create a new 8-bit string"). This is against the "strings are strings" spirit. Cannot you check the rest in, and leave "str" alone for now? From mal at lemburg.com Thu Jul 6 13:08:43 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 13:08:43 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> <39643AAE.B8448E4@lemburg.com> <010101bfe733$e84a8750$0900a8c0@SPIFF> Message-ID: <396468BB.EEC3D6F7@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > > > > > > > What do you think about this ? Should I add it to CVS > > > > > as experiment ? > > > > > > > > +1 on the "encode" part > > > > > > > > -0 on the "str" part (intuitively, it's -1, but I don't have > > > > any good arguments against it right now... maybe later) > > > > > > The str() extension complements unicode() which also works > > > as constructor for object given an encoding. > > > > > > Ideally, unicode() should also look for __unicode__() on instances > > > just like str() looks for __str__(). > > > > > > Note that we could also have a .decode() method instead of > > > modifying str(), but this would break symmetry to Unicode, > > > since you can't decode Unicode into anything... > > > > Anybody else have an opinion on this idea ? I'd like to get > > this done before the release of 2.0b1. > > Having thought this over, I'm -1 on the str fix. > > You're changing "str" from being a converter ("convert this to a > string") to a string constructor ("create a new 8-bit string"). This > is against the "strings are strings" spirit. Um, that was my motivation behind extending str() -- to make the two (str() and unicode()) aliases for the same function in some future Python version. Note that str() is in fact a constructor: you pass it an object and it creates a string from it for you. unicode() does the same thing (except that there's currently no __unicode__() check for instances). > Cannot you check the rest in, and leave "str" alone for now? I'll do that -- you won't be able to decode anything though, because there's no Python interface to PyString_Decode(). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Thu Jul 6 13:52:56 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 06:52:56 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060700.CAA01658@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> <14691.56789.869210.523939@beluga.mojam.com> <200007060700.CAA01658@cj20424-a.reston1.va.home.com> Message-ID: <14692.29464.106980.766555@beluga.mojam.com> >>>>> "Guido" == Guido van Rossum writes: >> ... could just as easily be done in ~/.pythonrc. Maybe I should >> retract the rlcompleter mods and just give something like [ ... brilliant example elided ... ] >> as an example in a yet-to-be-written libreadline.tex. Guido> Yes, much better. Okay, so the rlcompleter mods are out. That leaves two measly new methods in readline.c that won't bother anyone. Skip From guido at beopen.com Thu Jul 6 14:53:39 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 07:53:39 -0500 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) In-Reply-To: Your message of "Thu, 06 Jul 2000 12:21:05 +0200." <010101bfe733$e84a8750$0900a8c0@SPIFF> References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> <39643AAE.B8448E4@lemburg.com> <010101bfe733$e84a8750$0900a8c0@SPIFF> Message-ID: <200007061253.HAA02450@cj20424-a.reston1.va.home.com> > Subject: Re: [Python-Dev] 'abc'.encode() and str(obj, encoding) > From: "Fredrik Lundh" > To: "M.-A. Lemburg" , > "Python Developers @ python.org" > Date: Thu, 6 Jul 2000 12:21:05 +0200 > Delivery-Date: Thu Jul 6 06:22:40 2000 > > mal wrote: > > > > > > > > > What do you think about this ? Should I add it to CVS > > > > > as experiment ? > > > > > > > > +1 on the "encode" part > > > > > > > > -0 on the "str" part (intuitively, it's -1, but I don't have > > > > any good arguments against it right now... maybe later) > > > > > > The str() extension complements unicode() which also works > > > as constructor for object given an encoding. > > > > > > Ideally, unicode() should also look for __unicode__() on instances > > > just like str() looks for __str__(). > > > > > > Note that we could also have a .decode() method instead of > > > modifying str(), but this would break symmetry to Unicode, > > > since you can't decode Unicode into anything... > > > > Anybody else have an opinion on this idea ? I'd like to get > > this done before the release of 2.0b1. [/F] > Having thought this over, I'm -1 on the str fix. > > You're changing "str" from being a converter ("convert this to a > string") to a string constructor ("create a new 8-bit string"). This > is against the "strings are strings" spirit. I almost voted with you, except that int() also has an extra argument: int("100", 8) yields 64. In one of my proposals for a type system I've also used the str function and others as a constructor. Since I haven't seen the patch (too much other stuff going on you don't want to know about :-( ), I vote 0; that's neither +0 nor -0. > Cannot you check the rest in, and leave "str" alone for now? That would certainly be safe. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Thu Jul 6 14:18:04 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 08:18:04 -0400 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000703165305.R29590@lyra.org>; from gstein@lyra.org on Mon, Jul 03, 2000 at 04:53:05PM -0700 References: <20000703095600.A12141@thyrsus.com> <20000703165305.R29590@lyra.org> Message-ID: <20000706081804.A24401@thyrsus.com> Greg Stein : > I used: > > $ cvs -z3 -d :ext:gstein at cvs.python.sourceforge.net:/cvsroot/python co python > > The instructions on SF didn't quite work. Adding the :ext: in made it work > fine for me. I'm using CVS 1.10.6 snark:~/WWW/python$ cvs -z3 -d :ext:esr at cvs.python.sourceforge.net:/cvsroot/python co python esr at cvs.python.sourceforge.net's password: cvs checkout: warning: unrecognized response `' from cvs server cvs checkout: warning: unrecognized response `Welcome to cvs1.sourceforge.net' from cvs server cvs checkout: warning: unrecognized response `' from cvs server cvs checkout: warning: unrecognized response `This is a restricted Shell Account' from cvs server cvs checkout: warning: unrecognized response `You cannot execute anything here.' from cvs server cvs checkout: warning: unrecognized response `' from cvs server cvs [checkout aborted]: end of file from server (consult above messages if any) That didn't work either. Anyone got any other ideas? I seem to have CVS 1.10.7. -- Eric S. Raymond See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs. -- Dave Barry From mal at lemburg.com Thu Jul 6 14:09:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 14:09:53 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> <39643AAE.B8448E4@lemburg.com> <010101bfe733$e84a8750$0900a8c0@SPIFF> <200007061253.HAA02450@cj20424-a.reston1.va.home.com> Message-ID: <39647711.6BDF96C@lemburg.com> Guido van Rossum wrote: > > [/F] > > Having thought this over, I'm -1 on the str fix. > > > > You're changing "str" from being a converter ("convert this to a > > string") to a string constructor ("create a new 8-bit string"). This > > is against the "strings are strings" spirit. > > I almost voted with you, except that int() also has an extra argument: > int("100", 8) yields 64. In one of my proposals for a type system > I've also used the str function and others as a constructor. I've always thought of str() being a constructor, just like int(), float(), complex() and all the others. The reasoning for adding optionla arguments to str() was to make it match the unicode() signature. > Since I haven't seen the patch (too much other stuff going on you > don't want to know about :-( ), I vote 0; that's neither +0 nor -0. > > > Cannot you check the rest in, and leave "str" alone for now? > > That would certainly be safe. I've checked in the .encode() method and the C APIs that go with it. There's currently no way to access the codec decode methods though (that was part of the str() patch). Anyway, it's cool having the ability to use the codecs for strings too, e.g. you can now do conversions from the current default encoding to say UTF-16 by simply writing: setenv LANG de_DE # Latin-1 encoding python -c "print 'W?nsch dir was...'.encode('utf16')" -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 6 14:17:28 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 14:17:28 +0200 Subject: [Python-Dev] SRE's match objects are missing .regs ?! Message-ID: <396478D8.26CBD0FA@lemburg.com> Is this intended ? I've often used .regs directly to enhance performance, but it looks as if SRE doesn't support this: Traceback (most recent call last): File "", line 1, in ? File "/home/lemburg/lib/hack.py", line 76, in docs showdocstring(obj.__doc__,2) File "/home/lemburg/lib/hack.py", line 145, in showdocstring sp = m.regs[1][1] AttributeError: regs -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Thu Jul 6 14:27:32 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 6 Jul 2000 14:27:32 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 In-Reply-To: <14691.65439.950090.60795@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 05, 2000 at 11:40:15PM -0400 References: <200007052256.PAA12103@slayer.i.sourceforge.net> <14691.65439.950090.60795@anthem.concentric.net> Message-ID: <20000706142731.K13478@xs4all.nl> On Wed, Jul 05, 2000 at 11:40:15PM -0400, Barry A. Warsaw wrote: > >>>>> "TP" == Tim Peters writes: > TP> Add more "volatile" decls to stop gcc -Wall warnings. > TP> Somebody w/ gcc please check that the wngs are gone! > The ones in pypcre.c are gone, but there are still a bunch of other > -Wall warnings, none of which I have time to look at right now. I actually looked at most of these a couple of weeks back, and most are harmless. For instance: > -------------------- snip snip -------------------- > [...] > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c -o bufferobject.o > bufferobject.c: In function `PyBuffer_New': > bufferobject.c:174: warning: value computed is not used PyObject_INIT((PyObject *)b, &PyBuffer_Type); The 'value computed' is useless. The value computed is computed by the ',' operator, but the only things in there are sideffect operators. The last operation in the string of ',''s is either a void-returning function or an assignment, so I'd classify this one as a cosmetic bug in gcc ;) adding a '(void)' cast to the PyObject_INIT() macro or the calls to it would fix the warning. > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c -o classobject.o > classobject.c: In function `instance_dealloc': > classobject.c:526: warning: unused variable `_Py_RefTotal' Can be fixed by a surrounding #ifdef Py_TRACE_REFS. > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c object.c -o object.o > object.c: In function `_PyTrash_deposit_object': > object.c:1172: warning: unused variable `hold' Can be removed, seems to be left over from before Christians' trash hauling. > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c pystate.c -o pystate.o > pystate.c: In function `PyInterpreterState_New': > pystate.c:45: warning: value computed is not used Similar to PyObject_INIT(), but even sillier ;) Can be fixed in the same manner. > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c > ./posixmodule.c:496: warning: `posix_strint' defined but not used Looks like an obsoleted helper function, for calling string-int-functions. (Like posix_strintint, which is called in exactly one place.) Unsure if these are leftover or intended for future use ;) If they are just leftover, shouldn't we just make chown do the work posix_strintint does, and remove those two functions ? I also get a few others, by the way (redhat-6.1 supplied egcs-1.1.2): ceval.c: In function `eval_code2': ceval.c:333: warning: `opcode' might be used uninitialized in this function ceval.c:334: warning: `oparg' might be used uninitialized in this function The second one is fairly obvious: oparg is only initialized if opcode has an argument, but gcc doesn't know when that is. So as far as gcc is concerned it is possible to enter a branch that uses oparg without initializing it. The opcode one is because it's possible as far as gcc is concerned, to jump to on_error on the first iteration of the large for(;;) loop, before opcode is initialized. This might actually be possible, I think, if a signal arrives before the first time through the loop. ./pypcre.c: In function `compile_branch': ./pypcre.c:1222: warning: `c' might be used uninitialized in this function Just looking at this one gave me a headache. This code can definately use a good indent run, or better yet, replacement! I can't figure out why gcc complains about this one. ./socketmodule.c: In function `newSSLObject': ./socketmodule.c:1963: warning: unused variable `str' ./socketmodule.c: At top level: ./socketmodule.c:358: warning: `SSL_setattr' declared `static' but never defined As you can see, I compile the socket module with SSL ;) Both of these can be just removed, but I'm not sure howmuch of the SSL part is still 'work in progress'. And then there's some warnings in _cursesmodule.c, _tkinter.c, gcmodule.c, linuxaudiodev.c and tkappinit.c that the module maintainers should look at. (nudge nudge.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fredrik at pythonware.com Thu Jul 6 14:31:42 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 14:31:42 +0200 Subject: [Python-Dev] SRE's match objects are missing .regs ?! References: <396478D8.26CBD0FA@lemburg.com> Message-ID: <01bc01bfe746$25940d90$0900a8c0@SPIFF> mal wrote: > Is this intended ? I've often used .regs directly to enhance > performance, but it looks as if SRE doesn't support this: if you can figure out where (in the 1.5.2 docs) they're documented, I'll add them ;-) (I'd rather add a "spans" method, but that's me...) From akuchlin at cnri.reston.va.us Thu Jul 6 14:32:23 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Thu, 6 Jul 2000 08:32:23 -0400 Subject: [Python-Dev] SRE's match objects are missing .regs ?! In-Reply-To: <396478D8.26CBD0FA@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 02:17:28PM +0200 References: <396478D8.26CBD0FA@lemburg.com> Message-ID: <20000706083223.A29375@newcnri.cnri.reston.va.us> On Thu, Jul 06, 2000 at 02:17:28PM +0200, M.-A. Lemburg wrote: >Is this intended ? I've often used .regs directly to enhance >performance, but it looks as if SRE doesn't support this: .regs was never documented in the library reference, nor in the docstrings in libre.tex; it was an underlying implementation detail some people happened to take advantage of. If /F wants to add it in order to be nice, fine; I certainly wouldn't bother to do that. -amk From pavlos at gaaros.com Thu Jul 6 14:46:50 2000 From: pavlos at gaaros.com (Pavlos Christoforou) Date: Thu, 6 Jul 2000 08:46:50 -0400 (EDT) Subject: [Python-Dev] Re: [Zope-dev] ExtensionClass and __radd__()? In-Reply-To: <20000705183046.A26381@ludwig.cnri.reston.va.us> Message-ID: On Wed, 5 Jul 2000, Greg Ward wrote: > > Well, it's a nice theory. It doesn't explain why '__add__()' works for > ExtensionClass while '__radd__()' does not; perhaps ExtensionClass > implements that much of Python's class semantics, but doesn't go as far > as '__radd__()'. > A quick note which you probably already know: grep add ExtensionClass.c gives: static PyObject *py__add__, *py__sub__, *py__mul__, *py__div__, INIT_PY_NAME(__add__); BINOP(add,Add) FILLENTRY(nm->nb, add, add, METH_VARARGS, "Add to another"); FILLENTRY(sm->sq, concat, add, METH_VARARGS, SET_SPECIAL(add,add); subclass_add(PyObject *self, PyObject *v) UNLESS(m=subclass_getspecial(self,py__add__)) return NULL; && AsCMethod(m)->meth==(PyCFunction)add_by_name ASSIGN(m,AsCMethod(m)->type->tp_as_number->nb_add(self,v)); (binaryfunc)subclass_add, /*nb_add*/ (binaryfunc)subclass_add, /*sq_concat*/ return; /* we added a reference; don't delete now */ whereas grep radd ExtensionClass.c returns nothing Pavlos From gstein at lyra.org Thu Jul 6 15:21:52 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 06:21:52 -0700 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000706081804.A24401@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 06, 2000 at 08:18:04AM -0400 References: <20000703095600.A12141@thyrsus.com> <20000703165305.R29590@lyra.org> <20000706081804.A24401@thyrsus.com> Message-ID: <20000706062152.P29590@lyra.org> On Thu, Jul 06, 2000 at 08:18:04AM -0400, Eric S. Raymond wrote: > Greg Stein : > > I used: > > > > $ cvs -z3 -d :ext:gstein at cvs.python.sourceforge.net:/cvsroot/python co python > > > > The instructions on SF didn't quite work. Adding the :ext: in made it work > > fine for me. I'm using CVS 1.10.6 > > snark:~/WWW/python$ cvs -z3 -d :ext:esr at cvs.python.sourceforge.net:/cvsroot/python co python > esr at cvs.python.sourceforge.net's password: > cvs checkout: warning: unrecognized response `' from cvs server > cvs checkout: warning: unrecognized response `Welcome to cvs1.sourceforge.net' from cvs server > cvs checkout: warning: unrecognized response `' from cvs server > cvs checkout: warning: unrecognized response `This is a restricted Shell Account' from cvs server > cvs checkout: warning: unrecognized response `You cannot execute anything here.' from cvs server > cvs checkout: warning: unrecognized response `' from cvs server > cvs [checkout aborted]: end of file from server (consult above messages if any) > > That didn't work either. Anyone got any other ideas? > > I seem to have CVS 1.10.7. The response looks like the bare text you get when you "ssh" directly to the server. It prints some stuff then closes the connection. This would indicate to me that your CVS isn't passing the command over to the SF machine. Put this file into, say, /tmp/ssh-verbose: #!/bin/bash echo COMMAND: $@ exec /usr/bin/ssh -v $@ then do: $ export CVS_RSH=/tmp/ssh-verbose $ cvs ... same as above You should get a long stream of debug output. Right after you enter your password, you should see a couple lines like: debug: Sending command: cvs server debug: Entering interactive session. If not, then I'd suspect the CVS is invoking SSH incorrectly. The first line of output should look like: cvs log: warning: unrecognized response `COMMAND: cvs.python.sourceforge.net -l gstein cvs server' from cvs server That `... cvs server' in the command string is the key. I suspect those two words aren't in your command string, so SSH is just opening an interactive shell. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gward at mems-exchange.org Thu Jul 6 15:23:41 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 09:23:41 -0400 Subject: [Python-Dev] Re: [Zope-dev] ExtensionClass and __radd__()? In-Reply-To: ; from pavlos@gaaros.com on Thu, Jul 06, 2000 at 08:46:50AM -0400 References: <20000705183046.A26381@ludwig.cnri.reston.va.us> Message-ID: <20000706092340.B1539@ludwig.cnri.reston.va.us> On 06 July 2000, Pavlos Christoforou said: > A quick note which you probably already know: > > grep add ExtensionClass.c gives: [...lots...] > whereas grep radd ExtensionClass.c returns nothing Yep, did the same myself shortly after posting. It's not really clear what 'py__add__' is and how it works, though, so it's not obvious if 'py__radd__' is the right thing to add, and if so how to add it. Greg If it's just a matter of adding radd (and rsub, rmul, and rdiv) in all those places -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From skip at mojam.com Thu Jul 6 15:54:40 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 08:54:40 -0500 (CDT) Subject: [Python-Dev] how do I release a cvs lock? Message-ID: <14692.36768.23073.781592@beluga.mojam.com> Sjoerd & Fred both let me know that I am locking the Modules directory. How do I unlock it? The "cvs admin" command looks potentially promising, but very low-level. Skip From moshez at math.huji.ac.il Thu Jul 6 15:55:12 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 6 Jul 2000 16:55:12 +0300 (IDT) Subject: Viewing Patches on UNIX Machines (was Re: [Python-Dev] oh, and any interest in my readline history stuff?) In-Reply-To: <14691.54757.459091.820551@beluga.mojam.com> Message-ID: On Wed, 5 Jul 2000, Skip Montanaro wrote: > https://sourceforge.net/patch/?func=detailpatch&patch_id=100742&group_id=5470 I'm using the attached program to watch patches. run like python patch.py 100742 (UNIX only currently, sorry) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. -------------- next part -------------- def get_patch(number): import urllib return urllib.urlopen("http://sourceforge.net/patch/download.php?id=%s" % number) def show_file(file): import os less = os.popen("less", 'w') try: while 1: buf = file.read(4096) if not buf: break less.write(buf) finally: less.close() def show_patch(number): try: patch = get_patch(number) show_file(patch) finally: patch.close() def main(): import sys show_patch(sys.argv[1]) if __name__ == '__main__': main() From fdrake at beopen.com Thu Jul 6 16:03:38 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 10:03:38 -0400 (EDT) Subject: [Python-Dev] Bogus lock in Modules directory Message-ID: <14692.37306.880611.330267@cj42289-a.reston1.va.home.com> There's a bogus read lock in dist/src/Modules from last night; I've confirmed that it's bogus with Skip (whose lock it is), and filed a support request with SourceForge (#103231) to have it removed. I'll let everyone know when this is cleared. You should still be able to pick up updates without problems, but you can't check anything in in the Modules/ directory until this is cleared (because CVS won't let you). The link to the support request is: http://sourceforge.net/support/?func=detailsupport&support_id=103231&group_id=1 -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein at lyra.org Thu Jul 6 16:06:28 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 07:06:28 -0700 Subject: [Python-Dev] how do I release a cvs lock? In-Reply-To: <14692.36768.23073.781592@beluga.mojam.com>; from skip@mojam.com on Thu, Jul 06, 2000 at 08:54:40AM -0500 References: <14692.36768.23073.781592@beluga.mojam.com> Message-ID: <20000706070628.X29590@lyra.org> On Thu, Jul 06, 2000 at 08:54:40AM -0500, Skip Montanaro wrote: > Sjoerd & Fred both let me know that I am locking the Modules directory. How > do I unlock it? The "cvs admin" command looks potentially promising, but > very low-level. If it is an adminstrative-lock, then yes: cvs admin is the trick. But I don't think you can do that on a directory. So... it is probably a bungled directory-lock (e.g. it didn't get cleaned up). If so... then we probably need some SF admins to clean it up. Hmm. I just did a "cvs update" in the Modules directory. No problem. Sjoerd, Fred? What exactly are you referring to? I see nothing... (maybe Skip cleared it already?) Cheers, -g -- Greg Stein, http://www.lyra.org/ From fredrik at pythonware.com Thu Jul 6 16:11:38 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 16:11:38 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> Message-ID: <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> I wrote: > > both modules can be squeezed down to almost nothing. > it just takes a little work. > > fwiw, Tcl's version of the unicodectype file is about 30k, > and compiles to an 8k large object file on my win95 box. Just noticed that _sre.c takes ages to compile on my linux box, and comes out as a 450k object module. it's under 30k on Windows. Methinks gcc expands recursive inlined functions a bit more than visual C. I'll try do get it down under 100k before the final release... From guido at beopen.com Thu Jul 6 17:15:53 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 10:15:53 -0500 Subject: [Python-Dev] how do I release a cvs lock? In-Reply-To: Your message of "Thu, 06 Jul 2000 08:54:40 EST." <14692.36768.23073.781592@beluga.mojam.com> References: <14692.36768.23073.781592@beluga.mojam.com> Message-ID: <200007061515.KAA13255@cj20424-a.reston1.va.home.com> > Sjoerd & Fred both let me know that I am locking the Modules directory. How > do I unlock it? The "cvs admin" command looks potentially promising, but > very low-level. I doubt that cvs admin can help you -- it interfaces to rcs, which doesn't do per-directory locking. More likely a lock file used when you made a checkin or checkout is accidentally left behind. I believe you cannot remove this yourself nor can I help you with it ([re]moving files in the CVS repository tree is not for mere mortals). Submit a service request, they usually take care of it within a few hours. (Click in the "Request Support" entry in the SourceForge section of the left sidebar.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jim at digicool.com Thu Jul 6 16:25:10 2000 From: jim at digicool.com (Jim Fulton) Date: Thu, 06 Jul 2000 10:25:10 -0400 Subject: [Python-Dev] Comparison inconsistency with ExtensionClass References: <20000501184017.A1171@mems-exchange.org> Message-ID: <396496C6.82804F84@digicool.com> Greg Ward wrote: > > Hi all -- > > I seem to have discovered an inconsistency in the semantics of object > comparison between plain old Python instances and ExtensionClass > instances. (I've cc'd python-dev because it looks as though one *could* > blame Python for the inconsistency, but I don't really understand the > guts of either Python or ExtensionClass enough to know.) (demonstration snipped) > The first one and the last two are obvious, but the second one only > works thanks to a trick in PyObject_Compare(): > > if (PyInstance_Check(v) || PyInstance_Check(w)) { > ... > if (!PyInstance_Check(v)) > return -PyObject_Compare(w, v); > ... > } > > However, if I make Simple an ExtensionClass: > > from ExtensionClass import Base > > class Simple (Base): > > Then the "swap v and w and use w's comparison method" no longer works. > Here's the output of the script with Simple as an ExtensionClass: > > v1 == v2? no > v2 == v1? Simple.__cmp__: self=, other=36 > yes > v1 == v2.data? yes > v2.data == v1? yes > > It looks as though ExtensionClass would have to duplicate the trick in > PyObject_Compare() that I quoted, since Python has no idea that > ExtensionClass instances really should act like instances. This smells > to me like a bug in ExtensionClass. Comments? Technically, this *is* a bug in ExtensionClass, however, Python *does* deserve some of the blame. The intepreter actually uses the following rule: Instances of two different "python types" are not compared using type-supplied comparison methods unless: - At least one of the types is InstanceType or - Both of the types are numeric. This rule is rather inconvenient for ExtensionClass. It's also pretty inconvenient for non-ExtensionClass non-numeric extension types that want to be comparable with other things. You can work around this by making your ExtensionClass a numeric type. This should be possible by providing a numeric method. Jim -- Jim Fulton mailto:jim at digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From tismer at appliedbiometrics.com Thu Jul 6 16:33:59 2000 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Thu, 06 Jul 2000 16:33:59 +0200 Subject: [Python-Dev] how do I release a cvs lock? References: <14692.36768.23073.781592@beluga.mojam.com> <200007061515.KAA13255@cj20424-a.reston1.va.home.com> Message-ID: <396498D7.97ABB543@appliedbiometrics.com> Guido van Rossum wrote: > > > Sjoerd & Fred both let me know that I am locking the Modules directory. How > > do I unlock it? The "cvs admin" command looks potentially promising, but > > very low-level. > > I doubt that cvs admin can help you -- it interfaces to rcs, which > doesn't do per-directory locking. > > More likely a lock file used when you made a checkin or checkout is > accidentally left behind. I believe you cannot remove this yourself > nor can I help you with it ([re]moving files in the CVS repository > tree is not for mere mortals). Submit a service request, they usually > take care of it within a few hours. (Click in the "Request Support" > entry in the SourceForge section of the left sidebar.) Do we really want to live on with SourceForge(t) ? It seems to be pleasant for small projects, but maybe it would be more convenient to have a CVS that we control directly? The new starship is very powerful and could stand a couple of CVS repositories easily. While one might argue that this would give to much of Python to BeOpen (they got it already:), I think this could work smoothly. ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From guido at beopen.com Thu Jul 6 17:32:32 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 10:32:32 -0500 Subject: [Python-Dev] Comparison inconsistency with ExtensionClass In-Reply-To: Your message of "Thu, 06 Jul 2000 10:25:10 -0400." <396496C6.82804F84@digicool.com> References: <20000501184017.A1171@mems-exchange.org> <396496C6.82804F84@digicool.com> Message-ID: <200007061532.KAA13361@cj20424-a.reston1.va.home.com> [JimF] > Technically, this *is* a bug in ExtensionClass, however, Python > *does* deserve some of the blame. The intepreter actually uses the > following rule: > > Instances of two different "python types" are not compared > using type-supplied comparison methods unless: > > - At least one of the types is InstanceType or > > - Both of the types are numeric. > > This rule is rather inconvenient for ExtensionClass. > It's also pretty inconvenient for non-ExtensionClass > non-numeric extension types that want to be comparable with > other things. > > You can work around this by making your ExtensionClass a numeric > type. This should be possible by providing a numeric method. Without having investigated all the details of this thread, I suspect that all of this ought to be rethought when we do rich comparisons and revamp coercions. I'd say that would be a good project for Python 2.1... (Which most of the Zopers probably still know as 1.7. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Thu Jul 6 16:33:23 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 10:33:23 -0400 (EDT) Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> Message-ID: <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > Just noticed that _sre.c takes ages to compile on my linux > box, and comes out as a 450k object module. > > it's under 30k on Windows. Wow! Maybe try turning off optimizations? I think there's an option to just turn off inlining, bt I don't know if you can limit the number of recursive inlines. A simpler option: surround the "inline" directive with #ifndef __GNUC__ / #endif. > Methinks gcc expands recursive inlined functions a bit more > than visual C. I'll try do get it down under 100k before the > final release... Now, if we could do that for unicodedata and ucnhash, a lot more people would be happy! Marc-Andre, Bill: Would it be reasonable to have perfect_hash.py actually compress the text strings used for the character names? Since there's such a limited alphabet in use, something special purpose would probably be easy and do a lot of good. When checking the lookup, you could easily decode the string in the table to do the comparison. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Thu Jul 6 17:37:42 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 10:37:42 -0500 Subject: [Python-Dev] how do I release a cvs lock? In-Reply-To: Your message of "Thu, 06 Jul 2000 16:33:59 +0200." <396498D7.97ABB543@appliedbiometrics.com> References: <14692.36768.23073.781592@beluga.mojam.com> <200007061515.KAA13255@cj20424-a.reston1.va.home.com> <396498D7.97ABB543@appliedbiometrics.com> Message-ID: <200007061537.KAA13448@cj20424-a.reston1.va.home.com> > Do we really want to live on with SourceForge(t) ? > It seems to be pleasant for small projects, but > maybe it would be more convenient to have a CVS > that we control directly? > The new starship is very powerful and could stand a couple of > CVS repositories easily. > > While one might argue that this would give to much of Python > to BeOpen (they got it already:), I think this could work > smoothly. In my experience, maintaining the repository, with both anonymous and privileged (commit) access, is a lot of work -- managing user accounts for the privileged, keeping the machine up and running, etc. I'm really quite happy with the level of support we get from SF. In the long run, BeOpen might be interested in running this kind of service for the Python and other communities; but for now, it would just be a burden. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Thu Jul 6 17:40:00 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 10:40:00 -0500 Subject: [Python-Dev] grumble, grumble - makesetup prepends leading $(srcdir) - why? In-Reply-To: Your message of "Wed, 05 Jul 2000 23:47:10 EST." <14692.3918.493708.366779@beluga.mojam.com> References: <14692.3918.493708.366779@beluga.mojam.com> Message-ID: <200007061540.KAA13487@cj20424-a.reston1.va.home.com> > Here's one that's bugged me for awhile that I'm tired of working around. > Perhaps someone can explain why makesetup does what it does. > > In my Modules/Setup.local file I have > > TOP=$(HOME)/src/python > EDIR=$(TOP)/PyExtensions1.5 > llop $(EDIR)/llopmodule.c # helper function(s) for latlong.py > > This gets converted into > > llopmodule.o: $(srcdir)/$(EDIR)/llopmodule.c; $(CC) $(CCSHARED) $(CFLAGS) -c $(srcdir)/$(EDIR)/llopmodule.c > llopmodule$(SO): llopmodule.o; $(LDSHARED) llopmodule.o -o llopmodule$(SO) > > in Modules/Makefile. Is there a good reason why is $(srcdir)/ prepended to > the source file reference, thus breaking my local module references? It > seems the culprit is > > case $src in > glmodule.c) ;; > /*) ;; > *) src='$(srcdir)/'$src;; > esac > > around about line 193. I think this should be changed to > > case $src in > glmodule.c) ;; > /*) ;; > \$*) ;; > *) src='$(srcdir)/'$src;; > esac > > or something similar that protects paths that begin with a Make variable. > That fix works for me. Any objections to me checking it in? Good idea. Go ahead. > Also, who died and made glmodule.c king? It was Jack & me. We're not dead yet! The reason is that glmodule.c is actually generated by a script that is run automatically from the Makefile. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Thu Jul 6 16:41:23 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 6 Jul 2000 16:41:23 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <14692.39091.731830.389350@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 10:33:23AM -0400 References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> Message-ID: <20000706164123.A26534@xs4all.nl> On Thu, Jul 06, 2000 at 10:33:23AM -0400, Fred L. Drake, Jr. wrote: > Fredrik Lundh writes: > > Just noticed that _sre.c takes ages to compile on my linux > > box, and comes out as a 450k object module. > > it's under 30k on Windows. > Wow! Maybe try turning off optimizations? I think there's an > option to just turn off inlining, bt I don't know if you can limit the > number of recursive inlines. A simpler option: surround the "inline" > directive with #ifndef __GNUC__ / #endif. gcc tries to inline functions itself, too, depending on optimization level, and it might be that the heuristics to determine wether it's worth it or not are broken. You can use -fno-inline to see if that's the case. But it might even be that gcc is right, that the larger code is faster, in spite of being larger. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Thu Jul 6 16:49:25 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 10:49:25 -0400 (EDT) Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <20000706164123.A26534@xs4all.nl> References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> <20000706164123.A26534@xs4all.nl> Message-ID: <14692.40053.417868.570920@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > even be that gcc is right, that the larger code is faster, in spite of being > larger. It may be faster, but that doesn't mean the tradeoff is right. ;) Ideally, this shouldn't take a lot of space, simply because we don't want to exclude platforms with substantial *memory* constraints. But we can let benchmarkers decide what the right tradeoff it; the size isn't that big of a concern for me. (I made the right tradeoff -- I traded empty memory slots for filled ones! 512MB is a nice start. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Thu Jul 6 16:53:22 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 10:53:22 -0400 (EDT) Subject: [Python-Dev] how do I release a cvs lock? References: <14692.36768.23073.781592@beluga.mojam.com> <200007061515.KAA13255@cj20424-a.reston1.va.home.com> <396498D7.97ABB543@appliedbiometrics.com> Message-ID: <14692.40290.628899.363800@anthem.concentric.net> >>>>> "CT" == Christian Tismer writes: CT> Do we really want to live on with SourceForge(t) ? It seems CT> to be pleasant for small projects, but maybe it would be more CT> convenient to have a CVS that we control directly? The new CT> starship is very powerful and could stand a couple of CVS CT> repositories easily. CT> While one might argue that this would give to much of Python CT> to BeOpen (they got it already:), I think this could work CT> smoothly. I think for now SF is our home. Trying to move anything at this point would burn much more time than we have. We really want to get releases out asap! At some point we might look at a couple of alternatives, such as: create our own site based on the SF code base; help SF improve their s/w more directly; roll our own using better Python-based tools. -Barry From bwarsaw at beopen.com Thu Jul 6 16:55:36 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 10:55:36 -0400 (EDT) Subject: [Python-Dev] Comparison inconsistency with ExtensionClass References: <20000501184017.A1171@mems-exchange.org> <396496C6.82804F84@digicool.com> Message-ID: <14692.40424.736713.740441@anthem.concentric.net> >>>>> "JF" == Jim Fulton writes: JF> Instances of two different "python types" are not compared JF> using type-supplied comparison methods unless: JF> - At least one of the types is InstanceType or JF> - Both of the types are numeric. JF> This rule is rather inconvenient for ExtensionClass. JF> It's also pretty inconvenient for non-ExtensionClass JF> non-numeric extension types that want to be comparable with JF> other things. I ran into this problem when trying to translate a simple Boolean class into a built-in type. I basically could not get the comparisons to work correctly when I moved to C. So I'm +1 on fixing this at some point (probably as Guido points out, when we add rich comparisons). -Barry From gward at mems-exchange.org Thu Jul 6 17:03:26 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 11:03:26 -0400 Subject: [Python-Dev] help wanted: windows locales In-Reply-To: <00fa01bfe6b5$a8400460$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jul 05, 2000 at 09:17:20PM +0200 References: <00fa01bfe6b5$a8400460$f2a6b5d4@hagrid> Message-ID: <20000706110326.A9547@ludwig.cnri.reston.va.us> On 05 July 2000, Fredrik Lundh said: > windows_lang = { [...] > 0x042d: "eu_ES", # Basque Isn't Basque also spoken in France? > 0x0445: "bn_??", # Bengali Bangladesh I think; possibly India as well. Don't know the country code for Bangladesh. > 0x2809: "en"_BZ, # English (Belize) ^ ^ typo? > 0x0447: "gu_??", # Gujarati I think this is an Indian language too. > 0x043f: "kk_??", # Kazakh If I had to hazard a guess, I'd say Kazakhstan. ;-) > 0x0446: "pa_??", # Punjabi Probably India and Pakistan both. Would it be overkill to allow mapping one Windows hex code to two locale codes, eg. 0x0446 -> ("pa_IN", "pa_PK")? Better not bring up Kashmiri -- if you thought the politics of spelling English was touchy... ;-) Greg From jim at digicool.com Thu Jul 6 17:06:49 2000 From: jim at digicool.com (Jim Fulton) Date: Thu, 06 Jul 2000 11:06:49 -0400 Subject: [Python-Dev] ExtensionClass and __radd__()? References: <20000705183046.A26381@ludwig.cnri.reston.va.us> Message-ID: <3964A089.A8347970@digicool.com> Greg Ward wrote: > > Hi all -- > > looks like ExtensionClass doesn't recognize/implement the '__radd__()' > protocol. Speculation below; first, a demonstration. Normal case: a > regular class Number that knows how to add itself to other number-like > things: (demonstration snipped) > Speculation time: I'm guessing that this is similar to the problem with > 'isinstance()' and ExtensionClass that I found several months ago, which > was heroically debugged by Barry. To recap, it's a mutual > finger-pointing bug: Python (Guido) can claim that it's up to > ExtensionClass (Jim) to emulate the full semantics of Python > classes/instances, but ExtensionClass can claim that Python should be > more relaxed in what it accepts as a "class object" or "instance > object". > > I think the relevant code in Python is in Objects/abstract.c, > specifically 'PyNumber_Add()' and the BINOP macro: > > #define BINOP(v, w, opname, ropname, thisfunc) \ > if (PyInstance_Check(v) || PyInstance_Check(w)) \ > return PyInstance_DoBinOp(v, w, opname, ropname, thisfunc) > > [...] > PyNumber_Add(v, w) > PyObject *v, *w; > { > PySequenceMethods *m; > > BINOP(v, w, "__add__", "__radd__", PyNumber_Add); > [...] > > My guess is that PyInstance_Check() returns false for ExtensionClass > instances. Two possible fixes: loosen up PyInstance_Check(), or loosen > up BINOP. > > Well, it's a nice theory. It doesn't explain why '__add__()' works for > ExtensionClass while '__radd__()' does not; perhaps ExtensionClass > implements that much of Python's class semantics, but doesn't go as far > as '__radd__()'. I'd love to see __radd__ added. ;) I don't remember why it's not there. Maybe I was just lazy. It may be fairly hard to add. I haven't looked in quite a while. As anyone whos looked at ExtensionClass sources may be able to tell, ExtensionClass has to play quite a few tricks to: - Try to sanely bridge the quite different semantics of Python "types" and "classes" (e.g. there's no radd for "types"). - Try to overcome the fact that the interpreter special-cases InstanceType and ClassType pretty liberally. To (try to and mostly succeed to) provide instance semantics I have to do alot of weird indirection. This is especially hard for numeric things. Your analysis of the code demonstrates this issue. ExtensionClass instances are not of type InstanceType. In fact, each ExtensionClass is a separate type and instances of different ExtensionClasses have different types. Note that I just got around to responding to your earlier post "Comparison inconsistency with ExtensionClass". This has a similar root cause: the special-case treatment of InstanceType. I think that the *real* solution to this problem is to get rid of ExtensionClass. ;) To do this, I need to get the features I have in ExtensionClass into Python. I guess there's some hope for that in Python 3K (love that name :). In the mean time, I don't have time to fix the radd problem myself, but would be willing to advise someone who wanted to try to take it on, especially if we could work out some phone or face-to-face sessions. Jim -- Jim Fulton mailto:jim at digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From fredrik at pythonware.com Thu Jul 6 17:09:42 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 17:09:42 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid><00c801bfe754$1a6f8ad0$0900a8c0@SPIFF><14692.39091.731830.389350@cj42289-a.reston1.va.home.com><20000706164123.A26534@xs4all.nl> <14692.40053.417868.570920@cj42289-a.reston1.va.home.com> Message-ID: <013901bfe75c$37eed630$0900a8c0@SPIFF> fred wrote: > Thomas Wouters writes: > > even be that gcc is right, that the larger code is faster, in spite of being > > larger. > > It may be faster, but that doesn't mean the tradeoff is right. ;) > Ideally, this shouldn't take a lot of space, simply because we don't > want to exclude platforms with substantial *memory* constraints. yeah, but people porting SRE to small platforms can switch off inlining completely. if I do that on windows, the resulting DLL is less than 20k. which is pretty okay, I think, if you consider that the DLL contains two separate regular expression engines, a scanner framework, and lots of other stuff... cheers /F From paul at prescod.net Thu Jul 6 17:12:30 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 06 Jul 2000 10:12:30 -0500 Subject: [Python-Dev] list comprehensions again... References: <14691.49563.78765.683762@beluga.mojam.com> <200007060042.TAA06919@cj20424-a.reston1.va.home.com> Message-ID: <3964A1DE.F0878306@prescod.net> Guido van Rossum wrote: > > > Was there a public announcement made about new functionality for > > 2.0? > > Yes, there's something on http://pythonlabs.com/tech/python2.html. We > currently can't commit to a release schedule due to the problems with > CNRI. Between now and the release, someone needs to add something there about the XML support. In general, it is in the interest of the Python community (and of course, my personal interest!) to emphasize Python's XML sophistication. From a marketing point of view, the new XML support could be pushed as sufficient reason for a major version release all by itself. For instance, Even the Guido is impressed when he reads vacuous XML-related press releases from the TCL guys.[1] :) :) Python 2 could be the first language with support for SAX and DOM in the class libraries (though Java is catching fast) and the first to ship Expat as a standard module (on some platforms, anyhow). If the feature freeze "melts", we could probably add SOAP support in a month or so also. [1]http://www.python.org/pipermail/xml-sig/1999-October/003167.html (to be fair, I don't know that the TCL stuff is vacuous, I just presume that any "B2B integration server" is likely to be vacuous...) -- Paul Prescod - Not encumbered by corporate consensus The distinction between the real twentieth century (1914-1999) and the calenderical one (1900-2000) is based on the convincing idea that the century's bouts of unprecented violence, both within nations and between them, possess a definite historical coherence -- that they constitute, to put it simply, a single story. - The Unfinished Twentieth Century, Jonathan Schell Harper's Magazine, January 2000 From esr at thyrsus.com Thu Jul 6 17:27:21 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 11:27:21 -0400 Subject: [Python-Dev] help wanted: windows locales In-Reply-To: <20000706110326.A9547@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Thu, Jul 06, 2000 at 11:03:26AM -0400 References: <00fa01bfe6b5$a8400460$f2a6b5d4@hagrid> <20000706110326.A9547@ludwig.cnri.reston.va.us> Message-ID: <20000706112721.B25443@thyrsus.com> Greg Ward : > > 0x0447: "gu_??", # Gujarati > > I think this is an Indian language too. > > > 0x043f: "kk_??", # Kazakh > > If I had to hazard a guess, I'd say Kazakhstan. ;-) > > > 0x0446: "pa_??", # Punjabi > > Probably India and Pakistan both. Correct on all counts. -- Eric S. Raymond Love your country, but never trust its government. -- Robert A. Heinlein. From fdrake at beopen.com Thu Jul 6 17:50:47 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 11:50:47 -0400 (EDT) Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <013901bfe75c$37eed630$0900a8c0@SPIFF> References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> <20000706164123.A26534@xs4all.nl> <14692.40053.417868.570920@cj42289-a.reston1.va.home.com> <013901bfe75c$37eed630$0900a8c0@SPIFF> Message-ID: <14692.43735.835843.916140@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > yeah, but people porting SRE to small platforms can switch off > inlining completely. if I do that on windows, the resulting DLL > is less than 20k. So don't worry about the 100K for Linux/x86 unless you just want to test that -fno-inline (or whatever) is passed from the Setup file to the Makefile without makesetup barfing on it. (Not unusual for less common flags, but I think -f* is passed along.) > which is pretty okay, I think, if you consider that the DLL contains > two separate regular expression engines, a scanner framework, and > lots of other stuff... 20K -- 40K I'm not worried about. I'm less worried about the people with *no* RAM, who will run into problems before they try to start python, than about the guys with only a little RAM (say, 128MB ;). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jul 6 18:00:44 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 12:00:44 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <3964A1DE.F0878306@prescod.net> References: <14691.49563.78765.683762@beluga.mojam.com> <200007060042.TAA06919@cj20424-a.reston1.va.home.com> <3964A1DE.F0878306@prescod.net> Message-ID: <14692.44332.771745.446084@cj42289-a.reston1.va.home.com> Paul Prescod writes: > Between now and the release, someone needs to add something there about > the XML support. In general, it is in the interest of the Python > community (and of course, my personal interest!) to emphasize Python's > XML sophistication. From a marketing point of view, the new XML support > could be pushed as sufficient reason for a major version release all by > itself. For instance, Even the Guido is impressed when he reads vacuous > XML-related press releases from the TCL guys.[1] :) :) I've written a bit of text for Guido about this, but it's fairly short. If you, Lars, Andrew or anyone else from the XML gang would like to take a crack at it, here's what I've sent Guido: ------------------------------------------------------------------------ XML Support ........... Python 2.0 introduces new XML tools developed by the XML Special Interest Group (http://www.python.org/sigs/xml-sig/). The widely-accepted Expat XML parser from James Clark is used to provide a high-performance, non-validating parser to Python applications. This parser provides full Unicode support in compliance with the XML 1.0 specification. Interfaces are provided to work with the most widely accepted interfaces defined by the XML community: SAX, the Simple API for XML (http://www.megginson.com/SAX/) and DOM, the Document Object Model Level 1 (http://www.w3.org/TR/REC-DOM-Level-1/). ------------------------------------------------------------------------ > Python 2 could be the first language with support for SAX and DOM in the > class libraries (though Java is catching fast) and the first to ship > Expat as a standard module (on some platforms, anyhow). If the feature An excellent point we'd do well to capitalize on -- a lot of people interested in using XML would switch from other langs for this reason, I suspect. > [1]http://www.python.org/pipermail/xml-sig/1999-October/003167.html > (to be fair, I don't know that the TCL stuff is vacuous, I just presume > that any "B2B integration server" is likely to be vacuous...) That's a reasonable presumption, but I wouldn't make large bets on it either. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From akuchlin at mems-exchange.org Thu Jul 6 18:12:31 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 6 Jul 2000 12:12:31 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.680.483792.544003@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Wed, Jul 05, 2000 at 11:53:12PM -0400 References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> <14692.680.483792.544003@cj42289-a.reston1.va.home.com> Message-ID: <20000706121231.A14042@kronos.cnri.reston.va.us> On Wed, Jul 05, 2000 at 11:53:12PM -0400, Fred L. Drake, Jr. wrote: >Barry A. Warsaw writes: > > Think of all the new features added in 1.5.2 (a /micro/ release for > > gawds' sake). In retrospect, that was nutty. > Are you saying we should re-label that 1.6? That may prove... >convenient. ;) I've been privately wondering about making a new tarball of 1.5.2 that simply adds the Lib/distutils/ subdirectory and installs it, so people who don't want to risk the jump to 2.0 can still get the nice Distutils features. The problem is that it would take substantial willpower to only make that change; the temptation would be great to fix just this one really annoying bug, oh, and this little feature wouldn't break anything, and ... --amk From esr at thyrsus.com Thu Jul 6 18:21:22 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 12:21:22 -0400 Subject: [Python-Dev] urllib.browse() issues Message-ID: <20000706122122.A25613@thyrsus.com> Having finally wrestled CVS into at least temporary submission, I'm in the process of generating a patch to add a browser-launcher function to the standard library. There are a couple of issues connected to this. One: location. I still think, after meditating on it, that urllib and not os is the right place for this. Yes, it launches a process -- but that's implementation. It's a way to fetch the contents of an URL. In the potential *user's* view of the Python library, it belongs with other ways to fetch URLs. Two: cross-platform capability is a Good Thing. I rummaged around after a half-forgotten bit of lore in my files and discovered an allegation that under Windows, os.system("start %s" % url) is supposed to launch your default browser on the specified URL. Now here's what I'd like to write: if os.environ.has_key("BROWSER"): _browsers = string.split(os.environ["BROWSER"], ":") elif os.name == 'posix': _browsers = ["mozilla %s &", "netscape -remote 'openURL(%s)'", "netscape %s &", "lynx %s &", "w3m %s &"] elif os.name == 'nt': _browsers = ["start %s"] def urlbrowse(url): """Launch a browser, in background, pointed at the given URL. Accept either a string or a parsed URL tuple. Interpret the BROWSER environment variable, if it exists, as a colon-separated list of browser commands to try. """ from urlparse import urlunparse if type(url) == (): url = urlunparse(url) for browser in _browsers: if iscommand(string.split(browser)[0]): if os.system((browser % url)) == 0: return 1 return 0 The missing piece of implementation is the function iscommand(). I know how to write this under Unix: def iscommand(cmd): return os.system('which 1>/dev/null 2>&1 ' + cmd) == 0 So my question is this: is there any analogous way to check for the existence of a command under Windows? If so... Three: I'd like to add a cross-platform iscommand() function to os. -- Eric S. Raymond There's a truism that the road to Hell is often paved with good intentions. The corollary is that evil is best known not by its motives but by its *methods*. From akuchlin at mems-exchange.org Thu Jul 6 18:13:42 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 6 Jul 2000 12:13:42 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.44332.771745.446084@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 12:00:44PM -0400 References: <14691.49563.78765.683762@beluga.mojam.com> <200007060042.TAA06919@cj20424-a.reston1.va.home.com> <3964A1DE.F0878306@prescod.net> <14692.44332.771745.446084@cj42289-a.reston1.va.home.com> Message-ID: <20000706121342.B14042@kronos.cnri.reston.va.us> >On Thu, Jul 06, 2000 at 12:00:44PM -0400, Fred L. Drake, Jr. wrote: > I've written a bit of text for Guido about this, but it's fairly >short. If you, Lars, Andrew or anyone else from the XML gang would >like to take a crack at it, here's what I've sent Guido: That looks fine for the README or Misc/NEWS file. I want to write a section of the "What's New" article that goes into greater detail, shows some simple examples of parsing things, etc., but haven't gotten around to it yet. --amk From mal at lemburg.com Thu Jul 6 18:17:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 18:17:26 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> Message-ID: <3964B116.44E1606E@lemburg.com> "Fred L. Drake, Jr." wrote: > > Now, if we could do that for unicodedata and ucnhash, a lot more > people would be happy! > Marc-Andre, Bill: Would it be reasonable to have perfect_hash.py > actually compress the text strings used for the character names? > Since there's such a limited alphabet in use, something special > purpose would probably be easy and do a lot of good. When checking > the lookup, you could easily decode the string in the table to do the > comparison. I don't have the time to look into this, sorry. Other things are more important now, like changing the handling of the 's' and 't' parser markers for Unicode from UTF-8 to default encoding. This will complete the move from a fixed internal encoding to a locale dependent setting and should fix most problems people have noticed on their platforms. BTW, does the XML package already use the builtin Unicode support ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 6 18:28:12 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 18:28:12 +0200 Subject: [Python-Dev] Hash values and comparing objects Message-ID: <3964B39C.7E0CD312@lemburg.com> There currently is a problem with the Unicode objects which I'd like to resolve: Since Unicode object are comparable to strings, they should have the same hash value as their string correspondents (the 8-bit strings which compare equal -- this can depend on the default encoding which again depends on the locale setting). Previously, Unicode used UTF-8 as basis for calculating the hash value (the Unicode object created a UTF-8 string object and delegated the hash value calculation to it, caching the result and the string for future use). Since I would like to make the internal encoding cache use the default encoding instead, I have two problems to solve: 1. It is sometimes not possible to encode the Unicode value using the default encoding. A different strategy for calculating the hash value would have to be used. 2. In some locales '???' == u'???' is true, while in others this is not the case. If they do compare equal, the hash values must match. How serious is the need for objects which compare equal to have the same hash value ? (I would much prefer to calculate the hash value using the internal UTF-16 buffer rather than first creating an encoded string.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 6 18:33:55 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 18:33:55 +0200 Subject: [Python-Dev] urllib.browse() issues References: <20000706122122.A25613@thyrsus.com> Message-ID: <3964B4F3.5EE72F14@lemburg.com> "Eric S. Raymond" wrote: > > Having finally wrestled CVS into at least temporary submission, > I'm in the process of generating a patch to add a browser-launcher > function to the standard library. There are a couple of issues > connected to this. Eric, please have a look at Tools/idle/BrowserControl.py... it has all you need and can easily be extended to support more browsers. Might be a good candidate for the std lib if you ask me -- after a rename to say "browser.py". -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Thu Jul 6 18:51:51 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 12:51:51 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964B4F3.5EE72F14@lemburg.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> Message-ID: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Might be a good candidate for the std lib if you ask me -- > after a rename to say "browser.py". Agh! That was my original name for it! Guido wanted me to change it since that didn't describe it well (there's not a single browser implementation in there ;). browsercntl seems... ugly. I'd welcome suggestions for short, lower-case names, though. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jul 6 18:53:19 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 12:53:19 -0400 (EDT) Subject: [Python-Dev] forwarded message from noreply@sourceforge.net Message-ID: <14692.47487.15354.645423@cj42289-a.reston1.va.home.com> The bogus CVS lock in Modules/ is now fixed! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- An embedded message was scrubbed... From: noreply at sourceforge.net Subject: [ 103231 ] bogus directory lock Date: Thu, 6 Jul 2000 09:44:04 -0700 Size: 1840 URL: From ping at lfw.org Thu Jul 6 19:30:05 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 6 Jul 2000 10:30:05 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <20000705183353.B7564@ludwig.cnri.reston.va.us> Message-ID: On Wed, 5 Jul 2000, Greg Ward wrote: > > SyntaxError: expected indent > > SyntaxError: expected unindent The "expected indent" message seems a little abrupt to me (does it mean there's a problem because an indent is expected, or a problem with an indent that was expected, or a problem because an expected indent isn't there?) so i have changed it to SyntaxError: expected an indented block The latter case, "expected unindent", never occurs -- it is always okay to continue an indented block, so a DEDENT is never absolutely required. The rest of the messages now say "unindent" instead of "dedent". I've updated the patch. -- ?!ng "To be human is to continually change. Your desire to remain as you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From esr at thyrsus.com Thu Jul 6 19:39:57 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 13:39:57 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964B4F3.5EE72F14@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 06:33:55PM +0200 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> Message-ID: <20000706133957.C25726@thyrsus.com> M.-A. Lemburg : > "Eric S. Raymond" wrote: > > > > Having finally wrestled CVS into at least temporary submission, > > I'm in the process of generating a patch to add a browser-launcher > > function to the standard library. There are a couple of issues > > connected to this. > > Eric, please have a look at Tools/idle/BrowserControl.py... > it has all you need and can easily be extended to support > more browsers. It's kind of sideways to what I'm trying to accomplish in some ways -- but yes, I see some useful tricks in there. Perhapsa I'll try to clean this up into a browser.py. -- Eric S. Raymond The difference between death and taxes is death doesn't get worse every time Congress meets -- Will Rogers From mal at lemburg.com Thu Jul 6 19:37:31 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 19:37:31 +0200 Subject: [Python-Dev] urllib.browse() issues References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> Message-ID: <3964C3DB.B57E95F9@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > Might be a good candidate for the std lib if you ask me -- > > after a rename to say "browser.py". > > Agh! That was my original name for it! Guido wanted me to change > it since that didn't describe it well (there's not a single browser > implementation in there ;). Um, there's not a single OS implementation in os.py either ;-) I think it describes things well enough if you write browser.open('http://www.python.org/') Perhaps the interface should be a bit more RPC like, though... something like: b = browser.connect() b.open(http://www.python.org/') b.close() > browsercntl seems... ugly. I'd welcome suggestions for short, > lower-case names, though. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping at lfw.org Thu Jul 6 19:44:43 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 6 Jul 2000 10:44:43 -0700 (PDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> Message-ID: On Thu, 6 Jul 2000, Fred L. Drake, Jr. wrote: > browsercntl seems... ugly. I'd welcome suggestions for short, > lower-case names, though. browsing.py? -- ?!ng From esr at thyrsus.com Thu Jul 6 19:56:03 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 13:56:03 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: ; from ping@lfw.org on Thu, Jul 06, 2000 at 10:44:43AM -0700 References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> Message-ID: <20000706135603.A26040@thyrsus.com> Ka-Ping Yee : > On Thu, 6 Jul 2000, Fred L. Drake, Jr. wrote: > > browsercntl seems... ugly. I'd welcome suggestions for short, > > lower-case names, though. > > browsing.py? I like it. -- Eric S. Raymond "...The Bill of Rights is a literal and absolute document. The First Amendment doesn't say you have a right to speak out unless the government has a 'compelling interest' in censoring the Internet. The Second Amendment doesn't say you have the right to keep and bear arms until some madman plants a bomb. The Fourth Amendment doesn't say you have the right to be secure from search and seizure unless some FBI agent thinks you fit the profile of a terrorist. The government has no right to interfere with any of these freedoms under any circumstances." -- Harry Browne, 1996 USA presidential candidate, Libertarian Party From fdrake at beopen.com Thu Jul 6 19:58:00 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 13:58:00 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964C3DB.B57E95F9@lemburg.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> Message-ID: <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Um, there's not a single OS implementation in os.py either ;-) Good point; we should fix that. ;) > I think it describes things well enough if you write > > browser.open('http://www.python.org/') > > Perhaps the interface should be a bit more RPC like, though... > something like: > > b = browser.connect() > b.open(http://www.python.org/') > b.close() How about: b = browser.get() b.open("http://www.python.org/") That has the advantage of working with the existing code. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas at xs4all.net Thu Jul 6 20:09:24 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 6 Jul 2000 20:09:24 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 In-Reply-To: <20000706142731.K13478@xs4all.nl>; from thomas@xs4all.net on Thu, Jul 06, 2000 at 02:27:32PM +0200 References: <200007052256.PAA12103@slayer.i.sourceforge.net> <14691.65439.950090.60795@anthem.concentric.net> <20000706142731.K13478@xs4all.nl> Message-ID: <20000706200924.B26534@xs4all.nl> On Thu, Jul 06, 2000 at 02:27:32PM +0200, Thomas Wouters wrote: > PyObject_INIT((PyObject *)b, &PyBuffer_Type); > > The 'value computed' is useless. The value computed is computed by the ',' > operator, but the only things in there are sideffect operators. The last > operation in the string of ',''s is either a void-returning function or an > assignment, so I'd classify this one as a cosmetic bug in gcc ;) adding a > '(void)' cast to the PyObject_INIT() macro or the calls to it would fix the > warning. Er, ignore that. The value computed isn't useless, it's just the first argument. I overlooked that, sorry :P The return value is used in a couple of places. That leaves only one option to squench this warning, a (void) cast at the one spot that causes a warning. Or is there a better way ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Thu Jul 6 18:47:15 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 11:47:15 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc/templates module.tex,1.20,1.21 In-Reply-To: <200007061612.JAA11764@slayer.i.sourceforge.net> References: <200007061612.JAA11764@slayer.i.sourceforge.net> Message-ID: <14692.47123.218360.100174@beluga.mojam.com> Fred> *** 130,135 **** Fred> % detailed list of functions.) Fred> ! \subsection{Example} Fred> ! \nodename{Spam Example} Fred> The following example demonstrates how to open a can of spam using the Fred> --- 132,136 ---- Fred> % detailed list of functions.) Fred> ! \subsection{Example \label{spam-example}} Fred, I pulled the incorrect usage from libsocket.tex. Should all examples be changed to match? Skip From fdrake at beopen.com Thu Jul 6 20:25:52 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 14:25:52 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc/templates module.tex,1.20,1.21 In-Reply-To: <14692.47123.218360.100174@beluga.mojam.com> References: <200007061612.JAA11764@slayer.i.sourceforge.net> <14692.47123.218360.100174@beluga.mojam.com> Message-ID: <14692.53040.729280.724075@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > I pulled the incorrect usage from libsocket.tex. Should all examples be > changed to match? I'll go ahead and fix the socket documentation (I've made the changes already), but I wouldn't spend time looking for more instances. They can be fixed on an as-needed basis I think; there's enough real work to be done! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From moshez at math.huji.ac.il Thu Jul 6 20:42:40 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 6 Jul 2000 21:42:40 +0300 (IDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964B4F3.5EE72F14@lemburg.com> Message-ID: On Thu, 6 Jul 2000, M.-A. Lemburg wrote: > "Eric S. Raymond" wrote: > > > > Having finally wrestled CVS into at least temporary submission, > > I'm in the process of generating a patch to add a browser-launcher > > function to the standard library. There are a couple of issues > > connected to this. > > Eric, please have a look at Tools/idle/BrowserControl.py... > it has all you need and can easily be extended to support > more browsers. > > Might be a good candidate for the std lib if you ask me -- > after a rename to say "browser.py". It can easily be transformed into the standard library for free: just declare IDLE a standard library package. Even better would be to divorce all those parts of IDLE which are Tkinter independent and put those in a seperate package, whose name is TBD. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From mal at lemburg.com Thu Jul 6 20:58:45 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 20:58:45 +0200 Subject: [Python-Dev] urllib.browse() issues References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> Message-ID: <3964D6E5.536C0D93@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > Um, there's not a single OS implementation in os.py either ;-) > > Good point; we should fix that. ;) > > > I think it describes things well enough if you write > > > > browser.open('http://www.python.org/') > > > > Perhaps the interface should be a bit more RPC like, though... > > something like: > > > > b = browser.connect() > > b.open(http://www.python.org/') > > b.close() > > How about: > > b = browser.get() > b.open("http://www.python.org/") > > That has the advantage of working with the existing code. ;) Ok, fine with me. +1 for adding it to the standard lib from me. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From esr at thyrsus.com Thu Jul 6 21:44:34 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 15:44:34 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964D6E5.536C0D93@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 08:58:45PM +0200 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> Message-ID: <20000706154434.A26357@thyrsus.com> M.-A. Lemburg : > Ok, fine with me. > > +1 for adding it to the standard lib from me. Who's going to do the cut and fit? Me, or the IDLE maintainer? -- Eric S. Raymond Society in every state is a blessing, but government even in its best state is but a necessary evil; in its worst state an intolerable one; for when we suffer, or are exposed to the same miseries *by a government*, which we might expect in a country *without government*, our calamities is heightened by reflecting that we furnish the means by which we suffer." -- Thomas Paine From fdrake at beopen.com Thu Jul 6 21:41:08 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 15:41:08 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706154434.A26357@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> Message-ID: <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Who's going to do the cut and fit? Me, or the IDLE maintainer? If Guido doesn't object to moving this module, the task falls to me since I wrote it. Were there any requirements you had that the existing BrowserControl doesn't support? If so, please tell us from the requirements side. I'll write the documentation as well, if we move it. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Thu Jul 6 21:41:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 15:41:27 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: [moved from patches to Python-Dev] >> Patch #100745 has been updated. >> Visit SourceForge.net for more info. > http://sourceforge.net/patch/?func=detailpatch&patch_id=100745&group_id=5470 [Moshe] > -1: Since when have we stopped supporting machines without 4-byte integral > types? Or even non-standard 4 byte integral types? This looks extremely > dangerous. Indeed, Python *does* run on machines that don't have any 4-byte integral types -- or at least it used to . It doesn't run on any without an integral type *at least* 32-bits wide, though. Wouldn't the latter be good enough for this patch? That is, what's the requirement here for *exactly* 32 bits? BTW, a sane collection of typedefs would be another good candidate for pyport.h. From barry at scottb.demon.co.uk Thu Jul 6 21:58:22 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Thu, 6 Jul 2000 20:58:22 +0100 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack In-Reply-To: Message-ID: <000001bfe784$89f69080$060210ac@private> > The effectiveness of this is dependent on guessing a good value (per > platform) for MAX_RECURSION_DEPTH (and it's broken under Windows in 1.5.2). For embedding Python into other apps you need to control the value of MAX_RECURSION_DEPTH at run time. I can then adjust the value to: * take account of my app's impact on the stack usage * limit the depth to get a faster failure from buggy .py modules * work around any bug that gets the value wrong Having a pair of functions to Set/Get the value would be very nice. BArry From esr at thyrsus.com Thu Jul 6 22:35:11 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 16:35:11 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.57556.241282.594629@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 03:41:08PM -0400 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> Message-ID: <20000706163511.A26475@thyrsus.com> Fred L. Drake, Jr. : > If Guido doesn't object to moving this module, the task falls to me > since I wrote it. Were there any requirements you had that the > existing BrowserControl doesn't support? If so, please tell us from > the requirements side. Frankly, what's there strikes me as overly complex and tied to the heavyweight IDLE environment. Here's the latest version of my code for comparison. Comment and critique follows. # Support for launching a browser _browsers = None def iscommand(cmd): # I'd still like to put a cross-platform version of this in the library if os.name == 'posix': return os.system('which 1>/dev/null 2>&1 ' + cmd) == 0 else: return 1 def urlbrowse(url): """Launch a browser, in background if possible, pointed at the given URL. Accept either a string or a parsed URL tuple. Interpret the BROWSER environment variable, if it exists, as a colon-separated list of browser commands to try. """ from urlparse import urlunparse if type(url) == (): url = urlunparse(url) global _browsers if os.environ.has_key("BROWSER"): _browsers = string.split(os.environ["BROWSER"], ":") elif os.name == 'posix': _browsers = ["mozilla %s &", "netscape -remote 'openURL(%s)'", "netscape %s &", "lynx %s", "w3m %s"] elif os.name == 'nt': _browsers = ['start %s'] for browser in _browsers: if _iscommand(string.split(browser)[0]): if os.system((browser % url)) == 0: return 1 return 0 One significant difference is that my code gets the user preference for a browser from an environment variable, rather than a profile. This is appropriate for a preference that will be shared across multiple applications, and follows the pattern of well-known Unix envirinment variables like EDITOR. Another difference is that my code tries harder to have smart default behavior. Notice the order of attempts -- X browsers are tried first in background, then character browsers in the foreground. This means you are more likely to get some reasonable behavior independent of whether the calling Python program is launched from within X, from an Xterm, or on an X-less console. The register() calls seem kind of overelaborate. Why not just update a global dictionary directly? Things I like about the IDLE code, on the other hand...the distinction between open() and open_new() methods is good. It's also clearly smarter about the actual mechanics of browser invocation. I think what I'd like to see is a merged version that starts with your class organization, discards the .ini profile cruft in favor of an environment-variable check, uses my logic for hunting up a browser, and uses your incantations for actually invoking the browser. -- Eric S. Raymond Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their consciences. -- C. S. Lewis From mal at lemburg.com Thu Jul 6 22:28:47 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 22:28:47 +0200 Subject: [Python-Dev] Collection of typedefs for integral types References: Message-ID: <3964EBFF.69202D79@lemburg.com> Tim Peters wrote: > > [moved from patches to Python-Dev] > > >> Patch #100745 has been updated. > >> Visit SourceForge.net for more info. > > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100745&group_id=5470 > > [Moshe] > > -1: Since when have we stopped supporting machines without 4-byte integral > > types? Or even non-standard 4 byte integral types? This looks extremely > > dangerous. > > Indeed, Python *does* run on machines that don't have any 4-byte integral > types -- or at least it used to . It doesn't run on any without an > integral type *at least* 32-bits wide, though. Wouldn't the latter be good > enough for this patch? That is, what's the requirement here for *exactly* > 32 bits? > > BTW, a sane collection of typedefs would be another good candidate for > pyport.h. Good idea. The only problem with typedefs is that they tend to cause conflicts when different definitions are encountered. We'd have to use e.g. Py_UINT4, Py_UINT2, etc... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Thu Jul 6 22:32:36 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 16:32:36 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <3964EBFF.69202D79@lemburg.com> References: <3964EBFF.69202D79@lemburg.com> Message-ID: <14692.60644.899402.407317@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > The only problem with typedefs is that they tend to cause conflicts > when different definitions are encountered. > We'd have to use e.g. Py_UINT4, Py_UINT2, etc... Yes, we'd have to have our own names (unfortunate, but only matters for API functions, not locals). How bad that is depends on what you call "sane". And I'm not going to predict Tim on this! ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Thu Jul 6 22:33:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 16:33:22 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: [moved from patches to python-dev] [Bill Tutt] > Code currently in unicodeobject.c needs to do 32-bit arithmetic in > order to work. Additionally, UCS-4 characters (aka UTF-16 surrogate > characters) require 32 bits to represent the true unicode code point of a > surrogate pair. But is the requirement really for *exactly* 32 bits, or for *at least* 32 bits? The problem isn't with feebler machines, it's with higher-end ones: on some Python platforms, even sizeof(short) == 8. As is, your patch will prevent Python from compiling on those. From tim_one at email.msn.com Thu Jul 6 22:42:14 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 16:42:14 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <3964EBFF.69202D79@lemburg.com> Message-ID: >> BTW, a sane collection of typedefs would be another good candidate for >> pyport.h. [M.-A. Lemburg] > Good idea. > > The only problem with typedefs is that they tend to cause conflicts > when different definitions are encountered. > We'd have to use e.g. Py_UINT4, Py_UINT2, etc... Yes, but that's a hell of a lot better than the path the patch in question started going down, w/ its Unicode-specific _PyUnicode_Int32 and (! probably a bug) _PyUNICODE_Int32. From esr at thyrsus.com Thu Jul 6 22:59:31 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 16:59:31 -0400 Subject: [Python-Dev] Dangling locks again Message-ID: <20000706165931.A26662@thyrsus.com> Grrrrr...I can't commit my test patch. Skip has a dangling lock on the Lib directory. -- Eric S. Raymond What, then is law [government]? It is the collective organization of the individual right to lawful defense." -- Frederic Bastiat, "The Law" From fdrake at beopen.com Thu Jul 6 22:51:15 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 16:51:15 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706163511.A26475@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> Message-ID: <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Frankly, what's there strikes me as overly complex and tied to the > heavyweight IDLE environment. Here's the latest version of my code Actually, the code didn't originate in IDLE, but it did originate in a GUI program (never tested on Windows, but it used GTK+, so it might have worked there). > One significant difference is that my code gets the user preference > for a browser from an environment variable, rather than a profile. > This is appropriate for a preference that will be shared across multiple > applications, and follows the pattern of well-known Unix envirinment > variables like EDITOR. Which is great for Unix users, but otherwise stinks. I wasn't real happy with the .ini file thing, but wanted a way to configure it independent of the hosting application. > Another difference is that my code tries harder to have smart default > behavior. Notice the order of attempts -- X browsers are tried first > in background, then character browsers in the foreground. This means > you are more likely to get some reasonable behavior independent of > whether the calling Python program is launched from within X, from an > Xterm, or on an X-less console. I agree that this is good; I'll try and incorporate this. It would require that open/open_new could block (consoles, etc.), but that would be apporopriate in those contexts. > The register() calls seem kind of overelaborate. Why not just > update a global dictionary directly? Perhaps that's the right way to do it, but I'm not completely convinced either. If a GUI library uses this to provide help, and an application like Grail uses that library, Grail should be able to register itself as a help viewer. The exact mechanics are certainly open to debate; I'm not terribly enamored of the machinery there now. > Things I like about the IDLE code, on the other hand...the > distinction between open() and open_new() methods is good. It's also > clearly smarter about the actual mechanics of browser invocation. And I'd like to be able to support several more browsers, especially on Windows. I have no idea how any of this should be done for MacOS machines, either, which should be supportable. > I think what I'd like to see is a merged version that starts with your > class organization, discards the .ini profile cruft in favor of an > environment-variable check, uses my logic for hunting up a browser, > and uses your incantations for actually invoking the browser. I'll see if I can throw something together later today, and send it to python-dev for comments before checking it in. I guess the documentation falls in the category of "Internet Protocols *and Support*"... I don't think it fits anywhere else! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From rassilon at list.org Thu Jul 6 22:53:47 2000 From: rassilon at list.org (Bill Tutt) Date: Thu, 6 Jul 2000 13:53:47 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Tim Peters wrote: > [moved from patches to python-dev] > > [Bill Tutt] > > Code currently in unicodeobject.c needs to do 32-bit arithmetic in > > order to work. Additionally, UCS-4 characters (aka UTF-16 surrogate > > characters) require 32 bits to represent the true unicode code point of a > > surrogate pair. > > But is the requirement really for *exactly* 32 bits, or for *at least* 32 > bits? The problem isn't with feebler machines, it's with higher-end ones: > on some Python platforms, even sizeof(short) == 8. As is, your patch will > prevent Python from compiling on those. Its definately for at least 32 bits. Having a 32 bit specific type lets me not worry about all the issues relating to: What happens if sizeof(int) | sizeof(long) > 32 bits and I failed to compensate for that somehow. Now, the code that I changed to use the typedef might not care about this, but other code using the typedef might. Just color me a paranoid SOB. :) I'd rather always have a 32 bit type for something I know will always require just 32 bits. Bill From tim_one at email.msn.com Thu Jul 6 22:50:50 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 16:50:50 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <14692.60644.899402.407317@cj42289-a.reston1.va.home.com> Message-ID: >> Py_UINT4, Py_UINT2, etc... [Fred Drake] > Yes, we'd have to have our own names (unfortunate, but only matters > for API functions, not locals). How bad that is depends on what you > call "sane". And I'm not going to predict Tim on this! ;) I'm in favor of (as Trent Mick once suggested) getting exactly as insane as C9X: they thought hard about this, and came up with a whole slew of new symbolic names for the roles integral types play. We make typedefs of the same names (well, for as many as we actually *need*) but with Py_ in front of them. In time, as C9X takes over the world, the platform-#ifdef infested section of pyport.h declaring them actually *shrinks*, as more & more platforms support typedef'ing to the std C9X-defined names. From guido at beopen.com Thu Jul 6 23:53:19 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 16:53:19 -0500 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Your message of "Thu, 06 Jul 2000 16:42:14 -0400." References: Message-ID: <200007062153.QAA01183@cj20424-a.reston1.va.home.com> > >> BTW, a sane collection of typedefs would be another good candidate for > >> pyport.h. > > [M.-A. Lemburg] > > Good idea. > > > > The only problem with typedefs is that they tend to cause conflicts > > when different definitions are encountered. > > We'd have to use e.g. Py_UINT4, Py_UINT2, etc... > > Yes, but that's a hell of a lot better than the path the patch in question > started going down, w/ its Unicode-specific _PyUnicode_Int32 and (! probably > a bug) _PyUNICODE_Int32. C already *has* a sane collection of typedefs: short, int, long, maybe combined with unsigned. Plus size_t and so on. There should be only relatively few places where these aren't sufficient: the most common case being when you need the smallest type that's at least 32 bits, which on some systems is spelled as long, on others as int. When you need exactly 32 bits, you're out of luck (e.g. on Crays, it seems, if Tim is right). So it would be better not to write code that depends on exactly 32 (or 16, or 64, or 27) bits. Places where you just *have* to have exactly 32 bits are rare -- perhaps the calculation of 32-bit checksums is commonly done this way, but even there I would expect that it's possible to write the code to be correct for larger int sizes as well. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From rassilon at list.org Thu Jul 6 22:57:10 2000 From: rassilon at list.org (Bill Tutt) Date: Thu, 6 Jul 2000 13:57:10 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Bill Tutt wrote: > > > Its definately for at least 32 bits. > Having a 32 bit specific type lets me not worry about all the issues > relating to: > What happens if sizeof(int) | sizeof(long) > 32 bits and I failed to > compensate for that somehow. > > Now, the code that I changed to use the typedef might not care about this, > but other code using the typedef might. Just color me a paranoid SOB. :) > I'd rather always have a 32 bit type for something I know will always > require just 32 bits. > In any event, having the typedef is still useful since it clarifies the meaning behind the code. Bill From fdrake at beopen.com Thu Jul 6 22:56:21 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 16:56:21 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: References: <14692.60644.899402.407317@cj42289-a.reston1.va.home.com> Message-ID: <14692.62069.784802.306695@cj42289-a.reston1.va.home.com> Tim Peters writes: > I'm in favor of (as Trent Mick once suggested) getting exactly as insane as > C9X: they thought hard about this, and came up with a whole slew of new > symbolic names for the roles integral types play. We make typedefs of the > same names (well, for as many as we actually *need*) but with Py_ in front > of them. In time, as C9X takes over the world, the platform-#ifdef infested > section of pyport.h declaring them actually *shrinks*, as more & more > platforms support typedef'ing to the std C9X-defined names. Hey, if you're happy with C9X, I am too. What I've read about it made me almost think C had a future. But I'd still rather hack in Python. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Thu Jul 6 23:57:09 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 16:57:09 -0500 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Your message of "Thu, 06 Jul 2000 16:50:50 -0400." References: Message-ID: <200007062157.QAA01227@cj20424-a.reston1.va.home.com> > I'm in favor of (as Trent Mick once suggested) getting exactly as insane as > C9X: they thought hard about this, and came up with a whole slew of new > symbolic names for the roles integral types play. We make typedefs of the > same names (well, for as many as we actually *need*) but with Py_ in front > of them. In time, as C9X takes over the world, the platform-#ifdef infested > section of pyport.h declaring them actually *shrinks*, as more & more > platforms support typedef'ing to the std C9X-defined names. Great idea. (Is a summary of these names online somewhere?) It's always good to reuse hard-won knowledge that someone else gathered. (Python is an example of this -- it encodes a lot of hard-won knowledge that I gathered, and more recently also that many other gathered. This rule is also self-referential.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From pingster at ilm.com Thu Jul 6 23:01:49 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 6 Jul 2000 14:01:49 -0700 (PDT) Subject: [Python-Dev] Hash values and comparing objects In-Reply-To: <3964B39C.7E0CD312@lemburg.com> Message-ID: On Thu, 6 Jul 2000, M.-A. Lemburg wrote: > Previously, Unicode used UTF-8 as basis for calculating the > hash value Right, and i was trying to suggest (in a previous message) that the hash value should be calculated from the actual Unicode character values themselves. Then for any case where it's possible for an 8-bit string to be == to a Unicode string, they will have the same hash. Doesn't this solve the problem? Have i misunderstood? > How serious is the need for objects which compare equal to > have the same hash value ? For basic, immutable types like strings -- quite serious indeed, i would imagine. > 2. In some locales '???' == u'???' is true, while in others this is > not the case. If they do compare equal, the hash values > must match. This sounds very bad. I thought we agreed that attempting to compare (or add) a Unicode string and an 8-bit string containing non-ASCII characters (as in your example) should raise an exception. Such an attempt constitutes an ambiguous request -- you haven't specified how to turn the 8-bit bytes into Unicode, and it's better to be explicit than to have the interpreter guess (and guess differently depending on the environment!!) -- ?!ng From tim_one at email.msn.com Thu Jul 6 23:02:38 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 17:02:38 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: [Bill Tutt] > Its definately for at least 32 bits. > Having a 32 bit specific type lets me not worry about all the issues > relating to: > What happens if sizeof(int) | sizeof(long) > 32 bits and I failed to > compensate for that somehow. Provided you're sticking to unsigned types, there should be few issues here: the behavior of C's unsigned ints is well-defined across platforms. > Now, the code that I changed to use the typedef might not care about this, > but other code using the typedef might. Just color me a paranoid SOB. :) > I'd rather always have a 32 bit type for something I know will always > require just 32 bits. Understood, but you can't have that, not in Python source. I'm -1 on the patch so long as it requires something that can't be had . From esr at thyrsus.com Thu Jul 6 23:16:08 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 17:16:08 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.61763.530974.492605@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 04:51:15PM -0400 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> Message-ID: <20000706171608.A26696@thyrsus.com> Fred L. Drake, Jr. : > > One significant difference is that my code gets the user preference > > for a browser from an environment variable, rather than a profile. > > This is appropriate for a preference that will be shared across multiple > > applications, and follows the pattern of well-known Unix envirinment > > variables like EDITOR. > > Which is great for Unix users, but otherwise stinks. I wasn't real > happy with the .ini file thing, but wanted a way to configure it > independent of the hosting application. Environment variables work for Windows users, too -- and I believe there's a functionally similar name/value pair facility available through system resource forks on the Mac. I really think a profile file is excessively heavyweight here. Environment variables or X resources are a better medium for this kind of shared preference. I've actually been seriously thinking, once this is in the Python library, of going to the Perl and Tcl people and giving them code that would make *their* standard libraries do the right thing with the BROWSER variable. It shouldn't only be portable across Python applications, but across scripting languages as well -- something that would be much harder to do with an .ini file. > And I'd like to be able to support several more browsers, especially > on Windows. I have no idea how any of this should be done for MacOS > machines, either, which should be supportable. I certainly agree with that goal. -- Eric S. Raymond Such are a well regulated militia, composed of the freeholders, citizen and husbandman, who take up arms to preserve their property, as individuals, and their rights as freemen. -- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" referred to in the Second Amendment to the Constitution. From fdrake at beopen.com Thu Jul 6 23:08:55 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:08:55 -0400 (EDT) Subject: [Python-Dev] C9X information Message-ID: <14692.62823.198578.969389@cj42289-a.reston1.va.home.com> http://lglwww.epfl.ch/~wolf/c/c9x_changes.html This contains a summary of changes. Of particular note regarding today's discussion is item #38. GCC (at least recent versions) include the required header. The types are actually defined in for GCC; take a look there for the actual type names. In my installation, it includes things like this: /* Exact integral types. */ /* Signed. */ /* There is some amount of overlap with as known by inet code */ #ifndef __int8_t_defined # define __int8_t_defined typedef signed char int8_t; typedef short int int16_t; typedef int int32_t; # if __WORDSIZE == 64 typedef long int int64_t; # else __extension__ typedef long long int int64_t; # endif #endif /* Unsigned. */ typedef unsigned char uint8_t; typedef unsigned short int uint16_t; typedef unsigned int uint32_t; #if __WORDSIZE == 64 typedef unsigned long int uint64_t; #else __extension__ typedef unsigned long long int uint64_t; #endif /* Small types. */ /* Signed. */ typedef signed char int_least8_t; typedef short int int_least16_t; typedef int int_least32_t; #if __WORDSIZE == 64 typedef long int int_least64_t; #else __extension__ typedef long long int int_least64_t; #endif /* Unsigned. */ typedef unsigned char uint_least8_t; typedef unsigned short int uint_least16_t; typedef unsigned int uint_least32_t; #if __WORDSIZE == 64 typedef unsigned long int uint_least64_t; #else __extension__ typedef unsigned long long int uint_least64_t; #endif /* Fast types. */ /* Signed. */ typedef signed char int_fast8_t; #if __WORDSIZE == 64 typedef long int int_fast16_t; typedef long int int_fast32_t; typedef long int int_fast64_t; #else typedef int int_fast16_t; typedef int int_fast32_t; __extension__ typedef long long int int_fast64_t; #endif /* Unsigned. */ typedef unsigned char uint_fast8_t; #if __WORDSIZE == 64 typedef unsigned long int uint_fast16_t; typedef unsigned long int uint_fast32_t; typedef unsigned long int uint_fast64_t; #else typedef unsigned int uint_fast16_t; typedef unsigned int uint_fast32_t; __extension__ typedef unsigned long long int uint_fast64_t; #endif -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From akuchlin at mems-exchange.org Thu Jul 6 23:11:59 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 6 Jul 2000 17:11:59 -0400 Subject: [Python-Dev] Adding poll() system call Message-ID: <20000706171159.A25398@kronos.cnri.reston.va.us> For work-related reasons I'm looking at Medusa, and noticed that someone in that community wrote a wrapper for the poll() system call: http://www.nightmare.com/medusa/pollmodule.c The Medusa Web page says: The latest version of asyncore.py includes support for this module. poll(2) is much like select(2), but uses an array of structures rather than a bitmap. A major design problem with select(2) is that an fd_set is usually of a fixed maximum size, on many operating systems the kernel needs to rebuilt to raise this limit; even on those that have dynamically adjustable limits, you still need to recompile your application (because FD_SETSIZE is a macro). I'd suggest adding poll() to 2.0, and will submit a patch if given the go-ahead. But where should it go? A whole module for it seems excessive; should it go in posixmodule, or maybe select? (I can't figure out the POSIX status of poll(), though the Open Group does have a man page for it: http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html). --amk From guido at beopen.com Fri Jul 7 00:04:25 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 17:04:25 -0500 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Your message of "Thu, 06 Jul 2000 13:57:10 MST." References: Message-ID: <200007062204.RAA01266@cj20424-a.reston1.va.home.com> > In any event, having the typedef is still useful since it clarifies the > meaning behind the code. Actually, the typedef doesn't clarify the "== 32" vs ">= 32" issue at all! Many people appear to be thinking that an uint32 is guaranteed to be exactly 32 bits while this is in fact not guaranteed if you want full portability. Sometimes there *is* no 32-bit data type. The native data types don't have this problem -- but they have other problems because there's no native data type guaranteed to be "the smalles type >= 32 bits". Let's wait for what C9X does here. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From rassilon at list.org Thu Jul 6 23:16:50 2000 From: rassilon at list.org (Bill Tutt) Date: Thu, 6 Jul 2000 14:16:50 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: <200007062204.RAA01266@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 6 Jul 2000, Guido van Rossum wrote: > > In any event, having the typedef is still useful since it clarifies the > > meaning behind the code. > How about this: /* * Use this typedef when you need to represent a UTF-16 surrogate pair * as single unsigned integer. */ #if SIZEOF_INT >= 4 typedef unsigned int Py_UCS4; #else #if SIZEOF_LONG >= 4 typedef unsigned long Py_UCS4; #else #error "can't find integral type that can contain 32 bits" #endif /* SIZEOF_LONG */ #endif /* SIZEOF_INT */ Bill From guido at beopen.com Fri Jul 7 00:16:54 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 17:16:54 -0500 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: Your message of "Thu, 06 Jul 2000 17:16:08 -0400." <20000706171608.A26696@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> Message-ID: <200007062216.RAA01333@cj20424-a.reston1.va.home.com> [ESR] > Environment variables work for Windows users, too -- and I believe > there's a functionally similar name/value pair facility available > through system resource forks on the Mac. I really think a profile > file is excessively heavyweight here. Environment variables or X > resources are a better medium for this kind of shared preference. > > I've actually been seriously thinking, once this is in the Python > library, of going to the Perl and Tcl people and giving them code that > would make *their* standard libraries do the right thing with the > BROWSER variable. It shouldn't only be portable across Python > applications, but across scripting languages as well -- something that > would be much harder to do with an .ini file. But on Windows, there is already a registry setting to choose the browser. No native Windows user (as opposed to transplanted Unix users like you & me :-) is going to understand why they have to set an environment variable (something they believe is old-fashioned and mostly needed for the obscure and -- in their eyes -- equally obscure "DOS box") to change a preference that the system already knows perfectly well. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From pingster at ilm.com Thu Jul 6 23:16:07 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 6 Jul 2000 14:16:07 -0700 (PDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <20000706171159.A25398@kronos.cnri.reston.va.us> Message-ID: On Thu, 6 Jul 2000, Andrew Kuchling wrote: > > I'd suggest adding poll() to 2.0, and will submit a patch if given the > go-ahead. But where should it go? A whole module for it seems > excessive; should it go in posixmodule, or maybe select? posix would make sense to me. Actually, is there any good reason why select isn't in posix also? -- ?!ng "There's no point in being grown up if you can't be childish sometimes." -- Dr. Who From fdrake at beopen.com Thu Jul 6 23:23:08 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:23:08 -0400 (EDT) Subject: [Python-Dev] Re: forwarded message from Eric S. Raymond In-Reply-To: <14692.62818.835847.439551@beluga.mojam.com> References: <14692.61900.716303.447956@cj42289-a.reston1.va.home.com> <14692.62818.835847.439551@beluga.mojam.com> Message-ID: <14692.63676.527282.630370@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > Eric, my apologies. It would be real nice if SF could/would list locks that > are older than a few seconds (minutes?) when browsing the CVS repository. I think this is a good idea! I just filed the following bug report/ feature request: http://sourceforge.net/bugs/?func=detailbug&bug_id=108997&group_id=1 Feel free to add a comments explaining why this would be such a good idea! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Fri Jul 7 00:25:46 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 17:25:46 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Thu, 06 Jul 2000 14:16:07 MST." References: Message-ID: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> > > I'd suggest adding poll() to 2.0, and will submit a patch if given the > > go-ahead. But where should it go? A whole module for it seems > > excessive; should it go in posixmodule, or maybe select? > > posix would make sense to me. Yes, definitely. (The posix module contains lots of non-Posix stuff -- it was a way of saying Unix without pronouncing it.) > Actually, is there any good reason why select isn't in posix also? Yes -- select also works on Windows and DOS. (Ditto for socket.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From akuchlin at mems-exchange.org Thu Jul 6 23:28:31 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 6 Jul 2000 17:28:31 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007062225.RAA01376@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 05:25:46PM -0500 References: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> Message-ID: <20000706172831.B25398@kronos.cnri.reston.va.us> On Thu, Jul 06, 2000 at 05:25:46PM -0500, Guido van Rossum wrote: >> Actually, is there any good reason why select isn't in posix also? >Yes -- select also works on Windows and DOS. (Ditto for socket.) I don't know if poll() is available on Windows; anyone got a clue? poll() for DOS is almost certainly out of the question, and who cares these days? --amk From gstein at lyra.org Thu Jul 6 23:31:13 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 14:31:13 -0700 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706122122.A25613@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 06, 2000 at 12:21:22PM -0400 References: <20000706122122.A25613@thyrsus.com> Message-ID: <20000706143113.I29590@lyra.org> On Thu, Jul 06, 2000 at 12:21:22PM -0400, Eric S. Raymond wrote: > Having finally wrestled CVS into at least temporary submission, Eric, For the record, can you state what was wrong and how you fixed it? If/when others run into the same problem, then it will be great to know. thx! -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Thu Jul 6 23:29:38 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:29:38 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062216.RAA01333@cj20424-a.reston1.va.home.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> Message-ID: <14692.64066.241359.276620@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > But on Windows, there is already a registry setting to choose the > browser. No native Windows user (as opposed to transplanted Unix > users like you & me :-) is going to understand why they have to set an > environment variable (something they believe is old-fashioned and Exactly. On Windows, the existing code does the right thing and uses the registry settings. Or rather, it uses the Windows calls that make use of the registry settings, just like if you double-click on an HTML file directly. Which doesn't mean that BROWSER is the wrong thing on Unix; I'll take that into consideration (which does *not* mean I'll agree! Haven't decided yet, but it has clear merit). If someone "native" in the MacOS world can describe the right thing there, or provide a patch, that would be wonderful! I know about Internet Config, I just don't know what to do with it. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jul 6 23:31:18 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:31:18 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> References: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> Message-ID: <14692.64166.938741.169194@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > Yes -- select also works on Windows and DOS. (Ditto for socket.) That doesn't answer the question. Why select.select() instead of os.select()? I've never understood that one myself. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Thu Jul 6 23:37:56 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 17:37:56 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <200007062153.QAA01183@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > C already *has* a sane collection of typedefs: short, int, long, maybe > combined with unsigned. Those aren't typedefs, they're types, and the direct use of them was the cause of almost all of Trent Mick's Win64 porting pains. The std makes very weak promises about the std integral types, and Python (like all other C code that uses them directly!) accumulated lots of unwarranted assumptions. Rather than fix this with sane typedefs, we're now getting increasing amounts of ugly and brittle #ifdef'ed code keying off preprocessor symbols (like SIZEOF_LONG etc). > Plus size_t and so on. Those are typedefs. C9X adds more of that ilk, like "integral type big enough to hold a casted pointer", which current C doesn't address at all beyond guaranteeing there's *some* (unnamed) suitable type (and the lack of a typedef for which in Python accounted for maybe half of Trent's patches). > There should be only relatively few places where these aren't > sufficient: the most common case being when you need the smallest type > that's at least 32 bits, which on some systems is spelled as long, on > others as int. Agreed, and that's specifically what this patch needs (provided Bill gets over his paranoia ). > When you need exactly 32 bits, you're out of luck (e.g. on Crays, it > seems, if Tim is right). That sizeof(short) == 8 is in part why Python's long ints are currently broken on the J90 (the other reason is that the J90 has the only compiler I know of that does not generate code to sign-extend right shifts of signed integral types). > So it would be better not to write code that depends on exactly 32 (or > 16, or 64, or 27) bits. Places where you just *have* to have exactly > 32 bits are rare -- perhaps the calculation of 32-bit checksums is > commonly done this way, but even there I would expect that it's > possible to write the code to be correct for larger int sizes as well. Absolutely: the new crc32 checksum in Python was written this way (to require ints at least 32 bits, but tolerate ints larger than that). It is not, however, good that the code *spells* that requirement "unsigned long"! As obscure as can be. My position remains the same: adopt the C9X names for as many of the new integral synonyms as we *need*, but stick "Py_" in front of them. the-committee-wasn't-just-jerking-off-the-last-10-years-ly y'rs - tim From fdrake at beopen.com Thu Jul 6 23:41:43 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:41:43 -0400 (EDT) Subject: [Python-Dev] forwarded message from noreply@sourceforge.net Message-ID: <14692.64791.704062.354485@cj42289-a.reston1.va.home.com> Skip, Looks like the bug manager works much like we wish the patch manager did! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- An embedded message was scrubbed... From: noreply at sourceforge.net Subject: [Bug #108997] CVS browsing should show old locks Date: Thu, 6 Jul 2000 14:34:48 -0700 Size: 1734 URL: From mal at lemburg.com Thu Jul 6 23:42:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 23:42:08 +0200 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode References: Message-ID: <3964FD30.BB0F14D1@lemburg.com> Bill Tutt wrote: > > On Thu, 6 Jul 2000, Guido van Rossum wrote: > > > > In any event, having the typedef is still useful since it clarifies the > > > meaning behind the code. > > > > How about this: > /* > * Use this typedef when you need to represent a UTF-16 surrogate pair > * as single unsigned integer. > */ > #if SIZEOF_INT >= 4 > typedef unsigned int Py_UCS4; > #else > #if SIZEOF_LONG >= 4 > typedef unsigned long Py_UCS4; > #else > #error "can't find integral type that can contain 32 bits" > #endif /* SIZEOF_LONG */ > #endif /* SIZEOF_INT */ I like the name... Py_UCS4 is indeed what we're talking about here. What I don't understand is why you raise a compile error; AFAIK, unsigned long is at least 32 bits on all platforms and that's what the Unicode implementation would need to support UCS4 -- more bits don't do any harm since the storage type is fixed at 16-bit UTF-16 values. Ideal would be combining the above with the C9X typedefs, e.g. typedef uint4_t Py_UCS4; -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Thu Jul 6 23:47:32 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 16:47:32 -0500 (CDT) Subject: [Python-Dev] Problems with 2.0b1 and GCC Message-ID: <14692.65140.525706.197488@beluga.mojam.com> I thought I had this fixed, but apparently not. On my Linux (Mandrake 6.1 with some stuff from 7.1), I'm getting the following traceback in certain situations when running an oldish version of Zope (2.0.0): (gdb) bt #0 0x400712e8 in sigsuspend () from /lib/libc.so.6 #1 0x401471a0 in __DTOR_END__ () from /lib/libc.so.6 Yesterday I removed pgcc and egcs (both were installed for some reason) and upgraded the compilation environment to the following: gcc-c++-2.95.2-7mdk gcc-cpp-2.95.2-7mdk binutils-2.9.5.0.31-1mdk glibc-devel-2.1.1-15mdk glibc-2.1.1-15mdk compat-glibc-5.3-2.0.7.5mdk gcc-2.95.2-7mdk (Am I missing an important package that needs updating in the list above?) I had noticed the same traceback in test_fork1.py after I removed pgcc and installed gcc 2.95 and friends, but before I realized I had egcs installed. Deleting egcs cured the problem in at least some situations, but apparently not all. Anybody seen this? I suspect it has something to do with threading (which Zope requires). My Python directory tree is up-to-date wrt the CVS repository and was configured as ./configure --with-threads --with-cycle-gc --prefix=/usr and compiled as make OPT=-g I will try turning off cycle-gc. Any other thoughts from the assembled compilation gurus? Thx, Skip From guido at beopen.com Fri Jul 7 00:54:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 17:54:36 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Thu, 06 Jul 2000 17:31:18 -0400." <14692.64166.938741.169194@cj42289-a.reston1.va.home.com> References: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> <14692.64166.938741.169194@cj42289-a.reston1.va.home.com> Message-ID: <200007062254.RAA01617@cj20424-a.reston1.va.home.com> > That doesn't answer the question. Why select.select() instead of > os.select()? I've never understood that one myself. Different platform dependencies. The select module works on Windows, Mac and Unix. The posix module only runs on Unix and (under the name "nt", but using the same source file) on Win32. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gmcm at hypernet.com Thu Jul 6 23:55:20 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 6 Jul 2000 17:55:20 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> References: <20000706163511.A26475@thyrsus.com> Message-ID: <1249201972-6842244@hypernet.com> Fred L. Drake, Jr. wrote: > And I'd like to be able to support several more browsers, > especially > on Windows. That's what "start %s" % url does. The intent is the same as $EDITOR, though the mechanics make Rube Goldberg look boringly practical. - Gordon From mal at lemburg.com Thu Jul 6 23:53:59 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 23:53:59 +0200 Subject: [Python-Dev] Hash values and comparing objects References: Message-ID: <3964FFF7.A2D8AFFF@lemburg.com> Ka-Ping Yee wrote: > > On Thu, 6 Jul 2000, M.-A. Lemburg wrote: > > Previously, Unicode used UTF-8 as basis for calculating the > > hash value > > Right, and i was trying to suggest (in a previous message) > that the hash value should be calculated from the actual > Unicode character values themselves. Then for any case where > it's possible for an 8-bit string to be == to a Unicode > string, they will have the same hash. Doesn't this solve the > problem? Have i misunderstood? Not really, since the default encoding doesn't necessarily need to have anything to do with a Unicode subset, e.g. take one of the many Windows code pages. > > How serious is the need for objects which compare equal to > > have the same hash value ? > > For basic, immutable types like strings -- quite serious indeed, > i would imagine. What I meant was: would it do much harm if hash(unicode)==hash(string) would only be guaranteed for ASCII only values -- even though unicode may compare equal to string. > > 2. In some locales '???' == u'???' is true, while in others this is > > not the case. If they do compare equal, the hash values > > must match. > > This sounds very bad. I thought we agreed that attempting to > compare (or add) a Unicode string and an 8-bit string containing > non-ASCII characters (as in your example) should raise an exception. Only if the default encoding is ASCII. If Python runs in a different locale environment that encoding can change, e.g. to Latin-1 or one of the available code pages (this is to enhance Python's compatibility with the underlying environment). > Such an attempt constitutes an ambiguous request -- you haven't > specified how to turn the 8-bit bytes into Unicode, and it's better > to be explicit than to have the interpreter guess (and guess > differently depending on the environment!!) The interpreter doesn't guess, it uses the locale setting as defined by the user. If the programmer wants to be sure about what encoding is actually used, he will have to be explicit about it. That's what I would recommend for most applications, BTW. The auto-conversion magic is mainly meant for simplifying intergration of Unicode into existing systems. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From esr at thyrsus.com Fri Jul 7 00:04:51 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 18:04:51 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062216.RAA01333@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 05:16:54PM -0500 References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> Message-ID: <20000706180451.D26696@thyrsus.com> Guido van Rossum : > But on Windows, there is already a registry setting to choose the > browser. No native Windows user (as opposed to transplanted Unix > users like you & me :-) is going to understand why they have to set an > environment variable (something they believe is old-fashioned and > mostly needed for the obscure and -- in their eyes -- equally obscure > "DOS box") to change a preference that the system already knows > perfectly well. In my design the environment variable is only there as an optional override. Most of the time, the smart defaults do the right thing. -- Eric S. Raymond The most foolish mistake we could possibly make would be to permit the conquered Eastern peoples to have arms. History teaches that all conquerors who have allowed their subject races to carry arms have prepared their own downfall by doing so. -- Hitler, April 11 1942, revealing the real agenda of "gun control" From skip at mojam.com Thu Jul 6 23:56:40 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 16:56:40 -0500 (CDT) Subject: [Python-Dev] Problems with 2.0b1 and GCC In-Reply-To: <14692.65140.525706.197488@beluga.mojam.com> References: <14692.65140.525706.197488@beluga.mojam.com> Message-ID: <14693.152.401254.99695@beluga.mojam.com> Skip> I will try turning off cycle-gc. Did not help. (Neil, you can go home if you like... ;-) *sigh* Skip From tim_one at email.msn.com Thu Jul 6 23:55:10 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 17:55:10 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: [Bill Tutt] > How about this: > /* > * Use this typedef when you need to represent a UTF-16 surrogate pair > * as single unsigned integer. > */ > #if SIZEOF_INT >= 4 > typedef unsigned int Py_UCS4; > #else > #if SIZEOF_LONG >= 4 > typedef unsigned long Py_UCS4; > #else > #error "can't find integral type that can contain 32 bits" > #endif /* SIZEOF_LONG */ > #endif /* SIZEOF_INT */ Much better! In the future (when the infrastructure is in place), I expect we'll replace the #if stuff here with typedef Py_uint_least32_t UCS4; instead (where Py_uint_least32_t is defined in pyfort.h, and uint_least32_t is the C9X spelling of the true requirement). BTW, why not use #elif instead of nested #ifs? #elif is clearer and shorter. From gstein at lyra.org Fri Jul 7 00:00:42 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:00:42 -0700 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: <3964FD30.BB0F14D1@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 11:42:08PM +0200 References: <3964FD30.BB0F14D1@lemburg.com> Message-ID: <20000706150042.K29590@lyra.org> On Thu, Jul 06, 2000 at 11:42:08PM +0200, M.-A. Lemburg wrote: > Bill Tutt wrote: > > > > On Thu, 6 Jul 2000, Guido van Rossum wrote: > > > > > > In any event, having the typedef is still useful since it clarifies the > > > > meaning behind the code. > > > > > > > How about this: > > /* > > * Use this typedef when you need to represent a UTF-16 surrogate pair > > * as single unsigned integer. > > */ > > #if SIZEOF_INT >= 4 > > typedef unsigned int Py_UCS4; > > #else > > #if SIZEOF_LONG >= 4 > > typedef unsigned long Py_UCS4; > > #else > > #error "can't find integral type that can contain 32 bits" > > #endif /* SIZEOF_LONG */ > > #endif /* SIZEOF_INT */ > > I like the name... Py_UCS4 is indeed what we're talking about > here. > > What I don't understand is why you raise a compile error; AFAIK, > unsigned long is at least 32 bits on all platforms and that's > what the Unicode implementation would need to support UCS4 -- more > bits don't do any harm since the storage type is fixed at > 16-bit UTF-16 values. Agreed. Some logic is still desirable (picking "int" over "long" is goodness), but the error is not needed. Python simply does not work if a long is not at least 32 bits. Period. No reason for an error. > Ideal would be combining the above with the C9X typedefs, > e.g. typedef uint4_t Py_UCS4; Actually, uint_fast32_t Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Fri Jul 7 00:02:10 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:02:10 -0700 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: ; from tim_one@email.msn.com on Thu, Jul 06, 2000 at 05:37:56PM -0400 References: <200007062153.QAA01183@cj20424-a.reston1.va.home.com> Message-ID: <20000706150210.L29590@lyra.org> On Thu, Jul 06, 2000 at 05:37:56PM -0400, Tim Peters wrote: >... > My position remains the same: adopt the C9X names for as many of the new > integral synonyms as we *need*, but stick "Py_" in front of them. Why should we insert the Py_ prefix? We can just use autoconf to test for the types. If present, then we use them. If not, then we define our own replacements. I see no particular reason to complicate it with Py_. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Fri Jul 7 01:00:33 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 18:00:33 -0500 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: Your message of "Thu, 06 Jul 2000 18:04:51 -0400." <20000706180451.D26696@thyrsus.com> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> <20000706180451.D26696@thyrsus.com> Message-ID: <200007062300.SAA01689@cj20424-a.reston1.va.home.com> > In my design the environment variable is only there as an optional override. > Most of the time, the smart defaults do the right thing. Ah. I came in on the tail end of the discussion. This makes sense. BTW, Eric, do you happen to know the folks at SF who wrote the Patch Manager? I and some of the others here at PythonLabs would love to get together with them at the O'Reilly conference (if they are going there) or at some other time to discuss how to kmake the PM better. We've got a lot of experience now! (And obviously we also have some suggestions for the CVS feature regarding cleaning up of locks.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Fri Jul 7 00:01:28 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 18:01:28 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <1249201972-6842244@hypernet.com> References: <20000706163511.A26475@thyrsus.com> <1249201972-6842244@hypernet.com> Message-ID: <14693.440.602599.536953@cj42289-a.reston1.va.home.com> Gordon McMillan writes: > That's what "start %s" % url does. The intent is the same as > $EDITOR, though the mechanics make Rube Goldberg look > boringly practical. No, that supports "Whatever the user set as their default browser," and is the right default for Windows. It doesn't let me use a drop-down box in a GUI to say "This application should Opera for help, even though Navigator is the default." *That's* what I'd like to be able to do, because then there's a chance of being able to separate open() and open_new(). (And just 'cause I'm a little anal about allowing this kind of configurability that no more than one in a thousand will care about. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Fri Jul 7 01:03:42 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 18:03:42 -0500 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Your message of "Thu, 06 Jul 2000 15:02:10 MST." <20000706150210.L29590@lyra.org> References: <200007062153.QAA01183@cj20424-a.reston1.va.home.com> <20000706150210.L29590@lyra.org> Message-ID: <200007062303.SAA01719@cj20424-a.reston1.va.home.com> > Why should we insert the Py_ prefix? We can just use autoconf to test for > the types. If present, then we use them. If not, then we define our own > replacements. > > I see no particular reason to complicate it with Py_. Defensive coding. If the names are somehow present on the system but somehow not detected by configure, Python.h would run into trouble when it tries to define them when they are in fact already defined by some 3rd party extensiom module that includes the necessary magic to reveal the system definitinons for these names... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Fri Jul 7 00:04:07 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 7 Jul 2000 00:04:07 +0200 Subject: [Python-Dev] Grammar help. Message-ID: <20000707000407.E26534@xs4all.nl> Argh, my head hurts ! :P I need some help with the Python Grammar. Or rather, the Parser. I'm trying to add some new syntax to the current CVS snapshot, something Guido said he would like to see: built-in 'range'-like list creation, so that '[1:10]' is the same as 'range(1,10)'. The code isn't the problem, that's all done and it all works, but the problem is that it somehow broke normal list literals ! :-P Here's what I did. The current definition of 'atom' is: atom: '(' [testlist] ')' | '[' [testlist] ']' | << ... >> testlist: test (',' test)* [','] I tried adding it like this: atom: '(' [testlist] ')' | '[' [listmaker] ']' | << ... >> testlist: test (',' test)* [','] listmaker: testlist | rangemaker rangemaker: [test] ':' test And as I said, it works -- for the new syntax. But not for the old one. When I start the interpreter, here's what I see: XXX ambiguity! [snip] XXX ambiguity! 'import site' failed; traceback: File "./Lib/site.py", line 93 prefixes = [sys.prefix] ^ >>> [2:20] [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] >>> [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] File "", line 1 [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] ^ SyntaxError: invalid syntax So, for some reason it doesn't recognize the old list literals als valid syntax. And it probably has to do with ambiguity ;) But I can't, for the life of me, figure out what's so ambiguous about it. As far as I can tell, a bare 'test' can't be a ':', and 'rangemaker' always needs a ':'. Is this some kind of limitation in the Parser that I need to work around ? I tried reading the parser code, and I'm glad my head is reattached ;P Hints-greatly-appreciated-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Fri Jul 7 00:06:05 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 17:06:05 -0500 (CDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062300.SAA01689@cj20424-a.reston1.va.home.com> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> <20000706180451.D26696@thyrsus.com> <200007062300.SAA01689@cj20424-a.reston1.va.home.com> Message-ID: <14693.717.789360.222392@beluga.mojam.com> Guido> BTW, Eric, do you happen to know the folks at SF who wrote the Guido> Patch Manager? .... We've got a lot of experience now! Python was #19 on the top projects list a few days ago and is #14 now. Not bad at all for software rated as mature... (is that sort of like PG-13?) Skip From esr at thyrsus.com Fri Jul 7 00:15:57 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 18:15:57 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062300.SAA01689@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 06:00:33PM -0500 References: <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> <20000706180451.D26696@thyrsus.com> <200007062300.SAA01689@cj20424-a.reston1.va.home.com> Message-ID: <20000706181557.A26994@thyrsus.com> Guido van Rossum : > BTW, Eric, do you happen to know the folks at SF who wrote the Patch > Manager? I and some of the others here at PythonLabs would love to > get together with them at the O'Reilly conference (if they are going > there) or at some other time to discuss how to kmake the PM better. > We've got a lot of experience now! (And obviously we also have some > suggestions for the CVS feature regarding cleaning up of locks.) I don't know who they are, but I can find out. -- Eric S. Raymond Idealism is the noble toga that political gentlemen drape over their will to power. -- Aldous Huxley From gmcm at hypernet.com Fri Jul 7 00:11:46 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 6 Jul 2000 18:11:46 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.440.602599.536953@cj42289-a.reston1.va.home.com> References: <1249201972-6842244@hypernet.com> Message-ID: <1249200987-6901559@hypernet.com> Fred L. Drake, Jr. wrote: > > Gordon McMillan writes: > > That's what "start %s" % url does. The intent is the same as > > $EDITOR, though the mechanics make Rube Goldberg look > boringly > practical. > > No, that supports "Whatever the user set as their default > browser," > and is the right default for Windows. It doesn't let me use a > drop-down box in a GUI to say "This application should Opera for > help, even though Navigator is the default." *That's* what I'd > like to be able to do, because then there's a chance of being > able to separate open() and open_new(). (And just 'cause I'm a > little anal about allowing this kind of configurability that no > more than one in a thousand will care about. ;) No, Fred, you're not one in a thousand, you're *completely* unique. What 999/1000 Windows users will want is to have the help in a .chm. - Gordon From Vladimir.Marangozov at inrialpes.fr Fri Jul 7 00:18:02 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 7 Jul 2000 00:18:02 +0200 (CEST) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jul 06, 2000 12:51:51 PM Message-ID: <200007062218.AAA02492@python.inrialpes.fr> Fred L. Drake, Jr. wrote: > > [MAL] > > Might be a good candidate for the std lib if you ask me -- > > after a rename to say "browser.py". > > Agh! That was my original name for it! Guido wanted me to change > it since that didn't describe it well (there's not a single browser > implementation in there ;). It this is gonna be a standalone library module, and from what I've seen in this thread, I think that "browser.py" is too generic as a term. The module addresses web browsers (not text browsers, info browsers, file browsers...), so it would be nice to clarify this distinction unless the module is intended to supports any kind of browsers. Here are more options: webbrowser.py, wwwbrowser.py, webclient.py ... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From fdrake at beopen.com Fri Jul 7 00:15:53 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 18:15:53 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.717.789360.222392@beluga.mojam.com> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> <20000706180451.D26696@thyrsus.com> <200007062300.SAA01689@cj20424-a.reston1.va.home.com> <14693.717.789360.222392@beluga.mojam.com> Message-ID: <14693.1305.576040.512179@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > Python was #19 on the top projects list a few days ago and is #14 now. Not > bad at all for software rated as mature... (is that sort of like PG-13?) "Top projects" seems to be measured in downloads of released files; we're in the "Most active" list, and I'm not sure what those numbers represent... percentiles? (I.e., we've made more checkins than 99.36% of the projects at SF, using the number right now.) The "Most active ..." header should be a link to a explanation! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jul 7 00:21:37 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 18:21:37 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062218.AAA02492@python.inrialpes.fr> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <200007062218.AAA02492@python.inrialpes.fr> Message-ID: <14693.1649.220462.187258@cj42289-a.reston1.va.home.com> Vladimir Marangozov writes: > Here are more options: webbrowser.py, wwwbrowser.py, webclient.py ... Excellent! I'll take "webbrowser.py". -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gward at mems-exchange.org Fri Jul 7 00:22:56 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 18:22:56 -0400 Subject: [Python-Dev] Grammar help. In-Reply-To: <20000707000407.E26534@xs4all.nl>; from thomas@xs4all.net on Fri, Jul 07, 2000 at 12:04:07AM +0200 References: <20000707000407.E26534@xs4all.nl> Message-ID: <20000706182256.A15938@ludwig.cnri.reston.va.us> On 07 July 2000, Thomas Wouters said: > Argh, my head hurts ! :P Yeah, but try writing your *own* parser-generator. >grin< > Here's what I did. The current definition of 'atom' is: > > atom: '(' [testlist] ')' | '[' [testlist] ']' | << ... >> > testlist: test (',' test)* [','] > > I tried adding it like this: > > atom: '(' [testlist] ')' | '[' [listmaker] ']' | << ... >> > testlist: test (',' test)* [','] > listmaker: testlist | rangemaker > rangemaker: [test] ':' test I think the problem is this: * one possible candidate for atom is: '[' listmaker * two candidates for listmaker: testlist or rangemaker * but both of these start with a test; the fact that one of them is optional is probably beside the point * the parser needs to see ',' or ':' to know if it's got a testlist or a rangemaker: but because a test could be any number of tokens, it would need infinite lookahead. (I think.) Since this is a recursive-descent parser, it is most likely LL(1) -- at most one token of lookahead. Not good enough. Another, entirely hypothetical way of looking at it (based on experience with a completely different recursive descent parser generator (PCCTS/ANTLR) and dim recollections of the Dragon Book): * parser sees a '[' token and enters the 'atom' state (ie. calls a subroutine 'atom()') * swallows the '[' and immediately enters 'listmaker' (no other option) * now it wants to enter either 'testlist' or 'rangemaker': but the FIRST(testlist) == FIRST(test) (testlist can only start with a test), and FIRST(rangemaker) == FIRST(test) + ':' (rangemaker can start with a test or the ':' token) * I suspect this is the ambiguity: overlap in the FIRST sets of testlist and rangemaker The fix? Hmmm, I dunno. Never hacked on the Python grammar myself, and it's been a while since I hacked seriously on any grammar. Maybe the people (person?) who really understands this stuff will have an idea... Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From fdrake at beopen.com Fri Jul 7 00:24:57 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 18:24:57 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <1249200987-6901559@hypernet.com> References: <1249201972-6842244@hypernet.com> <1249200987-6901559@hypernet.com> Message-ID: <14693.1849.276233.217728@cj42289-a.reston1.va.home.com> Gordon McMillan writes: > No, Fred, you're not one in a thousand, you're *completely* > unique. What 999/1000 Windows users will want is to have > the help in a .chm. Dabnarbit, those Windows users are gettin' smart again... I'll havta put a few in their place! Harrumph! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr at thyrsus.com Fri Jul 7 00:33:32 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 18:33:32 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.1649.220462.187258@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 06:21:37PM -0400 References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <200007062218.AAA02492@python.inrialpes.fr> <14693.1649.220462.187258@cj42289-a.reston1.va.home.com> Message-ID: <20000706183332.B27129@thyrsus.com> Fred L. Drake, Jr. : > > Vladimir Marangozov writes: > > Here are more options: webbrowser.py, wwwbrowser.py, webclient.py ... > > Excellent! I'll take "webbrowser.py". That works for me, too. -- Eric S. Raymond Live free or die; death is not the worst of evils. -- General George Stark. From gward at mems-exchange.org Fri Jul 7 00:38:10 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 18:38:10 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706163511.A26475@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 06, 2000 at 04:35:11PM -0400 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> Message-ID: <20000706183810.B15938@ludwig.cnri.reston.va.us> On 06 July 2000, Eric S. Raymond said: > def iscommand(cmd): > # I'd still like to put a cross-platform version of this in the library > if os.name == 'posix': > return os.system('which 1>/dev/null 2>&1 ' + cmd) == 0 > else: > return 1 Speaking of heavyweight, this strikes me as excessive: N * 2 fork/execs, each of which will scan PATH anew, just to determine if a command exists? (OK, only N if 'which' is a shell built-in.) Why not scan PATH once yourself if you really need to determine a priori which command will fail? Easy to do since this will only be done on Unix. Alternately: > def urlbrowse(url): [...] > for browser in _browsers: > if _iscommand(string.split(browser)[0]): > if os.system((browser % url)) == 0: > return 1 > return 0 Rearrange this loop so it tries os.system() on each one in turn, and completes (successfully) when it finds one that works. (think think think) Ooh, that may not work so well because of the need to background X browsers. Ick. One could dream up a wild scheme that forks and forks and does the backgrounding itself, but what the hell: we're launching a big fat hairy *web browser* here, what does it matter if a shell is involved to parse the "&"? Maybe iscommand() is useful after all; I still think it should do its own PATH-scanning, though. Also, the wild variability of "which" across platforms and shells makes me wonder if, somewhere out there, there isn't a "which" that fails to return true/false on success. (check check check). Yes, there is: with bash 2.0.3 on Solaris 2.6: $ if which ls 1>/dev/null 2>&1 ; then echo yes ; fi yes $ if which skdfhjkjahdfs 1>/dev/null 2>&1 ; then echo yes ; fi yes ... so much for trusting "which" (I never did, anyways). Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From bwarsaw at beopen.com Fri Jul 7 00:44:50 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 18:44:50 -0400 (EDT) Subject: [Python-Dev] Dangling locks again References: <20000706165931.A26662@thyrsus.com> Message-ID: <14693.3042.926389.117529@anthem.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> Grrrrr...I can't commit my test patch. Skip has a dangling ESR> lock on the Lib directory. I already put in an SF request to get this cleaned. From gward at mems-exchange.org Fri Jul 7 00:47:18 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 18:47:18 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000706121231.A14042@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Jul 06, 2000 at 12:12:31PM -0400 References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> <14692.680.483792.544003@cj42289-a.reston1.va.home.com> <20000706121231.A14042@kronos.cnri.reston.va.us> Message-ID: <20000706184718.C15938@ludwig.cnri.reston.va.us> On 06 July 2000, Andrew Kuchling said: > I've been privately wondering about making a new tarball of 1.5.2 that > simply adds the Lib/distutils/ subdirectory and installs it, so people > who don't want to risk the jump to 2.0 can still get the nice > Distutils features. The problem is that it would take substantial > willpower to only make that change; the temptation would be great to > fix just this one really annoying bug, oh, and this little feature > wouldn't break anything, and ... Gee, is it really that hard to install the Distutils into a 1.5.2 installation? I do it a couple times a week and it it usually works for me. ;-) Greg From gstein at lyra.org Fri Jul 7 00:49:57 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:49:57 -0700 Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: <200007061855.LAA05178@slayer.i.sourceforge.net>; from montanaro@users.sourceforge.net on Thu, Jul 06, 2000 at 11:55:14AM -0700 References: <200007061855.LAA05178@slayer.i.sourceforge.net> Message-ID: <20000706154956.U29590@lyra.org> On Thu, Jul 06, 2000 at 11:55:14AM -0700, Skip Montanaro wrote: >... > + /* Exported function to load a readline history file */ > + > + static PyObject * > + read_history_file(self, args) > + PyObject *self; > + PyObject *args; > + { > + char *s = NULL; > + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) This allows somebody to pass read_history_file(None). That doesn't feel right. I'd suggest using the 's' format code. (if they want the default, then pass nothing at all) >... > + static PyObject * > + write_history_file(self, args) > + PyObject *self; > + PyObject *args; > + { > + char *s = NULL; > + if (!PyArg_ParseTuple(args, "|z:write_history_file", &s)) > + return NULL; Same here. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Fri Jul 7 01:53:51 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 18:53:51 -0500 Subject: [Python-Dev] Grammar help. In-Reply-To: Your message of "Thu, 06 Jul 2000 18:22:56 -0400." <20000706182256.A15938@ludwig.cnri.reston.va.us> References: <20000707000407.E26534@xs4all.nl> <20000706182256.A15938@ludwig.cnri.reston.va.us> Message-ID: <200007062353.SAA01958@cj20424-a.reston1.va.home.com> > On 07 July 2000, Thomas Wouters said: > > Argh, my head hurts ! :P Greg Ward replies: > Yeah, but try writing your *own* parser-generator. >grin< > > > Here's what I did. The current definition of 'atom' is: > > > > atom: '(' [testlist] ')' | '[' [testlist] ']' | << ... >> > > testlist: test (',' test)* [','] > > > > I tried adding it like this: > > > > atom: '(' [testlist] ')' | '[' [listmaker] ']' | << ... >> > > testlist: test (',' test)* [','] > > listmaker: testlist | rangemaker > > rangemaker: [test] ':' test > > I think the problem is this: > * one possible candidate for atom is: '[' listmaker > * two candidates for listmaker: testlist or rangemaker > * but both of these start with a test; the fact that one of them > is optional is probably beside the point > * the parser needs to see ',' or ':' to know if it's got a > testlist or a rangemaker: but because a test could be any number > of tokens, it would need infinite lookahead. (I think.) Since > this is a recursive-descent parser, it is most likely LL(1) -- > at most one token of lookahead. Not good enough. > > Another, entirely hypothetical way of looking at it (based on experience > with a completely different recursive descent parser generator > (PCCTS/ANTLR) and dim recollections of the Dragon Book): > * parser sees a '[' token and enters the 'atom' state > (ie. calls a subroutine 'atom()') > * swallows the '[' and immediately enters 'listmaker' (no other option) > * now it wants to enter either 'testlist' or 'rangemaker': but the > FIRST(testlist) == FIRST(test) (testlist can only start with a > test), and FIRST(rangemaker) == FIRST(test) + ':' (rangemaker > can start with a test or the ':' token) > * I suspect this is the ambiguity: overlap in the FIRST sets of > testlist and rangemaker Greg's got it right. It's a recursive descent a.k.a. LL(1) parser. The solution? Try to rewrite the grammar to avoid the ambiguities. So we have [testlist | rangemaker] for listmaker, where testlist is test(','test)* and rangemaker is [test]':'[test]. (Note that you'll have to add [':'[test]] to support [lo:hi:step], but tht's not the problem here.) Rewrite this as listmaker: [rangetail | test((','test)* | rangetail)] rangetail: ':' [test] [':' [test]] Now the two alternatives have different FIRST sets. The disadvantage is that you have to change the code generator to work withthis mess -- that's why people like LALR(1) and other parsers. But LL(1) was all I could create myself (Python uses a homegrown parser generator). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein at lyra.org Fri Jul 7 00:57:32 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:57:32 -0700 Subject: [Python-Dev] internal value (was: Hash values and comparing objects) In-Reply-To: <3964B39C.7E0CD312@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 06:28:12PM +0200 References: <3964B39C.7E0CD312@lemburg.com> Message-ID: <20000706155732.W29590@lyra.org> On Thu, Jul 06, 2000 at 06:28:12PM +0200, M.-A. Lemburg wrote: >... > Previously, Unicode used UTF-8 as basis for calculating the > hash value (the Unicode object created a UTF-8 string object > and delegated the hash value calculation to it, caching the > result and the string for future use). Since I would like > to make the internal encoding cache use the default encoding > instead, I have two problems to solve: Woah... are you saing that the "t#" marker could now return arbitrary encodings? That C code cannot depend on any particular encoding? Why? This is a pretty big semantic change. Cheers, -g -- Greg Stein, http://www.lyra.org/ From esr at thyrsus.com Fri Jul 7 01:04:10 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 19:04:10 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706183810.B15938@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Thu, Jul 06, 2000 at 06:38:10PM -0400 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <20000706183810.B15938@ludwig.cnri.reston.va.us> Message-ID: <20000706190410.B27191@thyrsus.com> Greg Ward : > Ooh, that may not work so well because of the need to background X > browsers. Ick. Bingo. You got it. That code is a lot smarter than it looks... > One could dream up a wild scheme that forks and forks > and does the backgrounding itself, but what the hell: we're launching a > big fat hairy *web browser* here, what does it matter if a shell is > involved to parse the "&"? My thinking exactly. A couple extra parses and forks are nothing. > Also, the wild variability of "which" across platforms and shells makes > me wonder if, somewhere out there, there isn't a "which" that fails to > return true/false on success. (check check check). Yes, there is: with > bash 2.0.3 on Solaris 2.6: Ugh... -- Eric S. Raymond In recent years it has been suggested that the Second Amendment protects the "collective" right of states to maintain militias, while it does not protect the right of "the people" to keep and bear arms. If anyone entertained this notion in the period during which the Constitution and the Bill of Rights were debated and ratified, it remains one of the most closely guarded secrets of the eighteenth century, for no known writing surviving from the period between 1787 and 1791 states such a thesis. -- Stephen P. Halbrook, "That Every Man Be Armed", 1984 From gstein at lyra.org Fri Jul 7 00:59:40 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:59:40 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 In-Reply-To: <20000706200924.B26534@xs4all.nl>; from thomas@xs4all.net on Thu, Jul 06, 2000 at 08:09:24PM +0200 References: <200007052256.PAA12103@slayer.i.sourceforge.net> <14691.65439.950090.60795@anthem.concentric.net> <20000706142731.K13478@xs4all.nl> <20000706200924.B26534@xs4all.nl> Message-ID: <20000706155940.X29590@lyra.org> On Thu, Jul 06, 2000 at 08:09:24PM +0200, Thomas Wouters wrote: > On Thu, Jul 06, 2000 at 02:27:32PM +0200, Thomas Wouters wrote: > > PyObject_INIT((PyObject *)b, &PyBuffer_Type); > > > > The 'value computed' is useless. The value computed is computed by the ',' > > operator, but the only things in there are sideffect operators. The last > > operation in the string of ',''s is either a void-returning function or an > > assignment, so I'd classify this one as a cosmetic bug in gcc ;) adding a > > '(void)' cast to the PyObject_INIT() macro or the calls to it would fix the > > warning. > > Er, ignore that. The value computed isn't useless, it's just the first > argument. I overlooked that, sorry :P The return value is used in a couple > of places. That leaves only one option to squench this warning, a (void) > cast at the one spot that causes a warning. Or is there a better way ? I would say: make PyObject_INIT() a void "function". Since it is just returning the first argument, then the code can just use that explicitly. Having a return value seems to indicate that what you pass and what comes back might actually change. Eek! Not true. If you don't want to make it a void function, then you'll need to add (void) casts to a few places. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Fri Jul 7 01:58:17 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 18:58:17 -0500 Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: Your message of "Thu, 06 Jul 2000 15:49:57 MST." <20000706154956.U29590@lyra.org> References: <200007061855.LAA05178@slayer.i.sourceforge.net> <20000706154956.U29590@lyra.org> Message-ID: <200007062358.SAA02001@cj20424-a.reston1.va.home.com> > On Thu, Jul 06, 2000 at 11:55:14AM -0700, Skip Montanaro wrote: > >... > > + /* Exported function to load a readline history file */ > > + > > + static PyObject * > > + read_history_file(self, args) > > + PyObject *self; > > + PyObject *args; > > + { > > + char *s = NULL; > > + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) > > This allows somebody to pass read_history_file(None). That doesn't feel > right. I'd suggest using the 's' format code. > > (if they want the default, then pass nothing at all) Hm, I actually like this style and would recommend it. There are often times where it's useful to pass an explicit parameter that says "use the default". For example when writing a Python wrapper: def my_read_hist(file=None): ...do-something... readline.read_history_file(file) ...do-something-else... With what you propose, you'd have to write def my_read_hist(file=None): ...do-something... if file is None: readline.read_history_file() else: readline.read_history_file(file) ...do-something-else... I don't see how forcing users to do that would be considered elegant. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein at lyra.org Fri Jul 7 01:05:40 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 16:05:40 -0700 Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: <200007062358.SAA02001@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 06:58:17PM -0500 References: <200007061855.LAA05178@slayer.i.sourceforge.net> <20000706154956.U29590@lyra.org> <200007062358.SAA02001@cj20424-a.reston1.va.home.com> Message-ID: <20000706160540.Y29590@lyra.org> Good point! Ignore me, then :-) Cheers, -g On Thu, Jul 06, 2000 at 06:58:17PM -0500, Guido van Rossum wrote: > > On Thu, Jul 06, 2000 at 11:55:14AM -0700, Skip Montanaro wrote: > > >... > > > + /* Exported function to load a readline history file */ > > > + > > > + static PyObject * > > > + read_history_file(self, args) > > > + PyObject *self; > > > + PyObject *args; > > > + { > > > + char *s = NULL; > > > + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) > > > > This allows somebody to pass read_history_file(None). That doesn't feel > > right. I'd suggest using the 's' format code. > > > > (if they want the default, then pass nothing at all) > > Hm, I actually like this style and would recommend it. There are > often times where it's useful to pass an explicit parameter that says > "use the default". For example when writing a Python wrapper: > > def my_read_hist(file=None): > ...do-something... > readline.read_history_file(file) > ...do-something-else... > > With what you propose, you'd have to write > > def my_read_hist(file=None): > ...do-something... > if file is None: > readline.read_history_file() > else: > readline.read_history_file(file) > ...do-something-else... > > I don't see how forcing users to do that would be considered elegant. > > --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) -- Greg Stein, http://www.lyra.org/ From barry at scottb.demon.co.uk Fri Jul 7 00:58:17 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Thu, 6 Jul 2000 23:58:17 +0100 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe Message-ID: <000001bfe79d$ac720ae0$060210ac@private> os.popen fails to work if pythonw.exe is used to start python. This is true for 1.5.2 and 1.6a2. The root cause of the problem is in the Microsoft C RTL implementation of _popen(). _popen() will fail if there is not a valid file descriptor for stdin or stdout. The following replacement for WinMain.c works around the problem. I also ensure a valid descriptor for stderr for completeness. This was compiled and test under VC++ 6.0 SP3 on Windows 2000. BArry -------------------------------- WinMain.c ------------------------- /* Minimal main program -- everything is loaded from the library. */ #include #include "Python.h" #include #include extern int Py_Main(); int WINAPI WinMain( HINSTANCE hInstance, // handle to current instance HINSTANCE hPrevInstance, // handle to previous instance LPSTR lpCmdLine, // pointer to command line int nCmdShow // show state of window ) { /* * make sure that the C RTL has valid file descriptors for * stdin, stdout, stderr. Use the NUL device. * This allows popen to work under pythonw. * * When pythonw.exe starts the C RTL function _ioinit is called * first. WinMain is called later hence the need to check for * invalid handles. * * Note: FILE stdin, stdout, stderr do not use the file descriptors * setup here. They are already initialised before WinMain was called. */ int null_file; null_file = open( "NUL", _O_RDWR ); /* check for STDIN is invalid */ if( _get_osfhandle( 0 ) == -1 ) { dup2( null_file, 0 ); } /* check for STDOUT is invalid */ if( _get_osfhandle( 1 ) == -1 ) { dup2( null_file, 1 ); } /* check for STDERR is invalid */ if( _get_osfhandle( 2 ) == -1 ) { dup2( null_file, 2 ); } close( null_file ); return Py_Main(__argc, __argv); } From pingster at ilm.com Fri Jul 7 01:09:21 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 6 Jul 2000 16:09:21 -0700 (PDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007062254.RAA01617@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 6 Jul 2000, Guido van Rossum wrote: > > That doesn't answer the question. Why select.select() instead of > > os.select()? I've never understood that one myself. > > Different platform dependencies. The select module works on Windows, > Mac and Unix. The posix module only runs on Unix and (under the name > "nt", but using the same source file) on Win32. Okay, then can select() be exposed in the os module by the posix, nt, and mac modules? -- ?!ng From fdrake at beopen.com Fri Jul 7 01:16:05 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 19:16:05 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: References: <200007062254.RAA01617@cj20424-a.reston1.va.home.com> Message-ID: <14693.4917.776799.332729@cj42289-a.reston1.va.home.com> Ka-Ping Yee writes: > Okay, then can select() be exposed in the os module by the > posix, nt, and mac modules? I don't think changing the interface is reasonable. There's too much legacy, and it's not like any of this is broken. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From rassilon at list.org Fri Jul 7 01:28:02 2000 From: rassilon at list.org (Bill Tutt) Date: Thu, 6 Jul 2000 16:28:02 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: <3964FD30.BB0F14D1@lemburg.com> Message-ID: On Thu, 6 Jul 2000, M.-A. Lemburg wrote: > Bill Tutt wrote: > > > > On Thu, 6 Jul 2000, Guido van Rossum wrote: > > > > > > In any event, having the typedef is still useful since it clarifies the > > > > meaning behind the code. > > > > > > > How about this: > > /* > > * Use this typedef when you need to represent a UTF-16 surrogate pair > > * as single unsigned integer. > > */ > > #if SIZEOF_INT >= 4 > > typedef unsigned int Py_UCS4; > > #else > > #if SIZEOF_LONG >= 4 > > typedef unsigned long Py_UCS4; > > #else > > #error "can't find integral type that can contain 32 bits" > > #endif /* SIZEOF_LONG */ > > #endif /* SIZEOF_INT */ > > I like the name... Py_UCS4 is indeed what we're talking about > here. > > What I don't understand is why you raise a compile error; AFAIK, > unsigned long is at least 32 bits on all platforms and that's > what the Unicode implementation would need to support UCS4 -- more > bits don't do any harm since the storage type is fixed at > 16-bit UTF-16 values. > Loud and obnoxious failures are much better than silent, and hard to debug failures. :) If unsigned long is big enough on all of the platforms we care about, then they won't ever see the compile error. :) Bill From guido at beopen.com Fri Jul 7 03:06:03 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 20:06:03 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Thu, 06 Jul 2000 16:09:21 MST." References: Message-ID: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> > On Thu, 6 Jul 2000, Guido van Rossum wrote: > > > That doesn't answer the question. Why select.select() instead of > > > os.select()? I've never understood that one myself. > > > > Different platform dependencies. The select module works on Windows, > > Mac and Unix. The posix module only runs on Unix and (under the name > > "nt", but using the same source file) on Win32. > > Okay, then can select() be exposed in the os module by the > posix, nt, and mac modules? What's the point? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From pingster at ilm.com Fri Jul 7 02:20:53 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 6 Jul 2000 17:20:53 -0700 (PDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 6 Jul 2000, Guido van Rossum wrote: > > Okay, then can select() be exposed in the os module by the > > posix, nt, and mac modules? > > What's the point? It's an operating system function, like all the others. select() belongs in os for the same reason that we don't import chdir, import wait, import fork, etc. etc. It's not an earth-shattering thing; i'm just pretty sure most people look for os.select() first and wonder why it's missing before discovering select.select(). -- ?!ng From klm at digicool.com Fri Jul 7 02:22:05 2000 From: klm at digicool.com (Ken Manheimer) Date: Thu, 6 Jul 2000 20:22:05 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Tim Peters wrote: > the-committee-wasn't-just-jerking-off-the-last-10-years-ly y'rs - > tim (The obvious question is, where they doing those other things at the same time, or during breaks?) Ken klm at digicool.com From fdrake at beopen.com Fri Jul 7 02:24:47 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 20:24:47 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: References: Message-ID: <14693.9039.56927.20039@cj42289-a.reston1.va.home.com> Ken Manheimer writes: > (The obvious question is, where they doing those other things at the same > time, or during breaks?) I'd rather not find out! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Vladimir.Marangozov at inrialpes.fr Fri Jul 7 02:34:09 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 7 Jul 2000 02:34:09 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Ka-Ping Yee" at Jul 05, 2000 12:20:41 PM Message-ID: <200007070034.CAA02914@python.inrialpes.fr> Ka-Ping Yee wrote: > > > [Ping] > > > 4. Added int *expected_ret argument to PyParser_AddToken; on > > > a syntax error, PyParser_AddToken (in parser.c) places the > > > expected token type (if any) into this output parameter. > > [me] > > I'd suggest passing a pointer to the perrdetail structure (to the > > whole error, that is), instead of a pointer to one of its fields. > [Ping] > I did consider that; the reason i eventually decided against it > is that munging perrdetail appears to be [parsetok.c] parsetok()'s > responsibility, not [parser.c] PyParser_AddToken()'s. The latter > doesn't mess with any of the other fields of perrdetail -- and it > returns an error code which becomes err_ret->error, so passing in > perrdetail gives PyParser_AddToken() two ways of returning the same > information. The redundancy and possible future confusion didn't > seem worth it. > > Another alternative is to change the return value so it *isn't* > an error code (only a success/fail flag) and then rely on the error > code in err_ret->error. I guess if you see a compelling reason for > this i don't mind doing it. But is there one? Okay. Since you've already altered the error list in errcode.h, I think that the best thing to do is to re-introduce E_INDENT but for the "missing indentation" case (reported to the user as "expected an indented block"), then return E_INDENT from AddToken() and revert back its signature. Thus all additional error cases you've detected so far would be handled fine in pythonrun.c. Does this sound good for you? I share most of your thoughts -- after another look at the updated patch, I don't think I like the augmented perrdetail and the redundant communication interface with PyParser_AddToken(). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From jeremy at beopen.com Fri Jul 7 03:05:23 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 6 Jul 2000 21:05:23 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706190410.B27191@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <20000706183810.B15938@ludwig.cnri.reston.va.us> <20000706190410.B27191@thyrsus.com> Message-ID: <14693.11475.243489.826433@bitdiddle.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> Greg Ward : >> Ooh, that may not work so well because of the need to background >> X browsers. Ick. ESR> Bingo. You got it. That code is a lot smarter than it ESR> looks... A comment is in order then. If the code is smarter than it looks, most people aren't going to think it looks very smart. Jeremy From fdrake at beopen.com Fri Jul 7 03:09:35 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 21:09:35 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706171608.A26696@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> Message-ID: <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > there's a functionally similar name/value pair facility available > through system resource forks on the Mac. I really think a profile > file is excessively heavyweight here. Environment variables or X I still haven't heard from any MacOS users what the "right" way to do this sort of thing is. Jack, Sjoerd, Just... are you listening? > I've actually been seriously thinking, once this is in the Python > library, of going to the Perl and Tcl people and giving them code that > would make *their* standard libraries do the right thing with the > BROWSER variable. It shouldn't only be portable across Python > applications, but across scripting languages as well -- something that > would be much harder to do with an .ini file. I don't buy that using a config file is harder for those languages, but I think providing similar functionality for all is a great idea. Ok, here's a version that keeps the idea of a register() function, but simplifies the machinery quite a bit. Instead of using a config file, the BROWSER environment variable is used. If not set, the default on Windows is to use the Windows default setting. On Unix, the default is Netscape if $DISPLAY is set, otherwise it's the "command line browser", which tries, in order: netscape, mosaic(!), lync, and w3m. I left out Mozilla since I couldn't get it to work at all last time I tried it (though I've had better results previously). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- A non-text attachment was scrubbed... Name: webbrowser.py Type: text/x-python Size: 4438 bytes Desc: web browser controller module URL: From fdrake at beopen.com Fri Jul 7 03:14:38 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 21:14:38 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> Message-ID: <14693.12030.937901.65835@cj42289-a.reston1.va.home.com> Fred L. Drake, Jr. writes: > lync, and w3m. I left out Mozilla since I couldn't get it to work at > all last time I tried it (though I've had better results previously). I just pulled downthe M16 release of Mozilla - again - and it still doesn't know how to run. I can cd to the installation directory and run it directly, but it just doesn't do the right thing for normal use -- type "mozilla" isn't enough. I'm actually pretty surprised no one has fixed that. Their wrapper shell scripts look pretty screwed up. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gmcm at hypernet.com Fri Jul 7 03:42:28 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 6 Jul 2000 21:42:28 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: References: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> Message-ID: <1249188344-7661966@hypernet.com> Ka-Ping Yee wrote: [wants select in os] > It's an operating system function, like all the others. > select() belongs in os for the same reason that we don't > import chdir, import wait, import fork, etc. etc. > > It's not an earth-shattering thing; i'm just pretty sure > most people look for os.select() first and wonder why it's > missing before discovering select.select(). Actually Windows users probably first look in socket, since it's a socket-only thing on Windows. - Gordon From jeremy at beopen.com Fri Jul 7 04:02:32 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 6 Jul 2000 22:02:32 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> References: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> Message-ID: <14693.14904.827148.290679@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> Okay, then can select() be exposed in the os module by the posix, >> nt, and mac modules? GvR> What's the point? Exactly. I don't see much point to moving it. Jeremy From esr at thyrsus.com Fri Jul 7 04:20:45 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 22:20:45 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.11727.410675.928619@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 09:09:35PM -0400 References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> Message-ID: <20000706222045.C27688@thyrsus.com> Fred L. Drake, Jr. : > Ok, here's a version that keeps the idea of a register() function, > but simplifies the machinery quite a bit. Instead of using a config > file, the BROWSER environment variable is used. If not set, the > default on Windows is to use the Windows default setting. On Unix, > the default is Netscape if $DISPLAY is set, otherwise it's the > "command line browser", which tries, in order: netscape, mosaic(!), > lync, and w3m. I left out Mozilla since I couldn't get it to work at > all last time I tried it (though I've had better results previously). Looks pretty good...though I have to wonder how much point there is in Grail support at this point. Having something like this in the standard library will be a real boon for on-line documentation and Web-aware programs. (I got M16 to run without difficulty, BTW. I have not switched yet because the UI still has a lot of sharp edges.) -- Eric S. Raymond The world is filled with violence. Because criminals carry guns, we decent law-abiding citizens should also have guns. Otherwise they will win and the decent people will lose. -- James Earl Jones From rassilon at list.org Fri Jul 7 04:15:01 2000 From: rassilon at list.org (Bill Tutt) Date: Thu, 6 Jul 2000 19:15:01 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Tim Peters wrote: > [Bill Tutt] > > How about this: > > /* > > * Use this typedef when you need to represent a UTF-16 surrogate pair > > * as single unsigned integer. > > */ > > #if SIZEOF_INT >= 4 > > typedef unsigned int Py_UCS4; > > #else > > #if SIZEOF_LONG >= 4 > > typedef unsigned long Py_UCS4; > > #else > > #error "can't find integral type that can contain 32 bits" > > #endif /* SIZEOF_LONG */ > > #endif /* SIZEOF_INT */ > > Much better! In the future (when the infrastructure is in place), I expect > we'll replace the #if stuff here with > > typedef Py_uint_least32_t UCS4; > > instead (where Py_uint_least32_t is defined in pyfort.h, and uint_least32_t > is the C9X spelling of the true requirement). > > BTW, why not use #elif instead of nested #ifs? #elif is clearer and > shorter. > I've updated both of these patches on SF. Comments welcome, Bill From skip at mojam.com Fri Jul 7 04:13:57 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 21:13:57 -0500 (CDT) Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: <20000706154956.U29590@lyra.org> References: <200007061855.LAA05178@slayer.i.sourceforge.net> <20000706154956.U29590@lyra.org> Message-ID: <14693.15589.244326.670660@beluga.mojam.com> Greg> On Thu, Jul 06, 2000 at 11:55:14AM -0700, Skip Montanaro wrote: >> ... >> + /* Exported function to load a readline history file */ >> + >> + static PyObject * >> + read_history_file(self, args) >> + PyObject *self; >> + PyObject *args; >> + { >> + char *s = NULL; >> + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) Greg> This allows somebody to pass read_history_file(None). That doesn't Greg> feel right. I'd suggest using the 's' format code. Thanks, I'll fix it tomorrow. I basically cloned read_init_file's code. That probably needs a tweak as well. Skip From skip at mojam.com Fri Jul 7 04:15:55 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 21:15:55 -0500 (CDT) Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: <20000706160540.Y29590@lyra.org> References: <200007061855.LAA05178@slayer.i.sourceforge.net> <20000706154956.U29590@lyra.org> <200007062358.SAA02001@cj20424-a.reston1.va.home.com> <20000706160540.Y29590@lyra.org> Message-ID: <14693.15707.301363.371690@beluga.mojam.com> Greg> Good point! Greg> Ignore me, then :-) No problem... ;-) Skip From Vladimir.Marangozov at inrialpes.fr Fri Jul 7 04:38:48 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 7 Jul 2000 04:38:48 +0200 (CEST) Subject: [Python-Dev] list comprehensions again... In-Reply-To: from "Tim Peters" at Jul 05, 2000 11:51:53 PM Message-ID: <200007070238.EAA03292@python.inrialpes.fr> Tim Peters wrote: > > OK, I'll be serious this time: if "the next release" is next week, damn > straight I want to stick to the feature freeze. > > But if it becomes predictably delayed for months, sure, open the floodgates > again. All this sounds reasonable. > > Unfortunately, the stuff holding up the release isn't technical in nature, > so there's nothing most of us can do to affect the outcome either way. So? To be or not to be? Make up your mind guys and we'll follow . You're the ones who have the best approximation of the set of all possible predictions. At least it should be better than mine. Since the release schedule was already revisited a number of times, and since we're moving to a major 2.0 version, I'm inclined to think that it would be fine to: 1) delay the release for september, or have a long beta-cycle until then (most people are going to spend their vacation in august anyway a) we won't get a solid feedback during a short beta in august, b) people will be pleased to see the major release ready on their return 2) Try finalizing at best & ASAP (say, next week) the pending issues with the big chunks that are already in -- SRE and Unicode. 3) Consider for inclusion in 2.0 the features we _already_know_ for sure have been delayed for 2.1 (a.k.a. -- 1.7) due to lack of time. 4) Emphasize the "quantum leap" with the 2.0 release by underlining the XML stuff Paul talked about + the major features considered in 3) I believe that staying in an undetermined Z-state for more than a week without a set of clearly defined options is not really what we all want, but maybe you have some additional considerations that may explain the ongoing patience about this lag... back-to-the-future-ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From fdrake at beopen.com Fri Jul 7 04:37:31 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 22:37:31 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706222045.C27688@thyrsus.com> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> <20000706222045.C27688@thyrsus.com> Message-ID: <14693.17003.16089.319857@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Looks pretty good...though I have to wonder how much point there is in > Grail support at this point. Having something like this in the standard That was the first browser I supported! (Which might indicate the age of some of the code a bit. ;) On the other hand, I don't see any real reason to discard it. I wouldn't mind a class to support Mosaic's CCI control interface either. ;) > library will be a real boon for on-line documentation and Web-aware > programs. Right. I originally wrote this (for Grail & Netscape) for a bookmark handling tool I never finished; this was the start of the browser controller; each class was supposed to be, essentially, a device driver for a Web-display abstract device. > (I got M16 to run without difficulty, BTW. I have not switched yet > because the UI still has a lot of sharp edges.) Interesting. I just re-installed it as root on Mandrake 7.0, and get the following as Joe User with all the default installation settings: cj42289-a(~/projects/python); PATH=/usr/local/mozilla:$PATH mozilla /dist/bin/run-mozilla.sh ./mozilla-bin /usr/local/mozilla/mozilla: /dist/bin/run-mozilla.sh: No such file or directory [127] cj42289-a(~/projects/python); (The "127" was the exit code, thanks to a bashlet from Ken Manheimer.) M12 did much better at this stuff, though the browser itself seems to have improved. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Fri Jul 7 05:22:35 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 22:22:35 -0500 (CDT) Subject: [Python-Dev] Re: [Patches] [Patch #100752] Make atoi work for negative bases, a useful generalization In-Reply-To: <200007070309.UAA12927@bush.i.sourceforge.net> References: <200007070309.UAA12927@bush.i.sourceforge.net> Message-ID: <14693.19707.553522.523595@beluga.mojam.com> Alex, I looked at your patch. Can you provide a little motivation for those of us who are base challenged? I've never even heard of negative bases. Thx, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From fdrake at beopen.com Fri Jul 7 05:40:33 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 23:40:33 -0400 (EDT) Subject: [Python-Dev] webbrowser module Message-ID: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> Ok, I've checked in the documentation for the webbrowser documentation. The implementation can go in as soon as SF clears a bogus read lock (support request files 6.5 hours ago). Well, I said I knew about InternetConfig for MacOS, but I clearly hadn't read the documentation! Getting this module working on MacOS is a trivial matter, if the docs are to be believed. If someone with a Mac could test it with a script like: import webbrowser webbrowser.open("http://www.python.org/") and let me know what happens, I'd really appreciate it! I've attached the version with Mac support below. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- A non-text attachment was scrubbed... Name: webbrowser.py Type: text/x-python Size: 4880 bytes Desc: web browser controller module URL: From moshez at math.huji.ac.il Fri Jul 7 06:25:40 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 7 Jul 2000 07:25:40 +0300 (IDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Bill Tutt wrote: > How about this: > /* > * Use this typedef when you need to represent a UTF-16 surrogate pair > * as single unsigned integer. > */ > #if SIZEOF_INT >= 4 > typedef unsigned int Py_UCS4; > #else > #if SIZEOF_LONG >= 4 > typedef unsigned long Py_UCS4; > #else > #error "can't find integral type that can contain 32 bits" > #endif /* SIZEOF_LONG */ > #endif /* SIZEOF_INT */ +0 from me, except (and this is really a nit, since I don't know real machines like that) what if sizeof(long) == 2 and sizeof(long long) == 4? long long is "almost standard", and I'm sure a configure test could make sure it is really there, so you can add #else #if HAVE_LONG_LONG and SIZEOF_LONG_LONG >= 4 .... #endif -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From mal at lemburg.com Fri Jul 7 10:16:09 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 10:16:09 +0200 Subject: [Python-Dev] Re: internal value (was: Hash values and comparing objects) References: <3964B39C.7E0CD312@lemburg.com> <20000706155732.W29590@lyra.org> Message-ID: <396591C9.C3533427@lemburg.com> Greg Stein wrote: > > On Thu, Jul 06, 2000 at 06:28:12PM +0200, M.-A. Lemburg wrote: > >... > > Previously, Unicode used UTF-8 as basis for calculating the > > hash value (the Unicode object created a UTF-8 string object > > and delegated the hash value calculation to it, caching the > > result and the string for future use). Since I would like > > to make the internal encoding cache use the default encoding > > instead, I have two problems to solve: > > Woah... are you saing that the "t#" marker could now return arbitrary > encodings? That C code cannot depend on any particular encoding? Right. If C code needs a particular encoding other than the locale dependent default encoding, it'll have to use "es#". > Why? This is a pretty big semantic change. It completes the switch from the fixed UTF-8 encoding to the locale dependent default encoding which we decided on a couple of weeks ago. Note that this change will make enhance compatibility with existing C extensions since they will now get the encoding that is default for them anyway... well, at least they stand a good chance ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From sjoerd at oratrix.nl Fri Jul 7 11:03:39 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Fri, 07 Jul 2000 11:03:39 +0200 Subject: [Python-Dev] forwarded message from noreply@sourceforge.net In-Reply-To: Your message of Thu, 06 Jul 2000 12:53:19 -0400. <14692.47487.15354.645423@cj42289-a.reston1.va.home.com> References: <14692.47487.15354.645423@cj42289-a.reston1.va.home.com> Message-ID: <20000707090340.7D00931047C@bireme.oratrix.nl> On Thu, Jul 6 2000 "Fred L. Drake, Jr." wrote: > The bogus CVS lock in Modules/ is now fixed! That's very nice and much appreciated, but I had (and still have) a problem with a lock in Lib... -- Sjoerd Mullender From sjoerd at oratrix.nl Fri Jul 7 11:40:34 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Fri, 07 Jul 2000 11:40:34 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines Message-ID: <20000707094036.AA22C31047C@bireme.oratrix.nl> The new defines in Python.h for SUSv2 compatibility seriously hamper compilation on SGI IRIX. The problem is that defining _XOPEN_SOURCE causes a number of common but non-standard features to be removed. In particular, ctermid_r and altzone are no longer defined. The former causes a warning (assignment of int-returning function to char *), the latter causes an error (altzone not defined). Something needs to be done about this but I don't know what since I don't know why the defines were necessary. -- Sjoerd Mullender From fredrik at pythonware.com Fri Jul 7 11:58:31 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 11:58:31 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines References: <20000707094036.AA22C31047C@bireme.oratrix.nl> Message-ID: <018301bfe7f9$e85c9dc0$0900a8c0@SPIFF> sjoerd wrote: > The new defines in Python.h for SUSv2 compatibility seriously hamper > compilation on SGI IRIX. > Something needs to be done about this but I don't know what since I > don't know why the defines were necessary. It was an attempt to make sure certain features were correctly defined. Some platforms add more stuff when you define this one, but others obviously remove stuff... I suggest removing it for now (it solves problems on Linux, but causes problems on at least Irix and tru64), and adding SUSv2 compliance as a possible design goal for Py3K... I've attached a patch (for some reason, I cannot check things in from any of my work machines. sigh.) [fredrik at brain src]$ cvs diff -u Include/Python.h Index: Include/Python.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Include/Python.h,v retrieving revision 2.20 diff -u -r2.20 Python.h --- Include/Python.h 2000/07/05 08:53:18 2.20 +++ Include/Python.h 2000/07/07 09:55:53 @@ -12,14 +12,17 @@ redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES. ******************************************************************/ -/* Enable compiler features including SUSv2 compatibility; switching - on C lib defines doesn't work here, because the symbols haven't - necessarily been defined yet. */ +/* Enable compiler features; switching on C lib defines doesn't work + here, because the symbols haven't necessarily been defined yet. */ + #ifndef _GNU_SOURCE # define _GNU_SOURCE 1 #endif + +#if 0 /* not yet. breaks stuff on too many platforms */ #ifndef _XOPEN_SOURCE # define _XOPEN_SOURCE 500 +#endif #endif /* Include nearly all Python header files */ From tismer at appliedbiometrics.com Fri Jul 7 12:21:07 2000 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 07 Jul 2000 12:21:07 +0200 Subject: [Python-Dev] how do I release a cvs lock? References: <14692.36768.23073.781592@beluga.mojam.com> <200007061515.KAA13255@cj20424-a.reston1.va.home.com> <396498D7.97ABB543@appliedbiometrics.com> <200007061537.KAA13448@cj20424-a.reston1.va.home.com> Message-ID: <3965AF13.C595B561@appliedbiometrics.com> Guido van Rossum wrote: > > > Do we really want to live on with SourceForge(t) ? > > It seems to be pleasant for small projects, but > > maybe it would be more convenient to have a CVS > > that we control directly? > > The new starship is very powerful and could stand a couple of > > CVS repositories easily. > > > > While one might argue that this would give to much of Python > > to BeOpen (they got it already:), I think this could work > > smoothly. > > In my experience, maintaining the repository, with both anonymous and > privileged (commit) access, is a lot of work -- managing user accounts > for the privileged, keeping the machine up and running, etc. I'm > really quite happy with the level of support we get from SF. Sure, if you have many projects and many users. > In the long run, BeOpen might be interested in running this kind of > service for the Python and other communities; but for now, it would > just be a burden. I was thinking of creating this service on the starship machine, and just for the couple of projects that we need, without help from BeOpen. I could initiate such a service, since it was one of our goals when we have a more powerful machine, and now we have it. But without interest I can save the time. - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From jack at oratrix.nl Fri Jul 7 12:33:03 2000 From: jack at oratrix.nl (Jack Jansen) Date: Fri, 07 Jul 2000 12:33:03 +0200 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: Message by "Eric S. Raymond" , Thu, 6 Jul 2000 12:21:22 -0400 , <20000706122122.A25613@thyrsus.com> Message-ID: <20000707103308.8074FE2673@oratrix.oratrix.nl> I would suggest not putting it into urllib but in a "launch" module. First, the actual implementation is going to be completely different for the various platforms, so if you put it into urllib it'll probably have to happen with an intermedeate module anyway, and by putting it in a separate module it's probably easier to extend to to various other things you might want to launch (fileviewers, editors, etc). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack at oratrix.nl Fri Jul 7 12:46:56 2000 From: jack at oratrix.nl (Jack Jansen) Date: Fri, 07 Jul 2000 12:46:56 +0200 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: Message by "Eric S. Raymond" , Thu, 6 Jul 2000 17:16:08 -0400 , <20000706171608.A26696@thyrsus.com> Message-ID: <20000707104701.0D3EBE2673@oratrix.oratrix.nl> Recently, "Eric S. Raymond" said: > Environment variables work for Windows users, too -- and I believe > there's a functionally similar name/value pair facility available > through system resource forks on the Mac. I really think a profile > file is excessively heavyweight here. Environment variables or X > resources are a better medium for this kind of shared preference. On the Mac life is easy: Internet Config keeps all this knowledge (and much more) in a database, and Python has an interface to it. So the code is simply import ic ic_instance = ic.IC() ic_instance.launchurl(url) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From mal at lemburg.com Fri Jul 7 12:54:48 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 12:54:48 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines References: <20000707094036.AA22C31047C@bireme.oratrix.nl> Message-ID: <3965B6F8.72742A2E@lemburg.com> Sjoerd Mullender wrote: > > The new defines in Python.h for SUSv2 compatibility seriously hamper > compilation on SGI IRIX. > > The problem is that defining _XOPEN_SOURCE causes a number of common > but non-standard features to be removed. In particular, ctermid_r and > altzone are no longer defined. The former causes a warning > (assignment of int-returning function to char *), the latter causes an > error (altzone not defined). > Something needs to be done about this but I don't know what since I > don't know why the defines were necessary. I think Fredrik is right. I'll remove the _XOPEN_SOURCE for now, but leave the _GNU_SOURCE define in (on Linux, Python compiles just fine using _GNU_SOURCE). Perhaps you could figure out which defines are needed to reenable the missing APIs on IRIX when _XOPEN_SOURCE is defined... it would be helpful to help pin-point the weak spots w/r to SUSv2 compatibility. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Fri Jul 7 14:29:27 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 07:29:27 -0500 Subject: [Python-Dev] Toby Dickenson's Unicode experience Message-ID: <200007071229.HAA03626@cj20424-a.reston1.va.home.com> He's got a point... Maybe add ustr(x) with the semantics below? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------- Forwarded Message Date: Fri, 07 Jul 2000 10:53:39 +0100 From: Toby Dickenson To: I18n-sig at python.org Subject: [I18n-sig] Unicode experience I'm just nearing the end of getting Zope to play well with unicode data. Most of the changes involved replacing a call to str, in situations where either a unicode or narrow string would be acceptable. My best alternative is: def convert_to_something_stringlike(x): if type(x)==type(u''): return x else: return str(x) This seems like a fundamental operation - would it be worth having something similar in the standard library? Toby Dickenson tdickenson at geminidataloggers.com _______________________________________________ I18n-sig mailing list I18n-sig at python.org http://www.python.org/mailman/listinfo/i18n-sig ------- End of Forwarded Message From guido at beopen.com Fri Jul 7 14:44:03 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 07:44:03 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: Your message of "Fri, 07 Jul 2000 13:15:49 +0200." <3965BBE5.D67DD838@lemburg.com> References: <3965BBE5.D67DD838@lemburg.com> Message-ID: <200007071244.HAA03694@cj20424-a.reston1.va.home.com> > Toby Dickenson wrote: > > > > I'm just nearing the end of getting Zope to play well with unicode > > data. Most of the changes involved replacing a call to str, in > > situations where either a unicode or narrow string would be > > acceptable. > > > > My best alternative is: > > > > def convert_to_something_stringlike(x): > > if type(x)==type(u''): > > return x > > else: > > return str(x) > > > > This seems like a fundamental operation - would it be worth having > > something similar in the standard library? Marc-Andre Lemburg replied: > You mean: for Unicode return Unicode and for everything else > return strings ? > > It doesn't fit well with the builtins str() and unicode(). I'd > say, make this a userland helper. I think this would be helpful to have in the std library. Note that in JPython, you'd already use str() for this, and in Python 3000 this may also be the case. At some point in the design discussion for the current Unicode support we also thought that we wanted str() to do this (i.e. allow 8-bit and Unicode string returns), until we realized that there were too many places that would be very unhappy if str() returned a Unicode string! The problem is similar to a situation you have with numbers: sometimes you want a coercion that converts everything to float except it should leave complex numbers complex. In other words it coerces up to float but it never coerces down to float. Luckily you can write that as "x+0.0" while converts int and long to float with the same value while leaving complex alone. For strings there is no compact notation like "+0.0" if you want to convert to string or Unicode -- adding "" might work in Perl, but not in Python. I propose ustr(x) with the semantics given by Toby. Class support (an __ustr__ method, with fallbacks on __str__ and __unicode__) would also be handy. > BTW, could you elaborate a bit on your experience with adding > Unicode support to Zope ? Such a report would certainly make > a nice complement to the Unicode tutorial and help other > people adding Unicode support to their apps. Yes, that's what we need. Thanks to Toby for pioneering this! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Fri Jul 7 13:56:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 7 Jul 2000 13:56:41 +0200 Subject: [Python-Dev] _sre.c's compiled size Message-ID: <20000707135641.F26534@xs4all.nl> For the record ;) I've compiled _sre with -fno-inline, on a RH6.2 egcs-1.1.2 system, and I have to admit compilation is going a lot faster. About 1/10th of the time, compared to without -fno-inline, which means it's about 1/100th of the annoyance when compiling a lot ;-) Also, the resulting object file is only 71K, instead of 440K, on my machine. Overall speed of python, as measured by pybench, doesn't really change, but pybench does not measure regexp speed at all, and I don't have a suitable testpackage for that. I've attached a teensy patch that allows '-f' flags to be used in Setup files, to be able to easily switch between the two. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- *** src/Modules/makesetup Thu Jul 6 13:58:06 2000 --- src-rangemaker/Modules/makesetup Fri Jul 7 13:23:25 2000 *************** *** 140,146 **** srcs) srcs="$srcs $arg"; skip=; continue;; esac case $arg in ! -[IDUC]*) cpps="$cpps $arg";; -Xlinker) libs="$libs $arg"; skip=libs;; -rpath) libs="$libs $arg"; skip=libs;; -[A-Zl]*) libs="$libs $arg";; --- 140,146 ---- srcs) srcs="$srcs $arg"; skip=; continue;; esac case $arg in ! -[IDUCf]*) cpps="$cpps $arg";; -Xlinker) libs="$libs $arg"; skip=libs;; -rpath) libs="$libs $arg"; skip=libs;; -[A-Zl]*) libs="$libs $arg";; From sjoerd at oratrix.nl Fri Jul 7 14:01:48 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Fri, 07 Jul 2000 14:01:48 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines In-Reply-To: Your message of Fri, 07 Jul 2000 12:54:48 +0200. <3965B6F8.72742A2E@lemburg.com> References: <20000707094036.AA22C31047C@bireme.oratrix.nl> <3965B6F8.72742A2E@lemburg.com> Message-ID: <20000707120149.6B39631047C@bireme.oratrix.nl> On Fri, Jul 7 2000 "M.-A. Lemburg" wrote: > Perhaps you could figure out which defines are needed to > reenable the missing APIs on IRIX when _XOPEN_SOURCE is > defined... it would be helpful to help pin-point the > weak spots w/r to SUSv2 compatibility. It looks like there is no way of doing this. The relevant bits of code are: In time.h (as an example): #if _SGIAPI && _NO_ANSIMODE extern time_t altzone; #endif /* _SGIAPI */ So _SGIAPI and _NO_ANSIMODE should both be defined and != 0. The definition of _SGIAPI is #define _SGIAPI ((defined(_SGI_SOURCE) && \ _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5) || \ (_ANSIMODE && _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5)) So, if _NO_XOPEN5 is 0, _SGIAPI is 0. The definition of _NO_XOPEN5 is #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || \ (defined(_XOPEN_SOURCE) && \ (_XOPEN_SOURCE+0 < 500))) So _NO_XOPEN5 is 0 since _XOPEN_SOURCE is defined and >= 500. All of this on IRIX 6.5.2. I can't check other versions of IRIX. -- Sjoerd Mullender From thomas at xs4all.net Fri Jul 7 14:08:56 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 7 Jul 2000 14:08:56 +0200 Subject: [Python-Dev] Grammar help. In-Reply-To: <200007062353.SAA01958@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 06:53:51PM -0500 References: <20000707000407.E26534@xs4all.nl> <20000706182256.A15938@ludwig.cnri.reston.va.us> <200007062353.SAA01958@cj20424-a.reston1.va.home.com> Message-ID: <20000707140856.G26534@xs4all.nl> On Thu, Jul 06, 2000 at 06:53:51PM -0500, Guido van Rossum wrote: > Greg's got it right. It's a recursive descent a.k.a. LL(1) parser. > The solution? Try to rewrite the grammar to avoid the ambiguities. > So we have [testlist | rangemaker] for listmaker, where testlist is > test(','test)* and rangemaker is [test]':'[test]. (Note that you'll > have to add [':'[test]] to support [lo:hi:step], but tht's not the > problem here.) > listmaker: [rangetail | test((','test)* | rangetail)] > rangetail: ':' [test] [':' [test]] Right, that's what I realized, too, after Greg told me what the problem was :) I basically did this, though the first 'test' in rangetail isn't optional, and I don't think it would make sense to have the 2nd test optional relative to the colon. But if you insist, it's a 2-character change ;) > The disadvantage is that you have to change the code generator to work > withthis mess -- that's why people like LALR(1) and other parsers. > But LL(1) was all I could create myself (Python uses a homegrown > parser generator). Actually, it turned out not to be that much of a mess. There's one 'if' statement that might look a bit strange, but the rest is pretty straightforward. I've attached the patch, it works ;) but it isn't finished yet: I'll try to get rid of the code duplication, add some comments and submit one relative to the list comprehension patch, so that when that one goes in, this one can, too ;) Don't forget to re-make Grammar if you test this patch out. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- diff -crN --exclude=CVS src/Grammar/Grammar src-rangemaker/Grammar/Grammar *** src/Grammar/Grammar Tue Mar 28 18:49:00 2000 --- src-rangemaker/Grammar/Grammar Fri Jul 7 10:32:19 2000 *************** *** 74,80 **** term: factor (('*'|'/'|'%') factor)* factor: ('+'|'-'|'~') factor | power power: atom trailer* ('**' factor)* ! atom: '(' [testlist] ')' | '[' [testlist] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ lambdef: 'lambda' [varargslist] ':' test trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME subscriptlist: subscript (',' subscript)* [','] --- 74,80 ---- term: factor (('*'|'/'|'%') factor)* factor: ('+'|'-'|'~') factor | power power: atom trailer* ('**' factor)* ! atom: '(' [testlist] ')' | '[' [listmaker] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ lambdef: 'lambda' [varargslist] ':' test trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME subscriptlist: subscript (',' subscript)* [','] diff -crN --exclude=CVS src/Include/opcode.h src-rangemaker/Include/opcode.h *** src/Include/opcode.h Fri Jun 30 19:58:04 2000 --- src-rangemaker/Include/opcode.h Fri Jul 7 13:05:13 2000 *************** *** 67,73 **** #define RETURN_VALUE 83 #define EXEC_STMT 85 ! #define POP_BLOCK 87 #define END_FINALLY 88 #define BUILD_CLASS 89 --- 67,73 ---- #define RETURN_VALUE 83 #define EXEC_STMT 85 ! #define BUILD_RANGE 86 #define POP_BLOCK 87 #define END_FINALLY 88 #define BUILD_CLASS 89 diff -crN --exclude=CVS src/Python/ceval.c src-rangemaker/Python/ceval.c *** src/Python/ceval.c Fri Jun 30 19:58:05 2000 --- src-rangemaker/Python/ceval.c Fri Jul 7 13:05:40 2000 *************** *** 65,70 **** --- 65,71 ---- static PyObject *cmp_outcome Py_PROTO((int, PyObject *, PyObject *)); static int import_from Py_PROTO((PyObject *, PyObject *, PyObject *)); static PyObject *build_class Py_PROTO((PyObject *, PyObject *, PyObject *)); + static PyObject *build_range Py_PROTO((PyObject *, PyObject *, PyObject *)); static int exec_statement Py_PROTO((PyFrameObject *, PyObject *, PyObject *, PyObject *)); static PyObject *find_from_args Py_PROTO((PyFrameObject *, int)); *************** *** 1110,1115 **** --- 1111,1127 ---- Py_DECREF(w); break; + case BUILD_RANGE: + w = POP(); + v = POP(); + u = POP(); + x = build_range(u, v, w); + PUSH(x); + Py_DECREF(u); + Py_DECREF(v); + Py_DECREF(w); + break; + case POP_BLOCK: { PyTryBlock *b = PyFrame_BlockPop(f); *************** *** 2801,2806 **** --- 2813,2897 ---- } } return PyClass_New(bases, methods, name); + } + + /* Stolen from bltinmodule.c */ + static long + get_len_of_range(lo, hi, step) + long lo; + long hi; + long step; /* must be > 0 */ + { + /* ------------------------------------------------------------- + If lo >= hi, the range is empty. + Else if n values are in the range, the last one is + lo + (n-1)*step, which must be <= hi-1. Rearranging, + n <= (hi - lo - 1)/step + 1, so taking the floor of the RHS gives + the proper value. Since lo < hi in this case, hi-lo-1 >= 0, so + the RHS is non-negative and so truncation is the same as the + floor. Letting M be the largest positive long, the worst case + for the RHS numerator is hi=M, lo=-M-1, and then + hi-lo-1 = M-(-M-1)-1 = 2*M. Therefore unsigned long has enough + precision to compute the RHS exactly. + ---------------------------------------------------------------*/ + long n = 0; + if (lo < hi) { + unsigned long uhi = (unsigned long)hi; + unsigned long ulo = (unsigned long)lo; + unsigned long diff = uhi - ulo - 1; + n = (long)(diff / (unsigned long)step + 1); + } + return n; + } + + static PyObject * + build_range(starto, endo, stepo) + PyObject *starto; + PyObject *endo; + PyObject *stepo; + { + long ilow = 0, ihigh = 0, istep = 1; + long bign; + int i, n; + PyObject * v; + + ilow = PyInt_AsLong(starto); + if (ilow == -1 && PyErr_Occurred()) + return NULL; + ihigh = PyInt_AsLong(endo); + if (ihigh == -1 && PyErr_Occurred()) + return NULL; + istep = PyInt_AsLong(stepo); + if (istep == -1 && PyErr_Occurred()) + return NULL; + + if (istep == 0) { + PyErr_SetString(PyExc_ValueError, "zero step for builtin range"); + return NULL; + } + if (istep > 0) + bign = get_len_of_range(ilow, ihigh, istep); + else + bign = get_len_of_range(ihigh, ilow, -istep); + n = (int)bign; + if (bign < 0 || (long)n != bign) { + PyErr_SetString(PyExc_OverflowError, + "too many items in builin range"); + return NULL; + } + v = PyList_New(n); + if (v == NULL) + return NULL; + for (i = 0; i < n; i++) { + PyObject *w = PyInt_FromLong(ilow); + if (w == NULL) { + Py_DECREF(v); + return NULL; + } + PyList_SET_ITEM(v, i, w); + ilow += istep; + } + return v; } static int diff -crN --exclude=CVS src/Python/compile.c src-rangemaker/Python/compile.c *** src/Python/compile.c Mon Jul 3 17:39:47 2000 --- src-rangemaker/Python/compile.c Fri Jul 7 13:05:41 2000 *************** *** 1018,1026 **** { int len; int i; ! if (TYPE(n) != testlist) ! REQ(n, exprlist); ! /* exprlist: expr (',' expr)* [',']; likewise for testlist */ len = (NCH(n) + 1) / 2; for (i = 0; i < NCH(n); i += 2) com_node(c, CHILD(n, i)); --- 1018,1025 ---- { int len; int i; ! REQ(n, listmaker); ! /* listmaker: test (',' test)* [',']; rangetail ommited */ len = (NCH(n) + 1) / 2; for (i = 0; i < NCH(n); i += 2) com_node(c, CHILD(n, i)); *************** *** 1029,1034 **** --- 1028,1081 ---- } static void + com_rangetail(c, n) + struct compiling *c; + node *n; + { + REQ(n, rangetail); + com_node(c, CHILD(n, 1)); + if (NCH(n) > 3) { + com_node(c, CHILD(n, 3)); + } else { + PyObject *v = PyInt_FromLong(1L); + if (!v) + c->c_errors++; + com_addoparg(c, LOAD_CONST, com_addconst(c, v)); + com_push(c, 1); + Py_XDECREF(v); + } + com_addbyte(c, BUILD_RANGE); + com_pop(c, 3); + } + + static void + com_listmaker(c, n) + struct compiling *c; + node *n; + { + if (TYPE(CHILD(n, 0)) != rangetail && (NCH(n) == 1 || + TYPE(CHILD(n, 1)) != rangetail)) { + /* '[' test (',' test)* [','] ']' */ + com_list_constructor(c, n); + return; + } + if (NCH(n) == 1) { + /* '[' rangetail ']' */ + PyObject *v = PyInt_FromLong(0L); + if (!v) + c->c_errors++; + com_addoparg(c, LOAD_CONST, com_addconst(c, v)); + com_push(c, 1); + Py_XDECREF(v); + com_rangetail(c, CHILD(n, 0)); + } else { + com_node(c, CHILD(n, 0)); + com_rangetail(c, CHILD(n, 1)); + } + } + + + static void com_dictmaker(c, n) struct compiling *c; node *n; *************** *** 1073,1079 **** com_push(c, 1); } else ! com_list_constructor(c, CHILD(n, 1)); break; case LBRACE: /* '{' [dictmaker] '}' */ com_addoparg(c, BUILD_MAP, 0); --- 1120,1126 ---- com_push(c, 1); } else ! com_listmaker(c, CHILD(n, 1)); break; case LBRACE: /* '{' [dictmaker] '}' */ com_addoparg(c, BUILD_MAP, 0); From fredrik at pythonware.com Fri Jul 7 14:30:51 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 14:30:51 +0200 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> Message-ID: <020001bfe80f$3b23ab10$0900a8c0@SPIFF> guido wrote: > I propose ustr(x) with the semantics given by Toby. +1 on concept. not sure about the name and the semantics. maybe a better name would be "unistr" (to match "unistr"). or maybe that's backwards? how about "String" (!). (the perfect name is "string", but that appears to be reserved by someone else...) as for the semantics, note that __str__ is allowed to return a unicode string in the current code base ("str" converts it to 8- bit using the default encoding). ustr/unistr/String should pass that one right through: def ustr(s): if type(s) in (type(""), type(u"")): return s s = s.__str__() if type(s) in (type(""), type(u"")): return s raise "__str__ returned wrong type" > Class support (an __ustr__ method, with fallbacks on __str__ > and __unicode__) would also be handy. -0 on this one (__str__ can already return either type, and if the goal is to get rid of both unichr and unistr in the future, we shouldn't add more hooks if we can avoid it. it's easier to remove stuff if you don't add them in the first place ;-) From thomas at xs4all.net Fri Jul 7 14:31:30 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 7 Jul 2000 14:31:30 +0200 Subject: [Python-Dev] Grammar help. In-Reply-To: <20000707140856.G26534@xs4all.nl>; from thomas@xs4all.net on Fri, Jul 07, 2000 at 02:08:56PM +0200 References: <20000707000407.E26534@xs4all.nl> <20000706182256.A15938@ludwig.cnri.reston.va.us> <200007062353.SAA01958@cj20424-a.reston1.va.home.com> <20000707140856.G26534@xs4all.nl> Message-ID: <20000707143130.H26534@xs4all.nl> On Fri, Jul 07, 2000 at 02:08:56PM +0200, Thomas Wouters wrote: > Don't forget to re-make Grammar if you test this patch out. Hm, something went wrong with the diff. Damned context diffs ;) > diff -crN --exclude=CVS src/Grammar/Grammar src-rangemaker/Grammar/Grammar > *** src/Grammar/Grammar Tue Mar 28 18:49:00 2000 > --- src-rangemaker/Grammar/Grammar Fri Jul 7 10:32:19 2000 > *************** > *** 74,80 **** > term: factor (('*'|'/'|'%') factor)* > factor: ('+'|'-'|'~') factor | power > power: atom trailer* ('**' factor)* > ! atom: '(' [testlist] ')' | '[' [testlist] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ > lambdef: 'lambda' [varargslist] ':' test > trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME > subscriptlist: subscript (',' subscript)* [','] > --- 74,80 ---- > term: factor (('*'|'/'|'%') factor)* > factor: ('+'|'-'|'~') factor | power > power: atom trailer* ('**' factor)* > ! atom: '(' [testlist] ')' | '[' [listmaker] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ > lambdef: 'lambda' [varargslist] ':' test > trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME > subscriptlist: subscript (',' subscript)* [','] If you want to try this patch out, you should add listmaker: rangetail | test ( rangetail | (',' test)* [',']) rangetail: ':' test [':' test] somewhere in Grammar/Grammar. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From pf at artcom-gmbh.de Fri Jul 7 14:26:38 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Fri, 7 Jul 2000 14:26:38 +0200 (MEST) Subject: [Python-Dev] webbrowser module In-Reply-To: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at "Jul 6, 2000 11:40:33 pm" Message-ID: Hi, Fred L. Drake, Jr.: > Ok, I've checked in the documentation for the webbrowser > documentation. The implementation can go in as soon as SF clears a > bogus read lock (support request files 6.5 hours ago). [...] May I suggest the patch below? It add's support for the Linux KDE file manager KFM (aka Konquerer) as the default web browser. This esspecially makes sense on smaller Linux machines, where users don't want to spend the huge amount of memory needed by a browser bloated to no avail with trashy stuff like Java / Javascript .... Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) ---- 8< ---- 8< ---- cut here ---- 8< ---- schnipp ---- 8< ---- schnapp ---- *** webbrowser.py.orig Fri Jul 7 10:28:05 2000 --- webbrowser.py Fri Jul 7 14:08:32 2000 *************** *** 1,4 **** ! """Remote-control interfaces to some browsers.""" import os import sys --- 1,4 ---- ! """webbrowser -- Remote-control interfaces to some browsers.""" import os import sys *************** *** 30,35 **** --- 30,36 ---- L[1] = L[0]() return L[1] + # Please note: the following definition hides a builtin function. def open(url, new=0): get().open(url, new) *************** *** 56,61 **** --- 57,63 ---- if os.environ.get("DISPLAY"): _browsers.extend([ ("netscape", "netscape %s >/dev/null &"), + ("kfmclient", "kfmclient openURL %s"), ("mosaic", "mosaic %s >/dev/null &"), ]) _browsers.extend([ *************** *** 102,107 **** --- 104,131 ---- register("netscape", Netscape) + class Konquerer: + """see http://developer.kde.org/documentation/other/kfmclient.html""" + def _remote(self, action): + cmd = "kfmclient %s >/dev/null 2>&1" % action + rc = os.system(cmd) + if rc: + import time + os.system("kfm -d &") + time.sleep(PROCESS_CREATION_DELAY) + rc = os.system(cmd) + return not rc + + def open(self, url, new=1): + # XXX currently I know no way to prevent KFM from opening a new win. + self.open_new(url) + + def open_new(self, url): + self._remote("openURL %s" % url) + + register("kfm", Konquerer) + + class Grail: # There should be a way to maintain a connection to Grail, but the # Grail remote control protocol doesn't really allow that at this *************** *** 167,172 **** --- 191,208 ---- DEFAULT_BROWSER = "windows-default" elif not os.environ.get("DISPLAY"): DEFAULT_BROWSER = "command-line-browser" + elif sys.platform == "linux2": + def small_ram(): + """returns True on machines with less than 128 MB Ram""" + import string, __builtin__ + memtotal = long(string.split( + __builtin__.open("/proc/meminfo").readlines()[1])[1]) + return memtotal < 128L * 1024 * 1024 # less than 128 MB + + if small_ram(): + DEFAULT_BROWSER = "kfm" + else: + DEFAULT_BROWSER = "netscape" else: DEFAULT_BROWSER = "netscape" From esr at thyrsus.com Fri Jul 7 15:03:22 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 7 Jul 2000 09:03:22 -0400 Subject: [Python-Dev] webbrowser module In-Reply-To: ; from pf@artcom-gmbh.de on Fri, Jul 07, 2000 at 02:26:38PM +0200 References: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> Message-ID: <20000707090322.A29880@thyrsus.com> Peter Funk : > May I suggest the patch below? It add's support for the > Linux KDE file manager KFM (aka Konquerer) as the default > web browser. This esspecially makes sense on smaller Linux > machines, where users don't want to spend the huge amount of > memory needed by a browser bloated to no avail with trashy > stuff like Java / Javascript .... Good patch! -- Eric S. Raymond The American Republic will endure, until politicians realize they can bribe the people with their own money. -- Alexis de Tocqueville From mal at lemburg.com Fri Jul 7 14:56:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 14:56:37 +0200 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <020001bfe80f$3b23ab10$0900a8c0@SPIFF> Message-ID: <3965D385.68D97C31@lemburg.com> Fredrik Lundh wrote: > > guido wrote: > > I propose ustr(x) with the semantics given by Toby. > > +1 on concept. > > not sure about the name and the semantics. Uhm, what's left then ;-) ? > maybe a better name would be "unistr" (to match "unistr"). > or maybe that's backwards? > > how about "String" (!). > > (the perfect name is "string", but that appears to be reserved > by someone else...) > > as for the semantics, note that __str__ is allowed to return a > unicode string in the current code base ("str" converts it to 8- > bit using the default encoding). ustr/unistr/String should pass > that one right through: > > def ustr(s): > if type(s) in (type(""), type(u"")): > return s > s = s.__str__() > if type(s) in (type(""), type(u"")): > return s > raise "__str__ returned wrong type" > > > Class support (an __ustr__ method, with fallbacks on __str__ > > and __unicode__) would also be handy. > > -0 on this one (__str__ can already return either type, and if the > goal is to get rid of both unichr and unistr in the future, we shouldn't > add more hooks if we can avoid it. it's easier to remove stuff if you > don't add them in the first place ;-) Agreed. I'm just adding coercion support for instances using that technique: instance defining __str__ can return Unicode objects which will then be used by the implementation whereever coercion to Unicode takes place. I'll add a similar hook to unicode(). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From alexwg at MIT.EDU Fri Jul 7 15:31:52 2000 From: alexwg at MIT.EDU (Alexander D Wissner-Gross) Date: Fri, 7 Jul 2000 09:31:52 -0400 (EDT) Subject: [Python-Dev] Re: [Patches] [Patch #100752] Make atoi work for negative bases, a useful generalization In-Reply-To: <14693.19707.553522.523595@beluga.mojam.com> Message-ID: Skip, Built-in support for negative bases would encourage further use of Python in math research (specifically, representation theory). For reference, Mathematica recently added support for negative base conversions. Negative bases allow the unique representation of both positive and negative integers without use of a sign. For example, "-3" in decimal equals, in base -2, "1101" (-3 = 1*(-2)^3 + 1*(-2)^2 + 0*(-2)^1 + 1*(-2)^0). It has been suggested that this property makes negative bases a more natural representation for integers than positive bases. There is more detailed information on the subject in The Art of Computer Programming Vol. 2. This functionality is not already in Python, as someone suggested on patches at python.org. Alex From guido at beopen.com Fri Jul 7 16:38:39 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 09:38:39 -0500 Subject: [Python-Dev] Re: [Patches] [Patch #100752] Make atoi work for negative bases, a useful generalization In-Reply-To: Your message of "Fri, 07 Jul 2000 09:31:52 -0400." References: Message-ID: <200007071438.JAA04100@cj20424-a.reston1.va.home.com> > Built-in support for negative bases would encourage further use of Python > in math research (specifically, representation theory). For reference, > Mathematica recently added support for negative base conversions. > > Negative bases allow the unique representation of both positive and > negative integers without use of a sign. For example, "-3" in decimal > equals, in base -2, "1101" (-3 = 1*(-2)^3 + 1*(-2)^2 + 0*(-2)^1 + 1*(-2)^0). > It has been suggested that this property makes negative bases a more natural > representation for integers than positive bases. There is more detailed > information on the subject in The Art of Computer Programming Vol. 2. Only a mathematician could call this "more natural"... For most of us, this is difficult to understand (e.g. the suggestion was made that int(s,x) == -int(s,-x), which isn't true) and there are no practical uses. As most of Python's users lack the sophistication to understand this, I'd rather not introduce this patch -- when I see a negative base somewhere, it's much more likely that it's a bug in the code than an advanced use of negative bases... That's a polite but firm -1. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Fri Jul 7 16:17:34 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 16:17:34 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines References: <20000707094036.AA22C31047C@bireme.oratrix.nl> <3965B6F8.72742A2E@lemburg.com> <20000707120149.6B39631047C@bireme.oratrix.nl> Message-ID: <3965E67E.CE81253D@lemburg.com> Sjoerd Mullender wrote: > > On Fri, Jul 7 2000 "M.-A. Lemburg" wrote: > > > Perhaps you could figure out which defines are needed to > > reenable the missing APIs on IRIX when _XOPEN_SOURCE is > > defined... it would be helpful to help pin-point the > > weak spots w/r to SUSv2 compatibility. > > It looks like there is no way of doing this. The relevant bits of > code are: > > In time.h (as an example): > #if _SGIAPI && _NO_ANSIMODE > extern time_t altzone; > #endif /* _SGIAPI */ > > So _SGIAPI and _NO_ANSIMODE should both be defined and != 0. > The definition of _SGIAPI is > #define _SGIAPI ((defined(_SGI_SOURCE) && \ > _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5) || \ > (_ANSIMODE && _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5)) > So, if _NO_XOPEN5 is 0, _SGIAPI is 0. The definition of _NO_XOPEN5 is > #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || \ > (defined(_XOPEN_SOURCE) && \ > (_XOPEN_SOURCE+0 < 500))) > So _NO_XOPEN5 is 0 since _XOPEN_SOURCE is defined and >= 500. Hmm, would that mean that altzone is not part of SUSv2 (in that case we'd have to change Python) ? Or are the SGI header files wrong here (which means we'd have to work around those bugs) ? > All of this on IRIX 6.5.2. I can't check other versions of IRIX. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Fri Jul 7 16:40:40 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 16:40:40 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines References: <20000707094036.AA22C31047C@bireme.oratrix.nl> <3965B6F8.72742A2E@lemburg.com> <20000707120149.6B39631047C@bireme.oratrix.nl> <3965E67E.CE81253D@lemburg.com> Message-ID: <02d201bfe821$52c4b090$0900a8c0@SPIFF> mal wrote: > Hmm, would that mean that altzone is not part of SUSv2 as far as I can tell, altzone is not part of SUSv2. the time.h file declares the following variables: extern int daylight; extern long int timezone; extern char *tzname[]; does anyone know what standard (if any) altzone is defined by? From sjoerd at oratrix.nl Fri Jul 7 17:05:53 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Fri, 07 Jul 2000 17:05:53 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines In-Reply-To: Your message of Fri, 07 Jul 2000 16:40:40 +0200. <02d201bfe821$52c4b090$0900a8c0@SPIFF> References: <20000707094036.AA22C31047C@bireme.oratrix.nl> <3965B6F8.72742A2E@lemburg.com> <20000707120149.6B39631047C@bireme.oratrix.nl> <3965E67E.CE81253D@lemburg.com> <02d201bfe821$52c4b090$0900a8c0@SPIFF> Message-ID: <20000707150554.37E2031047C@bireme.oratrix.nl> One of the big problems with configure is that the defines that are used to test features are not necessarily the same as the defines that are used when those features are actually used in the program being configured. Python's configure script tests for altzone, and if the defines in effect there were the same as the ones in effect during compilation, altzone would not have been found and the compilation would have gone smoothly. I don't have a solution for this problem, but a problem it is. -- Sjoerd Mullender From fdrake at beopen.com Fri Jul 7 18:22:16 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 12:22:16 -0400 (EDT) Subject: [Python-Dev] _sre.c's compiled size In-Reply-To: <20000707135641.F26534@xs4all.nl> References: <20000707135641.F26534@xs4all.nl> Message-ID: <14694.952.281470.320804@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > I've attached a teensy patch that allows '-f' flags to be used in > Setup files, to be able to easily switch between the two. This is checked in; thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jul 7 18:40:26 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 12:40:26 -0400 (EDT) Subject: [Python-Dev] webbrowser module In-Reply-To: References: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> Message-ID: <14694.2042.320980.231242@cj42289-a.reston1.va.home.com> Peter Funk writes: > May I suggest the patch below? It add's support for the > Linux KDE file manager KFM (aka Konquerer) as the default > web browser. This esspecially makes sense on smaller Linux Peter, Thanks for the Konquerer class! I'll add that. What I'm not sure about is using it as a default value if the use isn't running KDE. I just tried to play with kfm while Gnome was running, and it tried to load docklets and the like, which wasn't useful since the KDE panel wasn't running. (On the other hand, kfm *did* start up with the -d option, and kfmclient worked.) But that means that kfm was putting icons on my "desktop", and that's something I definately don't want. So I'm hesitant. Is there a reasonably reliable way to determine if the user is running KDE, and only make this the default in that case? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Fri Jul 7 18:53:19 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 7 Jul 2000 11:53:19 -0500 (CDT) Subject: [Python-Dev] webbrowser module In-Reply-To: <14694.2042.320980.231242@cj42289-a.reston1.va.home.com> References: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> <14694.2042.320980.231242@cj42289-a.reston1.va.home.com> Message-ID: <14694.2815.308486.875411@beluga.mojam.com> Fred> What I'm not sure about is using it as a default value if the use Fred> isn't running KDE. Fred, I'm running kde. From bash I see an environment variable named KDEDIR whose value is "/usr". Would that be a possible extra test to assure that kde is running before deciding to launch kfm? Skip From fdrake at beopen.com Fri Jul 7 19:05:09 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 13:05:09 -0400 (EDT) Subject: [Python-Dev] webbrowser module In-Reply-To: <14694.2815.308486.875411@beluga.mojam.com> References: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> <14694.2042.320980.231242@cj42289-a.reston1.va.home.com> <14694.2815.308486.875411@beluga.mojam.com> Message-ID: <14694.3525.845782.579413@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > I'm running kde. From bash I see an environment variable named KDEDIR whose > value is "/usr". Would that be a possible extra test to assure that kde is > running before deciding to launch kfm? Sounds good! How about this for the non-MacOS portion of the default-browser determination: DEFAULT_BROWSER = "command-line" if sys.platform[:3] == "win": del _browsers["kfm"] register("windows-default", WindowsDefault) DEFAULT_BROWSER = "windows-default" elif os.environ.get("DISPLAY"): if os.environ.get("KDEDIR"): DEFAULT_BROWSER = "kfm" elif _iscommand("netscape"): DEFAULT_BROWSER = "netscape" -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pf at artcom-gmbh.de Fri Jul 7 20:02:41 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Fri, 7 Jul 2000 20:02:41 +0200 (MEST) Subject: [Python-Dev] webbrowser module In-Reply-To: <14694.3525.845782.579413@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at "Jul 7, 2000 1: 5: 9 pm" Message-ID: Hi, Fred L. Drake, Jr. : > > Skip Montanaro writes: > > I'm running kde. From bash I see an environment variable named KDEDIR whose > > value is "/usr". Would that be a possible extra test to assure that kde is > > running before deciding to launch kfm? Clever idea, Skip! This will also work on SuSE Linux, where I have KDEDIR=/opt/kde > Sounds good! How about this for the non-MacOS portion of the > default-browser determination: > > DEFAULT_BROWSER = "command-line" > > if sys.platform[:3] == "win": > del _browsers["kfm"] > register("windows-default", WindowsDefault) > DEFAULT_BROWSER = "windows-default" > elif os.environ.get("DISPLAY"): > if os.environ.get("KDEDIR"): > DEFAULT_BROWSER = "kfm" > elif _iscommand("netscape"): > DEFAULT_BROWSER = "netscape" I believe there might be some people using KDE on a luxury computer (like the rolls royce alike that Fred has) and because they don't have to bother about RAM usage, they still may want to use Netscape as their default browser under KDE. I muust admit that Netscape provides more features and nice bookmark handling, although the differences might become smaller with KDE 2.x. That however again will burn more RAM. :-( Testing for available RAM will only work on Linux on the other hand, because most other unices lack '/proc/meminfo'. Using something more portable like the famous 'wc -c /dev/mem' unix tool abuse hack will not work due to the obvious lack of read permissions on /dev/mem for simple user processes. Adding the proposed AI (heuristic, hack, rule-of-thumb whatever you want to call it) to choose the default browser dependent on the amount of installed RAM is quite unpythonic, or what? However it is so simple, since Linux and Python are really powerful here: def small_ram(): """returns True on machines with less than 128 MB Ram""" import string, __builtin__ memtotal = long(string.split( __builtin__.open("/proc/meminfo").readlines()[1])[1]) return memtotal < 128L * 1024 * 1024 # less than 128 MB May be the best solution would be to test if any of the _browsers, which support a remote protocol is already running and only fire up a new browser, if no browser process can be identified. This however will break the current class hierarchy. So this should be delayed until Python 2.1? Finally: I like your proposed solution. Regards, Peter From paul at prescod.net Fri Jul 7 20:08:47 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 07 Jul 2000 13:08:47 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> Message-ID: <39661CAF.9252D734@prescod.net> Guido van Rossum wrote: > > ... > > For strings there is no compact notation like "+0.0" if you want to > convert to string or Unicode -- adding "" might work in Perl, but not > in Python. Actually, these days, foo+"" works in a LOT of languages. Perl, Java and JavaScript for sure. C++, depending on the type. Python's strictness about this issue has never caught a bug for me. It has only caused errors. Okay, some newbie may think that "5"+"5"=="10". But they could also expect [5]+[5]==[10]. There are limits to the extent that we can protect them from incorrect mental models. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From akuchlin at mems-exchange.org Fri Jul 7 20:15:05 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 07 Jul 2000 14:15:05 -0400 Subject: [Python-Dev] c.l.py.a revival Message-ID: While waiting for word of a 2.0b1 release, what about continuing to attempt to revive c.l.python.announce? Last I remember, it was suggested to add Guido as a moderator so he could in turn delegate handling of messages to someone else. Was any progress ever made with this? --amk From fdrake at beopen.com Fri Jul 7 20:19:16 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 14:19:16 -0400 (EDT) Subject: [Python-Dev] c.l.py.a revival In-Reply-To: References: Message-ID: <14694.7972.264112.121727@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > While waiting for word of a 2.0b1 release, what about continuing to > attempt to revive c.l.python.announce? Last I remember, it was > suggested to add Guido as a moderator so he could in turn delegate > handling of messages to someone else. Was any progress ever made with I think the problem was that the current moderators had to add Guido as a moderator; once that's done Guido can delegate as desired. Can you prod Markus for us on this one? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Fri Jul 7 20:20:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 20:20:53 +0200 Subject: [Python-Dev] c.l.py.a revival References: Message-ID: <39661F85.B87EDB2E@lemburg.com> Andrew Kuchling wrote: > > While waiting for word of a 2.0b1 release, what about continuing to > attempt to revive c.l.python.announce? Last I remember, it was > suggested to add Guido as a moderator so he could in turn delegate > handling of messages to someone else. Was any progress ever made with > this? How about reviving the announcement mailing list first -- messages posted to that list result in an error return mail and don't show up anywhere. If that works, I'd suggest adding support for forwarding the messages to the moderated list via the hack that was described last time we discussed this. I think Barry is already working on this one, right ;-) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy at beopen.com Fri Jul 7 20:23:41 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 14:23:41 -0400 (EDT) Subject: [Python-Dev] c.l.py.a revival In-Reply-To: References: Message-ID: <14694.8237.260813.999821@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> While waiting for word of a 2.0b1 release, what about AMK> continuing to attempt to revive c.l.python.announce? Last I AMK> remember, it was suggested to add Guido as a moderator so he AMK> could in turn delegate handling of messages to someone else. AMK> Was any progress ever made with this? I believe the desired solution was actually to use the python-announce mailing list to moderate the newsgroup. The current moderator sketched the desired setup, which involved setting up the mailing list moderation software to add the headers that indicated it was approved by the newsgroup moderators. I believe this is still on Barry's plate -- along with too many other things for me to count, but at least not bibimbap or doji bulgogi. Jeremy From fredrik at pythonware.com Fri Jul 7 21:05:01 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 21:05:01 +0200 Subject: [Python-Dev] where did httplib.HTTPS go? Message-ID: <000701bfe846$41b8ad40$0900a8c0@SPIFF> [fredrik at brain src]$ ./python Python 2.0b1 (#4, Jul 7 2000, 12:23:15) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 >>> import httplib >>> httplib.HTTPS Traceback (most recent call last): File "", line 1, in ? AttributeError: HTTPS urllib and the test code in httplib.py uses HTTPS, but I cannot find it. and neither can grep: Lib/httplib.py:HTTPS_PORT = 443 Lib/httplib.py:class HTTPSConnection(HTTPConnection): Lib/httplib.py: default_port = HTTPS_PORT Lib/httplib.py: hs = HTTPS() Lib/urllib.py: """Use HTTPS protocol.""" Lib/urllib.py: h = httplib.HTTPS(host, 0, where is it? what am I missing? From jeremy at beopen.com Fri Jul 7 21:13:13 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 15:13:13 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <000701bfe846$41b8ad40$0900a8c0@SPIFF> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> Message-ID: <14694.11209.999476.330370@bitdiddle.concentric.net> Looks like Greg didn't add it before he checked in the new implementation. I thought he was going to. I also thought he was going to change the indentation to four spaces. Is that a standard for Python code in the library, or am I just being fussy? Jeremy From fredrik at pythonware.com Fri Jul 7 21:13:27 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 21:13:27 +0200 Subject: [Python-Dev] bogus LANG setting results in "import site failed" message Message-ID: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> [fredrik at brain src]$ export LANG=foobar [fredrik at brain src]$ ./python 'import site' failed; use -v for traceback Python 2.0b1 (#4, Jul 7 2000, 12:23:15) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> that "import site" is a bit disturbing. maybe the locale-checking code should handle this case a bit more gracefully? (like, say, printing a more explicit warning message). From fdrake at beopen.com Fri Jul 7 21:14:14 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 15:14:14 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.11209.999476.330370@bitdiddle.concentric.net> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> Message-ID: <14694.11270.542014.447760@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > I also thought he was going to change the indentation to four spaces. > Is that a standard for Python code in the library, or am I just being > fussy? All new code should use four-space indents, but we've never gone through and agressively converted old code. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Fri Jul 7 21:19:45 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 15:19:45 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.11270.542014.447760@cj42289-a.reston1.va.home.com> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <14694.11270.542014.447760@cj42289-a.reston1.va.home.com> Message-ID: <14694.11601.611455.4339@bitdiddle.concentric.net> >>>>> "FLD" == Fred L Drake, writes: FLD> Jeremy Hylton writes: >> I also thought he was going to change the indentation to four >> spaces. Is that a standard for Python code in the library, or am >> I just being fussy? FLD> All new code should use four-space indents, but we've never FLD> gone through and agressively converted old code. Why is it that a reply from you in particular doesn't make me feel confident that I am not being fussy? :-) Jeremy From fdrake at beopen.com Fri Jul 7 21:19:39 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 15:19:39 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.11601.611455.4339@bitdiddle.concentric.net> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <14694.11270.542014.447760@cj42289-a.reston1.va.home.com> <14694.11601.611455.4339@bitdiddle.concentric.net> Message-ID: <14694.11595.370101.739327@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > Why is it that a reply from you in particular doesn't make me feel > confident that I am not being fussy? :-) I didn't say you *weren't* being fussy. ;) I will say that you *should* be fusy, which may be about what you expect. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Fri Jul 7 21:33:55 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 7 Jul 2000 15:33:55 -0400 (EDT) Subject: [Python-Dev] c.l.py.a revival References: <14694.8237.260813.999821@bitdiddle.concentric.net> Message-ID: <14694.12451.606319.130358@anthem.concentric.net> Yup, it's still on my plate and I'll try to spend some time on it this weekend. From mal at lemburg.com Fri Jul 7 21:37:35 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 21:37:35 +0200 Subject: [Python-Dev] bogus LANG setting results in "import site failed" message References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> Message-ID: <3966317F.4A39E6A2@lemburg.com> Fredrik Lundh wrote: > > [fredrik at brain src]$ export LANG=foobar > [fredrik at brain src]$ ./python > 'import site' failed; use -v for traceback > Python 2.0b1 (#4, Jul 7 2000, 12:23:15) [GCC egcs-2.91.66 19990314/Linux > (egcs-1.1.2 release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> > > that "import site" is a bit disturbing. maybe the locale-checking > code should handle this case a bit more gracefully? > > (like, say, printing a more explicit warning message). Here's the patch (Skip's locking the Lib dir ... grrr ;-): --- CVS-Python/Lib/site.py Wed Jun 28 17:30:57 2000 +++ Python+Unicode/Lib/site.py Fri Jul 7 21:30:54 2000 @@ -124,11 +124,16 @@ del exit # encoding used by the default locale of this system. If the default # encoding cannot be determined or is unknown, it defaults to 'ascii'. # def locale_aware_defaultencoding(): import locale - code, encoding = locale.get_default() + try: + code, encoding = locale.get_default() + except ValueError, why: + sys.stderr.write('Error setting default encoding (%s), using ASCII.\n' + % why) + encoding = None if encoding is None: encoding = 'ascii' try: sys.setdefaultencoding(encoding) except LookupError: -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Fri Jul 7 21:44:49 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 12:44:49 -0700 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.11209.999476.330370@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jul 07, 2000 at 03:13:13PM -0400 References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> Message-ID: <20000707124449.E29590@lyra.org> On Fri, Jul 07, 2000 at 03:13:13PM -0400, Jeremy Hylton wrote: > Looks like Greg didn't add it before he checked in the new > implementation. I thought he was going to. Yah, my fault. I'll get the changes back in there later tonite. > I also thought he was going to change the indentation to four spaces. > Is that a standard for Python code in the library, or am I just being > fussy? I think you're being fussy, but I can change this. I'll do a separate commit that just changes white space (and possibly reflow some comments). Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Fri Jul 7 21:46:07 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 12:46:07 -0700 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <000701bfe846$41b8ad40$0900a8c0@SPIFF>; from fredrik@pythonware.com on Fri, Jul 07, 2000 at 09:05:01PM +0200 References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> Message-ID: <20000707124606.F29590@lyra.org> On Fri, Jul 07, 2000 at 09:05:01PM +0200, Fredrik Lundh wrote: > [fredrik at brain src]$ ./python > Python 2.0b1 (#4, Jul 7 2000, 12:23:15) [GCC egcs-2.91.66 19990314/Linux > (egcs-1.1.2 release)] on linux2 > >>> import httplib > >>> httplib.HTTPS > Traceback (most recent call last): > File "", line 1, in ? > AttributeError: HTTPS > > urllib and the test code in httplib.py uses HTTPS, > but I cannot find it. and neither can grep: > > Lib/httplib.py:HTTPS_PORT = 443 > Lib/httplib.py:class HTTPSConnection(HTTPConnection): > Lib/httplib.py: default_port = HTTPS_PORT > Lib/httplib.py: hs = HTTPS() > Lib/urllib.py: """Use HTTPS protocol.""" > Lib/urllib.py: h = httplib.HTTPS(host, 0, > > where is it? what am I missing? Oh... one more comment: I'll be updating urllib.py at some point to *not* use HTTPS. It should be using HTTPSConnection instead. (and HTTPConnection rather than HTTP) ... dunno if other libraries use httplib, but I'll look and update those, too. Maybe in the Demo/ area. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Fri Jul 7 21:47:50 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 15:47:50 -0400 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <20000707124449.E29590@lyra.org> Message-ID: [Jeremy Hylton] > I also thought he was going to change the indentation to four spaces. > Is that a standard for Python code in the library, or am I just being > fussy? It is a std for distributed Python code, and so deciding whether it's fussy is irrelevant. [Greg Stein] > I think you're being fussy, Irrelevant. > but I can change this. Almost the right answer. > I'll do a separate commit that just changes white space (and possibly > reflow some comments). Bingo! life-is-so-much-easier-when-you-don't-think-too-much-ly y'rs - tim From fredrik at pythonware.com Fri Jul 7 21:48:43 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 21:48:43 +0200 Subject: [Python-Dev] repository locks References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> <3966317F.4A39E6A2@lemburg.com> Message-ID: <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> > Here's the patch (Skip's locking the Lib dir ... grrr ;-): tonight's stupid question: What's causing all these stale locks? I'm a totally clueless CVS user, and I've managed to check at least 114 things into the repository without leaving any locks behind me. Is it just sheer luck, or is there some flaw in CVS waiting for me to stumble upon? From tim_one at email.msn.com Fri Jul 7 21:55:39 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 15:55:39 -0400 Subject: [Python-Dev] repository locks In-Reply-To: <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> Message-ID: [/F] > What's causing all these stale locks? Best I can tell, Skip. > I'm a totally clueless CVS user, You don't want to fight me on that one . > and I've managed to check at least 114 things into the repository > without leaving any locks behind me. I think I've lucked out too. > Is it just sheer luck, or is there some flaw in CVS waiting > for me to stumble upon? There are many links in the chain from one of our machines to CVS on SourceForge. My bet is that if it's working for you, it will continue to work; and that we'll continue to see locks left behind by Skip until he manages to replace the link in his chain that's damaged. Also betting there's a 50-50 chance we'll never know which link it was. it's-software-it-sucks-it's-par-for-the-course-ly y'rs - tim From guido at beopen.com Fri Jul 7 23:02:16 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:02:16 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: Your message of "Fri, 07 Jul 2000 13:08:47 EST." <39661CAF.9252D734@prescod.net> References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <39661CAF.9252D734@prescod.net> Message-ID: <200007072102.QAA05114@cj20424-a.reston1.va.home.com> [me] > > For strings there is no compact notation like "+0.0" if you want to > > convert to string or Unicode -- adding "" might work in Perl, but not > > in Python. [PaulPrescod] > Actually, these days, foo+"" works in a LOT of languages. Perl, Java and > JavaScript for sure. Really? Does 3+"" really convert the 3 to a string in Java? > C++, depending on the type. Python's strictness > about this issue has never caught a bug for me. It has only caused > errors. Are you sure? This is the kind of error where you immediately see what's wrong and move on to the next bug. > Okay, some newbie may think that "5"+"5"=="10". But they could > also expect [5]+[5]==[10]. There are limits to the extent that we can > protect them from incorrect mental models. I won't argue with you there :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Fri Jul 7 23:02:49 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:02:49 -0500 Subject: [Python-Dev] c.l.py.a revival In-Reply-To: Your message of "Fri, 07 Jul 2000 14:15:05 -0400." References: Message-ID: <200007072102.QAA05127@cj20424-a.reston1.va.home.com> > While waiting for word of a 2.0b1 release, what about continuing to > attempt to revive c.l.python.announce? Last I remember, it was > suggested to add Guido as a moderator so he could in turn delegate > handling of messages to someone else. Was any progress ever made with > this? Not that I know of -- it's as dead as ever. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein at lyra.org Fri Jul 7 22:08:15 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 13:08:15 -0700 Subject: [Python-Dev] CVS: python/dist/src/Objects longobject.c,1.60,1.61 In-Reply-To: <200007071553.IAA06685@slayer.i.sourceforge.net>; from tim_one@users.sourceforge.net on Fri, Jul 07, 2000 at 08:53:31AM -0700 References: <200007071553.IAA06685@slayer.i.sourceforge.net> Message-ID: <20000707130815.I29590@lyra.org> On Fri, Jul 07, 2000 at 08:53:31AM -0700, Tim Peters wrote: >... > --- 1693,1709 ---- > sizeof(PyLongObject) - sizeof(digit), > sizeof(digit), > ! (destructor)long_dealloc, /*tp_dealloc*/ > ! 0, /*tp_print*/ > ! 0, /*tp_getattr*/ > ! 0, /*tp_setattr*/ > ! (int (*) (PyObject *, PyObject *)) > ! (cmpfunc)long_compare, /*tp_compare*/ > ! (reprfunc)long_repr, /*tp_repr*/ > ! &long_as_number, /*tp_as_number*/ > ! 0, /*tp_as_sequence*/ > ! 0, /*tp_as_mapping*/ > ! (long (*) (PyObject *)) > ! (hashfunc)long_hash, /*tp_hash*/ > ! 0, /*tp_call*/ > ! (reprfunc)long_str, /*tp_str*/ > }; What is with those double casts for tp_compare and tp_hash? The prototypes match cmpfunc and hashfunc, so I think they ought to just be dropped. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Fri Jul 7 23:11:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:11:29 -0500 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: Your message of "Fri, 07 Jul 2000 12:44:49 MST." <20000707124449.E29590@lyra.org> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <20000707124449.E29590@lyra.org> Message-ID: <200007072111.QAA05197@cj20424-a.reston1.va.home.com> > > I also thought he was going to change the indentation to four spaces. > > Is that a standard for Python code in the library, or am I just being > > fussy? > > I think you're being fussy, but I can change this. I'll do a separate commit > that just changes white space (and possibly reflow some comments). To my eyes, 2-space indents are unreadable. Please make it 4 spaces, like all other new code. There's no excuse for arguing about whitespace in Python. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Fri Jul 7 22:13:03 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 16:13:03 -0400 (EDT) Subject: [Python-Dev] repository locks In-Reply-To: <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> <3966317F.4A39E6A2@lemburg.com> <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> Message-ID: <14694.14799.389933.276211@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > I'm a totally clueless CVS user, and I've managed to check > at least 114 things into the repository without leaving any > locks behind me. The checkins aren't causing the problem -- these are read locks on the directories. > Is it just sheer luck, or is there some flaw in CVS waiting > for me to stumble upon? I think there's probably a bug in the CVS server, but not sure, and I haven't dug into the CVS code to figure it out. It looks like some operation is locking the directory (update, or a diff), and then the connection to the client disappears, and the server exits without cleaning up the lock. As long as we're reading from the repository, that doesn't matter -- the problem is when we go to write to the repository, the CVS server talking to us still thinks there's a reader, so we're denied access. Another possibility is that there's a stuck CVS server (with a dead connection) holding the lock, and it hasn't exited at all. But that's less likely. The problem is likely because we're a very active project with lots of simulataneous repository access on an overloaded service. I've noticed that the other services at SourceForge (message forums, support managers, etc.) have been really slow the past 36 hours as well. Clearly, we van blame it all on Skip. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Fri Jul 7 22:16:08 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 16:16:08 -0400 Subject: [Python-Dev] CVS: python/dist/src/Objects longobject.c,1.60,1.61 In-Reply-To: <20000707130815.I29590@lyra.org> Message-ID: [Greg Stein] > >... > > --- 1693,1709 ---- > > sizeof(PyLongObject) - sizeof(digit), > > sizeof(digit), > > ! (destructor)long_dealloc, /*tp_dealloc*/ > > ! 0, /*tp_print*/ > > ! 0, /*tp_getattr*/ > > ! 0, /*tp_setattr*/ > > ! (int (*) (PyObject *, PyObject *)) > > ! (cmpfunc)long_compare, /*tp_compare*/ > > ! (reprfunc)long_repr, /*tp_repr*/ > > ! &long_as_number, /*tp_as_number*/ > > ! 0, /*tp_as_sequence*/ > > ! 0, /*tp_as_mapping*/ > > ! (long (*) (PyObject *)) > > ! (hashfunc)long_hash, /*tp_hash*/ > > ! 0, /*tp_call*/ > > ! (reprfunc)long_str, /*tp_str*/ > > }; > > What is with those double casts for tp_compare and tp_hash? The > prototypes match cmpfunc and hashfunc, so I think they ought to > just be dropped. The patch in this area just normalized the whitespace for easier reading (although thanks to stinking hard tab characters, it may not *look* that way!) -- the double casts were there before. I'll be making more changes to the file "soon", and will look into what you suggest -- suspect you're right that it's just confusingly redundant. From guido at beopen.com Fri Jul 7 23:16:26 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:16:26 -0500 Subject: [Python-Dev] repository locks In-Reply-To: Your message of "Fri, 07 Jul 2000 21:48:43 +0200." <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> <3966317F.4A39E6A2@lemburg.com> <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> Message-ID: <200007072116.QAA05244@cj20424-a.reston1.va.home.com> > tonight's stupid question: > > What's causing all these stale locks? > > I'm a totally clueless CVS user, and I've managed to check > at least 114 things into the repository without leaving any > locks behind me. > > Is it just sheer luck, or is there some flaw in CVS waiting > for me to stumble upon? These locks are read-locks caused by checkouts that are aborted. Somehow the CVS server doesn't always catch this. I suppose there are also write-locks by commits that could be left around, but you typically don't abort a commit -- but it's common to hit ^C when an update takes a bit long. Not defending CVS (I think it should catch SIGPIPE since that's probably what it's getting since this is done remotely) but just setting the record straight. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From martin at loewis.home.cs.tu-berlin.de Fri Jul 7 22:24:03 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Fri, 7 Jul 2000 22:24:03 +0200 Subject: [Python-Dev] Encodings Message-ID: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> >> This sounds very bad. I thought we agreed that attempting to >> compare (or add) a Unicode string and an 8-bit string containing >> non-ASCII characters (as in your example) should raise an exception. > >Only if the default encoding is ASCII. That is not my understanding of the agreement, and I think the whole idea of a default encoding is a stupid one. I strongly suggest that the behaviour that Ping just explained and that Guido had suggested originally is implemented: Mixing unicode and string objects is only allowed if the string objects are ASCII. Everything else (including a "default" encoding of some kind) is an application issue. Otherwise, you'll just go on and ask questions endlessly how things should behave, and change the interpreter forwards and backwards. The meaning of mixing both kinds of objects is very easy to explain, and also allows for efficient implementation - which you won't get if you have to invoke a character conversion just to get the hash value of a unicode value (!) Regards, Martin From jeremy at beopen.com Fri Jul 7 22:31:35 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 16:31:35 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <200007072111.QAA05197@cj20424-a.reston1.va.home.com> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <20000707124449.E29590@lyra.org> <200007072111.QAA05197@cj20424-a.reston1.va.home.com> Message-ID: <14694.15911.109077.944657@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> To my eyes, 2-space indents are unreadable. Please make it 4 GvR> spaces, like all other new code. There's no excuse for arguing GvR> about whitespace in Python. :-) imputil.py also needs to be fixed. Jeremy From gstein at lyra.org Fri Jul 7 22:39:15 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 13:39:15 -0700 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.15911.109077.944657@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jul 07, 2000 at 04:31:35PM -0400 References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <20000707124449.E29590@lyra.org> <200007072111.QAA05197@cj20424-a.reston1.va.home.com> <14694.15911.109077.944657@bitdiddle.concentric.net> Message-ID: <20000707133915.L29590@lyra.org> On Fri, Jul 07, 2000 at 04:31:35PM -0400, Jeremy Hylton wrote: > >>>>> "GvR" == Guido van Rossum writes: > > GvR> To my eyes, 2-space indents are unreadable. Please make it 4 > GvR> spaces, like all other new code. There's no excuse for arguing > GvR> about whitespace in Python. :-) > > imputil.py also needs to be fixed. Damn. I just can't win! ;-) -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Fri Jul 7 22:39:00 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 16:39:00 -0400 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: <200007072102.QAA05114@cj20424-a.reston1.va.home.com> Message-ID: [Guido] >>> For strings there is no compact notation like "+0.0" if you want to >>> convert to string or Unicode -- adding "" might work in Perl, but not >>> in Python. BTW, "+0.0" is not a correct way to "boundedly coerce" to float under 754 arithmetic; "*1.0" is safer (the former does not always preserve the sign bit of a float zero correctly, but the latter does). [Paul Prescod] >> Actually, these days, foo+"" works in a LOT of languages. Perl, Java and >> JavaScript for sure. [Guido] > Really? Does 3+"" really convert the 3 to a string in Java? I don't remember about that specifically, but believe ""+3 does. OTOH, in *Perl* 3+"" converts "" to the *number* 0 and leaves 3 alone. >> Python's strictness about this issue has never caught a bug for me. It >> has only caused errors. > Are you sure? This is the kind of error where you immediately see > what's wrong and move on to the next bug. It's certainly caught errors for me, and especially when introducing Perl programmers to Python, where "they expect" string+number to convert the string to a number, apparently the opposite of the arbitrary choice Paul prefers. It's ambiguous as hell -- screw it. From bwarsaw at beopen.com Fri Jul 7 22:52:50 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 7 Jul 2000 16:52:50 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? References: <20000707124449.E29590@lyra.org> Message-ID: <14694.17186.868952.214837@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: >> I'll do a separate commit that just changes white space (and >> possibly reflow some comments). TP> Bingo! TP> life-is-so-much-easier-when-you-don't-think-too-much-ly TP> y'rs - tim Oh, and while you're at it, please untabify the file. I don't know if your module has tabs in it, but if so please convert all tabs to spaces. -Barry From pingster at ilm.com Fri Jul 7 22:50:32 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 7 Jul 2000 13:50:32 -0700 (PDT) Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: Message-ID: On Fri, 7 Jul 2000, Tim Peters wrote: > > Are you sure? This is the kind of error where you immediately see > > what's wrong and move on to the next bug. > > It's certainly caught errors for me, and especially when introducing Perl > programmers to Python, where "they expect" string+number to convert the > string to a number, apparently the opposite of the arbitrary choice Paul > prefers. It's not arbitrary -- the decision is made according to the type of the *operator* rather than the type of the operands. anything + anything returns a number anything . anything returns a string So "34"+0 converts to a number and 34."" converts to a string (i've seen both idioms fairly often). Anyway, i still agree that it's best to avoid automatic coercion between numbers and strings -- since it's now very easy to say int("3") as opposed to import string; string.atoi("3"), there's really no excuse for not being explicit. -- ?!ng "Things are more like they are now than they ever were before." -- Dwight D. Eisenhower From martin at loewis.home.cs.tu-berlin.de Fri Jul 7 22:53:37 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Fri, 7 Jul 2000 22:53:37 +0200 Subject: [Python-Dev] Unicode experience Message-ID: <200007072053.WAA02470@loewis.home.cs.tu-berlin.de> > Really? Does 3+"" really convert the 3 to a string in Java? Yes. It is one of my favorite Java features... If a binary + has one argument of type java.lang.String, then the other object is coerced to string as well (unless the other operand is also a string), using the following procedure: If it is a primitive type, an instance of the appopriate helper is created, in this case java.lang.Integer, so we only have java.lang.Object specializations now (*). Then, .toString() is invoked for the object, and the strings are concatenated. This allows to write things like System.out.println("Name:"+name" Age:"+age); so they did not have to copy the printf(3C) family of function, nor to introduce operator overloading for iostream-style output. Teaching this stuff to students, it turns out that there are two major sources of confusion: a) System.out.println("abc"+3+3) prints "abc33", whereas System.out.println(3+3+"abc") prints "6abc", so the binary + is not commutative. b) Both System.out.println("result "+myobj) and System.out.println(myobj) work, but for different reasons. In the first case, it works because of the magic binary '+'. In the second case, it works because println is overloaded for all types, i.e. println(int); println(double); ... println(Object); // invokes println(o.toString()); println(String); // does the real work Regards, Martin (*) Implementations don't have to create those temporaries; the usual as-if rule applies. From guido at beopen.com Fri Jul 7 23:58:56 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:58:56 -0500 Subject: [Python-Dev] Encodings In-Reply-To: Your message of "Fri, 07 Jul 2000 22:24:03 +0200." <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> Message-ID: <200007072158.QAA05483@cj20424-a.reston1.va.home.com> > That is not my understanding of the agreement, and I think the whole > idea of a default encoding is a stupid one. I strongly suggest that > the behaviour that Ping just explained and that Guido had suggested > originally is implemented: Mixing unicode and string objects is only > allowed if the string objects are ASCII. Everything else (including a > "default" encoding of some kind) is an application issue. > > Otherwise, you'll just go on and ask questions endlessly how things > should behave, and change the interpreter forwards and backwards. > > The meaning of mixing both kinds of objects is very easy to explain, > and also allows for efficient implementation - which you won't get if > you have to invoke a character conversion just to get the hash value > of a unicode value (!) I agree with this point. It can be implemented easily by deleting the locale specific guessing from site.py. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein at lyra.org Fri Jul 7 23:05:39 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 14:05:39 -0700 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.17186.868952.214837@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Jul 07, 2000 at 04:52:50PM -0400 References: <20000707124449.E29590@lyra.org> <14694.17186.868952.214837@anthem.concentric.net> Message-ID: <20000707140539.N29590@lyra.org> On Fri, Jul 07, 2000 at 04:52:50PM -0400, Barry A. Warsaw wrote: > >>>>> "TP" == Tim Peters writes: > > >> I'll do a separate commit that just changes white space (and > >> possibly reflow some comments). > > TP> Bingo! > > TP> life-is-so-much-easier-when-you-don't-think-too-much-ly > TP> y'rs - tim > > Oh, and while you're at it, please untabify the file. I don't know if > your module has tabs in it, but if so please convert all tabs to > spaces. I haven't had tabs in my Python files for years :-) (C code is a different matter...) Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Fri Jul 7 23:01:09 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 17:01:09 -0400 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: Message-ID: [Tim] > It's certainly caught errors for me, and especially when > introducing Perl programmers to Python, where "they expect" > string+number to convert the string to a number, apparently > the opposite of the arbitrary choice Paul prefers. [Ping] > It's not arbitrary -- the decision is made according to the > type of the *operator* rather than the type of the operands. > > anything + anything returns a number > anything . anything returns a string Of the languages discussed, this is true only in Perl. The other languages map "+" to the string meaning, so it's arbitrary wrt the universe under discussion. Toss Icon into the Perl camp on this one, btw. Within Perl, that "+" means numeric addition and "." string catenation is also abitrary -- it could just as well have been the other way around. Perl simply aped Awk's arbitrary choice for what "+" means. > So "34"+0 converts to a number and 34."" converts to a string > (i've seen both idioms fairly often). Yes, & about as often as you see explicit str() or int() calls in Python. It's not a question of not needing the functionality, but of how to spell it (both!). > ... > there's really no excuse for not being explicit. i-think-that's-what-i-said-the-first-time-ly y'rs - tim From skip at mojam.com Fri Jul 7 23:07:15 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 7 Jul 2000 16:07:15 -0500 (CDT) Subject: [Python-Dev] repository locks In-Reply-To: <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> <3966317F.4A39E6A2@lemburg.com> <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> Message-ID: <14694.18051.422859.570782@beluga.mojam.com> >> Here's the patch (Skip's locking the Lib dir ... grrr ;-): Fredrik> What's causing all these stale locks? To the best of my knowledge there were two stale locks, both caused by me (*sigh*) as the result of a single failed cvs diff command. The SF folks released the lock on Modules but apparently failed badly to respond to two separate requests (from Barry and me) to release the lock on Lib. Here's what I think happened (I'm not going to test my theory on the Python tree lest I bollux up more directories!). I wanted to create a single context diff containing just the changes I had made to Modules/readline.c and Lib/rlcompleter.py. I changed directory to my Python top-level directory and executed cvs diff -C Modules/readline.c Lib/rlcompleter.py This failed, as did a couple other permutations I tried shortly after that. My theory is that "cvs diff" fiddles things a bit then calls the local diff command. Diff's -C flag is supposed to have a number as an argument (the number of context lines to display - I should have used "-c", which is the same as "-C2" I think). Diff exited with a nonzero status. Either rcsdiff or cvs diff failed to recover properly and we're left with a read lock on both Modules and Lib. On a repository here I just tried: cvs diff -C www/dbserve.py which gave me the following output: cvs diff: Diffing GNIS cvs diff: Diffing conferences cvs diff: Diffing www Index: www/Makefile =================================================================== RCS file: /home/dolphin/projects/www-python/Makefile,v retrieving revision 1.51 diff -Cwww/dbserve.py -r1.51 Makefile cvs diff: invalid context length argument Segmentation fault And it left the following file in my repository: -rw-rw-r-- 1 skip users 0 Jul 7 15:54 #cvs.rfl.dolphin.25030 When I try to check in a changed file to that repository I get: cvs server: [15:57:27] waiting for skip's lock in /home/dolphin/projects/www-python Delete the lock file and after a short pause I get: cvs server: [15:58:57] obtained lock in /home/dolphin/projects/www-python Checking in fsm.py; /home/dolphin/projects/www-python/fsm.py,v <-- fsm.py new revision: 1.4; previous revision: 1.3 done Cute, huh? So, this confirms what I suspected. There would appear to be a bug in cvs (I'm using 1.10.7). I will look and see if this is a reported bug and/or see if there is a newer version of cvs. Note that this doesn't let SourceForge off the hook. In theory, anyone with read access to any (or all?!?) CVS repositories at sourceforge.net could bring them to a screeching halt (at least for a bit) by performing the same trick on lots of repositories. my-fortune-cookie-quote-takes-on-new-meaning-ly y'rs, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From bwarsaw at beopen.com Fri Jul 7 23:11:59 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 7 Jul 2000 17:11:59 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? References: <20000707124449.E29590@lyra.org> <14694.17186.868952.214837@anthem.concentric.net> <20000707140539.N29590@lyra.org> Message-ID: <14694.18335.738567.420313@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> I haven't had tabs in my Python files for years :-) Cool! GS> (C code is a different matter...) Yup. From fredrik at pythonware.com Fri Jul 7 23:26:42 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 23:26:42 +0200 Subject: [Python-Dev] what's dos-8x3/rfc822-n.py? Message-ID: <01a401bfe85a$0c1819f0$0900a8c0@SPIFF> more stupid questions: jeremy wrote: > rfc822-n.py > Log Message: > fix inconsistent use of tabs and spaces is that really a valid module name? shouldn't DOS users be able to use the standard rfc822 module? why are they different? (not sure, but the one in the dos-8x3 directory looks newer). (btw, why is there a Lib/dos-8x3 and a Lib/dos_8x3 directory in the repository?) From fredrik at pythonware.com Fri Jul 7 23:28:21 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 23:28:21 +0200 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <200007072158.QAA05483@cj20424-a.reston1.va.home.com> Message-ID: <01b501bfe85a$475f6cc0$0900a8c0@SPIFF> guido wrote: > > The meaning of mixing both kinds of objects is very easy to explain, > > and also allows for efficient implementation - which you won't get if > > you have to invoke a character conversion just to get the hash value > > of a unicode value (!) > > I agree with this point. It can be implemented easily by deleting the > locale specific guessing from site.py. as an aside, Jack reported that: if u" " in tuple(string.whitespace): ... bombs on the macintosh (this is from SRE). the reason? the default encoding is set to "ascii", but C's isspace predicate thinks that some characters in the 128-255 range are whitespace characters. tricky. PS. I'll post the Windows get_locale code tomorrow. hopefully, Jack can whip up something similar for the Mac. From guido at beopen.com Sat Jul 8 00:36:00 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 17:36:00 -0500 Subject: [Python-Dev] what's dos-8x3/rfc822-n.py? In-Reply-To: Your message of "Fri, 07 Jul 2000 23:26:42 +0200." <01a401bfe85a$0c1819f0$0900a8c0@SPIFF> References: <01a401bfe85a$0c1819f0$0900a8c0@SPIFF> Message-ID: <200007072236.RAA05766@cj20424-a.reston1.va.home.com> > more stupid questions: > > jeremy wrote: > > > rfc822-n.py > > Log Message: > > fix inconsistent use of tabs and spaces > > is that really a valid module name? No -- my mistake. I'll delete it. > shouldn't DOS users be able to use the standard rfc822 > module? why are they different? (not sure, but the > one in the dos-8x3 directory looks newer). That's a red herring. > (btw, why is there a Lib/dos-8x3 and a Lib/dos_8x3 > directory in the repository?) The dos_8x3 one was a mistake, but CVS won't let you really delete directories. Use "cvs update -P" to delete empty directories. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Fri Jul 7 23:31:13 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 7 Jul 2000 16:31:13 -0500 (CDT) Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: References: Message-ID: <14694.19489.449195.619187@beluga.mojam.com> Ping> So "34"+0 converts to a number and 34."" converts to a string Ping> (i've seen both idioms fairly often). Halleluhah! Never thought I'd get Perl programming help here! We have this nagging problem with our XML-RPC stuff. When a band or venue name consisting of all digits (like "311") name comes into our concert database server from a Perl client, it comes in as a number instead of a string. The only workaround so far was to check at all server interfaces where this might occur and call str() when we found a number. Now it looks like I can toss the problem back into the client and save a few cpu cycles on the server (and more to the point, not pay the cost of the test all the time)... Ka-Ping> Anyway, i still agree that it's best to avoid automatic Ka-Ping> coercion between numbers and strings Amen to that! Skip From guido at beopen.com Sat Jul 8 00:41:57 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 17:41:57 -0500 Subject: [Python-Dev] Python release delay Message-ID: <200007072241.RAA05873@cj20424-a.reston1.va.home.com> CNRI's Bob Kahn has this message for the Python user community: > "As a result of the recent transition of the Core Python development > activity from CNRI to BeOpen, a number of issues have arisen that CNRI and > BeOpen are in the process of working out. As soon as these are resolved, > which we hope will be very shortly, we plan to have the final version of > Python 1.6 available for download. We apologize for this delay, but > hopefully, it will not last long and will ultimately put the future python > evolution on a more solid foundation. In the meantime, BeOpen and CNRI will > also be working together on updates to the python.org website, and bug > reports, patches and other contributions to Python 1.6 should continue to > be submitted to CNRI following the procedures posted at the python.org site." --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Sat Jul 8 00:01:53 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 8 Jul 2000 00:01:53 +0200 Subject: [Python-Dev] Python release delay In-Reply-To: <200007072241.RAA05873@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 07, 2000 at 05:41:57PM -0500 References: <200007072241.RAA05873@cj20424-a.reston1.va.home.com> Message-ID: <20000708000153.J26534@xs4all.nl> On Fri, Jul 07, 2000 at 05:41:57PM -0500, Guido van Rossum wrote: > CNRI's Bob Kahn has this message for the Python user community: > > "As a result of the recent transition of the Core Python development > > activity from CNRI to BeOpen, a number of issues have arisen that CNRI and > > BeOpen are in the process of working out. As soon as these are resolved, > > which we hope will be very shortly, we plan to have the final version of > > Python 1.6 available for download. We apologize for this delay, but > > hopefully, it will not last long and will ultimately put the future python > > evolution on a more solid foundation. In the meantime, BeOpen and CNRI will > > also be working together on updates to the python.org website, and bug > > reports, patches and other contributions to Python 1.6 should continue to > > be submitted to CNRI following the procedures posted at the python.org site." Uuhmm... So... - The next version will be Python 1.6, not 2.0 - All patch submissions since PythonLabs started and everyone promptly forgot about the CNRI-required Disclaimer should be resubmitted with disclaimer (or perhaps disclaimer posted seperately) - This goes for all future versions of Python as well - CNRI, not Guido, BeOpen or PythonLabs , controls the future of Python, for everything from bugfixes to new features. When will we get your (Guido), PythonLabs' or BeOpen's official statement(s) on this ? :) Please-correct-me-if-I'm-wrong-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Sat Jul 8 00:07:48 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 18:07:48 -0400 (EDT) Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: <14694.19489.449195.619187@beluga.mojam.com> References: <14694.19489.449195.619187@beluga.mojam.com> Message-ID: <14694.21684.395468.753641@bitdiddle.concentric.net> >>>>> "SM" == Skip Montanaro writes: Ping> So "34"+0 converts to a number and 34."" converts to a string Ping> (i've seen both idioms fairly often). SM> Halleluhah! Never thought I'd get Perl programming help here! Talk about a low signal-to-noise ratio! You get insights into a lot more than Python on python-dev. Jeremy From pingster at ilm.com Sat Jul 8 00:26:13 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 7 Jul 2000 15:26:13 -0700 (PDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000707103308.8074FE2673@oratrix.oratrix.nl> Message-ID: On Fri, 7 Jul 2000, Jack Jansen wrote: > I would suggest not putting it into urllib but in a "launch" module. [...] > in a separate module it's probably easier to extend to to various > other things you might want to launch (fileviewers, editors, etc). Hmm, i rather like this idea. Actually, i like it enough to suggest that "launch" would be a good interface to external applications -- launch.filebrowser("/home") launch.webbrowser("http://www.python.org/", newwindow=1) launch.mailreader() launch.mailcomposer("python-dev at python.org", subject="Spam") launch.textviewer("README") launch.texteditor("spam.py") launch.shell("/usr") launch.remoteshell("unseen.python.org", port=23) On Unix this would take advantage of (and formalize) the PAGER, EDITOR, BROWSER, etc. environment variables; on Windows they could look at registry settings, and for Mac, they could use IC. The webbrowser() function would be based on ESR's webbrowser.py; the others shouldn't be too hard to toss off... -- ?!ng From jeremy at beopen.com Sat Jul 8 00:31:40 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 18:31:40 -0400 (EDT) Subject: [Python-Dev] Python release delay In-Reply-To: <20000708000153.J26534@xs4all.nl> References: <200007072241.RAA05873@cj20424-a.reston1.va.home.com> <20000708000153.J26534@xs4all.nl> Message-ID: <14694.23116.916187.841812@bitdiddle.concentric.net> This isn't an official statement, but I hope it will clarify our plans and how they relate to CNRI's plans. CNRI plans to issue a 1.6 release. PythonLabs is still planning to issue a Python 2.0 release, almost surely following the 1.6 release. The current CVS repository contains what will be the 2.0 release. Please use the current mechanisms for contributing to our release -- the SF patch manager, the old Python bug database, etc. I'm not sure how you can contribute to Python 1.6, since CNRI is ultimately responsible for it. We will probably assist them, but I'm not sure how. You may want to inquire about the license that Python 1.6 will be released under. In the absence of a better place to direct inquires, you could try webmaster at python.org. This address will reach someone at CNRI, who can probably direct you to the right person. Jeremy From paul at prescod.net Sat Jul 8 01:04:20 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 07 Jul 2000 18:04:20 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <39661CAF.9252D734@prescod.net> <200007072102.QAA05114@cj20424-a.reston1.va.home.com> Message-ID: <396661F4.6541AB42@prescod.net> Guido van Rossum wrote: > > Really? Does 3+"" really convert the 3 to a string in Java? class foo{ void foo(){ System.err.println( 5+"" ); } } > > C++, depending on the type. Python's strictness > > about this issue has never caught a bug for me. It has only caused > > errors. > > Are you sure? This is the kind of error where you immediately see > what's wrong and move on to the next bug. I am sure that 99% of the time when I get an error message trying to add a string to something, it is because I expect the thing to be automatically coerced to the string. This probably comes from the other languages I have used. > > It's certainly caught errors for me, and especially when introducing Perl > programmers to Python, where "they expect" string+number to convert the > string to a number, apparently the opposite of the arbitrary choice Paul > prefers. > > It's ambiguous as hell -- screw it. I don't see the choice as arbitrary. Perl's choice is just insane. :) According to the definition used in Java, Javascript and C++ (sometimes) x+y If y is a string then x+y is well-defined no matter what the type of x or the content of y. Under the Perl definition, it totally depends on the type of y and the contents of x. Insane! I advocate special casing of strings (which are already special cased in various ways) whereas Perl special cases particular string values. Insane! -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From paul at prescod.net Sat Jul 8 01:24:13 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 07 Jul 2000 18:24:13 -0500 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> Message-ID: <3966669D.B436CD39@prescod.net> "Martin v. Loewis" wrote: > > > ... > >Only if the default encoding is ASCII. > > That is not my understanding of the agreement, and I think the whole > idea of a default encoding is a stupid one. Let me be more tactful and say that I am not really comfortable with my code changing behavior subtly because of an environment variable. A default encoding might be interesting at I/O boundaries like print, raw_input() and read(), but I would rather it didn't work pervasively through the code. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From paul at prescod.net Sat Jul 8 01:28:13 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 07 Jul 2000 18:28:13 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: Message-ID: <3966678D.677F199F@prescod.net> Ka-Ping Yee wrote: > > ... > > Anyway, i still agree that it's best to avoid automatic coercion > between numbers and strings -- since it's now very easy to say > int("3") as opposed to import string; string.atoi("3"), there's > really no excuse for not being explicit. I want to be clear that I'm not asking for automatic coercion between numbers and strings but rather automatic coercion of any type to string. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From thomas at xs4all.net Sat Jul 8 01:32:16 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 8 Jul 2000 01:32:16 +0200 Subject: [Python-Dev] [OffTopic] Re: Unicode experience In-Reply-To: <396661F4.6541AB42@prescod.net>; from paul@prescod.net on Fri, Jul 07, 2000 at 06:04:20PM -0500 References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <39661CAF.9252D734@prescod.net> <200007072102.QAA05114@cj20424-a.reston1.va.home.com> <396661F4.6541AB42@prescod.net> Message-ID: <20000708013216.M26534@xs4all.nl> On Fri, Jul 07, 2000 at 06:04:20PM -0500, Paul Prescod wrote: > According to the definition used in Java, Javascript and C++ (sometimes) > x+y > If y is a string then x+y is well-defined no matter what the type of x > or the content of y. The right hand side of the operation determines what the result is ? Somehow I find that confusing and counter-intuitive, but perhaps I'm too used to __add__ vs. __radd__ ;) Anyway, I've tried to learn C++ and Java both twice now, buying books by *good* authors (like Peter v/d Linden) and I still manage to run screaming after reading a single page of feature listings ;) > Under the Perl definition, it totally depends on the type of y and the > contents of x. Insane! Nono, absolutely not. Perl is weirdly-typed: the type is determined by the *operator*, not the operands. If you do '$x + $y', and both $x and $y are strings, they will both be converted to numbers (ending up 0 if it fails) and added as numbers, and the result is a number. (But since perl is weirdly-typed, if you need it to result in a string, the number will be converted to a string as necessary.) If you want string-concatenation, use '.', which will turn numbers into strings. But Perl wouldn't be Perl if it hadn't *some* exceptions to this kind of rule ;) '$x++', where $x is a string, can return a string. The 'string-auto-increment' operator is Magic(tm): if the string matches /^[a-zA-Z]*[0-9]*$/, that is, something like 'spam001', the ++ operator adds one to the number at the end of the string. so 'spam001' would become 'spam002'. If you do it to 'spam999', it'll be incremented to 'span000', 'spaz999' becomes 'spba000', and so on. However, Perl wouldn't be Perl if it hadn't some excpetion to *this* too ;) Well, not really an exception, but... The string *must* exactly match the regexp above, or the '++' operator will turn it into a number '1' instead. So your string cannot be '-spam01', or 'sp0m01', or anything like that. Rendering this magic behaviour pretty useless in general, because it's easier, more readable and less buggy to do the work the magic ++ does by hand. (We actually had some database 'corruption' in our old user-database because of this... a tool accepted a 'template' username and tried to create a specified number of accounts with a name in sequence to that template... The original code had a safeguard (the above regexp) but it got removed somehow, and eventually someone used a wrong template, and we ended up with accounts named '1' through '8' ;P) > I advocate special casing of strings (which are already special cased in > various ways) whereas Perl special cases particular string values. > Insane! Well, yes. But Perl special cases about everything and their dog. Not Good. (Okay, I promise to stay on-topic for a while now ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From DavidA at ActiveState.com Sat Jul 8 01:40:15 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 7 Jul 2000 16:40:15 -0700 (Pacific Daylight Time) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.17186.868952.214837@anthem.concentric.net> Message-ID: > >>>>> "TP" == Tim Peters writes: > > >> I'll do a separate commit that just changes white space (and > >> possibly reflow some comments). > > TP> Bingo! > > TP> life-is-so-much-easier-when-you-don't-think-too-much-ly > TP> y'rs - tim > > Oh, and while you're at it, please untabify the file. I don't know if > your module has tabs in it, but if so please convert all tabs to > spaces. IMO, with the right python-mode settings, all of us using emacs should never have to have this discussion! (going to have to do something about that in Komodo ! =). --david From fdrake at beopen.com Sat Jul 8 01:49:20 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 19:49:20 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: References: <14694.17186.868952.214837@anthem.concentric.net> Message-ID: <14694.27776.620365.621524@cj42289-a.reston1.va.home.com> David Ascher writes: > IMO, with the right python-mode settings, all of us using emacs should > never have to have this discussion! I people didn't screw up their settings we wouldn't! Barry: Perhaps the right solution is to hard-code python-mode to always set indent-tabs-mode to nil, the indentation to 4, and retabify when it loads a file? ;) Oh, and do it again when it saves, so nobody can screw up their modules. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sat Jul 8 01:48:04 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 19:48:04 -0400 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: Message-ID: [David Ascher] > IMO, with the right python-mode settings, all of us using emacs should > never have to have this discussion! If Unix weenies would just *accept* the damned defaults, these discussions would never arise. You can tell a Unix user from across the room: they're the ones who attach leeches to their eyeballs and then complain about blurry vision . > (going to have to do something about that in Komodo ! =). Make it a Windows-only app. Windows users do whatever they're told, and then *pay* you, over & over, for punishing them . From pingster at ilm.com Sat Jul 8 01:59:16 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 7 Jul 2000 16:59:16 -0700 (PDT) Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: <3966678D.677F199F@prescod.net> Message-ID: On Fri, 7 Jul 2000, Paul Prescod wrote: > > I want to be clear that I'm not asking for automatic coercion between > numbers and strings but rather automatic coercion of any type to string. As it stands, with both 8-bit strings and Unicode strings, i think this would result in too much hidden complexity -- thinking about this can wait until we have only one string type. We could consider this after we unify strings, but even then it would take some arguing to convince me that automatic coercion is desirable. -- ?!ng From gstein at lyra.org Sat Jul 8 03:32:13 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 18:32:13 -0700 Subject: [Python-Dev] Encodings In-Reply-To: <3966669D.B436CD39@prescod.net>; from paul@prescod.net on Fri, Jul 07, 2000 at 06:24:13PM -0500 References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> Message-ID: <20000707183213.P29590@lyra.org> On Fri, Jul 07, 2000 at 06:24:13PM -0500, Paul Prescod wrote: > "Martin v. Loewis" wrote: > > > > > ... > > >Only if the default encoding is ASCII. > > > > That is not my understanding of the agreement, and I think the whole > > idea of a default encoding is a stupid one. > > Let me be more tactful and say that I am not really comfortable with my > code changing behavior subtly because of an environment variable. A > default encoding might be interesting at I/O boundaries like print, > raw_input() and read(), but I would rather it didn't work pervasively > through the code. Agreed. When this whole thing started, I thought there was going to be a fixed default encoding. Then the "changeable default" snuck into the code under the guise of "experimental work". Now that changeable default seems ingrained into the code and is introducing exactly the problems that we feared last fall -- unpredictability. Please... toss the changeable default. If everybody knows the default encoding is "ascii" and they want something else, then they know what to do. But when the default can change, then it can't be relied on. The coder is going to have to do an explicit encoding anyways. So why have a default? Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Sat Jul 8 06:11:45 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 00:11:45 -0400 (EDT) Subject: [Python-Dev] HAVE_OLD_CPP and the token-pasting operator Message-ID: <14694.43521.924155.15736@cj42289-a.reston1.va.home.com> operator.c includes a couple of macros that are defined to either use the ANSI token-pasting operator (##) or the old /**/ trick. Since I know macros in other source files are just using the token-pasting operator, and I've not heard anyone scream, should I just remove the old style macros since we're requiring ANSI C now? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sat Jul 8 06:31:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 00:31:27 -0400 Subject: [Python-Dev] Include/pyport.h now exists Message-ID: Checkin comment below. Would someone who understands (& can test! I can't yet) autoconfig please follow up on the last part? The stuff I checked in "fails safe", i.e. the lack of autoconfig support should not cause problems on any of your platforms. figured-it-was-best-to-just-do-it-and-apologize-later-ly y'rs - tim Cray J90 fixes for long ints. This was a convenient excuse to create the pyport.h file recently discussed! Please use new Py_ARITHMETIC_RIGHT_SHIFT when right-shifting signed int and you *need* sign-extension. This is #define'd in pyport.h, keying off new config symbol SIGNED_RIGHT_SHIFT_ZERO_FILLS. If you're running on a platform that needs that symbol #define'd, the std tests never would have worked for you (in particular, at least test_long would have failed). The autoconfig stuff got added to Python after my Unix days, so I don't know how that works. Would someone please look into doing & testing an auto-config of the SIGNED_RIGHT_SHIFT_ZERO_FILLS symbol? It needs to be defined if & only if, e.g., (-1) >> 3 is not -1. From tim_one at email.msn.com Sat Jul 8 06:33:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 00:33:42 -0400 Subject: [Python-Dev] HAVE_OLD_CPP and the token-pasting operator In-Reply-To: <14694.43521.924155.15736@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > operator.c includes a couple of macros that are defined to either > use the ANSI token-pasting operator (##) or the old /**/ trick. Since > I know macros in other source files are just using the token-pasting > operator, and I've not heard anyone scream, should I just remove the > old style macros since we're requiring ANSI C now? Yes! We should at least pretend we're living in the 1900's by now . From tim_one at email.msn.com Sat Jul 8 09:01:37 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 03:01:37 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <200007062157.QAA01227@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > ... (Is a summary of these [C9X] names online somewhere?) ISO refuses to put current stds online, so I'll reword an anonymous source (shhh! & some of this may be a little out of date): Exact-width typedefs: int8_t int16_t int32_t int64_t uint8_t uint16_t uint32_t uint64_t It's allowed that a given platform not define *any* of these. Therefore portable code can never rely on having exactly N bits regardless of N. Minimum-width typedefs: int_least8_t int_least16_t int_least32_t int_least64_t uint_least8_t uint_least16_t uint_least32_t uint_least64_t *All* of these must be defined (so even teensy platforms have to fake at least 64 bits). Fastest minimum-width typedefs: int_fast8_t int_fast16_t int_fast32_t int_fast64_t uint_fast8_t uint_fast16_t uint_fast32_t uint_fast64_t All of these must exist. What's the difference between these and minimum-width? For example, on a Cray J90 the least8_t will be a char, but since the HW supports no byte operations, the fast8_t will likely be 64 bits wide. Pointer<->int casting intptr_t uintptr_t These are signed & unsigned int types such that a valid void* p can be cast to them and back again, yielding a result == p. Very curiously, the last draft std I saw allowed for neither to be defined! Fattest types intmax_t uintmax_t The biggest int type (note that this may be fatter than "long long"!). Must be defined. Limit macros The names of these match the regexp (re.VERBOSE): U? INT (8|16|32|64) _ (MIN|MAX) | U? INT_ (LEAST|FAST) (8|16|32|64) _ (MIN|MAX) | INTPTR_ (MIN|MAX) | UINTPTR_MAX | INTMAX_ (MIN|MAX) | UINTMAX_MAX Macros for literals The names match the regexp: U? INT (8|16|32|64) _C Each of these 8 macros takes an integer literal argument, and expands it to whatever gibberish the platform needs to make a valid literal of at least the specified width. Also INTMAX_C(lit) and UINTMAX_C(lit), to do likewise for the fattest type (intmax_t or uintmax_t) supported by the platform. Macros for format specifiers There are many dozens of these! They address the problem that it's great you can now ask for, e.g., an int_fast32_t, but you still have no idea how big it is so also no idea what to stick in printf or scanf formats to do correct I/O on values of that type. Other limits ptrdiff_t: PTRDIFF_MIN PTRDIFF_MAX sig_atomic_t: SIG_ATOMIC_MIN SIG_ATOMIC_MAX size_t: SIZE_MAX wchar_t: WCHAR_MIN WCHAR_MAX wint_t: WINT_MIN WINT_MAX I don't expect Python needs more than half a dozen of these, but haven't given it sufficient thought. If somebody else beats me to it, I would be pleased . the-very-need-for-names-like-intmax_max-is-a-strong-argument- for-euthanasia-ly y'rs - tim From tim_one at email.msn.com Sat Jul 8 09:09:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 03:09:36 -0400 Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: <20000708064203.D7FBC1CD45@dinsdale.python.org> Message-ID: [various patches from Fred Drake, w/ the comment > ANSI-fied sources, converted to four-space indentation. ] Fred, you appear to be 4-space indenting C source. Is that allowed? Last I think I heard, Guido was still clinging to his schizophrenia on this topic (4-space for .py and no hard tabs, 8-space for .c/.h and hard tabs). god-knows-i'd-like-'em-to-be-the-same-ly y'rs - tim From moshez at math.huji.ac.il Sat Jul 8 10:07:30 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 8 Jul 2000 11:07:30 +0300 (IDT) Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: Message-ID: On Sat, 8 Jul 2000, Tim Peters wrote: > [various patches from Fred Drake, w/ the comment > > ANSI-fied sources, converted to four-space indentation. > ] > > Fred, you appear to be 4-space indenting C source. Is that allowed? Last I > think I heard, Guido was still clinging to his schizophrenia on this topic > (4-space for .py and no hard tabs, 8-space for .c/.h and hard tabs). I have never seen a formal statement from Guido about it, but I always assumed Python's C sources are linux kernel style...No? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From thomas at xs4all.net Sat Jul 8 10:28:47 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 8 Jul 2000 10:28:47 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules linuxaudiodev.c,2.2,2.3 In-Reply-To: <200007080606.XAA22987@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Fri, Jul 07, 2000 at 11:06:01PM -0700 References: <200007080606.XAA22987@slayer.i.sourceforge.net> Message-ID: <20000708102847.N26534@xs4all.nl> On Fri, Jul 07, 2000 at 11:06:01PM -0700, Fred L. Drake wrote: > Modified Files: > linuxaudiodev.c > Log Message: > Add method names to PyArg_ParseTuple() calls for better error messages. > Convert to four-space indents. Aren't tabs preferred as C-source indents, instead of 4-spaces ? At least, that's what I see in Python/*.c and Object/*.c, but I only vaguely recall it from the style document... -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From ping at lfw.org Sat Jul 8 11:35:05 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sat, 8 Jul 2000 02:35:05 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <200007070034.CAA02914@python.inrialpes.fr> Message-ID: On Fri, 7 Jul 2000, Vladimir Marangozov wrote: > Okay. Since you've already altered the error list in errcode.h, > I think that the best thing to do is to re-introduce E_INDENT > but for the "missing indentation" case (reported to the user as > "expected an indented block"), then return E_INDENT from AddToken() > and revert back its signature. Thus all additional error cases you've > detected so far would be handled fine in pythonrun.c. I think i'd rather leave the patch as it is. I can see that what you're suggesting would eliminate the need for the expected_ret argument to PyParser_AddToken(), but i think there's more value in exposing the expected token to pythonrun -- it leaves open the possibility for further more detailed and helpful messages in the future, without having to create separate error codes for each. It seems right that these situations should fall under the E_SYNTAX error code (otherwise we'd have to say that E_SYNTAX means "syntax error except for missing-indentation errors" etc.). E_SYNTAX is the general error code for "we got a token but the parser wouldn't accept it". (E_TABSPACE, E_TOODEEP, and E_DEDENT are errors at the token level.) And i don't see a lot of motivation to *avoid* passing back the expected token. There isn't anyone else depending on the interface to PyParser_AddToken (parser.h is a private header file). Hmm. Is that sufficiently convincing? -- ?!ng "To be human is to continually change. Your desire to remain as you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From Vladimir.Marangozov at inrialpes.fr Sat Jul 8 11:43:41 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 8 Jul 2000 11:43:41 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Ka-Ping Yee" at Jul 08, 2000 02:35:05 AM Message-ID: <200007080943.LAA09790@python.inrialpes.fr> Ka-Ping Yee wrote: > > And i don't see a lot of motivation to *avoid* passing back the > expected token. There isn't anyone else depending on the interface > to PyParser_AddToken (parser.h is a private header file). > > Hmm. Is that sufficiently convincing? Yes. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Sat Jul 8 11:55:07 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 8 Jul 2000 02:55:07 -0700 Subject: [Python-Dev] CVS: python/dist/src/Include pyport.h,NONE,2.1 Python.h,2.21,2.22 longintrepr.h,2.8,2.9 In-Reply-To: <200007080417.VAA05755@slayer.i.sourceforge.net>; from tim_one@users.sourceforge.net on Fri, Jul 07, 2000 at 09:17:24PM -0700 References: <200007080417.VAA05755@slayer.i.sourceforge.net> Message-ID: <20000708025506.A29590@lyra.org> On Fri, Jul 07, 2000 at 09:17:24PM -0700, Tim Peters wrote: >... > #ifndef Py_PYPORT_H > #define Py_PYPORT_H 1 > > /************************************************************************** > Symbols and macros to supply platform-independent interfaces to basic > C-language operations whose spellings vary across platforms. > > Please try to make documentation here as clear as possible: by definition, > the stuff here is trying to illuminate C's darkest corners. > > Config #defines referenced here: > > SIGNED_RIGHT_SHIFT_ZERO_FILLS > Meaning: To be defined iff i>>j does not extend the sign bit when i is a > signed integral type and i < 0. > Used in: Py_ARITHMETIC_RIGHT_SHIFT > **************************************************************************/ Note that it would be nice for pyport.h to *also* contain all the Include/my* stuff. i.e. it isn't just about C-language operations, but also about the (un)available libraries. IOW, stop the propagation of my* and drop those tweaky things into pyport. Cheers, -g -- Greg Stein, http://www.lyra.org/ From skip at mojam.com Sat Jul 8 12:32:40 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 8 Jul 2000 05:32:40 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> References: <14691.49563.78765.683762@beluga.mojam.com> <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> Message-ID: <14695.840.448508.397722@beluga.mojam.com> Regarding list comprehensions I recently proposed this as a possible option: >> * bundle up another patch for people to examine and comment on to which Fredrik replied /F> I'd vote for [that] Since Fredrik's voice is the only one I heard, and on the off-chance that the CNRI/BeOpen discussions and resulting 1.6 release push things out a bit (allowing a feature thaw) I'll oblige. The attached patch to add list comprehensions affects the following files: Doc/ref/ref5.tex Doc/tut/tut.tex Grammar/Grammar Include/graminit.h Lib/test/test_grammar.py Lib/test/output/test_grammar Python/compile.c Python/graminit.c About half the patch is the change to the (generated) graminit.c. The rest is actually fairly simple. i-really-hate-seeing-those-M's-when-i-cvs-update-ly y'rs, Skip -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: listcomp.patch URL: From effbot at telia.com Sat Jul 8 15:01:21 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 15:01:21 +0200 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe References: <000001bfe79d$ac720ae0$060210ac@private> Message-ID: <005801bfe8dc$9ef3f320$f2a6b5d4@hagrid> barry scott wrote: > os.popen fails to work if pythonw.exe is used to start python. This is > true for 1.5.2 and 1.6a2. > > The root cause of the problem is in the Microsoft C RTL implementation > of _popen(). _popen() will fail if there is not a valid file descriptor > for stdin or stdout. > > The following replacement for WinMain.c works around the problem. > I also ensure a valid descriptor for stderr for completeness. > > This was compiled and test under VC++ 6.0 SP3 on Windows 2000. +1 from me. unless mark|bill|trent|.+ objects, I'll check it in later. cheers /F PS. I've uploaded it to the SF patch manager: http://sourceforge.net/patch/index.php?patch_id=100764&group_id=5470 From gstein at lyra.org Sat Jul 8 15:14:18 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 8 Jul 2000 06:14:18 -0700 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe In-Reply-To: <005801bfe8dc$9ef3f320$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jul 08, 2000 at 03:01:21PM +0200 References: <000001bfe79d$ac720ae0$060210ac@private> <005801bfe8dc$9ef3f320$f2a6b5d4@hagrid> Message-ID: <20000708061417.E29590@lyra.org> Bill has done a ton of stuff with popen() on Windows. I'm CC'ing him to make sure that he sees this. Cheers, -g On Sat, Jul 08, 2000 at 03:01:21PM +0200, Fredrik Lundh wrote: > barry scott wrote: > > os.popen fails to work if pythonw.exe is used to start python. This is > > true for 1.5.2 and 1.6a2. > > > > The root cause of the problem is in the Microsoft C RTL implementation > > of _popen(). _popen() will fail if there is not a valid file descriptor > > for stdin or stdout. > > > > The following replacement for WinMain.c works around the problem. > > I also ensure a valid descriptor for stderr for completeness. > > > > This was compiled and test under VC++ 6.0 SP3 on Windows 2000. > > +1 from me. > > unless mark|bill|trent|.+ objects, I'll check it in later. > > cheers /F > > PS. I've uploaded it to the SF patch manager: > http://sourceforge.net/patch/index.php?patch_id=100764&group_id=5470 > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Sat Jul 8 15:29:34 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 09:29:34 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: References: <200007062157.QAA01227@cj20424-a.reston1.va.home.com> Message-ID: <14695.11454.283571.492775@cj42289-a.reston1.va.home.com> Tim Peters writes: > ISO refuses to put current stds online, so I'll reword an anonymous source > (shhh! & some of this may be a little out of date): The URL I posted has a pointer to a copy of the "Final Committee Draft," which is probably sufficient. PDF and PostScript were both available. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Sat Jul 8 15:32:55 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 09:32:55 -0400 (EDT) Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: References: <20000708064203.D7FBC1CD45@dinsdale.python.org> Message-ID: <14695.11655.433199.734714@cj42289-a.reston1.va.home.com> Tim Peters writes: > Fred, you appear to be 4-space indenting C source. Is that allowed? Last I > think I heard, Guido was still clinging to his schizophrenia on this topic > (4-space for .py and no hard tabs, 8-space for .c/.h and hard tabs). I seem to recall that Guido had caved on this, mostly because he received enough complaints about too much code getting shoved way over to the right, in a column a dozen of fewer characters wide (which is seriously hard to decode). I don't remember if this was on the list or in a meeting. If I'm mis-remembering, then we should presure him on this until he does cave. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Sat Jul 8 15:32:03 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 08 Jul 2000 08:32:03 -0500 Subject: [Python-Dev] String coercion References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <39661CAF.9252D734@prescod.net> <200007072102.QAA05114@cj20424-a.reston1.va.home.com> <396661F4.6541AB42@prescod.net> <20000708013216.M26534@xs4all.nl> Message-ID: <39672D53.899D4BEB@prescod.net> Thomas Wouters wrote: > > ... > > The right hand side of the operation determines what the result is ? No, either side determines what the result is. This is not magic. It's just like floating point coercion or complex number coercion. > Somehow > I find that confusing and counter-intuitive, but perhaps I'm too used to > __add__ vs. __radd__ ;) This can be easily defined in terms of add and radd: class PaulsString: def __init__( self, str ): self.str=str def __add__( self, foo ): return self.str + str( foo ) def __radd__( self, bar ): return str( bar ) + self.str print PaulsString("abcdef")+5 print open+PaulsString("ghijkl") abcdef5 ghijkl Here's an even simpler definition: class PaulsString: def __init__( self, str ): self.str=str def __coerce__( self, other ): return (self.str, str( other )) Ping says: > As it stands, with both 8-bit strings and Unicode strings, i think > this would result in too much hidden complexity -- thinking about this > can wait until we have only one string type. I don't see any hidden complexity. Python has features specifically designed to allow this sort of thing on a per-type basis. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From guido at beopen.com Sat Jul 8 16:34:14 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 09:34:14 -0500 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe In-Reply-To: Your message of "Thu, 06 Jul 2000 23:58:17 +0100." <000001bfe79d$ac720ae0$060210ac@private> References: <000001bfe79d$ac720ae0$060210ac@private> Message-ID: <200007081434.JAA07087@cj20424-a.reston1.va.home.com> > os.popen fails to work if pythonw.exe is used to start python. This is > true for 1.5.2 and 1.6a2. > > The root cause of the problem is in the Microsoft C RTL implementation > of _popen(). _popen() will fail if there is not a valid file descriptor > for stdin or stdout. > > The following replacement for WinMain.c works around the problem. > I also ensure a valid descriptor for stderr for completeness. > > This was compiled and test under VC++ 6.0 SP3 on Windows 2000. Let's also test it on Windows 98, 95 and NT. If it works for all, I'm +1. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Sat Jul 8 15:35:08 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 09:35:08 -0400 (EDT) Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: References: Message-ID: <14695.11788.491744.539193@cj42289-a.reston1.va.home.com> Moshe Zadka writes: > I have never seen a formal statement from Guido about it, but I always > assumed Python's C sources are linux kernel style...No? Python's sources are Guido's style. Any similarities with the Linux kernel are coincidental. I've seen a comparison, but don't remember much about it. Most developers don't even know where to look to find out the rules for Linux kernel style. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Sat Jul 8 16:39:51 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 09:39:51 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules linuxaudiodev.c,2.2,2.3 In-Reply-To: Your message of "Sat, 08 Jul 2000 10:28:47 +0200." <20000708102847.N26534@xs4all.nl> References: <200007080606.XAA22987@slayer.i.sourceforge.net> <20000708102847.N26534@xs4all.nl> Message-ID: <200007081439.JAA07139@cj20424-a.reston1.va.home.com> > Aren't tabs preferred as C-source indents, instead of 4-spaces ? At least, > that's what I see in Python/*.c and Object/*.c, but I only vaguely recall it > from the style document... Yes, you're right. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From effbot at telia.com Sat Jul 8 15:46:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 15:46:05 +0200 Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs References: <20000708064203.D7FBC1CD45@dinsdale.python.org> <14695.11655.433199.734714@cj42289-a.reston1.va.home.com> Message-ID: <039f01bfe8e2$deb32ac0$f2a6b5d4@hagrid> fred wrote: > Tim Peters writes: > > Fred, you appear to be 4-space indenting C source. Is that allowed? Last I > > think I heard, Guido was still clinging to his schizophrenia on this topic > > (4-space for .py and no hard tabs, 8-space for .c/.h and hard tabs). > > I seem to recall that Guido had caved on this, mostly because he > received enough complaints about too much code getting shoved way over > to the right, in a column a dozen of fewer characters wide (which is > seriously hard to decode). I don't remember if this was on the list > or in a meeting. > If I'm mis-remembering, then we should presure him on this until he > does cave. ;) guido? I think we need an official BDFL statement here... From guido at beopen.com Sat Jul 8 17:08:48 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 10:08:48 -0500 Subject: [Python-Dev] Encodings In-Reply-To: Your message of "Fri, 07 Jul 2000 18:32:13 MST." <20000707183213.P29590@lyra.org> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> Message-ID: <200007081508.KAA07351@cj20424-a.reston1.va.home.com> > Please... toss the changeable default. If everybody knows the default > encoding is "ascii" and they want something else, then they know what to do. > But when the default can change, then it can't be relied on. The coder is > going to have to do an explicit encoding anyways. So why have a default? I couldn't have said it better. It's okay for now to have it changeable at the C level -- with endless caveats that it should be set only once before any use, and marked as an experimental feature. But the Python access and the reliance on the environment should go. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Sat Jul 8 17:14:06 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 10:14:06 -0500 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: Your message of "Fri, 07 Jul 2000 19:49:20 -0400." <14694.27776.620365.621524@cj42289-a.reston1.va.home.com> References: <14694.17186.868952.214837@anthem.concentric.net> <14694.27776.620365.621524@cj42289-a.reston1.va.home.com> Message-ID: <200007081514.KAA07398@cj20424-a.reston1.va.home.com> > Barry: Perhaps the right solution is to hard-code python-mode to > always set indent-tabs-mode to nil, the indentation to 4, and retabify > when it loads a file? ;) Oh, and do it again when it saves, so > nobody can screw up their modules. ;) That would be fine if it weren't for triple-quoted strings... At the very least someone should run Lib/tabnanny.py on the Lib tree and fix all complaints! There are still complaints about mailbox.py and shlex.py. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Sat Jul 8 16:26:27 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 10:26:27 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <200007081514.KAA07398@cj20424-a.reston1.va.home.com> References: <14694.17186.868952.214837@anthem.concentric.net> <14694.27776.620365.621524@cj42289-a.reston1.va.home.com> <200007081514.KAA07398@cj20424-a.reston1.va.home.com> Message-ID: <14695.14867.517707.59800@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > At the very least someone should run Lib/tabnanny.py on the Lib tree > and fix all complaints! There are still complaints about mailbox.py > and shlex.py. I'll do this. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Sat Jul 8 17:00:33 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sat, 8 Jul 2000 11:00:33 -0400 (EDT) Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs References: <20000708064203.D7FBC1CD45@dinsdale.python.org> Message-ID: <14695.16913.984694.3842@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> Fred, you appear to be 4-space indenting C source. Is that TP> allowed? Last I think I heard, Guido was still clinging to TP> his schizophrenia on this topic (4-space for .py and no hard TP> tabs, 8-space for .c/.h and hard tabs). Emacs CC Mode has a "python" style which defines 8-space hard-tab indentation. This was the blessed style for Python's C code. I distinctly remember Guido agreeing to 4 space indents for Python 1.7 (or new code) but that it wasn't worth going back and changing existing code at this time. If Fred's doing a code cleansing then it's probably okay that he also adjust the indentation. Most important is consistency within the file. -Barry From tim_one at email.msn.com Sat Jul 8 17:17:49 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 11:17:49 -0400 Subject: [Python-Dev] CVS: python/dist/src/Include pyport.h ... In-Reply-To: <20000708025506.A29590@lyra.org> Message-ID: [Greg Stein] > Note that it would be nice for pyport.h to *also* contain all the > Include/my* stuff. i.e. it isn't just about C-language > operations, but also about the (un)available libraries. > > IOW, stop the propagation of my* and drop those tweaky things > into pyport. Sounds good to me, but I'm not going to make A Project out of that for myself. Kinda like getting rid of Py_PROTO and ANSI-fying, I'm just going to chip away at it as it's convenient when working on other things. pyproto.h isn't "my" file! Everyone have at it. best-way-to-get-everyone-on-the-same-page-is-to-have-everyone- write-part-of-it-ly y'rs - tim From tim_one at email.msn.com Sat Jul 8 17:29:06 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 11:29:06 -0400 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe In-Reply-To: <005801bfe8dc$9ef3f320$f2a6b5d4@hagrid> Message-ID: [/F] > +1 from me. > > unless mark|bill|trent|.+ objects, I'll check it in later. > > cheers /F > > PS. I've uploaded it to the SF patch manager: > http://sourceforge.net/patch/index.php?patch_id=100764&group_id=5470 Where I assigned it to you, but didn't accept it for sytle reasons: Assigned to effbot. I would have changed the status to accepted, except the coding style is one Guido won't accept: uses C++ comments in places, "if" braces in the wrong places, "extra" whitespace at each end of arglists, "if(" instead of "if (". I expect that arguing about style is futile. not-to-mention-a-waste-of-time-ly y'rs - tim From paul at prescod.net Sat Jul 8 17:34:16 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 08 Jul 2000 10:34:16 -0500 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] Message-ID: <396749F8.F98D2F8C@prescod.net> For those that don't read comp.lang.python. -------- Original Message -------- Subject: Re: Splitting c.l.py... Date: Sat, 08 Jul 2000 03:52:44 GMT From: "Neil Hodgson" Organization: BigPond Internet Services (http://www.bigpond.net.au) To: python-list at python.org Newsgroups: comp.lang.python References: <3dituj9cdi.fsf at kronos.cnri.reston.va.us> <39661DE1.A409330C at roguewave.com> <20000707140442.B4771 at kronos.cnri.reston.va.us> > Beats me. Hmm... here's a possibility: ... Essentially the newsgroup would > be a read-only view of the python-dev mailing list. But would it be of interest to anyone? python-dev has a much worse signal-to-noise ratio than comp.lang.python IMHO. One morning this week I opened up my mailer in the morning to see over 100 messages in python-dev and less than 80 in c.l.py. The traffic in python-dev alternates between checkin chat (there's a CVS lock here, that patch breaks on X, when will you finish Y?) and language/library design issues. I can see a reason for some of the detailed design issues to be decided on the same forum as the checkin chat with a limited group of people, but some of the larger issues should be debated in a wider forum. Was there any reason for "urllib.browse() issues" to be on python-dev? Possibly comp.lang.python is also a bad forum for discussing future changes to Python and should concentrate on solving peoples current problems and avoiding long winded discussions on new functionality. So a comp.lang.python.future (or similar mailing list) could provide a way for /all/ Pythoneers to be involved in the evolution of the language. Neil -- http://www.python.org/mailman/listinfo/python-list From tim_one at email.msn.com Sat Jul 8 17:36:32 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 11:36:32 -0400 Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: <14695.11655.433199.734714@cj42289-a.reston1.va.home.com> Message-ID: [Tim] > Fred, you appear to be 4-space indenting C source. Is that > allowed? Last I think I heard, Guido was still clinging to > his schizophrenia on this topic (4-space for .py and no hard > tabs, 8-space for .c/.h and hard tabs). [Fred] > I seem to recall that Guido had caved on this, mostly because he > received enough complaints about too much code getting shoved way over > to the right, in a column a dozen of fewer characters wide (which is > seriously hard to decode). I don't remember if this was on the list > or in a meeting. > If I'm mis-remembering, then we should presure him on this until he > does cave. ;) Guido, you need to Pronounce on this! I personally prefer 4-space no-hard-tabs everywhere, but given the way most editors work, the most important thing is that there's no variation within a given file type (e.g., that all .c files do the same, and all .py files do the same, but it's bearable for .c and .py files to differ -- which latter has been the case until now). From petersc at stud.ntnu.no Sat Jul 8 19:39:55 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Sat, 08 Jul 2000 17:39:55 +0000 Subject: indentation in .c files (was Re: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules linuxaudiodev.c,2.2,2.3) Message-ID: <3967676B.41E1CC5C@stud.ntnu.no> [Guido on a mail from Thomas Wouters] > > > Aren't tabs preferred as C-source indents, instead of 4-spaces ? At least, > > that's what I see in Python/*.c and Object/*.c, but I only vaguely recall it > > from the style document... > > Yes, you're right. Does that mean I should load up a revised version of my ANSI-fying patches for posixmodule and mmapmodule? Assuming Fred knew what he did, I also changed to -s 4 -t 8 ... Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From fdrake at beopen.com Sat Jul 8 18:01:39 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 12:01:39 -0400 (EDT) Subject: indentation in .c files (was Re: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules linuxaudiodev.c,2.2,2.3) In-Reply-To: <3967676B.41E1CC5C@stud.ntnu.no> References: <3967676B.41E1CC5C@stud.ntnu.no> Message-ID: <14695.20579.776070.898183@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > Does that mean I should load up a revised version of my > ANSI-fying patches for posixmodule and mmapmodule? ANSI-fication is clearly good. Whether or not 4-space indents go in is appearantly dependent on who checks in the patch. So leave them in if you've already done the work. ;) > Assuming Fred knew what he did, I also changed to -s 4 -t 8 ... Now, if we could get the rest of PythonLabs to make that assumption, we'd be in pretty good shape! ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Sat Jul 8 18:05:16 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 08 Jul 2000 18:05:16 +0200 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> Message-ID: <3967513C.BAF459FB@lemburg.com> Guido van Rossum wrote: > > > Please... toss the changeable default. If everybody knows the default > > encoding is "ascii" and they want something else, then they know what to do. > > But when the default can change, then it can't be relied on. The coder is > > going to have to do an explicit encoding anyways. So why have a default? > > I couldn't have said it better. It's okay for now to have it > changeable at the C level -- with endless caveats that it should be > set only once before any use, and marked as an experimental feature. > But the Python access and the reliance on the environment should go. Sorry, but I'm really surprised now: I've put many hours of work into this, hacked up encoding support for locale.py, went through endless discussions, proposed the changable default as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy ... and now all it takes is one single posting to render all that work useless ??? Instead of tossing things we should be *constructive* and come up with a solution to the hash value problem, e.g. I would like to make the hash value be calculated from the UTF-16 value in a way that is compatible with ASCII strings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Sat Jul 8 18:13:12 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 12:13:12 -0400 (EDT) Subject: [Python-Dev] SourceForge administration Message-ID: <14695.21272.269311.720751@cj42289-a.reston1.va.home.com> I was just browsing the SourceForge support requests, and it looks like no CVS-related requests have been dealt with for about 48 hours. So it's not that they're ignoring us, it's that they're ignoring support requests. If anyone knows anyone there, can ou ping them and ask if the company picnic has been going on all this time? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Sat Jul 8 18:24:08 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 12:24:08 -0400 (EDT) Subject: [Python-Dev] Encodings In-Reply-To: <3967513C.BAF459FB@lemburg.com> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> Message-ID: <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Sorry, but I'm really surprised now: I've put many hours of > work into this, hacked up encoding support for locale.py, > went through endless discussions, proposed the changable default > as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy My recollection was that the purpose of the changable default was so that we could experiment with different defaults more easily, not that we'd keep it changable. I'm not an expert on these issues and have tried to stay out of the way on the discussion, but the idea of a changable default just seems like we're asking for trouble. I'm sorry that you feel your efforts have been wasted; I don't think anyone tried to spend your time without careful consideration, but it is important that we all understand what we have gained from this experiment. Before you implemented the changable default, we all had the opportunity to presume to know how things would work with it, and could bitch or plead about it as we felt appropriate. Now that it's been tried, we have a little more real experiance with it, and can point to the evidence that's been presented here as we each make our arguments on the topic. So I'd have to say that your efforts have *not* been wasted; we now have a very good idea of what's involved and whether "it works." I, for one, am glad that the experiment was done (and expecially that it was done by someone who knows more about this than me!). > Instead of tossing things we should be *constructive* and come > up with a solution to the hash value problem, e.g. I would > like to make the hash value be calculated from the UTF-16 > value in a way that is compatible with ASCII strings. This may be the right thing for the hash value; I don't know. But I think this is in some ways separate from the changable defaults question. This approach can be taken for getting hash values right without having a changable default encoding. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From effbot at telia.com Sat Jul 8 18:45:07 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 18:45:07 +0200 Subject: [Python-Dev] SRE's match objects are missing .regs ?! References: <396478D8.26CBD0FA@lemburg.com> <20000706083223.A29375@newcnri.cnri.reston.va.us> Message-ID: <002a01bfe8fb$e0834d80$f2a6b5d4@hagrid> amk wrote: > .regs was never documented in the library reference, nor in the > docstrings in libre.tex; it was an underlying implementation detail > some people happened to take advantage of. If /F wants to add it in > order to be nice, fine; I certainly wouldn't bother to do that. I'm feel nice today. it'll be in the next release. From tim_one at email.msn.com Sat Jul 8 19:02:06 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 13:02:06 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <14695.11454.283571.492775@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > The URL I posted has a pointer to a copy of the "Final Committee > Draft," [for C9X] which is probably sufficient. PDF and PostScript > were both available. Worth repeating: http://lglwww.epfl.ch/~wolf/c/c9x_changes.html PDF and plain-text versions can be gotten from http://wwwold.dkuug.dk/jtc1/sc22/open/n2794/ These are much better than the things I was working from (don't tell, but since I knew some of the people on the committee, I went rummaging around their home pages looking for committee working docs). "whatever-it-takes"-is-pythonic-ly y'rs - tim From paul at prescod.net Sat Jul 8 19:01:24 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 08 Jul 2000 12:01:24 -0500 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> Message-ID: <39675E64.305A6B8@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Sorry, but I'm really surprised now: I've put many hours of > work into this, hacked up encoding support for locale.py, > went through endless discussions, proposed the changable default > as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy > ... and now all it takes is one single posting to render all that > work useless ??? I thought that the compromise was ASCII. Having the default be changable could lead to defacto forks in that language. I, for one, am sorry I didn't say something earlier but as Greg said, the changable default sort of drifted from something that was useful for testing to something we started making design decisions based upon. I thought I had missed a decision somewhere along the line to make it a permanent feature. Also, as I said, a changable default is probably worth considering for I/O boundaries. If 90% of the text on a Japanese user's computer is in Shift-JIS, then things like .rc and .ini files should be in that encoding. Or they could be in XML and the XML parser could handle encoding issues for you... Here's the central point: How can we write code if we don't know whether "..."+u"..." is going to trigger a UnicodeException because of some environment variable a user has set? To be safe, we need to specify the encoding explicitly....which renders auto-coercion useless. I am trying to be constructive, but I see the hash value problem as being unrelated to this very basic point. First and foremost, coercion has to be predictable. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From fdrake at beopen.com Sat Jul 8 19:11:03 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 13:11:03 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: References: <14695.11454.283571.492775@cj42289-a.reston1.va.home.com> Message-ID: <14695.24743.906316.151151@cj42289-a.reston1.va.home.com> Tim Peters writes: > Worth repeating: > > http://lglwww.epfl.ch/~wolf/c/c9x_changes.html ... > These are much better than the things I was working from (don't tell, but > since I knew some of the people on the committee, I went rummaging around > their home pages looking for committee working docs). And to think that first link was just the first thing that Google listed. ;) It is nice -- I found that before and it was nicer than a lot of the other C9X pages I looked at. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gmcm at hypernet.com Sat Jul 8 19:19:13 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 8 Jul 2000 13:19:13 -0400 Subject: [Python-Dev] C coding style In-Reply-To: References: <14695.11655.433199.734714@cj42289-a.reston1.va.home.com> Message-ID: <1249045739-16239476@hypernet.com> > [Tim] > > Fred, you appear to be 4-space indenting C source. Is that > > allowed? Last I think I heard, Guido was still clinging to his > > schizophrenia on this topic (4-space for .py and no hard tabs, > > 8-space for .c/.h and hard tabs). Blah blah blah. Jeez, guys. The following options will make indent produce something that's so close to Guido's style, he'd probably never notice that it's not exactly his style: -br -bap -nce -ss -i8 -ci8 -lp -ts8 -psl -npcs -nbc -ip8 -ncs -nfca why-be-anal-when-the-computer-can-do-it-for-you-ly y'rs - Gordon From petersc at stud.ntnu.no Sat Jul 8 21:27:50 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Sat, 08 Jul 2000 19:27:50 +0000 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix Message-ID: <396780B6.67247E2C@stud.ntnu.no> I am trying to fix the duplicate argument bug in the compiler. [example] >>> def f(a,a): print a ... >>> f(1,2) 2 [/example] My problem is that I get a segfault whenever I try to raise an com_error from com_arglist. I have attached a very short patch. Thanks for any hint, Peter P.S.: Is this on topic for python-dev? If not, where should I send such a request? -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de -------------- next part -------------- diff -c -d -T --recursive python/dist/src/Python/compile.c python-mod/dist/src/Python/compile.c *** python/dist/src/Python/compile.c Mon Jul 3 21:39:47 2000 --- python-mod/dist/src/Python/compile.c Sat Jul 8 19:13:42 2000 *************** *** 3102,3109 **** name = nbuf; sprintf(nbuf, ".%d", i); complex = 1; } ! com_newlocal(c, name); c->c_argcount++; if (++i >= nch) break; --- 3103,3120 ---- name = nbuf; sprintf(nbuf, ".%d", i); complex = 1; + } + + nameval = PyString_InternFromString(name); + if (nameval == NULL) { + c->c_errors++; } ! if (PyDict_GetItem(c->c_locals, nameval)) { ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); ! } ! com_newlocal_o(c, nameval); ! Py_DECREF(nameval); ! c->c_argcount++; if (++i >= nch) break; From fdrake at beopen.com Sat Jul 8 19:37:21 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 13:37:21 -0400 (EDT) Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix In-Reply-To: <396780B6.67247E2C@stud.ntnu.no> References: <396780B6.67247E2C@stud.ntnu.no> Message-ID: <14695.26321.650518.552363@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > P.S.: Is this on topic for python-dev? If not, where should > I send such a request? *I* think this is a good place for this. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From effbot at telia.com Sat Jul 8 21:12:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 21:12:45 +0200 Subject: [Python-Dev] changing the locale.py interface? Message-ID: <00c901bfe910$836758c0$f2a6b5d4@hagrid> http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100765&group_id=5470 Patch #100765 tightens up the new parts of the locale.py interface, and adds support for platform-dependent locale mechanisms. Here's a summary of the changes: - merged setlocale and set_locale. the internal setlocale function is overridden by a python version which accepts *either* a string (old behaviour) or a locale tuple. - renamed a few methods (for consistency): get_locale => getlocale get_default_locale => getdefaultlocale set_to_default => resetlocale (!) - the _locale implementation module can now implement an optional _getdefaultlocale function. if that function isn't available, a POSIX-based approach is used (check LANG and other environment variables). comments? From thomas at xs4all.net Sat Jul 8 21:21:50 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 8 Jul 2000 21:21:50 +0200 Subject: [Python-Dev] Include/pyport.h now exists In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 08, 2000 at 12:31:27AM -0400 References: Message-ID: <20000708212149.P26534@xs4all.nl> On Sat, Jul 08, 2000 at 12:31:27AM -0400, Tim Peters wrote: > Would someone who understands (& can test! I can't yet) autoconfig please > follow up on the last part? The stuff I checked in "fails safe", i.e. the > lack of autoconfig support should not cause problems on any of your > platforms. Can't say I understand all of autoconf but I read enough of the info pages to be able to do this ! :-) I couldn't find an existing test that covers this, so I used your example to make one; patch attached. It detects my linux box properly as 'doesn't zero-fill when right-shifting a negative number', but I haven't a Cray J90 handy to test the opposite ;) Feel free to change the wording to something a bit less... wordy, though ;) Oh, and don't forget to run autoheader & automake before checking in. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- *** src-lm+rm/configure.in Wed Jul 5 12:38:09 2000 --- src/configure.in Sat Jul 8 20:18:35 2000 *************** *** 1136,1141 **** --- 1136,1154 ---- # check for endianness AC_C_BIGENDIAN + # Check whether signed-right-shift fills the left hand bits with the sign + # bit, or with zero (like the Cray J90 does, according to Tim Peters.) + signed_rshift_0fills="unknown" + AC_MSG_CHECKING(whether right-shift of negative number pads with zeros) + AC_TRY_RUN([ + int main() + { + exit(((-1)>>3 == -1) ? 1 : 0); + } + ],AC_DEFINE(SIGNED_RIGHT_SHIFT_ZERO_FILLS) signed_rshift_0fills="yes", + signed_rshift_0fills="no") + AC_MSG_RESULT($signed_rshift_0fills) + # THIS MUST BE LAST, IT CAN BREAK OTHER TESTS! # Add sys/socket.h to confdefs.h cat >> confdefs.h <<\EOF From barry at scottb.demon.co.uk Sat Jul 8 21:31:37 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sat, 8 Jul 2000 20:31:37 +0100 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe In-Reply-To: Message-ID: <000801bfe913$224c9d40$060210ac@private> The C++ comments are in the original source. I'm happy to use any style if that makes it easier to get patches accepted. BArry > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Tim Peters > Sent: 08 July 2000 16:29 > To: Fredrik Lundh; Barry Scott; PythonDev > Subject: RE: [Python-Dev] Fix to allow os.popen to work from pythonw.exe > > > [/F] > > +1 from me. > > > > unless mark|bill|trent|.+ objects, I'll check it in later. > > > > cheers /F > > > > PS. I've uploaded it to the SF patch manager: > > http://sourceforge.net/patch/index.php?patch_id=100764&group_id=5470 > > Where I assigned it to you, but didn't accept it for sytle reasons: > > Assigned to effbot. I would have changed the status to > accepted, except the coding style is one Guido won't accept: > uses C++ comments in places, "if" braces in the wrong places, > "extra" whitespace at each end of arglists, "if(" instead of > "if (". > > I expect that arguing about style is futile. > > not-to-mention-a-waste-of-time-ly y'rs - tim > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From billtut at microsoft.com Sat Jul 8 22:03:17 2000 From: billtut at microsoft.com (Bill Tutt) Date: Sat, 8 Jul 2000 13:03:17 -0700 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD296@RED-MSG-50> Ah, yes, the dreaded popen bug. A) If you really want to fix the problem everywhere then create a patch to popen for windows only that uses the code from the win32popen.cpp code. It includes code to handle Windows 9x as well. Not to mention the fact that this patch doesn't fix os.popen() in the following case: C/C++/whatever language binary that is a GUI app (windows subsystem) that embeds Python. (aka PythonWin.exe) The win32popen.cpp code works for all platforms and all cases, so a big -1 on this patch since it isn't doesn't handle all cases for the platforms the patch does work on. B) The -1's below really should be: INVALID_HANDLE_VALUE ! if (_get_osfhandle(0) == -1) ! dup2(null_file, 0); ! ! if (_get_osfhandle(1) == -1) ! dup2(null_file, 1); ! ! if (_get_osfhandle(2) == -1) ! dup2(null_file, 2); ! ! close(null_file); ! ! return Py_Main(__argc, __argv); } Wishing he could throttle the person who wrote popen in the CRT, Bill p.s. Just to clarify: Win32popen.cpp is all of the real work. Win32popenWin9x.* is the Win9x helper .exe so that you can use popen. <> <> <> begin 600 win32popen.cpp M(VEN8VQU9&4@(G=I;F1O=W,N:"(-"@T*+R\@0&1O8PT*#0HC:6YC;'5D92`B M4'ET:&]N+F at B#0HC:6YC;'5D92`B;6%L;&]C+F at B#0HC:6YC;'5D92`B:6\N M:"(-"B-I;F-L=61E(")F8VYT;"YH(@T*(VEN8VQU9&4@(E!Y5VEN5'EP97,N M:"(-"@T*(V1E9FEN92!$;&Q%>'!O'1EDUO9'5L95!A=&A;73L)#0H-"B\O(%1H97-E('1E;&P at 7U!Y4&]P96XH M*2!W971H97(@=&\@PT*"6-H87(@*F-M9'-T4]B:F5C="`J9BPJ M4%R9U]087)S951U<&QE*&%R M9W,L(")S?',Z<&]P96XB+`T*"0D)"0D)("`F8VUDPT*"0E0>45R&-?5F%L M=65%5!O<&5N*&-M9'-T M5!O<&5N*&-M9'-T4]B:F5C="`J4'E0;W!E;C(H4'E/8FIE8W0@*G-E;&8L M(%!Y3V)J96-T("`J87)G45X8U]686QU M945R4]B:F5C="`@*F%R9W,I#0I[#0H)8VAAPT*"0E0>45R&-?5F%L M=65%4]B:F5C="`@*F%R9W,I M#0I[#0H)8VAAPT* M"0E0>45R&-?5F%L=65%D-O;G-O;&53<&%W;B`](")W:6XS,G!O<&5N5VEN.7 at N97AE M(%PB(CL-"@EI;G0@:3L-"@EI;G0@>#L-"@T*"6EF("AI(#T at 1V5T16YV:7)O M;FUE;G1687)I86)L92 at B0T]-4U!%0R(L3E5,3"PP*2D-"B`@("![#0H)"7,Q M(#T@*&-H87(@*BE?86QL;V-A*&DI.PT*"0EI9B`H(2AX(#T at 1V5T16YV:7)O M;FUE;G1687)I86)L92 at B0T]-4U!%0R(L(',Q+"!I*2DI#0H)"0ER971U#L-"@D):68@*"%G7V952AS,BP@>"D[#0H) M"0ES<')I;G1F*`T*"0D)"7,R+`T*"0D)"2(E2!C;60N97AE("\@8V]M;6%N M9"YC;VT@:6X@=&AE('!A=&@-"@DO+R!.;W<@=V4G;&P@:G5S="!EF5O9BA35$%25%5024Y&3RDI.PT*"7-I4W1APT*"0DO+R!#;&]S92!T:&4@ M:&%N9&QE4]B:F5C="`J M7U!Y4&]P96XH8VAAF5O9BA314-54DE465]!5%1224)55$53*3L-"@ES84%T='(N M8DEN:&5R:71(86YD;&4@/2!44E5%.PT*"7-A071T5=I;E]3971! M4$E%PT*"0EC87-E(%]/7U=2 M3TY,62!\(%]/7U1%6%0Z#0H)"0DO+R!#87-E(&9O'0@;6]D92X-"@D)"69D,2`](%]O<&5N7V]S9FAA M;F1L92 at H;&]N9REH0VAI;&13=&1I;E=R1'5P+"!M;V1E*3L-"@D)"68Q(#T@ M7V9D;W!E;BAF9#$L(")W(BD[#0H)"0EF(#T at 4'E&:6QE7T9R;VU&:6QE*&8Q M+"!C;61S=')I;F49I;&5?1G)O;49I;&4H9C$L(&-M M9'-TF4H M9BP@,"D[#0H)"0DO+R!792!D;VXG="!C87)E(&%B;W5T('1H97-E('!I<&5S M(&%N>6UO2!M;V1E+ at T*"0D)9F0Q(#T at 7V]P96Y?;W-F:&%N9&QE*"AL M;VYG*6A#:&EL9%-T9&EN5W)$=7`L(&UO9&4I.PT*"0D)9C$@/2!?9F1O<&5N M*&9D,2P@(G=B(BD[#0H)"0EF(#T at 4'E&:6QE7T9R;VU&:6QE*&8Q+"!C;61S M=')I;F49I;&5?4V5T0G5F4VEZ92AF M+"`P*3L-"@D)"2\O(%=E(&1O;B=T(&-APT*"2`@("!C:&%R("IM,2P@*FTR M.PT*"2`@("!0>4]B:F5C="`J<#$L("IP,CL-"@D@("`@#0H)("`@(&EF("AM M;V1E("8F(%]/7U1%6%0I#0H)"7L-"@D)"6TQ/2)R(CL-"@D)"6TR/2)W(CL- M"@D)?0T*"2`@("!E;'-E#0H)"7L-"@D)"6TQ/2)R8B([#0H)"0EM,CTB=V(B M.PT*"0E]#0H-"@D@("`@9F0Q(#T at 7V]P96Y?;W-F:&%N9&QE*"AL;VYG*6A# M:&EL9%-T9&EN5W)$=7`L(&UO9&4I.PT*"2`@("!F,2`](%]F9&]P96XH9F0Q M+"!M,BD[#0H)("`@(&9D,B`](%]O<&5N7V]S9FAA;F1L92 at H;&]N9REH0VAI M;&13=&1O=7129$1U<"P@;6]D92D[#0H)("`@(&8R(#T at 7V9D;W!E;BAF9#(L M(&TQ*3L-"@D@("`@<#$@/2!0>49I;&5?1G)O;49I;&4H9C$L(&-M9'-T49I;&5?1G)O;49I;&4H9C(L(&-M9'-T5]"=6EL9%9A;'5E*")/3R(L<#$L<#(I.PT* M"2`@("!B49I;&5? M1G)O;49I;&4H9C(L(&-M9'-TF4H<#,L(#`I.PT* M"2`@("!F(#T at 4'E?0G5I;&1686QU92 at B3T]/(BQP,2QP,BQP,RD[#0H)("`@ M(&)R96%K.PT*"7T-"@E]#0H-"@EI9B`H;B`]/2!03U!%3E\T*0T*"7L-"@D) M:68@*"%?4'E0;W!E;D-R96%T95!R;V-E2!T M:&4 at 8VAI;&0@2&%N9&QE(BD[#0H-"@ER971U71H;VX@=VEN,S)P:7!E(&UO9'5L95QN(@T*(G1O('=O M"X@($ET(&ES M7&XB#0HB;F]T(&1EPT*"2`@ M($UEF5O9BAS:2D[#0H@("!S:2YD=T9L86=S("`@(#T at 4U1!4E1&7U5315-41$A! M3D1,15,[#0H@("!S:2YH4W1D26YP=70@(#T at 1V5T4W1D2&%N9&QE("A35$1? M24Y0551?2$%.1$Q%*3L-"B`@('-I+FA3=&1/=71P=70@/2!'9713=&1(86YD M;&4@*%-41%]/5510551?2$%.1$Q%*3L-"B`@('-I+FA3=&1% Ah, yes, the dreaded popen bug. A) If you really want to fix the problem everywhere then create a patch to popen for windows only that uses the code from the win32popen.cpp code. It includes code to handle Windows 9x as well. Not to mention the fact that this patch doesn't fix os.popen() in the following case: C/C++/whatever language binary that is a GUI app (windows subsystem) that embeds Python. (aka PythonWin.exe) The win32popen.cpp code works for all platforms and all cases, so a big -1 on this patch since it isn't doesn't handle all cases for the platforms the patch does work on. B) The -1's below really should be: INVALID_HANDLE_VALUE ! if (_get_osfhandle(0) == -1) ! dup2(null_file, 0); ! ! if (_get_osfhandle(1) == -1) ! dup2(null_file, 1); ! ! if (_get_osfhandle(2) == -1) ! dup2(null_file, 2); ! ! close(null_file); ! ! return Py_Main(__argc, __argv); } Wishing he could throttle the person who wrote popen in the CRT, Bill p.s. Just to clarify: Win32popen.cpp is all of the real work. Win32popenWin9x.* is the Win9x helper .exe so that you can use popen. <> <> <> begin 600 win32popen.cpp M(VEN8VQU9&4@(G=I;F1O=W,N:"(-"@T*+R\@0&1O8PT*#0HC:6YC;'5D92`B M4'ET:&]N+F at B#0HC:6YC;'5D92`B;6%L;&]C+F at B#0HC:6YC;'5D92`B:6\N M:"(-"B-I;F-L=61E(")F8VYT;"YH(@T*(VEN8VQU9&4@(E!Y5VEN5'EP97,N M:"(-"@T*(V1E9FEN92!$;&Q%>'!O'1EDUO9'5L95!A=&A;73L)#0H-"B\O(%1H97-E('1E;&P at 7U!Y4&]P96XH M*2!W971H97(@=&\@PT*"6-H87(@*F-M9'-T4]B:F5C="`J9BPJ M4%R9U]087)S951U<&QE*&%R M9W,L(")S?',Z<&]P96XB+`T*"0D)"0D)("`F8VUDPT*"0E0>45R&-?5F%L M=65%5!O<&5N*&-M9'-T M5!O<&5N*&-M9'-T4]B:F5C="`J4'E0;W!E;C(H4'E/8FIE8W0@*G-E;&8L M(%!Y3V)J96-T("`J87)G45X8U]686QU M945R4]B:F5C="`@*F%R9W,I#0I[#0H)8VAAPT*"0E0>45R&-?5F%L M=65%4]B:F5C="`@*F%R9W,I M#0I[#0H)8VAAPT* M"0E0>45R&-?5F%L=65%D-O;G-O;&53<&%W;B`](")W:6XS,G!O<&5N5VEN.7 at N97AE M(%PB(CL-"@EI;G0@:3L-"@EI;G0@>#L-"@T*"6EF("AI(#T at 1V5T16YV:7)O M;FUE;G1687)I86)L92 at B0T]-4U!%0R(L3E5,3"PP*2D-"B`@("![#0H)"7,Q M(#T@*&-H87(@*BE?86QL;V-A*&DI.PT*"0EI9B`H(2AX(#T at 1V5T16YV:7)O M;FUE;G1687)I86)L92 at B0T]-4U!%0R(L(',Q+"!I*2DI#0H)"0ER971U#L-"@D):68@*"%G7V952AS,BP@>"D[#0H) M"0ES<')I;G1F*`T*"0D)"7,R+`T*"0D)"2(E2!C;60N97AE("\@8V]M;6%N M9"YC;VT@:6X@=&AE('!A=&@-"@DO+R!.;W<@=V4G;&P@:G5S="!EF5O9BA35$%25%5024Y&3RDI.PT*"7-I4W1APT*"0DO+R!#;&]S92!T:&4@ M:&%N9&QE4]B:F5C="`J M7U!Y4&]P96XH8VAAF5O9BA314-54DE465]!5%1224)55$53*3L-"@ES84%T='(N M8DEN:&5R:71(86YD;&4@/2!44E5%.PT*"7-A071T5=I;E]3971! M4$E%PT*"0EC87-E(%]/7U=2 M3TY,62!\(%]/7U1%6%0Z#0H)"0DO+R!#87-E(&9O'0@;6]D92X-"@D)"69D,2`](%]O<&5N7V]S9FAA M;F1L92 at H;&]N9REH0VAI;&13=&1I;E=R1'5P+"!M;V1E*3L-"@D)"68Q(#T@ M7V9D;W!E;BAF9#$L(")W(BD[#0H)"0EF(#T at 4'E&:6QE7T9R;VU&:6QE*&8Q M+"!C;61S=')I;F49I;&5?1G)O;49I;&4H9C$L(&-M M9'-TF4H M9BP@,"D[#0H)"0DO+R!792!D;VXG="!C87)E(&%B;W5T('1H97-E('!I<&5S M(&%N>6UO2!M;V1E+ at T*"0D)9F0Q(#T at 7V]P96Y?;W-F:&%N9&QE*"AL M;VYG*6A#:&EL9%-T9&EN5W)$=7`L(&UO9&4I.PT*"0D)9C$@/2!?9F1O<&5N M*&9D,2P@(G=B(BD[#0H)"0EF(#T at 4'E&:6QE7T9R;VU&:6QE*&8Q+"!C;61S M=')I;F49I;&5?4V5T0G5F4VEZ92AF M+"`P*3L-"@D)"2\O(%=E(&1O;B=T(&-APT*"2`@("!C:&%R("IM,2P@*FTR M.PT*"2`@("!0>4]B:F5C="`J<#$L("IP,CL-"@D@("`@#0H)("`@(&EF("AM M;V1E("8F(%]/7U1%6%0I#0H)"7L-"@D)"6TQ/2)R(CL-"@D)"6TR/2)W(CL- M"@D)?0T*"2`@("!E;'-E#0H)"7L-"@D)"6TQ/2)R8B([#0H)"0EM,CTB=V(B M.PT*"0E]#0H-"@D@("`@9F0Q(#T at 7V]P96Y?;W-F:&%N9&QE*"AL;VYG*6A# M:&EL9%-T9&EN5W)$=7`L(&UO9&4I.PT*"2`@("!F,2`](%]F9&]P96XH9F0Q M+"!M,BD[#0H)("`@(&9D,B`](%]O<&5N7V]S9FAA;F1L92 at H;&]N9REH0VAI M;&13=&1O=7129$1U<"P@;6]D92D[#0H)("`@(&8R(#T at 7V9D;W!E;BAF9#(L M(&TQ*3L-"@D@("`@<#$@/2!0>49I;&5?1G)O;49I;&4H9C$L(&-M9'-T49I;&5?1G)O;49I;&4H9C(L(&-M9'-T5]"=6EL9%9A;'5E*")/3R(L<#$L<#(I.PT* M"2`@("!B49I;&5? M1G)O;49I;&4H9C(L(&-M9'-TF4H<#,L(#`I.PT* M"2`@("!F(#T at 4'E?0G5I;&1686QU92 at B3T]/(BQP,2QP,BQP,RD[#0H)("`@ M(&)R96%K.PT*"7T-"@E]#0H-"@EI9B`H;B`]/2!03U!%3E\T*0T*"7L-"@D) M:68@*"%?4'E0;W!E;D-R96%T95!R;V-E2!T M:&4 at 8VAI;&0@2&%N9&QE(BD[#0H-"@ER971U71H;VX@=VEN,S)P:7!E(&UO9'5L95QN(@T*(G1O('=O M"X@($ET(&ES M7&XB#0HB;F]T(&1EPT*"2`@ M($UEF5O9BAS:2D[#0H@("!S:2YD=T9L86=S("`@(#T at 4U1!4E1&7U5315-41$A! M3D1,15,[#0H@("!S:2YH4W1D26YP=70@(#T at 1V5T4W1D2&%N9&QE("A35$1? M24Y0551?2$%.1$Q%*3L-"B`@('-I+FA3=&1/=71P=70@/2!'9713=&1(86YD M;&4@*%-41%]/5510551?2$%.1$Q%*3L-"B`@('-I+FA3=&1% Oops, silly outlook. I need to get around to writing that VBA macro that warns me if the attachment encoding isn't specified. Ugh. If anybody out there can't get the uuencoded version to decode in their mailer the files are at: http://lima.mudlib.org/~rassilon/popen Bill From barry at scottb.demon.co.uk Sat Jul 8 22:37:04 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sat, 8 Jul 2000 21:37:04 +0100 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD296@RED-MSG-50> Message-ID: <001301bfe91c$46ddcb80$060210ac@private> Bill, Your code is a far better solution. > B) The -1's below really should be: INVALID_HANDLE_VALUE Check with the implementation and MSDN you will see that the return type is long and the error condition is -1. INVALID_HANDLE_VALUE is not of type long and will give a compile warning C4047. Barry From effbot at telia.com Sat Jul 8 22:52:21 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 22:52:21 +0200 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD296@RED-MSG-50> Message-ID: <016a01bfe91e$6a6ecc00$f2a6b5d4@hagrid> bill wrote: > A) If you really want to fix the problem everywhere then create a > patch to popen for windows only that uses the code from the > win32popen.cpp code. It includes code to handle Windows 9x as > well. excellent! I'll take over from here. From billtut at microsoft.com Sat Jul 8 22:54:36 2000 From: billtut at microsoft.com (Bill Tutt) Date: Sat, 8 Jul 2000 13:54:36 -0700 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD299@RED-MSG-50> Heh, if the CRT really returns a long from the get OS handle function, then its typed wrong. :) For Win32 sizeof(HANDLE) == sizeof(long), that isn't the case for Win64. Bill -----Original Message----- From: Barry Scott [mailto:barry at scottb.demon.co.uk] Sent: Saturday, July 08, 2000 1:37 PM To: Bill Tutt; python-dev at python.org Subject: RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 Bill, Your code is a far better solution. > B) The -1's below really should be: INVALID_HANDLE_VALUE Check with the implementation and MSDN you will see that the return type is long and the error condition is -1. INVALID_HANDLE_VALUE is not of type long and will give a compile warning C4047. Barry From effbot at telia.com Sat Jul 8 23:04:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 23:04:19 +0200 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD296@RED-MSG-50> Message-ID: <019501bfe920$18cee220$f2a6b5d4@hagrid> bill wrote: > Just to clarify: > Win32popen.cpp is all of the real work. > Win32popenWin9x.* is the Win9x helper .exe so that you can use popen. stupid question: what exactly does the RC file do here: STRINGTABLE DISCARDABLE BEGIN 2000 "Dummy" // Needed to version branding works! END (couldn't really parse that comment ;-) From guido at beopen.com Sun Jul 9 00:06:06 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 17:06:06 -0500 Subject: [Python-Dev] Encodings In-Reply-To: Your message of "Sat, 08 Jul 2000 18:05:16 +0200." <3967513C.BAF459FB@lemburg.com> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> Message-ID: <200007082206.RAA08314@cj20424-a.reston1.va.home.com> > Guido van Rossum wrote: > > I couldn't have said it better. It's okay for now to have it > > changeable at the C level -- with endless caveats that it should be > > set only once before any use, and marked as an experimental feature. > > But the Python access and the reliance on the environment should go. [MAL replies] > Sorry, but I'm really surprised now: I've put many hours of > work into this, hacked up encoding support for locale.py, > went through endless discussions, proposed the changable default > as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy > ... and now all it takes is one single posting to render all that > work useless ??? I'm sorry too. As Fred Drake explained, the changeable default was an experiment. I won't repeat his excellent response. I am perhaps to blame for the idea that the character set of 8-bit strings in C can be derived in some whay from the locale -- but the main reason I brought it up was as a counter-argument to the Latin-1 fixed default that effbot arged for. I never dreamed that you could actually find out the name of the character set given the locale! > Instead of tossing things we should be *constructive* and come > up with a solution to the hash value problem, e.g. I would > like to make the hash value be calculated from the UTF-16 > value in a way that is compatible with ASCII strings. I think you are proposing to drop the following rule: if a == b then hash(a) == hash(b) or also if hash(a) != hasb(b) then a != b This is very fundamental for dictionaries! Note that it is currently broken: >>> d = {'\200':1} >>> d['\200'] 1 >>> u'\200' == '\200' 1 >>> d[u'\200'] Traceback (most recent call last): File "", line 1, in ? KeyError: ? >>> While you could fix this with a variable encoding, it would be very hard, probably involving the string to Unicode before taking its hash, and this would slow down the hash calculation for 8-bit strings considerably (and these are fundamental for the speed of the language!). So I am for restoring ASCII as the one and only fixed encoding. (Then you can fix your hash much easier!) Side note: the KeyError handling is broken. The bad key should be run through repr() (probably when the error is raised than when it is displayed). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Sun Jul 9 00:09:52 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 17:09:52 -0500 Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: Your message of "Sat, 08 Jul 2000 11:36:32 -0400." References: Message-ID: <200007082209.RAA08356@cj20424-a.reston1.va.home.com> > [Fred] > > I seem to recall that Guido had caved on this, mostly because he > > received enough complaints about too much code getting shoved way over > > to the right, in a column a dozen of fewer characters wide (which is > > seriously hard to decode). I don't remember if this was on the list > > or in a meeting. > > If I'm mis-remembering, then we should presure him on this until he > > does cave. ;) [Tim] > Guido, you need to Pronounce on this! > > I personally prefer 4-space no-hard-tabs everywhere, but given the way most > editors work, the most important thing is that there's no variation within a > given file type (e.g., that all .c files do the same, and all .py files do > the same, but it's bearable for .c and .py files to differ -- which latter > has been the case until now). Sorry, I still like -s8 -t8 for C code best. Just like the Linux kernel, if someone asks. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Sun Jul 9 00:19:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 17:19:02 -0500 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: Your message of "Sat, 08 Jul 2000 10:34:16 EST." <396749F8.F98D2F8C@prescod.net> References: <396749F8.F98D2F8C@prescod.net> Message-ID: <200007082219.RAA08379@cj20424-a.reston1.va.home.com> I don't know what to do about this, but Neil H's point that we might want to separate the operational issues from the deep discussions makes some sense. Maybe there's even room for three lists: operational, current code and patches, and future features. But in reality, the difference between the various lists isn't the topic: it's the group of people. The fact that people are only allowed into python-dev based on merit etc. (really a process of co-optation) makes a difference: I feel much more comfortable discussing both operational issues and future features here than I do in the general newsgroup, because I approximately know my audience. When posting to c.l.py these days I usually feel a lot of pressure about how my writings will be perceived by newbies, critics, members of other cultures, the press, and so on. Sure, they can read the python-dev archives, but few do, and (except for Gerrit Holl) I haven't had any feedback from outsiders to posts made here. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From effbot at telia.com Sat Jul 8 23:24:53 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 23:24:53 +0200 Subject: [Python-Dev] new popen for win32! Message-ID: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> just a few questions before I prepare the patch... - first, a stupid question: is the popen2 and popen3 versions replacements for the corresponding functions in the popen2 module. (or to put it another way: should the popen2 module be modified to use these functions on Windows?) - should this go into the "nt" (posix) module, or should I create a new module? - "win32popenWin9x.exe" is a rather unwieldy name for a file. does anyone have a better suggestion? python_popen.exe py_popen9x.exe popenStub.exe ...? - I'm using VC5 on this box, so I should probably avoid checking in my modified project files. any VC6-wielding volunteers out there? From effbot at telia.com Sat Jul 8 23:33:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 23:33:19 +0200 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <200007082206.RAA08314@cj20424-a.reston1.va.home.com> Message-ID: <01d901bfe924$26b42d60$f2a6b5d4@hagrid> guido wrote: > I am perhaps to blame for the idea that the character set of 8-bit > strings in C can be derived in some whay from the locale -- but the > main reason I brought it up was as a counter-argument to the Latin-1 > fixed default that effbot arged for. note that this work isn't exactly wasted; the default encoding mechanisms can (and should) be used to handle unicode args to system API's like open (etc). we just have to figure out how to design the internal API's. cannot be that hard, can it? > I never dreamed that you could actually find out the name of the > character set given the locale! never underestimate the malbot. (btw, this magic now works on windows too! ;-) >>> import locale >>> print locale.getdefaultlocale() ('sv_SE', 'cp1252') From gmcm at hypernet.com Sat Jul 8 23:42:11 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 8 Jul 2000 17:42:11 -0400 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <200007082219.RAA08379@cj20424-a.reston1.va.home.com> References: Your message of "Sat, 08 Jul 2000 10:34:16 EST." <396749F8.F98D2F8C@prescod.net> Message-ID: <1249029961-17188506@hypernet.com> [Guido] > I don't know what to do about this, but Neil H's point that we > might want to separate the operational issues from the deep > discussions makes some sense. Maybe there's even room for three > lists: operational, current code and patches, and future > features. > > But in reality, the difference between the various lists isn't > the topic: it's the group of people. There are at least 3 and maybe 6 or more of us who still read c.l.py (though I've dropped back to newsgroup so I can skip the braindead threads). As a partial solution, perhaps we could use some self-discipline and sometimes say "kick it to c.l.py". I, for one, would be willing to _help_ (not "assume responsibility for"!) monitoring threads of this sort and summarizing back to the dev list. For ideas on which Guido is > -0, I think this might be a good way to guage reaction. - Gordon From thomas at xs4all.net Sun Jul 9 00:01:36 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 00:01:36 +0200 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <1249029961-17188506@hypernet.com>; from gmcm@hypernet.com on Sat, Jul 08, 2000 at 05:42:11PM -0400 References: <396749F8.F98D2F8C@prescod.net> <200007082219.RAA08379@cj20424-a.reston1.va.home.com> <1249029961-17188506@hypernet.com> Message-ID: <20000709000135.Q26534@xs4all.nl> On Sat, Jul 08, 2000 at 05:42:11PM -0400, Gordon McMillan wrote: > There are at least 3 and maybe 6 or more of us who still read > c.l.py (though I've dropped back to newsgroup so I can skip > the braindead threads). As a partial solution, perhaps we > could use some self-discipline and sometimes say "kick it to > c.l.py". I, for one, would be willing to _help_ (not "assume > responsibility for"!) monitoring threads of this sort and > summarizing back to the dev list. Agreed, though I think it should go the other way, too. And it isn't just about discussing new features or bugs; people, or at least involved people, like to see that there are actually people working on improving Python ;) Whether it's a new feature, a bugfix, a radical or a subtle change, whether it leads to anything or not, they like to see Python isn't dead ;) The deminishing number of 'core developers' posting in c.l.py was one of the reasons I started reading the python-dev archives, anyway. The problem with making python-dev more accessible is that it makes python-dev more accessible, as well ;-P As Guido said, he hardly gets any non-python-dev responses to python-dev postings, and that's pretty understandable. The step from reading something in the web-based archives and replying to them is pretty large. It isn't impossible (I've responded to something I saw in the archives a few times, though not directly to Go--ehr, Guido ;) but it definately helps lessen the responses. Anyway, I try to keep up with python-list and python-dev both, so I'll help with occasionally gatewaying things ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Sun Jul 9 01:24:16 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 18:24:16 -0500 Subject: [Python-Dev] Encodings In-Reply-To: Your message of "Sat, 08 Jul 2000 23:33:19 +0200." <01d901bfe924$26b42d60$f2a6b5d4@hagrid> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <200007082206.RAA08314@cj20424-a.reston1.va.home.com> <01d901bfe924$26b42d60$f2a6b5d4@hagrid> Message-ID: <200007082324.SAA08736@cj20424-a.reston1.va.home.com> > > I never dreamed that you could actually find out the name of the > > character set given the locale! > > never underestimate the malbot. > > (btw, this magic now works on windows too! ;-) > > >>> import locale > >>> print locale.getdefaultlocale() > ('sv_SE', 'cp1252') That seems actually pretty useful for explicit conversions! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Sun Jul 9 01:34:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 18:34:02 -0500 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix In-Reply-To: Your message of "Sat, 08 Jul 2000 19:27:50 GMT." <396780B6.67247E2C@stud.ntnu.no> References: <396780B6.67247E2C@stud.ntnu.no> Message-ID: <200007082334.SAA08816@cj20424-a.reston1.va.home.com> > diff -c -d -T --recursive python/dist/src/Python/compile.c python-mod/dist/src/Python/compile.c > *** python/dist/src/Python/compile.c Mon Jul 3 21:39:47 2000 > --- python-mod/dist/src/Python/compile.c Sat Jul 8 19:13:42 2000 > *************** > *** 3102,3109 **** > name = nbuf; > sprintf(nbuf, ".%d", i); > complex = 1; > } > ! com_newlocal(c, name); > c->c_argcount++; > if (++i >= nch) > break; > --- 3103,3120 ---- > name = nbuf; > sprintf(nbuf, ".%d", i); > complex = 1; > + } > + > + nameval = PyString_InternFromString(name); > + if (nameval == NULL) { > + c->c_errors++; > } > ! if (PyDict_GetItem(c->c_locals, nameval)) { > ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); > ! } > ! com_newlocal_o(c, nameval); > ! Py_DECREF(nameval); > ! > c->c_argcount++; > if (++i >= nch) > break; > I get a compile error: nameval undeclared. Which version are you working off? Please use the SourceForge CVS tree! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From effbot at telia.com Sun Jul 9 00:59:39 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 00:59:39 +0200 Subject: [Python-Dev] Re: Patch #100752 - Make atoi work for negative bases Message-ID: <03af01bfe930$34e6b4a0$f2a6b5d4@hagrid> should this patch perhaps be rejected and/or postponed? http://sourceforge.net/patch/?func=detailpatch&patch_id=100752&group_id=5470 (iirc, guido was -1 on this one, right?) From petersc at stud.ntnu.no Sun Jul 9 04:28:33 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Sun, 09 Jul 2000 02:28:33 +0000 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix References: <396780B6.67247E2C@stud.ntnu.no> <200007082334.SAA08816@cj20424-a.reston1.va.home.com> Message-ID: <3967E351.826FE29F@stud.ntnu.no> Guido van Rossum wrote: > > I get a compile error: nameval undeclared. Which version are you > working off? Please use the SourceForge CVS tree! Oops. I forget one chunk of the patch which is related to the bugfix. By the way, I am using the CVS tree. It's just a 'PyObject *nameval;' declaration. I have attached a more complete patch. I still can't figure where the compiler segfaults. Good night (or good morning), Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de -------------- next part -------------- diff -c -d -T --recursive python/dist/src/Python/compile.c python-mod/dist/src/Python/compile.c *** python/dist/src/Python/compile.c Mon Jul 3 21:39:47 2000 --- python-mod/dist/src/Python/compile.c Sun Jul 9 02:04:26 2000 *************** *** 3092,3097 **** --- 3092,3098 ---- node *ch = CHILD(n, i); node *fp; char *name; + PyObject *nameval; if (TYPE(ch) == STAR || TYPE(ch) == DOUBLESTAR) break; REQ(ch, fpdef); /* fpdef: NAME | '(' fplist ')' */ *************** *** 3103,3109 **** sprintf(nbuf, ".%d", i); complex = 1; } ! com_newlocal(c, name); c->c_argcount++; if (++i >= nch) break; --- 3104,3118 ---- sprintf(nbuf, ".%d", i); complex = 1; } ! nameval = PyString_InternFromString(name); ! if (nameval == NULL) { ! c->c_errors++; ! } ! if (PyDict_GetItem(c->c_locals, nameval)) { ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); ! } ! com_newlocal_o(c, nameval); ! Py_DECREF(nameval); c->c_argcount++; if (++i >= nch) break; From fdrake at beopen.com Sun Jul 9 02:58:56 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 20:58:56 -0400 (EDT) Subject: [Python-Dev] Py_PROTO elimination in Include/ Message-ID: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com> I've removed Py_PROTO from the headers in the Include/ directory, with the exceptions of the my*.h headers. I'll leave it for others to fix those, merging with pyport.h as appropriate. I think I'll stop for a bite to eat. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein at lyra.org Sun Jul 9 03:10:28 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 8 Jul 2000 18:10:28 -0700 Subject: [Python-Dev] Re: Patch #100752 - Make atoi work for negative bases In-Reply-To: <03af01bfe930$34e6b4a0$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jul 09, 2000 at 12:59:39AM +0200 References: <03af01bfe930$34e6b4a0$f2a6b5d4@hagrid> Message-ID: <20000708181028.M29590@lyra.org> On Sun, Jul 09, 2000 at 12:59:39AM +0200, Fredrik Lundh wrote: > should this patch perhaps be rejected and/or postponed? > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100752&group_id=5470 > > (iirc, guido was -1 on this one, right?) "A polite, but firm, -1" is what he said. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jul 9 03:10:04 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 8 Jul 2000 18:10:04 -0700 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Sat, Jul 08, 2000 at 08:58:56PM -0400 References: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com> Message-ID: <20000708181004.L29590@lyra.org> On Sat, Jul 08, 2000 at 08:58:56PM -0400, Fred L. Drake, Jr. wrote: > > I've removed Py_PROTO from the headers in the Include/ directory, woo! Time to create that pydeprecated.h header and move Py_PROTO there :-) (for use by third-party modules) Good work, Fred! Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Sun Jul 9 03:51:05 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 21:51:05 -0400 Subject: [Python-Dev] Re: Patch #100752 - Make atoi work for negative bases In-Reply-To: <03af01bfe930$34e6b4a0$f2a6b5d4@hagrid> Message-ID: [/F] > should this patch perhaps be rejected and/or postponed? > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100752&group_id=5470 I see Guido rejected it. I saw that because I just logged in to reject it . From tim_one at email.msn.com Sun Jul 9 04:04:44 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 22:04:44 -0400 Subject: [Python-Dev] new popen for win32! In-Reply-To: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > just a few questions before I prepare the patch... > > - first, a stupid question: is the popen2 and popen3 > versions replacements for the corresponding functions > in the popen2 module. > > (or to put it another way: should the popen2 module > be modified to use these functions on Windows?) > > - should this go into the "nt" (posix) module, or should > I create a new module? It's hard to answer because I've forgotten how I *expected* things to work when I first moved to Windows. So, in an ass-backwards sense, that's the answer : if I "import os" and do os.popen, I expect it to work. Or, IOW, I expect the same popen-related code to work in the same ways via the same spelling regardless of OS. As is, I hardly ever use anything popen-related under Windows today because it usually craps out or hangs. There's no point to keeping Windows code around that doesn't work! > - "win32popenWin9x.exe" is a rather unwieldy name for a > file. does anyone have a better suggestion? > > python_popen.exe > py_popen9x.exe > popenStub.exe > > ...? Assuming this lives in Python's directories, no need to mention pyxxx. How about w9xpopen.exe Then it's an 8.3 name and will save mounds of directory space too . > - I'm using VC5 on this box, so I should probably avoid > checking in my modified project files. any VC6-wielding > volunteers out there? Tell me exactly what it is I'm volunteering for, and probably "yes". Certainly yes if you want me to "updgade" your VC5 .dsp/.dsw files to VC6 and mail 'em back to you, or to make the same changes in my VC6 files and check them in. From nhodgson at bigpond.net.au Sun Jul 9 04:30:49 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Sun, 9 Jul 2000 12:30:49 +1000 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] References: <396749F8.F98D2F8C@prescod.net> <200007082219.RAA08379@cj20424-a.reston1.va.home.com> Message-ID: <011d01bfe94d$b2fb7200$8119fea9@neil> Guido writes, > I feel much more comfortable > discussing both operational issues and future features here than I do > in the general newsgroup, because I approximately know my audience. > When posting to c.l.py these days I usually feel a lot of pressure > about how my writings will be perceived by newbies, critics, members > of other cultures, the press, and so on. I'd like to separate out the problem here. Is it that there is a need to keep politically damaging opinions private so the Python community is not seen to be disparaging some other project like Tk or Expat? Is it that it is more acceptable for you to make mistakes in front of a restricted audience? > Sure, they can read the > python-dev archives, but few do, and (except for Gerrit Holl) I > haven't had any feedback from outsiders to posts made here. How is the average Python user to learn of python-dev? I did know that python-dev existed before being invited on but had never been interested enough to find it. I just tried to find out about python-dev from the top level of python.org. Searched the Mailing Lists, Community and SIGs pages. Searched the FAQ. Even ran a search using the search page over the python.org web site with no relevant result. If it is desirable for more people to know about what happens on python-dev, then access to the archives should be made easier. My understanding is that currently anyone can write to python-dev but only invitees can subscribe. The inversion of the normal pattern of restricted mail list access does make some sense in allowing temporary inclusion of people involved in a discussion. But it denies outsiders the ability to sensibly read python-dev. Web archives are a poor imitation of a mail readers ability to filter threads and topics. The problem for me here is that knowledge of what is going to happen to Python is kept by the Python developers away from the Python users. Neil From tim_one at email.msn.com Sun Jul 9 05:22:13 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 23:22:13 -0400 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <011d01bfe94d$b2fb7200$8119fea9@neil> Message-ID: [Neil Hodgson] > ... > The problem for me here is that knowledge of what is going > to happen to Python is kept by the Python developers away from > the Python users. This is a bit funny, because users can know *much* more about what's coming up in Python now than they ever could in earlier days! The source tree, the patches, and the discussions are all there to be seen, for anyone who cares to make the effort. If users want to be spoon-fed, that's fine, but it's sure not my job to do that (albeit that it used to be a hobby of mine -- and one I hope to resume). When lambda, map and filter were added to Python 5 or 6 years ago, it was a complete surprise. The surprise level has gone down every year since. I expect that for P3K we should move toward a more formal and conventional scheme of writing detailed proposals, and actively soliciting coherent public review. The chaos of a general large newsgroup prevents accomplishing much of anything, though. if-newsgroups-are-the-answer-the-problem-isn't-python-development-ly y'rs - tim From tim_one at email.msn.com Sun Jul 9 05:22:16 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 23:22:16 -0400 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <20000708181004.L29590@lyra.org> Message-ID: I just removed all other occurrences of Py_PROTO and Py_FPROTO in the source tree. Fred, there's still at least one reference in the docs, but I expect you can grep for that more efficiently than I can point it out. [Greg Stein] > Time to create that pydeprecated.h header and move Py_PROTO there :-) > (for use by third-party modules) Be Guido's guest . From fdrake at beopen.com Sun Jul 9 06:51:35 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 00:51:35 -0400 (EDT) Subject: [Python-Dev] __SC__ #define? Message-ID: <14696.1239.522305.588599@cj42289-a.reston1.va.home.com> Does anyone know the purpose of the __SC__ define that's tested in Include/object.h or Objects/floatobject.c? I don't see anywhere in the Python sources where it can be set, and those are the only two places it gets tested. In object.h, it's used to determine the proper definition of statichere, and in floatobject.h it's used to determine if an ANSI prototype should be used. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sun Jul 9 07:15:56 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 01:15:56 -0400 Subject: [Python-Dev] Include/pyport.h now exists In-Reply-To: <20000708212149.P26534@xs4all.nl> Message-ID: [Tim] > Would someone who understands (& can test! I can't yet) > autoconfig please follow up on the last part? [Thomas Wouters] > Can't say I understand all of autoconf but I read enough of the > info pages to be able to do this ! :-) I couldn't find an existing > test that covers this, so I used your example to make one; patch > attached. It detects my linux box properly as 'doesn't zero-fill > when right-shifting a negative number', but I haven't a Cray J90 > handy to test the opposite ;) Only Marc Poinot can test on the J90 now. I tested the logic of the patch by switching the sense of the #ifdef in pyport.h, and it works fine on my box (the point to the #ifdef is to avoid the slow code on platforms that don't *need* the slow code). Don't worry about this -- and we already know for sure that signed right shifts do zero-fill on Marc's platform (perfectly acceptable according to the C std!). > Feel free to change the wording to something a bit less... wordy, > though ;) > Oh, and don't forget to run autoheader & automake before checking in. This helps, but my original request still stands: would somone who can *do* (all of) this please follow up on it? I'm running a Windows laptop in a hotel room -- I can't run Unix-specific config stuff (like autoheader or automake) at all. By "test" I didn't mean test the patch, but get the rest of the Unix config cruft built and test (just) whether the Unix config stuff works. From tim_one at email.msn.com Sun Jul 9 07:23:02 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 01:23:02 -0400 Subject: [Python-Dev] C coding style In-Reply-To: <1249045739-16239476@hypernet.com> Message-ID: [Gordon McMillan] > Jeez, guys. The following options will make indent produce > something that's so close to Guido's style, he'd probably never > notice that it's not exactly his style: > > -br -bap -nce -ss -i8 -ci8 -lp -ts8 -psl -npcs -nbc -ip8 -ncs -nfca Harrumph. Python doesn't recognize *any* of those switches. and-i-use-python-for-everything-ly y'rs - tim From tim_one at email.msn.com Sun Jul 9 07:23:03 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 01:23:03 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Message-ID: [Tim, pushing the adoption of some C9X-like typedefs in Python's source] > ... > the-committee-wasn't-just-jerking-off-the-last-10-years-ly y'rs - > tim [Ken Manheimer] > (The obvious question is, where they doing those other things at the same > time, or during breaks?) It varies by member. For example, the Reverend Tom MacDonald jerked off non-stop the entire time (& I've copied him on this for confirmation). But a surprising number of the members have never jerked off at all! Rev Tom, after 118 years serving on X3J11, do you think C9X is a good thing or a bad thing? And do you still get off on it regardless? And what does God think about C9X? community-involvement-ly y'rs - tim From fdrake at beopen.com Sun Jul 9 07:25:50 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 01:25:50 -0400 (EDT) Subject: [Python-Dev] __SC__ #define? In-Reply-To: <14696.1239.522305.588599@cj42289-a.reston1.va.home.com> References: <14696.1239.522305.588599@cj42289-a.reston1.va.home.com> Message-ID: <14696.3294.579121.909885@cj42289-a.reston1.va.home.com> Fred L. Drake, Jr. writes: > Does anyone know the purpose of the __SC__ define that's tested in > Include/object.h or Objects/floatobject.c? I don't see anywhere in > the Python sources where it can be set, and those are the only two > places it gets tested. > In object.h, it's used to determine the proper definition of > statichere, and in floatobject.h it's used to determine if an ANSI > prototype should be used. Ok, the use in floatobject.c can be removed; if defined, an ANSI signature was being used, which we want to be doing unconditionally at this point. So I'm removing the test there. The use in object.h is more confusing; the log messages are not terribly useful. If anyone understands this one; I'd appreciate a pointer. Appearantly (based on the message associated with the floatobject.c use), the define has something to do with a Macintosh compiler. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sun Jul 9 07:54:46 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 01:54:46 -0400 Subject: [Python-Dev] __SC__ #define? In-Reply-To: <14696.1239.522305.588599@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > Does anyone know the purpose of the __SC__ define that's tested in > Include/object.h or Objects/floatobject.c? Beats me. The symbol __SC__ appears to be predinfed by the Symantec C compiler. It shows up in several bits of interesting code via google, like #if defined(__MWERKS__) || defined (__SC__) #define BRAIN_DEAD_INLINING // define this to declare "hot" #endif // functions as macros instead // of C++ inline functions Alas, like most other older & widely-ported C programs, Python's use of magical & undocumented preprocessor symbols is a god-awful mess. most-developers-would-be-shot-except-they're-so-hard-to- replace-ly y'rs - tim From tim_one at email.msn.com Sun Jul 9 08:06:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 02:06:18 -0400 Subject: Release scheduloe (was RE: [Python-Dev] list comprehensions again...) In-Reply-To: <200007070238.EAA03292@python.inrialpes.fr> Message-ID: [Vladimir Marangozov] > ... [lots of reasonable stuff snipped] ... > ... > I believe that staying in an undetermined Z-state for more than a week > without a set of clearly defined options is not really what we all want, > but maybe you have some additional considerations that may explain the > ongoing patience about this lag... CNRI is involved too. They've chosen so far not to say anything public about what they're after here, and we can't speak for them. *Presuming* to speak for them could not have a good outcome, either. So we remain silent too. None of this is open to debate anyway -- except that if the delay goes on forever, vote with your keyboard by grabbing the Python source and making your own release <0.9 wink>! in-the-meantime-lots-of-good-patches-are-getting-in-ly y'rs - tim From tim_one at email.msn.com Sun Jul 9 08:22:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 02:22:52 -0400 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: <14694.19489.449195.619187@beluga.mojam.com> Message-ID: [Skip Montanaro] > Halleluhah! Never thought I'd get Perl programming help here! Skip, if you can't get Perl help on Python-Dev, where *could* you get it?! Passing out Perl help is one of Python-Dev's most important functions. never-leave-home-ly y'rs - tim From tim_one at email.msn.com Sun Jul 9 09:02:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 03:02:36 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixesUTF-8 en/decode In-Reply-To: Message-ID: > ... > what if sizeof(long) == 2 and sizeof(long long) == 4? That a long can hold at least 32 bits is required by the (current) C std. "long long" is std in C9X, and must hold at least 64 bits. From tim_one at email.msn.com Sun Jul 9 09:05:28 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 03:05:28 -0400 Subject: [Python-Dev] Microsoft adopts Python Message-ID: I take back everything bad I ever said about clueless support droids . -----Original Message----- From: python-help-admin at python.org Sent: Thursday, July 06, 2000 4:46 PM To: python Subject: [Python-Help] programming python I called Microsoft Support and asked for his advice how to learn programming C++ as a complete novice and he recommended to contact your organization for learning first Python. ... From thomas at xs4all.net Sun Jul 9 11:24:32 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 11:24:32 +0200 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <011d01bfe94d$b2fb7200$8119fea9@neil>; from nhodgson@bigpond.net.au on Sun, Jul 09, 2000 at 12:30:49PM +1000 References: <396749F8.F98D2F8C@prescod.net> <200007082219.RAA08379@cj20424-a.reston1.va.home.com> <011d01bfe94d$b2fb7200$8119fea9@neil> Message-ID: <20000709112432.T26534@xs4all.nl> On Sun, Jul 09, 2000 at 12:30:49PM +1000, Neil Hodgson wrote: > > When posting to c.l.py these days I usually feel a lot of pressure > > about how my writings will be perceived by newbies, critics, members > > of other cultures, the press, and so on. > I'd like to separate out the problem here. Is it that there is a need to > keep politically damaging opinions private so the Python community is not > seen to be disparaging some other project like Tk or Expat? Is it that it is > more acceptable for you to make mistakes in front of a restricted audience? Without pretending I can channel Guido as good as the others here ;) I think I know what Guido means: he's afraid of a Prophet Effect, like in the Life of Brian ;) The public image of Guido is a godly one, of stability and steady progress, no nasty suprises. If he were to suggest something radical on c.l.py, like the removal of lambda, classes, or case sensitivity, he'd have a small uprising in his mailbox: half the people on c.l.py would run away from Python screaming (or after screaming loudly in c.l.py,) and the other half would instantly start defending Guido's opinion, having convinced themselves it's a good idea. If he did it here, two things are different: Less people see his insane outburst, and before most people see it, a few developers will have replied, with well-argumented critique, with sooths both types of 'followers' who do happen to read it. (I mean no disrespect towards c.l.py readers, of course, and the stereotype doesn't hold in individual cases. Some of my best friends are c.l.py-readers! But I'm trying to make a point here ;) The other thing is that the audience that does read it right away, the developers, are much more critical towards Guido's opinion, and used to arguing about it in a friendly manner, with Guido and amongst eachother. So Guido has to be less careful about what he says, because he knows python-dev won't take him too seriously anyway ;) At-least-that's-what-I'd-think-if-I'd-written-the-perfect-programming- -language-and-had-to-develop-it-further-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From martin at loewis.home.cs.tu-berlin.de Sun Jul 9 11:26:36 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 9 Jul 2000 11:26:36 +0200 Subject: [Python-Dev] changing the locale.py interface? Message-ID: <200007090926.LAA01406@loewis.home.cs.tu-berlin.de> > comments? Looks good to me. Where is the patch to the documentation documenting all that ?-) Regards, Martin From mwh21 at cam.ac.uk Sun Jul 9 12:06:36 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Sun, 9 Jul 2000 11:06:36 +0100 (BST) Subject: [Python-Dev] __SC__ #define? In-Reply-To: <14696.3294.579121.909885@cj42289-a.reston1.va.home.com> Message-ID: On Sun, 9 Jul 2000, Fred L. Drake, Jr. wrote: > Ok, the use in floatobject.c can be removed; if defined, an ANSI > signature was being used, which we want to be doing unconditionally at > this point. So I'm removing the test there. > The use in object.h is more confusing; the log messages are not > terribly useful. If anyone understands this one; I'd appreciate a > pointer. Appearantly (based on the message associated with the > floatobject.c use), the define has something to do with a Macintosh > compiler. As Tim said, it's probably the Symantec C compiler, which is as far as I know dead (it was more or less dead when I was last playing around programming on the Mac, and that was several years ago). So unless someone screams "I still use Symantec!", I'd say nuke it. hmm-email-over-modem-and-telnet---joy-ly y'rs M. From mwh21 at cam.ac.uk Sun Jul 9 12:14:04 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Sun, 9 Jul 2000 11:14:04 +0100 (BST) Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <1249029961-17188506@hypernet.com> Message-ID: On Sat, 8 Jul 2000, Gordon McMillan wrote: > [Guido] > > I don't know what to do about this, but Neil H's point that we > > might want to separate the operational issues from the deep > > discussions makes some sense. Maybe there's even room for three > > lists: operational, current code and patches, and future > > features. > > > > But in reality, the difference between the various lists isn't > > the topic: it's the group of people. > > There are at least 3 and maybe 6 or more of us who still read > c.l.py (though I've dropped back to newsgroup so I can skip > the braindead threads). As a partial solution, perhaps we > could use some self-discipline and sometimes say "kick it to > c.l.py". I, for one, would be willing to _help_ (not "assume > responsibility for"!) monitoring threads of this sort and > summarizing back to the dev list. I think this is a good idea. I think it is important that comp.lang.python continues to have *some* interesting content, and that the impression is mantained that (reasonable) opinions expressed there are listened to, so that bright & curious people who happen along stick around and maybe move on to actually contributing to Python (yes, this is somewhat autobiographical - two of my first three posts to c.l.py were answered by Guido and David Ascher...). > For ideas on which Guido is > -0, I think this might be a good > way to guage reaction. So do I, and I'd also be willing to help monitor c.l.py (though not right now; due to a broken ethernet port, my access is a bit sporadic, and I'm having trouble keeping up with python-dev). Cheers, M. From effbot at telia.com Sun Jul 9 12:34:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 12:34:48 +0200 Subject: [Python-Dev] what about the SF task manager? Message-ID: <010b01bfe991$53af7280$f2a6b5d4@hagrid> has anyone here used the SF task/project manager? does it work? maybe we should switch SF's version on for python, so that people can list things they should get around to finish some day? ;-) (we could use the patch manager for this purpose, of course -- #100764 is one current example) in the long run, I'd much rather see something based on roundup (which is the best issue tracking system I've ever seen, period), but I guess nobody has time to deal with that right now... From effbot at telia.com Sun Jul 9 13:11:11 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 13:11:11 +0200 Subject: [Python-Dev] os.spawnv problem Message-ID: <011901bfe996$668ac580$f2a6b5d4@hagrid> according to the MSDN docs and my local header files, spawnv and friends return an integer, which contains the process's exit code. according to posixmodule.c (trent?), they return an intptr_t. unfortunately, this little change causes some inter- resting problems; spawnv tells me that my program returns the following exit code: 2167387144924954624 or, in another base: 0x1E141B2000000000L unless anyone can explain what those upper bit mean, and why they are relevant, I suggest casting the return code down to an int. From barry at scottb.demon.co.uk Sun Jul 9 13:50:40 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 9 Jul 2000 12:50:40 +0100 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 In-Reply-To: <019501bfe920$18cee220$f2a6b5d4@hagrid> Message-ID: <000201bfe99b$e7dff4c0$060210ac@private> > stupid question: what exactly does the RC file do here: > > STRINGTABLE DISCARDABLE > BEGIN > 2000 "Dummy" // Needed to version branding works! > END > > (couldn't really parse that comment ;-) I expect that the release engineering process will replace "Dummy" with the assigned version for the build. BArry From effbot at telia.com Sun Jul 9 15:12:04 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 15:12:04 +0200 Subject: [Python-Dev] os.spawnv problem References: <011901bfe996$668ac580$f2a6b5d4@hagrid> Message-ID: <014a01bfe9a7$4b8b64e0$f2a6b5d4@hagrid> I wrote: > according to posixmodule.c (trent?), they return an > intptr_t. > > unfortunately, this little change causes some inter- > resting problems; spawnv tells me that my program > returns the following exit code: > > 2167387144924954624 > > or, in another base: > > 0x1E141B2000000000L > > unless anyone can explain what those upper bit mean, > and why they are relevant, I suggest casting the return > code down to an int. nevermind; I found the problem: the preprocessor doesn't complain if you're comparing variables that doesn't exist, so the following code didn't quite do what the programmer had expected: #if SIZEOF_LONG == SIZE_VOID_P return Py_BuildValue("l", spawnval); #else return Py_BuildValue("L", spawnval); #endif (SIZE_VOID_P is not defined, and you cannot really expect Py_BuildValue to do the right thing if spawnval is an integer). patch coming. From akuchlin at cnri.reston.va.us Sun Jul 9 16:12:44 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 9 Jul 2000 10:12:44 -0400 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <20000709000135.Q26534@xs4all.nl>; from thomas@xs4all.net on Sun, Jul 09, 2000 at 12:01:36AM +0200 References: <396749F8.F98D2F8C@prescod.net> <200007082219.RAA08379@cj20424-a.reston1.va.home.com> <1249029961-17188506@hypernet.com> <20000709000135.Q26534@xs4all.nl> Message-ID: <20000709101244.B21174@newcnri.cnri.reston.va.us> On Sun, Jul 09, 2000 at 12:01:36AM +0200, Thomas Wouters wrote: >Agreed, though I think it should go the other way, too. And it isn't just >about discussing new features or bugs; people, or at least involved people, >like to see that there are actually people working on improving Python ;) People *do* report problems, suggest new features, or provide bugfixes on comp.lang.python, and it would be a pity to miss them; we just have to encourage people to submit through the appropriate channels. python-list is, I think, no longer a language hacking list, and that's probably a good thing. (Remember the person who once said they were shy about posting to python-list because all the discussion was so advanced?) Note for 2.0 final: the docs should mention how to submit patches, the existence of python-dev, etc. I can write a Misc/HACKING file. I'm not sure how to prevent people from inadvertently duplicating ongoing python-dev work, such as the recent case where someone mentioned adding history support to the readline module, which Skip was already doing. A summary of python-dev/CVS activity might be nice. --amk From fdrake at beopen.com Sun Jul 9 16:20:43 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 10:20:43 -0400 (EDT) Subject: [Python-Dev] __SC__ #define? In-Reply-To: References: <14696.3294.579121.909885@cj42289-a.reston1.va.home.com> Message-ID: <14696.35387.635950.631415@cj42289-a.reston1.va.home.com> Michael Hudson writes: > As Tim said, it's probably the Symantec C compiler, which is as far as I > know dead (it was more or less dead when I was last playing around > programming on the Mac, and that was several years ago). > > So unless someone screams "I still use Symantec!", I'd say nuke it. How about "If someone screams, we can add it back." I checking in the change now. Thanks, Michael & Tim! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Sun Jul 9 17:23:10 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 10:23:10 -0500 Subject: [Python-Dev] __SC__ #define? In-Reply-To: Your message of "Sun, 09 Jul 2000 11:06:36 +0100." References: Message-ID: <200007091523.KAA10316@cj20424-a.reston1.va.home.com> > So unless someone screams "I still use Symantec!", I'd say nuke it. Wait till Jack Jansen reads his email. In fact, he can nuke it himself if he doesn't need it... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Sun Jul 9 17:26:28 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 10:26:28 -0500 Subject: [Python-Dev] what about the SF task manager? In-Reply-To: Your message of "Sun, 09 Jul 2000 12:34:48 +0200." <010b01bfe991$53af7280$f2a6b5d4@hagrid> References: <010b01bfe991$53af7280$f2a6b5d4@hagrid> Message-ID: <200007091526.KAA10343@cj20424-a.reston1.va.home.com> [effbot] > has anyone here used the SF task/project manager? Not me. > does it work? Dunno. > maybe we should switch SF's version on for python, so > that people can list things they should get around to > finish some day? ;-) It's an idea. Currently these are hidden in the old TODO wizard and the "request" category in the Jitterbug-based bugs list on python.org... > (we could use the patch manager for this purpose, of > course -- #100764 is one current example) :-) > in the long run, I'd much rather see something based > on roundup (which is the best issue tracking system > I've ever seen, period), but I guess nobody has time > to deal with that right now... I've never seen roundup, either, but it is sure getting good press... Maybe one of my fellow PythonLabs employees can set it up on pythonlabs.com? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Sun Jul 9 16:34:48 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 10:34:48 -0400 (EDT) Subject: [Python-Dev] __SC__ #define? In-Reply-To: <200007091523.KAA10316@cj20424-a.reston1.va.home.com> References: <200007091523.KAA10316@cj20424-a.reston1.va.home.com> Message-ID: <14696.36232.876446.324645@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > > So unless someone screams "I still use Symantec!", I'd say nuke it. > > Wait till Jack Jansen reads his email. In fact, he can nuke it > himself if he doesn't need it... Er, too late. I can add it back if he needs it. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Sun Jul 9 17:35:07 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 10:35:07 -0500 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: Your message of "Sat, 08 Jul 2000 23:22:16 -0400." References: Message-ID: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> > I just removed all other occurrences of Py_PROTO and Py_FPROTO in the source > tree. Great work, Tim! There's one problem: several large patches that are waiting for us in the SF patch manager won't work any more because they reference context that you ripped out. I'm thinking of the augmented assignment and the list comprehensions patch, and I think Thomas Wouters' patch for [a:b:c] meaning range(a,b,c) is also broken now. I think your patch status guidelines suggest that these patches should be labeled out of date until the author uploads a new version... BTW, the more delay 2.0 incurs because of the negotiations between CNRI and BeOpen, the more sense it makes to me to add those language features! Last night I changed the status of the list comprehensions and augmented assignment patches to Open. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From barry at scottb.demon.co.uk Sun Jul 9 16:56:31 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 9 Jul 2000 15:56:31 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python Message-ID: <000001bfe9b5$de7168f0$060210ac@private> I read in the archives the problem with import of a 1.5 extension into newer Python release crashing say new Python. A solution that works is to use a new naming scheme for the initialisation entry point. Currently it is "init" + module-name with "_d" appended if it is debug image. Change "init" to "init16", "init20" and you can import the old 1.5 linked extension without a crash, you get an error reported instead. BArry From skip at mojam.com Sun Jul 9 16:17:41 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 9 Jul 2000 09:17:41 -0500 (CDT) Subject: [Python-Dev] Microsoft adopts Python In-Reply-To: References: Message-ID: <14696.35205.331898.137663@beluga.mojam.com> [ MS recommending Python before C++ ] Tim> I take back everything bad I ever said about clueless support Tim> droids . Maybe it was Bill Tutt on the phone! ;-) Skip From skip at mojam.com Sun Jul 9 16:23:41 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 9 Jul 2000 09:23:41 -0500 (CDT) Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: References: <1249029961-17188506@hypernet.com> Message-ID: <14696.35565.198655.899292@beluga.mojam.com> >> As a partial solution, perhaps we could use some self-discipline and >> sometimes say "kick it to c.l.py". Michael> .... I think it is important that comp.lang.python continues Michael> to have *some* interesting content, and that the impression is Michael> mantained that (reasonable) opinions expressed there are Michael> listened to, .... Whatever happened to the c.l.py weekly summary? David Ascher, Aaron Watters & Fredrik Lundh I think were doing it for a long time. It seems that with the python-dev archives on the web that perhaps the weekly editor could occasionally point toward specific threads to provide a high-signal intersection of the two lists. To expose interesting c.l.py threads to python-dev folks who may not track the group closely any more, perhaps the weekly summary could be posted here as well. Skip From fdrake at beopen.com Sun Jul 9 17:54:38 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 11:54:38 -0400 (EDT) Subject: [Python-Dev] Objects/ ANSI-fied Message-ID: <14696.41022.709280.192971@cj42289-a.reston1.va.home.com> Ok, the Objects/ directory has been ANSI-fied, and I've noticed /F slaving away in the Modules/ directory, so I'll get out of the way for a little bit. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Sun Jul 9 16:33:19 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 9 Jul 2000 09:33:19 -0500 (CDT) Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> References: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> Message-ID: <14696.36143.297072.353525@beluga.mojam.com> Guido> There's one problem: several large patches that are waiting for Guido> us in the SF patch manager won't work any more because they Guido> reference context that you ripped out. I'm thinking of the Guido> augmented assignment and the list comprehensions patch ... I will do a cvs update and generate a new patch today. Skip From effbot at telia.com Sun Jul 9 18:10:49 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 18:10:49 +0200 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] References: <1249029961-17188506@hypernet.com> <14696.35565.198655.899292@beluga.mojam.com> Message-ID: <003001bfe9c0$46517780$f2a6b5d4@hagrid> skip wrote: > > >> As a partial solution, perhaps we could use some self-discipline and > >> sometimes say "kick it to c.l.py". > > Michael> .... I think it is important that comp.lang.python continues > Michael> to have *some* interesting content, and that the impression is > Michael> mantained that (reasonable) opinions expressed there are > Michael> listened to, .... > > Whatever happened to the c.l.py weekly summary? David Ascher, Aaron Watters > & Fredrik Lundh I think were doing it for a long time. I'm still doing the daily edition: http://hem.passagen.se/eff/url.htm http://hem.passagen.se/eff/url-archive.htm Andrew took over the weekly edition a while ago (the latest issue is june 27, I think). For the daily edition, most of the interesting material comes from other sources (oreillynet, linuxdev.net, etc). comp.lang.python varies wildly; some weeks, there are lots of good stuff. Other weeks, I cannot find anything relevant at all... From skip at mojam.com Sun Jul 9 16:38:21 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 9 Jul 2000 09:38:21 -0500 (CDT) Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) Message-ID: <14696.36445.834366.510392@beluga.mojam.com> Interesting feature request from c.l.py... Skip -------------- next part -------------- An embedded message was scrubbed... From: Olmy Subject: Feature Request: IPv6 support built into 1.6/2.0 Date: Sun, 9 Jul 2000 10:47:03 -0500 (CDT) Size: 1360 URL: From effbot at telia.com Sun Jul 9 18:21:17 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 18:21:17 +0200 Subject: [Python-Dev] Objects/ ANSI-fied References: <14696.41022.709280.192971@cj42289-a.reston1.va.home.com> Message-ID: <004b01bfe9c1$b9354820$f2a6b5d4@hagrid> fred wrote: > Ok, the Objects/ directory has been ANSI-fied, and I've noticed /F > slaving away in the Modules/ directory, so I'll get out of the way for > a little bit. ;) well, I've been checking in Peter Schneider-Kamp's patches. but most of the remaining modules are Unix-only, and I'm on a Win95 box right now. so if anyone wants to make a stab at the patches in the 100768-100787 range, please go ahead. (fred, to give you more things to do, I just assigned Rob's big spelling patch to you, since large parts of it affect the documentation) cheers /F From effbot at telia.com Sun Jul 9 18:27:24 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 18:27:24 +0200 Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) References: <14696.36445.834366.510392@beluga.mojam.com> Message-ID: <005901bfe9c2$9232e740$f2a6b5d4@hagrid> > Interesting feature request from c.l.py... checking the eff-bot archive. wait a sec... yes, here it is: ftp://ftp.kame.net/pub/kame/misc/ has patches for 1.5.2 netbsd (and iirc, debian?) folks has also been working on this; here's one note: http://mail-index.netbsd.org/netbsd-bugs/2000/01/19/0017.html "of course, need to submit IPv6 support patch to original author (did in the past but he looked busy)" are they talking about guido, perhaps? From thomas at xs4all.net Sun Jul 9 18:25:03 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 18:25:03 +0200 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <14696.36143.297072.353525@beluga.mojam.com>; from skip@mojam.com on Sun, Jul 09, 2000 at 09:33:19AM -0500 References: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> <14696.36143.297072.353525@beluga.mojam.com> Message-ID: <20000709182503.X26534@xs4all.nl> On Sun, Jul 09, 2000 at 09:33:19AM -0500, Skip Montanaro wrote: > Guido> There's one problem: several large patches that are waiting for > Guido> us in the SF patch manager won't work any more because they > Guido> reference context that you ripped out. I'm thinking of the > Guido> augmented assignment and the list comprehensions patch ... > I will do a cvs update and generate a new patch today. Same here. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sun Jul 9 18:32:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 18:32:25 +0200 Subject: [Python-Dev] new popen for win32! [status update] References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> Message-ID: <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> current status: > - should this go into the "nt" (posix) module, or should > I create a new module? I just checked in a new version of posixmodule.c, which uses Bill's implementation instead of _popen. works just fine, on the boxes I've tested it on. > - "win32popenWin9x.exe" is a rather unwieldy name for a > file. does anyone have a better suggestion? > > python_popen.exe > py_popen9x.exe > popenStub.exe > > ...? tim suggested "w9xpopen.exe", which as good as it gets. I've checked in the PC/w9xpopen.c file, but I haven't up- dated the build files (see below): > - I'm using VC5 on this box, so I should probably avoid > checking in my modified project files. any VC6-wielding > volunteers out there? tim will fix this. > - first, a stupid question: is the popen2 and popen3 > versions replacements for the corresponding functions > in the popen2 module. > > (or to put it another way: should the popen2 module > be modified to use these functions on Windows?) the new posix code exports popen2, popen3, and popen4 on windows. I'll provide patches for popen2.py later (gotta do some more testing first). cheers /F From effbot at telia.com Sun Jul 9 18:44:24 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 18:44:24 +0200 Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) References: <14696.36445.834366.510392@beluga.mojam.com> <005901bfe9c2$9232e740$f2a6b5d4@hagrid> Message-ID: <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid> I wrote: > ftp://ftp.kame.net/pub/kame/misc/ has patches for 1.5.2 the patch looks fairly clean to to me. if anyone wants to check with the original author, and update the patch for 2.0, I'm definitely +1 on this one. From jeremy at alum.mit.edu Sun Jul 9 18:42:22 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Sun, 9 Jul 2000 12:42:22 -0400 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <20000709101244.B21174@newcnri.cnri.reston.va.us> Message-ID: >I'm not sure how to prevent people from inadvertently duplicating >ongoing python-dev work, such as the recent case where someone >mentioned adding history support to the readline module, which Skip >was already doing. A summary of python-dev/CVS activity might be >nice. This sounds very good! In the Perl world, there is a weekly summary of discussion on the perl5-porters list. It seems to be written by Mark-Jason Dominus most (all?) of the time. We could do the same thing if we could find people to do it. Perhaps a weekly Python-dev URL? If we had enough reporters, it might not be too much work. Volunteers? I'd be happy to coordinate. Jeremy From fdrake at beopen.com Sun Jul 9 18:48:56 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 12:48:56 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib webbrowser.py,NONE,1.1 In-Reply-To: <200007091645.JAA26779@slayer.i.sourceforge.net> References: <200007091645.JAA26779@slayer.i.sourceforge.net> Message-ID: <14696.44280.536157.31030@cj42289-a.reston1.va.home.com> Fred L. Drake writes: > Update of /cvsroot/python/python/dist/src/Lib The bogus lock in the Lib/ directory is clear; one of the SF guys was out of town for a few days. (Don't know about the others.) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sun Jul 9 19:01:23 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 13:01:23 -0400 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> Message-ID: [Tim] > I just removed all other occurrences of Py_PROTO and Py_FPROTO > in the source tree. [Guido] > Great work, Tim! If I have demacrofied more than others, it is because I've stood on the throat of Fred Drake . > There's one problem: several large patches that are waiting for us > in the SF patch manager won't work any more because they reference > context that you ripped out. Revolution, eggs, break, sorry. > I'm thinking of the augmented assignment and the list comprehensions > patch, and I think Thomas Wouters' patch for [a:b:c] meaning > range(a,b,c) is also broken now. > > I think your patch status guidelines suggest that these patches should > be labeled out of date until the author uploads a new version... Yes. > BTW, the more delay 2.0 incurs because of the negotiations between > CNRI and BeOpen, the more sense it makes to me to add those language > features! Last night I changed the status of the list comprehensions > and augmented assignment patches to Open. That makes sense to me, and not just because I've been keen on augmented assignment since before Python 1.0, and keen on listcomps since they first came up. Perhaps the person assigned to these patches would care to keep their statuses up to date? Not naming any names here , but if patch ownership means anything, it means owning the next step in the patch process. resisting-a-bad-precedent-ly y'rs - tim From tim_one at email.msn.com Sun Jul 9 19:04:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 13:04:42 -0400 Subject: [Python-Dev] new popen for win32! [status update] In-Reply-To: <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> Message-ID: [/F] > I just checked in a new version of posixmodule.c, which > uses Bill's implementation instead of _popen. works just > fine, on the boxes I've tested it on. > ... Thank you, Frederik! This stuff looks great. I believe I've got everything I need now to update the MSVC6 project files and installer and assorted readmes, and I'll do that later today (several hours from now). have-to-pause-once-a-week-to-eat-ly y'rs - tim From effbot at telia.com Sun Jul 9 19:37:35 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 19:37:35 +0200 Subject: [Python-Dev] new popen for win32! [status update] References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> Message-ID: <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> following up on myself: > > - first, a stupid question: is the popen2 and popen3 > > versions replacements for the corresponding functions > > in the popen2 module. > > > > (or to put it another way: should the popen2 module > > be modified to use these functions on Windows?) > > the new posix code exports popen2, popen3, and popen4 > on windows. I'll provide patches for popen2.py later (gotta > do some more testing first). the current api is: popen2.popen2(command, bufsize=default) popen2.popen3(command, bufsize=default) vs. nt.popen2(command, mode="t") nt.popen3(command, mode="t") the perfect compromise would of course be popen2(command, mode="t", bufsize=default) (similar to plain open). I suggest the popen2 api's to: def popen2.popen2(command, mode="t", bufsize=-1): if type(mode) is type(0) and bufsize==-1: bufsize = mode mode = "t" ... def nt.popen2(command, mode, bufsize=-1): if bufsize != -1: raise ValueError, "cannot set buffer size on windows" comments? From skip at mojam.com Sun Jul 9 18:03:00 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 9 Jul 2000 11:03:00 -0500 (CDT) Subject: [Python-Dev] patch for os.path.commonprefix (changes semantics - pls review) Message-ID: <14696.41524.306876.462534@beluga.mojam.com> os.path.commonprefix seems broken to me. If you ask it to return the common prefix of "/home/swen/spam" and "/home/swan/eggs", it returns "/home/sw". Since we are talking file paths, not strings, I think the common prefix should be "/home". Since my patch changes the semantics of the function, I submitted a patch via SF that implements what I believe to be the correct behavior instead of just checking in the change, so people could comment on it. Also, since the version in ntpath.py was the same as the version in posixpath.py I modified both, replacing "/" with os.sep (is that correct?). Note that I can't check that it returns something useful on NT, though I suspect it will. There is no commonprefix function in macpath.py. Is this a function that would have no meaning on the Mac? The patch is available for review at http://sourceforge.net/patch/?func=detailpatch&patch_id=100788&group_id=5470 Skip From effbot at telia.com Sun Jul 9 19:48:41 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 19:48:41 +0200 Subject: [Python-Dev] patch for os.path.commonprefix (changes semantics - pls review) References: <14696.41524.306876.462534@beluga.mojam.com> Message-ID: <015e01bfe9cd$ee090800$f2a6b5d4@hagrid> skip wrote: > Also, since the version in ntpath.py was the same as the version in > posixpath.py I modified both, replacing "/" with os.sep (is that correct?). see my comment on the site (in short: you should split on either os.sep or os.altsep, or normalize before splitting. and don't forget UNC names: \\machine\directory...). From thomas at xs4all.net Sun Jul 9 20:49:21 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 20:49:21 +0200 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 09, 2000 at 01:01:23PM -0400 References: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> Message-ID: <20000709204921.Y26534@xs4all.nl> On Sun, Jul 09, 2000 at 01:01:23PM -0400, Tim Peters wrote: > Perhaps the person assigned to these patches would care to keep > their statuses up to date? Not naming any names here , [..] Well, augmented assignment isn't assigned to anyone yet, so I guess I'll keep it up to date ;) Besides, it can be tricky to keep a patch up to date if you didn't write it yourself: you might fail to notice tiny details the original author had in the back of his head. Not that this particular clash was hard to resolve, of course, it was mostly context-clash, plus the issue of writing the patch ANSI style itself ;) Unless of course being assigned to a patch means you have to know it as well as the author(s), in which case I hush up and wait for Guido to assign you to the augassign patch ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sun Jul 9 20:54:01 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 20:54:01 +0200 Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) In-Reply-To: <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jul 09, 2000 at 06:44:24PM +0200 References: <14696.36445.834366.510392@beluga.mojam.com> <005901bfe9c2$9232e740$f2a6b5d4@hagrid> <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid> Message-ID: <20000709205401.Z26534@xs4all.nl> On Sun, Jul 09, 2000 at 06:44:24PM +0200, Fredrik Lundh wrote: > I wrote: > > ftp://ftp.kame.net/pub/kame/misc/ has patches for 1.5.2 > the patch looks fairly clean to to me. > if anyone wants to check with the original author, and update > the patch for 2.0, I'm definitely +1 on this one. Out of curiousity, what does the patch rely on ? I toyed around with IPv6 a while back (err, make that 3 years back. Gosh, does time fly!) and setting it up was pretty involved, getting the right client libraries and stuff. Is there anything like a standard interface, nowadays, or will the socket (or is that 'socket6' ?) library have to worry about all kinds of different interfaces ? I'd check the patch out, had I the time ;P I might get it late next week or so. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Sun Jul 9 21:04:20 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 15:04:20 -0400 (EDT) Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) In-Reply-To: <20000709205401.Z26534@xs4all.nl> References: <14696.36445.834366.510392@beluga.mojam.com> <005901bfe9c2$9232e740$f2a6b5d4@hagrid> <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid> <20000709205401.Z26534@xs4all.nl> Message-ID: <14696.52404.703807.177420@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > Out of curiousity, what does the patch rely on ? I toyed around with IPv6 a > while back (err, make that 3 years back. Gosh, does time fly!) and setting > it up was pretty involved, getting the right client libraries and stuff. > Is there anything like a standard interface, nowadays, or will the socket > (or is that 'socket6' ?) library have to worry about all kinds of different There's a standard API for both "normal" and advanced features of IPv6 sockets defined in some IETF documents; I'm not sure of their current state, but they've been in development for a while, so they might even be RFCs by now. > I'd check the patch out, had I the time ;P I might get it late next week or > so. I may look at them in a few days as well. Multiple opinions may be very valuable on a topic as detailed and pervasive as this! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From petersc at stud.ntnu.no Sun Jul 9 23:13:15 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Sun, 09 Jul 2000 21:13:15 +0000 Subject: [Python-Dev] PROTO_LIST in Modules/md5.h Message-ID: <3968EAEB.A06D9A38@stud.ntnu.no> Is this still needed with ANSI? Thanks, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From thomas at xs4all.net Sun Jul 9 21:16:42 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 21:16:42 +0200 Subject: [Python-Dev] PROTO_LIST in Modules/md5.h In-Reply-To: <3968EAEB.A06D9A38@stud.ntnu.no>; from petersc@stud.ntnu.no on Sun, Jul 09, 2000 at 09:13:15PM +0000 References: <3968EAEB.A06D9A38@stud.ntnu.no> Message-ID: <20000709211641.B26534@xs4all.nl> On Sun, Jul 09, 2000 at 09:13:15PM +0000, Peter Schneider-Kamp wrote: > Is this still needed with ANSI? No, and it isn't necessary with K&R C either, just if you wish to use both at the same time ;) It's the same as the Py_PROTO macro, and should be removed, yes. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Sun Jul 9 21:19:29 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 15:19:29 -0400 (EDT) Subject: [Python-Dev] PROTO_LIST in Modules/md5.h In-Reply-To: <3968EAEB.A06D9A38@stud.ntnu.no> References: <3968EAEB.A06D9A38@stud.ntnu.no> Message-ID: <14696.53313.296096.777677@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > Is this still needed with ANSI? No, but this is imported code, so perhaps it makes sense to leave that in. (Both md5.c and md5.h are imported, and are the only places that have this.) I won't object to ANSI-fying these two files, but I'm not sure it makes sense, either. These may as well be an external library. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Sun Jul 9 21:21:41 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 15:21:41 -0400 (EDT) Subject: [Python-Dev] Out of loop... Message-ID: <14696.53445.235099.144979@cj42289-a.reston1.va.home.com> Ok, it's been a busy week, and my wife & kids are just about back. I'll be largely out of touch here for about 24 hours. It's time to play with the kids! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sun Jul 9 21:38:05 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 15:38:05 -0400 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <20000709204921.Y26534@xs4all.nl> Message-ID: [Tim] > Perhaps the person assigned to these patches would care to keep > their statuses up to date? Not naming any names here , [..] [Thomas Wouters, with his heart in the right place but on the wrong track] > Well, augmented assignment isn't assigned to anyone yet, so I guess > I'll keep it up to date ;) Keeping a patch up to date is different than keeping the patch *status* up to date. I was talking about the latter. When Guido (or anyone else) notices that a patch is out of date, I am gently suggesting that they change the SourceForge Patch Manager Status field to "Out of date" themself (rather than, e.g., leaving the status "Open" and posting to Python-Dev that the status is wrong now -- the latter is an instance of the "active mailing list write-only black hole" we moved to SF to get away from). From thomas at xs4all.net Sun Jul 9 21:40:59 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 21:40:59 +0200 Subject: [Python-Dev] Out of loop... In-Reply-To: <14696.53445.235099.144979@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Sun, Jul 09, 2000 at 03:21:41PM -0400 References: <14696.53445.235099.144979@cj42289-a.reston1.va.home.com> Message-ID: <20000709214058.D26534@xs4all.nl> On Sun, Jul 09, 2000 at 03:21:41PM -0400, Fred L. Drake, Jr. wrote: > Ok, it's been a busy week, and my wife & kids are just about back. > I'll be largely out of touch here for about 24 hours. It's time to > play with the kids! Damn, this scares me. Even at my real-life job we don't warn eachother when we're out of the loop for a day or so. We've had a colleague go on a vacation, and not be missed for like a week before anyone started wondering where he was ;-) And here is Fred apologizing for spending a day with his family. Is it too late for me to opt out ?!? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Sun Jul 9 21:47:37 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 15:47:37 -0400 (EDT) Subject: [Python-Dev] Out of loop... In-Reply-To: <20000709214058.D26534@xs4all.nl> References: <14696.53445.235099.144979@cj42289-a.reston1.va.home.com> <20000709214058.D26534@xs4all.nl> Message-ID: <14696.55001.491151.543374@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > Damn, this scares me. Even at my real-life job we don't warn eachother when > we're out of the loop for a day or so. We've had a colleague go on a > vacation, and not be missed for like a week before anyone started wondering > where he was ;-) And here is Fred apologizing for spending a day with his > family. Is it too late for me to opt out ?!? You have to realize -- right now, email is the *primary* communications mechanism for PythonLabs, both internally and with the community. If we don't know that someone is away from their mail, we expect rapid response. Given my past week, there've been very few hours I've been away from my mail. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sun Jul 9 22:03:06 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 16:03:06 -0400 Subject: [Python-Dev] Out of loop... In-Reply-To: <20000709214058.D26534@xs4all.nl> Message-ID: [Fred L. Drake, Jr.] > Ok, it's been a busy week, and my wife & kids are just about back. > I'll be largely out of touch here for about 24 hours. It's time to > play with the kids! [Thomas Wouters, understandly terrified by the implications] > ... > And here is Fred apologizing for spending a day with his family. Is it > too late for me to opt out ?!? Far too late, yes. Your ours for life now (and probably longer, if CNRI has any say in the matter <0.9 wink>). [Fred again, rationalizing] > You have to realize -- right now, email is the *primary* communications > mechanism for PythonLabs, both internally and with the community. Actually, the community may not realize that we don't have an office, Jeremy and Barry live in a different state than Guido and Fred, and Tim is living in a hotel (although I think I've been careful to whine about the latter often enough here ). The *important* thing to notice, though, is that Fred is still replying to email instantly even after swearing on all that is holy that he'd be out of touch for 24 hours. pythonlabs-has-zero-tolerance-for-wimps-ly y'rs - tim From guido at beopen.com Sun Jul 9 23:52:13 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 16:52:13 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Sun, 09 Jul 2000 15:56:31 +0100." <000001bfe9b5$de7168f0$060210ac@private> References: <000001bfe9b5$de7168f0$060210ac@private> Message-ID: <200007092152.QAA14143@cj20424-a.reston1.va.home.com> > I read in the archives the problem with import of a 1.5 extension > into newer Python release crashing say new Python. > > A solution that works is to use a new naming scheme for the > initialisation entry point. Currently it is "init" + module-name > with "_d" appended if it is debug image. > > Change "init" to "init16", "init20" and you can import the old > 1.5 linked extension without a crash, you get an error reported > instead. Nice idea... Unfortunately it means that every module must be changed. If we want to do this, we'd best introduce a macro! E.g. (untested): #define Py_INIT(modname) DL_EXPORT(void) init20##modname() --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Sun Jul 9 23:53:42 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 16:53:42 -0500 Subject: [Python-Dev] Objects/ ANSI-fied In-Reply-To: Your message of "Sun, 09 Jul 2000 11:54:38 -0400." <14696.41022.709280.192971@cj42289-a.reston1.va.home.com> References: <14696.41022.709280.192971@cj42289-a.reston1.va.home.com> Message-ID: <200007092153.QAA14165@cj20424-a.reston1.va.home.com> > Ok, the Objects/ directory has been ANSI-fied, and I've noticed /F > slaving away in the Modules/ directory, so I'll get out of the way for > a little bit. ;) Great! Sounds like everybody is getting the hint that 2.0 needs to have some distinguishing characteristics compared to 1.6... :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From tim_one at email.msn.com Sun Jul 9 22:55:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 16:55:52 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <20000628010407.T29590@lyra.org> Message-ID: [Tim] > OTOH, we're also interested in *helping* SF get better! SF is > as much an Open Source project as Python, and it could become > an incredible resource for the entire OS community. [Greg Stein [mailto:gstein at lyra.org] Sent: Wednesday, June 28, 2000 4:04 AM] > This last statement is (unfortunately) not quite true. SourceForge is > developed in a closed, cathedral environment. There is no CVS > access to it, and all the developers work at VA Linux. Strictly speaking, > the *output* of this closed development is GPL'd. But it isn't what you > would expect. Ah! You were reading my stmt as a claim about SF, rather than as a warning about the new status of Python . Just kidding. I was talking out of my ass there, and appreciate the correction. From tim_one at email.msn.com Sun Jul 9 22:55:45 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 16:55:45 -0400 Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: <20000627101658.E7257@activestate.com> Message-ID: [Trent Mick Sent: Tuesday, June 27, 2000 1:17 PM] > What are the chances of getting other meta data fields on patches, i.e. > changes to the patch manager? A question for SourceForge. > Categorizing patches could really help as a filter. For instance, I > may be a Unicode genius and would like to see the patches associated > with it. There's already a "Category" field on SF patches, but the main view doesn't show it (you have to look at an individual patch to see it) and there's apparently no way to filter on it either. Also think you have to be an admin to create a new category. I'll confess in advance, though, that I expect each additional field will just be one more field set incorrectly on the vast minority of patches. > ... > Perhaps ownership (i.e. 'assigned to') of the patch should transfer > to the person responsible for later taking to patch out of 'postponed' > status. Yes; thank you; I'll post a revision later today. The intent was always that "assigned to" be the most likely person to take action next. From guido at beopen.com Mon Jul 10 00:02:37 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 17:02:37 -0500 Subject: [Python-Dev] new popen for win32! [status update] In-Reply-To: Your message of "Sun, 09 Jul 2000 19:37:35 +0200." <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> Message-ID: <200007092202.RAA14221@cj20424-a.reston1.va.home.com> > the current api is: > > popen2.popen2(command, bufsize=default) > popen2.popen3(command, bufsize=default) > > vs. > > nt.popen2(command, mode="t") > nt.popen3(command, mode="t") Not commenting on the question here, but on the return tuple: should it be (i,o,e) or (o,i,e)? The popen2 module uses the latter, but that's hard to remember for Unix-droids: it corresponds to (1,0,2) in file descriptors. So if it's not too late, let's do (i,o,e). (I tried to read the posixmodule.c source but got lost...) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From tim_one at email.msn.com Sun Jul 9 23:07:40 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 17:07:40 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr. Sent: Wednesday, June 28, 2000 9:30 AM] > ... > the only problem I've had with IE5 is accessing a project's anonymous > FTP area from the project page (IE5 just froze completely). This happens to me too. And a new problem popped up early this weekend (maybe Friday already): when I click the "Browse CVS Repository" link near the bottom right of http://sourceforge.net/cvs/?group_id=5470 IE5 pops up a box asking me whether I really want to download file "cvsweb". Useless! This used to work fine, and I sure haven't changed my IE setup. Clearing the browser caches didn't help. The link resolves to http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi?cvsroot=python today, and I don't know whether it resolved to something different last week. Also have no idea how browsers decide what to do -- it's not simple & straightforward, like e.g. floating-point arithmetic . .cgi is not an extension registered on my machine either. From petersc at stud.ntnu.no Mon Jul 10 01:17:44 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Sun, 09 Jul 2000 23:17:44 +0000 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix References: <396780B6.67247E2C@stud.ntnu.no> <200007082334.SAA08816@cj20424-a.reston1.va.home.com> Message-ID: <39690818.917030DE@stud.ntnu.no> While "slaving away" on the Modules/ directory (thanks for the term - it made my day ), I still haven't got a clue why Python crashes on me when I throw an error on duplicate arguments like in: [example] >>> def f(a, a): print a segfault [/example] Any help is again appreciated. Or should I just load up that mini patch to SF and wait for some unlucky guy that assigns it on himself <0.5 wink>? okay, back to Modules/r* - z* Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de -------------- next part -------------- diff -c -d -T --recursive python/dist/src/Python/compile.c python-mod/dist/src/Python/compile.c *** python/dist/src/Python/compile.c Mon Jul 3 21:39:47 2000 --- python-mod/dist/src/Python/compile.c Sun Jul 9 02:04:26 2000 *************** *** 3092,3097 **** --- 3092,3098 ---- node *ch = CHILD(n, i); node *fp; char *name; + PyObject *nameval; if (TYPE(ch) == STAR || TYPE(ch) == DOUBLESTAR) break; REQ(ch, fpdef); /* fpdef: NAME | '(' fplist ')' */ *************** *** 3103,3109 **** sprintf(nbuf, ".%d", i); complex = 1; } ! com_newlocal(c, name); c->c_argcount++; if (++i >= nch) break; --- 3104,3118 ---- sprintf(nbuf, ".%d", i); complex = 1; } ! nameval = PyString_InternFromString(name); ! if (nameval == NULL) { ! c->c_errors++; ! } ! if (PyDict_GetItem(c->c_locals, nameval)) { ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); ! } ! com_newlocal_o(c, nameval); ! Py_DECREF(nameval); c->c_argcount++; if (++i >= nch) break; From guido at beopen.com Mon Jul 10 00:27:33 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 17:27:33 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib popen2.py,1.9,1.10 In-Reply-To: Your message of "Sun, 09 Jul 2000 10:59:34 MST." <200007091759.KAA04874@slayer.i.sourceforge.net> References: <200007091759.KAA04874@slayer.i.sourceforge.net> Message-ID: <200007092227.RAA14284@cj20424-a.reston1.va.home.com> > - changed nt.popen2/popen3/popen4 return values > to match the popen2 module (stdout first, not > stdin). Really? Isn't that a horrid order? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 00:31:58 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 17:31:58 -0500 Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) In-Reply-To: Your message of "Sun, 09 Jul 2000 15:04:20 -0400." <14696.52404.703807.177420@cj42289-a.reston1.va.home.com> References: <14696.36445.834366.510392@beluga.mojam.com> <005901bfe9c2$9232e740$f2a6b5d4@hagrid> <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid> <20000709205401.Z26534@xs4all.nl> <14696.52404.703807.177420@cj42289-a.reston1.va.home.com> Message-ID: <200007092231.RAA14305@cj20424-a.reston1.va.home.com> I remember that someone from Japan (the KAME folks?) submitted IPv6 patches before -- maybe a year ago. Unfortunately, they had only tested it on one platform (*bsd?), and the porting instructions they gave didn't work at all on any platform I had access to (Solaris, Linux). If the portability of the new patches is up to snuff, I'd be all for integrating this. Ideally, it would detect at configure time whether IPv6 support is available and do the right thing. I suppose there's a POSIX standard for IPv6 socket extensions etc. somewhere? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Sun Jul 9 23:35:26 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 23:35:26 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14695.840.448508.397722@beluga.mojam.com>; from skip@mojam.com on Sat, Jul 08, 2000 at 05:32:40AM -0500 References: <14691.49563.78765.683762@beluga.mojam.com> <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> <14695.840.448508.397722@beluga.mojam.com> Message-ID: <20000709233525.E26534@xs4all.nl> On Sat, Jul 08, 2000 at 05:32:40AM -0500, Skip Montanaro wrote: > Since Fredrik's voice is the only one I heard, and on the off-chance that > the CNRI/BeOpen discussions and resulting 1.6 release push things out a bit > (allowing a feature thaw) I'll oblige. I have a couple of questions regarding this patch, if you don't mind. I didn't appoint myself arbiter of new code, and I'm certainly not a kind of spanish inquisition, but I really have to scratch my head when reading this patch (and the resulting code.) I hope you don't take it personal ;P Also, I'm not criticising the new feature, just wondering about the implementation. For one, the Grammar for list comprehensions: '[' [testlist [list_iter]] ']' Should that really be 'testlist' ? As far as I can see, it should be 'test' rather than 'testlist'. This is kind of nit-picky, but the presence of the list_iter part completely changes the meaning of the testlist in front of it: [1,2,3,4,5] is a list of 5 elements, but [1,2,3,4,5 if 1] is a list of one element, which is a 5-element tuple. I'd say the Grammar would be more like this: atom: '(' [testlist] ')' | '[' [listmaker] ']' | '{' [dictmaker] '}' | '' testlist '' | NAME | NUMBER | STRING+ listmaker: test ( list_iter | (',' test)* [',']) list_iter: list_for | list_if list_for: 'for' exprlist 'in' testlist [list_iter] list_if: 'if' test [list_iter] And by coincidence this is also fits very nicely with what the 'range-literal' patch does ;-) Another issue is the code- and logic-duplication of the patch to compile.c: it looks like a large part was just copied from com_for_node, and the block-stuff commented out. Why is it commented out, by the way ? Don't exceptions or something need the block setup ? If the block-setup was kept in, it might be easier to split the com_for_node into a function that compiles the header, and one that compiles the suite, and make com_list_for compile its own 'suite'. I'm hoping that's possible, because it would keep the code a lot cleaner, and it would make it easier for me to implement 'for i in x;j in y' and have it work for list comprehensions too ;-) Also, the patch creates a list, stores it locally, and calls append() to it inside the inner loop. Isn't it possible for the patch to build the list on the stack, pushing individual elements on the stack and calling BUILD_LIST at the end ? The for loops counts the number of loops anyway ;) and it would get rid of the fairly ugly tmpname thing altogether, I think. However, the logic of when to ROT_THREE and ROT_TWO and what not might run away from under us ;-P (But I'm facing that anyway, with the parallel-forloop) Alternatively, it would be nice to store the lists' append() in a local vrbl, to reduce the number of lookups ;-P Oh, and lastly, the patch is just screaming for a re-indent all over, and of some wel-placed comments... some of it was quite difficult to follow, compared to the rest of the code. Just-showing-I-care-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Mon Jul 10 00:34:52 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 17:34:52 -0500 Subject: [Python-Dev] PROTO_LIST in Modules/md5.h In-Reply-To: Your message of "Sun, 09 Jul 2000 15:19:29 -0400." <14696.53313.296096.777677@cj42289-a.reston1.va.home.com> References: <3968EAEB.A06D9A38@stud.ntnu.no> <14696.53313.296096.777677@cj42289-a.reston1.va.home.com> Message-ID: <200007092234.RAA14334@cj20424-a.reston1.va.home.com> > Peter Schneider-Kamp writes: > > Is this still needed with ANSI? > > No, but this is imported code, so perhaps it makes sense to leave > that in. (Both md5.c and md5.h are imported, and are the only places > that have this.) > I won't object to ANSI-fying these two files, but I'm not sure it > makes sense, either. These may as well be an external library. I'd say ANSIfy them. While they are derived from external code, they have been hacked enough, and the MD5 algorithm isn't going to change any time soon, so we might as well reformat them and generally clean them up according to our current taste. Of course, it's not high priority stuff, but sometimes it helps putting our "mark" on code. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jack at oratrix.nl Sun Jul 9 23:50:52 2000 From: jack at oratrix.nl (Jack Jansen) Date: Sun, 09 Jul 2000 23:50:52 +0200 Subject: [Python-Dev] Venting some steam on current developments Message-ID: <20000709215057.95047E2673@oratrix.oratrix.nl> I'm getting pretty depressed at the way Python development is proceeding at the moment. I spent all evening tonight on what seemed to be an almost trivial task: fixing the default unicode conversion on the Mac. All the machinery is there, the MacOS API has some nice conversion routines so I thought it'd be a question of putting in a few hooks and be done, but that turned out not to be so. The first problem (for which I can't blame the Python community, I guess:-) is that the names mac_roman and such are not official IANA names for the Mac encodings. Actually, it turns out there _are_ no official names, so the Mac APIs to turn encodings into names work wonderful for things including all ISO encodings, windows encodings, etc, but not for the native mac encodings. Sigh. Okay, we do this ourselves. Then I spent an hour recompiling Python because this *&^^$%&*^%$ setdefaultencoding didn't show up in sys for no conceivable reason. It turns out it is *deleted* in site.py after using it once. A comment in sysmodule.c would have been rather nice here... And then I found out that locale uses only environment variables to obtain all the basic encoding info in the first place, so that also has to be fixed up seriously. So many things are changing at the moment, and there seems to be so little thought of any platform that isn't linux or windows, that I think Python's portability to minority platforms is being seriously threatened. And at least I follow closely what is happening, I really don't want to think of the poor people who do BeOS or WinCE or Palm Python. Or even some of the lesser-used Unix ports. I'm fed up, I'll continue hacking tomorrow, if I don't have to spend yet another evening trying to get Python to compile again:-( -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From thomas at xs4all.net Sun Jul 9 23:55:47 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 23:55:47 +0200 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 09, 2000 at 05:07:40PM -0400 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Message-ID: <20000709235547.F26534@xs4all.nl> On Sun, Jul 09, 2000 at 05:07:40PM -0400, Tim Peters wrote: > And a new problem popped up early this weekend (maybe Friday already): when > I click the "Browse CVS Repository" link near the bottom right of > > http://sourceforge.net/cvs/?group_id=5470 > > IE5 pops up a box asking me whether I really want to download file "cvsweb". > Useless! This used to work fine, and I sure haven't changed my IE setup. > Clearing the browser caches didn't help. The link resolves to > > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi?cvsroot=python > > today, and I don't know whether it resolved to something different last > week. Also have no idea how browsers decide what to do -- it's not simple & > straightforward, like e.g. floating-point arithmetic . .cgi is not an > extension registered on my machine either. Actually, it's supposed to be simple and straightforward. Unfortunately, certain Windows programs decided not to play along ;) HTTP responses contain a header 'Content-Type', which should be a mimetype for the file the HTTP response accompanies. They may also contain a 'Content-Disposition' header, which contains a suggested filename for when writing the file to disk. Now, the Content-Type thing is working okay nowadays, even though you can override it (sometimes) using the 'helpers' or 'applications' settings in your browser ;) But the Content-Disposition header creates a ton of confusion on IE. Some versions of IE seem to think that when it's present, a file should *always* be saved to disk, instead of shown, regardless of mimetype and/or helper applications. Also, some versions of IE go completely bananas if the Content-Disposition header is listed before the Content-Type header, and gives a very strange response: a 'page not found' error without saying which page it was trying to download ;) I know all this for a fact, because we provide our customers with 'Secure Webmail', a web interface to their email (next to normal interfaces, of course.) And for a long while our helpdesk was forced to tell our IE-using users to switch to Netscape, because IE was giving the above errors, and more. Eventually, my boss and I spent two days with a couple of windows boxes trying to figure out why this was happening. by tcpdumping and tracing exactly what was being sent and received. (Not that easy, given that it was 1) a switched network on our side, 2) a special load-balancing-switch on the server side, and 3) 'Secure' Webmail, using SSL ;) We managed to track the above bugs when using non-SSL connections, but a few bugs remained in SSL only, and we never figured out how or why :P The bugs are really obscure: IE sometimes giving an error when clicking on 'new mailbox', but usually it went fine. IE giving a popup with some unclear error message out of the blue. Sometimes showing images, sometimes offering them for download. All in all, I'm no longer suprised when something dynamic (CGI scripts, php/asp/jsp pages, whatever) refuses to work properly with IE ;) Quite a depressing thing to know, this, but you can't always blame the website-owners or the software developers. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Mon Jul 10 00:08:21 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 18:08:21 -0400 Subject: [Python-Dev] Revision 2 of Patch Manager guidelines Message-ID: I believe the attached addresses all questions (but no "new feature requests") that were raised. Note especially the new threat to do "random assignment" of incoming patches, the new request that you comment on patches assigned to you at least weekly, and the new request that you take yourself off of patches you're assigned to but not actively pursuing. We already have patches just sitting there without action or comment for no apparent reason, and *something* has to force those to move along. at-least-now-we-can-see-which-patches-those-are-ly y'rs - tim Intended use of SourceForge patch status & "assigned to" fields --------------------------------------------------------------- revision 2 09-Jul-2000 In general, the status field should be close to self-explanatory, and the "assigned to" field should be the person responsible for taking the next step in the patch process. Both fields are expected to change value over the life of a patch; the normal workflow is detailed below. When you've got the time and the ability, feel free to move any patch that catches your eye along, whether or not it's been assigned to you. And if you're assigned to a patch but aren't going to take reasonably quick action (for whatever reason), please assign it to someone else ASAP: at those times you can't actively help, actively get out of the way. If you're an expert in some area and know that a patch in that area is both needed and non-controversial, just commit your changes directly -- no need then to get the patch mechanism involved in it. You should add a comment to every patch assigned to you at least once a week, if only to say that you realize it's still on your plate. This rule is meant to force your attention periodically: patches get harder & harder to deal with the longer they sit. Open The initial status of all patches. The patch is under consideration, but has not been reviewed yet. The status will normally change to Accepted or Rejected next. The person submitting the patch should (if they can) assign it to the person they most want to review it. Else the patch will be assigned via [xxx a list of expertise areas should be developed] [xxx but since this hasn't happened and volunteers are too few, random assignment is better than nothing: if you're a Python developer, expect to get assigned out of the blue!] Discussion of major patches is carried out on the Python-Dev mailing list. For simple patches, the SourceForge comment mechanism should be sufficient. [xxx an email gateway would be great, ditto Ping's Roundup] Accepted The powers that be accepted the patch, but it hasn't been applied yet. [xxx flesh out -- Guido Bottleneck avoidable here?] The status will normally change to Closed next. The person changing the status to Accepted should, at the same time, assign the patch to whoever they believe is most likely to be able & willing to apply it (the submitter if possible). Closed The patch has been accepted and applied. The previous status was Accepted, or possibly Open if the submitter was Guido (or moral equivalent in some particular area of expertise). Rejected The patch has been reviewed and rejected. When the objections are addressed, the status may change to Open again. The person changing the status to Rejected should assign the patch back to the submitter, or if it's clear the patch will never be accepted, assign it to None. Note that SourceForge allows the submitter to overwrite the patch with a new version. Out of date Previous status was Open or Accepted or Postponed, but the patch no longer works. Please enter a comment when changing the status to "Out of date", to record the nature of the problem and the previous status. Also assign it back to the submitter, as they need to upload a new version (note that SourceForge will not allow anyone other than the original submitter to update the patch). Postponed The previous status was Open or Accepted, but for some reason (e.g., pending release) the patch should not be reviewed or applied until further notice. The status will normally change to Open or Accepted next. Please enter a comment when changing the status to Postponed, to record the reason, the previous status, and the conditions under which the patch should revert to Open or Accepted. Also assign the patch to whoever is most likely able and willing to decide when the status should change again. Deleted Bit bucket. Use only if it's OK for the patch and its SourceForge history to disappear. As of 09-July-2000, SF does not actually throw away Deleted patches, but that may change. From thomas at xs4all.net Mon Jul 10 00:26:44 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 00:26:44 +0200 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix In-Reply-To: <39690818.917030DE@stud.ntnu.no>; from petersc@stud.ntnu.no on Sun, Jul 09, 2000 at 11:17:44PM +0000 References: <396780B6.67247E2C@stud.ntnu.no> <200007082334.SAA08816@cj20424-a.reston1.va.home.com> <39690818.917030DE@stud.ntnu.no> Message-ID: <20000710002644.G26534@xs4all.nl> On Sun, Jul 09, 2000 at 11:17:44PM +0000, Peter Schneider-Kamp wrote: > While "slaving away" on the Modules/ directory (thanks for > the term - it made my day ), I still haven't got a > clue why Python crashes on me when I throw an error on > duplicate arguments like in: > >>> def f(a, a): print a > segfault > Any help is again appreciated. Hm, strange. It works fine here. Do you get the segfault every time ? Anyway, a possible problem is that PyString_InternFromString might return NULL, and you later PyDict_GetItem() with it (not sure if that's a problem), and you pass it to com_newlocal_o (not sure if that's a problem either), and then you Py_DECREF it. And if you pass NULL to that macro you do have a problem :) You should use Py_XDECREF() if you aren't sure wether the object is NULL or not. If your python left a corefile, you can easily find out if that was the problem by using gdb on it. 'gdb ./python core', wait 'till it finishes loading, and type 'bt'. It should give you reversed (from a python point of view) backtrace from the time of the crash. > ! nameval = PyString_InternFromString(name); > ! if (nameval == NULL) { > ! c->c_errors++; > ! } > ! if (PyDict_GetItem(c->c_locals, nameval)) { > ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); > ! } > ! com_newlocal_o(c, nameval); > ! Py_DECREF(nameval); -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Mon Jul 10 00:33:21 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 18:33:21 -0400 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <20000709215057.95047E2673@oratrix.oratrix.nl> Message-ID: Random question: why isn't the Mac code checked into the main CVS tree? I don't know anything about Mac development, and because the code for it is invisible to me too, have no idea how any change may affect your life (e.g., if Guido hadn't remembered its Mac connection, I would have deleted the USE_STACKCHECK stuff -- for which there is no conceivable use via staring at every file in the CVS true -- not even a doc like "stuff you shouldn't screw with because it's important on the Mac" ). BTW, I heartily agree that the lack of official IANA names for Mac encodings is not my fault. sympathetic-but-too-ignorant-to-help-ly y'rs - tim From paul at prescod.net Mon Jul 10 00:38:24 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 09 Jul 2000 17:38:24 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> Message-ID: <3968FEE0.E1345788@prescod.net> Guido van Rossum wrote: > > ... > Nice idea... Unfortunately it means that every module must be > changed. If we want to do this, we'd best introduce a macro! > E.g. (untested): > > #define Py_INIT(modname) DL_EXPORT(void) init20##modname() Why is it that the init function names has to change for each module? Why not PyModuleMain or something? -- Paul Prescod - Not encumbered by corporate consensus "Computer Associates is expected to come in with better than expected earnings." Bob O'Brien, quoted in - http://www.fool.com/news/2000/foth000316.htm From dberlin at redhat.com Mon Jul 10 00:45:08 2000 From: dberlin at redhat.com (Daniel Berlin+list.python-dev) Date: 09 Jul 2000 18:45:08 -0400 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: "Tim Peters"'s message of "Sun, 9 Jul 2000 18:33:21 -0400" References: Message-ID: <86d7kmly8b.fsf@dan2.cygnus.com> "Tim Peters" writes: > Random question: why isn't the Mac code checked into the main CVS tree? I > don't know anything about Mac development, and because the code for it is > invisible to me too, have no idea how any change may affect your life (e.g., > if Guido hadn't remembered its Mac connection, I would have deleted the > USE_STACKCHECK stuff -- for which there is no conceivable use via staring at > every file in the CVS true -- not even a doc like "stuff you shouldn't screw > with because it's important on the Mac" ). Also, Jack, you said you pity those on lesser known platforms like BeOS. Well, on BeOS, most stuff is posix compliant enough that things like Unicode will work (besides that BeOS has native support for unicode in it's own API's) the way they are written. The only stuff we worry about is dynamic loading of shared libs, and threading. WinCE is probably going to run into the same issues Windows does, more or less. I'm gonna say that Macs are mainly the oddball here, and that mou are running into issues mainly because nobody has had to deal with them, cause it doesn't take that much work to make it work on our favorite platform. > > BTW, I heartily agree that the lack of official IANA names for Mac encodings > is not my fault. > I'll take the blame for this one. I've got broad shoulders. > sympathetic-but-too-ignorant-to-help-ly y'rs - tim > > > From effbot at telia.com Mon Jul 10 00:57:16 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 00:57:16 +0200 Subject: [Python-Dev] new popen for win32! [status update] References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> <200007092202.RAA14221@cj20424-a.reston1.va.home.com> Message-ID: <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> guido wrote: > > the current api is: > > > > popen2.popen2(command, bufsize=default) > > popen2.popen3(command, bufsize=default) > > > > vs. > > > > nt.popen2(command, mode="t") > > nt.popen3(command, mode="t") > > Not commenting on the question here, but on the return tuple: should > it be (i,o,e) or (o,i,e)? The popen2 module uses the latter, but > that's hard to remember for Unix-droids: it corresponds to (1,0,2) in > file descriptors. So if it's not too late, let's do (i,o,e). > > (I tried to read the posixmodule.c source but got lost...) oh, I just changed things around the other way (assuming that "popen2" was some kind of standard). changing things is trivial, decided what's the right way to do it is harder. here's another idea: one way to solve this would be to deprecate "popen2", and move that functionality into the os module -- with the return values sorted out. that is, let's introduce: f = os.popen(cmd, mode, bufsize) w, r = os.popen2(cmd, mode, bufsize) w, r, e = os.popen3(cmd, mode, bufsize) w, r = os.popen4(cmd, mode, bufsize) # windows only, at the moment and mark popen2 as obsolete. whaddayathink? From alex_c at MIT.EDU Mon Jul 10 00:54:44 2000 From: alex_c at MIT.EDU (Alexander S Coventry) Date: Sun, 9 Jul 2000 18:54:44 -0400 (EDT) Subject: [Python-Dev] Problem with 'import site' on Linux In-Reply-To: <20000709221002.A1FB71CF57@dinsdale.python.org> (python-dev-request@python.org) References: <20000709221002.A1FB71CF57@dinsdale.python.org> Message-ID: <200007092254.SAA289432@w20-575-115.mit.edu> The function _locale._getdefaultlocale seems to only be defined if python is compiled for windows, but an attempt is made to call it regardless of the OS in locale.getdefaultlocale. This is causing 'import site' to fail when I start python. I am not sure what ought to be called instead; in my version, for now, I am going to amend the try: except: block that this code is wrapped in so that it catches AttributeError's, as well. The code I'm referring to is around line 262 in Lib/locale.py, and line 343 in Modules/_localemodule.c Alex. From effbot at telia.com Mon Jul 10 01:11:38 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 01:11:38 +0200 Subject: [Python-Dev] Problem with 'import site' on Linux References: <20000709221002.A1FB71CF57@dinsdale.python.org> <200007092254.SAA289432@w20-575-115.mit.edu> Message-ID: <033001bfe9fb$09a16b20$f2a6b5d4@hagrid> alexander wrote: > The function _locale._getdefaultlocale seems to only be defined if > python is compiled for windows, but an attempt is made to call it > regardless of the OS in locale.getdefaultlocale. This is causing > 'import site' to fail when I start python. I am not sure what ought to > be called instead; in my version, for now, I am going to amend the try: > except: block that this code is wrapped in so that it catches > AttributeError's, as well. > > The code I'm referring to is around line 262 in Lib/locale.py, and line > 343 in Modules/_localemodule.c I'll fix this in the repository. the except clause should catch AttributeError, not NameError. sorry /F From effbot at telia.com Mon Jul 10 01:12:16 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 01:12:16 +0200 Subject: [Python-Dev] Venting some steam on current developments References: <20000709215057.95047E2673@oratrix.oratrix.nl> Message-ID: <033301bfe9fb$209d3520$f2a6b5d4@hagrid> jack wrote: > The first problem (for which I can't blame the Python community, I > guess:-) is that the names mac_roman and such are not official IANA > names for the Mac encodings. Actually, it turns out there _are_ no > official names, so the Mac APIs to turn encodings into names work > wonderful for things including all ISO encodings, windows encodings, > etc, but not for the native mac encodings. Sigh. Okay, we do this > ourselves. > Then I spent an hour recompiling Python because this *&^^$%&*^%$ > setdefaultencoding didn't show up in sys for no conceivable reason. It > turns out it is *deleted* in site.py after using it once. A comment in > sysmodule.c would have been rather nice here... mail problems? didn't I send you a couple of mails discussing what needed to be done, including where you could reach me over the weekend? did you see my changes to the locale module? I rewrote the darn thing to make it easier to deal with this on non-posix platforms, and posted the locale.py patch to the patch manager (the CVS repository had a stale lock, so I couldn't check it in before today). heck, I even sent you some pseudocode that showed one way to implement parts of _getdefaultlocale for the mac, and still you claim that we're ignoring non unix/windows platforms? you could have asked for help a little earlier, you know... From billtut at microsoft.com Mon Jul 10 01:06:50 2000 From: billtut at microsoft.com (Bill Tutt) Date: Sun, 9 Jul 2000 16:06:50 -0700 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC Wi nMain.c,1.3,1.4 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD29A@RED-MSG-50> Heh. Part of the win32 extension building process is to stamp version resources into binaries. That's what the rc file is for. Bill From barry at scottb.demon.co.uk Mon Jul 10 01:15:49 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Mon, 10 Jul 2000 00:15:49 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007092152.QAA14143@cj20424-a.reston1.va.home.com> Message-ID: <000401bfe9fb$9e5050b0$060210ac@private> The key problem here is that the python engine needs to verify the version of python that the extension supports before allowing the extension to do anything dangerous. Maybe the solution is a pair of functions and a bit of protocol. The first function is used for version checking. int check_version_##module_name(); The second function will do the init as today. init init##module_name(); Based on the outcome of calling the check_version function python can decide if it should call the init function. Issues with the check_version function that I can think of are: * how is a python version represented? * should the check_version function be passed the calling python's version? This would allow smart extensions to adapt to the invoking python's version dependent features. Barry From mhammond at skippinet.com.au Mon Jul 10 01:48:49 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 9 Jul 2000 19:48:49 -0400 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 In-Reply-To: <019501bfe920$18cee220$f2a6b5d4@hagrid> Message-ID: > stupid question: what exactly does the RC file do here: > > STRINGTABLE DISCARDABLE > BEGIN > 2000 "Dummy" // Needed to version branding works! > END > > (couldn't really parse that comment ;-) The "to" should be "so" - that will make it parse better, but probably still doesnt answer your question :-) Greg wrote a script that I use to brand .DLL/.EXE files with a version resource - eg, I brand the win32all package _after_ the final build - the version strings are written after it has been built and tested. However, this code fails for .DLL/.EXE files without any resources at all. This dummy resource gets around that problem. It can safely be ignored for inclusion into the core... Mark. From mhammond at skippinet.com.au Mon Jul 10 01:48:52 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 9 Jul 2000 19:48:52 -0400 Subject: [Python-Dev] new popen for win32! In-Reply-To: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> Message-ID: > - first, a stupid question: is the popen2 and popen3 > versions replacements for the corresponding functions > in the popen2 module. I believe Bill was first :-) Note that the param order may be different, and should be made the same. > (or to put it another way: should the popen2 module > be modified to use these functions on Windows?) IMO, yes. > - should this go into the "nt" (posix) module, or should > I create a new module? for no good reason, I would lean towards the NT module, but a seperate source file. > - "win32popenWin9x.exe" is a rather unwieldy name for a > file. does anyone have a better suggestion? I think the name can be unwieldy, as no one will ever execute this directly. The name should reflect its purpose, so no one says "hey - I never run this .exe, so I can remove it. > py_popen9x.exe I agree with Tim that "popen9x.exe" is fine. > - I'm using VC5 on this box, so I should probably avoid > checking in my modified project files. any VC6-wielding > volunteers out there? If its not done by the time I return to Oz, I will be happy to do it. However, I bet Bill beats me too it (unless someone explains to Tim what is expected of him, and off he goes :-) Mark. From petersc at stud.ntnu.no Mon Jul 10 04:14:05 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 02:14:05 +0000 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix References: <396780B6.67247E2C@stud.ntnu.no> <200007082334.SAA08816@cj20424-a.reston1.va.home.com> <39690818.917030DE@stud.ntnu.no> <20000710002644.G26534@xs4all.nl> Message-ID: <3969316D.467C85FA@stud.ntnu.no> Thomas Wouters wrote: > > Hm, strange. It works fine here. Do you get the segfault every time ? What system? Which version (I guess this day's CVS)? I get the segfault every time the error should be thrown. > Anyway, a possible problem is that PyString_InternFromString might return > NULL, and you later PyDict_GetItem() with it (not sure if that's a problem), > and you pass it to com_newlocal_o (not sure if that's a problem either), and > then you Py_DECREF it. And if you pass NULL to that macro you do have a > problem :) You should use Py_XDECREF() if you aren't sure wether the object > is NULL or not. No, that does not seem to be the problem. The segfault happens in PyErr_NormalizeException where PyClass_Check(type) accesses type->ob_type. I'm giving up for today. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From esr at thyrsus.com Mon Jul 10 02:40:09 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 9 Jul 2000 20:40:09 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: ; from pingster@ilm.com on Fri, Jul 07, 2000 at 03:26:13PM -0700 References: <20000707103308.8074FE2673@oratrix.oratrix.nl> Message-ID: <20000709204009.A4566@thyrsus.com> Ka-Ping Yee : > Hmm, i rather like this idea. Actually, i like it enough to > suggest that "launch" would be a good interface to external > applications -- > > launch.filebrowser("/home") > launch.webbrowser("http://www.python.org/", newwindow=1) > launch.mailreader() > launch.mailcomposer("python-dev at python.org", subject="Spam") > launch.textviewer("README") > launch.texteditor("spam.py") > launch.shell("/usr") > launch.remoteshell("unseen.python.org", port=23) > > On Unix this would take advantage of (and formalize) the PAGER, > EDITOR, BROWSER, etc. environment variables; on Windows they > could look at registry settings, and for Mac, they could use IC. I like it. -- Eric S. Raymond ..every Man has a Property in his own Person. This no Body has any Right to but himself. The Labour of his Body, and the Work of his Hands, we may say, are properly his. .... The great and chief end therefore, of Mens uniting into Commonwealths, and putting themselves under Government, is the Preservation of their Property. -- John Locke, "A Treatise Concerning Civil Government" From guido at beopen.com Mon Jul 10 03:49:26 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 20:49:26 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Sun, 09 Jul 2000 17:38:24 EST." <3968FEE0.E1345788@prescod.net> References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> Message-ID: <200007100149.UAA16917@cj20424-a.reston1.va.home.com> > Guido van Rossum wrote: > > > > ... > > Nice idea... Unfortunately it means that every module must be > > changed. If we want to do this, we'd best introduce a macro! > > E.g. (untested): > > > > #define Py_INIT(modname) DL_EXPORT(void) init20##modname() Paul Prescod replies: > Why is it that the init function names has to change for each module? > Why not PyModuleMain or something? Because Python supports a configuration time option to link modules statically. BArry Scott replies: > The key problem here is that the python engine needs to > verify the version of python that the extension supports > before allowing the extension to do anything dangerous. > > Maybe the solution is a pair of functions and a bit of > protocol. > > The first function is used for version checking. > > int check_version_##module_name(); > > The second function will do the init as today. > > init init##module_name(); > > Based on the outcome of calling the check_version function > python can decide if it should call the init function. > > Issues with the check_version function that I can think of > are: > > * how is a python version represented? > * should the check_version function be passed the calling > python's version? This would allow smart extensions to > adapt to the invoking python's version dependent features. There are endless variations on this theme. What's missing at the moment is a bit of requirements analysis. What's the problem we're trying to solve here? So far, the only problem that came up was that on Windows, you get an obscure crash when trying to load an extension built for Python 1.5(.x). Do we really need a whole new version negotiating architecture? You can already get the version string by looking at Py_GetVersion() -- this also answers the question of how a version is represented. On Windows, link-time compatibility is broken whenever we change the second digit of the version number, e.g. 15, 16, 20. On Unix, there's also a different version (the API version, see modsupport.h) which is checked when the module initializes itself (it's hidden in the call to Py_InitModule() that the module makes). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 04:09:04 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 21:09:04 -0500 Subject: [Python-Dev] new popen for win32! [status update] In-Reply-To: Your message of "Mon, 10 Jul 2000 00:57:16 +0200." <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> <200007092202.RAA14221@cj20424-a.reston1.va.home.com> <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> Message-ID: <200007100209.VAA16999@cj20424-a.reston1.va.home.com> > oh, I just changed things around the other way (assuming that > "popen2" was some kind of standard). > > changing things is trivial, decided what's the right way to do it > is harder. here's another idea: > > one way to solve this would be to deprecate "popen2", and move > that functionality into the os module -- with the return values > sorted out. that is, let's introduce: > > f = os.popen(cmd, mode, bufsize) > w, r = os.popen2(cmd, mode, bufsize) > w, r, e = os.popen3(cmd, mode, bufsize) > w, r = os.popen4(cmd, mode, bufsize) # windows only, at the moment > > and mark popen2 as obsolete. > > whaddayathink? Ah, I finally see the problem here. Sigh... Both orders are equally logical -- depending on your point of view! This is of course because pipes have a read end and a write end. So stdin is read by the child but written by the parent, and stdout is written by the child and read by the parent. From fdrake at beopen.com Mon Jul 10 04:38:01 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 22:38:01 -0400 (EDT) Subject: [Python-Dev] PROTO_LIST in Modules/md5.h In-Reply-To: <200007092234.RAA14334@cj20424-a.reston1.va.home.com> References: <3968EAEB.A06D9A38@stud.ntnu.no> <14696.53313.296096.777677@cj42289-a.reston1.va.home.com> <200007092234.RAA14334@cj20424-a.reston1.va.home.com> Message-ID: <14697.14089.167736.898381@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > Of course, it's not high priority stuff, but sometimes it helps > putting our "mark" on code. :-) Hey, we should talk to my dog. She knows all about marking her territory. ;-) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tmacd at eintelligence-inc.com Mon Jul 10 05:27:05 2000 From: tmacd at eintelligence-inc.com (Tom MacDonald) Date: Sun, 9 Jul 2000 22:27:05 -0500 (CDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: from "Tim Peters" at Jul 09, 2000 01:23:03 AM Message-ID: <200007100327.e6A3R5F25974@sundeva.eintelligence-inc.com> > [Tim, pushing the adoption of some C9X-like typedefs in Python's source] > > ... > > the-committee-wasn't-just-jerking-off-the-last-10-years-ly y'rs - > > tim > > [Ken Manheimer] > > (The obvious question is, where they doing those other things at the same > > time, or during breaks?) > > It varies by member. For example, the Reverend Tom MacDonald jerked off > non-stop the entire time (& I've copied him on this for confirmation). But > a surprising number of the members have never jerked off at all! You know me Tim. Ever since you showed me the pictures of mad dog and butcher vachon I can't stop. Interesting question but the committee never took a role call vote on that question. > Rev Tom, after 118 years serving on X3J11, do you think C9X is a good thing > or a bad thing? And do you still get off on it regardless? And what does > God think about C9X? If I have to boil C99 down to either good or bad, I'll pick good. It cleans up a lot of fuzzy words from C89, addresses some missing features that should be there (e.g., variable length arrays, long long, hex floating constants, // comments, , intmax_t, mixed declarations and code, designated initializers). There are features, though, that I wish were not there. The biggest being the complex type. This seems a tad ironic since I pushed for complex early on in the C99 process. I didn't realize that IEEE arithmetic made a complex type grow like the blob - even an imaginary type is there for those that want everything IEEE arithmetic has to offer. I18N was added (I think). I never could figure out if we made everybody that spoke their own language happy or not. It sure made C99 a lot bigger. Almost all of it in the library - though an implementation can support identifiers containing international characters. I don't like the following features: flexible array members, the number of new functions and operators required to support IEEE arithmetic, the LIA compatibility annex, and C99 style boolean support. I like the rest of it. However, no matter what I think, I don't see any vendors rushing to implement C99. Instead vendors are picking some C99 features and implementing those. So, perhaps the the answer to the question of whether C99 is good or bad is only interesting if someone actually implements it. Actually, you need several vendors to implement it. One reason C89 was so successful is that all vendors implemented it. I still like C. In my new job I'm using C++ all the time. I'm probably getting old and can't appreciate all this stuff C++ does for me under the covers, but I can never figure out which overloaded function or operator is actually instantiated by template such-n-such. With C, I can always see what's going on. So yes, I sill got off on it. I asked God what he thought about C99 and he said he didn't have an opinion on C99 cause he always uses python. Rev. Tom From fdrake at beopen.com Mon Jul 10 05:59:26 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 23:59:26 -0400 (EDT) Subject: [Python-Dev] ANSI-fication patches Message-ID: <14697.18974.492954.234194@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp recently submitted a large number of patches to make the C sources in the Modules/ directory ANSI compliant. I've passed most of these back to him for checkin, but for a number of them he commented that he had not tested them (presumably because he doesn't have SGI hardware, or some of the esoteric libraries shipped with IRIX). If someone could look at the ones that are still unassigned and comment on their passing tests, that would be great. Just add a comment to the patch or mark it accepted and pass it back to Peter ("nowonder" on SF). Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From moshez at math.huji.ac.il Mon Jul 10 07:04:05 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 10 Jul 2000 08:04:05 +0300 (IDT) Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: Message-ID: On Sun, 9 Jul 2000, Jeremy Hylton wrote: > In the Perl world, there is a weekly summary of discussion on the > perl5-porters list. It seems to be written by Mark-Jason Dominus most > (all?) of the time. We could do the same thing if we could find people to > do it. Perhaps a weekly Python-dev URL? If we had enough reporters, it > might not be too much work. > > Volunteers? I'd be happy to coordinate. I can volunteer, but I'd like to know a week in advance (and not every week, obviously) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From moshez at math.huji.ac.il Mon Jul 10 07:15:21 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 10 Jul 2000 08:15:21 +0300 (IDT) Subject: [Python-Dev] Out of loop... In-Reply-To: <20000709214058.D26534@xs4all.nl> Message-ID: On Sun, 9 Jul 2000, Thomas Wouters wrote: > On Sun, Jul 09, 2000 at 03:21:41PM -0400, Fred L. Drake, Jr. wrote: > > > Ok, it's been a busy week, and my wife & kids are just about back. > > I'll be largely out of touch here for about 24 hours. It's time to > > play with the kids! > > Damn, this scares me. Even at my real-life job we don't warn eachother when > we're out of the loop for a day or so. We've had a colleague go on a > vacation, and not be missed for like a week before anyone started wondering > where he was ;-) And here is Fred apologizing for spending a day with his > family. Is it too late for me to opt out ?!? Fred does it only out of courtesy. The PSU keeps track of all Python-Dev members, in case on of them is needed. If you need to find some Python-Dev member, just contact your local PSU representative. if-you-don't-know-who-he-is-you-got-a-*big*-problem-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From petersc at stud.ntnu.no Mon Jul 10 09:47:44 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 07:47:44 +0000 Subject: [Python-Dev] CVS read/write access Message-ID: <39697FA0.ADD1BB17@stud.ntnu.no> Thanks to Fred I now have 35 of my own patches assigned to me. Unfortunately trying to checkout read/write in order to be able to commit later I get this: nowonder at mobility:~/python > export CVS_RSH=ssh nowonder at mobility:~/python > export CVSROOT=nowonder at cvs.python.sourceforge.net:/cvsroot/python nowonder at mobility:~/python > cvs co python nowonder at cvs.python.sourceforge.net's password: Sorry, you don't have read/write access to the history file /cvsroot/python/CVSROOT/history Permission denied nowonder at mobility:~/python > As I also see no way to change the status of my patches, maybe some UserPermissions still need to be set. Maybe something like ? CVS write: yes ? Patch Manager: Tech & Admin But then I don't really know that much about sourceforge. For my own pet project (LegoVision) I just got one developer ;-) Thanks anyway, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From tim_one at email.msn.com Mon Jul 10 08:14:56 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 02:14:56 -0400 Subject: [Python-Dev] CVS read/write access In-Reply-To: <39697FA0.ADD1BB17@stud.ntnu.no> Message-ID: [Peter Schneider-Kamp] > Thanks to Fred I now have 35 of my own patches assigned to me. > Unfortunately trying to checkout read/write in order to be > able to commit later I get this: > > nowonder at mobility:~/python > export CVS_RSH=ssh > nowonder at mobility:~/python > export > CVSROOT=nowonder at cvs.python.sourceforge.net:/cvsroot/python Perhaps CVSROOT should have :ext: at the start? Here's mine: set CVSROOT=:ext:tim_one at cvs.python.sourceforge.net:/cvsroot/python Monkey see, monkey do, usually works best for software written by apes . > nowonder at mobility:~/python > cvs co python > nowonder at cvs.python.sourceforge.net's password: > Sorry, you don't have read/write access to the history file > /cvsroot/python/CVSROOT/history > Permission denied > nowonder at mobility:~/python > > As I also see no way to change the status of my patches, maybe > some UserPermissions still need to be set. > Maybe something like > > ? CVS write: yes > ? Patch Manager: Tech & Admin Bingo on this one: your Patch Manager permissions were set to "Tech only". I think that's the default. I've changed them to "Tech & Admin" for nowonder, so that problem should be solved now. > But then I don't really know that much about sourceforge. For my own > pet project (LegoVision) I just got one developer ;-) Ya, but at least you can release it when you want to . grass-is-greener-ly y'rs - tim From petersc at stud.ntnu.no Mon Jul 10 10:27:47 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 08:27:47 +0000 Subject: [Python-Dev] CVS read/write access References: Message-ID: <39698903.1EFDBFBA@stud.ntnu.no> Tim Peters wrote: > > Perhaps CVSROOT should have > > :ext: > > at the start? Here's mine: > > set CVSROOT=:ext:tim_one at cvs.python.sourceforge.net:/cvsroot/python No, doesn't change a thing. Unfortunately. > Monkey see, monkey do, usually works best for software written by apes > . Just what I did. Just that I looked at the CVS Howto. But I think the problem is somewhere else. > Bingo on this one: your Patch Manager permissions were set to "Tech only". > I think that's the default. I've changed them to "Tech & Admin" for > nowonder, so that problem should be solved now. Yes, thanx alot! Wasn't there something about CVS write access though? > > But then I don't really know that much about sourceforge. For my own > > pet project (LegoVision) I just got one developer ;-) > > Ya, but at least you can release it when you want to . Ooh, where is the point in the license telling me I cannot release Python, too <1.5 wink>? just-joking-but-wait-a-month-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From tim_one at email.msn.com Mon Jul 10 09:02:39 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 03:02:39 -0400 Subject: [Python-Dev] CVS read/write access In-Reply-To: <39698903.1EFDBFBA@stud.ntnu.no> Message-ID: >> Perhaps CVSROOT should have >> >> :ext: >> >> at the start? Here's mine: >> >> set CVSROOT=:ext:tim_one at cvs.python.sourceforge.net:/cvsroot/python [Peter S-K] > No, doesn't change a thing. Unfortunately. I was well beyond my area of competence with the first suggestion . You could get a real OS like me (Win98SE), or hope that one of your Unixish compatriots helps out. Maybe it would help if you told them other stuff about your setup (OS, version, CVS version, whether CVS works in other contexts for you, etc). > ... Wasn't there something about CVS write access though? *Everyone* on the Member Admin page has "Yes" under "CVS write", and there are no controls there even to change that to "No". Maybe it's one of these 4-hour SourceForge delay thingies? Doubt it, but it's a darned good excuse for me to go to sleep now . > Ooh, where is the point in the license telling me I cannot > release Python, too <1.5 wink>? > > just-joking-but-wait-a-month-ly y'rs > Peter Indeed, if we still haven't released Python after another month, I'm going to leave BeOpen PythonLabs and go to work somewhere I can <0.6 wink>. From effbot at telia.com Mon Jul 10 09:18:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 09:18:45 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules md5.h,2.5,2.6 md5c.c,2.3,2.4 References: <200007100421.VAA16454@slayer.i.sourceforge.net> Message-ID: <004201bfea3f$17b154c0$f2a6b5d4@hagrid> Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv16446 > > Modified Files: > md5.h md5c.c > Log Message: > > Guido said include these in the Great ANSI-fication, so here they are! weren't you supposed to drop out of sight for a while? besides, I'd assigned these patches to myself, and applied them locally. just thought I'd get some sleep before I checked them in again. (iow, please check the patch archive before hacking along. someone else might be working on the same thing) From petersc at stud.ntnu.no Mon Jul 10 11:27:49 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 09:27:49 +0000 Subject: [Python-Dev] CVS read/write access References: Message-ID: <39699715.E3368F53@stud.ntnu.no> Tim Peters wrote: > > I was well beyond my area of competence with the first suggestion . > You could get a real OS like me (Win98SE), or hope that one of your Unixish > compatriots helps out. Maybe it would help if you told them other stuff > about your setup (OS, version, CVS version, whether CVS works in other > contexts for you, etc). No, this is a python/sourceforge thing. cvs/ssh/sourceforge works just fine: nowonder at mobility:~/python > export CVS_RSH=ssh nowonder at mobility:~/python > export CVSROOT=nowonder at cvs.legovision.sourceforge.net:/cvsroot/legovision nowonder at mobility:~/python > cvs co legovision nowonder at cvs.legovision.sourceforge.net's password: cvs server: Updating legovision U legovision/LICENSE.txt U legovision/README.html cvs server: Updating legovision/LookingLego U legovision/LookingLego/ImageProcessing.cpp U legovision/LookingLego/ImageProcessing.h U legovision/LookingLego/InfraRed.cpp U legovision/LookingLego/InfraRed.h [cut - that's enough] > *Everyone* on the Member Admin page has "Yes" under "CVS write", and there > are no controls there even to change that to "No". Maybe it's one of these > 4-hour SourceForge delay thingies? Doubt it, but it's a darned good excuse > for me to go to sleep now . 6 hours that is, but possible. Hadn't thought of that one. I'll just wait some hours and try again (sounds like "okay, I'll reinstall Windows 98SE and try again" :}). I'll save some bandwidth until then, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From effbot at telia.com Mon Jul 10 09:46:36 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 09:46:36 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules md5.h,2.5,2.6 md5c.c,2.3,2.4 Message-ID: <008901bfea43$34f14a00$f2a6b5d4@hagrid> I wrote: > besides, I'd assigned these patches to myself, and applied > them locally. just thought I'd get some sleep before I checked > them in again. > > (iow, please check the patch archive before hacking along. > someone else might be working on the same thing) oh, I see. these patches were marked as "accepted", so they didn't show up on the main page. this is clearly a drawback of the "open => accepted => closed" scheme; you have to check several places before you know if something is being worked on... (having an "all except closed, rejected, delete" selection would be nice. roundup can do that, of course ;-) From gstein at lyra.org Mon Jul 10 10:32:50 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 01:32:50 -0700 Subject: [Python-Dev] CVS: python/dist/src/Modules posixmodule.c,2.143,2.144 In-Reply-To: <200007091310.GAA27888@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Sun, Jul 09, 2000 at 06:10:48AM -0700 References: <200007091310.GAA27888@slayer.i.sourceforge.net> Message-ID: <20000710013250.P29590@lyra.org> hmm. should that be PyLong_FromVoidPtr() ? It will return the appropriate object type based on the size of a void*. Cheers, -g On Sun, Jul 09, 2000 at 06:10:48AM -0700, Fredrik Lundh wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv27646/Modules > > Modified Files: > posixmodule.c > Log Message: > > > - fixed pointer size test in spawn functions. also added > cast to make sure Py_BuildValue gets the right thing. > > this change eliminates bogus return codes from successful > spawn calls (e.g. 2167387144924954624 instead of 0). > > Index: posixmodule.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v > retrieving revision 2.143 > retrieving revision 2.144 > diff -C2 -r2.143 -r2.144 > *** posixmodule.c 2000/07/08 22:48:53 2.143 > --- posixmodule.c 2000/07/09 13:10:40 2.144 > *************** > *** 1541,1548 **** > return posix_error(); > else > ! #if SIZEOF_LONG == SIZE_VOID_P > ! return Py_BuildValue("l", spawnval); > #else > ! return Py_BuildValue("L", spawnval); > #endif > } > --- 1541,1548 ---- > return posix_error(); > else > ! #if SIZEOF_LONG == SIZEOF_VOID_P > ! return Py_BuildValue("l", (long) spawnval); > #else > ! return Py_BuildValue("L", (LONG_LONG) spawnval); > #endif > } > *************** > *** 1649,1656 **** > (void) posix_error(); > else > ! #if SIZEOF_LONG == SIZE_VOID_P > ! res = Py_BuildValue("l", spawnval); > #else > ! res = Py_BuildValue("L", spawnval); > #endif > > --- 1649,1656 ---- > (void) posix_error(); > else > ! #if SIZEOF_LONG == SIZEOF_VOID_P > ! res = Py_BuildValue("l", (long) spawnval); > #else > ! res = Py_BuildValue("L", (LONG_LONG) spawnval); > #endif > > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 10 10:43:29 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 01:43:29 -0700 Subject: [Python-Dev] CVS read/write access In-Reply-To: <39699715.E3368F53@stud.ntnu.no>; from petersc@stud.ntnu.no on Mon, Jul 10, 2000 at 09:27:49AM +0000 References: <39699715.E3368F53@stud.ntnu.no> Message-ID: <20000710014329.Q29590@lyra.org> I lost the original note, but I recall that it said you couldn't write the "history" file. If so, then it is a problem that the SF Admins must solve. It means that you haven't been placed into the appropriate group or somesuch on SF. Log a support request with the copy of your output. Cheers, -g On Mon, Jul 10, 2000 at 09:27:49AM +0000, Peter Schneider-Kamp wrote: > Tim Peters wrote: > > > > I was well beyond my area of competence with the first suggestion . > > You could get a real OS like me (Win98SE), or hope that one of your Unixish > > compatriots helps out. Maybe it would help if you told them other stuff > > about your setup (OS, version, CVS version, whether CVS works in other > > contexts for you, etc). > > No, this is a python/sourceforge thing. cvs/ssh/sourceforge works just > fine: > > nowonder at mobility:~/python > export CVS_RSH=ssh > nowonder at mobility:~/python > export > CVSROOT=nowonder at cvs.legovision.sourceforge.net:/cvsroot/legovision > nowonder at mobility:~/python > cvs co legovision > nowonder at cvs.legovision.sourceforge.net's password: > cvs server: Updating legovision > U legovision/LICENSE.txt > U legovision/README.html > cvs server: Updating legovision/LookingLego > U legovision/LookingLego/ImageProcessing.cpp > U legovision/LookingLego/ImageProcessing.h > U legovision/LookingLego/InfraRed.cpp > U legovision/LookingLego/InfraRed.h > [cut - that's enough] > > > *Everyone* on the Member Admin page has "Yes" under "CVS write", and there > > are no controls there even to change that to "No". Maybe it's one of these > > 4-hour SourceForge delay thingies? Doubt it, but it's a darned good excuse > > for me to go to sleep now . > > 6 hours that is, but possible. Hadn't thought of that one. I'll > just wait some hours and try again (sounds like "okay, I'll > reinstall Windows 98SE and try again" :}). > > I'll save some bandwidth until then, > Peter > -- > Peter Schneider-Kamp ++47-7388-7331 > Herman Krags veg 51-11 mailto:peter at schneider-kamp.de > N-7050 Trondheim http://schneider-kamp.de > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 10 11:09:31 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:09:31 -0700 Subject: [Python-Dev] Re: CVS: python/dist/src/Lib locale.py,1.7,1.8 In-Reply-To: <200007091713.KAA02613@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Sun, Jul 09, 2000 at 10:13:00AM -0700 References: <200007091713.KAA02613@slayer.i.sourceforge.net> Message-ID: <20000710020930.T29590@lyra.org> This checkin was *very* hard to review. In fact, I just gave up. The problem is that you did functional changes *AND* white space changes. A bunch of lines appear changed, but they're just whitespace change. The *real* changes are hidden in there somewhere. Can I request (from everyone) to do white space changes *only*, or to do functional changes *only*. It will make it a lot easier on the people who are reviewing the checkins. thx! -g On Sun, Jul 09, 2000 at 10:13:00AM -0700, Fredrik Lundh wrote: > Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2501/Lib > > Modified Files: > locale.py > Log Message: > > > - merged setlocale and set_locale. the internal setlocale > function is overridden by a python version which accepts > *either* a string (old behaviour) or a locale tuple. > > - renamed a few methods (for consistency): > > get_locale => getlocale > get_default_locale => getdefaultlocale > set_to_default => resetlocale (!) > > - the _locale implementation module can now implement > an optional _getdefaultlocale function. if that function > isn't available, a POSIX-based approach is used (checking > LANG and other environment variables, as usual). -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Mon Jul 10 11:16:13 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 11:16:13 +0200 Subject: [Python-Dev] Re: CVS: python/dist/src/Lib locale.py,1.7,1.8 References: <200007091713.KAA02613@slayer.i.sourceforge.net> <20000710020930.T29590@lyra.org> Message-ID: <00b901bfea4f$7f24d720$f2a6b5d4@hagrid> greg wrote: > This checkin was *very* hard to review. In fact, I just gave up. > > The problem is that you did functional changes *AND* white space changes. A > bunch of lines appear changed, but they're just whitespace change. The > *real* changes are hidden in there somewhere. my current editor setup strips bogus trailing whitespace all by itself. once they're gone, it's a bit hard to put them back... the important changes are in getdefaultlocale and the overriding setlocale function. From gstein at lyra.org Mon Jul 10 11:20:48 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:20:48 -0700 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007100149.UAA16917@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Sun, Jul 09, 2000 at 08:49:26PM -0500 References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> Message-ID: <20000710022047.V29590@lyra.org> On Sun, Jul 09, 2000 at 08:49:26PM -0500, Guido van Rossum wrote: > > Guido van Rossum wrote: > > > > > > ... > > > Nice idea... Unfortunately it means that every module must be > > > changed. If we want to do this, we'd best introduce a macro! > > > E.g. (untested): > > > > > > #define Py_INIT(modname) DL_EXPORT(void) init20##modname() > > Paul Prescod replies: > > > Why is it that the init function names has to change for each module? > > Why not PyModuleMain or something? > > Because Python supports a configuration time option to link modules > statically. Not to mention that the .so is loaded into the process' address space. I don't think that you can have two symbols in the space with the same name. But hey... even if you can: the static link option Guido mentions is definitely the kicker. Cheers, -g -- Greg Stein, http://www.lyra.org/ From petersc at stud.ntnu.no Mon Jul 10 13:29:29 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 11:29:29 +0000 Subject: [Python-Dev] file closed! (was Re: CVS read/write access) References: <39699715.E3368F53@stud.ntnu.no> <20000710014329.Q29590@lyra.org> Message-ID: <3969B399.FC5E1AC2@stud.ntnu.no> Greg Stein wrote: > > If so, then it is a problem that the SF Admins must solve. It means that you > haven't been placed into the appropriate group or somesuch on SF. Log a ----- It was the group. But 20 minutes after I found out I checked again and suddenly python had appeared. Must have been this cron delay. Sorry-for-wasting-your-time Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gstein at lyra.org Mon Jul 10 11:35:24 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:35:24 -0700 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 09, 2000 at 05:07:40PM -0400 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Message-ID: <20000710023523.Y29590@lyra.org> bah. just file feature requests for them to use ViewCVS. cvsweb is a piece of crap anyways :-) Cheers, -g On Sun, Jul 09, 2000 at 05:07:40PM -0400, Tim Peters wrote: > [Fred L. Drake, Jr. > Sent: Wednesday, June 28, 2000 9:30 AM] > > ... > > the only problem I've had with IE5 is accessing a project's anonymous > > FTP area from the project page (IE5 just froze completely). > > This happens to me too. > > And a new problem popped up early this weekend (maybe Friday already): when > I click the "Browse CVS Repository" link near the bottom right of > > http://sourceforge.net/cvs/?group_id=5470 > > IE5 pops up a box asking me whether I really want to download file "cvsweb". > Useless! This used to work fine, and I sure haven't changed my IE setup. > Clearing the browser caches didn't help. The link resolves to > > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi?cvsroot=python > > today, and I don't know whether it resolved to something different last > week. Also have no idea how browsers decide what to do -- it's not simple & > straightforward, like e.g. floating-point arithmetic . .cgi is not an > extension registered on my machine either. -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 10 11:40:58 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:40:58 -0700 Subject: [Python-Dev] [OT] IE5 weirdness (was: Sourceforge Interface Concerns) In-Reply-To: <20000709235547.F26534@xs4all.nl>; from thomas@xs4all.net on Sun, Jul 09, 2000 at 11:55:47PM +0200 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> <20000709235547.F26534@xs4all.nl> Message-ID: <20000710024058.Z29590@lyra.org> On Sun, Jul 09, 2000 at 11:55:47PM +0200, Thomas Wouters wrote: >... >... Content-Type and Content-Disposition discussion ... >... > All in all, I'm no longer suprised when something dynamic (CGI scripts, > php/asp/jsp pages, whatever) refuses to work properly with IE ;) Quite a > depressing thing to know, this, but you can't always blame the > website-owners or the software developers. No doubt. I'm there with you. While working on the DAV stuff, I found that it totally bombs on a GET on a DAV resource when the Last-Modified header is not returned. (!!) Of course, dynamic scripts practically never return that, so I had to insert the following in my httpd.conf: Header set Last-Modified "Fri, 03 Mar 2000 06:32:31 GMT" Pretty fuggin broken, if you ask me :-) Oh. Even more broken: it makes you send the time. It doesn't display it in the Windows Explorer / Web Folder like you would expect. The "Modified" column is simply blank. *boggle* Cheers, -g -- Greg Stein, http://www.lyra.org/ From jack at oratrix.nl Mon Jul 10 11:45:41 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 10 Jul 2000 11:45:41 +0200 Subject: [Python-Dev] Symantec C compiler Message-ID: <20000710094541.9A02C37186D@snelboot.oratrix.nl> Folks, there are talks in python-dev of cleaning out ifdefs for the Symantec C compiler (__SC__). So, if anyone still uses it: scream loudly now or remain forever silent. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From gstein at lyra.org Mon Jul 10 11:49:05 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:49:05 -0700 Subject: [Python-Dev] [OT] version branding (was: CVS: python/dist/src/PC WinMain.c,1.3,1.4) In-Reply-To: ; from mhammond@skippinet.com.au on Sun, Jul 09, 2000 at 07:48:49PM -0400 References: <019501bfe920$18cee220$f2a6b5d4@hagrid> Message-ID: <20000710024905.A29590@lyra.org> On Sun, Jul 09, 2000 at 07:48:49PM -0400, Mark Hammond wrote: > > stupid question: what exactly does the RC file do here: > > > > STRINGTABLE DISCARDABLE > > BEGIN > > 2000 "Dummy" // Needed to version branding works! > > END > > > > (couldn't really parse that comment ;-) > > The "to" should be "so" - that will make it parse better, but probably > still doesnt answer your question :-) > > Greg wrote a script that I use to brand .DLL/.EXE files with a version > resource - eg, I brand the win32all package _after_ the final build - the > version strings are written after it has been built and tested. Heh. I wrote that after going through gyration after frustrating gyration with the Site Server "Build Team". Those guys had their little fiefdom and were responsible for building the product. You had to conform to their idiotic concepts and tools. Well, one of the worst was this complicated set of include files, macros, and other small tools to construct a version resource in the .rc file. Well, during the build process, you had to make sure that the "write the current version into so it can be picked up by the version.rc include stuff" actually got run. Of course, when you're developing code, what is the "current version"? etc etc. It was a horrible mess. So I ripped it all out and post-processed the DLL/EXE files. "ah. it built fine, passes the initial test suite, let's brand it and release for full testing." Slick as hell. Of course, the Build Team sure didn't like that. Much too easy. Might put them out of a job... :-) -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Mon Jul 10 12:00:36 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 12:00:36 +0200 Subject: [Python-Dev] Unicode maintainer wanted (was: Encodings) References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> Message-ID: <39699EC4.C4B30FC8@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > Sorry, but I'm really surprised now: I've put many hours of > > work into this, hacked up encoding support for locale.py, > > went through endless discussions, proposed the changable default > > as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy > > My recollection was that the purpose of the changable default was so > that we could experiment with different defaults more easily, not that > we'd keep it changable. That was the original idea -- noone actually did test this, though, after the hooks were in place... Then Guido (or was it someone else?) came up with the idea of making the default encoding depend on the default locale active at Python startup time and it turned out to satisfy proponents of all three encodings. Guido gave his OK in private mail, Fredrik was satisfied, a few people supported the decision in private mail and the rest made their agreement clear via collective silence. I then tried to hack up ways of extracting the encoding information from the locale settings -- not exactly an easy task and one which involved much research, two or three design cycles (in public on python-dev) and much refinement on the locale name mappings. All this took quite a lot of my time which I felt was worth investing to get all proponents happy. I, for one, still think that the fixed UTF-8 encoding was the best choice of all possibilities. Coding the locale stuff was meant as signal for compromise from my part and now the whole idea get's marked as failed experiment... > I'm not an expert on these issues and have tried to stay out of the > way on the discussion, but the idea of a changable default just seems > like we're asking for trouble. > I'm sorry that you feel your efforts have been wasted; I don't think > anyone tried to spend your time without careful consideration, but it > is important that we all understand what we have gained from this > experiment. > Before you implemented the changable default, we all had the > opportunity to presume to know how things would work with it, and > could bitch or plead about it as we felt appropriate. Now that it's > been tried, we have a little more real experiance with it, and can > point to the evidence that's been presented here as we each make our > arguments on the topic. > So I'd have to say that your efforts have *not* been wasted; we now > have a very good idea of what's involved and whether "it works." I, > for one, am glad that the experiment was done (and expecially that it > was done by someone who knows more about this than me!). Thanks, Fred, but your words won't change my decision to leave Unicode support to someone else. I don't support the recent decisions that were made and don't feel strong enough for Unicode to take all the blame for things which don't work like some people expect them to. Here's a TODO list for my successor(s): * change hash value calculation to work on the Py_UNICODE data instead of creating a default encoded cached object (what now is .utf8str) * change .utf8str to hold a default encoded string instead of an UTF-8 string (+ rename .utf8str to .defencstr) * document the new stuff in locale.py and TeX the codecs.py APIs (the docstrings are there -- they just need to be converted to the Python TeX style) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 10 11:14:41 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 11:14:41 +0200 Subject: [Python-Dev] Venting some steam on current developments References: <20000709215057.95047E2673@oratrix.oratrix.nl> Message-ID: <39699401.790447E8@lemburg.com> Jack Jansen wrote: > > I'm getting pretty depressed at the way Python development is > proceeding at the moment. You're not the only one. > I spent all evening tonight on what seemed > to be an almost trivial task: fixing the default unicode conversion on > the Mac. All the machinery is there, the MacOS API has some nice > conversion routines so I thought it'd be a question of putting in a > few hooks and be done, but that turned out not to be so. > > The first problem (for which I can't blame the Python community, I > guess:-) is that the names mac_roman and such are not official IANA > names for the Mac encodings. Actually, it turns out there _are_ no > official names, so the Mac APIs to turn encodings into names work > wonderful for things including all ISO encodings, windows encodings, > etc, but not for the native mac encodings. Sigh. Okay, we do this > ourselves. What exactly is your problem here ? The Python codec engine does know about the Mac encodings and even provides mapping tables for them. > Then I spent an hour recompiling Python because this *&^^$%&*^%$ > setdefaultencoding didn't show up in sys for no conceivable reason. It > turns out it is *deleted* in site.py after using it once. A comment in > sysmodule.c would have been rather nice here... There are lots of comments about it in site.py. sys.setdefaultencoding() is meant to be used *only* in site.py-- that's why it gets removed after having made the final decision on the default encoding. > And then I found out that locale uses only environment variables to > obtain all the basic encoding info in the first place, so that also > has to be fixed up seriously. That's not because we don't like Macs, it's simply because the people hacking on the code don't have Macs around to hack something up. But we did politely ask for someone with Mac-knowledge to add the needed support to locale.py. I did the Unix stuff, Fredrik added Windows support and we hoped that Just or you would add Mac support. Note that site.py will simply choose ASCII as default encoding in case it can't figure out what the current default encoding on the platform is -- there's no breakage there... Since all this support is written in Python there should be really no problem adding new hooks to it. > So many things are changing at the moment, and there seems to be so > little thought of any platform that isn't linux or windows, that I > think Python's portability to minority platforms is being seriously > threatened. And at least I follow closely what is happening, I really > don't want to think of the poor people who do BeOS or WinCE or Palm > Python. Or even some of the lesser-used Unix ports. > > I'm fed up, I'll continue hacking tomorrow, if I don't have to spend > yet another evening trying to get Python to compile again:-( -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jack at oratrix.nl Mon Jul 10 12:08:36 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 10 Jul 2000 12:08:36 +0200 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: Message by "Tim Peters" , Sun, 9 Jul 2000 18:33:21 -0400 , Message-ID: <20000710100837.6232337186D@snelboot.oratrix.nl> > Random question: why isn't the Mac code checked into the main CVS tree? The number one problem at the moment is that cvs-over-ssh doesn't work on the mac. So I currently do a diff on the mac, send the patches to unix, patch, submit. This is okay for the once in a while I have a patch to the core, but not for normal mac development. It'll also fail for non-text files. There's a very good free ssh for the Mac, but it's console-only, and there's a pretty abysmal commercial ssh which could possibly be beaten into forwarding connections, but it's expensive (and it doesn't work:-). I hope the situation will become better shortly. > BTW, I heartily agree that the lack of official IANA names for Mac encodings > is not my fault. Ok, fair enough. Who shall we blame then? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From mal at lemburg.com Mon Jul 10 12:19:21 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 12:19:21 +0200 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <200007082206.RAA08314@cj20424-a.reston1.va.home.com> Message-ID: <3969A329.E4D870DD@lemburg.com> Guido van Rossum wrote: > > > Instead of tossing things we should be *constructive* and come > > up with a solution to the hash value problem, e.g. I would > > like to make the hash value be calculated from the UTF-16 > > value in a way that is compatible with ASCII strings. > > I think you are proposing to drop the following rule: > > if a == b then hash(a) == hash(b) > > or also > > if hash(a) != hasb(b) then a != b > > This is very fundamental for dictionaries! The rule is fine for situations where a and b have the same type, but you can't expect coercion to be consistent with it. > Note that it is currently > broken: > > >>> d = {'\200':1} > >>> d['\200'] > 1 > >>> u'\200' == '\200' > 1 > >>> d[u'\200'] > Traceback (most recent call last): > File "", line 1, in ? > KeyError: ? > >>> That's because hash(unicode) currently get's calculated using the UTF-8 encoding as basis, while the compare uses the default encoding -- this needs to be changed, of course. > While you could fix this with a variable encoding, it would be very > hard, probably involving the string to Unicode before taking its hash, > and this would slow down the hash calculation for 8-bit strings > considerably (and these are fundamental for the speed of the > language!). > > So I am for restoring ASCII as the one and only fixed encoding. (Then > you can fix your hash much easier!) > > Side note: the KeyError handling is broken. The bad key should be run > through repr() (probably when the error is raised than when it is > displayed). Agreed. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jack at oratrix.nl Mon Jul 10 12:25:16 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 10 Jul 2000 12:25:16 +0200 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: Message by "Fredrik Lundh" , Mon, 10 Jul 2000 01:12:16 +0200 , <033301bfe9fb$209d3520$f2a6b5d4@hagrid> Message-ID: <20000710102516.7732437186E@snelboot.oratrix.nl> > did you see my changes to the locale module? I rewrote the darn > thing to make it easier to deal with this on non-posix platforms, and > posted the locale.py patch to the patch manager (the CVS repository > had a stale lock, so I couldn't check it in before today). > > heck, I even sent you some pseudocode that showed one way to > implement parts of _getdefaultlocale for the mac, and still you claim > that we're ignoring non unix/windows platforms? You're absolutely right, the tone of my previous message was a bit over the top. I hadn't seen your most recent fixes to _locale (which would have shown me the right way to do this for the Mac) nor the discussion on python-dev over the weekend (which would have made me aware of the site.py/sys.setdefaultencoding interaction). Sorry, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From fredrik at pythonware.com Mon Jul 10 12:48:22 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 12:48:22 +0200 Subject: [Python-Dev] CVS: python/dist/src/Modules posixmodule.c,2.143,2.144 References: <200007091310.GAA27888@slayer.i.sourceforge.net> <20000710013250.P29590@lyra.org> Message-ID: <00a201bfea5c$5ee72280$0900a8c0@SPIFF> greg wrote: > --- posixmodule.c 2000/07/09 13:10:40 2.144 > --- 1541,1548 ---- > return posix_error(); > else > ! #if SIZEOF_LONG == SIZEOF_VOID_P > ! return Py_BuildValue("l", (long) spawnval); > #else > ! return Py_BuildValue("L", (LONG_LONG) spawnval); > #endif > } > hmm. should that be PyLong_FromVoidPtr() ? It will return the appropriate > object type based on the size of a void*. I have no idea; I just fixed the typo... the spawn return value is an int according to the docs and my copy of the header files, so I'll leave it to trent to sort this one out. (it's probably a win64 oddity, and he's the only one here with a win64 box). cheers /F From fredrik at pythonware.com Mon Jul 10 14:10:07 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 14:10:07 +0200 Subject: [Python-Dev] new popen for win32! [status update] References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> <200007092202.RAA14221@cj20424-a.reston1.va.home.com> <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> <200007100209.VAA16999@cj20424-a.reston1.va.home.com> Message-ID: <00de01bfea67$cb12c800$0900a8c0@SPIFF> guido wrote: > So the best order to keep our sanity is really to return > (stdin,stdout,stderr), with the understanding that, as this is the > parent, stdin must be *written* and stdout/stderr must be *read*. ok. > I still can't figure out whether this is what your latest patch does that's what it's supposed to do, at least ;-) the popen2 module now assumes that if the os module exports a popen2 function, it returns the file descriptors in a "sane" order. (same goes for popen3 and popen4, of course). > (wouldn't it make sense if os.popen2 and os.popen3 were also available > on Unix?) definitely. I suggest moving the bulk of popen2.py to os.py (alternatively, to a separate "posixpopen.py" module which is imported from os.py on posix platforms). the popen2 module itself is then reduced to a thin wrapper, and marked as deprecated. comments? From guido at beopen.com Mon Jul 10 15:29:41 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 08:29:41 -0500 Subject: [Python-Dev] non-integer arguments to simple slices in 1.6? Message-ID: <200007101329.IAA18009@cj20424-a.reston1.va.home.com> I got the following email from Scott Johnston which suggests an interesting idea (for 2.0, of course, as that's what we're all working on now). basically, Scott proposes to deprecate __getslice__ (and its friends, __setslice__ and __delslice__) in favor of passing the slice arguments unadorned to __getitem__ if __getslice__ is not defined. On the surface, this seems reasonable to me, except that it doesn't help for extension classes... Any other comments? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------- Forwarded Message (reformatted) Date: Mon, 10 Jul 2000 00:03:07 -0700 From: "Scott F. Johnston" To: guido at python.org Subject: non-integer arguments to simple slices in 1.6? For python 1.6/2.0, have you considered unifying the slice operations? I'd like to be able to use simple "[:]" slice syntax on a class using non-integer indices, and without having negative indices automatically "wrapped". I can do this with the complex slice "[::]" syntax, but adding the extra colon and having two different slicing methods seems inconsistent. (One trapped in __getitem__ receiving unmutated objects in a slice object, the other in __getslice__ receiving mutated ints only.) There is an easy way of unifying this: Allow single-colon slices to be passed unmutated to a __getitem__ method as a slice object IF AND ONLY IF the class doesn't provide a __getslice__ method. (And allow the args to be any object as in the current [::] syntax.) Currently, trying to slice an object without a getslice method raises an error. If my __getitem__ handler is set to handle a [::] slice, why not let it handle [:] slices as well? This would be a good way of slowly depricating the __*slice__ operations. Optimally, I shouldn't have to test for SliceType in my __*item__ methods, and all slices would go unmutated to __*slice__ with an additional step term, but that would break a lot of legacy code. Thanks, - --S ------- End of Forwarded Message From moshez at math.huji.ac.il Mon Jul 10 14:52:58 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 10 Jul 2000 15:52:58 +0300 (IDT) Subject: [Python-Dev] non-integer arguments to simple slices in 1.6? In-Reply-To: <200007101329.IAA18009@cj20424-a.reston1.va.home.com> Message-ID: On Mon, 10 Jul 2000, Guido van Rossum wrote: > I got the following email from Scott Johnston which suggests an > interesting idea (for 2.0, of course, as that's what we're all working > on now). basically, Scott proposes to deprecate __getslice__ (and its > friends, __setslice__ and __delslice__) in favor of passing the slice > arguments unadorned to __getitem__ if __getslice__ is not defined. > > On the surface, this seems reasonable to me, except that it doesn't > help for extension classes... +1. Solving extension classes can be done similarily to the way "in" is solved. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From guido at beopen.com Mon Jul 10 16:08:43 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 09:08:43 -0500 Subject: [Python-Dev] new popen for win32! [status update] In-Reply-To: Your message of "Mon, 10 Jul 2000 14:10:07 +0200." <00de01bfea67$cb12c800$0900a8c0@SPIFF> References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> <200007092202.RAA14221@cj20424-a.reston1.va.home.com> <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> <200007100209.VAA16999@cj20424-a.reston1.va.home.com> <00de01bfea67$cb12c800$0900a8c0@SPIFF> Message-ID: <200007101408.JAA18274@cj20424-a.reston1.va.home.com> > > (wouldn't it make sense if os.popen2 and os.popen3 were also available > > on Unix?) > > definitely. I suggest moving the bulk of popen2.py to os.py (alternatively, > to a separate "posixpopen.py" module which is imported from os.py on > posix platforms). > > the popen2 module itself is then reduced to a thin wrapper, and marked > as deprecated. > > comments? Sounds good to me. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Mon Jul 10 15:31:38 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 09:31:38 -0400 (EDT) Subject: [Python-Dev] Re: CVS: python/dist/src/Lib locale.py,1.7,1.8 In-Reply-To: <20000710020930.T29590@lyra.org> References: <200007091713.KAA02613@slayer.i.sourceforge.net> <20000710020930.T29590@lyra.org> Message-ID: <14697.53306.858387.422925@bitdiddle.concentric.net> >>>>> "GS" == Greg Stein writes: GS> Can I request (from everyone) to do white space changes *only*, GS> or to do functional changes *only*. It will make it a lot easier GS> on the people who are reviewing the checkins. Only if you checkin in your own whitespaces changes! <0.7 wink> Jeremy From thomas at xs4all.net Mon Jul 10 16:32:33 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 16:32:33 +0200 Subject: [Python-Dev] parallel for-loops. Message-ID: <20000710163233.I26534@xs4all.nl> I've attached a patch that adds yet another new feature to Python ;P It's the 'parallel for loop' thing that's come past here and on python-list a few times. Guido sent me the suggested Grammar patch and I went from there, so if I got any of the details wrong, please yell at me, loudly. Here's how it works: >>> for x in [1,2,3,4,5]; y in ['a','b','c','d','e','f','g']: ... print x, y ... 1 a 2 b 3 c 4 d 5 e >>> The two loops are traversed in parallel, like in for x, y in map(None, [1,2,3,4,5], ['a','b','c','d','e','f','g']) *except* that the first IndexError of any of the lists terminates the loop. The syntax is not limited to two lists in parallel, of course! There is no specific limit forced by this patch, so the limit is either the available memory, or the max number of child nodes (32k or so) whichever comes first ;) The patch works internally by passing a tuple of sequences as argument to FOR_LOOP, instead of just a single sequence as before. Likewise, the result of the FOR_LOOP operation is a tuple, which is then unpacked into the proper variables. This is done for all for loops, even single-list ones, so all for-loops take a slight performance hit with this patch. (A tuple-build on entering the loop, and a few iterations, a tuple build and a tuple unpack, even for the common case. I didn't measure it, though.) If this is deemed undesirable, it would be trivial to add a new bytcode, FORMORE_LOOP or such, that handles the multiple-list type of for loop. I almost went ahead and did that, but decided I'd try for a patch that *doesn't* add bytecodes for a change ;) Unfortunately, the patch is binary incompatible, so the bytecode magic does have to be changed. Don't forget to type 'make' inside 'Grammar' after applying it. I'll do some more testing on this, write some docs and some tests, and if noone here has convinced me otherwise, upload it to sourceforge ;) The patch is really suprisingly small and elegant, thanks to Python's extreme simplicity! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- Index: Grammar/Grammar =================================================================== RCS file: /cvsroot/python/python/dist/src/Grammar/Grammar,v retrieving revision 1.35 diff -c -r1.35 Grammar *** Grammar/Grammar 2000/03/28 23:49:00 1.35 --- Grammar/Grammar 2000/07/10 14:06:26 *************** *** 54,60 **** compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | funcdef | classdef if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] while_stmt: 'while' test ':' suite ['else' ':' suite] ! for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite] try_stmt: ('try' ':' suite (except_clause ':' suite)+ #diagram:break ['else' ':' suite] | 'try' ':' suite 'finally' ':' suite) # NB compile.c makes sure that the default except clause is last --- 54,60 ---- compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | funcdef | classdef if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] while_stmt: 'while' test ':' suite ['else' ':' suite] ! for_stmt: 'for' exprlist 'in' testlist (';' exprlist 'in' testlist)* ':' suite ['else' ':' suite] try_stmt: ('try' ':' suite (except_clause ':' suite)+ #diagram:break ['else' ':' suite] | 'try' ':' suite 'finally' ':' suite) # NB compile.c makes sure that the default except clause is last Index: Python/ceval.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/ceval.c,v retrieving revision 2.183 diff -c -r2.183 ceval.c *** Python/ceval.c 2000/07/09 03:09:56 2.183 --- Python/ceval.c 2000/07/10 14:06:28 *************** *** 1473,1481 **** continue; case FOR_LOOP: ! /* for v in s: ... ! On entry: stack contains s, i. ! On exit: stack contains s, i+1, s[i]; but if loop exhausted: s, i are popped, and we jump */ w = POP(); /* Loop index */ --- 1473,1481 ---- continue; case FOR_LOOP: ! /* for v1 in s1; v2 in s2: ... ! On entry: stack contains t(s), i. ! On exit: stack contains t(s), i+1, t(s[i]); but if loop exhausted: s, i are popped, and we jump */ w = POP(); /* Loop index */ *************** *** 2548,2566 **** loop_subscript(v, w) PyObject *v, *w; { ! PySequenceMethods *sq = v->ob_type->tp_as_sequence; ! int i; ! if (sq == NULL || sq->sq_item == NULL) { ! PyErr_SetString(PyExc_TypeError, "loop over non-sequence"); return NULL; } i = PyInt_AsLong(w); ! v = (*sq->sq_item)(v, i); ! if (v) ! return v; ! if (PyErr_ExceptionMatches(PyExc_IndexError)) ! PyErr_Clear(); ! return NULL; } /* Extract a slice index from a PyInt or PyLong, the index is bound to --- 2548,2585 ---- loop_subscript(v, w) PyObject *v, *w; { ! PyObject *res; ! long i; ! int j, len; ! ! if (!PyTuple_Check(v)) { ! PyErr_SetString(PyExc_SystemError, "bad (internal) arg to for loop"); return NULL; } + + len = PyTuple_Size(v); + res = PyTuple_New(len); i = PyInt_AsLong(w); ! ! for (j = 0; j < len; j++) { ! PyObject *u = PyTuple_GET_ITEM(v, j); ! PySequenceMethods *sq = u->ob_type->tp_as_sequence; ! if (sq == NULL || sq->sq_item == NULL) { ! Py_DECREF(res); ! PyErr_SetString(PyExc_TypeError, "loop over non-sequence"); ! return NULL; ! } ! u = (*sq->sq_item)(u, i); ! if (u) { ! PyTuple_SET_ITEM(res, j, u); ! continue; ! } ! if (PyErr_ExceptionMatches(PyExc_IndexError)) ! PyErr_Clear(); ! Py_DECREF(res); ! return NULL; ! } ! return res; } /* Extract a slice index from a PyInt or PyLong, the index is bound to Index: Python/compile.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v retrieving revision 2.114 diff -c -r2.114 compile.c *** Python/compile.c 2000/07/09 03:09:56 2.114 --- Python/compile.c 2000/07/10 14:06:29 *************** *** 2433,2443 **** int break_anchor = 0; int anchor = 0; int save_begin = c->c_begin; REQ(n, for_stmt); ! /* 'for' exprlist 'in' exprlist ':' suite ['else' ':' suite] */ com_addfwref(c, SETUP_LOOP, &break_anchor); block_push(c, SETUP_LOOP); ! com_node(c, CHILD(n, 3)); v = PyInt_FromLong(0L); if (v == NULL) c->c_errors++; --- 2433,2457 ---- int break_anchor = 0; int anchor = 0; int save_begin = c->c_begin; + int inum, i; + REQ(n, for_stmt); ! /* 'for' exprlist 'in' exprlist (';' exprlist 'in' testlist)* ! ':' suite ['else' ':' suite] */ ! ! if (NCH(n) % 2) { ! /* Uneven number of children, so it includes 'else' clause */ ! inum = ((NCH(n) - 5) / 4); ! } else { ! /* No 'else' clause */ ! inum = ((NCH(n) - 2) / 4); ! } com_addfwref(c, SETUP_LOOP, &break_anchor); block_push(c, SETUP_LOOP); ! for (i = 1; i <= inum; i++) ! com_node(c, CHILD(n, i*4 - 1)); ! com_addoparg(c, BUILD_TUPLE, inum); ! com_pop(c, inum-1); v = PyInt_FromLong(0L); if (v == NULL) c->c_errors++; *************** *** 2448,2456 **** com_addoparg(c, SET_LINENO, n->n_lineno); com_addfwref(c, FOR_LOOP, &anchor); com_push(c, 1); ! com_assign(c, CHILD(n, 1), OP_ASSIGN); c->c_loops++; ! com_node(c, CHILD(n, 5)); c->c_loops--; com_addoparg(c, JUMP_ABSOLUTE, c->c_begin); c->c_begin = save_begin; --- 2462,2473 ---- com_addoparg(c, SET_LINENO, n->n_lineno); com_addfwref(c, FOR_LOOP, &anchor); com_push(c, 1); ! com_addoparg(c, UNPACK_TUPLE, inum); ! com_push(c, inum-1); ! for (i = 1; i <= inum; i++) ! com_assign(c, CHILD(n, i*4 - 3), OP_ASSIGN); c->c_loops++; ! com_node(c, CHILD(n, inum*4 + 1)); c->c_loops--; com_addoparg(c, JUMP_ABSOLUTE, c->c_begin); c->c_begin = save_begin; *************** *** 2458,2465 **** com_pop(c, 2); /* FOR_LOOP has popped these */ com_addbyte(c, POP_BLOCK); block_pop(c, SETUP_LOOP); ! if (NCH(n) > 8) ! com_node(c, CHILD(n, 8)); com_backpatch(c, break_anchor); } --- 2475,2483 ---- com_pop(c, 2); /* FOR_LOOP has popped these */ com_addbyte(c, POP_BLOCK); block_pop(c, SETUP_LOOP); ! if (NCH(n) % 2) { ! com_node(c, CHILD(n, inum*4 + 3)); ! } com_backpatch(c, break_anchor); } Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.140 diff -c -r2.140 import.c *** Python/import.c 2000/07/09 03:09:56 2.140 --- Python/import.c 2000/07/10 14:06:31 *************** *** 65,71 **** /* XXX Perhaps the magic number should be frozen and a version field added to the .pyc file header? */ /* New way to come up with the magic number: (YEAR-1995), MONTH, DAY */ ! #define MAGIC (50428 | ((long)'\r'<<16) | ((long)'\n'<<24)) /* Magic word as global; note that _PyImport_Init() can change the value of this global to accommodate for alterations of how the --- 65,71 ---- /* XXX Perhaps the magic number should be frozen and a version field added to the .pyc file header? */ /* New way to come up with the magic number: (YEAR-1995), MONTH, DAY */ ! #define MAGIC (50710 | ((long)'\r'<<16) | ((long)'\n'<<24)) /* Magic word as global; note that _PyImport_Init() can change the value of this global to accommodate for alterations of how the From guido at beopen.com Mon Jul 10 17:32:44 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 10:32:44 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure Message-ID: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> I decided to build the simple embedding demo in Demo/embed/. After fixing the Makefile (checkins coming), I ended up with one problem: the 'import site.py' failed error. When using -v I get this traceback: 'import site' failed; traceback: Traceback (most recent call last): File "/usr/local/lib/python2.0/site.py", line 146, in ? sys.setdefaultencoding('ascii') LookupError: no codec search functions registered: can't find encoding Is there some part of the initialization that I'm forgetting? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Mon Jul 10 16:38:40 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 16:38:40 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Demo/embed Makefile,1.3,1.4 In-Reply-To: <200007101435.HAA09733@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Mon, Jul 10, 2000 at 07:35:15AM -0700 References: <200007101435.HAA09733@slayer.i.sourceforge.net> Message-ID: <20000710163840.J26534@xs4all.nl> On Mon, Jul 10, 2000 at 07:35:15AM -0700, Guido van Rossum wrote: > Log Message: > Adapted for Python 2.0 under RH Linux. [..] > # XXX edit LIBS (in particular) to match $(blddir)/Modules/Makefile > ! LIBS= -lnsl -ldl -lreadline -ltermcap -lieee -lpthread -lutil You probably want -lcrypt in there, too, just in case. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm at hypernet.com Mon Jul 10 16:41:37 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Mon, 10 Jul 2000 10:41:37 -0400 Subject: [Python-Dev] non-integer arguments to simple slices in 1.6? In-Reply-To: <200007101329.IAA18009@cj20424-a.reston1.va.home.com> Message-ID: <1248882392-26064718@hypernet.com> [Guido] > I got the following email from Scott Johnston which suggests an > interesting idea (for 2.0, of course, as that's what we're all > working on now). basically, Scott proposes to deprecate > __getslice__ (and its friends, __setslice__ and __delslice__) in > favor of passing the slice arguments unadorned to __getitem__ if > __getslice__ is not defined. > > On the surface, this seems reasonable to me, except that it > doesn't help for extension classes... We have a problem here, but I think it's in the fact that currently certain slices end up in __getitem__ and some in __getslice__. IOW, I think that __getitem__ should return an item, and this fix (while clever) just compounds a mistake. - Gordon From guido at beopen.com Mon Jul 10 17:43:26 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 10:43:26 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Demo/embed Makefile,1.3,1.4 In-Reply-To: Your message of "Mon, 10 Jul 2000 16:38:40 +0200." <20000710163840.J26534@xs4all.nl> References: <200007101435.HAA09733@slayer.i.sourceforge.net> <20000710163840.J26534@xs4all.nl> Message-ID: <200007101543.KAA25995@cj20424-a.reston1.va.home.com> > > ! LIBS= -lnsl -ldl -lreadline -ltermcap -lieee -lpthread -lutil > > You probably want -lcrypt in there, too, just in case. No, I put *shared* at the earliest convenience in Setup (in fact there's one commented out that I enabled). I recommend everyone else to do the same. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Mon Jul 10 16:47:06 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 16:47:06 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> Message-ID: <3969E1EA.27E7F508@lemburg.com> Guido van Rossum wrote: > > I decided to build the simple embedding demo in Demo/embed/. After > fixing the Makefile (checkins coming), I ended up with one problem: > the 'import site.py' failed error. When using -v I get this traceback: > > 'import site' failed; traceback: > Traceback (most recent call last): > File "/usr/local/lib/python2.0/site.py", line 146, in ? > sys.setdefaultencoding('ascii') > LookupError: no codec search functions registered: can't find encoding > > Is there some part of the initialization that I'm forgetting? Looks like the 'import encodings' failed. Could you check this with -vv ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Mon Jul 10 17:50:49 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 10:50:49 -0500 Subject: [Python-Dev] non-integer arguments to simple slices in 1.6? In-Reply-To: Your message of "Mon, 10 Jul 2000 10:41:37 -0400." <1248882392-26064718@hypernet.com> References: <1248882392-26064718@hypernet.com> Message-ID: <200007101550.KAA26343@cj20424-a.reston1.va.home.com> > We have a problem here, but I think it's in the fact that > currently certain slices end up in __getitem__ and some in > __getslice__. > > IOW, I think that __getitem__ should return an item, and this > fix (while clever) just compounds a mistake. Agreed in an ideal world, but it's done like this for backwards compatibility. The proper solution would be for __getslice__ to always get the raw values given to the slice, but so that __getslice__ takes an optional third argument which gets the 3rd slice value if present. So x[i:j] results in x.__getslice__(i,j) while x[i:j:k] results in x.__getslice__(i,j,k). Missing values are replaced with None, so that x[:] results in x.__getslice__(None, None) and x[::] in x.__getslice__(None, None, None). This is pretty backwards incompatible! Perhaps to the devil with b/w compat? Note that C extensions also get too much service for slicing. It seems a somewhat tedious project to clean all of this up... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Mon Jul 10 16:52:53 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 16:52:53 +0200 Subject: [Python-Dev] parallel for-loops. In-Reply-To: <20000710163233.I26534@xs4all.nl>; from thomas@xs4all.net on Mon, Jul 10, 2000 at 04:32:33PM +0200 References: <20000710163233.I26534@xs4all.nl> Message-ID: <20000710165253.K26534@xs4all.nl> On Mon, Jul 10, 2000 at 04:32:33PM +0200, Thomas Wouters wrote: > I'll do some more testing on this, write some docs and some tests, And already found a bug ;) If anyone is testing this, and can't get 'else' clauses to work, change this: > ! com_node(c, CHILD(n, inum*4 + 3)); into this: > ! com_node(c, CHILD(n, inum*4 + 4)); -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Mon Jul 10 16:56:56 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 10 Jul 2000 17:56:56 +0300 (IDT) Subject: [Python-Dev] parallel for-loops. In-Reply-To: <20000710163233.I26534@xs4all.nl> Message-ID: On Mon, 10 Jul 2000, Thomas Wouters wrote: > Here's how it works: > > >>> for x in [1,2,3,4,5]; y in ['a','b','c','d','e','f','g']: > ... print x, y > ... > 1 a > 2 b > 3 c > 4 d > 5 e > >>> +1 on the concept anyway > If this is deemed undesirable, it would be trivial to add a new bytcode, > FORMORE_LOOP or such, that handles the multiple-list type of for loop. I > almost went ahead and did that, but decided I'd try for a patch that > *doesn't* add bytecodes for a change ;) Unfortunately, the patch is binary > incompatible, so the bytecode magic does have to be changed. It's all right, any patch would be binary incompatible > I'll do some more testing on this, write some docs and some tests, and if > noone here has convinced me otherwise, upload it to sourceforge ;) The patch > is really suprisingly small and elegant, thanks to Python's extreme > simplicity! Hmmmm... I still think there should be a FOR_MORELOOP, but I think this specific patch should be uploaded to SF so we can play with this a bit. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From guido at beopen.com Mon Jul 10 18:22:40 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 11:22:40 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: Your message of "Mon, 10 Jul 2000 08:00:35 MST." <200007101500.IAA13372@slayer.i.sourceforge.net> References: <200007101500.IAA13372@slayer.i.sourceforge.net> Message-ID: <200007101622.LAA01140@cj20424-a.reston1.va.home.com> > Moves some test code into the scope of if __name__ == '__main__', where it > won't get loaded when we're using the classes in this module. Eric, I believe you are mistaken, or at least expressing yourself unclearly in the checkin comment. While the test function *objects* indeed aren't created in your new version, it doesn't actually save any time when loading the module: all the code in a module is parsed, or all the bytecode is unmarshalled, regardless of whether it is executed. All you save in performance is a LOAD_CONST, a MAKE_FUNCTION, and a STORE_NAME -- all of which don't really do any work. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 18:30:57 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 11:30:57 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 16:47:06 +0200." <3969E1EA.27E7F508@lemburg.com> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> Message-ID: <200007101630.LAA01307@cj20424-a.reston1.va.home.com> (There's a linux question at the bottom.) > > I decided to build the simple embedding demo in Demo/embed/. After > > fixing the Makefile (checkins coming), I ended up with one problem: > > the 'import site.py' failed error. When using -v I get this traceback: > > > > 'import site' failed; traceback: > > Traceback (most recent call last): > > File "/usr/local/lib/python2.0/site.py", line 146, in ? > > sys.setdefaultencoding('ascii') > > LookupError: no codec search functions registered: can't find encoding > > > > Is there some part of the initialization that I'm forgetting? > > Looks like the 'import encodings' failed. Could you check this > with -vv ? Thanks for the hint. Seems I've got it nailed down: it's looking for the struct module: [...] import codecs # precompiled from /usr/local/lib/python2.0/codecs.pyc # trying /usr/local/lib/python2.0/struct.so # trying /usr/local/lib/python2.0/structmodule.so # trying /usr/local/lib/python2.0/struct.py # trying /usr/local/lib/python2.0/struct.pyc # trying /usr/local/lib/python2.0/plat-linux2/struct.so # trying /usr/local/lib/python2.0/plat-linux2/structmodule.so # trying /usr/local/lib/python2.0/plat-linux2/struct.py # trying /usr/local/lib/python2.0/plat-linux2/struct.pyc # trying /usr/local/lib/python2.0/lib-tk/struct.so # trying /usr/local/lib/python2.0/lib-tk/structmodule.so # trying /usr/local/lib/python2.0/lib-tk/struct.py # trying /usr/local/lib/python2.0/lib-tk/struct.pyc # trying /usr/local/lib/python2.0/lib-dynload/struct.so # trying /usr/local/lib/python2.0/lib-dynload/structmodule.so 'import site' failed; traceback: Traceback (most recent call last): File "/usr/local/lib/python2.0/site.py", line 146, in ? sys.setdefaultencoding('ascii') LookupError: no codec search functions registered: can't find encoding [...] But the bizarre thing is that the last file it tries (/usr/local/lib/python2.0/lib-dynload/structmodule.so) actually exists!!! OK, so there's code masking the ImportError in import_encodings() in codecs.c. I disabled that (hmm, maybe this should be disabled automatically when -v is used!). Now I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.0/site.py", line 146, in ? sys.setdefaultencoding('ascii') File "/usr/local/lib/python2.0/encodings/__init__.py", line 30, in ? import codecs,aliases File "/usr/local/lib/python2.0/codecs.py", line 10, in ? import struct,types,__builtin__ ImportError: /usr/local/lib/python2.0/lib-dynload/structmodule.so: undefined symbol: PyString_Type OK, I've managed to fix it by a change to the way I build Python: I'm now linking the struct module (and everything in Setup up to and including _codecs) statically. But I guess what's really missing is some kind of flag that tells the linker to export all symbols in the libpython2.0.a file... Is there a way? (I feel so stupid!) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Mon Jul 10 17:44:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 17:44:39 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> Message-ID: <3969EF67.29B9DC05@lemburg.com> Guido van Rossum wrote: > > (There's a linux question at the bottom.) > > > > I decided to build the simple embedding demo in Demo/embed/. After > > > fixing the Makefile (checkins coming), I ended up with one problem: > > > the 'import site.py' failed error. When using -v I get this traceback: > > > > > > 'import site' failed; traceback: > > > Traceback (most recent call last): > > > File "/usr/local/lib/python2.0/site.py", line 146, in ? > > > sys.setdefaultencoding('ascii') > > > LookupError: no codec search functions registered: can't find encoding > > > > > > Is there some part of the initialization that I'm forgetting? > > > > Looks like the 'import encodings' failed. Could you check this > > with -vv ? > > Thanks for the hint. Seems I've got it nailed down: it's looking for > the struct module: > > [...] > import codecs # precompiled from /usr/local/lib/python2.0/codecs.pyc > # trying /usr/local/lib/python2.0/struct.so > # trying /usr/local/lib/python2.0/structmodule.so > # trying /usr/local/lib/python2.0/struct.py > # trying /usr/local/lib/python2.0/struct.pyc > # trying /usr/local/lib/python2.0/plat-linux2/struct.so > # trying /usr/local/lib/python2.0/plat-linux2/structmodule.so > # trying /usr/local/lib/python2.0/plat-linux2/struct.py > # trying /usr/local/lib/python2.0/plat-linux2/struct.pyc > # trying /usr/local/lib/python2.0/lib-tk/struct.so > # trying /usr/local/lib/python2.0/lib-tk/structmodule.so > # trying /usr/local/lib/python2.0/lib-tk/struct.py > # trying /usr/local/lib/python2.0/lib-tk/struct.pyc > # trying /usr/local/lib/python2.0/lib-dynload/struct.so > # trying /usr/local/lib/python2.0/lib-dynload/structmodule.so > 'import site' failed; traceback: > Traceback (most recent call last): > File "/usr/local/lib/python2.0/site.py", line 146, in ? > sys.setdefaultencoding('ascii') > LookupError: no codec search functions registered: can't find encoding > [...] > > But the bizarre thing is that the last file it tries > (/usr/local/lib/python2.0/lib-dynload/structmodule.so) actually > exists!!! > > OK, so there's code masking the ImportError in import_encodings() in > codecs.c. I disabled that (hmm, maybe this should be disabled > automatically when -v is used!). Hard to do since the setting of the verbosity flag is not available to Python code. > Now I get this traceback: > > Traceback (most recent call last): > File "/usr/local/lib/python2.0/site.py", line 146, in ? > sys.setdefaultencoding('ascii') > File "/usr/local/lib/python2.0/encodings/__init__.py", line 30, in ? > import codecs,aliases > File "/usr/local/lib/python2.0/codecs.py", line 10, in ? > import struct,types,__builtin__ > ImportError: /usr/local/lib/python2.0/lib-dynload/structmodule.so: undefined symbol: PyString_Type > > OK, I've managed to fix it by a change to the way I build Python: I'm > now linking the struct module (and everything in Setup up to and > including _codecs) statically. > > But I guess what's really missing is some kind of flag that tells the > linker to export all symbols in the libpython2.0.a file... Is there a > way? (I feel so stupid!) From pf at artcom-gmbh.de Mon Jul 10 17:44:13 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Mon, 10 Jul 2000 17:44:13 +0200 (MEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_userstring,1.1,1.2 In-Reply-To: <200007101414.HAA08212@slayer.i.sourceforge.net> from Jeremy Hylton at "Jul 10, 2000 7:14:43 am" Message-ID: Hi, Jeremy Hylton: > Modified Files: > test_userstring > Log Message: > expect message "no regression test case for method 'encode' [...] > test_userstring > + no regression test case for method 'encode' > + no regression test case for method 'isalnum' > + no regression test case for method 'isalpha' Hmmmm..... Wouldn't it be better to actually write some simple test cases for these methods and add them to 'Lib/test/test_string.py' (if not already done)? My initial idea to put this check into 'test_userstring.py' was to discover missing test cases for new methods that should be copied from test_string.py in order to keep UserString in sync with new functionality added to the builtin string types. Regards, Peter From thomas at xs4all.net Mon Jul 10 17:56:42 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 17:56:42 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <3969EF67.29B9DC05@lemburg.com>; from mal@lemburg.com on Mon, Jul 10, 2000 at 05:44:39PM +0200 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> Message-ID: <20000710175642.L26534@xs4all.nl> On Mon, Jul 10, 2000 at 05:44:39PM +0200, M.-A. Lemburg wrote: > Guido van Rossum wrote: > > import struct,types,__builtin__ > > ImportError: /usr/local/lib/python2.0/lib-dynload/structmodule.so: undefined symbol: PyString_Type [...] > > But I guess what's really missing is some kind of flag that tells the > > linker to export all symbols in the libpython2.0.a file... Is there a > > way? (I feel so stupid!) > >From man ld: > -export-dynamic > When creating an ELF file, add all symbols to the > dynamic symbol table. Normally, the dynamic symbol > table contains only symbols which are used by a dy? > namic object. This option is needed for some uses > of dlopen. > (Not sure whether this is what you're looking for, though.) I think it is. The funny bit is that it should be included in LDFLAGS by default, on Linux. BSDI and some other operating systems need it too (at least newer versions) and gave the same error with shared libraries if the flag was omitted (old BSDI was COFF with fake-shared-libraries, new BSDI is ELF) I didn't bother to check, but does the embed Makefile include python's Makefile* stuff from $prefix/config ? Does it contain -export-dynamic ? If so, very pecurliar... ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Mon Jul 10 18:14:09 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 12:14:09 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_userstring,1.1,1.2 In-Reply-To: References: <200007101414.HAA08212@slayer.i.sourceforge.net> Message-ID: <14697.63057.193077.537823@bitdiddle.concentric.net> >>>>> "PF" == Peter Funk writes: PF> Hmmmm..... Wouldn't it be better to actually write some simple PF> test cases for these methods and add them to PF> 'Lib/test/test_string.py' (if not already done)? PF> My initial idea to put this check into 'test_userstring.py' was PF> to discover missing test cases for new methods that should be PF> copied from test_string.py in order to keep UserString in sync PF> with new functionality added to the builtin string types. That sounds like a good testing strategy, but I'm not sure I agree with a test that fails because it has failed to track a new feature. The current test suite does a mediocre job of testing all features or achieving code coverage. It's annoying that this test is reported as a failure when the module is, in fact, working properly. In the long term, a revision of the testing setup so that different classes of errors can be reported might be useful. The failure to test an encode method could be reported as a warning (non-fatal) instead of an error (fatal). I also don't like the implementation strategy, which causes code to be duplicated in test_string.py and test_userstring.py. I'll add a third module that can be loaded by either test module to perform the specific tests. Finally, test_string doesn't test encode either. Someone want to add a test for that? Jeremy From thomas at xs4all.net Mon Jul 10 18:15:54 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 18:15:54 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules posixmodule.c,2.148,2.149 In-Reply-To: <200007101559.IAA22393@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Mon, Jul 10, 2000 at 08:59:33AM -0700 References: <200007101559.IAA22393@slayer.i.sourceforge.net> Message-ID: <20000710181554.M26534@xs4all.nl> On Mon, Jul 10, 2000 at 08:59:33AM -0700, Fredrik Lundh wrote: > Modified Files: > posixmodule.c > Log Message: > -- get rid of a compiler warning on unix. (as reported > for #100836, but implemented in a different way) > - static PyObject * > - posix_strintint(PyObject *args, char *format, > - int (*func)(const char *, int, int)) [..] Why not get rid of posix_strint() in the same manner ? posix_strint() isn't used at all, currently. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Mon Jul 10 19:22:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 12:22:36 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 17:44:39 +0200." <3969EF67.29B9DC05@lemburg.com> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> Message-ID: <200007101722.MAA01227@cj20424-a.reston1.va.home.com> > > OK, so there's code masking the ImportError in import_encodings() in > > codecs.c. I disabled that (hmm, maybe this should be disabled > > automatically when -v is used!). > > Hard to do since the setting of the verbosity flag is not > available to Python code. Actually, it is: see pydebug.h, included by Python.h: extern DL_IMPORT(int) Py_VerboseFlag; > >From man ld: > > -E > > -export-dynamic > When creating an ELF file, add all symbols to the > dynamic symbol table. Normally, the dynamic symbol > table contains only symbols which are used by a dy? > namic object. This option is needed for some uses > of dlopen. > > (Not sure whether this is what you're looking for, though.) Thanks -- yes, that did it! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 19:25:12 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 12:25:12 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 17:56:42 +0200." <20000710175642.L26534@xs4all.nl> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> Message-ID: <200007101725.MAA01255@cj20424-a.reston1.va.home.com> > I didn't bother to check, but does the embed Makefile include python's > Makefile* stuff from $prefix/config ? Does it contain -export-dynamic ? If > so, very pecurliar... ;-P Makefile includes are notoriously unportable, aren't they? The embed/Makefile is a lame excuse for a Makefile -- it has XXX comments all over the place telling you to edit things to match the Python main Makefile... :-( My fault -- feel free to fix! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Mon Jul 10 18:35:50 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 12:35:50 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101622.LAA01140@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 11:22:40AM -0500 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> Message-ID: <20000710123550.A8478@thyrsus.com> Guido van Rossum : > I believe you are mistaken, or at least expressing yourself unclearly > in the checkin comment. While the test function *objects* indeed > aren't created in your new version, it doesn't actually save any time > when loading the module: all the code in a module is parsed, or all > the bytecode is unmarshalled, regardless of whether it is executed. > All you save in performance is a LOAD_CONST, a MAKE_FUNCTION, and a > STORE_NAME -- all of which don't really do any work. OK, correction accepted. But this is still a good idea for documentation purposes, no? -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. From effbot at telia.com Mon Jul 10 18:45:27 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 18:45:27 +0200 Subject: [Python-Dev] why isn't SRE a shared module? Message-ID: <007901bfea8e$8ee9b600$f2a6b5d4@hagrid> from Modules/Setup.in: # The modules listed here can't be built as shared libraries for # various reasons; therefore they are listed here instead of in the # normal order. # Some modules that are normally always on: regex regexmodule.c regexpr.c # Regular expressions, GNU Emacs style pcre pcremodule.c pypcre.c # Regular expressions, Perl style (for re.py) posix posixmodule.c # posix (UNIX) system calls signal signalmodule.c # signal(2) _sre _sre.c # Fredrik Lundh's new regular expressions possibly a stupid question, but what exactly is SRE doing in there? From jim at interet.com Mon Jul 10 18:43:03 2000 From: jim at interet.com (James C. Ahlstrom) Date: Mon, 10 Jul 2000 12:43:03 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> Message-ID: <3969FD17.487DA96A@interet.com> I just got back from vacation, so I am catching up. The following concerns Windows only, not *.so files on Unix. Background: Existing foo.pyd Windows extensions will crash the new Python because foo.pyd will load python15.dll, and python.exe will load python20.dll. MarkH explained why: [Mark] > The 1.5 module is linked against Python15.dll. When Python.exe (linked > against Python16.dll) starts up, it initializes the Python data structures > in Python16.dll. When Python then imports foo.pyd (linked against > Python15.dll), it immediately tries to call the functions in that DLL (such > as getting the thread state). As Python has not been initialized in that > DLL, we immediately die. This is really bad. Normally under Windows, DLL names do not change unless the API exported is changed in a major way. For example, there have been several versions of mfc42.dll without changing the name. [Mark continues] > Ironically, if Python1x.dll was simply named "Python.dll", there is a > _reasonable_ chance it would work fine. The cost of doing this tho, is > that you can not have Python 1.5 and Python 1.6 "side by side" on the same > machine. What this means is that if the new Python 2.0 (1.6?) simply names its DLL python15.dll just as before, everything Just Works almost. That is, it Just Works provided that foo.pyd only calls Python C functions whose interface has not changed. You can support Python 1.5 and 1.6 by removing the python*.dll from the Windows directories, and putting it in the directory of python.exe so it goes with the proper executable. Guido van Rossum wrote: > There are endless variations on this theme. What's missing at the > moment is a bit of requirements analysis. What's the problem we're > trying to solve here? So far, the only problem that came up was that > on Windows, you get an obscure crash when trying to load an extension > built for Python 1.5(.x). Yes, and this is a major problem, and is un-Windows-like. > Do we really need a whole new version > negotiating architecture? No, just keep the old name "python15.dll". Old foo.pyd will still work if they use only Python C functions with the same interface. Individual *.pyd authors will have to advise users whether they need to upgrade to new *.pyd versions or not. > You can already get the version string by > looking at Py_GetVersion() -- this also answers the question of how a > version is represented. True. And on Windows, there is a standard Version resource string which gives the DLL version, and can be read without loading the DLL. This string is referenced by the Wise (and other) installers to decide whether a DLL is newer and should be replaced. > On Windows, link-time compatibility is broken whenever we change the > second digit of the version number, e.g. 15, 16, 20. Yikes, lets not let that happen! JimA From effbot at telia.com Mon Jul 10 19:07:15 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 19:07:15 +0200 Subject: [Python-Dev] new unicode hash calculation References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> Message-ID: <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> mal wrote: > * change hash value calculation to work on the Py_UNICODE data > instead of creating a default encoded cached object (what > now is .utf8str) it this what you had in mind? static long unicode_hash(PyUnicodeObject *self) { register int len; register Py_UNICODE *p; register long x; if (self->hash != -1) return self->hash; len = PyUnicode_GET_SIZE(self); p = PyUnicode_AS_UNICODE(self); x = *p << 7; while (--len >= 0) x = (1000003*x) ^ *p++; x ^= a->ob_size; if (x == -1) x = -2; self->hash = x; return x; } From jeremy at beopen.com Mon Jul 10 19:24:27 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 13:24:27 -0400 (EDT) Subject: [Python-Dev] string.join and bad sequences In-Reply-To: <200007101708.KAA08018@slayer.i.sourceforge.net> References: <200007101708.KAA08018@slayer.i.sourceforge.net> Message-ID: <14698.1739.660431.756932@bitdiddle.concentric.net> I added a test case to Lib/test/string_tests.py that uses a sequence that returns the wrong answer from __len__. I've used this test in a number of places to make sure the interpreter doesn't dump core when it hits a bad user-defined sequence. class Sequence: def __init__(self): self.seq = 'wxyz' def __len__(self): return len(self.seq) def __getitem__(self, i): return self.seq[i] class BadSeq2(Sequence): def __init__(self): self.seq = ['a', 'b', 'c'] def __len__(self): return 8 The test of string.join and " ".join don't dump core, but they do raise an IndexError. I wonder if that's the right thing to do, because the other places where it is handled no exception is raised. The question boils down to the semantics of the sequence protocol. The string code defintion is: if __len__ returns X, then the length is X thus, __getitem__ should succeed for range(0, X) if it doesn't, raise an IndexError The other code (e.g. PySequence_Tuple) definition is: if __len__ return X, then the length is <= X if __getitem__ succeeds for range(0, X), then length is indeed X if it does not, then length is Y + 1 for highest Y where Y is greatest index that actually works The definition in PySequence_Tuple seemed quite clever when I first saw it, but I like it less now. If a user-defined sequence raises IndexError when len indicates it should not, the code is broken. The attempt to continue anyway is masking an error in user code. I vote for fixing PySequence_Tuple and the like to raise an IndexError. Jeremy From tim_one at email.msn.com Mon Jul 10 19:26:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 13:26:36 -0400 Subject: [Python-Dev] file closed! (was Re: CVS read/write access) In-Reply-To: <3969B399.FC5E1AC2@stud.ntnu.no> Message-ID: [Peter Schneider-Kamp] > ... > It was the group. But 20 minutes after I found out I checked again > and suddenly python had appeared. Must have been this cron delay. Yes, this sure fits the symptoms described at: http://sourceforge.net/docs/site/delay.php ... Updates to these other systems happen via cron 4 times per day, so changes made on the web site will appear to be live, but will not take effect until the next cron update. ... This includes all functions relating to mail aliases, shell passwords, user additions, group member changes, cvs repository creation, etc a-fine-art-to-knowing-when-sitting-on-your-ass-is-the-solution-ly y'rs - tim From mal at lemburg.com Mon Jul 10 19:30:20 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 19:30:20 +0200 Subject: [Python-Dev] new unicode hash calculation References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> Message-ID: <396A082C.77B4D71D@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > * change hash value calculation to work on the Py_UNICODE data > > instead of creating a default encoded cached object (what > > now is .utf8str) > > it this what you had in mind? > > static long > unicode_hash(PyUnicodeObject *self) > { > register int len; > register Py_UNICODE *p; > register long x; > > if (self->hash != -1) > return self->hash; > len = PyUnicode_GET_SIZE(self); > p = PyUnicode_AS_UNICODE(self); > x = *p << 7; > while (--len >= 0) > x = (1000003*x) ^ *p++; > x ^= a->ob_size; > if (x == -1) > x = -2; > self->hash = x; > return x; > } > > Well, sort of. It should be done in such a way that Unicode strings which only use the lower byte produce the same hash value as normal 8-bit strings -- is this the case for the above code ? My first idea was to apply a kind of two pass scan which first only uses the lower byte and then the higher byte to calculate a hash value. Both passes would use the same algorithm as the one for 8-bit strings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 10 19:32:31 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 19:32:31 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <200007101722.MAA01227@cj20424-a.reston1.va.home.com> Message-ID: <396A08AF.655B4836@lemburg.com> Guido van Rossum wrote: > > > > OK, so there's code masking the ImportError in import_encodings() in > > > codecs.c. I disabled that (hmm, maybe this should be disabled > > > automatically when -v is used!). > > > > Hard to do since the setting of the verbosity flag is not > > available to Python code. > > Actually, it is: see pydebug.h, included by Python.h: > > extern DL_IMPORT(int) Py_VerboseFlag; Yes... I meant: it is not available from Python. (mx.Tools publishes an interface to this flag: sys.verbosity() which also allows setting the value at runtime.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Mon Jul 10 20:38:46 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 13:38:46 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: Your message of "Mon, 10 Jul 2000 12:35:50 -0400." <20000710123550.A8478@thyrsus.com> References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> Message-ID: <200007101838.NAA01448@cj20424-a.reston1.va.home.com> > From: "Eric S. Raymond" > Guido van Rossum : > > I believe you are mistaken, or at least expressing yourself unclearly > > in the checkin comment. While the test function *objects* indeed > > aren't created in your new version, it doesn't actually save any time > > when loading the module: all the code in a module is parsed, or all > > the bytecode is unmarshalled, regardless of whether it is executed. > > All you save in performance is a LOAD_CONST, a MAKE_FUNCTION, and a > > STORE_NAME -- all of which don't really do any work. > > OK, correction accepted. But this is still a good idea for documentation > purposes, no? Actually, it makes manual testing of the module a little harder: from inside Python, I used to be able to say >>> import urllib >> urllib.test() With your change that doesn't work any more, so I'd rather see you revert it back... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 20:43:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 13:43:29 -0500 Subject: [Python-Dev] why isn't SRE a shared module? In-Reply-To: Your message of "Mon, 10 Jul 2000 18:45:27 +0200." <007901bfea8e$8ee9b600$f2a6b5d4@hagrid> References: <007901bfea8e$8ee9b600$f2a6b5d4@hagrid> Message-ID: <200007101843.NAA01635@cj20424-a.reston1.va.home.com> > from Modules/Setup.in: > > # The modules listed here can't be built as shared libraries for > # various reasons; therefore they are listed here instead of in the > # normal order. > > # Some modules that are normally always on: > > regex regexmodule.c regexpr.c # Regular expressions, GNU Emacs style > pcre pcremodule.c pypcre.c # Regular expressions, Perl style (for re.py) > posix posixmodule.c # posix (UNIX) system calls > signal signalmodule.c # signal(2) > _sre _sre.c # Fredrik Lundh's new regular expressions > > possibly a stupid question, but what exactly is SRE doing > in there? I think the comments are confusing. The first comment has it right -- I think posix and signal *must* be static. I'm not so sure about the rest... It's just recommended to link them statically because you'll end up loading them into 99% of all Python processes anyway. Of course, that's no longer true fo regex or pcre so they should be moved down anyway. It's up to you if you want to suggest special status for _sre.c... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 20:51:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 13:51:05 -0500 Subject: [Python-Dev] new unicode hash calculation In-Reply-To: Your message of "Mon, 10 Jul 2000 19:07:15 +0200." <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> Message-ID: <200007101851.NAA01792@cj20424-a.reston1.va.home.com> > mal wrote: > > > * change hash value calculation to work on the Py_UNICODE data > > instead of creating a default encoded cached object (what > > now is .utf8str) [effbot] > it this what you had in mind? > > static long > unicode_hash(PyUnicodeObject *self) > { > register int len; > register Py_UNICODE *p; > register long x; > > if (self->hash != -1) > return self->hash; > len = PyUnicode_GET_SIZE(self); > p = PyUnicode_AS_UNICODE(self); > x = *p << 7; > while (--len >= 0) > x = (1000003*x) ^ *p++; > x ^= a->ob_size; > if (x == -1) > x = -2; > self->hash = x; > return x; > } You mean this (fixed a->ob_size, restored comment): static long unicode_hash(PyUnicodeObject *self) { /* Since Unicode objects compare equal to their ASCII string counterparts, they should also use the ASCII strings as basis for their hash value. This is needed to assure that strings and Unicode objects behave in the same way as dictionary keys. */ register int len; register Py_UNICODE *p; register long x; if (self->hash != -1) return self->hash; len = PyUnicode_GET_SIZE(self); p = PyUnicode_AS_UNICODE(self); x = *p << 7; while (--len >= 0) x = (1000003*x) ^ *p++; x ^= PyUnicode_GET_SIZE(self); if (x == -1) x = -2; self->hash = x; return x; } --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 20:58:07 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 13:58:07 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Mon, 10 Jul 2000 12:43:03 -0400." <3969FD17.487DA96A@interet.com> References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> <3969FD17.487DA96A@interet.com> Message-ID: <200007101858.NAA01814@cj20424-a.reston1.va.home.com> [James Ahlstrom makes a plea for keeping the DLL name unchanged (python15.dll) so that existing extensions don't have to be rebuilt if they don't make calls to API functions that changed.] The problem with this is that it's hard to say whether this is the case. We haven't made an effort to keep the APIs compatible, because we were planning to change the DLL name to be incompatible. I guess we'd need a Microsoft style testing department that collects a large set of existing 1.5 style extensions, builds a Python 2.0 DLL named python15.dll, and tests whether all those 1.5 style extensions work correctly. Seems a lot of work to me. Plus, we'd have to check whether we didn't change any of the object lay-outs that are accessible via macros... Frankly, I'd rather declare incompatibility than do all the work. What's it good for? We're not forcing people to upgrade if their favorite DLLs haven't been upgraded yet... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 21:02:37 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 14:02:37 -0500 Subject: [Python-Dev] new unicode hash calculation In-Reply-To: Your message of "Mon, 10 Jul 2000 19:30:20 +0200." <396A082C.77B4D71D@lemburg.com> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> <396A082C.77B4D71D@lemburg.com> Message-ID: <200007101902.OAA01883@cj20424-a.reston1.va.home.com> > Well, sort of. It should be done in such a way that Unicode > strings which only use the lower byte produce the same hash > value as normal 8-bit strings -- is this the case for the > above code ? I already checked it -- it does, for ASCII or Latin-1 as the default encoding. Good enough for me. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Mon Jul 10 20:25:19 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 14:25:19 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101838.NAA01448@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 01:38:46PM -0500 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> Message-ID: <20000710142519.A8794@thyrsus.com> Guido van Rossum : > With your change that doesn't work any more, so I'd rather see you > revert it back... How do I do that in CVS-land? BTW, this patch was mostly just a test to verify that my CVS access mechanics work. So I'm not miffed at being asked to back it out. Also BTW, my access mechanics are a Python script called `forgetool' that automates away a bunch of CVS housekeeping -- setting CVSROOT properly on a per-project basis is one of the things it does. I'll write some docs and release it shortly. -- Eric S. Raymond The conclusion is thus inescapable that the history, concept, and wording of the second amendment to the Constitution of the United States, as well as its interpretation by every major commentator and court in the first half-century after its ratification, indicates that what is protected is an individual right of a private citizen to own and carry firearms in a peaceful manner. -- Report of the Subcommittee On The Constitution of the Committee On The Judiciary, United States Senate, 97th Congress, second session (February, 1982), SuDoc# Y4.J 89/2: Ar 5/5 From effbot at telia.com Mon Jul 10 20:31:01 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 20:31:01 +0200 Subject: [Python-Dev] new unicode hash calculation References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> <396A082C.77B4D71D@lemburg.com> <200007101902.OAA01883@cj20424-a.reston1.va.home.com> Message-ID: <012f01bfea9d$0a1cfc20$f2a6b5d4@hagrid> mal wrote: > It should be done in such a way that Unicode strings which > only use the lower byte produce the same hash value as > normal 8-bit strings -- is this the case for the above code ? yup. it's the same algorithm as for 8-bit strings, but using larger characters. as long as the high bits are zero, it (obviously) gives the same result. guido: > Good enough for me. I'll interpret that as a "okay, check it in". From guido at beopen.com Mon Jul 10 21:26:25 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 14:26:25 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: Your message of "Mon, 10 Jul 2000 14:25:19 -0400." <20000710142519.A8794@thyrsus.com> References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> Message-ID: <200007101926.OAA02072@cj20424-a.reston1.va.home.com> > How do I do that in CVS-land? cvs admin -o Or you could retrieve the previous version and check it in on top, with a comment such as "eating my words". :-) > BTW, this patch was mostly just a test to verify that my CVS access > mechanics work. So I'm not miffed at being asked to back it out. Thanks. > Also BTW, my access mechanics are a Python script called `forgetool' > that automates away a bunch of CVS housekeeping -- setting CVSROOT > properly on a per-project basis is one of the things it does. I'll > write some docs and release it shortly. I thought that you almost never have to set the CVSROOT variable once you've established your project work tree -- it's all stored in CVS/Root anyway. I believe CVSROOT is only used when you do a "cvs checkout" and that doesn't happen very often... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 21:36:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 14:36:05 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 19:32:31 +0200." <396A08AF.655B4836@lemburg.com> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <200007101722.MAA01227@cj20424-a.reston1.va.home.com> <396A08AF.655B4836@lemburg.com> Message-ID: <200007101936.OAA02180@cj20424-a.reston1.va.home.com> > Yes... I meant: it is not available from Python. (mx.Tools > publishes an interface to this flag: sys.verbosity() which > also allows setting the value at runtime.) It would make a lot of sense for the sys module to allow access to the values of all the Python command line options, and perhaps to allow changing them. Anybody interested in designing an API here? Some requirements would be platform independence, extensibility, and necessarily the ability to work even in an environment without command line flags (since it still has the corresponding internal flags). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Mon Jul 10 20:50:32 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 14:50:32 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101926.OAA02072@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 02:26:25PM -0500 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> <200007101926.OAA02072@cj20424-a.reston1.va.home.com> Message-ID: <20000710145031.A8888@thyrsus.com> Guido van Rossum : > I thought that you almost never have to set the CVSROOT variable once > you've established your project work tree -- it's all stored in > CVS/Root anyway. I believe CVSROOT is only used when you do a "cvs > checkout" and that doesn't happen very often... It's also needed when you login for anonymous access. Forgetool is intended for people like me who need to manage access to multiple SourceForge projects, some as a developer and some anonymously. It manages some local state about which projects you have developer access to and uses that to set CVSROOT and CVS_RSH correctly. Forgetool also supplies boilerplate for commands to copy files to the project HTTP directory. Things it will do soon: 1) Manage shared session keys so you don't have to type a password on each command. 2) Remote scripting of module releases. The basic idea is to make forgetool a Swiss-army knife for SourceForge developers who need to remote-script various common operations. This capability is not a big deal when you are active in one or two projects -- but I run thirty-five (yes, that's 35) projects that are waiting to move to SourceForge the day I can script the release process. -- Eric S. Raymond Every election is a sort of advance auction sale of stolen goods. -- H.L. Mencken From gstein at lyra.org Mon Jul 10 20:50:14 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 11:50:14 -0700 Subject: [Python-Dev] Re: CVS: python/dist/src/Lib locale.py,1.7,1.8 In-Reply-To: <14697.53306.858387.422925@bitdiddle.concentric.net>; from jeremy@beopen.com on Mon, Jul 10, 2000 at 09:31:38AM -0400 References: <200007091713.KAA02613@slayer.i.sourceforge.net> <20000710020930.T29590@lyra.org> <14697.53306.858387.422925@bitdiddle.concentric.net> Message-ID: <20000710115014.G29590@lyra.org> On Mon, Jul 10, 2000 at 09:31:38AM -0400, Jeremy Hylton wrote: > >>>>> "GS" == Greg Stein writes: > > GS> Can I request (from everyone) to do white space changes *only*, > GS> or to do functional changes *only*. It will make it a lot easier > GS> on the people who are reviewing the checkins. > > Only if you checkin in your own whitespaces changes! <0.7 wink> hehe... I will! I will! :-) [ just been busy folding mod_dav into Apache 2.0. that is pretty much done now... ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul at prescod.net Mon Jul 10 20:54:05 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 10 Jul 2000 13:54:05 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> <20000710022047.V29590@lyra.org> Message-ID: <396A1BCD.E08FB64D@prescod.net> Greg Stein wrote: > > > Because Python supports a configuration time option to link modules > > statically. Of course. I wasn't thinking. But here's another naive question, on what platforms is it significantly better to statically link and how is it significantly better? > Not to mention that the .so is loaded into the process' address space. I > don't think that you can have two symbols in the space with the same name. I've never been clear on that issue. It seems like an unreasonably strict constraint. Adding a function called "doit" to one library could break another dynamically library that happens to have the same name defined? I'd call that a bug in the dynamic loading infrastructure (and certainly not a problem on Windows!)! -- Paul Prescod - Not encumbered by corporate consensus "Computer Associates is expected to come in with better than expected earnings." Bob O'Brien, quoted in - http://www.fool.com/news/2000/foth000316.htm From paul at prescod.net Mon Jul 10 21:00:19 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 10 Jul 2000 14:00:19 -0500 Subject: [Python-Dev] file closed! (was Re: CVS read/write access) References: <39699715.E3368F53@stud.ntnu.no> <20000710014329.Q29590@lyra.org> <3969B399.FC5E1AC2@stud.ntnu.no> Message-ID: <396A1D43.A0F8FF50@prescod.net> Peter Schneider-Kamp wrote: > > Greg Stein wrote: > > > > If so, then it is a problem that the SF Admins must solve. It means that you > > haven't been placed into the appropriate group or somesuch on SF. Log a > ----- > > It was the group. But 20 minutes after I found out I checked again > and suddenly python had appeared. Must have been this cron delay. I had the same symptoms and the same solution (wait a few hours) when I joined pyxml. We should remember it in the future. -- Paul Prescod - Not encumbered by corporate consensus "Computer Associates is expected to come in with better than expected earnings." Bob O'Brien, quoted in - http://www.fool.com/news/2000/foth000316.htm From guido at beopen.com Mon Jul 10 22:14:50 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 15:14:50 -0500 Subject: [Python-Dev] string.join and bad sequences In-Reply-To: Your message of "Mon, 10 Jul 2000 13:24:27 -0400." <14698.1739.660431.756932@bitdiddle.concentric.net> References: <200007101708.KAA08018@slayer.i.sourceforge.net> <14698.1739.660431.756932@bitdiddle.concentric.net> Message-ID: <200007102014.PAA02382@cj20424-a.reston1.va.home.com> > I added a test case to Lib/test/string_tests.py that uses a sequence > that returns the wrong answer from __len__. I've used this test in a > number of places to make sure the interpreter doesn't dump core when > it hits a bad user-defined sequence. > > class Sequence: > def __init__(self): self.seq = 'wxyz' > def __len__(self): return len(self.seq) > def __getitem__(self, i): return self.seq[i] > > class BadSeq2(Sequence): > def __init__(self): self.seq = ['a', 'b', 'c'] > def __len__(self): return 8 > > The test of string.join and " ".join don't dump core, but they do > raise an IndexError. I wonder if that's the right thing to do, > because the other places where it is handled no exception is raised. > > The question boils down to the semantics of the sequence protocol. > > The string code defintion is: > if __len__ returns X, then the length is X > thus, __getitem__ should succeed for range(0, X) > if it doesn't, raise an IndexError > > The other code (e.g. PySequence_Tuple) definition is: > if __len__ return X, then the length is <= X > if __getitem__ succeeds for range(0, X), then length is indeed X > if it does not, then length is Y + 1 for highest Y > where Y is greatest index that actually works > > The definition in PySequence_Tuple seemed quite clever when I first > saw it, but I like it less now. If a user-defined sequence raises > IndexError when len indicates it should not, the code is broken. The > attempt to continue anyway is masking an error in user code. > > I vote for fixing PySequence_Tuple and the like to raise an > IndexError. I'm not sure I agree. When Steve Majewski proposed variable-length sequences, we ended up conceding that __len__ is just a hint. The actual length can be longer or shorter. The map and filter functions allow this, and so do min/max and others that go over sequences, and even (of course) the for loop. (In fact, the preferred behavior is not to call __len__ at all but just try x[0], x[1], x[2], ... until IndexError is hit.) If I read your description of PySequence_Tuple(), it accepts a __len__ that overestimates but not one that understestimates. That's wrong. (In Majewski's example, a tar file wrapper would claim to have 0 items but iterating over it in ascending order would access all the items in the file. Claiming some arbitrary integer as __len__ would be wrong.) So string.join(BadSeq2(), "") or "".join(BadSeq2()) should return "abc". --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Mon Jul 10 21:55:55 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 21:55:55 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <396A1BCD.E08FB64D@prescod.net>; from paul@prescod.net on Mon, Jul 10, 2000 at 01:54:05PM -0500 References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> <20000710022047.V29590@lyra.org> <396A1BCD.E08FB64D@prescod.net> Message-ID: <20000710215555.Q26534@xs4all.nl> On Mon, Jul 10, 2000 at 01:54:05PM -0500, Paul Prescod wrote: [Quoting Guido, IIRC] > > > Because Python supports a configuration time option to link modules > > > statically. > Of course. I wasn't thinking. But here's another naive question, on what > platforms is it significantly better to statically link and how is it > significantly better? Well, platforms that do not support dynamic linking/loading, for one ! :-) Not that frequent nowadays, but still something to take into account. Also, some platforms, like BSDI until not that long ago, use a binary format like COFF, which doesn't support shared libraries all that well. It's more of a hack (and a slightly insecure one, at that) than a structural solution. Which is why BSDI moved to ELF, thankfully :-) Also, shared libraries are an aditional performance hit, because of the extra layer of indirection (sometimes more than one) and on some architectures different memory layout. So people might choose to link (some) modules static for that reason. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From barry at scottb.demon.co.uk Mon Jul 10 22:09:20 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Mon, 10 Jul 2000 21:09:20 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007100149.UAA16917@cj20424-a.reston1.va.home.com> Message-ID: <000701bfeaaa$bb8dde40$060210ac@private> > There are endless variations on this theme. What's missing at the > moment is a bit of requirements analysis. What's the problem we're > trying to solve here? So far, the only problem that came up was that > on Windows, you get an obscure crash when trying to load an extension > built for Python 1.5(.x). Do we really need a whole new version > negotiating architecture? You can already get the version string by > looking at Py_GetVersion() -- this also answers the question of how a > version is represented. I post the first mail as I think it reflects poorly on Python if it crashes for this preventable reason. How important this problem is depends on how many users it will affect. Is it only a few .pyd that fail or all of them? Will a few users see this or lots of them? I'd hope one requirement is not to look bad in the eyes of the python users. When the old extension calls Py_GetVersion() it will be the python15.dll:Py_GetVersion(). Not the new one. Integer version values would be nicer to handle then hacking a string up. Barry From esr at thyrsus.com Mon Jul 10 22:28:55 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 16:28:55 -0400 Subject: [Python-Dev] Changes to ConfigParser Message-ID: <20000710162855.A9245@thyrsus.com> Earlier today, I committed a patch to ConfigParser that adds three new methods to the class. Here is the documentation: \begin{methoddesc}{has_option}{section, option} If the given section exists, and contains the given option. return 1; otherwise return 0. (New in 1.6) \end{methoddesc} \begin{methoddesc}{set}{section, option, value} If the given section exists, set the given option to the specified value; otherwise raise \exception{NoSectionError}. (New in 1.6) \end{methoddesc} \begin{methoddesc}{write}{fileobect} Write a representation of the configuration to the specified file object. This representation can be parsed by a future \method{read()} call. (New in 1.6) \end{methoddesc} These new methods are additions to the class, and do not change any existing code. Nevertheless Guido sent me a heads-up that I had committed a marginal violation of Python etiquette by changing the module without the explicit sign-off of the maintainers. For this I apologize, specifically to Andrew Kuchling and Barry Warsaw. Please note that I specifically refrained from fixing a bug in the existing code that was exposed by the new methods, in order to avoid the risk of breaking compatibility. Now I want to explain what I'm doing, specifically the next steps in my plan, and make sure there is a consensus to support it. I am working on a program called `forgetool' that is intended as a front end to SourceForge. It will keep your CVSROOT set properly as you hop between multiple projects, make it easy to do uploads to project HTTP directories without remembering a lot of boilerplate, enable remote scripting of releases, and in general serve as a SourceForge developer's Swiss-army knife. To do these things, forgetool needs to maintain some local state that is conveniently represented in the format of a Windows .ini file. More, it needs to be able to *update* .ini files as well as parse them. Accordingly, forgetool subclasses ConfigParser into EnhancedConfigParser adding the above methods. After testing them, I copied this code into ConfigParser for others to use. Two more things remain to be done: First, for completeness there ought to be remove_section and remove_option methods (though forgetool does not yet use them). I have documented these as follows: \begin{methoddesc}{remove_option}{section, option} Remove the specified \var{option} from the specified \var{section}. If the section does not exist, raise \exception{NoSectionError}. If the option existed to be removed, return 1; otherwise return 0. (New in 1.6) \end{methoddesc} \begin{methoddesc}{remove_section}{section} Remove the specified \var{section} from the configuration. If the section in fact existed, return 1. Otherwise return 0. \end{methoddesc} Second, the new methods expose a bug in the existing code. Because the case of section and option names is folded on input, the new write() method emits edited configurations with their case smashed. I think the existing code should be fixed to preserve case, with string.lower() being applied at key lookup time. Does anybody have a problem with these changes? Barry? Andrew? Again, I apologize for offending the local norms. I'm still learning... -- Eric S. Raymond If gun laws in fact worked, the sponsors of this type of legislation should have no difficulty drawing upon long lists of examples of criminal acts reduced by such legislation. That they cannot do so after a century and a half of trying -- that they must sweep under the rug the southern attempts at gun control in the 1870-1910 period, the northeastern attempts in the 1920-1939 period, the attempts at both Federal and State levels in 1965-1976 -- establishes the repeated, complete and inevitable failure of gun laws to control serious crime. -- Senator Orrin Hatch, in a 1982 Senate Report From akuchlin at mems-exchange.org Mon Jul 10 22:29:55 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 10 Jul 2000 16:29:55 -0400 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162855.A9245@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 10, 2000 at 04:28:55PM -0400 References: <20000710162855.A9245@thyrsus.com> Message-ID: <20000710162955.C7313@kronos.cnri.reston.va.us> On Mon, Jul 10, 2000 at 04:28:55PM -0400, Eric S. Raymond wrote: >Does anybody have a problem with these changes? Barry? Andrew? *blink* I've never even touched the ConfigParser module, so I don't know why Guido thought I had any interest in it. The first check-in comment for the module is "This was originally written by Ken and later revamped by Barry." --amk From esr at thyrsus.com Mon Jul 10 22:43:04 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 16:43:04 -0400 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162955.C7313@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Mon, Jul 10, 2000 at 04:29:55PM -0400 References: <20000710162855.A9245@thyrsus.com> <20000710162955.C7313@kronos.cnri.reston.va.us> Message-ID: <20000710164304.B9337@thyrsus.com> Andrew Kuchling : > *blink* I've never even touched the ConfigParser module, so I don't > know why Guido thought I had any interest in it. The first check-in > comment for the module is "This was originally written by Ken and > later revamped by Barry." Doh. Sorry. My bad. It is Ken, not Andrew. -- Eric S. Raymond A ``decay in the social contract'' is detectable; there is a growing feeling, particularly among middle-income taxpayers, that they are not getting back, from society and government, their money's worth for taxes paid. The tendency is for taxpayers to try to take more control of their finances .. -- IRS Strategic Plan, (May 1984) From fdrake at beopen.com Mon Jul 10 23:00:37 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:00:37 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules md5.h,2.5,2.6 md5c.c,2.3,2.4 In-Reply-To: <004201bfea3f$17b154c0$f2a6b5d4@hagrid> References: <200007100421.VAA16454@slayer.i.sourceforge.net> <004201bfea3f$17b154c0$f2a6b5d4@hagrid> Message-ID: <14698.14709.491272.693396@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > weren't you supposed to drop out of sight for a while? I did; I just poked my head round the corner when they were all asleep! ;-) But I've been out of touch for most of the day, so they've had as much of my time as they can handle for a couple of hours. Maybe I can get some of this email deleted! > besides, I'd assigned these patches to myself, and applied > them locally. just thought I'd get some sleep before I checked > them in again. > > (iow, please check the patch archive before hacking along. > someone else might be working on the same thing) Ah, I'd checked the open patches, but was in too much of a rush. Sorry! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Mon Jul 10 23:05:48 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:05:48 -0400 (EDT) Subject: [Python-Dev] CVS: python/dist/src/Modules posixmodule.c,2.143,2.144 In-Reply-To: <20000710013250.P29590@lyra.org> References: <200007091310.GAA27888@slayer.i.sourceforge.net> <20000710013250.P29590@lyra.org> Message-ID: <14698.15020.771347.741561@cj42289-a.reston1.va.home.com> Greg Stein writes: > hmm. should that be PyLong_FromVoidPtr() ? It will return the appropriate > object type based on the size of a void*. Greg, I see that the PyLong_FromVoidPtr() isn't documented -- are you volunteering? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Mon Jul 10 23:12:31 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 17:12:31 -0400 (EDT) Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length Message-ID: <14698.15423.878220.203259@bitdiddle.concentric.net> Tuple, List, String, and Dict have a PyXXX_Size method. The abstract object interface uses PySequence_Length. This is inconsistent and hard to remember. Can we add PySequence_Size and mark Length as deprecated? Jeremy From gstein at lyra.org Mon Jul 10 23:16:38 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 14:16:38 -0700 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <200007101725.MAA01255@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 12:25:12PM -0500 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> Message-ID: <20000710141638.R29590@lyra.org> On Mon, Jul 10, 2000 at 12:25:12PM -0500, Guido van Rossum wrote: > > I didn't bother to check, but does the embed Makefile include python's > > Makefile* stuff from $prefix/config ? Does it contain -export-dynamic ? If > > so, very pecurliar... ;-P > > Makefile includes are notoriously unportable, aren't they? The > embed/Makefile is a lame excuse for a Makefile -- it has XXX comments > all over the place telling you to edit things to match the Python main > Makefile... :-( My fault -- feel free to fix! We're using includes in the Apache 2.0 makefiles. I'm not sure whether this is going to make Apache 2.0 less portable or not. There haven't been any issues yet, though. (I think the makefile organization came from PHP; assuming that is as portable as Apache 1.3, then makefile includes are pretty darn portable) IMO, I say "start using makefile includes" and see who screams. VPATH is not portable, though. Cheers, -g -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Mon Jul 10 23:22:22 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 23:22:22 +0200 Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length References: <14698.15423.878220.203259@bitdiddle.concentric.net> Message-ID: <025001bfeab4$f07251e0$f2a6b5d4@hagrid> jeremy wrote: > Tuple, List, String, and Dict have a PyXXX_Size method. The abstract > object interface uses PySequence_Length. This is inconsistent and > hard to remember. Can we add PySequence_Size and mark Length as > deprecated? don't forget PyObject_Length and PyMapping_Length... From fdrake at beopen.com Mon Jul 10 23:20:04 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:20:04 -0400 (EDT) Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <20000710023523.Y29590@lyra.org> References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> <20000710023523.Y29590@lyra.org> Message-ID: <14698.15876.760261.661549@cj42289-a.reston1.va.home.com> Greg Stein writes: > bah. just file feature requests for them to use ViewCVS. cvsweb is a piece > of crap anyways :-) I've heard you say this before, but I've never had any problems with cvsweb. The display seems fine and I've never missed a feature. If you're being serious and not just plugging your own code, you need to be specific about the problems, and how ViewCVS is better. The problem with had with ViewCVS at python.org was the use of a single file for the script; parsing the whole thing for every run was just too slow. Part of that is the machine, part was configuration, and part was an overly high cost to the convenient installation. The last of those is in your court (possibly fixed by a more recent version; I don't know). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein at lyra.org Mon Jul 10 23:29:54 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 14:29:54 -0700 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <14698.15876.760261.661549@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 10, 2000 at 05:20:04PM -0400 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> <20000710023523.Y29590@lyra.org> <14698.15876.760261.661549@cj42289-a.reston1.va.home.com> Message-ID: <20000710142954.S29590@lyra.org> On Mon, Jul 10, 2000 at 05:20:04PM -0400, Fred L. Drake, Jr. wrote: > > Greg Stein writes: > > bah. just file feature requests for them to use ViewCVS. cvsweb is a piece > > of crap anyways :-) > > I've heard you say this before, but I've never had any problems with > cvsweb. The display seems fine and I've never missed a feature. If > you're being serious and not just plugging your own code, you need to > be specific about the problems, and how ViewCVS is better. From fdrake at beopen.com Mon Jul 10 23:29:00 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:29:00 -0400 (EDT) Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <39699401.790447E8@lemburg.com> References: <20000709215057.95047E2673@oratrix.oratrix.nl> <39699401.790447E8@lemburg.com> Message-ID: <14698.16412.396383.814694@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > There are lots of comments about it in site.py. > sys.setdefaultencoding() is meant to be used *only* in site.py-- > that's why it gets removed after having made the final decision The fact that it gets removed and is only provided as a hook for site.py needs to be documented in comments in sysmodule.c. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From effbot at telia.com Mon Jul 10 23:34:41 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 23:34:41 +0200 Subject: [Python-Dev] Sourceforge Interface Concerns References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com><20000710023523.Y29590@lyra.org> <14698.15876.760261.661549@cj42289-a.reston1.va.home.com> Message-ID: <027801bfeab6$aa6115e0$f2a6b5d4@hagrid> fred drake: > I've heard you say this before, but I've never had any problems with > cvsweb. The display seems fine and I've never missed a feature. If > you're being serious and not just plugging your own code, you need to > be specific about the problems, and how ViewCVS is better. it works with MSIE5, for a start. and it's written by greg, in python. that's all I need to know ;-) the IE problem could be a configuration problem, of course. unless tim beats me to it, I'll submit a support request some day... From fdrake at beopen.com Mon Jul 10 23:34:04 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:34:04 -0400 (EDT) Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <20000710100837.6232337186D@snelboot.oratrix.nl> References: <20000710100837.6232337186D@snelboot.oratrix.nl> Message-ID: <14698.16716.343786.196699@cj42289-a.reston1.va.home.com> Jack Jansen writes: > pretty abysmal commercial ssh which could possibly be beaten into > forwarding connections, but it's expensive (and it doesn't work:-). And port-forwarding isn't likely to help, either. ;( The remote CVS protocol can be used directly over a socket, but the standard CVS client isn't written to work that way with authentication. It really wants to talk to another process via a pipe (such as rsh or ssh); I have no idea how feasible this is on the Mac (because of my ignorance, not because I don't think the Mac can do it). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas at xs4all.net Mon Jul 10 23:34:16 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 23:34:16 +0200 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <027801bfeab6$aa6115e0$f2a6b5d4@hagrid>; from effbot@telia.com on Mon, Jul 10, 2000 at 11:34:41PM +0200 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com><20000710023523.Y29590@lyra.org> <14698.15876.760261.661549@cj42289-a.reston1.va.home.com> <027801bfeab6$aa6115e0$f2a6b5d4@hagrid> Message-ID: <20000710233416.S26534@xs4all.nl> On Mon, Jul 10, 2000 at 11:34:41PM +0200, Fredrik Lundh wrote: > the IE problem could be a configuration problem, of course. unless > tim beats me to it, I'll submit a support request some day... I seriously doubt it, unless cvsweb has an option 'break IE5'. (Or 'unbreak IE5', if you so wish ;) The symptoms Tim described exactly match one of the known bugs in IE. It might be fixed in a newer version of cvsweb, of course. If anyone is going to submit a support request, feel free to pass them my email for information on that bug ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Mon Jul 10 14:34:33 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 10 Jul 2000 07:34:33 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000709233525.E26534@xs4all.nl> References: <14691.49563.78765.683762@beluga.mojam.com> <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> <14695.840.448508.397722@beluga.mojam.com> <20000709233525.E26534@xs4all.nl> Message-ID: <14697.49881.701839.36716@beluga.mojam.com> Thomas> I have a couple of questions regarding this patch, if you don't Thomas> mind.... Thomas, I don't mind at all. I will remind folks that I am more the messenger than the messiah on this one, however. Greg Ewing (greg at cosc.canterbury.ac.nz) is the author of the change, so will be much better equipped than me to reply to your comments. I'm more a fan of the construct who happened to be in the right place at the right time. All I did was update Greg's patch to work with 1.5.2+ (which became 1.6alpha, which became 2.0beta). Thomas> For one, the Grammar for list comprehensions: Thomas> '[' [testlist [list_iter]] ']' Thomas> Should that really be 'testlist'? Thomas> [1,2,3,4,5] Thomas> is a list of 5 elements, but Thomas> [1,2,3,4,5 if 1] Thomas> is a list of one element, which is a 5-element tuple. I'll take a look at it. I'm not much of a parser person and my reading of the grammar is hampered by the fact that Grammar/Grammar and the grammar in the language reference manual no longer mesh very well. (Is that something that can be remedied?) I notice that in the comment at the top of com_list_comprehension Greg said: atom: '[' test list_iter ']' which suggests that you are onto something and that the 'testlist' variant is either a typo or a mistake that wasn't corrected in a later version of Greg's thinking ... Thomas> I'd say the Grammar would be more like this: Thomas> atom: '(' [testlist] ')' | '[' [listmaker] ']' | '{' [dictmaker] '}' | '' testlist '' | NAME | NUMBER | STRING+ Thomas> listmaker: test ( list_iter | (',' test)* [',']) Thomas> list_iter: list_for | list_if Thomas> list_for: 'for' exprlist 'in' testlist [list_iter] Thomas> list_if: 'if' test [list_iter] Thomas> And by coincidence this is also fits very nicely with what the Thomas> 'range-literal' patch does ;-) If we're going to have both we should probably have them work together, I agree. Thomas> Another issue is the code- and logic-duplication of the patch to Thomas> compile.c: it looks like a large part was just copied from Thomas> com_for_node, and the block-stuff commented out. Why is it Thomas> commented out, by the way ? Don't exceptions or something need Thomas> the block setup ? If the block-setup was kept in, it might be Thomas> easier to split the com_for_node into a function that compiles Thomas> the header, and one that compiles the suite, and make Thomas> com_list_for compile its own 'suite'. I'm hoping that's Thomas> possible, because it would keep the code a lot cleaner, and it Thomas> would make it easier for me to implement 'for i in x;j in y' and Thomas> have it work for list comprehensions too ;-) Come up with an alternate patch that does what you want. I think very few people have actually looked at Greg's patch closely and that his original patch was more a proof of concept than a ready-for-primetime chunk of code. Thomas> Also, the patch creates a list, stores it locally, and calls Thomas> append() to it inside the inner loop. Isn't it possible for the Thomas> patch to build the list on the stack, pushing individual Thomas> elements on the stack and calling BUILD_LIST at the end ? The Thomas> for loops counts the number of loops anyway ;) and it would get Thomas> rid of the fairly ugly tmpname thing altogether, I Thomas> think. However, the logic of when to ROT_THREE and ROT_TWO and Thomas> what not might run away from under us ;-P (But I'm facing that Thomas> anyway, with the parallel-forloop) Dunno. Thomas> Alternatively, it would be nice to store the lists' append() in Thomas> a local vrbl, to reduce the number of lookups ;-P Oh, and Thomas> lastly, the patch is just screaming for a re-indent all over, Thomas> and of some wel-placed comments... some of it was quite Thomas> difficult to follow, compared to the rest of the code. Yes, it does need to be reindented. Greg, can you give us some feedback on Thomas's comments when you get a chance? -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From gstein at lyra.org Tue Jul 11 00:11:07 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 15:11:07 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101926.OAA02072@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 02:26:25PM -0500 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> <200007101926.OAA02072@cj20424-a.reston1.va.home.com> Message-ID: <20000710151106.U29590@lyra.org> On Mon, Jul 10, 2000 at 02:26:25PM -0500, Guido van Rossum wrote: > > How do I do that in CVS-land? > > cvs admin -o I don't think the use of "cvs admin" should ever be encouraged. > Or you could retrieve the previous version and check it in on top, > with a comment such as "eating my words". :-) This is usually best, and it tracks what is actually occurring. Note that Eric's use of "cvs admin" did not generate a checkin email. Only by going and looking at the file, did I see that he has actually reverted the change. Committing over the top would generate a checkin message, so people can track the state of things. >... > > Also BTW, my access mechanics are a Python script called `forgetool' > > that automates away a bunch of CVS housekeeping -- setting CVSROOT > > properly on a per-project basis is one of the things it does. I'll > > write some docs and release it shortly. > > I thought that you almost never have to set the CVSROOT variable once > you've established your project work tree -- it's all stored in > CVS/Root anyway. I believe CVSROOT is only used when you do a "cvs > checkout" and that doesn't happen very often... This is correct. CVSROOT never needs to be set or to be changed once you have a working directory. In fact, with Python, I usually do the following: $ cvs ... co python $ mv python x $ mv x/dist/src python $ rm -r x The extra "dist/src" in the local filesystem is just annoying :-) Point is: CVS knows that my new python/ directory actually corresponds to python/dist/src/ in the CVS repository because of the CVS/* files. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jul 11 00:16:41 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 15:16:41 -0700 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <14698.16412.396383.814694@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 10, 2000 at 05:29:00PM -0400 References: <20000709215057.95047E2673@oratrix.oratrix.nl> <39699401.790447E8@lemburg.com> <14698.16412.396383.814694@cj42289-a.reston1.va.home.com> Message-ID: <20000710151641.V29590@lyra.org> On Mon, Jul 10, 2000 at 05:29:00PM -0400, Fred L. Drake, Jr. wrote: > > M.-A. Lemburg writes: > > There are lots of comments about it in site.py. > > sys.setdefaultencoding() is meant to be used *only* in site.py-- > > that's why it gets removed after having made the final decision > > The fact that it gets removed and is only provided as a hook for > site.py needs to be documented in comments in sysmodule.c. Um. I thought the current consensus was to remove setdefaultencoding() altogether and just stick with an ASCII default encoding. I don't think we should let people change the default if that is going to break other parts of the Python interpreter. It could also seriously mess up code that is expecting that hard-coded ASCII default. Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw at beopen.com Tue Jul 11 00:20:54 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 10 Jul 2000 18:20:54 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection (I think) Message-ID: <14698.19526.232315.802728@anthem.concentric.net> While running through the test suite with Purify, I ran across the following script which core dumps the current CVS snapshot. You need to have gc enabled to trigger this. I'm running on Solaris 2.6, using gcc 2.8.1. It also cores my Linux build of Python from CVS using egcs-2.91.66. -Barry -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: core.py URL: -------------- next part -------------- -------------------- snip snip -------------------- Program received signal SIGSEGV, Segmentation fault. 0x18659c in gc_list_remove (node=0x48028c) at ./gcmodule.c:86 86 node->gc_prev->gc_next = node->gc_next; (gdb) where #0 0x18659c in gc_list_remove (node=0x48028c) at ./gcmodule.c:86 #1 0x186fb4 in visit_reachable (op=0x480298, roots=0xefffe648) at ./gcmodule.c:194 #2 0x1227b0 in list_traverse (o=0x494ae4, visit=0x186f08 , arg=0xefffe648) at listobject.c:1339 #3 0x18710c in move_root_reachable (reachable=0xefffe648) at ./gcmodule.c:212 #4 0x187dc8 in collect (young=0x4026c0, old=0x4026cc) at ./gcmodule.c:390 #5 0x1883fc in collect_generations () at ./gcmodule.c:481 #6 0x1884e4 in _PyGC_Insert (op=0x4d48fc) at ./gcmodule.c:500 #7 0x147220 in PyTuple_New (size=1) at tupleobject.c:96 #8 0x148348 in tupleslice (a=0x4e40d4, ilow=1, ihigh=2) at tupleobject.c:294 #9 0xfbc80 in PySequence_GetSlice (s=0x4e40d4, i1=1, i2=2) at abstract.c:897 #10 0x8a100 in Exception__init__ (self=0x4d736c, args=0x4e40d4) at exceptions.c:217 #11 0xb0754 in call_builtin (func=0x445ce0, arg=0x4e40d4, kw=0x0) at ceval.c:2404 #12 0xb03fc in PyEval_CallObjectWithKeywords (func=0x445ce0, arg=0x4e40d4, kw=0x0) at ceval.c:2369 #13 0xb0e9c in call_function (func=0x445ce0, arg=0x4e40d4, kw=0x0) at ceval.c:2484 #14 0xb03bc in PyEval_CallObjectWithKeywords (func=0x44ad34, arg=0x4e46bc, kw=0x0) at ceval.c:2367 #15 0x101988 in PyInstance_New (class=0x44f8ec, arg=0x4e46bc, kw=0x0) at classobject.c:472 #16 0xb07b8 in call_builtin (func=0x44f8ec, arg=0x4e46bc, kw=0x0) at ceval.c:2407 #17 0xb03fc in PyEval_CallObjectWithKeywords (func=0x44f8ec, arg=0x4e46bc, kw=0x0) at ceval.c:2369 #18 0xc6c30 in PyErr_NormalizeException (exc=0xefffedf8, val=0xefffedfc, tb=0xefffee00) at errors.c:190 #19 0xaba18 in eval_code2 (co=0x4b5c08, globals=0x4a5b94, locals=0x0, args=0x462a1c, argcount=2, kws=0x462a24, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1846 #20 0xa7f3c in eval_code2 (co=0x4b7eb0, globals=0x466824, locals=0x0, args=0x4e4b78, argcount=4, kws=0x4e4b88, kwcount=0, defs=0x4dcec8, defcount=1, owner=0x0) at ceval.c:1587 #21 0xa7f3c in eval_code2 (co=0x47d1f8, globals=0x466824, locals=0x0, args=0x4bac00, argcount=4, kws=0x0, kwcount=0, defs=0x4dcd18, defcount=1, owner=0x0) at ceval.c:1587 #22 0xb13c0 in call_function (func=0x4dcc2c, arg=0x4babf4, kw=0x0) at ceval.c:2529 #23 0xb03bc in PyEval_CallObjectWithKeywords (func=0x4dcc2c, arg=0x4babf4, kw=0x0) at ceval.c:2367 #24 0xfe284 in PyObject_CallObject (o=0x4dcc2c, a=0x4babf4) at abstract.c:1360 #25 0x1c42f4 in call (function=0x2cdbe0 "_sub", args=0x4babf4) at ./_sre.c:1458 #26 0x1c4514 in pattern_sub (self=0x4ea2a0, args=0x4e605c) at ./_sre.c:1474 #27 0xb0754 in call_builtin (func=0x4d42b0, arg=0x4e605c, kw=0x0) at ceval.c:2404 #28 0xb03fc in PyEval_CallObjectWithKeywords (func=0x4d42b0, arg=0x4e605c, kw=0x0) at ceval.c:2369 #29 0xa90f0 in eval_code2 (co=0x479378, globals=0x466824, locals=0x0, args=0x45d600, argcount=3, kws=0x45d60c, kwcount=0, defs=0x48e598, defcount=1, owner=0x0) at ceval.c:1688 #30 0xa7f3c in eval_code2 (co=0x47a6e8, globals=0x45b14c, locals=0x45b14c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1587 #31 0x8e71c in PyEval_EvalCode (co=0x47a6e8, globals=0x45b14c, locals=0x45b14c) at ceval.c:298 #32 0xe6f9c in run_node (n=0x4644f8, filename=0xeffffb26 "/tmp/core.py", globals=0x45b14c, locals=0x45b14c) at pythonrun.c:895 #33 0xe6eac in run_err_node (n=0x4644f8, filename=0xeffffb26 "/tmp/core.py", globals=0x45b14c, locals=0x45b14c) at pythonrun.c:880 #34 0xe6df0 in PyRun_File (fp=0x42e728, filename=0xeffffb26 "/tmp/core.py", start=257, globals=0x45b14c, locals=0x45b14c) at pythonrun.c:868 #35 0xe5218 in PyRun_SimpleFile (fp=0x42e728, filename=0xeffffb26 "/tmp/core.py") at pythonrun.c:578 #36 0xe4804 in PyRun_AnyFile (fp=0x42e728, filename=0xeffffb26 "/tmp/core.py") at pythonrun.c:459 #37 0x85584 in Py_Main (argc=3, argv=0xeffff9fc) at main.c:271 #38 0x84848 in main (argc=3, argv=0xeffff9fc) at python.c:10 From bwarsaw at beopen.com Tue Jul 11 00:24:58 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 10 Jul 2000 18:24:58 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> <200007101926.OAA02072@cj20424-a.reston1.va.home.com> <20000710151106.U29590@lyra.org> Message-ID: <14698.19770.699007.508033@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: | $ cvs ... co python | $ mv python x | $ mv x/dist/src python | $ rm -r x GS> The extra "dist/src" in the local filesystem is just annoying GS> :-) GS> Point is: CVS knows that my new python/ directory actually GS> corresponds to python/dist/src/ in the CVS repository because GS> of the CVS/* files. cvs ... co -d python python/dist/src will do the same thing, much more easily! -Barry From gstein at lyra.org Tue Jul 11 00:33:14 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 15:33:14 -0700 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162855.A9245@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 10, 2000 at 04:28:55PM -0400 References: <20000710162855.A9245@thyrsus.com> Message-ID: <20000710153314.W29590@lyra.org> On Mon, Jul 10, 2000 at 04:28:55PM -0400, Eric S. Raymond wrote: > Earlier today, I committed a patch to ConfigParser that adds three new > methods to the class. Here is the documentation: Excellent! I have a few subclasses of ConfigParser that do these things, too. Glad to see it in the standard distro :-) >... > These new methods are additions to the class, and do not change any > existing code. Nevertheless Guido sent me a heads-up that I had > committed a marginal violation of Python etiquette by changing the > module without the explicit sign-off of the maintainers. API changes probably ought to be discussed on this list (which includes the maintainers of any code). Basic point: the "maintainer(s)" is usually quite unclear since we avoid attribution within the source if at all possible. Posing the suggested change here allows for changing maintainers (note that Fred has done a tone of work on ConfigParser, and I've submitted a few changes myself, too!), and it allows for broader input. However, bug fixes and minor reworking should probably be allowed regardless of the maintainer. I'd hate to end up at a point where the Python interpreter is partitioned into a bunch of little fiefdoms, where you must pay a toll to enter. >... > Two more things remain to be done: > > First, for completeness there ought to be remove_section and remove_option > methods (though forgetool does not yet use them). I have documented these > as follows: +1 >... > Second, the new methods expose a bug in the existing code. Because > the case of section and option names is folded on input, the new > write() method emits edited configurations with their case smashed. I > think the existing code should be fixed to preserve case, with > string.lower() being applied at key lookup time. +1 The string.lower() at lookup time shifts the performance response, but I don't really see config state as performance-intensive. Cheers, -g -- Greg Stein, http://www.lyra.org/ From m.favas at per.dem.csiro.au Tue Jul 11 00:44:20 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Tue, 11 Jul 2000 06:44:20 +0800 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? Message-ID: <396A51C4.894E1550@per.dem.csiro.au> No problems (apart from the usual test failures) with the CVS from 10 July, but with CVS from 11 July I get core dumps at random points in "make test" which seem to point to a problem with the GC code. Sample dbx output: (Platform is DEC (Compaq) Alpha, Compaq C T6.3-125 (dtk) on Digital UNIX V4.0F (Rev. 1229)) dbx version 3.11.10 Type 'help' for help. Core file created by program "python" thread 0xb signal Segmentation fault at >*[__nxm_thread_kill, 0x3ff805c7ca8] ret r31, (r26), 1 (dbx) where > 0 __nxm_thread_kill(0x3ffc01b3c10, 0x1200f47dc, 0x0, 0x11fffeed0, 0x3ff8059c724) [0x3ff805c7ca8] 1 pthread_kill(0x1200ea970, 0x1, 0x0, 0x11fffeee0, 0x3ffc01b36c0) [0x3ff805ad6f4] 2 (unknown)() [0x3ff8059712c] 3 (unknown)() [0x3ff807e370c] 4 exc_unwind(0x11fffaf28, 0xabadabad00beed00, 0x3ff80592b90, 0x11fffb1c8, 0x3ff807e3acc) [0x3ff807e380c] 5 exc_raise_signal_exception(0x86, 0x0, 0x120159490, 0x1, 0x1) [0x3ff807e3ac8] 6 (unknown)() [0x3ff805af254] 7 (unknown)() [0x12015948c] 8 (unknown)() [0x12014f36c] 9 (unknown)() [0x120159844] 10 _PyGC_Insert(0x7f, 0x6f, 0x120111690, 0x2, 0x140155e20) [0x120159d04] This _PyGC_Insert always appears here in the trace - sometimes called from PyTuple_New, sometimes from PyMethod_New... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From petersc at stud.ntnu.no Tue Jul 11 03:05:10 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Tue, 11 Jul 2000 01:05:10 +0000 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? References: <396A51C4.894E1550@per.dem.csiro.au> Message-ID: <396A72C6.6810C95E@stud.ntnu.no> Mark Favas wrote: > > No problems (apart from the usual test failures) with the CVS from 10 > July, but with CVS from 11 July I get core dumps at random points in > "make test" which seem to point to a problem with the GC code. Sample > dbx output: I wouldn't bet my life on it, but I don't think the GC code is responsible. The only changes checked in during the last days were the "long n = 0;" initialization and my ANSI-fication (which I just reviewed and which should be harmless). don't-have-a-clue-though-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From tim_one at email.msn.com Tue Jul 11 01:10:19 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 19:10:19 -0400 Subject: [Python-Dev] Messy gc death Message-ID: With the latest CVS (as of 6:30pm EDT), the std test suite blows up under Windows release & debug builds, like so (this is debug): Adding parser accelerators ... Done. test_grammar test_opcodes test_operations test_builtin test_exceptions test_types test_MimeWriter test_al test test_al skipped -- an optional feature could not be imported test_array test_atexit with a memory error. However, test_atexit works fine in isolation, so this isn't a nice little local bug. The death is in this function from gcmodule.c: static int visit_decref(PyObject *op, void *data) { if (op && PyObject_IS_GC(op)) { ***********this line************** PyObject_AS_GC(op)->gc_refs--; } return 0; } data is NULL at this point, and op appears to be a legit memory address, but the fields in op make no sense: _ob_next is 0x24, _ob_prev is 1, and ob_type is the MS "landfill" value 0xfdfdfdfd (MS debug libraries set malloc'ed memory to that). Chasing the bogus ob_type address is the cause of the meltdown. Here's the traceback: visit_decref(_object * 0x0082ad60, void * 0x00000000) line 151 + 12 bytes list_traverse(PyListObject * 0x0082af7c, int (_object *, void *)* 0x1e14ee2d visit_decref(_object *, void *), void * 0x00000000) line 1339 + 11 bytes subtract_refs(_gc_head * 0x1e1dae18 generation0) line 167 + 17 bytes collect(_gc_head * 0x1e1dae18 generation0, _gc_head * 0x1e1dae28 generation1) line 383 + 9 bytes collect_generations() line 481 + 15 bytes _PyGC_Insert(_object * 0x0082ca6c) line 501 PyDict_New() line 111 + 9 bytes PyModule_New(char * 0x0063f160) line 29 + 5 bytes PyImport_AddModule(char * 0x0063f160) line 449 + 9 bytes PyImport_ExecCodeModuleEx(char * 0x0063f160, _object * 0x0082b4c0, char * 0x0063eea8) line 482 + 9 bytes load_source_module() line 758 + 17 bytes load_module(char * 0x0063f160, _iobuf * 0x1025a908, char * 0x0063f004, int 1) line 1240 + 17 bytes import_submodule(_object * 0x1e1e5bc0 __Py_NoneStruct, char * 0x0063f160, char * 0x0063f160) line 1793 + 33 bytes load_next(_object * 0x1e1e5bc0 __Py_NoneStruct, _object * 0x1e1e5bc0 __Py_NoneStruct, char * * 0x0063f274, char * 0x0063f160, int * 0x0063f15c) line 1641 + 17 bytes import_module_ex() line 1483 + 35 bytes PyImport_ImportModuleEx(char * 0x007d0eec, _object * 0x007e541c, _object * 0x007e541c, _object * 0x1e1e5bc0 __Py_NoneStruct) line 1527 + 21 bytes builtin___import__() line 47 + 21 bytes call_builtin(_object * 0x00761fd0, _object * 0x008033ac, _object * 0x00000000) line 2404 + 11 bytes PyEval_CallObjectWithKeywords(_object * 0x00761fd0, _object * 0x008033ac, _object * 0x00000000) line 2369 + 17 bytes eval_code2(PyCodeObject * 0x007e34f0, _object * 0x007e541c, _object * 0x007e541c, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * 0x00000000) line 1425 + 15 bytes PyEval_EvalCode(PyCodeObject * 0x007e34f0, _object * 0x007e541c, _object * 0x007e541c) line 303 + 31 bytes PyImport_ExecCodeModuleEx(char * 0x0063f75c, _object * 0x007e34f0, char * 0x0063f4a4) line 506 + 17 bytes load_source_module() line 758 + 17 bytes load_module(char * 0x0063f75c, _iobuf * 0x1025a8e8, char * 0x0063f600, int 1) line 1240 + 17 bytes import_submodule(_object * 0x1e1e5bc0 __Py_NoneStruct, char * 0x0063f75c, char * 0x0063f75c) line 1793 + 33 bytes load_next(_object * 0x1e1e5bc0 __Py_NoneStruct, _object * 0x1e1e5bc0 __Py_NoneStruct, char * * 0x0063f870, char * 0x0063f75c, int * 0x0063f758) line 1641 + 17 bytes import_module_ex() line 1483 + 35 bytes PyImport_ImportModuleEx(char * 0x007da7dc, _object * 0x0076edbc, _object * 0x0079f59c, _object * 0x0079942c) line 1527 + 21 bytes builtin___import__() line 47 + 21 bytes call_builtin(_object * 0x00761fd0, _object * 0x007e987c, _object * 0x00000000) line 2404 + 11 bytes PyEval_CallObjectWithKeywords(_object * 0x00761fd0, _object * 0x007e987c, _object * 0x00000000) line 2369 + 17 bytes eval_code2(PyCodeObject * 0x00854060, _object * 0x0076edbc, _object * 0x00000000, _object * * 0x0084cee4, int 4, _object * * 0x0084cef4, int 0, _object * * 0x0084a3e0, int 1, _object * 0x00000000) line 1690 + 26 bytes eval_code2(PyCodeObject * 0x00854fb0, _object * 0x0076edbc, _object * 0x00000000, _object * * 0x00771e6c, int 0, _object * * 0x00771e6c, int 0, _object * * 0x008493d0, int 8, _object * 0x00000000) line 1590 + 88 bytes eval_code2(PyCodeObject * 0x00854990, _object * 0x0076edbc, _object * 0x0076edbc, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * 0x00000000) line 1590 + 88 bytes PyEval_EvalCode(PyCodeObject * 0x00854990, _object * 0x0076edbc, _object * 0x0076edbc) line 303 + 31 bytes run_node(_node * 0x007d25d0, char * 0x00760dd9, _object * 0x0076edbc, _object * 0x0076edbc) line 895 + 17 bytes run_err_node(_node * 0x007d25d0, char * 0x00760dd9, _object * 0x0076edbc, _object * 0x0076edbc) line 880 + 21 bytes PyRun_File(_iobuf * 0x1025a888, char * 0x00760dd9, int 257, _object * 0x0076edbc, _object * 0x0076edbc) line 869 + 38 bytes PyRun_SimpleFile(_iobuf * 0x1025a888, char * 0x00760dd9) line 578 + 26 bytes PyRun_AnyFile(_iobuf * 0x1025a888, char * 0x00760dd9) line 459 + 13 bytes Py_Main(int 2, char * * 0x00760da0) line 273 + 34 bytes main(int 2, char * * 0x00760da0) line 10 + 13 bytes mainCRTStartup() line 338 + 17 bytes No wonder Python needs Stackless to run on a Palm . anyone-got-a-clue?-ly y'rs - tim From m.favas at per.dem.csiro.au Tue Jul 11 02:07:09 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Tue, 11 Jul 2000 08:07:09 +0800 Subject: [Python-Dev] Messy gc death (Was: Core dump in garbage collection: PyGC_Insert???) Message-ID: <396A652D.254B7FE8@per.dem.csiro.au> Throwing a -g flag at the compilation and poking at the resultant core, I get two different traces, depending on where it crashed during "make test". The first is the the same trace as Tim, viz: Core file created by program "python" thread 0x11 signal Segmentation fault at >*[__nxm_thread_kill, 0x3ff805c7ca8] ret r31, (r26), 1 (dbx) where > 0 __nxm_thread_kill(0x3ffc01b3c10, 0x1200f4ccc, 0x0, 0x11fffeed0, 0x3ff8059c724) [0x3ff805c7ca8] 1 pthread_kill(0x1200ea6b0, 0x1, 0x0, 0x11fffeee0, 0x3ffc01b36c0) [0x3ff805ad6f4] 2 (unknown)() [0x3ff8059712c] 3 (unknown)() [0x3ff807e370c] 4 exc_unwind(0x11fffc568, 0xabadabad00beed00, 0x4f, 0x11fffc808, 0x3ff807e3acc) [0x3ff807e380c] 5 exc_raise_signal_exception(0x86, 0x0, 0x12015bdf0, 0x1, 0x1) [0x3ff807e3ac8] 6 (unknown)() [0x3ff805af254] 7 visit_decref(op = 0x1405f0d40, data = (nil)) ["./gcmodule.c":151, 0x12015bdec] 8 list_traverse(o = 0x1405e0818, visit = 0x12015bde0, arg = (nil)) ["listobject.c":1339, 0x120151c10] 9 subtract_refs(containers = 0x140019b30) ["./gcmodule.c":165, 0x12015be54] 10 collect(young = 0x140019b30, old = 0x140019b48) ["./gcmodule.c":383, 0x12015c53c] 11 collect_generations() ["./gcmodule.c":481, 0x12015c84c] 12 _PyGC_Insert(op = 0x140430158) ["./gcmodule.c":500, 0x12015c8c0] and the second is: Core file created by program "python" thread 0xb signal Segmentation fault at >*[__nxm_thread_kill, 0x3ff805c7ca8] ret r31, (r26), 1 (dbx) where > 0 __nxm_thread_kill(0x3ffc01b3c10, 0x1200f4ccc, 0x0, 0x11fffeed0, 0x3ff8059c724) [0x3ff805c7ca8] 1 pthread_kill(0x1200ea6b0, 0x1, 0x0, 0x11fffeee0, 0x3ffc01b36c0) [0x3ff805ad6f4] 2 (unknown)() [0x3ff8059712c] 3 (unknown)() [0x3ff807e370c] 4 exc_unwind(0x11fffbea8, 0xabadabad00beed00, 0x3ff80592b90, 0x11fffc148, 0x3ff807e3acc) [0x3ff807e380c] 5 exc_raise_signal_exception(0x86, 0x0, 0x12015bce0, 0x1, 0x1) [0x3ff807e3ac8] 6 (unknown)() [0x3ff805af254] 7 gc_list_remove(node = 0x140472728) ["./gcmodule.c":86, 0x12015bcdc] 8 visit_reachable(op = 0x140472740, roots = 0x11fffcaa0) ["./gcmodule.c":194, 0x12015bf04] 9 list_traverse(o = 0x140447518, visit = 0x12015bed0, arg = 0x11fffcaa0) ["listobject.c":1339, 0x120151c10] 10 move_root_reachable(reachable = 0x11fffcaa0) ["./gcmodule.c":212, 0x12015bf6c] 11 collect(young = 0x140019b60, old = 0x140019b60) ["./gcmodule.c":390, 0x12015c558] 12 collect_generations() ["./gcmodule.c":466, 0x12015c76c] 13 _PyGC_Insert(op = 0x140449b98) ["./gcmodule.c":500, 0x12015c8c0] -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From esr at thyrsus.com Tue Jul 11 02:34:35 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 20:34:35 -0400 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710153314.W29590@lyra.org>; from gstein@lyra.org on Mon, Jul 10, 2000 at 03:33:14PM -0700 References: <20000710162855.A9245@thyrsus.com> <20000710153314.W29590@lyra.org> Message-ID: <20000710203435.A9793@thyrsus.com> Greg Stein : > The string.lower() at lookup time shifts the performance response, but I > don't really see config state as performance-intensive. That's my thinking as well. -- Eric S. Raymond The common argument that crime is caused by poverty is a kind of slander on the poor. -- H. L. Mencken From greg at cosc.canterbury.ac.nz Tue Jul 11 02:31:55 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Tue, 11 Jul 2000 12:31:55 +1200 (NZST) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14697.49881.701839.36716@beluga.mojam.com> Message-ID: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> Thomas> '[' [testlist [list_iter]] ']' Thomas> Should that really be 'testlist'? I can't remember my exact thinking at the time, but probably I decided that, for consistency with the rest of the language, the most general form of expression possible, without making the grammar ambiguous, should be allowed. Personally, I don't mind very much either way, but if it were changed I expect you'd get complaints that things like [x,y for x in (1,2,3) for y in (4,5,6)] didn't do what the programmer expected. Thomas> And by coincidence this is also fits very nicely with what the Thomas> 'range-literal' patch does ;-) I'm not familiar with that one, so I can't comment. Thomas> it looks like a large part was just copied from Thomas> com_for_node, and the block-stuff commented out. As Skip said, it was a proof-of-concept, and I wanted to get it working with as few changes to existing code as possible, both because I wasn't sure I understood it well enough to mess with it, and to minimise the chance of conflict with other patches. Thomas> Why is it Thomas> commented out, by the way ? Don't exceptions or something need Thomas> the block setup ? If the block-setup was kept in, it might be The block setup is used to handle breaking out of the for loop. Since it's impossible to put a 'break' inside a list constructor, the block setup is not needed -- or at least that's what I decided at the time. I don't *think* that leaving it out will upset the exception mechanism, but I'm not absolutely sure. Can anyone who knows more about how it works comment? In any case, I agree that the two for-loop compiling procedures could and should be refactored somehow. Thomas> Isn't it possible for the Thomas> patch to build the list on the stack, pushing individual Thomas> elements on the stack and calling BUILD_LIST at the end ? Unfortunately, no. The compiler needs to know the maximum amount of stack used by the procedure, and in the case of a list comprehension, the list size is not known until run time. However, things could still be improved greatly. My recommendation would be to define a new opcode such as LIST_APPEND which would take an item off the top of the stack, reach down stack items and append it to the list found there. That would get rid of the temporary variable as well. Thomas> lastly, the patch is just screaming for a re-indent all over, I sort of hoped that, with it becoming an official feature, someone would go over the code manually afterwards, rather than just applying the patch and leaving it at that. If it's deemed that "someone" should be me, let me know and I'll see what I can do. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From fdrake at beopen.com Tue Jul 11 02:47:58 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 20:47:58 -0400 (EDT) Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <20000710151641.V29590@lyra.org> References: <20000709215057.95047E2673@oratrix.oratrix.nl> <39699401.790447E8@lemburg.com> <14698.16412.396383.814694@cj42289-a.reston1.va.home.com> <20000710151641.V29590@lyra.org> Message-ID: <14698.28350.493348.220791@cj42289-a.reston1.va.home.com> Greg Stein writes: > Um. I thought the current consensus was to remove setdefaultencoding() > altogether and just stick with an ASCII default encoding. I'm most happy with this. My comment was really that it did need a comment there, even in it's temporary existence. But ripping the whole mess out is definately the best solution. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Jul 11 02:50:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 20:50:40 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <20000710151106.U29590@lyra.org> References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> <200007101926.OAA02072@cj20424-a.reston1.va.home.com> <20000710151106.U29590@lyra.org> Message-ID: <14698.28512.30573.289668@cj42289-a.reston1.va.home.com> Greg Stein writes: > $ cvs ... co python > $ mv python x > $ mv x/dist/src python > $ rm -r x Try: cvs ... co -d python python/dist/src > The extra "dist/src" in the local filesystem is just annoying :-) Agreed! I've never used that form in my work area. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr at thyrsus.com Tue Jul 11 03:10:00 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 21:10:00 -0400 Subject: [Python-Dev] Re: SourceForge In-Reply-To: <396A6F7D.66D5F085@valinux.com>; from dbressler@valinux.com on Mon, Jul 10, 2000 at 05:51:09PM -0700 References: <20000707133533.E17746@valinux.com> <20000707182448.A31259@thyrsus.com> <39667D29.1A4FB1BB@valinux.com> <20000709214138.I4566@thyrsus.com> <396A4CFC.CEE2419A@valinux.com> <20000710203719.B9793@thyrsus.com> <396A6F7D.66D5F085@valinux.com> Message-ID: <20000710211000.A10068@thyrsus.com> Dan Bressler : > I'm trying to sync schedules -- If we could set it for Tuesday evening, July > 18th, that would work best. OK. Python folks who will be at the Monterey conference; Dan Bressler, one of the managers of SourceForge, is amenable to an evening meeting with this gang on Tuesday the 18th. I gather Tim Purdue, currently the lead programmer on the project, will be there. The exact time is still to be worked out. Anybody got a proposal? -- Eric S. Raymond "I hold it, that a little rebellion, now and then, is a good thing, and as necessary in the political world as storms in the physical." -- Thomas Jefferson, Letter to James Madison, January 30, 1787 From nascheme at enme.ucalgary.ca Tue Jul 11 03:15:37 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Mon, 10 Jul 2000 19:15:37 -0600 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <396A72C6.6810C95E@stud.ntnu.no>; from Peter Schneider-Kamp on Tue, Jul 11, 2000 at 01:05:10AM +0000 References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> Message-ID: <20000710191537.A5853@keymaster.enme.ucalgary.ca> On Tue, Jul 11, 2000 at 01:05:10AM +0000, Peter Schneider-Kamp wrote: > I wouldn't bet my life on it, but I don't think the GC code is > responsible. Its hard to say. The GC code will probably pick up on a lot of problems because it touches many objects. On the other hand, it could be my bug. I'm prettly limited here as my computer is somewhere between Calgary and Reston as I type this. I will try to find the problem though. Neil From nascheme at enme.ucalgary.ca Tue Jul 11 03:28:33 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Mon, 10 Jul 2000 19:28:33 -0600 Subject: [Python-Dev] GC core dump caused by stringobject changes? Message-ID: <20000710192833.B5853@keymaster.enme.ucalgary.ca> These seem to be the changes that trigger the bug. My problem or someone elses? No time to look in detail right now. :( Neil diff -ru py-old/dist/src/Objects/stringobject.c py/dist/src/Objects/stringobject.c --- py-old/dist/src/Objects/stringobject.c Mon Jul 10 17:25:54 2000 +++ py/dist/src/Objects/stringobject.c Mon Jul 10 21:18:35 2000 @@ -744,106 +744,66 @@ int seqlen = 0; int sz = 100; int i, slen; - PyObject *seq; + PyObject *orig, *seq, *item; - if (!PyArg_ParseTuple(args, "O:join", &seq)) + if (!PyArg_ParseTuple(args, "O:join", &orig)) return NULL; - seqlen = PySequence_Length(seq); - if (seqlen < 0 && PyErr_Occurred()) + seq = PySequence_Fast(orig, ""); + if (seq == NULL) { + if (PyErr_ExceptionMatches(PyExc_TypeError)) + PyErr_Format(PyExc_TypeError, + "sequence expected, %.80s found", + orig->ob_type->tp_name); return NULL; + } + seqlen = PySequence_Length(seq); if (seqlen == 1) { - /* Optimization if there's only one item */ - PyObject *item = PySequence_GetItem(seq, 0); - if (item == NULL) - return NULL; - if (!PyString_Check(item) && - !PyUnicode_Check(item)) { - PyErr_SetString(PyExc_TypeError, - "first argument must be sequence of strings"); - Py_DECREF(item); - return NULL; - } + item = PySequence_Fast_GET_ITEM(seq, 0); + Py_INCREF(item); return item; } + if (!(res = PyString_FromStringAndSize((char*)NULL, sz))) return NULL; p = PyString_AsString(res); - /* optimize for lists. all others (tuples and arbitrary sequences) - * just use the abstract interface. - */ - if (PyList_Check(seq)) { - for (i = 0; i < seqlen; i++) { - PyObject *item = PyList_GET_ITEM(seq, i); - if (!PyString_Check(item)){ - if (PyUnicode_Check(item)) { - Py_DECREF(res); - return PyUnicode_Join( - (PyObject *)self, - seq); - } - PyErr_Format(PyExc_TypeError, - "sequence item %i not a string", - i); - goto finally; - } - slen = PyString_GET_SIZE(item); - while (reslen + slen + seplen >= sz) { - if (_PyString_Resize(&res, sz*2)) - goto finally; - sz *= 2; - p = PyString_AsString(res) + reslen; - } - if (i > 0) { - memcpy(p, sep, seplen); - p += seplen; - reslen += seplen; + for (i = 0; i < seqlen; i++) { + item = PySequence_Fast_GET_ITEM(seq, i); + if (!PyString_Check(item)){ + if (PyUnicode_Check(item)) { + Py_DECREF(res); + Py_DECREF(item); + return PyUnicode_Join((PyObject *)self, + seq); } - memcpy(p, PyString_AS_STRING(item), slen); - p += slen; - reslen += slen; + PyErr_Format(PyExc_TypeError, + "sequence item %i: expected string, %.80s found", + i, item->ob_type->tp_name); + Py_DECREF(item); + Py_DECREF(seq); + goto finally; } - } - else { - for (i = 0; i < seqlen; i++) { - PyObject *item = PySequence_GetItem(seq, i); - if (!item) - goto finally; - if (!PyString_Check(item)){ - if (PyUnicode_Check(item)) { - Py_DECREF(res); - Py_DECREF(item); - return PyUnicode_Join( - (PyObject *)self, - seq); - } + slen = PyString_GET_SIZE(item); + while (reslen + slen + seplen >= sz) { + if (_PyString_Resize(&res, sz*2)) { Py_DECREF(item); - PyErr_Format(PyExc_TypeError, - "sequence item %i not a string", - i); + Py_DECREF(seq); goto finally; } - slen = PyString_GET_SIZE(item); - while (reslen + slen + seplen >= sz) { - if (_PyString_Resize(&res, sz*2)) { - Py_DECREF(item); - goto finally; - } - sz *= 2; - p = PyString_AsString(res) + reslen; - } - if (i > 0) { - memcpy(p, sep, seplen); - p += seplen; - reslen += seplen; - } - memcpy(p, PyString_AS_STRING(item), slen); - Py_DECREF(item); - p += slen; - reslen += slen; + sz *= 2; + p = PyString_AsString(res) + reslen; + } + if (i > 0) { + memcpy(p, sep, seplen); + p += seplen; + reslen += seplen; } + memcpy(p, PyString_AS_STRING(item), slen); + Py_DECREF(item); + p += slen; + reslen += slen; } if (_PyString_Resize(&res, reslen)) goto finally; From tim_one at email.msn.com Tue Jul 11 03:47:12 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 21:47:12 -0400 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <20000710191537.A5853@keymaster.enme.ucalgary.ca> Message-ID: [Peter Schneider-Kamp] > I wouldn't bet my life on it, but I don't think the GC code is > responsible. [Neil Schemenauer] > Its hard to say. I'll second that . > The GC code will probably pick up on a lot of problems because it touches > many objects. On the other hand, it could be my bug. I'm prettly > limited here as my computer is somewhere between Calgary and > Reston as I type this. I will try to find the problem though. I also doubt it's gc's fault: the recent patches to the gc code were absolutely vanilla, this all worked fine (at least for me) yesterday, and it's failing for multiple people on multiple platforms today. (BTW, Barry, your core.py does not fail under my Windows build.) I haven't had more time tonight to look at it, though, and won't tomorrow either. "Somehow or other" the list of objects it's crawling over is totally hosed (length 3, first one is a legit string object, last two seemingly random trash). If I remembered how to do this with CVS, I'd just do a mindless binary search over the last day's patches, rebuilding until the problem goes away ... OK, if back out *only* Jeremy's patch to stringobject.c: http://www.python.org/pipermail/python-checkins/2000-July/006424.html all my Windows gc failures go away. I picked on that patch because it's the only non-trivial patch that's gone in recently to a popular part of the code. Jeremy, want to double-check your refcounts ? suggestive-but-not-yet-proven-ly y'rs - tim From tim_one at email.msn.com Tue Jul 11 04:00:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 22:00:47 -0400 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <20000710191537.A5853@keymaster.enme.ucalgary.ca> Message-ID: [Peter Schneider-Kamp] > I wouldn't bet my life on it, but I don't think the GC code is > responsible. [Neil Schemenauer] > Its hard to say. I'll second that . > The GC code will probably pick up on a lot of problems because it touches > many objects. On the other hand, it could be my bug. I'm prettly > limited here as my computer is somewhere between Calgary and > Reston as I type this. I will try to find the problem though. I also doubt it's gc's fault: the recent patches to the gc code were absolutely vanilla, this all worked fine (at least for me) yesterday, and it's failing for multiple people on multiple platforms today. (BTW, Barry, your core.py does not fail under my Windows build.) I haven't had more time tonight to look at it, though, and won't tomorrow either. "Somehow or other" the list of objects it's crawling over is totally hosed (length 3, first one is a legit string object, last two seemingly random trash). If I remembered how to do this with CVS, I'd just do a mindless binary search over the last day's patches, rebuilding until the problem goes away ... OK, if I back out *only* Jeremy's very recent patch to stringobject.c: http://www.python.org/pipermail/python-checkins/2000-July/006424.html all my Windows gc failures go away. I picked on that patch because it's the only non-trivial patch that's gone in recently to a popular part of the code. Jeremy, want to double-check your refcounts ? suggestive-but-not-yet-proven-ly y'rs - tim From akuchlin at cnri.reston.va.us Tue Jul 11 04:34:04 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Mon, 10 Jul 2000 22:34:04 -0400 Subject: [Python-Dev] GC core dump caused by stringobject changes? In-Reply-To: <20000710192833.B5853@keymaster.enme.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Mon, Jul 10, 2000 at 07:28:33PM -0600 References: <20000710192833.B5853@keymaster.enme.ucalgary.ca> Message-ID: <20000710223404.A3195@newcnri.cnri.reston.va.us> On Mon, Jul 10, 2000 at 07:28:33PM -0600, Neil Schemenauer wrote: >These seem to be the changes that trigger the bug. My problem or >someone elses? No time to look in detail right now. :( >+ seq = PySequence_Fast(orig, ""); ... >+ item = PySequence_Fast_GET_ITEM(seq, i); ... >+ Py_DECREF(item); I think item shouldn't be DECREF'ed at all. Looking at what PySequence_Fast does, it either INCREF's its argument if it's a list or tuple and returns it, or coerces it to a tuple. It doesn't look like PySequence_Fast increments the refcount of what it returns. seq does need to be DECREF'ed, though: >>> import sys >>> L=['a', 'b', 'c'] >>> sys.getrefcount(L) 2 >>> for i in range(1000): a = ' '.join(L) ... >>> sys.getrefcount(L) 1002 >>> --amk From jeremy at beopen.com Tue Jul 11 05:19:32 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 23:19:32 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <20000710191537.A5853@keymaster.enme.ucalgary.ca> References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> Message-ID: <14698.37444.952060.876122@bitdiddle.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> On Tue, Jul 11, 2000 at 01:05:10AM +0000, Peter Schneider-Kamp NS> wrote: >> I wouldn't bet my life on it, but I don't think the GC code is >> responsible. NS> Its hard to say. The GC code will probably pick up on a lot of NS> problems because it touches many objects. On the other hand, it NS> could be my bug. My first guess would be something other than the GC. When I was working on the string_join fix this afternoon, a couple of my interim versions had refcount problems that lead to core dumps in the garbage collector. The GC catches lots of memory problems because it's touching all the objects; that doesn't mean its to blame for all those problems. Which leads me to ask, Barry, did you run purify on an interpreter with the latest stringobject.c? Jeremy From tim_one at email.msn.com Tue Jul 11 05:25:15 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 23:25:15 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <027801bfeab6$aa6115e0$f2a6b5d4@hagrid> Message-ID: [/F, on ViewCVS's virtues] > it works with MSIE5, for a start. > > and it's written by greg, in python. that's all I need to know ;-) > > the IE problem could be a configuration problem, of course. unless > tim beats me to it, I'll submit a support request some day... And I will unless you beat me to it . In the meantime, I downloaded stinking Netscape last night. Works fine. IE5 was having major problems displaying the SF Member Options page too (large table). And SF ftp access froze. And the new thing with displaying the CVS repository. They all work OK under NS. Surprised me, as my previous experiences with NS were a bloody nightmare of crashes and corruption! BTW, I'm certain I didn't do anything to change my IE5 config (& the SF CVS access worked fine on Friday). From jeremy at beopen.com Tue Jul 11 05:31:33 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 23:31:33 -0400 (EDT) Subject: [Python-Dev] GC core dump caused by stringobject changes? In-Reply-To: <20000710223404.A3195@newcnri.cnri.reston.va.us> References: <20000710192833.B5853@keymaster.enme.ucalgary.ca> <20000710223404.A3195@newcnri.cnri.reston.va.us> Message-ID: <14698.38165.629676.33065@bitdiddle.concentric.net> Right on both counts and now fixed! Jeremy From ping at lfw.org Mon Jul 10 11:23:55 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 10 Jul 2000 02:23:55 -0700 (PDT) Subject: [Python-Dev] String coercion In-Reply-To: <39672D53.899D4BEB@prescod.net> Message-ID: On Sat, 8 Jul 2000, Paul Prescod wrote: > Ping says: > > As it stands, with both 8-bit strings and Unicode strings, i think > > this would result in too much hidden complexity -- thinking about this > > can wait until we have only one string type. > > I don't see any hidden complexity. Python has features specifically > designed to allow this sort of thing on a per-type basis. Well... what happens when the other operand is a Unicode string? Do you also do automatic coercion when adding something to a Unicode string? When you add one to an arbitrary object, how do you convert the other object into a Unicode string? When you add an 8-bit string and Unicode together, what do you get? It's not that i don't think you might be able to come up with consistent rules. I just suspect that when you do, it might amount to more hidden stuff than i'm comfortable with. Of course you could also just use Itpl.py :) or a built-in version of same (Am i half-serious? Half-kidding? Well, let's just throw it out there...). Instead of: print PaulsString("abcdef")+5 print open+PaulsString("ghijkl") with Itpl.py it would just be: printpl("abcdef${5}") printpl("${open}ghijkl") A built-in Itpl-like operator might almost be justifiable, actually... i mean, we already have "%(open)sghijkl" % globals() Well, i don't know. Perhaps it looks too frighteningly like Perl. Anyway, the rules as implemented (see http://www.lfw.org/python/ for the actual Itpl.py module) are: 1. $$ becomes $ 2. ${ } around any expression evaluates the expression 3. $ followed by identifier, followed by zero or more of: a. .identifier b. [identifier] c. (identifier) evaluates the expression What i'm getting at with this approach is that you are clear from the start that the goal is a string: you have this string thing, and you're going to insert some stringified expressions and objects into it. I think it's clearer & less error-prone for interpolation to be its own operation, rather than overloading +. It also means you could start with a Unicode string with $s in it, and you would be assured of ending up with a Unicode string, for example. -- ?!ng From bwarsaw at beopen.com Tue Jul 11 06:07:54 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 00:07:54 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> <14698.37444.952060.876122@bitdiddle.concentric.net> Message-ID: <14698.40346.841864.110547@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> Which leads me to ask, Barry, did you run purify on an JH> interpreter with the latest stringobject.c? Yes. And I did get other memory errors before the core, which I should have looked at more carefully. Looks like that might have been it. My fault for encouraging you to check your changes in without looking at them, and then I had to disappear for a few hours. I've got them now and am looking at the code (I see a missing decref, but that should only leak memory). Will Purify shortly. -Barry From moshez at math.huji.ac.il Tue Jul 11 06:36:11 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 11 Jul 2000 07:36:11 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101500.IAA13372@slayer.i.sourceforge.net> Message-ID: On Mon, 10 Jul 2000, Eric S. Raymond wrote: > Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv11503/dist/src/Lib > > Modified Files: > urllib.py > Log Message: > Moves some test code into the scope of if __name__ == '__main__', where it > won't get loaded when we're using the classes in this module. Why? It's only parsed once (under usual conditions) per installation, it's cost in memory is not so high, and it's cool to be able to test via ''' import urllib urllib.main() ''' -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From bwarsaw at beopen.com Tue Jul 11 06:56:54 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 00:56:54 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> <14698.37444.952060.876122@bitdiddle.concentric.net> Message-ID: <14698.43286.502470.136885@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: >>>>> "NS" == Neil Schemenauer writes: NS> Its hard to say. The GC code will probably pick up on a lot NS> of problems because it touches many objects. On the other NS> hand, it could be my bug. It also appears to mask many problems. I just compiled out the gcmodule (which is sadly undocumented, I believe) and I've just gotten a number of new memory leaks. This is basically running a very simple Python script: -------------------- snip snip -------------------- '-'.join(('one',)) '-'.join((u'one',)) -------------------- snip snip -------------------- Will investigate further, but at first blush, they might be real cycles created in the exception initialization code. But anyway... JH> Which leads me to ask, Barry, did you run purify on an JH> interpreter with the latest stringobject.c? ...I'd actually expect the above script to leak *seq twice in the current CVS string_join(). It doesn't, but then neither does including the missing decrefs cause the objects to be decref'd extra times. Interesting. Still I think string_join() needs to be patched in two places to decref *seq (first, in the seqlen==1 clause, and later just before the return PyUnicode_Join()). I'll check in a patch, but would appreciate a proofread. -Barry From fdrake at beopen.com Tue Jul 11 07:52:33 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 01:52:33 -0400 (EDT) Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: References: <027801bfeab6$aa6115e0$f2a6b5d4@hagrid> Message-ID: <14698.46625.240075.125009@cj42289-a.reston1.va.home.com> Tim Peters writes: > OK under NS. Surprised me, as my previous experiences with NS were a bloody > nightmare of crashes and corruption! BTW, I'm certain I didn't do anything > to change my IE5 config (& the SF CVS access worked fine on Friday). You have to realize that they probably test with Netscape, but rarely if ever with IE. That's a function of audience. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From moshez at math.huji.ac.il Tue Jul 11 07:55:13 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 11 Jul 2000 08:55:13 +0300 (IDT) Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162855.A9245@thyrsus.com> Message-ID: On Mon, 10 Jul 2000, Eric S. Raymond wrote: > First, for completeness there ought to be remove_section and remove_option > methods (though forgetool does not yet use them). I have documented these > as follows: > > \begin{methoddesc}{remove_option}{section, option} > Remove the specified \var{option} from the specified \var{section}. > If the section does not exist, raise \exception{NoSectionError}. > If the option existed to be removed, return 1; otherwise return 0. Ummm..encoding success/failure as return values is not usually a good idea. Why not raise KeyError if there is no such option in the section? > \begin{methoddesc}{remove_section}{section} > Remove the specified \var{section} from the configuration. > If the section in fact existed, return 1. Otherwise return 0. Ditto. Raise a NoSectionError. IF someone wants to ignore the error, they can either check if it exists, or trap the error. > Does anybody have a problem with these changes? I'm +0 -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From fdrake at beopen.com Tue Jul 11 07:58:02 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 01:58:02 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <14698.43286.502470.136885@anthem.concentric.net> References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> <14698.37444.952060.876122@bitdiddle.concentric.net> <14698.43286.502470.136885@anthem.concentric.net> Message-ID: <14698.46954.479303.841718@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > It also appears to mask many problems. I just compiled out the > gcmodule (which is sadly undocumented, I believe) and I've just gotten Neil, Can you provide something for this module? Plain text is fine if you prefer; I can add the LaTeX markup. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pf at artcom-gmbh.de Tue Jul 11 09:12:29 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 11 Jul 2000 09:12:29 +0200 (MEST) Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162855.A9245@thyrsus.com> from "Eric S. Raymond" at "Jul 10, 2000 4:28:55 pm" Message-ID: Hi, Eric S. Raymond: > Earlier today, I committed a patch to ConfigParser that adds three new > methods to the class. Here is the documentation: [...] Applying the well known dictionary API to config info can help to to avoid reinventing a new API to deal with configuration info. What I would love to see, is a class 'ConfigDict' derived from 'UserDict.UserDict', which contains the section-names as keys and section-objects as values, where section-objects are also dictionaries containing the option-names as keys. The new class 'ConfigDict' should then provide a 'read()' or 'parse()' method (or take an optional filename as constructor argument) and would also provide 'write' and/or 'save' method(s). Hypothecical examples of use: rcfilename = os.path.join(os.environ.get("HOME", "."), ".myFoorc") cnf = ConfigParser.ConfigDict(rcfilename) # or alternatively: cnf = ConfigParser.ConfigDict() cnf.read(open(rcfilename, "r")) # ... accessing the configuration if cnf.has_key("FONT_SETTINGS"): try: size = int(cnf["FONT_SETTINGS"]["size"]) except KeyError: size = 10 # ... adding a section: cnf["new_section"] = {} # ... adding an option to the default section: cnf["screensize"] = "%dx%d" % (width, height) # ... cnf["FONT_SETTINGS"]["size"] = 10 # removing an option: del cnf["FONT_SETTINGS"]["fontname"] # removing a section or an option from the default section: del cnf["old_section"] del cnf["foo_bar"] # ... cnf.save() # only if instantiated using a filename argument # or alternatively: cnf.write(open(".myrc", "w")) [...] > To do these things, forgetool needs to maintain some local state that is > conveniently represented in the format of a Windows .ini file. More, > it needs to be able to *update* .ini files as well as parse them. This is a very common need. I agree, that this functionality should be provided by the standard library. Recently we had some discussion about a 'userpref' module, which should fill another related gap: provide a portable way to determine the rcfilename. a dot-rc file is the unix way to store this kind of information, on Windows a application specific ini file probaly belongs into another local directory (there is no $HOME) and on the Mac it probably belongs into a preferences folder ... still a lot of work to do. :-( Regards, Peter From gstein at lyra.org Tue Jul 11 11:08:18 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 02:08:18 -0700 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 11, 2000 at 08:55:13AM +0300 References: <20000710162855.A9245@thyrsus.com> Message-ID: <20000711020817.V29590@lyra.org> On Tue, Jul 11, 2000 at 08:55:13AM +0300, Moshe Zadka wrote: > On Mon, 10 Jul 2000, Eric S. Raymond wrote: > > First, for completeness there ought to be remove_section and remove_option > > methods (though forgetool does not yet use them). I have documented these > > as follows: > > > > \begin{methoddesc}{remove_option}{section, option} > > Remove the specified \var{option} from the specified \var{section}. > > If the section does not exist, raise \exception{NoSectionError}. > > If the option existed to be removed, return 1; otherwise return 0. > > Ummm..encoding success/failure as return values is not usually a good > idea. Why not raise KeyError if there is no such option in the section? Eric is defining it as "okay" to remove a non-existent option. If you want to know whether it was there, then check the return code. In most cases, you just want to say "just make sure it isn't there any more." IOW, I much prefer Eric's behavior spec over something that will generate an exception. > > \begin{methoddesc}{remove_section}{section} > > Remove the specified \var{section} from the configuration. > > If the section in fact existed, return 1. Otherwise return 0. > > Ditto. Raise a NoSectionError. IF someone wants to ignore the error, they > can either check if it exists, or trap the error. Same as above. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jul 11 11:10:09 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 02:10:09 -0700 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: ; from pf@artcom-gmbh.de on Tue, Jul 11, 2000 at 09:12:29AM +0200 References: <20000710162855.A9245@thyrsus.com> Message-ID: <20000711021008.W29590@lyra.org> On Tue, Jul 11, 2000 at 09:12:29AM +0200, Peter Funk wrote: > Hi, > > Eric S. Raymond: > > Earlier today, I committed a patch to ConfigParser that adds three new > > methods to the class. Here is the documentation: > [...] > Applying the well known dictionary API to config info can help to > to avoid reinventing a new API to deal with configuration info. > > What I would love to see, is a class 'ConfigDict' derived from > 'UserDict.UserDict', which contains the section-names as keys and > section-objects as values, where section-objects are also dictionaries > containing the option-names as keys. Then go ahead and code it. I guarantee that you'll have your wish if you code it. Otherwise, I'll lay very low odds on all the new module suggestions in your email. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Tue Jul 11 11:32:44 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 11 Jul 2000 11:32:44 +0200 (CEST) Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length In-Reply-To: <025001bfeab4$f07251e0$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 10, 2000 11:22:22 PM Message-ID: <200007110932.LAA14002@python.inrialpes.fr> Fredrik Lundh wrote: > > jeremy wrote: > > > Tuple, List, String, and Dict have a PyXXX_Size method. The abstract > > object interface uses PySequence_Length. This is inconsistent and > > hard to remember. Can we add PySequence_Size and mark Length as > > deprecated? > > don't forget PyObject_Length and PyMapping_Length... Why deprecate? There's nothing wrong with these names. However, for conveniency, it would make sense to have PyXXX_Size macros, synonyms for the PyXXX_Length functions. Or vice versa. Have _Length macros, synonyms for _Size functions. However, this is not backwards (binary) compatible, which I believe is harmless for a new release, but the recent Windows DLL thread reminds that bin compatibility accross versions is somewhat important. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Tue Jul 11 12:10:36 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 03:10:36 -0700 Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length In-Reply-To: <200007110932.LAA14002@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Tue, Jul 11, 2000 at 11:32:44AM +0200 References: <025001bfeab4$f07251e0$f2a6b5d4@hagrid> <200007110932.LAA14002@python.inrialpes.fr> Message-ID: <20000711031036.E29590@lyra.org> On Tue, Jul 11, 2000 at 11:32:44AM +0200, Vladimir Marangozov wrote: > Fredrik Lundh wrote: > > > > jeremy wrote: > > > > > Tuple, List, String, and Dict have a PyXXX_Size method. The abstract > > > object interface uses PySequence_Length. This is inconsistent and > > > hard to remember. Can we add PySequence_Size and mark Length as > > > deprecated? > > > > don't forget PyObject_Length and PyMapping_Length... > > Why deprecate? There's nothing wrong with these names. > However, for conveniency, it would make sense to have > PyXXX_Size macros, synonyms for the PyXXX_Length functions. Because having both names is even worse than having inconsistent names. The question will always arise "what is the difference? why should I use one over the other?" You can tell people they are the same until you're blue in the face -- the question will still come up. Maybe after a while, the question won't come up any more. But then you have to answer, "okay. so they're exactly the same. why have two of them, then?" :-) > Or vice versa. Have _Length macros, synonyms for _Size functions. > However, this is not backwards (binary) compatible, which I > believe is harmless for a new release, but the recent Windows > DLL thread reminds that bin compatibility accross versions > is somewhat important. Binary compatibility in Open Source software is a pipe dream. There is absolutely no sense in trying to worry about it, and even more sense to explicitly bail out with "that doesn't work." Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jul 11 12:35:34 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 03:35:34 -0700 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: ; from pf@artcom-gmbh.de on Tue, Jul 11, 2000 at 12:10:41PM +0200 References: <20000711021008.W29590@lyra.org> Message-ID: <20000711033534.K29590@lyra.org> On Tue, Jul 11, 2000 at 12:10:41PM +0200, Peter Funk wrote: > Greg Stein : > > On Tue, Jul 11, 2000 at 09:12:29AM +0200, Peter Funk wrote: > > > Hi, > > > > > > Eric S. Raymond: > > > > Earlier today, I committed a patch to ConfigParser that adds three new > > > > methods to the class. Here is the documentation: > > > [...] > > > Applying the well known dictionary API to config info can help to > > > to avoid reinventing a new API to deal with configuration info. > > > > > > What I would love to see, is a class 'ConfigDict' derived from > > > 'UserDict.UserDict', which contains the section-names as keys and > > > section-objects as values, where section-objects are also dictionaries > > > containing the option-names as keys. > > > > Then go ahead and code it. I guarantee that you'll have your wish if you > > code it. Otherwise, I'll lay very low odds on all the new module suggestions > > in your email. > > Okay: I just had a look into the implementation of ConfigParser and > stumbled over the '%(foo)' macro expansion features. If I go ahead and > implement these within (below) my ConfigDict.__getitem__ method, this > will lead to the problem, that > cnf['some_section']['foo'] = 'feeble' > cnf['some_section']['bar'] = 'baz' > cnf['some_section']['some_option'] = '%(foo)/paf/%(bar)' > print cnf['some_section']['some_option'] > might surprise users with the dictionary model in their head. > They might expect this to print '%(foo)/paf/%(bar)' instead of > 'feeble/paf/baz'. > > Any suggestions? It is a configuration dictionary. Users can simply deal with it :-) I'm not sure it is a big problem to worry about. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Tue Jul 11 14:41:18 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 11 Jul 2000 14:41:18 +0200 (CEST) Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length In-Reply-To: <20000711031036.E29590@lyra.org> from "Greg Stein" at Jul 11, 2000 03:10:36 AM Message-ID: <200007111241.OAA21491@python.inrialpes.fr> Greg Stein wrote: > > > Why deprecate? There's nothing wrong with these names. > > However, for conveniency, it would make sense to have > > PyXXX_Size macros, synonyms for the PyXXX_Length functions. > > Because having both names is even worse than having inconsistent names. The > question will always arise "what is the difference? why should I use one > over the other?" You can tell people they are the same until you're blue in > the face -- the question will still come up. Maybe after a while, the > question won't come up any more. But then you have to answer, "okay. so > they're exactly the same. why have two of them, then?" :-) Okay, then deprecate them if there are no other objections. But binary compatibility aside, if we don't provide _Length macros, this would break tons of legacy source code, so both must be there for some (long) time. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gward at mems-exchange.org Tue Jul 11 14:39:44 2000 From: gward at mems-exchange.org (Greg Ward) Date: Tue, 11 Jul 2000 08:39:44 -0400 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <200007101725.MAA01255@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 12:25:12PM -0500 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> Message-ID: <20000711083943.A27423@ludwig.cnri.reston.va.us> On 10 July 2000, Guido van Rossum said: > Makefile includes are notoriously unportable, aren't they? The > embed/Makefile is a lame excuse for a Makefile -- it has XXX comments > all over the place telling you to edit things to match the Python main > Makefile... :-( My fault -- feel free to fix! I think the mere existence of an "include" directive is pretty well-established. What's not portable, in my experience, is relying in neat-o semantics supplied by GNU make and (maybe? can't remember) SGI's decent make (smake I think? plain make under IRIX 4 and 5 was hopelessly brain-damaged). Specifically, GNU make will treat a missing include file not as an error, but something that should be rebuilt using the usual dependency rules. Apparently this is useful for including header dependency info in the Makefile, but of course it ties you right to GNU make. If you believe the "Recursive Make Considered Harmful" paper, it's probably better to rely on the ability to include Makefile fragments than to invoke make recursively. (It sound plausible to me, but I haven't tried out the ideas from that paper seriously yet.) Greg From guido at beopen.com Tue Jul 11 15:48:15 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 08:48:15 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 14:16:38 MST." <20000710141638.R29590@lyra.org> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> <20000710141638.R29590@lyra.org> Message-ID: <200007111348.IAA04699@cj20424-a.reston1.va.home.com> > We're using includes in the Apache 2.0 makefiles. I'm not sure whether this > is going to make Apache 2.0 less portable or not. There haven't been any > issues yet, though. > > (I think the makefile organization came from PHP; assuming that is as > portable as Apache 1.3, then makefile includes are pretty darn portable) > > IMO, I say "start using makefile includes" and see who screams. VPATH is not > portable, though. The difference is that Apache and PHP only need to be portable to server-class machines. Python also runs on (1) very ancient hardware; (2) some Cray-class machines; (3) non-Unix hardware with enough Unix emulation to be able to run the configure script (I believe the BeOS port falls in this category, and of course cygwin). Call me conservative, --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Tue Jul 11 14:59:44 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 08:59:44 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <14698.40346.841864.110547@anthem.concentric.net> References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> <14698.37444.952060.876122@bitdiddle.concentric.net> <14698.40346.841864.110547@anthem.concentric.net> Message-ID: <14699.6720.758571.615919@bitdiddle.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "JH" == Jeremy Hylton writes: JH> Which leads me to ask, Barry, did you run purify on an BAW> Looks like that might have been it. My fault for encouraging BAW> you to check your changes in without looking at them, and then BAW> I had to disappear for a few hours. I was in a rush, too. I should have waited until after my softball game. Jeremy From esr at thyrsus.com Tue Jul 11 15:08:17 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 11 Jul 2000 09:08:17 -0400 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <200007111348.IAA04699@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 08:48:15AM -0500 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> <20000710141638.R29590@lyra.org> <200007111348.IAA04699@cj20424-a.reston1.va.home.com> Message-ID: <20000711090817.A11533@thyrsus.com> Guido van Rossum : > > IMO, I say "start using makefile includes" and see who screams. VPATH is > > not portable, though. > > [No,] Call me conservative, I'm -1 on this also. I've had too many bad experiences dealing with variance in the semantics of inclusion. -- Eric S. Raymond What is a magician but a practicing theorist? -- Obi-Wan Kenobi, 'Return of the Jedi' From thomas at xs4all.net Tue Jul 11 15:17:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 15:17:41 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <200007111348.IAA04699@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 08:48:15AM -0500 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> <20000710141638.R29590@lyra.org> <200007111348.IAA04699@cj20424-a.reston1.va.home.com> Message-ID: <20000711151740.T26534@xs4all.nl> On Tue, Jul 11, 2000 at 08:48:15AM -0500, Guido van Rossum wrote: > > IMO, I say "start using makefile includes" and see who screams. VPATH is not > > portable, though. > The difference is that Apache and PHP only need to be portable to > server-class machines. Python also runs on (1) very ancient hardware; > (2) some Cray-class machines; (3) non-Unix hardware with enough Unix > emulation to be able to run the configure script (I believe the BeOS > port falls in this category, and of course cygwin). Actually, I was referring to the trick PIL and other extension modules use to build their own Makefile based on Python's. I'm not sure how portable that particular Makefile is, however. I'm one of those types that use 'gmake' on systems that do not have GNU make as the default make ;-) And forgive me for saying this, but I think providing a good, self-configuring but slightly unportable Makefile.pre.in *and* a README (and/or example) that shows how to do it by hand on old/incapacitated systems, is preferable over just providing a completely unportable Makefile and a README that shows how to do it on other systems :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Tue Jul 11 16:40:32 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 09:40:32 -0500 Subject: [Python-Dev] list comprehensions again... In-Reply-To: Your message of "Tue, 11 Jul 2000 12:31:55 +1200." <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> Message-ID: <200007111440.JAA05205@cj20424-a.reston1.va.home.com> > [x,y for x in (1,2,3) for y in (4,5,6)] Hm, I suppose the programmer meant the same as [(x,y) for x in (1,2,3) for y in (4,5,6)] Would it be really bad if we forced them to write it that way? Side note: the suggested syntax here (for i in seq1 for j in seq2) looks like a potential alternative for the currently proposed parallel for loop syntax (for i in seq1; j in seq2). Only problem: the for-for variant could be mistaken by someone used to see nested loops as meaning the same as for i in seq1: for j in seq2: ... Undecided and unhelpful, --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From akuchlin at mems-exchange.org Tue Jul 11 15:54:43 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 11 Jul 2000 09:54:43 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: ; from pingster@ilm.com on Thu, Jul 06, 2000 at 02:16:07PM -0700 References: <20000706171159.A25398@kronos.cnri.reston.va.us> Message-ID: <20000711095443.D27228@kronos.cnri.reston.va.us> On Thu, Jul 06, 2000 at 02:16:07PM -0700, Ka-Ping Yee quoted me: >> I'd suggest adding poll() to 2.0, and will submit a patch if given the >> go-ahead. But where should it go? A whole module for it seems >> excessive; should it go in posixmodule, or maybe select? I've completed a patch, SF#100852, to add os.poll() based on Sam Rushing's code with various modifications; I'd like a reviewer to look it over, after which I'll check it in. http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 I'm not happy with the interface -- you pass in a list of (file descriptor, event mask) 2-tuples -- but it seems the only way to expose all of poll()'s functionality. I thought about allowing a lone file descriptor as well as a tuple, in which you'd assume an event mask of POLLIN | POLLPRI | POLLOUT (all the common events), but it seemed like too much magic. Also, is there a C utility function to handle the "pass an integer or an object with a fileno() method" protocol for me? Should there be one? --amk From guido at beopen.com Tue Jul 11 16:58:46 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 09:58:46 -0500 Subject: [Python-Dev] Re: SourceForge In-Reply-To: Your message of "Mon, 10 Jul 2000 21:10:00 -0400." <20000710211000.A10068@thyrsus.com> References: <20000707133533.E17746@valinux.com> <20000707182448.A31259@thyrsus.com> <39667D29.1A4FB1BB@valinux.com> <20000709214138.I4566@thyrsus.com> <396A4CFC.CEE2419A@valinux.com> <20000710203719.B9793@thyrsus.com> <396A6F7D.66D5F085@valinux.com> <20000710211000.A10068@thyrsus.com> Message-ID: <200007111458.JAA05267@cj20424-a.reston1.va.home.com> > Dan Bressler : > > I'm trying to sync schedules -- If we could set it for Tuesday evening, July > > 18th, that would work best. > > OK. Python folks who will be at the Monterey conference; Dan > Bressler, one of the managers of SourceForge, is amenable to an > evening meeting with this gang on Tuesday the 18th. I gather Tim > Purdue, currently the lead programmer on the project, will be there. > > The exact time is still to be worked out. Anybody got a proposal? I'm not sure what time we'll be arriving in Monterey -- we have our plane tickets to San Jose and I know we're going to spend Tuesday daytime at the BeOpen headquarters in Santa Clara, but I don't know yet what mode of transportation we're going to take to Monterey and at what time. Given that Dan prefers Tuesday evening I'll try to press for leaving early enough so that there's some evening left! Looking forward to this meeting, --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Tue Jul 11 16:04:06 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 16:04:06 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111440.JAA05205@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 09:40:32AM -0500 References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> <200007111440.JAA05205@cj20424-a.reston1.va.home.com> Message-ID: <20000711160406.D25805@xs4all.nl> On Tue, Jul 11, 2000 at 09:40:32AM -0500, Guido van Rossum wrote: > > [x,y for x in (1,2,3) for y in (4,5,6)] > Hm, I suppose the programmer meant the same as > > [(x,y) for x in (1,2,3) for y in (4,5,6)] > Would it be really bad if we forced them to write it that way? Actually, the change in Grammar wouldn't enforce that. (At least, I think not.) Because the 'for' splits and disambiguates before the ',' in the first tuple, the parser will always see it as such, and it's probably pretty hard to convince the parser not to :-) Because of the way 'testlist' and 'test' are defined, it's easy to use them interchangeably. I think, anyway. I'm still new at this parsing thing :-) But the Gramar uses 'testlist' to mean the contents of the list itself, so it seems logical to me that this should be the case wether or not 'testlist' is followed by 'list_iter' -- currently, the presense of list_iter changes (the interpretation of) it from the contents of a list to a tuple. Like I said, it was nit-picky ;) > Side note: the suggested syntax here (for i in seq1 for j in seq2) > looks like a potential alternative for the currently proposed parallel > for loop syntax (for i in seq1; j in seq2). > Only problem: the for-for variant could be mistaken by someone used to > see nested loops as meaning the same as > > for i in seq1: > for j in seq2: ... I personally prefer 'for i in seq1; j in seq2' because it's a lot less ambiguous. More importantly, however, the meaning in the cited list-comprehension example is different ! [x,y for x in (1,2,3) for y in (4,5,6)] is actually turned into a pair of nested loops: tmp = [] for x in (1,2,3): for y in (4,5,6): tmp.append(x,y) (Quite literally so, in fact ;) So it's *not* the same as the parallel-loop-for: tmp = [] for x in (1,2,3); y in (4,5,6): tmp.append(x,y) For that reason alone, I'd go for the 2nd syntax ;) Unless, of course, you have a proposed new syntax for the nested-for-loop in list comprehensions :-) > Undecided and unhelpful, Helpfully deciding-ly'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From petersc at stud.ntnu.no Tue Jul 11 18:16:16 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Tue, 11 Jul 2000 16:16:16 +0000 Subject: merging my*.h into pyport.h (was: Re: [Python-Dev] Py_PROTO elimination in Include/) References: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com> Message-ID: <396B4850.A3D1A1A2@stud.ntnu.no> "Fred L. Drake, Jr." wrote: > > I've removed Py_PROTO from the headers in the Include/ directory, > with the exceptions of the my*.h headers. I'll leave it for others to > fix those, merging with pyport.h as appropriate. What do you think would be appropriate? I have been toying around with the my*.h headers a bit and loaded up a "proof of concept" patch that makes all my*.h obsolete. concerns with the patch: - messing around with a lot if non-linux #ifdef sections (can somebody have a look at that?) - possibly including unneeded headers (is that a problem?) - undocumented (I can take care of that when the time comes) hoping-for-feedback-ly y'rs Peter P.S.: What's the status of sre? I just ask because test_re keeps nagging all the time. :-] -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From petersc at stud.ntnu.no Tue Jul 11 18:19:40 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Tue, 11 Jul 2000 16:19:40 +0000 Subject: merging my*.h into pyport.h (was: Re: [Python-Dev] Py_PROTO elimination in Include/) References: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com> <396B4850.A3D1A1A2@stud.ntnu.no> Message-ID: <396B491C.C3ABFFE2@stud.ntnu.no> Peter Schneider-Kamp wrote: > > - messing around with a lot if non-linux #ifdef sections make that: a lot of non-linux #ifdef sections sorry, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From guido at beopen.com Tue Jul 11 17:23:45 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 10:23:45 -0500 Subject: [Python-Dev] Python License may be discussed at Python Consortium Meeting Message-ID: <200007111523.KAA05408@cj20424-a.reston1.va.home.com> While there still isn't much to report regarding the negotiations between BeOpen and CNRI about Python releases and licenses, I thought I should point out that there is some progress. BeOpen is taking a stance that all Python users should appreciate -- I'd summarize it as "keep the old Python license or bust". CNRI is trying to argue for a new license that is identical to the JPython license (http://www.jpython.org/jplicense.html) with removal of paragraph 3 (requirement to prominent display changes w.r.t. CNRI's version) and paragraph 4 (trademark restrictions). In our views, this license is unusable for several reasons -- it's not GPL-compatible, it's not Open Source compliant, and on previous occasions members of the Python community have reacted strongly against it. I promise that BeOpen won't accept CNRI's current proposal. It's impossible to say whether CNRI will accept BeOpen's position; as a precaution, assuming the issue is still open next week, we've added discussion of the license to the agenda of the Python Consortium meeting in Monterey (see below). I can't say what will happen if the negotiations break off -- but I hope that the discussion at the meeting will open CNRI's eyes. I hope that employees of consortium member companies will do everything they can to ensure that their company is represented at the meeting for this important discussion! Feel free to write me for more background information. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------- Forwarded Message Date: Mon, 10 Jul 2000 15:09:29 -0400 From: Albert Vezza To: consortium-members at python.org cc: rkahn at cnri.reston.va.us, Barbara Fuller Subject: [Py-Consortium] Python Consortium Meeting Python Consortium Members, There will be an important Python Consortium meeting on the July 21st following the O'Reilly Open Source Conference in Monterey, California. The meeting will be held at the Marriott which is adjacent to the Monterey Convention center. This is a discussion meeting and all items on the agenda will be fully explored along with any other important items that are brought to the table. If any member has an important issue they would like to see explored please let me know. Please RSVP to bfuller at foretec.com with the name of the attendees. Best regards, Al ---------------------------------------------------------- Proposed Agenda 8:00 Continental Breakfast 9:00 Python Consortium and Its Continuing Role 10:00 Transition of the Python Development Activity 12:00 Lunch 1:00 Management of the Python.Org Site 3:00 The future Python license 4:00 The desired development path for Python 2.0 5:00 Adjourn Albert Vezza Vice President Corporation for National Research Initiatives 1895 Preston White Drive Suite 100 Reston, VA 20191-5434 Internet mail: avezza at cnri.reston.va.us Tel: (703) 620-8990 Fax: (703) 620-0913 Natick, MA Office Tel: (508) 650 4020 Fax: (508) 650 4639 ------- End of Forwarded Message From gvwilson at nevex.com Tue Jul 11 16:42:55 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 10:42:55 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111440.JAA05205@cj20424-a.reston1.va.home.com> Message-ID: > > [x,y for x in (1,2,3) for y in (4,5,6)] > Hm, I suppose the programmer meant the same as > [(x,y) for x in (1,2,3) for y in (4,5,6)] > Would it be really bad if we forced them to write it that way? Strongly prefer the latter, as it permits: [[x,y] for x in (1,2,3) for y in (4,5,6)] (either now or in future). Would it also permit: [{x:y} for x in (1,2,3) for y in (4,5,6)] i.e. dict construction using list comprehension? I'd use this in quite a few places. > Side note: the suggested syntax here (for i in seq1 for j in seq2) > looks like a potential alternative for the currently proposed parallel > for loop syntax (for i in seq1; j in seq2). > > Only problem: the for-for variant could be mistaken by someone used to > see nested loops as meaning the same as > > for i in seq1: > for j in seq2: ... Until yesterday's posting, I assumed that this is what for-for loops would do, i.e. that they'd deliver a cross-product rather than one-from-each. Was going to ask whether: for i in seq1 and j in seq2: foo would be clearer, but then realized that people might assume it implied that: for i in seq1 or j in seq2: foo would also work, meaning either "while either list is non-empty" or "cross-product". Random thoughts, Greg From guido at beopen.com Tue Jul 11 17:57:10 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 10:57:10 -0500 Subject: [Python-Dev] Bug fixing policy (was Re: Changes to ConfigParser) In-Reply-To: Your message of "Mon, 10 Jul 2000 15:33:14 MST." <20000710153314.W29590@lyra.org> References: <20000710162855.A9245@thyrsus.com> <20000710153314.W29590@lyra.org> Message-ID: <200007111557.KAA05666@cj20424-a.reston1.va.home.com> Greg Stein writes: > > > API changes probably ought to be discussed on this list (which includes the > maintainers of any code). Basic point: the "maintainer(s)" is usually quite > unclear since we avoid attribution within the source if at all possible. > Posing the suggested change here allows for changing maintainers (note that > Fred has done a tone of work on ConfigParser, and I've submitted a few > changes myself, too!), and it allows for broader input. > > However, bug fixes and minor reworking should probably be allowed regardless > of the maintainer. I'd hate to end up at a point where the Python > interpreter is partitioned into a bunch of little fiefdoms, where you must > pay a toll to enter. > > Excellent summary. I would add that if a maintainer is actively maintaining their code, it's not polite to check in changes to their code. It's better to give them a chance to fix it first. (The maintainer them should attribute the fix to whoever first mailed it to them, if they use the fix.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Tue Jul 11 18:09:16 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 11:09:16 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Tue, 11 Jul 2000 09:54:43 -0400." <20000711095443.D27228@kronos.cnri.reston.va.us> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> Message-ID: <200007111609.LAA05816@cj20424-a.reston1.va.home.com> > >> I'd suggest adding poll() to 2.0, and will submit a patch if given the > >> go-ahead. But where should it go? A whole module for it seems > >> excessive; should it go in posixmodule, or maybe select? > > I've completed a patch, SF#100852, to add os.poll() based on Sam > Rushing's code with various modifications; I'd like a reviewer to look > it over, after which I'll check it in. > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 > > I'm not happy with the interface -- you pass in a list of (file > descriptor, event mask) 2-tuples -- but it seems the only way to > expose all of poll()'s functionality. I thought about allowing a lone > file descriptor as well as a tuple, in which you'd assume an event > mask of POLLIN | POLLPRI | POLLOUT (all the common events), but it > seemed like too much magic. I haven't read the patch in detail, but this approach seems reasonable. Somehow I don't understand why we need poll() when we have select(), however. Select() is portable, poll() is Unix specific, but it seems to provide the same functionality. What am I missing? > Also, is there a C utility function to handle the "pass an integer or > an object with a fileno() method" protocol for me? Should there be > one? This is a nice refactoring opportunity. The code probably exists in many places, e.g. selectmodule.c. It should be a function in fileobject.c, I suppose. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fredrik at pythonware.com Tue Jul 11 17:15:06 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 11 Jul 2000 17:15:06 +0200 Subject: [Python-Dev] Adding poll() system call References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> Message-ID: <000701bfeb4a$cbf101e0$0900a8c0@SPIFF> guido wrote: > Somehow I don't understand why we need poll() when we have select(), > however. Select() is portable, poll() is Unix specific, but it seems > to provide the same functionality. What am I missing? quoting from http://www.nightmare.com/medusa/ A major design problem with select(2) is that an fd_set is usually of a fixed maximum size, on many operating systems the kernel needs to rebuilt to raise this limit; even on those that have dynamically adjustable limits, you still need to re- compile your application (because FD_SETSIZE is a macro). From skip at mojam.com Tue Jul 11 04:48:42 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 10 Jul 2000 21:48:42 -0500 (CDT) Subject: [Python-Dev] More Symantec symbols Message-ID: <14698.35594.999203.707698@beluga.mojam.com> Picking up where the __SC__ thread left off, I noticed the following other Symantec symbols in the Python sources just now: ./Include/Python.h:48:#ifdef SYMANTEC__CFM68K__ ./Include/Python.h:65:#ifdef SYMANTEC__CFM68K__ ./Include/mymalloc.h:47:#ifdef SYMANTEC__CFM68K__ ./Include/mymath.h:8:#ifdef SYMANTEC__CFM68K__ ./Include/mymath.h:27:#ifdef SYMANTEC__CFM68K__ ./Python/dynload_mac.c:18:#ifdef SYMANTEC__CFM68K__ /* Really an older version of Universal Headers */ ./Python/errors.c:15:#ifdef SYMANTEC__CFM68K__ Should these be zapped as well or is this something wholely unrelated to the old Symantec compiler issue? Skip From akuchlin at mems-exchange.org Tue Jul 11 17:28:47 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 11 Jul 2000 11:28:47 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007111609.LAA05816@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 11:09:16AM -0500 References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> Message-ID: <20000711112847.G27228@kronos.cnri.reston.va.us> On Tue, Jul 11, 2000 at 11:09:16AM -0500, Guido van Rossum wrote: >Somehow I don't understand why we need poll() when we have select(), >however. Select() is portable, poll() is Unix specific, but it seems >to provide the same functionality. What am I missing? In addition to /F's quote, poll() also scales better since it only lists the file descriptors of interest, while select() builds a bitmap, turns on bits for the fds of interest, and then afterward you have to scan the whole bitmap again. It's O(maximum fd), while poll is O(# of fds), making it more useful for writing more scalable network servers that service thousands of clients at the same time. (At the very highest end, even poll() begins to scale badly since you list "all the open fds", not "all the open fds which have activity". At that point you're supposed to switch to async I/O, but probably you'd have switched from Python to C long before that point.) >This is a nice refactoring opportunity. The code probably exists in >many places, e.g. selectmodule.c. It should be a function in >fileobject.c, I suppose. OK; I'll write up a separate patch to do this and submit it first. (Looks like only select, _tkinter, and poll need this functionality.) --amk From skip at mojam.com Tue Jul 11 16:05:03 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 09:05:03 -0500 (CDT) Subject: [Python-Dev] once enabled gc won't go away until explicitly disabled? Message-ID: <14699.10639.15423.982767@beluga.mojam.com> I had been running with --with-cycle-gc, then the mystery bug hit yesterday, so last night I was working on other stuff and wanted to disable it. I tried removing config.cache and then executing configure as ./configure --with-threads but gc was still there. Then I explicitly commented out the gc line in Modules/Setup.config. Still no luck. Finally, I configured as ./configure --with-threads --without-cycle-gc and then it went away. Is this the correct behavior? Skip From bwarsaw at beopen.com Tue Jul 11 17:38:55 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 11:38:55 -0400 (EDT) Subject: [Python-Dev] once enabled gc won't go away until explicitly disabled? References: <14699.10639.15423.982767@beluga.mojam.com> Message-ID: <14699.16271.147279.134444@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> I had been running with --with-cycle-gc, then the mystery bug SM> hit yesterday, so last night I was working on other stuff and SM> wanted to disable it. I tried removing config.cache and then SM> executing configure as SM> ./configure --with-threads SM> but gc was still there. Then I explicitly commented out the SM> gc line in Modules/Setup.config. Still no luck. Finally, I SM> configured as SM> ./configure --with-threads --without-cycle-gc SM> and then it went away. SM> Is this the correct behavior? Yes, although both gc and threads are enabled by default in the current betas (so you don't need --with-threads). Whether they'll be enabled for the final release is still TBD. -Barry From guido at beopen.com Tue Jul 11 18:48:47 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 11:48:47 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Tue, 11 Jul 2000 17:15:06 +0200." <000701bfeb4a$cbf101e0$0900a8c0@SPIFF> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <000701bfeb4a$cbf101e0$0900a8c0@SPIFF> Message-ID: <200007111648.LAA06034@cj20424-a.reston1.va.home.com> > guido wrote: > > Somehow I don't understand why we need poll() when we have select(), > > however. Select() is portable, poll() is Unix specific, but it seems > > to provide the same functionality. What am I missing? > > quoting from http://www.nightmare.com/medusa/ > > A major design problem with select(2) is that an fd_set is > usually of a fixed maximum size, on many operating systems > the kernel needs to rebuilt to raise this limit; even on those > that have dynamically adjustable limits, you still need to re- > compile your application (because FD_SETSIZE is a macro). OK. +1 from me. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Tue Jul 11 17:52:05 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 11:52:05 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <20000711112847.G27228@kronos.cnri.reston.va.us> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> Message-ID: <14699.17061.139324.335138@bitdiddle.concentric.net> If we're adding poll to enhance scalability, I'd like to see a more efficient interface that generates the poll_fd* separately from calling poll. The interface would be something like this: obj = poll.new() # generate a new pollfd array obj.register(f1, POLLIN | POLLOUT) obj.register(f2, POLLOUT) obj.poll() obj.unregister(f2) obj.poll() I think this would be a lot more efficient when the files being polled don't change very often. Jeremy From thomas at xs4all.net Tue Jul 11 17:52:31 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 17:52:31 +0200 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <14699.17061.139324.335138@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 11, 2000 at 11:52:05AM -0400 References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> Message-ID: <20000711175231.V26534@xs4all.nl> On Tue, Jul 11, 2000 at 11:52:05AM -0400, Jeremy Hylton wrote: > The interface would be something like this: > obj = poll.new() # generate a new pollfd array I would suggest 'poll.Poller()' or some such, for similarity with pickle and such. 'new()' looks a bit C++ish to me ;) Definately +1 on the idea tho ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Tue Jul 11 17:53:14 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 11:53:14 -0400 (EDT) Subject: [Python-Dev] SyntaxError patches Message-ID: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> Ping has a really nice patch to generate better error messages for SyntaxError on SourceForge (#100734). This provides better messages, but keeps all these errors as plain SyntaxError exceptions. At one point, we were discussing having specializations of SyntaxError, and I posted a patch that defined IndentationError and TabError. With Ping's changes, using these instead of plain SyntaxError is trivial. Should I include that, or only change the error messages using Ping's patch? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Jul 11 17:56:42 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 11:56:42 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <20000711175231.V26534@xs4all.nl> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> <20000711175231.V26534@xs4all.nl> Message-ID: <14699.17338.219363.10153@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > I would suggest 'poll.Poller()' or some such, for similarity with pickle and > such. 'new()' looks a bit C++ish to me ;) Definately +1 on the idea tho ;) Both have precedents in the standard library; the MD5 and SHA hash modules both provide a new() function to create the objects. It's not clear that the class-like name is terribly appropriate since a C type could not be subclassed. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Tue Jul 11 16:35:53 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 09:35:53 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111440.JAA05205@cj20424-a.reston1.va.home.com> References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> <200007111440.JAA05205@cj20424-a.reston1.va.home.com> Message-ID: <14699.12489.875905.520781@beluga.mojam.com> Guido> [(x,y) for x in (1,2,3) for y in (4,5,6)] Guido> Would it be really bad if we forced them to write it that way? For that matter, perhaps requiring parens for all tuple definitions in Py3k wouldn't be a bad idea. Skip From thomas at xs4all.net Tue Jul 11 17:09:05 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 17:09:05 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from gvwilson@nevex.com on Tue, Jul 11, 2000 at 10:42:55AM -0400 Message-ID: <20000711181021.G25805@xs4all.nl> [Note: removing known python-dev members from CC: line. I apologize if that's inconvenient, but otherwise Mailman might not let the posting through. Also, Greg Ewing already received this msg, which had a typo in the To: line. Sorry, Greg ;-P] On Tue, Jul 11, 2000 at 10:42:55AM -0400, Greg Wilson wrote: > > > [x,y for x in (1,2,3) for y in (4,5,6)] > > Hm, I suppose the programmer meant the same as > > [(x,y) for x in (1,2,3) for y in (4,5,6)] > > Would it be really bad if we forced them to write it that way? Oh, yeah, I forgot to say why I disliked it, asside from it being hard to do: Isn't the idea that ()'s do not create tuples, ','s do ? To make something clear, though, '[x,y for x in (1,2,3) for y in (4,5,6)]' creates [(1, 4), (1, 5), (1, 6), (2, 4), (2, 5), (2, 6), (3, 4), (3, 5), (3, 6)] and *not* '[1, 4, 2, 5, 3, 6]', in case anyone was thinking that ! That would be the only reason I'd go for forcing '(x,y)' somehow: disambiguation. But then, tuple-creation is slightly ambiguous already, so allowing the ()'s to be left out here as well, seems pretty natural to me. > Strongly prefer the latter, as it permits: > [[x,y] for x in (1,2,3) for y in (4,5,6)] > (either now or in future). Would it also permit: > [{x:y} for x in (1,2,3) for y in (4,5,6)] > i.e. dict construction using list comprehension? I'd use this in quite a > few places. The first is a good example, though it creates a list of lists, not a single list. The second would create a list of dicts, not a single dict. If you want to create a single dict, this would be better syntax: {x:y for x in (1,2,3) for y in (4,5,6)} AKA dict-comprehensions ;) Unless '[' .. ']' is changed from list-creator to comprehensions-function, and the resulting object is determined by the first expression within the listcomp... That makes it a lot less logical, to me :P > Until yesterday's posting, I assumed that this is what for-for loops would > do, i.e. that they'd deliver a cross-product rather than one-from-each. Well, what would be the use ? You can do that using nested for-loops already. So it looks a tad different, so what ;) (Or are you talking about for-for-loops in list comprehensions instead ?) > Was going to ask whether: > > for i in seq1 and j in seq2: > foo > would be clearer, but then realized that people might assume it implied > that: > for i in seq1 or j in seq2: > foo > would also work, meaning either "while either list is non-empty" or > "cross-product". Well, the problem with *that* syntax is that it's already valid ! Imagine seq1 being a sequence, and seq2.__contains__ returning a sequence. Also, the parser would have a hard time figuring out what version of the for loop to use: is this 'for' exprlist 'in' testlist where 'testlist' contains 'and' and/or 'in', or 'for' exprlist 'in' testlist ('and' exprlist 'in' testlist)* ? I'm not sure if it's possible to use the 2nd form at all! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From akuchlin at mems-exchange.org Tue Jul 11 18:18:17 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 11 Jul 2000 12:18:17 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <14699.17061.139324.335138@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 11, 2000 at 11:52:05AM -0400 References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> Message-ID: <20000711121817.J27228@kronos.cnri.reston.va.us> On Tue, Jul 11, 2000 at 11:52:05AM -0400, Jeremy Hylton wrote: >obj = poll.new() # generate a new pollfd array >obj.register(f1, POLLIN | POLLOUT) >obj.register(f2, POLLOUT) >obj.poll() >obj.unregister(f2) >obj.poll() Very interesting, and probably worth doing because all that list parsing *is* a silly waste of CPU. But could poll still live in the posixmodule, then, or be a module of its own? [1] As a side issue, is posixmodule.c getting ungainly, at 5333 lines of source code? Should something be done about this? (Splitting it into several C files that get #included, or get linked together, for example.) --amk [1] Ironic footnote: Sam mentioned that Egroups doesn't actually use the pollmodule.c in the Medusa distribution, because they already have a module named "poll" that does something completely different. From fdrake at beopen.com Tue Jul 11 18:22:43 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 12:22:43 -0400 (EDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> References: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> Message-ID: <14699.18899.148734.462266@cj42289-a.reston1.va.home.com> I wrote: > At one point, we were discussing having specializations of > SyntaxError, and I posted a patch that defined IndentationError and > TabError. With Ping's changes, using these instead of plain > SyntaxError is trivial. Should I include that, or only change the > error messages using Ping's patch? I've attached a combined patch, in case any is interested. This does not include updated documentation, and could use additional tests. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: indentation-error.patch URL: From guido at beopen.com Tue Jul 11 19:52:43 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 12:52:43 -0500 Subject: [Python-Dev] list comprehensions again... In-Reply-To: Your message of "Tue, 11 Jul 2000 17:09:05 +0200." <20000711181021.G25805@xs4all.nl> References: <20000711181021.G25805@xs4all.nl> Message-ID: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Oops. I was simply mistaken on what the for-for syntax in list comprehensions did! Ideally, list comprehensions should support both parallel and nested for loops, but I'm not sure how to decide to parse them if they both occur. E.g. what is this? [(x,y+z) for x in (1,2,3,4,5,6); for y in "abc" for z in "de"] For me, the semicolon separates much stronger than the for, so (to me) this feels like (applying parentheses to show grouping): (for x); (for y for z) and would yield: [(1, "ad"), (2, "ae"), (3, "bd"), (4, "be"), (5, "cd"), (6, "ce")] But is that the most useful? And how do you write the other grouping? I mean: (for x; for y) (for z) which could yield: [(1, "ad"), (1, "ae"), (2, "bd"), (2, "be"), (3, "cd"), (3, "ce")] A more practical question: if we're going to introduce [::], list comprehensions, and parallel for loops, what would be the best way to introduce the patches so that each patch changes as little as possible of the code introduced by the previous patch? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From dbressler at valinux.com Tue Jul 11 19:03:09 2000 From: dbressler at valinux.com (Dan Bressler) Date: Tue, 11 Jul 2000 10:03:09 -0700 Subject: [Python-Dev] Re: SourceForge References: <20000707133533.E17746@valinux.com> <20000707182448.A31259@thyrsus.com> <39667D29.1A4FB1BB@valinux.com> <20000709214138.I4566@thyrsus.com> <396A4CFC.CEE2419A@valinux.com> <20000710203719.B9793@thyrsus.com> <396A6F7D.66D5F085@valinux.com> <20000710211000.A10068@thyrsus.com> <200007111458.JAA05267@cj20424-a.reston1.va.home.com> Message-ID: <396B534D.3C4A4E3A@valinux.com> If you're going to be in Santa Clara during the day, do you want to stay in the area and meet us in the evening? (Our offices are right in the neighborhood.) Guido van Rossum wrote: > > Dan Bressler : > > > I'm trying to sync schedules -- If we could set it for Tuesday evening, July > > > 18th, that would work best. > > > > OK. Python folks who will be at the Monterey conference; Dan > > Bressler, one of the managers of SourceForge, is amenable to an > > evening meeting with this gang on Tuesday the 18th. I gather Tim > > Purdue, currently the lead programmer on the project, will be there. > > > > The exact time is still to be worked out. Anybody got a proposal? > > I'm not sure what time we'll be arriving in Monterey -- we have our > plane tickets to San Jose and I know we're going to spend Tuesday > daytime at the BeOpen headquarters in Santa Clara, but I don't know > yet what mode of transportation we're going to take to Monterey and at > what time. Given that Dan prefers Tuesday evening I'll try to press > for leaving early enough so that there's some evening left! > > Looking forward to this meeting, > > --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Tue Jul 11 19:09:07 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 13:09:07 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <20000711121817.J27228@kronos.cnri.reston.va.us> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> <20000711121817.J27228@kronos.cnri.reston.va.us> Message-ID: <14699.21683.305409.97490@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Tue, Jul 11, 2000 at 11:52:05AM -0400, Jeremy Hylton wrote: >obj = poll.new() # generate a new pollfd array >obj.register(f1, POLLIN | POLLOUT) >obj.register(f2, POLLOUT) >obj.poll() >obj.unregister(f2) >obj.poll() AMK> Very interesting, and probably worth doing because all that AMK> list parsing *is* a silly waste of CPU. But could poll still AMK> live in the posixmodule, then, or be a module of its own? [1] The select module has exactly the same problem and could use the same interface. They could both live in their own module. I'm not sure what to call it. Possibilities include: - add it to the current select module - new name, e.g. asyncio, fileevent - call it _asyncore and expose it through the asyncore module Jeremy From gvwilson at nevex.com Tue Jul 11 19:09:11 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 13:09:11 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz Message-ID: I sent the message below to the 11 developers here in the office this morning. They all have 10+ years experience with C, and 2-3 years with C++, Java, or both. None have used Python (I'm working on it :-), but two have extensive Perl experience, and one worked on and with functional languages in grad school. The question was: OK, folks, language question. Given the statement: for x in [10, 20, 30]; y in [1, 2]: print x+y (note that the second list is shorter than the first), would you expect to see: (A) 'x' and 'y' move forward at the same rate: 11 22 (B) 'y' goes through the second list once for each value of 'x': 11 12 21 22 31 32 (C) an error message because the two lists are not the same length? Votes to me, please. Thanks, Greg *Everyone* voted (B). As useful as this capability is, I therefore think the proposed syntax is likely to mislead. Hope it's helpful, Greg From thomas at xs4all.net Tue Jul 11 19:22:03 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 19:22:03 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111752.MAA06413@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 12:52:43PM -0500 References: <20000711181021.G25805@xs4all.nl> <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Message-ID: <20000711192202.B7340@xs4all.nl> On Tue, Jul 11, 2000 at 12:52:43PM -0500, Guido van Rossum wrote: > Ideally, list comprehensions should support both parallel and nested > for loops, but I'm not sure how to decide to parse them if they both > occur. E.g. what is this? > > [(x,y+z) for x in (1,2,3,4,5,6); for y in "abc" for z in "de"] Well, listcomprehensions are currently almost a simple rewrite, so this is fairly easy to parse: the ; binds more tightly than the last 'for', and 'for' loops and 'if' branches parse left-to-right without possibilities of 'else'. [..] > But is that the most useful? And how do you write the other grouping? > I mean: > (for x; for y) (for z) > which could yield: > [(1, "ad"), (1, "ae"), (2, "bd"), (2, "be"), (3, "cd"), (3, "ce")] This might be a problem. Also, even providing the 'nested for' in listcomprehensions might be a problem, for exactly the reason you yourself showed: it's not that easy to see what it actually does. Can we get away with not including the nested-for syntax ? I mean, "don't do that then" is something that really appeals to me, and I think it applies here: If you want nested-for loops in creating a list, use a real for loop :P Also, on 4th or 5th pass, I'm still not sure about the whole list comprehensions syntax... I know what problem they are supposed to solve, and I think they succeed in that. But the syntax is pretty ambiguous, and not too pythonic at that. For instance, the endless mixing possibilities of 'for' and 'if' without delimiters or ways to group them can be pretty confusing. Some documentation on that might help, though. Also, it would be nice if list comprehensions could be used to initialize *part* of a list, something like this: ['a', 'b', c for c in ['C', 'D', 'E'], 'f', 'g'] (which would create ['a', 'b', 'C', 'D', 'E', 'f', 'g']) But that creates a legion of other confusalities... Perhaps adding a new/different delimiter to list comprehensions would be a good idea ? :P Disclaimer, though: I didn't follow the list-comprehension discussions on python-list, last year, that closely. I noticed the syntax and thought "that cool.", but that's about it. Was any other syntax proposed ? > A more practical question: if we're going to introduce [::], list > comprehensions, and parallel for loops, what would be the best way to > introduce the patches so that each patch changes as little as possible > of the code introduced by the previous patch? parallel-for-loops -> list comprehensions -> range-literals Unless list comprehensions do not adopt the parallel for loop syntax, in which case the order isn't that important. They don't really touch in that much places, not even the range-literals and list comprehensions patch. The Grammar and a single line in compile.c, if I recall correctly. The rest is just offset and fluff. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Tue Jul 11 20:24:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 13:24:05 -0500 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: Your message of "Tue, 11 Jul 2000 13:09:11 -0400." References: Message-ID: <200007111824.NAA06758@cj20424-a.reston1.va.home.com> > I sent the message below to the 11 developers here in the office this > morning. They all have 10+ years experience with C, and 2-3 years with > C++, Java, or both. None have used Python (I'm working on it :-), but two > have extensive Perl experience, and one worked on and with functional > languages in grad school. The question was: > > OK, folks, language question. Given the statement: > > for x in [10, 20, 30]; y in [1, 2]: > print x+y > > (note that the second list is shorter than the first), would you > expect to see: > > (A) 'x' and 'y' move forward at the same rate: > > 11 > 22 > > (B) 'y' goes through the second list once for each value of 'x': > > 11 > 12 > 21 > 22 > 31 > 32 > > (C) an error message because the two lists are not the same length? > > Votes to me, please. > > Thanks, > Greg > > *Everyone* voted (B). As useful as this capability is, I therefore think > the proposed syntax is likely to mislead. Thanks for user testing! I just wished you had shown it to them with two lists of the same length. That's the normal case, and I believe that the different length must have tricked them into believing that it couldn't possibly be (A). I'd like to run the experiment with that change. Do you have another set of guinea pigs around? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Tue Jul 11 18:07:39 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 11:07:39 -0500 (CDT) Subject: [Python-Dev] once enabled gc won't go away until explicitly disabled? In-Reply-To: <14699.16271.147279.134444@anthem.concentric.net> References: <14699.10639.15423.982767@beluga.mojam.com> <14699.16271.147279.134444@anthem.concentric.net> Message-ID: <14699.17995.992200.367742@beluga.mojam.com> BAW> Yes, although both gc and threads are enabled by default in the BAW> current betas (so you don't need --with-threads). Whether they'll BAW> be enabled for the final release is still TBD. Ah, yes, now I remember. I don't suppose there's any way to coax 'configure --help' into dumping out the default values, is there? I think it would be a very useful feature. Skip From skip at mojam.com Tue Jul 11 18:09:58 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 11:09:58 -0500 (CDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> References: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> Message-ID: <14699.18134.550769.266956@beluga.mojam.com> Fred> At one point, we were discussing having specializations of Fred> SyntaxError, and I posted a patch that defined IndentationError Fred> and TabError. I think you should go for it. As long as they are subclasses of SyntaxError no existing code should break. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From gvwilson at nevex.com Tue Jul 11 20:45:51 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 14:45:51 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007111824.NAA06758@cj20424-a.reston1.va.home.com> Message-ID: [Greg's list comprehension experiment deleted] > Guido: > I just wished you had shown it to them with two lists of the same > length. That's the normal case, and I believe that the different > length must have tricked them into believing that it couldn't possibly > be (A). > I'd like to run the experiment with that change. Do you have another > set of guinea pigs around? Yes, I'll have a roomful of people Thursday morning (practicing my talk for Monterey). If someone would like to rephrase the example, I'd be happy to do a show-of-hands poll. Thanks, Greg From guido at beopen.com Tue Jul 11 22:03:12 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 15:03:12 -0500 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: Your message of "Tue, 11 Jul 2000 14:45:51 -0400." References: Message-ID: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> > Yes, I'll have a roomful of people Thursday morning (practicing my talk > for Monterey). If someone would like to rephrase the example, I'd be > happy to do a show-of-hands poll. Suppose this code: for i in (1, 2, 3): print i prints this: 1 2 3 What do you think the following code would print? for i in (10, 20, 30); j in (1, 2, 3): print i+j A. 11 22 33 B. 11 12 13 21 22 23 31 32 33 I'm afraid the answer will be the same, if these are again numerical analysts -- these people live by nested DO loops. :-( --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Tue Jul 11 19:38:23 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 12:38:23 -0500 (CDT) Subject: [Python-Dev] patch assignments? Message-ID: <14699.23439.483525.515059@beluga.mojam.com> I just noticed a patch assignment made to me on June 30th: http://sourceforge.net/patch/?func=detailpatch&patch_id=100688&group_id=5470 with a comment from Tim on July 10th about it having been assigned to me. In the flood of patch submissions and updates I guess I missed this. The SF patch change mails say *nothing* as far as I can tell about what the nature of the change of status of a patch is. With all changes going through the patches mailing list, more interesting stuff can get lost in the sea of stuff I'm not particularly interested in. Consequently, I would have hit 'd' seeing a subject like "Add 'isatty(fd)' to posixmodule". Has anyone asked SF for a more complete patch mailing? If not, I will probably unsubscribe from patches at python.org so I can be assured that those notices I get are actually for me. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From pingster at ilm.com Tue Jul 11 21:11:58 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 12:11:58 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> Message-ID: On Tue, 11 Jul 2000, Greg Ewing wrote: > Thomas> '[' [testlist [list_iter]] ']' > Thomas> Should that really be 'testlist'? > [...] > if it were changed I expect > you'd get complaints that things like > > [x,y for x in (1,2,3) for y in (4,5,6)] Well, i imagine this would yield [x, 4, 5, 6, 4, 5, 6, 4, 5, 6] right? I think i vote for "produce parens only if i write parens". Hmm, another question. When someone writes: [x, y for x in 1, 2, 3 for y in 4, 5, 6] ...what should they get? (a) SyntaxError (b) [(1, 4), (1, 5), (1, 6), (2, 4), (2, 5), (2, 6), (3, 4), (3, 5), (3, 6)] (c) [x, 4, 5, 6, 4, 5, 6, 4, 5, 6] (d) [x, y, 2, 3, 5, 6] If we go with above rule of "produce parens only if i write parens", then the answer has to be (d). That is, commas bind last in a list (which seems consistent with normal practice...). Does this make sense or seem confusing to you? If it's too confusing, we can choose (a) and require that the first part of a list comprehension has to be a single test. -- ?!ng From pingster at ilm.com Tue Jul 11 21:15:26 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 12:15:26 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: Message-ID: On Tue, 11 Jul 2000, Greg Wilson wrote: > (either now or in future). Would it also permit: > > [{x:y} for x in (1,2,3) for y in (4,5,6)] > > i.e. dict construction using list comprehension? I'd use this in quite a > few places. The above would produce [{1: 4}, {1: 5}, {1: 6}, {2: 4}, {2: 5}, {2: 6}, {3: 4}, {3: 5}, {3: 6}] If, on the other hand, you tried to make a single dictionary with {x: y for x in (1, 2, 3) for y in (4, 5, 6)} it doesn't make a lot of sense (multiple y's for the same x?). The only thing i could imagine it producing, perhaps, is {1: 6, 2: 6, 3: 6} -- ?!ng From bwarsaw at beopen.com Tue Jul 11 21:29:43 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 15:29:43 -0400 (EDT) Subject: [Python-Dev] Memory leak tracking Message-ID: <14699.30119.262274.258429@anthem.concentric.net> Folks, I've been doing a fair bit of Purify-cation on the Python source tree. Things are looking pretty good in general, but I have a question for you all. When I compile out gc, I get more leaks in the core, namely in exceptions.c. Turning on gc clears all of these up; e.g. all the memory gets freed eventually. My suspicion therefore is that there are a number of cycles created during the initialization of the built-in exceptions. How important is it to fix these problems when gc is disabled? It's not a lot of memory (like <5000 bytes or so for running one of the regr tests) and it'll take some time to track them down and figure out what the right fix is. Given everything all the other more interesting work to do, it doesn't seem worth it. So far we haven't seen any showstopping gc bugs reported yet, so I'm hopeful it'll remain enabled by default in 2.0. Please let me know what you think. If the concensus is to fix them, I keep working on them. I do still plan on looking at the few memory problems still left even with gc turned on. -Barry From pingster at ilm.com Tue Jul 11 21:26:54 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 12:26:54 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 11 Jul 2000, Guido van Rossum wrote: > [(x,y+z) for x in (1,2,3,4,5,6); for y in "abc" for z in "de"] > > For me, the semicolon separates much stronger than the for, so (to me) > this feels like (applying parentheses to show grouping): > > (for x); (for y for z) When written like the above, i agree that the semicolon separates more strongly. Perhaps we should rearrange the syntax to make the semicolon more interior? This also addresses Greg's poll: > > for x in [10, 20, 30]; y in [1, 2]: > print x+y [...] > *Everyone* voted (B). How about writing this as: for x; y in [10, 20, 30]; [1, 2]: print x + y > And how do you write the other grouping? As a result, this provides a way to write parallel loops within list comprehensions, although it might not be very clear until you're familiar with the way it's written above. At least it's possible: [(x, y+z) for x; y in (1, 2, 3, 4, 5, 6); "abc" for z in "de"] If colons were introduced, would that help keep things clear? [(x, y+z): for x; y in (1, 2, 3, 4, 5, 6); "abc": for z in "de"] This would then be directly reminiscent of for x; y in (1, 2, 3, 4, 5, 6); "abc": for z in "de": list.append((x, y+z)) which provides the appropriate meaning. I don't like extra punctuation, but i'm not sure what else to do here since "for" alone is a very weak separator. -- ?!ng From pingster at ilm.com Tue Jul 11 21:40:22 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 12:40:22 -0700 (PDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: Message-ID: On Tue, 11 Jul 2000, Greg Wilson wrote: > for x in [10, 20, 30]; y in [1, 2]: > print x+y [...] > (A) 'x' and 'y' move forward at the same rate: > (B) 'y' goes through the second list once for each value of 'x': > (C) an error message because the two lists are not the same length? [...] > *Everyone* voted (B). Okay, i just thought of another answer to this. Scream at me if you find this hideous. for x in [10, 20, 30] while y in [1, 2]: print x+y My previous message proposed colons to separate the clauses of a list comprehension, which i now realize makes dict comprehensions impossible (or at least a little strange-looking). If we use "while", the lack of semicolons means that we can do parallel loops in list-comps without colons, which in turn enables dict-comps. -- ?!ng From thomas at xs4all.net Tue Jul 11 21:51:00 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 21:51:00 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from pingster@ilm.com on Tue, Jul 11, 2000 at 12:26:54PM -0700 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Message-ID: <20000711215100.C7340@xs4all.nl> On Tue, Jul 11, 2000 at 12:26:54PM -0700, Ka-Ping Yee wrote: > This would then be directly reminiscent of > > for x; y in (1, 2, 3, 4, 5, 6); "abc": > for z in "de": > list.append((x, y+z)) > > which provides the appropriate meaning. > I don't like extra punctuation, but i'm not sure what else to do > here since "for" alone is a very weak separator. Agreed, though I think ';' is the wrong punctuation for this... It's always been a statement-seperator, and now it's used to seperate parts of a statement, like a normal comma. I still think 'for x in a; y in b' is better than this, but I'm not sure how to liase it with list comprehensions' "nested for". But then, I'm not sure about any of the list comp syntax right now :-) To paraphrase Guido, I got myself in quite a mess ;-) Anyone object if I pull this discussion into c.l.py ? I'm not sure if any new ideas pop up, but it might give some more data to work with ;-P And I don't think any of this is urgent in any way, I doubt anything more will get done until after ORA OSCON, anyway. And maybe some of you guys that are actually going there can discuss it face to face ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw at beopen.com Tue Jul 11 21:54:16 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 15:54:16 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Message-ID: <14699.31592.410628.754071@anthem.concentric.net> Sorry, but I'm being to think that both the list comprehensions and parallel for loops are looking pretty dodgy. I wonder what newbies are going to think when they see this stuff? If the semantics aren't obvious to us, they definitely will not be to them. Range literals I can see as being worth it. I wonder if parallel for loops can't be handled more gracefully with a function -- isn't it just a nice wrapper around a specific call to map() anyway? List comprehensions do seem to need more syntactic support, but the ambiguity of the semantics bothers me. monkey-wretched-ly y'rs, -Barry From gvwilson at nevex.com Tue Jul 11 21:59:52 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 15:59:52 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711215100.C7340@xs4all.nl> Message-ID: > Thomas wrote: > Anyone object if I pull this discussion into c.l.py? Rather than asking for suggestions, would it make sense to prepare one or more examples of multi-loops and output, then ask people to vote on which ones they would expect to match up with which? Likely to be lower bandwidth, and it'd be an interesting experiment in language design procedures in its own right :-). Greg From fdrake at beopen.com Tue Jul 11 22:11:54 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 16:11:54 -0400 (EDT) Subject: [Python-Dev] Showing stale locks under cvsweb Message-ID: <14699.32650.73594.921249@cj42289-a.reston1.va.home.com> I've just received a response to my "bug report" at SourceForge about stale locks needing to be visible in cvsweb. They categorized it as "Irrelevant" and said the cvsweb people were the ones to contact (seems reasonable; now I know that there *are* cvsweb people!). I've found the right people and sent a note to them, with a copy to Greg Stein as well, noting that ViewCVS should support a similar feature. I'll let everyone know what happens regarding this if/when I get a response. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Tue Jul 11 22:20:36 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 16:20:36 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> References: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> Message-ID: <14699.33172.319800.354377@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> I'm afraid the answer will be the same, if these are again GvR> numerical analysts -- these people live by nested DO loops. :-( If we end up calling this new feature list comprehensions, we might create the expectation that they behave like list comprehensions in other languages. Haskell is one language with comprehensions and they behave the way that the numerical analysts expect them to behave. Maybe we should chalk it up to numerical analysts and funtional programmers being weird, but they may be on to something. Here's a short excerpt from the Gentle Introduction to Haskell: http://www.haskell.org/tutorial/goodies.html (Sec. 2.4.1) >[ f x | x <- xs ] >This expression can intuitively be read as "the list of all f x such >that x is drawn from xs." The similarity to set notation is not a >coincidence. The phrase x <- xs is called a generator, of which more >than one is allowed, as in: > >[ (x,y) | x <- xs, y <- ys ] > >This list comprehension forms the cartesian product of the two lists >xs and ys. The elements are selected as if the generators were >"nested" from left to right (with the rightmost generator varying >fastest); thus, if xs is [1,2] and ys is [3,4], the result is >[(1,3),(1,4),(2,3),(2,4)]. Jeremy From rushing at nightmare.com Tue Jul 11 22:26:53 2000 From: rushing at nightmare.com (Sam Rushing) Date: Tue, 11 Jul 2000 13:26:53 -0700 (PDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <26950820@toto.iv> Message-ID: <14699.33549.656358.89869@seattle.nightmare.com> Andrew Kuchling writes: > (At the very highest end, even poll() begins to scale badly since you > list "all the open fds", not "all the open fds which have activity". > At that point you're supposed to switch to async I/O, but probably > you'd have switched from Python to C long before that point.) Lots of good info on these issues is available here: http://www.kegel.com/c10k.html Linux and FreeBSD are growing new kernel-event-delivery mechanisms that promise better scalability and efficiency. Win32's had it from the beginning. For the eGroups coroutine scheduler ( http://www.egroups.com/group/python-coro ) I wrote a more efficient poll wrapper, but it's also very bare. Might be a starting point. This stuff hasn't been used yet, so the driver module has fallen way behind. Compare coro2.py to 'coro.py' in the egroups coro dist. http://www.nightmare.com/stuff/coro_poll.c http://www.nightmare.com/stuff/coro2.py In coro_poll.c, there's a single struct pollfd array, that should probably be PyObject-ified. -Sam From klm at digicool.com Tue Jul 11 22:33:01 2000 From: klm at digicool.com (Ken Manheimer) Date: Tue, 11 Jul 2000 16:33:01 -0400 (EDT) Subject: [Python-Dev] Objects/ ANSI-fied In-Reply-To: <200007092153.QAA14165@cj20424-a.reston1.va.home.com> Message-ID: On Sun, 9 Jul 2000, Guido van Rossum wrote: > > Ok, the Objects/ directory has been ANSI-fied, and I've noticed /F > > slaving away in the Modules/ directory, so I'll get out of the way for > > a little bit. ;) > > Great! Sounds like everybody is getting the hint that 2.0 needs to > have some distinguishing characteristics compared to 1.6... :-) Hmm. I just realized an interesting take on 2.0's "distinguishing features". Check out the volume of python-dev traffic - reflecting what's to me, at least, incredibly high pace and high fiber collaboration. Python 2.0 could be about a new process, as much as it is about the license policy changes that better enable it, or the productivity it seems to be promoting. (I'm not silly enough to suggest that the version change could happen solely on the basis of a new process - there really do seem to be genuine results, here...) (And if BeOpen happens to be looking for a product, and you can bottle this, they might like to have it.-) Seriously, maybe BeOpen should concentrate on helping teams to better employ available resources - look at how good they're doing with you guys. Well, ok, what they're doing right is leaving you guys mostly alone - maybe your payoff for them would be to clue them into what works, and they can do some work to deliver it to others. Might could help you all, too, in solidifying what's going on...) Ken klm at digicool.com From paul at prescod.net Tue Jul 11 22:44:06 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 15:44:06 -0500 Subject: [Python-Dev] list comprehensions again... References: Message-ID: <396B8716.C1C9EE3C@prescod.net> I'm sorry to muddy the waters, but perhaps a solution is to try and stay as close to regular Python syntax as possible. I am thinking of a nested comprehension as a regular nested for-loop that has an expression rather than a suite as its body: Nested (List): [for x in (0,10,20,30): for y in (0,1,2,3): x+y] [0,11,22,33] Parallel (Tuple): (for x in (0,10,20,30) and y in (0,1,2,3): x+y) (0,11,22,33) Parallel (Dict): {for x in (0,10,20,30) and y in range (0,1,2,3): x,y} The dict one needs a little explaining. A dict comprehension is a comprehension where the delimiters are curly braces and the generated items are required to be pairs. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From thomas at xs4all.net Tue Jul 11 22:47:49 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 22:47:49 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from gvwilson@nevex.com on Tue, Jul 11, 2000 at 03:59:52PM -0400 References: <20000711215100.C7340@xs4all.nl> Message-ID: <20000711224749.C7345@xs4all.nl> On Tue, Jul 11, 2000 at 03:59:52PM -0400, Greg Wilson wrote: > > Thomas wrote: > > Anyone object if I pull this discussion into c.l.py? > Rather than asking for suggestions, would it make sense to prepare one or > more examples of multi-loops and output, then ask people to vote on which > ones they would expect to match up with which? Likely to be lower > bandwidth, and it'd be an interesting experiment in language design > procedures in its own right :-). That's exactly what I had in mind, yes ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Tue Jul 11 22:49:44 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 15:49:44 -0500 Subject: [Python-Dev] list comprehensions again... References: <396B8716.C1C9EE3C@prescod.net> Message-ID: <396B8868.B58F3F0C@prescod.net> Paul Prescod wrote: > > ... > (for x in (0,10,20,30) and y in (0,1,2,3): > x+y) > (0,11,22,33) Sorry, replace the "and" with ";" or "while" to resolve the ambiguity: Nested (List): [for x in (0,10,20,30): for y in (0,1,2,3): x+y] [0,11,22,33] Parallel (Tuple): (for x in (0,10,20,30) ; y in (0,1,2,3): x+y) (0,11,22,33) Parallel (Dict): {for x in (0,10,20,30) ; y in range (0,1,2,3): x,y} -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Tue Jul 11 23:16:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 11 Jul 2000 23:16:42 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: Message-ID: <021201bfeb7d$515c3520$f2a6b5d4@hagrid> tim wrote: > I believe we also need a way to split unicodedatabase.c into multiple files, > as > 64K lines in a source file is unreasonable (Python can't handle a > source file that large either, and Python is the *definition* of > reasonableness here ), and the MS compiler spits out a warning about > its sheer size. just a heads-up: I've been hacking a little on a new unicode database. the results this far are quite promising: CTYPE: is*, to* functions 118k => 13k CNAME: code <=> name mappings (\N{name}) 440k => 160k CINFO: remaining unicode properties 590k => 42k (approximate code size with the old and new code, on Windows) on the source side, 3300k source files are replaced with about 600k (generated by a script, directly from the uni- code.txt data file). note that the CNAME and CINFO parts are optional; you only need CTYPE to build a working Python interpreter. integrating this with 2.0 should be relatively straightforward, but don't expect it to happen before next week or so... cheers /F From fdrake at beopen.com Tue Jul 11 23:20:38 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 17:20:38 -0400 (EDT) Subject: [Python-Dev] O'Reilly conference Message-ID: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> So who's going to the O'Reilly conference next week? The PythonLabs crew expects to be there, and we just might have some goodies. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pingster at ilm.com Tue Jul 11 23:31:24 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 14:31:24 -0700 (PDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 11 Jul 2000, Guido van Rossum wrote: > What do you think the following code would print? > > for i in (10, 20, 30); j in (1, 2, 3): > print i+j [...] > I'm afraid the answer will be the same, if these are again numerical > analysts -- these people live by nested DO loops. :-( What do you think the answer would be for for i; j in (10, 20, 30); (1, 2, 3): print i+j ? Would you consider posing this question? -- ?!ng From effbot at telia.com Tue Jul 11 23:39:22 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 11 Jul 2000 23:39:22 +0200 Subject: [Python-Dev] O'Reilly conference References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <025201bfeb80$829976e0$f2a6b5d4@hagrid> fred wrote: > So who's going to the O'Reilly conference next week? Portions of the Secret Labs crew expects to be there, and they just might have some goodies. ;) cheers /F From DavidA at ActiveState.com Tue Jul 11 23:48:52 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 11 Jul 2000 14:48:52 -0700 (Pacific Daylight Time) Subject: [Python-Dev] O'Reilly conference In-Reply-To: <025201bfeb80$829976e0$f2a6b5d4@hagrid> Message-ID: On Tue, 11 Jul 2000, Fredrik Lundh wrote: > fred wrote: > > > So who's going to the O'Reilly conference next week? A bunch of ActiveState folks, naturally. We'll have an _early_ demo of Komodo and friends, will be recruiting, etc. If anyone wants to guarantee that they talk to me about anything, it's best to let me know early. --david PS: Anyone who'se going w/ young kids who might want to do fun things w/ mine (& my wife =) should let me know. It's easier to deal w/ lots of kids than w/ a few, somehow... Andy Robinson's family will be there. From thomas at xs4all.net Tue Jul 11 23:47:38 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 23:47:38 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.31592.410628.754071@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Jul 11, 2000 at 03:54:16PM -0400 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> Message-ID: <20000711234737.D7340@xs4all.nl> On Tue, Jul 11, 2000 at 03:54:16PM -0400, Barry A. Warsaw wrote: > Sorry, but I'm being to think that both the list comprehensions and > parallel for loops are looking pretty dodgy. I wonder what newbies > are going to think when they see this stuff? If the semantics aren't > obvious to us, they definitely will not be to them. > Range literals I can see as being worth it. I wonder if parallel for > loops can't be handled more gracefully with a function -- isn't it > just a nice wrapper around a specific call to map() anyway? Well, not really. It doesn't create a new list, only a tuple to hold lists to iter over (in order to pass it to the opcode as a single PyObject) and similar for the resulting objects. It's definately more efficient than the map() solution (and different, see below ;) I agree that all this together looks dodgy, but I think there is a simple way to view it... I still think 'for x in a; y in b:' is the right syntax for parallel for loops. It's almost "only" syntactic sugar for 'for x,y in map(None, a, b)' but it's fairly straightforward, and in large blocks of code it might look a lot better. It also has the benifit of not padding the shortest list to the size of the longest one: getting that behaviour with a map requires an aditional 'filter' or such. Whether it does or doesn't do what people actually expect I don't know, but with all due respect to Greg for doing the usability test, I don't think it carries that much meaning: We should be testing Python newbies, not people who haven't tried Python at all, yet. Unfortunately, I don't have such a batch at hand either ;) (My colleagues either refuse to learn Python, or haven't stayed newbie for more than a few hours :-) Given that you can already do the nested-for-loop with a nested for loop, and it doesn't suffer (much) in way of readability or pythonity, I think most people will realize that the parallel for loop does actually do a parallel for-each. A number of Python features, like (the lack of) nested namespaces and the way assignment works, seem counter-intuitive (or at least lesser-intuitive) at first, but there simply isn't a better way to handle them and maintain Python's simplicity. I think this is one of those cases. Note that this doesn't include list comprehensions ! I find the syntax confusing myself, but it doesn't look like we can fix it by stealing the best syntax of parallel-for loops for it ;) Also, list comprehensions don't add *that* much. They provide an easier way to create a list, but they don't eradicate the need for map, reduce or filter, because there is no way to comprehend an already created list. I like Paul's proposal that makes list comprehensions look more like normal 'for' loops, requiring indentation and all, but I'm not sure if they're going to work... This definately requires more thought ;-) I think I'll post a (very) short summary of the entire discussion and some examples for people to vote about, and perhaps express their opinion, on c.l.py. Sometime tomorrow ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm at hypernet.com Tue Jul 11 23:47:56 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 11 Jul 2000 17:47:56 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.31592.410628.754071@anthem.concentric.net> Message-ID: <1248770416-32799859@hypernet.com> Barry A. Warsaw wrote: > Sorry, but I'm being to think that both the list comprehensions > and parallel for loops are looking pretty dodgy. I'm with Barry here (despite the public humiliation the association involves). My expectations (from examples) correlates to accompanying explanations no better than random choice. I *thought* I liked Greg Ewing's original proposal, but at this point I see syntactic salts of ammonia around one very clear idiom (nested fors) and one less intuitive but unambiguous idiom (map). I like the set notation, but there's a big impedance mismatch to Python. I'd be tempted to spell "cartesian product" as a product. To put it another way: - syntactic sugar for nested "for" loops would be nice, but there's no crying need for it - the current spelling of parallel loops is awkward and probably does warrant syntactic sugar (despite Greg Wilson's experiment that it's not what's expected). If list comprehensions are going to do *both*, the difference in how they're spelled will have to be obvious and intuitive, or we might as well just keep explaining how to use map. - Gordon From gstein at lyra.org Tue Jul 11 23:53:29 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 14:53:29 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from pingster@ilm.com on Tue, Jul 11, 2000 at 12:11:58PM -0700 References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> Message-ID: <20000711145329.T29590@lyra.org> On Tue, Jul 11, 2000 at 12:11:58PM -0700, Ka-Ping Yee wrote: >... > Does this make sense or seem confusing to you? > > If it's too confusing, we can choose (a) and require that the first > part of a list comprehension has to be a single test. If it is too confusing, then drop the darn feature. We're adding syntax that is sure to make Python programs a lot less readable when they are used. People will always say "now, what exactly does that do?" Adding new, complex features does not equate with positive forward progress. This whole notion of list comprehensions seems rather dubious, especially given the wildly varying ideas of what the different syntaxes mean. Sure, maybe we can decide on what it *should* mean, but people will continue to be confused by what they *think* it would mean. Drop the dumb thing altogether. What's the motivation? Bleh. -1 Cheers, -g -- Greg Stein, http://www.lyra.org/ From thomas at xs4all.net Tue Jul 11 23:54:01 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 23:54:01 +0200 Subject: [Python-Dev] O'Reilly conference In-Reply-To: <025201bfeb80$829976e0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jul 11, 2000 at 11:39:22PM +0200 References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> <025201bfeb80$829976e0$f2a6b5d4@hagrid> Message-ID: <20000711235401.E7340@xs4all.nl> On Tue, Jul 11, 2000 at 11:39:22PM +0200, Fredrik Lundh wrote: > fred wrote: > > So who's going to the O'Reilly conference next week? > Portions of the Secret Labs crew expects to be there, and > they just might have some goodies. ;) Goodies!? Argh! Can I send a colleague over to gather some of the goodies for me ? I'm not important enough to go to OSCON, only our resident Perl guru is... But we'd need him back or our company stops functioning, so I'll only send him over if you promise not to hurt him :) Otherwise, I'll have to stay Python-goodieless until the next IPC... -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw at beopen.com Tue Jul 11 23:55:56 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 17:55:56 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> Message-ID: <14699.38892.155046.60218@anthem.concentric.net> >>>>> "Gordo" == Gordon McMillan writes: Gordo> I'm with Barry here (despite the public humiliation the Gordo> association involves). For both of us, of course. :) -Barry From jack at oratrix.nl Tue Jul 11 23:55:12 2000 From: jack at oratrix.nl (Jack Jansen) Date: Tue, 11 Jul 2000 23:55:12 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Message by "James C. Ahlstrom" , Mon, 10 Jul 2000 12:43:03 -0400 , <3969FD17.487DA96A@interet.com> Message-ID: <20000711215517.E9C71E2673@oratrix.oratrix.nl> Excuse my ignorance, but isn't the whole problem that the python 1.6 DLL is in the system search path even when you are running Python 1.7? MacPython solves this problem by keeping the PythonCore dll in the application directory, so it'll be found by a Python executable in the same directory but not by a python executable living elsewhere. And even if you import a dynamic module that was meant for and older or newer version of Python you'll get a decent error message: because all PythonCore's have the same name the imported module will link against the one already loaded and complain bitterly about missing externals (all assuming the current PythonCore and the module aren't compatible). This is a bit of a simplification, because MacOS doesn't really use the dll filename for matching the library, and there are extreme cases where you can end up with two PythonCore's in one process (but they don't happen to the average user), but this is the general idea.... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From gstein at lyra.org Wed Jul 12 00:03:11 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 15:03:11 -0700 Subject: [Python-Dev] O'Reilly conference In-Reply-To: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jul 11, 2000 at 05:20:38PM -0400 References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <20000711150311.V29590@lyra.org> On Tue, Jul 11, 2000 at 05:20:38PM -0400, Fred L. Drake, Jr. wrote: > > So who's going to the O'Reilly conference next week? The PythonLabs > crew expects to be there, and we just might have some goodies. ;) I'll be there Tue, Wed, Thu. Cheers, -g -- Greg Stein, http://www.lyra.org/ From pingster at ilm.com Wed Jul 12 00:02:17 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 15:02:17 -0700 (PDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <14699.33172.319800.354377@bitdiddle.concentric.net> Message-ID: On Tue, 11 Jul 2000, Jeremy Hylton wrote: > If we end up calling this new feature list comprehensions, we might > create the expectation that they behave like list comprehensions in > other languages. Good point. > >[ f x | x <- xs ] [...] > >[ (x,y) | x <- xs, y <- ys ] The closest translations for these i can imagine are [ f(x), for x in xs ] [ (x,y), for x in xs, for y in ys ] I'd say the above has to be about my favourite for ease of reading. I think the following grammar would work: listmaker: test [',' (list_iter | [test (',' test)* [',']])] list_iter: list_for | list_if list_for: 'for' exprlist 'in' testlist [',' list_iter] list_if: 'if' test [',' list_iter] -- ?!ng From paul at prescod.net Wed Jul 12 00:11:29 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 17:11:29 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> Message-ID: <396B9B91.E33D8C58@prescod.net> Thomas Wouters wrote: > > .... They provide an easier way to create a list, but they don't > eradicate the need for map, reduce or filter, because there is no way to > comprehend an already created list. What do you mean? I think I see examples of list comprehensions working on existing lists on this page: http://www.cosc.canterbury.ac.nz/~greg/python/listcomp/ numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] evens = [x for x in numbers if x % 2 == 0] # filter mult3 = [3 * x for x in numbers] # map Reduce is somewhat of a different beast... -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gstein at lyra.org Wed Jul 12 00:29:52 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 15:29:52 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.38892.155046.60218@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Jul 11, 2000 at 05:55:56PM -0400 References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> <14699.38892.155046.60218@anthem.concentric.net> Message-ID: <20000711152951.X29590@lyra.org> On Tue, Jul 11, 2000 at 05:55:56PM -0400, Barry A. Warsaw wrote: > > >>>>> "Gordo" == Gordon McMillan writes: > > Gordo> I'm with Barry here (despite the public humiliation the > Gordo> association involves). > > For both of us, of course. :) Looks like all of us scrappy long-hairs are in this together. :-) As I posted in another note: this stuff introduces too much confusion and unknowns, for a small benefit. Create parallel() or product() or whatever to munge the lists. Not new syntax. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Wed Jul 12 00:30:46 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 15:30:46 -0700 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <20000711215517.E9C71E2673@oratrix.oratrix.nl>; from jack@oratrix.nl on Tue, Jul 11, 2000 at 11:55:12PM +0200 References: <20000711215517.E9C71E2673@oratrix.oratrix.nl> Message-ID: <20000711153046.Y29590@lyra.org> On Tue, Jul 11, 2000 at 11:55:12PM +0200, Jack Jansen wrote: > Excuse my ignorance, but isn't the whole problem that the python 1.6 > DLL is in the system search path even when you are running Python 1.7? Yes, and as has been discussed endlessly before: it needs to be there. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Wed Jul 12 00:26:12 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 11 Jul 2000 18:26:12 -0400 Subject: [Python-Dev] patch assignments? In-Reply-To: <14699.23439.483525.515059@beluga.mojam.com> Message-ID: [Skip Montanaro] > I just noticed a patch assignment made to me on June 30th: > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100688&group_id=5470 > > with a comment from Tim on July 10th about it having been assigned to me. Correction: My comment was made on July 9th, which is also the day it got assigned to you (look at the topmost line of the Patch History section at the bottom). This is one of those patches that had just sat there since June 30th without anyone picking it up. On July 9th I went thru those and assigned (most of) them "at random". > In the flood of patch submissions and updates I guess I missed > this. Na, you noticed it within 48 hours > > The SF patch change mails say *nothing* as far as I can tell about what > the nature of the change of status of a patch is. That's right. It sucks. Best clue is whether you're *explicitly* listed on the "To" line. > With all changes going through the patches mailing list, more interesting > stuff can get lost in the sea of stuff I'm not particularly interested in. > Consequently, I would have hit 'd' seeing a subject like "Add 'isatty(fd)' > to posixmodule". I hit 'd' (well, my mailer's equivalent) for almost all patch mail coming from SF. Feel free to do the same! What I suggest instead: if you're a Python developer on SF, patches *will* eventually get assigned to you. So log on at least once a week, and view the patches filtering on your "Unix name" via the "User" dropdown list. Then you'll know exactly what's on your plate. And if you're not going to do it, take yourself off. Do the latter too often, though, and you'll probably get threatening email from Guido . > Has anyone asked SF for a more complete patch mailing? Dunno, but there's some hope we can discuss this w/ them in person in CA next week. The SF patch manager has more problems than just that for a project with as many active developers as Python. > If not, I will probably unsubscribe from patches at python.org so I can be > assured that those notices I get are actually for me. I wouldn't hold my breath waiting for large changes to SF's software. From jack at oratrix.nl Wed Jul 12 00:30:57 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 00:30:57 +0200 Subject: [Python-Dev] More Symantec symbols In-Reply-To: Message by Skip Montanaro , Mon, 10 Jul 2000 21:48:42 -0500 (CDT) , <14698.35594.999203.707698@beluga.mojam.com> Message-ID: <20000711223102.84CA0E2673@oratrix.oratrix.nl> Recently, Skip Montanaro said: > > Picking up where the __SC__ thread left off, I noticed the following other > Symantec symbols in the Python sources just now: > > ./Include/Python.h:48:#ifdef SYMANTEC__CFM68K__ > [...] > Should these be zapped as well or is this something wholely unrelated to the > old Symantec compiler issue? Yes, go ahead and zap them. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paul at prescod.net Wed Jul 12 00:48:05 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 17:48:05 -0500 Subject: [Python-Dev] list comprehensions again... References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> <14699.38892.155046.60218@anthem.concentric.net> <20000711152951.X29590@lyra.org> Message-ID: <396BA425.2EF3B11F@prescod.net> Greg Stein wrote: > > Looks like all of us scrappy long-hairs are in this together. :-) > > As I posted in another note: this stuff introduces too much confusion and > unknowns, for a small benefit. Create parallel() or product() or whatever to > munge the lists. Not new syntax. Parallel iteration and list comprehensions are separate. I do prefer a parallel() (merge?) builtin to the semicolon syntax, myself. You could even define xparallel which is the lazy version (as in xrange). There's no way you are going to invent functions that do everything that list comprehensions do, however. And compared to map and filter, list comprehensions are positively crystal clear. Would it help to think of list comprehensions not so much as a vote for a new idea as a vote AGAINST lambda, map and filter? numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] mult3 = [3 * x for x in numbers] evens = [x for x in numbers if x % 2 == 0] numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] mult3 = map( lambda x: 3 * x, numbers) evens = filter( lambda x: x%2==0, numbers) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From bwarsaw at beopen.com Wed Jul 12 01:02:06 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 19:02:06 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> Message-ID: <14699.42862.320480.372351@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> I agree that all this together looks dodgy, but I think there TW> is a simple way to view it... I still think TW> 'for x in a; y in b:' TW> is the right syntax for parallel for loops. It's almost "only" TW> syntactic sugar for TW> 'for x,y in map(None, a, b)' But wouldn't some variation on for x, y in a, b: invoke resonance with the classic idiom? Okay, now I'm reduced to arguing syntax (and syntax which I haven't thought out much :). TW> but it's fairly straightforward, and in large blocks of code TW> it might look a lot better. It also has the benifit of not TW> padding the shortest list to the size of the longest one: TW> getting that behaviour with a map requires an aditional TW> 'filter' or such. So I guess if that's the behavior I want, I'd use map, right? There's probably no good way to spell both. -Barry From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 01:35:54 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 01:35:54 +0200 (CEST) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.18899.148734.462266@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jul 11, 2000 12:22:43 PM Message-ID: <200007112335.BAA23181@python.inrialpes.fr> Fred L. Drake, Jr. wrote: > > I've attached a combined patch, in case any is interested. This > does not include updated documentation, and could use additional > tests. +1. Go ahaid. I'd make TabError -> TabSpaceError (like the C preprocessor symbol) though. > + static char > + TabError__doc__[] = "Improper mixture of spaces and tabs."; TabSpaceError__doc__[] = "Improper mixture of tabs and spaces."; -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Wed Jul 12 01:54:06 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 16:54:06 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.42862.320480.372351@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Jul 11, 2000 at 07:02:06PM -0400 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> <14699.42862.320480.372351@anthem.concentric.net> Message-ID: <20000711165406.A29590@lyra.org> On Tue, Jul 11, 2000 at 07:02:06PM -0400, Barry A. Warsaw wrote: > > >>>>> "TW" == Thomas Wouters writes: > > TW> I agree that all this together looks dodgy, but I think there > TW> is a simple way to view it... I still think > > TW> 'for x in a; y in b:' > > TW> is the right syntax for parallel for loops. It's almost "only" > TW> syntactic sugar for > > TW> 'for x,y in map(None, a, b)' > > But wouldn't some variation on > > for x, y in a, b: > > invoke resonance with the classic idiom? Okay, now I'm reduced to > arguing syntax (and syntax which I haven't thought out much :). for x, y in a, b: won't work. "a, b" is a tuple constructor. The for-loop will iterate over a two-item tuple, and unpack each item (a and b) into the x,y variables. Try again or punt :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From skip at mojam.com Wed Jul 12 00:28:04 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 17:28:04 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.31592.410628.754071@anthem.concentric.net> References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> Message-ID: <14699.40820.255217.346654@beluga.mojam.com> BAW> Range literals I can see as being worth it. I wonder if parallel BAW> for loops can't be handled more gracefully with a function -- isn't BAW> it just a nice wrapper around a specific call to map() anyway? I believe Thomas proposed range literals to avoid calling the range() function... Regarding a wrapper around map(), you will need a pretty hairy wrapper, since you can do some pretty complex things with Greg's version of list comprehensions. Here's the list comprehensions code from test_grammar.py: nums = [1, 2, 3, 4, 5] strs = ["Apple", "Banana", "Coconut"] spcs = [" Apple", " Banana ", "Coco nut "] print [s.strip() for s in spcs] print [3 * x for x in nums] print [x for x in nums if x > 2] print [i, s for i in nums for s in strs] print [i, s for i in nums for s in [f for f in strs if "n" in f]] suppliers = [ (1, "Boeing"), (2, "Ford"), (3, "Macdonalds") ] parts = [ (10, "Airliner"), (20, "Engine"), (30, "Cheeseburger") ] suppart = [ (1, 10), (1, 20), (2, 20), (3, 30) ] print [ (sname, pname) for (sno, sname) in suppliers for (pno, pname) in parts for (sp_sno, sp_pno) in suppart if sno == sp_sno and pno == sp_pno ] and what it produces: ['Apple', 'Banana', 'Coco nut'] [3, 6, 9, 12, 15] [3, 4, 5] [(1, 'Apple'), (1, 'Banana'), (1, 'Coconut'), (2, 'Apple'), (2, 'Banana'), (2, 'Coconut'), (3, 'Apple'), (3, 'Banana'), (3, 'Coconut'), (4, 'Apple'), (4, 'Banana'), (4, 'Coconut'), (5, 'Apple'), (5, 'Banana'), (5, 'Coconut')] [(1, 'Banana'), (1, 'Coconut'), (2, 'Banana'), (2, 'Coconut'), (3, 'Banana'), (3, 'Coconut'), (4, 'Banana'), (4, 'Coconut'), (5, 'Banana'), (5, 'Coconut')] [('Boeing', 'Airliner'), ('Boeing', 'Engine'), ('Ford', 'Engine'), ('Macdonalds', 'Cheeseburger')] Here's my equivalent code: 1. map(string.strip, spcs) 2. newnums = [] for n in nums: newnums.append(3*n) return newnums 3. newnums = [] for n in nums: if n > 2: newnums.append(n) return newnums 4. l = [] for i in nums: for s in strs: l.append((i,s)) return l 5. l = [] fl = [] for f in strs: if "n" in f: fl.append(f) for i in nums: for s in fl: l.append((i,s)) return l 6. ... the join is left as an exercise for the reader ... ;-) It seems like fairly powerful stuff and generally tends to reduce the amount of code the user writes. Is it more or less understandable than the current alternatives? That's the $64K question. I think in most cases it is. I think map and filter are more difficult to use and understand than the example list comprehensions from the test suite, but perhaps that's just my bias. I was never much of a Lisper, so it took me a good year or two before I got comfortable with anything more than the simplest uses of map. I probably still can't locate more than two or three instances in my own code where I've used filter. The nested for loops like the fourth and fifth examples seem to stretch out vertically and require the use of temporary variables that add complexity to the constructs. Skip From skip at mojam.com Wed Jul 12 00:30:43 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 17:30:43 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.42862.320480.372351@anthem.concentric.net> References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> <14699.42862.320480.372351@anthem.concentric.net> Message-ID: <14699.40979.693147.384500@beluga.mojam.com> BAW> So I guess if that's the behavior I want, I'd use map, right? BAW> There's probably no good way to spell both. Yes, but you probably map() and filter() in your sleep with your Lisp experience... ;-) S From pingster at ilm.com Wed Jul 12 02:01:24 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 17:01:24 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711165406.A29590@lyra.org> Message-ID: On Tue, 11 Jul 2000, Greg Stein wrote: > On Tue, Jul 11, 2000 at 07:02:06PM -0400, Barry A. Warsaw wrote: [...] > > But wouldn't some variation on > > > > for x, y in a, b: > > > > invoke resonance with the classic idiom? Okay, now I'm reduced to > > arguing syntax (and syntax which I haven't thought out much :). > > for x, y in a, b: > > won't work. "a, b" is a tuple constructor. The for-loop will iterate over a > two-item tuple, and unpack each item (a and b) into the x,y variables. That's why i suggested the above, with semicolons instead of commas. Other ideas for a separator symbol are welcomed... but i think the semicolon may be the only reasonable option left. -- ?!ng "We're going to turn this team around 360 degrees." -- Jason Kidd, upon being drafted by the Dallas Mavericks From skip at mojam.com Wed Jul 12 00:36:32 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 17:36:32 -0500 (CDT) Subject: [Python-Dev] O'Reilly conference In-Reply-To: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <14699.41328.521867.559541@beluga.mojam.com> Fred> So who's going to the O'Reilly conference next week? The Fred> PythonLabs crew expects to be there, and we just might have some Fred> goodies. ;) I wish I had known about it sooner (or realized the confluence of different streams in my life). Turns out I'm in San Francisco this week... Skip From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 02:11:06 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 02:11:06 +0200 (CEST) Subject: [Python-Dev] Memory leak tracking In-Reply-To: <14699.30119.262274.258429@anthem.concentric.net> from "Barry A. Warsaw" at Jul 11, 2000 03:29:43 PM Message-ID: <200007120011.CAA23273@python.inrialpes.fr> Barry A. Warsaw wrote: > > How important is it to fix these problems when gc is disabled? > ... > Please let me know what you think. If the concensus is to fix them, I > keep working on them. I do still plan on looking at the few memory > problems still left even with gc turned on. I think that if we start relaxing our attention w.r.t. refcount policies, cyclic refs and the resulting mem leaks _in_the_core_, just because gc helps in hiding bad practice, we'll suffer more than you would in the attempt to fix these things. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Wed Jul 12 02:09:31 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 17:09:31 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from pingster@ilm.com on Tue, Jul 11, 2000 at 05:01:24PM -0700 References: <20000711165406.A29590@lyra.org> Message-ID: <20000711170930.E29590@lyra.org> On Tue, Jul 11, 2000 at 05:01:24PM -0700, Ka-Ping Yee wrote: > On Tue, 11 Jul 2000, Greg Stein wrote: > > On Tue, Jul 11, 2000 at 07:02:06PM -0400, Barry A. Warsaw wrote: > [...] > > > But wouldn't some variation on > > > > > > for x, y in a, b: > > > > > > invoke resonance with the classic idiom? Okay, now I'm reduced to > > > arguing syntax (and syntax which I haven't thought out much :). > > > > for x, y in a, b: > > > > won't work. "a, b" is a tuple constructor. The for-loop will iterate over a > > two-item tuple, and unpack each item (a and b) into the x,y variables. > > That's why i suggested the above, with semicolons instead of commas. > Other ideas for a separator symbol are welcomed... but i think the > semicolon may be the only reasonable option left. hehe... I have another "reasonable option" :-) -- Greg Stein, http://www.lyra.org/ From nascheme at enme.ucalgary.ca Wed Jul 12 02:13:52 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 11 Jul 2000 18:13:52 -0600 Subject: [Python-Dev] Memory leak tracking In-Reply-To: <200007120011.CAA23273@python.inrialpes.fr>; from Vladimir Marangozov on Wed, Jul 12, 2000 at 02:11:06AM +0200 References: <14699.30119.262274.258429@anthem.concentric.net> <200007120011.CAA23273@python.inrialpes.fr> Message-ID: <20000711181352.A13655@keymaster.enme.ucalgary.ca> Perhaps gc.set_debug(gc.DEBUG_LEAK) would be helpful. Yes, real docs are coming. :) Neil From bwarsaw at beopen.com Wed Jul 12 02:20:44 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 20:20:44 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> <14699.38892.155046.60218@anthem.concentric.net> <20000711152951.X29590@lyra.org> <396BA425.2EF3B11F@prescod.net> Message-ID: <14699.47580.918825.55340@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Would it help to think of list comprehensions not so much as a PP> vote for a new idea as a vote AGAINST lambda, map and filter? If you mean specifically map/filter with lambda, yes. But map/filter with are pretty straightforward I think. It's the lambda that's confusing. -Barry From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 02:26:07 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 02:26:07 +0200 (CEST) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 11, 2000 03:03:12 PM Message-ID: <200007120026.CAA23349@python.inrialpes.fr> Guido van Rossum wrote: > > What do you think the following code would print? May I answer this? :-) > > for i in (10, 20, 30); j in (1, 2, 3): > print i+j > > A. > > 11 > 22 > 33 > > B. > 11 > 12 > 13 > 21 > 22 > 23 > 31 > 32 > 33 > > I'm afraid the answer will be the same, if these are again numerical > analysts -- these people live by nested DO loops. :-( Without being a numerical analyst, I would respond B. That's what this syntax suggests to me. Someone proposed `for ... while ...' which clearly suggests something different than nested loops, and in that case, if I don't know what it is, I'll read the docs. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From skip at mojam.com Wed Jul 12 00:57:25 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 17:57:25 -0500 (CDT) Subject: [Python-Dev] os.path.commonprefix testers needed for DOS, NT and Mac Message-ID: <14699.42581.843754.542783@beluga.mojam.com> Those of you with DOS, Windows/NT or Mac boxes, please take a look at the following patch: https://sourceforge.net/patch/?func=detailpatch&patch_id=100788&group_id=5470 It fixes posixpath.commonprefix to chunk its input by path components instead of by characters, so the prefix it returns should be a valid path. I can only check on Linux (I sort of expect other Unix variants will work as well). I corrected ntpath.py (which was the same as the version in posixpath.py) and added it to dospath.py and macpath.py. I can't really test any of them. Would those of you who can, please try it out and get back to me with a "yea" or a "nay" (with corrections, if possible)? Thanks, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From paul at prescod.net Wed Jul 12 02:35:13 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 19:35:13 -0500 Subject: [Python-Dev] list comprehensions again... References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> <14699.38892.155046.60218@anthem.concentric.net> <20000711152951.X29590@lyra.org> <396BA425.2EF3B11F@prescod.net> <14699.47580.918825.55340@anthem.concentric.net> Message-ID: <396BBD41.A68E4477@prescod.net> "Barry A. Warsaw" wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> Would it help to think of list comprehensions not so much as a > PP> vote for a new idea as a vote AGAINST lambda, map and filter? > > If you mean specifically map/filter with lambda, yes. But map/filter > with are pretty straightforward I think. It's the lambda that's > confusing. Okay, but at least half of the time I want to use map/filter I want to do: map( lambda x: x.foo(), lst ) Python is an OO-ish language after all! Anyhow, with list comprehensions we could dump map/filter and probably lambda. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Wed Jul 12 02:44:10 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 19:44:10 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> Message-ID: <396BBF5A.B22837C@prescod.net> Thomas Wouters wrote: > > ... > > Well, not really. It doesn't create a new list, only a tuple to hold lists > to iter over (in order to pass it to the opcode as a single PyObject) and > similar for the resulting objects. It's definately more efficient than the > map() solution (and different, see below ;) Nevertheless, I think it is worth asking whether a parallel() or merge() function can do the same thing. It's not like the semicolon syntax screams out the right answer. The parallel function could return an iteratable object that generates tuples on demand. A function can be used in contexts other than a for loop. If we make functions like parallel and range not only builtin but non-overridable, we can do all sorts of optimizations in the bytecode compiler (and other compilers). In other words we can "inline" them when they are used in simple contexts. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gstein at lyra.org Wed Jul 12 02:50:56 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 17:50:56 -0700 Subject: [Python-Dev] Memory leak tracking In-Reply-To: <200007120011.CAA23273@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Wed, Jul 12, 2000 at 02:11:06AM +0200 References: <14699.30119.262274.258429@anthem.concentric.net> <200007120011.CAA23273@python.inrialpes.fr> Message-ID: <20000711175056.I29590@lyra.org> On Wed, Jul 12, 2000 at 02:11:06AM +0200, Vladimir Marangozov wrote: > Barry A. Warsaw wrote: > > > > How important is it to fix these problems when gc is disabled? > > ... > > Please let me know what you think. If the concensus is to fix them, I > > keep working on them. I do still plan on looking at the few memory > > problems still left even with gc turned on. > > I think that if we start relaxing our attention w.r.t. refcount policies, > cyclic refs and the resulting mem leaks _in_the_core_, just because gc > helps in hiding bad practice, we'll suffer more than you would in the > attempt to fix these things. Agreed. The core should never create refcount problems. With or without GC, that is just bad policy. Cheers, -g -- Greg Stein, http://www.lyra.org/ From pingster at ilm.com Wed Jul 12 02:47:00 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 17:47:00 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396BBD41.A68E4477@prescod.net> Message-ID: On Tue, 11 Jul 2000, Paul Prescod wrote: > > map( lambda x: x.foo(), lst ) > > Python is an OO-ish language after all! Anyhow, with list comprehensions > we could dump map/filter and probably lambda. Yeah, that would be quite nice. [x.foo(), for x in lst] What beauty! -- ?!ng From petrilli at amber.org Wed Jul 12 02:57:37 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Tue, 11 Jul 2000 20:57:37 -0400 Subject: [Python-Dev] O'Reilly conference In-Reply-To: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jul 11, 2000 at 05:20:38PM -0400 References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <20000711205737.A20771@trump.amber.org> Fred L. Drake, Jr. [fdrake at beopen.com] wrote: > > So who's going to the O'Reilly conference next week? The PythonLabs > crew expects to be there, and we just might have some goodies. ;) A good number of the Digicool people will be there, including: - Me, and who else really matters, ya' know? :-) - Jim Fulton - Paul Everitt - Gary Graham And I think one or two other people are going :-) Chris -- | Christopher Petrilli | petrilli at amber.org From pingster at ilm.com Wed Jul 12 03:05:10 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 18:05:10 -0700 (PDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396BA425.2EF3B11F@prescod.net> Message-ID: On Tue, 11 Jul 2000, Paul Prescod wrote: > > Parallel iteration and list comprehensions are separate. I do prefer a > parallel() (merge?) builtin to the semicolon syntax, myself. You could > even define xparallel which is the lazy version (as in xrange). I like this idea. This whole parallel iteration thing could be solved with a single built-in and no syntax changes. for x, y in parallel([10, 20, 30], [1, 2]): Or "zip", since you're zipping the lists together (i foresee potential geometric or concurrency-related interpretations of "parallel"): for x, y in zip([10, 20, 30], [1, 2]): [(x, y+z), for (x, y) in zip((1, 2, 3, 4, 5, 6), "abc"), for z in "de"] Taking this all together provides one coherent solution: - zip() built-in produces a lazy list-zipper object - list-comps are written [, , , ...] where each is "for x in y" or "if z" Advantages: - no semicolons; semicolons remain solely statement separators - no possible confusion between parallel and nested iteration - comma remains the top-level separator within lists, so grouping of list-comp clauses is clear - dict-comp is possible and straightforward if we really want it - looks much prettier than map/lambda :) How's that for a serious proposal? -- ?!ng From akuchlin at cnri.reston.va.us Wed Jul 12 03:29:23 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 11 Jul 2000 21:29:23 -0400 Subject: [Python-Dev] O'Reilly conference In-Reply-To: <14699.41328.521867.559541@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 11, 2000 at 05:36:32PM -0500 References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> <14699.41328.521867.559541@beluga.mojam.com> Message-ID: <20000711212923.A15998@newcnri.cnri.reston.va.us> On a related note, is anyone else from python-dev going to be going to the Ottawa Linux Symposium nex week? --amk From gmcm at hypernet.com Wed Jul 12 03:58:02 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 11 Jul 2000 21:58:02 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396B8868.B58F3F0C@prescod.net> Message-ID: <1248755410-33702453@hypernet.com> Paul Prescod wrote: > Nested (List): > > [for x in (0,10,20,30): > for y in (0,1,2,3): > x+y] > [0,11,22,33] Not what I'd expect at all. - Gordon From gmcm at hypernet.com Wed Jul 12 03:58:02 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 11 Jul 2000 21:58:02 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: References: <20000711165406.A29590@lyra.org> Message-ID: <1248755408-33702560@hypernet.com> Ka-Ping Yee wrote: > On Tue, 11 Jul 2000, Greg Stein wrote: > > for x, y in a, b: > > > > won't work. "a, b" is a tuple constructor. The for-loop will > > iterate over a two-item tuple, and unpack each item (a and b) > > into the x,y variables. > > That's why i suggested the above, with semicolons instead of > commas. Other ideas for a separator symbol are welcomed... but i > think the semicolon may be the only reasonable option left. for x, y in a, b: for x, y in a; b: speechless-ly y'rs - Gordon From gmcm at hypernet.com Wed Jul 12 03:58:02 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 11 Jul 2000 21:58:02 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396BBD41.A68E4477@prescod.net> Message-ID: <1248755407-33702623@hypernet.com> Paul Prescod wrote: > Python is an OO-ish language after all! Anyhow, with list > comprehensions we could dump map/filter and probably lambda. I see more lambdas used in Tkinter code than anywhere else. Not a list in sight. - Gordon From esr at thyrsus.com Wed Jul 12 04:44:01 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 11 Jul 2000 22:44:01 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: References: <200007111440.JAA05205@cj20424-a.reston1.va.home.com> Message-ID: <20000711224401.A1107@thyrsus.com> Greg Wilson : > > Side note: the suggested syntax here (for i in seq1 for j in seq2) > > looks like a potential alternative for the currently proposed parallel > > for loop syntax (for i in seq1; j in seq2). > > > > Only problem: the for-for variant could be mistaken by someone used to > > see nested loops as meaning the same as > > > > for i in seq1: > > for j in seq2: ... > > Until yesterday's posting, I assumed that this is what for-for loops would > do, i.e. that they'd deliver a cross-product rather than one-from-each. This seems like the natural interpretation to me, also. I therefore prefer the semicolon sequence. -- Eric S. Raymond To stay young requires the unceasing cultivation of the ability to unlearn old falsehoods. -- Lazarus Long From esr at thyrsus.com Wed Jul 12 05:17:51 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 11 Jul 2000 23:17:51 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.12489.875905.520781@beluga.mojam.com> References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> <200007111440.JAA05205@cj20424-a.reston1.va.home.com> <14699.12489.875905.520781@beluga.mojam.com> Message-ID: <20000711231751.A1265@thyrsus.com> Skip Montanaro : > > Guido> [(x,y) for x in (1,2,3) for y in (4,5,6)] > Guido> Would it be really bad if we forced them to write it that way? > > For that matter, perhaps requiring parens for all tuple definitions in Py3k > wouldn't be a bad idea. +1. IMO, naked tuples assignments are Perlish -- initially cute, but confusing. Syntactic junk food. -- Eric S. Raymond The common argument that crime is caused by poverty is a kind of slander on the poor. -- H. L. Mencken From tim_one at email.msn.com Wed Jul 12 04:59:41 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 11 Jul 2000 22:59:41 -0400 Subject: [Python-Dev] Windows build broken in exceptions.c Message-ID: exceptions.c(93) : error C2026: string too big, trailing characters truncated Error executing cl.exe. The platform (MSVC6) docs for C2026: After adjacent strings are concatenated, a string cannot be longer than 2048 characters. However, those docs aren't accurate: if I break the giant docstring into two pieces, like so (implicitly concatenated): "sub-giant piece one" "sub-giant piece two" everything is fine. The compiler only gripes about a single string literal > 2K. I guessed that might be true because it seems more of a "catch runaway string" gimmick than a reasonable compiler limit. Anyway, I hesitate to check in that MSVC6 workaround if the same problem is just going to crop up on other platforms. Has it popped up for anyone else? One alternative is to keep strings short and paste them together at runtime in the module init fnc. From greg at cosc.canterbury.ac.nz Wed Jul 12 05:02:09 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 12 Jul 2000 15:02:09 +1200 (NZST) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711192202.B7340@xs4all.nl> Message-ID: <200007120302.PAA06664@s454.cosc.canterbury.ac.nz> Thomas Wouters wrote: > But the syntax is pretty ambiguous, and not > too pythonic at that. For instance, the endless mixing possibilities of > 'for' and 'if' without delimiters or ways to group them can be pretty > confusing. I don't think it's so confusing if you think about LCs the right way. You're meant to be able to think of them as a declarative construct, e.g. [(x, y) for x in a for y in b if y > 3] means "a list of all tuples (x, y) such that x is in a and y is in b and y > 3". Assuming no side effects, the result doesn't depend on what order the loops and tests are nested in, so (unless you're concerned about speed) you don't need to think in terms of loops at all, just a set of conditions. The syntax I chose was the most pythonic one I could think of that worked. It would probably look better with some sort of separator, but I wouldn't like to use anything stronger than a comma (semicolons inside a statement just don't look right to me), which means something like [(x, y) for x in a, for y in b, if y > 3] But then it looks a bit redundant having to repeat the 'for' each time, so you'd really want it to be more like [(x, y) for x in a, y in b, y > 3] which is hopelessly ambiguous. So I gave up on commas altogether. > it would be nice if list comprehensions could be used to initialize > *part* of a list, It would, but would the greatly increased implementation complexity be worth it? (And don't forget to allow range-literals the same privilege!-) > Can we get away with not including the nested-for syntax? I'd be really disappointed if LCs only made it in in such an emasculated form. It would remove a huge amount of their power, and I would have serious doubts that what was left would be worth bothering with. Heavens, next thing you know, someone will suggest adding a lambda without nested scoping... :-) > parallel-for-loops -> list comprehensions -> range-literals That's sensible, but I wouldn't like to see LCs get held up waiting for a consensus on PFLs to emerge. I think that if we just make sure that LCs and normal FLs share the same piece of compiler code, whatever is done to FLs later will get inherited by LCs automatically... sort of... Concerning PFLs, it seems to me that earlier language design decisions have pretty well scuttled any hope of coming up with a natural-looking and compatible PFL syntax. So we're going to have to settle for (a) an incompatible one, (b) an unnatural looking one, or (c) none at all. In category (b), my suggestion of the day is: for {var, ...} in expr e.g. for {x, y} in a, b Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 05:11:12 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 05:11:12 +0200 (CEST) Subject: [Python-Dev] Include/pyport.h now exists In-Reply-To: <20000708212149.P26534@xs4all.nl> from "Thomas Wouters" at Jul 08, 2000 09:21:50 PM Message-ID: <200007120311.FAA10295@python.inrialpes.fr> Thomas Wouters wrote: > > [Tim] > > Would someone who understands (& can test! I can't yet) autoconfig please > > follow up on the last part? The stuff I checked in "fails safe", i.e. the > > lack of autoconfig support should not cause problems on any of your > > platforms. > > Can't say I understand all of autoconf but I read enough of the info pages > to be able to do this ! :-) I couldn't find an existing test that covers > this, so I used your example to make one; patch attached. It detects my > linux box properly as 'doesn't zero-fill when right-shifting a negative > number', but I haven't a Cray J90 handy to test the opposite ;) > > Feel free to change the wording to something a bit less... wordy, though ;) > Oh, and don't forget to run autoheader & automake before checking in. I've checked this in, but I haven't figured out whether and how I could assign an open (non assigned) patch to myself and close it. If I am missing something, please let me know. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw at beopen.com Wed Jul 12 05:23:00 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 23:23:00 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> Message-ID: <14699.58516.791911.405213@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: BAW> Range literals I can see as being worth it. I wonder if BAW> parallel for loops can't be handled more gracefully with a BAW> function -- isn't it just a nice wrapper around a specific BAW> call to map() anyway? SM> I believe Thomas proposed range literals to avoid calling the SM> range() function... Right, and that seems totally cool to me. Simple syntax, clear semantics. SM> Regarding a wrapper around map(), you will need a pretty hairy SM> wrapper, since you can do some pretty complex things with SM> Greg's version of list comprehensions. I meant the parallel for loops as a shortcut for map(). List comprehensions do seem more powerful, however: | print [s.strip() for s in spcs] | print [3 * x for x in nums] Cool so far. | print [x for x in nums if x > 2] Uh oh, starting to look like Perl... | print [i, s for i in nums for s in strs] | print [i, s for i in nums for s in [f for f in strs if "n" in f]] Yow! No one will accuse Python of only having one way to do it anymore! Even without the curse-word-symbols, I fear excessive scalp exposing head-scratching when I see this in code. -Barry From bwarsaw at beopen.com Wed Jul 12 05:25:01 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 23:25:01 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <20000711165406.A29590@lyra.org> Message-ID: <14699.58637.724595.543978@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> That's why i suggested the above, with semicolons instead of KY> commas. Other ideas for a separator symbol are KY> welcomed... but i think the semicolon may be the only KY> reasonable option left. vertical bar? From jeremy at beopen.com Wed Jul 12 05:29:36 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 23:29:36 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.58516.791911.405213@anthem.concentric.net> References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> Message-ID: <14699.58912.789947.837917@bitdiddle.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: BAW> | print [i, s for i in nums for s in strs] BAW> | print [i, s for i in nums for s in [f for f in strs if "n" in f]] BAW> Yow! No one will accuse Python of only having one way to do it BAW> anymore! Even without the curse-word-symbols, I fear excessive BAW> scalp exposing head-scratching when I see this in code. I think these examples demonstrate the need for some punctuation, though perhaps not curse-word-symbols. I really like the vertical bar that Haskell uses to separate the variables being assigned to from the generator expression. It's a very familiar notation from mathematics. There also needs to be some punctuation to separate each generator expression when there is more than one. Commas and semicolons both seem reasonable viewed in isolation; commas are problematic because they are already used for tuple creation. Jeremy From akuchlin at cnri.reston.va.us Wed Jul 12 05:29:04 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 11 Jul 2000 23:29:04 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.58516.791911.405213@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Jul 11, 2000 at 11:23:00PM -0400 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> Message-ID: <20000711232904.A16338@newcnri.cnri.reston.va.us> On Tue, Jul 11, 2000 at 11:23:00PM -0400, Barry A. Warsaw wrote: >Yow! No one will accuse Python of only having one way to do it >anymore! Even without the curse-word-symbols, I fear excessive scalp >exposing head-scratching when I see this in code. Agreed; unless some clearer phrasing emerges, I'll vote -1 on list comprehensions, since they offer too much potential for obfuscation. --amk From bwarsaw at beopen.com Wed Jul 12 05:32:41 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 23:32:41 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> <396BBF5A.B22837C@prescod.net> Message-ID: <14699.59097.346202.496529@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Nevertheless, I think it is worth asking whether a parallel() PP> or merge() function can do the same thing. It's not like the PP> semicolon syntax screams out the right answer. The parallel PP> function could return an iteratable object that generates PP> tuples on demand. A function can be used in contexts other PP> than a for loop. Right. I think I'm beginning to like an explicit function (builtin or not) better than the syntax change. -Barry From gvwilson at nevex.com Wed Jul 12 05:33:51 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 23:33:51 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711234737.D7340@xs4all.nl> Message-ID: > Thomas Wouters wrote: > I still think > > 'for x in a; y in b:' > > is the right syntax for parallel for loops. It's almost "only" > syntactic sugar for > > 'for x,y in map(None, a, b)' > > but it's fairly straightforward, and in large blocks of code it might > look a lot better. Is there a built-in function in Python to combine sequences elementwise? If I can write: for x,y in pairwise(a, b): foo(x,y) and if the compiler is smart enough to avoid actually constructing the pairwise list, then perhaps new syntax is unnecessary? > Given that you can already do the nested-for-loop with a nested for > loop, and it doesn't suffer (much) in way of readability or pythonity, > I think most people will realize that the parallel for loop does > actually do a parallel for-each. I disagree. That doesn't mean people can't be taught/won't remember that multi-loops are executed in step, rather that by cross product, but I believe most people will guess wrong the first time they see the current notation. Thanks, Greg From fdrake at beopen.com Wed Jul 12 05:41:59 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 23:41:59 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure.in,1.134,1.135 In-Reply-To: <200007120302.UAA13467@slayer.i.sourceforge.net> References: <200007120302.UAA13467@slayer.i.sourceforge.net> Message-ID: <14699.59655.736149.252369@cj42289-a.reston1.va.home.com> Vladimir Marangozov writes: > Closes patch #100832 > (but I can't assign it to myself, nor close it -- sorry) Vladimir, I just checked your permissions for the patch manager, and everything is enabled. You should just be able to set the status and assignment in the pull-down menus at the top of the form, and the values are updated when you click on "Submit Changes" at the bottom of the page. Did this not work for you, or was it not clear that that's the way to do it? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Wed Jul 12 05:44:47 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 23:44:47 -0400 (EDT) Subject: [Python-Dev] zip() and list-comprehension with commas References: <396BA425.2EF3B11F@prescod.net> Message-ID: <14699.59823.710880.896491@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> I like this idea. This whole parallel iteration thing could KY> be solved with a single built-in and no syntax changes. KY> for x, y in parallel([10, 20, 30], [1, 2]): KY> Or "zip", since you're zipping the lists together (i foresee KY> potential geometric or concurrency-related interpretations of KY> "parallel"): Definitely +1 on concept. The nice bit is that parallel() or zip() can return objects that iterate efficiently. -0 on zip(), +0 on parallel(), +0 on making them builtins. Alternatives (as Greg I think brought up): pairwise(), maybe zipper() for zip() since it's more evocative. -Barry From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 05:53:30 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 05:53:30 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure.in,1.134,1.135 In-Reply-To: <14699.59655.736149.252369@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jul 11, 2000 11:41:59 PM Message-ID: <200007120353.FAA25150@python.inrialpes.fr> Fred L. Drake, Jr. wrote: > > Vladimir Marangozov writes: > > Closes patch #100832 > > (but I can't assign it to myself, nor close it -- sorry) > > Vladimir, > I just checked your permissions for the patch manager, and > everything is enabled. You should just be able to set the status and > assignment in the pull-down menus at the top of the form, and the > values are updated when you click on "Submit Changes" at the bottom of > the page. > Did this not work for you, or was it not clear that that's the way > to do it? The latter. Thanks for the clarification. I'll check this out. Besides, I think I screwed the logic of this patch as now I get a "no" answer while it should be "yes" on my combo. So I definitely need to assign this patch to myself and fix it! -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at beopen.com Wed Jul 12 07:50:27 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 00:50:27 -0500 Subject: [Python-Dev] Memory leak tracking In-Reply-To: Your message of "Tue, 11 Jul 2000 15:29:43 -0400." <14699.30119.262274.258429@anthem.concentric.net> References: <14699.30119.262274.258429@anthem.concentric.net> Message-ID: <200007120550.AAA12465@cj20424-a.reston1.va.home.com> Barry Warsaw: > When I compile out gc, I get more leaks in the core, namely in > exceptions.c. Turning on gc clears all of these up; e.g. all the > memory gets freed eventually. My suspicion therefore is that there > are a number of cycles created during the initialization of the > built-in exceptions. Vladimir Marangozov: > I think that if we start relaxing our attention w.r.t. refcount policies, > cyclic refs and the resulting mem leaks _in_the_core_, just because gc > helps in hiding bad practice, we'll suffer more than you would in the > attempt to fix these things. Let me explain something about the new GC code. It does *not* hide missed DECREFs. If you miss a DECREF, the GC code thinks there's a global pointer to the object that keeps it alive, and will not release the object. I don't know what Barry found, but I suspect they are genuine cycles created during the exception initialization. It's easy enough to create cycles, e.g. form module -> class -> function -> module, or module -> function -> module, when defining classes or functions. The new GC code is *intended* to clean up exactly such cycles! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From bwarsaw at beopen.com Wed Jul 12 07:05:52 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 01:05:52 -0400 (EDT) Subject: [Python-Dev] Memory leak tracking References: <14699.30119.262274.258429@anthem.concentric.net> <200007120550.AAA12465@cj20424-a.reston1.va.home.com> Message-ID: <14699.64688.697935.541901@anthem.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> I don't know what Barry found, but I suspect they are genuine GvR> cycles created during the exception initialization. It's GvR> easy enough to create cycles, e.g. form module -> class -> GvR> function -> module, or module -> function -> module, when GvR> defining classes or functions. GvR> The new GC code is *intended* to clean up exactly such GvR> cycles! I suspect this is exactly what's happening. I'd have to spend more time to know exactly what's happening, but this jives with the observed behavior. If so, the only thing we could do is try to break the cycles manually at shutdown time and have the normal decrefs free all the memory. I'm not sure it's worth the effort. 1) it isn't much memory; 2) it only leaks when gc is disabled; 3) it's a one time cost, not e.g. a leak every time you spawn a thread. That last is interesting, because I believe at least on Solaris, there /is/ a leak for each new thread, but I haven't had time to find it yet. That one's worth tracking down. For the others, it's actually quite nice to see gc doing it's job! Other than that, running the test suite, the current CVS seems to have a very clean bill of health memory usage-wise. -Barry From moshez at math.huji.ac.il Wed Jul 12 07:22:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 08:22:06 +0300 (IDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: Message-ID: On Tue, 11 Jul 2000, Ka-Ping Yee wrote: > On Tue, 11 Jul 2000, Paul Prescod wrote: > > > > Parallel iteration and list comprehensions are separate. I do prefer a > > parallel() (merge?) builtin to the semicolon syntax, myself. You could > > even define xparallel which is the lazy version (as in xrange). > > I like this idea. This whole parallel iteration thing could be solved > with a single built-in and no syntax changes. > > for x, y in parallel([10, 20, 30], [1, 2]): > > Or "zip", since you're zipping the lists together (i foresee potential > geometric or concurrency-related interpretations of "parallel"): +1 on prefering a builtin to a syntax change > for x, y in zip([10, 20, 30], [1, 2]): > > [(x, y+z), for (x, y) in zip((1, 2, 3, 4, 5, 6), "abc"), for z in "de"] +1 on that too...really clear -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 07:38:13 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 07:38:13 +0200 (CEST) Subject: [Python-Dev] Memory leak tracking In-Reply-To: <200007120550.AAA12465@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 12, 2000 12:50:27 AM Message-ID: <200007120538.HAA23814@python.inrialpes.fr> Guido van Rossum wrote: > > Let me explain something about the new GC code. It does *not* hide > missed DECREFs. If you miss a DECREF, the GC code thinks there's a > global pointer to the object that keeps it alive, and will not release > the object. > Sure. > I don't know what Barry found, but I suspect they are genuine cycles > created during the exception initialization. It's easy enough to > create cycles, e.g. form module -> class -> function -> module, or > module -> function -> module, when defining classes or functions. > > The new GC code is *intended* to clean up exactly such cycles! My point is that it is better not to rely on the GC code for the core if we're not crystal clear when and why cycles are created. And even if we spot them all (and mark these locations in the source), it is always better to try breaking the cycles explicitely. It's a fact that we're not crystal clear where all these cycles are created (be they genuine, easily introduced or not). This is not a good thing and I don't want to support the idea of tolerating this situation. I wish I had Purify to help Barry cleaning this up... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From moshez at math.huji.ac.il Wed Jul 12 08:00:53 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 09:00:53 +0300 (IDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711231751.A1265@thyrsus.com> Message-ID: On Tue, 11 Jul 2000 esr at thyrsus.com wrote: > Skip Montanaro : > > > > Guido> [(x,y) for x in (1,2,3) for y in (4,5,6)] > > Guido> Would it be really bad if we forced them to write it that way? > > > > For that matter, perhaps requiring parens for all tuple definitions in Py3k > > wouldn't be a bad idea. > > +1. IMO, naked tuples assignments are Perlish -- initially cute, but > confusing. Syntactic junk food. I disagree. That would make the readable def fib(n): a, b = 0, 1 for i in range(n): a, b = b, a+b return a, b old_rabbits, young_rabbits = fib(100) (Ditto for GCD) A mess of parenthesis. Commas build tuples. Parenthesis fix precedence. Never the two shall mix. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Wed Jul 12 08:09:11 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 09:09:11 +0300 (IDT) Subject: [Python-Dev] File Object Copy Message-ID: I've found a need for the following function: def copyfile(fin, fout): while 1: buf = fin.read(4096) if not buf: break fout.write(buf) In several different places (modules I've written, SimpleHTTPServer uses it, urllib has that code inlined somewhere, etc.) (Of course, 4096 should be a parameter, but that's nits) Can anyone suggest a module in which this function would belong? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From andy at reportlab.com Wed Jul 12 08:52:05 2000 From: andy at reportlab.com (Andy Robinson) Date: Wed, 12 Jul 2000 07:52:05 +0100 Subject: [Python-Dev] zlib not compiled by default Message-ID: At present, zlib is available in Win32, but users need to uncomment the line in Modules/Setup and recompile on Unix. ReportLab now has 100+ subscribed users in our user group (so I presume at least 5x more users), and we use zlib heavily to compress images and PDF files. It can run without it, but at the expense of bloated output. Are there many other applications which use compression? If so, would it do be feasible to include it by default from version 1.6? Andy Robinson p.s. I can submit a patch if needed :-) From pf at artcom-gmbh.de Wed Jul 12 09:13:32 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 12 Jul 2000 09:13:32 +0200 (MEST) Subject: [Python-Dev] File Object Copy In-Reply-To: from Moshe Zadka at "Jul 12, 2000 9: 9:11 am" Message-ID: Hi, Moshe Zadka: > I've found a need for the following function: > > def copyfile(fin, fout): > while 1: > buf = fin.read(4096) > if not buf: > break > fout.write(buf) > > In several different places (modules I've written, SimpleHTTPServer uses > it, urllib has that code inlined somewhere, etc.) > > (Of course, 4096 should be a parameter, but that's nits) > > Can anyone suggest a module in which this function would belong? A very similar function lives at a somewhat hidden flat in the third floor of the standard library building. ;-) It is called 'shutil.copyfile'. See '......html/lib/module-shutil.html' for more information. 'shutil.copyfile' however takes filenames as arguments and contains the loop sketched above as inline code. I see two possibilities: 1. It would be easy to skip the open and close operations in 'shutil.copyfile', if either 'src' or 'dst' are already open file objects instead of strings. 2. Or you factor out the copy loop operation above and rename it into 'copycontent' or 'copybytes' or whatever. Regards, Peter From moshez at math.huji.ac.il Wed Jul 12 09:21:08 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 10:21:08 +0300 (IDT) Subject: [Python-Dev] File Object Copy In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Peter Funk wrote: > 'shutil.copyfile' however takes filenames as arguments and contains > the loop sketched above as inline code. I see two possibilities: > 1. It would be easy to skip the open and close operations in > 'shutil.copyfile', if either 'src' or 'dst' are already open > file objects instead of strings. -0: Too much Perl-like DWIM magic > 2. Or you factor out the copy loop operation above and rename it into > 'copycontent' or 'copybytes' or whatever. Of course it should be factored out: but the question remains, why shell utils? Do you really think copybytes belongs there? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Wed Jul 12 09:26:02 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 09:26:02 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure.in,1.134,1.135 In-Reply-To: <200007120353.FAA25150@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Wed, Jul 12, 2000 at 05:53:30AM +0200 References: <14699.59655.736149.252369@cj42289-a.reston1.va.home.com> <200007120353.FAA25150@python.inrialpes.fr> Message-ID: <20000712092602.F7340@xs4all.nl> On Wed, Jul 12, 2000 at 05:53:30AM +0200, Vladimir Marangozov wrote: > Besides, I think I screwed the logic of this patch as now I get a "no" > answer while it should be "yes" on my combo. So I definitely need to > assign this patch to myself and fix it! Actually, almost everyone should see 'no' in response to the statement 'checking if signed-right-shift zero-fills', except for Cray J90's and possibly other strange hardware. In any case, if 'test_long' succeeds for you, all is well. If you want it to say 'yes' instead of 'no' and still mean the same thing, swap the logic, and change the question to 'whether right-shift pads with sign bit' or some such. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From ping at lfw.org Tue Jul 11 19:31:59 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Tue, 11 Jul 2000 10:31:59 -0700 (PDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> Message-ID: On Tue, 11 Jul 2000, Fred L. Drake, Jr. wrote: > At one point, we were discussing having specializations of > SyntaxError, and I posted a patch that defined IndentationError and > TabError. I guess the question is, will we ever want to catch or distinguish just IndentationError or TabError exceptions in particular from within a Python program? I can't personally think of any situations where i would need more detail than SyntaxError (whatever the error is, i'll just want to say "syntax error" and show the message)... unless... should the expected token type be passed *all* the way back to the user level so that e.g. an IDE can provide a UI hint as to how to correct the syntax error? -- ?!ng From pf at artcom-gmbh.de Wed Jul 12 09:52:42 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 12 Jul 2000 09:52:42 +0200 (MEST) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <14699.59823.710880.896491@anthem.concentric.net> from "Barry A. Warsaw" at "Jul 11, 2000 11:44:47 pm" Message-ID: Hi, Barry A. Warsaw: > >>>>> "KY" == Ka-Ping Yee writes: > > > KY> I like this idea. This whole parallel iteration thing could > KY> be solved with a single built-in and no syntax changes. > > KY> for x, y in parallel([10, 20, 30], [1, 2]): > > KY> Or "zip", since you're zipping the lists together (i foresee > KY> potential geometric or concurrency-related interpretations of > KY> "parallel"): > > Definitely +1 on concept. The nice bit is that parallel() or zip() > can return objects that iterate efficiently. -0 on zip(), +0 on > parallel(), +0 on making them builtins. +1 on the concept. -1 on calling it 'zip' (I was first thinking of Info ZIP and zlib). -0 on calling it 'parallel' (makes me thinking of threads and processes). What about calling this function 'permute()'? Here is a strawman to play with: def permute(*args): """takes several sequences as arguments and returns a list of tuples, where each tuple contains an element of each sequence permutated through all possible combinations.""" if len(args) == 1: return map(lambda x:(x,), args[0]) else: res = []; cdr = apply(permute, args[1:]) for left in args[0]: for right in cdr: res.append((left,) + right) return res for x, y in permute([10, 20, 30], [1, 2]): print "x, y =", x, y BTW: How comes, that Ping very often invents or introduces very clever ideas and concepts, but also very often chooses unclear names for them? Is it just me not being a native english speaker? Regards, Peter From peter at schneider-kamp.de Wed Jul 12 12:00:33 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 12 Jul 2000 10:00:33 +0000 Subject: [Python-Dev] zip() and list-comprehension with commas References: Message-ID: <396C41C1.5A1C7652@schneider-kamp.de> Ka-Ping Yee wrote: > > Taking this all together provides one coherent solution: > > - zip() built-in produces a lazy list-zipper object +1 on this. no performance hit (probably a small gain), "zip" is imho the right name (see e.g. haskell). also answers on c.l.py could be shorter, saving considerable bandwidth > > - list-comps are written [, , , ...] > where each is "for x in y" or "if z" +0.5 on the concept, some questions: -------------------------------------------------------------------- I know special character are evil, but in this case I think [ | , , ...] would be on order of magnitude easier to read. Why not? -------------------------------------------------------------------- Would [x,y , for x in list1, if x > 1, if y > 2, for y in list2] be allowed? In other words: Should there be some rules of ordering? What would the above list comprehension produce for list1 = list2 = [1, 2, 3]? -------------------------------------------------------------------- Would the following be allowed (and desirable)? y = 3 [ x + y , for x in [1, 2, 3], if x > 1] producing [5, 6] -------------------------------------------------------------------- I don't know Python's parser, so I am sorry if this is a non-issue: How does it resolve the ambiguity between [, , ...] and [, , , ...]? Especially something like [x, y, z, for x in l1, for y in l2, for z in l3] concerns me. -------------------------------------------------------------------- that's it for now, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From effbot at telia.com Wed Jul 12 10:14:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 10:14:42 +0200 Subject: [Python-Dev] SyntaxError patches References: Message-ID: <00ba01bfebd9$3cfb5c80$f2a6b5d4@hagrid> ping wrote: > On Tue, 11 Jul 2000, Fred L. Drake, Jr. wrote: > > At one point, we were discussing having specializations of > > SyntaxError, and I posted a patch that defined IndentationError and > > TabError. > > I guess the question is, will we ever want to catch or distinguish > just IndentationError or TabError exceptions in particular from > within a Python program? TabError maybe (retabify and try again -- but if you'll implement that, you might as well untabify before compiling), but I cannot see any reason to handle IndentationError. Also sucks from a documentation perspective... I'm -1 (on this part of the patch). > I can't personally think of any situations where i would need more > detail than SyntaxError (whatever the error is, i'll just want to > say "syntax error" and show the message)... unless... should the > expected token type be passed *all* the way back to the user level > so that e.g. an IDE can provide a UI hint as to how to correct the > syntax error? and in that case, the IDE won't be interested in actually showing the exception type to anyone... It's probably better to add extra info to the exception object, such as an "error tag" which is guaranteed to stay the same, no matter what the message is changed into (I'd love to have this in Python- Works, for example). guess it's time to grep for SyntaxError exceptions... From effbot at telia.com Wed Jul 12 10:19:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 10:19:23 +0200 Subject: [Python-Dev] Windows build broken in exceptions.c References: Message-ID: <00c401bfebd9$e6d347e0$f2a6b5d4@hagrid> tim wrote: > exceptions.c(93) : error C2026: string too big, trailing characters > truncated and incidentally, I just got: SyntaxError: expression too long from python. but back to the original topic: what does the ANSI standard say about this? what is, for example, the limits for integer arrays? (my unicode database experiments results in a couple of big ones. and for best performance, they really have to be that big...) From peter at schneider-kamp.de Wed Jul 12 12:16:54 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 12 Jul 2000 10:16:54 +0000 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: Message-ID: <396C4596.C64D4EE6@schneider-kamp.de> Peter Funk wrote: > > What about calling this function 'permute()'? -1 on this: We are not looking for all possible pairings but for the (possibly lazy) equivalent of map(None, list1, list2, ...). > BTW: How comes, that Ping very often invents or introduces very clever > ideas and concepts, but also very often chooses unclear names for them? > Is it just me not being a native english speaker? I still think "zip" is okay, but that's probably my Haskell background. And no, I don't think it has to do something with not being a native English speaker. It's probably more the context you associate with "zip". I can't comment on earlier cases, though. heading-to-work-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mwh21 at cam.ac.uk Wed Jul 12 10:27:50 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Wed, 12 Jul 2000 09:27:50 +0100 (BST) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Peter Funk wrote: > BTW: How comes, that Ping very often invents or introduces very > clever ideas and concepts, but also very often chooses unclear names > for them? Is it just me not being a native english speaker? In this case it's you not being a functional programmer; `zip' seems perfectly natural to the part of my brain that speaks Haskell. Think zip as in "zipper"; this more sense to me than naming a compression algorithm "zip"... Cheers, M. From pf at artcom-gmbh.de Wed Jul 12 10:27:01 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 12 Jul 2000 10:27:01 +0200 (MEST) Subject: [Python-Dev] SyntaxError patches In-Reply-To: from Ka-Ping Yee at "Jul 11, 2000 10:31:59 am" Message-ID: > On Tue, 11 Jul 2000, Fred L. Drake, Jr. wrote: > > At one point, we were discussing having specializations of > > SyntaxError, and I posted a patch that defined IndentationError and > > TabError. Ka-Ping Yee: > I guess the question is, will we ever want to catch or distinguish > just IndentationError or TabError exceptions in particular from > within a Python program? I don't believe this. > I can't personally think of any situations where i would need more > detail than SyntaxError (whatever the error is, i'll just want to > say "syntax error" and show the message)... unless... should the > expected token type be passed *all* the way back to the user level > so that e.g. an IDE can provide a UI hint as to how to correct the > syntax error? That sounds rather complicated anyway, but it would certainly be nice for people using (or should I say needing?) an IDE. BTW: The following mistake has happened to me to in the past (I'm using the VI improved editor unter X11): If cut'n'pasting methods around between classes, sometimes I unintentionally copy a space character too much, so that the 'def' of the copied method is intended one blank to much to the right. Hmmmm... I should make this clearer using an example: ### class Foo(Bar): def pasted_method(self, ....) #---^ note this additional blank here (resulting in a 5 space indent). # ...a screenful of indented code snipped here... def another_method(self, baz, bang): #--------------------------------------^ # Python 1.5.2 barfs here with "SyntaxError: invalid token" ### This is not very intuitive and hard to see. The first time I stumbled about this it has taken me quite some time to discover my mistake. I wonder, if the error message could be improved. That would be a very valuable improvement for newbies. However this example might proove that the idea an IDE would be able to provide UI-hints for fixing errors is doomed to fail in the general case. Regards, Peter. From ping at lfw.org Wed Jul 12 10:36:25 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 01:36:25 -0700 (PDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C41C1.5A1C7652@schneider-kamp.de> Message-ID: On Wed, 12 Jul 2000, Peter Schneider-Kamp wrote: > +1 on this. no performance hit (probably a small gain), > "zip" is imho the right name (see e.g. haskell). Indeed, a nice coincidence. :) > -------------------------------------------------------------------- > > I know special character are evil, but in this case I think > [ | , , ...] > would be on order of magnitude easier to read. Why not? Alas, the vertical bar is already a bitwise-or operator, and couldn't safely be placed next to the . Hmm. How much of that "order of magnitude" comes from "|" looking like the math notation, and how much from the mere fact that "|" is distinguished from ","? Semicolon might be worth considering here, actually: [f(x); for x in l] > -------------------------------------------------------------------- > > Would [x,y , for x in list1, if x > 1, if y > 2, for y in list2] > be allowed? In other words: Should there be some rules of ordering? > What would the above list comprehension produce for > list1 = list2 = [1, 2, 3]? I would say raise SyntaxError on this example. Also, the way you've written the example would depend on an existing variable named 'y' because you put "if y > 2" outside of "for y in list2". If the existing variable was <= 2, you'd get an empty list. For the following, i'm assuming you intended to put "if y > 2" last. As for the SyntaxError, i think it's a good idea because the example could be ambiguous. You would have to either say [(x, y), for x in list1, if x > 1, for y in list2, if y > 2] or [x] + [y, for x in list1, if x > 1, for y in list2, if y > 2] The first would produce [(2, 3), (3, 3)], and the second would depend on the initial value of x and look like [x, 3, 3]. > -------------------------------------------------------------------- > > Would the following be allowed (and desirable)? > y = 3 > [ x + y , for x in [1, 2, 3], if x > 1] > producing [5, 6] Absolutely. > -------------------------------------------------------------------- > > I don't know Python's parser, so I am sorry if this is a non-issue: > How does it resolve the ambiguity between > [, , ...] and [, , , ...]? > Especially something like > [x, y, z, for x in l1, for y in l2, for z in l3] concerns me. I guess it depends how the argument about parens-around-tuples finally resolves, but personally i'd say that more than one expr before an attempted iteration clause should cause a SyntaxError. It would have to be written: [(x, y, z), for x in l1, for y in l2, for z in l3] -- ?!ng From mal at lemburg.com Wed Jul 12 10:32:00 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 12 Jul 2000 10:32:00 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: <396C4596.C64D4EE6@schneider-kamp.de> Message-ID: <396C2D00.BDA23AF2@lemburg.com> Peter Schneider-Kamp wrote: > > Peter Funk wrote: > > > > What about calling this function 'permute()'? > > -1 on this: We are not looking for all possible pairings but for the > (possibly lazy) equivalent of map(None, list1, list2, ...). > > > BTW: How comes, that Ping very often invents or introduces very clever > > ideas and concepts, but also very often chooses unclear names for them? > > Is it just me not being a native english speaker? > > I still think "zip" is okay, but that's probably my Haskell background. > And no, I don't think it has to do something with not being a native > English speaker. It's probably more the context you associate with > "zip". > I can't comment on earlier cases, though. Just for completeness: mx.Tools already has these APIs: tuples(sequence) Returns much the same as apply(map,(None,)+tuple(sequence)) does, except that the resulting list will always have the length of the first sub-sequence in sequence. The function returns a list of tuples (a[0], b[0], c[0],...), (a[1], b[1], c[1],...), ... with missing elements being filled in with None. Note that the function is of the single argument type meaning that calling tuples(a,b,c) is the same as calling tuples((a,b,c)). tuples() can be used as inverse to lists(). lists(sequence) Same as tuples(sequence), except that a tuple of lists is returned. Can be used as inverse to tuples(). and these have also proven useful: dict(items) Constructs a dictionary from the given items sequence. The sequence items must contain sequence entries with at least two values. The first one is interpreted as key, the second one as associated object. Remaining values are ignored. irange(object[,indices]) Builds a tuple of tuples (index,object[index]). If a sequence indices is given, the indices are read from it. If not, then the index sequence defaults to trange(len(object)). Note that object can be any object that can handle object[index], e.g. lists, tuples, string, dictionaries, even your own objects, if they provide a __getitem__-method. This makes very nifty constructions possible and extracting items from another sequence becomes a piece of cake. Give it a try ! You'll soon love this little function. indices(object) Returns the same as tuple(range(len(object))) -- a tad faster and a lot easier to type. I'm sure Python could steal a few of those ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Wed Jul 12 10:37:53 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 01:37:53 -0700 Subject: [Python-Dev] Memory leak tracking In-Reply-To: <14699.64688.697935.541901@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 12, 2000 at 01:05:52AM -0400 References: <14699.30119.262274.258429@anthem.concentric.net> <200007120550.AAA12465@cj20424-a.reston1.va.home.com> <14699.64688.697935.541901@anthem.concentric.net> Message-ID: <20000712013753.P29590@lyra.org> On Wed, Jul 12, 2000 at 01:05:52AM -0400, Barry A. Warsaw wrote: >... > I suspect this is exactly what's happening. I'd have to spend more > time to know exactly what's happening, but this jives with the > observed behavior. If so, the only thing we could do is try to break > the cycles manually at shutdown time and have the normal decrefs free > all the memory. > > I'm not sure it's worth the effort. 1) it isn't much memory; 2) it > only leaks when gc is disabled; 3) it's a one time cost, not > e.g. a leak every time you spawn a thread. > > That last is interesting, because I believe at least on Solaris, there > /is/ a leak for each new thread, but I haven't had time to find it > yet. That one's worth tracking down. For the others, it's actually > quite nice to see gc doing it's job! > > Other than that, running the test suite, the current CVS seems to have > a very clean bill of health memory usage-wise. Please try to consider the embedded case, too. If Python interpreters are created/destroyed, or modules are loaded/thrown out, or whatever... are there leaks? Any leak can be a disaster in embedded cases. Now... no need to be defensive :-) ... just pointing out there is another consideration when thinking about leaks. Cheers, -g -- Greg Stein, http://www.lyra.org/ From ping at lfw.org Wed Jul 12 10:40:55 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 01:40:55 -0700 (PDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Peter Funk wrote: > ### > class Foo(Bar): > def pasted_method(self, ....) > #---^ note this additional blank here (resulting in a 5 space indent). > # ...a screenful of indented code snipped here... > def another_method(self, baz, bang): > #--------------------------------------^ > # Python 1.5.2 barfs here with "SyntaxError: invalid token" > ### > > This is not very intuitive and hard to see. The first time I stumbled > about this it has taken me quite some time to discover my mistake. Gee. Well, with the SyntaxError patch, at least the error message is much better (even though the arrow still points to the wrong place): >>> class foo: ... def foo(self): ... pass ... def foo(bar): File "", line 4 def foo(bar): ^ SyntaxError: dedent does not match any outer indentation level Not sure why the arrow points there... i would have expected it to point at the beginning of the line, since it did successfully detect that the indentation was wrong. Maybe i'll investigate. -- ?!ng From effbot at telia.com Wed Jul 12 10:41:47 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 10:41:47 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: Message-ID: <00fc01bfebdd$05eed060$f2a6b5d4@hagrid> michael wrote: > > In this case it's you not being a functional programmer; `zip' seems > perfectly natural to the part of my brain that speaks Haskell. > > Think zip as in "zipper"; this more sense to me than naming a compression > algorithm "zip"... > footnote: merriam webster says: ... 1. to move, act, or function with speed and vigor ... 5. to close or open with or as if with a zipper ... I also checked two british dictionaries; the older only mentioned the first sense, the newer only the second. fwiw, the newer claims to be based on a "detailed ana- lysis of how modern English is really used". go figure. From mal at lemburg.com Wed Jul 12 10:36:38 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 12 Jul 2000 10:36:38 +0200 Subject: [Python-Dev] APIs for internal flags References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <200007101722.MAA01227@cj20424-a.reston1.va.home.com> <396A08AF.655B4836@lemburg.com> <200007101936.OAA02180@cj20424-a.reston1.va.home.com> Message-ID: <396C2E16.38DAAE58@lemburg.com> Guido van Rossum wrote: > > > Yes... I meant: it is not available from Python. (mx.Tools > > publishes an interface to this flag: sys.verbosity() which > > also allows setting the value at runtime.) > > It would make a lot of sense for the sys module to allow access to the > values of all the Python command line options, and perhaps to allow > changing them. > > Anybody interested in designing an API here? Some requirements would > be platform independence, extensibility, and necessarily the ability > to work even in an environment without command line flags (since it > still has the corresponding internal flags). For starters, here's what mx.Tools defines: sys.verbosity([level]) If level is given, the value of the interpreter's verbosity flag is set to level and the previous value of that flag is returned. Otherwise, the current value is returned. You can use this function to e.g. enable verborse lookup output to stderr for import statements even when the interpreter was not invoked with '-v' or '-vv' switch or to force verbosity to be switched off. sys.debugging([level]) If level is given, the value of the interpreter's debugging flag is set to level and the previous value of that flag is returned. Otherwise, the current value is returned. You can use this function to check whether the interpreter was called with '-d' flag or not. Some extensions use this flag to enable/disable debugging log output (e.g. all the mx Extensions). sys.optimization([level]) If level is given, the value of the interpreter's optimization flag is set to level and the previous value of that flag is returned. Otherwise, the current value is returned. You can use this function to e.g. compile Python scripts in optimized mode even though the interpreter was not started with -O. Perhaps a more generic interface would be nicer, but given that not all flags are really useful and some of them may not be altered after initialization, I find the per flag interfaces fit rather well (they also have the advantage of being able to add code on a per flag basis, which may become useful for future additions). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Wed Jul 12 10:43:38 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 01:43:38 -0700 Subject: [Python-Dev] File Object Copy In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jul 12, 2000 at 10:21:08AM +0300 References: Message-ID: <20000712014338.Q29590@lyra.org> On Wed, Jul 12, 2000 at 10:21:08AM +0300, Moshe Zadka wrote: > On Wed, 12 Jul 2000, Peter Funk wrote: > > 'shutil.copyfile' however takes filenames as arguments and contains > > the loop sketched above as inline code. I see two possibilities: > > 1. It would be easy to skip the open and close operations in > > 'shutil.copyfile', if either 'src' or 'dst' are already open > > file objects instead of strings. > > -0: Too much Perl-like DWIM magic > > > 2. Or you factor out the copy loop operation above and rename it into > > 'copycontent' or 'copybytes' or whatever. > > Of course it should be factored out: but the question remains, why shell > utils? Do you really think copybytes belongs there? Add shutil.copyfileob(src_file_ob, dst_file_ob). shutil.copyfile() can call it after opening the files. Does that function make absolute sense there? Tough question. It sure happens to work well, considered the dependent function copyfile(). I imagine there are a bazillion functions that could be re-factored. No sense getting overly concerned. Put the bugger in shutil for now. Step two: propose a new organization. Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul at prescod.net Wed Jul 12 10:52:41 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 03:52:41 -0500 Subject: [Python-Dev] list comprehensions again... References: <1248755410-33702453@hypernet.com> Message-ID: <396C31D9.4658CFD7@prescod.net> Gordon McMillan wrote: > > Paul Prescod wrote: > > > Nested (List): > > > > [for x in (0,10,20,30): > > for y in (0,1,2,3): > > x+y] > > [0,11,22,33] > > Not what I'd expect at all. No, I'm just an idiot. What you expect is what I meant. No excuse. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Wed Jul 12 11:04:27 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 11:04:27 +0200 Subject: [Python-Dev] File Object Copy References: <20000712014338.Q29590@lyra.org> Message-ID: <011401bfebe0$2f388c60$f2a6b5d4@hagrid> moshe wrote: > > > 1. It would be easy to skip the open and close operations in > > > 'shutil.copyfile', if either 'src' or 'dst' are already open > > > file objects instead of strings. > > > > -0: Too much Perl-like DWIM magic footnote: it's definitely an accepted pydiom: aifc.py: if type(f) == type(''): f = __builtin__.open(f, 'rb') binhex.py: if type(ofp) == type(''): ofname = ofp ofp = open(ofname, 'w') mimify.py: if type(infile) == type(''): ifile = open(infile) pstats.py: elif type(arg) == type(""): f = open(arg, 'rb') etc. it's a reasonable way to make your code a bit more reusable (it's rude to expect every chunk of potentially usable data to have a filename...). From peter at schneider-kamp.de Wed Jul 12 12:59:09 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 12 Jul 2000 10:59:09 +0000 Subject: [Python-Dev] zip() and list-comprehension with commas References: Message-ID: <396C4F7D.288B561D@schneider-kamp.de> Ka-Ping Yee wrote: > > On Wed, 12 Jul 2000, Peter Schneider-Kamp wrote: > > +1 on this. no performance hit (probably a small gain), > > "zip" is imho the right name (see e.g. haskell). > > Indeed, a nice coincidence. :) off-topic: I am still thinking about higher order functions in Python: e.g.: map(+ 1, [1, 2, 3]) instead of map(lambda x: x + 1, [1, 2, 3]) don't have a clue how to do that yet. > Alas, the vertical bar is already a bitwise-or operator, and > couldn't safely be placed next to the . [...] > Semicolon might be worth considering here, actually: [f(x); for x in l] Better than just a comma anyway. Okay for me. > [(x, y), for x in list1, if x > 1, for y in list2, if y > 2] [...] > The first would produce [(2, 3), (3, 3)], and the second would > It would have to be written: > > [(x, y, z), for x in l1, for y in l2, for z in l3] but that's loosing some of it's beauty for me. if we'd use the semicolon [ x, y, z; for x in l1, for y in l2, for z in l3] looks better to me. okay, really heading off to work now, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From moshez at math.huji.ac.il Wed Jul 12 11:06:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 12:06:06 +0300 (IDT) Subject: [Python-Dev] File Object Copy In-Reply-To: <20000712014338.Q29590@lyra.org> Message-ID: On Wed, 12 Jul 2000, Greg Stein wrote: > Add shutil.copyfileob(src_file_ob, dst_file_ob). shutil.copyfile() can call > it after opening the files. Done. Can someone who is able to checkin assign it to themselves? > Does that function make absolute sense there? Tough question. It sure > happens to work well, considered the dependent function copyfile(). I > imagine there are a bazillion functions that could be re-factored. No sense > getting overly concerned. > > Put the bugger in shutil for now. Step two: propose a new organization. Hmmmm...orthogonal to new organization, urllib and BaseHTTPServer need to be modified to call it. I'll do it as soon as the patch is accepted (100868) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Wed Jul 12 11:08:26 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 12:08:26 +0300 (IDT) Subject: [Python-Dev] File Object Copy In-Reply-To: <011401bfebe0$2f388c60$f2a6b5d4@hagrid> Message-ID: On Wed, 12 Jul 2000, Fredrik Lundh wrote: > footnote: it's definitely an accepted pydiom: Yes, but one I personally do not like > > aifc.py: > if type(f) == type(''): > f = __builtin__.open(f, 'rb') > > binhex.py: > if type(ofp) == type(''): > ofname = ofp > ofp = open(ofname, 'w') > > mimify.py: > if type(infile) == type(''): > ifile = open(infile) > > pstats.py: > elif type(arg) == type(""): > f = open(arg, 'rb') > > etc. > > it's a reasonable way to make your code a bit more reusable > (it's rude to expect every chunk of potentially usable data to > have a filename...). Of course -- that's why I think most code should use file-like objects. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul at prescod.net Wed Jul 12 11:25:33 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:25:33 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> Message-ID: <396C398D.9F85F8A8@prescod.net> "Barry A. Warsaw" wrote: > [Python is becoming Perl] > | print [i, s for i in nums for s in strs] Let me try my syntax on this example: print [for i in nums: for s in strs: i, s] I don't see that as being any worse than the procedural syntax. > | print [i, s for i in nums for s in [f for f in strs if "n" in f]] I don't see this as being a realistic example. First, let me ask whether you think that reasonable programmers are actually going to come up with this. Why wouldn't they use a temporary variable for s? When nesting gets deep, reasonable programmers try to unroll it, whether it is in a.b.c.d.e or a(b(c(d(e())))) or list comps. In fact, we know that most UNreasonable programmers can be swayed with arguments from efficiency. You are computing the value of s over and over again "num" times. It makes no sense to do it that way. I think that my syntax would make this clearer (of course I would!): print [ for i in nums: for s in [for f in strs: if "n" in f: f] (i,s)] You can see that nothing from the outer loop is being used in the inner one, so what's the point in having it there? Better: s=[for f in strs: if "n" in f: f] print [for i in nums: (i,s)] Which to me is a nicer way of saying what we today say as: map( None, nums, [s]*len(nums)] If you want to confuse a newbie, I'll claim that the "map" version will do it more than the list comp. version. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From ping at lfw.org Wed Jul 12 11:35:21 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 02:35:21 -0700 (PDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Peter Funk wrote: > > BTW: How comes, that Ping very often invents or introduces very clever > ideas and concepts, Gee, thanks. :) I feel a group hug coming on. > but also very often chooses unclear names for them? > Is it just me not being a native english speaker? I don't know. Perhaps my florx bignal zupkin isn't very moognacious? Shlarp mixon ru, but tralorping weefibbledon groxit zanquar bladu. Bladu bladu. Woom! Greefon sip habligor? (Chalar icko neevour, & blafare ort lirriless.) Bladiblipifiribble a wompy idea: >>> def klaatu(): # Verata nikto. ... phwee File "", line 2 phwee ^ HolyGrailError: see the violence inherent in the system Ruinon flast. Elninfrawok? - Glidimon. - Fip milang freebik. Ip nane (varblig nane) refilk ruzzin. - Zom plut 'klaatu()' ix 'klaatu(spam)' etc. - Hilliban dreef? Neems 'ploo' girdar oioizoik: >>> 3 3 >>> 4 4 >>> 5 HolyGrailError: five is right out >>> [1:4] [1, 2, 5] Jodinat greidar fablo! Ruinon flast; ruinon flast. Thorvon whananadak yum, onk triplation is dortiful. <0.5 wink> Ecky-ecky-ecky-ecky-pikang-zoop-boing? -- ?!ng From paul at prescod.net Wed Jul 12 11:29:30 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:29:30 -0500 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: Message-ID: <396C3A7A.75CA43B3@prescod.net> Peter Funk wrote: > > ... > > +1 on the concept. > -1 on calling it 'zip' (I was first thinking of Info ZIP and zlib). > -0 on calling it 'parallel' (makes me thinking of threads and processes). > > What about calling this function 'permute()'? But zip is not permute! zip( [0,1,2,3,4],[0,10,20,30,40])=[0,11,22,33,44] Anyhow, I kind of like the names tuples() and lists(), as proposed by MAL. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From ping at lfw.org Wed Jul 12 11:47:16 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 02:47:16 -0700 (PDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <396C3A7A.75CA43B3@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > > But zip is not permute! > > zip( [0,1,2,3,4],[0,10,20,30,40])=[0,11,22,33,44] You mean zip([0,1,2,3,4], [0,10,20,30,40]) -> [(0,0), (1,10), (2,20), (3,30), (4,40)] (It's late... maybe we all need some sleep.) :) -- ?!ng From paul at prescod.net Wed Jul 12 11:41:43 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:41:43 -0500 Subject: [Python-Dev] zip() and list-comprehension with commas References: <396C41C1.5A1C7652@schneider-kamp.de> Message-ID: <396C3D57.61328C2D@prescod.net> Peter Schneider-Kamp wrote: > > > Would [x,y , for x in list1, if x > 1, if y > 2, for y in list2] > be allowed? In other words: Should there be some rules of ordering? Would this syntax make the answer clearer: [for x in list1: if x > 1: if y > 2: for y in list2: x,y] I don't think that makes sense unless y is externally bound. > Would the following be allowed (and desirable)? > y = 3 > [ x + y , for x in [1, 2, 3], if x > 1] > producing [5, 6] y = 3 [for x in [1, 2, 3]: if x > 1: x + y] Sure, getting around Python's name binding "issues" is one of the (side) benefits of list comprehensions. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From jack at oratrix.nl Wed Jul 12 11:44:46 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 11:44:46 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message by Michael Hudson , Wed, 12 Jul 2000 09:27:50 +0100 (BST) , Message-ID: <20000712094447.2275337186D@snelboot.oratrix.nl> parallel()/zip() have an other advantage: it would be easy to extend to let the loop continue until the longest of the items, with a keyword argument: parallel((1, 2), (3, 4, 5), missing=None) # or extend, or some other name would return ((1, 3), (2, 4), (None, 5)) By the way: -1 on the name zip() and -0 on the name parallel(), but +1 on the concept. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paul at prescod.net Wed Jul 12 11:44:07 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:44:07 -0500 Subject: [Python-Dev] zip() and list-comprehension with commas References: Message-ID: <396C3DE7.367B569D@prescod.net> Ka-Ping Yee wrote: > > > As for the SyntaxError, i think it's a good idea because the > example could be ambiguous. You would have to either say > > [(x, y), for x in list1, if x > 1, for y in list2, if y > 2] > > or > > [x] + [y, for x in list1, if x > 1, for y in list2, if y > 2] The easy way to avoid the ambiguity is to dump the comma and use colons as Guido intended. [for x in list1: if x > 1: for y in list2: if y > 2: (x,y)] -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From jack at oratrix.nl Wed Jul 12 11:49:56 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 11:49:56 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message by Ka-Ping Yee , Wed, 12 Jul 2000 02:35:21 -0700 (PDT) , Message-ID: <20000712094956.A456437186D@snelboot.oratrix.nl> > Ecky-ecky-ecky-ecky-pikang-zoop-boing? > > > -- ?!ng Shouldn't that be "Ecky-ecky-ecky-ecky-pikang-zoop-boing'ly yours," ? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paul at prescod.net Wed Jul 12 11:55:11 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:55:11 -0500 Subject: [Python-Dev] New builtins References: <396C4596.C64D4EE6@schneider-kamp.de> <396C2D00.BDA23AF2@lemburg.com> Message-ID: <396C407F.CAB2584A@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Just for completeness: mx.Tools already has these APIs: > > tuples(sequence) > Returns much the same as apply(map,(None,)+tuple(sequence)) does, Like it. > lists(sequence) > Same as tuples(sequence), except that a tuple of lists is returned. Like it. > dict(items) > Constructs a dictionary from the given items sequence. Like it. In my opinion, these are naturals for built-in functions. Cool! These I'm not as sure about: > irange(object[,indices]) > Builds a tuple of tuples (index,object[index]). Isn't this just tuples( indices( object ), object ) > indices(object) > Returns the same as tuple(range(len(object))) -- Could be obsoleted by the range-building syntax: [0..len(object)] would do the same thing. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gstein at lyra.org Wed Jul 12 12:01:56 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:01:56 -0700 Subject: [Python-Dev] File Object Copy In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jul 12, 2000 at 12:06:06PM +0300 References: <20000712014338.Q29590@lyra.org> Message-ID: <20000712030156.U29590@lyra.org> On Wed, Jul 12, 2000 at 12:06:06PM +0300, Moshe Zadka wrote: > On Wed, 12 Jul 2000, Greg Stein wrote: > > > Add shutil.copyfileob(src_file_ob, dst_file_ob). shutil.copyfile() can call > > it after opening the files. > > Done. Can someone who is able to checkin assign it to themselves? Checked in, and the patch is now closed. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Wed Jul 12 12:05:56 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:05:56 -0700 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: ; from ping@lfw.org on Wed, Jul 12, 2000 at 02:35:21AM -0700 References: Message-ID: <20000712030556.V29590@lyra.org> All right. Now this is just whacked. "Step *away* from the drugs and nobody will get hurt." Damn, Ping. You rock. -g On Wed, Jul 12, 2000 at 02:35:21AM -0700, Ka-Ping Yee wrote: > On Wed, 12 Jul 2000, Peter Funk wrote: > > > > BTW: How comes, that Ping very often invents or introduces very clever > > ideas and concepts, > > Gee, thanks. :) I feel a group hug coming on. > > > but also very often chooses unclear names for them? > > Is it just me not being a native english speaker? > > I don't know. Perhaps my florx bignal zupkin isn't very moognacious? > > Shlarp mixon ru, but tralorping weefibbledon groxit zanquar bladu. > Bladu bladu. Woom! Greefon sip habligor? (Chalar icko neevour, & > blafare ort lirriless.) > > Bladiblipifiribble a wompy idea: > > >>> def klaatu(): # Verata nikto. > ... phwee > File "", line 2 > phwee > ^ > HolyGrailError: see the violence inherent in the system > > Ruinon flast. Elninfrawok? > > - Glidimon. > - Fip milang freebik. Ip nane (varblig nane) refilk ruzzin. > - Zom plut 'klaatu()' ix 'klaatu(spam)' etc. > - Hilliban dreef? > > Neems 'ploo' girdar oioizoik: > > >>> 3 > 3 > >>> 4 > 4 > >>> 5 > HolyGrailError: five is right out > >>> [1:4] > [1, 2, 5] > > Jodinat greidar fablo! Ruinon flast; ruinon flast. Thorvon > whananadak yum, onk triplation is dortiful. <0.5 wink> > > Ecky-ecky-ecky-ecky-pikang-zoop-boing? > > > -- ?!ng > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Wed Jul 12 12:10:48 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:10:48 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396C398D.9F85F8A8@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 04:25:33AM -0500 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> <396C398D.9F85F8A8@prescod.net> Message-ID: <20000712031048.W29590@lyra.org> On Wed, Jul 12, 2000 at 04:25:33AM -0500, Paul Prescod wrote: >... > If you want to confuse a newbie, I'll claim that the "map" version will > do it more than the list comp. version. Just because map() might confuse people doesn't mean it is now okay to introduce *more* confusion. "Gee, officer... there isn't a law against driving stoned. So I figured driving all whacked out on heroin is okay, too." Cheers, -g -- Greg Stein, http://www.lyra.org/ From ping at lfw.org Wed Jul 12 12:14:54 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 03:14:54 -0700 (PDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C3DE7.367B569D@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > > The easy way to avoid the ambiguity is to dump the comma and use colons > as Guido intended. > > [for x in list1: > if x > 1: > for y in list2: > if y > 2: > (x,y)] Does indentation matter, and are you proposing blocks of "real" code in there? I suspect that writing it this way is going to tempt people to include more code, maybe expect to be able to write "else" clauses, put in "break", etc. I think if you do it this way, the above is so close to how you'd write it without list comprehensions that it largely eliminates the succinctness that motivated list comprehensions in the first place. -- ?!ng From gstein at lyra.org Wed Jul 12 12:13:58 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:13:58 -0700 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: ; from andy@reportlab.com on Wed, Jul 12, 2000 at 07:52:05AM +0100 References: Message-ID: <20000712031358.X29590@lyra.org> On Wed, Jul 12, 2000 at 07:52:05AM +0100, Andy Robinson wrote: >... > Are there many other applications which > use compression? If so, would it do > be feasible to include it by default > from version 1.6? I believe the correct approach would be to have ./configure look for zlib. If present, then it should include the module into the build. [ this auto-build style could apply to many modules, actually ] There would need to be a way to override this auto-build of a module. >... > p.s. I can submit a patch if needed :-) This would be great. I'd recommend a patch against configure.in and associated files. (Modules/Setup.* ?) Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Wed Jul 12 12:18:03 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 12 Jul 2000 12:18:03 +0200 Subject: [Python-Dev] New builtins References: <396C4596.C64D4EE6@schneider-kamp.de> <396C2D00.BDA23AF2@lemburg.com> <396C407F.CAB2584A@prescod.net> Message-ID: <396C45DB.B58D9B51@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > Just for completeness: mx.Tools already has these APIs: > > > > tuples(sequence) > > Returns much the same as apply(map,(None,)+tuple(sequence)) does, > > Like it. > > > lists(sequence) > > Same as tuples(sequence), except that a tuple of lists is returned. > > Like it. > > > dict(items) > > Constructs a dictionary from the given items sequence. > > Like it. > > In my opinion, these are naturals for built-in functions. Cool! > > These I'm not as sure about: > > > irange(object[,indices]) > > Builds a tuple of tuples (index,object[index]). > > Isn't this just tuples( indices( object ), object ) Yep, but less to write... > > indices(object) > > Returns the same as tuple(range(len(object))) -- > > Could be obsoleted by the range-building syntax: > > [0..len(object)] > > would do the same thing. True, except that I find indices(obj) more intuitive (and its just one function call). Technical note: tuples build faster than lists. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Wed Jul 12 12:19:07 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 13:19:07 +0300 (IDT) Subject: [Python-Dev] SF again: Patch assignments Message-ID: Can anyone send me a clear explanation how to assign a patch to someone? I've spent 10 minutes roomaging around SF to no avail. sf-can-be-frustrating-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From pf at artcom-gmbh.de Wed Jul 12 12:16:24 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 12 Jul 2000 12:16:24 +0200 (MEST) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: from Ka-Ping Yee at "Jul 12, 2000 2:36:33 am" Message-ID: > On Wed, 12 Jul 2000, Peter Funk wrote: > > BTW: How comes, that Ping very often invents or introduces very clever > > ideas and concepts, but also very often chooses unclear names for them? > > Is it just me not being a native english speaker? > Ka-Ping Yee schrieb: > Sorry for the silly reply. :) Honestly, i'm curious, though. > What kinds of things have been unclear to you before? It would > be instructive for me to know... Sorry: I take that back. It was just me. I've justed browsed through your articles in the 2000 python-dev archive and the only thing I found is your 'Notifier' class proposal containing method names like 'denotify'. (http://www.python.org/pipermail/python-dev/2000-April/010367.html http://www.python.org/pipermail/python-dev/2000-April/010368.html) Obviously my memory was blurred. Regards, Peter From gstein at lyra.org Wed Jul 12 12:41:31 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:41:31 -0700 Subject: [Python-Dev] SF again: Patch assignments In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jul 12, 2000 at 01:19:07PM +0300 References: Message-ID: <20000712034131.B29590@lyra.org> On Wed, Jul 12, 2000 at 01:19:07PM +0300, Moshe Zadka wrote: > > Can anyone send me a clear explanation how to assign a patch to someone? > I've spent 10 minutes roomaging around SF to no avail. I just click on the patch itself. In the screen that comes up, there is a drop-box for "Assigned To:" where I can select a person. After selecting the appropriate victim, I hit the "Submit Changes" button at the bottom of the page. Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul at prescod.net Wed Jul 12 12:48:35 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 05:48:35 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> <396C398D.9F85F8A8@prescod.net> <20000712031048.W29590@lyra.org> Message-ID: <396C4D03.D4F1F8E7@prescod.net> Greg Stein wrote: > > On Wed, Jul 12, 2000 at 04:25:33AM -0500, Paul Prescod wrote: > >... > > If you want to confuse a newbie, I'll claim that the "map" version will > > do it more than the list comp. version. > > Just because map() might confuse people doesn't mean it is now okay to > introduce *more* confusion. But the map version is a very common convention! If we can make a common convention more readable, that's a net win. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From peter at schneider-kamp.de Wed Jul 12 15:09:12 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 12 Jul 2000 13:09:12 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules flmodule.c,1.40,1.41 fmmodule.c,1.14,1.15 References: <200007121043.DAA27255@slayer.i.sourceforge.net> Message-ID: <396C6DF8.42C314E1@schneider-kamp.de> Sjoerd Mullender wrote: > > Fixed up some ANSIfications. oops. One typo and one wrong replace. I was probably getting tired ,-) Thnx Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gstein at lyra.org Wed Jul 12 13:15:14 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 04:15:14 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396C4D03.D4F1F8E7@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 05:48:35AM -0500 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> <396C398D.9F85F8A8@prescod.net> <20000712031048.W29590@lyra.org> <396C4D03.D4F1F8E7@prescod.net> Message-ID: <20000712041513.C29590@lyra.org> On Wed, Jul 12, 2000 at 05:48:35AM -0500, Paul Prescod wrote: > Greg Stein wrote: > > > > On Wed, Jul 12, 2000 at 04:25:33AM -0500, Paul Prescod wrote: > > >... > > > If you want to confuse a newbie, I'll claim that the "map" version will > > > do it more than the list comp. version. > > > > Just because map() might confuse people doesn't mean it is now okay to > > introduce *more* confusion. > > But the map version is a very common convention! If we can make a common > convention more readable, that's a net win. Agreed, to a point. The counter-point is: "let's introduce syntax to make FOO more readable. great. now lets introduce syntax to make BAR more readable. sweet. how about BAZ?" There are a lot of common idioms in Python. How many do you want to add *syntax* for? Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Wed Jul 12 14:19:14 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 07:19:14 -0500 Subject: [Python-Dev] APIs for internal flags In-Reply-To: Your message of "Wed, 12 Jul 2000 10:36:38 +0200." <396C2E16.38DAAE58@lemburg.com> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <200007101722.MAA01227@cj20424-a.reston1.va.home.com> <396A08AF.655B4836@lemburg.com> <200007101936.OAA02180@cj20424-a.reston1.va.home.com> <396C2E16.38DAAE58@lemburg.com> Message-ID: <200007121219.HAA13436@cj20424-a.reston1.va.home.com> [me] > > Anybody interested in designing an API here? Some requirements would > > be platform independence, extensibility, and necessarily the ability > > to work even in an environment without command line flags (since it > > still has the corresponding internal flags). [MAL] > For starters, here's what mx.Tools defines: > > sys.verbosity([level]) > sys.debugging([level]) > sys.optimization([level]) [...] +1 on the concept. All the other routines in sys seem to have 'set' or 'get' in their name (e.g. get/setdefaultencoding). Maybe we should conform to that? You could argue over names, e.g. get/setverbosity, get/setdebuglevel, get/setoptlevel. Are there any other flags that you might want to know about? -i,-c,-x irrelevant -S possibly -t yes --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul at prescod.net Wed Jul 12 13:21:56 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 06:21:56 -0500 Subject: [Python-Dev] zip() and list-comprehension with commas References: Message-ID: <396C54D4.A7855CC4@prescod.net> Ka-Ping Yee wrote: > > ... > > Does indentation matter, I'd say no. It is an expression in parens. Arguably, we could make the actual line breaks optional also: [for x in list1: if x > 1: for y in list2: if y > 2: (x,y)] > and are you proposing blocks of "real" code in there? No. Just expressions. > I suspect that writing it this way > is going to tempt people to include more code, maybe expect > to be able to write "else" clauses, put in "break", etc. Miscomprehensions of this sort will not last long. It won't fail silently! else might be a useful extension. (future version!) abs=[for x in nums: if x>0: x else: -x] There is the danger of introducing the ambiguous else. > I think if you do it this way, the above is so close to how > you'd write it without list comprehensions that it largely > eliminates the succinctness that motivated list comprehensions > in the first place. It sounds like you are saying that the real benefit of list comprehensions is that they allow you to avoid newlines! Anyhow, if you don't like the newlines, I think we can make them optional without losing anything. Then this syntax is as compact as the original. The colon syntax is very clear about the fact that the lists are not evaluated in parallel. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Wed Jul 12 13:27:44 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 06:27:44 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> <396C398D.9F85F8A8@prescod.net> <20000712031048.W29590@lyra.org> <396C4D03.D4F1F8E7@prescod.net> <20000712041513.C29590@lyra.org> Message-ID: <396C5630.AEB894B5@prescod.net> Greg Stein wrote: > > ... > > Agreed, to a point. > > The counter-point is: "let's introduce syntax to make FOO more readable. > great. now lets introduce syntax to make BAR more readable. sweet. how about > BAZ?" > > There are a lot of common idioms in Python. How many do you want to add > *syntax* for? In this case, we're replacing four conventions: map( None, a, [b]*len(a)) map( lambda x: ... ) filter( lambda x: ...) a=[] for i in j: a.append( something( i )) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From akuchlin at cnri.reston.va.us Wed Jul 12 13:59:15 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Wed, 12 Jul 2000 07:59:15 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <20000712031358.X29590@lyra.org>; from gstein@lyra.org on Wed, Jul 12, 2000 at 03:13:58AM -0700 References: <20000712031358.X29590@lyra.org> Message-ID: <20000712075915.A17856@newcnri.cnri.reston.va.us> On Wed, Jul 12, 2000 at 03:13:58AM -0700, Greg Stein wrote: >[ this auto-build style could apply to many modules, actually ] I'm working on a patch for using a setup.py file and the Distutils to build the standard library; Setup.in then contains only those few modules needed to run the Distutils, and you'd never need to modify it. Not done yet, though... --amk From thomas at xs4all.net Wed Jul 12 14:07:37 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 14:07:37 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396B9B91.E33D8C58@prescod.net>; from paul@prescod.net on Tue, Jul 11, 2000 at 05:11:29PM -0500 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> <396B9B91.E33D8C58@prescod.net> Message-ID: <20000712140737.G7340@xs4all.nl> On Tue, Jul 11, 2000 at 05:11:29PM -0500, Paul Prescod wrote: > Thomas Wouters wrote: > > .... They provide an easier way to create a list, but they don't > > eradicate the need for map, reduce or filter, because there is no way to > > comprehend an already created list. > What do you mean? I think I see examples of list comprehensions working > on existing lists on this page: > http://www.cosc.canterbury.ac.nz/~greg/python/listcomp/ > numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] > evens = [x for x in numbers if x % 2 == 0] # filter > mult3 = [3 * x for x in numbers] # map Yes, sorry, I don't know what posessed me to say that, I was obviously mistaken. What can I say, it was late, I was exhausted ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Wed Jul 12 14:06:29 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 07:06:29 -0500 Subject: [Python-Dev] List comp. sci fi Message-ID: <396C5F45.A8267A96@prescod.net> There is this idea on the edge of my brain that has to get out. I'm afraid of overloading the idea too much while people are still uncomfortable with the basics but at the same time I think that it is exciting that there could be more power in list comprehensions than pure syntactic sugar. What if list comprehensions were lazy? They would be objects that generate the items one at a time. Does this kill two birds with one stone? Or just conflate two separate ideas? Consider: naturals=[for num in [0:sys.maxint]] # does not construct list!! evens=[for num in naturals: if num%2==0: num ] # ditto!! chunks=[for chunk in file.read( 2048 ): chunk] # ditto!! databaseRecords=[for rec in SQL.Execute( "..." ): rec ] ditto!! Let's presume that name bindings are lexical and cyclic garbage collection works as we expect it to. Converting lazy behavior to eager is easy: chunkList=tuple( chunks ) I'm not up to it right now, but I'm sure that there is a nice way to combine sre and lazy comprehensions to get objects that return "hits" in a string one at a time. How to implement this? Stackless Python. As my friend Joy says: Go for the big one or stay at home. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gvwilson at nevex.com Wed Jul 12 14:10:52 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 12 Jul 2000 08:10:52 -0400 (EDT) Subject: [Python-Dev] second experiment Message-ID: I'm giving a talk at the U. of Toronto tomorrow, and would like to re-run the "what does it do?" experiment with list comprehensions and simultaneous loops. I propose asking the following: The program: for x in [10, 20, 30]: print x prints: 10 20 30 and the program: for x in [10, 20, 30]: for y in [1, 2, 3]: print x+y prints: 11 12 13 21 22 23 31 32 33 Match each of the following: (A) for x in [10, 20, 30]; y in [1, 2, 3]: print x+y (B) for (x,y) in zip([10, 20, 30], [1, 2, 3]): print x+y (C) for (x in [10, 20, 30]) and (y in [1, 2, 3]): print x+y (D) something else to their output: (1) 11 22 33 (2) 11 12 13 21 22 23 31 32 33 (3) "Run-Time Error" Questions: 1. What should option (D) be? 2. Should the lists be the same length, or different lengths? I think the latter is the trickier case (equally reasonable to say "iterate for length of shortest" and "error if lists' lengths unequal") --- is that worth testing? 3. Can someone provide a couple of list comprehension alternatives as well? Reactions? Greg From guido at beopen.com Wed Jul 12 15:18:04 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 08:18:04 -0500 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: Your message of "Wed, 12 Jul 2000 03:13:58 MST." <20000712031358.X29590@lyra.org> References: <20000712031358.X29590@lyra.org> Message-ID: <200007121318.IAA14063@cj20424-a.reston1.va.home.com> > On Wed, Jul 12, 2000 at 07:52:05AM +0100, Andy Robinson wrote: > >... > > Are there many other applications which > > use compression? If so, would it do > > be feasible to include it by default > > from version 1.6? > > I believe the correct approach would be to have ./configure look for zlib. > If present, then it should include the module into the build. > [ this auto-build style could apply to many modules, actually ] > > There would need to be a way to override this auto-build of a module. > > >... > > p.s. I can submit a patch if needed :-) > > This would be great. I'd recommend a patch against configure.in and > associated files. (Modules/Setup.* ?) Greg subtly points out the difficulty with your proposal: this requires an external library that may not be available. In the past we've had enough complaints from people who failed to realize that if the build failed because of a missing external library, they could just disable the module that needs it. So I'm not for simply having it enabled in Setup.in by default. I would love to have a mechanism (run by configure or maybe better by makesetup) that automatically determines if a particular external library package is available. Come to think of it, in first approximation, makesetup could easily parse the -I, -L and -l options you specify for a particular extension and only build it if it can find all those... But it's a bit of work! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Wed Jul 12 15:21:18 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 08:21:18 -0500 Subject: [Python-Dev] File Object Copy In-Reply-To: Your message of "Wed, 12 Jul 2000 12:08:26 +0300." References: Message-ID: <200007121321.IAA14098@cj20424-a.reston1.va.home.com> > > footnote: it's definitely an accepted pydiom: > > Yes, but one I personally do not like > > > aifc.py: > > if type(f) == type(''): > > f = __builtin__.open(f, 'rb') > > etc. > > > > it's a reasonable way to make your code a bit more reusable > > (it's rude to expect every chunk of potentially usable data to > > have a filename...). > > Of course -- that's why I think most code should use file-like objects. Agreed. The quoted examples are all kludges in my book. (The API designer initially accepted only a filename, then realized this was a bad choice, and fixed it in a backwards compatible way instead of fixing it right. There are just as many examples where it's done right, I just can't think of any. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Wed Jul 12 14:24:19 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 12 Jul 2000 08:24:19 -0400 (EDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: References: Message-ID: <14700.25459.555611.544163@bitdiddle.concentric.net> >>>>> "KPY" == Ka-Ping Yee writes: KPY> Gee. Well, with the SyntaxError patch, at least the error KPY> message is much better (even though the arrow still points to KPY> the wrong place): >>> class foo: ... def foo(self): ... pass ... def foo(bar): File "", line 4 def foo(bar): ^ SyntaxError: dedent does not match any outer indentation level The error message is different and given a little phrasebook that translates between the exception and English, it may actually be better <0.3 wink>. I don't know what a dedent is. Nor do I know what "outer indentation levels" are or how they might apply to the line "def foo(bar):". I think the error message is trying to say "indentation does not match surrounding context," but other than "does not match" the words are obscure. Jeremy From jeremy at beopen.com Wed Jul 12 14:29:59 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 12 Jul 2000 08:29:59 -0400 (EDT) Subject: [Python-Dev] Windows build broken in exceptions.c In-Reply-To: <00c401bfebd9$e6d347e0$f2a6b5d4@hagrid> References: <00c401bfebd9$e6d347e0$f2a6b5d4@hagrid> Message-ID: <14700.25799.891112.727921@bitdiddle.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> tim wrote: >> exceptions.c(93) : error C2026: string too big, trailing >> characters truncated FL> and incidentally, I just got: FL> SyntaxError: expression too long FL> from python. Hey! That's cool. In earlier versions, you would have gotten a core dump. Jeremy From guido at beopen.com Wed Jul 12 15:27:51 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 08:27:51 -0500 Subject: [Python-Dev] SF again: Patch assignments In-Reply-To: Your message of "Wed, 12 Jul 2000 03:41:31 MST." <20000712034131.B29590@lyra.org> References: <20000712034131.B29590@lyra.org> Message-ID: <200007121327.IAA14145@cj20424-a.reston1.va.home.com> > > Can anyone send me a clear explanation how to assign a patch to someone? > > I've spent 10 minutes roomaging around SF to no avail. > > I just click on the patch itself. In the screen that comes up, there is a > drop-box for "Assigned To:" where I can select a person. After selecting the > appropriate victim, I hit the "Submit Changes" button at the bottom of the > page. Moshe didn't see the drop-box because his permissions didn't include assigning patches. I've fixed this (as a policy, we give everyone with checkin permissions tech&admin permissions for the patch manager, but that's not the SF default, so it must be done manually). This is the second or third post from a new SF developer asking about this. We really need to set up our own SF FAQ soon! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Wed Jul 12 14:44:00 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 14:44:00 +0200 Subject: [Python-Dev] second experiment In-Reply-To: ; from gvwilson@nevex.com on Wed, Jul 12, 2000 at 08:10:52AM -0400 References: Message-ID: <20000712144400.H7340@xs4all.nl> On Wed, Jul 12, 2000 at 08:10:52AM -0400, Greg Wilson wrote: > (A) for x in [10, 20, 30]; y in [1, 2, 3]: > print x+y > > (B) for (x,y) in zip([10, 20, 30], [1, 2, 3]): > print x+y > > (C) for (x in [10, 20, 30]) and (y in [1, 2, 3]): > print x+y Hm, grouping them... Hadn't thought of that. That's going to be gruesome to implement, but it might just be possible. It isn't possible to use this 'and'-syntax without parentheses, in any case. > (D) something else for x in [10, 20, 30] while y in [1, 2, 3]: print x+y for x; y in [10, 20, 20]; [1, 2, 3]: print x+y > to their output: I'd suggest additional output, too: 4) 1 2 3 5) 10 20 30 And tell them they can match more than one construct to the same output ;-) > 2. Should the lists be the same length, or different lengths? I think the > latter is the trickier case (equally reasonable to say "iterate for > length of shortest" and "error if lists' lengths unequal") --- is that > worth testing? Probably... I'm not sure howmuch time you want to keep them busy. This is supposed to be intuitive, which means they shouldn't be pressured to find the right answer. > 3. Can someone provide a couple of list comprehension alternatives as > well? I'm not going there for a while. I'm dazed and confused about list comprehensions, that's for sure. Well, you can try seeing whether they think one of these should be zipped or cartesian product: [ x,y for x in [1, 2, 3] for y in [10, 20, 30] ] [ x;y for x in [1, 2, 3]; for y in [10, 20, 30] ] No use checking for commas, we'd have to re-write Pythons' parser or Grammar entirely to allow that. See my upcoming post on the various proposed alterantive syntaxes and why they aren't going to work ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw at beopen.com Wed Jul 12 15:05:40 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 09:05:40 -0400 (EDT) Subject: [Python-Dev] File Object Copy References: <200007121321.IAA14098@cj20424-a.reston1.va.home.com> Message-ID: <14700.27940.592190.150292@anthem.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> Of course -- that's why I think most code should use file-like >> objects. GvR> Agreed. The quoted examples are all kludges in my book. GvR> (The API designer initially accepted only a filename, then GvR> realized this was a bad choice, and fixed it in a backwards GvR> compatible way instead of fixing it right. There are just as GvR> many examples where it's done right, I just can't think of GvR> any. :-) rfc822.Message() -Barry From fredrik at pythonware.com Wed Jul 12 15:13:40 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 15:13:40 +0200 Subject: [Python-Dev] File Object Copy References: <200007121321.IAA14098@cj20424-a.reston1.va.home.com> Message-ID: <007a01bfec02$ffb5af90$0900a8c0@SPIFF> guido wrote: > > > it's a reasonable way to make your code a bit more reusable > > > (it's rude to expect every chunk of potentially usable data to > > > have a filename...). > > > > Of course -- that's why I think most code should use file-like objects. > > Agreed. The quoted examples are all kludges in my book. (The API > designer initially accepted only a filename, then realized this was a > bad choice, and fixed it in a backwards compatible way instead of > fixing it right. There are just as many examples where it's done > right, I just can't think of any. :-) really? personally, I think that inventing new method names just because the language doesn't happen to support method overloading is a much bigger kludge ;-) (just like multiple inheritance, overloading can surely be abused by overambitious designers, but *not* having it is way too limiting) otoh, unless someone wants to remove overloading emulation from the modules I mentioned, this is probably a bit off-topic... cheers /F From jack at oratrix.nl Wed Jul 12 15:19:59 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 15:19:59 +0200 Subject: [Python-Dev] second experiment In-Reply-To: Message by Greg Wilson , Wed, 12 Jul 2000 08:10:52 -0400 (EDT) , Message-ID: <20000712131959.D823037186D@snelboot.oratrix.nl> > 1. What should option (D) be? for (x, y) in [(10, 1), (20, 2), (30, 3)]: print x+y And I think it should be the first question, being the currently existing idiom. If non-pythoneers understand the current semantics but not the new ones there's a problem. Oh yes, maybe you should add an answer 4: I haven't the faintest idea. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From gvwilson at nevex.com Wed Jul 12 15:26:13 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 12 Jul 2000 09:26:13 -0400 (EDT) Subject: [Python-Dev] second experiment In-Reply-To: <20000712131959.D823037186D@snelboot.oratrix.nl> Message-ID: > > 1. What should option (D) be? > > for (x, y) in [(10, 1), (20, 2), (30, 3)]: > print x+y > > And I think it should be the first question, being the currently > existing idiom. Very good point --- thanks. Greg From bwarsaw at beopen.com Wed Jul 12 15:35:09 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 09:35:09 -0400 (EDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: <20000712094447.2275337186D@snelboot.oratrix.nl> Message-ID: <14700.29709.259658.864250@anthem.concentric.net> >>>>> "JJ" == Jack Jansen writes: JJ> parallel()/zip() have an other advantage: it would be easy to JJ> extend to let the loop continue until the longest of the JJ> items, with a keyword argument: parallel((1, 2), (3, 4, 5), JJ> missing=None) # or extend, or some other name would return JJ> ((1, 3), (2, 4), (None, 5)) Yes, yes, yes! JJ> By the way: -1 on the name zip() and -0 on the name JJ> parallel(), but +1 on the concept. Is weave() perhaps a better name? -Barry From jack at oratrix.nl Wed Jul 12 15:57:35 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 15:57:35 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message by bwarsaw@beopen.com (Barry A. Warsaw) , Wed, 12 Jul 2000 09:35:09 -0400 (EDT) , <14700.29709.259658.864250@anthem.concentric.net> Message-ID: <20000712135736.2DA9737186D@snelboot.oratrix.nl> > JJ> By the way: -1 on the name zip() and -0 on the name > JJ> parallel(), but +1 on the concept. > > Is weave() perhaps a better name? My mental model tends to be transpose(), but that will definitely throw off mathematicians. Maybe we need an anti?!ng to come up with a good name:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From skip at mojam.com Wed Jul 12 05:59:28 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 22:59:28 -0500 (CDT) Subject: [Python-Dev] Really dumb test observation Message-ID: <14699.60704.857942.610871@beluga.mojam.com> I was working on Python module coverage test generation tonight (sample results in the morning!). I noticed that coverage of the random module wasn't very good (30%-40% lines executed). There was no regression test case for that module, but I saw there was a random.test() function, so I created the following simple regression test: import random random.test() Statement coverage jumped immediately to nearly 90%. Seems to me that if a module defines a test() function and we have no regression test file for the module, that the above trick may increase code coverage significantly. (Actually, perhaps in these cases the test() function and related bits should be copied to the relevant regression test file to avoid invisible coupling between the module and its regression test output.) Skip From thomas at xs4all.net Wed Jul 12 16:13:28 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 16:13:28 +0200 Subject: [Python-Dev] listcomp / par-for (summary) Message-ID: <20000712161328.I7340@xs4all.nl> I'm gonna try and summarize all the opinions and suggestions in the listcomprehensions thread-from-hell (mutt's thread-sorted view was going bananas ;) but I'm certain I missed some suggestions and opinions, so I apologize in advance ;) Basically, what's been said is that list comprehensions as they are, are too confusing. I haven't hear that many people say that, but not many people objected to those that did say it, and plenty of alternative syntaxes were proposed. The same goes for parallel-for. It isn't terribly obvious whether the proposed syntax implements a cartesian product (as a nested for loop does) or a cross-section. There seem to be less divergent thoughts about this, though. A builtin (zip() or such) is preferred by a number of people, but not that many alternative syntaxes came along. As said, the currently implemented list-comprehension syntax was too unclear, especially when nesting the 'for's and 'if's too deeply. One of the proposals was to enforce the use of ()'s and add commas to make the 'for's and 'if's more readable: [(x,y) for x in a, y in b, if y > 3] That is not going to work. Enforcing the parentheses is possible, but only if you *always* enforce them, even if they don't create a tuple: [([x,y]) for x in a] (which would create a list of lists, not a list of tuples of lists.) And the problem with enforcing it is that we have to split open a *lot* of the Grammar, in order to disambiguate the syntax. Ain't a recursive descent parser great ? :) Secondly, the use of commas to seperate the for and if statements is not possible. The parser will see the commas as part of the iter-list of the previous for statement. The same goes for all other seperators that already have a meaning inside a 'testlist': commas, vertical bars, ampersands, circumflexes, etc. About the only character that already had a meaning inside Python that's usable at this point is the semi-colon, because it's only used as a statement seperator, not part of an expression list. Of course, using a new character that hasn't a meaning yet also works. And the same also goes for keywords in the same place. 'and' won't work, for instance, because it's already part of 'exprlist' and 'testlist', but 'while' does work, because it's currently only valid as a statement, not in an expression. So we end up with the following possibly syntaxes: [ <...> ] and [ ; ; ; <...> ] and perhaps the use of Python blocks and such: [ : : <....> ] Though I think that is a bit of a far cry from the original proposal. All the other proposals simply won't work without a massive re-ordering of the Grammar or rewriting the entire parser into something more versatile (and complicated) than a simple recursive descent parser. And the exact same story can be told for the parallel-for loop: for x in a and y in b: will not work because the 'exprlist' in 'for' will eat up 'a and y in b'. Likewise for for x in a | y in b: for x|y in a|b: for x,y in a|b: etc. The unnatural for {x,y} in a, b: would work, but it'd require special-casing the use of {}'s, and might suggest 'dict-unpacking' to people. for x;y in a;b: probably will work, too. Actually, yes, this will work, even though I haven't tested it... It also makes seeing howmany lists you are looping over pretty easy. Hmm, I might even like this more than the currently implemented syntax, even if it's slightly less readable. The range-literal thing ([:10:2] -> [0,2,4,6,8]) seems to be acceptable, I believe ? It might 'merely' be syntactic sugar for a builtin, but it's such pretty sugar ! :-) And it's not possible to shadow the builtin like with range. (Though I have one possible addition to the range syntax: range tuples, like so: (20:10:3) They could just generate a rangeobject, like xrange does... That could be a fair bit of memory savings ;) But I have to admit the syntax isn't as obvious as [19:15:-1]) If I were to tally votes, I'd say the general consensus (for as far as there is one ;-) is rougly like this: list comprehensions: -1/-0 parallel for: -0 range literal: +0 Correct me if I'm wrong ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Wed Jul 12 16:19:47 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 09:19:47 -0500 (CDT) Subject: [Python-Dev] Re: test_posixpath fails In-Reply-To: <14699.58277.811263.365468@bitdiddle.concentric.net> References: <14699.58277.811263.365468@bitdiddle.concentric.net> Message-ID: <14700.32387.330444.979191@beluga.mojam.com> Jeremy> If I run the new test on my Linux box, I get two errors. The Jeremy> second error looks innocuous, but the first one looks like a Jeremy> real bug. Jeremy, Mea culpa. I wrote the commonprefix test assuming the adoption of my new (corrected) semantics. Looks like you are using the stock version that examines prefixes character-by-character, which can return path prefixes that don't exist. Try applying this patch: https://sourceforge.net/patch/?func=detailpatch&patch_id=100788&group_id=5470 Skip Jeremy> Jeremy >> python Lib/test/test_posixpath.py Jeremy> error! Jeremy> evaluated: posixpath.commonprefix(["/home/swenson/spam", "/home/swen/spam"]) Jeremy> should be: /home Jeremy> returned: /home/swen Jeremy> error! Jeremy> evaluated: posixpath.commonprefix(["/home/swen/spam", "/home/swen/eggs"]) Jeremy> should be: /home/swen Jeremy> returned: /home/swen/ Jeremy> 2 errors. From fdrake at beopen.com Wed Jul 12 16:20:28 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 12 Jul 2000 10:20:28 -0400 (EDT) Subject: [Python-Dev] Re: CVS: python/dist/src/Include abstract.h,2.21,2.22 In-Reply-To: <200007121256.FAA00462@slayer.i.sourceforge.net> References: <200007121256.FAA00462@slayer.i.sourceforge.net> Message-ID: <14700.32428.442840.683994@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > change abstract size functions PySequence_Size &c. > add macros for backwards compatibility with C source ... > + #define PyObject_Length(O) PyObject_Size((O)) Jeremy, This should probably be: #define PyObject_Length PyObject_Size without the parameters. This form can be used in the all the places where it can now, including passing a function reference. Seems like a good idea to offer as little potential breakage as possible. Are you planning to update the API reference, or should I do that? I'll be glad to do it; I've never liked the difference in the naming either! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Wed Jul 12 16:24:31 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 09:24:31 -0500 (CDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <14699.59823.710880.896491@anthem.concentric.net> References: <396BA425.2EF3B11F@prescod.net> <14699.59823.710880.896491@anthem.concentric.net> Message-ID: <14700.32671.461502.666561@beluga.mojam.com> BAW> Alternatives (as Greg I think brought up): pairwise(), maybe BAW> zipper() for zip() since it's more evocative. "zip" already has a lot of compression connotations. How about "stitch", as in "stitch two lists together"? Skip From nhodgson at bigpond.net.au Wed Jul 12 16:30:08 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Thu, 13 Jul 2000 00:30:08 +1000 Subject: [Python-Dev] Proxy settings for urllib on Win32 Message-ID: <004501bfec0d$ae1bca10$8119fea9@neil> Is there any reason why urllib uses environment variables for proxy settings on Win32? Its quite unlikely they will be set up and there is a standard registry location for this information. I've added retrieval of registry settings to my copy of urllib and it seems to work OK athough I'm not running off CVS and I recall the winreg module has changed recently. Here is the code going just after the "if os.name == 'mac'" proxy handling. elif os.name == 'nt': def getproxies(): """Return a dictionary of scheme -> proxy server URL mappings. Win32 uses the registry to store proxies. """ proxies = {} try: import winreg internetSettings = winreg.OpenKey(winreg.HKEY_CURRENT_USER, "Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings"); proxyEnable = winreg.QueryValueEx(internetSettings, "ProxyEnable")[0] if proxyEnable: # Returned as Unicode but problems occur if not converted to ASCII proxyServer = str(winreg.QueryValueEx(internetSettings, "ProxyServer")[0]) if ";" in proxyServer: # Individual per-protocol settings for p in string.split(proxyServer,";"): protocol, address = string.split(p, "=") proxies[protocol] = '%s://%s' % (protocol, address) else: # Use one setting for all protocols proxies['http'] = 'http://%s' % proxyServer proxies['ftp'] = 'ftp://%s' % proxyServer internetSettings.Close() except: # proxies already set up to be empty so nothing to do pass return proxies Neil From esr at thyrsus.com Wed Jul 12 16:56:31 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Wed, 12 Jul 2000 10:56:31 -0400 Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.18134.550769.266956@beluga.mojam.com> References: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> <14699.18134.550769.266956@beluga.mojam.com> Message-ID: <20000712105631.A1472@thyrsus.com> Skip Montanaro : > Fred> At one point, we were discussing having specializations of > Fred> SyntaxError, and I posted a patch that defined IndentationError > Fred> and TabError. > > I think you should go for it. As long as they are subclasses of SyntaxError > no existing code should break. For whatever it's worth, I agree. -- Eric S. Raymond According to the National Crime Survey administered by the Bureau of the Census and the National Institute of Justice, it was found that only 12 percent of those who use a gun to resist assault are injured, as are 17 percent of those who use a gun to resist robbery. These percentages are 27 and 25 percent, respectively, if they passively comply with the felon's demands. Three times as many were injured if they used other means of resistance. -- G. Kleck, "Policy Lessons from Recent Gun Control Research," From skip at mojam.com Wed Jul 12 16:40:23 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 09:40:23 -0500 (CDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: References: Message-ID: <14700.33623.201717.133682@beluga.mojam.com> Michael> Think zip as in "zipper"; this more sense to me than naming a Michael> compression algorithm "zip"... Unfortunately, regardless of your background or mine, most of the unwashed masses who will be (and are being) attracted to Python have only seen "zip" in computer contexts as it relates to file compression. To add weight to the connection, Python now has a "zipfile" module... Skip From MarkH at ActiveState.com Wed Jul 12 16:42:43 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Wed, 12 Jul 2000 10:42:43 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <3969FD17.487DA96A@interet.com> Message-ID: Sorry for the delay in responding to this stuff - Im at the MS PDC, and demoing a new Python compiler that I'm suddenly allowed to talk about - but that isnt the point of this mail :-] > This is really bad. Normally under Windows, DLL names do not change > unless the API exported is changed in a major way. For example, > there have been several versions of mfc42.dll without changing the > name. Yes, and each of these versions has broken various programs. Of all people, Im surprised to see you falling for the MS hype, Jim. MS have openly admitted, on a number of occasions, that Windows has "DLL hell", and has made a huge effort to address this in the .NET framework. The Python community has itself been bitten by "bogus" MFC42.dll files that MS profess to be compatible. If MS can't get it right with their resources, I don't like our chances! > What this means is that if the new Python 2.0 (1.6?) simply names > its DLL python15.dll just as before, everything Just Works almost. > That is, it Just Works provided that foo.pyd only calls Python > C functions whose interface has not changed. IMO, this constrains us too much. We can't afford this - we simply dont have the resources. > You can support Python 1.5 and 1.6 by removing the python*.dll > from the Windows directories, and putting it in the directory > of python.exe so it goes with the proper executable. We have discussed this over and over and over, ad nauseum. If you believe the earlier discussions were bunk, please refute them. Otherwise, simply re-asserting something that we have previously proven to be incorrect doesnt help anyone. > > trying to solve here? So far, the only problem that came up was that > > on Windows, you get an obscure crash when trying to load an extension > > built for Python 1.5(.x). > > Yes, and this is a major problem, and is un-Windows-like. :-) "Major Crashes" are un-Windows like? What is happening to this group - It amusing that this statement could be made without the Linux geeks making smart-arsed comments :-) Looks like Billy Boy really _is_ taking over the world :-) > No, just keep the old name "python15.dll". Old foo.pyd will > still work if they use only Python C functions with the same > interface. And as long as we go to extraordinary efforts to maintain binary compatibility. We are under resourced as it is - I dont believe we can do this. > Individual *.pyd authors will have to advise users whether > they need to upgrade to new *.pyd versions or not. This is where we are now. I agree that we should not crash, but it seems to me you havent solved anything - individual .pyd authors needing to tell users about each individual .pyd isnt a solution. > > You can already get the version string by > > looking at Py_GetVersion() -- this also answers the question of how a > > version is represented. > > True. And on Windows, there is a standard Version resource > string which gives the DLL version, and can be read without > loading the DLL. This string is referenced by the Wise (and > other) installers to decide whether a DLL is newer and should > be replaced. Im not sure how this helps us. Do you mean that "initfoo" should use the Windows resource/version APIs to determine if it can load? > > On Windows, link-time compatibility is broken whenever we change the > > second digit of the version number, e.g. 15, 16, 20. > > Yikes, lets not let that happen! Ideally, I agree. However, Im not sure how we can make this happen! Any ideas on how we can achieve this? And I mean in a practical sense, rather than with a hand-waving abstract theory - ie, specifically what developement practices should change, or be put in place, to ensure this? Mark. From bwarsaw at beopen.com Wed Jul 12 16:45:38 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 10:45:38 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> Message-ID: <14700.33938.765976.193911@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> I believe the correct approach would be to have ./configure GS> look for zlib. If present, then it should include the module GS> into the build. [ this auto-build style could apply to many GS> modules, actually ] It would have to check the libz version number. Older versions will core Python. -Barry From bwarsaw at beopen.com Wed Jul 12 16:46:19 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 10:46:19 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> <20000712075915.A17856@newcnri.cnri.reston.va.us> Message-ID: <14700.33979.832366.278311@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> I'm working on a patch for using a setup.py file and the AK> Distutils to build the standard library; Setup.in then AK> contains only those few modules needed to run the Distutils, AK> and you'd never need to modify it. Not done yet, though... +10 From MarkH at ActiveState.com Wed Jul 12 16:47:40 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Wed, 12 Jul 2000 10:47:40 -0400 Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length In-Reply-To: <14698.15423.878220.203259@bitdiddle.concentric.net> Message-ID: > Tuple, List, String, and Dict have a PyXXX_Size method. The abstract > object interface uses PySequence_Length. This is inconsistent and > hard to remember. Can we add PySequence_Size and mark Length as > deprecated? I definately prefer "length" - for example, with Unicode, PyUnicode_Size() implies the number of bytes (the size of the data structure) while PyUnicode_Length() implies the number of characters. Mark. From skip at mojam.com Wed Jul 12 16:50:54 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 09:50:54 -0500 (CDT) Subject: [Python-Dev] no test_posix, test_os or test_sys? Message-ID: <14700.34254.159786.213828@beluga.mojam.com> I decided I better examine the posix.isatty patch assigned to me before Guido kicks me out... I was a little annoyed it didn't include a new test case. I figured, "oh well, I'll just add one to test_posix.py". Oh Lord! No test_posix.py or test_os.py! (No test_sys.py either!) These are some of the most heavily used modules in Python. They deserve test cases... Unless someone has strenuous objections, I'm going to post something on c.l.py asking for volunteers to write test cases for each of these three. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From thomas at xs4all.net Wed Jul 12 16:58:52 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 16:58:52 +0200 Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: <14700.34254.159786.213828@beluga.mojam.com>; from skip@mojam.com on Wed, Jul 12, 2000 at 09:50:54AM -0500 References: <14700.34254.159786.213828@beluga.mojam.com> Message-ID: <20000712165852.J7340@xs4all.nl> On Wed, Jul 12, 2000 at 09:50:54AM -0500, Skip Montanaro wrote: > I decided I better examine the posix.isatty patch assigned to me before > Guido kicks me out... I was a little annoyed it didn't include a new test > case. I wasn't entirely certain how to test this. Can we rely on stdin/stdout being a terminal, inside tests ? I think not. It can be tested by test_pty and/or test_openpty, but then failure can mean two things: pty.openpty() failed, or isatty() failed. Or we can open an fd and make sure os.isatty() returns 0 for that. None of it seemed very sensible. (I did write the test_pty/test_openpty modules with this in mind, though: ## # Please uncomment these if os.isatty() is added. ## if not os.isatty(master_fd): ## raise TestFailed, "master_fd is not a tty" ## if not os.isatty(slave_fd): ## raise TestFailed, "slave_fd is not a tty" So if you accept the patch, please uncomment those lines ;) However, isatty() is a *very* simple wrapper around a very basic C function, so I didn't think it warranted a test case. (Like you pointed out, none of the other functions in posixmodule have test cases.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Wed Jul 12 17:01:46 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 10:01:46 -0500 (CDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14700.25459.555611.544163@bitdiddle.concentric.net> References: <14700.25459.555611.544163@bitdiddle.concentric.net> Message-ID: <14700.34906.286143.800770@beluga.mojam.com> SyntaxError: dedent does not match any outer indentation level Isn't something like "line indented incorrectly" sufficient to alert the programmer to an indentation on that line? Perhaps Python doesn't need to tell which direction to push the line. Skip From akuchlin at mems-exchange.org Wed Jul 12 17:06:37 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 12 Jul 2000 11:06:37 -0400 Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: <14700.34254.159786.213828@beluga.mojam.com>; from skip@mojam.com on Wed, Jul 12, 2000 at 09:50:54AM -0500 References: <14700.34254.159786.213828@beluga.mojam.com> Message-ID: <20000712110637.E1363@kronos.cnri.reston.va.us> On Wed, Jul 12, 2000 at 09:50:54AM -0500, Skip Montanaro wrote: >No test_posix.py or test_os.py! (No test_sys.py either!) These are some of >the most heavily used modules in Python. They deserve test cases... Note that you might want to break it up into subtests; for example, test_fork.py tests os.fork() already. So you could have one test case for file-related operations, another for uid-related, etc. A full test_os.py would be huge and ungainly. (I've speculated about adding a unit testing framework, similar to the one we use internally at the MEMS Exchange; the discipline of using it makes writing a test more time-consuming, but the tests also wind up being more comprehensive.) --amk From skip at mojam.com Wed Jul 12 17:11:44 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 10:11:44 -0500 (CDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C4F7D.288B561D@schneider-kamp.de> References: <396C4F7D.288B561D@schneider-kamp.de> Message-ID: <14700.35504.551569.956243@beluga.mojam.com> Peter> off-topic: Peter> I am still thinking about higher order functions in Python: Peter> e.g.: map(+ 1, [1, 2, 3]) instead of map(lambda x: x + 1, [1, 2, 3]) Peter> don't have a clue how to do that yet. That would be [x + 1 for x in [1,2,3]] of course... ;-) Skip From jack at oratrix.nl Wed Jul 12 17:16:19 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 17:16:19 +0200 Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: Message by Andrew Kuchling , Wed, 12 Jul 2000 11:06:37 -0400 , <20000712110637.E1363@kronos.cnri.reston.va.us> Message-ID: <20000712151620.1C31437186D@snelboot.oratrix.nl> > Note that you might want to break it up into subtests; for example, > test_fork.py tests os.fork() already. So you could have one test case > for file-related operations, another for uid-related, etc. A full > test_os.py would be huge and ungainly. +1. If the tests would also do the import in the right way, i.e. test_os_symlink would do a "from os import symlink", then on each platform it would only try the tests that are relevant to the platform, while the others would be skipped with an "optional feature couldn't be imported", in stead of crashing the whole test_os. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido at beopen.com Wed Jul 12 18:26:58 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 11:26:58 -0500 Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: Your message of "Wed, 12 Jul 2000 09:50:54 EST." <14700.34254.159786.213828@beluga.mojam.com> References: <14700.34254.159786.213828@beluga.mojam.com> Message-ID: <200007121626.LAA14732@cj20424-a.reston1.va.home.com> > Unless someone has strenuous objections, I'm going to post something on > c.l.py asking for volunteers to write test cases for each of these three. +10 --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Wed Jul 12 17:30:48 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 10:30:48 -0500 (CDT) Subject: [Python-Dev] Basic Python statement coverage results Message-ID: <14700.36648.674422.519358@beluga.mojam.com> I added Python statement coverage using my trace module to the stuff that is run nightly on my web site. When you get a chance, please visit http://www.musi-cal.com/~skip/python/Python/dist/src/ From esr at thyrsus.com Wed Jul 12 17:49:45 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Wed, 12 Jul 2000 11:49:45 -0400 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> References: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> Message-ID: <20000712114945.F1607@thyrsus.com> Guido van Rossum : > What do you think the following code would print? > > for i in (10, 20, 30); j in (1, 2, 3): > print i+j I think thre confusion over ambiguous syntax is telling us that what we need here is to bite the bullet and add a keyword to the language so there is a clear distinction from existing concepts. I make so bold as to sugest this: for i in (10, 20, 30) with j in (1, 2, 3): print i+j However, I have to say that having meditated on this design problem at some length I now think proliferating new control structures is the wrong answer. Instead, I propose that we look for ways to make smarter data structures drive control. Concretely. this approach would make `with' a data contructor, throw out the parallel-loop syntax, and write the following: >>> [2] with [3] [(2, 3)] >>> (10, 20, 30) with (1, 2, 3) ((10, 1), (20, 2), (30, 3)) >>> for (i, j) in (10, 20, 30) with (1, 2, 3): print i + j This doesn't instantly give us a way to interpret for (i, j) in (10, 20, 30, 40) with (1, 2): print i + j But suppose that the semantics of `with' were that it joins parallel arguments as far as it can and stops whenever it runs out of elements in any one argument. Then, >>> (10, 20, 30, 40) with (1, 2) ((10, 1), (20,2)) Problem solved. Now let's make life easier. The `with' keyword can actually become an n-adic intrinsic function, analogous to `range'. Now we write >>> for (i, j) in with((10, 20, 30, 40), (1, 2)): print i + j Presto! All need for parallel loops has now disappeared. If anyone doubts this, I will cheerfully produce source code for with(). -- Eric S. Raymond It is proper to take alarm at the first experiment on our liberties. We hold this prudent jealousy to be the first duty of citizens and one of the noblest characteristics of the late Revolution. The freemen of America did not wait till usurped power had strengthened itself by exercise and entangled the question in precedents. They saw all the consequences in the principle, and they avoided the consequences by denying the principle. We revere this lesson too much ... to forget it -- James Madison. From esr at thyrsus.com Wed Jul 12 17:55:07 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Wed, 12 Jul 2000 11:55:07 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.31592.410628.754071@anthem.concentric.net> References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> Message-ID: <20000712115507.G1607@thyrsus.com> Barry A. Warsaw : > Range literals I can see as being worth it. I wonder if parallel for > loops can't be handled more gracefully with a function -- isn't it > just a nice wrapper around a specific call to map() anyway? > > List comprehensions do seem to need more syntactic support, but the > ambiguity of the semantics bothers me. I agree with both evaluations, and have just posted a proposal to replace parallel for-loops with a new data constructor. (I still like list comprehensions. But they need to be cleaner.) -- Eric S. Raymond Question with boldness even the existence of a God; because, if there be one, he must more approve the homage of reason, than that of blindfolded fear.... Do not be frightened from this inquiry from any fear of its consequences. If it ends in the belief that there is no God, you will find incitements to virtue in the comfort and pleasantness you feel in its exercise... -- Thomas Jefferson, in a 1787 letter to his nephew From effbot at telia.com Wed Jul 12 17:43:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 17:43:45 +0200 Subject: [Python-Dev] more SyntaxError subclasses! Message-ID: <009a01bfec17$f7fe3be0$f2a6b5d4@hagrid> here are a bunch of other syntax error subclasses that might be useful: class StatementError(SyntaxError): "you cannot use this statement here" class AssignmentError(StatementError): "you cannot assign to this target" class CompilerError(SyntaxError): "sorry, this is a compiler restriction, not really a language restriction" class LimitError(CompilerError): "exceeded compiler limit" class TokenError(SyntaxError): "you cannot use this token here" class FunctionError(SyntaxError): "there's something wrong with this function/method declaration" class ArgumentError(FunctionError): "the argument declaration isn't correct" here's how they're used in the current interpreter (before the TabError/IndentationError patches): ArgumentError: "duplicate keyword argument" ArgumentError: "keyword can't be an expression" ArgumentError: "non-default argument follows default argument" ArgumentError: "non-keyword arg after keyword arg" AssignmentError: "can't assign to ()" AssignmentError: "can't assign to []" AssignmentError: "can't assign to function call" AssignmentError: "can't assign to lambda" AssignmentError: "can't assign to literal" AssignmentError: "can't assign to operator" LimitError: "expression too long" LimitError: "more than 255 arguments" StatementError: "'break' outside loop" StatementError: "'continue' not properly in loop" StatementError: "'return' outside function" StatementError: "default 'except:' must be last" StatementError: "name is local and global" SyntaxError: "invalid syntax" SyntaxError: "unexpected EOF while parsing" SyntaxError: "unknown parsing error" TabError: "inconsistent use of tabs and spaces in indentation" TokenError: "invalid token" comments? (I'm extra interested in arguments from people who think TabError and IndentationError is a good idea, but that this one sucks. I'm not sure I want to hear from people who thinks that this one is a great idea ;-) ... on a more serious note, I think it would be great to add a distinct attribute to the SyntaxError instance (an error number, most likely). this could be used by an IDE to provide concise info without having to parse the error message. I'll post a more complete proposal later... cheers /F From effbot at telia.com Wed Jul 12 17:32:51 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 17:32:51 +0200 Subject: [Python-Dev] Proxy settings for urllib on Win32 References: <004501bfec0d$ae1bca10$8119fea9@neil> Message-ID: <009901bfec17$f7bb1860$f2a6b5d4@hagrid> neil wrote: > Is there any reason why urllib uses environment variables for proxy > settings on Win32? Its quite unlikely they will be set up and there is a > standard registry location for this information. probably only laziness -- winreg is a recent addition, after all. > I've added retrieval of registry settings to my copy of urllib and it > seems to work OK athough I'm not running off CVS and I recall the winreg > module has changed recently. Here is the code going just after the "if > os.name == 'mac'" proxy handling. +1 from here. cheers /F From paul at prescod.net Wed Jul 12 17:39:51 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 10:39:51 -0500 Subject: [Python-Dev] listcomp / par-for (summary) References: <20000712161328.I7340@xs4all.nl> Message-ID: <396C9147.F4A4BE4F@prescod.net> Thanks for the summary. Here's my 1p. Thomas Wouters wrote: > >... > > Basically, what's been said is that list comprehensions as they are, are too > confusing. I haven't hear that many people say that, but not many people > objected to those that did say it, and plenty of alternative syntaxes were > proposed. I think that a lot of the confusion came with the conflation with parallel-for. Any concept is hard to follow when the syntax is changing hourly. -- Re: alternatives for listcomp: Another option is: [ : : <....>: ] -- RE: parallel for: Are there any arguments AGAINST using something like zip for a parallel for-loop a function? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Wed Jul 12 17:40:11 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 10:40:11 -0500 Subject: [Python-Dev] listcomp / par-for (summary) References: <20000712161328.I7340@xs4all.nl> Message-ID: <396C915B.8B1A3A1B@prescod.net> Here's my other 1p. > The range-literal thing ([:10:2] -> [0,2,4,6,8]) seems to be acceptable, I > believe ? It might 'merely' be syntactic sugar for a builtin, but it's > such pretty sugar ! :-) Let me play devil's advocate to make sure this is fleshed out enough. How's this for obfuscation: [0:10][0:10][0:10] --- And arguing from analogy, shouldn't range(0:bignum)[0:10:2] be [0:10:2] > And it's not possible to shadow the builtin like with range. You probably shouldn't be able to shadow most builtins period. > (Though I have one possible addition to the range syntax: range tuples, like > so: > > (20:10:3) I presume you meant (10:20:3). Right? > They could just generate a rangeobject, like xrange does... That could be a > fair bit of memory savings ;) But I have to admit the syntax isn't as > obvious as [19:15:-1]) I don't follow you here. Anyhow, I like the idea that there should be a syntax that does the rangeobject thing and it makes sense that it needs to be immutable. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Wed Jul 12 17:31:10 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 17:31:10 +0200 Subject: [Python-Dev] simple syntax error bombs interpreter Message-ID: <009101bfec16$35495fe0$f2a6b5d4@hagrid> using my latest Python 2.0 build, the interpreter bombs if I type the following two commands: >>> def a(b): ... global b ... (1.5.2 says "name is local and global"). From paul at prescod.net Wed Jul 12 17:44:45 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 10:44:45 -0500 Subject: [Python-Dev] Unit testing... References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> Message-ID: <396C926D.F223E686@prescod.net> Andrew Kuchling wrote: > > ... > > (I've speculated about adding a unit testing framework, similar to the > one we use internally at the MEMS Exchange; the discipline of using it > makes writing a test more time-consuming, but the tests also wind up > being more comprehensive.) I think PyUnit/JUnit and friends are in vogue these days. There is some virtue in having a framework that could be used also by extension module writers so that there is some consistency about finding and invoking tests. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Wed Jul 12 18:01:37 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 11:01:37 -0500 Subject: [Python-Dev] zip() and list-comprehension with commas References: <396BA425.2EF3B11F@prescod.net> <14699.59823.710880.896491@anthem.concentric.net> <14700.32671.461502.666561@beluga.mojam.com> Message-ID: <396C9661.3EF03755@prescod.net> Skip Montanaro wrote: > > BAW> Alternatives (as Greg I think brought up): pairwise(), maybe > BAW> zipper() for zip() since it's more evocative. > > "zip" already has a lot of compression connotations. How about "stitch", as > in "stitch two lists together"? "Stitch" and "with" are okay, but I'd like to hear someone debunk the names used today by MAL. They seemed very logical to me. I'd just change the semantics to be lazy in a couple of cases. >>> tuple([1,2,3]) (1,2,3) >>> tuples([1,2,3],[4,5,6]) >>> list((1,2,3)) [1,2,3] >>> lists((1,2,3),(4,5,6)) >>> dict([(1,2),(3,4),(5,6)]) {1:2,3:4,5:6} -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 18:13:19 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 18:13:19 +0200 (CEST) Subject: [Python-Dev] Re: merging my*.h into pyport.h In-Reply-To: <396B4850.A3D1A1A2@stud.ntnu.no> from "Peter Schneider-Kamp" at Jul 11, 2000 04:16:16 PM Message-ID: <200007121613.SAA29910@python.inrialpes.fr> Peter Schneider-Kamp wrote: > > What do you think would be appropriate? I have been toying around > with the my*.h headers a bit and loaded up a "proof of concept" patch > that makes all my*.h obsolete. Where's the patch? ... Ah, found it - assigned to / postponed by nowonder. This include business is tricky. I for one am against seeing mymalloc.h moved to pyport.h. It doesn't belong there and deserves a file on its own. If my*.[ch] files really disturb you, you can make them obsolete by renaming them to py*.[ch] :-). ~/python/dev> ls Include/my* Include/mymalloc.h Include/myproto.h Include/mytime.h Include/mymath.h Include/myselect.h - feel free to move to pyport.h both myproto.h and mymath.h (as you did) - mymalloc.h shouldn't be touched. You may eventyally want to rename it to pymalloc.h - not sure what to do with mytime.h and myselect.h - not sure whether it's worth renaming my*.c to py*.c > > P.S.: What's the status of sre? I just ask because test_re > keeps nagging all the time. :-] The problem is that /F has no idea where this bug comes from, and the suspicions he had about memory glitches in the SRE code haven't been confirmed by Barry's Purify analyses so far. I did some testing too, but found only unrelated buglets. I second Barry's opinion that the memory picture of the CVS snapshot is good enough. So this seems to be a bug related with the logic of the code, in an area where Barry and I have already publicly qualified ourselves as clueless. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From skip at mojam.com Wed Jul 12 18:25:57 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 11:25:57 -0500 (CDT) Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: <20000712165852.J7340@xs4all.nl> References: <14700.34254.159786.213828@beluga.mojam.com> <20000712165852.J7340@xs4all.nl> Message-ID: <14700.39957.204774.928368@beluga.mojam.com> Thomas> (I did write the test_pty/test_openpty modules with this in Thomas> mind, though: Thomas> ## # Please uncomment these if os.isatty() is added. Thomas> ## if not os.isatty(master_fd): Thomas> ## raise TestFailed, "master_fd is not a tty" Thomas> ## if not os.isatty(slave_fd): Thomas> ## raise TestFailed, "slave_fd is not a tty" Thomas> So if you accept the patch, please uncomment those lines ;) Will do. Thomas> However, isatty() is a *very* simple wrapper around a very basic Thomas> C function, so I didn't think it warranted a test case. (Like Thomas> you pointed out, none of the other functions in posixmodule have Thomas> test cases.) My message wasn't motivated so much with the missing test case for isatty, but that there are no regression tests at all for os, posix or sys. Skip From thomas at xs4all.net Wed Jul 12 18:26:56 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 18:26:56 +0200 Subject: [Python-Dev] listcomp / par-for (summary) In-Reply-To: <396C915B.8B1A3A1B@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 10:40:11AM -0500 References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> Message-ID: <20000712182656.K7340@xs4all.nl> On Wed, Jul 12, 2000 at 10:40:11AM -0500, Paul Prescod wrote: > > The range-literal thing ([:10:2] -> [0,2,4,6,8]) seems to be acceptable, > > I believe ? It might 'merely' be syntactic sugar for a builtin, but it's > > such pretty sugar ! :-) > Let me play devil's advocate to make sure this is fleshed out enough. > > How's this for obfuscation: > [0:10][0:10][0:10] Sure, but it's not more obfuscated than a long line of map(lambda ... reduce(filter(map(lambda ... ))) -- it's definately easier to parse for humans ! The parser won't have any trouble with it, if that's what you mean: >>> [:200:2][0:20] [0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38] >>> [:200:2][0:20][10:20] [20, 22, 24, 26, 28, 30, 32, 34, 36, 38] > --- > And arguing from analogy, shouldn't > > range(0:bignum)[0:10:2] be [0:10:2] Yes, it should, but there is no way to enforce it, currently, because range can be shadowed by a local or global variable. And it doesn't have to be unintended, either. With range literals, that's no longer possible. > > And it's not possible to shadow the builtin like with range. > You probably shouldn't be able to shadow most builtins period. Why not ? It would introduce a number of problems: adding new builtin functions would be as cagey as adding new reserved words (in effect, all builtins *become* reserved words.) So it would break a ton of code. It would make extending the builtins practically impossible. It would be very confusing for current Python programmers. Etcetera. > > (Though I have one possible addition to the range syntax: range tuples, > > like so: > > > > (20:10:3) > I presume you meant (10:20:3). Right? Yes, sorry. > > They could just generate a rangeobject, like xrange does... That could be a > > fair bit of memory savings ;) But I have to admit the syntax isn't as > > obvious as [19:15:-1]) > I don't follow you here. Anyhow, I like the idea that there should be a > syntax that does the rangeobject thing and it makes sense that it needs > to be immutable. Well, when I look at '(10:20:3)', it doesn't look like a range, to me. Mostly because it has no precedent in Python: ()'s are used for grouping, and for function calls. They do not create tuples! :) In fact, the '(10:20:3)' syntax reminds me more of dates or machine-addresses than it does of ranges. For that reason I think it's better to live with xrange() ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From DavidA at ActiveState.com Wed Jul 12 18:32:43 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 12 Jul 2000 09:32:43 -0700 (Pacific Daylight Time) Subject: [Python-Dev] more SyntaxError subclasses! In-Reply-To: <009a01bfec17$f7fe3be0$f2a6b5d4@hagrid> Message-ID: On Wed, 12 Jul 2000, Fredrik Lundh wrote: > here are a bunch of other syntax error subclasses that > might be useful: +1. > (I'm extra interested in arguments from people who think TabError > and IndentationError is a good idea, but that this one sucks. I'm > not sure I want to hear from people who thinks that this one is a > great idea ;-) Sorry. =) > on a more serious note, I think it would be great to add a distinct > attribute to the SyntaxError instance (an error number, most likely). > this could be used by an IDE to provide concise info without having > to parse the error message. Indeed. From DavidA at ActiveState.com Wed Jul 12 18:34:36 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 12 Jul 2000 09:34:36 -0700 (Pacific Daylight Time) Subject: [Python-Dev] ! Message-ID: Keeping up w/ python dev, patches and checkins is getting to be a huge amount of work! Should we _thank_ lawyers for turning what was a small intense rush in getting things done before a release into a long intense rush? Perish the thought... +1 on the new python-dev community! --david From mwh21 at cam.ac.uk Wed Jul 12 18:48:16 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 12 Jul 2000 17:48:16 +0100 Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: "Fredrik Lundh"'s message of "Wed, 12 Jul 2000 17:31:10 +0200" References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> Message-ID: "Fredrik Lundh" writes: > using my latest Python 2.0 build, the interpreter > bombs if I type the following two commands: > > >>> def a(b): > ... global b > ... Hmm. Mine doesn't. What platform, stack, etc? > (1.5.2 says "name is local and global"). That's what mine says. "ConflictingScopeError" anyone? It's not a syntax error in my book... Cheers, M. From thomas at xs4all.net Wed Jul 12 18:59:20 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 18:59:20 +0200 Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: ; from mwh21@cam.ac.uk on Wed, Jul 12, 2000 at 05:48:16PM +0100 References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> Message-ID: <20000712185920.M7340@xs4all.nl> On Wed, Jul 12, 2000 at 05:48:16PM +0100, Michael Hudson wrote: > "Fredrik Lundh" writes: > > using my latest Python 2.0 build, the interpreter > > bombs if I type the following two commands: > > > > >>> def a(b): > > ... global b > > ... > Hmm. Mine doesn't. What platform, stack, etc? Mine does crash. The crash seems to be caused by a refcounting bug: the error gets detected, com_error() gets called, creates the appropriate error object, control flows back the way it was supposed to, but between com_error and PyErr_PrintEx() the error gets eradicated, resulting in a segmentation fault. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Wed Jul 12 18:57:57 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 11:57:57 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: Message-ID: <396CA395.D43D9570@prescod.net> Mark Hammond wrote: > > ... > > > On Windows, link-time compatibility is broken whenever we change the > > > second digit of the version number, e.g. 15, 16, 20. > > > > Yikes, lets not let that happen! > > Ideally, I agree. However, Im not sure how we can make this happen! Any > ideas on how we can achieve this? And I mean in a practical sense, rather > than with a hand-waving abstract theory - ie, specifically what > developement practices should change, or be put in place, to ensure this? Someone who is very interested in this backwards compatibility issue could make a stub Python15.dll that exposes the old API with the exact same (old) semantics. If it turns out to be easy, great. If it turns out to be difficult then we know that the APIs changed too much for it to be practical. If programs start crashing, we blame the person who promised backwads compatibility. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From mwh21 at cam.ac.uk Wed Jul 12 19:01:47 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 12 Jul 2000 18:01:47 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: "Mark Hammond"'s message of "Wed, 12 Jul 2000 10:42:43 -0400" References: Message-ID: "Mark Hammond" writes: > Sorry for the delay in responding to this stuff - Im at the MS PDC, and > demoing a new Python compiler that I'm suddenly allowed to talk about - but > that isnt the point of this mail :-] ? I'm curious now! [snip] > > > trying to solve here? So far, the only problem that came up was that > > > on Windows, you get an obscure crash when trying to load an extension > > > built for Python 1.5(.x). > > > > Yes, and this is a major problem, and is un-Windows-like. > > :-) "Major Crashes" are un-Windows like? What is happening to this > group - It amusing that this statement could be made without the Linux > geeks making smart-arsed comments :-) Looks like Billy Boy really _is_ > taking over the world :-) I was tempted, it has to be said. I did point a friend at it and giggle. nothing-useful-to-say-ly y'rs M. From thomas at xs4all.net Wed Jul 12 19:04:44 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 19:04:44 +0200 Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: <20000712185920.M7340@xs4all.nl>; from thomas@xs4all.net on Wed, Jul 12, 2000 at 06:59:20PM +0200 References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> <20000712185920.M7340@xs4all.nl> Message-ID: <20000712190444.N7340@xs4all.nl> On Wed, Jul 12, 2000 at 06:59:20PM +0200, Thomas Wouters wrote: > On Wed, Jul 12, 2000 at 05:48:16PM +0100, Michael Hudson wrote: > > "Fredrik Lundh" writes: > > Hmm. Mine doesn't. What platform, stack, etc? > > Mine does crash. Eh, Linux (RedHat 6.1), both 2.0b1-CVS-tree (recent) and python 1.6a2 (couple of weeks old) that is. Traceback of the exception is: #0 PyErr_NormalizeException (exc=0xbffff718, val=0xbffff71c, tb=0xbffff720) at errors.c:170 #1 0x8065501 in PyErr_PrintEx (set_sys_last_vars=1) at pythonrun.c:686 #2 0x80654d6 in PyErr_Print () at pythonrun.c:676 #3 0x80652fa in PyRun_SimpleString (command=0x821fc58 "def a(b): global b\n") at pythonrun.c:601 #4 0x8052a01 in Py_Main (argc=3, argv=0xbffff7d4) at main.c:256 #5 0x8052606 in main (argc=3, argv=0xbffff7d4) at python.c:10 though I doubt it's really helpful, as the actual bug is elsewhere. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mwh21 at cam.ac.uk Wed Jul 12 19:21:14 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 12 Jul 2000 18:21:14 +0100 Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: Thomas Wouters's message of "Wed, 12 Jul 2000 19:04:44 +0200" References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> <20000712185920.M7340@xs4all.nl> <20000712190444.N7340@xs4all.nl> Message-ID: Thomas Wouters writes: > On Wed, Jul 12, 2000 at 06:59:20PM +0200, Thomas Wouters wrote: > > On Wed, Jul 12, 2000 at 05:48:16PM +0100, Michael Hudson wrote: > > > "Fredrik Lundh" writes: > > > Hmm. Mine doesn't. What platform, stack, etc? > > > > Mine does crash. > > Eh, Linux (RedHat 6.1), both 2.0b1-CVS-tree (recent) and python 1.6a2 > (couple of weeks old) that is. Oh yeah; the same. Python built from a checkout about half an hour ago (so there's probably only been twenty or so checkins since then...). Next question: gc or not gc? My not crashing one had gc on, am now building one with gc off ... [just got to _sre.c] ... Nope. Steady as a rock. I'll leave this one to someone who has a problem! Cheers, M. From moshez at math.huji.ac.il Wed Jul 12 19:26:34 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 20:26:34 +0300 (IDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <20000712114945.F1607@thyrsus.com> Message-ID: On Wed, 12 Jul 2000 esr at thyrsus.com wrote: > Presto! All need for parallel loops has now disappeared. If anyone > doubts this, I will cheerfully produce source code for with(). Ummm.....you mean def with(*args): apply(map, (None,)+args) ;-) (Actually, this isn't right, since map() adds None's instead of stopping. But that should be a considered a design bug in map() anyway) What would people think about xmap(), which acts anologously to xrange(), IOW calculate lazilly instead of eagerly? Or even, calculate "on demand", without caching: class xmap: def __init__(self, func, *args): self.func = func self.args = args def __getitem__(self, i): arg = [None]*len(self.args) for j in range(len(self.args)): arg[j] = self.args[j][i] return apply(self.func, arg) Wouldn't this solve the parallel iteration problem? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul at prescod.net Wed Jul 12 19:25:36 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 12:25:36 -0500 Subject: [Python-Dev] Ranges References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> Message-ID: <396CAA0F.FE42AFD0@prescod.net> Thomas Wouters wrote: > > > How's this for obfuscation: > > > [0:10][0:10][0:10] > > Sure, but it's not more obfuscated than a long line of map(lambda ... > reduce(filter(map(lambda ... ))) I'm just commenting on the overloaded syntax of list construction and truncation. No big deal. > > And arguing from analogy, shouldn't > > > > range(0:bignum)[0:10:2] be [0:10:2] > > Yes, it should, but there is no way to enforce it, currently, because range > can be shadowed by a local or global variable. And it doesn't have to be > unintended, either. With range literals, that's no longer possible. That's not what I mean. Ignore the range. My point is, if list construction and truncation are going to be parallel, they should be really parallel. [0,1,2,3,4,5,6,7,8,10][0:5:2]==[0:5:2] I don't understand "extended slicing" so I don't know why the former doesn't work today. > > You probably shouldn't be able to shadow most builtins period. > > Why not ? It would introduce a number of problems: adding new builtin > functions would be as cagey as adding new reserved words (in effect, all > builtins *become* reserved words.) I said "most", not "all". Over time they could migrate from being builtin to being non-overridable. No one should define a function (not method, but function) called "map" or "dir". In practice, I haven't seen such a thing. If we make a "tuples" function then for a year or two it is fair game for overriding, the it becomes frozen. > For that reason I think it's better to live with xrange() ;) You could also use a lazy list comprehension (if we made list comprehensions lazy): [for x in [0:10:20]: x] That would make people think twice about using xrange (as it should...xrange isn't usually as efficient as they think!) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From moshez at math.huji.ac.il Wed Jul 12 19:32:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 20:32:06 +0300 (IDT) Subject: [Python-Dev] listcomp / par-for (summary) In-Reply-To: <396C915B.8B1A3A1B@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > > And it's not possible to shadow the builtin like with range. > > You probably shouldn't be able to shadow most builtins period. I vehemently disagree. One reason we can add builtins to our hearts contents is that builtins do not interfere with current code base in a way that keywords do. OTOH, I see no reason to reward this behaviour: I'm currently considering an optimization to the interpreter which would mean that most code would run faster, but code that shadows builtins would run slower. (This ideas is bouncing around my head for a long while. I'll post here when I have some semblence of design ready) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 21:29:43 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 21:29:43 +0200 (CEST) Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: <009101bfec16$35495fe0$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 12, 2000 05:31:10 PM Message-ID: <200007121929.VAA09996@python.inrialpes.fr> Fredrik Lundh wrote: > > using my latest Python 2.0 build, the interpreter > bombs if I type the following two commands: > > >>> def a(b): > ... global b > ... > > (1.5.2 says "name is local and global"). > > > Yes. This is because PyErr_PrintEx() is invoked with a NULL exception. And the exception has been cleared cleared in get_inprogress_dict(). The appended patch should fix it. Let me know whether it works for you. Jeremy, what's the point of calling PyErr_Clear() in get_inprogress_dict()? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 ------------------------------[ cut here ]---------------------------- *** CVS/Objects/object.c Wed Jul 12 17:27:41 2000 --- dev/Objects/object.c Wed Jul 12 21:21:52 2000 *************** *** 356,362 **** } inprogress = PyDict_GetItem(tstate_dict, _PyCompareState_Key); if (inprogress == NULL) { - PyErr_Clear(); inprogress = PyDict_New(); if (inprogress == NULL) return NULL; --- 356,361 ---- From pingster at ilm.com Wed Jul 12 21:26:51 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 12:26:51 -0700 (PDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14700.25459.555611.544163@bitdiddle.concentric.net> Message-ID: On Wed, 12 Jul 2000, Jeremy Hylton wrote: > File "", line 4 > def foo(bar): > ^ > SyntaxError: dedent does not match any outer indentation level [...] > I don't know what a dedent is. Nor do I know what "outer indentation > levels" are or how they might apply to the line "def foo(bar):". Sorry, this is a transcript from my locally compiled Python. The actual patch says "unindent" rather than "dedent". (In this situation Python 1.5 prints a line to stderr saying "inconsistent dedent" but the SyntaxError only says "invalid syntax".) The intended meaning is "this line is less indented than the previous one, but i can't determine what block it goes with because there's no surrounding block indented at the same level". In short form, this became: "unindent does not match any outer indentation level". -- ?!ng From pingster at ilm.com Wed Jul 12 21:31:01 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 12:31:01 -0700 (PDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <396C2D00.BDA23AF2@lemburg.com> Message-ID: tuples(), lists(), dict(), and indices() look pretty generally useful to me. I agree that they look like good candidates for builtins. On Wed, 12 Jul 2000, M.-A. Lemburg wrote: > irange(object[,indices]) > Builds a tuple of tuples (index, object[index]). If a sequence > indices is given, the indices are read from it. If not, then > the index sequence defaults to trange(len(object)). This one in particular looks really fabulous. +1 to put this in builtins. In order of usefulness (just imho of course): irange +1 tuples +0.5 indices +0.5 dict +0 lists +0 -- ?!ng From thomas at xs4all.net Wed Jul 12 21:40:03 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 21:40:03 +0200 Subject: [Python-Dev] SyntaxError patches In-Reply-To: ; from pingster@ilm.com on Wed, Jul 12, 2000 at 12:26:51PM -0700 References: <14700.25459.555611.544163@bitdiddle.concentric.net> Message-ID: <20000712214003.P7340@xs4all.nl> On Wed, Jul 12, 2000 at 12:26:51PM -0700, Ka-Ping Yee wrote: > On Wed, 12 Jul 2000, Jeremy Hylton wrote: > > File "", line 4 > > def foo(bar): > > SyntaxError: dedent does not match any outer indentation level > [...] > > I don't know what a dedent is. Nor do I know what "outer indentation > > levels" are or how they might apply to the line "def foo(bar):". > The intended meaning is "this line is less indented than the previous > one, but i can't determine what block it goes with because there's > no surrounding block indented at the same level". In short form, this > became: "unindent does not match any outer indentation level". If the objective is to make error messages more accessible understandable to newbies, how about: Can't figure out where this statement belongs or Can't figure out what block this statement belongs to or Can't figure out where you wanted to place this line or There seems to be something wrong with the indentation of this line etc. Or they could be more Monty Python-esque. Anyone use the unix util 'screen', and its 'nethack' mode ? Excellent tool, both ways :-) Since these are syntax errors, not runtime errors, I'd say it's safe to use a more accusing stance to the viewer (that is, they're very likely to be the cause !) and I don't really see why all error messages should be mathematically correct, and thus phrased in some kind of lawyerese ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From pingster at ilm.com Wed Jul 12 21:48:54 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 12:48:54 -0700 (PDT) Subject: [Python-Dev] Ranges In-Reply-To: <396CAA0F.FE42AFD0@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > That's not what I mean. Ignore the range. My point is, if list > construction and truncation are going to be parallel, they should be > really parallel. > > [0,1,2,3,4,5,6,7,8,10][0:5:2]==[0:5:2] Did you think they were different? I thought they *were* parallel. I would expect: >>> range(0, 5, 2) [0, 2, 4] >>> [0:5:2] [0, 2, 4] >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] [0, 2, 4] >>> range(1000)[0:5:2] [0, 2, 4] Right? Am i misunderstanding how [x:y:z] should work? -- ?!ng From paul at prescod.net Wed Jul 12 22:03:29 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 15:03:29 -0500 Subject: [Python-Dev] Ranges References: Message-ID: <396CCF11.B5593E2C@prescod.net> Ka-Ping Yee wrote: > > >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] > [0, 2, 4] Well, today this is syntactically correct but it doesn't work as you (or I) predict. I don't know if that's because nobody has implemented it yet or if extended slices mean something other than what I think you and I think they should mean: Python 2.0b1 (#12, Jul 1 2000, 13:14:33) Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] Traceback (most recent call last): File "", line 1, in ? TypeError: sequence index must be integer The documentation on extended slicing is very thin, but if it doesn't do this, I'm not sure what it does! -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From pingster at ilm.com Wed Jul 12 22:22:07 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 13:22:07 -0700 (PDT) Subject: [Python-Dev] Ranges In-Reply-To: <396CCF11.B5593E2C@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > Python 2.0b1 (#12, Jul 1 2000, 13:14:33) > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] > Traceback (most recent call last): > File "", line 1, in ? > TypeError: sequence index must be integer Yeah. At the moment, [:] calls __getslice__ but [::] calls __getitem__ (ick). The list object is getting a call to __getitem__(slice(0, 5, 2)) and __getitem__ wants an integer. I was assuming this would get cleaned up along with the introduction of [x:y:z]-style range-makers (i recall Guido posting a suggestion for how to do so a little while back). Ah, yes: http://www.python.org/pipermail/python-dev/2000-July/012681.html The issues were - handling [:] and [::] consistently - allowing non-integer indices - letting user-defined objects do their own handling of negative indices I believe the two possibilities were __getitem__ gets either an index or a special slice object __getslice__ is deprecated (when missing, __getitem__ gets the slice args) and __getitem__ always gets an index __getslice__ gets three arguments, all optional, defaulting to None The latter isn't backward-compatible, but it makes a heckuva lot more sense. -- ?!ng From barry at scottb.demon.co.uk Wed Jul 12 22:30:45 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Wed, 12 Jul 2000 21:30:45 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Message-ID: <000001bfec40$0eb3a6e0$060210ac@private> > This is where we are now. I agree that we should not crash, but it seems > to me you havent solved anything - individual .pyd authors needing to tell > users about each individual .pyd isnt a solution. At least if Python can detect that a .PYD is out of date you know to ask for a newer .PYD or build it yourself. A crash is bad PR for the .PYD and Python. > > > You can already get the version string by > > > looking at Py_GetVersion() -- this also answers the question of how a > > > version is represented. > > > > True. And on Windows, there is a standard Version resource > > string which gives the DLL version, and can be read without > > loading the DLL. This string is referenced by the Wise (and > > other) installers to decide whether a DLL is newer and should > > be replaced. > > Im not sure how this helps us. Do you mean that "initfoo" should use the > Windows resource/version APIs to determine if it can load? As I pointed out you cannot use Py calls from a .PYD to find out the version as the .PYD calls the function in the old PYTHON15.DLL not the new one. BArry From paul at prescod.net Wed Jul 12 19:44:29 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 12:44:29 -0500 Subject: [Python-Dev] re: list comprehension / pop quiz References: Message-ID: <396CAE7D.B85AA3FB@prescod.net> Moshe Zadka wrote: > > What would people think about xmap(), which acts anologously to xrange(), > IOW calculate lazilly instead of eagerly? Or even, calculate "on demand", > without caching: > .... > Wouldn't this solve the parallel iteration problem? I don't think that using a function called "xmap" to build tuples is very intuitive to start with. What's so wrong with a builtin called "tuples()"? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Wed Jul 12 20:10:56 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 13:10:56 -0500 Subject: [Python-Dev] Par-for/range References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> Message-ID: <396CB4B0.EE284A39@prescod.net> Thomas Wouters wrote: > > ... > > For that reason I think it's better to live with xrange() ;) Thinking some more... If we had first class range syntax then it would be relatively easy to recognize the pattern for i in [x:y:z]: .... Then we could generate a special FOR_INTS bytecode. I've heard that "C" has a pretty efficient implementation of that construct. That would wipe out 96.3% of the need for xrange or tuplerange or whatever you want to call it. We could probably deprecate both functions and let the rare person who really wants an xrange use a class or math.xrange() or mxtools.xrange() or a lazy list comprehension (if we invent those!). Plus, if your loops are so large that they need xrange, you would probably get an interesting speedup from using a real C for-loop instead of an object! I mean for small values xrange is slower than range and when you think about what range is doing under the covers. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gvwilson at nevex.com Wed Jul 12 22:47:44 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 12 Jul 2000 16:47:44 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <396CAE7D.B85AA3FB@prescod.net> Message-ID: > Paul Prescod wrote: > I don't think that using a function called "xmap" to build tuples is > very intuitive to start with. What's so wrong with a builtin called > "tuples()"? I'm nervous about the readability of "tuple/tuples" and "map/xmap", having sometimes misread "xrange" for "range". (We take marks off student assignments that contain functions whose names only differ by one letter, don't we?) Greg From mwh21 at cam.ac.uk Wed Jul 12 23:03:53 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 12 Jul 2000 22:03:53 +0100 Subject: [Python-Dev] Par-for/range In-Reply-To: Paul Prescod's message of "Wed, 12 Jul 2000 13:10:56 -0500" References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> <396CB4B0.EE284A39@prescod.net> Message-ID: Paul Prescod writes: > Thinking some more... > > If we had first class range syntax then it would be relatively easy to > recognize the pattern > > for i in [x:y:z]: > .... > > Then we could generate a special FOR_INTS bytecode. I've heard that "C" > has a pretty efficient implementation of that construct. Hmm, yes, but how on earth would you implement that in ceval.c? You'd need another eval loop inside the code for FOR_INTS! (unless I'm being dense, of course). > That would wipe out 96.3% of the need for xrange or tuplerange or > whatever you want to call it. We could probably deprecate both functions > and let the rare person who really wants an xrange use a class or > math.xrange() or mxtools.xrange() or a lazy list comprehension (if we > invent those!). > > Plus, if your loops are so large that they need xrange, you would > probably get an interesting speedup from using a real C for-loop instead > of an object! I mean for small values xrange is slower than range and > when you think about what range is doing under the covers. To invent more statistics on the spot, I'll declare that loop overhead is a problem in about 3.4% of all interesting loops; what we need is a way to execute the body quicker... Cheers, M. From thomas at xs4all.net Wed Jul 12 23:19:42 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 23:19:42 +0200 Subject: [Python-Dev] Par-for/range In-Reply-To: <396CB4B0.EE284A39@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 01:10:56PM -0500 References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> <396CB4B0.EE284A39@prescod.net> Message-ID: <20000712231942.Q7340@xs4all.nl> On Wed, Jul 12, 2000 at 01:10:56PM -0500, Paul Prescod wrote: > Thomas Wouters wrote: > > For that reason I think it's better to live with xrange() ;) > If we had first class range syntax then it would be relatively easy to > recognize the pattern > > for i in [x:y:z]: > .... > > Then we could generate a special FOR_INTS bytecode. I've heard that "C" > has a pretty efficient implementation of that construct. Yes. This was one of the reasons Guido was interested in this. (We talked about this in private email before I implemented it ;) > Plus, if your loops are so large that they need xrange, you would > probably get an interesting speedup from using a real C for-loop instead > of an object! I mean for small values xrange is slower than range and > when you think about what range is doing under the covers. Well, with the new 'sq_contains' PySequenceMethods member, the operation: number in xrange(19,23578294,3)*393 # for instance ;) also gets very efficient. A *lot* more efficient than using the equivalent [ra::ge] syntax in any case. That would be one reason to add at least a 'BUILD_XRANGE' bytecode, so when the compiler is made sufficiently intelligent, it could issue 'BUILD_XRANGE' opcodes instead of BUILD_RANGE opcodes for if x in [:y:z]: and other instances where the resulting list isn't stored anywhere, so will never be modified. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Wed Jul 12 23:28:26 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 23:28:26 +0200 Subject: [Python-Dev] Par-for/range In-Reply-To: ; from mwh21@cam.ac.uk on Wed, Jul 12, 2000 at 10:03:53PM +0100 References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> <396CB4B0.EE284A39@prescod.net> Message-ID: <20000712232826.R7340@xs4all.nl> On Wed, Jul 12, 2000 at 10:03:53PM +0100, Michael Hudson wrote: > Paul Prescod writes: > > Thinking some more... > > > > If we had first class range syntax then it would be relatively easy to > > recognize the pattern > > > > for i in [x:y:z]: > > .... > > > > Then we could generate a special FOR_INTS bytecode. I've heard that "C" > > has a pretty efficient implementation of that construct. > Hmm, yes, but how on earth would you implement that in ceval.c? You'd > need another eval loop inside the code for FOR_INTS! (unless I'm > being dense, of course). Nah. We can't use the C for-loop for this, unless the bytecode interpreter is entirely rewritten. The FOR_INT opcode would be something like: on entry, stack contains r, i where r is range-object specifying (start/)step/end, i is loop counter i is incremented by step, checked against end, and if loop hasn't ended yet, r, new 'i' and old 'i' are pushed on the stack, so it contains: r, i+step, i and the rest of the bytecode can remain the same (assign top value to name, etc.) > To invent more statistics on the spot, I'll declare that loop overhead > is a problem in about 3.4% of all interesting loops; what we need is a > way to execute the body quicker... define 'problem' ;) If we can speed things up while keeping the functionality the same, the syntax clearer and the code only slightly more complicated, why not ? :-) Granted, though, if the issue is overall code speed, this isn't going to cut it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gward at mems-exchange.org Wed Jul 12 23:43:39 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 12 Jul 2000 17:43:39 -0400 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <20000711151740.T26534@xs4all.nl>; from thomas@xs4all.net on Tue, Jul 11, 2000 at 03:17:41PM +0200 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> <20000710141638.R29590@lyra.org> <200007111348.IAA04699@cj20424-a.reston1.va.home.com> <20000711151740.T26534@xs4all.nl> Message-ID: <20000712174339.A5836@ludwig.cnri.reston.va.us> On 11 July 2000, Thomas Wouters said: > Actually, I was referring to the trick PIL and other extension modules use > to build their own Makefile based on Python's. I'm not sure how portable > that particular Makefile is, however. I'm one of those types that use > 'gmake' on systems that do not have GNU make as the default make ;-) Makefile.pre.in is obsolete. See http://www.python.org/sigs/distutils-sig/ > And forgive me for saying this, but I think providing a good, > self-configuring but slightly unportable Makefile.pre.in *and* a README > (and/or example) that shows how to do it by hand on old/incapacitated > systems, is preferable over just providing a completely unportable Makefile > and a README that shows how to do it on other systems :-) Agreed, but of course the instructions are different (and much easier!) now. Greg From jack at oratrix.nl Wed Jul 12 23:51:17 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 23:51:17 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib dospath.py,1.13,1.14 macpath.py,1.22,1.23 ntpath.py,1.24,1.25 posixpath.py,1.31,1.32 In-Reply-To: Message by Skip Montanaro , Wed, 12 Jul 2000 09:56:00 -0700 , <200007121656.JAA09687@slayer.i.sourceforge.net> Message-ID: <20000712215122.B4E13E2679@oratrix.oratrix.nl> Skip, one bug in posixpath.commonprefix already: you use os.sep where you should use '/'. The pathname-manging routines in xxxpath have always worked on different platforms too (so you can interpret, say, a tarfile on MSDOS), and if I remember correctly this is especially important for posixpath because it's used in some of the url modules. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From bckfnn at worldonline.dk Wed Jul 12 23:48:11 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Wed, 12 Jul 2000 21:48:11 GMT Subject: [Python-Dev] Ranges In-Reply-To: References: Message-ID: <396ce4b5.20282194@smtp.worldonline.dk> [Paul Prescod] >Ka-Ping Yee wrote: >> >> >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] >> [0, 2, 4] > >Well, today this is syntactically correct but it doesn't work as you (or >I) predict. I don't know if that's because nobody has implemented it yet >or if extended slices mean something other than what I think you and I >think they should mean In current JPython: JPython 1.1+07 on java1.3.0 (JIT: null) Copyright (C) 1997-1999 Corporation for National Research Initiatives >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] [0, 2, 4] [Ka-Ping Yee} >Ah, yes: http://www.python.org/pipermail/python-dev/2000-July/012681.html > >The issues were > > - handling [:] and [::] consistently > - allowing non-integer indices > - letting user-defined objects do their own handling of negative indices > >I believe the two possibilities were > > __getitem__ gets either an index or a special slice object > __getslice__ is deprecated (when missing, __getitem__ gets the slice args) > >and > > __getitem__ always gets an index > __getslice__ gets three arguments, all optional, defaulting to None > >The latter isn't backward-compatible, but it makes a heckuva lot >more sense. AFAICT JPython already follows the first of the two possibilities. (I'm not suggesting what python-the-language should do but I too find the current behaviour of item/slice is IMO confusing). regards, finn JPython 1.1+07 on java1.3.0 (JIT: null) Copyright (C) 1997-1999 Corporation for National Research Initiatives >>> >>> class S1: ... def __getitem__(self, i): ... print "s1.__getitem__", i ... >>> a = S1() >>> >>> a[1] s1.__getitem__ 1 >>> a[:] s1.__getitem__ None:None:1 >>> a[1:2] s1.__getitem__ 1:2:1 >>> a[1:2:3] s1.__getitem__ 1:2:3 >>> a['a':'z'] s1.__getitem__ 'a':'z':1 >>> a['a':'z':2] s1.__getitem__ 'a':'z':2 >>> >>> >>> class S2: ... def __getslice__(self, i, a): ... print "s2.__getslice__", i, a ... def __len__(self): ... return 10 ... >>> a = S2() >>> >>> a[1] Traceback (innermost last): File "", line 1, in ? AttributeError: __getitem__ >>> a[:] s2.__getslice__ 0 2147483647 >>> a[1:2] s2.__getslice__ 1 2 >>> a[1:2:3] Traceback (innermost last): File "", line 1, in ? AttributeError: __getitem__ >>> a['a':'z'] s2.__getslice__ a z >>> a['a':'z':2] Traceback (innermost last): File "", line 1, in ? AttributeError: __getitem__ >>> a[-1:4] s2.__getslice__ -1 4 >>> >>> class S3: ... def __getitem__(self, i): ... print "s3.__getitem__", i ... def __getslice__(self, i, a): ... print "s3.__getslice__", i, a ... >>> a = S3() >>> >>> a[1] s3.__getitem__ 1 >>> a[:] s3.__getslice__ 0 2147483647 >>> a[1:2] s3.__getslice__ 1 2 >>> a[1:2:3] s3.__getitem__ 1:2:3 >>> a['a':'z'] s3.__getslice__ a z >>> a['a':'z':2] s3.__getitem__ 'a':'z':2 >>> From MarkH at ActiveState.com Thu Jul 13 00:11:58 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Wed, 12 Jul 2000 18:11:58 -0400 Subject: [Python-Dev] Python .NET (was Preventing 1.5 extensions crashing under 1.6/2.0 Python) In-Reply-To: Message-ID: > "Mark Hammond" writes: > > > Sorry for the delay in responding to this stuff - Im at the MS PDC, and > > demoing a new Python compiler that I'm suddenly allowed to > talk about - but > > that isnt the point of this mail :-] > > ? I'm curious now! There is a Python compiler available for the Microsoft .NET framework. Much of the press will have details on this emerging. A CNET article can be found at http://news.cnet.com/news/0-1003-200-2240702.html?tag=st.ne.1430735..ni This new compiler could be compared, conceptually, with JPython - it is a completely new implementation of Python. It has a compiler that generates native Windows .DLL/.EXE files. It uses a runtime that consists of a few thousand lines of C# (C-Sharp) code. The Python programs can be debugged at the source level with Visual Studio 7, as well as stand-alone debuggers for this environment. Python can sub-class VB or C# classes, and vice-versa. Unfortunately, there will not be a public release of their SDK for a couple of months - so the only people able to use this compiler are people who attended the PDC, and hence have the pre-beta SDK on their conference CDs. The compiler is looking pretty reasonable. pystone.py (amongst others, of course) compiles and runs. Im not going to tell you the results yet, 'cos they arent too good ;-) However, this should be quite exciting for the Python community. The general feel of the conference here is that the MS .NET technology is exciting and a good thing. I predict that the Windows community will embrace this technology, and having Python be a first-class citizen is a good thing! It _is_ a radical change, so I predict it wont be really significant on windows for a couple of years yet. Future work on this compiler will be under the ActiveState banner. However, the compiler and the runtime are all open source. The compiler is written in CPython, and uses win32com to get at the Reflection::Emit APIs provided by .NET. All the existing work has been done mainly by me, with some code and advice from Greg. Now the NDA is lifted, I hope (some of) the Python community will get behind this, and take advantage of the open-sourceness of the compiler and runtime, and help us turn this into an excellent language for this environment. All good stuff! Mark. From MarkH at ActiveState.com Thu Jul 13 00:14:13 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Wed, 12 Jul 2000 18:14:13 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <000001bfec40$0eb3a6e0$060210ac@private> Message-ID: > > This is where we are now. I agree that we should not crash, > > but it seems to me you havent solved anything - individual > > .pyd authors needing to tell users about each individual > > .pyd isnt a solution. > At least if Python can detect that a .PYD is out of date you know > to ask for a newer .PYD or build it yourself. A crash is bad PR for > the .PYD and Python. We all agree on this - hence this discussion. My point was that I'm not clear how the proposal moved us closer to this goal. > > > True. And on Windows, there is a standard Version resource > > > string which gives the DLL version, and can be read without > > > loading the DLL. This string is referenced by the Wise (and > > > other) installers to decide whether a DLL is newer and should > > > be replaced. > > > > Im not sure how this helps us. Do you mean that "initfoo" > > should use the Windows resource/version APIs to determine > > if it can load? > As I pointed out you cannot use Py calls from a .PYD to find out > the version as the .PYD calls the function in the old PYTHON15.DLL > not the new one. Firstly, this doesn't answer my question, so I'm not sure why you needed to restate this assertion. I can only assume that the answer to my question, in your opinion, is "yes"? Secondly, I'm not sure why this is a problem. Sure, we can't use the version number, but the extension could, for example, call Py_IsInitialized() - this is likely to be a good indication if our linked DLL is the "correct" one for this process. The problem is not intractable - someone who cares enough should put together a patch, test it, and submit it. Talk-is-cheap-ly, Mark. From gward at mems-exchange.org Thu Jul 13 00:18:53 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 12 Jul 2000 18:18:53 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007121318.IAA14063@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 12, 2000 at 08:18:04AM -0500 References: <20000712031358.X29590@lyra.org> <200007121318.IAA14063@cj20424-a.reston1.va.home.com> Message-ID: <20000712181853.A7355@ludwig.cnri.reston.va.us> On 12 July 2000, Guido van Rossum said: > I would love to have a mechanism (run by configure or maybe better by > makesetup) that automatically determines if a particular external > library package is available. Come to think of it, in first > approximation, makesetup could easily parse the -I, -L and -l options > you specify for a particular extension and only build it if it can > find all those... The Distutils "config" command is *achingly* close to supporting this kind of trickery. (Yes, I finally buckled and started implementing Autoconf in Python. Turned out not to be too hard.) I promised I'll think really hard about how to get it working really well next week, when I'm on holiday... ;-) Greg From peter at schneider-kamp.de Thu Jul 13 02:42:28 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 13 Jul 2000 00:42:28 +0000 Subject: [Python-Dev] simple syntax error bombs interpreter References: <200007121929.VAA09996@python.inrialpes.fr> Message-ID: <396D1074.48F7554A@schneider-kamp.de> Vladimir Marangozov wrote: > > Fredrik Lundh wrote: > > > > using my latest Python 2.0 build, the interpreter > > bombs if I type the following two commands: > > > > >>> def a(b): > > ... global b > > ... > > > > (1.5.2 says "name is local and global"). > > > > That's the same kind of situation I had with my >>> def f(a,a): ... print a segfault > The appended patch should fix it. Let me know whether it works for you. The appended patch works for me. Now my "duplicate arguments" error also works fine. Is there an issue with removing the PyErr_Clear()? Does it serve any just purpose? if-not-please-get-rid-of-it-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul at prescod.net Thu Jul 13 00:52:56 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 17:52:56 -0500 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators for matrix computation] Message-ID: <396CF6C8.94B84B9B@prescod.net> You can guess my instinctive reaction...still, I feel for these guys competing with pricy domain-specific software. -------- Original Message -------- Subject: Discussion: Introducing new operators for matrix computation Date: Wed, 12 Jul 2000 19:32:32 GMT From: hzhu at knowledgetrack.com (Huaiyu Zhu) Reply-To: hzhu at users.sourceforge.net Organization: Giganews.Com - Premium News Outsourcing To: python-list at python.org Newsgroups: comp.lang.python We are at a crucial juncture concerning introduction of new operators into Python for matrix computation, 1. Experiences with Matlab show that different operators for matrix and elementwise operators are very important 2. It is difficult to add .* and ./ as . is already a valid token. It seems that next candidate on the standard keyboard is @. 3. Gregory Lielens has just implemented a patch that could parse additional operators containing @ a at b is equivalent to a*b, overloaded using __mmul__ and __rmmul__ a@/b a/b __mrdiv__ and __rmrdiv__ a/@b b/a __mldiv__ and __rmldiv__ a@@b a**b __mpow__ and __rmpow__ He indicates similar constructions can be added easily. We intend to add these operators together with Thomas Wouters's augmented assignment operators (+=,*=, etc) to MatPy, but before that several decisions need to be made. First, the main choices: 1. Use a*b as matrix mul, and a@*b as elementwise mul. Pros: - Consistent with Matlab. - Consistent with current MatPy. - Convenient for matrix computations. Cons: - Inconsistent with NumPy - How to differentiate left and right div (matlab a\b and a/b)? 2. Use a@*b as matrix mul, and a*b as elementwise mul. Pros: - Consistent with NumPy - Can use a@/b and a/@b as matlab a/b and a\b. - Can use a at b as inner product so that a at b works irrespective of whether a and b are row or col operators. Cons: - Inconsistent with current MatPy. Need great effort to switch. - Using two symbol operator for matrix mul is cumbersome for long formulas. - It kind of looks ugly. 3. Use a at b as matrix mul, and a*b as elementwise mul. This has most of the pros and cons of choice 2, except Pros: - Single symbol operators for matrix mul and element mul. Cons: - Can't use a at b as inner product. Just to add to the agony, here are a few contrary views: 1. Consistency with Matlab is not necessarily good. In Matlab operators default to matrix (cf * and .*) but functions default to elementwise (cf exp and expm). In Python ** is defined by __pow__. Should it be consistent with pow the function or ** the operator? 2. Consistency with NumPy is not necessarily good. Currently one can use MatPy and NumPy at the same time. a*b will be matrixwise for MatPy and elementwise for NumPy. This is convenient when each usage is dominant in some part of a program. Removing this difference and MatPy will lose a lot of appeal when it is needed. 3. Although it is relatively difficult to switch the usage in MatPy, it is still a good time if we deem this to be A Good Thing. When the status is changed to beta from alpha it would be next to impossible to switch. To throw you completely off the track, here is one additional feature request that would great please mathematicians and greatly annoy computer scientists: Use ^ and @^ for matrix power. Currently ^ is defined as xor which is of sufficiently low level that is unlikely to occur with matrix computations. Note that this is not in our plan right now. One other thing that will be of great efficiency value (whenver somebody comes forward to do it) is to parse := as assignment. This way we can let a=b be simple reference assignment without creating a new Matrix object. The implementors of both previous patches have cautioned that Guido is unlikely to adopt the patch for the .* or @* operators. But I'm quite confident that he can be persuaded. There is a large number of users of Matlab and Octave (maybe even more than users of Python), and there is no fundamental reason they cannot use Python for doing the same thing, provided that we are allowed to add this little additional operator. :-) What other incentives are needed to persuade Guido? Here's a quote from Gregory, > they make a huge difference in readability of code dealing with linear > algebra, in particular when using small matrices. Such operators explain > partly the popularity of Matlab-like tools, imho. I can argue that linear algebra is very important for Python, perhaps even more important than complex numbers, but this is off topic. So all your comments, suggestions and flames a invited. I just have a small request: As this is getting too long, please reply separately to different parts of this article, so that the discussion threads remain manageable. -- Huaiyu Zhu hzhu at users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net -- http://www.python.org/mailman/listinfo/python-list From esr at thyrsus.com Thu Jul 13 01:23:25 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 19:23:25 -0400 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: ; from ping@lfw.org on Wed, Jul 12, 2000 at 02:35:21AM -0700 References: Message-ID: <20000712192325.F799@thyrsus.com> Ka-Ping Yee : > Jodinat greidar fablo! Ruinon flast; ruinon flast. Thorvon > whananadak yum, onk triplation is dortiful. <0.5 wink> > > Ecky-ecky-ecky-ecky-pikang-zoop-boing? > > > -- ?!ng :pingspeak: n. [Python development list] Attractive but incomprehensible babble. Pingspeak is distinguished from lower-quality nonsense by being at least phonotactically plausible, as if the author is writing in a language you don't know. -- Eric S. Raymond Every election is a sort of advance auction sale of stolen goods. -- H.L. Mencken From esr at thyrsus.com Thu Jul 13 01:26:55 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 19:26:55 -0400 Subject: [Python-Dev] File Object Copy In-Reply-To: <20000712014338.Q29590@lyra.org>; from gstein@lyra.org on Wed, Jul 12, 2000 at 01:43:38AM -0700 References: <20000712014338.Q29590@lyra.org> Message-ID: <20000712192655.G799@thyrsus.com> Greg Stein : > Put the bugger in shutil for now. Step two: propose a new organization. I agree. -- Eric S. Raymond Everything you know is wrong. But some of it is a useful first approximation. From esr at thyrsus.com Thu Jul 13 01:40:53 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 19:40:53 -0400 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <14700.29709.259658.864250@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 12, 2000 at 09:35:09AM -0400 References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> Message-ID: <20000712194053.J799@thyrsus.com> Barry A. Warsaw : > Is weave() perhaps a better name? I *like* it. Better than the `with()' I independently invented. I think the fact that three people indeoendently invented with()/parallel()/weave()/zip() in responmse to the syntax discussion is in itself pretty good evidence that a generator builtin would be better than new syntax. -- Eric S. Raymond In recent years it has been suggested that the Second Amendment protects the "collective" right of states to maintain militias, while it does not protect the right of "the people" to keep and bear arms. If anyone entertained this notion in the period during which the Constitution and the Bill of Rights were debated and ratified, it remains one of the most closely guarded secrets of the eighteenth century, for no known writing surviving from the period between 1787 and 1791 states such a thesis. -- Stephen P. Halbrook, "That Every Man Be Armed", 1984 From esr at thyrsus.com Thu Jul 13 01:42:52 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 19:42:52 -0400 Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C9661.3EF03755@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 11:01:37AM -0500 References: <396BA425.2EF3B11F@prescod.net> <14699.59823.710880.896491@anthem.concentric.net> <14700.32671.461502.666561@beluga.mojam.com> <396C9661.3EF03755@prescod.net> Message-ID: <20000712194252.K799@thyrsus.com> Paul Prescod : > "Stitch" and "with" are okay, but I'd like to hear someone debunk the > names used today by MAL. They seemed very logical to me. I'd just change > the semantics to be lazy in a couple of cases. I would be happy with weave(), with(), or MAL's names. I think zip is best avoided for reasons already discussed. -- Eric S. Raymond "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), From klm at digicool.com Thu Jul 13 01:54:59 2000 From: klm at digicool.com (Ken Manheimer) Date: Wed, 12 Jul 2000 19:54:59 -0400 (EDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C9661.3EF03755@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > Skip Montanaro wrote: > > > > BAW> Alternatives (as Greg I think brought up): pairwise(), maybe > > BAW> zipper() for zip() since it's more evocative. > > > > "zip" already has a lot of compression connotations. How about "stitch", as > > in "stitch two lists together"? > > "Stitch" and "with" are okay, but I'd like to hear someone debunk the > names used today by MAL. They seemed very logical to me. I'd just change > the semantics to be lazy in a couple of cases. > > >>> tuple([1,2,3]) > (1,2,3) > > >>> tuples([1,2,3],[4,5,6]) > > > >>> list((1,2,3)) > [1,2,3] > > >>> lists((1,2,3),(4,5,6)) > > > >>> dict([(1,2),(3,4),(5,6)]) > {1:2,3:4,5:6} How about this different name, with a somewhat different approach: Name is "furl", with inverse "unfurl". First argument is the target-type of the result: >>> furl([], (1, 2, 3), [4, 5, 6,]) [[1,4], [2,5], [3,6]] >>> furl((), [1,2,3],(4,5,6)) ((1,4), (2,5), (3,6)) >>> furl({}, (1,2,3), "abc") {1:'a', 2:'b', 3:'c'} >>> unfurl([], [1,4], [2,5], [3,6]) [[1, 2, 3], [4, 5, 6]] >>> unfurl((), [1,4], [2,5], [3,6]) ((1, 2, 3), (4, 5, 6)) >>> unfurl((), {1:'a', 2:'b', 3:'c'}) ((1, 2, 3), ('a', 'b', 'c')) Being explicit about the type of the result, rather than keying on the type of both arguments, means you're not surprised by an exception when one of your vars had a tuple and the other had a list. Better explicit than implicit, ay? I'm not at all opposed yielding generators, like in skip's example. Seems like comprehensions and simple notations for infinite generators - "[1..]" - would deliver the benefits of concise, arbitrarily elaborate stream sources where xrange, alone, falls way short. I really like "furl" - it may help to appreciate the charm if you say it out loud a few times: "furl". "furl". "furl". Ahhh. :-) Ken From akuchlin at cnri.reston.va.us Thu Jul 13 02:13:44 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Wed, 12 Jul 2000 20:13:44 -0400 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators for matrix computation] In-Reply-To: <396CF6C8.94B84B9B@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 05:52:56PM -0500 References: <396CF6C8.94B84B9B@prescod.net> Message-ID: <20000712201344.A1974@newcnri.cnri.reston.va.us> On Wed, Jul 12, 2000 at 05:52:56PM -0500, Paul Prescod quoted: >From: hzhu at knowledgetrack.com (Huaiyu Zhu) >The implementors of both previous patches have cautioned that Guido is >unlikely to adopt the patch for the .* or @* operators. But I'm quite >confident that he can be persuaded. There is a large number of users of Why not simply write a new parser for this application that generates the desired semantics? Maintaining a complete fork of the Python source might not be necessary if Jeremy's Python parsing/compiling framework could be easily modified to implement the new operators. (While a Python variant isn't something I'm enthused about, one language can't be all things to all people, and I don't see why matrix operations are so important as to get extra specialized operators; lots of people use Python for text processing or for COM, so why shouldn't special syntax be added for *those* applications? Having a special parser also means that other matrix-specific language changes could be made.) --amk From guido at beopen.com Thu Jul 13 03:38:28 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 20:38:28 -0500 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Your message of "Wed, 12 Jul 2000 19:40:53 -0400." <20000712194053.J799@thyrsus.com> References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> <20000712194053.J799@thyrsus.com> Message-ID: <200007130138.UAA01580@cj20424-a.reston1.va.home.com> > Barry A. Warsaw : > > Is weave() perhaps a better name? [ESR] > I *like* it. Better than the `with()' I independently invented. > > I think the fact that three people indeoendently invented > with()/parallel()/weave()/zip() in responmse to the syntax discussion > is in itself pretty good evidence that a generator builtin would be better > than new syntax. Yes, I agree. Main reason: it's trivial to combine this with list comprehensions, while the ';' notation had real problems there. My bid for a name: splice(). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Thu Jul 13 03:06:57 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 21:06:57 -0400 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <200007130138.UAA01580@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 12, 2000 at 08:38:28PM -0500 References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> <20000712194053.J799@thyrsus.com> <200007130138.UAA01580@cj20424-a.reston1.va.home.com> Message-ID: <20000712210657.Q799@thyrsus.com> Guido van Rossum : > Yes, I agree. Main reason: it's trivial to combine this with list > comprehensions, while the ';' notation had real problems there. Perhaps this frees up semicolon for use in the list-comprehension constructor syntax. BTW, I think whoever it was that suggested lazy eval for comprehensions was right on -- but that ties into the larger issue of generators and continuations. Really, a list comprehension ought to be syntactic sugar for an Icon-like generator object. > My bid for a name: splice(). Wearing my English-usage-pedant hat, I must regretfully judge this inferior to weave(). The reason has to do with the spatial geometry implied by the verbs. You *splice* two ropes together end-to-end; the proper data-structure analogy is with concatenation, and indeed splice() in Perl is a sort of generalized slice'n'dicer for sequences. On the other hand, you *weave* two threads together side by side to form a parallel bundle. Much closer image. OTOH, MAL's group of related constructors is pretty cool. -- Eric S. Raymond The real point of audits is to instill fear, not to extract revenue; the IRS aims at winning through intimidation and (thereby) getting maximum voluntary compliance -- Paul Strassel, former IRS Headquarters Agent Wall St. Journal 1980 From pingster at ilm.com Thu Jul 13 03:07:33 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 18:07:33 -0700 (PDT) Subject: [Python-Dev] co_lnotab and SET_LINENO Message-ID: Now that we have co_lnotab, why do we still generate SET_LINENO opcodes? -- ?!ng From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 03:26:23 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 03:26:23 +0200 (CEST) Subject: [Python-Dev] co_lnotab and SET_LINENO In-Reply-To: from "Ka-Ping Yee" at Jul 12, 2000 06:07:33 PM Message-ID: <200007130126.DAA10951@python.inrialpes.fr> Ka-Ping Yee wrote: > > Now that we have co_lnotab, why do we still generate > SET_LINENO opcodes? It has been discussed before. To summarize: - because these opcodes generate the callbacks from C to Python - the debugger relies on them - I haven't had the time to look seriously at the debugger and make it work without them. (this relates with breakpoints setting which requires generating callbacks for every source line) And this is where we are. If you're volunteering to look into this, I'll spend some time summarizing the pointers about this thread + the existing code in the area. Otherwise, I won't bother -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one at email.msn.com Thu Jul 13 03:38:00 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 12 Jul 2000 21:38:00 -0400 Subject: [Python-Dev] ! In-Reply-To: Message-ID: [David Ascher] > Keeping up w/ python dev, patches and checkins is getting to be a huge > amount of work! > > Should we _thank_ lawyers for turning what was a small intense rush in > getting things done before a release into a long intense rush? Perish the > thought... > > +1 on the new python-dev community! Except it's largely still the same python-dev community: the perceived zoom in productivity is entirely due to my forcing patch management onto SourceForge -- well, either that, or that the laywers keep Guido so busy that he can't take time to interfere with progress anymore . whatever-the-cause-don't-jinx-it-ly y'rs - tim From guido at beopen.com Thu Jul 13 04:41:06 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 21:41:06 -0500 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Your message of "Wed, 12 Jul 2000 21:06:57 -0400." <20000712210657.Q799@thyrsus.com> References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> <20000712194053.J799@thyrsus.com> <200007130138.UAA01580@cj20424-a.reston1.va.home.com> <20000712210657.Q799@thyrsus.com> Message-ID: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> > > My bid for a name: splice(). > > Wearing my English-usage-pedant hat, I must regretfully judge this > inferior to weave(). The reason has to do with the spatial geometry > implied by the verbs. > > You *splice* two ropes together end-to-end; the proper data-structure > analogy is with concatenation, and indeed splice() in Perl is a sort > of generalized slice'n'dicer for sequences. > > On the other hand, you *weave* two threads together side by side to > form a parallel bundle. Much closer image. Oops. I see now that splice isn't the right thing. But the first meaning of weave that comes to me suggest a 2D interlacing of threads that gives the wrong impression here (I know there are others but I'm much less familiar with them). I looked in a thesaurus and found a few potential alternatives: twine entwine intertwine interweave interlace interspeerse If none of these appeal, I say let's use zip and end this impossibly long thread. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From DavidA at ActiveState.com Thu Jul 13 03:44:13 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 12 Jul 2000 18:44:13 -0700 (Pacific Daylight Time) Subject: [Python-Dev] ! In-Reply-To: Message-ID: > > +1 on the new python-dev community! > > Except it's largely still the same python-dev community: It's the same group of people, behaving differently. Social change in action. It's a new community. =) > the perceived zoom > in productivity is entirely due to my forcing patch management onto > SourceForge -- well, either that, or that the laywers keep Guido so busy > that he can't take time to interfere with progress anymore . Actually, it's decentralization of responsibilities and power, and more people having full-time jobs doing the stuff. The lawyers help too =). --david From klm at digicool.com Thu Jul 13 03:47:33 2000 From: klm at digicool.com (Ken Manheimer) Date: Wed, 12 Jul 2000 21:47:33 -0400 (EDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: Guido: > I looked in a thesaurus and found a few potential alternatives: > > twine > entwine > intertwine > interweave > interlace > interspeerse > > If none of these appeal, I say let's use zip and end this impossibly > long thread. I have real doubts about using zip because of the extremely prominent "compression" connotations - it's one of the few things that neophyte as well as experienced computer users are exposed to, with winzip etc. I actually like interlace a lot. I also like "furl" - especially when you say it: "Furl. Furl. Furl." :-) Ken klm at digicool.com From bwarsaw at beopen.com Thu Jul 13 03:49:44 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 21:49:44 -0400 (EDT) Subject: [Python-Dev] zip() and list-comprehension with commas References: <396BA425.2EF3B11F@prescod.net> <14699.59823.710880.896491@anthem.concentric.net> <14700.32671.461502.666561@beluga.mojam.com> <396C9661.3EF03755@prescod.net> Message-ID: <14701.8248.42404.797966@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> "Stitch" and "with" are okay, but I'd like to hear someone PP> debunk the names used today by MAL. They seemed very logical PP> to me. I'd just change the semantics to be lazy in a couple of PP> cases. I don't like the fact that this will give you two pairs of built-ins that differ only by the last letter. It seems too easy to mistype or misread. OTOH, I've argued for a dict() built-in before. -Barry From bwarsaw at beopen.com Thu Jul 13 03:58:49 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 21:58:49 -0400 (EDT) Subject: [Python-Dev] Python .NET (was Preventing 1.5 extensions crashing under 1.6/2.0 Python) References: Message-ID: <14701.8793.942357.20599@anthem.concentric.net> >>>>> "MH" == Mark Hammond writes: MH> This new compiler could be compared, conceptually, with MH> JPython - it is a completely new implementation of Python. All this sounds very cool Mark, thanks for giving us an initial rundown! So what are you calling this particular Python interpreter? #Python? Naw... NPython? Naw... :) -Barry From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 04:03:14 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 04:03:14 +0200 (CEST) Subject: [Python-Dev] co_lnotab and SET_LINENO In-Reply-To: <200007130126.DAA10951@python.inrialpes.fr> from "Vladimir Marangozov" at Jul 13, 2000 03:26:23 AM Message-ID: <200007130203.EAA11217@python.inrialpes.fr> Vladimir Marangozov wrote: > > Ka-Ping Yee wrote: > > > > Now that we have co_lnotab, why do we still generate > > SET_LINENO opcodes? > > It has been discussed before. To summarize: > > - because these opcodes generate the callbacks from C to Python > - the debugger relies on them > - I haven't had the time to look seriously at the debugger and > make it work without them. (this relates with breakpoints setting > which requires generating callbacks for every source line) > > And this is where we are. If you're volunteering to look into this, > I'll spend some time summarizing the pointers about this thread + > the existing code in the area. Otherwise, I won't bother OK, if someone wants to play with this, see: http://starship.python.net/~vlad/lineno/ for (working at the time) patches Discussions on python-dev: - http://www.python.org/pipermail/python-dev/2000-April/subject.html Subject: "Why do we need Traceback Objects?" - http://www.python.org/pipermail/python-dev/1999-August/002252.html I'd be happy to discuss the topic again, offline, with any volunteer(s) willing to take over (and to look closely at the debugger issue -- I don't use the debugger and I can't make the time for it). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From skip at mojam.com Thu Jul 13 04:14:37 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 21:14:37 -0500 (CDT) Subject: [Python-Dev] Python .NET (was Preventing 1.5 extensions crashing under 1.6/2.0 Python) In-Reply-To: <14701.8793.942357.20599@anthem.concentric.net> References: <14701.8793.942357.20599@anthem.concentric.net> Message-ID: <14701.9741.273410.914425@beluga.mojam.com> BAW> So what are you calling this particular Python interpreter? BAW> #Python? Naw... NPython? Naw... :) How about McPython? 95-billion-served-ly y'rs, Skip From esr at thyrsus.com Thu Jul 13 04:54:09 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 22:54:09 -0400 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <200007130241.VAA01765@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 12, 2000 at 09:41:06PM -0500 References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> <20000712194053.J799@thyrsus.com> <200007130138.UAA01580@cj20424-a.reston1.va.home.com> <20000712210657.Q799@thyrsus.com> <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: <20000712225409.W799@thyrsus.com> Guido van Rossum : > twine > entwine Not bad. > intertwine > interweave Too long. > interlace Nah. Interlace is something you do with video. > interspeerse Too long. > If none of these appeal, I say let's use zip and end this impossibly > long thread. zip() has known problems -- people *will* associate it with compression. Which is too bad, it's a great image. -- Eric S. Raymond In every country and in every age, the priest has been hostile to liberty. He is always in alliance with the despot, abetting his abuses in return for protection to his own. -- Thomas Jefferson, 1814 From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 05:04:04 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 05:04:04 +0200 (CEST) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <20000712225409.W799@thyrsus.com> from "Eric S. Raymond" at Jul 12, 2000 10:54:09 PM Message-ID: <200007130304.FAA11483@python.inrialpes.fr> Eric S. Raymond wrote: > > Guido van Rossum : > > twine > > entwine > > Not bad. Ugh. Never heard about these <0.8 wink>. Make it simple and explicit for non-english speakers too, please. I'm-about-to-whine-so-I-propose-"combine()"-ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From pingster at ilm.com Thu Jul 13 05:01:59 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 20:01:59 -0700 (PDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: These verbs have the following meanings to me: >>> splice([1, 2, 3], [4, 5, 6]) [1, 2, 3, 4, 5, 6] >>> weave([1, 2, 3], [4, 5, 6]) [1, 4, 2, 5, 3, 6] >>> interlace([1, 2, 3], [4, 5, 6]) [1, 4, 2, 5, 3, 6] I also did a little surveying. I got opinions that "interlace" was especially misleading; "zip" was deemed to evoke compression too strongly; and "parallel" evoked concurrency too strongly. The people i asked generally agreed with the interpretations i used above, though one thought that weave() would produce [[1, 4], [2, 5], [3, 6]]. I'm afraid i have to say that "with" is a horrible name for a function, as it's a preposition. Verbs work best for function names, and nouns are next best. Prepositions are very awkward. One person i asked even said that of all the various options, he still liked "map(None, ...)" best because all the others had potentially conflicting connotations. I personally still like "zip", but i must defer to empirical results. "tuples" may be the clearest option. "twine" seems plausible (though it makes me think of twisting and rotation). (By the way, let's not forget irange. Go, irange, go!) -- ?!ng From pingster at ilm.com Thu Jul 13 05:09:09 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 20:09:09 -0700 (PDT) Subject: [Python-Dev] Re: Iterating in parallel In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Ka-Ping Yee wrote: > One person i asked even said that of all the various options, > he still liked "map(None, ...)" best because all the others had > potentially conflicting connotations. I forgot to add: when i said "map(None, ...)" was ugly, this person suggested "munge()", indicating that he'd prefer a completely obscure name to a name that might risk an alternate interpretation. He liked "munge()" and "twine()" best, considered "tuples()" acceptable, and declared "zip()" unacceptable but "zipper()" acceptable. -- ?!ng From pingster at ilm.com Thu Jul 13 05:37:32 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 20:37:32 -0700 (PDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Ken Manheimer wrote: > > I also like "furl" - especially when you say it: > "Furl. Furl. Furl." But furling is like rolling something up. *sigh* More words: marry knit stitch merge weld meld ladder Considered but rejected: adhere, braid, mesh, lash, crosslink, bind, conjoin, unite, tie, squeeze. Hm. None really beat "zip" for me in terms of the visualization (except perhaps "marry"). -- ?!ng From bwarsaw at beopen.com Thu Jul 13 05:45:29 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 23:45:29 -0400 (EDT) Subject: [Python-Dev] Iterating in parallel References: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: <14701.15193.695315.549635@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> I personally still like "zip", but i must defer to empirical KY> results. "tuples" may be the clearest option. "twine" seems KY> plausible (though it makes me think of twisting and rotation). Let me throw one more out, in honor of our fearless leader's recent life change: marry(). Usually only done in pairs, and with two big sequences, I get the image of a big Unification Church event :) -Barry From bwarsaw at beopen.com Thu Jul 13 05:54:34 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 23:54:34 -0400 (EDT) Subject: [Python-Dev] Iterating in parallel References: Message-ID: <14701.15738.293596.60350@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> Hm. None really beat "zip" for me in terms of the KY> visualization (except perhaps "marry"). You and I think too much alike ?!ng. And if that doesn't scare you now, you should have a talk with Gordon. -Barry From esr at thyrsus.com Thu Jul 13 06:09:29 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 00:09:29 -0400 Subject: [Python-Dev] Re: Iterating in parallel In-Reply-To: ; from pingster@ilm.com on Wed, Jul 12, 2000 at 08:37:32PM -0700 References: Message-ID: <20000713000929.B3212@thyrsus.com> Ka-Ping Yee : > On Wed, 12 Jul 2000, Ken Manheimer wrote: > > > > I also like "furl" - especially when you say it: > > "Furl. Furl. Furl." > > But furling is like rolling something up. > > *sigh* More words: > > marry > knit > stitch > merge > weld > meld > ladder > > Considered but rejected: adhere, braid, mesh, lash, crosslink, bind, > conjoin, unite, tie, squeeze. > > Hm. None really beat "zip" for me in terms of the visualization > (except perhaps "marry"). `knit' would work for me. -- Eric S. Raymond Whether the authorities be invaders or merely local tyrants, the effect of such [gun control] laws is to place the individual at the mercy of the state, unable to resist. -- Robert Anson Heinlein, 1949 From paul at prescod.net Thu Jul 13 06:02:28 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 23:02:28 -0500 Subject: [Python-Dev] Iterating in parallel References: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> <14701.15193.695315.549635@anthem.concentric.net> Message-ID: <396D3F54.39DD165F@prescod.net> "Barry A. Warsaw" wrote: > > ... > > Let me throw one more out, in honor of our fearless leader's recent > life change: marry(). Usually only done in pairs, and with two big > sequences, I get the image of a big Unification Church event :) Isn't it somewhat of a political statement to allow marriages of three or more items? I always presumed that this function was n-ary, like map. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From esr at thyrsus.com Thu Jul 13 06:26:00 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 00:26:00 -0400 Subject: [Python-Dev] Iterating in parallel In-Reply-To: <396D3F54.39DD165F@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 11:02:28PM -0500 References: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> <14701.15193.695315.549635@anthem.concentric.net> <396D3F54.39DD165F@prescod.net> Message-ID: <20000713002600.E3212@thyrsus.com> Paul Prescod : > > Let me throw one more out, in honor of our fearless leader's recent > > life change: marry(). Usually only done in pairs, and with two big > > sequences, I get the image of a big Unification Church event :) > > Isn't it somewhat of a political statement to allow marriages of three > or more items? I always presumed that this function was n-ary, like map. Perhaps we should call it "menage()"? :-) (Eric looks back on some fond memories. And no, you *don't* get the details.) -- Eric S. Raymond Let us hope our weapons are never needed --but do not forget what the common people knew when they demanded the Bill of Rights: An armed citizenry is the first defense, the best defense, and the final defense against tyranny. If guns are outlawed, only the government will have guns. Only the police, the secret police, the military, the hired servants of our rulers. Only the government -- and a few outlaws. I intend to be among the outlaws. -- Edward Abbey, "Abbey's Road", 1979 From DavidA at ActiveState.com Thu Jul 13 06:24:19 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 12 Jul 2000 21:24:19 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Iterating in parallel In-Reply-To: <20000713002600.E3212@thyrsus.com> Message-ID: > Perhaps we should call it "menage()"? :-) > > (Eric looks back on some fond memories. And no, you *don't* get the details.) ObJoke: A friend of mine in college was walking through a supermarket with her girlfriend (they were both highschool students at the time) and her girlfriend's mom. As she is walking down the aisle, the girlfriend had a sudden feeling of reliving a past experience, as if life was repeating itself and she was seeing things over again. She turned to her mom down the aisle and shouted: Hey, mom, I just had a 'maynage a troah!' I love misunderstood French. --david From paul at prescod.net Thu Jul 13 06:26:15 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 23:26:15 -0500 Subject: [Python-Dev] List comprehensions Message-ID: <396D44E7.F87983AB@prescod.net> I want to summarize my feelings on the list-comp syntax issue. There is no syntax for list comprehensions that will inherently scream "cartesian product, not parallel". The only way to do it is by analogy to what they already know: Python. [for x: if y(x): for z: (x,y,z)] -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From moshez at math.huji.ac.il Thu Jul 13 06:44:40 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 13 Jul 2000 07:44:40 +0300 (IDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <396CAE7D.B85AA3FB@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > Moshe Zadka wrote: > > > > What would people think about xmap(), which acts anologously to xrange(), > > IOW calculate lazilly instead of eagerly? Or even, calculate "on demand", > > without caching: > > .... > > Wouldn't this solve the parallel iteration problem? > > I don't think that using a function called "xmap" to build tuples is > very intuitive to start with. What's so wrong with a builtin called > "tuples()"? The name isn't so important -- what is more important is the lazy aspect of the thing. (And anyway, map/xmap is more general then tuples: def tuples(*lists): apply(map, (None,)+lists) ) and I see no reason not to support the stronger construct -- tuples could be build above it. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul at prescod.net Thu Jul 13 06:31:06 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 23:31:06 -0500 Subject: [Python-Dev] re: list comprehension / pop quiz References: Message-ID: <396D460A.96CCC807@prescod.net> Moshe Zadka wrote: > > ... > > The name isn't so important -- what is more important is the lazy aspect > of the thing. Names are always important. Is an xmap like an x-man? > (And anyway, map/xmap is more general then tuples: > > def tuples(*lists): > apply(map, (None,)+lists) > ) and I see no reason not to support the stronger construct -- tuples > could be build above it. I agree. I just think that the stronger construct should be called "lazy list comprehension". list comps. are much more general than maps and also easier to read. As you've pointed out, making them lazy also makes them more powerful. I don't think that there is any need for the eager equivalent because it is so easy to resolve a lazy one to an eager one in the rare case that that's what you need. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From klm at digicool.com Thu Jul 13 08:25:30 2000 From: klm at digicool.com (Ken Manheimer) Date: Thu, 13 Jul 2000 02:25:30 -0400 (EDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Ken Manheimer wrote: > Guido: > > > I looked in a thesaurus and found a few potential alternatives: > > [...] > > interlace > > [...] > > If none of these appeal, I say let's use zip and end this impossibly > > long thread. > > I actually like interlace a lot. Huh - how about "lace"? I like that even more than "interlace" - shorter, and with a particular, visceral appeal when thinking about laces that tie clothing together, like shoelaces. Lacing shoes means interleaving the laces, and unlacing them means un-interleaving them. Extraordinarily close visceral/physical analogue for the interlacing of the list/tuple arguments. For those that didn't see my posting in the thread "Re: zip() and list-comprehension with commas", i think it's a good idea to be explicit about the type of the results, rather than inferring them from the types of the arguments. Seem like there are so many contexts where lists and tuples are interchangeable that it's too easy for a variable to contain one when you expect the other - and the reorganizing routine would wind up raising unexpected errors, or unpredictable results, too often. Better to be explicit. And dictionaries seem like reasonable targets for lacing. >>> lace([], (1, 2, 3), [4, 5, 6,]) Lace [[1,4], [2,5], [3,6]] -%- \ / >>> lace((), [1,2,3],(4,5,6)) X ((1,4), (2,5), (3,6)) / \ \ / >>> lace({}, (1,2,3), "abc") X {1:'a', 2:'b', 3:'c'} (_) >>> unlace([], [1,4], [2,5], [3,6]) unlace [[1, 2, 3], [4, 5, 6]] \ / | | >>> unlace((), [1,4], [2,5], [3,6]) | | ((1, 2, 3), (4, 5, 6)) | | | | >>> unlace((), {1:'a', 2:'b', 3:'c'}) | | ((1, 2, 3), ('a', 'b', 'c')) |__| Also, i like having generators as the results of lacing things... I wonder whether this will have any inherent meaning for non-english speakers? Then again, i'm not sure 'tuple' had a lot of meaning for a lot of english or non-english speakers - people get used to it, as long as it's not using a word commonly known to have a *different* meaning in context (eg, "zip"). Ken From paul at prescod.net Thu Jul 13 08:07:30 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 01:07:30 -0500 Subject: [Python-Dev] strncpy Message-ID: <396D5CA2.DBBBDC2C@prescod.net> Tim, Re: Patch #100874 Thanks for the quick disposition. I'll fix the style errors. It's just so hard to concentrate on style when you're trying to fit code into the 5 character margin left by Guido's indentation style. Grrrr. ceval reminds me of old BBS messages written on a Commodore-64, but read on a 17" monitor. About this: > char buf[500]; > ... followed by an unchecked sprintf into buf. > > This is a security hole: Python doesn't restrict identifiers to > being no longer than 500 chars, so a hacker can easily trick this > code into overwriting the buffer bounds. I was prepared to be paranoid about this but then I saw this comment: /* XXX There are several unchecked sprintf or strcat calls in this file. XXX The only way these can become a danger is if some C code in the XXX Python source (or in an extension) uses ridiculously long names XXX or riduculously deep nesting in format strings. */ I interpreted that as "Python enforces reasonable identifier lengths, and only C code can violate it. I'm surprised to learn that Python doesn't have a max identifier length #defined somewhere. Especially since there is a defacto (probably undocumented) length limit for names in C extensions (according to the comment above). > Easy but tedious to > fix (e.g., #define the buf length, and use runtime code in > conjunction with strncpy to guarantee buf's bounds are respected). Let me suggest two non-tedious solutions so you can shoot them down: 1. sprintf(buf, "Local variable referenced " "before assignment: %.128s", namestr); Rationale: if you don't know what variable I'm talking about after 128 characters, you've got bigger problems than I can help with. I see this solution elsewhere in the code. 2. Add an implementation of snprintf to our code and fix the other hundred or so sprintf occurrences to use it. Most of them are safe but it couldn't hurt to pass cleanly through those heuristic security checkers Here's one: http://www.ijs.si/software/snprintf/ And there is one in Apache. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 08:09:50 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 01:09:50 -0500 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> Message-ID: <396D5D2E.4844F7FF@prescod.net> Paul Prescod wrote: > > Re: Patch #100874 Also, the LOAD_FAST and DELETE_FAST cases are identical when an exception is thrown. Should I make a small function as I would usually do or is that "bad style" in ceval. Moving code out of the switch probably helps keep commonly used code local and uncommon code "unlocal". -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From bwarsaw at beopen.com Thu Jul 13 09:00:17 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 03:00:17 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) Message-ID: <14701.26881.172217.870049@anthem.concentric.net> At our Pythonlabs meeting today, we decided we needed a more formal and organized way to track all the language and other changes being discussed on python-dev. Someone else (I don't remember who) suggested an IETF-like approach. I like that as a model, but am not sure how much of that formalism we need to adopt (or is even appropriate for us). Since my finger was slowest reaching my nose, I got elected Editor. On the positive side of that, I get to make the early decisions that will be cursed for generations of Python hackers to come. In any event, here's what I've just checked in. These things are called PEPs or Python Enhancement Proposals. Each has a number assigned to it by the Editor (me) which never changes over the lifetime of the proposal. The format is very loosely defined right now, but I'm sure will undergo formalization itself over time. Essentially, each PEP starts with a bunch of RFC822 style headers. Required headers are PEP: the number assigned by the editor Title: the title as given by the owner of the PEP Version: usually $Revision$ Owner: the owner/champion/shepherd of the PEP Status: the status as chosen from a currently very ill-defined set Optional headers are Python-Version: what version of Python this pertains to PEP 0 (zero) is the index of PEPs. PEP 1 will be the PEP Guidelines document (essentially this email message when it reflects back to my mailbox). I'll continue to own both these for the time being. PEP 200 is the Python 2.0 release schedule. Jeremy Hylton will own this one. PEP 201 discusses the parallel iteration feature. I currently own this one, and have fleshed this out completely based on my understanding of the issues as of 2:45am 13-Jul-2000. Use this as an example of the PEP format until PEP 1 is completed. PEP 202 will cover list comprehensions. I think Tim Peters volunteered to own this one. PEP 203 will cover augmented assignments. Thomas Wouters, we were thinking about you owning this one. My thoughts for these documents are that they will be almost completely self-contained, so that someone freshly coming on the issue can read the PEP, understand what the problem is, how the proposed solution works, and where to go to find more information. Wading through, or even following, the python-dev mailing list or archives should not be necessary. Another advantage is that these things will live in the Python CVS tree, so they will be diff-able, modifiable by anybody with check-in privileges, and will have the complete history in their CVS logs. What I don't want to do: argue about meta issues, such as whether PEPs are a good acronym, or whether we should use plain text or XML, or whether I've had enough sleep lately. They probably aren't, but I couldn't think of anything better; plain text is readable and writable by everybody and I didn't want to waste time trying to write a DTD; I haven't, so what's new? You can find the current set of documents under nondist/peps in the CVS tree. Please take a look, especially at pep-0201.txt which is nearest to being complete. Time for sleep. -Barry From paul at prescod.net Thu Jul 13 08:12:57 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 01:12:57 -0500 Subject: permuting several lists (was Re: [Python-Dev] zip() andlist-comprehension with commas) References: Message-ID: <396D5DE9.A0990F3F@prescod.net> Ken Manheimer wrote: > > ... > > Seem like there are so many contexts > where lists and tuples are interchangeable that it's too easy for a > variable to contain one when you expect the other - and the > reorganizing routine would wind up raising unexpected errors, or > unpredictable results, too often. Well, we (at least you and I) agree that we should use a generator, so you don't really have any control over the outer data structure without using a cast. I think it is safe to default the inner data structure to tuple. Tuples are safe because errors involving them cause TypeErrors whereas accidental writes to shared lists cause weird mutation bugs. Here are some variants you can get using recently proposed features: List of tuples: >>> list( lace( a, b, c )) A tuple of tuples: >>> tuple( lace( a, b, c)) A tuple of lists: >>> tuple( [for x in lace( a, b, c)]: list(x) ) A list of lists: >>> list( [for x in lace( a, b, c)]: list(x) ) A dictionary: >>> dict( lace( a, b, c )) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 08:13:52 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 01:13:52 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <396D5E20.69F228EC@prescod.net> I'm not clear on the role of opinions in this process. Do all of the opinions about a proposal go in the PEP: * "I hate this, here's why" * "I have a minor enhancement proposal" * "Here is my competing proposal" -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From fredrik at pythonware.com Thu Jul 13 09:09:57 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 09:09:57 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <013601bfec99$5a9af780$0900a8c0@SPIFF> barry wrote: > You can find the current set of documents under nondist/peps in the > CVS tree. Please take a look, especially at pep-0201.txt which is > nearest to being complete. can you perhaps post these somewhere on the python.org and/or pythonlabs.com sites? hiding them down in the CVS tree isn't optimal, especially when SF's CVS viewer doesn't work for roughly 86% of all web users... cheers /F From bwarsaw at beopen.com Thu Jul 13 09:11:07 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 03:11:07 -0400 (EDT) Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> Message-ID: <14701.27531.782443.22776@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Add an implementation of snprintf to our code and fix the PP> other hundred or so sprintf occurrences to use it. Most of PP> them are safe but it couldn't hurt to pass cleanly through PP> those heuristic security checkers PP> Here's one: PP> http://www.ijs.si/software/snprintf/ PP> And there is one in Apache. And one in Mailman, ripped from GNU screen. Because it's GPL'd it's not appropriate for Python, but could serve as another source of inspiration. So far, of the platforms people try to run Mailman on, I've only found it necessary for Solaris 2.5. -Barry From tim_one at email.msn.com Thu Jul 13 10:28:34 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 13 Jul 2000 04:28:34 -0400 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <013601bfec99$5a9af780$0900a8c0@SPIFF> Message-ID: [Barry] > You can find the current set of documents under nondist/peps in the > CVS tree. Please take a look, especially at pep-0201.txt which is > nearest to being complete. [/F] > can you perhaps post these somewhere on the python.org > and/or pythonlabs.com sites? In time, yes. For now we're just trying to get it started. Note that we can't currently change anything on python.org, and I'm not sure we're yet able to get at pythonlabs.com most days either <0.9 wink>. > hiding them down in the CVS tree isn't optimal, especially > when SF's CVS viewer doesn't work for roughly 86% of all > web users... Plus me ! Barry didn't say so, but he could have: the things for which he created PEPs are, as far as Guido is concerned, all going to be in the 2.0 release (yup! augmented assignments and list comprehensions and ... that other thing ). So we have a crucial need to make sense out of their respective Python-Dev messes *now* (as the "list comprehension guy", who was out of the loop yesterday for moving, out most of today for a mtg, and will be out tomorrow again for personal reasons, I despair of ever making coherent sense out of the 100+ msgs I haven't got to on the topic yet, inexplicably splintered along multiple Subject lines). So, like with the move to the SF patch manager, we're just moving to *something* we aren't yet certain is totally broken. It will work if all of us do . btw-the-truly-*new*-content-in-all-these-msgs-could-probably-fit-in-a- paragraph-ly y'rs - python's collective memory for lack of a pep From ping at lfw.org Thu Jul 13 09:35:29 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 00:35:29 -0700 (PDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: <396D3F54.39DD165F@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > > Isn't it somewhat of a political statement to allow marriages of three > or more items? I always presumed that this function was n-ary, like map. I *knew* someone was going to make a comment like this. ...which is why it was so much fun to propose it. :) -- ?!ng From moshez at math.huji.ac.il Thu Jul 13 09:36:09 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 13 Jul 2000 10:36:09 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: On Thu, 13 Jul 2000, Barry A. Warsaw wrote: > You can find the current set of documents under nondist/peps in the > CVS tree. Please take a look, especially at pep-0201.txt which is > nearest to being complete. Personally, I'm +1 on pop-0201 as it stands. Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] Otherwise user-code will probably have to special case more often. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From ping at lfw.org Thu Jul 13 09:48:54 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 00:48:54 -0700 (PDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: On Thu, 13 Jul 2000, Barry A. Warsaw wrote: > > These things are called PEPs or Python Enhancement Proposals. Excellent. I think having these things documented in a persistent way is a fabulous idea. > PEP 201 discusses the parallel iteration feature. I currently own > this one, and have fleshed this out completely based on my > understanding of the issues as of 2:45am 13-Jul-2000. Use this as an > example of the PEP format until PEP 1 is completed. Great. Thanks for doing all this work! May i suggest small edits? pep-0201.txt says: | exhausted. The for-loop can also be explicitly exited with a | `break' statement, and for-loops can have else: clauses, but these | is has no bearing on this PEP. These is has no sensible sentence, either. :) Barry is has no sleep lately too? | should raise an IndexError when the sequence is exhausted. This | protocol is current undocumented -- a defect in Python's | documentation hopefully soon corrected. "current undocumented" -> "currently undocumented" | For loops are described in the language reference manual here | http://www.python.org/doc/devel/ref/for.html | | An example for-loop Colons after "here" and "for-loop". | class _Marriage: | def __init__(self, args, kws): Shouldn't that be "_Mawwage"? I apologize... i'm having way too much fun at your expense. -- ?!ng From moshez at math.huji.ac.il Thu Jul 13 09:46:31 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 13 Jul 2000 10:46:31 +0300 (IDT) Subject: [Python-Dev] Ranges In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Ka-Ping Yee wrote: > I believe the two possibilities were > > __getitem__ gets either an index or a special slice object > __getslice__ is deprecated (when missing, __getitem__ gets the slice args) > > and > > __getitem__ always gets an index > __getslice__ gets three arguments, all optional, defaulting to None > > The latter isn't backward-compatible, but it makes a heckuva lot > more sense. Right. I'd be +1 on the latter if we didn't have to be backwards compatible. OTOH: How many people do you know who deal with slices in __getitem__, besides the numpy people? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From ping at lfw.org Thu Jul 13 09:52:17 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 00:52:17 -0700 (PDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: Message-ID: On Thu, 13 Jul 2000, Moshe Zadka wrote: > > Personally, I'm +1 on pop-0201 as it stands. Sure, looks great. Me too. > Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] > Otherwise user-code will probably have to special case more often. Yes, i agree with this stance on the issue. -- ?!ng From moshez at math.huji.ac.il Thu Jul 13 09:56:16 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 13 Jul 2000 10:56:16 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007121318.IAA14063@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 12 Jul 2000, Guido van Rossum wrote: > Greg subtly points out the difficulty with your proposal: this > requires an external library that may not be available. In the past > we've had enough complaints from people who failed to realize that if > the build failed because of a missing external library, they could > just disable the module that needs it. So I'm not for simply having > it enabled in Setup.in by default. Currently there are two external libraries one needs to build a "good" Python interpreter: zlib, and expat. Well, now that Python releases from BeOpen, and not CNRI, perhaps it will be deemed all right to put them in the source distribution, and by default have a Setup.in that builds on them? Perhaps even include a "last known good" Tcl/Tk? Rational: There are several kinds of people who build Python interpreters. Let me divide them into two groups, jokingly called "users" and "pushers". "Users" build Python interpreter for self consumption (or for consumption of a relatively small group of people). They sometimes don't know C, have a flaky internet connection, and do not have too much time. For them, Python should build out of the box. "Pushers", or packagers, are people who build a python interpreter on a platform and distribute it. Examples include BeOpen for the Windows installer, the nice folks at Red Hat for rpms, and some Debian packager for debs. These people usually configure the Python interpreter, and decided what needs to be built, so it's all right to let them edit Setup. addicted-to-python-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From ping at lfw.org Thu Jul 13 10:21:41 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 01:21:41 -0700 (PDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: Message-ID: On Thu, 13 Jul 2000, Ka-Ping Yee wrote: > > Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] > > Otherwise user-code will probably have to special case more often. > > Yes, i agree with this stance on the issue. Oh -- alternatively: >>> marry([0, 1, 2]) TypeError: marry() requires at least two arguments Notice, by the way, that marry() neither limits its arguments to only two, nor does it place any restrictions on the gender of its arguments. Indeed, this has truly far-reaching implications, as PEP 201 would then make Python the first programming language in the history of computing to directly acknowledge freedom of sexual orientation in its standard library. The excellent PR alone would clearly make this one a winner. -- ?!ng From gstein at lyra.org Thu Jul 13 10:54:25 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 01:54:25 -0700 Subject: [Python-Dev] strncpy In-Reply-To: <396D5CA2.DBBBDC2C@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 01:07:30AM -0500 References: <396D5CA2.DBBBDC2C@prescod.net> Message-ID: <20000713015424.X29590@lyra.org> On Thu, Jul 13, 2000 at 01:07:30AM -0500, Paul Prescod wrote: >... > > Easy but tedious to > > fix (e.g., #define the buf length, and use runtime code in > > conjunction with strncpy to guarantee buf's bounds are respected). > > Let me suggest two non-tedious solutions so you can shoot them down: > > 1. > > sprintf(buf, "Local variable referenced " > "before assignment: %.128s", > namestr); > > Rationale: if you don't know what variable I'm talking about after 128 > characters, you've got bigger problems than I can help with. I see this > solution elsewhere in the code. > > 2. > > Add an implementation of snprintf to our code and fix the other hundred > or so sprintf occurrences to use it. Most of them are safe but it > couldn't hurt to pass cleanly through those heuristic security checkers > > Here's one: > > http://www.ijs.si/software/snprintf/ > > And there is one in Apache. Actually, I looked into this a few months ago. There isn't a need to bulk up Python with a complete snprintf() solution. We really only use a couple format codes for generating error strings. Please see my note at: http://www.python.org/pipermail/python-dev/2000-April/010051.html Cheers, -g -- Greg Stein, http://www.lyra.org/ From moshez at math.huji.ac.il Thu Jul 13 10:52:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 13 Jul 2000 11:52:06 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: Message-ID: On Thu, 13 Jul 2000, Ka-Ping Yee wrote: [about what marry() should do with one argument] > Oh -- alternatively: > > >>> marry([0, 1, 2]) > TypeError: marry() requires at least two arguments Ummmmm......this seems a bit of an arbitrary restriction.... (Though I suppose this could be argued for from "the face of ambiguity refuse to guess") -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul at prescod.net Thu Jul 13 09:50:13 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 02:50:13 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: Message-ID: <396D74B5.5110A26D@prescod.net> Ka-Ping Yee wrote: > > ... > > Indeed, this has truly far-reaching implications, as PEP 201 would > then make Python the first programming language in the history of > computing to directly acknowledge freedom of sexual orientation in > its standard library. If Larry Wall can blatantly court the Christian vote, and Javasoft can go after the Asians, we'll have to build some coalitions of our own! Seriously though: I have some concern with implying that it works for only two lists. Our users may still be stuck in that 20th century point of view that, when stretched, might accept two lists of the same type but never three. Compare marry to "zip". The first time you see "zip", you figure out that it has nothing to do with zipping files, just by looking at the usage. But you could see, and use, "marry" over and over and over again and never realize that it works for three+ lists. How big of a problem is this? You decide. funny-how-whimsical-names-are--so-annoying-in-Perl -ly 'yrs -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 09:53:07 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 02:53:07 -0500 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> Message-ID: <396D7563.9DB73E1E@prescod.net> Greg Stein wrote: > > Actually, I looked into this a few months ago. >... Oh yeah? Where is the Python Enhancment Proposal? If we don't care about floating point, I think that there are about a dozen snprintf's we could steal (legally) around the Web. The author of the one I found says: > In retrospect, it appears that a lot of effort was wasted by > many people for not being aware of what others are doing. Sigh. Greg proposes: > %.###s -- switch to %s Isn't %.###s useful? If some yahoo gives us a 200 character variable name, is it really useful to quote it all back? For NameErrors and UnboundLocalErrors in ceval, I'm just going to use PyString_Format. If that's not solid, we're in big trouble. Okay, it isn't so fast but we're talking about relatively rare exceptions -- not IndexError or AttributeError. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gstein at lyra.org Thu Jul 13 11:31:59 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 02:31:59 -0700 Subject: [Python-Dev] strncpy In-Reply-To: <396D7563.9DB73E1E@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 02:53:07AM -0500 References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> Message-ID: <20000713023159.B29590@lyra.org> On Thu, Jul 13, 2000 at 02:53:07AM -0500, Paul Prescod wrote: > Greg Stein wrote: > > > > Actually, I looked into this a few months ago. >... > If we don't care about floating point, I think that there are about a > dozen snprintf's we could steal (legally) around the Web. The author of > the one I found says: We don't care about anything except for %d, %s, possibly %c and %x. > > In retrospect, it appears that a lot of effort was wasted by > > many people for not being aware of what others are doing. Sigh. IMO, there is a complexity tradeoff. A short formatter for a few codes, or pick up a complete implementation? And we *do* have some specific requirements. We need to format into a PyStringObject rather than a user-provided buffer/len like snprintf() does. > Greg proposes: > > %.###s -- switch to %s > > Isn't %.###s useful? If some yahoo gives us a 200 character variable > name, is it really useful to quote it all back? They did it, we can send it back. No biggy. The *reason* the %.###s is in there is to prevent buffer overruns. It isn't there for "nice output / truncation." Logically, it doesn't need to be there. > For NameErrors and UnboundLocalErrors in ceval, I'm just going to use > PyString_Format. If that's not solid, we're in big trouble. Okay, it > isn't so fast but we're talking about relatively rare exceptions -- not > IndexError or AttributeError. PyString_Format() requires Python objects for arguments. That is a completely different beast from PyErr_Format() (or the PyErr_SafeFormat that I described in that email). If you're going to create a PyStringObject for the format and one for the argument, then pass it to PyString_Format, then toast those temporaries... then you're going about it wrong. :-) A simple, *safe* string formatter for C types is needed within the core. Cheers, -g -- Greg Stein, http://www.lyra.org/ From jack at oratrix.nl Thu Jul 13 11:52:36 2000 From: jack at oratrix.nl (Jack Jansen) Date: Thu, 13 Jul 2000 11:52:36 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message by Guido van Rossum , Wed, 12 Jul 2000 21:41:06 -0500 , <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: <20000713095237.5570E37186D@snelboot.oratrix.nl> > twine > entwine > intertwine > interweave > interlace > interspeerse intertwine() and interlace() both give me the right feeling. Although with interlace I might be tempted to pass it two 320x480 bitmaps and assume an NTSC image will come out:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paul at prescod.net Thu Jul 13 10:01:24 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 03:01:24 -0500 Subject: [Python-Dev] Exceptions References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> Message-ID: <396D7754.96D6CCE7@prescod.net> Greg Stein wrote: > > If you're going to create a PyStringObject for the format and one for the > argument, then pass it to PyString_Format, then toast those temporaries... > then you're going about it wrong. :-) You're right. It's too late... Anyhow, this whole process seems wrong. Shouldn't the exceptions know what their appropriate error messages are and take the arguments for their format strings as arguments? There shouldn't be duplicated error messages spread throughout the code. It's brutal for consistency. You probably discussed this six months ago also. Anyhow, I think that that's the answer to Fredrik's (implicit) question about how decide when to make new exceptions. If it requires a new docstring or message string/format then it should be a new exception. We had relatively few exceptions before because they were just strings. Now that they are objects we should expect them to proliferate as they tend to in other languages where objects are exceptions. We should start tightening up the parameters we expect them to take for their constructors too. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From ping at lfw.org Thu Jul 13 12:19:59 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 03:19:59 -0700 (PDT) Subject: [Python-Dev] listcomp / par-for (summary) In-Reply-To: <20000712161328.I7340@xs4all.nl> Message-ID: On Wed, 12 Jul 2000, Thomas Wouters wrote: > As said, the currently implemented list-comprehension syntax was too > unclear, especially when nesting the 'for's and 'if's too deeply. One of the > proposals was to enforce the use of ()'s and add commas to make the 'for's > and 'if's more readable: > > [(x,y) for x in a, y in b, if y > 3] > > That is not going to work. Actually, it will (read on). > Enforcing the parentheses is possible, but only > if you *always* enforce them, even if they don't create a tuple: > > [([x,y]) for x in a] They don't always have to be enforced (read on). > Secondly, the use of commas to seperate the for and if statements is not > possible. The parser will see the commas as part of the iter-list of the > previous for statement. No, this really can be done. I was kinda suspicious when i read the above statements, so i proceeded to hack the grammar to see if i could implement the syntax i proposed. It is possible, and it turns out it's quite easy and straightforward. (No personal attack intended, Thomas -- sorry -- just wanted to show that it *is* possible.) All of the following syntaxes are possible (i've tried and tested a Python capable of each one): 1. [ <...> ] 2. [ , , , <...> ] 3. [ ; , , <...> ] 4. [ ; ; ; <...> ] For example, using a Python with "comma-comma" syntax (number 2), i get: >>> a = range(5) >>> b = range(10, 50, 10) >>> a [0, 1, 2, 3, 4] >>> b [10, 20, 30, 40] >>> [x*2, for x in a] [0, 2, 4, 6, 8] >>> [x, y, for x in a, for y in b, if y > 3] File "", line 1 [x, y, for x in a, for y in b, if y > 3] ^ SyntaxError: invalid syntax >>> [(x, y), for x in a, for y in b, if y > 3] [(0, 10), (0, 20), (0, 30), (0, 40), (1, 10), (1, 20), (1, 30), (1, 40), (2, 10), (2, 20), (2, 30), (2, 40), (3, 10), (3, 20), (3, 30), (3, 40), (4, 10), (4, 20), (4, 30), (4, 40)] >>> [[x, y], for x in a] [[0, 40], [1, 40], [2, 40], [3, 40], [4, 40]] >>> [([x, y]), for x in a] [[0, 40], [1, 40], [2, 40], [3, 40], [4, 40]] >>> [([x, y],), for x in a] [([0, 40],), ([1, 40],), ([2, 40],), ([3, 40],), ([4, 40],)] >>> def marry(*args): return apply(map, (None,)+args)[:min(map(len, args))] ... >>> [x + y, for x in a, for y in b] [10, 20, 30, 40, 11, 21, 31, 41, 12, 22, 32, 42, 13, 23, 33, 43, 14, 24, 34, 44] >>> [x + y, for x, y in marry(a, b)] [10, 21, 32, 43] >>> The above shows that we can indeed enforce parentheses around the initial test, while not requiring extra parentheses when no tuple is being constructed. Similarly, as you would expect, using a comma between clauses requires you to add parens if the expression after "in" contains bare commas. Otherwise everything works normally. I also tested stuff like [] [1] [1,] [1,,] [1,2] [1,2,] [1,2,,] and the modified Pythons behaved fine. The grammar rules for comma-comma syntax are: atom: '(' [testlist] ')' | '[' [test [',' (testlist | list_iter)]] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ list_iter: (list_for | list_if) list_for: 'for' exprlist 'in' test [',' list_iter] list_if: 'if' test [',' list_iter] Or for semicolon-comma syntax (number 3 above): atom: '(' [testlist] ')' | '[' [testlist [';' list_iter]] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ list_iter: (list_for | list_if) list_for: 'for' exprlist 'in' test [',' list_iter] list_if: 'if' test [',' list_iter] I won't post the changes to Python/compile.c for each case here, but they were pretty minor changes from Greg Ewing's original patch. Comma-comma syntax is my current favourite, with semicolon-comma a close second (but definitely second). -- ?!ng From mal at lemburg.com Thu Jul 13 12:16:56 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 12:16:56 +0200 Subject: [Python-Dev] Re: New builtins References: Message-ID: <396D9717.25E82B0B@lemburg.com> Ka-Ping Yee wrote: > > tuples(), lists(), dict(), and indices() look pretty generally useful > to me. I agree that they look like good candidates for builtins. > > On Wed, 12 Jul 2000, M.-A. Lemburg wrote: > > irange(object[,indices]) > > Builds a tuple of tuples (index, object[index]). If a sequence > > indices is given, the indices are read from it. If not, then > > the index sequence defaults to trange(len(object)). > > This one in particular looks really fabulous. +1 to put this in builtins. > > In order of usefulness (just imho of course): > > irange +1 > tuples +0.5 > indices +0.5 > dict +0 > lists +0 If you want these in the standard dist, just go ahead and steal them from mx.Tools -- I don't have time to look into this right now (and of course I already have them as builtins ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 13 12:30:19 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 12:30:19 +0200 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <396D5D2E.4844F7FF@prescod.net> Message-ID: <396D9A3B.B6985C97@lemburg.com> Paul Prescod wrote: > > Paul Prescod wrote: > > > > Re: Patch #100874 > > Also, the LOAD_FAST and DELETE_FAST cases are identical when an > exception is thrown. Should I make a small function as I would usually > do or is that "bad style" in ceval. Moving code out of the switch > probably helps keep commonly used code local and uncommon code > "unlocal". Before going down this road you should do some serious performance testing. ceval is *very* touchy about the order of the opcodes and adding indirection doesn't necessarily help (the compiler inlines the code again ;-). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 13 12:37:21 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 12:37:21 +0200 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <14701.27531.782443.22776@anthem.concentric.net> Message-ID: <396D9BE1.843BA74@lemburg.com> "Barry A. Warsaw" wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> Add an implementation of snprintf to our code and fix the > PP> other hundred or so sprintf occurrences to use it. Most of > PP> them are safe but it couldn't hurt to pass cleanly through > PP> those heuristic security checkers > > PP> Here's one: > > PP> http://www.ijs.si/software/snprintf/ > > PP> And there is one in Apache. > > And one in Mailman, ripped from GNU screen. Because it's GPL'd it's > not appropriate for Python, but could serve as another source of > inspiration. So far, of the platforms people try to run Mailman on, > I've only found it necessary for Solaris 2.5. Isn't there one in FreeBSD which we could use (Python's license being very BSDish, this should be possible, I guess). Anyway, I think most platforms have their own snprintf() in the C lib, so the code would hardly ever be needed -- perhaps its even safe to revert to sprintf() on those platforms via a macro snprintf(). The reasoning here is simple: if the platform doesn't provide it, it's quite possibly unsafe in a network environment anyway, because many programs will use sprintf() instead of snprintf() and thus won't do much buffer overflow checking. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping at lfw.org Thu Jul 13 12:41:45 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 03:41:45 -0700 (PDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: <20000713095237.5570E37186D@snelboot.oratrix.nl> Message-ID: On Thu, 13 Jul 2000, Jack Jansen wrote: > > intertwine() and interlace() both give me the right feeling. Although with > interlace I might be tempted to pass it two 320x480 bitmaps and assume an NTSC > image will come out:-) Sorry for flip-flopping on this -- to Paul especially -- but parallel() is looking better and better as i compare it with these other alternatives. It seems clear that the most common use of this thing is in a parallel-iteration idiom, and that it would be quite rarely used as part of an expression elsewhere. Given that, consider: for x, y, z in marry(a, b, c): print x + y + z for x, y, z in twine(a, b, c): print x + y + z for x, y, z in lace(a, b, c): print x + y + z for x, y, z in zip(a, b, c): print x + y + z for x, y, z in parallel(a, b, c): print x + y + z Which one makes its behaviour most obvious to you? For me, parallel() really stands out. It's so strong that it could outweigh the potential connotation of concurrency. (In fact, it *is* sort of concurrent. If each list were a generator, they would all be running concurrently to produce the triplets we're requesting.) (If "parallel" disturbs you too much, the concept of parallel *movement* inspires me to suggest "march", which has all of that good walking-together-in-lock-step feeling, with none of the twisty feeling i get from "twine" or "lace" or the alternating-back-and-forth feeling i get from "weave" or "interlace".) -- ?!ng From paul at prescod.net Thu Jul 13 10:08:08 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 03:08:08 -0500 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <396D5D2E.4844F7FF@prescod.net> <396D9A3B.B6985C97@lemburg.com> Message-ID: <396D78E8.70926D96@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Before going down this road you should do some serious > performance testing. ceval is *very* touchy about the order > of the opcodes and adding indirection doesn't necessarily > help (the compiler inlines the code again ;-). I'm not changing the order of the opcodes, just error handling. Anyhow, would performance results on my single computer be meaningful? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 10:09:11 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 03:09:11 -0500 Subject: [Python-Dev] Iterating in parallel References: Message-ID: <396D7927.EC241464@prescod.net> Ka-Ping Yee wrote: > > ... > > (If "parallel" disturbs you too much, the concept of parallel > *movement* inspires me to suggest "march", which has all of that > good walking-together-in-lock-step feeling, with none of the > twisty feeling i get from "twine" or "lace" or the > alternating-back-and-forth feeling i get from "weave" or "interlace".) If only as much thought had gone into choosing the name for "lambda"....or was that an earlier gay-pride statement? (yes, I know where it comes from) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 13:10:15 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 13:10:15 +0200 (CEST) Subject: [Python-Dev] Re: Iterating in parallel In-Reply-To: <20000713000929.B3212@thyrsus.com> from "Eric S. Raymond" at Jul 13, 2000 12:09:29 AM Message-ID: <200007131110.NAA12470@python.inrialpes.fr> Eric S. Raymond wrote: > > [Ping] > > Hm. None really beat "zip" for me in terms of the visualization > > (except perhaps "marry"). > > `knit' would work for me. I was thinking also about cross(), xcross() stop-that-noise-about-Marry-'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 13:40:33 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 13:40:33 +0200 (CEST) Subject: [Python-Dev] Iterating in parallel In-Reply-To: from "Ka-Ping Yee" at Jul 13, 2000 03:41:45 AM Message-ID: <200007131140.NAA12523@python.inrialpes.fr> Ka-Ping Yee wrote: > > ... Given that, consider: > > for x, y, z in marry(a, b, c): print x + y + z > > for x, y, z in twine(a, b, c): print x + y + z > > for x, y, z in lace(a, b, c): print x + y + z > > for x, y, z in zip(a, b, c): print x + y + z > > for x, y, z in parallel(a, b, c): print x + y + z > > Which one makes its behaviour most obvious to you? None. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From esr at thyrsus.com Thu Jul 13 14:01:13 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 08:01:13 -0400 Subject: [Python-Dev] Re: Iterating in parallel In-Reply-To: <200007131110.NAA12470@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Thu, Jul 13, 2000 at 01:10:15PM +0200 References: <20000713000929.B3212@thyrsus.com> <200007131110.NAA12470@python.inrialpes.fr> Message-ID: <20000713080113.A4157@thyrsus.com> Vladimir Marangozov : > > > Hm. None really beat "zip" for me in terms of the visualization > > > (except perhaps "marry"). > > > > `knit' would work for me. > > I was thinking also about cross(), xcross() Now that really sounds like a Cartesian-product operator. -- Eric S. Raymond The abortion rights and gun control debates are twin aspects of a deeper question --- does an individual ever have the right to make decisions that are literally life-or-death? And if not the individual, who does? From gvwilson at nevex.com Thu Jul 13 14:07:29 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Thu, 13 Jul 2000 08:07:29 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: Message-ID: > > I don't think that using a function called "xmap" to build tuples is > > very intuitive to start with. What's so wrong with a builtin called > > "tuples()"? 1. Trailing single-character difference between "tuple()" and "tuples()". (We'd take marks off students for naming things this way, wouldn't we?) 2. Need separate functions for creating tuples, lists, dicts, etc. I liked Ken M.'s idea of one function that took a type argument, and stitched/married/wove/welded/whatever'd its arguments to create something of that type, as it would require only one new function. Greg From gvwilson at nevex.com Thu Jul 13 14:13:41 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Thu, 13 Jul 2000 08:13:41 -0400 (EDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: Message-ID: > Ka-Ping Yee wrote: > Sorry for flip-flopping on this -- to Paul especially -- but > parallel() is looking better and better as i compare it with these > other alternatives. Strong -1 on parallel() unless it really performs concurrent execution. I'd take any of the other suggestions (except "zip()") over this. Greg From m.favas at per.dem.csiro.au Thu Jul 13 14:28:24 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Thu, 13 Jul 2000 20:28:24 +0800 Subject: [Python-Dev] re: list comprehension / pop quiz Message-ID: <396DB5E8.6F12ACA4@per.dem.csiro.au> Greg Wilson wrote: 2. Need separate functions for creating tuples, lists, dicts, etc. I liked Ken M.'s idea of one function that took a type argument, and stitched/married/wove/welded/whatever'd its arguments to create something of that type, as it would require only one new function. I'd like to endorse Ken's idea very strongly - and suggest the name "plait" (which can clearly operate on 2, 3, 4, or more strands - and can produce beautiful effects... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From esr at thyrsus.com Thu Jul 13 15:15:46 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 09:15:46 -0400 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <396DB5E8.6F12ACA4@per.dem.csiro.au>; from m.favas@per.dem.csiro.au on Thu, Jul 13, 2000 at 08:28:24PM +0800 References: <396DB5E8.6F12ACA4@per.dem.csiro.au> Message-ID: <20000713091546.A5094@thyrsus.com> Mark Favas : > I'd like to endorse Ken's idea very strongly - and suggest the name > "plait" (which can clearly operate on 2, 3, 4, or more strands - and can > produce beautiful effects... plait() is *good*. -- Eric S. Raymond No one is bound to obey an unconstitutional law and no courts are bound to enforce it. -- 16 Am. Jur. Sec. 177 late 2d, Sec 256 From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 15:16:04 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 15:16:04 +0200 (CEST) Subject: [Python-Dev] co_lnotab and SET_LINENO (fwd) Message-ID: <200007131316.PAA12706@python.inrialpes.fr> Maybe I should foward this to c.l.py as a CFP, detailing somewhat the issue and ask for contributions from people who are using the debugger? Guido? I won't do it if there's no a serious intent of including it, though. The contributions would require inspection, testing & possibly further improvements. I do volunteer for championing discussions and testing of this (relatively minor, but delicate) feature. > > Vladimir Marangozov wrote: > > > > Ka-Ping Yee wrote: > > > > > > Now that we have co_lnotab, why do we still generate > > > SET_LINENO opcodes? > > > > It has been discussed before. To summarize: > > > > - because these opcodes generate the callbacks from C to Python > > - the debugger relies on them > > - I haven't had the time to look seriously at the debugger and > > make it work without them. (this relates with breakpoints setting > > which requires generating callbacks for every source line) > > > > And this is where we are. If you're volunteering to look into this, > > I'll spend some time summarizing the pointers about this thread + > > the existing code in the area. Otherwise, I won't bother > > OK, if someone wants to play with this, see: > > http://starship.python.net/~vlad/lineno/ for (working at the time) patches > > Discussions on python-dev: > > - http://www.python.org/pipermail/python-dev/2000-April/subject.html > Subject: "Why do we need Traceback Objects?" > - http://www.python.org/pipermail/python-dev/1999-August/002252.html > > I'd be happy to discuss the topic again, offline, with any volunteer(s) > willing to take over (and to look closely at the debugger issue -- > I don't use the debugger and I can't make the time for it). > -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 15:29:04 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 15:29:04 +0200 (CEST) Subject: [Python-Dev] more SyntaxError subclasses! In-Reply-To: <009a01bfec17$f7fe3be0$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 12, 2000 05:43:45 PM Message-ID: <200007131329.PAA12745@python.inrialpes.fr> Fredrik Lundh wrote: > > here are a bunch of other syntax error subclasses that > might be useful: Fredrik, I don't want to let this thread die, since I'm firmly +1 on your proposal and the recent patches about more detailed syntax errors are ... well, recent . That said, what's your next proposal about making more progress on this? :-) > > I'll post a more complete proposal later... > Ah, okay. I'll be waiting for it. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas at xs4all.net Thu Jul 13 15:26:27 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 15:26:27 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.26881.172217.870049@anthem.concentric.net>; from bwarsaw@beopen.com on Thu, Jul 13, 2000 at 03:00:17AM -0400 References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <20000713152627.T7340@xs4all.nl> On Thu, Jul 13, 2000 at 03:00:17AM -0400, Barry A. Warsaw wrote: > PEP 203 will cover augmented assignments. Thomas Wouters, we were > thinking about you owning this one. Fine by me, though if it's a ploy to try and make me less involved with the other issues, it's bound to fail! :-) I'll see if my girlfriend lets me flesh out a PEP tonight. Where should I send it, by the way ? SF PM ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw at beopen.com Thu Jul 13 15:34:27 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 09:34:27 -0400 (EDT) Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <14701.27531.782443.22776@anthem.concentric.net> <396D9BE1.843BA74@lemburg.com> Message-ID: <14701.50531.652359.831584@anthem.concentric.net> >>>>> "M" == M writes: M> Anyway, I think most platforms have their own snprintf() in the M> C lib, so the code would hardly ever be needed -- perhaps its M> even safe to revert to sprintf() on those platforms via a macro M> snprintf(). Perhaps, but i think you're right, most platforms should have their own snprintf() by now. For those that don't, why re-invent the wheel? Find one with an acceptable license and drop it in. -Barry From thomas at xs4all.net Thu Jul 13 15:34:34 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 15:34:34 +0200 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <20000713091546.A5094@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 13, 2000 at 09:15:46AM -0400 References: <396DB5E8.6F12ACA4@per.dem.csiro.au> <20000713091546.A5094@thyrsus.com> Message-ID: <20000713153434.U7340@xs4all.nl> On Thu, Jul 13, 2000 at 09:15:46AM -0400, Eric S. Raymond wrote: > Mark Favas : > > I'd like to endorse Ken's idea very strongly - and suggest the name > > "plait" (which can clearly operate on 2, 3, 4, or more strands - and can > > produce beautiful effects... > plait() is *good*. Hmm... 'plait'. I don't even know what that means. I've read it before, but don't know what it means... something like 'cloth' or 'plaid' ?. And it sounds like 'plate'. I seriously prefer 'marry()', because it's widely known what marriage is. Also, it is more descriptive of what it should do: it shouldn't produce [1,4,2,5,3,6], but [(1,4),(2,5),(3,6)], or it's useless for tuple-unpacking in for-loops. And to hell with religious objections<1.1 wink> Actually, I try to respect other people's religions, having none myself, but I seriously think religion has no place in language design. A UNIX machine has processes, and those processes have children. But those child-processes have only a single parent! Did anyone ever question that ? Marry() is descriptive, and a common term, and if people refuse to marry() more than two lists, that's their choice. It's perfect. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fredrik at pythonware.com Thu Jul 13 15:54:27 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 15:54:27 +0200 Subject: [Python-Dev] re: list comprehension / pop quiz References: Message-ID: <002b01bfecd1$dcf7ca90$0900a8c0@SPIFF> (hmm. doesn't python-dev look a whole lot like python-list these days? maybe this thread, and its cousins, could be moved over to comp.lang.python for a while?) greg wrote: > 2. Need separate functions for creating tuples, lists, dicts, etc. I > liked Ken M.'s idea of one function that took a type argument, and > stitched/married/wove/welded/whatever'd its arguments to create > something of that type, as it would require only one new function. fwiw, I think it's about as unpythonish as it can be... what other function takes an instance of an object to figure out what object factory to call? and why force people to make a decision (list or tuple) that shouldn't matter in 99.9% of all cases? and wasn't this supposed to return a generator, not a sequence object? and "zip" is a pretty good name... in most cases, it will be perfectly clear from the context that it's not being used to compress things (sure, "zip" is a command name that happens to do something that this "zip" function won't do -- but the same thing applies to "dir", "del", "copy", "type", just to name a few...) btw, doesn't numpy provide something like this? reshape? From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 16:53:44 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 16:53:44 +0200 (CEST) Subject: [Python-Dev] GC paper Message-ID: <200007131453.QAA12964@python.inrialpes.fr> FYI (Neil et al.) You may want to read an interesting paper from the ECOOP'95 proceedings, entitled: "Incremental Mature Garbage Collection Using the Train Algorithm" I've put it here: http://sirac.inrialpes.fr/~marangoz/tmp/09520235.pdf Combined with an object malloc of ours, the GC scheme may benefit from the idea(s). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw at beopen.com Thu Jul 13 16:51:17 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 10:51:17 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <396D5E20.69F228EC@prescod.net> Message-ID: <14701.55141.272357.604260@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> I'm not clear on the role of opinions in this process. Do all PP> of the opinions about a proposal go in the PEP: | * "I hate this, here's why" | * "I have a minor enhancement proposal" | * "Here is my competing proposal" In some sense yes, but it's the job of the owner/shepherd to follow the various threads, and include debate about the proposal as open issues. This would all lead to one of these conclusions: - we've reached consensus and now need just implement the proposal - we've reached an impasse and the BDFL will rule by decree - the proposal is hopeless flawed and the idea should be dropped - we need more information or research - we're defering the proposal to a future release -Barry From akuchlin at mems-exchange.org Thu Jul 13 16:59:49 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 13 Jul 2000 10:59:49 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <14699.21683.305409.97490@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 11, 2000 at 01:09:07PM -0400 References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> <20000711121817.J27228@kronos.cnri.reston.va.us> <14699.21683.305409.97490@bitdiddle.concentric.net> Message-ID: <20000713105949.B14938@kronos.cnri.reston.va.us> On Tue, Jul 11, 2000 at 01:09:07PM -0400, Jeremy Hylton wrote: > AMK> Very interesting, and probably worth doing because all that > AMK> list parsing *is* a silly waste of CPU. But could poll still > AMK> live in the posixmodule, then, or be a module of its own? [1] > >The select module has exactly the same problem and could use the same >interface. They could both live in their own module. >I'm not sure what to call it. Possibilities include: > >- add it to the current select module >- new name, e.g. asyncio, fileevent >- call it _asyncore and expose it through the asyncore module I want to finish off the patch to add poll(), but don't know how to proceed. The decision to use Jeremy's more efficient API seems clear; my only question at this point is where to put it. I'd argue for adding it to the select module. Any strenuous objections? --amk From bwarsaw at beopen.com Thu Jul 13 17:07:01 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 11:07:01 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <14701.56085.908913.979451@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> Great. Thanks for doing all this work! Sure thing! KY> May i suggest small edits? No. ...oh wait. As editor my first response should always be an automatic `no' (isn't that right Jeremy?). But if you insist :) KY> These is has no sensible sentence, either. :) Barry is has no KY> sleep lately too? Point good making nawpli gatch sensible snooperscope. Rewritten for stop making sense lessly. Thanks! KY> "current undocumented" -> "currently undocumented" Fixed. KY> Colons after "here" and "for-loop". Fixed. | | class _Marriage: | | def __init__(self, args, kws): KY> Shouldn't that be "_Mawwage"? Be glad I didn't include the _Consummate class. KY> I apologize... i'm having way too much fun at your expense. It's a dirty job, but somebody needs to do it. And Gordon's been too quietly lately. -Barry From billtut at microsoft.com Thu Jul 13 17:08:10 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 13 Jul 2000 08:08:10 -0700 Subject: [Python-Dev] Unicode character name hashing Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CB@RED-MSG-50> I just had a rather unhappy epiphany this morning. F1, and f2 in ucnhash.c might not work on machines where sizeof(long) != 32 bits. When sizeof(long) != 32 bits, x will probably not overflow like it did on my IA-32 box thereby possibly giving the code fits. If some kind soul could test the ucnhash.c stuff running on the Cray Tim's always talking about, and an Alpha running Unix that'd be awesome. Thanks, Bill From jeremy at beopen.com Thu Jul 13 17:14:47 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 11:14:47 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.26881.172217.870049@anthem.concentric.net> References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <14701.56551.680037.481536@bitdiddle.concentric.net> At our meeting yesterday Tim suggested that each enhancement or language feature have two documents -- a specification and a rationale. It looks like Barry did not adopt that suggestion explicitly, but I think it's still a good approach for writing a single PEP. Each PEP should have a brief technical specification of the new feature. For a feature like augmented assignment, it would need to specify the syntax and semantics of each operation on each type and on the overloading mechanism for classes, e.g. is "a += b += c" valid syntactically and what does it mean. The PEP should also have a rationale that describes why the specification is the way it is. It should discuss alternatives that were considered and why there were not adopted. Other topics appropriate for the rationale might be motivation (why do we want this feature at all?) and comparison (what do other languages do?). The Scheme language has a similar mechanism called Scheme Requests for Implementation (SRFI), . It is not exactly the same, because Scheme seems to have no end of proposals that include specification and rationale; they just can't agree on a standard set <0.2 wink>. We might adopt some of their processes for the PEPs. Two things that each SRFI that PEPs don't yet have are: - a mail archive attached to the PEP that contains relevant discussion. A mail archive seems valuable for people interested in the next level of detail, but I'm not sure what mechanism to use to create one. (It also seems valuable because the old "search dejanews" certainly isn't stable in the long-term.) Maybe PEP authors could maintain their own archives. - a copyright notice. As a strawman, I propose that the owner/author of each PEP retains copyright, but must publish it under the OpenContent license, . Jeremy From bwarsaw at beopen.com Thu Jul 13 17:24:38 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 11:24:38 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <20000713152627.T7340@xs4all.nl> Message-ID: <14701.57142.361876.857890@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: >> PEP 203 will cover augmented assignments. Thomas Wouters, we >> were thinking about you owning this one. TW> Fine by me, though if it's a ploy to try and make me less TW> involved with the other issues, it's bound to fail! :-) Not at all! Tim practically bum rushed me to gain control of PEP202, and Jeremy all but begged for PEP200. I figured PEP201 was the one that I understood the best (not saying much :) and I needed one to flesh out as an example. BTW, PEP204 is up for grabs too. It's titled "Range Literals". TW> Where should I send it, by the way ? SF PM ? Well, you've got checkin privs so I'd say just write it and check it in. If people without checkin privs want to submit new PEPs, feel free to send them directly to me. Changes to existing PEPs should be sent to the owner, who can either make the changes themselves or send me context diffs. TW> I'll see if my girlfriend lets me flesh out a PEP TW> tonight. witty-but-crud-remark-omitted...-ba-dum-dum-ly y'rs, -Barry From jeremy at beopen.com Thu Jul 13 17:29:20 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 11:29:20 -0400 (EDT) Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: <200007121929.VAA09996@python.inrialpes.fr> References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> <200007121929.VAA09996@python.inrialpes.fr> Message-ID: <14701.57424.510413.580401@bitdiddle.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> Fredrik Lundh wrote: >> using my latest Python 2.0 build, the interpreter bombs if I >> type the following two commands: >> >> >>> def a(b): ... global b ... >> >> (1.5.2 says "name is local and global"). >> >> >> VM> Yes. This is because PyErr_PrintEx() is invoked with a NULL VM> exception. And the exception has been cleared cleared in VM> get_inprogress_dict(). VM> The appended patch should fix it. Let me know whether it works VM> for you. VM> Jeremy, what's the point of calling PyErr_Clear() in VM> get_inprogress_dict()? Looks like it was just a bug. Jeremy From guido at beopen.com Thu Jul 13 18:28:54 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 13 Jul 2000 11:28:54 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Thu, 13 Jul 2000 10:59:49 -0400." <20000713105949.B14938@kronos.cnri.reston.va.us> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> <20000711121817.J27228@kronos.cnri.reston.va.us> <14699.21683.305409.97490@bitdiddle.concentric.net> <20000713105949.B14938@kronos.cnri.reston.va.us> Message-ID: <200007131628.LAA09799@cj20424-a.reston1.va.home.com> > I want to finish off the patch to add poll(), but don't know how to > proceed. The decision to use Jeremy's more efficient API seems clear; > my only question at this point is where to put it. I'd argue for > adding it to the select module. Any strenuous objections? +1 --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Thu Jul 13 16:08:52 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 13 Jul 2000 09:08:52 -0500 (CDT) Subject: [Python-Dev] List comprehensions In-Reply-To: <396D44E7.F87983AB@prescod.net> References: <396D44E7.F87983AB@prescod.net> Message-ID: <14701.52596.651140.884121@beluga.mojam.com> >>>>> "Paul" == Paul Prescod writes: Paul> I want to summarize my feelings on the list-comp syntax Paul> issue. There is no syntax for list comprehensions that will Paul> inherently scream "cartesian product, not parallel". The only way Paul> to do it is by analogy to what they already know: Python. Paul> [for x: if y(x): for z: (x,y,z)] Agreed, however, your use of colons connotes the following to me l = [] for x in something: if y(x): for z in something_else: l.append((x,y,z)) return l Skip From skip at mojam.com Thu Jul 13 16:22:32 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 13 Jul 2000 09:22:32 -0500 (CDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: References: <20000713095237.5570E37186D@snelboot.oratrix.nl> Message-ID: <14701.53416.577920.628245@beluga.mojam.com> Ping> It seems clear that the most common use of this thing is in a Ping> parallel-iteration idiom, and that it would be quite rarely used Ping> as part of an expression elsewhere. Given that, consider: Ping> for x, y, z in marry(a, b, c): print x + y + z Ping> for x, y, z in twine(a, b, c): print x + y + z Ping> for x, y, z in lace(a, b, c): print x + y + z Ping> for x, y, z in zip(a, b, c): print x + y + z Ping> for x, y, z in parallel(a, b, c): print x + y + z Ping> Which one makes its behaviour most obvious to you? for x, y, z in stitch(a, b, c): print x + y + z ;-) -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From bwarsaw at beopen.com Thu Jul 13 17:53:38 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 11:53:38 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: <14701.58882.943772.897826@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> At our meeting yesterday Tim suggested that each enhancement JH> or language feature have two documents -- a specification and JH> a rationale. It looks like Barry did not adopt that JH> suggestion explicitly, but I think it's still a good approach JH> for writing a single PEP. Agreed. I think a single document can contain both spec and rationale. JH> Each PEP should have a brief technical specification of the JH> new feature. For a feature like augmented assignment, it JH> would need to specify the syntax and semantics of each JH> operation on each type and on the overloading mechanism for JH> classes, e.g. is "a += b += c" valid syntactically and what JH> does it mean. Yes. JH> The PEP should also have a rationale that describes why the JH> specification is the way it is. It should discuss JH> alternatives that were considered and why there were not JH> adopted. Other topics appropriate for the rationale might be JH> motivation (why do we want this feature at all?) and JH> comparison (what do other languages do?). Yes. JH> The Scheme language has a similar mechanism called Scheme JH> Requests for Implementation (SRFI), JH> . It is not exactly the same, JH> because Scheme seems to have no end of proposals that include JH> specification and rationale; they just can't agree on a JH> standard set <0.2 wink>. We might adopt some of their JH> processes for the PEPs. Great pointer, thanks. Would you like to co-own PEP001 and help me flesh out the guidelines? There are lots of good ideas in the SRFI's, but we should tailor them toward the Python community. JH> Two things that each SRFI that PEPs don't yet have are: JH> - a mail archive attached to the PEP that contains relevant JH> discussion. A mail archive seems valuable for people JH> interested in the next level of detail, but I'm not sure what JH> mechanism to use to create one. (It also seems valuable JH> because the old "search dejanews" certainly isn't stable in JH> the long-term.) Maybe PEP authors could maintain their own JH> archives. One thing mentioned in teh SRFI's is that each gets its own mailing list. That might not be a bad idea. I definitely had the notion that a PEP would contain URLs to other information (a References section). JH> - a copyright notice. As a strawman, I propose that the JH> owner/author JH> of each PEP retains copyright, but must publish it under the JH> OpenContent license, . Looks good to me. -Barry From thomas at xs4all.net Thu Jul 13 17:55:03 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 17:55:03 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.56551.680037.481536@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 11:14:47AM -0400 References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: <20000713175503.V7340@xs4all.nl> On Thu, Jul 13, 2000 at 11:14:47AM -0400, Jeremy Hylton wrote: > - a mail archive attached to the PEP that contains relevant > discussion. A mail archive seems valuable for people interested in > the next level of detail, but I'm not sure what mechanism to use to > create one. (It also seems valuable because the old "search > dejanews" certainly isn't stable in the long-term.) Maybe PEP > authors could maintain their own archives. Oh, good idea ! It'll also give me a good place to dump the two/three threads I have been saving in my inbox ;) Barry, Tim, I was also keeping the discussions on parallel-iteration and list-comprehensions. If you need those, I can send them as a nice little (hee hee) mailbox. > - a copyright notice. As a strawman, I propose that the owner/author > of each PEP retains copyright, but must publish it under the > OpenContent license, . Is there any reason not to include them in the standard Python licence, the same as the documentation ? It is documentation, after all, even if it's about unimplemented features ;) But then, I'm not a bloody lawyer, so what do I know. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Thu Jul 13 19:04:30 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 13 Jul 2000 13:04:30 -0400 Subject: [Python-Dev] more SyntaxError subclasses! In-Reply-To: <200007131329.PAA12745@python.inrialpes.fr> Message-ID: [Vladimir Marangozov] > Fredrik, I don't want to let this thread die, since I'm firmly +1 > on your proposal and the recent patches about more detailed syntax > errors are ... well, recent . That said, what's your next > proposal about making more progress on this? :-) PEP! Unless someone picks up on a thread instantly and implements it, it *always* fades away, doomed to reincarnate as if it were a new idea year after year after year, all the same arguments, all the same rebuttals, all the same greatness and noise . [/F] > I'll post a more complete proposal later... PEP it. Barry will be delighted to give it a Unique Global Identifier so that next year I can just say RTFPEP207-ly y'rs - tim. RTFPEP201-ly y'rs - tim From mal at lemburg.com Thu Jul 13 18:07:36 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 18:07:36 +0200 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <396D5D2E.4844F7FF@prescod.net> <396D9A3B.B6985C97@lemburg.com> <396D78E8.70926D96@prescod.net> Message-ID: <396DE948.F73C5C76@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > Before going down this road you should do some serious > > performance testing. ceval is *very* touchy about the order > > of the opcodes and adding indirection doesn't necessarily > > help (the compiler inlines the code again ;-). > > I'm not changing the order of the opcodes, just error handling. > > Anyhow, would performance results on my single computer be meaningful? Sure. If your changes cause a performance drop of more than 10% in pystone then this would be a sign of having to rethink the restructuring. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Thu Jul 13 18:10:19 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 12:10:19 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <20000713175503.V7340@xs4all.nl> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713175503.V7340@xs4all.nl> Message-ID: <14701.59883.957987.423016@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > Is there any reason not to include them in the standard Python licence, the > same as the documentation ? It is documentation, after all, even if it's In the IETF world, the Internet Society gets copyright of everything, so there's precedent for this. I don't think the author-based model isn't exactly what we're looking for. For specifications, there's usually an editor (the shephard, not the PEP Editor, in this case) who's name goes on there, with the copyright belonging to the organization under whose auspices the specification was written. For the W3C, the editors are named, and the copyright belongs to MIT, Inria, and Keio U. For us, the shephard is the editor and copyright should belong to the Python community (somehow; IANAL, so don't ask me how to do *that*). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Thu Jul 13 18:12:59 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 12:12:59 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.55141.272357.604260@anthem.concentric.net> References: <14701.26881.172217.870049@anthem.concentric.net> <396D5E20.69F228EC@prescod.net> <14701.55141.272357.604260@anthem.concentric.net> Message-ID: <14701.60043.481087.545575@bitdiddle.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "PP" == Paul Prescod writes: PP> I'm not clear on the role of opinions in this process. Do all of PP> the opinions about a proposal go in the PEP: PP> | * "I hate this, here's why" PP> | * "I have a minor enhancement proposal" PP> | * "Here is my competing proposal" BAW> In some sense yes, but it's the job of the owner/shepherd to BAW> follow the various threads, and include debate about the BAW> proposal as open issues. This would all lead to one of these BAW> conclusions: BAW> - we've reached consensus and now need just implement the BAW> proposal BAW> - we've reached an impasse and the BDFL will rule by decree BAW> - the proposal is hopeless flawed and the idea should be BAW> dropped BAW> - we need more information or research BAW> - we're defering the proposal to a future release This is the reason I suggested maintaining a separate mail archive of discussion. The PEP ought to represent a coherent proposal. It should discuss alternatives, but it should not be a compendium of all discussion and every possible idea. I would like to see something like the IETF model -- "rough consensus and running code" -- adopted. Python will be differently clearly, because the whole slogan is "We don't believe in kings, presidents, or voting. We believe in rough consensus and running code."[1] In the Python community, we do believe in at least one benevolent dictator for life. I propose the following guidlines: The PEP author is responsible for developing what he or she believes is a complete and coherent proposal. To be adopted, the PEP must constitute either the consensus opinion of the community (as determined by the PEP editor, Barry "Jon Postel" Warsaw) *or* be endorsed by Guido. It seems possible that we could have two different proposals for the same feature, which suggests we might want to have some notation about the final status of a PEP, e.g. accepted, rejected, etc., or that we have something like Internet drafts that will become PEPs only if adopted. Jeremy Note 1: People have suggested that it's actually the opposite: running consensus and rough code. From fdrake at beopen.com Thu Jul 13 18:15:41 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 12:15:41 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.60043.481087.545575@bitdiddle.concentric.net> References: <14701.26881.172217.870049@anthem.concentric.net> <396D5E20.69F228EC@prescod.net> <14701.55141.272357.604260@anthem.concentric.net> <14701.60043.481087.545575@bitdiddle.concentric.net> Message-ID: <14701.60205.465686.14824@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > Note 1: People have suggested that it's actually the opposite: running > consensus and rough code. When you have rough code, consensus tens to involve running competing ideas into the ground, right? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Thu Jul 13 14:25:48 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 07:25:48 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: <396DB54C.71F9332D@prescod.net> Jeremy Hylton wrote: > > ... > > - a mail archive attached to the PEP that contains relevant > discussion. A mail archive seems valuable for people interested in > the next level of detail, but I'm not sure what mechanism to use to > create one. (It also seems valuable because the old "search > dejanews" certainly isn't stable in the long-term.) Maybe PEP > authors could maintain their own archives. Here's a low-tech solution to get us started: Set up a mailbox for each PEP at pythonlabs or python.org and have people "CC:" that mail address, e.g. CC: pep202 at python.org. Run the changed ones through one of the mail to Web gateways daily. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 14:27:02 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 07:27:02 -0500 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> Message-ID: <396DB596.6F7C2C76@prescod.net> Skip Montanaro wrote: > > Paul> [for x: if y(x): for z: (x,y,z)] > > Agreed, however, your use of colons connotes the following to me > > l = [] > for x in something: > if y(x): > for z in something_else: > l.append((x,y,z)) > return l Yes, that's right. I forgot the "in something" and "in something_else" parts but your interpretation was still correct (a fault tolerant notation!!). [for x in something: if y(x): for z in something_else: (x,y,z)] -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From akuchlin at mems-exchange.org Thu Jul 13 18:44:12 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 13 Jul 2000 12:44:12 -0400 Subject: [Python-Dev] Unicode character name hashing In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CB@RED-MSG-50>; from billtut@microsoft.com on Thu, Jul 13, 2000 at 08:08:10AM -0700 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CB@RED-MSG-50> Message-ID: <20000713124412.D14938@kronos.cnri.reston.va.us> On Thu, Jul 13, 2000 at 08:08:10AM -0700, Bill Tutt wrote: >If some kind soul could test the ucnhash.c stuff running on the Cray Tim's >always talking about, and an Alpha running Unix that'd be awesome. If you want to test it on an Alpha, you could sign up for the Compaq test drive I posted about a while back; you get a 30-day account on your choice of Alphas running Tru64 4/5 or Linux. --amk From mal at lemburg.com Thu Jul 13 19:03:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 19:03:08 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <396DF64C.23833C61@lemburg.com> "Barry A. Warsaw" wrote: > > At our Pythonlabs meeting today, we decided we needed a more formal > and organized way to track all the language and other changes being > discussed on python-dev. Someone else (I don't remember who) > suggested an IETF-like approach. I like that as a model, but am not > sure how much of that formalism we need to adopt (or is even > appropriate for us). Someone on the reportlab list recently mentioned that SF supports subprojects via the task manager... wouldn't this be the ideal platform for managing PEPs ? > Wading > through, or even following, the python-dev mailing list or archives > should not be necessary. How about adding a PEP number to the subject line, e.g. "Re: [Python-Dev]:PEP999 Python Enhancement Proposals (PEPs)" ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Thu Jul 13 19:29:30 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 19:29:30 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> Message-ID: <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> greg wrote: > We don't care about anything except for %d, %s, possibly %c and %x. how about: PyObject * PyErr_SafeFormat(PyObject *exception, const char *format, ...) { va_list vargs; int n; const char* p; char* s; PyObject* string; /* figure out how large buffer we need */ va_start(vargs, format); n = 0; for (p = format; *p; p++) { if (*p == '%') { while (*++p && *p != '%' && !isalpha(*p)) ; switch (*p) { case 'c': va_arg(vargs, int); /* fall through... */ case '%': n++; break; case 'd': case 'i': case 'x': va_arg(vargs, int); n = n + 20; break; case 's': s = va_arg(vargs, char*); n = n + strlen(s); break; default: n = n + strlen(p); goto expand; } } else n = n + 1; } expand: string = PyString_FromStringAndSize(NULL, n); if (!string) return NULL; /* fill it in */ va_start(vargs, format); s = PyString_AsString(string); p = format; for (p = format; *p; p++) { if (*p == '%') { while (*++p && *p != '%' && !isalpha(*p)) ; switch (*p) { case 'c': *s++ = va_arg(vargs, int); break; case 'd': case 'i': itoa(va_arg(vargs, int), s, 10); s = s + strlen(s); break; case 'x': itoa(va_arg(vargs, int), s, 16); s = s + strlen(s); break; case 's': strcpy(s, va_arg(vargs, char*)); s = s + strlen(s); break; case '%': *s++ = '%'; break; default: strcpy(s, p-1); s = s + strlen(s); goto end; } } else *s++ = *p; } end: _PyString_Resize(&string, s - PyString_AsString(string)); PyErr_SetObject(exception, string); Py_XDECREF(string); return NULL; } From effbot at telia.com Thu Jul 13 19:42:26 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 19:42:26 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <011b01bfecf2$15952580$f2a6b5d4@hagrid> barry wrote: > I like that as a model, but am not sure how much of that formalism > we need to adopt (or is even appropriate for us). I hope PEPs won't replace the existing "small proposal, >0, patch, >0, commit" fast-track mechanism... (FTPEPs) From effbot at telia.com Thu Jul 13 19:45:00 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 19:45:00 +0200 Subject: [Python-Dev] more SyntaxError subclasses! References: Message-ID: <011c01bfecf2$17838800$f2a6b5d4@hagrid> tim wrote: > > I'll post a more complete proposal later... > > PEP it. I hope to FTPEP this one (the error tag part, not the "tons of syntaxerror variants" part) more later. From fdrake at beopen.com Thu Jul 13 19:44:51 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 13:44:51 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <011b01bfecf2$15952580$f2a6b5d4@hagrid> References: <14701.26881.172217.870049@anthem.concentric.net> <011b01bfecf2$15952580$f2a6b5d4@hagrid> Message-ID: <14702.19.539033.987227@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > I hope PEPs won't replace the existing "small proposal, >0, > patch, >0, commit" fast-track mechanism... (FTPEPs) The PEP process is not meant for small enhancements, but for things like list comprehensions, where there are real issues with determining the appropriate syntax and semantics. For small stuff, submit a patch using SF. For fixing a bug, either submit a patch or just fix it, depending on whether its within your pervue & how confident you are that your patch is appropriately portable. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Thu Jul 13 20:12:50 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 14:12:50 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <011b01bfecf2$15952580$f2a6b5d4@hagrid> Message-ID: <14702.1698.288014.78586@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: >> I like that as a model, but am not sure how much of that >> formalism we need to adopt (or is even appropriate for us). FL> I hope PEPs won't replace the existing "small proposal, >0, FL> patch, >0, commit" fast-track mechanism... (FTPEPs) I agree. PEPs are for those proposals that Tim's already seen 5 times before and never got any agreement on. :) From HZhu at knowledgetrack.com Thu Jul 13 20:33:04 2000 From: HZhu at knowledgetrack.com (Huaiyu Zhu) Date: Thu, 13 Jul 2000 11:33:04 -0700 (PDT) Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators for matrix computation] In-Reply-To: <20000712201344.A1974@newcnri.cnri.reston.va.us> Message-ID: On Wed, 12 Jul 2000, Andrew Kuchling wrote: > Why not simply write a new parser for this application that generates > the desired semantics? Maintaining a complete fork of the Python > source might not be necessary if Jeremy's Python parsing/compiling > framework could be easily modified to implement the new operators. I wonder how orthogonal would this be against the main development? Would it require a rebuild for each new release. Would it also require a patch each time? > > (While a Python variant isn't something I'm enthused about, one > language can't be all things to all people, and I don't see why matrix > operations are so important as to get extra specialized operators; > lots of people use Python for text processing or for COM, so why > shouldn't special syntax be added for *those* applications? Having a > special parser also means that other matrix-specific language changes > could be made.) Well, linear algebra is not just another special domain. It is almost as elementary as arithmetic. Vectors and matrices are fundamental concepts in mathematics that underlies almost all of "scientific computation". They distill centuries of research in science and engineering, especially computation techniques. It is unlikely that adding linear algebra support would open up a flood gate for similar constructs. Look it this way. Text processing do have their special syntaxes. A string is written as "string" instead of ['s','t','r','i','n','g']. There is even the new sep.join(list). There are also lists and dicts for to build structures for discrete maths. If we had requested that new syntax for Fourier analysis or fractal generation that would be comparable to text processing or COM. Python actually has the chance of being all things to most people. The other half of the computing crowd only needs a few very basic asistance to come across. This crowd consists of people who design bridges and missiles, figure out weather patterns or DNA structures, detect credit card fraud or defects on a microchip, design speach recognition systems or network traffic balance algorithms and machines that learn to play games. Science and technology have great power to penatrate many aspects of life. And imagine if most of that is implemented in a laguage that can also be taught in schools. Huaiyu PS. I suppose I am allowed to post to python-dev without invitation, but not subscribing to it? I find this rather strange. From effbot at telia.com Thu Jul 13 20:38:35 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 20:38:35 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: Message-ID: <01c601bfecf9$90cc8e80$f2a6b5d4@hagrid> ?!ng wrote: > > Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] > > Otherwise user-code will probably have to special case more often. as in # normal case for (x,) in zip([0, 1, 2]): ... vs. # special case for x in zip([0, 1, 2]): ... ? From jim at interet.com Thu Jul 13 20:34:03 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 14:34:03 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: Message-ID: <396E0B9B.DD74EF5@interet.com> Mark Hammond wrote: > Yes, and each of these versions has broken various programs. Of all > people, Im surprised to see you falling for the MS hype, Jim. My experience is that it often works. I have also (who hasn't?) had the experience that mysterious bugs disappear by installing the newest DLLs. > > What this means is that if the new Python 2.0 (1.6?) simply names > > its DLL python15.dll just as before, everything Just Works almost. > > That is, it Just Works provided that foo.pyd only calls Python > > C functions whose interface has not changed. > > IMO, this constrains us too much. We can't afford this - we simply dont > have the resources. I guess I haven't made myself clear. I am not proposing that we freeze the C interface. I am not proposing that we scrutinize any *.pyd's for incompatabilities. I am proposing that we leave the "python15.dll" name the same. I am proposing that the various *.pyd authors themselves either provide newer versions, or declare that their *.pyd needs no newer version of python15.dll. It is a matter of odds. If we necessarily rename python15.dll for each version release, Python has a 100% chance of failing with an obscure error or crashing if it uses any *.pyd at all unless all *.pyd are replaced with new versions. If we do not rename python15.dll, then a *.pyd may or may not fail. My guess (only a guess) is that many will work OK. > > You can support Python 1.5 and 1.6 by removing the python*.dll > > from the Windows directories, and putting it in the directory > > of python.exe so it goes with the proper executable. > > We have discussed this over and over and over, ad nauseum. If you believe > the earlier discussions were bunk, please refute them. Otherwise, simply > re-asserting something that we have previously proven to be incorrect > doesnt help anyone. Putting python15.dll in with python.exe works fine for just using the interpreter python.exe, and it works fine for Python extensions. It fails when the client for python15.dll is not python.exe, but is some other client such as COM. That is, it fails to support Python embedding in general. I proposed that someone who needed multiple Python versions could use this solution provided that he/she had no use for embedding. Not as a general policy. > > Yes, and this is a major problem, and is un-Windows-like. > > :-) "Major Crashes" are un-Windows like? What is happening to this > group - It amusing that this statement could be made without the Linux > geeks making smart-arsed comments :-) Looks like Billy Boy really _is_ > taking over the world :-) I am a Linux geek myself. And Windows is more and more stable all the time. And yes, Bill is taking over the world and I doubt DoJ can stop him. JimA From tim_one at email.msn.com Thu Jul 13 21:34:07 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 13 Jul 2000 15:34:07 -0400 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14702.1698.288014.78586@anthem.concentric.net> Message-ID: [Barry] > I agree. PEPs are for those proposals that Tim's already seen 5 times > before and never got any agreement on. :) Boost that to 50 and I'll agree . Also for proposals not necessarily originated by developers: we also have a history of losing "good ideas", just because the person fighting for them is not a developer, can't really address how to implement it, and no developer at the time "adopts" it. It's no good asking for examples, because *we've* all forgotten them <0.9 wink>. From jim at interet.com Thu Jul 13 20:38:39 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 14:38:39 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <20000711215517.E9C71E2673@oratrix.oratrix.nl> Message-ID: <396E0CAF.DA3A8740@interet.com> Jack Jansen wrote: > > Excuse my ignorance, but isn't the whole problem that the python 1.6 > DLL is in the system search path even when you are running Python 1.7? Yes, but it is necessary to put the DLL in the system search path to support Python embedding. That is, to support an arbitrary client of the DLL, such as another DLL, COM object, etc. JimA From jim at interet.com Thu Jul 13 20:43:38 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 14:43:38 -0400 Subject: [Python-Dev] O'Reilly conference References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <396E0DDA.530ADB62@interet.com> "Fred L. Drake, Jr." wrote: > > So who's going to the O'Reilly conference next week? The PythonLabs Sorry, can't make it. High air fares, gone too much already. JimA From mal at lemburg.com Thu Jul 13 20:44:27 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 20:44:27 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <01c601bfecf9$90cc8e80$f2a6b5d4@hagrid> Message-ID: <396E0E0B.C8D446BC@lemburg.com> Fredrik Lundh wrote: > > ?!ng wrote: > > > Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] > > > Otherwise user-code will probably have to special case more often. > > as in > > # normal case > for (x,) in zip([0, 1, 2]): > ... > > vs. > > # special case > for x in zip([0, 1, 2]): > ... > > ? Uhm, why should marry() be defined for a single argument ? IMHO, this only masks program errors. BTW: >>> from mx.Tools import NewBuiltins >>> marry = tuples >>> john = lists >>> marry([0,1,2]) Traceback (innermost last): File "", line 1, in ? TypeError: sequence elements must be sequences >>> marry([0,1,2],[3,4,5]) [(0, 3), (1, 4), (2, 5)] >>> john([0,1,2],[3,4,5]) ([0, 3], [1, 4], [2, 5]) ... the code is there. I'd say: use it :-) (Who invented those silly function names ?) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy at beopen.com Thu Jul 13 20:50:04 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 14:50:04 -0400 (EDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14700.34906.286143.800770@beluga.mojam.com> References: <14700.25459.555611.544163@bitdiddle.concentric.net> <14700.34906.286143.800770@beluga.mojam.com> Message-ID: <14702.3932.157846.676297@bitdiddle.concentric.net> >>>>> "SM" == Skip Montanaro writes: SyntaxError: dedent does not match any outer indentation level SM> Isn't something like "line indented incorrectly" sufficient to SM> alert the programmer to an indentation on that line? Perhaps SM> Python doesn't need to tell which direction to push the line. I like this error message best. It may not provided as much information as possible, but it seems to provide as much information as is really needed and as much as can be reasonably understood. Jeremy From jim at interet.com Thu Jul 13 20:49:40 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 14:49:40 -0400 Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> Message-ID: <396E0F44.59B63956@interet.com> Greg Stein wrote: > > On Wed, Jul 12, 2000 at 07:52:05AM +0100, Andy Robinson wrote: > >... > > Are there many other applications which > > use compression? If so, would it do > > be feasible to include it by default > > from version 1.6? > > I believe the correct approach would be to have ./configure look for zlib. > If present, then it should include the module into the build. I think that what Andy wants is to have zlib always distributed with Python, and always available. JimA From bwarsaw at beopen.com Thu Jul 13 20:53:25 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 14:53:25 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> <396E0F44.59B63956@interet.com> Message-ID: <14702.4133.886431.381684@anthem.concentric.net> >>>>> "JCA" == James C Ahlstrom writes: JCA> I think that what Andy wants is to have zlib always JCA> distributed with Python, and always available. We've argued about that before, although I'm not sure if we did so on python-dev. I argued for this, in the context of distutils, but I think Guido doesn't want to maintain this external library. We'd have to do that if we distribute it with Python. -Barry From jeremy at beopen.com Thu Jul 13 21:00:54 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 15:00:54 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: References: <200007121318.IAA14063@cj20424-a.reston1.va.home.com> Message-ID: <14702.4582.530066.817107@bitdiddle.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> On Wed, 12 Jul 2000, Guido van Rossum wrote: >> Greg subtly points out the difficulty with your proposal: this >> requires an external library that may not be available. In the >> past we've had enough complaints from people who failed to >> realize that if the build failed because of a missing external >> library, they could just disable the module that needs it. So >> I'm not for simply having it enabled in Setup.in by default. MZ> Currently there are two external libraries one needs to build a MZ> "good" Python interpreter: zlib, and expat. Well, now that MZ> Python releases from BeOpen, and not CNRI, perhaps it will be MZ> deemed all right to put them in the source distribution, and by MZ> default have a Setup.in that builds on them? Perhaps even MZ> include a "last known good" Tcl/Tk? I don't see the need to include the source code from other projects or libraries in a regular Python release. Rather, I'd like to see something like the Windows installer, which packages up third-party software like Tcl/Tk. I'm working on a nightly build system for Python that will produce a tar ball and some Linux RPMs, based in part on the very good work that Oliver Andrich did. One of the first things I discovered is that Expat isn't packaged very well for Linux systems, but that seemed easy to fix: http://www.pythonlabs.com/download/misc/rpm/expat-1.1-1.i386.rpm http://www.pythonlabs.com/download/misc/rpm/expat-1.1-1.src.rpm I'm sure there are other platforms and Linux distributions with different packaging mechanisms, but Windows and Linuxes-supporting-RPM seems like a good start. Jeremy From jeremy at beopen.com Thu Jul 13 21:10:28 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 15:10:28 -0400 (EDT) Subject: [Python-Dev] Unit testing... In-Reply-To: <396C926D.F223E686@prescod.net> References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> Message-ID: <14702.5156.863478.268256@bitdiddle.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Andrew Kuchling wrote: >> ... >> >> (I've speculated about adding a unit testing framework, similar >> to the one we use internally at the MEMS Exchange; the discipline >> of using it makes writing a test more time-consuming, but the >> tests also wind up being more comprehensive.) PP> I think PyUnit/JUnit and friends are in vogue these days. There PP> is some virtue in having a framework that could be used also by PP> extension module writers so that there is some consistency about PP> finding and invoking tests. I think there are several unit testing frameworks for Python. Would you be willing to survey the state of these projects and suggest one for adoption? I think the current regrtest script is a bit krufty; it's certainly hard to read. Two features I'd like to see in an improved testing framework are the ability to test syntax errors, e.g. check that def foo(a): global a raises a syntax error and does not dump core. It would also be good to include tests for modules like httplib that might fail for reasons that have nothing to do with the code itself. (Perhaps one could finesse the issue by building a test suite using the SimpleHTTPServer.) I don't think there's a good way to report a non-fatal error like, "couldn't run the httplib test because the network appears to be down." Jeremy From DavidA at ActiveState.com Thu Jul 13 21:16:14 2000 From: DavidA at ActiveState.com (David Ascher) Date: Thu, 13 Jul 2000 12:16:14 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Unit testing... In-Reply-To: <14702.5156.863478.268256@bitdiddle.concentric.net> Message-ID: > I think there are several unit testing frameworks for Python. Would > you be willing to survey the state of these projects and suggest one > for adoption? I think the current regrtest script is a bit krufty; > it's certainly hard to read. doctest.py! From gvwilson at nevex.com Thu Jul 13 21:17:41 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Thu, 13 Jul 2000 15:17:41 -0400 (EDT) Subject: [Python-Dev] multi-loop quiz results Message-ID: I gave 20+ grad students in computer engineering and computer science (plus a couple of profs) the questionnaire below. A summary of results is: * Everyone understood the existing syntax (A). * Most assumed that that the 'zip()' function version would yield cross-product iteration (B). This surprised me a lot, particularly as I think we all agree that 'zip()' is the most suggestive possible name for this function. * Versions (D), (F), and (H) show that semi-colon separated targets imply cross-product iteration, but 'and' and 'while' imply simultaneous iteration. * Version (G) shows that using 'and' suggests that the sequences being iterated over must have the same length. The questionnaire and a table of responses are included below (100 characters wide). Greg ---------------------------------------------------------------------- The single and double loop below print the output shown: for x in [10, 20, 30]: for x in [10, 20, 30]: print x for y in [1, 2, 3]: print x+y 10 11 20 12 30 13 21 22 23 31 32 33 Match each of the following to its output. (Note that several examples may print the same thing.) (1) (2) (3) (4) (5) (6) 11 11 11 11 error ?? 22 12 22 12 33 13 21 21 22 22 31 23 32 31 32 33 (A) for (x, y) in [[10, 1], [20, 2], [30, 3]]: 11 0 0 0 0 0 print x+y (B) for [x, y] in zip([10, 20, 30], [1, 2, 3]): 2 6 0 0 0 3 print x+y (C) for [x, y] in zip([10, 20, 30], [1, 2]): 0 0 1 4 4 2 print x+y (D) for x in [10, 20, 30]; y in [1, 2, 3]: 3 7 0 0 1 0 print x+y (E) for x in [10, 20, 30]; y in [1, 2]: 1 0 2 6 2 0 print x+y (F) for (x in [10, 20, 30]) and (y in [1, 2, 3]): 7 4 0 0 0 0 print x+y (G) for (x in [10, 20, 30]) and (y in [1, 2]): 0 0 1 2 6 2 print x+y (H) for x in [10, 20, 30] while y in [1, 2, 3]: 2 7 0 0 1 1 print x+y (I) for x in [10, 20, 30] while y in [1, 2]: 0 1 0 7 2 1 print x+y (J) for x; y in [10, 20, 30]; [1, 2, 3]: 2 3 0 1 3 2 print x+y (K) for x; y in [10, 20, 30]; [1, 2]: 0 1 0 3 5 2 print x+y From paul at prescod.net Thu Jul 13 19:27:07 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:27:07 -0500 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> <396E08E0.7536A665@lemburg.com> Message-ID: <396DFBEB.2363922C@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Is it really necessary to have all the "code" inside the square > brackets ? That's what a list comprehension is! Check the defacto PEP: http://www.cosc.canterbury.ac.nz/~greg/python/listcomp/ I take it you are against list comprehensions. > I always thought of list comprehension as a fast way to > just throw together a list, not as a way to "program" the > list contents. IMHO, that should be done using explicit > statements in the way Skip describes above. > > I would be completely satisfied with e.g. [0..10], [0..10:2] > and [10..0]. Those are not list comprehensions but "range literals." Actually, the syntax we are using is [0:10], [0:10:2], [10:0]. I prefer dotdot, but Guido chose the colon a decade ago. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From akuchlin at mems-exchange.org Thu Jul 13 21:25:14 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 13 Jul 2000 15:25:14 -0400 Subject: [Python-Dev] Unit testing... In-Reply-To: <14702.5156.863478.268256@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 03:10:28PM -0400 References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> <14702.5156.863478.268256@bitdiddle.concentric.net> Message-ID: <20000713152514.G14938@kronos.cnri.reston.va.us> On Thu, Jul 13, 2000 at 03:10:28PM -0400, Jeremy Hylton wrote: >I think there are several unit testing frameworks for Python. Would >you be willing to survey the state of these projects and suggest one >for adoption? I'm not particularly interested in looking at other tools, since I'm quite content with mems.tools.unittest, the one that Greg wrote. Earlier this week Neil S. added code coverage support for it using Skip's coverage code, so we can see which lines of code aren't getting exercised. --amk From gvwilson at nevex.com Thu Jul 13 21:26:15 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Thu, 13 Jul 2000 15:26:15 -0400 (EDT) Subject: [Python-Dev] Unit testing... In-Reply-To: <14702.5156.863478.268256@bitdiddle.concentric.net> Message-ID: On Thu, 13 Jul 2000, Jeremy Hylton wrote: >>> Andrew Kuchling wrote: >>> (I've speculated about adding a unit testing framework... >> Paul Prescod writes: >> I think PyUnit/JUnit and friends are in vogue these days. > Jeremy Hylton wrote: > I think there are several unit testing frameworks for Python. Would > you be willing to survey the state of these projects and suggest one > for adoption? Greg Wilson writes: We (Software Carpentry judges, plus a few invited others) are trying to select a narrower set of requirements for the "test tool" category. The current front runner is some sort of unit testing framework based on Kent Beck's xUnit, combined with coverage analysis so that you get a measure of code coverage. We'd be very interested in input from anyone on this list who has experience with either Steve Purcell or Cayte Lindner's PyUnit frameworks, or has worked with tools that do this double task, or has ideas about what they'd like --- the more input we get, the more likely we are to build what you want. Please contact me (gvwilson at nevex.com) or Alex Samuel (samuel at codesourcery.com). Thanks, Greg p.s. Purcell's version is http://pyunit.sourceforge.net/ Lindner's is ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip From effbot at telia.com Thu Jul 13 21:39:56 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 21:39:56 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <01c601bfecf9$90cc8e80$f2a6b5d4@hagrid> <396E0E0B.C8D446BC@lemburg.com> Message-ID: <026c01bfed02$2188e380$f2a6b5d4@hagrid> mal wrote: > Uhm, why should marry() be defined for a single argument ? because map is defined for a single argument? > ... the code is there. I'd say: use it :-) well, yes. if zip/marry/whatever is just a map without the first argument, that's definitely true ;-) in case someone wants to play: Index: Python/bltinmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v retrieving revision 2.170 diff -u -r2.170 bltinmodule.c --- Python/bltinmodule.c 2000/07/12 13:03:02 2.170 +++ Python/bltinmodule.c 2000/07/13 19:32:37 @@ -963,9 +963,10 @@ static PyObject * -builtin_map(self, args) +mapzip(self, args, zip) PyObject *self; PyObject *args; + int zip; { typedef struct { PyObject *seq; @@ -977,20 +978,31 @@ sequence *seqs = NULL, *sqp; int n, len; register int i, j; + int first_seq; n = PyTuple_Size(args); - if (n < 2) { - PyErr_SetString(PyExc_TypeError, - "map() requires at least two args"); - return NULL; + if (zip) { + if (n < 1) { + PyErr_SetString(PyExc_TypeError, + "zip() requires at least one arg"); + return NULL; + } + func = Py_None; + first_seq = 0; + } else { + if (n < 2) { + PyErr_SetString(PyExc_TypeError, + "map() requires at least two args"); + return NULL; + } + func = PyTuple_GetItem(args, 0); + first_seq = 1; + n--; } - func = PyTuple_GetItem(args, 0); - n--; - if (func == Py_None && n == 1) { /* map(None, S) is the same as list(S). */ - return PySequence_List(PyTuple_GetItem(args, 1)); + return PySequence_List(PyTuple_GetItem(args, first_seq)); } if ((seqs = PyMem_NEW(sequence, n)) == NULL) { @@ -1002,20 +1014,15 @@ int curlen; PySequenceMethods *sqf; - if ((sqp->seq = PyTuple_GetItem(args, i + 1)) == NULL) + if ((sqp->seq = PyTuple_GetItem(args, i + first_seq)) == NULL) goto Fail_2; sqp->sqf = sqf = sqp->seq->ob_type->tp_as_sequence; if (sqf == NULL || sqf->sq_length == NULL || - sqf->sq_item == NULL) - { - static char errmsg[] = - "argument %d to map() must be a sequence object"; - char errbuf[sizeof(errmsg) + 25]; - - sprintf(errbuf, errmsg, i+2); - PyErr_SetString(PyExc_TypeError, errbuf); + sqf->sq_item == NULL) { + PyErr_Format(PyExc_TypeError, + "argument %d to map() must be a sequence object", i+2); goto Fail_2; } @@ -1118,6 +1125,16 @@ return NULL; } + +static PyObject * +builtin_map(self, args) + PyObject *self; + PyObject *args; +{ + return mapzip(self, args, 0); +} + + static char map_doc[] = "map(function, sequence[, sequence, ...]) -> list\n\ \n\ @@ -1130,6 +1147,22 @@ static PyObject * +builtin_zip(self, args) + PyObject *self; + PyObject *args; +{ + return mapzip(self, args, 1); +} + + +static char zip_doc[] = +"zip(sequence[, sequence, ...]) -> list\n\ +\n\ +Return a list of the items of the sequence (or a list of tuples if more\n\ +than one sequence)."; + + +static PyObject * builtin_setattr(self, args) PyObject *self; PyObject *args; @@ -2327,6 +2360,7 @@ {"unichr", builtin_unichr, 1, unichr_doc}, {"vars", builtin_vars, 1, vars_doc}, {"xrange", builtin_xrange, 1, xrange_doc}, + {"zip", builtin_zip, 1, zip_doc}, {NULL, NULL}, }; From jeremy at beopen.com Thu Jul 13 21:37:39 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 15:37:39 -0400 (EDT) Subject: [Python-Dev] Unit testing... In-Reply-To: <20000713152514.G14938@kronos.cnri.reston.va.us> References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> <14702.5156.863478.268256@bitdiddle.concentric.net> <20000713152514.G14938@kronos.cnri.reston.va.us> Message-ID: <14702.6787.986976.271026@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Thu, Jul 13, 2000 at 03:10:28PM -0400, Jeremy Hylton wrote: >> I think there are several unit testing frameworks for Python. >> Would you be willing to survey the state of these projects and >> suggest one for adoption? AMK> I'm not particularly interested in looking at other tools, I didn't mean that I wanted you to do it :-). Are you saying that you personally aren't interested or that the rest of us shouldn't be interested in either? AMK> since I'm quite content with mems.tools.unittest, the one that AMK> Greg wrote. Earlier this week Neil S. added code coverage AMK> support for it using Skip's coverage code, so we can see which AMK> lines of code aren't getting exercised. I'm not at all familiar with this code. Has it been released? Is it open source? Could it be used for the Python test suite? Jeremy From mal at lemburg.com Thu Jul 13 21:51:59 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 21:51:59 +0200 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> <396E08E0.7536A665@lemburg.com> <396DFBEB.2363922C@prescod.net> Message-ID: <396E1DDF.1861EE80@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > Is it really necessary to have all the "code" inside the square > > brackets ? > > That's what a list comprehension is! Check the defacto PEP: > > http://www.cosc.canterbury.ac.nz/~greg/python/listcomp/ > > I take it you are against list comprehensions. If it means writing code in square brackets: yes -- I don't see any real benefit other than confusing the reader... it doesn't even gain any performance (I would have thought that constant ranges like [0:10] would generate [0,1,2,3,4,5,6,7,8,9] and make this a constant, but that doesn't seem to be the case). > > I always thought of list comprehension as a fast way to > > just throw together a list, not as a way to "program" the > > list contents. IMHO, that should be done using explicit > > statements in the way Skip describes above. > > > > I would be completely satisfied with e.g. [0..10], [0..10:2] > > and [10..0]. > > Those are not list comprehensions but "range literals." Oh, so I won't get these with list comprehension ? Hmm, then I'm posting on the wrong thread, I guess ;-) > Actually, the > syntax we are using is [0:10], [0:10:2], [10:0]. I prefer dotdot, but > Guido chose the colon a decade ago. Say, wouldn't it make more sense to have these notations generate tuples (which are immutable and could thus be stored as constants) rather than lists ?! for x in (0:10): print x Hmm, looks strange, perhaps not such a good notation.... for x in (0..10): print x or even: for x in 0..10: print x Oh, now this looks much better :-) The for-loop opcode could even make some use of this by not generating a tuple at all (it could use a special mutable counter like the one available in my speedup patch for 1.5: http://starship.python.net/~lemburg/mxPython-1.5.patch.gz [see the ceval part of the patch -- it uses the counter object the patch also contains which provides a mutable integer implementation for just this purpose] The patch also includes some other performance enhancements such as a small dictionary enhancement and many other things which have already made it into 2.0) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Thu Jul 13 19:34:44 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:34:44 -0500 Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> <396E0F44.59B63956@interet.com> <14702.4133.886431.381684@anthem.concentric.net> Message-ID: <396DFDB4.A257245C@prescod.net> "Barry A. Warsaw" wrote: > > ... > > We've argued about that before, although I'm not sure if we did so on > python-dev. I argued for this, in the context of distutils, but I > think Guido doesn't want to maintain this external library. We'd have > to do that if we distribute it with Python. I don't understand the last sentence???? Distributing a library with Python requires no more than "cp". Do we maintain TK on Windows? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 19:35:01 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:35:01 -0500 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <396DFDC5.6780A710@prescod.net> Huaiyu Zhu wrote: > > ... > > I wonder how orthogonal would this be against the main development? Would > it require a rebuild for each new release. Would it also require a patch > each time? I think that the idea is that you could install new syntaxes in the same way you install new modules...of course only after careful consideration!!! > Look it this way. Text processing do have their special syntaxes. Okay, but probably 90% of Python programmers do text processing at some point. Not so for matrix calculation. You believe that the Python world would grow greatly if we did matrices natively. I don't know if I believe that. I'm not entirely against your proposal but you've got to expect major pushback on such large-scale syntax and semantic changes. > PS. I suppose I am allowed to post to python-dev without invitation, but not > subscribing to it? I find this rather strange. Yes, it is rather strange. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From m.favas at per.dem.csiro.au Thu Jul 13 22:15:34 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Fri, 14 Jul 2000 04:15:34 +0800 Subject: [Python-Dev] Unicode character name hashing Message-ID: <396E2366.66F62B24@per.dem.csiro.au> [Bill has epiphany] >I just had a rather unhappy epiphany this morning. >F1, and f2 in ucnhash.c might not work on machines where sizeof(long) >!= 32 bits. I get the following from test_ucn on an Alpha running Tru64 Unix: python Lib/test/test_ucn.py UnicodeError: Unicode-Escape decoding error: Invalid Unicode Character Name This is with the current CVS - and it's been failing this test for some time now. I'm happy to test any fixes... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From mal at lemburg.com Thu Jul 13 20:22:24 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 20:22:24 +0200 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> Message-ID: <396E08E0.7536A665@lemburg.com> Paul Prescod wrote: > > Skip Montanaro wrote: > > > > Paul> [for x: if y(x): for z: (x,y,z)] > > > > Agreed, however, your use of colons connotes the following to me > > > > l = [] > > for x in something: > > if y(x): > > for z in something_else: > > l.append((x,y,z)) > > return l > > Yes, that's right. I forgot the "in something" and "in something_else" > parts but your interpretation was still correct (a fault tolerant > notation!!). > > [for x in something: if y(x): for z in something_else: (x,y,z)] Is it really necessary to have all the "code" inside the square brackets ? I always thought of list comprehension as a fast way to just throw together a list, not as a way to "program" the list contents. IMHO, that should be done using explicit statements in the way Skip describes above. I would be completely satisfied with e.g. [0..10], [0..10:2] and [10..0]. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at mems-exchange.org Thu Jul 13 22:46:42 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 13 Jul 2000 16:46:42 -0400 Subject: [Python-Dev] Unit testing... In-Reply-To: <14702.6787.986976.271026@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 03:37:39PM -0400 References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> <14702.5156.863478.268256@bitdiddle.concentric.net> <20000713152514.G14938@kronos.cnri.reston.va.us> <14702.6787.986976.271026@bitdiddle.concentric.net> Message-ID: <20000713164642.A15987@kronos.cnri.reston.va.us> On Thu, Jul 13, 2000 at 03:37:39PM -0400, Jeremy Hylton wrote: >I didn't mean that I wanted you to do it :-). Are you saying that you >personally aren't interested or that the rest of us shouldn't be >interested in either? I'm personally not interested in doing the work, that's all. Someone should definitely do this, though; a better standard testing framework would be very useful. >I'm not at all familiar with this code. Has it been released? Is it >open source? Could it be used for the Python test suite? Not formally released, no; an old version is hiding inside Quixote (http://www.mems-exchange.org/exchange/software/files/quixote/) as test.unittest.py, because it was used to write the included test suites. I could go try to get a licence for it, but you know what that'll be like. (My, aren't I sounding bitter today...) --amk From thomas at xs4all.net Thu Jul 13 23:07:00 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 23:07:00 +0200 Subject: [Python-Dev] multi-loop quiz results In-Reply-To: ; from gvwilson@nevex.com on Thu, Jul 13, 2000 at 03:17:41PM -0400 References: Message-ID: <20000713230659.W7340@xs4all.nl> On Thu, Jul 13, 2000 at 03:17:41PM -0400, Greg Wilson wrote: > I gave 20+ grad students in computer engineering and computer science > (plus a couple of profs) the questionnaire below. A summary of > results is: > * Versions (D), (F), and (H) show that semi-colon separated targets > imply cross-product iteration, but 'and' and 'while' imply > simultaneous iteration. Really ? Looking at it, it looks like 'while' also implies cross-product: > (H) > for x in [10, 20, 30] while y in [1, 2, 3]: 2 7 0 0 1 1 > print x+y > > (I) > for x in [10, 20, 30] while y in [1, 2]: 0 1 0 7 2 1 > print x+y 'and' does seem to be the 'right' thing, but mostly in the awkward extra-grouped variant... Apparently using a builtin instead of a syntax change is a good thing. Hopefully it will at least get people thinking, instead of assuming. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Thu Jul 13 19:40:25 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:40:25 -0500 Subject: [Python-Dev] Unit testing... References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> <14702.5156.863478.268256@bitdiddle.concentric.net> Message-ID: <396DFF09.191A04EE@prescod.net> Jeremy Hylton wrote: > > ... > > I think there are several unit testing frameworks for Python. No, not the right guy. I'm pretty low-tech when it comes to testing. I just write long scripts that use many methods and then check coverage. I was hoping that someone else would jump in and point out the many virtues of the trendy XUnit testing framework. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 19:51:04 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:51:04 -0500 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> <396E08E0.7536A665@lemburg.com> <396DFBEB.2363922C@prescod.net> <396E1DDF.1861EE80@lemburg.com> Message-ID: <396E0188.33861CC7@prescod.net> "M.-A. Lemburg" wrote: > > If it means writing code in square brackets: yes -- > I don't see any real benefit other than confusing the reader... > it doesn't even gain any performance We've discussed making them lazy, which would improve performance in some cases...especially with infinite lists. :) > Oh, so I won't get these with list comprehension ? Hmm, then > I'm posting on the wrong thread, I guess ;-) Well, I didn't want to say it, but... > Say, wouldn't it make more sense to > have these notations generate tuples (which are immutable and > could thus be stored as constants) rather than lists ?! I think that the notation should create a generator. > The for-loop opcode could even make some use of this by not generating > a tuple at all (it could use a special mutable counter like the > one available in my speedup patch for 1.5: We discussed this yesterday. Anyhow, you don't need to use tuples to get the speedup. You just have to recognize the pattern in a peephole optimizer. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From jim at interet.com Thu Jul 13 23:42:11 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 17:42:11 -0400 Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> <396E0F44.59B63956@interet.com> <14702.4133.886431.381684@anthem.concentric.net> Message-ID: <396E37B3.39C9BEC7@interet.com> "Barry A. Warsaw" wrote: > > >>>>> "JCA" == James C Ahlstrom writes: > > JCA> I think that what Andy wants is to have zlib always > JCA> distributed with Python, and always available. > > We've argued about that before, although I'm not sure if we did so on > python-dev. I argued for this, in the context of distutils, but I > think Guido doesn't want to maintain this external library. We'd have > to do that if we distribute it with Python. I don't think distributing zlib means we have to maintain it. Well, I guess we would have to get the new zlib version before each release, and re-write the interface functions if they change. Hmmm... Actually, I thought the issue was the megabyte size of the distribution. JimA From esr at thyrsus.com Thu Jul 13 23:54:29 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 17:54:29 -0400 Subject: [Python-Dev] List comprehensions In-Reply-To: <396E0188.33861CC7@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 12:51:04PM -0500 References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> <396E08E0.7536A665@lemburg.com> <396DFBEB.2363922C@prescod.net> <396E1DDF.1861EE80@lemburg.com> <396E0188.33861CC7@prescod.net> Message-ID: <20000713175429.A6605@thyrsus.com> Paul Prescod : > > Say, wouldn't it make more sense to > > have these notations generate tuples (which are immutable and > > could thus be stored as constants) rather than lists ?! > > I think that the notation should create a generator. I heartily agree. -- Eric S. Raymond To stay young requires the unceasing cultivation of the ability to unlearn old falsehoods. -- Lazarus Long From billtut at microsoft.com Thu Jul 13 23:44:34 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 13 Jul 2000 14:44:34 -0700 Subject: [Python-Dev] RE: Unicode character name hashing Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CF@RED-MSG-50> Does this patch happen to fix it? I'm afraid my skills relating to signed overflow is a bit rusty... :( Bill =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/ucnhash.c,v retrieving revision 1.2 diff -u -r1.2 ucnhash.c --- ucnhash.c 2000/06/29 00:06:39 1.2 +++ ucnhash.c 2000/07/13 21:41:07 @@ -30,12 +30,12 @@ len = cch; p = (unsigned char *) key; - x = 1694245428; + x = (long)0x64fc2234; while (--len >= 0) - x = (1000003*x) ^ toupper(*(p++)); + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); x ^= cch + 10; - if (x == -1) - x = -2; + if (x == (long)0xFFFFFFFF) + x = (long)0xfffffffe; x %= k_cHashElements; /* ensure the returned value is positive so we mimic Python's % operator */ if (x < 0) @@ -52,12 +52,12 @@ len = cch; p = (unsigned char *) key; - x = -1917331657; + x = (long)0x8db7d737; while (--len >= 0) - x = (1000003*x) ^ toupper(*(p++)); + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); x ^= cch + 10; - if (x == -1) - x = -2; + if (x == (long)0xFFFFFFFF) + x = (long)0xfffffffe; x %= k_cHashElements; /* ensure the returned value is positive so we mimic Python's % operator */ if (x < 0) -----Original Message----- From: Mark Favas [mailto:m.favas at per.dem.csiro.au] Sent: Thursday, July 13, 2000 1:16 PM To: python-dev at python.org; Bill Tutt Subject: Unicode character name hashing [Bill has epiphany] >I just had a rather unhappy epiphany this morning. >F1, and f2 in ucnhash.c might not work on machines where sizeof(long) >!= 32 bits. I get the following from test_ucn on an Alpha running Tru64 Unix: python Lib/test/test_ucn.py UnicodeError: Unicode-Escape decoding error: Invalid Unicode Character Name This is with the current CVS - and it's been failing this test for some time now. I'm happy to test any fixes... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From thomas at xs4all.net Thu Jul 13 23:53:56 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 23:53:56 +0200 Subject: [Python-Dev] [PEP204] Range Literals Message-ID: <20000713235356.X7340@xs4all.nl> On Thu, Jul 13, 2000 at 11:24:38AM -0400, Barry A. Warsaw wrote: > BTW, PEP204 is up for grabs too. It's titled "Range Literals". As I already wrote Barry, I'll do this one -- but only if it's a no-brainer. The patch is already written and I hadn't heard complaints about the syntax, but now I hear some rumbling about how it should be a generator instead of a list constructor. I don't feel like digging into that particular dungball, though, having no experience what so ever with iterators, generators or languages that implement those. (So I'm a C and Python programmar by heart. Sue me.) That isn't to say I think it's a bad idea, not at all. I just don't want to do it :-) But if anyone else wants to implement it, and do so before 2.0, yell now, and you can take over the entire range-literal thing as well. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Thu Jul 13 23:56:53 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 00:56:53 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <01c601bfecf9$90cc8e80$f2a6b5d4@hagrid> Message-ID: On Thu, 13 Jul 2000, Fredrik Lundh wrote: > as in > > # normal case > for (x,) in zip([0, 1, 2]): > ... > > vs. > > # special case > for x in zip([0, 1, 2]): > ... > I'm sorry, I don't buy that. # "special case" for x in [0, 1, 2]: ... # "special case" do_something_that_requires_a_list_of_tuples(zip(*lists)) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From fdrake at beopen.com Fri Jul 14 00:01:22 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 18:01:22 -0400 (EDT) Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: <20000713235356.X7340@xs4all.nl> References: <20000713235356.X7340@xs4all.nl> Message-ID: <14702.15410.306511.372250@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > As I already wrote Barry, I'll do this one -- but only if it's a no-brainer. > The patch is already written and I hadn't heard complaints about the syntax, > but now I hear some rumbling about how it should be a generator instead of a > list constructor. I don't feel like digging into that particular dungball, > though, having no experience what so ever with iterators, generators or Don't confuse being the PEP shephard with being the implementor, though *having* an implementation is important. Who does it is secondary. Can't the implementation be to create an xrange object instead of a list? Seems easy enough on first glance. But then, I've been carefully ignoring that whole discussion. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From moshez at math.huji.ac.il Fri Jul 14 00:03:54 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 01:03:54 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: On Thu, 13 Jul 2000, Jeremy Hylton wrote: > I don't see the need to include the source code from other projects or > libraries in a regular Python release. Rather, I'd like to see > something like the Windows installer, which packages up third-party > software like Tcl/Tk. But I'm exactly concerned with minority platforms here: people who have packagers can manage without our help. Are you going to make an installer for Solaris? AIX? Then at least help these people build Python from source -- with "known compatible versions". I *don't* think it should be done for beta versions, only as an alternative release -- a "rich source release". (If I have some time, I might try to build something like that for 2.0 final, at any rate.) I'm currently drawing a list for extensions to include: -- zlib -- Tcl/Tk -- expat -- PIL -- Anything else? I really want something with "everything" in it. My motivation: I work on quite a few Unixes at work (AIX, Solaris, HP and probably more to come). Installing Python on any of these is a pain -- exactly because of the need to download 5-6 packages, and install them iteratively. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From guido at beopen.com Fri Jul 14 01:05:12 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 13 Jul 2000 18:05:12 -0500 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: Your message of "Thu, 13 Jul 2000 23:53:56 +0200." <20000713235356.X7340@xs4all.nl> References: <20000713235356.X7340@xs4all.nl> Message-ID: <200007132305.SAA11276@cj20424-a.reston1.va.home.com> > As I already wrote Barry, I'll do this one -- but only if it's a no-brainer. > The patch is already written and I hadn't heard complaints about the syntax, > but now I hear some rumbling about how it should be a generator instead of a > list constructor. I don't feel like digging into that particular dungball, > though, having no experience what so ever with iterators, generators or > languages that implement those. (So I'm a C and Python programmar by heart. > Sue me.) It should be sweet and simple. Make it return a list, just like range(). The whole point is that an optimizer can recognize that you are doing "for i in [0:10]: ...", and use a generator anyway -- but that's a thing for later to implement. Also, don't bother with (::) to return an xrange as has been proposed. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From moshez at math.huji.ac.il Fri Jul 14 00:13:49 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 01:13:49 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: On Thu, 13 Jul 2000, Jeremy Hylton wrote: > Two things that each SRFI that PEPs don't yet have are: > > - a mail archive attached to the PEP that contains relevant > discussion. A mail archive seems valuable for people interested in > the next level of detail, but I'm not sure what mechanism to use to > create one. (It also seems valuable because the old "search > dejanews" certainly isn't stable in the long-term.) Maybe PEP > authors could maintain their own archives. I'm sure Roundup is up to this > - a copyright notice. As a strawman, I propose that the owner/author > of each PEP retains copyright, but must publish it under the > OpenContent license, . F**k licenses, they're more trouble then they're worth. Why not simply decree that it must be put in the public domain? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From esr at thyrsus.com Fri Jul 14 00:32:20 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 18:32:20 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: ; from moshez@math.huji.ac.il on Fri, Jul 14, 2000 at 01:03:54AM +0300 References: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: <20000713183220.A6899@thyrsus.com> Moshe Zadka : > I'm currently drawing a list for extensions to include: > > -- zlib > -- Tcl/Tk > -- expat > -- PIL > -- Anything else? > > I really want something with "everything" in it. > > My motivation: I work on quite a few Unixes at work (AIX, Solaris, HP and > probably more to come). Installing Python on any of these is a pain -- > exactly because of the need to download 5-6 packages, and install them > iteratively. I'm with Moshe on this one -- and I'll go further: I think the `rich' distribution ought to be the default mode, and would be willing to take on substantial work to help it happen. I agree with his choice of initial modules, too, and would certainly add ncurses, and would be sorely tempted to add libpng. Moshe's desire is a logical consequence of the "batteries are included" philosophy which is one of Python's central strengths. A good language *ought* to guarantee all its developers and users fuss-free access to a rich kit of state-of-the-art open source tools and libraries. If this means taking on the complexities of tracking several auxiliary libraries and making sure there is a consistent Python API to them as they evolve, so be it. That's our job, gentlemen. -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. From gstein at lyra.org Fri Jul 14 00:27:25 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 15:27:25 -0700 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.56551.680037.481536@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 11:14:47AM -0400 References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: <20000713152725.Z29590@lyra.org> On Thu, Jul 13, 2000 at 11:14:47AM -0400, Jeremy Hylton wrote: >... > - a copyright notice. As a strawman, I propose that the owner/author > of each PEP retains copyright, but must publish it under the > OpenContent license, . All right. This just gets me. Why must we assert copyrights on these things? Come on, people. Aren't we seeing Python 2.0 release problems because of copyrights? It isn't like this stuff is Intellectual Property or anything. It's just a summary of where the discussion is! It's a communication mechanism to bring people up to speed on the issues, concerns, and approaches. But something that needs to be copyrighted? Geez. That's just a bit much. Cheers, -g -- Greg Stein, http://www.lyra.org/ From moshez at math.huji.ac.il Fri Jul 14 00:31:35 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 01:31:35 +0300 (IDT) Subject: [Python-Dev] Re: extra packages (was: zlib not compiled by default) In-Reply-To: <20000713153251.A29590@lyra.org> Message-ID: On Thu, 13 Jul 2000, Greg Stein wrote: > On Fri, Jul 14, 2000 at 01:03:54AM +0300, Moshe Zadka wrote: > >... > > I'm currently drawing a list for extensions to include: > > > > -- zlib > > -- Tcl/Tk > > -- expat > > -- PIL > > -- Anything else? > > > > I really want something with "everything" in it. > > Don't forget pure-Python packages. > > I'd also add: mx*, and PyXML Right. The list goes on and on, but I think we can change the world with only 10 packages. and-i'm-forgetting-numpy-which-i-always-wanted-to-be-in-the-core-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Fri Jul 14 00:33:19 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 01:33:19 +0300 (IDT) Subject: [Python-Dev] Re: extra packages (was: zlib not compiled by default) In-Reply-To: <20000713153251.A29590@lyra.org> Message-ID: On Fri, Jul 14, 2000 at 01:03:54AM +0300, Moshe Zadka wrote: > I'm currently drawing a list for extensions to include: > > -- zlib > -- Tcl/Tk > -- expat > -- PIL > -- Anything else? > > I really want something with "everything" in it. Question to PythonLabs team: should I PEP this, or is this considered non-PEPable? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gstein at lyra.org Fri Jul 14 00:32:51 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 15:32:51 -0700 Subject: [Python-Dev] extra packages (was: zlib not compiled by default) In-Reply-To: ; from moshez@math.huji.ac.il on Fri, Jul 14, 2000 at 01:03:54AM +0300 References: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: <20000713153251.A29590@lyra.org> On Fri, Jul 14, 2000 at 01:03:54AM +0300, Moshe Zadka wrote: >... > I'm currently drawing a list for extensions to include: > > -- zlib > -- Tcl/Tk > -- expat > -- PIL > -- Anything else? > > I really want something with "everything" in it. Don't forget pure-Python packages. I'd also add: mx*, and PyXML Cheers, -g -- Greg Stein, http://www.lyra.org/ From jeremy at beopen.com Fri Jul 14 01:09:12 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 19:09:12 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <20000713152725.Z29590@lyra.org> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> Message-ID: <14702.19480.746784.235766@bitdiddle.concentric.net> >>>>> "GS" == Greg Stein writes: GS> It isn't like this stuff is Intellectual Property or GS> anything. It's just a summary of where the discussion is! It's a GS> communication mechanism to bring people up to speed on the GS> issues, concerns, and approaches. This may not be material to the discussion: It's not just a summary of discussion. It's a real proposal, including specification for the feature and rationale for the spec. GS> But something that needs to be copyrighted? Geez. That's just a GS> bit much. I think it stinks, but I'd hate to see distribution of these documents hampered because someone comes along and denies us the right to use it. I'd be satisfied with a statement of copyright or the notice "placed in the public domain" attached to each of them. My only concern is that without some explicit expression of rights, some party might try to prevent us from distributing a PEP. Jeremy From fdrake at beopen.com Fri Jul 14 01:07:21 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 19:07:21 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <20000713152725.Z29590@lyra.org> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> Message-ID: <14702.19369.605446.28207@cj42289-a.reston1.va.home.com> Greg Stein writes: > Why must we assert copyrights on these things? Come on, people. Aren't we > seeing Python 2.0 release problems because of copyrights? No. *Licensing* is distinct from copyright, and that's where we see problems. The copyrights are indisputable, but are not a problem. > It isn't like this stuff is Intellectual Property or anything. It's just a Let's not get into that one! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jul 14 01:11:27 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 19:11:27 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14702.19480.746784.235766@bitdiddle.concentric.net> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> <14702.19480.746784.235766@bitdiddle.concentric.net> Message-ID: <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > I think it stinks, but I'd hate to see distribution of these documents > hampered because someone comes along and denies us the right to use > it. I'd be satisfied with a statement of copyright or the notice > "placed in the public domain" attached to each of them. The copyright and license are both required to ensure permission to use, distribute, etc. There are a few "open content" licenses, and a reference to one of those should be sufficient. I don't know which one to recommend, however; that would require spending a little time reading them. > My only concern is that without some explicit expression of rights, > some party might try to prevent us from distributing a PEP. You hit that nail! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From m.favas at per.dem.csiro.au Fri Jul 14 01:22:48 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Fri, 14 Jul 2000 07:22:48 +0800 Subject: [Python-Dev] Re: extra packages (was: zlib not compiled by default) Message-ID: <396E4F48.71AD4103@per.dem.csiro.au> I'd like to see Pmw in there as well - and definitely numpy. Whatever _did_ happen to the proposal that it become part of the core...? -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From peter at schneider-kamp.de Fri Jul 14 04:38:33 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 14 Jul 2000 02:38:33 +0000 Subject: [Python-Dev] Pythonb at SourceForge FAQ Message-ID: <396E7D29.7AC68EA6@schneider-kamp.de> I started a small FAQ. Where should I put this? HTML file attached. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From gstein at lyra.org Fri Jul 14 02:45:54 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 17:45:54 -0700 Subject: [Python-Dev] Pythonb at SourceForge FAQ In-Reply-To: <396E7D29.7AC68EA6@schneider-kamp.de>; from peter@schneider-kamp.de on Fri, Jul 14, 2000 at 02:38:33AM +0000 References: <396E7D29.7AC68EA6@schneider-kamp.de> Message-ID: <20000713174554.R29590@lyra.org> Since we don't have ready access to python.org, I would suggest turning on the Python web pages at SF and placing it there. (of course, with obvious links from python.sourceforge.net to python.org) Having a FAQ about Python/SF at SF makes sense to me :-) Cheers, -g On Fri, Jul 14, 2000 at 02:38:33AM +0000, Peter Schneider-Kamp wrote: > I started a small FAQ. Where should I put this? > > HTML file attached. > > Peter > -- > Peter Schneider-Kamp ++47-7388-7331 > Herman Krags veg 51-11 mailto:peter at schneider-kamp.de > N-7050 Trondheim http://schneider-kamp.de > > Python at SourceForge - Frequently Asked Questions > > 0. Contents > > [1]1. General > > 1. [2]What is SourceForge? > 2. [3]Where do I find Python there? > > [4]2. CVS > > 1. [5]How do I check out a CVS version of Python? > 2. [6]What settings should I use? > 3. [7]Troubleshooting: "Permission Denied" > 4. [8]Where can I learn more about CVS? > > [9]3. Patches > > 1. [10]How to make a patch? > 2. [11]How to submit patches? > 3. [12]How to change the status of a patch? > > [13]A. Appendix > > 1. [14]Patch Manager Guidelines [09.07.2000] > 2. [15]Python Patch Submission Guidelines [29.06.2000] > > 1. General > > 1.1.: > > Q: What is SourceForge? > > A: > > [16]SourceForge is a free hosting service for [17]OpenSource projects. > The main website is found at > > [18]http://sourceforge.net > > 1.2.: > > Q: Where can I find Python on SourceForge? > > A: > > The [19]Python project page can be found at > > [20]http://sourceforge.net/projects/python > > 2. CVS > > 2.1.: > > Q: How do I check out a CVS version of Python? > > A: > > If you are not a SourceForge-recognized Python developer you can > still check out an anonymous CVS version (read-only) of Python: > > export > CVSROOT=:pserver:anonymous at cvs.python.sourceforge.net:/cvsroot/pyth > on > cvs login > cvs -z3 co python > > If you are indeed a developer you can check out a read/write version > with ssh: > > export CVS_RSH=ssh > export > CVSROOT=sf_username at cvs.python.sourceforge.net:/cvsroot/python > cvs -z3 co python > > 2.2.: > > Q: What setting should I use? > > A: > > That is, of course, hard to answer in the general case. I use the > following .cvsrc file: > > diff -c > update -d > > This defaults diff to context diffs (almost a requirement as > everything else is harder to read) and tells update to automatically > checkout new subdirectories. > > 2.3.: > > Q: I get the following error message: > > Sorry, you don't have read/write access to the history file > /cvsroot/python/CVSROOT/history > Permission denied > > A: > > If you are not a developer, you don't have read/write access. You have > to check out an anonymous copy. If you are a developer you have to be > in the SourceForge group "python". You can check this with the > following commands: > > ssh -l sf_username shell.sourceforge.net > groups > > If you have just recently (< 6 hours) been added to the Python > project, you probably have to wait for the SourceForge servers to > synch up. This can take up to 6 hours. > > 2.4.: > > Q: Where can I learn more about CVS? > > A: > > For SourceForge specific information consult their CVS documentation > at > > [21]http://sfdocs.sourceforge.net/sfdocs > > For general (and more advanced) information consult the free CVS Book > at > > [22]http://cvsbook.red-bean.com/cvsbook.html#Introduction > > 3. Patches > > 3.1.: > > Q: How to make a patch? > > A: > > If you are using CVS (anonymous or developer) you can use CVS to make > the patches for you. Just edit your local copy and enter the following > command: > > cvs diff | tee ~/name_of_the_patch.diff > > Else you can use the diff util which comes with most operating systems > (a Windows version is available as part of the cygwin tools). > > > 3.2.: > > Q: How to submit a patch? > > A: > > Please read the [23]Patch Submission Guidelines at > > [24]http://www.python.org/patches > > A [25]recent copy can be found in the Appendix of this FAQ. > > > 3.3.: > > Q: How to change the status of a patch? > > A: > > To change the status of a patch or assign it to somebody else you have > to be a) a SourceForge-recognized Python developer and b) a patch > administrator. Unfortunately the SourceForge default for developers is > not to be patch administrators. Contact one of the project > administrators if the following does not work for you. > > Click on the patch itself. In the screen that comes up, there is a > drop-box for "Assigned To:" and a drop-box for "Status:" where you can > select a new responsible developer or a new status respectively. After > selecting the appropriate victim and status, hit the "Submit Changes" > button at the bottom of the page. > > For more information about the use of the "Status:" and "Assigned To:" > fields consult the [26]Patch Manager Guidelines. A recent copy can be > found in the Appendix of this FAQ. > > A. Appendix > > A.1.: Patch Manager Guidelines > > Intended use of SourceForge patch status & "assigned to" fields > > revision 2 09-Jul-2000 > > In general, the status field should be close to self-explanatory, and > the "Assigned to:" field should be the person responsible for taking > the next step in the patch process. Both fields are expected to > change value over the life of a patch; the normal workflow is detailed > below. > > When you've got the time and the ability, feel free to move any patch > that catches your eye along, whether or not it's been assigned to > you. And if you're assigned to a patch but aren't going to take > reasonably quick action (for whatever reason), please assign it to > someone else ASAP: at those times you can't actively help, actively > get out of the way. > > If you're an expert in some area and know that a patch in that area is > both needed and non-controversial, just commit your changes directly > -- no need then to get the patch mechanism involved in it. > > You should add a comment to every patch assigned to you at least once > a week, if only to say that you realize it's still on your plate. > This rule is meant to force your attention periodically: patches get > harder & harder to deal with the longer they sit. > > Open > > The initial status of all patches. > The patch is under consideration, but has not been reviewed yet. > The status will normally change to Accepted or Rejected next. > The person submitting the patch should (if they can) assign it to > the person they most want to review it. > Else the patch will be assigned via [xxx a list of expertise areas > should be developed] [xxx but since this hasn't happened and > volunteers are too few, random assignment is better than nothing: > if you're a Python developer, expect to get assigned out of the > blue!] > Discussion of major patches is carried out on the Python-Dev > mailing list. For simple patches, the SourceForge comment > mechanism should be sufficient. [xxx an email gateway would be > great, ditto Ping's Roundup] > > Accepted > > The powers that be accepted the patch, but it hasn't been applied > yet. [xxx flesh out -- Guido Bottleneck avoidable here?] > The status will normally change to Closed next. > The person changing the status to Accepted should, at the same > time, assign the patch to whoever they believe is most likely to be > able & willing to apply it (the submitter if possible). > > Closed > > The patch has been accepted and applied. > The previous status was Accepted, or possibly Open if the submitter > was Guido (or moral equivalent in some particular area of > expertise). > > Rejected > > The patch has been reviewed and rejected. > When the objections are addressed, the status may change to Open > again. > The person changing the status to Rejected should assign the patch > back to the submitter, or if it's clear the patch will never be > accepted, assign it to None. > Note that SourceForge allows the submitter to overwrite the patch > with a new version. > > Out of date > > Previous status was Open or Accepted or Postponed, but the patch no > longer works. > Please enter a comment when changing the status to "Out of date", > to record the nature of the problem and the previous status. > Also assign it back to the submitter, as they need to upload a new > version (note that SourceForge will not allow anyone other than the > original submitter to update the patch). > > Postponed > > The previous status was Open or Accepted, but for some reason > (e.g., pending release) the patch should not be reviewed or applied > until further notice. > The status will normally change to Open or Accepted next. > Please enter a comment when changing the status to Postponed, to > record the reason, the previous status, and the conditions under > which the patch should revert to Open or Accepted. Also assign the > patch to whoever is most likely able and willing to decide when the > status should change again. > > Deleted > > Bit bucket. > Use only if it's OK for the patch and its SourceForge history to > disappear. > As of 09-July-2000, SF does not actually throw away Deleted > patches, but that may change. > > A.2.: Python Patch Submission Guidelines > > New: CNRI is no longer involved in Python patches. We no longer > request legal disclaimers. Also, We're now using the SourceForge Patch > Manager (a single mailing list became unmanageable). > > Many people contribute patches to Python. We've set up a new system to > deal with these. Here are the main guidelines: > * Submit your patch to the [27]patch manager interface at > [28]SourceForge. We strongly recommend that you [29]register with > SourceForge before submitting a patch. If you send patches > directly to Guido you introduce an extra delay. Ditto for the > "patches at python.org" mailing list address; this address should no > longer be used for patch submission. The patch manager is for > patches only; if you have a problem or suggestion but don't know > how to write the code for it, use the [30]Python Bugs List > instead. The bugs list is searchable; if you have a problem and > you're not sure if it has been reported or fixed already, this is > the first place to look. (There used to be a separate TODO list; > we now prefer that you use the bugs list for suggestions and > requests too.) > > > Submit documentation patches the same way. When adding the patch, > be sure to set the "Category" field to "documentation". For > documentation errors without patches, please use the [31]Python > Bugs List instead. > * We like context diffs. We grudgingly accept unified diffs. > Straight ("ed-style") diffs are right out! If you don't know how > to generate context diffs, you're probably not qualified to > produce high-quality patches anyway <0.5 wink>. > * We appreciate it if you send patches relative to the [32]current > CVS tree. These are our latest sources. It's almost a year since > Python 1.5.2 was released, and many source files have been touched > in more or less significant ways; a patch relative to Python 1.5.2 > can cause a lot of extra pain to apply right. Even a patch > relative to the latest alpha or beta release may be way out of > date. > * Please add a succinct message to your SourceForge entry that > explains what the patch is about that we can use directly as a > checkin message. Ideally, such a message explains the problem and > describes the fix in a few lines. > * For patches that add or change functionality: please also update > the documentation and the testcases (the Lib/test subdirectory). > For new modules, we appreciate a new test module (typically > test/test_spam.py). In this case, there's no need to mail the > documentation to a different address (in fact, in order to verify > that the bundle is complete, it's easier to mail everything > together). > * There are a variety of additional [33]style requirements. Please > have a look at these before writing new code. Also have a look at > the general [34]Python Style Guide. > > References > > 1. file://localhost/tmp/sf-faq.html#general > 2. file://localhost/tmp/sf-faq.html#g1 > 3. file://localhost/tmp/sf-faq.html#g2 > 4. file://localhost/tmp/sf-faq.html#cvs > 5. file://localhost/tmp/sf-faq.html#c1 > 6. file://localhost/tmp/sf-faq.html#c2 > 7. file://localhost/tmp/sf-faq.html#c3 > 8. file://localhost/tmp/sf-faq.html#c4 > 9. file://localhost/tmp/sf-faq.html#patches > 10. file://localhost/tmp/sf-faq.html#p1 > 11. file://localhost/tmp/sf-faq.html#p2 > 12. file://localhost/tmp/sf-faq.html#p3 > 13. file://localhost/tmp/sf-faq.html#appendix > 14. file://localhost/tmp/sf-faq.html#a1 > 15. file://localhost/tmp/sf-faq.html#a2 > 16. http://sourceforge.net/ > 17. http://opensource.org/ > 18. http://sourceforge.net/ > 19. http://sourceforge.net/projects/python > 20. http://sourceforge.net/projects/python > 21. http://sfdocs.sourceforge.net/sfdocs > 22. http://cvsbook.red-bean.com/cvsbook.html#Introduction > 23. http://www.python.org/patches > 24. http://www.python.org/patches > 25. file://localhost/tmp/sf-faq.html#a2 > 26. file://localhost/tmp/sf-faq.html#a1 > 27. http://sourceforge.net/patch/?group_id=5470 > 28. http://sourceforge.net/project/?group_id=5470 > 29. http://sourceforge.net/account/register.php > 30. http://www.python.org/search/search_bugs.html > 31. http://www.python.org/search/search_bugs.html > 32. http://sourceforge.net/cvs/?group_id=5470 > 33. http://www.python.org/patches/style.html > 34. http://www.python.org/doc/essays/styleguide.html -- Greg Stein, http://www.lyra.org/ From jeremy at beopen.com Fri Jul 14 02:59:40 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 20:59:40 -0400 (EDT) Subject: [Python-Dev] Pythonb at SourceForge FAQ In-Reply-To: <396E7D29.7AC68EA6@schneider-kamp.de> References: <396E7D29.7AC68EA6@schneider-kamp.de> Message-ID: <14702.26108.53369.420712@bitdiddle.concentric.net> You could check it into the Python distribution under Misc. I can arrange for it to be displayed at pythonlabs.com. Jeremy From peter at schneider-kamp.de Fri Jul 14 05:26:04 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 14 Jul 2000 03:26:04 +0000 Subject: http://python.sourceforge.net (was: Re: [Python-Dev] Pythonb at SourceForge FAQ) References: <396E7D29.7AC68EA6@schneider-kamp.de> <20000713174554.R29590@lyra.org> Message-ID: <396E884C.B55E4737@schneider-kamp.de> Hi Greg! I made a small link page (to python.org, sourceforge.net/projects/python and sf-faq.html) and loaded it up together with the faq (sf-faq.html). Anyone with a bit more feeling for design than me should feel free to improve it. Peter Greg Stein wrote: > > Since we don't have ready access to python.org, I would suggest turning on > the Python web pages at SF and placing it there. > > (of course, with obvious links from python.sourceforge.net to python.org) > > Having a FAQ about Python/SF at SF makes sense to me :-) > > Cheers, > -g -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From huaiyu_zhu at yahoo.com Fri Jul 14 03:30:02 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Thu, 13 Jul 2000 18:30:02 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] Message-ID: Paul Prescod wrote: > I think that the idea is that you could install new syntaxes in the same > way you install new modules...of course only after careful > consideration!!! This is much more than I has bargained for. Separting syntax with sematics is really the way to go. > I'm not entirely against your proposal but you've got to expect major > pushback on such large-scale syntax and semantic changes. Well, I was only asking for some additional operators, which wouldn't affect a single line of existing code. Everyone says no you can't get it, that's too much, but on the other hand you should get a parser to change the syntax anyway you want. So if I ask more I shall get the bit I wanted. When would this wonderful new parser be available so that I can change the syntax beyond recognition? :-) > > Look it this way. Text processing do have their special syntaxes. > > Okay, but probably 90% of Python programmers do text processing at some > point. Not so for matrix calculation. You believe that the Python world > would grow greatly if we did matrices natively. I don't know if I > believe that. I don't believe python should be bond to this heritage as much as perl does. Maybe those who do matrix have not joined yet. To justify support by the number of existing users sounds like a self-fulfilling prophacy. Think about how many users would do text precessing if they have to write regular expressions as layers of composite functions? How many would use arithmetic if they have to write add(mul(1,2),div(2.,3.))? Now compare what's written in matlab/octave (X'*X)\(X'*y) with what's written in python matrixmultiply(inverse(matrixmultiply(transpose(X), X)), (matrixmultiply(transpose(X), y[:,NewAxis]))) Now look at the total number of users of matlab/octave, and ask: Is python really so inferior that most of them wouldn't switch to python? To change this status does not even need native support of matrix. The only thing required is that there be enough binary operators to be overridden by applications - any application that needs additional binary operators. > > PS. I suppose I am allowed to post to python-dev without invitation, but > > not subscribing to it? I find this rather strange. > > Yes, it is rather strange. But I can see its use now. I have to get your reply from web and cut and paste in order to reply again. :-( Huaiyu From peter at schneider-kamp.de Fri Jul 14 05:29:59 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 14 Jul 2000 03:29:59 +0000 Subject: [Python-Dev] Pythonb at SourceForge FAQ References: <396E7D29.7AC68EA6@schneider-kamp.de> <14702.26108.53369.420712@bitdiddle.concentric.net> Message-ID: <396E8937.6FA299D2@schneider-kamp.de> Jeremy Hylton wrote: > > You could check it into the Python distribution under Misc. I can > arrange for it to be displayed at pythonlabs.com. Been there, done that. Following Greg's advice I put it up on http://python.sourceforge.net. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul at prescod.net Fri Jul 14 00:44:29 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 17:44:29 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> <14702.19480.746784.235766@bitdiddle.concentric.net> <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> Message-ID: <396E464D.F6D841ED@prescod.net> "Fred L. Drake, Jr." wrote: > > ... > > The copyright and license are both required to ensure permission to > use, distribute, etc. There are a few "open content" licenses, and a > reference to one of those should be sufficient. I don't know which > one to recommend, however; that would require spending a little time > reading them. Let me recommend my favorite: "Placed in the public domain." -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 00:48:38 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 17:48:38 -0500 Subject: [Python-Dev] [PEP204] Range Literals References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> Message-ID: <396E4746.DE25EFD4@prescod.net> Guido van Rossum wrote: > > ... > It should be sweet and simple. Make it return a list, just like > range(). The whole point is that an optimizer can recognize that you > are doing "for i in [0:10]: ...", and use a generator anyway -- but > that's a thing for later to implement. > > Also, don't bother with (::) to return an xrange as has been proposed. If Guido has decided that the design that has already been implemented is the right one, what's the point of the PEP? Someone just needs to review the patch and check it in! -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 00:48:39 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 17:48:39 -0500 Subject: [Python-Dev] [PEP204] Range Literals References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> Message-ID: <396E4747.9D055A96@prescod.net> Guido van Rossum wrote: > > .. > > It should be sweet and simple. Make it return a list, just like > range(). The whole point is that an optimizer can recognize that you > are doing "for i in [0:10]: ...", and use a generator anyway -- but > that's a thing for later to implement. Why disallow this: fives=[0:maxint:5] As Fred points out, we've already got the underlying object implementation in the src! MAL also pointed out that immutable objects (like xranges) can be safely precomputed and reused. Finally, whatever the answer is, it should probably be the same as list comprehensions. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 00:49:12 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 17:49:12 -0500 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <396E4768.A77473AA@prescod.net> Huaiyu Zhu wrote: > > ... > > So if I ask more I shall get the bit I wanted. When would this wonderful > new parser be available so that I can change the syntax beyond recognition? > :-) It all depends on who works on it and how hard they work. I really can't predict. There some Python features that I thought were years away and appeared from nowhere (cyclic gc) and others that seem perpetually on the verge of being available (e.g. a compiler that achieves order of magnitude performance improvements). If I had to pick a version number out of the wind I would say 2.1 or 2.2. I would predict the same timeline for any new operators. By the way, there is already a language specifically designed to allow people with particular interests to extend the syntax fairly arbitrarily. It is called REBOL. I think TCL is also a little more forgiving about syntactic variance. There may be others. > I don't believe python should be bond to this heritage as much as perl does. > Maybe those who do matrix have not joined yet. To justify support by the > number of existing users sounds like a self-fulfilling prophacy. It isn't the existing users. It's the users that we see around us. I don't remember anyone ever asking me for help using Python for matrices, at any company I have ever worked at. Obviously you live in a different world. Either of our perceptions could be skewed. Perhaps the best bet would be for you to make a matrix variant of Python so popular that we could see the audience in terms of downloads and discussions. > Now compare what's written in matlab/octave > > (X'*X)\(X'*y) > > with what's written in python > > matrixmultiply(inverse(matrixmultiply(transpose(X), X)), > (matrixmultiply(transpose(X), y[:,NewAxis]))) There must be a more compact syntax! Even without knowing the semantics: from matrix import tickmult, backslash backslash( tickmult( X, X ), tickmult( X, y )) > Now look at the total number of users of matlab/octave, and ask: Is python > really so inferior that most of them wouldn't switch to python? I have no idea. If the primary difference between expensive matrix packages and Python is syntax, perhaps you and I should incorporate and exploit that market inefficiency. :) > To change this status does not even need native support of matrix. The only > thing required is that there be enough binary operators to be overridden by > applications - any application that needs additional binary operators. Michael Hudson has a tagline that made me laugh out loud: I saw `cout' being shifted "Hello world" times to the left and stopped right there. -- Steve Gonedes He's talking about the random-seeming overloadings you get in C++ because there are so many overloadable operators and they are so poorly defined. Anyhow, what if I want a different syntax for the XML operators. "->" and "<-" might be useful. I am half-tempted to suggest a system where anyone could add new operators, perhaps in quotes or back-ticks or something but I am very afraid of what happens when the people who evented "cout shifting" get their hands on it! > But I can see its use now. I have to get your reply from web and cut and > paste in order to reply again. :-( How long until some enterprising Python programmer makes a utility that polls the website, and generates an email version of each message as it appears? :) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From jeremy at beopen.com Fri Jul 14 04:28:10 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 22:28:10 -0400 (EDT) Subject: [Python-Dev] urllib vs. cgi Message-ID: <14702.31418.483935.810948@bitdiddle.concentric.net> I was doing a little Web programming this evening and discovered an annoying asymmetry. The urllib module has a urlencode function that translates a dictionary of form entries into a URL query string. I wanted the inverse "urldecode" that turns the query string into the dictionary. There isn't one. But I guessed that CGI programmers had to have a function to do this! It seems there is one called cgi.parse_qs. This wasn't an obvious place to look, because I wasn't doing CGI programming at all. (I was writing a screen-scraped for SourceForge.) Any opinions on adding a symmetrical urldecode to urllib? I'm not thrilled by duplicating code, but the cgi module is big and hairy and urllib seems like the obvious place for it. Jeremy From esr at thyrsus.com Fri Jul 14 04:44:10 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 22:44:10 -0400 Subject: [Python-Dev] urllib vs. cgi In-Reply-To: <14702.31418.483935.810948@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 10:28:10PM -0400 References: <14702.31418.483935.810948@bitdiddle.concentric.net> Message-ID: <20000713224410.A7548@thyrsus.com> Jeremy Hylton : > Any opinions on adding a symmetrical urldecode to urllib? I'm not > thrilled by duplicating code, but the cgi module is big and hairy and > urllib seems like the obvious place for it. +0. It doesn't thrill me, but I can't argue with your analysis either. -- Eric S. Raymond The two pillars of `political correctness' are, a) willful ignorance, and b) a steadfast refusal to face the truth -- George MacDonald Fraser From esr at snark.thyrsus.com Fri Jul 14 04:46:37 2000 From: esr at snark.thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 22:46:37 -0400 Subject: [Python-Dev] ConfigParser changes Message-ID: <200007140246.WAA07574@snark.thyrsus.com> I've seen a couple plus responses to my proposed ConfigParser enhancements, no minuses, and the thread has petered out. If nobody hands me a -1, I'm going to merge them in in a day or so. Speak now... -- Eric S. Raymond "The state calls its own violence `law', but that of the individual `crime'" -- Max Stirner From bwarsaw at beopen.com Fri Jul 14 05:57:09 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 23:57:09 -0400 (EDT) Subject: [Python-Dev] Re: extra packages (was: zlib not compiled by default) References: <20000713153251.A29590@lyra.org> Message-ID: <14702.36757.14686.842685@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> Question to PythonLabs team: should I PEP this, or is this MZ> considered non-PEPable? I think it /is/ worth a PEP and have assigned #206 to you Moshe. -Barry From bwarsaw at beopen.com Fri Jul 14 05:59:38 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 23:59:38 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: <14702.36906.418249.461209@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I'm currently drawing a list for extensions to include: | -- zlib For sure. | -- Tcl/Tk I've always wanted it in every Python distribution I build, and this one in particular is a pain to add. | -- expat | -- PIL | -- Anything else? readline. My fear is that these extension modules might end up like pcre though. We start with the standard stuff and then start to slowly fork it as we find we need extras. Then we're stuck maintaining our version separately and folding in patches as the original moves forward. Yuck. Does distutils come to the rescue here? Am I being overly paranoid? -Barry From moshez at math.huji.ac.il Fri Jul 14 06:05:05 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 07:05:05 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14702.36906.418249.461209@anthem.concentric.net> Message-ID: On Thu, 13 Jul 2000, Barry A. Warsaw wrote: [about libraries to distribute with Python] > | -- Anything else? > > readline. -1 on that. I just thought of that before I got out of bed, and decided putting something GPLed there might be trouble. > My fear is that these extension modules might end up like pcre > though. We start with the standard stuff and then start to slowly > fork it as we find we need extras. Then we're stuck maintaining our > version separately and folding in patches as the original moves > forward. Yuck. Well, we managed writing Tcl/Tk wrappers without changing Tcl/Tk. Why should it be different if it's in the source distribution? The temptation? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From bwarsaw at beopen.com Fri Jul 14 06:06:43 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 14 Jul 2000 00:06:43 -0400 (EDT) Subject: [Python-Dev] [PEP204] Range Literals References: <20000713235356.X7340@xs4all.nl> Message-ID: <14702.37331.302346.67441@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> As I already wrote Barry, I'll do this one -- but only if it's TW> a no-brainer. The patch is already written and I hadn't heard TW> complaints about the syntax, but now I hear some rumbling TW> about how it should be a generator instead of a list TW> constructor. I don't feel like digging into that particular TW> dungball, though, having no experience what so ever with TW> iterators, generators or languages that implement those. (So TW> I'm a C and Python programmar by heart. Sue me.) TW> That isn't to say I think it's a bad idea, not at all. I just TW> don't want to do it :-) But if anyone else wants to implement TW> it, and do so before 2.0, yell now, and you can take over the TW> entire range-literal thing as well. Thomas, it would be wonderful if you could write up what you already know about range literals. Feel free to sprinkle `TBD's (to be done, or to be decided) in places you're uncomfortable about. We'll worry about filling those in or re-assigning later. -Barry P.S. I'd rather use TBD than XXX as is the Dutch convention. The USA is much more prudish than the Europeans, and I'd hate for our PEPs to get blocked from all those Python 8 year olds accessing our documents from the public libraries. :) From bwarsaw at beopen.com Fri Jul 14 06:09:48 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 14 Jul 2000 00:09:48 -0400 (EDT) Subject: [Python-Dev] [PEP204] Range Literals References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> <396E4747.9D055A96@prescod.net> Message-ID: <14702.37516.832386.689911@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Why disallow this: PP> fives=[0:maxint:5] PP> As Fred points out, we've already got the underlying object PP> implementation in the src! PP> MAL also pointed out that immutable objects (like xranges) can PP> be safely precomputed and reused. PP> Finally, whatever the answer is, it should probably be the PP> same as list comprehensions. This is why you want a PEP, Paul! -Barry From bwarsaw at beopen.com Fri Jul 14 06:37:27 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 14 Jul 2000 00:37:27 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <14702.36906.418249.461209@anthem.concentric.net> Message-ID: <14702.39175.2260.890343@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> -1 on that. I just thought of that before I got out of bed, MZ> and decided putting something GPLed there might be trouble. Ah, good point. I keep forgetting about that :) -Barry From paul at prescod.net Fri Jul 14 06:06:52 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 23:06:52 -0500 Subject: [Python-Dev] Request for Opinions Message-ID: <396E91DC.D767EF6F@prescod.net> I don't want to PEP this, I want to discuss it. In fact, I think we are supposed to discuss it four more times before I PEP it. And Tim has to participate in each discussion, right? There is a language called "XPath" for navigating XML trees. It makes your life a lot easier. XPath is to XML trees as SQL is to relational databases. Imagine working with relational databases by looping over records with no query language! I think that some portion of XPath should go into Python 2. 4Thought has a large, sophisticated implementation of the entire XPath language. They use Bison (not PyBison!) and FLEX for parsing performance. I guess there is about 2000 lines of C/yacc. The resulting binary is XXX. There is also about 2000 lines of Python code. On the one hand, this strikes me as a lot of code for one subpackage (xpath) of a package (xml). On the other hand, XPath is pretty stable so once the code is done, it is pretty stable and also self contained. It wasn't something we invented and will be tweaking forever. Rather it is a simple API to something relatively static. (XPath has extension mechanisms so it can solve new problems without growing syntactically) Is this an appropriate extension to Python, like pyexpat? We have three options: 1. use the relatively large 4XPath as is 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) that can be implemented in a couple of hundred lines of Python code (this code is mostly done already, in a module called TinyXPath) 3. try to scale 4XPath back by moving its parser to SRE, and making some of its features "options" that can be added separately (not clear how easy this is) What do you think? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov at inrialpes.fr Fri Jul 14 06:47:43 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 14 Jul 2000 06:47:43 +0200 (CEST) Subject: [Python-Dev] test_extcall Message-ID: <200007140447.GAA28593@python.inrialpes.fr> test_extcall.py contains the following code generating a cycle that cannot be broken explicitely: ... # what about willful misconduct? def saboteur(**kw): kw['x'] = locals() <-- yields cyclic kw: {'x': {'kw': {...}}, 'a': 1} d = {} saboteur(a=1, **d) ... Whoever wrote this test: is locals() absolutely necessary? Also, is there a good reason for not implementing GC for module objects? They are containers after all... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Fri Jul 14 07:16:32 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 14 Jul 2000 07:16:32 +0200 (CEST) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396E91DC.D767EF6F@prescod.net> from "Paul Prescod" at Jul 13, 2000 11:06:52 PM Message-ID: <200007140516.HAA28633@python.inrialpes.fr> Paul Prescod wrote: > > We have three options: > > 1. use the relatively large 4XPath as is > > 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) > that can be implemented in a couple of hundred lines of Python code > (this code is mostly done already, in a module called TinyXPath) > > 3. try to scale 4XPath back by moving its parser to SRE, and making > some of its features "options" that can be added separately (not clear > how easy this is) > > What do you think? Well, I think that the code you're talking about fits best the 4Suite and, for the moment, as a user I would download and install the whole suite from FourThought. You're talking about XPath, but there are also XLink, XPointer, XML Base and other incoming X'es. What's the motivation behind decoupling 4XPath from the 4Suite and making a second (eventually smaller) version of it for the Python lib? I don't really see the point (note: I haven't followed the XML-SIG lately). I'd like to see this discussion focusing on more ambitious goals, like including and providing support for a complete, rich and up to date XML package, which is what the 4Suite basically is. I'm not sure we're ready to discuss this right now, though, so I'd suggest to PEP it anyway. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Mark.Favas at per.dem.csiro.au Fri Jul 14 07:18:42 2000 From: Mark.Favas at per.dem.csiro.au (Favas, Mark (EM, Floreat)) Date: Fri, 14 Jul 2000 13:18:42 +0800 Subject: [Python-Dev] FW: Unicode character name hashing Message-ID: Forgot to copy Python-Dev... -----Original Message----- From: Mark Favas [mailto:m.favas at per.dem.csiro.au] Sent: Friday, 14 July 2000 7:00 AM To: Bill Tutt Subject: Re: Unicode character name hashing Just tried it, and got the same message: test_ucn test test_ucn crashed -- exceptions.UnicodeError : Unicode-Escape decoding error: Invalid Unicode Character Name Cheers, Mark Bill Tutt wrote: > > Does this patch happen to fix it? > I'm afraid my skills relating to signed overflow is a bit rusty... :( > > Bill > > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/ucnhash.c,v > retrieving revision 1.2 > diff -u -r1.2 ucnhash.c > --- ucnhash.c 2000/06/29 00:06:39 1.2 > +++ ucnhash.c 2000/07/13 21:41:07 > @@ -30,12 +30,12 @@ > > len = cch; > p = (unsigned char *) key; > - x = 1694245428; > + x = (long)0x64fc2234; > while (--len >= 0) > - x = (1000003*x) ^ toupper(*(p++)); > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); > x ^= cch + 10; > - if (x == -1) > - x = -2; > + if (x == (long)0xFFFFFFFF) > + x = (long)0xfffffffe; > x %= k_cHashElements; > /* ensure the returned value is positive so we mimic Python's % > operator */ > if (x < 0) > @@ -52,12 +52,12 @@ > > len = cch; > p = (unsigned char *) key; > - x = -1917331657; > + x = (long)0x8db7d737; > while (--len >= 0) > - x = (1000003*x) ^ toupper(*(p++)); > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); > x ^= cch + 10; > - if (x == -1) > - x = -2; > + if (x == (long)0xFFFFFFFF) > + x = (long)0xfffffffe; > x %= k_cHashElements; > /* ensure the returned value is positive so we mimic Python's % > operator */ > if (x < 0) > > -----Original Message----- > From: Mark Favas [mailto:m.favas at per.dem.csiro.au] > Sent: Thursday, July 13, 2000 1:16 PM > To: python-dev at python.org; Bill Tutt > Subject: Unicode character name hashing > > [Bill has epiphany] > >I just had a rather unhappy epiphany this morning. > >F1, and f2 in ucnhash.c might not work on machines where sizeof(long) >!= > 32 bits. > > I get the following from test_ucn on an Alpha running Tru64 Unix: > > python Lib/test/test_ucn.py > UnicodeError: Unicode-Escape decoding error: Invalid Unicode Character > Name > > This is with the current CVS - and it's been failing this test for some > time now. I'm happy to test any fixes... > > -- > Email - m.favas at per.dem.csiro.au Mark C Favas > Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining > Fax - +61 8 9383 9891 Private Bag No 5, Wembley > WGS84 - 31.95 S, 115.80 E Western Australia 6913 -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From huaiyu_zhu at yahoo.com Fri Jul 14 07:53:38 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Thu, 13 Jul 2000 22:53:38 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <396E4768.A77473AA@prescod.net> Message-ID: On Thu, 13 Jul 2000, Paul Prescod wrote: > It all depends on who works on it and how hard they work. I really can't So can some one answer this question for sure: Is it definitely possible to introduce .* ./ etc without much more difficulty than introducing @* and @/ and so on? If this is the case we do not need a new symbol. > Perhaps the best bet would be for you to make a matrix variant of Python > so popular that we could see the audience in terms of downloads and > discussions. That's exact what I'm doing. By far the largest hurdle to MatPy was the lack of binary operators. 2/3 of user discussions is on the the most economic usage of existing symbols. 1/3 of discussion is on how to make it work on Windows, because of relative imports and case insensitivity. To attract users I really need to let octave users know its existence, but this would be futile before we get symbols for both matrix and element operations. Here are a few indications of user support. Some Windows users have enthusiastically followed it for more than a month despite having to rename several files and change module names for each release. It was only fixed last weekend. I'd regard this as a testament of its usefulness and potential. People have also hacked the python parser and the interactive interpreter to support additional features. Some have also promised to supply additional C implementations of numerical procedures. All I had promised for this was to make an easy interface for matrix computation that works with Python, for my own use. Right now the only remaining hurdle to this goal is the lack of suitable symbols, and we are on the verge of overcoming it. > There must be a more compact syntax! Even without knowing the semantics: > > from matrix import tickmult, backslash > backslash( tickmult( X, X ), tickmult( X, y )) You are almost there. :-) The current MatPy expression is solve (X.H() * X, X.H() * y) > > Now look at the total number of users of matlab/octave, and ask: Is python > > really so inferior that most of them wouldn't switch to python? > > I have no idea. If the primary difference between expensive matrix > packages and Python is syntax, perhaps you and I should incorporate and > exploit that market inefficiency. :) The market is efficient. Matlab does worth that much (or even more). It does take that much human labor to get to that stage, so sadly we can't get rich by following them. On the other hand, open source may beat them easily, as long as 1. we are using a better language which has more potential 2. users have incentive to contribute because it's already useful 3. there's no big hurdle beyond what's already in Numerical Recipe I'm sure I can recruit enough developers to solve any numerical problem, as long as you don't ask them to hack the python parser! That's what I ask the python developers for. > Michael Hudson has a tagline that made me laugh out loud: > > I saw `cout' being shifted "Hello world" times to the left and > stopped right there. > -- Steve Gonedes If this was a notation used in a century's worth of mathemetical papers, it might not seem that strange. Could C++ stream IO ever make into just one mainstream math paper? > How long until some enterprising Python programmer makes a utility that > polls the website, and generates an email version of each message as it > appears? :) The same length of time that takes an enterprising Python programmer to find the principal axes of a set of data using eigen decomposition. :-) think-domain-specific-ly y'rs Huaiyu From tim_one at email.msn.com Fri Jul 14 08:15:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 14 Jul 2000 02:15:27 -0400 Subject: [Python-Dev] Windows build broken in exceptions.c In-Reply-To: <00c401bfebd9$e6d347e0$f2a6b5d4@hagrid> Message-ID: >> exceptions.c(93) : error C2026: string too big, trailing characters >> truncated [Fredrik Lundh Sent: Wednesday, July 12, 2000 4:19 AM] > but back to the original topic: what does the ANSI standard > say about this? A conforming C compiler isn't required to accept string literals longer than 509 characters (and that's *after* concatenating adjacent strings). An excellent summary (although not a rationale) can be found here: http://www-ccs.ucsd.edu/c/portable.html Read it carefully, and my bet is you'll realize you've never seen a portable C program! For example, ever #include a file whose basename was longer than 6 characters or used mixed case? Then you're in the unsupported fast lane . > what is, for example, the limits for integer arrays? There are (small!) limits both on physical source lines and on the size of initialized objects. See the above and *you* try to figure it out . > (my unicode database experiments results in a couple of big > ones. and for best performance, they really have to be that > big...) The std guarantees only the feeblest of compile-time abilities, so you're (the generic "you", i.e. "us") very unlikely to write this stuff in a way the std guarantees will work. But it's not worth worrying about (within reason), until we hit an actual compiler that complains. The only way to be completely sure is to stick to tiny compile-time entities and paste them together at runtime. and-even-then-it's-not-really-sure-ly y'rs - tim From mwh21 at cam.ac.uk Fri Jul 14 08:21:13 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 14 Jul 2000 07:21:13 +0100 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: bwarsaw@beopen.com's message of "Fri, 14 Jul 2000 00:37:27 -0400 (EDT)" References: <14702.36906.418249.461209@anthem.concentric.net> <14702.39175.2260.890343@anthem.concentric.net> Message-ID: bwarsaw at beopen.com (Barry A. Warsaw) writes: > >>>>> "MZ" == Moshe Zadka writes: > > MZ> -1 on that. I just thought of that before I got out of bed, > MZ> and decided putting something GPLed there might be trouble. > > Ah, good point. I keep forgetting about that :) It's been one of those things that "I will get round to sometime" for a long while now to write a (PD) replacement line editor in Python (thinking partly that it would be nice not to be "encumbered" by the GPL and that if it was written in a suitable style it might be possible to make it more "hookable" and provide eg. fancier completion). Unfortunately I know nothing about any of the issues involved, so I'd have to do a lot of reading first... Anyone else think this is a good idea/crazy? Cheers, M. From Mark.Favas at per.dem.csiro.au Fri Jul 14 08:30:13 2000 From: Mark.Favas at per.dem.csiro.au (Favas, Mark (EM, Floreat)) Date: Fri, 14 Jul 2000 14:30:13 +0800 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators for matrix comput ation] Message-ID: Speaking as a research scientist with my computational chemistry/visualization hat down around my ears, I'd certainly welcome such operators, as would a couple of my colleagues to whom I introduced Python. One was a heavy user of Sather until the steam went out of it, then C++ for a time, now Python+NumPy - and loving it! A set of matrix operators would expand Python's sphere of use - scientists process numbers as well as text... From fdrake at beopen.com Fri Jul 14 08:52:28 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 02:52:28 -0400 (EDT) Subject: [Python-Dev] ConfigParser changes In-Reply-To: <200007140246.WAA07574@snark.thyrsus.com> References: <200007140246.WAA07574@snark.thyrsus.com> Message-ID: <14702.47276.262761.585951@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > I've seen a couple plus responses to my proposed ConfigParser > enhancements, no minuses, and the thread has petered out. I don't see the patch on SourceForge, so go ahead and check them in. I think everyone agrees that the basic functionality is useful, and has been requested before. +1 from me. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein at lyra.org Fri Jul 14 09:15:39 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 00:15:39 -0700 Subject: [Python-Dev] Request for Opinions In-Reply-To: <396E91DC.D767EF6F@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 11:06:52PM -0500 References: <396E91DC.D767EF6F@prescod.net> Message-ID: <20000714001539.T29590@lyra.org> On Thu, Jul 13, 2000 at 11:06:52PM -0500, Paul Prescod wrote: >... > We have three options: > > 1. use the relatively large 4XPath as is > > 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) > that can be implemented in a couple of hundred lines of Python code > (this code is mostly done already, in a module called TinyXPath) > > 3. try to scale 4XPath back by moving its parser to SRE, and making > some of its features "options" that can be added separately (not clear > how easy this is) > > What do you think? I think this is for the XML SIG. I don't know why it is here. SIGs discuss and design, then roll up their final decisions. I haven't seen a clear consensus or decision from the XML SIG yet. You've got your TinyXPath module, but (forget who) has another module for much the same thing. There was a discussion of APIs. A discussion of how/where SRE could play into the game. IMO, these are all a bunch of points for the XML SIG, not python-dev. Cheers, -g -- Greg Stein, http://www.lyra.org/ From moshez at math.huji.ac.il Fri Jul 14 09:13:46 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 10:13:46 +0300 (IDT) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396E91DC.D767EF6F@prescod.net> Message-ID: On Thu, 13 Jul 2000, Paul Prescod wrote: > There is a language called "XPath" for navigating XML trees. It makes > your life a lot easier. XPath is to XML trees as SQL is to relational > databases. Imagine working with relational databases by looping over > records with no query language! I think that some portion of XPath > should go into Python 2. I agree -- XPath would be cool to work with. > 4Thought has a large, sophisticated implementation of the entire XPath > language. They use Bison (not PyBison!) and FLEX for parsing > performance. The output of Bison is covered by the GPL, and flex requires a runtime library. We want a rich Python, but there's no reason for a billionaire > 1. use the relatively large 4XPath as is This seems to have a significant cost for the Python distribution > 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) > that can be implemented in a couple of hundred lines of Python code > (this code is mostly done already, in a module called TinyXPath) +0 on that. > 3. try to scale 4XPath back by moving its parser to SRE, and making > some of its features "options" that can be added separately (not clear > how easy this is) If you think someone will do this, this is great. If not, there isn't much point in discussing it, is there? <0.9 wink> -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gstein at lyra.org Fri Jul 14 09:19:37 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 00:19:37 -0700 Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: ; from Mark.Favas@per.dem.csiro.au on Fri, Jul 14, 2000 at 02:30:13PM +0800 References: Message-ID: <20000714001937.U29590@lyra.org> On Fri, Jul 14, 2000 at 02:30:13PM +0800, Favas, Mark (EM, Floreat) wrote: > Speaking as a research scientist with my computational > chemistry/visualization hat down around my ears, I'd certainly welcome such > operators, as would a couple of my colleagues to whom I introduced Python. > One was a heavy user of Sather until the steam went out of it, then C++ for > a time, now Python+NumPy - and loving it! A set of matrix operators would > expand Python's sphere of use - scientists process numbers as well as > text... We can always gain new users by adding domain-specific operators. Take that to the extreme, though, and you'll have a mess of complicated operators that don't create a unified whole, that don't work well across various types, and are hard to understand for the majority of users. What then? Well, you *lose* users. Gain the domain-specific, lose the rest. New users are great. Adding complexity to gain them is counter-productive from a longer term viewpoint. Cheers, -g p.s. and allowing user-programmable syntax? you're truly kidding, right? -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Fri Jul 14 09:27:41 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 00:27:41 -0700 Subject: [Python-Dev] Re: CVS: python/dist/src/Misc sf-faq.html,1.2,1.3 In-Reply-To: <200007140622.XAA32744@slayer.i.sourceforge.net>; from marangoz@users.sourceforge.net on Thu, Jul 13, 2000 at 11:22:57PM -0700 References: <200007140622.XAA32744@slayer.i.sourceforge.net> Message-ID: <20000714002740.V29590@lyra.org> Um. Why did you go and do this? Looking at the original HTML, it appears that Peter was using the Mozilla editor to create the page. With your revamping, will he continue to be able to do that? When he next edits the page, will it just revert back to the original? Did you discuss doing this big change with Peter? We just got done with a discussion about how/where people should feel free to make changes and what kinds of changes. Something drastic like this should have at least been run by the author. Otherwise, it is a bit disrespectful. In this case, it may also break his continued maintenance of it (need to check w/ Peter tho). -g On Thu, Jul 13, 2000 at 11:22:57PM -0700, Vladimir Marangozov wrote: > Update of /cvsroot/python/python/dist/src/Misc > In directory slayer.i.sourceforge.net:/tmp/cvs-serv32383 > > Modified Files: > sf-faq.html > Log Message: > Gosh - clean up that messy HTML; make it valid XHTML instead. > > > Index: sf-faq.html > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Misc/sf-faq.html,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -C2 -r1.2 -r1.3 > *** sf-faq.html 2000/07/14 01:43:31 1.2 > --- sf-faq.html 2000/07/14 06:22:54 1.3 > *************** > *** 1,406 **** > ! > ! > > ! > ! > ... > ! > ! ! "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > ! > > ! Python at SourceForge - Frequently Asked Questions > ! > -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Fri Jul 14 09:36:06 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 14 Jul 2000 09:36:06 +0200 (CEST) Subject: [Python-Dev] Re: http://python.sourceforge.net In-Reply-To: <396E884C.B55E4737@schneider-kamp.de> from "Peter Schneider-Kamp" at Jul 14, 2000 03:26:04 AM Message-ID: <200007140736.JAA29096@python.inrialpes.fr> Peter Schneider-Kamp wrote: > > Hi Greg! > > I made a small link page (to python.org, sourceforge.net/projects/python > and sf-faq.html) and loaded it up together with the faq (sf-faq.html). > > Anyone with a bit more feeling for design than me should feel free to > improve it. Thanks! You'd have to chmod g+w the new files first, though. I can't Mr Proper them. In a moment of great annoyance I'll also try to enhance the pages. BTW, please make a HTML Tidy pass (http://www.w3.org/People/Raggett/tidy/) over the HTML files, at least, if they're edited with your favorite editor. Or you may want to use Amaya for editing HTML (http://www.w3.org/Amaya/) but it still core dumps from time to time . It's improving though... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas at xs4all.net Fri Jul 14 09:44:12 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 09:44:12 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: ; from huaiyu_zhu@yahoo.com on Thu, Jul 13, 2000 at 10:53:38PM -0700 References: <396E4768.A77473AA@prescod.net> Message-ID: <20000714094412.Z7340@xs4all.nl> On Thu, Jul 13, 2000 at 10:53:38PM -0700, Huaiyu Zhu wrote: > On Thu, 13 Jul 2000, Paul Prescod wrote: > > It all depends on who works on it and how hard they work. I really can't > So can some one answer this question for sure: > Is it definitely possible to introduce .* ./ etc without much more > difficulty than introducing @* and @/ and so on? No, I don't think it's possible without significantly restructuring the Grammar. However, Vladimir may prove me wrong, he has before ! :-) The problem is the recursive-descent parser Python is using, I don't think it can see the difference between 2. / 2 and 2 ./ 2 or a. / b and a ./ b Because the dot is already a pretty overloaded character: it does float-creation, rendering the first example ambiguous, and it does attribute-lookup, rendering the second ambiguous. However, I haven't tried it, it might be possible to make it work even with the current parser. > If this is the case we do not need a new symbol. Actually, you do need a new symbol, several in fact. You don't need to introduce a new *character*, but you get several new symbols: ./, .*, etc. I'm not sure if using the dot for this, too, is such a good idea, even if it's possible: yet another possible meaning for '.' ? I think using '@' is preferable. At least non-matrix people will know when to run screaming, when they see that ! :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov at inrialpes.fr Fri Jul 14 09:49:17 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 14 Jul 2000 09:49:17 +0200 (CEST) Subject: [Python-Dev] Re: CVS: python/dist/src/Misc sf-faq.html,1.2,1.3 In-Reply-To: <20000714002740.V29590@lyra.org> from "Greg Stein" at Jul 14, 2000 12:27:41 AM Message-ID: <200007140749.JAA29121@python.inrialpes.fr> Greg Stein wrote: > > Um. Why did you go and do this? Looking at the original HTML, it appears > that Peter was using the Mozilla editor to create the page. With your > revamping, will he continue to be able to do that? When he next edits the > page, will it just revert back to the original? This shouldn't be a problem for Peter. He can revert that with the editor of his choice; if its not conformant to the standards, I'll clean the files occasionally if you don't mind. Sorry for being sensible on this topic, working next to the W3C people and being an INRIA webmaster. I'm just trying to give the example about the culture. Unfortunately, I must reckon that the tools are following slowly, but everybody will jump in sooner or later... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas at xs4all.net Fri Jul 14 09:46:18 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 09:46:18 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <396E4768.A77473AA@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 05:49:12PM -0500 References: <396E4768.A77473AA@prescod.net> Message-ID: <20000714094618.A7340@xs4all.nl> On Thu, Jul 13, 2000 at 05:49:12PM -0500, Paul Prescod wrote: > Huaiyu Zhu wrote: > > But I can see its use now. I have to get your reply from web and cut and > > paste in order to reply again. :-( > How long until some enterprising Python programmer makes a utility that > polls the website, and generates an email version of each message as it > appears? :) You can already download the email version: the archives in mbox format. You'll have to download the entire month of conversation, possibly again and again if you're following a running converstation, and you'll lose the threading information (In-Reply-To: headers) but 'reply' should work fine. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein at lyra.org Fri Jul 14 10:02:20 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 01:02:20 -0700 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <20000714094412.Z7340@xs4all.nl>; from thomas@xs4all.net on Fri, Jul 14, 2000 at 09:44:12AM +0200 References: <396E4768.A77473AA@prescod.net> <20000714094412.Z7340@xs4all.nl> Message-ID: <20000714010220.Y29590@lyra.org> On Fri, Jul 14, 2000 at 09:44:12AM +0200, Thomas Wouters wrote: > On Thu, Jul 13, 2000 at 10:53:38PM -0700, Huaiyu Zhu wrote: > > On Thu, 13 Jul 2000, Paul Prescod wrote: > > > > It all depends on who works on it and how hard they work. I really can't > > > So can some one answer this question for sure: > > > Is it definitely possible to introduce .* ./ etc without much more > > difficulty than introducing @* and @/ and so on? > > No, I don't think it's possible without significantly restructuring the > Grammar. However, Vladimir may prove me wrong, he has before ! :-) The > problem is the recursive-descent parser Python is using, I don't think it > can see the difference between The issue isn't with recursive-descent, and this would be a relatively easy change. You would introduce a new token "./" to accomplish this (call it DOTSLASH). Thus, . / maps to (DOT, SLASH,) while ./ maps to (DOTSLASH,). Python already does this to differentiate between < and <<. Most languages do, actually. What is really weird is that Python sees the ellipsis value/operator/ whatever-the-heck-it-is as three individual DOT tokens rather than a single token. Thus, the following two statements are equal: a[...] a[. . .] Whacky :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Fri Jul 14 10:06:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 14 Jul 2000 04:06:42 -0400 Subject: Copyright & licenses (was RE: [Python-Dev] Python Enhancement Proposals (PEPs)) In-Reply-To: <14702.19369.605446.28207@cj42289-a.reston1.va.home.com> Message-ID: [Greg Stein] > Why must we assert copyrights on these things? Come on, people. Aren't > we seeing Python 2.0 release problems because of copyrights? [Fred L. Drake, Jr.] > No. *Licensing* is distinct from copyright, and that's where we see > problems. The question of who is to be the next copyright holder will become a bone of contention too before this is over, don't you think? What to do with all the current copyright notices is already a point of negotiation (e.g., should CWI really have a notice in files that didn't even exist yet under their tenure? etc. Note that when I added pyport.h to the project, I put in only a BeOpen copyright: *someone* is bound to gripe about that too, provided I ever admit to it in public ). I personally would like to get Python out of the copyright *and* license games forever, by releasing Python to the public domain (as, e.g., Ralph Griswold did with the Icon language from the start -- and enjoyed a hassle-free life ever after; yes, at least one closed-source copyrighted commercial version of Icon did appear, but that was no skin off Prof. Griswold's nose; he kept working on the PD one, and the commercial version eventually gave up -- heck, rather than see their work wasted, they contributed most of what they did back to the PD Icon Project!). I don't believe there's any real downside to PD in America so long as you're not afraid to compete on merit alone. Don't know about international law, though. > The copyrights are indisputable, but are not a problem. Pshaw -- everything's disputable . and-everything's-a-problem-ly y'rs - tim From tim_one at email.msn.com Fri Jul 14 10:06:44 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 14 Jul 2000 04:06:44 -0400 Subject: [Python-Dev] Request for Opinions In-Reply-To: <396E91DC.D767EF6F@prescod.net> Message-ID: [Paul Prescod] > I don't want to PEP this, I want to discuss it. In fact, I think we are > supposed to discuss it four more times before I PEP it. And Tim has to > participate in each discussion, right? No to the latter. I read everything. That's why I never have time to respond anymore <0.5 wink>. Discussions are great! Just be aware that if the discussion doesn't flow directly to a patch that's applied to the distribution, and you're still keen on the idea, without a PEP it will be *worse* for you than if the discussion had never occurred. That's because the people who *did* read the discussion the first time around are exponentially less likely to say anything (or even pay attention!) on each of the next 500 times the topic pops up again. So if this discussion doesn't reach a conclusion you like, PEP it or you may as well forget it forever (well, maybe not that long -- augmented assignments appear to be getting in after a mere 9 years of thrice-yearly strident from-scratch endlessly redundant advocacy ). From fredrik at pythonware.com Fri Jul 14 10:21:46 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 10:21:46 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <010401bfed6c$8d905300$0900a8c0@SPIFF> Huaiyu Zhu wrote: > Look it this way. Text processing do have their special syntaxes. what special syntax? regular expressions are a *sublanguage* in Python. everything else is done through methods and ordinary sequence operators. From peter at schneider-kamp.de Fri Jul 14 12:44:40 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 14 Jul 2000 10:44:40 +0000 Subject: [Python-Dev] Re: http://python.sourceforge.net References: <200007140736.JAA29096@python.inrialpes.fr> Message-ID: <396EEF18.163475CD@schneider-kamp.de> Vladimir Marangozov wrote: > > Thanks! You'd have to chmod g+w the new files first, though. > I can't Mr Proper them. In a moment of great annoyance I'll > also try to enhance the pages. Done that. > BTW, please make a HTML Tidy pass (http://www.w3.org/People/Raggett/tidy/) > over the HTML files, at least, if they're edited with your favorite editor. Ok, I did. Unfortunately before reading the checkins ... > Or you may want to use Amaya for editing HTML (http://www.w3.org/Amaya/) > but it still core dumps from time to time . It's improving though... Is that what you used for sf-faq.html? There is one thing I don't like about all this xml*, meta and other special tags. I used to write .html files with my favorite text editor: my little home page

My Little Home Page

Here goes the content. With XHTML I'll probably end up with something like this: my little home page

My Little Home Page

Here goes the content. Talk about readability and maintainability. I know the header is worst, but the generated sources (from Page Composer, Frontpage, Amaya or your favorite tool) are always a pain in the ass if it comes to reading them. And yes, I am one of those who used to do their html in . compiling-amaya-though-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gstein at lyra.org Fri Jul 14 10:51:17 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 01:51:17 -0700 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <396E0B9B.DD74EF5@interet.com>; from jim@interet.com on Thu, Jul 13, 2000 at 02:34:03PM -0400 References: <396E0B9B.DD74EF5@interet.com> Message-ID: <20000714015117.C29590@lyra.org> On Thu, Jul 13, 2000 at 02:34:03PM -0400, James C. Ahlstrom wrote: > Mark Hammond wrote: >... > I guess I haven't made myself clear. I am not proposing > that we freeze the C interface. I am not proposing that we > scrutinize any *.pyd's for incompatabilities. > > I am proposing that we leave the "python15.dll" name the same. > I am proposing that the various *.pyd authors themselves either > provide newer versions, or declare that their *.pyd needs no > newer version of python15.dll. As a .pyd part-time author, I'm going to punt *every* time and suggest people upgrade. I don't have time or inclination to piss around to figure out whether my PYD is compatible forwards/backwards across revisions. > It is a matter of odds. If we necessarily rename python15.dll > for each version release, Python has a 100% chance of failing > with an obscure error or crashing if it uses any *.pyd at all > unless all *.pyd are replaced with new versions. > > If we do not rename python15.dll, then a *.pyd may or may not > fail. My guess (only a guess) is that many will work OK. This is completely untenable. *) change the python DLL name failure mode: old modules simply won't load, or they'll fail drastically *) don't change the name failure mode: old modules may work, may have *subtle* bugs, or they may fail miserably As a user, I want complete guaranteed success or guaranteed failure. That half-way ground where my application may silently be broken is simply unacceptable. You're free to start creating releases in this way. Personally, I don't want to spend this kind of time and effort, for dubious benefit. I'm also not going to try to impose that upon PYD authors. And yes: this is all just IMO. One more vote in the crowd.. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gregory.lielens at fft.be Fri Jul 14 11:57:37 2000 From: gregory.lielens at fft.be (Gregory Lielens) Date: Fri, 14 Jul 2000 11:57:37 +0200 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators formatrix computation] References: <396DFDC5.6780A710@prescod.net> Message-ID: <396EE411.B3CB33A9@fft.be> Paul Prescod wrote: > > Huaiyu Zhu wrote: > > > > ... > > > > I wonder how orthogonal would this be against the main development? Would > > it require a rebuild for each new release. Would it also require a patch > > each time? > > I think that the idea is that you could install new syntaxes in the same > way you install new modules...of course only after careful > consideration!!! It seems potentially more dangerous than statically adding a new operator, no? If two modules install incompatible changes of syntax, for exmaple if they demand both @ as operator, they will be considered as incompatible? On the other hand, if @ is buil-in, it can be overloaded depending on the type of the operands, which seems safer...I am not sure, but it seems that if syntax is module-dependent, things becomes really complex... > > Look it this way. Text processing do have their special syntaxes. > > Okay, but probably 90% of Python programmers do text processing at some > point. Not so for matrix calculation. You believe that the Python world > would grow greatly if we did matrices natively. I don't know if I > believe that. Well, that kind of change could potentially attract all the numeric community...which is probably a minority (and becoming smaller, based on the evolution of the number of science students in belgium) compared to the rest of the comp world, but still a significant minority. At least, it will attract one person for sure: me :-) Anyway, it seems that that audience (numeric people) was targeted by python since the beginning, because why the hell include complex numbers as built-in type if not? They are of a less general usefullness than matrices, imho, the last can at least be used for graphic stuff... Greg. From ping at lfw.org Fri Jul 14 12:09:10 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Fri, 14 Jul 2000 03:09:10 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: Message-ID: On Thu, 13 Jul 2000, Huaiyu Zhu wrote: > > You are almost there. :-) The current MatPy expression is > solve (X.H() * X, X.H() * y) I was about to suggest something similar, but you beat me to it. I think that expression looks great. If you can say it that concisely, i don't think you need to throw in extra operators at all (let alone a half-dozen of them that are incomprehensible to anyone outside of the Matlab community). I actually believe solve(X.H()*X, X.H()*y) is *clearer* than (X'*X)\(X'*y) (What does the backslash mean? What does the tick mark mean? At least solve() is clear, and if i understood what H() stood for, it would mean more than a tick mark.) -- ?!ng From m.favas at per.dem.csiro.au Fri Jul 14 12:55:44 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Fri, 14 Jul 2000 18:55:44 +0800 Subject: [Python-Dev] Introducing new operators for matrix computation Message-ID: <396EF1B0.8CB53FD3@per.dem.csiro.au> Greg Stein wrote: >New users are great. Adding complexity to gain them is >counter-productive from a longer term viewpoint. > >Cheers, >-g > >p.s. and allowing user-programmable syntax? you're truly kidding, >right? The p.s. is one of the reasons I support putting useful matrix operators into the core - user-programmable syntax will only lead to even more complexity/confusion/fragmentation, and should be resisted strongly... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From effbot at telia.com Fri Jul 14 13:51:43 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 13:51:43 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: Message-ID: <009501bfed89$e415ce40$f2a6b5d4@hagrid> moshe wrote: > > # normal case > > for (x,) in zip([0, 1, 2]): > > ... > > > > # special case > > for x in zip([0, 1, 2]): > > ... > > I'm sorry, I don't buy that. > > # "special case" > for x in [0, 1, 2]: > ... > > # "special case" > do_something_that_requires_a_list_of_tuples(zip(*lists)) we sure have a major disconnect here -- wasn't the source of this discussion the need to be able to loop over multiple sequences in parallel? isn't "for" what you'd usually use when looping over things? From billtut at microsoft.com Fri Jul 14 14:30:35 2000 From: billtut at microsoft.com (Bill Tutt) Date: Fri, 14 Jul 2000 05:30:35 -0700 Subject: [Python-Dev] RE: Unicode character name hashing Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2D5@RED-MSG-50> After making use of the test drive Alphas by Compaq, I just uploaded a patch to SF that should fix this nasty issue. Ugh. Not fun.... If anybody else cares about identical string hash values across 32 v. 64 bit architectures, check out the patch. Bill -----Original Message----- From: Mark Favas [mailto:m.favas at per.dem.csiro.au] Sent: Thursday, July 13, 2000 4:00 PM To: Bill Tutt Subject: Re: Unicode character name hashing Just tried it, and got the same message: test_ucn test test_ucn crashed -- exceptions.UnicodeError : Unicode-Escape decoding error: Invalid Unicode Character Name Cheers, Mark Bill Tutt wrote: > > Does this patch happen to fix it? > I'm afraid my skills relating to signed overflow is a bit rusty... :( > > Bill > > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/ucnhash.c,v > retrieving revision 1.2 > diff -u -r1.2 ucnhash.c > --- ucnhash.c 2000/06/29 00:06:39 1.2 > +++ ucnhash.c 2000/07/13 21:41:07 > @@ -30,12 +30,12 @@ > > len = cch; > p = (unsigned char *) key; > - x = 1694245428; > + x = (long)0x64fc2234; > while (--len >= 0) > - x = (1000003*x) ^ toupper(*(p++)); > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); > x ^= cch + 10; > - if (x == -1) > - x = -2; > + if (x == (long)0xFFFFFFFF) > + x = (long)0xfffffffe; > x %= k_cHashElements; > /* ensure the returned value is positive so we mimic Python's % > operator */ > if (x < 0) > @@ -52,12 +52,12 @@ > > len = cch; > p = (unsigned char *) key; > - x = -1917331657; > + x = (long)0x8db7d737; > while (--len >= 0) > - x = (1000003*x) ^ toupper(*(p++)); > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); > x ^= cch + 10; > - if (x == -1) > - x = -2; > + if (x == (long)0xFFFFFFFF) > + x = (long)0xfffffffe; > x %= k_cHashElements; > /* ensure the returned value is positive so we mimic Python's % > operator */ > if (x < 0) > > -----Original Message----- > From: Mark Favas [mailto:m.favas at per.dem.csiro.au] > Sent: Thursday, July 13, 2000 1:16 PM > To: python-dev at python.org; Bill Tutt > Subject: Unicode character name hashing > > [Bill has epiphany] > >I just had a rather unhappy epiphany this morning. > >F1, and f2 in ucnhash.c might not work on machines where sizeof(long) >!= > 32 bits. > > I get the following from test_ucn on an Alpha running Tru64 Unix: > > python Lib/test/test_ucn.py > UnicodeError: Unicode-Escape decoding error: Invalid Unicode Character > Name > > This is with the current CVS - and it's been failing this test for some > time now. I'm happy to test any fixes... > > -- > Email - m.favas at per.dem.csiro.au Mark C Favas > Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining > Fax - +61 8 9383 9891 Private Bag No 5, Wembley > WGS84 - 31.95 S, 115.80 E Western Australia 6913 -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From paul at prescod.net Fri Jul 14 12:07:43 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:07:43 -0500 Subject: [Python-Dev] Request for Opinions References: <200007140516.HAA28633@python.inrialpes.fr> Message-ID: <396EE66F.59D0D45F@prescod.net> Vladimir Marangozov wrote: > >... > > Well, I think that the code you're talking about fits best the 4Suite > and, for the moment, as a user I would download and install the whole suite > from FourThought. Why? 4XPath is entirely separable and compatible with Python's current XML support. > You're talking about XPath, but there are also XLink, XPointer, XML Base > and other incoming X'es. Sure, there are a million XML-world specs. XPath is the one that makes navigating XML trees easy. We've put an XML tree package (miniDOM) in Python 2.0. Therefore XPath is the one that makes our XML tree package easy to navigate. > ... > I'd like to see this discussion focusing on more ambitious goals, like > including and providing support for a complete, rich and up to date XML > package, which is what the 4Suite basically is. Well, it's not very ambitious to propose projects that are already pretty much done! 4Suite is great and its mostly done. Now we're talking about making *Python* more complete. > I'm not sure we're ready > to discuss this right now, though, so I'd suggest to PEP it anyway. Why aren't we ready to dicuss it? -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 12:08:51 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:08:51 -0500 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> Message-ID: <396EE6B3.B86BED76@prescod.net> Greg Stein wrote: > > ... > > I think this is for the XML SIG. I don't know why it is here. SIGs discuss > and design, then roll up their final decisions. Okay, so we can agree in the XML SIG that we love XPath and then "check in" 4K of Bison/FLEX/C/Python code without consulting anyone else? I don't see any harm in consulting PythonDev....it's not like every string decision is entirely settled in string-sig and every internationalization feature in il8n-sig. There are also integration issues. Adopting a large package is one such. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From guido at beopen.com Fri Jul 14 16:07:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:07:29 -0500 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: Your message of "Fri, 14 Jul 2000 00:06:43 -0400." <14702.37331.302346.67441@anthem.concentric.net> References: <20000713235356.X7340@xs4all.nl> <14702.37331.302346.67441@anthem.concentric.net> Message-ID: <200007141407.JAA12817@cj20424-a.reston1.va.home.com> > P.S. I'd rather use TBD than XXX as is the Dutch convention. The USA > is much more prudish than the Europeans, and I'd hate for our PEPs to > get blocked from all those Python 8 year olds accessing our documents > from the public libraries. :) XXX is not a Dutch invention -- I picked up the habit from the X11 source code base. I believe it's fairly common in open source projects, and there are so many XXX'es throughout Python already that it's better not to try and change. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Fri Jul 14 16:13:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:13:29 -0500 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: Your message of "Fri, 14 Jul 2000 00:37:27 -0400." <14702.39175.2260.890343@anthem.concentric.net> References: <14702.36906.418249.461209@anthem.concentric.net> <14702.39175.2260.890343@anthem.concentric.net> Message-ID: <200007141413.JAA12883@cj20424-a.reston1.va.home.com> I just want to make it crystal clear that I'm *against* (that's a -999, only overridable by a bus) inclusion of 3rd party library source code in the Python source distribution. Exceptions can only be made if the particular 3rd party code needs to be modified before it is usable from Python (e.g. some checksum algorithms, and PCRE) or if there is no reasonably accessible distribution available on the web. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Fri Jul 14 16:17:53 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:17:53 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: Your message of "Thu, 13 Jul 2000 19:11:27 -0400." <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> <14702.19480.746784.235766@bitdiddle.concentric.net> <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> Message-ID: <200007141417.JAA12935@cj20424-a.reston1.va.home.com> > > My only concern is that without some explicit expression of rights, > > some party might try to prevent us from distributing a PEP. According to a discussion I just had with Tim about a different issue, putting it in the public domain is just as good a safeguard against this particular problem. But we have an additional requirement here: we want to prevent others from distributing mutilated versions of our standard documents. I believe some form of open copyright is the best protection against that. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul at prescod.net Fri Jul 14 12:10:56 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:10:56 -0500 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators formatrix computation] References: <396DFDC5.6780A710@prescod.net> <396EE411.B3CB33A9@fft.be> Message-ID: <396EE730.6183423F@prescod.net> Gregory Lielens wrote: > > ... > > It seems potentially more dangerous than statically adding a new > operator, no? If two modules > install incompatible changes of syntax, for exmaple if they demand both > @ as operator, they will be considered as incompatible? I think that the idea is that one module would be in the Matrix sublanguage and another would be in an XML sublanguage. That way your context shifts are clear. Presumably the first or second line of the file says what sublanguage you are using. > Anyway, it seems that that audience (numeric people) was targeted by > python since the beginning, because why the hell include complex numbers > as built-in type if not? They are of a less general usefullness than > matrices, imho, the last can at least be used for graphic stuff... Okay, but look at the syntactic support complex numbers needed. Just "j". The same for string processing. We just reused most of the existing operators. If you guys made a really kick-ass matrix package that everyone loved and didn't need any new syntax, Guido might be tempted to make matrices a built-in type also! The funny thing is that most of the Python syntax that I don't use today is ALREADY for matrix operations: foo[x,y:a,b] foo()[...] -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 12:11:45 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:11:45 -0500 Subject: [Python-Dev] Re: http://python.sourceforge.net References: <200007140736.JAA29096@python.inrialpes.fr> <396EEF18.163475CD@schneider-kamp.de> Message-ID: <396EE761.9ADE5325@prescod.net> Peter Schneider-Kamp wrote: > >... > > With XHTML I'll probably end up with something like this: I don't know what you mean by probably, but about half of the stuff in your document is optional. Here's a fairly minimal XHTML representation: > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > > > my little home page > > >

My Little Home Page

> Here goes the content. > > Other than the first three lines, it is almost the same as your original HTML. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From esr at thyrsus.com Fri Jul 14 15:35:08 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 09:35:08 -0400 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: <200007141407.JAA12817@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 09:07:29AM -0500 References: <20000713235356.X7340@xs4all.nl> <14702.37331.302346.67441@anthem.concentric.net> <200007141407.JAA12817@cj20424-a.reston1.va.home.com> Message-ID: <20000714093508.A8842@thyrsus.com> Guido van Rossum : > XXX is not a Dutch invention -- I picked up the habit from the X11 > source code base. I believe it's fairly common in open source > projects, and there are so many XXX'es throughout Python already that > it's better not to try and change. Guido is correct. XXX as a to-be-done marker was already known to me and well established in the U.S. in 1990, when I collected the following entry: @hd{XXX} @pr{X-X-X} @g{n.} @p{} A marker that attention is needed. Commonly used in program comments to indicate areas that are kluged up or need to be. Some hackers liken `XXX' to the notional heavy-porn movie rating. Compare @es{FIXME}. @comment from Bob Page , 16 Dec 1990 -- Eric S. Raymond No matter how one approaches the figures, one is forced to the rather startling conclusion that the use of firearms in crime was very much less when there were no controls of any sort and when anyone, convicted criminal or lunatic, could buy any type of firearm without restriction. Half a century of strict controls on pistols has ended, perversely, with a far greater use of this weapon in crime than ever before. -- Colin Greenwood, in the study "Firearms Control", 1972 From esr at thyrsus.com Fri Jul 14 15:39:31 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 09:39:31 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007141413.JAA12883@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 09:13:29AM -0500 References: <14702.36906.418249.461209@anthem.concentric.net> <14702.39175.2260.890343@anthem.concentric.net> <200007141413.JAA12883@cj20424-a.reston1.va.home.com> Message-ID: <20000714093931.B8842@thyrsus.com> Guido van Rossum : > I just want to make it crystal clear that I'm *against* (that's a > -999, only overridable by a bus) inclusion of 3rd party library source > code in the Python source distribution. Exceptions can only be made > if the particular 3rd party code needs to be modified before it is > usable from Python (e.g. some checksum algorithms, and PCRE) or if > there is no reasonably accessible distribution available on the web. OK, I'm confused now. Moshe, are we talking about including 3rd-party code, or simply changing the build process so that RPMs and Debian packages have some additional requires and possibly include some unmodified binary libraries from third parties? -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. From paul at prescod.net Fri Jul 14 12:13:24 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:13:24 -0500 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> Message-ID: <396EE7C4.17DEF722@prescod.net> Greg Stein wrote: > > ... > > I haven't seen a clear consensus or decision from the XML SIG yet. By the way, one of the major reasons there is no clear consensus from the XML SIG yet is because we are hung up on an issue of fact. Is it technically and politically feasible to put 4XPath into the Python distribution. Our discussions over there will be radically different if everybody over here says "sure, that's no problem." -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From guido at beopen.com Fri Jul 14 16:37:46 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:37:46 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Thu, 13 Jul 2000 14:34:03 -0400." <396E0B9B.DD74EF5@interet.com> References: <396E0B9B.DD74EF5@interet.com> Message-ID: <200007141437.JAA13178@cj20424-a.reston1.va.home.com> Ignoring most that's been said in this thread, would it be possible for the installer to detect the presence of python15.dll in the system directory and offer to delete it? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul at prescod.net Fri Jul 14 15:42:50 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 08:42:50 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> <14702.19480.746784.235766@bitdiddle.concentric.net> <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> <200007141417.JAA12935@cj20424-a.reston1.va.home.com> Message-ID: <396F18DA.A3EE25BF@prescod.net> Guido van Rossum wrote: > > ... > > But we have an additional requirement here: we want to prevent others > from distributing mutilated versions of our standard documents. What about the Annotated Python Enhancement Proposals? I don't see what the big deal is. People can find the real ones the same way they find the real Python distribution. Mutilated ones do not hurt us much and are not that likely in the first place. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From guido at beopen.com Fri Jul 14 16:52:16 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:52:16 -0500 Subject: [Python-Dev] ConfigParser changes In-Reply-To: Your message of "Thu, 13 Jul 2000 22:46:37 -0400." <200007140246.WAA07574@snark.thyrsus.com> References: <200007140246.WAA07574@snark.thyrsus.com> Message-ID: <200007141452.JAA13252@cj20424-a.reston1.va.home.com> > I've seen a couple plus responses to my proposed ConfigParser > enhancements, no minuses, and the thread has petered out. > > If nobody hands me a -1, I'm going to merge them in in a day or so. > Speak now... Cool. One possible suggestion (just for your contemplation): if you're only adding methods, would it make sense to make a subclass, so that from the class one uses it is clear whether one intends to modify the options or just to read them? That would enable future optimizations. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gvwilson at nevex.com Fri Jul 14 15:59:18 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 09:59:18 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <200007141417.JAA12935@cj20424-a.reston1.va.home.com> Message-ID: > Guido (on copyrights, public domain, etc.): > But we have an additional requirement here: we want to prevent others > from distributing mutilated versions of our standard documents. I > believe some form of open copyright is the best protection against > that. We're using the Open Publication License for Software Carpentry for exactly this reason. I once had to get the IEEE's copyright lawyer involved in a dispute where some material I had written had been slightly modified and then posted on the web under someone else's name --- still occasionally have to deal with fallout from copies of copies of copies of the distorted version. Greg From jeremy at beopen.com Fri Jul 14 16:03:58 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 10:03:58 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: References: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: <14703.7630.267201.436909@bitdiddle.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I'm currently drawing a list for extensions to include: MZ> -- zlib -- Tcl/Tk -- expat -- PIL -- Anything else? MZ> I really want something with "everything" in it. Then your list is much too short. Everything is a lot. You also need OpenSSL, NumPy, PyXML, and kjBuckets. And that's just getting started. My worry about the list of things to include is where exactly to cut the list short. The crucial modules are going to be different for every person. You mentioned PIL as one of your first four extensions. I've used PIL exactly once, and then only as a brief experiment. When I took a poll on c.l.py about the RADIUS authentication module, I got one response saying it was vitally important and everyone needs it. (I think that respondents definition of everyone was "everyone who operates an ISP or campus network.") So add radius to your list. Jeremy From guido at beopen.com Fri Jul 14 17:05:39 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:05:39 -0500 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: Your message of "Thu, 13 Jul 2000 17:48:38 EST." <396E4746.DE25EFD4@prescod.net> References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> <396E4746.DE25EFD4@prescod.net> Message-ID: <200007141505.KAA13385@cj20424-a.reston1.va.home.com> > If Guido has decided that the design that has already been implemented > is the right one, what's the point of the PEP? Someone just needs to > review the patch and check it in! Right! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Fri Jul 14 16:22:56 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 10:22:56 -0400 Subject: [Python-Dev] ConfigParser changes In-Reply-To: <200007141452.JAA13252@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 09:52:16AM -0500 References: <200007140246.WAA07574@snark.thyrsus.com> <200007141452.JAA13252@cj20424-a.reston1.va.home.com> Message-ID: <20000714102256.A9019@thyrsus.com> Guido van Rossum : > One possible suggestion (just for your contemplation): if you're only > adding methods, would it make sense to make a subclass, so that from > the class one uses it is clear whether one intends to modify the > options or just to read them? That would enable future optimizations. Yes, and I even know what I'd call the class: ConfigEditor. Unfortunately this plan it trips on a historical fact; one (1) of the write methods, add_section(), already existed in ConfigParser. Moving it to a ConfigEditor subclass would break backward compatibility. And I think it would be just too ugly to move all but one of the write methods into ConfigEditor and leave add_section() in the base class. If not for this problem I would be more than happy to do as you suggest. -- Eric S. Raymond "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy From moshez at math.huji.ac.il Fri Jul 14 16:14:11 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 17:14:11 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <009501bfed89$e415ce40$f2a6b5d4@hagrid> Message-ID: On Fri, 14 Jul 2000, Fredrik Lundh wrote: > we sure have a major disconnect here -- wasn't the source > of this discussion the need to be able to loop over multiple > sequences in parallel? Yes > isn't "for" what you'd usually use when looping over things? Yes. The thing is, you don't need to cater to people who want to iterate over one sequence -- you can already do that easily in current day Python. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Fri Jul 14 16:20:17 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 16:20:17 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: ; from ping@lfw.org on Fri, Jul 14, 2000 at 03:09:10AM -0700 References: Message-ID: <20000714162017.B7340@xs4all.nl> On Fri, Jul 14, 2000 at 03:09:10AM -0700, Ka-Ping Yee wrote: > I actually believe > solve(X.H()*X, X.H()*y) > is *clearer* than > (X'*X)\(X'*y) > (What does the backslash mean? What does the tick mark mean? > At least solve() is clear, and if i understood what H() stood > for, it would mean more than a tick mark.) More importantly, how are they grouped ? Is '* a single operator, or is ' a binary operator and * an unary operator ? Or is ' a postfix unary operator and * the binary operator ? Does the backslash escape the opening paren for some reason, or is it an operator on its own ? Oh, wait, I see it now ! It's a string literal of the new 'X' type, containing '*X)\(X', multiplied by y! I wonder what that 'X' type string is... Maybe a built-in regular expression ? Confusing-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Fri Jul 14 16:20:11 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 17:20:11 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14703.7630.267201.436909@bitdiddle.concentric.net> Message-ID: On Fri, 14 Jul 2000, Jeremy Hylton wrote: > MZ> I really want something with "everything" in it. > > Then your list is much too short. Everything is a lot. "Everything" is different from everything. <"wink"> > You also need OpenSSL, NumPy, PyXML, and kjBuckets. And that's just > getting started. I want to aim for "top 10 packages". And anyway, having distutils should make this a snap -- the only thing we have to do is match versions. > My worry about the list of things to include is where exactly to cut > the list short. The crucial modules are going to be different for > every person. You mentioned PIL as one of your first four extensions. > I've used PIL exactly once, and then only as a brief experiment. When > I took a poll on c.l.py about the RADIUS authentication module, I got > one response saying it was vitally important and everyone needs it. > (I think that respondents definition of everyone was "everyone who > operates an ISP or campus network.") So add radius to your list. My list is of course tentative, but once my PEP hits the CVS archive, I intend to poll c.l.py for opinions on what packages to include. I've seen quite a few questions in c.l.py over PIL, and only one about RADIUS, but that's just anecdotal evidence. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gvwilson at nevex.com Fri Jul 14 16:24:14 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 10:24:14 -0400 (EDT) Subject: [Python-Dev] request for minor enhancement Message-ID: I would like 'min' and 'max' to be in-fix binary operators, with '__min__' and '__max__' as the associated overloadable method names, and 'min=' and 'max=' as the in-place forms. I find myself re-defining them in almost every module I write, and believe that their semantics and implementation would be unproblematic? Reactions? Thanks, Greg From guido at beopen.com Fri Jul 14 17:29:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:29:02 -0500 Subject: [Python-Dev] Request for Opinions In-Reply-To: Your message of "Fri, 14 Jul 2000 05:13:24 EST." <396EE7C4.17DEF722@prescod.net> References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE7C4.17DEF722@prescod.net> Message-ID: <200007141529.KAA13625@cj20424-a.reston1.va.home.com> > By the way, one of the major reasons there is no clear consensus from > the XML SIG yet is because we are hung up on an issue of fact. Is it > technically and politically feasible to put 4XPath into the Python > distribution. Our discussions over there will be radically different if > everybody over here says "sure, that's no problem." I have no idea what 4XPath is. Assuming it is a separately maintained and distributed 3rd party library, the answer is no for the source distribution and yes for binary distributions. I know you've argued about this before but it's pointless, I don't want to have 3rd party code checked in as part of the Python CVS tree or distributed as part of a Python source distribution. However, one thing we *could* do is collect convenient links to the source code of the latest versions of all the necessary or popular 3rd party libraries -- or even redistribute copies from our website if their license allows it. We could also create a "sumo" (meaning so big it contains everything) source distribution that contains Python and all needed 3rd party libraries. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Fri Jul 14 17:33:16 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:33:16 -0500 Subject: [Python-Dev] Pythonb at SourceForge FAQ In-Reply-To: Your message of "Thu, 13 Jul 2000 17:45:54 MST." <20000713174554.R29590@lyra.org> References: <396E7D29.7AC68EA6@schneider-kamp.de> <20000713174554.R29590@lyra.org> Message-ID: <200007141533.KAA13655@cj20424-a.reston1.va.home.com> > > 3.3.: > > > > Q: How to change the status of a patch? > > > > A: > > > > To change the status of a patch or assign it to somebody else you have > > to be a) a SourceForge-recognized Python developer and b) a patch > > administrator. Unfortunately the SourceForge default for developers is > > not to be patch administrators. Contact one of the project > > administrators if the following does not work for you. > > > > Click on the patch itself. In the screen that comes up, there is a > > drop-box for "Assigned To:" and a drop-box for "Status:" where you can > > select a new responsible developer or a new status respectively. After > > selecting the appropriate victim and status, hit the "Submit Changes" > > button at the bottom of the page. Note: if are sure that you have the right permissions and a drop-box does not appear, check that you are actually logged in to SF! > > For more information about the use of the "Status:" and "Assigned To:" > > fields consult the [26]Patch Manager Guidelines. A recent copy can be > > found in the Appendix of this FAQ. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Fri Jul 14 17:38:52 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:38:52 -0500 Subject: [Python-Dev] urllib vs. cgi In-Reply-To: Your message of "Thu, 13 Jul 2000 22:44:10 -0400." <20000713224410.A7548@thyrsus.com> References: <14702.31418.483935.810948@bitdiddle.concentric.net> <20000713224410.A7548@thyrsus.com> Message-ID: <200007141538.KAA13713@cj20424-a.reston1.va.home.com> > Jeremy Hylton : > > Any opinions on adding a symmetrical urldecode to urllib? I'm not > > thrilled by duplicating code, but the cgi module is big and hairy and > > urllib seems like the obvious place for it. [ESR] > +0. It doesn't thrill me, but I can't argue with your analysis either. +0. Ditto. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gregory.lielens at fft.be Fri Jul 14 16:43:51 2000 From: gregory.lielens at fft.be (Gregory Lielens) Date: Fri, 14 Jul 2000 16:43:51 +0200 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators formatrix computation] References: <396DFDC5.6780A710@prescod.net> <396EE411.B3CB33A9@fft.be> <396EE730.6183423F@prescod.net> Message-ID: <396F2727.E301FBB4@fft.be> > Okay, but look at the syntactic support complex numbers needed. Just > "j". The same for string processing. We just reused most of the existing > operators. If you guys made a really kick-ass matrix package that > everyone loved and didn't need any new syntax, Guido might be tempted to > make matrices a built-in type also! Right, but I think that making a kick-ass matrix package without syntax modification is not possible... Indeed, what characterize the numeric languages around (e.g. matlab, octave, yorick, r-lab, ...) is precisely the presence of a syntax able to naturrally express linear algebra expression. All of them introduce easy matrix concatenation, multiplication, division and bloc-adressing...By the way, all matrix package are more or less cloning the matlab way, with minor differences (except for yorick, which have a more general syntax able to deal with multidimensional arrays cleanly, but probably make things less easy with 2D matrix). I think that such convergence comes probably from the fact that the Matlab way is the good way for numeric stuff... > The funny thing is that most of the Python syntax that I don't use today > is ALREADY for matrix operations: > > foo[x,y:a,b] > foo()[...] This is inevitable, I agree that numeric stuff is completely off-topic for a lot of peoples...But unicode support is also an excess-feature for numerical code. Of course, when you write something which must compute linear regressions and you want to ask input to a user which only speek japanese...In fact, what attracts me in Python the first time I've heard of it (3 weeks ago, so do not take my words too seriously...) is that it seems to be able to do numeric stuff quite well, except for matrix...the Python+NumPy package improve that, but not to the point of beeing matlab-like. Python+NumPy+MatPy is better in that sense, but still lack some operators to be THE solution...I tried to implement those operators as a way to check how python is extensible (a must, as the intended use of this - or anoteher numeric language) is to serve as command tools for c++ Finite element software, and I was surprise how easy it was...So here they are! I do not really see a problem in adding new operators, except when - it slows down the old ones, and I do not think it could be noticed in the present case...more ifs in the source code is certainly not something to worry about... - it makes python code unintelligible, and this is not relevant either: No numeric -> do not use them, but if you do numeric stuff, everything becomes clearer. - it makes python source more complex: true, but so little than I think it makes no practical difference. It is really a small change, after all I was able to implement it in a matter of day after looking for the fist time in the code...Arguably, this change is of the same order of magnitude as the 1.0j stuff...perhaps smaller - It is a hole which will unleash the craziest operators , and makes python look like binary with expressions soup like k=(a*$$^b)%/(@~c): That's the only risk I would be affraid of, but as already mentioned, linear algebra is a well established field , used almost everywhere in numerics and we have a bunch of languages which already support these kind of operators... From guido at beopen.com Fri Jul 14 17:45:08 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:45:08 -0500 Subject: [Python-Dev] PyErr_SafeFormat In-Reply-To: Your message of "Thu, 13 Jul 2000 19:29:30 +0200." <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> Message-ID: <200007141545.KAA13821@cj20424-a.reston1.va.home.com> > greg wrote: > > We don't care about anything except for %d, %s, possibly %c and %x. > > how about: I would suggest to build this into PyErr_Format, which is what everybody already uses. Instant safety. Need some more analysis of what format codes are actually used, and support for %.200s which is currently used often. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Fri Jul 14 17:05:04 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 11:05:04 -0400 Subject: [Python-Dev] request for minor enhancement In-Reply-To: ; from gvwilson@nevex.com on Fri, Jul 14, 2000 at 10:24:14AM -0400 References: Message-ID: <20000714110504.A9206@thyrsus.com> Greg Wilson : > I would like 'min' and 'max' to be in-fix binary operators, with '__min__' > and '__max__' as the associated overloadable method names, and 'min=' and > 'max=' as the in-place forms. I find myself re-defining them in almost > every module I write, and believe that their semantics and implementation > would be unproblematic? > > Reactions? +0 -- Eric S. Raymond "As to the species of exercise, I advise the gun. While this gives [only] moderate exercise to the body, it gives boldness, enterprise, and independence to the mind. Games played with the ball and others of that nature, are too violent for the body and stamp no character on the mind. Let your gun, therefore, be the constant companion to your walks." -- Thomas Jefferson, writing to his teenaged nephew. From guido at beopen.com Fri Jul 14 17:58:28 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:58:28 -0500 Subject: [Python-Dev] request for minor enhancement In-Reply-To: Your message of "Fri, 14 Jul 2000 10:24:14 -0400." References: Message-ID: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> > I would like 'min' and 'max' to be in-fix binary operators, with '__min__' > and '__max__' as the associated overloadable method names, and 'min=' and > 'max=' as the in-place forms. I find myself re-defining them in almost > every module I write, and believe that their semantics and implementation > would be unproblematic? You seem to propose two independent things. 1. in-fix min and max: you want to write "x min y" instead min(x, y). Why? It's not a notation I'm familiar with. Plus it's incompatible, since min would have to be a reserved word and it would break all existing code using min(). 2. __min__ and __max__ to override the semantics. Sure, this can be added regardless of (1). But do you want to override min(a, b) or min(sequence)? Note that min() and max() are variadic functions -- you can write min(a,b,c,d,e) which is the same as min([a,b,c,d,e]). 3. min= and max=? Ah, I see, like += and -=. Since I don't see much hope for (1) this is irrelevant. (But it's a good proposal for a generic syntax for other operators that are spelled with a reserved word.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Fri Jul 14 17:01:43 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 11:01:43 -0400 (EDT) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396EE6B3.B86BED76@prescod.net> References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE6B3.B86BED76@prescod.net> Message-ID: <14703.11095.264917.268373@bitdiddle.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Greg Stein wrote: >> ... >> >> I think this is for the XML SIG. I don't know why it is >> here. SIGs discuss and design, then roll up their final >> decisions. PP> Okay, so we can agree in the XML SIG that we love XPath and then PP> "check in" 4K of Bison/FLEX/C/Python code without consulting PP> anyone else? Yes. You've got it exactly. How do you think lambda made its way into the language? Seriously -- you've already seen Guido's response. I think there's no chance of adding third-party code to the Python CVS repository or source distribution. The only way I could imagine it happening is if there was strong consensus from the XML SIG. So Greg's suggestion is a good one. Jeremy From moshez at math.huji.ac.il Fri Jul 14 17:08:28 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 18:08:28 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007141413.JAA12883@cj20424-a.reston1.va.home.com> Message-ID: On Fri, 14 Jul 2000, Guido van Rossum wrote: > I just want to make it crystal clear that I'm *against* (that's a > -999, only overridable by a bus) inclusion of 3rd party library source > code in the Python source distribution. Exceptions can only be made > if the particular 3rd party code needs to be modified before it is > usable from Python (e.g. some checksum algorithms, and PCRE) or if > there is no reasonably accessible distribution available on the web. I took it that you're alright with a "sumo" distribution, which is core Python with + lots of goodies. I think it would be neat if the sumo distribution would be released together with the thin distribution from PythonLabs, and that Python-Dev would help support it. I *don't* think we need to maintain any such thing in the CVS tree -- only in the .tar.gz we let the world download. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gvwilson at nevex.com Fri Jul 14 17:17:17 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 11:17:17 -0400 (EDT) Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> Message-ID: > > Greg Wilson wrote: > > I would like 'min' and 'max' to be in-fix binary operators, with '__min__' > > and '__max__' as the associated overloadable method names, and 'min=' and > > 'max=' as the in-place forms. > On Fri, 14 Jul 2000, Guido van Rossum wrote: > > 1. in-fix min and max: you want to write "x min y" instead min(x, y). > Why? It's not a notation I'm familiar with. Plus it's incompatible, > since min would have to be a reserved word and it would break all > existing code using min(). I got there by working backwards to make things consistent. I want overloadable '__min__' and 'min=', and everything else that has these forms is binary infix (I think). > 2. __min__ and __max__ to override the semantics. Sure, this can be > added regardless of (1). But do you want to override min(a, b) or > min(sequence)? Note that min() and max() are variadic functions -- > you can write min(a,b,c,d,e) which is the same as min([a,b,c,d,e]). '+', '*', and the bitwise operators are equally variadic --- is confusion avoided by using punctuation for the infix binary form, and a named function for the general form? If the answer is 'yes', then my crystal ball predicts the following exchange: Greg: So let's adopt the notation '?' for 'min' and 'max', as used in C* and other parallel languages. We can then use '?=' for the infix forms, and reserve 'min()' and 'max()' as built-ins for the variadic forms. After all, it's just an historical accident that 'min' and 'max' aren't treated with the same respect as '+' and 'or'. Someone: Uck! I've never seen that before! It looks like line noise! It's not worth complexifying the core language with new operators for this special case. Greg: ...which is exactly the response I've twice typed in, and deleted, on the "linear algebra operators" thread. If 'min' and 'max' (which are used for strings as well as numbers) aren't worth new operators, I don't think matrices are either (and I probably do more matrix algebra than most people on this list). > 3. min= and max=? Ah, I see, like += and -=. Since I don't see much > hope for (1) this is irrelevant. (But it's a good proposal for a > generic syntax for other operators that are spelled with a reserved > word.) Thanks, Greg p.s. if min(a,b,c,d,e) is the same as min([a,b,c,d,e]), then what is the meaning of min([a,b,c,d,e], [g,h,i,j,k])? From moshez at math.huji.ac.il Fri Jul 14 17:18:31 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 18:18:31 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <20000714093931.B8842@thyrsus.com> Message-ID: On Fri, 14 Jul 2000, Eric S. Raymond wrote: > Guido van Rossum : > > I just want to make it crystal clear that I'm *against* (that's a > > -999, only overridable by a bus) inclusion of 3rd party library source > > code in the Python source distribution. Exceptions can only be made > > if the particular 3rd party code needs to be modified before it is > > usable from Python (e.g. some checksum algorithms, and PCRE) or if > > there is no reasonably accessible distribution available on the web. > > OK, I'm confused now. > > Moshe, are we talking about including 3rd-party code, or simply > changing the build process so that RPMs and Debian packages have some > additional requires and possibly include some unmodified binary > libraries from third parties? Neither. Let me explain: I *don't* care about RPM and Debian packages, nor about windows installers. Those who create such packages have time on their hands, and usually a pretty good Python and C knowledge. What I do care about, is that when building a complete Python interpreter from source on a UNIX system, one has the option of downloading the sumo package, type "./configure;make;make install", drink a cup of coffee, and have a Python installation which does what he needs. Take me, for example. I've decided to write a GUI in Python, and I need to -- download Tcl 8.0 (because that's what Python 1.5.2 works with), and compile it -- download Tk 8.0 and compile it -- Edit the Modules/Setup file to point to my Tcl/Tk installation -- Compile Python Now, if I find out later (as I have) that PIL would make my life easier, I need to download PIL, edit *it* so it builds against my Tcl/Tk, and install it. (Eventually, I decided to go without PIL because I don't have the time) Then I want to prototype some XML manipulation in Python. So I have to find out where expat lives, compile it, and only then I can get PyExpat to work. Now, if I were using Debian, I'd simply spend some quality time with apt-get and get over this. But I'm using Solaris, and later I might need to port to AIX. So I'm using source distributions, and it is simply painful. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From akuchlin at mems-exchange.org Fri Jul 14 17:20:02 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 14 Jul 2000 11:20:02 -0400 Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: ; from gvwilson@nevex.com on Fri, Jul 14, 2000 at 11:17:17AM -0400 References: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> Message-ID: <20000714112002.E28819@kronos.cnri.reston.va.us> On Fri, Jul 14, 2000 at 11:17:17AM -0400, Greg Wilson wrote: >I want overloadable '__min__' and 'min=', and everything else that has these >forms is binary infix (I think). One exception to the binary infix form: 'if foo' will call foo.__nonzero__. --amk From MarkH at ActiveState.com Fri Jul 14 17:21:29 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Fri, 14 Jul 2000 11:21:29 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007141437.JAA13178@cj20424-a.reston1.va.home.com> Message-ID: > Ignoring most that's been said in this thread, would it be possible > for the installer to detect the presence of python15.dll in the system > directory and offer to delete it? This should only be done if the installer can be very sure that the user _tried_ to uninstall 1.5, but this DLL remains. This could be done in a number of ways, none of which are foolproof (eg, you could check for a 1.5 registry key, but of the user has added their own PythonPath entries, for example, the installer wont remove them (as it didnt add them) - meaning you end up with a partial 1.5 registry tree remaining. A big of experimentation could provide something that works in a majority of cases. IMO, it is very important 1.5 and x.x can coexist on the same machine; especially in the light of this thread, where it should be obvious that many extension wont be available for post 1.5 releases until quite some time after that core release hits the street... Mark. \ From akuchlin at mems-exchange.org Fri Jul 14 17:23:15 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 14 Jul 2000 11:23:15 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14703.7630.267201.436909@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jul 14, 2000 at 10:03:58AM -0400 References: <14702.4582.530066.817107@bitdiddle.concentric.net> <14703.7630.267201.436909@bitdiddle.concentric.net> Message-ID: <20000714112315.F28819@kronos.cnri.reston.va.us> On Fri, Jul 14, 2000 at 10:03:58AM -0400, Jeremy Hylton wrote: >the list short. The crucial modules are going to be different for >every person. You mentioned PIL as one of your first four extensions. That's why I think this is a mug's game; people have wildly differing needs, and you can't meet them all. The correct fix is to make it easy to automatically download & install packages automatically; distributions then become simple lists. "You want to do Web development? Grab Cookie.py, wizard.py, DocumentTemplate, ..." "Numeric work? NumPy, PhysicalValue, Snow, ..." --amk From guido at beopen.com Fri Jul 14 18:24:56 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 11:24:56 -0500 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: Your message of "Fri, 14 Jul 2000 18:08:28 +0300." References: Message-ID: <200007141624.LAA14130@cj20424-a.reston1.va.home.com> > I took it that you're alright with a "sumo" distribution, which is core > Python with + lots of goodies. I think it would be neat if the sumo > distribution would be released together with the thin distribution from > PythonLabs, and that Python-Dev would help support it. Yes, we here at PythonLabs don't know enough about all the different 3rd party packages to know what to add and how to ensure that it builds easily. I suppose it should also have a top-level super-Makefile and a suggested Modules/Setup file (with all the 3rd packages enabled and correct pointers to source directories). > I *don't* think we need to maintain any such thing in the CVS tree -- only > in the .tar.gz we let the world download. Agreed. I have to add that I'm +0 on this idea -- it would seem that if we distribute a sumo RPM distribution we'd help way more people. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Fri Jul 14 18:26:49 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 11:26:49 -0500 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: Your message of "Fri, 14 Jul 2000 18:18:31 +0300." References: Message-ID: <200007141626.LAA14154@cj20424-a.reston1.va.home.com> > Neither. Let me explain: I *don't* care about RPM and Debian packages, nor > about windows installers. Those who create such packages have time on > their hands, and usually a pretty good Python and C knowledge. What I do > care about, is that when building a complete Python interpreter from > source on a UNIX system, one has the option of downloading the sumo > package, type "./configure;make;make install", drink a cup of coffee, and > have a Python installation which does what he needs. > > Take me, for example. I've decided to write a GUI in Python, and I need to > -- download Tcl 8.0 (because that's what Python 1.5.2 works with), and > compile it > -- download Tk 8.0 and compile it > -- Edit the Modules/Setup file to point to my Tcl/Tk installation > -- Compile Python > > Now, if I find out later (as I have) that PIL would make my life easier, > I need to download PIL, edit *it* so it builds against my Tcl/Tk, and > install it. (Eventually, I decided to go without PIL because I don't have > the time) > > Then I want to prototype some XML manipulation in Python. So I have to > find out where expat lives, compile it, and only then I can get PyExpat > to work. > > Now, if I were using Debian, I'd simply spend some quality time with > apt-get and get over this. But I'm using Solaris, and later I might need > to port to AIX. So I'm using source distributions, and it is simply > painful. Bah, Solaris. Who still uses that old crap? :-) Or you could wait for ActivePython, which promises a binary distribution of Python 2.0 for Solaris. http://www.activestate.com/Products/ActivePython.html --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Fri Jul 14 17:39:26 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 11:39:26 -0400 Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: ; from gvwilson@nevex.com on Fri, Jul 14, 2000 at 11:17:17AM -0400 References: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> Message-ID: <20000714113926.B9381@thyrsus.com> Greg Wilson : > Greg: So let's adopt the notation '?' for 'min' and > 'max', as used in C* and other parallel languages. We can > then use '?=' for the infix forms, and reserve > 'min()' and 'max()' as built-ins for the variadic forms. > After all, it's just an historical accident that 'min' and > 'max' aren't treated with the same respect as '+' and 'or'. I would support something like this. What's really going on here, IMO, is that you're groping towards giving Python a complete set of notations for lattice algebra. My ma\thematician head likes this idea. -- Eric S. Raymond Men trained in arms from their infancy, and animated by the love of liberty, will afford neither a cheap or easy conquest. -- From the Declaration of the Continental Congress, July 1775. From jeremy at beopen.com Fri Jul 14 17:36:00 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 11:36:00 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007141624.LAA14130@cj20424-a.reston1.va.home.com> References: <200007141624.LAA14130@cj20424-a.reston1.va.home.com> Message-ID: <14703.13152.88286.674722@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> I *don't* think we need to maintain any such thing in the CVS >> tree -- only in the .tar.gz we let the world download. GvR> Agreed. GvR> I have to add that I'm +0 on this idea -- it would seem that if GvR> we distribute a sumo RPM distribution we'd help way more GvR> people. I think it's significantly harder to create a .tar.gz file with a configure script and a makefile that builds Python and all the third-party libraries it depends on. Does the zlib source belong in the .tar.gz? How about OpenSSL? Tcl/Tk? libc? There are at least two problems with putting anything other than Python in a .tar.gz that we distribute. First, the user who grabs it may already have some of the third-party extensions installed. Second, we have a version-skew nightmare because each library is updated at its own pace. This is why Andrew is still correct! >>>>> "AMK" == Andrew Kuchling writes: AMK> The correct fix is to make it easy to AMK> automatically download & install packages automatically; AMK> distributions then become simple lists. "You want to do Web AMK> development? Grab Cookie.py, wizard.py, DocumentTemplate, ..." AMK> "Numeric work? NumPy, PhysicalValue, Snow, AMK> ..." The distutils plus platform-specific package management like RPM and Debian packages are the right solution. We can produce a Python package that indicates its dependence on readline, Tcl/Tk, or anything else. We can also provide a collection of Python packages via distutils that addresses the needs of particular audiences -- Web slingers, numerical analysts, etc. Jeremy From effbot at telia.com Fri Jul 14 17:39:08 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 17:39:08 +0200 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> Message-ID: <00f001bfeda9$a7d0d400$f2a6b5d4@hagrid> paul wrote: > We have three options: > > 1. use the relatively large 4XPath as is > > 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) > that can be implemented in a couple of hundred lines of Python code > (this code is mostly done already, in a module called TinyXPath) > > 3. try to scale 4XPath back by moving its parser to SRE, and making > some of its features "options" that can be added separately (not clear > how easy this is) > > What do you think? if there's a migration path from (2) to (1) (interface-wise, at least), I'd vote for (2). or (2)+(3), if that makes sense. (I know I've promised to look at (1)+(3), but I haven't quite gotten there yet...) From effbot at telia.com Fri Jul 14 17:33:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 17:33:19 +0200 Subject: [Python-Dev] request for minor enhancement / linear algebra References: Message-ID: <00ef01bfeda9$a753b4c0$f2a6b5d4@hagrid> greg wrote: > p.s. if min(a,b,c,d,e) is the same as min([a,b,c,d,e]), then what is the > meaning of min([a,b,c,d,e], [g,h,i,j,k])? same as min([[a,b,c,d,e], [g,h,i,j,k]]), of course. From thomas at xs4all.net Fri Jul 14 17:33:43 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 17:33:43 +0200 Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: <20000714112002.E28819@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Fri, Jul 14, 2000 at 11:20:02AM -0400 References: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> <20000714112002.E28819@kronos.cnri.reston.va.us> Message-ID: <20000714173343.C7340@xs4all.nl> On Fri, Jul 14, 2000 at 11:20:02AM -0400, Andrew Kuchling wrote: > On Fri, Jul 14, 2000 at 11:17:17AM -0400, Greg Wilson wrote: > >I want overloadable '__min__' and 'min=', and everything else that has > >these forms is binary infix (I think). > One exception to the binary infix form: 'if foo' will call > foo.__nonzero__. And another: int(foo) (and other, implicit conversions) call foo.__int__. However, I think overloading 'min' and 'max' should fall under the rich comparisons PEP. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From uche.ogbuji at fourthought.com Fri Jul 14 17:38:59 2000 From: uche.ogbuji at fourthought.com (Uche Ogbuji) Date: Fri, 14 Jul 2000 09:38:59 -0600 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE7C4.17DEF722@prescod.net> <200007141529.KAA13625@cj20424-a.reston1.va.home.com> Message-ID: <396F3413.608AF907@fourthought.com> Even though I'm one of the 4XPath developers, I've largely stayed on the sidelines because I've never been on python-dev, and I don't know how such matters are usually considered. Guido's response gives good guidance, and my ideas are expressed in-line. Guido van Rossum wrote: > > > By the way, one of the major reasons there is no clear consensus from > > the XML SIG yet is because we are hung up on an issue of fact. Is it > > technically and politically feasible to put 4XPath into the Python > > distribution. Our discussions over there will be radically different if > > everybody over here says "sure, that's no problem." > > I have no idea what 4XPath is. Assuming it is a separately maintained > and distributed 3rd party library, the answer is no for the source > distribution and yes for binary distributions. Paul did suggest a couple of other options. One was to make 4XPath easier to integrate into Python (by moving to SRE or otherwise removing the lex/yacc dependencuy), and this is a possibility. However, I don't know how you gauge what a "third-party" module is. My guess would be that it's a matter of copyright. If so, that might be an obstacle, but maybe not an insurmountable one. The other solution was to write an XPath-lite, probably all in Python to go with minidom in the Python distro. This would be the path of least resistance, but we are still discussion on xml-sig the useful subset of XPath. Is there any clear statement of policiy for including modules? Even a mailing-list archive entry? I don't expect one because this is open-source/BDFL world where the policy usually lies in a highly-respectable head, but it could certainly guide this conversation either here or on xml-sig. > We could also create a "sumo" (meaning so big it contains everything) > source distribution that contains Python and all needed 3rd party > libraries. Not a bad idea as a stop-gap answer to CPAN. -- Uche Ogbuji Principal Consultant uche.ogbuji at fourthought.com +01 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python From guido at beopen.com Fri Jul 14 18:47:03 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 11:47:03 -0500 Subject: [Python-Dev] Request for Opinions In-Reply-To: Your message of "Fri, 14 Jul 2000 09:38:59 CST." <396F3413.608AF907@fourthought.com> References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE7C4.17DEF722@prescod.net> <200007141529.KAA13625@cj20424-a.reston1.va.home.com> <396F3413.608AF907@fourthought.com> Message-ID: <200007141647.LAA14305@cj20424-a.reston1.va.home.com> > Even though I'm one of the 4XPath developers, I've largely stayed on the > sidelines because I've never been on python-dev, and I don't know how > such matters are usually considered. Guido's response gives good > guidance, and my ideas are expressed in-line. Thanks for responding! > Guido van Rossum wrote: > > > > > By the way, one of the major reasons there is no clear consensus from > > > the XML SIG yet is because we are hung up on an issue of fact. Is it > > > technically and politically feasible to put 4XPath into the Python > > > distribution. Our discussions over there will be radically different if > > > everybody over here says "sure, that's no problem." > > > > I have no idea what 4XPath is. Assuming it is a separately maintained > > and distributed 3rd party library, the answer is no for the source > > distribution and yes for binary distributions. > > Paul did suggest a couple of other options. One was to make 4XPath > easier to integrate into Python (by moving to SRE or otherwise removing > the lex/yacc dependencuy), and this is a possibility. However, I don't > know how you gauge what a "third-party" module is. My guess would be > that it's a matter of copyright. If so, that might be an obstacle, but > maybe not an insurmountable one. The other solution was to write an > XPath-lite, probably all in Python to go with minidom in the Python > distro. This would be the path of least resistance, but we are still > discussion on xml-sig the useful subset of XPath. > > Is there any clear statement of policiy for including modules? Even a > mailing-list archive entry? I don't expect one because this is > open-source/BDFL world where the policy usually lies in a > highly-respectable head, but it could certainly guide this conversation > either here or on xml-sig. My policy for including modules is that Python becomes the only distribution point of the code, and the code is maintained through the Python CVS tree (possibly by the original author). This places restrictions on the copyright notice. There are exceptions (e.g. cPickle.c has a life of its own in the Zope world, although the modules frequently get re-sync'ed), but they are rare and must serve very special purposes. Unless I'm mistaken, 4XPath leads a separate life so can't be included. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gvwilson at nevex.com Fri Jul 14 17:49:12 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 11:49:12 -0400 (EDT) Subject: [Python-Dev] Re: request for minor enhancement / linear algebra In-Reply-To: <20000714113926.B9381@thyrsus.com> Message-ID: > > Greg: So let's adopt the notation '?' for 'min' and > > 'max', as used in C* and other parallel languages. We can > > then use '?=' for the infix forms, and reserve > > 'min()' and 'max()' as built-ins for the variadic forms. > > After all, it's just an historical accident that 'min' and > > 'max' aren't treated with the same respect as '+' and 'or'. > Eric Raymond: > I would support something like this. What's really going on here, > IMO, is that you're groping towards giving Python a complete set of > notations for lattice algebra. My mathematician head likes this > idea. Greg: I was actually trying to convince people that adding operators one by one (even well-defined ones that lots of people would use) would be a bad idea. Our two main reasons for choosing Python for Software Carpentry were its simplicity (it can be taught quickly) and its availability (widely portable, open source). I (and my customers) would enjoy doing matrix algebra using mathematical notation in Python, but one-at-a-time extensions are going to reduce the chances of people choosing Python for their projects. Saying, "But you don't have to use these new operators if you don't want to," is a red herring --- if I want to understand/modify other people's code, I'll have to learn 'em (just as I've had to learn most of Perl's syntax, one painful special case at a time, in order to use the LDAP, XML, CGI, and imaging libraries). So: I would like this (linear algebra, min/max, other notation) to happen, but only if there's an extensible, scalable framework for user-defined libraries to add operators to Python, in the same way that they can now add new classes. "Extend, or extend not --- there is no special case." Thanks, Greg From effbot at telia.com Fri Jul 14 17:56:26 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 17:56:26 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <396E0B9B.DD74EF5@interet.com> <200007141437.JAA13178@cj20424-a.reston1.va.home.com> Message-ID: <01b201bfedac$12353d20$f2a6b5d4@hagrid> guido wrote: > Ignoring most that's been said in this thread, would it be possible > for the installer to detect the presence of python15.dll in the system > directory and offer to delete it? would the average user know when to click "Yes" ? From moshez at math.huji.ac.il Fri Jul 14 17:50:55 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 18:50:55 +0300 (IDT) Subject: [Python-Dev] request for minor enhancement In-Reply-To: Message-ID: On Fri, 14 Jul 2000, Greg Wilson wrote: > I would like 'min' and 'max' to be in-fix binary operators, with '__min__' > and '__max__' as the associated overloadable method names, and 'min=' and > 'max=' as the in-place forms. I find myself re-defining them in almost > every module I write, and believe that their semantics and implementation > would be unproblematic? I'm -1 on that. I'm a mathematician by schooling, and I must say max(1,2) reads much more naturally to me then 1 max 2 And "max=" just looks..... i max= 5? Come on, isn't i = max(i, 5) much more readable? Re: overloading: it is useful only for lattices, as any linear order can just use the definition max(i,j) == k iff (i==k or j==k) and i<=k and j<=k Until Python recognizes the fact that not everything is linearly ordered (AKA, rich comparisons, which should be done as a PEP really), it would be futile to deal with lattices. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From fdrake at beopen.com Fri Jul 14 17:56:00 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 11:56:00 -0400 (EDT) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396EE66F.59D0D45F@prescod.net> References: <200007140516.HAA28633@python.inrialpes.fr> <396EE66F.59D0D45F@prescod.net> Message-ID: <14703.14352.411905.934970@cj42289-a.reston1.va.home.com> [Note that I've simplified the headers, but cross-posted to python-dev and xml-sig. *Please* follow up to xml-sig!] Paul Prescod writes: > Why aren't we ready to dicuss it? I think the XML crew should discuss these things first. PyXML has generally been treated as a catch all for various neat XML stuff, but looking at it as a careful extension of the core XML support means we need to think about it that way, including the line between what's in the core and what isn't. I think it's very valuable to listen to the experts on this topic (which I think is predominantly you, the FourThought crew, and Lars, with Sean playing a secondary role since he's usually too busy to participate in the discussions). I'd like to see this discussed in the SIG with an eye to creating two non-experimental packages: 1. XML support for the Python standard library, and 2. an XML extension package that adds support for more recommendations and candidate recommendations. There should still be something like the current PyXML, which contains all the neat stuff that doesn't fall in one of the other two categories. I think a PEP and further discussions in the XML-SIG are in order before we add more material into the standard library. I'm firmly committed to getting the "right stuff" in there, but I don't want to rush headlong into adding things before they're ready and agreed upon. I'd love to see you or one of the other Python+XML leaders be editor for a PEP on this topic. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Fri Jul 14 17:57:26 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 10:57:26 -0500 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE7C4.17DEF722@prescod.net> <200007141529.KAA13625@cj20424-a.reston1.va.home.com> Message-ID: <396F3866.97D1752@prescod.net> Guido van Rossum wrote: > >... > > I have no idea what 4XPath is. Assuming it is a separately maintained > and distributed 3rd party library, the answer is no for the source > distribution and yes for binary distributions. 4XPath is currently separately maintained. If it became part of the Python source, I would expect that to become the canonical version. The issue here isn't third party libraries its quantity of source and the fact that it is a mix of Bison/FLEX/C/Python. If it were six hundred lines of pure Python I think we would have checked it in already! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Fri Jul 14 18:02:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 18:02:48 +0200 Subject: [Python-Dev] re: list comprehension / pop quiz References: <396DB5E8.6F12ACA4@per.dem.csiro.au> <20000713091546.A5094@thyrsus.com> <20000713153434.U7340@xs4all.nl> Message-ID: <01ed01bfedac$f5f81fa0$f2a6b5d4@hagrid> thomas wrote: > > plait() is *good*. > > Hmm... 'plait'. I don't even know what that means. it's yoghurt, right? From moshez at math.huji.ac.il Fri Jul 14 18:04:41 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 19:04:41 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14703.13152.88286.674722@bitdiddle.concentric.net> Message-ID: On Fri, 14 Jul 2000, Jeremy Hylton wrote: > I think it's significantly harder to create a .tar.gz file with a > configure script and a makefile that builds Python and all the > third-party libraries it depends on. Does the zlib source belong in > the .tar.gz? How about OpenSSL? Tcl/Tk? libc? Yes to all popular ones but "libc". > There are at least two problems with putting anything other than > Python in a .tar.gz that we distribute. First, the user who grabs it > may already have some of the third-party extensions installed. And I'm not suggesting to install any third-party extension publicly! Everything should be installled in Python's tree. > Second, we have a version-skew nightmare because each library is > updated at its own pace. No, we release a known-good version. Users who need more sophistication can build their own. > This is why Andrew is still correct! For well packaged platforms, like, well, Linux and FreeBSD. But on Solaris, it's much harder to find the readline library in an already packaged form, and the dependancy mechanism there sucks anyway. > AMK> The correct fix is to make it easy to > AMK> automatically download & install packages automatically; > AMK> distributions then become simple lists. "You want to do Web > AMK> development? Grab Cookie.py, wizard.py, DocumentTemplate, ..." > AMK> "Numeric work? NumPy, PhysicalValue, Snow, > AMK> ..." > > The distutils plus platform-specific package management like RPM and > Debian packages are the right solution. For Linux, plus add ports to cover FreeBSD. Anyone using any other UNIX is SOL right now. I agree that a "web-oriented sumo distribution", "numeric-oriented sumo distribution", .... etc. would be cool. If we had infinite resources, I'd be +10 on that -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Fri Jul 14 18:13:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 18:13:45 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> Message-ID: <02c701bfedae$7db6fd20$f2a6b5d4@hagrid> guido wrote: > > > We don't care about anything except for %d, %s, possibly %c and %x. > > > > how about: > > I would suggest to build this into PyErr_Format, which is what > everybody already uses. Instant safety. Need some more analysis of > what format codes are actually used greg's original mail mentioned %d, %i, %s, %c and %x, which is what I implemented. (if my code stumbles upon any other formatting code, it simply copies the rest of the formatting string to the output string.) it also looks as if PyErr_Format is undocumented, so we could solve this by simply writing some documentation ;-) > and support for %.200s which is currently used often. note that the code intentionally ignores the .200 part; as greg pointed out, they're only used today to make sure the message doesn't overflow PyErr_Format's buffer... but it's easy to fix. patch coming. From esr at thyrsus.com Fri Jul 14 18:21:40 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 12:21:40 -0400 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <01ed01bfedac$f5f81fa0$f2a6b5d4@hagrid>; from effbot@telia.com on Fri, Jul 14, 2000 at 06:02:48PM +0200 References: <396DB5E8.6F12ACA4@per.dem.csiro.au> <20000713091546.A5094@thyrsus.com> <20000713153434.U7340@xs4all.nl> <01ed01bfedac$f5f81fa0$f2a6b5d4@hagrid> Message-ID: <20000714122140.A9722@thyrsus.com> Fredrik Lundh : > thomas wrote: > > > plait() is *good*. > > > > Hmm... 'plait'. I don't even know what that means. > > it's yoghurt, right? No, *I* wrote `plait() is *good*.' In English, `plait' is a slightly unusual word with a meaning almost indistinguishable from `braid'. The difference is that the primary use of `braid' has to do with hair, while `plait' is associated with ribbons or other forms of ornament. -- Eric S. Raymond [W]hat country can preserve its liberties, if its rulers are not warned from time to time that [the] people preserve the spirit of resistance? Let them take arms...The tree of liberty must be refreshed from time to time, with the blood of patriots and tyrants. -- Thomas Jefferson, letter to Col. William S. Smith, 1787 From guido at beopen.com Fri Jul 14 19:14:44 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 12:14:44 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Fri, 14 Jul 2000 17:56:26 +0200." <01b201bfedac$12353d20$f2a6b5d4@hagrid> References: <396E0B9B.DD74EF5@interet.com> <200007141437.JAA13178@cj20424-a.reston1.va.home.com> <01b201bfedac$12353d20$f2a6b5d4@hagrid> Message-ID: <200007141714.MAA14470@cj20424-a.reston1.va.home.com> > > Ignoring most that's been said in this thread, would it be possible > > for the installer to detect the presence of python15.dll in the system > > directory and offer to delete it? > > would the average user know when to click "Yes" ? Whenever they don't have a 1.5 installation that they are interested in preserving. Hm, the registry probably points to where that would live if it existed, so the installer (or a custom program run automatically by it) can do more probing if it needs to. I guess the user should think about whether they want their Python COM things to use 1.5 or 2.0. Only the one they choose should install its DLL in the system directory; the other one should have its DLL in its own directory. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Fri Jul 14 18:15:49 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 14 Jul 2000 11:15:49 -0500 Subject: [Python-Dev] A bit of a delay on stuff on my plate... Message-ID: <200007141615.LAA11548@dolphin.mojam.com> I ran into a little snag yesterday on the way to making a few changes (particularly the *path.commonprefix stuff). I mislaid my computer. Actually, I left it (in its briefcase, with my cell phone and Palm - in short, essentially my entire electronic existence) in a meeting in Los Altos and didn't realize it until I got to the SF airport. Fortunately, it was retrieved, but I am sans electronica for a day or two until it gets shipped out to me. I'll take care of everything that's on my plate when I get my electronic life reassembled. I've already assigned some tasks to volunteers who are helping with regression test writing for the posix, *path and sys modules. Hopefully they'll make some progress in my absence... Skip From huaiyu_zhu at yahoo.com Fri Jul 14 18:29:17 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 09:29:17 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <010401bfed6c$8d905300$0900a8c0@SPIFF> Message-ID: On Fri, 14 Jul 2000, Fredrik Lundh wrote: > Huaiyu Zhu wrote: > > Look it this way. Text processing do have their special syntaxes. > > what special syntax? > > regular expressions are a *sublanguage* in Python. everything else > is done through methods and ordinary sequence operators. Following is the quote of my previous post: > > (While a Python variant isn't something I'm enthused about, one > language can't be all things to all people, and I don't see why matrix > operations are so important as to get extra specialized operators; > lots of people use Python for text processing or for COM, so why > shouldn't special syntax be added for *those* applications? Having a > special parser also means that other matrix-specific language changes > could be made.) Well, linear algebra is not just another special domain. It is almost as elementary as arithmetic. Vectors and matrices are fundamental concepts in mathematics that underlies almost all of "scientific computation". They distill centuries of research in science and engineering, especially computation techniques. It is unlikely that adding linear algebra support would open up a flood gate for similar constructs. Look it this way. Text processing do have their special syntaxes. A string is written as "string" instead of ['s','t','r','i','n','g']. There is even the new sep.join(list). There are also lists and dicts for to build structures for discrete maths. If we had requested that new syntax for Fourier analysis or fractal generation that would be comparable to text processing or COM. Python actually has the chance of being all things to most people. The other half of the computing crowd only needs a few very basic asistance to come across. This crowd consists of people who design bridges and missiles, figure out weather patterns or DNA structures, detect credit card fraud or defects on a microchip, design speach recognition systems or network traffic balance algorithms and machines that learn to play games. Science and technology have great power to penatrate many aspects of life. And imagine if most of that is implemented in a laguage that can also be taught in schools. Huaiyu From ping at lfw.org Fri Jul 14 18:31:49 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Fri, 14 Jul 2000 09:31:49 -0700 (PDT) Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: Message-ID: On Fri, 14 Jul 2000, Greg Wilson wrote: > > p.s. if min(a,b,c,d,e) is the same as min([a,b,c,d,e]), then what is the > meaning of min([a,b,c,d,e], [g,h,i,j,k])? Why, [(a,g), (b,h), (c,i), (d,j), (e,k)], of course. killing two birds with one (planet-sized) stone, -- ?!ng From huaiyu_zhu at yahoo.com Fri Jul 14 18:51:59 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 09:51:59 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <20000714162017.B7340@xs4all.nl> Message-ID: > > (X'*X)\(X'*y) > > > (What does the backslash mean? What does the tick mark mean? > > At least solve() is clear, and if i understood what H() stood > > for, it would mean more than a tick mark.) > > More importantly, how are they grouped ? Is '* a single operator, or is ' a > binary operator and * an unary operator ? Or is ' a postfix unary operator > and * the binary operator ? Does the backslash escape the opening paren for > some reason, or is it an operator on its own ? > > Oh, wait, I see it now ! It's a string literal of the new 'X' type, > containing '*X)\(X', multiplied by y! I wonder what that 'X' type string > is... Maybe a built-in regular expression ? What does this mean? s = 1.2; g = 4.4; t = 6. a = s/2 + t/3 + 1/g Ah, that means a is the operation that globally substitute '2' followed by one or more space followed by ' t' with string '3 + 1'. :-) It seems many in this list visually parse an expression in the following order, arithmetic, structure, user defined. However, for anyone who's done any numerical computation, matrix is part of arithmetic, with as much justification as complex numbers (theoretically even more justification). Whether it's user defined or built in, it has the same precedence as arithmetic. Imagine if users are forced to write the above as a = add(add(div(s,2), div(t,3)), div(1,g)) to avoid confusion with regular expression! When we talk about CP4E, don't forget math 4E. And matrix is pivotal to that goal. As to the original expression in matlab, ' is a postfix operator and \ is an ordinary binary operator, as in undergraduate math books. Huaiyu From paul at prescod.net Fri Jul 14 18:51:12 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 11:51:12 -0500 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE6B3.B86BED76@prescod.net> <14703.11095.264917.268373@bitdiddle.concentric.net> Message-ID: <396F4500.E80ABB39@prescod.net> Jeremy Hylton wrote: > > ... > > Seriously -- you've already seen Guido's response. I think there's no > chance of adding third-party code to the Python CVS repository or > source distribution. The only way I could imagine it happening is if > there was strong consensus from the XML SIG. So Greg's suggestion is > a good one. I don't see the XML SIG overriding/convincing Guido on that issue, so it wasn't really the issue I was asking about. I need to know what sorts of packages Python's maintainers are willing to adopt. As extreme examples, if I write a 50,000 line persistence package that many people asked for, would it go into Python? If I write an extension module in Pascal, could that go into Python? Obviously the 4XPath example is not that extreme so I'm trying to get opinions. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 18:51:21 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 11:51:21 -0500 Subject: [Python-Dev] linear algebra References: Message-ID: <396F4509.30069096@prescod.net> Greg Wilson wrote: > > .... Saying, "But you don't have to use these new operators if > you don't want to," is a red herring --- if I want to understand/modify > other people's code, I'll have to learn 'em (just as I've had to learn > most of Perl's syntax, one painful special case at a time, in order to use > the LDAP, XML, CGI, and imaging libraries). > > So: I would like this (linear algebra, min/max, other notation) to happen, > but only if there's an extensible, scalable framework for user-defined > libraries to add operators to Python, in the same way that they can now > add new classes. I don't want to come to someone else's code and have to learn a bunch of operators that they invented, for the same reason that you don't want to learn all of Perl's built-in special cases. I would support a framework to compile and load well-defined, independent, Python-based languages (PyMatrix, XSLPy) onto a shared Python virtual machine. OTOH, I would freak out if I loaded a module that proported to be Python and found it had a bunch of operators not defined in the Python specification. I'll leave that experiment to REBOL and see what happens. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 18:56:54 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 11:56:54 -0500 Subject: [Python-Dev] Request for Opinions References: <200007140516.HAA28633@python.inrialpes.fr> <396EE66F.59D0D45F@prescod.net> <14703.14352.411905.934970@cj42289-a.reston1.va.home.com> Message-ID: <396F4656.6396D7C8@prescod.net> "Fred L. Drake, Jr." wrote: > > I think a PEP and further discussions in the XML-SIG are in order > before we add more material into the standard library. I'm firmly > committed to getting the "right stuff" in there, but I don't want to > rush headlong into adding things before they're ready and agreed > upon. My impression was that we discussed this in the SIG last week but the discussion petered out when we realized that none of us knew whether it was even feasible to add something the size of 4XPath to Python. Nobody could say it would or would not be a problem which makes planning impossible and further discussion a useless cycle of "wouldn't it be nice, but it may or may not be possible, but wouldn't it be nice, but it may or may not be ...". -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From fdrake at beopen.com Fri Jul 14 19:06:43 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 13:06:43 -0400 (EDT) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396F4656.6396D7C8@prescod.net> References: <200007140516.HAA28633@python.inrialpes.fr> <396EE66F.59D0D45F@prescod.net> <14703.14352.411905.934970@cj42289-a.reston1.va.home.com> <396F4656.6396D7C8@prescod.net> Message-ID: <14703.18595.926991.596182@cj42289-a.reston1.va.home.com> Paul Prescod writes: > My impression was that we discussed this in the SIG last week but the > discussion petered out when we realized that none of us knew whether it > was even feasible to add something the size of 4XPath to Python. Nobody > could say it would or would not be a problem which makes planning Then this falls into the "Fred's falling behind on his email again" category, and my remarks can be safely ignored until I've done my homework. Sorry for the confusion. ;( But I still think a PEP documenting the rationale for any decision is valuable. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From huaiyu_zhu at yahoo.com Fri Jul 14 19:11:29 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 10:11:29 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: Message-ID: On Fri, 14 Jul 2000, Ka-Ping Yee wrote: > > You are almost there. :-) The current MatPy expression is > > solve (X.H() * X, X.H() * y) > > I was about to suggest something similar, but you beat me to it. > > I think that expression looks great. If you can say it that > concisely, i don't think you need to throw in extra operators > at all (let alone a half-dozen of them that are incomprehensible > to anyone outside of the Matlab community). Well, the Matlab community includes most scientists and enginears and educators and students of science and engineering who can afford Matlab, or who has enough computer literacy to know how to install Octave (or to install Linux so that Octave comes with it). Many are learning Linux just for this purpose alone. At least several of my former students did. Back to topic. Here's the quote from my c.l.py post: This is not a call for a special language for matrix only. But we do need enough binary operators to override with. The additional operators might be useful at other places as well. In matlab the following operations are all different from each other a+b a.+b a-b a.-b a*b a.*b a/b a./b a\b a.\b a^b a.^b What python operators can we override for them all? Just one additional symbol for so many new binary operators is a good bargain, IMO. I think cleanness is one of the main virtue of python, but it is lacking in numerical computation. To give an example of the difference it makes, I'll quote from my original post asking for matrix in python (with corrections) [example of matlab and python codes you've seen. end quote] So why do we need new operators? Because we are using * as matrixmultiply so we need .* as elementwise multiply. From esr at thyrsus.com Fri Jul 14 19:36:20 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 13:36:20 -0400 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: ; from huaiyu_zhu@yahoo.com on Fri, Jul 14, 2000 at 10:11:29AM -0700 References: Message-ID: <20000714133620.A10054@thyrsus.com> Huaiyu Zhu : > This is not a call for a special language for matrix only. But we do need > enough binary operators to override with. The additional operators might be > useful at other places as well. > > In matlab the following operations are all different from each other > > a+b a.+b > a-b a.-b > a*b a.*b > a/b a./b > a\b a.\b > a^b a.^b > > What python operators can we override for them all? Just one additional > symbol for so many new binary operators is a good bargain, IMO. Put this way, I'm more inclined to support it. I might even be tempted to add .| and .& for lattice algebras. I agree that supporting user-defined syntax threatens to fragment the language. To avoid that, perhaps it would be best to leave what are in effect user-definable hooks in Python's lexical space. This could address Greg's desire for an infix max and min as well. The design question becomes: what undefined binary tokens do we want to add the the language core? With what precedence? What is the compiler to assume about associativity? -- Eric S. Raymond Ideology, politics and journalism, which luxuriate in failure, are impotent in the face of hope and joy. -- P. J. O'Rourke From effbot at telia.com Fri Jul 14 19:36:16 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 19:36:16 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <036101bfedba$048fdbe0$f2a6b5d4@hagrid> before this goes out of hand, let me just say that there might be good reasons for adding more operators for Python, but your "why cannot I have special syntax when everyone else got it" approach doesn't really work: > What does this mean? > > s = 1.2; g = 4.4; t = 6. > a = s/2 + t/3 + 1/g > > Ah, that means a is the operation that globally substitute '2' followed by > one or more space followed by ' t' with string '3 + 1'. :-) huh? Python doesn't support the s/// syntax (you're thinking about Perl or awk, right?) ...and: > a\b a.\b huh? Python doesn't have a backslash operator. ...and: > Look it this way. Text processing do have their special syntaxes. A string > is written as "string" instead of ['s','t','r','i','n','g']. huh? Python doesn't have a character type (C, C++) > There is even the new sep.join(list). huh? that's a method call, not special syntax... > If we had requested that new syntax for Fourier analysis or fractal > generation that would be comparable to text processing or COM. huh? Python doesn't have special syntax for text processing (Perl, Icon) or COM (C#, Visual Basic) if you cannot get your Python facts right, why should I trust you when you say that "Python needs this or that"? From effbot at telia.com Fri Jul 14 19:54:43 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 19:54:43 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> Message-ID: <038101bfedbc$983c81c0$f2a6b5d4@hagrid> guido wrote: > Need some more analysis of what format codes are actually used, > and support for %.200s which is currently used often. possibly stupid idea: would it make sense to add custom formatting codes, like: %S => char*, string, clip if excessively long %T => PyObject*, show name of type, clip if excessively long where "clip" means: truncate at 80 characters, and add "..." to indicate that the string was truncated. this covers most of the places where %.\d+s are used (in the Python core, at least...) From gvwilson at nevex.com Fri Jul 14 19:48:50 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 13:48:50 -0400 (EDT) Subject: [Python-Dev] Re: linear algebra In-Reply-To: <396F4509.30069096@prescod.net> Message-ID: > > Greg Wilson wrote: > > > > .... Saying, "But you don't have to use these new operators if > > you don't want to," is a red herring --- if I want to understand/modify > > other people's code, I'll have to learn 'em (just as I've had to learn > > most of Perl's syntax, one painful special case at a time, in order to use > > the LDAP, XML, CGI, and imaging libraries). > > > > So: I would like this (linear algebra, min/max, other notation) to happen, > > but only if there's an extensible, scalable framework for user-defined > > libraries to add operators to Python, in the same way that they can now > > add new classes. > Paul Prescod wrote: > > I don't want to come to someone else's code and have to learn a bunch > of operators that they invented, for the same reason that you don't > want to learn all of Perl's built-in special cases. Greg Wilson writes: I strongly agree. If there isn't a "new operator definition" mechanism that maintains Python's simplicity, then I believe we should stick to functions and methods, rather than introducing "just a few" new operators for linear algebra (or regular expressions, or [your favorite topic goes here]). > Eric Raymond wrote: > > I agree that supporting user-defined syntax threatens to fragment the > language. To avoid that, perhaps it would be best to leave what are in > effect user-definable hooks in Python's lexical space. > > The design question becomes: what undefined binary tokens do we want > to add the the language core? With what precedence? What is the > compiler to assume about associativity? This is an interesting alternative I hadn't thought of --- add operators, with associated special methods and in-place assignment forms, but do not provide a "standard" definition (i.e. leave all functionality open to the user). Thanks, Greg From paul at prescod.net Fri Jul 14 20:02:09 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 13:02:09 -0500 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: <20000714133620.A10054@thyrsus.com> Message-ID: <396F55A1.10828D06@prescod.net> "Eric S. Raymond" wrote: > > ... > > I agree that supporting user-defined syntax threatens to fragment the language. > To avoid that, perhaps it would be best to leave what are in effect > user-definable hooks in Python's lexical space. I really don't see how it is better to fragment the semantic space by encouraging people to project random meanings onto operators with no intrinsic meanings. Given the choice, I would prefer to have the language explicitly fragment into domain-specific variants with their own grammars. At least then I know that I'm really dealing with a new language that is Pythonic, but not Python. DTML, a Python XSL and this matrix Python are examples of languages that might benefit from an easy way to be hosted on the Python VM and interact with pure Python modules. Also a statically typed Python variant might be intersting. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From akuchlin at mems-exchange.org Fri Jul 14 20:02:36 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 14 Jul 2000 14:02:36 -0400 Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: <20000714133620.A10054@thyrsus.com>; from esr@thyrsus.com on Fri, Jul 14, 2000 at 01:36:20PM -0400 References: <20000714133620.A10054@thyrsus.com> Message-ID: <20000714140236.H28819@kronos.cnri.reston.va.us> On Fri, Jul 14, 2000 at 01:36:20PM -0400, Eric S. Raymond wrote: >Huaiyu Zhu : >> This is not a call for a special language for matrix only. But we do need >> enough binary operators to override with. The additional operators might be >> useful at other places as well. > >I agree that supporting user-defined syntax threatens to fragment the language. >To avoid that, perhaps it would be best to leave what are in effect >user-definable hooks in Python's lexical space. Huaiyu Zhu thinks that better matrix operators will attract a significant new of new users; I'm doubtful of this claim. We're both just guessing, since neither of us has actual evidence to support our respective points of view. Given that uncertainty, there seems little impetus for adding new operators; Python will have to live with them for a long time, even if the matrix work withers after a short time, or never really catches on. It should be possible to try out new operators *right now*, with no core changes. I believe Jeremy's compiler code, written in pure Python, can parse a module and generate the corresponding bytecodes. Therefore, you could take that code and hack it to support 'a .| b', by generating equivalent code to a.__dotbar__(b), or whatever. The only visible difference is that some error messages would be obscure; 2 .| 1 would get a '2 has no attribute __dotbar__' exception; this isn't significant. So, rather than add a whole bunch of new operators to the core, I'd first want to see the alternative syntax implemented through a hacked parser and *in use by a significant community*, and then we can consider what bits from it to add to the core. --amk From esr at thyrsus.com Fri Jul 14 20:47:12 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 14:47:12 -0400 Subject: [Python-Dev] Re: linear algebra In-Reply-To: ; from gvwilson@nevex.com on Fri, Jul 14, 2000 at 01:48:50PM -0400 References: <396F4509.30069096@prescod.net> Message-ID: <20000714144712.A10278@thyrsus.com> Greg Wilson : > This is an interesting alternative I hadn't thought of --- add operators, > with associated special methods and in-place assignment forms, but do not > provide a "standard" definition (i.e. leave all functionality open to the > user). Yes. This steers a Pythonic middle path between user-definable syntax (too big a can of worms) and doing nothing at all to help out constituencies like the MatLab people. Overloading otherwise undefined special method names for operators is a well-understood way to add functionality to classes. Lrt's use it. -- Eric S. Raymond Rapists just *love* unarmed women. And the politicians who disarm them. From jeremy at beopen.com Fri Jul 14 20:40:43 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 14:40:43 -0400 (EDT) Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: <20000714140236.H28819@kronos.cnri.reston.va.us> References: <20000714133620.A10054@thyrsus.com> <20000714140236.H28819@kronos.cnri.reston.va.us> Message-ID: <14703.24235.5194.840166@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> It should be possible to try out new operators *right now*, AMK> with no core changes. I believe Jeremy's compiler code, AMK> written in pure Python, can parse a module and generate the AMK> corresponding bytecodes. Therefore, you could take that code AMK> and hack it to support 'a .| b', by generating equivalent code AMK> to a.__dotbar__(b), or whatever. The only visible difference AMK> is that some error messages would be obscure; 2 .| 1 would get AMK> a '2 has no attribute __dotbar__' exception; this isn't AMK> significant. There is one hitch. There is a corresponding bytecode op for each of the builtin operators. When Python sees 'm * x + b', it generates BINARY_MULTIPLY and BINARY_ADD opcode. If you wanted to add a new binary operator, you couldn't add a new opcode for it. Instead, you'd have to generate explicit instructions to check for the attr and then call it. This isn't a big problem, although the resulting interpreter is probably slower than one with builtin opcodes. Not sure how much slower. AMK> So, rather than add a whole bunch of new operators to the core, AMK> I'd first want to see the alternative syntax implemented AMK> through a hacked parser and *in use by a significant AMK> community*, and then we can consider what bits from it to add AMK> to the core. This seems like a reasonable approach to me. You basically build a frontend that compiles the Python+extensions into standard Python bytecode. Jeremy From moshez at math.huji.ac.il Fri Jul 14 20:41:27 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 21:41:27 +0300 (IDT) Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: <14703.24235.5194.840166@bitdiddle.concentric.net> Message-ID: On Fri, 14 Jul 2000, Jeremy Hylton wrote: > AMK> So, rather than add a whole bunch of new operators to the core, > AMK> I'd first want to see the alternative syntax implemented > AMK> through a hacked parser and *in use by a significant > AMK> community*, and then we can consider what bits from it to add > AMK> to the core. > > This seems like a reasonable approach to me. You basically build a > frontend that compiles the Python+extensions into standard Python > bytecode. Wouldn't it be better to compile the Python+extensions into standard Python? Something that would work at the parse tree level? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From jeremy at beopen.com Fri Jul 14 20:49:24 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 14:49:24 -0400 (EDT) Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: References: <14703.24235.5194.840166@bitdiddle.concentric.net> Message-ID: <14703.24756.648338.160796@bitdiddle.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> On Fri, 14 Jul 2000, Jeremy Hylton wrote: AMK> So, rather than add a whole bunch of new operators to the core, AMK> I'd first want to see the alternative syntax implemented AMK> through a hacked parser and *in use by a significant AMK> community*, and then we can consider what bits from it to add AMK> to the core. >> This seems like a reasonable approach to me. You basically >> build a frontend that compiles the Python+extensions into >> standard Python bytecode. MZ> Wouldn't it be better to compile the Python+extensions into MZ> standard Python? Something that would work at the parse tree MZ> level? That's a lot of work! I'm not aware of any tools that generate Python source code from a parser tree. The Python bytecode is so high-level that it is pretty easy to understand. The parse tree generated by Python's builtin parser is really hard to work with. So it definitely makes sense to use the transformer that Greg & Bill wrote to get a decent abstract syntax. At that point, you can either generate bytecode directly or write a new code generate that generates source from the AST. Jeremy From alex_c at MIT.EDU Fri Jul 14 22:30:14 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Fri, 14 Jul 2000 16:30:14 -0400 (EDT) Subject: [Python-Dev] posixpath module. Message-ID: <200007142030.QAA156803@w20-575-116.mit.edu> (Cc'd to python-dev, this time, since you're incommunicado.) I have a preliminary version of test_posixpath.py. You can see it at http://puffin.lcs.mit.edu:8080/Lib/test/test_posixpath.py I don't have any negative tests with garbage input. I'm thinking that that's not so important anyway, because in python programs tend to break with garbage input, but of course I'm really punting mainly out of temporary boredom. :) Should posixpath.normpath resolve '/..' to '/'? My linux box does. Alex. From thomas at xs4all.net Fri Jul 14 22:36:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 22:36:08 +0200 Subject: [Python-Dev] posixpath module. In-Reply-To: <200007142030.QAA156803@w20-575-116.mit.edu>; from alex_c@MIT.EDU on Fri, Jul 14, 2000 at 04:30:14PM -0400 References: <200007142030.QAA156803@w20-575-116.mit.edu> Message-ID: <20000714223607.D7340@xs4all.nl> On Fri, Jul 14, 2000 at 04:30:14PM -0400, Alex Coventry wrote: > Should posixpath.normpath resolve '/..' to '/'? My linux box does. Yes. At least, every UNIX box I ever heard of does that, and I'm sure it's listed in some standard or other. (the '.' and '..' directories on UNIX filesystems aren't magic, they are just hard links to the appropriate directory. '..' on '/' simply points to the same directory as '.' on '/', and '/' itself.) I think the same goes for URLs, though I'm not as sure on that. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Fri Jul 14 22:48:45 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 16:48:45 -0400 (EDT) Subject: [Python-Dev] Patch Manager screen scraper Message-ID: <14703.31917.642280.604366@bitdiddle.concentric.net> I wrote a small script to extract patch meta data from the SourceForge patch manager and install them in a local Postgres database. This code might be useful for other folks, although the second half (the Postgres half) depends on having PyGreSQL installed. I'm posting the current source here in case anyone else wants to fiddle. It's definitely rough. Attached is the code and the DB schema. Jeremy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patchtool.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-schema.txt URL: From paul at prescod.net Fri Jul 14 22:56:52 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 15:56:52 -0500 Subject: [Python-Dev] posixpath module. References: <200007142030.QAA156803@w20-575-116.mit.edu> Message-ID: <396F7E94.FF4D4C0B@prescod.net> Alex Coventry wrote: > > (Cc'd to python-dev, this time, since you're incommunicado.) Skip is having computer problems. Lost computer problems. :) -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Fri Jul 14 23:02:30 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 23:02:30 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> <02c701bfedae$7db6fd20$f2a6b5d4@hagrid> Message-ID: <000d01bfedd7$122db480$f2a6b5d4@hagrid> > patch coming. not quite ready to be checked in, but good enough to take on a test drive: http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From gstein at lyra.org Fri Jul 14 23:18:02 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 14:18:02 -0700 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007141714.MAA14470@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 12:14:44PM -0500 References: <396E0B9B.DD74EF5@interet.com> <200007141437.JAA13178@cj20424-a.reston1.va.home.com> <01b201bfedac$12353d20$f2a6b5d4@hagrid> <200007141714.MAA14470@cj20424-a.reston1.va.home.com> Message-ID: <20000714141801.T29590@lyra.org> On Fri, Jul 14, 2000 at 12:14:44PM -0500, Guido van Rossum wrote: > > > Ignoring most that's been said in this thread, would it be possible > > > for the installer to detect the presence of python15.dll in the system > > > directory and offer to delete it? > > > > would the average user know when to click "Yes" ? > > Whenever they don't have a 1.5 installation that they are interested > in preserving. Hm, the registry probably points to where that would > live if it existed, so the installer (or a custom program run > automatically by it) can do more probing if it needs to. Who says they have a 1.5 installation on their system? Maybe the DLL arrived through some third-party application that happens to use/embed Python. Any python*.dll probably should be ignored. Cheers, -g -- Greg Stein, http://www.lyra.org/ From huaiyu_zhu at yahoo.com Fri Jul 14 23:28:09 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 14:28:09 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <036101bfedba$048fdbe0$f2a6b5d4@hagrid> Message-ID: On Fri, 14 Jul 2000, Fredrik Lundh wrote: > before this goes out of hand, let me just say that there might be good > reasons for adding more operators for Python, but your "why cannot I > have special syntax when everyone else got it" approach doesn't really > work: > Well, these quotings are getting out of hand. Please read the c.l.py thread and see where all this comes from. My posts have been repeatedly forwarded here out of context. Note that the (X'*X)\(X'*y) syntax is Matlab, not python. I mentioned text processing and COM because it was claimed that requesting additional binary operators for matrix is similar to requesting special syntax for text processing and COM. I have repeatedly stated here and elsewhere, that I do NOT want special syntax. I only want a few more binary operators that bear resemblance to the existing ones. I want them in such a way that as long as you do not use them, NOTHING would be changed. However several people continuously said: you cannot get that because that's too much of a request, however you should get your own complete parser so that you can make any syntax as you want, even if it is incompatible. I find this very strange. Maybe the audience here do not appreciate it, but "matrix people" are not some aliens, and matrix computation need to be compatible with everything else in python. If I'm only going to do matrix but nothing else, why wouldn't I just stick with octave? > if you cannot get your Python facts right, why should I trust you > when you say that "Python needs this or that"? Maybe if you read all the original posts you would find these "wrong facts" just disappears. You might also find that many people did not get the fact right about what is being asked in these threads. One sure way to get the facts right is to get MatPy, unar, type make install, and see what you get. It's not that difficult, at least easier than writing these emails. Huaiyu -- Huaiyu Zhu hzhu at users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net From huaiyu_zhu at yahoo.com Sat Jul 15 00:04:52 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 15:04:52 -0700 (PDT) Subject: [Fwd: Re: [Python-Dev] Introducing new operators for matrix computation] In-Reply-To: <396F5819.D3C20E40@prescod.net> Message-ID: I like this idea as well. I only need to clarify two things: 1. Is this available right now? Where to get it? 2. Will this be guaranteed to be compatible with future development of python? My doubt is: If this is the case why the augmented assinment needs to be a patch? The development of MatPy has been quite rapid since it started over a month ago. Right now we are ready to go into feature addition phase that will be even faster. The only uncertainty is what operators we will have. We got our own patch yesterday. We'd like to settle on this very quickly. Once these are settled, we'll just included it in the MatPy distribution. After we get enough usage the whole NumPy-MatPy packages might be included in core python just as string or re. Given that there is a conference next week, perhaps we can't fix it in a week. But we'll decide soon after that. I will not argue any more here about how many new users python may attract with matrix. With proper tools I would be able to prove by fact. Although we seek the core developer opinions here, we do not really need approval to go ahead. But the danger is that a bad choice may stuck with python for ever when this thing gets incorporated into main distribution. Switching the meaning of the operators would be almost completely impossible, unlike the regex and re case. So even if you don't make use of matrix now, you might still want to give a thought on how it should be done. Huaiyu On Fri, 14 Jul 2000, Paul Prescod wrote: > I like this idea! > > -------- Original Message -------- > Subject: Re: [Python-Dev] Introducing new operators for matrix > computation > Date: Fri, 14 Jul 2000 14:02:36 -0400 > From: Andrew Kuchling > Reply-To: akuchlin at mems-exchange.org > To: python-dev at python.org > References: > > <20000714133620.A10054 at thyrsus.com> > > On Fri, Jul 14, 2000 at 01:36:20PM -0400, Eric S. Raymond wrote: > >Huaiyu Zhu : > >> This is not a call for a special language for matrix only. But we do need > >> enough binary operators to override with. The additional operators might be > >> useful at other places as well. > > > >I agree that supporting user-defined syntax threatens to fragment the language. > >To avoid that, perhaps it would be best to leave what are in effect > >user-definable hooks in Python's lexical space. > > Huaiyu Zhu thinks that better matrix operators will attract a > significant new of new users; I'm doubtful of this claim. We're both > just guessing, since neither of us has actual evidence to support our > respective points of view. Given that uncertainty, there seems little > impetus for adding new operators; Python will have to live with them > for a long time, even if the matrix work withers after a short time, > or never really catches on. > > It should be possible to try out new operators *right now*, with no > core changes. I believe Jeremy's compiler code, written in pure > Python, can parse a module and generate the corresponding bytecodes. > Therefore, you could take that code and hack it to support 'a .| b', > by generating equivalent code to a.__dotbar__(b), or whatever. The > only visible difference is that some error messages would be obscure; > 2 .| 1 would get a '2 has no attribute __dotbar__' exception; this > isn't significant. > > So, rather than add a whole bunch of new operators to the core, I'd > first want to see the alternative syntax implemented through a hacked > parser and *in use by a significant community*, and then we can > consider what bits from it to add to the core. > > --amk > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From alex_c at MIT.EDU Sat Jul 15 00:08:39 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Fri, 14 Jul 2000 18:08:39 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <396F7E94.FF4D4C0B@prescod.net> (message from Paul Prescod on Fri, 14 Jul 2000 15:56:52 -0500) References: <200007142030.QAA156803@w20-575-116.mit.edu> <396F7E94.FF4D4C0B@prescod.net> Message-ID: <200007142208.SAA157802@w20-575-116.mit.edu> > Skip is having computer problems. Lost computer problems. :) Yeah, sorry, that's what I meant. :) Alex. From fdrake at beopen.com Sat Jul 15 00:26:49 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 18:26:49 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <200007142030.QAA156803@w20-575-116.mit.edu> References: <200007142030.QAA156803@w20-575-116.mit.edu> Message-ID: <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> Alex Coventry writes: > I don't have any negative tests with garbage input. I'm thinking that > that's not so important anyway, because in python programs tend to break > with garbage input, but of course I'm really punting mainly out of > temporary boredom. :) If an exception is expected, it should test that it gets the right failure. This is especially important in a regression test, so that failing cases don't silently becoming non-failing cases. > Should posixpath.normpath resolve '/..' to '/'? My linux box does. I don't understand; in what context? "/" on my box contains "..", which is itself. There's nothing special about it in the "path algebra," but it may be a useful reduction. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From huaiyu_zhu at yahoo.com Sat Jul 15 00:44:20 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 15:44:20 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <20000714133620.A10054@thyrsus.com> Message-ID: On Fri, 14 Jul 2000, Eric S. Raymond wrote: > Huaiyu Zhu : > > This is not a call for a special language for matrix only. But we do need > > enough binary operators to override with. The additional operators > > might be useful at other places as well. > > > > In matlab the following operations are all different from each other > > > > a+b a.+b > > a-b a.-b > > a*b a.*b > > a/b a./b > > a\b a.\b > > a^b a.^b > > > > What python operators can we override for them all? Just one additional > > symbol for so many new binary operators is a good bargain, IMO. > > Put this way, I'm more inclined to support it. I might even be tempted > to add .| and .& for lattice algebras. > > I agree that supporting user-defined syntax threatens to fragment the > language. To avoid that, perhaps it would be best to leave what are in > effect user-definable hooks in Python's lexical space. Completely agree. That's what the issue is about. More information is given below in my quote from c.l.p. > This could address Greg's desire for an infix max and min as well. > > The design question becomes: what undefined binary tokens do we > want to add the the language core? With what precedence? What is > the compiler to assume about associativity? Given what's quoted below, would you think . is the best choice? Not to say its attractiveness to all the matlab crowd. ------------------------ start quote ----------------------------- On Thu, 13 Jul 2000 16:35:57 -0600, Bjorn Pettersen wrote: >I fully understand your desire to make the syntax for your domain >specific notation as intuitive as possible. For people who don't know >matlab however, .+ et. al. have no pre-defined meaning. Since + has a >predefined meaning of addition, most people when overloading it will do >"additive" things with it, e.g. concatenating to sequences. Since .+ >doesn't have a pre-defined meaning I'm afraid people will override it >with random semantics... > >If you want to do matlab syntax, perhaps a better approach would be to >write your own expression parser? > Hmm, I see what you mean: If a certain syntax is not meaningful to all the users, don't expose it to all of them lest they came up with random incompatible usages. Sounds reasonable, but ... Point 1. We _can_ assign a universal meaning to dot operators, as "componentwise operators". For example [1, 2] + [3, 4] # [1, 2, 3, 4] [1, 2] .+ [3, 4] # [4, 6] ['a','b'] * 2 # ['a','b','a','b'] ["a","b"] .* 2 # ['aa', 'bb'] {'a':1, 'b':1} .+ {'a':1, 'c':1} # {'a':2, 'b':1, 'c': 1} 'abc' .+ 'def' # exception: you must define string.__dot_add__ This could be useful in all sorts of situations. Of course people can still override it with incompatible meanings at their own discretion, just as they could do to anything else. Point 2. If users in completely disjoint domains override a certain type of binary operators with incompatible meanings, is there great harm? Providing a few operators for user adoptation might even prevent grotesque overriding of more core operators. After all, there is almost endless supply of names for classes, modules, function and so on, but there is almost no binary operators free for adoption. Point 3. A special parser could work, (and if the patch under discussion is not accepted we'll just keep it around for use with matrix computation), as long as it is made quite orthogonal to other parts of the language. This way people using it will not be left behind other developments of the language. However, I still think a unified parser with overridable operators present a smaller risk of fragmentation. Huaiyu From alex_c at MIT.EDU Sat Jul 15 00:42:49 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Fri, 14 Jul 2000 18:42:49 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> (fdrake@beopen.com) References: <200007142030.QAA156803@w20-575-116.mit.edu> <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> Message-ID: <200007142242.SAA12205@mint-square.mit.edu> > If an exception is expected, it should test that it gets the right > failure. This is especially important in a regression test, so that > failing cases don't silently becoming non-failing cases. You're right, of course. I'll get back to them at some point. > in what context? "/" on my box contains "..", which is itself. > There's nothing special about it in the "path algebra," but it may > be a useful reduction. For instance: >>> import posixpath >>> posixpath.normpath('/..') '/..' I would have thought '/' would be a better result to return. My impression was that normpath is used to tell whether two paths are actually the same, and if that's the case, its current behaviour is going to give false negatives. On the other hand, the code seems to explicitly ignore multiple leading /'s, and that will also give some false mismatches, so I must be confused somewhere... Alex. From effbot at telia.com Sat Jul 15 01:06:41 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 01:06:41 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <000901bfede8$2d0103a0$f2a6b5d4@hagrid> Huaiyu Zhu wrote: > Given what's quoted below, would you think . is the best choice? if what you're saying means that: >>> 1.+2. 3.0 becomes: >>> 1.+2. Traceback (innermost last): File "", line 1, in ? TypeError: __dotadd__ nor __rdotadd__ defined for these operands it's clearly not a good choice. From huaiyu_zhu at yahoo.com Sat Jul 15 01:33:13 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 16:33:13 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <000901bfede8$2d0103a0$f2a6b5d4@hagrid> Message-ID: On Sat, 15 Jul 2000, Fredrik Lundh wrote: > Huaiyu Zhu wrote: > > Given what's quoted below, would you think . is the best choice? > > if what you're saying means that: > > >>> 1.+2. > 3.0 > > becomes: > > >>> 1.+2. > Traceback (innermost last): > File "", line 1, in ? > TypeError: __dotadd__ nor __rdotadd__ defined for these operands > > it's clearly not a good choice. > > > To quote from my c.l.py post: On Fri, 14 Jul 2000 11:38:51 -0600, Bjorn Pettersen wrote: > >Well, this could actually be generally useful, but not with the .+ >syntax (since the dot would interfer with methods on the sequence >object). My impression from the python-dev list is that this is not the case. Some say it is easy to distinguish a. + b a .+ b Some say it is difficult. But the first is a syntax error anyway. The only real danger is 3. + a 3 .+ a But in this case pointwise operation does not make sense. So I suppose the following rules would resolve all the ambiguities: Dot binds with preceding number. Otherwise it binds with following operator. Otherwise it is a member indicator. Otherwise it is syntax error. Examples: 2.+b a.+b <-- only this is new a.b a.3 Huaiyu From fdrake at beopen.com Sat Jul 15 01:52:50 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 19:52:50 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <200007142242.SAA12205@mint-square.mit.edu> References: <200007142030.QAA156803@w20-575-116.mit.edu> <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> <200007142242.SAA12205@mint-square.mit.edu> Message-ID: <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> Alex Coventry writes: > I would have thought '/' would be a better result to return. My I agree, feel free to propose a patch! > impression was that normpath is used to tell whether two paths are > actually the same, and if that's the case, its current behaviour is > going to give false negatives. On the other hand, the code seems to > explicitly ignore multiple leading /'s, and that will also give some > false mismatches, so I must be confused somewhere... I'd call that a bug until someone can justify the current behavior. I'd love to see a patch for that as well. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From huaiyu_zhu at yahoo.com Sat Jul 15 02:09:20 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 17:09:20 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <036101bfedba$048fdbe0$f2a6b5d4@hagrid> Message-ID: On Fri, 14 Jul 2000, Fredrik Lundh wrote: > > is written as "string" instead of ['s','t','r','i','n','g']. > > huh? Python doesn't have a character type (C, C++) Likewise, matlab doesn't have a number type, only matrices. Generalization from number to matrix is definitely a smaller step than generalization from character to string. Matrix is more suitable for a builtin type than complex number is, because it is conceptually much simpler. The whole field of linear algebra is built on eight statements, two of them can be derived from the other. You can't even define all the concepts like upper or lower case, white space, tab, symbol, character and number and identifier and concatenation and so on in just eight statements, let alone to state all the rules of text processing. The issue arises because one generalization is more familiar to one group of people but the other is to other people. And people tend to regard what they are not familiar with as "specific domain". Huaiyu From moshez at math.huji.ac.il Sat Jul 15 02:43:42 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 03:43:42 +0300 (IDT) Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: <14703.24756.648338.160796@bitdiddle.concentric.net> Message-ID: On Fri, 14 Jul 2000, Jeremy Hylton wrote: > I'm not aware of any tools that generate Python > source code from a parser tree. Sounds like an interesting project. Hmmmm....another item on the todo list. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From HZhu at knowledgetrack.com Sat Jul 15 03:42:11 2000 From: HZhu at knowledgetrack.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 18:42:11 -0700 (PDT) Subject: [Python-Dev] List comprehension syntax Message-ID: I just read the whole thread on list comprehension. Here's my proposed syntax, given by examples. This notation is very safe as it has been used in mathematics for years. a = [1, 2, 3]; b = [4, 5, 6] #---------------------------------------------------- # Parallel loops: c = tuples(a,b) # c = [(1,4), (2,5), (3,6)] c = lists(a,b) # c = [[1,4], [2,5], [3,6]] c = xtuples(a,b) # c = ((1,4), (2,5), (3,6)) c = xlists(a,b) # c = ([1,4], [2,5], [3,6]) #---------------------------------------------------- # prefix x has the same effect as in xrange in loops for pair in xtuples(a,b): print pair # print (1,4); print (2,5); print (3,6) for pair in xtuples(a,b): print pair # print [1,4]; print [2,5]; print [3,6] for i, j in xlists(a,b): pass #---------------------------------------------------- # list comprehension - all elements that satisfy conditions c = [x*2, y: x, y in xtuples(a,b)] # c = [(2,4), (4,5), (6,6)] c = [[x, y]: x, y in xtuples(a,b)] # c = [[1,4], [2,5], [3,6]] c = [x: x in a+b; x%2=0] # c = [2, 4, 6] c = [x in a+b: x%2=0] # ditto c = [x,y: x, y in xtuples(a,b); x>1; x+y<8] # c = [(2,5)] c = [x,y in xtuples(a,b): x>1; x+y<8] # ditto #---------------------------------------------------- # Corresponding to old syntax c = [x in a: f(x)] # c = filter(f, x) c = [f(x): x in a] # c = map(f, a) #---------------------------------------------------- # Iterated loops (all elements that satisfy condition): c = [x, y: x in a; y in b] # c = [(1,4), (1,5), (1,6), (2,4), (2,5), ...] c = [[x,y]: x in a; y in b] # c = [[1,4], [1,5], [1,6], [2,4], [2,5], ...] for i, j in [i, j: i in a; j in b]: print i, j # print 1,4; print 1,5; ... for i in a; j in b: print i, j # ditto -- Huaiyu Zhu hzhu at users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net From effbot at telia.com Sat Jul 15 10:46:28 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 10:46:28 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <001e01bfee39$2b738200$f2a6b5d4@hagrid> Huaiyu Zhu wrote: > The only real danger is > > 3. + a > 3 .+ a > > But in this case pointwise operation does not make sense. really? what if "a" is a froob? class froob: def __add__(self, other): return other + 1.0 def __dotadd__(self, other): return other + 1.0 >>> a = froob() >>> print 3+a() 4.0 >>> print 3.+a() SyntaxError: sorry, that doesn't make sense. try inserting a space. >>> print 3. + a() 4.0 >>> print 3.0+a() 4.0 From effbot at telia.com Sat Jul 15 10:49:57 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 10:49:57 +0200 Subject: [Python-Dev] Introducing new operators for matrix computation References: Message-ID: <004101bfee39$aa2d3820$f2a6b5d4@hagrid> moshe wrote: > Jeremy: > > > I'm not aware of any tools that generate Python > > source code from a parser tree. > > Sounds like an interesting project. Hmmmm....another item on the todo > list. http://bicyclerepair.sourceforge.net/ From huaiyu_zhu at yahoo.com Sat Jul 15 11:54:13 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Sat, 15 Jul 2000 02:54:13 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <001e01bfee39$2b738200$f2a6b5d4@hagrid> Message-ID: On Sat, 15 Jul 2000, Fredrik Lundh wrote: > > The only real danger is > > > > 3. + a > > 3 .+ a > > > > But in this case pointwise operation does not make sense. > > really? what if "a" is a froob? Really. Because 3 is a single point. It doesn't matter what a is. > >>> print 3.+a() > SyntaxError: sorry, that doesn't make sense. try inserting a space. Why isn't this 3. + a()? Hmm, I can see my bad habit of writing long posts so that they are often quoted only partially. Here's the missing half: So I suppose the following rules would resolve all the ambiguities: Dot binds with preceding number. Otherwise it binds with following operator. Otherwise it is a member indicator. Otherwise it is syntax error. Examples: 2.+b a.+b <-- only this is new a.b a.3 Huaiyu From effbot at telia.com Sat Jul 15 12:11:53 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 12:11:53 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <007e01bfee45$1a581ec0$f2a6b5d4@hagrid> > On Sat, 15 Jul 2000, Fredrik Lundh wrote: > > > > The only real danger is > > > > > > 3. + a > > > 3 .+ a > > > > > > But in this case pointwise operation does not make sense. > > > > really? what if "a" is a froob? > > Really. Because 3 is a single point. It doesn't matter what a is. you're inventing an entirely new language here. > > >>> print 3.+a() > > SyntaxError: sorry, that doesn't make sense. try inserting a space. > > Why isn't this 3. + a()? yeah, why? the answer is in the python documentation. > Hmm, I can see my bad habit of writing long posts so that they are often > quoted only partially. Here's the missing half: sure, I read the missing half. doesn't change a thing. please move further discussion to comp.lang.python. this discussion doesn't belong on python-dev. From paul at prescod.net Sat Jul 15 13:00:58 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 06:00:58 -0500 Subject: [Python-Dev] Re: linear algebra References: <396F4509.30069096@prescod.net> <20000714144712.A10278@thyrsus.com> Message-ID: <3970446A.318FDF4E@prescod.net> "Eric S. Raymond" wrote: > > ... > > > Overloading otherwise undefined special method names for operators is > a well-understood way to add functionality to classes. Lrt's use it. I don't know why you think that this is well-understood. Nevertheless, let's propose we add some fixed list of operators: .+ .* ./ .\ Would you propose that: "abc" .+ "c" => "abc".find( "c") "def" .* ".e." => re.match( "def", ".e." ) " " / ["a","b","c","d","e"] => " ".join( [...] ) "a b c" .\ " " => "a b c d e".split( " " ) To me, these bindings look like the kind of things I'd expect in P3rL, because the relationship between the syntax and the behavior is mostly random. In other words, you can't just invent a bunch of operators and THEN figure out how they are going to be used in various domains. You need to invent the operators *for* the domains. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Sat Jul 15 13:22:46 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 13:22:46 +0200 Subject: [Python-Dev] Re: linear algebra References: <396F4509.30069096@prescod.net> <20000714144712.A10278@thyrsus.com> <3970446A.318FDF4E@prescod.net> Message-ID: <000701bfee4f$01960820$f2a6b5d4@hagrid> paul wrote: > To me, these bindings look like the kind of things I'd expect in P3rL, > because the relationship between the syntax and the behavior is mostly > random. I saw cout being shifted "Hello world" times to the left and stopped right there. -- Steve Gonedes (which is the last I'm going to say on this topic. at least in public; I'll save the "over my dead body" stuff for guido's private mailbox). cheers /F From gstein at lyra.org Sat Jul 15 13:22:38 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 15 Jul 2000 04:22:38 -0700 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <007e01bfee45$1a581ec0$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jul 15, 2000 at 12:11:53PM +0200 References: <007e01bfee45$1a581ec0$f2a6b5d4@hagrid> Message-ID: <20000715042238.K29590@lyra.org> On Sat, Jul 15, 2000 at 12:11:53PM +0200, Fredrik Lundh wrote: >... > please move further discussion to comp.lang.python. this > discussion doesn't belong on python-dev. Fredrik -- I've been reading your notes a bit, and you're being antagonistic, belligerent, and unfair. I'm not sure it is called for. As for the discussion being here? It isn't his fault. Somebody *else* brought it here, and he is merely trying to respond to the questions and concerns that have been brought up in this forum. I think he has got every right to do that. You should chill out and back off. Cheers, -g -- Greg Stein, http://www.lyra.org/ From martin at loewis.home.cs.tu-berlin.de Sat Jul 15 14:32:59 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 15 Jul 2000 14:32:59 +0200 Subject: [Python-Dev] request for minor enhancement / linear algebra Message-ID: <200007151232.OAA18450@loewis.home.cs.tu-berlin.de> > I got there by working backwards to make things consistent. I want > overloadable '__min__' and 'min=', and everything else that has > these forms is binary infix (I think). If min was overloadable, it would fall in the same category as cmp, divmod, getattr, hasattr, hash, hex, int, len, long, oct, pow, repr, setattr, str the category being "overloadable builtins". Of those, cmp, divmod, getattr, hasattr, pow and setattr take more than one argument. divmod and pow are truly binary in the sense that both __foo__ and __rfoo__ are tried. So if min was overloadable, there would be no need for it being infix; it should attempt both __min__ and __rmin__, though. Actually, it shouldn't - instead, it should invoke __min__ on every argument. > '+', '*', and the bitwise operators are equally variadic --- is > confusion avoided by using punctuation for the infix binary form, > and a named function for the general form? An infix operator, by nature, cannot be variadic. 1+2+3 is not a single operation returning 6, but two operation invocations. Likewise, >>> import operator >>> operator.add(1,2,3) Traceback (most recent call last): File "", line 1, in ? TypeError: function requires exactly 2 arguments; 3 given Unlike that, min(1,2,3) *is* an atomic operation. If it was overloadable, I would *not* expect that first __min__(1,2) is computed, and then __min__(1,3). Instead, I'd expect it to be done as a whole. Now, the question is: if the first argument does not provide __min__, how exactly should __min__ be invoked on the other arguments? One solution would be that min(a,b,c) does a.__min__([a,b,c]) b.__min__([a,b,c]) c.__min__([a,b,c]) Regards, Martin From effbot at telia.com Sat Jul 15 15:57:03 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 15:57:03 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? Message-ID: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> as tim pointed out in an earlier thread (on SRE), the \xnn escape code is something of a kludge. I just noted that the unicode string type supports \x as well as \u, with slightly different semantics: \u -- exactly four hexadecimal characters are read. \x -- 1 or more hexadecimal characters are read, and the result is casted to a Py_UNICODE character. I'm pretty sure this is an optimal design, but I'm not sure how it should be changed: 1. treat \x as a hexadecimal byte, not a hexadecimal character. or in other words, make sure that ord("\xabcd") == ord(u"\xabcd") fwiw, this is how it's done in SRE's parser (see the python-dev archives for more background). 2. ignore \x. after all, \u is much cleaner. u"\xabcd" == "\\xabcd" u"\u0061" == "\x61" == "\x0061" == "\x00000061" 3. treat \x as an encoding error. 4. read no more than 4 characters. (a comment in the code says that \x reads 0-4 characters, but the code doesn't match that comment) u"\x0061bcd" == "abcd" 5. leave it as it is (just fix the comment). comments? From effbot at telia.com Sat Jul 15 16:09:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 16:09:25 +0200 Subject: [Python-Dev] decoding errors when comparing strings Message-ID: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> with the locale aware encoding mechanisms switched off (sys.getdefaultencoding() == "ascii"), I stumbled upon some interesting behaviour: first something that makes sense: >>> u"abc" == "abc" 1 >>> u"???" == "abc" 0 but how about this one: >>> u"abc" == "???" Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII decoding error: ordinal not in range(128) or this one: >>> u"???" == "???" Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII decoding error: ordinal not in range(128) ignoring implementation details for a moment, is this really the best we can do? From gmcm at hypernet.com Sat Jul 15 16:17:20 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 15 Jul 2000 10:17:20 -0400 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: References: <036101bfedba$048fdbe0$f2a6b5d4@hagrid> Message-ID: <1248451855-51961207@hypernet.com> Huaiyu Zhu wrote: > The whole field of linear algebra is built on eight statements, > two of them can be derived from the other. You can't even define > all the concepts like upper or lower case, white space, tab, > symbol, character and number and identifier and concatenation and > so on in just eight statements, let alone to state all the rules > of text processing. You claimed elsewhere that these arguments were quoted out of context, yet you bring them up again. So let's nail this, alright? Text processing doesn't use any new operators. It reuses some arithmetic operators. Everything else is done with methods or functions. If that's what a linear algebra extension used, there would be nothing to discuss. Or you could take something like the regex route: pyLinearAlgebra.evaluate(r'(X`*X)\(X`*y)', X=X, y=y) ... and there would be nothing to discuss. But you want new operators, and that's a can of worms. They need to be spelled sensibly and in a way that doesn't conflict with current Python punctuation / operators. They need precedence rules built into the grammar. If the precedence rules aren't right, the operators are damn near useless, because it will take so many parens to get the right result, you might as well be using one of the above techniques. > The issue arises because one generalization is more familiar to > one group of people but the other is to other people. And people > tend to regard what they are not familiar with as "specific > domain". Python isn't a matrix manipulation language. Like any language that does in-fix, adding operators is a tricky business and affects everybody, whether they know it or not. - Gordon From effbot at telia.com Sat Jul 15 17:46:02 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 17:46:02 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? Message-ID: <002101bfee73$c8531100$f2a6b5d4@hagrid> (except for the unicode object module, that is). as I've mentioned earlier, I'm working on an alternative unicode database, which includes a ucnhash replacement. my first thought was to emulate the existing api, but it has two small problems: -- it returns pointers into the database. this means that you cannot compress the names at all, if you want to be thread- safe (which you have to be, in this case). -- it exposes low-level implementation details, such as the hash table size, etc. I'm not sure if I can emulate that in any sane way under the new database design. so if nobody uses this, I'd rather change the unicodeobject.c file to use the new API directly... From thomas at xs4all.net Sat Jul 15 18:01:30 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 15 Jul 2000 18:01:30 +0200 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: <200007141505.KAA13385@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 10:05:39AM -0500 References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> <396E4746.DE25EFD4@prescod.net> <200007141505.KAA13385@cj20424-a.reston1.va.home.com> Message-ID: <20000715180130.H7340@xs4all.nl> On Fri, Jul 14, 2000 at 10:05:39AM -0500, Guido van Rossum wrote: > > If Guido has decided that the design that has already been implemented > > is the right one, what's the point of the PEP? Someone just needs to > > review the patch and check it in! > Right! Well, uhm, what now, then ? Should I finish PEP204 ? It's about half done, but throwing it away isn't a problem. I used it to get used to writing PEPs, anyway ;) I still have a question regarding the range literals patch, though, as I noted in the comment on SF: [...] the patch contains some code duplication (about the entire build_range function, plus get_len_of_range()) I'm not sure how to properly solve that: is it okay for compile.c to rely on something from bltinmodule.c ? If not, should I move the common functionality into listobject.c ? There is also the question regarding (::) and generators. Should I finish the PEP for the sake of that ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Sat Jul 15 18:10:03 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 19:10:03 +0300 (IDT) Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: <20000715180130.H7340@xs4all.nl> Message-ID: On Sat, 15 Jul 2000, Thomas Wouters wrote: > There is also the question regarding (::) and generators. Should I finish > the PEP for the sake of that ? I think we decided we don't need those. The only reason people need generators is for extra efficiency in for i in range(10^6): if i==5: break But the compiler can do that for the [::] version, since it's non-overridable. About the refactoring: my advice is to refactor first, and ask questions later <0.6 wink> -- after you mess with the code, just moving a function around takes about 3 seconds. (I'd put it in listobject.c first -- but just pick a place) From mal at lemburg.com Sat Jul 15 18:58:45 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 18:58:45 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> Message-ID: <39709844.595B84F6@lemburg.com> Fredrik Lundh wrote: > > as tim pointed out in an earlier thread (on SRE), the > \xnn escape code is something of a kludge. > > I just noted that the unicode string type supports \x > as well as \u, with slightly different semantics: > > \u -- exactly four hexadecimal characters are read. > > \x -- 1 or more hexadecimal characters are read, and > the result is casted to a Py_UNICODE character. \x is there in Unicode for compatibility with the 8-bit string implementation and in sync with ANSI C. Guido wanted these semantics when I asked him about it during the implementation phase. > I'm pretty sure this is an optimal design, but I'm not sure > how it should be changed: > > 1. treat \x as a hexadecimal byte, not a hexadecimal > character. or in other words, make sure that > > ord("\xabcd") == ord(u"\xabcd") > > fwiw, this is how it's done in SRE's parser (see the > python-dev archives for more background). > > 2. ignore \x. after all, \u is much cleaner. > > u"\xabcd" == "\\xabcd" > u"\u0061" == "\x61" == "\x0061" == "\x00000061" > > 3. treat \x as an encoding error. > > 4. read no more than 4 characters. (a comment in the > code says that \x reads 0-4 characters, but the code > doesn't match that comment) > > u"\x0061bcd" == "abcd" > > 5. leave it as it is (just fix the comment). I'd suggest 5 -- makes converting 8-bit strings using \x to Unicode a tad easier. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jul 15 19:03:30 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 19:03:30 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> Message-ID: <39709962.1C0A576E@lemburg.com> Fredrik Lundh wrote: > > (except for the unicode object module, that is). I don't think so... it's very new and the C API isn't documented. > as I've mentioned earlier, I'm working on an alternative unicode > database, which includes a ucnhash replacement. > > my first thought was to emulate the existing api, but it has two > small problems: > > -- it returns pointers into the database. this means that you > cannot compress the names at all, if you want to be thread- > safe (which you have to be, in this case). > > -- it exposes low-level implementation details, such as the hash > table size, etc. I'm not sure if I can emulate that in any sane > way under the new database design. > > so if nobody uses this, I'd rather change the unicodeobject.c > file to use the new API directly... Please don't drop the idea of an on-demand loadable module though. The current design used by Bill Tutt is to load the ucnhash module (which contains the mappings) only when it is needed -- most code won't need it. BTW, does you database use the on-demand loading feature ? I don't think that having the Unicode database linked statically in the Python interpreter is a good idea -- at least not until Unicode takes over ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Sat Jul 15 17:37:01 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 15 Jul 2000 10:37:01 -0500 (CDT) Subject: [Python-Dev] what to call this zip() function? In-Reply-To: References: Message-ID: <14704.34077.358194.82087@beluga.mojam.com> Nothing has really jumped out as the "right" way to express the proposed builtin that does map(None, l1, l2, l3, l4) How about collate? What we're doing is effectively what a copy machine does when it collates multiple copies of its input... Skip From mal at lemburg.com Sat Jul 15 19:15:05 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 19:15:05 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> Message-ID: <39709C19.A9A27625@lemburg.com> Fredrik Lundh wrote: > > with the locale aware encoding mechanisms switched off > (sys.getdefaultencoding() == "ascii"), I stumbled upon some > interesting behaviour: > > first something that makes sense: > > >>> u"abc" == "abc" > 1 > > >>> u"???" == "abc" > 0 > > but how about this one: > > >>> u"abc" == "???" > Traceback (most recent call last): > File "", line 1, in ? > UnicodeError: ASCII decoding error: ordinal not in range(128) > > or this one: > > >>> u"???" == "???" > Traceback (most recent call last): > File "", line 1, in ? > UnicodeError: ASCII decoding error: ordinal not in range(128) > > ignoring implementation details for a moment, is this really the > best we can do? This is merely due to the fact that on your Latin-1 platform, "?" and u"?" map to the same ordinals. The unicode-escape codec (which is used by the Python parser) takes single characters in the whole 8-bit range as Unicode ordinals, so u"?" really maps to unichr(ord("?")). The alternative would be forcing usage of escapes for non-ASCII Unicode character literals and issuing an error for all non-ASCII ones. BTW, I have a feeling that we should mask the decoding errors during compares in favour of returning 0... ...otherwise the current dictionary would bomb (it doesn't do any compare error checking !) in case a Unicode string happens to have the same hash value as an 8-bit string key. (Can't test this right now, but this is what should happen according to the C sources.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Sat Jul 15 19:24:56 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 12:24:56 -0500 Subject: [Python-Dev] decoding errors when comparing strings References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> Message-ID: <39709E68.820634C6@prescod.net> Fredrik Lundh wrote: > > ... > > but how about this one: > > >>> u"???" == "???" > Traceback (most recent call last): > File "", line 1, in ? > UnicodeError: ASCII decoding error: ordinal not in range(128) As soon as you find a character out of the ASCII range in one of the strings, I think that you should report that the two strings are unequal. We can't have exceptions popping out of dictionaries and other "blind compare" situations. Is there any precedent for throwing an exception on cmp? Also, is it really necessary to allow raw non-ASCII characters in source code though? We know that they aren't portable across editing environments, so one person's happy face will be another person's left double-dagger. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Sat Jul 15 19:36:38 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 19:36:38 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> <39709962.1C0A576E@lemburg.com> Message-ID: <005c01bfee83$4bafc480$f2a6b5d4@hagrid> mal wrote: > > (except for the unicode object module, that is). > > I don't think so... it's very new and the C API isn't > documented. great. I'll just pretend it doesn't exist. > > so if nobody uses this, I'd rather change the unicodeobject.c > > file to use the new API directly... > > Please don't drop the idea of an on-demand loadable module > though. The current design used by Bill Tutt is to load the > ucnhash module (which contains the mappings) only when it > is needed -- most code won't need it. > > BTW, does you database use the on-demand loading feature ? > I don't think that having the Unicode database linked statically > in the Python interpreter is a good idea -- at least not until > Unicode takes over ;-) but of course... everything except the "ctype" info is loaded from PYD/SO's, just as before. the only difference is that the files are slightly smaller :-) -rw-r--r-- 1 500 everyone 443392 Jul 15 18:55 ucnhash.pyd -rw-r--r-- 1 500 everyone 161280 Jul 15 18:53 uninames.pyd -rw-r--r-- 1 500 everyone 594944 Jul 11 23:03 unicodedata.pyd -rw-r--r-- 1 500 everyone 42496 Jul 15 15:25 unidata.pyd -rw-r--r-- 1 500 everyone 118329 Jul 13 21:01 unicodectype.obj -rw-r--r-- 1 500 everyone 10961 Jul 15 15:23 unictype.obj (names and sizes may change slightly before the final patch, but you get the idea). cheers /F From effbot at telia.com Sat Jul 15 19:54:47 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 19:54:47 +0200 Subject: [Python-Dev] [patch #100889] a smaller unicode name database Message-ID: <006a01bfee85$c787f3a0$f2a6b5d4@hagrid> my unicode database compression project has resulted in its first patch: https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100899&group_id=5470 this patch replaces "ucnhash" (sorry bill!) with a new module called "uninames". on my windows box, the new module is about 1/3 of the old one (about 160k). YMMV, as usual. From effbot at telia.com Sat Jul 15 20:00:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 20:00:48 +0200 Subject: [Python-Dev] [patch #100889] a smaller unicode name database References: <006a01bfee85$c787f3a0$f2a6b5d4@hagrid> Message-ID: <007401bfee86$9dd566e0$f2a6b5d4@hagrid> > my unicode database compression project has resulted in its first > patch: > > https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100899&group_id=5470 two additional comments: first, the patch was too large for sourceforge (>512000 bytes), so I've uploaded it to the secret effbot site instead: http://w1.132.telia.com/~u13208596/uninames-patch.txt second, the uninames module provides two public Python functions: getname(code) returns the character name corresponding to the given character code, or None if the name is not known. getcode(name) returns the character code for the given character name. again, it returns None if the code is not known. Q: should I raise exceptions instead of returning None? Q: what other functions would be useful? getallnames()? anything else? cheers /F From mal at lemburg.com Sat Jul 15 19:57:45 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 19:57:45 +0200 Subject: [Python-Dev] Linker problems on Linux Message-ID: <3970A619.D2CA39AA@lemburg.com> I just tried to compile the current CVS version on Linux. The compile went fine, but when I started Python, I got: 'import site' failed; use -v for traceback Python 2.0b1 (#1, Jul 15 2000, 19:22:33) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) Traceback (most recent call last): File "/home/lemburg/bin/pyinteractive.py", line 7, in ? import mx.Tools File "/home/lemburg/projects/mx/Tools/__init__.py", line 24, in ? from Tools import * File "/home/lemburg/projects/mx/Tools/Tools.py", line 10, in ? from mxTools import * File "/home/lemburg/projects/mx/Tools/mxTools/__init__.py", line 1, in ? from mxTools import * ImportError: /home/lemburg/projects/mx/Tools/mxTools/mxTools.so: undefined symbol: PyObject_Length >>> Why isn't PyObject_Length being exported anymore ??? I hve the funny feeling that the API name cosmetics applied to xxx_Length() got someone carried away a bit ;-) We shouldn't drop binary compatibility on *all* platforms just for the sake of style... I remember very well how Guido opposed to any binary incompatible changes in earlier versions of Python and can't really believe that this strategy has suddenly changed for 2.0. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jul 15 19:59:56 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 19:59:56 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709C19.A9A27625@lemburg.com> Message-ID: <3970A69C.3361B209@lemburg.com> "M.-A. Lemburg" wrote: > > BTW, I have a feeling that we should mask the decoding errors > during compares in favour of returning 0... > > ...otherwise the current dictionary would bomb (it doesn't do any > compare error checking !) in case a Unicode string happens to have > the same hash value as an 8-bit string key. (Can't test this right now, > but this is what should happen according to the C sources.) Here's the test: >>> s = '?' >>> u = u'?' >>> hash(s) -880683291 >>> hash(u) -880683291 >>> d = {s:1} >>> d[s] 1 >>> d[u] Traceback (most recent call last): File "", line 1, in ? KeyError>>> >>> Looks strange, doesn't it... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jul 15 20:02:31 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 20:02:31 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> <39709962.1C0A576E@lemburg.com> <005c01bfee83$4bafc480$f2a6b5d4@hagrid> Message-ID: <3970A737.6B13B543@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > so if nobody uses this, I'd rather change the unicodeobject.c > > > file to use the new API directly... > > > > Please don't drop the idea of an on-demand loadable module > > though. The current design used by Bill Tutt is to load the > > ucnhash module (which contains the mappings) only when it > > is needed -- most code won't need it. > > > > BTW, does you database use the on-demand loading feature ? > > I don't think that having the Unicode database linked statically > > in the Python interpreter is a good idea -- at least not until > > Unicode takes over ;-) > > but of course... > > everything except the "ctype" info is loaded from PYD/SO's, just as > before. the only difference is that the files are slightly smaller :-) > > -rw-r--r-- 1 500 everyone 443392 Jul 15 18:55 ucnhash.pyd > -rw-r--r-- 1 500 everyone 161280 Jul 15 18:53 uninames.pyd > > -rw-r--r-- 1 500 everyone 594944 Jul 11 23:03 unicodedata.pyd > -rw-r--r-- 1 500 everyone 42496 Jul 15 15:25 unidata.pyd > > -rw-r--r-- 1 500 everyone 118329 Jul 13 21:01 unicodectype.obj > -rw-r--r-- 1 500 everyone 10961 Jul 15 15:23 unictype.obj > > (names and sizes may change slightly before the final patch, but you > get the idea). Cool :-) (I'd suggest keeping the original names, BTW) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sat Jul 15 20:10:07 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 20:10:07 +0200 Subject: [Python-Dev] what to call this zip() function? References: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: <007d01bfee87$eb2c2e00$f2a6b5d4@hagrid> skip wrote: > Nothing has really jumped out as the "right" way to express the proposed > builtin that does > > map(None, l1, l2, l3, l4) > > How about collate? What we're doing is effectively what a copy machine does > when it collates multiple copies of its input... let's see: merriam webster has the following to say: collate: ... to assemble in proper order; especially : to assemble (as printed sheets) in order for binding ... "binding"? sounds familiar. let's take a look at the language reference: ... Assignment statements are used to (re)bind names to values ... The for statement is used to iterate over the elements of a sequence ... Each item in turn is assigned to the target list using the standard rules for assignments ... +1 from here. From mal at lemburg.com Sat Jul 15 20:09:49 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 20:09:49 +0200 Subject: [Python-Dev] [patch #100889] a smaller unicode name database References: <006a01bfee85$c787f3a0$f2a6b5d4@hagrid> <007401bfee86$9dd566e0$f2a6b5d4@hagrid> Message-ID: <3970A8ED.28CEC0FE@lemburg.com> Fredrik Lundh wrote: > > > my unicode database compression project has resulted in its first > > patch: > > > > https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100899&group_id=5470 > > two additional comments: > > first, the patch was too large for sourceforge (>512000 bytes), so > I've uploaded it to the secret effbot site instead: > > http://w1.132.telia.com/~u13208596/uninames-patch.txt > > second, the uninames module provides two public Python functions: I'd name this: unicodenames (we shouldn't be afraid of long module names ;-). > getname(code) returns the character name corresponding to > the given character code, or None if the name is not known. > > getcode(name) returns the character code for the given character > name. again, it returns None if the code is not known. > > Q: should I raise exceptions instead of returning None? Yes... getname() with an unkown code means that an unassigned code is being requested: this is a ValueError. getcode(name) should raise a ValueError exception too, since the requested name may be unsupported by Python's version of the Unicode lib (vers. 3.0). BTW, did you make the lookups case insensitive ? (Would be useful, IMHO.) > Q: what other functions would be useful? getallnames()? anything > else? Perhaps a dictionary like interface written on top of the above two APIs (in Python, of course). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Sat Jul 15 20:14:19 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 21:14:19 +0300 (IDT) Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: On Sat, 15 Jul 2000, Skip Montanaro wrote: > > Nothing has really jumped out as the "right" way to express the proposed > builtin that does > > map(None, l1, l2, l3, l4) > > How about collate? What we're doing is effectively what a copy machine does > when it collates multiple copies of its input... Collate is great! +0 on that. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Sat Jul 15 20:21:52 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 20:21:52 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> <39709962.1C0A576E@lemburg.com> <005c01bfee83$4bafc480$f2a6b5d4@hagrid> <3970A737.6B13B543@lemburg.com> Message-ID: <008b01bfee89$8e731460$f2a6b5d4@hagrid> mal wrote: > Cool :-) oh, just wait until I've gotten my head around Christian's superoptimizations ;-) > (I'd suggest keeping the original names, BTW) unicodedata and unicodectype are okay, but frankly, isn't "ucnhash" overly cryptic? how about "unicodenames"? From effbot at telia.com Sat Jul 15 20:30:07 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 20:30:07 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> Message-ID: <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> paul wrote: > As soon as you find a character out of the ASCII range in one of the > strings, I think that you should report that the two strings are > unequal. sounds reasonable -- but how do you flag "unequal" in cmp? which value is "larger" if all that we know is that they're different... > We can't have exceptions popping out of dictionaries and other "blind > compare" situations. Is there any precedent for throwing an exception > on cmp? not really. it's a bit amusing that "a" == x works for all built-in types, except unicode strings... (not to mention that "a" < x works, in a way...) > Also, is it really necessary to allow raw non-ASCII characters in source > code though? We know that they aren't portable across editing > environments, so one person's happy face will be another person's left > double-dagger. I suppose changing that would break code. maybe it's time to reopen the "pragma encoding" thread? (I'll dig up my old proposal, and post it under a new subject). From ping at lfw.org Sat Jul 15 20:34:57 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sat, 15 Jul 2000 11:34:57 -0700 (PDT) Subject: [Python-Dev] what to call this zip() function? Message-ID: Skip Montanaro wrote: > How about collate? The analogy with a photocopying machine is pretty good, but i'm afraid this will play havoc with those who see "collate" in terms of determining sort order. * * * With me acting as the user and a willing guinea pig playing the part of the Python interpreter, i got the following results: >>> a = [1, 2, 3] >>> b = [4, 5, 6] >>> c = [7, 8, 9] >>> for x, y, z in twine(a, b, c): ... print x, y, z 1 5 9 2 6 7 3 4 8 >>> for x, y, z in weave(a, b, c): ... print x, y, z 1 5 7 2 4 8 3 None 9 None 6 None >>> for x, y, z in parallel(a, b, c): ... print x, y, z 1 4 7 2 5 8 3 6 9 * * * On Fri, 14 Jul 2000, Eric S. Raymond wrote: > No, *I* wrote `plait() is *good*.' > > In English, `plait' is a slightly unusual word with a meaning almost > indistinguishable from `braid'. ...which is almost entirely the *wrong* meaning, imho. Here are the pictures i get from the words suggested so far. splice furl _______ --> <-- / _____ \ --------= =------- / / \ \ \_______/ / ___________/ twine /|\ lace -%- \|/ \ / \ X /|\ / \ \|/ \ / \ X /|\ (_) \|/ braid / \ / plait | | plait | / (sense 2) | _______|_ (sense 1) \ / \ |/| | \ | | _______|_ / \ / |/| | | / | | \ / \ | | \ | / \ / weave -|-----|-----|- interlace -----------> interweave | | | | | interleave <----------- knit ----|-----|---- -----------> | | | | | <----------- -|-----|-----|- -----------> | | | | | <----------- ----|-----|---- -----------> | | | | | <----------- -|-----|-----|- parallel --------------- march ------ o-> - - - --------------- ------ o-> - - - --------------- ------ o-> - - - --------------- ------ o-> - - - zip o o merge | | | marry o o (herd?) | | | o o \ | / o-o \|/ o-o | o-o | o-o | o-o v * * * It's fairly clear to me that, of the names that evoke images of some sort, only "parallel", "march", and "merge" are actually accurate. "zip" and "marry" are nearly accurate except that they usually give the impression that only two things are being joined. Of these five options, "zip" and "parallel" have potentially misleading meanings. "merge" sounds the most neutral to me. "tuples" is also very neutral (though it doesn't really suggest *how* the tuples are obtained). Therefore, i'm down to "merge", "tuples", or "march" (maybe "herd"); i'd be quite happy with "parallel" or "zip" but others have already come out strongly against those two. * * * Finally, on the lighter side... more ideas from my twisted mind. for x, y, z in rearrange(a, b, c)? for x, y, z in herd(a, b, c)? for x, y, z in mutilate(a, b, c)? for x, y, z in harass(a, b, c)? for x, y, z in abuse(a, b, c)? for x, y, z in torture(a, b, c)? A friend also suggested a name reminiscent of our discussion. for x, y, z in flamewar(a, b, c): print x, y, z You want an argument? Oh, this is abuse. Arguments are down the hall. -- ?!ng From ping at lfw.org Sat Jul 15 20:36:48 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sat, 15 Jul 2000 11:36:48 -0700 (PDT) Subject: [Python-Dev] Re: what to call this zip() function? In-Reply-To: Message-ID: On Sat, 15 Jul 2000, Ka-Ping Yee wrote: > zip o o merge | | | > marry o o (herd?) | | | > o o \ | / > o-o \|/ > o-o | > o-o | > o-o | > o-o v Oh yes. "meld" also falls in the "merge"/"herd" category. -- ?!ng From alex_c at MIT.EDU Sat Jul 15 20:32:00 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Sat, 15 Jul 2000 14:32:00 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> (fdrake@beopen.com) References: <200007142030.QAA156803@w20-575-116.mit.edu> <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> <200007142242.SAA12205@mint-square.mit.edu> <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> Message-ID: <200007151832.OAA63801@w20-575-115.mit.edu> Should posixpath.expandvars throw a SyntaxError if it encounters unbalanced curly braces? >>> import posixpath >>> posixpath.expandvars('/dir1/dir${DIR_NUM/dir2') '/dir1/dir${DIR_NUM/dir2' >>> Alex. From paul at prescod.net Sat Jul 15 20:37:43 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 13:37:43 -0500 Subject: [Python-Dev] what to call this zip() function? References: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: <3970AF77.385853E0@prescod.net> Skip Montanaro wrote: > > Nothing has really jumped out as the "right" way to express the proposed > builtin that does > > map(None, l1, l2, l3, l4) > > How about collate? What we're doing is effectively what a copy machine does > when it collates multiple copies of its input... +1 on collate! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From thomas at xs4all.net Sat Jul 15 20:44:10 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 15 Jul 2000 20:44:10 +0200 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <3970A619.D2CA39AA@lemburg.com>; from mal@lemburg.com on Sat, Jul 15, 2000 at 07:57:45PM +0200 References: <3970A619.D2CA39AA@lemburg.com> Message-ID: <20000715204410.I7340@xs4all.nl> On Sat, Jul 15, 2000 at 07:57:45PM +0200, M.-A. Lemburg wrote: > I just tried to compile the current CVS version on Linux. > The compile went fine, but when I started Python, I got: > 'import site' failed; use -v for traceback > Python 2.0b1 (#1, Jul 15 2000, 19:22:33) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > Traceback (most recent call last): > File "/home/lemburg/bin/pyinteractive.py", line 7, in ? > import mx.Tools > File "/home/lemburg/projects/mx/Tools/__init__.py", line 24, in ? > from Tools import * > File "/home/lemburg/projects/mx/Tools/Tools.py", line 10, in ? > from mxTools import * > File "/home/lemburg/projects/mx/Tools/mxTools/__init__.py", line 1, in ? > from mxTools import * > ImportError: /home/lemburg/projects/mx/Tools/mxTools/mxTools.so: undefined symbol: PyObject_Length > Why isn't PyObject_Length being exported anymore ??? PyObject_Length is changed into a #define, to PyObject_Size. This preserves the API but not the ABI ;) GCC has a construct to make one function an alias for another: PyObject * PyObject_Length() __attribute__((alias("PyObject_Size"))); But this is not likely to work in other compilers, and not on all architectures to start with. The most portable solution is probably to make PyObject_Length() a wrapper for PyObject_Size, and hope the compiler knows how to handle that most efficiently. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm at hypernet.com Sat Jul 15 20:44:48 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 15 Jul 2000 14:44:48 -0400 Subject: [Python-Dev] what to call this zip() function? In-Reply-To: Message-ID: <1248435790-52927448@hypernet.com> Ka-Ping Yee wrote: > You want an argument? Oh, this is abuse. Arguments are down the > hall. Now that's my kind of company! Drop in anytime, Barry. No appointment necessary.... - Gordon From paul at prescod.net Sat Jul 15 20:48:20 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 13:48:20 -0500 Subject: [Python-Dev] Pre-PEP Idea Message-ID: <3970B1F4.D4D8BAE9@prescod.net> Hopefully this transcript will speak for itself...mostly. >>> help | The help function allows you to read help on Python's various | functions, objects, instructions and modules. You have two options: | | 1. Use help( obj ) to browse the help attached to some function, | module, class or other object. e.g. help( dir ) | | 2. Use help( "somestring" ) to browse help on one of the predefined | help topics, unassociated with any particular object: | | help( "intro" ) - What is Python? | help( "keywords" ) - What are the keywords? | help( "syntax" ) - What is the overall syntax? | help( "operators" ) - What operators are available? | help( "types" ) - What types are built-in (not extension types)? | help( "exceptions" ) - What exceptions can be raised? | help( "modules" ) - What modules are in the standard library? | help( "copyright" ) - Who owns Python? | help( "moreinfo" ) - Where is there more information? | help( "changes" ) - What changed in Python 2.0? | help( "extensions" ) - What extensions are installed? | help( "faq" ) - What questions are frequently asked? | help( "ack" ) - Who has done work on Python lately? | help( "language" ) - Change the language of the help function >>> >>> help( "keywords" ) | "if" - Conditional execution | "while" - Loop while a condition is true | "for" - Loop over a sequence of values (often numbers) | "try" - Set up an exception handler | "def" - Define a named function | "class" - Define a class | "assert" - Check that some code is working as you expect it to. | "pass" - Do nothing | "del" - Delete a data value | "print" - Print a value | "return" - Return information from a function | "raise" - Raise an exception | "break" - Terminate a loop | "continue" - Skip to the next loop statement | "import" - Import a module | "global" - Declare a variable global | "exec" - Execute some dynamically generated code | "lambda" - Define an unnamed function | For more information, type e.g. help("assert") >>> >>> help( dir ) | dir([object]) -> list of strings | Return an alphabetized list of names comprising (some of) the attributes | of the given object. Without an argument, the names in the current scope | are listed. With an instance argument, only the instance attributes are | returned. With a class argument, attributes of the base class are not | returned. For other types or arguments, this may list members or methods. >>> >>> import pickle >>> help( pickle ) | create portable serialized representations of Python objects. | See module cPickle for a (much) faster implementation. | See module copy_reg for a mechanism for registering custom picklers. | Classes: | Pickler | Unpickler | Functions: | dump(object, file) | dumps(object) -> string | load(file) -> object | loads(string) -> object | Misc variables: | __version__ | format_version | compatible_formats >>> -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From moshez at math.huji.ac.il Sat Jul 15 20:50:55 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 21:50:55 +0300 (IDT) Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> Message-ID: On Sat, 15 Jul 2000, Fredrik Lundh wrote: > paul wrote: > > As soon as you find a character out of the ASCII range in one of the > > strings, I think that you should report that the two strings are > > unequal. > > sounds reasonable -- but how do you flag "unequal" in cmp? which > value is "larger" if all that we know is that they're different... We can say something like "beyond the ASCII range, every unicode character is larger then any regular 8-bit character", and compare lexicographically. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Sat Jul 15 20:55:07 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 21:55:07 +0300 (IDT) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B1F4.D4D8BAE9@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Hopefully this transcript will speak for itself...mostly. > > >>> help +0. Here's what I think would make it +1: -- have all that wonderful stuff in help.py -- have the startup code of the *interactive interpreter only* do "from help import help" at the beginning. by-all-means-PEP-it-*i've*-seen-it-a-gazillion-times-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Sat Jul 15 21:08:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 21:08:58 +0200 Subject: [Python-Dev] Pre-PEP Idea References: <3970B1F4.D4D8BAE9@prescod.net> Message-ID: <010e01bfee90$224df960$f2a6b5d4@hagrid> paul wrote: > Hopefully this transcript will speak for itself...mostly. > > >>> help > | The help function allows you to read help on Python's various > | functions, objects, instructions and modules. heh. so that's why I'm having a slight headache; paul is in there stealing my ideas? ;-) ... I got stuck on whether this is best implemented as a true builtin, or just patched into the builtins dictionary by site.py... why not just post a site.py patch, and forget about the PEP for now? 1) plus a sys.sethelphook function which allow the environ- ment to override the default behaviour; for example, if you're typing help("intro") in PythonWorks' console window, you pro- bably want to get nicely formatted help in the "info" panel, not in the console window itself. From Vladimir.Marangozov at inrialpes.fr Sat Jul 15 21:13:04 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 15 Jul 2000 21:13:04 +0200 (CEST) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B1F4.D4D8BAE9@prescod.net> from "Paul Prescod" at Jul 15, 2000 01:48:20 PM Message-ID: <200007151913.VAA03550@python.inrialpes.fr> Paul Prescod wrote: > > Hopefully this transcript will speak for itself...mostly. > Very nice, Paul! PEP it without hesitation. I'm all for it! We'll discuss subsequently what's the best way to implement interactive help screens. don't-forget-to-add-man()-for-Tom-Christiansen-<0.8 wink>'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul at prescod.net Sat Jul 15 21:13:55 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 14:13:55 -0500 Subject: [Python-Dev] Pre-PEP Idea References: Message-ID: <3970B7F3.28F64A3E@prescod.net> Moshe Zadka wrote: > > ... > > -- have all that wonderful stuff in help.py > -- have the startup code of the *interactive interpreter only* do > "from help import help" at the beginning. Sorry, that's a part I should have explanied more. help is not a magical function/statement but an instance with a repr that does the right thing. And yes, it will probably only be loaded at the repl. Or it could be a 10-line instance that loads its content when it is actually used. That might allow python -c "import help" Here's a sample definition. class helploader: def __repr__( self ): global help from helptext import help return repr( help ) def __call__( self ): global help from helptext import help return repr( help ) help=helploader() -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Sat Jul 15 21:22:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 21:22:42 +0200 Subject: [Python-Dev] posixpath module. References: <200007142030.QAA156803@w20-575-116.mit.edu><14703.37801.644447.63587@cj42289-a.reston1.va.home.com><200007142242.SAA12205@mint-square.mit.edu> <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> <200007151832.OAA63801@w20-575-115.mit.edu> Message-ID: <012f01bfee92$0e21df40$f2a6b5d4@hagrid> alex wrote: > > Should posixpath.expandvars throw a SyntaxError if it encounters > unbalanced curly braces? > > >>> import posixpath > >>> posixpath.expandvars('/dir1/dir${DIR_NUM/dir2') > '/dir1/dir${DIR_NUM/dir2' > >>> probably not; code using it might not be prepared to handle an exception... what does the Unix shell do in this case? (intuitively, I'd treat ${FOO as $FOO, say: _varprog = re.compile(r'\$(\{[^{}$]*\}|{?\w+|)') but that's me...) From moshez at math.huji.ac.il Sat Jul 15 21:19:11 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 22:19:11 +0300 (IDT) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B7F3.28F64A3E@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Moshe Zadka wrote: > > > > ... > > > > -- have all that wonderful stuff in help.py > > -- have the startup code of the *interactive interpreter only* do > > "from help import help" at the beginning. > > Sorry, that's a part I should have explanied more. > > help is not a magical function/statement but an instance with a repr > that does the right thing. And yes, it will probably only be loaded at > the repl. Or it could be a 10-line instance that loads its content when > it is actually used. That might allow > > python -c "import help" > > Here's a sample definition. > > class helploader: > def __repr__( self ): > global help > from helptext import help > return repr( help ) > def __call__( self ): > global help > from helptext import help > return repr( help ) > help=helploader() BTW, that should probably be CCed to the doc-sig, because that information has to come from somewhere. doc-sig traffic kind of died after the initial IPC8-induced burst. Fred, any plans on seriously reviving doc-sig? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul at prescod.net Sat Jul 15 21:19:41 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 14:19:41 -0500 Subject: [Python-Dev] Pre-PEP Idea References: <3970B1F4.D4D8BAE9@prescod.net> <010e01bfee90$224df960$f2a6b5d4@hagrid> Message-ID: <3970B94D.40F5032A@prescod.net> Fredrik Lundh wrote: > > ... > > heh. so that's why I'm having a slight headache; paul is > in there stealing my ideas? ;-) I should have just let you invent it! > I got stuck on whether this is best implemented as a true > builtin, or just patched into the builtins dictionary by site.py... six of one, half dozen of the other. * builtin means a little more consistency across environments * ptach means a little less code on startup What do you think of my ten-line bootstrapper idea. I weigh the former slightly higher then the latter. Plus, I could perhaps put a helpful message in the bootstrapper to help people debug site.py and PYTHONPATH problems. :) > 1) plus a sys.sethelphook function which allow the environ- > ment to override the default behaviour; for example, if you're > typing help("intro") in PythonWorks' console window, you pro- > bably want to get nicely formatted help in the "info" panel, > not in the console window itself. Good idea. And eventually some way for extensions to register themselves...and a pager. Do we have pager code hanging around? Some docstrings are already long and we have no mechanism for breaking them up .... -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From alex_c at MIT.EDU Sat Jul 15 21:23:55 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Sat, 15 Jul 2000 15:23:55 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <012f01bfee92$0e21df40$f2a6b5d4@hagrid> (effbot@telia.com) References: <200007142030.QAA156803@w20-575-116.mit.edu><14703.37801.644447.63587@cj42289-a.reston1.va.home.com><200007142242.SAA12205@mint-square.mit.edu> <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> <200007151832.OAA63801@w20-575-115.mit.edu> <012f01bfee92$0e21df40$f2a6b5d4@hagrid> Message-ID: <200007151923.PAA64675@w20-575-115.mit.edu> > > Should posixpath.expandvars throw a SyntaxError if it encounters > > unbalanced curly braces? > > probably not; code using it might not be prepared > to handle an exception... > > what does the Unix shell do in this case? It gives an error: athena% echo ${HOME Missing }. athena% echo ${HOME} /afs/athena.mit.edu/user/a/l/alex_c athena% You're probably right about backwards compatibility being worth more than compatibility with Unix in this case, though. Alex. From paul at prescod.net Sat Jul 15 21:24:21 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 14:24:21 -0500 Subject: [Python-Dev] Pre-PEP Idea References: <3970B1F4.D4D8BAE9@prescod.net> <010e01bfee90$224df960$f2a6b5d4@hagrid> Message-ID: <3970BA65.5DBFB39A@prescod.net> Fredrik Lundh wrote: > > ... > > why not just post a site.py patch, and forget about the > PEP for now? Also, how should I include a new module in a patch? Do I do a directory diff? Or just checkin the stupid thing? -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From moshez at math.huji.ac.il Sat Jul 15 21:41:13 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 22:41:13 +0300 (IDT) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B94D.40F5032A@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Good idea. And eventually some way for extensions to register > themselves...and a pager. Do we have pager code hanging around? Some > docstrings are already long and we have no mechanism for breaking them > up .... Do you mean this: import sys def pager(lines, length=23): while lines: sys.stdout.writelines(lines[:length]) lines = lines[length:] if lines: raw_input("--more--") def main(): pager(open(sys.argv[1]).readlines()) if __name__ == '__main__': main() -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Sat Jul 15 21:58:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 21:58:25 +0200 Subject: [Python-Dev] Pre-PEP Idea References: <3970B1F4.D4D8BAE9@prescod.net> <010e01bfee90$224df960$f2a6b5d4@hagrid> <3970BA65.5DBFB39A@prescod.net> Message-ID: <016001bfee97$0b67fd20$f2a6b5d4@hagrid> paul wrote: > Also, how should I include a new module in a patch? Do I do a directory > diff? Or just checkin the stupid thing? I had the same problem for the "uninames" patch. I ended up using "diff -N" on local, empty files. hopefully, someone out there might have a better solution? (the docs imply that "cvs -N" might work, but it sure didn't work for me...) From paul at prescod.net Sat Jul 15 22:03:15 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 15:03:15 -0500 Subject: [Python-Dev] Pre-PEP Idea References: Message-ID: <3970C383.9D844BF3@prescod.net> Moshe Zadka wrote: > > Do you mean this: > > import sys > > def pager(lines, length=23): > while lines: > sys.stdout.writelines(lines[:length]) > lines = lines[length:] > if lines: > raw_input("--more--") > > def main(): > pager(open(sys.argv[1]).readlines()) > Okay, okay, it didn't turn out so hard. :) I was just about to write it myself. Is there a way to get a single key portably, rather than requiring a return? Not a biggee. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Sat Jul 15 22:04:30 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 15:04:30 -0500 Subject: [Python-Dev] Pre-PEP Idea References: <200007151913.VAA03550@python.inrialpes.fr> Message-ID: <3970C3CE.804A8BF@prescod.net> Vladimir Marangozov wrote: > > Paul Prescod wrote: > > > > Hopefully this transcript will speak for itself...mostly. > > > > Very nice, Paul! > PEP it without hesitation. I'm all for it! We'll discuss subsequently > what's the best way to implement interactive help screens. > > don't-forget-to-add-man()-for-Tom-Christiansen-<0.8 wink>'ly y'rs No joke, in the interactive environment I am going to add apropos and man as aliases. Or at least messages that say: "try help". -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Sat Jul 15 22:16:16 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 15:16:16 -0500 Subject: [Python-Dev] Pre-PEP Idea References: Message-ID: <3970C690.42CA22FF@prescod.net> Moshe Zadka wrote: > > BTW, that should probably be CCed to the doc-sig, because that information > has to come from somewhere. True enough. Let me get some infrastructure in place and sic them on it. It may also be good to ask for volunteers in c.l.py. Here are my ideas about content: 1. There is the list of hardcoded strings that are probably just triple-quoted strings. 2. There are docstrings. 3. If you happen to know a filename, you can reach into the HTML docs like this: help( "docs:lib/module-grp.html") 4. Docstrings can "redirect" to the HTML docs like this: def myfunc(): """No docs here! Please see """ ... Here's what the HTML-converted output will look like (not perfect but not bad): next[1] up[2] previous[3] Python Library Reference contents[4] modules[5] index[6] Next: 8.1 posix [7] Up: Python Library Reference[8] Previous: 7.15.1 Completer Objects[9] ------------------------------------------------------------------------ 8. Unix Specific Services The modules described in this chapter provide interfaces to features that are unique to the Unix operating system, or in some cases to some or many variants of it. Here's an overview: posix[10] The most common POSIX system calls (normally used via module os[11]). pwd[12] The password database (getpwnam() and friends). grp[13] The group database (getgrnam() and friends). crypt[14] The crypt() function used to check Unix passwords. dl[15] Call C functions in shared objects. dbm[16] The standard ``database'' interface, based on ndbm. gdbm[17] GNU's reinterpretation of dbm. termios[18] POSIX style tty control. ------------------------------------------------------------------------ next[30] up[31] previous[32] Python Library Reference contents[33] modules[34] index[35] Next: 8.1 posix [36] Up: Python Library Reference[37] Previous: 7.15.1 Completer Objects[38] ------------------------------------------------------------------------ See About this document...[39] for information on suggesting changes. [1] docs:lib/module-posix.html [2] docs:lib/lib.html [3] docs:lib/completer-objects.html ... Thanks Fred and Guido. The htmllib code is pretty close for what I need! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From moshez at math.huji.ac.il Sat Jul 15 22:21:14 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 23:21:14 +0300 (IDT) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970C383.9D844BF3@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Is there a way to get a single key portably, rather than > requiring a return? Not that I know of. coding-during-commercials-is-fun-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Sat Jul 15 22:29:21 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 22:29:21 +0200 Subject: [Python-Dev] [patch #100889] a smaller unicode name database References: <006a01bfee85$c787f3a0$f2a6b5d4@hagrid> <007401bfee86$9dd566e0$f2a6b5d4@hagrid> <3970A8ED.28CEC0FE@lemburg.com> Message-ID: <018c01bfee9b$5ce953c0$f2a6b5d4@hagrid> mal wrote: > > second, the uninames module provides two public Python functions: > > I'd name this: unicodenames (we shouldn't be afraid of long > module names ;-). ok. > getname() with an unkown code means that an unassigned > code is being requested: this is a ValueError. > > getcode(name) should raise a ValueError exception too, since the > requested name may be unsupported by Python's version of the > Unicode lib (vers. 3.0). ok. > BTW, did you make the lookups case insensitive ? (Would be > useful, IMHO.) sure. both getcode and \N are case insensitive. > Perhaps a dictionary like interface written on top of > the above two APIs (in Python, of course). sounds like something for a "unicodeutils.py" module ;-) maybe later... ... if anyone would like to play with this, I just updated the patch at: http://w1.132.telia.com/~u13208596/uninames-patch.txt (the module is renamed, the patch isn't...) note: the patch doesn't update the build files. Should be pretty obvious how to do that... From huaiyu_zhu at yahoo.com Sat Jul 15 22:30:31 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Sat, 15 Jul 2000 13:30:31 -0700 (PDT) Subject: [Python-Dev] More discussion on new infix operators In-Reply-To: <1248451855-51961207@hypernet.com> Message-ID: I would like to redirect this discussion to deal with solvable problems, rather than going on at several fronts, not all of them immediately resolvable. I'll provide some background, summarize what I've learned in these discussions, and finally present some options and comments. The issue arises from the attempt to introduce matrix operations into python. This may be an unfamiliar subject here, and we can't hope to agree upon how fundamental or useful it is. So let's just regard it as some mysterious thing that engineers like to do [1]. It happens that in this domain the familiar arithmetic operators split into two personalities, matrix-wise and element-wise. Both are used frequently, often within the same formula. There are several successful commercial and free languages for numerical computation. Many of them use the Matlab approach: ordinary operators for matrix operation, dot-operators for element-wise operation. These languages are very elegant and powerful within the domain of their applications. The problem is, many of them are not object oriented. Most people do not use matrix as part of a math course, but as a method for solving real problems. So they are forced to use Perl, shell scripts or embedded or embedding C/C++ to integrate these calculations into their applications. There is no need to explain here why people would want to use Python as the glue language. You may also agree that calling other languages within Python cannot beat using native Python modules written in C. A great deal of work has been done to build the Numerical package. Although the situation improves tremendously, it still do not appeal to most users of the dedicated matrix languages, for two reasons. One is that NumPy emphasizes on multi-array rather than matrix [2]. The other is the lack of support to distinguish the two personalities of operators. The MatPy project was started to solve these problems. It defines matrix classes that wrap around the Numeric classes, so that ordinary operators default to matrix-wise operations, solving the first problem. The second problem cannot be solved without any change to Python syntax, because there simply isn't enough binary operators available. It is necessary to add new operators. They can all live in the area of current "invalid syntax" so they would not interfere with existing code. We made a patch to the parser to add new operators, and I started a discussion on the best allocation of these operators, when the discussion was also brought here. So much for the background. From these discussions I believe the following is clear (please correct me). 1. It is not much more difficult to add .* style operators than to add @* style operators, even though . is overused and @ is unused. 2. There already exists some facilities for changing syntax within pure python. But I don't remember any mention of where it is, and it seems people do not agree on its usability status at the moment. 3. Most here do not want additional operators in the core language until they see it successfully used in at least one domain. There is also an argument that operators that are only meaningful in one domain would acquire completely incomprehensible semantics in all other domains. 4. There are three types of suggestion for matrix computation: 1) Do not make any syntax change. This includes two proposals: 1.a) Use function calls like dotmul(a,b). 1.b) Define Element and Matrix classes in parallel, with methods for casting. Use a.Element()*b.Element() in place of a.*b. 2) Add additional operators. These operators have fixed precedence as their original counterparts but their semantics can be overridden in applications. They are encouraged to preserve the object-wise and element-wise distinctions. 2.a) Add @* type operators. 2.b) Add .* type operators. 3) User a patched parser. This also allows additional syntactic changes: 3.a) Only as a temporary measure until it is accepted to core language. 3.b) Each application can have their own syntax with some marker on each module to indicate which is which. 3.c) Just develop a different language. 5. Will introducing dot operators conflict with any existing language structures? It does not affect member indicators, because that's always between two names. It may interfere with a trailing decimal point, but that can be fixed by a simple rule (3.*a means 3. * a). Now to the options with my own comments. 1.a) is unacceptable because infix operators improve readability tremendously compared with prefix operators. 1.b) is unacceptable because it is too long and involves at least two method calls and object initialization for each operation. 2.a) was our original plan, and we have a patch for doing so. It is less than optimal aesthetically, and we were not sure to use it for matrix or element-wise operations. It is not intended to be submitted to the core language until the matrix package itself is ready to do so, although it couldn't possibly be changed at that time. 2.b) is my personal favorite. As ESR pointed out, there are also potential applications in other areas. To prevent incompatible semantics, it could be encouraged to be used only in "dual personality" situations. Whenever possible, the dot operators default to "element-wise operation" for any composite objects. For example [1,2] + [10,20] == [1,2,10,20] [1,2] .+ [10,20] == [11,22] 3) is not a good option in this case. First, it is overkill. Linear algebra is a very mature field and only a handful of well-known operators are called for. These operations are written in science and engineering books for years and are very unlikely to change anytime soon. Second, it presents greater danger of incompatibility and fragmentation. Unlike different semantics, different syntax cannot even live within the same module. Third, the very reason people would want to use python for matrix computation is because it is an integral part of their application that need to work with everything else smoothly. The situation now is that MatPy project has to move on, no matter what. It will introduce some kind of binary infix operators just to be viable (unless some entirely new argument comes along). But there do not seem to be additional big hurdles on either algorithm or man power to impede its further development. I hope, and I do believe personally, that it will acquire wide-spread usage once such basic facilities are provided, and will eventually be integrated into the core language. It would be next to impossible to change operators at that moment. Therefore I am most interested in hearing any thoughts on whether there exist any mortal danger for introducing the dot operators. For example, will it be confused with any planned new language features? Arguments on whether this would open the floodgate for other feature requests is unlikely to change the course of MatPy development because we agreed not to talk about how specific the domain is [1]. That's all I could think of at this moment. I'd like to thank your patience for reading so far. I am grateful for all the rational and very helpful opinions I heard here, and I eagerly expect more. Huaiyu [1] I'd be glad to provide easy introduction to numerical computation through email to anyone who would spend half an hour experimenting. [2] The easiest (but not quite accurate) way to describe the difference is to compare with lists and strings: If you are doing text processing you want a dedicated string type, rather than a list of characters, although theoretically the latter can do just about everything the former can. From thomas at xs4all.net Sat Jul 15 23:52:27 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 15 Jul 2000 23:52:27 +0200 Subject: [Python-Dev] More discussion on new infix operators In-Reply-To: ; from huaiyu_zhu@yahoo.com on Sat, Jul 15, 2000 at 01:30:31PM -0700 References: <1248451855-51961207@hypernet.com> Message-ID: <20000715235226.J7340@xs4all.nl> On Sat, Jul 15, 2000 at 01:30:31PM -0700, Huaiyu Zhu wrote: > 1.a) is unacceptable because infix operators improve readability > tremendously compared with prefix operators. Where's the usability study to prove that ? Seriously, though, claiming it is 'unacceptable' without providing arguments ? Why is it unacceptable ? This solution has proven perfectly acceptable for regular expressions, amongst other things. We have Perl gurus, addicted to perl's builtin regexp syntax, join us all the time. And you bet those perl people are addicted to short and confusing notations! > 1.b) is unacceptable because it is too long and involves at least two method > calls and object initialization for each operation. Not necessarily, it depends on your implementation. I would suggest something as follows (probably highly inaccurate because I know didley squat about matrices, but I'll give it a try): class Matrix: "A container class to hold matrices." def __init__(self, ): self.matrix = self.elementwise = ElementwiseMatrix(self.matrix) def __mul__(self, val): return self.matrix.normalmultiply(val) <...> class ElementwiseMatrix: "A container class to hold matrices, implementing elementwise operators." def __init__(self, matrix): self.matrix = matrix def __mul__(self, val): return self.matrix.elementwisemultiply(val) <...> This will allow you to do something like this, given that 'a' and 'b' are Matrices: a.elementwise * b.elementwise to yield a new Matrix (or whatever would be most convenient.) With the Cycle-GC patch, which is in 2.0, you can rewrite them a bit and add some circular references (or you can do that now, if you don't mind having a manual '.destroy()' method) so you can retrieve 'a' if you only have 'a.elementwise'. (Though I would suggest making the front-ends for the real matrix as small as possible, not containing any data themselves, and just create a new one whenever necessary. You just need to be sure not to use 'is' on the front-ends, then, but that's all.) And like this, you can use 'ae = a.elementwise' and pass 'ae' around and operate on it. And this also works immediately with augmented assignment, which might be in 2.0. As for performance, two method calls and an object initialization aren't really a problem, are they ? If you're looking for speed in many little calculations, Python is the wrong language. If you're looking for speed in large calculations, you won't notice this extra overhead. And in the proposal above, the overhead is reduced anyway. And like this, I'd say the whole thing is a lot more Pythonic! And it clearly reflects the 'dual personality' of matrices. > I hope, and I do believe personally, that it will acquire wide-spread usage > once such basic facilities are provided, and will eventually be integrated > into the core language. It would be next to impossible to change operators > at that moment. Therefore I am most interested in hearing any thoughts on > whether there exist any mortal danger for introducing the dot operators. > For example, will it be confused with any planned new language features? Well, I can (and will!) only speak for myself, but in my opinion, the addition of the 'dot' operators would conflict more with the core of the language than any specific feature. The entire philosophy of Python is to keep it as clear and simple and easy to understand as possible. In that light, even the use of the '%' symbol as the printf-operator is a mistake, and I actually agree with that -- even though it's extremely useful. It will be hard to explain to people who have no notion of strings, let alone printf() ;-) The 'dot' operators, though, remind me of the stories about ANSI C and how Microsoft tried to convince the ANSI committee in charge of C to include keywords specifically for the intel architecture. ('near', 'far', and two others, I forget. They are (were?) necessary to deal with the way DOS (and Windows ?) handles Intel's segmented memory model.) Even at that time, the PC was the most used computer around, but the committee decided against including these keywords. The PC might have have been the most used C programming platform, but the committee argued that no single platform should have that much impact on the programming language. (*) I think the 'dot' operators are in the same position. It might bring a lot of people to see the light if it had special matrix syntax, and that syntax might even be applicable in a few other areas without causing too much confusions. And I'd be happy for those people if they did see the light ;) But it stays a single domain, and Python isn't just about drawing as many people to Python as possible. At least, not in my humble opinion. In short, I'm -0 on this idea. If the BDFL is indeed benificial in your case, I won't put up a fight, but I wouldn't add it myself. But-then-I'm-only-+0-on-augmented-assignment-myself<0.3 wink>-ly y'rs, (* This story comes from Peter v.d. Linden's Deep C Secrets. I'm sure Tim, having sat on that committee under one alias or another, can tell this story much more accurately ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sun Jul 16 00:01:56 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 00:01:56 +0200 Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970BA65.5DBFB39A@prescod.net>; from paul@prescod.net on Sat, Jul 15, 2000 at 02:24:21PM -0500 References: <3970B1F4.D4D8BAE9@prescod.net> <010e01bfee90$224df960$f2a6b5d4@hagrid> <3970BA65.5DBFB39A@prescod.net> Message-ID: <20000716000155.K7340@xs4all.nl> On Sat, Jul 15, 2000 at 02:24:21PM -0500, Paul Prescod wrote: > Fredrik Lundh wrote: > > why not just post a site.py patch, and forget about the > > PEP for now? > Also, how should I include a new module in a patch? Do I do a directory > diff? Or just checkin the stupid thing? You can supposedly use 'cvs add' to add the name, and then *not* commit ;) If you then use cvs diff, it should show up. Alternatively, and this is probably best, checkout a new copy of the tree (or simply do a 'cp -pPR') and diff between those two. In franctic times, it can be a hassle to get them both up to date, but if you're just going for a diff that adds a new file, that doesn't matter. (I remember trying to create a good patch in the weekend of July 1st. It was horrible, by the time an update had finished, things it had updated at the start were already changed again :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Sun Jul 16 00:20:49 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 00:20:49 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> <39709962.1C0A576E@lemburg.com> <005c01bfee83$4bafc480$f2a6b5d4@hagrid> <3970A737.6B13B543@lemburg.com> <008b01bfee89$8e731460$f2a6b5d4@hagrid> Message-ID: <3970E3C1.B8718924@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Cool :-) > > oh, just wait until I've gotten my head around Christian's > superoptimizations ;-) BTW, I didn't see your generator script in the patch... could you explain what the tables contain and how they are built ? > > (I'd suggest keeping the original names, BTW) > > unicodedata and unicodectype are okay, but frankly, isn't > "ucnhash" overly cryptic? True. > how about "unicodenames"? Sounds ok to me :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sun Jul 16 00:27:16 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 00:27:16 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: Message-ID: <3970E544.ED8C7213@lemburg.com> Moshe Zadka wrote: > > On Sat, 15 Jul 2000, Fredrik Lundh wrote: > > > paul wrote: > > > As soon as you find a character out of the ASCII range in one of the > > > strings, I think that you should report that the two strings are > > > unequal. > > > > sounds reasonable -- but how do you flag "unequal" in cmp? which > > value is "larger" if all that we know is that they're different... > > We can say something like "beyond the ASCII range, every unicode character > is larger then any regular 8-bit character", and compare > lexicographically. The usual method in the Python compare logic is to revert to the type name for compares in case coercion fails... I think this is the right description in this case: decoding fails and thus coercion becomes impossible. PyObject_Compare() has the logic, we'd just have to reenable it for Unicode which currently is handled as special case to pass through the decoding error. Note that Unicode objects which don't coerce would then always compare larger than 8-bit strings ("unicode" > "string"). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sun Jul 16 00:56:33 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 00:56:33 +0200 Subject: [Python-Dev] Linker problems on Linux References: <3970A619.D2CA39AA@lemburg.com> <20000715204410.I7340@xs4all.nl> Message-ID: <3970EC21.1112C71@lemburg.com> Thomas Wouters wrote: > > On Sat, Jul 15, 2000 at 07:57:45PM +0200, M.-A. Lemburg wrote: > > > I just tried to compile the current CVS version on Linux. > > The compile went fine, but when I started Python, I got: > > > 'import site' failed; use -v for traceback > > Python 2.0b1 (#1, Jul 15 2000, 19:22:33) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > > Traceback (most recent call last): > > File "/home/lemburg/bin/pyinteractive.py", line 7, in ? > > import mx.Tools > > File "/home/lemburg/projects/mx/Tools/__init__.py", line 24, in ? > > from Tools import * > > File "/home/lemburg/projects/mx/Tools/Tools.py", line 10, in ? > > from mxTools import * > > File "/home/lemburg/projects/mx/Tools/mxTools/__init__.py", line 1, in ? > > from mxTools import * > > ImportError: /home/lemburg/projects/mx/Tools/mxTools/mxTools.so: undefined symbol: PyObject_Length > > > Why isn't PyObject_Length being exported anymore ??? > > PyObject_Length is changed into a #define, to PyObject_Size. This preserves > the API but not the ABI ;) GCC has a construct to make one function an alias > for another: > > PyObject * PyObject_Length() __attribute__((alias("PyObject_Size"))); > > But this is not likely to work in other compilers, and not on all > architectures to start with. The most portable solution is probably to make > PyObject_Length() a wrapper for PyObject_Size, and hope the compiler knows > how to handle that most efficiently. Right, there will have to be an exported API PyObject_Length() which then does nothing other than to call PyObject_Size(). There's an example of how this can be done in ceval.c (see the PyEval_CallObject() API). Why hasn't anyone objected to simply dropping such an important API without proper backwards compatibility workaround ? The situation on Windows is already bad enough with extensions compiled against 1.5 causing a segfault... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Sun Jul 16 01:09:01 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 15 Jul 2000 19:09:01 -0400 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <3970EC21.1112C71@lemburg.com> Message-ID: [M.-A. Lemburg] > ... > Why hasn't anyone objected to simply dropping such an important > API without proper backwards compatibility workaround ? If I knew it was happening, I would have whined. And I expect Guido would have screamed. So let's fix it, and move on. I expect patch review isn't as good as it used to be because of the clumsy SourceForge interface, so nobody noticed. > The situation on Windows is already bad enough with extensions > compiled against 1.5 causing a segfault... Hey, your now-buggy old extensions aren't our fault . it's-windows-segfaults-are-a-feature-ly y'rs - tim From thomas at xs4all.net Sun Jul 16 01:53:44 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 01:53:44 +0200 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <3970EC21.1112C71@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 12:56:33AM +0200 References: <3970A619.D2CA39AA@lemburg.com> <20000715204410.I7340@xs4all.nl> <3970EC21.1112C71@lemburg.com> Message-ID: <20000716015344.M7340@xs4all.nl> On Sun, Jul 16, 2000 at 12:56:33AM +0200, M.-A. Lemburg wrote: > Right, there will have to be an exported API PyObject_Length() which > then does nothing other than to call PyObject_Size(). There's an > example of how this can be done in ceval.c (see the PyEval_CallObject() > API). Agreed. I've uploaded a patch that does this to SF. Someone please review it and apply it if desired. I need to head to bed or I won't get breakfast in bed tomorrow ;) > Why hasn't anyone objected to simply dropping such an important > API without proper backwards compatibility workaround ? I claim naivete for myself ;-) I remember seeing the patch go past, and wondering briefly if that wouldn't break binary compatibility. And I remember thinking "Naah, they wouldn't have approved it if that was an issue." :) Green-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bckfnn at worldonline.dk Sun Jul 16 02:02:04 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Sun, 16 Jul 2000 00:02:04 GMT Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <14704.34077.358194.82087@beluga.mojam.com> References: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: <3970fb6d.33279713@smtp.worldonline.dk> On Sat, 15 Jul 2000 10:37:01 -0500 (CDT), you wrote: > >Nothing has really jumped out as the "right" way to express the proposed >builtin that does > > map(None, l1, l2, l3, l4) How about paste? Properly only makes any sense to users who know the unix command tho. regards, finn From paul at prescod.net Sun Jul 16 03:14:30 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 20:14:30 -0500 Subject: [Python-Dev] Help command Message-ID: <39710C75.A7DB127F@prescod.net> Okay, I wrote the help command today. The transcript before was just a Microsoft-style "Technology Preview." I'm pretty happy with the extent to which I can pull in HTML and get lots of content from Fred's HTML distribution immediately. The only trick is finding out where the documentation is. I know that Unix users have a variety of installation patterns and I have no idea if this works at all on the Macintosh. Please help! Here's my current scheme: if os.environ.has_key("PYTHONDOCS"): self.docdir=os.environ["PYTHONDOCS"] else: if os.environ.has_key("PYTHONHOME"): pyhome=os.environ["PYTHONHOME"] else: pyhome=os.path.split( sys.executable )[0] self.docdir=os.path.join( pyhome, "doc" ) testfile=os.path.join( os.path.join( self.docdir, "lib" ), "index.html") if not os.path.exists( testfile ): raise EnvironmentError, ("Cannot find documentation directory" + self.docdir ) -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Sun Jul 16 03:44:55 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 20:44:55 -0500 Subject: [Python-Dev] Help command Message-ID: <39711397.1D3F38A1@prescod.net> Would anyone scream if I just checked this help module in? You can play with it without a site.py patch. Just import it "by hand". A patch is somewhat cumbersome for a new module and a lot less people would try it if they had to hunt down and install a particular patch. I could check it in, we could try it out for a week and then just as easily I could delete it if people don't like it. There is no impact on any other code. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From tim_one at email.msn.com Sun Jul 16 03:52:19 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 15 Jul 2000 21:52:19 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CB@RED-MSG-50> Message-ID: [Bill Tutt] > I just had a rather unhappy epiphany this morning. > F1, and f2 in ucnhash.c might not work on machines where > sizeof(long) != 32 bits. If "not work" means "may not return the same answer as when a long does have exactly 32 bits", then yes, it's certain not to work. Else I don't know -- I don't understand the (undocumented) postconditions (== what does "work" mean, exactly?) for these functions. If getting the same bits is what's important, f1 can be repaired by inserting this new block: /* cut back to 32 bits */ x &= 0xffffffffL; if (x & 0x80000000L) { /* if negative as a 32-bit thing, extend sign bit to full precision */ x -= 0x80000000L; /* subtract 2**32 in a portable way */ x -= 0x80000000L; /* by subtracting 2**31 twice */ } between the existing x ^= cch + 10; and if (x == -1) This assumes that negative numbers are represented in 2's-complement, but should deliver the same bits in the end on any machine for which that's true (I don't know of any Python platform for which it isn't). The same shoe work for f2 after replacing its negative literal with a 0x...L bit pattern too. The assumption about 2's-comp, and the new "if" block, could be removed by making these functions compute with and return unsigned longs instead. I don't know why they're using signed longs now (the bits produced are exactly the same either way, up until the "%" operation, at which point C is ill-defined when using signed long). BTW, you can test stuff like this on Win32 by cloning the function and using _int64 instead of long in the copy, then see whether they get the same results. From gstein at lyra.org Sun Jul 16 05:47:10 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 15 Jul 2000 20:47:10 -0700 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 15, 2000 at 07:09:01PM -0400 References: <3970EC21.1112C71@lemburg.com> Message-ID: <20000715204710.B29590@lyra.org> On Sat, Jul 15, 2000 at 07:09:01PM -0400, Tim Peters wrote: > [M.-A. Lemburg] > > ... > > Why hasn't anyone objected to simply dropping such an important > > API without proper backwards compatibility workaround ? > > If I knew it was happening, I would have whined. And I expect Guido would > have screamed. So let's fix it, and move on. I expect patch review isn't > as good as it used to be because of the clumsy SourceForge interface, so > nobody noticed. That has nothing to do with it. A full discussion occurred here on what to do. The consensus was reached and the code was changed. I knew it was happening, and I hardly ever look at the Patch Manager. In other words, you can't place the blame there. Personally, I had no issue with it at all. Python 1.5 extensions are not compatible with Python 1.6. We knew that already. So if they have to recompile anyways, then they are going to pick up the macro redefinition. No big deal. > > The situation on Windows is already bad enough with extensions > > compiled against 1.5 causing a segfault... Unrelated FUD. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jul 16 05:55:40 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 15 Jul 2000 20:55:40 -0700 Subject: [Python-Dev] Help command In-Reply-To: <39711397.1D3F38A1@prescod.net>; from paul@prescod.net on Sat, Jul 15, 2000 at 08:44:55PM -0500 References: <39711397.1D3F38A1@prescod.net> Message-ID: <20000715205540.C29590@lyra.org> On Sat, Jul 15, 2000 at 08:44:55PM -0500, Paul Prescod wrote: > Would anyone scream if I just checked this help module in? You can play > with it without a site.py patch. Just import it "by hand". A patch is > somewhat cumbersome for a new module and a lot less people would try it > if they had to hunt down and install a particular patch. I could check > it in, we could try it out for a week and then just as easily I could > delete it if people don't like it. There is no impact on any other code. +1. check the sucker in. I would doubt that anybody has a problem with the *idea*. We can quibble over details much easier with it actually part of the distro. Cheers, -g -- Greg Stein, http://www.lyra.org/ From moshez at math.huji.ac.il Sun Jul 16 06:59:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 07:59:06 +0300 (IDT) Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <3970fb6d.33279713@smtp.worldonline.dk> Message-ID: On Sun, 16 Jul 2000, Finn Bock wrote: > On Sat, 15 Jul 2000 10:37:01 -0500 (CDT), you wrote: > > > > >Nothing has really jumped out as the "right" way to express the proposed > >builtin that does > > > > map(None, l1, l2, l3, l4) > > How about paste? Properly only makes any sense to users who know the > unix command tho. I've been using UNIX for the past 5 years, and have only a dim recollection on paste (when I start doing things that require "cut" and "paste" I usually rich for my big guns like Python (and Perl before that)) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Sun Jul 16 07:02:27 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 08:02:27 +0300 (IDT) Subject: [Python-Dev] Help command In-Reply-To: <39710C75.A7DB127F@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Okay, I wrote the help command today. The transcript before was just a > Microsoft-style "Technology Preview." I'm pretty happy with the extent > to which I can pull in HTML and get lots of content from Fred's HTML > distribution immediately. The only trick is finding out where the > documentation is. I know that Unix users have a variety of installation > patterns and I have no idea if this works at all on the Macintosh. > Please help! In a Red Hat installation, they don't install the HTML docs at all. But then, you don't want to know what I think of Red Hat (demonstrating Python on Red Hat systems usually requires me to resort to slight-of-hand tricks every now and then) In a Debian installation, they live in /usr/doc/python/... (In short, have it a compiled in default. Whoever packages it will decide) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Sun Jul 16 07:03:32 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 08:03:32 +0300 (IDT) Subject: [Python-Dev] Help command In-Reply-To: <39711397.1D3F38A1@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Would anyone scream if I just checked this help module in? You can play > with it without a site.py patch. Just import it "by hand". A patch is > somewhat cumbersome for a new module and a lot less people would try it > if they had to hunt down and install a particular patch. I'm +1, as long as the module says on the top ''' # experimental module -- might change interface or die without notice ''' Or something to that effect -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From tim_one at email.msn.com Sun Jul 16 07:24:15 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 01:24:15 -0400 Subject: [Python-Dev] Help command In-Reply-To: <39711397.1D3F38A1@prescod.net> Message-ID: [Paul Prescod] > Would anyone scream if I just checked this help module in? Sure, but who cares? I won't scream at you, and I've been so bitchy lately nobody will even respond to me anymore . Do it! Agree with Moshe that a disclaimer about its experimental nature be prominently displayed at the top, lest we get locked into supporting its initial flawlets forever. From tim_one at email.msn.com Sun Jul 16 07:49:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 01:49:27 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2D5@RED-MSG-50> Message-ID: [Bill Tutt] > After making use of the test drive Alphas by Compaq, I just > uploaded a patch to SF that should fix this nasty issue. > Ugh. Not fun.... Ah, I replied earlier before seeing this. Please see my earlier response for a simpler change that will actually work . Briefly, > > len = cch; > > p = (unsigned char *) key; > > - x = 1694245428; > > + x = (long)0x64fc2234; No point to this change (although there *is* for the *negative* literal in f2). And (for f2) note that the way to spell a long literal is with "L" at the end, not via casting an int literal to long. > > while (--len >= 0) > > - x = (1000003*x) ^ toupper(*(p++)); > > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); No point to either of the changes here (you're effectively doing a mod 2**32 on each step, but that isn't necessary -- doing just one at the end (after the loop) is equivalent). > > x ^= cch + 10; > > - if (x == -1) > > - x = -2; > > + if (x == (long)0xFFFFFFFF) > > + x = (long)0xfffffffe; This is wrong in too many ways to count . But your tests won't show the failure unless x *does* happen to equal -1 at the end of the preceding, and you're extremely unlikely to bump into that in a small batch of test cases. Short course: on the 32-bit long machine, x will be -2 after this block then. But on the 64-bit long machine, x will be 2**32-2 (a large and unrelated positive long). The change I suggested is simpler & avoids all those problems; alas, like the above, it also assumes 2's-complement representation of negative longs. From esr at thyrsus.com Sun Jul 16 08:27:38 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Sun, 16 Jul 2000 02:27:38 -0400 Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <14704.34077.358194.82087@beluga.mojam.com> References: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: <20000716022738.B1517@thyrsus.com> Skip Montanaro : > Nothing has really jumped out as the "right" way to express the proposed > builtin that does > > map(None, l1, l2, l3, l4) > > How about collate? What we're doing is effectively what a copy machine does > when it collates multiple copies of its input... At least as good as "knit" and "plait". Better than "weave" (sorry, Barry) and without the unhelpful connotations of "marry" and "zip". A bit long, though. -- Eric S. Raymond Everything you know is wrong. But some of it is a useful first approximation. From esr at thyrsus.com Sun Jul 16 08:40:25 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Sun, 16 Jul 2000 02:40:25 -0400 Subject: [Python-Dev] what to call this zip() function? In-Reply-To: References: Message-ID: <20000716024025.C1517@thyrsus.com> Ka-Ping Yee : > The analogy with a photocopying machine is pretty good, but > i'm afraid this will play havoc with those who see "collate" in > terms of determining sort order. *ouch* Damn. Ping is right. He just blew "collate" out of the water, folks. > It's fairly clear to me that, of the names that evoke images > of some sort, only "parallel", "march", and "merge" are actually > accurate. "zip" and "marry" are nearly accurate except that they > usually give the impression that only two things are being joined. Well argued (and cool pictures, too!). I think parallel, zip, and marry are out for various reasons of connotative overload, so we're down to "merge", "meld", and "knit". -- Eric S. Raymond The end move in politics is always to pick up a gun. -- R. Buckminster Fuller From effbot at telia.com Sun Jul 16 10:25:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 10:25:05 +0200 Subject: [Python-Dev] what to call this zip() function? References: <20000716024025.C1517@thyrsus.com> Message-ID: <004b01bfeeff$59f28380$f2a6b5d4@hagrid> eric: > ping: > > The analogy with a photocopying machine is pretty good, but > > i'm afraid this will play havoc with those who see "collate" in > > terms of determining sort order. > > *ouch* > > Damn. Ping is right. He just blew "collate" out of the water, folks. is this the end of Python development? just imagine what this crowd would have done if guido had asked you *before* he added things like: dir ("hey, dir should give you a list of filenames") cgi ("the computer graphics crowd won't like that") del ("removes files, right?") compile ("but people will think that it generates machine code") global ("but it's not truly global. how about regional or domestic?") hash ("that's a data type, right?") ("or perhaps something from the The Amsterdam Aloha Seed Bank?") hex ("now wait. it's not clear from the name if it con- verts a hex string to an integer, or the other way around. oh, it's the latter. sorry, but that will confuse perl pro- grammers") type ("is that some variation of print, or?") copy ("I'd say most people expect it to copy entire files") and so on... ... maybe something completely random? how about: ymr116c ("sorry, this will confuse the hell out of yeast researchers") ... how about a new rule: if the group fails to reach consensus on a name, especially if they're not discussion the semantics at all, just pick the original name. "zip", in other words. simple zip patches has already been posted to this list. why not take them on a test drive, and see if the *semantics* are what you want them to be? (in the meantime, maybe someone could run the zip/collate/etc thing by comp.lang.python. maybe people are smarter than we think?) From effbot at telia.com Sun Jul 16 10:33:02 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 10:33:02 +0200 Subject: [Python-Dev] RE: Unicode character name hashing References: Message-ID: <005f01bfef00$75fcbf40$f2a6b5d4@hagrid> tim wrote: > If "not work" means "may not return the same answer as when a long does have > exactly 32 bits", then yes, it's certain not to work. Else I don't know -- > I don't understand the (undocumented) postconditions (== what does "work" > mean, exactly?) for these functions. he's using the hash function to look things up in a static table... fwiw, "ucnhash" might be slightly obsolete (see my "unicodenames" patch for a smaller replacement). as far as I can tell, my hash function should work on a 64-bit machine... ...on the other hand, it currently assumes that an "int" is at least 32 bits. should I change this? do we still pretend to support 16-bit computers? From moshez at math.huji.ac.il Sun Jul 16 10:29:42 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 11:29:42 +0300 (IDT) Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <004b01bfeeff$59f28380$f2a6b5d4@hagrid> Message-ID: On Sun, 16 Jul 2000, Fredrik Lundh wrote: > how about a new rule: if the group fails to reach consensus > on a name, especially if they're not discussion the semantics > at all, just pick the original name. > > "zip", in other words. +1. The dir() example shows that pkzip is a non-issue. (After all, we have a dircache module which has no connection to the builtin dir(), and no one seems to have any problems with that) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From billtut at microsoft.com Sun Jul 16 10:35:56 2000 From: billtut at microsoft.com (Bill Tutt) Date: Sun, 16 Jul 2000 01:35:56 -0700 Subject: [Python-Dev] RE: Unicode character name hashing Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2DE@RED-MSG-50> Not that any of this is terribly important given F bot's new patch, except for wrt to the perfect hash generation code. But... > Tim wrote: > [Bill Tutt] > > I just had a rather unhappy epiphany this morning. > > F1, and f2 in ucnhash.c might not work on machines where > > sizeof(long) != 32 bits. > If "not work" means "may not return the same answer as when a long does have > exactly 32 bits", then yes, it's certain not to work. Else I don't know -- > I don't understand the (undocumented) postconditions (== what does "work" > mean, exactly?) for these functions. "Works" means that f1, and f2 must always generate the same bits no matter what platform they're executed on > If getting the same bits is what's important, f1 can be repaired by > inserting this new block: > /* cut back to 32 bits */ > x &= 0xffffffffL; > if (x & 0x80000000L) { > /* if negative as a 32-bit thing, extend sign bit to full precision */ > x -= 0x80000000L; /* subtract 2**32 in a portable way */ > x -= 0x80000000L; /* by subtracting 2**31 twice */ > } > between the existing > x ^= cch + 10; > and > if (x == -1) > This assumes that negative numbers are represented in 2's-complement, but > should deliver the same bits in the end on any machine for which that's true > (I don't know of any Python platform for which it isn't). The same shoe > work for f2 after replacing its negative literal with a 0x...L bit pattern > too. > The assumption about 2's-comp, and the new "if" block, could be removed by > making these functions compute with and return unsigned longs instead. I > don't know why they're using signed longs now (the bits produced are exactly > the same either way, up until the "%" operation, at which point C is > ill-defined when using signed long). The SF patch does indeed use unsigned longs. Bill From thomas at xs4all.net Sun Jul 16 11:01:51 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 11:01:51 +0200 Subject: [Python-Dev] Help command In-Reply-To: ; from moshez@math.huji.ac.il on Sun, Jul 16, 2000 at 08:02:27AM +0300 References: <39710C75.A7DB127F@prescod.net> Message-ID: <20000716110151.N7340@xs4all.nl> On Sun, Jul 16, 2000 at 08:02:27AM +0300, Moshe Zadka wrote: > On Sat, 15 Jul 2000, Paul Prescod wrote: > > Okay, I wrote the help command today. The transcript before was just a > > Microsoft-style "Technology Preview." I'm pretty happy with the extent > > to which I can pull in HTML and get lots of content from Fred's HTML > > distribution immediately. The only trick is finding out where the > > documentation is. I know that Unix users have a variety of installation > > patterns and I have no idea if this works at all on the Macintosh. > > Please help! > In a Red Hat installation, they don't install the HTML docs at all. > But then, you don't want to know what I think of Red Hat (demonstrating > Python on Red Hat systems usually requires me to resort to slight-of-hand > tricks every now and then) Don't forget that RedHat isn't impervious to outside influence. Adding this help thing might make them realize installing the HTML docs is a good idea ;-) And who knows, they might even add documentation for their snackmodule. +1 on the whole idea from me, too. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sun Jul 16 11:21:59 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 11:21:59 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> <39709962.1C0A576E@lemburg.com> <005c01bfee83$4bafc480$f2a6b5d4@hagrid> <3970A737.6B13B543@lemburg.com> <008b01bfee89$8e731460$f2a6b5d4@hagrid> <3970E3C1.B8718924@lemburg.com> Message-ID: <007d01bfef07$4e53fd80$f2a6b5d4@hagrid> mal wrote: > BTW, I didn't see your generator script in the patch... could > you explain what the tables contain and how they are built ? I'm working on the ctype/data portions right now; I'll update the patch along the way, including the generator script when it's ready. (in other words, treat this patch as experimental until it includes the entire database). From mal at lemburg.com Sun Jul 16 11:29:44 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 11:29:44 +0200 Subject: [Python-Dev] Linker problems on Linux References: <3970EC21.1112C71@lemburg.com> <20000715204710.B29590@lyra.org> Message-ID: <39718088.A4172516@lemburg.com> Greg Stein wrote: > > On Sat, Jul 15, 2000 at 07:09:01PM -0400, Tim Peters wrote: > > [M.-A. Lemburg] > > > ... > > > Why hasn't anyone objected to simply dropping such an important > > > API without proper backwards compatibility workaround ? > > > > If I knew it was happening, I would have whined. And I expect Guido would > > have screamed. So let's fix it, and move on. I expect patch review isn't > > as good as it used to be because of the clumsy SourceForge interface, so > > nobody noticed. > > That has nothing to do with it. A full discussion occurred here on what to > do. The consensus was reached and the code was changed. I don't believe that Guido reached any consensus on this... he has always tried to make releases as binary compatible as possible (which is a very user friendly way of designing software). > I knew it was happening, and I hardly ever look at the Patch Manager. In > other words, you can't place the blame there. > > Personally, I had no issue with it at all. Python 1.5 extensions are not > compatible with Python 1.6. We knew that already. So if they have to > recompile anyways, then they are going to pick up the macro redefinition. Sure they are... what makes you think that 1.5 extensions won't work with 1.6 ? Ok, you get annoying warnings, but it's still better as temporary solution than putting out a new version of Python which won't work together with most existing extensions simply due to linker problems. > No big deal. Ok, Greg, you pay the support bill ;-) > > > The situation on Windows is already bad enough with extensions > > > compiled against 1.5 causing a segfault... > > Unrelated FUD. Why unrelated ? Why FUD ? The problem is real (until we check in the fix). Anyway, enough ranting ;-) ... I'll review Thomas Wouters patch and then check it in. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Sun Jul 16 11:34:50 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 11:34:50 +0200 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <39718088.A4172516@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 11:29:44AM +0200 References: <3970EC21.1112C71@lemburg.com> <20000715204710.B29590@lyra.org> <39718088.A4172516@lemburg.com> Message-ID: <20000716113449.P7340@xs4all.nl> On Sun, Jul 16, 2000 at 11:29:44AM +0200, M.-A. Lemburg wrote: > Anyway, enough ranting ;-) ... I'll review Thomas Wouters patch > and then check it in. Wait a couple of minutes. I didn't follow your instructions closely enough, the new patch does ;-) (old patch just added back the functions as wrappers, but didn't #define them as the PyEval_CallObject one did.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Sun Jul 16 11:43:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 11:43:39 +0200 Subject: [Python-Dev] SF login names Message-ID: <397183CB.6415C6BC@lemburg.com> Is there a login name to real name mapping available on SF ? I'm just asking because login names such as "VizNut" or "nowonder" don't carry enough information to identify the person behind it and I think it would be nice to know who you are talking to in patch dicsussions ;-) Perhaps the initial submission comment should include the full name of the patch author ?! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Sun Jul 16 11:47:57 2000 From: billtut at microsoft.com (Bill Tutt) Date: Sun, 16 Jul 2000 02:47:57 -0700 Subject: [Python-Dev] [patch #100889] a smaller unicode name database] Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2DF@RED-MSG-50> From: "Fredrik Lundh" > > my unicode database compression project has resulted in its first > > patch: > > > > https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100899&gro up_id=5470 > two additional comments: > first, the patch was too large for sourceforge (>512000 bytes), so > I've uploaded it to the secret effbot site instead: > http://w1.132.telia.com/~u13208596/uninames-patch.txt > second, the uninames module provides two public Python functions: > getname(code) returns the character name corresponding to > the given character code, or None if the name is not known. > > getcode(name) returns the character code for the given character > name. again, it returns None if the code is not known. Getcode/getname need to use Py_UCS4 instead of int. Smaller data sizes are definitely cool, but as MAL mentioned you didn't include the genration code, nor an explanation about how the stuff works. Looking good so far! Bill From thomas at xs4all.net Sun Jul 16 11:51:31 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 11:51:31 +0200 Subject: [Python-Dev] SF login names In-Reply-To: <397183CB.6415C6BC@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 11:43:39AM +0200 References: <397183CB.6415C6BC@lemburg.com> Message-ID: <20000716115131.Q7340@xs4all.nl> On Sun, Jul 16, 2000 at 11:43:39AM +0200, M.-A. Lemburg wrote: > Is there a login name to real name mapping available on SF ? There's the search engine: the input field with a selector above it, in the bottom left corner. You can type in 'BigBrassBalz' and select 'people', hit 'search', and it'll tell you that's Tim Peters, and provide a link with more information. > I'm just asking because login names such as "VizNut" or > "nowonder" don't carry enough information to identify the person > behind it and I think it would be nice to know who you are > talking to in patch dicsussions ;-) Well, sometimes the realname isn't even that much help ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sun Jul 16 12:01:40 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 12:01:40 +0200 Subject: [Python-Dev] SF login names References: <397183CB.6415C6BC@lemburg.com> Message-ID: <00c101bfef0c$dad680c0$f2a6b5d4@hagrid> mal wrote: > Is there a login name to real name mapping available on SF ? use the search box in the lower left; just change "software/group" to "people", and type the login name... > I'm just asking because login names such as "VizNut" or > "nowonder" don't carry enough information to identify the > person behind it here's a few: viznut = randall hopper nowonder = peter schneider-kamp flight = gregor hoffleit effbot = dunno htrd = toby dickenson ...and the "what the heck does that mean" award goes to: nyamatongwe = neil hodgson cheers /F From mal at lemburg.com Sun Jul 16 12:07:32 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 12:07:32 +0200 Subject: [Python-Dev] SF login names References: <397183CB.6415C6BC@lemburg.com> <00c101bfef0c$dad680c0$f2a6b5d4@hagrid> Message-ID: <39718964.1679361C@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Is there a login name to real name mapping available on SF ? > > use the search box in the lower left; just change "software/group" > to "people", and type the login name... Thanks for the hint. > > I'm just asking because login names such as "VizNut" or > > "nowonder" don't carry enough information to identify the > > person behind it > > here's a few: > > viznut = randall hopper > nowonder = peter schneider-kamp > flight = gregor hoffleit > effbot = dunno > htrd = toby dickenson > > ...and the "what the heck does that mean" award goes to: > > nyamatongwe = neil hodgson :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sun Jul 16 13:04:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 13:04:45 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> Message-ID: <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> mal wrote: > > 1. treat \x as a hexadecimal byte, not a hexadecimal > > character. or in other words, make sure that > > > > ord("\xabcd") == ord(u"\xabcd") > > > > fwiw, this is how it's done in SRE's parser (see the > > python-dev archives for more background). ... > > 5. leave it as it is (just fix the comment). > > I'd suggest 5 -- makes converting 8-bit strings using \x > to Unicode a tad easier. if that's the main argument, you really want alternative 1. with alternative 5, the contents of the string may change if you add a leading "u". alternative 1 is also the only reasonable way to make ordinary strings compatible with SRE (see the earlier discussion for why SRE has to be strict on this one...) so let's change the question into a proposal: for maximum compatibility with 8-bit strings and SRE, let's change "\x" to mean "binary byte" in unicode string literals too. From effbot at telia.com Sun Jul 16 13:28:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 13:28:19 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> <02c701bfedae$7db6fd20$f2a6b5d4@hagrid> <000d01bfedd7$122db480$f2a6b5d4@hagrid> Message-ID: <00ff01bfef18$f3914260$f2a6b5d4@hagrid> I wrote: > not quite ready to be checked in, but good enough to take > on a test drive: > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 anyone looked at this? should I check it in, and see what happens? From moshez at math.huji.ac.il Sun Jul 16 13:27:21 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 14:27:21 +0300 (IDT) Subject: [Python-Dev] PyErr_SafeFormat In-Reply-To: <00ff01bfef18$f3914260$f2a6b5d4@hagrid> Message-ID: On Sun, 16 Jul 2000, Fredrik Lundh wrote: > anyone looked at this? I did. It looked all right, except for the "default" in the switch statements. or-maybe-i-didn't-understand-it-at-all-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Sun Jul 16 13:37:40 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 13:37:40 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: Message-ID: <011501bfef1a$40495880$f2a6b5d4@hagrid> moshe wrote: > On Sun, 16 Jul 2000, Fredrik Lundh wrote: > > > anyone looked at this? > > I did. It looked all right, except for the "default" in the switch > statements. what's wrong with the default clause? the idea is that if it stumbles upon a formatting code it doesn't understand, it copies the rest of the format string to the output string (it cannot just skip unknown codes, since there's no way to know what's in the argument list...) if you can think of a better approach, let me know asap. cheers /F From moshez at math.huji.ac.il Sun Jul 16 13:55:18 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 14:55:18 +0300 (IDT) Subject: [Python-Dev] PyErr_SafeFormat In-Reply-To: <011501bfef1a$40495880$f2a6b5d4@hagrid> Message-ID: On Sun, 16 Jul 2000, Fredrik Lundh wrote: > what's wrong with the default clause? That it wasn't clear... > the idea is that if it stumbles upon a formatting code it doesn't > understand, it copies the rest of the format string to the output > string (it cannot just skip unknown codes, since there's no way > to know what's in the argument list...) Seems reasonable. I'm +1 on that as long as you take the above paragraph and stick it in a comment somewhere in the patch. aw-to-hel-with-documentation-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From mal at lemburg.com Sun Jul 16 14:13:57 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 14:13:57 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> Message-ID: <3971A705.B23AD7D3@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > > 1. treat \x as a hexadecimal byte, not a hexadecimal > > > character. or in other words, make sure that > > > > > > ord("\xabcd") == ord(u"\xabcd") > > > > > > fwiw, this is how it's done in SRE's parser (see the > > > python-dev archives for more background). > ... > > > 5. leave it as it is (just fix the comment). > > > > I'd suggest 5 -- makes converting 8-bit strings using \x > > to Unicode a tad easier. > > if that's the main argument, you really want alternative 1. > > with alternative 5, the contents of the string may change > if you add a leading "u". Ah ok, now I understand what you meant "\xfffe" will turn out as "\xfe", while u"\xfffe" results in u"\ufffe". > alternative 1 is also the only reasonable way to make ordinary > strings compatible with SRE (see the earlier discussion for why > SRE has to be strict on this one...) > > so let's change the question into a proposal: > > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. Hmm, this is probably not in sync with C9X (see section 6.4.4.4), but then perhaps we should depreciate usage of \xXX in the context of Unicode objects altogether. Our \uXXXX notation is far superior to what C9X tries to squeeze into \x (IMHO at least). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sun Jul 16 14:25:12 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 14:25:12 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> <02c701bfedae$7db6fd20$f2a6b5d4@hagrid> <000d01bfedd7$122db480$f2a6b5d4@hagrid> <00ff01bfef18$f3914260$f2a6b5d4@hagrid> Message-ID: <3971A9A8.705AA86E@lemburg.com> Fredrik Lundh wrote: > > I wrote: > > > not quite ready to be checked in, but good enough to take > > on a test drive: > > > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 > > anyone looked at this? > > should I check it in, and see what happens? The patch needs some docs which go into api.tex. Right now, all formatting codes supported by printf() are allowed. Your patch changes this into a useful, but far more limited set of codes. In the end, I would prefer the solution I mentioned a few days ago: add checks to configure which determine the availability of snprintf() and then put a macro def into pyport.h which either uses snprintf() (if available) or simply drops the length argument and sticks with sprintf(). Since snprintf() will become a standard anyway, why try to emulate its behaviour ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Sun Jul 16 14:45:02 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 15:45:02 +0300 (IDT) Subject: [Python-Dev] PyErr_SafeFormat In-Reply-To: <3971A9A8.705AA86E@lemburg.com> Message-ID: On Sun, 16 Jul 2000, M.-A. Lemburg wrote: > In the end, I would prefer the solution I mentioned a few days > ago: add checks to configure which determine the availability > of snprintf() and then put a macro def into pyport.h which > either uses snprintf() (if available) or simply drops the > length argument and sticks with sprintf(). > > Since snprintf() will become a standard anyway, why try to > emulate its behaviour ? I'm -1 on that approach. Python tries to cater to low-end C compilers as well, and even when snprintf() will become a standard, it will take time to become a widely available standard. /F's patch works *right* *now* on almost every C compiler. python-turned-ansi-only-when-c9x-is-on-the-brink-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From barry at scottb.demon.co.uk Sun Jul 16 14:46:56 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 16 Jul 2000 13:46:56 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <20000714141801.T29590@lyra.org> Message-ID: <000001bfef23$ec90ce30$060210ac@private> I've been looking at the code to see how hard it is to implement my two function solution to the mismatched extensions crash. I can do the work to generate a patch if the following analysis and design is acceptable. Requirements as I see it are: 1. Python extensions must match the python core to work correctly 2. Python must only load an extension that is compatible with its API 3. Extensions written against python15 do not have to work against python16 etc. 4. No Python Core resources available for implementing backward compatibility for API changes. 5. Extension writers prefer new version of Python to refuse to load old extensions rather the risk subtle bugs through compatibility code in core. I'll use XXX to stand in for the extension name. The changes require that pointers to two functions are returned rather the one to initXXX. The function prefixes "init" and "APIversion" might be made more python specific rather then generic. I propose: - PythonExtensionInitModuleXXX - PythonExtenaionApiVersionXXX The current code calls _PyImport_GetDynLoadFunc that is implemented once for each OS. There are 9 implemented currently. Each does the prepend of "init" to the "shortname" function name. If two function pointers are to be returned then the single function _PyImport_GetDynLoadFunc will need to change into a pair of functions to prevent the possiblity of loading the shared lib twice. _PyImport_GetDynLoadModule return a handle to a dynamically loaded module _PyImport_GetDynLoadFunction return a pointer to a function from a module _PyImport_LoadDynamicModule would call _PyImport_GetDynLoadModule once to load the module and then call _PyImport_GetDynLoadFunction twice to get the pair of function pointers. [Q: _PyImport_LoadDynamicModule may still crash if the Python cannot catch failures in the OS load mechanism.] _PyImport_GetDynLoadFunction will no longer prefix the "init" as that is part of the algorithm of _PyImport_LoadDynamicModule. _PyImport_GetDynLoadFunction would do any name manging that the OS requires to load find the symbol. Prefixing of "_" for example on some unixes. Each extension module implements PythonExtensionInitModuleXXX and PythonExtensionApiVersionXXX. PythonExtensionInitModuleXXX is implemented as before. PythonExtensionApiVersionXXX returns the value PYTHON_API_VERSION as defined in modsupport.h. [Q: Is PYTHON_API_VERSION the corrent symbol?] int PythonExtensionApiVersionXXX() { return PYTHON_API_VERSION; } void PythonExtensionInitModuleXXX() { /* init stuff for module XXX */ } _PyImport_LoadDynamicModule will: 1. Try to load the module - on failure reports an error 2. Try to find PythonExtensionInitModuleXXX from module - on failure report not a python extension - no initXXX function 3. Try to find PythonExtensionApiVersionXXX from module - on failure report its an old extension - please upgrade 4. Call PythonExtensionApiVersionXXX and compare to PYTHON_API_VERSION - if not equal report its an old extension - please upgrade 5. Call PythonExtensionInitModuleXXX Comments please? BArry From bckfnn at worldonline.dk Sun Jul 16 14:42:01 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Sun, 16 Jul 2000 12:42:01 GMT Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> Message-ID: <39719b4f.12749973@smtp.worldonline.dk> [Fredrik Lundh] >mal wrote: > >> > 1. treat \x as a hexadecimal byte, not a hexadecimal >> > character. or in other words, make sure that >> >=20 >> > ord("\xabcd") =3D=3D ord(u"\xabcd") >> >=20 >> > fwiw, this is how it's done in SRE's parser (see the >> > python-dev archives for more background). >... >> > 5. leave it as it is (just fix the comment). >>=20 >> I'd suggest 5 -- makes converting 8-bit strings using \x >> to Unicode a tad easier. > >if that's the main argument, you really want alternative 1. > >with alternative 5, the contents of the string may change >if you add a leading "u". > >alternative 1 is also the only reasonable way to make ordinary >strings compatible with SRE (see the earlier discussion for why >SRE has to be strict on this one...) > >so let's change the question into a proposal: > > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. This would potentially break JPython where the \x is already used to introduce 16-bit chars in ordinary strings. OTOH the implementation of \x in JPython is so full of bugs and inconsistencies that I'm +1 on your proposal. regards, finn From gmcm at hypernet.com Sun Jul 16 15:07:55 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sun, 16 Jul 2000 09:07:55 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007141437.JAA13178@cj20424-a.reston1.va.home.com> References: Your message of "Thu, 13 Jul 2000 14:34:03 -0400." <396E0B9B.DD74EF5@interet.com> Message-ID: <1248369603-56908500@hypernet.com> There seems to be some confusion about this subject. Clarification: An extension compiled for 1.5 will, when loaded by 1.6 / 2.0 either: - fail to load (python15.dll not found) - crash (python15.dll found) This is because the typical way of building an extension on Windows has you link against the import lib for the current version of Python. An import lib is nothing like a static lib - it's a bit of stub code (which gets statically linked in) which automatically does the dynamic load of the associated dll. In other words, python15.lib (the import lib) automatically loads python15.dll at runtime. 1) One proposed solution was to remove the version number from the python dll, and rely on binary compatibility. As Mark said, this would "probably" work. The problem being that moving from "probably" to "certainly" is very difficult. And a failure would be every bit as messy as the current situation (crash - except you've removed any easy way of diagnosing the situation). 2) Another was to stop putting pythonxx.dll in the system directory - that breaks COM support. 3) Another is to have the 1.6 / 2.0 installer remove any other versions of the python dll from the system directory. But that breaks having multiple versions of python installed (which *does* work). 4) Another would be to build extensions with the version number in the name (eg, kjbuckets15.dll), with some added magic to the c-extension import code (so "import kjbuckets" evaluates to loading "kjbuckets" + sys.winver-with-the-dot- removed + ['.dll' | '.pyd']). I don't think this would break anything (but it would tax the capabilities of your typical Windows developer ). 5) The last "solution" I can think of is the Tcl stubs mechanism. In this scenario, the extension would not link against any import lib for python at all. It would rely on getting a pointer to a (large) table of pointers to python-exported functions and symbols in the initmodule call. There's a lot of drudge work involved in setting this up. It does mean that binary compatibility can always be maintained, or if it's decided to break binary compatibility, failure can be made "graceful" . (It also means that embedders could statically link in python, and still dynamically load extensions). Unfortunately, this solution still doesn't help with the transition from 1.5 to 1.6 / 2.0. 6) Of course, we can also do nothing. This is not as bad as it has been painted. Extensions on Windows are supposed to live in the DLLs subdirectory (although certain package writers don't follow this convention); and since this is a new install, it's a new directory. So we tell users not to move extensions from their old install into the new one. Extension writers who don't follow this convention (you know who you are) can figure out their own responses. In an ideal world, I rather like #5 (stubs), but I vote for #4 (version number in the extension module name) or #6 (get a life). - Gordon From nhodgson at bigpond.net.au Sun Jul 16 15:24:23 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Sun, 16 Jul 2000 23:24:23 +1000 Subject: [Python-Dev] SF login names References: <397183CB.6415C6BC@lemburg.com> <00c101bfef0c$dad680c0$f2a6b5d4@hagrid> Message-ID: <038501bfef29$295f9210$8119fea9@neil> > ...and the "what the heck does that mean" award goes to: > > nyamatongwe = neil hodgson About as off-topic as possible ;) nyama="meat" and ngwe="piece of land" so maybe place with good hunting. Its a hill in South-East Zimbabwe and I haven't managed to get there yet. Place names make good account and password names as they can be fairly obscure but still memorable. I expected to fix SourceForge up with a more obvious name once the account was working but its a pain to change stuff on SF so haven't done so. Neil From paul at prescod.net Sun Jul 16 15:49:45 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 08:49:45 -0500 Subject: [Python-Dev] Help command References: Message-ID: <3971BD79.D4F378CD@prescod.net> Moshe Zadka wrote: > > ... > > In a Red Hat installation, they don't install the HTML docs at all. What docs are installed? As I recall, "man Python" was similarly useless on my last Red Hat machine. Hopefully that's been fixed but of course we don't deliver our docs in man format. It was very frustrating to find Python "hidden" like that when I knew that Red Hat uses it extensively themselves. I also wanted it to have an icon in their little start menu thing. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Sun Jul 16 15:51:06 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 08:51:06 -0500 Subject: [Python-Dev] htmllib Message-ID: <3971BDCA.1D69F1CB@prescod.net> I'm having a problem with htmllib. It worked fine in the alpha but not now. I presume it is either sre or unicode. Before I "dig in", is htmllib supposed to work or is someone still working on incompatibilities between it and sre/unicode. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Sun Jul 16 16:04:43 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 09:04:43 -0500 Subject: [Python-Dev] what to call this zip() function? References: <20000716024025.C1517@thyrsus.com> <004b01bfeeff$59f28380$f2a6b5d4@hagrid> Message-ID: <3971C0FB.9EDDF76@prescod.net> Fredrik Lundh wrote: > > ... > > (in the meantime, maybe someone could run the zip/collate/etc > thing by comp.lang.python. maybe people are smarter than we > think?) Agree that the universe will not collapse no matter what name we choose. Unless it has a totally backwards name, people will see it in use and figure it out. We could just do a straight-up vote and be done with it. There is clearly no right or wrong answer, just answers that appeal to various people. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From moshez at math.huji.ac.il Sun Jul 16 16:08:58 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 17:08:58 +0300 (IDT) Subject: [Python-Dev] Help command In-Reply-To: <3971BD79.D4F378CD@prescod.net> Message-ID: On Sun, 16 Jul 2000, Paul Prescod wrote: > > In a Red Hat installation, they don't install the HTML docs at all. > > What docs are installed? The LaTeX files. Did I say how much I enjoy working on Red Hat machines yet? linux-users-should-use-a-real-distribution-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Sun Jul 16 16:09:47 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 16:09:47 +0200 Subject: [Python-Dev] Help command In-Reply-To: <3971BD79.D4F378CD@prescod.net>; from paul@prescod.net on Sun, Jul 16, 2000 at 08:49:45AM -0500 References: <3971BD79.D4F378CD@prescod.net> Message-ID: <20000716160947.T7340@xs4all.nl> On Sun, Jul 16, 2000 at 08:49:45AM -0500, Paul Prescod wrote: > Moshe Zadka wrote: > > In a Red Hat installation, they don't install the HTML docs at all. > What docs are installed? As I recall, "man Python" was similarly useless > on my last Red Hat machine. Hopefully that's been fixed but of course we > don't deliver our docs in man format. It was very frustrating to find > Python "hidden" like that when I knew that Red Hat uses it extensively > themselves. I also wanted it to have an icon in their little start menu > thing. Last I checked, the documentation came in a seperate RPM apckage, And it was just the TeX files, not HTML. And it was just the Library Reference in /usr/doc/python-docs-1.5.2/Doc/, not Doc/lib as one would expect. Oh, there seems to be the Language Reference as well, in /usr/doc/python-docs-1.5.2/Doc/ref/, but those are in FrameMaker format (ref*.doc files. Never heard of FrameMaker myself.) In short, ferget it ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From dberlin at redhat.com Sun Jul 16 16:21:11 2000 From: dberlin at redhat.com (Daniel Berlin+list.python-dev) Date: 16 Jul 2000 10:21:11 -0400 Subject: [Python-Dev] Help command In-Reply-To: Moshe Zadka's message of "Sun, 16 Jul 2000 17:08:58 +0300 (IDT)" References: Message-ID: Moshe Zadka writes: > On Sun, 16 Jul 2000, Paul Prescod wrote: > > > > In a Red Hat installation, they don't install the HTML docs at all. > > > > What docs are installed? > > The LaTeX files. Did I say how much I enjoy working on Red Hat machines > yet? > Yeah, and we love you too. J/K. If you like, I can yell at the people responsible for this, but i'm sure they'll just flame me. --Dan From gmcm at hypernet.com Sun Jul 16 16:57:45 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sun, 16 Jul 2000 10:57:45 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <000001bfef23$ec90ce30$060210ac@private> References: <20000714141801.T29590@lyra.org> Message-ID: <1248363013-57304903@hypernet.com> Barry Scott wrote: > I've been looking at the code to see how hard it is to > implement my two function solution to the mismatched > extensions crash. > > I can do the work to generate a patch if the following > analysis and design is acceptable. > > Requirements as I see it are: > > 1. Python extensions must match the python core to work correctly Not necessarily. > 2. Python must only load an extension that is compatible with its > API > 3. Extensions written against python15 do not have to work > against python16 etc. > 4. No Python Core resources available for implementing backward > compatibility for API changes. > 5. Extension writers prefer new version of Python to refuse to > load > old extensions rather the risk subtle bugs through > compatibility code in core. > > I'll use XXX to stand in for the extension name. > > The changes require that pointers to two functions are > returned rather the one to initXXX. You may be making things more complex than they need to be. On (most?) *nixen, a dynamic load is basically a runtime link. If the link fails (a symbol has disappeared), the module won't load. IOW, I think it's really only when an API call has changed semantics that you need to worry. [Some unixen still don't support dynamic loading; others, eg AIX, do it sufficiently differently to cause havoc with portability; but I think it's fair to say it's a "runtime link".] Further, it's now common practice to have xxx.so be a link to xxx.major.minor.shoesize.so, so diagnosis is relatively easy. In other words, aren't we *only* worried about Windows? If not, then: > int PythonExtensionApiVersionXXX() > { > return PYTHON_API_VERSION; > } is rather restrictive, since you can't write a module at 2.1 time that declares itself compatible with 2.0. Better to pass in the running version, and return yes / no. Now on Windows, since a good chunk of the "link" was done at compile time, the only possible answer is return arg == PYTHON_API_VERSION; But if we're only worried about Windows, I think hacking the Windows load code to turn import kjbuckets into a LoadLibraryEx of kjbuckets+2digitversion+extension does the same thing with less pain. OTOH, I'm willing to live with a procedural solution: - the installer creates a fresh DLLs subdirectory - users are warned not to move extensions into the new DLLs directory, but to get new ones - extension writers who don't use the DLLs directory can - be glad they coded defensively - be sorry they didn't. - Gordon From paul at prescod.net Sun Jul 16 16:20:29 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 09:20:29 -0500 Subject: [Python-Dev] Help command References: Message-ID: <3971C4AD.74EFAD90@prescod.net> Moshe Zadka wrote: > > On Sun, 16 Jul 2000, Paul Prescod wrote: > > > > In a Red Hat installation, they don't install the HTML docs at all. > > > > What docs are installed? > > The LaTeX files. Did I say how much I enjoy working on Red Hat machines > yet? > > linux-users-should-use-a-real-distribution-ly y'rs, Z. Does "man python" work yet? Or maybe my installation was just messed up. As an aside, I think that there are three reasons that it would be nice if we delivered the Python documentation in man format: 1. man(1) die-hards (blow-hards!) would be happy 2. man open() etc. would return Python information which is a way of advertising Python 3. documenting every function in every programming language in a common namespace is a ridiculous idea and by contributing to the problem we can do our part to kill a tool that has lived long past its time. :) -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Sun Jul 16 17:33:13 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 10:33:13 -0500 Subject: [Python-Dev] Help command References: Message-ID: <3971D5B9.A39DA465@prescod.net> "Daniel Berlin+list.python-dev" wrote: > > ... > > If you like, I can yell at the people responsible for this, but i'm > sure they'll just flame me. Wouldn't it make sense for the people packaging the software to talk directly to the people creating the software? I want to put an interactive intepreter dependency on the HTML documentation. I need a guarantee that future Red Hats will install the help files properly. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From thomas at xs4all.net Sun Jul 16 17:58:35 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 17:58:35 +0200 Subject: [Python-Dev] Help command In-Reply-To: <3971C4AD.74EFAD90@prescod.net>; from paul@prescod.net on Sun, Jul 16, 2000 at 09:20:29AM -0500 References: <3971C4AD.74EFAD90@prescod.net> Message-ID: <20000716175835.Y7340@xs4all.nl> On Sun, Jul 16, 2000 at 09:20:29AM -0500, Paul Prescod wrote: > Does "man python" work yet? Or maybe my installation was just messed up. Nope. > As an aside, I think that there are three reasons that it would be nice > if we delivered the Python documentation in man format: > 1. man(1) die-hards (blow-hards!) would be happy Hey, I resemble that remark ! I actually use the Perl manpages every now and then, because it's hard to find stuff about operators and special variables in perldoc. But then, there is hardly any need for that in Python ;) > 2. man open() etc. would return Python information which is a way of > advertising Python 'man open()' would probably return the 'open' command (catagory 1) from the 'open' package, at least on Linux :-) On other systems, it would most likely show the 'open' system call, not the python call. You'd have to fix manpath to search python paths before system paths for that ;) I'm not against supplying the Python library reference in man-form, I'm just not very sure what form it would have or how useful it would be. > 3. documenting every function in every programming language in a common > namespace is a ridiculous idea and by contributing to the problem we can > do our part to kill a tool that has lived long past its time. :) Say what you will, man(1) is a great tool for what it does. Info sucks for that, so does HTML. Info is a nice way to bundle a package's information, and to supply introductions and extended manuals in a way that 'man' cannot, but man stays the quickest quick-ref, man! (But I agree, adding TCL and Perl (and Python!) functions in the common manpath is a silly idea. Lets keep it for the C/POSIX API, commands and the system files ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sun Jul 16 18:12:00 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 18:12:00 +0200 Subject: [Python-Dev] htmllib References: <3971BDCA.1D69F1CB@prescod.net> Message-ID: <001d01bfef40$9383d860$f2a6b5d4@hagrid> paul wrote: > I'm having a problem with htmllib. It worked fine in the alpha but not > now. I presume it is either sre or unicode. Before I "dig in", is > htmllib supposed to work or is someone still working on > incompatibilities between it and sre/unicode. probably SRE. try replacing "import re" with "import pre; re = pre" in htmllib.py, and see if the problem goes away. From tim_one at email.msn.com Sun Jul 16 18:49:51 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 12:49:51 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2DE@RED-MSG-50> Message-ID: [Bill Tutt] > Not that any of this is terribly important given F bot's new patch ... Ack! Nevermind. Old and in the way. From tim_one at email.msn.com Sun Jul 16 18:49:53 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 12:49:53 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <005f01bfef00$75fcbf40$f2a6b5d4@hagrid> Message-ID: [/F] > fwiw, "ucnhash" might be slightly obsolete (see my "unicodenames" patch > for a smaller replacement). as far as I can tell, my hash function should > work on a 64-bit machine... Will look at it once I find it . > ...on the other hand, it currently assumes that an "int" is at > least 32 bits. > > should I change this? Absolutely! "long" is the only way current C has to spell "at least 32". A natural opportunity to put some C9X-derived typedefs into pyport.h, like typedef long Py_int_fast32_t; typedef unsigned long Py_uint_fast32_t; That may be a lie on some 64-bit machines, but it's a benign lie (i.e., will still *work*), and people working on those machines can slop in the #ifdef's they need to cut those back to int (or even short) when appropriate. > do we still pretend to support 16-bit computers? I don't, but we're interested in minimizing the amount of telepathy needed to understand the code regardless. Guido most often used "long" to mean "at least 32" elsewhere in the codebase (this is why the Reference Manual guarantees that a Python int is at least 32 bits, i.e. because C guarantees "long" is) -- in accord with good C practice at the time, and, as it turned out, with what ISO/ANSI standardized. "int" doesn't mean anything to me when I see it except "huh -- this code is probably going to break someday" <0.5 wink>. The C9X typedefs allow to remove all guessing about intent. From effbot at telia.com Sun Jul 16 19:18:37 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 19:18:37 +0200 Subject: [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> Message-ID: <004101bfef49$e2c0cb00$f2a6b5d4@hagrid> > so let's change the question into a proposal: > > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. I've prepared a small patch. If nobody objects, I'll check it in next weekend, or so... http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100912&group_id=5470 From mal at lemburg.com Sun Jul 16 19:58:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 19:58:23 +0200 Subject: [Python-Dev] RE: Unicode character name hashing References: Message-ID: <3971F7BF.321997AA@lemburg.com> Tim Peters wrote: > [hash function in unicodename] > > ...on the other hand, it currently assumes that an "int" is at > > least 32 bits. > > > > should I change this? > > Absolutely! "long" is the only way current C has to spell "at least 32". Note that Unicode code which needs enough bits to hold a UCS4 value should always use the Py_UCS4 type (see unicodeobject.h)... any changes needed to assure the 32-bit nature should then be made to the Py_UCS4 typedef. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sun Jul 16 19:59:33 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 19:59:33 +0200 Subject: [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> <004101bfef49$e2c0cb00$f2a6b5d4@hagrid> Message-ID: <3971F805.D6937139@lemburg.com> Fredrik Lundh wrote: > > > so let's change the question into a proposal: > > > > for maximum compatibility with 8-bit strings and SRE, > > let's change "\x" to mean "binary byte" in unicode string > > literals too. > > I've prepared a small patch. If nobody objects, I'll check > it in next weekend, or so... > > http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100912&group_id=5470 There were objections from Finn Bock and myself: \xXXXX is defined to mean "read all hex chars until the next non-hex char and then cast to the underlying type (char or wchar_t)" in C9X. Don't know about Java... Finn ? Not that this definition is optimal, but we should stick to what the standard says and only depreciate usage of \xXXXX in favour of \uXXXX. Code using escapes like "\xABCD" which then results in "\xCD" is broken anyway -- having u"\xABCD" return "\uABCD" wouldn't make much of a difference (+ the bug would become pretty obvious if viewed in a Unicode aware viewer: Asian characters are very easy to recognize in ASCII text ;-) Would it be hard to make JPython support \uXXXX ? (Or does it already ?) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From DavidA at ActiveState.com Sun Jul 16 20:15:17 2000 From: DavidA at ActiveState.com (David Ascher) Date: Sun, 16 Jul 2000 11:15:17 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B7F3.28F64A3E@prescod.net> Message-ID: > help is not a magical function/statement but an instance with a repr > that does the right thing. And yes, it will probably only be loaded at > the repl. Or it could be a 10-line instance that loads its content when > it is actually used. That might allow Geez, guys, that's one of the first things I did for Python! The URL is long dead, but i think there's a version in the contrib ftp directory. I think I called it ihelp. I used the emacs info files, so is way out of date. --david PS: Then again, these days I'd rather work out an API for a help lookup mechanims that the twelve IDEs could all use, rather than encourage people to stick with glass tty's =). From tim_one at email.msn.com Sun Jul 16 20:14:02 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 14:14:02 -0400 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: <3971A705.B23AD7D3@lemburg.com> Message-ID: [/F] > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. [MAL] > Hmm, this is probably not in sync with C9X (see section 6.4.4.4), The behavior of \x in C9X is nearly incomprehensible -- screw it. > but then perhaps we should depreciate usage of \xXX in the context > of Unicode objects altogether. Our \uXXXX notation is far > superior to what C9X tries to squeeze into \x (IMHO at least). \x is a hack inherited from the last version of C, put in back when they knew they had to do *something* to support "big characters" but had no real idea what. C9X was not allowed to break anything in the std it built on, so they kept all the old implementation-defined \x behavior, and made it even more complicated so it would make some kind sense with the new C9X character gimmicks. Python is stuck trying to make sense out of its ill-considered adoption of old-C's \x notation too. Letting it mean "a byte" regardless of context should make it useless enough that people will eventually learn to avoid it . Note that C9X also has \u and \U notations, and \u in C9X means what it does in Python, except that C9X explicitly punts on what happens for \u values in these (inclusive) ranges: \u0000 - \u0020 \u007f - \u009f \ud800 - \udfff \U is used in C9X for 8-digit (hex) characters, deferring to ISO 10646. If C9X didn't *have* to keep \x around, I'm sure they would have tossed it. From jeremy at beopen.com Sun Jul 16 20:24:20 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Sun, 16 Jul 2000 14:24:20 -0400 (EDT) Subject: [Python-Dev] Linker problems on Linux In-Reply-To: References: <3970EC21.1112C71@lemburg.com> Message-ID: <14705.64980.579728.132423@bitdiddle.concentric.net> >>>>> "TP" == Tim Peters writes: TP> [M.-A. Lemburg] >> ... Why hasn't anyone objected to simply dropping such an >> important API without proper backwards compatibility workaround ? TP> If I knew it was happening, I would have whined. And I expect TP> Guido would have screamed. Actually, I wasn't sure we had reached consensus on the list before I checked it in, so I got an explicit okay from Guido before I made the changes. I know I didn't think about binary compatibility, and suspect that Guido overlooked it as well. TP> So let's fix it, and move on. I TP> expect patch review isn't as good as it used to be because of TP> the clumsy SourceForge interface, so nobody noticed. We got reviews of the patch, too. Fred suggested a small cleanup of the original patch. That said, I don't object to binary compatibility. I'm +0 on the patch. Jeremy From dberlin at redhat.com Sun Jul 16 20:23:43 2000 From: dberlin at redhat.com (Daniel Berlin+list.python-dev) Date: 16 Jul 2000 14:23:43 -0400 Subject: [Python-Dev] Help command In-Reply-To: Paul Prescod's message of "Sun, 16 Jul 2000 10:33:13 -0500" References: <3971D5B9.A39DA465@prescod.net> Message-ID: Paul Prescod writes: > "Daniel Berlin+list.python-dev" wrote: > > > > ... > > > > If you like, I can yell at the people responsible for this, but i'm > > sure they'll just flame me. > > Wouldn't it make sense for the people packaging the software to talk > directly to the people creating the software? Let me find out who owns that RPM. I'm just on the same mailing lists as the development department and whatnot. (I'm a GDB engineer, Cygnus was bought by redhat) > I want to put an > interactive intepreter dependency on the HTML documentation. I need a > guarantee that future Red Hats will install the help files properly. From tim_one at email.msn.com Sun Jul 16 20:24:56 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 14:24:56 -0400 Subject: [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? In-Reply-To: <3971F805.D6937139@lemburg.com> Message-ID: [/F] > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. > > I've prepared a small patch. If nobody objects, I'll check > it in next weekend, or so... > > [patch 100912] [MAL] > There were objections from Finn Bock and myself: \xXXXX is > defined to mean "read all hex chars until the next non-hex char > and then cast to the underlying type (char or wchar_t)" in C9X. Python and C9X are different languages -- Python isn't obligated to ape C9X's backward-compatibility hacks. > Don't know about Java... Finn ? Java doesn't have \x notation, period -- Java isn't insane . Finn was talking about JPython's attempts to make sense of Python's \x notation. > Not that this definition is optimal, but we should stick to what > the standard says ... Why? It's a standard for a different language. Most of what C9X says about \x boils down to "implementation-defined" anyway, and that's unPythonic on the face of it. From effbot at telia.com Sun Jul 16 20:34:29 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 20:34:29 +0200 Subject: [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> <004101bfef49$e2c0cb00$f2a6b5d4@hagrid> <3971F805.D6937139@lemburg.com> Message-ID: <007701bfef54$848a2300$f2a6b5d4@hagrid> mal wrote: > There were objections from Finn Bock and myself: \xXXXX is > defined to mean "read all hex chars until the next non-hex char > and then cast to the underlying type (char or wchar_t)" in C9X. finn wrote: "the implementation of \x in JPython is so full of bugs and inconsistencies that I'm +1 on your proposal." since when is +1 an objection? ;-) > Not that this definition is optimal, but we should stick to what > the standard says and only depreciate usage of \xXXXX in favour > of \uXXXX. Code using escapes like "\xABCD" which then results > in "\xCD" is broken anyway -- having u"\xABCD" return "\uABCD" > wouldn't make much of a difference (+ the bug would become pretty > obvious if viewed in a Unicode aware viewer: Asian characters are > very easy to recognize in ASCII text ;-) as Tim pointed out in the SRE thread, the only standard that means something here is Python 1.5.2. And in Python 1.5.2, \u means read as many hex digits as you can, and cast the result to a character. I'd say it's more important to be compatible with Python (1.5.2 string literals, SRE regular expression literals), than to be com- patible with C9X... From tim_one at email.msn.com Sun Jul 16 20:29:46 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 14:29:46 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <3971F7BF.321997AA@lemburg.com> Message-ID: [MAL] > Note that Unicode code which needs enough bits to hold a UCS4 > value should always use the Py_UCS4 type (see unicodeobject.h)... > any changes needed to assure the 32-bit nature should then > be made to the Py_UCS4 typedef. That's fine. The Py_UCS4 typedef should in turn be defined by direct reference to a C9X-derived typedef from pyport.h: the latter is where 32-bitness "should be" defined. Then the only changes ever needed will be to pyport.h (where people will *expect* such changes to get made). From mal at lemburg.com Sun Jul 16 20:33:45 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 20:33:45 +0200 Subject: [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> <004101bfef49$e2c0cb00$f2a6b5d4@hagrid> <3971F805.D6937139@lemburg.com> <007701bfef54$848a2300$f2a6b5d4@hagrid> Message-ID: <39720009.970A7159@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > There were objections from Finn Bock and myself: \xXXXX is > > defined to mean "read all hex chars until the next non-hex char > > and then cast to the underlying type (char or wchar_t)" in C9X. > > finn wrote: > > "the implementation of \x in JPython is so full of bugs > and inconsistencies that I'm +1 on your proposal." > > since when is +1 an objection? ;-) Ooops, I must have overlooked that one. > > Not that this definition is optimal, but we should stick to what > > the standard says and only depreciate usage of \xXXXX in favour > > of \uXXXX. Code using escapes like "\xABCD" which then results > > in "\xCD" is broken anyway -- having u"\xABCD" return "\uABCD" > > wouldn't make much of a difference (+ the bug would become pretty > > obvious if viewed in a Unicode aware viewer: Asian characters are > > very easy to recognize in ASCII text ;-) > > as Tim pointed out in the SRE thread, the only standard that > means something here is Python 1.5.2. And in Python 1.5.2, > \u means read as many hex digits as you can, and cast the > result to a character. > > I'd say it's more important to be compatible with Python (1.5.2 > string literals, SRE regular expression literals), than to be com- > patible with C9X... Ok, ok, go ahead :-) (please also update the docs, if there are any on this subject -- a grep didn't show anything up on \xXXX) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sun Jul 16 20:40:46 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 20:40:46 +0200 Subject: [Python-Dev] [patch #100889] a smaller unicode name database References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2DF@RED-MSG-50> Message-ID: <00b301bfef55$ba8992a0$f2a6b5d4@hagrid> bill wrote: > Smaller data sizes are definitely cool, but as MAL mentioned you didn't > include the genration code, nor an explanation about how the stuff works. brute force ;-) seriously, it's a pretty simple design. here's an overview: The unicodenames database consists of two parts: a name database which maps character codes to names, and a code database, mapping names to codes. * The Name Database (getname) First, the 10538 text strings are split into 42193 words, and combined into a 4949-word lexicon (a 29k byte array). Each word is given a unique index number (common words get lower numbers), and there's a "lexicon offset" table mapping from numbers to words (10k). To get back to the original text strings, I use a "phrase book". For each original string, the phrase book stores a a list of word numbers. Numbers 0-127 are stored in one byte, higher numbers (less common words) use two bytes. At this time, about 65% of the words can be represented by a single byte. The result is a 56k array. The final data structure is an offset table, which maps code points to phrase book offsets. Instead of using one big table, I split each code point into a "page number" and a "line number" on that page. offset = line[ (page[code>>SHIFT]< From peter at schneider-kamp.de Sun Jul 16 23:11:25 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 16 Jul 2000 21:11:25 +0000 Subject: [Python-Dev] [PEP204] Range Literals References: Message-ID: <397224FD.B30D1368@schneider-kamp.de> Moshe Zadka wrote: > > I think we decided we don't need those. The only reason people need > generators is for extra efficiency in >From following the recent discussion here (and from my Haskell brain part) I thought that generators are also useful for stuff like: even = (0:sys.maxint:2) first20even = even[:20] Having spend the weekend falling into cold mountain lakes, I may of course be mistaken about this. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From jack at oratrix.nl Sun Jul 16 22:03:44 2000 From: jack at oratrix.nl (Jack Jansen) Date: Sun, 16 Jul 2000 22:03:44 +0200 Subject: [Python-Dev] ascii default encoding Message-ID: <20000716200349.BD9A059214@oratrix.oratrix.nl> Now that the default encoding for 8-bit strings has gone back to "ascii", shouldn't the initialization of strop.whitespace and friends only range over 0..128 in stead of 0..256? On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but the \312 causes problems because it can't be converted from/to unicode as long as the default encoding is ascii... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From paul at prescod.net Sun Jul 16 22:05:53 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 15:05:53 -0500 Subject: [Python-Dev] [PEP204] Range Literals References: <397224FD.B30D1368@schneider-kamp.de> Message-ID: <397215A1.5ED50D9@prescod.net> Peter Schneider-Kamp wrote: > > ... > > I thought that generators are also useful for stuff like: > > even = (0:sys.maxint:2) > first20even = even[:20] Yes but I doubt Guido would take that usage scenariou very seriously. He's been fairly disinterested in lazy behavior for a long time. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gvwilson at nevex.com Sun Jul 16 22:08:30 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Sun, 16 Jul 2000 16:08:30 -0400 (EDT) Subject: [Python-Dev] More discussion on new infix operators In-Reply-To: <20000715235226.J7340@xs4all.nl> Message-ID: > > On Sat, Jul 15, 2000 at 01:30:31PM -0700, Huaiyu Zhu wrote: > > > 1.a) is unacceptable because infix operators improve readability > > tremendously compared with prefix operators. > On Sat, 15 Jul 2000, Thomas Wouters wrote: > > Where's the usability study to prove that ? I'm with Huaiyu on this one --- scientists and engineers have had Lisp-style prefix notation thrown at them many times, and have always resisted it (just as most computer science departments have :-). Greg From mal at lemburg.com Sun Jul 16 22:10:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 22:10:08 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib onlinehelp.py,NONE,1.1 References: <200007161953.MAA30130@slayer.i.sourceforge.net> Message-ID: <397216A0.EE5BB26E@lemburg.com> [New onlinehelp module] Great work ! Wouldn't it make sense to hook the new [whatever it is called now... browser.py] into the module as standard way of displaying the help text provided PYTHONHELPBROWSER is set to one of the supported browsers ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sun Jul 16 22:14:54 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 22:14:54 +0200 Subject: [Python-Dev] ascii default encoding References: <20000716200349.BD9A059214@oratrix.oratrix.nl> Message-ID: <397217BE.29F69C28@lemburg.com> Jack Jansen wrote: > > Now that the default encoding for 8-bit strings has gone back to > "ascii", shouldn't the initialization of strop.whitespace and friends > only range over 0..128 in stead of 0..256? > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but > the \312 causes problems because it can't be converted from/to unicode > as long as the default encoding is ascii... string.py is depreciated -- please use string methods instead. Note that the 8-bit string methods are locale aware in case the C lib APIs isspace() and isalpha() support locales. You may have to adjust the locale setting to POSIX for these APIs to return ASCII only values. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Sun Jul 16 22:18:42 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 15:18:42 -0500 Subject: [Python-Dev] Checked in... Message-ID: <397218A2.A90BCAB3@prescod.net> onlinehelp.py is checked in. Here's the docstring: This module is experimental and could be removed or radically changed at any time. It is intended specifically for the standard interpreter command line but is intended to be compatible with and useful for other (e.g. GUI, handheld) environments. Help with those other environments is appreciated. Please remember to set PYTHONDOCS to the location of your HTML files: e.g. set PYTHONDOCS=c:\python\docs PYTHONDOCS=/python/docs The docs directory should have a lib subdirectory with "index.html" in it. If it has *.tex then you have the documentation *source* distribution, not the runtime distribution. The module exposes one object: "help". "help" has a repr that does something useful if you just type: >>> from onlinehelp import help >>> help Of course one day the first line will be done automatically by site.py or something like that. help can be used as a function. The function takes the following forms of input: help( "string" ) -- built-in topic or global help( ) -- docstring from object or type help( "doc:filename" ) -- filename from Python documentation Type help to get the rest of the instructions. You can also use the module as a command line program: python onlinehelp.py "if" -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From martin at loewis.home.cs.tu-berlin.de Sun Jul 16 22:57:47 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 16 Jul 2000 22:57:47 +0200 Subject: [Python-Dev] Linker problems on Linux Message-ID: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> >> Why hasn't anyone objected to simply dropping such an important >> API without proper backwards compatibility workaround ? > If I knew it was happening, I would have whined. And I expect Guido > would have screamed. Although I ran into this as well, I don't think it is as bad as it sounds. The API has not been changed; only modules compiled for 1.5 (*) won't run in current CVS python - you have to recompile. Even if you restore the PySequence_Length as a Python entry point, you still get a warning that the ABI version mismatches. I haven't thoroughly checked, yet, but I believe that there is no way that Python 2 can guarantee binary compatibility for all 1.5.x modules. For example, if you have a 1.5.2-compiled type in an extension module, and that type happens to implement PySequenceMethods, then applying 'a in b' will likely crash: Python 2 will check for the sq_contains field, but that is past the end of the function table in the old module. So I think it is actually a good thing if an important ABI is not supported anymore. Instead of getting random crashes, you get an error on import. I wish there was a better way to gracefully fail when importing 1.5 modules on Windows. The approach of calling the entry not 'initxxx' but 'init2xxx' would work, but is quite inconvenient. Regards, Martin (*) modules compiled with last week's CVS python won't work, either, but if you have any of these, you know how to recompile things :-) From paul at prescod.net Sun Jul 16 22:58:22 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 15:58:22 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib onlinehelp.py,NONE,1.1 References: <200007161953.MAA30130@slayer.i.sourceforge.net> <397216A0.EE5BB26E@lemburg.com> Message-ID: <397221EE.D248C6D3@prescod.net> "M.-A. Lemburg" wrote: > > [New onlinehelp module] > > Great work ! > > Wouldn't it make sense to hook the new [whatever it is called > now... browser.py] into the module as standard way of displaying > the help text provided PYTHONHELPBROWSER is set to one of > the supported browsers ? Not for me. I would prefer to see the raw text rather than having a new window pop up. I would be happy to provide a mode that does this but I would rather it wasn't the default. Also, some of the text is docstrings. Presumably I wouldn't launch a browser for those, so the interface becomes somewhat inconsistent. How about this: if I taught urllib (or something) to translate doc: URLs into real URLs then you could do something like: browser.browse( "doc:lib/lambda" ) Maybe that would help...more thought needed. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From mhammond at skippinet.com.au Sun Jul 16 23:14:38 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 16 Jul 2000 17:14:38 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007141714.MAA14470@cj20424-a.reston1.va.home.com> Message-ID: > I guess the user should think about whether they want their Python COM > things to use 1.5 or 2.0. Only the one they choose should install its > DLL in the system directory; the other one should have its DLL in its > own directory. This may be a good idea - however, it is not necessary. Whatever version of Python was used to register the COM object is also used to execute it. Thus, you can have different objects on the same machine, each of which uses different Python versions. Indeed, the same process could potentially load 2 seperate versions of Python - this should work fine (although it has never been tested by me!) Mark. From mhammond at skippinet.com.au Sun Jul 16 23:14:40 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 16 Jul 2000 17:14:40 -0400 Subject: [Python-Dev] Help command In-Reply-To: <39710C75.A7DB127F@prescod.net> Message-ID: > Okay, I wrote the help command today. The transcript before was just a > Microsoft-style "Technology Preview." I'm pretty happy with the extent > to which I can pull in HTML and get lots of content from Fred's HTML ... > Here's my current scheme: Note that on Windows, there is a help key in the registry that points to the various help files. The core installer uses this, as does the win32all installer. Pythonwin reads this key to populate the "Help" menu. Mark. From gstein at lyra.org Sun Jul 16 23:19:22 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 14:19:22 -0700 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 16, 2000 at 02:14:02PM -0400 References: <3971A705.B23AD7D3@lemburg.com> Message-ID: <20000716141921.K29590@lyra.org> To me, this says punt the \x construct from Unicode objects altogether. If it is broken, then why try to retain it? I *do* find it useful in the regular string objects. For Unicode, I would totally understand needing to use \u instead. Cheers, -g On Sun, Jul 16, 2000 at 02:14:02PM -0400, Tim Peters wrote: > [/F] > > for maximum compatibility with 8-bit strings and SRE, > > let's change "\x" to mean "binary byte" in unicode string > > literals too. > > [MAL] > > Hmm, this is probably not in sync with C9X (see section 6.4.4.4), > > The behavior of \x in C9X is nearly incomprehensible -- screw it. > > > but then perhaps we should depreciate usage of \xXX in the context > > of Unicode objects altogether. Our \uXXXX notation is far > > superior to what C9X tries to squeeze into \x (IMHO at least). > > \x is a hack inherited from the last version of C, put in back when they > knew they had to do *something* to support "big characters" but had no real > idea what. C9X was not allowed to break anything in the std it built on, so > they kept all the old implementation-defined \x behavior, and made it even > more complicated so it would make some kind sense with the new C9X character > gimmicks. > > Python is stuck trying to make sense out of its ill-considered adoption of > old-C's \x notation too. Letting it mean "a byte" regardless of context > should make it useless enough that people will eventually learn to avoid it > . > > Note that C9X also has \u and \U notations, and \u in C9X means what it does > in Python, except that C9X explicitly punts on what happens for \u values in > these (inclusive) ranges: > > \u0000 - \u0020 > \u007f - \u009f > \ud800 - \udfff > > \U is used in C9X for 8-digit (hex) characters, deferring to ISO 10646. > > If C9X didn't *have* to keep \x around, I'm sure they would have tossed it. > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From thomas at xs4all.net Sun Jul 16 23:19:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 23:19:08 +0200 Subject: [Python-Dev] ascii default encoding In-Reply-To: <397217BE.29F69C28@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 10:14:54PM +0200 References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> Message-ID: <20000716231908.A7340@xs4all.nl> On Sun, Jul 16, 2000 at 10:14:54PM +0200, M.-A. Lemburg wrote: > Jack Jansen wrote: > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but > > the \312 causes problems because it can't be converted from/to unicode > > as long as the default encoding is ascii... > string.py is depreciated -- please use string methods instead. You mean 'deprecated'. And please wait with deprecating string.py until all functionality is indeed available through string methods. And please don't do that :) I don't think " ".letters really makes sense... Besides, 'string.join' is a good compromise for the people who don't like " ".join() :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sun Jul 16 23:25:53 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 23:25:53 +0200 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Sun, Jul 16, 2000 at 10:57:47PM +0200 References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> Message-ID: <20000716232553.B7340@xs4all.nl> On Sun, Jul 16, 2000 at 10:57:47PM +0200, Martin v. Loewis wrote: > For example, if you have a 1.5.2-compiled type in an extension module, > and that type happens to implement PySequenceMethods, then applying 'a > in b' will likely crash: Python 2 will check for the sq_contains > field, but that is past the end of the function table in the old > module. Nope. This is specifically fixed by the new tp_flags structmember (which was 'unused' before, so reading *that* will work ok) and the PyType_HasFeature macro. All code that wants to access one of the really new struct members (currently, bf_getcharbuffer, sq_contains and the cycle-gc stuff. And my augmented assignment patch adds another 13 ;) should check tp_flags first. See the comment in Include/object.h regarding this. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From martin at loewis.home.cs.tu-berlin.de Sun Jul 16 23:26:45 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 16 Jul 2000 23:26:45 +0200 Subject: [Python-Dev] onlinehelp unforgiving Message-ID: <200007162126.XAA25108@loewis.home.cs.tu-berlin.de> After installing the current Python CVS, I tried to do >>> from onlinehelp import help Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.0/onlinehelp.py", line 323, in ? help=Help(sys.stdout,24) File "/usr/local/lib/python2.0/onlinehelp.py", line 216, in __init__ raise EnvironmentError, error EnvironmentError: Cannot find documentation directory /usr/local/bin/doc. Set the PYTHONDOCS environment variable to point to a "doc" directory. It should have a subdirectory "Lib" with a file named "index.html". I was mainly interested in seeing the doc string retriever in real life. To do so, I'm in the process of obtaining a set of html files (hopefully typing make in the Doc directory will give me those). Still, I think that module should work without HTML help installed, and only fail if somebody tries to access the documentation. Or, there should be a function doc() in addition to help() for retrieving and printing doc strings. I'd actually prefer the second option: >>> doc(xml) Core XML support for Python. This package contains three sub-packages: dom -- The W3C Document Object Model. This supports DOM Level 1 + Namespaces. parser -- Python wrappers for XML parsers (currently only supports Expat). sax -- The Simple API for XML, developed by XML-Dev, led by David Megginson and ported to Python by Lars Marius Garshol. This supports the SAX 2 API. should work even without any documentation installed. In any case, I think this (or the help function) should be builtin. Regards, Martin From thomas at xs4all.net Sun Jul 16 23:33:17 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 23:33:17 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: <20000716141921.K29590@lyra.org>; from gstein@lyra.org on Sun, Jul 16, 2000 at 02:19:22PM -0700 References: <3971A705.B23AD7D3@lemburg.com> <20000716141921.K29590@lyra.org> Message-ID: <20000716233317.C7340@xs4all.nl> On Sun, Jul 16, 2000 at 02:19:22PM -0700, Greg Stein wrote: > To me, this says punt the \x construct from Unicode objects altogether. If > it is broken, then why try to retain it? > I *do* find it useful in the regular string objects. For Unicode, I would > totally understand needing to use \u instead. Don't forget the -U option to python, which turns all strings into Unicode strings. So it's broken now, that's no reason to break it some more ;) I also thought the long-term idea was to make all strings unicode strings. Making the two strings different in more than implementation is probably a bad idea. I'm with Tim here: screw the retarded compatibility. Make \x make sense in normal strings and unicode strings both, but in a way that breaks as little as possible: if it always results in one byte in 8bit strings, it should do the same, IMHO, in unicode strings. I'm also for making \x take at most four bytes, like the documentation states, instead of hassling with a perl-like construct such as C has. I would be very, very suprised if anyone was using \x29E8F28DA727 and expects it to work like \x27. We can use the beta cycle to see if it breaks anything. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Sun Jul 16 23:34:00 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 23:34:00 +0200 Subject: [Python-Dev] ascii default encoding References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> Message-ID: <39722A48.B8DADEB5@lemburg.com> Thomas Wouters wrote: > > On Sun, Jul 16, 2000 at 10:14:54PM +0200, M.-A. Lemburg wrote: > > Jack Jansen wrote: > > > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but > > > the \312 causes problems because it can't be converted from/to unicode > > > as long as the default encoding is ascii... > > > string.py is depreciated -- please use string methods instead. > > You mean 'deprecated'. Hmm, my Webster says "to lessen in value" -- that's what I had in mind... > And please wait with deprecating string.py until all > functionality is indeed available through string methods. And please don't > do that :) I don't think " ".letters really makes sense... "Depreciated" means that you should not use it in new code -- perhaps someday string.py will disappear, even though I doubt that. > Besides, 'string.join' is a good compromise for the people who > don't like " ".join() Tim Peters will have to take the blame for this one ;-) I don't find delimiter.join(sequence) awkward or funny -- using methods for this has added value: it defines an interface which other objects could support as well and thus makes your code polymorph. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Sun Jul 16 23:42:29 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 23:42:29 +0200 Subject: [Python-Dev] ascii default encoding In-Reply-To: <39722A48.B8DADEB5@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 11:34:00PM +0200 References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> <39722A48.B8DADEB5@lemburg.com> Message-ID: <20000716234228.E7340@xs4all.nl> On Sun, Jul 16, 2000 at 11:34:00PM +0200, M.-A. Lemburg wrote: > "Depreciated" means that you should not use it in new code -- > perhaps someday string.py will disappear, even though I doubt > that. The common term for that is 'deprecated', not 'depreciated'. Really :) There once was someone who posted a patch to linux-kernel to fix all those bloody typos everyone made. Almost all instances of 'depreciated' where spelled 'deprecated' ! Deprecate: 1.To express disapproval of; deplore. 2.To belittle; depreciate. Deprecate \Dep"re*cate\: To pray against, as an evil; to seek to avert by prayer; to desire the removal of; to seek deliverance from; to express deep regret for; to disapprove of strongly. The difference is minor, but there really is one. Come on Eric, show us the hackers dictionary on this ;) > > Besides, 'string.join' is a good compromise for the people who > > don't like " ".join() > Tim Peters will have to take the blame for this one ;-) I don't > find delimiter.join(sequence) awkward or funny -- using methods > for this has added value: it defines an interface which other > objects could support as well and thus makes your code polymorph. Indeed. And is there any harm in providing conveniency functions for those that prefer more obvious code ? There is hardly any doubt what string.join(s, sep) does. And some people prefer it that way. They don't care that it's really 'return sep.join(s)' behind their backs. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein at lyra.org Mon Jul 17 00:00:48 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:00:48 -0700 Subject: [Python-Dev] onlinehelp unforgiving In-Reply-To: <200007162126.XAA25108@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Sun, Jul 16, 2000 at 11:26:45PM +0200 References: <200007162126.XAA25108@loewis.home.cs.tu-berlin.de> Message-ID: <20000716150048.N29590@lyra.org> +1 with Martin. There is more to online help than the HTML stuff. Cheers, -g On Sun, Jul 16, 2000 at 11:26:45PM +0200, Martin v. Loewis wrote: > After installing the current Python CVS, I tried to do > > >>> from onlinehelp import help > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/local/lib/python2.0/onlinehelp.py", line 323, in ? > help=Help(sys.stdout,24) > File "/usr/local/lib/python2.0/onlinehelp.py", line 216, in __init__ > raise EnvironmentError, error > EnvironmentError: Cannot find documentation directory /usr/local/bin/doc. > Set the PYTHONDOCS environment variable to point to a "doc" directory. > It should have a subdirectory "Lib" with a file named "index.html". > > I was mainly interested in seeing the doc string retriever in real > life. To do so, I'm in the process of obtaining a set of html files > (hopefully typing make in the Doc directory will give me those). > > Still, I think that module should work without HTML help installed, > and only fail if somebody tries to access the documentation. Or, there > should be a function doc() in addition to help() for retrieving and > printing doc strings. > > I'd actually prefer the second option: > > >>> doc(xml) > Core XML support for Python. > > This package contains three sub-packages: > > dom -- The W3C Document Object Model. This supports DOM Level 1 + > Namespaces. > > parser -- Python wrappers for XML parsers (currently only supports Expat). > > sax -- The Simple API for XML, developed by XML-Dev, led by David > Megginson and ported to Python by Lars Marius Garshol. This > supports the SAX 2 API. > > should work even without any documentation installed. In any case, I > think this (or the help function) should be builtin. > > Regards, > Martin > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 17 00:04:10 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:04:10 -0700 Subject: [Python-Dev] urllib and doc: (was: CVS: python/dist/src/Lib onlinehelp.py,NONE,1.1) In-Reply-To: <397221EE.D248C6D3@prescod.net>; from paul@prescod.net on Sun, Jul 16, 2000 at 03:58:22PM -0500 References: <200007161953.MAA30130@slayer.i.sourceforge.net> <397216A0.EE5BB26E@lemburg.com> <397221EE.D248C6D3@prescod.net> Message-ID: <20000716150410.O29590@lyra.org> On Sun, Jul 16, 2000 at 03:58:22PM -0500, Paul Prescod wrote: >... > How about this: if I taught urllib (or something) to translate doc: URLs > into real URLs then you could do something like: > > browser.browse( "doc:lib/lambda" ) > > Maybe that would help...more thought needed. urllib should NOT try to parse a "doc:" scheme. Any scheme in urllib should ONLY be IANA-registered schemes, and the resulting URL should follow the appropriate RFCs. If doc: is ever registered, then go ahead and teach it to urllib. Until then, I'll scream and shout and be very annoying :-) Big -1 on this from me. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Mon Jul 17 00:01:48 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 00:01:48 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49 References: <200007162139.OAA18443@slayer.i.sourceforge.net> Message-ID: <397230CC.D8380547@lemburg.com> Greg Stein wrote: > > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv18430 > > Modified Files: > unicodeobject.c > Log Message: > stop messing around with goto and just write the macro correctly. > > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.48 > retrieving revision 2.49 > diff -C2 -r2.48 -r2.49 > *** unicodeobject.c 2000/07/16 18:47:43 2.48 > --- unicodeobject.c 2000/07/16 21:39:49 2.49 > *************** > *** 632,640 **** > } > > ! #define UTF8_ERROR(details) do { \ > ! if (utf8_decoding_error(&s, &p, errors, details)) \ > ! goto onError; \ > ! goto nextChar; \ > ! } while (0) > > PyObject *PyUnicode_DecodeUTF8(const char *s, > --- 632,641 ---- > } > > ! #define UTF8_ERROR(details) \ > ! if (1) { \ > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > ! goto onError; \ > ! continue; \ > ! } else Greg, this doesn't work... UTF8_ERROR is used in if-clauses and the above may alter the else-branches in subtle ways which are just as hard to detect as the original bug. The goto may not be the greatest in style, but it doesn't have the above caveats. Please revert the checkin. > > PyObject *PyUnicode_DecodeUTF8(const char *s, > *************** > *** 732,737 **** > } > s += n; > - nextChar: > - /* empty */; > } > > --- 733,736 ---- > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Mon Jul 17 00:09:25 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:09:25 -0700 Subject: [Python-Dev] ascii default encoding In-Reply-To: <20000716234228.E7340@xs4all.nl>; from thomas@xs4all.net on Sun, Jul 16, 2000 at 11:42:29PM +0200 References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> <39722A48.B8DADEB5@lemburg.com> <20000716234228.E7340@xs4all.nl> Message-ID: <20000716150925.Q29590@lyra.org> Thomas is quite correct. "Deprecated" is the proper term. -g On Sun, Jul 16, 2000 at 11:42:29PM +0200, Thomas Wouters wrote: > On Sun, Jul 16, 2000 at 11:34:00PM +0200, M.-A. Lemburg wrote: > > > "Depreciated" means that you should not use it in new code -- > > perhaps someday string.py will disappear, even though I doubt > > that. > > The common term for that is 'deprecated', not 'depreciated'. Really :) There > once was someone who posted a patch to linux-kernel to fix all those bloody > typos everyone made. Almost all instances of 'depreciated' where spelled > 'deprecated' ! > > Deprecate: > > 1.To express disapproval of; deplore. > 2.To belittle; depreciate. > > Deprecate \Dep"re*cate\: > To pray against, as an evil; to seek to avert by prayer; to desire the > removal of; to seek deliverance from; to express deep regret for; to > disapprove of strongly. > > The difference is minor, but there really is one. Come on Eric, show us the > hackers dictionary on this ;) > > > > Besides, 'string.join' is a good compromise for the people who > > > don't like " ".join() > > > Tim Peters will have to take the blame for this one ;-) I don't > > find delimiter.join(sequence) awkward or funny -- using methods > > for this has added value: it defines an interface which other > > objects could support as well and thus makes your code polymorph. > > Indeed. And is there any harm in providing conveniency functions for those > that prefer more obvious code ? There is hardly any doubt what > > string.join(s, sep) > > does. And some people prefer it that way. They don't care that it's really > 'return sep.join(s)' behind their backs. > > -- > Thomas Wouters > > Hi! I'm a .signature virus! copy me into your .signature file to help me spread! > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Mon Jul 17 01:10:20 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:10:20 -0500 Subject: [Python-Dev] Checked in... In-Reply-To: Your message of "Sun, 16 Jul 2000 15:18:42 EST." <397218A2.A90BCAB3@prescod.net> References: <397218A2.A90BCAB3@prescod.net> Message-ID: <200007162310.SAA05749@cj20424-a.reston1.va.home.com> > onlinehelp.py is checked in. Here's the docstring: Sorry Paul, but checking things in is not the appropriate way to start a discussion. Without a prior discussion of requirements and design alternatives I don't think that it should be checked in, even labeled experimental. The proper thing to do if you want feedback on the source code is to post the source code somewhere (here). There are simply too many people with too many ideas for this to work -- Python would become a work designed by committee. I'm on my way to Monterey and don't have time to comment on the contents right now, but please follow the procedure! (And I *know* that the procedure isn't carefully documented -- that's one more reason to be conservative in your checkins.) Annoyed, --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Mon Jul 17 00:13:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 00:13:39 +0200 Subject: [Python-Dev] ascii default encoding References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> <39722A48.B8DADEB5@lemburg.com> <20000716234228.E7340@xs4all.nl> Message-ID: <39723393.BD32D592@lemburg.com> Thomas Wouters wrote: > > On Sun, Jul 16, 2000 at 11:34:00PM +0200, M.-A. Lemburg wrote: > > > "Depreciated" means that you should not use it in new code -- > > perhaps someday string.py will disappear, even though I doubt > > that. > > The common term for that is 'deprecated', not 'depreciated'. Really :) There > once was someone who posted a patch to linux-kernel to fix all those bloody > typos everyone made. Almost all instances of 'depreciated' where spelled > 'deprecated' ! > > Deprecate: > > 1.To express disapproval of; deplore. > 2.To belittle; depreciate. ^^^^^^^^^^ This is what I was referring to :-) > Deprecate \Dep"re*cate\: > To pray against, as an evil; to seek to avert by prayer; to desire the > removal of; to seek deliverance from; to express deep regret for; to > disapprove of strongly. I wouldn't want to pray against string.py ;-) Here's what my Merriam-Webster has to say: Depreciate: 1. to lessen in price or value 2. undervalue, belittle, disparage > The difference is minor, but there really is one. Come on Eric, show us the > hackers dictionary on this ;) It seems that one is stronger than the other. I'll stick with the weaker one ;-) > > > Besides, 'string.join' is a good compromise for the people who > > > don't like " ".join() > > > Tim Peters will have to take the blame for this one ;-) I don't > > find delimiter.join(sequence) awkward or funny -- using methods > > for this has added value: it defines an interface which other > > objects could support as well and thus makes your code polymorph. > > Indeed. And is there any harm in providing conveniency functions for those > that prefer more obvious code ? There is hardly any doubt what > > string.join(s, sep) > > does. And some people prefer it that way. They don't care that it's really > 'return sep.join(s)' behind their backs. Fine... but it'll cause a performance hit when used in tight loops (function call + method lookup). They should use somehting like: spacejoin = ' '.join spacejoin(sequence) instead. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Mon Jul 17 00:17:50 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:17:50 -0700 Subject: [Python-Dev] binary incompatibility and tp_flags (was: Linker problems on Linux) In-Reply-To: <20000716232553.B7340@xs4all.nl>; from thomas@xs4all.net on Sun, Jul 16, 2000 at 11:25:53PM +0200 References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> Message-ID: <20000716151750.R29590@lyra.org> On Sun, Jul 16, 2000 at 11:25:53PM +0200, Thomas Wouters wrote: > On Sun, Jul 16, 2000 at 10:57:47PM +0200, Martin v. Loewis wrote: > > > For example, if you have a 1.5.2-compiled type in an extension module, > > and that type happens to implement PySequenceMethods, then applying 'a > > in b' will likely crash: Python 2 will check for the sq_contains > > field, but that is past the end of the function table in the old > > module. > > Nope. This is specifically fixed by the new tp_flags structmember (which was > 'unused' before, so reading *that* will work ok) and the PyType_HasFeature > macro. All code that wants to access one of the really new struct members > (currently, bf_getcharbuffer, sq_contains and the cycle-gc stuff. And my > augmented assignment patch adds another 13 ;) should check tp_flags first. > > See the comment in Include/object.h regarding this. Actually, those flags should only be used if you are attempting to maintain binary compatibility. At the point where you say "okay. binary compatibility is hereby broken.", then we go and remove the flags for the new structure members. The concept is pretty simple: *) if an extension was compiled before the addition of the new member, then the core should not attempt to access it. to detect this case, the core looks at the flag bit, which will be zero. *) when the extension is recompiled, the struct grows according to the new definition. -) The extension may still have zero in there, so Python still won't look, even though it could -) The extension added Py_TPFLAGS_DEFAULT and picks up the bit that says the new struct member is there. It is probably NULL, unless the author has filled in a value. The last API bump was to 1009 for "Unicode API added". I'm not sure why Guido bumped it since the *addition* of an API shouldn't create binary incompatibility. Regardless, I think we have introduced several semantic incompatibilities or even signature changes in the APIs. We should do a bump for safety's sake and we should toss the two Py_TPFLAGS_HAVE_* macros (and the corresponding tests within the core interpreter). Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Mon Jul 17 01:14:57 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:14:57 -0500 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: Your message of "Sun, 16 Jul 2000 23:33:17 +0200." <20000716233317.C7340@xs4all.nl> References: <3971A705.B23AD7D3@lemburg.com> <20000716141921.K29590@lyra.org> <20000716233317.C7340@xs4all.nl> Message-ID: <200007162314.SAA05833@cj20424-a.reston1.va.home.com> > I'm with Tim here: screw the retarded compatibility. Make \x make sense in > normal strings and unicode strings both, but in a way that breaks as little > as possible: if it always results in one byte in 8bit strings, it should do > the same, IMHO, in unicode strings. I'm also for making \x take at most four > bytes, like the documentation states, instead of hassling with a perl-like > construct such as C has. I would be very, very suprised if anyone was using > \x29E8F28DA727 and expects it to work like \x27. Haven't read Tim's post, but I agree to screw compatibility here, and I see two reasonable ways out: (1) \x takes up to 2 hex chars in 8-bit strings and up to 4 hex chars in Unicode. (2) \x takes up to 4 hex chars in all strings. The presence of -U and ease of JPython compatibility both suggest that (2) is best. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From effbot at telia.com Mon Jul 17 00:25:39 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 00:25:39 +0200 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> Message-ID: <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> guido wrote: > > > onlinehelp.py is checked in. Here's the docstring: > > Sorry Paul, but checking things in is not the appropriate way to start > a discussion. Without a prior discussion of requirements and design > alternatives I don't think that it should be checked in, even labeled > experimental. in paul's defence, note that tim, greg stein, and moshe all told paul to go ahead and check it in... (you'll find their posts in the "help command" thread) cheers /F From effbot at telia.com Mon Jul 17 00:28:43 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 00:28:43 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? References: <3971A705.B23AD7D3@lemburg.com> <20000716141921.K29590@lyra.org> <20000716233317.C7340@xs4all.nl> <200007162314.SAA05833@cj20424-a.reston1.va.home.com> Message-ID: <004d01bfef75$34bd5a60$f2a6b5d4@hagrid> guido wrote: > Haven't read Tim's post, but I agree to screw compatibility here, and > I see two reasonable ways out: I think tim and thomas both meant "screw C9X compatibility", not "screw 1.5.2 compatibility". (maybe we should continue this discussion when you're back from OSCON? it's not that critical...) From effbot at telia.com Mon Jul 17 00:35:56 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 00:35:56 +0200 Subject: [Python-Dev] ascii default encoding References: <20000716200349.BD9A059214@oratrix.oratrix.nl> Message-ID: <008501bfef76$362902e0$f2a6b5d4@hagrid> jack wrote: > Now that the default encoding for 8-bit strings has gone back to > "ascii", shouldn't the initialization of strop.whitespace and friends > only range over 0..128 in stead of 0..256? > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but > the \312 causes problems because it can't be converted from/to unicode > as long as the default encoding is ascii... on windows and unix boxes, the default locale is "posix" (aka "C"), which in practice means "plain ascii". the only way to end up with non-ascii characters in whitespace/uppercase/lowercase/etc is to explicitly change the locale (by calling locale.setlocale). how does this work on the mac? do the mac libraries use another default locale? one slightly radical way to solve this would be to modify the loops in stropmodule.c/initstrop (changing 256 to 128). From guido at beopen.com Mon Jul 17 01:32:27 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:32:27 -0500 Subject: [Python-Dev] Checked in... In-Reply-To: Your message of "Mon, 17 Jul 2000 00:25:39 +0200." <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> Message-ID: <200007162332.SAA06030@cj20424-a.reston1.va.home.com> > in paul's defence, note that tim, greg stein, and moshe > all told paul to go ahead and check it in... > > (you'll find their posts in the "help command" thread) Sigh. Sorry Paul. Now I'm annoyed at Tim, Greg & Moshe. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein at lyra.org Mon Jul 17 00:37:36 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:37:36 -0700 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) In-Reply-To: <397230CC.D8380547@lemburg.com>; from mal@lemburg.com on Mon, Jul 17, 2000 at 12:01:48AM +0200 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> Message-ID: <20000716153736.T29590@lyra.org> On Mon, Jul 17, 2000 at 12:01:48AM +0200, M.-A. Lemburg wrote: > Greg Stein wrote: >... > > ! #define UTF8_ERROR(details) \ > > ! if (1) { \ > > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > > ! goto onError; \ > > ! continue; \ > > ! } else > > Greg, this doesn't work... UTF8_ERROR is used in if-clauses > and the above may alter the else-branches in subtle ways which > are just as hard to detect as the original bug. The goto may > not be the greatest in style, but it doesn't have the above > caveats. Nope. It *does* work. Note the "else" on the end there. That creates the proper binding. All uses of the UTF8_ERROR() macro have a semicolon after them (like any normal statement does(!)). This expands the macro to: if (1) { ... } else ; /* this is the semicolon I referred to */ Therefore, it creates a complete if/else statement, and any surrounding if/else statements will bind as expected. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 17 00:41:38 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:41:38 -0700 Subject: [Python-Dev] Checked in... In-Reply-To: <200007162310.SAA05749@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Sun, Jul 16, 2000 at 06:10:20PM -0500 References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> Message-ID: <20000716154138.U29590@lyra.org> To defend Paul here a bit, we did start some discussion here, and at least some of us said "the concept is fine, so check it in. we can totally revamp as necessary." CVS is a much better communication/testing vehicle than the damn Patch Manager or posting modules at some private web site. And we can always "cvs rm" a module. Another alternative would be to create /nondist/sandbox/ and have people toss modules-for-discussion or modules-in-progress into that area. We can dork around as much as needed. When the module is "ready", then we add it into the /dist/ branch. CVS is a great tool for this. Let's not try to create roadblocks that prevent effective work. Cheers, -g On Sun, Jul 16, 2000 at 06:10:20PM -0500, Guido van Rossum wrote: > > onlinehelp.py is checked in. Here's the docstring: > > Sorry Paul, but checking things in is not the appropriate way to start > a discussion. Without a prior discussion of requirements and design > alternatives I don't think that it should be checked in, even labeled > experimental. > > The proper thing to do if you want feedback on the source code is to > post the source code somewhere (here). There are simply too many > people with too many ideas for this to work -- Python would become a > work designed by committee. > > I'm on my way to Monterey and don't have time to comment on the > contents right now, but please follow the procedure! (And I *know* > that the procedure isn't carefully documented -- that's one more > reason to be conservative in your checkins.) > > Annoyed, > > --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Mon Jul 17 01:39:03 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:39:03 -0500 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: Your message of "Mon, 17 Jul 2000 00:28:43 +0200." <004d01bfef75$34bd5a60$f2a6b5d4@hagrid> References: <3971A705.B23AD7D3@lemburg.com> <20000716141921.K29590@lyra.org> <20000716233317.C7340@xs4all.nl> <200007162314.SAA05833@cj20424-a.reston1.va.home.com> <004d01bfef75$34bd5a60$f2a6b5d4@hagrid> Message-ID: <200007162339.SAA06110@cj20424-a.reston1.va.home.com> > guido wrote: > > Haven't read Tim's post, but I agree to screw compatibility here, and > > I see two reasonable ways out: > > I think tim and thomas both meant "screw C9X compatibility", > not "screw 1.5.2 compatibility". Oops again. > (maybe we should continue this discussion when you're back > from OSCON? it's not that critical...) Yes please! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Mon Jul 17 01:00:46 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Sun, 16 Jul 2000 19:00:46 -0400 Subject: [Python-Dev] ascii default encoding In-Reply-To: <20000716234228.E7340@xs4all.nl> References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> <39722A48.B8DADEB5@lemburg.com> <20000716234228.E7340@xs4all.nl> Message-ID: <20000716190046.A3833@thyrsus.com> Thomas Wouters : > Deprecate: > > 1.To express disapproval of; deplore. > 2.To belittle; depreciate. > > Deprecate \Dep"re*cate\: > To pray against, as an evil; to seek to avert by prayer; to desire the > removal of; to seek deliverance from; to express deep regret for; to > disapprove of strongly. > > The difference is minor, but there really is one. Come on Eric, show us the > hackers dictionary on this ;) Your wish is my command... @hd{deprecated} @g{adj.} @p{} Said of a program or feature that is considered obsolescent and in the process of being phased out, usually in favor of a specified replacement. Deprecated features can, unfortunately, linger on for many years. This term appears with distressing frequency in standards documents when the committees writing the documents realize that large amounts of extant (and presumably happily working) code depend on the feature(s) that have passed out of favor. See also @es{dusty deck}. @comment ESR 1983 -- Eric S. Raymond This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. From tim_one at email.msn.com Mon Jul 17 00:46:35 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 18:46:35 -0400 Subject: [Python-Dev] Checked in... In-Reply-To: <200007162310.SAA05749@cj20424-a.reston1.va.home.com> Message-ID: [Paul Prescod] >> onlinehelp.py is checked in. Here's the docstring: [Guido] > Sorry Paul, but checking things in is not the appropriate way to start > a discussion. There was a discussion, overwhelmingly positive, and then to make further progress Paul asked here whether it wouldn't be easier to just check something in so we could all kick the tires. At least three of us (four if you count me twice, as I tend to do ) said "sure!". > ... > Annoyed, I can understand that too . But as Paul said, it's a self-contained module that "can't" break anything else, and he did ask first, so maybe you could look on it a bit more kindly this once. From guido at beopen.com Mon Jul 17 01:53:41 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:53:41 -0500 Subject: [Python-Dev] Checked in... In-Reply-To: Your message of "Sun, 16 Jul 2000 15:41:38 MST." <20000716154138.U29590@lyra.org> References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <20000716154138.U29590@lyra.org> Message-ID: <200007162353.SAA06185@cj20424-a.reston1.va.home.com> [Greg] > To defend Paul here a bit, we did start some discussion here, and at least > some of us said "the concept is fine, so check it in. we can totally revamp > as necessary." I can't even go away for a weekend and they start checking stuff in behind my back. ;-) > CVS is a much better communication/testing vehicle than the damn Patch > Manager or posting modules at some private web site. > > And we can always "cvs rm" a module. Actually, this leaves a turd in the Attic directory. Adding something to the CVS repository gives it a false legitimacy -- not everybody reads the "experimental feature" comment. > Another alternative would be to create /nondist/sandbox/ and have people > toss modules-for-discussion or modules-in-progress into that area. We can > dork around as much as needed. When the module is "ready", then we add it > into the /dist/ branch. I like this much better! > CVS is a great tool for this. Let's not try to create roadblocks that > prevent effective work. Sure. But let's be careful with what we check in, especially into the "dist" source tree. This is not a place for random experiments. I've seen a few examples recently where it seemed some kind of discussion was being carried out by checkins. Regardless of who's right or wrong, that's the wrong medium for such a process. [Tim] > There was a discussion, overwhelmingly positive, and then to make further > progress Paul asked here whether it wouldn't be easier to just check > something in so we could all kick the tires. At least three of us (four if > you count me twice, as I tend to do ) said "sure!". > > > ... > > Annoyed, > > I can understand that too . But as Paul said, it's a self-contained > module that "can't" break anything else, and he did ask first, so maybe you > could look on it a bit more kindly this once. Sure. I recommend the use of the nondist CVS tree for experiments. But to me the dist subtree is sacred and should only contain code we believe we agree on. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul at prescod.net Mon Jul 17 01:06:24 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:06:24 -0500 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> Message-ID: <39723FF0.D6BFD9F1@prescod.net> Okay, I've removed it and attached it to this email but I still think that's a pretty cumbersome way to proceed. I've already made one modification. Future ones will need to be distributed as email patches. As a new module that won't be the basis of anything, and with significant interest, I don't see the danger in a checkin. Anyhow, this version should not require the PYTHONDOCS environment variable unless you try to refer to a help topic that requires the online help. Still, in the future, I don't see the benefit in duplicating the documentation for all of the statements and operators. If you want that documentation, you'll probably need the HTML installed. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html -------------- next part -------------- """ Online help module. This module is experimental and could be removed or radically changed at any time. It is intended specifically for the standard interpreter command line but is intended to be compatible with and useful for other (e.g. GUI, handheld) environments. Help with those other environments is appreciated. Please remember to set PYTHONDOCS to the location of your HTML files: e.g. set PYTHONDOCS=c:\python\docs PYTHONDOCS=/python/docs The docs directory should have a lib subdirectory with "index.html" in it. If it has *.tex then you have the documentation *source* distribution, not the runtime distribution. The module exposes one object: "help". "help" has a repr that does something useful if you just type: >>> from onlinehelp import help >>> help Of course one day the first line will be done automatically by site.py or something like that. help can be used as a function. The function takes the following forms of input: help( "string" ) -- built-in topic or global help( ) -- docstring from object or type help( "doc:filename" ) -- filename from Python documentation Type help to get the rest of the instructions. You can also use the module as a command line program: python onlinehelp.py if """ # todo: consider following links: # help( 3 ) -> follows link 3 in the last-displayed doc # help( 4 ) -> follows link 4 in the last-displayed doc # ... import htmllib # todo: add really basic tr/td support import formatter import os, sys import re prompt="--more-- (enter for more, q to quit) " topics={} # all built-in (non-HTML, non-docstring) topics go in here commands="" # only used at the top level def topLevelCommand( name, description, text ): """ this function is just for use at the top-level to make sure that every advertised top-level topic has a description and every description has text. Maybe we can generalize it later.""" global commands topics[name]=text if description[0]=="[": placeholder="(dummy)" elif description[0]=="<": placeholder="link" else: placeholder="" commands=commands+'help( "%s" ) %s - %s\n' % \ (name, placeholder, description ) topLevelCommand( "intro", "What is Python? Read this first!", """Welcome to Python, the easy to learn, portable, object oriented programming language. [info on how to use help] [info on intepreter]""" ) topLevelCommand( "keywords", "What are the keywords?", "") topLevelCommand( "syntax", "What is the overall syntax?", "[placeholder]") topLevelCommand( "operators", "What operators are available?", "" ) topLevelCommand( "builtins", "What functions, types, etc. are built-in?", "") topLevelCommand( "modules", "What modules are in the standard library?", "") topLevelCommand( "copyright", "Who owns Python?", "[who knows]") topLevelCommand( "moreinfo", "Where is there more information?", "[placeholder]") topLevelCommand( "changes", "What changed in Python 2.0?", "[placeholder]" ) topLevelCommand( "extensions", "What extensions are installed?", "[placeholder]") topLevelCommand( "faq", "What questions are frequently asked?", "[placeholder]") topLevelCommand( "ack", "Who has done work on Python lately?", "[placeholder for list of people who contributed patches]") topics[ "prompt" ]="""""" topics[ "types" ]="""""" topics["everything"]= \ """
The help function allows you to read help on Python's various 
functions, objects, instructions and modules. You have two options:

1. Use help( obj ) to browse the help attached to some function, module
class or other object. e.g. help( dir )

2. Use help( "somestring" ) to browse help on one of the predefined 
help topics, unassociated with any particular object:

%s
""" % commands topics[ "keywords" ]=\ """
"if"       - Conditional execution
"while"    - Loop while a condition is true
"for"      - Loop over a sequence of values (often numbers)
"try"      - Set up an exception handler
"def"      - Define a named function
"class"    - Define a class
"assert"   - Check that some code is working as you expect it to.
"pass"     - Do nothing
"del"      - Delete a data value
"print"    - Print a value
"return"   - Return information from a function
"raise"    - Raise an exception
"break"    - Terminate a loop
"continue" - Skip to the next loop statement
"import"   - Import a module
"global"   - Declare a variable global
"exec"     - Execute some dynamically generated code
"lambda"   - Define an unnamed function

For more information, type e.g. help("assert")
""" topics[ "if" ]="""""" topics[ "while" ]="""""" topics[ "for" ]="""""" topics[ "try" ]="""""" topics[ "def" ]="""""" topics[ "class" ]="""""" topics[ "assert" ]="""""" topics[ "pass" ]="""""" topics[ "del" ]="""""" topics[ "print" ]="""""" topics[ "return" ]="""""" topics[ "raise" ]="""""" topics[ "break" ]="""""" topics[ "continue" ]="""""" topics[ "import" ]="""""" topics[ "global" ]="""""" topics[ "exec" ]="""""" topics[ "lambda" ]="""""" envir_var="PYTHONDOCS" class Help: def __init__( self, out, line_length, docdir=None ): self.out=out self.line_length=line_length self.Parser=htmllib.HTMLParser self.Formatter=formatter.AbstractFormatter self.Pager=Pager self.Writer=formatter.DumbWriter self.docdir=docdir def initDocDir( self ): if os.environ.has_key(envir_var): self.docdir=os.environ[envir_var] else: if os.environ.has_key("PYTHONHOME"): pyhome=os.environ["PYTHONHOME"] else: pyhome=os.path.split( sys.executable )[0] self.docdir=os.path.join( pyhome, "doc" ) testfile=os.path.join( os.path.join( self.docdir, "lib" ), "index.html") if not os.path.exists( testfile ): error = \ """Cannot find documentation directory %s. Set the %s environment variable to point to a "doc" directory. It should have a subdirectory "Lib" with a file named "index.html". """ % (self.docdir, envir_var ) raise EnvironmentError, error def __repr__( self ): self( "everything" ) return "" def __call__( self, ob, out=None ): try: self.call( ob, out ) return 1 except (KeyboardInterrupt, EOFError): return 0 def call( self, ob, out ): self.pager=out or self.Pager( self.out, self.line_length ) if type( ob ) in (type(""),type(u"")): if ob.startswith( "<" ): ob=ob[1:] if ob.endswith( ">" ): ob=ob[:-1] self.write( 'Topic: help( "%s" )\n' % ob ) if ob.startswith("doc:"): path=ob[4:] if not self.docdir: self.initDocDir() fullpath=os.path.join( self.docdir, path ) data=open( fullpath ).read() index=ob.rfind( "/" ) self.writeHTML( ob[:index], data ) else: try: info=topics[ob] docrlmatch=re.search( "(]+>)", info.split("\n")[0] ) if docrlmatch: # a first-line redirect self( docrlmatch.group(1) ) else: self.writeHTML( "", info ) except KeyError: glo=__builtins__.__dict__.get( ob, 0 ) if glo: self( glo ) else: sys.stderr.write( "No such topic "+`ob` ) return None else: self.write( 'Topic: help( %s )\n' % ob ) if hasattr( ob, "__doc__" ): self.writeText(ob.__doc__) else: self.writeText( type( ob ).__doc__ ) def writeHTML( self, base, str ): parser=self.Parser(self.Formatter( self.Writer( self ))) parser.feed( str ) # calls self.write automatically for i in range( len( parser.anchorlist) ): self.pager.write( "[%s] %s/%s\n" %(i+1, base,parser.anchorlist[i] )) self.pager.flush() self.out.write( "\n" ) def writeText( self, str ): self.pager.write( str ) self.pager.flush() self.out.write( "\n" ) def write( self, str ): self.pager.write( str ) from cStringIO import StringIO class Pager: numlines=1 def __init__(self, out, pagesize=24, linestart="" ): self.out=out self.pagesize=pagesize self.buf=StringIO() self.linestart=linestart def close(self ): self.flush() def flush(self ): data=self.buf.getvalue().rstrip() # dump trailing ws while data.endswith( "\n|" ): # dump trailing lines data=data[:-2] self.out.write( data ) self.buf=StringIO() def write(self, str ): lines=str.split( "\n" ) self.buf.write( lines[0] ) for line in lines[1:]: self.buf.write( "\n| " ) self.buf.write( line ) if self.numlines and not self.numlines%(self.pagesize): dat=self.buf.getvalue().strip() self.out.write( "| " ) self.out.write( dat ) self.out.write( "\n" ) j=raw_input(prompt) if j and j[0]=="q": raise EOFError self.buf=StringIO() self.numlines=self.numlines+1 help=Help(sys.stdout,24) def test(): rc = 1 rc = rc and help( "everything" ) rc = rc and help( "exec" ) rc = rc and help( "doc:lib/unix.html" ) rc = rc and help( "doc:lib/module-tty.html" ) rc = rc and help( "doc:ref/print.html" ) rc = rc and help( "faq" ) rc = rc and help( dir ) repr( help ) if __name__=="__main__": if len( sys.argv )!=2: print "Usage: %s or %s test" % ( sys.argv[0], sys.argv[0] ) sys.exit(0) elif sys.argv[1]=="test": test() else: help( sys.argv[1] ) From paul at prescod.net Mon Jul 17 01:11:07 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:11:07 -0500 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <20000716154138.U29590@lyra.org> <200007162353.SAA06185@cj20424-a.reston1.va.home.com> Message-ID: <3972410B.4847D37B@prescod.net> Okay, everybody seems to like the nondist idea, should it be nondist/src/onlinehelp.py # simple nondist/src/help/onlinehelp.py # its own directory -- in case it splits into two modules nondist/src/Lib/onlinehelp.py # code proposed for standard library -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From tim_one at email.msn.com Mon Jul 17 01:12:48 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 19:12:48 -0400 Subject: [Python-Dev] Checked in... In-Reply-To: <200007162353.SAA06185@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > I recommend the use of the nondist CVS tree for experiments. But to me > the dist subtree is sacred and should only contain code we believe we > agree on. That's easy to agree with too, but I need to make a confession here: my belief is that consensus will *never* be reached on anything having to do with doc presentation. Whether it's "structured text", or just what to put in a docstring, the Python community has an unbroken string of failures to agree on anything. Against that, Python has had an obvious need for better online help since the first day I used it, and anticipating that Paul's approach would never reach consensus, my vote to "sure! check it in!" was secretly based on "better anything than (10 more years of) poke-and-hope 'print thing.__doc__'". So this was a very special case to me. I don't cheat often, but when I do I make sure you're not looking <0.9 wink>. at-least-you're-annoyed-at-the-right-person-now-ly y'rs - tim From paul at prescod.net Mon Jul 17 01:22:08 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:22:08 -0500 Subject: [Python-Dev] Checked in... References: Message-ID: <397243A0.5F4AEE4F@prescod.net> Tim Peters wrote: > > ... > > That's easy to agree with too, but I need to make a confession here: my > belief is that consensus will *never* be reached on anything having to do > with doc presentation. Whether it's "structured text", or just what to put > in a docstring, the Python community has an unbroken string of failures to > agree on anything. I'm not quite as pessimistic as you but part of my rationale was anything, no matter how crappy, would be better than nothing, which is what we have years of. I don't care if its: help=""" Try http://www.python.org. Have a nice day! """ help=NameError is just rude! I am optimistic that having a user-friendly way to find out about objects will get the ball rolling for more docstrings, along with Ka Ping's code to put docstrings on the Web and some IDE's docstring reporting. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov at inrialpes.fr Mon Jul 17 01:43:41 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 17 Jul 2000 01:43:41 +0200 (CEST) Subject: [Python-Dev] intallation & help system Message-ID: <200007162343.BAA23397@python.inrialpes.fr> I've just installed the latest Gnome release (http://www.gnome.org) and I must say that I was really pleased (not to say, impressed) by two things: 1. Installation All I had to type was: ~> lynx -source http://go-gnome.com | sh This went on downloading and executing an installation script, which figured out automatically the system I am running on (RedHat 6.2), then asked me to select the nearest mirror and downloaded and installed the right set of packages for RH-6.2. Very cool! I'd like to see something similar for Python. 2. Integrated Help System You guys should definitely try out the Gnome help browser, if you haven't seen it already. This is a very good source of inspiration for implementing and integrated help for Python. The gnome-help browser is a unified interface to man, info and HTML docs. It introduces some 'magic' naming schemes (explained in ghelp:help-browser) For instance: a) http: ... The usual http: naming conventions for accessing documents through HTTP b) file: ... The usual file naming scheme for accessing local files) c) whatis: ... Do a substring search of document names Examples - whatis:ls whatis:xman d) toc: ... Load a table of contents of available documents Examples - toc: toc:man toc:info toc:ghelp e) man: ... Load a manual page Examples - man:ls man:ls(1) f) info: ... Load a GNU info page Examples - info:emacs info:emacs#Top g) ghelp: ... Load a Gnome help page for an application Examples - ghelp:help-browser If you're still unclear on how to implement an integrated help system for Python, replace 'ghelp' by 'python' or 'pyhelp' and steal everything else from the Gnome help system <0.5 wink>. happy-with-open-source'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul at prescod.net Mon Jul 17 01:39:03 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:39:03 -0500 Subject: [Python-Dev] Pre-PEP Idea References: Message-ID: <39724797.21AC2263@prescod.net> David Ascher wrote: > > ... > > Geez, guys, that's one of the first things I did for Python! I guess I'm cleaning up your unfinished project then. :) Anyhow, we can't expect Windows and Mac Python users to have info installed. > PS: Then again, these days I'd rather work out an API for a help lookup > mechanims that the twelve IDEs could all use, rather than encourage people > to stick with glass tty's =). I think that's the long-term goal. But the interpreter is the canonical Python user interface. Once we get information flowing into there, it will be easier to repurpose the information for the GUIs. Anyhow, I find this pretty useful: $ python onlinehelp.py dir Topic: help( ) | dir([object]) -> list of strings | | Return an alphabetized list of names comprising (some of) the attributes | of the given object. Without an argument, the names in the current scope | are listed. With an instance argument, only the instance attributes are | returned. With a class argument, attributes of the base class are not | returned. For other types or arguments, this may list members or methods. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Mon Jul 17 01:48:01 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:48:01 -0500 Subject: [Python-Dev] intallation & help system References: <200007162343.BAA23397@python.inrialpes.fr> Message-ID: <397249B1.7FD6EFF6@prescod.net> Vladimir Marangozov wrote: > >.. > > 2. Integrated Help System > > ... > > If you're still unclear on how to implement an integrated help system > for Python, replace 'ghelp' by 'python' or 'pyhelp' and steal everything > else from the Gnome help system <0.5 wink>. Okay, but Python needs a help system that is tty compatible. More advanced help systems should of course be provided by the IDEs. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov at inrialpes.fr Mon Jul 17 02:02:43 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 17 Jul 2000 02:02:43 +0200 (CEST) Subject: [Python-Dev] intallation & help system In-Reply-To: <397249B1.7FD6EFF6@prescod.net> from "Paul Prescod" at Jul 16, 2000 06:48:01 PM Message-ID: <200007170002.CAA23476@python.inrialpes.fr> Paul Prescod wrote: > > Vladimir Marangozov wrote: > > > >.. > > > > 2. Integrated Help System > > > > ... > > > > If you're still unclear on how to implement an integrated help system > > for Python, replace 'ghelp' by 'python' or 'pyhelp' and steal everything > > else from the Gnome help system <0.5 wink>. > > Okay, but Python needs a help system that is tty compatible. This is not a problem. I can get all this info on a tty instead of in a window. BTW, part of the Gnome installation process is tty-based. If there's a problem of some kind, ESR would solve them in no time, being an ncurses expert :-). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul at prescod.net Mon Jul 17 02:03:21 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 19:03:21 -0500 Subject: [Python-Dev] intallation & help system References: <200007170002.CAA23476@python.inrialpes.fr> Message-ID: <39724D49.135F0684@prescod.net> Vladimir Marangozov wrote: > > ... > > This is not a problem. I can get all this info on a tty instead of > in a window. BTW, part of the Gnome installation process is tty-based. > If there's a problem of some kind, ESR would solve them in no time, > being an ncurses expert :-). I still think that there is something important in not requiring anything beyond a command line, stdin and stdout for the basic help system. Curses won't run on the palm pilot! It should also be possible to plug in more sophisticated UIs where they are available. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gmcm at hypernet.com Mon Jul 17 02:08:48 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sun, 16 Jul 2000 20:08:48 -0400 Subject: [Python-Dev] ascii default encoding In-Reply-To: <39723393.BD32D592@lemburg.com> Message-ID: <1248329948-59293691@hypernet.com> M.-A. Lemburg, > Thomas Wouters wrote: [deprecate / depreciate] > It seems that one is stronger than the other. I'll stick with the > weaker one ;-) One is passive. Your new car depreciates in value, whether Guido says it should or not. > > > > Besides, 'string.join' is a good compromise for the people > > > > who don't like " ".join() > Fine... but it'll cause a performance hit when used in tight > loops (function call + method lookup). They should use somehting > like: > > spacejoin = ' '.join > spacejoin(sequence) > > instead. It's become very obvious that you haven't read c.l.py in quite awhile. - Gordon From paul at prescod.net Mon Jul 17 03:32:34 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 20:32:34 -0500 Subject: [Python-Dev] urllib and doc: (was: CVS: python/dist/src/Lib onlinehelp.py,NONE,1.1) References: <200007161953.MAA30130@slayer.i.sourceforge.net> <397216A0.EE5BB26E@lemburg.com> <397221EE.D248C6D3@prescod.net> <20000716150410.O29590@lyra.org> Message-ID: <39726232.BE95113@prescod.net> Greg Stein wrote: > > ... > > urllib should NOT try to parse a "doc:" scheme. Any scheme in urllib should > ONLY be IANA-registered schemes, and the resulting URL should follow the > appropriate RFCs. > > If doc: is ever registered, then go ahead and teach it to urllib. Until > then, I'll scream and shout and be very annoying :-) Actually, the URL specs are specifically designed to be extensible and to allow local, community-oriented URL (or URN) prefixes. It is a deficiency of urllib that it cannot be taught to deal with new URLs without changing its code. You can extend Java's URL handler or Windows URL handler "externally." Anyhow, I am light years ahead from doing anything in that vein. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From mhammond at skippinet.com.au Mon Jul 17 03:42:36 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 16 Jul 2000 21:42:36 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <1248369603-56908500@hypernet.com> Message-ID: [Gordon, responding to Barry] > In an ideal world, I rather like #5 (stubs), but I vote for #4 > (version number in the extension module name) or #6 (get a > life). #6 sounds good. But as I'm still experiencing a life in Orlando (with a couple of teenage girls dragging a couple of grumpy old Dads around Universal studios), I'll throw something in :-) Barry's idea sounds reasonable - although a little more elaborate than is necessary. Barry calls for all extension authors to modify their extension code. I can't see a simple solution that avoids this. However, the solution seems a little over-elaborate. If we are asking them to change their code, can we investigate whether asking them to insert a simple: if (!Py_IsInitialized()) Py_FatalError("Bad Python version"); /* Never returns */ works OK? I believe it will, as long as Python's fatal error handler doesnt make thread-state assumptions. Too-much-of-a-life-to-check-ly, Mark. From skip at mojam.com Mon Jul 17 03:24:26 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 16 Jul 2000 20:24:26 -0500 (CDT) Subject: [Python-Dev] Help command In-Reply-To: <20000716175835.Y7340@xs4all.nl> References: <3971C4AD.74EFAD90@prescod.net> <20000716175835.Y7340@xs4all.nl> Message-ID: <14706.24650.876236.67230@beluga.mojam.com> Thomas> On Sun, Jul 16, 2000 at 09:20:29AM -0500, Paul Prescod wrote: >> Does "man python" work yet? Or maybe my installation was just messed >> up. Thomas> Nope. It does on Mandrake 6.1 (a RH derivative). Skip From ping at lfw.org Mon Jul 17 07:28:24 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sun, 16 Jul 2000 22:28:24 -0700 (PDT) Subject: [Python-Dev] Checked in... In-Reply-To: <200007162332.SAA06030@cj20424-a.reston1.va.home.com> Message-ID: On Sun, 16 Jul 2000, Guido van Rossum wrote: > > in paul's defence, note that tim, greg stein, and moshe > > all told paul to go ahead and check it in... > > Sigh. Sorry Paul. Now I'm annoyed at Tim, Greg & Moshe. Uh, i'm afraid you'll have to add me to the list. I wanted to encourage Paul to proceed at full speed (even though i didn't get around to it before seeing the messages from the others). I've felt similarly: anything that works reasonably is better than nothing, even if it's not perfect. That said, i have been doing some stuff in this area -- check out http://www.lfw.org/python/ for inspect.py and htmldoc.py. The former in particular is useful for extracting docstrings and argument specs in a nice way. My plan was to complete htmldoc.py and try to get in into the distribution so that anyone could browse documentation on the standard library. It would include an option to start a little webserver with a one-line command so that doc pages could be automatically generated on your own modules as you work on them. The next step in the plan was to provide text output so you could ask about modules from the shell prompt (like a "man" command specific to Python) and a function call you could use from inside the interpreter to get quick help as well. -- ?!ng From martin at loewis.home.cs.tu-berlin.de Mon Jul 17 08:48:50 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 17 Jul 2000 08:48:50 +0200 Subject: [Python-Dev] Compiling the online documentation In-Reply-To: <20000716233459.D7340@xs4all.nl> (message from Thomas Wouters on Sun, 16 Jul 2000 23:34:59 +0200) References: <200007162126.XAA25108@loewis.home.cs.tu-berlin.de> <20000716233459.D7340@xs4all.nl> Message-ID: <200007170648.IAA00903@loewis.home.cs.tu-berlin.de> Thomas Wouters wrote: > Only if you have TeX/LaTeX *and* latex2html installed :P I've failed to find > an RPM for latex2html up til now, and I'm too lazy to hunt down the sources > and compile it myself. I found one at ftp://ftp.cs.tu-berlin.de/pub/linux/Mirrors/contrib.redhat.com/noarch/noarch/latex2html-99.1-1.noarch.rpm This, in turn, needs giftrans-1.12.2-4.i386.rpm. With both packages installed, I tried to run make in Doc/html again, only to get PAPER=letter ../tools/mkhtml.sh api -html_version 4.0 latex2html -init_file /usr/src/python/Doc/perl/l2hinit.perl -dir api -html_version 4.0 /usr/src/python/Doc/api/api.tex Too many arguments for undef operator at /usr/bin/latex2html line 2771, near "$trans)" Too many arguments for undef operator at /usr/bin/latex2html line 3076, near "$etmp)" BEGIN not safe after errors--compilation aborted at /usr/bin/latex2html line 4404. This is with perl 5.6; which perl version is required for latex2html? Regards, Martin From mal at lemburg.com Mon Jul 17 09:55:02 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 09:55:02 +0200 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> Message-ID: <3972BBD6.A81B2577@lemburg.com> Greg Stein wrote: > > On Mon, Jul 17, 2000 at 12:01:48AM +0200, M.-A. Lemburg wrote: > > Greg Stein wrote: > >... > > > ! #define UTF8_ERROR(details) \ > > > ! if (1) { \ > > > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > > > ! goto onError; \ > > > ! continue; \ > > > ! } else > > > > Greg, this doesn't work... UTF8_ERROR is used in if-clauses > > and the above may alter the else-branches in subtle ways which > > are just as hard to detect as the original bug. The goto may > > not be the greatest in style, but it doesn't have the above > > caveats. > > Nope. It *does* work. Note the "else" on the end there. That creates the > proper binding. Greg, I did see the "else", but that does two things: it breaks the code if there's no semicolon after the UT8F_ERROR() macro and it produces warnings which relate to the fact that the "else" part is ambiguous: if (condition) UTF8_ERROR(); else {...} expands to: if (condition) if (1) {...} else ; else {...} And gcc doesn't like it: unicodeobject.c: In function `PyUnicode_FromEncodedObject': unicodeobject.c:424: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:429: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c: In function `PyUnicode_DecodeUTF8': unicodeobject.c:673: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:687: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:698: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:710: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:716: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c: In function `PyUnicode_EncodeUTF8': unicodeobject.c:829: warning: suggest parentheses around arithmetic in operand of | unicodeobject.c: At top level: unicodeobject.c:755: warning: `utf8_encoding_error' defined but not used > All uses of the UTF8_ERROR() macro have a semicolon after them (like any > normal statement does(!)). This expands the macro to: > > if (1) { > ... > } else > ; /* this is the semicolon I referred to */ > > Therefore, it creates a complete if/else statement, and any surrounding > if/else statements will bind as expected. The goto solution is much cleaner and also easier to understand. Please revert the change you made (or I will ;-). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Mon Jul 17 10:09:53 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 10:09:53 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: Message-ID: <003f01bfefc6$64840540$f2a6b5d4@hagrid> mark wrote: > If we are asking them to change their code, can we investigate whether > asking them to insert a simple: > > if (!Py_IsInitialized()) > Py_FatalError("Bad Python version"); /* Never returns */ > > works OK? I believe it will, as long as Python's fatal error handler > doesnt make thread-state assumptions. I'm probably missing something here, but is there any reason you cannot add this code to Py_InitModule4 instead: PyObject *m, *d, *v; PyMethodDef *ml; + if (!Py_IsInitialized()) + Py_FatalError("Bad Python version"); /* Never returns */ if (module_api_version != PYTHON_API_VERSION) fprintf(stderr, api_version_warning, From mal at lemburg.com Mon Jul 17 10:06:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 10:06:50 +0200 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> Message-ID: <3972BE9A.3C09AC97@lemburg.com> > Okay, I've removed it and attached it to this email but I still think > that's a pretty cumbersome way to proceed. I've already made one > modification. Future ones will need to be distributed as email patches. > As a new module that won't be the basis of anything, and with > significant interest, I don't see the danger in a checkin. The standard procedure has always been to put the code and the docs somewhere up on the web to support future developments. You only have to publish the pointers every now and then. It was worked great in the past. I don't see any reason it shouldn't work now. I agree with Guido that dist/ shouldn't be used for developing new software, but also agree with Paul et al. that this is a valueable addition to the standard lib. > Anyhow, this version should not require the PYTHONDOCS environment > variable unless you try to refer to a help topic that requires the > online help. Still, in the future, I don't see the benefit in > duplicating the documentation for all of the statements and operators. > If you want that documentation, you'll probably need the HTML installed. You may want to have a look at my hack.py utility which already provides a convenient way of printing the doc strings *and* the published interface: http://starship.python.net/?lemburg/hack.py It needs to be modified a bit to work with SRE since it uses the old regs array (the tool was written for regex which had this array, then ported to re, which also had the array, but didn't document it; SRE doesn't have it anymore... sigh). Here's an example: >>> hack.docs(os) Module : _exit : _exit(status) Exit to the system with specified status, without normal exit processing. chdir : chdir(path) -> None Change the current working directory to the specified path. chmod : chmod(path, mode) -> None Change the access permissions of a file. chown : chown(path, uid, gid) -> None Change the owner and group id of path to the numeric uid and gid. close : close(fd) -> None Close a file descriptor (for low level IO). dup : dup(fd) -> fd2 Return a duplicate of a file descriptor. dup2 : dup2(fd, fd2) -> None Duplicate file descriptor. execv : execv(path, args) Execute an executable path with arguments, replacing current process. path: path of executable file args: tuple or list of strings execve : execve(path, args, env) Execute a path with arguments and environment, replacing current process. path: path of executable file args: tuple or list of arguments env: dictonary of strings mapping to strings fdopen : fdopen(fd, [, mode='r' [, bufsize]]) -> file_object Return an open file object connected to a file descriptor. fork : fork() -> pid Fork a child process. Return 0 to child process and PID of child to parent process. fstat : fstat(fd) -> (mode, ino, dev, nlink, uid, gid, size, atime, mtime, ctime) Like stat(), but for an open file descriptor. ftruncate : ftruncate(fd, length) -> None Truncate a file to a specified length. getcwd : getcwd() -> path Return a string representing the current working directory. getegid : getegid() -> egid Return the current process's effective group id. geteuid : geteuid() -> euid Return the current process's effective user id. getgid : getgid() -> gid Return the current process's group id. getpgrp : getpgrp() -> pgrp Return the current process group id. getpid : getpid() -> pid Return the current process id getppid : getppid() -> ppid Return the parent's process id. getuid : getuid() -> uid Return the current process's user id. kill : kill(pid, sig) -> None Kill a process with a signal. link : link(src, dst) -> None Create a hard link to a file. listdir : listdir(path) -> list_of_strings Return a list containing the names of the entries in the directory. path: path of directory to list The list is in arbitrary order. It does not include the special entries '.' and '..' even if they are present in the directory. lseek : lseek(fd, pos, how) -> newpos Set the current position of a file descriptor. lstat : lstat(path) -> (mode,ino,dev,nlink,uid,gid,size,atime,mtime,ctime) Like stat(path), but do not follow symbolic links. mkdir : mkdir(path [, mode=0777]) -> None Create a directory. mkfifo : mkfifo(file, [, mode=0666]) -> None Create a FIFO (a POSIX named pipe). nice : nice(inc) -> new_priority Decrease the priority of process and return new priority. open : open(filename, flag [, mode=0777]) -> fd Open a file (for low level IO). Module path : Common pathname manipulations, Posix version. Instead of importing this module directly, import os and refer to this module as os.path. pipe : pipe() -> (read_end, write_end) Create a pipe. popen : popen(command [, mode='r' [, bufsize]]) -> pipe Open a pipe to/from a command returning a file object. putenv : putenv(key, value) -> None Change or add an environment variable. read : read(fd, buffersize) -> string Read a file descriptor. readlink : readlink(path) -> path Return a string representing the path to which the symbolic link points. remove : remove(path) -> None Remove a file (same as unlink(path)). rename : rename(old, new) -> None Rename a file or directory. rmdir : rmdir(path) -> None Remove a directory. setgid : setgid(gid) -> None Set the current process's group id. setpgid : setpgid(pid, pgrp) -> None Call the system call setpgid(). setpgrp : setpgrp() -> None Make this process a session leader. setsid : setsid() -> None Call the system call setsid(). setuid : setuid(uid) -> None Set the current process's user id. stat : stat(path) -> (mode,ino,dev,nlink,uid,gid,size,atime,mtime,ctime) Perform a stat system call on the given path. strerror : strerror(code) -> string Translate an error code to a message string. symlink : symlink(src, dst) -> None Create a symbolic link. system : system(command) -> exit_status Execute the command (a string) in a subshell. tcgetpgrp : tcgetpgrp(fd) -> pgid Return the process group associated with the terminal given by a fd. tcsetpgrp : tcsetpgrp(fd, pgid) -> None Set the process group associated with the terminal given by a fd. times : times() -> (utime, stime, cutime, cstime, elapsed_time) Return a tuple of floating point numbers indicating process times. umask : umask(new_mask) -> old_mask Set the current numeric umask and return the previous umask. uname : uname() -> (sysname, nodename, release, version, machine) Return a tuple identifying the current operating system. unlink : unlink(path) -> None Remove a file (same as remove(path)). utime : utime(path, (atime, utime)) -> None Set the access and modified time of the file to the given values. wait : wait() -> (pid, status) Wait for completion of a child process. waitpid : waitpid(pid, options) -> (pid, status) Wait for completion of a give child process. write : write(fd, string) -> byteswritten Write a string to a file descriptor. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 17 10:11:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 10:11:37 +0200 Subject: [Python-Dev] ascii default encoding References: <1248329948-59293691@hypernet.com> Message-ID: <3972BFB9.180C9502@lemburg.com> Gordon McMillan wrote: > > M.-A. Lemburg, > > > Thomas Wouters wrote: > > [deprecate / depreciate] > > > It seems that one is stronger than the other. I'll stick with the > > weaker one ;-) > > One is passive. Your new car depreciates in value, whether > Guido says it should or not. Ok ok... :-) I'll remove the "i" from "depreciated" and will instead try to add the "n" to "unkown" -- promised ;-) > > > > > Besides, 'string.join' is a good compromise for the people > > > > > who don't like " ".join() > > > Fine... but it'll cause a performance hit when used in tight > > loops (function call + method lookup). They should use somehting > > like: > > > > spacejoin = ' '.join > > spacejoin(sequence) > > > > instead. > > It's become very obvious that you haven't read c.l.py in quite > awhile. That's true -- don't have time for that anymore. I usually only scan the newsgroup for articles related to my mx stuff and database/datetime related things. For me, python-dev has become the new home. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Mon Jul 17 10:18:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 10:18:05 +0200 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> Message-ID: <007501bfefc7$8aff9800$f2a6b5d4@hagrid> mal wrote: > It needs to be modified a bit to work with SRE since it > uses the old regs array (the tool was written for regex > which had this array, then ported to re, which also had the > array, but didn't document it; SRE doesn't have it anymore... > sigh). the next SRE checkin has it... coming later today, assuming that I can find the new little bug I just introduced... while you're waiting, feel free to use "pre" instead. From mal at lemburg.com Mon Jul 17 10:15:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 10:15:50 +0200 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> <007501bfefc7$8aff9800$f2a6b5d4@hagrid> Message-ID: <3972C0B6.2C80DF9C@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > It needs to be modified a bit to work with SRE since it > > uses the old regs array (the tool was written for regex > > which had this array, then ported to re, which also had the > > array, but didn't document it; SRE doesn't have it anymore... > > sigh). > > the next SRE checkin has it... coming later today, assuming > that I can find the new little bug I just introduced... Cool :-) > while you're waiting, feel free to use "pre" instead. Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 17 10:26:54 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 10:26:54 +0200 Subject: [Python-Dev] binary incompatibility and tp_flags (was: Linker problems on Linux) References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> Message-ID: <3972C34E.A470B748@lemburg.com> Greg Stein wrote: > > On Sun, Jul 16, 2000 at 11:25:53PM +0200, Thomas Wouters wrote: > > On Sun, Jul 16, 2000 at 10:57:47PM +0200, Martin v. Loewis wrote: > > > > > For example, if you have a 1.5.2-compiled type in an extension module, > > > and that type happens to implement PySequenceMethods, then applying 'a > > > in b' will likely crash: Python 2 will check for the sq_contains > > > field, but that is past the end of the function table in the old > > > module. > > > > Nope. This is specifically fixed by the new tp_flags structmember (which was > > 'unused' before, so reading *that* will work ok) and the PyType_HasFeature > > macro. All code that wants to access one of the really new struct members > > (currently, bf_getcharbuffer, sq_contains and the cycle-gc stuff. And my > > augmented assignment patch adds another 13 ;) should check tp_flags first. > > > > See the comment in Include/object.h regarding this. > > Actually, those flags should only be used if you are attempting to maintain > binary compatibility. > > At the point where you say "okay. binary compatibility is hereby broken.", > then we go and remove the flags for the new structure members. I can't remember anyone saying something in that direction. > The last API bump was to 1009 for "Unicode API added". I'm not sure why > Guido bumped it since the *addition* of an API shouldn't create binary > incompatibility. He bumped it so that extensions can switch on the API number and then decide whether to use the new API or not... there are extensions out there which want to be compatible to 1.5.2 *and* 2.0. E.g. my mx stuff has a special portability file (mxpyapi.h) which is meant to achieve exactly this... > Regardless, I think we have introduced several semantic incompatibilities or > even signature changes in the APIs. We should do a bump for safety's sake > and we should toss the two Py_TPFLAGS_HAVE_* macros (and the corresponding > tests within the core interpreter). I can only speak for my mx stuff, but that still works greats with the 2.0 API -- except for the missing PyObject_Length() API, but that'll go back in as soon as Thomas has modified his patch on SF. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Mon Jul 17 10:40:33 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 10:40:33 +0200 Subject: [Python-Dev] binary incompatibility and tp_flags (was: Linker problems on Linux) In-Reply-To: <3972C34E.A470B748@lemburg.com>; from mal@lemburg.com on Mon, Jul 17, 2000 at 10:26:54AM +0200 References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> <3972C34E.A470B748@lemburg.com> Message-ID: <20000717104033.F7340@xs4all.nl> On Mon, Jul 17, 2000 at 10:26:54AM +0200, M.-A. Lemburg wrote: > I can only speak for my mx stuff, but that still works greats > with the 2.0 API -- except for the missing PyObject_Length() > API, but that'll go back in as soon as Thomas has modified > his patch on SF. I already did that ;) About 5 minutes after you added the comment about it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein at lyra.org Mon Jul 17 11:05:32 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:05:32 -0700 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) In-Reply-To: <3972BBD6.A81B2577@lemburg.com>; from mal@lemburg.com on Mon, Jul 17, 2000 at 09:55:02AM +0200 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> Message-ID: <20000717020531.X29590@lyra.org> On Mon, Jul 17, 2000 at 09:55:02AM +0200, M.-A. Lemburg wrote: > Greg Stein wrote: >... > > Nope. It *does* work. Note the "else" on the end there. That creates the > > proper binding. > > Greg, I did see the "else", but that does two things: it breaks > the code if there's no semicolon after the UT8F_ERROR() macro The current *and* the previous macro would break if there was no semicolon. No difference here. > and it produces warnings which relate to the fact that the "else" > part is ambiguous: > > if (condition) UTF8_ERROR(); > else {...} > > expands to: > > if (condition) > if (1) {...} > else ; > else {...} That is not ambiguous. > And gcc doesn't like it: > > unicodeobject.c: In function `PyUnicode_FromEncodedObject': > unicodeobject.c:424: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:429: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c: In function `PyUnicode_DecodeUTF8': > unicodeobject.c:673: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:687: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:698: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:710: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:716: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c: In function `PyUnicode_EncodeUTF8': > unicodeobject.c:829: warning: suggest parentheses around arithmetic in operand of | > unicodeobject.c: At top level: > unicodeobject.c:755: warning: `utf8_encoding_error' defined but not used Agreed. It produces warnings. gcc is being stupid here because there is no ambiguity. It is saying "well, gee golly, you might have a problem" but we really don't. gcc is trying to be too smart. But hey... if it wants to produce warnings... then fine. We can work around the dumb thing. > > All uses of the UTF8_ERROR() macro have a semicolon after them (like any > > normal statement does(!)). This expands the macro to: > > > > if (1) { > > ... > > } else > > ; /* this is the semicolon I referred to */ > > > > Therefore, it creates a complete if/else statement, and any surrounding > > if/else statements will bind as expected. > > The goto solution is much cleaner and also easier to understand. Arguable. > Please revert the change you made (or I will ;-). I will, but only to shut gcc up. It is flat out wrong. -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 17 11:16:56 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:16:56 -0700 Subject: [Python-Dev] Checked in... In-Reply-To: <3972410B.4847D37B@prescod.net>; from paul@prescod.net on Sun, Jul 16, 2000 at 06:11:07PM -0500 References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <20000716154138.U29590@lyra.org> <200007162353.SAA06185@cj20424-a.reston1.va.home.com> <3972410B.4847D37B@prescod.net> Message-ID: <20000717021656.Z29590@lyra.org> On Sun, Jul 16, 2000 at 06:11:07PM -0500, Paul Prescod wrote: > Okay, everybody seems to like the nondist idea, should it be > > nondist/src/onlinehelp.py > # simple > nondist/src/help/onlinehelp.py > # its own directory -- in case it splits into two modules > nondist/src/Lib/onlinehelp.py > # code proposed for standard library There isn't any need for organization. The area is not going to be heavily trafficked. If somebody comes along with something "big", then they can place it into a subdir. Even then, it could be questionable. The audience for this stuff is python-dev. nondist/src/ is still a bit official. As I mentioned in my note, /nondist/sandbox/ is a good candidate -- it is very clear that we are talking about stuff that is just messing around. Therefore, I'd suggest /nondist/sandbox/onlinehelp.py Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Mon Jul 17 11:15:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 11:15:53 +0200 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> Message-ID: <3972CEC9.1842AD7F@lemburg.com> Greg Stein wrote: > > > The goto solution is much cleaner and also easier to understand. > > Arguable. > > > Please revert the change you made (or I will ;-). > > I will, but only to shut gcc up. It is flat out wrong. Thank you :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Mon Jul 17 11:17:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 11:17:41 +0200 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) In-Reply-To: <20000717020531.X29590@lyra.org>; from gstein@lyra.org on Mon, Jul 17, 2000 at 02:05:32AM -0700 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> Message-ID: <20000717111741.H7340@xs4all.nl> On Mon, Jul 17, 2000 at 02:05:32AM -0700, Greg Stein wrote: > On Mon, Jul 17, 2000 at 09:55:02AM +0200, M.-A. Lemburg wrote: > > and it produces warnings which relate to the fact that the "else" > > part is ambiguous: > > > > if (condition) UTF8_ERROR(); > > else {...} > > > > expands to: > > > > if (condition) > > if (1) {...} > > else ; > > else {...} > > That is not ambiguous. Nope. The example was flawed. *this* is ambiguous: if (condition) UTF8_ERROR(); And that's exactly what gcc is whining about: if (s + n > e) UTF8_ERROR("unexpected end of data"); It's very clearly defined what happens, here, but gcc can't see the macro as is, and mis-placing 'else's is a very common error. Especially combined with macros :) In absense of a standard-defined error-reporting tool, gcc -Wall does a very good job. And don't start about lint, the versions of lint I've seen were much more picky ;) > > The goto solution is much cleaner and also easier to understand. > Arguable. Even more arguable is the coding style issue ;) I haven't seen this 'if (1) {} else' trick used in macros elsewhere, not in Python and not in other code. Granted, those pieces of code didn't need to call continue, but I personally prefer the goto over the weird macro. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Mon Jul 17 11:23:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 11:23:26 +0200 Subject: [Python-Dev] binary incompatibility and tp_flags (was: Linker problems on Linux) References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> <3972C34E.A470B748@lemburg.com> <20000717104033.F7340@xs4all.nl> Message-ID: <3972D08E.B2F38679@lemburg.com> Thomas Wouters wrote: > > On Mon, Jul 17, 2000 at 10:26:54AM +0200, M.-A. Lemburg wrote: > > > I can only speak for my mx stuff, but that still works greats > > with the 2.0 API -- except for the missing PyObject_Length() > > API, but that'll go back in as soon as Thomas has modified > > his patch on SF. > > I already did that ;) About 5 minutes after you added the comment about it. Checked in. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Mon Jul 17 11:30:02 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:30:02 -0700 Subject: [Python-Dev] binary incompatibility and tp_flags In-Reply-To: <3972C34E.A470B748@lemburg.com>; from mal@lemburg.com on Mon, Jul 17, 2000 at 10:26:54AM +0200 References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> <3972C34E.A470B748@lemburg.com> Message-ID: <20000717023002.C29590@lyra.org> On Mon, Jul 17, 2000 at 10:26:54AM +0200, M.-A. Lemburg wrote: > Greg Stein wrote: >... > > Actually, those flags should only be used if you are attempting to maintain > > binary compatibility. > > > > At the point where you say "okay. binary compatibility is hereby broken.", > > then we go and remove the flags for the new structure members. > > I can't remember anyone saying something in that direction. Never said anyone did :-) ... just said, "*when* it happens, then we have some stuff that we can clean out." > > The last API bump was to 1009 for "Unicode API added". I'm not sure why > > Guido bumped it since the *addition* of an API shouldn't create binary > > incompatibility. > > He bumped it so that extensions can switch on the API number > and then decide whether to use the new API or not... there are > extensions out there which want to be compatible to 1.5.2 *and* > 2.0. E.g. my mx stuff has a special portability file (mxpyapi.h) > which is meant to achieve exactly this... Hrm. This is a bit weird then. Modules will produce errors when they really don't need to. I understand that it would be handy to say "hey, does the Unicode stuff exist", but that same mechanism is going to produce errors at module-init time when stuff is loaded. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 17 11:39:50 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:39:50 -0700 Subject: [Python-Dev] if/else and macros In-Reply-To: <20000717111741.H7340@xs4all.nl>; from thomas@xs4all.net on Mon, Jul 17, 2000 at 11:17:41AM +0200 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> Message-ID: <20000717023950.E29590@lyra.org> On Mon, Jul 17, 2000 at 11:17:41AM +0200, Thomas Wouters wrote: > On Mon, Jul 17, 2000 at 02:05:32AM -0700, Greg Stein wrote: > > On Mon, Jul 17, 2000 at 09:55:02AM +0200, M.-A. Lemburg wrote: > > > > and it produces warnings which relate to the fact that the "else" > > > part is ambiguous: > > > > > > if (condition) UTF8_ERROR(); > > > else {...} > > > > > > expands to: > > > > > > if (condition) > > > if (1) {...} > > > else ; > > > else {...} > > > > That is not ambiguous. > > Nope. The example was flawed. *this* is ambiguous: > > if (condition) UTF8_ERROR(); > > And that's exactly what gcc is whining about: > > if (s + n > e) > UTF8_ERROR("unexpected end of data"); Oh come on. This is getting silly. Neither of those examples are ambiguous. C has a very strict definition of what happens. In your examples, it expands to: if (condition) if (1) { ... } else ; GCC spits out a warning to tell the person "oh hey... I'm associating that else with the second 'if' command... but I'm going to spit out a warning just in case that isn't want you really meant." There is no ambiguity. Zero. I repeat: none. GCC is simply *assuming* that you may have messed up, so it spits out a warning. But ambiguity? Not at all. Cheers, -g -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Mon Jul 17 11:45:18 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 11:45:18 +0200 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> Message-ID: <000d01bfefd3$b924d540$f2a6b5d4@hagrid> thomas wrote: > Even more arguable is the coding style issue ;) I haven't seen this 'if (1) > {} else' trick used in macros elsewhere, not in Python and not in other > code hey, it's saving a whopping ten lines of code, or so ;-) If I'd written that code, I'd spelled it out... and come to think of it, I *did* write the original version of that code! FYI, I don't like that macro. Instead of arguing about how it should look, just get rid of it. here's how the original code looked: if (ch < 0x80) goto bogus; /* illegal UTF-8 encoding */ ... bogus: PyErr_SetString( PyExc_ValueError, "invalid UTF-8 code" ); ... I would have implemented the changes like this: if (ch < 0x80) { detail = "illegal encoding"; goto bogus; } ... bogus: if (!utf8_decoding_error(&s, &p, errors, detail)) goto ignore; ... This solution gets rids of the macro mess, and what's more important, it moves exception handling out of the inner loop. (yes, it's using goto's, but it's a decoding loop, and it should be as fast as it possibly can -- especially if you're feeding it valid data!) The result is smaller source, smaller code, a smaller inner loop, faster decoding, and less discussion on this list. From gstein at lyra.org Mon Jul 17 11:57:56 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:57:56 -0700 Subject: [Python-Dev] if/else and macros In-Reply-To: <000d01bfefd3$b924d540$f2a6b5d4@hagrid>; from effbot@telia.com on Mon, Jul 17, 2000 at 11:45:18AM +0200 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> Message-ID: <20000717025756.G29590@lyra.org> On Mon, Jul 17, 2000 at 11:45:18AM +0200, Fredrik Lundh wrote: >... > This solution gets rids of the macro mess, and what's more > important, it moves exception handling out of the inner loop. > > (yes, it's using goto's, but it's a decoding loop, and it should > be as fast as it possibly can -- especially if you're feeding it > valid data!) > > The result is smaller source, smaller code, a smaller inner loop, > faster decoding, and less discussion on this list. Can't just out of the loop. One of the possible results of the error is to ignore it and continue. Or to insert a particular character and continue. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Mon Jul 17 12:04:12 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 12:04:12 +0200 Subject: [Python-Dev] binary incompatibility and tp_flags References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> <3972C34E.A470B748@lemburg.com> <20000717023002.C29590@lyra.org> Message-ID: <3972DA1C.E273F9C7@lemburg.com> Greg Stein wrote: > > On Mon, Jul 17, 2000 at 10:26:54AM +0200, M.-A. Lemburg wrote: > > Greg Stein wrote: > >... > > > Actually, those flags should only be used if you are attempting to maintain > > > binary compatibility. > > > > > > At the point where you say "okay. binary compatibility is hereby broken.", > > > then we go and remove the flags for the new structure members. > > > > I can't remember anyone saying something in that direction. > > Never said anyone did :-) ... just said, "*when* it happens, then we have > some stuff that we can clean out." Ah, ok :) > > > The last API bump was to 1009 for "Unicode API added". I'm not sure why > > > Guido bumped it since the *addition* of an API shouldn't create binary > > > incompatibility. > > > > He bumped it so that extensions can switch on the API number > > and then decide whether to use the new API or not... there are > > extensions out there which want to be compatible to 1.5.2 *and* > > 2.0. E.g. my mx stuff has a special portability file (mxpyapi.h) > > which is meant to achieve exactly this... > > Hrm. This is a bit weird then. Modules will produce errors when they really > don't need to. > > I understand that it would be handy to say "hey, does the Unicode stuff > exist", but that same mechanism is going to produce errors at module-init > time when stuff is loaded. The modules produce API warnings at startup, but they still continue to work like before and this is important since there are many people out there which are used to updating their software via RPM (or other packagers) and don't know how to compile source files. My comment about the API number bump was referring to using added functionality if available -- there could be #ifdef sections in the source files to enable/disable e.g. Unicode support. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Mon Jul 17 12:42:59 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 05:42:59 -0500 Subject: [Python-Dev] Checked in... References: Message-ID: <3972E333.363CD227@prescod.net> Ka-Ping Yee wrote: > >... > > My plan was to complete htmldoc.py and try to get in into the > distribution so that anyone could browse documentation on the > standard library. +1 > It would include an option to start a little > webserver with a one-line command so that doc pages could be > automatically generated on your own modules as you work on them. +0 > The next step in the plan was to provide text output so you > could ask about modules from the shell prompt (like a "man" > command specific to Python) and a function call you could use > from inside the interpreter to get quick help as well. Not sure how to interpret this. If it depends on the aforementioned web server, I'm -1. If it calls the htmldoc code directly, I'm +1. I'd love to have the interpreter build on your docstring-formatting heuristics and that docstring-language plugin feature we discussed to allow people to experiment with semi-structured docstring formats. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Mon Jul 17 13:17:00 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 06:17:00 -0500 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> Message-ID: <3972EB2C.66EAB279@prescod.net> "M.-A. Lemburg" wrote: > > ... > > You may want to have a look at my hack.py utility which already > provides a convenient way of printing the doc strings *and* > the published interface: > > http://starship.python.net/?lemburg/hack.py Yes, that's got some pretty nice ideas. I may get the same features from Ka-Ping's htmldoc so that we don't have two pieces of code doing the same thing. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From peter at schneider-kamp.de Mon Jul 17 15:36:35 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 17 Jul 2000 13:36:35 +0000 Subject: [Python-Dev] SourceForge down? Message-ID: <39730BE3.B1A83A59@schneider-kamp.de> Since yesterday evening I cannot get to the Python pages at SourceForge. That is sometimes I cannot even log in to SourceForge. Other times it just takes minutes to load a page. Do you experience something similar? Or is it just me? Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mal at lemburg.com Mon Jul 17 13:40:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 13:40:50 +0200 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> <3972EB2C.66EAB279@prescod.net> Message-ID: <3972F0C2.E0266A0C@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > You may want to have a look at my hack.py utility which already > > provides a convenient way of printing the doc strings *and* > > the published interface: > > > > http://starship.python.net/~lemburg/hack.py > > Yes, that's got some pretty nice ideas. I may get the same features from > Ka-Ping's htmldoc so that we don't have two pieces of code doing the > same thing. Do you have a pointer for it ? (I'm always interested in new tools which support auto-documentation.) Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Mon Jul 17 13:44:55 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 13:44:55 +0200 Subject: [Python-Dev] SourceForge down? In-Reply-To: <39730BE3.B1A83A59@schneider-kamp.de>; from peter@schneider-kamp.de on Mon, Jul 17, 2000 at 01:36:35PM +0000 References: <39730BE3.B1A83A59@schneider-kamp.de> Message-ID: <20000717134455.J7340@xs4all.nl> On Mon, Jul 17, 2000 at 01:36:35PM +0000, Peter Schneider-Kamp wrote: > Since yesterday evening I cannot get to the Python pages at > SourceForge. That is sometimes I cannot even log in to > SourceForge. Other times it just takes minutes to load > a page. I had similar problems yesterday during the day. I've reported it to staff at sourceforge.net, and they confirmed something looked messed up. Sometime during the (european) evening things started working properly again. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Mon Jul 17 13:46:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 13:46:26 +0200 Subject: [Python-Dev] SourceForge down? References: <39730BE3.B1A83A59@schneider-kamp.de> Message-ID: <3972F212.5E5A7E4B@lemburg.com> Peter Schneider-Kamp wrote: > > Since yesterday evening I cannot get to the Python pages at > SourceForge. That is sometimes I cannot even log in to > SourceForge. Other times it just takes minutes to load > a page. > > Do you experience something similar? Or is it just me? Works fine for me... you sometimes just have to wait a few minutes for the response :-( -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Mon Jul 17 13:52:14 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 06:52:14 -0500 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> <3972EB2C.66EAB279@prescod.net> <3972F0C2.E0266A0C@lemburg.com> Message-ID: <3972F36E.4A03E71B@prescod.net> "M.-A. Lemburg" wrote: > > > Do you have a pointer for it ? (I'm always interested in new > tools which support auto-documentation.) http://www.lfw.org/python/ -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From mal at lemburg.com Mon Jul 17 14:09:42 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 14:09:42 +0200 Subject: [Python-Dev] htmldoc.py + inspect.py References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> <3972EB2C.66EAB279@prescod.net> <3972F0C2.E0266A0C@lemburg.com> <3972F36E.4A03E71B@prescod.net> Message-ID: <3972F786.42FA2BE1@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > > > Do you have a pointer for it ? (I'm always interested in new > > tools which support auto-documentation.) > > http://www.lfw.org/python/ The output looks cool given that none of the standard lib Python module doc-strings were explicitely written to be rendered by this tool. But what I particularly like is the inspect.py module. That would make a great addition to the standard lib ! Note to Ping: your files are missing a clear license notice. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From infoez at macauweb.com Mon Jul 17 15:30:16 2000 From: infoez at macauweb.com (Sin Hang Kin) Date: Mon, 17 Jul 2000 21:30:16 +0800 Subject: [Python-Dev] Will Python die? Message-ID: <003f01bfeff3$26ac9840$770da8c0@bbs> See subject. I am really worry, before putting more effort to it, can any body explain the current status of python 2? Unicode is a must for my work, without it, python is useless. So I need python 2, if 2.0 will die, I better switch beforehand. Sorry!!! but it is very important. Rgs, Kent Sin --------------------------------- kentsin.weblogs.com kentsin.imeme.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at beopen.com Mon Jul 17 15:44:53 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 17 Jul 2000 09:44:53 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory In-Reply-To: <200007171050.DAA28047@slayer.i.sourceforge.net> References: <200007171050.DAA28047@slayer.i.sourceforge.net> Message-ID: <14707.3541.488523.886708@bitdiddle.concentric.net> Paul, You created a nondist subdirectory in the nondist tree. I don't think this is what you intended. Jeremy From mal at lemburg.com Mon Jul 17 15:43:51 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 15:43:51 +0200 Subject: [Python-Dev] Will Python die? References: <003f01bfeff3$26ac9840$770da8c0@bbs> Message-ID: <39730D97.323ADC08@lemburg.com> > Sin Hang Kin wrote: > > See subject. > I am really worry, before putting more effort to it, can any body explain the current status of python 2? In short: no way ;-) For the long story read on here: http://www.pythonlabs.com/tech/python2.html http://www.pythonlabs.com/tech/ http://www.pythonlabs.com/plans.html > Unicode is a must for my work, without it, python is useless. So I need python 2, if 2.0 will die, I better switch beforehand. Python2 has native Unicode support -- probably one of the most advanced there currently is among scripting languages. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Mon Jul 17 15:50:48 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 15:50:48 +0200 Subject: [Python-Dev] Will Python die? In-Reply-To: <003f01bfeff3$26ac9840$770da8c0@bbs>; from infoez@macauweb.com on Mon, Jul 17, 2000 at 09:30:16PM +0800 References: <003f01bfeff3$26ac9840$770da8c0@bbs> Message-ID: <20000717155048.K7340@xs4all.nl> On Mon, Jul 17, 2000 at 09:30:16PM +0800, Sin Hang Kin wrote: > I am really worry, before putting more effort to it, can any body explain > the current status of python 2? > Unicode is a must for my work, without it, python is useless. So I need > python 2, if 2.0 will die, I better switch beforehand. > Sorry!!! but it is very important. You betcha it's important ! What do those five people at PythonLabs do when Python dies ? They'd be out of a job ! Can't have that, now can we ;) Seriously, though: Python is not dead. Python 2 is not dead. CNRI and BeOpen are trying to resolve some 'issues', and the last news is that CNRI is going to release Python 1.6. I assume it'll be based off the 1.6 alphas, and those included unicode. BeOpen / PythonLabs will probably start by releasing Python 2.0. This'll likely have to wait until 1.6 is released, but the python dev team is working hard to make 2.0 a complete release on its own. It will include unicode, probably with less bugs and problems than 1.6 ;-) It will also include a ton of other things, which are being worked on right now. (Some of the things that might be included in 2.0 are list comprehensions (a way to replace map, filter and reduce), augmented assignment (x += y and such), online help() facility for the interpreter, possibly some new library modules, and many enhancements to the current standard library.) However, because of the issues between CNRI and BeOpen, it's completely unclear when Python 2.0 will be released. (Or, indeed, when CNRI's Python 1.6 will be released.) If you need the unicode support now, I'd suggest grabbing the CVS tree and see how it suits your needs. If it doesn't, give people here some feedback, so they can fix the problems or suggest ways to work around it. There are likely to be some changes to unicode (the functionality of '\x' and '\u' for instance) but the code is pretty solid as it is. Hope that helps ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Mon Jul 17 16:13:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 17 Jul 2000 10:13:52 -0400 Subject: [Python-Dev] SourceForge down? In-Reply-To: <39730BE3.B1A83A59@schneider-kamp.de> Message-ID: [Peter Schneider-Kamp] > Since yesterday evening I cannot get to the Python pages at > SourceForge. That is sometimes I cannot even log in to > SourceForge. Other times it just takes minutes to load > a page. > > Do you experience something similar? Or is it just me? Was true for me too all day, via the web interface. cmdline CVS worked fine, though. Couldn't get at patches. Off to CA for a week! If anyone wants to make progress on the patches assigned to me, be my guest ; from tim_one@email.msn.com on Mon, Jul 17, 2000 at 10:13:52AM -0400 References: <39730BE3.B1A83A59@schneider-kamp.de> Message-ID: <20000717163829.L7340@xs4all.nl> On Mon, Jul 17, 2000 at 10:13:52AM -0400, Tim Peters wrote: > Off to CA for a week! If anyone wants to make progress on the patches > assigned to me, be my guest myself (at least temporarily) off them!). I would take you off the patches, but I doubt anyone else would pick them up anyway ;) Some need an executive decision, I think, like the EXTENDED_ARG patch (which isn't assigned to you, yet) and the array.pop/count/etc patch. Some just need some discussion, and there isn't likely to be a lot of decision-making-discussion while almost all of PythonLabs and undoubtly the most of python-dev are at OSCON. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From peter at schneider-kamp.de Mon Jul 17 18:59:25 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 17 Jul 2000 16:59:25 +0000 Subject: [Python-Dev] SourceForge down? References: <39730BE3.B1A83A59@schneider-kamp.de> <20000717163829.L7340@xs4all.nl> Message-ID: <39733B6D.E4B83607@schneider-kamp.de> Thomas Wouters wrote: > > I would take you off the patches, but I doubt anyone else would pick them up > anyway ;) Some need an executive decision, I think, like the EXTENDED_ARG > patch (which isn't assigned to you, yet) and the array.pop/count/etc patch. And the {l,r}just with pad character patch (which isn't assigned to Tim either). > Some just need some discussion, and there isn't likely to be a lot of > decision-making-discussion while almost all of PythonLabs and undoubtly the > most of python-dev are at OSCON. Not if we want to keep our heads <0.99 wink>. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul at prescod.net Mon Jul 17 17:56:51 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 10:56:51 -0500 Subject: [Python-Dev] Will Python die? References: <003f01bfeff3$26ac9840$770da8c0@bbs> Message-ID: <39732CC3.4E1620C5@prescod.net> Python cannot die while its license permits anyone to improve it and there are still thousands of users. If Python were in any danger, there are dozens of people who could take over its advancement, including its current maintainer, Guido, at his new job! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Mon Jul 17 18:17:55 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 11:17:55 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> Message-ID: <397331B3.E12E9F31@prescod.net> Jeremy Hylton wrote: > > Paul, > > You created a nondist subdirectory in the nondist tree. I don't think > this is what you intended. Yeah, I know. Working in the middle of the night. I tried to remove it immediately but obviously didn't succeed. If its still there, maybe someone can enlighten me on how to dump it. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Mon Jul 17 18:44:01 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 18:44:01 +0200 Subject: [Python-Dev] if/else and macros References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> <20000717025756.G29590@lyra.org> Message-ID: <009501bff00e$3d3bc980$f2a6b5d4@hagrid> greg wrote: > > The result is smaller source, smaller code, a smaller inner loop, > > faster decoding, and less discussion on this list. > > Can't just out of the loop. One of the possible results of the error is to > ignore it and continue. Or to insert a particular character and continue. of course -- if you decide not to break the loop, just jump back in. I just fixed the UTF8 decoder: before: source: 5108 lines object size: 173,151 bytes after: source: 5106 lines object size: 171,630 bytes just give me four more months ;-) From ping at lfw.org Mon Jul 17 18:48:50 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 17 Jul 2000 09:48:50 -0700 (PDT) Subject: [Python-Dev] htmldoc.py + inspect.py In-Reply-To: <3972F786.42FA2BE1@lemburg.com> Message-ID: On Mon, 17 Jul 2000, M.-A. Lemburg wrote: > > But what I particularly like is the inspect.py module. That > would make a great addition to the standard lib ! Yes, i consider inspect.py pretty much done, and hoped it would be considered for the standard library. I proposed it a little while ago (http://www.python.org/pipermail/python-dev/2000-May/011031.html); but it was set aside during the feature freeze. If we are in a position to consider it again now, then yes, i'd like to suggest it for the standard library. > Note to Ping: your files are missing a clear license notice. I thought we didn't have to add the contribution release form anymore because that was for CNRI? Anyway, i added a comment. Is it sufficient? # I, Ka-Ping Yee, the author of this contribution, hereby grant to anyone and # everyone a nonexclusive, irrevocable, royalty-free, worldwide license to # reproduce, distribute, perform and/or display publicly, prepare derivative # versions, and otherwise use this contribution as part of the Python software # and its related documentation, or any derivative versions thereof, at no cost # to anyone, and to authorize others to do so. -- ?!ng From bwarsaw at beopen.com Mon Jul 17 19:16:22 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 13:16:22 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> Message-ID: <14707.16230.872435.656875@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Yeah, I know. Working in the middle of the night. I tried to PP> remove it immediately but obviously didn't succeed. If its PP> still there, maybe someone can enlighten me on how to dump it. You can't. Somebody with access to the repository will have to remove it, but even then, if someone else has already done and update and gotten the new dir, it'll mess up their working directories. Best to just leave it empty and let "cvs up -P" prune it out. -Barry From ping at lfw.org Mon Jul 17 19:31:21 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 17 Jul 2000 10:31:21 -0700 (PDT) Subject: [Python-Dev] Checked in... In-Reply-To: <3972E333.363CD227@prescod.net> Message-ID: On Mon, 17 Jul 2000, Paul Prescod wrote: > Ka-Ping Yee wrote: > > My plan was to complete htmldoc.py and try to get in into the > > distribution so that anyone could browse documentation on the > > standard library. > > +1 Yay. :) > > It would include an option to start a little > > webserver with a one-line command so that doc pages could be > > automatically generated on your own modules as you work on them. > > +0 I'd like Python to come packaged in such a way that people can easily deploy it in an organization along with whatever stuff they develop. So being able to very easily generate and see docs on their own modules, integrated with the view of docs for the rest of the standard library, would be a nice thing. It makes a Python environment easier to support. > > The next step in the plan was to provide text output so you > > could ask about modules from the shell prompt (like a "man" > > command specific to Python) and a function call you could use > > from inside the interpreter to get quick help as well. > > Not sure how to interpret this. If it depends on the aforementioned web > server, I'm -1. If it calls the htmldoc code directly, I'm +1. Did you mean you wanted it to generate HTML and then use htmllib, like you did, to turn it into text? I hadn't thought of that. The way i imagined it, it wouldn't depend on htmldoc or the web server at all. It would call inspect.py to get its info and just format some text on its own. Before you posted onlineHelp (great work, by the way!), i was thinking of calling it "pydoc", and envisioning something like: >>> import pydoc # or have site.py take care of this >>> pydoc.doc(urllib) ---- module urllib: Open an arbitrary URL. See the following document for more info on URLs: "Names and Addresses, URIs, URLs, URNs, URCs", at http://www.w3.org/pub/WWW/Addressing/Overview.html . . . ---- functions: urlopen(url, data=None) urlretrieve(url, filename=None, reporthook=Nne) . . . ---- classes: class URLopener: Class to open URLs. . . . etc. and also the same output from the shell command % pydoc urllib ---- module urllib: Open an arbitrary URL. See the following document for more info on URLs: "Names and Addresses, URIs, URLs, URNs, URCs", at http://www.w3.org/pub/WWW/Addressing/Overview.html . . . etc. This is basically identical to how you were describing the onlinehelp/help commands. I didn't think of using the external (TeX/HTML) documentation though... that's a clever idea. So: - use doc pages only? - use internal info only? - separate scripts for each? - use both? - use doc pages if installed, then fall back to internal info? One other note: how about leaving the job of listing the text to to an external app like "less"/"more", as determined by the PAGER environment variable, allowing customization? The code we use to figure out what program to run should eventually move into launch.textviewer. Perhaps this would then provide interactive apps (e.g. IDLE) the opportunity to simply replace (or hook into) launch.textviewer. > I'd love > to have the interpreter build on your docstring-formatting heuristics > and that docstring-language plugin feature we discussed to allow people > to experiment with semi-structured docstring formats. Sure. Not a high priority for me, but once we have the module, it's easy to extend and experiment. -- ?!ng From peter at schneider-kamp.de Mon Jul 17 21:45:44 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 17 Jul 2000 19:45:44 +0000 Subject: [Python-Dev] Will Python die? References: <003f01bfeff3$26ac9840$770da8c0@bbs> <39732CC3.4E1620C5@prescod.net> Message-ID: <39736268.306B8DF0@schneider-kamp.de> Paul Prescod wrote: > > Python cannot die while its license permits anyone to improve it and > there are still thousands of users. If Python were in any danger, there > are dozens of people who could take over its advancement, including its > current maintainer, Guido, at his new job! Tim once (0.9-winking-ly) mentioned the possibility of voting with the "keyboard by grabbing the Python source and making your own release". I don't wanna do this on my own (and get zapped from a lightning bolt thrown by the powers that are), but what would be the pros and cons of an inofficial (maybe 1.8?) alpha-in-between-release? I think the CVS tree is in a relative stable state, so if this is going to take another 1 1/2 months, this might be a good time. just-thinking-and-winking-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mal at lemburg.com Mon Jul 17 19:46:01 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 19:46:01 +0200 Subject: [Python-Dev] htmldoc.py + inspect.py References: Message-ID: <39734659.16D327D9@lemburg.com> Ka-Ping Yee wrote: > > On Mon, 17 Jul 2000, M.-A. Lemburg wrote: > > > > But what I particularly like is the inspect.py module. That > > would make a great addition to the standard lib ! > > Yes, i consider inspect.py pretty much done, and hoped it would be > considered for the standard library. I proposed it a little while ago > (http://www.python.org/pipermail/python-dev/2000-May/011031.html); > but it was set aside during the feature freeze. > > If we are in a position to consider it again now, then yes, i'd like > to suggest it for the standard library. Don't know if we are in such a position, but it's worth putting on the list of candidates. Perhaps you should simply put up a patch to SF which includes the module -- this will give it some more exposure and assure that the idea is not lost. > > Note to Ping: your files are missing a clear license notice. > > I thought we didn't have to add the contribution release form > anymore because that was for CNRI? Sure, but there may be others who would like to use it, right ;-) As long as there's no license on a file, you bascially cannot legally copy it without first getting the authors permission. > Anyway, i added a comment. Is it sufficient? > > # I, Ka-Ping Yee, the author of this contribution, hereby grant to anyone and > # everyone a nonexclusive, irrevocable, royalty-free, worldwide license to > # reproduce, distribute, perform and/or display publicly, prepare derivative > # versions, and otherwise use this contribution as part of the Python software > # and its related documentation, or any derivative versions thereof, at no cost > # to anyone, and to authorize others to do so. This only gives the right to use the module in case it becomes part of the standard lib :-( I usually put the old Python license into the files (with changed names of course). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping at lfw.org Mon Jul 17 20:01:58 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 17 Jul 2000 11:01:58 -0700 (PDT) Subject: [Python-Dev] htmldoc.py + inspect.py In-Reply-To: <39734659.16D327D9@lemburg.com> Message-ID: On Mon, 17 Jul 2000, M.-A. Lemburg wrote: > This only gives the right to use the module in case it becomes > part of the standard lib :-( Fixed. # I, Ka-Ping Yee, the author of this contribution, hereby grant to anyone and # everyone a nonexclusive, irrevocable, royalty-free, worldwide license to # reproduce, distribute, perform and/or display publicly, prepare derivative # versions, and otherwise use this contribution in any fashion, or any # derivative versions thereof, at no cost to anyone, and to authorize others # to do so. This software is provided "as is", with NO WARRANTY WHATSOEVER, # not even a warranty of merchantability or fitness for any particular purpose. Geez. Is that enough words yet? All i wanted to say was "go play". :) -- ?!ng From thomas at xs4all.net Mon Jul 17 20:01:16 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 20:01:16 +0200 Subject: [Python-Dev] 'shadowing' builtins Message-ID: <20000717200116.P7340@xs4all.nl> This is probably the wrong time, given that most of y'all are likely on their way to OSCON ;) But the perl-hugging hippy colleague of mine that is currently at OSCON gave (as in 'handed') me this idea on shadowing builtins. He decided to go to David Beazly's python introduction, and he was suprised at how you can do 'None = 4'. And when I explained it's harmless (because it's local, not global) he was suprised it didn't generate a warning. And, well, why doesn't it generate a warning ? Only with an, uhm, '-w' option or so, of course, or perhaps add it to the '-t' option. It would be also a compile-time-check. It might require a seperate lookup table (haven't looked at it at all, yet) that duplicates the 'builtin' namespace, but I'd think it's worth it. Or is this an old and already-shot-down idea ? :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Mon Jul 17 20:04:19 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 20:04:19 +0200 Subject: [Python-Dev] if/else and macros References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> <20000717025756.G29590@lyra.org> <009501bff00e$3d3bc980$f2a6b5d4@hagrid> Message-ID: <39734AA3.7B33EE44@lemburg.com> Fredrik Lundh wrote: > > greg wrote: > > > The result is smaller source, smaller code, a smaller inner loop, > > > faster decoding, and less discussion on this list. > > > > Can't just out of the loop. One of the possible results of the error is to > > ignore it and continue. Or to insert a particular character and continue. > > of course -- if you decide not to break the loop, just > jump back in. This is getting silly, really ;-) Jumping out of loops is ok, but jumping back in is not: you can never know whether the optimizer rearranges the loop code, so jumping *into* loop constructs is not going to be portable. I'll remove the macro completely and also fix the UTF16 codec which has the same continue problem. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Mon Jul 17 20:04:22 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 13:04:22 -0500 Subject: [Python-Dev] Checked in... References: Message-ID: <39734AA5.C6ACA757@prescod.net> Ka-Ping Yee wrote: > > ... > > I'd like Python to come packaged in such a way that people can > easily deploy it in an organization along with whatever stuff > they develop. So being able to very easily generate and see docs > on their own modules, integrated with the view of docs for the > rest of the standard library, would be a nice thing. It makes a > Python environment easier to support. Agreed. I'm just not sure if it requires a webserver. You could set up a makefile to recognize when an HTML doc is out of sync with its Python. > The way i imagined it, it wouldn't depend on htmldoc or the web > server at all. It would call inspect.py to get its info and just > format some text on its own. I didn't know about the clean separation of htmldoc and inspect when I wrote that. You're right, it should call inspect directly. > This is basically identical to how you were describing the > onlinehelp/help commands. I didn't think of using the external > (TeX/HTML) documentation though... that's a clever idea. So: > > - use doc pages only? That's not doable unless there is a process to get docstrings into doc pages -- which is a great idea but probably some ways away. > - use internal info only? Where do I get information on statements and "topics" (like slicing, as a topic). > - separate scripts for each? Maybe internally. Ideally not at the user interface layer. > - use doc pages if installed, then fall back to internal info? My model, which you may or may not have noticed yet, is to use docstrings for objects that have docstrings, but the docstrings can point to HTML documentation in the circumstance where the canonical doc is maintained in HTML. In that case, I magically go to the HTML, rather than showing the reference. My personal feeling is that over time a lot of the library documentation should move inline for ease of maintenance and reduction of duplication. But that won't happen until we integrate inspect.py and latex2html. I have some ideas about that too. It's the opposite of the current scheme. We should put pointers from the LaTeX into the modules. A preprocessor would use inspect.py to generate a combined LaTeX that merges inline (LaTeX) and out-of-line (docstring) information. Then we start moving bits of the documentation into docstrings a little at a time. Anything that uses LaTeX features that are "funky" can stay in LaTeX until we invent a structured docstring syntax (whenever). > One other note: how about leaving the job of listing the text to > to an external app like "less"/"more", as determined by the PAGER > environment variable, allowing customization? The code we use to > figure out what program to run should eventually move into > launch.textviewer. I'm happy to do this on platforms that support it. I'm somewhat nervous about popen on non-Unix systems...maybe I should write a text file and then launch the pager on that. > Perhaps this would then provide interactive apps (e.g. IDLE) the > opportunity to simply replace (or hook into) launch.textviewer. Good idea. One tricky issue is what format to use, though. troff/man is great for Unix TTY, HTML is great for GUIs and raw text is the lowest common denominiator. Do I want to get into n*m translations? Maybe, maybe not. Or maybe HTML is the lowest common denominator and Unix TTY users should use lynx? -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Mon Jul 17 20:18:44 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 13:18:44 -0500 Subject: [Python-Dev] 'shadowing' builtins References: <20000717200116.P7340@xs4all.nl> Message-ID: <39734E04.C7D29873@prescod.net> Thomas Wouters wrote: > > ... > > He decided to go to David Beazly's python introduction, and he was suprised > at how you can do 'None = 4'. And when I explained it's harmless (because > it's local, not global) he was suprised it didn't generate a warning. And, > well, why doesn't it generate a warning ? Only with an, uhm, '-w' option or > so, of course, or perhaps add it to the '-t' option. It would be also a > compile-time-check. It might require a seperate lookup table (haven't looked > at it at all, yet) that duplicates the 'builtin' namespace, but I'd think > it's worth it. A few thoughts: * None, map and other such long-term, ancient built-ins should not be directly overridable. I don't think we need a warning mode. Just outlaw it. We can do this with a semantic check in the compiler. * Those with a good reason to shadow them would do it by assignment to the module's dict or __builtins__. The "feature" would still be there if you need it, but it would be syntactically distinct. Or maybe we need to disallow it entirely to allow optimizers to attack this important special case. * Python badly needs a warning infrastructure. If I had time, that would be my first PEP. I'd rather the former tightening up was not hostage to a warning infrastructure that nobody gets around to implementing, though. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Mon Jul 17 20:21:25 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 13:21:25 -0500 Subject: [Python-Dev] Will Python die? References: <003f01bfeff3$26ac9840$770da8c0@bbs> <39732CC3.4E1620C5@prescod.net> <39736268.306B8DF0@schneider-kamp.de> Message-ID: <39734EA5.BBF96453@prescod.net> Peter Schneider-Kamp wrote: > > ... > > Tim once (0.9-winking-ly) mentioned the possibility of voting with the > "keyboard by grabbing the Python source and making your own release". As long as Tim and Guido are thinking about this possibility, I don't want to waste my brain cells considering it. I don't have as much information as they do and I'm only a little bit smarter than them anyhow. :) Seriously, I don't know enough about the licensing issues. I don't know exactly what CNRI "owns" and what we need from them to proceed. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Mon Jul 17 20:23:34 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 13:23:34 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> Message-ID: <39734F26.5799F13D@prescod.net> "Barry A. Warsaw" wrote: > > ... > > You can't. Gah. That sucks. > Somebody with access to the repository will have to remove > it, You mean an SF employee? > but even then, if someone else has already done and update and > gotten the new dir, it'll mess up their working directories. Best to > just leave it empty and let "cvs up -P" prune it out. Not in the long run. It's just messy. There's a mistake I won't make again (this week). -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Mon Jul 17 20:44:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 20:44:25 +0200 Subject: [Python-Dev] if/else and macros References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> <20000717025756.G29590@lyra.org> <009501bff00e$3d3bc980$f2a6b5d4@hagrid> <39734AA3.7B33EE44@lemburg.com> Message-ID: <003101bff01f$193c5520$f2a6b5d4@hagrid> mal wrote: > This is getting silly, really ;-) indeed. > Jumping out of loops is ok, but jumping back in is not: you can > never know whether the optimizer rearranges the loop code, so > jumping *into* loop constructs is not going to be portable. sorry, but that's bullshit. if the optimizer cannot figure out where basic blocks start and end, it's broken beyond repair. quoting the ANSI C rationale: "The Committee considered proposals for forbidding a goto into a block from outside, since such a restriction would make possible much easier flow optimization and would avoid the whole issue of initializing auto storage (see ?3.1.2.4). The Committee rejected such a ban out of fear of invalidating working code (however un- disciplined) and out of concern for those producing machine- generated C." From bwarsaw at beopen.com Mon Jul 17 20:54:11 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 14:54:11 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> Message-ID: <14707.22099.762232.325117@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: >> You can't. PP> Gah. That sucks. Welcome to CVS. What did Greg Wilson say at IPC8? Paraphrasing: CVS is the worst tool everybody uses. :) >> Somebody with access to the repository will have to remove it, PP> You mean an SF employee? Yup, you need to make an admin request to do anything with the repository, like remove directories, move files, or clear locks. >> but even then, if someone else has already done and update and >> gotten the new dir, it'll mess up their working directories. >> Best to just leave it empty and let "cvs up -P" prune it out. PP> Not in the long run. It's just messy. PP> There's a mistake I won't make again (this week). Been there, done that. :) -Barry From bwarsaw at beopen.com Mon Jul 17 21:06:13 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 15:06:13 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration Message-ID: <14707.22821.945571.314619@anthem.concentric.net> I've made a final pass through PEP 201, Parallel Iteration. For those of you without easy access to the CVS tree, I'm including it below. You can also access it through the web at http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/python/nondist/peps/pep-0201.txt?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=python High bit: Guido strongly prefers zip() as the name of the built-in. All the suggestions so far have pluses and minuses, and in the absence of a clear winner, he'd just as soon go with the Haskell name. I agree. Please see the new reference implementation, which includes a __len__() method, and the discussion of the rejected elaborations. There's still the open issue of what zip(sequence_a) should return. I'd like to reach closure on this sometime soon after the guys get back from California. -Barry -------------------- snip snip -------------------- PEP: 201 Title: Parallel Iteration Version: $Revision: 1.2 $ Owner: bwarsaw at beopen.com (Barry A. Warsaw) Python-Version: 2.0 Status: Draft Introduction This PEP describes the `parallel iteration' proposal for Python 2.0, previously known as `parallel for loops'. This PEP tracks the status and ownership of this feature, slated for introduction in Python 2.0. It contains a description of the feature and outlines changes necessary to support the feature. This PEP summarizes discussions held in mailing list forums, and provides URLs for further information, where appropriate. The CVS revision history of this file contains the definitive historical record. Standard For-Loops Motivation for this feature has its roots in a concept described as `parallel for loops'. A standard for-loop in Python iterates over every element in the sequence until the sequence is exhausted. A `break' statement inside the loop suite causes an explicit loop exit. For-loops also have else: clauses which get executed when the loop exits normally (i.e. not by execution of a break). For-loops can iterate over built-in types such as lists and tuples, but they can also iterate over instance types that conform to an informal sequence protocol. This protocol states that the instance should implement the __getitem__() method, expecting a monotonically increasing index starting at 0, and this method should raise an IndexError when the sequence is exhausted. This protocol is currently undocumented -- a defect in Python's documentation hopefully soon corrected. For-loops are described in the Python language reference manual[1]. An example for-loop: >>> for i in (1, 2, 3): print i ... 1 2 3 In this example, the variable `i' is called the `target', and is assigned the next element of the list, each time through the loop. Parallel For-Loops Parallel for-loops are non-nested iterations over two or more sequences, such that at each pass through the loop, one element from each sequence is taken to compose the target. This behavior can already be accomplished in Python through the use of the map() built-in function: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> for i in map(None, a, b): print i ... (1, 4) (2, 5) (3, 6) Here, map() returns a list of N-tuples, where N is the number of sequences in map()'s argument list (after the initial `None'). Each tuple is constructed of the i-th elements from each of the argument lists, specifically in this example: >>> map(None, a, b) [(1, 4), (2, 5), (3, 6)] The for-loop simply iterates over this list as normal. While the map() idiom is a common one in Python, it has several disadvantages: - It is non-obvious to programmers without a functional programming background. - The use of the magic `None' first argument is non-obvious. - It has arbitrary, often unintended, and inflexible semantics when the lists are not of the same length: the shorter sequences are padded with `None'. >>> c = (4, 5, 6, 7) >>> map(None, a, c) [(1, 4), (2, 5), (3, 6), (None, 7)] For these reasons, several proposals were floated in the Python 2.0 beta time frame for providing a better spelling of parallel for-loops. The initial proposals centered around syntactic changes to the for statement, but conflicts and problems with the syntax were unresolvable, especially when parallel for-loops were combined with another proposed feature called `list comprehensions' (see pep-0202.txt). The Proposed Solution The proposed solution is to introduce a new built-in sequence generator function, available in the __builtin__ module. This function is to be called `zip' and has the following signature: zip(seqa, [seqb, [...]], [pad=]) zip() takes one or more sequences and weaves their elements together, just as map(None, ...) does with sequences of equal length. The optional keyword argument `pad', if supplied, is a value used to pad all shorter sequences to the length of the longest sequence. If `pad' is omitted, then weaving stops when the shortest sequence is exhausted. It is not possible to pad short lists with different pad values, nor will zip() ever raise an exception with lists of different lengths. To accomplish either behavior, the sequences must be checked and processed before the call to zip(). Lazy Execution For performance purposes, zip() does not construct the list of tuples immediately. Instead it instantiates an object that implements a __getitem__() method and conforms to the informal for-loop protocol. This method constructs the individual tuples on demand. Examples Here are some examples, based on the reference implementation below. >>> a = (1, 2, 3, 4) >>> b = (5, 6, 7, 8) >>> c = (9, 10, 11) >>> d = (12, 13) >>> zip(a, b) [(1, 5), (2, 6), (3, 7), (4, 8)] >>> zip(a, d) [(1, 12), (2, 13)] >>> zip(a, d, pad=0) [(1, 12), (2, 13), (3, 0), (4, 0)] >>> zip(a, d, pid=0) Traceback (most recent call last): File "", line 1, in ? File "/usr/tmp/python-iKAOxR", line 11, in zip TypeError: unexpected keyword arguments >>> zip(a, b, c, d) [(1, 5, 9, 12), (2, 6, 10, 13)] >>> zip(a, b, c, d, pad=None) [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)] >>> map(None, a, b, c, d) [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)] Reference Implementation Here is a reference implementation, in Python of the zip() built-in function and helper class. These would ultimately be replaced by equivalent C code. class _Zipper: def __init__(self, args, kws): # Defaults self.__padgiven = 0 if kws.has_key('pad'): self.__padgiven = 1 self.__pad = kws['pad'] del kws['pad'] # Assert no unknown arguments are left if kws: raise TypeError('unexpected keyword arguments') self.__sequences = args self.__seqlen = len(args) def __getitem__(self, i): ret = [] exhausted = 0 for s in self.__sequences: try: ret.append(s[i]) except IndexError: if not self.__padgiven: raise exhausted = exhausted + 1 if exhausted == self.__seqlen: raise ret.append(self.__pad) return tuple(ret) def __len__(self): # If we're padding, then len is the length of the longest sequence, # otherwise it's the length of the shortest sequence. if not self.__padgiven: shortest = -1 for s in self.__sequences: slen = len(s) if shortest < 0 or slen < shortest: shortest = slen return shortest longest = 0 for s in self.__sequences: slen = len(s) if slen > longest: longest = slen return longest def __str__(self): ret = [] i = 0 while 1: try: ret.append(self[i]) except IndexError: break i = i + 1 return str(ret) __repr__ = __str__ def zip(*args, **kws): return _Zipper(args, kws) Rejected Elaborations Some people have suggested that the user be able to specify the type of the inner and outer containers for the zipped sequence. This would be specified by additional keyword arguments to zip(), named `inner' and `outer'. This elaboration is rejected for several reasons. First, there really is no outer container, even though there appears to be an outer list container the example above. This is simply an artifact of the repr() of the zipped object. User code can do its own looping over the zipped object via __getitem__(), and build any type of outer container for the fully evaluated, concrete sequence. For example, to build a zipped object with lists as an outer container, use >>> list(zip(sequence_a, sequence_b, sequence_c)) for tuple outer container, use >>> tuple(zip(sequence_a, sequence_b, sequence_c)) This type of construction will usually not be necessary though, since it is expected that zipped objects will most often appear in for-loops. Second, allowing the user to specify the inner container introduces needless complexity and arbitrary decisions. You might imagine that instead of the default tuple inner container, the user could prefer a list, or a dictionary, or instances of some sequence-like class. One problem is the API. Should the argument to `inner' be a type or a template object? For flexibility, the argument should probably be a type object (i.e. TupleType, ListType, DictType), or a class. For classes, the implementation could just pass the zip element to the constructor. But what about built-in types that don't have constructors? They would have to be special-cased in the implementation (i.e. what is the constructor for TupleType? The tuple() built-in). Another problem that arises is for zips greater than length two. Say you had three sequences and you wanted the inner type to be a dictionary. What would the semantics of the following be? >>> zip(sequence_a, sequence_b, sequence_c, inner=DictType) Would the key be (element_a, element_b) and the value be element_c, or would the key be element_a and the value be (element_b, element_c)? Or should an exception be thrown? This suggests that the specification of the inner container type is needless complexity. It isn't likely that the inner container will need to be specified very often, and it is easy to roll your own should you need it. Tuples are chosen for the inner container type due to their (slight) memory footprint and performance advantages. Open Issues - What should "zip(a)" do? Given a = (1, 2, 3); zip(a) three outcomes are possible. 1) Returns [(1,), (2,), (3,)] Pros: no special casing in the implementation or in user code, and is more consistent with the description of it's semantics. Cons: this isn't what map(None, a) would return, and may be counter to user expectations. 2) Returns [1, 2, 3] Pros: consistency with map(None, a), and simpler code for for-loops, e.g. for i in zip(a): instead of for (i,) in zip(a): Cons: too much complexity and special casing for what should be a relatively rare usage pattern. 3) Raises TypeError Pros: None Cons: needless restriction Current scoring seems to generally favor outcome 1. - The name of the built-in `zip' may cause some initial confusion with the zip compression algorithm. Other suggestions include (but are not limited to!): marry, weave, parallel, lace, braid, interlace, permute, furl, tuples, lists, stitch, collate, knit, plait, and with. All have disadvantages, and there is no clear unanimous choice, therefore the decision was made to go with `zip' because the same functionality is available in other languages (e.g. Haskell) under the name `zip'[2]. References [1] http://www.python.org/doc/devel/ref/for.html [2] http://www.haskell.org/onlinereport/standard-prelude.html#$vzip TBD: URL to python-dev archives Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: From thomas at xs4all.net Mon Jul 17 21:38:04 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 21:38:04 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net>; from bwarsaw@beopen.com on Mon, Jul 17, 2000 at 03:06:13PM -0400 References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <20000717213804.Q7340@xs4all.nl> On Mon, Jul 17, 2000 at 03:06:13PM -0400, Barry A. Warsaw wrote: > There's still the open issue of what zip(sequence_a) should return. I'd vote for [(a,), (b,), (c,)], that is, still return tuples. It's consistent with the use in the case of multiple sequences. We already have map(None, sequence_a) that does it the non-obvious way ;) In the map case it's easily explained: it turns the sequence into a list. In the case of zip(), that isn't necessary (and not the point of the function, anyway.) I-still-wish-it-were-marry()-ly y'rs, ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Mon Jul 17 21:39:14 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 21:39:14 +0200 Subject: [Python-Dev] Will Python die? In-Reply-To: <39734EA5.BBF96453@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 01:21:25PM -0500 References: <003f01bfeff3$26ac9840$770da8c0@bbs> <39732CC3.4E1620C5@prescod.net> <39736268.306B8DF0@schneider-kamp.de> <39734EA5.BBF96453@prescod.net> Message-ID: <20000717213914.R7340@xs4all.nl> On Mon, Jul 17, 2000 at 01:21:25PM -0500, Paul Prescod wrote: > Peter Schneider-Kamp wrote: > I don't have as much information as they do and I'm only a little bit > smarter than them anyhow. :) Yeah, I'm only a little bit smarter than Guido divided by Tim, too. Or-is-that-Guido-minus-Tim-ly y'rs, ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Mon Jul 17 22:04:54 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 22:04:54 +0200 Subject: [Python-Dev] if/else and macros References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> <20000717025756.G29590@lyra.org> <009501bff00e$3d3bc980$f2a6b5d4@hagrid> <39734AA3.7B33EE44@lemburg.com> <003101bff01f$193c5520$f2a6b5d4@hagrid> Message-ID: <007201bff02a$46f02860$f2a6b5d4@hagrid> I wrote: > sorry, but that's bullshit. or in slightly fewer words: "goto != longjmp" From Vladimir.Marangozov at inrialpes.fr Mon Jul 17 22:15:40 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 17 Jul 2000 22:15:40 +0200 (CEST) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net> from "Barry A. Warsaw" at Jul 17, 2000 03:06:13 PM Message-ID: <200007172015.WAA25033@python.inrialpes.fr> Barry A. Warsaw wrote: > > > I've made a final pass through PEP 201, Parallel Iteration. Nice! I think that a broader audience needs to read this. Why not asking for reactions on c.l.py? > High bit: Guido strongly prefers zip() as the name of the built-in. > All the suggestions so far have pluses and minuses, and in the absence > of a clear winner, he'd just as soon go with the Haskell name. I > agree. I don't feel comfortable with it. Period. You might want to see what http://www.dict.org has to say about it. Looking at the examples for this builtin function, and without thinking too much about the name, I'd call it - fold(). zip-gun'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gmcm at hypernet.com Mon Jul 17 22:22:45 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Mon, 17 Jul 2000 16:22:45 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <1248257113-63674673@hypernet.com> Barry A. Warsaw wrote: [PEP 201, Parallel Iteration] > Open Issues > > - What should "zip(a)" do? Given > > a = (1, 2, 3); zip(a) > > three outcomes are possible. How about a fourth: zip(a) is the same as zip(a, []) ? Look at it this way: what should zip(a, pad=None) return? Obviously: [(1, None), (2, None), (3, None)] So what should zip(a) return? Don't special case it, just return []. With only one arg, zip has clearly lost meaning. That is, it's clearly a degenerate case, and not worth a bunch of special casing. although-we-do-special-case-Barry-ly y'rs - Gordon From esr at thyrsus.com Mon Jul 17 23:01:15 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Mon, 17 Jul 2000 17:01:15 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net> References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <20000717170114.B7624@thyrsus.com> Barry A. Warsaw : > High bit: Guido strongly prefers zip() as the name of the built-in. > All the suggestions so far have pluses and minuses, and in the absence > of a clear winner, he'd just as soon go with the Haskell name. I agree. Grumble. Not too happy with the conclusion, but can't argue with the logic. I somewhat reluctantly agree. -- Eric S. Raymond Gun Control: The theory that a woman found dead in an alley, raped and strangled with her panty hose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound. -- L. Neil Smith From skip at mojam.com Mon Jul 17 21:58:11 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 17 Jul 2000 14:58:11 -0500 (CDT) Subject: [Python-Dev] 'shadowing' builtins In-Reply-To: <20000717200116.P7340@xs4all.nl> References: <20000717200116.P7340@xs4all.nl> Message-ID: <14707.25939.889361.800800@beluga.mojam.com> Thomas> He decided to go to David Beazly's python introduction, and he Thomas> was suprised at how you can do 'None = 4'. And when I explained Thomas> it's harmless (because it's local, not global) he was suprised Thomas> it didn't generate a warning. And, well, why doesn't it generate Thomas> a warning? I wrote a script some time ago to print these warnings. Search http://www.musi-cal.com/~skip/python/ for the string "hiding builtin names"... Skip From peter at schneider-kamp.de Tue Jul 18 01:39:31 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 17 Jul 2000 23:39:31 +0000 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <200007172015.WAA25033@python.inrialpes.fr> Message-ID: <39739933.DFFAAFD9@schneider-kamp.de> Vladimir Marangozov wrote: > > I don't feel comfortable with it. Period. > You might want to see what http://www.dict.org has to say about it. > > Looking at the examples for this builtin function, and without thinking > too much about the name, I'd call it - fold(). Please, don't!!! As far as I can remember, fold is the "reduce of the functional languages". At least it is that in Haskell. Here's a quote from the Journal of Functional Programming (July 1999): "In functional programming, fold is a standard operator that encapsulates a simple pattern of recursion for processing lists." BTW: I still like zip() and as someone said: dir and del have the same problem/not-a-problem Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Vladimir.Marangozov at inrialpes.fr Tue Jul 18 00:05:06 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 18 Jul 2000 00:05:06 +0200 (CEST) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <39739933.DFFAAFD9@schneider-kamp.de> from "Peter Schneider-Kamp" at Jul 17, 2000 11:39:31 PM Message-ID: <200007172205.AAA25258@python.inrialpes.fr> Peter Schneider-Kamp wrote: > > [me] > > Looking at the examples for this builtin function, and without thinking > > too much about the name, I'd call it - fold(). > > Please, don't!!! As far as I can remember, fold is the "reduce of the > functional languages". At least it is that in Haskell. > > Here's a quote from the Journal of Functional Programming (July 1999): > "In functional programming, fold is a standard operator that > encapsulates a simple pattern of recursion for processing lists." Okay, but weren't we paying less attention to historical facts in language design? Guido regrets map() that slipped through, for instance. My opinion is a newbie opinion. I just can't believe that we can't find a more intuitive name for this function! From peter at schneider-kamp.de Tue Jul 18 02:11:03 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 00:11:03 +0000 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <3973A097.B85D6775@schneider-kamp.de> "Barry A. Warsaw" wrote: > > I've made a final pass through PEP 201, Parallel Iteration. For those > of you without easy access to the CVS tree, I'm including it below. > You can also access it through the web at Great work. It's a pleasure to read. > High bit: Guido strongly prefers zip() as the name of the built-in. > All the suggestions so far have pluses and minuses, and in the absence > of a clear winner, he'd just as soon go with the Haskell name. I > agree. I agree (giving +1 would be blasphemy, right?). One important remark: What about unzip()? Shouldn't there be the reverse function? One example (which I really wrote not so long ago in an ANN context): def normalize(seq): # scale to values in 0..1 return map(lambda x, max=max(seq), min=min(seq): (x-min)/(max-min), seq) # from file with: x1 y1 z1\nx2 y2 z2\n etc. data = [[1.0, 2.0, 3.0], [-1.0, 1.0, -1.0], [-1.0, -2.0, -3.0], [2.0, 3.0, 1.0]] # zip related data fields, normalize that field, unzip data = unzip(map(normalize,zip(data))) > Please see the new reference implementation, which includes a > __len__() method, and the discussion of the rejected elaborations. > There's still the open issue of what zip(sequence_a) should return. I think zip([1, 2, 3]) should give ((1), (2), (3)). My reasons? 1) It feels right to me. 2) It is the way Lisp (or Scheme, don't remember) deals with it. [Haskell's zip-unzip is limited to two lists] By the way, yet another example for unzip(): mylist = [(1,), (2,), (3,)] What looks better? a) newlist = map(lambda x:x[0], mylist) b) newlist = unzip(mylist) advocating-unzip-as-an-overridable-builtin-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From effbot at telia.com Tue Jul 18 00:24:21 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 18 Jul 2000 00:24:21 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <200007172205.AAA25258@python.inrialpes.fr> Message-ID: <006f01bff03d$c1f20c00$f2a6b5d4@hagrid> > I just can't believe that we can't find a more intuitive name > for this function! ...and I cannot believe that you're trying to reopen this discussion once again :-( (or is this a trick by Guido to make sure we don't do any real work while he's on the conference? ;-) "After consultation with Guido, zip() is chosen as the name of this built-in." -- seen on the python-checkins list. From peter at schneider-kamp.de Tue Jul 18 02:21:16 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 00:21:16 +0000 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <200007172205.AAA25258@python.inrialpes.fr> Message-ID: <3973A2FC.2CD26F44@schneider-kamp.de> Vladimir Marangozov wrote: > > What's the problem with `folding' sequences element-wise in Python? > > What's the problem with `zipping' sequences element-wise in Python? > > Which one of the 2 questions above makes more sense? The first. But it gives me the wrong impression: fold the list [1, 2, 3]: \ / f(1,f(2,f(3))) for some function f fold the lists [1, 2, 3] and [4, 5, 6] elementwise: \ / f(f(3,f(6)),f(f(2,f(5)),f(1,f(4)))) for some function f I'd just wonder what to fold the lists with. Even if my judgement is biased by my Haskell organ, I still think that taking the name of an important list operator from different languages for a completely different list operation is way worse than using the name of a file compression utility as a list operator. just-my-cents(0.02)-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Vladimir.Marangozov at inrialpes.fr Tue Jul 18 00:38:32 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 18 Jul 2000 00:38:32 +0200 (CEST) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <006f01bff03d$c1f20c00$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 18, 2000 12:24:21 AM Message-ID: <200007172238.AAA25374@python.inrialpes.fr> Fredrik Lundh wrote: > > > I just can't believe that we can't find a more intuitive name > > for this function! > > ...and I cannot believe that you're trying to reopen this discussion > once again :-( :-) Sorry, but it was discussed during a short period of time (despite the huge number of posts in that time slice) and I wasn't really available for participating seriously in the discussion. So now I'm taking the opportunity to read the PEP without much external pression, as well as to say what I think and to think what I say. Note that I suggested Barry to sumbit this PEP to a broader audience for collection external opinions on all aspects of the PEP. If there are several people with CS background that don't feel good with this name, there's something wrong with it. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gmcm at hypernet.com Tue Jul 18 00:44:44 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Mon, 17 Jul 2000 18:44:44 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <200007172238.AAA25374@python.inrialpes.fr> References: <006f01bff03d$c1f20c00$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 18, 2000 12:24:21 AM Message-ID: <1248248594-64187019@hypernet.com> Vladimir.Marangozov wrote: > Fredrik Lundh wrote: > > > > > I just can't believe that we can't find a more intuitive name > > > for this function! > > > > ...and I cannot believe that you're trying to reopen this > > discussion once again :-( > > :-) Sorry, but it was discussed during a short period of time > (despite the huge number of posts in that time slice) and I > wasn't really available for participating seriously in the > discussion. So now I'm taking the opportunity to read the PEP > without much external pression, as well as to say what I think > and to think what I say. > > Note that I suggested Barry to sumbit this PEP to a broader > audience for collection external opinions on all aspects of the > PEP. If there are several people with CS background that don't > feel good with this name, there's something wrong with it. To me, "zip" in the context of computers means compress. But it's a stupid name for compress. And one look at the args makes it obvious it's not a compress. So I expect that your typical newbie will do one, and only one "Huh??? Oh - zip as in zipper, not zip as in PKZIP" and never have to post again. wishfully-y'rs - Gordon From Vladimir.Marangozov at inrialpes.fr Tue Jul 18 01:11:47 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 18 Jul 2000 01:11:47 +0200 (CEST) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248248594-64187019@hypernet.com> from "Gordon McMillan" at Jul 17, 2000 06:44:44 PM Message-ID: <200007172311.BAA25445@python.inrialpes.fr> Gordon McMillan wrote: > > To me, "zip" in the context of computers means compress. > But it's a stupid name for compress. And one look at the args > makes it obvious it's not a compress. So I expect that your > typical newbie will do one, and only one "Huh??? Oh - zip as > in zipper, not zip as in PKZIP" and never have to post again. Right. > > wishfully-y'rs My wish is to add fold() as one of the suggested names in the PEP, then let this PEP spend some time in c.l.py. Give people a chance to catch up, please. That's how the PEP process is intended to work. The name hasn't been cast in stone. It's in the PEP, not in CVS. end-of-story-ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul at prescod.net Tue Jul 18 01:10:53 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 18:10:53 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <3973927D.D2D37DE0@prescod.net> I would say that you should make the ambiguous single-param case illegal. For one of the examples you say: > for i in zip(a): Why would you ever do that??? The only way that would make sense to me if zip([[1],[2]])==zip([1],[2]), which I would dislike. Use zip(*[[1],[2]]) instead. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Tue Jul 18 01:11:17 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 18:11:17 -0500 Subject: [Python-Dev] Votes Message-ID: <39739295.4AEB5195@prescod.net> I'm going to wait for four positive votes or one from Guido before I take the following action cd nondist cvs add sandbox cd sandbox cvs add onlinehelp.py cvs add inspect.py -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From peter at schneider-kamp.de Tue Jul 18 03:19:33 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 01:19:33 +0000 Subject: [Python-Dev] Votes References: <39739295.4AEB5195@prescod.net> Message-ID: <3973B0A5.AE63E45F@schneider-kamp.de> Paul Prescod wrote: > > I'm going to wait for four positive votes or one from Guido before I > take the following action Don't know if my one counts, but you can have it anyway: +1 on nondist/sandbox Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From akuchlin at mems-exchange.org Tue Jul 18 01:57:32 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 17 Jul 2000 19:57:32 -0400 (EDT) Subject: [Python-Dev] Python-dev summary: Jul 1-15 Message-ID: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Note: this is an experiment in whether I can make a useful, interesting, somewhat coherent summary of python-dev activity. Things I'm not sure of: * Accuracy. I skipped past some threads such as the list comprehensions one, and may be unaware of a resolution. * How many links are needed? Should I try to link to several posts per thread, SF patches, etc.? That makes more work for me, but also makes the summary more useful. * Bi-weekly OK? I think it's a reasonable frequency. I'll check my e-mail tomorrow; if no one screams loudly, I'll post it. (My connectivity is poor enough that I don't want to do major editing on it, or be able to respond to many e-mails in detail.) ================== Python-dev summary, July 1-15, 2000: The 2-week period started with reactions to Guido's June 30 announcement that the 2.0b1 release would be delayed for an indefinite period due to legal wrangling. This gave everyone a second chance to contribute more patches while waiting for the release, and the activity level remained high. Two dominant issues for this time period were Unicode-related issues, and list comprehensions. The Unicode issues, as usual, turned on the question of where strings and Unicode strings should be interchangeable. A discussion in the thread "Minidom and Unicode" considered whether it's legal to return a Unicode string from __repr__. The consensus was that it should be legal, despite fears of breaking code that expects only an 8-bit string, and the CVS tree was patched accordingly. Python's interpreter mode uses repr() to display the results of expressions, and it will convert Unicode strings to ASCII, using the unicode-escape encoding. The following code, typed into the interpreter, will print 'abc\u3456'. class C: def __repr__(self): return u'abc\u3456' print repr( C() ) Hashing also presented a problem. As M.-A. Lemburg explained in http://www.python.org/pipermail/python-dev/2000-July/012150.html: The problem comes from the fact that the default encoding can be changed to a locale specific value (site.py does the lookup for you), e.g. given you have defined LANG to be us_en, Python will default to Latin-1 as default encoding. This results in '???' == u'???', but hash('???') != hash(u'???'), which is in conflict with the general rule about objects having the same hash value if they compare equal. The resolution seems to be simply removing the ability to change the default encoding and adopt ASCII as the fixed default; if you want to use other encodings, you must specify them explicitly. List comprehensions originated as a patch from Greg Ewing that's now being kept up-to-date versus the CVS tree by Skip Montanaro. Originally they weren't on the roadmap for 1.6, but with the greater version number jump to 2.0, GvR is more willing to incorporate larger changes. List comprehensions provide a more concise way to create lists in situations where map() and filter() would currently be used. To take some examples from the patched-for-list-comphrensions version of the Python Tutorial: >>> spcs = [" Apple", " Banana ", "Coco nut "] >>> print [s.strip() for s in spcs] ['Apple', 'Banana', 'Coco nut'] >>> vec1 = [2, 4, 6] >>> vec2 = [4, 3, -9] >>> print [x*y for x in vec1 for y in vec2] [8, 6, -18, 16, 12, -36, 24, 18, -54] A lengthy subthread about intuitiveness sprang from the second example, and from a patch from Thomas Wouters that implements parallel 'for' loops. The patch makes "for x in [1,2]; y in ['a','b']" cause x,y to be 1,'a', and then 2,'b'. The thread circulated around whether people would expect this syntax to produce the Cartesian product of the two lists: (1,'a'), (1, 'b'), (2, 'a'), (2, 'b'). No clear answer or final syntax has emerged yet, though Greg Wilson has been trying out syntaxes on Python-unaware people and asking them what they'd expect: http://www.python.org/pipermail/python-dev/2000-July/012810.html It was also suggested to add a new built-in function for parallel 'for' loops instead of new syntax, so you would code 'for x,y in zip([1,2], ['a','b']):'. A lengthy and very dull discussion ensued about the name 'zip': should it be 'plait', 'knit', 'parallel', or even 'marry'? Some new procedures for Python development were set out: Tim Peters wrote some guidelines for using SourceForge's patch manager: http://www.python.org/pipermail/python-dev/2000-July/012635.html Barry Warsaw announced a series of Python Extension Proposal (PEP) documents, which play the role of RFCs for significant changes to Python: http://www.python.org/pipermail/python-dev/2000-July/013059.html Mark Hammond gave the first glimpse of a fourth Python implementation: "This new compiler could be compared, conceptually, with JPython - it is a completely new implementation of Python. It has a compiler that generates native Windows .DLL/.EXE files. It uses a runtime that consists of a few thousand lines of C# (C-Sharp) code. The Python programs can be debugged at the source level with Visual Studio 7, as well as stand-alone debuggers for this environment. Python can sub-class VB or C# classes, and vice-versa." http://www.python.org/pipermail/python-dev/2000-July/013019.html Other bits: Skip Montanaro experimented with using code coverage tools to measure the effectiveness of the Python test suite, by seeing which lines of code (both C and Python) that are exercised by the tests. A summary of the results is at: http://www.musi-cal.com/~skip/python/Python/dist/src/summary.html Skip also added support to the readline module for saving and loading command histories. ESR suggested adding a standard lexer to the core, and /F suggested an extension to regular expressions that would make them more useful for tokenizing: http://www.python.org/pipermail/python-dev/2000-July/012032.html CVS problems were briefly a distraction, with dangling locks preventing commits to the Lib/ and Modules/ subdirectories for a few days. Despite such glitches, the move to SourceForge has accelerated development overall, as more people can make check-ins and review them. For some time Tim Peters has been suggesting removing the Py_PROTO macro and making the sources require ANSI C; mostly this is because the macro breaks the C cross-referencing support in Tim's editor. :) The ball finally started rolling on this, and snowballed into a massive set of patches to use ANSI C prototypes everywhere. Fred Drake and Peter Schneider-Kamp rose to the occasion and edited the prototypes in dozens of files. Jeremy Hylton pointed out that "Tuple, List, String, and Dict have a Py*_Size method. The abstract object interface uses PySequence_Length. This is inconsistent and hard to remember," and suggested that *_Size be made the standard form, and *_Length will be deprecated. Just before the cutoff date, Paul Prescod proposed a new help() function for interactive use, and began implementing it: http://www.python.org/pipermail/python-dev/2000-July/013346.html Huaiyu Zhu suggested adding new operators to support matrix math: http://www.python.org/pipermail/python-dev/2000-July/013364.html A slew of minor patches and bugfixes were made, too. Some highlights: * Ka-Ping Yee improved the syntax error messages. * ESR made various changes to ConfigParser.py * Some of Sam Rushing's patches from Medusa were applied to add os.setreuid() and friends; AMK is working on adding the poll() system call. * /F was his usual "patching machine" self, integrating PythonWin's win32popen function so that os.popen will now work correctly on Windows as well as Unix, writing PyErr_SafeFormat() to prevent buffer overflows, and proposing some patches to reduce the 600K size of the Unicode character database. Some fun posts came up during the near-endless zip()/plait()/whatever naming thread: http://www.python.org/pipermail/python-dev/2000-July/012920.html: "BTW: How comes, that Ping very often invents or introduces very clever ideas and concepts, but also very often chooses unclear names for them? Is it just me not being a native english speaker?" "I don't know. Perhaps my florx bignal zupkin isn't very moognacious?" -- Peter Funk and Ka-Ping Yee, 12 Jul 2000 http://www.python.org/pipermail/python-dev/2000-July/013050.html, while everyone was trying to think up alternative names for zip(): "Let me throw one more out, in honor of our fearless leader's recent life change: marry(). Usually only done in pairs, and with two big sequences, I get the image of a big Unification Church event :)" "Isn't it somewhat of a political statement to allow marriages of three or more items? I always presumed that this function was n-ary, like map." -- Barry Warsaw and Paul Prescod From bwarsaw at beopen.com Tue Jul 18 02:04:02 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 20:04:02 -0400 (EDT) Subject: [Python-Dev] Votes References: <39739295.4AEB5195@prescod.net> Message-ID: <14707.40690.705582.995282@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> I'm going to wait for four positive votes or one from Guido PP> before I take the following action | cd nondist | cvs add sandbox | cd sandbox | cvs add onlinehelp.py | cvs add inspect.py +1 And since I'm the only one left minding the store, while everyone else goes off galavanting in sunny California, you can read that as +1000 :) nothing-like-a-dose-of-al-haig-to-make-you-feel-important-til-the-boss-comes- home-ly y'rs, -Barry From gstein at lyra.org Tue Jul 18 02:13:17 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 17:13:17 -0700 Subject: [Python-Dev] htmldoc.py + inspect.py In-Reply-To: ; from ping@lfw.org on Mon, Jul 17, 2000 at 11:01:58AM -0700 References: <39734659.16D327D9@lemburg.com> Message-ID: <20000717171317.P29590@lyra.org> On Mon, Jul 17, 2000 at 11:01:58AM -0700, Ka-Ping Yee wrote: > On Mon, 17 Jul 2000, M.-A. Lemburg wrote: > > This only gives the right to use the module in case it becomes > > part of the standard lib :-( > > Fixed. > > # I, Ka-Ping Yee, the author of this contribution, hereby grant to anyone and > # everyone a nonexclusive, irrevocable, royalty-free, worldwide license to > # reproduce, distribute, perform and/or display publicly, prepare derivative > # versions, and otherwise use this contribution in any fashion, or any > # derivative versions thereof, at no cost to anyone, and to authorize others > # to do so. This software is provided "as is", with NO WARRANTY WHATSOEVER, > # not even a warranty of merchantability or fitness for any particular purpose. > > Geez. Is that enough words yet? All i wanted to say was "go play". :) Here is short for you: # Written by Ka-Ping Yee. Public Domain. No warranties. Can't get any easier than that. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jul 18 02:21:23 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 17:21:23 -0700 Subject: [Python-Dev] Votes In-Reply-To: <39739295.4AEB5195@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 06:11:17PM -0500 References: <39739295.4AEB5195@prescod.net> Message-ID: <20000717172123.Q29590@lyra.org> On Mon, Jul 17, 2000 at 06:11:17PM -0500, Paul Prescod wrote: > I'm going to wait for four positive votes or one from Guido before I > take the following action > > cd nondist > cvs add sandbox > cd sandbox > cvs add onlinehelp.py > cvs add inspect.py Considering that I suggested /nondist/sandbox/ it probably stands to reason that you had my +1 all along :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul at prescod.net Tue Jul 18 02:27:46 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 19:27:46 -0500 Subject: [Python-Dev] Python-dev summary: Jul 1-15 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: <3973A482.48023039@prescod.net> I like it. I don't see anything about range literals, though. Probably buried in the list comp. discussion. I can't remember anything else you might have missed off the top of my head. I liked the part where someone asked: "What causes these CVS locks?" and Tim replied: "Skip, apparently." Luckily you cut off before I get zapped with a lightening bolt for checking in inappropriately. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul at prescod.net Tue Jul 18 02:30:08 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 19:30:08 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> Message-ID: <3973A510.86D2AF54@prescod.net> "Barry A. Warsaw" wrote: > > >>>>> "PP" == Paul Prescod writes: > > >> You can't. > > PP> Gah. That sucks. > > Welcome to CVS. What did Greg Wilson say at IPC8? Paraphrasing: CVS > is the worst tool everybody uses. :) Okay, but it isn't entirely CVS' fault. Not *entirely*. Shouldn't out CVS space be writeable by one of us. Okay, that person could royally screw everything up but hey, that's the whole point of Unix, isn't it? -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From klm at digicool.com Tue Jul 18 02:40:33 2000 From: klm at digicool.com (Ken Manheimer) Date: Mon, 17 Jul 2000 20:40:33 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <3973A097.B85D6775@schneider-kamp.de> Message-ID: On Tue, 18 Jul 2000, Peter Schneider-Kamp wrote: > One important remark: > What about unzip()? Shouldn't there be the reverse function? > One example (which I really wrote not so long ago in an ANN context): Evan Simpson (a colleague here at digicool, who'd be a good addition to python-dev) noticed that unzip is unnecessary - zip is its own inverse. Since this is a worthwhile observation, i'll indulge a bit and present it in evan's terms - particularly noting a different packaging that i think is pretty cool, as methods on sequences. > From evan at digicool.com Mon Jul 17 20:17:30 2000 > Date: Mon, 17 Jul 2000 14:36:18 -0400 > From: Evan Simpson > To: Ken Manheimer > Subject: Next Braid > > How's this: > > ([1, 2, 3], ['a', 'b', 'c']).braid() == ((1, 'a'), (2, 'b'), (3, 'c')) > [[1, 2, 3], ['a', 'b', 'c']].braid() == [(1, 'a'), (2, 'b'), (3, 'c')] > > and > > [[1,2,3], ['a']].braid(None) == [(1, 'a'), (2, None), (3, None)] > > Also, notice that if 's' is a rectangular sequence of sequences, then for > all 'a' and 'b': > > s.braid()[a][b] == s[b][a] by definition, so > > s.braid().braid()[a][b] == s.braid()[b][a] == s[a][b] and therefore, > > braid is its own inverse, and we don't need unbraid. > > Cheers, > > Evan @ digicool & 4-am I can't do better than that, but i have one further elaboration i'd like to see. If the subject sequence already contains some elements, the result sequence is a copy of the originals with the new braided, whoops zipped elements appended - this way, braids can be cumulative. >>> [(1, 3), (2, 4)].braid(('a', 'b'), ('x', 'y')) [(1, 3, 'a', 'x'), (2, 4, 'b', 'y')] Anyway, we don't need an unzip/unbraid. ! Ken klm at digicool.com From klm at digicool.com Tue Jul 18 02:43:38 2000 From: klm at digicool.com (Ken Manheimer) Date: Mon, 17 Jul 2000 20:43:38 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: Message-ID: Whoops, i got my section wrong. Disregard the last part. On Mon, 17 Jul 2000, Ken Manheimer wrote: > On Tue, 18 Jul 2000, Peter Schneider-Kamp wrote: > > > One important remark: > > What about unzip()? Shouldn't there be the reverse function? > > One example (which I really wrote not so long ago in an ANN context): > > Evan Simpson (a colleague here at digicool, who'd be a good addition > to python-dev) noticed that unzip is unnecessary - zip is its own > inverse. Since this is a worthwhile observation, i'll indulge a bit > and present it in evan's terms - particularly noting a different > packaging that i think is pretty cool, as methods on sequences. > > > From evan at digicool.com Mon Jul 17 20:17:30 2000 > > Date: Mon, 17 Jul 2000 14:36:18 -0400 > > From: Evan Simpson > > To: Ken Manheimer > > Subject: Next Braid > > > > How's this: > > > > ([1, 2, 3], ['a', 'b', 'c']).braid() == ((1, 'a'), (2, 'b'), (3, 'c')) > > [[1, 2, 3], ['a', 'b', 'c']].braid() == [(1, 'a'), (2, 'b'), (3, 'c')] > > > > and > > > > [[1,2,3], ['a']].braid(None) == [(1, 'a'), (2, None), (3, None)] > > > > Also, notice that if 's' is a rectangular sequence of sequences, then for > > all 'a' and 'b': > > > > s.braid()[a][b] == s[b][a] by definition, so > > > > s.braid().braid()[a][b] == s.braid()[b][a] == s[a][b] and therefore, > > > > braid is its own inverse, and we don't need unbraid. > > > > Cheers, > > > > Evan @ digicool & 4-am > > I can't do better than that, but i have one further elaboration i'd > like to see. If the subject sequence already contains some elements, > the result sequence is a copy of the originals with the new braided, > whoops zipped elements appended - this way, braids can be cumulative. > > >>> [(1, 3), (2, 4)].braid(('a', 'b'), ('x', 'y')) > [(1, 3, 'a', 'x'), (2, 4, 'b', 'y')] > > Anyway, we don't need an unzip/unbraid. ! > > Ken > klm at digicool.com > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From mhammond at skippinet.com.au Tue Jul 18 04:16:51 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 17 Jul 2000 22:16:51 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <003f01bfefc6$64840540$f2a6b5d4@hagrid> Message-ID: [Fredrik] > I'm probably missing something here, but is there any reason > you cannot add this code to Py_InitModule4 instead: > > PyObject *m, *d, *v; > PyMethodDef *ml; > + if (!Py_IsInitialized()) > + Py_FatalError("Bad Python version"); /* Never returns */ Py_InitModule4() is inside Pythonxx.dll - so it _will_ be initialized. The point of putting this code inside the .pyd is that the .pyd will be calling the Py_IsInitialized() from Python15.dll - and this DLL has never been initialized. Putting it inside Py_InitModule4() will never trigger an error... Mark. From pingster at ilm.com Tue Jul 18 04:37:08 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Mon, 17 Jul 2000 19:37:08 -0700 (PDT) Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: On Mon, 17 Jul 2000, Andrew Kuchling wrote: > Note: this is an experiment in whether I can make a useful, > interesting, somewhat coherent summary of python-dev activity. Very nice job! Well done. Thanks for doing all the work! > * Accuracy. I skipped past some threads such as the list > comprehensions one, and may be unaware of a resolution. As Paul mentioned, there was some talk about range literals. There was some stuff about augmented assignment too, i believe? Thomas Wouters tried to summarize the list-comp, parallel-iteration, and range-literal threads, to which i responded with an alternative proposal. Huaiyu Zhu also presented a fairly complete list-comp proposal (though i think the syntax is not quite implementable). Eric suggested adding a cross-platform "browse" routine to urllib. Some discussion ensued; some names for a separate module were proposed including "webbrowser.py"; some people suggested using the "start" command on Windows instead; i suggested a "launch" module for launching other kinds of external applications as well as web browsers; i don't remember if any resolution was reached. Paul started a small thread on automatic coercion of any type to string. There was some discussion of rearranging newsgroup and mailing list traffic, choosing more distinct purposes for comp.lang.python and python-dev, etc. A suggestion to make string.atoi work for negative bases was politely but quickly squashed. There were random gripes about SourceForge. Moshe suggested a file-copy routine that accepted objects; Greg Stein checked it in. Paul raised the issue of bringing an XPath implementation into Python. Paul made a fairly detailed proposal for an online help mechanism (this happened on July 15 at the end of your time window; more discussion ensued). -- ?!ng "Smoking kills. If you're killed, you've lost a very important part of your life." -- Brooke Shields From gmcm at hypernet.com Tue Jul 18 04:38:37 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Mon, 17 Jul 2000 22:38:37 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: References: <003f01bfefc6$64840540$f2a6b5d4@hagrid> Message-ID: <1248234561-65031149@hypernet.com> Mark Hammond wrote: > [Fredrik] > > I'm probably missing something here, but is there any reason > > you cannot add this code to Py_InitModule4 instead: > > > > PyObject *m, *d, *v; > > PyMethodDef *ml; > > + if (!Py_IsInitialized()) > > + Py_FatalError("Bad Python version"); /* Never returns */ > > Py_InitModule4() is inside Pythonxx.dll - so it _will_ be > initialized. The point of putting this code inside the .pyd is > that the .pyd will be calling the Py_IsInitialized() from > Python15.dll - and this DLL has never been initialized. Putting > it inside Py_InitModule4() will never trigger an error... Florida sun getting to you? Or the teenage girls? Or just being in the wrong hemisphere (so all the blood rushes to your feet)? initXXX() (normally) calls Py_InitModule4, so it would be the one in whatever XXXmodule loaded. - Gordon From gmcm at hypernet.com Tue Jul 18 04:38:37 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Mon, 17 Jul 2000 22:38:37 -0400 Subject: [Python-Dev] Votes In-Reply-To: <14707.40690.705582.995282@anthem.concentric.net> Message-ID: <1248234559-65031252@hypernet.com> Barry A. Warsaw wrote: > +1 > > And since I'm the only one left minding the store, while everyone > else goes off galavanting in sunny California, you can read that > as +1000 :) > > nothing-like-a-dose-of-al-haig-to-make-you-feel-important-til-the > -boss-comes- home-ly y'rs, -Barry C'mon Barry, you didn't verb a single noun! - Gordon From mhammond at skippinet.com.au Tue Jul 18 04:42:49 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 17 Jul 2000 22:42:49 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <1248234561-65031149@hypernet.com> Message-ID: > Florida sun getting to you? Or the teenage girls? Or just being > in the wrong hemisphere (so all the blood rushes to your feet)? > > initXXX() (normally) calls Py_InitModule4, so it would be the > one in whatever XXXmodule loaded. Doh! All of the above - plus an unshakable belief that while on vacation I never need to check my facts before spouting off. But-fortunately-that-all-ends-tomorrow-ly, Mark. From bwarsaw at beopen.com Tue Jul 18 05:27:21 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 23:27:21 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> Message-ID: <14707.52889.135983.472187@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Okay, but it isn't entirely CVS' fault. Not PP> *entirely*. Shouldn't out CVS space be writeable by one of PP> us. Okay, that person could royally screw everything up but PP> hey, that's the whole point of Unix, isn't it? Yeah, but it's only necessary because CVS doesn't let you do those tasks through it's interface. Well, kind of a pointless argument because it probably won't change on SF any time soon, and who among us is actively hacking on CVS? :) -Barry From esr at thyrsus.com Tue Jul 18 06:06:44 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jul 2000 00:06:44 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: References: <3973A097.B85D6775@schneider-kamp.de> Message-ID: <20000718000644.A8911@thyrsus.com> Ken Manheimer : > > ([1, 2, 3], ['a', 'b', 'c']).braid() == ((1, 'a'), (2, 'b'), (3, 'c')) > > [[1, 2, 3], ['a', 'b', 'c']].braid() == [(1, 'a'), (2, 'b'), (3, 'c')] > > > > and > > > > [[1,2,3], ['a']].braid(None) == [(1, 'a'), (2, None), (3, None)] This is rather cool -- I especially like the implied feature of deriving the type of the result from the type of the outermost level of the object. I would be +1 on making zip/braid a sequence method rather than a function. -- Eric S. Raymond I don't like the idea that the police department seems bent on keeping a pool of unarmed victims available for the predations of the criminal class. -- David Mohler, 1989, on being denied a carry permit in NYC From gstein at lyra.org Tue Jul 18 05:55:50 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 20:55:50 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory In-Reply-To: <14707.52889.135983.472187@anthem.concentric.net>; from bwarsaw@beopen.com on Mon, Jul 17, 2000 at 11:27:21PM -0400 References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> <14707.52889.135983.472187@anthem.concentric.net> Message-ID: <20000717205550.Z29590@lyra.org> On Mon, Jul 17, 2000 at 11:27:21PM -0400, Barry A. Warsaw wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> Okay, but it isn't entirely CVS' fault. Not > PP> *entirely*. Shouldn't out CVS space be writeable by one of > PP> us. Okay, that person could royally screw everything up but > PP> hey, that's the whole point of Unix, isn't it? > > Yeah, but it's only necessary because CVS doesn't let you do those > tasks through it's interface. Well, kind of a pointless argument > because it probably won't change on SF any time soon, and who among us > is actively hacking on CVS? :) I'm actively involved with CVS's successor. Does that count? :-) -- Greg Stein, http://www.lyra.org/ From bwarsaw at beopen.com Tue Jul 18 05:56:42 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 23:56:42 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> <14707.52889.135983.472187@anthem.concentric.net> <20000717205550.Z29590@lyra.org> Message-ID: <14707.54650.959052.870977@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> I'm actively involved with CVS's successor. Does that count? GS> :-) Only if I get to play with it! From esr at thyrsus.com Tue Jul 18 06:15:51 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jul 2000 00:15:51 -0400 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: <20000718001551.C8911@thyrsus.com> Ka-Ping Yee : > Eric suggested adding a cross-platform "browse" routine to urllib. > Some discussion ensued; some names for a separate module were > proposed including "webbrowser.py"; some people suggested using > the "start" command on Windows instead; i suggested a "launch" > module for launching other kinds of external applications as well > as web browsers; i don't remember if any resolution was reached. Fred Drake coded up a new version after I critiqued the original. He and I agreed it was good, and we didn't see any -1s on adding it to the library. Fred, did you ever commit that sucker? -- Eric S. Raymond The possession of arms by the people is the ultimate warrant that government governs only with the consent of the governed. -- Jeff Snyder From paul at prescod.net Tue Jul 18 06:00:36 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 23:00:36 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> <14707.52889.135983.472187@anthem.concentric.net> Message-ID: <3973D664.747D3886@prescod.net> "Barry A. Warsaw" wrote: > > ... > > Yeah, but it's only necessary because CVS doesn't let you do those > tasks through it's interface. Well, kind of a pointless argument > because it probably won't change on SF any time soon, and who among us > is actively hacking on CVS? :) I mean CVS stores our information as a bunch of files on a hard disk. Those files use the Unix UGO security model. You are some one trusted (one or the other) should be in the PythonAdmins Unix group and you or that person should be able to physically change files in our directories using your shell account. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From gstein at lyra.org Tue Jul 18 06:17:17 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 21:17:17 -0700 Subject: [Python-Dev] CVS: python/nondist/nondist - New directory In-Reply-To: <3973D664.747D3886@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 11:00:36PM -0500 References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> <14707.52889.135983.472187@anthem.concentric.net> <3973D664.747D3886@prescod.net> Message-ID: <20000717211717.C29590@lyra.org> On Mon, Jul 17, 2000 at 11:00:36PM -0500, Paul Prescod wrote: > "Barry A. Warsaw" wrote: > > > > ... > > > > Yeah, but it's only necessary because CVS doesn't let you do those > > tasks through it's interface. Well, kind of a pointless argument > > because it probably won't change on SF any time soon, and who among us > > is actively hacking on CVS? :) > > I mean CVS stores our information as a bunch of files on a hard disk. > Those files use the Unix UGO security model. You are some one trusted > (one or the other) should be in the PythonAdmins Unix group and you or > that person should be able to physically change files in our directories > using your shell account. "should" != "current state of things" :-) The CVS repositories aren't opened up like that on SF, AFAIK. So yes, "should" is quite true, but that doesn't help us now :-( As Barry said... unless SF changes that policy, then we just deal with it. We could make an SF admin request to torch the nondist/nondist directory from the repository. Cheers, -g -- Greg Stein, http://www.lyra.org/ From moshez at math.huji.ac.il Tue Jul 18 07:54:15 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 08:54:15 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: On Mon, 17 Jul 2000, Barry A. Warsaw wrote: [On the builtin that resembles lambda *args: map(None, *args)] > High bit: Guido strongly prefers zip() as the name of the built-in. > All the suggestions so far have pluses and minuses, and in the absence > of a clear winner, he'd just as soon go with the Haskell name. I > agree. > > Please see the new reference implementation, which includes a > __len__() method, and the discussion of the rejected elaborations. > There's still the open issue of what zip(sequence_a) should return. I'm +1 on that. One thing that bugs me is that we're adding a builtin type. Why not stick with the Python implementation? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Tue Jul 18 08:11:58 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 08:11:58 +0200 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: <200007172357.TAA16970@newcnri.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Mon, Jul 17, 2000 at 07:57:32PM -0400 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: <20000718081158.T7340@xs4all.nl> On Mon, Jul 17, 2000 at 07:57:32PM -0400, Andrew Kuchling wrote: > List comprehensions originated as a patch from Greg Ewing that's now > being kept up-to-date versus the CVS tree by Skip Montanaro. > Originally they weren't on the roadmap for 1.6, but with the greater > version number jump to 2.0, GvR is more willing to incorporate larger > changes. It may be worth mentioning that augmented assignment is also being considered for 2.0, and possibly other operators (we still haven't heard from Guido on that, I believe, and there was at least one +1 from Eric.) Also, maybe the outcome of small CNRI/BeOpen thread would be nice to mention? CNRI says they will release python 1.6, and python 2.0 will probably (possibly ?) be released by BeOpen after that ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From klm at digicool.com Tue Jul 18 08:16:07 2000 From: klm at digicool.com (Ken Manheimer) Date: Tue, 18 Jul 2000 02:16:07 -0400 (EDT) Subject: [Python-Dev] pdbtrack.el - alt approach to emacs-based python debugging Message-ID: <14707.63015.14103.987843@korak.digicool.com> You emacs inhabitants out there may be interested in pdbtrack.el, a little alternative for source-file python debugging in emacs: http://www.zope.org/Wikis/klm/PDBTrack With pdbtrack, whenever you run pdb, emacs tracks (*) the current source file line, centered in another emacs window. It keys on the process output, cuing on the stack trace format and the pdb prompt, so it's pretty unlikely to misfire. That's all it does - it lacks a lot of GUD features, like putting highlighting glyphs on the current line, providing debugging commands from inside the source file buffer, etc. On the other hand, it's also very trim, code-lines-wise - a total of 122 lines, without any GUD connection, and that includes 59 lines that are only for working around a bug in mainline emacs' make-local-hook. (Incorporating the GUD-style features may not be too hard - since it touches the buffer where the debugging was started, as well as the source file buffers, it could set up the necessary state and bindings per session. But i'm not particularly driven to pursue that - tracking the current line in the source file seems to be most of what i need...) The fundamental difference between pdbtrack and GUD/pdb.el is that pdbtrack doesn't require you to launch the debugging session from a particular buffer - it tracks from any comint buffers where you run python. This fits the way i tend to use the debugger - generally, i do more-or-less elaborate interactions with my application *before* i go into the debugger, to set up the context and/or explore my way to the debugging start point. With GUD i have to start the session directly in the debugger. And then, when i finish a GUD session, (i believe) the context is lost. When debugging in a regular shell buffer (and the python-mode py-shell, etc), i drop back into python, wander around, and often launch back into the debugger, with the accumulated state. pdbtrack tracks wherever and whenver you're running pdb in emacs. (I posted more description yesterday to the python and the zope lists: http://www.python.org/pipermail/python-list/2000-July/108654.html ) If this proves to be of general interest and acceptance, i'd love to see it considered for inclusion with python-mode... Ken klm at digicool.com ((*) "whenever you run *pdb*, emacs *tracks*" - that's why i almost called it "zip":->) From thomas at xs4all.net Tue Jul 18 08:16:18 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 08:16:18 +0200 Subject: [Python-Dev] Votes In-Reply-To: <39739295.4AEB5195@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 06:11:17PM -0500 References: <39739295.4AEB5195@prescod.net> Message-ID: <20000718081618.U7340@xs4all.nl> On Mon, Jul 17, 2000 at 06:11:17PM -0500, Paul Prescod wrote: > I'm going to wait for four positive votes or one from Guido before I > take the following action > cd nondist > cvs add sandbox > cd sandbox > cvs add onlinehelp.py > cvs add inspect.py +1. There. You have it ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Tue Jul 18 08:31:52 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 09:31:52 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248257113-63674673@hypernet.com> Message-ID: (assume a = [1, 2, 3]) On Mon, 17 Jul 2000, Gordon McMillan wrote: > How about a fourth: zip(a) is the same as zip(a, []) ? Huh??????????????????? > Look at it this way: what should zip(a, pad=None) return? [(1,), (2,), (3,)], of course > Obviously: [(1, None), (2, None), (3, None)] Why? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Tue Jul 18 08:56:01 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 09:56:01 +0300 (IDT) Subject: [Python-Dev] Votes In-Reply-To: <39739295.4AEB5195@prescod.net> Message-ID: On Mon, 17 Jul 2000, Paul Prescod wrote: > I'm going to wait for four positive votes or one from Guido before I > take the following action > > cd nondist > cvs add sandbox > cd sandbox > cvs add onlinehelp.py > cvs add inspect.py Here's one -- +1 -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From mal at lemburg.com Tue Jul 18 09:48:04 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 18 Jul 2000 09:48:04 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration References: Message-ID: <39740BB3.C80C7CA8@lemburg.com> Moshe Zadka wrote: > > (assume a = [1, 2, 3]) > > On Mon, 17 Jul 2000, Gordon McMillan wrote: > > > How about a fourth: zip(a) is the same as zip(a, []) ? > > Huh??????????????????? I think he meant: zip((a,[])) > > Look at it this way: what should zip(a, pad=None) return? > > [(1,), (2,), (3,)], of course > > > Obviously: [(1, None), (2, None), (3, None)] > > Why? Good question ;-) Here's another one: why should zip() have this special case at all ? I mean, have you ever seen a zipper with only one part ? Ok, there is one-hand clapping, but I wouldn't consider this the normal mode of operation ;-) IMHO, all the special casing does is mask programming errors. And another one: zip() as defined is an operation which is -- in some respects -- the inverse of itself, yet the name does not carry this information. You can't zip a zipper twice. The mathematical operation behind it is called transposition (you view the sequence of sequences as matrix), so in that light the natural name would be transpose()... tranpose(transpose(matrix))) has the same structure as matrix itself. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Tue Jul 18 10:04:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 18 Jul 2000 10:04:05 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <003f01bfefc6$64840540$f2a6b5d4@hagrid> <1248234561-65031149@hypernet.com> Message-ID: <00cd01bff08e$c0849580$f2a6b5d4@hagrid> gordon wrote: > initXXX() (normally) calls Py_InitModule4, so it would be the > one in whatever XXXmodule loaded. exactly my point... so, would this work? Index: Python/modsupport.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/modsupport.c,v retrieving revision 2.48 diff -u -r2.48 modsupport.c --- Python/modsupport.c 2000/07/09 03:09:56 2.48 +++ Python/modsupport.c 2000/07/18 07:55:03 @@ -51,6 +51,8 @@ { PyObject *m, *d, *v; PyMethodDef *ml; + if (!Py_IsInitialized()) + Py_FatalError("Interpreter not initialized (version mismatch?)"); if (module_api_version != PYTHON_API_VERSION) fprintf(stderr, api_version_warning, name, PYTHON_API_VERSION, name, module_api_version); "Fatal Python error: Interpreter not initialized" might not be too helpful, but it's surely better than "PyThreadState_Get: no current thread"... From tim_one at email.msn.com Tue Jul 18 10:00:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 18 Jul 2000 04:00:18 -0400 Subject: [Python-Dev] Will Python die? In-Reply-To: <39736268.306B8DF0@schneider-kamp.de> Message-ID: [Peter Schneider-Kamp] > Tim once (0.9-winking-ly) mentioned the possibility of voting with the > "keyboard by grabbing the Python source and making your own release". > > I don't wanna do this on my own (and get zapped from a lightning bolt > thrown by the powers that are), but what would be the pros and cons > of an inofficial (maybe 1.8?) alpha-in-between-release? I don't see any pros at this time, although I'm typing on my laptop while sitting on the sidewalk in the dark in front of a Howard Johnson's with my hair dripping wet, so Guido can sleep in peace in the room we're sharing, and this after a hellish 12-hour trip to get to the God-forsaken State of California, so I'm not seeing many pros of any kind at the moment . The Python Consortium meeting is this Friday, and the license hassles are on the agenda. While not privy to all the details myself, I can't imagine that any side in this debate can afford to *allow* the impasse to continue longer than that. So I'd advise a bit more patience. I intend to stay all up night, listening for secrets Guido may spill in his sleep. the-con-is-making-a-confused-release-even-more-confused-ly y'rs - tim From mal at lemburg.com Tue Jul 18 10:07:24 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 18 Jul 2000 10:07:24 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <003f01bfefc6$64840540$f2a6b5d4@hagrid> <1248234561-65031149@hypernet.com> <00cd01bff08e$c0849580$f2a6b5d4@hagrid> Message-ID: <3974103C.AE2D2320@lemburg.com> Fredrik Lundh wrote: > > gordon wrote: > > initXXX() (normally) calls Py_InitModule4, so it would be the > > one in whatever XXXmodule loaded. > > exactly my point... > > so, would this work? Hmm, as I see it this patch would have to be in 1.5.2 to be of any use for the problem mentioned in the subject line: the 1.5 extension links against python15.dll and thus calls the Py_InitModule() of that DLL, not the one in python20.dll which would have the logic below. Anyway, it's a good start for future versions of Python. > Index: Python/modsupport.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Python/modsupport.c,v > retrieving revision 2.48 > diff -u -r2.48 modsupport.c > --- Python/modsupport.c 2000/07/09 03:09:56 2.48 > +++ Python/modsupport.c 2000/07/18 07:55:03 > @@ -51,6 +51,8 @@ > { > PyObject *m, *d, *v; > PyMethodDef *ml; > + if (!Py_IsInitialized()) > + Py_FatalError("Interpreter not initialized (version mismatch?)"); > if (module_api_version != PYTHON_API_VERSION) > fprintf(stderr, api_version_warning, > name, PYTHON_API_VERSION, name, module_api_version); > > "Fatal Python error: Interpreter not initialized" might not be too helpful, > but it's surely better than "PyThreadState_Get: no current thread"... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Tue Jul 18 10:09:59 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 11:09:59 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory In-Reply-To: <14707.54650.959052.870977@anthem.concentric.net> Message-ID: On Mon, 17 Jul 2000, Barry A. Warsaw wrote: > > >>>>> "GS" == Greg Stein writes: > > GS> I'm actively involved with CVS's successor. Does that count? > > GS> :-) > > Only if I get to play with it! Yeah, Greg, what's up with davlib.py? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gstein at lyra.org Tue Jul 18 10:38:25 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 01:38:25 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 18, 2000 at 11:09:59AM +0300 References: <14707.54650.959052.870977@anthem.concentric.net> Message-ID: <20000718013825.F29590@lyra.org> On Tue, Jul 18, 2000 at 11:09:59AM +0300, Moshe Zadka wrote: > On Mon, 17 Jul 2000, Barry A. Warsaw wrote: > > >>>>> "GS" == Greg Stein writes: > > > > GS> I'm actively involved with CVS's successor. Does that count? > > > > GS> :-) > > > > Only if I get to play with it! > > Yeah, Greg, what's up with davlib.py? Euh. What about it? It is moving along fine. I wouldn't call it stable enough for inclusion into the standard distro, though. What is there is fine, but I think more APIs will be needed to pick up stuff from the new/upcoming DAV extension specs. Cheers, -g p.s. http://subversion.tigris.org/ is the CVS successor I'm talking about -- Greg Stein, http://www.lyra.org/ From peter at schneider-kamp.de Tue Jul 18 12:37:25 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 10:37:25 +0000 Subject: [Python-Dev] Will Python die? References: Message-ID: <39743365.73CC983E@schneider-kamp.de> Tim Peters wrote: > > I don't see any pros at this time, although I'm typing on my laptop while > sitting on the sidewalk in the dark in front of a Howard Johnson's with my > hair dripping wet, so Guido can sleep in peace in the room we're sharing, > and this after a hellish 12-hour trip to get to the God-forsaken State of > California, so I'm not seeing many pros of any kind at the moment . > The Python Consortium meeting is this Friday, and the license hassles are on > the agenda. While not privy to all the details myself, I can't imagine that > any side in this debate can afford to *allow* the impasse to continue longer > than that. Okay, that sounds better than nothing. Meanwhile the question "what happened to 1.6?" starts popping up in c.l.py more often. > So I'd advise a bit more patience. I intend to stay all up night, listening > for secrets Guido may spill in his sleep. Be sure to write a secret transcript of *everything*. We might use it the next time we want to add some special syntax to Python being-more-patient-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From moshez at math.huji.ac.il Tue Jul 18 11:02:30 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 12:02:30 +0300 (IDT) Subject: [Python-Dev] Will Python die? In-Reply-To: Message-ID: On Tue, 18 Jul 2000, Tim Peters wrote: > [Peter Schneider-Kamp] > > Tim once (0.9-winking-ly) mentioned the possibility of voting with the > > "keyboard by grabbing the Python source and making your own release". > > > > I don't wanna do this on my own (and get zapped from a lightning bolt > > thrown by the powers that are), but what would be the pros and cons > > of an inofficial (maybe 1.8?) alpha-in-between-release? > > I don't see any pros at this time I agree with Tim -- your 1.8 would face backwards- and forwards- compatabilitiy issues CVS versions do not have to face. >, although I'm typing on my laptop while > sitting on the sidewalk in the dark in front of a Howard Johnson's with my > hair dripping wet, so Guido can sleep in peace in the room we're sharing, > and this after a hellish 12-hour trip to get to the God-forsaken State of > California, so I'm not seeing many pros of any kind at the moment . Sounds like loads of fun....next you should get into the room and wake up Guido. That should be even more fun. > So I'd advise a bit more patience. I intend to stay all up night, listening > for secrets Guido may spill in his sleep. I don't think you should. there-are-some-things-bots-were-not-meant-to-know-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From peter at schneider-kamp.de Tue Jul 18 13:23:38 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 11:23:38 +0000 Subject: [Python-Dev] PEP 201 - Parallel iteration References: Message-ID: <39743E3A.249212D5@schneider-kamp.de> Ken Manheimer wrote: > > Evan Simpson (a colleague here at digicool, who'd be a good addition > to python-dev) noticed that unzip is unnecessary - zip is its own > inverse. Since this is a worthwhile observation, i'll indulge a bit > and present it in evan's terms - particularly noting a different > packaging that i think is pretty cool, as methods on sequences. Yeah, but this is only true if we let zip() be a sequence method (or a function taking a sequence): for x,y in [[1, 2, 3], [4, 5, 6]].zip(): for x,y in zip([[1, 2, 3], [4, 5, 6]]): for x,y in zip([1, 2, 3], [4, 5, 6]): To be fair I'll do second one: a = [1, 2, 3] b = [4, 5, 6] c = [7, 8, 9] for x,y,z in [a, b, c].zip(): for x,y,z in zip([a, b, c]): for x,y,z in zip(a, b, c): I still think the third form is more explicit, but I am +0 on making zip() a sequence method. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From fredrik at pythonware.com Tue Jul 18 11:46:27 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 18 Jul 2000 11:46:27 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <39743E3A.249212D5@schneider-kamp.de> Message-ID: <011701bff09d$0bc5b020$0900a8c0@SPIFF> peter wrote: > I still think the third form is more explicit, but I am > +0 on making zip() a sequence method. Remember the "string join" debate? There is no sequence base class in Python (it's an informal inter- face, not a type), so where would you put that method? As specified, "zip" has a *single* implementation which takes any number of objects implementing the sequence interface, and return an object implementing the same interface. Can it be much simpler? -1 on a method. Python is moving towards more genericness (if you accept an integer/sequence/string, you should be able to deal with any kind of integer/sequence/string). Adding a method would be a move in the opposite direction. From jack at oratrix.nl Tue Jul 18 11:54:26 2000 From: jack at oratrix.nl (Jack Jansen) Date: Tue, 18 Jul 2000 11:54:26 +0200 Subject: [Python-Dev] ascii default encoding In-Reply-To: Message by "Fredrik Lundh" , Mon, 17 Jul 2000 00:35:56 +0200 , <008501bfef76$362902e0$f2a6b5d4@hagrid> Message-ID: <20000718095427.0F3CE37186D@snelboot.oratrix.nl> > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but > > the \312 causes problems because it can't be converted from/to unicode > > as long as the default encoding is ascii... > > on windows and unix boxes, the default locale is "posix" (aka "C"), > which in practice means "plain ascii". the only way to end up with > non-ascii characters in whitespace/uppercase/lowercase/etc is to > explicitly change the locale (by calling locale.setlocale). On the Mac, under CodeWarrior, the default locale (and, actually, the only locale) is "C", and it uses the mac-roman charset, so including the upper 128 characters. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From thomas at xs4all.net Tue Jul 18 11:59:47 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 11:59:47 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <39743E3A.249212D5@schneider-kamp.de>; from peter@schneider-kamp.de on Tue, Jul 18, 2000 at 11:23:38AM +0000 References: <39743E3A.249212D5@schneider-kamp.de> Message-ID: <20000718115947.Y7340@xs4all.nl> On Tue, Jul 18, 2000 at 11:23:38AM +0000, Peter Schneider-Kamp wrote: > Ken Manheimer wrote: > > Evan Simpson (a colleague here at digicool, who'd be a good addition > > to python-dev) noticed that unzip is unnecessary - zip is its own > > inverse. Since this is a worthwhile observation, i'll indulge a bit > > and present it in evan's terms - particularly noting a different > > packaging that i think is pretty cool, as methods on sequences. > for x,y,z in [a, b, c].zip(): -1. Completely counter-intuitive, in my opinion... It would be nice if having a list of lists to marry() is a common operation, but I doubt it is. Having to create one just for the sake of zip() looks silly to me. > for x,y,z in zip([a, b, c]): -1. What's the point ? What's the difference ? What would 'zip([a,b,c],[d,e,f])' do ? > for x,y,z in zip(a, b, c): Still +0 on this. I still prefer the altered syntax 'for' loop :-) And marry() over zip(). But I can live with this. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Tue Jul 18 12:18:31 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 12:18:31 +0200 Subject: [Python-Dev] PEP 204 - Range Literals Message-ID: <20000718121831.A7340@xs4all.nl> I've attached the first draft of PEP 204, Range Literals, which I just uploaded to CVS as well. If anyone finds time to review it, or the proposed implementation (patch #100902 on SourceForge) please do. I'm not sure what to do with the patch... Guido said as much as 'apply it'(*), but I doubt anyone really looked at it yet ;) I wrote this using 'joe', which is still my favorite editor, because despite many, many minutes of effort, xemacs simply refused to do what I wanted it to do. How do you 're-flow' a paragraph, for instance, or enable word wrapping, or better yet: word wrapping with autoindentation ? If anyone has a quick-and-dirty howto on [x]emacs, feel free to share ;) (* In http://www.python.org/pipermail/python-dev/2000-July/013234.html) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pep-0204.txt URL: From fredrik at pythonware.com Tue Jul 18 12:21:54 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 18 Jul 2000 12:21:54 +0200 Subject: [Python-Dev] ascii default encoding References: <20000718095427.0F3CE37186D@snelboot.oratrix.nl> Message-ID: <013501bff0a1$ff35cca0$0900a8c0@SPIFF> jack wrote: > On the Mac, under CodeWarrior, the default locale (and, actually, the only > locale) is "C", and it uses the mac-roman charset, so including the upper 128 > characters. I could have sworn that the "C" locale only included characters in the ASCII range [1], but a more careful reading of the specification indicates that the behaviour is only *defined* for characters in the ASCII range... two alternatives: -- limit the string constants to the portable range (0..127). if you want more characters, you have to explicitly call locale.setlocale(..., "C"). -- leave it as it is. this means that code that does things like "if char in string.whitespace" will break if char is unicode, and you're running on a mac. on second thought, it's probably better to just fix mixed string com- parisions... (so that instead of throwing an exception, unichr(202) will simply be != chr(202)...) 1) not quite true: the portable character set only lists all characters in the ASCII character set, it doesn't define what code points they should use. From thomas at xs4all.net Tue Jul 18 13:00:59 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 13:00:59 +0200 Subject: [Python-Dev] Patches Message-ID: <20000718130059.B7340@xs4all.nl> Now that everyone of importance is off to sunny California, how about we put some of the patches that have been idling on the SF PM to the vote ? If Barry objects we can always organize some gigs for him away from the 'office' ;) I'd personally like to hear some votes/opinions on the range literal patch, but it seems to me there are others that only require some voting and second opinions: - Add 'isatty(fd)' to posixmodule. Do Macs and Windows machines have an isatty() function that makes sense to include ? - Better error message with UnboundLocalError Patch looks okay to me, and Tim already said he liked the idea. - arraymodule: adding count, extend, index, pop, remove I believe there was some discussion about this before, don't know the outcome. - new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Probably needs Guido and/or Tim decreeing whether the change is worth it - safe version of PyErr_Format +0 on that, but what do I know. Don't know if it's actually safe ;) - Optional pad character for rjust, ljust Definately +1, but I have a nagging feeling there is a better way to do it: Why wasn't this implemented before ? What are people using instead of string.rjust(string, padchar) ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm at hypernet.com Tue Jul 18 14:26:02 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 18 Jul 2000 08:26:02 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <39740BB3.C80C7CA8@lemburg.com> Message-ID: <1248199317-67151042@hypernet.com> M.-A. Lemburg wrote: > Moshe Zadka wrote: > > > > (assume a = [1, 2, 3]) > > > > On Mon, 17 Jul 2000, Gordon McMillan wrote: > > > > > How about a fourth: zip(a) is the same as zip(a, []) ? > > > > Huh??????????????????? > > I think he meant: zip((a,[])) No I didn't. Sigh. >>pad([1,2,3], [1], pad=None) [(1,1), (2,None), (3,None)] >>pad([1,2,3], [], pad=None) [(1,None), (2,None), (3,None)] (If you don't agree with that, you don't agree with the PEP). So I'm proposing that the 2nd positional arg, if not present, be treated as []. That makes: >>zip([1,2,3], pad=None) [(1,None), (2,None), (3,None) >>zip([1,2,3]) [] The other possibility is to make Evan Simpson's dream come true, so >>zip([(1,None), (2,None), (3,None)]) [[1,2,3],[None,None,None]] But then you'd have to throw an exception if the (single) arg wasn't a rectangular sequence of sequences. Also, since lately Guido's on a kick to get rid of auto-tupling/untupling of args, I think you need to use apply(zip, tuple(...)) or the *args syntax to accomplish this. > Here's another one: why should zip() have this special case > at all ? I mean, have you ever seen a zipper with only one > part ? Ok, there is one-hand clapping, but I wouldn't consider > this the normal mode of operation ;-) IMHO, all the special > casing does is mask programming errors. Which doesn't answer the question posed in the PEP. All of the proposed responses are special cases. The one I've seen mentioned most often: >>zip([1,2,3]) [(1,),(2,),(3,)] is very much as special case, as you can see if you ask "what happens when I add a pad arg?". However, if the dev list is having so much trouble deciding how it should decay, I'll vote for throwing an exception. > And another one: zip() as defined is an operation which is -- in > some respects -- the inverse of itself, yet the name does not > carry this information. You can't zip a zipper twice. The > mathematical operation behind it is called transposition (you > view the sequence of sequences as matrix), so in that light the > natural name would be transpose()... tranpose(transpose(matrix))) > has the same structure as matrix itself. But zip takes some number of sequences, not necessarily of the same length. That's not a matrix. I think if you go that route, the user has to first insure they're all the same length and then package them into a sequence. It might have its uses, but not as a replacement for map(None, ...). - Gordon From gmcm at hypernet.com Tue Jul 18 14:26:02 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 18 Jul 2000 08:26:02 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: References: <1248257113-63674673@hypernet.com> Message-ID: <1248199315-67151142@hypernet.com> Moshe Zadka wrote: > (assume a = [1, 2, 3]) > > On Mon, 17 Jul 2000, Gordon McMillan wrote: > > > How about a fourth: zip(a) is the same as zip(a, []) ? > > Huh??????????????????? > > > Look at it this way: what should zip(a, pad=None) return? > > [(1,), (2,), (3,)], of course Then why does the PEP say: >>> zip(a, b, c, d, pad=None) [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)] >>> map(None, a, b, c, d) [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)] If you want no padding, you don't specify a pad arg. pad=None means "pad with None". > > Obviously: [(1, None), (2, None), (3, None)] > > Why? To be consistent. - Gordon From moshez at math.huji.ac.il Tue Jul 18 15:18:03 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 16:18:03 +0300 (IDT) Subject: [Python-Dev] Patches In-Reply-To: <20000718130059.B7340@xs4all.nl> Message-ID: On Tue, 18 Jul 2000, Thomas Wouters wrote: > Now that everyone of importance is off to sunny California, how about we put > some of the patches that have been idling on the SF PM to the vote ? If > Barry objects we can always organize some gigs for him away from the > 'office' ;) Or we can unleash Gordon upon him...seems to be the only thing which strikes terror into his heart (after meeting Gordon, I can understand why) > I'd personally like to hear some votes/opinions on the range literal patch, Didn't Guido urge you to check it in? > - Add 'isatty(fd)' to posixmodule. +1 on that > - Better error message with UnboundLocalError > Patch looks okay to me, and Tim already said he liked the idea. But it seems he had a quibble with the style -- so it's better to wait until he approves. I think we *should* assign it to him, and bug him about it. Any other opinions? > - arraymodule: adding count, extend, index, pop, remove > I believe there was some discussion about this before, don't know the > outcome. I'm +1, but I remember Tim and Guido had something to say about it, so it's safest to wait for them > - new EXTENDED_ARG opcode, elimiate 16-bit oparg limit > Probably needs Guido and/or Tim decreeing whether the change is worth it Agreed > - safe version of PyErr_Format > +0 on that, but what do I know. Don't know if it's actually safe ;) I'm +1. As far as I could read, it is safe. That's the safest we can get without serious stress-tests. This, again, brings up the problem of regression testing for APIs, which is a different topic. (Anyone wants to PEP it?) > - Optional pad character for rjust, ljust > Definately +1, but I have a nagging feeling there is a better way to do it: > Why wasn't this implemented before ? What are people using instead of > string.rjust(string, padchar) ? Probably hand calculations: l = len(s) return s+'p'*(just-l) It's possible.... In fact, putting an implementation of pad() like that in the string.py module would be wonderful, because it would work with both regular strings and unicode. However, string.py is looking as though as it's going to be deprecated. In short, I'd want Guido/Tim/effbot/MAL opinions here before we make a move. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From peter at schneider-kamp.de Tue Jul 18 16:21:59 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 14:21:59 +0000 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> Message-ID: <39746807.DFA2B329@schneider-kamp.de> Thomas Wouters wrote: > > Now that everyone of importance is off to sunny California, how about we put > some of the patches that have been idling on the SF PM to the vote ? If > Barry objects we can always organize some gigs for him away from the > 'office' ;) I am +0 on voting. I don't like the silence on the checkins mailing list. > I'd personally like to hear some votes/opinions on the range literal patch, > but it seems to me there are others that only require some voting and second > opinions: Wasn't there a decision from the BDFL? > - arraymodule: adding count, extend, index, pop, remove > I believe there was some discussion about this before, don't know the > outcome. Guido said something like (hope I got it right): count, index and remove should be implemented in a faster way, but that would take a lot more code and not be worth it. who would use index, count and remove on arrays anyway? so better leave them out, pop is okay though. extend would be worth adding. Tim said something like (hope I got this one right, too): better to have count, index and remove at all than not to have them. I would use them. I interpret that as a -0 from Guido and a +1 from Tim, but - as always - YMMV. My opinion is that an array is only really useful if it supports as much of the list interface as possible. As I understand things arrays are lists where you trade the ability to store any element against some increase in speed. For the slow count, index and remove functions I have three proposals (in order of decreasing appeal to me): 1) just put em in, they are in any case not slower than the Python code you would use to emulate them. +1 2) put them in and add some warnings to the docs that say they are slow. +0 3) do it the fast way. that would be a lot of work and - as Guido pointed out - probably not worth it. I'd do it if it was neccessary though. -0 > - safe version of PyErr_Format > +0 on that, but what do I know. Don't know if it's actually safe ;) -0 on that, I'd rather use snprintf when available, sprintf when not. > - Optional pad character for rjust, ljust > Definately +1, but I have a nagging feeling there is a better way to do it: > Why wasn't this implemented before ? What are people using instead of > string.rjust(string, padchar) ? +1 in any case, but I think we should wait for the new version which supports padstrings, too. also I think there is still no docs/test cases. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From moshez at math.huji.ac.il Tue Jul 18 14:34:38 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 15:34:38 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248199315-67151142@hypernet.com> Message-ID: On Tue, 18 Jul 2000, Gordon McMillan wrote: [about zip(a, pad=None) ] > > > Obviously: [(1, None), (2, None), (3, None)] > > > > Why? > > To be consistent. But when there is only one list, all lists are of the same size, so the pad argument is moot. (Consistent with all other cases where all lists are the same size) Or maybe we're talking about a different situation? Can you show a fake Python session which demonstrates your point? confused-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Tue Jul 18 15:33:48 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 15:33:48 +0200 Subject: [Python-Dev] Patches In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 18, 2000 at 04:18:03PM +0300 References: <20000718130059.B7340@xs4all.nl> Message-ID: <20000718153348.B7345@xs4all.nl> On Tue, Jul 18, 2000 at 04:18:03PM +0300, Moshe Zadka wrote: > On Tue, 18 Jul 2000, Thomas Wouters wrote: > > I'd personally like to hear some votes/opinions on the range literal patch, > Didn't Guido urge you to check it in? I have *no* idea :) The 'Right!' seemed to imply that, but I doubt he'd let me check it in without *someone* reviewing it ;) > > - Better error message with UnboundLocalError > > Patch looks okay to me, and Tim already said he liked the idea. > But it seems he had a quibble with the style -- so it's better to wait > until he approves. I think we *should* assign it to him, and bug him > about it. Any other opinions? The style issue is history. The new version is style-conforming, I think, asside from a small bug in the definition of the helper function (see the comment, Paul ;) That doesn't mean Tim shouldn't check it first, though. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Tue Jul 18 15:44:01 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 16:44:01 +0300 (IDT) Subject: [Python-Dev] posixpath.normpath Message-ID: Simple question: what should a) posixpath.normpath("..") b) posixpath.normpath("/..") return? Anyone? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From peter at schneider-kamp.de Tue Jul 18 17:44:04 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 15:44:04 +0000 Subject: [Python-Dev] Will Python die? References: Message-ID: <39747B44.4284A38B@schneider-kamp.de> Moshe Zadka wrote: > > I agree with Tim -- your 1.8 would face backwards- and forwards- > compatabilitiy issues CVS versions do not have to face. I basically agree. An official release would be a Bad Thing(TM). But at least some information should leak to the masses to prevent slashdot threads like that: http://slashdot.org/comments.pl?sid=00/07/17/0312221&threshold=-1&commentsort=0&mode=flat&cid=41 Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From moshez at math.huji.ac.il Tue Jul 18 15:46:07 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 16:46:07 +0300 (IDT) Subject: [Python-Dev] Will Python die? In-Reply-To: <39747B44.4284A38B@schneider-kamp.de> Message-ID: On Tue, 18 Jul 2000, Peter Schneider-Kamp wrote: > But at least some information should leak to the masses to prevent > slashdot threads like that: > > http://slashdot.org/comments.pl?sid=00/07/17/0312221&threshold=-1&commentsort=0&mode=flat&cid=41 My fault -- I stopped reading /. Can you summarize the thread? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From peter at schneider-kamp.de Tue Jul 18 18:06:37 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 16:06:37 +0000 Subject: [Python-Dev] Will Python die? References: Message-ID: <3974808D.5D49575D@schneider-kamp.de> Moshe Zadka wrote: > > My fault -- I stopped reading /. Can you summarize the thread? The thread is about if Visual Python is an alternative for Visual Basic or, if not, it can be used as that. A subthread of this thread dealt with Pythons release schedule: "Speaking of Python, does anyone know what's up with Python 1.6^H^H2.0? A while back, python.org had said that version 1.6 would be out on June 1. Then there was an announcement, mid-June that it would be delayed. Then at the end of June, this link was placed on python.org, and it was stated that the Python interpreter, version 1.6, was renamed to 2.0, and the first beta would be available on July 1. Now, on July 17, that link has been removed from python.org (although the webpage still exists), and the release schedule is gone!" Quoting from relevant replies: "python 1.6 will be out in august check the downloads page of www.python.org or checkout the pythonlabs at www.beopen.com where most of the core python developers opened shop" "Yeah, the Python 1.6 download page says that Python 1.6 beta1 will be done on July 1, and beta 2 on July 14. It's July 17 now, and the only available download is alpha 2...." read-what-you-want-from-that-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gvwilson at nevex.com Tue Jul 18 16:11:30 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 18 Jul 2000 10:11:30 -0400 (EDT) Subject: [Python-Dev] Re: PEP 201 - Parallel iteration In-Reply-To: <200007172015.WAA25033@python.inrialpes.fr> Message-ID: I realize it's late in the day, but could the name of the concept (not the function) be changed from "parallel iteration" to something that doesn't imply concurrent execution quite so strongly? I think the use of "parallel" is very likely to mislead, particularly scientists and engineers who actually have parallel loops in their jumped-up Fortran and C++ systems. Thanks, Greg From akuchlin at cnri.reston.va.us Tue Jul 18 16:13:21 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 18 Jul 2000 10:13:21 -0400 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: ; from pingster@ilm.com on Mon, Jul 17, 2000 at 07:37:08PM -0700 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: <20000718101321.D21354@newcnri.cnri.reston.va.us> Thanks to everyone who made some suggestions. The more minor edits have been made, but I haven't added any of the threads I missed because doing a long stretch of Emacs editing in this lame Windows terminal program will drive me insane, so I just posted the summary to python-list. How is it possible for Microsoft to not get a VT100-compatible terminal program working correctly? VT100s have been around since, when, the 1970s? Can anyone suggest a Windows terminal program that *doesn't* suck dead bunnies through a straw? --amk From skip at mojam.com Tue Jul 18 16:18:31 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 18 Jul 2000 09:18:31 -0500 (CDT) Subject: [Python-Dev] Patches In-Reply-To: <20000718130059.B7340@xs4all.nl> References: <20000718130059.B7340@xs4all.nl> Message-ID: <14708.26423.536040.581684@beluga.mojam.com> Thomas> Now that everyone of importance is off to sunny California, how Thomas> about we put some of the patches that have been idling on the SF Thomas> PM to the vote ? As someone who has been assigned some patches that are still open (isatty, normpath fix, history functions for readline), I'm still pretty much in the dark about what my rights and responsibilities are. Am I supposed to eyeball a patch and check it in if it looks okay (compiles, doesn't break "make test", etc)? Am I supposed to bring it up for discussion on python-dev? Something entirely different (blow up a bush, perhaps)? I just submitted a feature request for the patch manager at SF. I asked for the following: 1. better selection/exclusion predicates for the filtering function 2. filtering based on assignee/submitter 3. display of a patch's state in the table If you'd like to review it and add your own two cents, it's at https://sourceforge.net/forum/message.php?msg_id=41288 Skip From gvwilson at nevex.com Tue Jul 18 16:36:02 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 18 Jul 2000 10:36:02 -0400 (EDT) Subject: [Python-Dev] CVS / Subversion / language choice In-Reply-To: <3973A510.86D2AF54@prescod.net> Message-ID: > > Welcome to CVS. What did Greg Wilson say at IPC8? Paraphrasing: CVS > > is the worst tool everybody uses. :) "CVS is the suckiest tool that developers have to use on a daily basis." (It was actually one of my students at Los Alamos --- and it was one of the few times there's been a round of applause in a class I've taught :-). BTW, if you haven't seen Subversion: http://subversion.tigris.org It's worth checking out (if only to see what's keeping Greg Stein off the streets and out of trouble). The project's aim is to produce a "better CVS", i.e. fix some of the known warts, and web-enable it using WebDAV. I like their goals (fairly conservative, but therefore also fairly likely to be accepted), and their use of ASCII art in PDFs :-). The thing that surprised me was their decision to do their first implementation in C, rather than getting something together quickly in a scripting language, and then re-writing modules for performance when/as necessary. I asked Brian Behlendorf about this; he said the reasons were: > ...we're focusing on C in the short run is to take away any religious > wars concerning python vs java vs perl - C, as crappy as it is, is > still a pretty neutral language when it comes to deployment, as > everyone has a C compiler but not everyone wants to install python. > Also, the server side will mostly consist of an Apache plugin and a > driver for the actual database format, so keeping it all in C and all > in the same process is attractive. > > Also, the developers I've got working on it are very comfortable in C, > and I'm trusting that they considered it and elected to just write in > C directly. These were pretty much the same reasons Larry McVoy gave me when I asked him why BitKeeper was using C rather than a scripting language. I'd be interested in knowing whether this attitude is still the norm, or whether there is evidence of a general shift toward the prototyping/filling-in model. I have a progress report to write for Software Carpentry, and... (In the interests of conserving bandwidth, please reply directly; I'll summarize and re-post if there's sufficient interest.) Thanks, Greg From thomas at xs4all.net Tue Jul 18 16:42:24 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 16:42:24 +0200 Subject: [Python-Dev] Patches In-Reply-To: <14708.26423.536040.581684@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 18, 2000 at 09:18:31AM -0500 References: <20000718130059.B7340@xs4all.nl> <14708.26423.536040.581684@beluga.mojam.com> Message-ID: <20000718164224.D7345@xs4all.nl> On Tue, Jul 18, 2000 at 09:18:31AM -0500, Skip Montanaro wrote: > Thomas> Now that everyone of importance is off to sunny California, how > Thomas> about we put some of the patches that have been idling on the SF > Thomas> PM to the vote ? > As someone who has been assigned some patches that are still open (isatty, > normpath fix, history functions for readline), Don't forget: you can assign them to someone else if you feel you have too much, or if you aren't the right person, or just don't feel like dealing with that patch. > I'm still pretty much in the dark about what my rights and > responsibilities are. Am I supposed to eyeball a patch and check it in if > it looks okay (compiles, doesn't break "make test", etc)? Yes, at the least. Also whether it complies to coding style, includes a test (when necessary), etc. > Am I supposed to bring it up for discussion on > python-dev? Possibly. I donno. That used to be done on patches, I gather, but that list is kind of defunct, now. That's partly why I wrote the first posting in this thread, to bring some of those patches to attention. I don't think you're intended to be the Guardian Angel of those patches, though, just the one checking them out. If you aren't sure, post here (or patches at python.org), I guess. If you can't figure out what to do, assign it to Tim. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From esr at thyrsus.com Tue Jul 18 18:36:31 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jul 2000 12:36:31 -0400 Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <20000718171739.F7345@xs4all.nl> References: <20000718121831.A7340@xs4all.nl> <20000718110823.B10480@thyrsus.com> <20000718171739.F7345@xs4all.nl> Message-ID: <20000718123631.B10741@thyrsus.com> Thomas Wouters : > Well, I guess I agree. The above was just a bit of 'Red Red Wine' induced > brainstorm, but on reflection it does seem logical. The one-dimensionality > of range and xrange always bothered me ;) The biggest problem is, however, > how to create a 'range' of a specific type of object, given a start, step > and end object. A new PyNumberMethods member 'int_range' ? Or some kind of > 'newobject_fromnumber' protocol ? Let's worry about that later. For now, throwing an exception is OK. > How about we checkin the current patch, which does what the PEP describes, > and continue the PEP for the sake of these issues ? :) +1. -- Eric S. Raymond If I were to select a jack-booted group of fascists who are perhaps as large a danger to American society as I could pick today, I would pick BATF [the Bureau of Alcohol, Tobacco, and Firearms]. -- U.S. Representative John Dingell, 1980 From skip at mojam.com Tue Jul 18 20:55:01 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 18 Jul 2000 13:55:01 -0500 (CDT) Subject: [Python-Dev] what happened with the python-list addresses? Message-ID: <14708.43013.274067.569324@beluga.mojam.com> I don't want to create a storm on c.l.py, so I post here. I noticed a bunch of "email addresses" that look like "aahz at netcom.com.bbs@openbazaar.net" in recent digests. Is there some sort of runaway gateway? Who is openbazaar.net? Sounds like something ESR would be involved with, though I can't reach an obvious web site in that domain and they appear to be located in Taiwan. Skip From skip at mojam.com Tue Jul 18 16:19:51 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 18 Jul 2000 09:19:51 -0500 (CDT) Subject: [Python-Dev] Patches In-Reply-To: <20000718130059.B7340@xs4all.nl> References: <20000718130059.B7340@xs4all.nl> Message-ID: <14708.26503.552322.616643@beluga.mojam.com> Thomas> - Optional pad character for rjust, ljust Thomas> Definately +1, but I have a nagging feeling there is a better Thomas> way to do it: Why wasn't this implemented before ? What are Thomas> people using instead of string.rjust(string, padchar) ? Perhaps it's just obscure (to me). I don't believe I've ever used [lr]just. Skip From esr at thyrsus.com Tue Jul 18 17:08:23 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jul 2000 11:08:23 -0400 Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <20000718121831.A7340@xs4all.nl> References: <20000718121831.A7340@xs4all.nl> Message-ID: <20000718110823.B10480@thyrsus.com> Thomas Wouters : > I wrote this using 'joe', which is still my favorite editor, because despite > many, many minutes of effort, xemacs simply refused to do what I wanted it > to do. How do you 're-flow' a paragraph, Esc-g > for instance, or enable word > wrapping, or better yet: word wrapping with autoindentation ? Esc-x set-variable auto-fill 1 To always enable it in text mode, add (setq text-mode-hook '(lambda () (auto-fill-mode 1))) to your .emacs file. Emacs will detect your indent level and honor it. > One possible solution to the discrepancy of requiring the `end' > argument in range literals is to allow the range syntax to create > a `generator', rather than a list, such as the `xrange' builtin > function does. However, a generator would not be a list, and it > would be impossible, for instance, to assign to items in the > generator, or append to it. Not so. Appending to the generator object, or assigning to it, would simply force eager rather than lazy evaluation of the generator. This would have to throw an exception on infinite generators. But all this is academic until Python has continuations, really. For finite cases eager vs. lazy only makes a difference in the timing of computations, not their result. While this could be semantically significant for some list comprehensions, it won't be for range literals. (You might want to go look at Haskell or Icon to learn more about how lazy and eager evaluation interact.) > Should it be possible to mix range syntax with normal list > literals, creating a single list, like so: > > >>> [5, 6, 1:6, 7, 9] > to create > [5, 6, 1, 2, 3, 4, 5, 7, 9] I'm completely neutral on this. > However, as the syntax and semantics of list comprehensions are > still subject of hot debate, these issues are probably best > addressed by the `list comprehensions' PEP. Agreed. > Range literals accept objects other than integers: it performs > PyInt_AsLong() on the objects passed in, so as long as the objects > can be coerced into integers, they will be accepted. The > resulting list, however, is always composed of standard integers. > > Should range literals create a list of the passed-in type ? It > might be desirable in the cases of other builtin types, such as > longs and strings: > > >>> [ 1L : 2L<<64 : 2<<32L ] > >>> ["a":"z":"b"] > >>> ["a":"z":2] > > However, this might be too much `magic' to be obvious. It might > also present problems with user-defined classes: even if the base > class can be found and a new instance created, the instance may > require additional arguments to __init__, causing the creation to > fail. +1. Whenever possible, builtins ought to do something intuitive with any type that is passed in, and range literals have an obvious and intuitive definition for any well-ordered base type. I think it would be more surprising if this did *not* work for well-ordered scalar types. I don't view the issue for user-defined classes as a showstopper; it would be OK, and semantically reasonable, to throw an exception in this case. > The PyList_FromRange() and PyList_GetLenOfRange() functions need > to be classified: are they part of the API, or should they be made > private functions ? No opinion. -- Eric S. Raymond ...the Federal Judiciary...an irresponsible body, working like gravity by night and by day, gaining a little today and a little tomorrow, and advancing its noiseless step like a thief over the field of jurisdiction until all shall be usurped from the States; and the government of all be consolidated into one. From esr at thyrsus.com Tue Jul 18 17:11:57 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jul 2000 11:11:57 -0400 Subject: [Python-Dev] Patches In-Reply-To: <20000718130059.B7340@xs4all.nl> References: <20000718130059.B7340@xs4all.nl> Message-ID: <20000718111157.C10480@thyrsus.com> Thomas Wouters : > I'd personally like to hear some votes/opinions on the range literal patch, > but it seems to me there are others that only require some voting and second > opinions: I just posted a detailed response on that. > - Add 'isatty(fd)' to posixmodule. > Do Macs and Windows machines have an isatty() function that makes sense to > include ? Unknown to me. I'm +1 on adding this anyway. > - Better error message with UnboundLocalError > Patch looks okay to me, and Tim already said he liked the idea. +0. > - arraymodule: adding count, extend, index, pop, remove > I believe there was some discussion about this before, don't know the > outcome. Is there a PEP? I suspect from looking at the names that I would be +0 on this, but I wonder why pop() and no push()? > - new EXTENDED_ARG opcode, elimiate 16-bit oparg limit > Probably needs Guido and/or Tim decreeing whether the change is worth it > > - safe version of PyErr_Format > +0 on that, but what do I know. Don't know if it's actually safe ;) > > - Optional pad character for rjust, ljust > Definately +1, but I have a nagging feeling there is a better way to do it: > Why wasn't this implemented before ? What are people using instead of > string.rjust(string, padchar) ? No opinion on these. -- Eric S. Raymond He that would make his own liberty secure must guard even his enemy from oppression: for if he violates this duty, he establishes a precedent that will reach unto himself. -- Thomas Paine From thomas at xs4all.net Tue Jul 18 16:59:46 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 16:59:46 +0200 Subject: [Python-Dev] Patches In-Reply-To: <20000718111157.C10480@thyrsus.com>; from esr@thyrsus.com on Tue, Jul 18, 2000 at 11:11:57AM -0400 References: <20000718130059.B7340@xs4all.nl> <20000718111157.C10480@thyrsus.com> Message-ID: <20000718165945.E7345@xs4all.nl> On Tue, Jul 18, 2000 at 11:11:57AM -0400, esr at thyrsus.com wrote: > > - arraymodule: adding count, extend, index, pop, remove > > I believe there was some discussion about this before, don't know the > > outcome. > > Is there a PEP? I suspect from looking at the names that I would > be +0 on this, but I wonder why pop() and no push()? No PEP, it's pre-PEP. The methods names are not in question, because they mirror the current *list* method names ;) and push() is spelled 'append()' in Python. Here's what pop() does: >>> x = [1,2,3,4,5] >>> x.pop() 5 >>> x [1, 2, 3, 4] The question is mostly whether count(), index() and maybe remove() are worth adding to the arrayobject, given their inefficient implementation. (An efficient implementation would require a fair bit of code, but on the plus side, that same code could then be used for 'sq_contains', which currently is appallingly inefficient.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Tue Jul 18 18:00:31 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 19:00:31 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248199317-67151042@hypernet.com> Message-ID: On Tue, 18 Jul 2000, Gordon McMillan wrote: > (If you don't agree with that, you don't agree with the PEP). I agree with that. Luckily, I've snipped it, so it's not valid as evidence > So I'm proposing that the 2nd positional arg, if not present, be > treated as []. That makes: That's a special case! > Which doesn't answer the question posed in the PEP. All of > the proposed responses are special cases. The one I've seen > mentioned most often: > >>zip([1,2,3]) > [(1,),(2,),(3,)] > is very much as special case, as you can see if you ask > "what happens when I add a pad arg?". I disagree: you agree that if you add a pad argument when the lists are all the same size it doesn't matter (if you don't agree with this, you don't agree with the PEP). Now, when there is only one list, the lists are all the same size. QED. > However, if the dev list is having so much trouble deciding how > it should decay, I'll vote for throwing an exception. I'm starting to agree -- I'm thinking like a mathematician, which not everyone in the world are (sadly) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Tue Jul 18 17:17:39 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 17:17:39 +0200 Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <20000718110823.B10480@thyrsus.com>; from esr@thyrsus.com on Tue, Jul 18, 2000 at 11:08:23AM -0400 References: <20000718121831.A7340@xs4all.nl> <20000718110823.B10480@thyrsus.com> Message-ID: <20000718171739.F7345@xs4all.nl> On Tue, Jul 18, 2000 at 11:08:23AM -0400, esr at thyrsus.com wrote: > Thomas Wouters : > > One possible solution to the discrepancy of requiring the `end' > > argument in range literals is to allow the range syntax to create > > a `generator', rather than a list, such as the `xrange' builtin > > function does. However, a generator would not be a list, and it > > would be impossible, for instance, to assign to items in the > > generator, or append to it. > Not so. Appending to the generator object, or assigning to it, would > simply force eager rather than lazy evaluation of the generator. This > would have to throw an exception on infinite generators. > (You might want to go look at Haskell or Icon to learn more about > how lazy and eager evaluation interact.) Well, I had an xrange() like generator in mind. There currently isn't a very good way for a generator to turn itself into a list, unless it's some kind of polymorphic object that behaves one way until it gets assigned to... In which case I wouldn't want to meet it in a dark alley, alone, at night, without my language reference printout. I don't have the human resources to do an in-depth study of generators (or other languages) right now. The idiots I have to cooperate with at work (from our parent company) are sucking all life out of me, in a bad way ;P > > Should range literals create a list of the passed-in type ? It > > might be desirable in the cases of other builtin types, such as > > longs and strings: [..] > > However, this might be too much `magic' to be obvious. It might > > also present problems with user-defined classes: even if the base > > class can be found and a new instance created, the instance may > > require additional arguments to __init__, causing the creation to > > fail. > +1. Whenever possible, builtins ought to do something intuitive with > any type that is passed in, and range literals have an obvious and > intuitive definition for any well-ordered base type. I think it > would be more surprising if this did *not* work for well-ordered > scalar types. Well, I guess I agree. The above was just a bit of 'Red Red Wine' induced brainstorm, but on reflection it does seem logical. The one-dimensionality of range and xrange always bothered me ;) The biggest problem is, however, how to create a 'range' of a specific type of object, given a start, step and end object. A new PyNumberMethods member 'int_range' ? Or some kind of 'newobject_fromnumber' protocol ? How about we checkin the current patch, which does what the PEP describes, and continue the PEP for the sake of these issues ? :) > I don't view the issue for user-defined classes as a showstopper; > it would be OK, and semantically reasonable, to throw an exception > in this case. Agreed. And thanx for the emacs pointers ! :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Tue Jul 18 20:07:58 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 18 Jul 2000 13:07:58 -0500 (CDT) Subject: [Python-Dev] Patches In-Reply-To: References: <20000718130059.B7340@xs4all.nl> Message-ID: <14708.40190.852802.966575@beluga.mojam.com> Moshe> In fact, putting an implementation of pad() like that in the Moshe> string.py module would be wonderful, because it would work with Moshe> both regular strings and unicode. However, string.py is looking Moshe> as though as it's going to be deprecated. In short, I'd want Moshe> Guido/Tim/effbot/MAL opinions here before we make a move. Don't know about the powers that be, but I don't see how you can realistically deprecate string.py until you deprecate map(). My most frequent use of map() is the simple newlist = map(string.strip, oldlist) where oldlist is a list of strings. (Replace "strip" by "upper", "lower", etc, depending on your needs.) As far as I'm aware, there's no clean way to do that with string methods. Skip From effbot at telia.com Tue Jul 18 21:37:39 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 18 Jul 2000 21:37:39 +0200 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> Message-ID: <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> > > - safe version of PyErr_Format > > +0 on that, but what do I know. Don't know if it's actually safe ;) > > -0 on that, I'd rather use snprintf when available, sprintf when not. strange argument. why is it okay to crash Python on Windows, pure SUSv2 platforms, pure ANSI C platforms, etc? besides, snprintf doesn't do the same thing as my PyErr_Format replacement... From gstein at lyra.org Tue Jul 18 21:41:44 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 12:41:44 -0700 Subject: [Python-Dev] Terminal programs (was: Python-dev summary: Jul 1-15) In-Reply-To: <20000718101321.D21354@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Tue, Jul 18, 2000 at 10:13:21AM -0400 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> Message-ID: <20000718124144.M29590@lyra.org> On Tue, Jul 18, 2000 at 10:13:21AM -0400, Andrew Kuchling wrote: > Thanks to everyone who made some suggestions. The more minor > edits have been made, but I haven't added any of the threads I missed > because doing a long stretch of Emacs editing in this lame Windows terminal > program will drive me insane, so I just posted the summary to python-list. > > How is it possible for Microsoft to not get a VT100-compatible > terminal program working correctly? VT100s have been around since, > when, the 1970s? Can anyone suggest a Windows terminal program that > *doesn't* suck dead bunnies through a straw? yes. I use "Tera Term Pro" with the SSH extensions. That gives me an excellent Telnet app, and it gives me SSH. I have never had a problem with it. [ initially, there is a little tweakiness with creating the "known_hosts" file, but you just hit "continue" and everything is fine after that. ] Tera Term Pro can be downloaded from some .jp address. I think there is a 16-bit vs 32-bit program. I use the latter. The SSL stuff is located in Oz, me thinks. I've got it on the laptop. Great stuff. Cheers, -g -- Greg Stein, http://www.lyra.org/ From nascheme at enme.ucalgary.ca Tue Jul 18 22:37:03 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 18 Jul 2000 14:37:03 -0600 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: <20000718101321.D21354@newcnri.cnri.reston.va.us>; from Andrew Kuchling on Tue, Jul 18, 2000 at 10:13:21AM -0400 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> Message-ID: <20000718143703.A15498@keymaster.enme.ucalgary.ca> On Tue, Jul 18, 2000 at 10:13:21AM -0400, Andrew Kuchling wrote: > Can anyone suggest a Windows terminal program that *doesn't* suck dead > bunnies through a straw? I like putty. You can do a google search for it or grab it off my website: http://www.enme.ucalgary.ca/~nascheme/putty.exe http://www.enme.ucalgary.ca/~nascheme/pscp.exe http://www.enme.ucalgary.ca/~nascheme/putty.zip It's a single exectutable that does telnet, SSH and raw TCP connections (very nice when your away from home). It sucks much less than the Windows telnet. Hmm, I wonder if MS was motivated to make logging into a Unix machine as painful as possible? Neil From paul at prescod.net Tue Jul 18 22:50:57 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 18 Jul 2000 15:50:57 -0500 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> Message-ID: <3974C331.4FAFD48D@prescod.net> Thomas Wouters wrote: > >... > > .... > > - Better error message with UnboundLocalError > Patch looks okay to me, and Tim already said he liked the idea. Tim might as well look at it. I'm a little paranoid about changing ceval. I fixed the static typo you pointed out. Re: range literal: I think you need to assign it to some "core" to look at. Yes, Guido likes the idea but nobody has verified the implementation. Maybe it isn't an issue of core/non-core but more just a requirement for a second opinion. I would advise against checking in without it. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From thomas at xs4all.net Tue Jul 18 23:28:33 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 23:28:33 +0200 Subject: [Python-Dev] 'shadowing' builtins In-Reply-To: <39734E04.C7D29873@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 01:18:44PM -0500 References: <20000717200116.P7340@xs4all.nl> <39734E04.C7D29873@prescod.net> Message-ID: <20000718232833.F4283@xs4all.nl> On Mon, Jul 17, 2000 at 01:18:44PM -0500, Paul Prescod wrote: > Thomas Wouters wrote: > > He decided to go to David Beazly's python introduction, and he was suprised > > at how you can do 'None = 4'. And when I explained it's harmless (because > > it's local, not global) he was suprised it didn't generate a warning. And, > > well, why doesn't it generate a warning ? Only with an, uhm, '-w' option or > > so, of course, or perhaps add it to the '-t' option. It would be also a > > compile-time-check. It might require a seperate lookup table (haven't looked > > at it at all, yet) that duplicates the 'builtin' namespace, but I'd think > > it's worth it. > * None, map and other such long-term, ancient built-ins should not be > directly overridable. I don't think we need a warning mode. Just outlaw > it. We can do this with a semantic check in the compiler. My first reaction was 'Ack, eek, argh, nonono'. So I decided to sleep over it. And my reaction is still 'Ack. eek, argh, nonono' ;) If it's optional, like a '-ww' option, sure. But by default ? Please don't. One of python's great features is that it's so damned consistent. Having some builtins overridable and others not would not only break a lot of code, it would also confuse a lot of people. There is no particular reason to disallow assigning to map() for programs where map() is not used, for instance. I often find myself doing 'list = <...>' for small scripts, eventhough I realize while I'm typing that 'list' is a builtin function. Part of the reasons is that 'list' is an incredibly descriptive name, and my code often gets read by colleagues who still need to get infected by the Python virus. (Though, I have to admit, it *is* slowly spreading ;) Nevertheless, I wouldn't do that in large projects, and that's where I invision the '-w' option would be best used. 'This might become a problem'. > * Those with a good reason to shadow them would do it by assignment to > the module's dict or __builtins__. The "feature" would still be there if > you need it, but it would be syntactically distinct. Or maybe we need to > disallow it entirely to allow optimizers to attack this important > special case. Perhaps, as an option. With an optimizer. I wouldn't do it for the sake of it; only do it if the user asks for it. > * Python badly needs a warning infrastructure. If I had time, that > would be my first PEP. I'd rather the former tightening up was not > hostage to a warning infrastructure that nobody gets around to > implementing, though. I might be tempted to suggest a compile-only command line switch, too. Doing it through a small script is a tad cumbersome, especially if you just want a compile-run with (for instance) -w or -t, to see if you have any obvious problems. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Tue Jul 18 23:45:19 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 18 Jul 2000 16:45:19 -0500 Subject: [Python-Dev] 'shadowing' builtins References: <20000717200116.P7340@xs4all.nl> <39734E04.C7D29873@prescod.net> <20000718232833.F4283@xs4all.nl> Message-ID: <3974CFEF.C55AC9B@prescod.net> Thomas Wouters wrote: > > ... > > My first reaction was 'Ack, eek, argh, nonono'. So I decided to sleep over > it. And my reaction is still 'Ack. eek, argh, nonono' ;) If it's optional, > like a '-ww' option, sure. But by default ? Please don't. One of python's > great features is that it's so damned consistent. Having some builtins > overridable and others not would not only break a lot of code, it would also > confuse a lot of people. Most people probably do not even know that the built-in functions can be shadowed. That's precisely the problem. I don't think that enforcing a rule that they expect to already be enforced will confuse them. As your friend pointed out, NOT enforcing the rule confuses them. > There is no particular reason to disallow assigning to map() for programs > where map() is not used, for instance. I often find myself doing 'list = > <...>' for small scripts, eventhough I realize while I'm typing that 'list' > is a builtin function. Part of the reasons is that 'list' is an incredibly > descriptive name, and my code often gets read by colleagues who still need > to get infected by the Python virus. Using the same word for two different things is more likely to confuse them than help them. Anyhow, constructor functions and type names need to be unified (for consistency) and type names and class names need to be unified (for consistency). And class names start with an upper case letter. So the need to override list() is scheduled to go away (eventually!) > Nevertheless, I wouldn't do that in large projects, and that's where I > invision the '-w' option would be best used. 'This might become a problem'. It is just as likely a problem in a small project than ina a big one. The shadowing is local, after all. It isn't a problem that "gets worse" as the program grows. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From esr at thyrsus.com Wed Jul 19 00:11:48 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jul 2000 18:11:48 -0400 Subject: [Python-Dev] what happened with the python-list addresses? In-Reply-To: <14708.43013.274067.569324@beluga.mojam.com> References: <14708.43013.274067.569324@beluga.mojam.com> Message-ID: <20000718181148.F1283@thyrsus.com> Skip Montanaro : > > I don't want to create a storm on c.l.py, so I post here. I noticed a bunch > of "email addresses" that look like "aahz at netcom.com.bbs@openbazaar.net" in > recent digests. Is there some sort of runaway gateway? Who is > openbazaar.net? Sounds like something ESR would be involved with, though I > can't reach an obvious web site in that domain and they appear to be located > in Taiwan. > > Skip I know nothing about it. -- Eric S. Raymond What, then is law [government]? It is the collective organization of the individual right to lawful defense." -- Frederic Bastiat, "The Law" From peter at schneider-kamp.de Wed Jul 19 02:04:00 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 00:04:00 +0000 Subject: [Python-Dev] PEP 204 - Range Literals References: <20000718121831.A7340@xs4all.nl> Message-ID: <3974F070.CC18BED0@schneider-kamp.de> Thomas Wouters wrote: > > I've attached the first draft of PEP 204, Range Literals, which I just > uploaded to CVS as well. If anyone finds time to review it, or the proposed > implementation (patch #100902 on SourceForge) please do. I'm not sure what > to do with the patch... Guido said as much as 'apply it'(*), but I doubt > anyone really looked at it yet ;) Well, I can't say I really looked at it (the patch touches areas where I would deny me all too much expertise), but as far as I could understand it, it looks fine to me. This considered, I am still +1 on it. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From jack at oratrix.nl Wed Jul 19 00:09:39 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 19 Jul 2000 00:09:39 +0200 Subject: [Python-Dev] posixpath.normpath In-Reply-To: Message by Moshe Zadka , Tue, 18 Jul 2000 16:44:01 +0300 (IDT) , Message-ID: <20000718220944.ECF41126BD4@oratrix.oratrix.nl> Recently, Moshe Zadka said: > Simple question: what should > > a) posixpath.normpath("..") .. What else could it return? > b) posixpath.normpath("/..") This I'm a bit less sure about. Does anyone remember the Newcastle Connection a.k.a Unix United? It was a distributed filesystem where other hosts were reachable through /.. . Think of something analogous to going from foo.bar.nl to the root of bletch.bar.nl by doing /../bletch/ . The newcastle connection is long dead (at least, I assume it is) but unless the Posix standard unequivocally specifies that /.. == /. I think I'd keep it as-is. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack at oratrix.nl Wed Jul 19 00:13:35 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 19 Jul 2000 00:13:35 +0200 Subject: [Python-Dev] what happened with the python-list addresses? In-Reply-To: Message by Skip Montanaro , Tue, 18 Jul 2000 13:55:01 -0500 (CDT) , <14708.43013.274067.569324@beluga.mojam.com> Message-ID: <20000718221340.50A58126BD4@oratrix.oratrix.nl> Recently, Skip Montanaro said: > openbazaar.net? Sounds like something ESR would be involved with, [...] On the premise that anything with "bazaar" has to do with ESR? Hmm, then I could try asking him for a refund on that overpriced and leaky teapot I got in Egypt last year... :-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From peter at schneider-kamp.de Wed Jul 19 02:13:52 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 00:13:52 +0000 Subject: [Python-Dev] PEP 206 - NumPy Message-ID: <3974F2C0.F028CE48@schneider-kamp.de> I know this has probably been discussed many times, but a) I haven't been around that long and b) there is a TBD in nondist/peps/pep-206.txt :-] What would it take to include NumPy with the "Batteries included" release of Python? BTW: What about kjBuckets and some other modules that have been proposed? They are not in the PEP. ducking-behind-a-shuttle-style-ceramic-tile-heat-absorber-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From barry at scottb.demon.co.uk Wed Jul 19 00:15:10 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Tue, 18 Jul 2000 23:15:10 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Message-ID: <000601bff105$a3770500$060210ac@private> mark commenting on Gordon commenting on Barry... > If we are asking them to change their code, can we investigate whether > asking them to insert a simple: > > if (!Py_IsInitialized()) > Py_FatalError("Bad Python version"); /* Never returns */ > > works OK? I believe it will, as long as Python's fatal error handler > doesnt make thread-state assumptions. I think this code will crash. 1. Python20.dll loads and is initialised. 2. python20.dll loads old_extension.pyd 3. old_extension.pyd causes python15.dll to load At this point we have two copies of python in memory. 4. old_extension.pyd calls Py_IsInitialized() which is bound to the function in python15.dll. 5. FALSE is return as python15.dll has not been initialised. 6. Py_FatalError which is bound in python15.dll is called. May well crash, certainly does not communicate to python20.dll You could just: if (!Py_IsInitialized()) return; Which prevents the module being created and hence gets an already implemented error message. The down side is that does not work for .PYD that have already been shipped for 1.5. Also if we wish to solve this class of problem for unix as well this does not work. Barry From barry at scottb.demon.co.uk Wed Jul 19 00:36:15 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Tue, 18 Jul 2000 23:36:15 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python Message-ID: <000701bff108$950ec9f0$060210ac@private> Mark's comment about what I'd come up with being too complex inspired this simpler solution. Change the init function name to a new name PythonExtensionInit_ say. Pass in the API version for the extension writer to check. If the version is bad for this extension returns without calling any python functions. Add a return code that is true if compatible, false if not. If compatible the extension can use python functions and report and problems it wishes. int PythonExtensionInit_XXX( int invoking_python_api_version ) { if( invoking_python_api_version != PYTHON_API_VERSION ) { /* python will report that the module is incompatible */ return 0; } /* setup module for XXX ... */ /* say this extension is compatible with the invoking python */ return 1; } All 1.5 extensions fail to load on later python 2.0 and later. All 2.0 extensions fail to load on python 1.5. All new extensions work only with python of the same API version. Document that failure to setup a module could mean the extension is incompatible with this version of python. Small code change in python core. But need to tell extension writers what the new interface is and update all extensions within the python CVS tree. Barry From effbot at telia.com Wed Jul 19 00:52:11 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 19 Jul 2000 00:52:11 +0200 Subject: [Python-Dev] uPEP: encoding directive References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> Message-ID: <016501bff10a$d09bc660$f2a6b5d4@hagrid> > [paul] > > Also, is it really necessary to allow raw non-ASCII characters in source > > code though? We know that they aren't portable across editing > > environments, so one person's happy face will be another person's left > > double-dagger. > > [me] > I suppose changing that would break code. maybe it's time > to reopen the "pragma encoding" thread? > > (I'll dig up my old proposal, and post it under a new subject). as brief as I can make it: 1. add support for "compiler directives". I suggest the following syntax, loosely based on XML: #?python key=value [, key=value ...] (note that "#?python" will be treated as a token after this change. if someone happens to use comments that start with #?python, they'll get a "SyntaxError: bad #?python compiler directive"...) 2. for now, only accept compiler directives if they appear before the first "real" statement. 3. keys are python identifiers (NAME tokens), values are simple literals (STRING, NUMBER) 4. key/value pairs are collected in a dictionary. 5. for now, we only support the "encoding" key. it is used to determine how string literals (STRING tokens) are converted to string or unicode string objects. 6. the encoding value can be any of: "undefined" or not defined at all: plain string: copy source characters as is unicode string: expand 8-bit source characters to unicode characters (i.e. treat them as ISO Latin 1) "ascii" plain string: characters in the 128-255 range gives a SyntaxError (illegal character in string literal). unicode string: same as for plain string any other ascii-compatible encoding (the ISO 8859 series, Mac Roman, UTF-8, and others): plain string: characters in the 128-255 range gives a SyntaxError (illegal character in string literal). unicode string: characters in the 128-255 range are decoded, according to the given encoding. string has been decoded, any other encoding (UCS-2, UTF-16) undefined (or SyntaxError: illegal encoding) to be able to flag this as a SyntaxError, I assume we can add an "ASCII compatible" flag to the encoding files. 7. only the contents of string literals can be encoded. the tokenizer still works on 7-bit ASCII (hopefully, this will change in future versions). 8. encoded string literals are decoded before Python looks for backslash escape codes. I think that's all. Comments? I've looked at the current implementation rather carefully, and it shouldn't be that hard to come up with patches that implement this scheme. From Vladimir.Marangozov at inrialpes.fr Wed Jul 19 01:37:09 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 19 Jul 2000 01:37:09 +0200 Subject: [Python-Dev] [Fwd: Python-dev summary: July 1-15] Message-ID: <3974EA25.EF4B86C7@inrialpes.fr> Forgot to cc: the list. Vladimir Marangozov wrote: > > David Bolen wrote: > > > > Andrew Kuchling writes: > > > > > This is a first experiment in whether I can make a useful, > > > interesting, somewhat coherent summary of python-dev activity. > > > If reaction is favorable, and time permits, it may become a biweekly > > > posting. > > > > This seems quite useful - is there any "proper" way to send feedback > > on mail on python-dev without actually being on the list? > > > > Yes. It's the comp.lang.python newsgroup. Pick up an issue, give it > a meaningful subject line (eg. Subject: Re: PEP 201 - Parallel iteration) > and discuss it. Most people on python-dev read the newsgroup regularly > and forward to the python-dev list some of the issues that have been > brought here. So there's feedback from the group to python-dev > and there's a natural selection of the topics that need python-dev's > attention. This "selection" is a matter of experience -- some topics > are recurrent in Python's life and not all posters in c.l.py are aware > that they have been discussed extensively in the past. > > The reverse wasn't true and the python-dev summary documents are intended > to inform a broader audience, notably the Python community, on its > current activities. The natural place for discussing all topics brought > on python-dev is the comp.lang.python newsgroup. This is also the place > where the python-dev members are looking for feedback. For instance, > read the PEP documents -- they summarize recent and past proposals for > various enhancements. All python-dev members are interested in seeing > them discussed by the community. So don't hesitate to take a stance on > a PEP if you think that you could share an educated opinion. > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw at beopen.com Wed Jul 19 01:34:17 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 19:34:17 -0400 (EDT) Subject: [Python-Dev] what happened with the python-list addresses? References: <14708.43013.274067.569324@beluga.mojam.com> Message-ID: <14708.59769.955591.282115@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> I don't want to create a storm on c.l.py, so I post here. I SM> noticed a bunch of "email addresses" that look like SM> "aahz at netcom.com.bbs@openbazaar.net" in recent digests. Is SM> there some sort of runaway gateway? Who is openbazaar.net? SM> Sounds like something ESR would be involved with, though I SM> can't reach an obvious web site in that domain and they appear SM> to be located in Taiwan. No clue from me, unfortunately. Thomas Wouters noticed the same thing and the postmaster identified in the headers has been notified. -Barry From gstein at lyra.org Wed Jul 19 02:26:13 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 17:26:13 -0700 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: <20000718143703.A15498@keymaster.enme.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Tue, Jul 18, 2000 at 02:37:03PM -0600 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> <20000718143703.A15498@keymaster.enme.ucalgary.ca> Message-ID: <20000718172613.I7033@lyra.org> On Tue, Jul 18, 2000 at 02:37:03PM -0600, Neil Schemenauer wrote: > On Tue, Jul 18, 2000 at 10:13:21AM -0400, Andrew Kuchling wrote: > > Can anyone suggest a Windows terminal program that *doesn't* suck dead > > bunnies through a straw? > > I like putty. You can do a google search for it or grab it off my > website: > > http://www.enme.ucalgary.ca/~nascheme/putty.exe > http://www.enme.ucalgary.ca/~nascheme/pscp.exe > http://www.enme.ucalgary.ca/~nascheme/putty.zip > > It's a single exectutable that does telnet, SSH and raw TCP connections > (very nice when your away from home). It sucks much less than the > Windows telnet. Hmm, I wonder if MS was motivated to make logging into > a Unix machine as painful as possible? Well it also sucks when you're trying to connect to a MUD. Has nothing to do with Unix :-) Face it: their telnet just blows chunks... hehe... Cheers, -g -- Greg Stein, http://www.lyra.org/ From alex_c at MIT.EDU Wed Jul 19 02:22:45 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Tue, 18 Jul 2000 20:22:45 -0400 (EDT) Subject: [Python-Dev] PEP 206 - NumPy In-Reply-To: <3974F2C0.F028CE48@schneider-kamp.de> (message from Peter Schneider-Kamp on Wed, 19 Jul 2000 00:13:52 +0000) References: <3974F2C0.F028CE48@schneider-kamp.de> Message-ID: <200007190022.UAA107087@w20-575-115.mit.edu> > BTW: What about kjBuckets and some other modules that have > been proposed? They are not in the PEP. I used to use kjbuckets.kjSet a lot, but when I switched to bleeding-edge python, I decided to try a roll-your-own using python dictionaries because I expected (for no good reason -- I've never looked at the python source for this :) the hashing implementation had improved. I haven't done any formal benchmarking, but for the one application where I decided to do this, that one change made for a tremendous speed up. The class I used instead of kjbuckets.kjSet is at http://puffin.lcs.mit.edu:8080/cgi-bin/cvsweb/mouse/tools/Set.py?rev=1.6&content-type=text/x-cvsweb-markup Alex. From gstein at lyra.org Wed Jul 19 02:48:03 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 17:48:03 -0700 Subject: [Python-Dev] uPEP: encoding directive In-Reply-To: <016501bff10a$d09bc660$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jul 19, 2000 at 12:52:11AM +0200 References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> Message-ID: <20000718174803.L7033@lyra.org> On Wed, Jul 19, 2000 at 12:52:11AM +0200, Fredrik Lundh wrote: >... > as brief as I can make it: Sounds reasonable to me. PEP it, and let's see what the BDFL has to say about the general direction. Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Wed Jul 19 03:09:24 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 18 Jul 2000 21:09:24 -0400 (EDT) Subject: [Python-Dev] posixpath.normpath In-Reply-To: References: Message-ID: <14708.65476.123678.27693@beowolf.beopen.com> Moshe Zadka writes: > Simple question: what should > > a) posixpath.normpath("..") ".." > b) posixpath.normpath("/..") "/" -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Wed Jul 19 03:45:24 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 18 Jul 2000 20:45:24 -0500 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> <14708.40190.852802.966575@beluga.mojam.com> Message-ID: <39750834.B068CA61@prescod.net> Skip Montanaro wrote: > > ... > newlist = map(string.strip, oldlist) > > As far as I'm aware, there's no clean way to do that with string methods. Once we have list comprehensions, there will be: newlist = [for x in oldlist: x.strip()] I think the list-comp version is much more readable and "generic". -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From gmcm at hypernet.com Tue Jul 18 21:11:37 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 18 Jul 2000 15:11:37 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: References: <1248199317-67151042@hypernet.com> Message-ID: <1248148993-1712008@hypernet.com> Moshe wrote: > I disagree: you agree that if you add a pad argument when the > lists are all the same size it doesn't matter (if you don't agree > with this, you don't agree with the PEP). Now, when there is only > one list, the lists are all the same size. QED. I would agree if we were talking about transpose(matrix, [pad]). Then: transpose([(1,2,3)]) -> [(1,), (2,), (3,)] and transpose([(1,), (2,), (3,)]) -> [(1,2,3)] That is, a 3X1 transposes to a 1X3 and vice versa. But zip doesn't take a matrix, it takes some number of sequences. Oh heck, I'll agree anyway. But I dread explaining why 1) it doesn't behave like map(None, [1,2,3]) 2) why zip(((1,2),(3,4))) doesn't yield [(1,3), (2,4)] but [((1,2),), ((3,4),)] instead! So: document zip as taking 2 or more sequences, and throw an exception if fed only one. - Gordon From bwarsaw at beopen.com Wed Jul 19 05:42:53 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:42:53 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> Message-ID: <14709.9149.395757.2952@anthem.concentric.net> >>>>> "Gordo" == Gordon McMillan writes: Gordo> How about a fourth: zip(a) is the same as zip(a, []) ? I don't like it. The way I view zip() is that the length of the elements returned by __getitem__() should always be equal to the number of sequences passed in as parameters. Thus it seems most natural to me that >>> zip((1, 2, 3)) [(1,), (2,), (3,)] >>> zip((1, 2, 3), pad=None) [(1,), (2,), (3,)] When I talk about "special casing", there's two ways to look at it. One possibility is that the implementation of zip has to explicitly check that the number of sequences is 1 and then `do something special' if so. To support Gordon's proposal, or the map()-equivalent, or the raise-an-exception proposal, that would be the case. The second possibility is that user code must `appear' to special case the situation when the number of sequences is exactly 1. I.e. >>> for (i,) in zip((1, 2, 3)): instead of the more natural (because it's less to type and because of the map() heritage): >>> for i in zip((1, 2, 3)): The first example isn't really special casing though. Personally, I think this is going to come up so infrequently that it's not worth it. -Barry From bwarsaw at beopen.com Wed Jul 19 05:44:16 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:44:16 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <1248199317-67151042@hypernet.com> Message-ID: <14709.9232.893964.219712@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I disagree: you agree that if you add a pad argument when the MZ> lists are all the same size it doesn't matter (if you don't MZ> agree with this, you don't agree with the PEP). Now, when MZ> there is only one list, the lists are all the same size. QED. Bingo. -Barry From bwarsaw at beopen.com Wed Jul 19 05:47:32 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:47:32 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <1248248594-64187019@hypernet.com> <200007172311.BAA25445@python.inrialpes.fr> Message-ID: <14709.9428.832622.474548@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> My wish is to add fold() as one of the suggested names in the VM> PEP Done. VM> then let this PEP spend some time in c.l.py. Will do. I just updated the reference implementation. I want to finish going through the comments in this forum and then I'll post to c.l.py. -Barry From bwarsaw at beopen.com Wed Jul 19 05:58:28 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:58:28 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <3973A097.B85D6775@schneider-kamp.de> Message-ID: <14709.10084.225732.826719@anthem.concentric.net> >>>>> "KM" == Ken Manheimer writes: KM> Evan Simpson (a colleague here at digicool, who'd be a good KM> addition to python-dev) noticed that unzip is unnecessary - KM> zip is its own inverse. Only if the sequences are of the same length. I've added this to the PEP, using the extended call syntax. Note that when the sequences are of the same length, zip() is reversible: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> x = zip(a, b) >>> y = zip(*x) # alternatively, apply(zip, x) >>> z = zip(*y) # alternatively, apply(zip, y) >>> x [(1, 4), (2, 5), (3, 6)] >>> y [(1, 2, 3), (4, 5, 6)] >>> z [(1, 4), (2, 5), (3, 6)] >>> x == z 1 It is not possible to reverse zip this way when the sequences are not all the same length. -Barry From bwarsaw at beopen.com Wed Jul 19 05:59:03 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:59:03 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <39743E3A.249212D5@schneider-kamp.de> <011701bff09d$0bc5b020$0900a8c0@SPIFF> Message-ID: <14709.10119.28590.73144@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> Remember the "string join" debate? Yup! FL> -1 on a method. Agreed. -Barry From bwarsaw at beopen.com Wed Jul 19 06:00:17 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 00:00:17 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <14709.10193.715558.561239@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I'm +1 on that. One thing that bugs me is that we're adding a MZ> builtin type. Why not stick with the Python implementation? I've been thinking a little bit about the other generators, especially irange(). I wonder if we shouldn't just be putting zip() and friends in their own Python module and not make them builtins? -Barry From peter at schneider-kamp.de Wed Jul 19 08:17:49 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 06:17:49 +0000 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> Message-ID: <3975480D.29F6A89C@schneider-kamp.de> Fredrik Lundh wrote: > > > -0 on that, I'd rather use snprintf when available, sprintf when not. > > strange argument. why is it okay to crash Python on Windows, > pure SUSv2 platforms, pure ANSI C platforms, etc? I was assuming that most modern systems have a sprintf function available. If this is not the case, my argument is indeed void. I was extrapolating from the fact that it's available on the systems I work on (linux, sunos, solaris). > besides, snprintf doesn't do the same thing as my PyErr_Format > replacement... Yes, but it would by possible to use snprintf in PyErr_Format. +1 on the patch. We cannot neglect Windows (unfortunately). Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From moshez at math.huji.ac.il Wed Jul 19 06:28:00 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 07:28:00 +0300 (IDT) Subject: [Python-Dev] posixpath.normpath In-Reply-To: <20000718220944.ECF41126BD4@oratrix.oratrix.nl> Message-ID: On Wed, 19 Jul 2000, Jack Jansen wrote: > > Recently, Moshe Zadka said: > > Simple question: what should > > > > a) posixpath.normpath("..") > > .. > > What else could it return? > > > b) posixpath.normpath("/..") > > This I'm a bit less sure about. Does anyone remember the Newcastle > Connection a.k.a Unix United? It was a distributed filesystem where > other hosts were reachable through /.. . Think of something analogous > to going from foo.bar.nl to the root of bletch.bar.nl by doing > /../bletch/ . > > The newcastle connection is long dead (at least, I assume it is) but > unless the Posix standard unequivocally specifies that /.. == /. I > think I'd keep it as-is. Reason I'm asking: I don't like the posixpath.normpath patch, and thinking of rewriting it into a competitor. Those two sound reasonable, but I'll wait for more opinions... -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Wed Jul 19 06:32:00 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 07:32:00 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248148993-1712008@hypernet.com> Message-ID: On Tue, 18 Jul 2000, Gordon McMillan wrote: > So: document zip as taking 2 or more sequences, and throw > an exception if fed only one. Agreed: it seems too much ambiguos. I mean, I didn't think it ambiguous, and neither did Gordon and /F -- only each of us saw a different unambiguouity which show it is. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Wed Jul 19 06:37:29 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 07:37:29 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.10193.715558.561239@anthem.concentric.net> Message-ID: On Wed, 19 Jul 2000, Barry A. Warsaw wrote: > >>>>> "MZ" == Moshe Zadka writes: > > MZ> I'm +1 on that. One thing that bugs me is that we're adding a > MZ> builtin type. Why not stick with the Python implementation? > > I've been thinking a little bit about the other generators, especially > irange(). I wonder if we shouldn't just be putting zip() and friends > in their own Python module and not make them builtins? I'm +1. def-irange(seq):-zip(xrange(len(seq)), seq)-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Wed Jul 19 08:02:19 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 08:02:19 +0200 Subject: [Python-Dev] 'shadowing' builtins In-Reply-To: <3974CFEF.C55AC9B@prescod.net>; from paul@prescod.net on Tue, Jul 18, 2000 at 04:45:19PM -0500 References: <20000717200116.P7340@xs4all.nl> <39734E04.C7D29873@prescod.net> <20000718232833.F4283@xs4all.nl> <3974CFEF.C55AC9B@prescod.net> Message-ID: <20000719080218.G4283@xs4all.nl> On Tue, Jul 18, 2000 at 04:45:19PM -0500, Paul Prescod wrote: > Thomas Wouters wrote: > > My first reaction was 'Ack, eek, argh, nonono'. So I decided to sleep over > > it. And my reaction is still 'Ack. eek, argh, nonono' ;) If it's optional, > > like a '-ww' option, sure. But by default ? Please don't. One of python's > > great features is that it's so damned consistent. Having some builtins > > overridable and others not would not only break a lot of code, it would also > > confuse a lot of people. > Most people probably do not even know that the built-in functions can be > shadowed. That's precisely the problem. I don't think that enforcing a > rule that they expect to already be enforced will confuse them. As your > friend pointed out, NOT enforcing the rule confuses them. No. He didn't know the scoping rules, and that was all he was worried about. He was only confused because it didn't generate a warning when he thought it should. Making it impossible to shadow builtins by default would confuse a lot more people, because suddenly they can't use the variable names they want, and they can't figure out why. "list" is a builtin ?? > Using the same word for two different things is more likely to confuse > them than help them. Anyhow, constructor functions and type names need > to be unified (for consistency) and type names and class names need to > be unified (for consistency). And class names start with an upper case > letter. So the need to override list() is scheduled to go away > (eventually!) My code never does that. My code simply does not use 'list'. As for the other style issues, There also wasn't a *need* to override list, it was merely convenience. And Python is a very, very convenient language... let's not change that :P > > Nevertheless, I wouldn't do that in large projects, and that's where I > > invision the '-w' option would be best used. 'This might become a problem'. > It is just as likely a problem in a small project than ina a big one. > The shadowing is local, after all. It isn't a problem that "gets worse" > as the program grows. Actually, no, it depends on where and how you use it. In large programs, my functions get larger too, on average. I'm talking 10 lines -> 100 lines here. Also don't forget the global namespace, which affects a lot more code in large programs. And lastly, small programs are only edited by me, or sometimes quick-fixed by a colleague. Large programs get edited by a fair group of people, over a number of years. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Wed Jul 19 08:13:00 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 08:13:00 +0200 Subject: [Python-Dev] posixpath.normpath In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 18, 2000 at 04:44:01PM +0300 References: Message-ID: <20000719081300.H4283@xs4all.nl> On Tue, Jul 18, 2000 at 04:44:01PM +0300, Moshe Zadka wrote: > a) posixpath.normpath("..") '..'. > b) posixpath.normpath("/..") '/'. I *think* this is POSIXly defined, but I'm not sure. However, this is the behaviour on all UNIX machines I've ever seen, and also in protocols like HTTP that take a URL with forward slashes and possibly '..'s. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Wed Jul 19 08:14:52 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 09:14:52 +0300 (IDT) Subject: [Python-Dev] posixpath.normpath In-Reply-To: <20000719081300.H4283@xs4all.nl> Message-ID: On Wed, 19 Jul 2000, Thomas Wouters wrote: > On Tue, Jul 18, 2000 at 04:44:01PM +0300, Moshe Zadka wrote: > > > a) posixpath.normpath("..") > > '..'. > > > b) posixpath.normpath("/..") > > '/'. I *think* this is POSIXly defined, but I'm not sure. However, this is > the behaviour on all UNIX machines I've ever seen, and also in protocols > like HTTP that take a URL with forward slashes and possibly '..'s. OK. I've posted a patch which corrects posixpath.normpath and competes with 100900. Now Skip gets to decide which of them he likes better... -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From mwh21 at cam.ac.uk Wed Jul 19 08:19:42 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 19 Jul 2000 07:19:42 +0100 Subject: [Python-Dev] what happened with the python-list addresses? In-Reply-To: bwarsaw@beopen.com's message of "Tue, 18 Jul 2000 19:34:17 -0400 (EDT)" References: <14708.43013.274067.569324@beluga.mojam.com> <14708.59769.955591.282115@anthem.concentric.net> Message-ID: bwarsaw at beopen.com (Barry A. Warsaw) writes: > >>>>> "SM" == Skip Montanaro writes: > > SM> I don't want to create a storm on c.l.py, so I post here. I > SM> noticed a bunch of "email addresses" that look like > SM> "aahz at netcom.com.bbs@openbazaar.net" in recent digests. Is > SM> there some sort of runaway gateway? Who is openbazaar.net? > SM> Sounds like something ESR would be involved with, though I > SM> can't reach an obvious web site in that domain and they appear > SM> to be located in Taiwan. > > No clue from me, unfortunately. Thomas Wouters noticed the same thing > and the postmaster identified in the headers has been notified. It's stopped now, it seems; killfiling on Organization: OpenBazaar was an effective stop gap measure. Cheers, M. From mwh21 at cam.ac.uk Wed Jul 19 08:30:54 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 19 Jul 2000 07:30:54 +0100 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: Andrew Kuchling's message of "Tue, 18 Jul 2000 10:13:21 -0400" References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> Message-ID: Andrew Kuchling writes: > Thanks to everyone who made some suggestions. The more minor > edits have been made, but I haven't added any of the threads I missed > because doing a long stretch of Emacs editing in this lame Windows terminal > program will drive me insane, so I just posted the summary to python-list. > > How is it possible for Microsoft to not get a VT100-compatible > terminal program working correctly? VT100s have been around since, > when, the 1970s? Can anyone suggest a Windows terminal program that > *doesn't* suck dead bunnies through a straw? Windows 2000's is (much!) better. Putty is also good; it lives at http://www.chiark.greenend.org.uk/~sgtatham/putty/ Cheers, M. From moshez at math.huji.ac.il Wed Jul 19 08:38:45 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 09:38:45 +0300 (IDT) Subject: [Python-Dev] PEP 206 - NumPy In-Reply-To: <3974F2C0.F028CE48@schneider-kamp.de> Message-ID: On Wed, 19 Jul 2000, Peter Schneider-Kamp wrote: > I know this has probably been discussed many times, but > a) I haven't been around that long and > b) there is a TBD in nondist/peps/pep-206.txt :-] > > What would it take to include NumPy with the "Batteries included" > release of Python? Well, as maintainer of 206, I'd like to answer that: user requests. I haven't done any numeric programming for some time now, so I'm out of touch with this world. I'm planning of preparing 206 for c.l.py discussion this weekend. > BTW: What about kjBuckets and some other modules that have > been proposed? They are not in the PEP. Well, my usual rule is that anyone proposing a new module must do the web research necessary to find out where is the official place to download a known working version from. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gstein at lyra.org Wed Jul 19 08:53:17 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 23:53:17 -0700 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.10193.715558.561239@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 19, 2000 at 12:00:17AM -0400 References: <14707.22821.945571.314619@anthem.concentric.net> <14709.10193.715558.561239@anthem.concentric.net> Message-ID: <20000718235317.A7561@lyra.org> On Wed, Jul 19, 2000 at 12:00:17AM -0400, Barry A. Warsaw wrote: > >>>>> "MZ" == Moshe Zadka writes: > > MZ> I'm +1 on that. One thing that bugs me is that we're adding a > MZ> builtin type. Why not stick with the Python implementation? > > I've been thinking a little bit about the other generators, especially > irange(). I wonder if we shouldn't just be putting zip() and friends > in their own Python module and not make them builtins? Which are you proposing: 1) implement in a Python module. clients use some_module.zip() 2) implement in a Python module. insert into builtins. clients use zip(). ?? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Wed Jul 19 08:55:59 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 23:55:59 -0700 Subject: [Python-Dev] Patches In-Reply-To: <3975480D.29F6A89C@schneider-kamp.de>; from peter@schneider-kamp.de on Wed, Jul 19, 2000 at 06:17:49AM +0000 References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> Message-ID: <20000718235559.B7561@lyra.org> On Wed, Jul 19, 2000 at 06:17:49AM +0000, Peter Schneider-Kamp wrote: > Fredrik Lundh wrote: > > > > > -0 on that, I'd rather use snprintf when available, sprintf when not. Falling back to sprintf() is just untenable. > > strange argument. why is it okay to crash Python on Windows, > > pure SUSv2 platforms, pure ANSI C platforms, etc? > > I was assuming that most modern systems have a sprintf function (I presume you meant snprintf here) Yes, most do, but it isn't quite the same... > available. If this is not the case, my argument is indeed void. > > I was extrapolating from the fact that it's available on the > systems I work on (linux, sunos, solaris). > > > besides, snprintf doesn't do the same thing as my PyErr_Format > > replacement... > > Yes, but it would by possible to use snprintf in PyErr_Format. still not quite the same. /F's PyErr_Format returns an arbitrary length string. snprintf() would be cut at some pre-specified limit. Cheers, -g -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Wed Jul 19 09:42:41 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 19 Jul 2000 09:42:41 +0200 Subject: [Python-Dev] Python-dev summary: Jul 1-15 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> Message-ID: <008001bff156$7b503a00$f2a6b5d4@hagrid> michael hudson: > > How is it possible for Microsoft to not get a VT100-compatible > > terminal program working correctly? VT100s have been around since, > > when, the 1970s? Can anyone suggest a Windows terminal program that > > *doesn't* suck dead bunnies through a straw? > > Windows 2000's is (much!) better. much better, but still not good enough. fwiw, I'm using CRT ($35, big deal), which is about as good as it can get: http://www.vandyke.com/products/crt/ From tim_one at email.msn.com Wed Jul 19 07:12:11 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 19 Jul 2000 01:12:11 -0400 Subject: [Python-Dev] RE: Discussion: Introducing new operators for matrix computation In-Reply-To: Message-ID: Sleeping in the same room with Guido for a night did not make it easier to channel him, but it did make it easier to cloud his mind: Guido is not opposed to adding new operator symbols to core Python. As of breakfast Tuesday, anyway, and there are witnesses, so he'll have trouble changing his mind (well, it will be clumsy for him to *admit* it if he changes his mind ...). But but but (you knew it wouldn't be *that* easy!): + Everybody concerned that new operators are "not Pythonic" please swallow it -- it is Pythonic, cuz Guido said it is <0.9 wink -- but see following points too>. Contribute by helping to come up with a complete and Pythonically beautiful implementation instead. + Please keep this off of Python-Dev. Doesn't belong there (at least not yet). Interested parties can form a mailing list, or try to discuss it on comp.lang.python (my personal hope is that you try the latter, and stick to one Subject line). + There *must* be a PEP for this. Guido won't read any more of the debate -- it's too voluminous, repetitive and contentious. He'll eventually read a PEP, though, *after* some sort of consensus is reached. A PEP requires a champion. I hope Huaiyu Zhu volunteers for this, as he's argued his case eloquently and rationally. The champion doesn't need to know how to implement it, but does need to summarize sometimes-opposing positions dispassionately. + There are things Guido will & won't tolerate. Guessing which is an interesting & educational challenge . For example, adding a new operator like .+ is fine, as the maximal-munch rule for lexing can resolve formal ambiguities easily. OTOH, *any* new operator symbol containing a backslash is dead before arrival -- backslash has purely "meta" meanings in Python today. If the goal is to make Python look exactly like some other language, forget it. It's still Python, with some light syntactic sugar to make life in special domains sweeter. + This one is from me, but it's a safe bet you can view at as precognitive channeling if you oppose it: anyone suggesting to, e.g., make ".+" mean something new and exciting for ints or floats or strings or ... will be shot. There are probably no operations on the builtin types used frequently enough to merit new syntactic shorthands (excepting, perhaps, that if P3K changes the meaning of integer division, a new "//" operator for flooring division was looked upon kindly in the past). The new operators are for convenience in special domains (where the case for them is indeed very strong), not an excuse to turn current Python into a cryptic mess. + Also from me: forget about user-defined precedence and associativity. The PEP must define these once & for all, and that's that. + The set of new operator symbols cannot be open-ended (as it is in, e.g., Haskell). There are at least 4 variants of Python tranlators already in existence, and Guido wants the set of operator symbols fixed so that a variety of parsing techniques can be used in their natural forms without trickery. IOW, the full set of operator symbols must-- as it is today --be a fixed finite set known in advance. + If the numerical folk can't reach consensus on the set of operators and what they should mean, my bet is that Guido will let this die rather than get sucked into Pronouncing on each of the points in dispute. After all, he has little personal use for this stuff: if the people who *do* want it can't agree, it's not worth having. how's-that-for-a-mysterious-announcement?-ly y'rs - tim From tim_one at email.msn.com Wed Jul 19 07:12:14 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 19 Jul 2000 01:12:14 -0400 Subject: [Python-Dev] Patches In-Reply-To: <14708.26423.536040.581684@beluga.mojam.com> Message-ID: [Skip Montanaro] > As someone who has been assigned some patches that are still open (isatty, > normpath fix, history functions for readline), I'm still pretty > much in the dark about what my rights and responsibilities are. You have responsibility for keeping Python in perfect condition, and the right to be as confused as you like . > Am I supposed to eyeball a patch and check it in if it looks okay > (compiles, doesn't break "make test", etc)? Am I supposed to bring > it up for discussion on python-dev? Something entirely different > (blow up a bush, perhaps)? You're responsible for "taking the next step". What that step is depends on *your* good judgment: if you feel confident that the patch is fine, sure, check it in and close it. If you're confident that the patch sucks, reject it, explain why in a comment, and assign it back to the submitter. If you're uncertain, do neither of those: bring it up on Python-Dev, or if you think you know who *can* resolve your uncertainties, make a comment and assign it to them. > I just submitted a feature request for the patch manager at SF. > I asked for the following: > > 1. better selection/exclusion predicates for the filtering function > 2. filtering based on assignee/submitter > 3. display of a patch's state in the table > > If you'd like to review it and add your own two cents, it's at > > https://sourceforge.net/forum/message.php?msg_id=41288 We (PythonLabs) met with three of the Source Forge developers late Tuesday afternoon. They're perfectly reasonable and perfectly overburdened too. The one & only thing we got them to promise to implement Real Soon Now is a new checkbox on the Project Admin page, saying to send *all* patch email to the patches email address. By itself, this doesn't help anything. What it does do is enable *us* to build on the SF patch pages via automated "screen scraper" programs. Ka-Ping Yee wrote one of those but didn't post it here, to generate *useful* email when a msg from SourceForge tickles it. Jeremy Hylton posted a program here to scrape the SF pages and download the info into a local database. We can build better display and filtering tools (likely cmdline) ourselves on top of these. The SF people would be happy to too, but they appear not to have the bandwidth for it now. forthrightly y'rs - tim From python at horizon.com Wed Jul 19 10:22:40 2000 From: python at horizon.com (python at horizon.com) Date: 19 Jul 2000 08:22:40 -0000 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] Message-ID: <20000719082240.17706.qmail@science.horizon.com> ESR was kind enough to suggest that this idea was worthy of a larger audience, so here is my Very Humble Opinion Indeed... (My knowledge of Python is limited to buying the O'Reilly book and meaning to read it one of these days, so I may be missing something REALLY elementary here.) But if you want extensible infix operators without burdening people trying to read the code too much, consider this: For each existing operator #, there is an infinite family of user-definable operators @#, @@#, etc. These get progressivley less readable, so I don't think you'd *want* to go past @@, but hey, it's there if you want. Each one has the same precedence and associativity as the bare operator #, so there are no new rules for anyone to learn. "a @* b * c @@* d" would associate to the left as usual, producing "((a @* b) * c) @@* d". You should probably extend this to unary operators, so someone could, for example, define unary @- to be complex conjugate. An alternative precednece rule would put * > @* > @@* > ... > + > @+ > ..., which also avoids requiring people to learn much of anything new, but I think people trying to write parsers would object strenuously to an infinite number of precedence levels. You need some way to define all of these functions, but I assume that's just a Small Matter of Programming for the uber-studly programmers here, leaping from tree to tree in the mighty forests of British Columbia... Oh wait a minute, I'm sorry. That's just getting silly. A language I worked on a Long Time Ago used backquotes to turn operators into normal functions so a + b was `+`(a,b), and the syntax was also used when defining such functions, but I'm sure Python has some existing scheme for referring to built-in operators that could be extended. Anyway, just food for thought. (If that isn't enough extra operators, you can also add *@. And then even @*@. @@*@ and @*@@ are for the terminally masochistic, and anyone who'd go beyond that should be kept away from computers and sharp objects until they're feeling better.) "Better get a bu.}}}}NO CARRIER From jack at oratrix.nl Wed Jul 19 10:37:26 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 19 Jul 2000 10:37:26 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/sf-html sf-faq.html,1.4,1.5 In-Reply-To: Message by Peter Schneider-Kamp , Tue, 18 Jul 2000 14:43:26 -0700 , <200007182143.OAA02155@slayer.i.sourceforge.net> Message-ID: <20000719083726.9343137186E@snelboot.oratrix.nl> Peter, could you add a Macintosh section saying that it's currently quite impossible to use cvs over ssh, at least: as far as we know, and that any reports of getting it to work and/or pointers to more info would be appreciated? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From effbot at telia.com Wed Jul 19 10:55:41 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 19 Jul 2000 10:55:41 +0200 Subject: [Python-Dev] RE: Discussion: Introducing new operators for matrix computation References: Message-ID: <018301bff15f$1f1acb20$f2a6b5d4@hagrid> tim wrote: > + There are things Guido will & won't tolerate. Guessing which is an > interesting & educational challenge . For example, adding a new > operator like > > .+ > > is fine, as the maximal-munch rule for lexing can resolve formal ambiguities > easily. Only if you're thinking as a compiler... ;-) Besides, the proposed way to resolve "3.+x" means that the meaning of an operator would change depending on the preceeding operand (and the other way around). Sure sounds like Perl to me... > This one is from me, but it's a safe bet you can view at as precognitive > channeling if you oppose it: anyone suggesting to, e.g., make ".+" mean > something new and exciting for ints or floats or strings Why not strings? As Perl has showed, *everyone* is doing string processing. If we're gonna add stuff, why not cater to the masses? For a start, how about: match = string .~ pattern I'm sure we can do something fun with ?, the sre scanner, and list comprehensions too... > There are at least 4 variants of Python translators Fwiw, a recent sunworld article says six. And don't forget syntax checking development environments (afaik, at least two of them does that, or will in a near future). > Please keep this off of Python-Dev. Okay, okay. Last time I tried to say that, everyone shouted at me. On the other hand, now that Python has dropped from spot 10 down to 15 on the sourceforge top activity list, it's about time python-dev went back to actually doing things, instead of just talking about what could be done... ;-) From thomas at xs4all.net Wed Jul 19 13:25:55 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 13:25:55 +0200 Subject: [Python-Dev] ANSIfication ? Message-ID: <20000719132554.B9897@xs4all.nl> Is there any particular reason the ANSIfication stopped before it reached Python/, other than time issues ? If not, good, because I'm busy ANSIfying that directory ;) I'll post some patches later today, except for ceval.c and compile.c: the work I'm doing is relative to the range-literal patch, so I'm gonna wait until that one's accepted before uploading those ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From peter at schneider-kamp.de Wed Jul 19 15:43:47 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 13:43:47 +0000 Subject: [Python-Dev] ANSIfication ? References: <20000719132554.B9897@xs4all.nl> Message-ID: <3975B093.C2F125BD@schneider-kamp.de> Thomas Wouters wrote: > > Is there any particular reason the ANSIfication stopped before it reached > Python/, other than time issues ? If not, good, because I'm busy ANSIfying I don't think so. After ANSIfying the whole Module/ directory I was fed up. I'd guess the same applies to Fred who slaved away in Objects/ ... Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From bwarsaw at beopen.com Wed Jul 19 14:29:53 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 08:29:53 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <14709.10193.715558.561239@anthem.concentric.net> <20000718235317.A7561@lyra.org> Message-ID: <14709.40769.935694.167265@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: >> other generators, especially irange(). I wonder if we >> shouldn't just be putting zip() and friends in their own Python >> module and not make them builtins? GS> Which are you proposing: GS> 1) implement in a Python module. clients use some_module.zip() Yes. GS> 2) implement in a Python module. insert into builtins. clients GS> use zip(). No. -Barry From bwarsaw at beopen.com Wed Jul 19 14:50:56 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 08:50:56 -0400 (EDT) Subject: [Python-Dev] RE: Discussion: Introducing new operators for matrix computation References: Message-ID: <14709.42032.689117.684055@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> + There *must* be a PEP for this. There already is: PEP 211, Adding New Operators to Python. And it's been assigned to Greg Wilson, although he may want to re-assign it. It's currently just boilerplate. -Barry From alex_c at MIT.EDU Wed Jul 19 15:36:59 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Wed, 19 Jul 2000 09:36:59 -0400 (EDT) Subject: [Python-Dev] posixpath.normpath In-Reply-To: (message from Moshe Zadka on Wed, 19 Jul 2000 07:28:00 +0300 (IDT)) References: Message-ID: <200007191336.JAA18516@nerd-xing.mit.edu> FWIW, I vote for Moshe's patch. Alex. From paul at prescod.net Wed Jul 19 02:37:29 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 18 Jul 2000 19:37:29 -0500 Subject: [Python-Dev] PEP 204 - Range Literals References: <20000718121831.A7340@xs4all.nl> Message-ID: <3974F849.A83AC7CB@prescod.net> Should range literals create a list of the passed-in type ? It might be desirable in the cases of other builtin types, such as longs and strings: >>> [ 1L : 2L<<64 : 2<<32L ] >>> ["a":"z":"b"] >>> ["a":"z":2] However, this might be too much `magic' to be obvious. Well the step argument is of debatable utility for strings but ["0":"9"] seems mildly useful. Also, it makes sense to create a range of floating point numbers. If we were going to do this, we would probably have an overloadable operator: string.__range__( start=None, end=None, step=None ) It could return a sequence of whatever kind. I'm not clear why we can't implement it as a function call to __builtins__.range . -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From thomas at xs4all.net Wed Jul 19 14:55:28 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 14:55:28 +0200 Subject: [Python-Dev] HAVE_STDARG_PROTOTYPES Message-ID: <20000719145528.C9897@xs4all.nl> I'm currently assuming HAVE_STDARG_PROTOTYPES, as defined by configure comes implicitly with ANSI C compilers. (It defines the way to handle variable-argument functions, and I think the '...' method is standard ANSI C. Please correct me if I'm wrong.) However, I'm not sure what the ANSI standard says on the subject of va_list: there is a define that checks whether va_list is an array of some sort, or not. Is that K&R-C compatibility we can throw out, or should I keep it ? (it's not that much, so I'm keeping it for now.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Wed Jul 19 16:39:50 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 16:39:50 +0200 Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <3974F849.A83AC7CB@prescod.net>; from paul@prescod.net on Tue, Jul 18, 2000 at 07:37:29PM -0500 References: <20000718121831.A7340@xs4all.nl> <3974F849.A83AC7CB@prescod.net> Message-ID: <20000719163950.D9897@xs4all.nl> On Tue, Jul 18, 2000 at 07:37:29PM -0500, Paul Prescod wrote: > I'm not clear why we can't implement it as a function call to > __builtins__.range . I did that mostly because of the error messages. Giving the range() error messages when using [1:100] is a bit confusing. Can't think of any other reason, though. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Wed Jul 19 17:43:13 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 19 Jul 2000 10:43:13 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_openpty.py,1.1,1.2 test_pty.py,1.2,1.3 In-Reply-To: <200007191451.HAA13863@slayer.i.sourceforge.net> References: <200007191451.HAA13863@slayer.i.sourceforge.net> Message-ID: <14709.52369.695950.390400@beluga.mojam.com> Thomas, Thanks for ANSIfying isatty and uncommenting it isatty tests. I had uncommented the tests here, but forgot to check them in... Skip From paul at prescod.net Wed Jul 19 18:09:05 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 11:09:05 -0500 Subject: [Python-Dev] uPEP: encoding directive References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> Message-ID: <3975D2A1.5DDA10E6@prescod.net> I'd prefer if you would separate out the compile directives PEP from the encoding PEP. I'm +1 on compiler directives. I'm -0 on literal encodings. It seems like more effort than is necessary. If we're going to restrict people to ASCII-like encodings, we could just restrict them to ASCII and get it over with. Also, I don't like that the default mode is non-portable. The default should be ASCII. Yes, this could cause backwards-compatibility problems. Maybe problems should be reported with warning. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul at prescod.net Wed Jul 19 18:09:45 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 11:09:45 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> Message-ID: <3975D2C9.66FE16C2@prescod.net> "Barry A. Warsaw" wrote: > >... > > > The second possibility is that user code must `appear' to special case > the situation when the number of sequences is exactly 1. I.e. > > >>> for (i,) in zip((1, 2, 3)): > > instead of the more natural (because it's less to type and because of > the map() heritage): > > >>> for i in zip((1, 2, 3)): Why are you using zip in this case? If you *know* that you are going to get back 1-tuples then you must know that the input is a single list (i.e. you aren't using "apply"). So why are you using zip at all? -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul at prescod.net Wed Jul 19 18:10:34 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 11:10:34 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <14709.10193.715558.561239@anthem.concentric.net> Message-ID: <3975D2FA.74795C3@prescod.net> "Barry A. Warsaw" wrote: > > ... > > I've been thinking a little bit about the other generators, especially > irange(). I wonder if we shouldn't just be putting zip() and friends > in their own Python module and not make them builtins? I prefer builtins (or in some cases methods) for this type of slice and dice functionality. It's not related to some particular datatype or domain. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul at prescod.net Wed Jul 19 18:11:39 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 11:11:39 -0500 Subject: [Python-Dev] PEP 204 - Range Literals References: <20000718121831.A7340@xs4all.nl> Message-ID: <3975D33B.6F4F0C8C@prescod.net> Should range literals create a list of the passed-in type ? It might be desirable in the cases of other builtin types, such as longs and strings: >>> [ 1L : 2L<<64 : 2<<32L ] >>> ["a":"z":"b"] >>> ["a":"z":2] However, this might be too much `magic' to be obvious. Well the step argument is of debatable utility for strings but ["0":"9"] seems mildly useful. Also, it makes sense to create a range of floating point numbers. If we were going to do this, we would probably have an overloadable operator: string.__range__( start=None, end=None, step=None ) It could return a sequence of whatever kind. I'm not clear why we can't implement it as a function call to __builtins__.range . -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From ping at lfw.org Wed Jul 19 18:46:39 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 19 Jul 2000 09:46:39 -0700 (PDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.10193.715558.561239@anthem.concentric.net> Message-ID: On Wed, 19 Jul 2000, Barry A. Warsaw wrote: > > I've been thinking a little bit about the other generators, especially > irange(). I wonder if we shouldn't just be putting zip() and friends > in their own Python module and not make them builtins? I'd say put both zip() and irange() in builtins. They're useful enough. (Ideally range(), zip(), and irange() would all make generators one day, and xrange() could be deprecated.) I would prefer zip() and irange() to make generators now -- because this means you could *pass* them generators, and they wouldn't force their arguments to enumerate everything first! For example, make readlines() a generator too and you've got for lnum, line in irange(file.readlines()): print "%5d: %s" % (lnum, line), How pretty is that? There's no issue with using generators in place of lists, as far as i can tell, since (as has already been suggested) you just turn the generator into a real list if somebody calls one of the methods on it or uses it where a tuple is expected. -- ?!ng From ping at lfw.org Wed Jul 19 18:58:56 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 19 Jul 2000 09:58:56 -0700 (PDT) Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <3974F849.A83AC7CB@prescod.net> Message-ID: On Tue, 18 Jul 2000, Paul Prescod wrote: > Should range literals create a list of the passed-in type ? It > might be desirable in the cases of other builtin types, such as > longs and strings: > > >>> [ 1L : 2L<<64 : 2<<32L ] > >>> ["a":"z":"b"] > >>> ["a":"z":2] > > However, this might be too much `magic' to be obvious. Too much magic. Remember the analogy is with the slice operator: lst[start:end]. Only integers work there, and only integers are acceptable to range() now, so it's simpler and happier all around to keep the range literals to just integers too. > Well the step argument is of debatable utility for strings but ["0":"9"] > seems mildly useful. Also, it makes sense to create a range of floating > point numbers. Not useful enough, i think, to be worth it. If you need to do a range check, you can still say "a" <= x <= "z". When working with ranges or regions on the number line, you probably want something more specifically designed for that. (For example, you might want to talk about open, closed, or half-open intervals.) If we're going to consider the feature, E's CoordinateSpaces and Regions are worth a serious look. Hmm. I don't have a good reference on that. I'll post one when i find it. -- ?!ng From moshez at math.huji.ac.il Wed Jul 19 18:56:51 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 19:56:51 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: Message-ID: On Wed, 19 Jul 2000, Ka-Ping Yee wrote: > On Wed, 19 Jul 2000, Barry A. Warsaw wrote: > > > > I've been thinking a little bit about the other generators, especially > > irange(). I wonder if we shouldn't just be putting zip() and friends > > in their own Python module and not make them builtins? > > I'd say put both zip() and irange() in builtins. They're useful enough. One of the things I love about Python is the clean namespaces. Each builtin function takes away some of the cleanliness. It's a tradeof, but I think we should be wary of tossing stuff into builtins just because we can't find a good place for them. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Wed Jul 19 19:15:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 19 Jul 2000 19:15:23 +0200 Subject: [Python-Dev] uPEP: encoding directive References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> <3975D2A1.5DDA10E6@prescod.net> Message-ID: <001801bff1a4$ed941a20$f2a6b5d4@hagrid> paul wrote: > If we're going to restrict people to ASCII-like encodings, we > could just restrict them to ASCII and get it over with. Sorry, you lost me there... in what part(s) of the source file should we restrict users to pure ASCII? (in string literals? unicode string literals? the entire script?) From peter at schneider-kamp.de Wed Jul 19 21:27:37 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 19:27:37 +0000 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> Message-ID: <39760129.9BA42B7E@schneider-kamp.de> Bjorn Pettersen wrote: > > I think the PEPs are a great idea, but it would be even better if they > were more accessible... How about putting them up on the beopen or > python.org site? (That way the faq can refer to them for recurring > discussions with all the arguments archived in the PEP...) How about putting them on sourceforge? python.sourceforge.net/peps/pep-0206.txt and friends What do you think? Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul at prescod.net Wed Jul 19 19:32:38 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 12:32:38 -0500 Subject: [Python-Dev] uPEP: encoding directive References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> <3975D2A1.5DDA10E6@prescod.net> <001801bff1a4$ed941a20$f2a6b5d4@hagrid> Message-ID: <3975E636.4FCF61ED@prescod.net> Fredrik Lundh wrote: > > paul wrote: > > If we're going to restrict people to ASCII-like encodings, we > > could just restrict them to ASCII and get it over with. > > Sorry, you lost me there... in what part(s) of the source file > should we restrict users to pure ASCII? > > (in string literals? unicode string literals? the entire script?) The entire script. If we're going to require a Japanse user to use 3 bytes to encode some character then we might as well require them to use backslash syntax. I mean if we're going to be revolutionary, then we could take the XML route. * require the encoding pragma to be the first line * auto-detect one-byte, two-byte based on #? * figure out precise encoding from directive Otherwise, I'm not sure if we're making enough progress. Westerners probably won't bother to put in the directive as long as their code works fine without it. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul at prescod.net Wed Jul 19 19:36:10 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 12:36:10 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: Message-ID: <3975E70A.F9F8BE42@prescod.net> Moshe Zadka wrote: > > ... > > One of the things I love about Python is the clean namespaces. Each > builtin function takes away some of the cleanliness. It's a tradeof, but I > think we should be wary of tossing stuff into builtins just because we > can't find a good place for them. I feel the same way, but I hate importing basic functionality necessary for every single script, no matter what the domain. I wish there weren't so many exceptions directly in builtins. They should go in a sub-module __builtins__.exceptions . -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From effbot at telia.com Wed Jul 19 19:45:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 19 Jul 2000 19:45:23 +0200 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> Message-ID: <00b801bff1a9$248f4780$f2a6b5d4@hagrid> greg wrote: > > Yes, but it would by possible to use snprintf in PyErr_Format. > > still not quite the same. /F's PyErr_Format returns an arbitrary length > string. snprintf() would be cut at some pre-specified limit. if I understood GvR correctly, the only remaining issue here is whether we need more formatting codes (PyErr_Format is undocumented, so I'm not sure we need to be backwards compatible with code outside the interpreter...) in an earlier post, I suggested adding a couple of PyErr_Format- specific formatting codes: possibly stupid idea: would it make sense to add custom formatting codes, like: %S => char*, string, clip if excessively long %T => PyObject*, show name of type, clip if excessively long where "clip" means: truncate at 80 characters, and add "..." to indicate that the string was truncated. this covers most of the places where %.\d+s are used (in the Python core, at least...) comments? From bwarsaw at beopen.com Wed Jul 19 20:46:13 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 14:46:13 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> <3975D2C9.66FE16C2@prescod.net> Message-ID: <14709.63349.415183.336374@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Why are you using zip in this case? If you *know* that you are PP> going to get back 1-tuples then you must know that the input PP> is a single list (i.e. you aren't using "apply"). So why are PP> you using zip at all? It was just an example, but I agree, you probably wouldn't use zip in this situation. My question is, why would you ever use zip with one parameter? To me, that's an argument for letting zip(a) return 1-tuples, not raising an exception. -Barry From bwarsaw at beopen.com Wed Jul 19 20:48:20 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 14:48:20 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14709.10193.715558.561239@anthem.concentric.net> Message-ID: <14709.63476.37009.258626@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> (Ideally range(), zip(), and irange() would all make KY> generators one day, and xrange() could be deprecated.) I agree! So maybe what we need is a general generator type written in C. Could the xrange type be subverted to this purpose? -Barry From thomas at xs4all.net Wed Jul 19 21:13:06 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 21:13:06 +0200 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <39760129.9BA42B7E@schneider-kamp.de>; from peter@schneider-kamp.de on Wed, Jul 19, 2000 at 07:27:37PM +0000 References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> Message-ID: <20000719211306.F9897@xs4all.nl> On Wed, Jul 19, 2000 at 07:27:37PM +0000, Peter Schneider-Kamp wrote: > Bjorn Pettersen wrote: > > I think the PEPs are a great idea, but it would be even better if they > > were more accessible... How about putting them up on the beopen or > > python.org site? (That way the faq can refer to them for recurring > > discussions with all the arguments archived in the PEP...) > How about putting them on sourceforge? > python.sourceforge.net/peps/pep-0206.txt and friends +1 if we can do it automatically. +0 if it has to be done by whoever commits new versions ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Wed Jul 19 21:17:37 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 21:17:37 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.63476.37009.258626@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 19, 2000 at 02:48:20PM -0400 References: <14709.10193.715558.561239@anthem.concentric.net> <14709.63476.37009.258626@anthem.concentric.net> Message-ID: <20000719211736.G9897@xs4all.nl> On Wed, Jul 19, 2000 at 02:48:20PM -0400, Barry A. Warsaw wrote: > >>>>> "KY" == Ka-Ping Yee writes: > KY> (Ideally range(), zip(), and irange() would all make > KY> generators one day, and xrange() could be deprecated.) > I agree! So maybe what we need is a general generator type written in > C. Could the xrange type be subverted to this purpose? Not likely. You'd have to write the assignment functions (changing the object into a list-type if that is done) and most of the other stuff has to be rewritten: almost all of xrange() is specific for PyInt's. It stores step, start, end and repeater (for 'xrange * 10') as longs, and calculates return values for getitem and repr and the like from those. Other than a standard object boilerplate, it's pretty useless for more generic generators. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Wed Jul 19 21:47:42 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 14:47:42 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> <3975D2C9.66FE16C2@prescod.net> <14709.63349.415183.336374@anthem.concentric.net> Message-ID: <397605DE.C0DF661C@prescod.net> Barry A. Warsaw" wrote: >... > > It was just an example, but I agree, you probably wouldn't use zip in > this situation. My question is, why would you ever use zip with one > parameter? To me, that's an argument for letting zip(a) return > 1-tuples, not raising an exception. Your logic is impeccable. Also, consider this: zip( "mybigfile.xml" ) -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From bwarsaw at beopen.com Wed Jul 19 22:12:57 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 16:12:57 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14709.10193.715558.561239@anthem.concentric.net> <14709.63476.37009.258626@anthem.concentric.net> <20000719211736.G9897@xs4all.nl> Message-ID: <14710.3017.560649.169558@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> Other than a standard object boilerplate, it's pretty useless TW> for more generic generators. Urg. Oh well. From bwarsaw at beopen.com Wed Jul 19 22:14:59 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 16:14:59 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> <3975D2C9.66FE16C2@prescod.net> <14709.63349.415183.336374@anthem.concentric.net> <397605DE.C0DF661C@prescod.net> Message-ID: <14710.3139.869652.473413@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> zip( "mybigfile.xml" ) Newbie: "Why doesn't this compress my file for me?" Paul: "!" :) -Barry From thomas at xs4all.net Wed Jul 19 22:24:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 22:24:08 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <397605DE.C0DF661C@prescod.net>; from paul@prescod.net on Wed, Jul 19, 2000 at 02:47:42PM -0500 References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> <3975D2C9.66FE16C2@prescod.net> <14709.63349.415183.336374@anthem.concentric.net> <397605DE.C0DF661C@prescod.net> Message-ID: <20000719222408.L9897@xs4all.nl> On Wed, Jul 19, 2000 at 02:47:42PM -0500, Paul Prescod wrote: > Also, consider this: > zip( "mybigfile.xml" ) That's kinda like 'dir()', isn't it ? "I don't have those files in my directory!!?" Nevertheless, yet another reason to use marry() No confusion there! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Wed Jul 19 22:40:16 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 23:40:16 +0300 (IDT) Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) In-Reply-To: <00b801bff1a9$248f4780$f2a6b5d4@hagrid> Message-ID: On Wed, 19 Jul 2000, Fredrik Lundh wrote: > possibly stupid idea: would it make sense to add custom > formatting codes, like: > > %S => char*, string, clip if excessively long > %T => PyObject*, show name of type, clip if excessively long > > where "clip" means: > > truncate at 80 characters, and add "..." to indicate > that the string was truncated. I'm +0 on those. Seems like useful things. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Wed Jul 19 22:47:41 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 23:47:41 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.63349.415183.336374@anthem.concentric.net> Message-ID: On Wed, 19 Jul 2000, Barry A. Warsaw wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> Why are you using zip in this case? If you *know* that you are > PP> going to get back 1-tuples then you must know that the input > PP> is a single list (i.e. you aren't using "apply"). So why are > PP> you using zip at all? > > It was just an example, but I agree, you probably wouldn't use zip in > this situation. My question is, why would you ever use zip with one > parameter? Or, in other words, anyone using zip() with one parameter is plain nuts or made a bug. > To me, that's an argument for letting zip(a) return > 1-tuples, not raising an exception. I fail to see the logic. To me, that points at the exception route: if it's probably a bug, yell loudly. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Wed Jul 19 22:49:55 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 22:49:55 +0200 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) In-Reply-To: <00b801bff1a9$248f4780$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jul 19, 2000 at 07:45:23PM +0200 References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> Message-ID: <20000719224955.M9897@xs4all.nl> On Wed, Jul 19, 2000 at 07:45:23PM +0200, Fredrik Lundh wrote: > possibly stupid idea: would it make sense to add custom > formatting codes, like: > > %S => char*, string, clip if excessively long > %T => PyObject*, show name of type, clip if excessively long > > where "clip" means: > > truncate at 80 characters, and add "..." to indicate > that the string was truncated. > > this covers most of the places where %.\d+s are used (in > the Python core, at least...) +0, but I haven't enough experience with this kind of thing to have a real opinion. I guess it's better than nothing ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw at beopen.com Wed Jul 19 23:10:34 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 17:10:34 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14709.63349.415183.336374@anthem.concentric.net> Message-ID: <14710.6474.635823.308717@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I fail to see the logic. To me, that points at the exception MZ> route: if it's probably a bug, yell loudly. Hmm, thinking about the ambiguity your brought up with zip-with-no-args, which I agree with more than zip-with-one-arg, I might be willing to concede the exception for anything less than 2 sequences provided. At the very least, I will work this into the PEP so Guido can rule by (informed) decree. -Barry From jack at oratrix.nl Thu Jul 20 00:03:19 2000 From: jack at oratrix.nl (Jack Jansen) Date: Thu, 20 Jul 2000 00:03:19 +0200 Subject: [Python-Dev] PyArg_ParseTuple format specifiers again Message-ID: <20000719220324.73E3E191AA8@oratrix.oratrix.nl> Of course, after I added the H specifier to PyArg_ParseTuple it turns out that solved ninetysomething% of my problems, but it turns out that what I really need is not an "unsigned short" converter but a "16 bit" converter, i.e. something that will happily accept anything from -32768 to 65535 without complaints. (The old "h" format, in other words). I need this because all the MacOS API modules are machine generated, both the C modules and the .py files with all the constants in it, and some header file authors use -1 to mean "16 1 bits", some use 0xffff. And I really don't want to hand-massage 40K lines of C and 6K lines of Python everytime a new MacOS release comes out.... And I also need such a format char for 8 bit values. Does anyone mind if I change the H specifier to do no value checking other than making sure it fits in 16 bits, and add a B specifier for unchecked bytes? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From paul at prescod.net Thu Jul 20 00:53:42 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 17:53:42 -0500 Subject: [Python-Dev] Perl rewrite Message-ID: <39763176.47254BEF@prescod.net> Interesting.... http://www.perl.org/ http://slashdot.org/article.pl?sid=00/07/19/203221&mode=nested -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From petrilli at amber.org Thu Jul 20 02:41:58 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Wed, 19 Jul 2000 20:41:58 -0400 Subject: [Python-Dev] Perl rewrite In-Reply-To: <39763176.47254BEF@prescod.net>; from paul@prescod.net on Wed, Jul 19, 2000 at 05:53:42PM -0500 References: <39763176.47254BEF@prescod.net> Message-ID: <20000719204158.A20244@trump.amber.org> Paul Prescod [paul at prescod.net] wrote: > Interesting.... > > http://www.perl.org/ > http://slashdot.org/article.pl?sid=00/07/19/203221&mode=nested I must say that Larry Wall's "keynote" was um... interesting. :-) Perhaps Guido will summarize it :-) Chris -- | Christopher Petrilli | petrilli at amber.org From paul at prescod.net Thu Jul 20 03:06:47 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 20:06:47 -0500 Subject: [Python-Dev] Perl rewrite References: <39763176.47254BEF@prescod.net> <20000719204158.A20244@trump.amber.org> Message-ID: <397650A7.9A32E3B@prescod.net> Christopher Petrilli wrote: > >... > > I must say that Larry Wall's "keynote" was um... interesting. :-) > Perhaps Guido will summarize it :-) Then we'll have to wait a week! What are the high points? -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From petrilli at amber.org Thu Jul 20 08:20:06 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Thu, 20 Jul 2000 02:20:06 -0400 Subject: [Python-Dev] Perl rewrite In-Reply-To: <397650A7.9A32E3B@prescod.net>; from paul@prescod.net on Wed, Jul 19, 2000 at 08:06:47PM -0500 References: <39763176.47254BEF@prescod.net> <20000719204158.A20244@trump.amber.org> <397650A7.9A32E3B@prescod.net> Message-ID: <20000720022005.B20244@trump.amber.org> Paul Prescod [paul at prescod.net] wrote: > Christopher Petrilli wrote: > > > >... > > > > I must say that Larry Wall's "keynote" was um... interesting. :-) > > Perhaps Guido will summarize it :-) > > Then we'll have to wait a week! What are the high points? He knows how to snap, and beat sticks together... :-) Chris -- | Christopher Petrilli | petrilli at amber.org From paul at prescod.net Thu Jul 20 08:35:28 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 01:35:28 -0500 Subject: [Python-Dev] PEP-able Message-ID: <39769DB0.BCE7FB38@prescod.net> PEP: ??? Title: Computed Attributes Version: $Revision: 1.0 $ Owner: paul at prescod.net Python-Version: 2.0 Status: Incomplete Introduction This PEP describes a feature to make it easier to use Python attribute set/get/del syntax to fetch the results of a computation or to invoke computation. This feature has been emulated using __getattr__/__setattr__/__delattr__ but this approach suffers severe usability and performance concerns. Syntax Special methods should declare themselves with declarations of the following form: class x: def __get_foo__(self ): ... def __set_foo__(self, value ): ... def __del_foo__(self ): ... They are used like this: fooval=x.foo x.foo=fooval+5 del x.foo Semantics References of the sort x.y should be taken, if x is an instance type of a class with a __get_y__ method as being equivalent to a call to that method. Code that assigns to y should instead call __set_y__ if that method is defined on x's class. Code that deletes x.y should call __del_y__ if that method is defined on x's class. It is disallowed to actually have an attribute named y in the dictionary for reasons that will become clear when we discuss the implementation. It is not required that every special method have two more matching special methods. If one is declared then the other two operations are effectively prohibited and will raise an exception. This is an easy way to make read-only (or even write-only or delete-only) attributes. An implementation of __get_y__ takes precedence over an implementation of __getattr__ based on the principle that __getattr__ is supposed to be invoked only after finding an appropriate attribute has failed. This is important for acceptable performance. An implementation of __set_y__ takes precedence over an implementation of __setattr__ in order to be consistent. The opposite choice seems fairly feasible also, however. The same goes for __del_y__. Proposed Implementation There is a new object called a computed attribute object. It has three attributes: get, set, delete. In PyClass_New, methods of the appropriate form will be detected and converted into objects (just like unbound method objects). Matching methods go in the same computed attribute object and missing methods are replaced with a stub that throws the TypeError. If there are any computed attributes at all, a flag is set. Let's call it "I_have_computed_attributes" for now. A get proceeds as usual until just before the object is returned. In addition to the current check whether the returned object is a method it would also check whether a returned object is a computed attribute. If so, it would invoke the getter method and return the value. To remove a computed attribute object you could directly fiddle with the dictionary. A set proceeds by checking the "I_have_computed_attributes" flag. If it is not set, everything proceeds as it does today. If it is set then we must do a dictionary get on the requested object name. If it returns a computed method attribute then we call the setter function with the value. If it returns any other object then we discard the result and continue as we do today. The I_have_computed_attributes flag is intended to eliminate the performance degradation of an extra "get" per "set" for objects not using this feature. You might note that I have not proposed any logic to keep this flag up to date as attributes are added and removed from the instance's dictionary. This is consistent with current Python. If you add a __setattr__ method to an object after it is in use, that method will not behave as it would if it were available at "compile" time. The implementation of delete is analogous to the implementation of set. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 08:51:33 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 01:51:33 -0500 Subject: [Python-Dev] Consistency questions Message-ID: <3976A175.12D4DB53@prescod.net> #1. Why does can I overwrite the "standard output object" with assignment syntax sys.stdout=mystdoutobj But I have to add a profile function with function syntax: sys.setprofile( myprofilefunc ) #2. Why doesn't dir( obj ) return inherited methods? -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From peter at schneider-kamp.de Thu Jul 20 10:53:11 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 20 Jul 2000 08:53:11 +0000 Subject: [Python-Dev] questionnaire about zip and for loops Message-ID: <3976BDF7.82FB6C56@schneider-kamp.de> This is a slightly reduced version of a questionnaire run by Greg Wilson on some CS grad students. I'd like to use the readers of comp.lang.python as guinea pigs this time. PLEASE SEND THE RESULTS TO mailto:peter at schneider-kamp.de - DON'T SEND THEM TO THE LIST Thanks for your time, Peter ----------------------------------------------------------------------------------------- The single and double loop below print the output shown: for x in [10, 20, 30]: for x in [10, 20, 30]: print x for y in [1, 2, 3]: print x+y 10 11 20 12 30 13 21 22 23 31 32 33 Match each of the following example for-loops to an output. Only make one cross per line. Please consider each example on its own. (Note that several examples may print the same thing.) (1) (2) (3) (4) (5) (6) 11 11 11 11 error ?? 22 12 22 12 33 13 21 21 22 22 31 23 32 31 32 33 (A) for (x, y) in [[10, 1], [20, 2], [30, 3]]: o o o o o o print x+y (B) for [x, y] in zip([10, 20, 30], [1, 2, 3]): o o o o o o print x+y (C) for [x, y] in zip([10, 20, 30], [1, 2]): o o o o o o print x+y (D) for x; y in [10, 20, 30]; [1, 2, 3]: o o o o o o print x+y (E) for x; y in [10, 20, 30]; [1, 2]: o o o o o o print x+y (F) for x in [10, 20, 30]; y in [1, 2, 3]: o o o o o o print x+y (G) for x in [10, 20, 30]; y in [1, 2]: o o o o o o print x+y -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mwh21 at cam.ac.uk Thu Jul 20 09:00:26 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 20 Jul 2000 08:00:26 +0100 Subject: [Python-Dev] PEP-able In-Reply-To: Paul Prescod's message of "Thu, 20 Jul 2000 01:35:28 -0500" References: <39769DB0.BCE7FB38@prescod.net> Message-ID: Paul Prescod writes: > PEP: ??? > Title: Computed Attributes > Version: $Revision: 1.0 $ > Owner: paul at prescod.net > Python-Version: 2.0 > Status: Incomplete +1! (you beat me to it...) M. -- On the other hand, the following areas are subject to boycott in reaction to the rampant impurity of design or execution, as determined after a period of study, in no particular order: ... http://www.naggum.no/profile.html From peter at schneider-kamp.de Thu Jul 20 11:44:31 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 20 Jul 2000 09:44:31 +0000 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> Message-ID: <3976C9FF.A7799738@schneider-kamp.de> Thomas Wouters wrote: > > On Wed, Jul 19, 2000 at 07:27:37PM +0000, Peter Schneider-Kamp wrote: > > > > How about putting them on sourceforge? > > python.sourceforge.net/peps/pep-0206.txt and friends > > +1 if we can do it automatically. +0 if it has to be done by whoever commits > new versions ;) I can do it (and keep up with the changes) for now. But in the long run this probably should be automated. I only see the password barrier: scp pep-*.txt nowonder at shell.sourceforge.net:/home/groups/python/htdocs/peps will make me enter my password/passphrase. How would one go about doing something like that? One "solution" I can think of is to checkout a copy of nondist/peps from the CVS to htdocs/peps. Then the peps could be held up to date by running cvs up in that directory once a day (or 4 times a day). But this would require some action of SF to add it to their cron, wouldn't it?! Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From thomas at xs4all.net Thu Jul 20 10:35:46 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 10:35:46 +0200 Subject: [Python-Dev] Consistency questions In-Reply-To: <3976A175.12D4DB53@prescod.net>; from paul@prescod.net on Thu, Jul 20, 2000 at 01:51:33AM -0500 References: <3976A175.12D4DB53@prescod.net> Message-ID: <20000720103546.N9897@xs4all.nl> On Thu, Jul 20, 2000 at 01:51:33AM -0500, Paul Prescod wrote: > #1. Why does can I overwrite the "standard output object" with > assignment syntax > sys.stdout=mystdoutobj > But I have to add a profile function with function syntax: > sys.setprofile( myprofilefunc ) There is a slight difference in semantics: sys.stdout is occasionally read by a function or stmt that wants to write to stdout. Changing it doesn't actually change something in the interpreter. sys.setprofile(), however, has to change something in the current threadstate. It's not something that's read from the sys module every time it's used, but rather an accompanying variable that has to be set as well. > #2. Why doesn't dir( obj ) return inherited methods? Because inherited methods (and other inherited attributes) aren't stored in an instance's __dict__. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm at hypernet.com Thu Jul 20 15:43:33 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 20 Jul 2000 09:43:33 -0400 Subject: [Python-Dev] PEP-able In-Reply-To: <39769DB0.BCE7FB38@prescod.net> Message-ID: <1248021882-9357610@hypernet.com> Paul Prescod wrote: [Title: Computed Attributes] > Semantics > It is disallowed to actually have an attribute named y in the > dictionary for reasons that will become clear when we discuss > the implementation. What happens here (and when): class A: y = None class B(A): def __XXX_y__(self): ... > An implementation of __get_y__ takes precedence over an > implementation of __getattr__ based on the principle that > __getattr__ is supposed to be invoked only after finding an > appropriate attribute has failed. This is important for > acceptable performance. Hmmm. Current Python: search for y fails, try __getattr__. Proposed: search for y fails, try the __get_y__, then __getattr__. We've still done the same work before trying the hook, so how is performance affected? Or are you proposing to try the hook first, thus improving performance for hooked attributes at the price of degrading performance for all non- hooked attributes? > Proposed Implementation > > There is a new object called a computed attribute object. It > has three attributes: get, set, delete. In PyClass_New, > methods of the appropriate form will be detected and > converted into objects (just like unbound method objects). > Matching methods go in the same computed attribute object and > missing methods are replaced with a stub that throws the > TypeError. If there are any computed attributes at all, a > flag is set. Let's call it "I_have_computed_attributes" for > now. class A: def __get_y__(self): ... class B(A): def __set_y__(self, value): .... Notice a problem here? Is it B's author's intent to make a read- only attribute read-write (in which case the accessor object probably needs to get copied from A.__dict__ to B.__dict__ so as not to interfere with other derived classes)? Or do we assume he wants to make it write-only, and to make it read- write does he need to do: class B(A): def __set_y__(self, value): .... def __get_y__(self): return A.__get_y__(self) (which involves another wrinkle, because there is no attribute "__get_y__" in class A). - Gordon From skip at mojam.com Thu Jul 20 16:12:02 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 20 Jul 2000 09:12:02 -0500 (CDT) Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <3976C9FF.A7799738@schneider-kamp.de> References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> Message-ID: <14711.2226.242735.766934@beluga.mojam.com> Peter> But in the long run this probably should be automated. I only see Peter> the password barrier: Peter> scp pep-*.txt nowonder at shell.sourceforge.net:/home/groups/python/htdocs/peps Peter> will make me enter my password/passphrase. Peter> How would one go about doing something like that? Assuming you are running on some Unix flavor, use ssh-agent to start your X session: ssh-agent startx and in your .xinitrc file (or equivalent) execute ssh-add References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> Message-ID: <14711.2370.880455.337906@beluga.mojam.com> >> #2. Why doesn't dir( obj ) return inherited methods? Thomas> Because inherited methods (and other inherited attributes) Thomas> aren't stored in an instance's __dict__. dir() *could* be smarter and walk up the chain starting at __class__ looking for useful stuff to include. Unfortunately, dir() is written in C so it's harder to modify than it ought to be... Skip From guido at beopen.com Thu Jul 20 16:52:00 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 20 Jul 2000 07:52:00 -0700 Subject: [Python-Dev] Fw: CVS commit backout trivia Message-ID: <008601bff25a$0f770520$3e2c4fce@beopen.com> I haven't tried the suggestion below but seems like a good idea, and could be added to our SF FAQ... --Guido ----- Original Message ----- From: "Mitchell Morris" To: Sent: Wednesday, July 19, 2000 3:52 PM Subject: CVS commit backout trivia > I was reading through the python-dev archives today and saw a message from > you dated 2000-07-10 about backing out a CVS commit with "cvs admin -o" and > wanted to point out that there is a more history-friendly mechanism: "cvs > update -j -j filename". The update > command will apply the diffs between and in reverse > order. That way you don't branch or set sticky tags that have to be cleaned > up after. > > hoping-this-is-of-some-miniscule-help-ly y'rs > +Mitchell From paul at prescod.net Thu Jul 20 17:12:38 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 10:12:38 -0500 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> Message-ID: <397716E6.F19E25BE@prescod.net> Gordon McMillan wrote: > > What happens here (and when): > class A: > y = None > class B(A): > def __XXX_y__(self): > ... I would say that the latter would just take precedence over the former as if you had typed: class B(A): __XXX_y__=ComputedAttribute( foo, bar, baz ) > Hmmm. Current Python: search for y fails, try __getattr__. > Proposed: search for y fails, try the __get_y__, then > __getattr__. We've still done the same work before trying the > hook, so how is performance affected? Actually, I was justifying Python's current behavior as much as I was the current behavior. A truly general __getattr__ would access all attribute tests, not just non-existent attributes and thus be symmetric with setattr. But that would also be slow as hell. > class A: > def __get_y__(self): > ... > class B(A): > def __set_y__(self, value): > .... My first instinct is just to disallow this and figure it out after we have some more usage information/implementation resources. We could just say that all methods must be defined in the same class and if not. In other words, the methods "shadow each other" as a group. This is no more messy than inherited __getattr__ s. My second thought is to have the constructor for computed attributes objects look for a computed attribute higher in the tree and copy in the appropriate fields. Prohibiting it might be clearest for all concerned. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From thomas at xs4all.net Thu Jul 20 17:21:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 17:21:08 +0200 Subject: [Python-Dev] Consistency questions In-Reply-To: <14711.2370.880455.337906@beluga.mojam.com>; from skip@mojam.com on Thu, Jul 20, 2000 at 09:14:26AM -0500 References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> Message-ID: <20000720172108.S9897@xs4all.nl> On Thu, Jul 20, 2000 at 09:14:26AM -0500, Skip Montanaro wrote: > >> #2. Why doesn't dir( obj ) return inherited methods? > Thomas> Because inherited methods (and other inherited attributes) > Thomas> aren't stored in an instance's __dict__. > dir() *could* be smarter and walk up the chain starting at __class__ looking > for useful stuff to include. Unfortunately, dir() is written in C so it's > harder to modify than it ought to be... I would suggest adding a second, optional argument to dir(), 'recurse' or such, to add that behaviour. I think I can add that code to dir() if it's deemed a good idea ;) Turning it on by default would probably break too much code. Opinions ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From trentm at ActiveState.com Thu Jul 20 17:29:37 2000 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 20 Jul 2000 08:29:37 -0700 Subject: [Python-Dev] PyArg_ParseTuple format specifiers again In-Reply-To: <20000719220324.73E3E191AA8@oratrix.oratrix.nl> References: <20000719220324.73E3E191AA8@oratrix.oratrix.nl> Message-ID: <20000720082937.A22151@ActiveState.com> On Thu, Jul 20, 2000 at 12:03:19AM +0200, Jack Jansen wrote: > Of course, after I added the H specifier to PyArg_ParseTuple it turns > out that solved ninetysomething% of my problems, but it turns out that > what I really need is not an "unsigned short" converter but a "16 bit" > converter, i.e. something that will happily accept anything from > -32768 to 65535 without complaints. (The old "h" format, in other > words). > That is too bad that the unsigned OR signed decision could not be made. > I need this because all the MacOS API modules are machine generated, > both the C modules and the .py files with all the constants in it, and > some header file authors use -1 to mean "16 1 bits", some use > 0xffff. And I really don't want to hand-massage 40K lines of C and 6K > lines of Python everytime a new MacOS release comes out.... Very fair. > > And I also need such a format char for 8 bit values. > > Does anyone mind if I change the H specifier to do no value checking > other than making sure it fits in 16 bits, and add a B specifier for > unchecked bytes? Now I think that the best answer is to have a separate PyArg_UncheckedParseTuple() that gives you what you want Jack. Or, maybe more easily, PyArg_ParseTuple could revert to the 1.5.2 form and not do bounds checking and a new PyArg_CheckedParseTuple could do bounds checking. Actually, yes, the latter is a better idea. It would allow us to clean up the L as unsigned long rather than LONG_LONG issue if we wanted. Thereafter PyArg_CheckedParseTuple would be the preferred method if possible. Hence, PyArg_ParseTuple(): b - byte h - short i - int l - long L - LONG_LONG Pros: - This is as in 1.5.2. All the values are either not bounds checked at all or (maybe a little better) checked to be within [XXX_MIN, UXXX_MAX], i.e. in the range of the union of the signed and unsigned ranges. This will be backward compatible and only break code that had an overflow bug in it anyway. - It should make Jack happy, except that he would now have to go change all his 'H's back to 'h's. :( PyArg_CheckedParseTuple(): b - signed byte B - unsigned byte h - signed short H - unsigned short i - signed int I - unsigned int l - signed long L - unsigned long q - signed LONG_LONG Q - unsigned LONG_LONG Pros: - b,h,i,l and the capital equivs are the same as the formatters in the struct module for consistency - the use of capital for unsigned version of all the variables is intuitive (or at least straight forward and consistent) - q,Q for a 'quad' or long long is better than the current 'L' Cons: - New function may raise questions of "which do I use PyArg_ParseTuple or PyArg_CheckedParseTuple?" This is a documentation issue. - New function may require parallel maintenance in both functions. Or maybe not if one is made to use the other (efficiency prob?) - 'L' has changed meaning from one function to the other. I would propose just leaving is as is for 2.0 (unless the code breakage is okay) and then change 'L' in PyArg_ParseTuple to mean 'unsigned long' in Py3k. I can code this up after the O'Reilly conference if people (Jack, Guido, Tim, others?) think that this is a good idea. Trent -- Trent Mick TrentM at ActiveState.com From mal at lemburg.com Thu Jul 20 17:33:54 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 17:33:54 +0200 Subject: [Python-Dev] Will Python die? References: <3974808D.5D49575D@schneider-kamp.de> Message-ID: <39771BE2.A80ADD92@lemburg.com> Peter Schneider-Kamp wrote: > > Moshe Zadka wrote: > > > > My fault -- I stopped reading /. Can you summarize the thread? > > The thread is about if Visual Python is an alternative for > Visual Basic or, if not, it can be used as that. > > A subthread of this thread dealt with Pythons release schedule: > "Speaking of Python, does anyone know what's up with Python 1.6^H^H2.0? > A while back, python.org had said that version 1.6 would be out on > June 1. Then there was an announcement, mid-June that it would be > delayed. Then at the end of June, this link was placed on python.org, > and it was stated that the Python interpreter, version 1.6, was > renamed to 2.0, and the first beta would be available on July 1. Now, > on July 17, that link has been removed from python.org (although the > webpage still exists), and the release schedule is gone!" > > Quoting from relevant replies: > "python 1.6 will be out in august > check the downloads page of www.python.org > or checkout the pythonlabs at www.beopen.com > where most of the core python developers opened shop" > > "Yeah, the Python 1.6 download page says that Python 1.6 beta1 will be > done on July 1, and beta 2 on July 14. It's July 17 now, and the only > available download is alpha 2...." You may not have noticed, but the 2.0beta1 is already available to the public: just download the most recent CVS version (or the tarball from David Ascher's starship page). About the schedule: I think we'll know more after the Python Consortium Meeting. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 20 17:37:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 17:37:50 +0200 Subject: [Python-Dev] map() for methods References: <20000718130059.B7340@xs4all.nl> <14708.40190.852802.966575@beluga.mojam.com> Message-ID: <39771CCE.F70A48D4@lemburg.com> Skip Montanaro wrote: > > Moshe> In fact, putting an implementation of pad() like that in the > Moshe> string.py module would be wonderful, because it would work with > Moshe> both regular strings and unicode. However, string.py is looking > Moshe> as though as it's going to be deprecated. In short, I'd want > Moshe> Guido/Tim/effbot/MAL opinions here before we make a move. > > Don't know about the powers that be, but I don't see how you can > realistically deprecate string.py until you deprecate map(). My most > frequent use of map() is the simple > > newlist = map(string.strip, oldlist) > > where oldlist is a list of strings. (Replace "strip" by "upper", "lower", > etc, depending on your needs.) > > As far as I'm aware, there's no clean way to do that with string methods. True, we'll need somthing like this for methods too... e.g. like the following API in mx.Tools: method_mapply(objects,methodname[,args=(),kw={}]) Creates a tuple of values by applying the given arguments to each object's method. The objects are processed as given in the sequence objects. A simple application is e.g. method_mapply([a,b,c],'method', (x,y)) resulting in a tuple (a.method(x,y), b.method(x,y), c.method(x,y)). Thanks to Aaron Waters for suggesting this function. The name is clumsy... suggestions welcome :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 20 17:49:20 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 17:49:20 +0200 Subject: [Python-Dev] Coercion (RE: Discussion: Introducing new operators for matrix computation) References: Message-ID: <39771F80.90DD0C99@lemburg.com> [Adding new operators] Just a side note before everyone forgets: I think we'll need to carefully redefine coercion *before* adding any new slots/operators/etc. to Python. The current model where coercion is centralized won't scale well with the new operators. My (old) proposal for this (see my Python Pages) was to decentralize coercion and make the coercion process part of the operators task. Thoughts ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Thu Jul 20 17:50:58 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 20 Jul 2000 10:50:58 -0500 (CDT) Subject: [Python-Dev] Consistency questions In-Reply-To: <20000720172108.S9897@xs4all.nl> References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> <20000720172108.S9897@xs4all.nl> Message-ID: <14711.8162.800169.884936@beluga.mojam.com> Thomas> I would suggest adding a second, optional argument to dir(), Thomas> 'recurse' or such, to add that behaviour. I think I can add that Thomas> code to dir() if it's deemed a good idea ;) Turning it on by Thomas> default would probably break too much code. I don't think so. I suspect most people use dir() interactively to see what attributes an object supports and would appreciate the improved functionality. Besides, we are talking 2.0 here. Nothing wrong with a little breakage... ;-) Skip From jack at oratrix.nl Thu Jul 20 17:51:39 2000 From: jack at oratrix.nl (Jack Jansen) Date: Thu, 20 Jul 2000 17:51:39 +0200 Subject: [Python-Dev] PyArg_ParseTuple format specifiers again In-Reply-To: Message by Trent Mick , Thu, 20 Jul 2000 08:29:37 -0700 , <20000720082937.A22151@ActiveState.com> Message-ID: <20000720155140.73BA837186E@snelboot.oratrix.nl> Hmm. I think that having separate PyArg_ParseTuple and PyArg_UncheckedParseTuple is absolute overkill. Also, I think the functionality of having the checks is a fine one, I was at the time grumbling about it being a backward-incompatible change, and moreover one that caused me a lot of work at a time that I had more than enough other things to do. But now that the work is done I see no reason to revert it. If we'd want to do a complete set of arguments for each of 8, 16 and 32 bit integers we would have 3 specifiers: signed, unsigned and bitpattern. As it stands now we have: signed unsign bitpattern 8bit - b - 16bit h H - 32bit - - l (note the last one: 32bit values are in essence not checked because the parser happily stuffs 0xffffffff into a long). What I would be happy with is to have "natural" (unsigned for char, signed for other types) and bitpattern, so natural bitpattern 8bit b B 16bit h H 32bit l L I agree about breaking L: it's there but in the standard distribution it isn't used a single time. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From mal at lemburg.com Thu Jul 20 17:58:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 17:58:39 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <14709.10193.715558.561239@anthem.concentric.net> <20000718235317.A7561@lyra.org> Message-ID: <397721AF.9F6D023E@lemburg.com> Greg Stein wrote: > > On Wed, Jul 19, 2000 at 12:00:17AM -0400, Barry A. Warsaw wrote: > > >>>>> "MZ" == Moshe Zadka writes: > > > > MZ> I'm +1 on that. One thing that bugs me is that we're adding a > > MZ> builtin type. Why not stick with the Python implementation? > > > > I've been thinking a little bit about the other generators, especially > > irange(). I wonder if we shouldn't just be putting zip() and friends > > in their own Python module and not make them builtins? > > Which are you proposing: > > 1) implement in a Python module. clients use some_module.zip() > 2) implement in a Python module. insert into builtins. clients use zip(). FYI, mx.Tools implements 1) + 2). I usually put the "rom mx.Tools import NewBuiltins" at the top of the module source file so that it becomes clear that the module uses the set of new builtins available through mx.Tools. YMMV. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 20 18:07:11 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 18:07:11 +0200 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> Message-ID: <397723AF.4B11379A@lemburg.com> Fredrik Lundh wrote: > > greg wrote: > > > > Yes, but it would by possible to use snprintf in PyErr_Format. > > > > still not quite the same. /F's PyErr_Format returns an arbitrary length > > string. snprintf() would be cut at some pre-specified limit. > > if I understood GvR correctly, the only remaining issue here > is whether we need more formatting codes > > (PyErr_Format is undocumented, so I'm not sure we need to > be backwards compatible with code outside the interpreter...) > > comments? How about this: You add your new PyErr_Format() replacement with the existing subset of codes, but instead of bailing out when the function sees a format code it doesn't understand, you use sprintf() or snprintf() (where available) to format the unkown code ?! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From donb at init.com Thu Jul 20 18:11:38 2000 From: donb at init.com (Donald Beaudry) Date: Thu, 20 Jul 2000 12:11:38 -0400 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> <397716E6.F19E25BE@prescod.net> Message-ID: <200007201611.MAA26587@zippy.init.com> Paul Prescod wrote, > My first instinct is just to disallow this and figure it out after > we have some more usage information/implementation resources. We > could just say that all methods must be defined in the same class > and if not. In other words, the methods "shadow each other" as a > group. One way of doing that, which I feel also makes things a bit more obvious, is to allow only a single routine per attribute: __attr_XXX__. Here's an example: def __attr_foo__(self, op, value=None): if op is 'get': return self.compute() elif op is 'set': self.adjust(value) else: self.do_the_del_thing() String interning makes the op tests quite fast. > My second thought is to have the constructor for computed attributes > objects look for a computed attribute higher in the tree and copy in > the appropriate fields. That sounds fragile and would create "book keeping" problems if maintaining the current level of dynamic attribute magic is desired. > Prohibiting it might be clearest for all concerned. I agree that prohibiting it is the right idea. The question is how. Permitting only one routine per attribute lets the traditional attribute lookup rules work and thus prevents head scratching when trying to find the code that actually maintains an attribute. The cost is some additional burden on the writer of the __attr_XXX method (and some magic to distinguish the del case). -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb at init.com Lexington, MA 02421 ...Will hack for sushi... From peter at schneider-kamp.de Thu Jul 20 20:51:21 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 20 Jul 2000 18:51:21 +0000 Subject: [Python-Dev] PEPs on the web Message-ID: <39774A29.86E469BB@schneider-kamp.de> I have put up the PEPs on http://python.sourceforge.net/peps/ Three questions remain: 1) Is that okay? No one cried out aloud and I got some agreement. 2) Should I put a link from http://python.sourceforge.net ? 3) What about making those PEPs xhtml (or something like that)? Pros: - links from pep-000.txt - links from the other peps Cons: - harder to read in checkins - harder to edit (maybe we could use as little markup as possible?) Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gmcm at hypernet.com Thu Jul 20 19:03:13 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 20 Jul 2000 13:03:13 -0400 Subject: [Python-Dev] Consistency questions In-Reply-To: <14711.8162.800169.884936@beluga.mojam.com> References: <20000720172108.S9897@xs4all.nl> Message-ID: <1248009902-10078204@hypernet.com> Skip Montanaro wrote: > > Thomas> I would suggest adding a second, optional argument to > dir(), Thomas> 'recurse' or such, to add that behaviour. I > think I can add that Thomas> code to dir() if it's deemed a > good idea ;) Turning it on by Thomas> default would probably > break too much code. > > I don't think so. I suspect most people use dir() interactively > to see what attributes an object supports and would appreciate > the improved functionality. Besides, we are talking 2.0 here. > Nothing wrong with a little breakage... ;-) In the std lib: cmd.py (already looks in __class__ and __bases__), rlcompleter (doesn't), rexec (only invoked on modules?). It seems a gratuitous breakage, since it's additional behavior, not fixed behavior. - Gordon From gmcm at hypernet.com Thu Jul 20 19:03:13 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 20 Jul 2000 13:03:13 -0400 Subject: [Python-Dev] Computed-attributes In-Reply-To: <397716E6.F19E25BE@prescod.net> Message-ID: <1248009900-10078307@hypernet.com> Paul Prescod wrote: > Gordon McMillan wrote: > > > > What happens here (and when): > > class A: > > y = None > > class B(A): > > def __XXX_y__(self): > > ... > > I would say that the latter would just take precedence over the > former as if you had typed: > > class B(A): > __XXX_y__=ComputedAttribute( foo, bar, baz ) OK. I gather that the ComputedAttribute is actually named after the attribute. So in this situation, "y" is found in B.__dict__, and is a ComputedAttribute which hides A's (normal) attribute. Then: class A: def __init__(self): self.y = class B(A): def __set_y__(self, value): ... def __init__(self): A.__init__(self) means that the hook in B will be invoked when A.__init__ runs. I wonder what "gotchas" lie in wait ;-). > > Hmmm. Current Python: search for y fails, try __getattr__. > > Proposed: search for y fails, try the __get_y__, then > > __getattr__. We've still done the same work before trying the > > hook, so how is performance affected? I hadn't realized when I wrote that that the ComputedAttribute would have the attribute's name. That does make getattr faster. But: > Actually, I was justifying Python's current behavior as much as I > was the current behavior. A truly general __getattr__ would > access all attribute tests, not just non-existent attributes and > thus be symmetric with setattr. But that would also be slow as > hell. I use __getattr__ most often to do lazy evaluation. So: def __getattr__(self, nm): if nm == 'doohickies': rslt = self.doohickies = return rslt Yes, you can do this either way, but I rather like the fact that it's a last resort hook. > > class A: > > def __get_y__(self): > > ... > > class B(A): > > def __set_y__(self, value): > > .... > > My first instinct is just to disallow this and figure it out > after we have some more usage information/implementation > resources. We could just say that all methods must be defined in > the same class and if not. In other words, the methods "shadow > each other" as a group. > > This is no more messy than inherited __getattr__ s. Not at all. The complexity of doing __getattr__ and __setattr__ hooks is all in the class you implement them in. There's no *new* complexity in going to base class implementations - you just chain as usual. The only surprise might be that if the hapless subclasser doesn't realize that some base class has a __setattr__ hook set. I'm not against this proposal. But I think there are *no* "safe" ways of doing attr hacks; and simply getting to "safer" may be a whole lot of work. [I also note that there are quite a few Python developers who want their users to say "x = obj.getx()", but want Python to create the accessor method "getx(self)" (if they haven't written one) and outlaw "x = obj.x". I have no sympathy for them, but they exist.] - Gordon From gmcm at hypernet.com Thu Jul 20 19:03:13 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 20 Jul 2000 13:03:13 -0400 Subject: [Python-Dev] Consistency questions In-Reply-To: <20000720172108.S9897@xs4all.nl> References: <14711.2370.880455.337906@beluga.mojam.com>; from skip@mojam.com on Thu, Jul 20, 2000 at 09:14:26AM -0500 Message-ID: <1248009898-10078427@hypernet.com> Thomas Wouters wrote: [ Why doesn't dir( obj ) return inherited methods? ] > I would suggest adding a second, optional argument to dir(), > 'recurse' or such, to add that behaviour. I think I can add that > code to dir() if it's deemed a good idea ;) Turning it on by > default would probably break too much code. I strongly agree with the last sentence. I'm only +0 on the enhancement (Mark's got that in PythonWin, and I hardly ever use it). - Gordon From mal at lemburg.com Thu Jul 20 19:05:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 19:05:37 +0200 Subject: [Python-Dev] PEP-able References: <39769DB0.BCE7FB38@prescod.net> Message-ID: <39773161.1DA45DE6@lemburg.com> Paul Prescod wrote: > > PEP: ??? > Title: Computed Attributes > Version: $Revision: 1.0 $ > Owner: paul at prescod.net > Python-Version: 2.0 > Status: Incomplete > > Introduction > > This PEP describes a feature to make it easier to use Python > attribute set/get/del syntax to fetch the results of a computation > or to invoke computation. This feature has been emulated using > __getattr__/__setattr__/__delattr__ but this approach suffers > severe usability and performance concerns. > > Syntax > > Special methods should declare themselves with declarations of the > following form: > > class x: > def __get_foo__(self ): ... def __set_foo__(self, value ): ... > def __del_foo__(self ): ... > > They are used like this: > > fooval=x.foo > x.foo=fooval+5 > del x.foo I don't get the point: how is this better than defining explicit access methods ? get_foo(self) set_foo(self, value) del_foo(self) These not only define a distinct interface, but also provide more flexibility, e.g. get_foo() could have a default argument. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 20 19:13:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 19:13:23 +0200 Subject: [Python-Dev] Consistency questions References: <3976A175.12D4DB53@prescod.net> Message-ID: <39773333.ABFDD65D@lemburg.com> Paul Prescod wrote: > > #1. Why does can I overwrite the "standard output object" with > assignment syntax > > sys.stdout=mystdoutobj > > But I have to add a profile function with function syntax: > > sys.setprofile( myprofilefunc ) .set/get APIs usually interface to C flags or variables which are not meant to be used directly (often due to performance reasons). > #2. Why doesn't dir( obj ) return inherited methods? Maybe because inherited methods are not local to the object. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mwh21 at cam.ac.uk Thu Jul 20 19:17:54 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 20 Jul 2000 18:17:54 +0100 Subject: [Python-Dev] Consistency questions In-Reply-To: "Gordon McMillan"'s message of "Thu, 20 Jul 2000 13:03:13 -0400" References: <20000720172108.S9897@xs4all.nl> <1248009902-10078204@hypernet.com> Message-ID: "Gordon McMillan" writes: > Skip Montanaro wrote: > > > > > Thomas> I would suggest adding a second, optional argument to > > dir(), Thomas> 'recurse' or such, to add that behaviour. I > > think I can add that Thomas> code to dir() if it's deemed a > > good idea ;) Turning it on by Thomas> default would probably > > break too much code. > > > > I don't think so. I suspect most people use dir() interactively > > to see what attributes an object supports and would appreciate > > the improved functionality. Besides, we are talking 2.0 here. > > Nothing wrong with a little breakage... ;-) > > In the std lib: > cmd.py (already looks in __class__ and __bases__), > rlcompleter (doesn't), Yes it does! (at least in CVS; that was my first patch to Python...) > rexec (only invoked on modules?). > > It seems a gratuitous breakage, since it's additional behavior, > not fixed behavior. Gentle agreement. Cheers, M. -- After a heavy night, I travelled on, my face toward home - the comma being by no means guaranteed. -- paraphrased from cam.misc From paul at prescod.net Thu Jul 20 19:21:07 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:21:07 -0500 Subject: [Python-Dev] map() for methods References: <20000718130059.B7340@xs4all.nl> <14708.40190.852802.966575@beluga.mojam.com> <39771CCE.F70A48D4@lemburg.com> Message-ID: <39773503.8738E2F5@prescod.net> "M.-A. Lemburg" wrote: > > > True, we'll need somthing like this for methods too... e.g. > like the following API in mx.Tools: > > method_mapply(objects,methodname[,args=(),kw={}]) > ... > > The name is clumsy... suggestions welcome :-) How about this name: "list comprehension." -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From thomas at xs4all.net Thu Jul 20 20:36:17 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 20:36:17 +0200 Subject: [Python-Dev] Coercion (RE: Discussion: Introducing new operators for matrix computation) In-Reply-To: <39771F80.90DD0C99@lemburg.com>; from mal@lemburg.com on Thu, Jul 20, 2000 at 05:49:20PM +0200 References: <39771F80.90DD0C99@lemburg.com> Message-ID: <20000720203617.U9897@xs4all.nl> On Thu, Jul 20, 2000 at 05:49:20PM +0200, M.-A. Lemburg wrote: > [Adding new operators] > Just a side note before everyone forgets: I think we'll > need to carefully redefine coercion *before* adding any > new slots/operators/etc. to Python. > The current model where coercion is centralized won't > scale well with the new operators. My (old) proposal for this > (see my Python Pages) was to decentralize coercion and > make the coercion process part of the operators task. > Thoughts ? Agreed. I also think, but that's a personal opinion, that adding new operators should be done carefully, and I'm not sure if 2.0 is the right time for it. It depends on how far away 2.0 is, of course, not just to make sure the operators are implemented right, with clear semantics and everything, but also to give everyone a chance to accept the idea of new operators ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Thu Jul 20 20:40:35 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 20:40:35 +0200 Subject: [Python-Dev] PEPs on the web In-Reply-To: <39774A29.86E469BB@schneider-kamp.de>; from peter@schneider-kamp.de on Thu, Jul 20, 2000 at 06:51:21PM +0000 References: <39774A29.86E469BB@schneider-kamp.de> Message-ID: <20000720204034.V9897@xs4all.nl> On Thu, Jul 20, 2000 at 06:51:21PM +0000, Peter Schneider-Kamp wrote: > I have put up the PEPs on http://python.sourceforge.net/peps/ > 1) Is that okay? No one cried out aloud and I got some agreement. I don't see why not. It certainly seems the right place for it ! And it's not like they were a corporate secret before. > 2) Should I put a link from http://python.sourceforge.net ? I'd say so, yeah. > 3) What about making those PEPs xhtml (or something like that)? > Pros: > - links from pep-000.txt > - links from the other peps > Cons: > - harder to read in checkins > - harder to edit > (maybe we could use as little markup as possible?) Definate -1 from here. I like plaintext. It also works just fine for RFCs. I don't mind if the reference section (which should be the only place that contains URIs ;) is written in a markup language to facilitate HTMLization, or maybe just straight HTML, but I don't feel like escaping all those '>'s in there. However, if they can be converted to HTML automatically, based on minor clues and/or whitespace-layout, fine by me ;) I wouldn't mind adding things like paragraph markers and such, I just dont like to edit HTML newer than 1.1 ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Thu Jul 20 19:27:19 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:27:19 -0500 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> <397723AF.4B11379A@lemburg.com> Message-ID: <39773677.B3543269@prescod.net> "M.-A. Lemburg" wrote: > >... > > You add your new PyErr_Format() replacement with the existing > subset of codes, but instead of bailing out when the function > sees a format code it doesn't understand, you use sprintf() > or snprintf() (where available) to format the unkown code ?! I think its too magical and could hide security holes under too many levels of conditional behavior. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 19:49:09 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:49:09 -0500 Subject: [Python-Dev] PEP-able References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> Message-ID: <39773B95.2B70EBBC@prescod.net> "M.-A. Lemburg" wrote: > > .. > > I don't get the point: how is this better than defining > explicit access methods ? > > get_foo(self) > set_foo(self, value) > del_foo(self) It's more verbose for the client programmer and it forces them to "know" that there is magical processing going on under the covers. I'm going to provide examples of where we do or would use a feature like this in extension modules so that you can see that I'm just trying to extend the fun to Python programmers (not just extension writers). There are about a million places in Python's implementation where extension modules do computation like: def __setattr__( name, val ): if attribute_to_set=="__class__": assert PyClass_Check( val ): elif attribute_to_set=="__dict__": assert PyDict_Check( val ): One could imagine a circumstance in which we decide to "trap" sys.stdin=o so that if it HASN'T been set we could use a more efficient stdout writing protocol internal to the interpreter implementation. In general, it is useful when you want to migrate from an attribute-setting situation to a computational situation without changing existing code. You can also think of the various places where the interpreter traps when you try to write to a read-only attribute. In pyexpat, when you assign to certain variables we "push" that information down to expat itself (set variables in expat). Imagine trying to read or write an attribute over COM or CORBA. Why should Python programmers have to use foo.set("a", 5) when VB programmers just say foo.a=5? Mark Hammond currently does this with __getattr__ I believe. It would be more efficient better to auto-generate getter and setter methods. In general, its useful for proxy situations where the set of attribute you want to proxy are known in advance. It's just a cleaner, Pythonic way to do something that is already common either using __getattr__ hacks or in extension modules. > These not only define a distinct interface, but also provide > more flexibility, e.g. get_foo() could have a default argument. I'm not taking away anyone's right to use methods. The logical extension of your argument is that we should always use getter/setter methods in case we need to add arguments to them later. That's the Java stance but I think we can differentiate ourselves from Java with clearer code. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 19:52:28 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:52:28 -0500 Subject: [Python-Dev] Computed-attributes References: <1248009900-10078307@hypernet.com> Message-ID: <39773C5C.D9C07572@prescod.net> Gordon McMillan wrote: > > ... > Then: > > class A: > def __init__(self): > self.y = > class B(A): > def __set_y__(self, value): > ... > def __init__(self): > A.__init__(self) > > means that the hook in B will be invoked when A.__init__ > runs. I wonder what "gotchas" lie in wait ;-). Python is full of these gotchas. (__setattr__ has the same problem, for example). It's amazing that anything ever works. :) For any lurkers: my tongue is firmly in my cheek! > [I also note that there are quite a few Python developers who > want their users to say "x = obj.getx()", but want Python to > create the accessor method "getx(self)" (if they haven't written > one) and outlaw "x = obj.x". I have no sympathy for them, but > they exist.] Java-heads. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 19:56:27 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:56:27 -0500 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> <397716E6.F19E25BE@prescod.net> <200007201611.MAA26587@zippy.init.com> Message-ID: <39773D4B.495E1C4B@prescod.net> Don Beaudry! The master returns to check on the upstarts. Donald Beaudry wrote: > > ... > > One way of doing that, which I feel also makes things a bit more > obvious, is to allow only a single routine per attribute: __attr_XXX__. My first reaction was negative but it does simplify a bunch of stuff. Inheritance is straightforward, calling a base class is straightforward, implementation is simpler. Overall, I like it! > I agree that prohibiting it is the right idea. The question is how. > Permitting only one routine per attribute lets the traditional > attribute lookup rules work and thus prevents head scratching when > trying to find the code that actually maintains an attribute. The > cost is some additional burden on the writer of the __attr_XXX method > (and some magic to distinguish the del case). Don't follow that. Why not just have "get"/"set"/"del" opcodes? -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From moshez at math.huji.ac.il Thu Jul 20 20:58:54 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 20 Jul 2000 21:58:54 +0300 (IDT) Subject: [Python-Dev] Coercion (RE: Discussion: Introducing new operators for matrix computation) In-Reply-To: <39771F80.90DD0C99@lemburg.com> Message-ID: On Thu, 20 Jul 2000, M.-A. Lemburg wrote: > The current model where coercion is centralized won't > scale well with the new operators. My (old) proposal for this > (see my Python Pages) was to decentralize coercion and > make the coercion process part of the operators task. > > Thoughts ? > Yes. Coercion should be PEPed. It definitely qualifies for PEPing. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul at prescod.net Thu Jul 20 20:57:10 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 13:57:10 -0500 Subject: [Python-Dev] Computed-attributes References: <1248009900-10078307@hypernet.com> Message-ID: <39774B86.2D6317AB@prescod.net> Gordon McMillan wrote: > > ... > Then: > > class A: > def __init__(self): > self.y = > class B(A): > def __set_y__(self, value): > ... > def __init__(self): > A.__init__(self) > > means that the hook in B will be invoked when A.__init__ > runs. I wonder what "gotchas" lie in wait ;-). Python is full of these gotchas. (__setattr__ has the same problem, for example). It's amazing that anything ever works. :) For any lurkers: my tongue is firmly in my cheek! > [I also note that there are quite a few Python developers who > want their users to say "x = obj.getx()", but want Python to > create the accessor method "getx(self)" (if they haven't written > one) and outlaw "x = obj.x". I have no sympathy for them, but > they exist.] Java-heads. What do you think of Don B's idea. It simplifies things somewhat. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 19:27:19 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:27:19 -0500 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> <397723AF.4B11379A@lemburg.com> Message-ID: <39773677.B3543269@prescod.net> "M.-A. Lemburg" wrote: > >... > > You add your new PyErr_Format() replacement with the existing > subset of codes, but instead of bailing out when the function > sees a format code it doesn't understand, you use sprintf() > or snprintf() (where available) to format the unkown code ?! I think its too magical and could hide security holes under too many levels of conditional behavior. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 19:56:27 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:56:27 -0500 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> <397716E6.F19E25BE@prescod.net> <200007201611.MAA26587@zippy.init.com> Message-ID: <39773D4B.495E1C4B@prescod.net> Don Beaudry! The master returns to check on the upstarts. Donald Beaudry wrote: > > ... > > One way of doing that, which I feel also makes things a bit more > obvious, is to allow only a single routine per attribute: __attr_XXX__. My first reaction was negative but it does simplify a bunch of stuff. Inheritance is straightforward, calling a base class is straightforward, implementation is simpler. Overall, I like it! > I agree that prohibiting it is the right idea. The question is how. > Permitting only one routine per attribute lets the traditional > attribute lookup rules work and thus prevents head scratching when > trying to find the code that actually maintains an attribute. The > cost is some additional burden on the writer of the __attr_XXX method > (and some magic to distinguish the del case). Don't follow that. Why not just have "get"/"set"/"del" opcodes? -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 19:58:19 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:58:19 -0500 Subject: [Python-Dev] Consistency questions References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> <20000720172108.S9897@xs4all.nl> <14711.8162.800169.884936@beluga.mojam.com> Message-ID: <39773DBB.9480F7BF@prescod.net> Skip Montanaro wrote: > > ... > > I don't think so. I suspect most people use dir() interactively to see what > attributes an object supports and would appreciate the improved > functionality. Besides, we are talking 2.0 here. Nothing wrong with a > little breakage... ;-) I think that Thomas is right that there is going to be a fair bit of code that manually worked around this limitation in dir and now will get two copies of some attributes. What do you think about attrs( foo ) It's more descriptive anyhow. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From moshez at math.huji.ac.il Thu Jul 20 21:04:15 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 20 Jul 2000 22:04:15 +0300 (IDT) Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) In-Reply-To: <39773677.B3543269@prescod.net> Message-ID: [M.-A. Lemburg] > You add your new PyErr_Format() replacement with the existing > subset of codes, but instead of bailing out when the function > sees a format code it doesn't understand, you use sprintf() > or snprintf() (where available) to format the unkown code ?! [Paul Prescod] > I think its too magical and could hide security holes under too many > levels of conditional behavior. FWIW, I agree with Paul -- if an unknown format code is used, it will be plainly seen in the exception, so we will know *exactly* what popular format codes we forgot to add. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Thu Jul 20 21:09:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 20 Jul 2000 22:09:06 +0300 (IDT) Subject: [Python-Dev] PEPs on the web In-Reply-To: <39774A29.86E469BB@schneider-kamp.de> Message-ID: On Thu, 20 Jul 2000, Peter Schneider-Kamp wrote: > 2) Should I put a link from http://python.sourceforge.net ? +1 and more! > 3) What about making those PEPs xhtml (or something like that)? > Pros: > - links from pep-000.txt > - links from the other peps > Cons: > - harder to read in checkins > - harder to edit > (maybe we could use as little markup as possible?) -1. RFCs got to rule the 'net with text alone. If it's good enough for the IETF, it's good enough for us. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Thu Jul 20 21:46:18 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 20 Jul 2000 21:46:18 +0200 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> Message-ID: <008901bff283$2d55d2a0$f2a6b5d4@hagrid> peter wrote: > 3) What about making those PEPs xhtml (or something like that)? > Pros: > - links from pep-000.txt > - links from the other peps > Cons: > - harder to read in checkins > - harder to edit > (maybe we could use as little markup as possible?) please stick to plain text sources. here's a little script that converts text PEP's to HTML. feel free to add it to your uploading scripts. # convert PEP's to (X)HTML import cgi, glob, os, re fixpat = re.compile("((http|ftp):[-_a-zA-Z0-9/.+?~:]+)|(pep-\d+(.txt)?|.") def fixanchor(match): text = match.group(0) link = None if text[:5] == "http:" or text[:4] == "ftp:": link = text elif text[:3] == "pep": link = os.path.splitext(text)[0] + ".html" if link: return "%s" % (link, cgi.escape(text)) return cgi.escape(match.group(0)) def fixfile(infile, outfile): # convert plain text pep to minimal XHTML markup fi = open(infile) fo = open(outfile, "w") fo.write("\n") # head header = [] fo.write("\n") while 1: line = fi.readline() if not line or ":" not in line: break key, value = line.split(":", 1) value = value.strip() header.append((key, value)) if key.lower() == "title": fo.write("%s\n" % cgi.escape(value)) fo.write("\n") # body fo.write("\n") fo.write("
\n")
    for k, v in header:
        fo.write("%s: %s\n" % (cgi.escape(k), cgi.escape(v)))
    title = 0
    while 1:
        line = fi.readline()
        if not line:
            break
        if line[:1] == "\f":
            fo.write("
\n")
            title = 1
        else:
            line = fixpat.sub(fixanchor, line)
            if title:
                fo.write("
%s
\n" % line)
            else:
                fo.write(line)
            title = 0
    fo.write("
\n") fo.write("\n") fo.write("\n") for file in glob.glob("pep-*.txt"): print file, "..." fixfile(file, os.path.splitext(file)[0] + ".html") cheers /F From huaiyu_zhu at yahoo.com Thu Jul 20 21:42:44 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Thu, 20 Jul 2000 12:42:44 -0700 (PDT) Subject: [Python-Dev] Coercion (RE: Discussion: Introducing new operators for matrix computation) In-Reply-To: <20000720203617.U9897@xs4all.nl> Message-ID: On Thu, 20 Jul 2000, Thomas Wouters wrote: > On Thu, Jul 20, 2000 at 05:49:20PM +0200, M.-A. Lemburg wrote: > > [Adding new operators] > > > Just a side note before everyone forgets: I think we'll > > need to carefully redefine coercion *before* adding any > > new slots/operators/etc. to Python. > > > The current model where coercion is centralized won't > > scale well with the new operators. My (old) proposal for this > > (see my Python Pages) was to decentralize coercion and > > make the coercion process part of the operators task. > > > Thoughts ? > Just a note. The additional operators for numerical computation have exactly the same properties as the conventional math operators. Their default on numbers are identical. Don't know if this is relevant, though. > Agreed. I also think, but that's a personal opinion, that adding new > operators should be done carefully, and I'm not sure if 2.0 is the right > time for it. It depends on how far away 2.0 is, of course, not just to make > sure the operators are implemented right, with clear semantics and > everything, but also to give everyone a chance to accept the idea of new > operators ;P Any timeline? Huaiyu From donb at init.com Thu Jul 20 21:48:45 2000 From: donb at init.com (Donald Beaudry) Date: Thu, 20 Jul 2000 15:48:45 -0400 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> <397716E6.F19E25BE@prescod.net> <200007201611.MAA26587@zippy.init.com> <39773D4B.495E1C4B@prescod.net> Message-ID: <200007201948.PAA29206@zippy.init.com> Paul Prescod wrote, > Donald Beaudry wrote: > > The cost is some additional burden on the writer of the __attr_XXX > > method (and some magic to distinguish the del case). > > Don't follow that. Why not just have "get"/"set"/"del" opcodes? Sorry about that... it was an editing problem. At first I was going to propose that the __attr_XXX method take just one optional argument: the set value. If it was there do a set, if not do a get. The problem was how to do the del (magic?). Then I had the bright idea of using the op parameter but never removed my "magic" comment. The "additional burden" I was refering to was that of writing a method which must first decide what to do. Personally, I call this a feature since it forces all maintenance of a given attribute into a single place. Others might argue that the code in a single purpose setter, getter, or deller would read better. -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb at init.com Lexington, MA 02421 ...So much code, so little time... From thomas at xs4all.net Thu Jul 20 22:13:00 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 22:13:00 +0200 Subject: [Python-Dev] ANSIfication again ;) Message-ID: <20000720221300.W9897@xs4all.nl> I just went over all of the Python source, using this little program (which I called findkrc.py): import sys, string for file in sys.argv[1:] d = open(file).read() if string.find(d, ";\n{") <> -1 or string.find(d, "()\n{") <> -1: print file (using find -name '*.[ch]' -print | xargs ./findkrc.py) And I fixed almost all of the instances of K&R C syntax. However, I found a lot of instances of the 2nd type: empty argument list. However, as far as I remember, ANSI C states that should be written as '(void)'. Is that a non-issue, and should I not bother fixing those ? (Most of the files in Modules/ has one or more instances of those.) I also found a number of files which were already converted to ANSI syntax, but with one function leftover. Should I bother uploading a patch for those, or can I just commit them ? They're only a few lines per file, after all. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jul 20 22:49:30 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 22:49:30 +0200 Subject: [Python-Dev] __set_foo__ et al. (PEP-able) References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> <39773B95.2B70EBBC@prescod.net> Message-ID: <397765DA.133518A2@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > .. > > > > I don't get the point: how is this better than defining > > explicit access methods ? > > > > get_foo(self) > > set_foo(self, value) > > del_foo(self) > > It's more verbose for the client programmer and it forces them to "know" > that there is magical processing going on under the covers. Magical processing is usually not a very good design, IMHO (no, I don't like the Unicode auto-conversions ;-). > I'm going to > provide examples of where we do or would use a feature like this in > extension modules so that you can see that I'm just trying to extend the > fun to Python programmers (not just extension writers). > > There are about a million places in Python's implementation where > extension modules do computation like: > > def __setattr__( name, val ): > if attribute_to_set=="__class__": > assert PyClass_Check( val ): > elif attribute_to_set=="__dict__": > assert PyDict_Check( val ): But that's just an implementation detail (you either do the lookup via a mapping, e.g. the instance dict, or by switching on the attribute name)... in C and with only a few cases, the switching technique is faster than the lookup. > One could imagine a circumstance in which we decide to "trap" > sys.stdin=o so that if it HASN'T been set we could use a more efficient > stdout writing protocol internal to the interpreter implementation. > > In general, it is useful when you want to migrate from an > attribute-setting situation to a computational situation without > changing existing code. > > You can also think of the various places where the interpreter traps > when you try to write to a read-only attribute. > > In pyexpat, when you assign to certain variables we "push" that > information down to expat itself (set variables in expat). > > Imagine trying to read or write an attribute over COM or CORBA. Why > should Python programmers have to use foo.set("a", 5) when VB > programmers just say foo.a=5? Mark Hammond currently does this with > __getattr__ I believe. It would be more efficient better to > auto-generate getter and setter methods. > > In general, its useful for proxy situations where the set of attribute > you want to proxy are known in advance. > > It's just a cleaner, Pythonic way to do something that is already common > either using __getattr__ hacks or in extension modules. It's also *much* slower: you'd have to check objects for e.g. obj.__set_foo__ prior to every obj.foo=1 assignment. I think that these techniques are better implemented by writing a special proxy which then does your proposed mapping for a predefined set of attributes. mx.Proxy would be a good code base for these kind of experiments, but a simple Python prototype would do as well. > > These not only define a distinct interface, but also provide > > more flexibility, e.g. get_foo() could have a default argument. > > I'm not taking away anyone's right to use methods. The logical extension > of your argument is that we should always use getter/setter methods in > case we need to add arguments to them later. That's the Java stance but > I think we can differentiate ourselves from Java with clearer code. Well, you can't really say what is best in the general case. I usually use the direct attribute access method for information containers and the method access for more elaborate objects (ones which care about the data format, apply extra checks, depend on state, etc.). Very often these methods set more than just one attribute, so using __set_foo__ wouldn't work here. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Thu Jul 20 23:14:00 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 20 Jul 2000 23:14:00 +0200 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <008901bff283$2d55d2a0$f2a6b5d4@hagrid> Message-ID: <015101bff28f$6dad9200$f2a6b5d4@hagrid> minor nit: - fo.write("
\n") + fo.write("
\n") From paul at prescod.net Thu Jul 20 23:18:08 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 16:18:08 -0500 Subject: [Python-Dev] __set_foo__ et al. (PEP-able) References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> <39773B95.2B70EBBC@prescod.net> <397765DA.133518A2@lemburg.com> Message-ID: <39776C90.67FAFFD8@prescod.net> "M.-A. Lemburg" wrote: > > > def __setattr__( name, val ): > > if attribute_to_set=="__class__": > > assert PyClass_Check( val ): > > elif attribute_to_set=="__dict__": > > assert PyDict_Check( val ): > > But that's just an implementation detail (you either do the > lookup via a mapping, e.g. the instance dict, or by switching > on the attribute name)... in C and with only a few cases, the > switching technique is faster than the lookup. That's not the case. In this case, Guido is doing type checking on sets. You can only do that in Python with an __setattr__ hack. > > It's just a cleaner, Pythonic way to do something that is already common > > either using __getattr__ hacks or in extension modules. > > It's also *much* slower: you'd have to check objects for > e.g. obj.__set_foo__ prior to every obj.foo=1 assignment. It's much, much faster for than __getattr__ for gets. It's probably no slower than __setattr__ for sets because you aren't switching on the attribute name in Python. Anyhow gets are much more common than sets so speeding them up is a big win. > I think that these techniques are better implemented by > writing a special proxy which then does your proposed > mapping for a predefined set of attributes. Proxies are slow and introduce a host of their own "issues." In practice, I've never seen anyone implement this pattern with proxies unless the proxies were doing something else already (e.g. COM). They always use a direct __getattr__/__setattr__. > I usually use the direct attribute access method for > information containers and the method access for more > elaborate objects (ones which care about the data format, > apply extra checks, depend on state, etc.). Very often > these methods set more than just one attribute, so using > __set_foo__ wouldn't work here. Don't follow. Here's an example that: * cares about data format * applies extra checks * is state dependent * sets more than one attribute internally def __set_enddate__( self, val ): if len(val)==3 and val>self.start_date self.endday, self.endmonth, self.endyear=val else: raise TypeError def __get_enddate__(self, val): return self.endday, self.endmonth, self.endyear obj.enddate=(15, 12, 2000) print obj.endday print obj.endmonth print obj.endyear d,m,y=obj.enddate -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From mal at lemburg.com Thu Jul 20 23:42:32 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 23:42:32 +0200 Subject: [Python-Dev] __set_foo__ et al. (PEP-able) References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> <39773B95.2B70EBBC@prescod.net> <397765DA.133518A2@lemburg.com> <39776C90.67FAFFD8@prescod.net> Message-ID: <39777248.9FE80D68@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > > def __setattr__( name, val ): > > > if attribute_to_set=="__class__": > > > assert PyClass_Check( val ): > > > elif attribute_to_set=="__dict__": > > > assert PyDict_Check( val ): > > > > But that's just an implementation detail (you either do the > > lookup via a mapping, e.g. the instance dict, or by switching > > on the attribute name)... in C and with only a few cases, the > > switching technique is faster than the lookup. > > That's not the case. In this case, Guido is doing type checking on sets. > You can only do that in Python with an __setattr__ hack. Huh ? "if attribute_to_set == ..." looks like a switch on attribute name to me. > > > It's just a cleaner, Pythonic way to do something that is already common > > > either using __getattr__ hacks or in extension modules. > > > > It's also *much* slower: you'd have to check objects for > > e.g. obj.__set_foo__ prior to every obj.foo=1 assignment. > > It's much, much faster for than __getattr__ for gets. It's probably no > slower than __setattr__ for sets because you aren't switching on the > attribute name in Python. Anyhow gets are much more common than sets so > speeding them up is a big win. __get_foo__ causes a Python function call and this is about the most costly activity there is in Python's internals. > > I think that these techniques are better implemented by > > writing a special proxy which then does your proposed > > mapping for a predefined set of attributes. > > Proxies are slow and introduce a host of their own "issues." In > practice, I've never seen anyone implement this pattern with proxies > unless the proxies were doing something else already (e.g. COM). They > always use a direct __getattr__/__setattr__. Sure, I meant proxies as good starting point for meta classes which deal with your proposed technique. BTW, proxies written in C are fast -- __getattr__ in C is within practical range. > > I usually use the direct attribute access method for > > information containers and the method access for more > > elaborate objects (ones which care about the data format, > > apply extra checks, depend on state, etc.). Very often > > these methods set more than just one attribute, so using > > __set_foo__ wouldn't work here. > > Don't follow. Here's an example that: (Note: I described my personal style -- not as general rule or guideline.) > * cares about data format > * applies extra checks > * is state dependent > * sets more than one attribute internally > > def __set_enddate__( self, val ): > if len(val)==3 and val>self.start_date > self.endday, self.endmonth, self.endyear=val > else: > raise TypeError > > def __get_enddate__(self, val): > return self.endday, self.endmonth, self.endyear > > obj.enddate=(15, 12, 2000) > print obj.endday > print obj.endmonth > print obj.endyear > > d,m,y=obj.enddate Well, yes. It works. But tell me: how are you going to debug this ? Assignments will suddenly raise exceptions and the traceback won't be of any use for programmers to find the true error location. Too much magic and too many possibilities for overloading dots ;-) (I've never understood why Javascript causes a new URL to be shown when your assign to top.window.location.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From peter at schneider-kamp.de Fri Jul 21 01:49:02 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 20 Jul 2000 23:49:02 +0000 Subject: [Python-Dev] ANSIfication again ;) References: <20000720221300.W9897@xs4all.nl> Message-ID: <39778FEE.88427388@schneider-kamp.de> Thomas Wouters wrote: > > And I fixed almost all of the instances of K&R C syntax. However, I found a > lot of instances of the 2nd type: empty argument list. However, as far as I > remember, ANSI C states that should be written as '(void)'. Is that a > non-issue, and should I not bother fixing those ? (Most of the files in > Modules/ has one or more instances of those.) Yes, I think that's right. I just looked at them and thought: Oh, no parameters - no work ;-) But then even "gcc -pedantic -ansi" doesn't care about this. Take that as a +0. > I also found a number of files which were already converted to ANSI syntax, > but with one function leftover. Should I bother uploading a patch for those, > or can I just commit them ? They're only a few lines per file, after all. I'd guess that if you feel that it's right and there is no functional change involved no one will object. not-feeling-competent-enough-for-a-straight-"just-do-it"-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mal at lemburg.com Thu Jul 20 23:56:07 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 23:56:07 +0200 Subject: [Python-Dev] uPEP: encoding directive References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> Message-ID: <39777577.316F1B9@lemburg.com> Fredrik Lundh wrote: > > > [paul] > > > Also, is it really necessary to allow raw non-ASCII characters in source > > > code though? We know that they aren't portable across editing > > > environments, so one person's happy face will be another person's left > > > double-dagger. > > > > [me] > > I suppose changing that would break code. maybe it's time > > to reopen the "pragma encoding" thread? > > > > (I'll dig up my old proposal, and post it under a new subject). > > as brief as I can make it: > 1. add support for "compiler directives". I suggest the following > syntax, loosely based on XML: > > #?python key=value [, key=value ...] > > (note that "#?python" will be treated as a token after this change. > if someone happens to use comments that start with #?python, > they'll get a "SyntaxError: bad #?python compiler directive"...) > > 2. for now, only accept compiler directives if they appear before > the first "real" statement. > > 3. keys are python identifiers (NAME tokens), values are simple > literals (STRING, NUMBER) > > 4. key/value pairs are collected in a dictionary. > > [...] I like the proposal, but how would you implement this ? Note that strings are decoded in compiler.c after having run the source through the tokenizer (which eliminates the comments). You'd have to carry the encoding information through to the compiler somehow. There's also a different problem to this: dynamic compilation. What encoding should eval() and exec use or expect ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Fri Jul 21 00:02:14 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 21 Jul 2000 00:02:14 +0200 Subject: [Python-Dev] converting PEPs to HTML References: <39774A29.86E469BB@schneider-kamp.de> <008901bff283$2d55d2a0$f2a6b5d4@hagrid> Message-ID: <003901bff296$377cb880$f2a6b5d4@hagrid> I've hacked a little more on the conversion script. here's the resulting HTML files: http://w1.132.telia.com/~u13208596/peps/ and here's the script itself: http://w1.132.telia.com/~u13208596/peps/pepfixup.py enjoy /F From effbot at telia.com Fri Jul 21 00:08:36 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 21 Jul 2000 00:08:36 +0200 Subject: [Python-Dev] ANSIfication again ;) References: <20000720221300.W9897@xs4all.nl> <39778FEE.88427388@schneider-kamp.de> Message-ID: <004901bff297$0f4c37e0$f2a6b5d4@hagrid> peter wrote: > thomas wrote: > > However, as far as I remember, ANSI C states that should be written > > as '(void)'. Is that a non-issue, and should I not bother fixing those ? > > (Most of the files in Modules/ has one or more instances of those.) > > Yes, I think that's right. I just looked at them and thought: Oh, no > parameters - no work ;-) > > But then even "gcc -pedantic -ansi" doesn't care about this. > Take that as a +0. strictly speaking, (void) and () are two different things: "If the function does not expect any arguments, you write only the keyword void void reset(void); no arguments, no return ... "You can also declare a function and not provide information about the number or types of its arguments. Do not write declarations within the parentheses of the function decoration. double bessel(); no argument information (from http://www-ccs.ucsd.edu/c/function.html) but I guess it's up to you if you want to be more pedantic than -pedantic... From paul at prescod.net Fri Jul 21 00:03:34 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 17:03:34 -0500 Subject: [Python-Dev] __set_foo__ et al. (PEP-able) References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> <39773B95.2B70EBBC@prescod.net> <397765DA.133518A2@lemburg.com> <39776C90.67FAFFD8@prescod.net> <39777248.9FE80D68@lemburg.com> Message-ID: <39777736.EB18917E@prescod.net> "M.-A. Lemburg" wrote: > > Paul Prescod wrote: > > > > "M.-A. Lemburg" wrote: > > > > > > > def __setattr__( name, val ): > > > > if attribute_to_set=="__class__": > > > > assert PyClass_Check( val ): > > > > elif attribute_to_set=="__dict__": > > > > assert PyDict_Check( val ): > > > > > That's not the case. In this case, Guido is doing type checking on sets. > > You can only do that in Python with an __setattr__ hack. > > Huh ? "if attribute_to_set == ..." looks like a switch on > attribute name to me. But he's doing the switch not for performance reasons but to check the data value before allowing the assignment! In Python you might do it for the same basic reason. > __get_foo__ causes a Python function call and this is about > the most costly activity there is in Python's internals. You wouldn't use __get_foo__ unless you *needed to do some computation*. Therefore you shouldn't compare it to anything OTHER than a Python function call. The appropriate comparision is to __getattr__ with a big switch statement or code. > Well, yes. It works. But tell me: how are you going to debug > this ? Assignments will suddenly raise exceptions and the > traceback won't be of any use for programmers to find the > true error location. Assignments can raise exceptions today. Try assigning to tuple slot. The traceback will go through the code that did the assignment. It won't be at the bottom of the traceback but it will appear. The traceback will be MORE useful than the altenatives of either a proxy or __getattr__. > Too much magic and too many possibilities for overloading > dots ;-) Python already gives you the ability to do this magic and we do it all over the place. The question is whether to make it a little more reliable, performant and consistent or not. > (I've never understood why Javascript causes a new URL to be shown > when your assign to top.window.location.) Well a Python web-browser could implement the same poor design decision *today*. I am going to make it easier but I'm not going to force people to use it! -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From skip at mojam.com Fri Jul 21 00:05:04 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 20 Jul 2000 17:05:04 -0500 (CDT) Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <39778FEE.88427388@schneider-kamp.de> References: <20000720221300.W9897@xs4all.nl> <39778FEE.88427388@schneider-kamp.de> Message-ID: <14711.30608.650773.223155@beluga.mojam.com> [ () vs. (void) in ANSI C ] Peter> But then even "gcc -pedantic -ansi" doesn't care about this. I doubt it should. "()" is perfectly valid ANSI C isn't it? As I recall it means "I know nothing about this function's input parameters, so I won't check it." On the other hand, "(void)" means "This function takes precisely zero input args". Skip From pingster at ilm.com Fri Jul 21 00:09:30 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 20 Jul 2000 15:09:30 -0700 (PDT) Subject: [Python-Dev] realpath? Message-ID: We have normpath() and readlink(), but how about realpath()? Seems like a good thing to have in the posixmodule. The man page for the C routine says: char *realpath (const char *file_name, char *resolved_name); DESCRIPTION realpath resolves all links, symbolic links, and references to ``.'' and ``..'' in file_name and stores it in resolved_name. It can handle both relative and absolute path names. For absolute path names and the relative names whose resolved name cannot be expressed relatively (for example, ../../reldir), it returns the resolved absolute name. resolved_name should point to a buffer (MAXPATHLEN) bytes in length to contain the fully resolved path name. -- ?!ng From effbot at telia.com Fri Jul 21 00:21:08 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 21 Jul 2000 00:21:08 +0200 Subject: [Python-Dev] [patch #100927] Fix for broken gethostbyname("0") Message-ID: <005d01bff298$d2fcd900$f2a6b5d4@hagrid> this patch by Pekka Pessi adds support for "0" and "-1" to gethostbyname: "0" (a string, not an integer) is the same thing as "" (INADDR_ANY) "-1" is the same thing as "". (INADDR_BROADCAST) Pekka hasn't followed up on my comments on the patch page, so I thought I'd take the question to this forum in- stead: -- why is gethostbyname "broken" if it doesn't support the magic strings "0" and "-1"? I'm tempted to reject the patch, but I'm probably missing something here... From gstein at lyra.org Fri Jul 21 00:26:33 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 20 Jul 2000 15:26:33 -0700 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <14711.2226.242735.766934@beluga.mojam.com>; from skip@mojam.com on Thu, Jul 20, 2000 at 09:12:02AM -0500 References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> Message-ID: <20000720152633.H8820@lyra.org> On Thu, Jul 20, 2000 at 09:12:02AM -0500, Skip Montanaro wrote: > > Peter> But in the long run this probably should be automated. I only see > Peter> the password barrier: > > Peter> scp pep-*.txt nowonder at shell.sourceforge.net:/home/groups/python/htdocs/peps > Peter> will make me enter my password/passphrase. > > Peter> How would one go about doing something like that? > > ... ssh-agent ... Easier than ssh-agent is to create an "authorized_keys" file. Log onto the shell box and type "mkdir .ssh". Next, copy the .ssh/identity.pub file from your local machine to .ssh/authorized_keys on shell.sourceforge.net. From effbot at telia.com Fri Jul 21 00:31:22 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 21 Jul 2000 00:31:22 +0200 Subject: [Python-Dev] realpath? References: Message-ID: <006b01bff29a$3ca51380$f2a6b5d4@hagrid> ?!ng wrote: > We have normpath() and readlink(), but how about realpath()? > > Seems like a good thing to have in the posixmodule. it's in SUSv2, so +1 from me. but don't forget #if defined(HAVE_REALPATH). what's the best way to emulate this one on Windows, btw? From peter at schneider-kamp.de Fri Jul 21 02:53:25 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 21 Jul 2000 00:53:25 +0000 Subject: [Python-Dev] [ANNOUNCE] Python Enhancement Proposals on the Web Message-ID: <39779F05.3181C5E5@schneider-kamp.de> The so called PEPs (Python Enhancement Proposals) are now available on the web at http://python.sourceforge.net/peps Thanks to /F who hacked up a small pep2html converter you can browse them as hypertext rather than as the plain text they are. PEPs that already carry some content include: 0201 Parallel Iteration bwarsaw 0203 Augmented Assignments twouters 0204 Range Literals twouters 0206 2.0 Batteries Included moshez Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gstein at lyra.org Fri Jul 21 00:54:52 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 20 Jul 2000 15:54:52 -0700 Subject: [Python-Dev] Re: [patch #100895 ] PyErr_Format In-Reply-To: ; from moshez@math.huji.ac.il on Thu, Jul 20, 2000 at 10:04:15PM +0300 References: <39773677.B3543269@prescod.net> Message-ID: <20000720155451.K8820@lyra.org> On Thu, Jul 20, 2000 at 10:04:15PM +0300, Moshe Zadka wrote: > > [M.-A. Lemburg] > > You add your new PyErr_Format() replacement with the existing > > subset of codes, but instead of bailing out when the function > > sees a format code it doesn't understand, you use sprintf() > > or snprintf() (where available) to format the unkown code ?! > > [Paul Prescod] > > I think its too magical and could hide security holes under too many > > levels of conditional behavior. > > FWIW, I agree with Paul -- if an unknown format code is used, it will be > plainly seen in the exception, so we will know *exactly* what popular > format codes we forgot to add. Agreed. Just punt on unknown codes. The "failure mode" is obvious and the fix is easy. We don't need complexity to resolve something which is obvious and easy. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Fri Jul 21 00:57:41 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 20 Jul 2000 15:57:41 -0700 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) In-Reply-To: <00b801bff1a9$248f4780$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jul 19, 2000 at 07:45:23PM +0200 References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> Message-ID: <20000720155741.L8820@lyra.org> On Wed, Jul 19, 2000 at 07:45:23PM +0200, Fredrik Lundh wrote: >... > if I understood GvR correctly, the only remaining issue here > is whether we need more formatting codes I would say "no. let's wait and implement when a need is discovered." > (PyErr_Format is undocumented, so I'm not sure we need to > be backwards compatible with code outside the interpreter...) > > in an earlier post, I suggested adding a couple of PyErr_Format- > specific formatting codes: > > possibly stupid idea: would it make sense to add custom > formatting codes, like: > > %S => char*, string, clip if excessively long > %T => PyObject*, show name of type, clip if excessively long > > where "clip" means: > > truncate at 80 characters, and add "..." to indicate > that the string was truncated. > > this covers most of the places where %.\d+s are used (in > the Python core, at least...) > > comments? Punt. Keep it clean and simple. If a long value goes in, then so be it. There isn't a need for us to clean up after somebody's horrendous long-identifier code. The only reason stuff like %.300s exists is to prevent buffer overflows. It isn't because we are parents looking after little children :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From donb at init.com Fri Jul 21 02:33:11 2000 From: donb at init.com (Donald Beaudry) Date: Thu, 20 Jul 2000 20:33:11 -0400 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> Message-ID: <200007210033.UAA31657@zippy.init.com> Greg Stein wrote, > Easier than ssh-agent is to create an "authorized_keys" file. Log onto the > shell box and type "mkdir .ssh". Next, copy the .ssh/identity.pub file from > your local machine to .ssh/authorized_keys on shell.sourceforge.net. > > From then on, SF will used the auth'd key rather than asking for your > password. That's mostly correct, but... you are assuming that the private side of the key (.ssh/identity on the local host) has not been encrypted with a passphrase. If it has, the scp command will prompt for it instead of the remote password. When using an encrypted private key ssh-agent is the answer. Personally, I am pretty paranoid about my private keys so (now ;) I always encrypt them. As a loose rule, I wont give anyone access to my systems (accept a public key) unless they at least tell me that their private key has been encrypted. How much trouble could could be caused by unauthorized access to your SF account? How secure is your private key? -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb at init.com Lexington, MA 02421 ...Will hack for sushi... From moshez at math.huji.ac.il Fri Jul 21 06:21:02 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 21 Jul 2000 07:21:02 +0300 (IDT) Subject: [Python-Dev] [patch #100927] Fix for broken gethostbyname("0") In-Reply-To: <005d01bff298$d2fcd900$f2a6b5d4@hagrid> Message-ID: On Fri, 21 Jul 2000, Fredrik Lundh wrote: > this patch by Pekka Pessi adds support for "0" and "-1" > to gethostbyname: > > "0" (a string, not an integer) is the same thing as "" > (INADDR_ANY) > > "-1" is the same thing as "". > (INADDR_BROADCAST) > > Pekka hasn't followed up on my comments on the patch > page, so I thought I'd take the question to this forum in- > stead: > > -- why is gethostbyname "broken" if it doesn't > support the magic strings "0" and "-1"? > > I'm tempted to reject the patch, but I'm probably missing > something here... I'm -1 on the patch too. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Fri Jul 21 07:59:15 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 21 Jul 2000 07:59:15 +0200 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <200007210033.UAA31657@zippy.init.com>; from donb@init.com on Thu, Jul 20, 2000 at 08:33:11PM -0400 References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> Message-ID: <20000721075915.Y9897@xs4all.nl> On Thu, Jul 20, 2000 at 08:33:11PM -0400, Donald Beaudry wrote: > Greg Stein wrote, > > Easier than ssh-agent is to create an "authorized_keys" file. Log onto the > > shell box and type "mkdir .ssh". Next, copy the .ssh/identity.pub file from > > your local machine to .ssh/authorized_keys on shell.sourceforge.net. > > > > From then on, SF will used the auth'd key rather than asking for your > > password. > That's mostly correct, but... you are assuming that the private side > of the key (.ssh/identity on the local host) has not been encrypted > with a passphrase. If it has, the scp command will prompt for it > instead of the remote password. When using an encrypted private key > ssh-agent is the answer. > Personally, I am pretty paranoid about my private keys so (now ;) I > always encrypt them. As a loose rule, I wont give anyone access to my > systems (accept a public key) unless they at least tell me that their > private key has been encrypted. And that's perfectly sensible. I'm not a crypto-junkie in any way, but using ssh with non-passphrase-protected is dangerous stuff. We do use it, at XS4ALL, actually, for scripts to execute commands on remote machines, but we do it with seperate keysets, and restricted per host. Nevertheless, if one of those private keys ever gets stolen, it's very likely the thief can get access to semi-sensitive parts of our system. Using a authorized_keys scheme with an unencrypted private key makes your private key, something you 'have', your password, without coupling it to something you 'know'. So anyone who steals your private key can pretend to be you ;) For more security, I'd suggest a cronjob that connects to your ssh-agent first, and just bails out if you haven't an ssh-agent running. (That means a private key is only useful on a machine that also has an accompanying ssh-agent running, and the 'hacker' can assume your privileges. This is the case for the common root access hole, but not so if the machine is rebooted, for instance, to gain that root access, or if it's only a file-stealing hole instead of a full-access hole ;) Then again, I'm a system administrator for a high-profile ISP. I might be a tad paranoid myself ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Fri Jul 21 08:13:54 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 21 Jul 2000 08:13:54 +0200 Subject: [Python-Dev] [patch #100927] Fix for broken gethostbyname("0") In-Reply-To: <005d01bff298$d2fcd900$f2a6b5d4@hagrid>; from effbot@telia.com on Fri, Jul 21, 2000 at 12:21:08AM +0200 References: <005d01bff298$d2fcd900$f2a6b5d4@hagrid> Message-ID: <20000721081354.Z9897@xs4all.nl> On Fri, Jul 21, 2000 at 12:21:08AM +0200, Fredrik Lundh wrote: > Pekka hasn't followed up on my comments on the patch > page, so I thought I'd take the question to this forum in- > stead: > > -- why is gethostbyname "broken" if it doesn't > support the magic strings "0" and "-1"? > I'm tempted to reject the patch, but I'm probably missing > something here... Well, '0' is a valid ipaddress. Strange, but valid. An ipaddress needn't contain any dots ;) it's just a 32bit value, after all. The dot-notation is for convenience, mostly: centurion:~ > ping 0 PING 0 (0.0.0.0) from 127.0.0.1 : 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.1 ms (This is also the reason '127.0.0.1' can be written as '127.1') You can also type things like 'http://2224488794' in most browsers. Go ahead, try it ;) So I'd say: accept "0". It's valid behaviour. However, -1 is something else: centurion:~ > ping -- -1 ping: unknown host -1 I can see where it comes from, as it should be interpreted as 0xFFFFFFFF, but it's not a convention I'm aware of. And it's also not 'an ipaddress in dot notation', because there can't be negative values in an ipaddress even if you leave out the dots. All in all, I'm +1 on the first, -1 on the second. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Fri Jul 21 08:18:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 21 Jul 2000 08:18:08 +0200 Subject: [Python-Dev] Consistency questions In-Reply-To: <39773DBB.9480F7BF@prescod.net>; from paul@prescod.net on Thu, Jul 20, 2000 at 12:58:19PM -0500 References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> <20000720172108.S9897@xs4all.nl> <14711.8162.800169.884936@beluga.mojam.com> <39773DBB.9480F7BF@prescod.net> Message-ID: <20000721081808.A9897@xs4all.nl> On Thu, Jul 20, 2000 at 12:58:19PM -0500, Paul Prescod wrote: > I think that Thomas is right that there is going to be a fair bit of > code that manually worked around this limitation in dir and now will get > two copies of some attributes. What do you think about > attrs( foo ) Hm, "methods and attributes are different things, right ?" I catch my newbie colleagues thinking that all the time ;P How about 'ls' ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov at inrialpes.fr Fri Jul 21 14:27:45 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 21 Jul 2000 14:27:45 +0200 (CEST) Subject: [Python-Dev] object allocator Message-ID: <200007211227.OAA04028@python.inrialpes.fr> I've spent some time recently in reviving the pymalloc project, and now that Python has GC and is fairly clean w.r.t. its allocators, I think I'm going to suggest the inclusion of pymalloc as an object allocator (i.e. obmalloc). Three main reasons motivate this suggestion: 1. obmalloc keeps under control the memory allocated for most objects; 2. it compensates for the space overhead induced by GC; 3. it gives worthy speedups. To give it a try, see: http://starship.beopen.com/crew/vlad/pymalloc/ It's basically a VMM aware, generalized free list implementation which handles dynamically small mem blocks (small = under 64 bytes for combos with 4-byte pointers). This accounts for > 95% of all object structs allocated by Python. Thread safety is disabled (just like the other object-specific allocators). There's no profiling for the moment. I'm going to rewrite entirely the stats code, but still, give it a try in the meantime. I have only rough numbers, but my preliminary tests indicate that for memory consuming scripts, GC increases the peak mem usage by more than 5% (5 to 15% and up) compared to no-GC, and obmalloc decreases that to something in between GC and no-GC. Sometimes also below no-GC. This is due to the fact that obmalloc does not introduce per block overhead for every allocation, as standard libc mallocs do. I consistently get speedups of 3%-20% for long-enough running scripts (on Linux, Solaris and AIX). Regarding space, for low-mem consuming scripts, obmalloc increases the mem usage (reservation) as it preallocates & suballocates 256k blocks, but I'm not interested in low-mem consuming scripts. Things start to be interesting for higher mem consumptions. Just an example with regrtest.py on my setup: The (peak) requested memory is about 4 MB. GC adds 150 KB more compared to no-GC. With GC and with obmalloc, I sometimes get 100k less compared to no-GC. This is optimistic, but I won't argue more about it, because these are all virtual memory numbers. All this needs to be pursued, probably PEP'ed, but I think I can already emit my opinion about a compromise: If obmalloc.c gets in 2.0, I am okay to leave GC enabled for 2.0 final. Probably obmalloc needs to go in pair with GC. And Neil & al. can make use of it as a basis for further enhancements of the GC code (note that most of the object mem is now under Python's control). That said, it would be nice if you could test this code on your combos and report some results and impressions back here. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From nascheme at enme.ucalgary.ca Fri Jul 21 15:32:22 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 21 Jul 2000 07:32:22 -0600 Subject: [Python-Dev] object allocator In-Reply-To: <200007211227.OAA04028@python.inrialpes.fr>; from Vladimir Marangozov on Fri, Jul 21, 2000 at 02:27:45PM +0200 References: <200007211227.OAA04028@python.inrialpes.fr> Message-ID: <20000721073222.B25293@keymaster.enme.ucalgary.ca> Nice work Vladimir. I will definately check this out in more detail when I get my home computer back. I'm hoping we can group objects with gc_prev and gc_next pointers and reduce the memory overhead. Neil From skip at mojam.com Fri Jul 21 16:36:31 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 21 Jul 2000 09:36:31 -0500 (CDT) Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <200007210033.UAA31657@zippy.init.com> References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> Message-ID: <14712.24559.935141.849089@beluga.mojam.com> Donald> That's mostly correct, but... you are assuming that the private Donald> side of the key (.ssh/identity on the local host) has not been Donald> encrypted with a passphrase. If it has, the scp command will Donald> prompt for it instead of the remote password. When using an Donald> encrypted private key ssh-agent is the answer. Okay, someone has to admit ignorance. Might as well be me. ;-) 1. How can I tell if my .ssh/identity file has been encrypted? 2. If it hasn't, how do I encrypt it? When I run ssh-add, it prompts me for my passphrase. Is that sufficient to suggest I have an encrypted identity file? Skip From donb at init.com Fri Jul 21 16:44:47 2000 From: donb at init.com (Donald Beaudry) Date: Fri, 21 Jul 2000 10:44:47 -0400 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> <14712.24559.935141.849089@beluga.mojam.com> Message-ID: <200007211444.KAA04701@zippy.init.com> Skip Montanaro wrote, > Okay, someone has to admit ignorance. Might as well be me. ;-) > > 1. How can I tell if my .ssh/identity file has been encrypted? > 2. If it hasn't, how do I encrypt it? > > When I run ssh-add, it prompts me for my passphrase. Is that > sufficient to suggest I have an encrypted identity file? Yes. You will only be asked for a passphrase if your identity is encrypted. I dont know the answer to your first two questions. -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb at init.com Lexington, MA 02421 ...So much code, so little time... From peter at schneider-kamp.de Fri Jul 21 19:19:37 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 21 Jul 2000 17:19:37 +0000 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> <14712.24559.935141.849089@beluga.mojam.com> Message-ID: <39788629.85DE5CD7@schneider-kamp.de> Skip Montanaro wrote: > > Okay, someone has to admit ignorance. Might as well be me. ;-) > > 1. How can I tell if my .ssh/identity file has been encrypted? If you are prompted for a passphrase and giving that passphrase let's you work, then everything should be fine with your identity. > 2. If it hasn't, how do I encrypt it? You choose the passphrase when you generate the key with ssh-keygen. To change it call: ssh-keygen -p Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul at prescod.net Fri Jul 21 18:25:39 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 11:25:39 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 Message-ID: <39787983.9682ABC5@prescod.net> I don't have a PEP number for this yet but I wanted to go through another round of comments after changing the mechanism according to Don Beaudry's suggestions. The name has been changed because every attribute is computed at some point or another. The important thing is that we are defining methods that trap sets/gets to attributes. PEP: ??? Title: Attribute Access Handlers Version: $Revision: 1.0 $ Owner: paul at prescod.net Python-Version: 2.0 Status: Incomplete Introduction It is possible (and even relatively common) in Python code and in extension modules to "trap" when an instance's client code attempts to set an attribute and execute code instead. In other words it is possible to allow users to use attribute assignment/ retrieval/deletion syntax even though the underlying implementation is doing some computation rather than directly modifying a binding. This PEP describes a feature that makes it easier, more efficient and safer to implement these handlers in Python than it is today. Justification Scenario 1: You have a deployed class that works on an attribute named "stdout". After a while, you think it would be better to check that stdout is really an object with a "write" method at the moment of assignment. Rather than change to a setstdout method (which would be incompatible with deployed code) you would rather trap the assignment and check the object's type. Scenario 2: You want to be as compatible as possible with an object model that has a concept of attribute assignment. It could be the W3C Document Object Model or a particular COM interface (e.g. the PowerPoint interface). In that case you may well want attributes in the model to show up as attributes in the Python interface, even though the underlying implementation may not use attributes at all. Scenario 3: A user wants to make an attribute read-only. In short, this feature allows programmers to separate the interface of their module from the underlying implementation for whatever purpose. Again, this is not a new feature but merely a new syntax for an existing convention. Syntax Special methods should declare themselves with declarations of the following form: class x: def __attr_XXX__(self, op, val ): if op=="get": return someComputedValue(self.internal) elif op=="set": self.internal=someComputedValue(val) elif op=="del": del self.internal Client code looks like this: fooval=x.foo x.foo=fooval+5 del x.foo Semantics Attribute references of all three kinds should call the method. The op parameter can be "get"/"set"/"del". Of course this string will be interned so the actual checks for the string will be very fast. It is disallowed to actually have an attribute named XXX in the same instance as a method named __attr_XXX__. An implementation of __attr_XXX__ takes precedence over an implementation of __getattr__ based on the principle that __getattr__ is supposed to be invoked only after finding an appropriate attribute has failed. An implementation of __attr_XXX__ takes precedence over an implementation of __setattr__ in order to be consistent. The opposite choice seems fairly feasible also, however. The same goes for __del_y__. Proposed Implementation There is a new object called a computed attribute object. It has three attributes: get, set, delete. In PyClass_New, methods of the appropriate form will be detected and converted into objects (just like unbound method objects). Matching methods go in the same computed attribute object and missing methods are replaced with a stub that throws the TypeError. If there are any computed attributes at all, a flag is set. Let's call it "I_have_computed_attributes" for now. A get proceeds as usual until just before the object is returned. In addition to the current check whether the returned object is a method it would also check whether a returned object is a computed attribute. If so, it would invoke the getter method and return the value. To remove a computed attribute object you could directly fiddle with the dictionary. A set proceeds by checking the "I_have_computed_attributes" flag. If it is not set, everything proceeds as it does today. If it is set then we must do a dictionary get on the requested object name. If it returns a computed method attribute then we call the setter function with the value. If it returns any other object then we discard the result and continue as we do today. Note that having a computed attribute will affect attribute setting performance for all sets on a particular instance, but no more so than today. Gets are more efficient than they are today with __getattr__. The I_have_computed_attributes flag is intended to eliminate the performance degradation of an extra "get" per "set" for objects not using this feature. You might note that I have not proposed any logic to keep this flag up to date as attributes are added and removed from the instance's dictionary. This is consistent with current Python. If you add a __setattr__ method to an object after it is in use, that method will not behave as it would if it were available at "compile" time. The dynamism is arguably not worth the extra implementation effort. The implementation of delete is analogous to the implementation of set. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From nascheme at enme.ucalgary.ca Fri Jul 21 19:19:54 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 21 Jul 2000 11:19:54 -0600 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <39787983.9682ABC5@prescod.net>; from Paul Prescod on Fri, Jul 21, 2000 at 11:25:39AM -0500 References: <39787983.9682ABC5@prescod.net> Message-ID: <20000721111954.A27901@keymaster.enme.ucalgary.ca> On Fri, Jul 21, 2000 at 11:25:39AM -0500, Paul Prescod wrote: > PEP: ??? > Title: Attribute Access Handlers > Version: $Revision: 1.0 $ > Owner: paul at prescod.net > Python-Version: 2.0 > Status: Incomplete So far I'm a strong +1. I dislike the all or nothing approach of __setattr__ and the performance cost associated with it. Support for "attribute access handlers" should largely eliminate the need for writing attribute access wrappers (getters and setters). The benefits are that code is simpler (you can use object attributes directly for outside the class), performance is better, and you always have the option of computing the value in the future without changing code that uses the object. Neil From Vladimir.Marangozov at inrialpes.fr Fri Jul 21 19:26:15 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 21 Jul 2000 19:26:15 +0200 (CEST) Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <39787983.9682ABC5@prescod.net> from "Paul Prescod" at Jul 21, 2000 11:25:39 AM Message-ID: <200007211726.TAA04540@python.inrialpes.fr> Paul Prescod wrote: > > I don't have a PEP number for this yet but I wanted to go through > another round of comments after changing the mechanism according to Don > Beaudry's suggestions. > > The name has been changed because every attribute is computed at some > point or another. The important thing is that we are defining methods > that trap sets/gets to attributes. Paul, this is clearly unclear <0.1 wink>. I for one don't get it. The whole point of __getattr__, __setattr__ is to trap attribute accesses and assignment. Python lets you trap the attribute binding process through these two functions. At yes, it is common case, because people want to specialize the binding rules in an object's namespace. However, this is defined only for Python's instance objects. If this is intended to generalize the concept for builtin objects, then you reach the object model deficiencies (metacalass, type dochotomy, etc.) which is not a trivial problem. If you're running after performance, because this programmable trapping occurs only in Python, well, state it explicitely in your writing. I believe that you're running after the generalization. I am not sure that what's in this per-PEP is a generic solution though. Because you're discussing handlers written in Pythonland (and this is also unclear in your writing). Simply put, these handlers would be invoked by hooks taken into account by the C code. Except hooking dict lookups with Python or C handlers, I don't see the point of this PEP. If the handlers are written in Python, this is what you get with __getattr__ and __setattr__. If you think C handlers, well, tell us about it explicitely. or-I-am-missing-the-point-completely y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gmcm at hypernet.com Fri Jul 21 19:45:27 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Fri, 21 Jul 2000 13:45:27 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <39787983.9682ABC5@prescod.net> Message-ID: <1247920968-15427430@hypernet.com> > I don't have a PEP number for this yet but I wanted to go through > another round of comments after changing the mechanism according > to Don Beaudry's suggestions. [snip] > Proposed Implementation > > There is a new object called a computed attribute object. It > has three attributes: get, set, delete. raise InternalInconsistencyError - Gordon From effbot at telia.com Fri Jul 21 20:31:53 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 21 Jul 2000 20:31:53 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0200.txt,1.1,1.2 References: <200007211813.LAA12850@slayer.i.sourceforge.net> Message-ID: <001a01bff341$f63119a0$f2a6b5d4@hagrid> some comments: > + * SyntaxError enhancements - Fredrik Lundh > + http://www.python.org/pipermail/python-dev/2000-July/012981.html ouch. what part of this "proposal" has been accepted? hopefully the latter part (the "error number" part). > + * snprintf - owner??? > + Use snprintf to avoid buffer overflows. Need configure hackery > + to discovery if it is available on the current platform and a > + default implementation if it is not. > + http://www.python.org/pipermail/python-dev/2000-April/010051.html > + This function is expected to be part of C9X (check). patch #100895, I hope. note that snprintf and this implementation are not equivalent (the safe version of PyErr_Format allocates a buffer large enough to hold the message). ... btw, don't forget patch #100941 (a bug fix to the new windows popen code). I'm working on a slightly modified version of David's patch -- should be ready for check in on monday... From paul at prescod.net Fri Jul 21 20:39:19 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 13:39:19 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <200007211726.TAA04540@python.inrialpes.fr> Message-ID: <397898D7.1D16A2B@prescod.net> Vladimir Marangozov wrote: > >... > Paul, this is clearly unclear <0.1 wink>. I for one don't get it. > The whole point of __getattr__, __setattr__ is to trap attribute > accesses and assignment. Sure, but ALL attribute accesses and assignment. What if you just want to trap one or two or ten? > However, this is defined only for Python's instance objects. If this > is intended to generalize the concept for builtin objects, then you > reach the object model deficiencies (metacalass, type dochotomy, etc.) > which is not a trivial problem. This feature has nothing to do with built-in types. Built-in types *always* use the getattr convention anyhow. > If you're running after performance, because this programmable trapping > occurs only in Python, well, state it explicitely in your writing. I mentioned performance explicitly in the introduction: > This PEP describes a feature that makes it easier, more efficient > and safer to implement these handlers in Python than it is today. Performance is only one of the goals. Clarity is the more major one. Safety is another. When you start combining __getattr__ with multiply inherited base class __getattr__ and so forth you get into a real mess. This proposal does not have that problem. > If the handlers are written in Python, this is what you get with __getattr__ > and __setattr__. If you think C handlers, well, tell us about it explicitely. The proposal explicitly says that the propsal allows nothing that getattr and setattr do not already allow. If you're looking for something that they do that this doesn't, you won't find it. Rather: > This PEP describes a feature that makes it easier, more efficient > and safer to implement these handlers in Python than it is today. Not a new ability, just a more structured way to exercise it. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Fri Jul 21 20:49:23 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 13:49:23 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <1247920968-15427430@hypernet.com> Message-ID: <39789B33.4C01AC03@prescod.net> Gordon McMillan wrote: > > [snip] > > > Proposed Implementation > > > > There is a new object called a computed attribute object. It > > has three attributes: get, set, delete. > > raise InternalInconsistencyError Good point. Here's a fix for that and something else I left out before. There is a new object type called a computed attribute object. Objects of this type have the following attributes: name (e.g. XXX, not __attr__XXX__ method (pointer to a method object In PyClass_New, methods of the appropriate form will be detected and converted into objects (just like unbound method objects). If there are any computed attributes in an instance at all, a flag is set. Let's call it "I_have_computed_attributes" for now. Derived classes inherit the flag from base classes. Instances inherit the flag from classes. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From donb at init.com Fri Jul 21 20:54:13 2000 From: donb at init.com (Donald Beaudry) Date: Fri, 21 Jul 2000 14:54:13 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <200007211726.TAA04540@python.inrialpes.fr> Message-ID: <200007211854.OAA06814@zippy.init.com> Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) wrote, > Paul, this is clearly unclear <0.1 wink>. I for one don't get it. > The whole point of __getattr__, __setattr__ is to trap attribute > accesses and assignment. Python lets you trap the attribute binding > process through these two functions. At yes, it is common case, > because people want to specialize the binding rules in an object's > namespace. The __getattr__ and __setattr__ mechanism is useful but hard to use. Paul's proposal suggests makeing it easier to override access for a single attribute.... or am I unclear on what you are unclear about? > However, this is defined only for Python's instance objects. If this > is intended to generalize the concept for builtin objects, then you > reach the object model deficiencies (metacalass, type dochotomy, etc.) > which is not a trivial problem. Whoa.... where did that come from. While the idea behind Paul's proposal could easily be applied to builtin objects (I've been using the technique for years) he's not even mentioning them in the proposal. It would still be up to the extension writer to decide how best to implement tp_setattr and tp_getattr. Only the instanceobject's tp_setattr and tp_getattr would need to change. > If you're running after performance, because this programmable > trapping occurs only in Python, well, state it explicitely in your > writing. I dont see performance as the big issue here. What I do see is a tidying up of a common usage of the current __setattr__/__getattr__ mechanism. For better or worse, it will make it much easier to write code which controls access to an attribute. > I believe that you're running after the generalization. I am not > sure that what's in this per-PEP is a generic solution > though. Because you're discussing handlers written in Pythonland > (and this is also unclear in your writing). Simply put, these > handlers would be invoked by hooks taken into account by the C > code. Except hooking dict lookups with Python or C handlers, I don't > see the point of this PEP. Wow! What does Paul's proposal have to do with hooking dict lookups? ...or is that what you are wondering? If that's what you are wondering, wonder no more. There is no connection. > If the handlers are written in Python, this is what you get with > __getattr__ and __setattr__. If you think C handlers, well, tell us > about it explicitely. Ah... now I see where *you* think Paul is going. To implement this, I would write up a little object called attrobject which would be very similar to a instancemethod. When the class is created I would check for methods whos names matched the __attr__XXX pattern. For each of these methods I would create an attrobject to wrap it then stick that back in the class dictionary under the name XXX. The tp_getattr method would then go through it's normal lookup procedure. But, before returning the result it would check the type of the object. If the object is an attrobject, the associated method would be called. The result of that call would be return from tp_getattr. The tp_setattr changes are where Paul's proposal loses. To make this work it becomes necessary to first attempt a "modified" getattr to determine if an attrobject exist for this attribute. I say "modified" getattr because in this case we dont really want to evaluate the attrobject. If no attrobject exists for the named attribute the set operation proceed as usual. If one does exist, it's associated method is called with the specified value. What hurts here is that it is now necessary to do that "modified" getattr on each set operation. If this is what you mean by "C handlers", then that's what Paul (in my opinion) is saying. Otherwise... -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb at init.com Lexington, MA 02421 ...Will hack for sushi... From donb at init.com Fri Jul 21 21:00:00 2000 From: donb at init.com (Donald Beaudry) Date: Fri, 21 Jul 2000 15:00:00 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <1247920968-15427430@hypernet.com> Message-ID: <200007211900.PAA06902@zippy.init.com> try: "Gordon McMillan" wrote, > > Proposed Implementation > > > > There is a new object called a computed attribute object. It > > has three attributes: get, set, delete. > > raise InternalInconsistencyError except InternalInconsistencyError: see_previous_posts_suggesting_get_set_del_all_be_moved_to_a_single_method() -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb at init.com Lexington, MA 02421 ...So much code, so little time... From bwarsaw at beopen.com Fri Jul 21 21:17:57 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 21 Jul 2000 15:17:57 -0400 (EDT) Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> <20000721075915.Y9897@xs4all.nl> Message-ID: <14712.41445.595701.546261@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> And that's perfectly sensible. I'm not a crypto-junkie in any TW> way, but using ssh with non-passphrase-protected is dangerous TW> stuff. We do use it, at XS4ALL, actually, for scripts to TW> execute commands on remote machines, but we do it with TW> seperate keysets, and restricted per host. Right, that's the way to do it. Remember that you can have multiple keypairs associated with your shell account, so if you /really/ wanted to do this (and I don't suggest it), then generate a new keypair, leave the new private key unpassphrase protected, and upload the new keypair to SF. Use this keypair only for SF so if it's cracked your exposure is minimized. As paranoid as I am, I usually generate new keypairs when I travel with my ssh client. I use that keypair only for that trip and discard it when I get back. -Barry From bwarsaw at beopen.com Fri Jul 21 21:30:33 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 21 Jul 2000 15:30:33 -0400 (EDT) Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> Message-ID: <14712.42201.725616.586420@anthem.concentric.net> >>>>> "PS" == Peter Schneider-Kamp writes: PS> I have put up the PEPs on http://python.sourceforge.net/peps/ Very cool, thanks! And thanks to /F for his conversion script PS> 1) Is that okay? No one cried out aloud and I got some PS> agreement. Yes, but I would make a couple of suggestions. 1) Let's change the project homepage to point to python.sourceforge.net with a prominent link back to www.python.org. Otherwise, /finding/ these peps and the other useful information isn't as convenient. 2) I'm not crazy about the front page for python.sourceforge.net. Do the links go with the blue box above or below the link? The first box say "On this site..." Which is this site? python.sourceforge.net or the site pointed to by the link above (or below :)? Do the blue boxes serve any real purpose? PS> 2) Should I put a link from http://python.sourceforge.net ? Which of course you did, so thanks! PS> 3) What about making those PEPs xhtml (or something like PS> that)? | Pros: | - links from pep-000.txt | - links from the other peps | Cons: | - harder to read in checkins | - harder to edit | (maybe we could use as little markup as possible?) Definitely -1 as other have said. PEPs should be plain text. /F's conversion script is perfect. -Barry From paul at prescod.net Fri Jul 21 21:36:47 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 14:36:47 -0500 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> Message-ID: <3978A64F.249C22F3@prescod.net> "Barry A. Warsaw" wrote: > > 2) I'm not crazy about the front page for python.sourceforge.net. > Do the links go with the blue box above or below the link? The > first box say "On this site..." Which is this site? > python.sourceforge.net or the site pointed to by the link above (or > below :)? Do the blue boxes serve any real purpose? A clear title at the top would be good. The other titles don't need to be in all caps. The blue tables are not necessary. Keep it simple Schneider-Kamp :) Still, what is there is so much better than what was there before that I feel bad complaining. It's definately an important development! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gmcm at hypernet.com Fri Jul 21 21:58:20 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Fri, 21 Jul 2000 15:58:20 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <397898D7.1D16A2B@prescod.net> Message-ID: <1247912995-15907044@hypernet.com> Paul Prescod wrote: > Performance is only one of the goals. Clarity is the more major > one. Safety is another. When you start combining __getattr__ with > multiply inherited base class __getattr__ and so forth you get > into a real mess. This proposal does not have that problem. You're doing some obsfucating here. Overriding a method with multiple base class implementations of that method with the desire to chain to one or more of the base class implementations of that method is a mess. It's not more of a mess because the method is named __getattr__. The obvious solution has nothing to do with the language - it's to use has-a instead of is-a. This proposal changes those semantics. Hooking an attribute masks anything in a base class with that name. That's probably a good thing, but it should be made explicit since that's not the way __getattr__ behaves. Similarly, there's a difference from __setattr__. If you assign to the instance.__dict__, the hook will no longer apply for that instance / attribute. Also note that while this is *safer* than __xxxattr__, it's still not *safe*. Infinite recursion is less likely, but still easily achieved. Truth-in-PEPs-ly y'rs - Gordon From paul at prescod.net Fri Jul 21 22:38:25 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 15:38:25 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <1247912995-15907044@hypernet.com> Message-ID: <3978B4C1.99BDD4CF@prescod.net> Gordon McMillan wrote: > > ... > > You're doing some obsfucating here. Overriding a method with > multiple base class implementations of that method with the > desire to chain to one or more of the base class > implementations of that method is a mess. It's not more of a > mess because the method is named __getattr__. > ... Solving the particular problem I am trying to solve is extremely messy in a deep hiearchy with one or more __getattr__ implementations. You must know about all of the parent getattrs and understand their semantics enough to to decide what order to call them in. If you think of getattr as "just another method" then there is no problem but it isn't just another method. It's a method that is used to implement a variety of radically different patterns. > This proposal changes those semantics. Hooking an attribute > masks anything in a base class with that name. That's > probably a good thing, but it should be made explicit since > that's not the way __getattr__ behaves. I don't see the difference. def __attr_XXX__( self, op, va ): Parent.__attr_XXX__( self, op, val ) You can still chain if you want. > Similarly, there's a difference from __setattr__. If you assign to > the instance.__dict__, the hook will no longer apply for that > instance / attribute. That's true. > Also note that while this is *safer* than __xxxattr__, it's still > not *safe*. Infinite recursion is less likely, but still easily > achieved. The ability to recurse infinitely is a property of methods in general, not this method in particular. Okay, it is a little more likely because of a logic flaw but I don't see that as being unsafe. I see the current __getattr__ hacks as being unsafe because in a deep inheritance hierarchy a seemingly insignicant addition in one place will break code somewhere else. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From gmcm at hypernet.com Fri Jul 21 23:27:29 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Fri, 21 Jul 2000 17:27:29 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <3978B4C1.99BDD4CF@prescod.net> Message-ID: <1247907646-16228779@hypernet.com> Paul Prescod wrote: > Gordon McMillan wrote: > > This proposal changes those semantics. Hooking an attribute > > masks anything in a base class with that name. That's probably > > a good thing, but it should be made explicit since that's not > > the way __getattr__ behaves. > > I don't see the difference. > > def __attr_XXX__( self, op, va ): > Parent.__attr_XXX__( self, op, val ) > > You can still chain if you want. You can? Your proposal only specified that when the class object is being created, method names of the form __attr_XXX__ would cause stuff to happen in the way the class is built. You never said that accesses to things named __YYY_XXX__ on another object would also get transformed into something else. Also, what if the base class just has "attr" - not a hook at all? It will be masked by the hook (which is the difference in behavior I was pointing out). > > Similarly, there's a difference from __setattr__. If you assign > > to the instance.__dict__, the hook will no longer apply for > > that instance / attribute. > > That's true. > > > Also note that while this is *safer* than __xxxattr__, it's > > still not *safe*. Infinite recursion is less likely, but still > > easily achieved. > > The ability to recurse infinitely is a property of methods in > general, not this method in particular. Okay, it is a little more > likely because of a logic flaw but I don't see that as being > unsafe. And earlier I said: > > Overriding a method with > > multiple base class implementations of that method with the > > desire to chain to one or more of the base class > > implementations of that method is a mess. It's not more of a > > mess because the method is named __getattr__. ... So I guess we're even, since we've used the same argument both ways. > I see the current __getattr__ hacks as being unsafe because in a > deep inheritance hierarchy a seemingly insignicant addition in > one place will break code somewhere else. Deep inheritance hierarchies are unpythonic <0.001 wink>. - Gordon From paul at prescod.net Fri Jul 21 23:54:24 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 16:54:24 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <1247907646-16228779@hypernet.com> Message-ID: <3978C690.ED273B22@prescod.net> Gordon McMillan wrote: > > You can? Your proposal only specified that when the class > object is being created, method names of the form > __attr_XXX__ would cause stuff to happen in the way the class > is built. You never said that accesses to things named > __YYY_XXX__ on another object would also get transformed > into something else. I would say that __attr_XXX__ causes two things to go into the __dict__: __attr_XXX___ = XXX = So you can call __attr_XXX__ directly just as you can call __getattr__ directly or __init__ etc. > Deep inheritance hierarchies are unpythonic <0.001 wink>. I'm told that in Zope even shallow hiearchies that use __getattr__ cause problems. I proposed this idea about three years ago. I'm only bringing it up again now because of a problem getting the DOM to work with Zope because of Zope's use of __getattr__. I'm told this has gotten better recently but I still see it as a symptom of a problem. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From bckfnn at worldonline.dk Fri Jul 21 23:59:53 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Fri, 21 Jul 2000 21:59:53 GMT Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <39787983.9682ABC5@prescod.net> References: <39787983.9682ABC5@prescod.net> Message-ID: <3978c7bf.10449886@smtp.worldonline.dk> [Paul Prescod on computed attributes] I'm not sure how well this is connected, but I would like to describe an existing feature of JPython that allow for computed attributes. The implementation of every python object have three methods (a little simplified): public PyObject _doget(PyObject container) { return this; } public boolean _doset(PyObject container, PyObject value) { return false; } public boolean _dodel(PyObject container) { return false; } As part of the implementation of __getattr__, the _doget method is always called: public PyObject __findattr__(String name) { ... PyObject ret = __class__.lookup(name, false); if (ret != null) return ret._doget(this); return null; } This way each computed attribute get controll when accessed, modified and deleted. The hooks primary purpose is to support JPythons use of java bean properties, fields and methods. It is currently not available from within python, so it is not possible to define "def _doget(..)" in a python class. All this is just a datapoint. regards, finn From bwarsaw at beopen.com Sat Jul 22 02:16:37 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 21 Jul 2000 20:16:37 -0400 (EDT) Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <39787983.9682ABC5@prescod.net> <3978c7bf.10449886@smtp.worldonline.dk> Message-ID: <14712.59365.265600.645342@anthem.concentric.net> >>>>> "FB" == Finn Bock writes: FB> This way each computed attribute get controll when accessed, FB> modified and deleted. The hooks primary purpose is to support FB> JPythons use of java bean properties, fields and methods. It FB> is currently not available from within python, so it is not FB> possible to define "def _doget(..)" in a python class. FB> All this is just a datapoint. But a good one, and perhaps one to model CPython on. There are also similarities here with the Zope Acquisition model, which uses __of__ instead. So this is clearly a functionality that is very useful in some contexts. JPython's __findattr__ hook might also be useful because it allows interposition on the lookup of all names, i.e. not just missing names. In any event, we should look to JPython as an example of how it might be done, but once a formal mechanism is adopted for CPython, we'll add it to the language spec and update JPython to support the same mechanism. -Barry From hzhu at rocket.knowledgetrack.com Sat Jul 22 04:08:22 2000 From: hzhu at rocket.knowledgetrack.com (Huaiyu Zhu) Date: Fri, 21 Jul 2000 19:08:22 -0700 Subject: [Python-Dev] Re: questionnaire about zip and for loops In-Reply-To: <3976BDF7.82FB6C56@schneider-kamp.de> References: <3976BDF7.82FB6C56@schneider-kamp.de> Message-ID: <200007220208.TAA00997@rocket.knowledgetrack.com> You need to add a Reply-To: line so people wouldn't send to the list by mistake. It is also difficult for many editors and mailers to deal with long lines. Huaiyu In comp.lang.python, you wrote: >This is a slightly reduced version of a questionnaire run by Greg Wilson on some CS >grad students. > >I'd like to use the readers of comp.lang.python as guinea pigs this time. > >PLEASE SEND THE RESULTS TO mailto:peter at schneider-kamp.de - DON'T SEND THEM TO THE LIST > >Thanks for your time, >Peter > >----------------------------------------------------------------------------------------- > >The single and double loop below print the output shown: > >for x in [10, 20, 30]: for x in [10, 20, 30]: > print x for y in [1, 2, 3]: > print x+y >10 11 >20 12 >30 13 > 21 > 22 > 23 > 31 > 32 > 33 > >Match each of the following example for-loops to an output. Only make one cross per line. >Please consider each example on its own. >(Note that several examples may print the same thing.) > > > (1) (2) (3) (4) (5) (6) > > 11 11 11 11 error ?? > 22 12 22 12 > 33 13 21 > 21 22 > 22 31 > 23 32 > 31 > 32 > 33 > >(A) >for (x, y) in [[10, 1], [20, 2], [30, 3]]: x o o o o o > print x+y > >(B) >for [x, y] in zip([10, 20, 30], [1, 2, 3]): x o o o o o > print x+y > >(C) >for [x, y] in zip([10, 20, 30], [1, 2]): o o x o o o > print x+y > >(D) >for x; y in [10, 20, 30]; [1, 2, 3]: o o o o x o > print x+y > >(E) >for x; y in [10, 20, 30]; [1, 2]: o o o o x o > print x+y > >(F) >for x in [10, 20, 30]; y in [1, 2, 3]: o x o o o o > print x+y > >(G) >for x in [10, 20, 30]; y in [1, 2]: o o o x o o > print x+y > > >-- >Peter Schneider-Kamp ++47-7388-7331 >Herman Krags veg 51-11 mailto:peter at schneider-kamp.de >N-7050 Trondheim http://schneider-kamp.de > From peter at schneider-kamp.de Sat Jul 22 06:59:38 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 04:59:38 +0000 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> Message-ID: <39792A39.B5C71052@schneider-kamp.de> "Barry A. Warsaw" wrote: > > >>>>> "PS" == Peter Schneider-Kamp writes: > > PS> I have put up the PEPs on http://python.sourceforge.net/peps/ > > Very cool, thanks! And thanks to /F for his conversion script > > PS> 1) Is that okay? No one cried out aloud and I got some > PS> agreement. > > Yes, but I would make a couple of suggestions. > > 1) Let's change the project homepage to point to > python.sourceforge.net with a prominent link back to > www.python.org. Otherwise, /finding/ these peps and the other > useful information isn't as convenient. > > 2) I'm not crazy about the front page for python.sourceforge.net. > Do the links go with the blue box above or below the link? The > first box say "On this site..." Which is this site? > python.sourceforge.net or the site pointed to by the link above (or > below :)? Do the blue boxes serve any real purpose? I'm no big bad designer guy. I didn't like it either, but I figured that (as it is in the CVS) someone would come around and put something nicer there. Well, I've tried my luck once again. Hope this one is better: http://python.sourceforge.net feedback-appreciating-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From peter at schneider-kamp.de Sat Jul 22 07:03:39 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 05:03:39 +0000 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> Message-ID: <39792B2B.DA3D36DC@schneider-kamp.de> "Barry A. Warsaw" wrote: > > 1) Let's change the project homepage to point to > python.sourceforge.net with a prominent link back to > www.python.org. Otherwise, /finding/ these peps and the other > useful information isn't as convenient. Ah yes. If this is considered to be a Wise Idea(TM), then could someone with admin rights change this? ain't-no-project-admin-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul at prescod.net Sat Jul 22 05:07:48 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 22:07:48 -0500 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> <39792A39.B5C71052@schneider-kamp.de> Message-ID: <39791004.95AA6994@prescod.net> Peter Schneider-Kamp wrote: > >... > > Well, I've tried my luck once again. Hope this one is better: > http://python.sourceforge.net It's a beaut! Uncluttered and clean. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From bwarsaw at beopen.com Sat Jul 22 05:48:12 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 21 Jul 2000 23:48:12 -0400 (EDT) Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> <39792A39.B5C71052@schneider-kamp.de> Message-ID: <14713.6524.705655.958481@anthem.concentric.net> >>>>> "PS" == Peter Schneider-Kamp writes: PS> I'm no big bad designer guy. I didn't like it either, but I PS> figured that (as it is in the CVS) someone would come around PS> and put something nicer there. PS> Well, I've tried my luck once again. Hope this one is better: PS> http://python.sourceforge.net Perfect! >> 1) Let's change the project homepage to point to >> python.sourceforge.net with a prominent link back to >> www.python.org. Otherwise, /finding/ these peps and the other >> useful information isn't as convenient. PS> Ah yes. If this is considered to be a Wise Idea(TM), then PS> could someone with admin rights change this? Done. Thanks, -Barry From bwarsaw at beopen.com Sat Jul 22 06:47:32 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sat, 22 Jul 2000 00:47:32 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP Message-ID: <14713.10084.165489.836569@anthem.concentric.net> I've long wanted to make the print statement able to handle alternative output files in a more convenient syntax. Yes you can rebind sys.stdout, but that is often very clumsy to get right in the face of exceptions. All the talk about extra operators has made me giddy (no, not geddy :) so my proposal is to allow `@' after the print keyword using syntax such as: print @ sys.stderr, 'hello' The thing between the @ and the , must be an expression yeilding an object with a write() method, otherwise you'd get a runtime exception (probably TypeError). Thus, these two are equivalent: print @ sys.stdout, 'wassup?' print 'wassup?' It makes it quite convenient to do things like: f = open('log, 'w') print @ f, 'starting' do_something_that_expects_to_print_to_stdout() print @ f, 'ending' etc., etc. I started hacking on the grammar to play with this, but haven't gotten very far, and I'm way too tired to continue tonight. I'd continue though if there's positive feedback. Thoughts? -Barry From moshez at math.huji.ac.il Sat Jul 22 08:49:57 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 22 Jul 2000 09:49:57 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.10084.165489.836569@anthem.concentric.net> Message-ID: On Sat, 22 Jul 2000, Barry A. Warsaw wrote: > I've long wanted to make the print statement able to handle > alternative output files in a more convenient syntax. Yes you can > rebind sys.stdout, but that is often very clumsy to get right in the > face of exceptions. Then why not go the other way, and get sys.stdout-rebinding easier to get right? something like sys.push_stdout(fileobj) try: print and stuff finally: sys.pop_stdout() > Thoughts? Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating Python way too much. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From tim_one at email.msn.com Sat Jul 22 09:06:59 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 03:06:59 -0400 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <20000720221300.W9897@xs4all.nl> Message-ID: [posted & mailed] [Thomas Wouters] > ... > However, I found a lot of instances of the 2nd type: empty argument > list. However, as far as I remember, ANSI C states that should be > written as '(void)'. Yes. > I also found a number of files which were already converted to > ANSI syntax, but with one function leftover. Should I bother' uploading > a patch for those, or can I just commit them ? Commit. hard-not-to-make-the-sig-look-concise-after-that!-ly y'rs - tim From mhammond at skippinet.com.au Sat Jul 22 09:18:13 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 22 Jul 2000 17:18:13 +1000 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: Message-ID: > Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating > Python way too much. I've gotta agree here - I really am quite concerned about all the cool-but-not-really-necessary stuff being proposed. I fear that Python will no longer be the small, simple to understand system that drew many of us to it in the first place. OTOH, I have great faith that Guido will simply reject most of these ideas, regardless of the huge amount of work being spent on their PEPs, etc. At least, I _hope_ he does! Our-simple-Python-is-turning-into-Medusa-ly, Mark. From tim_one at email.msn.com Sat Jul 22 09:30:00 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 03:30:00 -0400 Subject: [Python-Dev] map() for methods In-Reply-To: <39771CCE.F70A48D4@lemburg.com> Message-ID: [Skip Montanaro] > Don't know about the powers that be, but I don't see how you can > realistically deprecate string.py until you deprecate map(). My most > frequent use of map() is the simple > > newlist = map(string.strip, oldlist) > > where oldlist is a list of strings. (Replace "strip" by > "upper", "lower", etc, depending on your needs.) > > As far as I'm aware, there's no clean way to do that with > string methods. Sorry if someone pointed this out already (2K+ msgs backed up!): newlist = [s.strip() for s in oldlist] Not that that's a reason to deprecate string.py, but this use of "map" is not a reason not to deprecate it either. Ditto for "map". From gstein at lyra.org Sat Jul 22 10:27:48 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 22 Jul 2000 01:27:48 -0700 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.10084.165489.836569@anthem.concentric.net>; from bwarsaw@beopen.com on Sat, Jul 22, 2000 at 12:47:32AM -0400 References: <14713.10084.165489.836569@anthem.concentric.net> Message-ID: <20000722012748.E10086@lyra.org> On Sat, Jul 22, 2000 at 12:47:32AM -0400, Barry A. Warsaw wrote: >... > All the talk about extra operators has made me giddy (no, not geddy :) > so my proposal is to allow `@' after the print keyword using syntax > such as: > > print @ sys.stderr, 'hello' Ick. -1 Use sys.stderr.write('hello\n') Cheers, -g -- Greg Stein, http://www.lyra.org/ From thomas at xs4all.net Sat Jul 22 10:32:05 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 10:32:05 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.10084.165489.836569@anthem.concentric.net>; from bwarsaw@beopen.com on Sat, Jul 22, 2000 at 12:47:32AM -0400 References: <14713.10084.165489.836569@anthem.concentric.net> Message-ID: <20000722103204.G9897@xs4all.nl> On Sat, Jul 22, 2000 at 12:47:32AM -0400, Barry A. Warsaw wrote: > I've long wanted to make the print statement able to handle > alternative output files in a more convenient syntax. Yes you can > rebind sys.stdout, but that is often very clumsy to get right in the > face of exceptions. > print @ sys.stderr, 'hello' No offense, but I'd rather deprecate 'print' than see this. For me, 'print' is for debugging purposes only (and possibly very teensy scripts.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From peter at schneider-kamp.de Sat Jul 22 12:33:29 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 10:33:29 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.7,1.8 References: <200007212003.NAA02595@slayer.i.sourceforge.net> Message-ID: <39797879.C63724A8@schneider-kamp.de> Barry Warsaw wrote: > > + 212 pep-0212.txt Additional Builtin Generators bwarsaw Whatever happened to 212? If you don't have anything ready yet I can commit an empty version. Just tell me. BTW: I cannot ssh to shell.sourceforge.net. It worked fine 5 hours ago. CVS over ssh works fine though. I sent a support request. I tried from different machines from different countries, with password or key identification (it never got so far). Is anyone experiencing similar problems? eating-breakfast-soon-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From thomas at xs4all.net Sat Jul 22 10:47:13 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 10:47:13 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 22, 2000 at 03:06:59AM -0400 References: <20000720221300.W9897@xs4all.nl> Message-ID: <20000722104713.H9897@xs4all.nl> On Sat, Jul 22, 2000 at 03:06:59AM -0400, Tim Peters wrote: > > I also found a number of files which were already converted to > > ANSI syntax, but with one function leftover. Should I bother' uploading > > a patch for those, or can I just commit them ? > Commit. Well, I already did that ;) I've also ANSIfied everything in Python/ and Parser/, and the couple of declarations in PC/ that were still using empty argument lists. The changes fall in two categories: those I can test (and have tested and seem to work fine) and those that I can't test because I haven't such expensive hardware. I'll upload the latter category, and I'm perfectly willing to upload the former one, too, but I wonder if anyone is actually going to review them ? If not, well, there's not much use in uploading them, is there ? Also, there is an issue with extern function declarations: should we change all those to full prototypes ? Some aren't too obvious (like the ^*@#$&** readline functions, which don't have prototypes to start with, and the info pages are not very helpful) and in one spot a function of the wrong type is passed to PyAddCallback, resulting in a new warning during -Wall ;) A cast can fix that, though. And then there is the question whether all those externs are really necessary. They seem to be put in because one OS or another was missing them in a header file, but giving them prototypes from a Linux system might give more warnings on other platforms: a 'const char **' is not the same pointer as a 'char **', even though a 'const char *' is the same as a 'char *'. Perhaps these prototyped function declarations should be put in pyport.h, instead, surrounded by platform #ifdefs ? Make-me-checkin-all-these-changes-and-I'll-end-up-next-to-Guido-on-the- -SourceForge-CVS-stats-ly y'rs, ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sat Jul 22 10:54:54 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 22 Jul 2000 10:54:54 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP References: Message-ID: <00d601bff3ba$8300d640$f2a6b5d4@hagrid> mark wrote: > I've gotta agree here - I really am quite concerned about all the > cool-but-not-really-necessary stuff being proposed. I fear that Python > will no longer be the small, simple to understand system that drew many of > us to it in the first place. that's only because you're a lazy guy, and don't want to have to implement one weird thing after another in your compiler, just be- cause someone submitted a patch to CPython ;-) (seriously, I *strongly* agree with what you're saying, but you already knew that, of course... or maybe that's just because I'm a lazy guy, and don't want to implement one weird thing after an- other in my tools) > OTOH, I have great faith that Guido will simply reject most of these ideas, > regardless of the huge amount of work being spent on their PEPs, etc. At > least, I _hope_ he does! well, if he doesn't, we can always join the Perl6 project... > Our-simple-Python-is-turning-into-Medusa-ly, hey, what's wrong with Sam's Medusa server? ;-) From thomas at xs4all.net Sat Jul 22 10:51:58 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 10:51:58 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.7,1.8 In-Reply-To: <39797879.C63724A8@schneider-kamp.de>; from peter@schneider-kamp.de on Sat, Jul 22, 2000 at 10:33:29AM +0000 References: <200007212003.NAA02595@slayer.i.sourceforge.net> <39797879.C63724A8@schneider-kamp.de> Message-ID: <20000722105158.I9897@xs4all.nl> On Sat, Jul 22, 2000 at 10:33:29AM +0000, Peter Schneider-Kamp wrote: > Barry Warsaw wrote: > > + 212 pep-0212.txt Additional Builtin Generators bwarsaw > Whatever happened to 212? If you don't have anything ready yet > I can commit an empty version. Just tell me. 'Whatever happened' is that Barry assigned himself to that PEP just yesterday, and has been too busy with all those other things to check even the template in ;) > BTW: I cannot ssh to shell.sourceforge.net. It worked fine 5 hours > ago. CVS over ssh works fine though. I sent a support request. > Is anyone experiencing similar problems? Ayup: centurion:~/python/python-anon/dist/src/Python > ssh -v shell.sourceforge.net SSH Version 1.2.27 [i586-unknown-linux], protocol version 1.5. Standard version. Does not use RSAREF. centurion.xs4all.nl: Reading configuration data /home/thomas/.ssh/config centurion.xs4all.nl: Applying options for * centurion.xs4all.nl: Reading configuration data /etc/ssh/ssh_config centurion.xs4all.nl: Applying options for * centurion.xs4all.nl: ssh_connect: getuid 500 geteuid 0 anon 0 centurion.xs4all.nl: Connecting to shell.sourceforge.net [198.186.203.36] port 22. centurion.xs4all.nl: Allocated local port 1013. centurion.xs4all.nl: Connection established. Connection closed by foreign host. 'ssh' is broken, or they have nameserver difficulties and a fascist-loggingly sshd, or the machines is just overtaxed or so. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sat Jul 22 11:03:51 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 22 Jul 2000 11:03:51 +0200 Subject: [Python-Dev] ANSIfication again ;) References: <20000720221300.W9897@xs4all.nl> <20000722104713.H9897@xs4all.nl> Message-ID: <00fd01bff3bb$c2f47da0$f2a6b5d4@hagrid> thomas wrote: > Make-me-checkin-all-these-changes-and-I'll-end-up-next-to-Guido-on-the- > -SourceForge-CVS-stats-ly y'rs, ;-) don't worry -- after the consortium meeting yesterday, he'll probably change the copyright on all files again... From effbot at telia.com Sat Jul 22 11:08:36 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 22 Jul 2000 11:08:36 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/sf-html at.gif,NONE,1.1 py.gif,NONE,1.1 sf.gif,NONE,1.1 index.html,1.2,1.3 References: <200007220253.TAA12076@slayer.i.sourceforge.net> Message-ID: <010701bff3bc$6be16cc0$f2a6b5d4@hagrid> peter wrote: > GIF89aT looks like you checked them in as text files... From peter at schneider-kamp.de Sat Jul 22 13:04:30 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 11:04:30 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.7,1.8 References: <200007212003.NAA02595@slayer.i.sourceforge.net> <39797879.C63724A8@schneider-kamp.de> <20000722105158.I9897@xs4all.nl> Message-ID: <39797FBE.A91CAFC6@schneider-kamp.de> Thomas Wouters wrote: > > 'Whatever happened' is that Barry assigned himself to that PEP just > yesterday, and has been too busy with all those other things to check even > the template in ;) I guessed so. I have checked in an empty template. > > Is anyone experiencing similar problems? > > Ayup: glad-it's-not-just-me-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From peter at schneider-kamp.de Sat Jul 22 13:28:34 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 11:28:34 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/sf-html at.gif,NONE,1.1 py.gif,NONE,1.1 sf.gif,NONE,1.1 index.html,1.2,1.3 References: <200007220253.TAA12076@slayer.i.sourceforge.net> <010701bff3bc$6be16cc0$f2a6b5d4@hagrid> Message-ID: <39798562.CEF75D2D@schneider-kamp.de> Fredrik Lundh wrote: > > looks like you checked them in as text files... oops. i removed them and added them as binary files. having-put-this-in-the-faq-so-I-can-remember-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From tim_one at email.msn.com Sat Jul 22 11:29:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 05:29:47 -0400 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <20000722104713.H9897@xs4all.nl> Message-ID: [Thomas Wouters] > ... > I've also ANSIfied everything in Python/ and Parser/, and the couple of > declarations in PC/ that were still using empty argument lists. > > The changes fall in two categories: those I can test (and have tested and > seem to work fine) and those that I can't test because I haven't such > expensive hardware. Didn't we go thru this before? If "expensive hardware" means SGI, Guido said commit SGI ANSIfication patches. > I'll upload the latter category, and I'm perfectly willing to upload > the former one, too, Does "upload" mean "submit a patch" or "commit"? Commit. > but I wonder if anyone is actually going to review them ? Don't want a patch for this. Commit. > ... > Also, there is an issue with extern function declarations: should > we change all those to full prototypes ? Every function call should have a prototype in scope. That's the answer to the question you meant to ask . > Some aren't too obvious (like the ^*@#$&** readline functions, which > don't have prototypes to start with, and the info pages are not very > helpful) and in one spot a function of the wrong type is passed to > PyAddCallback, resulting in a new warning during -Wall ;) A cast > can fix that, though. > > > And then there is the question whether all those externs are really > necessary. ... Every function call should have a prototype in scope. There is no other goal here -- ANSIfication is for a reason, not just to say "it's been ANSIfied". If this causes warnings, good! It's turning up bugs in the code then. Casts are rarely the correct way to fix those, though (e.g., *why* is a function of the wrong type being passed? don't cast the warning away without understanding that fully). > ... [...] ... Too much detail for me. Fix them or don't, but I don't think it needs this much discussion. If you don't know how to fix some particular one, try posting a focused single-issue msg about that particular one. > ... > Make-me-checkin-all-these-changes-and-I'll-end-up-next-to-Guido-on-the- > -SourceForge-CVS-stats-ly y'rs, ;-) Heh -- nothing would please him more! From thomas at xs4all.net Sat Jul 22 11:30:28 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 11:30:28 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <00fd01bff3bb$c2f47da0$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jul 22, 2000 at 11:03:51AM +0200 References: <20000720221300.W9897@xs4all.nl> <20000722104713.H9897@xs4all.nl> <00fd01bff3bb$c2f47da0$f2a6b5d4@hagrid> Message-ID: <20000722113028.J9897@xs4all.nl> On Sat, Jul 22, 2000 at 11:03:51AM +0200, Fredrik Lundh wrote: > > Make-me-checkin-all-these-changes-and-I'll-end-up-next-to-Guido-on-the- > > -SourceForge-CVS-stats-ly y'rs, ;-) > don't worry -- after the consortium meeting yesterday, he'll > probably change the copyright on all files again... Yeah, about the consortium meeting... any idea when the general public and grunts like us (well, me, in any case) get to hear the results ? The subject is pretty dear to us, you see ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sat Jul 22 11:38:16 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 11:38:16 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 22, 2000 at 05:29:47AM -0400 References: <20000722104713.H9897@xs4all.nl> Message-ID: <20000722113816.K9897@xs4all.nl> On Sat, Jul 22, 2000 at 05:29:47AM -0400, Tim Peters wrote: > [Thomas Wouters] > > The changes fall in two categories: those I can test (and have tested and > > seem to work fine) and those that I can't test because I haven't such > > expensive hardware. > Didn't we go thru this before? If "expensive hardware" means SGI, Guido > said commit SGI ANSIfication patches. OS/2, NT, etc, are quite a bit different from SGI. SGI is UNIX, which I grok. I can't claim the same for NT ;P > Does "upload" mean "submit a patch" or "commit"? Commit. upload means submit a patch. I was nearly done uploading them, too! I guess I'll mark them as 'accepted' and commit them instead. > > but I wonder if anyone is actually going to review them ? > Don't want a patch for this. Commit. Will do. I'll need to generate new ones for compile.c and ceval.c, though, because these were done relative to the range-literals patch. > Every function call should have a prototype in scope. That's the answer to > the question you meant to ask . Each time you post one of these 'go ahead and do it' messages, I go ahead and do it, thinking to myself, "he said that before". And then the next time I see something I'm not quite sure about, I think "he said to go ahead and do it... but that was not about 'this', it was about the slightly different 'that' instead." ;P Simply-trying-not-to-overstep-my-bounds-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sat Jul 22 12:13:03 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 22 Jul 2000 12:13:03 +0200 Subject: [Python-Dev] slightly OT: perl and tcl teams are reorganizing Message-ID: <018501bff3c5$70b54ce0$f2a6b5d4@hagrid> tcl: http://dev.ajubasolutions.com/community/coreteam/ perl: http://www.perl.org/perl6/ http://www.news.perl.org/perl-news.cgi?item=964033768%7C25110 From tim_one at email.msn.com Sat Jul 22 12:15:43 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 06:15:43 -0400 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <20000722113816.K9897@xs4all.nl> Message-ID: [Tim] >> Didn't we go thru this before? If "expensive hardware" means SGI, Guido >> said commit SGI ANSIfication patches. [Thomas Wouters] > OS/2, NT, etc, are quite a bit different from SGI. SGI is UNIX, which I > grok. I can't claim the same for NT ;P NT is expensive hardware? That MS .NET project is more ambitious than I thought . >> commit ... commit ... commit > Will do. Excellent. > ... > Each time you post one of these 'go ahead and do it' messages, I go > ahead and do it, thinking to myself, "he said that before". And then > the next time I see something I'm not quite sure about, I think "he > said to go ahead and do it... but that was not about 'this', it was > about the slightly different 'that' instead." ;P > > Simply-trying-not-to-overstep-my-bounds-ly y'rs, There's no way to find out your bounds *except* by going beyond them -- which, happily enough, is also the way to expand your bounds. If we didn't think you were a perfectly wonderful human being, you wouldn't have gotten commit access to begin with. Do note that Guido has yelled at people only a few times here so far, and all of those on the receiving end are still here -- including me. But then he was surely wrong to yell at me . an-exaggerated-sense-of-one's-own-importance-is-a-virtue- in-this-field-ly y'rs - tim From tim_one at email.msn.com Sat Jul 22 12:15:45 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 06:15:45 -0400 Subject: Consortium mtg non-news (was RE: [Python-Dev] ANSIfication again ;)) In-Reply-To: <20000722113028.J9897@xs4all.nl> Message-ID: [Thomas Wouters] > ... about the consortium meeting... any idea when the general public and > grunts like us (well, me, in any case) get to hear the results ? > The subject is pretty dear to us, you see ;-P Me too! Guido went to the consortium mtg on Friday, but Fred, Jeremy and I are not consortium members, so didn't attend -- we spent 12+ hours fighting to get home from California instead (Jeremy, you missed some delightful midnight freeway gridlock heading into VA), and haven't heard from Guido either. There was some good reason for optimism before the mtg. The only email Guido sent after the mtg was some bad news about PythonLabs office space, so I assume he didn't think good news was worth mentioning <0.9 wink>. may-as-well-study-the-entrails-of-a-pigeon-ly y'rs - tim From esr at thyrsus.com Sat Jul 22 12:55:46 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Sat, 22 Jul 2000 06:55:46 -0400 Subject: Consortium mtg non-news (was RE: [Python-Dev] ANSIfication again ;)) In-Reply-To: References: <20000722113028.J9897@xs4all.nl> Message-ID: <20000722065546.A18263@thyrsus.com> Tim Peters : > [Thomas Wouters] > > ... about the consortium meeting... any idea when the general public and > > grunts like us (well, me, in any case) get to hear the results ? > > The subject is pretty dear to us, you see ;-P > > Me too! Guido went to the consortium mtg on Friday, but Fred, Jeremy and I > are not consortium members, so didn't attend -- we spent 12+ hours fighting > to get home from California instead (Jeremy, you missed some delightful > midnight freeway gridlock heading into VA), and haven't heard from Guido > either. There was some good reason for optimism before the mtg. The only > email Guido sent after the mtg was some bad news about PythonLabs office > space, so I assume he didn't think good news was worth mentioning <0.9 > wink>. I won't steal Guido's thunder, but I will say that the meeting went well in all important respects (aside from being boring for long periods :-)). I think all the surprises will be pleasant ones. -- Eric S. Raymond Power concedes nothing without a demand. It never did, and it never will. Find out just what people will submit to, and you have found out the exact amount of injustice and wrong which will be imposed upon them; and these will continue until they are resisted with either words or blows, or with both. The limits of tyrants are prescribed by the endurance of those whom they oppress. -- Frederick Douglass, August 4, 1857 From effbot at telia.com Sat Jul 22 14:28:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 22 Jul 2000 14:28:19 +0200 Subject: [Python-Dev] slightly OT: perl and tcl teams are reorganizing References: <018501bff3c5$70b54ce0$f2a6b5d4@hagrid> Message-ID: <022601bff3d8$551ccea0$f2a6b5d4@hagrid> first this: > http://dev.ajubasolutions.com/community/coreteam/ ...new, larger, "batteries included" releases... and then I stumbled upon this little quote on comp.lang.tcl: > > IMO, it's obvious: Tcl needs to go where people are going. Glueing to > > each and every technology under the sun, and that includes Python and > > Perl. Closing the door out of fear of being overtaken by others would > > be a big mistake. > > And let us not forget that Guido himself posted a message to c.l.t > suggesting that python and tcl pool their work at the lower level > implementation. hmm. what exactly am I missing here? ;-) From akuchlin at cnri.reston.va.us Sat Jul 22 15:25:30 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 22 Jul 2000 09:25:30 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: ; from mhammond@skippinet.com.au on Sat, Jul 22, 2000 at 05:18:13PM +1000 References: Message-ID: <20000722092530.A24247@newcnri.cnri.reston.va.us> On Sat, Jul 22, 2000 at 05:18:13PM +1000, Mark Hammond quoted: >> Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating >> Python way too much. and then wrote: >I've gotta agree here - I really am quite concerned about all the >cool-but-not-really-necessary stuff being proposed. I fear that Python Seconded from me. IMHO it's only worth adding a new feature if it multiplies power by a significant amount; if it just adds a tiny increment, it's not worth adding a small bit of extra complexity, extra code, and having to resync JPython and Python# (does that project have a name yet?). The urge to add little tiny things that make microtask X convenient is what made Perl -- and Sendmail, and DTML, and ... -- what they are today. --amk From guido at python.org Sat Jul 22 15:35:38 2000 From: guido at python.org (Guido van Rossum) Date: Sat, 22 Jul 2000 06:35:38 -0700 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722113028.J9897@xs4all.nl> <20000722065546.A18263@thyrsus.com> Message-ID: <003301bff3e1$bd5dde60$360bfea9@beopen.com> The meeting went well. Some major conclusions: - The latest license proposed by CNRI (attached) is acceptable to the consortium members and to OSI (the Open Source Initiative); Eric Raymond (who is on the OSI board) believes there will be no trouble getting it approved as Open Source at the next board meeting, which happens to be next Friday. There are remaining lingering grumblings from Richard Stallman, but these all seem to hinge on slight misreadings on his side; we believe the license is GPL compatible. We will work this out with Stallman over the next few weeks. - The python.org website will be hosted at SourceForge. As a community resource, it will be run in a way that does not advantage any one party (read: no banner ads). We will expedite transformation to Zope (Digital Creations has offered to help!), but the first priority is to get the existing site moved. Pending the move, the PythonLabs folks will be able to maintain the site as it currently exists at CNRI, like before. - Python 1.6 (a CNRI release with PythonLabs' help) will come out with CNRI's Open Source License in two phases: a beta around August 1st, and a final release mid-August (of course this schedule is subject to the usual qualifications). This will release all of the work on Python done at CNRI since 1.5.2 was released to the public -- a significant step. - Python 2.0 (a BeOpen PythonLabs release) will start with a beta release 1-2 weeks after 1.6 final is released; we're striving for a short beta cycle. New language features will include list comprehensions, range literals, the zip() function, and augmented assignment. I would like to thank all who helped reaching this conclusion: CNRI's Bob Kahn for traveling out west to discuss these issues in person, Eric Raymond and Bruce Perens for their useful contributions to the negotiations, BeOpen's Bob Weiner for taking care of the bulk of the negotiations, and the consortium member representatives for making the meeting a success! --Guido van Rossum [Note that I'm cc'ing Kahn, Perens and the consortium mailing list; please take these off your CC list when replying to this message in the python-dev list!!!] -------------- next part -------------- A non-text attachment was scrubbed... Name: PYTHON1.6revised.doc Type: application/msword Size: 23040 bytes Desc: not available URL: From paul at prescod.net Sat Jul 22 16:54:17 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 09:54:17 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> Message-ID: <3979B599.7274105C@prescod.net> "Barry A. Warsaw" wrote: > > I've long wanted to make the print statement able to handle > alternative output files in a more convenient syntax. Yes you can > rebind sys.stdout, but that is often very clumsy to get right in the > face of exceptions. Why not use outputfile.write directly? print is such a hack already. What are we trying to get at, really? What are the virtues of print, what are the virtues of "outputfile.write" and how can we combine them? -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Sat Jul 22 17:37:29 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 10:37:29 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <20000722092530.A24247@newcnri.cnri.reston.va.us> Message-ID: <3979BFB9.419EC323@prescod.net> Andrew Kuchling wrote: > > On Sat, Jul 22, 2000 at 05:18:13PM +1000, Mark Hammond quoted: > >> Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating > >> Python way too much. > and then wrote: > >I've gotta agree here - I really am quite concerned about all the > >cool-but-not-really-necessary stuff being proposed. I fear that Python > > Seconded from me. I think that this class vague complaints are a little unfair. We've had a wide range of proposals from extra functions to minor new syntax to new magical methods to radically new control flow features. It isn't helpful to lump them altogether and condemn them because Barry broke the cardinal rule of never using an at-symbol in a feature syntax. (shame on you Barry!) List which proposed features you like and don't like and why! That's the only way your concerns could really be addressed. > IMHO it's only worth adding a new feature if it > multiplies power by a significant amount; I think it is also worthwhile to recognize "conventions" that could be made clearer with first-class syntax. List comprehensions replace the map/lambda convention (and would IMHO, allow map/filter, at-least, to be deprecated). Range literals replace the for i in range(...) convention and so forth. Those of us who have already internalized the conventions are more likely to see new syntax as an intrusion rather than as a long-term clarification. > The urge to add little tiny things that make microtask X convenient is > what made Perl -- and Sendmail, and DTML, and ... -- what they are > today. Many languages (including some of the ones you mention) also suffer from the syndrome where a first-class feature has been left out so you have to memorize some stupid and non-intuitive "convention" rather than doing things in a straightforward way. I strongly feel that map/lambda and in fact most uses of map fall into this category. The concept is fine but the syntax sucks. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Sat Jul 22 17:39:30 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 10:39:30 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <20000722092530.A24247@newcnri.cnri.reston.va.us> Message-ID: <3979C032.357FCAF4@prescod.net> Andrew Kuchling wrote: > > On Sat, Jul 22, 2000 at 05:18:13PM +1000, Mark Hammond quoted: > >> Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating > >> Python way too much. > and then wrote: > >I've gotta agree here - I really am quite concerned about all the > >cool-but-not-really-necessary stuff being proposed. I fear that Python > > Seconded from me. I think that this class vague complaints are a little unfair. We've had a wide range of proposals from extra functions to minor new syntax to new magical methods to radically new control flow features. It isn't helpful to lump them altogether and condemn them because Barry broke the cardinal rule of never using an at-symbol in a feature syntax. (shame on you Barry!) List which proposed features you like and don't like and why! That's the only way your concerns could really be addressed. > IMHO it's only worth adding a new feature if it > multiplies power by a significant amount; I think it is also worthwhile to recognize "conventions" that could be made clearer with first-class syntax. List comprehensions replace the map/lambda convention (and would IMHO, allow map/filter, at-least, to be deprecated). Range literals replace the for i in range(...) convention and so forth. Those of us who have already internalized the conventions are more likely to see new syntax as an intrusion rather than as a long-term clarification. > The urge to add little tiny things that make microtask X convenient is > what made Perl -- and Sendmail, and DTML, and ... -- what they are > today. Many languages (including some of the ones you mention) also suffer from the syndrome where a first-class feature has been left out so you have to memorize some stupid and non-intuitive "convention" rather than doing things in a straightforward way. I strongly feel that map/lambda and in fact most uses of map fall into this category. The concept is fine but the syntax sucks. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From gmcm at hypernet.com Sat Jul 22 18:00:23 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 22 Jul 2000 12:00:23 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <3979B599.7274105C@prescod.net> Message-ID: <1247840871-20245181@hypernet.com> Paul Prescod wrote: > print is such a hack already. > > What are we trying to get at, really? What are the virtues of > print, what are the virtues of "outputfile.write" and how can we > combine them? The answer to that is contained in the answer to "Why did Guido make print a keyword?". occaisionally-encumbered-by-bouts-of-rationality-ly y'rs -Gordon From paul at prescod.net Sat Jul 22 18:20:52 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 11:20:52 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <20000722092530.A24247@newcnri.cnri.reston.va.us> Message-ID: <3979C9E4.E66FE451@prescod.net> Andrew Kuchling wrote: > > .... > > The urge to add little tiny things that make microtask X convenient is > what made Perl -- and Sendmail, and DTML, and ... -- what they are > today. I also wanted to say that Perl and Sendmail (don't know about DTML) suffer much more from poor design than from feature creep. It isn't just about quantity of features -- quality also matters. The group of people who spent a week arguing about the name "zip" would never allow "eval" to mean "evaluate string" and "catch exceptions" nor make unadorned variable name mean "file handle" nor make :0:c a "command". Common Lisp and Linux are victims of feature creep. Perl and Sendmail just suck. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Sat Jul 22 18:29:48 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 11:29:48 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> Message-ID: <3979CBFC.2EED0234@prescod.net> Gordon McMillan wrote: > > ... > > The answer to that is contained in the answer to "Why did > Guido make print a keyword?". I would guess that he invented print before sys.stdout. :) The main reason I use print (for debugging) is because a) it doesn't require me to coerce variables to strings explicitly. That's why I want autocoercion everywhere. b) it doesn't require me to import sys. That's an argument for making stdout (or sys!) a builtin c) it just seems less technical for newbies than the unpronouncable string of consonants "std". Overall, I think the language would be better off if print were gone. There are more generalized ways to do what it does. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From akuchlin at cnri.reston.va.us Sat Jul 22 18:36:03 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 22 Jul 2000 12:36:03 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <003301bff3e1$bd5dde60$360bfea9@beopen.com>; from guido@python.org on Sat, Jul 22, 2000 at 06:35:38AM -0700 References: <20000722113028.J9897@xs4all.nl> <20000722065546.A18263@thyrsus.com> <003301bff3e1$bd5dde60$360bfea9@beopen.com> Message-ID: <20000722123603.A24658@newcnri.cnri.reston.va.us> On Sat, Jul 22, 2000 at 06:35:38AM -0700, Guido van Rossum wrote: >- Python 1.6 (a CNRI release with PythonLabs' help) will come out with >CNRI's Open Source License in two phases: a beta around August 1st, and a >final release mid-August (of course this schedule is subject to the usual >qualifications). This will release all of the work on Python done at CNRI >since 1.5.2 was released to the public -- a significant step. Glad there's some resolution to this, and apparently a favorable one! (I haven't read the licence yet -- no way to read Word on this Linux laptop.) So, what version does the current CVS tree represent? Is it what will become 1.6, or will some things be removed from the CVS tree in order to make the 1.6 release? From reading the feature lists, it looks like none of the 2.0 features are checked in yet, so I'd wager that the CVS tree is 1.6. I guess what I'm wondering is how 1.6/2.0 development will be organized; finishing 1.6, and postponing augmented assignment/list comprehensions/whatever until 2.0, seems like the best course, since it means we won't have to wrestle with 2 development branches. --amk From thomas at xs4all.net Sat Jul 22 19:34:45 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 19:34:45 +0200 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000722123603.A24658@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jul 22, 2000 at 12:36:03PM -0400 References: <20000722113028.J9897@xs4all.nl> <20000722065546.A18263@thyrsus.com> <003301bff3e1$bd5dde60$360bfea9@beopen.com> <20000722123603.A24658@newcnri.cnri.reston.va.us> Message-ID: <20000722193445.M9897@xs4all.nl> On Sat, Jul 22, 2000 at 12:36:03PM -0400, Andrew Kuchling wrote: > On Sat, Jul 22, 2000 at 06:35:38AM -0700, Guido van Rossum wrote: > >- Python 1.6 (a CNRI release with PythonLabs' help) will come out with > >CNRI's Open Source License in two phases: a beta around August 1st, and a > >final release mid-August (of course this schedule is subject to the usual > >qualifications). This will release all of the work on Python done at CNRI > >since 1.5.2 was released to the public -- a significant step. > So, what version does the current CVS tree represent? Is it what will > become 1.6, or will some things be removed from the CVS tree in order > to make the 1.6 release? From reading the feature lists, it looks > like none of the 2.0 features are checked in yet, so I'd wager that > the CVS tree is 1.6. How I read it, and what I understood from Jeremy's unofficial response last week, is that 1.6 will be everything that was included while Guido (and Barry, Jeremy and Fred) worked at CNRI. That can probably be seen as everything before the CVS tree moved to SourceForge, plus a bit. I'd suspect some of the half-developed features and most of the bugfixes will move into 1.6 as well, but that's just because that makes sense to me -- so it might not be what CNRI wants ;) > I guess what I'm wondering is how 1.6/2.0 development will be > organized; finishing 1.6, and postponing augmented assignment/list > comprehensions/whatever until 2.0, seems like the best course, since > it means we won't have to wrestle with 2 development branches. In the above interpretation, the current CVS tree is 2.0-to-be. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Sat Jul 22 19:41:03 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 13:41:03 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000722123603.A24658@newcnri.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > ... > (I haven't read the licence yet -- no way to read Word on this > Linux laptop.) Plain text below, or see http://hdl.handle.net/1895.22/1011. I like the old Python license better -- but then I'm relatively sane . > So, what version does the current CVS tree represent? Is it what will > become 1.6, or will some things be removed from the CVS tree in order > to make the 1.6 release? From reading the feature lists, it looks > like none of the 2.0 features are checked in yet, so I'd wager that > the CVS tree is 1.6. Guido said "This [1.6] will release all of the work on Python done at CNRI since 1.5.2 was released to the public". The great recent burst of Python-Dev activity in the CVS tree was not done at CNRI, or the bulk of it even by people with any connection present or past to CNRI. > I guess what I'm wondering is how 1.6/2.0 development will be > organized; finishing 1.6, and postponing augmented assignment/list > comprehensions/whatever until 2.0, seems like the best course, since > it means we won't have to wrestle with 2 development branches. I *expect* that only BeOpen PythonLabs, and perhaps CNRI, will wrestle with 1.6, working from a snapshot of the CVS tree as of the day after Guido et alia left. As Guido also said, 1.6 will be "a CNRI release with PythonLabs' help". There's no technical argument behind any of this, so don't even try to start a fruitful discussion . For example, consider all the patches added since then that did not come with CNRI's disclaimer -- mucking with that retroactively would slow everything (both 1.6 and 2.0!) down. And that's not the only artificial hassle: you should know better than most the nature of the issues involved in a CNRI release. Python-Dev should focus on 2.0! At heart, it's specifically Guido who owes CNRI a 1.6 release. No loss to Python-Dev, as by now he's forgotten how to write code anyway . birthing-pains-ly y'rs - tim PYTHON 1.6, Beta 1 CNRI LICENSE AGREEMENT IMPORTANT: PLEASE READ THE FOLLOWING AGREEMENT CAREFULLY. BY CLICKING ON THE "ACCEPT" BUTTON WHERE INDICATED, OR BY COPYING, INSTALLING OR OTHERWISE USING THE SOFTWARE, YOU ARE DEEMED TO HAVE AGREED TO THE TERMS AND CONDITIONS OF THIS AGREEMENT. 1. This LICENSE AGREEMENT is between the Corporation for National Research Initiatives, having an office at 1895 Preston White Drive, Reston, VA 20191 ("CNRI"), and the Individual or Organization ("Licensee") accessing and otherwise using Python 1.6, beta 1 software in source or binary form and its associated documentation, as released at the www.python.org Internet site on July __, 2000 ("Software"). 2. Subject to the terms and conditions of this License Agreement, CNRI hereby grants Licensee a non-exclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use the Software alone or in any derivative version, provided, however, that CNRI's License Agreement and CNRI's notice of copyright, i.e., "Copyright (c) 1995 - 2000 Corporation for National Research Initiatives; All Rights reserved" are both retained in the Software, alone or in any derivative version prepared by Licensee. Alternately, in lieu of CNRI's License Agreement, Licensee may substitute the following text (omitting the quotes): "Python 1.6, beta 1, is made available subject to the terms and conditions in CNRI's License Agreement. This Agreement may be located on the Internet using the following unique, persistent identifier (known as a handle): 1895.22/1011. This Agreement may also be obtained from a proxy server on the Internet using the following URL: http://hdl.handle.net/1895.22/1011". 3. In the event Licensee prepares a derivative work that is based on or incorporates the Software or any part thereof, and wants to make the derivative work available to the public as provided herein, then Licensee hereby agrees to indicate in any such work the nature of the modifications made to CNRI's Software. 4. CNRI is making the Software available to Licensee on an "AS IS" basis. CNRI MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, CNRI MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 5. CNRI SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF THE SOFTWARE FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. SOME STATES DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY SO THE ABOVE DISCLAIMER MAY NOT APPLY TO LICENSEE. 6. This License Agreement will automatically terminate upon a material breach of its terms and conditions. 7. This License Agreement shall be governed by and interpreted in all respects by the law of the State of Virginia, excluding conflict of law provisions. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between CNRI and Licensee. Licensee may not use CNRI trademarks or trade name in a trademark sense to endorse or promote products or services of Licensee, or any third party. 8. By clicking on the "ACCEPT" button where indicated, or by copying, installing or otherwise using the software, Licensee agrees to be bound by the terms and conditions of this License Agreement. ACCEPT From effbot at telia.com Sat Jul 22 20:07:22 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 22 Jul 2000 20:07:22 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> Message-ID: <031101bff407$b05879c0$f2a6b5d4@hagrid> gordon wrote: > The answer to that is contained in the answer to "Why did > Guido make print a keyword?". from the archives: http://www.egroups.com/message/python-list/20 Date: Sat Dec 7, 1991 11:00pm From: Guido van Rossum Subject: Why print is a built-in statement From thomas at xs4all.net Sat Jul 22 20:36:10 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 20:36:10 +0200 Subject: [Python-Dev] SF Patch Manager Message-ID: <20000722203610.N9897@xs4all.nl> I noticed the SF PM was updated to send out comment-summaries and patch status along with the notification something was changed (and it's lovely, yay!) However, at roughly the same time, the PM stopped sending mail to patches at python.org when a new patch was submitted. Was the patches-notification-address changed, or is that feature disabled now ? (Or perhaps the PM update zapped the old address ?) Never-satisfied-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Sat Jul 22 21:45:01 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 14:45:01 -0500 Subject: [Python-Dev] onlinehelp.py Message-ID: <3979F9BD.EE44A896@prescod.net> I've updated onlinehelp.py with some nice new features built on cool code other people wrote. It's checked in. 1. Richard Chamberlain's wrote textdoc.py which builds on Ka-Ping Yee's inspect.py. Together, they allow me to get a lot more introspective information from modules and clsses even though they may not have docstrings. It will even use comments as docstrings. Thanks to Richard who wrote textdoc.py specifically for this purpose. >>> help( foo.__init__ ) | __init__(self, qName, namespaceURI='', localName=None) | no doc string 2. If you ask for help on a string that it doesn't "know about", it will attempt to import it. >>> help( "profile" ) | profile | Class for profiling Python code. | | Modules: | | marshal, os, sys, time | | Classes: | | class HotProfile(Profile): | | The fastest derived profile example. It does not calculate | caller-callee relationships, and does not calculate cumulative ... 3. It will also try to find the string as a sub-attr of a module. This part is really cool: >>> help( "xml.dom.minidom.AttributeList.items" ) (note that xml.dom.minidom is a package, AttributeList is a class, items, is a method) All features are available from the Unix or Windows command line: python onlinehelp.py xml.dom.minidom.AttributeList.items Have fun! The rest of the message is an example transcript. >>> help( "xml" ) Topic: help( ) | xml | Core XML support for Python. | | This package contains three sub-packages: | | dom -- The W3C Document Object Model. This supports DOM Level 1 + | Namespaces. | | parser -- Python wrappers for XML parsers (currently only supports Expat ). | | sax -- The Simple API for XML, developed by XML-Dev, led by David | Megginson and ported to Python by Lars Marius Garshol. This | supports the SAX 2 API. | | Modules: | | dom, sax >>> help( "xml.dom" ) Topic: help( ) | xml.dom | W3C Document Object Model implementation for Python. | | The Python mapping of the Document Object Model is documented in <...>. | | This package contains the following modules: | | minidom -- A simple implementation of the Level 1 DOM with namespace | support added (based on the Level 2 specification). | | Modules: | | minidom, pulldom >>> help( "xml.dom.minidom" ) | Topic: help( ) | xml.dom.minidom | no doc string | | Modules: | | pulldom, string, types | | Classes: | | class Attr(Node): | | no doc string | | Methods: | | __init__(self, qName, namespaceURI='', localName=None, prefix=None) | no doc string | | __setattr__(self, name, value) | no doc string | | class AttributeList: | | the attribute list is a transient interface to the underlying --more-- (enter for more, q to quit) q 0 >>> help( "xml.dom.minidom.AttributeList" ) | Topic: help( xml.dom.minidom.AttributeList ) | class AttributeList: | | the attribute list is a transient interface to the underlying | dictionaries. mutations here will change the underlying element's | dictionary | | Methods: | | __cmp__(self, other) | no doc string | | __delitem__(self, attname_or_tuple) | no doc string | | __getitem__(self, attname_or_tuple) | #FIXME: is it appropriate to return .value? | | __init__(self, attrs, attrsNS) | no doc string | | __len__(self) | no doc string | | __setitem__(self, attname, value) --more-- (enter for more, q to quit) q >>> help( "xml.dom.minidom.AttributeList.items" ) Topic: help( ) | items(self) | no doc string | 1 >>> -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From bwarsaw at beopen.com Sat Jul 22 22:02:21 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sat, 22 Jul 2000 16:02:21 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> Message-ID: <14713.64973.585633.87443@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Why not use outputfile.write directly? Because it's less readable. log.write('post to %s from %s, size=%d\n' % (listname, sender, len(msg))) vs print 'post to', listname, 'from', sender, 'size=', len(msg) With the former, you have to know about the rules for string interpolation, you have to make sure you've got your tuple is the right length, you have to remember to add the trailing newline. PP> print is such a hack already. Maybe, but how often do /you/ use it? It's an incredibly convenient hack. PP> What are we trying to get at, really? What are the virtues of PP> print, what are the virtues of "outputfile.write" and how can PP> we combine them? Some one else outlined these: print autoconverts to string, it adds the trailing newline, it's easy for newbies to learn and it's very readable. I have no problem with the print statement, but it doesn't matter because it's never going away. I know all about the idiom for temporarily binding sys.stdout around print statements. /That/ is a hack because you're making a non-local change to the system, potentially affecting code you're not even aware of. So my extended print suggestion doesn't add any new keywords or operators (forget about `@' specifically -- it's a red herring) and I don't think it makes the statement any less readable, and in fact improves usability for little extra cognitive or code complexity costs. -Barry From bwarsaw at beopen.com Sat Jul 22 22:07:08 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sat, 22 Jul 2000 16:07:08 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> <3979CBFC.2EED0234@prescod.net> Message-ID: <14713.65260.762631.233327@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Overall, I think the language would be better off if print PP> were gone. There are more generalized ways to do what it PP> does. Really? We can start by fixing the nearly 5000 occurances of it in the Python distribution or the 230 occurances in Mailman. How often does print show up in your own code? print is incredibly convenient; I'd hate to write CGI scripts without it. Why not make it just a little more so? -Barry From paul at prescod.net Sat Jul 22 22:13:51 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 15:13:51 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> Message-ID: <397A007F.CF8DEBE2@prescod.net> "Barry A. Warsaw" wrote: > > ... > Because it's less readable. > > log.write('post to %s from %s, size=%d\n' % (listname, sender, len(msg))) > > vs > > print 'post to', listname, 'from', sender, 'size=', len(msg) Okay, how about log.writeln("Post to ", listname, " from ", sender, " size=", len( msg )) or (with auto string-coercion): log.writeln("Post to "+listname+" from "+sender+" size="+len( msg )) > With the former, you have to know about the rules for string > interpolation, you have to make sure you've got your tuple is the > right length, you have to remember to add the trailing newline. Nevertheless, every Python programmer needs to learn the ".write" way in order to do reasonable text processing. So print's idiosyncracies are just one more thing to learn. In the long run, print hurts newbies more than it helps them because it confuses them into thinking its useful and then frustrates them when they learn its a hack that always appends trailing whitespace. > So my extended print suggestion doesn't add any new keywords or > operators (forget about `@' specifically -- it's a red herring) and I > don't think it makes the statement any less readable, and in fact > improves usability for little extra cognitive or code complexity > costs. I don't see what proposal you are promoting that doesn't have "@" in it? -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Sat Jul 22 22:25:34 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 15:25:34 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> <3979CBFC.2EED0234@prescod.net> <14713.65260.762631.233327@anthem.concentric.net> Message-ID: <397A033E.40CF8DA1@prescod.net> "Barry A. Warsaw" wrote: > > ... > Really? We can start by fixing the nearly 5000 occurances of it in > the Python distribution or the 230 occurances in Mailman. How often > does print show up in your own code? Print almost never shows up in my production code because I always want to allow the option of redirecting the output and assigning sys.stdout is a hack for all of the reasons you've pointed out. I do use print constantly for debug output but the whole point there is that I don't have to set up a file object. I wouldn't use it even there if Python auto-coerced strings and moved stdout into __builtins__. Or else stdout.println could auto-coerce a list of objects. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From tim_one at email.msn.com Sun Jul 23 00:06:29 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 18:06:29 -0400 Subject: [Python-Dev] SF Patch Manager In-Reply-To: <20000722203610.N9897@xs4all.nl> Message-ID: [Thomas Wouters] > I noticed the SF PM was updated to send out comment-summaries and > patch status along with the notification something was changed > (and it's lovely, yay!) However, at roughly the same time, the PM > stopped sending mail to patches at python.org when a new patch was > submitted. That's not it -- the last email in the patches archive from SourceForge was at Thu, 20 Jul 2000 15:40:33 -0700: http://www.python.org/pipermail/patches/2000-July/001221.html and is one of the new-style, more-informative msgs. > Was the patches-notification-address changed, No. > or is that feature disabled now ? No. > (Or perhaps the PM update zapped the old address ?) No. Good guesses, but everything we can affect on the SF end looks good. Just a few *hours* ago, I enabled another new SF feature: email should be sent to patches at python.org for *every* change to patch status now. Doesn't appear to be happening, though. From mhammond at skippinet.com.au Sun Jul 23 00:36:57 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 23 Jul 2000 08:36:57 +1000 Subject: [Python-Dev] Feature bloat in Python (was some PEP thing!) In-Reply-To: <3979BFB9.419EC323@prescod.net> Message-ID: [Paul] > I think that this class vague complaints are a little unfair. That is why we have these lists - so people _can_ disagree. > We've had > a wide range of proposals from extra functions to minor new syntax to > new magical methods to radically new control flow features. Yep - and I still lump them _all_ in the same category. I don't believe I have seen a _single_ PEP I would support (except maybe the "batteries included" one, as it doesn't change the language, just the distribution.) Is that specific enough? > It isn't helpful to lump them altogether and condemn them because Barry > broke the cardinal rule of never using an at-symbol in a feature syntax. Why do you believe I did? Where on earth did you get the impression this has anything to do with the "@" symbol? You seem to be the only one constantly raising this. Even when Barry says it is a red-herring, you wont let it die. I apologize to Barry for picking on his mail; this was not a reflection on the proposal as such, it was just the unfortunate straw that broke the serpent's back. I have changed the subject line to reflect this. > List which proposed features you like and don't > like and why! That's the only way your concerns could really be > addressed. Please re-read my original mail. I said "cool-but-not-really-necessary" features; other people have followed up and clearly understood that I was talking about code-bloat, and not that the features themselves necessarily suck. Each feature, in isolation, could possibly be bashed into something I support. When these are all combined I start having serious reservations. An example of the sum of the parts being significantly greater than the value added to the whole. > I think it is also worthwhile to recognize "conventions" that could be > made clearer with first-class syntax. List comprehensions replace the > map/lambda convention (and would IMHO, allow map/filter, at-least, to be > deprecated). Range literals replace the for i in range(...) convention > and so forth. Hrm - but in a later mail, you state: > Common Lisp and Linux are victims of feature creep. Perl and Sendmail > just suck. If we ignore the obvious bigotry in your statement (Perl and Sendmail "just suck" ?? Tell that to the orders of magnitude more people who use them than Python!) you have just addressed my concerns fairly succinctly. Maybe if you had made them in the same email you could have seen the conundrum? > Those of us who have already internalized the conventions are more > likely to see new syntax as an intrusion rather than as a long-term > clarification. Agreed - hence this debate is useful. However, I will state that the reason I skipped Perl and went for Python all those years ago was that the intent of Python code, even before I knew the language, was clear. This is a key feature of Python, and a selling point I always in my own advocacy efforts. Most of these proposals are watering that down, IMO. But I happily admit that neither you or I are able to make meaningful statements about that - we are too close it. > things in a straightforward way. I strongly feel that map/lambda and in > fact most uses of map fall into this category. The concept is fine but > the syntax sucks. Agreed. So when someone presents a solution that is obvious to the readers of this list, we will be well on our way. This hasn't happened yet. If you can't quickly and quietly win this friendly audience over, IMO the proposal has failed. If any proposal causes even a small thread on this forum that boils down to "but its not clear to me what this should do", then I would have thought it self-evident that the proposal sucks. Convincing us that it _should_ be obvious if only we were all a little brighter and more willing to accept change for changes sake doesn't help anyone, least of all the person making these statements. (Let me be clear that this last statement is not directed personally at Paul!) Standing-by-everything-I-said-ly, Mark. From thomas at xs4all.net Sun Jul 23 02:24:53 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 02:24:53 +0200 Subject: [Python-Dev] ANSIfication. Message-ID: <20000723022452.Q9897@xs4all.nl> I'm done checking in the ansification patches. It doesn't fix everything, for a couple of reasons: - Some function-declarations and function-pointers store functions I don't have access to, like the 'sv' and 'gl' modules, and the 'gl' module seems half auto-generated. - the 'dl' module does some nasty things which I don't feel deserve a prototype. (loading a function using dl_sym, and calling it with 10 char* arguments.) - Some prototypes aren't standardized. This is only really a problem with getopt(), called from Modules/main.c. On some systems, it's 'char **', on some it's 'const char **', and those two pointers are not compatible. (Or did they fix that in C9X ? Somehow I doubt it.) - Readline is a mess. I can start adding prototypes, but the standard readline include files don't do that either, and I'm not terribly sure on some of the prototypes, having never worked with readline myself. The infopages try to be as vague as possible on what kind of function the second argument to 'rl_bind' is, for instance ;) I've fixed the passing of 'PyErr_CheckSignals(void)' to Py_AddPendingCall (which wants a function that takes a void* argument instead) by passing a static wrapper function instead, in both instances (Modules/signalmodule.c and Parser/intrcheck.c.) I'm also tempted to suggest to remove most of the 'extern's, and possibly add them to pyport.h if they are still an issue. Most of the current externs for library functions seem to me like old cruft, though I have no way of telling how old they are. The getopt() prototype would be solved that way, in any case, by removing it and relying on the appropriate include file defining it. Here's an example of what I think is old cruft: posixmodule.c: /* XXX These are for SunOS4.1.3 but shouldn't hurt elsewhere */ extern int rename(const char *, const char *); extern int pclose(FILE *); extern int lstat(const char *, struct stat *); extern int symlink(const char *, const char *); extern int fsync(int fd); There are a couple of more things that might be candidate for cleanup or removal now, by the way. The 'ANY' #define in Include/mymalloc.h, and the type(s) derived from it, for instance. I'm not sure how 'standard' the void* type is, but I thought it was ANSI mandated ? If anyone wants to look at one or more of the above problems, here's how you can find them: find . -name '*.[ch]' | xargs fgrep extern | fgrep '()' find . -name '*.[ch]' | xargs fgrep ')()' Night-night-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Sun Jul 23 04:42:29 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 22 Jul 2000 22:42:29 -0400 (EDT) Subject: [Python-Dev] ANSIfication ? In-Reply-To: <3975B093.C2F125BD@schneider-kamp.de> References: <20000719132554.B9897@xs4all.nl> <3975B093.C2F125BD@schneider-kamp.de> Message-ID: <14714.23445.744869.80794@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > I don't think so. After ANSIfying the whole Module/ directory I was fed > up. > I'd guess the same applies to Fred who slaved away in Objects/ ... I was also tired & had more important things to do. ;) If this hasn't already been done (I'm still several hundreds of messages behind), then feel free to barge ahead! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nhodgson at bigpond.net.au Sun Jul 23 05:26:43 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Sun, 23 Jul 2000 13:26:43 +1000 Subject: [Python-Dev] Python Consortium Meeting News References: Message-ID: <01e601bff455$d31d3f10$8119fea9@neil> I don't like this new license as it is much more complex than the old license. Its about 4 times longer and appears to me to attempt to claim a licensing relationship with third parties who use software written in Python. Is Python going to use this license forever, or is it just for 1.6? Neil From moshez at math.huji.ac.il Sun Jul 23 07:09:15 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 23 Jul 2000 08:09:15 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397A007F.CF8DEBE2@prescod.net> Message-ID: On Sat, 22 Jul 2000, Paul Prescod wrote: > "Barry A. Warsaw" wrote: > > > > ... > > Because it's less readable. > > > > log.write('post to %s from %s, size=%d\n' % (listname, sender, len(msg))) > > > > vs > > > > print 'post to', listname, 'from', sender, 'size=', len(msg) > > Okay, how about > > log.writeln("Post to ", listname, " from ", sender, " size=", len( msg > )) Better yet, have writeln auto put spaces, and you have log.writeln("Post to", listname, "from", sender, "size=%s" % len(msg)) But I'm -0 on that, preferring a new sys function, called writeln writeln("......") writeln(file=logfile, "fffffff", "ffff") and of course writeln(nl=0, "ffffff") to simulate print "ffffff", That would be extremely readable, require no new syntax and no additional builtins. Reference implementation: def writeln(*args, **kw): import sys file = sys.stdout end = '\n' if kw.has_key("file"): file = kw['file'] del kw['file'] if kw.has_key("nl"): if not kw['nl']: end = ' ' del kw['nl'] file.write(" ".join(map(str, args))+end) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From tim_one at email.msn.com Sun Jul 23 07:25:14 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 01:25:14 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <01e601bff455$d31d3f10$8119fea9@neil> Message-ID: [Neil Hodgson] > I don't like this new license as it is much more complex than > the old license. Then I'd say you're normal! The principals on "our side" of the negotiation view this license as something of a triumph, simply because it's so much less obnoxious than the proposals that preceded it. Not speaking for my employer, I think we lost. OTOH, python.org will no longer be held hostage. > Its about 4 times longer and appears to me to attempt to claim a > licensing relationship with third parties who use software written in > Python. > > Is Python going to use this license forever, or is it just for 1.6? Who knows? It's all hifalutin legalese. Note that the text Guido sent out is not the same as the text it references at http://hdl.handle.net/1895.22/1011 either. I believe it's the latter that's out of date, and the text Guido sent is friendlier to users. Still, one way to read the Guido version is that 2.0 and everything after is a "derivative work", so must (paragraph 2) include the 1.6 CNRI license, and (paragraph 3) "indicate in any such work the nature of the modifications made to CNRI?s Software". OTOH, I can see at least two other ways to read it! Perhaps a consortium member who already paid a lawyer would care to pass on their confusion . looks-infectious-to-me-ly y'rs - tim From paul at prescod.net Sun Jul 23 08:13:50 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 01:13:50 -0500 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: Message-ID: <397A8D1E.CB6F140D@prescod.net> Mark Hammond wrote: > > [Paul] > > I think that this class vague complaints are a little unfair. > > That is why we have these lists - so people _can_ disagree. I didn't mean to say otherwise. > > > It isn't helpful to lump them altogether and condemn them because Barry > > broke the cardinal rule of never using an at-symbol in a feature syntax. > > Why do you believe I did? Where on earth did you get the impression this > has anything to do with the "@" symbol? It was a joke. Obviously all of your concern does not stem from one character. On the other hand, I don't think that it is a coincidence that you jumped on the one recent proposal with a syntax that adds a character to the Python repertoire. It's ugly so its an easy target. Or to put it another way, it was *likely* to be the straw that broke the camel's back because it could change the look of Python most radically. > You seem to be the only one > constantly raising this. Even when Barry says it is a red-herring, you > wont let it die. I don't see how a fundamental element of the proposed syntax can be a red-herring! You might as well claim that the new matrix operators are a red herring in the discussion of new matrix operators. If Barry has proposed another syntax I haven't seen it. > Please re-read my original mail. I said "cool-but-not-really-necessary" > features; other people have followed up and clearly understood that I was > talking about code-bloat, and not that the features themselves necessarily > suck. Each feature, in isolation, could possibly be bashed into something > I support. When these are all combined I start having serious > reservations. An example of the sum of the parts being significantly > greater than the value added to the whole. So your opinion is that no new syntax should be added to Python unless it offers massive new functionality. But any syntax that offers massive new functionality (e.g. static type declarations, multimethods, meta-object-protocol) is going to be considered too severe of a change and/or un-Pythonic. > > I think it is also worthwhile to recognize "conventions" that could be > > made clearer with first-class syntax. List comprehensions replace the > > map/lambda convention (and would IMHO, allow map/filter, at-least, to be > > deprecated). Range literals replace the for i in range(...) convention > > and so forth. > > Hrm - but in a later mail, you state: > > Common Lisp and Linux are victims of feature creep. Perl and Sendmail > > just suck. > > If we ignore the obvious bigotry in your statement (Perl and Sendmail "just > suck" ?? Are we now in a society where it is inappropriate to criticize technologies? > Tell that to the orders of magnitude more people who use them > than Python!) I do and have. > you have just addressed my concerns fairly succinctly. Maybe > if you had made them in the same email you could have seen the conundrum? Not at all. There are lots of cool technologies that have grown far beyond their original incarnations: * Unix/Linux * Apache * Zope * EMACS * Common Lisp The important thing isn't the size of the system but the consistency and quality of its design. I was not attracted to Python because it was small but because it was self-consistent. The requirement that every new feature be consistent with the others *makes* it small. TCL is pretty small too, but I have no interest in using it. Scheme is extremely small and I had to give up on it despite my initial attraction. > Agreed - hence this debate is useful. However, I will state that the > reason I skipped Perl and went for Python all those years ago was that the > intent of Python code, even before I knew the language, was clear. This is > a key feature of Python, and a selling point I always in my own advocacy > efforts. Agreed. And do you see code with heavy map/filter/reduce usage as clear? How about code with long getattr functions, doing a dozen tricks at once? My attribute access function proposal (to take one at random :) ) could significantly clarify the code generated by makepy, which I often use as "template code" for COM programming. You talk about clarity and minimalism as if they were the same thing. It is *exactly my point* that sometimes you *trade* clarity for minimalism. On the one end of the spectrum is Common Lisp and on the other is the lambda calculus. I agree that we want to stay close to the middle. > Most of these proposals are watering that down, IMO. But I happily admit > that neither you or I are able to make meaningful statements about that - > we are too close it. If we can't make meaningful statements about usability, Python is doomed. > Agreed. So when someone presents a solution that is obvious to the readers > of this list, we will be well on our way. This hasn't happened yet. If > you can't quickly and quietly win this friendly audience over, IMO the > proposal has failed. If any proposal causes even a small thread on this > forum that boils down to "but its not clear to me what this should do", > then I would have thought it self-evident that the proposal sucks. There is no construct in the Python programming language that is self-evident *in its entirety* including all corner cases. There are a few which you can "feel around" based on knowledge from other programming languages but even those have many Pythonic twists that you can only learn by reading the documentation. Even the "for" statement would have taken a long, complicated, intricate debate on python-dev to work out the current semantics, including IndexError, else:, and mutability. The try statement is even more complex. I can't even believe that something like a=[2:30] is comparable to the various complexities *already in the language*. If Python were half as big as it is today (e.g. no classes, no exception handling), we would be having a big debate about whether to add the missing features. In other words, you have raised the bar on adding features to Python so high that it can never be met. Nothing non-trivial is ever intuitively obvious, including every edge condition and interaction. It just doesn't happen. > Convincing us that it _should_ be obvious if only we were all a little > brighter and more willing to accept change for changes sake doesn't help > anyone, least of all the person making these statements. I don't know what you are talking about. Which of these proposals require you to be a little brighter? a=[1:50] # Range literals a+=[51:60] # Augmented assignment j=[for k in a: if k%2: k*2] # list comprehensions k=zip( [1,2,3,4], [5,6,7,8] ) # parallel iteration d = dict( k ) # new builtin function Which proposals require too much intelligence? Which ones would you not be able to "sight read" coming from Java or Perl? And how do they really compare (for sight-reading) to the contemporary equivalents: a=range(1,50) a=a+range(51,60) j=[] for k in a: if k%2: j.append( k*2 ) array1=[1,2,3,4] array2=[5,6,7,8] k=[] k=map(None, array1, array2 ) d={} for name,val in k: d[name]=val Is this latter code really clearer and easier to read -- even for a newbie -- than the former? Okay, Pep 207, 208, 209 and 213 are likely to be more complex. That's because they are cleaning up parts of the language that are already relatively complex. They aren't adding significant new functionality nor syntax. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From peter at schneider-kamp.de Sun Jul 23 10:21:33 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 23 Jul 2000 08:21:33 +0000 Subject: [Python-Dev] extended print statement, uPre-PEP References: Message-ID: <397AAB0D.1803F60C@schneider-kamp.de> First I want to say, that I use the print statement mainly for debugging and for "print func.__doc__" in the shell, but I would be very unhappy to see it go away. quasi patch for readline: Moshe Zadka wrote: > > Reference implementation: > > def writeln(*args, **kw): > import sys > file = sys.stdout > end = '\n' + joinstring = ' ' > if kw.has_key("file"): > file = kw['file'] > del kw['file'] + if kw.has_key("join"): + joinstring = kw['join'] + del kw['join'] > if kw.has_key("nl"): > if not kw['nl']: ! end = joinstring > del kw['nl'] ! file.write(joinstring.join(map(str, args))+end) Or this one : def writeln(*args, **kw): import sys file = sys.stdout end = '' if kw.has_key("file"): sys.stdout = kw['file'] del kw['file'] if kw.has_key("nl"): if not kw['nl']: end = ',' del kw['nl'] exec("print "+", ".join(map(repr,args))+end) having-slept-for-three-hours-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From moshez at math.huji.ac.il Sun Jul 23 08:29:21 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 23 Jul 2000 09:29:21 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397AAB0D.1803F60C@schneider-kamp.de> Message-ID: On Sun, 23 Jul 2000, Peter Schneider-Kamp wrote: > First I want to say, that I use the print statement mainly > for debugging and for "print func.__doc__" in the shell, > but I would be very unhappy to see it go away. Nobody is suggesting it it went away (though writeln(func.__doc__) is not much longer) -- just that we don't add more craft for that... -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From nhodgson at bigpond.net.au Sun Jul 23 08:29:49 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Sun, 23 Jul 2000 16:29:49 +1000 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: <397A8D1E.CB6F140D@prescod.net> Message-ID: <00c601bff46f$67f6fbd0$8119fea9@neil> > I don't know what you are talking about. Which of these proposals > require you to be a little brighter? > ... *** This one. > j=[for k in a: if k%2: k*2] # list comprehensions > ... > Which proposals require too much intelligence? Which ones would you not > be able to "sight read" coming from Java or Perl? And how do they really > compare (for sight-reading) to the contemporary equivalents: Maybe I'm trapped in my past here but my "sight reading" of list comprehensions brings back memories of BCPL which would have propagated the result of the loop (IIRC, the last expression evaluated within the loop) as the result of the expression. Its hardly obvious what this does based on experience with most current languages including C++, Java or VB. The counter-example given for this in current Python is much more readable to users of these languages. OTOH list comprehensions would be a more significant capability upgrade than the other changes to me and is thus worthy of a larger syntax change. Neil From paul at prescod.net Sun Jul 23 08:34:36 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 01:34:36 -0500 Subject: [Python-Dev] Consistency questions References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> <20000720172108.S9897@xs4all.nl> <14711.8162.800169.884936@beluga.mojam.com> <39773DBB.9480F7BF@prescod.net> <20000721081808.A9897@xs4all.nl> Message-ID: <397A91FC.AEB8DA7B@prescod.net> Thomas Wouters wrote: > >.... > Hm, "methods and attributes are different things, right ?" I catch > my newbie colleagues thinking that all the time ;P How about if we added a function that would help them to see the error of their ways? We could call it "attrs". -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Sun Jul 23 08:36:32 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 01:36:32 -0500 Subject: [Python-Dev] [Fwd: Re: merge (Re: zip or marry etc)] Message-ID: <397A9270.3340DE88@prescod.net> This is the first name I've seen that is clearly self-descriptive: maketuples. It is a little bit wordy but it is also pretty darn clear about what is going on! -------- Original Message -------- Subject: Re: merge (Re: zip or marry etc) Date: 20 Jul 2000 11:53:49 -0400 From: Dan Schmidt Organization: Harmonix Musick Systems To: python-list at python.org Newsgroups: comp.lang.python References: <20000718100813.C21354 at newcnri.cnri.reston.va.us> <39763FF4.2CA5BF75 at schneider-kamp.de> <8l59pa$6ff$1 at slb1.atl.mindspring.net> <8l6vc5$c07$1 at slb6.atl.mindspring.net> <+MLEAgA0Lxd5EwDd at jessikat.fsnet.co.uk> ... zip is fine with me, but if we were to choose a brand-new name, I like the make_pairs that someone proposed, or, since I guess it can work on more than two lists, make_tuples. Or how about tuple_up? :) -- Dan Schmidt | http://www.dfan.org Honest Bob CD now available! | http://www.dfan.org/honestbob/cd.html -- http://www.python.org/mailman/listinfo/python-list From bwarsaw at beopen.com Sun Jul 23 09:07:18 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 03:07:18 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> Message-ID: <14714.39334.615638.738713@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> I don't see what proposal you are promoting that doesn't have PP> "@" in it? Forget about @, let's use >> instead. What I mean by "red herring" is that it doesn't much matter what the token after print is -- we can argue about that all we want later. As long as the token can't appear in that position with any other meaningful semantics, you're fine. I've got a very rough set of patches that implement this, and here's an example that really works. I'll flesh the patches out and post them to SF. -Barry -------------------- snip snip --------------------print.py import sys from StringIO import StringIO listname = 'mylist' sender = 'barry at beopen.com' msg = 'x' * 1000 print 'post to', listname, 'from', sender, 'size=', len(msg) print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg) log = StringIO() print >> log, 'post to', listname, 'from', sender, 'size=', len(msg) print log.getvalue(), -------------------- snip snip -------------------- % ./python /tmp/print.py post to mylist from barry at beopen.com size= 1000 post to mylist from barry at beopen.com size= 1000 post to mylist from barry at beopen.com size= 1000 From mhammond at skippinet.com.au Sun Jul 23 09:08:56 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 23 Jul 2000 17:08:56 +1000 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <397A8D1E.CB6F140D@prescod.net> Message-ID: > > > It isn't helpful to lump them altogether and condemn them > > > because Barry broke the cardinal rule of never using an > > > at-symbol in a feature syntax. > > Why do you believe I did? Where on earth did you get the > > impression this has anything to do with the "@" symbol? > It was a joke. What exactly was the joke? You sound quite serious to me! > Obviously all of your concern does not stem from one > character. On the other hand, I don't think that it is a coincidence > that you jumped on the Sorry, but I don't think you are in a position to make statements about my thought processes. > It's ugly so its an easy target. You should notice that I have not made a single specific comment about this proposal. You have no clue as to my feelings on Barry's proposal. > I don't see how a fundamental element of the proposed syntax can be a > red-herring! I thought your comments on this were a joke? > So your opinion is that no new syntax should be added to Python unless > it offers massive new functionality. But any syntax that offers massive > new functionality (e.g. static type declarations, multimethods, > meta-object-protocol) is going to be considered too severe of a change > and/or un-Pythonic. Where have I made comment on "too severe" or "too un-Pythonic"? I do agree that changes to Python should offer significant benefits, as another contributor to this thread has already stated. > > If we ignore the obvious bigotry in your statement (Perl and > > Sendmail "just suck" ?? > Are we now in a society where it is inappropriate to criticize > technologies? Are we now in a society where "just suck" is a learned and reasonable critisism of a technology? Or one where bigotry, in any form, is acceptable? > > Tell that to the orders of magnitude more people who use them > > than Python!) > > I do and have. *sigh* Telling people their preferred tools "just suck" is unlikely to be effective advocacy. > Agreed. And do you see code with heavy map/filter/reduce usage as clear? Nope. Proposals to clean this up are clearly good. I have avoided making specific comments about specific proposals in these diatribes. However, the existing proposals to "solve" this, IMO, don't. > How about code with long getattr functions, doing a dozen tricks at > once? I have never seen a getattr function doing many tricks. Many attributes for sure, but almost always using the same trick. > My attribute access function proposal (to take one at random :) ) > could significantly clarify the code generated by makepy, which I often > use as "template code" for COM programming. I dont think this is a good example. makepy generated code is not meant to be readable. The fact it often is (and that I often recommend it be read) is a necessity caused by lack of reasonable documentation or alternative tools. I agree your proposal could make makepy generated code more readable; but as the point of makepy generated code is functional, I would probably keep it just as it is! makepy is, IMO, a perfect example of where getattr would still be preferred over your proposal. This is not to say I dont see merit in your proposal; I just don't think makepy is a good example. > > Most of these proposals are watering that down, IMO. But I > > happily admit that neither you or I are able to make > > meaningful statements about that - we are too close it. > If we can't make meaningful statements about usability, Python is > doomed. Im confused. You asserted that we are probably too familiar with Python to make meaningful statements about how newbies will find these syntax changes. I simply agreed, but pointed out that you are also in no position to make the counter claim. Now you are asserting we can make such statements? > I can't even believe that something like > > a=[2:30] > > is comparable to the various complexities *already in the language*. If > Python were half as big as it is today (e.g. no classes, no exception > handling), we would be having a big debate about whether to add the > missing features. I respectfully disagree. To me: a = range(2,30) is just as good, and much clearer. To compare this syntactic sugar to the language having no classes or exceptions is absurd. > I don't know what you are talking about. Which of these proposals > require you to be a little brighter? Neil has already answered. But I must concede - I am not bright enough for many of these. > a=[1:50] # Range literals I admit I _could_ guess at this. > a+=[51:60] # Augmented assignment IMO, a poor example. a+=1 _is_ obvious. a+=[51:60] is, IMO, clearly not. a += range(51,60) is better. > j=[for k in a: if k%2: k*2] # list comprehensions Yep - I admit it - I'm not bright enough. > k=zip( [1,2,3,4], [5,6,7,8] ) # parallel iteration Ditto - I have "winzip", and even zip.exe. I fully understand that the only zips I have encountered on the computer relate to compression. So presumably this is something related to list compression? > d = dict( k ) # new builtin function NFI about this? Is this a copy operation? What is the type of "k" in this example? > Which proposals require too much intelligence? Fortunately, I'm not insecure about my intelligence. [OTOH, I'm also not delusional about it ;-] I suggest most of them. > And how do they really compare (for sight-reading) to > the contemporary equivalents: > a=range(1,50) Worse. > a=a+range(51,60) Worse. > j=[] > for k in a: > if k%2: > j.append( k*2 ) Worse. > > array1=[1,2,3,4] > array2=[5,6,7,8] > k=[] > k=map(None, array1, array2 ) Better. Replace map with a loop, and it goes back to worse. > d={} > for name,val in k: > d[name]=val Worse. > Is this latter code really clearer and easier to read -- even for a > newbie -- than the former? IMO, yes. But as you earlier asserted, to which I agreed, but you then recanted, I dont believe either of us can speak for newbies. Anyway, I believe we have both made our points, and in the interests of preventing this from becoming a real flame-fest, I will refrain from further comments in this vein, and simply place my faith in the benevolent dictator. Thanking-God-Python-isnt-being-designed-by-this-committee-ly Mark. From peter at schneider-kamp.de Sun Jul 23 11:13:19 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 23 Jul 2000 09:13:19 +0000 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> Message-ID: <397AB72F.FC51AEDE@schneider-kamp.de> "Barry A. Warsaw" wrote: > > print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg) I saw `cout' being shifted "Hello world" times to the left and stopped right there. -- Steve Gonedes BTW: I think "print >> sys.stdout" is counter-intuitive, as it looks like something is flowing from print to sys.stdout. This would confuse C++-aware folk heavily. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From peter at schneider-kamp.de Sun Jul 23 11:31:39 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 23 Jul 2000 09:31:39 +0000 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: Message-ID: <397ABB7B.7867860@schneider-kamp.de> Mark Hammond wrote: > > Anyway, I believe we have both made our points, and in the interests of > preventing this from becoming a real flame-fest, I will refrain from > further comments in this vein, and simply place my faith in the benevolent > dictator. I don't want put oil in the fire. That said, I wouldn't place to much faith in the BDFL rejecting those features. Not after this statement: "- Python 2.0 (a BeOpen PythonLabs release) will start with a beta release 1-2 weeks after 1.6 final is released; we're striving for a short beta cycle. New language features will include list comprehensions, range literals, the zip() function, and augmented assignment." of-course-maybe-I-should-read-"will"-as-"could"-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From m.favas at per.dem.csiro.au Sun Jul 23 09:34:00 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Sun, 23 Jul 2000 15:34:00 +0800 Subject: [Python-Dev] _cursesmodule linking, and portability Message-ID: <397A9FE8.DC1EBB6@per.dem.csiro.au> Earlier today I uploaded a patch to SF for _cursesmodule.c so that it would link on Tru64 Unix (Version 4.0F). The problem was that the function has_key() is not present on this platform (nor, apparently, on SGI or Sun). Moshe queried whether this patch was required to link against ncurses on Tru64. ncurses does not exist on Tru64. Access to the functionality of V 4 of the X/Open curses API spec is enabled by the macro _XOPEN_SOURCE_EXTENDED - neither the header file nor the (only) curses library have any reference to has_key(). I am not a curses person (except when... ), so I do not know whether has_key() is part of the _standard_ (new?) curses, but I am concerned that the _cursesmodule.c code exposes this interface for all but SGI, Sun and Tru64 systems. What happens when Python code is written that uses this function? It will fail on at least these three platforms... Should the has_key() function be removed, or a wrapper written for those systems that don't support this function? -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From moshez at math.huji.ac.il Sun Jul 23 09:40:20 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 23 Jul 2000 10:40:20 +0300 (IDT) Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: <397A9FE8.DC1EBB6@per.dem.csiro.au> Message-ID: On Sun, 23 Jul 2000, Mark Favas wrote: > Earlier today I uploaded a patch to SF for _cursesmodule.c so that it > would link on Tru64 Unix (Version 4.0F). The problem was that the > function has_key() is not present on this platform (nor, apparently, on > SGI or Sun). Moshe queried whether this patch was required to link > against ncurses on Tru64. ncurses does not exist on Tru64. I see. I think ESR (who is the new curses maintainer) decided to support only ncurses. You might convince him a) to support Tru64 curses too b) to tell you how to compile ncurses for the Tru64 At any rate, thank you for the quick response. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From effbot at telia.com Sun Jul 23 10:15:52 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 10:15:52 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> Message-ID: <005901bff47e$3ffa7b20$f2a6b5d4@hagrid> paul wrote: > Nevertheless, every Python programmer needs to learn the ".write" way in > order to do reasonable text processing. So print's idiosyncracies are > just one more thing to learn. ...and since people need to learn how to write classes to write larger programs, we can disallow statements and functions on the module level... ...and since people need to learn how to balance parentheses to write larger data structures, we might as well reintroduce braces... ...and since people need to learn C++ and Java anyway, to solve performance problems or interface with low-level stuff, we might as well give up the whole project. >>> usability_guidelines.index("they have to learn it anyway") Traceback (most recent call last): ValueError: list.index(x): x not in list (fwiw, this is related to why adding TabError and IndentationError was a rather lousy idea...) From effbot at telia.com Sun Jul 23 10:12:38 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 10:12:38 +0200 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: Message-ID: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> mark wrote: > If you can't quickly and quietly win this friendly audience over, IMO the > proposal has failed. If any proposal causes even a small thread on this > forum that boils down to "but its not clear to me what this should do", > then I would have thought it self-evident that the proposal sucks. > Convincing us that it _should_ be obvious if only we were all a little > brighter and more willing to accept change for changes sake doesn't > help anyone, least of all the person making these statements from the new Tcl Code Team rules: "A project can also be proposed by someone outside the Tcl Core Team, but it can't be approved without an advocate on the Tcl Core Team who will take personal responsibility for it. A project must have support from at least 2 members of the Tcl Core Team (including the proposer); if anyone in the Tcl Core Team objects to the proposal, then there must be at least 4 members in favor (including the proposer). If there are two or more "no" votes then the proposal is rejected, regardless of the number of people in favor. "The idea here is that the Tcl Core Team can only work effectively if it is highly collegial; any project that generates significant contro- versy should not go into the Tcl core." and for the record, I'm fully prepared to vote "no" on list comprehensions, augumented assignments, range literals, and every trace of a new operator that changes how python code is tokenized and parsed. not that it will change anything: > Thanking-God-Python-isnt-being-designed-by-this-committee-ly ...with two major releases with only a few weeks in between, I'm afraid we'll see the usual "do we really need this?" rule being replaced with "what can we add to make sure people know there's really a difference?". obviously, things with fancy names and existing patches are on the top of that list :-( From m.favas at per.dem.csiro.au Sun Jul 23 10:10:35 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Sun, 23 Jul 2000 16:10:35 +0800 Subject: [Python-Dev] _cursesmodule linking, and portability] Message-ID: <397AA87B.7B00DEF@per.dem.csiro.au> Should have included python-dev on this one - must be a Sunday afternoon... It's still the case that, under the current implementation, Sun and SGI platforms do not expose the has_key() function. My patch just adds Tru64 (nee Digital Unix, nee OSF/1) to that group... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 -------------- next part -------------- An embedded message was scrubbed... From: Mark Favas Subject: Re: [Python-Dev] _cursesmodule linking, and portability Date: Sun, 23 Jul 2000 15:57:42 +0800 Size: 1861 URL: From effbot at telia.com Sun Jul 23 10:26:24 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 10:26:24 +0200 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: <397A8D1E.CB6F140D@prescod.net> <00c601bff46f$67f6fbd0$8119fea9@neil> Message-ID: <007601bff47f$b1191c20$f2a6b5d4@hagrid> neil wrote: > > > j=[for k in a: if k%2: k*2] # list comprehensions > > Maybe I'm trapped in my past here but my "sight reading" of list > comprehensions brings back memories of BCPL which would have propagated the > result of the loop (IIRC, the last expression evaluated within the loop) as > the result of the expression. Its hardly obvious what this does based on > experience with most current languages including C++, Java or VB. and my "sight reading" of this is that j is an anonymous function with a rather meaningless for-loop in it... From moshez at math.huji.ac.il Sun Jul 23 10:20:54 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 23 Jul 2000 11:20:54 +0300 (IDT) Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> Message-ID: On Sun, 23 Jul 2000, Fredrik Lundh wrote: > and for the record, I'm fully prepared to vote "no" on list comprehensions, > augumented assignments, range literals, and every trace of a new operator > that changes how python code is tokenized and parsed. I wouldn't go that far, but I'd vote "not until after 2.0" on everything except range literals. The idea being that range literals is something that has discussed since before I knew of Python (which is an objective measurement of course), and we've known what form they'll take for that long. List comprehensions, augmented assignments and new operators are something with an effect on the language that I personally cannot appreciate without more testing. > ...with two major releases with only a few weeks in between, I'm afraid we'll > see the usual "do we really need this?" rule being replaced with "what can we > add to make sure people know there's really a difference?". Well, I'm less cynical -- I do believe that we won't put any features without careful thought about the side effects of usability and readability. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From thomas at xs4all.net Sun Jul 23 11:00:18 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 11:00:18 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14714.39334.615638.738713@anthem.concentric.net>; from bwarsaw@beopen.com on Sun, Jul 23, 2000 at 03:07:18AM -0400 References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> Message-ID: <20000723110018.R9897@xs4all.nl> On Sun, Jul 23, 2000 at 03:07:18AM -0400, Barry A. Warsaw wrote: > Forget about @, let's use >> instead. What I mean by "red herring" is > that it doesn't much matter what the token after print is -- we can > argue about that all we want later. As long as the token can't appear > in that position with any other meaningful semantics, you're fine. > print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg) Eventhough I said I'd prefer deprecating 'print' over doing something like this, I can actually see this work. '>>' on files has two meanings: the C++ one, and the UNIX one. I'm still not sure if it's a good idea, but given this example and the arguments for it, I'm not violently opposed anymore. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sun Jul 23 11:01:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 11:01:41 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397AB72F.FC51AEDE@schneider-kamp.de>; from peter@schneider-kamp.de on Sun, Jul 23, 2000 at 09:13:19AM +0000 References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397AB72F.FC51AEDE@schneider-kamp.de> Message-ID: <20000723110141.S9897@xs4all.nl> On Sun, Jul 23, 2000 at 09:13:19AM +0000, Peter Schneider-Kamp wrote: > "Barry A. Warsaw" wrote: > > print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg) > BTW: I think "print >> sys.stdout" is counter-intuitive, as it looks > like something is flowing from print to sys.stdout. This would > confuse C++-aware folk heavily. Nonsense. This isn't C++, it's Python, and the step for this isn't as great as for other 'strange' features in Python. Furthermore, their observation is true. Something *is* flowing from print to sys.stdout. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov at inrialpes.fr Sat Jul 22 20:20:39 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 22 Jul 2000 20:20:39 +0200 (CEST) Subject: [Python-Dev] object allocator In-Reply-To: <20000721073222.B25293@keymaster.enme.ucalgary.ca> from "Neil Schemenauer" at Jul 21, 2000 07:32:22 AM Message-ID: <200007221820.UAA01386@python.inrialpes.fr> Neil Schemenauer wrote: > > Nice work Vladimir. I will definately check this out in more detail > when I get my home computer back. I'm hoping we can group objects with > gc_prev and gc_next pointers and reduce the memory overhead. I am hoping for more. The major problem with the existing GC algorithm is related with the big number of objects landing in the older generation, which atomic traversal may cause dalays. That's why I mentioned the GC paper discussing this same problem. As for obmalloc, hey python-dev, make some time to check this out! We get more control, more speed and a priori less memory consumption. This is the only small piece of code that I have seen for a while that can boost the overall speed so much, given the current state of CPython. On my Linux, Pentium III 550, regrtest.py drops from 45 secs to 40 secs. I am particularly interested in feedback from Windows users -- the only popular setup I haven't tested so far... The malloc algorithm has been rewritten. Everything is incremental now, even the free list preallocation in an object's pool. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Sat Jul 22 19:56:03 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 22 Jul 2000 19:56:03 +0200 (CEST) Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <200007211726.TAA04540@python.inrialpes.fr> from "Vladimir Marangozov" at Jul 21, 2000 07:26:15 PM Message-ID: <200007221756.TAA01359@python.inrialpes.fr> [me] > > Paul Prescod wrote: > > > > I don't have a PEP number for this yet but I wanted to go through > > another round of comments after changing the mechanism according to Don > > Beaudry's suggestions. > > ... > > Paul, this is clearly unclear <0.1 wink>. Thanks (Paul, Don, Gordon) for clarifying this pre-PEP. As I see it, this aims at providing builtin support for the following (simplified & quickly hacked) __getattr__ version: def new_getattr(self, name, rec=0): hookname = "__get_%s__" % name if not rec and hasattr(self, hookname): hook = new_getattr(self, hookname, rec=1) return hook(self) # builtin __getattr__ follows ... if self.__dict__.has_key(name): return self.__dict__[name] if self.__class__.__dict__.has_key(name): return self.__class__.__dict__[name] # ... return class_lookup(self, name) raise AttributeError, name class C: def __get_hi__(self): return "coucou" def __getattr__(self, name): return new_getattr(self, name) >>> c = C() >>> c.hi "coucou" and its setattr, delattr counterparts. But people are already massively using __getattr__ as method dispatchers, so as I understand it, this is not just about "Attribute Access Handlers". You're looking for a "Normative Naming Scheme and Builtin Support for Attribute Access Handlers", no more, no less. Okay, so make this clear in the PEP. The presented scenarios don't make this clear, IMO. I asked myself what's the enhancement here... Also, it would be useful if you could include a Python implementation of the concept, stating explicitely where the existing functionality ends, and where the proposed enhancement starts, so that people can play with it. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From esr at thyrsus.com Sun Jul 23 14:10:58 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 23 Jul 2000 08:10:58 -0400 Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: <397A9FE8.DC1EBB6@per.dem.csiro.au>; from m.favas@per.dem.csiro.au on Sun, Jul 23, 2000 at 03:34:00PM +0800 References: <397A9FE8.DC1EBB6@per.dem.csiro.au> Message-ID: <20000723081058.D9463@thyrsus.com> Mark Favas : > Earlier today I uploaded a patch to SF for _cursesmodule.c so that it > would link on Tru64 Unix (Version 4.0F). The problem was that the > function has_key() is not present on this platform (nor, apparently, on > SGI or Sun). Moshe queried whether this patch was required to link > against ncurses on Tru64. ncurses does not exist on Tru64. Access to the > functionality of V 4 of the X/Open curses API spec is enabled by the > macro _XOPEN_SOURCE_EXTENDED - neither the header file nor the (only) > curses library have any reference to has_key(). I am not a curses person > (except when... ), so I do not know whether has_key() is part of > the _standard_ (new?) curses, but I am concerned that the > _cursesmodule.c code exposes this interface for all but SGI, Sun and > Tru64 systems. What happens when Python code is written that uses this > function? It will fail on at least these three platforms... Should the > has_key() function be removed, or a wrapper written for those systems > that don't support this function? OK. The story is this: 1. has_key() is unique to ncurses. It's not specified in the X/Open curses API. 2. We added it for a reason :-). It's hard to write programs that adapt to different numbers of function keys without it -- and this is still an issue. because that number still varies even though all the world is a VT100 emulator these days. So I recommend trying to add has_key to the curses module interface in Python, conditionalized on whether you can pick it out of the local curses headers. You can use the implementation in ncurses as a model. -- Eric S. Raymond You know why there's a Second Amendment? In case the government fails to follow the first one. -- Rush Limbaugh, in a moment of unaccustomed profundity 17 Aug 1993 From moshez at math.huji.ac.il Sun Jul 23 14:21:31 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 23 Jul 2000 15:21:31 +0300 (IDT) Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: <20000723081058.D9463@thyrsus.com> Message-ID: On Sun, 23 Jul 2000, Eric S. Raymond wrote: > OK. The story is this: > > 1. has_key() is unique to ncurses. It's not specified in the > X/Open curses API. > > 2. We added it for a reason :-). It's hard to write programs that adapt to > different numbers of function keys without it -- and this is still an issue. > because that number still varies even though all the world is a VT100 > emulator these days. > > So I recommend trying to add has_key to the curses module interface in Python, > conditionalized on whether you can pick it out of the local curses headers. This sounds just like what Mark did. Or maybe I'm reading you wrong. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mal at lemburg.com Sun Jul 23 14:28:36 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 23 Jul 2000 14:28:36 +0200 Subject: [Python-Dev] ANSIfication. References: <20000723022452.Q9897@xs4all.nl> Message-ID: <397AE4F4.E1A9DDE0@lemburg.com> Thomas Wouters wrote: > > I'm also tempted to suggest to remove most of the 'extern's, and possibly > add them to pyport.h if they are still an issue. Most of the current externs > for library functions seem to me like old cruft, though I have no way of > telling how old they are. The getopt() prototype would be solved that way, > in any case, by removing it and relying on the appropriate include file > defining it. > > Here's an example of what I think is old cruft: > posixmodule.c: > /* XXX These are for SunOS4.1.3 but shouldn't hurt elsewhere */ > extern int rename(const char *, const char *); > extern int pclose(FILE *); > extern int lstat(const char *, struct stat *); > extern int symlink(const char *, const char *); > extern int fsync(int fd); I'd suggest doing this in two steps: 1. move the externs to pyport.h (which is the right place for these platform dependent defines and includes) and add #if 0 ... #endif around them 2. check whether these are still needed during the beta phase and if no one complains remove the cruft completely Alternatively, you could also add specific platform dependent #ifdefs to pyport.h which only enable the externs on those platforms where they are needed. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sun Jul 23 14:34:41 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 23 Jul 2000 14:34:41 +0200 Subject: [Python-Dev] Python Consortium Meeting News References: Message-ID: <397AE661.17E19867@lemburg.com> Tim Peters wrote: > > [Neil Hodgson] > > I don't like this new license as it is much more complex than > > the old license. > > Then I'd say you're normal! The principals on "our side" of the negotiation > view this license as something of a triumph, simply because it's so much > less obnoxious than the proposals that preceded it. Not speaking for my > employer, I think we lost. OTOH, python.org will no longer be held hostage. > > > Its about 4 times longer and appears to me to attempt to claim a > > licensing relationship with third parties who use software written in > > Python. > > > > Is Python going to use this license forever, or is it just for 1.6? > > Who knows? It's all hifalutin legalese. Note that the text Guido sent out > is not the same as the text it references at > http://hdl.handle.net/1895.22/1011 either. I believe it's the latter that's > out of date, and the text Guido sent is friendlier to users. Still, one way > to read the Guido version is that 2.0 and everything after is a "derivative > work", so must (paragraph 2) include the 1.6 CNRI license, and (paragraph 3) > "indicate in any such work the nature of the modifications made to CNRI?s > Software". OTOH, I can see at least two other ways to read it! Perhaps a > consortium member who already paid a lawyer would care to pass on their > confusion . Looks like we're going to have a license bloat here ;-) BTW, what happened to the CWI copyright ? It seems to be missing completely from the CNRI text... could be that we'll have to fight with three different license texts which all apply to 2.0 in the future. Why not simply make Python public-domain instead ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Sun Jul 23 15:16:12 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 15:16:12 +0200 Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: ; from moshez@math.huji.ac.il on Sun, Jul 23, 2000 at 03:21:31PM +0300 References: <20000723081058.D9463@thyrsus.com> Message-ID: <20000723151612.T9897@xs4all.nl> On Sun, Jul 23, 2000 at 03:21:31PM +0300, Moshe Zadka wrote: > On Sun, 23 Jul 2000, Eric S. Raymond wrote: > > So I recommend trying to add has_key to the curses module interface in > > Python, conditionalized on whether you can pick it out of the local > > curses headers. > This sounds just like what Mark did. Or maybe I'm reading you wrong. I think what Eric means is moving the ncurses 'has_key' function into the cursesmodule directly, so that there is an implementation for it on all platforms. (Unsure if that's feasible, though.) Or if he doesn't, he doesn't realize that it's already conditional, and hence not too useful in cursesmodule -- you can't rely on it being there. How about a fake has_key for systems that have strict XPG4 or SVr4 curses, that assumes the terminal in question has a minimal set of function keys ? I'm thinking 'vt100' here, given the abundance of vt100(-derived) terminals, but a smaller set would be fine, too, I think. Oh, and perhaps an autoconf test on has_key is a better idea than a platform specific #ifdef -- if people port ncurses to that platform, they'd get has_key after all. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Sun Jul 23 17:10:00 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 10:10:00 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> Message-ID: <397B0AC8.C6780D33@prescod.net> "Barry A. Warsaw" wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> I don't see what proposal you are promoting that doesn't have > PP> "@" in it? > > Forget about @, let's use >> instead. Okay, but we're still inventing a new token that doesn't exist otherwise in the language. There are two reasons I oppose this. 1. On the one hand, we are making the print statement even more of a special "syntax region" than it already is. In my opinion that's newbie *unfriendly*. They learn how ">>" works in one place and then when they look around for somewhere else to use it, they won't find it. I think that that is profoundly unpythonic. 2. On the other hand, I oppose special case hacks *in general* because when you solve a problem in one place, it doesn't solve it elsewhere. The benefits of print are: * no requirement for parens * newline by default * easy string coercion and interpolation * less thinking about whitepspace Okay, but what about when I want these features elsewhere in the Python language? At least the last three should should be available everywhere in Python. In fact, we can do better than print: Yours: print >> sys.stdout, 'post to', listname, 'from', sender, \ 'size=', len(msg) My proposal: writeln( $"post to ${listname} from ${sender} size=${len(msg)}" ) (or) log.writeln( $"post to ${listname} from ${sender} size=${len(msg)}") Note that I have more control over whitespace than in your example. I am also reusing conventions from other popular languages. The interpolation is available *wherever* string processing is done and it uses standard Python features to redirect the output. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Sun Jul 23 17:31:03 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 10:31:03 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <005901bff47e$3ffa7b20$f2a6b5d4@hagrid> Message-ID: <397B0FB7.56982655@prescod.net> Fredrik Lundh wrote: > > paul wrote: > > Nevertheless, every Python programmer needs to learn the ".write" way in > > order to do reasonable text processing. So print's idiosyncracies are > > just one more thing to learn. > > ...and since people need to learn how to write classes to write > larger programs, we can disallow statements and functions on the > module level... My first reaction was: "Great, you've demonstrated that any argument can be extended and parodied into meaningless. Big deal." But on second thought, you haven't even done that. Everything you learn about statements and functions is directly useful when you learn classes. It builds naturally. There is no conflict. Print is a magical syntax zone where everything works differently: * "," means concatenate, * objects are automatically coerced to strings, * newlines appear out of nowhere * parentheses change the behavior radically * (soon maybe) ">>" is used to redirect object invocations Nothing you learn there will help you to learn stderr.write(...) which works completely differently. > >>> usability_guidelines.index("they have to learn it anyway") > Traceback (most recent call last): > ValueError: list.index(x): x not in list Oh really? I thought that this was in the guidelines: "There should be one-- and preferably only one --obvious way to do it.." Of course it must be balanced with everything else in the guidelines, but it should be a factor. Also: "Special cases aren't special enough to break the rules." What could be more special than a unique syntax zone for writing out text to a stream? -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From m.favas at per.dem.csiro.au Sun Jul 23 17:39:52 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Sun, 23 Jul 2000 23:39:52 +0800 Subject: [Python-Dev] _cursesmodule linking, and portability References: <20000723081058.D9463@thyrsus.com> <20000723151612.T9897@xs4all.nl> Message-ID: <397B11C8.8377D2A7@per.dem.csiro.au> Thomas Wouters wrote: > > On Sun, Jul 23, 2000 at 03:21:31PM +0300, Moshe Zadka wrote: > > On Sun, 23 Jul 2000, Eric S. Raymond wrote: > > > > So I recommend trying to add has_key to the curses module interface in > > > Python, conditionalized on whether you can pick it out of the local > > > curses headers. > > > This sounds just like what Mark did. Or maybe I'm reading you wrong. > > I think what Eric means is moving the ncurses 'has_key' function into the > cursesmodule directly, so that there is an implementation for it on all > platforms. (Unsure if that's feasible, though.) Or if he doesn't, he doesn't > realize that it's already conditional, and hence not too useful in > cursesmodule -- you can't rely on it being there. > > How about a fake has_key for systems that have strict XPG4 or SVr4 curses, > that assumes the terminal in question has a minimal set of function keys ? > I'm thinking 'vt100' here, given the abundance of vt100(-derived) terminals, > but a smaller set would be fine, too, I think. > > Oh, and perhaps an autoconf test on has_key is a better idea than a platform > specific #ifdef -- if people port ncurses to that platform, they'd get > has_key after all. This seems to be the way to go. In a nutshell: from what Eric says, has_key() is a needed functionality in the curses module/package. This function is not supplied by the standard curses libraries on the Sun, SGI and Compaq/DEC Unix platforms (and, I guess, any other platforms that implement only the X/Open curses API). The code in _cursesmodule.c as it currently stands has specific support for Sun and SGI, (and compilation support for Compaq/DEC). For Sun and SGI, exposure of this has_key() function at the Python level is #ifdef'ed out (and my patch just adds Compaq/DEC to this set). If this functionality is indeed vital, there should either be an equivalent written in Python present (inside a try: - except: clause) in the curses package for those platforms not providing it natively, or code for has_key() provided in the _cursesmodule.c itself. And an autoconf test does indeed seem the best way to determine whether has_key() exists, rather than platform #ifdefs. Alternatively, support for Sun, SGI, etc should be dropped from the _cursesmodule.c code and a comment to that effect made in Setup.in. The current comment specifies only that the System V version of curses ("often supplied by the ncurses library") is required. -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From akuchlin at cnri.reston.va.us Sun Jul 23 17:56:27 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 23 Jul 2000 11:56:27 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.65260.762631.233327@anthem.concentric.net>; from bwarsaw@beopen.com on Sat, Jul 22, 2000 at 04:07:08PM -0400 References: <1247840871-20245181@hypernet.com> <3979CBFC.2EED0234@prescod.net> <14713.65260.762631.233327@anthem.concentric.net> Message-ID: <20000723115627.B27195@newcnri.cnri.reston.va.us> On Sat, Jul 22, 2000 at 04:07:08PM -0400, Barry A. Warsaw wrote: >print is incredibly convenient; I'd hate to write CGI scripts without >it. Why not make it just a little more so? Bad example; quick-and-dirty CGI scripts may get away with using print. However, if you want decent error handling, such as not outputting a partial page if you get an exception, you need to either not use print, or replace sys.stdout to trap output from 'print' and only send the output once it's all been generated. --amk From effbot at telia.com Sun Jul 23 18:14:13 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 18:14:13 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <005901bff47e$3ffa7b20$f2a6b5d4@hagrid> <397B0FB7.56982655@prescod.net> Message-ID: <002601bff4c1$0c179200$f2a6b5d4@hagrid> paul wrote: > Oh really? I thought that this was in the guidelines: > > "There should be one-- and preferably only one --obvious way to do it.." > > Of course it must be balanced with everything else in the guidelines, > but it should be a factor. Also: > > "Special cases aren't special enough to break the rules." you obviously didn't read the 10-year old post I pointed to: "...everything else I could think of had other disadvantages. Perhaps printing is one of these things that are important enough to warrant more than one way to do things, even in Python..." ::: I don't know if your recent campaign to remove things from Python is an attempt to compensate for all the PEP stuff, or if you really think Python will become easier to use if we start removing the stuff that makes it easy to use... ...but instead of speculating, I'm just going to quote someone else: "I will refrain from further comments in this vein, and simply place my faith in the benevolent dictator." ::: now back to PEP200. From akuchlin at cnri.reston.va.us Sun Jul 23 18:07:53 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 23 Jul 2000 12:07:53 -0400 Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: <397B11C8.8377D2A7@per.dem.csiro.au>; from m.favas@per.dem.csiro.au on Sun, Jul 23, 2000 at 11:39:52PM +0800 References: <20000723081058.D9463@thyrsus.com> <20000723151612.T9897@xs4all.nl> <397B11C8.8377D2A7@per.dem.csiro.au> Message-ID: <20000723120753.C27195@newcnri.cnri.reston.va.us> On Sun, Jul 23, 2000 at 11:39:52PM +0800, Mark Favas wrote: >just adds Compaq/DEC to this set). If this functionality is indeed >vital, there should either be an equivalent written in Python present Indeed; this week I'll look at translating the ncurses has_key() to Python code. Dropping support for Solaris/IRIX/Tru64 would be excessively harsh. --amk From m.favas at per.dem.csiro.au Sun Jul 23 18:58:54 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Mon, 24 Jul 2000 00:58:54 +0800 Subject: [Python-Dev] ANSIfication breaks socketmodule compile... Message-ID: <397B244E.24ADFEE1@per.dem.csiro.au> The recent bout of ANSIfication seems to have raised a couple of issues with socketmodule: 1) It now won't compile on Tru64, because the declaration of "gethostname" on line 114 conflicts with that in the system unistd.h header file. 114 declares the second parameter as size_t, unistd.h declares it as int (unless the macro _XOPEN_SOURCE_EXTENDED is defined, but that's another can of worms...). The simple fix here is to add another !(defined(__osf__) to the preceding #if line. 2) There'll be an issue on those platforms where the second parameter _is_ declared as type size_t, because the gethostname function is called at line 1402 with the second parameter cast to an int, rather than a size_t... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From effbot at telia.com Sun Jul 23 20:07:31 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 20:07:31 +0200 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile Message-ID: <006c01bff4d1$67022800$f2a6b5d4@hagrid> file signalmodule.c, line 146: #if RETSIGTYPE != void return 0; #endif is that really a valid preprocessor expression? if I understand the ANSI specification correctly, it should be interpreted as "0 != 0" (in other words, it doesn't quite do what the author expected), but MSVC 5.0 thinks that this is fatal error. From effbot at telia.com Sun Jul 23 20:11:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 20:11:48 +0200 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile Message-ID: <007701bff4d1$92f90a00$f2a6b5d4@hagrid> file signalmodule.c, line 146: #if RETSIGTYPE != void return 0; #endif is that really a valid preprocessor expression? if I understand the ANSI specification correctly, it should be interpreted as "0 != 0" (in other words, it doesn't quite do what the author expected), but MSVC 5.0 thinks that this is fatal error. I suggest removing it -- if people are using ANSI C compilers on non-POSIX platforms, they might as well live with a warning... Index: Modules/signalmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/signalmodule.c,v retrieving revision 2.48 diff -c -r2.48 signalmodule.c *** Modules/signalmodule.c 2000/07/22 23:49:30 2.48 --- Modules/signalmodule.c 2000/07/23 18:02:02 *************** *** 94,100 **** static RETSIGTYPE (*old_siginthandler)(int) = SIG_DFL; - static PyObject * signal_default_int_handler(PyObject *self, PyObject *args) --- 94,99 ---- *************** *** 143,151 **** siginterrupt(sig_num, 1); #endif signal(sig_num, signal_handler); ! #if RETSIGTYPE != void ! return 0; ! #endif } --- 142,148 ---- siginterrupt(sig_num, 1); #endif signal(sig_num, signal_handler); ! return; } From paul at prescod.net Sun Jul 23 20:06:51 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 13:06:51 -0500 Subject: [Python-Dev] print References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <005901bff47e$3ffa7b20$f2a6b5d4@hagrid> <397B0FB7.56982655@prescod.net> <002601bff4c1$0c179200$f2a6b5d4@hagrid> Message-ID: <397B343B.B00F2A67@prescod.net> Lest this get (more) out of hand, I'm not proposing that print could be deprecated in the forseeable future. We can, however, make it easier to write to file objects (and cstring objects, and...) rather than making print *more* of a special syntax zone than it already is. If we do our jobs well then people may see the writeln function/method as a simpler, more flexible alternative to print and use it of their own accord. Fredrik Lundh wrote: > > ... > > you obviously didn't read the 10-year old post I pointed to: > > "...everything else I could think of had other disadvantages. > Perhaps printing is one of these things that are important > enough to warrant more than one way to do things, even > in Python..." I absolutely did, that's why I said: > > Of course it must be balanced with everything else in the guidelines, > > but it should be a factor. Do you disagree???? To put it another way: you can tell me that you disagree with my conclusions about print without stating that the guidelines I am using to argue it are somehow inappropriate. So you balance the various guidelines differently than I do. Fine! We can agree to that without claiming that the other person's arguments are invalid. Having a single, obvious way to do something is *one factor we should keep in mind*. Do you disagree???? In the same message you quoted, Guido admitted that his weightings are questionable. Maybe he still stands by them. Maybe he doesn't. He sure isn't going to get mad at me (as you are) merely for raising the question! > I don't know if your recent campaign to remove things from Python is > an attempt to compensate for all the PEP stuff, or if you really think > Python will become easier to use if we start removing the stuff that > makes it easy to use... > > ...but instead of speculating, I'm just going to quote someone else: Funny, it looks like you have already speculated! I happen to think that the print special syntax zone does not make Python easier to use *in the long run* and I offer the following frequently asked questions as evidence: "How do I make print not put a newline at the end?" "Okay, now how do I make it not put whitespace at the end?" "Why is print a statement at all?" and the following infrequently asked questions: "Why can't I have a method named print?" "Why is the syntax for writing to stdout so different from the syntax for writing to stderr?" "Why are the arguments to print automatically coerced but not those for (e.g.) write?" "Why does (e.g.) dir take parentheses but print doesn't?" "I just want to append a few variables to a string. Why isn't it as easy to glue them together as it is to print them out? Shouldn't the comma insert a space?" In REXX, the print statement would print out the names of variables that weren't assigned yet. That made it really easy to do: print hello world The question is whether it made things easier for new programmers *in the long run*. I claim no there and here. (I'm told the Amiga had the string "Hello World" hardcoded in ROM some where :) ). > "I will refrain from further comments in this vein, and simply > place my faith in the benevolent dictator." Two adults should be able to disagree about a Python keyword without getting freaked out. I happen to think that part of what makes Guido a good BDFL is that he listens to people's opinions and he isn't going to get that if every language change proposal is shouted down as heresy, nor if those opposed just don't contribute on principle. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From effbot at telia.com Sun Jul 23 20:16:10 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 20:16:10 +0200 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c Message-ID: <008b01bff4d2$1a1ed140$f2a6b5d4@hagrid> w_byte is a macro that either calls C's putc, or w_more. putc takes an int, and all calls to w_byte make sure they're passing the right thing. however, w_more is defined to take a char, which results in warnings from MSVC5. quick fix: change w_more to take an integer too: Index: Python/marshal.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/marshal.c,v retrieving revision 1.53 diff -c -r1.53 marshal.c *** Python/marshal.c 2000/07/22 18:47:25 1.53 --- Python/marshal.c 2000/07/23 18:07:07 *************** *** 55,61 **** else w_more(c, p) static void ! w_more(char c, WFILE *p) { int size, newsize; if (p->str == NULL) --- 55,61 ---- else w_more(c, p) static void ! w_more(int c, WFILE *p) { int size, newsize; if (p->str == NULL) *************** *** 69,75 **** p->ptr = PyString_AS_STRING((PyStringObject *)p->str) + size; p->end = PyString_AS_STRING((PyStringObject *)p->str) + newsize; ! *p->ptr++ = c; } } --- 69,75 ---- p->ptr = PyString_AS_STRING((PyStringObject *)p->str) + size; p->end = PyString_AS_STRING((PyStringObject *)p->str) + newsize; ! *p->ptr++ = (char) c; } } From moshez at math.huji.ac.il Sun Jul 23 20:27:16 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 23 Jul 2000 21:27:16 +0300 (IDT) Subject: [Python-Dev] ANSIfication breaks socketmodule compile... In-Reply-To: <397B244E.24ADFEE1@per.dem.csiro.au> Message-ID: On Mon, 24 Jul 2000, Mark Favas wrote: > The recent bout of ANSIfication seems to have raised a couple of issues > with socketmodule: > > 1) It now won't compile on Tru64, because the declaration of > "gethostname" on line 114 conflicts with that in the system unistd.h > header file. 114 declares the second parameter as size_t, unistd.h > declares it as int (unless the macro _XOPEN_SOURCE_EXTENDED is defined, > but that's another can of worms...). The simple fix here is to add > another !(defined(__osf__) to the preceding #if line. Hmmmm....gethostname() prototype should probably be left to system includes, and not defined at all (except maybe in pyport.h under heavy #ifdef guard) > 2) There'll be an issue on those platforms where the second parameter > _is_ declared as type size_t, because the gethostname function is called > at line 1402 with the second parameter cast to an int, rather than a > size_t... This is plain wrong! The cast should probably be deleted. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From tim_one at email.msn.com Sun Jul 23 20:29:56 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 14:29:56 -0400 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: <006c01bff4d1$67022800$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > file signalmodule.c, line 146: > > #if RETSIGTYPE != void > return 0; > #endif > > is that really a valid preprocessor expression? No. Checked in a fix a few minutes ago. > if I understand the ANSI specification correctly, it should be > interpreted as "0 != 0" (in other words, it doesn't quite do what > the author expected), No, it's simply not C. "void" has no meaning at all in a constant integer expression (which is what must appear after #if). > but MSVC 5.0 thinks that this is fatal error. Ditto 6.0, and they're both right . From thomas at xs4all.net Sun Jul 23 21:40:06 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 21:40:06 +0200 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: <006c01bff4d1$67022800$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jul 23, 2000 at 08:07:31PM +0200 References: <006c01bff4d1$67022800$f2a6b5d4@hagrid> Message-ID: <20000723214006.U9897@xs4all.nl> On Sun, Jul 23, 2000 at 08:07:31PM +0200, Fredrik Lundh wrote: > file signalmodule.c, line 146: > #if RETSIGTYPE != void > return 0; > #endif > is that really a valid preprocessor expression? According to how I interpreted gcc's documentation, yes. And it works, too, with gcc. I'll readily admit gcc isn't the perfect example of ANSIness though. > if I understand the ANSI specification correctly, it should be interpreted > as "0 != 0" (in other words, it doesn't quite do what the author expected), > but MSVC 5.0 thinks that this is fatal error. I guess I should've mentioned this seperately, in my posting last night ;) Ohwell, I doubt I would've come up with something as good as Tim's solution even if I knew the above wasn't valid. As for the other point, I'd say drop the support for 'int'-returning systems altogether. If such systems are still in use, they would've been generating warnings for a long time now. Apparently noone noticed. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Sun Jul 23 21:43:33 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 15:43:33 -0400 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: <008b01bff4d2$1a1ed140$f2a6b5d4@hagrid> Message-ID: > w_byte is a macro that either calls C's putc, or w_more. > > putc takes an int, and all calls to w_byte make sure they're > passing the right thing. > > however, w_more is defined to take a char, which results in > warnings from MSVC5. > > quick fix: change w_more to take an integer too: > ... And I see you checked that in. Good! I later replaced part of it, via a new mini-subsystem that may tick somebody off, so I'll explain that here so people can yell at me now: 1. asserts are a fundamental tool of good C practice, but are very rarely used in Python source. To encourage their use, I added an include of to Python.h, so that assert is always available. 2. Added a new Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) macro to pyport.h, which is also always available. This casts VALUE from type WIDE to type NARROW, but assert-fails if info is lost due to the cast and Py_DEBUG is #define'd (when we're not in Py_DEBUG mode, it just expands to (NARROW)(VALUE)). Note: this kind of thing is much easier to do in C++, because of inline functions and being able to templatize those on the types involved (i.e., the compiler can figure out which specific checker to expand at compile-time, rather than making you redundantly-- and hence possibly incorrectly --name the types "by hand" again). 3. It's nice that eyeballing every call to marshal's w_byte allows one to infer that the derived calls to w_more are safe, but it's much better to let the compiler check that. So I replaced the raw cast with an invocation of Py_SAFE_DOWNCAST. Doesn't cost anything except in Py_DEBUG mode. From tim_one at email.msn.com Sun Jul 23 21:55:17 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 15:55:17 -0400 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: <20000723214006.U9897@xs4all.nl> Message-ID: [Thomas Wouters] > ... > As for the other point, I'd say drop the support for > 'int'-returning systems altogether. If such systems are still > in use, they would've been generating warnings for a long time > now. Apparently noone noticed. The Unix(tm)-ish autoconfigure stuff came after my Unixish days, and I still don't have a Unixish system available so I've got scant idea how it works. From thomas at xs4all.net Sun Jul 23 22:16:35 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 22:16:35 +0200 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 23, 2000 at 03:55:17PM -0400 References: <20000723214006.U9897@xs4all.nl> Message-ID: <20000723221635.V9897@xs4all.nl> On Sun, Jul 23, 2000 at 03:55:17PM -0400, Tim Peters wrote: > [Thomas Wouters] > > As for the other point, I'd say drop the support for > > 'int'-returning systems altogether. If such systems are still > > in use, they would've been generating warnings for a long time > > now. Apparently noone noticed. > > The Unix(tm)-ish autoconfigure stuff came after my Unixish days, and I still > don't have a Unixish system available so I've got scant idea how it works. > >From what I can dope out, RETSIGTYPE isn't mentioned in configure.in at all, > but gets pulled out of thin air by magic anyway by the time "configure" is > built: > echo "$ac_t""$ac_cv_type_signal" 1>&6 > cat >> confdefs.h < #define RETSIGTYPE $ac_cv_type_signal > EOF Autoconf consists of standard and user-defined rules. The standard ones are things like checking the availability of ANSI types, and usually consist of a single m4 macro: # Type availability checks AC_TYPE_MODE_T AC_TYPE_OFF_T AC_TYPE_PID_T AC_TYPE_SIGNAL AC_TYPE_SIZE_T AC_TYPE_UID_T 'AC_TYPE_SIGNAL' expands in those 40 lines of code in configure that check the return type of signal handlers. User-defined rules are like the one I wrote for right-shifting-zero-fills, and are a tad longer: there are a few 'component' macros that check for headers, functions or libraries, and you can write your own little test-program to switch on. All the macros get expanded into a shell script that compiles (and executes, when necessary) test programs. > This *suggests* it's "still an issue" under Unixy things, but beats me. > void is ANSI, int isn't. If any Unixoid swears it's OK to nuke RETSIGTYPE, > I'd be delighted to do it. configure is also built to run on any system with an almost-working K&R C compiler and something remotely resembling proto-UNIX ;) It doesn't care much about standards, because it's build in order to easily support systems that *aren't* following the standards. All in all, if the ANSI standard says signal-handlers should return void, by all means, remove the switch altogether. I removed the whole HAVE_STDARG_PROTOTYPES switch for ANSI variable-arg lists for exactly the same reason. I just wasn't sure if the return type of signal handers was defined by ANSI C. In fact, we can probably remove a lot more checks from configure.in and the code that #ifdefs on the result, if we decide to really eradicate every trace of non-ANSI code. However, it's not winning anything more than a few seconds of 'configure' time and a few milliseconds of 'cpp' time, so it's probably not worth it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sun Jul 23 22:31:47 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 22:31:47 +0200 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 23, 2000 at 03:43:33PM -0400 References: <008b01bff4d2$1a1ed140$f2a6b5d4@hagrid> Message-ID: <20000723223147.W9897@xs4all.nl> On Sun, Jul 23, 2000 at 03:43:33PM -0400, Tim Peters wrote: > Note: this kind of thing is much easier to do in C++, because of > inline functions and being able to templatize those on the types > involved (i.e., the compiler can figure out which specific checker to > expand at compile-time, rather than making you redundantly-- and hence > possibly incorrectly --name the types "by hand" again). Is that a veiled suggestion to compile Python as C++ ? ;) I actually tried to do that, and it almost worked. Some of the current code uses a few C++ reserved words ('new', 'class') that need to be renamed, and a couple of expressions need some additional parentheses. (The Py_INCREF/DECREF macros, for instance, produced some incomprehensible g++ error.) (I tried compiling with g++ to find any lingering K&R C prototypes. And it worked, it found a few for me I hadn't realized were wrong.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Sun Jul 23 22:32:10 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 16:32:10 -0400 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: <20000723221635.V9897@xs4all.nl> Message-ID: [Thomas Wouters] > ... > All in all, if the ANSI standard says signal-handlers should > return void, by all means, remove the switch altogether. I removed > the whole HAVE_STDARG_PROTOTYPES switch for ANSI variable-arg lists > for exactly the same reason. I just wasn't sure if the return type > of signal handers was defined by ANSI C. Yes, it is. Almost nothing *else* about signals is defined to work in a portable way, but handlers are defined to return void. > In fact, we can probably remove a lot more checks from > configure.in and the code that #ifdefs on the result, if we decide > to really eradicate every trace of non-ANSI code. However, it's not > winning anything more than a few seconds of 'configure' time and a few > milliseconds of 'cpp' time, so it's probably not worth it. I don't really care about extra crap in the configure scripts, except to the extent that they baffle people porting to new platforms (the Talmudic distinctions drawn to support 197 incompatible flavors of Unix leave people on other systems scratching their heads until the earlier of wearing their fingernails away or passing out from blood loss ). What I *really* care about is getting RETSIGTYPE out of our *source* code. Macros do damage! They're hard to figure out, hard to write safely, full of surprises even so, and frustrate the heck out of single-stepping in the debugger. Unforunately, they're necessary to write robust cross-platform C code. But every one we can nuke is one less knife in the heart. Hmm ... I'll leave the Unix config stuff alone, but get rid of RETSIGTYPE in the rest of the tree. Objections? From thomas at xs4all.net Sun Jul 23 22:41:07 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 22:41:07 +0200 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 23, 2000 at 04:32:10PM -0400 References: <20000723221635.V9897@xs4all.nl> Message-ID: <20000723224107.R9892@xs4all.nl> On Sun, Jul 23, 2000 at 04:32:10PM -0400, Tim Peters wrote: > What I *really* care about is getting RETSIGTYPE out of our *source* code. > Macros do damage! They're hard to figure out, hard to write safely, full of > surprises even so, and frustrate the heck out of single-stepping in the > debugger. Unforunately, they're necessary to write robust cross-platform C > code. But every one we can nuke is one less knife in the heart. Agreed. And each one makes it harder to port to new systems ;) (I wish I had access to such a hard-to-do new system... I like a little challenge ;) > Hmm ... I'll leave the Unix config stuff alone, but get rid of RETSIGTYPE in > the rest of the tree. Objections? Sounds like a good idea to me. Does config.h get exported to extention code, by the way ? If it is, keeping it in is probably a good idea. It doesn't look like it is, though, so I'm tempted to remote the autoconf check anyway. All your reasons for removing the macros from the source go for configure.in, too, especially when porting to new systems. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Sun Jul 23 23:11:30 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 17:11:30 -0400 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: <20000723223147.W9897@xs4all.nl> Message-ID: [Tim] > Note: this kind of thing is much easier to do in C++ ... [Thomas Wouters] > Is that a veiled suggestion to compile Python as C++ ? ;) Na, just a data point. If P3K is a reimplementation from the ground up, C++ is certainly worth considering. At the O'Reilly conference, it was announced that the Perl rewrite in C++ (codenamed Topaz) has been abandoned. I didn't attend that session, but my impression from others is that they attempted to model Perl objects directly by C++ objects, and were frustrated by the consequent lack of low-level control. That's more ambitious than I would have tried. Using C++ just as "a better C" actually works, keeping the OO stuff simple and internal (e.g., I'd still expose a plain-C interface, and ignore the last 5 years of new C++ features <0.5 wink -- whether any given compiler handles them correctly is still too much of a crap shoot>). So not really C++, but maybe C++--. > I actually tried to do that, and it almost worked. Some of the current > code uses a few C++ reserved words ('new', 'class') that need to be > renamed, and a couple of expressions need some additional parentheses. > (The Py_INCREF/DECREF macros, for instance, produced some > incomprehensible g++ error.) It would be good to clean that stuff up, to ease future experiments. I haven't used C since 1994, *except* when working on Python, so stuff like "new" and "class" used in non-C++ ways bothers my eyeballs. mutual-back-scratching-ly y'rs - tim From tim_one at email.msn.com Mon Jul 24 00:23:48 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 18:23:48 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.64973.585633.87443@anthem.concentric.net> Message-ID: [Barry A. Warsaw] > ... > log.write('post to %s from %s, size=%d\n' % (listname, > sender, len(msg))) > > vs > > print 'post to', listname, 'from', sender, 'size=', len(msg) > > With the former, you have to know about the rules for string > interpolation, you have to make sure you've got your tuple is the > right length, you have to remember to add the trailing newline. OTOH, they don't produce the same output! The comma after "from %s" is missing in the latter, and the latter adds an extra space after "size=". These very much relate to the endlessly repeated newcomer questions Paul sketched, such as "how can I get rid of the trailing newline?", "how can I print to a different file?", and (IIRC, Paul missed this one) "how can I get *rid* of the space between two items?". The uncomfortable truth is that getting the output you want, to the destination you want, is usually a lot less hassle in Perl. Paul latched on to the heart of Perl's convenience with his [Paul] > log.writeln($"post to ${listname} from ${sender}, size=${len(msg)}") where I've put back the comma from Barry's original. Perhaps Barry will counter with print >> log, $"post to ${listname} from ${sender}, size=${len(msg)}" Then I'd counter-counter with print >> log, $"post to $listname from $sender, size=${len(msg)}" But there's not a new suggestion in this whole thing -- even ">>" specifically was suggested long ago for this purpose. I can't say whether Guido ever read those suggestions, but I don't recall him ever responding. ABC *did* have auto-stringifying expression interpolation in its strings, so presumably he didn't like it there. I know I didn't like it in ABC, but for an avoidable reason: it used the same character for both "interpolate this" left and right brackets, which often made it hard to see exactly what was being interpolated. I've always been surprised that Guido retained that latter property in Python's shorthand for repr (a function that doesn't *merit* a shorthand if ever there was one ): >>> print ``1+2`+`3+4`` '37' >>> I'm not sure how Python's parser manages to get that straight! In Precodese, it would be (except that $(x) is presumably str(x) rather than repr(x)): print $"$($(1+2)+$(3+4))" which at least makes the grouping clear. I'm all for it. in-principle-if-not-in-every-detail-ly y'rs - tim From tim_one at email.msn.com Mon Jul 24 02:55:10 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 20:55:10 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <397AE661.17E19867@lemburg.com> Message-ID: [M.-A. Lemburg] > BTW, what happened to the CWI copyright ? It seems to be missing > completely from the CNRI text... could be that we'll have > to fight with three different license texts which all apply > to 2.0 in the future. > > Why not simply make Python public-domain instead ? CNRI wanted a new licence, and CNRI wrote the new license text. Their motivations and reasoning were-- and remain --a mystery to me (not in the sense that I didn't understand them, but in the plainer sense that I was never told -- everything they said on the subject consisted of the single msg Guido forwarded to c.l.py, which said nothing specific -- perhaps they said more at the consortium mtg? don't know). Can only suggest you direct questions to the people Guido named in his announcement (Dr. Kahn at CNRI, Bob Weiner at BeOpen). From bwarsaw at beopen.com Mon Jul 24 04:07:40 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 22:07:40 -0400 (EDT) Subject: [Python-Dev] Evolving Python (was Re: Feature bloat in Python ...) References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> Message-ID: <14715.42220.655527.947800@anthem.concentric.net> I think we're going about this all wrong. We all have our pet peeves, syntax gripes, missing functionality, etc. about Python. We're all so quick to identify these problems and expect everybody else to agree with us. We proposal solutions or enhancements to the language that of course, everybody should immediately agree on. But we never get consensus. Given the size of the developer community, and the diversity of applications and experience, we never will on any of these features. If we put each PEP and pre-PEP up for a vote here, I'll bet every one would fail. The Perl6 and Tcl crews should take a lesson here. You cannot design a language by committee. I'm beginning to think that our role on python-dev is different than we thought. I think for a particular proposal for a new language feature, or core language functionality, it is our job to explore the details and ramifications as much as possible. These should be summarized in a PEP, and it must have running code or a working patch. Guido can't possibly follow every thread in this mailing list and he shouldn't have to. But he can read a PEP, apply a patch, play with the new feature and decide yeah, nay, lukewarm-but-needs-more-work. We need to make Guido's job as language designer and BDFL easier, not harder. Sniping at each other means he has to get involved in petty crap among his advisors. This is what I'd hoped the PEPs and python-dev would be for: to encourage people to explore ways to improve the language and for people to work together to write good proposals and build good code. Even if it's eventually rejected. If you have a language feature that you're willing to champion, then I encourage you to write a PEP and develop a patch. Post the patch to SF so others can play with it. Without working code, a language proposal should by default be considered incomplete. Tired-and-venting-ly, -Barry From paul at prescod.net Mon Jul 24 04:11:57 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 21:11:57 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: Message-ID: <397BA5ED.D3C33699@prescod.net> Tim Peters wrote: > > ... > > I'm not sure how Python's parser manages to get that straight! In > Precodese, it would be (except that $(x) is presumably str(x) rather than > repr(x)): > > print $"$($(1+2)+$(3+4))" > > which at least makes the grouping clear. I'm all for it. Egad. It's enough to make me think twice about my own proposal. :) Nevertheless, I agree it's clearer than your tick-example which almost made me run for my plotted plant. As happy as I am to have it called Prescod-ese, I admit to influence from some languages that (otherwise) suck. :) credit-where-due 'ly yrs -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Mon Jul 24 04:42:48 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 21:42:48 -0500 Subject: [Python-Dev] pep-dev References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> Message-ID: <397BAD28.E4BF7E54@prescod.net> "Barry A. Warsaw" wrote: > > ... > > I'm beginning to think that our role on python-dev is different than > we thought. I think for a particular proposal for a new language > feature, or core language functionality, it is our job to explore the > details and ramifications as much as possible. These should be > summarized in a PEP, and it must have running code or a working patch. This isn't directly a followup but you've touched on something I've been thinking. I have been thinking for several days that PEPs give us a clear dividing line between what could go on in Python-dev and what could go on in a theoretical "other mailing list" with an open subscription. I called this once "Python syntax" but instead we could call it pep-dev. If we make a pep-dev mailing list where anyone could contribute then we could have a lot more input from the Python community but the list could still be focused enough that current python-dev'ers would feel like they weren't wading through a million TKinter and curses questions. Python-dev itself could be reserved for final implementation questions once a feature has been accepted. Guido wouldn't need to read every message in PEP-dev because the whole point is to come up with a PEP that he *could* read. In fact, nobody would read every message of PEP-dev (well, maybe Thomas Wouters, he seems to have infinite energy). Each message could be clearly labelled as relating to this PEP or that one and if you aren't interested, you could just ignore that thread. Messages that are not about a PEP would be strongly frowned upon. Discussing curly-brace delimiters is fine -- as long as the end result is a PEP that ensures that we never, ever have to discuss it again because it clearly states all of the arguments for and against. (okay, maybe I'm dreaming) Even if you hate the features being proposed in PEPs, it seems really useful to describe each of them once so that we have something to point at and say: "Yeah, we've thought about it in detail and Guido decided against it. Raising it again won't help." There are also some issues that really should be worked out somewhere, like our standard package hierarchy (if any) and the class hierarchy we will use after type/class unification. And a formal definition of some of our implicit interfaces...etc. etc. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From bwarsaw at beopen.com Mon Jul 24 04:49:47 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 22:49:47 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> Message-ID: <14715.44747.65722.305555@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> log.writeln("Post to ", listname, " from ", sender, " size=", PP> len( msg )) That could work, if we added writeln() to all file-like objects. One advantage of extending print is that the write() method is already a documented (and existing) interface. PP> or (with auto string-coercion): PP> log.writeln("Post to "+listname+" from "+sender+" size="+len( PP> msg )) Isn't adding auto string-coercion a more radical suggestion than extending print? -Barry From tim_one at email.msn.com Mon Jul 24 04:55:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 22:55:36 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397BA5ED.D3C33699@prescod.net> Message-ID: [Tim] > ... > I'm not sure how Python's parser manages to get that [``1+2`+`3+4``] > straight! In Prescodese, it would be (except that $(x) is presumably > str(x) rather than repr(x)): > > print $"$($(1+2)+$(3+4))" > > which at least makes the grouping clear. I'm all for it. [Paul Prescod] > Egad. It's enough to make me think twice about my own proposal. :) > > Nevertheless, I agree it's clearer than your tick-example which almost > made me run for my plotted plant. Yes, both examples suck, but distinct left & right bracketing characters at least make the extremes tractable. They also make the usual cases obvious, as some of us have learned from languages that suck . > As happy as I am to have it called Prescod-ese, I admit to influence > from some languages that (otherwise) suck. :) Indeed, if Perl got the philosophy wrong but many details right, then Python may be open to the opposite critique. BTW, triple-quoted strings got added to Python after I whined (& whined, & whined) on c.l.py that I was writing some block-output generating programs in Perl because pasting screen-width strings with explicit newlines together was driving me nuts in Python. Wouldn't be the first time we stole the heart of a decent detail from Perl! Python's "%(name)format" % dict is great (& better than Perl) for fine-grained control of formatting, but we're missing Perl's ease in the vast area between that and what plain "print" can do. Perl's got nothing to be ashamed of here: Larry looked at the mass of insanely convoluted quoting and interpolation rules from the Unix shells and from Tcl, and came up with something downright Pythonic in its uniformity and simplicity. Except he couldn't resist pushing it too far (e.g., trying to *guess* whether "[]" are literal characters or an indexing operator in "$a[$b]"). BTW, at the time, half the people on c.l.py complained that triple-quoted strings were unnecessary feature bloat too. Jeez, if I cared about what was *necessary*, I'd program in Scheme <0.3 wink>. BTW too, in "There should be one-- and preferably only one --obvious way to do it", "obvious" doesn't mean instantly understandable to someone from Mars. Nothing in computer languages is obvious in that sense. It means more "easy to learn and hard to forget once you know it", and that the vast majority of people who know the language are likely to spell it the same way. Sequence slicing is the perfect example: newbies are routinely baffled by it, but once they get it they never lose it, and all of us use it. Pushing and popping sys.stdout doesn't qualify as obvious that way, ditto the twenty ways to paste the output you want together by hand now (note that whenever this pops up on c.l.py, about as many alternatives are suggested as there are responses -- unPythonic). we-can-leave-python-alone-when-it-finishes-becoming-python-ly y'rs - tim From bwarsaw at beopen.com Mon Jul 24 05:01:42 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:01:42 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <397A007F.CF8DEBE2@prescod.net> Message-ID: <14715.45462.695712.12998@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> But I'm -0 on that, preferring a new sys function, called MZ> writeln MZ> That would be extremely readable, require no new syntax and no MZ> additional builtins. MZ> Reference implementation: Add a `sep' keyword, check for residual keyword arguments, and I might be +0 on that. Of course, now you're in the realm of... so-easy-i'll-just-cut-and-paste-this-into-my-own-app-ly y'rs, -Barry -------------------- snip snip -------------------- def writeln(*args, **kws): import sys file = sys.stdout sep = ' ' end = '\n' if kws.has_key('file'): file = kws['file'] del kws['file'] if kws.has_key('nl'): if not kws['nl']: end = ' ' del kws['nl'] if kws.has_key('sep'): sep = kws['sep'] del kws['sep'] if kws: raise TypeError('unexpected keywords') file.write(sep.join(map(str, args)) + end) From bwarsaw at beopen.com Mon Jul 24 05:02:54 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:02:54 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> Message-ID: <14715.45534.435629.993813@anthem.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: BAW> I've got a very rough set of patches that implement this, and BAW> here's an example that really works. I'll flesh the patches BAW> out and post them to SF. I've now done this, so at least there's working code you can play with. -Barry From bwarsaw at beopen.com Mon Jul 24 05:10:07 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:10:07 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> Message-ID: <14715.45967.555713.668818@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: >> have PP> "@" in it? Forget about @, let's use >> instead. PP> Okay, but we're still inventing a new token that doesn't exist PP> otherwise in the language. No we're not! From token.h: #define RIGHTSHIFT 35 PP> There are two reasons I oppose this. PP> 1. On the one hand, we are making the print statement even PP> more of a special "syntax region" than it already is. In my PP> opinion that's newbie *unfriendly*. They learn how ">>" works PP> in one place and then when they look around for somewhere else PP> to use it, they won't find it. I think that that is profoundly PP> unpythonic. Where would people look to use >> in this sense elsewhere? PP> 2. On the other hand, I oppose special case hacks *in general* PP> because when you solve a problem in one place, it doesn't PP> solve it elsewhere. The benefits of print are: | * no requirement for parens | * newline by default | * easy string coercion and interpolation | * less thinking about whitepspace PP> Okay, but what about when I want these features elsewhere in PP> the Python language? At least the last three should should be PP> available everywhere in Python. Don't these things mostly crop up in printing, in one form or another. I can imagine you might want to use something like #3.5 or #4 when, e.g. building a string to be used as a regex, but in that case, you already have #3.5 and #4, and probably don't want #2. (We won't even touch #1 in that context :). -Barry From bwarsaw at beopen.com Mon Jul 24 05:12:33 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:12:33 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> <3979CBFC.2EED0234@prescod.net> <14713.65260.762631.233327@anthem.concentric.net> <20000723115627.B27195@newcnri.cnri.reston.va.us> Message-ID: <14715.46113.795737.74175@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> Bad example; quick-and-dirty CGI scripts may get away with AK> using print. However, if you want decent error handling, such AK> as not outputting a partial page if you get an exception, you AK> need to either not use print, or replace sys.stdout to trap AK> output from 'print' and only send the output once it's all AK> been generated. You're right, of course. I think extended print would make writing stuff like this more readable. -Barry From bwarsaw at beopen.com Mon Jul 24 05:21:59 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:21:59 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.64973.585633.87443@anthem.concentric.net> Message-ID: <14715.46679.547126.183981@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: | [Paul] | log.writeln($"post to ${listname} from ${sender}, size=${len(msg)}") TP> where I've put back the comma from Barry's original. Perhaps TP> Barry will counter with | print >> log, $"post to ${listname} from ${sender}, size=${len(msg)}" Actually, I'd counter with something quite similar, but much more Pythonic. print >> log, 'post to %(listname)s from %(sender)s, size=%(msglen)s' % { 'listname': listname, 'sender' : sender, 'msglen' : len(msg), } variants of which I use all the time! TP> But there's not a new suggestion in this whole thing -- even TP> ">>" specifically was suggested long ago for this purpose. :) -Barry From bwarsaw at beopen.com Mon Jul 24 05:29:21 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:29:21 -0400 (EDT) Subject: [Python-Dev] pep-dev References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> <397BAD28.E4BF7E54@prescod.net> Message-ID: <14715.47121.177301.678752@anthem.concentric.net> I think this is a very good idea Paul. -Barry From tim_one at email.msn.com Mon Jul 24 05:40:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 23:40:18 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14715.46679.547126.183981@anthem.concentric.net> Message-ID: [Paul] > log.writeln($"post to ${listname} from ${sender}, size=${len(msg)}") [Tim] > where I've put back the comma from Barry's original. Perhaps > Barry will counter with > > print >> log, $"post to $listname from $sender, size=$(len(msg))" [Barry] > Actually, I'd counter with something quite similar, but much more > Pythonic. > > print >> log, 'post to %(listname)s from %(sender)s, > size=%(msglen)s' % { > 'listname': listname, > 'sender' : sender, > 'msglen' : len(msg), > } > > variants of which I use all the time! Me too, but because there's nothing better: Perl people think it's *entirely* Pythonic to, e.g., need to type "listname" three times where they only need to type it once <1/3 wink>. That much redundancy on a single line of code is not helpful at all. This is simply an area where Perl is friendlier & easier. As I mentioned in another msg, Python's %(name)format shines when format is non-trivial; alas, plain unqualified %s formats account for the vast bulk of uses in my experience. From paul at prescod.net Mon Jul 24 05:41:39 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 22:41:39 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> <14715.45967.555713.668818@anthem.concentric.net> Message-ID: <397BBAF3.683DE578@prescod.net> "Barry A. Warsaw" wrote: > > No we're not! From token.h: > > #define RIGHTSHIFT 35 Okay, okay, you're inventing a new semantic for an existing token. > Where would people look to use >> in this sense elsewhere? You've got me. Maybe nowhere. Maybe they'll just ask why >> is a binary operator except in print. Maybe they'll see a=j>>k and think it has something to do with string printing. That's reasonable if you don't have the C-family background. Maybe they just look back after six months and say: "Why the hell did I learn that >> hack if it is never going to be used anywhere else in the language?" Maybe they'll just be sitting in the front row of my Python class and say: "that looks like somewhat of a hack and it reminds me of one of the ugliest features of C++" and I won't have any answer except to say: "yes its a hack, but believe me Python isn't really a hacky language...there are just a few." We all have different design aesthetics. I would rather see a hundred clean features added to Python's syntax rather than one hack. You'll recall that when you announced the addition of string methods I told you that you had cleaned up one of my two big Python embarrassments. print is the other. Renumbering: > 1 no requirement for parens > 2 newline by default > 3 easy string coercion > 4 easy string interpolation > 5 less thinking about whitespace > > Don't these things mostly crop up in printing, in one form or > another. I can imagine you might want to use something like #4 or > #5 when, e.g. building a string to be used as a regex, but in that > case, you already have #4 and #5, and probably don't want #2. (We > won't even touch #1 in that context :). I don't follow. Consider: I'm building up a string to be used to search my phones database. (Prescod, Paul): phone=555-1211, fax=555-2121 Don't I want 3, 4 and 5? Why do you say I "already have them?" def lookup( query ) regex=$"${person.lastname},${person.firstname}: .*${query}=(\w+)" .... lookup( "phone" ) lookup( "fax" ) Sure, I could set up a tuple or a dict but you pointed out yesterday that that is inconvenient. If it's too inconvenient for people who are printing things then I think it's too inconvenient for everyone. (yes, I'm confident that there is a bug in my regexp logic -- you get the picture!) -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From skip at mojam.com Mon Jul 24 06:12:17 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 23 Jul 2000 23:12:17 -0500 (CDT) Subject: [Python-Dev] map() for methods In-Reply-To: References: <39771CCE.F70A48D4@lemburg.com> Message-ID: <14715.49697.141824.636846@beluga.mojam.com> A couple people have responded to my comment about deprecating the string without deprecating map(). Most recently, Tim stated: >> As far as I'm aware, there's no clean way to do that with string >> methods. Tim> Sorry if someone pointed this out already (2K+ msgs backed up!): Tim> newlist = [s.strip() for s in oldlist] I realized that list comprehensions were possible, but they aren't yet in the language, so I didn't think them a fair substitute for map(string.strip, oldlist) If you get list comprehensions in there in some guise, then sure, deprecate away... Skip From skip at mojam.com Mon Jul 24 06:24:16 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 23 Jul 2000 23:24:16 -0500 (CDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <3979C032.357FCAF4@prescod.net> References: <20000722092530.A24247@newcnri.cnri.reston.va.us> <3979C032.357FCAF4@prescod.net> Message-ID: <14715.50416.423999.54454@beluga.mojam.com> Paul> I think it is also worthwhile to recognize "conventions" that Paul> could be made clearer with first-class syntax. List comprehensions Paul> replace the map/lambda convention (and would IMHO, allow Paul> map/filter, at-least, to be deprecated). Range literals replace Paul> the for i in range(...) convention and so forth. Range literals would also allow compilers such as Python2C to optimize Python ints to C ints. It can't do this today without assuming that range() and xrange return a sequence of ints. I guess I'll stick my neck way out there with Barry and say I rather like his "print @" proposal. Most new Python programmers learn about print earlier than a combination of somefile.write() + the "%" operator. While it might mostly be syntactic sugar, it is generally easier for new folks to understand. I suspect (though won't bother to check) that most of the I/O in the Python tutorial uses print instead of sys.stdout.write as well. Extending print's semantics to other file-like objects makes sense to me. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From skip at mojam.com Mon Jul 24 06:34:53 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 23 Jul 2000 23:34:53 -0500 (CDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <3979C9E4.E66FE451@prescod.net> References: <20000722092530.A24247@newcnri.cnri.reston.va.us> <3979C9E4.E66FE451@prescod.net> Message-ID: <14715.51053.852304.213936@beluga.mojam.com> Paul> Common Lisp and Linux are victims of feature creep. Perl and Paul> Sendmail just suck. Whoa there! Not to get into an off-topic shouting match of tit-for-tat, but Sendmail's syntax dates from a time when things were a lot less uniform than they are today. Machines were a helluva lot slower, had lots less memory and faced a decidedly less uniform email environment than later tools did. I don't believe early versions of Sendmail had "frozen" config files either, so parsing fast (probably with a very crude, ad hoc parser) was important. The universe of email possibilities -- both in addressing and connectivity -- was much broader than it is today. You had !-paths, Bitnet, SMTP, CSNet, direct connections, store-and-forward and fewer standards (like RFC-822 and its descendants). Unlike more recent tools, Sendmail did it all. That very few people ever have to stare at a raw sendmail.cf file anymore is a big credit to the Sendmail gang in my opinion... Skip From moshez at math.huji.ac.il Mon Jul 24 07:02:32 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 24 Jul 2000 08:02:32 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14715.45462.695712.12998@anthem.concentric.net> Message-ID: On Sun, 23 Jul 2000, Barry A. Warsaw wrote: > Add a `sep' keyword, check for residual keyword arguments, and I might > be +0 on that. Of course, now you're in the realm of... > > so-easy-i'll-just-cut-and-paste-this-into-my-own-app-ly y'rs, Well, I know Python, being very quick to write in, makes this awfully easy. But I still thing people would use import sys sys.writeln("hello", first_name, last_name+",") rather then def writeln(*args, **kws): ... writeln(...) Actually, I'm beginning to think we need a utils.py module for this, and the cool generator stuff. If we decide we need this in the builtins, the builtin module could do the equivalent of "from utils import *" or-we-could-just-make-python-harder-to-write-in-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From moshez at math.huji.ac.il Mon Jul 24 07:21:03 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 24 Jul 2000 08:21:03 +0300 (IDT) Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: Message-ID: On Sun, 23 Jul 2000, Tim Peters wrote: > At the O'Reilly conference, it was announced that the Perl rewrite in C++ > (codenamed Topaz) has been abandoned. I didn't attend that session, but my > impression from others is that they attempted to model Perl objects directly > by C++ objects, and were frustrated by the consequent lack of low-level > control. As another data-point, I've heard from reliable sources that Topaz was written to use bleeding edge C++, including all manners of weird templates. C++ I might be able to live with, but a very least common denominator C++ -- otherwise you hurt the well-known Python portability, which is a major strength. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From klm at digicool.com Mon Jul 24 07:29:36 2000 From: klm at digicool.com (Ken Manheimer) Date: Mon, 24 Jul 2000 01:29:36 -0400 (EDT) Subject: [Python-Dev] aargh Message-ID: <14715.54336.634634.776495@korak.digicool.com> I'm feeling some dismay reading over recent postings to python-dev. Particularly some of the rancor in the print discussion, and "Thank god guido is still in charge, and not going to go crazy", countered by "but guido said he was going to do this or that, ha" - i found myself thinking that (1) i'm glad i'm not in guido's place, and (2) geeze, aren't we making guido job harder, not easier? What the heck is going on? I think people are sounding off too much, posing features and opinions when they don't *need* to do so. People should think twice before posing new python features - and hold off, a lot more of the time. Treat every single thing you propose as if it costs something significant - because it does! Not only does it take bandwidth - which could be concentrated on crucial ideas - but if the feature does fly, it means sacrificing some established familiarity, a valuable commodity in the language business. Change costs, and usually needs to be worth a lot to be worth the while! Those of you offering lots of clever changes - what are you doing? Do you really think they're all so important, or are you just pleased to be finding neat little ideas? Everyone needs to hold out for what they at least consider outstandingly important. Ken klm at digicool.com From thomas at xs4all.net Mon Jul 24 07:36:02 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 24 Jul 2000 07:36:02 +0200 Subject: [Python-Dev] pep-dev In-Reply-To: <397BAD28.E4BF7E54@prescod.net>; from paul@prescod.net on Sun, Jul 23, 2000 at 09:42:48PM -0500 References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> <397BAD28.E4BF7E54@prescod.net> Message-ID: <20000724073602.Y9897@xs4all.nl> On Sun, Jul 23, 2000 at 09:42:48PM -0500, Paul Prescod wrote: > "Barry A. Warsaw" wrote: > > I'm beginning to think that our role on python-dev is different than > > we thought. I think for a particular proposal for a new language > > feature, or core language functionality, it is our job to explore the > > details and ramifications as much as possible. These should be > > summarized in a PEP, and it must have running code or a working patch. For the record, this has always been how I saw PEPs, with the slight distinction that sometimes Guido would come along and offer divine guidance, and the PEP would reflect Guido's opinion in the end. There is nothing wrong with it reflecting the community's opinion, though, as long as the champion is able to grasp all of it. Guido's 'guidance' could just be his judgement of the final result ;) Though on some subjects, this might require a fair ammount of Guido-channeling on the side of the champion, in order not to waste too much time on things Guido will not allow anyway. Things like user-defined syntax in the core language. > Guido wouldn't need to read every message in PEP-dev because the whole > point is to come up with a PEP that he *could* read. In fact, nobody > would read every message of PEP-dev (well, maybe Thomas Wouters, he > seems to have infinite energy). Not at all ! I have been purposely ignoring most of the numerous messages on python-list about new operators, user-defined operators and multimethods. I even have trouble following python-dev sometimes ;) especially in the longer-posted threads. I seem to have near-endless energy discussing the finer points of coding style and standards, and actually toying with code, merely because programming is one of my great passions, and the only one I can't really relieve at work or with my girlfriend ;) > Each message could be clearly labelled as relating to this PEP or that one > and if you aren't interested, you could just ignore that thread. Excellent idea. We should have realized before that python-list and python-dev are too much 'involved' fora for proto-ideas: everyone worries (on both lists) that what someone else proposes is going to be accepted without counterword, so everyone has something to add or counter. I would suggest plenty of drafts before a PEP is accepted, though, and give everyone on python-list and python-dev time to get their own comments added to the PEP. If python.org is still being held hostage, I can create a couple of lists for this purpose (but Barry already knows that ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From esr at thyrsus.com Mon Jul 24 07:55:00 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 01:55:00 -0400 Subject: [Python-Dev] aargh In-Reply-To: <14715.54336.634634.776495@korak.digicool.com>; from klm@digicool.com on Mon, Jul 24, 2000 at 01:29:36AM -0400 References: <14715.54336.634634.776495@korak.digicool.com> Message-ID: <20000724015500.A14548@thyrsus.com> Ken Manheimer : > I think people are sounding off too much, posing features and opinions > when they don't *need* to do so. People should think twice before > posing new python features - and hold off, a lot more of the time. OK, the recent discussion has been chaotic. But it's had two results I think are valuable. 1. We killed off a bad syntax (for parallel iterations) and replaced it with a clean builtin function that will genuinely add to the language without adding undue complications (zip). 2. The PEPs will direct, and perhaps make unnecessary, a lot of future discussion on language extensions. Even failed PEPs will be valuable if they show that certain propositions that look initially attractive can't be well defined or can't justify their complexity overhead. Personally, I also think the case for range literals has been made even if the other PEPs fail on various grounds. -- Eric S. Raymond A ``decay in the social contract'' is detectable; there is a growing feeling, particularly among middle-income taxpayers, that they are not getting back, from society and government, their money's worth for taxes paid. The tendency is for taxpayers to try to take more control of their finances .. -- IRS Strategic Plan, (May 1984) From bwarsaw at beopen.com Mon Jul 24 07:45:18 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 24 Jul 2000 01:45:18 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> <14715.45967.555713.668818@anthem.concentric.net> <397BBAF3.683DE578@prescod.net> Message-ID: <14715.55278.925626.187181@anthem.concentric.net> | def lookup( query ) | regex=$"${person.lastname},${person.firstname}: .*${query}=(\w+)" | .... So let me try to guess what you mean here. I really have no idea if I'm right. $"..." is some new type of syntax that says to do magic name lookup and interpolation when creating the string. person.lastname must be an attribute on some object bound to the variable `person'. Where does `person' come from? I guess you'd use the normal namespace rules, so if I saw this function in your code I'd have to assume that person appears in the globals (because putting it in builtins is bad form and I don't see it in the function's locals). But you really don't need any of that new magic stuff or new syntax (or is it a new string type?). The nugget of interesting new functionality here is that your doing attribute lookup inside a string interpolation, and /that/ might be a cool thing to have. E.g. def lookup(query): regex = '%(person.lastname)s,%(person.firstname)s: .*%(query)s=(\w+)' \ % vars() seems reasonable to me, and doesn't add nearly as much new or magical stuff as your example above. -Barry From tim_one at email.msn.com Mon Jul 24 08:18:55 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 24 Jul 2000 02:18:55 -0400 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > ... > ...with two major releases with only a few weeks in between, I'm > afraid we'll see the usual "do we really need this?" rule being > replaced with "what can we add to make sure people know there's > really a difference?". FWIW, and as I understand it, at one point in the negotiations with CNRI, the idea was raised (by them) that the only way to release Python 2.0 with a different license than CNRI's new 1.6 license was indeed to make major changes so that "people know there's really a difference". I don't know whether that still applies, but at the time it sure seemed to intensify Guido's sense of urgency about these proposals <0.9 wink>. > obviously, things with fancy names and existing patches are on > the top of that list :-( And, in most cases, not only fancy names and patches, but also years of favorable preceding discussion. In particular, none of the things you mentioned (list comprehensions, augumented assignments, range literals) is in any sense new, or has escaped being debated to death multiple times. The only new thing in the debates this year was a convincing argument that the syntax for lockstep "for" loops probably sucked. the-"do-we-need-this?"-parts-were-decided-before-ly y'rs - tim From moshez at math.huji.ac.il Mon Jul 24 08:38:12 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 24 Jul 2000 09:38:12 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14715.44747.65722.305555@anthem.concentric.net> Message-ID: On Sun, 23 Jul 2000, Barry A. Warsaw wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> log.writeln("Post to ", listname, " from ", sender, " size=", > PP> len( msg )) > > That could work, if we added writeln() to all file-like objects. One > advantage of extending print is that the write() method is already a > documented (and existing) interface. No, this is an advantage for having "writeln" as a function rather then a method. > Isn't adding auto string-coercion a more radical suggestion than > extending print? Well, I'm not sure which one I fear more -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From paul at prescod.net Mon Jul 24 09:01:18 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 02:01:18 -0500 Subject: [Python-Dev] aargh References: <14715.54336.634634.776495@korak.digicool.com> Message-ID: <397BE9BE.14517764@prescod.net> Ken Manheimer wrote: > > ... > > Those of you offering lots of clever changes - what are you doing? Do > you really think they're all so important, or are you just pleased to > be finding neat little ideas? Everyone needs to hold out for what > they at least consider outstandingly important. Why? When did sharing ideas hurt anyone? If Guido likes them, he'll put them in. If he doesn't, we're wasting our own time. I think that trying to improve Python is a pretty good way to waste my time. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Mon Jul 24 09:23:30 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 02:23:30 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> <14715.45967.555713.668818@anthem.concentric.net> <397BBAF3.683DE578@prescod.net> <14715.55278.925626.187181@anthem.concentric.net> Message-ID: <397BEEF2.AF9E1C74@prescod.net> "Barry A. Warsaw" wrote: > > ... > The nugget of interesting new > functionality here is that your doing attribute lookup inside a string > interpolation, and /that/ might be a cool thing to have. Attribute lookup is just a special case of expressions. What if I needed to do a function call? *You* were the one that prompted me to think up this syntax (actually I probably remembered some it from some work Ping did years ago...) The original example had a function call in it. There is no nice way to integrate a function call (or method call) into ""%vars(). That's what gave rise this this: print >> log, 'post to %(listname)s from %(sender)s, size=%(msglen)s' % { 'listname': listname, 'sender' : sender, 'msglen' : len(msg), } It seems we're going around in circles, though. You were the one that said that the percent operator is inconvenient way back here: http://www.python.org/pipermail/python-dev/2000-July/013837.html I think you were right back then! Also, I agree with Tim that what we have is great for all kinds of corner cases but a pain for a lot of the common ones. Other minor problems include: 1. "Why do I have to say the s in %()s when I'm using the s formatting code 97.68% of the time?" I shouldn't need to. To me, the s looks like a pluralization of listname and sender. A template should have clear delimiters so that it is straightforward to read. 2. "Why do I have to tell it what namespace to evaluate in when 93.5% of the time, it's vars()?" Anyhow, you may be right that a less severe change is possible. I went with the dollar sign syntax because a) it is very much like many other languages that many programmers have used and b) because it didn't have the backwards compatibility issues of trying to stay compatible with printf (especially that trailing-s thing). -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From ping at lfw.org Mon Jul 24 11:13:42 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 24 Jul 2000 02:13:42 -0700 (PDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397BA5ED.D3C33699@prescod.net> Message-ID: On Sun, 23 Jul 2000, Paul Prescod wrote: > As happy as I am to have it called Prescod-ese, I admit to influence > from some languages that (otherwise) suck. :) I agree that formatting and interpolation is one area where Perl is much stronger, and it should be easy to do such things in Python. > credit-where-due 'ly yrs I kind of hate to do this, but i can't restrain myself from pointing out that i *did* propose just this solution quite recently, in: http://www.python.org/pipermail/python-dev/2000-July/012764.html I wrote a module to do this a few years ago (1996, i think). It supported attribute lookup, item lookup, and expressions. (No one has yet mentioned the issue of escaping the dollar sign, which i handled by doubling it.) See the exact rules described, with examples, at http://www.lfw.org/python/Itpl.html If you want to play, just download http://www.lfw.org/python/Itpl15.py and try the itpl() function in the module. I would be quite pleased if (for example) $"" performed the equivalent of a function call to itpl() on the enclosed string. Apologetically (& only *gently* indignant), -- ?!ng From fredrik at pythonware.com Mon Jul 24 11:18:33 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 24 Jul 2000 11:18:33 +0200 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: Message-ID: <00cd01bff550$244f9f90$0900a8c0@SPIFF> tim wrote: > > obviously, things with fancy names and existing patches are on > > the top of that list :-( > > And, in most cases, not only fancy names and patches, but also years of > favorable preceding discussion. In particular, none of the things you > mentioned (list comprehensions, augumented assignments, range literals) is > in any sense new, or has escaped being debated to death multiple times. yeah, but what concerns me here is that we're talking about a release within 4-6 weeks, but we don't even have all the PEPs in place... ::: I cannot really comment on the list comprehension syntax since the PEP isn't there yet, but if I remember the syntax correctly, maybe "list confusions" is a better name than "list comprehensions". I surely don't understand them... "execute a piece of code and do something magic with the result of the last expression"? The lambda syntax is bad enough (it should really support an optional "return"), and I'd rather not see more of that... makes me think of nasty C bugs (and Perl, but that's another story). I'm somewhere between -1 and -0 on this one; I would very much prefer if we left that one out for 2.1, and considered adding real blocks instead. ::: The augumented assignment proposal is okay. I've never seen this as a real problem -- if I find myself writing: somethingverylong = somethingverylong + 1 there's probably a design flaw somewhere. But they're easy to read and grok -- even if you haven't used C or Java before, it's pretty clear from context what they're doing. I'm +0 on this one. ::: The range literal syntax is questionable; the proposal claims that the advantages are: "clarity of purpose" -- really? I'd say it's far from clear that slices really are the same thing as integer lists. They're also somewhat hard to read... "efficiency" -- sorry, but this a bogus argument. it's perfectly possible to do this optimization in the interpreter (a method caching interpreter could for example treat for/in/range as a method of the local namespace) "consistency" -- this is basically the first argument once again, claiming that it's "logical" that ranges and slices are the same thing. I'm not so sure... I'm -0 on this one. Changing it to require a "subject" for the slicing (e.g. int[0:10]) would make me +0. ::: I'm also beginning to like Barry's ">> file" proposal. It's like the augumented assignment syntax -- it's easy to understand what it's doing when you see it in context. (it really should be "print #file", of course ;-) ::: finally, based on the title along, I'm totally +1 on PEP-209. From nhodgson at bigpond.net.au Mon Jul 24 12:13:00 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Mon, 24 Jul 2000 20:13:00 +1000 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: <00cd01bff550$244f9f90$0900a8c0@SPIFF> Message-ID: <039101bff557$bf947280$8119fea9@neil> > The augumented assignment proposal is okay. I've never seen this > as a real problem -- if I find myself writing: This is the third time I've seen this misspelling on the list. Is the collective Python subconscious trying to morph "augmented assignments" into "argumented assignments"? Neil From peter at schneider-kamp.de Mon Jul 24 14:40:31 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 24 Jul 2000 12:40:31 +0000 Subject: [Python-Dev] Re: Variables in strings.. References: <81324605608.20000724121203@buz.ch> Message-ID: <397C393F.E4AFEBB4@schneider-kamp.de> Gabriel Ambuehl wrote: > > print "Hello $name" > would do the job. Now the only solution I could find in Python was > this awful > print "Hello %(name)s" % var() There is of course: print "Hello", name print "Hello", name[1] But that is probably not what you ask for. There is a thread about extending the print statement right now at the python-dev mailing list: http://www.python.org/pipermail/python-dev/2000-July/thread.html Part of this thread deals with what you are looking for. You may want to read the whole thread, but a good point to start is Tim's first post in that subthread: http://www.python.org/pipermail/python-dev/2000-July/013895.html > syntax which, after all, doesn't even seem to support lists as > print "Hello %(name[1])s" % var() > just raises a KeyError. May anyone point me to some more comfortable > ways than just endless concatenation of strings and lists which doesn't really > help for readibility (which is one of the main points why I'm > switching from Perl to Python)? As far as I have understood matters, the $name $(name[1]) syntax woul be able to do what you want. But then I have not really followed that thread closely. Peter P.S.: To python-dev: Wouldn't it be better to discuss this on python-list (or pep-dev)? -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mal at lemburg.com Mon Jul 24 12:53:27 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 12:53:27 +0200 Subject: [Python-Dev] string formatting (extended print statement, uPre-PEP) References: Message-ID: <397C2027.CE8D411B@lemburg.com> Ka-Ping Yee wrote: > > On Sun, 23 Jul 2000, Paul Prescod wrote: > > As happy as I am to have it called Prescod-ese, I admit to influence > > from some languages that (otherwise) suck. :) > > I agree that formatting and interpolation is one area where Perl is > much stronger, and it should be easy to do such things in Python. > > > credit-where-due 'ly yrs > > I kind of hate to do this, but i can't restrain myself from pointing > out that i *did* propose just this solution quite recently, in: > > http://www.python.org/pipermail/python-dev/2000-July/012764.html > > I wrote a module to do this a few years ago (1996, i think). It > supported attribute lookup, item lookup, and expressions. (No one > has yet mentioned the issue of escaping the dollar sign, which i > handled by doubling it.) > > See the exact rules described, with examples, at > > http://www.lfw.org/python/Itpl.html > > If you want to play, just download > > http://www.lfw.org/python/Itpl15.py > > and try the itpl() function in the module. > > I would be quite pleased if (for example) $"" performed the > equivalent of a function call to itpl() on the enclosed string. Any reason this can't be emulated using the existing "..." % mapping syntax ? You'd just have to provide a smart mapping which evaluates the %(something)s tags in the format string to a string ready for insertion... something may even contain balanced parenthesis, so even function calls are within range. Note that a = 1 b = 2 print "We have %(a)s apples and %(b)s oranges" % locals() is already possible today without any additional magic. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Mon Jul 24 12:57:40 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 24 Jul 2000 03:57:40 -0700 Subject: [Python-Dev] Re: Feature bloat in Python In-Reply-To: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jul 23, 2000 at 10:12:38AM +0200 References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> Message-ID: <20000724035739.J10898@lyra.org> On Sun, Jul 23, 2000 at 10:12:38AM +0200, Fredrik Lundh wrote: > mark wrote: > > If you can't quickly and quietly win this friendly audience over, IMO the > > proposal has failed. If any proposal causes even a small thread on this > > forum that boils down to "but its not clear to me what this should do", > > then I would have thought it self-evident that the proposal sucks. > > Convincing us that it _should_ be obvious if only we were all a little > > brighter and more willing to accept change for changes sake doesn't > > help anyone, least of all the person making these statements > > from the new Tcl Code Team rules: > > "A project can also be proposed by someone outside the Tcl Core > Team, but it can't be approved without an advocate on the Tcl > Core Team who will take personal responsibility for it. A project > must have support from at least 2 members of the Tcl Core Team > (including the proposer); if anyone in the Tcl Core Team objects > to the proposal, then there must be at least 4 members in favor > (including the proposer). If there are two or more "no" votes then > the proposal is rejected, regardless of the number of people in > favor. > > "The idea here is that the Tcl Core Team can only work effectively > if it is highly collegial; any project that generates significant contro- > versy should not go into the Tcl core." Compare/contrast to Apache: Big changes / non-bug fixes "require consensus approval before the change can be committed." "An action item requiring consensus approval must receive at least 3 binding +1 votes and no vetos." Apache requires at least one maintainer for any code in the distro (sounds like Tcl will also require one). Changes require (3) people to agree/approve them (Tcl appears to say 2, unless a veto arrives and makes it 4). Vetos are very harsh in Apache and can be made and held (forever) by a *single* person. Most vetos occur simply because a particular patch/commit has some repercussion that the author didn't see, or there is an obviously "better" (for your particular definition of "better") way to do the thing. But a veto is also quite permanent, binding, and respected. As a result, Apache does tend to be cooperative to avoid vetoes on designs, but they do happen. Something that Mark didn't seem to make clear (but I believe he intended): If we have problems understanding how something will work, then how can we possibly expect it will be understood by Python users who (almost by definition of their absence on this list) have less experience with Python than we do? or: If it isn't obvious to us, then it will be opaque to the majority of users. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Mon Jul 24 14:51:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 07:51:02 -0500 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: Your message of "Sun, 23 Jul 2000 20:55:10 -0400." References: Message-ID: <200007241251.HAA14668@cj20424-a.reston1.va.home.com> All questions asked in this thread so far were answered correctly by Tim Peters. I'm only happy with the new license insofar as it represents a consensus between CNRI, the members of the Python Consortium and OSI that was very hard to reach. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Mon Jul 24 14:48:39 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 24 Jul 2000 14:48:39 +0200 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: ; from moshez@math.huji.ac.il on Mon, Jul 24, 2000 at 08:21:03AM +0300 References: Message-ID: <20000724144839.B266@xs4all.nl> On Mon, Jul 24, 2000 at 08:21:03AM +0300, Moshe Zadka wrote: > On Sun, 23 Jul 2000, Tim Peters wrote: > > At the O'Reilly conference, it was announced that the Perl rewrite in C++ > > (codenamed Topaz) has been abandoned. I didn't attend that session, but my > > impression from others is that they attempted to model Perl objects directly > > by C++ objects, and were frustrated by the consequent lack of low-level > > control. > As another data-point, I've heard from reliable sources that Topaz was > written to use bleeding edge C++, including all manners of weird > templates. > C++ I might be able to live with, but a very least common denominator C++ > -- otherwise you hurt the well-known Python portability, which is a major > strength. Tim himself stated that himself, in the very mail you half-quoted ;) C++ has some nice features, and it has a lot of (IMHO) not very nice features. Though I have to admit I'm not that up to speed in C++ features, I have seen C++ code do things that scared me shitless. They also have me wondering how efficient the generated code can be. Using C++ will hurt portability regardless, though. Not only because there are less C++ compilers than C compilers, but also because less people know C++ than C, and the *act* of porting gets harder. However, I do see some merit in making the current code compilable for a C++ compiler, and perhaps offering some extentions in the form of templates or such like Tim suggested. I haven't looked at that CXX thing, though, and I don't know if it (or direct extention code written C++) would benifit from a C++-compilable Python. In the mean time, it helps finding old prototype-less functions ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fredrik at pythonware.com Mon Jul 24 15:02:04 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 24 Jul 2000 15:02:04 +0200 Subject: [Python-Dev] Evolving Python (was Re: Feature bloat in Python ...) References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> Message-ID: <01c201bff56f$5daf0770$0900a8c0@SPIFF> barry wrote: > I'm beginning to think that our role on python-dev is different than > we thought. I think for a particular proposal for a new language > feature, or core language functionality, it is our job to explore the > details and ramifications as much as possible. if this is true, I really want a separate list for those of us who'd rather work on improving the implementation and the standard library. after all, adding more syntactic fl^H^Hstuff isn't the only way to improve Python... (and I'm pretty sure it's not the best way to improve it, either) From skip at mojam.com Mon Jul 24 15:50:22 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 24 Jul 2000 08:50:22 -0500 (CDT) Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <00cd01bff550$244f9f90$0900a8c0@SPIFF> References: <00cd01bff550$244f9f90$0900a8c0@SPIFF> Message-ID: <14716.18846.944097.966109@beluga.mojam.com> Fredrik> I cannot really comment on the list comprehension syntax since Fredrik> the PEP isn't there yet, but if I remember the syntax Fredrik> correctly, maybe "list confusions" is a better name than "list Fredrik> comprehensions". I surely don't understand them... Let me take a crack at explaining list comprehensions one more time. There is a patch available to play with, btw: https://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470 As current implemented (which is probably not precisely what people have been talking about), a list comprehension is simply a create a new list from one or more other lists to new using a series of constraint expressions. Working through some simple examples from the modified test_grammar.py: * multiplying a list by a constant... >>> nums = [1,2,3,4,5] >>> print [3*x for x in nums] [3, 6, 9, 12, 15] You can read this as, "for all values 3x such that x is in nums". * selecting a subset of a list... >>> print [x for x in nums if x > 2] [3, 4, 5] You can read this as, "for all values x such that x is in nums and x is greater than 2". * combining two lists... >>> strs = ["Apple", "Banana", "Coconut"] >>> print [i, s for i in nums for s in strs] [(1, 'Apple'), (1, 'Banana'), (1, 'Coconut'), (2, 'Apple'), (2, 'Banana'), (2, 'Coconut'), (3, 'Apple'), (3, 'Banana'), (3, 'Coconut'), (4, 'Apple'), (4, 'Banana'), (4, 'Coconut'), (5, 'Apple'), (5, 'Banana'), (5, 'Coconut')] You can read this as, "for all pairs (i,s) such that i is in nums and s is in strs". * nesting list comprehensions ... >>> print [i, s for i in nums for s in [f for f in strs if "n" in f]] [(1, 'Banana'), (1, 'Coconut'), (2, 'Banana'), (2, 'Coconut'), (3, 'Banana'), (3, 'Coconut'), (4, 'Banana'), (4, 'Coconut'), (5, 'Banana'), (5, 'Coconut')] You can read this as, "for all pairs (i,s) such that is is in nums as s is in the subset of nums that contains the letter 'n'". I don't think it's so different than the notation mathematicians use to describe and build sets. We don't have the luxury of convenient glyphs that mean "there exists" and "for all", however. As has been pointed out, the syntax is constrained by the demands of the current parser and preexisting expression syntax. For instance, we can't currently put "and" between the different clauses to clearly indicate that we are not nesting for statements without creating ambiguities. I don't know, perhaps that's simply an argument for stronger parsing technology for Python. If so, and a stronger parser would allow a more readable implementation of list comprehensions, I'd be in favor of delaying their introduction until such a parser was in place. I'm not the person to make the decisions about a new parser. Would (for example) a yacc/bison and lex/flex based parser be completely out of the question in the 2.1 to 2.2 timeframe? Would it allow a more expressive grammar? What portability issues would be involved? Skip From skip at mojam.com Mon Jul 24 16:09:45 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 24 Jul 2000 09:09:45 -0500 (CDT) Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <14716.18846.944097.966109@beluga.mojam.com> References: <00cd01bff550$244f9f90$0900a8c0@SPIFF> <14716.18846.944097.966109@beluga.mojam.com> Message-ID: <14716.20009.223815.39832@beluga.mojam.com> me> ... a list comprehension is simply a create a new list ... should be ... a list comprehension is simply a way to create a new list ... Also, in me> We don't have the luxury of convenient glyphs that mean "there me> exists" and "for all", however. I should have included "such that". It has, indeed, been a few years since I cracked a math book of any kind... ;-) Skip From jim at interet.com Mon Jul 24 16:20:16 2000 From: jim at interet.com (James C. Ahlstrom) Date: Mon, 24 Jul 2000 10:20:16 -0400 Subject: [Python-Dev] aargh References: <14715.54336.634634.776495@korak.digicool.com> Message-ID: <397C50A0.F63E7E8D@interet.com> Ken Manheimer wrote: > thinking that (1) i'm glad i'm not in guido's place, and (2) geeze, > aren't we making guido job harder, not easier? > I think people are sounding off too much, posing features and opinions > when they don't *need* to do so. People should think twice before > posing new python features - and hold off, a lot more of the time. > Treat every single thing you propose as if it costs something > significant - because it does! Way to go Ken!! I couldn't agree more!! No one can object to trying to improve Python. But there is insufficient fear and loathing of feature bloat and complexity. Members of this group are smart and can easily handle advanced features, but the same can not be said of c.l.p nor application programmers in general. Excess advanced features will hamper widespread acceptance of Python. JimA From akuchlin at mems-exchange.org Mon Jul 24 16:20:26 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 24 Jul 2000 10:20:26 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 22, 2000 at 01:41:03PM -0400 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> Message-ID: <20000724102026.A4196@kronos.cnri.reston.va.us> On Sat, Jul 22, 2000 at 01:41:03PM -0400, Tim Peters wrote: >since 1.5.2 was released to the public". The great recent burst of >Python-Dev activity in the CVS tree was not done at CNRI, or the bulk of it >even by people with any connection present or past to CNRI. The problem there is Unicode support, which has changed quite a bit since that time -- the default encoding, if nothing else. 1.6 will probably need to have Unicode disabled, or have support that's incompatible with 2.0, or someone will have to backport the current code to 1.6. (Better you guys than me, though...) --amk From akuchlin at mems-exchange.org Mon Jul 24 16:25:17 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 24 Jul 2000 10:25:17 -0400 Subject: [Python-Dev] Evolving Python In-Reply-To: <01c201bff56f$5daf0770$0900a8c0@SPIFF>; from fredrik@pythonware.com on Mon, Jul 24, 2000 at 03:02:04PM +0200 References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> <01c201bff56f$5daf0770$0900a8c0@SPIFF> Message-ID: <20000724102517.B4196@kronos.cnri.reston.va.us> On Mon, Jul 24, 2000 at 03:02:04PM +0200, Fredrik Lundh wrote: >if this is true, I really want a separate list for those of us who'd >rather work on improving the implementation and the standard >library. Seconded. There's lots of unsexy but useful stuff to be done simply making the core distribution a bit more solid or a bit faster, the demos a bit more up-to-date, the docs a bit more complete, &c. I think that part of my dislike of new language features stems from the redirection of effort away from such basic tasks. Can hardly wait until PEP-related discussion finds its new home, whether on c.l.p or on a pep-dev list. --amk From fdrake at beopen.com Mon Jul 24 16:33:54 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 24 Jul 2000 10:33:54 -0400 (EDT) Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724102026.A4196@kronos.cnri.reston.va.us> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> Message-ID: <14716.21458.361479.350602@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > The problem there is Unicode support, which has changed quite a bit And CNRI did handle the contracting for the Unicode support, so it's reasonable for it to be in there. But I wasn't at the consortium meeting, so don't know if any specific technical decisions were made there (I'd expect not). I was trapped on an airplane high above the earth, locked in battle with a recent version of LaTeX2HTML. ;( -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nowonder at pool.informatik.rwth-aachen.de Mon Jul 24 19:26:06 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Mon, 24 Jul 2000 17:26:06 +0000 Subject: [Python-Dev] object allocator References: <200007211227.OAA04028@python.inrialpes.fr> Message-ID: <397C7C2E.44DCBA39@pool.informatik.rwth-aachen.de> Hei Vladimir! I have taken the liberty to submit your obmalloc.c as a patch on SourceForge. I have done this to make it easier for others to try it. It should build out of the box. > All this needs to be pursued, probably PEP'ed, but I think I can > already emit my opinion about a compromise: Let's wait with PEP'ing until there has been at least some discussion. > That said, it would be nice if you could test this code on your combos > and report some results and impressions back here. Right now I can only say that it runs fine on SuSE Linux 6.4. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From bwarsaw at beopen.com Mon Jul 24 17:30:47 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 24 Jul 2000 11:30:47 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> <14715.45967.555713.668818@anthem.concentric.net> <397BBAF3.683DE578@prescod.net> <14715.55278.925626.187181@anthem.concentric.net> <397BEEF2.AF9E1C74@prescod.net> Message-ID: <14716.24871.915663.693288@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> 1. "Why do I have to say the s in %()s when I'm using the s PP> formatting code 97.68% of the time?" I shouldn't need to. To PP> me, the s looks like a pluralization of listname and sender. A PP> template should have clear delimiters so that it is PP> straightforward to read. PP> 2. "Why do I have to tell it what namespace to evaluate in PP> when 93.5% of the time, it's vars()?" >>>>> "KY" == Ka-Ping Yee writes: KY> I kind of hate to do this, but i can't restrain myself from KY> pointing out that i *did* propose just this solution quite KY> recently, in: KY> http://www.python.org/pipermail/python-dev/2000-July/012764.html KY> I wrote a module to do this a few years ago (1996, i think). KY> It supported attribute lookup, item lookup, and expressions. KY> (No one has yet mentioned the issue of escaping the dollar KY> sign, which i handled by doubling it.) I think I've been lulled into conflating two different issues. As I see it doing the interpolation is separate from where the output goes, however it's clear that ?!ng's printpl() function could grow the optional keyword arguments that Moshe suggested. Still, I think it makes sense for them to be two separate proposals (with cross references if necessary). I've decided to PEP the extended print syntax and would be more than happy to assign a PEP number for a string interpolation proposal, if someone else volunteers to champion it. -Barry From mal at lemburg.com Mon Jul 24 17:28:36 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 17:28:36 +0200 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> Message-ID: <397C60A4.A4A9513C@lemburg.com> Andrew Kuchling wrote: > > On Sat, Jul 22, 2000 at 01:41:03PM -0400, Tim Peters wrote: > >since 1.5.2 was released to the public". The great recent burst of > >Python-Dev activity in the CVS tree was not done at CNRI, or the bulk of it > >even by people with any connection present or past to CNRI. > > The problem there is Unicode support, which has changed quite a bit > since that time -- the default encoding, if nothing else. 1.6 will > probably need to have Unicode disabled, or have support that's > incompatible with 2.0, or someone will have to backport the current > code to 1.6. (Better you guys than me, though...) Hmm, why shouldn't it be possible to use the current version of Unicode support in 1.6 ? AFAIK, most of the patching was done by Fredrik and myself and we were not related to CNRI or BeOpen in any way at the time of the move to BeOpen. Wouldn't it suffice for Fredrik and me to send in a wet-sign for the Unicode patches since that date ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 24 17:39:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 17:39:53 +0200 Subject: [Python-Dev] Python CVS License ? Message-ID: <397C6349.7B441A80@lemburg.com> I was wondering what the license terms are for the current CVS snapshot... There's a lot of code in there which carries its own license or copyright, e.g. the Unicode stuff still only has the note "(c) Copyright CNRI, All Rights Reserved. NO WARRANTY." and the SRE modules are "Copyright (c) 1997-2000 by Secret Labs AB. All rights reserved.". As it stands, I guess the current CVS tree is not legally copyable or usable by anyone who wants decent Unicode support. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Mon Jul 24 22:13:10 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 15:13:10 -0500 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: <00cd01bff550$244f9f90$0900a8c0@SPIFF> Message-ID: <397CA356.4CF1F82B@prescod.net> Fredrik Lundh wrote: > >... > > yeah, but what concerns me here is that we're talking about a > release within 4-6 weeks, but we don't even have all the PEPs > in place... I do not believe it is a goal to implement all PEP-ed features in Python 2.0. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Mon Jul 24 18:17:47 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 11:17:47 -0500 Subject: [Python-Dev] Sorry Message-ID: <397C6C2B.ED72DF2F@prescod.net> I hate to bring up the zip name thing again but I'm strongly leaning toward something of the form: mktuples maketuples totuples gentuples tupleorama -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From Jasbahr at origin.EA.com Mon Jul 24 19:07:58 2000 From: Jasbahr at origin.EA.com (Asbahr, Jason) Date: Mon, 24 Jul 2000 12:07:58 -0500 Subject: [Python-Dev] Python Consortium Meeting News Message-ID: <11A17AA2B9EAD111BCEA00A0C9B4179305CB54FC@molach.origin.ea.com> Depending on the release schedule for 2.0, we may have to ship our product with Python 1.6, and Unicode is one of the key features we need from this release. I hope Marc is right that the current version of the Unicode support can be incorporated into the 1.6 official release. Cheers, Jason Asbahr Origin Systems, Inc. jasbahr at origin.ea.com -----Original Message----- From: M.-A. Lemburg [mailto:mal at lemburg.com] Sent: Monday, July 24, 2000 10:29 AM To: akuchlin at mems-exchange.org Cc: python-dev at python.org Subject: Re: [Python-Dev] Python Consortium Meeting News Andrew Kuchling wrote: > > On Sat, Jul 22, 2000 at 01:41:03PM -0400, Tim Peters wrote: > >since 1.5.2 was released to the public". The great recent burst of > >Python-Dev activity in the CVS tree was not done at CNRI, or the bulk of it > >even by people with any connection present or past to CNRI. > > The problem there is Unicode support, which has changed quite a bit > since that time -- the default encoding, if nothing else. 1.6 will > probably need to have Unicode disabled, or have support that's > incompatible with 2.0, or someone will have to backport the current > code to 1.6. (Better you guys than me, though...) Hmm, why shouldn't it be possible to use the current version of Unicode support in 1.6 ? AFAIK, most of the patching was done by Fredrik and myself and we were not related to CNRI or BeOpen in any way at the time of the move to BeOpen. Wouldn't it suffice for Fredrik and me to send in a wet-sign for the Unicode patches since that date ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ _______________________________________________ Python-Dev mailing list Python-Dev at python.org http://www.python.org/mailman/listinfo/python-dev From guido at beopen.com Mon Jul 24 18:45:30 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 11:45:30 -0500 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: Your message of "Mon, 24 Jul 2000 17:28:36 +0200." <397C60A4.A4A9513C@lemburg.com> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> Message-ID: <200007241645.LAA15974@cj20424-a.reston1.va.home.com> > Hmm, why shouldn't it be possible to use the current > version of Unicode support in 1.6 ? AFAIK, most of the patching > was done by Fredrik and myself and we were not related to > CNRI or BeOpen in any way at the time of the move to BeOpen. I would expect that untangling the patches from the ANSIfication would be too much work. I'm not too interested in doing that. > Wouldn't it suffice for Fredrik and me to send in a wet-sign > for the Unicode patches since that date ? I suppose so (but I can't speak for CNRI any more). One possibility, if there are people interested in helping out with 1.6, would be to create a branch on SF. But since this needs to be a branch relative to an old version, I'm not sure exactly how to do that. (The problem with checking out by date is that CVS gives you all the *deleted* files back, even if they were deleted at the selected date. Sigh.) Regarding incompatibilities between 1.6 and 2.0: we can simply mark the Unicode support in 1.6 as experimental, and announce that relying on the default conversion beyond ASCII in 1.6 causes forward compatibility problems. I plan to release 2.0 pretty soon after 2.0! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 24 18:47:34 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 11:47:34 -0500 Subject: [Python-Dev] Python CVS License ? In-Reply-To: Your message of "Mon, 24 Jul 2000 17:39:53 +0200." <397C6349.7B441A80@lemburg.com> References: <397C6349.7B441A80@lemburg.com> Message-ID: <200007241647.LAA15998@cj20424-a.reston1.va.home.com> > I was wondering what the license terms are for the current > CVS snapshot... > > There's a lot of code in there which carries > its own license or copyright, e.g. the Unicode stuff still > only has the note "(c) Copyright CNRI, All Rights Reserved. > NO WARRANTY." and the SRE modules are "Copyright (c) 1997-2000 by > Secret Labs AB. All rights reserved.". > > As it stands, I guess the current CVS tree is not legally > copyable or usable by anyone who wants decent Unicode support. And that's probably a good thing. It's a development tree -- please don't make releases of it! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul at prescod.net Mon Jul 24 18:09:58 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 11:09:58 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: Message-ID: <397C6A56.389B56CC@prescod.net> Ka-Ping Yee wrote: > > On Sun, 23 Jul 2000, Paul Prescod wrote: > > As happy as I am to have it called Prescod-ese, I admit to influence > > from some languages that (otherwise) suck. :) > > I agree that formatting and interpolation is one area where Perl is > much stronger, and it should be easy to do such things in Python. > > > credit-where-due 'ly yrs > > I kind of hate to do this, but i can't restrain myself from pointing > out that i *did* propose just this solution quite recently, in: > > http://www.python.org/pipermail/python-dev/2000-July/012764.html Sorry, for whatever reason I didn't actually read that message. It's sitting in the middle of a bunch of other messages I have marked as unread. You're right, you definately get credit for the idea and I'll let you take the flames when we introduce it to comp.lang.python. :) Why don't you PEP it? -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From thomas at xs4all.net Mon Jul 24 18:10:49 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 24 Jul 2000 18:10:49 +0200 Subject: [Python-Dev] ANSIfication. In-Reply-To: <397AE4F4.E1A9DDE0@lemburg.com>; from mal@lemburg.com on Sun, Jul 23, 2000 at 02:28:36PM +0200 References: <20000723022452.Q9897@xs4all.nl> <397AE4F4.E1A9DDE0@lemburg.com> Message-ID: <20000724181049.C266@xs4all.nl> On Sun, Jul 23, 2000 at 02:28:36PM +0200, M.-A. Lemburg wrote: [ Me complaining about externs everywhere ] > I'd suggest doing this in two steps: > 1. move the externs to pyport.h (which is the right place for > these platform dependent defines and includes) and > add #if 0 ... #endif around them > 2. check whether these are still needed during the beta phase and > if no one complains remove the cruft completely > Alternatively, you could also add specific platform dependent > #ifdefs to pyport.h which only enable the externs on those > platforms where they are needed. I did a bit of both. Those that already had a proper platform #ifdef or comment, I left in. The others are moved into a #if 0 block. If noone objects to the current setup, I'll start moving around the rest, too. If anyone has access to BeOS, Solaris and/or SGI, please try to see if the decls are really necessary, still :P Those are the 'unchecked' ones I included. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein at lyra.org Mon Jul 24 21:30:54 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 24 Jul 2000 12:30:54 -0700 Subject: [Python-Dev] [jon@latchkey.com: [ANNOUNCE] Jakarta-ORO Project] Message-ID: <20000724123054.W10898@lyra.org> The Java ORO stuff is now under the Apache Software Foundation license. I'm posting here because the licensing of the ORO stuff came up at the Consortium meeting the other day re: its inclusion in JPython. Information is available at The Apache Jakarta project also has a lighter weight regexp engine under the ASF license (depending on how much "stuff" is needed). Info at Please forward to the JPython lists as appropriate. Cheers, -g ----- Forwarded message from Jon Stevens ----- Reply-To: members at apache.org Date: Mon, 24 Jul 2000 12:07:05 -0700 Subject: [ANNOUNCE] Jakarta-ORO Project From: Jon Stevens To: just keeping you all in the loop. push yet another project onto the stack. :-) -jon ---------- From: Jon Stevens Reply-To: general at jakarta.apache.org Date: Mon, 24 Jul 2000 11:49:36 -0700 To: Cc: "Daniel F. Savarese" Subject: [ANNOUNCE] Jakarta-ORO Project Hey All, Thanks to a generous code donation by Daniel F. Savarese, we now have a full featured regex package for Java under a BSD/Apache license. "The Jakarta-ORO Java classes are a set of text-processing Java classes that provide Perl5 compatible regular expressions, AWK-like regular expressions, glob expressions, and utility classes for performing substitutions, splits, filtering filenames, etc. This library is the successor to the OROMatcher, AwkTools, PerlTools, and TextTools libraries from ORO, Inc. (www.oroinc.com). They have been donated to the Jakarta Project by Daniel Savarese (www.savarese.org), the copyright holder of the ORO libraries. Daniel will continue to participate in their development under the Jakarta Project." Come and get it: -jon ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/ From ping at lfw.org Mon Jul 24 20:48:04 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 24 Jul 2000 11:48:04 -0700 (PDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14716.24871.915663.693288@anthem.concentric.net> Message-ID: On Mon, 24 Jul 2000, Barry A. Warsaw wrote: > Still, I think it makes sense for them to be two separate proposals > (with cross references if necessary). I've decided to PEP the > extended print syntax and would be more than happy to assign a PEP > number for a string interpolation proposal, if someone else volunteers > to champion it. Okay, i'll do it. -- ?!ng From barry at scottb.demon.co.uk Mon Jul 24 22:38:15 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Mon, 24 Jul 2000 21:38:15 +0100 Subject: [Python-Dev] if/else and macros In-Reply-To: <20000717023950.E29590@lyra.org> Message-ID: <000001bff5af$17dffb60$060210ac@private> > > > ! #define UTF8_ERROR(details) \ > > > ! if (1) { \ > > > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > > > ! goto onError; \ > > > ! continue; \ > > > ! } else Try defining the macro this way: #define UTF8_ERROR(details) \ do { \ if (utf8_decoding_error(&s, &p, errors, (details))) \ goto onError; \ continue; \ } while(0) BArry From guido at beopen.com Mon Jul 24 22:00:39 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 15:00:39 -0500 Subject: [Python-Dev] "Michael Bryan Becraft": Brainbench Test in Python Message-ID: <200007242000.PAA17136@cj20424-a.reston1.va.home.com> Anyone interested? Please write directly to him. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------- Forwarded Message Date: Fri, 14 Jul 2000 13:31:23 -0400 From: "Michael Bryan Becraft" To: Subject: Brainbench Test in Python Dear sir, I am developing a test in Python 1.5 for assessing the skills of Python programmers, and wonder if anyone within your organisation would be interested in reviewing the test questions for us. I need at least one more reviewer, a task which generally takes 4-6 hours. The pay for the task would be $200 total (I realise that is not much), but would appreciate the input if there are any interested colleagues. If anyone is interested in what we do with online certifications, they can register to take free tests at our site. Thanks for your time, Mike Becraft Michael Bryan Becraft Assessment Development Manager - Brainbench Telephone: (703) 437-7849 Facsimile: (703) 437-7801 http://www.brainbench.com mailto:michael.becraft at brainbench.com ------- End of Forwarded Message From jeremy at beopen.com Mon Jul 24 22:55:26 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 24 Jul 2000 16:55:26 -0400 (EDT) Subject: [Python-Dev] Sorry In-Reply-To: <397C6C2B.ED72DF2F@prescod.net> References: <397C6C2B.ED72DF2F@prescod.net> Message-ID: <14716.44350.785087.111127@bitdiddle.concentric.net> Let's not discuss names on python-dev! Barry is writing the PEP on the subject. If you've got name ideas, send them to him. He can post of a summary of name discussions if it becomes an issue. Jeremy From bwarsaw at beopen.com Mon Jul 24 23:08:15 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 24 Jul 2000 17:08:15 -0400 (EDT) Subject: [Python-Dev] [jon@latchkey.com: [ANNOUNCE] Jakarta-ORO Project] References: <20000724123054.W10898@lyra.org> Message-ID: <14716.45119.543707.536193@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> The Java ORO stuff is now under the Apache Software Foundation GS> license. I'm posting here because the licensing of the ORO GS> stuff came up at the Consortium meeting the other day re: its GS> inclusion in JPython. Information is available at GS> Excellent. I knew this was going to happen and had been watching the Jakarta pages for it's public announcement. Thanks for posting about it. This and the release of JPython under the same license as CPython will mean an OSD compliant version of JPython without the silly dual licenses. I'm hoping this can all happen soon so we can move JPython development to SourceForge and start working on it again. GS> Please forward to the JPython lists as appropriate. | Cheers, Done, thanks. -Barry From effbot at telia.com Mon Jul 24 23:25:30 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 24 Jul 2000 23:25:30 +0200 Subject: [Python-Dev] [ Patch #100895 ] safe version of PyErr_Format Message-ID: <014501bff5b5$b4965520$f2a6b5d4@hagrid> not sure about the outcome here; should I go ahead and check it in? (properly ANSIfied, of course): http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From esr at thyrsus.com Mon Jul 24 23:40:19 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 17:40:19 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <200007241645.LAA15974@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 24, 2000 at 11:45:30AM -0500 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> Message-ID: <20000724174019.E31538@thyrsus.com> Guido van Rossum : > I plan to release 2.0 pretty soon after 2.0! Hm. I take it, then, that your time machine is back from the shop? -- Eric S. Raymond Sometimes the law defends plunder and participates in it. Sometimes the law places the whole apparatus of judges, police, prisons and gendarmes at the service of the plunderers, and treats the victim -- when he defends himself -- as a criminal. -- Frederic Bastiat, "The Law" From guido at beopen.com Tue Jul 25 00:35:53 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 17:35:53 -0500 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: Your message of "Mon, 24 Jul 2000 17:40:19 -0400." <20000724174019.E31538@thyrsus.com> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> Message-ID: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> > Guido van Rossum : > > I plan to release 2.0 pretty soon after 2.0! ESR > Hm. I take it, then, that your time machine is back from the shop? Argh. You know that I meant "after 1.6". Here's my current timeline (I'll post this on the web when we have access): - 1.6beta1 out around August 1 - 1.6final around August 15 - 2.0beta1 around August 30 - various betas - 2.0final around September 30 Obviously not every PEP will be included in 2.0. I plan on including these: zip(); list comprehensions; augmented assignments; range literals. Also whatever's in pep-0200. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Mon Jul 24 23:36:19 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 23:36:19 +0200 Subject: [Python-Dev] [ Patch #100895 ] safe version of PyErr_Format References: <014501bff5b5$b4965520$f2a6b5d4@hagrid> Message-ID: <397CB6D3.207B3599@lemburg.com> Fredrik Lundh wrote: > > not sure about the outcome here; should I go ahead > and check it in? (properly ANSIfied, of course): > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 +0 I would still like to see the snprintf() fallback solution somewhere in there, but what the heck... go ahead ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Tue Jul 25 00:47:52 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 17:47:52 -0500 Subject: [Python-Dev] [ Patch #100895 ] safe version of PyErr_Format In-Reply-To: Your message of "Mon, 24 Jul 2000 23:25:30 +0200." <014501bff5b5$b4965520$f2a6b5d4@hagrid> References: <014501bff5b5$b4965520$f2a6b5d4@hagrid> Message-ID: <200007242247.RAA17840@cj20424-a.reston1.va.home.com> > not sure about the outcome here; should I go ahead > and check it in? (properly ANSIfied, of course): > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 I'm for it, but don't know of all the consequences. It would be helpful to create a test suite that triggered all the calls to PyErr_Format() that exist in the core. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Mon Jul 24 23:54:38 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 23:54:38 +0200 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> Message-ID: <397CBB1E.D5AE9DF1@lemburg.com> Guido van Rossum wrote: > > Here's my current timeline > (I'll post this on the web when we have access): > > - 1.6beta1 out around August 1 > - 1.6final around August 15 > - 2.0beta1 around August 30 > - various betas > - 2.0final around September 30 > > Obviously not every PEP will be included in 2.0. I plan on including > these: zip(); list comprehensions; augmented assignments; range > literals. Also whatever's in pep-0200. How about adding XML support as the "Big New Feature" to 2.0 instead of 1.6 (if I remember correctly, XML was added after the BeOpen move, right) ? Not that I have anything against XML going into 1.6, but this would make the new version number a little more understandable. BTW, how rock solid is Python's builtin XML support ? I'm asking because I want to make our product XML aware and the various different parser implementations out there gave me a rather unsecure feeling about which one to go after... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Tue Jul 25 00:04:33 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 00:04:33 +0200 Subject: [Python-Dev] if/else and macros In-Reply-To: <000001bff5af$17dffb60$060210ac@private>; from barry@scottb.demon.co.uk on Mon, Jul 24, 2000 at 09:38:15PM +0100 References: <20000717023950.E29590@lyra.org> <000001bff5af$17dffb60$060210ac@private> Message-ID: <20000725000433.D266@xs4all.nl> On Mon, Jul 24, 2000 at 09:38:15PM +0100, Barry Scott wrote: > > > > ! #define UTF8_ERROR(details) \ > > > > ! if (1) { \ > > > > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > > > > ! goto onError; \ > > > > ! continue; \ > > > > ! } else > > Try defining the macro this way: > #define UTF8_ERROR(details) \ > do { \ > if (utf8_decoding_error(&s, &p, errors, (details))) \ > goto onError; \ > continue; \ > } while(0) That isn't going to work, and is the entire reason for the 'if' construction rather than the 'do {} while' one: the 'continue' applies to the innermost loop, the 'do {} while(0)', producing some decidedly unpredicted behaviour. Anyhow, I believe it's fixed more adequately now, or someone is going to ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Tue Jul 25 00:20:18 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 24 Jul 2000 18:20:18 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python Message-ID: <14716.49442.232191.940532@bitdiddle.concentric.net> I'm starting to work on PEP 200, the release schedule for 2.0. As part of that document, I'd like to write down some rules for contributing code to that release. I've come up with some guidelines based on the discussion we've had on python-dev since moving to SourceForge as well as some offline discussions at PythonLabs. I've included them below for comment and review. Once we have reached some agreement on what the rules should be, I'll add them to PEP 200 and check them in. Jeremy Use good sense when committing changes. You should know what we mean by good sense or we wouldn't have given you commit privileges <0.5 wink>. Some specific examples of good sense include: - Do whatever the dictator tells you. - Discuss any controversial changes on python-dev first. If you get a lot of +1 votes and no -1 votes, make the change. If you get a some -1 votes, think twice; consider asking Guido what he thinks. - If the change is to code you contributed, it probably makes sense for you to fix it. - If the change affects code someone else wrote, it probably makes sense to ask him or her first. - You can use the SF Patch Manager to submit a patch and assign it to someone for review. Any significant new feature must be described in a PEP and approved before it is checked in. Any significant code addition, such as a new module or large patch, MUST include test cases for the regression test and documentation. A patch should not be checked in until the tests and documentation are ready. If you fix a bug, you SHOULD write a test case that would have caught the bug. If you commit a patch from the SF Patch Manager or fix a bug from the Jitterbug database, be sure to reference the patch/bug number in the CVS log message. Also be sure to change the status in the patch manager or bug database. It is not acceptable for any checked in code to cause the regression test to fail. If a checkin causes a failure, it MUST be fixed within 24 hours or it will be backed out. All contributed C code MUST be ANSI C. If possible check it with two different compilers, e.g. gcc and MSVC. All contributed Python code MUST follow Guido's Python style guide. http://www.python.org/doc/essays/styleguide.html It is understood that any code contributed will be released under an Open Source license. Do not contribute code if it can't be released this way. From m.favas at per.dem.csiro.au Tue Jul 25 00:21:34 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Tue, 25 Jul 2000 06:21:34 +0800 Subject: [Python-Dev] Status of re...??? Message-ID: <397CC16E.89E1446B@per.dem.csiro.au> test_re has been failing (and not just failing, but failing incorrectly ) for some time now (test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou"). What's the future for re - is it planned to remove it from 2.0? -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From jeremy at beopen.com Tue Jul 25 00:30:44 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 24 Jul 2000 18:30:44 -0400 (EDT) Subject: [Python-Dev] Status of re...??? In-Reply-To: <397CC16E.89E1446B@per.dem.csiro.au> References: <397CC16E.89E1446B@per.dem.csiro.au> Message-ID: <14716.50068.826877.488769@bitdiddle.concentric.net> Good question! I'm at a complete loss about what's going on with the re module. There is no point in having a test that is supposed to fail, because it's impossible to tell the difference between an expected failure and an unexpected failure. I just proposed some guidelines for contributing code, which probably cross your message in transit, that included a guideline that no checked in code should cause the regression test to fail. If the problem is known SRE bugs, I think the re test should be temporarily changed to eliminate the known bugs. If SRE is later fixed, the test cases can be restored. What is the current schedule for fixing SRE? I need to know for the release schedule. Jeremy From m.favas at per.dem.csiro.au Tue Jul 25 00:36:05 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Tue, 25 Jul 2000 06:36:05 +0800 Subject: [Python-Dev] Failing regression tests... Message-ID: <397CC4D5.D6EC87E@per.dem.csiro.au> [Jeremy Hylton just wrote:] I just proposed some guidelines for contributing code, which probably cross your message in transit, that included a guideline that no checked in code should cause the regression test to fail. I know 64-bit platforms aren't mainstream (yet), but test_ucn has also been failing (test test_ucn crashed -- exceptions.UnicodeError : Unicode-Escape decoding error: Invalid Unicode Character Name) for quite a while now on these beasts. Bill Tutt proposed a patch, which Tim critiqued, while at the same time /F was producing another way of doing it , and... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From esr at thyrsus.com Tue Jul 25 01:09:35 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 19:09:35 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <200007242235.RAA17731@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 24, 2000 at 05:35:53PM -0500 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> Message-ID: <20000724190935.G31538@thyrsus.com> Guido van Rossum : > > Guido van Rossum : > > > I plan to release 2.0 pretty soon after 2.0! > > ESR > > Hm. I take it, then, that your time machine is back from the shop? > > Argh. You know that I meant "after 1.6". Yes. But the joke was not resistible. > Here's my current timeline > (I'll post this on the web when we have access): > > - 1.6beta1 out around August 1 > - 1.6final around August 15 > - 2.0beta1 around August 30 > - various betas > - 2.0final around September 30 A timetable. Excellent. Now I know when I have to get my stuff done (curses docs, enhanced Berkeley DB support). > Obviously not every PEP will be included in 2.0. I plan on including > these: zip(); list comprehensions; augmented assignments; range > literals. Also whatever's in pep-0200. All this makes me happy, except that I'm a touch dubious about list comprehensions now. Still like the idea, still think the syntax ought to be clearer somehow. -- Eric S. Raymond "As to the species of exercise, I advise the gun. While this gives [only] moderate exercise to the body, it gives boldness, enterprise, and independence to the mind. Games played with the ball and others of that nature, are too violent for the body and stamp no character on the mind. Let your gun, therefore, be the constant companion to your walks." -- Thomas Jefferson, writing to his teenaged nephew. From mal at lemburg.com Tue Jul 25 01:05:20 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 25 Jul 2000 01:05:20 +0200 Subject: [Python-Dev] Failing regression tests... References: <397CC4D5.D6EC87E@per.dem.csiro.au> Message-ID: <397CCBB0.A8D7F6DC@lemburg.com> Mark Favas wrote: > > [Jeremy Hylton just wrote:] > I just proposed some guidelines for contributing code, which probably > cross your message in transit, that included a guideline that no > checked in code should cause the regression test to fail. > > I know 64-bit platforms aren't mainstream (yet), but test_ucn has also > been failing (test test_ucn crashed -- exceptions.UnicodeError : > Unicode-Escape decoding error: Invalid Unicode Character Name) for quite > a while now on these beasts. Bill Tutt proposed a patch, which Tim > critiqued, while at the same time /F was producing another way of doing > it , and... The patch is there on SF... but AFAIK, Fredrik has not yet finished work on it. I would rather like to see /Fs new module in the distribution because of its reduced size. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Tue Jul 25 01:05:39 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 24 Jul 2000 18:05:39 -0500 (CDT) Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724190935.G31538@thyrsus.com> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> Message-ID: <14716.52163.222710.772833@beluga.mojam.com> Eric> A timetable. Excellent. Now I know when I have to get my stuff Eric> done (curses docs, enhanced Berkeley DB support). Eric, you are aware that there is a libdb 2.0 module floating around already, right? >> Obviously not every PEP will be included in 2.0. I plan on including >> these: zip(); list comprehensions; augmented assignments; range >> literals. Also whatever's in pep-0200. Skip From jeremy at beopen.com Tue Jul 25 01:57:10 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 24 Jul 2000 19:57:10 -0400 (EDT) Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> Message-ID: <14716.55254.609098.924791@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> Obviously not every PEP will be included in 2.0. I plan on GvR> including these: zip(); list comprehensions; augmented GvR> assignments; range literals. Also whatever's in pep-0200. Given the release schedule you mentioned, we need to start making progress on the PEPs. I suggest we aim for completed design documents for these features by Aug. 9; that leaves three weeks between completion of design document and first beta release. Jeremy From esr at thyrsus.com Tue Jul 25 02:07:17 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 20:07:17 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <14716.52163.222710.772833@beluga.mojam.com>; from skip@mojam.com on Mon, Jul 24, 2000 at 06:05:39PM -0500 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> Message-ID: <20000724200717.A32163@thyrsus.com> Skip Montanaro : > > Eric> A timetable. Excellent. Now I know when I have to get my stuff > Eric> done (curses docs, enhanced Berkeley DB support). > > Eric, you are aware that there is a libdb 2.0 module floating around > already, right? I'm in touch with the authors, Robin Dunn and Greg Smith. Robin wrote the 2.0 module; Greg updated it for the latest version of libdn, 3.1.55. They both recommend using Greg's version. We've discussed the following plan: 1. Import Greg's 3.x module into the Python core. 2. Adapt Robin's dbShelve stuff to work with Greg's code. (My high-level goal in all this is to give shelves many-readers/one-writer locking so they can be used as session databases by Python CGI scripts). 3. Document it all. Both Greg and Robin are enthusiastic about having this code in the core and are willing to put it under the distribution's license. Yes, there is a test suite. The only problem with this plan is that I don't understand the Python distribution's module build system and step 1 looks kind of hairy. Is this stuff documented anywhere? -- Eric S. Raymond The price of liberty is, always has been, and always will be blood. The person who is not willing to die for his liberty has already lost it to the first scoundrel who is willing to risk dying to violate that person's liberty. Are you free? -- Andrew Ford From akuchlin at cnri.reston.va.us Tue Jul 25 02:17:21 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Mon, 24 Jul 2000 20:17:21 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724200717.A32163@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 24, 2000 at 08:07:17PM -0400 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> Message-ID: <20000724201721.A9990@newcnri.cnri.reston.va.us> On Mon, Jul 24, 2000 at 08:07:17PM -0400, Eric S. Raymond wrote: >1. Import Greg's 3.x module into the Python core. ... >The only problem with this plan is that I don't understand the Python >distribution's module build system and step 1 looks kind of hairy. Is >this stuff documented anywhere? Try reading the comments at the top of Modules/Setup.in. For a very simple module that's only a file or two, like posixmodule.c or the md5 module, you can simply add an appropriate line to Setup.in. But I vaguely recall that the 3.x bsddb module is a bunch of files -- if that's the case, I'm not sure what to do. For PCRE, I wrote a script which munges several source files into one big pypcre.c, but this is messy and probably was a mistake. I'm not sure what's involved in extending the system to support building in subdirectories of Modules/. (Maybe a line like "pcre pcre/pcre.c pcre/compile.c pcre/study.c ..." in Setup.in would just magically work?) --amk From nowonder at pool.informatik.rwth-aachen.de Tue Jul 25 09:02:51 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Tue, 25 Jul 2000 07:02:51 +0000 Subject: [Python-Dev] guidelines for contributing to Python References: <14716.49442.232191.940532@bitdiddle.concentric.net> Message-ID: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Jeremy Hylton wrote: > > If you fix a bug, you SHOULD write a test case that would have caught > the bug. Two questions: - Where should a test for a bug in Python/compile.c go? - Do we really need to carry around a test for (almost) every bug? > If you commit a patch from the SF Patch Manager or fix a bug from the > Jitterbug database, be sure to reference the patch/bug number in the > CVS log message. Also be sure to change the status in the patch > manager or bug database. "Be sure to have access to the bug database." I don't think I have. BTW: Is there some reason why we don't switch to the SF bug stuff? [Disclaimer: I have no experience with that part of SF, I am just plain curious] Peter P.S.: I don't like this SHOUTING should, must etc. -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From fdrake at beopen.com Tue Jul 25 07:15:35 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 01:15:35 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: <14717.8823.421584.948836@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > P.S.: I don't like this SHOUTING should, must etc. I don't either, but I think I know where it came from. There's an IETF RFC that carefully defines these terms as they relate to standards compliance, and IETF documents use them this way (capitalized). I think we should follow the W3C lead on this one: they adopt the IETF RFC but state that the terms are not specially cased; they are shown as normal English words. (I think the RFC doesn't actually require the capitalization, but I'm not certain offhand.) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Jul 25 07:19:44 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 01:19:44 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: <14717.9072.475757.832530@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > Two questions: > - Where should a test for a bug in Python/compile.c go? > - Do we really need to carry around a test for (almost) every bug? I'd rather carry around the test cases than lose them. These are important for regression tests where a large part of the point is that the implementation doesn't regress and allow an old bug (or it's symptoms) to resurface without being detected. > "Be sure to have access to the bug database." I don't think I have. This sort of thing is a serious problem. > BTW: Is there some reason why we don't switch to the SF bug stuff? > [Disclaimer: I have no experience with that part of SF, I am > just plain curious] I think the SourceForge developers may be looking into importing a Jitterbug database; once that's possible we should definately move that service over. Jitterbug *really* sucks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From dan at cgsoftware.com Tue Jul 25 07:26:13 2000 From: dan at cgsoftware.com (Daniel Berlin) Date: Mon, 24 Jul 2000 22:26:13 -0700 (PDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: On Tue, 25 Jul 2000, Peter Schneider-Kamp wrote: > Jeremy Hylton wrote: > > > > If you fix a bug, you SHOULD write a test case that would have caught > > the bug. > > Two questions: > - Where should a test for a bug in Python/compile.c go? > - Do we really need to carry around a test for (almost) every bug? Yes. It's the only way to make sure it doesn't happen again. GCC has about 6000 regression tests currently, fer instance. Each came about as part of a bug reported (usually what happens is someone takes the preprocessed source sent in with the bug report, and distills it down to about 100-1024 bytes worth of code that demonstrate the bug.). --Dan From bwarsaw at beopen.com Tue Jul 25 07:35:46 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 01:35:46 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python References: <14716.49442.232191.940532@bitdiddle.concentric.net> Message-ID: <14717.10034.65655.779012@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> All contributed Python code MUST follow Guido's Python style JH> guide. http://www.python.org/doc/essays/styleguide.html I'd like to create two new PEPs, one which would be a Python coding style guide, based on Guido's seminal essay, but updated, and a C coding style guide for modules and core C code. I'd probably eventually like to add one for Java code in the JPython core as well. Any objections to PEPing these, even though it may be a little while before they're fleshed out? Anybody else care to champion them? If not, I will do it. -Barry From bwarsaw at beopen.com Tue Jul 25 07:38:26 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 01:38:26 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python References: <14716.49442.232191.940532@bitdiddle.concentric.net> <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.9072.475757.832530@cj42289-a.reston1.va.home.com> Message-ID: <14717.10194.305692.8974@anthem.concentric.net> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> I think the SourceForge developers may be looking into Fred> importing a Jitterbug database; once that's possible we Fred> should definately move that service over. Jitterbug Fred> *really* sucks! I've been using the SF bug tracker for Mailman and it definitely sucks less than Jitterbug. Not perfect, but very usable. One thing I'd like to see (and I've made a request for this), is the ability to link bugs and patches. Very often a Mailman user will post a bug report and a dever will post a patch to fix the bug. It'd be nice if there could be a direct crosslink between the two. And if SF can import a Jitterbug database, that'd be a huge win! -Barry From bwarsaw at beopen.com Tue Jul 25 07:40:32 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 01:40:32 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: <14717.10320.356127.243997@anthem.concentric.net> >>>>> "DB" == Daniel Berlin writes: DB> Yes. It's the only way to make sure it doesn't happen again. DB> GCC has about 6000 regression tests currently, fer instance. DB> Each came about as part of a bug reported (usually what DB> happens is someone takes the preprocessed source sent in with DB> the bug report, and distills it down to about 100-1024 bytes DB> worth of code that demonstrate the bug.). Absolutely agreed. I can't even count the number of times that my regression test suite saved much embarrassment with CC Mode. Python is a big complex system with many interacting pieces. A butterfly change here can cause a hurricane breakage elsewhere. It's exactly this kind of thing the regression tests will catch. -Barry From paul at prescod.net Tue Jul 25 09:15:10 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 25 Jul 2000 02:15:10 -0500 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <397CBB1E.D5AE9DF1@lemburg.com> Message-ID: <397D3E7E.520C7440@prescod.net> "M.-A. Lemburg" wrote: > > ... > > BTW, how rock solid is Python's builtin XML support ? I'm asking > because I want to make our product XML aware and the various > different parser implementations out there gave me a rather > unsecure feeling about which one to go after... If by "rock solid" you mean "doesn't crash and doesn't leak memory" then yeah, I think its pretty rock solid but someone like you should kick PyExpat's Unicode tires more forcefully than they have been kicked. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Tue Jul 25 09:19:43 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 25 Jul 2000 02:19:43 -0500 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <397CBB1E.D5AE9DF1@lemburg.com> Message-ID: <397D3F8F.44EB162A@prescod.net> "M.-A. Lemburg" wrote: > > ... > > BTW, how rock solid is Python's builtin XML support ? I'm asking > because I want to make our product XML aware and the various > different parser implementations out there gave me a rather > unsecure feeling about which one to go after... If by "rock solid" you mean "doesn't crash and doesn't leak memory" then yeah, I think its pretty rock solid but someone like you should kick PyExpat's Unicode tires more forcefully than they have been kicked. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From moshez at math.huji.ac.il Tue Jul 25 09:30:53 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 10:30:53 +0300 (IDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <14717.9072.475757.832530@cj42289-a.reston1.va.home.com> Message-ID: On Tue, 25 Jul 2000, Fred L. Drake, Jr. wrote: > I think the SourceForge developers may be looking into importing a > Jitterbug database; once that's possible we should definately move > that service over. Jitterbug *really* sucks! In the mean time, could anyone send an explanation about Jitterbug? (where it is, what should we look for, etc.) -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From tim_one at email.msn.com Tue Jul 25 10:16:50 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 04:16:50 -0400 Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: Message-ID: [Moshe Zadka] > In the mean time, could anyone send an explanation about > Jitterbug? (where it is, what should we look for, etc.) Jitterbug is the bug-tracking system Python currently uses (at python.org). That's why it would be keen if SourceForge could import all its info by magic. From mal at lemburg.com Tue Jul 25 10:54:15 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 25 Jul 2000 10:54:15 +0200 Subject: [Python-Dev] Python's new builtin XML support (Python Consortium Meeting News) References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <397CBB1E.D5AE9DF1@lemburg.com> <397D3F8F.44EB162A@prescod.net> Message-ID: <397D55B7.4C7B664C@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > BTW, how rock solid is Python's builtin XML support ? I'm asking > > because I want to make our product XML aware and the various > > different parser implementations out there gave me a rather > > unsecure feeling about which one to go after... > > If by "rock solid" you mean "doesn't crash and doesn't leak memory" then > yeah, I think its pretty rock solid but someone like you should kick > PyExpat's Unicode tires more forcefully than they have been kicked. I will once I find time to look into these things :-) My concern was basically about design changes (I always assume that code going into the core doesn't crash and tries not to leak memory ;-) -- before trying to come up with an integration scheme I wan't to be sure that the backend will remain functional across at least two Python versions. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Tue Jul 25 10:59:46 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 11:59:46 +0300 (IDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: Message-ID: On Tue, 25 Jul 2000, Tim Peters wrote: > [Moshe Zadka] > > In the mean time, could anyone send an explanation about > > Jitterbug? (where it is, what should we look for, etc.) > > Jitterbug is the bug-tracking system Python currently uses (at python.org). > That's why it would be keen if SourceForge could import all its info by > magic. No, I meant something along the lines of "the jitterbug database is at the following URL:, to get a list of the currently-open bugs, do this, to get a list of the bugs which are related to some area do that" and so on. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From nowonder at pool.informatik.rwth-aachen.de Tue Jul 25 13:36:56 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Tue, 25 Jul 2000 11:36:56 +0000 Subject: [Python-Dev] guidelines for contributing to Python References: Message-ID: <397D7BD8.9584187F@pool.informatik.rwth-aachen.de> Moshe Zadka wrote: > > No, I meant something along the lines of "the jitterbug database is at the > following URL:, to get a list of the currently-open bugs, do this, to get > a list of the bugs which are related to some area do that" and so on. Non-authoritative answer: the jitterbug database is at the following URL: http://www.python.org/python-bugs [parrot.python.org at 132.151.19.90] to get a list of the currently-open bugs, click on open (between the second last and the last horizontal ruler) to get a list of the bugs which are related to some area, enter an appropriate regular expression and press "Select Messages", then select open (or whatever category you'd like to view) hope-that-helps-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From nowonder at pool.informatik.rwth-aachen.de Tue Jul 25 13:39:11 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Tue, 25 Jul 2000 11:39:11 +0000 Subject: [Python-Dev] guidelines for contributing to Python References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> Message-ID: <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> Okay, so where do I put that test for Python/compile.c? BTW: Someone with the right permissions might want to close open bug 81 (duplicate keyword args) Peter "Barry A. Warsaw" wrote: > > Absolutely agreed. I can't even count the number of times that my > regression test suite saved much embarrassment with CC Mode. Python > is a big complex system with many interacting pieces. A butterfly > change here can cause a hurricane breakage elsewhere. It's exactly > this kind of thing the regression tests will catch. -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From fdrake at beopen.com Tue Jul 25 13:32:30 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 07:32:30 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <14717.10034.65655.779012@anthem.concentric.net> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> Message-ID: <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > I'd like to create two new PEPs, one which would be a Python coding > style guide, based on Guido's seminal essay, but updated, and a C > coding style guide for modules and core C code. I'd probably > eventually like to add one for Java code in the JPython core as well. Why would these be PEPs? I know some of us had discussed that a style guide should be written as part of the standard documentation. The PEPs exist largely for developers of Python's interpreters and standard library. The style guide is for a larger audience, so needs to be part of the standard documentation. I stated at some point that I would convert Guido's "essay"; perhaps that should move up the list of priorities so that the other people interested can work with it; I seem to recall that you, Greg Wilson, and possibly Jeremy were interested. > Any objections to PEPing these, even though it may be a little while > before they're fleshed out? Anybody else care to champion them? If > not, I will do it. I'm willing if this is part of the standard documentation. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Tue Jul 25 14:38:19 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 07:38:19 -0500 Subject: [Python-Dev] ANSIfication. In-Reply-To: Your message of "Sun, 23 Jul 2000 02:24:53 +0200." <20000723022452.Q9897@xs4all.nl> References: <20000723022452.Q9897@xs4all.nl> Message-ID: <200007251238.HAA19158@cj20424-a.reston1.va.home.com> > I'm done checking in the ansification patches. It doesn't fix everything, > for a couple of reasons: Thanks for doing all this work, Thomas! Frankly, I think that for *any* functions that are in some external library (e.g. libc), Python should never provide a function prototype at all. The standard headers should provide the prototypes! There used to be a bunch of systems out there where the standard headers were inadequate for one reason or another -- e.g. some systems didn't bother to declare int functions, and Python was taking pointers to such functions. But this should all long be gone... I don't mind breaking some ports in a minor way by removing *all* prototypes for standard library functions. (Ditto for non-standard external libraries like readline.) I recall that more recently there were also some cases where a prototype wasn't in scope because the right combination of magical #defines wasn't present, especially for functions that weren't in the old POSIX or C standards. Adding prototypes for these is wrong: we should figure out the right #defines and define these in Python.h or config.h! > There are a couple of more things that might be candidate for cleanup or > removal now, by the way. The 'ANY' #define in Include/mymalloc.h, and the > type(s) derived from it, for instance. I'm not sure how 'standard' the void* > type is, but I thought it was ANSI mandated ? Yes, void* is ANSI. Get rid of all references to ANY. (Ages ago, on K&R systems ANY had to defined as char *.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Tue Jul 25 14:49:03 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 07:49:03 -0500 Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: Your message of "Tue, 25 Jul 2000 07:32:30 -0400." <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> Message-ID: <200007251249.HAA19269@cj20424-a.reston1.va.home.com> > Why would these be PEPs? I know some of us had discussed that a > style guide should be written as part of the standard documentation. > The PEPs exist largely for developers of Python's interpreters and > standard library. The style guide is for a larger audience, so needs > to be part of the standard documentation. Good point. But... > I stated at some point that I would convert Guido's "essay"; perhaps > that should move up the list of priorities so that the other people > interested can work with it; I seem to recall that you, Greg Wilson, > and possibly Jeremy were interested. The issue is that a new PEP feels much more lightweight than a new manual section. > > Any objections to PEPing these, even though it may be a little while > > before they're fleshed out? Anybody else care to champion them? If > > not, I will do it. > > I'm willing if this is part of the standard documentation. The Python style guide should probably go into the standard docs. The C style guide might as well be one of the meta-PEPs, like the index (maybe call it PEP 0100). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Tue Jul 25 13:57:49 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 07:57:49 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <200007251249.HAA19269@cj20424-a.reston1.va.home.com> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> <200007251249.HAA19269@cj20424-a.reston1.va.home.com> Message-ID: <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > The issue is that a new PEP feels much more lightweight than a new > manual section. There are a number of smaller manuals now (doc, dist, inst). > The C style guide might as well be one of the meta-PEPs, like the > index (maybe call it PEP 0100). Should it? I would expect it to be part of a single style guide or a chapter in the Extending & Embedding manual. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas at xs4all.net Tue Jul 25 14:21:20 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 14:21:20 +0200 Subject: [Python-Dev] ANSIfication. In-Reply-To: <200007251238.HAA19158@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 07:38:19AM -0500 References: <20000723022452.Q9897@xs4all.nl> <200007251238.HAA19158@cj20424-a.reston1.va.home.com> Message-ID: <20000725142120.G266@xs4all.nl> On Tue, Jul 25, 2000 at 07:38:19AM -0500, Guido van Rossum wrote: > Thanks for doing all this work, Thomas! I can't take all the credit, Fred and Peter did a lot of it, too. Also, my girlfriend's decision to spend the weekend catching up on her sleep mattered a lot ;) > Frankly, I think that for *any* functions that are in some external > library (e.g. libc), Python should never provide a function prototype > at all. The standard headers should provide the prototypes! Impeccable timing, Guido ! I competely agree, and this is why: I was just trying to figure out how to solve that problem on the one Solaris box we have. (An aging old beast, probably with a messed-up installation -- all SunOS experience we had has fled in horror when we moved to BSDI and Linux ;) I was encountering a lot of undeclared functions, and was dutifuly adding them to the SOLARIS block in pyport.h, when I found out that SOLARIS isn't defined :P I spent half an hour looking for a reliable way to detect the SunOS version, or even whether it's some Sun product at all, and failed. I'm not sure if that's a problem with Solaris or with that specific installation of it (Solaris 2.5.6, by the way,) but it convinced me to just forget about auto-detecting these cases. Dropping the prototypes altogether, and merely keeping the prototype-pyport-section for *real* problems, rather than warnings caused by missing declarations, would suit me fine ! > Yes, void* is ANSI. Get rid of all references to ANY. (Ages ago, > on K&R systems ANY had to defined as char *.) Okidoki. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Tue Jul 25 14:21:24 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 07:21:24 -0500 (CDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> Message-ID: <14717.34372.437370.172614@beluga.mojam.com> Peter> Okay, so where do I put that test for Python/compile.c? I suggest Lib/test/test_compile.py, with a corresponding output file in Lib/test/output/test_compile, assuming it's a test that can be written in Python. (If not, the group (or someone in it) probably needs to figure out a C-based testing framework.) I wouldn't worry that it's a lone test for the time being. It will likely gain friends as time goes on. Skip From moshez at math.huji.ac.il Tue Jul 25 14:36:34 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 15:36:34 +0300 (IDT) Subject: [Python-Dev] Features for Python 2.0 Message-ID: Earlier today (from my prespective ), Guido said that Python 2.0 is supposed to include zip(), list comprehensions, range literals and augmented assignments. In private mail, Guido said the list is open to downwards debate, so I'm opening it. Would anyone feel really bad if we postpone list comprehensions and augmented assignments to a later version? I'm a bit afraid of those features, since they are quite large, and it is yet uncertain how programs which use those features will look. (OTOH, zip will simply replace some map(None) and iterating in parallel by index, and [0:10:2] will replace range(0, 10, 2), so we have a pretty good idea about their effects) -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at beopen.com Tue Jul 25 15:43:58 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 08:43:58 -0500 Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: Your message of "Tue, 25 Jul 2000 07:57:49 -0400." <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> <200007251249.HAA19269@cj20424-a.reston1.va.home.com> <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> Message-ID: <200007251343.IAA19755@cj20424-a.reston1.va.home.com> > There are a number of smaller manuals now (doc, dist, inst). OK. Since you've offered to do this, I have no objection. > > The C style guide might as well be one of the meta-PEPs, like the > > index (maybe call it PEP 0100). > > Should it? I would expect it to be part of a single style guide or > a chapter in the Extending & Embedding manual. E&E is for writing 3rd party modules. This is for the core code. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From moshez at math.huji.ac.il Tue Jul 25 14:51:56 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 15:51:56 +0300 (IDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> Message-ID: On Tue, 25 Jul 2000, Fred L. Drake, Jr. wrote: > Should it? I would expect it to be part of a single style guide or > a chapter in the Extending & Embedding manual. Definitely not a chapter in the extending and embedding manual: the average Python extender doesn't give a hoot about what Guido thinks about C programming, even though he should -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at beopen.com Tue Jul 25 15:53:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 08:53:05 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:36:34 +0300." References: Message-ID: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> > Would anyone feel really bad if we postpone list comprehensions and > augmented assignments to a later version? I'm a bit afraid of those > features, since they are quite large, and it is yet uncertain how programs > which use those features will look. (OTOH, zip will simply replace some > map(None) and iterating in parallel by index, and [0:10:2] will replace > range(0, 10, 2), so we have a pretty good idea about their effects) If you folks hadn't wasted so much time discussion augmented print statements and new operators, we could have had the augmented assignments and list comprehensions checked in already! If you have a specific objection, raise it. Drop the meta issues. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From moshez at math.huji.ac.il Tue Jul 25 15:00:07 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 16:00:07 +0300 (IDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 25 Jul 2000, Guido van Rossum wrote: > > Would anyone feel really bad if we postpone list comprehensions and > > augmented assignments to a later version? I'm a bit afraid of those > > features, since they are quite large, and it is yet uncertain how programs > > which use those features will look. (OTOH, zip will simply replace some > > map(None) and iterating in parallel by index, and [0:10:2] will replace > > range(0, 10, 2), so we have a pretty good idea about their effects) > > If you folks hadn't wasted so much time discussion augmented print > statements and new operators, we could have had the augmented > assignments and list comprehensions checked in already! > > If you have a specific objection, raise it. Drop the meta issues. OK, here's a possible confusion point in augmented assignments: Sometimes c = a a += b assert a is c fails, and sometimes not, depending on a's type. This is just begging for trouble. Maybe it will cause massive confusion, maybe it won't. I know I'll usually be wary of using it. List comprehensions' problems is that we cannot find a syntax that we all agree is readable. Perhaps the answer is not list comprehensions, but lexical scoping combined with steroid versions of map and filter, together with zip to bind things together. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From thomas at xs4all.net Tue Jul 25 15:20:44 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 15:20:44 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 25, 2000 at 04:00:07PM +0300 References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: <20000725152044.H266@xs4all.nl> On Tue, Jul 25, 2000 at 04:00:07PM +0300, Moshe Zadka wrote: > OK, here's a possible confusion point in augmented assignments: > Sometimes > c = a > a += b > assert a is c > fails, and sometimes not, depending on a's type. This is just begging > for trouble. Maybe it will cause massive confusion, maybe it won't. I know > I'll usually be wary of using it. In my very honest opinion, that's overstating it a bit. It isn't much more confusing than the failure of c = a + b assert c is a + b for some types, but not for others. Not to mention that a + b can produce an entirely different object than b + a depending on the types. Now, how's that for confusing ! Has anyone ever seen a problem caused by that ? I haven't, and I doubt the augmented assignment is going to cause such problems. I *have* seen something like this: c = a.extend(b) Though that was a real silly mistake on the programmers part, and hasn't repeated itself. All in all, the only way we are really going to spot these pitfalls, realistic or not, is by *using* the new syntax, and letting 'newbies' use it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Tue Jul 25 16:24:08 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:24:08 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 16:00:07 +0300." References: Message-ID: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> > Sometimes > > c = a > a += b > assert a is c > > fails, and sometimes not, depending on a's type. This is just begging > for trouble. Maybe it will cause massive confusion, maybe it won't. I know > I'll usually be wary of using it. Don't worry about this. Python doesn't guarantee the semantics for 'is' independent on the type anyway. E.g.: a = b[:] assert a is b may fail or succeed depending on the type (try it with strings, tuples and lists). > List comprehensions' problems is that we cannot find a syntax that we all > agree is readable. Perhaps the answer is not list comprehensions, but > lexical scoping combined with steroid versions of map and filter, together > with zip to bind things together. I'm about 3000 messages behind in that particular discussion. I still really like Greg Ewing's original syntax: [x for x in seq] with extensions to [x+y for x in seq1 for y in seq2] [x for x in seq if pred(x)] [x, x*2 for x in seq] (General meta-comment on PEPs: these long intros explaining the problem are a detriment to finding the actual proposal. Perhaps we could have a one-paragraph explanation for the need, then a concrete proposal, then motivation and rationale and background, and then raised objections plus responses? Currently the rationale seems to be coming up front, which distracts from the proposal.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Tue Jul 25 15:28:37 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 15:28:37 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251353.IAA19818@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 08:53:05AM -0500 References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: <20000725152837.I266@xs4all.nl> On Tue, Jul 25, 2000 at 08:53:05AM -0500, Guido van Rossum wrote: > If you folks hadn't wasted so much time discussion augmented print > statements and new operators, we could have had the augmented > assignments and list comprehensions checked in already! I don't think the augmented assignment patch is ready to be checked in, though ! There are a number of crude hacks that might be solved better: the 2-argument opcodes, for instance, could posisbly be avoided by abusing the proposed 'extended_arg' opcode. And the patch re-uses the binary opcodes as augmented-assignment opcodes, merely because those #defines were already available in both ceval.c and compile.c: this would 'break' if we wanted to incorporate a new operator in augmented-assignment without adding a new 'normal' opcode for that operator. I'm still working on the PEP, really :) It's just a pretty long one, trying to explain all the intricate details and the simple elegance of the solution . Perhaps it'll inspire some discussion in the details of the patch, too. Humb-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Tue Jul 25 15:30:16 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 16:30:16 +0300 (IDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 25 Jul 2000, Guido van Rossum wrote: > > List comprehensions' problems is that we cannot find a syntax that we all > > agree is readable. Perhaps the answer is not list comprehensions, but > > lexical scoping combined with steroid versions of map and filter, together > > with zip to bind things together. > > I'm about 3000 messages behind in that particular discussion. I still > really like Greg Ewing's original syntax: > > [x for x in seq] I think the main problem with this syntax was that there is no seperator between the expression and the "for". Not a parser issue, but a human one: the same reason there is a colon after the "if" keyword. Now, [x; for x in seq] and [x: for x in seq] each had their objections. These will all probably be in the PEP, so I'll shut up now. > [x+y for x in seq1 for y in seq2] > [x for x in seq if pred(x)] > [x, x*2 for x in seq] And what about [x+y for x in seq1 for y in seq2 if y>2 if x<3] or [x+y for x in seq1 if x<3 for y in seq2 if y>2] What is allowed? Aren't we being a bit too TIMTOWTDIish here? (From there on, the discussion diverged) -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From skip at mojam.com Tue Jul 25 15:33:42 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 08:33:42 -0500 (CDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: <14717.38710.261186.468871@beluga.mojam.com> Guido> If you folks hadn't wasted so much time discussion augmented Guido> print statements and new operators, we could have had the Guido> augmented assignments and list comprehensions checked in already! I hate to play the role of Obvious Man, but I will point out that the list comprehensions patch was assigned to Guido on July 8, who promptly postponed it... ;-) Skip From jeremy at beopen.com Tue Jul 25 15:39:58 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 09:39:58 -0400 (EDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: <14717.39086.748350.672470@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> Would anyone feel really bad if we postpone list comprehensions >> and augmented assignments to a later version? I'm a bit afraid of >> those features, since they are quite large, and it is yet >> uncertain how programs which use those features will look. (OTOH, >> zip will simply replace some map(None) and iterating in parallel >> by index, and [0:10:2] will replace range(0, 10, 2), so we have a >> pretty good idea about their effects) GvR> If you folks hadn't wasted so much time discussion augmented GvR> print statements and new operators, we could have had the GvR> augmented assignments and list comprehensions checked in GvR> already! Not so fast Mr. Van Rossum! We need to get the specifications for these features written first. Barry should be updating the PEP guidelines today, and Tim and Thomas have been assigned PEPs on the two most controversial features. Yesterday, I proposed we set Aug. 9 as the deadline for completing the specs. Until we have the specs, I don't think we need to have lots of long-winded debates about whether the features scare people :-). Jeremy From thomas at xs4all.net Tue Jul 25 15:37:30 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 15:37:30 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251424.JAA19917@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 09:24:08AM -0500 References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> Message-ID: <20000725153730.J266@xs4all.nl> On Tue, Jul 25, 2000 at 09:24:08AM -0500, Guido van Rossum wrote: > (General meta-comment on PEPs: these long intros explaining the > problem are a detriment to finding the actual proposal. Perhaps we > could have a one-paragraph explanation for the need, then a concrete > proposal, then motivation and rationale and background, and then > raised objections plus responses? Currently the rationale seems to be > coming up front, which distracts from the proposal.) You can put Barry in Cardinal Fang's chair for that one ! :) He suggested to use his PEP201, Parallel Iteration, as a working example of a PEP. And PEP201 starts with a relatively long introduction of how for-loops and the current map(None, seq1, seq2) work. I've been meaning to ask people about the format, layout and style of the PEPs, but kept deferring it until after PEP-203 ;P Jeremy and Tim mentioned a Rationale section, but didn't give any clues as to what it should look like, and where and/or how it should be placed in the rest of the PEP. It's also hard to keep the PEP both concise and easy to read for those not initiated in the confusing ways of the Python ;-) Who are we writing PEPs for ? For you, Guido ? For the python-dev team as a whole ? For python-list ? For the whole of the Python community ? A collection of parts of one or more of the above ? Answer that question and the faults in all current PEPs become obvious ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From esr at thyrsus.com Tue Jul 25 02:35:55 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 20:35:55 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724201721.A9990@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Mon, Jul 24, 2000 at 08:17:21PM -0400 References: <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> Message-ID: <20000724203555.A32412@thyrsus.com> Andrew Kuchling : > Try reading the comments at the top of Modules/Setup.in. For a very > simple module that's only a file or two, like posixmodule.c or the md5 > module, you can simply add an appropriate line to Setup.in. But I > vaguely recall that the 3.x bsddb module is a bunch of files -- if > that's the case, I'm not sure what to do. Looks like just one to me, though there is some auxiliary called config.c to me that I don't understand. Here, I'll enclose the stuff; it's not large. -- Eric S. Raymond ...Virtually never are murderers the ordinary, law-abiding people against whom gun bans are aimed. Almost without exception, murderers are extreme aberrants with lifelong histories of crime, substance abuse, psychopathology, mental retardation and/or irrational violence against those around them, as well as other hazardous behavior, e.g., automobile and gun accidents." -- Don B. Kates, writing on statistical patterns in gun crime -------------- next part -------------- A non-text attachment was scrubbed... Name: py-bsddb3-2.1.0.tar.gz Type: application/octet-stream Size: 65086 bytes Desc: not available URL: From guido at beopen.com Tue Jul 25 16:40:53 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:40:53 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:28:37 +0200." <20000725152837.I266@xs4all.nl> References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> <20000725152837.I266@xs4all.nl> Message-ID: <200007251440.JAA20085@cj20424-a.reston1.va.home.com> > There are a number of crude hacks that might be solved better: the > 2-argument opcodes, for instance, could posisbly be avoided by abusing the > proposed 'extended_arg' opcode. And the patch re-uses the binary opcodes as > augmented-assignment opcodes, merely because those #defines were already > available in both ceval.c and compile.c: this would 'break' if we wanted to > incorporate a new operator in augmented-assignment without adding a new > 'normal' opcode for that operator. > > I'm still working on the PEP, really :) It's just a pretty long one, trying > to explain all the intricate details and the simple elegance of the solution > . Perhaps it'll inspire some discussion in the details of the patch, > too. Suggestion: write the VM spec first, and check that in when you're done. I bet that writing down the VM spec will clarify a lot, since it will specify the semantics (the syntax we all know). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From bwarsaw at beopen.com Tue Jul 25 15:43:05 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 09:43:05 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> <200007251249.HAA19269@cj20424-a.reston1.va.home.com> <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> <200007251343.IAA19755@cj20424-a.reston1.va.home.com> Message-ID: <14717.39273.635728.922559@anthem.concentric.net> Okay Fred, if you want to make them manuals instead of PEPs, I don't object. -Barry From moshez at math.huji.ac.il Tue Jul 25 15:43:57 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 16:43:57 +0300 (IDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <20000725152044.H266@xs4all.nl> Message-ID: On Tue, 25 Jul 2000, Thomas Wouters wrote: > All in all, the only way we are really going to spot these pitfalls, > realistic or not, is by *using* the new syntax, and letting 'newbies' use > it. Without arguing with the specifics, I'm against this attitude: what will you do if you find newbies always stumble over those issues? You can't take it out, because you're commited to backwards compatability. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From effbot at telia.com Tue Jul 25 15:52:39 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 25 Jul 2000 15:52:39 +0200 Subject: [Python-Dev] Features for Python 2.0 References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> Message-ID: <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> guido wrote: > [x for x in seq] > [x+y for x in seq1 for y in seq2] > [x for x in seq if pred(x)] > [x, x*2 for x in seq] stupid question: does the last one mean that a python parser has to stack an infinite number of tokens before it can figure out if it has a list or a list comprehension? did Python just turn into something that is much harder to parse? From guido at beopen.com Tue Jul 25 16:49:22 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:49:22 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 09:39:58 -0400." <14717.39086.748350.672470@bitdiddle.concentric.net> References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> <14717.39086.748350.672470@bitdiddle.concentric.net> Message-ID: <200007251449.JAA20159@cj20424-a.reston1.va.home.com> > Not so fast Mr. Van Rossum! We need to get the specifications for > these features written first. Barry should be updating the PEP > guidelines today, and Tim and Thomas have been assigned PEPs on the > two most controversial features. Yesterday, I proposed we set Aug. 9 > as the deadline for completing the specs. They are not controversial with *me*, and the complaints about either that were repeated today don't impress me much. The only concerns I have are: - Should we allow [x, y for x in s1 for y in s2] or should we require that to be written as [(x, y) for x in s1 for y in s2]? - What does a += b += c mean? Plus doubts about the cleanliness of the implementations given by the currently proposed patches, e.g. Thomas' doubt about the use of so many new opcodes (which I think is actually fine). > Until we have the specs, I don't think we need to have lots of > long-winded debates about whether the features scare people :-). Agreed. Besides, our priorities should be focused on the 1.6 release first. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Tue Jul 25 16:54:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:54:02 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:37:30 +0200." <20000725153730.J266@xs4all.nl> References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <20000725153730.J266@xs4all.nl> Message-ID: <200007251454.JAA20180@cj20424-a.reston1.va.home.com> > Who are we writing PEPs for ? For you, Guido ? For the python-dev team as a > whole ? For python-list ? For the whole of the Python community ? A > collection of parts of one or more of the above ? Answer that question and > the faults in all current PEPs become obvious ;) The PEPs should be written for review of proposed changes for those who are serious about language design and implementation. I consider myself an element of that set but not its only member! For this audience, exactness and conciseness of description count; "selling" the feature to the general audience is not desirable. A rationale is necessary; this should include a motivation for the feature and discussion of (reasonable) alternatives and objections that have been brougt up (if any). A PEP should also be the place to point to when someone starts rehashing an old discussion. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Tue Jul 25 15:56:43 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 15:56:43 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 25, 2000 at 04:43:57PM +0300 References: <20000725152044.H266@xs4all.nl> Message-ID: <20000725155642.K266@xs4all.nl> On Tue, Jul 25, 2000 at 04:43:57PM +0300, Moshe Zadka wrote: > On Tue, 25 Jul 2000, Thomas Wouters wrote: > > All in all, the only way we are really going to spot these pitfalls, > > realistic or not, is by *using* the new syntax, and letting 'newbies' use > > it. > Without arguing with the specifics, I'm against this attitude: what will > you do if you find newbies always stumble over those issues? You can't > take it out, because you're commited to backwards compatability. I didn't suggest we turned augmented assignment 'on' in beta phase, and removed it if it turned out too confusing. I was thinking more along the lines of the recent 'usability study' of parallel loops. Urging people to install the patch just to see how it works, and if it works how they expected. The point is we can argue all year long about how will be confusing because of , and too confusing for users of , and this too confusing if you come from language. We probably all are right, too ! But in the end we have to decide whether the new functionality is worth the extra confusion. And part of that is determining how confusing the new syntax and semantics really are, for those used to Python and those new to Python. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Tue Jul 25 16:57:35 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:57:35 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:52:39 +0200." <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> Message-ID: <200007251457.JAA20217@cj20424-a.reston1.va.home.com> > guido wrote: > > > [x for x in seq] > > [x+y for x in seq1 for y in seq2] > > [x for x in seq if pred(x)] > > [x, x*2 for x in seq] > > stupid question: does the last one mean that a python parser has > to stack an infinite number of tokens before it can figure out if it > has a list or a list comprehension? > > did Python just turn into something that is much harder to parse? This is a (minor) open issue; I'd be happy with requiring [(x, x*2) for x in seq] --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Tue Jul 25 16:59:58 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:59:58 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 16:43:57 +0300." References: Message-ID: <200007251459.JAA20243@cj20424-a.reston1.va.home.com> > > All in all, the only way we are really going to spot these pitfalls, > > realistic or not, is by *using* the new syntax, and letting 'newbies' use > > it. > > Without arguing with the specifics, I'm against this attitude: what will > you do if you find newbies always stumble over those issues? You can't > take it out, because you're commited to backwards compatability. Thomas and Moshe, stop worrying (and arguing) about this! For these two proposals that has long been resolved. What I expect from you two is suggestions on how to best implement this. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Tue Jul 25 17:01:13 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 10:01:13 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:56:43 +0200." <20000725155642.K266@xs4all.nl> References: <20000725152044.H266@xs4all.nl> <20000725155642.K266@xs4all.nl> Message-ID: <200007251501.KAA20258@cj20424-a.reston1.va.home.com> > I didn't suggest we turned augmented assignment 'on' in beta phase, and > removed it if it turned out too confusing. I was thinking more along the > lines of the recent 'usability study' of parallel loops. Urging people to > install the patch just to see how it works, and if it works how they > expected. > > The point is we can argue all year long about how will be confusing > because of , and too confusing for users of , and this > too confusing if you come from language. We probably all are right, > too ! But in the end we have to decide whether the new functionality is > worth the extra confusion. And part of that is determining how confusing the > new syntax and semantics really are, for those used to Python and those new > to Python. Oh please. Augmented assignment is about the most requested feature. Every other language that Python newbies are likely familiar with has it in exactly the same form. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Tue Jul 25 16:27:40 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 10:27:40 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: <14717.41948.876878.174423@bitdiddle.concentric.net> >>>>> "PSK" == Peter Schneider-Kamp writes: >> If you commit a patch from the SF Patch Manager or fix a bug from >> the Jitterbug database, be sure to reference the patch/bug number >> in the CVS log message. Also be sure to change the status in the >> patch manager or bug database. PSK> "Be sure to have access to the bug database." I don't think I PSK> have. If you don't have access to Jitterbug, you can send me email and I'll make the change. Jeremy From sjoerd at oratrix.nl Tue Jul 25 16:27:18 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Tue, 25 Jul 2000 16:27:18 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: Your message of Thu, 20 Jul 2000 22:13:00 +0200. <20000720221300.W9897@xs4all.nl> References: <20000720221300.W9897@xs4all.nl> Message-ID: <20000725142719.0341831047C@bireme.oratrix.nl> On Thu, Jul 20 2000 Thomas Wouters wrote: > > I just went over all of the Python source, using this little program > (which I called findkrc.py): > > import sys, string > > for file in sys.argv[1:] > d = open(file).read() > if string.find(d, ";\n{") <> -1 or string.find(d, "()\n{") <> -1: > print file > > (using find -name '*.[ch]' -print | xargs ./findkrc.py) > > And I fixed almost all of the instances of K&R C syntax. However, I found a > lot of instances of the 2nd type: empty argument list. However, as far as I > remember, ANSI C states that should be written as '(void)'. Is that a > non-issue, and should I not bother fixing those ? (Most of the files in > Modules/ has one or more instances of those.) There is a difference between a function *declaration* and a function *definition*. The former, a function declaration, tells the compiler, this is the type of the function (and its arguments). In a function declaration it is useful to make the distinction between "no arguments" and "unknown arguments". This is done by using the "void" keyword. So int foo(); means that there is a function named "foo" that returns an int and with unknown arguments. int bar(void); means that there is a function named "bar" that returns an int and that doesn't take any arguments. However in a function definition you *must* specify the arguments. So if you define a function int foo() { ... } it is clear that foo doesn't have any arguments. There is no difference with int foo(void) { ... } -- Sjoerd Mullender From effbot at telia.com Tue Jul 25 16:40:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 25 Jul 2000 16:40:48 +0200 Subject: [Python-Dev] Features for Python 2.0 References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> <200007251457.JAA20217@cj20424-a.reston1.va.home.com> Message-ID: <00b401bff646$54389080$f2a6b5d4@hagrid> guido wrote: > This is a (minor) open issue; I'd be happy with requiring > > [(x, x*2) for x in seq] doesn't really change anything, does it? the (x, x*2) could still be a value tuple or an assignment target. I'm no parser expert, but doesn't this mean that we're ruling out certain kinds of parsers? From effbot at telia.com Tue Jul 25 17:01:35 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 25 Jul 2000 17:01:35 +0200 Subject: [Python-Dev] Features for Python 2.0 References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> <200007251457.JAA20217@cj20424-a.reston1.va.home.com> <00b401bff646$54389080$f2a6b5d4@hagrid> Message-ID: <00dc01bff649$4049ff20$f2a6b5d4@hagrid> I wrote: > guido wrote: > > This is a (minor) open issue; I'd be happy with requiring > > > > [(x, x*2) for x in seq] > > doesn't really change anything, does it? the (x, x*2) could > still be a value tuple or an assignment target. umm. not sure "assignment target" was the right term here; what I'm trying to say is that you cannot tell what you're parsing until you've seen the "for" keyword. or in other words, the "n" in "when you see 'x', you have to read 'n' more tokens before you can tell what 'x' is" suddenly became much larger... (after all, I've successfully parsed Python code with a very simple non-backtracking recursive-descent parser -- and I'm not sure I can teach that one to recognize list comprehensions...) (and yes, I'm sure this can be expressed in [AELRS]+\(\d+\) notation, but I'm not gonna try ;-) From fdrake at beopen.com Tue Jul 25 16:57:25 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 10:57:25 -0400 (EDT) Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724203555.A32412@thyrsus.com> References: <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> Message-ID: <14717.43733.134803.961463@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Looks like just one to me, though there is some auxiliary called config.c > to me that I don't understand. Here, I'll enclose the stuff; it's Don't worry about config.c -- that's generated from the Setup files. As long as the right line appears in Setup.in, that's sufficient. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas at xs4all.net Tue Jul 25 17:02:15 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 17:02:15 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <20000725142719.0341831047C@bireme.oratrix.nl>; from sjoerd@oratrix.nl on Tue, Jul 25, 2000 at 04:27:18PM +0200 References: <20000720221300.W9897@xs4all.nl> <20000725142719.0341831047C@bireme.oratrix.nl> Message-ID: <20000725170215.P224@xs4all.nl> On Tue, Jul 25, 2000 at 04:27:18PM +0200, Sjoerd Mullender wrote: > On Thu, Jul 20 2000 Thomas Wouters wrote: > > for file in sys.argv[1:] > > d = open(file).read() > > if string.find(d, ";\n{") <> -1 or string.find(d, "()\n{") <> -1: > > print file > There is a difference between a function *declaration* and a function > *definition*. The script I included only finds function *definitions*, not declarations, and definitions is what I was talking about. > So if you define a function > int foo() > { > it is clear that foo doesn't have any arguments. There is no difference > with > int foo(void) > { And that was exactly what I was asking :) I know there is no difference between the two, and the question was: should I fix them anyway ? I got at least one (maybe more, I forget) affirmatives, so I fixed them. (The ones I could find, that is.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Tue Jul 25 18:12:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 11:12:05 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 17:01:35 +0200." <00dc01bff649$4049ff20$f2a6b5d4@hagrid> References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> <200007251457.JAA20217@cj20424-a.reston1.va.home.com> <00b401bff646$54389080$f2a6b5d4@hagrid> <00dc01bff649$4049ff20$f2a6b5d4@hagrid> Message-ID: <200007251612.LAA20609@cj20424-a.reston1.va.home.com> > > guido wrote: > > > This is a (minor) open issue; I'd be happy with requiring > > > > > > [(x, x*2) for x in seq] [effbot] > > doesn't really change anything, does it? the (x, x*2) could > > still be a value tuple or an assignment target. [effbot again] > umm. not sure "assignment target" was the right term here; what > I'm trying to say is that you cannot tell what you're parsing until > you've seen the "for" keyword. > > or in other words, the "n" in "when you see 'x', you have to read > 'n' more tokens before you can tell what 'x' is" suddenly became > much larger... > > (after all, I've successfully parsed Python code with a very simple > non-backtracking recursive-descent parser -- and I'm not sure I > can teach that one to recognize list comprehensions...) > > (and yes, I'm sure this can be expressed in [AELRS]+\(\d+\) > notation, but I'm not gonna try ;-) Don't worry. Greg Ewing had no problem expressing this in Python's own grammar, which is about as restricted as parsers come. (It's LL(1), which is equivalent to pure recursive descent with one lookahead token, i.e. no backtracking.) Here's Greg's grammar: atom: ... | '[' [testlist [list_iter]] ']' | ... list_iter: list_for | list_if list_for: 'for' exprlist 'in' testlist [list_iter] list_if: 'if' test [list_iter] Note that before, the list syntax was '[' [testlist] ']'. Let me explain it in different terms: The parser parses a series comma-separated expressions. Previously, it was expecting ']' as the sole possible token following this. After the change, 'for' is another possible following token. This is no problem at all for any parser that knows how to parse matching parentheses! If you'd rather not support [x, y for ...] because it's ambiguous (to the human reader, not to the parser!), we can change the grammar to something like: '[' test [',' testlist | list_iter] ']' (Note that | binds less than concatenation, and [...] means an optional part.) To merge with range literals, we'd have to go for: '[' test [':' test [':' test] | ',' testlist | list_iter ] ']' Another modification is needed to support [:x] and [:x:y], but that's a separate path through the parser entirely: atom: ... | '[' range | test [ range | ',' testlist | list_iter ] ']' | ... range: ':' test [':' test] --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jim at interet.com Tue Jul 25 17:24:54 2000 From: jim at interet.com (James C. Ahlstrom) Date: Tue, 25 Jul 2000 11:24:54 -0400 Subject: [Python-Dev] InfoWorld July 17 looks at Zope and Python Message-ID: <397DB146.C68F9CD0@interet.com> See that issue for a review of Zope. Python is mentioned in connection with Zope. JimA From akuchlin at mems-exchange.org Tue Jul 25 17:32:41 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 11:32:41 -0400 Subject: [Python-Dev] Re: Berkeley DB In-Reply-To: <20000724203555.A32412@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 24, 2000 at 08:35:55PM -0400 References: <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> Message-ID: <20000725113241.D32196@kronos.cnri.reston.va.us> On Mon, Jul 24, 2000 at 08:35:55PM -0400, Eric S. Raymond wrote: >Looks like just one to me, though there is some auxiliary called config.c >to me that I don't understand. Here, I'll enclose the stuff; it's >not large. Ah, it looks much simpler than I thought; there's one C file, so adding the C code is just a matter of dropping db_wrap.c into Modules, and adding the single line in the package's Setup.in to Modules/Setup.in. There are a bunch of *.py files, though; might it be worth creating a subpackage for BerkeleyDB in order to keep from cluttering up the library root? db_wrap.c is also an obscure name, and it would be nice to change it. --amk From gvwilson at nevex.com Tue Jul 25 17:39:48 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 25 Jul 2000 11:39:48 -0400 (EDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Message-ID: > Moshe Zadka wrote: > Would anyone feel really bad if we postpone list comprehensions and > augmented assignments to a later version? I would like augmented assignments as soon as possible. I would also like to volunteer to repeat the "simultaneous loop" syntax experiment with list comprehensions, i.e. see whether what's being proposed lines up with people's pre-existing intuitions. Greg From fdrake at beopen.com Tue Jul 25 17:40:42 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 11:40:42 -0400 (EDT) Subject: [Python-Dev] Re: Berkeley DB In-Reply-To: <20000725113241.D32196@kronos.cnri.reston.va.us> References: <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> Message-ID: <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > cluttering up the library root? db_wrap.c is also an obscure name, > and it would be nice to change it. _bsddb seems reasonable. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Tue Jul 25 18:47:18 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 11:47:18 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 11:39:48 -0400." References: Message-ID: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> > I would also like to volunteer to repeat the "simultaneous loop" syntax > experiment with list comprehensions, i.e. see whether what's being > proposed lines up with people's pre-existing intuitions. Please do! Though I have no doubt of the outcome: [x+y for x in [10, 20, 30] for y in [1, 2, 3]] will be almost universally understood to mean [11, 12, 13, 21, 22, 23, 31, 32, 33]. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Tue Jul 25 17:58:47 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 11:58:47 -0400 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: ; from gvwilson@nevex.com on Tue, Jul 25, 2000 at 11:39:48AM -0400 References: Message-ID: <20000725115847.C1785@thyrsus.com> Greg Wilson : > I would also like to volunteer to repeat the "simultaneous loop" syntax > experiment with list comprehensions, i.e. see whether what's being > proposed lines up with people's pre-existing intuitions. I think that's n excellent idea. User testing! bWhat a concept! -- Eric S. Raymond "Rightful liberty is unobstructed action, according to our will, within limits drawn around us by the equal rights of others." -- Thomas Jefferson From moshez at math.huji.ac.il Tue Jul 25 17:51:54 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 18:51:54 +0300 (IDT) Subject: [Python-Dev] Product iteration Message-ID: A large part of the problem in list comprehensions (I think) is that we need to allow more then one "for" term, so we can iterate over the product of several lists. Why not solve that the same way we solved the parallel iteration problem, by using a function, called, say, "product". Then list comprehensions can limited to be (in pseudo formal grammar): '[' expr 'for' var 'in' seq [ 'if' pred ] ']' Such that "var" can be anything that can today be in a for loop, e.g., (x, (y, z)) Then we wouldn't have the irksome problem of how for's and if's intermix: the predicate at the end can be an and'ed sequence of predicates. Reference implemntation: class _Producter: def __init__(self, lists): if not lists: raise TypeError("must receive at least one list") self.lists = lists self.lengths = map(len, lists) self.n_lists = len(lists) def __getitem__(self, i): if i<0: raise ValueError("only non-negative indices supported") ret = [None] * self.n_lists for j in range(self.n_lists): i, i_j = divmod(i, self.lengths[j]) ret[j] = self.lists[j][i_j] if i != 0: raise IndexError("not that many items") return tuple(ret) def product(*lists): return _Producter(lists) -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From esr at thyrsus.com Tue Jul 25 18:03:27 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 12:03:27 -0400 Subject: [Python-Dev] Re: Berkeley DB In-Reply-To: <14717.46330.703979.141406@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jul 25, 2000 at 11:40:42AM -0400 References: <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> Message-ID: <20000725120327.D1785@thyrsus.com> Fred L. Drake, Jr. : > > Andrew Kuchling writes: > > cluttering up the library root? db_wrap.c is also an obscure name, > > and it would be nice to change it. > > _bsddb seems reasonable. There is already a bsddbmodule.c. Can somebody explain why some module names have a leading underscore and some don't? -- Eric S. Raymond "Extremism in the defense of liberty is no vice; moderation in the pursuit of justice is no virtue." -- Barry Goldwater (actually written by Karl Hess) From esr at thyrsus.com Tue Jul 25 18:07:27 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 12:07:27 -0400 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251647.LAA20899@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 11:47:18AM -0500 References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> Message-ID: <20000725120726.F1785@thyrsus.com> Guido van Rossum : > > I would also like to volunteer to repeat the "simultaneous loop" syntax > > experiment with list comprehensions, i.e. see whether what's being > > proposed lines up with people's pre-existing intuitions. > > Please do! > > Though I have no doubt of the outcome: > > [x+y for x in [10, 20, 30] for y in [1, 2, 3]] > > will be almost universally understood to mean > > [11, 12, 13, 21, 22, 23, 31, 32, 33]. This is my expectation as well. -- Eric S. Raymond The abortion rights and gun control debates are twin aspects of a deeper question --- does an individual ever have the right to make decisions that are literally life-or-death? And if not the individual, who does? From fdrake at beopen.com Tue Jul 25 17:56:05 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 11:56:05 -0400 (EDT) Subject: [Python-Dev] Re: Berkeley DB In-Reply-To: <20000725120327.D1785@thyrsus.com> References: <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> Message-ID: <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > There is already a bsddbmodule.c. Can somebody explain why some module names > have a leading underscore and some don't? I was under the impression that db_wrap was an implementation detail for some Python code; module names with a leading underscore are not intended to be directly used by anything other than a Python wrapper module. The existing bsddb module *is* the public interface; if db_wrap is a direct replacment, it should be called bsddb instead of _bsddb. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From akuchlin at mems-exchange.org Tue Jul 25 18:03:19 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 12:03:19 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <14717.47253.118639.700872@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jul 25, 2000 at 11:56:05AM -0400 References: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> Message-ID: <20000725120319.E32196@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 11:56:05AM -0400, Fred L. Drake, Jr. wrote: >module. The existing bsddb module *is* the public interface; if >db_wrap is a direct replacment, it should be called bsddb instead of >_bsddb. It's not; in fact, db_wrap.c is SWIG-generated code while the old bsddb module was a hand-written extension. Is it OK to add a SWIG-generated module to the core? (I have an irrational dislike SWIG's trick of encoding pointers as strings, because it provides a way to deliberately engineer core dumps; it's just sort of unsettling.) --amk From bwarsaw at beopen.com Tue Jul 25 18:09:50 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 12:09:50 -0400 (EDT) Subject: [Python-Dev] Product iteration References: Message-ID: <14717.48078.888579.564219@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> A large part of the problem in list comprehensions (I think) MZ> is that we need to allow more then one "for" term, so we can MZ> iterate over the product of several lists. All this belongs in PEP 202. Can we please stop discussing it here until that PEP is done? Tim Peters owns it, so until he assigns it to someone else, I suggest that if you have an opinion on list comprehensions, send your comments to him. Let Tim collect all the comments and write the PEP. didn't-mean-to-pick-on-moshe-ly y'rs, -Barry From thomas at xs4all.net Tue Jul 25 18:18:16 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 18:18:16 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251440.JAA20085@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 09:40:53AM -0500 References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> <20000725152837.I266@xs4all.nl> <200007251440.JAA20085@cj20424-a.reston1.va.home.com> Message-ID: <20000725181815.L266@xs4all.nl> On Tue, Jul 25, 2000 at 09:40:53AM -0500, Guido van Rossum wrote: > > I'm still working on the PEP, really :) It's just a pretty long one, trying > > to explain all the intricate details and the simple elegance of the solution > > . Perhaps it'll inspire some discussion in the details of the patch, > > too. > Suggestion: write the VM spec first, and check that in when you're > done. I bet that writing down the VM spec will clarify a lot, since > it will specify the semantics (the syntax we all know). The syntax isn't a problem, the exact semantics are ;) But I'll try the reverse method of the proposal, see where it leads. It'll be a quick and short technical description to start with, though, and I'm not entirely clear on whether that should be the PEP or not ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Tue Jul 25 18:22:44 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 12:22:44 -0400 (EDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> Message-ID: <14717.48852.392171.944585@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> I would also like to volunteer to repeat the "simultaneous loop" >> syntax experiment with list comprehensions, i.e. see whether >> what's being proposed lines up with people's pre-existing >> intuitions. GvR> Please do! GvR> Though I have no doubt of the outcome: GvR> [x+y for x in [10, 20, 30] for y in [1, 2, 3]] GvR> will be almost universally understood to mean GvR> [11, 12, 13, 21, 22, 23, 31, 32, 33]. For reference, here is the what Haskell does with the same definition. Prelude> [ x+y | x <- [10, 20, 30], y <- [1, 2, 3]] [11,12,13,21,22,23,31,32,33] Jeremy PS I still find the Haskell more readable because it has some simple syntax that identifies what role each part of the expression plays. The producer is to the left of the vertical bar and each generator is identified by a "<-". From thomas at xs4all.net Tue Jul 25 18:22:55 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 18:22:55 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251449.JAA20159@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 09:49:22AM -0500 References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> <14717.39086.748350.672470@bitdiddle.concentric.net> <200007251449.JAA20159@cj20424-a.reston1.va.home.com> Message-ID: <20000725182255.M266@xs4all.nl> On Tue, Jul 25, 2000 at 09:49:22AM -0500, Guido van Rossum wrote: > - What does a += b += c mean? I don't want to start a discussion on this, but I just want to say: the current implementation considers it a syntax error, and I think that's a very reasonable thing to do. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw at beopen.com Tue Jul 25 18:25:07 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 12:25:07 -0400 (EDT) Subject: [Python-Dev] Features for Python 2.0 PEP References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <20000725153730.J266@xs4all.nl> Message-ID: <14717.48995.148454.146372@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> You can put Barry in Cardinal Fang's chair for that one ! :) TW> He suggested to use his PEP201, Parallel Iteration, as a TW> working example of a PEP. And PEP201 starts with a relatively TW> long introduction of how for-loops and the current map(None, TW> seq1, seq2) work. Yes, but as with any `first' it takes a little while to flesh things out. I'll soon have a revision that edits much of that out. PEP 1 is nearly ready so hopefully that'll answer most of the style questions. -Barry From jeremy at beopen.com Tue Jul 25 18:29:34 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 12:29:34 -0400 (EDT) Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725120319.E32196@kronos.cnri.reston.va.us> References: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> Message-ID: <14717.49262.480392.948763@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Tue, Jul 25, 2000 at 11:56:05AM -0400, Fred L. Drake, AMK> Jr. wrote: >> module. The existing bsddb module *is* the public interface; if >> db_wrap is a direct replacment, it should be called bsddb instead >> of _bsddb. AMK> It's not; in fact, db_wrap.c is SWIG-generated code while the AMK> old bsddb module was a hand-written extension. Is it OK to add AMK> a SWIG-generated module to the core? (I have an irrational AMK> dislike SWIG's trick of encoding pointers as strings, because AMK> it provides a way to deliberately engineer core dumps; it's AMK> just sort of unsettling.) Indeed! The stock SWIG produces dangerous code for pointers and inefficient code for returning multiple values. The code it produces is hard to read at least in part because it is indented incorrectly. I don't think any of these features are acceptable for a core module. I have some patches and typemaps for SWIG that do a better job, but it's still not great. If people are interested, I can post to the list. The two primary changes are to use PyCObjects for pointers and to generate better code for returning tuples. (The current code generates a return tuple incrementally; for each value, it creates a new tuple and appends it to the old return value.) Jeremy PS Andrew: The patched version of SWIG might still be installed in the depot at CNRI. You could try it out. From fdrake at beopen.com Tue Jul 25 18:29:02 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 12:29:02 -0400 (EDT) Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725120319.E32196@kronos.cnri.reston.va.us> References: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> Message-ID: <14717.49230.549418.726681@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > It's not; in fact, db_wrap.c is SWIG-generated code while the old > bsddb module was a hand-written extension. Is it OK to add a > SWIG-generated module to the core? (I have an irrational dislike > SWIG's trick of encoding pointers as strings, because it provides a > way to deliberately engineer core dumps; it's just sort of > unsettling.) You're right -- SWIG code stinks for exactly this reason. I think Jeremy did some work to avoid this, but I imagine that's no longer available (it's at CNRI). It seems to me that the right thing is to fix SWIG (probably as part of the next generation of the tool). I'm not sure what Dave's current plans are, or if there's any expectation for the schedule. I don't see anything relevant at www.swig.org, but I might be missing something obvious to SWIG users. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From akuchlin at mems-exchange.org Tue Jul 25 18:46:51 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 12:46:51 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <14717.49262.480392.948763@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 25, 2000 at 12:29:34PM -0400 References: <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> Message-ID: <20000725124651.F32196@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 12:29:34PM -0400, Jeremy Hylton wrote: >I don't think any of these features are acceptable for a core module. So what should we do WRT BerkeleyDB? The existing module in Python only really supports BSDDB 1.85. Robin Dunn's module, and the enhanced version of it by Greg someone-or-other, uses SWIG. Options I can think of: 1) Give up and do nothing 2) Try fixing SWIG. 3) Include the SWIG-generated code as it stands 4) Write a custom new BerkeleyDB extension. (In time for 2.0b1? Iffy...) I think the only solution is to do the job right and do #4, though it might wind up being postponed until Python 2.1, or whatever comes after 2.0. --amk From guido at beopen.com Tue Jul 25 19:51:39 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 12:51:39 -0500 Subject: [Python-Dev] Berkeley DB In-Reply-To: Your message of "Tue, 25 Jul 2000 12:46:51 -0400." <20000725124651.F32196@kronos.cnri.reston.va.us> References: <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> Message-ID: <200007251751.MAA21417@cj20424-a.reston1.va.home.com> > 1) Give up and do nothing > 2) Try fixing SWIG. > 3) Include the SWIG-generated code as it stands > 4) Write a custom new BerkeleyDB extension. (In time for 2.0b1? Iffy...) > > I think the only solution is to do the job right and do #4, though it > might wind up being postponed until Python 2.1, or whatever comes > after 2.0. Is the existing 3rd party BerkeleyDB broken, or just stylistically too bad for inclusion in the core? If the latter, we could remove bsddb from the core and refer to the 3rd party module -- assuming it has a website and all. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Tue Jul 25 18:55:56 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 12:55:56 -0400 (EDT) Subject: [Python-Dev] Berkeley DB In-Reply-To: <200007251751.MAA21417@cj20424-a.reston1.va.home.com> References: <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> <200007251751.MAA21417@cj20424-a.reston1.va.home.com> Message-ID: <14717.50844.387001.258809@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > Is the existing 3rd party BerkeleyDB broken, or just stylistically too > bad for inclusion in the core? If the latter, we could remove bsddb > from the core and refer to the 3rd party module -- assuming it has a > website and all. Pointing to the new extension from the documentation is certainly reasonable under any circumstance, with a note about why it may be interesting or useful as an alternate implementation. Does anyone have a URL I can use? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Tue Jul 25 18:59:55 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 25 Jul 2000 18:59:55 +0200 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> Message-ID: <397DC78B.B31FF0CE@lemburg.com> Guido van Rossum wrote: > > > I would also like to volunteer to repeat the "simultaneous loop" syntax > > experiment with list comprehensions, i.e. see whether what's being > > proposed lines up with people's pre-existing intuitions. > > Please do! > > Though I have no doubt of the outcome: > > [x+y for x in [10, 20, 30] for y in [1, 2, 3]] > > will be almost universally understood to mean > > [11, 12, 13, 21, 22, 23, 31, 32, 33]. Just a note about the syntax: why does the above have the expression and the "for" notation reversed ? Wouldn't it make much more sense to write something more lambda function like, e.g. [for (x,y) in zip([10,20,30], [1,2,3]): x+y] or [for x in range(100): x*2] ? I believe the above would cause much less confusion since it resembles standard Python "for" loop notation (making it intuitive for Python programmers) and is in syntax very similar to what "lambda" uses: lambda : List comprehension would then become something like: [for in : ] -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at mems-exchange.org Tue Jul 25 19:01:35 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 13:01:35 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <200007251751.MAA21417@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 12:51:39PM -0500 References: <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> <200007251751.MAA21417@cj20424-a.reston1.va.home.com> Message-ID: <20000725130135.G32196@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 12:51:39PM -0500, Guido van Rossum wrote: >Is the existing 3rd party BerkeleyDB broken, or just stylistically too >bad for inclusion in the core? If the latter, we could remove bsddb The latter. The existing module still works fine, particularly if you just need a DBM-like file that can also be traversed in sorted-key order, but it's not compatible with the current BerkeleyDB code. --amk From jeremy at beopen.com Tue Jul 25 19:08:30 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 13:08:30 -0400 (EDT) Subject: [Python-Dev] Makefile and dependencies Message-ID: <14717.51598.566139.423603@bitdiddle.concentric.net> The Python Makefiles do not contain enough dependency information to do incremental builds safely. If you change a .h file, none of the .c files that use it will be re-compiled unless they were also changed. This makes it a bit more tedious to test new code, because you need to do a make clean to be sure you're getting everything. I know next-to-nothing about makefiles. Is there anyone with some expertise in this area who could contribute better dependency information? Or is the lack of dependency information a conscious decision? Jeremy From guido at beopen.com Tue Jul 25 20:09:00 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 13:09:00 -0500 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: Your message of "Tue, 25 Jul 2000 13:08:30 -0400." <14717.51598.566139.423603@bitdiddle.concentric.net> References: <14717.51598.566139.423603@bitdiddle.concentric.net> Message-ID: <200007251809.NAA21636@cj20424-a.reston1.va.home.com> > The Python Makefiles do not contain enough dependency information to > do incremental builds safely. If you change a .h file, none of the .c > files that use it will be re-compiled unless they were also changed. > This makes it a bit more tedious to test new code, because you need to > do a make clean to be sure you're getting everything. > > I know next-to-nothing about makefiles. Is there anyone with some > expertise in this area who could contribute better dependency > information? Or is the lack of dependency information a conscious > decision? No, it's gradually been degraded. There's a "make depend" target that's broken beyond repair. I hope someone helps you to fix this! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From nascheme at enme.ucalgary.ca Tue Jul 25 19:29:34 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 25 Jul 2000 11:29:34 -0600 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: <200007251809.NAA21636@cj20424-a.reston1.va.home.com>; from Guido van Rossum on Tue, Jul 25, 2000 at 01:09:00PM -0500 References: <14717.51598.566139.423603@bitdiddle.concentric.net> <200007251809.NAA21636@cj20424-a.reston1.va.home.com> Message-ID: <20000725112934.A23143@keymaster.enme.ucalgary.ca> Guido, would you be interested in a non-recursive Python Makefile? I don't have a patch yet and I'm not sure it is possible to make it portable. Neil From moshez at math.huji.ac.il Tue Jul 25 19:32:43 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 20:32:43 +0300 (IDT) Subject: [Python-Dev] Makefile and dependencies In-Reply-To: <14717.51598.566139.423603@bitdiddle.concentric.net> Message-ID: On Tue, 25 Jul 2000, Jeremy Hylton wrote: > The Python Makefiles do not contain enough dependency information to > do incremental builds safely. If you change a .h file, none of the .c > files that use it will be re-compiled unless they were also changed. > This makes it a bit more tedious to test new code, because you need to > do a make clean to be sure you're getting everything. > > I know next-to-nothing about makefiles. Is there anyone with some > expertise in this area who could contribute better dependency > information? Or is the lack of dependency information a conscious > decision? Well, there could probably be an improvement, but not one that would *ensure* safe incremental builds. The fundamental problems is that it's using recursive make, which tends to have this problem. (Anyone has a URL handy for Recursive Make Considered Harmful?). In the mean time, perhaps running makedepend on the makefiles can improve the situation. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at beopen.com Tue Jul 25 20:33:38 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 13:33:38 -0500 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: Your message of "Tue, 25 Jul 2000 11:29:34 CST." <20000725112934.A23143@keymaster.enme.ucalgary.ca> References: <14717.51598.566139.423603@bitdiddle.concentric.net> <200007251809.NAA21636@cj20424-a.reston1.va.home.com> <20000725112934.A23143@keymaster.enme.ucalgary.ca> Message-ID: <200007251833.NAA21781@cj20424-a.reston1.va.home.com> > Guido, would you be interested in a non-recursive Python Makefile? I > don't have a patch yet and I'm not sure it is possible to make it > portable. Actually, the recursive version works just fine for me. It's the dependencies that aren't properly set. (Each .c file should depend on most .h files, and that info is missing from the sub-Makefiles; the toplevel Makefile just recurses into directories.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From trentm at ActiveState.com Tue Jul 25 19:37:36 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 10:37:36 -0700 Subject: C testing framework (was: Re: [Python-Dev] guidelines for contributing to Python) In-Reply-To: <14717.34372.437370.172614@beluga.mojam.com> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> <14717.34372.437370.172614@beluga.mojam.com> Message-ID: <20000725103736.B577@ActiveState.com> On Tue, Jul 25, 2000 at 07:21:24AM -0500, Skip Montanaro wrote: > > assuming it's a test that can be written in > Python. (If not, the group (or someone in it) probably needs to figure out > a C-based testing framework.) I already have a simple starter implementation for this with a couple stupid limitations. Would y'all like to see it? As well, this has been discussed a couple of times before: single email: http://www.python.org/pipermail/python-dev/2000-May/010750.html start of a later thread: http://www.python.org/pipermail/python-dev/2000-June/011622.html Show it? PEP it? Forget it? Trent -- Trent Mick TrentM at ActiveState.com From guido at beopen.com Tue Jul 25 20:42:32 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 13:42:32 -0500 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: Your message of "Tue, 25 Jul 2000 20:32:43 +0300." References: Message-ID: <200007251842.NAA21899@cj20424-a.reston1.va.home.com> > Well, there could probably be an improvement, but not one that would > *ensure* safe incremental builds. I don't believe that at all. The problem is that the submakefiles (in Parser, Objects, Python, and Modules) don't specify all dependencies on the header files in Include. If proper dependencies were added, the recursive make strategy would be totally fine. The toplevel Makefile always descends into each subdirectory to do whatever needs to be done there; there are some tricks so that the subdirectories know what to do and whether the toplevel libpython$(VERSION).a needs to be updated. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From tim_one at email.msn.com Tue Jul 25 19:50:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 13:50:47 -0400 Subject: [PEP 202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: <14717.48078.888579.564219@anthem.concentric.net> Message-ID: [Moshe] > A large part of the problem in list comprehensions (I think) > is that we need to allow more then one "for" term, so we can > iterate over the product of several lists. ... [Barry A. Warsaw] > All this belongs in PEP 202. Can we please stop discussing it here > until that PEP is done? But closed discussions are not the way to build a PEP: it's a PEP champion's job to *summarize* significant opposing viewpoints in the rationale, but there's no way to judge "significant" without intense community involvement. Vigorous open discussion is vital to any stds process. > Tim Peters owns it, so until he assigns it to someone else, I suggest > that if you have an opinion on list comprehensions, send your comments > to him. Let Tim collect all the comments and write the PEP. This is not how I want to do it. In the particular case of list comprehensions, everyone (well, everyone both conscious and sane ) is sick of the debate because it's been going on for *years*, and was almost purely repetitive long before Greg Ewing made his first patch. In this case I happen to think Moshe is trying to solve "a problem" likely nobody else sees as a problem, but I can't tell without seeing how others react to his (bizarre ) suggestion. A PEP isn't a dumping ground for every random suggestion that comes along, either -- open discussion is needed to narrow things down to the truly serious alternatives. A PEP writer's job should be more editor than arbiter: Guido is the only BDFL here! All that said, I have an enormous backlog of listcomp msgs still to plow through, and I'm going to flatly ignore any in the future unless they have PEP 202 in the Subject line (as this retitled msg has). A pep-dev mailing list is clearly a very good idea, but until one is set up I'm afraid python-dev is the only natural place to bear the unbearable (to some) pep-dev traffic. From trentm at ActiveState.com Tue Jul 25 20:00:00 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 11:00:00 -0700 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <397DC78B.B31FF0CE@lemburg.com> References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> Message-ID: <20000725110000.C577@ActiveState.com> On Tue, Jul 25, 2000 at 06:59:55PM +0200, M . -A . Lemburg wrote: > Wouldn't it make much more sense to write something > more lambda function like, e.g. > > [for (x,y) in zip([10,20,30], [1,2,3]): x+y] or [for x in [10,20,30]: for y in [1,2,3]: x+y] > > or > > [for x in range(100): x*2] > > List comprehension would then become something like: > > [for in : ] > For what it is worth, I like that. I can easily digest either though, so I think that this is a question for user testing. Trent -- Trent Mick TrentM at ActiveState.com From skip at mojam.com Tue Jul 25 20:05:24 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 13:05:24 -0500 (CDT) Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725130135.G32196@kronos.cnri.reston.va.us> References: <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> <200007251751.MAA21417@cj20424-a.reston1.va.home.com> <20000725130135.G32196@kronos.cnri.reston.va.us> Message-ID: <14717.55012.596068.67219@beluga.mojam.com> Andrew> The latter. The existing module still works fine, particularly Andrew> if you just need a DBM-like file that can also be traversed in Andrew> sorted-key order, but it's not compatible with the current Andrew> BerkeleyDB code. The only thing that's needed to use the current bsddb module interface with libdb 2.x is to include db_185.h instead of db.h. You don't get all the 2.x functionality, but you do get the less buggy libdb implementation. I've been using it like that for a couple years. Skip From bwarsaw at beopen.com Tue Jul 25 20:10:52 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 14:10:52 -0400 (EDT) Subject: [Python-Dev] Makefile and dependencies References: <14717.51598.566139.423603@bitdiddle.concentric.net> Message-ID: <14717.55340.327775.690317@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> I know next-to-nothing about makefiles. Is there anyone with JH> some expertise in this area who could contribute better JH> dependency information? Or is the lack of dependency JH> information a conscious decision? makedepend is the way to go and is probably compatible with GNU and non-GNU makes. -Barry From skip at mojam.com Tue Jul 25 20:09:58 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 13:09:58 -0500 (CDT) Subject: C testing framework (was: Re: [Python-Dev] guidelines for contributing to Python) In-Reply-To: <20000725103736.B577@ActiveState.com> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> <14717.34372.437370.172614@beluga.mojam.com> <20000725103736.B577@ActiveState.com> Message-ID: <14717.55286.1741.361478@beluga.mojam.com> [c-based testing framework] Trent> Show it? PEP it? Forget it? I say show it. I see no reason to make a PEP unless there are a number of potential immediate alternatives. It doesn't affect the functionality of the distribution, only its quality. If something better comes along later, Trent's can be replaced. Skip From jeremy at beopen.com Tue Jul 25 20:25:56 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 14:25:56 -0400 (EDT) Subject: C testing framework (was: Re: [Python-Dev] guidelines for contributing to Python) In-Reply-To: <20000725103736.B577@ActiveState.com> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> <14717.34372.437370.172614@beluga.mojam.com> <20000725103736.B577@ActiveState.com> Message-ID: <14717.56244.101761.909713@bitdiddle.concentric.net> >>>>> "TM" == Trent Mick writes: TM> single email: TM> http://www.python.org/pipermail/python-dev/2000-May/010750.html TM> start of a later thread: TM> http://www.python.org/pipermail/python-dev/2000-June/011622.html TM> Show it? PEP it? Forget it? One or more of the first two. All the feedback first time around was positive, but it was suggested too close to the purported 1.6 feature freeze deadline. Let's put it back on track for 2.0. Jeremy From effbot at telia.com Tue Jul 25 20:31:10 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 25 Jul 2000 20:31:10 +0200 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> Message-ID: <002001bff666$832b18c0$f2a6b5d4@hagrid> mal wrote: > Wouldn't it make much more sense to write something > more lambda function like, e.g. > > [for (x,y) in zip([10,20,30], [1,2,3]): x+y] > > or > > [for x in range(100): x*2] fwiw, I read that as: [ for x in range(100): x * 2 ] which makes no sense at all. From trentm at ActiveState.com Tue Jul 25 20:27:13 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 11:27:13 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs machine with >= 32bit longs Message-ID: <20000725112713.D577@ActiveState.com> I was assigned this patch a while back to try on some 64-bit systems. Fine, I can do that but I have since seen a number of message on python-dev regarding it: - Fredrik had a new, better replacement? Fredrik? - The name changed to unicodedata? MAL? - Bill, you said that the patch is no longer necessary? Anyway, can someone familiar with the patch tell me if I should check it on 64-bit systems (Win64, Linux64) and then who I should pass the patch on to? OR should I just mark it Out of Date or Rejected? Thanks, Trent -- Trent Mick TrentM at ActiveState.com From skip at mojam.com Tue Jul 25 20:41:17 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 13:41:17 -0500 (CDT) Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <002001bff666$832b18c0$f2a6b5d4@hagrid> References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> <002001bff666$832b18c0$f2a6b5d4@hagrid> Message-ID: <14717.57165.155081.532709@beluga.mojam.com> >> [for x in range(100): x*2] Fredrik> fwiw, I read that as: Fredrik> [ Fredrik> for x in range(100): Fredrik> x * 2 Fredrik> ] Fredrik> which makes no sense at all. It makes perfect sense. You read it correctly as far as I can tell. Using Greg's patch, I get what you'd expect from a simple for loop: >>> [x*2 for x in range(10)] [0, 2, 4, 6, 8, 10, 12, 14, 16, 18] It occurred to me a little bit ago to suggest that we just allow complete statements within list constructors. The semantics would be that any objects left on the stack at the end of the statements would constitute the elements of the list. Is that too weird? Skip From effbot at telia.com Tue Jul 25 20:57:16 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 25 Jul 2000 20:57:16 +0200 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com><397DC78B.B31FF0CE@lemburg.com><002001bff666$832b18c0$f2a6b5d4@hagrid> <14717.57165.155081.532709@beluga.mojam.com> Message-ID: <000c01bff66a$2a451540$f2a6b5d4@hagrid> skip wrote: > The semantics would be that any objects left on the stack > at the end of the statements would constitute the elements > of the list. Is that too weird? yes. From billtut at microsoft.com Tue Jul 25 21:08:57 2000 From: billtut at microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 12:08:57 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD329@RED-MSG-50> Well, Fredrik's changes aren't checked in yet, so checking it all in doesn't hurt. The other relevant question is since Fredrik's code will eventually get in, do we want to yank the code that generates it? (Tools/perfecthash) If we keep it, then that part of the patch should go in. If we don't keep it, that's fine too. You'd need to test it on Linux64. Win64's integer types are 32bits, and the C code doesn't use long longs. The easiest way of testing it of course is to apply the ucnhash.c patch to your tree and run test_ucn.py. :) Bill -----Original Message----- From: Trent Mick [mailto:trentm at ActiveState.com] Sent: Tuesday, July 25, 2000 11:27 AM To: Jeremy Hylton; Bill Tutt; M . -A . Lemburg; Mark Favas; Fredrik Lundh Cc: python-dev at python.org Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs machine with >= 32bit longs I was assigned this patch a while back to try on some 64-bit systems. Fine, I can do that but I have since seen a number of message on python-dev regarding it: - Fredrik had a new, better replacement? Fredrik? - The name changed to unicodedata? MAL? - Bill, you said that the patch is no longer necessary? Anyway, can someone familiar with the patch tell me if I should check it on 64-bit systems (Win64, Linux64) and then who I should pass the patch on to? OR should I just mark it Out of Date or Rejected? Thanks, Trent -- Trent Mick TrentM at ActiveState.com _______________________________________________ Python-Dev mailing list Python-Dev at python.org http://www.python.org/mailman/listinfo/python-dev From esr at thyrsus.com Tue Jul 25 21:28:32 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 15:28:32 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 25, 2000 at 06:51:54PM +0300 References: Message-ID: <20000725152832.A2019@thyrsus.com> Moshe Zadka : > > A large part of the problem in list comprehensions (I think) is that we > need to allow more then one "for" term, so we can iterate over the product > of several lists. Why not solve that the same way we solved the parallel > iteration problem, by using a function, called, say, "product". > > Then list comprehensions can limited to be (in pseudo formal grammar): > > '[' expr 'for' var 'in' seq [ 'if' pred ] ']' > > Such that "var" can be anything that can today be in a for loop, e.g., > > (x, (y, z)) > > Then we wouldn't have the irksome problem of how for's and if's intermix: > the predicate at the end can be an and'ed sequence of predicates. *KLANNGGG!!!* <-- the sound of the sacred two-by-four of enlightenment belatedly whacking Eric upside the head Dammit, I should have seen this sooner; the whole debate about parallel loops and zip() was a flare-lit clue. Gentlemen, we've been going entirely down the wrong path trying to express list comprehensions via a syntax in imperative style. What they want to be is an applicative sublanguage in functional style -- and mostly about data composition rather than the expression of iteration per se. zip() is part of this. Finding a way to handle conditionals ain't hard; in fact, it's already in the language! The right way to say [x**2 for x in range(1, 99) if isprime(x)] is like this: [x**2 for x in filter(isprime, range(1, 99)] Look at the implications: there is no longer any need for special syntax (or for python-dev debates over special syntax, or newbie confusion over special syntax) on the right side of the for. We get all the power of list comprehensions from one simple [for ... in ...] construct exactly parallel to the for ... in that Python programmers already understand. So instead of trying to fix list comprehensions with syntactic hacks, we can extend it by having a properly rich and orthogonal set of constructor functions. filter, zip, product, and lambda are good enough to cover anything the presently proposed comprehension syntax can handle. But there's a difference, because unfreezing and extending a syntax is a heckuva lot harder than inventing new functional constructors. If you notice that this looks a lot like LISP or F or Haskell, you win. These languages got comprehensions right on the basis of a lot of experience in depth. We can learn from their example. -- Eric S. Raymond An armed society is a polite society. Manners are good when one may have to back up his acts with his life. -- Robert A. Heinlein, "Beyond This Horizon", 1942 From skip at mojam.com Tue Jul 25 21:18:43 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 14:18:43 -0500 (CDT) Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <000c01bff66a$2a451540$f2a6b5d4@hagrid> References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> <002001bff666$832b18c0$f2a6b5d4@hagrid> <14717.57165.155081.532709@beluga.mojam.com> <000c01bff66a$2a451540$f2a6b5d4@hagrid> Message-ID: <14717.59411.881986.179947@beluga.mojam.com> >> The semantics would be that any objects left on the stack at the end >> of the statements would constitute the elements of the list. Is that >> too weird? Fredrik> yes. That was my initial reaction, which was why I didn't post it when I had the idea, only when I saw your interpretation... S From akuchlin at mems-exchange.org Tue Jul 25 21:37:06 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 15:37:06 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725152832.A2019@thyrsus.com>; from esr@thyrsus.com on Tue, Jul 25, 2000 at 03:28:32PM -0400 References: <20000725152832.A2019@thyrsus.com> Message-ID: <20000725153706.B11657@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 03:28:32PM -0400, Eric S. Raymond wrote: >[x**2 for x in filter(isprime, range(1, 99)] ... >filter, zip, product, and lambda are good enough to cover anything the >presently proposed comprehension syntax can handle. ... but not so elegantly, if the filter needs variables from the current scope. Consider removing all numbers in that range that are a multiple of a variable 'n'; you'd have to write: [x**2 for x in filter(lambda x, number = n: (x%n)!=0, range(1,99)) ] This uses the default argument hack to pass the value of 'n' into the scope of the lambda-created function as the parameter 'number'. Icky... I'd rather see extra syntax than more use of this kludge! --amk From skip at mojam.com Tue Jul 25 21:43:00 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 14:43:00 -0500 (CDT) Subject: [PEP 202] Re: [Python-Dev] Product iteration In-Reply-To: <20000725152832.A2019@thyrsus.com> References: <20000725152832.A2019@thyrsus.com> Message-ID: <14717.60868.260948.186346@beluga.mojam.com> Eric> Dammit, I should have seen this sooner; the whole debate about Eric> parallel loops and zip() was a flare-lit clue. Gentlemen, we've Eric> been going entirely down the wrong path trying to express list Eric> comprehensions via a syntax in imperative style. What they want Eric> to be is an applicative sublanguage in functional style -- and Eric> mostly about data composition rather than the expression of Eric> iteration per se. Part of the motivation for list comprehensions as I recall is that we'd like to get away from such a strong reliance on map, reduce and filter. Although powerful concepts, as implemented in Python they tend to be inefficient in many cases, are not powerful enough (incomplete set of functions perhaps?) for the Lispers and are too confusing for non-Lispers, especially when used in complex ways (more than two of them used in the same expression constitutes complex usage to my feeble brain). (I PEP'd the subject so Guido and Tim can find it easily.) Skip From gmcm at hypernet.com Tue Jul 25 21:56:35 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 25 Jul 2000 15:56:35 -0400 Subject: [PEP 202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: References: <14717.48078.888579.564219@anthem.concentric.net> Message-ID: <1247567499-36688181@hypernet.com> [Tim] > In this case I happen to think Moshe is trying to solve "a > problem" likely nobody else sees as a problem, but I can't tell > without seeing how others react to his (bizarre ) > suggestion. FWIW, I like the original Greg Ewing syntax best. Reason: list comprehensions are declarative, and his syntax *looks* declarative. Procedural syntax inside those [...] is wacko, just as d = { ['one'] = 1, ['two'] = 2 } would be. Also, extra punctuation is just noise. PEP202-now-closed-ly y'rs - Gordon From effbot at telia.com Tue Jul 25 23:01:18 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 25 Jul 2000 23:01:18 +0200 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com><397DC78B.B31FF0CE@lemburg.com><002001bff666$832b18c0$f2a6b5d4@hagrid><14717.57165.155081.532709@beluga.mojam.com><000c01bff66a$2a451540$f2a6b5d4@hagrid> <14717.59411.881986.179947@beluga.mojam.com> Message-ID: <002101bff67b$7fba7680$f2a6b5d4@hagrid> skip wrote: > Fredrik> yes. > > That was my initial reaction, which was why I didn't post it when I had the > idea, only when I saw your interpretation... fwiw, the syntax implemented by the patch is the best one I've seen this far. it wasn't that syntax I had in mind when I talked about list confusions... ::: however, I think I prefer [(x, x*2) for x in seq] over [x, x*2 for x in seq] (it doesn't only help me scan it, it also simplifies a piece of code that I happen to have here...) the bot says +0. From guido at beopen.com Tue Jul 25 23:59:43 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 16:59:43 -0500 Subject: [Python-Dev] patches activity In-Reply-To: Your message of "Tue, 25 Jul 2000 16:10:26 EST." <200007252110.QAA24625@server1.lfw.org> References: <200007252110.QAA24625@server1.lfw.org> Message-ID: <200007252159.QAA24008@cj20424-a.reston1.va.home.com> I take it that Ping's script to scrape patches works, and the SF folks have fixed the sending of email on changed patches. So now we get every notification twice. Ping, do you have a better address where we can send the raw email? --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From thomas at xs4all.net Tue Jul 25 23:03:23 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 23:03:23 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment Message-ID: <20000725230322.N266@xs4all.nl> No, this isn't the first full draft of the PEP :P While writing up the proposed VM changes, I came to the conclusion my patch was all wrong, and I would like some input in case I forgot something. The current patch introduces the following bytecodes: GETSET_SUBSCR GETSET_SLICE GETSET_SLICE+1 GETSET_SLICE+2 GETSET_SLICE+3 GETSET_ATTR GETSET_NAME GETSET_FAST GETSET_GLOBAL Each bytecode does the loading of the object, the actual operation it is supposed to perform, and the storing in the original place. All opcodes get an argument to specify which operation should be performed, which is also where the need for 2-argument opcodes comes from: the NAME/FAST/GLOBAL opcodes need both a name-index and an opcode argument. My excuse for this design is similar to Guido's excuse for the current Python parser: I was young, I was foolish, and I didn't know how to reuse things, only how to *add* things ;) I was also intimidated by the whole idea of a stack, having never really programmed in a low-level programming language before. I now realize only 11 new opcodes are necessary, and it can even be reduced to 1, by splitting the operation into seperate LOAD, , and STORE instructions, with a few ROT_TWO and ROT_THREE's mixed in. could be a new bytecode for each operation (11 in total) or a single 'AUGOP' bytecode with an argument to specify the operation. I think it's less elegant from the bytecode point of view, but it does require a lot less changes in ceval/compile. There is only one significant difference between the current version and this, and that's behaviour in the face of threads. I had originally seen augmented assignment as a way to increment a counter 'thread-safe': the load and store operation are done in one bytecode, and can thus not be interrupted by a thread switch. But after thinking about it, it doesn't make that much sense. It only works for builtin types, not for classes defining a __op_ab__, and possibly not for extention types. In fact, there might be some possibility for a thread switch even in builtin types, though I have never looked at that. Opinions ? Is the semi-reliability in the face of threads a good idea ? Did I miss anything important about the current implementation ? Should I forget about this idea and keep the patch as it is (and go back to my PEP) or should I rewrite the patch and then rewrite the PEP ? This alternate implementation would eradicate my next-to-last objection to including the patch, I think, but we'll discuss the last one, the naming of the __hooks__, after I finish the bloody PEP ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mwh21 at cam.ac.uk Tue Jul 25 23:12:17 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 25 Jul 2000 22:12:17 +0100 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Thomas Wouters's message of "Tue, 25 Jul 2000 23:03:23 +0200" References: <20000725230322.N266@xs4all.nl> Message-ID: Thomas Wouters writes: [opcodes for augmented assignment] > I now realize only 11 new opcodes are necessary, and it can even be reduced > to 1, by splitting the operation into seperate LOAD, , and STORE > instructions, with a few ROT_TWO and ROT_THREE's mixed in. could > be a new bytecode for each operation (11 in total) or a single 'AUGOP' > bytecode with an argument to specify the operation. Can you really do a[b:c] += d with ROT_THREE & ROT_TWO? I thought one couldn't when I was doing the first patch, but maybe I'm wrong. > I think it's less elegant from the bytecode point of view, but it does > require a lot less changes in ceval/compile. There is only one significant > difference between the current version and this, and that's behaviour in the > face of threads. And size of bytecode! > I had originally seen augmented assignment as a way to increment a counter > 'thread-safe': the load and store operation are done in one bytecode, and > can thus not be interrupted by a thread switch. But after thinking about it, > it doesn't make that much sense. It only works for builtin types, not for > classes defining a __op_ab__, and possibly not for extention types. In fact, > there might be some possibility for a thread switch even in builtin types, > though I have never looked at that. > > Opinions ? Is the semi-reliability in the face of threads a good idea ? IMHO, yes. > Did I miss anything important about the current implementation ? > Should I forget about this idea and keep the patch as it is (and go > back to my PEP) or should I rewrite the patch and then rewrite the > PEP ? For now, I'd just write the PEP. Cheers, M. -- On the other hand, the following areas are subject to boycott in reaction to the rampant impurity of design or execution, as determined after a period of study, in no particular order: ... http://www.naggum.no/profile.html From nascheme at enme.ucalgary.ca Tue Jul 25 23:13:34 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 25 Jul 2000 15:13:34 -0600 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: <200007251833.NAA21781@cj20424-a.reston1.va.home.com>; from Guido van Rossum on Tue, Jul 25, 2000 at 01:33:38PM -0500 References: <14717.51598.566139.423603@bitdiddle.concentric.net> <200007251809.NAA21636@cj20424-a.reston1.va.home.com> <20000725112934.A23143@keymaster.enme.ucalgary.ca> <200007251833.NAA21781@cj20424-a.reston1.va.home.com> Message-ID: <20000725151334.A24845@keymaster.enme.ucalgary.ca> On Tue, Jul 25, 2000 at 01:33:38PM -0500, Guido van Rossum wrote: > Actually, the recursive version works just fine for me. It's the > dependencies that aren't properly set. (Each .c file should depend on > most .h files, and that info is missing from the sub-Makefiles; the > toplevel Makefile just recurses into directories.) Isn't it a lot easier to maintain inter-directory dependencies with a non-recursive Makefile? Also, build times should be quicker. Perhaps it is not worth the effort. Neil From trentm at ActiveState.com Tue Jul 25 23:28:05 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 14:28:05 -0700 Subject: [Python-Dev] patches activity In-Reply-To: <200007252159.QAA24008@cj20424-a.reston1.va.home.com> References: <200007252110.QAA24625@server1.lfw.org> <200007252159.QAA24008@cj20424-a.reston1.va.home.com> Message-ID: <20000725142804.A7183@ActiveState.com> On Tue, Jul 25, 2000 at 04:59:43PM -0500, Guido van Rossum wrote: > I take it that Ping's script to scrape patches works, and the SF folks > have fixed the sending of email on changed patches. So now we get > every notification twice. As well, would it be possible in your processing to normalize text paragraphs to 80 columns. nit nit nit Thanks, Trent p.s. Thanks for doing this, Ping. It helps a lot. -- Trent Mick TrentM at ActiveState.com From guido at beopen.com Wed Jul 26 00:32:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 17:32:36 -0500 Subject: [Python-Dev] patches activity In-Reply-To: Your message of "Tue, 25 Jul 2000 14:28:05 MST." <20000725142804.A7183@ActiveState.com> References: <200007252110.QAA24625@server1.lfw.org> <200007252159.QAA24008@cj20424-a.reston1.va.home.com> <20000725142804.A7183@ActiveState.com> Message-ID: <200007252232.RAA24277@cj20424-a.reston1.va.home.com> > > As well, would it be possible in your processing to normalize text paragraphs > to 80 columns. nit nit nit > Code for that is in IDLE: Tools/idle/FormatParagraph.py, function reformat_paragraph(). > p.s. Thanks for doing this, Ping. It helps a lot. Yes! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From mal at lemburg.com Tue Jul 25 23:45:25 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 25 Jul 2000 23:45:25 +0200 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> <002001bff666$832b18c0$f2a6b5d4@hagrid> Message-ID: <397E0A75.6F49041E@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Wouldn't it make much more sense to write something > > more lambda function like, e.g. > > > > [for (x,y) in zip([10,20,30], [1,2,3]): x+y] > > > > or > > > > [for x in range(100): x*2] > > fwiw, I read that as: > > [ > for x in range(100): > x * 2 > ] > > which makes no sense at all. Why doesn't that make sense ? Is this just a gut feeling or explainable ? IMHO, the meaning of the differen parts is intuitively understandable from the fact that Python's standard "for" notation works in the same way. OTOH, the notation "x*2 for x in range(100)" looks strange to me and probably to others too, because it doesn't make clear what "x" really refers to until you read on... this is Python not Forth or Haskell ! BTW, is it the missing append operator (the one that pushes x*2 onto the list) that's bothering you ? Note that we could also extend the above by allowing multiple such constructs separated by commas: data = (1.3, 1.2, 1.1) l = [for x in data: 3*x, for x in data: x/10] -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Tue Jul 25 23:47:05 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 17:47:05 -0400 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <002101bff67b$7fba7680$f2a6b5d4@hagrid> Message-ID: I didn't read this because it doesn't have PEP202 in the Subject line <0.9 wink>. Nevertheless, FWIW, I prefer [(x, x*2) for x in seq] too. > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Fredrik Lundh > Sent: Tuesday, July 25, 2000 5:01 PM > To: Skip Montanaro > Cc: python-dev at python.org > Subject: Re: [Python-Dev] List comprehension syntax (Features for Python > 2.0) > > > skip wrote: > > Fredrik> yes. > > > > That was my initial reaction, which was why I didn't post it > when I had the > > idea, only when I saw your interpretation... > > fwiw, the syntax implemented by the patch is the best > one I've seen this far. it wasn't that syntax I had in mind > when I talked about list confusions... > > ::: > > however, I think I prefer > > [(x, x*2) for x in seq] > > over > > [x, x*2 for x in seq] > > (it doesn't only help me scan it, it also simplifies a piece of > code that I happen to have here...) > > the bot says +0. > > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev From esr at thyrsus.com Tue Jul 25 23:57:59 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 17:57:59 -0400 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <397DC78B.B31FF0CE@lemburg.com>; from mal@lemburg.com on Tue, Jul 25, 2000 at 06:59:55PM +0200 References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> Message-ID: <20000725175759.B2019@thyrsus.com> M.-A. Lemburg : > I believe the above would cause much less confusion since > it resembles standard Python "for" loop notation (making it > intuitive for Python programmers) and is in syntax very > similar to what "lambda" uses: > > lambda : > > List comprehension would then become something like: > > [for in : ] I agree with this proposal. It harmonizes well with the use of applicative or functional notation. -- Eric S. Raymond To make inexpensive guns impossible to get is to say that you're putting a money test on getting a gun. It's racism in its worst form. -- Roy Innis, president of the Congress of Racial Equality (CORE), 1988 From esr at thyrsus.com Tue Jul 25 23:59:37 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 17:59:37 -0400 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <14717.57165.155081.532709@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 25, 2000 at 01:41:17PM -0500 References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> <002001bff666$832b18c0$f2a6b5d4@hagrid> <14717.57165.155081.532709@beluga.mojam.com> Message-ID: <20000725175937.C2019@thyrsus.com> Skip Montanaro : > It occurred to me a little bit ago to suggest that we just allow complete > statements within list constructors. The semantics would be that any > objects left on the stack at the end of the statements would constitute the > elements of the list. Is that too weird? Not only is it non-weird, I think it is finally pushing in the right direction. -- Eric S. Raymond Rapists just *love* unarmed women. And the politicians who disarm them. From esr at thyrsus.com Wed Jul 26 00:08:18 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:08:18 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725153706.B11657@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Tue, Jul 25, 2000 at 03:37:06PM -0400 References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> Message-ID: <20000725180818.D2019@thyrsus.com> Andrew Kuchling : > On Tue, Jul 25, 2000 at 03:28:32PM -0400, Eric S. Raymond wrote: > >[x**2 for x in filter(isprime, range(1, 99)] > ... > >filter, zip, product, and lambda are good enough to cover anything the > >presently proposed comprehension syntax can handle. > > ... but not so elegantly, if the filter needs variables from the > current scope. Consider removing all numbers in that range that are a > multiple of a variable 'n'; you'd have to write: > > [x**2 for x in filter(lambda x, number = n: (x%n)!=0, range(1,99)) ] > > This uses the default argument hack to pass the value of 'n' into the > scope of the lambda-created function as the parameter 'number'. > Icky... I'd rather see extra syntax than more use of this kludge! Wrong answer. The right answer is to fix lambda (or some variant of lambda) to be a true lexical closure. -- Eric S. Raymond Question with boldness even the existence of a God; because, if there be one, he must more approve the homage of reason, than that of blindfolded fear.... Do not be frightened from this inquiry from any fear of its consequences. If it ends in the belief that there is no God, you will find incitements to virtue in the comfort and pleasantness you feel in its exercise... -- Thomas Jefferson, in a 1787 letter to his nephew From akuchlin at mems-exchange.org Wed Jul 26 00:01:16 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 18:01:16 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180818.D2019@thyrsus.com>; from esr@thyrsus.com on Tue, Jul 25, 2000 at 06:08:18PM -0400 References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> Message-ID: <20000725180116.A12239@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond wrote: >Wrong answer. The right answer is to fix lambda (or some variant of lambda) >to be a true lexical closure. Hm... hmmmm... fixing this has been suggested before, but always foundered on the fact that creating a closure required a cycle, which would leak memory. Now we have an optional GC that should handle this, so maybe fixing it can be revisited. (But this would mean that GC is essentially no longer optional -- maybe too radical a thing to do before we're sure about the new GC. 2.1, maybe?) --amk From esr at thyrsus.com Wed Jul 26 00:14:22 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:14:22 -0400 Subject: [PEP 202] Re: [Python-Dev] Product iteration In-Reply-To: <14717.60868.260948.186346@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 25, 2000 at 02:43:00PM -0500 References: <20000725152832.A2019@thyrsus.com> <14717.60868.260948.186346@beluga.mojam.com> Message-ID: <20000725181422.E2019@thyrsus.com> Skip Montanaro : > Part of the motivation for list comprehensions as I recall is that we'd like > to get away from such a strong reliance on map, reduce and filter. In that case, the the lesson is that this is a bad road to go down. The cost of moving away from a functional syntax, in this case, seems to be dubious thickets of syntactic ugliness, Mind you, I'm not a functional-language bigot; I'm not after turning Python into LISP. Python has taught me the limits of the LISP approach to the world. But I think the lesson from this particular debate is that it's not really possible to do better than functional syntax for expressing the kinds of things that want to go on the right side of a comprehension. -- Eric S. Raymond Live free or die; death is not the worst of evils. -- General George Stark. From tim_one at email.msn.com Wed Jul 26 00:08:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 18:08:47 -0400 Subject: [PEP202 listcomps] (was RE: [Python-Dev] List comprehension syntax (Features for Python 2.0)) In-Reply-To: <397E0A75.6F49041E@lemburg.com> Message-ID: [MAL, on /F's complaints about [for x in range(100): x*2] ] > ... > IMHO, the meaning of the differen parts is intuitively > understandable from the fact that Python's standard "for" > notation works in the same way. > > OTOH, the notation "x*2 for x in range(100)" looks strange to me > and probably to others too, because it doesn't make clear what "x" > really refers to until you read on... this is Python not Forth or > Haskell ! The feature is taken from Haskell, which in turn adapted it from SETL. Both follow the long-established ordering of mathematical set-builder notation, where the *expression* is leftmost. It's the expression that's important, not the incidental details of the iterators -- there's more than a century of user experience behind that <0.6 wink>. I'll note that everything "looks strange" the first time you see it. It's more important that it feels right after you grasp it. That's the case here! When I see [x**2 for x in range(100)] I (being a left-to-right reader) immediately grasp "ah, it's a list of squares". Write it [for x in range(100): x*2] and it's simply harder to grasp (indeed, *that* "looks strange" to me -- it looks like somebody started to write a "for" loop and made a typo). In any case, this particular point was debated to death more than a year ago, and Guido already Pronounced on it. > ... > Note that we could also extend the above by allowing multiple > such constructs separated by commas: > > data = (1.3, 1.2, 1.1) > l = [for x in data: 3*x, > for x in data: x/10] Sure, and we could write u[...] for Unicode lists too . I see no advantage in the above over the simpler construct, i.e. l = [3*x for x in data] + [x/10 for x in data] except that it may be easier for a dirt-dumb implementation to optimize the former. From jeremy at beopen.com Wed Jul 26 00:15:31 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 18:15:31 -0400 (EDT) Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us> References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: <14718.4483.735535.296724@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond AMK> wrote: >> Wrong answer. The right answer is to fix lambda (or some variant >> of lambda) to be a true lexical closure. AMK> Hm... hmmmm... fixing this has been suggested before, but AMK> always foundered on the fact that creating a closure required a AMK> cycle, which would leak memory. Now we have an optional GC AMK> that should handle this, so maybe fixing it can be revisited. AMK> (But this would mean that GC is essentially no longer optional AMK> -- maybe too radical a thing to do before we're sure about the AMK> new GC. 2.1, maybe?) I was thinking this would be a post 2.0 PEP. Jeremy From esr at thyrsus.com Wed Jul 26 00:26:28 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:26:28 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Tue, Jul 25, 2000 at 06:01:16PM -0400 References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: <20000725182628.H2019@thyrsus.com> Andrew Kuchling : > On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond wrote: > >Wrong answer. The right answer is to fix lambda (or some variant of lambda) > >to be a true lexical closure. > > Hm... hmmmm... fixing this has been suggested before, but always > foundered on the fact that creating a closure required a cycle, which > would leak memory. Now we have an optional GC that should handle > this, so maybe fixing it can be revisited. (But this would mean that > GC is essentially no longer optional -- maybe too radical a thing to > do before we're sure about the new GC. 2.1, maybe?) I think there's enough controversy about comprehensions at this point to warrant not rushing out an implementation we might regret. (Heh. Look at me telling *Guido* to go slow and careful...heh.) -- Eric S. Raymond To make inexpensive guns impossible to get is to say that you're putting a money test on getting a gun. It's racism in its worst form. -- Roy Innis, president of the Congress of Racial Equality (CORE), 1988 From mwh21 at cam.ac.uk Wed Jul 26 00:19:05 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 25 Jul 2000 23:19:05 +0100 Subject: [Python-Dev] Product iteration In-Reply-To: "Eric S. Raymond"'s message of "Tue, 25 Jul 2000 18:08:18 -0400" References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> Message-ID: "Eric S. Raymond" writes: > Wrong answer. The right answer is to fix lambda (or some variant of > lambda) to be a true lexical closure. And presumably local functions too? Otherwise that's also the wrong answer... Cheers, M. -- 40. There are two ways to write error-free programs; only the third one works. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html From esr at thyrsus.com Wed Jul 26 00:33:18 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:33:18 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <14717.55012.596068.67219@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 25, 2000 at 01:05:24PM -0500 References: <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> <200007251751.MAA21417@cj20424-a.reston1.va.home.com> <20000725130135.G32196@kronos.cnri.reston.va.us> <14717.55012.596068.67219@beluga.mojam.com> Message-ID: <20000725183318.I2019@thyrsus.com> Skip Montanaro : > The only thing that's needed to use the current bsddb module interface with > libdb 2.x is to include db_185.h instead of db.h. You don't get all the 2.x > functionality, but you do get the less buggy libdb implementation. I've > been using it like that for a couple years. It shouldn't be difficult to write a configure test to autoconfigure this. But I think a previous poster was right to suggest writing a custom interface for the 3.x code instead. -- Eric S. Raymond "Rightful liberty is unobstructed action, according to our will, within limits drawn around us by the equal rights of others." -- Thomas Jefferson From esr at thyrsus.com Wed Jul 26 00:35:22 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:35:22 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725124651.F32196@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Tue, Jul 25, 2000 at 12:46:51PM -0400 References: <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> Message-ID: <20000725183522.J2019@thyrsus.com> Andrew Kuchling : > I think the only solution is to do the job right and do #4, though it > might wind up being postponed until Python 2.1, or whatever comes > after 2.0. I'm inclined to agree...sadly, I don't yet have the chops to do this myself. -- Eric S. Raymond The right to buy weapons is the right to be free. -- A.E. Van Vogt, "The Weapon Shops Of Isher", ASF December 1942 From trentm at ActiveState.com Wed Jul 26 00:39:12 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 15:39:12 -0700 Subject: [Python-Dev] Summary or failing regression tests... Message-ID: <20000725153912.A21409@ActiveState.com> Here is a list of the regrtests that are currently failing for me on Linux32 and Win32. Is anybody looking at test_mmap, test_userstring, test_winreg, and test_winreg2? Skip, You and Jeremy(?) were talking about test_posixpath on Linux. It looks like the sames errors you were talking about occur on Win32. I didn't look too closely, can you? Fredrik, are you aware of the test_sre failure on Win32? Am I doing something wrong to be getting this? On Linux32: - test_fork1 This fails/hangs/crashes inconsistently because (some little bird told me) the fork stuff and threads are incompatible. Am I right? Now that we are turning threads on by default what is the proper thing to do here? SHould test_fork1 be changed to skip if threads are enabled? On Win32: - test_mmap one liner: test test_mmap crashed -- exceptions.WindowsError : [Errno 6] The handle is invalid full output: Position of foo: 1.0 pages Length of file: 2.0 pages Contents of byte 0: '\000' Contents of first 3 bytes: '\000\000\000' Modifying file's content... Contents of byte 0: '3' Contents of first 3 bytes: '3\000\000' Contents of second page: foobar Regex match on mmap (page start, length of match): 1.0 6 Seek to zeroth byte Seek to 42nd byte Seek to last byte Try to seek to negative position... Try to seek beyond end of mmap... Try to seek to negative position... Attempting resize() Traceback (most recent call last): File "..\Lib\test\test_mmap.py", line 114, in ? test_both() File "..\Lib\test\test_mmap.py", line 100, in test_both m.resize( 512 ) WindowsError: [Errno 6] The handle is invalid - test_posixpath one liner: test test_posixpath failed -- Writing: 'error!', expected: 'No err' full output: error! evaluated: posixpath.commonprefix(["/home/swenson/spam", "/home/swen/spam"]) should be: /home returned: /home/swen error! evaluated: posixpath.commonprefix(["/home/swen/spam", "/home/swen/eggs"]) should be: /home/swen returned: /home/swen/ 2 errors. - test_re one liner: test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou" full output: Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Traceback (most recent call last): File "..\Lib\test\test_re.py", line 122, in ? raise TestFailed, "symbolic reference" test_support.TestFailed: symbolic reference discussion: This has been discussed a litle by Mark Favas and Jeremy with no conclusion. http://www.python.org/pipermail/python-dev/2000-July/013963.html - test_sre one liner: test test_sre failed -- Writing: '=== Failed incorrectly', expected: "===grouping error ('(" full output: Running tests on sre.search and sre.match Running tests on sre.sub Running tests on symbolic references Traceback (most recent call last): File "..\Lib\test\test_sre.py", line 124, in ? raise TestFailed, "symbolic reference" test_support.TestFailed: symbolic reference discussion: This has been discussed a litle by Mark Favas and Jeremy with no conclusion http://www.python.org/pipermail/python-dev/2000-July/013963.html - test_userstring one liner: test test_userstring failed -- Writing: "'a'", expected: '' full output: 'a' <> 'A' <> '\012' <> 'abc' <> 'aBc123' <> 'abc\012' <> 'a' <> 'A' <> '\012' <> '123abc456' <> 'a1b3c' <> 'aBc000 ' <> 'abc\012' <> - test_winreg one liner: test test_winreg failed -- Unread: '\012' full output: (this works when run standalone) - test_winreg2 (crashes) full output: Fatal Python error: PyThreadState_Get: no current thread abnormal program termination Thanks, Trent -- Trent Mick TrentM at ActiveState.com From nowonder at pool.informatik.rwth-aachen.de Wed Jul 26 02:47:21 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Wed, 26 Jul 2000 00:47:21 +0000 Subject: [Python-Dev] Summary or failing regression tests... References: <20000725153912.A21409@ActiveState.com> Message-ID: <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> Trent Mick wrote: > > On Linux32: > - test_fork1 > This fails/hangs/crashes inconsistently because (some little bird told me) > the fork stuff and threads are incompatible. Am I right? Now that we are > turning threads on by default what is the proper thing to do here? SHould > test_fork1 be changed to skip if threads are enabled? That works fine to me (--with-threads). Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From effbot at telia.com Wed Jul 26 00:55:27 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 00:55:27 +0200 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs machine with >= 32bit longs References: <20000725112713.D577@ActiveState.com> Message-ID: <004801bff68b$6e364280$f2a6b5d4@hagrid> trent wrote: > I was assigned this patch a while back to try on some 64-bit systems. Fine, I > can do that but I have since seen a number of message on python-dev regarding > it: > > - Fredrik had a new, better replacement? Fredrik? my patch is here: http://w1.132.telia.com/~u13208596/uninames-patch.txt (it's ~600k, which is more than sourceforge can handle) if you have some time to spare, feel tree to try it out on your favourite 64-bit platform (I haven't had time to test it on our alphas, but I'm pretty sure it'll work). the patch doesn't update the build files, so you need to do some manual tweaking to make sure the unicodenames module is built. if everything works as it should, the resulting interpreter should survive test_ucn.py even if ucnhash.pyd (.so) is nowhere to be seen... From effbot at telia.com Wed Jul 26 01:00:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 01:00:58 +0200 Subject: [Python-Dev] Summary or failing regression tests... References: <20000725153912.A21409@ActiveState.com> Message-ID: <005601bff68c$340d3b80$f2a6b5d4@hagrid> trent wrote: > Fredrik, are you aware of the test_sre failure on Win32? Am I doing something > wrong to be getting this? > Traceback (most recent call last): > File "..\Lib\test\test_sre.py", line 124, in ? > raise TestFailed, "symbolic reference" > test_support.TestFailed: symbolic reference hmm. *I* don't get that error (Win32, MSVC 5.0). If everything works as it should, test_re and test_sre should produce what's in output/test_s?re does anyone else see this error on Linux? From trentm at activestate.com Wed Jul 26 00:55:00 2000 From: trentm at activestate.com ('Trent Mick') Date: Tue, 25 Jul 2000 15:55:00 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD329@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD329@RED-MSG-50> Message-ID: <20000725155500.B21409@ActiveState.com> On Tue, Jul 25, 2000 at 12:08:57PM -0700, Bill Tutt wrote: > Well, Fredrik's changes aren't checked in yet, so checking it all in doesn't > hurt. > > The other relevant question is since Fredrik's code will eventually get in, > do we want to yank the code that generates it? > (Tools/perfecthash) If we keep it, then that part of the patch should go in. > If we don't keep it, that's fine too. > > You'd need to test it on Linux64. Win64's integer types are 32bits, and the > C code doesn't use long longs. > The easiest way of testing it of course is to apply the ucnhash.c patch to > your tree and run test_ucn.py. :) Okay. I tried it and with the patch test_ucn.py passes fine. I am going to add a comment to the patch on SourceForge and then assigned it back to.... hmmmm... eenie meenie minie... Bill! Is that alright? Trent -- Trent Mick TrentM at ActiveState.com From billtut at microsoft.com Wed Jul 26 00:53:22 2000 From: billtut at microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 15:53:22 -0700 Subject: [PEP 202] Re: [Python-Dev] Product iteration Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32C@RED-MSG-50> > From: Eric S. Raymond [mailto:esr at thyrsus.com] > Skip Montanaro : > > Part of the motivation for list comprehensions as I recall is that we'd like > > to get away from such a strong reliance on map, reduce and filter. > In that case, the the lesson is that this is a bad road to go down. > The cost of moving away from a functional syntax, in this case, seems > to be dubious thickets of syntactic ugliness, > Mind you, I'm not a functional-language bigot; I'm not after turning Python > into LISP. Python has taught me the limits of the LISP approach to the world. > But I think the lesson from this particular debate is that it's not really > possible to do better than functional syntax for expressing the kinds of things > that want to go on the right side of a comprehension. Amen. I personally liked the Haskell syntax Jeremy posted earlier. It just makes sense visually. Bill From nascheme at enme.ucalgary.ca Wed Jul 26 00:57:28 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 25 Jul 2000 16:57:28 -0600 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us>; from Andrew Kuchling on Tue, Jul 25, 2000 at 06:01:16PM -0400 References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: <20000725165728.A25611@keymaster.enme.ucalgary.ca> On Tue, Jul 25, 2000 at 06:01:16PM -0400, Andrew Kuchling wrote: > On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond wrote: > >Wrong answer. The right answer is to fix lambda (or some variant of lambda) > >to be a true lexical closure. > > Hm... hmmmm... fixing this has been suggested before, but always > foundered on the fact that creating a closure required a cycle, which > would leak memory. Now we have an optional GC that should handle > this, so maybe fixing it can be revisited. (But this would mean that > GC is essentially no longer optional -- maybe too radical a thing to > do before we're sure about the new GC. 2.1, maybe?) I would like to get the memory consumption down before making GC standard. Hopefully Vladimir and I can team up to accomplish this. still-waiting-for-my-home-machine-ly Neil From tim_one at email.msn.com Wed Jul 26 00:57:44 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 18:57:44 -0400 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: <20000725152832.A2019@thyrsus.com> Message-ID: [Eric S. Raymond] > ... > The right way to say > > [x**2 for x in range(1, 99) if isprime(x)] > > is like this: > > [x**2 for x in filter(isprime, range(1, 99)] > ... > If you notice that this looks a lot like LISP or F or Haskell, you win. Win some, lose some: the original looks much more like Haskell, from which Greg Ewing borrowed list comprehensions: [x**2, x <- [1..98], isprime(x)] (Note: that's from memory, as I don't have Haskell on my laptop; while a detail may be wrong (in particular, I don't recall how Haskell spells "square"), the thrust is not: Haskell allows an arbitrary sequence of iterators and predicates, exactly as does the proposal. It's formally defined in terms of expansion to masses of lambdas and applications, but the whole point to the Haskell spelling is to raise the expressiveness above the LISP level] > These languages got comprehensions right on the basis of a lot of > experience in depth. We can learn from their example. Indeed, we're trying to . This is much more a Haskell than a LISP feature, and follows Haskell in using special syntax to relieve the monotony of relentlessly uniform function composition. It derives in turn from SETL, which followed common set-theoretic notation. This "grabbed" Guido; LISP spellings never did, and I bet never will. Indeed, your latter spelling is so close to the current map(lambda x: x**2, filter(isprime, range(1, 99)) as to make little difference. From trentm at activestate.com Wed Jul 26 01:02:59 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 25 Jul 2000 16:02:59 -0700 Subject: [Python-Dev] Summary or failing regression tests... In-Reply-To: <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> Message-ID: <20000725160259.C21409@ActiveState.com> On Wed, Jul 26, 2000 at 12:47:21AM +0000, Peter Schneider-Kamp wrote: > Trent Mick wrote: > > > > On Linux32: > > - test_fork1 > > This fails/hangs/crashes inconsistently because (some little bird told me) > > the fork stuff and threads are incompatible. Am I right? Now that we are > > turning threads on by default what is the proper thing to do here? SHould > > test_fork1 be changed to skip if threads are enabled? > > That works fine to me (--with-threads). > 'test_fork1' works for me when run as: ./python Lib/test/regrtest.py but hangs when run as: ./python Lib/test/test_fork1.py or ./python Lib/test/regrtest.py test_fork1 I don't know why? Trent -- Trent Mick TrentM at ActiveState.com From tim_one at email.msn.com Wed Jul 26 01:03:59 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 19:03:59 -0400 Subject: Closures (was RE: [Python-Dev] Product iteration) In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > Hm... hmmmm... fixing this has been suggested before, but always > foundered on the fact that creating a closure required a cycle, which > would leak memory. Now we have an optional GC that should handle > this, so maybe fixing it can be revisited. (But this would mean that > GC is essentially no longer optional -- maybe too radical a thing to > do before we're sure about the new GC. 2.1, maybe?) Definitely PEP material: let's please, please, please not have this entire debate again. BTW, I'm having trouble believing the release schedule for 1.6 and 2.0 without this, so definitely post-2.0 on those grounds alone. From billtut at microsoft.com Wed Jul 26 01:03:00 2000 From: billtut at microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 16:03:00 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> Well, I can't check it in, so assigning it back to me would be fairly pointless. Someone should also chime in on the Tools/perfecthash stuff as well. If we want to keep it, I'll see if I can come up with an example using Python's tokens since the data set is way smaller. :) Bill -----Original Message----- From: 'Trent Mick' [mailto:trentm at activestate.com] Sent: Tuesday, July 25, 2000 3:55 PM To: Bill Tutt Cc: Jeremy Hylton; M . -A . Lemburg; Mark Favas; Fredrik Lundh; python-dev at python.org Subject: Re: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs On Tue, Jul 25, 2000 at 12:08:57PM -0700, Bill Tutt wrote: > Well, Fredrik's changes aren't checked in yet, so checking it all in doesn't > hurt. > > The other relevant question is since Fredrik's code will eventually get in, > do we want to yank the code that generates it? > (Tools/perfecthash) If we keep it, then that part of the patch should go in. > If we don't keep it, that's fine too. > > You'd need to test it on Linux64. Win64's integer types are 32bits, and the > C code doesn't use long longs. > The easiest way of testing it of course is to apply the ucnhash.c patch to > your tree and run test_ucn.py. :) Okay. I tried it and with the patch test_ucn.py passes fine. I am going to add a comment to the patch on SourceForge and then assigned it back to.... hmmmm... eenie meenie minie... Bill! Is that alright? Trent -- Trent Mick TrentM at ActiveState.com From trentm at activestate.com Wed Jul 26 01:06:37 2000 From: trentm at activestate.com ('Trent Mick') Date: Tue, 25 Jul 2000 16:06:37 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> Message-ID: <20000725160637.A21687@ActiveState.com> On Tue, Jul 25, 2000 at 04:03:00PM -0700, Bill Tutt wrote: > Well, I can't check it in, so assigning it back to me would be fairly > pointless. Very sneaky. I defaulted to Jeremy. Trent -- Trent Mick TrentM at ActiveState.com From guido at beopen.com Wed Jul 26 02:12:23 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 19:12:23 -0500 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs In-Reply-To: Your message of "Tue, 25 Jul 2000 16:03:00 MST." <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> Message-ID: <200007260012.TAA31561@cj20424-a.reston1.va.home.com> > Well, I can't check it in, so assigning it back to me would be fairly > pointless. Someone should also chime in on the Tools/perfecthash stuff as > well. If we want to keep it, I'll see if I can come up with an example > using Python's tokens since the data set is way smaller. :) I've learned from the sad NumPy experience that it's really bad to generate code and then throw away the generator and start editing the generated code... So please keep the generator up-to-date! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From bwarsaw at beopen.com Wed Jul 26 01:13:56 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 19:13:56 -0400 (EDT) Subject: [PEP202 listcomps] (was RE: [Python-Dev] List comprehension syntax (Features for Python 2.0)) References: <397E0A75.6F49041E@lemburg.com> Message-ID: <14718.7988.542661.35195@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> I'll note that everything "looks strange" the first time you TP> see it. It's more important that it feels right after you TP> grasp it. It's the "Pink Floyd" syndrome. A new band of mine is searching for a name, and all of them seem dumb the first time you say them. 35 years and tens of millions of records later, and even "Pink Floyd" seems like a brilliant name for a band. hoping-to-have-the-same-problem-ly y'rs, -Barry From mhammond at skippinet.com.au Wed Jul 26 01:12:03 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 26 Jul 2000 09:12:03 +1000 Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725120319.E32196@kronos.cnri.reston.va.us> Message-ID: > Is it OK to add a SWIG-generated module to the core? That is a little tricky. Longer term it should be reasonable. However, there are a few reasonable objections that I will have trouble defending (the most obvious one being a more complex build system) > (I have an irrational dislike SWIG's trick of encoding pointers > as strings, I think your fear is completely rational! However, take heart in the fact that I have _many_ SWIG extension modules, and have _never_ had SWIG generate a pointer on me. It often takes some hoop jumping, and requires some hand-coded helpers, but SWIG still saves me time, while providing a rock-solid interface. If SWIG code does end up in the core, I would prefer to see SWIG pointers banned! Mark. From effbot at telia.com Wed Jul 26 01:21:14 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 01:21:14 +0200 Subject: [Python-Dev] Re: Summary or failing regression tests... References: <20000725153912.A21409@ActiveState.com> Message-ID: <007601bff68f$0871dfa0$f2a6b5d4@hagrid> as for your other errors (still on Win95, MSVC 5.0): > - test_mmap > one liner: > test test_mmap crashed -- exceptions.WindowsError : [Errno 6] The handle is invalid same here (but a different error code?) > - test_posixpath > one liner: > test test_posixpath failed -- Writing: 'error!', expected: 'No err' nope. > - test_re > one liner: > test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou" nope. but are you sure you've updated the output directory lately? the "=== Failed incorrectly" part is expected, the abc stuff is not. > Traceback (most recent call last): > File "..\Lib\test\test_re.py", line 122, in ? > raise TestFailed, "symbolic reference" > test_support.TestFailed: symbolic reference nope. > - test_sre > one liner: > test test_sre failed -- Writing: '=== Failed incorrectly', expected: "===grouping error ('(" nope. but again, the expected stuff looks wrong. > Traceback (most recent call last): > File "..\Lib\test\test_sre.py", line 124, in ? > raise TestFailed, "symbolic reference" > test_support.TestFailed: symbolic reference nope. > - test_userstring > one liner: > test test_userstring failed -- Writing: "'a'", expected: '' nope -- but the output indicates that you're testing against an old copy of UserString.py > > - test_winreg > one liner: > test test_winreg failed -- Unread: '\012' nope. > - test_winreg2 (crashes) > full output: > Fatal Python error: PyThreadState_Get: no current thread > > abnormal program termination almost. I got other interesting errors when I had an old winreg.pyd in the path. if I remove that one, the test runs, prints HKEY_CLASSES_ROOT, and then starts consuming 99.99% CPU (not sure if it terminates; I need my cycles for more important stuff...) From billtut at microsoft.com Wed Jul 26 01:14:03 2000 From: billtut at microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 16:14:03 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> The patch for the generator is up to date. The question is "Should we keep Tools/perfecthash in CVS after Fredrick checks in his new unicode name support?" Bill -----Original Message----- From: Guido van Rossum [mailto:guido at beopen.com] Sent: Tuesday, July 25, 2000 5:12 PM To: Bill Tutt Cc: python-dev at python.org Subject: Re: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs > Well, I can't check it in, so assigning it back to me would be fairly > pointless. Someone should also chime in on the Tools/perfecthash stuff as > well. If we want to keep it, I'll see if I can come up with an example > using Python's tokens since the data set is way smaller. :) I've learned from the sad NumPy experience that it's really bad to generate code and then throw away the generator and start editing the generated code... So please keep the generator up-to-date! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Wed Jul 26 02:19:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 19:19:05 -0500 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: Your message of "Tue, 25 Jul 2000 18:57:44 -0400." References: Message-ID: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> > It derives in turn from SETL, which followed common set-theoretic > notation. This "grabbed" Guido; LISP spellings never did, and I bet > never will. I've never used or even seen SETL, but there is a connection: SETL had a profound influence on the designers of ABC, in particular Lambert Meertens, who spent a sabbatical year working with the folks at New York University who wrote the first validated Ada compiler in SETL. (http://www.faqs.org/faqs/computer-lang/Ada/comp-lang-ada/part2/ question 4.2.2, to save you the Google search.) I happen to have a standing invitation to come give a talk there... Since I'm posting in this thread anyway, I am with Tim -- I like Greg Ewing's proposed syntax best, for the reasons Tim stated. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Wed Jul 26 02:23:12 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 19:23:12 -0500 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs In-Reply-To: Your message of "Tue, 25 Jul 2000 16:14:03 MST." <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> Message-ID: <200007260023.TAA31667@cj20424-a.reston1.va.home.com> > The patch for the generator is up to date. The question is "Should we keep > Tools/perfecthash in CVS after Fredrick checks in his new unicode name > support?" Oh, never mind. I'd say keep it around -- it's a cool thing for which eventually someone will find a use! (But it should really be up to Andrew -- if he prefers to have it on his webpage instead, we should honor that.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From effbot at telia.com Wed Jul 26 01:27:17 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 01:27:17 +0200 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> <200007260012.TAA31561@cj20424-a.reston1.va.home.com> Message-ID: <009101bff691$d9b3e700$f2a6b5d4@hagrid> guido wrote: > > Well, I can't check it in, so assigning it back to me would be fairly > > pointless. Someone should also chime in on the Tools/perfecthash stuff as > > well. If we want to keep it, I'll see if I can come up with an example > > using Python's tokens since the data set is way smaller. :) > > I've learned from the sad NumPy experience that it's really bad to > generate code and then throw away the generator and start editing the > generated code... So please keep the generator up-to-date! note that if #100899 goes in instead, Bill's tweak of Andrew's original code won't be needed for anything related to unicode. the perfect hash module is still a useful tool (not that I ever got it to do a decent job on the unicode database. Bill's either very lucky, or he's got a really fast computer... ;-) From akuchlin at cnri.reston.va.us Wed Jul 26 01:58:28 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 25 Jul 2000 19:58:28 -0400 Subject: [Python-Dev] is this obsolete? In-Reply-To: <200007260023.TAA31667@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 07:23:12PM -0500 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> <200007260023.TAA31667@cj20424-a.reston1.va.home.com> Message-ID: <20000725195828.A19959@newcnri.cnri.reston.va.us> On Tue, Jul 25, 2000 at 07:23:12PM -0500, Guido van Rossum wrote: >Oh, never mind. I'd say keep it around -- it's a cool thing for which >eventually someone will find a use! (But it should really be up to >Andrew -- if he prefers to have it on his webpage instead, we should >honor that.) It seems too esoteric to take up space in the Tools/ directory, so I'd suggest taking it out. I'll look at Bill's changes and grab interesting bits for my copy, though. --amk From effbot at telia.com Wed Jul 26 02:09:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 02:09:48 +0200 Subject: [Python-Dev] decoding errors when comparing strings Message-ID: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> (revisiting an old thread on mixed string comparisions) summary: the current interpreter throws an "ASCII decoding error" exception if you compare 8-bit and unicode strings, and the 8-bit string happen to contain a character in the 128-255 range. this is not only confusing for users, it also confuses the hell out of Python itself. for example: >>> a = u"?" >>> b = "?" >>> hash(a) -283818363 >>> hash(b) -283818363 >>> a == b Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII decoding error: ordinal not in range(128) >>> d = {} >>> d[a] = "a" >>> d[b] = "b" >>> len(d) UnicodeError: ASCII decoding error: ordinal not in range(128) oops. ::: it's clear that we should do something about this, but it's not entirely clear what do to. quoting from the earlier thread: [paul] > As soon as you find a character out of the ASCII range in one of the > strings, I think that you should report that the two strings are > unequal. [me] > sounds reasonable -- but how do you flag "unequal" in cmp? which > value is "larger" if all that we know is that they're different... [moshe] > We can say something like "beyond the ASCII range, every unicode character > is larger then any regular 8-bit character", and compare > lexicographically. [mal] > The usual method in the Python compare logic is to revert to > the type name for compares in case coercion fails... I think > this is the right description in this case: decoding fails and > thus coercion becomes impossible. > > PyObject_Compare() has the logic, we'd just have to reenable > it for Unicode which currently is handled as special case to > pass through the decoding error. > > Note that Unicode objects which don't coerce would then always > compare larger than 8-bit strings ("unicode" > "string"). ::: having digested this for a week or two, I'm leaning towards moshe's proposal. even if mal's proposal will give the same result in practice, I'm not entirely happy with the idea that the actual contents of a variable (and not just its type) should determine whether the "last resort" type name comparision should be used. a third alternative would be to keep the exception, and make the dictionary code exception proof. having looked at the code, I'm afraid this might be easier said than done... ::: comments? From billtut at microsoft.com Wed Jul 26 02:27:09 2000 From: billtut at microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 17:27:09 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD330@RED-MSG-50> > From: Fredrik Lundh [mailto:effbot at telia.com] > note that if #100899 goes in instead, Bill's tweak of Andrew's > original code won't be needed for anything related to unicode. > the perfect hash module is still a useful tool (not that I ever > got it to do a decent job on the unicode database. Bill's either > very lucky, or he's got a really fast computer... ;-) The secret to getting it to work is to start with a high step rate, find your initial solution so you can test code. Then you set the code up to search for a smaller solution while you're off doing weekend things. Given the number of Unicode character names there wasn't any other way to do it. Smaller key spaces may not care about finding a smaller multiplier solution. I do like my work computer though. Dual 733Mhz with 512MB of ram. Have to have lots of ram to test a web app that caches 30 MB of data out of the database, while still running DevStudio, VSS, etc.... :) Bill From guido at beopen.com Wed Jul 26 05:02:14 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 22:02:14 -0500 Subject: [Python-Dev] is this obsolete? In-Reply-To: Your message of "Tue, 25 Jul 2000 19:58:28 -0400." <20000725195828.A19959@newcnri.cnri.reston.va.us> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> <200007260023.TAA31667@cj20424-a.reston1.va.home.com> <20000725195828.A19959@newcnri.cnri.reston.va.us> Message-ID: <200007260302.WAA31854@cj20424-a.reston1.va.home.com> > It seems too esoteric to take up space in the Tools/ directory, so I'd > suggest taking it out. I'll look at Bill's changes and grab > interesting bits for my copy, though. OK. Please take it out yourself! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Wed Jul 26 05:11:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 22:11:05 -0500 Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: Your message of "Wed, 26 Jul 2000 02:09:48 +0200." <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> Message-ID: <200007260311.WAA31872@cj20424-a.reston1.va.home.com> > (revisiting an old thread on mixed string comparisions) I think it's PEP time for this one... > summary: the current interpreter throws an "ASCII decoding > error" exception if you compare 8-bit and unicode strings, and > the 8-bit string happen to contain a character in the 128-255 > range. Doesn't bother me at all. If I write a user-defined class that raises an exception in __cmp__ you can get the same behavior. The fact that the hashes were the same is a red herring; there are plenty of values with the same hash that aren't equal. I see the exception as a useful warning that the program isn't sufficiently Unicode aware to work correctly. That's a *good* thing in my book -- I'd rather raise an exception than silently fail. Note that it can't break old code unless you try to do new things with the old code: the old code coudn't have supported Unicode because it doesn't exist in Python 1.5.2. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From greg at cosc.canterbury.ac.nz Wed Jul 26 04:49:16 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 14:49:16 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: Message-ID: <200007260249.OAA09513@s454.cosc.canterbury.ac.nz> Moshe Zadka said: > [x; for x in seq] > > and > > [x: for x in seq] Having both the separator and the following 'for' looks somewhat redundant to my eyes. By the way, have people tried looking at some examples in an editor with syntax highlighting? You may find that the various parts stand out more clearly then -- I certainly do. > And what about > > [x+y for x in seq1 for y in seq2 if y>2 if x<3] > > or > > [x+y for x in seq1 if x<3 for y in seq2 if y>2] > > What is allowed? Both are allowed, and both are useful. They produce the same result, but the second one is more efficient. So you can either write declaratively and not worry about the order, or if you're concerned about speed, you can fine-tune the order of the clauses. > Aren't we being a bit too TIMTOWTDIish here? No more than being able to say either x = (a+b); y = (c+d); h = sqrt(x*x + y*y) or h = sqrt((a+b)*(a+b) + (c+d)*(c+d)) Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From greg at cosc.canterbury.ac.nz Wed Jul 26 04:52:31 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 14:52:31 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> Message-ID: <200007260252.OAA09516@s454.cosc.canterbury.ac.nz> > did Python just turn into something that is much harder to parse? Guido has already answered this, but just to make sure, I tried it out on my test implementation: s454% ./python Python 1.5.2 (#11, Sep 11 1999, 16:11:20) [GCC 2.8.1] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> seq = [1,2,3,4,5] >>> [x, x*2 for x in seq] [(1, 2), (2, 4), (3, 6), (4, 8), (5, 10)] >>> Yep, it works! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From greg at cosc.canterbury.ac.nz Wed Jul 26 04:59:14 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 14:59:14 +1200 (NZST) Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <20000725110000.C577@ActiveState.com> Message-ID: <200007260259.OAA09520@s454.cosc.canterbury.ac.nz> Trent Mick suggested: > [for x in [10,20,30]: for y in [1,2,3]: x+y] When designing the syntax, I decided to put the target expression first, because I wanted it to read declaratively. Also I think it's clearer when you can see right up front what it's going to be a list *of*. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From greg at cosc.canterbury.ac.nz Wed Jul 26 05:03:07 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 15:03:07 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: <14717.57165.155081.532709@beluga.mojam.com> Message-ID: <200007260303.PAA09523@s454.cosc.canterbury.ac.nz> Skip Montanaro suggested: > we just allow complete > statements within list constructors. The semantics would be that any > objects left on the stack at the end of the statements would constitute the > elements of the list. Is that too weird? It's too procedural, and too Forth-like. I think it's actually an advantage that the iterator clauses don't look *exactly* like their procedural counterparts, because it's less likely to fool you into thinking that you can put arbitrary statements there. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From greg at cosc.canterbury.ac.nz Wed Jul 26 05:07:10 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 15:07:10 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: <20000725152832.A2019@thyrsus.com> Message-ID: <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> "Eric S. Raymond" said: > What they want to be is an applicative sublanguage in functional > style Um, that might be what *you* want them to be, but it's the complete opposite of what *I* want them to be, which is a way of getting away from all those convoluted combinator constructs! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From gvwilson at nevex.com Wed Jul 26 05:08:49 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 25 Jul 2000 23:08:49 -0400 (EDT) Subject: [Python-Dev] list comprehension quiz Message-ID: Hi, folks. In order to put the list comprehension syntax questionnaire together, I would be grateful if anyone with a favorite syntax could send me their equivalent of the following scraps of Python (or other scraps and their equivalents, if you think there are interesting cases that I'm not covering). In order to save bandwidth, please mail me directly --- I will summarize and post the questionnaire itself. Thanks, Greg -- 1 ---------------------------------------- input = [1, 2, 3, 4, 5] output = [] for num in input: output.append(2 * num) >>> [2, 4, 6, 8, 10] -- 2 ---------------------------------------- input = [1, 2, 3, 4, 5] output = [] for num in input: if is_odd(num): output.append(num) >>> [1, 3, 5] -- 3 ---------------------------------------- input = [1, 2, 3, 4, 5] output = 0 for num in input: output = output + num >>> 15 -- 4 ---------------------------------------- tens = [10, 20, 30] units = [ 1, 2] output = [] for t in tens: for u in units: output.append(u + t) >>> [11, 12, 21, 22, 31, 32] -- 5 ---------------------------------------- tens = [10, 20, 30] units = [ 1, 2, 3, 4, 5] output = [] lim = min(len(tens), len(units)) for i in range(0, lim): output.append(max(tens[i], units[i])) >>> [10, 20, 30] -- 6 ---------------------------------------- phones = {229 : 'Greg', 231 : 'Toni', 268 : 'Jaq', 271 : 'Hassan'} output = [] for p in phones.keys(): if p > 250: output.append(phones[p]) >>> ['Hassan', 'Jaq'] From greg at cosc.canterbury.ac.nz Wed Jul 26 05:12:54 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 15:12:54 +1200 (NZST) Subject: [Python-Dev] Names for things In-Reply-To: <14718.7988.542661.35195@anthem.concentric.net> Message-ID: <200007260312.PAA09530@s454.cosc.canterbury.ac.nz> bwarsaw at beopen.com (Barry A. Warsaw): > 35 years and tens of millions of records later, and even "Pink Floyd" seems > like a brilliant name for a band. And "Monty Python" is such an obviously good name for a comedy show... and "Python" for a programming language! Guido obviously used his time machine to plant the name in our minds a few decades ago to give us time to get used to the idea. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From tim_one at email.msn.com Wed Jul 26 05:11:53 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 23:11:53 -0400 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> Message-ID: [Greg Wilson] > I would also like to volunteer to repeat the "simultaneous loop" syntax > experiment with list comprehensions, i.e. see whether what's being > proposed lines up with people's pre-existing intuitions. [Guido] > Please do! > > Though I have no doubt of the outcome: > > [x+y for x in [10, 20, 30] for y in [1, 2, 3]] > > will be almost universally understood to mean > > [11, 12, 13, 21, 22, 23, 31, 32, 33]. I'm not sure about that! Greg hangs out with functional programmers and old Fortran-heads. Fortran has a handy construct called "implied DO (loops)" in I/O statements, and in those the *innermost* (leftmost) shorthand loop varies fastest. So I expect the Fortran'ers to guess [11, 21, 31, 12, 22, ...] I agree the experiment is worth trying, but I'm not sure we're observing anything other than experienced programmers' prior language-dependent conditioning ... which would also explain why neither Greg's functional nor Fortran guinea pigs had any concept of lockstep iteration across multiple loop controls. BTW, an MxN slice of a 2D array A in Fortran will often show up in an I/O stmt as ... ((A(I,J), I=1,M), J=1,N) ... and the "innermost fastest" rule relates directly to Fortran's oddball decision to use column-major array storage: the natural way to write the I/O using implied DOs caters to varying the first index fastest (== contiguous memory locations under column-major storage). It's not like there's a *profound* reason behind this . From esr at thyrsus.com Wed Jul 26 05:34:26 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 23:34:26 -0400 Subject: [Python-Dev] PEP202 In-Reply-To: <200007260307.PAA09527@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Jul 26, 2000 at 03:07:10PM +1200 References: <20000725152832.A2019@thyrsus.com> <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> Message-ID: <20000725233426.B3540@thyrsus.com> Greg Ewing : > > What they want to be is an applicative sublanguage in functional > > style > > Um, that might be what *you* want them to be, but it's the > complete opposite of what *I* want them to be, which is a > way of getting away from all those convoluted combinator > constructs! So your theory is that non-intuitive procedural syntax so complex that it *needs* usability testing is better. Riiiight... -- Eric S. Raymond "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy From akuchlin at cnri.reston.va.us Wed Jul 26 05:40:31 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 25 Jul 2000 23:40:31 -0400 Subject: [Python-Dev] Names for things In-Reply-To: <200007260312.PAA09530@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Jul 26, 2000 at 03:12:54PM +1200 References: <14718.7988.542661.35195@anthem.concentric.net> <200007260312.PAA09530@s454.cosc.canterbury.ac.nz> Message-ID: <20000725234031.A20602@newcnri.cnri.reston.va.us> Regarding naming... I would recommend not wasting any more time on the naming issue. (This is a recurring theme in my posts -- remember, I spent about 0.3 microseconds thinking about whether "Python" would be a good name for a programming language, and I've never regretted it.) -- Guido van Rossum, 25 Nov 1998 From greg at cosc.canterbury.ac.nz Wed Jul 26 05:52:25 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 15:52:25 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: <20000725233426.B3540@thyrsus.com> Message-ID: <200007260352.PAA09543@s454.cosc.canterbury.ac.nz> > So your theory is that non-intuitive procedural syntax so complex that > it *needs* usability testing is better. It seems that our brains work in different ways here. What's clear to you is obscure to me, and vice versa. (I'm not the one that thinks it needs usability testing, by the way - that's a different Greg.) Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From jeremy at beopen.com Wed Jul 26 05:57:38 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 23:57:38 -0400 (EDT) Subject: [Python-Dev] PEP202 In-Reply-To: <20000725233426.B3540@thyrsus.com> References: <20000725152832.A2019@thyrsus.com> <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> <20000725233426.B3540@thyrsus.com> Message-ID: <14718.25010.135008.849218@bitdiddle.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> Greg Ewing : [>> ESR wrote:] >> > What they want to be is an applicative sublanguage in >> > functional style >> >> Um, that might be what *you* want them to be, but it's the >> complete opposite of what *I* want them to be, which is a way of >> getting away from all those convoluted combinator constructs! ESR> So your theory is that non-intuitive procedural syntax so ESR> complex that it *needs* usability testing is better. ESR> Riiiight... Wow! There's so much jargon being slung here I don't know what's going on. (For the second time in the last few weeks, I feel like a bit player in a movie where all the major roles are played by Peter Sellers. ) Seriously, I don't understand how to apply terms like "applicative sublanguage in functional style" or "procedural syntax" to a concept like list comprehensions. The basic idea is to express the elements of list using a set-like notation similar to the one used by mathematicians. I don't know whether to call that applicative, functional, or procedural; perhaps none of them applu. Maybe it's just late, but I suspect that these high-level terms don't inform the debate much. I think we can all agree on two things: 1. Greg and Eric have different goals, which is fine. 2. Usability testing is always a good thing. To paraphrase Fred Brooks, even the best language designers aren't so omniscient as to get it right the first time. Jeremy From skip at mojam.com Wed Jul 26 06:35:20 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 23:35:20 -0500 (CDT) Subject: [Python-Dev] PEP202 In-Reply-To: <14718.25010.135008.849218@bitdiddle.concentric.net> References: <20000725152832.A2019@thyrsus.com> <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> <20000725233426.B3540@thyrsus.com> <14718.25010.135008.849218@bitdiddle.concentric.net> Message-ID: <14718.27272.221884.457831@beluga.mojam.com> Jeremy> 2. Usability testing is always a good thing. To paraphrase Fred Jeremy> Brooks, even the best language designers aren't so omniscient Jeremy> as to get it right the first time. Though Guido came damn close... ;-) S From esr at thyrsus.com Wed Jul 26 06:55:26 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 26 Jul 2000 00:55:26 -0400 Subject: [Python-Dev] PEP202 -- glossary of terms In-Reply-To: <14718.25010.135008.849218@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 25, 2000 at 11:57:38PM -0400 References: <20000725152832.A2019@thyrsus.com> <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> <20000725233426.B3540@thyrsus.com> <14718.25010.135008.849218@bitdiddle.concentric.net> Message-ID: <20000726005526.A3796@thyrsus.com> Jeremy Hylton : > Seriously, I don't understand how to apply terms like "applicative > sublanguage in functional style" or "procedural syntax" to a concept > like list comprehensions. The basic idea is to express the elements > of list using a set-like notation similar to the one used by > mathematicians. I don't know whether to call that applicative, > functional, or procedural; perhaps none of them applu. Maybe it's > just late, but I suspect that these high-level terms don't inform the > debate much. Partly this is my error; I should have said "conventional" or "infix" where I said "procedural". I was writing too fast -- procedural languages are conventional in a different way, but I was referring to conventional syntax. More generally, I guess I have to apologize for excessive use of jargon without enough context. The crowd on this list is so fearsomely competent that I tend to forget that most of you don't have a technical specialty in language design. Here's a brief glossary of relevant language-designer jargon: functional style: Refers to a language in which everything is pure function calls, without side-effects or variables. Backus's F is one of the better-known examples. LISP would be functional if there were no (setq ...). The advantage of functional language is the same as their disadvantage: no side-effects. Makes them easy to reason about, but you have to jump through hoops to do statefulness. procedural style: A procedural language has procedures that operate on variables. Explicit statefulness and side-effects are basic to such languages. applicative sublanguage: This is more about syntax. To say a syntax is applicative is to say that it *looks* like cascaded function calls, as opposed (for example) to using infix syntax or keywords. (This is oversimplifying a little; Haskell combines keywords with a syntax that could be called applicative, but Haskell is weird by design that way.) imperative vs. declarative: In an imperative language, you tell the machine to do stuff. In a declarative language you specify a desired end state and let the language implementation deduce how to generate it. A good example of a declarative sublanguage familiar to most Python programers is Tk widget layout. List comprehensions are declarative in style, even though they analyze down to a series of imperative actions. Most of Python is much more straightforwardly imperative. One of the heuristics of good language design is that boundaries between imperative and declarative sublanguages are always tricky -- users have a strong tendency to try to port concepts across the boundary and get confused. This is behind some of the confusion about comprehensions. conventional: Means different things in different contexts. When speaking of syntax, it means pseudo-algebraic syntax with infix notation and keyords. In other contexts, it can mean procedural rather than functional, or manual memory management rather than garbage collection, or fixed-extent vs. unlimited-extent. The archetypal conventional language is Algol-60. For you young 'uns out there, think Pascal. -- Eric S. Raymond From moshez at math.huji.ac.il Wed Jul 26 06:54:50 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 26 Jul 2000 07:54:50 +0300 (IDT) Subject: [Python-Dev] Meta: pep-dev (was Re: [PEP 2-0-2 listcomps] (was RE: [Python-Dev] Product iteration)) In-Reply-To: Message-ID: (Added hiphens in 2-0-2 to keep out of the timbot's radar) On Tue, 25 Jul 2000, Tim Peters wrote: > A pep-dev mailing list is clearly a very good idea, but until one is set up > I'm afraid python-dev is the only natural place to bear the unbearable (to > some) pep-dev traffic. It seems that the correct solution is not a big "pep-dev", but rather a "pep-[1-9][0-9]*-dev" lists, one for each pep. So I'll just sit back quietly and wait for ?!in to suggest roundup for this. Then we'll Barry see how he can easily make mailman do this. <202 wink> last-man-coding-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From moshez at math.huji.ac.il Wed Jul 26 09:09:51 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 26 Jul 2000 10:09:51 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: On Tue, 25 Jul 2000, Andrew Kuchling wrote: > On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond wrote: > >Wrong answer. The right answer is to fix lambda (or some variant of lambda) > >to be a true lexical closure. > > Hm... hmmmm... fixing this has been suggested before, but always > foundered on the fact that creating a closure required a cycle, which > would leak memory. Now we have an optional GC that should handle > this, so maybe fixing it can be revisited. (But this would mean that > GC is essentially no longer optional -- maybe too radical a thing to > do before we're sure about the new GC. 2.1, maybe?) I think I'd rather have this solved by weak references then by building cycles. Cycles are evil even in the face of GC -- you have undetermined finalization. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From nowonder at pool.informatik.rwth-aachen.de Wed Jul 26 10:10:40 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Wed, 26 Jul 2000 08:10:40 +0000 Subject: [Python-Dev] Summary or failing regression tests... References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> Message-ID: <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> Trent Mick wrote: > > 'test_fork1' works for me when run as: > ./python Lib/test/regrtest.py > > but hangs when run as: > ./python Lib/test/test_fork1.py > or > ./python Lib/test/regrtest.py test_fork1 On my system there is no problem: nowonder at mobility:~/python/python/dist/src > ./python Lib/test/test_fork1.py nowonder at mobility:~/python/python/dist/src > ./python Lib/test/regrtest.py test_fork1 test_fork1 1 test OK. I am using a (somewhat modified) SuSE 6.4 distribution with an old 2.2.13 kernel. What does your's look like? Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From effbot at telia.com Wed Jul 26 09:49:44 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 09:49:44 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> <200007260311.WAA31872@cj20424-a.reston1.va.home.com> Message-ID: <00a601bff6d6$12f14820$f2a6b5d4@hagrid> guido wrote: > > summary: the current interpreter throws an "ASCII decoding > > error" exception if you compare 8-bit and unicode strings, and > > the 8-bit string happen to contain a character in the 128-255 > > range. > > Doesn't bother me at all. If I write a user-defined class that raises > an exception in __cmp__ you can get the same behavior. The fact that > the hashes were the same is a red herring; there are plenty of values > with the same hash that aren't equal. > > I see the exception as a useful warning that the program isn't > sufficiently Unicode aware to work correctly. That's a *good* thing > in my book -- I'd rather raise an exception than silently fail. I assume that means you're voting for alternative 3: "a third alternative would be to keep the exception, and make the dictionary code exception proof." because the following isn't exactly good behaviour: >>> a = "?" >>> b = unicode(a, "iso-8859-1") >>> d = {} >>> d[a] = "a" >>> d[b] = "b" >>> len(d) UnicodeError: ASCII decoding error: ordinal not in range(128) >>> len(d) 2 (in other words, the dictionary implementation misbehaves if items with the same hash value cannot be successfully compared) From tim_one at email.msn.com Wed Jul 26 10:09:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 26 Jul 2000 04:09:27 -0400 Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: <00a601bff6d6$12f14820$f2a6b5d4@hagrid> Message-ID: [Guido] > ... > I see the exception as a useful warning that the program isn't > sufficiently Unicode aware to work correctly. That's a *good* thing > in my book -- I'd rather raise an exception than silently fail. [Fredrik Lundh] > I assume that means you're voting for alternative 3: > > "a third alternative would be to keep the exception, and make > the dictionary code exception proof." > > because the following isn't exactly good behaviour: > > >>> a = "?" > >>> b = unicode(a, "iso-8859-1") > >>> d = {} > >>> d[a] = "a" > >>> d[b] = "b" > >>> len(d) > UnicodeError: ASCII decoding error: ordinal not in range(128) > >>> len(d) > 2 > > (in other words, the dictionary implementation misbehaves if items > with the same hash value cannot be successfully compared) Hmm. That's a bug in the dict implementation that's independent of Unicode issues, then -- and I can provoke similar behavior with classes that raise exceptions from __cmp__, without using Unicode anywhere. So, ya, the dict bugs have to be fixed. Nobody needs to vote on *that* part . I'll look into it "soon", unless somebody else does first. From mal at lemburg.com Wed Jul 26 10:11:40 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 26 Jul 2000 10:11:40 +0200 Subject: [Python-Dev] test_fork1.py failing (Summary or failing regression tests...) References: <20000725153912.A21409@ActiveState.com> Message-ID: <397E9D3C.9181A0E0@lemburg.com> Trent Mick wrote: > > Here is a list of the regrtests that are currently failing for me on Linux32 > and Win32. Is anybody looking at test_mmap, test_userstring, test_winreg, > and test_winreg2? > > Skip, You and Jeremy(?) were talking about test_posixpath on Linux. It looks > like the sames errors you were talking about occur on Win32. I didn't look > too closely, can you? > > Fredrik, are you aware of the test_sre failure on Win32? Am I doing something > wrong to be getting this? > > On Linux32: > - test_fork1 > This fails/hangs/crashes inconsistently because (some little bird told me) > the fork stuff and threads are incompatible. Am I right? Now that we are > turning threads on by default what is the proper thing to do here? SHould > test_fork1 be changed to skip if threads are enabled? Does this mean that a stock Python 1.6/2.0 interpreter will not properly do fork() on Linux32 (even when using threads) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jul 26 10:41:06 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 26 Jul 2000 10:41:06 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> Message-ID: <397EA422.3E785467@lemburg.com> Fredrik Lundh wrote: > > (revisiting an old thread on mixed string comparisions) > > summary: the current interpreter throws an "ASCII decoding > error" exception if you compare 8-bit and unicode strings, and > the 8-bit string happen to contain a character in the 128-255 > range. > > this is not only confusing for users, it also confuses the hell > out of Python itself. for example: > > >>> a = u"?" > >>> b = "?" > >>> hash(a) > -283818363 > >>> hash(b) > -283818363 > >>> a == b > Traceback (most recent call last): > File "", line 1, in ? > UnicodeError: ASCII decoding error: ordinal not in range(128) > >>> d = {} > >>> d[a] = "a" > >>> d[b] = "b" > >>> len(d) > UnicodeError: ASCII decoding error: ordinal not in range(128) > > oops. This is due to the fact that the Python dictionary lookup implementation doesn't properly treat exceptions raised during object compares -- this should probably be changed (e.g. the lookup procedure could clear the error just before returning to caller) ?! The Unicode implementation only makes this bug in the core visible because before that raising exceptions during compares was not a common thing to do. > ::: > > it's clear that we should do something about this, but it's > not entirely clear what do to. > > quoting from the earlier thread: > > [paul] > > As soon as you find a character out of the ASCII range in one of the > > strings, I think that you should report that the two strings are > > unequal. > > [me] > > sounds reasonable -- but how do you flag "unequal" in cmp? which > > value is "larger" if all that we know is that they're different... > > [moshe] > > We can say something like "beyond the ASCII range, every unicode character > > is larger then any regular 8-bit character", and compare > > lexicographically. > > [mal] > > The usual method in the Python compare logic is to revert to > > the type name for compares in case coercion fails... I think > > this is the right description in this case: decoding fails and > > thus coercion becomes impossible. > > > > PyObject_Compare() has the logic, we'd just have to reenable > > it for Unicode which currently is handled as special case to > > pass through the decoding error. > > > > Note that Unicode objects which don't coerce would then always > > compare larger than 8-bit strings ("unicode" > "string"). > > ::: > > having digested this for a week or two, I'm leaning towards > moshe's proposal. > > even if mal's proposal will give the same result in practice, I'm > not entirely happy with the idea that the actual contents of a > variable (and not just its type) should determine whether the > "last resort" type name comparision should be used. This has been the standard way of processing for years: if coercion fails (for whatever reason), go ahead and fall back to the type name compare. > a third alternative would be to keep the exception, and make > the dictionary code exception proof. having looked at the code, > I'm afraid this might be easier said than done... Right. Plus we'd have to be *very* careful about not introducing a performance problem here instead (after all, dict lookups are at the heart of what makes Python so cool). Note that we should look into this independent of the Unicode discussion: user code may very well raise exceptions too and the result would be a lingering exception state just like in the example above. > ::: > > comments? I'd say: mask the coercion error during compare in the standard way and remove the special casing for Unicode in PyObject_Compare(). Then as second step: rethink coercion altogether and possibly fix the situation in the compare operator of either strings or Unicode. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mhammond at skippinet.com.au Wed Jul 26 10:45:48 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 26 Jul 2000 18:45:48 +1000 Subject: [Python-Dev] Product iteration In-Reply-To: Message-ID: > I think I'd rather have this solved by weak references then by building > cycles. Cycles are evil even in the face of GC -- you have undetermined > finalization. It's worth pointing out that Python actually guarantees you may have undetermined finalization - it's just not an implementation requirement that it be that way. But-it-phrases-it-a-little-differently-than-that- ly, Mark. From effbot at telia.com Wed Jul 26 10:55:46 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 10:55:46 +0200 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> Message-ID: <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> guido wrote: > > It derives in turn from SETL, which followed common set-theoretic > > notation. This "grabbed" Guido; LISP spellings never did, and I bet > > never will. > > I've never used or even seen SETL, but there is a connection: SETL had > a profound influence on the designers of ABC, in particular Lambert > Meertens, who spent a sabbatical year working with the folks at New > York University who wrote the first validated Ada compiler in SETL. found this one: http://www-robotics.eecs.lehigh.edu/~bacon/setlprog.ps.gz interesting reading. SETL sure has a pythonic feel... with a few improvements, of course (like the [start next end] range literals... too late to fix that in python, I suppose...) and personally, I prefer their "tuple former" syntax over the the current PEP202 proposal: [expression : iterator] [n : n in [1:100]] [(x**2, x) : x in [1:5]] [a : a in y if a > 5] (all examples are slightly pythonified; most notably, they use "|" or "st" (such that) instead of "if") the expression can be omitted if it's the same thing as the loop variable, *and* there's at least one "if" clause: [a in y if a > 5] also note that their "for-in" statement can take qualifiers: for a in y if a > 5: ... is there any special reason why we cannot use colon instead of "for"? From mal at lemburg.com Wed Jul 26 11:11:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 26 Jul 2000 11:11:37 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> <200007260311.WAA31872@cj20424-a.reston1.va.home.com> Message-ID: <397EAB49.8B5B0505@lemburg.com> Guido van Rossum wrote: > > > (revisiting an old thread on mixed string comparisions) > > I think it's PEP time for this one... > > > summary: the current interpreter throws an "ASCII decoding > > error" exception if you compare 8-bit and unicode strings, and > > the 8-bit string happen to contain a character in the 128-255 > > range. > > Doesn't bother me at all. If I write a user-defined class that raises > an exception in __cmp__ you can get the same behavior. The fact that > the hashes were the same is a red herring; there are plenty of values > with the same hash that aren't equal. > > I see the exception as a useful warning that the program isn't > sufficiently Unicode aware to work correctly. That's a *good* thing > in my book -- I'd rather raise an exception than silently fail. > > Note that it can't break old code unless you try to do new things with > the old code: the old code coudn't have supported Unicode because it > doesn't exist in Python 1.5.2. Hmm, so you do want exceptions to be raised for coercion errors during compare ? For the record: PyObject_Compare() currently only does coercion for number slot compatible types (ok, all Python instances have these slots...). Unicode objects are handled in a special case to allow the PyUnicode_Compare() API to do all necessary conversions and then proceed with the compare. The coercion proposal will have to deal with all this in 2.1. My version of the proposal (see Python Pages) puts all the power into the hands of the operators themselves rather than using a centralized coercion method. In this scenario, the special casing in PyObject_Compare() for Unicode would no longer be necessary, since the Unicode compare slot could then take care of the needed conversions (essentially PyUnicode_Compare() would beceom that slot). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From nowonder at pool.informatik.rwth-aachen.de Wed Jul 26 13:24:44 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Wed, 26 Jul 2000 11:24:44 +0000 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> Message-ID: <397ECA7C.E872636C@pool.informatik.rwth-aachen.de> [Fredrik Lundh] > > and personally, I prefer their "tuple former" syntax over the the > current PEP202 proposal: > > [expression : iterator] > > [n : n in [1:100]] > [(x**2, x) : x in [1:5]] > [a : a in y if a > 5] Funny. I send a mail to Tim this morning with a similar proposal: [Peter] > > Not being too happy with the proposed syntaxes I came up > with a new one. > > I think it is much better to parse (for human readers), > but I am open about ';' as the delimiter. ':' would feel > very fine to me, too. > > Syntax: > [; , , ...] > > Example for semantics: > [x+y; x in [1, 2, 3], x <= 2, y in [10, 20, 30], y in [5, 10, 20]] > == [11, 21, 12, 22] > > How to implement this example: > (only a sketch, this will probably be too slow to > really do it like this, but maybe you get the idea > that it is at least possible to do it) > 1) set baselist_for_x and baselist_for_y to > something special (None?) indicating all possible > values for x and y (they are unconstrained) > 2) on encountering "x in [1, 2, 3]" set > baselist_for_x to [1, 2, 3] > 3) on encountering "x <= 2" filter baselist_for_x > and get [1, 2] > 4) on encountering "y in [10, 20, 30]" set > baselist_for_y to [10, 20, 30] > 5) on encountering "y in [5, 10, 20] see that > baselist_for_y != special value (None?) and so > filter baselist_for_y and get [10, 20] > 6) produce cross product of baselist_for_x > and baselist_for_y > 7) apply expression to elements of cross product > > The general idea is to start with lists of all > possible values (represented by a special value) > and use the conditions in the list comprehension > to constrain that list. If we don't want to deal > with infinite lists (and therefore lazy stuff) > we could through an ConstraintError on the following: > > >>> [x; x > 10000] > ConstraintError: missing sequence constraint for x The difference (besides ';' against ':') is the use of commas for seperation and not using if. [Fredrik Lundh] > is there any special reason why we cannot use colon instead > of "for"? There seem to be some reasons, but I am not sure I have understood them. Probably I'll best quote from Tim's reply: [Tim Peters] > That said, I can guarantee Guido will hate that in > > > [x+y; x in [1, 2, 3], x <= 2, y in [10, 20, 30], y in [5, 10, 20]] > > you have > y in [...] > meaning iteration in one position but have it meaning a filter in another. No. I have it mean filter in all cases. That's just implementation. [Tim Peters] > The syntax is also deadly ambiguous: > x <= 2 > is a legit Python expression today, but so is > x <= 2, y > and so is > x <= 2, y in [10, 20, 30] > and so is > x <= 2, y in [10, 20, 30], y > etc. This syntax is simply unparsable given the uses for commas in Python's > existing expression syntax. That's one reason "for" and "if" have been in > every other proposal for at least the last year . Wouldn't it be possible to just parse the first part (before the delimiter - be it ';' or ':') as an expression and allow a tuple of boolean expressions after the delimiter? Picture list comprehensions as list constraints. With [x,y: x in list1, y in list2, x > 10, odd(y)] I say that I want to have all tuples of x and y who satisfy the following constraints: - x is an element of list1 and greater than 10 - y is an element of list2 and odd For the parser the following cases would both be valid: [x+y: x in list1, y in list2] [(x+y): (x in list1, y in list2)] The latter would be what Python sees, but given that parentheses are optional for expressions and tuple building the former would be legal python. [Tim Peters] > Don't mean to be discouraging, but looks like you missed the first year of > this debate! Actually I think I did. But then I didn't even know about Python 4 months ago. newbie-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gmcm at hypernet.com Wed Jul 26 11:32:11 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Wed, 26 Jul 2000 05:32:11 -0400 Subject: [Python-Dev] PEP202 In-Reply-To: <20000725233426.B3540@thyrsus.com> References: <200007260307.PAA09527@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Jul 26, 2000 at 03:07:10PM +1200 Message-ID: <1247518565-39631569@hypernet.com> > So your theory is that non-intuitive procedural syntax ... C'mon Eric. The only intuitive syntax is: - the grunt - the scream - the laugh - "Well Helloooo sailor" -and-3-of-those-are-ambiguous-ly y'rs - Gordon From mal at lemburg.com Wed Jul 26 12:32:32 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 26 Jul 2000 12:32:32 +0200 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> Message-ID: <397EBE40.54E76DF4@lemburg.com> Fredrik Lundh wrote: > > SETL sure has a pythonic feel... > > with a few improvements, of course (like the [start next end] > range literals... too late to fix that in python, I suppose...) > > and personally, I prefer their "tuple former" syntax over the the > current PEP202 proposal: > > [expression : iterator] > > [n : n in [1:100]] > [(x**2, x) : x in [1:5]] > [a : a in y if a > 5] > > (all examples are slightly pythonified; most notably, they > use "|" or "st" (such that) instead of "if") > > the expression can be omitted if it's the same thing as the > loop variable, *and* there's at least one "if" clause: > > [a in y if a > 5] > > also note that their "for-in" statement can take qualifiers: > > for a in y if a > 5: > ... > > is there any special reason why we cannot use colon instead > of "for"? For mathematicians the [ : ] or [ | ] looks natural since it's their every day style of writing sets, but I doubt that CP4E users get the grasp of this. Anyway, whatever syntax you choose, please make sure that the and the parts are very well visibily separated. [ for in ] doesn't fall in that category, IMHO. Hehe, this is starting to get the feel of SQL with their horrible SELECT syntax: SELECT FROM WHERE ORDER BY etc. pp. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From m.favas at per.dem.csiro.au Wed Jul 26 12:40:04 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Wed, 26 Jul 2000 18:40:04 +0800 Subject: [Python-Dev] Sub-package import mechanism now broken? Message-ID: <397EC004.A73F815@per.dem.csiro.au> Have the sub-package import semantics changed, or is import broken in the current CVS? (still works in my last version of 1.6a2, and, yes, /usr/local/lib/python2.0/site-packages Python 2.0b1 (#208, Jul 26 2000, 14:54:31) [C] on osf1V4 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> import Pmw >>> from xml import * >>> from xml.sax import saxlib Traceback (most recent call last): File "", line 1, in ? ImportError: cannot import name saxlib >>> from xml.parsers.xmlproc import xmlproc Traceback (most recent call last): File "", line 1, in ? ImportError: No module named parsers.xmlproc >>> -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From guido at beopen.com Wed Jul 26 14:57:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 07:57:02 -0500 Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: Your message of "Wed, 26 Jul 2000 09:49:44 +0200." <00a601bff6d6$12f14820$f2a6b5d4@hagrid> References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> <200007260311.WAA31872@cj20424-a.reston1.va.home.com> <00a601bff6d6$12f14820$f2a6b5d4@hagrid> Message-ID: <200007261257.HAA01308@cj20424-a.reston1.va.home.com> > > I see the exception as a useful warning that the program isn't > > sufficiently Unicode aware to work correctly. That's a *good* thing > > in my book -- I'd rather raise an exception than silently fail. > > I assume that means you're voting for alternative 3: > > "a third alternative would be to keep the exception, and make > the dictionary code exception proof." Yes. > because the following isn't exactly good behaviour: > > >>> a = "?" > >>> b = unicode(a, "iso-8859-1") > >>> d = {} > >>> d[a] = "a" > >>> d[b] = "b" > >>> len(d) > UnicodeError: ASCII decoding error: ordinal not in range(128) > >>> len(d) > 2 > > (in other words, the dictionary implementation misbehaves if items > with the same hash value cannot be successfully compared) Good point. This would happen if you used flakey class instances as keys as well! (Note that the exception really happens on the d[b] = "b" statement; but because the dict implementation doesn't check for exceptions, it gets reported too late. We've seen this kind of bugs before in Python.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Wed Jul 26 15:00:33 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 08:00:33 -0500 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: Your message of "Wed, 26 Jul 2000 10:55:46 +0200." <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> Message-ID: <200007261300.IAA01335@cj20424-a.reston1.va.home.com> > is there any special reason why we cannot use colon instead > of "for"? Would conflict with the proposed syntax for range literals. Both [0:10] and [x : x in seq] have the same syntactical form. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Wed Jul 26 15:02:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 08:02:02 -0500 Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: Your message of "Wed, 26 Jul 2000 11:11:37 +0200." <397EAB49.8B5B0505@lemburg.com> References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> <200007260311.WAA31872@cj20424-a.reston1.va.home.com> <397EAB49.8B5B0505@lemburg.com> Message-ID: <200007261302.IAA01353@cj20424-a.reston1.va.home.com> > Hmm, so you do want exceptions to be raised for coercion errors > during compare ? Sure, fine. > For the record: > PyObject_Compare() currently only does coercion for number > slot compatible types (ok, all Python instances have these > slots...). Unicode objects are handled in a special case to > allow the PyUnicode_Compare() API to do all necessary conversions > and then proceed with the compare. > > The coercion proposal will have to deal with all this in 2.1. > > My version of the proposal (see Python Pages) puts all the power > into the hands of the operators themselves rather than using > a centralized coercion method. In this scenario, the special > casing in PyObject_Compare() for Unicode would no longer > be necessary, since the Unicode compare slot could then take > care of the needed conversions (essentially PyUnicode_Compare() > would beceom that slot). This all sounds okay to me -- I've signed off on that design (in principle) years ago... --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Wed Jul 26 15:12:20 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 08:12:20 -0500 Subject: [Python-Dev] Product iteration In-Reply-To: Your message of "Wed, 26 Jul 2000 10:09:51 +0300." References: Message-ID: <200007261312.IAA01454@cj20424-a.reston1.va.home.com> > > Hm... hmmmm... fixing this has been suggested before, but always > > foundered on the fact that creating a closure required a cycle, which > > would leak memory. Now we have an optional GC that should handle > > this, so maybe fixing it can be revisited. (But this would mean that > > GC is essentially no longer optional -- maybe too radical a thing to > > do before we're sure about the new GC. 2.1, maybe?) > > I think I'd rather have this solved by weak references then by building > cycles. Cycles are evil even in the face of GC -- you have undetermined > finalization. But in this case, there aren't any custom finalizers involved in the cycle (although there may be some *hanging off* the cycle). E.g. after: def f(): def g(): pass f() we have (taking some notational liberties and simplifications): globals = {'f': f} f.func_globals = globals locals = {'g': g} g.func_globals = locals # or maybe g.func_parent = locals In other words the cycles are between a dictionary and a function object: globals <--> f locals <--> g I don't see any finalization issues. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From moshez at math.huji.ac.il Wed Jul 26 14:21:00 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 26 Jul 2000 15:21:00 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <200007261312.IAA01454@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 26 Jul 2000, Guido van Rossum wrote: > > I think I'd rather have this solved by weak references then by building > > cycles. Cycles are evil even in the face of GC -- you have undetermined > > finalization. > > But in this case, there aren't any custom finalizers involved in the > cycle (although there may be some *hanging off* the cycle). Yes, but those finalizers hanging off the cycle would occur in some random time in the future, not right now, hence rendering the def f(): fp = open("fff") pass idiom dangerous, since you're not sure how long fp will remain open. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at beopen.com Wed Jul 26 15:31:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 08:31:29 -0500 Subject: [Python-Dev] Product iteration In-Reply-To: Your message of "Wed, 26 Jul 2000 15:21:00 +0300." References: Message-ID: <200007261331.IAA01752@cj20424-a.reston1.va.home.com> > > But in this case, there aren't any custom finalizers involved in the > > cycle (although there may be some *hanging off* the cycle). > > Yes, but those finalizers hanging off the cycle would occur in some random > time in the future, not right now, hence rendering the > > def f(): > fp = open("fff") > pass > > idiom dangerous, since you're not sure how long fp will remain open. Aha. You're complaining about the finalizers being postponed arbitrarily. I thought you were complaining about the issue of finalization order *within* the cycle. Since this is still an improvement over current practice (where a finalizer hanging off a cycle may never be called) and there are no serialization issues, I don't see the problem. If you want to use weak references, please try to specify *in detail* which objects would have weak references to which other objects and how the system would resolve these... I'm never sure that things can be made 100% safe using this technique, so it may help to spell it out for me! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From m.favas at per.dem.csiro.au Wed Jul 26 15:11:11 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Wed, 26 Jul 2000 21:11:11 +0800 Subject: [Python-Dev] Sub-package import mechanism now broken? No, but... Message-ID: <397EE36F.59615826@per.dem.csiro.au> Opps - the import mechanism is not broken, it's just that the xml package in lib/site-packages no longer gets found, because of the new xml package in lib. This will still break existing code, unless the xml package in lib is renamed, has the same functionality as the PyXML package that installs in lib/site-packages, or has a method of handing off to the, um, more extensive site-package version... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From jack at oratrix.nl Wed Jul 26 15:30:01 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 26 Jul 2000 15:30:01 +0200 Subject: [Python-Dev] ANSIfication. In-Reply-To: Message by Guido van Rossum , Tue, 25 Jul 2000 07:38:19 -0500 , <200007251238.HAA19158@cj20424-a.reston1.va.home.com> Message-ID: <20000726133002.4D95937186E@snelboot.oratrix.nl> > Frankly, I think that for *any* functions that are in some external > library (e.g. libc), Python should never provide a function prototype > at all. The standard headers should provide the prototypes! They should, but what if they don't? That's what I like about the pyport.h: it allows Python to build out of the box but still keeps all the cruft needed because some platforms don't have their act together in a single place. I know that I'm not expected to understand sections of pyport.h that are for platforms I'm not familiar with... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido at beopen.com Wed Jul 26 16:33:18 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 09:33:18 -0500 Subject: [Python-Dev] ANSIfication. In-Reply-To: Your message of "Wed, 26 Jul 2000 15:30:01 +0200." <20000726133002.4D95937186E@snelboot.oratrix.nl> References: <20000726133002.4D95937186E@snelboot.oratrix.nl> Message-ID: <200007261433.JAA02431@cj20424-a.reston1.va.home.com> [Guido] > > Frankly, I think that for *any* functions that are in some external > > library (e.g. libc), Python should never provide a function prototype > > at all. The standard headers should provide the prototypes! [Jack] > They should, but what if they don't? That's what I like about the > pyport.h: it allows Python to build out of the box but still keeps > all the cruft needed because some platforms don't have their act > together in a single place. I know that I'm not expected to > understand sections of pyport.h that are for platforms I'm not > familiar with... Exactly! But the point is that over the last 10 years we've collected an enormous amount of cruft in this area that's not needed any more, because platforms improve. So my proposal is to remove all the cruft for which we don't have positive confirmation that it's needed somewhere, and then add back whatever's necessary to support all esoteric platforms again. Not-saying-what's-considered-esoteric-ly, --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From moshez at math.huji.ac.il Wed Jul 26 15:33:46 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 26 Jul 2000 16:33:46 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <200007261331.IAA01752@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 26 Jul 2000, Guido van Rossum wrote: > Since this is still an improvement over current practice (where a > finalizer hanging off a cycle may never be called) and there are no > serialization issues, I don't see the problem. Today inner functions don't create cycles involving local variables. Lexical scoping would change that. > If you want to use weak references, please try to specify *in detail* > which objects would have weak references to which other objects and > how the system would resolve these... I'm never sure that things can > be made 100% safe using this technique, so it may help to spell it out > for me! OK, how's that: inner functions have weak reference to variables in the same scope def f(): x = 1 def g(): pass g would have only a weak reference to "x". I'm changing "no reference" to "weak reference", so I'm not incrementing effective reference counting. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at beopen.com Wed Jul 26 16:44:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 09:44:05 -0500 Subject: [Python-Dev] Product iteration In-Reply-To: Your message of "Wed, 26 Jul 2000 16:33:46 +0300." References: Message-ID: <200007261444.JAA02518@cj20424-a.reston1.va.home.com> > Today inner functions don't create cycles involving local variables. > Lexical scoping would change that. Fair enough. To resolve this, an inner function should only have a reference to the outer function if it actually references the outer function's locals -- which can be determined at compile time. > > If you want to use weak references, please try to specify *in detail* > > which objects would have weak references to which other objects and > > how the system would resolve these... I'm never sure that things can > > be made 100% safe using this technique, so it may help to spell it out > > for me! > > OK, how's that: inner functions have weak reference to variables in the > same scope > > def f(): > x = 1 > def g(): > pass Insert "print x" in the body of g, and "return g" in the body of f. > > g would have only a weak reference to "x". > > I'm changing "no reference" to "weak reference", so I'm not incrementing > effective reference counting. Ehm, I'm always confused by the semantics of weak references (you could say that I haven't a clue about them), so you'd have to do better than this. In any case, in your proposal the weak reference to x would go away when f returns, so if g is exported from f, it breaks! def f(): x = 1 def g(): print x g() return g gee = f() gee() This would first print 1 (the call to g() inside f()) and then raise a NameError (probably a new subclass e.g. UnboundOuterNameError). This behavior is unacceptable, at least to the people who have been clamoring most for this feature (the Schemers): it is expected that x is kept alive as long as g lives. So, try again! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From fdrake at beopen.com Wed Jul 26 15:44:18 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 26 Jul 2000 09:44:18 -0400 (EDT) Subject: [Python-Dev] Sub-package import mechanism now broken? No, but... In-Reply-To: <397EE36F.59615826@per.dem.csiro.au> References: <397EE36F.59615826@per.dem.csiro.au> Message-ID: <14718.60210.729406.658995@cj42289-a.reston1.va.home.com> Mark Favas writes: > Opps - the import mechanism is not broken, it's just that the xml > package in lib/site-packages no longer gets found, because of the new > xml package in lib. This will still break existing code, unless the xml > package in lib is renamed, has the same functionality as the PyXML I expect we'll be making the package in site-packages an extension provider for the xml package in the standard library. I'm planning to discuss this issue at today's PythonLabs meeting. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From moshez at math.huji.ac.il Wed Jul 26 15:56:12 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 26 Jul 2000 16:56:12 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <200007261444.JAA02518@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 26 Jul 2000, Guido van Rossum wrote: > > OK, how's that: inner functions have weak reference to variables in the > > same scope > > > > def f(): > > x = 1 > > def g(): > > pass > > Insert "print x" in the body of g, and "return g" in the body of f. What are you trying to do, simulate classes via closures? I don't see any reason for this to work. However, this should work def powers_of(n): return map(lambda x: n**x, range(10)) > Ehm, I'm always confused by the semantics of weak references (you > could say that I haven't a clue about them), so you'd have to do > better than this. > > In any case, in your proposal the weak reference to x would go away > when f returns, so if g is exported from f, it breaks! Exactly. But breaks cleanly, of course (what yo suggested works great) > This behavior is unacceptable, at least to the people who have been > clamoring most for this feature (the Schemers): it is expected that > x is kept alive as long as g lives. Ummmm....to put it harshly f**k Schemers (I'm speaking as a latent schemer myself, so I can be harsh): I don't want lexical scoping to simulate classes, Python's got a wonderful object system. I want lexical scoping to make the common case of map(lambda) or def _(...): .... map(_, ....) less horrible (IOW, without the lambda x,n=n,y=y,something=other: hack) The only question about lexical scoping is "what are we trying to do?". I'm trying to have a working map(). You (seem to be) trying to simulate objects via closures. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From trentm at activestate.com Wed Jul 26 18:30:24 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 26 Jul 2000 09:30:24 -0700 Subject: [Python-Dev] test_fork1 failing --with-threads (for some people)... In-Reply-To: <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> Message-ID: <20000726093024.C26632@ActiveState.com> On Wed, Jul 26, 2000 at 08:10:40AM +0000, Peter Schneider-Kamp wrote: > I am using a (somewhat modified) SuSE 6.4 distribution > with an old 2.2.13 kernel. > > What does your's look like? > [trentm at molotok ~]$ cat /proc/version Linux version 2.2.12-20smp (root at porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Mon Sep 27 10:34:45 EDT 1999 RedHat dist Trent -- Trent Mick TrentM at ActiveState.com From trentm at ActiveState.com Wed Jul 26 18:32:32 2000 From: trentm at ActiveState.com (Trent Mick) Date: Wed, 26 Jul 2000 09:32:32 -0700 Subject: [Python-Dev] test_fork1.py failing (Summary or failing regression tests...) In-Reply-To: <397E9D3C.9181A0E0@lemburg.com> References: <20000725153912.A21409@ActiveState.com> <397E9D3C.9181A0E0@lemburg.com> Message-ID: <20000726093232.D26632@ActiveState.com> On Wed, Jul 26, 2000 at 10:11:40AM +0200, M . -A . Lemburg wrote: > Trent Mick wrote: > > > > On Linux32: > > - test_fork1 > > This fails/hangs/crashes inconsistently because (some little bird told me) > > the fork stuff and threads are incompatible. Am I right? Now that we are > > turning threads on by default what is the proper thing to do here? SHould > > test_fork1 be changed to skip if threads are enabled? > > Does this mean that a stock Python 1.6/2.0 interpreter will > not properly do fork() on Linux32 (even when using threads) ? > As I said: *some little bird told me*. (I think it was David.) I don't know, Marc-Andre. I am just waving a flag. Ignorantly yours, Trent -- Trent Mick TrentM at ActiveState.com From trentm at activestate.com Wed Jul 26 18:37:26 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 26 Jul 2000 09:37:26 -0700 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <200007260259.OAA09520@s454.cosc.canterbury.ac.nz> References: <20000725110000.C577@ActiveState.com> <200007260259.OAA09520@s454.cosc.canterbury.ac.nz> Message-ID: <20000726093726.E26632@ActiveState.com> On Wed, Jul 26, 2000 at 02:59:14PM +1200, Greg Ewing wrote: > Trent Mick suggested: > > > [for x in [10,20,30]: for y in [1,2,3]: x+y] > > When designing the syntax, I decided to put the target > expression first, because I wanted it to read declaratively. > Also I think it's clearer when you can see right up front > what it's going to be a list *of*. > Yes, I expressed liking someones (MAL's? Skip's?) suggested: [for x in [1,2,3]: x] Over the currently favoured [x for x in [1,2,3]] However, given Tim's response to that thread (list comprehensions are declarative, the important thing is for the synxtax to be memorable after initial familiarity), I am inclined to retract my opinion and support: [x for x in [1,2,3]] and its ilk. Mainly, I don't want to get pulled into the debate. It has been debated and there are too many cooks in the kitchen. Trent -- Trent Mick TrentM at ActiveState.com From nowonder at nowonder.de Wed Jul 26 20:40:07 2000 From: nowonder at nowonder.de (Peter Schneider-Kamp) Date: Wed, 26 Jul 2000 18:40:07 +0000 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> Message-ID: <397F3087.D4E38ED2@nowonder.de> Trent Mick wrote: > > Linux version 2.2.12-20smp (root at porky.devel.redhat.com) (gcc version > egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Mon Sep 27 10:34:45 > EDT 1999 Could SMP be involved? Do you get the same on a non-SMP system? Do others have the same problem with SMP systems? Peter Linux version 2.2.13 (root at mobility) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Fri Mar 3 00:43:36 CET 2000 -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From trentm at activestate.com Wed Jul 26 19:27:13 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 26 Jul 2000 10:27:13 -0700 Subject: [Python-Dev] testing Fredrik's UCN patch on Linux64 (works! :) In-Reply-To: <004801bff68b$6e364280$f2a6b5d4@hagrid> References: <20000725112713.D577@ActiveState.com> <004801bff68b$6e364280$f2a6b5d4@hagrid> Message-ID: <20000726102713.D27257@ActiveState.com> > > - Fredrik had a new, better replacement? Fredrik? > > my patch is here: > http://w1.132.telia.com/~u13208596/uninames-patch.txt > > (it's ~600k, which is more than sourceforge can handle) > > if you have some time to spare, feel tree to try it out on your > favourite 64-bit platform (I haven't had time to test it on our > alphas, but I'm pretty sure it'll work). Happy to try it.... > > the patch doesn't update the build files, so you need to do some > manual tweaking to make sure the unicodenames module is built. > I.e. just slap a unicodenames line in Modules/Setup? [trentm at nickel src]$ ./python Lib/test/test_ucn.py Testing General Unicode Character Name, and case insensitivity... done. Testing misc. symbols for unicode character name expansion.... done. Testing unicode character name expansion strict error handling.... done. [trentm at nickel src]$ ./python Lib/test/regrtest.py test_ucn test_ucn 1 test OK. It works. Do I need to try it on Win64. It is more of a pain to try it there because the Win64 build system is a big f***ing mess. Trent -- Trent Mick TrentM at ActiveState.com From trentm at activestate.com Wed Jul 26 20:04:52 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 26 Jul 2000 11:04:52 -0700 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <397F3087.D4E38ED2@nowonder.de> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> Message-ID: <20000726110452.A27966@ActiveState.com> On Wed, Jul 26, 2000 at 06:40:07PM +0000, Peter Schneider-Kamp wrote: > Trent Mick wrote: > > > > Linux version 2.2.12-20smp (root at porky.devel.redhat.com) (gcc version > > egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Mon Sep 27 10:34:45 > > EDT 1999 > > Could SMP be involved? Do you get the same on a non-SMP system? > Do others have the same problem with SMP systems? > Yup, it looks like that is a possibility. I tried test_fork1 a few times on: [trentm at ladder src]$ cat /proc/version Linux version 2.2.14 (root at ladder.ActiveState.com) (gcc version 2.95.2 19991024 (release)) #1 Mon Mar 6 16:49:17 PST 2000 (a Mandrake box)... and it works fine: [trentm at ladder src]$ ./python Lib/test/test_fork1.py [trentm at ladder src]$ ./python Lib/test/regrtest.py test_fork1 test_fork1 1 test OK. [trentm at ladder src]$ So...... who knows more about SMP issues and why we have them? I am inexperienced and clueless here. Trent -- Trent Mick TrentM at ActiveState.com From klm at digicool.com Wed Jul 26 21:16:31 2000 From: klm at digicool.com (Ken Manheimer) Date: Wed, 26 Jul 2000 15:16:31 -0400 (EDT) Subject: [Python-Dev] PEP202 -- glossary of terms In-Reply-To: <20000726005526.A3796@thyrsus.com> Message-ID: On Wed, 26 Jul 2000, Eric S. Raymond wrote: > functional style: > > Refers to a language in which everything is pure function calls, without > side-effects or variables. Backus's F is one of the better-known > examples. LISP would be functional if there were no (setq ...). Typo, i think: that would probably be "FP". Quite cool language, from the guy also primary in bringing us fortran. > The advantage of functional language is the same as their disadvantage: > no side-effects. Makes them easy to reason about, but you have to jump > through hoops to do statefulness. I think "easy to reason about" in this case is mostly in the line of rigorous mathematic reasoning - algebraic/provability - than it is about approachability for novices/non-mathematicians! My impression is that in functional programming, you use functions to manipulate functions to get results - combinators, which are extremely powerful, expressively and mathematically, are also quite difficult to approach for the uninitiated. (I always thought APL presented similar challenges, but in the medium of programs as arrays/matrices.) I think one big advantage of the procedural style is how much easier it is for people to get what loops do, where applicative (map/reduce/apply) and combinatory logic operators are a lot harder. And list comprehensions as proposed capitalize on the greater approachability of loops. However, i do think a function like zip()/pairwise()/whatever can help for the tricky bit where the loop approach breaks down... (And i would be surprised if jeremy, who was steeped in MIT's scheme-based programming fundamentals curriculum, was asking for definitions. ?) Ken klm at digicool.com From bckfnn at worldonline.dk Wed Jul 26 21:42:29 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Wed, 26 Jul 2000 19:42:29 GMT Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <397f38e5.12750954@smtp.worldonline.dk> CPythons unicode compare function contains some code to compare surrogate characters in code-point order (I think). This is properly a very neat feature but is differs from java's way of comparing strings. Python 2.0b1 (#0, Jul 26 2000, 21:29:11) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> print u'\ue000' < u'\ud800' 1 >>> print ord(u'\ue000') < ord(u'\ud800') 0 >>> Java (and JPython) compares the 16-bit characters numericly which result in: JPython 1.1+08 on java1.3.0 (JIT: null) Copyright (C) 1997-1999 Corporation for National Research Initiatives >>> print u'\ue000' < u'\ud800' 0 >>> print ord(u'\ue000') < ord(u'\ud800') 0 >>> I don't think I can come up with a solution that allow JPython to emulate CPython on this type of comparison. regards, finn From thomas at xs4all.net Wed Jul 26 22:02:17 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 26 Jul 2000 22:02:17 +0200 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: <200007261300.IAA01335@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 26, 2000 at 08:00:33AM -0500 References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> <200007261300.IAA01335@cj20424-a.reston1.va.home.com> Message-ID: <20000726220216.O266@xs4all.nl> On Wed, Jul 26, 2000 at 08:00:33AM -0500, Guido van Rossum wrote: > > is there any special reason why we cannot use colon instead > > of "for"? > Would conflict with the proposed syntax for range literals. Both > > [0:10] > > and > [x : x in seq] > have the same syntactical form. Much, much worse: the latter *is* a range literal. It's not likely to produce anything useful, depending on 'x', but it is a valid range literal. (It'll create a range from 'x' to '0', if 'x' is not in 'seq', or '1', if 'x' is in 'seq', using step 1.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Wed Jul 26 22:50:32 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 26 Jul 2000 22:50:32 +0200 Subject: [Python-Dev] ANSIfication. In-Reply-To: <20000726133002.4D95937186E@snelboot.oratrix.nl>; from jack@oratrix.nl on Wed, Jul 26, 2000 at 03:30:01PM +0200 References: <20000726133002.4D95937186E@snelboot.oratrix.nl> Message-ID: <20000726225032.P266@xs4all.nl> On Wed, Jul 26, 2000 at 03:30:01PM +0200, Jack Jansen wrote: > > Frankly, I think that for *any* functions that are in some external > > library (e.g. libc), Python should never provide a function prototype > > at all. The standard headers should provide the prototypes! > They should, but what if they don't? That's what I like about the > pyport.h: it allows Python to build out of the box but still keeps all the > cruft needed because some platforms don't have their act together in a > single place. I know that I'm not expected to understand sections of > pyport.h that are for platforms I'm not familiar with... That's kind-of what I wrote in my reply to Guido. There is only one problem with this, though, and that's finding platform-identifying #defines. I don't have enough experience with portable software to assume anything, and I unable to find anything identifying the platform on the one Solaris 2.6 box we have (and don't use, because it's Solaris ;) I haven't tried finding any on the Linux or BSDI boxes we do use, but I think Linux glibc2 is recognizable -- but that's also the system most likely to be up to date ! If anyone can give some hints on identifying platforms, or finding out whether a given prototype is included in the header files, please do :P Until then, I don't think we can do much else with the *current* prototypes than remove them. And if anyone needs those #defines, they'll have to figure out how to uniquely identify their architecture, first. Actually... I think it's possible for autoconf to find out if a prototype is included by trying to take the address of a function... but that's kind of a severe method, and doesn't say anything about what the prototype should look like. And is there really any danger of real bugs being caused by missing prototypes ? Most (well, at least *some*) testing is done on Linux systems, on which I have yet to find a prototype missing from the std. include files. It'll generate some warnings on some other operating systems, but that's all, I think. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Wed Jul 26 23:47:12 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 26 Jul 2000 14:47:12 -0700 (PDT) Subject: [Python-Dev] Product iteration In-Reply-To: References: <200007261444.JAA02518@cj20424-a.reston1.va.home.com> Message-ID: <14719.23648.966686.131625@mailhost.beopen.com> Moshe Zadka writes: > On Wed, 26 Jul 2000, Guido van Rossum wrote: > > > > OK, how's that: inner functions have weak reference to variables in the > > > same scope > > > > > > def f(): > > > x = 1 > > > def g(): > > > pass > > > > Insert "print x" in the body of g, and "return g" in the body of f. > > What are you trying to do, simulate classes via closures? I don't see any > reason for this to work. > There's not simulation going on. He's just expecting closures to work. I think that any proposal for changed scoping needs to do lexical scoping properly, including closures. If it doesn't, I vote -1. The argument about finalization is specious. You should not write code that depends on current finalization semantics to do things like closing files. It's relying on an implementation-dependent feature that is not part of the language spec. (Just try it on JPython.) Jeremy From esr at thyrsus.com Thu Jul 27 00:09:59 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 26 Jul 2000 18:09:59 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <14719.23648.966686.131625@mailhost.beopen.com>; from jeremy@beopen.com on Wed, Jul 26, 2000 at 02:47:12PM -0700 References: <200007261444.JAA02518@cj20424-a.reston1.va.home.com> <14719.23648.966686.131625@mailhost.beopen.com> Message-ID: <20000726180959.A6654@thyrsus.com> Jeremy Hylton : > The argument about finalization is specious. You should not write > code that depends on current finalization semantics to do things like > closing files. It's relying on an implementation-dependent feature > that is not part of the language spec. (Just try it on JPython.) I strongly agree. -- Eric S. Raymond Morality is always the product of terror; its chains and strait-waistcoats are fashioned by those who dare not trust others, because they dare not trust themselves, to walk in liberty. -- Aldous Huxley From trentm at ActiveState.com Thu Jul 27 01:01:57 2000 From: trentm at ActiveState.com (Trent Mick) Date: Wed, 26 Jul 2000 16:01:57 -0700 Subject: [Python-Dev] Re: C testing framework In-Reply-To: <14717.55286.1741.361478@beluga.mojam.com> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> <14717.34372.437370.172614@beluga.mojam.com> <20000725103736.B577@ActiveState.com> <14717.55286.1741.361478@beluga.mojam.com> Message-ID: <20000726160157.A26692@ActiveState.com> On Tue, Jul 25, 2000 at 01:09:58PM -0500, Skip Montanaro wrote: > > [c-based testing framework] > > Trent> Show it? PEP it? Forget it? > > I say show it. I see no reason to make a PEP unless there are a number of > potential immediate alternatives. It doesn't affect the functionality of > the distribution, only its quality. If something better comes along later, > Trent's can be replaced. Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp Patch: *** /home/trentm/main/contrib/python/dist/src/Lib/test/test_capi.py Wed Jul 26 15:39:35 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/Lib/test/test_capi.py Wed Jul 26 10:37:31 2000 *************** *** 0 **** --- 1,17 ---- + import sys + import test_support + import _test + + # import and run the _test module tests (tests for the Python/C API) + # + # (any exported function beginning with 'test_') + + for name in dir(_test): + if name.startswith('test_'): + test = getattr(_test, name) + if test_support.verbose: + print "internal", name + try: + test() + except _test.error: + raise test_support.TestFailed, sys.exc_info()[1] *** /home/trentm/main/contrib/python/dist/src/Lib/test/output/test_capi Wed Jul 26 15:39:35 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/Lib/test/output/test_capi Wed Jul 26 10:36:37 2000 *************** *** 0 **** --- 1 ---- + test_capi *** /home/trentm/main/contrib/python/dist/src/Modules/_testmodule.c Wed Jul 26 15:39:35 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/Modules/_testmodule.c Wed Jul 26 15:39:31 2000 *************** *** 0 **** --- 1,64 ---- + //--------------------------------------------------------------------------- + // C Extension module to test Python interpreter C APIs. + // + // The 'test_*' functions exprted by this module are run as part of + // the standard Python regression test (via test_capi.py). + //--------------------------------------------------------------------------- + + #include "Python.h" + #include "marshal.h" + + #define TEST_FILENAME "__test_filename" // filename used for testing + + PyObject *TestError; + + + /* test defines from config.h (particularly the SIZEOF_* defines) + + The ones derived from autoconf on the UNIX-like OSes can be relied + upon, but the Microsoft platform have these hardcoded. Better safe + than sorry. + */ + PyObject* + test_config(PyObject *self, PyObject *args) + { + /*XXX could probably break these out to allow the error message to be + * better, as well could test more config.h settings */ + if (SIZEOF_INT != sizeof(int) || + SIZEOF_LONG != sizeof(long) || + #ifdef HAVE_LONG_LONG + SIZEOF_LONG_LONG != sizeof(LONG_LONG) || + #endif + SIZEOF_VOID_P != sizeof(void*) || + SIZEOF_TIME_T != sizeof(time_t)) { + PyErr_SetString(TestError, + "SIZEOF_* configuration defines are not all correct"); + return NULL; + } + + Py_INCREF(Py_None); + return Py_None; + } + + + + + /* must defined special structure to define methods and attributes to Python */ + static PyMethodDef TestMethods[] = { + {"test_config", test_config, METH_VARARGS}, + {NULL, NULL} /* sentinel */ + }; + + + /* must define intialization function, often 'init' */ + DL_EXPORT(void) + init_test(void) + { + PyObject *m, *d; + + m = Py_InitModule("_test", TestMethods); + + TestError = PyErr_NewException("_test.error", NULL, NULL); + d = PyModule_GetDict(m); + PyDict_SetItemString(d, "error", TestError); + } *** /home/trentm/main/contrib/python/dist/src/Modules/Setup.in Fri Jun 30 09:05:22 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/Modules/Setup.in Wed Jul 26 14:30:37 2000 *************** *** 426,431 **** --- 426,436 ---- #EXPAT_DIR=/usr/local/src/expat #pyexpat pyexpat.c -I$(EXPAT_DIR)/xmlparse -L$(EXPAT_DIR) -lexpat + # internal C API testing module (tests exprted by this module are + # called as part of the test suite) + *shared* + _test _testmodule.c + *static* # Example -- included for reference only: # xx xxmodule.c *** /home/trentm/main/contrib/python/dist/src/PCbuild/_test.dsp Wed Jul 26 15:39:35 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/PCbuild/_test.dsp Wed Jul 26 14:30:03 2000 *************** *** 0 **** --- 1,100 ---- + # Microsoft Developer Studio Project File - Name="_test" - Package Owner=<4> + # Microsoft Developer Studio Generated Build File, Format Version 6.00 + # ** DO NOT EDIT ** + + # TARGTYPE "Win32 (x86) Dynamic-Link Library" 0x0102 + + CFG=_test - Win32 Debug + !MESSAGE This is not a valid makefile. To build this project using NMAKE, + !MESSAGE use the Export Makefile command and run + !MESSAGE + !MESSAGE NMAKE /f "_test.mak". + !MESSAGE + !MESSAGE You can specify a configuration when running NMAKE + !MESSAGE by defining the macro CFG on the command line. For example: + !MESSAGE + !MESSAGE NMAKE /f "_test.mak" CFG="_test - Win32 Debug" + !MESSAGE + !MESSAGE Possible choices for configuration are: + !MESSAGE + !MESSAGE "_test - Win32 Release" (based on "Win32 (x86) Dynamic-Link Library") + !MESSAGE "_test - Win32 Debug" (based on "Win32 (x86) Dynamic-Link Library") + !MESSAGE + + # Begin Project + # PROP AllowPerConfigDependencies 0 + # PROP Scc_ProjName "" + # PROP Scc_LocalPath "" + CPP=cl.exe + MTL=midl.exe + RSC=rc.exe + + !IF "$(CFG)" == "_test - Win32 Release" + + # PROP BASE Use_MFC 0 + # PROP BASE Use_Debug_Libraries 0 + # PROP BASE Output_Dir "Release" + # PROP BASE Intermediate_Dir "Release" + # PROP BASE Target_Dir "" + # PROP Use_MFC 0 + # PROP Use_Debug_Libraries 0 + # PROP Output_Dir "." + # PROP Intermediate_Dir "x86-temp-release\_test" + # PROP Ignore_Export_Lib 0 + # PROP Target_Dir "" + F90=df.exe + # ADD BASE CPP /nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_TEST_EXPORTS" /YX /FD /c + # ADD CPP /nologo /MD /W3 /GX /Zi /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /YX /FD /c + # ADD BASE MTL /nologo /D "NDEBUG" /mktyplib203 /win32 + # ADD MTL /nologo /D "NDEBUG" /mktyplib203 /win32 + # ADD BASE RSC /l 0x409 /d "NDEBUG" + # ADD RSC /l 0x409 /d "NDEBUG" + BSC32=bscmake.exe + # ADD BASE BSC32 /nologo + # ADD BSC32 /nologo + LINK32=link.exe + # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 + # ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /out:"./_test.pyd" /export:init_test + # SUBTRACT LINK32 /pdb:none + + !ELSEIF "$(CFG)" == "_test - Win32 Debug" + + # PROP BASE Use_MFC 0 + # PROP BASE Use_Debug_Libraries 1 + # PROP BASE Output_Dir "Debug" + # PROP BASE Intermediate_Dir "Debug" + # PROP BASE Target_Dir "" + # PROP Use_MFC 0 + # PROP Use_Debug_Libraries 1 + # PROP Output_Dir "." + # PROP Intermediate_Dir "x86-temp-debug\_test" + # PROP Ignore_Export_Lib 0 + # PROP Target_Dir "" + F90=df.exe + # ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_TEST_EXPORTS" /YX /FD /GZ /c + # ADD CPP /nologo /MDd /W3 /Gm /GX /Zi /Od /I "..\Include" /I "..\PC" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /YX /FD /GZ /c + # ADD BASE MTL /nologo /D "_DEBUG" /mktyplib203 /win32 + # ADD MTL /nologo /D "_DEBUG" /mktyplib203 /o "NUL" /win32 + # ADD BASE RSC /l 0x409 /d "_DEBUG" + # ADD RSC /l 0x409 /d "_DEBUG" + BSC32=bscmake.exe + # ADD BASE BSC32 /nologo + # ADD BSC32 /nologo + LINK32=link.exe + # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept + # ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /out:"./_test_d.pyd" /pdbtype:sept /export:init_test + # SUBTRACT LINK32 /pdb:none + + !ENDIF + + # Begin Target + + # Name "_test - Win32 Release" + # Name "_test - Win32 Debug" + # Begin Source File + + SOURCE=..\Modules\_testmodule.c + # ADD CPP /I "..\Include" /I "..\PC" + # End Source File + # End Target + # End Project *** /home/trentm/main/contrib/python/dist/src/PCbuild/pcbuild.dsw Wed Jul 26 15:10:27 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/PCbuild/pcbuild.dsw Wed Jul 26 15:13:22 2000 *************** *** 33,38 **** --- 33,53 ---- ############################################################################### + Project: "_test"=".\_test.dsp" - Package Owner=<4> + + Package=<5> + {{{ + }}} + + Package=<4> + {{{ + Begin Project Dependency + Project_Dep_Name python20 + End Project Dependency + }}} + + ############################################################################### + Project: "_tkinter"=".\_tkinter.dsp" - Package Owner=<4> Package=<5> -- Trent Mick TrentM at ActiveState.com From guido at beopen.com Thu Jul 27 02:38:55 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 19:38:55 -0500 Subject: [Python-Dev] The State of Python Message-ID: <200007270038.TAA03951@cj20424-a.reston1.va.home.com> I've placed the slides of my talk at the O'Reilly Open Source Convention on-line at our BeOpen PythonLabs website: http://www.pythonlabs.com/talks.html We're also very close to announcing news regarding a new Python license, Python 1.6 and 2.0 release schedules, and a transition of the python.org website to hosting by VA Linux. The announcement is waiting for final negotiations about GPL compatibility of the new license; BeOpen's CTO, Bob Weiner, is confident that the issue will be resolved one way or another by Friday. A preview of what we will announce: - A new license for Python 1.6 and later: the "CNRI Open Source License", approved by the Open Source Initiative; - Release plans for Python 1.6: the last CNRI release, to be issued with help from BeOpen; - Release plans for Python 2.0: the first release to be issued by BeOpen; - A transition for the python.org website: it will be hosted by VA Linux (home of SourceForge), under supervision of the Python Consortium and myself, maintained by the Python community. Please hold your breath a little longer! A re-release of JPython using the CNRI Open Source License is possible a little later, pending further negotiations with CNRI. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From m.favas at per.dem.csiro.au Thu Jul 27 03:22:36 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Thu, 27 Jul 2000 09:22:36 +0800 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs machine with >= 32bit longs References: <20000725112713.D577@ActiveState.com> <004801bff68b$6e364280$f2a6b5d4@hagrid> Message-ID: <397F8EDC.328DDF1C@per.dem.csiro.au> Fredrik Lundh wrote: > > trent wrote: > > I was assigned this patch a while back to try on some 64-bit systems. Fine, I > > can do that but I have since seen a number of message on python-dev regarding > > it: > > > > - Fredrik had a new, better replacement? Fredrik? > > my patch is here: > http://w1.132.telia.com/~u13208596/uninames-patch.txt > > (it's ~600k, which is more than sourceforge can handle) > > if you have some time to spare, feel tree to try it out on your > favourite 64-bit platform (I haven't had time to test it on our > alphas, but I'm pretty sure it'll work). > > the patch doesn't update the build files, so you need to do some > manual tweaking to make sure the unicodenames module is built. > > if everything works as it should, the resulting interpreter should > survive test_ucn.py even if ucnhash.pyd (.so) is nowhere to be > seen... > > I've just tried /F's patch on my Alpha (Tru64 Unix, V4.0F), and everything seems fine - compiles, passes test_ucn (and the rest). -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From jeremy at beopen.com Thu Jul 27 05:07:02 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 26 Jul 2000 23:07:02 -0400 (EDT) Subject: [Python-Dev] failures in the regression tests Message-ID: <14719.42838.895374.783407@bitdiddle.concentric.net> I am trying to keep track of failures in the regression test suite. At the moment, all the available tests work correctly on my Linux box. I understand there are still problems with test_fork1 on some SMP Linux boxes. (I believe this error has been around for many months.) And that the test_winreg and test_winreg32 tests are failing on Windows builds. If you are aware of any other tests that are failing, please let me know. (Preferably by private email.) We need to get the tests fixed quickly. As I write in PEP 200 (Python 2.0 release schedule): >Failing test cases need to get fixed > > We need to resolve errors in the regression test suite quickly. > Changes should not be committed to the CVS tree unless the > regression test runs cleanly with the changes applied. If it > fails, there may be bugs lurking in the code. (There may be bugs > anyway, but that's another matter.) If the test cases are known > to fail, they serve no useful purpose. Jeremy From fdrake at beopen.com Thu Jul 27 05:05:21 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 26 Jul 2000 23:05:21 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <397F3087.D4E38ED2@nowonder.de> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> Message-ID: <14719.42737.305992.235671@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > Could SMP be involved? Do you get the same on a non-SMP system? > Do others have the same problem with SMP systems? I mentioned the possibility at our PythonLabs meeting today that this may be related; when I observed problems with test_fork1, it was on an SMP linux box running Mandrake 7.0 with the stock SMP kernel. I have *not* seen the problem pop up on the uniprocessor I have now. I think Barry may have access to an SMP Sparc machine; if so, we'll be checking it out there. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jul 27 05:09:39 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 26 Jul 2000 23:09:39 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <20000726110452.A27966@ActiveState.com> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> <20000726110452.A27966@ActiveState.com> Message-ID: <14719.42995.823876.5177@cj42289-a.reston1.va.home.com> Trent Mick writes: > So...... who knows more about SMP issues and why we have them? I am > inexperienced and clueless here. Another possible issue is that at one point configure was using GNU Pth instead of LinuxThreads by default. Since Pth is fairly young, there may be issues there as well. Pth is no longer preferred over LinuxThreads. For non-Linux users: LinuxThreads is the default pthreads implementation on Linux, and GNU Pth is a new "portable" implementation that I understand is very young and unstable. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Thu Jul 27 05:23:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 26 Jul 2000 23:23:52 -0400 Subject: [Python-Dev] failures in the regression tests In-Reply-To: <14719.42838.895374.783407@bitdiddle.concentric.net> Message-ID: On Win98, with the CVS version as of 11:15pm EDT, in both debug and release builds: 59 tests OK. 3 tests failed: test_mmap test_winreg test_winreg2 26 tests skipped: test_al test_bsddb test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_grp test_gzip test_imgfile test_li nuxaudiodev test_minidom test_nis test_openpty test_popen2 test_pty test_pwd tes t_pyexpat test_signal test_sunaudiodev test_timing test_zlib Seems odd that test_popen2 is still being skipped (I thought we were fixing popen & friends under Windows, but lost track of that). > ... > If you are aware of any other tests that are failing, please let me > know. (Preferably by private email.) Like I'm going to trust you to keep Windows details straight . From thomas at xs4all.net Thu Jul 27 06:04:42 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 06:04:42 +0200 Subject: [Python-Dev] test_fork1 on SMP? In-Reply-To: <14719.42737.305992.235671@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Wed, Jul 26, 2000 at 11:05:21PM -0400 References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> <14719.42737.305992.235671@cj42289-a.reston1.va.home.com> Message-ID: <20000727060442.Q266@xs4all.nl> On Wed, Jul 26, 2000 at 11:05:21PM -0400, Fred L. Drake, Jr. wrote: > > Peter Schneider-Kamp writes: > > Could SMP be involved? Do you get the same on a non-SMP system? > > Do others have the same problem with SMP systems? > I think Barry may have access to an SMP Sparc machine; if so, we'll > be checking it out there. I have also seen test_fork1 failures on BSDI, using a SMP machine, but I haven't tried it on non-SMP (we don't have too many of those). However, all our BSDI kernels are the same, having been built for SMP. Meetings permitting (which is doubtful, today :-() I'll see if I can pin that down. It would, however, be fairly peculiar if test_fork1 breaks on all SMP-supporting systems... I don't really recall a reason for thread semantics to change reliably based on kernel/cpu settings, and it would be silly for them to do so! But I'll admit threads are silly, period ;-) 6-AM-and-preparing-for-a-full-10-hour-day-of-meetings-:-S-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Thu Jul 27 06:32:02 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 00:32:02 -0400 Subject: [Python-Dev] test_fork1 on SMP? In-Reply-To: <20000727060442.Q266@xs4all.nl> Message-ID: [Thomas Wouters] > I have also seen test_fork1 failures on BSDI, using a SMP machine, but > I haven't tried it on non-SMP (we don't have too many of those). > However, all our BSDI kernels are the same, having been built for SMP. > Meetings permitting (which is doubtful, today :-() I'll see if I can > pin that down. > > It would, however, be fairly peculiar if test_fork1 breaks on all > SMP-supporting systems... I don't really recall a reason for thread > semantics to change reliably based on kernel/cpu settings, and it would > be silly for them to do so! But I'll admit threads are silly, period ;-) Silly? Without threads your clothes would fall off . I wonder whether the "fork" part is a red herring here. It's extremely rare to see a thread bug that actually requires a multi-headed machine to trigger (in fact, I don't believe I've ever seen one), but the nature of races in flawed threaded code is often such that you're a million times more *likely* to hit a bad timing window on a multi-headed machine than on a time-sliced single-headed box. And this is particularly true under operating systems that are reluctant to switch threads on a singled-headed box. For example, 1.5.2's dreaded invalid_tstate bug had never been reported on a single-headed box until I spent several *hours* hand-crafting an extreme test case to provoke it on one (and that was after I was sure I had located the timing hole "by thought", so knew exactly what I needed to do to trigger it -- 'twas very hard to provoke it on a one-headed box even then!). > 6-AM-and-preparing-for-a-full-10-hour-day-of-meetings-:-S-ly y'rs, So long as you still put in your 18 hours on Python today, we're happy to let you engage in all the recreational activities you like . generously y'rs - tim From moshez at math.huji.ac.il Thu Jul 27 06:39:54 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 27 Jul 2000 07:39:54 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <14719.23648.966686.131625@mailhost.beopen.com> Message-ID: On Wed, 26 Jul 2000, Jeremy Hylton wrote: > The argument about finalization is specious. You should not write > code that depends on current finalization semantics to do things like > closing files. It's relying on an implementation-dependent feature > that is not part of the language spec. (Just try it on JPython.) I know, and I'm not. But the thing is, there are plenty of users of CPython which do rely on this feature -- so you're going to break people's code. Not nice. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mhammond at skippinet.com.au Thu Jul 27 06:47:07 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu, 27 Jul 2000 14:47:07 +1000 Subject: [Python-Dev] Product iteration In-Reply-To: Message-ID: > I know, and I'm not. But the thing is, there are plenty of users of > CPython which do rely on this feature -- so you're going to break > people's code. Not nice. No - we will simply be pointing out their already broken code. We arent breaking anything! I have no problem with this at all. The sooner we point out the broken code the better. The last thing we want is for obviously and documented broken code to suddenly be considered non-broken simply by the volume of poor code out there... Either way, I think you are overstating the problem. The main scenario is closing resources, and for most users these are unlikely to be so scarce that delaying their finalization will cause problems. If someone is writing a web-server, for example, and assumes that files or sockets are automatically closed, and they open them at such a rate that true GC causes them a problem, then IMO they have got what they deserve ;-) Mark. From bwarsaw at beopen.com Thu Jul 27 06:58:00 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 27 Jul 2000 00:58:00 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> <14719.42737.305992.235671@cj42289-a.reston1.va.home.com> Message-ID: <14719.49496.935765.730596@anthem.concentric.net> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> Barry may have access to an SMP Sparc machine; if so, we'll Fred> be checking it out there. I thought I did, but nope, it's a single processor. What about SF? -Barry From guido at beopen.com Thu Jul 27 07:59:15 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 00:59:15 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Tue, 25 Jul 2000 23:03:23 +0200." <20000725230322.N266@xs4all.nl> References: <20000725230322.N266@xs4all.nl> Message-ID: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> I've been thinking a bit about this myself, and I think it's good idea to show the bytecodes generated for the various cases, just to make sure that we understand the semantics. I'll just use +=, but the same list applies to all 11 binary operators (**, *, /, %, +, -, |, &, ^, <<, >>). I'm making up opcodes -- the different variants of LOAD and STORE don't matter. On the right I'm displaying the stack contents after execution of the opcode (push appends to the end). I'm writing 'result' to indicate the result of the += operator. a += b LOAD a [a] LOAD b [a, b] AUGADD [result] STORE a [] a.attr += b LOAD a [a] DUP [a, a] GETATTR 'attr' [a, a.attr] LOAD b [a, a.attr, b] AUGADD [a, result] SETATTR 'attr' [] a[i] += b LOAD a [a] DUP [a, a] LOAD i [a, a, i] DUP [a, a, i, i] ROT3 [a, i, a, i] GETITEM [a, i, a[i]] LOAD b [a, i, a[i], b] AUGADD [a, i, result] SETITEM [] I'm leaving the slice variant out; I'll get to that in a minute. If the right hand side is more complicated than in the example, the line 'LOAD b' is simply replaced by code that calculates the value of the expression; this always ends up eventually pushing a single value onto the stack, leaving anything below it alone, just like the 'LOAD b' opcode. Ditto for the index expression ('i' in the example). Similarly, for the cases a.attr and a[i], if instead of a there's a more complicated expression (e.g. sys.modules[name].foo().bar += 1) the initial 'LOAD a' is replaced by code that loads the object on the stack -- in this example, sys.modules[name].foo(). Only the final selector (".attr", "[i]") is special. (Terminology: a selector is something that addresses a possibly writable component of a container object, e.g. a[i] or a.attr; a[i:j] is also a selector. f() could be seen as a selector but cannot be used on the left hand side of an assignment.) There are two more forms of potential interest. First, what should happen to a tuple assignment? a, b, c += x (Which is exactly the same as "(a, b, c) += x".) I think this should be a compile-time error. If t and u are tuples, "t += u" means the same as "t = t+u"; but if we apply this rule we would get "(a, b, c) = (a, b, c) + u", which is only valid if u is an empty tuple (or a class instance with unusual coercion behavior). But when u is empty, it's not useful (nothing changes), so it's unlikely that someone would have this intention. More likely, the programmer was hoping that this would be the same as "a+=x; b+=x; c+=x" -- but that's the same misconception as expecting "a, b, c = 0" to mean "a = b = c = 0" so we don't need to cater to it. Second, what should happen to a slice assignment? The basic slice form is: a[i:j] += b but there are others: Python's slice syntax allows an arbitrary comma-separated sequence of single indexes, regular slices (lo:hi), extended slices (lo:hi:step), and "ellipsis" tokens ('...') between the square brackets. Here's an extreme example: a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] += 1 First, let me indicate what code is generated for such a form when it's used in a regular expression or assignment. Any such form *except* basic slices (a[i:j], a[:j], a[i:], and a[:]) is translated into code that uses GETITEM or SETITEM with an index that is formed from a simple translation of the actual expressions. - If there are two or more comma-separated values, the index is a tuple of the translations of the individual values. - An ellipsis ("...") is translated into the builtin object Ellipsis. - A non-slice is translated into itself. - A slice is translated into a "slice object", this is a built-in object representing the lower and upper bounds and step. There is also a built-in function, slice(), taking 1-3 arguments in the same way as range(). Thus: - "lo:hi" is equivalent to slice(lo, hi); - "lo:hi:step" is equivalent to slice(lo, hi, step); - omitted values are replaced with None, so e.g. ":hi" is equivalent to slice(None, hi). So, the extreme example above means exactly the same as a[x], where x is a tuple with the following items: slice(None, None) Ellipsis slice(None, None, None) slice(0, 10, 2) slice(None, 10, None) 1 slice(2, None) slice(None, None, -1) Why all this elaboration? Because I want to use this to give a standardized semantics even to basic slices. If a[lo:hi:step] is translated the same as a[slice(lo, hi, step)], then we can give a[lo:hi] the same translation as a[slice(lo, hi)], and thus the slice case for augmented assignment can generate the same code (apart from the slice-building operations) as the index case. Thus (writing 'slice' to indicate the slice object built from i and j): a[i:j] += b LOAD a [a] DUP [a, a] LOAD i [a, a, i] ** LOAD j [a, a, i, j] ** BUILD_SLICE 2 [a, a, slice] ** DUP [a, a, slice, slice] ROT3 [a, slice, a, slice] GETITEM [a, slice, a[slice]] LOAD b [a, slice, a[slice], b] AUGADD [a, slice, result] SETITEM [] Comparing this to the code for "a[i] += b", only the three lines marked with ** are really different, and all that these do is to push a single object representing the slice onto the stack. I won't show the code for "a[i:j:k] += b" or for "a[i:j, k:l]", but it's clear how these should be done. Postscript (unrelated to augmented assignment) It would be nice if the SLICE bytecodes were removed altogether and instead slice() objects would be created for all slices, even basic ones. (I believe this was proposed in this list at some point.) The original SLICE opcodes were introduced in ancient times, when basic slices were the only accepted slice syntax. This would mean that all objects supporting slices would have to support the *mapping* interface instead of (or in addition to) the sequence interface; the mapping interface would have to determine whether a getitem / setitem call was really a slice call and do the right thing. In particular, for backward compatibility, class instances could have a mapping interface whose internal getitem function checks if the argument is a slice object whose step is None and whose lo and hi are None or integers; then if a __getslice__ method exists, it could call that, in all other cases it could call __getitem__. None of the other built-in objects that support slices would have to be changed; the GETITEM opcode could notice that an object supports the sequence interface but not the mapping interface, and then look for a basic slice or an integer and do the right thing. Problems with this are mostly related to the existing C API for slices, like PySequence_GetSlice(), which propagate the various restrictions. Too-much-rambling-reduces-the-chance-of-useful-responses-ly, --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From bwarsaw at beopen.com Thu Jul 27 07:01:38 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 27 Jul 2000 01:01:38 -0400 (EDT) Subject: [Python-Dev] Product iteration References: <14719.23648.966686.131625@mailhost.beopen.com> Message-ID: <14719.49714.427661.775934@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I know, and I'm not. But the thing is, there are plenty of MZ> users of CPython which do rely on this feature -- so you're MZ> going to break people's code. Not nice. Nope, the code is already broken. They just don't know it yet. -Barry From moshez at math.huji.ac.il Thu Jul 27 07:06:00 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 27 Jul 2000 08:06:00 +0300 (IDT) Subject: [Python-Dev] was Re: Type inference now simplicity (fwd) Message-ID: I think most of the people here aren't reading c.l.py, so here are some feelings from "the community" -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez ---------- Forwarded message ---------- Date: Wed, 26 Jul 2000 21:14:34 GMT From: Shae Erisson To: python-list at python.org Newsgroups: comp.lang.python Subject: was Re: Type inference now simplicity Neil Hodgson wrote: > I found this article quite depressing. One of the effects of .NET appears > to be the homogenisation of programming languages. When the platform > emphasises compilation, compiler helpful warts like variable declaration and > "option fast" start appearing. There is a place for languages with optional > typing but there is also a place for a language that tries to stay very > simple. > > VB has been on a long journey of complexification which has been great > for many but has left some people behind. One of my mates works as a > manager/bureaucrat - programming isn't a significant part of his job but > over the years he's been able to write bits of dBase, Excel macros and HTML > with embedded JavaScript. Excel moved from a simple macro language to a > simplified VB variant (OK, so far) to using full VB (getting worse) and then > VB starts gaining C++ features (bad). So this bloke has stopped programming > in Excel - just too hard now. Adding 'programming in the large' features > appears good to help the more advanced users but it introduces unwanted > complexity for others. JavaScript was the last refuge of simplicity but now > Microsoft (and Netscape) are moving it into the same zone as Python, VB and > C#. I expect a new simple language will appear, gain some users and then > embark on the same journey to complexity. I agree with this. With Python, I'm opposed to the idea of adding autoincrement operators like += etc. I'm opposed to adding the extra for loop stuff like "for [x,y,z] in [a,b,c]." And I'm opposed to it because it seems like sugar to me. I've always loved Python's simplicity, and I hope it stays that way. Adding new operators and new syntax will make Python harder to read, and harder to learn. I don't want that. Simplicity always seems to improve things. Usually, I can improve by removing rather than adding. Concepts like WikiWiki, Refactoring, etc. appeal to me tremendously. -- Shae Matijs Erisson - http://www.webwitches.com/~shae/ VirtualPairProgramming Wanted - Linux/Emacs/Python/Speak Freely .fi: rakastan ohjelmointia - python kengitt?? aasia -- http://www.python.org/mailman/listinfo/python-list From guido at beopen.com Thu Jul 27 08:11:28 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 01:11:28 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 00:59:15 EST." <200007270559.AAA04753@cj20424-a.reston1.va.home.com> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> Message-ID: <200007270611.BAA04802@cj20424-a.reston1.va.home.com> I should add something about the assumed pseudo thread-safety of a+=b. I think this assumption is bogus, since we have to load a, do some stuff, and then store a, and we can't guarantee that the stuff we do is atomic -- in face we *know* it's not if it involves a user-defined method. Simply put: a += 1 IS NOT ATOMIC! Note that C doesn't guarantee that a++ is atomic either, even if a is declared volatile. (I believe there's an atomic data type, but I don't think it guarantees atomic ++. That would be very expensive because the VM cache would have to be flushed on multiprocessor machines. The only docs I found are at http://www.gnu.org/manual/glibc-2.0.6/html_node/libc_365.html.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From tim_one at email.msn.com Thu Jul 27 07:17:03 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 01:17:03 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <14719.49496.935765.730596@anthem.concentric.net> Message-ID: > >>>>> "Fred" == Fred L Drake, Jr writes: > > Fred> Barry may have access to an SMP Sparc machine; if so, we'll > Fred> be checking it out there. [Barry] > I thought I did, but nope, it's a single processor. What about SF? In parallel, could someone summarize the symptoms? Exactly how does it fail? Does it fail the same way across all platforms on which it does fail? Does it fail every time on all platforms on which it fails, or fail only some of the time on all platforms on which it fails, or fails some of the time on some of the platforms on which it fails but fails all of the time on the rest of the platforms on which it fails ? If there exists a platform on which it fails but it doesn't fail every time on that platform, that would be strong evidence of a timing hole. Those usually require thought to identify and repair. I'll voluteer to eyeball the code and do some thinking, but not unless the symptoms suggest that's worthwhile. ignorantly y'rs - tim From thomas at xs4all.net Thu Jul 27 09:21:44 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 09:21:44 +0200 Subject: [Python-Dev] test_fork1 on SMP? In-Reply-To: ; from tim_one@email.msn.com on Thu, Jul 27, 2000 at 12:32:02AM -0400 References: <20000727060442.Q266@xs4all.nl> Message-ID: <20000727092144.R266@xs4all.nl> On Thu, Jul 27, 2000 at 12:32:02AM -0400, Tim Peters wrote: > [Thomas Wouters] > > I have also seen test_fork1 failures on BSDI, using a SMP machine, but > > I haven't tried it on non-SMP (we don't have too many of those). > > However, all our BSDI kernels are the same, having been built for SMP. > > Meetings permitting (which is doubtful, today :-() I'll see if I can > > pin that down. > > > > It would, however, be fairly peculiar if test_fork1 breaks on all > > SMP-supporting systems... I don't really recall a reason for thread > > semantics to change reliably based on kernel/cpu settings, and it would > > be silly for them to do so! But I'll admit threads are silly, period ;-) > Silly? Without threads your clothes would fall off . Clothes ? What clothes ? I'm stuck in meetings all day, remember, and those require a suit and tie. And I have suit nor tie ;) > I wonder whether the "fork" part is a red herring here. It's extremely rare > to see a thread bug that actually requires a multi-headed machine to trigger > (in fact, I don't believe I've ever seen one), but the nature of races in > flawed threaded code is often such that you're a million times more *likely* > to hit a bad timing window on a multi-headed machine than on a time-sliced > single-headed box. Actually, I got the impression the 'bug' wasn't only present on multi-headed Linux machines with an SMP kernel, but single-headed Linux machines with an SMP kernel as well. You see, in Linux, the extra logic required for SMP is optional, at compile time. It changes a lot in the scheduler, but I'm not sure if it should be visible from outside. I haven't actually tested it on a UP machine with SMP kernel, though. And anyway, I thought the test_fork1 test tested for fork() behaviour in threads. It spawns a thread, fork()s one of those threads, and tests to see if the other threads still exist after the fork(), in the new child. The entire test is done in Python code, so how the scheduler and/or race conditions come into play isn't too obvious to me. Except of course the whole test if flawed. > > 6-AM-and-preparing-for-a-full-10-hour-day-of-meetings-:-S-ly y'rs, > So long as you still put in your 18 hours on Python today, we're happy to > let you engage in all the recreational activities you like . I'll clock the hours I spend thinking about Python in those meetings, so not to worry ;) Dreaming-Python-makes-it-24h-a-day-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Thu Jul 27 09:32:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 09:32:42 +0200 Subject: [Python-Dev] Product iteration References: Message-ID: <005f01bff79c$daa0e6c0$f2a6b5d4@hagrid> moshe wrote: > On Wed, 26 Jul 2000, Jeremy Hylton wrote: > > > The argument about finalization is specious. You should not write > > code that depends on current finalization semantics to do things like > > closing files. It's relying on an implementation-dependent feature > > that is not part of the language spec. (Just try it on JPython.) > > I know, and I'm not. But the thing is, there are plenty of users of > CPython which do rely on this feature -- so you're going to break > people's code. Not nice. one problem is that there are many places when you don't know if you can close the file or not -- whoever handed you the file handle might expect it to remain open after you've done with it. That's why people use stuff like: self.fp = None # close if I'm the last user ::: But wouldn't fp = fopen(...); if (!fp && (errno == EMFILE || errno == ENFILE)) { py_force_gc(); fp = fopen(...); } solve this, at least for simple scripts? From effbot at telia.com Thu Jul 27 09:39:40 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 09:39:40 +0200 Subject: [Python-Dev] failures in the regression tests References: Message-ID: <007b01bff79d$d3f5f120$f2a6b5d4@hagrid> tim wrote: > Seems odd that test_popen2 is still being skipped (I thought we were fixing > popen & friends under Windows, but lost track of that). well, didn't you volunteer to fix the last few things for Win9X? ;-) (the w9xpopen.exe needs to be built and installed in the proper place, but I'm using VC5 and would really prefer if someone with VC6 took care of that...) From effbot at telia.com Thu Jul 27 09:44:30 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 09:44:30 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> Message-ID: <008301bff79e$806d3f80$f2a6b5d4@hagrid> finn bock wrote: > Java (and JPython) compares the 16-bit characters numericly which result in: > > JPython 1.1+08 on java1.3.0 (JIT: null) > Copyright (C) 1997-1999 Corporation for National Research Initiatives > >>> print u'\ue000' < u'\ud800' > 0 > >>> print ord(u'\ue000') < ord(u'\ud800') > 0 > >>> > > I don't think I can come up with a solution that allow JPython to emulate > CPython on this type of comparison. since we don't really support surrogates (or anything else related to 32-bit unicode) anywhere else, I'd rather change CPython to emulate JPython here. (just #ifdef out the neat stuff, and don't switch it on again before we've sorted all other 32-bit unicode issues...) From effbot at telia.com Thu Jul 27 09:53:52 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 09:53:52 +0200 Subject: [Python-Dev] failures in the regression tests References: Message-ID: <009d01bff79f$d0b5cf60$f2a6b5d4@hagrid> tim wrote: > Seems odd that test_popen2 is still being skipped (I thought we were fixing > popen & friends under Windows, but lost track of that). umm. looks like I forgot to check in my test_popen2.py changes. the original code skipped the test if it couldn't find os.fork... ::: if you don't have w9xpopen in place, the test will "crash": test test_popen2 crashed -- exceptions.OSError : [Errno 2] No such file or directory From mal at lemburg.com Thu Jul 27 09:58:16 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 09:58:16 +0200 Subject: [Python-Dev] test_fork1 on SMP? References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> <14719.42737.305992.235671@cj42289-a.reston1.va.home.com> <20000727060442.Q266@xs4all.nl> Message-ID: <397FEB98.17176FF0@lemburg.com> Thomas Wouters wrote: > > On Wed, Jul 26, 2000 at 11:05:21PM -0400, Fred L. Drake, Jr. wrote: > > > > Peter Schneider-Kamp writes: > > > Could SMP be involved? Do you get the same on a non-SMP system? > > > Do others have the same problem with SMP systems? > > > I think Barry may have access to an SMP Sparc machine; if so, we'll > > be checking it out there. > > I have also seen test_fork1 failures on BSDI, using a SMP machine, but I > haven't tried it on non-SMP (we don't have too many of those). However, all > our BSDI kernels are the same, having been built for SMP. Meetings > permitting (which is doubtful, today :-() I'll see if I can pin that down. > > It would, however, be fairly peculiar if test_fork1 breaks on all > SMP-supporting systems... I don't really recall a reason for thread > semantics to change reliably based on kernel/cpu settings, and it would be > silly for them to do so! But I'll admit threads are silly, period ;-) Could you be more specific about which aspect of test_fork1.py fails ? After looking at the code it seems that it's not the os.fork() itself that is not working, but some particular combination of using os.fork() on a process with multiple threads running. If the latter is the case, then I'd propose to simply switch off threads for SMP machines (is there a compile time switch we could use for this ?) until we have figured out what causes the problem. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 27 10:02:49 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 10:02:49 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> Message-ID: <397FECA9.56BB1C50@lemburg.com> Guido van Rossum wrote: > > I should add something about the assumed pseudo thread-safety of a+=b. > > I think this assumption is bogus, since we have to load a, do some > stuff, and then store a, and we can't guarantee that the stuff we do > is atomic -- in face we *know* it's not if it involves a user-defined > method. > > Simply put: > > a += 1 IS NOT ATOMIC! > > Note that C doesn't guarantee that a++ is atomic either, even if a is > declared volatile. (I believe there's an atomic data type, but I > don't think it guarantees atomic ++. That would be very expensive > because the VM cache would have to be flushed on multiprocessor > machines. The only docs I found are at > http://www.gnu.org/manual/glibc-2.0.6/html_node/libc_365.html.) If that's the case, then why do we need augemented assignments at all ? (I understood the atomicness being the main argument for introducing augmented assigns.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 27 10:22:31 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 10:22:31 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> Message-ID: <397FF146.2D307063@lemburg.com> Finn Bock wrote: > > CPythons unicode compare function contains some code to compare surrogate > characters in code-point order (I think). This is properly a very neat > feature but is differs from java's way of comparing strings. > > Python 2.0b1 (#0, Jul 26 2000, 21:29:11) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> print u'\ue000' < u'\ud800' > 1 > >>> print ord(u'\ue000') < ord(u'\ud800') > 0 > >>> > > Java (and JPython) compares the 16-bit characters numericly which result in: > > JPython 1.1+08 on java1.3.0 (JIT: null) > Copyright (C) 1997-1999 Corporation for National Research Initiatives > >>> print u'\ue000' < u'\ud800' > 0 > >>> print ord(u'\ue000') < ord(u'\ud800') > 0 > >>> > > I don't think I can come up with a solution that allow JPython to emulate > CPython on this type of comparison. The code originally worked the same way as what Java does here. Bill Tutt then added ideas from some IBM Java lib which turns the UTF-16 comparison into a true UCS-4 comparison. This really has nothing to do with being able to support surrogates or not (as Fredrik mentioned), it is the correct behaviour provided UTF-16 is used as encoding for UCS-4 values in Unicode literals which is what Python currently does. BTW, does Java support UCS-4 ? If not, then Java is wrong here ;-) Comparing Unicode strings is not as trivial as one might think: private point areas introduce a great many possibilities of getting things wrong and the fact that many characters can be expressed by combining other characters adds to the confusion. E.g. for sorting, we'd need full normalization support for Unicode and would have to come up with some smart strategy to handle private code point areas. All this is highly non-trivial and will probably not get implemented for a while (other issues are more important right now, e.g. getting the internals to use the default encoding instead of UTF-8). For now I'd suggest leaving Bill's code activated because it does the right thing for Python's Unicode implementation (which is built upon UTF-16). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Thu Jul 27 11:06:23 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 11:06:23 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007270559.AAA04753@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 12:59:15AM -0500 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> Message-ID: <20000727110622.S266@xs4all.nl> On Thu, Jul 27, 2000 at 12:59:15AM -0500, Guido van Rossum wrote: > I'm making up opcodes -- the different variants of LOAD and STORE > don't matter. On the right I'm displaying the stack contents after > execution of the opcode (push appends to the end). I'm writing > 'result' to indicate the result of the += operator. I take it you rather see a 'AUGOP' bytecode than a 'GETSET_' bytecode, that does the loading, operation and storing ? Not that I disagree, not at all, I just want to have that clear ;) > There are two more forms of potential interest. First, what should > happen to a tuple assignment? > > a, b, c += x > > (Which is exactly the same as "(a, b, c) += x".) Here's what happens now: >>> (a, b, c) += 1,2,3 SyntaxError: no augmented assignment to tuple (Isn't a reference implementation a cool thing ? ;) > Second, what should happen to a slice assignment? The basic slice > form is: > a[i:j] += b > but there are others: Python's slice syntax allows an arbitrary [yadah] What's so special about slice assignment ? You yourself (though Tim) suggested the following: x += y is effectively (minus order and number of evaluations) x = x.__add_ab__(y) Where __add_ab__() is the Python method, if 'x' is a python class, or plain '__add__' if 'x' doesn't have an '__add_ab__', or 'y.__radd__' if x doesn't have __add__. Similarly, if 'x' is a builtin, tp_as_number->nb_inplace_add is used, or tp_as_number->nb_add, etc. (Or sq_concat, if it's a seq and the operator is add.) The __add_ab__ method, or the C equivalent, can decide for itself whether it should return 'self', thus making the operation truly in-place, or a new instance of an object. This may seem as a complicated and unexpected way to do things, but it makes it possible to transparently support __add__ and __radd__ too, because they already return new objects. And you (through Tim) literally scolded me for trying to suggest x[1:10] += y being something like x = x.__add_slice_ab__(y, slice(1,10)) Instead, it should become x[1:10] = x[1:10] + y (Or rather, to keep the same order of evaluation:) tmp1 = y # in case of a more complicated expression tmp2 = x[1:10] x[1:10] = tmp2.__add_ab__(tmp1) The whole story about how complicated, convoluted and confusing Python's slicing is, though interesting and correct, is not connected to augmented assignment ;) > a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] += 1 Becomes tmp1 = a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] = tmp1.__add_ab__(1) > It would be nice if the SLICE bytecodes were removed altogether and > instead slice() objects would be created for all slices, even basic > ones. (I believe this was proposed in this list at some point.) The > original SLICE opcodes were introduced in ancient times, when basic > slices were the only accepted slice syntax. Agreed, however! You can't just make all slices use a sliceobject, for two reasons: a C extention type can use both the sequence and the mapping interface, and might not expect basic slices to be turned into a slice object. For instance, it's mapping interface may raise a TypeError, "Slices not supported", when it encounters a slice. Choosing mapping over sequence methods may break all that code. The same goes for Python classes. The other reason is usability. The current __get_slice__(self, start, end) sytnax is very convenient for nearly all uses of slices. Possibly because the builtin types don't handle extended slices currently, and possibly because the slice-object way is not generally known. (Just recently, there was someone asking on python-list on how to use slices. I'm not sure if he got a proper answer, but I've never seen such questions on the subject of basic slices!) If we do get a new __get_slice__ that handles all slices, I suggest doing it like this: class X: def __get_newslice__(self, (start, end, step)): where the type of start, end and step is not defined. This can be done with slice objects and sequence-unpacking, of course, but it makes it a lot more usable. Back-to-my-meetings-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Thu Jul 27 12:12:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 12:12:48 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> Message-ID: <002101bff7b3$38232fe0$f2a6b5d4@hagrid> mal wrote: > This really has nothing to do with being able to support > surrogates or not (as Fredrik mentioned), it is the correct > behaviour provided UTF-16 is used as encoding for UCS-4 values > in Unicode literals which is what Python currently does. Really? I could have sworn that most parts of Python use UCS-2, not UTF-16. Built-ins like ord, unichr, len; slicing; string methods; regular expressions, etc. all clearly assume that a Py_UNICODE is a unicode code point. My point is that we shouldn't pretend we're supporting UTF-16 if we don't do that throughout. As far as I can tell, cmp() is the *only* unicode function that thinks the internal storage is UTF-16. Everything else assumes UCS-2. And for Python 2.0, it's surely easier to fix cmp() than to fix everything else. (this is the same problem as 8-bit/unicode comparisions, where the current consensus is that it's better to raise an exception if it looks like the programmer doesn't know what he was doing, rather than pretend it's another encoding). ::: To summarize, here's the "character encoding guidelines" for Python 2.0: In Unicode context, 8-bit strings contain ASCII. Characters in the 0x80-0xFF range are invalid. 16-bit strings contain UCS-2. Characters in the 0xD800-0xDFFF range are invalid. If you want to use any other encoding, use the codecs pro- vided by the Unicode subsystem. If you need to use Unicode characters that cannot be represented as UCS-2, you cannot use Python 2.0's Unicode subsystem. Anything else is just a hack. From pf at artcom-gmbh.de Thu Jul 27 12:08:07 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Thu, 27 Jul 2000 12:08:07 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: from Mark Hammond at "Jul 27, 2000 2:47: 7 pm" Message-ID: Hi all, This rant is about automatically reclaimed resources like file descriptors. First let me cite a few sentences from the ancient book "Programming Python" written by Mark Lutz (p.122). Since this was the very first available book on Python, it could be considered as some kind of Python Programmers Guide. Much existing code today relies on the lessons teached there: """The short answer is that all files in this program are closed automatically: there's no need to call the file object "close" method. [...] More specifically, Python uses a reference count garbage collection strategy to reclaim memory behind the scenes. [...] each time we set 'input' to a new file in the for loop above, its previous value can be reclaimed. [...] When a file object is reclaimed, the file is automatically closed [...] We usually don't need to close such files manually; [...] """ A typical code example (simplified from a real application) : >>> import os, rfc822 >>> posters = {} >>> for arti in os.listdir('/var/spool/news/comp/lang/python'): ... poster = rfc822.Message(open(arti)).get("From") ... posters[poster] = posters.get(poster, 0) + 1 ... >>> for poster, howoften in posters.items(): ... print poster, "posted", howoften, "times to clp." ... I'm in no way convinced to consider code like above as broken. This simple automatic and deterministic behaviour of C-Python is part of the attractive elegance of Python and one of the major advantages over other languages like Java, that IMO suck beans. I've *NOT* tried scripts like the example above with JPython. But if JPython would run out of available file descriptors with such a simple application, then I think JPython or the Java VM are broken. Jeremy Hylton : > The argument about finalization is specious. You should not write > code that depends on current finalization semantics to do things like > closing files. It's relying on an implementation-dependent feature > that is not part of the language spec. (Just try it on JPython.) Eric S. Raymond" : > I strongly agree. Mark Hammond (answering to Moshe): > No - we will simply be pointing out their already broken code. We arent > breaking anything! > > I have no problem with this at all. The sooner we point out the broken > code the better. The last thing we want is for obviously and documented > broken code to suddenly be considered non-broken simply by the volume of > poor code out there... > > Either way, I think you are overstating the problem. The main scenario is > closing resources, and for most users these are unlikely to be so scarce > that delaying their finalization will cause problems. If someone is > writing a web-server, for example, and assumes that files or sockets are > automatically closed, and they open them at such a rate that true GC causes > them a problem, then IMO they have got what they deserve ;-) no no no. This time I have to agree with Moshe and disagree with Mark, Jeremy, Eric. Or I've missed the point. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From thomas at xs4all.net Thu Jul 27 12:22:24 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 12:22:24 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <397FECA9.56BB1C50@lemburg.com>; from mal@lemburg.com on Thu, Jul 27, 2000 at 10:02:49AM +0200 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> Message-ID: <20000727122223.T266@xs4all.nl> On Thu, Jul 27, 2000 at 10:02:49AM +0200, M.-A. Lemburg wrote: > Guido van Rossum wrote: > > I should add something about the assumed pseudo thread-safety of a+=b. > > Simply put: > > > > a += 1 IS NOT ATOMIC! > If that's the case, then why do we need augemented assignments > at all ? > (I understood the atomicness being the main argument for > introducing augmented assigns.) Nah, that was just something that emerged from my implementation, and only stood up in the face of simple builtin objects. I probably shouldn't have mentioned this ;-P I can't say anything about Guido's reasons for augmented assignment, but mine are ease-of-use, ease of use, and the ease of usage. And-python-is-all-about-ease-of-use-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jul 27 12:30:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 12:30:53 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> Message-ID: <39800F5D.C8ECF801@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > This really has nothing to do with being able to support > > surrogates or not (as Fredrik mentioned), it is the correct > > behaviour provided UTF-16 is used as encoding for UCS-4 values > > in Unicode literals which is what Python currently does. > > Really? I could have sworn that most parts of Python use > UCS-2, not UTF-16. The design specifies that Py_UNICODE refers to UTF-16. To make life easier, the implementation currently assumes UCS-2 in many parts, but this is should only be considered a temporary situation. Since supporting UTF-16 poses some real challenges (being a variable length encoding), full support for surrogates was postponed to some future implementation. > Built-ins like ord, unichr, len; slicing; > string methods; regular expressions, etc. all clearly assume > that a Py_UNICODE is a unicode code point. > > My point is that we shouldn't pretend we're supporting > UTF-16 if we don't do that throughout. We should keep that design detail in mind though. > As far as I can tell, cmp() is the *only* unicode function > that thinks the internal storage is UTF-16. > > Everything else assumes UCS-2. True. > And for Python 2.0, it's surely easier to fix cmp() than to > fix everything else. Also true :-) > (this is the same problem as 8-bit/unicode comparisions, where > the current consensus is that it's better to raise an exception > if it looks like the programmer doesn't know what he was doing, > rather than pretend it's another encoding). Perhaps you are right and we should #if 0 the comparison sections related to UTF-16 for now. I'm not sure why Bill needed the cmp() function to support surrogates... Bill ? Still, it will have to be reenabled sometime in the future when full surrogate support is added to Python. > ::: > > To summarize, here's the "character encoding guidelines" for > Python 2.0: > > In Unicode context, 8-bit strings contain ASCII. Characters > in the 0x80-0xFF range are invalid. 16-bit strings contain > UCS-2. Characters in the 0xD800-0xDFFF range are invalid. The latter is not true. In fact, thanks to Bill, the UTF-8 codec supports processing surrogates already and will output correct UTF-8 code even for Unicode strings containing surrogates. > If you want to use any other encoding, use the codecs pro- > vided by the Unicode subsystem. If you need to use Unicode > characters that cannot be represented as UCS-2, you cannot > use Python 2.0's Unicode subsystem. See above. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Thu Jul 27 15:09:37 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 08:09:37 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 10:02:49 +0200." <397FECA9.56BB1C50@lemburg.com> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> Message-ID: <200007271309.IAA06750@cj20424-a.reston1.va.home.com> > > Simply put: > > > > a += 1 IS NOT ATOMIC! > > > If that's the case, then why do we need augemented assignments > at all ? > > (I understood the atomicness being the main argument for > introducing augmented assigns.) Huh? Where did you get that idea? Can you point to a message where this was indicated? The reason for introducing it is that it's been the single-most requested feature ever since Python's inception. I think the reason it's been requested so much is that it's a waste of typing skills as well as (and more importantly) unnecessary extra effort to deduce what's going on in code like a.b.f().x[i] = a.b.f().x[i] + 1 Another important reason is that in cases like a[long_and_expensive_call()] = a[long_and_expensive_call()] + 1 you want to avoid doing the long_and_expensive_call() twice. Introducing a temp variable reduces the readability of the code. Note that my proposed semantics guarantee that in a[long_and_expensive_call()] += 1 the index is computed only once -- but this is not the same as atomicity (which has to do with other threads, signal handlers and similar asynchronous things). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Vladimir.Marangozov at inrialpes.fr Thu Jul 27 14:22:13 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 27 Jul 2000 14:22:13 +0200 (CEST) Subject: [Python-Dev] failures in the regression tests In-Reply-To: from "Tim Peters" at Jul 26, 2000 11:23:52 PM Message-ID: <200007271222.OAA02394@python.inrialpes.fr> Tim Peters wrote: > > On Win98, with the CVS version as of 11:15pm EDT, in both debug and release > builds: > > 59 tests OK. > 3 tests failed: test_mmap test_winreg test_winreg2 Make that 58/4 because of test_re which failure is hidden in output/test_re. /F - do you know at least what's going on? The SRE engine is a already a recurrent theme on this list, so I won't repeat what has been said, but if you can't sched some light on the errors, maybe documenting a little more the SRE code and its design would help the knowledgeable here to look at it and provide some help? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at beopen.com Thu Jul 27 15:37:24 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 08:37:24 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 11:06:23 +0200." <20000727110622.S266@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> Message-ID: <200007271337.IAA09101@cj20424-a.reston1.va.home.com> > I take it you rather see a 'AUGOP' bytecode than a 'GETSET_' bytecode, > that does the loading, operation and storing ? Not that I disagree, not at > all, I just want to have that clear ;) Yes, mostly because there are so many variants based on the kind of loading and storing: for each load-type operator you need 11 GETSET operators, and there are many different load operators: local, global, unspecified (== local by dict instead), by attribute, by index, or by slice... I am still neutral on the choice between a single AUGOP with an argument that takes an argument specifying the opcode, and 11 new operators: AUGASS_ADD, ... (Actually, the latter seem the most logical given that we also have BINARY_ADD, ...) > Here's what happens now: > > >>> (a, b, c) += 1,2,3 > SyntaxError: no augmented assignment to tuple > > (Isn't a reference implementation a cool thing ? ;) Very nice. Don't touch that part. > > Second, what should happen to a slice assignment? The basic slice > > form is: > > > a[i:j] += b > > > but there are others: Python's slice syntax allows an arbitrary [yadah] > > What's so special about slice assignment ? The only special thing about slice assignment is that there are 12 extra opcodes to deal with slices in the non-augmented-assignment case. I was making a case for avoiding this explosion, but somehow I got lost in my own train of thought. :( > You yourself (though Tim) > suggested the following: > > x += y > > is effectively (minus order and number of evaluations) > > x = x.__add_ab__(y) > > Where __add_ab__() is the Python method, if 'x' is a python class, or plain > '__add__' if 'x' doesn't have an '__add_ab__', or 'y.__radd__' if x doesn't > have __add__. Similarly, if 'x' is a builtin, tp_as_number->nb_inplace_add is > used, or tp_as_number->nb_add, etc. (Or sq_concat, if it's a seq and the > operator is add.) > > The __add_ab__ method, or the C equivalent, can decide for itself whether it > should return 'self', thus making the operation truly in-place, or a new > instance of an object. This may seem as a complicated and unexpected way to > do things, but it makes it possible to transparently support __add__ and > __radd__ too, because they already return new objects. > > And you (through Tim) literally scolded me for trying to suggest > > x[1:10] += y > > being something like > > x = x.__add_slice_ab__(y, slice(1,10)) > > Instead, it should become > > x[1:10] = x[1:10] + y > > (Or rather, to keep the same order of evaluation:) > > tmp1 = y # in case of a more complicated expression > tmp2 = x[1:10] > x[1:10] = tmp2.__add_ab__(tmp1) > > The whole story about how complicated, convoluted and confusing Python's > slicing is, though interesting and correct, is not connected to augmented > assignment ;) > > > a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] += 1 > > Becomes > > tmp1 = a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] > a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] = tmp1.__add_ab__(1) Yes. I should have realized earlier on that my pseudo code was just spelling out the necessary DUP etc. opcodes to avoid calculating the location of 'a' or the index(es) twice. Looking at my pseudo code for "a[i:j] += b" again, I realize that there's no reason to treat basic slices different than in other contexts -- it can be done with just DUP, ROT3 and ROT4: a[i:j] += b LOAD a [a] DUP [a, a] LOAD i [a, a, i] DUP [a, a, i, i] ROT3 [a, i, a, i] LOAD j [a, i, a, i, j] DUP [a, i, a, i, j, j] ROT4 [a, i, j, a, i, j] GETSLICE [a, i, j, slice] LOAD b [a, i, j, slice, b] AUGADD [a, i, j, result] SETSLICE [] So we need a new opcode ROT4 (or ROT_FOUR to be consistent in the spelling). > > It would be nice if the SLICE bytecodes were removed altogether and > > instead slice() objects would be created for all slices, even basic > > ones. (I believe this was proposed in this list at some point.) The > > original SLICE opcodes were introduced in ancient times, when basic > > slices were the only accepted slice syntax. > > Agreed, however! You can't just make all slices use a sliceobject, for two > reasons: a C extention type can use both the sequence and the mapping > interface, and might not expect basic slices to be turned into a slice > object. For instance, it's mapping interface may raise a TypeError, "Slices > not supported", when it encounters a slice. Choosing mapping over sequence > methods may break all that code. The same goes for Python classes. That's right. The backwards compatibility issues are the most daunting. > The other reason is usability. The current __get_slice__(self, start, end) > sytnax is very convenient for nearly all uses of slices. Possibly because > the builtin types don't handle extended slices currently, and possibly > because the slice-object way is not generally known. (Just recently, there > was someone asking on python-list on how to use slices. I'm not sure if he > got a proper answer, but I've never seen such questions on the subject of > basic slices!) > > If we do get a new __get_slice__ that handles all slices, I suggest doing it > like this: > > class X: > def __get_newslice__(self, (start, end, step)): > > where the type of start, end and step is not defined. This can be done with > slice objects and sequence-unpacking, of course, but it makes it a lot more > usable. Another alternative that tries to preserve compatibility is to call __getslice__(self, start, end) when the step is None, but __getslice__(self, start, end, step) when it isn't. Old code will raise a reasonable exception when a step is specified, while step-aware code can specify the step as a default argument value of 1 or None. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Thu Jul 27 15:41:25 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 08:41:25 -0500 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: Your message of "Thu, 27 Jul 2000 12:12:48 +0200." <002101bff7b3$38232fe0$f2a6b5d4@hagrid> References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> Message-ID: <200007271341.IAA09455@cj20424-a.reston1.va.home.com> > As far as I can tell, cmp() is the *only* unicode function > that thinks the internal storage is UTF-16. > > Everything else assumes UCS-2. > > And for Python 2.0, it's surely easier to fix cmp() than to > fix everything else. Agreed (I think). > (this is the same problem as 8-bit/unicode comparisions, where > the current consensus is that it's better to raise an exception > if it looks like the programmer doesn't know what he was doing, > rather than pretend it's another encoding). > > ::: > > To summarize, here's the "character encoding guidelines" for > Python 2.0: > > In Unicode context, 8-bit strings contain ASCII. Characters > in the 0x80-0xFF range are invalid. 16-bit strings contain > UCS-2. Characters in the 0xD800-0xDFFF range are invalid. > > If you want to use any other encoding, use the codecs pro- > vided by the Unicode subsystem. If you need to use Unicode > characters that cannot be represented as UCS-2, you cannot > use Python 2.0's Unicode subsystem. > > Anything else is just a hack. I wouldn't go so far as raising an exception when a comparison involves 0xD800-0xDFFF; after all we don't raise an exception when an ASCII string contains 0x80-0xFF either (except when converting to Unicode). The invalidity of 0xD800-0xDFFF means that these aren't valid Unicode code points; it doesn't mean that we should trap all attempts to use these values. That ways, apps that need UTF-16 awareness can code it themselves. Why? Because I don't want to proliferate code that explicitly traps 0xD800-0xDFFF throughout the code. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Thu Jul 27 15:44:26 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 08:44:26 -0500 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Your message of "Thu, 27 Jul 2000 12:08:07 +0200." References: Message-ID: <200007271344.IAA09722@cj20424-a.reston1.va.home.com> > This rant is about automatically reclaimed resources like file descriptors. > > First let me cite a few sentences from the ancient book "Programming Python" > written by Mark Lutz (p.122). Since this was the very first available book > on Python, it could be considered as some kind of Python Programmers Guide. > Much existing code today relies on the lessons teached there: > > """The short answer is that all files in this program are closed > automatically: there's no need to call the file object "close" method. > [...] > More specifically, Python uses a reference count garbage collection > strategy to reclaim memory behind the scenes. > [...] > each time we set 'input' to a new file in the for loop above, its > previous value can be reclaimed. > [...] > When a file object is reclaimed, the file is automatically closed > [...] > We usually don't need to close such files manually; > [...] > """ At the time Mark wrote, this was true. When JPython was introduced, I realized that I couldn't guarantee this in all implementations, so I removed that part of the language spec (at least in my head, and in the collective memory of the Python community). In any case, Moshe used this argument to defend weak binding to references to outer variables from inside inner functions; but that breaks closures, which is unacceptable. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From mwh21 at cam.ac.uk Thu Jul 27 14:55:19 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Thu, 27 Jul 2000 13:55:19 +0100 (BST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271337.IAA09101@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 27 Jul 2000, Guido van Rossum wrote: > > Here's what happens now: > > > > >>> (a, b, c) += 1,2,3 > > SyntaxError: no augmented assignment to tuple > > > > (Isn't a reference implementation a cool thing ? ;) > > Very nice. Don't touch that part. I think quite a lot of the code I wrote in compile.c for my augmented assignment patch lives on in Thomas's patch, and I was very conservative; if I couldn't work out what something should mean, I banned it (eg. a += b += c is a syntax error too). On reflection, I think I got this right. The error messages could be imporoved, I suspect. [snip to a very nearly completely different topic] > Another alternative that tries to preserve compatibility is to call > __getslice__(self, start, end) when the step is None, but > __getslice__(self, start, end, step) when it isn't. Old code will > raise a reasonable exception when a step is specified, while > step-aware code can specify the step as a default argument value of > 1 or None. Good idea. Are lists and tuples going to support seq[a:b:c] anytime soon? Patches welcome, I'd guess... Cheers, M. From thomas at xs4all.net Thu Jul 27 15:00:36 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 15:00:36 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271337.IAA09101@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 08:37:24AM -0500 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> Message-ID: <20000727150036.Z224@xs4all.nl> On Thu, Jul 27, 2000 at 08:37:24AM -0500, Guido van Rossum wrote: > > I take it you rather see a 'AUGOP' bytecode than a 'GETSET_' bytecode, > > that does the loading, operation and storing ? Not that I disagree, not at > > all, I just want to have that clear ;) > Yes, mostly because there are so many variants based on the kind of > loading and storing: for each load-type operator you need 11 GETSET > operators, and there are many different load operators: local, global, > unspecified (== local by dict instead), by attribute, by index, or by > slice... Except if you add a new type of bytecode, the 2-argument type. Which is what my implementation currently does. It necessitates just 9 new bytecodes that way: GETSET_SUBSCR, SLICE+0 through SLICE+3, NAME, FAST, GLOBAL and ATTR. The last four need 2 arguments, one for the name-index (or local vrbl number) and one for the actual operation. > I am still neutral on the choice between a single AUGOP with an > argument that takes an argument specifying the opcode, and 11 new > operators: AUGASS_ADD, ... (Actually, the latter seem the most > logical given that we also have BINARY_ADD, ...) Agreed. However, there isn't enough place in the current bytecode ranges for 9 consecutive non-argument opcodes. I'm also not sure how scarce a commodity opcodes are. Then again, it can also be 'undone' later. > > What's so special about slice assignment ? > The only special thing about slice assignment is that there are 12 > extra opcodes to deal with slices in the non-augmented-assignment > case. I was making a case for avoiding this explosion, but somehow I > got lost in my own train of thought. :( There's no explosion in the augmented assignment case, anyhow: either it's just 4 opcodes for handling slices, or it reuses the current opcodes. > So we need a new opcode ROT4 (or ROT_FOUR to be consistent in the > spelling). Yes. How about a ROT_ANY argument opcode while we're at it ? would specify the number to rotate... you could even encode *how* to rotate in that argument. (using the upper byte, imposing a sensible limit of 255 for the number of rotations ;-) > > class X: > > def __get_newslice__(self, (start, end, step)): > > where the type of start, end and step is not defined. This can be done with > > slice objects and sequence-unpacking, of course, but it makes it a lot more > > usable. > Another alternative that tries to preserve compatibility is to call > __getslice__(self, start, end) when the step is None, but > __getslice__(self, start, end, step) when it isn't. Old code will > raise a reasonable exception when a step is specified, while > step-aware code can specify the step as a default argument value of > 1 or None. Yes, that's very reasonable. I would suggest making the error 'special', in this case, though. So that you don't get a TypeError about incorrect number of arguments, but rather a 'object does not support extended slices' or some such TypeError. Actually, it might be worth doing it like this: Try to call __getslice__ with unconverted start, stop and step If it fails with a TypeError, and step is not None, raise the above error Else, convert start and stop to ints like the current normal slice behaviour, and try __getslice__ the old way. Or is that too much magic ? I don't think it'll break anything written in Python code, but I'm not sure what to do with the C API... But it's easier to break the API than Python code, me thinks. Break-over-godda-run-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Thu Jul 27 15:02:05 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 15:02:05 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: ; from mwh21@cam.ac.uk on Thu, Jul 27, 2000 at 01:55:19PM +0100 References: <200007271337.IAA09101@cj20424-a.reston1.va.home.com> Message-ID: <20000727150204.A224@xs4all.nl> On Thu, Jul 27, 2000 at 01:55:19PM +0100, Michael Hudson wrote: > I think quite a lot of the code I wrote in compile.c for my augmented > assignment patch lives on in Thomas's patch, and I was very conservative; > if I couldn't work out what something should mean, I banned it Yup, that's all yours. I wouldn't have known how to ban it anyway, and I wouldn't have known where to start *anything* without your patch, Michael! Gratefully-y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jul 27 15:01:51 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 15:01:51 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> <200007271309.IAA06750@cj20424-a.reston1.va.home.com> Message-ID: <398032BF.1F9A09ED@lemburg.com> Guido van Rossum wrote: > > > > Simply put: > > > > > > a += 1 IS NOT ATOMIC! > > > > > If that's the case, then why do we need augemented assignments > > at all ? > > > > (I understood the atomicness being the main argument for > > introducing augmented assigns.) > > Huh? Where did you get that idea? Can you point to a message where > this was indicated? It was advertised this way by Thomas: http://www.python.org/pipermail/python-list/2000-June/060680.html And since assignments in Python are thread safe, I thought it would only be natural for augemented assigns to also be thread safe which would have been a real advantage, since a=a+1 is not thread safe. All other uses simply boil down to reducing typing efforts, IMHO. (But that shouldn't keep you from adding it to the language ;-) Some comments: > The reason for introducing it is that it's been the single-most > requested feature ever since Python's inception. I think the reason > it's been requested so much is that it's a waste of typing skills as > well as (and more importantly) unnecessary extra effort to deduce > what's going on in code like > > a.b.f().x[i] = a.b.f().x[i] + 1 This can be written as: result = a.b.f().x result[i] = result[i] + 1 > Another important reason is that in cases like > > a[long_and_expensive_call()] = a[long_and_expensive_call()] + 1 Dito for this one: i = long_and_expensive_call() a[i] = a[i] + 1 > you want to avoid doing the long_and_expensive_call() twice. > Introducing a temp variable reduces the readability of the code. Not really... in fact if the name makes it clear what it refers too, it can augment the readbility. Besdies, a.b.f().x[i] isn't good style to begin with ;-) > Note that my proposed semantics guarantee that in > > a[long_and_expensive_call()] += 1 > > the index is computed only once -- but this is not the same as > atomicity (which has to do with other threads, signal handlers and > similar asynchronous things). Nevermind... I just wanted to hint at the added value of making these assignments atomic operations and not just an optimization of a = a + 1. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Thu Jul 27 16:12:58 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 09:12:58 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 13:55:19 +0100." References: Message-ID: <200007271412.JAA12251@cj20424-a.reston1.va.home.com> > Good idea. Are lists and tuples going to support seq[a:b:c] anytime soon? It's on my wish list, but can't be done for 2.0. > Patches welcome, I'd guess... Yes. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Thu Jul 27 16:22:48 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 09:22:48 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 15:00:36 +0200." <20000727150036.Z224@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> Message-ID: <200007271422.JAA13096@cj20424-a.reston1.va.home.com> > > Yes, mostly because there are so many variants based on the kind of > > loading and storing: for each load-type operator you need 11 GETSET > > operators, and there are many different load operators: local, global, > > unspecified (== local by dict instead), by attribute, by index, or by > > slice... > > Except if you add a new type of bytecode, the 2-argument type. Which is what > my implementation currently does. It necessitates just 9 new bytecodes that > way: GETSET_SUBSCR, SLICE+0 through SLICE+3, NAME, FAST, GLOBAL and ATTR. > The last four need 2 arguments, one for the name-index (or local vrbl > number) and one for the actual operation. But the two-arg opcode format slows down the opcode decoding -- and that's the most time-critical part of all of ceval.c! > > I am still neutral on the choice between a single AUGOP with an > > argument that takes an argument specifying the opcode, and 11 new > > operators: AUGASS_ADD, ... (Actually, the latter seem the most > > logical given that we also have BINARY_ADD, ...) > > Agreed. However, there isn't enough place in the current bytecode ranges for > 9 consecutive non-argument opcodes. I'm also not sure how scarce a commodity > opcodes are. Then again, it can also be 'undone' later. There's no need for them to be consecutive! (The BINARY_* family isn't even consecutive!) I say, just some open ranges, like 54-59 and 73-79. > Yes. How about a ROT_ANY argument opcode while we're at it ? would > specify the number to rotate... you could even encode *how* to rotate in > that argument. (using the upper byte, imposing a sensible limit of 255 for > the number of rotations ;-) No, let's not overgeneralize. > > Another alternative that tries to preserve compatibility is to call > > __getslice__(self, start, end) when the step is None, but > > __getslice__(self, start, end, step) when it isn't. Old code will > > raise a reasonable exception when a step is specified, while > > step-aware code can specify the step as a default argument value of > > 1 or None. > > Yes, that's very reasonable. I would suggest making the error 'special', > in this case, though. So that you don't get a TypeError about incorrect > number of arguments, but rather a 'object does not support extended slices' > or some such TypeError. Yes. > Actually, it might be worth doing it like this: > > Try to call __getslice__ with unconverted start, stop and step > If it fails with a TypeError, and step is not None, raise the above error > Else, convert start and stop to ints like the current normal slice > behaviour, and try __getslice__ the old way. No, trying to call something and retrying if it fails is a bad idea: the code might fail for a very different reason, and retrying it might mask the bug, or execute a side effect twice... There's no reason why we can't check whether the step is None; it's already impossible to find out whether a particular slice was "lo:hi:None" or "lo:hi:" (once extended slice mode is used). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From nascheme at enme.ucalgary.ca Thu Jul 27 15:50:58 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 27 Jul 2000 07:50:58 -0600 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: ; from Tim Peters on Thu, Jul 27, 2000 at 01:17:03AM -0400 References: <14719.49496.935765.730596@anthem.concentric.net> Message-ID: <20000727075058.A25450@keymaster.enme.ucalgary.ca> On Thu, Jul 27, 2000 at 01:17:03AM -0400, Tim Peters wrote: > If there exists a platform on which it fails but it doesn't fail every time > on that platform, that would be strong evidence of a timing hole. Those > usually require thought to identify and repair. I'll voluteer to > eyeball the code and do some thinking, but not unless the symptoms suggest > that's worthwhile. > > ignorantly y'rs - tim Here is some code that seems to hang on Linux UP machines. Sometimes it prints PIDS for a while and other times it stops after only a few. I don't know if that counts. I raised this issue over a month ago. Tim, your getting forgetful. :) Neil import threading import os, sys class MyThread(threading.Thread): def start(self): threading.Thread.start(self) def run(self): while 1: if os.fork() == 0: print os.getpid() os._exit(0) os.wait() MyThread().start() MyThread().start() MyThread().start() From billtut at microsoft.com Thu Jul 27 15:55:59 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 06:55:59 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33A@RED-MSG-50> Fredrik wrote: > since we don't really support surrogates (or anything else > related to 32-bit unicode) anywhere else, I'd rather change > CPython to emulate JPython here. That's not entirely true. UTF-8 encoding supports surrogates. No reason that we couldn't put the code into a unicode helper function module. If I get a chance to finish my port of the simple Unicode compression thing that'll support surrogates as well. We're eventually going to need one of these anyway for additional Unicode related algorithms. Collation, etc... Bill From effbot at telia.com Thu Jul 27 16:05:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 16:05:25 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> <200007271341.IAA09455@cj20424-a.reston1.va.home.com> Message-ID: <006901bff7d3$c06d1e40$f2a6b5d4@hagrid> > [me] > > To summarize, here's the "character encoding guidelines" for > > Python 2.0: > > > > In Unicode context, 8-bit strings contain ASCII. Characters > > in the 0x80-0xFF range are invalid. 16-bit strings contain > > UCS-2. Characters in the 0xD800-0xDFFF range are invalid. > > > > If you want to use any other encoding, use the codecs pro- > > vided by the Unicode subsystem. If you need to use Unicode > > characters that cannot be represented as UCS-2, you cannot > > use Python 2.0's Unicode subsystem. > > > > Anything else is just a hack. [guido] > I wouldn't go so far as raising an exception when a comparison > involves 0xD800-0xDFFF; after all we don't raise an exception when an > ASCII string contains 0x80-0xFF either (except when converting to > Unicode). that's what the "unicode context" qualifier means: 8-bit strings can contain anything, unless you're using them as unicode strings. > The invalidity of 0xD800-0xDFFF means that these aren't valid Unicode > code points; it doesn't mean that we should trap all attempts to use > these values. That ways, apps that need UTF-16 awareness can code it > themselves. > > Why? Because I don't want to proliferate code that explicitly traps > 0xD800-0xDFFF throughout the code. you only need to check "on the way in", and leave it to the decoders to make sure they generate UCS-2 only. the original unicode implementation did just that, but Bill and Marc-Andre recently lowered the shields: the UTF-8 decoder now generates UTF-16 encoded data. (so does \N{}, but that's a non-issue: (oddly enough, the UTF-16 decoder won't accept anything that isn't UCS-2 ;-) my proposal is to tighten this up in 2.0: ifdef out the UTF-16 code in the UTF-8 decoder, and ifdef out the UTF-16 stuff in the compare function. let's wait until 2.1 before we support the full unicode character set (and I'm pretty sure "the right way" is UCS-4 storage and a unified string implementation, but let's discuss that later). patch coming. From jeremy at beopen.com Thu Jul 27 16:06:17 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 27 Jul 2000 10:06:17 -0400 (EDT) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: References: Message-ID: <14720.16857.900370.320050@bitdiddle.concentric.net> >>>>> "PF" == Peter Funk writes: PF> Hi all, This rant is about automatically reclaimed resources PF> like file descriptors. PF> First let me cite a few sentences from the ancient book PF> "Programming Python" written by Mark Lutz (p.122). Since this PF> was the very first available book on Python, it could be PF> considered as some kind of Python Programmers Guide. Feel free to think of it as a guide, but don't think of it as a specification! (It is, as you mention, fairly old.) The only official word on reclaiming externel resource is the Python Language Reference -- http://www.python.org/doc/current/ref/. >Some objects contain references to "external" resources such as open >files or windows. It is understood that these resources are freed when >the object is garbage-collected, but since garbage collection is not >guaranteed to happen, such objects also provide an explicit way to >release the external resource, usually a close() method. Programs are >strongly recommended to explicitly close such objects. The >`try...finally' statement provides a convenient way to do this. If this isn't clear enough, we could revise it for the next release of the documentation. As Guido said, the code is broken, not JPython. Jeremy From effbot at telia.com Thu Jul 27 16:10:09 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 16:10:09 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> <200007271341.IAA09455@cj20424-a.reston1.va.home.com> <006901bff7d3$c06d1e40$f2a6b5d4@hagrid> Message-ID: <007601bff7d4$60a644e0$f2a6b5d4@hagrid> I wrote: > now generates UTF-16 encoded data. (so does \N{}, but > that's a non-issue: ...because all characters in the current name database have 16-bit codes. From Vladimir.Marangozov at inrialpes.fr Thu Jul 27 15:52:40 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 27 Jul 2000 15:52:40 +0200 (CEST) Subject: [Python-Dev] was Re: Type inference now simplicity (fwd) In-Reply-To: from "Moshe Zadka" at Jul 27, 2000 08:06:00 AM Message-ID: <200007271352.PAA02626@python.inrialpes.fr> Moshe Zadka wrote: > > [c.l.py posting deleted] > > [Moshe, concluding] > > Adding new operators and new syntax will make Python harder to read, and > harder to learn. I don't want that. > To some extent, I share these feelings. But only to some extent, because in my eyes it's all a matter of priority. I'll try to elaborate quickly. Before going into extending Python with features, it's more important to make the current implementation rock solid, a.k.a "commercial quality". Presently, this is not really the case and there are already long-standing known issues that nobody gets excited about. Solving these issues is of paramount importance for the acceptance of Python in .com software and generally speaking, its proliferation. For instance: 1. It is unacceptable that Python blows when a generated code object happens to be greater than 2 bytes. If this doesn't get fixed in the VM, the compiler should at least check for this overflow and refuse to emit the bytecode stream. 2. It is unacceptable that Python leaks memory or happens to core dump, without having optional emergency procedures. In this regard, I highly value robust (commercial) software which, for example, pops up a window on low-memory conditions inviting me to free more mem by quitting other apps and gives me the choice to abort the current execution or resume it. Python core dumps on several known situations, notably those that involve recursive calls. 3. I consider very-high priority the recently discussed integrated help system. 4. I consider high priority the opportunity to get more performance in terms of system resources: memory & execution speed. And this is why I'm working on it as time permits. I find unacceptable the fact that there are already some potential improvements on the table which have not been considered seriously so far: removal of SET_LINENO, GC + malloc integration, etc. 5. I find unwise the whole process of enriching the core, whithout a global vision on a modular and extensible core architecture. Adding 10 additional opcodes for augmented assignment is considered nuts. The addition of opcodes for extended calls is already a fact, although I never use them and I don't need them. Other enhancements have been proposed and they come on top of the system, making it quite heavy. And I don't use Unicode - so why it isn't optional? Because there's no a truly modular architecture in place. I hope that python-dev will eventually realize that all these issues are more important that augmented assignment, zip(), and other recently discussed enhancements. IMO, the latter are crap compared to the concerns above. and-I'm-not-talking-about-types-or-Py3K'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From billtut at microsoft.com Thu Jul 27 16:18:56 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 07:18:56 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33B@RED-MSG-50> > From: M.-A. Lemburg [mailto:mal at lemburg.com] > Fredrik Lundh wrote: > > > > mal wrote: > > > This really has nothing to do with being able to support > > > surrogates or not (as Fredrik mentioned), it is the correct > > > behaviour provided UTF-16 is used as encoding for UCS-4 values > > > in Unicode literals which is what Python currently does. > > > > Really? I could have sworn that most parts of Python use > > UCS-2, not UTF-16. > The design specifies that Py_UNICODE refers to UTF-16. To make > life easier, the implementation currently assumes UCS-2 in > many parts, but this is should only be considered a > temporary situation. Since supporting UTF-16 poses some > real challenges (being a variable length encoding), full > support for surrogates was postponed to some future > implementation. Heh. Now you're being silly. Supporting UTF-16 isn't that difficult. You always know whether the character is a low surrogate or a high surrogate. The interesting question is whether or not you have your builtin Unicode object expose each 16-bit character as is, or you support iterating over Py_UCS4 characters, or you want to have a wrapping object that does the right thing here. This might be the way to go. > > Built-ins like ord, unichr, len; slicing; > > string methods; regular expressions, etc. all clearly assume > > that a Py_UNICODE is a unicode code point. > > > > My point is that we shouldn't pretend we're supporting > > UTF-16 if we don't do that throughout. > We should keep that design detail in mind though. > > As far as I can tell, cmp() is the *only* unicode function > > that thinks the internal storage is UTF-16. > > > Everything else assumes UCS-2. No, its UTF-16, it just doesn't yet handle surrogates in all of the appropriate places. :) The unicodename stuff also needs to support future named surrogate characters now. > > And for Python 2.0, it's surely easier to fix cmp() than to > > fix everything else. > Also true :-) Everything but the regular expressions would be fairly simple to add UTF-16 support to. I'd imagine that adding support for \u10FFFF in the regular expression syntax wouldn't be that hard either. > > (this is the same problem as 8-bit/unicode comparisions, where > > the current consensus is that it's better to raise an exception > > if it looks like the programmer doesn't know what he was doing, > > rather than pretend it's another encoding). > Perhaps you are right and we should #if 0 the comparison > sections related to UTF-16 for now. I'm not sure why Bill > needed the cmp() function to support surrogates... Bill ? I didn't need it to. I happened upon the code on the IBM website, so I figured I'd point it out and see what people thought of sticking it into the Python Unicode stuff. :) (Wishing Python 2.0 would ship with Unicode collation support) See the earlier comment about creating a wrapping class that handles UTF-16 issues better. > Still, it will have to be reenabled sometime in the > future when full surrogate support is added to Python. Bill From moshez at math.huji.ac.il Thu Jul 27 16:26:04 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 27 Jul 2000 17:26:04 +0300 (IDT) Subject: [Python-Dev] was Re: Type inference now simplicity (fwd) In-Reply-To: <200007271352.PAA02626@python.inrialpes.fr> Message-ID: On Thu, 27 Jul 2000, Vladimir Marangozov wrote: > Before going into extending Python with features, it's more important > to make the current implementation rock solid, a.k.a "commercial quality". > Presently, this is not really the case and there are already long-standing > known issues that nobody gets excited about. Solving these issues is of > paramount importance for the acceptance of Python in .com software and > generally speaking, its proliferation. I agree. > For instance: > > 1. It is unacceptable that Python blows when a generated code object > happens to be greater than 2 bytes. If this doesn't get fixed in > the VM, the compiler should at least check for this overflow and > refuse to emit the bytecode stream. Can you elaborate on that? At least the numeric typo error makes this a guessing job > 2. It is unacceptable that Python leaks memory or happens to core dump, > without having optional emergency procedures. In this regard, I highly > value robust (commercial) software which, for example, pops up a window > on low-memory conditions inviting me to free more mem by quitting other > apps and gives me the choice to abort the current execution or resume it. Personally, I don't. If there is no memory, Python should quit gracefully (throwing MemoryError exception is fine by me -- core dumping is not) > Python core dumps on several known situations, notably those that > involve recursive calls. This doesn't have to do with low-memory conditions, this is because Python uses the C stack. Finally putting in stackless will make this the same as low-memory conditions, and we already covered that 3. I consider very-high priority the recently discussed integrated help > system. I don't. It's in the "useful, but not necessary". What *is* necessary is a good IDE, with integrated help. IDLE is being worked on, as is ActiveState's Komodo and my Bwian vapourware. > 4. I consider high priority the opportunity to get more performance in > terms of system resources: memory & execution speed. And this is why > I'm working on it as time permits. I find unacceptable the fact that > there are already some potential improvements on the table which have > not been considered seriously so far: removal of SET_LINENO, GC + malloc > integration, etc. I totally agree -- and even more so. I hope to have the time to work on serious Python optimization, notable things like method caching, optimizing built-in function calls, etc. > 5. I find unwise the whole process of enriching the core, whithout a > global vision on a modular and extensible core architecture. Adding > 10 additional opcodes for augmented assignment is considered nuts. > The addition of opcodes for extended calls is already a fact, although > I never use them and I don't need them. Other enhancements have been > proposed and they come on top of the system, making it quite heavy. > And I don't use Unicode - so why it isn't optional? Because > there's no a truly modular architecture in place. Ummm.....most of unicode *is* optional: the codec package and various unicode modules are optional. u"" strings have new syntax, which is really needed. > I hope that python-dev will eventually realize that all these issues are > more important that augmented assignment I completely agree. > zip() zip() and friends (irange, product) have been suggested to live in a seperate Python module, hence completely optional. If you're talking about time usage, well, it's not your time -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From effbot at telia.com Thu Jul 27 16:43:34 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 16:43:34 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33B@RED-MSG-50> Message-ID: <009801bff7d9$0e90d580$f2a6b5d4@hagrid> bill wrote: > Heh. Now you're being silly. Supporting UTF-16 isn't that difficult. You > always know whether the character is a low surrogate or a high surrogate. sorry, but you're being silly. using variable-width encoding for interal storage is difficult, slow, and just plain stupid on modern hardware. (image processing people stopped doing stupid things like that ages ago, and trust me -- a typical image contains many more pixels than a typical text ;-) after all, if variable-width internal storage had been easy to deal with, we could have used UTF-8 from the start... (and just like the Tcl folks, we would have ended up rewriting the whole thing in the next release ;-) From billtut at microsoft.com Thu Jul 27 16:24:48 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 07:24:48 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33C@RED-MSG-50> -----Original Message----- > From: Guido van Rossum [mailto:guido at beopen.com] > The invalidity of 0xD800-0xDFFF means that these aren't valid Unicode > code points; it doesn't mean that we should trap all attempts to use > these values. That ways, apps that need UTF-16 awareness can code it > themselves. 0xD800-0xDFFF are valid code points. They just aren't characters that you normally want to render all on their own. :) > Why? Because I don't want to proliferate code that explicitly traps > 0xD800-0xDFFF throughout the code. Err... I don't think you have much choice in the long term. Its not like the code is all that difficult, and certain cases might be able to use helper functions to help centralize that particular part of code. Bill From effbot at telia.com Thu Jul 27 16:50:53 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 16:50:53 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33B@RED-MSG-50> <009801bff7d9$0e90d580$f2a6b5d4@hagrid> Message-ID: <00a601bff7da$12aca9e0$f2a6b5d4@hagrid> I wrote: > (image processing people stopped doing stupid things like that > ages ago, and trust me -- a typical image contains many more > pixels than a typical text ;-) ...contains characters. sorry folks, my thinkahead fifo buffer appears to be broken today. time for a reboot. From billtut at microsoft.com Thu Jul 27 16:43:44 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 07:43:44 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33D@RED-MSG-50> Fredik wrote: > the original unicode implementation did just that, but Bill and > Marc-Andre recently lowered the shields: the UTF-8 decoder > now generates UTF-16 encoded data. (so does \N{}, but > that's a non-issue:=20 > my proposal is to tighten this up in 2.0: ifdef out the UTF-16 > code in the UTF-8 decoder, and ifdef out the UTF-16 stuff in > the compare function. Commenting the UTF-16 stuff out in the compare function is a valid point, given our current Unicode string object. I disagree strongly with disabling the surrogate support in UTF-8, and we should fix the UTF-16 decoder. Since the decoder/encoder support doesn't hurt any other piece of code by emitting surrogate pairs, I don't see why you want to disable the code. > (oddly enough, the UTF-16 decoder won't accept anything > that isn't UCS-2 ;-) Well that's an easy bug to fix. > let's wait until 2.1 before we support the full unicode character > set (and I'm pretty sure "the right way" is UCS-4 storage and a > unified string implementation, but let's discuss that later). I've mentioned this before, but why discuss this later? Indeed why would we want to fix it for 2.1? Esp. if we move to UCS-4 storage in a minor release. Why not just get the Unicode support correct this time around. Save the poor users of the Python Unicode support from going nuts when we make these additional confusing changes later. If you think you want to move to UCS-4 later, don't wait, do it know. Add support for special surrogate handling later if we must, but please oh please don't change the storage mechanism in memory in a later relase. Java and Win32 are all UTF-16 based, and those extra 16-bits are actually wasted for nearly every common Unicode data you'd hope to handle. I think using UTF-16 as an internal storage mechanism actually makes sense. Whether or not you want to have your character type expose an array of 16-bit values, or the appearance of an array of UCS-4 characters is a separate issue. An issue I think should be answered now, instead of fixing it later. Bill From billtut at microsoft.com Thu Jul 27 16:49:06 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 07:49:06 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33E@RED-MSG-50> Fredrik: > sorry, but you're being silly. using variable-width encoding for > interal storage is difficult, slow, and just plain stupid on modern > hardware. So use UCS-4 internal storage now. UTF-16 just seems like a handy internal storage mechanism to pick since Win32 and Java use it for their native string processing. > (image processing people stopped doing stupid things like that > ages ago, and trust me -- a typical image contains many more > pixels than a typical text ;-) > after all, if variable-width internal storage had been easy to deal > with, we could have used UTF-8 from the start... (and just like > the Tcl folks, we would have ended up rewriting the whole thing > in the next release ;-) Oh please, UTF-16 is substantially simpler to deal with than UTF-8. I would go nuts if our internal storage mechanism was UTF-8. Bill From Vladimir.Marangozov at inrialpes.fr Thu Jul 27 17:03:51 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 27 Jul 2000 17:03:51 +0200 (CEST) Subject: [Python-Dev] was Re: Type inference now simplicity (fwd) In-Reply-To: from "Moshe Zadka" at Jul 27, 2000 05:26:04 PM Message-ID: <200007271503.RAA02899@python.inrialpes.fr> Moshe Zadka wrote: > > > For instance: > > > > 1. It is unacceptable that Python blows when a generated code object > > happens to be greater than 2 bytes. If this doesn't get fixed in > > the VM, the compiler should at least check for this overflow and > > refuse to emit the bytecode stream. > > Can you elaborate on that? At least the numeric typo error makes this > a guessing job I won't :-) Of course I meant the case where the size doesn't fit in 2 bytes, i.e. > 32k > > Python core dumps on several known situations, notably those that > > involve recursive calls. > > This doesn't have to do with low-memory conditions, this is because Python > uses the C stack. I know, it has been discussed to death. So what? Live with it (the C stack) and fix the code, as it has been done for recursive comparisons and marshal. The point of my mail isn't in the details, though... As you might guess, I haven't been exhaustive regarding the current state of the (C) implementation. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From effbot at telia.com Thu Jul 27 17:35:27 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 17:35:27 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33E@RED-MSG-50> Message-ID: <00cb01bff7e0$79e74d80$f2a6b5d4@hagrid> bill wrote: > So use UCS-4 internal storage now. UTF-16 just seems like a handy internal > storage mechanism to pick since Win32 and Java use it for their native > string processing. umm. the Java docs I have access to doesn't mention surrogates at all (they do point out that a character is 16-bit, and they don't provide an \U escape). on the other hand, MSDN says: Windows 2000 provides support for basic input, output, and simple sorting of surrogates. However, not all Windows 2000 system components are surrogate compatible. Also, surrogates are not supported in Windows 95/98 or in Windows NT 4.0. and then mentions all the usual problems with variable-width encodings... > > after all, if variable-width internal storage had been easy to deal > > with, we could have used UTF-8 from the start... (and just like > > the Tcl folks, we would have ended up rewriting the whole thing > > in the next release ;-) > > Oh please, UTF-16 is substantially simpler to deal with than UTF-8. in what way? as in "one or two words" is simpler than "one, two, three, four, five, or six bytes"? or as in "nobody will notice anyway..." ;-) ::: if UCS-2/BMP was good enough for NT 4.0, Unicode 1.1, and Java 1.0, it's surely good enough for Python 2.0 ;-) (and if I understand things correctly, 2.1 isn't that far away...) From effbot at telia.com Thu Jul 27 17:53:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 17:53:45 +0200 Subject: [Python-Dev] more unicode: \U support? Message-ID: <012f01bff7e2$e0443820$f2a6b5d4@hagrid> would it be a good idea to add \UXXXXXXXX (8 hex digits) to 2.0? (only characters in the 0000-ffff range would be accepted in the current version, of course). From thomas at xs4all.net Thu Jul 27 17:48:03 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 17:48:03 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271422.JAA13096@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 09:22:48AM -0500 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> Message-ID: <20000727174803.U266@xs4all.nl> On Thu, Jul 27, 2000 at 09:22:48AM -0500, Guido van Rossum wrote: [about INPLACE_ADD/SUBTRACT/ETC] > There's no need for them to be consecutive! (The BINARY_* family > isn't even consecutive!) I say, just some open ranges, like 54-59 and > 73-79. [and about ROT_ANY] > No, let's not overgeneralize. Roger dodger, wilco dilco, milli vanilli. > > Try to call __getslice__ with unconverted start, stop and step > > If it fails with a TypeError, and step is not None, raise the above error > > Else, convert start and stop to ints like the current normal slice > > behaviour, and try __getslice__ the old way. > > No, trying to call something and retrying if it fails is a bad idea: > the code might fail for a very different reason, and retrying it might > mask the bug, or execute a side effect twice... Yeah, I realized that too, while listening one of my colleagues trying to make some point or other. Hrm... So backwards compatibility is out ? I'm not sure howmany Python code uses slice-objects, but I would consider it a (personal ;) failure if slicing has to be *broken* before it can be fixed. If we can't figure out whether a function supports the 'new syntax' reliably, I don't see how we can transform the error message either. I'll bet inspecting the __getitem__ method to find out whether it supports the one or the other is way too much of a runtime penalty to suffer at each index. So the only workable way to support all combinations of __getitem__ and __getslice__ is by adding a new builtin, __getitems__ ? (too confusing a name... __getanything__ ? :P) Feeble-(after-all-those-meetings)-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Thu Jul 27 19:03:39 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 12:03:39 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 17:48:03 +0200." <20000727174803.U266@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> Message-ID: <200007271703.MAA00802@cj20424-a.reston1.va.home.com> > > No, trying to call something and retrying if it fails is a bad idea: > > the code might fail for a very different reason, and retrying it might > > mask the bug, or execute a side effect twice... > > Yeah, I realized that too, while listening one of my colleagues trying to > make some point or other. Hrm... So backwards compatibility is out ? I'm not > sure howmany Python code uses slice-objects, but I would consider it a > (personal ;) failure if slicing has to be *broken* before it can be fixed. Huh? I thought I proposed a b/w compat solution: IF there is a __getslice__ method: IF the slice step is None: call __getslice__(lo, hi) ELSE: # the slice step is not None call __getslice__(lo, hi, step) What's wrong with that? > If we can't figure out whether a function supports the 'new syntax' > reliably, I don't see how we can transform the error message either. I'll > bet inspecting the __getitem__ method to find out whether it supports the > one or the other is way too much of a runtime penalty to suffer at each > index. No, we don't deal with __getitem__; if *it* doesn't support a tuple containing slice objects, tough luck. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From skip at mojam.com Thu Jul 27 18:03:29 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 27 Jul 2000 11:03:29 -0500 (CDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <398032BF.1F9A09ED@lemburg.com> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> <200007271309.IAA06750@cj20424-a.reston1.va.home.com> <398032BF.1F9A09ED@lemburg.com> Message-ID: <14720.23889.451562.474003@beluga.mojam.com> >> Another important reason is that in cases like >> >> a[long_and_expensive_call()] = a[long_and_expensive_call()] + 1 M-A> Dito for this one: M-A> i = long_and_expensive_call() M-A> a[i] = a[i] + 1 Only if you know that long_and_expensive_call() has no side effects! Skip From mal at lemburg.com Thu Jul 27 18:09:05 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 18:09:05 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> <200007271309.IAA06750@cj20424-a.reston1.va.home.com> <398032BF.1F9A09ED@lemburg.com> <14720.23889.451562.474003@beluga.mojam.com> Message-ID: <39805EA1.9DA9BEF@lemburg.com> Skip Montanaro wrote: > > > >> Another important reason is that in cases like > >> > >> a[long_and_expensive_call()] = a[long_and_expensive_call()] + 1 > > M-A> Dito for this one: > > M-A> i = long_and_expensive_call() > M-A> a[i] = a[i] + 1 > > Only if you know that long_and_expensive_call() has no side effects! If it does, then you'll have to write the long version anyway, if it doesn't I don't see a problem, if you don't know then you shouldn't use the function anyway ;-)) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Thu Jul 27 18:13:16 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 18:13:16 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271703.MAA00802@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 12:03:39PM -0500 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> Message-ID: <20000727181315.B224@xs4all.nl> On Thu, Jul 27, 2000 at 12:03:39PM -0500, Guido van Rossum wrote: > > So backwards compatibility is out ? I'm not sure howmany Python code > > uses slice-objects, but I would consider it a (personal ;) failure if > > slicing has to be *broken* before it can be fixed. > Huh? I thought I proposed a b/w compat solution: > IF there is a __getslice__ method: > IF the slice step is None: > call __getslice__(lo, hi) > ELSE: # the slice step is not None > call __getslice__(lo, hi, step) > What's wrong with that? Well, what happens if __getslice__ and __getitem__ both exist, and __getitem__ is used to handle extended slices, but __getslice__ isn't (yet)? Currently, if it's a single item, __getitem__ is called. If it's a basic slice, __getslice__ is called. If it's an extended slice, __getitem__ is called. In the above picture, __getslice__ would be called instead, with the 'wrong' number of arguments, and the use of extended slices would break. > > If we can't figure out whether a function supports the 'new syntax' > > reliably, I don't see how we can transform the error message either. I'll > > bet inspecting the __getitem__ method to find out whether it supports the > > one or the other is way too much of a runtime penalty to suffer at each > > index. > No, we don't deal with __getitem__; if *it* doesn't support a tuple > containing slice objects, tough luck. Sorry, that was my feebleness popping up. I was talking about __getslice__. How do we find out if __getslice__ accepts 4 arguments, rather than 3 ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Thu Jul 27 18:22:48 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 18:22:48 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <20000727181315.B224@xs4all.nl>; from thomas@xs4all.net on Thu, Jul 27, 2000 at 06:13:16PM +0200 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> Message-ID: <20000727182248.V266@xs4all.nl> On Thu, Jul 27, 2000 at 06:13:16PM +0200, Thomas Wouters wrote: > Sorry, that was my feebleness popping up. I was talking about __getslice__. > How do we find out if __getslice__ accepts 4 arguments, rather than 3 ? Actually, it wasn't the feebleness as much as the two different things you seem to be wanting, Guido ;) Previously (in another thread, and perhaps in the start of this thread as well) you argued that an index should always call __getitem__, with a slice object if it's a slice of some kind, *even a basic one*. So that we lose __getslice__ and rather teach people to use __getslice__. So now you want to *extend* the 'special case' to extended, 3-argument slices, but *not* Ellipses and tupled-slices (which aren't really tuples, because you can do (1, 2:5, ...)) -- or am I reading this wrong ? :) Don't worry, Guido, it isn't just you, I failed to grasp what those managers were trying to tell me today, too... I may just be too dense, today. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Thu Jul 27 19:25:44 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 12:25:44 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 18:13:16 +0200." <20000727181315.B224@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> Message-ID: <200007271725.MAA17990@cj20424-a.reston1.va.home.com> > > IF there is a __getslice__ method: > > IF the slice step is None: > > call __getslice__(lo, hi) > > ELSE: # the slice step is not None > > call __getslice__(lo, hi, step) > > > What's wrong with that? > > Well, what happens if __getslice__ and __getitem__ both exist, and > __getitem__ is used to handle extended slices, but __getslice__ isn't (yet)? > Currently, if it's a single item, __getitem__ is called. If it's a basic > slice, __getslice__ is called. If it's an extended slice, __getitem__ is > called. > > In the above picture, __getslice__ would be called instead, with the 'wrong' > number of arguments, and the use of extended slices would break. Good point. Sigh. I suppose we could inspect the __getslice__ method's argument count (it *is* available somewher) but that seems a hack (and could still break if default arguments were used for something else). Another solution: require a class variable to indicate the class's awareness: e.g. you must define __getslice_takes_three_args__ when __getslice__(lo, hi, step) is supported, otherwise the call goes to __getitem__(slice(lo, hi, step)). This is a bit like the feature flag bits in the type struct. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Thu Jul 27 19:30:51 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 12:30:51 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 18:22:48 +0200." <20000727182248.V266@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> <20000727182248.V266@xs4all.nl> Message-ID: <200007271730.MAA21788@cj20424-a.reston1.va.home.com> > Actually, it wasn't the feebleness as much as the two different things you > seem to be wanting, Guido ;) Previously (in another thread, and perhaps in > the start of this thread as well) you argued that an index should always > call __getitem__, with a slice object if it's a slice of some kind, *even a > basic one*. So that we lose __getslice__ and rather teach people to use > __getslice__. That would be nice, but it would be b/w incompatible, so now we're trying (again) to figure out how to still support __getslice__. My proposal is to try and be b/w compatible if __getslice__ exists. See my previous mail. > So now you want to *extend* the 'special case' to extended, 3-argument > slices, but *not* Ellipses and tupled-slices (which aren't really tuples, > because you can do (1, 2:5, ...)) -- or am I reading this wrong ? :) Not sure what you mean by that. (1, 2:5, ...) by itself is illegal syntax; the special slice syntax can only occur directly in an indexing context, e.g. a[1, 2:5, ...]. > Don't worry, Guido, it isn't just you, I failed to grasp what those managers > were trying to tell me today, too... I may just be too dense, today. I hope they weren't telling you to stop working on Python! You seem made for this work... --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From tim_one at email.msn.com Thu Jul 27 18:59:04 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 12:59:04 -0400 Subject: Refcount vs GC semantics (was RE: [Python-Dev] Product iteration) In-Reply-To: Message-ID: Plea: could we try to get an accurate subject line on at least 1 msg in 10? Thanks. [Moshe] > I know, and I'm not. But the thing is, there are plenty of users of > CPython which do rely on this feature -- so you're going to break > people's code. Not nice. [Mark Hammond] > No - we will simply be pointing out their already broken code. We > arent breaking anything! > > I have no problem with this at all. The sooner we point out the > broken code the better. The last thing we want is for obviously and > documented broken code to suddenly be considered non-broken simply by > the volume of poor code out there... Spoken like a man who has never maintained a language implementation used by hordes of unhappy users <0.5 wink>. The bitching about "breaking" .append(1,2,3) was nothing compared to what this would stir up, and when the first "important" customer seriously threatens to walk, vendors usually back down out of a healthy sense of self-preservation. Been there so many times it even makes me want to puke . > Either way, I think you are overstating the problem. I agree with that too. I don't think CPython could get away with this, but you have a new implementation and users will see this as a basis on which they compete. The *convenience* of CPython's (accidental but real!) semantics here is undeniable. Still, I don't see it coming up much except wrt temp files, and if that becomes An Issue for you, you can always special-case the snot out of them. users-don't-read-manuals-but-they-do-pay-the-bills-ly y'rs - tim From ping at lfw.org Thu Jul 27 19:10:51 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 27 Jul 2000 10:10:51 -0700 (PDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 27 Jul 2000, Guido van Rossum wrote: > Second, what should happen to a slice assignment? My vote is: nothing! (Read on.) > The basic slice form is: > > a[i:j] += b What does this mean? I don't see how it could be any different from: a[j:j] = b If people want to insert sequences into other sequences, they should use this form; if they want to insert an element into a sequence, they should be encouraged to use an .insert() method. In other words, we already have perfectly good ways of doing this (more importantly, there are already clear and simple ways to implement such behaviour in your own objects). > a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] += 1 What on earth could this mean? And why would anyone want it? I can't even imagine what the simpler case a[i:j:k] += 1 would do... unless you wish to propose element-wise operators (e.g. add 1 to each of the elements that would participate in the slice) and i think that might be a whole new can of worms. It wasn't clear to me that this was your intent, though. It looks to me like going through various contortions to support augmented assignment to slices is not going to be worth the trouble. May i suggest >>> a[i:j] += b SyntaxError: augmented assignment to a slice is not allowed just like >>> (a, b, c) += 1,2,3 SyntaxError: augmented assignment to a tuple is not allowed ? -- ?!ng From effbot at telia.com Thu Jul 27 19:20:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 19:20:05 +0200 Subject: [Python-Dev] [ Patch #100990 ] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> <200007271341.IAA09455@cj20424-a.reston1.va.home.com> <006901bff7d3$c06d1e40$f2a6b5d4@hagrid> Message-ID: <017901bff7ee$eadb9740$f2a6b5d4@hagrid> > my proposal is to tighten this up in 2.0: ifdef out the UTF-16 > code in the UTF-8 decoder, and ifdef out the UTF-16 stuff in > the compare function. > patch coming. http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100990&group_id=5470 From ping at lfw.org Thu Jul 27 19:25:38 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 27 Jul 2000 10:25:38 -0700 (PDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271725.MAA17990@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 27 Jul 2000, Guido van Rossum wrote: > I suppose we could inspect the __getslice__ method's argument count > (it *is* available somewher) but that seems a hack (and could still > break if default arguments were used for something else). Yuck! > Another solution: require a class variable to indicate the class's > awareness: e.g. you must define __getslice_takes_three_args__ when > __getslice__(lo, hi, step) is supported, otherwise the call goes to > __getitem__(slice(lo, hi, step)). Here's another solution: if you're going to revamp the whole item/slice-getting interface, which is what this pretty much amounts to, use a separate interface. Old interface: __getitem__(index) # I get an ITEM. __getitem__(slice-object) # I get a SLICE or an ITEM. (!) __getslice__(lo, hi, step) # I get a SLICE. New interface: __get__(index) # I get an ITEM. __get__(slice-object) # I get a SLICE or an ITEM. (!) To be honest, the whole collision between slices and items makes me rather uncomfortable. I would prefer to separate them: one method for getting *items*, one method for getting *slices*. Neither of the interfaces above handles this correctly for the case of multidimensional arrays. So, how about: __get__(index, ...) # I want an ITEM. __getslice__(slice-object, ...) # I want a SLICE. I think an interface like this would be much easier to program against. The return value is better defined: __get__ always returns a single item; __getslice__ always returns some kind of collection of items (usually, if not always, the same type as the original collection being sliced). This would require detection of whether any of the components of a multidimensional (i.e. tuple) index were slices, but i think the improved consistency is well worth it. __getslice__ is called if any slices are involved; __get__ is called otherwise. Here are some examples for illustration: a[i] a.__get__(i) a[i, j] a.__get__(i, j) a[i:j] a.__getslice__(slice(i, j)) a[i:j:k] a.__getslice__(slice(i, j, k)) a[i, j, k] a.__get__(i, j, k) a[i, j, k:l] a.__getslice__(i, j, slice(k, l)) I can't imagine ever wanting to define custom behaviour for __getslice__ *without* implementing __get__ or __getitem__, so the presence of a __get__ method can be used to detect whether we should use the new interface. -- ?!ng From tim_one at email.msn.com Thu Jul 27 19:17:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 13:17:22 -0400 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007270611.BAA04802@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > ... > Note that C doesn't guarantee that a++ is atomic either, even if a is > declared volatile. For people who don't know, or may have forgotten, threads are not a part of std C or C++: those languages say nothing whatsoever about behavior in the presence of threads. And this is still true in C99! ANSI/ISO committees work by consensus, and there are so many goofy thread models out there consensus will never be reached (keep that in mind as you ponder how PEPs should proceed <0.6 wink>). > (I believe there's an atomic data type, but I don't think it > guarantees atomic ++. You may be thinking of sig_atomic_t? That relates to a technical meaning for "atomic" in signal handlers, a meaning that has nothing to do with threads. In effect, sig_atomic_t is simply a volatile integral type small enough so that read and write each take one machine instruction (so, e.g., a 64-bit int would not serve as a suitable sig_atomic_t on a 32-bit machine, as it would have to be read and written "in pieces", and an interrupting signal could cause an interrupted read or write to use inconsistent pieces). From ping at lfw.org Thu Jul 27 19:31:56 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 27 Jul 2000 10:31:56 -0700 (PDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Message-ID: On Thu, 27 Jul 2000, Ka-Ping Yee wrote: > So, how about: > > __get__(index, ...) # I want an ITEM. > __getslice__(slice-object, ...) # I want a SLICE. Addendum: For __set__ and __setslice__, since there may be a variable number of index arguments, it seems the value to set must *precede* the indices. The full interface: __get__(*indices) __set__(value, *indices) __del__(*indices) __getslice__(*slices) __setslice__(value, *slices) __delslice__(*slices) I prefer putting the indices last to passing in a tuple of indices for the following reasons: 1. It would be annoying and slightly slower to have to declare __get__((index,)) instead of __get__(index). 2. I want to encourage prediction of the number of indices. Since most multidimensional types are likely to have a fixed number of dimensions, it's better to have an interface look like, e.g. __get__(x, y, z) # Clearly a 3-dimensional array! instead of __get__(indices) # Don't know how many dimensions. The error is caught earlier, and the expectations of the programmer are more visible. To implement a variable number of dimensions, of course one can always write __get__(*indices) but this would not be the conventional thing to write: it would make clear that there is something special going on here. -- ?!ng From tim_one at email.msn.com Thu Jul 27 19:26:31 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 13:26:31 -0400 Subject: [Python-Dev] test_fork1 on SMP? In-Reply-To: <20000727092144.R266@xs4all.nl> Message-ID: [Thomas Wouters] > ... > And anyway, I thought the test_fork1 test tested for fork() behaviour in > threads. It spawns a thread, Four threads, actually. > fork()s one of those threads, It forks "the main" thread, which is in addition to the four it spawns. > and tests to see if the other threads still exist after the fork(), > in the new child. The entire test is done in Python code, so how > the scheduler and/or race conditions come into play isn't too > obvious to me. Except of course the whole test if flawed. The test uses loops and time.sleep instead of proper synchronization, so its behavior is at best probabilistic, depending entirely on timing accidents (*likely* accidents, but accidents all the same). But I don't have a machine here that supports fork at all, so I can't run it, and I don't know how it fails on the machines it fails on. If it's failing with a thread exiting with a non-zero exit code, then I'd say the timing uncertainties in the *Python* code are irrelevant, and it's the failing platform's fork implementation that's broken. From bckfnn at worldonline.dk Thu Jul 27 20:01:01 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Thu, 27 Jul 2000 18:01:01 GMT Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <397FF146.2D307063@lemburg.com> References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> Message-ID: <398065f3.6724599@smtp.worldonline.dk> [M.-A. Lemburg] >BTW, does Java support UCS-4 ? If not, then Java is wrong >here ;-) Java claims to use unicode 2.1 [*]. I couldn't locate anything describing if this is UCS-2 or UTF-16. I think unicode 2.1 includes UCS-4. The actual level of support for UCS-4 is properly debatable. - The builtin char is 16bit wide and can obviously not support UCS-4. - The Character class can report if a character is a surrogate: >>> from java.lang import Character >>> Character.getType("\ud800") == Character.SURROGATE 1 - As reported, direct string comparison ignore surrogates. - The BreakIterator does not handle surrogates. It does handle combining characters and it seems a natural place to put support for surrogates. - The Collator class offers different levels of normalization before comparing string but does not seem to support surrogates. This class seems a natural place for javasoft to put support for surrogates during string comparison. These findings are gleaned from the sources of JDK1.3 [*] http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#25310 regards, finn From tim_one at email.msn.com Thu Jul 27 20:20:26 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 14:20:26 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <20000727075058.A25450@keymaster.enme.ucalgary.ca> Message-ID: [Neil Schemenauer] > Here is some code that seems to hang on Linux UP machines. > Sometimes it prints PIDS for a while and other times it stops > after only a few. Well, that sucks! Does "UP" mean uniprocessor in this context? > I don't know if that counts. I raised this issue over a month > ago. Tim, your getting forgetful. :) Getting? I'm very old. I think. But even if I had a memory, I usually ignore Unix-specific posts (i.e., I can't run code with a .fork(), so can only sit back & admire the perversity of those who both can & do ). From billtut at microsoft.com Thu Jul 27 20:23:27 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 11:23:27 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD343@RED-MSG-50> > umm. the Java docs I have access to doesn't mention surrogates > at all (they do point out that a character is 16-bit, and they don't > provide an \U escape). When Java does support surrogates, it seems likely that for backward compatibility reasons that they'll start paying attention to surrogates. Altering to a 32-bit int would break too much of their users code. > on the other hand, MSDN says: > Windows 2000 provides support for basic input, output, and > simple sorting of surrogates. However, not all Windows 2000 > system components are surrogate compatible. Also, surrogates > are not supported in Windows 95/98 or in Windows NT 4.0. > and then mentions all the usual problems with variable-width > encodings... Which means it supports UTF-16, and the support can only get better. > > > after all, if variable-width internal storage had been easy to deal > > > with, we could have used UTF-8 from the start... (and just like > > > the Tcl folks, we would have ended up rewriting the whole thing > > > in the next release ;-) > >=20 > > Oh please, UTF-16 is substantially simpler to deal with than UTF-8. > in what way? as in "one or two words" is simpler than "one, two, > three, four, five, or six bytes"? > or as in "nobody will notice anyway..." ;-) As in it's very easy to determine arbitrarily which byte of the surrogate you're dealing with based on its 16-bit value. You can't say that about UTF-8. > if UCS-2/BMP was good enough for NT 4.0, Unicode 1.1, and Java 1.0, > it's surely good enough for Python 2.0 ;-) > > (and if I understand things correctly, 2.1 isn't that far away...) They were, since UTF-16 didn't exist at the time. :) I think we both want Python's unicode support to eventually support surrogate range characters. Let me see if I can reiterate what we're both trying to say. What you're saying: * We might switch to UCS-4 when we support this extra stuff because variable length encodings are annoying. My counter point: Switching to UCS-4 isn't backward compatible. If you want to avoid variable length encoding then start with UCS-4 from the beginning. BUT, keeping in mind that Windows, and Java are either right now, or likely to be UTF-16 systems. What I'm saying: * Just use UTF-16 and be done with it. Windows is using it, and Java if it isn't already is definitely likely to do so. Your counter point: Supporting UTF-16 is complicated, and we don't want to do all of this for Python 2.0. (Especially anything that involves writing a Unicode string object that hides the surrogate as two 16-bit entities) My response: This is true. I've never suggested we do all of the UTF-16 support for Python 2.0. The UTF-16 code point order comparision patch I submitted was just something I noticed online, and submitted the patch more for feedback and comments rather then wanting, or needing the patch to get in. However, that doesn't mean bad things will happen if we allow the UTF-8/16 (en/de)coders handle surrogate characters. The Python code can worry about this variable length encoding on its own. The core should still be able to UTF-8 the unicode string so that it can be pickled however. Did I get what you're saying right, and do you understand what I'm getting at? Bill -----Original Message----- From: Fredrik Lundh [mailto:effbot at telia.com] Sent: Thursday, July 27, 2000 8:35 AM To: Bill Tutt Cc: python-dev at python.org Subject: Re: [Python-Dev] UTF-16 code point comparison This message uses a character set that is not supported by the Internet Service. To view the original message content, open the attached message. If the text doesn't display correctly, save the attachment to disk, and then open it using a viewer that can display the original character set. << File: message.txt >> From billtut at microsoft.com Thu Jul 27 20:29:34 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 11:29:34 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD344@RED-MSG-50> > From: bckfnn at worldonline.dk [mailto:bckfnn at worldonline.dk] > - The BreakIterator does not handle surrogates. It does handle > combining characters and it seems a natural place to put support > for surrogates. > - The Collator class offers different levels of normalization before > comparing string but does not seem to support surrogates. This class > seems a natural place for javasoft to put support for surrogates > during string comparison. Both of these aren't surprising given that there aren't any officially allocated characters in surrogate land (but they're coming fast), and the most likely first allocations are to the combined CJK glyph space which doesn't really have anything to collate. :) Bill From tim_one at email.msn.com Thu Jul 27 20:36:23 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 14:36:23 -0400 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33C@RED-MSG-50> Message-ID: [Guido] >> Why? Because I don't want to proliferate code that explicitly traps >> 0xD800-0xDFFF throughout the code. [Bill Tutt] > Err... I don't think you have much choice in the long term. When the Unicode push started, it was agreed that we would ignore surrogates "for now". I sounded a caution then that I will repeat: the Unicode folks made a bad engineering decision, based on the (Eurocentric) assumption that 64K was a large enough space to meet their stated goals. Don't know how long it will take this half of the world to realize it, but UCS-4 is inevitable. From tim_one at email.msn.com Thu Jul 27 20:41:15 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 14:41:15 -0400 Subject: [Python-Dev] more unicode: \U support? In-Reply-To: <012f01bff7e2$e0443820$f2a6b5d4@hagrid> Message-ID: [/F] > would it be a good idea to add \UXXXXXXXX > (8 hex digits) to 2.0? > > (only characters in the 0000-ffff range would > be accepted in the current version, of course). In which case there seems darned little point to it now . From guido at beopen.com Thu Jul 27 21:44:42 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 14:44:42 -0500 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: Your message of "Thu, 27 Jul 2000 14:36:23 -0400." References: Message-ID: <200007271944.OAA29768@cj20424-a.reston1.va.home.com> > When the Unicode push started, it was agreed that we would ignore surrogates > "for now". I sounded a caution then that I will repeat: the Unicode folks > made a bad engineering decision, based on the (Eurocentric) assumption that > 64K was a large enough space to meet their stated goals. Don't know how > long it will take this half of the world to realize it, but UCS-4 is > inevitable. If we can put it off long enough until RAM and disk space have become twice as cheap, I'm happy. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From billtut at microsoft.com Thu Jul 27 20:52:04 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 11:52:04 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD345@RED-MSG-50> > From: Tim Peters [mailto:tim_one at email.msn.com] > When the Unicode push started, it was agreed that we would ignore surrogates > "for now". I sounded a caution then that I will repeat: the Unicode folks > made a bad engineering decision, based on the (Eurocentric) assumption that > 64K was a large enough space to meet their stated goals. Don't know how > long it will take this half of the world to realize it, but UCS-4 is > inevitable. On new systems perhaps, but important existing systems (Win32, and probably Java) are stuck with that bad decision and have to use UTF-16 for backward compatability purposes. Surrogates aren't as far out as you might think. (The next rev of the Unicode spec) That's certainly sooner than Win32 going away. :) Bill From effbot at telia.com Thu Jul 27 21:04:36 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 21:04:36 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0160.txt,1.3,1.4 References: <200007271846.LAA27298@slayer.i.sourceforge.net> Message-ID: <021d01bff7fd$8258afa0$f2a6b5d4@hagrid> fred wrote: > Remove the ugly form-feed characters some people use with Emacs. note that those "ugly" form-feeds become nice
and

in the HTML versions... From effbot at telia.com Thu Jul 27 21:05:01 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 21:05:01 +0200 Subject: [Python-Dev] more unicode: \U support? References: Message-ID: <021e01bff7fd$93c34de0$f2a6b5d4@hagrid> tim wrote: > [/F] > > would it be a good idea to add \UXXXXXXXX > > (8 hex digits) to 2.0? > > > > (only characters in the 0000-ffff range would > > be accepted in the current version, of course). > > In which case there seems darned little point to it now . with Python's approach to escape codes, it's not exactly easy to *add* a new escape code -- you risk breaking code that for some reason (intentional or not) relies on u"\U12345678" to end up as a backslash followed by 9 characters... not very likely, but I've seen stranger things... (btw, can you walk over to Guido's office and tell him why \x should ignore anything but the last two hex digits, no matter what string type we're using...) From bwarsaw at beopen.com Thu Jul 27 21:24:38 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 27 Jul 2000 15:24:38 -0400 (EDT) Subject: [Python-Dev] PEP 201, zip() builtin Message-ID: <14720.35958.632383.574511@anthem.concentric.net> Folks, Here is the latest PEP 201, updated based on conversations with Guido yesterday. Notice that there are no more Open Issues. See instead the BDFL Pronouncements section. Plan on seeing a C-based implementation checked into the CVS devel tree soon. If you want to comment on this PEP, you must include "PEP 201" in the Subject: header. Enjoy, -Barry -------------------- snip snip -------------------- PEP: 201 Title: Parallel Iteration Version: $Revision: 1.10 $ Author: bwarsaw at beopen.com (Barry A. Warsaw) Python-Version: 2.0 Status: Draft Created: 13-Jul-2000 Post-History: 27-Jul-2000 Introduction This PEP describes the `parallel iteration' proposal for Python 2.0, previously known as `parallel for loops'. This PEP tracks the status and ownership of this feature, slated for introduction in Python 2.0. It contains a description of the feature and outlines changes necessary to support the feature. This PEP summarizes discussions held in mailing list forums, and provides URLs for further information, where appropriate. The CVS revision history of this file contains the definitive historical record. Motivation Standard for-loops in Python iterate over every element in a sequence until the sequence is exhausted[1]. However, for-loops iterate over only a single sequence, and it is often desirable to loop over more than one sequence, in a lock-step, "Chinese Menu" type of way. The common idioms used to accomplish this are unintuitive and inflexible. This PEP proposes a standard way of performing such iterations by introducing a new builtin function called `zip'. Parallel For-Loops Parallel for-loops are non-nested iterations over two or more sequences, such that at each pass through the loop, one element from each sequence is taken to compose the target. This behavior can already be accomplished in Python through the use of the map() built-in function: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> for i in map(None, a, b): print i ... (1, 4) (2, 5) (3, 6) >>> map(None, a, b) [(1, 4), (2, 5), (3, 6)] The for-loop simply iterates over this list as normal. While the map() idiom is a common one in Python, it has several disadvantages: - It is non-obvious to programmers without a functional programming background. - The use of the magic `None' first argument is non-obvious. - It has arbitrary, often unintended, and inflexible semantics when the lists are not of the same length: the shorter sequences are padded with `None'. >>> c = (4, 5, 6, 7) >>> map(None, a, c) [(1, 4), (2, 5), (3, 6), (None, 7)] For these reasons, several proposals were floated in the Python 2.0 beta time frame for providing a better spelling of parallel for-loops. The initial proposals centered around syntactic changes to the for statement, but conflicts and problems with the syntax were unresolvable, especially when parallel for-loops were combined with another proposed feature called `list comprehensions' (see pep-0202.txt). The Proposed Solution The proposed solution is to introduce a new built-in sequence generator function, available in the __builtin__ module. This function is to be called `zip' and has the following signature: zip(seqa, [seqb, [...]]) zip() takes one or more sequences and weaves their elements together, just as map(None, ...) does with sequences of equal length. The weaving stops when the shortest sequence is exhausted. Return Value zip() returns a real Python list, the same way map() does. Examples Here are some examples, based on the reference implementation below. >>> a = (1, 2, 3, 4) >>> b = (5, 6, 7, 8) >>> c = (9, 10, 11) >>> d = (12, 13) >>> zip(a, b) [(1, 5), (2, 6), (3, 7), (4, 8)] >>> zip(a, d) [(1, 12), (2, 13)] >>> zip(a, b, c, d) [(1, 5, 9, 12), (2, 6, 10, 13)] Note that when the sequences are of the same length, zip() is reversible: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> x = zip(a, b) >>> y = zip(*x) # alternatively, apply(zip, x) >>> z = zip(*y) # alternatively, apply(zip, y) >>> x [(1, 4), (2, 5), (3, 6)] >>> y [(1, 2, 3), (4, 5, 6)] >>> z [(1, 4), (2, 5), (3, 6)] >>> x == z 1 It is not possible to reverse zip this way when the sequences are not all the same length. Reference Implementation Here is a reference implementation, in Python of the zip() built-in function. These would ultimately be replaced by equivalent C code. def zip(*args): if not args: raise TypeError('zip() expects one or more sequence arguments') ret = [] # find the length of the shortest sequence shortest = min(*map(len, args)) for i in range(shortest): item = [] for s in args: item.append(s[i]) ret.append(tuple(item)) return ret BDFL Pronouncements Note: the BDFL refers to Guido van Rossum, Python's Benevolent Dictator For Life. - The function's name. An earlier version of this PEP included an open issue listing 20+ proposed alternative names to zip(). In the face of no overwhelmingly better choice, the BDFL strongly prefers zip() due to it's Haskell[2] heritage. See version 1.7 of this PEP for the list of alteratives. - zip() shall be a built-in function. - Optional padding. An earlier version of this PEP proposed an optional `pad' keyword argument, which would be used when the argument sequences were not the same length. This is similar behavior to the map(None, ...) semantics except that the user would be able to specify pad object. This has been rejected by the BDFL in favor of always truncating to the shortest sequence. - Lazy evaluation. An earlier version of this PEP proposed that zip() return a built-in object that performed lazy evaluation using __getitem__() protocol. This has been strongly rejected by the BDFL in favor of returning a real Python list. If lazy evaluation is desired in the future, the BDFL suggests an xzip() function be added. - zip() with no arguments. the BDFL strongly prefers this raise a TypeError exception. - zip() with one argument. the BDFL strongly prefers that this return a list of 1-tuples. - Inner and outer container control. An earlier version of this PEP contains a rather lengthy discussion on a feature that some people wanted, namely the ability to control what the inner and outer container types were (they are tuples and list respectively in this version of the PEP). Given the simplified API and implementation, this elaboration is rejected. For a more detailed analysis, see version 1.7 of this PEP. References [1] http://www.python.org/doc/current/ref/for.html [2] http://www.haskell.org/onlinereport/standard-prelude.html#$vzip TBD: URL to python-dev archives Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: From fdrake at beopen.com Thu Jul 27 21:23:27 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 27 Jul 2000 15:23:27 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0160.txt,1.3,1.4 In-Reply-To: <021d01bff7fd$8258afa0$f2a6b5d4@hagrid> References: <200007271846.LAA27298@slayer.i.sourceforge.net> <021d01bff7fd$8258afa0$f2a6b5d4@hagrid> Message-ID: <14720.35887.525712.225755@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > note that those "ugly" form-feeds become nice
and

> in the HTML versions... They are no longer needed for that. I tossed the
because I thought it was ugly and distracting, but that can be changed if people prefer to have them. The

for headings is there. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nascheme at enme.ucalgary.ca Thu Jul 27 21:23:22 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 27 Jul 2000 13:23:22 -0600 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: ; from Tim Peters on Thu, Jul 27, 2000 at 02:20:26PM -0400 References: <20000727075058.A25450@keymaster.enme.ucalgary.ca> Message-ID: <20000727132322.A27400@keymaster.enme.ucalgary.ca> On Thu, Jul 27, 2000 at 02:20:26PM -0400, Tim Peters wrote: > [Neil Schemenauer] > > Here is some code that seems to hang on Linux UP machines. > > Sometimes it prints PIDS for a while and other times it stops > > after only a few. > > Well, that sucks! Does "UP" mean uniprocessor in this context? Yes. Neil From bwarsaw at beopen.com Thu Jul 27 21:27:43 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 27 Jul 2000 15:27:43 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0160.txt,1.3,1.4 References: <200007271846.LAA27298@slayer.i.sourceforge.net> <021d01bff7fd$8258afa0$f2a6b5d4@hagrid> Message-ID: <14720.36143.764784.551163@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: >> Remove the ugly form-feed characters some people use with >> Emacs. | note that those "ugly" form-feeds become nice
and

| in the HTML versions... This was a compromise between Jeremy and I (PEP 1 co-authors). No form-feeds, but section headers start in column 0 while the bodies start indented 4 spaces. -Barry From tim_one at email.msn.com Thu Jul 27 21:26:03 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 15:26:03 -0400 Subject: [Python-Dev] more unicode: \U support? In-Reply-To: <021e01bff7fd$93c34de0$f2a6b5d4@hagrid> Message-ID: [/F] > would it be a good idea to add \UXXXXXXXX > (8 hex digits) to 2.0? > > (only characters in the 0000-ffff range would > be accepted in the current version, of course). [Tim] > In which case there seems darned little point to it now . [/F] > with Python's approach to escape codes, it's not exactly easy > to *add* a new escape code -- you risk breaking code that for > some reason (intentional or not) relies on u"\U12345678" to end > up as a backslash followed by 9 characters... > > not very likely, but I've seen stranger things... Ah! You're right, I'm wrong. +1 on \U12345678 now. > (btw, can you walk over to Guido's office and tell him why \x > should ignore anything but the last two hex digits, no matter > what string type we're using...) No, but I can mail to his office, and am doing so. Guido, are you opposing us on this? If so, it would save time if you explained just the specific point you're wrong about . From esr at thyrsus.com Thu Jul 27 21:56:03 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jul 2000 15:56:03 -0400 Subject: [Python-Dev] PEP 201 In-Reply-To: <14720.35958.632383.574511@anthem.concentric.net>; from bwarsaw@beopen.com on Thu, Jul 27, 2000 at 03:24:38PM -0400 References: <14720.35958.632383.574511@anthem.concentric.net> Message-ID: <20000727155603.D9683@thyrsus.com> Barry A. Warsaw : > Here is the latest PEP 201, updated based on conversations with Guido > yesterday. Notice that there are no more Open Issues. Excellent. I have no remaining issues or hesitations about this PEP and am happy to see it resolved. Three cheers for Guido and everybody else who worked hard to make this fly! -- Eric S. Raymond The right to buy weapons is the right to be free. -- A.E. Van Vogt, "The Weapon Shops Of Isher", ASF December 1942 From tim_one at email.msn.com Thu Jul 27 21:45:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 15:45:47 -0400 Subject: [Python-Dev] PEP 201, zip() builtin In-Reply-To: <14720.35958.632383.574511@anthem.concentric.net> Message-ID: [Barry A. Warsaw] > -------------------- snip snip -------------------- > PEP: 201 > Title: Parallel Iteration Could we please change "Parallel" to, e.g., "Lockstep" throughout? Greg Wilson correctly pointed out that "parallel" in the context of loops means something very different to the scientific branch of the Python community. Easier to fix this now that after it's spread to the docs. > ... > However, for-loops iterate over only a single sequence, and it > is often desirable to loop over more than one sequence, in a > lock-step, "Chinese Menu" type of way. Just as you realized how inappropriate "parallel" was right here . > # find the length of the shortest sequence > shortest = min(*map(len, args)) Clearer as > shortest = min(map(len, args)) However, this implies that all sequences must tell the truth about their lengths, but the iteration protocol actually terminates via a sequence raising IndexError. I believe we want zip to follow the iteration protocol, in effect breaking out of the outer loop as soon as some s[i] raises IndexError. This was agreed to by all (incl. the BDFL) in some other year's debates over this. > prefers zip() due to it's Haskell[2] heritage. See version 1.7 "its", not "it's" > - Lazy evaluation. An earlier version of this PEP proposed that > zip() return a built-in object that performed lazy evaluation > using __getitem__() protocol. This has been strongly rejected > by the BDFL in favor of returning a real Python list. If lazy > evaluation is desired in the future, the BDFL suggests an xzip() > function be added. Which he'll then fight tooth and nail . > ... Nice job, Barry! Thank you. From guido at beopen.com Thu Jul 27 22:49:01 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 15:49:01 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 10:10:51 MST." References: Message-ID: <200007272049.PAA30143@cj20424-a.reston1.va.home.com> [Guido] > > Second, what should happen to a slice assignment? [Ping] > My vote is: nothing! (Read on.) > > > The basic slice form is: > > > > a[i:j] += b > > What does this mean? I don't see how it could be any different from: > > a[j:j] = b Apparently you haven't used NumPy arrays (matrices). I haven't either, but I hear they overload + so that A+B is elementwise addition, and you can write A+1 to add 1 to each element of A. Thus, for a NumPy programmer, A += 1 would certainly look like A = A+1, and similar for A += B. > It looks to me like going through various contortions to support > augmented assignment to slices is not going to be worth the trouble. > > May i suggest > > >>> a[i:j] += b > SyntaxError: augmented assignment to a slice is not allowed That's what I thought too until I realized that for NumPy arrays slice+= makes sense. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Vladimir.Marangozov at inrialpes.fr Thu Jul 27 21:55:06 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 27 Jul 2000 21:55:06 +0200 (CEST) Subject: [Python-Dev] PEP 201, zip() builtin In-Reply-To: <14720.35958.632383.574511@anthem.concentric.net> from "Barry A. Warsaw" at Jul 27, 2000 03:24:38 PM Message-ID: <200007271955.VAA03850@python.inrialpes.fr> Barry A. Warsaw wrote: > > > Folks, > > Here is the latest PEP 201, updated based on conversations with Guido > yesterday. Notice that there are no more Open Issues. See instead > the BDFL Pronouncements section. Plan on seeing a C-based > implementation checked into the CVS devel tree soon. > > If you want to comment on this PEP, you must include "PEP 201" in the > Subject: header. Yes! I have a comment: "Long live BDFL!!!" Happy to see the 1st PEP closed! moving-forward'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas at xs4all.net Thu Jul 27 22:05:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 22:05:08 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271730.MAA21788@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 12:30:51PM -0500 References: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> <20000727182248.V266@xs4all.nl> <200007271730.MAA21788@cj20424-a.reston1.va.home.com> Message-ID: <20000727220508.C224@xs4all.nl> On Thu, Jul 27, 2000 at 12:30:51PM -0500, Guido van Rossum wrote: > > Actually, it wasn't the feebleness as much as the two different things you > > seem to be wanting, Guido ;) Previously (in another thread, and perhaps in > > the start of this thread as well) you argued that an index should always > > call __getitem__, with a slice object if it's a slice of some kind, *even a > > basic one*. So that we lose __getslice__ and rather teach people to use > > __getslice__. > That would be nice, but it would be b/w incompatible, so now we're > trying (again) to figure out how to still support __getslice__. My > proposal is to try and be b/w compatible if __getslice__ exists. See > my previous mail. Yes. So what we're talking about is a better way to do indexing all together, all types in one shot. ('indexes', 'slices' and 'collections' ? I'm not sure how to name the first and the last one, if not that.) And not just indexing, but setting and deleting at the same time, right ? So the most preferred way is to pass a single argument which is either: - A single object (directly what was passed in) for a single index. - A slice-object if any kind of single-slice was passed in, which holds the zero-to-three objects that the slice was 'created' with. - A tuple of zero or more of either of the above two. While I'm writing this down, I'm not sure if it's such a good idea. Isn't this placing a tad too much into one function ? It might require some severe logic to support this all, especially if you give 'special' meanings to some indexes. And we're inserting a new catch-all method -- a set of them, actually: get, set and del -- and that while Paul is trying to solve the other catch-all Python has, __getattr__/__setattr__. Then again, the use of this method is quite different from __getattr__/__setattr__... Most classes will commit to either a sequence-type or a mapping-type, and not even bother with extended slices or tuple-indexes. And lets not forget the convenience of writing those methods: __getitem__ is intuitive, both in name and semantics. So is __getslice__. The passing of a slice object to __getitem__ is a tad less intuitive, and a tuple of index/slice objects even less. I'm tempted to suggest a single change: when __getslice__ is not defined, pass a slice object (with no step, as if the slice had a trailing ':') to __getitem__, and document it properly. (and make builtin objects accept sliceobjects too !) Perhaps try to slowly deprecate getslice__. Give plenty __of examples of using __getitem__ and slice objects in the standard documentation. Also, I think it makes sense to make slice objects indexable, so that you can do: start, end, step = sliceobj instead of the less intuitive start, end, step = sliceobj.start, sliceobj.end, sliceobj.step But I've never used slice objects myself, so I can't really say whether it's a good idea. I suspect this is all for 2.1 or later, though. (As for what ?!ng suggested, the variable-args __hooks__, I don't see a difference between __getitem__(self, *val) and __getitem__(self, val) where val is a tuple. The same reasoning stands.) > > So now you want to *extend* the 'special case' to extended, 3-argument > > slices, but *not* Ellipses and tupled-slices (which aren't really tuples, > > because you can do (1, 2:5, ...)) -- or am I reading this wrong ? :) > > Not sure what you mean by that. (1, 2:5, ...) by itself is illegal > syntax; the special slice syntax can only occur directly in an > indexing context, e.g. a[1, 2:5, ...]. Exactly my point ;P Ferget it, not important. What I was trying to say was that: x[1, 2, 4:10:2] isn't the same as x[(1, 2, 4:10:2)] So the first isn't really indexing with a tuple -- because you can't do the 2nd. But the result as passed to __getitem__ *is* a tuple, so forget what I said ;) > > Don't worry, Guido, it isn't just you, I failed to grasp what those managers > > were trying to tell me today, too... I may just be too dense, today. > I hope they weren't telling you to stop working on Python! You seem > made for this work... Heh, nono, they don't have any say over what I do with Python. I'd force them to join the Python Consortium before I'd let them have any say over that ;) I don't do any *work* with Python, other than waiting for Barry to bring Mailman 2.0 out of beta so we can start a 'product line' on that, instead of Majordomo. It has nothing to do with Python but everything with my colleagues ;-) In fact, the only people who even know what Python is are my direct colleagues, my co-System-administrators, one of which is my direct boss. I didn't even see those people today, because half the meetings today and yesterday were with a bunch of product developers and the senior VP of technology (that's his translated title), and the other half was with the workers council, the management team and the CEO (sort of) of the company. And besides, even if they did try to tell me to stop with Python, it would go like the first episode of Red Dwarf, where Lister comes out of stasis and Holly, the shipboard computer, tries to tell him everyone's dead and he's been in stasis for 3 million years. "So where is everyone, Hol ?" "They're dead, Dave." "Who, the captain ?" "Everyone, Dave." "What, Petersen ?" "Yes, Dave. Everyone. Everyone is dead." "Not Kochansky!" "Yes, Dave. Everyone is dead. Dead is everyone. Is everyone dead. Dead everyone is." "Wait. What are you trying to tell me here, Hol ?" "You have to quit with Python, even in your free time." "What are you trying to tell me ?" ... And if that failed, I'd quit. I don't work here to get dictated how to do my work, and I certainly don't work here to get dictated how to live my life *outside* of work. I realize that's how PythonLabs operates but it's not how we run things in the old country, Guido ! :) No, all work I did and am doing on and with Python was hobby work. Which is just fine with me, for the moment, because it means I can slow down the pace whenever I want to. (Not that I've had that urge yet.) Can't-imagine-working-full-time-on-or-with-Python---two-week-bliss!- -seven-week-burnout-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Thu Jul 27 22:12:42 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 22:12:42 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: ; from ping@lfw.org on Thu, Jul 27, 2000 at 10:10:51AM -0700 References: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> Message-ID: <20000727221242.W266@xs4all.nl> On Thu, Jul 27, 2000 at 10:10:51AM -0700, Ka-Ping Yee wrote: > On Thu, 27 Jul 2000, Guido van Rossum wrote: > > The basic slice form is: > > > > a[i:j] += b > What does this mean? I don't see how it could be any different from: > a[j:j] = b a[i:j] += b means exactly the same as: a[i:j] = a[i:j] + b Whether it does anything other than raising an exception depends entirely on the types of a and b ! > I can't even imagine what the simpler case > a[i:j:k] += 1 > would do... unless you wish to propose element-wise operators (e.g. > add 1 to each of the elements that would participate in the slice) That's entirely user-defined. Augmented assignment simply extends Pythons extremely liberal (my cultural heritage tempts me to say 'communist';) semantics in these cases. a[i:j:k] += 1 is exactly a[i:j:k] = a[i:j:k] + 1 If 'a' is a Python class, this would turn into (forgetting about order of evaluation, for a second): a.__setitem__(slice(i, j, k), a[slice(i, j, k)].__add_ab__(1)) > It looks to me like going through various contortions to support > augmented assignment to slices is not going to be worth the trouble. > May i suggest > >>> a[i:j] += b > SyntaxError: augmented assignment to a slice is not allowed Sure, but it doesn't make sense unless 'a[i:j] = a[i:j] + b' raises similar problems. Why this arbitrary border ? Because you can't imagine people wanting it ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jul 27 22:22:09 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 22:22:09 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <398065f3.6724599@smtp.worldonline.dk> Message-ID: <398099F1.B6B1D281@lemburg.com> Finn Bock wrote: > > [M.-A. Lemburg] > > >BTW, does Java support UCS-4 ? If not, then Java is wrong > >here ;-) > > Java claims to use unicode 2.1 [*]. I couldn't locate anything describing if > this is UCS-2 or UTF-16. I think unicode 2.1 includes UCS-4. The actual > level of support for UCS-4 is properly debatable. > > - The builtin char is 16bit wide and can obviously not support UCS-4. > - The Character class can report if a character is a surrogate: > >>> from java.lang import Character > >>> Character.getType("\ud800") == Character.SURROGATE > 1 >>> unicodedata.category(u'\ud800') 'Cs' ... which means the same thing only in Unicode3 standards notation. Make me think: perhaps we should add the Java constants to unicodedata base. Is there a list of those available somewhere ? > - As reported, direct string comparison ignore surrogates. I would guess that this'll have to change as soon as JavaSoft folks realize that they need to handle UTF-16 and not only UCS-2. > - The BreakIterator does not handle surrogates. It does handle > combining characters and it seems a natural place to put support > for surrogates. What is a BreakIterator ? An iterator to scan line/word breaks ? > - The Collator class offers different levels of normalization before > comparing string but does not seem to support surrogates. This class > seems a natural place for javasoft to put support for surrogates > during string comparison. We'll need something like this for 2.1 too: first some standard APIs for normalization and then a few unicmp() APIs to use for sorting. We might even have to add collation sequences somewhere because this is a locale issue as well... sometimes it's even worse with different strategies used for different tasks within one locale, e.g. in Germany we sometimes sort the Umlaut ? as "ae" and at other times as extra character. > These findings are gleaned from the sources of JDK1.3 > > [*] > http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#25310 > Thanks for the infos, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Thu Jul 27 22:23:49 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 22:23:49 +0200 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <200007271944.OAA29768@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 02:44:42PM -0500 References: <200007271944.OAA29768@cj20424-a.reston1.va.home.com> Message-ID: <20000727222349.X266@xs4all.nl> On Thu, Jul 27, 2000 at 02:44:42PM -0500, Guido van Rossum wrote: > > When the Unicode push started, it was agreed that we would ignore surrogates > > "for now". I sounded a caution then that I will repeat: the Unicode folks > > made a bad engineering decision, based on the (Eurocentric) assumption that > > 64K was a large enough space to meet their stated goals. Don't know how > > long it will take this half of the world to realize it, but UCS-4 is > > inevitable. > If we can put it off long enough until RAM and disk space have become > twice as cheap, I'm happy. I think 'speed' is more of an issue than 'price'. (price lowers much faster than speed rises.) However, I have to admit I've been lagging behind on the latest technologies, RAM-bus or SCRAM-jet or whatever they were called, which is supposed to allow a 1Ghz or thereabouts bus-architecture. (Which doesn't make RAM that speed, yet, but at least it evades the current bus bottleneck ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jul 27 22:29:59 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 22:29:59 +0200 Subject: [Python-Dev] more unicode: \U support? References: Message-ID: <39809BC7.FD8E9C35@lemburg.com> Tim Peters wrote: > > [/F] > > would it be a good idea to add \UXXXXXXXX > > (8 hex digits) to 2.0? > > > > (only characters in the 0000-ffff range would > > be accepted in the current version, of course). I don't really get the point of adding \uXXXXXXXX when the internal format used is UTF-16 with support for surrogates. What should \u12341234 map to in a future implementation ? Two Python (UTF-16) Unicode characters ? > [Tim] > > In which case there seems darned little point to it now . > > [/F] > > with Python's approach to escape codes, it's not exactly easy > > to *add* a new escape code -- you risk breaking code that for > > some reason (intentional or not) relies on u"\U12345678" to end > > up as a backslash followed by 9 characters... > > > > not very likely, but I've seen stranger things... > > Ah! You're right, I'm wrong. +1 on \U12345678 now. See http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#100850 for how Java defines \uXXXX... We're following an industry standard here ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Thu Jul 27 22:35:11 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 13:35:11 -0700 Subject: [Python-Dev] more unicode: \U support? Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD347@RED-MSG-50> Actually, it'd be \U10FFFF, no need for 8 digits. Java doesn't support surrogates yet, so what Java does for \u doesn't make any difference. :) \U10FFFF should expand to either one character in UCS-4, or two characters in UTF-16/UCS-2. No particular reason why it can't work for 2.0. This is similar to the UTF-8 issue wrt surrogates. Bill From mwh21 at cam.ac.uk Thu Jul 27 22:41:02 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 27 Jul 2000 21:41:02 +0100 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Guido van Rossum's message of "Thu, 27 Jul 2000 09:12:58 -0500" References: <200007271412.JAA12251@cj20424-a.reston1.va.home.com> Message-ID: Guido van Rossum writes: > > Good idea. Are lists and tuples going to support seq[a:b:c] anytime soon? > > It's on my wish list, but can't be done for 2.0. This would involve the list type implementing the mapping API wouldn't it? This would seem to be a little on the silly side. Never mind; here's a quick-hack patch that "seems to work" for lists: Index: listobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/listobject.c,v retrieving revision 2.83 diff -u -c -r2.83 listobject.c *** listobject.c 2000/07/25 12:56:38 2.83 --- listobject.c 2000/07/27 20:38:50 *************** *** 1400,1405 **** --- 1400,1441 ---- (objobjproc)list_contains, /*sq_contains*/ }; + static PyObject* + list_subscript(PyObject* list, PyObject* item) + { + if (PyInt_Check(item)) { + return list_item((PyListObject*)list,PyInt_AS_LONG(item)); + } else if (PySlice_Check(item)) { + int start, stop, step, cur, i; + PyObject* result; + PyObject* it; + + if (PySlice_GetIndices((PySliceObject*)item,PyList_Size(list),&start,&stop,&step) < 0) { + PyErr_SetString(PyExc_TypeError, "slice indices must be integers"); + return NULL; + } + + result = PyList_New((stop-start)/step+1); + + for (cur = start, i = 0; cur < stop; cur += step, i++) { + it = PyList_GET_ITEM(list,cur); + Py_INCREF(it); + PyList_SET_ITEM(result,i,it); + } + + return result; + } else { + PyErr_SetString(PyExc_TypeError, "list indices must be integers"); + return NULL; + } + }; + + static PyMappingMethods list_as_mapping = { + (inquiry)list_length, + (binaryfunc)list_subscript, + (objobjargproc)NULL + }; + PyTypeObject PyList_Type = { PyObject_HEAD_INIT(&PyType_Type) 0, *************** *** 1414,1420 **** (reprfunc)list_repr, /*tp_repr*/ 0, /*tp_as_number*/ &list_as_sequence, /*tp_as_sequence*/ ! 0, /*tp_as_mapping*/ 0, /*tp_hash*/ 0, /*tp_call*/ 0, /*tp_str*/ --- 1450,1456 ---- (reprfunc)list_repr, /*tp_repr*/ 0, /*tp_as_number*/ &list_as_sequence, /*tp_as_sequence*/ ! &list_as_mapping, /*tp_as_mapping*/ 0, /*tp_hash*/ 0, /*tp_call*/ 0, /*tp_str*/ Have I missed anything obvious? I'd upload it to SF, but I don't really want something I've put such little effort into to be seriously considered... Cheers, M. -- 112. Computer Science is embarrassed by the computer. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html From tim_one at email.msn.com Thu Jul 27 22:57:58 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 16:57:58 -0400 Subject: [Python-Dev] more unicode: \U support? In-Reply-To: <39809BC7.FD8E9C35@lemburg.com> Message-ID: [/F] > would it be a good idea to add \UXXXXXXXX > (8 hex digits) to 2.0? > > (only characters in the 0000-ffff range would > be accepted in the current version, of course). [Tim agreed two msgs later; Guido agreed in private] [MAL] > I don't really get the point of adding \uXXXXXXXX No: Fredrik's suggestion is with an uppercase U. He is not proposing to extend the (lowercase) \u1234 notation. > when the internal format used is UTF-16 with support for surrogates. > > What should \u12341234 map to in a future implementation ? > Two Python (UTF-16) Unicode characters ? \U12345678 is C99's ISO 10646 notation; as such, it can't always be mapped to UTF-16. > See > > http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc .html#100850 > > for how Java defines \uXXXX... Which I pushed for from the start, and nobody is seeking to change. > We're following an industry standard here ;-) \U12345678 is also an industry standard, but in a more recent language (than Java) that had more time to consider the eventual implications of Unicode's limitations. We reserve the notation now so that it's possible to outgrow Unicode later. From tim_one at email.msn.com Thu Jul 27 23:01:39 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 17:01:39 -0400 Subject: [Python-Dev] more unicode: \U support? In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD347@RED-MSG-50> Message-ID: [Bill Tutt] > Actually, it'd be \U10FFFF, no need for 8 digits. Nope, \U is taken from the new C standard, and requires exactly 8 hex digits. It's a notation for ISO 10646, not for Unicode. > Java doesn't support surrogates yet, so what Java does for \u doesn't > make any difference. :) \u in Python was meant to mimic Java exactly, if for nothing else then for the sake of JPython. From esr at thyrsus.com Thu Jul 27 23:38:59 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jul 2000 17:38:59 -0400 Subject: [Python-Dev] Request for guidance on documentation Message-ID: <20000727173859.A10337@thyrsus.com> I have now made two passes through the docs for the new curses module, correcting minor errors and adding explanatory material. The question is what to do next, and that turns on whether discursive tutorial sections are are considered fit for inclusion in the library reference. If they are, I'll rewrite the existing curses HOWTO and slide it in there, perhaps adding some stuff from the "Introduction to ncurses" HTML tutorial I wrote lo those many moons ago for the ncurses distribution. Can anybody point me at the TeX source for the curses HOWTO? Also, I'm not sure where the material for curses.textbox should go. New section? Or a subsection in the curses document? -- Eric S. Raymond 'Faith' means not _wanting_ to know what is true. -- Nietzsche, Der Antichrist From trentm at ActiveState.com Fri Jul 28 00:00:56 2000 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 27 Jul 2000 15:00:56 -0700 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: References: <14719.49496.935765.730596@anthem.concentric.net> Message-ID: <20000727150056.B26555@ActiveState.com> On Thu, Jul 27, 2000 at 01:17:03AM -0400, Tim Peters wrote: > In parallel, could someone summarize the symptoms? Exactly how does it > fail? Does it fail the same way across all platforms on which it does fail? > Does it fail every time on all platforms on which it fails, or fail only > some of the time on all platforms on which it fails, or fails some of the > time on some of the platforms on which it fails but fails all of the time on > the rest of the platforms on which it fails ? > > If there exists a platform on which it fails but it doesn't fail every time > on that platform, that would be strong evidence of a timing hole. Those > usually require thought to identify and repair. I'll voluteer to > eyeball the code and do some thinking, but not unless the symptoms suggest > that's worthwhile. > > ignorantly y'rs - tim Here is what I have found: Machine: [trentm at molotok ~/main/contrib/python.build/dist/src]$ cat /proc/version Linux version 2.2.12-20smp (root at porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Mon Sep 27 10:34:45 EDT 1999 Note that this is an SMP machine. General symptoms: test_fork1 did *not* fail for me all the time. In fact it seemed, in this run of testing, to pass fine a number of time in a row and then some magical switch flipped and now it fails every time. I don't know what the 'switch' case is, nor do I know how to flip it on and off. This failing everytime is modulo debugging print statements that I have put in test_fork1.py. This indicates that it is a timing issue. Instumented test_fork1.py: -------------------------------------------------------------------------- import os, sys, time, thread try: os.fork except AttributeError: raise ImportError, "os.fork not defined -- skipping test_fork1" LONGSLEEP = 2 SHORTSLEEP = 0.5 NUM_THREADS = 4 alive = {} stop = 0 def f(id): while not stop: alive[id] = os.getpid() print 'thread %s: pid=%s' % (str(id), str(alive[id])) try: time.sleep(SHORTSLEEP) except IOError: pass def main(): print 'start main' for i in range(NUM_THREADS): thread.start_new(f, (i,)) print 'before sleep' time.sleep(LONGSLEEP) print 'after sleep (threads should be started now)' a = alive.keys() a.sort() assert a == range(NUM_THREADS) prefork_lives = alive.copy() print 'before fork' cpid = os.fork() print 'after fork' if cpid == 0: print 'child: start' # Child time.sleep(LONGSLEEP) n = 0 for key in alive.keys(): if alive[key] != prefork_lives[key]: n = n+1 print 'child: done, exit_value=%d' % n os._exit(n) else: print 'parent: start' # Parent spid, status = os.waitpid(cpid, 0) print 'parent: done waiting for child(pid=%d,status=%d)' %\ (spid, status) assert spid == cpid assert status == 0, "cause = %d, exit = %d" % (status&0xff, status>>8) global stop # Tell threads to die print 'parent: tell threads to die' stop = 1 time.sleep(2*SHORTSLEEP) # Wait for threads to die print 'parent: done (expect threads to be dead by now, hack)' main() -------------------------------------------------------------------------- A couple of test runs: *** This test run passed: [trentm at molotok ~/main/contrib/python.build/dist/src]$ ./python Lib/test/test_fork1.py start main before sleep thread 0: pid=26416 thread 1: pid=26417 thread 2: pid=26418 thread 3: pid=26419 thread 0: pid=26416 thread 1: pid=26417 thread 2: pid=26418 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 thread 3: pid=26419 thread 1: pid=26417 thread 0: pid=26416 after sleep (threads should be started now) before fork after fork thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 parent: start after fork child: start thread 0: pid=26416 thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 child: done, exit_value=0 parent: done waiting for child(pid=26420,status=0) parent: tell threads to die parent: done (expect threads to be dead by now, hack) *** This test run seg faulted but completed: [trentm at molotok ~/main/contrib/python.build/dist/src]$ ./python Lib/test/test_fork1.py start main before sleep thread 0: pid=26546 thread 1: pid=26547 thread 2: pid=26548 thread 3: pid=26549 thread 1: pid=26547 thread 3: pid=26549 thread 2: pid=26548 thread 0: pid=26546 thread 2: pid=26548 thread 0: pid=26546 thread 1: pid=26547 thread 3: pid=26549 thread 3: pid=26549 thread 1: pid=26547 thread 2: pid=26548 thread 0: pid=26546 after sleep (threads should be started now) before fork after fork parent: start after fork child: start Segmentation fault (core dumped) [trentm at molotok ~/main/contrib/python.build/dist/src]$ child: done, exit_value=0 [trentm at molotok ~/main/contrib/python.build/dist/src]$ *** This test hung on the last statement: [trentm at molotok ~/main/contrib/python.build/dist/src]$ ./python Lib/test/test_fork1.py start main before sleep thread 0: pid=26753 thread 1: pid=26754 thread 2: pid=26755 thread 3: pid=26756 thread 2: pid=26755 thread 3: pid=26756 thread 0: pid=26753 thread 1: pid=26754 thread 0: pid=26753 thread 2: pid=26755 thread 3: pid=26756 thread 1: pid=26754 thread 0: pid=26753 thread 3: pid=26756 thread 2: pid=26755 thread 1: pid=26754 after sleep (threads should be started now) before fork thread 0: pid=26753 after fork thread 2: pid=26755 parent: start thread 3: pid=26756 thread 1: pid=26754 after fork child: start thread 0: pid=26753 thread 3: pid=26756 thread 1: pid=26754 thread 2: pid=26755 thread 0: pid=26753 thread 3: pid=26756 thread 1: pid=26754 thread 2: pid=26755 thread 0: pid=26753 thread 3: pid=26756 thread 1: pid=26754 thread 2: pid=26755 thread 0: pid=26753 child: done, exit_value=0 parent: done waiting for child(pid=26757,status=0) Those are the only three run cases that I get. Trent -- Trent Mick TrentM at ActiveState.com From billtut at microsoft.com Fri Jul 28 00:25:01 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 15:25:01 -0700 Subject: [Python-Dev] more unicode: \U support? Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD34A@RED-MSG-50> [Tim stating that we need 8 digits to mimic C99's \U notation due to the ISO 10646 UCS-4 stuff.] Heh, I suppose. ISO has approved the following document for the next rev of 10646 though. "Proposal to restrict the range of code positions to the values up to U-0010FFFF": http://anubis.dkuug.dk/jtc1/sc2/wg2/docs/n2175.htm FYI, Bill From tim_one at email.msn.com Fri Jul 28 00:51:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 18:51:27 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <20000727150056.B26555@ActiveState.com> Message-ID: [Trent Mick, rallies to the cry for a summary of symptoms, which I'll summarize as On Linux version 2.2.12-20smp (root at porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP test_fork1 has one of three outcomes, varying across runs: 1. no problem 2. segfault 3. hang ] Thank you! In no case did the test fail on the particular thing it's *trying* to test: that after a fork, spawned threads don't show up in the child. So it's failing in unanticipated ways (when it does fail), and, to my eyes, ways that are very unlikely to be Python's fault. Everyone pursuing the other "fork bug" please note that test_fork1 doesn't import threading or use any mutexes -- it just spawns threads, forks once, and .sleeps() a lot. As with the other bug, would be interesting to recode test_fork1 in C and see whether it still segfaults and/or hangs. Should be easier to do for this test than the other one, since the *only* thread gimmick test_fork1 uses is thread.start_new(). We'll either discover that it still fails, in which case it's clearly not something Python caused and we'll have something pretty simple to pass on to the platform folks; or that it doesn't, in which case it's *really* interesting . Does anyone have test_fork1 failures on other flavors of SMP? From jeremy at beopen.com Fri Jul 28 01:08:33 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 27 Jul 2000 19:08:33 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: References: <20000727150056.B26555@ActiveState.com> Message-ID: <14720.49393.792630.426570@bitdiddle.concentric.net> >>>>> "TP" == Tim Peters writes: TP> unlikely to be Python's fault. Everyone pursuing the other TP> "fork bug" please note that test_fork1 doesn't import threading TP> or use any mutexes -- it just spawns threads, forks once, and TP> .sleeps() a lot. I don't think the "other" "fork bug" uses any more thread gimmicks than the bug you're considering. The test script that Neil posted did use the threading module, but it works just as well with the thread module. It only uses start_new_thread. The big difference between the two bugs is that the one Neil posted results in deadlock rather than a segfault. So they may well be completely different. For both bugs, though, a mutex and a condition variable are being use: The interpreter lock is being acquired and released in both cases. My current theory is that Python isn't dealing with the interpreter lock correctly across a fork. If some thread other than the one calling fork holds the interpreter lock mutex, the lock will be held forever in the child thread. If the child thread isn't making progress, the parent thread won't make progress either. Jeremy Here's a simplified test case: import os import thread def f(): while 1: if os.fork() == 0: print "%s %s" % (thread.get_ident(), os.getpid()) os._exit(0) os.wait() thread.start_new_thread(f, ()) thread.start_new_thread(f, ()) f() From trentm at ActiveState.com Fri Jul 28 01:17:47 2000 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 27 Jul 2000 16:17:47 -0700 Subject: [Python-Dev] failures in the regression tests In-Reply-To: <14719.42838.895374.783407@bitdiddle.concentric.net> References: <14719.42838.895374.783407@bitdiddle.concentric.net> Message-ID: <20000727161747.A27222@ActiveState.com> On Wed, Jul 26, 2000 at 11:07:02PM -0400, Jeremy Hylton wrote: > I am trying to keep track of failures in the regression test suite. > At the moment, all the available tests work correctly on my Linux > box. I understand there are still problems with test_fork1 on some > SMP Linux boxes. (I believe this error has been around for many > months.) And that the test_winreg and test_winreg32 tests are failing > on Windows builds. > > If you are aware of any other tests that are failing, please let me > know. (Preferably by private email.) We need to get the tests fixed > quickly. As I write in PEP 200 (Python 2.0 release schedule): Configuration: WinNT 4.00.1381 IE 5.500.2314.1003 MSVC 6.0 Dual Xeon processors (500Mhz?) Python CVS as of this morning Failures: test_mmap test_winreg test_winreg2 test_popen2 *** test_mmap: C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\test_mmap.py Position of foo: 1.0 pages Length of file: 2.0 pages Contents of byte 0: '\000' Contents of first 3 bytes: '\000\000\000' Modifying file's content... Contents of byte 0: '3' Contents of first 3 bytes: '3\000\000' Contents of second page: foobar Regex match on mmap (page start, length of match): 1.0 6 Seek to zeroth byte Seek to 42nd byte Seek to last byte Try to seek to negative position... Try to seek beyond end of mmap... Try to seek to negative position... Attempting resize() Traceback (most recent call last): File "..\Lib\test\test_mmap.py", line 114, in ? test_both() File "..\Lib\test\test_mmap.py", line 100, in test_both m.resize( 512 ) WindowsError: [Errno 6] The handle is invalid Fredrik (Win65, MSVC 5.0) tells me he gets the same failure but with a different error code. *** test_popen2 C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\test_popen2.py testing popen2... Traceback (most recent call last): File "..\Lib\test\test_popen2.py", line 22, in ? main() File "..\Lib\test\test_popen2.py", line 20, in main popen2._test() File "C:\trentm\tmp\python\dist\src\lib\popen2.py", line 148, in _test assert r.read() == teststr AssertionError I haven't looked at this one. *** test_winreg C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\regrtest.py test_winreg test_winreg test test_winreg failed -- Unread: '\012' 1 test failed: test_winreg This is just failing because Lib/test/output/test_winreg has one blank line at the end that it should not. I am going to checkin a fix soon (if I can remember how, seeing as I let everyone else checkin all my previous patches :) *** test_winreg2 C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\regrtest.py test_winreg2 test_winreg2 test test_winreg2 failed -- Writing: ' ', expected: '' 1 test failed: test_winreg2 C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\test_winreg2.py Test Passed: testKeyDict_Values Test Passed: testKeyDict_Items Test Passed: testGetValueNames Test Passed: testSetDwordBigEndian Test Passed: testGetSubkeyNames Test Passed: testResourceRequirementsListType Test Passed: testLoad Test Passed: testDeleteKey Test Passed: testValueDict_Length Test Passed: testResourceDescriptionType Test Passed: testSetMultiSz Test Passed: testSetFullResourceDescription HKEY_CLASSES_ROOT HKEY_CURRENT_USER HKEY_LOCAL_MACHINE HKEY_USERS HKEY_CURRENT_CONFIG HKEY_DYN_DATA HKEY_PERFORMANCE_DATA Test Passed: testHives Test Passed: testDWordType Test Passed: testRemote Test Passed: testKeyDict_DelItem Test Failed: testSetIntValue Traceback (most recent call last): File "..\Lib\test\test_winreg2.py", line 297, in ? func() File "..\Lib\test\test_winreg2.py", line 178, in testSetIntValue key.deleteKey( "HKLM\\Software\\a\\b") AttributeError: 'RegKey' instance has no attribute 'deleteKey' Test Passed: testResourceLinkType Test Passed: testNoneType Test Passed: testValueDict_Map Test Passed: testSetResourceList Test Passed: testKeyDict_Length Test Passed: testKeyDict_ClearKeys Test Passed: testDWordBigEndianType Test Passed: testOpen Test Passed: testSetBinaryData Test Passed: testStringType Test Failed: testSetBinaryValue Traceback (most recent call last): File "..\Lib\test\test_winreg2.py", line 297, in ? func() File "..\Lib\test\test_winreg2.py", line 183, in testSetBinaryValue key.setValue( "abcd", array.array( 'c', "PPPPPPPPPPPPPPP") ) NameError: array Test Passed: testSetResourceRequirementsList Test Passed: testValueDict_Items Test Passed: testShortcuts Test Passed: testUnicodeValueName Test Passed: testGetValueDataFromEnum Test Passed: testValueDict_Get Test Passed: testValueDict_GetItem Test Passed: testValueDict_Keys Test Passed: testKeyDict_HasKey Test Passed: testExpandStringType Test Passed: testValueDict_HasKey Test Passed: testCreateKey Test Passed: testGetBinaryData Test Passed: testKeyDict_Get Test Passed: testSave Test Passed: testValueDict_ClearKeys Test Passed: testCmp Test Passed: testLinkType Test Passed: testSetExpandString Test Passed: testKeyDict_GetItem Test Passed: testRepr Test Passed: testClose Test Passed: testSetLink Test Passed: testGetValueDataFromName Test Passed: testUnicodeKeyName Test Passed: testKeyDict_Map Test Passed: testGetValueNameDataAndType Test Passed: testOpenFailure Test Passed: testSetDword Test Passed: testOpenKeyWithFlags Test Passed: testSetNone Test Passed: testKeyDict_Keys Test Passed: testMultiStringType Test Passed: testSetStringValue Test Passed: testValueDict_DelItem Test Passed: testNonZero Test Passed: testFlush Test Passed: testGetSubkeys Test Passed: testDeleteValue Test Passed: testSetString Test Passed: testValueDict_Values This is funny I was getting a more serious crash before. So was Fredrik. Trent -- Trent Mick TrentM at ActiveState.com From nhodgson at bigpond.net.au Fri Jul 28 01:21:01 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Fri, 28 Jul 2000 09:21:01 +1000 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: Message-ID: <013901bff821$55dd02e0$8119fea9@neil> > Getting? I'm very old. I think. But even if I had a memory, I usually > ignore Unix-specific posts (i.e., I can't run code with a .fork(), so can > only sit back & admire the perversity of those who both can & do ). IIRC ActiveState contributed to Perl a version of fork that works on Win32. Has anyone looked at this? Could it be grabbed for Python? This would help heal one of the more difficult platform rifts. Emulating fork for Win32 looks quite difficult to me but if its already done... Neil From trentm at ActiveState.com Fri Jul 28 01:36:01 2000 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 27 Jul 2000 16:36:01 -0700 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) In-Reply-To: <013901bff821$55dd02e0$8119fea9@neil> References: <013901bff821$55dd02e0$8119fea9@neil> Message-ID: <20000727163601.A32039@ActiveState.com> On Fri, Jul 28, 2000 at 09:21:01AM +1000, Neil Hodgson wrote: > IIRC ActiveState contributed to Perl a version of fork that works on > Win32. Has anyone looked at this? Could it be grabbed for Python? This would > help heal one of the more difficult platform rifts. Emulating fork for Win32 > looks quite difficult to me but if its already done... > I just asked Sarathy about this and he direct me to 'perldoc perlfork' (If you have ActivePerl 5.6 installed then you can look it up.) I have attached it here. The emulation of fork() in Win32 is not a perfect solution (e.g. sockets are not dupped, etc.). Trent ------------------- snip --------------------------- NAME perlfork - Perl's fork() emulation SYNOPSIS Perl provides a fork() keyword that corresponds to the Unix system call of the same name. On most Unix-like platforms where the fork() system call is available, Perl's fork() simply calls it. On some platforms such as Windows where the fork() system call is not available, Perl can be built to emulate fork() at the interpreter level. While the emulation is designed to be as compatible as possible with the real fork() at the the level of the Perl program, there are certain important differences that stem from the fact that all the pseudo child "processes" created this way live in the same real process as far as the operating system is concerned. This document provides a general overview of the capabilities and limitations of the fork() emulation. Note that the issues discussed here are not applicable to platforms where a real fork() is available and Perl has been configured to use it. DESCRIPTION The fork() emulation is implemented at the level of the Perl interpreter. What this means in general is that running fork() will actually clone the running interpreter and all its state, and run the cloned interpreter in a separate thread, beginning execution in the new thread just after the point where the fork() was called in the parent. We will refer to the thread that implements this child "process" as the pseudo-process. To the Perl program that called fork(), all this is designed to be transparent. The parent returns from the fork() with a pseudo-process ID that can be subsequently used in any process manipulation functions; the child returns from the fork() with a value of `0' to signify that it is the child pseudo-process. Behavior of other Perl features in forked pseudo-processes Most Perl features behave in a natural way within pseudo-processes. $$ or $PROCESS_ID This special variable is correctly set to the pseudo-process ID. It can be used to identify pseudo-processes within a particular session. Note that this value is subject to recycling if any pseudo-processes are launched after others have been wait()-ed on. %ENV Each pseudo-process maintains its own virtual enviroment. Modifications to %ENV affect the virtual environment, and are only visible within that pseudo-process, and in any processes (or pseudo-processes) launched from it. chdir() and all other builtins that accept filenames Each pseudo-process maintains its own virtual idea of the current directory. Modifications to the current directory using chdir() are only visible within that pseudo-process, and in any processes (or pseudo-processes) launched from it. All file and directory accesses from the pseudo-process will correctly map the virtual working directory to the real working directory appropriately. wait() and waitpid() wait() and waitpid() can be passed a pseudo-process ID returned by fork(). These calls will properly wait for the termination of the pseudo-process and return its status. kill() kill() can be used to terminate a pseudo-process by passing it the ID returned by fork(). This should not be used except under dire circumstances, because the operating system may not guarantee integrity of the process resources when a running thread is terminated. Note that using kill() on a pseudo-process() may typically cause memory leaks, because the thread that implements the pseudo-process does not get a chance to clean up its resources. exec() Calling exec() within a pseudo-process actually spawns the requested executable in a separate process and waits for it to complete before exiting with the same exit status as that process. This means that the process ID reported within the running executable will be different from what the earlier Perl fork() might have returned. Similarly, any process manipulation functions applied to the ID returned by fork() will affect the waiting pseudo-process that called exec(), not the real process it is waiting for after the exec(). exit() exit() always exits just the executing pseudo-process, after automatically wait()-ing for any outstanding child pseudo-processes. Note that this means that the process as a whole will not exit unless all running pseudo-processes have exited. Open handles to files, directories and network sockets All open handles are dup()-ed in pseudo-processes, so that closing any handles in one process does not affect the others. See below for some limitations. Resource limits In the eyes of the operating system, pseudo-processes created via the fork() emulation are simply threads in the same process. This means that any process-level limits imposed by the operating system apply to all pseudo-processes taken together. This includes any limits imposed by the operating system on the number of open file, directory and socket handles, limits on disk space usage, limits on memory size, limits on CPU utilization etc. Killing the parent process If the parent process is killed (either using Perl's kill() builtin, or using some external means) all the pseudo-processes are killed as well, and the whole process exits. Lifetime of the parent process and pseudo-processes During the normal course of events, the parent process and every pseudo-process started by it will wait for their respective pseudo-children to complete before they exit. This means that the parent and every pseudo-child created by it that is also a pseudo-parent will only exit after their pseudo-children have exited. A way to mark a pseudo-processes as running detached from their parent (so that the parent would not have to wait() for them if it doesn't want to) will be provided in future. CAVEATS AND LIMITATIONS BEGIN blocks The fork() emulation will not work entirely correctly when called from within a BEGIN block. The forked copy will run the contents of the BEGIN block, but will not continue parsing the source stream after the BEGIN block. For example, consider the following code: BEGIN { fork and exit; # fork child and exit the parent print "inner\n"; } print "outer\n"; This will print: inner rather than the expected: inner outer This limitation arises from fundamental technical difficulties in cloning and restarting the stacks used by the Perl parser in the middle of a parse. Open filehandles Any filehandles open at the time of the fork() will be dup()-ed. Thus, the files can be closed independently in the parent and child, but beware that the dup()-ed handles will still share the same seek pointer. Changing the seek position in the parent will change it in the child and vice-versa. One can avoid this by opening files that need distinct seek pointers separately in the child. Forking pipe open() not yet implemented The `open(FOO, "|-")' and `open(BAR, "-|")' constructs are not yet implemented. This limitation can be easily worked around in new code by creating a pipe explicitly. The following example shows how to write to a forked child: # simulate open(FOO, "|-") sub pipe_to_fork ($) { my $parent = shift; pipe my $child, $parent or die; my $pid = fork(); die "fork() failed: $!" unless defined $pid; if ($pid) { close $child; } else { close $parent; open(STDIN, "<&=" . fileno($child)) or die; } $pid; } if (pipe_to_fork('FOO')) { # parent print FOO "pipe_to_fork\n"; close FOO; } else { # child while () { print; } close STDIN; exit(0); } And this one reads from the child: # simulate open(FOO, "-|") sub pipe_from_fork ($) { my $parent = shift; pipe $parent, my $child or die; my $pid = fork(); die "fork() failed: $!" unless defined $pid; if ($pid) { close $child; } else { close $parent; open(STDOUT, ">&=" . fileno($child)) or die; } $pid; } if (pipe_from_fork('BAR')) { # parent while () { print; } close BAR; } else { # child print "pipe_from_fork\n"; close STDOUT; exit(0); } Forking pipe open() constructs will be supported in future. Global state maintained by XSUBs External subroutines (XSUBs) that maintain their own global state may not work correctly. Such XSUBs will either need to maintain locks to protect simultaneous access to global data from different pseudo-processes, or maintain all their state on the Perl symbol table, which is copied naturally when fork() is called. A callback mechanism that provides extensions an opportunity to clone their state will be provided in the near future. Interpreter embedded in larger application The fork() emulation may not behave as expected when it is executed in an application which embeds a Perl interpreter and calls Perl APIs that can evaluate bits of Perl code. This stems from the fact that the emulation only has knowledge about the Perl interpreter's own data structures and knows nothing about the containing application's state. For example, any state carried on the application's own call stack is out of reach. Thread-safety of extensions Since the fork() emulation runs code in multiple threads, extensions calling into non-thread-safe libraries may not work reliably when calling fork(). As Perl's threading support gradually becomes more widely adopted even on platforms with a native fork(), such extensions are expected to be fixed for thread-safety. BUGS * Having pseudo-process IDs be negative integers breaks down for the integer `-1' because the wait() and waitpid() functions treat this number as being special. The tacit assumption in the current implementation is that the system never allocates a thread ID of `1' for user threads. A better representation for pseudo-process IDs will be implemented in future. * This document may be incomplete in some respects. AUTHOR Support for concurrent interpreters and the fork() emulation was implemented by ActiveState, with funding from Microsoft Corporation. This document is authored and maintained by Gurusamy Sarathy . SEE ALSO the section on "fork" in the perlfunc manpage, the perlipc manpage -- Trent Mick TrentM at ActiveState.com From mhammond at skippinet.com.au Fri Jul 28 02:11:51 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 28 Jul 2000 10:11:51 +1000 Subject: [Python-Dev] failures in the regression tests In-Reply-To: <20000727161747.A27222@ActiveState.com> Message-ID: > Failures: > test_mmap Im looking at this > test_winreg > test_winreg2 And intend looking at these after. Mark. From billtut at microsoft.com Fri Jul 28 02:15:23 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 17:15:23 -0700 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD34C@RED-MSG-50> [ActivePerl's hack for fork()] Oh gack. I think I'd rather just not go down this road. This is one huge ugly hack. :( Having to maintain separate environments, and separate working directories. *shiver* Bill From tim_one at email.msn.com Fri Jul 28 02:32:00 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 20:32:00 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <14720.49393.792630.426570@bitdiddle.concentric.net> Message-ID: [Jeremy Hylton] > ... > For both bugs, though, a mutex and a condition variable are being use: Oh ya -- now that you mention it, I wrote that code -- but more than 7 years ago! How could a failure have gone undetected for so long? > The interpreter lock is being acquired and released in both cases. > > My current theory is that Python isn't dealing with the interpreter > lock correctly across a fork. If some thread other than the one > calling fork holds the interpreter lock mutex, Let's flesh out the most likely bad case: the main thread gets into posix_fork one of the spawned threads (say, thread 1) tries to acquire the global lock thread 1 gets into PyThread_acquire_lock thread 1 grabs the pthread mutex guarding "the global lock" the main thread executes fork() while thread 1 holds the mutex in the original process, everything's still cool: thread 1 still exists there, and it releases the mutex it acquired (after seeing that the "is it locked?" flag is set), yadda yadda yadda. but in the forked process, things are not cool: the (cloned) mutex guarding the global lock is still held What happens next in the child process is interesting : there is only one thread in the child process, and it's still in posix_fork. There it sets the main_thread and main_pid globals, and returns to the interpreter loop. That the forked pthread_mutex is still locked is irrelevant at this point: the child process won't care about that until enough bytecodes pass that its sole thread offers to yield. It doesn't bash into the already-locked cloned pthread mutex until it executes PyThread_release_lock as part of offering to yield. Then the child hangs. Don't know about this specific implementation, but phtread mutex acquires were usually implemented as busy-loops in my day (which is one reason Python locks were *not* modeled directly as pthread mutexes). So, in this scenario, the child hangs in a busy loop after an accidental amount of time passes after the fork. Matches your symptoms? It doesn't match Trent's segfault, but one nightmare at a time ... From mhammond at skippinet.com.au Fri Jul 28 04:06:10 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 28 Jul 2000 12:06:10 +1000 Subject: [Python-Dev] FW: [Patch #101006] fix mmapmodule test failures Message-ID: Hi all, I just uploaded a patch of mmapmodule to fix the test failures. The patch is not trivial, so I didnt just check it in. However, the patch also isnt _that_ large, so if some Windows people could give it a quick eyeball I would appreciate it. http://sourceforge.net/patch/?func=detailpatch&patch_id=101006&group_id=547 0 [Doh: Just noticed - the clode block that handles the DuplicateHandle() function failing needs to Py_DECREF the new object - Damn! So ignore that particular bug in the patch :-] Thanks, Mark. From greg at cosc.canterbury.ac.nz Fri Jul 28 05:02:29 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Fri, 28 Jul 2000 15:02:29 +1200 (NZST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <20000727150036.Z224@xs4all.nl> Message-ID: <200007280302.PAA09779@s454.cosc.canterbury.ac.nz> > Try to call __getslice__ with unconverted start, stop and step > If it fails with a TypeError, and step is not None, raise the above error > Else, convert start and stop to ints like the current normal slice > behaviour, and try __getslice__ the old way. NO!!! If my __getslice__ method has a bug which results in a type error, I want to get a traceback about it, not have it silently swallowed. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From greg at cosc.canterbury.ac.nz Fri Jul 28 05:10:07 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Fri, 28 Jul 2000 15:10:07 +1200 (NZST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271422.JAA13096@cj20424-a.reston1.va.home.com> Message-ID: <200007280310.PAA09782@s454.cosc.canterbury.ac.nz> Guido van Rossum : > But the two-arg opcode format slows down the opcode decoding -- and > that's the most time-critical part of all of ceval.c! I don't see why that has to be so, as long as you don't try to pre-fetch the extra argument before switching on the opcode. Just leave it up to each branch of the switch to fetch another argument if needed. In fact, why not do that for one-argument opcodes as well? If what you say is true, that should make argument decoding even faster than it is now! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From greg at cosc.canterbury.ac.nz Fri Jul 28 05:52:33 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Fri, 28 Jul 2000 15:52:33 +1200 (NZST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Message-ID: <200007280352.PAA09790@s454.cosc.canterbury.ac.nz> Ka-Ping Yee : > __get__(index, ...) # I want an ITEM. > __getslice__(slice-object, ...) # I want a SLICE. I like this (although it would be safer if the new-style __getslice__ had a new name as well). > This would require detection of whether any of the components > of a multidimensional (i.e. tuple) index were slices Doesn't the parser know this already? By the way, if you're going to make a clear separation between items and slices, then either *none* or *all* of the members of a multidimensional index should be slices, and mixing them should be an error! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From mhammond at skippinet.com.au Fri Jul 28 05:57:44 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 28 Jul 2000 13:57:44 +1000 Subject: [Python-Dev] New winreg module really an improvement? Message-ID: Ive just updated the test suite so that test_winreg2.py actually works. It appears that the new winreg.py module is still in a state of flux, but all work has ceased. The test for this module has lots of placeholders that are not filled in. Worse, the test code was checked in an obviously broken state (presumably "to be done", but guess who the bunny who had to do it was :-( Browsing the source made it clear that the module docstrings are still incomplete (eg "For information on the key API, open a key and look at its docstring."). As far as I can tell, there is no documentation in the library reference for this module (but the underlying _winreg module does have reasonable documentation) This is the first time I have had a serious look at the new winreg module, and the first time I have had to use it. I found it quite unintuitive, and it took me quite some time to update the test suite for what should have been a trivial case: Eg, the specific example I had a problem with was: key[value] Returns a result that includes the key index! This would be similar to a dictionary index _always_ returning the tuple, and the first element of the tuple is _always_ the key you just indexed. Has anyone else actually looked at or played with this, and still believe it is an improvement over _winreg? I personally find it unintuitive, and will personally continue to use _winreg. If we can't find anyone to complete it, document it, and stand up and say they really like it, I suggest we pull it. Still-can't-see-the-added-value-ly, Mark. From fdrake at beopen.com Fri Jul 28 06:49:28 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 28 Jul 2000 00:49:28 -0400 (EDT) Subject: [Python-Dev] New winreg module really an improvement? In-Reply-To: References: Message-ID: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> Mark Hammond writes: > It appears that the new winreg.py module is still in a state of flux, but > all work has ceased. The test for this module has lots of placeholders > that are not filled in. Worse, the test code was checked in an obviously > broken state (presumably "to be done", but guess who the bunny who had to > do it was :-( It was supposed to be Paul Prescod, since it was his module. > This is the first time I have had a serious look at the new winreg module, > and the first time I have had to use it. I found it quite unintuitive, and > it took me quite some time to update the test suite for what should have > been a trivial case: Interesting; I'd understood from Paul that you'd given approval to this module. > Has anyone else actually looked at or played with this, and still believe > it is an improvement over _winreg? I personally find it unintuitive, and > will personally continue to use _winreg. If we can't find anyone to > complete it, document it, and stand up and say they really like it, I > suggest we pull it. Paul, this is very much on your plate to make Mark happy with it, or it goes! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mhammond at skippinet.com.au Fri Jul 28 07:04:53 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 28 Jul 2000 15:04:53 +1000 Subject: [Python-Dev] New winreg module really an improvement? In-Reply-To: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> Message-ID: > Interesting; I'd understood from Paul that you'd given approval to > this module. Actually, it was more more along the lines of me promising to spend some time "over the next few days", and not getting to it. However, I believe it was less than a week before it was just checked in. I also sent a copy of the .NET registry API at that time, suggesting that it may be a better reference API, and one that VB, C# etc programmers will (over time) be familiar with. [Now I can admit it was the .NET API :-] Then the checkin just appeared! The end result was that I was never quite happy, but I felt personally responsible as I didnt find the time to look into this. I felt that I couldn't object, as I had let the team down. I fear this may be a general symptom of the new flurry of activity; no-one with a real job can keep up with this list, meaning valuable feedback on many proposals is getting lost. For example, DigiCool have some obviously smart people, but they are clearly too busy to offer feedback on anything lately. That is a real shame, and a good resource we are missing out on. > Paul, this is very much on your plate to make Mark happy > with it, or it goes! The comments about the documentation etc are easy to fix. I am quite interested to hear from people like Gordon and Bill about their thoughts. I am willing to accept the fact that just because I don't personally like it doesn't mean it sucks ;-) Mark. From bckfnn at worldonline.dk Fri Jul 28 07:15:17 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Fri, 28 Jul 2000 05:15:17 GMT Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <398099F1.B6B1D281@lemburg.com> References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <398065f3.6724599@smtp.worldonline.dk> <398099F1.B6B1D281@lemburg.com> Message-ID: <39811268.1131747@smtp.worldonline.dk> [M.-A. Lemburg] >Finn Bock wrote: >> >> [M.-A. Lemburg] >> >> >BTW, does Java support UCS-4 ? If not, then Java is wrong >> >here ;-) >> >> Java claims to use unicode 2.1 [*]. I couldn't locate anything describing if >> this is UCS-2 or UTF-16. I think unicode 2.1 includes UCS-4. The actual >> level of support for UCS-4 is properly debatable. >> >> - The builtin char is 16bit wide and can obviously not support UCS-4. >> - The Character class can report if a character is a surrogate: >> >>> from java.lang import Character >> >>> Character.getType("\ud800") == Character.SURROGATE >> 1 > >>>> unicodedata.category(u'\ud800') >'Cs' > >... which means the same thing only in Unicode3 standards >notation. > >Make me think: perhaps we should add the Java constants to >unicodedata base. Is there a list of those available >somewhere ? UNASSIGNED = 0 UPPERCASE_LETTER LOWERCASE_LETTER TITLECASE_LETTER MODIFIER_LETTER OTHER_LETTER NON_SPACING_MARK ENCLOSING_MARK COMBINING_SPACING_MARK DECIMAL_DIGIT_NUMBER LETTER_NUMBER OTHER_NUMBER SPACE_SEPARATOR LINE_SEPARATOR PARAGRAPH_SEPARATOR CONTROL FORMAT PRIVATE_USE SURROGATE DASH_PUNCTUATION START_PUNCTUATION END_PUNCTUATION CONNECTOR_PUNCTUATION OTHER_PUNCTUATION MATH_SYMBOL CURRENCY_SYMBOL MODIFIER_SYMBOL OTHER_SYMBOL >> - As reported, direct string comparison ignore surrogates. > >I would guess that this'll have to change as soon as JavaSoft >folks realize that they need to handle UTF-16 and not only >UCS-2. Predicting the future can be difficult, but here is my take: javasoft will never change the way String.compareTo works. String.compareTo is documented as: """ Compares two strings lexicographically. The comparison is based on the Unicode value of each character in the strings. ... """ Instead they will mark it as a very naive string comparison and suggest users to use the Collator classes for anything but the simplest cases. >> - The BreakIterator does not handle surrogates. It does handle >> combining characters and it seems a natural place to put support >> for surrogates. > >What is a BreakIterator ? An iterator to scan line/word breaks ? Yes, as well as character breaks. It already contains the framework for marking two chars next to each other as one. >> - The Collator class offers different levels of normalization before >> comparing string but does not seem to support surrogates. This class >> seems a natural place for javasoft to put support for surrogates >> during string comparison. > >We'll need something like this for 2.1 too: first some >standard APIs for normalization and then a few unicmp() >APIs to use for sorting. > >We might even have to add collation sequences somewhere because >this is a locale issue as well... sometimes it's even worse >with different strategies used for different tasks within one >locale, e.g. in Germany we sometimes sort the Umlaut ? as "ae" >and at other times as extra character. Info: The java Collator class is configured with - a locale and - a strengh parameter IDENTICAL; all difference are significant. PRIMARY (a vs b) SECONDARY (a vs ?) TERTIARY (a vs A) - a decomposition (http://www.unicode.org/unicode/reports/tr15/) NO_DECOMPOSITION CANONICAL_DECOMPOSITION FULL_DECOMPOSITION regards, finn From tim_one at email.msn.com Fri Jul 28 07:24:11 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 28 Jul 2000 01:24:11 -0400 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD345@RED-MSG-50> Message-ID: [Tim] > ... Don't know how long it will take this half of the world to > realize it, but UCS-4 is inevitable. [Bill Tutt] > On new systems perhaps, but important existing systems (Win32, > and probably Java) are stuck with that bad decision and have to > use UTF-16 for backward compatability purposes. Somehow that doesn't strike me as a good reason for Python to mimic them . > Surrogates aren't as far out as you might think. (The next rev of > the Unicode spec) But indeed, that's the *point*: they exhausted their 64K space in just a few years. Now the same experts say that adding 4 bits to the range will suffice for all time; I don't buy it; they picked 4 bits because that's what the surrogate mechanism was defined earlier to support. > That's certainly sooner than Win32 going away. :) I hope it stays around forever -- it's a great object lesson in what optimizing for yesterday's hardware can buy you . From bwarsaw at beopen.com Fri Jul 28 07:50:57 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 28 Jul 2000 01:50:57 -0400 (EDT) Subject: [Python-Dev] PEP 201, zip() builtin References: <14720.35958.632383.574511@anthem.concentric.net> Message-ID: <14721.8001.902979.957977@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> Could we please change "Parallel" to, e.g., "Lockstep" TP> throughout? Greg Wilson correctly pointed out that "parallel" TP> in the context of loops means something very different to the TP> scientific branch of the Python community. Easier to fix this TP> now that after it's spread to the docs. I know, and I guess I never came up with anything better which is why I didn't change it. "Lockstep" it is. TP> Just as you realized how inappropriate "parallel" was right TP> here . Heh. >> # find the length of the shortest sequence shortest = >> min(*map(len, args)) TP> Clearer as >> shortest = min(map(len, args)) A little experimentation leftover. Good catch. TP> However, this implies that all sequences must tell the truth TP> about their lengths, but the iteration protocol actually TP> terminates via a sequence raising IndexError. I believe we TP> want zip to follow the iteration protocol, in effect breaking TP> out of the outer loop as soon as some s[i] raises IndexError. TP> This was agreed to by all (incl. the BDFL) in some other TP> year's debates over this. Yup, I always intended the C implementation to obey the undocumented iteration protocol. But it /is/ better if the PEP's implementation were closer to the eventual C code, so I've swapped in a replacement. >> prefers zip() due to it's Haskell[2] heritage. See version 1.7 TP> "its", not "it's" Good catch. >> - Lazy evaluation. An earlier version of this PEP proposed >> that zip() return a built-in object that performed lazy >> evaluation using __getitem__() protocol. This has been >> strongly rejected by the BDFL in favor of returning a real >> Python list. If lazy evaluation is desired in the future, the >> BDFL suggests an xzip() function be added. TP> Which he'll then fight tooth and nail . :) >> ... TP> Nice job, Barry! Thank you. My pleasure! -Barry From moshez at math.huji.ac.il Fri Jul 28 07:49:30 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 28 Jul 2000 08:49:30 +0300 (IDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271725.MAA17990@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 27 Jul 2000, Guido van Rossum wrote: > Another solution: require a class variable to indicate the class's > awareness: e.g. you must define __getslice_takes_three_args__ when > __getslice__(lo, hi, step) is supported, otherwise the call goes to > __getitem__(slice(lo, hi, step)). I don't think it can work: what about inheritance? Think of these two cases: class A: __getslice_takes_3_args__ def __getslice__(...): ... class B(A): def __getslice__(...): ... # something completely different and class C(A): def __getslice__(self, *args): # do something apply(A.__getslice__, (self,)+args) > This is a bit like the feature flag bits in the type struct. Which are ugly as hell too.....and only work because builtin types have a flat inheritance. oh-well-python-3000-is-just-around-the-corner-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From nowonder at nowonder.de Fri Jul 28 09:57:53 2000 From: nowonder at nowonder.de (Peter Schneider-Kamp) Date: Fri, 28 Jul 2000 07:57:53 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.13,1.14 References: <200007280549.WAA02159@slayer.i.sourceforge.net> Message-ID: <39813D01.C3680553@nowonder.de> Barry Warsaw wrote: > > Update of /cvsroot/python/python/nondist/peps > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2151 > > Modified Files: > pep-0000.txt Hi Barry! I don't know if it is possible to run pep2html.py on your system (I have only used it on Linux), but it would be nice if you could do that after committing changes to the PEPs. Thanks, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From bwarsaw at beopen.com Fri Jul 28 08:43:34 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 28 Jul 2000 02:43:34 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.13,1.14 References: <200007280549.WAA02159@slayer.i.sourceforge.net> <39813D01.C3680553@nowonder.de> Message-ID: <14721.11158.464598.572935@anthem.concentric.net> >>>>> "PS" == Peter Schneider-Kamp writes: PS> I don't know if it is possible to run pep2html.py on your PS> system (I have only used it on Linux), but it would be nice PS> if you could do that after committing changes to the PEPs. Hmm, I get the following exception when running on Python 2.0b1. Too sleepy to track this down right now. -B -------------------- snip snip -------------------- % python pep2html.py pep-0200.txt ... Traceback (most recent call last): File "pep2html.py", line 132, in ? main() File "pep2html.py", line 113, in main fixfile(file, os.path.splitext(file)[0] + ".html") File "pep2html.py", line 100, in fixfile line = fixpat.sub(lambda x, c=infile: fixanchor(c, x), line) TypeError: function requires exactly 3 arguments; 2 given From trentm at activestate.com Fri Jul 28 09:12:49 2000 From: trentm at activestate.com (Trent Mick) Date: Fri, 28 Jul 2000 00:12:49 -0700 Subject: [Python-Dev] failures in the regression tests In-Reply-To: References: <20000727161747.A27222@ActiveState.com> Message-ID: <20000728001249.A3056@ActiveState.com> On Fri, Jul 28, 2000 at 10:11:51AM +1000, Mark Hammond wrote: > And intend looking at these after. > > test_winreg Mark, you saw that I checked in a patch to Lib/test/output/test_winreg to make test_winreg pass, right? I did not check the test for content I just compared the output file with a newly generated (regrtest.py -g) output file. Trent -- Trent Mick TrentM at ActiveState.com From mal at lemburg.com Fri Jul 28 12:16:09 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 12:16:09 +0200 Subject: [Python-Dev] more unicode: \U support? References: Message-ID: <39815D69.1317A927@lemburg.com> Tim Peters wrote: > > [/F] > > would it be a good idea to add \UXXXXXXXX > > (8 hex digits) to 2.0? > > > > (only characters in the 0000-ffff range would > > be accepted in the current version, of course). > > [Tim agreed two msgs later; Guido agreed in private] > > [MAL] > > I don't really get the point of adding \uXXXXXXXX > > No: Fredrik's suggestion is with an uppercase U. He is not proposing to > extend the (lowercase) \u1234 notation. Ah, ok. So there will be no incompatibility with Java et al. > > when the internal format used is UTF-16 with support for surrogates. > > > > What should \u12341234 map to in a future implementation ? > > Two Python (UTF-16) Unicode characters ? > > \U12345678 is C99's ISO 10646 notation; as such, it can't always be mapped > to UTF-16. Sure it can: you'd have to use surrogates. Whether this should happen is another question, but not one which we'll have to deal with now, since as Fredrik proposed, \UXXXXXXXX will only work for 0-FFFF and raise an exception for all higher values. > > See > > > > http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc > .html#100850 > > > > for how Java defines \uXXXX... > > Which I pushed for from the start, and nobody is seeking to change. > > > We're following an industry standard here ;-) > > \U12345678 is also an industry standard, but in a more recent language (than > Java) that had more time to consider the eventual implications of Unicode's > limitations. We reserve the notation now so that it's possible to outgrow > Unicode later. Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Fri Jul 28 12:21:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 12:21:08 +0200 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: <013901bff821$55dd02e0$8119fea9@neil> Message-ID: <39815E94.462F65EF@lemburg.com> Neil Hodgson wrote: > > > Getting? I'm very old. I think. But even if I had a memory, I usually > > ignore Unix-specific posts (i.e., I can't run code with a .fork(), so can > > only sit back & admire the perversity of those who both can & do ). > > IIRC ActiveState contributed to Perl a version of fork that works on > Win32. Has anyone looked at this? Could it be grabbed for Python? This would > help heal one of the more difficult platform rifts. Emulating fork for Win32 > looks quite difficult to me but if its already done... This would indeed be a *very* useful addition and help porting os.fork() applications to Win32. (Ok, in the long run they would have to be converted to multi-threaded apps due to the process creation overhead on Win32, but for short term porting to Win32 this would be a Cool Thing, IMHO.) Can this code be grabbed from somewhere ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Fri Jul 28 13:42:12 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 06:42:12 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Fri, 28 Jul 2000 15:10:07 +1200." <200007280310.PAA09782@s454.cosc.canterbury.ac.nz> References: <200007280310.PAA09782@s454.cosc.canterbury.ac.nz> Message-ID: <200007281142.GAA03952@cj20424-a.reston1.va.home.com> > Guido van Rossum : > > > But the two-arg opcode format slows down the opcode decoding -- and > > that's the most time-critical part of all of ceval.c! > > I don't see why that has to be so, as long as you don't try > to pre-fetch the extra argument before switching on the > opcode. Just leave it up to each branch of the switch to > fetch another argument if needed. Sure. That's not how the patch is currently implemented though -- it adds this to the main opcode decoding: if (HAS_2ARG(opcode)) oparg2 = NEXTARG(); > In fact, why not do that for one-argument opcodes as well? > If what you say is true, that should make argument decoding > even faster than it is now! Yes -- but also would cause about 30-40 copies of the same code (which could be a single macro call). This could easily be tested and timed though. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Fri Jul 28 13:47:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 06:47:29 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Fri, 28 Jul 2000 15:52:33 +1200." <200007280352.PAA09790@s454.cosc.canterbury.ac.nz> References: <200007280352.PAA09790@s454.cosc.canterbury.ac.nz> Message-ID: <200007281147.GAA04007@cj20424-a.reston1.va.home.com> > Ka-Ping Yee : > > > __get__(index, ...) # I want an ITEM. > > __getslice__(slice-object, ...) # I want a SLICE. > > I like this (although it would be safer if the new-style > __getslice__ had a new name as well). > > > This would require detection of whether any of the components > > of a multidimensional (i.e. tuple) index were slices > > Doesn't the parser know this already? Yes. > By the way, if you're going to make a clear separation between items > and slices, then either *none* or *all* of the members of a > multidimensional index should be slices, and mixing them should > be an error! Huh? The way I understand this, mixing indices and slices is used all the time to reduce the dimensionality of an array. E.g. if A is a 2-dimensional array, A[0] is a 1-dim vector, and so are A[0, 1:-1] and A[:-1, 1]. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From thomas at xs4all.net Fri Jul 28 12:49:34 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 12:49:34 +0200 Subject: [Python-Dev] Developer activity (Was: New winreg module really an improvement?) In-Reply-To: ; from mhammond@skippinet.com.au on Fri, Jul 28, 2000 at 03:04:53PM +1000 References: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> Message-ID: <20000728124933.A266@xs4all.nl> On Fri, Jul 28, 2000 at 03:04:53PM +1000, Mark Hammond wrote: [ Something about something changing very fast, not giving Mark the chance to react to it ] > I fear this may be a general symptom of the new flurry of activity; no-one > with a real job can keep up with this list, meaning valuable feedback on > many proposals is getting lost. For example, DigiCool have some obviously > smart people, but they are clearly too busy to offer feedback on anything > lately. That is a real shame, and a good resource we are missing out on. Well, the same goes for Guido. Much though I liked the discussion about slices (and about augmented assignment) yesterday, it took me completely by suprise. And I'm not sure what the end result is, either. I don't even know whether it's finished or not, and it's not that easy to find out: it could be restin', pinin' for the fjords, or it could be nailed to its perch, it could be an ex-thread. And if it has ceased to be, well, it didn't amount to much, I think. Some opinions, and a simple (but effective, as far as I can tell) patch from Michael on one of the sub-issues. And I believe that's where PEPs are supposed to come in. They summarise the discussions, so that cool and smart people can look through it, see the proposal, see the pros and cons, and add their own. I'm not sure if it'll *work* like that, given that PEPs take some effort to create, and the format is still not too clear (at least, not to me.) And then there is the stuff that keeps popping up and isn't really PEPable: segfaults, tests failing, problem areas not covered by tests, unexpected behaviour noone has come around to fix or can figure out how to fix, etc. Maybe we need a TODO list, to store these issues ? Noone else is keeping track, I think, unless it's done in the Jitterbug buglist -- and I can't really work with jitterbug, myself. Items on the TODO list that stay on too long and start repetetive discussions are clearly candidates for PEPs, but others are just longstanding bugs that need to be properly investigated and fixed (probably elaborately) and noone disagrees with that. And if the 'fix' is non-obvious and involved, and generates too much discussion, it can always be PEPulated ;-) And if the TODO list needs a maintainer, someone that keeps track of all 'issues' that need closer examination, I'd be happy to volunteer. My idea would be to limit it to python-dev, unless someone forwards c.l.py traffic or other traffic that points out TODO-listable issues. (Or maybe SF has a good tool for this ? Not being a project admin, I've never seen the 'project manager', so I'm not sure if it has anything like a 'wishlist' ?) PS: Mark, I *do* have a real job, honest ;) I just get to be near my mail for about 14 hours a day. (I waste 4 hours to work/home travel, 6 hours to sleep/eating.) You should try working for an ISP, too! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Fri Jul 28 14:06:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:06:05 -0500 Subject: [Python-Dev] New winreg module really an improvement? In-Reply-To: Your message of "Fri, 28 Jul 2000 15:04:53 +1000." References: Message-ID: <200007281206.HAA04102@cj20424-a.reston1.va.home.com> I vaguely remember that I wasn't happy with the way this was handled either, but was too busy at the time to look into it. (I can't say whether I'm happy with the module or not, since I've never tried to use it. But I do feel unhappy about the process.) Note that Paul recently updated most of the docstrings, so he can't be blamed alone, and I'm sure fixes to the docstrings are welcome. Mark, could you spend some time explaining what you think should be changed in the module? I think it's not too late to change it -- after all there aren't any real users of the module out. (I note that Greg Ward chose the same route as you -- he uses _winreg, not winreg.) I vaguely remember that Paul Prescod's main gripe with the _winreg API was that it's not object-oriented enough -- but that seems his main gripe about most code these days. :-) Paul, how much experience with using the Windows registry did you have when you designed the new API? --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Fri Jul 28 14:26:07 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:26:07 -0500 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: Your message of "Fri, 28 Jul 2000 05:15:17 GMT." <39811268.1131747@smtp.worldonline.dk> References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <398065f3.6724599@smtp.worldonline.dk> <398099F1.B6B1D281@lemburg.com> <39811268.1131747@smtp.worldonline.dk> Message-ID: <200007281226.HAA04140@cj20424-a.reston1.va.home.com> > Predicting the future can be difficult, but here is my take: > javasoft will never change the way String.compareTo works. > String.compareTo is documented as: > """ > Compares two strings lexicographically. The comparison is based on > the Unicode value of each character in the strings. ... > """ (Noting that their definition of "character" is probably "a 16-bit value of type char", and has only fleeting resemblance to what is or is not defined as a character by the Unicode standard.) > Instead they will mark it as a very naive string comparison and suggest > users to use the Collator classes for anything but the simplest cases. Without having digested the entire discussion, this sounds like a good solution for Python too. The "==" operator should compare strings based on a simple-minded representation-oriented definition, and all the other stuff gets pushed into separate methods or classes. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Vladimir.Marangozov at inrialpes.fr Fri Jul 28 13:34:07 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 13:34:07 +0200 (CEST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007281142.GAA03952@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 28, 2000 06:42:12 AM Message-ID: <200007281134.NAA05764@python.inrialpes.fr> Guido van Rossum wrote: > > > In fact, why not do that for one-argument opcodes as well? > > If what you say is true, that should make argument decoding > > even faster than it is now! > > Yes -- but also would cause about 30-40 copies of the same code (which > could be a single macro call). This could easily be tested and timed > though. > Yes, and we won't be able to conclude anything. This is micro-optimization which doesn't give meaningful results. Actually, when I played last time with the main loop (it was for 1.5.2 I believe) duplicating the second argfetch doesn't give any speedup. Mainly because the code for the 2nd byte fetch is already in the processor's cache. Consequently, testing and fetching the 2nd argbyte (or skipping it) is faster when it's done before the big switch. If it's done per opcode, the cache may be invalidated. Micro-optimization doesn't worth the effort. As to the 2-byte arg limit, I think I'd be happy if the compiler raises an exception if this limit is exceeded. unrelated-with-PEP-203'ly y's -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at beopen.com Fri Jul 28 14:38:34 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:38:34 -0500 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) In-Reply-To: Your message of "Fri, 28 Jul 2000 12:21:08 +0200." <39815E94.462F65EF@lemburg.com> References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> Message-ID: <200007281238.HAA04294@cj20424-a.reston1.va.home.com> > > IIRC ActiveState contributed to Perl a version of fork that works > > on Win32. Has anyone looked at this? Could it be grabbed for > > Python? This would help heal one of the more difficult platform > > rifts. Emulating fork for Win32 looks quite difficult to me but if > > its already done... > This would indeed be a *very* useful addition and help porting > os.fork() applications to Win32. (Ok, in the long run they would > have to be converted to multi-threaded apps due to the process > creation overhead on Win32, but for short term porting to Win32 > this would be a Cool Thing, IMHO.) I have only one word: yuck! Portable Python code should not rely on fork. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Fri Jul 28 14:41:41 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:41:41 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Fri, 28 Jul 2000 13:34:07 +0200." <200007281134.NAA05764@python.inrialpes.fr> References: <200007281134.NAA05764@python.inrialpes.fr> Message-ID: <200007281241.HAA04335@cj20424-a.reston1.va.home.com> > > Yes -- but also would cause about 30-40 copies of the same code (which > > could be a single macro call). This could easily be tested and timed > > though. > > Yes, and we won't be able to conclude anything. This is micro-optimization > which doesn't give meaningful results. Actually, when I played last time > with the main loop (it was for 1.5.2 I believe) duplicating the second > argfetch doesn't give any speedup. Mainly because the code for > the 2nd byte fetch is already in the processor's cache. Consequently, > testing and fetching the 2nd argbyte (or skipping it) is faster when > it's done before the big switch. If it's done per opcode, the cache may > be invalidated. Fair enough (for one particular CPU at least). > Micro-optimization doesn't worth the effort. As to the 2-byte arg limit, > I think I'd be happy if the compiler raises an exception if this limit > is exceeded. That would be a good first step indeed! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Fri Jul 28 14:53:54 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:53:54 -0500 Subject: [Python-Dev] Developer activity (Was: New winreg module really an improvement?) In-Reply-To: Your message of "Fri, 28 Jul 2000 12:49:34 +0200." <20000728124933.A266@xs4all.nl> References: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> <20000728124933.A266@xs4all.nl> Message-ID: <200007281253.HAA04381@cj20424-a.reston1.va.home.com> [Mark H] > > I fear this may be a general symptom of the new flurry of activity; no-one > > with a real job can keep up with this list, meaning valuable feedback on > > many proposals is getting lost. For example, DigiCool have some obviously > > smart people, but they are clearly too busy to offer feedback on anything > > lately. That is a real shame, and a good resource we are missing out on. [Thomas W] > Well, the same goes for Guido. Not sure what you mean. I'm too busy to offer feedback on anything? Give me a break! I probably spend 4 hours reading and responding to python-dev each day. > Much though I liked the discussion about > slices (and about augmented assignment) yesterday, it took me completely by > suprise. And I'm not sure what the end result is, either. I don't even know > whether it's finished or not, and it's not that easy to find out: it could > be restin', pinin' for the fjords, or it could be nailed to its perch, it > could be an ex-thread. And if it has ceased to be, well, it didn't amount to > much, I think. Some opinions, and a simple (but effective, as far as I can > tell) patch from Michael on one of the sub-issues. It's still open. I was trying to respond to your own post where you considered a redesign of the augmented assignment bytecode. I still think the proposed redesign is a good one (always use LOAD a, LOAD b, AUGASS, STORE b; or LOADSLICE, LOAD b, AUGASS, STORESLICE etc.) > And I believe that's where PEPs are supposed to come in. They summarise the > discussions, so that cool and smart people can look through it, see the > proposal, see the pros and cons, and add their own. I'm not sure if it'll > *work* like that, given that PEPs take some effort to create, and the format > is still not too clear (at least, not to me.) Don't worry too much about the format! Just write in a style that you think works for you. We're specifying the format to ensure that PEPs contain all the necessary information and are easily readable; I hope the rules aren't seen as stifling for PEP authors! > And then there is the stuff > that keeps popping up and isn't really PEPable: segfaults, tests failing, > problem areas not covered by tests, unexpected behaviour noone has come > around to fix or can figure out how to fix, etc. > > Maybe we need a TODO list, to store these issues ? Noone else is keeping > track, I think, unless it's done in the Jitterbug buglist -- and I can't > really work with jitterbug, myself. Items on the TODO list that stay on too > long and start repetetive discussions are clearly candidates for PEPs, but > others are just longstanding bugs that need to be properly investigated and > fixed (probably elaborately) and noone disagrees with that. And if the 'fix' > is non-obvious and involved, and generates too much discussion, it can > always be PEPulated ;-) > > And if the TODO list needs a maintainer, someone that keeps track of all > 'issues' that need closer examination, I'd be happy to volunteer. My idea > would be to limit it to python-dev, unless someone forwards c.l.py traffic > or other traffic that points out TODO-listable issues. Actually, Jeremy is the officially appointed 2.0 release manager, and as far as I can tell he's doing a good job of keeping track of open issues. He's also working on transferring the JitterBug database to the SF Bug Tracker, so we can shut off Jitterbug. > (Or maybe SF has a good tool for this ? Not being a project admin, I've > never seen the 'project manager', so I'm not sure if it has anything like a > 'wishlist' ?) The SF Bug Trackerwould work, I think. > PS: Mark, I *do* have a real job, honest ;) I just get to be near my mail > for about 14 hours a day. (I waste 4 hours to work/home travel, 6 hours to > sleep/eating.) You should try working for an ISP, too! 4 hours travel time? That gets you across the country! This job must be real important for you...! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From skip at mojam.com Fri Jul 28 14:17:46 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 28 Jul 2000 07:17:46 -0500 (CDT) Subject: [Python-Dev] urllib - {quote,unquote} vs. {quote_plus,unquote_plus} Message-ID: <14721.31210.734864.412520@beluga.mojam.com> I realize there is a symmetry between the functionality of urllib.{quote,unquote} and urllib.{quote_plus,unquote_plus}, but why doesn't unquote function like unquote_plus and map "+" to " "? Skip From thomas at xs4all.net Fri Jul 28 14:24:29 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 14:24:29 +0200 Subject: [Python-Dev] Developer activity (Was: New winreg module really an improvement?) In-Reply-To: <200007281253.HAA04381@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 28, 2000 at 07:53:54AM -0500 References: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> <20000728124933.A266@xs4all.nl> <200007281253.HAA04381@cj20424-a.reston1.va.home.com> Message-ID: <20000728142429.B266@xs4all.nl> On Fri, Jul 28, 2000 at 07:53:54AM -0500, Guido van Rossum wrote: > > Well, the same goes for Guido. > Not sure what you mean. I'm too busy to offer feedback on anything? > Give me a break! I probably spend 4 hours reading and responding to > python-dev each day. Unless I misinterpreted you, *you yourself* said this, Guido. (I can look this up if you wish.) PEPs are there so you (and others, like me) don't have to follow the details of each discussion. I didn't mean to imply you (or anyone else) don't consider python-dev important enough to follow, absolutely not. I just meant that we can't expect you (or anyone) to give feedback on *everything*, given the pace of messages yesterday (or any of the other bursts of activity.) Reading all messages is something else than understanding the issues, considering them and proposing new solutions or new ways of viewing them. > > Much though I liked the discussion about slices (and about augmented > > assignment) yesterday, it took me completely by suprise. And I'm not > > sure what the end result is, either. > I still think the proposed redesign is a good one (always use LOAD a, LOAD > b, AUGASS, STORE b; or LOADSLICE, LOAD b, AUGASS, STORESLICE etc.) So do I. I think thread-safety should be solved differently, even though I think it should be solved, somehow. ThreadSafeDict, with explicit grab/release lock ? :P But that was the other sub-thread. In this particular case, I was referring to the slicing thing, but I'm probably too impatient and urging on these issues. (Actually, I know I am. I'm just a tad worried things like this will go on and on and get lost and etc, etc, etc.) I'll be implementing the seperate AUGMENTED_ADD/SUBTRACT/etc ops this weekend, I think, and removing the 2-argument opcodes etc. > > And if the TODO list needs a maintainer, someone that keeps track of all > > 'issues' that need closer examination, I'd be happy to volunteer. My idea > > would be to limit it to python-dev, unless someone forwards c.l.py traffic > > or other traffic that points out TODO-listable issues. > Actually, Jeremy is the officially appointed 2.0 release manager, and > as far as I can tell he's doing a good job of keeping track of open > issues. He's also working on transferring the JitterBug database to > the SF Bug Tracker, so we can shut off Jitterbug. Ah, yes, hadn't considered the 2.0 release manager, probably because I hadn't figured it as a job for him -- some of these issues go beyond 2.0. Never-saw-a-release-manager-before-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From akuchlin at cnri.reston.va.us Fri Jul 28 14:29:19 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 28 Jul 2000 08:29:19 -0400 Subject: [Python-Dev] Re: [Patch #100740] gzip: readline(), readlines() patch In-Reply-To: <200007281025.DAA28944@delerium.i.sourceforge.net>; from noreply@sourceforge.net on Fri, Jul 28, 2000 at 03:25:36AM -0700 References: <200007281025.DAA28944@delerium.i.sourceforge.net> Message-ID: <20000728082919.A10938@newcnri.cnri.reston.va.us> On Fri, Jul 28, 2000 at 03:25:36AM -0700, noreply at sourceforge.net wrote: >Patch #100740 has been updated. >gvanrossum wrote: >Almost right. The docs for file objects specifically imply that a >negative arg to readline() or a zero arg to readlines() is the same as >no args; your defaults are sys.maxint so an explicit -1 or 0 won't do >the right thing. (This is important for wrapper classes that want to Which docs say this? I looked at Doc/lib/libstdtypes.tex to get the semantics: \begin{methoddesc}[file]{readline}{\optional{size}} ... If the \var{size} argument is present and non-negative, it is a maximum byte count (including the trailing newline) and an incomplete line may be returned. ... \end{methoddesc} \begin{methoddesc}[file]{readlines}{\optional{sizehint}} ... If the optional \var{sizehint} argument is present, instead of reading up to \EOF{}, whole lines totalling approximately \var{sizehint} bytes (possibly after rounding up to an internal buffer size) are read. \end{methoddesc} Neither text mentions the special cases for -1 and 0 in each function. Fixing the patch to get this right is trivial, but I think the docs need to be updated to mention this. --amk From akuchlin at cnri.reston.va.us Fri Jul 28 14:34:19 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 28 Jul 2000 08:34:19 -0400 Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <20000727173859.A10337@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 27, 2000 at 05:38:59PM -0400 References: <20000727173859.A10337@thyrsus.com> Message-ID: <20000728083419.B10938@newcnri.cnri.reston.va.us> On Thu, Jul 27, 2000 at 05:38:59PM -0400, Eric S. Raymond wrote: >correcting minor errors and adding explanatory material. The question >is what to do next, and that turns on whether discursive tutorial sections >are are considered fit for inclusion in the library reference. That's up to Fred to decide. I suspect the answer is no, since it would make the library reference too large and ungainly if every section had a tutorial. Regular expressions, socket programming, and XML processing are all sizable topics in their own right that would be covered. I will re-raise the idea of adding the HOWTOs to the documentation subtree, though; Fred & I have discussed it before, and decided not to for reasons that I can't remember. >Can anybody point me at the TeX source for the curses HOWTO? I'l mail it to you privately. >Also, I'm not sure where the material for curses.textbox should go. New >section? Or a subsection in the curses document? Probably a subsection, but again, Fred has final ruling on that. --amk From fdrake at beopen.com Fri Jul 28 15:24:41 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 28 Jul 2000 09:24:41 -0400 (EDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <20000728083419.B10938@newcnri.cnri.reston.va.us> References: <20000727173859.A10337@thyrsus.com> <20000728083419.B10938@newcnri.cnri.reston.va.us> Message-ID: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> On Thu, Jul 27, 2000 at 05:38:59PM -0400, Eric S. Raymond wrote: > correcting minor errors and adding explanatory material. The question > is what to do next, and that turns on whether discursive tutorial sections > are are considered fit for inclusion in the library reference. Andrew Kuchling writes: > That's up to Fred to decide. I suspect the answer is no, since it > would make the library reference too large and ungainly if every Hey, it's large & unweildy now. ;-) But I think you're right. Improving the curses HOWTO separately from the reference documentation makes sense. > I will re-raise the idea of adding the HOWTOs to the documentation > subtree, though; Fred & I have discussed it before, and decided not to > for reasons that I can't remember. I don't recall exactly, but I think it had a bit to do with the release scheduling (perhaps this was when the documentation was release lockstep with CPython?) and editorial control -- as long as you're willing to act as HOWTO editor, you should be able to release regardless of whether there's anything new to release in the standard library. Eric again: > Also, I'm not sure where the material for curses.textbox should go. New > section? Or a subsection in the curses document? curses.textbox should be documented in a \section like any other module. It can be placed in libcurses.tex along with the other curses-related modules. Is curses.wrapper documented, or is it an implementation detail? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Fri Jul 28 16:33:32 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 09:33:32 -0500 Subject: [Python-Dev] Re: [Patch #100740] gzip: readline(), readlines() patch In-Reply-To: Your message of "Fri, 28 Jul 2000 08:29:19 -0400." <20000728082919.A10938@newcnri.cnri.reston.va.us> References: <200007281025.DAA28944@delerium.i.sourceforge.net> <20000728082919.A10938@newcnri.cnri.reston.va.us> Message-ID: <200007281433.JAA04585@cj20424-a.reston1.va.home.com> > >Almost right. The docs for file objects specifically imply that a > >negative arg to readline() or a zero arg to readlines() is the same as > >no args; your defaults are sys.maxint so an explicit -1 or 0 won't do > >the right thing. (This is important for wrapper classes that want to > > Which docs say this? I looked at Doc/lib/libstdtypes.tex to get the > semantics: > > \begin{methoddesc}[file]{readline}{\optional{size}} > ... If the \var{size} argument is present and > non-negative, it is a maximum byte count (including the trailing > newline) and an incomplete line may be returned. ... > \end{methoddesc} I read this that any negative argument has the same effect as an absent argument. I suggested -1 as a typical negative number. The doc could be more explicit though. > \begin{methoddesc}[file]{readlines}{\optional{sizehint}} > ... If the optional \var{sizehint} argument is > present, instead of reading up to \EOF{}, whole lines totalling > approximately \var{sizehint} bytes (possibly after rounding up to an > internal buffer size) are read. > \end{methoddesc} Here you're right -- I got the 0 from the code. It should be documented. > Neither text mentions the special cases for -1 and 0 in each function. > Fixing the patch to get this right is trivial, but I think the docs > need to be updated to mention this. Agreed. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From pf at artcom-gmbh.de Fri Jul 28 15:37:56 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Fri, 28 Jul 2000 15:37:56 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: <14720.16857.900370.320050@bitdiddle.concentric.net> from Jeremy Hylton at "Jul 27, 2000 10: 6:17 am" Message-ID: Hi, Jeremy Hylton wrote: [...] > Feel free to think of it as a guide, but don't think of it as a > specification! (It is, as you mention, fairly old.) The only ------------------------------------------^^^^^^^^^^^ This was my argument to harden Moshes point, that *MUCH* code written until today relies on this advertised behaviour! > official word on reclaiming externel resource is the Python Language > Reference -- http://www.python.org/doc/current/ref/. > > >Some objects contain references to "external" resources such as open > >files or windows. It is understood that these resources are freed when > >the object is garbage-collected, but since garbage collection is not > >guaranteed to happen, such objects also provide an explicit way to > >release the external resource, usually a close() method. Programs are > >strongly recommended to explicitly close such objects. The > >`try...finally' statement provides a convenient way to do this. > > If this isn't clear enough, we could revise it for the next release of > the documentation. As Guido said, the code is broken, not JPython. Thank you: This paragraph is indeed clear enough. :-( And I must admit, that the above cited paragraph is at least as old as Mark Lutz book (I've just restored Python1.2/Doc to check this out, since I couldn't believe that in the first place: damned time machine!) I must have overlooked this particular paragraph in the past and so may many other users of Python (At least Mark Lutz ;-) ?) However I disagree with this paragraph. IMO one of the major strenghts of Python (in its reference implementation C-Python) has today compared to other languages (Java) is this particular behaviour. The argument made in the last sentence of the paragraph cited from the reference manual is bogus: In order to be able to call a close() method you have to keep an explicit reference to the object in question. This usually requires many lines of source code where previously only one line was needed: func(constructor("foo").method()) has to be recoded as try: ref = constructor("foo") func(ref.method()) finally: ref.close() if constructor happens to keep external resources. This is a factor of five (in LOC) of code bloat and is absolutely unacceptable. And in GUI programs you usually have *many* objects, that keep external resources like windows, files and the like. If this kind of coding is required to make existing Python apps running reliable under 'JPython', then this will render 'JPython' (and any other Python implementation without proper reliable reclaiming) pretty useless for me. (and may be to other members of the Python community) For me all those nifty new features currently discussed here (augmented ass., list comprehensions...) are not all *that* useful, compared to this important convience of the current C-Python implementation. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From moshez at math.huji.ac.il Fri Jul 28 15:45:20 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 28 Jul 2000 16:45:20 +0300 (IDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> Message-ID: On Fri, 28 Jul 2000, Fred L. Drake, Jr. wrote: > I don't recall exactly, but I think it had a bit to do with the > release scheduling (perhaps this was when the documentation was > release lockstep with CPython?) and editorial control -- as long as > you're willing to act as HOWTO editor, you should be able to release > regardless of whether there's anything new to release in the standard > library. Neither of those reasons are enough not to put the HOWTOs in the CVS tree. Editors can keep the version in the CVS current via the patch manager, and release them as they need to. However, people who d/l Python will automatically download the HOWTOs. Think of perldoc lol (lists of lists) -- definitely "HOWTO" material, but in the Perl standard docs. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at beopen.com Fri Jul 28 16:54:07 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 09:54:07 -0500 Subject: [Python-Dev] Developer activity (Was: New winreg module really an improvement?) In-Reply-To: Your message of "Fri, 28 Jul 2000 14:24:29 +0200." <20000728142429.B266@xs4all.nl> References: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> <20000728124933.A266@xs4all.nl> <200007281253.HAA04381@cj20424-a.reston1.va.home.com> <20000728142429.B266@xs4all.nl> Message-ID: <200007281454.JAA04789@cj20424-a.reston1.va.home.com> > > > Well, the same goes for Guido. > > > Not sure what you mean. I'm too busy to offer feedback on anything? > > Give me a break! I probably spend 4 hours reading and responding to > > python-dev each day. > > Unless I misinterpreted you, *you yourself* said this, Guido. (I can look > this up if you wish.) PEPs are there so you (and others, like me) don't > have to follow the details of each discussion. I didn't mean to imply you > (or anyone else) don't consider python-dev important enough to follow, > absolutely not. I just meant that we can't expect you (or anyone) to give > feedback on *everything*, given the pace of messages yesterday (or any of > the other bursts of activity.) You were commenting on Digital Creation's total absence. I am busy, but I am still very much involved in everything that goes on here, hence my reaction of "no fair!" That said, *nobody* can deal with 500 messages in one weekend, so the creations of PEPs should be received enthusiastically by all. > Reading all messages is something else than understanding the issues, > considering them and proposing new solutions or new ways of viewing them. And believe me, whereever I can, I do! > So do I. I think thread-safety should be solved differently, even though I > think it should be solved, somehow. ThreadSafeDict, with explicit > grab/release lock ? :P Library issue. > But that was the other sub-thread. In this particular case, I was referring > to the slicing thing, but I'm probably too impatient and urging on these > issues. (Actually, I know I am. I'm just a tad worried things like this will > go on and on and get lost and etc, etc, etc.) The slicing reorg is all pie-in-the-sky. Good for a post-2.0 PEP. > I'll be implementing the seperate AUGMENTED_ADD/SUBTRACT/etc ops this > weekend, I think, and removing the 2-argument opcodes etc. Good! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Vladimir.Marangozov at inrialpes.fr Fri Jul 28 16:04:03 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 16:04:03 +0200 (CEST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007281241.HAA04335@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 28, 2000 07:41:41 AM Message-ID: <200007281404.QAA06091@python.inrialpes.fr> Guido van Rossum wrote: > > > [me, on micro-optimizing the main loop] > > Fair enough (for one particular CPU at least). Since we're at it, it's worth mentioning another conclusion we came across at the time: the cache effects in the main loop are significant -- it is more important to try keeping at best the main loop small enough, so that those effects are minimized. An experiment I did at the time which gave some delta-speedup: I folded most of the UNOP & BINOP opcodes since they differ only by the functon they call and they duplicate most of the opcode body. Like this: Original: case BINARY_POWER: w = POP(); v = POP(); x = PyNumber_Power(v, w, Py_None); Py_DECREF(v); Py_DECREF(w); PUSH(x); if (x != NULL) continue; break; case BINARY_MULTIPLY: w = POP(); v = POP(); x = PyNumber_Multiply(v, w); Py_DECREF(v); Py_DECREF(w); PUSH(x); if (x != NULL) continue; break; ... Folded version: case BINARY_POWER: w = POP(); v = POP(); x = PyNumber_Power(v, w, Py_None); goto end_binop; case BINARY_MULTIPLY: w = POP(); v = POP(); x = PyNumber_Multiply(v, w); goto end_binop; ... end_binop: Py_DECREF(v); Py_DECREF(w); PUSH(x); if (x != NULL) continue; break; This reduced the code size of ceval.c, which resulted in less cache effects and gave more speed, despite the additional jumps. It possibly results in less page-faults too, although this is unlikely. Which makes me think that, if we want to do something about cache effects, it is probably not a bad idea to just "reorder" the bytecodes in the big switch by decreasing frequency (we have some stats about this -- I believe Skip and MAL have discussed the opcodes' frequency and the charts lie somewhere in the archives). I remember Marc-Andre had done something in this direction and reported some perf improvements too. Since reordering the opcodes doesn't really hurt, if I'm about to do something with the main loop, it'll be only this. > > > Micro-optimization doesn't worth the effort. As to the 2-byte arg limit, > > I think I'd be happy if the compiler raises an exception if this limit > > is exceeded. > > That would be a good first step indeed! I'll try to have a look, if someone else is not more reactive than me. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at beopen.com Fri Jul 28 17:05:48 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 10:05:48 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Fri, 28 Jul 2000 16:04:03 +0200." <200007281404.QAA06091@python.inrialpes.fr> References: <200007281404.QAA06091@python.inrialpes.fr> Message-ID: <200007281505.KAA04865@cj20424-a.reston1.va.home.com> > Since we're at it, it's worth mentioning another conclusion we came across > at the time: the cache effects in the main loop are significant -- it is > more important to try keeping at best the main loop small enough, so that > those effects are minimized. Yes, that's what Tim keeps hammering on too. > An experiment I did at the time which gave some delta-speedup: > I folded most of the UNOP & BINOP opcodes since they differ only by the > functon they call and they duplicate most of the opcode body. Like this: [...] > This reduced the code size of ceval.c, which resulted in less cache effects > and gave more speed, despite the additional jumps. It possibly results in > less page-faults too, although this is unlikely. I expect this is wholly attributable to the reduced code size. Most binary operators aren't used frequently enough to make a difference in other ways. If you put the common code at the end of the code for binary '+', that would optimize the most common operator. > Which makes me think that, if we want to do something about cache effects, > it is probably not a bad idea to just "reorder" the bytecodes in the big > switch by decreasing frequency (we have some stats about this -- I believe > Skip and MAL have discussed the opcodes' frequency and the charts lie > somewhere in the archives). I remember Marc-Andre had done something in > this direction and reported some perf improvements too. Since reordering > the opcodes doesn't really hurt, if I'm about to do something with the > main loop, it'll be only this. Go for it -- sounds good! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From fdrake at beopen.com Fri Jul 28 16:06:00 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 28 Jul 2000 10:06:00 -0400 (EDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> Message-ID: <14721.37704.872570.141761@cj42289-a.reston1.va.home.com> Moshe Zadka writes: > Neither of those reasons are enough not to put the HOWTOs in the CVS tree. > Editors can keep the version in the CVS current via the patch manager, > and release them as they need to. However, people who d/l Python will > automatically download the HOWTOs. Think of perldoc lol (lists of lists) > -- definitely "HOWTO" material, but in the Perl standard docs. I'm happy to have them under CVS; I think the big issue is *where*. I'm not convinced they belong in the same portion of the tree as the standard documentation. Here's a thought: we currently have dist/ src/ Doc/ Instead, we could have: dist/ docs/ howto/ standard/ src/ The howto/ tree could be the howto collection Andrew maintains, and standard/ could be the XML version of the documentation once I've converted everything (which just shouldn't been in src/ to begin with). The documentation tools would become a separate component (which I've been thinking about for a while now), used by both the standard documentation and the howtos. Another option would be to simply create a new SourceForge project for HOWTO documents. That would be Andrew's baby, so would have to be his preferred approach. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr at thyrsus.com Fri Jul 28 16:21:09 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 10:21:09 -0400 Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: ; from moshez@math.huji.ac.il on Fri, Jul 28, 2000 at 04:45:20PM +0300 References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> Message-ID: <20000728102109.B14644@thyrsus.com> Moshe Zadka : > Neither of those reasons are enough not to put the HOWTOs in the CVS tree. > Editors can keep the version in the CVS current via the patch manager, > and release them as they need to. However, people who d/l Python will > automatically download the HOWTOs. Think of perldoc lol (lists of lists) > -- definitely "HOWTO" material, but in the Perl standard docs. I agree. There should be a HOWTO directory in the CVS tree. -- Eric S. Raymond Strict gun laws are about as effective as strict drug laws...It pains me to say this, but the NRA seems to be right: The cities and states that have the toughest gun laws have the most murder and mayhem. -- Mike Royko, Chicago Tribune From esr at thyrsus.com Fri Jul 28 16:26:23 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 10:26:23 -0400 Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <14721.37704.872570.141761@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jul 28, 2000 at 10:06:00AM -0400 References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> <14721.37704.872570.141761@cj42289-a.reston1.va.home.com> Message-ID: <20000728102623.D14644@thyrsus.com> Fred L. Drake, Jr. : > I'm happy to have them under CVS; I think the big issue is *where*. > I'm not convinced they belong in the same portion of the tree as the > standard documentation. > Here's a thought: we currently have > > dist/ > src/ > Doc/ > > Instead, we could have: > > dist/ > docs/ > howto/ > standard/ > src/ > > The howto/ tree could be the howto collection Andrew maintains, and > standard/ could be the XML version of the documentation once I've > converted everything (which just shouldn't been in src/ to begin > with). This seems eminently reasonable to me. -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. From akuchlin at mems-exchange.org Fri Jul 28 16:21:32 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 28 Jul 2000 10:21:32 -0400 Subject: [Python-Dev] Howto docs In-Reply-To: <14721.37704.872570.141761@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jul 28, 2000 at 10:06:00AM -0400 References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> <14721.37704.872570.141761@cj42289-a.reston1.va.home.com> Message-ID: <20000728102132.A29083@kronos.cnri.reston.va.us> On Fri, Jul 28, 2000 at 10:06:00AM -0400, Fred L. Drake, Jr. wrote: > Instead, we could have: > dist/ > docs/ > howto/ > standard/ > src/ If you want to do this reorganization, fine, but it seems like it'll be a long way off. Why not just put them in nondist/doc/howto? (Other documentation could be put in nondist/doc -- I could even dig out the grimoire and add it, if someone would be interested in updating and maintaining it.) On the other hand, the documentation maintainers might be a different set of people from code maintainers, and we might not want them checking in code changes, so having the docs as a completely separate project would allow finer control of this. On the third hand, we do have the python-checkins list to keep an eye on what's happening. I'd vote for nondist/doc/howto. --amk From esr at thyrsus.com Fri Jul 28 16:32:56 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 10:32:56 -0400 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007281505.KAA04865@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 28, 2000 at 10:05:48AM -0500 References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> Message-ID: <20000728103256.E14644@thyrsus.com> Guido van Rossum : > > Which makes me think that, if we want to do something about cache effects, > > it is probably not a bad idea to just "reorder" the bytecodes in the big > > switch by decreasing frequency (we have some stats about this -- I believe > > Skip and MAL have discussed the opcodes' frequency and the charts lie > > somewhere in the archives). I remember Marc-Andre had done something in > > this direction and reported some perf improvements too. Since reordering > > the opcodes doesn't really hurt, if I'm about to do something with the > > main loop, it'll be only this. > > Go for it -- sounds good! Allow me to also suggest liberal use of "inline" for small helper functions called from within the main interpreter loop. The nonlocality produced by subroutine calls plays hell with small caches. Side observation: the fact that micro-optimizations are giving us measurable speedups tells us that the higher-level architecture and algoirithms are very well tuned. Take a bow, Guido! -- Eric S. Raymond "Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action." -- George Washington, in a speech of January 7, 1790 From esr at thyrsus.com Fri Jul 28 16:42:23 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 10:42:23 -0400 Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jul 28, 2000 at 09:24:41AM -0400 References: <20000727173859.A10337@thyrsus.com> <20000728083419.B10938@newcnri.cnri.reston.va.us> <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> Message-ID: <20000728104223.G14644@thyrsus.com> Fred L. Drake, Jr. : > curses.textbox should be documented in a \section like any other > module. It can be placed in libcurses.tex along with the other > curses-related modules. Ah! I didn't realize multiple suggestions could live in the same file under our conventions. Guess I'll have to go reread the Documentation HOWTO. > Is curses.wrapper documented, or is it an implementation detail? I'll document it. -- Eric S. Raymond No matter how one approaches the figures, one is forced to the rather startling conclusion that the use of firearms in crime was very much less when there were no controls of any sort and when anyone, convicted criminal or lunatic, could buy any type of firearm without restriction. Half a century of strict controls on pistols has ended, perversely, with a far greater use of this weapon in crime than ever before. -- Colin Greenwood, in the study "Firearms Control", 1972 From mal at lemburg.com Fri Jul 28 16:39:21 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 16:39:21 +0200 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> <200007281238.HAA04294@cj20424-a.reston1.va.home.com> Message-ID: <39819B19.F5624BD0@lemburg.com> Guido van Rossum wrote: > > > > IIRC ActiveState contributed to Perl a version of fork that works > > > on Win32. Has anyone looked at this? Could it be grabbed for > > > Python? This would help heal one of the more difficult platform > > > rifts. Emulating fork for Win32 looks quite difficult to me but if > > > its already done... > > > This would indeed be a *very* useful addition and help porting > > os.fork() applications to Win32. (Ok, in the long run they would > > have to be converted to multi-threaded apps due to the process > > creation overhead on Win32, but for short term porting to Win32 > > this would be a Cool Thing, IMHO.) > > I have only one word: yuck! > > Portable Python code should not rely on fork. I wasn't talking about "portable" code, but about "porting" code to Win32. I happen to use an application which manages a few processes and spawns these using .fork(). It would nice to have a .fork() like API on Win32 to experiment with. Anyway, I would already be happy if I could just look at the code from ActiveState... if it's Perl all the way I probably don't want to look any further into this ;-) BTW, I'm not too familiar with IPC on Win32. What would be the best strategy to this on the Windows platforms ? I remember that Skip once posted a comparison of Unix Domain sockets and TCP Sockets on Unix which showed that UD sockets are much faster than TCP sockets. On Win32 these don't exist and I suppose that TCP sockets are too slow for my server. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Fri Jul 28 16:59:57 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 16:59:57 +0200 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> Message-ID: <39819FED.41C11063@lemburg.com> Guido van Rossum wrote: > > > Since we're at it, it's worth mentioning another conclusion we came across > > at the time: the cache effects in the main loop are significant -- it is > > more important to try keeping at best the main loop small enough, so that > > those effects are minimized. > > Yes, that's what Tim keeps hammering on too. +1 from here ;-) I have done quite a bit of testing with the old 1.5 ceval loop (patch still available in case someone wants to look at it) and found these things: 1. It pays off to special case LOAD_FAST by handling it before going into the switch at all, since this is the one most often used opcode in Python. 2. Reordering the opcodes has some noticable effect on performance too, even though it is very touchy to cache lines. 3. Splitting the big switch in two with the first one holding the most of often used opcodes while the second one takes care of the more esoteric ones helps keeping the inner loop in the CPU cache and thus increases performance. From esr at thyrsus.com Fri Jul 28 17:26:46 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 11:26:46 -0400 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <39819FED.41C11063@lemburg.com>; from mal@lemburg.com on Fri, Jul 28, 2000 at 04:59:57PM +0200 References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> Message-ID: <20000728112646.A15634@thyrsus.com> M.-A. Lemburg : > LOAD_FAST(124) : 19323126 ================================ > SET_LINENO(127) : 15055591 ======================== > LOAD_CONST(100) : 9254683 =============== > LOAD_NAME(101) : 8218954 ============= > LOAD_GLOBAL(116) : 7174876 =========== > STORE_FAST(125) : 5927769 ========= > POP_TOP( 1) : 5587424 ========= > CALL_FUNCTION(131) : 5404709 ======== > JUMP_IF_FALSE(111) : 5289262 ======== > COMPARE_OP(106) : 4495179 ======= > LOAD_ATTR(105) : 3481878 ===== > BINARY_ADD( 23) : 3420811 ===== > RETURN_VALUE( 83) : 2221212 === > STORE_NAME( 90) : 2176228 === > STORE_ATTR( 95) : 2085338 === > BINARY_SUBSCR( 25) : 1834612 === > JUMP_ABSOLUTE(113) : 1648327 == > STORE_SUBSCR( 60) : 1446307 == > JUMP_FORWARD(110) : 1014821 = > BINARY_SUBTRACT( 24) : 910085 = > POP_BLOCK( 87) : 806160 = > STORE_GLOBAL( 97) : 779880 = > FOR_LOOP(114) : 735245 = > SETUP_LOOP(120) : 657432 = > BINARY_MODULO( 22) : 610121 = > 32( 32) : 530811 > 31( 31) : 530657 > BINARY_MULTIPLY( 20) : 392274 > SETUP_EXCEPT(121) : 285523 Some thoughts: 1. That looks as close to a Poisson distribution as makes no difference. I wonder what that means? 2. Microtuning in the implementations of the top 3 opcodes looks indicated, as they seem to constitute more than 50% of all calls. 3. On the other hand, what do you get when you weight these by average time per opcode? -- Eric S. Raymond "The bearing of arms is the essential medium through which the individual asserts both his social power and his participation in politics as a responsible moral being..." -- J.G.A. Pocock, describing the beliefs of the founders of the U.S. From thomas at xs4all.net Fri Jul 28 17:32:56 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 17:32:56 +0200 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <20000728112646.A15634@thyrsus.com>; from esr@thyrsus.com on Fri, Jul 28, 2000 at 11:26:46AM -0400 References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <20000728112646.A15634@thyrsus.com> Message-ID: <20000728173256.C266@xs4all.nl> On Fri, Jul 28, 2000 at 11:26:46AM -0400, Eric S. Raymond wrote: > > LOAD_FAST(124) : 19323126 ================================ > > SET_LINENO(127) : 15055591 ======================== > 1. That looks as close to a Poisson distribution as makes no difference. > I wonder what that means? It means there's still room for optimization! Other than that, probably not much. I also think that the similarity vanishes if you take into account that SET_LINENO does nothing, and LOAD_FAST is a basic operation and should be grouped with LOAD_NAME and LOAD_GLOBAL. > 2. Microtuning in the implementations of the top 3 opcodes looks indicated, > as they seem to constitute more than 50% of all calls. Actually, I believe there was talk of removing SET_LINENO altogether... or am I mistaken in that ? In any case, you can do it by using -OO. > 3. On the other hand, what do you get when you weight these by average > time per opcode? My guess is that *_NAME moves on up, as they already are pretty high up, and BINARY_* and UNARY_*, go *way* up: imagine all those classes that implement __add__ and __not__. Even if you have but a few of those calls, they effectively are (Python) function calls. In other words, those are pretty meaningless. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov at inrialpes.fr Fri Jul 28 17:47:50 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 17:47:50 +0200 (CEST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <39819FED.41C11063@lemburg.com> from "M.-A. Lemburg" at Jul 28, 2000 04:59:57 PM Message-ID: <200007281547.RAA06456@python.inrialpes.fr> M.-A. Lemburg wrote: > > If you need help, I can dig up those old tools and patches... Yes, please do. I think I'll come up with a patch posted to SF for your collective review. [Eric Reymond, on opcode stats by MAL] > > LOAD_FAST(124) : 19323126 ================================ > > SET_LINENO(127) : 15055591 ======================== > > LOAD_CONST(100) : 9254683 =============== > > LOAD_NAME(101) : 8218954 ============= > > ... > > Some thoughts: > > 1. That looks as close to a Poisson distribution as makes no difference. > I wonder what that means? Well, it's difficult to say what this means without looking at the tools that were used to generate these stats. > > 2. Microtuning in the implementations of the top 3 opcodes looks indicated, > as they seem to constitute more than 50% of all calls. Imagine what will happen if SET_LINENO disappears But this is very tricky business which is more complicated than it looks like... > > 3. On the other hand, what do you get when you weight these by average > time per opcode? I haven't run 100M opcodes, but you may want to have a look at some old micro-profiling I did long time ago: http://starship.python.net/~vlad/tprof/ The relevant file for the main loop is: http://starship.python.net/~vlad/tprof/pybench-0.6/python-151-orig-thr/__t.eval_code2_ceval.c I am not sure this makes any sense by now, though. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Fri Jul 28 18:07:21 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 18:07:21 +0200 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <20000728112646.A15634@thyrsus.com> Message-ID: <3981AFB9.26AEB1D1@lemburg.com> "Eric S. Raymond" wrote: > > M.-A. Lemburg : > > LOAD_FAST(124) : 19323126 ================================ > > SET_LINENO(127) : 15055591 ======================== > > LOAD_CONST(100) : 9254683 =============== > > LOAD_NAME(101) : 8218954 ============= > > LOAD_GLOBAL(116) : 7174876 =========== > > STORE_FAST(125) : 5927769 ========= > > POP_TOP( 1) : 5587424 ========= > > CALL_FUNCTION(131) : 5404709 ======== > > JUMP_IF_FALSE(111) : 5289262 ======== > > COMPARE_OP(106) : 4495179 ======= > > LOAD_ATTR(105) : 3481878 ===== > > BINARY_ADD( 23) : 3420811 ===== > > RETURN_VALUE( 83) : 2221212 === > > STORE_NAME( 90) : 2176228 === > > STORE_ATTR( 95) : 2085338 === > > BINARY_SUBSCR( 25) : 1834612 === > > JUMP_ABSOLUTE(113) : 1648327 == > > STORE_SUBSCR( 60) : 1446307 == > > JUMP_FORWARD(110) : 1014821 = > > BINARY_SUBTRACT( 24) : 910085 = > > POP_BLOCK( 87) : 806160 = > > STORE_GLOBAL( 97) : 779880 = > > FOR_LOOP(114) : 735245 = > > SETUP_LOOP(120) : 657432 = > > BINARY_MODULO( 22) : 610121 = > > 32( 32) : 530811 > > 31( 31) : 530657 > > BINARY_MULTIPLY( 20) : 392274 > > SETUP_EXCEPT(121) : 285523 > > Some thoughts: > > 1. That looks as close to a Poisson distribution as makes no difference. > I wonder what that means? I'd say that there are good chances on applying optimizations to the Python byte code -- someone with enough VC should look into this on a serious basis ;-) I think that highly optimized Python byte code compilers/ interpreters would make nice commercial products which complement the targetted Python+Batteries distros. > 2. Microtuning in the implementations of the top 3 opcodes looks indicated, > as they seem to constitute more than 50% of all calls. Separating out LOAD_FAST from the switch shows a nice effect. SET_LINENO is removed by -OO anyway, so there's really no use in optimizing this one. In my hacked up version I've also moved the signal handler into the second switch (along with SET_LINENO). The downside of this is that your program will only "see" signals if it happens to execute one of the less common opcodes, on the plus side you get an additional boost in performance -- if your app doesn't rely on signals to work, this is also a great way to squeeze out a little more performance. > 3. On the other hand, what do you get when you weight these by average > time per opcode? Haven't tested this, but even by simply reordering the cases according to the above stats you get a positive response from pybench and pystone. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at mems-exchange.org Fri Jul 28 18:13:12 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 28 Jul 2000 12:13:12 -0400 Subject: [Python-Dev] Reordering opcodes In-Reply-To: <3981AFB9.26AEB1D1@lemburg.com>; from mal@lemburg.com on Fri, Jul 28, 2000 at 06:07:21PM +0200 References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <20000728112646.A15634@thyrsus.com> <3981AFB9.26AEB1D1@lemburg.com> Message-ID: <20000728121312.E29083@kronos.cnri.reston.va.us> On Fri, Jul 28, 2000 at 06:07:21PM +0200, M.-A. Lemburg wrote: >I'd say that there are good chances on applying optimizations >to the Python byte code -- someone with enough VC should look >into this on a serious basis ;-) At OLS I saw David S. Miller's keynote. Miller's been a Linux kernel hacker for quite a long time, and has been responsible for much of the Sparc and MIPS port, maintains the networking stack, etc. In his talk he mentioned that occasionally he gets really tired of kernel-space work, and has to do something in user-space for a change of pace; in that vein he rewrote GCC's Sparc64 backend, and recently wrote an nVidia driver for XFree86. My first thought when he said that was "Gosh, he should look at ceval.c!" --amk From billtut at microsoft.com Fri Jul 28 18:42:56 2000 From: billtut at microsoft.com (Bill Tutt) Date: Fri, 28 Jul 2000 09:42:56 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD34D@RED-MSG-50> > From: Tim Peters [mailto:tim_one at email.msn.com] > [Tim] > > ... Don't know how long it will take this half of the world to > > realize it, but UCS-4 is inevitable. > > [Bill Tutt] > > On new systems perhaps, but important existing systems (Win32, > > and probably Java) are stuck with that bad decision and have to > > use UTF-16 for backward compatability purposes. > Somehow that doesn't strike me as a good reason for Python to mimic them > . So don't. If you think UTF-16 is yet another bad engineering decision, then take the hit now of making Python's unicode support natively UCS-4 so we don't have a backward compatability problem when the next Unicode or ISO 10646 revision comes out. Just realize and accept the cost of doing so. (constant conversions for a nice big chunk of your users.) > > Surrogates aren't as far out as you might think. (The next rev of > > the Unicode spec) > But indeed, that's the *point*: they exhausted their 64K space in just a > few years. Now the same experts say that adding 4 bits to the range will > suffice for all time; I don't buy it; they picked 4 bits because that's what > the surrogate mechanism was defined earlier to support. I don't think the experts are saying the extra 4 bits will suffice for all time, but it should certainly suffice until we meet aliens form a different planet. :) > > That's certainly sooner than Win32 going away. :) > I hope it stays around forever -- it's a great object lesson in what > optimizing for yesterday's hardware can buy you . Heh. A dev manager from Excel made the exact same comment to me just yesterday. :) Bill From thomas at xs4all.net Fri Jul 28 18:45:12 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 18:45:12 +0200 Subject: [Python-Dev] buglet in unary ops on classes. Message-ID: <20000728184512.D266@xs4all.nl> While poking around looking for something else, I found this little buglet: >>> class X: ... def __getattr__(self, val): ... print "getattr:", val ... raise AttributeError >>> x = X() >>> ~x getattr: __invert__ Traceback (most recent call last): File "", line 1, in ? File "", line 4, in __getattr__ AttributeError The unary ops all do this (raising AttributeError), but the binary ops do not: >>> x+1 getattr: __coerce__ getattr: __add__ Traceback (most recent call last): File "", line 1, in ? TypeError: __add__ nor __radd__ defined for these operands Shouldn't this translation be done for unary ops as well ? Is it safe to assume that instance_getattr() only returns NULL if the attribute is not found ? PyInstance_DoBinOp() takes this assumption wrt. PyObject_GetAttr(), and I don't really see a problem with it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov at inrialpes.fr Fri Jul 28 19:01:31 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 19:01:31 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <3981AFB9.26AEB1D1@lemburg.com> from "M.-A. Lemburg" at Jul 28, 2000 06:07:21 PM Message-ID: <200007281701.TAA06630@python.inrialpes.fr> M.-A. Lemburg wrote: > > Separating out LOAD_FAST from the switch shows a nice effect. > SET_LINENO is removed by -OO anyway, so there's really no > use in optimizing this one. Actually, I think that instead of fighting with SET_LINENO for the standard setup, it would make sense to change the invocation options to something more standard: 1) python - code without SET_LINENO 2) python -g - code for debugging, with SET_LINENO 3) python -O - code without doc-strings. The point is that currently there's no optimization of the code stream at all, in the sense of classic compiler optimization (code block-level optimizations, loop unrolling, etc). And SET_LINENO is actually useful only for debugging (with pdb, etc). What about this as a sane proposal for SET_LINENO? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From trentm at ActiveState.com Fri Jul 28 19:10:15 2000 From: trentm at ActiveState.com (Trent Mick) Date: Fri, 28 Jul 2000 10:10:15 -0700 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) In-Reply-To: <39815E94.462F65EF@lemburg.com> References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> Message-ID: <20000728101015.A6542@ActiveState.com> On Fri, Jul 28, 2000 at 12:21:08PM +0200, M . -A . Lemburg wrote: > > > > IIRC ActiveState contributed to Perl a version of fork that works on > > Win32. Has anyone looked at this? Could it be grabbed for Python? This would > > help heal one of the more difficult platform rifts. Emulating fork for Win32 > > looks quite difficult to me but if its already done... > > This would indeed be a *very* useful addition and help porting > os.fork() applications to Win32. (Ok, in the long run they would > have to be converted to multi-threaded apps due to the process > creation overhead on Win32, but for short term porting to Win32 > this would be a Cool Thing, IMHO.) > > Can this code be grabbed from somewhere ? > It is all in ActivePerl. You can download the source code: http://www.activestate.com/Products/ActivePerl/Download.html Besides, I would guess (and I *am* guessing, I don't know this) that the Perl fork stuff is fairly closely tied to Perl, i.e. it may not be easy at all to yank it out and plug it into Python. However, I echo the Bill's and Guido's sentiments. Having a hacked emulation of fork encourages people to use it. Once someone has their favorite UNIX app it running on Win32 with the fake-fork they will have little incentive to port it properly using threads. There will then be calls to improve to Win32 fork implementation... and that is the wrong support path. Trent -- Trent Mick TrentM at ActiveState.com From mal at lemburg.com Fri Jul 28 20:12:48 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 20:12:48 +0200 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> <20000728101015.A6542@ActiveState.com> Message-ID: <3981CD20.BD53BFF0@lemburg.com> Trent Mick wrote: > > On Fri, Jul 28, 2000 at 12:21:08PM +0200, M . -A . Lemburg wrote: > > > > > > IIRC ActiveState contributed to Perl a version of fork that works on > > > Win32. Has anyone looked at this? Could it be grabbed for Python? This would > > > help heal one of the more difficult platform rifts. Emulating fork for Win32 > > > looks quite difficult to me but if its already done... > > > > This would indeed be a *very* useful addition and help porting > > os.fork() applications to Win32. (Ok, in the long run they would > > have to be converted to multi-threaded apps due to the process > > creation overhead on Win32, but for short term porting to Win32 > > this would be a Cool Thing, IMHO.) > > > > Can this code be grabbed from somewhere ? > > > > It is all in ActivePerl. You can download the source code: > > http://www.activestate.com/Products/ActivePerl/Download.html Thanks. > Besides, I would guess (and I *am* guessing, I don't know this) that the Perl > fork stuff is fairly closely tied to Perl, i.e. it may not be easy at all to > yank it out and plug it into Python. > > However, I echo the Bill's and Guido's sentiments. Having a hacked > emulation of fork encourages people to use it. Once someone has their > favorite UNIX app it running on Win32 with the fake-fork they will have > little incentive to port it properly using threads. There will then be calls > to improve to Win32 fork implementation... and that is the wrong support > path. You're probably right... :-/ BTW, (pardon my ignorance) what is the most portable way to do the equivalent of a os.system("cmd &") as native OS API call ? [On Unix, "cmd &" starts a new process which runs in the background and detached from the calling process.] I've looked at .execve and .spawnve, but they both replace the current process. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Fri Jul 28 20:33:38 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 28 Jul 2000 20:33:38 +0200 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> <20000728101015.A6542@ActiveState.com> <3981CD20.BD53BFF0@lemburg.com> Message-ID: <008d01bff8c2$5c99f240$f2a6b5d4@hagrid> mal wrote: > BTW, (pardon my ignorance) what is the most portable way to > do the equivalent of a os.system("cmd &") as native OS > API call ? [On Unix, "cmd &" starts a new process which runs > in the background and detached from the calling process.] > > I've looked at .execve and .spawnve, but they both replace > the current process. on windows, spawn(P_NOWAIT) does what you want. here's an example from the eff-bot guide: # # os-spawn-example-2.py import os import string def run(program, *args, **kw): # find executable mode = kw.get("mode", os.P_WAIT) for path in string.split(os.environ["PATH"], os.pathsep): file = os.path.join(path, program) + ".exe" try: return os.spawnv(mode, file, (file,) + args) except os.error: pass raise os.error, "cannot find executable" run("python", "hello.py", mode=os.P_NOWAIT) From Vladimir.Marangozov at inrialpes.fr Fri Jul 28 21:24:36 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 21:24:36 +0200 (CEST) Subject: [Python-Dev] further optimising the micro-optimisations for cache locality (fwd) Message-ID: <200007281924.VAA06918@python.inrialpes.fr> FYI. It would be interesting to collect some feedback on these ideas for popular combos. Who knows... Forwarded message: > From morton at dennisinter.com Fri Jul 28 20:48:29 2000 > From: morton at dennisinter.com (Damien Morton) > To: > Subject: further optimising the micro-optimisations for cache locality > Date: Fri, 28 Jul 2000 14:34:29 -0400 > Message-ID: > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > Importance: Normal > > Folded version: > > case BINARY_ADD: > w = POP(); > v = POP(); > x = PyNumber_Add(v, w); > goto end_binop; > > case BINARY_MULTIPLY: > w = POP(); > v = POP(); > x = PyNumber_Multiply(v, w); > goto end_binop; > > ... > end_binop: > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > > Further folded version: > > > > case BINARY_POWER: > f = PyNumber_Add; > goto do_binop; > > case BINARY_MULTIPLY: > f = PyNumber_Multiply; > goto do_binop; > > ... > do_binop: > w = POP(); > v = POP(); > x = f(v, w); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > > Further Further folded version: > (i havent looked at the mainloop code, but can guess its structure) > > i assume 'op' is the opcode we are swtching on > > // the function to call for this op > (void *)() op_func[] = { ..., PyNumber_Add, PyNumber_Multiply, ... }; > > // the kind of op this func describes > unsigned char op_type[] = { ..., DO_BINOP1, DO_BINOP2, DO_UNOP, ... }; > > // these two tables will be cached because of the frequency the are accessed > // ive used a table of pointers and a table of bytes to reduce the memory > required > // because the tables are small, locality within and between the tables isnt > important > // might be an idea to force the tables into contiguous memory somehow > // i could also have used a table of structs, but alignment would increase > memory usage > > unsigned char op; > > switch(op_type[op]) { > case DO_BINOP1: > w = POP(); > v = POP(); > x = op_func[op](v, w); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > case DO_BINOP2: > w = POP(); > v = POP(); > x = op_func[op](v, w, Py_None); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > case DO_UNOP: > v = POP(); > x = op_func[op](v); > Py_DECREF(v); > PUSH(x); > if (x != NULL) continue; > break; > > ===================== original message ================================= > Guido van Rossum wrote: > > > > > [me, on micro-optimizing the main loop] > > > > Fair enough (for one particular CPU at least). > > Since we're at it, it's worth mentioning another conclusion we came across > at the time: the cache effects in the main loop are significant -- it is > more important to try keeping at best the main loop small enough, so that > those effects are minimized. > > An experiment I did at the time which gave some delta-speedup: > I folded most of the UNOP & BINOP opcodes since they differ only by the > functon they call and they duplicate most of the opcode body. Like this: > > Original: > case BINARY_POWER: > w = POP(); > v = POP(); > x = PyNumber_Power(v, w, Py_None); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > > case BINARY_MULTIPLY: > w = POP(); > v = POP(); > x = PyNumber_Multiply(v, w); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > ... > > > Folded version: > > case BINARY_POWER: > w = POP(); > v = POP(); > x = PyNumber_Power(v, w, Py_None); > goto end_binop; > > case BINARY_MULTIPLY: > w = POP(); > v = POP(); > x = PyNumber_Multiply(v, w); > goto end_binop; > > ... > end_binop: > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > > > This reduced the code size of ceval.c, which resulted in less cache effects > and gave more speed, despite the additional jumps. It possibly results in > less page-faults too, although this is unlikely. > > Which makes me think that, if we want to do something about cache effects, > it is probably not a bad idea to just "reorder" the bytecodes in the big > switch by decreasing frequency (we have some stats about this -- I believe > Skip and MAL have discussed the opcodes' frequency and the charts lie > somewhere in the archives). I remember Marc-Andre had done something in > this direction and reported some perf improvements too. Since reordering > the opcodes doesn't really hurt, if I'm about to do something with the > main loop, it'll be only this. > > > > > > Micro-optimization doesn't worth the effort. As to the 2-byte arg limit, > > > I think I'd be happy if the compiler raises an exception if this limit > > > is exceeded. > > > > That would be a good first step indeed! > > I'll try to have a look, if someone else is not more reactive than me. > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 > -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas at xs4all.net Fri Jul 28 21:41:54 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 21:41:54 +0200 Subject: [Python-Dev] further optimising the micro-optimisations for cache locality (fwd) In-Reply-To: <200007281924.VAA06918@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Fri, Jul 28, 2000 at 09:24:36PM +0200 References: <200007281924.VAA06918@python.inrialpes.fr> Message-ID: <20000728214154.G266@xs4all.nl> On Fri, Jul 28, 2000 at 09:24:36PM +0200, Vladimir Marangozov wrote: > It would be interesting to collect some feedback on these ideas for > popular combos. Who knows... I like these ideas, though I think anything beyond 'further folded' requires a seperate switch for the non-common operators and those that do a tad more than call a function with a certain number of arguments and push the result on the stack. Re-numbering the ops into fast-ops and slow-ops, as well as argument-ops and nonargument-ops. (I hope all non-argument ops fall in the 'fast' category, or it might get tricky ;-P) I'm also wondering whether they really speed things up. The confusion might force the compiler to generate *less* efficient code. Then again, it removes some of the burden from the compiler, too, so it probably depends very heavily on the compiler whether this is going to have a positive effect. > > // the function to call for this op > > (void *)() op_func[] = { ..., PyNumber_Add, PyNumber_Multiply, ... }; > > > > // the kind of op this func describes > > unsigned char op_type[] = { ..., DO_BINOP1, DO_BINOP2, DO_UNOP, ... }; > > > > // these two tables will be cached because of the frequency the are > > // accessed > > // ive used a table of pointers and a table of bytes to reduce the > > // memory required because the tables are small, locality within and > > // between the tables isnt important > > // might be an idea to force the tables into contiguous memory somehow > > // i could also have used a table of structs, but alignment would > > // increase memory usage I'm not so sure about any of these comments, given that we do jump to a function right after accessing these tables. I suggest heavy testing, and I can offer only two architectures myself (linux-i386 and solaris-sparc-gcc.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From trentm at activestate.com Fri Jul 28 22:02:07 2000 From: trentm at activestate.com (Trent Mick) Date: Fri, 28 Jul 2000 13:02:07 -0700 Subject: [Python-Dev] build problems under MSVC 5.0 In-Reply-To: <019e01bfe1ec$728c6c00$f2a6b5d4@hagrid> References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> <20000629095343.B21926@activestate.com> <019e01bfe1ec$728c6c00$f2a6b5d4@hagrid> Message-ID: <20000728130207.A7348@ActiveState.com> On Thu, Jun 29, 2000 at 07:07:02PM +0200, Fredrik Lundh wrote: > trent wrote: > > I think (am I wrong?) to generalize that the intention for both Win32 and > > Win64 is to have _beginthread return an unsigned pointer-sized integer: hence > > uintptr_t. > > > > This would eliminate the #ifdef but would require a typedef for uintptr_t on > > Win32. This can be done in PC/config.h (I already did this for intptr_t, > > because I needed *that* elsewhere.) Does this also need to be generalized to > > typedef uintptr_t whereever it is not defined, i.e. in the autoconf files. > > > > I can look at this this weekend, if that is soon enough. > > I suggest checking in the #ifdef as a stopgap measure, if you > promise to come up with the right thing (whatever that is) in > time for 1.6 final. > > Should I go ahead and check it in? > Fredrik, I have put the "right thing" (I hope) up on SourceForge and assigned it to you: http://sourceforge.net/patch/?func=detailpatch&patch_id=101010&group_id=5470 I explained what I think is the right idea in the preceeding email in this thread: http://www.python.org/pipermail/python-dev/2000-June/011800.html Could you try the patch and then assign it back to me for check in? (Or just check it in yourself) Thanks, Trent -- Trent Mick TrentM at ActiveState.com From Vladimir.Marangozov at inrialpes.fr Fri Jul 28 22:20:02 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 22:20:02 +0200 (CEST) Subject: [Python-Dev] further optimising the micro-optimisations for cache locality (fwd) In-Reply-To: <20000728214154.G266@xs4all.nl> from "Thomas Wouters" at Jul 28, 2000 09:41:54 PM Message-ID: <200007282020.WAA07138@python.inrialpes.fr> Thomas Wouters wrote: > > On Fri, Jul 28, 2000 at 09:24:36PM +0200, Vladimir Marangozov wrote: > > > It would be interesting to collect some feedback on these ideas for > > popular combos. Who knows... > > I like these ideas, though I think anything beyond 'further folded' requires > a seperate switch for the non-common operators and those that do a tad more > than call a function with a certain number of arguments and push the result > on the stack. I agree. Note that all we can get though this game is some dubious percents that we shouldn't ignore, but which persistency in the long term is quite questionable. There's no way that, to pick a guy at random, Tim won't confirm this! And just like Guido, I'm not ready to trade code cleanliness for dubious speed. However, I take the opportunity to invite you again to "heavy test" the object allocator's candidate -- obmalloc.c, which, in my educated understanding of the current C implementation is the only piece of code that is capable of increasing Python's overall performance by > 10% assuming that your script involves object allocations. It is my strong belief that this perfomance comes for free, by instrumenting Python at its most inner internals, not on top of it! Of course, improvements to this code are welcome and I'd be happy to discuss them in this forum. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mwh21 at cam.ac.uk Fri Jul 28 22:58:11 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 28 Jul 2000 21:58:11 +0100 Subject: [Python-Dev] extended slicing for lists In-Reply-To: Michael Hudson's message of "27 Jul 2000 21:41:02 +0100" References: <200007271412.JAA12251@cj20424-a.reston1.va.home.com> Message-ID: Michael Hudson writes: > Guido van Rossum writes: > > > > Good idea. Are lists and tuples going to support seq[a:b:c] anytime > > > soon? > > > > It's on my wish list, but can't be done for 2.0. > > This would involve the list type implementing the mapping API wouldn't > it? This would seem to be a little on the silly side. Never mind; > here's a quick-hack patch that "seems to work" for lists: [snip] I've now put this (or a slightly less buggy version) onto sourceforge. Guido said (after I bothered him in private email) that he'd expect that: >>> l = range(10) >>> l[2:10:2] = [0]*5 >>> l [0, 1, 0, 3, 0, 5, 0, 7, 0, 9] >>> And also: >>> l = range(10) >>> l[4:-1:-1] = range(5) >>> l [4, 3, 2, 1, 0, 5, 6, 7, 8, 9] >>> (and presumably del l[a:b:c]) Now I'd expect *that* as well, but I was wondering what should happen if the lengths of the lists don't match up ... just bail? That would be easiest, but it doesn't quite gel well with current behaviour for simple slices. Presuming an error, what about these (assuming d is a list of the wrong length): l[a:b:-1] = d l[a:b:1] = d l[a:b:] = d I think these should probably be errors too, but I'd welcome any opinions people have. Cheers, M. -- A witty saying proves nothing. -- Voltaire From bwarsaw at beopen.com Fri Jul 28 23:24:57 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 28 Jul 2000 17:24:57 -0400 (EDT) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> Message-ID: <14721.64041.139313.716754@anthem.concentric.net> >>>>> "M" == M writes: M> These stats were created using an instrumented Python M> interpreter running real applications (and recording all M> executed opcodes to a file), so they can be considered close M> enough to what Python typically does in its inner loop. M> If you need help, I can dig up those old tools and patches... If you can update them for the current CVS, I'd suggest uploading them to SF. I'd then be willing to run Mailman for a while on an instrumented Python to see what it does. -Barry From guido at beopen.com Sat Jul 29 04:02:38 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 21:02:38 -0500 Subject: [Python-Dev] Python License News Message-ID: <200007290202.VAA05626@cj20424-a.reston1.va.home.com> Bob Weiner (BeOpen's CTO, my boss) told me that he's very close to reaching a compromise with CNRI about the new Python license. There's only one remaining issue before Richard Stallman is willing to declare the license GPL-compatible. We expect that this wrinkle will be worked out with CNRI's president Bob Kahn on Monday. Tim Peters knows more, you just have to ask the right way. :-) Gotta run, --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From mhammond at skippinet.com.au Sat Jul 29 05:07:38 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 29 Jul 2000 13:07:38 +1000 Subject: [Python-Dev] Python License News In-Reply-To: <200007290202.VAA05626@cj20424-a.reston1.va.home.com> Message-ID: [Trimmed to list for the sake of Tim's modesty] > Tim Peters knows more, you just have to ask the right way. :-) Tim - tell us about your testicles again! Is-that-correct-ly, Mark. From fdrake at beopen.com Sat Jul 29 06:05:17 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 29 Jul 2000 00:05:17 -0400 (EDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <20000728104223.G14644@thyrsus.com> References: <20000727173859.A10337@thyrsus.com> <20000728083419.B10938@newcnri.cnri.reston.va.us> <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> <20000728104223.G14644@thyrsus.com> Message-ID: <14722.22525.140359.615231@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Ah! I didn't realize multiple suggestions could live in the same file > under our conventions. Guess I'll have to go reread the Documentation > HOWTO. Multiple sections can live in the same file if they are sufficiently tightly related. For example, curses and curses.ascii, pyexpat and pyexpat.errors, pickle and cPickle, StringIO and cStringIO. I don't know that this is discussed in "Documenting Python," but should be; I'll fix that for Python 2.0. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sat Jul 29 08:14:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 29 Jul 2000 02:14:18 -0400 Subject: [Python-Dev] Python License News In-Reply-To: Message-ID: [Guido] > Tim Peters knows more, you just have to ask the right way. :-) [Mark Hammond] > Tim - tell us about your testicles again! > > Is-that-correct-ly, Works for me. I had thought they were permanently enlarged, but I detect signs that, should the temperature in Virginia ever fall below 80F, and the relative humidity below a gazillion or two percent, they may return to a familiar state. I grew up in a cold climate, and this may just be a bizarre attempt to shed excess heat. I expect to set up a home page soon with a charming and practical photographic essay on this topic . As to the Python license, Guido said > We expect that this wrinkle will be worked out with CNRI's > president Bob Kahn on Monday. and given the history of this I'd rather wait until then to see whether expectations pan out -- and discussing the license before we're allowed to *show* it would be frustrating for everyone anyway. That said, this is certainly a harder license for a non-lawyer to understand than was the CWI license, but I expect CNRI would counter that their license is more likely than CWI's to stand up in court. If such things interest you, feel free to speculate . Some things *everyone* should agree are good: + Eric Raymond informed us that the board of the Open Source Initiative had voted to certify the license as fully Open Source compliant. http://www.opensource.org/osd.html That was a happy day! But it's already become a slightly different license than they voted on, so I bet we have to seek OSI certification again. + I've seen Richard Stallman's remaining objections, and they're of a technical nature (meaning that to BeOpen PythonLabs they don't seem like they *should* be a sticking point; but CNRI may not agree). As many dozens of current Python projects rely on GPL compatibility, BeOpen will not accept a license that RMS rejects (and, I'll add, he's made the *reasons* for his objections clear, and has gone the extra mile to suggest specific changes). + My previous employers used Python in proprietary ("closed source") ways, and I *believe* the proposed license still allows that. But there are new (relative to the CWI Python license) requirements, and I don't understand what some of the license text means, so don't take my guess on that! Anyone who intends using Python 1.6 or beyond in proprietary ways would be well advised to have their lawyers study the license carefully, as no party to this negotiation was in your shoes or visibly (to me) looking out for you. (And, no, I was not a party to any of it) + There is still no clause specifically prohibiting ActiveState from using Python . Or anyone else. ordered-the-champagne-but-not-drinking-it-yet-ly y'rs - tim From ping at lfw.org Sat Jul 29 08:57:22 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Fri, 28 Jul 2000 23:57:22 -0700 (PDT) Subject: [Python-Dev] extended slicing for lists In-Reply-To: Message-ID: On 28 Jul 2000, Michael Hudson wrote: > >>> l = range(10) > >>> l[2:10:2] = [0]*5 > >>> l > [0, 1, 0, 3, 0, 5, 0, 7, 0, 9] > >>> Hmph. I'd be perfectly comfortable with >>> l[2:10:2] = [0]*5 TypeError: lists cannot assign to stepped slices I can't see this being a commonly desired feature. If it were perfectly clear what should happen in all cases, i'd be okay with it -- but the ambiguity you get when the length of the right side doesn't match the length of the indicated slice is sufficient for me to suggest just dropping it: better to avoid confusion altogether. > (and presumably del l[a:b:c]) That seems reasonable and well-defined. A separate question: does l[::-1] return l reversed? That is, are the defaults for omitted start/end exchanged if step is negative? This would seem to be quite useful -- having to say l[len(l)-1:-1:-1] would be a royal pain. -- ?!ng From moshez at math.huji.ac.il Sat Jul 29 08:51:21 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 29 Jul 2000 09:51:21 +0300 (IDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <14722.22525.140359.615231@cj42289-a.reston1.va.home.com> Message-ID: On Sat, 29 Jul 2000, Fred L. Drake, Jr. wrote: > > Eric S. Raymond writes: > > Ah! I didn't realize multiple suggestions could live in the same file > > under our conventions. Guess I'll have to go reread the Documentation > > HOWTO. > > Multiple sections can live in the same file if they are sufficiently > tightly related. For example, curses and curses.ascii, pyexpat and > pyexpat.errors, pickle and cPickle, StringIO and cStringIO. > I don't know that this is discussed in "Documenting Python," but > should be; I'll fix that for Python 2.0. Let me just say what Fred said in a different way: from the processing engine POV, there's just *one file* with lots of include directives. The division into file is just to make life easier for us -- so if two sections are related, it's easier to keep them in the same file. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From effbot at telia.com Sat Jul 29 09:42:14 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 29 Jul 2000 09:42:14 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib SimpleHTTPServer.py,1.10,1.11 References: <200007290515.WAA25057@slayer.i.sourceforge.net> Message-ID: <002401bff930$8439f340$f2a6b5d4@hagrid> is it worth replacing a couple of lines of obvious code with a reference to a little-used module? and if I want to, how do I tweak the block size? > *** SimpleHTTPServer.py 2000/05/21 16:25:29 1.10 > --- SimpleHTTPServer.py 2000/07/29 05:15:56 1.11 > *************** > *** 16,19 **** > --- 16,20 ---- > import urllib > import cgi > + import shutil > from StringIO import StringIO > > *************** > *** 152,161 **** > > """ > ! > ! BLOCKSIZE = 8192 > ! while 1: > ! data = source.read(BLOCKSIZE) > ! if not data: break > ! outputfile.write(data) > > def guess_type(self, path): > --- 153,157 ---- > > """ > ! shutil.copyfileobj(source, outputfile) > > def guess_type(self, path): > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins From moshez at math.huji.ac.il Sat Jul 29 09:51:00 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 29 Jul 2000 10:51:00 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib SimpleHTTPServer.py,1.10,1.11 In-Reply-To: <002401bff930$8439f340$f2a6b5d4@hagrid> Message-ID: On Sat, 29 Jul 2000, Fredrik Lundh wrote: > is it worth replacing a couple of lines of obvious code > with a reference to a little-used module? I believe so. So did everyone when the thread came up on Python-Dev a couple of weeks ago -- I haven't followed up with the checkin for so long because of technical problems (AKA lack of computer). > and if I want to, how do I tweak the block size? Just like you would in the old days: subclass SimpleHTTPServer, and substitute the copyfile method with a call to shutil.copyfile with a non-default size. (IOW, it's easier then what it was before). From mwh21 at cam.ac.uk Sat Jul 29 11:07:43 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 29 Jul 2000 10:07:43 +0100 Subject: [Python-Dev] extended slicing for lists In-Reply-To: Ka-Ping Yee's message of "Fri, 28 Jul 2000 23:57:22 -0700 (PDT)" References: Message-ID: The patch is here, btw: http://sourceforge.net/patch/?func=detailpatch&patch_id=100998&group_id=5470 Ka-Ping Yee writes: > On 28 Jul 2000, Michael Hudson wrote: > > >>> l = range(10) > > >>> l[2:10:2] = [0]*5 > > >>> l > > [0, 1, 0, 3, 0, 5, 0, 7, 0, 9] > > >>> > > Hmph. I'd be perfectly comfortable with > > >>> l[2:10:2] = [0]*5 > TypeError: lists cannot assign to stepped slices > > I can't see this being a commonly desired feature. If it > were perfectly clear what should happen in all cases, i'd > be okay with it -- but the ambiguity you get when the length > of the right side doesn't match the length of the indicated > slice is sufficient for me to suggest just dropping it: > better to avoid confusion altogether. Well, the BDFL spoke. > > (and presumably del l[a:b:c]) > > That seems reasonable and well-defined. Yes. > A separate question: does l[::-1] return l reversed? Yes. All that cleverness is in PySlice_GetIndices, so this patch gets it for free. > That is, are the defaults for omitted start/end exchanged if step is > negative? This would seem to be quite useful -- having to say > l[len(l)-1:-1:-1] would be a royal pain. Well, you could probably always say l[sys.maxint:0:-1] (your example returns the empty list!) but yes, I think l[::-1] is one of the neater bits of new behaviour. Cheers, M. -- "declare"? my bogometer indicates that you're really programming in some other language and trying to force Common Lisp into your mindset. this won't work. -- Erik Naggum, comp.lang.lisp From moshez at math.huji.ac.il Sat Jul 29 12:17:14 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 29 Jul 2000 13:17:14 +0300 (IDT) Subject: [Python-Dev] test turds? Message-ID: Hi! Recently I patched a bug in whichdb. Following Tim's advice "each bug we find is a bug in the regression testing", I decided to write a test case for whichdb. However, the problem is that I'm not sure where I can create files, which must not be leftovers from the test suite. Does anyone know of a test which creates files, and how it deals with them? Thanks. awake-when-it's-night-in-*civilized*-places-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mwh21 at cam.ac.uk Sat Jul 29 12:41:30 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 29 Jul 2000 11:41:30 +0100 Subject: [Python-Dev] extended slicing for lists In-Reply-To: Michael Hudson's message of "29 Jul 2000 10:07:43 +0100" References: Message-ID: Michael Hudson writes: > The patch is here, btw: > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100998&group_id=5470 And has now been updated to support assignments & deletions. I'm happy with deletions, but assignments seem to be a bit counter-intuitive - for example both of Guido's examples: >>> l = range(10) >>> l[2:10:2] = [0]*5 >>> l [0, 1, 0, 3, 0, 5, 0, 7, 0, 9] >>> l = range(10) >>> l[4:-1:-1] = range(5) >>> l [4, 3, 2, 1, 0, 5, 6, 7, 8, 9] are wrong! >>> l[2:10:2] = [0]*5 Traceback (most recent call last): File "", line 1, in ? ValueError: attempt to assign list of size 5 to extended slice of size 4 >>> l[4:-1:-1] = range(5) Traceback (most recent call last): File "", line 1, in ? ValueError: attempt to assign list of size 5 to extended slice of size 0 So I'd really appreciate it if people could play around with the patch and see if (a) they can break it (b) they like the way assignments behave (I am already hooked on the indexing & deletion). now-all-we-need-is-a-slice-expression-for-sorting-ly y'rs M. -- 59. In English every word can be verbed. Would that it were so in our programming languages. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html From mhammond at skippinet.com.au Sat Jul 29 15:13:57 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 29 Jul 2000 23:13:57 +1000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/LibSimpleHTTPServer.py,1.10,1.11 In-Reply-To: Message-ID: > > and if I want to, how do I tweak the block size? [Moshe] > Just like you would in the old days: subclass SimpleHTTPServer, and > substitute the copyfile method with a call to shutil.copyfile with a > non-default size. (IOW, it's easier then what it was before). I think thats a little of an overkill. It requires duplicating the entire method for the sake of one constant. def copyfile(self, source, outputfile): BLOCKSIZE = 8192 to def copyfile(self, source, outputfile, blocksize = 8192): is much more reasonable IMO. Mark. From moshez at math.huji.ac.il Sat Jul 29 15:26:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 29 Jul 2000 16:26:06 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/LibSimpleHTTPServer.py,1.10,1.11 In-Reply-To: Message-ID: On Sat, 29 Jul 2000, Mark Hammond wrote: > and if I want to, how do I tweak the block size? [Moshe] > Just like you would in the old days: subclass SimpleHTTPServer, and > substitute the copyfile method with a call to shutil.copyfile with a > non-default size. (IOW, it's easier then what it was before). [Mark] > I think thats a little of an overkill. It requires duplicating the entire > method for the sake of one constant. But Mark, the "entire method" is simply a call to shutil.copyfileobj (well, that and a docstring). So "duplicating" it is the only thing possible, unless you want to define a class variable "BLOCKSIZE". It can be supported without duplicating the functionality of shutil.copyfileobj, but that sure sounds like an overkill.... -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mhammond at skippinet.com.au Sat Jul 29 15:37:45 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 29 Jul 2000 23:37:45 +1000 Subject: [Python-Dev] Re: [Python-checkins] CVS:python/dist/src/LibSimpleHTTPServer.py,1.10,1.11 In-Reply-To: Message-ID: > But Mark, the "entire method" is simply a call to shutil.copyfileobj OK - I looked at it before I updated CVS! Oops :-) > unless you want to define a class variable "BLOCKSIZE". It can > be supported without duplicating the functionality of shutil.copyfileobj, > but that sure sounds like an overkill.... Huh? Well, shutil.copyfileobj appears to have a "length" param, which is exactly what was being asked for (although possibly a poor choice of a name!). It is still more resonable to add a default param than to require a subclass. The shutil author clearly thought so! Mark. From moshez at math.huji.ac.il Sat Jul 29 15:52:36 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 29 Jul 2000 16:52:36 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS:python/dist/src/LibSimpleHTTPServer.py,1.10,1.11 In-Reply-To: Message-ID: On Sat, 29 Jul 2000, Mark Hammond wrote: [About SimpleHTTPServer.copyfile always using the default block-size] > It is still more resonable to add a default param than to require a > subclass. The shutil author clearly thought so! Ani Zatar! I'm the shutil.copyfileobj function author, and the circumstances are different. SimpleHTTPServer.copyfile is called by the methods which are not overridable (in the sense of overriding them being supported), so there is no sense in adding a default parameter -- you need to have something persistent in the class for that: and that is either a variable or method. PS. The "Ani Zatar" part is in case some Israeli reads the archive: it's a non-funny joke in Hebrew, and I won't translate it. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mmorris at pop.mindspring.com Sat Jul 29 08:19:59 2000 From: mmorris at pop.mindspring.com (Mitchell Morris) Date: Fri, 28 Jul 2000 23:19:59 -0700 Subject: [Python-Dev] Fire, may I present accellerant. Accellerant, this is fire. Message-ID: <20000729061933.LUNZ24904.mail.rdc1.wa.home.com@finin> In general I try to keep my head down. I recently needed some support for regression testing as part of a stealth Python introduction-cum-advocacy effort. I wound up using Steve Purcell's pyunit testing framework, and thought it was a shame that it wasn't part of the standard distribution. To that end ... PEP: eric-the-half-a-pep Title: Guido-blessed unit/regression test framework Version: 0 Target of Opportunity: mmorris at mindspring.com (Mitchell Morris) Python-Version: 2.0 Status: pre-pre-pre-Draft Introduction This proto-PEP advocates that there should be, in the standard library, a unit/regression test framework. This Guido-blessed framework would provide test semantics both useful and standardized. In addition to being a useful structure in it's own right, it would provide an obvious direction for development projects to prepare and use their own regression test policies. Why Should I Care? Software developers have known for quite some time that the majority of our time is spent identifying and correcting errors. Various suggestions for reducing this burden have been explored and most of them have been rejected. One thing that seems to provide some benefit is writing test plans and running them against the software product. This doesn't necessarily eliminate bugs, but it does allow us to find some of them and insure they don't reoccur as we correct later ones. One variation of this process is to extend the test plan as other defects are identified and corrected. Part of the correction would be updating the test suite to include a test that would have identified and exercised the defect. In this way the test plan grows to verify that correct behavior increases monotonically. This kind of test plan also allows very aggressive refactoring, in that the developer can make sweeping changes to module internals with great confidence that things will either (a) not break elsewhere, or (b) break loudly when the unit tests fail. Given the (relative) success of test plans and Python's general friendliness to rapid development and refactoring, there should be a standard tool in all distributions to encourage this dynamic. But ... Smalltalk and Java are Evil! Kent Beck has recently generated a lot of press by writing about his development methodology which he calls "Extreme Programming"[1]. Aside from the unfortunate connotations to sports which would still be completely anonymous without ESPN2, there are a number of useful tools emerging from the XP camp. One of the prime tenets is that developers write their classes and their unit tests at the same time. According to XP, these unit tests have to run at 100% for the code to be acceptable for integration. The design of the testing framework generated by XP is fairly simple: individual tests check the correct functionality of a single quantum of testable behavior, usually public behavior. These individual tests can be aggregated into suites, which are also runnable. Suites can be aggregated as well. Tools are provided to execute these tests and suites in both text and GUI formats. Kent Beck and Erich Gamma wrote a paper called "Test Infected"[2] to demonstrate how the code and tests are developed in tandem. This paper, written as a script for a pair programming session, shows how the various pieces of the JUnit implementation work together. (JUnit is the XP testing tool for Java.) We've Already Got One, Thanks. The current distribution has a regression testing framework, in Lib/test/regrtest.py, which addresses some of these same issues. The obvious question is why not use the tool which is already there? The current tool presents several issues that make this a less-than-exemplary solution: it doesn't allow for graphical manipulation, it separates test and expected result into separate files stored in separate locations, and it tries to generate the tests as well as run them. The objections to regrtest.py then boil down to the it's philosophy. We've Got More Than We Can Stand, Thanks. Really. Also for our consideration is doctest.py, contributed by the inestimable Tim Peters. doctest.py presents a simple straightforward means to embed the individual tests into the production code itself as commentary. This suggests that the separation of test and result presents a cognitive dissonance in other people besides just me. doctest.py doesn't provide any mechanism, however, for aggregating several modules into a single test run, nor does it provide a GUI. Once again, additional effort could obviously provide the missing functionality. On the other hand, doctest.py isn't currently part of the standard distribution. What's All This Then? The point of this proposal is Steve Purcell's pyunit package[3]. This is a Python implementation of XP's xUnit specification. It provides a means for running individual tests, aggregating individual tests into larger suites, running those tests in both text and GUI modes, and keeps the tests and expected results together in a single source module. You Have A Point? Yes: pyunit should be part of the standard library. pyunit documentation should be included in the distribution. New development should be encouraged to use pyunit. We should all rub pyunit all over our bodies as often as we can. Even if it isn't pyunit, Python should have a documented standard component for unit and regression testing, and we should encourage new development to use it, and we should demand that core development include it. References 1 -- XP Wiki see also: 2 -- Beck, Kent and Gamma, Erich, "Test Infected" 3 -- pyunit project at Source Forge pyromanically y'rs +Mitchell From guido at python.org Sat Jul 29 19:39:01 2000 From: guido at python.org (Guido van Rossum) Date: Sat, 29 Jul 2000 12:39:01 -0500 Subject: [Python-Dev] Bookstand at LA Python conference Message-ID: <200007291739.MAA06848@cj20424-a.reston1.va.home.com> The next Python conference will be in Long Beach (Los Angeles). We're looking for a bookstore to set up a bookstand like we had at the last conference. Does anybody have a suggestion? See http://www.python9.com for conference info! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Sat Jul 29 20:04:41 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 29 Jul 2000 13:04:41 -0500 Subject: [Python-Dev] Should repr() of string should observe locale? Message-ID: <200007291804.NAA07155@cj20424-a.reston1.va.home.com> There have been some requests (Francois Pinard, recently Alexander Voinov) that repr() of a string should not use escape sequences for characters that are printable according to the locale. I don't have the time to write a PEP or implement it (although it should be simple enough) but it needs to be recorded as a feature that I think is good (that's at least a +0). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From moshez at math.huji.ac.il Sat Jul 29 19:08:58 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 29 Jul 2000 20:08:58 +0300 (IDT) Subject: [Python-Dev] Should repr() of string should observe locale? In-Reply-To: <200007291804.NAA07155@cj20424-a.reston1.va.home.com> Message-ID: On Sat, 29 Jul 2000, Guido van Rossum wrote: > There have been some requests (Francois Pinard, recently Alexander > Voinov) that repr() of a string should not use escape sequences for > characters that are printable according to the locale. > > I don't have the time to write a PEP or implement it (although it > should be simple enough) but it needs to be recorded as a feature that > I think is good (that's at least a +0). I don't. Most people who are requesting it are requesting it for the purpose of the interactive Python session. I think there is general agreement that there should be a way to better control the REPL from Python (my, now lost, sys.display patch, for example). Wouldn't that solve the problem? -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From fdrake at beopen.com Sat Jul 29 21:01:52 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 29 Jul 2000 15:01:52 -0400 (EDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: References: <14722.22525.140359.615231@cj42289-a.reston1.va.home.com> Message-ID: <14723.10784.479056.30153@cj42289-a.reston1.va.home.com> Moshe Zadka writes: > Let me just say what Fred said in a different way: from the processing > engine POV, there's just *one file* with lots of include directives. > The division into file is just to make life easier for us -- so if > two sections are related, it's easier to keep them in the same file. Almost, but not quite. The division into files allows us to reorganize the sections into chapters differently with simple edits; I've found that very useful a couple of times! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From klm at digicool.com Sat Jul 29 21:53:17 2000 From: klm at digicool.com (Ken Manheimer) Date: Sat, 29 Jul 2000 15:53:17 -0400 (EDT) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <200007281701.TAA06630@python.inrialpes.fr> Message-ID: On Fri, 28 Jul 2000 Vladimir.Marangozov at inrialpes.fr wrote: > M.-A. Lemburg wrote: > > > > Separating out LOAD_FAST from the switch shows a nice effect. > > SET_LINENO is removed by -OO anyway, so there's really no > > use in optimizing this one. > > Actually, I think that instead of fighting with SET_LINENO > for the standard setup, it would make sense to change the > invocation options to something more standard: > > 1) python - code without SET_LINENO > 2) python -g - code for debugging, with SET_LINENO > 3) python -O - code without doc-strings. > > The point is that currently there's no optimization of the > code stream at all, in the sense of classic compiler optimization > (code block-level optimizations, loop unrolling, etc). > > And SET_LINENO is actually useful only for debugging (with pdb, etc). > > What about this as a sane proposal for SET_LINENO? I would be firmly -1 on this proposal. Without a major payoff - say, double or better performance improvements - i think it's a bad idea to disable debugging in the common case. Python already has -o and -oo - aren't they sufficient? (Maybe i'm misremembering, but i recall that removing SET_LINENO didn't yield a whole lot of performance improvement. Actually, i have the impression it's been a canonical example of how casual optimizations don't do what you expect - but i may be off base here.) I see the ability to debug at whim, even when you didn't expect having to do so, as being a major win, part of the incremental development process. For me, it's a virtue up there with "having the source" in making it easier to fix my own and other people's mistakes. (The inconvenience of having to rerun with debugging enabled is magnified greatly when dealing with connecting to longrunning processes, as i tend to do with zope under zeo and medusa. Then i'm really screwed if someone forgot to start with optional debugging enabled.) If you can replace SET_LINENO's functionality with something that doesn't have the same overhead, great! I have the impression from your recent comments along these lines that that isn't happening immediately... Ken klm at digicool.com From akuchlin at mems-exchange.org Sat Jul 29 22:34:57 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Sat, 29 Jul 2000 16:34:57 -0400 Subject: [Python-Dev] SF most active project listing Message-ID: I was curious about how "most active project" is defined, and took a look at the SF code. It's computed by the util/db_project_weekly_metric.pl script, which sums up a bunch of parameters to get a number. The parameters are: 3 * # of forum postings 4 * # of tasks 3 * # of bugs 10 * # of patches 5 * # of support 1 * # of CVS commits 5 * # of developers 5 * # of file releases .3 * # of downloads All of these numbers seem to be counted over the past week. I suspect the code has a mathematical bug: the queries use, for example, log(4*count(project_task.project_task_id)) for counting things. However, IIRC, log ab = log a + log b, so the multipliers just add a constant to every project's number, and therefore it's a flat sum of all the parameters. IMHO that should be 4*log(count(....)), and will report it. --amk From tim_one at email.msn.com Sat Jul 29 22:05:14 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 29 Jul 2000 16:05:14 -0400 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: Message-ID: [Ken Manheimer] > ... > (Maybe i'm misremembering, but i recall that removing SET_LINENO > didn't yield a whole lot of performance improvement. That's correct, it's rarely more than just a few percent. > Actually, i have the impression it's been a canonical example of > how casual optimizations don't do what you expect - but i may be > off base here.) Well, it did what *I* expected . There are the "state lottery" and "penny saved is a penny earned" schools of optimization. They appeal, respectively, to "no guts, no glory" and "slow and steady wins the race" types. Both are valuable, although the true merits of the latter don't become apparent until after it's been pursued consistently for years. Python hasn't done that (there's been no consistency of effort, just manic "speed it up" bursts), and neither has it pursued any Major Schemes since LOAD_FAST was introduced. The most interesting dropped project "in the middle" was Skip Montanaro's Rattlesnake, which aimed to change the VM from a stack to a register model. > I see the ability to debug at whim, even when you didn't expect having > to do so, as being a major win, part of the incremental development > process. Same here! But I'm a little warped : I worked on optimization for a living for so many years, that one reason I was attracted to Python is that it didn't do *any* optimization to screw up my view of what my code was doing. Any debugger that claims to work well with "for real" optimized code in any language is lying. So the only optimizations I've ever supported in default-mode Python are things the user can't detect via semantics or usability. So I'm also -1 on [Vladimir] > 1) python - code without SET_LINENO > 2) python -g - code for debugging, with SET_LINENO > 3) python -O - code without doc-strings. unless SET_LINENO isn't needed for debugging. The speedup -O yields today is real and consistent, but rarely makes a difference worth worrying about (the only times it's mattered for me were in extremely well-tested CPU-bound programs that I intended to run for days straight, and then I appreciated the few hours it saved). python-the-choice-for-a-slow-generation-ly y'rs - tim From tim_one at email.msn.com Sat Jul 29 22:16:26 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 29 Jul 2000 16:16:26 -0400 Subject: [Python-Dev] SF most active project listing In-Reply-To: Message-ID: [Andrew Kuchling] > I was curious about how "most active project" is defined, and took a > look at the SF code. It's computed by the > util/db_project_weekly_metric.pl script, which sums up a bunch of > parameters to get a number. The parameters are: > > 3 * # of forum postings > 4 * # of tasks > 3 * # of bugs > 10 * # of patches > 5 * # of support > 1 * # of CVS commits > 5 * # of developers > 5 * # of file releases > .3 * # of downloads > > All of these numbers seem to be counted over the past week. Since it's Perl (or PHP?), I hope they remembered to change what "past week" means each week . Hmm: since they weight patches at 10 times the value of a commit, I guess they value projects where lots of people are unhappy but can't agree on what to do about it . > I suspect the code has a mathematical bug: the queries use, for > example, log(4*count(project_task.project_task_id)) for counting > things. However, IIRC, log ab = log a + log b, so the multipliers > just add a constant to every project's number, and therefore it's a > flat sum of all the parameters. IMHO that should be > 4*log(count(....)), and will report it. Ha! *Another* bug they wouldn't have had if they had written it in Python instead! Ya, ya, I'm lying, but if we all agree to say it's the truth, maybe they'll fall for it. agreeing-with-your-analysis-but-unsure-why-they're-taking-a-log- at-all-ly y'rs - tim From ping at lfw.org Sun Jul 30 01:22:50 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sat, 29 Jul 2000 16:22:50 -0700 (PDT) Subject: [Python-Dev] extended slicing for lists In-Reply-To: Message-ID: Michael Hudson wrote: > Ka-Ping Yee writes: > > [...] sufficient for me to suggest just dropping it: > > better to avoid confusion altogether. > > Well, the BDFL spoke. Hence my mock-indignant "hmph". :) > > having to say l[len(l)-1:-1:-1] would be a royal pain. > > Well, you could probably always say > > l[sys.maxint:0:-1] > > (your example returns the empty list!) Hey, wait a second. To get l[start:end:step], you start with 'start' and keep adding 'step' until you get to -- but not including -- 'end', right? So l[len(l)-1:-1:-1] should return the entire list reversed, not the empty list. range() demonstrates the behaviour nicely: >>> size = 5 >>> range(size-1,-1,-1) [4, 3, 2, 1, 0] Wouldn't l[sys.maxint:0:-1] return all but the first element of l in reverse order? >>> range(size-1,0,-1) [4, 3, 2, 1] Note that we should deprecate the use of sys.maxint (preferring None) in this situation, since if the step is less than -1, the elements you get ought to depend on the value of sys.maxint % step. I'd expect: >>> l = [0, 1, 2, 3, 4, 5] >>> l[5:0:-3] [5, 2] >>> l[6:0:-3] [4, 1] >>> l[7:0:-3] [3, 0] >>> l[8:0:-3] [5, 2] hence >>> l[sys.maxint:0:-3] [???, ???] # depends on sys.maxint % 3 My guiding principle is that the indices should always match what you get from range(), and if start or end are missing, you get the items you would have gotten if you extend the sequence out forever. -- ?!ng From Vladimir.Marangozov at inrialpes.fr Sun Jul 30 04:39:26 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sun, 30 Jul 2000 04:39:26 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: from "Tim Peters" at Jul 29, 2000 04:05:14 PM Message-ID: <200007300239.EAA21825@python.inrialpes.fr> [Tim & Ken voting -1 and arguing about] > [Vladimir] > > 1) python - code without SET_LINENO > > 2) python -g - code for debugging, with SET_LINENO > > 3) python -O - code without doc-strings. > > unless SET_LINENO isn't needed for debugging. To be honest, I was -1 myself shortly after sending the message. The consequences, at least for IDLE, make this truly insane, unless, as you both pointed out, SET_LINENO's functionality is achieved without it. As a matter of fact, its functionality *can* be achieved, at least for debugging purposes. That is, for generating the callbacks from the main loop to a Python function, called on every new source line. This is what basically the patch I ended up with does. To clarify the current state of the challenge to remove SET_LINENO, here's a short summary of the idea we dicussed previously and which I implemented (the patch does look scary without explanation ). Consider the following code sequence diagram (current state), assuming that each position is an opcode, arguments included: 0 1 2 3 01234567890123456780123456780123 co_code -> [#....#......#....#..#....#....] where '.' - an opcode ^ '#' - SET_LINENO IP (instruction pointer) Whenever a sys.settrace function is set, it is called on every # and this is basically how the debugger gets control for each source line. It finds out the source line by reading it from the current frame - f.lineno Now, here's the picture with the patch intended to obviate SET_LINENO: 0 1 2 3 01234567890123456780123456780123 co_code -> [........................] the same co_code w/o SET_LINENO copy of -> [+...+.....+...+.+...+...] '+' is a 1-byte CALL_TRACE opcode co_code ^ overriding the 1st opcode of each internal to IP new source line eval_code2() Whenever a sys.settrace function is set, a copy of the original code stream is created and the IP is redirected to execute the copy before entering the main loop. In this copy, the 1st instruction for each line is set to CALL_TRACE. These locations are computed from the co_lnotab table. CALL_TRACE updates f.lineno and invokes the sys.settrace function. On return from sys.settrace, it reads the opcode byte it has overwritten from the original co_code and jumps directly to the argument fetch before the big switch. All this works like a charm, except that, a priori, it has 2 drawbacks regarding full compatibility with the current state with SET_LINENO: a) f.lineno is not updated on a regular basis like SET_LINENO does; only when sys.settrace is set & CALL_TRACE is called. b) the IP is redirected to the copy of co_code before entering the main loop. In practical terms, this means that only entire code objects are traceable, that is, tracing can't start in the middle of a code object. I am not sure whether these 2 things hurt. If so, probably a) hurts more than b), but this is where I stopped working on this at the time, being short of more ideas... If you have one, you're welcome :-) P!ng?? Florx bignal zupkin moognacious today? If not, this scheme probably looses due to a) and b) and SET_LINENO has to stay, at least, for full backward compatibility. Conclusion: the functionality is achieved, full back/compat is not :-/ -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one at email.msn.com Sun Jul 30 09:53:15 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 03:53:15 -0400 Subject: [Python-Dev] Should repr() of string should observe locale? In-Reply-To: Message-ID: [Guido] > There have been some requests (Francois Pinard, recently Alexander > Voinov) that repr() of a string should not use escape sequences for > characters that are printable according to the locale. > > I don't have the time to write a PEP or implement it (although it > should be simple enough) but it needs to be recorded as a feature > that I think is good (that's at least a +0). [Moshe Zadka] > I don't. Most people who are requesting it are requesting it for the > purpose of the interactive Python session. I think there is general > agreement that there should be a way to better control the REPL from > Python (my, now lost, sys.display patch, for example). Wouldn't that > solve the problem? Because str(list) and str(dict) and str(tuple) end up calling repr() on the items they contain, even simple stmts like e.g. print list_of_goofy_foreign_i.e._not_plain_ascii_strings produce unreadable octal escapes instead of the goofy foreign non-ascii characters goofy foreigners want . That's one of the Lost Pythonic Theses, btw: Goofy is better than unreadable. Hooking the REPL loop doesn't help with that, in part because an explicit print would sidestep the hook, and the rest because it's a real problem in non-interactive mode too. So there are problems other than just Fran\347ois's, including your desire to hook the P in REPL, and including that str(list) and str(dict) and str(tuple) applying repr to their containees causes horrible output for many a user-defined class too (so much so that many classes code __repr__ to do what __str__ is *supposed* to do) -- but they're arguably all distinct problems. That said, I'm -1 too, because Guido once sensibly agreed that strings produced by repr should restrict themselves to the characters C guarantees can be written and read faithfully in text-mode I/O, excluding the tab character (or, iow, each character c in a string produced by repr should have ord(c) in range(32, 128)). Give that up and text-mode pickles (plus anything else repr is used deliberately for in a text file) lose their guarantee of cross-platform portability at the C level (not to mention losing x-platform human readability); etc. The problem isn't that repr sticks in backslash escapes, the problem is that repr gets called when repr is inappropriate. There was extensive debate about that in Python-Dev earlier this year (and the year before, and ...). Thanks to the lack of PEPs in those benighted days, I bet we get to do it all over again . I can't make time for this round, though. In brief: Breaking repr's contract to produce printable ASCII is unacceptable damage to me, no matter what the short-term perceived benefit. A principled solution appeared to require a combination of (at least) making the P in the REPL loop hookable, and making the builtin container types pass on whichever of {str, repr} they were passed *to*; the latter is problematic when the containee is a string, though, because str(string) produces a string without delimiters to say "hey, I'm a string!", making the output pretty unreadable in the context of the containee; further fiddling of some sort is needed. if-the-current-repr-didn't-exist-we'd-have-to-reinvent-it-and- we-still-wouldn't-want-to-invoke-either-repr-much-of-the- time-anyway-ly y'rs - tim From akuchlin at cnri.reston.va.us Sun Jul 30 14:07:18 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 30 Jul 2000 08:07:18 -0400 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <200007300239.EAA21825@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jul 30, 2000 at 04:39:26AM +0200 References: <200007300239.EAA21825@python.inrialpes.fr> Message-ID: <20000730080718.A22903@newcnri.cnri.reston.va.us> Hasn't backward compatibility already been broken for 2.0? So why not break it a little more? It always seemed odd to me that the current line number is always kept up to date, even though 99.999% of the time, no one will care. Why not just keep a small table that holds the offset in the bytecode at which each line starts, and look it up when it's needed? --amk From guido at beopen.com Sun Jul 30 16:02:38 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 09:02:38 -0500 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: Your message of "Sun, 30 Jul 2000 08:07:18 -0400." <20000730080718.A22903@newcnri.cnri.reston.va.us> References: <200007300239.EAA21825@python.inrialpes.fr> <20000730080718.A22903@newcnri.cnri.reston.va.us> Message-ID: <200007301402.JAA08591@cj20424-a.reston1.va.home.com> > Hasn't backward compatibility already been broken for 2.0? So why not > break it a little more? Sure -- within reason. > It always seemed odd to me that the current line number is always kept > up to date, even though 99.999% of the time, no one will care. Why > not just keep a small table that holds the offset in the bytecode at > which each line starts, and look it up when it's needed? That already exists. Search for co_lnotab, and for PyCode_Addr2Line(). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From m.favas at per.dem.csiro.au Sun Jul 30 15:54:15 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Sun, 30 Jul 2000 21:54:15 +0800 Subject: [Python-Dev] checkins and regression tests Message-ID: <39843387.9F35D544@per.dem.csiro.au> It'd be nice if the newly checked-in test were run through the test framework before being checked in - the latest test_mmap.py fails due to the "inconsistent tab-space" problem... Mark -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From guido at beopen.com Sun Jul 30 17:34:06 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 10:34:06 -0500 Subject: [Python-Dev] urllib - {quote,unquote} vs. {quote_plus,unquote_plus} In-Reply-To: Your message of "Fri, 28 Jul 2000 07:17:46 EST." <14721.31210.734864.412520@beluga.mojam.com> References: <14721.31210.734864.412520@beluga.mojam.com> Message-ID: <200007301534.KAA12762@cj20424-a.reston1.va.home.com> > I realize there is a symmetry between the functionality of > urllib.{quote,unquote} and urllib.{quote_plus,unquote_plus}, but why doesn't > unquote function like unquote_plus and map "+" to " "? The +/space mapping is unique to CGI query strings. The unquote function is used in a lot of places to decode parts of URLs (e.g. throughout urllib.py itself), e.g. the hostname or (more likely) the pathname can be encoded using %xx, and there a + does *not* mean a space. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Sun Jul 30 17:42:49 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 10:42:49 -0500 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Your message of "Fri, 28 Jul 2000 15:37:56 +0200." References: Message-ID: <200007301542.KAA12794@cj20424-a.reston1.va.home.com> > IMO one of the major strenghts of Python (in its reference implementation > C-Python) has today compared to other languages (Java) is this particular > behaviour. ["this behavior": closing files as soon as they go out of scope] > The argument made in the last sentence of the paragraph cited from > the reference manual is bogus: In order to be able to call a close() > method you have to keep an explicit reference to the object in question. > This usually requires many lines of source code where previously only > one line was needed: > > func(constructor("foo").method()) > has to be recoded as > try: > ref = constructor("foo") > func(ref.method()) > finally: > ref.close() > if constructor happens to keep external resources. This is a factor of > five (in LOC) of code bloat and is absolutely unacceptable. Only if you expect that func() may fail *and* that there may be an outer try/except that keeps the program alive for much longer. Normally it becomes the totally acceptable ref = constructor("foo") func(ref.method()) ref.close() I would recommend the try/finally version only if func() is *expected* to fail for some I/O related reason. And in much Python code (e.g. most scripts and throw-away programming) even the one-liner is totally acceptable. > If this kind of coding is required to make existing Python apps running > reliable under 'JPython', then this will render 'JPython' (and any other > Python implementation without proper reliable reclaiming) pretty useless > for me. (and may be to other members of the Python community) This sounds like a bit of an exaggeration to me. The fact of the matter is that we can't guarantee this, and in fact there are lots of gotcha's with expecting this behavior (e.g. when you catch an exception while a file object is local, the exception handling may easily keep it alive longer than expected. It's also very easy to forget other references to the object. Listen, I'm sorry for causing your worldview on this point to collapse, but it's no big deal, okay?! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Sun Jul 30 17:52:31 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 10:52:31 -0500 Subject: [Python-Dev] Howto docs In-Reply-To: Your message of "Fri, 28 Jul 2000 10:21:32 -0400." <20000728102132.A29083@kronos.cnri.reston.va.us> References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> <14721.37704.872570.141761@cj42289-a.reston1.va.home.com> <20000728102132.A29083@kronos.cnri.reston.va.us> Message-ID: <200007301552.KAA12837@cj20424-a.reston1.va.home.com> > On the other hand, the documentation maintainers might be a different > set of people from code maintainers, and we might not want them > checking in code changes, so having the docs as a completely separate > project would allow finer control of this. On the third hand, we do > have the python-checkins list to keep an eye on what's happening. > > I'd vote for nondist/doc/howto. Short term, definitely. Long term, I feel that making it a separate SF project might be a good idea. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Sun Jul 30 18:39:57 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 11:39:57 -0500 Subject: [Python-Dev] buglet in unary ops on classes. In-Reply-To: Your message of "Fri, 28 Jul 2000 18:45:12 +0200." <20000728184512.D266@xs4all.nl> References: <20000728184512.D266@xs4all.nl> Message-ID: <200007301639.LAA16514@cj20424-a.reston1.va.home.com> > While poking around looking for something else, I found this little buglet: > > >>> class X: > ... def __getattr__(self, val): > ... print "getattr:", val > ... raise AttributeError > > >>> x = X() > >>> ~x > getattr: __invert__ > Traceback (most recent call last): > File "", line 1, in ? > File "", line 4, in __getattr__ > AttributeError > > The unary ops all do this (raising AttributeError), but the binary ops do > not: > > >>> x+1 > getattr: __coerce__ > getattr: __add__ > Traceback (most recent call last): > File "", line 1, in ? > TypeError: __add__ nor __radd__ defined for these operands > > Shouldn't this translation be done for unary ops as well ? Is it safe to > assume that instance_getattr() only returns NULL if the attribute is not > found ? PyInstance_DoBinOp() takes this assumption wrt. PyObject_GetAttr(), > and I don't really see a problem with it. In general, I'm against changing exceptions. There are situations conceivable where an AttributeError from a custom __getattr__ is caused by a bug in that __getattr__ or in something it calls, and it's important not to destroy the traceback in that case. The TypeError for a binary operator violates this principle. This is because the coercion process has to try several things that may fail with an AttributeError. Saving the tracebacks is just too much work. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From pf at artcom-gmbh.de Sun Jul 30 17:55:39 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Sun, 30 Jul 2000 17:55:39 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: <200007301542.KAA12794@cj20424-a.reston1.va.home.com> from Guido van Rossum at "Jul 30, 2000 10:42:49 am" Message-ID: Hi, Guido van Rossum: > > IMO one of the major strenghts of Python (in its reference implementation > > C-Python) has today compared to other languages (Java) is this particular > > behaviour. > > ["this behavior": closing files as soon as they go out of scope] > > > The argument made in the last sentence of the paragraph cited from > > the reference manual is bogus: In order to be able to call a close() > > method you have to keep an explicit reference to the object in question. > > This usually requires many lines of source code where previously only > > one line was needed: > > > > func(constructor("foo").method()) > > has to be recoded as > > try: > > ref = constructor("foo") > > func(ref.method()) > > finally: > > ref.close() > > if constructor happens to keep external resources. This is a factor of > > five (in LOC) of code bloat and is absolutely unacceptable. > > Only if you expect that func() may fail *and* that there may be an > outer try/except that keeps the program alive for much longer. In a GUI this is usually the case: For example Pmw contains such a default handler, which catches all otherwise uncaught exceptions and prevents the application from bombing. > Normally it becomes the totally acceptable > > ref = constructor("foo") > func(ref.method()) > ref.close() Sigh. This is still a factor of three. But LOCs are not my major point: An application programmer has to know, whether the object in question uses external resources or not, or he has to use the inconvinient 'close()' or 'destroy()' anyway, if he want's to make sure. [...] > And in much Python code (e.g. most scripts and throw-away programming) > even the one-liner is totally acceptable. Only if the "constructor().method()" idiom is not contained in a loop. Ancient Unix systems allowed only 20 files open at the same time. Although this has been increased to 120 or so in the mean time, you will easily ran out of file descriptors with the simple throw-away script posted in my first rant in this thread: >>> import os, rfc822 >>> posters = {} >>> for arti in os.listdir('/var/spool/news/comp/lang/python'): ... poster = rfc822.Message(open(arti)).get("From") ... posters[poster] = posters.get(poster, 0) + 1 ... >>> for poster, howoften in posters.items(): ... print poster, "posted", howoften, "times to clp." ... I believe scripts like this one are very common in the industry, since this idioms were advertised by several books (I still have to look up Martin v.Loewis "Das Pythonbuch", but IRC it contained subsection comparing Pythons garbage collection with Java GC and advertised the advantages of ref count GC) > > If this kind of coding is required to make existing Python apps running > > reliable under 'JPython', then this will render 'JPython' (and any other > > Python implementation without proper reliable reclaiming) pretty useless > > for me. (and may be to other members of the Python community) > > This sounds like a bit of an exaggeration to me. May be. Since Tkinter has been ported to JPython, I theoretically could give this platform at least a try. But now I know in advance, where I've to expect serious problems. I believe a lot of my GUI code based on Tkinter/Pmw makes use of this behaviour which simply works as advertised by Mark Lutz (and possibly others). [...] > Listen, I'm sorry for causing your worldview on this point to > collapse, but it's no big deal, okay?! If it is only *my* worldview: sure. But their might be others, who have learned Python 3 or 4 years ago. May be by using C-Python, may be by using Mark Lutz book "Programming Python". Since C-Python is available on all major platforms and the implementation in fact guarantees this behaviour (Pheeew!), this is indeed no big deal. No need to use 'JPython'. ;-) Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From mwh21 at cam.ac.uk Sun Jul 30 18:14:51 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 30 Jul 2000 17:14:51 +0100 Subject: [Python-Dev] extended slicing for lists In-Reply-To: Ka-Ping Yee's message of "Sat, 29 Jul 2000 16:22:50 -0700 (PDT)" References: Message-ID: Ka-Ping Yee writes: > Hey, wait a second. To get l[start:end:step], you start with 'start' > and keep adding 'step' until you get to -- but not including -- 'end', > right? So l[len(l)-1:-1:-1] should return the entire list reversed, > not the empty list. Yes, but "-1" also means the last element of the list, so >>> range(10)[3:-1:2] [3, 5, 7] If you want "to the end" behaviour, use None (or nothing): >>> range(10)[5::-2] [5, 3, 1] >>> range(10)[5:None:-2] [5, 3, 1] (these two are indistinguishable) Also, can I plead my case in that this was not my decision - it's the logic implemented by PySlice_GetIndices. > range() demonstrates the behaviour nicely: > > >>> size = 5 > >>> range(size-1,-1,-1) > [4, 3, 2, 1, 0] > > Wouldn't l[sys.maxint:0:-1] return all but the first element of l in > reverse order? Yes. > >>> range(size-1,0,-1) > [4, 3, 2, 1] > > Note that we should deprecate the use of sys.maxint (preferring None) > in this situation, since if the step is less than -1, the elements > you get ought to depend on the value of sys.maxint % step. I'd expect: > > >>> l = [0, 1, 2, 3, 4, 5] > >>> l[5:0:-3] > [5, 2] > >>> l[6:0:-3] > [4, 1] > >>> l[7:0:-3] > [3, 0] > >>> l[8:0:-3] > [5, 2] Whereas at the moment you get: >>> l[5:0:-3] [5, 2] >>> l[6:0:-3] Traceback (most recent call last): File "", line 1, in ? TypeError: slice indices must be integers >>> l[7:0:-3] Traceback (most recent call last): File "", line 1, in ? TypeError: slice indices must be integers >>> l[8:0:-3] Traceback (most recent call last): File "", line 1, in ? TypeError: slice indices must be integers (which is definitely screwy). Perhaps I shouldn't use PySlice_GetIndices (but then if I don't use it for this patch, what on earth would you use it for?). At any rate PySlice_GetIndices needs mending to accept longs (in the style of PyObject_GetItem). > hence > > >>> l[sys.maxint:0:-3] > [???, ???] # depends on sys.maxint % 3 > > My guiding principle is that the indices should always match what > you get from range(), and if start or end are missing, you get the > items you would have gotten if you extend the sequence out forever. Aside from the interpretation of negative indices, I basically agree. Cheers, M. -- languages shape the way we think, or don't. -- Erik Naggum, comp.lang.lisp From guido at beopen.com Sun Jul 30 19:20:07 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 12:20:07 -0500 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: Your message of "Fri, 28 Jul 2000 18:07:21 +0200." <3981AFB9.26AEB1D1@lemburg.com> References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <20000728112646.A15634@thyrsus.com> <3981AFB9.26AEB1D1@lemburg.com> Message-ID: <200007301720.MAA17682@cj20424-a.reston1.va.home.com> > Separating out LOAD_FAST from the switch shows a nice effect. > SET_LINENO is removed by -OO anyway, so there's really no > use in optimizing this one. I tried this and found about three percent speed increase on pystone, for what that's worth. This is with python -OO on Linux x86. Note that removing the (now redundant) case from the switch seemed to make a small difference too. Alas, I have no time to play with optimizing the main loop in a more rigorous way... :-( Here's the patch I came up with: Index: ceval.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/ceval.c,v retrieving revision 2.187 diff -c -r2.187 ceval.c *** ceval.c 2000/07/25 12:56:38 2.187 --- ceval.c 2000/07/30 16:13:23 *************** *** 608,616 **** f->f_lasti = INSTR_OFFSET(); #endif opcode = NEXTOP(); ! if (HAS_ARG(opcode)) oparg = NEXTARG(); #ifdef DYNAMIC_EXECUTION_PROFILE #ifdef DXPAIRS dxpairs[lastopcode][opcode]++; --- 608,631 ---- f->f_lasti = INSTR_OFFSET(); #endif + get_opcode: opcode = NEXTOP(); ! if (HAS_ARG(opcode)) { oparg = NEXTARG(); + if (opcode == LOAD_FAST) { + x = GETLOCAL(oparg); + if (x != NULL) { + Py_INCREF(x); + PUSH(x); + goto get_opcode; + } + PyErr_SetObject(PyExc_UnboundLocalError, + PyTuple_GetItem(co->co_varnames, + oparg)); + goto on_error; + } + } + #ifdef DYNAMIC_EXECUTION_PROFILE #ifdef DXPAIRS dxpairs[lastopcode][opcode]++; *************** *** 1282,1300 **** } Py_INCREF(x); PUSH(x); - break; - - case LOAD_FAST: - x = GETLOCAL(oparg); - if (x == NULL) { - PyErr_SetObject(PyExc_UnboundLocalError, - PyTuple_GetItem(co->co_varnames, - oparg)); - break; - } - Py_INCREF(x); - PUSH(x); - if (x != NULL) continue; break; case STORE_FAST: --- 1297,1302 ---- From jeremy at beopen.com Sun Jul 30 18:30:18 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Sun, 30 Jul 2000 12:30:18 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <200007301530.KAA12747@cj20424-a.reston1.va.home.com> References: <14719.49496.935765.730596@anthem.concentric.net> <20000727075058.A25450@keymaster.enme.ucalgary.ca> <200007271455.JAA20686@cj20424-a.reston1.va.home.com> <14720.19413.201297.246838@bitdiddle.concentric.net> <200007271616.LAA27700@cj20424-a.reston1.va.home.com> <14720.22377.745878.821529@bitdiddle.concentric.net> <200007271746.MAA29479@cj20424-a.reston1.va.home.com> <14720.27358.569557.671132@bitdiddle.concentric.net> <200007301530.KAA12747@cj20424-a.reston1.va.home.com> Message-ID: <14724.22554.818853.722906@bitdiddle.concentric.net> This message duplicates some of my previous messages about the thread/fork deadlock. (Received report that some of my earlier messages appear to be lost.) I'm running a simpler version of Neil's test program that uses the thread module instead of the threading module. It's attached at the end of the message (test_fork2.py). It spawns five threads; then each thread, including the main thread, go into a while 1: loop that forks. The program locks up after about 100-200 forks. The process structure looks like this: > ps --forest PID TTY TIME CMD 684 pts/0 00:00:00 bash 783 pts/0 00:00:00 python 784 pts/0 00:00:00 \_ python 785 pts/0 00:00:00 | \_ python 786 pts/0 00:00:00 | \_ python 951 pts/0 00:00:00 | | \_ python 787 pts/0 00:00:05 | \_ python 788 pts/0 00:00:04 | \_ python 953 pts/0 00:00:00 | | \_ python 789 pts/0 00:00:00 | \_ python 952 pts/0 00:00:00 | \_ python 950 pts/0 00:00:00 \_ python 964 pts/0 00:00:00 ps top reports the following CPU activity: PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 787 jeremy 19 0 2048 2048 1940 R 0 52.8 0.7 0:06 python 788 jeremy 17 0 2048 2048 1940 R 0 44.2 0.7 0:06 python If I attached to process 787 with gdb, this is the stack trace I can see: #0 pthread_cond_wait (cond=0x80f297c, mutex=0x80f2988) at queue.h:25 #1 0x806fee3 in PyThread_acquire_lock (lock=0x80f2978, waitflag=1) at ../../Python/thread_pthread.h:311 #2 0x8054ec1 in PyEval_RestoreThread (tstate=0x80fb2f0) at ../../Python/ceval.c:171 #3 0x80c1242 in posix_wait (self=0x0, args=0x80f1cac) at ../../Modules/posixmodule.c:2849 #4 0x8059b83 in call_builtin (func=0x8103578, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2369 #5 0x8059a41 in PyEval_CallObjectWithKeywords (func=0x8103578, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2337 #6 0x80583b1 in eval_code2 (co=0x8144ec0, globals=0x80f25d4, locals=0x0, args=0x80f1cb8, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ../../Python/ceval.c:1675 #7 0x805a01d in call_function (func=0x8144cdc, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2491 #8 0x8059a21 in PyEval_CallObjectWithKeywords (func=0x8144cdc, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2335 #9 0x80b03aa in t_bootstrap (boot_raw=0x8142ad8) at ../../Modules/threadmodule.c:193 #10 0x4001ceca in pthread_start_thread (arg=0xbf3ffe60) at manager.c:213 After I collect the stack trace and restart the program, several other processes start running again: PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 786 jeremy 14 0 2048 2048 1928 R 0 24.6 0.7 0:09 python 788 jeremy 15 0 2048 2048 1928 R 0 24.6 0.7 0:34 python 787 jeremy 17 0 2048 2048 1928 R 0 24.4 0.7 0:34 python 783 jeremy 15 0 2048 2048 1928 R 0 23.8 0.7 0:09 python If I run the process again with thread debugging enabled (Py_DEBUG defined at compiel time and THREADDEBUG set to 1), I get the following trace: PyThread_init_thread called PyThread_allocate_lock() -> 0x80f2010 PyThread_acquire_lock(0x80f2010, 1) called PyThread_acquire_lock(0x80f2010, 1) -> 1 PyThread_release_lock(0x80f2010) called PyThread_allocate_lock called PyThread_allocate_lock() -> 0x80f6c58 PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 Adding parser accelerators ... Done. PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_allocate_lock called PyThread_allocate_lock() -> 0x80f6498 PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_start_new_thread called [lots of stuff omitted] 2051 2127 PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 1024 2130 PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_release_lock(0x80f6498) called [blocks] In this case, the deadlock occurs much more quickly. (Perhaps the extra I/O produced by the debugging output exacerbates the problem.) Jeremy PS If you don't have access to a Linux machine, you can use one of the Linux test machines on the SF compile farm. Log into linux.compile.sourceforge.net. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test_fork2.py URL: From guido at beopen.com Sun Jul 30 19:29:58 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 12:29:58 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 22:05:08 +0200." <20000727220508.C224@xs4all.nl> References: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> <20000727182248.V266@xs4all.nl> <200007271730.MAA21788@cj20424-a.reston1.va.home.com> <20000727220508.C224@xs4all.nl> Message-ID: <200007301729.MAA17698@cj20424-a.reston1.va.home.com> > Yes. So what we're talking about is a better way to do indexing all > together, all types in one shot. ('indexes', 'slices' and 'collections' ? > I'm not sure how to name the first and the last one, if not that.) And not > just indexing, but setting and deleting at the same time, right ? Yes. > So the most preferred way is to pass a single argument which is either: > > - A single object (directly what was passed in) for a single index. > - A slice-object if any kind of single-slice was passed in, which holds the > zero-to-three objects that the slice was 'created' with. > - A tuple of zero or more of either of the above two. (Make that a tuple of two or more!) Indexing like a[] is illegal, and indexing like a[i] passes a non-tuple. > While I'm writing this down, I'm not sure if it's such a good idea. Isn't > this placing a tad too much into one function ? It might require some severe > logic to support this all, especially if you give 'special' meanings to some > indexes. And we're inserting a new catch-all method -- a set of them, > actually: get, set and del -- and that while Paul is trying to solve the > other catch-all Python has, __getattr__/__setattr__. Actually, __getitem__ *already* has to deal with -- the only case it doesn't get currently is the step-less single slice, which gets passed to __getslice__ -- and dies if it's not there. > And lets not forget the convenience of writing those methods: __getitem__ is > intuitive, both in name and semantics. So is __getslice__. The passing of a > slice object to __getitem__ is a tad less intuitive, and a tuple of > index/slice objects even less. Don't worry, that's already the case. > I'm tempted to suggest a single change: when __getslice__ is not defined, > pass a slice object (with no step, as if the slice had a trailing ':') to > __getitem__, and document it properly. Great! That's *exactly* what I've been proposing. > (and make builtin objects accept > sliceobjects too !) That gets a +1 from me too, in general (there's some doubt about the usefulness of things like ``L1[lo:ho:step] = L2''). > Perhaps try to slowly deprecate getslice__. Yes. > Give plenty > __of examples of using __getitem__ and slice objects > in the standard documentation. Sure. > Also, I think it makes sense to make slice > objects indexable, so that you can do: > > start, end, step = sliceobj > > instead of the less intuitive > > start, end, step = sliceobj.start, sliceobj.end, sliceobj.step > > But I've never used slice objects myself, so I can't really say whether it's > a good idea. Maybe that's a good idea. > I suspect this is all for 2.1 or later, though. Actually, the actual change (fall back on __*item__ with a slice object when __*slice__ doesn't exist) should be simple to add for 2.0. Just submit to the SF PM! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From thomas at xs4all.net Sun Jul 30 19:09:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 30 Jul 2000 19:09:41 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007301729.MAA17698@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Sun, Jul 30, 2000 at 12:29:58PM -0500 References: <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> <20000727182248.V266@xs4all.nl> <200007271730.MAA21788@cj20424-a.reston1.va.home.com> <20000727220508.C224@xs4all.nl> <200007301729.MAA17698@cj20424-a.reston1.va.home.com> Message-ID: <20000730190941.P13365@xs4all.nl> On Sun, Jul 30, 2000 at 12:29:58PM -0500, Guido van Rossum wrote: > > So the most preferred way is to pass a single argument which is either: > > > > - A single object (directly what was passed in) for a single index. > > - A slice-object if any kind of single-slice was passed in, which holds the > > zero-to-three objects that the slice was 'created' with. > > - A tuple of zero or more of either of the above two. > (Make that a tuple of two or more!) Indexing like a[] is illegal, and > indexing like a[i] passes a non-tuple. No sir: >>> class X: ... def __getitem__(self, val): ... return val ... >>> x = X() >>> x[()] () >>> x[1,] (1,) > > While I'm writing this down, I'm not sure if it's such a good idea. Isn't > > this placing a tad too much into one function ? It might require some severe > > logic to support this all, especially if you give 'special' meanings to some > > indexes. And we're inserting a new catch-all method -- a set of them, > > actually: get, set and del -- and that while Paul is trying to solve the > > other catch-all Python has, __getattr__/__setattr__. > Actually, __getitem__ *already* has to deal with -- the only case it > doesn't get currently is the step-less single slice, which gets passed > to __getslice__ -- and dies if it's not there. It should, but it doesn't, in most cases. God knows the code I wrote that had getitem and getslice didn't take slice objects into account, mostly because I didn't know how they worked ! Not to mention slice-tuples, which I didn't know were possible until you mentioned it ;) > > And lets not forget the convenience of writing those methods: __getitem__ is > > intuitive, both in name and semantics. So is __getslice__. The passing of a > > slice object to __getitem__ is a tad less intuitive, and a tuple of > > index/slice objects even less. > Don't worry, that's already the case. I know, I was arguing for an improvement, here :) > > I'm tempted to suggest a single change: when __getslice__ is not defined, > > pass a slice object (with no step, as if the slice had a trailing ':') to > > __getitem__, and document it properly. > > Great! That's *exactly* what I've been proposing. [snip more approvals] > > I suspect this is all for 2.1 or later, though. > Actually, the actual change (fall back on __*item__ with a slice > object when __*slice__ doesn't exist) should be simple to add for > 2.0. Just submit to the SF PM! That's what I thought. I'll see about that inbetween augmented assignment (which is not easy to do right, in retrospect. I almost uploaded a patch that evaluated 'x' in 'x += 1' twice ;) unless someone beats me to it, of course. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Sun Jul 30 20:19:53 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 30 Jul 2000 21:19:53 +0300 (IDT) Subject: [Python-Dev] Should repr() of string should observe locale? In-Reply-To: Message-ID: On Sun, 30 Jul 2000, Tim Peters identified loads of problems with Python, some of which I wish to address: > A principled solution appeared to require a combination of (at least) making > the P in the REPL loop hookable Oh yes. I think I want to PEP on this one. Barry, that's two numbers you owe me. still-commited-to-dumping-work-on-barry-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From tim_one at email.msn.com Sun Jul 30 20:55:09 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 14:55:09 -0400 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Message-ID: [Peter Funk] > ... > Only if the "constructor().method()" idiom is not contained in > a loop. Ancient Unix systems allowed only 20 files open at the > same time. Although this has been increased to 120 or so in > the mean time, you will easily ran out of file descriptors with > the simple throw-away script posted in my first rant in this > thread: > ... > I believe scripts like this one are very common in the industry, > since this idioms were advertised by several books (I still have > to look up Martin v.Loewis "Das Pythonbuch", but IRC it contained > subsection comparing Pythons garbage collection with Java GC and > advertised the advantages of ref count GC) You don't have to dig that deep: they're also common in the standard distribution, including at least two of mine (checkappend.py and tabnanny.py). There's a long copy/paste/modify tradition of not bothering to close file objects in multi-file tools, dating back at least to Guido's 1991 eptags.py . These aren't hard to "fix", but that isn't the point. A lot of code out there would start failing in data- and platform-dependent ways if CPython stopped cleaning up dead file objects "real soon" after they die, and there's no easy way to identify in advance which code that may be. It would piss off a lot of people! But I don't know why we're arguing about it. Nobody (AFAIK) has announced plans to take refcounting out of CPython, but that you can't *rely* on refcounting across Python implementations is ancient news (and a reality in practice since JPython). Guido certainly can't *require* that all implementations use refcounting! The Reference Manual has been clear about this for years, and other implementations already rely on what they were promised there: it's already too late to stop this from being a basis on which implementations will compete. as-if-microsoft-had-the-resources-to-take-on-beopen-anyway-ly y'rs - tim From Vladimir.Marangozov at inrialpes.fr Sun Jul 30 23:45:19 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sun, 30 Jul 2000 23:45:19 +0200 (CEST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007301720.MAA17682@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 30, 2000 12:20:07 PM Message-ID: <200007302145.XAA26775@python.inrialpes.fr> Guido van Rossum wrote: > > > Separating out LOAD_FAST from the switch shows a nice effect. > > SET_LINENO is removed by -OO anyway, so there's really no > > use in optimizing this one. > > I tried this and found about three percent speed increase on pystone, > for what that's worth. This is with python -OO on Linux x86. Note > that removing the (now redundant) case from the switch seemed to make > a small difference too. > > [patch deleted] Some speedup confirmed on my Linux PIII too. But you saved a round-trip around the ticker test. If this is acceptable, then let's do it for the opcodes involving only stack operations (probably not the JUMPs) _and_ which do not contain DECREFs which may trigger an external call. Here's the picture on my machine (I get the same picture with -OO): cvs - the original ceval.c in CVS load_fast - ceval.c with your patch top5 - ceval.c with my patch at SF moving 5 opcodes to the top top5-loadfast - my patch and your patch ~/python/dev>./python-cvs Lib/test/pystone.py Pystone(1.1) time for 120000 passes = 19.85 This machine benchmarks at 6045.34 pystones/second ~/python/dev>./python-load_fast Lib/test/pystone.py Pystone(1.1) time for 120000 passes = 19.61 This machine benchmarks at 6119.33 pystones/second ~/python/dev>./python-top5 Lib/test/pystone.py Pystone(1.1) time for 120000 passes = 18.87 This machine benchmarks at 6359.3 pystones/second ~/python/dev>./python-top5-load_fast Lib/test/pystone.py Pystone(1.1) time for 120000 passes = 19.08 This machine benchmarks at 6289.31 pystones/second Which shows, among others, that important cache effects are still here, bacause "python-top5-load_fast" is slower than "python-top5" alone... no-more-time-for-it-from-me-either'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From pf at artcom-gmbh.de Mon Jul 31 00:31:59 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Mon, 31 Jul 2000 00:31:59 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: from Tim Peters at "Jul 30, 2000 2:55: 9 pm" Message-ID: Hi, Tim Peters: > > [about Class().method()-idiom] [...] > You don't have to dig that deep: they're also common in the standard > distribution, including at least two of mine (checkappend.py and > tabnanny.py). There's a long copy/paste/modify tradition of not bothering > to close file objects in multi-file tools, dating back at least to Guido's > 1991 eptags.py . > > These aren't hard to "fix", but that isn't the point. A lot of code out > there would start failing in data- and platform-dependent ways if CPython > stopped cleaning up dead file objects "real soon" after they die, and > there's no easy way to identify in advance which code that may be. It would > piss off a lot of people! Thank you! Pheew. This applies in particular not only to file descriptors. This hits other limited resources also: color table entries, windows, network connections and so on. > But I don't know why we're arguing about it. Nobody (AFAIK) has announced > plans to take refcounting out of CPython, but that you can't *rely* on > refcounting across Python implementations is ancient news (and a reality in > practice since JPython). This topic was initially raised in the recent discussion about weak references which had a completely different subject line: "Product iteration". Mark Hammond wrote in this thread: MH> I have no problem with this at all. The sooner we point out the broken MH> code the better. The last thing we want is for obviously and documented MH> broken code to suddenly be considered non-broken simply by the volume of MH> poor code out there... Here I would say : "too late!" The volume of code is already there and from my POV this code simply doesn't look broken. I think it is but elegant, because it is usually shorter and was easier to write, because the programmer hasn't to bother too much about any external resources, which may have been used by some temp objects under the hood. > Guido certainly can't *require* that all implementations use refcounting! Okay. But this is "(for language lawyers)" anyway ;-). Anybody who want's to develop a seriously competing Python implementation is well advised to implement a similar "real soon" object recycling strategy regardless of what the Language Reference may tell them and what Guido "require". The existing code requires it. The current reliable automatic recycling behaviour in C-Python is so very very convenient, that I wouldn't want to do without it in practice. This is like having to use the staircase to go upstairs to the 10th floor in a building if there is an elevator with an open door just beside the first step. > The Reference Manual has been clear about this for years, and other > implementations already rely on what they were promised there: it's already > too late to stop this from being a basis on which implementations will > compete. Competing Python implementations? Hmmm.... Hmmm.... there is "stackless" but AFAIK it also uses refcounting... . ;-) Happy with C-Python, Peter From mhammond at skippinet.com.au Mon Jul 31 00:38:34 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 31 Jul 2000 08:38:34 +1000 Subject: [Python-Dev] checkins and regression tests In-Reply-To: <39843387.9F35D544@per.dem.csiro.au> Message-ID: > It'd be nice if the newly checked-in test were run through the test > framework before being checked in - the latest test_mmap.py fails due to > the "inconsistent tab-space" problem... That would be my fault. Thomas has already fixed it - thanks! However, Im a little confused by the error you saw. It certainly tested OK for me on both Linux and Windows, both when I checked it in, and as soon as I saw your message (but before updaing CVS). It also looks like it should have worked - a tab was used where 8 spaces should have been. I do find it a little ironic that Pythonwin has a number of features to detect this exact problem - but I didnt use Pythonwin to edit that :-( Oh well, all's well that ends well :-) Mark. From tim_one at email.msn.com Mon Jul 31 00:41:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 18:41:42 -0400 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007302145.XAA26775@python.inrialpes.fr> Message-ID: [Vladimir Marangozov] > ... > Which shows, among others, that important cache effects are > still here, bacause "python-top5-load_fast" is slower than > "python-top5" alone... I would rather call them "second-order effects" (SOE), as we can actually have no idea what causes them without a whale of a lot of work. They *could* be unfortunate accidents in the data or instruction caches, or *could* be that rearranging the code caused the compiler to spill a variable to memory that would have been better off in a register, or *could* be that the compiler optimizer runs out of steam in a different place than before and so generates sub-optimal code in any number of other respects, or *could* be that the sequence of jumps just happened to change in a way that causes one to get mis-predicted by the HW, or causes the HW prediction cache to flush at a bad moment, or etc etc etc. A gloss: almost all interesting optimizations a compiler performs, from register assignment to instruction scheduling, take exponential time to optimize "for real". No compiler can afford that much time (although there are some platform-specific "superoptimizers" out there that you can run for days over small pieces of code), so in practice compilers string together a long chain of fast but more-or-less fragile heuristic approaches, or even resort to general "mystery schemes" (like simulated annealing). Predicting what pops out the other end generally can't be done easier than by running the optimizer and *seeing* what pops out! So tiny changes can have wonderfully unexpected effects, and in general you cannot out-think them in advance. And as CPU HW has gotten ever-more complex, SOE has spread to cover a much larger territory than it used to (note that Intel doesn't even pretend to document the actual P3 timing rules anymore -- they've gotten too complicated to explain! compilers only work from an *approximation* to HW truth now). That said, there's good cross-platform reason to believe that Vladimir's "top 5" rearrangement is a helpful change, and more helpful than sucking out one popular opcode. It also has less potential to trigger harmful SOE, because it doesn't change the basic-block structure of the code (optimizers crawl over a graph of the basic blocks, and changes to the *topology* of the graph can cause heuristics to "get stuck" in new & exciting places <0.9 wink>; this is important in ceval because the loop is soooooo big -- optimizers are likely to fall into a state of unstable equilibrium when chewing over this much code). +1 on top5 because it's an easy change that's likely to help and unlikely to hurt. -0 on peeing away more time on micro-optimization right now. then-again-if-it's-the-only-way-guido-can-take-time-to-actually- work-on-python...-ly y'rs - tim From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 01:26:12 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 01:26:12 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <200007301402.JAA08591@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 30, 2000 09:02:38 AM Message-ID: <200007302326.BAA05861@python.inrialpes.fr> Guido van Rossum wrote: > > > Hasn't backward compatibility already been broken for 2.0? So why not > > break it a little more? > > Sure -- within reason. Ok folks. I've uploaded an updated patch on SF against CVS if you want to play with it. IDLE, at least, seems to be happy. I'm not sure whether something else relies on f.lineno and whether it is now broken because of the lack of lineno updates. (Note that you need to delete your .pyc files so that the compiler can regenerate the code without SET_LINENO; if SET_LINENO are in the code, you wouldn't see any difference...) -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one at email.msn.com Mon Jul 31 01:26:00 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 19:26:00 -0400 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Message-ID: Peter, what would you say if someone told you your Python programs would run, oh, 30% faster, but in return for that you could no longer rely on refcount semantics? What do you think *most* people would say? I don't know, but I'm certain I'd hear different answers from different people. Don't fall into the trap of believing that refcounting is a pure win! JPython and Vyper and the MS runtime aren't doing "real gc" just because they want to irritate people . There are tradeoffs here, and new Python code is probably more interesting to MS than old Python code. I personally don't think you'd find this a big deal if you had *always* needed to do explicit .close()-like calls in Python, and most programmers (across the world and across languages) have never used a language in which they *didn't* need to do explicit closes. Python has plenty of other attractions for them. MS may very well be delighted to leave the legacy Python market to BeOpen <0.9 wink>. remind-me-to-call-uncle-bill-in-the-morning-ly y'rs - tim From tim_one at email.msn.com Mon Jul 31 01:46:12 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 19:46:12 -0400 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <20000730080718.A22903@newcnri.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > ... > It always seemed odd to me that the current line number is > always kept up to date, even though 99.999% of the time, no > one will care. Why not just keep a small table that holds > the offset in the bytecode at which each line starts, and > look it up when it's needed? As Guido said, we already do -- indeed, that's how Python manages to produce line numbers in tracebacks under -O mode (which inhibits generation of SET_LINENO opcodes). Your next job is to think about how, e.g., you can set a breakpoint on a specific line of code in the debugger. Take a quick peek at the implementation of SET_LINENO in ceval.c, and you'll see that's where the trace hook is implemented. No SET_LINENO, no trace callback. That's what Vladimir has been trying to solve: the trick is arranging to pay something at runtime for it only when you're actually using it. debuggers-always-need-dirty-tricks-ly y'rs - tim From nhodgson at bigpond.net.au Mon Jul 31 01:50:34 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Mon, 31 Jul 2000 09:50:34 +1000 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) References: Message-ID: <015d01bffa80$f4bbced0$8119fea9@neil> > Don't fall into the trap of believing that refcounting is a pure win! > JPython and Vyper and the MS runtime aren't doing "real gc" just because > they want to irritate people . There are tradeoffs here, and new > Python code is probably more interesting to MS than old Python code. This aspect of GC is, however, irritating some C++ programmers who are an important MS customer group. This can be used to block C# and 'managed' C++ inside .NET with the argument "C# is /less/ safe because it is harder to ensure clean up so you'll leak resources". The base problem is that the only resource GC knows about is memory. There should be a way of attaching other resources such as file handles and data base connections to a similar mechanism. Neil From greg at cosc.canterbury.ac.nz Mon Jul 31 02:05:00 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Mon, 31 Jul 2000 12:05:00 +1200 (NZST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007281134.NAA05764@python.inrialpes.fr> Message-ID: <200007310005.MAA10150@s454.cosc.canterbury.ac.nz> > Yes, and we won't be able to conclude anything. This is micro-optimization > which doesn't give meaningful results. That's why I said "if what you say is true", i.e. if the claimed slowdown from the extra argument decoding step actually exists. There are two possibilities: (1) It really does slow down the execution of all bytescodes. In that case, move it into the handler code for the relevant bytecodes, where it won't affect the speed of anything else. (2) Otherwise, leave it where it is. Either way, I don't see any justification to reject the idea of having 2-arg opcodes because of speed, which is what the original post seemed to be saying. Or maybe I misunderstood. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 02:25:08 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 02:25:08 +0200 (CEST) Subject: 2-arg opcodes (was Re: [Python-Dev] PEP 203 Augmented Assignment) In-Reply-To: <200007310005.MAA10150@s454.cosc.canterbury.ac.nz> from "Greg Ewing" at Jul 31, 2000 12:05:00 PM Message-ID: <200007310025.CAA10819@python.inrialpes.fr> Greg Ewing wrote: > > Either way, I don't see any justification to reject the idea of > having 2-arg opcodes because of speed, which is what the > original post seemed to be saying. Or maybe I misunderstood. The latter. I was objecting to Guido's suggestion to time it and see... I'm not opposed to the idea, although it is likely to slow things down. But assuming we don't talk about performance, I don't see a reason for not thinking about a generalized scheme with variable-size arguments, (cf. classical CPU instruction sets) that is, instructions which operate on 1-, 2- or 4-byte arguments. if-you-wanna-fix-it-do-it-like-a-man-'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From greg at cosc.canterbury.ac.nz Mon Jul 31 02:25:55 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Mon, 31 Jul 2000 12:25:55 +1200 (NZST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007281547.RAA06456@python.inrialpes.fr> Message-ID: <200007310025.MAA10154@s454.cosc.canterbury.ac.nz> > Imagine what will happen if SET_LINENO disappears But this is > very tricky business which is more complicated than it looks like... Can someone summarise what the issues are with SET_LINENO? I had the impression that they're not needed for finding the line numbers in tracebacks. So what would we lose if they disappeared? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From mhammond at skippinet.com.au Mon Jul 31 03:45:01 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 31 Jul 2000 11:45:01 +1000 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007310025.MAA10154@s454.cosc.canterbury.ac.nz> Message-ID: > Can someone summarise what the issues are with SET_LINENO? > I had the impression that they're not needed for finding the > line numbers in tracebacks. So what would we lose if they > disappeared? The debugger (and quite possibly the profiler - I havent checked!) As Tim said only a few hours ago: --- Your next job is to think about how, e.g., you can set a breakpoint on a specific line of code in the debugger. Take a quick peek at the implementation of SET_LINENO in ceval.c, and you'll see that's where the trace hook is implemented. No SET_LINENO, no trace callback. That's what Vladimir has been trying to solve: the trick is arranging to pay something at runtime for it only when you're actually using it. debuggers-always-need-dirty-tricks-ly y'rs - tim --- Mark. From gvwilson at nevex.com Mon Jul 31 04:11:09 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Sun, 30 Jul 2000 22:11:09 -0400 (EDT) Subject: [Python-Dev] re-ordering op-codes / DDJ Message-ID: Hi, folks. Given how popular byte code interpreters are these days, I think "Doctor Dobb's Journal" would be very interested in an article if work is done on re-ordering/re-organizing the Python VM to improve performance. Interested parties please mail me directly... Thanks, Greg From greg at cosc.canterbury.ac.nz Mon Jul 31 04:18:26 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Mon, 31 Jul 2000 14:18:26 +1200 (NZST) Subject: Ditching SET_LINENO (RE: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment)) In-Reply-To: Message-ID: <200007310218.OAA10165@s454.cosc.canterbury.ac.nz> > the trick is arranging to pay something > at runtime for it only when you're actually using it. When tracing is in effect, switch to another copy of ceval2() which contains extra code to do whatever grubby things are needed to detect the start of a line using the line starts table. (Search it before executing each opcode, expand it into a parallel array of flags, or whatever.) The two versions of ceval2() could be generated from the same source file with some #defines. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 04:34:08 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 04:34:08 +0200 (CEST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: from "Mark Hammond" at Jul 31, 2000 11:45:01 AM Message-ID: <200007310234.EAA11379@python.inrialpes.fr> Mark Hammond wrote: > > > Can someone summarise what the issues are with SET_LINENO? > > I had the impression that they're not needed for finding the > > line numbers in tracebacks. So what would we lose if they > > disappeared? > > The debugger (and quite possibly the profiler - I havent checked!) Addendum: the debugger in its current state. And the whole point of the solution we were thinking of is to make sure that the debugger (and other objects, like tracebacks) do read the line number only when the main loop fires a "line" event via a hook. Given the state of the art, however, nobody can guarantee that the line number is not fetched in legacy code from the frame directly, through f.lineno (for whatever purpose). Note that we can trap the access to the f.lineno attribute in frameobject.c, but the problem boils down to computing the line number from the current instruction, i.e. from 'f.lasti', because the only thing we have at our disposal is a table (co_lnotab) which maps line number offsets and instruction offsets (through delta increments). Note that the f.lasti attr is not updated as it should in the main loop, because it would infer a lot of overhead (to be up to date, it needs to be updated for every opcode). It is updated only for 'important' events: a trace hook, an exception, a Python function call. So, at the heart of the difficulty here is the fact that we can't figure out precisely where we are in the opcode stream, if we ask that from Python (because the program counter is not stored anywhere regularly). We need to get notified by the main loop. And whenever you ask 'f.lineno' from Python, well, you're asking this information from the Python side (without notification from the C side). Do you follow me up to this point? :-) Now, with SET_LINENO, we are sure that f.lineno is always up to date, because its purpose is to update f.lineno (on one hand) *and* to fire a "line" event from the main loop if a hook is in place. The compiler makes sure to insert SET_LINENO opcodes for each new source line (this is why, BTW, you can end up with 10 SET_LINENO in a row if you have 10 doc strings in a row that describe some Python function). Without SET_LINENO, we have to deal with these two problems: firing "line" events whenever a tracing function is set and updating f.lineno. We can manage to fire a "line" event (through the scheme I've explained previously, or similar), but we still can't (well, I don't see a reliable way so far) update f.lineno permanently. that's-all-'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 04:42:10 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 04:42:10 +0200 (CEST) Subject: Ditching SET_LINENO (RE: [Python-Dev] Reordering opcodes (PEP 203 In-Reply-To: <200007310218.OAA10165@s454.cosc.canterbury.ac.nz> from "Greg Ewing" at Jul 31, 2000 02:18:26 PM Message-ID: <200007310242.EAA11409@python.inrialpes.fr> Greg Ewing wrote: > > > the trick is arranging to pay something > > at runtime for it only when you're actually using it. > > When tracing is in effect, switch to another copy of ceval2() > which contains extra code to do whatever grubby things are > needed to detect the start of a line using the line > starts table. (Search it before executing each opcode, > expand it into a parallel array of flags, or whatever.) > > The two versions of ceval2() could be generated from the same > source file with some #defines. Huh? See my Addendum: to Mark's message that I just posted, which explains the whole story in detail. I forgot to change the subject line which still reads "Opcode reordering". Ah wait... from the archives: http://www.python.org/pipermail/python-dev/2000-July/014395.html If you think your suggestion still holds, then could you elaborate a bit more? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 05:35:49 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 05:35:49 +0200 (CEST) Subject: [Python-Dev] SET_LINENO = f.lineno + ticker + ... = ? In-Reply-To: <200007310242.EAA11409@python.inrialpes.fr> from "Vladimir Marangozov" at Jul 31, 2000 04:42:10 AM Message-ID: <200007310335.FAA11459@python.inrialpes.fr> [me, on explaining the deal with SET_LINENO] > > See my Addendum: to Mark's message that I just posted, which explains > the whole story in detail. I forgot to change the subject line which > still reads "Opcode reordering". Ah wait... from the archives: > > http://www.python.org/pipermail/python-dev/2000-July/014395.html > Which makes me think about the tstate->ticker. This is the only variable updated for every opcode. If we can manage to involve the ticker in the computation of f.lineno, having f.lasti and interp->checkinterval and whatever variables are logged somewhere, we're about to win. But it's likely to be messy, because thread states and frames would be involved. If this is possible, we'll trap f.lineno's access in frameobject.c and through this magic formula we could get an updated f.lineno on every Python request. Could someone think of a "magic formula" to compute the PC (the index of the current opcode), which is enough for computing f.lineno with PyCode_Addr2Line()? Guido? Tim? Anyone? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one at email.msn.com Mon Jul 31 06:23:56 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 31 Jul 2000 00:23:56 -0400 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007310234.EAA11379@python.inrialpes.fr> Message-ID: [Vladimir Marangozov] > ... > And the whole point of the solution we were thinking of is to > make sure that the debugger (and other objects, like > tracebacks) do read the line number only when the main loop > fires a "line" event via a hook. > > Given the state of the art, however, nobody can guarantee that > the line number is not fetched in legacy code from the frame > directly, through f.lineno (for whatever purpose). I really don't think we care about that. Guido, do we ? f_lineno is conceptually an internal implementation detail of frame objects, and Guido has often warned that if you access the internals you're on your own (I don't think even Michael's bytecodehacks cares about this one ). So long as all uses of f_lineno in the std distribution can be faked, I think it's fine to just get rid of that member. WRT your later msg, strongly doubt tstate->ticker will help: it's an integer in range(tstate->interp->checkinterval + 1), and wraps around over & over. Besides, the modular base (checkinterval) can be changed by the user at any time. tstate->ticker is thus but the circular shadow of a legion of ghosts. It isn't worth all these brain cells just to preserve an internal detail! OK, it would be worth it if it were easy -- but it's not. From thomas at xs4all.net Mon Jul 31 06:48:49 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 31 Jul 2000 06:48:49 +0200 Subject: [Python-Dev] checkins and regression tests In-Reply-To: ; from mhammond@skippinet.com.au on Mon, Jul 31, 2000 at 08:38:34AM +1000 References: <39843387.9F35D544@per.dem.csiro.au> Message-ID: <20000731064849.J266@xs4all.nl> On Mon, Jul 31, 2000 at 08:38:34AM +1000, Mark Hammond wrote: > > It'd be nice if the newly checked-in test were run through the test > > framework before being checked in - the latest test_mmap.py fails due to > > the "inconsistent tab-space" problem... > That would be my fault. Thomas has already fixed it - thanks! My shadow is still trying to catch up :) > However, Im a little confused by the error you saw. It certainly tested OK > for me on both Linux and Windows, both when I checked it in, and as soon as > I saw your message (but before updaing CVS). It also looks like it should > have worked - a tab was used where 8 spaces should have been. 'make test' runs 'python -tt' on the test scripts, at least on systems using Makefile. And '-tt' means you can't mix spaces and tabs even if you use 8-space tabstops. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Mon Jul 31 06:57:41 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 31 Jul 2000 07:57:41 +0300 (IDT) Subject: [Python-Dev] RE: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Message-ID: On Sun, 30 Jul 2000, Tim Peters wrote: > But I don't know why we're arguing about it. Nobody (AFAIK) has announced > plans to take refcounting out of CPython, but that you can't *rely* on > refcounting across Python implementations is ancient news (and a reality in > practice since JPython). Well, to bring this back to the original: I proposed a variant of lexical scoping where an inner function has only a weak reference to its surroundin environment, so that def f(x): def g(): return x return g f(1)() Would fail with "UnboundOuterVariable", but the more commonly used def f(x): return map(lambda i,x=x: i*x, range(10)) Would turn into def f(x): return map(lambda i: i*x, range(10)) And work. Guido seemed to want to simulate classes by closures , and I tried to convince him that a) Python has a perfectly good class mechanism <3000 wink> b) non-weak references would cause cycles, which would mean that the currently working code: def f(file): file = open(file) def g(x): print x g(file.read()) Would fail is called in a loop if GC is not called too often. lexical-scoping-is-too-powerful-for-its-own-good-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 07:54:08 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 07:54:08 +0200 (CEST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: from "Tim Peters" at Jul 31, 2000 12:23:56 AM Message-ID: <200007310554.HAA11702@python.inrialpes.fr> Tim Peters wrote: > > [Vladimir Marangozov] > > ... > > And the whole point of the solution we were thinking of is to > > make sure that the debugger (and other objects, like > > tracebacks) do read the line number only when the main loop > > fires a "line" event via a hook. > > > > Given the state of the art, however, nobody can guarantee that > > the line number is not fetched in legacy code from the frame > > directly, through f.lineno (for whatever purpose). > > I really don't think we care about that. Guido, do we ? > > f_lineno is conceptually an internal implementation detail of frame objects, > and Guido has often warned that if you access the internals you're on your > own (I don't think even Michael's bytecodehacks cares about this one > ). So long as all uses of f_lineno in the std distribution can be > faked, I think it's fine to just get rid of that member. > > WRT your later msg, strongly doubt tstate->ticker will help: it's an > integer in range(tstate->interp->checkinterval + 1), and wraps around over & > over. Besides, the modular base (checkinterval) can be changed by the user > at any time. tstate->ticker is thus but the circular shadow of a legion of > ghosts. > > It isn't worth all these brain cells just to preserve an internal detail! It is! > OK, it would be worth it if it were easy -- but it's not. It is! I think I found the solution :-) Whenever f.f_lineno is accessed, the compiler generates a LOAD_ATTR relative to f. Therefore, updating f->f_lasti = INSTR_OFFSET() in LOAD_ATTR + trapping "lineno" access in frameobject.c with PyCode_Addr2Line(f->f_lasti) ensures that we'll always get the right line number. Of course, this makes the update of f->f_lasti for every LOAD_ATTR, but given the ranking of SET_LINENO compared to LOAD_ATTR in the DXP and MAL's frequency charts, I think this is a pure win! Et voila . I'll update my patch at SF later. now-back-to-work'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From ping at lfw.org Mon Jul 31 08:38:45 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sun, 30 Jul 2000 23:38:45 -0700 (PDT) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007310234.EAA11379@python.inrialpes.fr> Message-ID: Mark Hammond wrote: > > > Can someone summarise what the issues are with SET_LINENO? > > I had the impression that they're not needed for finding the > > line numbers in tracebacks. Yes, traceback info comes from c_lnotab and doesn't depend on SET_LINENO. Only tracing and f.lineno depend on SET_LINENO. > > So what would we lose if they disappeared? > > The debugger (and quite possibly the profiler - I havent checked!) I'm still a little puzzled on this one. The only way you can view a running Python program in the debugger is to have started it within the debugger, right? I don't think it's possible to attach a debugger to an already running program. Hence -- if you had to know beforehand that you were going to start the debugger anyway, then you clearly have the opportunity to say -g whenever you want to do debugging. It seems to me that any debugger (or IDLE et al.) can just start with #!/usr/bin/env python -g and we could then drop SET_LINENO by default. Am i missing something? On Mon, 31 Jul 2000, Vladimir Marangozov wrote: > Note that the f.lasti attr is not updated as it should in the main loop, > because it would infer a lot of overhead (to be up to date, it needs to > be updated for every opcode). It is updated only for 'important' events: > a trace hook, an exception, a Python function call. This is okay. The *only* time this is going to make any difference is when a function is trying to inspect the location of the PC within itself. (When the frame is being inspected from anywhere else, f.lasti will be up to date because it will have been set on function call.) I think we don't need to care so much about a function looking at its own f.lineno. Just use PyCode_Addr2Line on f.lasti whenever someone asks for f.lineno, and perhaps document the caveat for anyone weird enough to write navel-gazing functions. :) -- ?!ng From ping at lfw.org Mon Jul 31 08:47:59 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sun, 30 Jul 2000 23:47:59 -0700 (PDT) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: Message-ID: On Sat, 29 Jul 2000, Ken Manheimer wrote: > On Fri, 28 Jul 2000 Vladimir.Marangozov at inrialpes.fr wrote: > > 1) python - code without SET_LINENO > > 2) python -g - code for debugging, with SET_LINENO > > 3) python -O - code without doc-strings. [...] > I would be firmly -1 on this proposal. Funny -- i was just about to throw in a hearty +1. > I see the ability to debug at whim, even when you didn't expect having to > do so, as being a major win, part of the incremental development process. But you *can't* debug at whim, right? You have to have started the debugger, so it can hook sys.settrace, before you run your program. If you have to start the debugger anyway, then you can surely say -g. If you *didn't* start the debugger beforehand, the best you can get is a detailed traceback with function names and line numbers -- and you don't lose any of that when SET_LINENO goes away. Let's suppose: 1. -g is turned on by default in interactive mode, since we don't know if you're going to feel like tracing today. 2. Programs (like debuggers and IDEs) that know they're going to use sys.settrace, or which contain embedded interactive interpreters, begin with #!/usr/bin/env python -g 3. Other programs begin with the usual #!/usr/bin/env python Given this -- are there any debugging opportunities you're missing out on? I don't see any... -- ?!ng From MarkH at ActiveState.com Mon Jul 31 08:47:17 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Mon, 31 Jul 2000 16:47:17 +1000 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: Message-ID: > I'm still a little puzzled on this one. The only way you can view > a running Python program in the debugger is to have started it > within the debugger, right? Not really. > I don't think it's possible to attach > a debugger to an already running program. IDLE and Pythonwin are able to debug arbitary programs once they have started - and they are both written in Python. In addition, most debuggers have a technique for breaking into the debugger from code - ie, a hard break-point. pdb.set_trace() is how pdb does it. Pythonwin has one. IDLE either does, or will grow one. I can see a number of other problems: * You do not want to debug the IDE itself, just a tiny bit of code running under the IDE. Making the IDE take the full hit simply because it wants to run a debugger occasionally isnt fair. Also, people tend to start these IDEs once, and keep them running during a number of discrete tasks. Only a few of these tasks may involve firing up the debugger. Asking them to restart the IDE simply to enable the debugger would be a pain for the user. Worse, these IDEs are often started from a GUI, rather than from the command line. This would mean we need 2 (in Windows parlance) shortcuts - "IDLE" and "IDLE with debugging". The end result is that all IDEs will run with debugging enabled. * Python often is embedded, for example, in a Web Server, or used for CGI. It should be possible to debug these programs directly. It shouldnt be necessary to (eg) change the CGI settings so Python is invoked with a special flag whenever you want to use a debugger. It can be hard enought to setup CGI as it is, let alone trying to make it's behaviour depend on if a script needs to be debugged or not. * We should not force Python embedders to handle this themselves. For example, asking someone who embeds Python to support a command-line switch to enable debugging Python is a PITA. It may not even be possible. With Active Scripting, for example, the host may not know it is even using Python at all! It all seems to push the problem down to those who can least afford to manage it, and least equipped to understand how it needs to be tweaked for their particular situation. However, I could agree that the debugger itself trigger debuggable behaviour. I just dont believe this should be a startup-only switch. sys.set_debugging(1) would work for me. OTOH, a debugger always announces itself by calling sys.settrace(), so this is really all that is necessary (and debugging can be disabled whenever sys.settrace(None) is called, and no existing frames have their tracer set.) Mark. From pf at artcom-gmbh.de Mon Jul 31 09:43:55 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Mon, 31 Jul 2000 09:43:55 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: from Tim Peters at "Jul 30, 2000 7:26: 0 pm" Message-ID: Good morning Tim, Tim Peters: > Peter, what would you say if someone told you your Python programs would > run, oh, 30% faster, but in return for that you could no longer rely on > refcount semantics? Personally I wouldn't go for that trade. Waiting three or four more months and buying new hardware usually gives the same speedup anyway. What really matters is programmer time, not program run time. At least most of the time. When I started programming (with punch cards 25 yrs ago) the situation was clearly different. But today? Computing power is so incredible cheap today... > What do you think *most* people would say? [...] Hard to say. But I believe people looking at Python are more interested in programmer productivity than in highly optimized performance. And don't having to worry about tedious and clumsy cleanup actions is an undeniable win in programmer productivity. This win is twofold: 1. you don't have to check, whether the objects provide a close() or a destroy() method. 2. you don't have to invent silly names for these otherwise anonymous objects. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From nowonder at nowonder.de Mon Jul 31 12:07:46 2000 From: nowonder at nowonder.de (Peter Schneider-Kamp) Date: Mon, 31 Jul 2000 10:07:46 +0000 Subject: [Python-Dev] TCP socket timeout module? Message-ID: <39854FF2.EC017E60@nowonder.de> How hard would it be to implement a functionality like this in socketmodule.c? Is such a functionality desirable? guess-this-has-been-discussed-a-thousand-times-before-ly y'rs Peter -------- Original Message -------- Subject: [ANN] TCP socket timeout module --> timeoutsocket.py Date: Sun, 30 Jul 2000 20:54:23 -0400 From: "Timothy O'Malley" Organization: Posted via Supernews, http://www.supernews.com To: python-list at python.org Newsgroups: comp.lang.python Numerous times I have seen people request a solution for TCP socket timeouts in conjunction with urllib. Recently, I found myself in the same boat. I wrote a server that would connect to skytel.com and send automated pages. Periodically, the send thread in the server would hang for a long(!) time. Yup -- I was bit by a two hour timeout built into tcp sockets. Thus, I wrote timeoutsocket.py With timeoutsocket.py, you can force *all* TCP sockets to have a timeout. And, this is all accomplished without interfering with the standard python library! Here's how to put a 20 second timeout on all TCP sockets for urllib: import timeoutsock import urllib timeoutsocket.setDefaultSocketTimeout(20) Just like that, any TCP connection made by urllib will have a 20 second timeout. If a connect(), read(), or write() blocks for more than 20 seconds, then a socket.Timeout error will be raised. Want to see how to use this in ftplib? import ftplib import timeoutsocket timeoutsocket.setDefaultSocketTimeout(20) Wasn't that easy! The timeoutsocket.py module acts as a shim on top of the standard socket module. Whenever a TCP socket is requested, an instance of TimeoutSocket is returned. This wrapper class adds timeout support to the standard TCP socket. Where can you get this marvel of modern engineering? http://www.timo-tasi.org/python/timeoutsocket.py And it will very soon be found on the Vaults of Parnassus. Good Luck! -- -- happy daze -tim O -- http://www.python.org/mailman/listinfo/python-list From mal at lemburg.com Mon Jul 31 10:13:46 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 10:13:46 +0200 Subject: [Python-Dev] SET_LINENO and python options References: <200007300239.EAA21825@python.inrialpes.fr> Message-ID: <3985353A.A8E0406C@lemburg.com> [Vladimir on removing SET_LINENO opcodes per default] Is there any reason why we can't just use traceback.tb_lineno() + maybe an equivalent C function instead of adding useless opcodes into the byte code stream ? The line number information is already stored in the co_lnotab table, so SET_LINENO is redundant in some respects. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 31 10:19:01 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 10:19:01 +0200 Subject: [Python-Dev] SPAM from "The Western Web Newsletter" References: <20000731020103.2B91B1CD4C@dinsdale.python.org> Message-ID: <39853675.96EA5731@lemburg.com> Could someone please add a filter to the Mailman lists to prevent these horse back advocates ?! Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Stefan.Debler at bitways.de Mon Jul 31 10:30:53 2000 From: Stefan.Debler at bitways.de (S.Debler (Bitways)) Date: Mon, 31 Jul 2000 10:30:53 +0200 Subject: [Python-Dev] Urgent inquiry for Paper bags! Message-ID: <200007310830.KAA04569@mcqueen.wolfsburg.de> Urgent inquiry for Paper bags, Dear Sirs, We are an international trading company, mainly serving the European industry. The Bitways Group purchases globally on own account and then resells the products to various clients. Our aim is to source globally and to offer our clients the best prices worldwide. From tim_one at email.msn.com Mon Jul 31 10:42:50 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 31 Jul 2000 04:42:50 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <14724.22554.818853.722906@bitdiddle.concentric.net> Message-ID: [Jeremy Hylton, with an excellent writeup of what he's found out about his test_fork2.py test] It's a baffler! AFAIK, nobody yet has thought of a way that a fork can screw up the state of the locks in the *parent* process (it must be easy to see how they can get screwed up in a child, because two of us already did ). But your hangs appear to be in parents, as the gdb stacktrace shows that a parent process is (presumably) hanging while trying to reacquire the global lock in the expansion of the Py_END_ALLOW_THREADS macro right after the pid = wait(&status); in posix_wait returns (#2 is from the macro expansion): #0 pthread_cond_wait (cond=0x80f297c, mutex=0x80f2988) at queue.h:25 #1 0x806fee3 in PyThread_acquire_lock (lock=0x80f2978, waitflag=1) at ../../Python/thread_pthread.h:311 #2 0x8054ec1 in PyEval_RestoreThread (tstate=0x80fb2f0) at ../../Python/ceval.c:171 #3 0x80c1242 in posix_wait (self=0x0, args=0x80f1cac) at ../../Modules/posixmodule.c:2849 However, the stacktrace shows that the parent in question is executing pthread_cond_wait, and this is the worst implementation of pthread_cond_wait in existence if it's using a busy loop to wait for the condition variable to get signaled! If this process keeps accumulating cycles, it either *is* the worst implementation in existence, or the process isn't actually hung and you just happened to capture the stack at a misleading time. The debug output may be misleading too: > ... > [lots of stuff omitted] Ouch -- wish you hadn't. Debug output is likely to come out-of-order, so without *all* of it we can't see exactly how far out of balance the acquire and release calls got. > 2051 2127 > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_release_lock(0x80f6498) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > PyThread_release_lock(0x80f6498) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > PyThread_release_lock(0x80f6498) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > 1024 2130 > PyThread_release_lock(0x80f6498) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > PyThread_release_lock(0x80f6498) called > [blocks] It's probably *not* blocking on the release: In this bunch of output, there are 7 calls to acquire, 5 calls to release, and 5 returns from acquire. That the # of release calls == the # of acquire returns suggests this output is "good enough", and if so that leaves two acquire calls waiting forever. Don't know what to do now. Obvious suggestions include putting many prints into test_fork2 so we get a better idea of what's happening, or going back to Trent's print-filled variant of test_fork1 (which I still think is an easier one to study, as it forks only once instead of unboundedly often). BTW, in *my* day, the answer to the question "what happens to a threaded program at a fork?" was to walk away laughing -- and not sure the reality of that has actually changed, regardless of how many more words they may have added to the pthreads docs in the meantime <0.7 wink>. silly-humans-ly y'rs - tim From mal at lemburg.com Mon Jul 31 10:48:51 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 10:48:51 +0200 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <14721.64041.139313.716754@anthem.concentric.net> Message-ID: <39853D73.ACBB54CA@lemburg.com> "Barry A. Warsaw" wrote: > > >>>>> "M" == M writes: > > M> These stats were created using an instrumented Python > M> interpreter running real applications (and recording all > M> executed opcodes to a file), so they can be considered close > M> enough to what Python typically does in its inner loop. > > M> If you need help, I can dig up those old tools and patches... > > If you can update them for the current CVS, I'd suggest uploading them > to SF. I'd then be willing to run Mailman for a while on an > instrumented Python to see what it does. I'll see what I can do... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 31 11:12:48 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 11:12:48 +0200 Subject: [Python-Dev] os.kill() on Win32 ? (Fork on Win32) References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> <20000728101015.A6542@ActiveState.com> <3981CD20.BD53BFF0@lemburg.com> <008d01bff8c2$5c99f240$f2a6b5d4@hagrid> Message-ID: <39854310.4944366@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > BTW, (pardon my ignorance) what is the most portable way to > > do the equivalent of a os.system("cmd &") as native OS > > API call ? [On Unix, "cmd &" starts a new process which runs > > in the background and detached from the calling process.] > > > > I've looked at .execve and .spawnve, but they both replace > > the current process. > > on windows, spawn(P_NOWAIT) does what you want. here's > an example from the eff-bot guide: > > # > # os-spawn-example-2.py > > import os > import string > > def run(program, *args, **kw): > # find executable > mode = kw.get("mode", os.P_WAIT) > for path in string.split(os.environ["PATH"], os.pathsep): > file = os.path.join(path, program) + ".exe" > try: > return os.spawnv(mode, file, (file,) + args) > except os.error: > pass > raise os.error, "cannot find executable" > > run("python", "hello.py", mode=os.P_NOWAIT) Cool, so os.spawnve(os.P_NOWAIT, ...) looks like a portable alternative to os.fork() for the case where you do not rely on the parent process resources being available in the child process. Next, I'll have to find out how to kill a process given its process ID under Windows... wouldn't it be possible to write an emulation of os.kill() for Win32 platforms too ? (there's a SysInfo tool for Windows which says that OpenProcess(PROCESS_TERMINATE, FALSE, pid); will do the trick -- not sure if that works as expected though). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 31 11:16:56 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 11:16:56 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <398065f3.6724599@smtp.worldonline.dk> <398099F1.B6B1D281@lemburg.com> <39811268.1131747@smtp.worldonline.dk> <200007281226.HAA04140@cj20424-a.reston1.va.home.com> Message-ID: <39854408.5D496075@lemburg.com> Guido van Rossum wrote: > > > Predicting the future can be difficult, but here is my take: > > javasoft will never change the way String.compareTo works. > > String.compareTo is documented as: > > """ > > Compares two strings lexicographically. The comparison is based on > > the Unicode value of each character in the strings. ... > > """ > > (Noting that their definition of "character" is probably "a 16-bit > value of type char", and has only fleeting resemblance to what is or > is not defined as a character by the Unicode standard.) > > > Instead they will mark it as a very naive string comparison and suggest > > users to use the Collator classes for anything but the simplest cases. > > Without having digested the entire discussion, this sounds like a good > solution for Python too. The "==" operator should compare strings > based on a simple-minded representation-oriented definition, and all > the other stuff gets pushed into separate methods or classes. This would probably be the best way to go: we'll need collation routines sooner or later anyway. Bill's "true UCS-4" compare could then become part of that lib. Should I #if 0 the current implementation of the UCS-4 compare in CVS ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From MarkH at ActiveState.com Mon Jul 31 11:47:14 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Mon, 31 Jul 2000 19:47:14 +1000 Subject: [Python-Dev] os.kill() on Win32 ? (Fork on Win32) In-Reply-To: <39854310.4944366@lemburg.com> Message-ID: > Next, I'll have to find out how to kill a process given > its process ID under Windows... wouldn't it be possible to hprocess = OpenProcess( accessFlags, bInherit, pid ); TerminateProcess(hprocess, exitCode); The hard bit on Win32 is finding the PID when you only have the process name (for example) but it sounds like you dont have that specific problem... Mark. From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 12:16:17 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 12:16:17 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <3985353A.A8E0406C@lemburg.com> from "M.-A. Lemburg" at Jul 31, 2000 10:13:46 AM Message-ID: <200007311016.MAA12484@python.inrialpes.fr> M.-A. Lemburg wrote: > > [Vladimir on removing SET_LINENO opcodes per default] > > Is there any reason why we can't just use traceback.tb_lineno() > + maybe an equivalent C function instead of adding useless opcodes > into the byte code stream ? > Yes - you seem to have missed half the story . How would you generate callbacks (fire "line" events) from within the mainloop when a sys.settrace function is set and the PC starts executing opcodes corresponding to a new line number? Note that we don't "add" any new opcodes, and in the scheme I presented CALL_TRACE is also internal to eval_code2(), like the copy of co_code, but I eventually decided to show it in opcodes.h. SET_LINENO is not generated anymore and is reduced to a NOOP in ceval, CALL_TRACE is introduced only for the callbacks. For b/w compatibility (of .pyc files) I think we can't just "get rid" of it. And now that the game is over with finding the solution to f.f_lineno's access, the proposal about "python -g" which preserves SET_LINENO makes sense (at least for visualizing SET_LINENO in a disassembly). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Mon Jul 31 12:21:09 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 12:21:09 +0200 Subject: [Python-Dev] os.kill() on Win32 ? (Fork on Win32) References: Message-ID: <39855315.4E14C432@lemburg.com> Mark Hammond wrote: > > > Next, I'll have to find out how to kill a process given > > its process ID under Windows... wouldn't it be possible to > > hprocess = OpenProcess( accessFlags, bInherit, pid ); > TerminateProcess(hprocess, exitCode); Would it make sense to add something like this to posixmodule.c as emulation of the Unix kill() on Win32 ? Here's the manpage for reference: SYNOPSIS #include #include int kill(pid_t pid, int sig); DESCRIPTION The kill system call can be used to send any signal to any process group or process. If pid is positive, then signal sig is sent to pid. If pid equals 0, then sig is sent to every process in the process group of the current process. If pid equals -1, then sig is sent to every process except for the first one, from higher numbers in the process table to lower. If pid is less than -1, then sig is sent to every process in the process group -pid. If sig is 0, then no signal is sent, but error checking is still performed. RETURN VALUE On success, zero is returned. On error, -1 is returned, and errno is set appropriately. > The hard bit on Win32 is finding the PID when you only have the process > name (for example) but it sounds like you dont have that specific > problem... Not really, since my server manages its own set of processes and knows the different PIDs. It keeps track of what the processes currently do and terminates the ones that act in unexpected ways, e.g. due to programming errors. On Unix this results in a high availability bug tolerant server application which allows running user written code. My future goal would be porting it to Win2k, provided the needed APIs are available (or can be emulated in some way). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Mon Jul 31 12:35:36 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 31 Jul 2000 12:35:36 +0200 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <200007311016.MAA12484@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Mon, Jul 31, 2000 at 12:16:17PM +0200 References: <3985353A.A8E0406C@lemburg.com> <200007311016.MAA12484@python.inrialpes.fr> Message-ID: <20000731123536.K266@xs4all.nl> On Mon, Jul 31, 2000 at 12:16:17PM +0200, Vladimir Marangozov wrote: > SET_LINENO is not generated anymore and is reduced to a NOOP in ceval, > CALL_TRACE is introduced only for the callbacks. For b/w compatibility > (of .pyc files) I think we can't just "get rid" of it. Why not, except for the possible desirability of a -g flag that does use it? If you up the bytecode magic, which several other things in the pipeline are going to do anyway (augmented assignment, range literals, list comprehensions) old bytecode will be recompiled, and new bytecode will not be used on old interpreters. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Mon Jul 31 12:35:38 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 12:35:38 +0200 Subject: [Python-Dev] SET_LINENO and python options References: <200007311016.MAA12484@python.inrialpes.fr> Message-ID: <3985567A.2E4FDC79@lemburg.com> Vladimir Marangozov wrote: > > M.-A. Lemburg wrote: > > > > [Vladimir on removing SET_LINENO opcodes per default] > > > > Is there any reason why we can't just use traceback.tb_lineno() > > + maybe an equivalent C function instead of adding useless opcodes > > into the byte code stream ? > > > > Yes - you seem to have missed half the story . How would you > generate callbacks (fire "line" events) from within the mainloop > when a sys.settrace function is set and the PC starts executing > opcodes corresponding to a new line number? Good question :-) You're right: I forgot about the trace function call in the SET_LINENO opcode. > Note that we don't "add" any new opcodes, and in the scheme I presented > CALL_TRACE is also internal to eval_code2(), like the copy of co_code, > but I eventually decided to show it in opcodes.h. With "add" I meant the SET_LINENO opcode... remove the "useless" from my comment above ;-) > SET_LINENO is not generated anymore and is reduced to a NOOP in ceval, > CALL_TRACE is introduced only for the callbacks. For b/w compatibility > (of .pyc files) I think we can't just "get rid" of it. > > And now that the game is over with finding the solution to f.f_lineno's > access, the proposal about "python -g" which preserves SET_LINENO makes > sense (at least for visualizing SET_LINENO in a disassembly). BTW, we already have "python -d" which sets the debugging flag. You could simply use that flag for generating the SET_LINENO opcodes. Still, I think that the SET_LINENO issue is not really all that important: we have "python -O" which removes the opcodes. Perhaps moving the opcode a bit further down in the big switch would help CPU caches for production code (running under "python -O")... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pf at artcom-gmbh.de Mon Jul 31 12:45:53 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Mon, 31 Jul 2000 12:45:53 +0200 (MEST) Subject: doctest.py and testing frameworks (was Re: [Python-Dev] Fire, may I present accellerant. Accellerant, thi...) In-Reply-To: <20000730215059.OSQC24904.mail.rdc1.wa.home.com@finin> from Mitchell Morris at "Jul 30, 2000 2:51:30 pm" Message-ID: Hi, Mitchell Morris wrote to me: > Peter: > > Thanks for reading my post, and I especially appreciate your taking > the time and effort to respond. I also appreciate that you didn't take > me to task for using "it's" instead of "its" as the possessive form. > (I've been completely reeducated now, I assure you). As I'm not > currently a subscriber to python-dev, I don't know if this should > have been replied to the list or directly to you, so I'm sending it to > you only. If you feel it appropriate, please redistribute it as you > wish. [...I wrote to Mitchell:...] > > I've used doctest in my own code and found the idea to integrate > > test cases as sequences of calling code and expected result tuples > > as documentation (exmaples of use) into the doc string of modules, > > classes and methods very appealing. > > > > However this promising approach needs further work: Especially > > GUI parts can't be tested this way and in larger contexts, it > > is indeed very tedious to place *all* test code into doc strings. > > Often you need to prepare a defined starting point for the tests > > of several methods. It is not easy to decide, where to put this. > > I used doctest rather extensively a little while ago, but it was only > the vanilla variant originally posted by Tim. I thought it was really an > excellent work, but ran into similar stumbling blocks. The largest > issue for me was the aggregation of several modules worth of tests > into larger chunks, but I now know (from what I had to build to > complete the test plan I was working with) that I would very shortly > have run into the problems of replicating the test environment: > preparing input files/directories/databases, creating all the > supplementary bits and pieces, etc ad nauseam. > > A secondary issue which none of these tools address yet, but I feel > will be significant eventually, is the explicit naming of inter-test > dependence. If my class B tests require using some functionality > from class A, I would want the A tests to succeed before trying the > B tests at all (assuming I'm going to run both A and B in a single > iteration). I suspect, then, that one of these candidates will require > additional work to be our complete solution; I want to make sure > that I/we are working on the best candidate possible before > spending the effort. > > > > > again, additional effort could obviously provide the missing > > > functionality. On the other hand, doctest.py isn't currently > > > part of the standard distribution. > > > > Yes. :-( > > This, I feel, represents a significant problem. We should have a > testing framework as part of the core distribution. I agree. > We have HTML > tokenizing, mail sending, RFC822 parsing, /bin/sh-like lexing, etc > etc but don't feel that providing test support to our community of > developer is appropriate? Bizarre. Perhaps even more bizarre is > that there is a non-trivial regrtest.py that is part of the distribution, > but it's hidden away and not documented. Perhaps because no one volunteered to write documentation for it. Writing docs is an tedious task especially if you are no native english speaker. > I think we are not > providing all the service to the Python community that we could > and should. You are welcome to do something about this. > One of the strengths of Python, in my experience, has been the > ease with which code is written. This makes it much easier to > convince yourself and others to refactor mercilessly; the kinds of > cruft that grow on C++ solutions are rarely seen in Python code > because we can repartition and rewrite our work much more easily. > Providing a standard means to verify functionality before refactoring > makes it much safer to proceed, since we can "prove" (for a very > loose definition of "prove") that we haven't broken anything that > anybody else cares about. I think this is a direction we should > encourage, both through example and explicit > direction/documentation. > > > > I attach my version of 'doctest' to this email. Do what you want with it. > > Currently I favour 'doctest' over 'pyunit'. > > If you don't mind, could you elaborate why you prefer doctest, or at > least what you find unpleasant about pyunit? I would like to include > this in the document for future reference, and you may even > convince me to change my vote for doctest.py instead. I must admit that I didn't had a look at PyUnit since January. I've just downloaded pyunit-1.2.0 and had a closer look at it. Nevertheless it is very hard to beat the elegance of Tim Peters approach to cut'n'paste test cases from the interpreter prompt. Although you usually get 2 lines for each test case, building the test cases is much easier in the first place. May be both approaches to unit testing can be integrated somehow? Steal the concept of 'fixtures' from PyUnit and steal the idea to define simple test cases in the doc strings from 'doctest'. It shouldn't be that hard to add a semiautomatic import hierarchy traversal tool. Regards, Peter From gvwilson at nevex.com Mon Jul 31 14:54:58 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Mon, 31 Jul 2000 08:54:58 -0400 (EDT) Subject: [Python-Dev] Internet Groupware for Scientific Collaboration Message-ID: [Not strictly related to Python development, but likely to be of interest to many readers of this list.] Jon Udell (architect of www.byte.com and O'Reilly's new Safari site, author of "Practical Internet Groupware", a Python fan) has prepared a report for Software Carpentry called "Internet Groupware for Scientific Collaboration". It is on-line at: http://www.software-carpentry.com/Groupware/report.html Hope you enjoy it, Greg Wilson From fdrake at beopen.com Mon Jul 31 17:01:14 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 31 Jul 2000 11:01:14 -0400 (EDT) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: References: <200007310234.EAA11379@python.inrialpes.fr> Message-ID: <14725.38074.60946.579456@cj42289-a.reston1.va.home.com> Ka-Ping Yee writes: > (or IDLE et al.) can just start with > > #!/usr/bin/env python -g > > and we could then drop SET_LINENO by default. Am i missing something? This #! isn't portable; the program is only guaranteed to get one parameter from the #! line ("python" in this example). Some platforms are more forgiving and just use the rest of the command line (or a maximum of 32 characters), but that means you lose the "-g" on too many platforms. The other concerns that have been brought up are fairly important as well. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 17:37:16 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 17:37:16 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <3985567A.2E4FDC79@lemburg.com> from "M.-A. Lemburg" at Jul 31, 2000 12:35:38 PM Message-ID: <200007311537.RAA22542@python.inrialpes.fr> M.-A. Lemburg wrote: > > BTW, we already have "python -d" which sets the debugging > flag. You could simply use that flag for generating the SET_LINENO > opcodes. You're right. In case someone is not on the patches list and wants to test this, here's the log message of the latest patch update: Date: 2000-Jul-31 07:57 By: marangoz Comment: Another rewrite, making this whole strategy b/w compatible according to the 1st incompatibility point a) described in: http://www.python.org/pipermail/p ython-dev/2000-July/014364.html Changes: 1. f.f_lineno is computed and updated on f_lineno attribute requests for f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated on *all* attribute accesses (in LOAD_ATTR in the main loop). 2. The standard setup does not generate SET_LINENO, but uses co_lnotab for computing the source line number (e.g. tracebacks) This is equivalent to the actual "python -O". 3. With "python -d", we fall back to the current version of the interpreter (with SET_LINENO) thus making it easy to test whether this patch fully replaces SET_LINENO's behavior. (modulo f->f_lineno accesses from legacy C code, but this is insane). IMO, this version already worths the pain to be truly tested and improved. One improvement is to define a nicer public C API for breakpoints: - PyCode_SetBreakPointAtLine(line) - PyCode_SetBreakPointAtAddr(addr) or similar, which would install a CALL_TRACE opcode in the appropriate location of the copy of co_code. Another idea is to avoid duplicating the entire co_code just for storing the CALL_TRACE opcodes. We can store them in the original and keep a table of breakpoints. Setting the breakpoints would occur whenever the sys.settrace hook is set. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470 -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From jeremy at beopen.com Mon Jul 31 18:48:32 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 31 Jul 2000 12:48:32 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.15,1.16 In-Reply-To: <200007311638.JAA27412@slayer.i.sourceforge.net> References: <200007311638.JAA27412@slayer.i.sourceforge.net> Message-ID: <14725.44512.46379.190368@bitdiddle.concentric.net> Barry, A couple of suggestions on assigning PEP numbers: Let's require at least an abstract before we assign a number. We've got a bunch of PEPs that have been assigned and never touched; all they've got is a title and a name. If we have an abstract, non-experts and non-channelers have a better chance of figuring out what the PEP is. We might also think about a deadline or time limit. If a PEP has no activity for N days (90?), it is automatically changed to status deferred. After it has been deferred, we can assign it to a new author. There's not much point in making a big list of topics that people would like to write about some day if they get the time. It looks like we now have seven PEPs with only a name and title. Jeremy From bwarsaw at beopen.com Mon Jul 31 18:56:03 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 31 Jul 2000 12:56:03 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.15,1.16 References: <200007311638.JAA27412@slayer.i.sourceforge.net> <14725.44512.46379.190368@bitdiddle.concentric.net> Message-ID: <14725.44963.961828.923053@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> A couple of suggestions on assigning PEP numbers: JH> Let's require at least an abstract before we assign a number. JH> We've got a bunch of PEPs that have been assigned and never JH> touched; all they've got is a title and a name. If we have an JH> abstract, non-experts and non-channelers have a better chance JH> of figuring out what the PEP is. JH> We might also think about a deadline or time limit. If a PEP JH> has no activity for N days (90?), it is automatically changed JH> to status deferred. After it has been deferred, we can assign JH> it to a new author. JH> There's not much point in making a big list of topics that JH> people would like to write about some day if they get the JH> time. It looks like we now have seven PEPs with only a name JH> and title. Strongly agree, and will follow these guidelines in the future. Can you add these to PEP 1? -Barry From jeremy at beopen.com Mon Jul 31 19:31:36 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 31 Jul 2000 13:31:36 -0400 (EDT) Subject: [Python-Dev] SF bug tracker Message-ID: <14725.47096.914241.264282@bitdiddle.concentric.net> Which interface do you like better: the SourceForge bug tracker or Jitterbug? I am leaning towards moving the bug database from Jitterbug at python.org to SF. The advantages of moving to SF are: - bugs, patches, and CVS all managed by the same service - bugs can be assigned to specific people for resolution - cleaner interface for searching bugs - bugs can be assigned a priority The primary disadvantage of SF is email support. Jitterbug can receive comments about a bug via email and add them to its database. The SF bug tracker does not. It works like the patch manager, requiring you to use the Web interface to add more information. The SF bug tracker will send an email message every time a bug entry is updated, but that's it. Please let me know what you think. Jeremy From guido at beopen.com Mon Jul 31 20:43:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 31 Jul 2000 13:43:05 -0500 Subject: [Python-Dev] SF bug tracker In-Reply-To: Your message of "Mon, 31 Jul 2000 13:31:36 -0400." <14725.47096.914241.264282@bitdiddle.concentric.net> References: <14725.47096.914241.264282@bitdiddle.concentric.net> Message-ID: <200007311843.NAA22953@cj20424-a.reston1.va.home.com> > Which interface do you like better: the SourceForge bug tracker or > Jitterbug? I am leaning towards moving the bug database from > Jitterbug at python.org to SF. > > The advantages of moving to SF are: > > - bugs, patches, and CVS all managed by the same service > - bugs can be assigned to specific people for resolution > - cleaner interface for searching bugs > - bugs can be assigned a priority > > The primary disadvantage of SF is email support. Jitterbug can > receive comments about a bug via email and add them to its database. > The SF bug tracker does not. It works like the patch manager, > requiring you to use the Web interface to add more information. > > The SF bug tracker will send an email message every time a bug entry > is updated, but that's it. I would like to add that as far as I can tell we've only received a very small number of Jitterbug bug reports via email. In fact, the only one I can find in my email archives that originated via email was PR#110, which was in fact a followup! (We got plenty of followups via email, but that was because with Jitterbug it was actually *easier* to use email than the web I/F.) (Of course, this is not counting the bugs sent directly to guido at python.org -- these are in the hundreds.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From klm at digicool.com Mon Jul 31 20:47:09 2000 From: klm at digicool.com (Ken Manheimer) Date: Mon, 31 Jul 2000 14:47:09 -0400 (EDT) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: Message-ID: On Sun, 30 Jul 2000, Ka-Ping Yee wrote: > On Sat, 29 Jul 2000, Ken Manheimer wrote: > > On Fri, 28 Jul 2000 Vladimir.Marangozov at inrialpes.fr wrote: > > > 1) python - code without SET_LINENO > > > 2) python -g - code for debugging, with SET_LINENO > > > 3) python -O - code without doc-strings. > [...] > > I would be firmly -1 on this proposal. > > Funny -- i was just about to throw in a hearty +1. > > > I see the ability to debug at whim, even when you didn't expect having to > > do so, as being a major win, part of the incremental development process. > > But you *can't* debug at whim, right? You have to have started the > debugger, so it can hook sys.settrace, before you run your program. > If you have to start the debugger anyway, then you can surely say -g. Nope. More often than not, if i'm developing something substantial, then my interpreter sessions will involve developing context, running something then having it fail, doing a pdb.pm() post mortem, and then doing a second run with pdb.run(). My life would be worse if i happened to forget to start python with the '-g' in the first place. This scenario happens even when i don't intend to be "developing", ie when i encounter bugs in random code i'm using. As it stands, i (and anyone) have recourse to poke around at will. This is the kind of thing that makes an interpreted language valuable to me in the first place, and why i'm willing to trade of a lot more than a few percent performance. (This all may be moot if the linenotab-based alternative pans out - then everyone can be happy.) > Let's suppose: > > 1. -g is turned on by default in interactive mode, since we > don't know if you're going to feel like tracing today. This would address my above concerns. > 2. Programs (like debuggers and IDEs) that know they're going > to use sys.settrace, or which contain embedded interactive > interpreters, begin with > > #!/usr/bin/env python -g > > 3. Other programs begin with the usual > > #!/usr/bin/env python > > Given this -- are there any debugging opportunities you're missing > out on? I don't see any... One important one would be connecting with a long-running process, eg something running under medusa via the medusa monitor client. Unfortunately, it looks like the monitor client currently doesn't use a pty, or uses it wrong, or something, so the debugger doesn't work right anyway - which has been a royal pain on many occasions! I could see it being worthwhile to run the server process in an economy mode, if the economy were big. For some definition of big, of course.-) Ken klm at digicool.com From thomas at xs4all.net Mon Jul 31 21:07:25 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 31 Jul 2000 21:07:25 +0200 Subject: [Python-Dev] SF bug tracker In-Reply-To: <14725.47096.914241.264282@bitdiddle.concentric.net>; from jeremy@beopen.com on Mon, Jul 31, 2000 at 01:31:36PM -0400 References: <14725.47096.914241.264282@bitdiddle.concentric.net> Message-ID: <20000731210725.N266@xs4all.nl> On Mon, Jul 31, 2000 at 01:31:36PM -0400, Jeremy Hylton wrote: > Which interface do you like better: the SourceForge bug tracker or > Jitterbug? I am leaning towards moving the bug database from > Jitterbug at python.org to SF. Without having too much experience with Jitterbug, and only the 'read' side at that, and slightly more experience, also only on the 'read' side, with the SF buglist, I can safely say I prefer the SF bug tracker. Jitterbug is totally alien to me, the different catagories boggle me, the overviews of each catagory boggle me, and I'm not sure if I've seen everything even after I browsed through each list. But as said, I have only little experience with Jitterbug. The SF buglist might not make it too clear from the first overview in what catagory a bug belongs, but it's easily selectable, and it's very obvious which bugs are open and how important they are. And it gives people more feedback on sourceforge, in case they don't read their mail ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bckfnn at worldonline.dk Mon Jul 31 21:50:58 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Mon, 31 Jul 2000 19:50:58 GMT Subject: [Python-Dev] SF bug tracker In-Reply-To: <200007311843.NAA22953@cj20424-a.reston1.va.home.com> References: <14725.47096.914241.264282@bitdiddle.concentric.net> <200007311843.NAA22953@cj20424-a.reston1.va.home.com> Message-ID: <3985d87b.12451444@smtp.worldonline.dk> [Guido van Rossum] >I would like to add that as far as I can tell we've only received a >very small number of Jitterbug bug reports via email. In that case you did not include the counts from JPythons jitterbug. Almost everything I have submitted there is through email. But do not take that as an endorsements of jitterbug. If the existing data can be moved then I'm +1 on doing so. regards, finn From trentm at ActiveState.com Mon Jul 31 22:41:26 2000 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 31 Jul 2000 13:41:26 -0700 Subject: [Python-Dev] test turds? In-Reply-To: ; from moshez@math.huji.ac.il on Sat, Jul 29, 2000 at 01:17:14PM +0300 References: Message-ID: <20000731134126.A1683@ActiveState.com> On Sat, Jul 29, 2000 at 01:17:14PM +0300, Moshe Zadka wrote: > Hi! > > Recently I patched a bug in whichdb. Following Tim's advice "each bug we > find is a bug in the regression testing", I decided to write a test case > for whichdb. However, the problem is that I'm not sure where I can create > files, which must not be leftovers from the test suite. Does anyone know test_support.TESTFN is a test filename that is intended to be used by Python test scripts. Currently it is just the file '@test' in the current directory. A better mechanism might be to use the tempfile.mktemp() module and function. > of a test which creates files, and how it deals with them? [.../dist/src/Lib/test]$ grep -l 'open\b' test_*.py test_array.py test_b1.py test_b2.py test_binhex.py test_bsddb.py test_cd.py test_cpickle.py test_dbm.py test_dl.py test_exceptions.py test_fcntl.py test_gdbm.py test_gl.py test_linuxaudiodev.py test_mmap.py test_pkg.py test_popen2.py test_pty.py test_rgbimg.py test_select.py test_sunaudiodev.py test_tokenize.py test_winreg.py test_winreg2.py test_zipfile.py test_zlib.py Trent From jack at oratrix.nl Mon Jul 31 23:01:00 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 31 Jul 2000 23:01:00 +0200 Subject: [Python-Dev] test turds? In-Reply-To: Message by Trent Mick , Mon, 31 Jul 2000 13:41:26 -0700 , <20000731134126.A1683@ActiveState.com> Message-ID: <20000731210105.6F6ADE266F@oratrix.oratrix.nl> Recently, Trent Mick said: > test_support.TESTFN is a test filename that is intended to be used by Python > test scripts. Currently it is just the file '@test' in the current directory. > A better mechanism might be to use the tempfile.mktemp() module and function. test_dbm.py (and possibly a few others) use /tmp/delete_me. This leaves a nasty turd on the Mac if the test fails. (Nasty because a file called /tmp/delete_me in the Python home directory confuses the hell out of cvs:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From skip at mojam.com Mon Jul 31 23:54:59 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 31 Jul 2000 16:54:59 -0500 (CDT) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: References: Message-ID: <14725.62899.678602.179470@beluga.mojam.com> Tim> The most interesting dropped project "in the middle" was Skip Tim> Montanaro's Rattlesnake, which aimed to change the VM from a stack Tim> to a register model. 'e's not dead, just restin'... ;-) Skip From jack at oratrix.nl Mon Jul 31 23:59:34 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 31 Jul 2000 23:59:34 +0200 Subject: [Python-Dev] test_re fails with re==pre Message-ID: <20000731215940.28A11E266F@oratrix.oratrix.nl> Test_re now works fine if re is sre, but it still fails if re is pre. Is this an artifact of the test harness or is there still some sort of incompatibility lurking in there? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From guido at python.org Sat Jul 1 00:57:45 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 17:57:45 -0500 Subject: [Python-Dev] Idle breakage In-Reply-To: Your message of "Fri, 30 Jun 2000 23:24:06 +0200." <046a01bfe2d9$88302360$f2a6b5d4@hagrid> References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> Message-ID: <200006302257.RAA21104@cj20424-a.reston1.va.home.com> > when's the 2.0 deadline? In a couple of hours. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Sat Jul 1 01:02:50 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 18:02:50 -0500 Subject: [Python-Dev] Idle breakage In-Reply-To: Your message of "Fri, 30 Jun 2000 23:39:26 +0200." <049601bfe2db$acea1380$f2a6b5d4@hagrid> References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> Message-ID: <200006302302.SAA21232@cj20424-a.reston1.va.home.com> > confirmed. SRE implements $ exactly as described in > the library reference, RE doesn't ;-) All this is done to match what Perl does. :-( > patch coming within 30 minutes. Saw it. Thanks! But I still get warnings in IDLE: Failed to load extension 'ParenMatch' Traceback (most recent call last): File "../Tools/idle/EditorWindow.py", line 529, in load_standard_extensions self.load_extension(name) File "../Tools/idle/EditorWindow.py", line 539, in load_extension mod = __import__(name, globals(), locals(), []) File "/projects/python/develop/guido/src/Tools/idle/ParenMatch.py", line 15, in ? import PyParse File "/projects/python/develop/guido/src/Tools/idle/PyParse.py", line 14, in ? _synchre = re.compile(r""" File "./../Lib/sre.py", line 54, in compile return _compile(pattern, flags) File "./../Lib/sre.py", line 86, in _compile p = sre_compile.compile(pattern, flags) File "./../Lib/sre_compile.py", line 217, in compile _compile(code, p.data, flags) File "./../Lib/sre_compile.py", line 121, in _compile emit(ATCODES[AT_MULTILINE[av]]) KeyError: at_boundary --Guido van Rossum (home page: http://www.python.org/~guido/) From effbot at telia.com Sat Jul 1 00:14:49 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 00:14:49 +0200 Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> Message-ID: <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> guido wrote: > > confirmed. SRE implements $ exactly as described in > > the library reference, RE doesn't ;-) > > All this is done to match what Perl does. :-( guess we have to update the docs; I'll take care of that when I've recovered from all this... > emit(ATCODES[AT_MULTILINE[av]]) > KeyError: at_boundary sigh. with ~1000 patterns in my collection of test scripts, one could have hoped I'd seen it all. but that's a new one. patch coming within 30 minutes (when will I ever sleep?) From guido at python.org Sat Jul 1 01:10:30 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 18:10:30 -0500 Subject: [Python-Dev] Oops on AIX In-Reply-To: Your message of "Fri, 30 Jun 2000 19:52:15 +0200." <200006301752.TAA22474@python.inrialpes.fr> References: <200006301752.TAA22474@python.inrialpes.fr> Message-ID: <200006302310.SAA21344@cj20424-a.reston1.va.home.com> > After the CVS commit storm that occurred during the last 3 days, > I wanted to validate the current build on AIX. And I am stalled. > > I am not sure, but it seems like the errors I get relate with the > latest 64-bit support patches, and I don't dare to suggest corrections > in this area, so I welcome any help... let me suggest patches... If these work, please check them in: > xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c > "methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed. Index: methodobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/methodobject.c,v retrieving revision 2.28 diff -c -r2.28 methodobject.c *** methodobject.c 2000/06/30 15:01:00 2.28 --- methodobject.c 2000/06/30 22:09:55 *************** *** 180,186 **** if (x == -1) return -1; } ! y = _Py_HashPointer(a->m_ml->ml_meth); if (y == -1) return -1; x ^= y; --- 180,186 ---- if (x == -1) return -1; } ! y = _Py_HashPointer((void*)(a->m_ml->ml_meth)); if (y == -1) return -1; x ^= y; > xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c > "./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined. > "./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h. > make: 1254-004 The error code from the last command is 1. Index: posixmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v retrieving revision 2.138 diff -c -r2.138 posixmodule.c *** posixmodule.c 2000/06/29 21:12:41 2.138 --- posixmodule.c 2000/06/30 22:10:39 *************** *** 285,290 **** --- 285,291 ---- #endif /* choose the appropriate stat and fstat functions and return structs */ + #undef STAT #ifdef MS_WIN64 # define STAT _stati64 # define FSTAT _fstati64 --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Sat Jul 1 01:14:05 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 18:14:05 -0500 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: Your message of "Fri, 30 Jun 2000 11:43:14 MST." References: Message-ID: <200006302314.SAA21371@cj20424-a.reston1.va.home.com> > Not that I hope to override the heavy -1, but I don't agree with the second > point. It embodies a huge amount of knowledge that is needed to write > portable code. As such, IMO, it _does_ belong in the standard library. How > is it different in its nature from sys.platform, which is only a much weaker > version of the same concept? A more subtle way of stating my opinion could be: if we were to do something in the standard distribution about the problems that this is addressing, I think we would do it in a much more direct fashion, e.g. by making the appropriate enquiry functions directly accessible. --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw at beopen.com Sat Jul 1 00:15:34 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 18:15:34 -0400 (EDT) Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> Message-ID: <14685.7174.668568.445940@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> patch coming within 30 minutes (when will I ever sleep?) When WE say you can :) -Barry From DavidA at ActiveState.com Sat Jul 1 00:20:12 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 30 Jun 2000 15:20:12 -0700 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <200006302314.SAA21371@cj20424-a.reston1.va.home.com> Message-ID: > > Not that I hope to override the heavy -1, but I don't agree > with the second > > point. It embodies a huge amount of knowledge that is needed to write > > portable code. As such, IMO, it _does_ belong in the standard > library. How > > is it different in its nature from sys.platform, which is only > a much weaker > > version of the same concept? > > A more subtle way of stating my opinion could be: if we were to do > something in the standard distribution about the problems that this is > addressing, I think we would do it in a much more direct fashion, > e.g. by making the appropriate enquiry functions directly accessible. > > --Guido van Rossum (home page: http://www.python.org/~guido/) I much prefer that answer, as it leaves the door open to a patch. I don't care about the implementation, just the feature. Thanks. --david From effbot at telia.com Sat Jul 1 00:36:55 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 00:36:55 +0200 Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> Message-ID: <050501bfe2e3$b2517680$f2a6b5d4@hagrid> > > KeyError: at_boundary > > sigh. with ~1000 patterns in my collection of test scripts, > one could have hoped I'd seen it all. but that's a new one. umm. I'm not sure I want to check this one in. of all stupid bugs... I really gotta do something about that regression test suite. (don't worry, the patch is on its way. unfortunately, my setup is botched, so I cannot test drive IDLE myself. or to put it another way, I cannot guarantee that this is the last problem with IDLE+SRE...) From bwarsaw at beopen.com Sat Jul 1 00:37:20 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 18:37:20 -0400 (EDT) Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> <050501bfe2e3$b2517680$f2a6b5d4@hagrid> Message-ID: <14685.8480.389966.608982@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> (don't worry, the patch is on its way. unfortunately, my FL> setup is botched, so I cannot test drive IDLE myself. or FL> to put it another way, I cannot guarantee that this is the FL> last problem with IDLE+SRE...) Go ahead and check it in. I'll run idle and see wot hoppens. -B From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 00:46:37 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 00:46:37 +0200 (CEST) Subject: [Python-Dev] Oops on AIX In-Reply-To: <200006302310.SAA21344@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 30, 2000 06:10:30 PM Message-ID: <200006302246.AAA23519@python.inrialpes.fr> Guido van Rossum wrote: > > let me suggest patches... If these work, please check them in: Yes, they do, thanks! (I can't check them in) There's one error left, occuring at two locations in the signalmodule, but I think the solution would be to have an appropriate cast: "./signalmodule.c", line 359.49: 1506-280 (E) Function argument assignment between types "void*" and "void(*)(int)" is not allowed. "./signalmodule.c", line 363.48: 1506-280 (E) Function argument assignment between types "void*" and "void(*)(int)" is not allowed. > > > xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c > > "methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed. > > > Index: methodobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/methodobject.c,v > retrieving revision 2.28 > diff -c -r2.28 methodobject.c > *** methodobject.c 2000/06/30 15:01:00 2.28 > --- methodobject.c 2000/06/30 22:09:55 > *************** > *** 180,186 **** > if (x == -1) > return -1; > } > ! y = _Py_HashPointer(a->m_ml->ml_meth); > if (y == -1) > return -1; > x ^= y; > --- 180,186 ---- > if (x == -1) > return -1; > } > ! y = _Py_HashPointer((void*)(a->m_ml->ml_meth)); > if (y == -1) > return -1; > x ^= y; > > > > > xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c > > "./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined. > > "./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h. > > make: 1254-004 The error code from the last command is 1. > > Index: posixmodule.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v > retrieving revision 2.138 > diff -c -r2.138 posixmodule.c > *** posixmodule.c 2000/06/29 21:12:41 2.138 > --- posixmodule.c 2000/06/30 22:10:39 > *************** > *** 285,290 **** > --- 285,291 ---- > #endif > > /* choose the appropriate stat and fstat functions and return structs */ > + #undef STAT > #ifdef MS_WIN64 > # define STAT _stati64 > # define FSTAT _fstati64 > > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From fdrake at beopen.com Sat Jul 1 00:46:18 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 18:46:18 -0400 (EDT) Subject: [Python-Dev] Idle breakage In-Reply-To: <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> Message-ID: <14685.9018.355154.468866@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > guess we have to update the docs; I'll take care of that > when I've recovered from all this... The docs are frozen & published for this release, so next week is fine. ** THANKS! ** > patch coming within 30 minutes (when will I ever sleep?) You sleep??? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From effbot at telia.com Sat Jul 1 01:35:49 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 01:35:49 +0200 Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca><046a01bfe2d9$88302360$f2a6b5d4@hagrid><049601bfe2db$acea1380$f2a6b5d4@hagrid><200006302302.SAA21232@cj20424-a.reston1.va.home.com><04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid><050501bfe2e3$b2517680$f2a6b5d4@hagrid> <14685.8480.389966.608982@anthem.concentric.net> Message-ID: <056501bfe2ec$5876c080$f2a6b5d4@hagrid> barry wrote: > Go ahead and check it in. I'll run idle and see wot hoppens. well? can I go to sleep now? please? From guido at python.org Sat Jul 1 02:35:35 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 19:35:35 -0500 Subject: [Python-Dev] Idle breakage In-Reply-To: Your message of "Sat, 01 Jul 2000 01:35:49 +0200." <056501bfe2ec$5876c080$f2a6b5d4@hagrid> References: <20000630143148.A9725@acs.ucalgary.ca><046a01bfe2d9$88302360$f2a6b5d4@hagrid><049601bfe2db$acea1380$f2a6b5d4@hagrid><200006302302.SAA21232@cj20424-a.reston1.va.home.com><04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid><050501bfe2e3$b2517680$f2a6b5d4@hagrid> <14685.8480.389966.608982@anthem.concentric.net> <056501bfe2ec$5876c080$f2a6b5d4@hagrid> Message-ID: <200007010035.TAA22470@cj20424-a.reston1.va.home.com> > barry wrote: > > > Go ahead and check it in. I'll run idle and see wot hoppens. > > well? can I go to sleep now? please? Yes. Thanks! --Guido van Rossum (home page: http://www.python.org/~guido/) From nascheme at enme.ucalgary.ca Sat Jul 1 01:41:54 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 17:41:54 -0600 Subject: [Python-Dev] Updating patches on SF Message-ID: <20000630174154.A18362@acs.ucalgary.ca> WTF is going on? I did successfully update one of my patches but now that feature no longer seems to work. I get the message: Patch Uploaded Successfully Added Patch Could Not Send Patch Update and the old patch remains. Neil From nascheme at enme.ucalgary.ca Sat Jul 1 01:46:43 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 17:46:43 -0600 Subject: [Python-Dev] Updating patches on SF In-Reply-To: <20000630174154.A18362@acs.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Fri, Jun 30, 2000 at 05:41:54PM -0600 References: <20000630174154.A18362@acs.ucalgary.ca> Message-ID: <20000630174643.A18492@acs.ucalgary.ca> Killing the disk and memory cache seemed to fix the problem. Neil From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 02:13:37 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 02:13:37 +0200 (CEST) Subject: [Python-Dev] test_array failure on AIX Message-ID: <200007010013.CAA28135@python.inrialpes.fr> Any advice as to where I should look at and/or how to try fixing this? ~/python/CVS> ./python Lib/test/test_array.py **************************************** array after append: array('c', 'c') char array with 10 bytes of TESTFN appended: array('c', 'cThe quick ') char array with list appended: array('c', 'cThe quick abc') array of c after inserting another: array('c', 'ccThe quick abc') array of c converted to a list: ['c', 'c', 'T', 'h', 'e', ' ', 'q', 'u', 'i', 'c', 'k', ' ', 'a', 'b', 'c'] array of c converted to a string: 'ccThe quick abc' **************************************** array after append: array('b', [1]) array of b after inserting another: array('b', [1, 1]) array of b converted to a list: [1, 1] array of b converted to a string: '\001\001' overflow test: array('b', [-128L]) Traceback (most recent call last): File "Lib/test/test_array.py", line 137, in ? main() File "Lib/test/test_array.py", line 13, in main testtype(type, 1) File "Lib/test/test_array.py", line 132, in testtype testoverflow(type, signedLowerLimit, signedUpperLimit) File "Lib/test/test_array.py", line 25, in testoverflow raise TestFailed, "array(%s) overflowed assigning %s" %\ test_support -- test failed: array('b') overflowed assigning -128L -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at python.org Sat Jul 1 03:19:52 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 20:19:52 -0500 Subject: [Python-Dev] test_array failure on AIX In-Reply-To: Your message of "Sat, 01 Jul 2000 02:13:37 +0200." <200007010013.CAA28135@python.inrialpes.fr> References: <200007010013.CAA28135@python.inrialpes.fr> Message-ID: <200007010119.UAA24318@cj20424-a.reston1.va.home.com> > Any advice as to where I should look at and/or how to try fixing this? > > > ~/python/CVS> ./python Lib/test/test_array.py > **************************************** > array after append: array('c', 'c') > char array with 10 bytes of TESTFN appended: array('c', 'cThe quick ') > char array with list appended: array('c', 'cThe quick abc') > array of c after inserting another: array('c', 'ccThe quick abc') > array of c converted to a list: ['c', 'c', 'T', 'h', 'e', ' ', 'q', 'u', 'i', 'c', 'k', ' ', 'a', 'b', 'c'] > array of c converted to a string: 'ccThe quick abc' > **************************************** > array after append: array('b', [1]) > array of b after inserting another: array('b', [1, 1]) > array of b converted to a list: [1, 1] > array of b converted to a string: '\001\001' > overflow test: array('b', [-128L]) > Traceback (most recent call last): > File "Lib/test/test_array.py", line 137, in ? > main() > File "Lib/test/test_array.py", line 13, in main > testtype(type, 1) > File "Lib/test/test_array.py", line 132, in testtype > testoverflow(type, signedLowerLimit, signedUpperLimit) > File "Lib/test/test_array.py", line 25, in testoverflow > raise TestFailed, "array(%s) overflowed assigning %s" %\ > test_support -- test failed: array('b') overflowed assigning -128L Look at b_setitem() in arraymodule.c. What is CHAR_MIN? Do you perchance have unsigned characters??? If so, let's just replace CHAR_MIN with -128 and CHAR_MAX with 127. --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein at lyra.org Sat Jul 1 02:32:24 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 30 Jun 2000 17:32:24 -0700 Subject: [Python-Dev] proper CVS usage is a must! (was: CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32) In-Reply-To: <395CB46B.34053D3E@lemburg.com>; from mal@lemburg.com on Fri, Jun 30, 2000 at 04:53:31PM +0200 References: <200006301029.DAA25494@slayer.i.sourceforge.net> <20000630142154.968F831047C@bireme.oratrix.nl> <395CB46B.34053D3E@lemburg.com> Message-ID: <20000630173224.O29590@lyra.org> On Fri, Jun 30, 2000 at 04:53:31PM +0200, M.-A. Lemburg wrote: > > Why was the change that occurred in revision 2.31 reverted? Accident? > > > > The change log said: > > Jack Jansen: Use include "" instead of <>; and staticforward declarations > > Accident... I'll revert that change. This is symptomatic of people not being careful with their CVS usage. *ALWAYS* do a "cvs update" before any commits. If the file has changed while you're working on it, CVS will merge the changes in with yours. You will be notified if there were any conflicts. But this is a MUST. We've seen this reversal of changes twice now. Only through the careful eye of some -checkins watchers has that fact turned up. If those people weren't watching, we'd be lost. If you're going to commit changes to Python, then please take the responsibility to use CVS correctly. Thanks! -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jul 1 02:34:10 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 30 Jun 2000 17:34:10 -0700 Subject: [Python-Dev] attribution? (was: CVS: python/dist/src/Objects unicodeobject.c,2.32,2.33) In-Reply-To: <200006301458.HAA12572@slayer.i.sourceforge.net>; from lemburg@users.sourceforge.net on Fri, Jun 30, 2000 at 07:58:23AM -0700 References: <200006301458.HAA12572@slayer.i.sourceforge.net> Message-ID: <20000630173410.P29590@lyra.org> On Fri, Jun 30, 2000 at 07:58:23AM -0700, M.-A. Lemburg wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv12549/Objects > > Modified Files: > unicodeobject.c > Log Message: > Marc-Andre Lemburg : > A previous patch by Jack Jansen was accidently reverted. Is placing your email address into the log message really useful? After all, the checkin is already labeled as yours. I'm all for complete log messages, but scattering emails in there is a bit redundant. Certainly, if you commit somebody *else's* patch, then put their name in. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 02:37:39 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 02:37:39 +0200 (CEST) Subject: [Python-Dev] test_array failure on AIX In-Reply-To: <200007010119.UAA24318@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 30, 2000 08:19:52 PM Message-ID: <200007010037.CAA28255@python.inrialpes.fr> Guido van Rossum wrote: > > Look at b_setitem() in arraymodule.c. > > What is CHAR_MIN? > > Do you perchance have unsigned characters??? This answers your question: /usr/include/sys/limits.h:#define CHAR_MIN (0) /usr/include/sys/limits.h:#define SCHAR_MIN (-SCHAR_MAX - 1) > > If so, let's just replace CHAR_MIN with -128 and CHAR_MAX with 127. Yes! I #undef/define'd them like this in arraymodule.c and the test passes. Thanks! -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Sat Jul 1 02:40:25 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 30 Jun 2000 17:40:25 -0700 Subject: [Python-Dev] Checked in new PC\config.h In-Reply-To: ; from mhammond@skippinet.com.au on Sat, Jul 01, 2000 at 01:48:43AM +1000 References: Message-ID: <20000630174025.Q29590@lyra.org> On Sat, Jul 01, 2000 at 01:48:43AM +1000, Mark Hammond wrote: > Hi all, > I noticed that PC\config.h still had a reference to "Python16.lib". I > simply checked in a new version without submitting a patch or following any > other process. I hope this was appropriate. If this isn't "proper", then the process is broken. IMO, patches are for people without commit access, or when a committer wants some feedback on their patch. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Sat Jul 1 03:10:08 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 1 Jul 2000 11:10:08 +1000 Subject: [Python-Dev] Windows build issues In-Reply-To: <200006302133.QAA20696@cj20424-a.reston1.va.home.com> Message-ID: > > Also, I get a few warnings when compiling. One is about an /IZ > > (I think) option being ignored. There are a few other warnings > > as well which I didn't write down. > > Probably 6.0 flags that 5.0 doesn't have. What can we do? This was probably "/ZI". "/ZI" means "symbolic information for edit-and-continue" and is only VC6. "/Zi" means "symbolic information", and is in _all_ VC versions. /ZI doesnt give us much for Python. Im my experience, changing Pythion binaries while debugging is cute, but pretty useless as often a .py file _also_ needs changing, and Python doesnt really support "edit-and-continue" in the same way. MSVC kindly bumps a "/Zi" option to "/ZI" automatically and silently when doing the VC5->VC6 updgrade So I can see no reason not to use "/Zi" for both. From the GUI, it should be obvious - its the symbolic debug option without edit-and-continue. Mark. From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 03:51:07 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 03:51:07 +0200 (CEST) Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: from "Ka-Ping Yee" at Jun 29, 2000 05:44:35 PM Message-ID: <200007010151.DAA00574@python.inrialpes.fr> Ka-Ping Yee wrote: > > On 30 Jun 2000, Michael Hudson wrote: > > Yup, that works fine. Don't understand the details - and as I have my > > graduation ceremony tomorrow I'm going to go to bed and leave learning > > them until some other occasion! > > Cool. > > Okay, i just discovered sunau.py. Here's my real shot at > test_linuxaudiodev.py. Can you give this a try? > > > ---- test_linuxaudiodev.py ---- > from test_support import verbose, findfile, TestFailed > import linuxaudiodev > import os, sunau Yes, but this uses sunau which assumes the audioop.c module is enabled (imported by readframes(), sunau.py line 259) which might not be the case. Besides, Michael reported that it doesn't work quite right. So I'd blindly vote for Michael Hudson's improved version which uses only linuxaudiodev and plays the test sound without noise: ----------[ test_linuxaudiodev.py posted by Michael Hudson ]----------- from test_support import verbose, findfile, TestFailed import linuxaudiodev import os,struct def play_au_file(path): fp = open(path, "r") # Read the .au file header. header = fp.read(24) hdrsize, length, encoding, rate, channels = \ struct.unpack(">xxxxiiiii", header) fp.read(hdrsize - 24) data = fp.read() fp.close() # Set the data format according to the code in the .au header. if encoding == 1: size, fmt = 8, linuxaudiodev.AFMT_MU_LAW elif encoding == 2: size, fmt = 8, linuxaudiodev.AFMT_S8 elif encoding == 3: size, fmt = 16, linuxaudiodev.AFMT_S16_BE else: raise "audio format not supported" dsp = linuxaudiodev.open("w") dsp.setparameters(rate, size, channels, fmt) dsp.write(data) dsp.close() def test(): play_au_file(findfile('audiotest.au')) test() ---------------------------------------------------------------------- -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at python.org Sat Jul 1 05:35:33 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 22:35:33 -0500 Subject: [Python-Dev] Sorry. No Release. Message-ID: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> I can't say how disappointed I am: at the very last moment I have heard that I am not allowed to release Python 2.0b1 on July 1 as planned. Some last-minute issues have come up regarding the licensing from CNRI. BeOpen is going to resolve these issues as soon as possible, but it could be weeks... In the mean time, I thank everybody who worked very hard to make this release a success. We will continue to work on the SourceForge CVS repository as before. There will be a 2.0 release as soon as possible! --Guido van Rossum (home page: http://www.python.org/~guido/) From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 05:07:28 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 05:07:28 +0200 (CEST) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 30, 2000 10:35:33 PM Message-ID: <200007010307.FAA01904@python.inrialpes.fr> Guido van Rossum wrote: > > I can't say how disappointed I am: at the very last moment I have > heard that I am not allowed to release Python 2.0b1 on July 1 as > planned. Some last-minute issues have come up regarding the licensing > from CNRI. BeOpen is going to resolve these issues as soon as > possible, but it could be weeks... Doh. The premature 2.0 release excitement died prematurely > > In the mean time, I thank everybody who worked very hard to make this > release a success. We will continue to work on the SourceForge CVS > repository as before. There will be a 2.0 release as soon as > possible! Maybe it would be good to think about and define a short-term plan of action, given that we'll have a "major" release and that now we have some more time, cf. the previous discussion on the subject. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw at beopen.com Sat Jul 1 05:13:44 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 23:13:44 -0400 (EDT) Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> <050501bfe2e3$b2517680$f2a6b5d4@hagrid> <14685.8480.389966.608982@anthem.concentric.net> <056501bfe2ec$5876c080$f2a6b5d4@hagrid> Message-ID: <14685.25064.334520.654960@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: >> Go ahead and check it in. I'll run idle and see wot hoppens. FL> well? can I go to sleep now? please? Sorry, I was off-line for a while. I see Guido gave the word, but just to follow up, yes Idle works for me too. Thanks! From mhammond at skippinet.com.au Sat Jul 1 06:56:18 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 1 Jul 2000 14:56:18 +1000 Subject: [Python-Dev] Python for Windows extensions updated for Python 2.0 Message-ID: Hi all, FYI - Ive just finished checking into CVS all the changes necessary for Python 2.0. So if you update the complete Python tree from sourceforge and the Win32 extensions trees from pythonpros, you should get successful builds of everything. I recommend that you seek-and-destroy Py*16* on your machine - this will ensure that if you have missed any extension modules, you get a nice "Python16.dll not found", rather than the thread-state crash that happens if that DLL does indeed still exist. Mark. From petrilli at amber.org Sat Jul 1 07:00:16 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Sat, 1 Jul 2000 01:00:16 -0400 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <14685.1021.870885.796187@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jun 30, 2000 at 04:33:01PM -0400 References: <200006302126.QAA20621@cj20424-a.reston1.va.home.com> <14685.1021.870885.796187@bitdiddle.concentric.net> Message-ID: <20000701010016.A4402@trump.amber.org> Jeremy Hylton [jeremy at beopen.com] wrote: > Perhaps I am too easy-going, but I consider the 2.0 release a > 'dot-release' masquerading as a major revision. It might be a little > silly, but it seems even sillier to preserve a naming scheme that > makes users think that the technology is immature. I have to say I always thought Guido was a bit conservative... 1.3 -> 1.4 would have been a 3.x release from any "other company", and certainly 1.4 to 1.5 has some major new things (exception changes, etc). I think X.Y means X MAY introduce backward incompatibility, but doesn't have to. It just means major new functionality... I've seen a few of our customers go... "But wait, it's only at 1.5"... yeah, so? Chris -- | Christopher Petrilli | petrilli at amber.org From skip at mojam.com Sat Jul 1 09:07:00 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 1 Jul 2000 02:07:00 -0500 (CDT) Subject: [Python-Dev] barest beginnings of test coverage results Message-ID: <14685.39060.785993.960514@beluga.mojam.com> I compiled the Python interpreter with the flags necessary to get statement and branch coverage information then generated coverage files using the GNU coverage tool, gcov. If you'd like a peek at the coverage files, have a look at http://www.musi-cal.com/~skip/python/Python/dist/src/ The statement/branch coverage information is for one run of executing Lib/test/regrtest.py. Anywhere there is a C source file with coverage info the filename will end in ".c.gcov". I will eventually segregate the coverage files into a parallel tree and not mix them with the build tree. I would also like to adjust the regrtest.py stuff to generate statement coverage for .py files using my trace module: http://www.musi-cal.com/~skip/python/trace.py. For an example of how far this sort of thing can go, poke around in VTK's nightly quality dashboard: http://public.kitware.com/vtk/quality/MostRecentResults/ The VTK gang has been doing this for a couple years and now displays the following information: * pass/fail and faster/slower summaries of their nightly regression tests * code coverage information (using gcc/gcov as I'm doing) * all this on eight different Unix platforms each night Skip From martin at loewis.home.cs.tu-berlin.de Sat Jul 1 09:47:20 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 1 Jul 2000 09:47:20 +0200 Subject: [Python-Dev] Minidom and Unicode Message-ID: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> While trying the minidom parser from the current CVS, I found that repr apparently does not work for nodes: Python 2.0b1 (#29, Jun 30 2000, 10:48:11) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from xml.dom.minidom import parse >>> d=parse("/usr/src/python/Doc/tools/sgmlconv/conversion.xml") >>> d.childNodes [Traceback (most recent call last): File "", line 1, in ? TypeError: __repr__ returned non-string (type unicode) The problem here is that __repr__ is computed as def __repr__( self ): return "" and that self.tagName is u'conversion', so the resulting string is a unicode string. I'm not sure whose fault that is: either __repr__ should accept unicode strings, or minidom.Element.__repr__ should be changed to return a plain string, e.g. by converting tagname to UTF-8. In any case, I believe __repr__ should 'work' for these objects. Regards, Martin From effbot at telia.com Sat Jul 1 11:10:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 11:10:45 +0200 Subject: [Python-Dev] Sorry. No Release. References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> Message-ID: <00ab01bfe33c$3fc85620$f2a6b5d4@hagrid> guido wrote: > I can't say how disappointed I am: at the very last moment I have > heard that I am not allowed to release Python 2.0b1 on July 1 as > planned. Some last-minute issues have come up regarding the licensing > from CNRI. BeOpen is going to resolve these issues as soon as > possible, but it could be weeks... what's the legal status of the material on the SF site. can people download and redistribute snapshots of the CVS repository, or is it in some kind of legal limbo at this time? From gstein at lyra.org Sat Jul 1 11:09:23 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 02:09:23 -0700 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: <200006301748.KAA11055@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Fri, Jun 30, 2000 at 10:48:54AM -0700 References: <200006301748.KAA11055@slayer.i.sourceforge.net> Message-ID: <20000701020923.S29590@lyra.org> While I'm very glad that I suggested PyLong_FromVoidPtr() for issues like this, I think that returning an HKEY should probably use a PyCObject. You will then be able to supply a "free" function that can close the HKEY. Cheers, -g On Fri, Jun 30, 2000 at 10:48:54AM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/PC > In directory slayer.i.sourceforge.net:/tmp/cvs-serv11047/PC > > Modified Files: > msvcrtmodule.c _winreg.c > Log Message: > [*** Not tested as I don't have Windows running right now! ***] > > Trent Mick : > > Fix PC/msvcrtmodule.c and PC/winreg.c for Win64. Basically: > > - sizeof(HKEY) > sizeof(long) on Win64, so use PyLong_FromVoidPtr() > instead of PyInt_FromLong() to return HKEY values on Win64 > > - Check for string overflow of an arbitrary registry value (I know > that ensuring that a registry value does not overflow 2**31 characters > seems ridiculous but it is *possible*). > > Closes SourceForge patch #100517. >... -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jul 1 12:24:38 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 03:24:38 -0700 Subject: [Python-Dev] ML replies (was: CVS: python/dist/src/PCbuild readme.txt,1.5,1.6) In-Reply-To: <14684.43443.919858.897738@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Jun 30, 2000 at 10:07:47AM -0400 References: <14684.43443.919858.897738@anthem.concentric.net> Message-ID: <20000701032438.U29590@lyra.org> On Fri, Jun 30, 2000 at 10:07:47AM -0400, Barry A. Warsaw wrote: > > >>>>> "MH" == Mark Hammond writes: > > MH> [I wishing mailing-lists would agree on how they handle > MH> reply-to :-] > > It's fundamentally broken, but the problem is in the mail readers > (MUA). There's no header (that I'm aware of) that portably tells an > MUA - "Hey, for a group follow up, don't go to the original list, go > to THIS one instead, but for an individual followup (i.e. reply) still > address that to the original author." > > This is one reason why munging reply-to is evil. But in this case > we've agreed that following up to python-dev is more important than > preserving the ability to reply to the author. What about the Mail-Followup-To header? That can be helpful for some newsreaders (e.g. Mutt). Dunno how many observe it. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jul 1 12:29:59 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 03:29:59 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml/sax __init__.py,NONE,1.1 In-Reply-To: <200006291933.MAA05055@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Thu, Jun 29, 2000 at 12:33:45PM -0700 References: <200006291933.MAA05055@slayer.i.sourceforge.net> Message-ID: <20000701032959.V29590@lyra.org> Do you really want to import that many items into the xml.sax module? IMO, be specific on what is imported into xml.sax for *convenience*. Don't just import the world. Also note that the import for SAXParseException is redundant. Cheers, -g On Thu, Jun 29, 2000 at 12:33:45PM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Lib/xml/sax > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5045 > > Added Files: > __init__.py > Log Message: > > Package docstring and initialization. > > > --- NEW FILE --- > """Simple API for XML (SAX) implementation for Python. > > This module provides an implementation of the SAX 2 interface; > information about the Java version of the interface can be found at > http://www.megginson.com/SAX/. The Python version of the interface is > documented at <...>. > > This package contains the following modules: > > saxutils -- Implementation of the convenience functions normally used > to work with SAX. > > saxlib -- Implementation of the shared SAX 2 classes. > > drv_pyexpat -- Driver that allows use of the Expat parser with the classes > defined in saxlib. > > """ > > from handler import * > from expatreader import * > from _exceptions import * > from saxutils import * > from _exceptions import SAXParseException > import xmlreader > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From esr at thyrsus.com Sat Jul 1 12:52:22 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 1 Jul 2000 06:52:22 -0400 Subject: [Python-Dev] ML replies (was: CVS: python/dist/src/PCbuild readme.txt,1.5,1.6) In-Reply-To: <20000701032438.U29590@lyra.org>; from gstein@lyra.org on Sat, Jul 01, 2000 at 03:24:38AM -0700 References: <14684.43443.919858.897738@anthem.concentric.net> <20000701032438.U29590@lyra.org> Message-ID: <20000701065222.A31221@thyrsus.com> Greg Stein : > > This is one reason why munging reply-to is evil. But in this case > > we've agreed that following up to python-dev is more important than > > preserving the ability to reply to the author. > > What about the Mail-Followup-To header? That can be helpful for some > newsreaders (e.g. Mutt). Dunno how many observe it. Eudora honors it, too. It's not an official standard, unfortunately; I was on the IETF committee where that battle was fought to a bloody draw. But it's the best you can do. -- Eric S. Raymond "The best we can hope for concerning the people at large is that they be properly armed." -- Alexander Hamilton, The Federalist Papers at 184-188 From mal at lemburg.com Sat Jul 1 13:51:43 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 13:51:43 +0200 Subject: [Python-Dev] proper CVS usage is a must! (was: CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32) References: <200006301029.DAA25494@slayer.i.sourceforge.net> <20000630142154.968F831047C@bireme.oratrix.nl> <395CB46B.34053D3E@lemburg.com> <20000630173224.O29590@lyra.org> Message-ID: <395DDB4F.F9186544@lemburg.com> Greg Stein wrote: > > On Fri, Jun 30, 2000 at 04:53:31PM +0200, M.-A. Lemburg wrote: > > > Why was the change that occurred in revision 2.31 reverted? Accident? > > > > > > The change log said: > > > Jack Jansen: Use include "" instead of <>; and staticforward declarations > > > > Accident... I'll revert that change. > > This is symptomatic of people not being careful with their CVS usage. > > *ALWAYS* do a "cvs update" before any commits. If the file has changed while > you're working on it, CVS will merge the changes in with yours. You will be > notified if there were any conflicts. > > But this is a MUST. We've seen this reversal of changes twice now. Only > through the careful eye of some -checkins watchers has that fact turned up. > If those people weren't watching, we'd be lost. > > If you're going to commit changes to Python, then please take the > responsibility to use CVS correctly. Hey, Greg, stay cool :-) The accident happened because I had to modify Trent's patch to make it apply correctly and I forgot to update the *copy* of the CVS tree in which I edited the changes. I always do a cvs update to my local CVS version before the checkins, in fact, the small script I posted to this list does the checking for me and won't accept the checkins if the local version is out of sync. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jul 1 13:55:02 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 13:55:02 +0200 Subject: [Python-Dev] attribution? (was: CVS: python/dist/src/Objects unicodeobject.c,2.32,2.33) References: <200006301458.HAA12572@slayer.i.sourceforge.net> <20000630173410.P29590@lyra.org> Message-ID: <395DDC16.2768421C@lemburg.com> Greg Stein wrote: > > On Fri, Jun 30, 2000 at 07:58:23AM -0700, M.-A. Lemburg wrote: > > Update of /cvsroot/python/python/dist/src/Objects > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv12549/Objects > > > > Modified Files: > > unicodeobject.c > > Log Message: > > Marc-Andre Lemburg : > > A previous patch by Jack Jansen was accidently reverted. > > Is placing your email address into the log message really useful? After all, > the checkin is already labeled as yours. > > I'm all for complete log messages, but scattering emails in there is a bit > redundant. > > Certainly, if you commit somebody *else's* patch, then put their name in. I wasn't sure whether the person who checks in patches appears in the CVS log, so I added the name and email in front of the message. I'll remove the note in my checkin script. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jul 1 13:56:44 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 13:56:44 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <200006302314.SAA21371@cj20424-a.reston1.va.home.com> Message-ID: <395DDC7C.4285D56A@lemburg.com> Guido van Rossum wrote: > > > Not that I hope to override the heavy -1, but I don't agree with the second > > point. It embodies a huge amount of knowledge that is needed to write > > portable code. As such, IMO, it _does_ belong in the standard library. How > > is it different in its nature from sys.platform, which is only a much weaker > > version of the same concept? > > A more subtle way of stating my opinion could be: if we were to do > something in the standard distribution about the problems that this is > addressing, I think we would do it in a much more direct fashion, > e.g. by making the appropriate enquiry functions directly accessible. platform.py does use the available functions on a couple of platforms... and it itself provides direct enquiry functions for Python programs to use. Perhaps I'm misunderstanding you here. Anyway, it's there for non-core programs to use and so far I think the core lib has managed to switch on sys.platform and do the right thing, so platform.py may not be all that necessary in the core. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jul 1 14:02:55 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 14:02:55 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> Message-ID: <395DDDEF.4ABB5BFC@lemburg.com> "Martin v. Loewis" wrote: > > While trying the minidom parser from the current CVS, I found that > repr apparently does not work for nodes: > > Python 2.0b1 (#29, Jun 30 2000, 10:48:11) [GCC 2.95.2 19991024 (release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> from xml.dom.minidom import parse > >>> d=parse("/usr/src/python/Doc/tools/sgmlconv/conversion.xml") > >>> d.childNodes > [Traceback (most recent call last): > File "", line 1, in ? > TypeError: __repr__ returned non-string (type unicode) > > The problem here is that __repr__ is computed as > > def __repr__( self ): > return "" > > and that self.tagName is u'conversion', so the resulting string is a > unicode string. > > I'm not sure whose fault that is: either __repr__ should accept > unicode strings, or minidom.Element.__repr__ should be changed to > return a plain string, e.g. by converting tagname to UTF-8. In any > case, I believe __repr__ should 'work' for these objects. Note that __repr__ has to return a string object (and IIRC this is checked in object.c or abstract.c). The correct way to get there is to simply return str(...) or to have a switch on the type of self.tagName and then call .encode(). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Sat Jul 1 15:21:12 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 01 Jul 2000 08:21:12 -0500 Subject: [Python-Dev] barest beginnings of test coverage results In-Reply-To: Your message of "Sat, 01 Jul 2000 02:07:00 EST." <14685.39060.785993.960514@beluga.mojam.com> References: <14685.39060.785993.960514@beluga.mojam.com> Message-ID: <200007011321.IAA09485@cj20424-a.reston1.va.home.com> > I compiled the Python interpreter with the flags necessary to get statement > and branch coverage information then generated coverage files using the GNU > coverage tool, gcov. If you'd like a peek at the coverage files, have a > look at > > http://www.musi-cal.com/~skip/python/Python/dist/src/ > > The statement/branch coverage information is for one run of executing > Lib/test/regrtest.py. Wow, Skip! Very impressive. But there's soooooo much data... How do we find the gems? Should we just look at one file per day and try to add testcases that get rid of the ##### comments? Is there a way to sort the files based on the number or significance of the ##### comments? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From akuchlin at cnri.reston.va.us Sat Jul 1 14:28:29 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 1 Jul 2000 08:28:29 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <200007010335.WAA29653@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 10:35:33PM -0500 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> Message-ID: <20000701082829.C2345@newcnri.cnri.reston.va.us> On Fri, Jun 30, 2000 at 10:35:33PM -0500, Guido van Rossum wrote: >I can't say how disappointed I am: at the very last moment I have >heard that I am not allowed to release Python 2.0b1 on July 1 as >planned. Some last-minute issues have come up regarding the licensing I'm not convinced this delay is wholly a bad thing. Did Barry ever track down the mysterious crashes he was seeing from running the test suite? And it's more time to experiment with the garbage collection, hunt for SRE bugs, and so forth. --amk From martin at loewis.home.cs.tu-berlin.de Sat Jul 1 14:22:39 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 1 Jul 2000 14:22:39 +0200 Subject: [Python-Dev] Minidom and Unicode In-Reply-To: <395DDDEF.4ABB5BFC@lemburg.com> (mal@lemburg.com) References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> Message-ID: <200007011222.OAA11088@loewis.home.cs.tu-berlin.de> > Note that __repr__ has to return a string object (and IIRC > this is checked in object.c or abstract.c). The correct way > to get there is to simply return str(...) or to have a > switch on the type of self.tagName and then call .encode(). Ok. I believe tagName will be always a Unicode object (as mandated by the DOM API), so I propose patch 100706 (http://sourceforge.net/patch/?func=detailpatch&patch_id=100706&group_id=5470) Regards, Martin From guido at beopen.com Sat Jul 1 15:46:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 01 Jul 2000 08:46:29 -0500 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: Your message of "Sat, 01 Jul 2000 08:28:29 -0400." <20000701082829.C2345@newcnri.cnri.reston.va.us> References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> Message-ID: <200007011346.IAA09576@cj20424-a.reston1.va.home.com> > I'm not convinced this delay is wholly a bad thing. Did Barry ever > track down the mysterious crashes he was seeing from running the test > suite? And it's more time to experiment with the garbage collection, > hunt for SRE bugs, and so forth. But that's what beta releases are for, right? The result now is that fewer people will try out the code than if it were released today, and the final release will undoubtedly be delayed again. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From effbot at telia.com Sat Jul 1 14:52:51 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 14:52:51 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> Message-ID: <010601bfe35b$46727ae0$f2a6b5d4@hagrid> mal wrote: > > I'm not sure whose fault that is: either __repr__ should accept > > unicode strings, or minidom.Element.__repr__ should be changed to > > return a plain string, e.g. by converting tagname to UTF-8. In any > > case, I believe __repr__ should 'work' for these objects. > > Note that __repr__ has to return a string object (and IIRC > this is checked in object.c or abstract.c). The correct way > to get there is to simply return str(...) or to have a > switch on the type of self.tagName and then call .encode(). assuming that the goal is to get rid of this restriction in future versions (a string is a string is a string), how about special- casing this in PyObject_Repr: PyObject *res; res = (*v->ob_type->tp_repr)(v); if (res == NULL) return NULL; --- if (PyUnicode_Check(res)) { PyObject* str; str = PyUnicode_AsEncodedString(res, NULL, NULL); if (str) { Py_DECREF(res); res = str; } } --- if (!PyString_Check(res)) { PyErr_Format(PyExc_TypeError, "__repr__ returned non-string (type %.200s)", res->ob_type->tp_name); Py_DECREF(res); return NULL; } return res; in this way, people can "do the right thing" in their code, and have it work better in future versions... (just say "+1", and the mad patcher will update the repository) From guido at beopen.com Sat Jul 1 16:13:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 01 Jul 2000 09:13:36 -0500 Subject: [Python-Dev] Minidom and Unicode In-Reply-To: Your message of "Sat, 01 Jul 2000 14:52:51 +0200." <010601bfe35b$46727ae0$f2a6b5d4@hagrid> References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> Message-ID: <200007011413.JAA09667@cj20424-a.reston1.va.home.com> > mal wrote: > > > I'm not sure whose fault that is: either __repr__ should accept > > > unicode strings, or minidom.Element.__repr__ should be changed to > > > return a plain string, e.g. by converting tagname to UTF-8. In any > > > case, I believe __repr__ should 'work' for these objects. > > > > Note that __repr__ has to return a string object (and IIRC > > this is checked in object.c or abstract.c). The correct way > > to get there is to simply return str(...) or to have a > > switch on the type of self.tagName and then call .encode(). [/F] > assuming that the goal is to get rid of this restriction in future > versions (a string is a string is a string), how about special- > casing this in PyObject_Repr: > > PyObject *res; > res = (*v->ob_type->tp_repr)(v); > if (res == NULL) > return NULL; > --- > if (PyUnicode_Check(res)) { > PyObject* str; > str = PyUnicode_AsEncodedString(res, NULL, NULL); > if (str) { > Py_DECREF(res); > res = str; > } > } > --- > if (!PyString_Check(res)) { > PyErr_Format(PyExc_TypeError, > "__repr__ returned non-string (type %.200s)", > res->ob_type->tp_name); > Py_DECREF(res); > return NULL; > } > return res; > > in this way, people can "do the right thing" in their code, > and have it work better in future versions... > > (just say "+1", and the mad patcher will update the repository) +1 --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul at prescod.net Sat Jul 1 15:09:20 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 08:09:20 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> Message-ID: <395DED80.A30FB417@prescod.net> "M.-A. Lemburg" wrote: > > Note that __repr__ has to return a string object (and IIRC > this is checked in object.c or abstract.c). The correct way > to get there is to simply return str(...) or to have a > switch on the type of self.tagName and then call .encode(). > ... I prefer the former solution and unless someone screams I will check that in in a few hours. Why can't repr have a special case that converts Unicode strings to "Python strings" automatically. This case is going to byte other people. > Ok. I believe tagName will be always a Unicode object (as mandated by > the DOM API), so I propose patch 100706 > (http://sourceforge.net/patch/?func=detailpatch&patch_id=100706&group_id=5470) I would like Unicode usage to be a userland option for reasons of performance and backwards compatibility. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Sat Jul 1 15:12:28 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 08:12:28 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> Message-ID: <395DEE3C.E7BAD4C3@prescod.net> Fredrik Lundh wrote: > > ... > > assuming that the goal is to get rid of this restriction in future > versions (a string is a string is a string), how about special- > casing this in PyObject_Repr: This is my prefered solution. +1 from me. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From mhammond at skippinet.com.au Sat Jul 1 15:23:21 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 1 Jul 2000 23:23:21 +1000 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: <20000701020923.S29590@lyra.org> Message-ID: > While I'm very glad that I suggested PyLong_FromVoidPtr() for issues like > this, I think that returning an HKEY should probably use a PyCObject. You > will then be able to supply a "free" function that can close the HKEY. This is exactly what we do. Trents patches are just for the functions that return the underlying handle value as an integer (which is definately a useful thing to be able to do!) Mark. From gstein at lyra.org Sat Jul 1 15:51:11 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 06:51:11 -0700 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: ; from mhammond@skippinet.com.au on Sat, Jul 01, 2000 at 11:23:21PM +1000 References: <20000701020923.S29590@lyra.org> Message-ID: <20000701065111.Z29590@lyra.org> On Sat, Jul 01, 2000 at 11:23:21PM +1000, Mark Hammond wrote: > > While I'm very glad that I suggested PyLong_FromVoidPtr() for issues like > > this, I think that returning an HKEY should probably use a PyCObject. You > > will then be able to supply a "free" function that can close the HKEY. > > This is exactly what we do. Trents patches are just for the functions that > return the underlying handle value as an integer (which is definately a > useful thing to be able to do!) But I don't understand why you want an integer. From the Python programmer's standpoint, they just want a handle, right? The safety of having the "free" function is quite nice. Without it, it would seem to be "easy" to leak handles. Without using PyCObject, we'd need a complete handle type (like the one in win32api or wherever). Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 16:23:16 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 16:23:16 +0200 (CEST) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <200007011346.IAA09576@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 01, 2000 08:46:29 AM Message-ID: <200007011423.QAA05486@python.inrialpes.fr> Guido van Rossum wrote: > > > I'm not convinced this delay is wholly a bad thing. Did Barry ever > > track down the mysterious crashes he was seeing from running the test > > suite? And it's more time to experiment with the garbage collection, > > hunt for SRE bugs, and so forth. > > But that's what beta releases are for, right? The result now is that > fewer people will try out the code than if it were released today, and > the final release will undoubtedly be delayed again. Guido, what about reverting the version number to 2.0a3 ? We're still not in a beta stage, but there *is* a new version ready, which, if not beta, should be an alpha. We're used to see the version bumped a day or two before the release. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From amk1 at erols.com Sat Jul 1 15:22:30 2000 From: amk1 at erols.com (A.M. Kuchling) Date: Sat, 1 Jul 2000 09:22:30 -0400 Subject: [Python-Dev] sysconfig/SRE bug Message-ID: <200007011322.JAA25612@207-172-146-185.s185.tnt3.ann.va.dialup.rcn.com> sysconfig.py contains a pattern that breaks SRE: >>> import re, pre >>> pre.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}") >>> re.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}") Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.0/sre.py", line 54, in compile return _compile(pattern, flags) ... File "/usr/lib/python2.0/sre_parse.py", line 538, in parse p = _parse(source, state) File "/usr/lib/python2.0/sre_parse.py", line 394, in _parse raise error, "bogus range" Escaping the { and } fix this. This is a problem with the {xxx,yyy} notation for ranges; PCRE looks ahead, and treats it as a literal unless it's followed by digits of the right form. From pypcre.c: /* This function is called when a '{' is encountered in a place where it might start a quantifier. It looks ahead to see if it really is a quantifier or not. It is only a quantifier if it is one of the forms {ddd} {ddd,} or {ddd,ddd} where the ddds are digits. */ I suppose the goal of Perl compatibility means this magical behaviour needs to be preserved? --amk From bwarsaw at beopen.com Sat Jul 1 17:16:46 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sat, 1 Jul 2000 11:16:46 -0400 (EDT) Subject: [Python-Dev] Sorry. No Release. References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> Message-ID: <14686.2910.855580.146653@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> I'm not convinced this delay is wholly a bad thing. Did Barry AK> ever track down the mysterious crashes he was seeing from AK> running the test suite? No, and Purify didn't help, although it did identify a couple of small memory leaks. Nothing more serious than that. One possible source of discrepancy though is that the machine I ran the tests on apparently didn't have enough memory (at 256MB!) to run the entire regrtest under a Purify'd Python. I'm going to continue looking though. -Barry From effbot at telia.com Sat Jul 1 17:54:29 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 17:54:29 +0200 Subject: [Python-Dev] sysconfig/SRE bug References: <200007011322.JAA25612@207-172-146-185.s185.tnt3.ann.va.dialup.rcn.com> Message-ID: <01f701bfe374$a661c500$f2a6b5d4@hagrid> andrew wrote: > sysconfig.py contains a pattern that breaks SRE: > > >>> import re, pre > >>> pre.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}") > > >>> re.compile(r"\${([A-Za-z][A-Za-z0-9_]*)}") > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/lib/python2.0/sre.py", line 54, in compile > return _compile(pattern, flags) > ... > File "/usr/lib/python2.0/sre_parse.py", line 538, in parse > p = _parse(source, state) > File "/usr/lib/python2.0/sre_parse.py", line 394, in _parse > raise error, "bogus range" > > Escaping the { and } fix this. This is a problem with the {xxx,yyy} > notation for ranges; PCRE looks ahead, and treats it as a literal > unless it's followed by digits of the right form. From pypcre.c: > > /* This function is called when a '{' is encountered in a place where it might > start a quantifier. It looks ahead to see if it really is a quantifier or not. > It is only a quantifier if it is one of the forms {ddd} {ddd,} or {ddd,ddd} > where the ddds are digits. > */ > > I suppose the goal of Perl compatibility means this magical behaviour > needs to be preserved? I'm not so sure about this one; the $ behaviour is documented in Perl, but this isn't (as far as I can tell, at least). and since it's detected by the parser, it's probably better to change the sysconfig module... (fixing this in the sre_parser isn't exactly trivial, either...) From effbot at telia.com Sat Jul 1 17:57:08 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 17:57:08 +0200 Subject: [Python-Dev] sysconfig/SRE bug References: <200007011322.JAA25612@207-172-146-185.s185.tnt3.ann.va.dialup.rcn.com> <01f701bfe374$a661c500$f2a6b5d4@hagrid> Message-ID: <01fd01bfe375$057389c0$f2a6b5d4@hagrid> I wrote: > I'm not so sure about this one; the $ behaviour is documented > in Perl, but this isn't (as far as I can tell, at least). umm. I suppose "If a curly bracket occurs in any other context, it is treated as a regular character" is documentation enough. please ignore me. From bwarsaw at beopen.com Sat Jul 1 18:16:48 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sat, 1 Jul 2000 12:16:48 -0400 (EDT) Subject: [Python-Dev] Re: ML replies (was: CVS: python/dist/src/PCbuild readme.txt,1.5,1.6) References: <14684.43443.919858.897738@anthem.concentric.net> <20000701032438.U29590@lyra.org> Message-ID: <14686.6512.329946.694266@anthem.concentric.net> [Please remove python-dev from followups, I'm sure most of those folks don't care about this... -BAW] MM-Devers: on python-dev there's been some discussion about the Reply-to: munging that you can select on Mailman lists. Say you've got a python-checkins list that receives CVS log messages automatically. But you don't want discussions about the changes on python-checkins, you want them on python-dev. How can Mailman set up the headers on outgoing messages to get this behavior? It can't. So it fakes it by setting Reply-to: to the address of the discussion list. We now join our conversation already in progress... >>>>> "GS" == Greg Stein writes: GS> What about the Mail-Followup-To header? That can be helpful GS> for some newsreaders (e.g. Mutt). Dunno how many observe it. It looks like VM/Emacs doesn't (which is what I use), but I'm sure that'd be easy to add. I would be most interested to know what Outlook and NS do with it. However Mail-Followup-To: isn't in any RFC that I can find, not even 2076. It can be found in a discussion by Dan Bernstein[1], but that document specifically says that list managers should /not/ set it because this defeats the intended purpose. I agree - given Dan's recommendation. So there is clearly no header that will support the functionality we want. And all this crud has been debated ad-nauseum in several working groups, MUA forums, etc. with no agreement. I almost hesitate even bringing it up here. Few of the discussions that I've read (in a morning's worth of archive surfing) even mention the situation we're trying to address. One potential solution for Mailman might be to lie about the To: address. So in the above scenario, the message would have a To: field set to python-dev even though the message would actually be sent to the python-checkins membership. An elaboration on that would be to set Resent-To: to python-checkins. But those are all hacks, nearly as disgusting as what Mailman currently does. -Barry [1] http://cr.yp.to/proto/replyto.html From skip at mojam.com Sat Jul 1 18:16:31 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 1 Jul 2000 11:16:31 -0500 (CDT) Subject: [Python-Dev] barest beginnings of test coverage results In-Reply-To: <200007011321.IAA09485@cj20424-a.reston1.va.home.com> References: <14685.39060.785993.960514@beluga.mojam.com> <200007011321.IAA09485@cj20424-a.reston1.va.home.com> Message-ID: <14686.6495.370859.13048@beluga.mojam.com> Guido> But there's soooooo much data... How do we find the gems? Guido> Should we just look at one file per day and try to add testcases Guido> that get rid of the ##### comments? Is there a way to sort the Guido> files based on the number or significance of the ##### comments? All I referred you to yesterday (it was late...) was a CVS tree in which I had built the interpreter with the necessary flags, run regrtest.py, then generated coverage files. The next step is to generate one or more pages of coverage summaries. Then you'll be able to browse something like http://www.musi-cal.com/~skip/python/Python/dist/src/lines.html http://www.musi-cal.com/~skip/python/Python/dist/src/branches.html and zero in on those files with lower than desired coverage. Skip From nascheme at enme.ucalgary.ca Sat Jul 1 18:20:37 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Sat, 1 Jul 2000 10:20:37 -0600 Subject: [Python-Dev] barest beginnings of test coverage results In-Reply-To: <200007011321.IAA09485@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Sat, Jul 01, 2000 at 08:21:12AM -0500 References: <14685.39060.785993.960514@beluga.mojam.com> <200007011321.IAA09485@cj20424-a.reston1.va.home.com> Message-ID: <20000701102037.A28228@acs.ucalgary.ca> On Sat, Jul 01, 2000 at 08:21:12AM -0500, Guido van Rossum wrote: > Wow, Skip! Very impressive. But there's soooooo much data... How do > we find the gems? http://www.musi-cal.com/~skip/python/Python/dist/src/summary.html The summary seems pretty good to me. Neil From skip at mojam.com Sat Jul 1 18:24:18 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 1 Jul 2000 11:24:18 -0500 (CDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <14686.2910.855580.146653@anthem.concentric.net> References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> Message-ID: <14686.6962.530478.967290@beluga.mojam.com> AK> I'm not convinced this delay is wholly a bad thing. Did Barry ever AK> track down the mysterious crashes he was seeing from running the AK> test suite? BAW> No, and Purify didn't help, although it did identify a couple of BAW> small memory leaks. Nothing more serious than that. One possible BAW> source of discrepancy though is that the machine I ran the tests on BAW> apparently didn't have enough memory (at 256MB!) to run the entire BAW> regrtest under a Purify'd Python. I'm going to continue looking BAW> though. My guess is that -tt triggered a SyntaxError (maybe we should create an IndentationError that is a subclass of SyntaxError?) the .pyc file didn't get generated, but the exception was caught by regrtest and execution continued. That would have caused any test that tried to import the tab-challenged file(s) to fail, right? Would that have been sufficient to provoke the symptoms we saw? -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From skip at mojam.com Sat Jul 1 18:31:43 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 1 Jul 2000 11:31:43 -0500 (CDT) Subject: [Python-Dev] barest beginnings of test coverage results In-Reply-To: <20000701102037.A28228@acs.ucalgary.ca> References: <14685.39060.785993.960514@beluga.mojam.com> <200007011321.IAA09485@cj20424-a.reston1.va.home.com> <20000701102037.A28228@acs.ucalgary.ca> Message-ID: <14686.7407.760808.838286@beluga.mojam.com> >> Wow, Skip! Very impressive. But there's soooooo much data... How >> do we find the gems? Neil> http://www.musi-cal.com/~skip/python/Python/dist/src/summary.html Neil> The summary seems pretty good to me. ;-) I got to the problem after Guido responded but apparently before you surfed... Skip From esr at thyrsus.com Sat Jul 1 18:43:03 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 1 Jul 2000 12:43:03 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <14686.6962.530478.967290@beluga.mojam.com>; from skip@mojam.com on Sat, Jul 01, 2000 at 11:24:18AM -0500 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> Message-ID: <20000701124303.A31955@thyrsus.com> Skip Montanaro : > My guess is that -tt triggered a SyntaxError (maybe we should create an > IndentationError that is a subclass of SyntaxError?) +1! -- Eric S. Raymond The United States is in no way founded upon the Christian religion -- George Washington & John Adams, in a diplomatic message to Malta. From chuqui at plaidworks.com Sat Jul 1 18:34:19 2000 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Sat, 1 Jul 2000 09:34:19 -0700 Subject: [Python-Dev] [Mailman-Developers] Re: ML replies (was: CVS: python/dist/src/PCbuild readme.txt,1.5,1.6) In-Reply-To: <14686.6512.329946.694266@anthem.concentric.net> References: <14684.43443.919858.897738@anthem.concentric.net> <20000701032438.U29590@lyra.org> <14686.6512.329946.694266@anthem.concentric.net> Message-ID: At 12:16 PM -0400 7/1/00, Barry A. Warsaw wrote: > GS> What about the Mail-Followup-To header? That can be helpful > GS> for some newsreaders (e.g. Mutt). Dunno how many observe it. > >It looks like VM/Emacs doesn't (which is what I use), but I'm sure >that'd be easy to add. I would be most interested to know what >Outlook and NS do with it. > >However Mail-Followup-To: isn't in any RFC that I can find, not even >2076. It's non-standard, and in fact, arguably non-compliant, since any unofficial header should be in the X-headername form. >So there is clearly no header that will support the functionality we >want. This is a case where Reply-To is the correct header to set, or at least, least incorrect. >One potential solution for Mailman might be to lie about the To: >address. So in the above scenario, the message would have a To: field >set to python-dev even though the message would actually be sent to >the python-checkins membership. um, uh, well... I don't like it. Even if you had Sender: and List-ID set properly, it still seems wrong. For this case, I think the best setup is Reply-to, because that's waht you want: it came FROM this place, but responses go to this other place. The proper answer is setting reply-to, not attempting to rearrange the concept of "from this place". As a strong proponent of "don't use reply-to!" -- this is a case where it's the proper answer. It's not perfect by any means, since reply-to coerces someone away from replying privately, but in this situation, that's better than not doing it. -- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui at plaidworks.com) Apple Mail List Gnome (mailto:chuq at apple.com) And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'" From effbot at telia.com Sat Jul 1 18:46:08 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 18:46:08 +0200 Subject: [Python-Dev] unicode alphanumerics Message-ID: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> when looking through skip's coverage listing, I noted a bug in SRE: #define SRE_UNI_IS_ALNUM(ch) ((ch) < 256 ? isalnum((ch)) : 0) this predicate is used for \w when a pattern is compiled using the "unicode locale" (flag U), and should definitely not use 8-bit locale stuff. however, there's no such thing as a Py_UNICODE_ISALNUM (or even a Py_UNICODE_ISALPHA). what should I do? how about using: Py_UNICODE_ISLOWER || Py_UNICODE_ISUPPER || Py_UNICODE_ISTITLE || Py_UNICODE_ISDIGIT From mal at lemburg.com Sat Jul 1 18:46:52 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 18:46:52 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> Message-ID: <395E207C.91E3A2A5@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > I'm not sure whose fault that is: either __repr__ should accept > > > unicode strings, or minidom.Element.__repr__ should be changed to > > > return a plain string, e.g. by converting tagname to UTF-8. In any > > > case, I believe __repr__ should 'work' for these objects. > > > > Note that __repr__ has to return a string object (and IIRC > > this is checked in object.c or abstract.c). The correct way > > to get there is to simply return str(...) or to have a > > switch on the type of self.tagName and then call .encode(). > > assuming that the goal is to get rid of this restriction in future > versions (a string is a string is a string), how about special- > casing this in PyObject_Repr: > > PyObject *res; > res = (*v->ob_type->tp_repr)(v); > if (res == NULL) > return NULL; > --- > if (PyUnicode_Check(res)) { > PyObject* str; > str = PyUnicode_AsEncodedString(res, NULL, NULL); > if (str) { > Py_DECREF(res); > res = str; > } > } > --- > if (!PyString_Check(res)) { > PyErr_Format(PyExc_TypeError, > "__repr__ returned non-string (type %.200s)", > res->ob_type->tp_name); > Py_DECREF(res); > return NULL; > } > return res; > > in this way, people can "do the right thing" in their code, > and have it work better in future versions... > > (just say "+1", and the mad patcher will update the repository) I'd say +0, since the auto-converion can fail if the default encoding doesn't have room for the tagName characters. Either way, I'd still prefer the DOM code to use an explicit .encode() together with some lossless encoding, e.g. unicode-escape. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 18:52:50 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 18:52:50 +0200 (CEST) Subject: [Python-Dev] test, please ignore Message-ID: <200007011652.SAA05728@python.inrialpes.fr> -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Sat Jul 1 18:56:49 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 18:56:49 +0200 (CEST) Subject: [Python-Dev] Sorry. No Release. Message-ID: <200007011656.SAA05767@python.inrialpes.fr> Resending... Subject: Re: [Python-Dev] Sorry. No Release. To: guido at beopen.com (Guido van Rossum) Date: Sat, 1 Jul 2000 16:23:16 +0200 (CEST) Cc: python-dev at python.org Guido van Rossum wrote: > > > I'm not convinced this delay is wholly a bad thing. Did Barry ever > > track down the mysterious crashes he was seeing from running the test > > suite? And it's more time to experiment with the garbage collection, > > hunt for SRE bugs, and so forth. > > But that's what beta releases are for, right? The result now is that > fewer people will try out the code than if it were released today, and > the final release will undoubtedly be delayed again. Guido, what about reverting the version number to 2.0a3 ? We're still not in a beta stage, but there *is* a new version ready, which, if not beta, should be an alpha. We're used to see the version bumped a day or two before the release. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Sat Jul 1 18:56:12 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 18:56:12 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> Message-ID: <395E22AC.6BB76041@lemburg.com> Fredrik Lundh wrote: > > when looking through skip's coverage listing, I noted a bug in > SRE: > > #define SRE_UNI_IS_ALNUM(ch) ((ch) < 256 ? isalnum((ch)) : 0) > > this predicate is used for \w when a pattern is compiled using > the "unicode locale" (flag U), and should definitely not use 8-bit > locale stuff. > > however, there's no such thing as a Py_UNICODE_ISALNUM > (or even a Py_UNICODE_ISALPHA). what should I do? how > about using: > > Py_UNICODE_ISLOWER || > Py_UNICODE_ISUPPER || > Py_UNICODE_ISTITLE || > Py_UNICODE_ISDIGIT This will give you all cased chars along with all digits; it ommits the non-cased ones. It's a good start, but probably won't cover the full range of letters + numbers. Perhaps we need another table for isalpha in unicodectype.c ? (Or at least one which defines all non-cased letters.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sat Jul 1 19:13:51 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 19:13:51 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> Message-ID: <028301bfe37f$bb349380$f2a6b5d4@hagrid> mal wrote: > > Py_UNICODE_ISLOWER || > > Py_UNICODE_ISUPPER || > > Py_UNICODE_ISTITLE || > > Py_UNICODE_ISDIGIT > > This will give you all cased chars along with all digits; > it ommits the non-cased ones. but of course... > It's a good start, but probably won't cover the full range > of letters + numbers. > > Perhaps we need another table for isalpha in unicodectype.c ? > (Or at least one which defines all non-cased letters.) +1 from me (SRE needs this, and it doesn't really make much sense to add unicode tables to SRE just because the built-in ones are slightly incomplete...) how about this plan: -- you add a Py_UNICODE_ALPHA to unicodeobject.h asap, which does exactly that (or I can do that, if you prefer). (and maybe even a Py_UNICODE_ALNUM) -- I change SRE to use that asap. -- you, I, or someone else add a better implementation, some other day. From skip at mojam.com Sat Jul 1 20:54:40 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 1 Jul 2000 13:54:40 -0500 (CDT) Subject: [Python-Dev] test coverage summaries - now updated nightly Message-ID: <14686.15984.430156.148785@beluga.mojam.com> I've spent amount as much time on generating automated statement and branch coverage as I can afford for the next few days. At this point I think I have it generating a reasonable facsimile of useful output. A cron job on www.musi-cal.com does the following early each morning (4:45AM Pacific time): make clean cvs update config.status --recheck make python with gcov flags make test > testresults.txt generate coverage pages (lines.html & branches.html) The relevant output files on the web server are http://www.musi-cal.com/~skip/python/Python/dist/src/lines.html http://www.musi-cal.com/~skip/python/Python/dist/src/branches.html http://www.musi-cal.com/~skip/python/Python/dist/src/testresults.txt A couple shell scripts do all the dirty work for now: http://www.musi-cal.com/~skip/python/Python/dist/src/gencoverage http://www.musi-cal.com/~skip/python/Python/dist/src/gencoverage1 I may put an index.html file in there just to provide a little cover for the directory tree. I'll also enable a couple more modules in Modules/Setup. Skip From paul at prescod.net Sat Jul 1 21:00:20 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 14:00:20 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> Message-ID: <395E3FC4.959BB042@prescod.net> "M.-A. Lemburg" wrote: > > ... > > I'd say +0, since the auto-converion can fail if the default > encoding doesn't have room for the tagName characters. > > Either way, I'd still prefer the DOM code to use an explicit > .encode() together with some lossless encoding, e.g. > unicode-escape. If we want to use a hard-coded lossless encoding, we should do so in repr. Rather than having us fix a dozen modules with problems like this, we should fix repr once and for all. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Sat Jul 1 21:02:37 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 14:02:37 -0500 Subject: [Python-Dev] test coverage summaries - now updated nightly References: <14686.15984.430156.148785@beluga.mojam.com> Message-ID: <395E404D.FBD47947@prescod.net> Skip Montanaro wrote: > > I've spent amount as much time on generating automated statement and branch > coverage as I can afford for the next few days. At this point I think I > have it generating a reasonable facsimile of useful output. I may have missed email about this during my email troubles yesterday, but why aren't we doing coverage testing of Python code too? Or am I missing that link? -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From effbot at telia.com Sat Jul 1 21:11:34 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 21:11:34 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> Message-ID: <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> paul wrote: > If we want to use a hard-coded lossless encoding, we should do so in > repr. Rather than having us fix a dozen modules with problems like this, > we should fix repr once and for all. how about allowing str and repr to actually return unicode strings? or in other words: PyObject *res; res = (*v->ob_type->tp_repr)(v); if (res == NULL) return NULL; if (!PyString_Check(res) && !PyUnicode_Check(res)) { PyErr_Format(PyExc_TypeError, "__repr__ returned non-string (type %.200s)", res->ob_type->tp_name); Py_DECREF(res); return NULL; } return res; (strings are strings are strings, etc) From effbot at telia.com Sat Jul 1 21:13:35 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 1 Jul 2000 21:13:35 +0200 Subject: [Python-Dev] test coverage summaries - now updated nightly References: <14686.15984.430156.148785@beluga.mojam.com> <395E404D.FBD47947@prescod.net> Message-ID: <02b601bfe390$774a0a40$f2a6b5d4@hagrid> paul wrote: > Skip Montanaro wrote: > > > > I've spent amount as much time on generating automated statement and branch > > coverage as I can afford for the next few days. At this point I think I > > have it generating a reasonable facsimile of useful output. > > I may have missed email about this during my email troubles yesterday, > but why aren't we doing coverage testing of Python code too? Or am I > missing that link? from Skip's original mail: /.../ I would also like to adjust the regrtest.py stuff to generate statement coverage for .py files using my trace module: http://www.musi-cal.com/~skip/python/trace.py. From mal at lemburg.com Sat Jul 1 21:22:10 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 01 Jul 2000 21:22:10 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> <028301bfe37f$bb349380$f2a6b5d4@hagrid> Message-ID: <395E44E2.63383BC5@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > Py_UNICODE_ISLOWER || > > > Py_UNICODE_ISUPPER || > > > Py_UNICODE_ISTITLE || > > > Py_UNICODE_ISDIGIT > > > > This will give you all cased chars along with all digits; > > it ommits the non-cased ones. > > but of course... > > > It's a good start, but probably won't cover the full range > > of letters + numbers. > > > > Perhaps we need another table for isalpha in unicodectype.c ? > > (Or at least one which defines all non-cased letters.) > > +1 from me (SRE needs this, and it doesn't really make much > sense to add unicode tables to SRE just because the built-in > ones are slightly incomplete...) > > how about this plan: > > -- you add a Py_UNICODE_ALPHA to unicodeobject.h asap, > which does exactly that (or I can do that, if you prefer). > (and maybe even a Py_UNICODE_ALNUM) Ok, I'll add Py_UNICODE_ISALPHA and Py_UNICODE_ISALNUM (first with approximations of the sort you give above and later with true implementations using tables in unicodectype.c) on Monday... gotta run now. > -- I change SRE to use that asap. > > -- you, I, or someone else add a better implementation, > some other day. > > Nice weekend :) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Sat Jul 1 21:45:00 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 14:45:00 -0500 Subject: [Python-Dev] Cygwin report Message-ID: <395E4A3C.74A10F74@prescod.net> Here are instructions for compiling on cygwin. If anyone out there wants to make some tweaks to the build process so that this stuff isn't required anymore, it would be appreciated. ---- Threading does not work: I don't know much about posix threading APIs but I note that the standard Cygwin's pthread.h does not seem to define a pthread_cond_t type. I guess cygwin's pthread is incomplete. There seems to be a more complete one here: http://sunsite.org.uk/gnu/MORE_GNU/cygnus/pthreads-win32/ But I don't care enough to download and try it out. If there is an easy way to turn off threads by default when the platform is cygwin, that would make life a little easier for people using it. --- Sockets: gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./socketmodule.c ./socketmodule.c:146: netinet/tcp.h: No such file or directory (I just commented this module out) --- Then I got an error I haven't seen before /python/python/dist/src/Modules/python.c:12: undefined reference to `Py_Main' collect2: ld returned 1 exit status libpython2.0.a was too small to be real so I deleted it and tried "make" again. It worked. Now I have modules/python.exe mv python ../python mv: cannot move `python' to `../python/python': No such file or directory make[1]: *** [link] Error 1 make[1]: Leaving directory `/python/python/dist/src/Modules' make: *** [python] Error 2 Adding "EXE=exe" to Makefile, Modules\Setup.local and Modules\Makefile does not seem to help. For now, I'll move the file myself. (I'm not clear why it is the "Modules" makefile's responsibility to build and move python.exe anyhow!) --- If you compile using cygwin, do not make the mistake of trying to use ^Z as end of term. It hangs cygwin. Use ^D instead. -- Testing: File "./Lib/random.py", line 84, in ? NV_MAGICCONST = 4*exp(-0.5)/sqrt(2.0) OverflowError: math range error (comment out the line that imports random and try again) --- -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From gmcm at hypernet.com Sat Jul 1 21:58:24 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 1 Jul 2000 15:58:24 -0400 Subject: [Python-Dev] Cygwin report In-Reply-To: <395E4A3C.74A10F74@prescod.net> Message-ID: <1249640994-55813280@hypernet.com> Paul Prescod wrote: > Here are instructions for compiling on cygwin. If anyone out > there wants to make some tweaks to the build process so that this > stuff isn't required anymore, it would be appreciated. ---- > Threading does not work: If you targeted mingw, threading should work. Also should get a smaller, faster exe and one that has a prayer of working with pre-built extensions. last-three-words-optional-ly y'rs - Gordon From skip at mojam.com Sat Jul 1 23:27:37 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 1 Jul 2000 16:27:37 -0500 (CDT) Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: <395E404D.FBD47947@prescod.net> References: <14686.15984.430156.148785@beluga.mojam.com> <395E404D.FBD47947@prescod.net> Message-ID: <14686.25161.513218.84366@beluga.mojam.com> >> I've spent amount as much time on generating automated statement and >> branch coverage as I can afford for the next few days. At this point >> I think I have it generating a reasonable facsimile of useful output. Paul> I may have missed email about this during my email troubles Paul> yesterday, but why aren't we doing coverage testing of Python code Paul> too? Or am I missing that link? Perhap you did miss it. That's next on my list. I have a trace module that will do line counting, but I haven't worked on this thing long enough to get to it. If anyone's game, take a look at http://www.musi-cal.com/~skip/python/trace.py Shouldn't take an awful lot of effort. I just haven't got the time today. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From martin at loewis.home.cs.tu-berlin.de Sun Jul 2 00:43:17 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 2 Jul 2000 00:43:17 +0200 Subject: [Python-Dev] Copyright notice Message-ID: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> On startup, the current CVS python reports (on my system) Python 2.0b1 (#31, Jul 1 2000, 23:13:39) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) Now that the file copyrights are changed, I expect this message to change as well. May I suggest that, instead of adding another line, the two last lines of this message are removed? People who need to find out who holds the copyright to this software still can print sys.copyright. Regards, Martin From paul at prescod.net Sun Jul 2 02:15:57 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 19:15:57 -0500 Subject: [Python-Dev] test coverage summaries - now updated nightly References: <14686.15984.430156.148785@beluga.mojam.com> <395E404D.FBD47947@prescod.net> <14686.25161.513218.84366@beluga.mojam.com> Message-ID: <395E89BD.62EEC94D@prescod.net> Skip Montanaro wrote: > > ... > Perhap you did miss it. That's next on my list. I have a trace module that > will do line counting, but I haven't worked on this thing long enough to get > to it. > > If anyone's game, take a look at > > http://www.musi-cal.com/~skip/python/trace.py Thanks. It's because I've recently been using your trace module that I originally presumed that the coverage testing would be Python coverage testing. I don't yet completely understand the counting mechanism that the tool uses (some numbers look fishy) but overall it is a great boon for testing. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From mhammond at skippinet.com.au Sun Jul 2 02:21:30 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 2 Jul 2000 10:21:30 +1000 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: <20000701065111.Z29590@lyra.org> Message-ID: > > This is exactly what we do. Trents patches are just for the > functions that > > return the underlying handle value as an integer (which is definately a > > useful thing to be able to do!) > > But I don't understand why you want an integer. From the Python > programmer's > standpoint, they just want a handle, right? Yes - but there _are_ functions that return the integer. This is used mainly so the handles can be passed to external programs, or external API functions wrapped via SWIG, etc. The normal case is a "handle object". The "handle object" has auto-close ability. The "handle object" _also_ has the ability to get the raw underlying handle, should the programmer choose. Im afraid you will never convince me this is wrong :-) > Without using PyCObject, we'd need a complete handle type (like > the one in > win32api or wherever). That is exactly what we have. Sorry - I thought "CObject" was a generic term for any C-implemented PyObject. Mark. From paul at prescod.net Sun Jul 2 02:22:23 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 19:22:23 -0500 Subject: [Python-Dev] test coverage summaries - now updated nightly References: <14686.15984.430156.148785@beluga.mojam.com> <395E404D.FBD47947@prescod.net> <02b601bfe390$774a0a40$f2a6b5d4@hagrid> Message-ID: <395E8B3F.39D5C69A@prescod.net> Fredrik Lundh wrote: > > from Skip's original mail: > > /.../ I would also like to > adjust the regrtest.py stuff to generate statement coverage for .py files > using my trace module: http://www.musi-cal.com/~skip/python/trace.py. Thanks. If anyone sent me private mail yesterday (perhaps Fred about xml.*) they should send it again. My ISP's story is that their ISP went belly up without any warning. Grrr. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Sun Jul 2 02:27:13 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 01 Jul 2000 19:27:13 -0500 Subject: [Python-Dev] Repr References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> Message-ID: <395E8C61.E30CA40D@prescod.net> Fredrik Lundh wrote: > > ... > > how about allowing str and repr to actually return > unicode strings? What does that mean for the interactive prompt (repr is used in the repl!). -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From gstein at lyra.org Sun Jul 2 02:34:50 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 1 Jul 2000 17:34:50 -0700 Subject: [Python-Dev] use PyCObject (was: CVS: python/dist/src/PC msvcrtmodule.c,1.4,1.5 _winreg.c,1.5,1.6) In-Reply-To: ; from mhammond@skippinet.com.au on Sun, Jul 02, 2000 at 10:21:30AM +1000 References: <20000701065111.Z29590@lyra.org> Message-ID: <20000701173450.F29590@lyra.org> On Sun, Jul 02, 2000 at 10:21:30AM +1000, Mark Hammond wrote: > > > This is exactly what we do. Trents patches are just for the > > functions that > > > return the underlying handle value as an integer (which is definately a > > > useful thing to be able to do!) > > > > But I don't understand why you want an integer. From the Python > > programmer's > > standpoint, they just want a handle, right? > > Yes - but there _are_ functions that return the integer. This is used > mainly so the handles can be passed to external programs, or external API > functions wrapped via SWIG, etc. All right. I see the usage now. The checkin message didn't have enough context, so I went and look at the darn file. Ignore me :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Sun Jul 2 02:49:53 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 2 Jul 2000 10:49:53 +1000 Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: <14686.15984.430156.148785@beluga.mojam.com> Message-ID: > I've spent amount as much time on generating automated statement > and branch > coverage as I can afford for the next few days. At this point I think I > have it generating a reasonable facsimile of useful output. This is very cool. It would be great if there was some sort of "multi-platform" support, and a merging of the results. My idea here is so modules such as "mmapmodule" can give a better indication of the true test coverage. Your data shows this test at less than 50% - probably mainly due to the #ifdef MS_WIN32 blocks. If we merged a coverage of a Windows run against this same file, we would have an excellent basis for ensuring that the Python test suite did indeed hit as much as we could make it. This is longer term of course. Along the same vein is the Mozilla "tinderbox". It appears they have a job that starts a complete rebuild and test suite run every time a checkin is made to the CVS tree. A Web page shows the progress of each of the platforms (including some nice flaming images when the build or test suite is broken.) http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey Mark. From fdrake at beopen.com Sun Jul 2 05:34:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 1 Jul 2000 23:34:40 -0400 (EDT) Subject: [Python-Dev] Copyright notice In-Reply-To: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> References: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> Message-ID: <14686.47184.792611.628971@cj42289-a.reston1.va.home.com> Martin v. Loewis writes: > Now that the file copyrights are changed, I expect this message to > change as well. May I suggest that, instead of adding another line, > the two last lines of this message are removed? You may! I rather like this idea myself. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sun Jul 2 05:42:28 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 1 Jul 2000 23:42:28 -0400 Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: <395E8B3F.39D5C69A@prescod.net> Message-ID: [Paul Prescod] > ...If anyone sent me private mail yesterday (perhaps Fred about > xml.*) they should send it again. My ISP's story is that their ISP went > belly up without any warning. Grrr. Ditto! My POP3 server at MSN crapped out a little after midnight, and I appear to have lost all mail sent from then until about 2pm. The pipermail archives on python.org stopped archiving around midnight too. My email .forward from tpeters at beopen.com also seems still to be hosed. Was July 1 some "32-bit day" that slipped thru paranoia's cracks <0.9 wink>? From esr at thyrsus.com Sun Jul 2 13:25:24 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 07:25:24 -0400 Subject: [Python-Dev] I have a patch for shlex... Message-ID: <20000702072524.A5592@thyrsus.com> I have a patch for shlex. There has been a lot of discussion of patch management consequent to the SourceForge relocation here that I haven't followed closely. So what's the current protocol for submitting a patch? (The patch gives input sourcing cpp-like semantics for relative paths, rather than making all inclusions relative to the current working directory. Since the source feature has not yet been in a public production release, there are no backwards-compatibility issues.) -- Eric S. Raymond Everything that is really great and inspiring is created by the individual who can labor in freedom. -- Albert Einstein, in H. Eves Return to Mathematical Circles, Boston: Prindle, Weber and Schmidt, 1988. From effbot at telia.com Sun Jul 2 13:30:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 2 Jul 2000 13:30:48 +0200 Subject: [Python-Dev] I have a patch for shlex... References: <20000702072524.A5592@thyrsus.com> Message-ID: <000e01bfe418$fa3e5400$f2a6b5d4@hagrid> eric wrote: > I have a patch for shlex. There has been a lot of discussion of patch > management consequent to the SourceForge relocation here that I haven't > followed closely. So what's the current protocol for submitting a patch? the patch manager is your friend: http://sourceforge.net/patch/?func=addpatch&group_id=5470 bonus points if the summary mentions the module or subsystem name, and you describe/motivate the change either in a comment on the patch details page, or at the top of the patch itself. cheers /F From rob at hooft.net Sun Jul 2 14:02:11 2000 From: rob at hooft.net (Rob W. W. Hooft) Date: Sun, 2 Jul 2000 14:02:11 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml __init__.py,1.1,1.2 In-Reply-To: <200007010458.VAA21264@slayer.i.sourceforge.net> References: <200007010458.VAA21264@slayer.i.sourceforge.net> Message-ID: <14687.12099.151636.943086@temoleh.chem.uu.nl> >>>>> "PP" == Paul Prescod writes: PP> sax -- The Simple API for XML, developed by XML-Dev, led by PP> David Megginson and ported to Python by Lars Marius Garsholm. His name is "Lars Marius Garshol", no m. Rob From esr at thyrsus.com Sun Jul 2 14:26:44 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 08:26:44 -0400 Subject: [Python-Dev] The submit patch form yields a cryptic message Message-ID: <20000702082644.A5758@thyrsus.com> "Patch Uploaded Successfully Added Patch Could Not Send Patch Update" -- Eric S. Raymond The kind of charity you can force out of people nourishes about as much as the kind of love you can buy --- and spreads even nastier diseases. From esr at thyrsus.com Sun Jul 2 14:45:16 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 08:45:16 -0400 Subject: [Python-Dev] Application for developer status Message-ID: <20000702084516.A5777@thyrsus.com> May I have developer status on the SourceForge CVS, please? I maintain two standard-library modules (shlex and netrc) and have been involved with the development of several others (including Cmd, smtp, httplib, and multifile). My only immediate plan for what to do with developer access is to add the browser-launch capability previously discussed on this list. My general interest is in improving the standard class library, especially in the areas of Internet-protocol support (urllib, ftp, telnet, pop, imap, smtp, nntplib, etc.) and mini-language toolkits and frameworks (shlex. netrc, Cmd, ConfigParser). If the Internet-protocol support in the library were broken out as a development category, I would be willing to fill the patch-handler slot for it. -- Eric S. Raymond See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs. -- Dave Barry From fdrake at beopen.com Sun Jul 2 15:51:04 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 2 Jul 2000 09:51:04 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml __init__.py,1.1,1.2 In-Reply-To: <14687.12099.151636.943086@temoleh.chem.uu.nl> References: <200007010458.VAA21264@slayer.i.sourceforge.net> <14687.12099.151636.943086@temoleh.chem.uu.nl> Message-ID: <14687.18632.87208.648581@cj42289-a.reston1.va.home.com> Rob W. W. Hooft writes: > >>>>> "PP" == Paul Prescod writes: > > PP> sax -- The Simple API for XML, developed by XML-Dev, led by > PP> David Megginson and ported to Python by Lars Marius Garsholm. > > His name is "Lars Marius Garshol", no m. Yup! But it looks like Paul was quoting from the xml/__init__.py file docstring, which I wrote. So, I'll have to take credit for the typo. ;( I'll fix it now; thanks for pointing it out! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Sun Jul 2 16:42:01 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 2 Jul 2000 09:42:01 -0500 (CDT) Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: References: <14686.15984.430156.148785@beluga.mojam.com> Message-ID: <14687.21689.32691.579185@beluga.mojam.com> Mark> It would be great if there was some sort of "multi-platform" Mark> support, and a merging of the results. Agreed. We could set up a scheme where people run my scripts on other systems and then mail me the generated files. Windows would be kind of tough though, because my stuff currently relies on gcc/gcov. What facilities does Windows have for coverage testing Mark? Mark> Along the same vein is the Mozilla "tinderbox". It appears they Mark> have a job that starts a complete rebuild and test suite run every Mark> time a checkin is made to the CVS tree. That seems a bit extreme to me, and I don't know about you, but I don't have the spare resources available to "burn" on such a project. skip From paul at prescod.net Sun Jul 2 17:07:49 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 10:07:49 -0500 Subject: [Python-Dev] Application for developer status References: <20000702084516.A5777@thyrsus.com> Message-ID: <395F5AC5.FF11284F@prescod.net> "Eric S. Raymond" wrote: > > ... > > My only immediate plan for what to do with developer access is to add > the browser-launch capability previously discussed on this list. My > general interest is in improving the standard class library, > especially in the areas of Internet-protocol support (urllib, ftp, > telnet, pop, imap, smtp, nntplib, etc.) and mini-language toolkits and > frameworks (shlex. netrc, Cmd, ConfigParser). As an aside: I would be pumpld about getting a generic lexer into the Python distribution. Greg Ewing was working on one and there are various others out there. http://www.cosc.canterbury.ac.nz/~greg/python/Plex/ -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm, by David Berlinski From paul at prescod.net Sun Jul 2 17:10:49 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 10:10:49 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml __init__.py,1.1,1.2 References: <200007010458.VAA21264@slayer.i.sourceforge.net> <14687.12099.151636.943086@temoleh.chem.uu.nl> <14687.18632.87208.648581@cj42289-a.reston1.va.home.com> Message-ID: <395F5B79.5310B93D@prescod.net> "Fred L. Drake, Jr." wrote: > > Yup! But it looks like Paul was quoting from the xml/__init__.py > file docstring, which I wrote. So, I'll have to take credit for the > typo. ;( I'll fix it now; thanks for pointing it out! No, I added that typo. You just made the mistake of naming David Megginson but not Lars. I thought that the latter was closer to our hearts. But not close enough to spell his name right. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From esr at thyrsus.com Sun Jul 2 17:52:31 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 11:52:31 -0400 Subject: [Python-Dev] Application for developer status In-Reply-To: <395F5AC5.FF11284F@prescod.net>; from paul@prescod.net on Sun, Jul 02, 2000 at 10:07:49AM -0500 References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> Message-ID: <20000702115231.A6785@thyrsus.com> Paul Prescod : > As an aside: I would be pumpld about getting a generic lexer into the > Python distribution. Greg Ewing was working on one and there are various > others out there. > http://www.cosc.canterbury.ac.nz/~greg/python/Plex/ Yes, this would be a good thing. I'm also talking with John Aycock about his elegant SPARK toolkit for generating Earley-algorithm parsers. Once that comes out of beta, I would consider it a core-library candidate. -- Eric S. Raymond No matter how one approaches the figures, one is forced to the rather startling conclusion that the use of firearms in crime was very much less when there were no controls of any sort and when anyone, convicted criminal or lunatic, could buy any type of firearm without restriction. Half a century of strict controls on pistols has ended, perversely, with a far greater use of this weapon in crime than ever before. -- Colin Greenwood, in the study "Firearms Control", 1972 From effbot at telia.com Sun Jul 2 18:13:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 2 Jul 2000 18:13:58 +0200 Subject: [Python-Dev] A standard lexer? References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> Message-ID: <001701bfe440$88beaaa0$f2a6b5d4@hagrid> paul wrote: > As an aside: I would be pumpld about getting a generic lexer into the > Python distribution. how about this quick and dirty proposal: - add a new primitive to SRE: (?P#n), where n is a small integer. this primitive sets the match object's "index" variable to n when the engine stumbles upon it. - given a list of "phrases", combine them into a single regular expression like this: (?:phrase1(?P#1))|(?:phrase2(?P#2))|... - apply match repeatedly to the input string. for each match, use the index attribute to figure out what phrase we matched. see below for a slightly larger example. import sre class Scanner: def __init__(self, lexicon): self.lexicon = lexicon p = [] for phrase, action in lexicon: p.append("(?:%s)(?P#%d)" % (phrase, len(p))) self.scanner = sre.compile("|".join(p)) def scan(self, string): result = [] append = result.append match = self.scanner.match i = 0 while 1: m = match(string, i) if not m: break j = m.end() if i == j: break action = self.lexicon[m.index][1] if callable(action): self.match = match action = action(self, m.group()) if action is not None: append(action) i = j return result, string[i:] def s_ident(scanner, token): return token def s_operator(scanner, token): return "operator%s" % token def s_float(scanner, token): return float(token) def s_int(scanner, token): return int(token) scanner = Scanner([ (r"[a-zA-Z_]\w*", s_ident), (r"\d+\.\d*", s_float), (r"\d+", s_int), (r"=|\+|-|\*|/", s_operator), (r"\s+", None), ]) tokens, tail = scanner.scan("sum = 3*foo + 312.50 + bar") print tokens if tail: print "syntax error at", tail ## prints: ## ['sum', 'operator=', 3, 'operator*', 'foo', 'operator+', ## 312.5, 'operator+', 'bar'] From paul at prescod.net Sun Jul 2 18:30:25 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 11:30:25 -0500 Subject: [Python-Dev] Lexing/parsing References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> <20000702115231.A6785@thyrsus.com> Message-ID: <395F6E21.E59ADE6D@prescod.net> "Eric S. Raymond" wrote: > > ... > > Yes, this would be a good thing. I'm also talking with John Aycock about > his elegant SPARK toolkit for generating Earley-algorithm parsers. Once that > comes out of beta, I would consider it a core-library candidate. I pointed one of my co-workers at Spark and he loved the lexer but said that the parser ended up being too slow to be useful. I didn't know enough about the Earley-algorithm to suggest how he could re-organize his grammar to optimize for it. If naive Python programmers cannot generate usable parsers then it may not be appropriate for the standard library. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From fdrake at beopen.com Sun Jul 2 18:33:26 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 2 Jul 2000 12:33:26 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/xml __init__.py,1.1,1.2 In-Reply-To: <395F5B79.5310B93D@prescod.net> References: <200007010458.VAA21264@slayer.i.sourceforge.net> <14687.12099.151636.943086@temoleh.chem.uu.nl> <14687.18632.87208.648581@cj42289-a.reston1.va.home.com> <395F5B79.5310B93D@prescod.net> Message-ID: <14687.28374.752438.191737@cj42289-a.reston1.va.home.com> Paul Prescod writes: > No, I added that typo. You just made the mistake of naming David > Megginson but not Lars. I thought that the latter was closer to our > hearts. But not close enough to spell his name right. Oops! Ok, typo conceeded. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Sun Jul 2 18:38:54 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 11:38:54 -0500 Subject: [Python-Dev] Re: A standard lexer? References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> <001701bfe440$88beaaa0$f2a6b5d4@hagrid> Message-ID: <395F701E.621CACD4@prescod.net> Fredrik Lundh wrote: > >... > > - add a new primitive to SRE: (?P#n), where n is a small integer. > this primitive sets the match object's "index" variable to n when > the engine stumbles upon it. How about an interned string instead? > - given a list of "phrases", combine them into a single regular > expression like this: > > (?:phrase1(?P#1))|(?:phrase2(?P#2))|... Will sre do anything about optimizing common prefixes and so forth? Overall, I like your proposal. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From esr at thyrsus.com Sun Jul 2 18:58:39 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 2 Jul 2000 12:58:39 -0400 Subject: [Python-Dev] Lexing/parsing In-Reply-To: <395F6E21.E59ADE6D@prescod.net>; from paul@prescod.net on Sun, Jul 02, 2000 at 11:30:25AM -0500 References: <20000702084516.A5777@thyrsus.com> <395F5AC5.FF11284F@prescod.net> <20000702115231.A6785@thyrsus.com> <395F6E21.E59ADE6D@prescod.net> Message-ID: <20000702125839.A6935@thyrsus.com> Paul Prescod : > I pointed one of my co-workers at Spark and he loved the lexer but said > that the parser ended up being too slow to be useful. I didn't know > enough about the Earley-algorithm to suggest how he could re-organize > his grammar to optimize for it. If naive Python programmers cannot > generate usable parsers then it may not be appropriate for the standard > library. I'm using a SPARK-generated parser plus shlex in CML2. This does not seem to create a speed problem. -- Eric S. Raymond No kingdom can be secured otherwise than by arming the people. The possession of arms is the distinction between a freeman and a slave. -- "Political Disquisitions", a British republican tract of 1774-1775 From tim_one at email.msn.com Sun Jul 2 18:52:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 2 Jul 2000 12:52:52 -0400 Subject: [Python-Dev] Application for developer status In-Reply-To: <20000702084516.A5777@thyrsus.com> Message-ID: [Eric S. Raymond] > May I have developer status on the SourceForge CVS, please? I maintain > two standard-library modules (shlex and netrc) and have been involved > with the development of several others (including Cmd, smtp, httplib, and > multifile). > > My only immediate plan for what to do with developer access is to add > the browser-launch capability previously discussed on this list. My > general interest is in improving the standard class library, > especially in the areas of Internet-protocol support (urllib, ftp, > telnet, pop, imap, smtp, nntplib, etc.) and mini-language toolkits and > frameworks (shlex. netrc, Cmd, ConfigParser). > > If the Internet-protocol support in the library were broken out as a > development category, I would be willing to fill the patch-handler > slot for it. Eric, I just added you -- go nuts! Don't forget your docstrings, and try hard not to add new modules Guido will hate <0.9 wink -- but new modules do merit python-dev discussion first>. Ah, one more: the layout of the "Edit Member Permissions" admin page on SF is completely screwed up for me, so you got whatever the default permissions are. This looked fine to me a few days ago, but we've added several members since then. Would one of the admins using Netscape please check that page for sane display? I can't yet tell whether it's an IE5 or SF problem. From tim_one at email.msn.com Sun Jul 2 19:21:03 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 2 Jul 2000 13:21:03 -0400 Subject: [Python-Dev] A standard lexer? In-Reply-To: <001701bfe440$88beaaa0$f2a6b5d4@hagrid> Message-ID: [Paul Prescod] > As an aside: I would be pumped about getting a generic lexer into the > Python distribution. [Fredrik Lundh] > how about this quick and dirty proposal: > > - add a new primitive to SRE: (?P#n), where n is a small integer. > this primitive sets the match object's "index" variable to n when > the engine stumbles upon it. Note that the lack of "something like this" is one of the real barriers to speeding SPARK's lexing, and the speed of a SPARK lexer now (well, last I looked into this) can be wildly dependent on the order in which you define your lexing methods (partly because there's no way to figure out which lexing method matched without iterating through all the groups to find the first that isn't None). The same kind of irritating iteration is needed in IDLE and pyclbr too (disguised as unrolled if/elif/elif/... chains), and in tokenize.py (there *really* disguised in a convoluted way, by doing more string tests on the matched substring to *infer* which of the regexp pattern chunks must have matched). OTOH, arbitrary small integers are not Pythonic. Your example *generates* them in order to guarantee they're unique, which is a bad sign (it implies users can't do this safely by hand, and I believe that's the truth of it too): > for phrase, action in lexicon: > p.append("(?:%s)(?P#%d)" % (phrase, len(p))) How about instead enhancing existing (?Ppattern) notation, to set a new match object attribute to name if & when pattern matches? Then arbitrary info associated with a named pattern can be gotten at via dicts via the pattern name, & the whole mess should be more readable. On the third hand, I'm really loathe to add more gimmicks to stinking regexps. But, on the fourth hand, no alternative yet has proven popular enough to move away from those suckers. if-you-can't-get-a-new-car-at-least-tune-up-the-old-one-ly y'rs - tim From dan at cgsoftware.com Sun Jul 2 19:40:04 2000 From: dan at cgsoftware.com (Daniel Berlin) Date: Sun, 2 Jul 2000 10:40:04 -0700 (PDT) Subject: [Python-Dev] A standard lexer? In-Reply-To: Message-ID: > > > On the third hand, I'm really loathe to add more gimmicks to stinking > regexps. But, on the fourth hand, no alternative yet has proven popular > enough to move away from those suckers. > > if-you-can't-get-a-new-car-at-least-tune-up-the-old-one-ly y'rs - tim > > > Right. Actually, if it helps, i'm working on porting re2c to python. Because it was written properly, it's rather simple (in fact, i've only needed to modify one file, add some if's to ee if we want python generation, and output the python code instead of c code) The lexers it generates for c/C++ are much faster than flex lexers, because they are directly coded. I haven't benchmarked it against SPARK yet, but i would imagine it would blow it away, for the same reason it blows away flex. --Dan From effbot at telia.com Sun Jul 2 19:55:11 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 2 Jul 2000 19:55:11 +0200 Subject: [Python-Dev] A standard lexer? References: Message-ID: <002901bfe44e$af624be0$f2a6b5d4@hagrid> tim wrote: > OTOH, arbitrary small integers are not Pythonic. Your example *generates* > them in order to guarantee they're unique, which is a bad sign. this feature itself has been on the todo list for quite a while; the (?P#n) syntax just exposes the inner workings (the "small integer" is simply some- thing that fits in a SRE_CODE word). as you say, it's probably a good idea to hide it a bit better... > > for phrase, action in lexicon: > > p.append("(?:%s)(?P#%d)" % (phrase, len(p))) > > How about instead enhancing existing (?Ppattern) notation, to set a > new match object attribute to name if & when pattern matches? Then > arbitrary info associated with a named pattern can be gotten at via dicts > via the pattern name, & the whole mess should be more readable. good idea. and fairly easy to implement, I think. on the other hand, that means creating more real groups. and groups don't come for free... maybe this functionality should only be available through the scanner class? it can compile the patterns separately, and combine the data structures before passing them to the code generator. a little bit more code to write, but less visible oddities. > On the third hand, I'm really loathe to add more gimmicks to stinking > regexps. But, on the fourth hand, no alternative yet has proven popular > enough to move away from those suckers. > > if-you-can't-get-a-new-car-at-least-tune-up-the-old-one-ly y'rs - tim hey, SRE is a new car. same old technology, though. only smaller ;-) btw, if someone wants to play with this, I just checked in a new SRE snapshot. a little bit of documentation can be found here: http://hem.passagen.se/eff/2000_07_01_bot-archive.htm#416954 From pingster at ilm.com Sun Jul 2 22:54:58 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Sun, 2 Jul 2000 13:54:58 -0700 (PDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000701124303.A31955@thyrsus.com> Message-ID: Skip Montanaro : > My guess is that -tt triggered a SyntaxError (maybe we should create an > IndentationError that is a subclass of SyntaxError?) Yes! +1! -- ?!ng From paul at prescod.net Sun Jul 2 23:09:24 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 02 Jul 2000 16:09:24 -0500 Subject: [Python-Dev] Sorry. No Release. References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> Message-ID: <395FAF84.87B1FD17@prescod.net> Skip Montanaro wrote: > > ... > > My guess is that -tt triggered a SyntaxError (maybe we should create an > IndentationError that is a subclass of SyntaxError?) +1 That would be great for newbies! -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From effbot at telia.com Mon Jul 3 00:35:28 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 3 Jul 2000 00:35:28 +0200 Subject: [Python-Dev] A standard lexer? References: Message-ID: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid> tim wrote: > > for phrase, action in lexicon: > > p.append("(?:%s)(?P#%d)" % (phrase, len(p))) > > How about instead enhancing existing (?Ppattern) notation, to set a > new match object attribute to name if & when pattern matches? Then > arbitrary info associated with a named pattern can be gotten at via dicts > via the pattern name, & the whole mess should be more readable. I just added "lastindex" and "lastgroup" attributes to the match object. "lastindex" is the integer index of the last matched capturing group, "lastgroup" the corresponding name (or None, if the group didn't have a name). both attributes are None if no group were matched. From mal at lemburg.com Mon Jul 3 00:44:55 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 00:44:55 +0200 Subject: [Python-Dev] A standard lexer? References: Message-ID: <395FC5E7.DD0251A2@lemburg.com> Daniel Berlin wrote: > > Actually, if it helps, i'm working on porting re2c to python. Pointers ? > Because it was written properly, it's rather simple (in fact, i've only > needed to modify one file, add some if's to ee if we want python > generation, and output the python code instead of c code) > The lexers it generates for c/C++ are much faster than flex lexers, > because they are directly coded. > I haven't benchmarked it against SPARK yet, but i would imagine it would > blow it away, for the same reason it blows away flex. Perhaps you should also look at the tagging engine in mxTextTools (you know where...) ?! It's very low-level, but it makes nice target for optimizing parser generators since it provides a Python interface to raw C speed. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From dberlin at cygnus.com Mon Jul 3 00:49:37 2000 From: dberlin at cygnus.com (Daniel Berlin) Date: 02 Jul 2000 18:49:37 -0400 Subject: [Python-Dev] A standard lexer? In-Reply-To: "M.-A. Lemburg"'s message of "Mon, 03 Jul 2000 00:44:55 +0200" References: <395FC5E7.DD0251A2@lemburg.com> Message-ID: <86zoo0du66.fsf@dan2.cygnus.com> "M.-A. Lemburg" writes: > Daniel Berlin wrote: > > > > Actually, if it helps, i'm working on porting re2c to python. > > Pointers ? http://www.tildeslash.org/re2c/index.html > > > Because it was written properly, it's rather simple (in fact, i've only > > needed to modify one file, add some if's to ee if we want python > > generation, and output the python code instead of c code) > > The lexers it generates for c/C++ are much faster than flex lexers, > > because they are directly coded. > > I haven't benchmarked it against SPARK yet, but i would imagine it would > > blow it away, for the same reason it blows away flex. > > Perhaps you should also look at the tagging engine in > mxTextTools (you know where...) ?! It's very low-level, but > it makes nice target for optimizing parser generators since > it provides a Python interface to raw C speed. > re2c is simply a scanner generator, not a parser. --Dan From tim_one at email.msn.com Mon Jul 3 01:22:31 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 2 Jul 2000 19:22:31 -0400 Subject: [Python-Dev] (harmless?) CVS error on SourceForge Message-ID: Recent commit had an error msg at the end; don't remember enough about CVS to recall whether it matters; anyone else? C:\pysrc>cvs commit python/dist/src/PC/example_nt CVS.EXE commit: Examining python/dist/src/PC/example_nt Password: Checking in python/dist/src/PC/example_nt/example.dsp; /cvsroot/python/python/dist/src/PC/example_nt/example.dsp,v <-- example.dsp new revision: 1.3; previous revision: 1.2 done Checking in python/dist/src/PC/example_nt/example.dsw; /cvsroot/python/python/dist/src/PC/example_nt/example.dsw,v <-- example.dsw new revision: 1.2; previous revision: 1.1 done Removing python/dist/src/PC/example_nt/example.mak; /cvsroot/python/python/dist/src/PC/example_nt/example.mak,v <-- example.mak new revision: delete; previous revision: 1.3 done Checking in python/dist/src/PC/example_nt/readme.txt; /cvsroot/python/python/dist/src/PC/example_nt/readme.txt,v <-- readme.txt new revision: 1.7; previous revision: 1.6 done Running syncmail... Mailing python-checkins at python.org... ...syncmail done. cvs [diff aborted]: no such tag NONE C:\pysrc> From akuchlin at cnri.reston.va.us Mon Jul 3 02:57:55 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 2 Jul 2000 20:57:55 -0400 Subject: [Python-Dev] A standard lexer? In-Reply-To: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid>; from effbot@telia.com on Mon, Jul 03, 2000 at 12:35:28AM +0200 References: <00f201bfe475$d5e00c40$f2a6b5d4@hagrid> Message-ID: <20000702205755.A7533@newcnri.cnri.reston.va.us> Might it be worth taking the lexer discussion to the String-SIG? The more public the discussion, the better, and it is why the SIG is there... --amk From fdrake at beopen.com Mon Jul 3 08:15:26 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 02:15:26 -0400 (EDT) Subject: [Python-Dev] (harmless?) CVS error on SourceForge In-Reply-To: References: Message-ID: <14688.12158.189752.140235@cj42289-a.reston1.va.home.com> Tim Peters writes: > Recent commit had an error msg at the end; don't remember enough about CVS > to recall whether it matters; anyone else? ... > cvs [diff aborted]: no such tag NONE This is harmless, and only affects the message sent to python-checkins. It is generated by the "cvs diff" executed by the syncmail script. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Mon Jul 3 08:33:37 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 02:33:37 -0400 (EDT) Subject: [Python-Dev] Application for developer status In-Reply-To: References: <20000702084516.A5777@thyrsus.com> Message-ID: <14688.13249.310796.64561@cj42289-a.reston1.va.home.com> Tim Peters writes: > Ah, one more: the layout of the "Edit Member Permissions" admin page on SF > is completely screwed up for me, so you got whatever the default permissions > are. This looked fine to me a few days ago, but we've added several members > since then. > > Would one of the admins using Netscape please check that page for sane > display? I can't yet tell whether it's an IE5 or SF problem. It looks fine to me -- you may be plagued by a slow network connection. ;) I've updated Eric's permissions so he can use the patch manager properly. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mhammond at skippinet.com.au Mon Jul 3 08:28:02 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 3 Jul 2000 16:28:02 +1000 Subject: [Python-Dev] test coverage summaries - now updated nightly In-Reply-To: <14687.21689.32691.579185@beluga.mojam.com> Message-ID: [Skip] > Mark> It would be great if there was some sort of "multi-platform" > Mark> support, and a merging of the results. > Agreed. We could set up a scheme where people run my scripts on other > systems and then mail me the generated files. Windows would be kind of > tough though, because my stuff currently relies on gcc/gcov. What > facilities does Windows have for coverage testing Mark? There is a source-profiler, but Im not sure how deep it lets you into the data. I'll look into this at some stage. Or some people are working towards gcc makefiles for windows - maybe that is a better way to go for this? Mark> Along the same vein is the Mozilla "tinderbox". It ... > That seems a bit extreme to me, and I don't know about you, but > I don't have > the spare resources available to "burn" on such a project. I think that the tinderbox code is open-source too! I agree this is a bit extreme, but I do believe something like it would be useful, and need not be too hard. As more and more checkins happen from different people, the chances of platform-breakage would seem to be quite high. A Python script that periodically scanned CVS for changes, then executed a build and did something pretty simple with the log wouldnt be too hard. However, I do agree we should wait until it is _nearly_ a problem (as opposed to _is_ a problem :-) Mark. From martin at loewis.home.cs.tu-berlin.de Mon Jul 3 09:29:23 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 3 Jul 2000 09:29:23 +0200 Subject: [Python-Dev] Minidom and Unicode Message-ID: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> > the repository has been updated. In what way? Python 2.0b1 (#1, Jul 3 2000, 09:12:07) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> class X: ... def __repr__(self): ... if hasattr(self,"u"): ... return u'\u30b9' ... else: ... return u'hallo' ... >>> x=X() >>> x hallo >>> x.u=1 >>> x Traceback (most recent call last): File "", line 1, in ? TypeError: __repr__ returned non-string (type unicode) > no need to change minidom. The need still appears to exist, both for minidom.Element (KATAKANA LETTER SU is a letter, and thus a valid tag name), as well as minidom.Text. A string is a string is a string. Regards, Martin From mal at lemburg.com Mon Jul 3 10:35:51 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 10:35:51 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> Message-ID: <39605067.DCC2B968@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > I'd say +0, since the auto-converion can fail if the default > > encoding doesn't have room for the tagName characters. > > > > Either way, I'd still prefer the DOM code to use an explicit > > .encode() together with some lossless encoding, e.g. > > unicode-escape. > > If we want to use a hard-coded lossless encoding, we should do so in > repr. Rather than having us fix a dozen modules with problems like this, > we should fix repr once and for all. I think it's ok to auto-convert to the default encoding as intermediate solution, but the applications wanting to return Unicode as __repr__ or __str__ should really use .encode() to make sure the output that is produces matches their (or their user's) expectations. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 3 10:43:59 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 10:43:59 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> Message-ID: <3960524F.F6C2D4A8@lemburg.com> Fredrik Lundh wrote: > > paul wrote: > > > If we want to use a hard-coded lossless encoding, we should do so in > > repr. Rather than having us fix a dozen modules with problems like this, > > we should fix repr once and for all. > > how about allowing str and repr to actually return > unicode strings? > > or in other words: > > PyObject *res; > res = (*v->ob_type->tp_repr)(v); > if (res == NULL) > return NULL; > if (!PyString_Check(res) && !PyUnicode_Check(res)) { > PyErr_Format(PyExc_TypeError, > "__repr__ returned non-string (type %.200s)", > res->ob_type->tp_name); > Py_DECREF(res); > return NULL; > } > return res; > > (strings are strings are strings, etc) -1: This breaks code, since it is expected that PyObject_Str() returns a string object. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Mon Jul 3 10:53:52 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 04:53:52 -0400 (EDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <395FAF84.87B1FD17@prescod.net> References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> Message-ID: <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> Skip Montanaro wrote: > My guess is that -tt triggered a SyntaxError (maybe we should create an > IndentationError that is a subclass of SyntaxError?) Paul Prescod writes: > +1 > > That would be great for newbies! Yes, but the name is confusing, because it isn't raised for every sort of indentation error if it's only used for tab/space problems: try: 1/0 1/0 finally: pass still would raise SyntaxError. Should that raise an IndentationError as well? Or should IndentationError be named something else? (Just adding IndentationError for -tt isn't hard, I have a preliminary patch for that now. Adding it for the case above looks harder.) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr at thyrsus.com Mon Jul 3 11:20:52 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 05:20:52 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <14688.21664.958984.801457@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 03, 2000 at 04:53:52AM -0400 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> Message-ID: <20000703052052.E11175@thyrsus.com> Fred L. Drake, Jr. : > > Skip Montanaro wrote: > > My guess is that -tt triggered a SyntaxError (maybe we should create an > > IndentationError that is a subclass of SyntaxError?) > > Paul Prescod writes: > > +1 > > > > That would be great for newbies! > > Yes, but the name is confusing, because it isn't raised for every > sort of indentation error if it's only used for tab/space problems: > > try: > 1/0 > 1/0 > finally: > pass > > still would raise SyntaxError. Should that raise an IndentationError > as well? Or should IndentationError be named something else? WhitespaceError -- Eric S. Raymond Morality is always the product of terror; its chains and strait-waistcoats are fashioned by those who dare not trust others, because they dare not trust themselves, to walk in liberty. -- Aldous Huxley From effbot at telia.com Mon Jul 3 11:27:55 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 3 Jul 2000 11:27:55 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> <3960524F.F6C2D4A8@lemburg.com> Message-ID: <004001bfe4d0$f91b2720$f2a6b5d4@hagrid> mal wrote: > > (strings are strings are strings, etc) > > -1: This breaks code, since it is expected that PyObject_Str() > returns a string object. unicode strings are also strings, right? the interesting question here is to figure out who's expecting that, and figure out if that code can be changed. From mal at lemburg.com Mon Jul 3 11:36:18 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 11:36:18 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <02a801bfe390$2e93d7e0$f2a6b5d4@hagrid> <3960524F.F6C2D4A8@lemburg.com> <004001bfe4d0$f91b2720$f2a6b5d4@hagrid> Message-ID: <39605E92.492D1F3E@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > (strings are strings are strings, etc) > > > > -1: This breaks code, since it is expected that PyObject_Str() > > returns a string object. > > unicode strings are also strings, right? Well, I usually refer to them as Unicode objects to make it clear that they are different from the standard notion of a string in Python. If we were to use classes for Python basic type I would make them have the same base class though... > the interesting question here is to figure out who's expecting that, > and figure out if that code can be changed. We might proceed in that direction for Py3K, but I don't think it's a good idea to make such changes just now. IMHO, it's better to provide other means of getting at the Unicode data, e.g. instances could provide a __unicode__ method hook which the builtin unicode() queries and then uses to convert to Unicode. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Mon Jul 3 11:54:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 3 Jul 2000 11:54:25 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> Message-ID: <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> martin wrote: > In what way? > > Python 2.0b1 (#1, Jul 3 2000, 09:12:07) [GCC 2.95.2 19991024 (release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> class X: > ... def __repr__(self): > ... if hasattr(self,"u"): > ... return u'\u30b9' > ... else: > ... return u'hallo' > ... > >>> x=X() > >>> x > hallo > >>> x.u=1 > >>> x > Traceback (most recent call last): > File "", line 1, in ? > TypeError: __repr__ returned non-string (type unicode) > > > no need to change minidom. > > The need still appears to exist, both for minidom.Element (KATAKANA > LETTER SU is a letter, and thus a valid tag name), as well as > minidom.Text. A string is a string is a string. works for me: $ export LANG=posix.utf8 $ python >>> import sys >>> sys.getdefaultencoding() 'utf8' >>> class X: ... def __repr__(self): ... return u"u\30b9" ... >>> x = X() >>> x ?,? (or to put it another way, I'm not sure the repr/str fix is the real culprit here...) From mal at lemburg.com Mon Jul 3 12:38:04 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 12:38:04 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> <028301bfe37f$bb349380$f2a6b5d4@hagrid> <395E44E2.63383BC5@lemburg.com> Message-ID: <39606D0C.CB3F18FD@lemburg.com> "M.-A. Lemburg" wrote: > > Fredrik Lundh wrote: > > how about this plan: > > > > -- you add a Py_UNICODE_ALPHA to unicodeobject.h asap, > > which does exactly that (or I can do that, if you prefer). > > (and maybe even a Py_UNICODE_ALNUM) > > Ok, I'll add Py_UNICODE_ISALPHA and Py_UNICODE_ISALNUM > (first with approximations of the sort you give above and > later with true implementations using tables in unicodectype.c) > on Monday... gotta run now. > > > -- I change SRE to use that asap. > > > > -- you, I, or someone else add a better implementation, > > some other day. I've just looked into this... the problem here is what to consider as being "alpha" and what "numeric". I could add two new tables for the characters with category 'Lo' (other letters, not cased) and 'Lm' (letter modifiers) to match all letters in the Unicode database, but those tables have some 5200 entries (note that there are only 804 lower case letters and 686 upper case ones). Note that there seems to be no definition of what is to be considered alphanumeric in Unicode. The only quote I found was in http://www.w3.org/TR/xslt#convert which says: """ Alphanumeric means any character that has a Unicode category of Nd, Nl, No, Lu, Ll, Lt, Lm or Lo. """ Here's what the glibc has to say about these chars: /* Test for any wide character for which `iswupper' or 'iswlower' is true, or any wide character that is one of a locale-specific set of wide-characters for which none of `iswcntrl', `iswdigit', `iswpunct', or `iswspace' is true. */ extern int iswalpha __P ((wint_t __wc)); Question: Should I go ahead and add the Lo and Lm tables to unicodectype.c ? Pros: standards confrom Cons: huge in size -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From martin at loewis.home.cs.tu-berlin.de Mon Jul 3 15:08:56 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 3 Jul 2000 15:08:56 +0200 Subject: [Python-Dev] Minidom and Unicode In-Reply-To: <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> (effbot@telia.com) References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> Message-ID: <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> > works for me: > > $ export LANG=posix.utf8 [...] > (or to put it another way, I'm not sure the repr/str fix is > the real culprit here...) I think it is. My understanding is that repr always returns something printable - if possible even something that can be passed to eval. I'd certainly expect that a minidom Node can be printed always, no matter what the default encoding is. Consequently, I'd prefer if the conversion uses some fixed, repr-style encoding, eg. unicode-escape (just as repr of a unicode object does). If it is deemed unacceptable to put this into the interpreter proper, I'd prefer if minidom is changed to allow representation of all Nodes on all systems. Regards, Martin From esr at thyrsus.com Mon Jul 3 15:56:00 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 09:56:00 -0400 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? Message-ID: <20000703095600.A12141@thyrsus.com> I have a valid ssh account on SourceForge. I follow the directions on the Python CVS page and get this: Script started on Mon Jul 3 09:50:42 2000 snark:~/WWW/python$ echo $CVS_RSH /usr/bin/ssh snark:~/WWW/python$ cvs -z3 -desr at cvs.python.sourceforge.net:/cvsroot/python co python esr at cvs.python.sourceforge.net's password: cvs checkout: warning: unrecognized response `' from cvs server cvs checkout: warning: unrecognized response `Welcome to cvs1.sourceforge.net' from cvs server cvs checkout: warning: unrecognized response `' from cvs server cvs checkout: warning: unrecognized response `This is a restricted Shell Account' from cvs server cvs checkout: warning: unrecognized response `You cannot execute anything here.' from cvs server cvs checkout: warning: unrecognized response `' from cvs server cvs [checkout aborted]: end of file from server (consult above messages if any) snark:~/WWW/python$ exit Script done on Mon Jul 3 09:51:23 2000 -- Eric S. Raymond Idealism is the noble toga that political gentlemen drape over their will to power. -- Aldous Huxley From root at theporch.com Mon Jul 3 15:46:00 2000 From: root at theporch.com (Phillip Porch) Date: Mon, 3 Jul 2000 08:46:00 -0500 (CDT) Subject: [Python-Dev] Typo in pty.py Message-ID: I was compiling and testing the current snapshot of python (current as of 7:00 AM CDT 7/3/00) and found that test_pty failed. Here is the output of the test. [sco root-tty01 src] ./python Lib/test/test_pty.py Calling master_open() Got master_fd '6', slave_name '/dev/ttyp1' Calling slave_open('/dev/ttyp1') Got slave_fd '7' Writing to slave_fd I wish to buy a fish license. For my pet fish, Eric. calling pty.fork() Traceback (most recent call last): File "Lib/test/test_pty.py", line 50, in ? pid, master_fd = pty.fork() File "./Lib/pty.py", line 95, in fork master_fd, slave_fd = openpty() File "./Lib/pty.py", line 28, in openpty slave_fd = _slave_open(slave_name) NameError: _slave_open I believe there is a typo on line 28 in Lib/pty.py... the call should not be _slave_open but slave_open. I made that change and the test ran fine. -- Phillip P. Porch NIC:PP1573 finger for http://www.theporch.com UTM - 16 514546E 3994565N PGP key From gward at mems-exchange.org Mon Jul 3 15:50:16 2000 From: gward at mems-exchange.org (Greg Ward) Date: Mon, 3 Jul 2000 09:50:16 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000703052052.E11175@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 03, 2000 at 05:20:52AM -0400 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> <20000703052052.E11175@thyrsus.com> Message-ID: <20000703095016.A24655@ludwig.cnri.reston.va.us> [Fred L. Drake, Jr. ] > Yes, but the name is confusing, because it isn't raised for every > sort of indentation error if it's only used for tab/space problems: [Eric S. Raymond] > WhitespaceError How about TabError? Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From esr at thyrsus.com Mon Jul 3 16:04:05 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 10:04:05 -0400 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000703095016.A24655@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Mon, Jul 03, 2000 at 09:50:16AM -0400 References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> <20000703052052.E11175@thyrsus.com> <20000703095016.A24655@ludwig.cnri.reston.va.us> Message-ID: <20000703100405.B12176@thyrsus.com> Greg Ward : > [Fred L. Drake, Jr. ] > > Yes, but the name is confusing, because it isn't raised for every > > sort of indentation error if it's only used for tab/space problems: > > [Eric S. Raymond] > > WhitespaceError > > How about TabError? Not a big deal to me which gets used. -- Eric S. Raymond The United States is in no way founded upon the Christian religion -- George Washington & John Adams, in a diplomatic message to Malta. From fredrik at pythonware.com Mon Jul 3 16:01:17 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 3 Jul 2000 16:01:17 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> Message-ID: <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> martin wrote: > > > > $ export LANG=posix.utf8 > [...] > > (or to put it another way, I'm not sure the repr/str fix is > > the real culprit here...) > > I think it is. My understanding is that repr always returns something > printable - if possible even something that can be passed to eval. I'd > certainly expect that a minidom Node can be printed always, no matter > what the default encoding is. > > Consequently, I'd prefer if the conversion uses some fixed, repr-style > encoding, eg. unicode-escape (just as repr of a unicode object does). oh, you're right. repr should of course use unicode-escape, not the default encoding. my fault. I'll update the repository soonish. > If it is deemed unacceptable to put this into the interpreter proper, > I'd prefer if minidom is changed to allow representation of all Nodes > on all systems. the reason for this patch was to avoid forcing everyone to deal with this in their own code, by providing some kind of fallback behaviour. From fdrake at beopen.com Mon Jul 3 16:23:34 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 10:23:34 -0400 (EDT) Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000703095600.A12141@thyrsus.com> References: <20000703095600.A12141@thyrsus.com> Message-ID: <14688.41446.716190.904222@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > I have a valid ssh account on SourceForge. I follow the directions on the > Python CVS page and get this: This looks like SourceForge is having problems. Have you verified that you've installed your public key? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Mon Jul 3 17:35:18 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 17:35:18 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> Message-ID: <3960B2B6.9290F932@lemburg.com> Fredrik Lundh wrote: > > martin wrote: > > > > > > $ export LANG=posix.utf8 > > [...] > > > (or to put it another way, I'm not sure the repr/str fix is > > > the real culprit here...) > > > > I think it is. My understanding is that repr always returns something > > printable - if possible even something that can be passed to eval. I'd > > certainly expect that a minidom Node can be printed always, no matter > > what the default encoding is. > > > > Consequently, I'd prefer if the conversion uses some fixed, repr-style > > encoding, eg. unicode-escape (just as repr of a unicode object does). > > oh, you're right. repr should of course use unicode-escape, not > the default encoding. my fault. > > I'll update the repository soonish. I'd rather have some more discussion about this... IMHO, all auto-conversions should use the default encoding. The main point here is not to confuse the user with even more magic happening under the hood. If the programmer knows that he'll have to deal with Unicode then he should make sure that the proper encoding is used and document it that way, e.g. use unicode-escape for Minidom's __repr__ methods. BTW, any takers for __unicode__ to complement __str__ ? > > If it is deemed unacceptable to put this into the interpreter proper, > > I'd prefer if minidom is changed to allow representation of all Nodes > > on all systems. > > the reason for this patch was to avoid forcing everyone to deal with > this in their own code, by providing some kind of fallback behaviour. That's what your patch does; I don't see a reason to change it :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From esr at thyrsus.com Mon Jul 3 17:53:36 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 11:53:36 -0400 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <14688.41446.716190.904222@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 03, 2000 at 10:23:34AM -0400 References: <20000703095600.A12141@thyrsus.com> <14688.41446.716190.904222@cj42289-a.reston1.va.home.com> Message-ID: <20000703115336.C12315@thyrsus.com> Fred L. Drake, Jr. : > > Eric S. Raymond writes: > > I have a valid ssh account on SourceForge. I follow the directions on the > > Python CVS page and get this: > > This looks like SourceForge is having problems. Have you verified > that you've installed your public key? Yes, I can ssh to my SouurceForge account with no problems. -- Eric S. Raymond When all government ...in little as in great things... shall be drawn to Washington as the center of all power; it will render powerless the checks provided of one government on another, and will become as venal and oppressive as the government from which we separated." -- Thomas Jefferson, 1821 Don't think of it as `gun control', think of it as `victim disarmament'. If we make enough laws, we can all be criminals. From effbot at telia.com Mon Jul 3 18:00:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 3 Jul 2000 18:00:19 +0200 Subject: [Python-Dev] FYI: Perl Unicode Handling HOWTO Message-ID: <006401bfe508$9ebf4ee0$f2a6b5d4@hagrid> for the curious: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-07/msg00004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Unicode Handling HOWTO.url Type: application/octet-stream Size: 224 bytes Desc: not available URL: From paul at prescod.net Mon Jul 3 18:15:46 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 11:15:46 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> Message-ID: <3960BC32.CBBF3D6D@prescod.net> "M.-A. Lemburg" wrote: > > ... > > IMHO, all auto-conversions should use the default encoding. The > main point here is not to confuse the user with even more magic > happening under the hood. I don't see anything confusing about having unicode-escape be the appropriate escape used for repr. Maybe we need to differentiate between lossless and lossy encodings. If the default encoding is lossless then repr could use it. Otherwise it could use unicode-escape. Anyhow, why would it be wrong for Fredrick to hard-code an encoding in repr but right for me to hard-code one in minidom? Users should not need to comb through the hundreds of modules in the library figuring out what kind of Unicode handling they should expect. It should be as centralized as possible. > If the programmer knows that he'll have to deal with Unicode > then he should make sure that the proper encoding is used > and document it that way, e.g. use unicode-escape for Minidom's > __repr__ methods. One of the major goals of our current Unicode auto-conversion "compromise" is that modules like xmllib and minidom should work with Unicode out of the box without any special enhancements. According to Guido, that's the primary reason we have Unicode auto-conversions at all. http://www.python.org/pipermail/i18n-sig/2000-May/000173.html I'm going to fight very hard to make basic Unicode support in Python modules "just work" without a bunch of internationalization knowledge from the programmer. __repr__ is pretty basic. > > the reason for this patch was to avoid forcing everyone to deal with > > this in their own code, by providing some kind of fallback behaviour. > > That's what your patch does; I don't see a reason to change it :-) If you're still proposing that I should deal with it in a particular module's domain-specific code then the patch isn't done yet! -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Mon Jul 3 18:21:26 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 11:21:26 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <39605067.DCC2B968@lemburg.com> Message-ID: <3960BD86.A10797E3@prescod.net> "M.-A. Lemburg" wrote: > > ... > > I think it's ok to auto-convert to the default encoding > as intermediate solution, but the applications wanting to > return Unicode as __repr__ or __str__ should really > use .encode() to make sure the output that is produces > matches their (or their user's) expectations. If my users have expectations, I don't know them. I could allow them to tell me what encoding to use, but surely they would rather do that in a Python-wide fashion. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Mon Jul 3 18:24:41 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 11:24:41 -0500 Subject: [Python-Dev] Sorry. No Release. References: <200007010335.WAA29653@cj20424-a.reston1.va.home.com> <20000701082829.C2345@newcnri.cnri.reston.va.us> <14686.2910.855580.146653@anthem.concentric.net> <14686.6962.530478.967290@beluga.mojam.com> <395FAF84.87B1FD17@prescod.net> <14688.21664.958984.801457@cj42289-a.reston1.va.home.com> Message-ID: <3960BE49.CAB2776B@prescod.net> "Fred L. Drake, Jr." wrote: > > ... > > (Just adding IndentationError for -tt isn't hard, I have a > preliminary patch for that now. Adding it for the case above looks > harder.) I think that in a perfect world, IndentationError would apply to both of them. Maybe TabError would be a subclass of IndentationError. You could set up the hierarchy that way without actually implementing the code that recognizes "ordinary" indentation errors. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From mal at lemburg.com Mon Jul 3 18:37:12 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 18:37:12 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> <3960BC32.CBBF3D6D@prescod.net> Message-ID: <3960C138.85D9B36A@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > IMHO, all auto-conversions should use the default encoding. The > > main point here is not to confuse the user with even more magic > > happening under the hood. > > I don't see anything confusing about having unicode-escape be the > appropriate escape used for repr. Maybe we need to differentiate between > lossless and lossy encodings. If the default encoding is lossless then > repr could use it. Otherwise it could use unicode-escape. Simply because auto-conversion should use one single encoding throughout the code. > Anyhow, why would it be wrong for Fredrick to hard-code an encoding in > repr but right for me to hard-code one in minidom? Because hardcoding the encoding into the core Python API touches all programs. Hardcoded encodings should be userland options whereever possible. Besides, we're talking about __repr__ which is mainly a debug tool and doesn't affect program flow or interfacing in any way. The format used is a userland decision and the encoding used for it is too. > Users should not need > to comb through the hundreds of modules in the library figuring out what > kind of Unicode handling they should expect. It should be as centralized > as possible. True. > > If the programmer knows that he'll have to deal with Unicode > > then he should make sure that the proper encoding is used > > and document it that way, e.g. use unicode-escape for Minidom's > > __repr__ methods. > > One of the major goals of our current Unicode auto-conversion > "compromise" is that modules like xmllib and minidom should work with > Unicode out of the box without any special enhancements. According to > Guido, that's the primary reason we have Unicode auto-conversions at > all. > > http://www.python.org/pipermail/i18n-sig/2000-May/000173.html > > I'm going to fight very hard to make basic Unicode support in Python > modules "just work" without a bunch of internationalization knowledge > from the programmer. Great :-) The next big project ought to be getting the standard lib to work with Unicode input. A good way to test drive this, is running Python with -U option. > __repr__ is pretty basic. > > > > the reason for this patch was to avoid forcing everyone to deal with > > > this in their own code, by providing some kind of fallback behaviour. > > > > That's what your patch does; I don't see a reason to change it :-) > > If you're still proposing that I should deal with it in a particular > module's domain-specific code then the patch isn't done yet! You don't have too: a user who uses Latin-1 tag names will see the output of __repr__ as Latin-1... pretty straight forward if you ask me. If you want to make sure that __repr__ output is printable everywhere you should use an explicit lossless encoding for your application. Again, this is a userland decision which you'll have to make. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 3 18:39:52 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 18:39:52 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007010747.JAA00921@loewis.home.cs.tu-berlin.de> <395DDDEF.4ABB5BFC@lemburg.com> <010601bfe35b$46727ae0$f2a6b5d4@hagrid> <395E207C.91E3A2A5@lemburg.com> <395E3FC4.959BB042@prescod.net> <39605067.DCC2B968@lemburg.com> <3960BD86.A10797E3@prescod.net> Message-ID: <3960C1D8.18C4EA7D@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > I think it's ok to auto-convert to the default encoding > > as intermediate solution, but the applications wanting to > > return Unicode as __repr__ or __str__ should really > > use .encode() to make sure the output that is produces > > matches their (or their user's) expectations. > > If my users have expectations, I don't know them. I could allow them to > tell me what encoding to use, but surely they would rather do that in a > Python-wide fashion. They can choose the encoding by setting their LANG variable or you could make the setting application specific by using .encode where needed. BTW, are tag names using non-ASCII really used in practice ? I can understand values being Unicode, but Unicode tag names don't really make all that much sense to me (ok, that's a personal opinion). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 3 18:44:14 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jul 2000 18:44:14 +0200 Subject: [Python-Dev] unicode alphanumerics References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> <028301bfe37f$bb349380$f2a6b5d4@hagrid> <395E44E2.63383BC5@lemburg.com> <39606D0C.CB3F18FD@lemburg.com> Message-ID: <3960C2DE.F7E2FB7A@lemburg.com> FYI, I've added two new macros which allow querying alphabetic and alphanumeric characters: Py_UNICODE_ISALPHA() and Py_UNICODE_ISALNUM() The implementation is currently only experimental -- some 5200 chars are missing from being correctly identified as being alphanumeric (see my other post on the topic). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Mon Jul 3 19:01:27 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 3 Jul 2000 19:01:27 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> <3960BC32.CBBF3D6D@prescod.net> <3960C138.85D9B36A@lemburg.com> Message-ID: <00d201bfe510$573fce20$f2a6b5d4@hagrid> mal wrote: > > Anyhow, why would it be wrong for Fredrick to hard-code an encoding in > > repr but right for me to hard-code one in minidom? > > Because hardcoding the encoding into the core Python API touches > all programs. Hardcoded encodings should be userland options > whereever possible. the problem is that the existing design breaks peoples expectations: first, minidom didn't work because people expected to be able to return the result of: "8 bit string" + something + "8 bit string" or "8 bit string %s" % something from __repr__. that's a reasonable expectation (just look in the python standard library). after my fix, minidom still didn't work because people expected the conversion to work on all strings, on all platforms. that's also a reasonable expectation (read on). > Besides, we're talking about __repr__ which is mainly a > debug tool and doesn't affect program flow or interfacing > in any way. exactly. this is the whole point: __repr__ is a debug tool, and therefore it must work in all platforms, for all strings. if it's true that repr() cannot be changed to return unicode strings (in which case the conversion will be done on the way out to the user, by a file object or a user-interface library which might actually know what encoding to use), using a lossless encoding is the second best thing. on the other hand, if we can change repr/str, this is a non- issue. maybe someone could tell me exactly what code we'll break if we do that change? From gward at mems-exchange.org Mon Jul 3 19:07:48 2000 From: gward at mems-exchange.org (Greg Ward) Date: Mon, 3 Jul 2000 13:07:48 -0400 Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: <200007010151.DAA00574@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sat, Jul 01, 2000 at 03:51:07AM +0200 References: <200007010151.DAA00574@python.inrialpes.fr> Message-ID: <20000703130748.A31370@ludwig.cnri.reston.va.us> [Ping] > Okay, i just discovered sunau.py. Here's my real shot at > test_linuxaudiodev.py. Can you give this a try? Didn't work -- even after I changed has_key(formats, ...) to formats.has_key(...). Here's what I get: Traceback (most recent call last): File "test_linuxaudiodev-ping.py", line 37, in ? test() File "test_linuxaudiodev-ping.py", line 35, in test play_au_file(findfile('audiotest.au')) File "test_linuxaudiodev-ping.py", line 26, in play_au_file raise "audio format not supported by linuxaudiodev" audio format not supported by linuxaudiodev Sheesh, you'd think that plain old "Sun/NeXT audio data: 8-bit ISDN u-law, mono, 8000 Hz" (this is what "file" reports on "audiotest.au") would be supported. ;-) So I tried Michael Hudson's version. It also failed, but in a more interesting way. There mere traceback is not enough, but it's a start: Traceback (most recent call last): File "test_linuxaudiodev-hudson.py", line 62, in ? test() File "test_linuxaudiodev-hudson.py", line 60, in test play_au_file(findfile('audiotest.au')) File "test_linuxaudiodev-hudson.py", line 55, in play_au_file dsp.write(data) linuxaudiodev.error: (11, 'Resource temporarily unavailable') Here's the sequence of events I get: * run Michael's version of test_linuxaudiodev.py * it *immediately* dumps the above traceback, but does not return me to my shell prompt * Cardinal Fang *does* start his famous proclamation, and it sounds right (same as I get from "play audiotest.au") * but it's truncated about 3/4 of the way through: "Nobody expects the Spani----" * and then Python terminates with exit status 1 (presumably due to the traceback) Very curious! I know next-to-nothing about both Python's exception handling, sound drivers on Linux, and PC audio hardware. Any speculation I might offer would probably be useless, so I will merely comment that this is indeed curious. Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From bckfnn at worldonline.dk Mon Jul 3 19:06:05 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Mon, 03 Jul 2000 17:06:05 GMT Subject: [Python-Dev] unicode alphanumerics In-Reply-To: <39606D0C.CB3F18FD@lemburg.com> References: <024401bfe37b$dbe58d40$f2a6b5d4@hagrid> <395E22AC.6BB76041@lemburg.com> <028301bfe37f$bb349380$f2a6b5d4@hagrid> <395E44E2.63383BC5@lemburg.com> <39606D0C.CB3F18FD@lemburg.com> Message-ID: <3960c790.8381401@smtp.worldonline.dk> [M.-A. Lemburg] >"M.-A. Lemburg" wrote: >> >> Fredrik Lundh wrote: >> > how about this plan: >> > >> > -- you add a Py_UNICODE_ALPHA to unicodeobject.h asap, >> > which does exactly that (or I can do that, if you prefer). >> > (and maybe even a Py_UNICODE_ALNUM) >> >> Ok, I'll add Py_UNICODE_ISALPHA and Py_UNICODE_ISALNUM >> (first with approximations of the sort you give above and >> later with true implementations using tables in unicodectype.c) >> on Monday... gotta run now. >> >> > -- I change SRE to use that asap. >> > >> > -- you, I, or someone else add a better implementation, >> > some other day. > >I've just looked into this... the problem here is what to >consider as being "alpha" and what "numeric". > >I could add two new tables for the characters with category 'Lo' >(other letters, not cased) and 'Lm' (letter modifiers) >to match all letters in the Unicode database, but those >tables have some 5200 entries (note that there are only 804 lower >case letters and 686 upper case ones). In JDK1.3, Character.isLetter(..) and Character.isDigit(..) are documented as: http://java.sun.com/j2se/1.3/docs/api/java/lang/Character.html#isLetter(char) http://java.sun.com/j2se/1.3/docs/api/java/lang/Character.html#isDigit(char) http://java.sun.com/j2se/1.3/docs/api/java/lang/Character.html#isLetterOrDigit(char) I guess that java uses the extra huge tables. regards, finn From paul at prescod.net Mon Jul 3 20:38:26 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 13:38:26 -0500 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> <3960BC32.CBBF3D6D@prescod.net> <3960C138.85D9B36A@lemburg.com> <00d201bfe510$573fce20$f2a6b5d4@hagrid> Message-ID: <3960DDA2.3C608267@prescod.net> Fredrik Lundh wrote: > > ... > > exactly. this is the whole point: __repr__ is a debug tool, > and therefore it must work in all platforms, for all strings. As a debugging tool, it would probably help rather than hurt things to have repr be consistent on all platforms. If it is going to do a conversion, I vote for unicode-escape everywhere. > on the other hand, if we can change repr/str, this is a non- > issue. maybe someone could tell me exactly what code we'll > break if we do that change? I agree that we want to move to a world where unicode strings and 8-bit strings are accepted equally throughout Python. We do need some information about whether moving there quickly will break code or not. We need to know what Idle, PythonWin, Zope and other such environments do with the results of repr. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From ping at lfw.org Mon Jul 3 23:35:38 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 3 Jul 2000 16:35:38 -0500 (CDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000703095016.A24655@ludwig.cnri.reston.va.us> Message-ID: Eric S. Raymond wrote: > WhitespaceError Greg Ward wrote: > How about TabError? But what i'd really like is an IndentationError that shows up whenever there's an indentation problem. It doesn't even have to be its own class of error, i suppose, as long as it gets indicated some way ("SyntaxError: invalid indentation" would be fine). This response would be good for all of the following situations: >>> 3 File "", line 1 3 ^ SyntaxError: invalid syntax >>> if 1: ... 3 File "", line 2 3 ^ SyntaxError: invalid syntax >>> if 1: ... 3 ... 4 inconsistent dedent File "", line 3 4 ^ SyntaxError: invalid token >>> if 1: ... if 2: ... 3 File "", line 3 3 ^ SyntaxError: invalid syntax >>> if 1: ... if 2: ... 3 inconsistent dedent File "", line 3 3 ^ SyntaxError: invalid token >>> if 1: ... if 2: ... 3 ... 4 inconsistent dedent File "", line 4 4 ^ SyntaxError: invalid token -- ?!ng From tim_one at email.msn.com Mon Jul 3 23:52:13 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 3 Jul 2000 17:52:13 -0400 Subject: [Python-Dev] Just spotted on SourceForge main page In-Reply-To: <20000628223707.A1168@beelzebub> Message-ID: > Maybe this is what all you Windows folks are looking for. > > SFSetup v1 released > mhearn - 06/28/00 11:00 - SourceForge Setup for Win32 > > SFSetup is a program to automatically setup SSH and WinCVS for > SourceForge projects under the Windows 32 platform. It's now available > for download so if you have not yet set up SSH and WinCVS and want it > done for you, you can use this program. Go to sfsetup.sourceforge.net > to find out how to use it. It's open source and written in Delphi - > the code is in CVS and any improvements are welcome! Thanks -mike Note that this requires WinCVS 1.06 specifically (something like that -- see SFSetup's readme or whatever). I tried using it with a later version of WinCVS, and it left my machine in some state such that the behaviors of both cmdline CVS and WinCVS make no sense to anyone who has seen them actually working correctly. Barry in particular is baffled by how I manage to check in anything at all now. My ssh_keygen doesn't work either (no, I do *not* need even more pointers to purported Windows ssh implementations -- I've got 'em all, and I'll eventually unpack the one that happens to work on my system ). The great thing about all the instructions I've found so far is that they're written by people who apparently have no real understanding of how the underlying components (and/or Windows) work. So they're full of magical incantations that may or may not make sense on your particular setup. They may as well be trying to explain how to get the Microsoft Foundation Classes running under Linux . poke-&-hope-will-win-in-the-end-ly y'rs - tim From paul at prescod.net Tue Jul 4 00:31:57 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 03 Jul 2000 17:31:57 -0500 Subject: [Python-Dev] Just spotted on SourceForge main page References: Message-ID: <3961145D.708AFDB6@prescod.net> Tim Peters wrote: > > .. > > The great thing about all the instructions I've found so far is that they're > written by people who apparently have no real understanding of how the > underlying components (and/or Windows) work. So they're full of magical > incantations that may or may not make sense on your particular setup. I found the same damn thing. I actually emailed one of the guys about an apparent contradiction between his howto and another one and he basically said: "Hey, this is what works for me!" (in his defence, he did justify his interpration based on guesses about what the ssh for Windows porters were thinking) I also found that sfsetup program useless. Worse than useless. I have no idea what it did to my system. Argh. I eventually got it working. I'd love to tell you what I did but I just hacked and hacked until it worked. One time I got those messages that ESR did but who knows what made them go away. I'm not using ssh keys. I just specify my password over and over and over and over and... -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From fdrake at beopen.com Tue Jul 4 00:58:22 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 18:58:22 -0400 (EDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: References: <20000703095016.A24655@ludwig.cnri.reston.va.us> Message-ID: <14689.6798.745740.419095@cj42289-a.reston1.va.home.com> Ka-Ping Yee writes: > But what i'd really like is an IndentationError that shows > up whenever there's an indentation problem. That's what I think of when I hear "IndentationError" -- TabError is a specialized case of that. I think the general IndentationError will be hard to do, since many cases are just another parse error by the time they can be turned into exceptions. Unless I'm misreading that code. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein at lyra.org Tue Jul 4 01:20:43 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 16:20:43 -0700 Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <14689.6798.745740.419095@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 03, 2000 at 06:58:22PM -0400 References: <20000703095016.A24655@ludwig.cnri.reston.va.us> <14689.6798.745740.419095@cj42289-a.reston1.va.home.com> Message-ID: <20000703162043.K29590@lyra.org> On Mon, Jul 03, 2000 at 06:58:22PM -0400, Fred L. Drake, Jr. wrote: > > Ka-Ping Yee writes: > > But what i'd really like is an IndentationError that shows > > up whenever there's an indentation problem. > > That's what I think of when I hear "IndentationError" -- TabError is > a specialized case of that. > I think the general IndentationError will be hard to do, since many > cases are just another parse error by the time they can be turned into > exceptions. Unless I'm misreading that code. Speaking out of my butt here, without looking at code, I would suspect that the parser can return specializations "syntax error" to indicate that a problem with indentation occurred. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jul 4 01:53:05 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 16:53:05 -0700 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000703095600.A12141@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 03, 2000 at 09:56:00AM -0400 References: <20000703095600.A12141@thyrsus.com> Message-ID: <20000703165305.R29590@lyra.org> On Mon, Jul 03, 2000 at 09:56:00AM -0400, Eric S. Raymond wrote: > I have a valid ssh account on SourceForge. I follow the directions on the > Python CVS page and get this: > > Script started on Mon Jul 3 09:50:42 2000 > snark:~/WWW/python$ echo $CVS_RSH > /usr/bin/ssh > snark:~/WWW/python$ cvs -z3 -desr at cvs.python.sourceforge.net:/cvsroot/python co python I used: $ cvs -z3 -d :ext:gstein at cvs.python.sourceforge.net:/cvsroot/python co python The instructions on SF didn't quite work. Adding the :ext: in made it work fine for me. I'm using CVS 1.10.6 Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Tue Jul 4 01:54:43 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 3 Jul 2000 19:54:43 -0400 (EDT) Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000703165305.R29590@lyra.org> References: <20000703095600.A12141@thyrsus.com> <20000703165305.R29590@lyra.org> Message-ID: <14689.10179.591139.81266@cj42289-a.reston1.va.home.com> Greg Stein writes: > I used: > > $ cvs -z3 -d :ext:gstein at cvs.python.sourceforge.net:/cvsroot/python co python > > The instructions on SF didn't quite work. Adding the :ext: in made it work > fine for me. I'm using CVS 1.10.6 Interesting; using CVS 1.10.7 I was able to check out a tree using my login & SSH (requiring my passphrase, not password), but I didn't need the :ext: part. Sounds like there are some real version dependencies in the instructions. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Tue Jul 4 04:25:33 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 03 Jul 2000 21:25:33 -0500 Subject: [Python-Dev] Copyright notice In-Reply-To: Your message of "Sun, 02 Jul 2000 00:43:17 +0200." <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> References: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> Message-ID: <200007040225.VAA01396@cj20424-a.reston1.va.home.com> > On startup, the current CVS python reports (on my system) > > Python 2.0b1 (#31, Jul 1 2000, 23:13:39) [GCC 2.95.2 19991024 (release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > > Now that the file copyrights are changed, I expect this message to > change as well. May I suggest that, instead of adding another line, > the two last lines of this message are removed? > > People who need to find out who holds the copyright to this software > still can print sys.copyright. I think I recall this was a convention that the GNU folks claim is required from a legal standpoint. E.g. when I start gdb, I get: GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux". (gdb) The Python welcome message is a lot less verbose! But I am not a lawyer (IANAL) and maybe the GNU folks are superstitious about this. On the other hand, why does it bother you? (*NOT* a rhetorical question.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Tue Jul 4 03:48:17 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 3 Jul 2000 21:48:17 -0400 Subject: [Python-Dev] Copyright notice In-Reply-To: <200007040225.VAA01396@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 03, 2000 at 09:25:33PM -0500 References: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> <200007040225.VAA01396@cj20424-a.reston1.va.home.com> Message-ID: <20000703214817.A13791@thyrsus.com> Guido van Rossum : > On the other hand, why does it bother you? (*NOT* a rhetorical question.) Maybe he doesn't like noisy programs. I don't either. Programs should either (a) tell me what I need to hear, (b) tell me what I've asked to hear, or (c) keep their traps shut and refrain from wasting my time and attention. (There are some who would say this atttude makes me old-fashioned in an age of GUIs. Au contraire -- visual gewgaws and noise are so seductive to interface designers that we need to be *less* tolerant of noise than formerly.) -- Eric S. Raymond The men and women who founded our country knew, by experience, that there are times when the free person's answer to oppressive government has to be delivered with a bullet. Thus, the right to bear arms is not just *a* freedom; it's the mother of all freedoms. Don't let them disarm you! From gstein at lyra.org Tue Jul 4 04:02:36 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 19:02:36 -0700 Subject: [Python-Dev] Copyright notice In-Reply-To: <20000703214817.A13791@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 03, 2000 at 09:48:17PM -0400 References: <200007012243.AAA10870@loewis.home.cs.tu-berlin.de> <200007040225.VAA01396@cj20424-a.reston1.va.home.com> <20000703214817.A13791@thyrsus.com> Message-ID: <20000703190235.G29590@lyra.org> On Mon, Jul 03, 2000 at 09:48:17PM -0400, Eric S. Raymond wrote: > Guido van Rossum : > > On the other hand, why does it bother you? (*NOT* a rhetorical question.) > > Maybe he doesn't like noisy programs. I don't either. Programs > should either (a) tell me what I need to hear, (b) tell me what I've > asked to hear, or (c) keep their traps shut and refrain from wasting my > time and attention. Agreed. I've prefer not to have several lines of spammage hit my screen whenever I invoked Python. What's the point? And note there isn't a license requirement to print that stuff. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Tue Jul 4 04:31:11 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 4 Jul 2000 12:31:11 +1000 Subject: [Python-Dev] Copyright notice In-Reply-To: <20000703214817.A13791@thyrsus.com> Message-ID: > Programs > should either (a) tell me what I need to hear, (b) tell me what I've > asked to hear, or (c) keep their traps shut and refrain from wasting my > time and attention. You have almost described my perfect partner :-) [Not really, of course, but the sexist comparison was just _screaming_ to be made :-] Mark. From gstein at lyra.org Tue Jul 4 04:59:08 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 19:59:08 -0700 Subject: [Python-Dev] Copyright notice In-Reply-To: ; from mhammond@skippinet.com.au on Tue, Jul 04, 2000 at 12:31:11PM +1000 References: <20000703214817.A13791@thyrsus.com> Message-ID: <20000703195908.H29590@lyra.org> On Tue, Jul 04, 2000 at 12:31:11PM +1000, Mark Hammond wrote: > > > Programs > > should either (a) tell me what I need to hear, (b) tell me what I've > > asked to hear, or (c) keep their traps shut and refrain from wasting my > > time and attention. > > You have almost described my perfect partner :-) *rofl* > [Not really, of course, but the sexist comparison was just _screaming_ to > be made :-] Sexist? Not at all. You didn't say whether your perfect partner was a man or a woman. ;-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Tue Jul 4 06:35:00 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 00:35:00 -0400 (EDT) Subject: [Python-Dev] Making -tt the default Message-ID: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> The recent discussion about the possibility of specialized forms of SyntaxError for indentation and tab/space issues brings up the problem of the -t/-tt options to the interpreter. If a distinct exception is defined for indentation-related errors, that could probably be implemented and tested without regard for the -t/-tt setting, except for the tab/space exception. That exception is only raised when -tt is specified, and there's no way from Python to determine if it is set except for testing to see that the exception is raised when ambiguous tab/space combinations are presented to the tokenizer. This reminds us that most programmers aren't going to bother with the -tt option; it's something extra that they don't really need to get the job done. Life without it, however, is shakey: Python code is harder to share than it needs to be because nobody can rely on non-ambiguous tab/space usage. If -tt were the default, the problem would not be discovered after code is deployed but, rather, before it is otherwise tested by the original developers and maintainers. There are two things that can be done: have distutils always use -tt when compiling code that gets installed (using a child interpreter if needed), and setting -tt as the default in the next Python release. Using -tt in the distutils will cause this setting to be used with Python 1.5.2 installations. Setting -tt to be the default, and not having a way to override it, would lead to some small code simplifications as well. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From DavidA at ActiveState.com Tue Jul 4 06:45:22 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 3 Jul 2000 21:45:22 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: > This reminds us that most programmers aren't going to bother with > the -tt option; it's something extra that they don't really need to > get the job done. Which reminds me that I'd really like the default python-mode.el to use more 'strict' defaults than it currently does. I don't know how, but I routinely generate bad indentations w/ pymode, which I blame on bad defaults in the elisp file. I can fix the config, of course, with enough work, but I believe it should be set to a more strict default. --da From fdrake at beopen.com Tue Jul 4 06:49:53 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 00:49:53 -0400 (EDT) Subject: [Python-Dev] Sorry. No Release. In-Reply-To: <20000703162043.K29590@lyra.org> References: <20000703095016.A24655@ludwig.cnri.reston.va.us> <14689.6798.745740.419095@cj42289-a.reston1.va.home.com> <20000703162043.K29590@lyra.org> Message-ID: <14689.27889.33072.39039@cj42289-a.reston1.va.home.com> Greg Stein writes: > Speaking out of my butt here, without looking at code, I would suspect that > the parser can return specializations "syntax error" to indicate that a > problem with indentation occurred. And I'm sure you'll find the way to do it. ;) Here's a patch that sets up the IndentationError and TabError exceptions, and gets TabError raised when -tt is in effect. If you can figure out how to get IndentationError raised for other indentation-related errors, I'll be interested in seeing it. Essentially, the parser-generator will need to be able to distinguish between INDENT/DEDENT errors and other errors, and I've not dug deep enough to figure that one out. The tab/space errors are easy since they're in the hand-coded lexer. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: indentation-error.patch URL: From fdrake at beopen.com Tue Jul 4 06:54:04 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 00:54:04 -0400 (EDT) Subject: [Python-Dev] Making -tt the default In-Reply-To: References: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: <14689.28140.772442.865150@cj42289-a.reston1.va.home.com> David Ascher writes: > Which reminds me that I'd really like the default python-mode.el to use more > 'strict' defaults than it currently does. I don't know how, but I routinely > generate bad indentations w/ pymode, which I blame on bad defaults in the > elisp file. I can fix the config, of course, with enough work, but I > believe it should be set to a more strict default. Recent versions of python-mode all use default indentations of 4 spaces, and I don't think it generates tabs. If it can, it shouldn't. Barry? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Tue Jul 4 07:01:48 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 4 Jul 2000 01:01:48 -0400 Subject: Windows vs SourceForge (was RE: [Python-Dev] Just spotted on SourceForge main page) In-Reply-To: <200007040313.WAA01842@cj20424-a.reston1.va.home.com> Message-ID: [Tim] > The great thing about all the instructions I've found so far is > that they're written by people who apparently have no real understanding > of how the underlying components (and/or Windows) work. [an anonymous Guido replied in pvt] > That was not my impression of Andy's instructions. They were to the > point and effective. Yes, they certainly *looked* that way . I didn't mean to slander Andy! His instructions didn't work for me, but then nobody else's did either, and I've increasingly suspected it's because I've got so many half-broken SSH, CVS, and WinCVS installations on this machine fighting each other. So, without an imminent release busting my homeless balls, I decided to take the time to start over from scratch: + Ran an official uninstaller for everything that left one behind (only WinCVS). + Manually tracked down all the crap WinCVS left behind in the registry anyway, and deleted it. + Deleted all the ssh and cvs .exe's on machine. + Got the crap out of my autoexec.bat (I'm running Win98SE) that various packages had inserted there (I *think* this stuff was left behind by the SourceForge setup tool). + Deleted all the .ssh directories on my machine (and found some in surprising places! e.g., one was hiding under "\My Documents"(!)). + Got rid of an absurd \etc directory (again suspect the SF setup tool, although several goofy sets of instructions demanded you create one of these). + Nuked my entire Python tree. + Rebooted. + Did a full tape backup of the machine . + Retrieved Andy Robinson's instructions and tried them again. Worked great! I'll attach a modified version below, where I filled in blanks and repaired (just a few) typos as I went along. This should get you a functional Windows cmdline CVS running with SourceForge, and I don't want a GUI version anyway. If there's anything here that isn't crystal clear or doesn't work, gripe at me, not Andy ... all's-well-that-ends-ly y'rs - tim Setting up a cmdline CVS to work with SourceForge under Windows --------------------------------------------------------------- 28-Jun-2000 Original by Andy Robinson (andy at reportlab.com) 03-Jul-2000 Modified by Tim Peters (tim_one at msn.com) 1. Get ftp.reportlab.com/tools/cvs-1.10-win.zip ftp.reportlab.com/tools/ssh-1.2.14-win32bin.zip (copied from somewhere obscure for safety, I forget where) 2. Unzip these to a location on your path. Type 'cvs' and 'ssh' from somewhere else to verify. 3. Choose where to keep your CVS projects; let's assume C:\Code 4. Create a subdirectory C:\Code\.ssh (yes, dot-ssh) 5. (see #8 for an alternative) Create two environment variables: HOME=C:\Code CVS_RSH=ssh HOME must point to the directory above your .ssh directory. On Win9x, this can be done in a batch file or autoexec.bat; e.g., set HOME=c:\Code set CVS_RSH=ssh Run the batch file, or reboot if you're using autoexec.bat. On NT or 2000, go to Control Panel | System | Environment and set them at either user or machine level. 6. If not done so, get a Sourceforge account and a project you can log in to. 7. Teach SSH about your project's home, by doing ssh -l $USERNAME $MYPROJECT.sourceforge.net where $USERNAME is your SourceForge login name and $MYPROJECT your SourceForge project name. You'll see Host "$MYPROJECT.sourceforge.net" added to the list of known hosts. and then Creating random seed file ~/.ssh/random_seed. This may take a while. After a while it will prompt for a password. Type your SourceForge password and hit ENTER. After some SourceForge msgs scroll by, you'll be left at a SourceForge shell prompt. Type exit and hit ENTER. Now you're back at the DOS prompt. 8. You will need either a lengthy command line or a batch file for each sourceforge project. I set cvsroot in a batch file in my 'c:\code' directory, and have one such file for each CVS project I use (about ten of them!): set CVSROOT=:ext:$USERNAME at cvs.$MYPROJECT.sourceforge.net:/cvsroot/$DIRNAME where $USERNAME and $MYPROJECT are again your SourceForge login and project names, and $DIRNAME is the top-level directory in the SourceForge CVS tree; a project can have several, but usually there is just one. Note: you can keep HOME and CVS_SSH out of your permanent environment (see #5) by adding those definitions to this batch file instead. 9. Execute this batch file. You can now go to C:\Code and do cvs -z7 checkout $MYPROJECT (z7 means 'compress network traffic', handy over dialup lines) 10. From now on, just use CVS normally, running this batch file first each time you bring up a DOS box you're going to use for CVS work. Note that you'll be asked for your password each time you enter a CVS command. I wouldn't survive without Karl Fogel's book "Open Source Development with CVS", Coriolis Press. The CVS reference material (about 225 printed pages!) from this book is available for free download from http://cvsbook.red-bean.com/ Footnote: for anonymous checkout, I think you just omit the 'my_user_name@' part from the CVSROOT variable. I hope this helps; let me know if people have any problems with the instructions. - Andy Robinson ReportLab From tim_one at email.msn.com Tue Jul 4 07:11:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 4 Jul 2000 01:11:27 -0400 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14689.28140.772442.865150@cj42289-a.reston1.va.home.com> Message-ID: [David Ascher] > Which reminds me that I'd really like the default python-mode.el to use > more 'strict' defaults than it currently does. If you can, please be explicit about what exactly in the pymode config you think needs to be changed. I can't tell from your complaint. > I don't know how, But we should be able to guess ? > but I routinely generate bad indentations w/ pymode, which I blame on bad > defaults in the elisp file. I can fix the config, of course, If so, being explicit should be a piece of cake ... > with enough work, but I believe it should be set to a more strict default. I never got bad indentation out of pymode when I was working on it, so I'm at a loss here. It can't prevent you from, e.g., inserting a literal tab character via C-q, if that's what you're doing. I assume you're not doing that, though. More info! From gstein at lyra.org Tue Jul 4 07:17:07 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 22:17:07 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: ; from DavidA@ActiveState.com on Mon, Jul 03, 2000 at 09:45:22PM -0700 References: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: <20000703221706.L29590@lyra.org> On Mon, Jul 03, 2000 at 09:45:22PM -0700, David Ascher wrote: > > This reminds us that most programmers aren't going to bother with > > the -tt option; it's something extra that they don't really need to > > get the job done. > > Which reminds me that I'd really like the default python-mode.el to use more > 'strict' defaults than it currently does. I don't know how, but I routinely > generate bad indentations w/ pymode, which I blame on bad defaults in the > elisp file. I can fix the config, of course, with enough work, but I > believe it should be set to a more strict default. Never seen this happen. Can you watch yourself and discover how you are generating these? I do admit that maybe pymode is generating them for me, too, but that I unconsciously compensate for the problem. I have certainly never consciously went "woah! bad pymode! bad pymode! stop that!" :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Tue Jul 4 07:23:29 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 4 Jul 2000 01:23:29 -0400 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > ... > There are two things that can be done: have distutils always use > -tt when compiling code that gets installed (using a child interpreter > if needed), and setting -tt as the default in the next Python > release. +1 from me. Hey, it's 2.0: we can break anything . > .... > Setting -tt to be the default, and not having a way to override it, +1 on that too. > would lead to some small code simplifications as well. and-also-cut-out-one-bogus-source-of-c.l.py-whitespace- flamewars-ly y'rs - tim From DavidA at ActiveState.com Tue Jul 4 07:49:32 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 3 Jul 2000 22:49:32 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: Message-ID: > If you can, please be explicit about what exactly in the pymode config you > think needs to be changed. I can't tell from your complaint. You can't channel me, eh? Loser. Ok, I'll keep an eye out and see if I can reproduce what I'm doing wrong. Sorry for just complaining and not giving people a chance to fix whatever it is I'm doing wrong =). --david From tim_one at email.msn.com Tue Jul 4 08:06:43 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 4 Jul 2000 02:06:43 -0400 Subject: [Python-Dev] Making -tt the default In-Reply-To: Message-ID: [Tim, fails to channel David] [David Ascher] > You can't channel me, eh? Loser. Oh, indeed yes! No more than two hours before, I failed Guido too, by failing to guess one of the passwords I needed to do something he commanded me to do. My myth of omniscience was much easier to maintain at a distance . > Ok, I'll keep an eye out and see if I can reproduce what I'm doing wrong. > Sorry for just complaining and not giving people a chance to fix > whatever it is I'm doing wrong =). It occurs to me that I had Emacs set up (in my own .emacs) to never ever use literal tab characters. That may go a way in explaining why pymode never generated ambiguous indentation for me! I suppose you can also get in trouble by editing *other* peoples' code containing a mix of tabs and spaces. So never do that either. heck-give-up-computers-and-get-an-honest-job-ly y'rs - tim From gstein at lyra.org Tue Jul 4 08:39:38 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 3 Jul 2000 23:39:38 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: ; from tim_one@email.msn.com on Tue, Jul 04, 2000 at 02:06:43AM -0400 References: Message-ID: <20000703233938.N29590@lyra.org> On Tue, Jul 04, 2000 at 02:06:43AM -0400, Tim Peters wrote: >... > > Ok, I'll keep an eye out and see if I can reproduce what I'm doing wrong. > > Sorry for just complaining and not giving people a chance to fix > > whatever it is I'm doing wrong =). > > It occurs to me that I had Emacs set up (in my own .emacs) to never ever use > literal tab characters. That may go a way in explaining why pymode never > generated ambiguous indentation for me! > > I suppose you can also get in trouble by editing *other* peoples' code > containing a mix of tabs and spaces. So never do that either. I use the following tidbit of code in my .emacs: (add-hook 'python-mode-hook (lambda () (setq indent-tabs-mode nil) (setq py-indent-offset 2) (setq py-smart-indentation nil) (define-key py-mode-map "\e\C-h" 'backward-kill-word) )) The indent-tabs-mode is the key to disabling tab characters and using just spaces. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jul 4 09:35:02 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 4 Jul 2000 00:35:02 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.165,2.166 codecs.c,2.8,2.9 compile.c,2.112,2.113 modsupport.c,2.45 In-Reply-To: <200007040710.JAA16635@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Tue, Jul 04, 2000 at 09:10:08AM +0200 References: <200007032139.OAA29276@slayer.i.sourceforge.net> <200007040710.JAA16635@python.inrialpes.fr> Message-ID: <20000704003502.P29590@lyra.org> Placing it there means everybody and their brother will now have to include it. Personally, I'd rather have the number of headers in my compilation unit minimized. Take the argument of "put it into Python.h" to the extreme: why have any includes in any of the .c files? Put them ALL into Python.h so nobody has to bother with them in their .c files. :-) Cheers, -g On Tue, Jul 04, 2000 at 09:10:08AM +0200, Vladimir Marangozov wrote: > > This HAVE_LIMITS_H define spans over several files already. > Why not putting it in Python.h and cleanup the rest? > > Jack Jansen wrote: > > > > Update of /cvsroot/python/python/dist/src/Python > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv29235/Python > > > > Modified Files: > > bltinmodule.c codecs.c compile.c modsupport.c > > Log Message: > > Include limits.h if we have it. > > > > > > Index: bltinmodule.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v > > retrieving revision 2.165 > > retrieving revision 2.166 > > diff -C2 -r2.165 -r2.166 > > *** bltinmodule.c 2000/06/30 23:58:05 2.165 > > --- bltinmodule.c 2000/07/03 21:39:47 2.166 > > *************** > > *** 24,27 **** > > --- 24,30 ---- > > #include > > #endif > > + #ifdef HAVE_LIMITS_H > > + #include > > + #endif > > > > /* Forward */ > > > > Index: codecs.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Python/codecs.c,v > > retrieving revision 2.8 > > retrieving revision 2.9 > > diff -C2 -r2.8 -r2.9 > > *** codecs.c 2000/06/29 14:50:15 2.8 > > --- codecs.c 2000/07/03 21:39:47 2.9 > > *************** > > *** 11,14 **** > > --- 11,17 ---- > > #include "Python.h" > > #include > > + #ifdef HAVE_LIMITS_H > > + #include > > + #endif > > > > /* --- Globals ------------------------------------------------------------ */ > > > > Index: compile.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v > > retrieving revision 2.112 > > retrieving revision 2.113 > > diff -C2 -r2.112 -r2.113 > > *** compile.c 2000/06/30 23:58:06 2.112 > > --- compile.c 2000/07/03 21:39:47 2.113 > > *************** > > *** 34,37 **** > > --- 34,40 ---- > > > > #include > > + #ifdef HAVE_LIMITS_H > > + #include > > + #endif > > > > /* Three symbols from graminit.h are also defined in Python.h, with > > > > Index: modsupport.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Python/modsupport.c,v > > retrieving revision 2.45 > > retrieving revision 2.46 > > diff -C2 -r2.45 -r2.46 > > *** modsupport.c 2000/06/30 23:58:06 2.45 > > --- modsupport.c 2000/07/03 21:39:47 2.46 > > *************** > > *** 12,15 **** > > --- 12,18 ---- > > > > #include "Python.h" > > + #ifdef HAVE_LIMITS_H > > + #include > > + #endif > > > > #ifdef MPW /* MPW pushes 'extended' for float and double types with varargs */ > > > > > > _______________________________________________ > > Python-checkins mailing list > > Python-checkins at python.org > > http://www.python.org/mailman/listinfo/python-checkins > > > > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From fredrik at pythonware.com Tue Jul 4 11:18:40 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 11:18:40 +0200 Subject: [Python-Dev] Re: [ Patch #100719 ] Use '#!/usr/bin/env python' in scripts References: <20000703233938.N29590@lyra.org> Message-ID: <010101bfe598$d88381b0$0900a8c0@SPIFF> (just a heads up, not sure if SF was able to send out the notifications) This patch suggests changing /usr/local/bin/python to /usr/bin/env python in cgi.py and faqwiz.py. Note that both scripts are CGI scripts, and the FAQ has the following to say about that: http://www.python.org/doc/FAQ.html#4.63 Note -- *don't* do this for CGI scripts. The $PATH variable for CGI scripts is often very minimal, so you need to use the actual absolute pathname of the interpreter. -1, in other words (assuming that the FAQ is correct) From mal at lemburg.com Tue Jul 4 11:45:05 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 11:45:05 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! Message-ID: <3961B221.4F7552C3@lemburg.com> There was a discussion about adding a #define _XOPEN_SOURCE to the standard header files in Python (among other things to fix the warning in the timemodule.c on Linux). What happened to that idea ? I think it would be worthwhile to add a #ifdef __GNUC__ # define _GNU_SOURCE #endif to Python.h. This enables all features available for the gcc compiler including _XOPEN_SOURCE and fixes warnings related to missing prototypes. Thoughts ? Would this hurt anybody ? BTW, I'm +1 on adding a mylimits.h to Python.h too. mylimits.h would then either include the system's limits.h file or provide workarounds for platforms which don't have it. Then we could drop the #define INT_MAX which can be found in several Python C files. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Tue Jul 4 11:51:54 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 4 Jul 2000 02:51:54 -0700 Subject: [Python-Dev] Re: [ Patch #100719 ] Use '#!/usr/bin/env python' in scripts In-Reply-To: <010101bfe598$d88381b0$0900a8c0@SPIFF>; from fredrik@pythonware.com on Tue, Jul 04, 2000 at 11:18:40AM +0200 References: <20000703233938.N29590@lyra.org> <010101bfe598$d88381b0$0900a8c0@SPIFF> Message-ID: <20000704025154.W29590@lyra.org> On Tue, Jul 04, 2000 at 11:18:40AM +0200, Fredrik Lundh wrote: > (just a heads up, not sure if SF was able to send > out the notifications) > > This patch suggests changing /usr/local/bin/python to > /usr/bin/env python in cgi.py and faqwiz.py. Note > that both scripts are CGI scripts, and the FAQ has the > following to say about that: > > http://www.python.org/doc/FAQ.html#4.63 > > Note -- *don't* do this for CGI scripts. The $PATH > variable for CGI scripts is often very minimal, so > you need to use the actual absolute pathname of > the interpreter. > > -1, in other words (assuming that the FAQ is correct) I have observed the same behavior in my CGI scripts: you cannot rely on PATH, so the /usr/bin/env thing simply doesn't work. -1 also. Cheers, -g -- Greg Stein, http://www.lyra.org/ From sjoerd at oratrix.nl Tue Jul 4 11:55:41 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Tue, 04 Jul 2000 11:55:41 +0200 Subject: [Python-Dev] SRE incompatibility Message-ID: <20000704095542.8697B31047C@bireme.oratrix.nl> >>> regexp = '(([a-z]+):)?([a-z]+)$' >>> import re >>> re.match(regexp, 'smil').group(0,1,2,3) ('smil', None, 's', 'smil') >>> import pre >>> pre.match(regexp, 'smil').group(0,1,2,3) ('smil', None, None, 'smil') Needless to say, I am relying on the third value being None... (My regular expression was actually more like '(?:(?P[a-z]+):)?(?P[a-z]+)$' and I check for result.group('prefix')) -- Sjoerd Mullender From gstein at lyra.org Tue Jul 4 12:01:43 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 4 Jul 2000 03:01:43 -0700 Subject: [Python-Dev] suggest pyportable.h (was: Make _GNU_SOURCE default for gcc ?!) In-Reply-To: <3961B221.4F7552C3@lemburg.com>; from mal@lemburg.com on Tue, Jul 04, 2000 at 11:45:05AM +0200 References: <3961B221.4F7552C3@lemburg.com> Message-ID: <20000704030143.Y29590@lyra.org> On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: >... GNU_SOURCE ... Seems fine, and I can't see how it would hurt. +1 > BTW, I'm +1 on adding a mylimits.h to Python.h too. mylimits.h > would then either include the system's limits.h file or provide > workarounds for platforms which don't have it. Then we could drop > the #define INT_MAX which can be found in several Python C files. Euh... we should probably stop creating myfoo.h every time we want to replace some "foo" header. It would be much nicer to simply create "pyportable.h" and have it include the various pieces when available or to create suitable defaults for them. There would be a companion pyportable.c to define replacement functions. Continuing to litter the Python source area with a bunch of little files for all the edge cases on the planet... just doesn't make much sense to me. It starts to create too much confusion/complexity. Cheers, -g -- Greg Stein, http://www.lyra.org/ From fredrik at pythonware.com Tue Jul 4 12:08:50 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 12:08:50 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> Message-ID: <018a01bfe59f$da814950$0900a8c0@SPIFF> mal wrote: > There was a discussion about adding a #define _XOPEN_SOURCE > to the standard header files in Python (among other things to > fix the warning in the timemodule.c on Linux). > > What happened to that idea ? > > I think it would be worthwhile to add a > > #ifdef __GNUC__ > # define _GNU_SOURCE > #endif > > to Python.h. This enables all features available for the > gcc compiler including _XOPEN_SOURCE and fixes warnings > related to missing prototypes. > > Thoughts ? Would this hurt anybody ? what does "fixes warnings" mean? does it change the compiler's behaviour, or does it just make sure stuff are defined in the right files? how is this different from just a plain (and truly portable) #define _XOPEN_SOURCE? (the only concern I see here is that people on Linux platforms might start churning out code that depends on certain gcc-only features, without noticing...) +1 on _XOPEN_SOURCE +0 on _GNU_SOURCE From mal at lemburg.com Tue Jul 4 12:13:04 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 12:13:04 +0200 Subject: [Python-Dev] suggest pyportable.h (was: Make _GNU_SOURCE default for gcc ?!) References: <3961B221.4F7552C3@lemburg.com> <20000704030143.Y29590@lyra.org> Message-ID: <3961B8B0.96E010C3@lemburg.com> Greg Stein wrote: > > On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: > >... GNU_SOURCE ... > > Seems fine, and I can't see how it would hurt. > > +1 > > > BTW, I'm +1 on adding a mylimits.h to Python.h too. mylimits.h > > would then either include the system's limits.h file or provide > > workarounds for platforms which don't have it. Then we could drop > > the #define INT_MAX which can be found in several Python C files. > > Euh... we should probably stop creating myfoo.h every time we want to > replace some "foo" header. > > It would be much nicer to simply create "pyportable.h" and have it include > the various pieces when available or to create suitable defaults for them. > There would be a companion pyportable.c to define replacement functions. > > Continuing to litter the Python source area with a bunch of little files for > all the edge cases on the planet... just doesn't make much sense to me. It > starts to create too much confusion/complexity. Fine with me... we should probably make it contains all the different myfoo.h header files. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Jul 4 12:43:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 12:43:23 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> Message-ID: <3961BFCB.DD7895E1@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > There was a discussion about adding a #define _XOPEN_SOURCE > > to the standard header files in Python (among other things to > > fix the warning in the timemodule.c on Linux). > > > > What happened to that idea ? > > > > I think it would be worthwhile to add a > > > > #ifdef __GNUC__ > > # define _GNU_SOURCE > > #endif > > > > to Python.h. This enables all features available for the > > gcc compiler including _XOPEN_SOURCE and fixes warnings > > related to missing prototypes. > > > > Thoughts ? Would this hurt anybody ? > > what does "fixes warnings" mean? does it change the compiler's > behaviour, or does it just make sure stuff are defined in the right > files? AFAIK, it only makes certain APIs available as prototype. Without the prototypes the usual response from the compiler are warning such as "converted integer to pointer without a cast" and somesuch (the default return value being "int"). > how is this different from just a plain (and truly portable) > #define _XOPEN_SOURCE? _XOPEN_SOURCE would also cure the warning in timemodule. > (the only concern I see here is that people on Linux platforms > might start churning out code that depends on certain gcc-only > features, without noticing...) > > +1 on _XOPEN_SOURCE > +0 on _GNU_SOURCE Ok, so how about adding #define _XOPEN_SOURCE to Python.h ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pf at artcom-gmbh.de Tue Jul 4 12:31:34 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 4 Jul 2000 12:31:34 +0200 (MEST) Subject: [Python-Dev] Re: [ Patch #100719 ] Use '#!/usr/bin/env python' in scripts In-Reply-To: <010101bfe598$d88381b0$0900a8c0@SPIFF> from Fredrik Lundh at "Jul 4, 2000 11:18:40 am" Message-ID: Hi, Fredrik Lundh : > (just a heads up, not sure if SF was able to send > out the notifications) > > This patch suggests changing /usr/local/bin/python to > /usr/bin/env python in cgi.py and faqwiz.py. Note > that both scripts are CGI scripts, and the FAQ has the > following to say about that: > > http://www.python.org/doc/FAQ.html#4.63 > > Note -- *don't* do this for CGI scripts. The $PATH > variable for CGI scripts is often very minimal, so > you need to use the actual absolute pathname of > the interpreter. > > -1, in other words (assuming that the FAQ is correct) I agree (now). I had submitted a similar patch at the beginning of this year, since such a patch is also part of the diff files usually applied on the major Linux distributions in order to build the Python binary RPMs on these Systems (SuSE Linux, RedHat). But I was conviced, that patching the official source tree would be a bad idea, since this will break these CGI scripts on most traditional Unices (e.g. Slowlaris), where people are unfortunately normally forced to build Python on their own and might forget (or are not allowed) to add /usr/local/bin to the default path. Since all major Linux distributions however come with a properly patched Python package anyway. Python living in /usr/bin on all those boxes is no argument. I believe applying such a patch has to wait until the proposed "world domination" of Linux has become real. ;-) So ---at least today--- the FAQ entry is ---still--- somewhat correct. However may be someone could add a note about prebuild Python RPMs to FAQ 4.63 in the mean time? I believe that otherwise Linux people will keep submitting patches like this one with increasing frequency. At least our customers throw out their Sun Sparc and SGI boxes and replace them with cheap Athlon or PIII boxes running SuSE or RedHat Linux with increasing velocity. Especially those in China, Singapur and Brasil. So in our customer base, Solaris and IRIX is dying out faster than I myself as a strong Linux proposer had believed even at the beginning of this year. YMMV since we are only a small company in a very special market segment. Regards, Peter From mal at lemburg.com Tue Jul 4 13:05:34 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 13:05:34 +0200 Subject: [Python-Dev] Minidom and Unicode References: <200007030729.JAA05450@loewis.home.cs.tu-berlin.de> <004e01bfe4d4$acc737c0$f2a6b5d4@hagrid> <200007031308.PAA00821@loewis.home.cs.tu-berlin.de> <01eb01bfe4f7$2975e330$0900a8c0@SPIFF> <3960B2B6.9290F932@lemburg.com> <3960BC32.CBBF3D6D@prescod.net> <3960C138.85D9B36A@lemburg.com> <00d201bfe510$573fce20$f2a6b5d4@hagrid> <3960DDA2.3C608267@prescod.net> Message-ID: <3961C4FE.D71A81B8@lemburg.com> Paul Prescod wrote: > > Fredrik Lundh wrote: > > > > ... > > > > exactly. this is the whole point: __repr__ is a debug tool, > > and therefore it must work in all platforms, for all strings. > > As a debugging tool, it would probably help rather than hurt things to > have repr be consistent on all platforms. If it is going to do a > conversion, I vote for unicode-escape everywhere. Ok, if you provide documentation for this, I'll give in on __repr__. In any case, __str__ should use the default encoding. > > on the other hand, if we can change repr/str, this is a non- > > issue. maybe someone could tell me exactly what code we'll > > break if we do that change? > > I agree that we want to move to a world where unicode strings and 8-bit > strings are accepted equally throughout Python. We do need some > information about whether moving there quickly will break code or not. > We need to know what Idle, PythonWin, Zope and other such environments > do with the results of repr. Anybody care to test this ? I think we should be careful about letting Unicode objects go loose in environments which were not designed to work with them. Let's first start with polishing up the standard lib to work with Unicode. It currently fails badly... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Tue Jul 4 13:07:53 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 13:07:53 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> Message-ID: <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> mal wrote: > Ok, so how about adding > > #define _XOPEN_SOURCE > > to Python.h ? digging through my old notes, it should be: /* force susv2 compatibility, where available */ #define _XOPEN_SOURCE 500 IIRC, Guido agreed that this was a good idea, so what are we waiting for? If it doesn't break the build on your Linux box, just go ahead and check it in! From mal at lemburg.com Tue Jul 4 13:10:42 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 13:10:42 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> Message-ID: <3961C632.CFADDC65@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > Ok, so how about adding > > > > #define _XOPEN_SOURCE > > > > to Python.h ? > > digging through my old notes, it should be: > > /* force susv2 compatibility, where available */ > #define _XOPEN_SOURCE 500 > > IIRC, Guido agreed that this was a good idea, so what > are we waiting for? If it doesn't break the build on your > Linux box, just go ahead and check it in! Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Jul 4 13:49:03 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 13:49:03 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> <3961C632.CFADDC65@lemburg.com> Message-ID: <3961CF2F.113EC4F7@lemburg.com> "M.-A. Lemburg" wrote: > > Fredrik Lundh wrote: > > > > mal wrote: > > > > > Ok, so how about adding > > > > > > #define _XOPEN_SOURCE > > > > > > to Python.h ? > > > > digging through my old notes, it should be: > > > > /* force susv2 compatibility, where available */ > > #define _XOPEN_SOURCE 500 > > > > IIRC, Guido agreed that this was a good idea, so what > > are we waiting for? If it doesn't break the build on your > > Linux box, just go ahead and check it in! > > Ok. Hmm, with "#define _XOPEN_SOURCE 500" I get these (new) errors: ./posixmodule.c: In function `posix_tmpnam': ./posixmodule.c:3494: warning: assignment makes pointer from integer without a cast ./signalmodule.c:83: `SIGMAX' undeclared here (not in a function) ./signalmodule.c:83: size of array `Handlers' has non-integer type Both errors can only be fixed using __USE_MISC: __USE_MISC Define things common to BSD and System V Unix. It is defined when either _BSD_SOURCE or _SVID_SOURCE is defined... question is: which to use ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping at lfw.org Tue Jul 4 14:05:38 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Tue, 4 Jul 2000 05:05:38 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: Message-ID: On Mon, 3 Jul 2000, Ka-Ping Yee wrote: > It doesn't even have to be its own class of error, i suppose, > as long as it gets indicated some way ("SyntaxError: invalid > indentation" would be fine). It turns out that this should be quite easy. If it weren't past 4am i would be posting a patch instead of just a verbal suggestion right now -- but here's how to do it. For this kind of thing: > >>> if 1: > ... 3 > ... 4 > inconsistent dedent > File "", line 3 > 4 > ^ > SyntaxError: invalid token ...clearly it's trivial, as the case is already marked in the code (tokenizer.c). Instead of dumping the "inconsistent dedent" message to stderr, return E_INDENT. For this situation: > >>> 3 > File "", line 1 > 3 > ^ > SyntaxError: invalid syntax ...we have an INDENT where none is expected. This is also easy. At the end of PyParser_AddToken, we simply check to see if the token that caused the problem was indent-related: if (type == INDENT || type == DEDENT) return E_INDENT; Finally, the most interesting case: > >>> if 1: > ... 3 > File "", line 2 > 3 > ^ > SyntaxError: invalid syntax ...we expected an INDENT and didn't get one. This is a matter of checking the accelerator table to see what we were expecting. Also not really that hard: int expected; /* at the top of PyParser_AddToken */ ... if (s->s_lower == s->s_upper - 1) /* only one possibility */ { expected = ps->p_grammar->g_ll.ll_label[s->s_lower].lb_type; if (expected == INDENT || expected == DEDENT) return E_INDENT; } I like this last case best, as it means we can produce more useful messages for a variety of syntax errors! When there is a single particular kind of token expected, now Python can tell you what it is. After inserting this: /* Stuck, report syntax error */ fprintf(stderr, "Syntax error: unexpected %s", _PyParser_TokenNames[type]); if (s->s_lower == s->s_upper - 1) { fprintf(stderr, " (wanted %s)", _PyParser_TokenNames[labels[s->s_lower].lb_type]); } fprintf(stderr, "\n"); ... i played around a bit: >>> (3,4] Syntax error: unexpected RSQB (wanted RPAR) File "", line 1 (3,4] ^ SyntaxError: invalid syntax >>> 3.. Syntax error: unexpected NEWLINE (wanted NAME) File "", line 1 3.. ^ SyntaxError: invalid syntax >>> 3.) Syntax error: unexpected RPAR File "", line 1 3.) ^ SyntaxError: invalid syntax >>> a^^ Syntax error: unexpected CIRCUMFLEX File "", line 1 a^^ ^ SyntaxError: invalid syntax >>> if 3: ... 3 Syntax error: unexpected NUMBER (wanted INDENT) File "", line 2 3 ^ SyntaxError: invalid syntax >>> 4,, Syntax error: unexpected COMMA File "", line 1 4,, ^ SyntaxError: invalid syntax >>> [3,) Syntax error: unexpected RPAR (wanted RSQB) File "", line 1 [3,) ^ SyntaxError: invalid syntax >>> if a == 3 and Syntax error: unexpected NEWLINE File "", line 1 if a == 3 and ^ SyntaxError: invalid syntax >>> if a = 3: Syntax error: unexpected EQUAL (wanted COLON) File "", line 1 if a = 3: ^ SyntaxError: invalid syntax This isn't going to cover all cases, but i thought it was pretty cool. So, in summary: - Producing E_INDENT errors is easy, and should require just three small changes (one in tokenizer.c and two in parser.c, specifically PyParser_AddToken) - We can get some info we need to produce better syntax error messages in general, but this requires a little more thought about how to pass the info back out of the parser to pythonrun.c (err_input). -- ?!ng "This code is better ihan any code that doesn't work has any right to be." -- Roger Gregory, on Xanadu From fredrik at pythonware.com Tue Jul 4 14:40:09 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 14:40:09 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> <3961C632.CFADDC65@lemburg.com> <3961CF2F.113EC4F7@lemburg.com> Message-ID: <002a01bfe5b4$fdeb1820$0900a8c0@SPIFF> mal wrote: > Hmm, with "#define _XOPEN_SOURCE 500" I get these (new) errors: > > ./posixmodule.c: In function `posix_tmpnam': > ./posixmodule.c:3494: warning: assignment makes pointer from integer without a cast looks like a bug in the header files; SUSv2 says that this should be defined in stdio.h... > ./signalmodule.c:83: `SIGMAX' undeclared here (not in a function) > ./signalmodule.c:83: size of array `Handlers' has non-integer type but this one is stranger; as far as I can tell, SIGMAX is not part of SUSv2 at all. and what's worse, I cannot find any suitable replacement. does it work better if you just define _XOPEN_SOURCE, without any specific value? or maybe you should just add _GNU_SOURCE to make it work on your box. I promise to play with this on our Unix boxes, but not today... From mal at lemburg.com Tue Jul 4 16:03:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 16:03:37 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> <3961C632.CFADDC65@lemburg.com> <3961CF2F.113EC4F7@lemburg.com> <002a01bfe5b4$fdeb1820$0900a8c0@SPIFF> Message-ID: <3961EEB9.413FF4FF@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Hmm, with "#define _XOPEN_SOURCE 500" I get these (new) errors: > > > > ./posixmodule.c: In function `posix_tmpnam': > > ./posixmodule.c:3494: warning: assignment makes pointer from integer > without a cast > > looks like a bug in the header files; SUSv2 says that > this should be defined in stdio.h... The header files on my machine only define tmpnam_r in case __USE_MISC is true. The latter is defined for either BSD or SysV compatibility, yet not by _XOPEN_SOURCE. > > ./signalmodule.c:83: `SIGMAX' undeclared here (not in a function) > > ./signalmodule.c:83: size of array `Handlers' has non-integer type > > but this one is stranger; as far as I can tell, SIGMAX is not > part of SUSv2 at all. and what's worse, I cannot find any > suitable replacement. I guess we should patch signalmodule.c to fall back to _NSIG instead of trying SIGMAX. I'll check in a fix later today. > does it work better if you just define _XOPEN_SOURCE, without any > specific value? Same errors. > or maybe you should just add _GNU_SOURCE to make > it work on your box. I promise to play with this on our Unix boxes, > but not today... Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at cnri.reston.va.us Tue Jul 4 16:13:47 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 4 Jul 2000 10:13:47 -0400 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <3961B221.4F7552C3@lemburg.com>; from mal@lemburg.com on Tue, Jul 04, 2000 at 11:45:05AM +0200 References: <3961B221.4F7552C3@lemburg.com> Message-ID: <20000704101347.A14382@newcnri.cnri.reston.va.us> On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: >#ifdef __GNUC__ ># define _GNU_SOURCE >#endif Doesn't it make more sense to define _GNU_SOURCE only if the C library is glibc? You could be using GCC on Solaris with Sun's libc, for example, where _GNU_SOURCE would be meaningless. Probably you have to define _XOPEN_SOURCE everywhere, and _GNU_SOURCE if the libc is glibc. --amk From fredrik at pythonware.com Tue Jul 4 16:22:34 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 4 Jul 2000 16:22:34 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <3961BFCB.DD7895E1@lemburg.com> <01fe01bfe5a8$1a49e4e0$0900a8c0@SPIFF> <3961C632.CFADDC65@lemburg.com> <3961CF2F.113EC4F7@lemburg.com> <002a01bfe5b4$fdeb1820$0900a8c0@SPIFF> <3961EEB9.413FF4FF@lemburg.com> Message-ID: <002a01bfe5c3$4c5ed510$0900a8c0@SPIFF> mal wrote: > > looks like a bug in the header files; SUSv2 says that > > this should be defined in stdio.h... > > The header files on my machine only define tmpnam_r in > case __USE_MISC is true. The latter is defined for either > BSD or SysV compatibility, yet not by _XOPEN_SOURCE. oh, sorry. looks like I was off by two here, and thought you were talking about tmpnam. fwiw, SUSv2 seems to say that tmpnam is thread safe, if used in the right way. there is no tmpnam_r in SUSv2. I'll dig into this later (maybe they've added things in SUSv3). > > > ./signalmodule.c:83: `SIGMAX' undeclared here (not in a function) > > > ./signalmodule.c:83: size of array `Handlers' has non-integer type > > > > but this one is stranger; as far as I can tell, SIGMAX is not > > part of SUSv2 at all. and what's worse, I cannot find any > > suitable replacement. > > I guess we should patch signalmodule.c to fall back to _NSIG > instead of trying SIGMAX. sounds reasonable (or rather, I haven't got a clue, so I'll have to trust you on this one ;-) cheers /F From mal at lemburg.com Tue Jul 4 16:22:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 16:22:50 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <20000704101347.A14382@newcnri.cnri.reston.va.us> Message-ID: <3961F33A.28E2B980@lemburg.com> Andrew Kuchling wrote: > > On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: > >#ifdef __GNUC__ > ># define _GNU_SOURCE > >#endif > > Doesn't it make more sense to define _GNU_SOURCE only if the C library > is glibc? You could be using GCC on Solaris with Sun's libc, for > example, where _GNU_SOURCE would be meaningless. Probably you have to > define _XOPEN_SOURCE everywhere, and _GNU_SOURCE if the libc is glibc. Good point... it should probably read: #ifdef __GLIBC__ # define _GNU_SOURCE #else # define _XOPEN_SOURCE 500 #endif I'll do some more testing later today. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Tue Jul 4 19:32:41 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 13:32:41 -0400 (EDT) Subject: [Python-Dev] Making -tt the default In-Reply-To: References: Message-ID: <14690.8121.869315.508174@cj42289-a.reston1.va.home.com> Tim Peters writes: > It occurs to me that I had Emacs set up (in my own .emacs) to never ever use > literal tab characters. That may go a way in explaining why pymode never > generated ambiguous indentation for me! I have: (setq-default indent-tabs-mode nil) Perhaps python-mode should include (setq indent-tabs-mode nil) just for python-mode buffers, if it doesn't already. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Jul 4 19:40:56 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 13:40:56 -0400 (EDT) Subject: [Python-Dev] Re: [ Patch #100719 ] Use '#!/usr/bin/env python' in scripts In-Reply-To: <010101bfe598$d88381b0$0900a8c0@SPIFF> References: <20000703233938.N29590@lyra.org> <010101bfe598$d88381b0$0900a8c0@SPIFF> Message-ID: <14690.8616.285301.679626@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > This patch suggests changing /usr/local/bin/python to > /usr/bin/env python in cgi.py and faqwiz.py. Note > that both scripts are CGI scripts, and the FAQ has the > following to say about that: > > http://www.python.org/doc/FAQ.html#4.63 > > Note -- *don't* do this for CGI scripts. The $PATH > variable for CGI scripts is often very minimal, so > you need to use the actual absolute pathname of > the interpreter. > > -1, in other words (assuming that the FAQ is correct) The FAQ is correct. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Tue Jul 4 19:45:17 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 19:45:17 +0200 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... Message-ID: <396222AD.8312C32@lemburg.com> While fiddling around with the _GNU_SOURCE define I found that there are several warnings left in the current CVS version which should be removed, I guess. Here's the list I get from compiling the tree using -Wall grouped by C file: bufferobject.c: In function `PyBuffer_New': bufferobject.c:174: warning: value computed is not used classobject.c: In function `instance_dealloc': classobject.c:526: warning: unused variable `_Py_RefTotal' object.c: In function `_PyTrash_deposit_object': object.c:1172: warning: unused variable `hold' object.c:1171: warning: `typecode' might be used uninitialized in this function ceval.c: In function `eval_code2': ceval.c:333: warning: `opcode' might be used uninitialized in this function ceval.c:334: warning: `oparg' might be used uninitialized in this function pystate.c: In function `PyInterpreterState_New': pystate.c:45: warning: value computed is not used ./gcmodule.c: In function `debug_cycle': ./gcmodule.c:295: warning: unsigned int format, long unsigned int arg (arg 5) ./gcmodule.c: In function `collect': ./gcmodule.c:374: warning: int format, long int arg (arg 3) ./gcmodule.c:374: warning: int format, long int arg (arg 4) ./gcmodule.c:374: warning: int format, long int arg (arg 5) ./gcmodule.c:438: warning: int format, long int arg (arg 3) ./gcmodule.c:438: warning: int format, long int arg (arg 4) ./gcmodule.c: In function `collect_generations': ./gcmodule.c:458: warning: `n' might be used uninitialized in this function ./pypcre.c: In function `compile_branch': ./pypcre.c:1222: warning: `c' might be used uninitialized in this function ./pypcre.c: In function `pcre_exec': ./pypcre.c:4524: warning: variable `start_bits' might be clobbered by `longjmp' or `vfork' ./pypcre.c:4525: warning: variable `start_match' might be clobbered by `longjmp' or `vfork' ./posixmodule.c: At top level: ./posixmodule.c:496: warning: `posix_strint' defined but not used _sre.c: In function `pattern_match': _sre.c:819: warning: `mark1' might be used uninitialized in this function _sre.c:819: warning: `mark0' might be used uninitialized in this function ./_sre.c:819: warning: `mark1' might be used uninitialized in this function ./_sre.c:819: warning: `mark0' might be used uninitialized in this function _sre.c: In function `pattern_search': _sre.c:985: warning: `prefix_len' might be used uninitialized in this function _sre.c:819: warning: `mark0' might be used uninitialized in this function [...many more of these... all referencing line 819] In file included from ./mmapmodule.c:24: ../Include/Python.h:18: warning: `_GNU_SOURCE' redefined ./mmapmodule.c:21: warning: this is the location of the previous definition [...looks like someone needed _GNU_SOURCE too ;-)...] ./parsermodule.c: In function `validate_arglist': ./parsermodule.c:2089: warning: `ok' might be used uninitialized in this function -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Jul 4 19:48:35 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 19:48:35 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <20000704101347.A14382@newcnri.cnri.reston.va.us> <3961F33A.28E2B980@lemburg.com> Message-ID: <39622373.7C65C72C@lemburg.com> "M.-A. Lemburg" wrote: > > Andrew Kuchling wrote: > > > > On Tue, Jul 04, 2000 at 11:45:05AM +0200, M.-A. Lemburg wrote: > > >#ifdef __GNUC__ > > ># define _GNU_SOURCE > > >#endif > > > > Doesn't it make more sense to define _GNU_SOURCE only if the C library > > is glibc? You could be using GCC on Solaris with Sun's libc, for > > example, where _GNU_SOURCE would be meaningless. Probably you have to > > define _XOPEN_SOURCE everywhere, and _GNU_SOURCE if the libc is glibc. > > Good point... it should probably read: > > #ifdef __GLIBC__ > # define _GNU_SOURCE > #else > # define _XOPEN_SOURCE 500 > #endif > > I'll do some more testing later today. The testing showed that the above switch doesn't work: __GLIBC__ is defined in features.h which is included by all standard C lib headers in glibc. The following finally made the warnings in timemodule.c go away: /* Enable compiler features including SUSv2 compatibility; switching on C lib defines doesn't work here, because the symbols haven't necessarily been defined yet. */ #define _GNU_SOURCE 1 #define _XOPEN_SOURCE 500 Defining _GNU_SOURCE on non glibc platforms shouldn't hurt, so I simply dropped the switch. Should I check this in ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Tue Jul 4 19:53:15 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 13:53:15 -0400 (EDT) Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <018a01bfe59f$da814950$0900a8c0@SPIFF> References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> Message-ID: <14690.9355.219446.754205@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > what does "fixes warnings" mean? does it change the compiler's > behaviour, or does it just make sure stuff are defined in the right > files? There's a strptime() declaration about halfway down the file in an #if 0 section; this has to be enabled on Linux to get rid of a warning. Defining _GNU_SOURCE at the top of the file also gets rid of the warning, but defining _XOPEN_SOURCE doesn't; in that case I get more: gcc -fpic -g -O2 -I../../Modules/../Include -I.. -DHAVE_CONFIG_H -c ../../Modules/timemodule.c ../../Modules/timemodule.c: In function `inittime': ../../Modules/timemodule.c:652: structure has no member named `tm_gmtoff' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:653: structure has no member named `tm_zone' ../../Modules/timemodule.c:657: structure has no member named `tm_gmtoff' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' ../../Modules/timemodule.c:658: structure has no member named `tm_zone' make[1]: *** [timemodule.o] Error 1 make: *** [sharedmods] Error 2 > how is this different from just a plain (and truly portable) > #define _XOPEN_SOURCE? A valid concern, but most of _GNU_SOURCE is just shorthand to make sure just about every non-conflicting declaration is made, so that differences between other platforms "standard" declarations aren't as much of a problem. But I'm not advocating it for general use; the sources are already working well aside from this one warning in timemodule.c; defining _GNU_SOURCE here is sufficient as far as I can tell. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From DavidA at ActiveState.com Tue Jul 4 19:59:25 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 4 Jul 2000 10:59:25 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14690.8121.869315.508174@cj42289-a.reston1.va.home.com> Message-ID: > Tim Peters writes: > > It occurs to me that I had Emacs set up (in my own .emacs) to > never ever use > > literal tab characters. That may go a way in explaining why > pymode never > > generated ambiguous indentation for me! > > I have: > > (setq-default indent-tabs-mode nil) > > Perhaps python-mode should include > > (setq indent-tabs-mode nil) > > just for python-mode buffers, if it doesn't already. +1 --david From fdrake at beopen.com Tue Jul 4 20:25:28 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 14:25:28 -0400 (EDT) Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <39622373.7C65C72C@lemburg.com> References: <3961B221.4F7552C3@lemburg.com> <20000704101347.A14382@newcnri.cnri.reston.va.us> <3961F33A.28E2B980@lemburg.com> <39622373.7C65C72C@lemburg.com> Message-ID: <14690.11288.36303.553802@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > /* Enable compiler features including SUSv2 compatibility; switching > on C lib defines doesn't work here, because the symbols haven't > necessarily been defined yet. */ > #define _GNU_SOURCE 1 > #define _XOPEN_SOURCE 500 ... > Should I check this in ? This works for me; I presume you putting this before all other #includes? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Jul 4 20:43:47 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 14:43:47 -0400 (EDT) Subject: [Python-Dev] Making -tt the default In-Reply-To: References: <14690.8121.869315.508174@cj42289-a.reston1.va.home.com> Message-ID: <14690.12387.705074.991760@cj42289-a.reston1.va.home.com> David Ascher writes: > +1 I've submitted patch #100729 on SourceForge and assigned it to Barry. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Jul 4 20:50:57 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 4 Jul 2000 14:50:57 -0400 (EDT) Subject: [Python-Dev] Making the CVS tree pass the -Wall test... In-Reply-To: <396222AD.8312C32@lemburg.com> References: <396222AD.8312C32@lemburg.com> Message-ID: <14690.12817.194151.569623@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Here's the list I get from compiling the tree using -Wall > grouped by C file: Feel free to fix these! (I agree they should be done, but I need to pull away from email and these little proto-buglets so I can actually get done some of the things on my list. ;) > ./parsermodule.c: In function `validate_arglist': > ./parsermodule.c:2089: warning: `ok' might be used uninitialized in this function Ok, I've fixed this one, since it's probably my fault. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Tue Jul 4 21:00:38 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 21:00:38 +0200 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... References: <396222AD.8312C32@lemburg.com> <14690.12817.194151.569623@cj42289-a.reston1.va.home.com> Message-ID: <39623456.E8B0B833@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > Here's the list I get from compiling the tree using -Wall > > grouped by C file: > > Feel free to fix these! (I agree they should be done, but I need to > pull away from email and these little proto-buglets so I can actually > get done some of the things on my list. ;) Same here ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Jul 4 21:05:01 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 21:05:01 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <20000704101347.A14382@newcnri.cnri.reston.va.us> <3961F33A.28E2B980@lemburg.com> <39622373.7C65C72C@lemburg.com> <14690.11288.36303.553802@cj42289-a.reston1.va.home.com> Message-ID: <3962355D.7FD7429@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > /* Enable compiler features including SUSv2 compatibility; switching > > on C lib defines doesn't work here, because the symbols haven't > > necessarily been defined yet. */ > > #define _GNU_SOURCE 1 > > #define _XOPEN_SOURCE 500 > ... > > Should I check this in ? > > This works for me; I presume you putting this before all other > #includes? Right. I've added some ifdefs just to make sure. This is how my Python.h file looks now: ... See the file "Misc/COPYRIGHT" for information on usage and redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES. ******************************************************************/ /* Enable compiler features including SUSv2 compatibility; switching on C lib defines doesn't work here, because the symbols haven't necessarily been defined yet. */ #ifndef _GNU_SOURCE # define _GNU_SOURCE 1 #endif #ifndef _XOPEN_SOURCE # define _XOPEN_SOURCE 500 #endif /* Include nearly all Python header files */ #include "patchlevel.h" #include "config.h" ... Other opinions ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Tue Jul 4 22:58:46 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jul 2000 22:58:46 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <20000704200730.617431D0CE@dinsdale.python.org> Message-ID: <39625006.A0F7B0C0@lemburg.com> billtut at microsoft.com wrote: > > Full_Name: Bill Tutt > Version: CVS > OS: NT > Submission from: tide70.microsoft.com (131.107.3.70) > > u'\ud800' causes the interpreter to crash > example: > print u'\ud800' > What happens: > The code failes to compile because while adding the constant, the unicode_hash > function is called which for some reason requires the UTF-8 string format. The reasoning at the time was that dictionaries should accept Unicode objects as keys which match their string equivalents as the same key, e.g. 'abc' works just as well as u'abc'. UTF-8 was the default encoding back then. I'm not sure how to fix the hash value given the new strategy w/r to the default encoding... According to the docs, objects comparing equal should have the same hash value, yet this would require the hash value to be calculated using the default encoding and that would not only cause huge performance problems, but could effectively render Unicode useless, because not all default encodings are lossless (ok, one could work around this by falling back to some other way of calculating the hash value in case the conversion fails). Looks like we have a problem here :-/ > The conversion to UTF-8 fails (completly bogus), the compiler only notes that > compilation failed, and cleared the stored exception info. > > When compilatino finishes it remembered that it failed, and returns. > The interpreter then proceeds to crash in PyErr_NormalizeException() because the > UTF-8 conversion exception info isn't there anymore. > > Suggested fix: > Changing the UTF-8 conversion code to emit 4 bytes for surrogate characters. > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list at python.org > http://www.python.org/mailman/listinfo/python-bugs-list -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping at lfw.org Tue Jul 4 23:40:21 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Tue, 4 Jul 2000 14:40:21 -0700 (PDT) Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) In-Reply-To: <39625006.A0F7B0C0@lemburg.com> Message-ID: On Tue, 4 Jul 2000, M.-A. Lemburg wrote: > > The reasoning at the time was that dictionaries should accept > Unicode objects as keys which match their string equivalents > as the same key, e.g. 'abc' works just as well as u'abc'. [...] > According to the docs, objects comparing equal should have the > same hash value, yet this would require the hash value to be > calculated using the default encoding and that > would not only cause huge performance problems, but could > effectively render Unicode useless, Given the new 7-bit-ASCII-as-default-encoding-for-8-bit-strings convention, shouldn't just hashing the character values work fine? That is, hash('abc') should == hash(u'abc'), no conversion required. -- ?!ng From jack at oratrix.nl Tue Jul 4 23:50:02 2000 From: jack at oratrix.nl (Jack Jansen) Date: Tue, 04 Jul 2000 23:50:02 +0200 Subject: [Python-Dev] PyArg_ParseTuple and 16 bit bitpatterns Message-ID: <20000704215007.957B2E2673@oratrix.oratrix.nl> I've adapted PyArg_ParseTuple (and Py_BuildValue) to understand the H format specifier, which is meant for 16-bit bitpatterns. (in case you didn't follow the discussion last month: the old lowercase h now checks values to be in the range -32768..32767, so constants like 0x8000 are not acceptable anymore). I haven't added an I and L specifier, because (surprise, surprise:-) for 32-bit integers 0x80000000 turns out to be a legal value, unlike for their poor 16-bit brethren. I've currently implemented H as meaning unsigned (i.e. 0..0xffff), but on second thoughts I think allowing -32768..0xffff might be better: there's probably lots of code out there that passes -1 when all 16 flag bits should be set. Please let me know if you have strong opinions on either meaning before I check this in. Note that I'll only adapt PyArg_ParseTuple and the gazzilion mac-specific occurrences of "h" where a 16-bit pattern is needed. I've done only a very cursory check of other occurences of "h", but someone else will have to pick that up if they feel like. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From jack at oratrix.nl Tue Jul 4 23:53:36 2000 From: jack at oratrix.nl (Jack Jansen) Date: Tue, 04 Jul 2000 23:53:36 +0200 Subject: [Python-Dev] Sre tests failing Message-ID: <20000704215342.18235E2673@oratrix.oratrix.nl> Since this weekend lots of test.autotest tests fail on my Mac because sre seems to lack lots of stuff that re did have. And as /F has been rather quiet these last 24 hours: is this a problem only I have and i should investigate, or should I quietly wait for it to be fixed shortly? Failing tests include test_sre, test_xmllib, test_strftime and test_tokenize, to name a few. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From martin at loewis.home.cs.tu-berlin.de Wed Jul 5 00:12:03 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed, 5 Jul 2000 00:12:03 +0200 Subject: [Python-Dev] Copyright notice Message-ID: <200007042212.AAA01334@loewis.home.cs.tu-berlin.de> > I think I recall this was a convention that the GNU folks claim is > required from a legal standpoint. The GPL requires such a message, specifically 2c) c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) So if you modify gdb, you'll have to update the copyright notice it prints. Please note the exception: some programs (e.g. bash) don't "normally" print a message, so you don't have to add one. In any case, I believe this is just a GPL requirement - for Python, you could have it behave in any way you please. > On the other hand, why does it bother you? I don't bother too much, and I hadn't said anything if I didn't expect the message to change anyway. The interactive prompt of Python 2 will be shown on page 1 of the next print of my Python book, and I did not mean to go into Python's history until page 14 :-) Regards, Martin From billtut at microsoft.com Wed Jul 5 00:39:26 2000 From: billtut at microsoft.com (Bill Tutt) Date: Tue, 4 Jul 2000 15:39:26 -0700 Subject: [Python-Dev] RE: \ud800 crashes interpreter (PR#384) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD269@RED-MSG-50> > MAL wrotw: >> Bill wrote: >> u'\ud800' causes the interpreter to crash >> example: >> print u'\ud800' >> What happens: >> The code failes to compile because while adding the constant, the unicode_hash >> function is called which for some reason requires the UTF-8 string format. > The reasoning at the time was that dictionaries should accept > Unicode objects as keys which match their string equivalents > as the same key, e.g. 'abc' works just as well as u'abc'. > UTF-8 was the default encoding back then. I'm not sure how > to fix the hash value given the new strategy w/r to the > default encoding... > According to the docs, objects comparing equal should have the > same hash value, yet this would require the hash value to be > calculated using the default encoding and that > would not only cause huge performance problems, but could > effectively render Unicode useless, because not all default > encodings are lossless (ok, one could work around this by > falling back to some other way of calculating the hash > value in case the conversion fails). Yeah, yeah, yeah. I know all that, just never liked it. :) The current problem is that the UTF-8 can't round trip surrogate characters atm. This is easy to fix, so I'm doing a patch to fix this oversight, unless you beat me to it. Anything else is slightly more annoying to fix. Bill From effbot at telia.com Wed Jul 5 01:44:15 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 01:44:15 +0200 Subject: [Python-Dev] Sre tests failing References: <20000704215342.18235E2673@oratrix.oratrix.nl> Message-ID: <001e01bfe611$c60df820$f2a6b5d4@hagrid> > Since this weekend lots of test.autotest tests fail on my Mac because > sre seems to lack lots of stuff that re did have. And as /F has been > rather quiet these last 24 hours: is this a problem only I have and i > should investigate, or should I quietly wait for it to be fixed > shortly? > > Failing tests include test_sre, test_xmllib, test_strftime and > test_tokenize, to name a few. test_sre.py should work (if you compare the output against the output/test_sre file, that is -- see the repository copy of that file for a list of things that are expected to break...) I think test_tokenize should work too... test_xmllib appears to be broken on my box (possibly caused by SRE). test_strftime complains about tons of stuff on my Win95 box; dunno if it's done that way on purpose... From effbot at telia.com Wed Jul 5 01:46:07 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 01:46:07 +0200 Subject: [Python-Dev] SRE incompatibility References: <20000704095542.8697B31047C@bireme.oratrix.nl> Message-ID: <002601bfe612$06e90ec0$f2a6b5d4@hagrid> sjoerd wrote: > >>> re.match(regexp, 'smil').group(0,1,2,3) > ('smil', None, 's', 'smil') > >>> import pre > >>> pre.match(regexp, 'smil').group(0,1,2,3) > ('smil', None, None, 'smil') > > Needless to say, I am relying on the third value being None... I've confirmed this (last night's fix should have solved this, but it didn't). I'll post patches as soon as I have them... From trentm at activestate.com Wed Jul 5 01:42:58 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 4 Jul 2000 16:42:58 -0700 Subject: [Python-Dev] PyArg_ParseTuple and 16 bit bitpatterns In-Reply-To: <20000704215007.957B2E2673@oratrix.oratrix.nl> References: <20000704215007.957B2E2673@oratrix.oratrix.nl> Message-ID: <20000704164258.B5972@activestate.com> Hi Jack, I am your evil man for this one (but then you already knew that). On Tue, Jul 04, 2000 at 11:50:02PM +0200, Jack Jansen wrote: > I've adapted PyArg_ParseTuple (and Py_BuildValue) to understand the H > format specifier, which is meant for 16-bit bitpatterns. (in case you > didn't follow the discussion last month: the old lowercase h now > checks values to be in the range -32768..32767, so constants like > 0x8000 are not acceptable anymore). I think that the Right Answer is: b = signed byte B = unsigned byte h = signed short H = unsigned short i = signed int I = unsigned int l = signed long L = unsigned long Before my patch we had (no range checking was done so signed vs. unsigned made no difference): b = byte h = short i = int l = long L = LONG_LONG After my patch (i.e. now) we have: b = unsigned byte h = signed short i = signed int l = signed long L = signed LONG_LONG Notes on that: - Choosing signed or unsigned for each was based on the common case (or presuming what the common case was). I.e. unsigned bytes are more common than signed bytes. - unsigned byte is 'b' and not (my ideal) 'B', for backward compatibility reasons - LONG_LONG as 'L' really sucks because that is the blocker to PyArg_ParseTuple nirvana (my first list). It should be 'q' and 'Q' for Quad or something like that. Your patch is adding (right?): H = unsigned short Aside: Now that it will be called 2.0 would we maybe want to go for the Right Answer. I suspect that a *lot* more people would complain of breakage with the use of 'L' changing to 'Q', and that I am asking for a lynching. > > I haven't added an I and L specifier, because (surprise, surprise:-) > for 32-bit integers 0x80000000 turns out to be a legal value, unlike > for their poor 16-bit brethren. I can't see how 'I' allows 0x80000000 (unless, of course, sizeof(int) > 4 on your machine) because the 'I' formatter is not in PyArg_ParseTuple. Yes, 'L' will probably accept 0x80000000 because LONG_LONG is probably 64-bits wide on your machine hence. > > I've currently implemented H as meaning unsigned (i.e. 0..0xffff), but I woudl suggest allowing [0, USHRT_MAX]. Should be defined in limits.h (guessing), I think. > on second thoughts I think allowing -32768..0xffff might be better: > there's probably lots of code out there that passes -1 when all 16 > flag bits should be set. Please let me know if you have strong I think that uses of -1 should use either USHRT_MAX or (unsigned short)-1. > opinions on either meaning before I check this in. > > Note that I'll only adapt PyArg_ParseTuple and the > gazzilion mac-specific occurrences of "h" where a 16-bit pattern is > needed. I've done only a very cursory check of other occurences of > "h", but someone else will have to pick that up if they feel like. > I am sorry to have been the cause of work for you. I just think that the 'security' offered by bounds checking all values converted by PyArg_ParseTuple is important. Trent -- Trent Mick trentm at activestate.com From tim_one at email.msn.com Wed Jul 5 07:51:07 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 01:51:07 -0400 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... In-Reply-To: <396222AD.8312C32@lemburg.com> Message-ID: [M.-A. Lemburg] > While fiddling around with the _GNU_SOURCE define I found > that there are several warnings left in the current CVS > version which should be removed, I guess. > > Here's the list I get from compiling the tree using -Wall > grouped by C file: So long as any warnings remain, would you please repost the list from time to time? There's no need to group them by file. > ./pypcre.c:4524: warning: variable `start_bits' might be > clobbered by `longjmp' or `vfork' > ./pypcre.c:4525: warning: variable `start_match' might be > clobbered by `longjmp' or `vfork' These are often a PITA to fix: gcc does brain-dead flow analysis, and this particular msg is almost always bogus as a result. There are several open bugs filed against gcc on this (I know because one of them is mine ). The others look straightforward to fix (on a first scan). From martin at loewis.home.cs.tu-berlin.de Wed Jul 5 08:50:54 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed, 5 Jul 2000 08:50:54 +0200 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... Message-ID: <200007050650.IAA00972@loewis.home.cs.tu-berlin.de> >> ./pypcre.c:4524: warning: variable `start_bits' might be >> clobbered by `longjmp' or `vfork' >> ./pypcre.c:4525: warning: variable `start_match' might be >> clobbered by `longjmp' or `vfork' > These are often a PITA to fix: gcc does brain-dead flow analysis, and this > particular msg is almost always bogus as a result. There are several open > bugs filed against gcc on this (I know because one of them is mine ). > The others look straightforward to fix (on a first scan). At least for start_match, what exactly is bogus about this message? setjmp is invoked in line 4691 of pypcre, and start_match is modified in line 4737, at the end of the while loop containing the setjmp call. If somebody would invoke longjmp on the jmp_buf after start_match is modified, it would have an indeterminate value, according to 7.13.2.1p3 of C99. Likewise for start_bits, as it may also be modified after setjmp() has been called, since it appears in the same loop. I admit that there wouldn't be too many calls that could actually invoke longjmp() before the next invocation of setjmp, except perhaps for pchars(), but gcc is not supposed to determine potential callers of longjmp: The compiler sees only the calls to `setjmp'. It cannot know where `longjmp' will be called; in fact, a signal handler could call it at any point in the code. As a result, you may get a warning even when there is in fact no problem because `longjmp' cannot in fact be called at the place which would cause a problem. So while I'd admit that gcc "does brain-dead flow analysis", I think this particular msg is not bogus in this specific case. It's more often than not that gcc users fail to understand this message, though. Regards, Martin From rob at hooft.net Wed Jul 5 09:02:53 2000 From: rob at hooft.net (Rob W. W. Hooft) Date: Wed, 5 Jul 2000 09:02:53 +0200 (CEST) Subject: [Python-Dev] Spelling check: more typos Message-ID: <14690.56733.627266.907044@temoleh.chem.uu.nl> I got some positive comments on my previous load of spelling checks, so I spent another evening using some ispell, some spell, and some special python code to look for more spelling errors in the python source code. Base was the CVS on 2 July. There are a few more 'problematic' cases in here: First: American vs. British spelling. Since most text is in American spelling, I "corrected" some words from the British spelling to the American. I haven't done that with everything, especially in modules where British-spelling variable names are used. Then 2 points on distutils: - the word "licence" is used throughout, and "license" is introduced as alternative. The other way around looks more natural to me. - the term "anal retentives" should probably be replaced before 2.0 Furthermore: there is still a lib/stdwin manual. Shouldn't that be removed too? Is "s's" as in "the process's exit code" valid English? I seem to remember that for words in s, the final s should be dropped. Is it "Lance Ellinghouse" or "Ellinghaus"? I uploaded my patch to the patch manager (as unidiff, sorry, but it is large enough in the current form, and for spelling corrections easy enough to follow). Rob Hooft -- ===== rob at hooft.net http://www.hooft.net/people/rob/ ===== ===== R&D, Nonius BV, Delft http://www.nonius.nl/ ===== ===== PGPid 0xFA19277D ========================== Use Linux! ========= From gstein at lyra.org Wed Jul 5 09:52:09 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 5 Jul 2000 00:52:09 -0700 Subject: [Python-Dev] Re: [Patches] Patch 100718 -- LinuxThreads vs. Pth In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jul 05, 2000 at 09:38:13AM +0300 References: Message-ID: <20000705005209.J29590@lyra.org> On Wed, Jul 05, 2000 at 09:38:13AM +0300, Moshe Zadka wrote: > > I'm +1 on this -- LinuxThreads is more-or-less Posix compliant, and is > based on Kernel level support. It seems much closer to the norm in the > Linux world then Pth. This patch is a huge +1. We should *never* prefer Pth over LinuxThreads. Never. Ever. Hell... there isn't really "LinuxThreads" any more -- it is part of glibc. We really shouldn't take an external package over the core C library. Pth is a user-mode thread package. That should not be used by Python unless somebody specifically requests it. Gah. How did that Pth get preferred installation... I'm off to fix this sucker. Big time. There is a separate problem for how somebody can override the selection mechanism. But we're talking defaults here, and we should select the proper default. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Wed Jul 5 09:55:55 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 09:55:55 +0200 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... References: Message-ID: <3962EA0B.2EBED7A8@lemburg.com> Tim Peters wrote: > > [M.-A. Lemburg] > > While fiddling around with the _GNU_SOURCE define I found > > that there are several warnings left in the current CVS > > version which should be removed, I guess. > > > > Here's the list I get from compiling the tree using -Wall > > grouped by C file: > > So long as any warnings remain, would you please repost the list from time > to time? There's no need to group them by file. Ok. Note that the idea behind posting the list was to make module authors/editors aware of warnings in their code... Fred already made his changes -- it would probably be a good idea if the others did the same. > > ./pypcre.c:4524: warning: variable `start_bits' might be > > clobbered by `longjmp' or `vfork' > > ./pypcre.c:4525: warning: variable `start_match' might be > > clobbered by `longjmp' or `vfork' > > These are often a PITA to fix: gcc does brain-dead flow analysis, and this > particular msg is almost always bogus as a result. There are several open > bugs filed against gcc on this (I know because one of them is mine ). > The others look straightforward to fix (on a first scan). That one has been in Python since pcre was adopted -- I don't think there's much we can do about it either... but then: sre is coming on strong so we might as well drop pcre for say 2.1. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Wed Jul 5 10:06:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 5 Jul 2000 11:06:06 +0300 (IDT) Subject: [Python-Dev] SF Beuracracy again Message-ID: Is there a difference between what SF calls "developers" and what we informally call "poeple with commit access"? Can anyone clear the stati people can have with regard to the Python project? (I've just revived my account on SF because of Python...) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From tim_one at email.msn.com Wed Jul 5 10:14:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 04:14:22 -0400 Subject: [Python-Dev] RE: [Patches] Patch 100718 -- LinuxThreads vs. Pth In-Reply-To: Message-ID: [moved from patches to python-dev] [Moshe] > (Question to PythonLabs team: any hope of getting the patch contents in > e-mail? It's much easier to comment that way) Seems really a question for SourceForge at this point. If we could have, we would have by now. From mal at lemburg.com Wed Jul 5 10:34:27 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 10:34:27 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: Message-ID: <3962F313.186B10FB@lemburg.com> Ka-Ping Yee wrote: > > On Tue, 4 Jul 2000, M.-A. Lemburg wrote: > > > > The reasoning at the time was that dictionaries should accept > > Unicode objects as keys which match their string equivalents > > as the same key, e.g. 'abc' works just as well as u'abc'. > [...] > > According to the docs, objects comparing equal should have the > > same hash value, yet this would require the hash value to be > > calculated using the default encoding and that > > would not only cause huge performance problems, but could > > effectively render Unicode useless, > > Given the new 7-bit-ASCII-as-default-encoding-for-8-bit-strings > convention, shouldn't just hashing the character values work > fine? That is, hash('abc') should == hash(u'abc'), no conversion > required. Yes, and it does so already for pure ASCII values. The problem comes from the fact that the default encoding can be changed to a locale specific value (site.py does the lookup for you), e.g. given you have defined LANG to be us_en, Python will default to Latin-1 as default encoding. This results in '???' == u'???', but hash('???') != hash(u'???'), which is in conflict with the general rule about objects having the same hash value if they compare equal. Now, I could go and change the internal cache buffer to hold the default encoding instead of UTF-8, but this would affect not only hash(), but also the 's' and 't' parser markers, etc. ... I wonder why compiling "print u'\uD800'" causes the hash value to be computed ... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jul 5 10:37:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 10:37:23 +0200 Subject: [Python-Dev] RE: \ud800 crashes interpreter (PR#384) References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD269@RED-MSG-50> Message-ID: <3962F3C3.74A7825D@lemburg.com> Bill Tutt wrote: > > > MAL wrotw: > >> Bill wrote: > >> u'\ud800' causes the interpreter to crash > >> example: > >> print u'\ud800' > >> What happens: > >> The code failes to compile because while adding the constant, the > unicode_hash > >> function is called which for some reason requires the UTF-8 string > format. > > > The reasoning at the time was that dictionaries should accept > > Unicode objects as keys which match their string equivalents > > as the same key, e.g. 'abc' works just as well as u'abc'. > > > UTF-8 was the default encoding back then. I'm not sure how > > to fix the hash value given the new strategy w/r to the > > default encoding... > > > According to the docs, objects comparing equal should have the > > same hash value, yet this would require the hash value to be > > calculated using the default encoding and that > > would not only cause huge performance problems, but could > > effectively render Unicode useless, because not all default > > encodings are lossless (ok, one could work around this by > > falling back to some other way of calculating the hash > > value in case the conversion fails). > > Yeah, yeah, yeah. I know all that, just never liked it. :) > The current problem is that the UTF-8 can't round trip surrogate characters > atm. > This is easy to fix, so I'm doing a patch to fix this oversight, unless you > beat me to it. > > Anything else is slightly more annoying to fix. I left out surrogates in the UTF-8 codec on purpose: the Python implementation currently doesn't have support for these, e.g. slicing doesn't care about UTF-16 surrogates, so I made sure that people using these get errors ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Wed Jul 5 11:05:16 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 05:05:16 -0400 Subject: [Python-Dev] RE: Making the CVS tree pass the -Wall test... In-Reply-To: <200007050650.IAA00972@loewis.home.cs.tu-berlin.de> Message-ID: >> ./pypcre.c:4524: warning: variable `start_bits' might be >> clobbered by `longjmp' or `vfork' >> ./pypcre.c:4525: warning: variable `start_match' might be >> clobbered by `longjmp' or `vfork' [Tim sez these are almost always bogus wngs, Martin sez these two are legit] The start_bits wng is bogus because start_bit's only definition points precede the do-loop: start_bits will either be NULL or extra->start_bits by the time the "do" is entered, and can never change after that (yes, start_bits "appears" in the loop, but not as an lvalue -- it's only referenced). So the value setjmp tucks away is necessarily the correct value for longjmp to restore. This is a purely local flow question; knowledge of when a longjmp may occur isn't needed. I agree the start_match wng is legit. In my previous life, I tracked down about a hundred of these, and found only one that was legit. So pypcre is as sick as Dragon's half-million lines of speech recognition code . "The usual" way to fix this is to slop "volatile" onto the declarations, as the author already did for three other locals. That's the second reason this warning sucks: it depends on which locals gcc decides to carry in registers, and that varies from release to release. And that's the third reason this warning sucks: gcc is actually complaining about its *own* decision to carry something in a register <0.1 wink -- and if it *knows* it's not safe to carry something in a register, it shouldn't!>. From tim_one at email.msn.com Wed Jul 5 11:07:59 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 05:07:59 -0400 Subject: [Python-Dev] Making the CVS tree pass the -Wall test... In-Reply-To: <3962EA0B.2EBED7A8@lemburg.com> Message-ID: [MAL] > While fiddling around with the _GNU_SOURCE define I found > that there are several warnings left in the current CVS > version which should be removed, I guess. [Tim] > So long as any warnings remain, would you please repost the > list from time to time? There's no need to group them by file. [MAL] > Ok. > > Note that the idea behind posting the list was to make > module authors/editors aware of warnings in their code... Fred > already made his changes -- it would probably be a good idea > if the others did the same. Of course. That's why I'm asking you to repost this list until no wngs remain . one-time-implicit-nags-don't-work-ly y'rs - tim From tim_one at email.msn.com Wed Jul 5 11:11:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 05:11:18 -0400 Subject: [Python-Dev] SF Beuracracy again In-Reply-To: Message-ID: [Moshe Zadka] > Is there a difference between what SF calls "developers" and what we > informally call "poeple with commit access"? Not that I know of. > Can anyone clear the stati > people can have with regard to the Python project? Try rephrasing that question in a known language . Ah, plural of "status"? You're a developer or you're not, and if you're a developer you're an admin or you're not. That's it. > (I've just revived my account on SF because of Python...) If you're looking for sympathy, this is the wrong list . From fredrik at pythonware.com Wed Jul 5 11:14:21 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 11:14:21 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> Message-ID: <007f01bfe661$68b26080$0900a8c0@SPIFF> mal wrote: > > Given the new 7-bit-ASCII-as-default-encoding-for-8-bit-strings > > convention, shouldn't just hashing the character values work > > fine? That is, hash('abc') should == hash(u'abc'), no conversion > > required. > > Yes, and it does so already for pure ASCII values. The problem > comes from the fact that the default encoding can be changed to > a locale specific value (site.py does the lookup for you), e.g. > given you have defined LANG to be us_en, Python will default > to Latin-1 as default encoding. footnote: in practice, this is a Unix-only feature. I suggest adding code to the _locale module (or maybe sys is better?) which can be used to dig up a suitable encoding for non-Unix platforms. On Windows, the code page should be "cp%d" % GetACP(). I'll look into this later today. From thomas at xs4all.net Wed Jul 5 11:15:09 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 5 Jul 2000 11:15:09 +0200 Subject: [Python-Dev] python 2.0 and '-tt' Message-ID: <20000705111509.J13469@xs4all.nl> I seem to recall someone claiming that the behaviour of the -tt flag was going to be the default in the next 'major' release of Python. Seeing as how the socket.socket change is back in again, it might be worth looking at this again ? Then again, I'm a newbie, it might be a done deal already, one way or the other ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mwh21 at cam.ac.uk Wed Jul 5 11:19:29 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Wed, 5 Jul 2000 10:19:29 +0100 (BST) Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <14690.56733.627266.907044@temoleh.chem.uu.nl> Message-ID: On Wed, 5 Jul 2000, Rob W. W. Hooft wrote: [schnipp] > Then 2 points on distutils: > - the word "licence" is used throughout, and "license" is introduced as > alternative. The other way around looks more natural to me. Isn't one the noun (licence) and one the verb (license)? (mind you dictionary.com doesn't think so, so I'd say pick one and stick with it). > - the term "anal retentives" should probably be replaced before 2.0 This reminds me of when they took out the swear words from the sources to linuk-kernel :-) > Is "s's" as in "the process's exit code" valid English? I think yes, because "process" is not a plural; it would be "processes' exit codes". but-then-I'm-a-mathematician-ly y'rs Michael From mal at lemburg.com Wed Jul 5 11:27:21 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 11:27:21 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> <007f01bfe661$68b26080$0900a8c0@SPIFF> Message-ID: <3962FF79.B1A773D0@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > Given the new 7-bit-ASCII-as-default-encoding-for-8-bit-strings > > > convention, shouldn't just hashing the character values work > > > fine? That is, hash('abc') should == hash(u'abc'), no conversion > > > required. > > > > Yes, and it does so already for pure ASCII values. The problem > > comes from the fact that the default encoding can be changed to > > a locale specific value (site.py does the lookup for you), e.g. > > given you have defined LANG to be us_en, Python will default > > to Latin-1 as default encoding. > > footnote: in practice, this is a Unix-only feature. > > I suggest adding code to the _locale module (or maybe sys is > better?) which can be used to dig up a suitable encoding for > non-Unix platforms. On Windows, the code page should be > "cp%d" % GetACP(). > > I'll look into this later today. Could you add code to the _locale module which interfaces to GetACP() on win32 ? locale.get_default could then make use of this API to figure out the encoding. Ideal would be another API for win32 which allows querying the active language (it would have to return an RFC 1766 language code or we could add aliasis to the locale_alias database). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Wed Jul 5 11:38:55 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 11:38:55 +0200 Subject: [Python-Dev] Spelling check: more typos References: Message-ID: <009501bfe664$d6845ca0$0900a8c0@SPIFF> > Isn't one the noun (licence) and one the verb (license)? (mind you > dictionary.com doesn't think so, so I'd say pick one and stick with it). fwiw, none of the dictionaries I've checked agree with you. and they all seem to prefer "license" over "licence". > > Is "s's" as in "the process's exit code" valid English? > > I think yes, because "process" is not a plural; it would be "processes' > exit codes". according to the only grammar I found: FORMING THE POSSESSIVE WITH 'S AND ' 1.Singular nouns take 's 2.irregular plurals take 's 3.Nouns ending in s (plural or singular) take ' > but-then-I'm-a-mathematician-ly y'rs and we're a bunch of non-native english speakers ;-) From mal at lemburg.com Wed Jul 5 11:53:10 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 11:53:10 +0200 Subject: [Python-Dev] Docs for string methods ? Message-ID: <39630586.A253198A@lemburg.com> I've just checked in new string methods which provide access to the C APIs isalpha and isalnum for both strings and Unicode objects. Question: where should I put the docs ? I haven't found any place in the current CVS tree which document the new string methods -- even though all of them have doc strings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Wed Jul 5 12:01:21 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 12:01:21 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> Message-ID: <00d101bfe667$f9099d00$0900a8c0@SPIFF> mal wrote: > I've just checked in new string methods talking about string methods: how about providing an "encode" method for 8-bit strings too? From esr at thyrsus.com Wed Jul 5 12:09:43 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Jul 2000 06:09:43 -0400 Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <009501bfe664$d6845ca0$0900a8c0@SPIFF>; from fredrik@pythonware.com on Wed, Jul 05, 2000 at 11:38:55AM +0200 References: <009501bfe664$d6845ca0$0900a8c0@SPIFF> Message-ID: <20000705060943.A18539@thyrsus.com> Fredrik Lundh : > > Isn't one the noun (licence) and one the verb (license)? (mind you > > dictionary.com doesn't think so, so I'd say pick one and stick with it). > > fwiw, none of the dictionaries I've checked agree with you. > and they all seem to prefer "license" over "licence". > > > > Is "s's" as in "the process's exit code" valid English? > > > > I think yes, because "process" is not a plural; it would be "processes' > > exit codes". > > according to the only grammar I found: > > FORMING THE POSSESSIVE WITH 'S AND ' > 1.Singular nouns take 's > 2.irregular plurals take 's > 3.Nouns ending in s (plural or singular) take ' > > > but-then-I'm-a-mathematician-ly y'rs > > and we're a bunch of non-native english speakers ;-) I am a native speaker, and an expert in the fine points of English grammar and usage (a necessary qualification for editing the New Hacker's Dictionary). Tim's source is correct. Learn these rules; they will mark you out from the vast sea of yahoos who (for example) use "it's" where "its" is correct. (Guido's English is impressively correct, BTW. The rest of you non-native speakers -- and some of you native ones -- could learn from him.) -- Eric S. Raymond You [should] not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harm it would cause if improperly administered -- Lyndon Johnson, former President of the U.S. From mwh21 at cam.ac.uk Wed Jul 5 12:06:11 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Wed, 5 Jul 2000 11:06:11 +0100 (BST) Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <20000705060943.A18539@thyrsus.com> Message-ID: On Wed, 5 Jul 2000, Eric S. Raymond wrote: > Fredrik Lundh : > > > > Is "s's" as in "the process's exit code" valid English? > > > > > > I think yes, because "process" is not a plural; it would be "processes' > > > exit codes". > > > > according to the only grammar I found: > > > > FORMING THE POSSESSIVE WITH 'S AND ' > > 1.Singular nouns take 's > > 2.irregular plurals take 's > > 3.Nouns ending in s (plural or singular) take ' > > > > > but-then-I'm-a-mathematician-ly y'rs > > > > and we're a bunch of non-native english speakers ;-) > > I am a native speaker, and an expert in the fine points of English grammar > and usage (a necessary qualification for editing the New Hacker's > Dictionary). Tim's source is correct. Tim? Do you mean /F? > Learn these rules; they will mark you out from the vast sea of yahoos > who (for example) use "it's" where "its" is correct. Well, the given rules don't account for that one do they? "Process' exit code" just looks wrong to me. Don't know why. Cheers, M. From mal at lemburg.com Wed Jul 5 12:06:21 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 12:06:21 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> Message-ID: <3963089D.8144149C@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > I've just checked in new string methods > > talking about string methods: how about providing an > "encode" method for 8-bit strings too? I've tossed that idea around a few times too... it could have the same interface as the Unicode one (without default encoding though). The only problem is that there are currently no codecs which could deal with strings on input. String codecs would have to be of the form 'latin1_utf8', that is, have implicit knowledge about the input encoding (and not only the output encoding as with Unicode codecs). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Wed Jul 5 12:15:54 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 12:15:54 +0200 Subject: [Python-Dev] Spelling check: more typos References: <009501bfe664$d6845ca0$0900a8c0@SPIFF> <20000705060943.A18539@thyrsus.com> Message-ID: <010901bfe66a$017d8b70$0900a8c0@SPIFF> eric wrote: > > > > Is "s's" as in "the process's exit code" valid English? > > > > > > I think yes, because "process" is not a plural; it would be "processes' > > > exit codes". > > > > according to the only grammar I found: > > > > FORMING THE POSSESSIVE WITH 'S AND ' > > 1.Singular nouns take 's > > 2.irregular plurals take 's > > 3.Nouns ending in s (plural or singular) take ' > > > > > but-then-I'm-a-mathematician-ly y'rs > > > > and we're a bunch of non-native english speakers ;-) > > I am a native speaker, and an expert in the fine points of English grammar > and usage (a necessary qualification for editing the New Hacker's > Dictionary). Tim's source is correct. Learn these rules; they will > mark you out from the vast sea of yahoos who (for example) use "it's" > where "its" is correct. what rules? the "tim is always correct" rule, or the grammar rules I quoted? From esr at thyrsus.com Wed Jul 5 12:24:34 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Jul 2000 06:24:34 -0400 Subject: [Python-Dev] Spelling check: more typos In-Reply-To: ; from mwh21@cam.ac.uk on Wed, Jul 05, 2000 at 11:06:11AM +0100 References: <20000705060943.A18539@thyrsus.com> Message-ID: <20000705062434.A18614@thyrsus.com> Michael Hudson : > > > FORMING THE POSSESSIVE WITH 'S AND ' > > > 1.Singular nouns take 's > > > 2.irregular plurals take 's > > > 3.Nouns ending in s (plural or singular) take ' > > > > > I am a native speaker, and an expert in the fine points of English grammar > > and usage (a necessary qualification for editing the New Hacker's > > Dictionary). Tim's source is correct. > > Tim? Do you mean /F? I believe /F was quoting Tim. > > Learn these rules; they will mark you out from the vast sea of yahoos > > who (for example) use "it's" where "its" is correct. > > Well, the given rules don't account for that one do they? Hm, I guess you have to know that pronouns pluralize irregularly to cover that case. What creates the confusion is that "it's" is the correct contraction of "it is", but looks like a possessive inflection of the pronoun "it". -- Eric S. Raymond "You have taught us much. Come with us and join the movement." "This movement of yours, does it have slogans?" inquired the Chink. "Right on!" they cried. And they quoted him some. "Your movement, does it have a flag?" asked the Chink. "You bet!" and they described their emblem. "And does your movement have leaders?" "Great leaders." "Then shove it up your butts," said the Chink. "I have taught you nothing." -- Tom Robbins, "Even Cowgirls Get The Blues" From fredrik at pythonware.com Wed Jul 5 12:20:04 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 12:20:04 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> Message-ID: <011101bfe66a$96d18aa0$0900a8c0@SPIFF> mal wrote: > Fredrik Lundh wrote: > > > > mal wrote: > > > I've just checked in new string methods > > > > talking about string methods: how about providing an > > "encode" method for 8-bit strings too? > > I've tossed that idea around a few times too... it could > have the same interface as the Unicode one (without default > encoding though). The only problem is that there are currently > no codecs which could deal with strings on input. imho, a consistent interface is more important than a truly optimal implementation (string are strings yada yada). or in other words, def encode(self, encoding): if encoding is close enough: return self return unicode(self).encode(encoding) ought to be good enough for now. From mal at lemburg.com Wed Jul 5 12:29:11 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 12:29:11 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> <011101bfe66a$96d18aa0$0900a8c0@SPIFF> Message-ID: <39630DF7.4B7ADB63@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Fredrik Lundh wrote: > > > > > > mal wrote: > > > > I've just checked in new string methods > > > > > > talking about string methods: how about providing an > > > "encode" method for 8-bit strings too? > > > > I've tossed that idea around a few times too... it could > > have the same interface as the Unicode one (without default > > encoding though). The only problem is that there are currently > > no codecs which could deal with strings on input. > > imho, a consistent interface is more important than a truly > optimal implementation (string are strings yada yada). or in > other words, > > def encode(self, encoding): > if encoding is close enough: > return self > return unicode(self).encode(encoding) > > ought to be good enough for now. Ideally str() should have an encoding parameter too. Then I could add generic PyString_Encode|Decode|AsEncodedString APIs to stringobject.c which match the corresponding ones in unicodeobject.c gzippeddata = file.read() # Unzip a data packet (decode part of the codec) data = str(gzippeddata, 'data_gzip') # Zip a data packet (encode part of the codec) gzippeddata = data.encode('data_gzip') Looks cool ;-) Note that 'abc'.encode('utf8') would fail because the UTF-8 codec expects Unicod on input to its encode method (hmm, perhaps I ought to make the method use the 'u' parser marker instead of 'U' -- that way, the method would auto-convert the 'abc' string to Unicode using the default encoding and then proceed to encode it in UTF-8). Other opinions ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jul 5 12:32:33 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 12:32:33 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> <011101bfe66a$96d18aa0$0900a8c0@SPIFF> <39630DF7.4B7ADB63@lemburg.com> Message-ID: <39630EC1.891DCE8F@lemburg.com> "M.-A. Lemburg" wrote: > > Note that 'abc'.encode('utf8') would fail because the UTF-8 > codec expects Unicod on input to its encode method (hmm, perhaps > I ought to make the method use the 'u' parser marker instead > of 'U' -- that way, the method would auto-convert the 'abc' > string to Unicode using the default encoding and then proceed > to encode it in UTF-8). Uhm, forget that last part... 'u' doesn't do auto-conversion :-( I could add that functionality to the interfaces in _codecmodule.c directly, though. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping at lfw.org Wed Jul 5 12:50:18 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 5 Jul 2000 03:50:18 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: Message-ID: On Tue, 4 Jul 2000, Ka-Ping Yee wrote: > It turns out that this should be quite easy. If it weren't > past 4am i would be posting a patch instead of just a verbal > suggestion right now -- but here's how to do it. Okay, done. Submitted to SourceForge as patch #100734. For the patch itself, see http://sourceforge.net/patch/download.php?id=100734 or http://sourceforge.net/patch/?func=detailpatch&patch_id=100734&group_id=5470 Here is a sample of the resulting behaviour: >>> if 3: ... 3 File "", line 2 3 ^ SyntaxError: expected indent here >>> 3 File "", line 1 3 ^ SyntaxError: unexpected indent >>> if 1: ... 3 ... 4 File "", line 3 4 ^ SyntaxError: dedent does not match any outer indentation level >>> if 1: ... if 2: ... 3 File "", line 3 3 ^ SyntaxError: unexpected dedent >>> if 1: ... if 2: ... 3 File "", line 3 3 ^ SyntaxError: dedent does not match any outer indentation level >>> Also (didn't want to waste pages of text demonstrating it) if you indent more than 100 levels, you get SyntaxError: too many levels of indentation instead of the current message, "invalid token". The internal changes are: 1. Added E_TOODEEP (too many indentation levels) and E_DEDENT (no matching outer block for dedent) to errcode.h. 2. Made PyTokenizer_Get (in tokenizer.c) return E_TOODEEP and E_DEDENT instead of printing messages to stderr; added corresponding error messages in err_input (in pythonrun.c). 3. Renamed E_INDENT to E_TABSPACE. 4. Added int *expected_ret argument to PyParser_AddToken; on a syntax error, PyParser_AddToken (in parser.c) places the expected token type (if any) into this output parameter. 5. Added "token" and "expected" to struct perrdetail; made parsetok (in parsetok.c) copy the current token into "token" and the expected token into "expected" on a syntax error. 6. Added checks in err_input (in pythonrun.c) to print more detailed error messages if err->token or err->expected happens to be INDENT or DEDENT when a syntax error occurs. This leaves the door open for err_input to say more interesting things about the syntax error if it wants, based on the information in err->token and err->expected, though i haven't added any more detailed messages except for the ones about indentation for now. Look good to you? -- ?!ng From gvwilson at nevex.com Wed Jul 5 13:10:33 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 5 Jul 2000 07:10:33 -0400 (EDT) Subject: [Python-Dev] re: punctuation / spelling Message-ID: The best on-line writing style guide I know of is the one used by the The Economist: http://www.economist.com/editorial/freeforall/library/index_styleguide.html Their advice on possessives is: Use the normal possessive ending 's after singular words or names that end in s: boss's, caucus's, Delors's, St James's, Jones's, Shanks's. Use it after plurals that do not end in s: children's, Frenchmen's, media's. Use the ending s' on plurals that end in s---Danes', bosses', Joneses'---including plural names that take a singular verb, eg, Reuters', Barclays', Stewarts & Lloyds', Salomon Brothers'. Although singular in other respects, the United States, the United Nations, the Philippines, etc, have a plural possessive apostrophe: eg, Who will be the United States' next president? Strunk & White is also a good, pocket-sized resource, but so far as I know there is no up-to-date edition on-line. Greg From esr at thyrsus.com Wed Jul 5 13:32:10 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Jul 2000 07:32:10 -0400 Subject: [Python-Dev] re: punctuation / spelling In-Reply-To: ; from gvwilson@nevex.com on Wed, Jul 05, 2000 at 07:10:33AM -0400 References: Message-ID: <20000705073210.B18933@thyrsus.com> Greg Wilson : > The best on-line writing style guide I know of is the one used by the The > Economist: > > http://www.economist.com/editorial/freeforall/library/index_styleguide.html I enthusiastically second this recommendation. For American use their advice is a touch British-flavored in the orthography department, but their recommendations on grammar and style are impeccable. The Economist is my favorite news magazine in the world. -- Eric S. Raymond "This country, with its institutions, belongs to the people who inhabit it. Whenever they shall grow weary of the existing government, they can exercise their constitutional right of amending it or their revolutionary right to dismember it or overthrow it." -- Abraham Lincoln, 4 April 1861 From fredrik at pythonware.com Wed Jul 5 13:51:56 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 13:51:56 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> <011101bfe66a$96d18aa0$0900a8c0@SPIFF> <39630DF7.4B7ADB63@lemburg.com> Message-ID: <02b501bfe677$6ba38b00$0900a8c0@SPIFF> mal wrote: > > > > talking about string methods: how about providing an > > > > "encode" method for 8-bit strings too? > > > > > > I've tossed that idea around a few times too... it could > > > have the same interface as the Unicode one (without default > > > encoding though). The only problem is that there are currently > > > no codecs which could deal with strings on input. > > > > imho, a consistent interface is more important than a truly > > optimal implementation (string are strings yada yada). or in > > other words, > > > > def encode(self, encoding): > > if encoding is close enough: > > return self > > return unicode(self).encode(encoding) > > > > ought to be good enough for now. /snip/ > Note that 'abc'.encode('utf8') would fail because the UTF-8 > codec expects Unicod on input to its encode method (hmm, perhaps > I ought to make the method use the 'u' parser marker instead > of 'U' -- that way, the method would auto-convert the 'abc' > string to Unicode using the default encoding and then proceed > to encode it in UTF-8). sorry, I wasn't clear: the "def encode" snippet above should be a string method, not a function. "abc".encode("utf8") would be "return self" if the default encoding is "ascii" or "utf8", and "return unicode("abc").encode("utf8")" other- wise. cheers /F From bwarsaw at beopen.com Wed Jul 5 13:56:02 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 07:56:02 -0400 (EDT) Subject: [Python-Dev] Making -tt the default References: <20000703233938.N29590@lyra.org> Message-ID: <14691.8786.180085.468266@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> (add-hook 'python-mode-hook | (lambda () | (setq indent-tabs-mode nil) | (setq py-indent-offset 2) | (setq py-smart-indentation nil) | (define-key py-mode-map "\e\C-h" 'backward-kill-word) | )) GS> The indent-tabs-mode is the key to disabling tab characters GS> and using just spaces. Greg, can you explain why you turn off py-smart-indentation? Its purpose is to give you the correct settings when editing someone else's existing code. With this variable set to t, it tries to guess the existing code's indentation level depth and then sets py-indent-offset to that value, on the assumption that 1) the original author indented their code consistently 2) it is better to be consistent with the existing indentation than impose your own and have mixed indentation Both of these are worthy goals, IMO, so py-smart-indentation should generally remain true. For brand new code, given the fact that pymode's default for py-indent-offset is 4, and Emacs' default for tab-width is 8 (and should not be changed), you'll generally find that indent-tabs-mode will be nil when py-smart-indentation is t. So I think pymode is doing the right thing, and I'm -1 on patch #100729. If the user wants indent-tabs-mode set to nil unconditionally, then setting it in your python-mode-hook, as you've done, is the Emacs way. But if someone can give a good example where this approach is flawed, please let me know. -Barry From fredrik at pythonware.com Wed Jul 5 13:57:40 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 13:57:40 +0200 Subject: [Python-Dev] Better SyntaxError messages References: Message-ID: <02bf01bfe678$3a1baee0$0900a8c0@SPIFF> ?!ng wrote: > Okay, done. Submitted to SourceForge as patch #100734. For the patch > itself, see http://sourceforge.net/patch/download.php?id=100734 or > http://sourceforge.net/patch/?func=detailpatch&patch_id=100734&group_id=5470 +2 on concept. and the patch looks clean. let's get this one in there asap! (marc-andre?) > Look good to you? you bet! From mal at lemburg.com Wed Jul 5 13:59:34 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 13:59:34 +0200 Subject: [Python-Dev] Docs for string methods ? References: <39630586.A253198A@lemburg.com> <00d101bfe667$f9099d00$0900a8c0@SPIFF> <3963089D.8144149C@lemburg.com> <011101bfe66a$96d18aa0$0900a8c0@SPIFF> <39630DF7.4B7ADB63@lemburg.com> <02b501bfe677$6ba38b00$0900a8c0@SPIFF> Message-ID: <39632326.9A724C2@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > > > talking about string methods: how about providing an > > > > > "encode" method for 8-bit strings too? > > > > > > > > I've tossed that idea around a few times too... it could > > > > have the same interface as the Unicode one (without default > > > > encoding though). The only problem is that there are currently > > > > no codecs which could deal with strings on input. > > > > > > imho, a consistent interface is more important than a truly > > > optimal implementation (string are strings yada yada). or in > > > other words, > > > > > > def encode(self, encoding): > > > if encoding is close enough: > > > return self > > > return unicode(self).encode(encoding) > > > > > > ought to be good enough for now. > > /snip/ > > > Note that 'abc'.encode('utf8') would fail because the UTF-8 > > codec expects Unicod on input to its encode method (hmm, perhaps > > I ought to make the method use the 'u' parser marker instead > > of 'U' -- that way, the method would auto-convert the 'abc' > > string to Unicode using the default encoding and then proceed > > to encode it in UTF-8). > > sorry, I wasn't clear: the "def encode" snippet above should be > a string method, not a function. > > "abc".encode("utf8") would be "return self" if the default encoding > is "ascii" or "utf8", and "return unicode("abc").encode("utf8")" other- > wise. I've just checked in modifications to the builtin codecs which allow them to accept 8-bit strings too. They will convert the strings to Unicode and then encode them as usual. So given that the .encode() method gets accepted (I haven't heard any other opinions yet), "abc".encode("utf8") will work just like any other builtin codec (the 8-bit string will be interpreted under the default encoding assumption). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jul 5 14:01:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 14:01:26 +0200 Subject: [Python-Dev] Better SyntaxError messages References: <02bf01bfe678$3a1baee0$0900a8c0@SPIFF> Message-ID: <39632396.32E4BA61@lemburg.com> Fredrik Lundh wrote: > > ?!ng wrote: > > Okay, done. Submitted to SourceForge as patch #100734. For the patch > > itself, see http://sourceforge.net/patch/download.php?id=100734 or > > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100734&group_id=5470 > > +2 on concept. > > and the patch looks clean. let's get this one in > there asap! (marc-andre?) I'd rather have someone else with more knowledge about Python's parser check this in... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Wed Jul 5 14:19:27 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 14:19:27 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> <007f01bfe661$68b26080$0900a8c0@SPIFF> <3962FF79.B1A773D0@lemburg.com> Message-ID: <02f701bfe67b$43ec51b0$0900a8c0@SPIFF> mal wrote: > Ideal would be another API for win32 which allows querying > the active language (it would have to return an RFC 1766 > language code or we could add aliasis to the locale_alias > database). A quick look indicates that Windows uses "language identifiers": http://msdn.microsoft.com/library/psdk/winbase/nls_8xo3.htm Maybe Bill can dig up some better way to do this (a "language identifier to language code" table would be nice. There's one in Windows 2000 ;-) From Vladimir.Marangozov at inrialpes.fr Wed Jul 5 14:29:36 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 5 Jul 2000 14:29:36 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Ka-Ping Yee" at Jul 05, 2000 03:50:18 AM Message-ID: <200007051229.OAA19526@python.inrialpes.fr> Ka-Ping Yee wrote: > > On Tue, 4 Jul 2000, Ka-Ping Yee wrote: > > It turns out that this should be quite easy. If it weren't > > past 4am i would be posting a patch instead of just a verbal > > suggestion right now -- but here's how to do it. > > Okay, done. Looks fine. +1 on the concept. 2 things about the patch: > > >>> if 3: > ... 3 > File "", line 2 > 3 > ^ > SyntaxError: expected indent here I'd remove the word "here" so that the error msg is self-contained. "expected indent" & "expected dedent" are fine. > The internal changes are: > > 1. Added E_TOODEEP (too many indentation levels) and > E_DEDENT (no matching outer block for dedent) to errcode.h. > > 2. Made PyTokenizer_Get (in tokenizer.c) return E_TOODEEP and > E_DEDENT instead of printing messages to stderr; added > corresponding error messages in err_input (in pythonrun.c). > > 3. Renamed E_INDENT to E_TABSPACE. > > 4. Added int *expected_ret argument to PyParser_AddToken; on > a syntax error, PyParser_AddToken (in parser.c) places the > expected token type (if any) into this output parameter. I'd suggest passing a pointer to the perrdetail structure (to the whole error, that is), instead of a pointer to one of its fields. > > 5. Added "token" and "expected" to struct perrdetail; made > parsetok (in parsetok.c) copy the current token into "token" > and the expected token into "expected" on a syntax error. > > 6. Added checks in err_input (in pythonrun.c) to print more > detailed error messages if err->token or err->expected > happens to be INDENT or DEDENT when a syntax error occurs. > > This leaves the door open for err_input to say more interesting > things about the syntax error if it wants, based on the information > in err->token and err->expected, though i haven't added any more > detailed messages except for the ones about indentation for now. > > > Look good to you? > Yes. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gvwilson at nevex.com Wed Jul 5 14:34:28 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 5 Jul 2000 08:34:28 -0400 (EDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <200007051229.OAA19526@python.inrialpes.fr> Message-ID: > On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > I'd remove the word "here" so that the error msg is self-contained. > "expected indent" & "expected dedent" are fine. I just did a poll --- only 2 out of 5 programmers in my shouting radius know what "dedent" means. Is there a more accessible way to phrase the error message? Thanks, Greg From Vladimir.Marangozov at inrialpes.fr Wed Jul 5 14:54:50 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 5 Jul 2000 14:54:50 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Greg Wilson" at Jul 05, 2000 08:34:28 AM Message-ID: <200007051254.OAA19572@python.inrialpes.fr> Greg Wilson wrote: > > > On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > > I'd remove the word "here" so that the error msg is self-contained. > > "expected indent" & "expected dedent" are fine. > > I just did a poll --- only 2 out of 5 programmers in my shouting radius > know what "dedent" means. Is there a more accessible way to phrase the > error message? Good point. Here's another suggestion: "expected indent" -> "missing expected indentation" "expected dedent" -> "missing expected closing indentation" ? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mwh21 at cam.ac.uk Wed Jul 5 15:17:49 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Wed, 5 Jul 2000 14:17:49 +0100 (BST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <200007051254.OAA19572@python.inrialpes.fr> Message-ID: On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > Greg Wilson wrote: > > > > > On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > > > I'd remove the word "here" so that the error msg is self-contained. > > > "expected indent" & "expected dedent" are fine. > > > > I just did a poll --- only 2 out of 5 programmers in my shouting radius > > know what "dedent" means. Is there a more accessible way to phrase the > > error message? > > Good point. > > Here's another suggestion: > > "expected indent" -> "missing expected indentation" +0 - doesn't really change much does it? > "expected dedent" -> "missing expected closing indentation" Eugh. How about "expected decrease in indentation"? Though I think dedent (or mabye outdent) is pretty obvious in context. Also "decrease in indentation does not match any outer level" is a pretty hefty error message. Still, these things are so much better than the status quo that I'm about +1e8 on the general idea... Cheers, Michael From Mike.Da.Silva at uk.fid-intl.com Wed Jul 5 15:27:18 2000 From: Mike.Da.Silva at uk.fid-intl.com (Da Silva, Mike) Date: Wed, 5 Jul 2000 14:27:18 +0100 Subject: [Python-Dev] Better SyntaxError messages Message-ID: Michael Hudson wrote: >On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > > Greg Wilson wrote: > > > > > > > On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > > > > I'd remove the word "here" so that the error msg is self-contained. > > > > "expected indent" & "expected dedent" are fine. > > > > > > I just did a poll --- only 2 out of 5 programmers in my shouting radius > > > know what "dedent" means. Is there a more accessible way to phrase the > > > error message? > > > > Good point. > > > > Here's another suggestion: > > > > "expected indent" -> "missing expected indentation" > +0 - doesn't really change much does it? > > "expected dedent" -> "missing expected closing indentation" > Eugh. How about "expected decrease in indentation"? Though I think > dedent (or mabye outdent) is pretty obvious in context. > Also "decrease in indentation does not match any outer level" > is a pretty hefty error message. How about "expected unindent" ? > Still, these things are so much better than the status quo that I'm about +1e8 on the general idea... > Cheers, > Michael Regards, Mike _______________________________________________ Python-Dev mailing list Python-Dev at python.org http://www.python.org/mailman/listinfo/python-dev From Vladimir.Marangozov at inrialpes.fr Wed Jul 5 15:36:37 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 5 Jul 2000 15:36:37 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Michael Hudson" at Jul 05, 2000 02:17:49 PM Message-ID: <200007051336.PAA19744@python.inrialpes.fr> Michael Hudson wrote: > > [me] > > Here's another suggestion: > > > > "expected indent" -> "missing expected indentation" > > +0 - doesn't really change much does it? It's slightly more explicit. > > > "expected dedent" -> "missing expected closing indentation" > > Eugh. How about "expected decrease in indentation"? Though I think > dedent (or mabye outdent) is pretty obvious in context. I like your correction. The problem is that "dedent" is very context-specific and it would be better if this term is avoided for user-messages, because they generally pop up out of context (i.e. when your head is in another context, so the context switch is painful). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From billtut at microsoft.com Wed Jul 5 17:26:22 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 5 Jul 2000 08:26:22 -0700 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD26A@RED-MSG-50> > MAL wrote: > ... I wonder why compiling "print u'\uD800'" causes the > hash value to be computed ... That's an easy one. Com_addconst() (or something it calls) calls PyObject_Hash() during the compilation process. Re: UTF-8 There's no reason why you can't support surrogates in UTF-8, while still not supporting them in slice notation. It's certainly the easiest way to fix the problem. Bill From mal at lemburg.com Wed Jul 5 17:40:19 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 17:40:19 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD26A@RED-MSG-50> Message-ID: <396356E3.A2F586B5@lemburg.com> Bill Tutt wrote: > > > MAL wrote: > > ... I wonder why compiling "print u'\uD800'" causes the > > hash value to be computed ... > > That's an easy one. Com_addconst() (or something it calls) calls > PyObject_Hash() during the compilation process. Ah ok. > Re: UTF-8 > There's no reason why you can't support surrogates in UTF-8, while still not > supporting them in slice notation. True. > It's certainly the easiest way to fix the problem. Well, it doesn't really fix the problem... your note only made it clear that with the change in default encoding (be it ASCII or whatever the locale defines), has the unwanted side effect of breaking the has/cmp rule for non-ASCII character strings vs. Unicode. Perhaps pushing the default encoding down all the way is the solution (with some trickery this is possible now, since changing the default encoding is only allows in site.py) or simply stating that the hash/cmp rule only works for ASCII contents of the objects. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Wed Jul 5 06:57:19 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 4 Jul 2000 23:57:19 -0500 (CDT) Subject: [Python-Dev] SyntaxError/IndentationError/WhitespaceError Message-ID: <14690.49199.153631.236949@beluga.mojam.com> Just back from the annual patriotic revelry... Here are my thoughts on the various kinds of exceptions one might raise to denote various problems with indentation. SyntaxError - the most general form of parsing error WhitespaceError - tells the user something's wrong with the way the whitespace of the line parses - what -tt mode would raise IndentationError - more specific than WhitespaceError, but indicates the lines won't line up properly (without -tt mode) - what the parser would raise for something like: try: 1/0 1/0 except ZeroDivisionError: pass The distinction between WhitespaceError and IndentationError is likely to be a bit subtle for newbies, so I wonder if it's worth the effort to distinguish the two. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From gward at mems-exchange.org Wed Jul 5 19:02:15 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 13:02:15 -0400 Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: ; from Mike.Da.Silva@uk.fid-intl.com on Wed, Jul 05, 2000 at 02:27:18PM +0100 References: Message-ID: <20000705130215.A7564@ludwig.cnri.reston.va.us> On 05 July 2000, Da Silva, Mike said: > > > "expected dedent" -> "missing expected closing indentation" > > > Eugh. How about "expected decrease in indentation"? Though I think > > dedent (or mabye outdent) is pretty obvious in context. > > > Also "decrease in indentation does not match any outer level" > > is a pretty hefty error message. > > How about "expected unindent" ? I was going to suggest "unindent" from the moment I saw Ping's patch, so let me just chime in with a "yes indeed!". Also, along with the rest of the known universe, I strongly favour the proposed change. Haven't tried the patch yet, but I will. Greg From Vladimir.Marangozov at inrialpes.fr Wed Jul 5 19:12:37 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 5 Jul 2000 19:12:37 +0200 (CEST) Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <3962355D.7FD7429@lemburg.com> from "M.-A. Lemburg" at Jul 04, 2000 09:05:01 PM Message-ID: <200007051712.TAA20213@python.inrialpes.fr> M.-A. Lemburg wrote: > > I've added some ifdefs just to make sure. This is how my > Python.h file looks now: > > ... > See the file "Misc/COPYRIGHT" for information on usage and > redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES. > ******************************************************************/ > > /* Enable compiler features including SUSv2 compatibility; switching > on C lib defines doesn't work here, because the symbols haven't > necessarily been defined yet. */ > #ifndef _GNU_SOURCE > # define _GNU_SOURCE 1 > #endif > #ifndef _XOPEN_SOURCE > # define _XOPEN_SOURCE 500 > #endif Typically this should go to a new file -- pyport.h, suggested by Greg, included at the top of Python.h (and which allows to cleanup the HAVE_LIMITS_H define and others). We may introduce subsequently pyport.c if needed. Anything wrong with this? Opinions? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Wed Jul 5 19:12:31 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 19:12:31 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <200007051712.TAA20213@python.inrialpes.fr> Message-ID: <39636C7F.D0A29101@lemburg.com> Vladimir Marangozov wrote: > > M.-A. Lemburg wrote: > > > > I've added some ifdefs just to make sure. This is how my > > Python.h file looks now: > > > > ... > > See the file "Misc/COPYRIGHT" for information on usage and > > redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES. > > ******************************************************************/ > > > > /* Enable compiler features including SUSv2 compatibility; switching > > on C lib defines doesn't work here, because the symbols haven't > > necessarily been defined yet. */ > > #ifndef _GNU_SOURCE > > # define _GNU_SOURCE 1 > > #endif > > #ifndef _XOPEN_SOURCE > > # define _XOPEN_SOURCE 500 > > #endif > > Typically this should go to a new file -- pyport.h, suggested by Greg, > included at the top of Python.h (and which allows to cleanup the > HAVE_LIMITS_H define and others). We may introduce subsequently pyport.c > if needed. > > Anything wrong with this? Opinions? Fine with me... I'd name it pyportability.h like Greg suggested, though. Note that the above is already checked into CVS (and the first bug related to it has shown up too; also fixed in CVS). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Wed Jul 5 19:39:29 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 19:39:29 +0200 Subject: [Python-Dev] locale.setlocale vs. locale.set_locale Message-ID: <006a01bfe6a7$fa696000$f2a6b5d4@hagrid> maybe it's just me, but I think it's a bit confusing to have two functions in the same module with very similar names: >>> import locale >>> print locale.setlocale.__doc__ (integer,string=None) -> string. Activates/queries locale processing. >>> print locale.set_locale.__doc__ Set the locale according to the localetuple (language code, encoding) as returned by get_locale() and get_default(). The given codes are passed through the locale aliasing engine before being given to setlocale() for processing. category may be given as one of the LC_* values. It defaults to LC_ALL. maybe "setlocale" should be changed to accept either a string or a tuple? (from which follows that get_locale should be "getlocale", and get_default "getdefaultlocale". or something...) (btw, maybe both doc strings should mention the arguments? or maybe none of them should? what does the style guide say?) From effbot at telia.com Wed Jul 5 19:47:55 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 19:47:55 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> <007f01bfe661$68b26080$0900a8c0@SPIFF> <3962FF79.B1A773D0@lemburg.com> <02f701bfe67b$43ec51b0$0900a8c0@SPIFF> Message-ID: <007f01bfe6aa$28e52d40$f2a6b5d4@hagrid> I wrote: > A quick look indicates that Windows uses "language identifiers": > http://msdn.microsoft.com/library/psdk/winbase/nls_8xo3.htm > > Maybe Bill can dig up some better way to do this (a "language > identifier to language code" table would be nice. There's one > in Windows 2000 ;-) nevermind; I've crafted a piece of code that digs out the RFC 1766 language code (e.g. en-EN) and the code page (e.g. cp1252), on Win98/NT4/2000. unfortunately, Win95 won't give me the language code; it insists on using "language identifiers" (such as 041d). guess we need a table after all. oh well. patch follows. From mal at lemburg.com Wed Jul 5 19:53:43 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 19:53:43 +0200 Subject: [Python-Dev] Re: \ud800 crashes interpreter (PR#384) References: <3962F313.186B10FB@lemburg.com> <007f01bfe661$68b26080$0900a8c0@SPIFF> <3962FF79.B1A773D0@lemburg.com> <02f701bfe67b$43ec51b0$0900a8c0@SPIFF> <007f01bfe6aa$28e52d40$f2a6b5d4@hagrid> Message-ID: <39637627.BFDA941A@lemburg.com> Fredrik Lundh wrote: > > I wrote: > > > A quick look indicates that Windows uses "language identifiers": > > http://msdn.microsoft.com/library/psdk/winbase/nls_8xo3.htm > > > > Maybe Bill can dig up some better way to do this (a "language > > identifier to language code" table would be nice. There's one > > in Windows 2000 ;-) > > nevermind; I've crafted a piece of code that digs out the RFC 1766 > language code (e.g. en-EN) and the code page (e.g. cp1252), on > Win98/NT4/2000. > > unfortunately, Win95 won't give me the language code; it insists > on using "language identifiers" (such as 041d). guess we need a > table after all. oh well. > > patch follows. Great :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jul 5 20:02:04 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 20:02:04 +0200 Subject: [Python-Dev] locale.setlocale vs. locale.set_locale References: <006a01bfe6a7$fa696000$f2a6b5d4@hagrid> Message-ID: <3963781C.DD06D0DE@lemburg.com> Fredrik Lundh wrote: > > maybe it's just me, but I think it's a bit confusing to have two > functions in the same module with very similar names: > > >>> import locale > > >>> print locale.setlocale.__doc__ > (integer,string=None) -> string. Activates/queries locale processing. > > >>> print locale.set_locale.__doc__ > Set the locale according to the localetuple (language code, > encoding) as returned by get_locale() and get_default(). > > The given codes are passed through the locale aliasing engine > before being given to setlocale() for processing. > > category may be given as one of the LC_* values. It defaults > to LC_ALL. The new set_locale() is meant to complement get_locale(); both work on tuples (langcode, encoding). setlocale() has a completely different interface: it uses a locale category integer together with a setup string. The reasoning here was to add a higher level interface on top of setlocale() which is the direct interface to the underlying low level C API. The underscore variants provide aliasing support and knows about the formats which the setlocale() API will accept -- at least on Linux setlocale() is very picky about case and layout of the setup string. > maybe "setlocale" should be changed to accept either a > string or a tuple? > > (from which follows that get_locale should be "getlocale", and > get_default "getdefaultlocale". or something...) If you want to change anything here: now is the time ;-) Please also adapt site.py which uses these APIs. > (btw, maybe both doc strings should mention the arguments? or > maybe none of them should? what does the style guide say?) I always thought that the arguments should only be mentioned for C functions... not sure, though. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jul 5 20:11:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 20:11:08 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) Message-ID: <39637A3C.9489CB15@lemburg.com> The idea is not new: strings and Unicode should have more or less the same methods to enhance their compatibility. The attached patch adds encoding capabilities to normal strings and extends the builtin str() to accept an optional encoding (and error) argument. It also tries to reuse the already available Unicode codecs for the purposes of strings (conversions are done via the default encoding in both directions). With it you can use the existing codecs to easily encode or decode strings and data into string objects: >>> 'abc'.encode('utf16') '\377\376a\000b\000c\000' >>> str(_, 'utf16') 'abc' Since the codec API and registry support more than just Unicode codecs, one could also think of things like: '...long...data...string...'.encode('data_gzip') or other complicated string conversions. The str(obj[, encoding[, errors]]) builtin does the exact opposite: it takes the string representation of obj and then decodes it using the given encoding. What do you think about this ? Should I add it to CVS as experiment ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ -------------- next part -------------- diff -u -rbP -x *.o -x *.pyc -x Makefile -x *~ -x *.so -x add2lib -x pgen -x buildno -x core -x config.* -x libpython* -x python -x Setup -x Setup.local -x Setup.thread -x Setup.config -x hassignal -x Makefile.pre -x configure -x *.bak -x *.s -x DEADJOE -x *.rej -x *.orig -x Demo -x CVS -x Doc -x *.orig -x .#* -x distutils -x */plat* -x *.py -x ACKS -x *.txt -x README CVS-Python/Include/stringobject.h Python+Unicode/Include/stringobject.h --- CVS-Python/Include/stringobject.h Sat Jul 1 10:30:46 2000 +++ Python+Unicode/Include/stringobject.h Wed Jul 5 18:59:46 2000 @@ -81,6 +81,37 @@ #define PyString_AS_STRING(op) (((PyStringObject *)(op))->ob_sval) #define PyString_GET_SIZE(op) (((PyStringObject *)(op))->ob_size) +/* --- Generic Codecs ----------------------------------------------------- */ + +/* Create a string object by decoding the encoded string s of the + given size. */ + +extern DL_IMPORT(PyObject*) PyString_Decode( + const char *s, /* encoded string */ + int size, /* size of buffer */ + const char *encoding, /* encoding */ + const char *errors /* error handling */ + ); + +/* Encodes a char buffer of the given size and returns a + Python string object. */ + +extern DL_IMPORT(PyObject*) PyString_Encode( + const char *s, /* string char buffer */ + int size, /* number of chars to encode */ + const char *encoding, /* encoding */ + const char *errors /* error handling */ + ); + +/* Encodes a string object and returns the result as Python string + object. */ + +extern DL_IMPORT(PyObject*) PyString_AsEncodedString( + PyObject *str, /* string object */ + const char *encoding, /* encoding */ + const char *errors /* error handling */ + ); + #ifdef __cplusplus } #endif diff -u -rbP -x *.o -x *.pyc -x Makefile -x *~ -x *.so -x add2lib -x pgen -x buildno -x core -x config.* -x libpython* -x python -x Setup -x Setup.local -x Setup.thread -x Setup.config -x hassignal -x Makefile.pre -x configure -x *.bak -x *.s -x DEADJOE -x *.rej -x *.orig -x Demo -x CVS -x Doc -x *.orig -x .#* -x distutils -x */plat* -x *.py -x ACKS -x *.txt -x README CVS-Python/Objects/stringobject.c Python+Unicode/Objects/stringobject.c --- CVS-Python/Objects/stringobject.c Wed Jul 5 11:42:49 2000 +++ Python+Unicode/Objects/stringobject.c Wed Jul 5 19:47:44 2000 @@ -152,6 +152,100 @@ return (PyObject *) op; } +PyObject *PyString_Decode(const char *s, + int size, + const char *encoding, + const char *errors) +{ + PyObject *buffer = NULL, *str; + + if (encoding == NULL) + encoding = PyUnicode_GetDefaultEncoding(); + + /* Decode via the codec registry */ + buffer = PyBuffer_FromMemory((void *)s, size); + if (buffer == NULL) + goto onError; + str = PyCodec_Decode(buffer, encoding, errors); + if (str == NULL) + goto onError; + /* Convert Unicode to a string using the default encoding */ + if (PyUnicode_Check(str)) { + PyObject *temp = str; + str = PyUnicode_AsEncodedString(str, NULL, NULL); + Py_DECREF(temp); + if (str == NULL) + goto onError; + } + if (!PyString_Check(str)) { + PyErr_Format(PyExc_TypeError, + "decoder did not return an string object (type=%.400s)", + str->ob_type->tp_name); + Py_DECREF(str); + goto onError; + } + Py_DECREF(buffer); + return str; + + onError: + Py_XDECREF(buffer); + return NULL; +} + +PyObject *PyString_Encode(const char *s, + int size, + const char *encoding, + const char *errors) +{ + PyObject *v, *str; + + str = PyString_FromStringAndSize(s, size); + if (str == NULL) + return NULL; + v = PyString_AsEncodedString(str, encoding, errors); + Py_DECREF(str); + return v; +} + +PyObject *PyString_AsEncodedString(PyObject *str, + const char *encoding, + const char *errors) +{ + PyObject *v; + + if (!PyString_Check(str)) { + PyErr_BadArgument(); + goto onError; + } + + if (encoding == NULL) + encoding = PyUnicode_GetDefaultEncoding(); + + /* Encode via the codec registry */ + v = PyCodec_Encode(str, encoding, errors); + if (v == NULL) + goto onError; + /* Convert Unicode to a string using the default encoding */ + if (PyUnicode_Check(v)) { + PyObject *temp = v; + v = PyUnicode_AsEncodedString(v, NULL, NULL); + Py_DECREF(temp); + if (v == NULL) + goto onError; + } + if (!PyString_Check(v)) { + PyErr_Format(PyExc_TypeError, + "encoder did not return a string object (type=%.400s)", + v->ob_type->tp_name); + Py_DECREF(v); + goto onError; + } + return v; + + onError: + return NULL; +} + static void string_dealloc(op) PyObject *op; @@ -1686,6 +1780,25 @@ } +static char encode__doc__[] = +"S.encode([encoding[,errors]]) -> string\n\ +\n\ +Return an encoded string version of S. Default encoding is the current\n\ +default string encoding. errors may be given to set a different error\n\ +handling scheme. Default is 'strict' meaning that encoding errors raise\n\ +a ValueError. Other possible values are 'ignore' and 'replace'."; + +static PyObject * +string_encode(PyStringObject *self, PyObject *args) +{ + char *encoding = NULL; + char *errors = NULL; + if (!PyArg_ParseTuple(args, "|ss:encode", &encoding, &errors)) + return NULL; + return PyString_AsEncodedString((PyObject *)self, encoding, errors); +} + + static char expandtabs__doc__[] = "S.expandtabs([tabsize]) -> string\n\ \n\ @@ -2252,6 +2365,7 @@ {"ljust", (PyCFunction)string_ljust, 1, ljust__doc__}, {"rjust", (PyCFunction)string_rjust, 1, rjust__doc__}, {"center", (PyCFunction)string_center, 1, center__doc__}, + {"encode", (PyCFunction)string_encode, 1, encode__doc__}, {"expandtabs", (PyCFunction)string_expandtabs, 1, expandtabs__doc__}, {"splitlines", (PyCFunction)string_splitlines, 1, splitlines__doc__}, #if 0 diff -u -rbP -x *.o -x *.pyc -x Makefile -x *~ -x *.so -x add2lib -x pgen -x buildno -x core -x config.* -x libpython* -x python -x Setup -x Setup.local -x Setup.thread -x Setup.config -x hassignal -x Makefile.pre -x configure -x *.bak -x *.s -x DEADJOE -x *.rej -x *.orig -x Demo -x CVS -x Doc -x *.orig -x .#* -x distutils -x */plat* -x *.py -x ACKS -x *.txt -x README CVS-Python/Python/bltinmodule.c Python+Unicode/Python/bltinmodule.c --- CVS-Python/Python/bltinmodule.c Tue Jul 4 10:30:50 2000 +++ Python+Unicode/Python/bltinmodule.c Wed Jul 5 19:40:14 2000 @@ -2050,18 +2050,39 @@ PyObject *self; PyObject *args; { - PyObject *v; + PyObject *v, *w; + const void *buffer; + int len; + char *encoding = NULL; + char *errors = NULL; - if (!PyArg_ParseTuple(args, "O:str", &v)) + if ( !PyArg_ParseTuple(args, "O|ss:str", &v, &encoding, &errors) ) return NULL; - return PyObject_Str(v); + + /* Get string representation */ + if (PyString_Check(v)) + Py_INCREF(v); + else + v = PyObject_Str(v); + if (encoding == NULL) + return v; + + /* Decode data raw */ + if (PyObject_AsReadBuffer(v, &buffer, &len)) + return NULL; + w = PyString_Decode((const char *)buffer, len, encoding, errors); + Py_DECREF(v); + return w; } static char str_doc[] = -"str(object) -> string\n\ +"str(object [, encoding[, errors]]) -> string\n\ \n\ -Return a nice string representation of the object.\n\ -If the argument is a string, the return value is the same object."; +Return a string representation of the object.\n\ +If the argument is a string, the return value is the same object.\n\ +If encoding is given, the string representation is decoded prior\n\ +to returning it. errors, defining the error handling for the decoding\n\ +process, defaults to 'strict'."; static PyObject * From trentm at activestate.com Wed Jul 5 20:12:20 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 5 Jul 2000 11:12:20 -0700 Subject: [Python-Dev] where did the rest of my traceback go? Message-ID: <20000705111220.A10839@activestate.com> Pardon me if this is a stupid question: Python 2.0b1 (#0, Jul 4 2000, 16:47:31) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> compile('foo=', 'foo.py', 'exec') Traceback (most recent call last): File "", line 1, in ? File "", line 1 foo= ^ SyntaxError: unexpected EOF while parsing >>> import sys, traceback >>> tb = sys.last_traceback >>> traceback.print_tb(tb) File "", line 1, in ? >>> traceback.print_stack() File "", line 1, in ? >>> Where did the rest of the stack trace go (i.e. the File "" block)? Insights appreciated, Trent -- Trent Mick trentm at activestate.com From effbot at telia.com Wed Jul 5 20:37:00 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 20:37:00 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> Message-ID: <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> mal wrote: > The idea is not new: strings and Unicode should have more > or less the same methods to enhance their compatibility. > > The attached patch adds encoding capabilities to normal > strings and extends the builtin str() to accept an optional > encoding (and error) argument. It also tries to reuse the > already available Unicode codecs for the purposes of strings > (conversions are done via the default encoding in both > directions). ... > What do you think about this ? Should I add it to CVS > as experiment ? +1 on the "encode" part -0 on the "str" part (intuitively, it's -1, but I don't have any good arguments against it right now... maybe later) From mal at lemburg.com Wed Jul 5 20:51:48 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 20:51:48 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> Message-ID: <396383C4.40390E0F@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > The idea is not new: strings and Unicode should have more > > or less the same methods to enhance their compatibility. > > > > The attached patch adds encoding capabilities to normal > > strings and extends the builtin str() to accept an optional > > encoding (and error) argument. It also tries to reuse the > > already available Unicode codecs for the purposes of strings > > (conversions are done via the default encoding in both > > directions). > > ... > > > What do you think about this ? Should I add it to CVS > > as experiment ? > > +1 on the "encode" part > > -0 on the "str" part (intuitively, it's -1, but I don't have > any good arguments against it right now... maybe later) The str() extension complements unicode() which also works as constructor for object given an encoding. Ideally, unicode() should also look for __unicode__() on instances just like str() looks for __str__(). Note that we could also have a .decode() method instead of modifying str(), but this would break symmetry to Unicode, since you can't decode Unicode into anything... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Wed Jul 5 21:17:20 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 21:17:20 +0200 Subject: [Python-Dev] help wanted: windows locales Message-ID: <00fa01bfe6b5$a8400460$f2a6b5d4@hagrid> Here's a tentative version of a mapping between windows identifiers and locale codes. There's probably bugs in here; I've tried to match data from a number of sources with Microsoft's descriptions (as given in the comments). Extra bonus for filling in "??". Most notably, those norwegians caused some problems here (don't they always? ;-). I'm pretty sure one of these should be "no_NO": 0x0414: "nb_NO", # Norwegian (Bokmal) 0x0814: "nn_NO", # Norwegian (Nynorsk) But which one? Same goes for the spaniards: which one should be "es_ES"? 0x040a: "es_??", # Spanish (Traditional Sort) 0x0c0a: "es_??", # Spanish (Modern Sort) thanks /F # # Map Windows language code to ISO 3166/ISO 639 code. This is only # used on older Windows platforms (Windows 95, most notable). # # NOTE: this table isn't complete. If you have time and knowledge, # please fill in the missing mappings (marked with ??) and send to # the Python core team (or directly to effbot at telia.com). # # Thanks /F windows_lang = { 0x0436: "af_AF", # Afrikaans 0x041c: "sq_AL", # Albanian 0x0401: "ar_SA", # Arabic (Saudi Arabia) 0x0801: "ar_IQ", # Arabic (Iraq) 0x0c01: "ar_EG", # Arabic (Egypt) 0x1001: "ar_LY", # Arabic (Libya) 0x1401: "ar_DZ", # Arabic (Algeria) 0x1801: "ar_MA", # Arabic (Morocco) 0x1c01: "ar_TN", # Arabic (Tunisia) 0x2001: "ar_OM", # Arabic (Oman) 0x2401: "ar_YE", # Arabic (Yemen) 0x2801: "ar_SY", # Arabic (Syria) 0x2c01: "ar_JO", # Arabic (Jordan) 0x3001: "ar_LB", # Arabic (Lebanon) 0x3401: "ar_KW", # Arabic (Kuwait) 0x3801: "ar_AE", # Arabic (U.A.E.) 0x3c01: "ar_BH", # Arabic (Bahrain) 0x4001: "ar_QA", # Arabic (Qatar) 0x042b: "hy_AM", # Armenian 0x044d: "as_??", # Assamese 0x042c: "az_AZ", # Azeri (Latin) 0x082c: "az_??", # Azeri (Cyrillic) 0x042d: "eu_ES", # Basque 0x0423: "be_BY", # Belarussian 0x0445: "bn_??", # Bengali 0x0402: "bg_BG", # Bulgarian 0x0455: "my_MM", # Burmese 0x0403: "ca_ES", # Catalan 0x0404: "zh_TW", # Chinese (Taiwan) 0x0804: "zh_CN", # Chinese (PRC) 0x0c04: "zh_HK", # Chinese (Hong Kong SAR, PRC) 0x1004: "zh_SG", # Chinese (Singapore) 0x1404: "zh_MO", # Chinese (Macau SAR) 0x041a: "hr_HR", # Croatian (Hrvatska) 0x0405: "cs_CZ", # Czech 0x0406: "da_DK", # Danish 0x0413: "nl_NL", # Dutch (Netherlands) 0x0813: "nl_BE", # Dutch (Belgium) 0x0409: "en_US", # English (United States) 0x0809: "en_UK", # English (United Kingdom) 0x0c09: "en_AU", # English (Australian) 0x1009: "en_CA", # English (Canadian) 0x1409: "en_NZ", # English (New Zealand) 0x1809: "en_IE", # English (Ireland) 0x1c09: "en_ZA", # English (South Africa) 0x2009: "en_JM", # English (Jamaica) 0x2409: "en_??", # English (Caribbean) 0x2809: "en"_BZ, # English (Belize) 0x2c09: "en_TT", # English (Trinidad) 0x3009: "en_ZW", # English (Zimbabwe) 0x3409: "en_PH", # English (Philippines) 0x0425: "et_EE", # Estonian 0x0438: "fo_FO", # Faeroese 0x0429: "fa_IR", # Farsi 0x040b: "fi_FI", # Finnish 0x040c: "fr_FR", # French (Standard) 0x080c: "fr_BE", # French (Belgian) 0x0c0c: "fr_CA", # French (Canadian) 0x100c: "fr_CH", # French (Switzerland) 0x140c: "fr_LU", # French (Luxembourg) 0x180c: "fr_MC", # French (Monaco) 0x0437: "ka_GE", # Georgian 0x0407: "de_DE", # German (Standard) 0x0807: "de_CH", # German (Switzerland) 0x0c07: "de_AT", # German (Austria) 0x1007: "de_LU", # German (Luxembourg) 0x1407: "de_LI", # German (Liechtenstein) 0x0408: "el_GR", # Greek 0x0447: "gu_??", # Gujarati 0x040d: "iw_IL", # Hebrew 0x0439: "hi_IN", # Hindi 0x040e: "hu_HU", # Hungarian 0x040f: "is_IS", # Icelandic 0x0421: "id_ID", # Indonesian 0x0410: "it_IT", # Italian (Standard) 0x0810: "it_CH", # Italian (Switzerland) 0x0411: "ja_JA", # Japanese 0x044b: "kn_??", # Kannada 0x0860: "ks_IN", # Kashmiri (India) 0x043f: "kk_??", # Kazakh 0x0457: "??_??", # Konkani 0x0412: "ko_??", # Korean 0x0812: "ko_??", # Korean (Johab) 0x0426: "lv_LV", # Latvian 0x0427: "lt_LT", # Lithuanian 0x0827: "lt_??", # Lithuanian (Classic) 0x042f: "mk_MK", # Macedonian 0x043e: "ms_MY", # Malay (Malaysian) 0x083e: "ms_??", # Malay (Brunei Darussalam) 0x044c: "ml_??", # Malayalam 0x0458: "??_??", # Manipuri 0x044e: "mr_??", # Marathi 0x0861: "ne_IN", # Nepali (India) 0x0414: "nb_NO", # Norwegian (Bokmal) 0x0814: "nn_NO", # Norwegian (Nynorsk) 0x0448: "or_??", # Oriya 0x0415: "pl_PL", # Polish 0x0416: "pt_BR", # Portuguese (Brazil) 0x0816: "pt_PT", # Portuguese (Standard) 0x0446: "pa_??", # Punjabi 0x0418: "ro_RO", # Romanian 0x0419: "ru_RU", # Russian 0x044f: "sa_??", # Sanskrit 0x0c1a: "sr_??", # Serbian (Cyrillic) 0x081a: "sr_??", # Serbian (Latin) 0x0459: "sd_??", # Sindhi 0x041b: "sk_??", # Slovak 0x0424: "sl_SL", # Slovenian 0x040a: "es_??", # Spanish (Traditional Sort) 0x080a: "es_MX", # Spanish (Mexican) 0x0c0a: "es_??", # Spanish (Modern Sort) 0x100a: "es_GT", # Spanish (Guatemala) 0x140a: "es_??", # Spanish (Costa Rica) 0x180a: "es_PA", # Spanish (Panama) 0x1c0a: "es_DO", # Spanish (Dominican Republic) 0x200a: "es_VE", # Spanish (Venezuela) 0x240a: "es_CO", # Spanish (Colombia) 0x280a: "es_PE", # Spanish (Peru) 0x2c0a: "es_AR", # Spanish (Argentina) 0x300a: "es_EC", # Spanish (Ecuador) 0x340a: "es_CL", # Spanish (Chile) 0x380a: "es_UY", # Spanish (Uruguay) 0x3c0a: "es_PY", # Spanish (Paraguay) 0x400a: "es_BO", # Spanish (Bolivia) 0x440a: "es_SV", # Spanish (El Salvador) 0x480a: "es_HN", # Spanish (Honduras) 0x4c0a: "es_NI", # Spanish (Nicaragua) 0x500a: "es_PR", # Spanish (Puerto Rico) 0x0430: "??_??", # Sutu 0x0441: "sw_KE", # Swahili (Kenya) 0x041d: "sv_SE", # Swedish 0x081d: "sv_FI", # Swedish (Finland) 0x0449: "ta_??", # Tamil 0x0444: "tt_??", # Tatar (Tatarstan) 0x044a: "te_??", # Telugu 0x041e: "th_TH", # Thai 0x041f: "tr_TR", # Turkish 0x0422: "tk_UA", # Ukrainian 0x0420: "ur_PK", # Urdu (Pakistan) 0x0820: "ur_IN", # Urdu (India) 0x0443: "uz_UZ", # Uzbek (Latin) 0x0843: "uz_??", # Uzbek (Cyrillic) 0x042a: "vi_VN", # Vietnamese } From pingster at ilm.com Wed Jul 5 21:20:41 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 5 Jul 2000 12:20:41 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <200007051229.OAA19526@python.inrialpes.fr> Message-ID: On Wed, 5 Jul 2000, Vladimir Marangozov wrote: > Looks fine. +1 on the concept. Yay! > > SyntaxError: expected indent here > > I'd remove the word "here" so that the error msg is self-contained. > "expected indent" & "expected dedent" are fine. Fine with me (more on messages below). > > 4. Added int *expected_ret argument to PyParser_AddToken; on > > a syntax error, PyParser_AddToken (in parser.c) places the > > expected token type (if any) into this output parameter. > > I'd suggest passing a pointer to the perrdetail structure (to the > whole error, that is), instead of a pointer to one of its fields. I did consider that; the reason i eventually decided against it is that munging perrdetail appears to be [parsetok.c] parsetok()'s responsibility, not [parser.c] PyParser_AddToken()'s. The latter doesn't mess with any of the other fields of perrdetail -- and it returns an error code which becomes err_ret->error, so passing in perrdetail gives PyParser_AddToken() two ways of returning the same information. The redundancy and possible future confusion didn't seem worth it. Another alternative is to change the return value so it *isn't* an error code (only a success/fail flag) and then rely on the error code in err_ret->error. I guess if you see a compelling reason for this i don't mind doing it. But is there one? Greg Wilson wrote: > I just did a poll --- only 2 out of 5 programmers in my shouting radius > know what "dedent" means. Is there a more accessible way to phrase the > error message? Indeed. Sorry about that -- i should have realized that it's a fairly cryptic term. "Dedent" seems to have become a standard term within the C code; perhaps we can allow "dedent" in the C code and standardize on "unindent" outside? How about this set of messages, then: SyntaxError: unexpected indent SyntaxError: unexpected unindent SyntaxError: expected indent SyntaxError: expected unindent SyntaxError: unindent did not match any outer indentation level SyntaxError: inconsistent use of tabs and spaces in indentation SyntaxError: too many levels of indentation Hmm. For the record, the section of the reference manual about indentation talks about INDENT and DEDENT tokens. In fact i don't think there's any mention of the word "unindent" in the Python documentation. But outside of the Python docs, "unindent" is clearly a commonly used and understood term in general practice, much more so than "dedent". -- ?!ng From effbot at telia.com Wed Jul 5 21:52:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 21:52:23 +0200 Subject: [Python-Dev] Making -tt the default References: <14689.26996.975805.829295@cj42289-a.reston1.va.home.com> Message-ID: <01ac01bfe6ba$8c1ed680$f2a6b5d4@hagrid> fred wrote: > There are two things that can be done: have distutils always use > -tt when compiling code that gets installed (using a child interpreter > if needed), that's reasonable. > and setting -tt as the default in the next Python release. where "next" is Py3K, I hope. breaking an unknown amount of existing libraries and code samples, just for the sake of it, isn't exactly a great way to promote Python... From effbot at telia.com Wed Jul 5 21:56:09 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 5 Jul 2000 21:56:09 +0200 Subject: [Python-Dev] Spelling check: more typos References: <20000705060943.A18539@thyrsus.com> <20000705062434.A18614@thyrsus.com> Message-ID: <01f001bfe6bb$5198bb60$f2a6b5d4@hagrid> eric wrote: > > > Tim's source is correct. > > > > Tim? Do you mean /F? > > I believe /F was quoting Tim. nope. not that it matters much; that economist style guide seem to override it anyway ;-) From martin at loewis.home.cs.tu-berlin.de Wed Jul 5 22:25:17 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed, 5 Jul 2000 22:25:17 +0200 Subject: [Python-Dev] help wanted: windows locales Message-ID: <200007052025.WAA01309@loewis.home.cs.tu-berlin.de> > I'm pretty sure one of these should be "no_NO": > 0x0414: "nb_NO", # Norwegian (Bokmal) > 0x0814: "nn_NO", # Norwegian (Nynorsk) > But which one? Looking at http://lcweb.loc.gov/standards/iso639-2/englangn.html, it seems the answer is "neither". I believe "no_NO" is used for traditional Norwegian on many systems (that would be Bokm?l, right?). On a number of Unix systems (Linux, Solaris), Nynorsk is requested by appending "@nynorsk" to $LANG, e.g. no at nynorsk (Linux), no_NO.ISO8859-1 at nynorsk (Solaris). The latter also recognizes no_NY for Nynorsk, but that doesn't sound too official. It seems that ISO 639-2:1998 isn't that widely implemented; is anybody actually using nn/nb? Regards, Martin From gstein at lyra.org Wed Jul 5 22:42:30 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 5 Jul 2000 13:42:30 -0700 Subject: [Python-Dev] Making -tt the default In-Reply-To: <14691.8786.180085.468266@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 05, 2000 at 07:56:02AM -0400 References: <20000703233938.N29590@lyra.org> <14691.8786.180085.468266@anthem.concentric.net> Message-ID: <20000705134230.C12873@lyra.org> On Wed, Jul 05, 2000 at 07:56:02AM -0400, Barry A. Warsaw wrote: > >>>>> "GS" == Greg Stein writes: > GS> (add-hook 'python-mode-hook > | (lambda () > | (setq indent-tabs-mode nil) > | (setq py-indent-offset 2) > | (setq py-smart-indentation nil) > | (define-key py-mode-map "\e\C-h" 'backward-kill-word) > | )) > > GS> The indent-tabs-mode is the key to disabling tab characters > GS> and using just spaces. > > Greg, can you explain why you turn off py-smart-indentation? Its > purpose is to give you the correct settings when editing someone > else's existing code. With this variable set to t, it tries to guess > the existing code's indentation level depth and then sets > py-indent-offset to that value, on the assumption that > > 1) the original author indented their code consistently > > 2) it is better to be consistent with the existing indentation than > impose your own and have mixed indentation > > Both of these are worthy goals, IMO, so py-smart-indentation should > generally remain true. The goal is fine, and I agree with it. However, it was guessing the wrong tab for me at some point, and so I just turned it off. That's the way I have it; other people probably don't want to do that. *shrug* Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw at beopen.com Wed Jul 5 22:48:41 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 16:48:41 -0400 (EDT) Subject: [Python-Dev] Making -tt the default References: <20000703233938.N29590@lyra.org> <14691.8786.180085.468266@anthem.concentric.net> <20000705134230.C12873@lyra.org> Message-ID: <14691.40745.724265.337058@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> The goal is fine, and I agree with it. However, it was GS> guessing the wrong tab for me at some point, and so I just GS> turned it off. GS> That's the way I have it; other people probably don't want to GS> do that. No problem, 'cause you're already setting indent-tabs-mode in your hook. -Barry From jack at oratrix.nl Wed Jul 5 22:53:26 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 05 Jul 2000 22:53:26 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c Message-ID: <20000705205331.E8BCDE2673@oratrix.oratrix.nl> Is anyone else experiencing problems with the immense new switch in unicodectype.c? Trying to compile it crashes my machine(!)... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From mal at lemburg.com Wed Jul 5 23:09:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 05 Jul 2000 23:09:53 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <20000705205331.E8BCDE2673@oratrix.oratrix.nl> Message-ID: <3963A421.35A7F989@lemburg.com> Jack Jansen wrote: > > Is anyone else experiencing problems with the immense new switch in > unicodectype.c? Trying to compile it crashes my machine(!)... It compiles fine on my Linux machine using gcc. The output is a 114k .o file (including debug information). Do you have similar problems with ceval.c ? If yes, I could break the switch in two using the same flag as in ceval.c. If not, please give some compiler details, so that I can switch on those. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Wed Jul 5 23:42:37 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 17:42:37 -0400 Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <20000705205331.E8BCDE2673@oratrix.oratrix.nl> Message-ID: [posted & mailed] [Jack Jansen] > Is anyone else experiencing problems with the immense new switch in > unicodectype.c? Trying to compile it crashes my machine(!)... No problem here, but it needs to be fixed for you! There's no future in pushing anyone's compiler limits, and particularly not when Python is attracting more attention on smaller platforms (read feebler compilers, among others gotchas). I believe we also need a way to split unicodedatabase.c into multiple files, as > 64K lines in a source file is unreasonable (Python can't handle a source file that large either, and Python is the *definition* of reasonableness here ), and the MS compiler spits out a warning about its sheer size. Or was Christian's long-threatened compression patch supposed to reduce the line count in that one? From effbot at telia.com Thu Jul 6 00:13:46 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 00:13:46 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: Message-ID: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> tim wrote: > [Jack Jansen] > > Is anyone else experiencing problems with the immense new switch in > > unicodectype.c? Trying to compile it crashes my machine(!)... > > No problem here, but it needs to be fixed for you! There's no future in > pushing anyone's compiler limits, and particularly not when Python is > attracting more attention on smaller platforms (read feebler compilers, > among others gotchas). both modules can be squeezed down to almost nothing. it just takes a little work. fwiw, Tcl's version of the unicodectype file is about 30k, and compiles to an 8k large object file on my win95 box. if nobody else fixes this, I'll do something about it before 2.0 final. promise. cheers /F From mal at lemburg.com Thu Jul 6 00:19:38 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 00:19:38 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: Message-ID: <3963B47A.638A7A82@lemburg.com> Tim Peters wrote: > > [posted & mailed] > > [Jack Jansen] > > Is anyone else experiencing problems with the immense new switch in > > unicodectype.c? Trying to compile it crashes my machine(!)... > > No problem here, but it needs to be fixed for you! There's no future in > pushing anyone's compiler limits, and particularly not when Python is > attracting more attention on smaller platforms (read feebler compilers, > among others gotchas). > > I believe we also need a way to split unicodedatabase.c into multiple files, > as > 64K lines in a source file is unreasonable (Python can't handle a > source file that large either, and Python is the *definition* of > reasonableness here ), and the MS compiler spits out a warning about > its sheer size. > > Or was Christian's long-threatened compression patch supposed to reduce the > line count in that one? Both the line count and the memory consumption... the same can be done for unicodectype.c -- but I don't have the time to look into this, so for now all I can offer is to split the huge switch in two if that helps. BTW, if your compiler supports Unicode (that is provides a working wctype.h file), you can compile Python using the compile time switch --with-wctype-functions. Python will then use the C libs iswXXX() APIs which should return more or less the same values as the Python ones (could be that the C lib is Unicode 2.0 -- so YMMV). Note that this hasn't been tested much yet. Feedback is welcome. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gward at mems-exchange.org Thu Jul 6 00:30:46 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 18:30:46 -0400 Subject: [Python-Dev] ExtensionClass and __radd__()? Message-ID: <20000705183046.A26381@ludwig.cnri.reston.va.us> Hi all -- looks like ExtensionClass doesn't recognize/implement the '__radd__()' protocol. Speculation below; first, a demonstration. Normal case: a regular class Number that knows how to add itself to other number-like things: class Number: def __init__ (self, n): self.n = n def __str__ (self): return str(self.n) def __add__ (self, other): return self.n + other __radd__ = __add__ n = Number(37) print n, n + 5, 5 + n The output of this is exactly what you'd expect: 37 42 42 (I have convinced myself that '__radd__()' is called in the "5 + n" case by writing a separate '__radd__()' with a print statement. Everything is sane!) Now the same thing as an ExtensionClass: from ExtensionClass import Base class ECNumber (Base): def __init__ (self, n): self.n = n def __str__ (self): return str(self.n) def __add__ (self, other): return self.n + other __radd__ = __add__ ecn = ECNumber(37) print ecn, ecn + 5, 5 + ecn The output of this is puzzling, to say the least: 37 42 134883149 IOW, "5 + ecn" evaluates to 134883149 -- that's a plain int, I checked with 'type()' on it. If I put this code: print id(ecn), id(5), id(ECNumber), id(Base), id(ExtensionClass) immediately after the last print, I get 135530536 135220848 135568720 1075195712 1075195488 ... which just tells me that the result of "5 + ecn" looks a lot like an id(), but isn't the id() of anything obvious. (Or 5 + any obvious id().) Happens the same with the ExtensionClass code from Zope 2.1.5 or 2.2beta1, and with Python 1.5.2 and the latest CVS Python. Speculation time: I'm guessing that this is similar to the problem with 'isinstance()' and ExtensionClass that I found several months ago, which was heroically debugged by Barry. To recap, it's a mutual finger-pointing bug: Python (Guido) can claim that it's up to ExtensionClass (Jim) to emulate the full semantics of Python classes/instances, but ExtensionClass can claim that Python should be more relaxed in what it accepts as a "class object" or "instance object". I think the relevant code in Python is in Objects/abstract.c, specifically 'PyNumber_Add()' and the BINOP macro: #define BINOP(v, w, opname, ropname, thisfunc) \ if (PyInstance_Check(v) || PyInstance_Check(w)) \ return PyInstance_DoBinOp(v, w, opname, ropname, thisfunc) [...] PyNumber_Add(v, w) PyObject *v, *w; { PySequenceMethods *m; BINOP(v, w, "__add__", "__radd__", PyNumber_Add); [...] My guess is that PyInstance_Check() returns false for ExtensionClass instances. Two possible fixes: loosen up PyInstance_Check(), or loosen up BINOP. Well, it's a nice theory. It doesn't explain why '__add__()' works for ExtensionClass while '__radd__()' does not; perhaps ExtensionClass implements that much of Python's class semantics, but doesn't go as far as '__radd__()'. Other opinions? Greg From gward at mems-exchange.org Thu Jul 6 00:33:53 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 18:33:53 -0400 Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: ; from pingster@ilm.com on Wed, Jul 05, 2000 at 12:20:41PM -0700 References: <200007051229.OAA19526@python.inrialpes.fr> Message-ID: <20000705183353.B7564@ludwig.cnri.reston.va.us> On 05 July 2000, Ka-Ping Yee said: > How about this set of messages, then: > > SyntaxError: unexpected indent > SyntaxError: unexpected unindent How about "did not expect indent" and "did not expect unindent" -- reads a little easier to my eyes. > SyntaxError: expected indent > SyntaxError: expected unindent > SyntaxError: unindent did not match any outer indentation level > SyntaxError: inconsistent use of tabs and spaces in indentation > SyntaxError: too many levels of indentation Good. > Hmm. For the record, the section of the reference manual about > indentation talks about INDENT and DEDENT tokens. In fact i don't > think there's any mention of the word "unindent" in the Python > documentation. But outside of the Python docs, "unindent" is > clearly a commonly used and understood term in general practice, > much more so than "dedent". I don't think too many newbies read the reference manual (or the parser source, for that matter). Stick to clear, simple, plain-English terms in error messages, even if they are different from (not inconsistent with!) what's in the formal docs. Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From gward at mems-exchange.org Thu Jul 6 00:45:48 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 18:45:48 -0400 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! In-Reply-To: <018a01bfe59f$da814950$0900a8c0@SPIFF>; from fredrik@pythonware.com on Tue, Jul 04, 2000 at 12:08:50PM +0200 References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> Message-ID: <20000705184548.C7564@ludwig.cnri.reston.va.us> On 04 July 2000, Fredrik Lundh said: > > to Python.h. This enables all features available for the > > gcc compiler including _XOPEN_SOURCE and fixes warnings > > related to missing prototypes. > > > > Thoughts ? Would this hurt anybody ? > > what does "fixes warnings" mean? does it change the compiler's > behaviour, or does it just make sure stuff are defined in the right > files? Just like MAL said, it fixes warnings from missing prototypes. Eg. the (I think) on Linux (glibc 2.x, at least) doesn't declare 'strptime()' unless __USE_XOPEN is true. (__USE_XOPEN is defined if _XOPEN_SOURCE is defined, by .) > +1 on _XOPEN_SOURCE > +0 on _GNU_SOURCE Agreed, unless someone can explain a) what _GNU_SOURCE adds that _XOPEN_SOURCE does not, and b) why that's necessary (if so). Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From mal at lemburg.com Thu Jul 6 00:53:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 00:53:08 +0200 Subject: [Python-Dev] Make _GNU_SOURCE default for gcc ?! References: <3961B221.4F7552C3@lemburg.com> <018a01bfe59f$da814950$0900a8c0@SPIFF> <20000705184548.C7564@ludwig.cnri.reston.va.us> Message-ID: <3963BC54.5B49AD72@lemburg.com> Greg Ward wrote: > > On 04 July 2000, Fredrik Lundh said: > > > to Python.h. This enables all features available for the > > > gcc compiler including _XOPEN_SOURCE and fixes warnings > > > related to missing prototypes. > > > > > > Thoughts ? Would this hurt anybody ? > > > > what does "fixes warnings" mean? does it change the compiler's > > behaviour, or does it just make sure stuff are defined in the right > > files? > > Just like MAL said, it fixes warnings from missing prototypes. Eg. the > (I think) on Linux (glibc 2.x, at least) doesn't declare > 'strptime()' unless __USE_XOPEN is true. (__USE_XOPEN is defined if > _XOPEN_SOURCE is defined, by .) > > > +1 on _XOPEN_SOURCE > > +0 on _GNU_SOURCE > > Agreed, unless someone can explain a) what _GNU_SOURCE adds that > _XOPEN_SOURCE does not, and b) why that's necessary (if so). It's already checked in, but since you asked: _GNU_SOURCE defines one symbol which is essential on Linux to get at a bunch of BSD/SysV API prototypes which _XOPEN_SOURCE doesn't activate. Time support is one area where this is needed, I found tmpnam_r() to be another one. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Thu Jul 6 01:00:33 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 18:00:33 -0500 (CDT) Subject: [Python-Dev] dismantle CVS repository on cvs.python.org? Message-ID: <14691.48657.899199.497977@beluga.mojam.com> Is it time to disable anonymous CVS access from cvs.python.org? On one of my machines I was still referring to it, but only noticed today because the build still said "1.6...". Best would be if there was some way to get it to spit out an error message that referred people to either the python.org web site or the SourceForge repository web site. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From guido at beopen.com Thu Jul 6 02:15:13 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 19:15:13 -0500 Subject: [Python-Dev] dismantle CVS repository on cvs.python.org? In-Reply-To: Your message of "Wed, 05 Jul 2000 18:00:33 EST." <14691.48657.899199.497977@beluga.mojam.com> References: <14691.48657.899199.497977@beluga.mojam.com> Message-ID: <200007060015.TAA06841@cj20424-a.reston1.va.home.com> > Is it time to disable anonymous CVS access from cvs.python.org? On one of > my machines I was still referring to it, but only noticed today because the > build still said "1.6...". Best would be if there was some way to get it to > spit out an error message that referred people to either the python.org web > site or the SourceForge repository web site. Yes -- it was left on by mistake. However CNRI currently doesn't let us modify the python.org site. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Thu Jul 6 01:15:39 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 18:15:39 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... Message-ID: <14691.49563.78765.683762@beluga.mojam.com> Was there a public announcement made about new functionality for 2.0? I had submitted list comprehensions to the old 1.6 cycle, and it was being held to the now never-to-be 1.7. Are we in feature freeze for 2.0 at this point? I can do one of three things: * commit the changes I have currently against the CVS repository * bundle up another patch for people to examine and comment on * shut up and go do something more useful Skip From skip at mojam.com Thu Jul 6 01:18:51 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 18:18:51 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? Message-ID: <14691.49755.365679.923078@beluga.mojam.com> Along the same lines, I have some pretty simple mods to readline.c and rlcompleter.py that use atexit to automatically save the current history to the file identified by the PYTHONHISTORY environment variable. (If unset, no history read/write is done). If we aren't in feature freeze, I'd like to check it in. Skip From effbot at telia.com Thu Jul 6 01:27:13 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 01:27:13 +0200 Subject: [Python-Dev] list comprehensions again... References: <14691.49563.78765.683762@beluga.mojam.com> Message-ID: <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> skip wrote: > Are we in feature freeze for 2.0 at this point? hopefully. > I can do one of three things: > > * commit the changes I have currently against the CVS repository > > * bundle up another patch for people to examine and comment on I'd vote for the second alternative. > * shut up and go do something more useful nope. that's what I'm going to do. cheers /F From jeremy at beopen.com Thu Jul 6 01:41:05 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 5 Jul 2000 19:41:05 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14691.49563.78765.683762@beluga.mojam.com> References: <14691.49563.78765.683762@beluga.mojam.com> Message-ID: <14691.51089.280721.161530@bitdiddle.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> Was there a public announcement made about new functionality for SM> 2.0? I had submitted list comprehensions to the old 1.6 cycle, SM> and it was being held to the now never-to-be 1.7. Are we in SM> feature freeze for 2.0 at this point? SM> I can do one of three things: SM> * commit the changes I have currently against the CVS SM> repository SM> * bundle up another patch for people to examine and comment SM> on SM> * shut up and go do something more useful At lunch today, Guido raised almost the same question! Tim and I argued that we should continue the feature freeze, and spend any extra time wasted while we wait for CNRI to quit stalling to resolve open bugs and do more testing. It's been a long time since the last bug fix release, and there are already a lot of new features. We'd probably be best served by working hard to make 2.0 stable and solid -- and then getting 2.1 released quickly. Jeremy From guido at beopen.com Thu Jul 6 02:42:24 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 19:42:24 -0500 Subject: [Python-Dev] list comprehensions again... In-Reply-To: Your message of "Wed, 05 Jul 2000 18:15:39 EST." <14691.49563.78765.683762@beluga.mojam.com> References: <14691.49563.78765.683762@beluga.mojam.com> Message-ID: <200007060042.TAA06919@cj20424-a.reston1.va.home.com> > Was there a public announcement made about new functionality for > 2.0? Yes, there's something on http://pythonlabs.com/tech/python2.html. We currently can't commit to a release schedule due to the problems with CNRI. > I had > submitted list comprehensions to the old 1.6 cycle, and it was being held to > the now never-to-be 1.7. Are we in feature freeze for 2.0 at this point? That's up for debate. Reversing our usual good-cop-bad-cop roles, Tim Peters is for a feature freeze while I am for adding more features to 2.0 to make it stand apart. :-) > I can do one of three things: > > * commit the changes I have currently against the CVS repository > > * bundle up another patch for people to examine and comment on > > * shut up and go do something more useful It's not wise to commit changes without agreement on whether they should be applied... Anyway, the patches are currently in Tim Peters' court. Are your changes different from what's already in the patch manager for list comprehensions? If so, you should probably upload a revised patch... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Thu Jul 6 02:44:15 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 19:44:15 -0500 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: Your message of "Wed, 05 Jul 2000 18:18:51 EST." <14691.49755.365679.923078@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> Message-ID: <200007060044.TAA08483@cj20424-a.reston1.va.home.com> > Along the same lines, I have some pretty simple mods to readline.c and > rlcompleter.py that use atexit to automatically save the current history to > the file identified by the PYTHONHISTORY environment variable. (If unset, > no history read/write is done). If we aren't in feature freeze, I'd like to > check it in. To ease review of the patch, why don't you upload it? Does the patch also load the history at start time? That would be useful... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gward at mems-exchange.org Thu Jul 6 02:00:44 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 5 Jul 2000 20:00:44 -0400 Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <14690.56733.627266.907044@temoleh.chem.uu.nl>; from rob@hooft.net on Wed, Jul 05, 2000 at 09:02:53AM +0200 References: <14690.56733.627266.907044@temoleh.chem.uu.nl> Message-ID: <20000705200043.D7564@ludwig.cnri.reston.va.us> On 05 July 2000, Rob W. W. Hooft said: > Then 2 points on distutils: > - the word "licence" is used throughout, and "license" is introduced as > alternative. The other way around looks more natural to me. In American English, "license" is both noun and verb. In the rest of the world, "licence" is the noun and "license" the verb. Hence, I might license you to use my software with the GNU General Public Licence. (Except that the FSF is American, so they don't use "licence". Oops.) Alternately: when I moved to the US, I traded in my Canadian driver's licence for an American license. (Except that I lived in Quebec, and had a permis de conduire. Oops again!) I am not American, so I do not use American English in source code or documentation, and strive to avoid it in everyday speech. ;-) If an overwhelming majority insists on American spellings in source code, command-line options, documentation, and the like, then I *might* give in, but only reluctantly. There is more than one way to use the English language, and just because the most populous (and richest, and most heavily-armed, etc.) English-speaking nation does it one way doesn't mean we should all do it that way. Bottom line: when used as a noun, "licence" and "license" should be accepted equally. This is currently the case on the Distutils command-line, but I'm not sure if it holds in the setup script. Will check. > - the term "anal retentives" should probably be replaced before 2.0 Oh c'mon, if it's just in *comments* is anyone really going to be offended? Where is it, anyways? Anyways, why is the guy who combs the source code looking for spelling errors complaining about the use of "anal retentive"? Perhaps it cuts a little close to home? >evil grin< (Sorry, that was uncalled for -- but irresistable. Nothing personal, of course!) Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From fdrake at beopen.com Thu Jul 6 02:21:14 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 20:21:14 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14691.49755.365679.923078@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> Message-ID: <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > Along the same lines, I have some pretty simple mods to readline.c and > rlcompleter.py that use atexit to automatically save the current history to > the file identified by the PYTHONHISTORY environment variable. (If unset, Skip, "bash" doesn't make me set a variable to control saving of history to ~/.bash_history; I'd be perfectly happy if Python wrote ~/.python_history by default, and simply allowed me to turn it off somehow (either from my $PYTHONSTARTUP script or a separate environment variable). There should be a reasonable default size to the history (say, 2000 lines ;), and a way to set that as well. Perhaps this is reasonable: in rlcompleter (or whereever this stuff goes), have a variable history_size that is set based on $PYTHONHISTORYSIZE if set, or 2000 if not. If the variable is set to 0, there is no history saving (or loading), and non-numeric values (like "true" ;) mean "use the default" (which is at least 2000 ;). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jul 6 02:27:20 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 20:27:20 -0400 (EDT) Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <20000705200043.D7564@ludwig.cnri.reston.va.us> References: <14690.56733.627266.907044@temoleh.chem.uu.nl> <20000705200043.D7564@ludwig.cnri.reston.va.us> Message-ID: <14691.53864.55446.173589@cj42289-a.reston1.va.home.com> Greg Ward writes: > Bottom line: when used as a noun, "licence" and "license" should be > accepted equally. This is currently the case on the Distutils > command-line, but I'm not sure if it holds in the setup script. Will If it's a keyword parameter, use it with exactly one spelling and document it that way. If packagers can't read the distutils documentation, too bad. I'll hold my comments on which is the right way to spell "license". ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Thu Jul 6 03:48:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 20:48:29 -0500 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: Your message of "Wed, 05 Jul 2000 20:21:14 -0400." <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> Message-ID: <200007060148.UAA10852@cj20424-a.reston1.va.home.com> > Skip Montanaro writes: > > Along the same lines, I have some pretty simple mods to readline.c and > > rlcompleter.py that use atexit to automatically save the current history to > > the file identified by the PYTHONHISTORY environment variable. (If unset, [Fred] > Skip, > "bash" doesn't make me set a variable to control saving of history > to ~/.bash_history; I'd be perfectly happy if Python wrote > ~/.python_history by default, and simply allowed me to turn it off > somehow (either from my $PYTHONSTARTUP script or a separate > environment variable). There should be a reasonable default size to > the history (say, 2000 lines ;), and a way to set that as well. > Perhaps this is reasonable: in rlcompleter (or whereever this stuff > goes), have a variable history_size that is set based on > $PYTHONHISTORYSIZE if set, or 2000 if not. If the variable is set to > 0, there is no history saving (or loading), and non-numeric values > (like "true" ;) mean "use the default" (which is at least 2000 ;). On the other hand, bash reads .profile and .bashrc and a few other files by default, while Python reads such a file only when $PYTHONSTARTUP is set. I actually like this. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Thu Jul 6 03:04:41 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 21:04:41 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060148.UAA10852@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> <200007060148.UAA10852@cj20424-a.reston1.va.home.com> Message-ID: <14691.56105.43228.613238@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > On the other hand, bash reads .profile and .bashrc and a few other > files by default, while Python reads such a file only when > $PYTHONSTARTUP is set. I actually like this. Fair enough, though I'd be happy to change that as well. :) So perhaps $PYTHONHISTORY should specify the file name, and the filename and size can also be set from the $PYTHONSTARTUP script if desired, and a function call can be made to load the history? I'd prefer to *only* need to add a line or two to my $PYTHONSTARTUP script, and not set yet more environment variables, if at all possible. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Thu Jul 6 01:57:29 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 18:57:29 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007060042.TAA06919@cj20424-a.reston1.va.home.com> References: <14691.49563.78765.683762@beluga.mojam.com> <200007060042.TAA06919@cj20424-a.reston1.va.home.com> Message-ID: <14691.52073.836046.104252@beluga.mojam.com> Guido> Are your changes different from what's already in the patch Guido> manager for list comprehensions? If so, you should probably Guido> upload a revised patch... Nope. I only remembered them today when I executed "cvs update" and saw all those "M"s... Skip From tim_one at email.msn.com Thu Jul 6 03:27:48 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 21:27:48 -0400 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack Message-ID: Twice in ceval.c, and once in object.c, there's code referencing PyOS_CheckStack under the control of the preprocessor symbol USE_STACKCHECK. There's nothing in the std distribution that could possibly define either of those names. Why are they there? If nobody objects, I'll get rid of this code! PS for Jeremy: the mechanism I was thinking of is _ts.recursion_depth, which is used cross-platform in ceval.c, like so: if (++tstate->recursion_depth > MAX_RECURSION_DEPTH) { --tstate->recursion_depth; PyErr_SetString(PyExc_RuntimeError, "Maximum recursion depth exceeded"); tstate->frame = f->f_back; Py_DECREF(f); return NULL; } The effectiveness of this is dependent on guessing a good value (per platform) for MAX_RECURSION_DEPTH (and it's broken under Windows in 1.5.2). From skip at mojam.com Thu Jul 6 01:58:55 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 18:58:55 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060044.TAA08483@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <200007060044.TAA08483@cj20424-a.reston1.va.home.com> Message-ID: <14691.52159.562929.565934@beluga.mojam.com> Guido> To ease review of the patch, why don't you upload it? Will do. Guido> Does the patch also load the history at start time? That would Guido> be useful... That's the whole idea... ;-) Skip From tim_one at email.msn.com Thu Jul 6 03:37:11 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 21:37:11 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007060042.TAA06919@cj20424-a.reston1.va.home.com> Message-ID: Oh, all right, I'll address this now: > It's not wise to commit changes without agreement on whether they > should be applied... Anyway, the patches are currently in Tim Peters' > court. I think that speaks for itself: immediately after ESR praised Guido's impeccable English, Guido goes and violates the Economist's style guide by not spelling that Tim Peters's court as I and all right-thinking singular grammarians would have done. I grew up in the Peters' house along with the rest of the Peters family, but if I ever get an apartment here it will be Peters's. glad-to-have-settled-*that*-one-ly y'rs - tim From guido at beopen.com Thu Jul 6 05:00:18 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 22:00:18 -0500 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack In-Reply-To: Your message of "Wed, 05 Jul 2000 21:27:48 -0400." References: Message-ID: <200007060300.WAA11066@cj20424-a.reston1.va.home.com> > Twice in ceval.c, and once in object.c, there's code referencing > PyOS_CheckStack under the control of the preprocessor symbol USE_STACKCHECK. > There's nothing in the std distribution that could possibly define either of > those names. Why are they there? If nobody objects, I'll get rid of this > code! They are there for the Mac code, which has its own config.h. The Mac distribution is maintained separately by Jack Jansen. There are occasional compromises in the main source code for the Mac port, and this is one. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Thu Jul 6 02:42:13 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 19:42:13 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060044.TAA08483@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <200007060044.TAA08483@cj20424-a.reston1.va.home.com> Message-ID: <14691.54757.459091.820551@beluga.mojam.com> >> Along the same lines, I have some pretty simple mods to readline.c and >> rlcompleter.py ... Guido> To ease review of the patch, why don't you upload it? Done. It's available for review at https://sourceforge.net/patch/?func=detailpatch&patch_id=100742&group_id=5470 Skip From tim_one at email.msn.com Thu Jul 6 04:14:39 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 22:14:39 -0400 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack In-Reply-To: <200007060300.WAA11066@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > They are there for the Mac code, which has its own config.h. The Mac > distribution is maintained separately by Jack Jansen. There are > occasional compromises in the main source code for the Mac port, and > this is one. Then I would like to a) Add comments to the #ifdef's saying they're for the Mac. "Mystery code" is bad in group-maintained software. I expect Jack will maintain that it isn't really Mac-specific, but a wonderful feature for any platform that cares to #define USE_STACKCHECK and PyOS_CheckStack. Then I preemptively sneer in his general direction . b) Wonder out loud why this code is useful on a Mac but not other platforms. We can get segfaulting recursion while print'ing and repr'ing on all platforms. So shouldn't we work to catch that on all platforms too? Macs shouldn't be something special wrt this. From skip at mojam.com Thu Jul 6 02:48:19 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 19:48:19 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14691.53498.883311.132983@cj42289-a.reston1.va.home.com> Message-ID: <14691.55123.961759.456729@beluga.mojam.com> Fred> "bash" doesn't make me set a variable to control saving of history Fred> to ~/.bash_history; I'd be perfectly happy if Python wrote Fred> ~/.python_history by default ... Fred, I was just following the trend established with PYTHONSTARTUP. It appears Guido did it that way on purpose... It doesn't much matter to me, though I wonder how system-dependent the code might get if you needed it to be available across multiple platforms. Unix, Windows and Mac all have different (sometimes nonexistent) notions of HOME, so it would be difficult to implement one mechanism that worked in a foolproof way. As for limiting the number of lines read or written (where should the truncation take place?), I'll gladly add a size parameter to either read_history or write_history if the underlying readline functions support the capability. Skip From gstein at lyra.org Thu Jul 6 04:27:21 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 5 Jul 2000 19:27:21 -0700 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14691.49755.365679.923078@beluga.mojam.com>; from skip@mojam.com on Wed, Jul 05, 2000 at 06:18:51PM -0500 References: <14691.49755.365679.923078@beluga.mojam.com> Message-ID: <20000705192721.A29590@lyra.org> On Wed, Jul 05, 2000 at 06:18:51PM -0500, Skip Montanaro wrote: > Along the same lines, I have some pretty simple mods to readline.c and > rlcompleter.py that use atexit to automatically save the current history to > the file identified by the PYTHONHISTORY environment variable. (If unset, > no history read/write is done). If we aren't in feature freeze, I'd like to > check it in. I'm against additional magic environment variables. Can't you just have people put something into their .pythonrc file? Or will it still require some C-level changes? Basically, can you point people at doing: .pythonrc: import rlhistory rlhistory.save_to('/home/gstein/.py_history') Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Thu Jul 6 04:36:01 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 22:36:01 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <20000705192721.A29590@lyra.org> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> Message-ID: <14691.61585.352105.188917@cj42289-a.reston1.va.home.com> Greg Stein writes: > I'm against additional magic environment variables. > > Can't you just have people put something into their .pythonrc file? Or will > it still require some C-level changes? > > Basically, can you point people at doing: I think this makes the most sense. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Thu Jul 6 03:16:05 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 20:16:05 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <20000705192721.A29590@lyra.org> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> Message-ID: <14691.56789.869210.523939@beluga.mojam.com> Greg> I'm against additional magic environment variables. Greg> Can't you just have people put something into their .pythonrc Greg> file? Or will it still require some C-level changes? C-level changes are still required, but just to expose the existing functions in the GNU history library. After responding to Fred's note, I realized that what I'm doing in rlcompleter.py: import os histfile = os.getenv("PYTHONHISTORY") if histfile is not None: try: readline.read_history_file(histfile) except IOError: pass import atexit atexit.register(readline.write_history_file, histfile) del os, histfile could just as easily be done in ~/.pythonrc. Maybe I should retract the rlcompleter mods and just give something like import os histfile = os.path.join(os.environ["HOME"], ".python_history") try: readline.read_history_file(histfile) except IOError: pass import atexit atexit.register(readline.write_history_file, histfile) del os, histfile as an example in a yet-to-be-written libreadline.tex. Skip From fdrake at beopen.com Thu Jul 6 04:55:31 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 22:55:31 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14691.56789.869210.523939@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> <14691.56789.869210.523939@beluga.mojam.com> Message-ID: <14691.62755.609990.761864@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > as an example in a yet-to-be-written libreadline.tex. So when can I expect this to be checked in??? :-) (Surely you didn't expect me not to jump? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Thu Jul 6 05:40:15 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 23:40:15 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 References: <200007052256.PAA12103@slayer.i.sourceforge.net> Message-ID: <14691.65439.950090.60795@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> Add more "volatile" decls to stop gcc -Wall warnings. TP> Somebody w/ gcc please check that the wngs are gone! The ones in pypcre.c are gone, but there are still a bunch of other -Wall warnings, none of which I have time to look at right now. Here's an excerpt. -Barry -------------------- snip snip -------------------- [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c -o bufferobject.o bufferobject.c: In function `PyBuffer_New': bufferobject.c:174: warning: value computed is not used gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c -o classobject.o classobject.c: In function `instance_dealloc': classobject.c:526: warning: unused variable `_Py_RefTotal' [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c object.c -o object.o object.c: In function `_PyTrash_deposit_object': object.c:1172: warning: unused variable `hold' [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c pystate.c -o pystate.o pystate.c: In function `PyInterpreterState_New': pystate.c:45: warning: value computed is not used [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./gcmodule.c ./gcmodule.c: In function `debug_cycle': ./gcmodule.c:295: warning: unsigned int format, long unsigned int arg (arg 5) ./gcmodule.c: In function `collect': ./gcmodule.c:374: warning: int format, long int arg (arg 3) ./gcmodule.c:374: warning: int format, long int arg (arg 4) ./gcmodule.c:374: warning: int format, long int arg (arg 5) ./gcmodule.c:438: warning: int format, long int arg (arg 3) ./gcmodule.c:438: warning: int format, long int arg (arg 4) [...] gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c ./posixmodule.c:496: warning: `posix_strint' defined but not used [...] gcc -fpic -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./linuxaudiodev.c ./linuxaudiodev.c: In function `newladobject': ./linuxaudiodev.c:68: warning: unused variable `opendev' ./linuxaudiodev.c:67: warning: unused variable `ctldev' ./linuxaudiodev.c: At top level: ./linuxaudiodev.c:406: warning: `ins' defined but not used [...] gcc -fpic -DWITH_APPINIT -I/usr/X11R6/include -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./_tkinter.c ./_tkinter.c: In function `Sleep': ./_tkinter.c:270: warning: unused variable `frac' ./_tkinter.c: In function `Tkapp_DeleteFileHandler': ./_tkinter.c:1595: warning: unused variable `data' gcc -fpic -DWITH_APPINIT -I/usr/X11R6/include -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./tkappinit.c ./tkappinit.c: In function `Tcl_AppInit': ./tkappinit.c:22: warning: `main' is usually a function [...] gcc -fpic -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./_cursesmodule.c ./_cursesmodule.c: In function `PyCurses_UngetMouse': ./_cursesmodule.c:1646: warning: unused variable `rtn' ./_cursesmodule.c: In function `PyCurses_MouseMask': ./_cursesmodule.c:1950: warning: unused variable `rtn' ./_cursesmodule.c: In function `PyCurses_TypeAhead': ./_cursesmodule.c:2162: warning: unused variable `err' ./_cursesmodule.c: At top level: ./_cursesmodule.c:1478: warning: `PyCurses_resetty' defined but not used ./_cursesmodule.c:1479: warning: `PyCurses_savetty' defined but not used From bwarsaw at beopen.com Thu Jul 6 05:46:56 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 23:46:56 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> Message-ID: <14692.304.49138.508128@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> At lunch today, Guido raised almost the same question! Tim JH> and I argued that we should continue the feature freeze, and JH> spend any extra time wasted while we wait for CNRI to quit JH> stalling to resolve open bugs and do more testing. It's been JH> a long time since the last bug fix release, and there are JH> already a lot of new features. We'd probably be best served JH> by working hard to make 2.0 stable and solid -- and then JH> getting 2.1 released quickly. I'm really quite torn. The more rational side of my brain agrees with this position. OTOH, it just doesn't make much sense to me to add list comprehensions and augmented assignments (and a raft of other new features) in a 2.1 release. Seems like 2.0 is where all the new stuff should go, with 2.x's as bug fix releases. Think of all the new features added in 1.5.2 (a /micro/ release for gawds' sake). In retrospect, that was nutty. ah-hell-let's-release-a-1.6-after-all-ly y'rs, -Barry From tim_one at email.msn.com Thu Jul 6 05:45:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 23:45:36 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 In-Reply-To: <14691.65439.950090.60795@anthem.concentric.net> Message-ID: [Barry, quotes Tim's checkin comment] > TP> Add more "volatile" decls to stop gcc -Wall warnings. > TP> Somebody w/ gcc please check that the wngs are gone! > The ones in pypcre.c are gone, Since pypcre.c is the only file I changed, that's actually good news . Thank you for checking. > but there are still a bunch of other > -Wall warnings, none of which I have time to look at right now. > > Here's an excerpt. > ... Also good! If we keep posting this relentlessly, it *may* eventually shame the authors into cleaning up their code . From bwarsaw at beopen.com Thu Jul 6 05:47:50 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 5 Jul 2000 23:47:50 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? References: <14691.49755.365679.923078@beluga.mojam.com> Message-ID: <14692.358.213728.411981@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> Along the same lines, I have some pretty simple mods to SM> readline.c and rlcompleter.py that use atexit to automatically SM> save the current history to the file identified by the SM> PYTHONHISTORY environment variable. (If unset, no history SM> read/write is done). If we aren't in feature freeze, I'd like SM> to check it in. +1 And +10000...000 if you can make it properly record multi-line input. -Barry From guido at beopen.com Thu Jul 6 06:52:09 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 05 Jul 2000 23:52:09 -0500 Subject: [Python-Dev] list comprehensions again... In-Reply-To: Your message of "Wed, 05 Jul 2000 23:46:56 -0400." <14692.304.49138.508128@anthem.concentric.net> References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> Message-ID: <200007060452.XAA11841@cj20424-a.reston1.va.home.com> > I'm really quite torn. The more rational side of my brain agrees with > this position. OTOH, it just doesn't make much sense to me to add > list comprehensions and augmented assignments (and a raft of other new > features) in a 2.1 release. Seems like 2.0 is where all the new stuff > should go, with 2.x's as bug fix releases. That was my reasoning too -- which is why I was quite torn too at lunch (not just by the menu choices). I believe earlier we discussed how in particular list comprehensions don't affect much else, so even if they are broken, that shouldn't affect the stability of all the other new code that we put in, and I don't see how they could hold up the 2.0final release much. I'm much less sure about augmented assignments -- that's one big sucker of a patch! > Think of all the new features added in 1.5.2 (a /micro/ release for > gawds' sake). In retrospect, that was nutty. Yesh... > ah-hell-let's-release-a-1.6-after-all-ly y'rs, That's an in-joke :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Thu Jul 6 05:52:28 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 22:52:28 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14692.358.213728.411981@anthem.concentric.net> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> Message-ID: <14692.636.850060.295979@beluga.mojam.com> BAW> And +10000...000 if you can make it properly record multi-line BAW> input. I take it there's an implicit smiley in there somewhere. All I do is expose the read_history and write_history in the GNU history library. The rest is up to readline & Python. Skip From tim_one at email.msn.com Thu Jul 6 05:51:53 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 5 Jul 2000 23:51:53 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.304.49138.508128@anthem.concentric.net> Message-ID: OK, I'll be serious this time: if "the next release" is next week, damn straight I want to stick to the feature freeze. But if it becomes predictably delayed for months, sure, open the floodgates again. Unfortunately, the stuff holding up the release isn't technical in nature, so there's nothing most of us can do to affect the outcome either way. From fdrake at beopen.com Thu Jul 6 05:53:12 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 5 Jul 2000 23:53:12 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.304.49138.508128@anthem.concentric.net> References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> Message-ID: <14692.680.483792.544003@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > Think of all the new features added in 1.5.2 (a /micro/ release for > gawds' sake). In retrospect, that was nutty. Are you saying we should re-label that 1.6? That may prove... convenient. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Thu Jul 6 06:03:30 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 23:03:30 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: References: <14692.304.49138.508128@anthem.concentric.net> Message-ID: <14692.1298.368572.533393@beluga.mojam.com> Well, how about taking a baseline snapshot now and branching the tree (I can almost hear Barry groaning all the way in Chicago...)? If the CNRI stuff gets cleared up quickly, the baseline + bug fixes becomes the 2.0 release and the other branch becomes 2.1 or something later. If it takes several weeks or a month (or more?), the snapshot gets forgotten and the branch becomes 2.0. I know branching is a struggle, probably not helped by the addition of the SourceForge stuff to the mix, but it might work out here. Skip From guido at beopen.com Thu Jul 6 07:04:19 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 00:04:19 -0500 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: Your message of "Wed, 05 Jul 2000 22:52:28 EST." <14692.636.850060.295979@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> Message-ID: <200007060504.AAA11934@cj20424-a.reston1.va.home.com> > BAW> And +10000...000 if you can make it properly record multi-line > BAW> input. > > I take it there's an implicit smiley in there somewhere. All I do is expose > the read_history and write_history in the GNU history library. The rest is > up to readline & Python. Barry was serious. IDLE does this right -- it remembers and lets you recall and edit entire multi-line commands. It's understood that readline doesn't support this, but at the same time it's a severe limitation that means that readline will never be good enough for the E in CP4E. This doesn't mean it's not an improvement over no line editing at all! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From tim_one at email.msn.com Thu Jul 6 06:14:48 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 00:14:48 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007060042.TAA06919@cj20424-a.reston1.va.home.com> Message-ID: > ... > Anyway, the patches are currently in Tim Peters' court. Forgot to say this before: among moving, bug-fixing, general testing, and the O'Reilly conference, I don't believe I'll find time to look at these patches for at least 2-- and more likely 3 --weeks. So if somebody is especially keen to get this in soon, feel encouraged to reassign the patch to yourself. From tim_one at email.msn.com Thu Jul 6 06:14:50 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 00:14:50 -0400 Subject: [Python-Dev] Spelling check: more typos In-Reply-To: <01f001bfe6bb$5198bb60$f2a6b5d4@hagrid> Message-ID: Time to clear this one up too : Eric was taken in by a faux (i.e., not mine) "-ly y'rs" signoff. And if we're talking about one process, it's the process's exit code; if more than one, the processes' exit codes. "process exit code" also works for me. english-is-what-we-make-it-ly y'rs - tim From tim_one at email.msn.com Thu Jul 6 06:25:58 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 00:25:58 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.1298.368572.533393@beluga.mojam.com> Message-ID: [Skip Montanaro] > Well, how about taking a baseline snapshot now and branching the > tree (I can almost hear Barry groaning all the way in Chicago...)? > ... > I know branching is a struggle, probably not helped by the addition of the > SourceForge stuff to the mix, but it might work out here. That's exactly the kind of redirection of effort that a feature freeze is imposed to prevent. Even talking about it takes time away from work that *needs* to be completed for the release. OTOH, if the release is months away anyway, there's no need for a fork . From skip at mojam.com Thu Jul 6 06:27:38 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 23:27:38 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060504.AAA11934@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> <200007060504.AAA11934@cj20424-a.reston1.va.home.com> Message-ID: <14692.2746.526025.335108@beluga.mojam.com> Guido> Barry was serious. IDLE does this right -- it remembers and lets Guido> you recall and edit entire multi-line commands. Yeah, but readline isn't a command editor, just a line editor and history. If I execute the following interactively: for i in range(10): print i I can use C-p to retrieve the lines and re-execute them. It's no better or worse than what bash does. In fact, with some versions of bash, it does recall entire multiline commands, for example, taking for f in `ls *.c` ; do echo $f done and returning for f in `ls *.c` ; do echo $f ; done instead when you retrieve it from the history. I find this particularly annoying and would much rather have the line-by-line recall that older versions of bash (and now Python) support. I've never used IDLE. What does it do to facilitate command recall and editing that's much different than Python or bash? Would it pop up the above Python for loop into a text editor widget and execute it when the widget is closed? Skip From fdrake at beopen.com Thu Jul 6 06:35:30 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 00:35:30 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14692.2746.526025.335108@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> <200007060504.AAA11934@cj20424-a.reston1.va.home.com> <14692.2746.526025.335108@beluga.mojam.com> Message-ID: <14692.3218.271993.100946@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > instead when you retrieve it from the history. I find this particularly > annoying and would much rather have the line-by-line recall that older > versions of bash (and now Python) support. This is something where you'd really want to be able to select which you prefer and toggle back and forth. I usually want a whole block, but sometimes I want to construct a new block from pieces of previous blocks. > I've never used IDLE. What does it do to facilitate command recall and > editing that's much different than Python or bash? Would it pop up the > above Python for loop into a text editor widget and execute it when the > widget is closed? No; it retrieves the whole multi-line block and inserts is at the prompt, allowing you to edit any part of it before type to execute. It's better than the bash behavior because it doesn't replace the actual newlines with semicolon separators (which wouldn't be sufficient for arbitrary Python code anyway). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Thu Jul 6 06:44:09 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 00:44:09 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> Message-ID: <14692.3737.500081.892301@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: BAW> And +10000...000 if you can make it properly record BAW> multi-line input. SM> I take it there's an implicit smiley in there somewhere. Well, would classify a wistful, dreamy sort of smile as "implicit"? :) -Barry From skip at mojam.com Thu Jul 6 06:47:10 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 23:47:10 -0500 (CDT) Subject: [Python-Dev] grumble, grumble - makesetup prepends leading $(srcdir) - why? Message-ID: <14692.3918.493708.366779@beluga.mojam.com> Here's one that's bugged me for awhile that I'm tired of working around. Perhaps someone can explain why makesetup does what it does. In my Modules/Setup.local file I have TOP=$(HOME)/src/python EDIR=$(TOP)/PyExtensions1.5 llop $(EDIR)/llopmodule.c # helper function(s) for latlong.py This gets converted into llopmodule.o: $(srcdir)/$(EDIR)/llopmodule.c; $(CC) $(CCSHARED) $(CFLAGS) -c $(srcdir)/$(EDIR)/llopmodule.c llopmodule$(SO): llopmodule.o; $(LDSHARED) llopmodule.o -o llopmodule$(SO) in Modules/Makefile. Is there a good reason why is $(srcdir)/ prepended to the source file reference, thus breaking my local module references? It seems the culprit is case $src in glmodule.c) ;; /*) ;; *) src='$(srcdir)/'$src;; esac around about line 193. I think this should be changed to case $src in glmodule.c) ;; /*) ;; \$*) ;; *) src='$(srcdir)/'$src;; esac or something similar that protects paths that begin with a Make variable. That fix works for me. Any objections to me checking it in? Also, who died and made glmodule.c king? Skip From bwarsaw at beopen.com Thu Jul 6 06:54:36 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 00:54:36 -0400 (EDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> <200007060504.AAA11934@cj20424-a.reston1.va.home.com> <14692.2746.526025.335108@beluga.mojam.com> Message-ID: <14692.4364.272173.857069@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> I can use C-p to retrieve the lines and re-execute them. It's SM> no better or worse than what bash does. In fact, with some SM> versions of bash, it does recall entire multiline commands, SM> for example, taking | for f in `ls *.c` ; do | echo $f | done SM> and returning SM> for f in `ls *.c` ; do echo $f ; done SM> instead when you retrieve it from the history. I find this SM> particularly annoying and would much rather have the SM> line-by-line recall that older versions of bash (and now SM> Python) support. Not me. I love this particular feature of bash. I'm using 2.03. And it's one killer (IMO) feature of IDLE. -Barry From skip at mojam.com Thu Jul 6 06:58:11 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 5 Jul 2000 23:58:11 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14692.4364.272173.857069@anthem.concentric.net> References: <14691.49755.365679.923078@beluga.mojam.com> <14692.358.213728.411981@anthem.concentric.net> <14692.636.850060.295979@beluga.mojam.com> <200007060504.AAA11934@cj20424-a.reston1.va.home.com> <14692.2746.526025.335108@beluga.mojam.com> <14692.4364.272173.857069@anthem.concentric.net> Message-ID: <14692.4579.624873.898969@beluga.mojam.com> SM> for f in `ls *.c` ; do echo $f ; done SM> ... I find this particularly annoying and would much rather have the SM> line-by-line recall that older versions of bash (and now Python) SM> support. BAW> Not me. I love this particular feature of bash. I'm using 2.03. BAW> And it's one killer (IMO) feature of IDLE. My main (error) reason for recalling a multiline command in bash is to insert a command I forgot to include, which is probably why I detest the way bash 2.x does command recall. Does IDLE allow new lines to be inserted into multiline commands or is it restricted to editing the existing lines? ESR is probably pretty damn good at curses in Python by now. Perhaps he can blend readline and curses together into a "simple" multiline command recall editor... ;-) Skip From Mark.Favas at per.dem.csiro.au Thu Jul 6 07:01:59 2000 From: Mark.Favas at per.dem.csiro.au (Favas, Mark (EM, Floreat)) Date: Thu, 6 Jul 2000 13:01:59 +0800 Subject: [Python-Dev] Defining _XOPEN_SOURCE in Python.h breaks 2.0b1 on Tru64 Unix Message-ID: This change results in mathmodule.c failing to compile (rint is undefined) due to an interaction between defining _XOPEN_SOURCE and the use of _XOPEN_SOURCE_EXTENDED in the system includes (/usr/include/math.h). Yes, configure correctly defines HAVE_RINT. This change also results in a number of errors and warnings in timemodule.c, and probably further modules down the compilation chain. From tim_one at email.msn.com Thu Jul 6 07:18:43 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 01:18:43 -0400 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <14692.4579.624873.898969@beluga.mojam.com> Message-ID: [Skip Montanaro] > ... > Does IDLE allow new lines to be inserted into multiline commands or > is it restricted to editing the existing lines? Insertion is easy. In fact, it's sometimes surprising! The deal is that ENTER means two things in the IDLE shell: it may mean "insert a new line", or it may mean "I'm done with my edits, so run this block again". Which action IDLE performs depends on where the cursor is at the time ENTER is hit (whether or not at the end of the copied block). Lovely as the feature is, I think it gets in my way more often than not, as, e.g., I'm very likely to copy a multiline for-loop down and change just the limit on a range; then hitting ENTER doesn't do what I expect. there's-nothing-about-a-ui-somebody-won't-hate-ly y'rs - tim From guido at beopen.com Thu Jul 6 09:00:49 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 02:00:49 -0500 Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: Your message of "Wed, 05 Jul 2000 20:16:05 EST." <14691.56789.869210.523939@beluga.mojam.com> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> <14691.56789.869210.523939@beluga.mojam.com> Message-ID: <200007060700.CAA01658@cj20424-a.reston1.va.home.com> > C-level changes are still required, but just to expose the existing > functions in the GNU history library. After responding to Fred's note, I > realized that what I'm doing in rlcompleter.py: > > import os > histfile = os.getenv("PYTHONHISTORY") > if histfile is not None: > try: > readline.read_history_file(histfile) > except IOError: > pass > import atexit > atexit.register(readline.write_history_file, histfile) > del os, histfile > > could just as easily be done in ~/.pythonrc. Maybe I should retract the > rlcompleter mods and just give something like > > import os > histfile = os.path.join(os.environ["HOME"], ".python_history") > try: > readline.read_history_file(histfile) > except IOError: > pass > import atexit > atexit.register(readline.write_history_file, histfile) > del os, histfile > > as an example in a yet-to-be-written libreadline.tex. Yes, much better. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Thu Jul 6 09:52:14 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 09:52:14 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> Message-ID: <39643AAE.B8448E4@lemburg.com> "M.-A. Lemburg" wrote: > > Fredrik Lundh wrote: > > > > mal wrote: > > > > > The idea is not new: strings and Unicode should have more > > > or less the same methods to enhance their compatibility. > > > > > > The attached patch adds encoding capabilities to normal > > > strings and extends the builtin str() to accept an optional > > > encoding (and error) argument. It also tries to reuse the > > > already available Unicode codecs for the purposes of strings > > > (conversions are done via the default encoding in both > > > directions). > > > > ... > > > > > What do you think about this ? Should I add it to CVS > > > as experiment ? > > > > +1 on the "encode" part > > > > -0 on the "str" part (intuitively, it's -1, but I don't have > > any good arguments against it right now... maybe later) > > The str() extension complements unicode() which also works > as constructor for object given an encoding. > > Ideally, unicode() should also look for __unicode__() on instances > just like str() looks for __str__(). > > Note that we could also have a .decode() method instead of > modifying str(), but this would break symmetry to Unicode, > since you can't decode Unicode into anything... Anybody else have an opinion on this idea ? I'd like to get this done before the release of 2.0b1. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Thu Jul 6 10:53:47 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 6 Jul 2000 01:53:47 -0700 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Objects unicodeobject. c,2.33,2.34 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD276@RED-MSG-50> ! if (c1 > (1<<11) * 26) ! c1 += utf16Fixup[c1>>11]; ! if (c2 > (1<<11) * 26) ! c2 += utf16Fixup[c2>>11]; ! This change from the patch is kind of silly. You've made the code flow more complicated for no particularly good reason, esp. considering the size of utf16Fixup[]. That is, the cost in the CPU of handling the branch prediction is likely to be much higher than the array lookup for every character. Bill From fredrik at pythonware.com Thu Jul 6 11:02:45 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 11:02:45 +0200 Subject: [Python-Dev] Spelling check: more typos References: <14690.56733.627266.907044@temoleh.chem.uu.nl> <20000705200043.D7564@ludwig.cnri.reston.va.us> Message-ID: <006b01bfe728$f4dcc380$0900a8c0@SPIFF> greg wrote: > In American English, "license" is both noun and verb. In the rest of > the world, "licence" is the noun and "license" the verb. should have realized that all dictionaries I consulted happened to be american. when I saw your post, I looked it up in the dictionaries I have at home (all British), and they all pointed out that the americans have it all mixed up. Just like those "Original Swedish Apfelstrudel" I found in Palo Alto... From jack at oratrix.nl Thu Jul 6 11:05:12 2000 From: jack at oratrix.nl (Jack Jansen) Date: Thu, 06 Jul 2000 11:05:12 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: Message by "M.-A. Lemburg" , Thu, 06 Jul 2000 00:19:38 +0200 , <3963B47A.638A7A82@lemburg.com> Message-ID: <20000706090512.EF3EC37186E@snelboot.oratrix.nl> > BTW, if your compiler supports Unicode (that is provides > a working wctype.h file), you can compile Python using > the compile time switch --with-wctype-functions. Python > will then use the C libs iswXXX() APIs which should return > more or less the same values as the Python ones (could be that > the C lib is Unicode 2.0 -- so YMMV). Note that this hasn't > been tested much yet. Feedback is welcome. Unfortunately the native wctype implementation is apparently different enough that it makes test_unicode fail. But I've solved the problem by splitting the 5000-entry switch statement into multiple switches with 1000 entries each. That's good enough for the CodeWarrior compiler (which doesn't have the least problem with the tiny 256-case switch in ceval.c). It may not be good enough for people who have compilers with really low limits on the number of cases in a switch, though. I'll check it in shortly. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack at oratrix.nl Thu Jul 6 11:12:10 2000 From: jack at oratrix.nl (Jack Jansen) Date: Thu, 06 Jul 2000 11:12:10 +0200 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack In-Reply-To: Message by "Tim Peters" , Wed, 5 Jul 2000 22:14:39 -0400 , Message-ID: <20000706091210.443F537186E@snelboot.oratrix.nl> > a) Add comments to the #ifdef's saying they're for the Mac. "Mystery code" > is bad in group-maintained software. I expect Jack will maintain that it > isn't really Mac-specific, but a wonderful feature for any platform that > cares to #define USE_STACKCHECK and PyOS_CheckStack. Then I preemptively > sneer in his general direction . Hehheh:-) But I think it actually is used by some of the other ports. Any platform that doesn't guarantee a vm-hole between the stack and everything else should use a stack check, and this'll probably include all the handhelds and such. > b) Wonder out loud why this code is useful on a Mac but not other platforms. > We can get segfaulting recursion while print'ing and repr'ing on all > platforms. So shouldn't we work to catch that on all platforms too? Macs > shouldn't be something special wrt this. Well, a segfault is bad, but silently pushing the stack into the heap or into other random data is worse. And as the stackcheck isn't free it isn't used on other platforms. Moreover, I'm not even sure you can determine the stack limit on all platforms... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From thomas at xs4all.net Thu Jul 6 11:46:32 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 6 Jul 2000 11:46:32 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007060452.XAA11841@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 05, 2000 at 11:52:09PM -0500 References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> <200007060452.XAA11841@cj20424-a.reston1.va.home.com> Message-ID: <20000706114632.H13478@xs4all.nl> On Wed, Jul 05, 2000 at 11:52:09PM -0500, Guido van Rossum wrote: > I'm much less sure about augmented assignments -- that's one big > sucker of a patch! Ah, but it fits so nicely with the rest of Python ! :) The changes to support the new grammar, the new bytecodes and the __overload_ab__ methods are pretty teensy, but there's a lot of code to support the in-place operators in builtin and extension types, keeping the current API's semantics regarding conversion and such. In fact, test_augassign is just as large as the changes to ceval.c, and larger than those to compile.c ;) I agree though, that it's a big sucker of a patch to take in at once. I haven't found any bugs lately, but I don't use it that much. But it should run perfectly with old code, even if you just change all occurances of 'x = x + y' into 'x += y'. The worst thing that happens is that spam[something()] += other() is not entirely the same as: idx = something() spam[idx] = spam[idx] + other() but rather val = other() idx = something() spam[idx] = val because of the order of argument evaluation. But this shouldn't come as a suprise to anyone who has ever looked at the order of argument evaluation (I hadn't, before this) because it is exactly the same order as: spam[something()] = other() Would it help if I delivered it one piece at a time ? ;) I would suggest against adding augmented assignment in 2.0 if it went by the by-now-old schedule of the first beta at july 1st, because this patch can certainly use a full beta cycle to find out if any bugs lurk, but if 2.0 is months away, 2.1 is even more months away. But then, I have no idea about the problems which delay the 2.0 beta cycle, so I shouldn't be making assumptions ;P Advocating-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jul 6 11:48:56 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 11:48:56 +0200 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.33,2.34 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD276@RED-MSG-50> Message-ID: <39645608.9612520B@lemburg.com> Bill Tutt wrote: > > ! if (c1 > (1<<11) * 26) > ! c1 += utf16Fixup[c1>>11]; > ! if (c2 > (1<<11) * 26) > ! c2 += utf16Fixup[c2>>11]; > ! > > > > This change from the patch is kind of silly. You've made the code flow more > complicated for no particularly good reason, The reason was that it avoids the fixup lookup for all non-surrogate characters -- the vast majority of all chars processed. > esp. considering the size of > utf16Fixup[]. That is, the cost in the CPU of handling the branch prediction > is likely to be much higher than the array lookup for every character. Note that the lookup also involves a shift operation for every character. But if you insist, I'll do some benchmarking and check which version is faster. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 6 11:52:17 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 11:52:17 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <20000706090512.EF3EC37186E@snelboot.oratrix.nl> Message-ID: <396456D1.1D5EE0A5@lemburg.com> Jack Jansen wrote: > > > BTW, if your compiler supports Unicode (that is provides > > a working wctype.h file), you can compile Python using > > the compile time switch --with-wctype-functions. Python > > will then use the C libs iswXXX() APIs which should return > > more or less the same values as the Python ones (could be that > > the C lib is Unicode 2.0 -- so YMMV). Note that this hasn't > > been tested much yet. Feedback is welcome. > > Unfortunately the native wctype implementation is apparently different enough > that it makes test_unicode fail. But I've solved the problem by splitting the > 5000-entry switch statement into multiple switches with 1000 entries each. > That's good enough for the CodeWarrior compiler (which doesn't have the least > problem with the tiny 256-case switch in ceval.c). It may not be good enough > for people who have compilers with really low limits on the number of cases in > a switch, though. > > I'll check it in shortly. It might also be a good idea to add if (ch < 0x100) switch... statements. Most Unicode chars will be in the Latin-1 range anyway and this should improve performance. I'll add these to the other switches in unicodectype.c too after you've made your changes. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 6 12:03:28 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 12:03:28 +0200 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.33,2.34 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD276@RED-MSG-50> <39645608.9612520B@lemburg.com> Message-ID: <39645970.18CC2B9F@lemburg.com> "M.-A. Lemburg" wrote: > > Bill Tutt wrote: > > > > ! if (c1 > (1<<11) * 26) > > ! c1 += utf16Fixup[c1>>11]; > > ! if (c2 > (1<<11) * 26) > > ! c2 += utf16Fixup[c2>>11]; > > ! > > > > > > > > This change from the patch is kind of silly. You've made the code flow more > > complicated for no particularly good reason, > > The reason was that it avoids the fixup lookup for all non-surrogate > characters -- the vast majority of all chars processed. > > > esp. considering the size of > > utf16Fixup[]. That is, the cost in the CPU of handling the branch prediction > > is likely to be much higher than the array lookup for every character. > > Note that the lookup also involves a shift operation for every > character. > > But if you insist, I'll do some benchmarking and check which > version is faster. Your version: 0.98 sec. Fixed version: 0.96 sec. I don't think it's worth discussing this ;-) What's more interesting is that string compares are twice as fast: Same test: 0.46 sec. This is probably due to the compiler optimizing the memcmp() call which is used in string compares. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Thu Jul 6 12:21:05 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 12:21:05 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> <39643AAE.B8448E4@lemburg.com> Message-ID: <010101bfe733$e84a8750$0900a8c0@SPIFF> mal wrote: > > > > > > > What do you think about this ? Should I add it to CVS > > > > as experiment ? > > > > > > +1 on the "encode" part > > > > > > -0 on the "str" part (intuitively, it's -1, but I don't have > > > any good arguments against it right now... maybe later) > > > > The str() extension complements unicode() which also works > > as constructor for object given an encoding. > > > > Ideally, unicode() should also look for __unicode__() on instances > > just like str() looks for __str__(). > > > > Note that we could also have a .decode() method instead of > > modifying str(), but this would break symmetry to Unicode, > > since you can't decode Unicode into anything... > > Anybody else have an opinion on this idea ? I'd like to get > this done before the release of 2.0b1. Having thought this over, I'm -1 on the str fix. You're changing "str" from being a converter ("convert this to a string") to a string constructor ("create a new 8-bit string"). This is against the "strings are strings" spirit. Cannot you check the rest in, and leave "str" alone for now? From mal at lemburg.com Thu Jul 6 13:08:43 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 13:08:43 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> <39643AAE.B8448E4@lemburg.com> <010101bfe733$e84a8750$0900a8c0@SPIFF> Message-ID: <396468BB.EEC3D6F7@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > > > > > > > What do you think about this ? Should I add it to CVS > > > > > as experiment ? > > > > > > > > +1 on the "encode" part > > > > > > > > -0 on the "str" part (intuitively, it's -1, but I don't have > > > > any good arguments against it right now... maybe later) > > > > > > The str() extension complements unicode() which also works > > > as constructor for object given an encoding. > > > > > > Ideally, unicode() should also look for __unicode__() on instances > > > just like str() looks for __str__(). > > > > > > Note that we could also have a .decode() method instead of > > > modifying str(), but this would break symmetry to Unicode, > > > since you can't decode Unicode into anything... > > > > Anybody else have an opinion on this idea ? I'd like to get > > this done before the release of 2.0b1. > > Having thought this over, I'm -1 on the str fix. > > You're changing "str" from being a converter ("convert this to a > string") to a string constructor ("create a new 8-bit string"). This > is against the "strings are strings" spirit. Um, that was my motivation behind extending str() -- to make the two (str() and unicode()) aliases for the same function in some future Python version. Note that str() is in fact a constructor: you pass it an object and it creates a string from it for you. unicode() does the same thing (except that there's currently no __unicode__() check for instances). > Cannot you check the rest in, and leave "str" alone for now? I'll do that -- you won't be able to decode anything though, because there's no Python interface to PyString_Decode(). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Thu Jul 6 13:52:56 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 06:52:56 -0500 (CDT) Subject: [Python-Dev] oh, and any interest in my readline history stuff? In-Reply-To: <200007060700.CAA01658@cj20424-a.reston1.va.home.com> References: <14691.49755.365679.923078@beluga.mojam.com> <20000705192721.A29590@lyra.org> <14691.56789.869210.523939@beluga.mojam.com> <200007060700.CAA01658@cj20424-a.reston1.va.home.com> Message-ID: <14692.29464.106980.766555@beluga.mojam.com> >>>>> "Guido" == Guido van Rossum writes: >> ... could just as easily be done in ~/.pythonrc. Maybe I should >> retract the rlcompleter mods and just give something like [ ... brilliant example elided ... ] >> as an example in a yet-to-be-written libreadline.tex. Guido> Yes, much better. Okay, so the rlcompleter mods are out. That leaves two measly new methods in readline.c that won't bother anyone. Skip From guido at beopen.com Thu Jul 6 14:53:39 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 07:53:39 -0500 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) In-Reply-To: Your message of "Thu, 06 Jul 2000 12:21:05 +0200." <010101bfe733$e84a8750$0900a8c0@SPIFF> References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> <39643AAE.B8448E4@lemburg.com> <010101bfe733$e84a8750$0900a8c0@SPIFF> Message-ID: <200007061253.HAA02450@cj20424-a.reston1.va.home.com> > Subject: Re: [Python-Dev] 'abc'.encode() and str(obj, encoding) > From: "Fredrik Lundh" > To: "M.-A. Lemburg" , > "Python Developers @ python.org" > Date: Thu, 6 Jul 2000 12:21:05 +0200 > Delivery-Date: Thu Jul 6 06:22:40 2000 > > mal wrote: > > > > > > > > > What do you think about this ? Should I add it to CVS > > > > > as experiment ? > > > > > > > > +1 on the "encode" part > > > > > > > > -0 on the "str" part (intuitively, it's -1, but I don't have > > > > any good arguments against it right now... maybe later) > > > > > > The str() extension complements unicode() which also works > > > as constructor for object given an encoding. > > > > > > Ideally, unicode() should also look for __unicode__() on instances > > > just like str() looks for __str__(). > > > > > > Note that we could also have a .decode() method instead of > > > modifying str(), but this would break symmetry to Unicode, > > > since you can't decode Unicode into anything... > > > > Anybody else have an opinion on this idea ? I'd like to get > > this done before the release of 2.0b1. [/F] > Having thought this over, I'm -1 on the str fix. > > You're changing "str" from being a converter ("convert this to a > string") to a string constructor ("create a new 8-bit string"). This > is against the "strings are strings" spirit. I almost voted with you, except that int() also has an extra argument: int("100", 8) yields 64. In one of my proposals for a type system I've also used the str function and others as a constructor. Since I haven't seen the patch (too much other stuff going on you don't want to know about :-( ), I vote 0; that's neither +0 nor -0. > Cannot you check the rest in, and leave "str" alone for now? That would certainly be safe. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Thu Jul 6 14:18:04 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 08:18:04 -0400 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000703165305.R29590@lyra.org>; from gstein@lyra.org on Mon, Jul 03, 2000 at 04:53:05PM -0700 References: <20000703095600.A12141@thyrsus.com> <20000703165305.R29590@lyra.org> Message-ID: <20000706081804.A24401@thyrsus.com> Greg Stein : > I used: > > $ cvs -z3 -d :ext:gstein at cvs.python.sourceforge.net:/cvsroot/python co python > > The instructions on SF didn't quite work. Adding the :ext: in made it work > fine for me. I'm using CVS 1.10.6 snark:~/WWW/python$ cvs -z3 -d :ext:esr at cvs.python.sourceforge.net:/cvsroot/python co python esr at cvs.python.sourceforge.net's password: cvs checkout: warning: unrecognized response `' from cvs server cvs checkout: warning: unrecognized response `Welcome to cvs1.sourceforge.net' from cvs server cvs checkout: warning: unrecognized response `' from cvs server cvs checkout: warning: unrecognized response `This is a restricted Shell Account' from cvs server cvs checkout: warning: unrecognized response `You cannot execute anything here.' from cvs server cvs checkout: warning: unrecognized response `' from cvs server cvs [checkout aborted]: end of file from server (consult above messages if any) That didn't work either. Anyone got any other ideas? I seem to have CVS 1.10.7. -- Eric S. Raymond See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs. -- Dave Barry From mal at lemburg.com Thu Jul 6 14:09:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 14:09:53 +0200 Subject: [Python-Dev] 'abc'.encode() and str(obj, encoding) References: <39637A3C.9489CB15@lemburg.com> <00de01bfe6b0$045560c0$f2a6b5d4@hagrid> <396383C4.40390E0F@lemburg.com> <39643AAE.B8448E4@lemburg.com> <010101bfe733$e84a8750$0900a8c0@SPIFF> <200007061253.HAA02450@cj20424-a.reston1.va.home.com> Message-ID: <39647711.6BDF96C@lemburg.com> Guido van Rossum wrote: > > [/F] > > Having thought this over, I'm -1 on the str fix. > > > > You're changing "str" from being a converter ("convert this to a > > string") to a string constructor ("create a new 8-bit string"). This > > is against the "strings are strings" spirit. > > I almost voted with you, except that int() also has an extra argument: > int("100", 8) yields 64. In one of my proposals for a type system > I've also used the str function and others as a constructor. I've always thought of str() being a constructor, just like int(), float(), complex() and all the others. The reasoning for adding optionla arguments to str() was to make it match the unicode() signature. > Since I haven't seen the patch (too much other stuff going on you > don't want to know about :-( ), I vote 0; that's neither +0 nor -0. > > > Cannot you check the rest in, and leave "str" alone for now? > > That would certainly be safe. I've checked in the .encode() method and the C APIs that go with it. There's currently no way to access the codec decode methods though (that was part of the str() patch). Anyway, it's cool having the ability to use the codecs for strings too, e.g. you can now do conversions from the current default encoding to say UTF-16 by simply writing: setenv LANG de_DE # Latin-1 encoding python -c "print 'W?nsch dir was...'.encode('utf16')" -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 6 14:17:28 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 14:17:28 +0200 Subject: [Python-Dev] SRE's match objects are missing .regs ?! Message-ID: <396478D8.26CBD0FA@lemburg.com> Is this intended ? I've often used .regs directly to enhance performance, but it looks as if SRE doesn't support this: Traceback (most recent call last): File "", line 1, in ? File "/home/lemburg/lib/hack.py", line 76, in docs showdocstring(obj.__doc__,2) File "/home/lemburg/lib/hack.py", line 145, in showdocstring sp = m.regs[1][1] AttributeError: regs -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Thu Jul 6 14:27:32 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 6 Jul 2000 14:27:32 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 In-Reply-To: <14691.65439.950090.60795@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 05, 2000 at 11:40:15PM -0400 References: <200007052256.PAA12103@slayer.i.sourceforge.net> <14691.65439.950090.60795@anthem.concentric.net> Message-ID: <20000706142731.K13478@xs4all.nl> On Wed, Jul 05, 2000 at 11:40:15PM -0400, Barry A. Warsaw wrote: > >>>>> "TP" == Tim Peters writes: > TP> Add more "volatile" decls to stop gcc -Wall warnings. > TP> Somebody w/ gcc please check that the wngs are gone! > The ones in pypcre.c are gone, but there are still a bunch of other > -Wall warnings, none of which I have time to look at right now. I actually looked at most of these a couple of weeks back, and most are harmless. For instance: > -------------------- snip snip -------------------- > [...] > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c -o bufferobject.o > bufferobject.c: In function `PyBuffer_New': > bufferobject.c:174: warning: value computed is not used PyObject_INIT((PyObject *)b, &PyBuffer_Type); The 'value computed' is useless. The value computed is computed by the ',' operator, but the only things in there are sideffect operators. The last operation in the string of ',''s is either a void-returning function or an assignment, so I'd classify this one as a cosmetic bug in gcc ;) adding a '(void)' cast to the PyObject_INIT() macro or the calls to it would fix the warning. > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c -o classobject.o > classobject.c: In function `instance_dealloc': > classobject.c:526: warning: unused variable `_Py_RefTotal' Can be fixed by a surrounding #ifdef Py_TRACE_REFS. > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c object.c -o object.o > object.c: In function `_PyTrash_deposit_object': > object.c:1172: warning: unused variable `hold' Can be removed, seems to be left over from before Christians' trash hauling. > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c pystate.c -o pystate.o > pystate.c: In function `PyInterpreterState_New': > pystate.c:45: warning: value computed is not used Similar to PyObject_INIT(), but even sillier ;) Can be fixed in the same manner. > gcc -g -Wall -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c > ./posixmodule.c:496: warning: `posix_strint' defined but not used Looks like an obsoleted helper function, for calling string-int-functions. (Like posix_strintint, which is called in exactly one place.) Unsure if these are leftover or intended for future use ;) If they are just leftover, shouldn't we just make chown do the work posix_strintint does, and remove those two functions ? I also get a few others, by the way (redhat-6.1 supplied egcs-1.1.2): ceval.c: In function `eval_code2': ceval.c:333: warning: `opcode' might be used uninitialized in this function ceval.c:334: warning: `oparg' might be used uninitialized in this function The second one is fairly obvious: oparg is only initialized if opcode has an argument, but gcc doesn't know when that is. So as far as gcc is concerned it is possible to enter a branch that uses oparg without initializing it. The opcode one is because it's possible as far as gcc is concerned, to jump to on_error on the first iteration of the large for(;;) loop, before opcode is initialized. This might actually be possible, I think, if a signal arrives before the first time through the loop. ./pypcre.c: In function `compile_branch': ./pypcre.c:1222: warning: `c' might be used uninitialized in this function Just looking at this one gave me a headache. This code can definately use a good indent run, or better yet, replacement! I can't figure out why gcc complains about this one. ./socketmodule.c: In function `newSSLObject': ./socketmodule.c:1963: warning: unused variable `str' ./socketmodule.c: At top level: ./socketmodule.c:358: warning: `SSL_setattr' declared `static' but never defined As you can see, I compile the socket module with SSL ;) Both of these can be just removed, but I'm not sure howmuch of the SSL part is still 'work in progress'. And then there's some warnings in _cursesmodule.c, _tkinter.c, gcmodule.c, linuxaudiodev.c and tkappinit.c that the module maintainers should look at. (nudge nudge.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fredrik at pythonware.com Thu Jul 6 14:31:42 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 14:31:42 +0200 Subject: [Python-Dev] SRE's match objects are missing .regs ?! References: <396478D8.26CBD0FA@lemburg.com> Message-ID: <01bc01bfe746$25940d90$0900a8c0@SPIFF> mal wrote: > Is this intended ? I've often used .regs directly to enhance > performance, but it looks as if SRE doesn't support this: if you can figure out where (in the 1.5.2 docs) they're documented, I'll add them ;-) (I'd rather add a "spans" method, but that's me...) From akuchlin at cnri.reston.va.us Thu Jul 6 14:32:23 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Thu, 6 Jul 2000 08:32:23 -0400 Subject: [Python-Dev] SRE's match objects are missing .regs ?! In-Reply-To: <396478D8.26CBD0FA@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 02:17:28PM +0200 References: <396478D8.26CBD0FA@lemburg.com> Message-ID: <20000706083223.A29375@newcnri.cnri.reston.va.us> On Thu, Jul 06, 2000 at 02:17:28PM +0200, M.-A. Lemburg wrote: >Is this intended ? I've often used .regs directly to enhance >performance, but it looks as if SRE doesn't support this: .regs was never documented in the library reference, nor in the docstrings in libre.tex; it was an underlying implementation detail some people happened to take advantage of. If /F wants to add it in order to be nice, fine; I certainly wouldn't bother to do that. -amk From pavlos at gaaros.com Thu Jul 6 14:46:50 2000 From: pavlos at gaaros.com (Pavlos Christoforou) Date: Thu, 6 Jul 2000 08:46:50 -0400 (EDT) Subject: [Python-Dev] Re: [Zope-dev] ExtensionClass and __radd__()? In-Reply-To: <20000705183046.A26381@ludwig.cnri.reston.va.us> Message-ID: On Wed, 5 Jul 2000, Greg Ward wrote: > > Well, it's a nice theory. It doesn't explain why '__add__()' works for > ExtensionClass while '__radd__()' does not; perhaps ExtensionClass > implements that much of Python's class semantics, but doesn't go as far > as '__radd__()'. > A quick note which you probably already know: grep add ExtensionClass.c gives: static PyObject *py__add__, *py__sub__, *py__mul__, *py__div__, INIT_PY_NAME(__add__); BINOP(add,Add) FILLENTRY(nm->nb, add, add, METH_VARARGS, "Add to another"); FILLENTRY(sm->sq, concat, add, METH_VARARGS, SET_SPECIAL(add,add); subclass_add(PyObject *self, PyObject *v) UNLESS(m=subclass_getspecial(self,py__add__)) return NULL; && AsCMethod(m)->meth==(PyCFunction)add_by_name ASSIGN(m,AsCMethod(m)->type->tp_as_number->nb_add(self,v)); (binaryfunc)subclass_add, /*nb_add*/ (binaryfunc)subclass_add, /*sq_concat*/ return; /* we added a reference; don't delete now */ whereas grep radd ExtensionClass.c returns nothing Pavlos From gstein at lyra.org Thu Jul 6 15:21:52 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 06:21:52 -0700 Subject: [Python-Dev] OK, so how do I make CVS actually *work*? In-Reply-To: <20000706081804.A24401@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 06, 2000 at 08:18:04AM -0400 References: <20000703095600.A12141@thyrsus.com> <20000703165305.R29590@lyra.org> <20000706081804.A24401@thyrsus.com> Message-ID: <20000706062152.P29590@lyra.org> On Thu, Jul 06, 2000 at 08:18:04AM -0400, Eric S. Raymond wrote: > Greg Stein : > > I used: > > > > $ cvs -z3 -d :ext:gstein at cvs.python.sourceforge.net:/cvsroot/python co python > > > > The instructions on SF didn't quite work. Adding the :ext: in made it work > > fine for me. I'm using CVS 1.10.6 > > snark:~/WWW/python$ cvs -z3 -d :ext:esr at cvs.python.sourceforge.net:/cvsroot/python co python > esr at cvs.python.sourceforge.net's password: > cvs checkout: warning: unrecognized response `' from cvs server > cvs checkout: warning: unrecognized response `Welcome to cvs1.sourceforge.net' from cvs server > cvs checkout: warning: unrecognized response `' from cvs server > cvs checkout: warning: unrecognized response `This is a restricted Shell Account' from cvs server > cvs checkout: warning: unrecognized response `You cannot execute anything here.' from cvs server > cvs checkout: warning: unrecognized response `' from cvs server > cvs [checkout aborted]: end of file from server (consult above messages if any) > > That didn't work either. Anyone got any other ideas? > > I seem to have CVS 1.10.7. The response looks like the bare text you get when you "ssh" directly to the server. It prints some stuff then closes the connection. This would indicate to me that your CVS isn't passing the command over to the SF machine. Put this file into, say, /tmp/ssh-verbose: #!/bin/bash echo COMMAND: $@ exec /usr/bin/ssh -v $@ then do: $ export CVS_RSH=/tmp/ssh-verbose $ cvs ... same as above You should get a long stream of debug output. Right after you enter your password, you should see a couple lines like: debug: Sending command: cvs server debug: Entering interactive session. If not, then I'd suspect the CVS is invoking SSH incorrectly. The first line of output should look like: cvs log: warning: unrecognized response `COMMAND: cvs.python.sourceforge.net -l gstein cvs server' from cvs server That `... cvs server' in the command string is the key. I suspect those two words aren't in your command string, so SSH is just opening an interactive shell. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gward at mems-exchange.org Thu Jul 6 15:23:41 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 09:23:41 -0400 Subject: [Python-Dev] Re: [Zope-dev] ExtensionClass and __radd__()? In-Reply-To: ; from pavlos@gaaros.com on Thu, Jul 06, 2000 at 08:46:50AM -0400 References: <20000705183046.A26381@ludwig.cnri.reston.va.us> Message-ID: <20000706092340.B1539@ludwig.cnri.reston.va.us> On 06 July 2000, Pavlos Christoforou said: > A quick note which you probably already know: > > grep add ExtensionClass.c gives: [...lots...] > whereas grep radd ExtensionClass.c returns nothing Yep, did the same myself shortly after posting. It's not really clear what 'py__add__' is and how it works, though, so it's not obvious if 'py__radd__' is the right thing to add, and if so how to add it. Greg If it's just a matter of adding radd (and rsub, rmul, and rdiv) in all those places -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From skip at mojam.com Thu Jul 6 15:54:40 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 08:54:40 -0500 (CDT) Subject: [Python-Dev] how do I release a cvs lock? Message-ID: <14692.36768.23073.781592@beluga.mojam.com> Sjoerd & Fred both let me know that I am locking the Modules directory. How do I unlock it? The "cvs admin" command looks potentially promising, but very low-level. Skip From moshez at math.huji.ac.il Thu Jul 6 15:55:12 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 6 Jul 2000 16:55:12 +0300 (IDT) Subject: Viewing Patches on UNIX Machines (was Re: [Python-Dev] oh, and any interest in my readline history stuff?) In-Reply-To: <14691.54757.459091.820551@beluga.mojam.com> Message-ID: On Wed, 5 Jul 2000, Skip Montanaro wrote: > https://sourceforge.net/patch/?func=detailpatch&patch_id=100742&group_id=5470 I'm using the attached program to watch patches. run like python patch.py 100742 (UNIX only currently, sorry) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. -------------- next part -------------- def get_patch(number): import urllib return urllib.urlopen("http://sourceforge.net/patch/download.php?id=%s" % number) def show_file(file): import os less = os.popen("less", 'w') try: while 1: buf = file.read(4096) if not buf: break less.write(buf) finally: less.close() def show_patch(number): try: patch = get_patch(number) show_file(patch) finally: patch.close() def main(): import sys show_patch(sys.argv[1]) if __name__ == '__main__': main() From fdrake at beopen.com Thu Jul 6 16:03:38 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 10:03:38 -0400 (EDT) Subject: [Python-Dev] Bogus lock in Modules directory Message-ID: <14692.37306.880611.330267@cj42289-a.reston1.va.home.com> There's a bogus read lock in dist/src/Modules from last night; I've confirmed that it's bogus with Skip (whose lock it is), and filed a support request with SourceForge (#103231) to have it removed. I'll let everyone know when this is cleared. You should still be able to pick up updates without problems, but you can't check anything in in the Modules/ directory until this is cleared (because CVS won't let you). The link to the support request is: http://sourceforge.net/support/?func=detailsupport&support_id=103231&group_id=1 -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein at lyra.org Thu Jul 6 16:06:28 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 07:06:28 -0700 Subject: [Python-Dev] how do I release a cvs lock? In-Reply-To: <14692.36768.23073.781592@beluga.mojam.com>; from skip@mojam.com on Thu, Jul 06, 2000 at 08:54:40AM -0500 References: <14692.36768.23073.781592@beluga.mojam.com> Message-ID: <20000706070628.X29590@lyra.org> On Thu, Jul 06, 2000 at 08:54:40AM -0500, Skip Montanaro wrote: > Sjoerd & Fred both let me know that I am locking the Modules directory. How > do I unlock it? The "cvs admin" command looks potentially promising, but > very low-level. If it is an adminstrative-lock, then yes: cvs admin is the trick. But I don't think you can do that on a directory. So... it is probably a bungled directory-lock (e.g. it didn't get cleaned up). If so... then we probably need some SF admins to clean it up. Hmm. I just did a "cvs update" in the Modules directory. No problem. Sjoerd, Fred? What exactly are you referring to? I see nothing... (maybe Skip cleared it already?) Cheers, -g -- Greg Stein, http://www.lyra.org/ From fredrik at pythonware.com Thu Jul 6 16:11:38 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 16:11:38 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> Message-ID: <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> I wrote: > > both modules can be squeezed down to almost nothing. > it just takes a little work. > > fwiw, Tcl's version of the unicodectype file is about 30k, > and compiles to an 8k large object file on my win95 box. Just noticed that _sre.c takes ages to compile on my linux box, and comes out as a 450k object module. it's under 30k on Windows. Methinks gcc expands recursive inlined functions a bit more than visual C. I'll try do get it down under 100k before the final release... From guido at beopen.com Thu Jul 6 17:15:53 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 10:15:53 -0500 Subject: [Python-Dev] how do I release a cvs lock? In-Reply-To: Your message of "Thu, 06 Jul 2000 08:54:40 EST." <14692.36768.23073.781592@beluga.mojam.com> References: <14692.36768.23073.781592@beluga.mojam.com> Message-ID: <200007061515.KAA13255@cj20424-a.reston1.va.home.com> > Sjoerd & Fred both let me know that I am locking the Modules directory. How > do I unlock it? The "cvs admin" command looks potentially promising, but > very low-level. I doubt that cvs admin can help you -- it interfaces to rcs, which doesn't do per-directory locking. More likely a lock file used when you made a checkin or checkout is accidentally left behind. I believe you cannot remove this yourself nor can I help you with it ([re]moving files in the CVS repository tree is not for mere mortals). Submit a service request, they usually take care of it within a few hours. (Click in the "Request Support" entry in the SourceForge section of the left sidebar.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jim at digicool.com Thu Jul 6 16:25:10 2000 From: jim at digicool.com (Jim Fulton) Date: Thu, 06 Jul 2000 10:25:10 -0400 Subject: [Python-Dev] Comparison inconsistency with ExtensionClass References: <20000501184017.A1171@mems-exchange.org> Message-ID: <396496C6.82804F84@digicool.com> Greg Ward wrote: > > Hi all -- > > I seem to have discovered an inconsistency in the semantics of object > comparison between plain old Python instances and ExtensionClass > instances. (I've cc'd python-dev because it looks as though one *could* > blame Python for the inconsistency, but I don't really understand the > guts of either Python or ExtensionClass enough to know.) (demonstration snipped) > The first one and the last two are obvious, but the second one only > works thanks to a trick in PyObject_Compare(): > > if (PyInstance_Check(v) || PyInstance_Check(w)) { > ... > if (!PyInstance_Check(v)) > return -PyObject_Compare(w, v); > ... > } > > However, if I make Simple an ExtensionClass: > > from ExtensionClass import Base > > class Simple (Base): > > Then the "swap v and w and use w's comparison method" no longer works. > Here's the output of the script with Simple as an ExtensionClass: > > v1 == v2? no > v2 == v1? Simple.__cmp__: self=, other=36 > yes > v1 == v2.data? yes > v2.data == v1? yes > > It looks as though ExtensionClass would have to duplicate the trick in > PyObject_Compare() that I quoted, since Python has no idea that > ExtensionClass instances really should act like instances. This smells > to me like a bug in ExtensionClass. Comments? Technically, this *is* a bug in ExtensionClass, however, Python *does* deserve some of the blame. The intepreter actually uses the following rule: Instances of two different "python types" are not compared using type-supplied comparison methods unless: - At least one of the types is InstanceType or - Both of the types are numeric. This rule is rather inconvenient for ExtensionClass. It's also pretty inconvenient for non-ExtensionClass non-numeric extension types that want to be comparable with other things. You can work around this by making your ExtensionClass a numeric type. This should be possible by providing a numeric method. Jim -- Jim Fulton mailto:jim at digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From tismer at appliedbiometrics.com Thu Jul 6 16:33:59 2000 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Thu, 06 Jul 2000 16:33:59 +0200 Subject: [Python-Dev] how do I release a cvs lock? References: <14692.36768.23073.781592@beluga.mojam.com> <200007061515.KAA13255@cj20424-a.reston1.va.home.com> Message-ID: <396498D7.97ABB543@appliedbiometrics.com> Guido van Rossum wrote: > > > Sjoerd & Fred both let me know that I am locking the Modules directory. How > > do I unlock it? The "cvs admin" command looks potentially promising, but > > very low-level. > > I doubt that cvs admin can help you -- it interfaces to rcs, which > doesn't do per-directory locking. > > More likely a lock file used when you made a checkin or checkout is > accidentally left behind. I believe you cannot remove this yourself > nor can I help you with it ([re]moving files in the CVS repository > tree is not for mere mortals). Submit a service request, they usually > take care of it within a few hours. (Click in the "Request Support" > entry in the SourceForge section of the left sidebar.) Do we really want to live on with SourceForge(t) ? It seems to be pleasant for small projects, but maybe it would be more convenient to have a CVS that we control directly? The new starship is very powerful and could stand a couple of CVS repositories easily. While one might argue that this would give to much of Python to BeOpen (they got it already:), I think this could work smoothly. ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From guido at beopen.com Thu Jul 6 17:32:32 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 10:32:32 -0500 Subject: [Python-Dev] Comparison inconsistency with ExtensionClass In-Reply-To: Your message of "Thu, 06 Jul 2000 10:25:10 -0400." <396496C6.82804F84@digicool.com> References: <20000501184017.A1171@mems-exchange.org> <396496C6.82804F84@digicool.com> Message-ID: <200007061532.KAA13361@cj20424-a.reston1.va.home.com> [JimF] > Technically, this *is* a bug in ExtensionClass, however, Python > *does* deserve some of the blame. The intepreter actually uses the > following rule: > > Instances of two different "python types" are not compared > using type-supplied comparison methods unless: > > - At least one of the types is InstanceType or > > - Both of the types are numeric. > > This rule is rather inconvenient for ExtensionClass. > It's also pretty inconvenient for non-ExtensionClass > non-numeric extension types that want to be comparable with > other things. > > You can work around this by making your ExtensionClass a numeric > type. This should be possible by providing a numeric method. Without having investigated all the details of this thread, I suspect that all of this ought to be rethought when we do rich comparisons and revamp coercions. I'd say that would be a good project for Python 2.1... (Which most of the Zopers probably still know as 1.7. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Thu Jul 6 16:33:23 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 10:33:23 -0400 (EDT) Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> Message-ID: <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > Just noticed that _sre.c takes ages to compile on my linux > box, and comes out as a 450k object module. > > it's under 30k on Windows. Wow! Maybe try turning off optimizations? I think there's an option to just turn off inlining, bt I don't know if you can limit the number of recursive inlines. A simpler option: surround the "inline" directive with #ifndef __GNUC__ / #endif. > Methinks gcc expands recursive inlined functions a bit more > than visual C. I'll try do get it down under 100k before the > final release... Now, if we could do that for unicodedata and ucnhash, a lot more people would be happy! Marc-Andre, Bill: Would it be reasonable to have perfect_hash.py actually compress the text strings used for the character names? Since there's such a limited alphabet in use, something special purpose would probably be easy and do a lot of good. When checking the lookup, you could easily decode the string in the table to do the comparison. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Thu Jul 6 17:37:42 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 10:37:42 -0500 Subject: [Python-Dev] how do I release a cvs lock? In-Reply-To: Your message of "Thu, 06 Jul 2000 16:33:59 +0200." <396498D7.97ABB543@appliedbiometrics.com> References: <14692.36768.23073.781592@beluga.mojam.com> <200007061515.KAA13255@cj20424-a.reston1.va.home.com> <396498D7.97ABB543@appliedbiometrics.com> Message-ID: <200007061537.KAA13448@cj20424-a.reston1.va.home.com> > Do we really want to live on with SourceForge(t) ? > It seems to be pleasant for small projects, but > maybe it would be more convenient to have a CVS > that we control directly? > The new starship is very powerful and could stand a couple of > CVS repositories easily. > > While one might argue that this would give to much of Python > to BeOpen (they got it already:), I think this could work > smoothly. In my experience, maintaining the repository, with both anonymous and privileged (commit) access, is a lot of work -- managing user accounts for the privileged, keeping the machine up and running, etc. I'm really quite happy with the level of support we get from SF. In the long run, BeOpen might be interested in running this kind of service for the Python and other communities; but for now, it would just be a burden. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Thu Jul 6 17:40:00 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 10:40:00 -0500 Subject: [Python-Dev] grumble, grumble - makesetup prepends leading $(srcdir) - why? In-Reply-To: Your message of "Wed, 05 Jul 2000 23:47:10 EST." <14692.3918.493708.366779@beluga.mojam.com> References: <14692.3918.493708.366779@beluga.mojam.com> Message-ID: <200007061540.KAA13487@cj20424-a.reston1.va.home.com> > Here's one that's bugged me for awhile that I'm tired of working around. > Perhaps someone can explain why makesetup does what it does. > > In my Modules/Setup.local file I have > > TOP=$(HOME)/src/python > EDIR=$(TOP)/PyExtensions1.5 > llop $(EDIR)/llopmodule.c # helper function(s) for latlong.py > > This gets converted into > > llopmodule.o: $(srcdir)/$(EDIR)/llopmodule.c; $(CC) $(CCSHARED) $(CFLAGS) -c $(srcdir)/$(EDIR)/llopmodule.c > llopmodule$(SO): llopmodule.o; $(LDSHARED) llopmodule.o -o llopmodule$(SO) > > in Modules/Makefile. Is there a good reason why is $(srcdir)/ prepended to > the source file reference, thus breaking my local module references? It > seems the culprit is > > case $src in > glmodule.c) ;; > /*) ;; > *) src='$(srcdir)/'$src;; > esac > > around about line 193. I think this should be changed to > > case $src in > glmodule.c) ;; > /*) ;; > \$*) ;; > *) src='$(srcdir)/'$src;; > esac > > or something similar that protects paths that begin with a Make variable. > That fix works for me. Any objections to me checking it in? Good idea. Go ahead. > Also, who died and made glmodule.c king? It was Jack & me. We're not dead yet! The reason is that glmodule.c is actually generated by a script that is run automatically from the Makefile. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Thu Jul 6 16:41:23 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 6 Jul 2000 16:41:23 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <14692.39091.731830.389350@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 10:33:23AM -0400 References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> Message-ID: <20000706164123.A26534@xs4all.nl> On Thu, Jul 06, 2000 at 10:33:23AM -0400, Fred L. Drake, Jr. wrote: > Fredrik Lundh writes: > > Just noticed that _sre.c takes ages to compile on my linux > > box, and comes out as a 450k object module. > > it's under 30k on Windows. > Wow! Maybe try turning off optimizations? I think there's an > option to just turn off inlining, bt I don't know if you can limit the > number of recursive inlines. A simpler option: surround the "inline" > directive with #ifndef __GNUC__ / #endif. gcc tries to inline functions itself, too, depending on optimization level, and it might be that the heuristics to determine wether it's worth it or not are broken. You can use -fno-inline to see if that's the case. But it might even be that gcc is right, that the larger code is faster, in spite of being larger. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Thu Jul 6 16:49:25 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 10:49:25 -0400 (EDT) Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <20000706164123.A26534@xs4all.nl> References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> <20000706164123.A26534@xs4all.nl> Message-ID: <14692.40053.417868.570920@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > even be that gcc is right, that the larger code is faster, in spite of being > larger. It may be faster, but that doesn't mean the tradeoff is right. ;) Ideally, this shouldn't take a lot of space, simply because we don't want to exclude platforms with substantial *memory* constraints. But we can let benchmarkers decide what the right tradeoff it; the size isn't that big of a concern for me. (I made the right tradeoff -- I traded empty memory slots for filled ones! 512MB is a nice start. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Thu Jul 6 16:53:22 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 10:53:22 -0400 (EDT) Subject: [Python-Dev] how do I release a cvs lock? References: <14692.36768.23073.781592@beluga.mojam.com> <200007061515.KAA13255@cj20424-a.reston1.va.home.com> <396498D7.97ABB543@appliedbiometrics.com> Message-ID: <14692.40290.628899.363800@anthem.concentric.net> >>>>> "CT" == Christian Tismer writes: CT> Do we really want to live on with SourceForge(t) ? It seems CT> to be pleasant for small projects, but maybe it would be more CT> convenient to have a CVS that we control directly? The new CT> starship is very powerful and could stand a couple of CVS CT> repositories easily. CT> While one might argue that this would give to much of Python CT> to BeOpen (they got it already:), I think this could work CT> smoothly. I think for now SF is our home. Trying to move anything at this point would burn much more time than we have. We really want to get releases out asap! At some point we might look at a couple of alternatives, such as: create our own site based on the SF code base; help SF improve their s/w more directly; roll our own using better Python-based tools. -Barry From bwarsaw at beopen.com Thu Jul 6 16:55:36 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 10:55:36 -0400 (EDT) Subject: [Python-Dev] Comparison inconsistency with ExtensionClass References: <20000501184017.A1171@mems-exchange.org> <396496C6.82804F84@digicool.com> Message-ID: <14692.40424.736713.740441@anthem.concentric.net> >>>>> "JF" == Jim Fulton writes: JF> Instances of two different "python types" are not compared JF> using type-supplied comparison methods unless: JF> - At least one of the types is InstanceType or JF> - Both of the types are numeric. JF> This rule is rather inconvenient for ExtensionClass. JF> It's also pretty inconvenient for non-ExtensionClass JF> non-numeric extension types that want to be comparable with JF> other things. I ran into this problem when trying to translate a simple Boolean class into a built-in type. I basically could not get the comparisons to work correctly when I moved to C. So I'm +1 on fixing this at some point (probably as Guido points out, when we add rich comparisons). -Barry From gward at mems-exchange.org Thu Jul 6 17:03:26 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 11:03:26 -0400 Subject: [Python-Dev] help wanted: windows locales In-Reply-To: <00fa01bfe6b5$a8400460$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jul 05, 2000 at 09:17:20PM +0200 References: <00fa01bfe6b5$a8400460$f2a6b5d4@hagrid> Message-ID: <20000706110326.A9547@ludwig.cnri.reston.va.us> On 05 July 2000, Fredrik Lundh said: > windows_lang = { [...] > 0x042d: "eu_ES", # Basque Isn't Basque also spoken in France? > 0x0445: "bn_??", # Bengali Bangladesh I think; possibly India as well. Don't know the country code for Bangladesh. > 0x2809: "en"_BZ, # English (Belize) ^ ^ typo? > 0x0447: "gu_??", # Gujarati I think this is an Indian language too. > 0x043f: "kk_??", # Kazakh If I had to hazard a guess, I'd say Kazakhstan. ;-) > 0x0446: "pa_??", # Punjabi Probably India and Pakistan both. Would it be overkill to allow mapping one Windows hex code to two locale codes, eg. 0x0446 -> ("pa_IN", "pa_PK")? Better not bring up Kashmiri -- if you thought the politics of spelling English was touchy... ;-) Greg From jim at digicool.com Thu Jul 6 17:06:49 2000 From: jim at digicool.com (Jim Fulton) Date: Thu, 06 Jul 2000 11:06:49 -0400 Subject: [Python-Dev] ExtensionClass and __radd__()? References: <20000705183046.A26381@ludwig.cnri.reston.va.us> Message-ID: <3964A089.A8347970@digicool.com> Greg Ward wrote: > > Hi all -- > > looks like ExtensionClass doesn't recognize/implement the '__radd__()' > protocol. Speculation below; first, a demonstration. Normal case: a > regular class Number that knows how to add itself to other number-like > things: (demonstration snipped) > Speculation time: I'm guessing that this is similar to the problem with > 'isinstance()' and ExtensionClass that I found several months ago, which > was heroically debugged by Barry. To recap, it's a mutual > finger-pointing bug: Python (Guido) can claim that it's up to > ExtensionClass (Jim) to emulate the full semantics of Python > classes/instances, but ExtensionClass can claim that Python should be > more relaxed in what it accepts as a "class object" or "instance > object". > > I think the relevant code in Python is in Objects/abstract.c, > specifically 'PyNumber_Add()' and the BINOP macro: > > #define BINOP(v, w, opname, ropname, thisfunc) \ > if (PyInstance_Check(v) || PyInstance_Check(w)) \ > return PyInstance_DoBinOp(v, w, opname, ropname, thisfunc) > > [...] > PyNumber_Add(v, w) > PyObject *v, *w; > { > PySequenceMethods *m; > > BINOP(v, w, "__add__", "__radd__", PyNumber_Add); > [...] > > My guess is that PyInstance_Check() returns false for ExtensionClass > instances. Two possible fixes: loosen up PyInstance_Check(), or loosen > up BINOP. > > Well, it's a nice theory. It doesn't explain why '__add__()' works for > ExtensionClass while '__radd__()' does not; perhaps ExtensionClass > implements that much of Python's class semantics, but doesn't go as far > as '__radd__()'. I'd love to see __radd__ added. ;) I don't remember why it's not there. Maybe I was just lazy. It may be fairly hard to add. I haven't looked in quite a while. As anyone whos looked at ExtensionClass sources may be able to tell, ExtensionClass has to play quite a few tricks to: - Try to sanely bridge the quite different semantics of Python "types" and "classes" (e.g. there's no radd for "types"). - Try to overcome the fact that the interpreter special-cases InstanceType and ClassType pretty liberally. To (try to and mostly succeed to) provide instance semantics I have to do alot of weird indirection. This is especially hard for numeric things. Your analysis of the code demonstrates this issue. ExtensionClass instances are not of type InstanceType. In fact, each ExtensionClass is a separate type and instances of different ExtensionClasses have different types. Note that I just got around to responding to your earlier post "Comparison inconsistency with ExtensionClass". This has a similar root cause: the special-case treatment of InstanceType. I think that the *real* solution to this problem is to get rid of ExtensionClass. ;) To do this, I need to get the features I have in ExtensionClass into Python. I guess there's some hope for that in Python 3K (love that name :). In the mean time, I don't have time to fix the radd problem myself, but would be willing to advise someone who wanted to try to take it on, especially if we could work out some phone or face-to-face sessions. Jim -- Jim Fulton mailto:jim at digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From fredrik at pythonware.com Thu Jul 6 17:09:42 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 6 Jul 2000 17:09:42 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid><00c801bfe754$1a6f8ad0$0900a8c0@SPIFF><14692.39091.731830.389350@cj42289-a.reston1.va.home.com><20000706164123.A26534@xs4all.nl> <14692.40053.417868.570920@cj42289-a.reston1.va.home.com> Message-ID: <013901bfe75c$37eed630$0900a8c0@SPIFF> fred wrote: > Thomas Wouters writes: > > even be that gcc is right, that the larger code is faster, in spite of being > > larger. > > It may be faster, but that doesn't mean the tradeoff is right. ;) > Ideally, this shouldn't take a lot of space, simply because we don't > want to exclude platforms with substantial *memory* constraints. yeah, but people porting SRE to small platforms can switch off inlining completely. if I do that on windows, the resulting DLL is less than 20k. which is pretty okay, I think, if you consider that the DLL contains two separate regular expression engines, a scanner framework, and lots of other stuff... cheers /F From paul at prescod.net Thu Jul 6 17:12:30 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 06 Jul 2000 10:12:30 -0500 Subject: [Python-Dev] list comprehensions again... References: <14691.49563.78765.683762@beluga.mojam.com> <200007060042.TAA06919@cj20424-a.reston1.va.home.com> Message-ID: <3964A1DE.F0878306@prescod.net> Guido van Rossum wrote: > > > Was there a public announcement made about new functionality for > > 2.0? > > Yes, there's something on http://pythonlabs.com/tech/python2.html. We > currently can't commit to a release schedule due to the problems with > CNRI. Between now and the release, someone needs to add something there about the XML support. In general, it is in the interest of the Python community (and of course, my personal interest!) to emphasize Python's XML sophistication. From a marketing point of view, the new XML support could be pushed as sufficient reason for a major version release all by itself. For instance, Even the Guido is impressed when he reads vacuous XML-related press releases from the TCL guys.[1] :) :) Python 2 could be the first language with support for SAX and DOM in the class libraries (though Java is catching fast) and the first to ship Expat as a standard module (on some platforms, anyhow). If the feature freeze "melts", we could probably add SOAP support in a month or so also. [1]http://www.python.org/pipermail/xml-sig/1999-October/003167.html (to be fair, I don't know that the TCL stuff is vacuous, I just presume that any "B2B integration server" is likely to be vacuous...) -- Paul Prescod - Not encumbered by corporate consensus The distinction between the real twentieth century (1914-1999) and the calenderical one (1900-2000) is based on the convincing idea that the century's bouts of unprecented violence, both within nations and between them, possess a definite historical coherence -- that they constitute, to put it simply, a single story. - The Unfinished Twentieth Century, Jonathan Schell Harper's Magazine, January 2000 From esr at thyrsus.com Thu Jul 6 17:27:21 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 11:27:21 -0400 Subject: [Python-Dev] help wanted: windows locales In-Reply-To: <20000706110326.A9547@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Thu, Jul 06, 2000 at 11:03:26AM -0400 References: <00fa01bfe6b5$a8400460$f2a6b5d4@hagrid> <20000706110326.A9547@ludwig.cnri.reston.va.us> Message-ID: <20000706112721.B25443@thyrsus.com> Greg Ward : > > 0x0447: "gu_??", # Gujarati > > I think this is an Indian language too. > > > 0x043f: "kk_??", # Kazakh > > If I had to hazard a guess, I'd say Kazakhstan. ;-) > > > 0x0446: "pa_??", # Punjabi > > Probably India and Pakistan both. Correct on all counts. -- Eric S. Raymond Love your country, but never trust its government. -- Robert A. Heinlein. From fdrake at beopen.com Thu Jul 6 17:50:47 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 11:50:47 -0400 (EDT) Subject: [Python-Dev] Problems with the new unicodectype.c In-Reply-To: <013901bfe75c$37eed630$0900a8c0@SPIFF> References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> <20000706164123.A26534@xs4all.nl> <14692.40053.417868.570920@cj42289-a.reston1.va.home.com> <013901bfe75c$37eed630$0900a8c0@SPIFF> Message-ID: <14692.43735.835843.916140@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > yeah, but people porting SRE to small platforms can switch off > inlining completely. if I do that on windows, the resulting DLL > is less than 20k. So don't worry about the 100K for Linux/x86 unless you just want to test that -fno-inline (or whatever) is passed from the Setup file to the Makefile without makesetup barfing on it. (Not unusual for less common flags, but I think -f* is passed along.) > which is pretty okay, I think, if you consider that the DLL contains > two separate regular expression engines, a scanner framework, and > lots of other stuff... 20K -- 40K I'm not worried about. I'm less worried about the people with *no* RAM, who will run into problems before they try to start python, than about the guys with only a little RAM (say, 128MB ;). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jul 6 18:00:44 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 12:00:44 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <3964A1DE.F0878306@prescod.net> References: <14691.49563.78765.683762@beluga.mojam.com> <200007060042.TAA06919@cj20424-a.reston1.va.home.com> <3964A1DE.F0878306@prescod.net> Message-ID: <14692.44332.771745.446084@cj42289-a.reston1.va.home.com> Paul Prescod writes: > Between now and the release, someone needs to add something there about > the XML support. In general, it is in the interest of the Python > community (and of course, my personal interest!) to emphasize Python's > XML sophistication. From a marketing point of view, the new XML support > could be pushed as sufficient reason for a major version release all by > itself. For instance, Even the Guido is impressed when he reads vacuous > XML-related press releases from the TCL guys.[1] :) :) I've written a bit of text for Guido about this, but it's fairly short. If you, Lars, Andrew or anyone else from the XML gang would like to take a crack at it, here's what I've sent Guido: ------------------------------------------------------------------------ XML Support ........... Python 2.0 introduces new XML tools developed by the XML Special Interest Group (http://www.python.org/sigs/xml-sig/). The widely-accepted Expat XML parser from James Clark is used to provide a high-performance, non-validating parser to Python applications. This parser provides full Unicode support in compliance with the XML 1.0 specification. Interfaces are provided to work with the most widely accepted interfaces defined by the XML community: SAX, the Simple API for XML (http://www.megginson.com/SAX/) and DOM, the Document Object Model Level 1 (http://www.w3.org/TR/REC-DOM-Level-1/). ------------------------------------------------------------------------ > Python 2 could be the first language with support for SAX and DOM in the > class libraries (though Java is catching fast) and the first to ship > Expat as a standard module (on some platforms, anyhow). If the feature An excellent point we'd do well to capitalize on -- a lot of people interested in using XML would switch from other langs for this reason, I suspect. > [1]http://www.python.org/pipermail/xml-sig/1999-October/003167.html > (to be fair, I don't know that the TCL stuff is vacuous, I just presume > that any "B2B integration server" is likely to be vacuous...) That's a reasonable presumption, but I wouldn't make large bets on it either. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From akuchlin at mems-exchange.org Thu Jul 6 18:12:31 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 6 Jul 2000 12:12:31 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.680.483792.544003@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Wed, Jul 05, 2000 at 11:53:12PM -0400 References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> <14692.680.483792.544003@cj42289-a.reston1.va.home.com> Message-ID: <20000706121231.A14042@kronos.cnri.reston.va.us> On Wed, Jul 05, 2000 at 11:53:12PM -0400, Fred L. Drake, Jr. wrote: >Barry A. Warsaw writes: > > Think of all the new features added in 1.5.2 (a /micro/ release for > > gawds' sake). In retrospect, that was nutty. > Are you saying we should re-label that 1.6? That may prove... >convenient. ;) I've been privately wondering about making a new tarball of 1.5.2 that simply adds the Lib/distutils/ subdirectory and installs it, so people who don't want to risk the jump to 2.0 can still get the nice Distutils features. The problem is that it would take substantial willpower to only make that change; the temptation would be great to fix just this one really annoying bug, oh, and this little feature wouldn't break anything, and ... --amk From esr at thyrsus.com Thu Jul 6 18:21:22 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 12:21:22 -0400 Subject: [Python-Dev] urllib.browse() issues Message-ID: <20000706122122.A25613@thyrsus.com> Having finally wrestled CVS into at least temporary submission, I'm in the process of generating a patch to add a browser-launcher function to the standard library. There are a couple of issues connected to this. One: location. I still think, after meditating on it, that urllib and not os is the right place for this. Yes, it launches a process -- but that's implementation. It's a way to fetch the contents of an URL. In the potential *user's* view of the Python library, it belongs with other ways to fetch URLs. Two: cross-platform capability is a Good Thing. I rummaged around after a half-forgotten bit of lore in my files and discovered an allegation that under Windows, os.system("start %s" % url) is supposed to launch your default browser on the specified URL. Now here's what I'd like to write: if os.environ.has_key("BROWSER"): _browsers = string.split(os.environ["BROWSER"], ":") elif os.name == 'posix': _browsers = ["mozilla %s &", "netscape -remote 'openURL(%s)'", "netscape %s &", "lynx %s &", "w3m %s &"] elif os.name == 'nt': _browsers = ["start %s"] def urlbrowse(url): """Launch a browser, in background, pointed at the given URL. Accept either a string or a parsed URL tuple. Interpret the BROWSER environment variable, if it exists, as a colon-separated list of browser commands to try. """ from urlparse import urlunparse if type(url) == (): url = urlunparse(url) for browser in _browsers: if iscommand(string.split(browser)[0]): if os.system((browser % url)) == 0: return 1 return 0 The missing piece of implementation is the function iscommand(). I know how to write this under Unix: def iscommand(cmd): return os.system('which 1>/dev/null 2>&1 ' + cmd) == 0 So my question is this: is there any analogous way to check for the existence of a command under Windows? If so... Three: I'd like to add a cross-platform iscommand() function to os. -- Eric S. Raymond There's a truism that the road to Hell is often paved with good intentions. The corollary is that evil is best known not by its motives but by its *methods*. From akuchlin at mems-exchange.org Thu Jul 6 18:13:42 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 6 Jul 2000 12:13:42 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14692.44332.771745.446084@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 12:00:44PM -0400 References: <14691.49563.78765.683762@beluga.mojam.com> <200007060042.TAA06919@cj20424-a.reston1.va.home.com> <3964A1DE.F0878306@prescod.net> <14692.44332.771745.446084@cj42289-a.reston1.va.home.com> Message-ID: <20000706121342.B14042@kronos.cnri.reston.va.us> >On Thu, Jul 06, 2000 at 12:00:44PM -0400, Fred L. Drake, Jr. wrote: > I've written a bit of text for Guido about this, but it's fairly >short. If you, Lars, Andrew or anyone else from the XML gang would >like to take a crack at it, here's what I've sent Guido: That looks fine for the README or Misc/NEWS file. I want to write a section of the "What's New" article that goes into greater detail, shows some simple examples of parsing things, etc., but haven't gotten around to it yet. --amk From mal at lemburg.com Thu Jul 6 18:17:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 18:17:26 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: <033c01bfe6ce$4dd63a80$f2a6b5d4@hagrid> <00c801bfe754$1a6f8ad0$0900a8c0@SPIFF> <14692.39091.731830.389350@cj42289-a.reston1.va.home.com> Message-ID: <3964B116.44E1606E@lemburg.com> "Fred L. Drake, Jr." wrote: > > Now, if we could do that for unicodedata and ucnhash, a lot more > people would be happy! > Marc-Andre, Bill: Would it be reasonable to have perfect_hash.py > actually compress the text strings used for the character names? > Since there's such a limited alphabet in use, something special > purpose would probably be easy and do a lot of good. When checking > the lookup, you could easily decode the string in the table to do the > comparison. I don't have the time to look into this, sorry. Other things are more important now, like changing the handling of the 's' and 't' parser markers for Unicode from UTF-8 to default encoding. This will complete the move from a fixed internal encoding to a locale dependent setting and should fix most problems people have noticed on their platforms. BTW, does the XML package already use the builtin Unicode support ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 6 18:28:12 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 18:28:12 +0200 Subject: [Python-Dev] Hash values and comparing objects Message-ID: <3964B39C.7E0CD312@lemburg.com> There currently is a problem with the Unicode objects which I'd like to resolve: Since Unicode object are comparable to strings, they should have the same hash value as their string correspondents (the 8-bit strings which compare equal -- this can depend on the default encoding which again depends on the locale setting). Previously, Unicode used UTF-8 as basis for calculating the hash value (the Unicode object created a UTF-8 string object and delegated the hash value calculation to it, caching the result and the string for future use). Since I would like to make the internal encoding cache use the default encoding instead, I have two problems to solve: 1. It is sometimes not possible to encode the Unicode value using the default encoding. A different strategy for calculating the hash value would have to be used. 2. In some locales '???' == u'???' is true, while in others this is not the case. If they do compare equal, the hash values must match. How serious is the need for objects which compare equal to have the same hash value ? (I would much prefer to calculate the hash value using the internal UTF-16 buffer rather than first creating an encoded string.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 6 18:33:55 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 18:33:55 +0200 Subject: [Python-Dev] urllib.browse() issues References: <20000706122122.A25613@thyrsus.com> Message-ID: <3964B4F3.5EE72F14@lemburg.com> "Eric S. Raymond" wrote: > > Having finally wrestled CVS into at least temporary submission, > I'm in the process of generating a patch to add a browser-launcher > function to the standard library. There are a couple of issues > connected to this. Eric, please have a look at Tools/idle/BrowserControl.py... it has all you need and can easily be extended to support more browsers. Might be a good candidate for the std lib if you ask me -- after a rename to say "browser.py". -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Thu Jul 6 18:51:51 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 12:51:51 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964B4F3.5EE72F14@lemburg.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> Message-ID: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Might be a good candidate for the std lib if you ask me -- > after a rename to say "browser.py". Agh! That was my original name for it! Guido wanted me to change it since that didn't describe it well (there's not a single browser implementation in there ;). browsercntl seems... ugly. I'd welcome suggestions for short, lower-case names, though. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jul 6 18:53:19 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 12:53:19 -0400 (EDT) Subject: [Python-Dev] forwarded message from noreply@sourceforge.net Message-ID: <14692.47487.15354.645423@cj42289-a.reston1.va.home.com> The bogus CVS lock in Modules/ is now fixed! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- An embedded message was scrubbed... From: noreply at sourceforge.net Subject: [ 103231 ] bogus directory lock Date: Thu, 6 Jul 2000 09:44:04 -0700 Size: 1840 URL: From ping at lfw.org Thu Jul 6 19:30:05 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 6 Jul 2000 10:30:05 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <20000705183353.B7564@ludwig.cnri.reston.va.us> Message-ID: On Wed, 5 Jul 2000, Greg Ward wrote: > > SyntaxError: expected indent > > SyntaxError: expected unindent The "expected indent" message seems a little abrupt to me (does it mean there's a problem because an indent is expected, or a problem with an indent that was expected, or a problem because an expected indent isn't there?) so i have changed it to SyntaxError: expected an indented block The latter case, "expected unindent", never occurs -- it is always okay to continue an indented block, so a DEDENT is never absolutely required. The rest of the messages now say "unindent" instead of "dedent". I've updated the patch. -- ?!ng "To be human is to continually change. Your desire to remain as you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From esr at thyrsus.com Thu Jul 6 19:39:57 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 13:39:57 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964B4F3.5EE72F14@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 06:33:55PM +0200 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> Message-ID: <20000706133957.C25726@thyrsus.com> M.-A. Lemburg : > "Eric S. Raymond" wrote: > > > > Having finally wrestled CVS into at least temporary submission, > > I'm in the process of generating a patch to add a browser-launcher > > function to the standard library. There are a couple of issues > > connected to this. > > Eric, please have a look at Tools/idle/BrowserControl.py... > it has all you need and can easily be extended to support > more browsers. It's kind of sideways to what I'm trying to accomplish in some ways -- but yes, I see some useful tricks in there. Perhapsa I'll try to clean this up into a browser.py. -- Eric S. Raymond The difference between death and taxes is death doesn't get worse every time Congress meets -- Will Rogers From mal at lemburg.com Thu Jul 6 19:37:31 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 19:37:31 +0200 Subject: [Python-Dev] urllib.browse() issues References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> Message-ID: <3964C3DB.B57E95F9@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > Might be a good candidate for the std lib if you ask me -- > > after a rename to say "browser.py". > > Agh! That was my original name for it! Guido wanted me to change > it since that didn't describe it well (there's not a single browser > implementation in there ;). Um, there's not a single OS implementation in os.py either ;-) I think it describes things well enough if you write browser.open('http://www.python.org/') Perhaps the interface should be a bit more RPC like, though... something like: b = browser.connect() b.open(http://www.python.org/') b.close() > browsercntl seems... ugly. I'd welcome suggestions for short, > lower-case names, though. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping at lfw.org Thu Jul 6 19:44:43 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 6 Jul 2000 10:44:43 -0700 (PDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> Message-ID: On Thu, 6 Jul 2000, Fred L. Drake, Jr. wrote: > browsercntl seems... ugly. I'd welcome suggestions for short, > lower-case names, though. browsing.py? -- ?!ng From esr at thyrsus.com Thu Jul 6 19:56:03 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 13:56:03 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: ; from ping@lfw.org on Thu, Jul 06, 2000 at 10:44:43AM -0700 References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> Message-ID: <20000706135603.A26040@thyrsus.com> Ka-Ping Yee : > On Thu, 6 Jul 2000, Fred L. Drake, Jr. wrote: > > browsercntl seems... ugly. I'd welcome suggestions for short, > > lower-case names, though. > > browsing.py? I like it. -- Eric S. Raymond "...The Bill of Rights is a literal and absolute document. The First Amendment doesn't say you have a right to speak out unless the government has a 'compelling interest' in censoring the Internet. The Second Amendment doesn't say you have the right to keep and bear arms until some madman plants a bomb. The Fourth Amendment doesn't say you have the right to be secure from search and seizure unless some FBI agent thinks you fit the profile of a terrorist. The government has no right to interfere with any of these freedoms under any circumstances." -- Harry Browne, 1996 USA presidential candidate, Libertarian Party From fdrake at beopen.com Thu Jul 6 19:58:00 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 13:58:00 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964C3DB.B57E95F9@lemburg.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> Message-ID: <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Um, there's not a single OS implementation in os.py either ;-) Good point; we should fix that. ;) > I think it describes things well enough if you write > > browser.open('http://www.python.org/') > > Perhaps the interface should be a bit more RPC like, though... > something like: > > b = browser.connect() > b.open(http://www.python.org/') > b.close() How about: b = browser.get() b.open("http://www.python.org/") That has the advantage of working with the existing code. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas at xs4all.net Thu Jul 6 20:09:24 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 6 Jul 2000 20:09:24 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 In-Reply-To: <20000706142731.K13478@xs4all.nl>; from thomas@xs4all.net on Thu, Jul 06, 2000 at 02:27:32PM +0200 References: <200007052256.PAA12103@slayer.i.sourceforge.net> <14691.65439.950090.60795@anthem.concentric.net> <20000706142731.K13478@xs4all.nl> Message-ID: <20000706200924.B26534@xs4all.nl> On Thu, Jul 06, 2000 at 02:27:32PM +0200, Thomas Wouters wrote: > PyObject_INIT((PyObject *)b, &PyBuffer_Type); > > The 'value computed' is useless. The value computed is computed by the ',' > operator, but the only things in there are sideffect operators. The last > operation in the string of ',''s is either a void-returning function or an > assignment, so I'd classify this one as a cosmetic bug in gcc ;) adding a > '(void)' cast to the PyObject_INIT() macro or the calls to it would fix the > warning. Er, ignore that. The value computed isn't useless, it's just the first argument. I overlooked that, sorry :P The return value is used in a couple of places. That leaves only one option to squench this warning, a (void) cast at the one spot that causes a warning. Or is there a better way ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Thu Jul 6 18:47:15 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 11:47:15 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc/templates module.tex,1.20,1.21 In-Reply-To: <200007061612.JAA11764@slayer.i.sourceforge.net> References: <200007061612.JAA11764@slayer.i.sourceforge.net> Message-ID: <14692.47123.218360.100174@beluga.mojam.com> Fred> *** 130,135 **** Fred> % detailed list of functions.) Fred> ! \subsection{Example} Fred> ! \nodename{Spam Example} Fred> The following example demonstrates how to open a can of spam using the Fred> --- 132,136 ---- Fred> % detailed list of functions.) Fred> ! \subsection{Example \label{spam-example}} Fred, I pulled the incorrect usage from libsocket.tex. Should all examples be changed to match? Skip From fdrake at beopen.com Thu Jul 6 20:25:52 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 14:25:52 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc/templates module.tex,1.20,1.21 In-Reply-To: <14692.47123.218360.100174@beluga.mojam.com> References: <200007061612.JAA11764@slayer.i.sourceforge.net> <14692.47123.218360.100174@beluga.mojam.com> Message-ID: <14692.53040.729280.724075@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > I pulled the incorrect usage from libsocket.tex. Should all examples be > changed to match? I'll go ahead and fix the socket documentation (I've made the changes already), but I wouldn't spend time looking for more instances. They can be fixed on an as-needed basis I think; there's enough real work to be done! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From moshez at math.huji.ac.il Thu Jul 6 20:42:40 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 6 Jul 2000 21:42:40 +0300 (IDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964B4F3.5EE72F14@lemburg.com> Message-ID: On Thu, 6 Jul 2000, M.-A. Lemburg wrote: > "Eric S. Raymond" wrote: > > > > Having finally wrestled CVS into at least temporary submission, > > I'm in the process of generating a patch to add a browser-launcher > > function to the standard library. There are a couple of issues > > connected to this. > > Eric, please have a look at Tools/idle/BrowserControl.py... > it has all you need and can easily be extended to support > more browsers. > > Might be a good candidate for the std lib if you ask me -- > after a rename to say "browser.py". It can easily be transformed into the standard library for free: just declare IDLE a standard library package. Even better would be to divorce all those parts of IDLE which are Tkinter independent and put those in a seperate package, whose name is TBD. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From mal at lemburg.com Thu Jul 6 20:58:45 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 20:58:45 +0200 Subject: [Python-Dev] urllib.browse() issues References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> Message-ID: <3964D6E5.536C0D93@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > Um, there's not a single OS implementation in os.py either ;-) > > Good point; we should fix that. ;) > > > I think it describes things well enough if you write > > > > browser.open('http://www.python.org/') > > > > Perhaps the interface should be a bit more RPC like, though... > > something like: > > > > b = browser.connect() > > b.open(http://www.python.org/') > > b.close() > > How about: > > b = browser.get() > b.open("http://www.python.org/") > > That has the advantage of working with the existing code. ;) Ok, fine with me. +1 for adding it to the standard lib from me. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From esr at thyrsus.com Thu Jul 6 21:44:34 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 15:44:34 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <3964D6E5.536C0D93@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 08:58:45PM +0200 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> Message-ID: <20000706154434.A26357@thyrsus.com> M.-A. Lemburg : > Ok, fine with me. > > +1 for adding it to the standard lib from me. Who's going to do the cut and fit? Me, or the IDLE maintainer? -- Eric S. Raymond Society in every state is a blessing, but government even in its best state is but a necessary evil; in its worst state an intolerable one; for when we suffer, or are exposed to the same miseries *by a government*, which we might expect in a country *without government*, our calamities is heightened by reflecting that we furnish the means by which we suffer." -- Thomas Paine From fdrake at beopen.com Thu Jul 6 21:41:08 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 15:41:08 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706154434.A26357@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> Message-ID: <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Who's going to do the cut and fit? Me, or the IDLE maintainer? If Guido doesn't object to moving this module, the task falls to me since I wrote it. Were there any requirements you had that the existing BrowserControl doesn't support? If so, please tell us from the requirements side. I'll write the documentation as well, if we move it. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Thu Jul 6 21:41:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 15:41:27 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: [moved from patches to Python-Dev] >> Patch #100745 has been updated. >> Visit SourceForge.net for more info. > http://sourceforge.net/patch/?func=detailpatch&patch_id=100745&group_id=5470 [Moshe] > -1: Since when have we stopped supporting machines without 4-byte integral > types? Or even non-standard 4 byte integral types? This looks extremely > dangerous. Indeed, Python *does* run on machines that don't have any 4-byte integral types -- or at least it used to . It doesn't run on any without an integral type *at least* 32-bits wide, though. Wouldn't the latter be good enough for this patch? That is, what's the requirement here for *exactly* 32 bits? BTW, a sane collection of typedefs would be another good candidate for pyport.h. From barry at scottb.demon.co.uk Thu Jul 6 21:58:22 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Thu, 6 Jul 2000 20:58:22 +0100 Subject: [Python-Dev] USE_STACKCHECK/PyOS_CheckStack In-Reply-To: Message-ID: <000001bfe784$89f69080$060210ac@private> > The effectiveness of this is dependent on guessing a good value (per > platform) for MAX_RECURSION_DEPTH (and it's broken under Windows in 1.5.2). For embedding Python into other apps you need to control the value of MAX_RECURSION_DEPTH at run time. I can then adjust the value to: * take account of my app's impact on the stack usage * limit the depth to get a faster failure from buggy .py modules * work around any bug that gets the value wrong Having a pair of functions to Set/Get the value would be very nice. BArry From esr at thyrsus.com Thu Jul 6 22:35:11 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 16:35:11 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.57556.241282.594629@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 03:41:08PM -0400 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> Message-ID: <20000706163511.A26475@thyrsus.com> Fred L. Drake, Jr. : > If Guido doesn't object to moving this module, the task falls to me > since I wrote it. Were there any requirements you had that the > existing BrowserControl doesn't support? If so, please tell us from > the requirements side. Frankly, what's there strikes me as overly complex and tied to the heavyweight IDLE environment. Here's the latest version of my code for comparison. Comment and critique follows. # Support for launching a browser _browsers = None def iscommand(cmd): # I'd still like to put a cross-platform version of this in the library if os.name == 'posix': return os.system('which 1>/dev/null 2>&1 ' + cmd) == 0 else: return 1 def urlbrowse(url): """Launch a browser, in background if possible, pointed at the given URL. Accept either a string or a parsed URL tuple. Interpret the BROWSER environment variable, if it exists, as a colon-separated list of browser commands to try. """ from urlparse import urlunparse if type(url) == (): url = urlunparse(url) global _browsers if os.environ.has_key("BROWSER"): _browsers = string.split(os.environ["BROWSER"], ":") elif os.name == 'posix': _browsers = ["mozilla %s &", "netscape -remote 'openURL(%s)'", "netscape %s &", "lynx %s", "w3m %s"] elif os.name == 'nt': _browsers = ['start %s'] for browser in _browsers: if _iscommand(string.split(browser)[0]): if os.system((browser % url)) == 0: return 1 return 0 One significant difference is that my code gets the user preference for a browser from an environment variable, rather than a profile. This is appropriate for a preference that will be shared across multiple applications, and follows the pattern of well-known Unix envirinment variables like EDITOR. Another difference is that my code tries harder to have smart default behavior. Notice the order of attempts -- X browsers are tried first in background, then character browsers in the foreground. This means you are more likely to get some reasonable behavior independent of whether the calling Python program is launched from within X, from an Xterm, or on an X-less console. The register() calls seem kind of overelaborate. Why not just update a global dictionary directly? Things I like about the IDLE code, on the other hand...the distinction between open() and open_new() methods is good. It's also clearly smarter about the actual mechanics of browser invocation. I think what I'd like to see is a merged version that starts with your class organization, discards the .ini profile cruft in favor of an environment-variable check, uses my logic for hunting up a browser, and uses your incantations for actually invoking the browser. -- Eric S. Raymond Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their consciences. -- C. S. Lewis From mal at lemburg.com Thu Jul 6 22:28:47 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 22:28:47 +0200 Subject: [Python-Dev] Collection of typedefs for integral types References: Message-ID: <3964EBFF.69202D79@lemburg.com> Tim Peters wrote: > > [moved from patches to Python-Dev] > > >> Patch #100745 has been updated. > >> Visit SourceForge.net for more info. > > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100745&group_id=5470 > > [Moshe] > > -1: Since when have we stopped supporting machines without 4-byte integral > > types? Or even non-standard 4 byte integral types? This looks extremely > > dangerous. > > Indeed, Python *does* run on machines that don't have any 4-byte integral > types -- or at least it used to . It doesn't run on any without an > integral type *at least* 32-bits wide, though. Wouldn't the latter be good > enough for this patch? That is, what's the requirement here for *exactly* > 32 bits? > > BTW, a sane collection of typedefs would be another good candidate for > pyport.h. Good idea. The only problem with typedefs is that they tend to cause conflicts when different definitions are encountered. We'd have to use e.g. Py_UINT4, Py_UINT2, etc... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Thu Jul 6 22:32:36 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 16:32:36 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <3964EBFF.69202D79@lemburg.com> References: <3964EBFF.69202D79@lemburg.com> Message-ID: <14692.60644.899402.407317@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > The only problem with typedefs is that they tend to cause conflicts > when different definitions are encountered. > We'd have to use e.g. Py_UINT4, Py_UINT2, etc... Yes, we'd have to have our own names (unfortunate, but only matters for API functions, not locals). How bad that is depends on what you call "sane". And I'm not going to predict Tim on this! ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Thu Jul 6 22:33:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 16:33:22 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: [moved from patches to python-dev] [Bill Tutt] > Code currently in unicodeobject.c needs to do 32-bit arithmetic in > order to work. Additionally, UCS-4 characters (aka UTF-16 surrogate > characters) require 32 bits to represent the true unicode code point of a > surrogate pair. But is the requirement really for *exactly* 32 bits, or for *at least* 32 bits? The problem isn't with feebler machines, it's with higher-end ones: on some Python platforms, even sizeof(short) == 8. As is, your patch will prevent Python from compiling on those. From tim_one at email.msn.com Thu Jul 6 22:42:14 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 16:42:14 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <3964EBFF.69202D79@lemburg.com> Message-ID: >> BTW, a sane collection of typedefs would be another good candidate for >> pyport.h. [M.-A. Lemburg] > Good idea. > > The only problem with typedefs is that they tend to cause conflicts > when different definitions are encountered. > We'd have to use e.g. Py_UINT4, Py_UINT2, etc... Yes, but that's a hell of a lot better than the path the patch in question started going down, w/ its Unicode-specific _PyUnicode_Int32 and (! probably a bug) _PyUNICODE_Int32. From esr at thyrsus.com Thu Jul 6 22:59:31 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 16:59:31 -0400 Subject: [Python-Dev] Dangling locks again Message-ID: <20000706165931.A26662@thyrsus.com> Grrrrr...I can't commit my test patch. Skip has a dangling lock on the Lib directory. -- Eric S. Raymond What, then is law [government]? It is the collective organization of the individual right to lawful defense." -- Frederic Bastiat, "The Law" From fdrake at beopen.com Thu Jul 6 22:51:15 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 16:51:15 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706163511.A26475@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> Message-ID: <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Frankly, what's there strikes me as overly complex and tied to the > heavyweight IDLE environment. Here's the latest version of my code Actually, the code didn't originate in IDLE, but it did originate in a GUI program (never tested on Windows, but it used GTK+, so it might have worked there). > One significant difference is that my code gets the user preference > for a browser from an environment variable, rather than a profile. > This is appropriate for a preference that will be shared across multiple > applications, and follows the pattern of well-known Unix envirinment > variables like EDITOR. Which is great for Unix users, but otherwise stinks. I wasn't real happy with the .ini file thing, but wanted a way to configure it independent of the hosting application. > Another difference is that my code tries harder to have smart default > behavior. Notice the order of attempts -- X browsers are tried first > in background, then character browsers in the foreground. This means > you are more likely to get some reasonable behavior independent of > whether the calling Python program is launched from within X, from an > Xterm, or on an X-less console. I agree that this is good; I'll try and incorporate this. It would require that open/open_new could block (consoles, etc.), but that would be apporopriate in those contexts. > The register() calls seem kind of overelaborate. Why not just > update a global dictionary directly? Perhaps that's the right way to do it, but I'm not completely convinced either. If a GUI library uses this to provide help, and an application like Grail uses that library, Grail should be able to register itself as a help viewer. The exact mechanics are certainly open to debate; I'm not terribly enamored of the machinery there now. > Things I like about the IDLE code, on the other hand...the > distinction between open() and open_new() methods is good. It's also > clearly smarter about the actual mechanics of browser invocation. And I'd like to be able to support several more browsers, especially on Windows. I have no idea how any of this should be done for MacOS machines, either, which should be supportable. > I think what I'd like to see is a merged version that starts with your > class organization, discards the .ini profile cruft in favor of an > environment-variable check, uses my logic for hunting up a browser, > and uses your incantations for actually invoking the browser. I'll see if I can throw something together later today, and send it to python-dev for comments before checking it in. I guess the documentation falls in the category of "Internet Protocols *and Support*"... I don't think it fits anywhere else! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From rassilon at list.org Thu Jul 6 22:53:47 2000 From: rassilon at list.org (Bill Tutt) Date: Thu, 6 Jul 2000 13:53:47 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Tim Peters wrote: > [moved from patches to python-dev] > > [Bill Tutt] > > Code currently in unicodeobject.c needs to do 32-bit arithmetic in > > order to work. Additionally, UCS-4 characters (aka UTF-16 surrogate > > characters) require 32 bits to represent the true unicode code point of a > > surrogate pair. > > But is the requirement really for *exactly* 32 bits, or for *at least* 32 > bits? The problem isn't with feebler machines, it's with higher-end ones: > on some Python platforms, even sizeof(short) == 8. As is, your patch will > prevent Python from compiling on those. Its definately for at least 32 bits. Having a 32 bit specific type lets me not worry about all the issues relating to: What happens if sizeof(int) | sizeof(long) > 32 bits and I failed to compensate for that somehow. Now, the code that I changed to use the typedef might not care about this, but other code using the typedef might. Just color me a paranoid SOB. :) I'd rather always have a 32 bit type for something I know will always require just 32 bits. Bill From tim_one at email.msn.com Thu Jul 6 22:50:50 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 16:50:50 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <14692.60644.899402.407317@cj42289-a.reston1.va.home.com> Message-ID: >> Py_UINT4, Py_UINT2, etc... [Fred Drake] > Yes, we'd have to have our own names (unfortunate, but only matters > for API functions, not locals). How bad that is depends on what you > call "sane". And I'm not going to predict Tim on this! ;) I'm in favor of (as Trent Mick once suggested) getting exactly as insane as C9X: they thought hard about this, and came up with a whole slew of new symbolic names for the roles integral types play. We make typedefs of the same names (well, for as many as we actually *need*) but with Py_ in front of them. In time, as C9X takes over the world, the platform-#ifdef infested section of pyport.h declaring them actually *shrinks*, as more & more platforms support typedef'ing to the std C9X-defined names. From guido at beopen.com Thu Jul 6 23:53:19 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 16:53:19 -0500 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Your message of "Thu, 06 Jul 2000 16:42:14 -0400." References: Message-ID: <200007062153.QAA01183@cj20424-a.reston1.va.home.com> > >> BTW, a sane collection of typedefs would be another good candidate for > >> pyport.h. > > [M.-A. Lemburg] > > Good idea. > > > > The only problem with typedefs is that they tend to cause conflicts > > when different definitions are encountered. > > We'd have to use e.g. Py_UINT4, Py_UINT2, etc... > > Yes, but that's a hell of a lot better than the path the patch in question > started going down, w/ its Unicode-specific _PyUnicode_Int32 and (! probably > a bug) _PyUNICODE_Int32. C already *has* a sane collection of typedefs: short, int, long, maybe combined with unsigned. Plus size_t and so on. There should be only relatively few places where these aren't sufficient: the most common case being when you need the smallest type that's at least 32 bits, which on some systems is spelled as long, on others as int. When you need exactly 32 bits, you're out of luck (e.g. on Crays, it seems, if Tim is right). So it would be better not to write code that depends on exactly 32 (or 16, or 64, or 27) bits. Places where you just *have* to have exactly 32 bits are rare -- perhaps the calculation of 32-bit checksums is commonly done this way, but even there I would expect that it's possible to write the code to be correct for larger int sizes as well. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From rassilon at list.org Thu Jul 6 22:57:10 2000 From: rassilon at list.org (Bill Tutt) Date: Thu, 6 Jul 2000 13:57:10 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Bill Tutt wrote: > > > Its definately for at least 32 bits. > Having a 32 bit specific type lets me not worry about all the issues > relating to: > What happens if sizeof(int) | sizeof(long) > 32 bits and I failed to > compensate for that somehow. > > Now, the code that I changed to use the typedef might not care about this, > but other code using the typedef might. Just color me a paranoid SOB. :) > I'd rather always have a 32 bit type for something I know will always > require just 32 bits. > In any event, having the typedef is still useful since it clarifies the meaning behind the code. Bill From fdrake at beopen.com Thu Jul 6 22:56:21 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 16:56:21 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: References: <14692.60644.899402.407317@cj42289-a.reston1.va.home.com> Message-ID: <14692.62069.784802.306695@cj42289-a.reston1.va.home.com> Tim Peters writes: > I'm in favor of (as Trent Mick once suggested) getting exactly as insane as > C9X: they thought hard about this, and came up with a whole slew of new > symbolic names for the roles integral types play. We make typedefs of the > same names (well, for as many as we actually *need*) but with Py_ in front > of them. In time, as C9X takes over the world, the platform-#ifdef infested > section of pyport.h declaring them actually *shrinks*, as more & more > platforms support typedef'ing to the std C9X-defined names. Hey, if you're happy with C9X, I am too. What I've read about it made me almost think C had a future. But I'd still rather hack in Python. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Thu Jul 6 23:57:09 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 16:57:09 -0500 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Your message of "Thu, 06 Jul 2000 16:50:50 -0400." References: Message-ID: <200007062157.QAA01227@cj20424-a.reston1.va.home.com> > I'm in favor of (as Trent Mick once suggested) getting exactly as insane as > C9X: they thought hard about this, and came up with a whole slew of new > symbolic names for the roles integral types play. We make typedefs of the > same names (well, for as many as we actually *need*) but with Py_ in front > of them. In time, as C9X takes over the world, the platform-#ifdef infested > section of pyport.h declaring them actually *shrinks*, as more & more > platforms support typedef'ing to the std C9X-defined names. Great idea. (Is a summary of these names online somewhere?) It's always good to reuse hard-won knowledge that someone else gathered. (Python is an example of this -- it encodes a lot of hard-won knowledge that I gathered, and more recently also that many other gathered. This rule is also self-referential.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From pingster at ilm.com Thu Jul 6 23:01:49 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 6 Jul 2000 14:01:49 -0700 (PDT) Subject: [Python-Dev] Hash values and comparing objects In-Reply-To: <3964B39C.7E0CD312@lemburg.com> Message-ID: On Thu, 6 Jul 2000, M.-A. Lemburg wrote: > Previously, Unicode used UTF-8 as basis for calculating the > hash value Right, and i was trying to suggest (in a previous message) that the hash value should be calculated from the actual Unicode character values themselves. Then for any case where it's possible for an 8-bit string to be == to a Unicode string, they will have the same hash. Doesn't this solve the problem? Have i misunderstood? > How serious is the need for objects which compare equal to > have the same hash value ? For basic, immutable types like strings -- quite serious indeed, i would imagine. > 2. In some locales '???' == u'???' is true, while in others this is > not the case. If they do compare equal, the hash values > must match. This sounds very bad. I thought we agreed that attempting to compare (or add) a Unicode string and an 8-bit string containing non-ASCII characters (as in your example) should raise an exception. Such an attempt constitutes an ambiguous request -- you haven't specified how to turn the 8-bit bytes into Unicode, and it's better to be explicit than to have the interpreter guess (and guess differently depending on the environment!!) -- ?!ng From tim_one at email.msn.com Thu Jul 6 23:02:38 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 17:02:38 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: [Bill Tutt] > Its definately for at least 32 bits. > Having a 32 bit specific type lets me not worry about all the issues > relating to: > What happens if sizeof(int) | sizeof(long) > 32 bits and I failed to > compensate for that somehow. Provided you're sticking to unsigned types, there should be few issues here: the behavior of C's unsigned ints is well-defined across platforms. > Now, the code that I changed to use the typedef might not care about this, > but other code using the typedef might. Just color me a paranoid SOB. :) > I'd rather always have a 32 bit type for something I know will always > require just 32 bits. Understood, but you can't have that, not in Python source. I'm -1 on the patch so long as it requires something that can't be had . From esr at thyrsus.com Thu Jul 6 23:16:08 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 17:16:08 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.61763.530974.492605@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 04:51:15PM -0400 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> Message-ID: <20000706171608.A26696@thyrsus.com> Fred L. Drake, Jr. : > > One significant difference is that my code gets the user preference > > for a browser from an environment variable, rather than a profile. > > This is appropriate for a preference that will be shared across multiple > > applications, and follows the pattern of well-known Unix envirinment > > variables like EDITOR. > > Which is great for Unix users, but otherwise stinks. I wasn't real > happy with the .ini file thing, but wanted a way to configure it > independent of the hosting application. Environment variables work for Windows users, too -- and I believe there's a functionally similar name/value pair facility available through system resource forks on the Mac. I really think a profile file is excessively heavyweight here. Environment variables or X resources are a better medium for this kind of shared preference. I've actually been seriously thinking, once this is in the Python library, of going to the Perl and Tcl people and giving them code that would make *their* standard libraries do the right thing with the BROWSER variable. It shouldn't only be portable across Python applications, but across scripting languages as well -- something that would be much harder to do with an .ini file. > And I'd like to be able to support several more browsers, especially > on Windows. I have no idea how any of this should be done for MacOS > machines, either, which should be supportable. I certainly agree with that goal. -- Eric S. Raymond Such are a well regulated militia, composed of the freeholders, citizen and husbandman, who take up arms to preserve their property, as individuals, and their rights as freemen. -- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" referred to in the Second Amendment to the Constitution. From fdrake at beopen.com Thu Jul 6 23:08:55 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:08:55 -0400 (EDT) Subject: [Python-Dev] C9X information Message-ID: <14692.62823.198578.969389@cj42289-a.reston1.va.home.com> http://lglwww.epfl.ch/~wolf/c/c9x_changes.html This contains a summary of changes. Of particular note regarding today's discussion is item #38. GCC (at least recent versions) include the required header. The types are actually defined in for GCC; take a look there for the actual type names. In my installation, it includes things like this: /* Exact integral types. */ /* Signed. */ /* There is some amount of overlap with as known by inet code */ #ifndef __int8_t_defined # define __int8_t_defined typedef signed char int8_t; typedef short int int16_t; typedef int int32_t; # if __WORDSIZE == 64 typedef long int int64_t; # else __extension__ typedef long long int int64_t; # endif #endif /* Unsigned. */ typedef unsigned char uint8_t; typedef unsigned short int uint16_t; typedef unsigned int uint32_t; #if __WORDSIZE == 64 typedef unsigned long int uint64_t; #else __extension__ typedef unsigned long long int uint64_t; #endif /* Small types. */ /* Signed. */ typedef signed char int_least8_t; typedef short int int_least16_t; typedef int int_least32_t; #if __WORDSIZE == 64 typedef long int int_least64_t; #else __extension__ typedef long long int int_least64_t; #endif /* Unsigned. */ typedef unsigned char uint_least8_t; typedef unsigned short int uint_least16_t; typedef unsigned int uint_least32_t; #if __WORDSIZE == 64 typedef unsigned long int uint_least64_t; #else __extension__ typedef unsigned long long int uint_least64_t; #endif /* Fast types. */ /* Signed. */ typedef signed char int_fast8_t; #if __WORDSIZE == 64 typedef long int int_fast16_t; typedef long int int_fast32_t; typedef long int int_fast64_t; #else typedef int int_fast16_t; typedef int int_fast32_t; __extension__ typedef long long int int_fast64_t; #endif /* Unsigned. */ typedef unsigned char uint_fast8_t; #if __WORDSIZE == 64 typedef unsigned long int uint_fast16_t; typedef unsigned long int uint_fast32_t; typedef unsigned long int uint_fast64_t; #else typedef unsigned int uint_fast16_t; typedef unsigned int uint_fast32_t; __extension__ typedef unsigned long long int uint_fast64_t; #endif -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From akuchlin at mems-exchange.org Thu Jul 6 23:11:59 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 6 Jul 2000 17:11:59 -0400 Subject: [Python-Dev] Adding poll() system call Message-ID: <20000706171159.A25398@kronos.cnri.reston.va.us> For work-related reasons I'm looking at Medusa, and noticed that someone in that community wrote a wrapper for the poll() system call: http://www.nightmare.com/medusa/pollmodule.c The Medusa Web page says: The latest version of asyncore.py includes support for this module. poll(2) is much like select(2), but uses an array of structures rather than a bitmap. A major design problem with select(2) is that an fd_set is usually of a fixed maximum size, on many operating systems the kernel needs to rebuilt to raise this limit; even on those that have dynamically adjustable limits, you still need to recompile your application (because FD_SETSIZE is a macro). I'd suggest adding poll() to 2.0, and will submit a patch if given the go-ahead. But where should it go? A whole module for it seems excessive; should it go in posixmodule, or maybe select? (I can't figure out the POSIX status of poll(), though the Open Group does have a man page for it: http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html). --amk From guido at beopen.com Fri Jul 7 00:04:25 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 17:04:25 -0500 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Your message of "Thu, 06 Jul 2000 13:57:10 MST." References: Message-ID: <200007062204.RAA01266@cj20424-a.reston1.va.home.com> > In any event, having the typedef is still useful since it clarifies the > meaning behind the code. Actually, the typedef doesn't clarify the "== 32" vs ">= 32" issue at all! Many people appear to be thinking that an uint32 is guaranteed to be exactly 32 bits while this is in fact not guaranteed if you want full portability. Sometimes there *is* no 32-bit data type. The native data types don't have this problem -- but they have other problems because there's no native data type guaranteed to be "the smalles type >= 32 bits". Let's wait for what C9X does here. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From rassilon at list.org Thu Jul 6 23:16:50 2000 From: rassilon at list.org (Bill Tutt) Date: Thu, 6 Jul 2000 14:16:50 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: <200007062204.RAA01266@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 6 Jul 2000, Guido van Rossum wrote: > > In any event, having the typedef is still useful since it clarifies the > > meaning behind the code. > How about this: /* * Use this typedef when you need to represent a UTF-16 surrogate pair * as single unsigned integer. */ #if SIZEOF_INT >= 4 typedef unsigned int Py_UCS4; #else #if SIZEOF_LONG >= 4 typedef unsigned long Py_UCS4; #else #error "can't find integral type that can contain 32 bits" #endif /* SIZEOF_LONG */ #endif /* SIZEOF_INT */ Bill From guido at beopen.com Fri Jul 7 00:16:54 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 17:16:54 -0500 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: Your message of "Thu, 06 Jul 2000 17:16:08 -0400." <20000706171608.A26696@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> Message-ID: <200007062216.RAA01333@cj20424-a.reston1.va.home.com> [ESR] > Environment variables work for Windows users, too -- and I believe > there's a functionally similar name/value pair facility available > through system resource forks on the Mac. I really think a profile > file is excessively heavyweight here. Environment variables or X > resources are a better medium for this kind of shared preference. > > I've actually been seriously thinking, once this is in the Python > library, of going to the Perl and Tcl people and giving them code that > would make *their* standard libraries do the right thing with the > BROWSER variable. It shouldn't only be portable across Python > applications, but across scripting languages as well -- something that > would be much harder to do with an .ini file. But on Windows, there is already a registry setting to choose the browser. No native Windows user (as opposed to transplanted Unix users like you & me :-) is going to understand why they have to set an environment variable (something they believe is old-fashioned and mostly needed for the obscure and -- in their eyes -- equally obscure "DOS box") to change a preference that the system already knows perfectly well. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From pingster at ilm.com Thu Jul 6 23:16:07 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 6 Jul 2000 14:16:07 -0700 (PDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <20000706171159.A25398@kronos.cnri.reston.va.us> Message-ID: On Thu, 6 Jul 2000, Andrew Kuchling wrote: > > I'd suggest adding poll() to 2.0, and will submit a patch if given the > go-ahead. But where should it go? A whole module for it seems > excessive; should it go in posixmodule, or maybe select? posix would make sense to me. Actually, is there any good reason why select isn't in posix also? -- ?!ng "There's no point in being grown up if you can't be childish sometimes." -- Dr. Who From fdrake at beopen.com Thu Jul 6 23:23:08 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:23:08 -0400 (EDT) Subject: [Python-Dev] Re: forwarded message from Eric S. Raymond In-Reply-To: <14692.62818.835847.439551@beluga.mojam.com> References: <14692.61900.716303.447956@cj42289-a.reston1.va.home.com> <14692.62818.835847.439551@beluga.mojam.com> Message-ID: <14692.63676.527282.630370@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > Eric, my apologies. It would be real nice if SF could/would list locks that > are older than a few seconds (minutes?) when browsing the CVS repository. I think this is a good idea! I just filed the following bug report/ feature request: http://sourceforge.net/bugs/?func=detailbug&bug_id=108997&group_id=1 Feel free to add a comments explaining why this would be such a good idea! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Fri Jul 7 00:25:46 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 17:25:46 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Thu, 06 Jul 2000 14:16:07 MST." References: Message-ID: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> > > I'd suggest adding poll() to 2.0, and will submit a patch if given the > > go-ahead. But where should it go? A whole module for it seems > > excessive; should it go in posixmodule, or maybe select? > > posix would make sense to me. Yes, definitely. (The posix module contains lots of non-Posix stuff -- it was a way of saying Unix without pronouncing it.) > Actually, is there any good reason why select isn't in posix also? Yes -- select also works on Windows and DOS. (Ditto for socket.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From akuchlin at mems-exchange.org Thu Jul 6 23:28:31 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 6 Jul 2000 17:28:31 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007062225.RAA01376@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 05:25:46PM -0500 References: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> Message-ID: <20000706172831.B25398@kronos.cnri.reston.va.us> On Thu, Jul 06, 2000 at 05:25:46PM -0500, Guido van Rossum wrote: >> Actually, is there any good reason why select isn't in posix also? >Yes -- select also works on Windows and DOS. (Ditto for socket.) I don't know if poll() is available on Windows; anyone got a clue? poll() for DOS is almost certainly out of the question, and who cares these days? --amk From gstein at lyra.org Thu Jul 6 23:31:13 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 14:31:13 -0700 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706122122.A25613@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 06, 2000 at 12:21:22PM -0400 References: <20000706122122.A25613@thyrsus.com> Message-ID: <20000706143113.I29590@lyra.org> On Thu, Jul 06, 2000 at 12:21:22PM -0400, Eric S. Raymond wrote: > Having finally wrestled CVS into at least temporary submission, Eric, For the record, can you state what was wrong and how you fixed it? If/when others run into the same problem, then it will be great to know. thx! -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Thu Jul 6 23:29:38 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:29:38 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062216.RAA01333@cj20424-a.reston1.va.home.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> Message-ID: <14692.64066.241359.276620@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > But on Windows, there is already a registry setting to choose the > browser. No native Windows user (as opposed to transplanted Unix > users like you & me :-) is going to understand why they have to set an > environment variable (something they believe is old-fashioned and Exactly. On Windows, the existing code does the right thing and uses the registry settings. Or rather, it uses the Windows calls that make use of the registry settings, just like if you double-click on an HTML file directly. Which doesn't mean that BROWSER is the wrong thing on Unix; I'll take that into consideration (which does *not* mean I'll agree! Haven't decided yet, but it has clear merit). If someone "native" in the MacOS world can describe the right thing there, or provide a patch, that would be wonderful! I know about Internet Config, I just don't know what to do with it. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jul 6 23:31:18 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:31:18 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> References: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> Message-ID: <14692.64166.938741.169194@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > Yes -- select also works on Windows and DOS. (Ditto for socket.) That doesn't answer the question. Why select.select() instead of os.select()? I've never understood that one myself. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Thu Jul 6 23:37:56 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 17:37:56 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <200007062153.QAA01183@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > C already *has* a sane collection of typedefs: short, int, long, maybe > combined with unsigned. Those aren't typedefs, they're types, and the direct use of them was the cause of almost all of Trent Mick's Win64 porting pains. The std makes very weak promises about the std integral types, and Python (like all other C code that uses them directly!) accumulated lots of unwarranted assumptions. Rather than fix this with sane typedefs, we're now getting increasing amounts of ugly and brittle #ifdef'ed code keying off preprocessor symbols (like SIZEOF_LONG etc). > Plus size_t and so on. Those are typedefs. C9X adds more of that ilk, like "integral type big enough to hold a casted pointer", which current C doesn't address at all beyond guaranteeing there's *some* (unnamed) suitable type (and the lack of a typedef for which in Python accounted for maybe half of Trent's patches). > There should be only relatively few places where these aren't > sufficient: the most common case being when you need the smallest type > that's at least 32 bits, which on some systems is spelled as long, on > others as int. Agreed, and that's specifically what this patch needs (provided Bill gets over his paranoia ). > When you need exactly 32 bits, you're out of luck (e.g. on Crays, it > seems, if Tim is right). That sizeof(short) == 8 is in part why Python's long ints are currently broken on the J90 (the other reason is that the J90 has the only compiler I know of that does not generate code to sign-extend right shifts of signed integral types). > So it would be better not to write code that depends on exactly 32 (or > 16, or 64, or 27) bits. Places where you just *have* to have exactly > 32 bits are rare -- perhaps the calculation of 32-bit checksums is > commonly done this way, but even there I would expect that it's > possible to write the code to be correct for larger int sizes as well. Absolutely: the new crc32 checksum in Python was written this way (to require ints at least 32 bits, but tolerate ints larger than that). It is not, however, good that the code *spells* that requirement "unsigned long"! As obscure as can be. My position remains the same: adopt the C9X names for as many of the new integral synonyms as we *need*, but stick "Py_" in front of them. the-committee-wasn't-just-jerking-off-the-last-10-years-ly y'rs - tim From fdrake at beopen.com Thu Jul 6 23:41:43 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 17:41:43 -0400 (EDT) Subject: [Python-Dev] forwarded message from noreply@sourceforge.net Message-ID: <14692.64791.704062.354485@cj42289-a.reston1.va.home.com> Skip, Looks like the bug manager works much like we wish the patch manager did! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- An embedded message was scrubbed... From: noreply at sourceforge.net Subject: [Bug #108997] CVS browsing should show old locks Date: Thu, 6 Jul 2000 14:34:48 -0700 Size: 1734 URL: From mal at lemburg.com Thu Jul 6 23:42:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 23:42:08 +0200 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode References: Message-ID: <3964FD30.BB0F14D1@lemburg.com> Bill Tutt wrote: > > On Thu, 6 Jul 2000, Guido van Rossum wrote: > > > > In any event, having the typedef is still useful since it clarifies the > > > meaning behind the code. > > > > How about this: > /* > * Use this typedef when you need to represent a UTF-16 surrogate pair > * as single unsigned integer. > */ > #if SIZEOF_INT >= 4 > typedef unsigned int Py_UCS4; > #else > #if SIZEOF_LONG >= 4 > typedef unsigned long Py_UCS4; > #else > #error "can't find integral type that can contain 32 bits" > #endif /* SIZEOF_LONG */ > #endif /* SIZEOF_INT */ I like the name... Py_UCS4 is indeed what we're talking about here. What I don't understand is why you raise a compile error; AFAIK, unsigned long is at least 32 bits on all platforms and that's what the Unicode implementation would need to support UCS4 -- more bits don't do any harm since the storage type is fixed at 16-bit UTF-16 values. Ideal would be combining the above with the C9X typedefs, e.g. typedef uint4_t Py_UCS4; -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Thu Jul 6 23:47:32 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 16:47:32 -0500 (CDT) Subject: [Python-Dev] Problems with 2.0b1 and GCC Message-ID: <14692.65140.525706.197488@beluga.mojam.com> I thought I had this fixed, but apparently not. On my Linux (Mandrake 6.1 with some stuff from 7.1), I'm getting the following traceback in certain situations when running an oldish version of Zope (2.0.0): (gdb) bt #0 0x400712e8 in sigsuspend () from /lib/libc.so.6 #1 0x401471a0 in __DTOR_END__ () from /lib/libc.so.6 Yesterday I removed pgcc and egcs (both were installed for some reason) and upgraded the compilation environment to the following: gcc-c++-2.95.2-7mdk gcc-cpp-2.95.2-7mdk binutils-2.9.5.0.31-1mdk glibc-devel-2.1.1-15mdk glibc-2.1.1-15mdk compat-glibc-5.3-2.0.7.5mdk gcc-2.95.2-7mdk (Am I missing an important package that needs updating in the list above?) I had noticed the same traceback in test_fork1.py after I removed pgcc and installed gcc 2.95 and friends, but before I realized I had egcs installed. Deleting egcs cured the problem in at least some situations, but apparently not all. Anybody seen this? I suspect it has something to do with threading (which Zope requires). My Python directory tree is up-to-date wrt the CVS repository and was configured as ./configure --with-threads --with-cycle-gc --prefix=/usr and compiled as make OPT=-g I will try turning off cycle-gc. Any other thoughts from the assembled compilation gurus? Thx, Skip From guido at beopen.com Fri Jul 7 00:54:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 17:54:36 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Thu, 06 Jul 2000 17:31:18 -0400." <14692.64166.938741.169194@cj42289-a.reston1.va.home.com> References: <200007062225.RAA01376@cj20424-a.reston1.va.home.com> <14692.64166.938741.169194@cj42289-a.reston1.va.home.com> Message-ID: <200007062254.RAA01617@cj20424-a.reston1.va.home.com> > That doesn't answer the question. Why select.select() instead of > os.select()? I've never understood that one myself. Different platform dependencies. The select module works on Windows, Mac and Unix. The posix module only runs on Unix and (under the name "nt", but using the same source file) on Win32. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gmcm at hypernet.com Thu Jul 6 23:55:20 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 6 Jul 2000 17:55:20 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> References: <20000706163511.A26475@thyrsus.com> Message-ID: <1249201972-6842244@hypernet.com> Fred L. Drake, Jr. wrote: > And I'd like to be able to support several more browsers, > especially > on Windows. That's what "start %s" % url does. The intent is the same as $EDITOR, though the mechanics make Rube Goldberg look boringly practical. - Gordon From mal at lemburg.com Thu Jul 6 23:53:59 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jul 2000 23:53:59 +0200 Subject: [Python-Dev] Hash values and comparing objects References: Message-ID: <3964FFF7.A2D8AFFF@lemburg.com> Ka-Ping Yee wrote: > > On Thu, 6 Jul 2000, M.-A. Lemburg wrote: > > Previously, Unicode used UTF-8 as basis for calculating the > > hash value > > Right, and i was trying to suggest (in a previous message) > that the hash value should be calculated from the actual > Unicode character values themselves. Then for any case where > it's possible for an 8-bit string to be == to a Unicode > string, they will have the same hash. Doesn't this solve the > problem? Have i misunderstood? Not really, since the default encoding doesn't necessarily need to have anything to do with a Unicode subset, e.g. take one of the many Windows code pages. > > How serious is the need for objects which compare equal to > > have the same hash value ? > > For basic, immutable types like strings -- quite serious indeed, > i would imagine. What I meant was: would it do much harm if hash(unicode)==hash(string) would only be guaranteed for ASCII only values -- even though unicode may compare equal to string. > > 2. In some locales '???' == u'???' is true, while in others this is > > not the case. If they do compare equal, the hash values > > must match. > > This sounds very bad. I thought we agreed that attempting to > compare (or add) a Unicode string and an 8-bit string containing > non-ASCII characters (as in your example) should raise an exception. Only if the default encoding is ASCII. If Python runs in a different locale environment that encoding can change, e.g. to Latin-1 or one of the available code pages (this is to enhance Python's compatibility with the underlying environment). > Such an attempt constitutes an ambiguous request -- you haven't > specified how to turn the 8-bit bytes into Unicode, and it's better > to be explicit than to have the interpreter guess (and guess > differently depending on the environment!!) The interpreter doesn't guess, it uses the locale setting as defined by the user. If the programmer wants to be sure about what encoding is actually used, he will have to be explicit about it. That's what I would recommend for most applications, BTW. The auto-conversion magic is mainly meant for simplifying intergration of Unicode into existing systems. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From esr at thyrsus.com Fri Jul 7 00:04:51 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 18:04:51 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062216.RAA01333@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 05:16:54PM -0500 References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> Message-ID: <20000706180451.D26696@thyrsus.com> Guido van Rossum : > But on Windows, there is already a registry setting to choose the > browser. No native Windows user (as opposed to transplanted Unix > users like you & me :-) is going to understand why they have to set an > environment variable (something they believe is old-fashioned and > mostly needed for the obscure and -- in their eyes -- equally obscure > "DOS box") to change a preference that the system already knows > perfectly well. In my design the environment variable is only there as an optional override. Most of the time, the smart defaults do the right thing. -- Eric S. Raymond The most foolish mistake we could possibly make would be to permit the conquered Eastern peoples to have arms. History teaches that all conquerors who have allowed their subject races to carry arms have prepared their own downfall by doing so. -- Hitler, April 11 1942, revealing the real agenda of "gun control" From skip at mojam.com Thu Jul 6 23:56:40 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 16:56:40 -0500 (CDT) Subject: [Python-Dev] Problems with 2.0b1 and GCC In-Reply-To: <14692.65140.525706.197488@beluga.mojam.com> References: <14692.65140.525706.197488@beluga.mojam.com> Message-ID: <14693.152.401254.99695@beluga.mojam.com> Skip> I will try turning off cycle-gc. Did not help. (Neil, you can go home if you like... ;-) *sigh* Skip From tim_one at email.msn.com Thu Jul 6 23:55:10 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 6 Jul 2000 17:55:10 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: [Bill Tutt] > How about this: > /* > * Use this typedef when you need to represent a UTF-16 surrogate pair > * as single unsigned integer. > */ > #if SIZEOF_INT >= 4 > typedef unsigned int Py_UCS4; > #else > #if SIZEOF_LONG >= 4 > typedef unsigned long Py_UCS4; > #else > #error "can't find integral type that can contain 32 bits" > #endif /* SIZEOF_LONG */ > #endif /* SIZEOF_INT */ Much better! In the future (when the infrastructure is in place), I expect we'll replace the #if stuff here with typedef Py_uint_least32_t UCS4; instead (where Py_uint_least32_t is defined in pyfort.h, and uint_least32_t is the C9X spelling of the true requirement). BTW, why not use #elif instead of nested #ifs? #elif is clearer and shorter. From gstein at lyra.org Fri Jul 7 00:00:42 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:00:42 -0700 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: <3964FD30.BB0F14D1@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 11:42:08PM +0200 References: <3964FD30.BB0F14D1@lemburg.com> Message-ID: <20000706150042.K29590@lyra.org> On Thu, Jul 06, 2000 at 11:42:08PM +0200, M.-A. Lemburg wrote: > Bill Tutt wrote: > > > > On Thu, 6 Jul 2000, Guido van Rossum wrote: > > > > > > In any event, having the typedef is still useful since it clarifies the > > > > meaning behind the code. > > > > > > > How about this: > > /* > > * Use this typedef when you need to represent a UTF-16 surrogate pair > > * as single unsigned integer. > > */ > > #if SIZEOF_INT >= 4 > > typedef unsigned int Py_UCS4; > > #else > > #if SIZEOF_LONG >= 4 > > typedef unsigned long Py_UCS4; > > #else > > #error "can't find integral type that can contain 32 bits" > > #endif /* SIZEOF_LONG */ > > #endif /* SIZEOF_INT */ > > I like the name... Py_UCS4 is indeed what we're talking about > here. > > What I don't understand is why you raise a compile error; AFAIK, > unsigned long is at least 32 bits on all platforms and that's > what the Unicode implementation would need to support UCS4 -- more > bits don't do any harm since the storage type is fixed at > 16-bit UTF-16 values. Agreed. Some logic is still desirable (picking "int" over "long" is goodness), but the error is not needed. Python simply does not work if a long is not at least 32 bits. Period. No reason for an error. > Ideal would be combining the above with the C9X typedefs, > e.g. typedef uint4_t Py_UCS4; Actually, uint_fast32_t Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Fri Jul 7 00:02:10 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:02:10 -0700 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: ; from tim_one@email.msn.com on Thu, Jul 06, 2000 at 05:37:56PM -0400 References: <200007062153.QAA01183@cj20424-a.reston1.va.home.com> Message-ID: <20000706150210.L29590@lyra.org> On Thu, Jul 06, 2000 at 05:37:56PM -0400, Tim Peters wrote: >... > My position remains the same: adopt the C9X names for as many of the new > integral synonyms as we *need*, but stick "Py_" in front of them. Why should we insert the Py_ prefix? We can just use autoconf to test for the types. If present, then we use them. If not, then we define our own replacements. I see no particular reason to complicate it with Py_. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Fri Jul 7 01:00:33 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 18:00:33 -0500 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: Your message of "Thu, 06 Jul 2000 18:04:51 -0400." <20000706180451.D26696@thyrsus.com> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> <20000706180451.D26696@thyrsus.com> Message-ID: <200007062300.SAA01689@cj20424-a.reston1.va.home.com> > In my design the environment variable is only there as an optional override. > Most of the time, the smart defaults do the right thing. Ah. I came in on the tail end of the discussion. This makes sense. BTW, Eric, do you happen to know the folks at SF who wrote the Patch Manager? I and some of the others here at PythonLabs would love to get together with them at the O'Reilly conference (if they are going there) or at some other time to discuss how to kmake the PM better. We've got a lot of experience now! (And obviously we also have some suggestions for the CVS feature regarding cleaning up of locks.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Fri Jul 7 00:01:28 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 18:01:28 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <1249201972-6842244@hypernet.com> References: <20000706163511.A26475@thyrsus.com> <1249201972-6842244@hypernet.com> Message-ID: <14693.440.602599.536953@cj42289-a.reston1.va.home.com> Gordon McMillan writes: > That's what "start %s" % url does. The intent is the same as > $EDITOR, though the mechanics make Rube Goldberg look > boringly practical. No, that supports "Whatever the user set as their default browser," and is the right default for Windows. It doesn't let me use a drop-down box in a GUI to say "This application should Opera for help, even though Navigator is the default." *That's* what I'd like to be able to do, because then there's a chance of being able to separate open() and open_new(). (And just 'cause I'm a little anal about allowing this kind of configurability that no more than one in a thousand will care about. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Fri Jul 7 01:03:42 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 18:03:42 -0500 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Your message of "Thu, 06 Jul 2000 15:02:10 MST." <20000706150210.L29590@lyra.org> References: <200007062153.QAA01183@cj20424-a.reston1.va.home.com> <20000706150210.L29590@lyra.org> Message-ID: <200007062303.SAA01719@cj20424-a.reston1.va.home.com> > Why should we insert the Py_ prefix? We can just use autoconf to test for > the types. If present, then we use them. If not, then we define our own > replacements. > > I see no particular reason to complicate it with Py_. Defensive coding. If the names are somehow present on the system but somehow not detected by configure, Python.h would run into trouble when it tries to define them when they are in fact already defined by some 3rd party extensiom module that includes the necessary magic to reveal the system definitinons for these names... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Fri Jul 7 00:04:07 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 7 Jul 2000 00:04:07 +0200 Subject: [Python-Dev] Grammar help. Message-ID: <20000707000407.E26534@xs4all.nl> Argh, my head hurts ! :P I need some help with the Python Grammar. Or rather, the Parser. I'm trying to add some new syntax to the current CVS snapshot, something Guido said he would like to see: built-in 'range'-like list creation, so that '[1:10]' is the same as 'range(1,10)'. The code isn't the problem, that's all done and it all works, but the problem is that it somehow broke normal list literals ! :-P Here's what I did. The current definition of 'atom' is: atom: '(' [testlist] ')' | '[' [testlist] ']' | << ... >> testlist: test (',' test)* [','] I tried adding it like this: atom: '(' [testlist] ')' | '[' [listmaker] ']' | << ... >> testlist: test (',' test)* [','] listmaker: testlist | rangemaker rangemaker: [test] ':' test And as I said, it works -- for the new syntax. But not for the old one. When I start the interpreter, here's what I see: XXX ambiguity! [snip] XXX ambiguity! 'import site' failed; traceback: File "./Lib/site.py", line 93 prefixes = [sys.prefix] ^ >>> [2:20] [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] >>> [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] File "", line 1 [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] ^ SyntaxError: invalid syntax So, for some reason it doesn't recognize the old list literals als valid syntax. And it probably has to do with ambiguity ;) But I can't, for the life of me, figure out what's so ambiguous about it. As far as I can tell, a bare 'test' can't be a ':', and 'rangemaker' always needs a ':'. Is this some kind of limitation in the Parser that I need to work around ? I tried reading the parser code, and I'm glad my head is reattached ;P Hints-greatly-appreciated-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Fri Jul 7 00:06:05 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 17:06:05 -0500 (CDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062300.SAA01689@cj20424-a.reston1.va.home.com> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> <20000706180451.D26696@thyrsus.com> <200007062300.SAA01689@cj20424-a.reston1.va.home.com> Message-ID: <14693.717.789360.222392@beluga.mojam.com> Guido> BTW, Eric, do you happen to know the folks at SF who wrote the Guido> Patch Manager? .... We've got a lot of experience now! Python was #19 on the top projects list a few days ago and is #14 now. Not bad at all for software rated as mature... (is that sort of like PG-13?) Skip From esr at thyrsus.com Fri Jul 7 00:15:57 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 18:15:57 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062300.SAA01689@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 06:00:33PM -0500 References: <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> <20000706180451.D26696@thyrsus.com> <200007062300.SAA01689@cj20424-a.reston1.va.home.com> Message-ID: <20000706181557.A26994@thyrsus.com> Guido van Rossum : > BTW, Eric, do you happen to know the folks at SF who wrote the Patch > Manager? I and some of the others here at PythonLabs would love to > get together with them at the O'Reilly conference (if they are going > there) or at some other time to discuss how to kmake the PM better. > We've got a lot of experience now! (And obviously we also have some > suggestions for the CVS feature regarding cleaning up of locks.) I don't know who they are, but I can find out. -- Eric S. Raymond Idealism is the noble toga that political gentlemen drape over their will to power. -- Aldous Huxley From gmcm at hypernet.com Fri Jul 7 00:11:46 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 6 Jul 2000 18:11:46 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.440.602599.536953@cj42289-a.reston1.va.home.com> References: <1249201972-6842244@hypernet.com> Message-ID: <1249200987-6901559@hypernet.com> Fred L. Drake, Jr. wrote: > > Gordon McMillan writes: > > That's what "start %s" % url does. The intent is the same as > > $EDITOR, though the mechanics make Rube Goldberg look > boringly > practical. > > No, that supports "Whatever the user set as their default > browser," > and is the right default for Windows. It doesn't let me use a > drop-down box in a GUI to say "This application should Opera for > help, even though Navigator is the default." *That's* what I'd > like to be able to do, because then there's a chance of being > able to separate open() and open_new(). (And just 'cause I'm a > little anal about allowing this kind of configurability that no > more than one in a thousand will care about. ;) No, Fred, you're not one in a thousand, you're *completely* unique. What 999/1000 Windows users will want is to have the help in a .chm. - Gordon From Vladimir.Marangozov at inrialpes.fr Fri Jul 7 00:18:02 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 7 Jul 2000 00:18:02 +0200 (CEST) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jul 06, 2000 12:51:51 PM Message-ID: <200007062218.AAA02492@python.inrialpes.fr> Fred L. Drake, Jr. wrote: > > [MAL] > > Might be a good candidate for the std lib if you ask me -- > > after a rename to say "browser.py". > > Agh! That was my original name for it! Guido wanted me to change > it since that didn't describe it well (there's not a single browser > implementation in there ;). It this is gonna be a standalone library module, and from what I've seen in this thread, I think that "browser.py" is too generic as a term. The module addresses web browsers (not text browsers, info browsers, file browsers...), so it would be nice to clarify this distinction unless the module is intended to supports any kind of browsers. Here are more options: webbrowser.py, wwwbrowser.py, webclient.py ... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From fdrake at beopen.com Fri Jul 7 00:15:53 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 18:15:53 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.717.789360.222392@beluga.mojam.com> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <200007062216.RAA01333@cj20424-a.reston1.va.home.com> <20000706180451.D26696@thyrsus.com> <200007062300.SAA01689@cj20424-a.reston1.va.home.com> <14693.717.789360.222392@beluga.mojam.com> Message-ID: <14693.1305.576040.512179@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > Python was #19 on the top projects list a few days ago and is #14 now. Not > bad at all for software rated as mature... (is that sort of like PG-13?) "Top projects" seems to be measured in downloads of released files; we're in the "Most active" list, and I'm not sure what those numbers represent... percentiles? (I.e., we've made more checkins than 99.36% of the projects at SF, using the number right now.) The "Most active ..." header should be a link to a explanation! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jul 7 00:21:37 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 18:21:37 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <200007062218.AAA02492@python.inrialpes.fr> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <200007062218.AAA02492@python.inrialpes.fr> Message-ID: <14693.1649.220462.187258@cj42289-a.reston1.va.home.com> Vladimir Marangozov writes: > Here are more options: webbrowser.py, wwwbrowser.py, webclient.py ... Excellent! I'll take "webbrowser.py". -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gward at mems-exchange.org Fri Jul 7 00:22:56 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 18:22:56 -0400 Subject: [Python-Dev] Grammar help. In-Reply-To: <20000707000407.E26534@xs4all.nl>; from thomas@xs4all.net on Fri, Jul 07, 2000 at 12:04:07AM +0200 References: <20000707000407.E26534@xs4all.nl> Message-ID: <20000706182256.A15938@ludwig.cnri.reston.va.us> On 07 July 2000, Thomas Wouters said: > Argh, my head hurts ! :P Yeah, but try writing your *own* parser-generator. >grin< > Here's what I did. The current definition of 'atom' is: > > atom: '(' [testlist] ')' | '[' [testlist] ']' | << ... >> > testlist: test (',' test)* [','] > > I tried adding it like this: > > atom: '(' [testlist] ')' | '[' [listmaker] ']' | << ... >> > testlist: test (',' test)* [','] > listmaker: testlist | rangemaker > rangemaker: [test] ':' test I think the problem is this: * one possible candidate for atom is: '[' listmaker * two candidates for listmaker: testlist or rangemaker * but both of these start with a test; the fact that one of them is optional is probably beside the point * the parser needs to see ',' or ':' to know if it's got a testlist or a rangemaker: but because a test could be any number of tokens, it would need infinite lookahead. (I think.) Since this is a recursive-descent parser, it is most likely LL(1) -- at most one token of lookahead. Not good enough. Another, entirely hypothetical way of looking at it (based on experience with a completely different recursive descent parser generator (PCCTS/ANTLR) and dim recollections of the Dragon Book): * parser sees a '[' token and enters the 'atom' state (ie. calls a subroutine 'atom()') * swallows the '[' and immediately enters 'listmaker' (no other option) * now it wants to enter either 'testlist' or 'rangemaker': but the FIRST(testlist) == FIRST(test) (testlist can only start with a test), and FIRST(rangemaker) == FIRST(test) + ':' (rangemaker can start with a test or the ':' token) * I suspect this is the ambiguity: overlap in the FIRST sets of testlist and rangemaker The fix? Hmmm, I dunno. Never hacked on the Python grammar myself, and it's been a while since I hacked seriously on any grammar. Maybe the people (person?) who really understands this stuff will have an idea... Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From fdrake at beopen.com Fri Jul 7 00:24:57 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 18:24:57 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <1249200987-6901559@hypernet.com> References: <1249201972-6842244@hypernet.com> <1249200987-6901559@hypernet.com> Message-ID: <14693.1849.276233.217728@cj42289-a.reston1.va.home.com> Gordon McMillan writes: > No, Fred, you're not one in a thousand, you're *completely* > unique. What 999/1000 Windows users will want is to have > the help in a .chm. Dabnarbit, those Windows users are gettin' smart again... I'll havta put a few in their place! Harrumph! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr at thyrsus.com Fri Jul 7 00:33:32 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 18:33:32 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.1649.220462.187258@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 06:21:37PM -0400 References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <200007062218.AAA02492@python.inrialpes.fr> <14693.1649.220462.187258@cj42289-a.reston1.va.home.com> Message-ID: <20000706183332.B27129@thyrsus.com> Fred L. Drake, Jr. : > > Vladimir Marangozov writes: > > Here are more options: webbrowser.py, wwwbrowser.py, webclient.py ... > > Excellent! I'll take "webbrowser.py". That works for me, too. -- Eric S. Raymond Live free or die; death is not the worst of evils. -- General George Stark. From gward at mems-exchange.org Fri Jul 7 00:38:10 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 18:38:10 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706163511.A26475@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 06, 2000 at 04:35:11PM -0400 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> Message-ID: <20000706183810.B15938@ludwig.cnri.reston.va.us> On 06 July 2000, Eric S. Raymond said: > def iscommand(cmd): > # I'd still like to put a cross-platform version of this in the library > if os.name == 'posix': > return os.system('which 1>/dev/null 2>&1 ' + cmd) == 0 > else: > return 1 Speaking of heavyweight, this strikes me as excessive: N * 2 fork/execs, each of which will scan PATH anew, just to determine if a command exists? (OK, only N if 'which' is a shell built-in.) Why not scan PATH once yourself if you really need to determine a priori which command will fail? Easy to do since this will only be done on Unix. Alternately: > def urlbrowse(url): [...] > for browser in _browsers: > if _iscommand(string.split(browser)[0]): > if os.system((browser % url)) == 0: > return 1 > return 0 Rearrange this loop so it tries os.system() on each one in turn, and completes (successfully) when it finds one that works. (think think think) Ooh, that may not work so well because of the need to background X browsers. Ick. One could dream up a wild scheme that forks and forks and does the backgrounding itself, but what the hell: we're launching a big fat hairy *web browser* here, what does it matter if a shell is involved to parse the "&"? Maybe iscommand() is useful after all; I still think it should do its own PATH-scanning, though. Also, the wild variability of "which" across platforms and shells makes me wonder if, somewhere out there, there isn't a "which" that fails to return true/false on success. (check check check). Yes, there is: with bash 2.0.3 on Solaris 2.6: $ if which ls 1>/dev/null 2>&1 ; then echo yes ; fi yes $ if which skdfhjkjahdfs 1>/dev/null 2>&1 ; then echo yes ; fi yes ... so much for trusting "which" (I never did, anyways). Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From bwarsaw at beopen.com Fri Jul 7 00:44:50 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 6 Jul 2000 18:44:50 -0400 (EDT) Subject: [Python-Dev] Dangling locks again References: <20000706165931.A26662@thyrsus.com> Message-ID: <14693.3042.926389.117529@anthem.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> Grrrrr...I can't commit my test patch. Skip has a dangling ESR> lock on the Lib directory. I already put in an SF request to get this cleaned. From gward at mems-exchange.org Fri Jul 7 00:47:18 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 6 Jul 2000 18:47:18 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000706121231.A14042@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Jul 06, 2000 at 12:12:31PM -0400 References: <14691.49563.78765.683762@beluga.mojam.com> <14691.51089.280721.161530@bitdiddle.concentric.net> <14692.304.49138.508128@anthem.concentric.net> <14692.680.483792.544003@cj42289-a.reston1.va.home.com> <20000706121231.A14042@kronos.cnri.reston.va.us> Message-ID: <20000706184718.C15938@ludwig.cnri.reston.va.us> On 06 July 2000, Andrew Kuchling said: > I've been privately wondering about making a new tarball of 1.5.2 that > simply adds the Lib/distutils/ subdirectory and installs it, so people > who don't want to risk the jump to 2.0 can still get the nice > Distutils features. The problem is that it would take substantial > willpower to only make that change; the temptation would be great to > fix just this one really annoying bug, oh, and this little feature > wouldn't break anything, and ... Gee, is it really that hard to install the Distutils into a 1.5.2 installation? I do it a couple times a week and it it usually works for me. ;-) Greg From gstein at lyra.org Fri Jul 7 00:49:57 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:49:57 -0700 Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: <200007061855.LAA05178@slayer.i.sourceforge.net>; from montanaro@users.sourceforge.net on Thu, Jul 06, 2000 at 11:55:14AM -0700 References: <200007061855.LAA05178@slayer.i.sourceforge.net> Message-ID: <20000706154956.U29590@lyra.org> On Thu, Jul 06, 2000 at 11:55:14AM -0700, Skip Montanaro wrote: >... > + /* Exported function to load a readline history file */ > + > + static PyObject * > + read_history_file(self, args) > + PyObject *self; > + PyObject *args; > + { > + char *s = NULL; > + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) This allows somebody to pass read_history_file(None). That doesn't feel right. I'd suggest using the 's' format code. (if they want the default, then pass nothing at all) >... > + static PyObject * > + write_history_file(self, args) > + PyObject *self; > + PyObject *args; > + { > + char *s = NULL; > + if (!PyArg_ParseTuple(args, "|z:write_history_file", &s)) > + return NULL; Same here. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Fri Jul 7 01:53:51 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 18:53:51 -0500 Subject: [Python-Dev] Grammar help. In-Reply-To: Your message of "Thu, 06 Jul 2000 18:22:56 -0400." <20000706182256.A15938@ludwig.cnri.reston.va.us> References: <20000707000407.E26534@xs4all.nl> <20000706182256.A15938@ludwig.cnri.reston.va.us> Message-ID: <200007062353.SAA01958@cj20424-a.reston1.va.home.com> > On 07 July 2000, Thomas Wouters said: > > Argh, my head hurts ! :P Greg Ward replies: > Yeah, but try writing your *own* parser-generator. >grin< > > > Here's what I did. The current definition of 'atom' is: > > > > atom: '(' [testlist] ')' | '[' [testlist] ']' | << ... >> > > testlist: test (',' test)* [','] > > > > I tried adding it like this: > > > > atom: '(' [testlist] ')' | '[' [listmaker] ']' | << ... >> > > testlist: test (',' test)* [','] > > listmaker: testlist | rangemaker > > rangemaker: [test] ':' test > > I think the problem is this: > * one possible candidate for atom is: '[' listmaker > * two candidates for listmaker: testlist or rangemaker > * but both of these start with a test; the fact that one of them > is optional is probably beside the point > * the parser needs to see ',' or ':' to know if it's got a > testlist or a rangemaker: but because a test could be any number > of tokens, it would need infinite lookahead. (I think.) Since > this is a recursive-descent parser, it is most likely LL(1) -- > at most one token of lookahead. Not good enough. > > Another, entirely hypothetical way of looking at it (based on experience > with a completely different recursive descent parser generator > (PCCTS/ANTLR) and dim recollections of the Dragon Book): > * parser sees a '[' token and enters the 'atom' state > (ie. calls a subroutine 'atom()') > * swallows the '[' and immediately enters 'listmaker' (no other option) > * now it wants to enter either 'testlist' or 'rangemaker': but the > FIRST(testlist) == FIRST(test) (testlist can only start with a > test), and FIRST(rangemaker) == FIRST(test) + ':' (rangemaker > can start with a test or the ':' token) > * I suspect this is the ambiguity: overlap in the FIRST sets of > testlist and rangemaker Greg's got it right. It's a recursive descent a.k.a. LL(1) parser. The solution? Try to rewrite the grammar to avoid the ambiguities. So we have [testlist | rangemaker] for listmaker, where testlist is test(','test)* and rangemaker is [test]':'[test]. (Note that you'll have to add [':'[test]] to support [lo:hi:step], but tht's not the problem here.) Rewrite this as listmaker: [rangetail | test((','test)* | rangetail)] rangetail: ':' [test] [':' [test]] Now the two alternatives have different FIRST sets. The disadvantage is that you have to change the code generator to work withthis mess -- that's why people like LALR(1) and other parsers. But LL(1) was all I could create myself (Python uses a homegrown parser generator). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein at lyra.org Fri Jul 7 00:57:32 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:57:32 -0700 Subject: [Python-Dev] internal value (was: Hash values and comparing objects) In-Reply-To: <3964B39C.7E0CD312@lemburg.com>; from mal@lemburg.com on Thu, Jul 06, 2000 at 06:28:12PM +0200 References: <3964B39C.7E0CD312@lemburg.com> Message-ID: <20000706155732.W29590@lyra.org> On Thu, Jul 06, 2000 at 06:28:12PM +0200, M.-A. Lemburg wrote: >... > Previously, Unicode used UTF-8 as basis for calculating the > hash value (the Unicode object created a UTF-8 string object > and delegated the hash value calculation to it, caching the > result and the string for future use). Since I would like > to make the internal encoding cache use the default encoding > instead, I have two problems to solve: Woah... are you saing that the "t#" marker could now return arbitrary encodings? That C code cannot depend on any particular encoding? Why? This is a pretty big semantic change. Cheers, -g -- Greg Stein, http://www.lyra.org/ From esr at thyrsus.com Fri Jul 7 01:04:10 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 19:04:10 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706183810.B15938@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Thu, Jul 06, 2000 at 06:38:10PM -0400 References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <20000706183810.B15938@ludwig.cnri.reston.va.us> Message-ID: <20000706190410.B27191@thyrsus.com> Greg Ward : > Ooh, that may not work so well because of the need to background X > browsers. Ick. Bingo. You got it. That code is a lot smarter than it looks... > One could dream up a wild scheme that forks and forks > and does the backgrounding itself, but what the hell: we're launching a > big fat hairy *web browser* here, what does it matter if a shell is > involved to parse the "&"? My thinking exactly. A couple extra parses and forks are nothing. > Also, the wild variability of "which" across platforms and shells makes > me wonder if, somewhere out there, there isn't a "which" that fails to > return true/false on success. (check check check). Yes, there is: with > bash 2.0.3 on Solaris 2.6: Ugh... -- Eric S. Raymond In recent years it has been suggested that the Second Amendment protects the "collective" right of states to maintain militias, while it does not protect the right of "the people" to keep and bear arms. If anyone entertained this notion in the period during which the Constitution and the Bill of Rights were debated and ratified, it remains one of the most closely guarded secrets of the eighteenth century, for no known writing surviving from the period between 1787 and 1791 states such a thesis. -- Stephen P. Halbrook, "That Every Man Be Armed", 1984 From gstein at lyra.org Fri Jul 7 00:59:40 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 15:59:40 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules pypcre.c,2.18,2.19 In-Reply-To: <20000706200924.B26534@xs4all.nl>; from thomas@xs4all.net on Thu, Jul 06, 2000 at 08:09:24PM +0200 References: <200007052256.PAA12103@slayer.i.sourceforge.net> <14691.65439.950090.60795@anthem.concentric.net> <20000706142731.K13478@xs4all.nl> <20000706200924.B26534@xs4all.nl> Message-ID: <20000706155940.X29590@lyra.org> On Thu, Jul 06, 2000 at 08:09:24PM +0200, Thomas Wouters wrote: > On Thu, Jul 06, 2000 at 02:27:32PM +0200, Thomas Wouters wrote: > > PyObject_INIT((PyObject *)b, &PyBuffer_Type); > > > > The 'value computed' is useless. The value computed is computed by the ',' > > operator, but the only things in there are sideffect operators. The last > > operation in the string of ',''s is either a void-returning function or an > > assignment, so I'd classify this one as a cosmetic bug in gcc ;) adding a > > '(void)' cast to the PyObject_INIT() macro or the calls to it would fix the > > warning. > > Er, ignore that. The value computed isn't useless, it's just the first > argument. I overlooked that, sorry :P The return value is used in a couple > of places. That leaves only one option to squench this warning, a (void) > cast at the one spot that causes a warning. Or is there a better way ? I would say: make PyObject_INIT() a void "function". Since it is just returning the first argument, then the code can just use that explicitly. Having a return value seems to indicate that what you pass and what comes back might actually change. Eek! Not true. If you don't want to make it a void function, then you'll need to add (void) casts to a few places. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Fri Jul 7 01:58:17 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 18:58:17 -0500 Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: Your message of "Thu, 06 Jul 2000 15:49:57 MST." <20000706154956.U29590@lyra.org> References: <200007061855.LAA05178@slayer.i.sourceforge.net> <20000706154956.U29590@lyra.org> Message-ID: <200007062358.SAA02001@cj20424-a.reston1.va.home.com> > On Thu, Jul 06, 2000 at 11:55:14AM -0700, Skip Montanaro wrote: > >... > > + /* Exported function to load a readline history file */ > > + > > + static PyObject * > > + read_history_file(self, args) > > + PyObject *self; > > + PyObject *args; > > + { > > + char *s = NULL; > > + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) > > This allows somebody to pass read_history_file(None). That doesn't feel > right. I'd suggest using the 's' format code. > > (if they want the default, then pass nothing at all) Hm, I actually like this style and would recommend it. There are often times where it's useful to pass an explicit parameter that says "use the default". For example when writing a Python wrapper: def my_read_hist(file=None): ...do-something... readline.read_history_file(file) ...do-something-else... With what you propose, you'd have to write def my_read_hist(file=None): ...do-something... if file is None: readline.read_history_file() else: readline.read_history_file(file) ...do-something-else... I don't see how forcing users to do that would be considered elegant. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein at lyra.org Fri Jul 7 01:05:40 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 6 Jul 2000 16:05:40 -0700 Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: <200007062358.SAA02001@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 06:58:17PM -0500 References: <200007061855.LAA05178@slayer.i.sourceforge.net> <20000706154956.U29590@lyra.org> <200007062358.SAA02001@cj20424-a.reston1.va.home.com> Message-ID: <20000706160540.Y29590@lyra.org> Good point! Ignore me, then :-) Cheers, -g On Thu, Jul 06, 2000 at 06:58:17PM -0500, Guido van Rossum wrote: > > On Thu, Jul 06, 2000 at 11:55:14AM -0700, Skip Montanaro wrote: > > >... > > > + /* Exported function to load a readline history file */ > > > + > > > + static PyObject * > > > + read_history_file(self, args) > > > + PyObject *self; > > > + PyObject *args; > > > + { > > > + char *s = NULL; > > > + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) > > > > This allows somebody to pass read_history_file(None). That doesn't feel > > right. I'd suggest using the 's' format code. > > > > (if they want the default, then pass nothing at all) > > Hm, I actually like this style and would recommend it. There are > often times where it's useful to pass an explicit parameter that says > "use the default". For example when writing a Python wrapper: > > def my_read_hist(file=None): > ...do-something... > readline.read_history_file(file) > ...do-something-else... > > With what you propose, you'd have to write > > def my_read_hist(file=None): > ...do-something... > if file is None: > readline.read_history_file() > else: > readline.read_history_file(file) > ...do-something-else... > > I don't see how forcing users to do that would be considered elegant. > > --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) -- Greg Stein, http://www.lyra.org/ From barry at scottb.demon.co.uk Fri Jul 7 00:58:17 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Thu, 6 Jul 2000 23:58:17 +0100 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe Message-ID: <000001bfe79d$ac720ae0$060210ac@private> os.popen fails to work if pythonw.exe is used to start python. This is true for 1.5.2 and 1.6a2. The root cause of the problem is in the Microsoft C RTL implementation of _popen(). _popen() will fail if there is not a valid file descriptor for stdin or stdout. The following replacement for WinMain.c works around the problem. I also ensure a valid descriptor for stderr for completeness. This was compiled and test under VC++ 6.0 SP3 on Windows 2000. BArry -------------------------------- WinMain.c ------------------------- /* Minimal main program -- everything is loaded from the library. */ #include #include "Python.h" #include #include extern int Py_Main(); int WINAPI WinMain( HINSTANCE hInstance, // handle to current instance HINSTANCE hPrevInstance, // handle to previous instance LPSTR lpCmdLine, // pointer to command line int nCmdShow // show state of window ) { /* * make sure that the C RTL has valid file descriptors for * stdin, stdout, stderr. Use the NUL device. * This allows popen to work under pythonw. * * When pythonw.exe starts the C RTL function _ioinit is called * first. WinMain is called later hence the need to check for * invalid handles. * * Note: FILE stdin, stdout, stderr do not use the file descriptors * setup here. They are already initialised before WinMain was called. */ int null_file; null_file = open( "NUL", _O_RDWR ); /* check for STDIN is invalid */ if( _get_osfhandle( 0 ) == -1 ) { dup2( null_file, 0 ); } /* check for STDOUT is invalid */ if( _get_osfhandle( 1 ) == -1 ) { dup2( null_file, 1 ); } /* check for STDERR is invalid */ if( _get_osfhandle( 2 ) == -1 ) { dup2( null_file, 2 ); } close( null_file ); return Py_Main(__argc, __argv); } From pingster at ilm.com Fri Jul 7 01:09:21 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 6 Jul 2000 16:09:21 -0700 (PDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007062254.RAA01617@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 6 Jul 2000, Guido van Rossum wrote: > > That doesn't answer the question. Why select.select() instead of > > os.select()? I've never understood that one myself. > > Different platform dependencies. The select module works on Windows, > Mac and Unix. The posix module only runs on Unix and (under the name > "nt", but using the same source file) on Win32. Okay, then can select() be exposed in the os module by the posix, nt, and mac modules? -- ?!ng From fdrake at beopen.com Fri Jul 7 01:16:05 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 19:16:05 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: References: <200007062254.RAA01617@cj20424-a.reston1.va.home.com> Message-ID: <14693.4917.776799.332729@cj42289-a.reston1.va.home.com> Ka-Ping Yee writes: > Okay, then can select() be exposed in the os module by the > posix, nt, and mac modules? I don't think changing the interface is reasonable. There's too much legacy, and it's not like any of this is broken. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From rassilon at list.org Fri Jul 7 01:28:02 2000 From: rassilon at list.org (Bill Tutt) Date: Thu, 6 Jul 2000 16:28:02 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: <3964FD30.BB0F14D1@lemburg.com> Message-ID: On Thu, 6 Jul 2000, M.-A. Lemburg wrote: > Bill Tutt wrote: > > > > On Thu, 6 Jul 2000, Guido van Rossum wrote: > > > > > > In any event, having the typedef is still useful since it clarifies the > > > > meaning behind the code. > > > > > > > How about this: > > /* > > * Use this typedef when you need to represent a UTF-16 surrogate pair > > * as single unsigned integer. > > */ > > #if SIZEOF_INT >= 4 > > typedef unsigned int Py_UCS4; > > #else > > #if SIZEOF_LONG >= 4 > > typedef unsigned long Py_UCS4; > > #else > > #error "can't find integral type that can contain 32 bits" > > #endif /* SIZEOF_LONG */ > > #endif /* SIZEOF_INT */ > > I like the name... Py_UCS4 is indeed what we're talking about > here. > > What I don't understand is why you raise a compile error; AFAIK, > unsigned long is at least 32 bits on all platforms and that's > what the Unicode implementation would need to support UCS4 -- more > bits don't do any harm since the storage type is fixed at > 16-bit UTF-16 values. > Loud and obnoxious failures are much better than silent, and hard to debug failures. :) If unsigned long is big enough on all of the platforms we care about, then they won't ever see the compile error. :) Bill From guido at beopen.com Fri Jul 7 03:06:03 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 06 Jul 2000 20:06:03 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Thu, 06 Jul 2000 16:09:21 MST." References: Message-ID: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> > On Thu, 6 Jul 2000, Guido van Rossum wrote: > > > That doesn't answer the question. Why select.select() instead of > > > os.select()? I've never understood that one myself. > > > > Different platform dependencies. The select module works on Windows, > > Mac and Unix. The posix module only runs on Unix and (under the name > > "nt", but using the same source file) on Win32. > > Okay, then can select() be exposed in the os module by the > posix, nt, and mac modules? What's the point? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From pingster at ilm.com Fri Jul 7 02:20:53 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 6 Jul 2000 17:20:53 -0700 (PDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 6 Jul 2000, Guido van Rossum wrote: > > Okay, then can select() be exposed in the os module by the > > posix, nt, and mac modules? > > What's the point? It's an operating system function, like all the others. select() belongs in os for the same reason that we don't import chdir, import wait, import fork, etc. etc. It's not an earth-shattering thing; i'm just pretty sure most people look for os.select() first and wonder why it's missing before discovering select.select(). -- ?!ng From klm at digicool.com Fri Jul 7 02:22:05 2000 From: klm at digicool.com (Ken Manheimer) Date: Thu, 6 Jul 2000 20:22:05 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Tim Peters wrote: > the-committee-wasn't-just-jerking-off-the-last-10-years-ly y'rs - > tim (The obvious question is, where they doing those other things at the same time, or during breaks?) Ken klm at digicool.com From fdrake at beopen.com Fri Jul 7 02:24:47 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 20:24:47 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: References: Message-ID: <14693.9039.56927.20039@cj42289-a.reston1.va.home.com> Ken Manheimer writes: > (The obvious question is, where they doing those other things at the same > time, or during breaks?) I'd rather not find out! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Vladimir.Marangozov at inrialpes.fr Fri Jul 7 02:34:09 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 7 Jul 2000 02:34:09 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Ka-Ping Yee" at Jul 05, 2000 12:20:41 PM Message-ID: <200007070034.CAA02914@python.inrialpes.fr> Ka-Ping Yee wrote: > > > [Ping] > > > 4. Added int *expected_ret argument to PyParser_AddToken; on > > > a syntax error, PyParser_AddToken (in parser.c) places the > > > expected token type (if any) into this output parameter. > > [me] > > I'd suggest passing a pointer to the perrdetail structure (to the > > whole error, that is), instead of a pointer to one of its fields. > [Ping] > I did consider that; the reason i eventually decided against it > is that munging perrdetail appears to be [parsetok.c] parsetok()'s > responsibility, not [parser.c] PyParser_AddToken()'s. The latter > doesn't mess with any of the other fields of perrdetail -- and it > returns an error code which becomes err_ret->error, so passing in > perrdetail gives PyParser_AddToken() two ways of returning the same > information. The redundancy and possible future confusion didn't > seem worth it. > > Another alternative is to change the return value so it *isn't* > an error code (only a success/fail flag) and then rely on the error > code in err_ret->error. I guess if you see a compelling reason for > this i don't mind doing it. But is there one? Okay. Since you've already altered the error list in errcode.h, I think that the best thing to do is to re-introduce E_INDENT but for the "missing indentation" case (reported to the user as "expected an indented block"), then return E_INDENT from AddToken() and revert back its signature. Thus all additional error cases you've detected so far would be handled fine in pythonrun.c. Does this sound good for you? I share most of your thoughts -- after another look at the updated patch, I don't think I like the augmented perrdetail and the redundant communication interface with PyParser_AddToken(). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From jeremy at beopen.com Fri Jul 7 03:05:23 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 6 Jul 2000 21:05:23 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706190410.B27191@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <20000706183810.B15938@ludwig.cnri.reston.va.us> <20000706190410.B27191@thyrsus.com> Message-ID: <14693.11475.243489.826433@bitdiddle.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> Greg Ward : >> Ooh, that may not work so well because of the need to background >> X browsers. Ick. ESR> Bingo. You got it. That code is a lot smarter than it ESR> looks... A comment is in order then. If the code is smarter than it looks, most people aren't going to think it looks very smart. Jeremy From fdrake at beopen.com Fri Jul 7 03:09:35 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 21:09:35 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706171608.A26696@thyrsus.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> Message-ID: <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > there's a functionally similar name/value pair facility available > through system resource forks on the Mac. I really think a profile > file is excessively heavyweight here. Environment variables or X I still haven't heard from any MacOS users what the "right" way to do this sort of thing is. Jack, Sjoerd, Just... are you listening? > I've actually been seriously thinking, once this is in the Python > library, of going to the Perl and Tcl people and giving them code that > would make *their* standard libraries do the right thing with the > BROWSER variable. It shouldn't only be portable across Python > applications, but across scripting languages as well -- something that > would be much harder to do with an .ini file. I don't buy that using a config file is harder for those languages, but I think providing similar functionality for all is a great idea. Ok, here's a version that keeps the idea of a register() function, but simplifies the machinery quite a bit. Instead of using a config file, the BROWSER environment variable is used. If not set, the default on Windows is to use the Windows default setting. On Unix, the default is Netscape if $DISPLAY is set, otherwise it's the "command line browser", which tries, in order: netscape, mosaic(!), lync, and w3m. I left out Mozilla since I couldn't get it to work at all last time I tried it (though I've had better results previously). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- A non-text attachment was scrubbed... Name: webbrowser.py Type: text/x-python Size: 4438 bytes Desc: web browser controller module URL: From fdrake at beopen.com Fri Jul 7 03:14:38 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 21:14:38 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> References: <20000706122122.A25613@thyrsus.com> <3964B4F3.5EE72F14@lemburg.com> <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> Message-ID: <14693.12030.937901.65835@cj42289-a.reston1.va.home.com> Fred L. Drake, Jr. writes: > lync, and w3m. I left out Mozilla since I couldn't get it to work at > all last time I tried it (though I've had better results previously). I just pulled downthe M16 release of Mozilla - again - and it still doesn't know how to run. I can cd to the installation directory and run it directly, but it just doesn't do the right thing for normal use -- type "mozilla" isn't enough. I'm actually pretty surprised no one has fixed that. Their wrapper shell scripts look pretty screwed up. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gmcm at hypernet.com Fri Jul 7 03:42:28 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 6 Jul 2000 21:42:28 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: References: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> Message-ID: <1249188344-7661966@hypernet.com> Ka-Ping Yee wrote: [wants select in os] > It's an operating system function, like all the others. > select() belongs in os for the same reason that we don't > import chdir, import wait, import fork, etc. etc. > > It's not an earth-shattering thing; i'm just pretty sure > most people look for os.select() first and wonder why it's > missing before discovering select.select(). Actually Windows users probably first look in socket, since it's a socket-only thing on Windows. - Gordon From jeremy at beopen.com Fri Jul 7 04:02:32 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 6 Jul 2000 22:02:32 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> References: <200007070106.UAA02151@cj20424-a.reston1.va.home.com> Message-ID: <14693.14904.827148.290679@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> Okay, then can select() be exposed in the os module by the posix, >> nt, and mac modules? GvR> What's the point? Exactly. I don't see much point to moving it. Jeremy From esr at thyrsus.com Fri Jul 7 04:20:45 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 6 Jul 2000 22:20:45 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <14693.11727.410675.928619@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jul 06, 2000 at 09:09:35PM -0400 References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> Message-ID: <20000706222045.C27688@thyrsus.com> Fred L. Drake, Jr. : > Ok, here's a version that keeps the idea of a register() function, > but simplifies the machinery quite a bit. Instead of using a config > file, the BROWSER environment variable is used. If not set, the > default on Windows is to use the Windows default setting. On Unix, > the default is Netscape if $DISPLAY is set, otherwise it's the > "command line browser", which tries, in order: netscape, mosaic(!), > lync, and w3m. I left out Mozilla since I couldn't get it to work at > all last time I tried it (though I've had better results previously). Looks pretty good...though I have to wonder how much point there is in Grail support at this point. Having something like this in the standard library will be a real boon for on-line documentation and Web-aware programs. (I got M16 to run without difficulty, BTW. I have not switched yet because the UI still has a lot of sharp edges.) -- Eric S. Raymond The world is filled with violence. Because criminals carry guns, we decent law-abiding citizens should also have guns. Otherwise they will win and the decent people will lose. -- James Earl Jones From rassilon at list.org Fri Jul 7 04:15:01 2000 From: rassilon at list.org (Bill Tutt) Date: Thu, 6 Jul 2000 19:15:01 -0700 (PDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Tim Peters wrote: > [Bill Tutt] > > How about this: > > /* > > * Use this typedef when you need to represent a UTF-16 surrogate pair > > * as single unsigned integer. > > */ > > #if SIZEOF_INT >= 4 > > typedef unsigned int Py_UCS4; > > #else > > #if SIZEOF_LONG >= 4 > > typedef unsigned long Py_UCS4; > > #else > > #error "can't find integral type that can contain 32 bits" > > #endif /* SIZEOF_LONG */ > > #endif /* SIZEOF_INT */ > > Much better! In the future (when the infrastructure is in place), I expect > we'll replace the #if stuff here with > > typedef Py_uint_least32_t UCS4; > > instead (where Py_uint_least32_t is defined in pyfort.h, and uint_least32_t > is the C9X spelling of the true requirement). > > BTW, why not use #elif instead of nested #ifs? #elif is clearer and > shorter. > I've updated both of these patches on SF. Comments welcome, Bill From skip at mojam.com Fri Jul 7 04:13:57 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 21:13:57 -0500 (CDT) Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: <20000706154956.U29590@lyra.org> References: <200007061855.LAA05178@slayer.i.sourceforge.net> <20000706154956.U29590@lyra.org> Message-ID: <14693.15589.244326.670660@beluga.mojam.com> Greg> On Thu, Jul 06, 2000 at 11:55:14AM -0700, Skip Montanaro wrote: >> ... >> + /* Exported function to load a readline history file */ >> + >> + static PyObject * >> + read_history_file(self, args) >> + PyObject *self; >> + PyObject *args; >> + { >> + char *s = NULL; >> + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) Greg> This allows somebody to pass read_history_file(None). That doesn't Greg> feel right. I'd suggest using the 's' format code. Thanks, I'll fix it tomorrow. I basically cloned read_init_file's code. That probably needs a tweak as well. Skip From skip at mojam.com Fri Jul 7 04:15:55 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 21:15:55 -0500 (CDT) Subject: [Python-Dev] 's' vs 'z' format (was: CVS: python/dist/src/Modules readline.c,2.18,2.19) In-Reply-To: <20000706160540.Y29590@lyra.org> References: <200007061855.LAA05178@slayer.i.sourceforge.net> <20000706154956.U29590@lyra.org> <200007062358.SAA02001@cj20424-a.reston1.va.home.com> <20000706160540.Y29590@lyra.org> Message-ID: <14693.15707.301363.371690@beluga.mojam.com> Greg> Good point! Greg> Ignore me, then :-) No problem... ;-) Skip From Vladimir.Marangozov at inrialpes.fr Fri Jul 7 04:38:48 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 7 Jul 2000 04:38:48 +0200 (CEST) Subject: [Python-Dev] list comprehensions again... In-Reply-To: from "Tim Peters" at Jul 05, 2000 11:51:53 PM Message-ID: <200007070238.EAA03292@python.inrialpes.fr> Tim Peters wrote: > > OK, I'll be serious this time: if "the next release" is next week, damn > straight I want to stick to the feature freeze. > > But if it becomes predictably delayed for months, sure, open the floodgates > again. All this sounds reasonable. > > Unfortunately, the stuff holding up the release isn't technical in nature, > so there's nothing most of us can do to affect the outcome either way. So? To be or not to be? Make up your mind guys and we'll follow . You're the ones who have the best approximation of the set of all possible predictions. At least it should be better than mine. Since the release schedule was already revisited a number of times, and since we're moving to a major 2.0 version, I'm inclined to think that it would be fine to: 1) delay the release for september, or have a long beta-cycle until then (most people are going to spend their vacation in august anyway a) we won't get a solid feedback during a short beta in august, b) people will be pleased to see the major release ready on their return 2) Try finalizing at best & ASAP (say, next week) the pending issues with the big chunks that are already in -- SRE and Unicode. 3) Consider for inclusion in 2.0 the features we _already_know_ for sure have been delayed for 2.1 (a.k.a. -- 1.7) due to lack of time. 4) Emphasize the "quantum leap" with the 2.0 release by underlining the XML stuff Paul talked about + the major features considered in 3) I believe that staying in an undetermined Z-state for more than a week without a set of clearly defined options is not really what we all want, but maybe you have some additional considerations that may explain the ongoing patience about this lag... back-to-the-future-ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From fdrake at beopen.com Fri Jul 7 04:37:31 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 22:37:31 -0400 (EDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000706222045.C27688@thyrsus.com> References: <14692.47399.468383.574690@cj42289-a.reston1.va.home.com> <3964C3DB.B57E95F9@lemburg.com> <14692.51368.914266.945297@cj42289-a.reston1.va.home.com> <3964D6E5.536C0D93@lemburg.com> <20000706154434.A26357@thyrsus.com> <14692.57556.241282.594629@cj42289-a.reston1.va.home.com> <20000706163511.A26475@thyrsus.com> <14692.61763.530974.492605@cj42289-a.reston1.va.home.com> <20000706171608.A26696@thyrsus.com> <14693.11727.410675.928619@cj42289-a.reston1.va.home.com> <20000706222045.C27688@thyrsus.com> Message-ID: <14693.17003.16089.319857@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Looks pretty good...though I have to wonder how much point there is in > Grail support at this point. Having something like this in the standard That was the first browser I supported! (Which might indicate the age of some of the code a bit. ;) On the other hand, I don't see any real reason to discard it. I wouldn't mind a class to support Mosaic's CCI control interface either. ;) > library will be a real boon for on-line documentation and Web-aware > programs. Right. I originally wrote this (for Grail & Netscape) for a bookmark handling tool I never finished; this was the start of the browser controller; each class was supposed to be, essentially, a device driver for a Web-display abstract device. > (I got M16 to run without difficulty, BTW. I have not switched yet > because the UI still has a lot of sharp edges.) Interesting. I just re-installed it as root on Mandrake 7.0, and get the following as Joe User with all the default installation settings: cj42289-a(~/projects/python); PATH=/usr/local/mozilla:$PATH mozilla /dist/bin/run-mozilla.sh ./mozilla-bin /usr/local/mozilla/mozilla: /dist/bin/run-mozilla.sh: No such file or directory [127] cj42289-a(~/projects/python); (The "127" was the exit code, thanks to a bashlet from Ken Manheimer.) M12 did much better at this stuff, though the browser itself seems to have improved. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Fri Jul 7 05:22:35 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 6 Jul 2000 22:22:35 -0500 (CDT) Subject: [Python-Dev] Re: [Patches] [Patch #100752] Make atoi work for negative bases, a useful generalization In-Reply-To: <200007070309.UAA12927@bush.i.sourceforge.net> References: <200007070309.UAA12927@bush.i.sourceforge.net> Message-ID: <14693.19707.553522.523595@beluga.mojam.com> Alex, I looked at your patch. Can you provide a little motivation for those of us who are base challenged? I've never even heard of negative bases. Thx, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From fdrake at beopen.com Fri Jul 7 05:40:33 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 6 Jul 2000 23:40:33 -0400 (EDT) Subject: [Python-Dev] webbrowser module Message-ID: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> Ok, I've checked in the documentation for the webbrowser documentation. The implementation can go in as soon as SF clears a bogus read lock (support request files 6.5 hours ago). Well, I said I knew about InternetConfig for MacOS, but I clearly hadn't read the documentation! Getting this module working on MacOS is a trivial matter, if the docs are to be believed. If someone with a Mac could test it with a script like: import webbrowser webbrowser.open("http://www.python.org/") and let me know what happens, I'd really appreciate it! I've attached the version with Mac support below. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- A non-text attachment was scrubbed... Name: webbrowser.py Type: text/x-python Size: 4880 bytes Desc: web browser controller module URL: From moshez at math.huji.ac.il Fri Jul 7 06:25:40 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 7 Jul 2000 07:25:40 +0300 (IDT) Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixes UTF-8 en/decode In-Reply-To: Message-ID: On Thu, 6 Jul 2000, Bill Tutt wrote: > How about this: > /* > * Use this typedef when you need to represent a UTF-16 surrogate pair > * as single unsigned integer. > */ > #if SIZEOF_INT >= 4 > typedef unsigned int Py_UCS4; > #else > #if SIZEOF_LONG >= 4 > typedef unsigned long Py_UCS4; > #else > #error "can't find integral type that can contain 32 bits" > #endif /* SIZEOF_LONG */ > #endif /* SIZEOF_INT */ +0 from me, except (and this is really a nit, since I don't know real machines like that) what if sizeof(long) == 2 and sizeof(long long) == 4? long long is "almost standard", and I'm sure a configure test could make sure it is really there, so you can add #else #if HAVE_LONG_LONG and SIZEOF_LONG_LONG >= 4 .... #endif -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From mal at lemburg.com Fri Jul 7 10:16:09 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 10:16:09 +0200 Subject: [Python-Dev] Re: internal value (was: Hash values and comparing objects) References: <3964B39C.7E0CD312@lemburg.com> <20000706155732.W29590@lyra.org> Message-ID: <396591C9.C3533427@lemburg.com> Greg Stein wrote: > > On Thu, Jul 06, 2000 at 06:28:12PM +0200, M.-A. Lemburg wrote: > >... > > Previously, Unicode used UTF-8 as basis for calculating the > > hash value (the Unicode object created a UTF-8 string object > > and delegated the hash value calculation to it, caching the > > result and the string for future use). Since I would like > > to make the internal encoding cache use the default encoding > > instead, I have two problems to solve: > > Woah... are you saing that the "t#" marker could now return arbitrary > encodings? That C code cannot depend on any particular encoding? Right. If C code needs a particular encoding other than the locale dependent default encoding, it'll have to use "es#". > Why? This is a pretty big semantic change. It completes the switch from the fixed UTF-8 encoding to the locale dependent default encoding which we decided on a couple of weeks ago. Note that this change will make enhance compatibility with existing C extensions since they will now get the encoding that is default for them anyway... well, at least they stand a good chance ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From sjoerd at oratrix.nl Fri Jul 7 11:03:39 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Fri, 07 Jul 2000 11:03:39 +0200 Subject: [Python-Dev] forwarded message from noreply@sourceforge.net In-Reply-To: Your message of Thu, 06 Jul 2000 12:53:19 -0400. <14692.47487.15354.645423@cj42289-a.reston1.va.home.com> References: <14692.47487.15354.645423@cj42289-a.reston1.va.home.com> Message-ID: <20000707090340.7D00931047C@bireme.oratrix.nl> On Thu, Jul 6 2000 "Fred L. Drake, Jr." wrote: > The bogus CVS lock in Modules/ is now fixed! That's very nice and much appreciated, but I had (and still have) a problem with a lock in Lib... -- Sjoerd Mullender From sjoerd at oratrix.nl Fri Jul 7 11:40:34 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Fri, 07 Jul 2000 11:40:34 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines Message-ID: <20000707094036.AA22C31047C@bireme.oratrix.nl> The new defines in Python.h for SUSv2 compatibility seriously hamper compilation on SGI IRIX. The problem is that defining _XOPEN_SOURCE causes a number of common but non-standard features to be removed. In particular, ctermid_r and altzone are no longer defined. The former causes a warning (assignment of int-returning function to char *), the latter causes an error (altzone not defined). Something needs to be done about this but I don't know what since I don't know why the defines were necessary. -- Sjoerd Mullender From fredrik at pythonware.com Fri Jul 7 11:58:31 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 11:58:31 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines References: <20000707094036.AA22C31047C@bireme.oratrix.nl> Message-ID: <018301bfe7f9$e85c9dc0$0900a8c0@SPIFF> sjoerd wrote: > The new defines in Python.h for SUSv2 compatibility seriously hamper > compilation on SGI IRIX. > Something needs to be done about this but I don't know what since I > don't know why the defines were necessary. It was an attempt to make sure certain features were correctly defined. Some platforms add more stuff when you define this one, but others obviously remove stuff... I suggest removing it for now (it solves problems on Linux, but causes problems on at least Irix and tru64), and adding SUSv2 compliance as a possible design goal for Py3K... I've attached a patch (for some reason, I cannot check things in from any of my work machines. sigh.) [fredrik at brain src]$ cvs diff -u Include/Python.h Index: Include/Python.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Include/Python.h,v retrieving revision 2.20 diff -u -r2.20 Python.h --- Include/Python.h 2000/07/05 08:53:18 2.20 +++ Include/Python.h 2000/07/07 09:55:53 @@ -12,14 +12,17 @@ redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES. ******************************************************************/ -/* Enable compiler features including SUSv2 compatibility; switching - on C lib defines doesn't work here, because the symbols haven't - necessarily been defined yet. */ +/* Enable compiler features; switching on C lib defines doesn't work + here, because the symbols haven't necessarily been defined yet. */ + #ifndef _GNU_SOURCE # define _GNU_SOURCE 1 #endif + +#if 0 /* not yet. breaks stuff on too many platforms */ #ifndef _XOPEN_SOURCE # define _XOPEN_SOURCE 500 +#endif #endif /* Include nearly all Python header files */ From tismer at appliedbiometrics.com Fri Jul 7 12:21:07 2000 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 07 Jul 2000 12:21:07 +0200 Subject: [Python-Dev] how do I release a cvs lock? References: <14692.36768.23073.781592@beluga.mojam.com> <200007061515.KAA13255@cj20424-a.reston1.va.home.com> <396498D7.97ABB543@appliedbiometrics.com> <200007061537.KAA13448@cj20424-a.reston1.va.home.com> Message-ID: <3965AF13.C595B561@appliedbiometrics.com> Guido van Rossum wrote: > > > Do we really want to live on with SourceForge(t) ? > > It seems to be pleasant for small projects, but > > maybe it would be more convenient to have a CVS > > that we control directly? > > The new starship is very powerful and could stand a couple of > > CVS repositories easily. > > > > While one might argue that this would give to much of Python > > to BeOpen (they got it already:), I think this could work > > smoothly. > > In my experience, maintaining the repository, with both anonymous and > privileged (commit) access, is a lot of work -- managing user accounts > for the privileged, keeping the machine up and running, etc. I'm > really quite happy with the level of support we get from SF. Sure, if you have many projects and many users. > In the long run, BeOpen might be interested in running this kind of > service for the Python and other communities; but for now, it would > just be a burden. I was thinking of creating this service on the starship machine, and just for the couple of projects that we need, without help from BeOpen. I could initiate such a service, since it was one of our goals when we have a more powerful machine, and now we have it. But without interest I can save the time. - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From jack at oratrix.nl Fri Jul 7 12:33:03 2000 From: jack at oratrix.nl (Jack Jansen) Date: Fri, 07 Jul 2000 12:33:03 +0200 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: Message by "Eric S. Raymond" , Thu, 6 Jul 2000 12:21:22 -0400 , <20000706122122.A25613@thyrsus.com> Message-ID: <20000707103308.8074FE2673@oratrix.oratrix.nl> I would suggest not putting it into urllib but in a "launch" module. First, the actual implementation is going to be completely different for the various platforms, so if you put it into urllib it'll probably have to happen with an intermedeate module anyway, and by putting it in a separate module it's probably easier to extend to to various other things you might want to launch (fileviewers, editors, etc). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack at oratrix.nl Fri Jul 7 12:46:56 2000 From: jack at oratrix.nl (Jack Jansen) Date: Fri, 07 Jul 2000 12:46:56 +0200 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: Message by "Eric S. Raymond" , Thu, 6 Jul 2000 17:16:08 -0400 , <20000706171608.A26696@thyrsus.com> Message-ID: <20000707104701.0D3EBE2673@oratrix.oratrix.nl> Recently, "Eric S. Raymond" said: > Environment variables work for Windows users, too -- and I believe > there's a functionally similar name/value pair facility available > through system resource forks on the Mac. I really think a profile > file is excessively heavyweight here. Environment variables or X > resources are a better medium for this kind of shared preference. On the Mac life is easy: Internet Config keeps all this knowledge (and much more) in a database, and Python has an interface to it. So the code is simply import ic ic_instance = ic.IC() ic_instance.launchurl(url) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From mal at lemburg.com Fri Jul 7 12:54:48 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 12:54:48 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines References: <20000707094036.AA22C31047C@bireme.oratrix.nl> Message-ID: <3965B6F8.72742A2E@lemburg.com> Sjoerd Mullender wrote: > > The new defines in Python.h for SUSv2 compatibility seriously hamper > compilation on SGI IRIX. > > The problem is that defining _XOPEN_SOURCE causes a number of common > but non-standard features to be removed. In particular, ctermid_r and > altzone are no longer defined. The former causes a warning > (assignment of int-returning function to char *), the latter causes an > error (altzone not defined). > Something needs to be done about this but I don't know what since I > don't know why the defines were necessary. I think Fredrik is right. I'll remove the _XOPEN_SOURCE for now, but leave the _GNU_SOURCE define in (on Linux, Python compiles just fine using _GNU_SOURCE). Perhaps you could figure out which defines are needed to reenable the missing APIs on IRIX when _XOPEN_SOURCE is defined... it would be helpful to help pin-point the weak spots w/r to SUSv2 compatibility. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Fri Jul 7 14:29:27 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 07:29:27 -0500 Subject: [Python-Dev] Toby Dickenson's Unicode experience Message-ID: <200007071229.HAA03626@cj20424-a.reston1.va.home.com> He's got a point... Maybe add ustr(x) with the semantics below? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------- Forwarded Message Date: Fri, 07 Jul 2000 10:53:39 +0100 From: Toby Dickenson To: I18n-sig at python.org Subject: [I18n-sig] Unicode experience I'm just nearing the end of getting Zope to play well with unicode data. Most of the changes involved replacing a call to str, in situations where either a unicode or narrow string would be acceptable. My best alternative is: def convert_to_something_stringlike(x): if type(x)==type(u''): return x else: return str(x) This seems like a fundamental operation - would it be worth having something similar in the standard library? Toby Dickenson tdickenson at geminidataloggers.com _______________________________________________ I18n-sig mailing list I18n-sig at python.org http://www.python.org/mailman/listinfo/i18n-sig ------- End of Forwarded Message From guido at beopen.com Fri Jul 7 14:44:03 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 07:44:03 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: Your message of "Fri, 07 Jul 2000 13:15:49 +0200." <3965BBE5.D67DD838@lemburg.com> References: <3965BBE5.D67DD838@lemburg.com> Message-ID: <200007071244.HAA03694@cj20424-a.reston1.va.home.com> > Toby Dickenson wrote: > > > > I'm just nearing the end of getting Zope to play well with unicode > > data. Most of the changes involved replacing a call to str, in > > situations where either a unicode or narrow string would be > > acceptable. > > > > My best alternative is: > > > > def convert_to_something_stringlike(x): > > if type(x)==type(u''): > > return x > > else: > > return str(x) > > > > This seems like a fundamental operation - would it be worth having > > something similar in the standard library? Marc-Andre Lemburg replied: > You mean: for Unicode return Unicode and for everything else > return strings ? > > It doesn't fit well with the builtins str() and unicode(). I'd > say, make this a userland helper. I think this would be helpful to have in the std library. Note that in JPython, you'd already use str() for this, and in Python 3000 this may also be the case. At some point in the design discussion for the current Unicode support we also thought that we wanted str() to do this (i.e. allow 8-bit and Unicode string returns), until we realized that there were too many places that would be very unhappy if str() returned a Unicode string! The problem is similar to a situation you have with numbers: sometimes you want a coercion that converts everything to float except it should leave complex numbers complex. In other words it coerces up to float but it never coerces down to float. Luckily you can write that as "x+0.0" while converts int and long to float with the same value while leaving complex alone. For strings there is no compact notation like "+0.0" if you want to convert to string or Unicode -- adding "" might work in Perl, but not in Python. I propose ustr(x) with the semantics given by Toby. Class support (an __ustr__ method, with fallbacks on __str__ and __unicode__) would also be handy. > BTW, could you elaborate a bit on your experience with adding > Unicode support to Zope ? Such a report would certainly make > a nice complement to the Unicode tutorial and help other > people adding Unicode support to their apps. Yes, that's what we need. Thanks to Toby for pioneering this! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Fri Jul 7 13:56:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 7 Jul 2000 13:56:41 +0200 Subject: [Python-Dev] _sre.c's compiled size Message-ID: <20000707135641.F26534@xs4all.nl> For the record ;) I've compiled _sre with -fno-inline, on a RH6.2 egcs-1.1.2 system, and I have to admit compilation is going a lot faster. About 1/10th of the time, compared to without -fno-inline, which means it's about 1/100th of the annoyance when compiling a lot ;-) Also, the resulting object file is only 71K, instead of 440K, on my machine. Overall speed of python, as measured by pybench, doesn't really change, but pybench does not measure regexp speed at all, and I don't have a suitable testpackage for that. I've attached a teensy patch that allows '-f' flags to be used in Setup files, to be able to easily switch between the two. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- *** src/Modules/makesetup Thu Jul 6 13:58:06 2000 --- src-rangemaker/Modules/makesetup Fri Jul 7 13:23:25 2000 *************** *** 140,146 **** srcs) srcs="$srcs $arg"; skip=; continue;; esac case $arg in ! -[IDUC]*) cpps="$cpps $arg";; -Xlinker) libs="$libs $arg"; skip=libs;; -rpath) libs="$libs $arg"; skip=libs;; -[A-Zl]*) libs="$libs $arg";; --- 140,146 ---- srcs) srcs="$srcs $arg"; skip=; continue;; esac case $arg in ! -[IDUCf]*) cpps="$cpps $arg";; -Xlinker) libs="$libs $arg"; skip=libs;; -rpath) libs="$libs $arg"; skip=libs;; -[A-Zl]*) libs="$libs $arg";; From sjoerd at oratrix.nl Fri Jul 7 14:01:48 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Fri, 07 Jul 2000 14:01:48 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines In-Reply-To: Your message of Fri, 07 Jul 2000 12:54:48 +0200. <3965B6F8.72742A2E@lemburg.com> References: <20000707094036.AA22C31047C@bireme.oratrix.nl> <3965B6F8.72742A2E@lemburg.com> Message-ID: <20000707120149.6B39631047C@bireme.oratrix.nl> On Fri, Jul 7 2000 "M.-A. Lemburg" wrote: > Perhaps you could figure out which defines are needed to > reenable the missing APIs on IRIX when _XOPEN_SOURCE is > defined... it would be helpful to help pin-point the > weak spots w/r to SUSv2 compatibility. It looks like there is no way of doing this. The relevant bits of code are: In time.h (as an example): #if _SGIAPI && _NO_ANSIMODE extern time_t altzone; #endif /* _SGIAPI */ So _SGIAPI and _NO_ANSIMODE should both be defined and != 0. The definition of _SGIAPI is #define _SGIAPI ((defined(_SGI_SOURCE) && \ _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5) || \ (_ANSIMODE && _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5)) So, if _NO_XOPEN5 is 0, _SGIAPI is 0. The definition of _NO_XOPEN5 is #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || \ (defined(_XOPEN_SOURCE) && \ (_XOPEN_SOURCE+0 < 500))) So _NO_XOPEN5 is 0 since _XOPEN_SOURCE is defined and >= 500. All of this on IRIX 6.5.2. I can't check other versions of IRIX. -- Sjoerd Mullender From thomas at xs4all.net Fri Jul 7 14:08:56 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 7 Jul 2000 14:08:56 +0200 Subject: [Python-Dev] Grammar help. In-Reply-To: <200007062353.SAA01958@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 06, 2000 at 06:53:51PM -0500 References: <20000707000407.E26534@xs4all.nl> <20000706182256.A15938@ludwig.cnri.reston.va.us> <200007062353.SAA01958@cj20424-a.reston1.va.home.com> Message-ID: <20000707140856.G26534@xs4all.nl> On Thu, Jul 06, 2000 at 06:53:51PM -0500, Guido van Rossum wrote: > Greg's got it right. It's a recursive descent a.k.a. LL(1) parser. > The solution? Try to rewrite the grammar to avoid the ambiguities. > So we have [testlist | rangemaker] for listmaker, where testlist is > test(','test)* and rangemaker is [test]':'[test]. (Note that you'll > have to add [':'[test]] to support [lo:hi:step], but tht's not the > problem here.) > listmaker: [rangetail | test((','test)* | rangetail)] > rangetail: ':' [test] [':' [test]] Right, that's what I realized, too, after Greg told me what the problem was :) I basically did this, though the first 'test' in rangetail isn't optional, and I don't think it would make sense to have the 2nd test optional relative to the colon. But if you insist, it's a 2-character change ;) > The disadvantage is that you have to change the code generator to work > withthis mess -- that's why people like LALR(1) and other parsers. > But LL(1) was all I could create myself (Python uses a homegrown > parser generator). Actually, it turned out not to be that much of a mess. There's one 'if' statement that might look a bit strange, but the rest is pretty straightforward. I've attached the patch, it works ;) but it isn't finished yet: I'll try to get rid of the code duplication, add some comments and submit one relative to the list comprehension patch, so that when that one goes in, this one can, too ;) Don't forget to re-make Grammar if you test this patch out. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- diff -crN --exclude=CVS src/Grammar/Grammar src-rangemaker/Grammar/Grammar *** src/Grammar/Grammar Tue Mar 28 18:49:00 2000 --- src-rangemaker/Grammar/Grammar Fri Jul 7 10:32:19 2000 *************** *** 74,80 **** term: factor (('*'|'/'|'%') factor)* factor: ('+'|'-'|'~') factor | power power: atom trailer* ('**' factor)* ! atom: '(' [testlist] ')' | '[' [testlist] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ lambdef: 'lambda' [varargslist] ':' test trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME subscriptlist: subscript (',' subscript)* [','] --- 74,80 ---- term: factor (('*'|'/'|'%') factor)* factor: ('+'|'-'|'~') factor | power power: atom trailer* ('**' factor)* ! atom: '(' [testlist] ')' | '[' [listmaker] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ lambdef: 'lambda' [varargslist] ':' test trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME subscriptlist: subscript (',' subscript)* [','] diff -crN --exclude=CVS src/Include/opcode.h src-rangemaker/Include/opcode.h *** src/Include/opcode.h Fri Jun 30 19:58:04 2000 --- src-rangemaker/Include/opcode.h Fri Jul 7 13:05:13 2000 *************** *** 67,73 **** #define RETURN_VALUE 83 #define EXEC_STMT 85 ! #define POP_BLOCK 87 #define END_FINALLY 88 #define BUILD_CLASS 89 --- 67,73 ---- #define RETURN_VALUE 83 #define EXEC_STMT 85 ! #define BUILD_RANGE 86 #define POP_BLOCK 87 #define END_FINALLY 88 #define BUILD_CLASS 89 diff -crN --exclude=CVS src/Python/ceval.c src-rangemaker/Python/ceval.c *** src/Python/ceval.c Fri Jun 30 19:58:05 2000 --- src-rangemaker/Python/ceval.c Fri Jul 7 13:05:40 2000 *************** *** 65,70 **** --- 65,71 ---- static PyObject *cmp_outcome Py_PROTO((int, PyObject *, PyObject *)); static int import_from Py_PROTO((PyObject *, PyObject *, PyObject *)); static PyObject *build_class Py_PROTO((PyObject *, PyObject *, PyObject *)); + static PyObject *build_range Py_PROTO((PyObject *, PyObject *, PyObject *)); static int exec_statement Py_PROTO((PyFrameObject *, PyObject *, PyObject *, PyObject *)); static PyObject *find_from_args Py_PROTO((PyFrameObject *, int)); *************** *** 1110,1115 **** --- 1111,1127 ---- Py_DECREF(w); break; + case BUILD_RANGE: + w = POP(); + v = POP(); + u = POP(); + x = build_range(u, v, w); + PUSH(x); + Py_DECREF(u); + Py_DECREF(v); + Py_DECREF(w); + break; + case POP_BLOCK: { PyTryBlock *b = PyFrame_BlockPop(f); *************** *** 2801,2806 **** --- 2813,2897 ---- } } return PyClass_New(bases, methods, name); + } + + /* Stolen from bltinmodule.c */ + static long + get_len_of_range(lo, hi, step) + long lo; + long hi; + long step; /* must be > 0 */ + { + /* ------------------------------------------------------------- + If lo >= hi, the range is empty. + Else if n values are in the range, the last one is + lo + (n-1)*step, which must be <= hi-1. Rearranging, + n <= (hi - lo - 1)/step + 1, so taking the floor of the RHS gives + the proper value. Since lo < hi in this case, hi-lo-1 >= 0, so + the RHS is non-negative and so truncation is the same as the + floor. Letting M be the largest positive long, the worst case + for the RHS numerator is hi=M, lo=-M-1, and then + hi-lo-1 = M-(-M-1)-1 = 2*M. Therefore unsigned long has enough + precision to compute the RHS exactly. + ---------------------------------------------------------------*/ + long n = 0; + if (lo < hi) { + unsigned long uhi = (unsigned long)hi; + unsigned long ulo = (unsigned long)lo; + unsigned long diff = uhi - ulo - 1; + n = (long)(diff / (unsigned long)step + 1); + } + return n; + } + + static PyObject * + build_range(starto, endo, stepo) + PyObject *starto; + PyObject *endo; + PyObject *stepo; + { + long ilow = 0, ihigh = 0, istep = 1; + long bign; + int i, n; + PyObject * v; + + ilow = PyInt_AsLong(starto); + if (ilow == -1 && PyErr_Occurred()) + return NULL; + ihigh = PyInt_AsLong(endo); + if (ihigh == -1 && PyErr_Occurred()) + return NULL; + istep = PyInt_AsLong(stepo); + if (istep == -1 && PyErr_Occurred()) + return NULL; + + if (istep == 0) { + PyErr_SetString(PyExc_ValueError, "zero step for builtin range"); + return NULL; + } + if (istep > 0) + bign = get_len_of_range(ilow, ihigh, istep); + else + bign = get_len_of_range(ihigh, ilow, -istep); + n = (int)bign; + if (bign < 0 || (long)n != bign) { + PyErr_SetString(PyExc_OverflowError, + "too many items in builin range"); + return NULL; + } + v = PyList_New(n); + if (v == NULL) + return NULL; + for (i = 0; i < n; i++) { + PyObject *w = PyInt_FromLong(ilow); + if (w == NULL) { + Py_DECREF(v); + return NULL; + } + PyList_SET_ITEM(v, i, w); + ilow += istep; + } + return v; } static int diff -crN --exclude=CVS src/Python/compile.c src-rangemaker/Python/compile.c *** src/Python/compile.c Mon Jul 3 17:39:47 2000 --- src-rangemaker/Python/compile.c Fri Jul 7 13:05:41 2000 *************** *** 1018,1026 **** { int len; int i; ! if (TYPE(n) != testlist) ! REQ(n, exprlist); ! /* exprlist: expr (',' expr)* [',']; likewise for testlist */ len = (NCH(n) + 1) / 2; for (i = 0; i < NCH(n); i += 2) com_node(c, CHILD(n, i)); --- 1018,1025 ---- { int len; int i; ! REQ(n, listmaker); ! /* listmaker: test (',' test)* [',']; rangetail ommited */ len = (NCH(n) + 1) / 2; for (i = 0; i < NCH(n); i += 2) com_node(c, CHILD(n, i)); *************** *** 1029,1034 **** --- 1028,1081 ---- } static void + com_rangetail(c, n) + struct compiling *c; + node *n; + { + REQ(n, rangetail); + com_node(c, CHILD(n, 1)); + if (NCH(n) > 3) { + com_node(c, CHILD(n, 3)); + } else { + PyObject *v = PyInt_FromLong(1L); + if (!v) + c->c_errors++; + com_addoparg(c, LOAD_CONST, com_addconst(c, v)); + com_push(c, 1); + Py_XDECREF(v); + } + com_addbyte(c, BUILD_RANGE); + com_pop(c, 3); + } + + static void + com_listmaker(c, n) + struct compiling *c; + node *n; + { + if (TYPE(CHILD(n, 0)) != rangetail && (NCH(n) == 1 || + TYPE(CHILD(n, 1)) != rangetail)) { + /* '[' test (',' test)* [','] ']' */ + com_list_constructor(c, n); + return; + } + if (NCH(n) == 1) { + /* '[' rangetail ']' */ + PyObject *v = PyInt_FromLong(0L); + if (!v) + c->c_errors++; + com_addoparg(c, LOAD_CONST, com_addconst(c, v)); + com_push(c, 1); + Py_XDECREF(v); + com_rangetail(c, CHILD(n, 0)); + } else { + com_node(c, CHILD(n, 0)); + com_rangetail(c, CHILD(n, 1)); + } + } + + + static void com_dictmaker(c, n) struct compiling *c; node *n; *************** *** 1073,1079 **** com_push(c, 1); } else ! com_list_constructor(c, CHILD(n, 1)); break; case LBRACE: /* '{' [dictmaker] '}' */ com_addoparg(c, BUILD_MAP, 0); --- 1120,1126 ---- com_push(c, 1); } else ! com_listmaker(c, CHILD(n, 1)); break; case LBRACE: /* '{' [dictmaker] '}' */ com_addoparg(c, BUILD_MAP, 0); From fredrik at pythonware.com Fri Jul 7 14:30:51 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 14:30:51 +0200 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> Message-ID: <020001bfe80f$3b23ab10$0900a8c0@SPIFF> guido wrote: > I propose ustr(x) with the semantics given by Toby. +1 on concept. not sure about the name and the semantics. maybe a better name would be "unistr" (to match "unistr"). or maybe that's backwards? how about "String" (!). (the perfect name is "string", but that appears to be reserved by someone else...) as for the semantics, note that __str__ is allowed to return a unicode string in the current code base ("str" converts it to 8- bit using the default encoding). ustr/unistr/String should pass that one right through: def ustr(s): if type(s) in (type(""), type(u"")): return s s = s.__str__() if type(s) in (type(""), type(u"")): return s raise "__str__ returned wrong type" > Class support (an __ustr__ method, with fallbacks on __str__ > and __unicode__) would also be handy. -0 on this one (__str__ can already return either type, and if the goal is to get rid of both unichr and unistr in the future, we shouldn't add more hooks if we can avoid it. it's easier to remove stuff if you don't add them in the first place ;-) From thomas at xs4all.net Fri Jul 7 14:31:30 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 7 Jul 2000 14:31:30 +0200 Subject: [Python-Dev] Grammar help. In-Reply-To: <20000707140856.G26534@xs4all.nl>; from thomas@xs4all.net on Fri, Jul 07, 2000 at 02:08:56PM +0200 References: <20000707000407.E26534@xs4all.nl> <20000706182256.A15938@ludwig.cnri.reston.va.us> <200007062353.SAA01958@cj20424-a.reston1.va.home.com> <20000707140856.G26534@xs4all.nl> Message-ID: <20000707143130.H26534@xs4all.nl> On Fri, Jul 07, 2000 at 02:08:56PM +0200, Thomas Wouters wrote: > Don't forget to re-make Grammar if you test this patch out. Hm, something went wrong with the diff. Damned context diffs ;) > diff -crN --exclude=CVS src/Grammar/Grammar src-rangemaker/Grammar/Grammar > *** src/Grammar/Grammar Tue Mar 28 18:49:00 2000 > --- src-rangemaker/Grammar/Grammar Fri Jul 7 10:32:19 2000 > *************** > *** 74,80 **** > term: factor (('*'|'/'|'%') factor)* > factor: ('+'|'-'|'~') factor | power > power: atom trailer* ('**' factor)* > ! atom: '(' [testlist] ')' | '[' [testlist] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ > lambdef: 'lambda' [varargslist] ':' test > trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME > subscriptlist: subscript (',' subscript)* [','] > --- 74,80 ---- > term: factor (('*'|'/'|'%') factor)* > factor: ('+'|'-'|'~') factor | power > power: atom trailer* ('**' factor)* > ! atom: '(' [testlist] ')' | '[' [listmaker] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ > lambdef: 'lambda' [varargslist] ':' test > trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME > subscriptlist: subscript (',' subscript)* [','] If you want to try this patch out, you should add listmaker: rangetail | test ( rangetail | (',' test)* [',']) rangetail: ':' test [':' test] somewhere in Grammar/Grammar. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From pf at artcom-gmbh.de Fri Jul 7 14:26:38 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Fri, 7 Jul 2000 14:26:38 +0200 (MEST) Subject: [Python-Dev] webbrowser module In-Reply-To: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at "Jul 6, 2000 11:40:33 pm" Message-ID: Hi, Fred L. Drake, Jr.: > Ok, I've checked in the documentation for the webbrowser > documentation. The implementation can go in as soon as SF clears a > bogus read lock (support request files 6.5 hours ago). [...] May I suggest the patch below? It add's support for the Linux KDE file manager KFM (aka Konquerer) as the default web browser. This esspecially makes sense on smaller Linux machines, where users don't want to spend the huge amount of memory needed by a browser bloated to no avail with trashy stuff like Java / Javascript .... Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) ---- 8< ---- 8< ---- cut here ---- 8< ---- schnipp ---- 8< ---- schnapp ---- *** webbrowser.py.orig Fri Jul 7 10:28:05 2000 --- webbrowser.py Fri Jul 7 14:08:32 2000 *************** *** 1,4 **** ! """Remote-control interfaces to some browsers.""" import os import sys --- 1,4 ---- ! """webbrowser -- Remote-control interfaces to some browsers.""" import os import sys *************** *** 30,35 **** --- 30,36 ---- L[1] = L[0]() return L[1] + # Please note: the following definition hides a builtin function. def open(url, new=0): get().open(url, new) *************** *** 56,61 **** --- 57,63 ---- if os.environ.get("DISPLAY"): _browsers.extend([ ("netscape", "netscape %s >/dev/null &"), + ("kfmclient", "kfmclient openURL %s"), ("mosaic", "mosaic %s >/dev/null &"), ]) _browsers.extend([ *************** *** 102,107 **** --- 104,131 ---- register("netscape", Netscape) + class Konquerer: + """see http://developer.kde.org/documentation/other/kfmclient.html""" + def _remote(self, action): + cmd = "kfmclient %s >/dev/null 2>&1" % action + rc = os.system(cmd) + if rc: + import time + os.system("kfm -d &") + time.sleep(PROCESS_CREATION_DELAY) + rc = os.system(cmd) + return not rc + + def open(self, url, new=1): + # XXX currently I know no way to prevent KFM from opening a new win. + self.open_new(url) + + def open_new(self, url): + self._remote("openURL %s" % url) + + register("kfm", Konquerer) + + class Grail: # There should be a way to maintain a connection to Grail, but the # Grail remote control protocol doesn't really allow that at this *************** *** 167,172 **** --- 191,208 ---- DEFAULT_BROWSER = "windows-default" elif not os.environ.get("DISPLAY"): DEFAULT_BROWSER = "command-line-browser" + elif sys.platform == "linux2": + def small_ram(): + """returns True on machines with less than 128 MB Ram""" + import string, __builtin__ + memtotal = long(string.split( + __builtin__.open("/proc/meminfo").readlines()[1])[1]) + return memtotal < 128L * 1024 * 1024 # less than 128 MB + + if small_ram(): + DEFAULT_BROWSER = "kfm" + else: + DEFAULT_BROWSER = "netscape" else: DEFAULT_BROWSER = "netscape" From esr at thyrsus.com Fri Jul 7 15:03:22 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 7 Jul 2000 09:03:22 -0400 Subject: [Python-Dev] webbrowser module In-Reply-To: ; from pf@artcom-gmbh.de on Fri, Jul 07, 2000 at 02:26:38PM +0200 References: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> Message-ID: <20000707090322.A29880@thyrsus.com> Peter Funk : > May I suggest the patch below? It add's support for the > Linux KDE file manager KFM (aka Konquerer) as the default > web browser. This esspecially makes sense on smaller Linux > machines, where users don't want to spend the huge amount of > memory needed by a browser bloated to no avail with trashy > stuff like Java / Javascript .... Good patch! -- Eric S. Raymond The American Republic will endure, until politicians realize they can bribe the people with their own money. -- Alexis de Tocqueville From mal at lemburg.com Fri Jul 7 14:56:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 14:56:37 +0200 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <020001bfe80f$3b23ab10$0900a8c0@SPIFF> Message-ID: <3965D385.68D97C31@lemburg.com> Fredrik Lundh wrote: > > guido wrote: > > I propose ustr(x) with the semantics given by Toby. > > +1 on concept. > > not sure about the name and the semantics. Uhm, what's left then ;-) ? > maybe a better name would be "unistr" (to match "unistr"). > or maybe that's backwards? > > how about "String" (!). > > (the perfect name is "string", but that appears to be reserved > by someone else...) > > as for the semantics, note that __str__ is allowed to return a > unicode string in the current code base ("str" converts it to 8- > bit using the default encoding). ustr/unistr/String should pass > that one right through: > > def ustr(s): > if type(s) in (type(""), type(u"")): > return s > s = s.__str__() > if type(s) in (type(""), type(u"")): > return s > raise "__str__ returned wrong type" > > > Class support (an __ustr__ method, with fallbacks on __str__ > > and __unicode__) would also be handy. > > -0 on this one (__str__ can already return either type, and if the > goal is to get rid of both unichr and unistr in the future, we shouldn't > add more hooks if we can avoid it. it's easier to remove stuff if you > don't add them in the first place ;-) Agreed. I'm just adding coercion support for instances using that technique: instance defining __str__ can return Unicode objects which will then be used by the implementation whereever coercion to Unicode takes place. I'll add a similar hook to unicode(). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From alexwg at MIT.EDU Fri Jul 7 15:31:52 2000 From: alexwg at MIT.EDU (Alexander D Wissner-Gross) Date: Fri, 7 Jul 2000 09:31:52 -0400 (EDT) Subject: [Python-Dev] Re: [Patches] [Patch #100752] Make atoi work for negative bases, a useful generalization In-Reply-To: <14693.19707.553522.523595@beluga.mojam.com> Message-ID: Skip, Built-in support for negative bases would encourage further use of Python in math research (specifically, representation theory). For reference, Mathematica recently added support for negative base conversions. Negative bases allow the unique representation of both positive and negative integers without use of a sign. For example, "-3" in decimal equals, in base -2, "1101" (-3 = 1*(-2)^3 + 1*(-2)^2 + 0*(-2)^1 + 1*(-2)^0). It has been suggested that this property makes negative bases a more natural representation for integers than positive bases. There is more detailed information on the subject in The Art of Computer Programming Vol. 2. This functionality is not already in Python, as someone suggested on patches at python.org. Alex From guido at beopen.com Fri Jul 7 16:38:39 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 09:38:39 -0500 Subject: [Python-Dev] Re: [Patches] [Patch #100752] Make atoi work for negative bases, a useful generalization In-Reply-To: Your message of "Fri, 07 Jul 2000 09:31:52 -0400." References: Message-ID: <200007071438.JAA04100@cj20424-a.reston1.va.home.com> > Built-in support for negative bases would encourage further use of Python > in math research (specifically, representation theory). For reference, > Mathematica recently added support for negative base conversions. > > Negative bases allow the unique representation of both positive and > negative integers without use of a sign. For example, "-3" in decimal > equals, in base -2, "1101" (-3 = 1*(-2)^3 + 1*(-2)^2 + 0*(-2)^1 + 1*(-2)^0). > It has been suggested that this property makes negative bases a more natural > representation for integers than positive bases. There is more detailed > information on the subject in The Art of Computer Programming Vol. 2. Only a mathematician could call this "more natural"... For most of us, this is difficult to understand (e.g. the suggestion was made that int(s,x) == -int(s,-x), which isn't true) and there are no practical uses. As most of Python's users lack the sophistication to understand this, I'd rather not introduce this patch -- when I see a negative base somewhere, it's much more likely that it's a bug in the code than an advanced use of negative bases... That's a polite but firm -1. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Fri Jul 7 16:17:34 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 16:17:34 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines References: <20000707094036.AA22C31047C@bireme.oratrix.nl> <3965B6F8.72742A2E@lemburg.com> <20000707120149.6B39631047C@bireme.oratrix.nl> Message-ID: <3965E67E.CE81253D@lemburg.com> Sjoerd Mullender wrote: > > On Fri, Jul 7 2000 "M.-A. Lemburg" wrote: > > > Perhaps you could figure out which defines are needed to > > reenable the missing APIs on IRIX when _XOPEN_SOURCE is > > defined... it would be helpful to help pin-point the > > weak spots w/r to SUSv2 compatibility. > > It looks like there is no way of doing this. The relevant bits of > code are: > > In time.h (as an example): > #if _SGIAPI && _NO_ANSIMODE > extern time_t altzone; > #endif /* _SGIAPI */ > > So _SGIAPI and _NO_ANSIMODE should both be defined and != 0. > The definition of _SGIAPI is > #define _SGIAPI ((defined(_SGI_SOURCE) && \ > _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5) || \ > (_ANSIMODE && _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5)) > So, if _NO_XOPEN5 is 0, _SGIAPI is 0. The definition of _NO_XOPEN5 is > #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || \ > (defined(_XOPEN_SOURCE) && \ > (_XOPEN_SOURCE+0 < 500))) > So _NO_XOPEN5 is 0 since _XOPEN_SOURCE is defined and >= 500. Hmm, would that mean that altzone is not part of SUSv2 (in that case we'd have to change Python) ? Or are the SGI header files wrong here (which means we'd have to work around those bugs) ? > All of this on IRIX 6.5.2. I can't check other versions of IRIX. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fredrik at pythonware.com Fri Jul 7 16:40:40 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 16:40:40 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines References: <20000707094036.AA22C31047C@bireme.oratrix.nl> <3965B6F8.72742A2E@lemburg.com> <20000707120149.6B39631047C@bireme.oratrix.nl> <3965E67E.CE81253D@lemburg.com> Message-ID: <02d201bfe821$52c4b090$0900a8c0@SPIFF> mal wrote: > Hmm, would that mean that altzone is not part of SUSv2 as far as I can tell, altzone is not part of SUSv2. the time.h file declares the following variables: extern int daylight; extern long int timezone; extern char *tzname[]; does anyone know what standard (if any) altzone is defined by? From sjoerd at oratrix.nl Fri Jul 7 17:05:53 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Fri, 07 Jul 2000 17:05:53 +0200 Subject: [Python-Dev] problems with SUSv2 compatibility defines In-Reply-To: Your message of Fri, 07 Jul 2000 16:40:40 +0200. <02d201bfe821$52c4b090$0900a8c0@SPIFF> References: <20000707094036.AA22C31047C@bireme.oratrix.nl> <3965B6F8.72742A2E@lemburg.com> <20000707120149.6B39631047C@bireme.oratrix.nl> <3965E67E.CE81253D@lemburg.com> <02d201bfe821$52c4b090$0900a8c0@SPIFF> Message-ID: <20000707150554.37E2031047C@bireme.oratrix.nl> One of the big problems with configure is that the defines that are used to test features are not necessarily the same as the defines that are used when those features are actually used in the program being configured. Python's configure script tests for altzone, and if the defines in effect there were the same as the ones in effect during compilation, altzone would not have been found and the compilation would have gone smoothly. I don't have a solution for this problem, but a problem it is. -- Sjoerd Mullender From fdrake at beopen.com Fri Jul 7 18:22:16 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 12:22:16 -0400 (EDT) Subject: [Python-Dev] _sre.c's compiled size In-Reply-To: <20000707135641.F26534@xs4all.nl> References: <20000707135641.F26534@xs4all.nl> Message-ID: <14694.952.281470.320804@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > I've attached a teensy patch that allows '-f' flags to be used in > Setup files, to be able to easily switch between the two. This is checked in; thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jul 7 18:40:26 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 12:40:26 -0400 (EDT) Subject: [Python-Dev] webbrowser module In-Reply-To: References: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> Message-ID: <14694.2042.320980.231242@cj42289-a.reston1.va.home.com> Peter Funk writes: > May I suggest the patch below? It add's support for the > Linux KDE file manager KFM (aka Konquerer) as the default > web browser. This esspecially makes sense on smaller Linux Peter, Thanks for the Konquerer class! I'll add that. What I'm not sure about is using it as a default value if the use isn't running KDE. I just tried to play with kfm while Gnome was running, and it tried to load docklets and the like, which wasn't useful since the KDE panel wasn't running. (On the other hand, kfm *did* start up with the -d option, and kfmclient worked.) But that means that kfm was putting icons on my "desktop", and that's something I definately don't want. So I'm hesitant. Is there a reasonably reliable way to determine if the user is running KDE, and only make this the default in that case? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Fri Jul 7 18:53:19 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 7 Jul 2000 11:53:19 -0500 (CDT) Subject: [Python-Dev] webbrowser module In-Reply-To: <14694.2042.320980.231242@cj42289-a.reston1.va.home.com> References: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> <14694.2042.320980.231242@cj42289-a.reston1.va.home.com> Message-ID: <14694.2815.308486.875411@beluga.mojam.com> Fred> What I'm not sure about is using it as a default value if the use Fred> isn't running KDE. Fred, I'm running kde. From bash I see an environment variable named KDEDIR whose value is "/usr". Would that be a possible extra test to assure that kde is running before deciding to launch kfm? Skip From fdrake at beopen.com Fri Jul 7 19:05:09 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 13:05:09 -0400 (EDT) Subject: [Python-Dev] webbrowser module In-Reply-To: <14694.2815.308486.875411@beluga.mojam.com> References: <14693.20785.392024.422763@cj42289-a.reston1.va.home.com> <14694.2042.320980.231242@cj42289-a.reston1.va.home.com> <14694.2815.308486.875411@beluga.mojam.com> Message-ID: <14694.3525.845782.579413@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > I'm running kde. From bash I see an environment variable named KDEDIR whose > value is "/usr". Would that be a possible extra test to assure that kde is > running before deciding to launch kfm? Sounds good! How about this for the non-MacOS portion of the default-browser determination: DEFAULT_BROWSER = "command-line" if sys.platform[:3] == "win": del _browsers["kfm"] register("windows-default", WindowsDefault) DEFAULT_BROWSER = "windows-default" elif os.environ.get("DISPLAY"): if os.environ.get("KDEDIR"): DEFAULT_BROWSER = "kfm" elif _iscommand("netscape"): DEFAULT_BROWSER = "netscape" -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pf at artcom-gmbh.de Fri Jul 7 20:02:41 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Fri, 7 Jul 2000 20:02:41 +0200 (MEST) Subject: [Python-Dev] webbrowser module In-Reply-To: <14694.3525.845782.579413@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at "Jul 7, 2000 1: 5: 9 pm" Message-ID: Hi, Fred L. Drake, Jr. : > > Skip Montanaro writes: > > I'm running kde. From bash I see an environment variable named KDEDIR whose > > value is "/usr". Would that be a possible extra test to assure that kde is > > running before deciding to launch kfm? Clever idea, Skip! This will also work on SuSE Linux, where I have KDEDIR=/opt/kde > Sounds good! How about this for the non-MacOS portion of the > default-browser determination: > > DEFAULT_BROWSER = "command-line" > > if sys.platform[:3] == "win": > del _browsers["kfm"] > register("windows-default", WindowsDefault) > DEFAULT_BROWSER = "windows-default" > elif os.environ.get("DISPLAY"): > if os.environ.get("KDEDIR"): > DEFAULT_BROWSER = "kfm" > elif _iscommand("netscape"): > DEFAULT_BROWSER = "netscape" I believe there might be some people using KDE on a luxury computer (like the rolls royce alike that Fred has) and because they don't have to bother about RAM usage, they still may want to use Netscape as their default browser under KDE. I muust admit that Netscape provides more features and nice bookmark handling, although the differences might become smaller with KDE 2.x. That however again will burn more RAM. :-( Testing for available RAM will only work on Linux on the other hand, because most other unices lack '/proc/meminfo'. Using something more portable like the famous 'wc -c /dev/mem' unix tool abuse hack will not work due to the obvious lack of read permissions on /dev/mem for simple user processes. Adding the proposed AI (heuristic, hack, rule-of-thumb whatever you want to call it) to choose the default browser dependent on the amount of installed RAM is quite unpythonic, or what? However it is so simple, since Linux and Python are really powerful here: def small_ram(): """returns True on machines with less than 128 MB Ram""" import string, __builtin__ memtotal = long(string.split( __builtin__.open("/proc/meminfo").readlines()[1])[1]) return memtotal < 128L * 1024 * 1024 # less than 128 MB May be the best solution would be to test if any of the _browsers, which support a remote protocol is already running and only fire up a new browser, if no browser process can be identified. This however will break the current class hierarchy. So this should be delayed until Python 2.1? Finally: I like your proposed solution. Regards, Peter From paul at prescod.net Fri Jul 7 20:08:47 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 07 Jul 2000 13:08:47 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> Message-ID: <39661CAF.9252D734@prescod.net> Guido van Rossum wrote: > > ... > > For strings there is no compact notation like "+0.0" if you want to > convert to string or Unicode -- adding "" might work in Perl, but not > in Python. Actually, these days, foo+"" works in a LOT of languages. Perl, Java and JavaScript for sure. C++, depending on the type. Python's strictness about this issue has never caught a bug for me. It has only caused errors. Okay, some newbie may think that "5"+"5"=="10". But they could also expect [5]+[5]==[10]. There are limits to the extent that we can protect them from incorrect mental models. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From akuchlin at mems-exchange.org Fri Jul 7 20:15:05 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 07 Jul 2000 14:15:05 -0400 Subject: [Python-Dev] c.l.py.a revival Message-ID: While waiting for word of a 2.0b1 release, what about continuing to attempt to revive c.l.python.announce? Last I remember, it was suggested to add Guido as a moderator so he could in turn delegate handling of messages to someone else. Was any progress ever made with this? --amk From fdrake at beopen.com Fri Jul 7 20:19:16 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 14:19:16 -0400 (EDT) Subject: [Python-Dev] c.l.py.a revival In-Reply-To: References: Message-ID: <14694.7972.264112.121727@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > While waiting for word of a 2.0b1 release, what about continuing to > attempt to revive c.l.python.announce? Last I remember, it was > suggested to add Guido as a moderator so he could in turn delegate > handling of messages to someone else. Was any progress ever made with I think the problem was that the current moderators had to add Guido as a moderator; once that's done Guido can delegate as desired. Can you prod Markus for us on this one? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Fri Jul 7 20:20:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 20:20:53 +0200 Subject: [Python-Dev] c.l.py.a revival References: Message-ID: <39661F85.B87EDB2E@lemburg.com> Andrew Kuchling wrote: > > While waiting for word of a 2.0b1 release, what about continuing to > attempt to revive c.l.python.announce? Last I remember, it was > suggested to add Guido as a moderator so he could in turn delegate > handling of messages to someone else. Was any progress ever made with > this? How about reviving the announcement mailing list first -- messages posted to that list result in an error return mail and don't show up anywhere. If that works, I'd suggest adding support for forwarding the messages to the moderated list via the hack that was described last time we discussed this. I think Barry is already working on this one, right ;-) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy at beopen.com Fri Jul 7 20:23:41 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 14:23:41 -0400 (EDT) Subject: [Python-Dev] c.l.py.a revival In-Reply-To: References: Message-ID: <14694.8237.260813.999821@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> While waiting for word of a 2.0b1 release, what about AMK> continuing to attempt to revive c.l.python.announce? Last I AMK> remember, it was suggested to add Guido as a moderator so he AMK> could in turn delegate handling of messages to someone else. AMK> Was any progress ever made with this? I believe the desired solution was actually to use the python-announce mailing list to moderate the newsgroup. The current moderator sketched the desired setup, which involved setting up the mailing list moderation software to add the headers that indicated it was approved by the newsgroup moderators. I believe this is still on Barry's plate -- along with too many other things for me to count, but at least not bibimbap or doji bulgogi. Jeremy From fredrik at pythonware.com Fri Jul 7 21:05:01 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 21:05:01 +0200 Subject: [Python-Dev] where did httplib.HTTPS go? Message-ID: <000701bfe846$41b8ad40$0900a8c0@SPIFF> [fredrik at brain src]$ ./python Python 2.0b1 (#4, Jul 7 2000, 12:23:15) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 >>> import httplib >>> httplib.HTTPS Traceback (most recent call last): File "", line 1, in ? AttributeError: HTTPS urllib and the test code in httplib.py uses HTTPS, but I cannot find it. and neither can grep: Lib/httplib.py:HTTPS_PORT = 443 Lib/httplib.py:class HTTPSConnection(HTTPConnection): Lib/httplib.py: default_port = HTTPS_PORT Lib/httplib.py: hs = HTTPS() Lib/urllib.py: """Use HTTPS protocol.""" Lib/urllib.py: h = httplib.HTTPS(host, 0, where is it? what am I missing? From jeremy at beopen.com Fri Jul 7 21:13:13 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 15:13:13 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <000701bfe846$41b8ad40$0900a8c0@SPIFF> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> Message-ID: <14694.11209.999476.330370@bitdiddle.concentric.net> Looks like Greg didn't add it before he checked in the new implementation. I thought he was going to. I also thought he was going to change the indentation to four spaces. Is that a standard for Python code in the library, or am I just being fussy? Jeremy From fredrik at pythonware.com Fri Jul 7 21:13:27 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 21:13:27 +0200 Subject: [Python-Dev] bogus LANG setting results in "import site failed" message Message-ID: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> [fredrik at brain src]$ export LANG=foobar [fredrik at brain src]$ ./python 'import site' failed; use -v for traceback Python 2.0b1 (#4, Jul 7 2000, 12:23:15) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> that "import site" is a bit disturbing. maybe the locale-checking code should handle this case a bit more gracefully? (like, say, printing a more explicit warning message). From fdrake at beopen.com Fri Jul 7 21:14:14 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 15:14:14 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.11209.999476.330370@bitdiddle.concentric.net> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> Message-ID: <14694.11270.542014.447760@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > I also thought he was going to change the indentation to four spaces. > Is that a standard for Python code in the library, or am I just being > fussy? All new code should use four-space indents, but we've never gone through and agressively converted old code. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Fri Jul 7 21:19:45 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 15:19:45 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.11270.542014.447760@cj42289-a.reston1.va.home.com> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <14694.11270.542014.447760@cj42289-a.reston1.va.home.com> Message-ID: <14694.11601.611455.4339@bitdiddle.concentric.net> >>>>> "FLD" == Fred L Drake, writes: FLD> Jeremy Hylton writes: >> I also thought he was going to change the indentation to four >> spaces. Is that a standard for Python code in the library, or am >> I just being fussy? FLD> All new code should use four-space indents, but we've never FLD> gone through and agressively converted old code. Why is it that a reply from you in particular doesn't make me feel confident that I am not being fussy? :-) Jeremy From fdrake at beopen.com Fri Jul 7 21:19:39 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 15:19:39 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.11601.611455.4339@bitdiddle.concentric.net> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <14694.11270.542014.447760@cj42289-a.reston1.va.home.com> <14694.11601.611455.4339@bitdiddle.concentric.net> Message-ID: <14694.11595.370101.739327@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > Why is it that a reply from you in particular doesn't make me feel > confident that I am not being fussy? :-) I didn't say you *weren't* being fussy. ;) I will say that you *should* be fusy, which may be about what you expect. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Fri Jul 7 21:33:55 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 7 Jul 2000 15:33:55 -0400 (EDT) Subject: [Python-Dev] c.l.py.a revival References: <14694.8237.260813.999821@bitdiddle.concentric.net> Message-ID: <14694.12451.606319.130358@anthem.concentric.net> Yup, it's still on my plate and I'll try to spend some time on it this weekend. From mal at lemburg.com Fri Jul 7 21:37:35 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 07 Jul 2000 21:37:35 +0200 Subject: [Python-Dev] bogus LANG setting results in "import site failed" message References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> Message-ID: <3966317F.4A39E6A2@lemburg.com> Fredrik Lundh wrote: > > [fredrik at brain src]$ export LANG=foobar > [fredrik at brain src]$ ./python > 'import site' failed; use -v for traceback > Python 2.0b1 (#4, Jul 7 2000, 12:23:15) [GCC egcs-2.91.66 19990314/Linux > (egcs-1.1.2 release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> > > that "import site" is a bit disturbing. maybe the locale-checking > code should handle this case a bit more gracefully? > > (like, say, printing a more explicit warning message). Here's the patch (Skip's locking the Lib dir ... grrr ;-): --- CVS-Python/Lib/site.py Wed Jun 28 17:30:57 2000 +++ Python+Unicode/Lib/site.py Fri Jul 7 21:30:54 2000 @@ -124,11 +124,16 @@ del exit # encoding used by the default locale of this system. If the default # encoding cannot be determined or is unknown, it defaults to 'ascii'. # def locale_aware_defaultencoding(): import locale - code, encoding = locale.get_default() + try: + code, encoding = locale.get_default() + except ValueError, why: + sys.stderr.write('Error setting default encoding (%s), using ASCII.\n' + % why) + encoding = None if encoding is None: encoding = 'ascii' try: sys.setdefaultencoding(encoding) except LookupError: -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Fri Jul 7 21:44:49 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 12:44:49 -0700 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.11209.999476.330370@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jul 07, 2000 at 03:13:13PM -0400 References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> Message-ID: <20000707124449.E29590@lyra.org> On Fri, Jul 07, 2000 at 03:13:13PM -0400, Jeremy Hylton wrote: > Looks like Greg didn't add it before he checked in the new > implementation. I thought he was going to. Yah, my fault. I'll get the changes back in there later tonite. > I also thought he was going to change the indentation to four spaces. > Is that a standard for Python code in the library, or am I just being > fussy? I think you're being fussy, but I can change this. I'll do a separate commit that just changes white space (and possibly reflow some comments). Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Fri Jul 7 21:46:07 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 12:46:07 -0700 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <000701bfe846$41b8ad40$0900a8c0@SPIFF>; from fredrik@pythonware.com on Fri, Jul 07, 2000 at 09:05:01PM +0200 References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> Message-ID: <20000707124606.F29590@lyra.org> On Fri, Jul 07, 2000 at 09:05:01PM +0200, Fredrik Lundh wrote: > [fredrik at brain src]$ ./python > Python 2.0b1 (#4, Jul 7 2000, 12:23:15) [GCC egcs-2.91.66 19990314/Linux > (egcs-1.1.2 release)] on linux2 > >>> import httplib > >>> httplib.HTTPS > Traceback (most recent call last): > File "", line 1, in ? > AttributeError: HTTPS > > urllib and the test code in httplib.py uses HTTPS, > but I cannot find it. and neither can grep: > > Lib/httplib.py:HTTPS_PORT = 443 > Lib/httplib.py:class HTTPSConnection(HTTPConnection): > Lib/httplib.py: default_port = HTTPS_PORT > Lib/httplib.py: hs = HTTPS() > Lib/urllib.py: """Use HTTPS protocol.""" > Lib/urllib.py: h = httplib.HTTPS(host, 0, > > where is it? what am I missing? Oh... one more comment: I'll be updating urllib.py at some point to *not* use HTTPS. It should be using HTTPSConnection instead. (and HTTPConnection rather than HTTP) ... dunno if other libraries use httplib, but I'll look and update those, too. Maybe in the Demo/ area. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Fri Jul 7 21:47:50 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 15:47:50 -0400 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <20000707124449.E29590@lyra.org> Message-ID: [Jeremy Hylton] > I also thought he was going to change the indentation to four spaces. > Is that a standard for Python code in the library, or am I just being > fussy? It is a std for distributed Python code, and so deciding whether it's fussy is irrelevant. [Greg Stein] > I think you're being fussy, Irrelevant. > but I can change this. Almost the right answer. > I'll do a separate commit that just changes white space (and possibly > reflow some comments). Bingo! life-is-so-much-easier-when-you-don't-think-too-much-ly y'rs - tim From fredrik at pythonware.com Fri Jul 7 21:48:43 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 21:48:43 +0200 Subject: [Python-Dev] repository locks References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> <3966317F.4A39E6A2@lemburg.com> Message-ID: <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> > Here's the patch (Skip's locking the Lib dir ... grrr ;-): tonight's stupid question: What's causing all these stale locks? I'm a totally clueless CVS user, and I've managed to check at least 114 things into the repository without leaving any locks behind me. Is it just sheer luck, or is there some flaw in CVS waiting for me to stumble upon? From tim_one at email.msn.com Fri Jul 7 21:55:39 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 15:55:39 -0400 Subject: [Python-Dev] repository locks In-Reply-To: <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> Message-ID: [/F] > What's causing all these stale locks? Best I can tell, Skip. > I'm a totally clueless CVS user, You don't want to fight me on that one . > and I've managed to check at least 114 things into the repository > without leaving any locks behind me. I think I've lucked out too. > Is it just sheer luck, or is there some flaw in CVS waiting > for me to stumble upon? There are many links in the chain from one of our machines to CVS on SourceForge. My bet is that if it's working for you, it will continue to work; and that we'll continue to see locks left behind by Skip until he manages to replace the link in his chain that's damaged. Also betting there's a 50-50 chance we'll never know which link it was. it's-software-it-sucks-it's-par-for-the-course-ly y'rs - tim From guido at beopen.com Fri Jul 7 23:02:16 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:02:16 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: Your message of "Fri, 07 Jul 2000 13:08:47 EST." <39661CAF.9252D734@prescod.net> References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <39661CAF.9252D734@prescod.net> Message-ID: <200007072102.QAA05114@cj20424-a.reston1.va.home.com> [me] > > For strings there is no compact notation like "+0.0" if you want to > > convert to string or Unicode -- adding "" might work in Perl, but not > > in Python. [PaulPrescod] > Actually, these days, foo+"" works in a LOT of languages. Perl, Java and > JavaScript for sure. Really? Does 3+"" really convert the 3 to a string in Java? > C++, depending on the type. Python's strictness > about this issue has never caught a bug for me. It has only caused > errors. Are you sure? This is the kind of error where you immediately see what's wrong and move on to the next bug. > Okay, some newbie may think that "5"+"5"=="10". But they could > also expect [5]+[5]==[10]. There are limits to the extent that we can > protect them from incorrect mental models. I won't argue with you there :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Fri Jul 7 23:02:49 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:02:49 -0500 Subject: [Python-Dev] c.l.py.a revival In-Reply-To: Your message of "Fri, 07 Jul 2000 14:15:05 -0400." References: Message-ID: <200007072102.QAA05127@cj20424-a.reston1.va.home.com> > While waiting for word of a 2.0b1 release, what about continuing to > attempt to revive c.l.python.announce? Last I remember, it was > suggested to add Guido as a moderator so he could in turn delegate > handling of messages to someone else. Was any progress ever made with > this? Not that I know of -- it's as dead as ever. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein at lyra.org Fri Jul 7 22:08:15 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 13:08:15 -0700 Subject: [Python-Dev] CVS: python/dist/src/Objects longobject.c,1.60,1.61 In-Reply-To: <200007071553.IAA06685@slayer.i.sourceforge.net>; from tim_one@users.sourceforge.net on Fri, Jul 07, 2000 at 08:53:31AM -0700 References: <200007071553.IAA06685@slayer.i.sourceforge.net> Message-ID: <20000707130815.I29590@lyra.org> On Fri, Jul 07, 2000 at 08:53:31AM -0700, Tim Peters wrote: >... > --- 1693,1709 ---- > sizeof(PyLongObject) - sizeof(digit), > sizeof(digit), > ! (destructor)long_dealloc, /*tp_dealloc*/ > ! 0, /*tp_print*/ > ! 0, /*tp_getattr*/ > ! 0, /*tp_setattr*/ > ! (int (*) (PyObject *, PyObject *)) > ! (cmpfunc)long_compare, /*tp_compare*/ > ! (reprfunc)long_repr, /*tp_repr*/ > ! &long_as_number, /*tp_as_number*/ > ! 0, /*tp_as_sequence*/ > ! 0, /*tp_as_mapping*/ > ! (long (*) (PyObject *)) > ! (hashfunc)long_hash, /*tp_hash*/ > ! 0, /*tp_call*/ > ! (reprfunc)long_str, /*tp_str*/ > }; What is with those double casts for tp_compare and tp_hash? The prototypes match cmpfunc and hashfunc, so I think they ought to just be dropped. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Fri Jul 7 23:11:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:11:29 -0500 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: Your message of "Fri, 07 Jul 2000 12:44:49 MST." <20000707124449.E29590@lyra.org> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <20000707124449.E29590@lyra.org> Message-ID: <200007072111.QAA05197@cj20424-a.reston1.va.home.com> > > I also thought he was going to change the indentation to four spaces. > > Is that a standard for Python code in the library, or am I just being > > fussy? > > I think you're being fussy, but I can change this. I'll do a separate commit > that just changes white space (and possibly reflow some comments). To my eyes, 2-space indents are unreadable. Please make it 4 spaces, like all other new code. There's no excuse for arguing about whitespace in Python. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Fri Jul 7 22:13:03 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 16:13:03 -0400 (EDT) Subject: [Python-Dev] repository locks In-Reply-To: <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> <3966317F.4A39E6A2@lemburg.com> <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> Message-ID: <14694.14799.389933.276211@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > I'm a totally clueless CVS user, and I've managed to check > at least 114 things into the repository without leaving any > locks behind me. The checkins aren't causing the problem -- these are read locks on the directories. > Is it just sheer luck, or is there some flaw in CVS waiting > for me to stumble upon? I think there's probably a bug in the CVS server, but not sure, and I haven't dug into the CVS code to figure it out. It looks like some operation is locking the directory (update, or a diff), and then the connection to the client disappears, and the server exits without cleaning up the lock. As long as we're reading from the repository, that doesn't matter -- the problem is when we go to write to the repository, the CVS server talking to us still thinks there's a reader, so we're denied access. Another possibility is that there's a stuck CVS server (with a dead connection) holding the lock, and it hasn't exited at all. But that's less likely. The problem is likely because we're a very active project with lots of simulataneous repository access on an overloaded service. I've noticed that the other services at SourceForge (message forums, support managers, etc.) have been really slow the past 36 hours as well. Clearly, we van blame it all on Skip. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Fri Jul 7 22:16:08 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 16:16:08 -0400 Subject: [Python-Dev] CVS: python/dist/src/Objects longobject.c,1.60,1.61 In-Reply-To: <20000707130815.I29590@lyra.org> Message-ID: [Greg Stein] > >... > > --- 1693,1709 ---- > > sizeof(PyLongObject) - sizeof(digit), > > sizeof(digit), > > ! (destructor)long_dealloc, /*tp_dealloc*/ > > ! 0, /*tp_print*/ > > ! 0, /*tp_getattr*/ > > ! 0, /*tp_setattr*/ > > ! (int (*) (PyObject *, PyObject *)) > > ! (cmpfunc)long_compare, /*tp_compare*/ > > ! (reprfunc)long_repr, /*tp_repr*/ > > ! &long_as_number, /*tp_as_number*/ > > ! 0, /*tp_as_sequence*/ > > ! 0, /*tp_as_mapping*/ > > ! (long (*) (PyObject *)) > > ! (hashfunc)long_hash, /*tp_hash*/ > > ! 0, /*tp_call*/ > > ! (reprfunc)long_str, /*tp_str*/ > > }; > > What is with those double casts for tp_compare and tp_hash? The > prototypes match cmpfunc and hashfunc, so I think they ought to > just be dropped. The patch in this area just normalized the whitespace for easier reading (although thanks to stinking hard tab characters, it may not *look* that way!) -- the double casts were there before. I'll be making more changes to the file "soon", and will look into what you suggest -- suspect you're right that it's just confusingly redundant. From guido at beopen.com Fri Jul 7 23:16:26 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:16:26 -0500 Subject: [Python-Dev] repository locks In-Reply-To: Your message of "Fri, 07 Jul 2000 21:48:43 +0200." <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> <3966317F.4A39E6A2@lemburg.com> <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> Message-ID: <200007072116.QAA05244@cj20424-a.reston1.va.home.com> > tonight's stupid question: > > What's causing all these stale locks? > > I'm a totally clueless CVS user, and I've managed to check > at least 114 things into the repository without leaving any > locks behind me. > > Is it just sheer luck, or is there some flaw in CVS waiting > for me to stumble upon? These locks are read-locks caused by checkouts that are aborted. Somehow the CVS server doesn't always catch this. I suppose there are also write-locks by commits that could be left around, but you typically don't abort a commit -- but it's common to hit ^C when an update takes a bit long. Not defending CVS (I think it should catch SIGPIPE since that's probably what it's getting since this is done remotely) but just setting the record straight. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From martin at loewis.home.cs.tu-berlin.de Fri Jul 7 22:24:03 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Fri, 7 Jul 2000 22:24:03 +0200 Subject: [Python-Dev] Encodings Message-ID: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> >> This sounds very bad. I thought we agreed that attempting to >> compare (or add) a Unicode string and an 8-bit string containing >> non-ASCII characters (as in your example) should raise an exception. > >Only if the default encoding is ASCII. That is not my understanding of the agreement, and I think the whole idea of a default encoding is a stupid one. I strongly suggest that the behaviour that Ping just explained and that Guido had suggested originally is implemented: Mixing unicode and string objects is only allowed if the string objects are ASCII. Everything else (including a "default" encoding of some kind) is an application issue. Otherwise, you'll just go on and ask questions endlessly how things should behave, and change the interpreter forwards and backwards. The meaning of mixing both kinds of objects is very easy to explain, and also allows for efficient implementation - which you won't get if you have to invoke a character conversion just to get the hash value of a unicode value (!) Regards, Martin From jeremy at beopen.com Fri Jul 7 22:31:35 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 16:31:35 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <200007072111.QAA05197@cj20424-a.reston1.va.home.com> References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <20000707124449.E29590@lyra.org> <200007072111.QAA05197@cj20424-a.reston1.va.home.com> Message-ID: <14694.15911.109077.944657@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> To my eyes, 2-space indents are unreadable. Please make it 4 GvR> spaces, like all other new code. There's no excuse for arguing GvR> about whitespace in Python. :-) imputil.py also needs to be fixed. Jeremy From gstein at lyra.org Fri Jul 7 22:39:15 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 13:39:15 -0700 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.15911.109077.944657@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jul 07, 2000 at 04:31:35PM -0400 References: <000701bfe846$41b8ad40$0900a8c0@SPIFF> <14694.11209.999476.330370@bitdiddle.concentric.net> <20000707124449.E29590@lyra.org> <200007072111.QAA05197@cj20424-a.reston1.va.home.com> <14694.15911.109077.944657@bitdiddle.concentric.net> Message-ID: <20000707133915.L29590@lyra.org> On Fri, Jul 07, 2000 at 04:31:35PM -0400, Jeremy Hylton wrote: > >>>>> "GvR" == Guido van Rossum writes: > > GvR> To my eyes, 2-space indents are unreadable. Please make it 4 > GvR> spaces, like all other new code. There's no excuse for arguing > GvR> about whitespace in Python. :-) > > imputil.py also needs to be fixed. Damn. I just can't win! ;-) -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Fri Jul 7 22:39:00 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 16:39:00 -0400 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: <200007072102.QAA05114@cj20424-a.reston1.va.home.com> Message-ID: [Guido] >>> For strings there is no compact notation like "+0.0" if you want to >>> convert to string or Unicode -- adding "" might work in Perl, but not >>> in Python. BTW, "+0.0" is not a correct way to "boundedly coerce" to float under 754 arithmetic; "*1.0" is safer (the former does not always preserve the sign bit of a float zero correctly, but the latter does). [Paul Prescod] >> Actually, these days, foo+"" works in a LOT of languages. Perl, Java and >> JavaScript for sure. [Guido] > Really? Does 3+"" really convert the 3 to a string in Java? I don't remember about that specifically, but believe ""+3 does. OTOH, in *Perl* 3+"" converts "" to the *number* 0 and leaves 3 alone. >> Python's strictness about this issue has never caught a bug for me. It >> has only caused errors. > Are you sure? This is the kind of error where you immediately see > what's wrong and move on to the next bug. It's certainly caught errors for me, and especially when introducing Perl programmers to Python, where "they expect" string+number to convert the string to a number, apparently the opposite of the arbitrary choice Paul prefers. It's ambiguous as hell -- screw it. From bwarsaw at beopen.com Fri Jul 7 22:52:50 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 7 Jul 2000 16:52:50 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? References: <20000707124449.E29590@lyra.org> Message-ID: <14694.17186.868952.214837@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: >> I'll do a separate commit that just changes white space (and >> possibly reflow some comments). TP> Bingo! TP> life-is-so-much-easier-when-you-don't-think-too-much-ly TP> y'rs - tim Oh, and while you're at it, please untabify the file. I don't know if your module has tabs in it, but if so please convert all tabs to spaces. -Barry From pingster at ilm.com Fri Jul 7 22:50:32 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 7 Jul 2000 13:50:32 -0700 (PDT) Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: Message-ID: On Fri, 7 Jul 2000, Tim Peters wrote: > > Are you sure? This is the kind of error where you immediately see > > what's wrong and move on to the next bug. > > It's certainly caught errors for me, and especially when introducing Perl > programmers to Python, where "they expect" string+number to convert the > string to a number, apparently the opposite of the arbitrary choice Paul > prefers. It's not arbitrary -- the decision is made according to the type of the *operator* rather than the type of the operands. anything + anything returns a number anything . anything returns a string So "34"+0 converts to a number and 34."" converts to a string (i've seen both idioms fairly often). Anyway, i still agree that it's best to avoid automatic coercion between numbers and strings -- since it's now very easy to say int("3") as opposed to import string; string.atoi("3"), there's really no excuse for not being explicit. -- ?!ng "Things are more like they are now than they ever were before." -- Dwight D. Eisenhower From martin at loewis.home.cs.tu-berlin.de Fri Jul 7 22:53:37 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Fri, 7 Jul 2000 22:53:37 +0200 Subject: [Python-Dev] Unicode experience Message-ID: <200007072053.WAA02470@loewis.home.cs.tu-berlin.de> > Really? Does 3+"" really convert the 3 to a string in Java? Yes. It is one of my favorite Java features... If a binary + has one argument of type java.lang.String, then the other object is coerced to string as well (unless the other operand is also a string), using the following procedure: If it is a primitive type, an instance of the appopriate helper is created, in this case java.lang.Integer, so we only have java.lang.Object specializations now (*). Then, .toString() is invoked for the object, and the strings are concatenated. This allows to write things like System.out.println("Name:"+name" Age:"+age); so they did not have to copy the printf(3C) family of function, nor to introduce operator overloading for iostream-style output. Teaching this stuff to students, it turns out that there are two major sources of confusion: a) System.out.println("abc"+3+3) prints "abc33", whereas System.out.println(3+3+"abc") prints "6abc", so the binary + is not commutative. b) Both System.out.println("result "+myobj) and System.out.println(myobj) work, but for different reasons. In the first case, it works because of the magic binary '+'. In the second case, it works because println is overloaded for all types, i.e. println(int); println(double); ... println(Object); // invokes println(o.toString()); println(String); // does the real work Regards, Martin (*) Implementations don't have to create those temporaries; the usual as-if rule applies. From guido at beopen.com Fri Jul 7 23:58:56 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 16:58:56 -0500 Subject: [Python-Dev] Encodings In-Reply-To: Your message of "Fri, 07 Jul 2000 22:24:03 +0200." <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> Message-ID: <200007072158.QAA05483@cj20424-a.reston1.va.home.com> > That is not my understanding of the agreement, and I think the whole > idea of a default encoding is a stupid one. I strongly suggest that > the behaviour that Ping just explained and that Guido had suggested > originally is implemented: Mixing unicode and string objects is only > allowed if the string objects are ASCII. Everything else (including a > "default" encoding of some kind) is an application issue. > > Otherwise, you'll just go on and ask questions endlessly how things > should behave, and change the interpreter forwards and backwards. > > The meaning of mixing both kinds of objects is very easy to explain, > and also allows for efficient implementation - which you won't get if > you have to invoke a character conversion just to get the hash value > of a unicode value (!) I agree with this point. It can be implemented easily by deleting the locale specific guessing from site.py. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein at lyra.org Fri Jul 7 23:05:39 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 14:05:39 -0700 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.17186.868952.214837@anthem.concentric.net>; from bwarsaw@beopen.com on Fri, Jul 07, 2000 at 04:52:50PM -0400 References: <20000707124449.E29590@lyra.org> <14694.17186.868952.214837@anthem.concentric.net> Message-ID: <20000707140539.N29590@lyra.org> On Fri, Jul 07, 2000 at 04:52:50PM -0400, Barry A. Warsaw wrote: > >>>>> "TP" == Tim Peters writes: > > >> I'll do a separate commit that just changes white space (and > >> possibly reflow some comments). > > TP> Bingo! > > TP> life-is-so-much-easier-when-you-don't-think-too-much-ly > TP> y'rs - tim > > Oh, and while you're at it, please untabify the file. I don't know if > your module has tabs in it, but if so please convert all tabs to > spaces. I haven't had tabs in my Python files for years :-) (C code is a different matter...) Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Fri Jul 7 23:01:09 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 17:01:09 -0400 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: Message-ID: [Tim] > It's certainly caught errors for me, and especially when > introducing Perl programmers to Python, where "they expect" > string+number to convert the string to a number, apparently > the opposite of the arbitrary choice Paul prefers. [Ping] > It's not arbitrary -- the decision is made according to the > type of the *operator* rather than the type of the operands. > > anything + anything returns a number > anything . anything returns a string Of the languages discussed, this is true only in Perl. The other languages map "+" to the string meaning, so it's arbitrary wrt the universe under discussion. Toss Icon into the Perl camp on this one, btw. Within Perl, that "+" means numeric addition and "." string catenation is also abitrary -- it could just as well have been the other way around. Perl simply aped Awk's arbitrary choice for what "+" means. > So "34"+0 converts to a number and 34."" converts to a string > (i've seen both idioms fairly often). Yes, & about as often as you see explicit str() or int() calls in Python. It's not a question of not needing the functionality, but of how to spell it (both!). > ... > there's really no excuse for not being explicit. i-think-that's-what-i-said-the-first-time-ly y'rs - tim From skip at mojam.com Fri Jul 7 23:07:15 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 7 Jul 2000 16:07:15 -0500 (CDT) Subject: [Python-Dev] repository locks In-Reply-To: <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> References: <000701bfe847$6ec85cd0$0900a8c0@SPIFF> <3966317F.4A39E6A2@lemburg.com> <006101bfe84c$5b7b29a0$0900a8c0@SPIFF> Message-ID: <14694.18051.422859.570782@beluga.mojam.com> >> Here's the patch (Skip's locking the Lib dir ... grrr ;-): Fredrik> What's causing all these stale locks? To the best of my knowledge there were two stale locks, both caused by me (*sigh*) as the result of a single failed cvs diff command. The SF folks released the lock on Modules but apparently failed badly to respond to two separate requests (from Barry and me) to release the lock on Lib. Here's what I think happened (I'm not going to test my theory on the Python tree lest I bollux up more directories!). I wanted to create a single context diff containing just the changes I had made to Modules/readline.c and Lib/rlcompleter.py. I changed directory to my Python top-level directory and executed cvs diff -C Modules/readline.c Lib/rlcompleter.py This failed, as did a couple other permutations I tried shortly after that. My theory is that "cvs diff" fiddles things a bit then calls the local diff command. Diff's -C flag is supposed to have a number as an argument (the number of context lines to display - I should have used "-c", which is the same as "-C2" I think). Diff exited with a nonzero status. Either rcsdiff or cvs diff failed to recover properly and we're left with a read lock on both Modules and Lib. On a repository here I just tried: cvs diff -C www/dbserve.py which gave me the following output: cvs diff: Diffing GNIS cvs diff: Diffing conferences cvs diff: Diffing www Index: www/Makefile =================================================================== RCS file: /home/dolphin/projects/www-python/Makefile,v retrieving revision 1.51 diff -Cwww/dbserve.py -r1.51 Makefile cvs diff: invalid context length argument Segmentation fault And it left the following file in my repository: -rw-rw-r-- 1 skip users 0 Jul 7 15:54 #cvs.rfl.dolphin.25030 When I try to check in a changed file to that repository I get: cvs server: [15:57:27] waiting for skip's lock in /home/dolphin/projects/www-python Delete the lock file and after a short pause I get: cvs server: [15:58:57] obtained lock in /home/dolphin/projects/www-python Checking in fsm.py; /home/dolphin/projects/www-python/fsm.py,v <-- fsm.py new revision: 1.4; previous revision: 1.3 done Cute, huh? So, this confirms what I suspected. There would appear to be a bug in cvs (I'm using 1.10.7). I will look and see if this is a reported bug and/or see if there is a newer version of cvs. Note that this doesn't let SourceForge off the hook. In theory, anyone with read access to any (or all?!?) CVS repositories at sourceforge.net could bring them to a screeching halt (at least for a bit) by performing the same trick on lots of repositories. my-fortune-cookie-quote-takes-on-new-meaning-ly y'rs, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From bwarsaw at beopen.com Fri Jul 7 23:11:59 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 7 Jul 2000 17:11:59 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? References: <20000707124449.E29590@lyra.org> <14694.17186.868952.214837@anthem.concentric.net> <20000707140539.N29590@lyra.org> Message-ID: <14694.18335.738567.420313@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> I haven't had tabs in my Python files for years :-) Cool! GS> (C code is a different matter...) Yup. From fredrik at pythonware.com Fri Jul 7 23:26:42 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 23:26:42 +0200 Subject: [Python-Dev] what's dos-8x3/rfc822-n.py? Message-ID: <01a401bfe85a$0c1819f0$0900a8c0@SPIFF> more stupid questions: jeremy wrote: > rfc822-n.py > Log Message: > fix inconsistent use of tabs and spaces is that really a valid module name? shouldn't DOS users be able to use the standard rfc822 module? why are they different? (not sure, but the one in the dos-8x3 directory looks newer). (btw, why is there a Lib/dos-8x3 and a Lib/dos_8x3 directory in the repository?) From fredrik at pythonware.com Fri Jul 7 23:28:21 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 7 Jul 2000 23:28:21 +0200 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <200007072158.QAA05483@cj20424-a.reston1.va.home.com> Message-ID: <01b501bfe85a$475f6cc0$0900a8c0@SPIFF> guido wrote: > > The meaning of mixing both kinds of objects is very easy to explain, > > and also allows for efficient implementation - which you won't get if > > you have to invoke a character conversion just to get the hash value > > of a unicode value (!) > > I agree with this point. It can be implemented easily by deleting the > locale specific guessing from site.py. as an aside, Jack reported that: if u" " in tuple(string.whitespace): ... bombs on the macintosh (this is from SRE). the reason? the default encoding is set to "ascii", but C's isspace predicate thinks that some characters in the 128-255 range are whitespace characters. tricky. PS. I'll post the Windows get_locale code tomorrow. hopefully, Jack can whip up something similar for the Mac. From guido at beopen.com Sat Jul 8 00:36:00 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 17:36:00 -0500 Subject: [Python-Dev] what's dos-8x3/rfc822-n.py? In-Reply-To: Your message of "Fri, 07 Jul 2000 23:26:42 +0200." <01a401bfe85a$0c1819f0$0900a8c0@SPIFF> References: <01a401bfe85a$0c1819f0$0900a8c0@SPIFF> Message-ID: <200007072236.RAA05766@cj20424-a.reston1.va.home.com> > more stupid questions: > > jeremy wrote: > > > rfc822-n.py > > Log Message: > > fix inconsistent use of tabs and spaces > > is that really a valid module name? No -- my mistake. I'll delete it. > shouldn't DOS users be able to use the standard rfc822 > module? why are they different? (not sure, but the > one in the dos-8x3 directory looks newer). That's a red herring. > (btw, why is there a Lib/dos-8x3 and a Lib/dos_8x3 > directory in the repository?) The dos_8x3 one was a mistake, but CVS won't let you really delete directories. Use "cvs update -P" to delete empty directories. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Fri Jul 7 23:31:13 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 7 Jul 2000 16:31:13 -0500 (CDT) Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: References: Message-ID: <14694.19489.449195.619187@beluga.mojam.com> Ping> So "34"+0 converts to a number and 34."" converts to a string Ping> (i've seen both idioms fairly often). Halleluhah! Never thought I'd get Perl programming help here! We have this nagging problem with our XML-RPC stuff. When a band or venue name consisting of all digits (like "311") name comes into our concert database server from a Perl client, it comes in as a number instead of a string. The only workaround so far was to check at all server interfaces where this might occur and call str() when we found a number. Now it looks like I can toss the problem back into the client and save a few cpu cycles on the server (and more to the point, not pay the cost of the test all the time)... Ka-Ping> Anyway, i still agree that it's best to avoid automatic Ka-Ping> coercion between numbers and strings Amen to that! Skip From guido at beopen.com Sat Jul 8 00:41:57 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 07 Jul 2000 17:41:57 -0500 Subject: [Python-Dev] Python release delay Message-ID: <200007072241.RAA05873@cj20424-a.reston1.va.home.com> CNRI's Bob Kahn has this message for the Python user community: > "As a result of the recent transition of the Core Python development > activity from CNRI to BeOpen, a number of issues have arisen that CNRI and > BeOpen are in the process of working out. As soon as these are resolved, > which we hope will be very shortly, we plan to have the final version of > Python 1.6 available for download. We apologize for this delay, but > hopefully, it will not last long and will ultimately put the future python > evolution on a more solid foundation. In the meantime, BeOpen and CNRI will > also be working together on updates to the python.org website, and bug > reports, patches and other contributions to Python 1.6 should continue to > be submitted to CNRI following the procedures posted at the python.org site." --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Sat Jul 8 00:01:53 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 8 Jul 2000 00:01:53 +0200 Subject: [Python-Dev] Python release delay In-Reply-To: <200007072241.RAA05873@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 07, 2000 at 05:41:57PM -0500 References: <200007072241.RAA05873@cj20424-a.reston1.va.home.com> Message-ID: <20000708000153.J26534@xs4all.nl> On Fri, Jul 07, 2000 at 05:41:57PM -0500, Guido van Rossum wrote: > CNRI's Bob Kahn has this message for the Python user community: > > "As a result of the recent transition of the Core Python development > > activity from CNRI to BeOpen, a number of issues have arisen that CNRI and > > BeOpen are in the process of working out. As soon as these are resolved, > > which we hope will be very shortly, we plan to have the final version of > > Python 1.6 available for download. We apologize for this delay, but > > hopefully, it will not last long and will ultimately put the future python > > evolution on a more solid foundation. In the meantime, BeOpen and CNRI will > > also be working together on updates to the python.org website, and bug > > reports, patches and other contributions to Python 1.6 should continue to > > be submitted to CNRI following the procedures posted at the python.org site." Uuhmm... So... - The next version will be Python 1.6, not 2.0 - All patch submissions since PythonLabs started and everyone promptly forgot about the CNRI-required Disclaimer should be resubmitted with disclaimer (or perhaps disclaimer posted seperately) - This goes for all future versions of Python as well - CNRI, not Guido, BeOpen or PythonLabs , controls the future of Python, for everything from bugfixes to new features. When will we get your (Guido), PythonLabs' or BeOpen's official statement(s) on this ? :) Please-correct-me-if-I'm-wrong-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Sat Jul 8 00:07:48 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 18:07:48 -0400 (EDT) Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: <14694.19489.449195.619187@beluga.mojam.com> References: <14694.19489.449195.619187@beluga.mojam.com> Message-ID: <14694.21684.395468.753641@bitdiddle.concentric.net> >>>>> "SM" == Skip Montanaro writes: Ping> So "34"+0 converts to a number and 34."" converts to a string Ping> (i've seen both idioms fairly often). SM> Halleluhah! Never thought I'd get Perl programming help here! Talk about a low signal-to-noise ratio! You get insights into a lot more than Python on python-dev. Jeremy From pingster at ilm.com Sat Jul 8 00:26:13 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 7 Jul 2000 15:26:13 -0700 (PDT) Subject: [Python-Dev] urllib.browse() issues In-Reply-To: <20000707103308.8074FE2673@oratrix.oratrix.nl> Message-ID: On Fri, 7 Jul 2000, Jack Jansen wrote: > I would suggest not putting it into urllib but in a "launch" module. [...] > in a separate module it's probably easier to extend to to various > other things you might want to launch (fileviewers, editors, etc). Hmm, i rather like this idea. Actually, i like it enough to suggest that "launch" would be a good interface to external applications -- launch.filebrowser("/home") launch.webbrowser("http://www.python.org/", newwindow=1) launch.mailreader() launch.mailcomposer("python-dev at python.org", subject="Spam") launch.textviewer("README") launch.texteditor("spam.py") launch.shell("/usr") launch.remoteshell("unseen.python.org", port=23) On Unix this would take advantage of (and formalize) the PAGER, EDITOR, BROWSER, etc. environment variables; on Windows they could look at registry settings, and for Mac, they could use IC. The webbrowser() function would be based on ESR's webbrowser.py; the others shouldn't be too hard to toss off... -- ?!ng From jeremy at beopen.com Sat Jul 8 00:31:40 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 7 Jul 2000 18:31:40 -0400 (EDT) Subject: [Python-Dev] Python release delay In-Reply-To: <20000708000153.J26534@xs4all.nl> References: <200007072241.RAA05873@cj20424-a.reston1.va.home.com> <20000708000153.J26534@xs4all.nl> Message-ID: <14694.23116.916187.841812@bitdiddle.concentric.net> This isn't an official statement, but I hope it will clarify our plans and how they relate to CNRI's plans. CNRI plans to issue a 1.6 release. PythonLabs is still planning to issue a Python 2.0 release, almost surely following the 1.6 release. The current CVS repository contains what will be the 2.0 release. Please use the current mechanisms for contributing to our release -- the SF patch manager, the old Python bug database, etc. I'm not sure how you can contribute to Python 1.6, since CNRI is ultimately responsible for it. We will probably assist them, but I'm not sure how. You may want to inquire about the license that Python 1.6 will be released under. In the absence of a better place to direct inquires, you could try webmaster at python.org. This address will reach someone at CNRI, who can probably direct you to the right person. Jeremy From paul at prescod.net Sat Jul 8 01:04:20 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 07 Jul 2000 18:04:20 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <39661CAF.9252D734@prescod.net> <200007072102.QAA05114@cj20424-a.reston1.va.home.com> Message-ID: <396661F4.6541AB42@prescod.net> Guido van Rossum wrote: > > Really? Does 3+"" really convert the 3 to a string in Java? class foo{ void foo(){ System.err.println( 5+"" ); } } > > C++, depending on the type. Python's strictness > > about this issue has never caught a bug for me. It has only caused > > errors. > > Are you sure? This is the kind of error where you immediately see > what's wrong and move on to the next bug. I am sure that 99% of the time when I get an error message trying to add a string to something, it is because I expect the thing to be automatically coerced to the string. This probably comes from the other languages I have used. > > It's certainly caught errors for me, and especially when introducing Perl > programmers to Python, where "they expect" string+number to convert the > string to a number, apparently the opposite of the arbitrary choice Paul > prefers. > > It's ambiguous as hell -- screw it. I don't see the choice as arbitrary. Perl's choice is just insane. :) According to the definition used in Java, Javascript and C++ (sometimes) x+y If y is a string then x+y is well-defined no matter what the type of x or the content of y. Under the Perl definition, it totally depends on the type of y and the contents of x. Insane! I advocate special casing of strings (which are already special cased in various ways) whereas Perl special cases particular string values. Insane! -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From paul at prescod.net Sat Jul 8 01:24:13 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 07 Jul 2000 18:24:13 -0500 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> Message-ID: <3966669D.B436CD39@prescod.net> "Martin v. Loewis" wrote: > > > ... > >Only if the default encoding is ASCII. > > That is not my understanding of the agreement, and I think the whole > idea of a default encoding is a stupid one. Let me be more tactful and say that I am not really comfortable with my code changing behavior subtly because of an environment variable. A default encoding might be interesting at I/O boundaries like print, raw_input() and read(), but I would rather it didn't work pervasively through the code. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From paul at prescod.net Sat Jul 8 01:28:13 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 07 Jul 2000 18:28:13 -0500 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience References: Message-ID: <3966678D.677F199F@prescod.net> Ka-Ping Yee wrote: > > ... > > Anyway, i still agree that it's best to avoid automatic coercion > between numbers and strings -- since it's now very easy to say > int("3") as opposed to import string; string.atoi("3"), there's > really no excuse for not being explicit. I want to be clear that I'm not asking for automatic coercion between numbers and strings but rather automatic coercion of any type to string. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From thomas at xs4all.net Sat Jul 8 01:32:16 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 8 Jul 2000 01:32:16 +0200 Subject: [Python-Dev] [OffTopic] Re: Unicode experience In-Reply-To: <396661F4.6541AB42@prescod.net>; from paul@prescod.net on Fri, Jul 07, 2000 at 06:04:20PM -0500 References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <39661CAF.9252D734@prescod.net> <200007072102.QAA05114@cj20424-a.reston1.va.home.com> <396661F4.6541AB42@prescod.net> Message-ID: <20000708013216.M26534@xs4all.nl> On Fri, Jul 07, 2000 at 06:04:20PM -0500, Paul Prescod wrote: > According to the definition used in Java, Javascript and C++ (sometimes) > x+y > If y is a string then x+y is well-defined no matter what the type of x > or the content of y. The right hand side of the operation determines what the result is ? Somehow I find that confusing and counter-intuitive, but perhaps I'm too used to __add__ vs. __radd__ ;) Anyway, I've tried to learn C++ and Java both twice now, buying books by *good* authors (like Peter v/d Linden) and I still manage to run screaming after reading a single page of feature listings ;) > Under the Perl definition, it totally depends on the type of y and the > contents of x. Insane! Nono, absolutely not. Perl is weirdly-typed: the type is determined by the *operator*, not the operands. If you do '$x + $y', and both $x and $y are strings, they will both be converted to numbers (ending up 0 if it fails) and added as numbers, and the result is a number. (But since perl is weirdly-typed, if you need it to result in a string, the number will be converted to a string as necessary.) If you want string-concatenation, use '.', which will turn numbers into strings. But Perl wouldn't be Perl if it hadn't *some* exceptions to this kind of rule ;) '$x++', where $x is a string, can return a string. The 'string-auto-increment' operator is Magic(tm): if the string matches /^[a-zA-Z]*[0-9]*$/, that is, something like 'spam001', the ++ operator adds one to the number at the end of the string. so 'spam001' would become 'spam002'. If you do it to 'spam999', it'll be incremented to 'span000', 'spaz999' becomes 'spba000', and so on. However, Perl wouldn't be Perl if it hadn't some excpetion to *this* too ;) Well, not really an exception, but... The string *must* exactly match the regexp above, or the '++' operator will turn it into a number '1' instead. So your string cannot be '-spam01', or 'sp0m01', or anything like that. Rendering this magic behaviour pretty useless in general, because it's easier, more readable and less buggy to do the work the magic ++ does by hand. (We actually had some database 'corruption' in our old user-database because of this... a tool accepted a 'template' username and tried to create a specified number of accounts with a name in sequence to that template... The original code had a safeguard (the above regexp) but it got removed somehow, and eventually someone used a wrong template, and we ended up with accounts named '1' through '8' ;P) > I advocate special casing of strings (which are already special cased in > various ways) whereas Perl special cases particular string values. > Insane! Well, yes. But Perl special cases about everything and their dog. Not Good. (Okay, I promise to stay on-topic for a while now ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From DavidA at ActiveState.com Sat Jul 8 01:40:15 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 7 Jul 2000 16:40:15 -0700 (Pacific Daylight Time) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <14694.17186.868952.214837@anthem.concentric.net> Message-ID: > >>>>> "TP" == Tim Peters writes: > > >> I'll do a separate commit that just changes white space (and > >> possibly reflow some comments). > > TP> Bingo! > > TP> life-is-so-much-easier-when-you-don't-think-too-much-ly > TP> y'rs - tim > > Oh, and while you're at it, please untabify the file. I don't know if > your module has tabs in it, but if so please convert all tabs to > spaces. IMO, with the right python-mode settings, all of us using emacs should never have to have this discussion! (going to have to do something about that in Komodo ! =). --david From fdrake at beopen.com Sat Jul 8 01:49:20 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 7 Jul 2000 19:49:20 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: References: <14694.17186.868952.214837@anthem.concentric.net> Message-ID: <14694.27776.620365.621524@cj42289-a.reston1.va.home.com> David Ascher writes: > IMO, with the right python-mode settings, all of us using emacs should > never have to have this discussion! I people didn't screw up their settings we wouldn't! Barry: Perhaps the right solution is to hard-code python-mode to always set indent-tabs-mode to nil, the indentation to 4, and retabify when it loads a file? ;) Oh, and do it again when it saves, so nobody can screw up their modules. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sat Jul 8 01:48:04 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 7 Jul 2000 19:48:04 -0400 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: Message-ID: [David Ascher] > IMO, with the right python-mode settings, all of us using emacs should > never have to have this discussion! If Unix weenies would just *accept* the damned defaults, these discussions would never arise. You can tell a Unix user from across the room: they're the ones who attach leeches to their eyeballs and then complain about blurry vision . > (going to have to do something about that in Komodo ! =). Make it a Windows-only app. Windows users do whatever they're told, and then *pay* you, over & over, for punishing them . From pingster at ilm.com Sat Jul 8 01:59:16 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 7 Jul 2000 16:59:16 -0700 (PDT) Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: <3966678D.677F199F@prescod.net> Message-ID: On Fri, 7 Jul 2000, Paul Prescod wrote: > > I want to be clear that I'm not asking for automatic coercion between > numbers and strings but rather automatic coercion of any type to string. As it stands, with both 8-bit strings and Unicode strings, i think this would result in too much hidden complexity -- thinking about this can wait until we have only one string type. We could consider this after we unify strings, but even then it would take some arguing to convince me that automatic coercion is desirable. -- ?!ng From gstein at lyra.org Sat Jul 8 03:32:13 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 7 Jul 2000 18:32:13 -0700 Subject: [Python-Dev] Encodings In-Reply-To: <3966669D.B436CD39@prescod.net>; from paul@prescod.net on Fri, Jul 07, 2000 at 06:24:13PM -0500 References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> Message-ID: <20000707183213.P29590@lyra.org> On Fri, Jul 07, 2000 at 06:24:13PM -0500, Paul Prescod wrote: > "Martin v. Loewis" wrote: > > > > > ... > > >Only if the default encoding is ASCII. > > > > That is not my understanding of the agreement, and I think the whole > > idea of a default encoding is a stupid one. > > Let me be more tactful and say that I am not really comfortable with my > code changing behavior subtly because of an environment variable. A > default encoding might be interesting at I/O boundaries like print, > raw_input() and read(), but I would rather it didn't work pervasively > through the code. Agreed. When this whole thing started, I thought there was going to be a fixed default encoding. Then the "changeable default" snuck into the code under the guise of "experimental work". Now that changeable default seems ingrained into the code and is introducing exactly the problems that we feared last fall -- unpredictability. Please... toss the changeable default. If everybody knows the default encoding is "ascii" and they want something else, then they know what to do. But when the default can change, then it can't be relied on. The coder is going to have to do an explicit encoding anyways. So why have a default? Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Sat Jul 8 06:11:45 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 00:11:45 -0400 (EDT) Subject: [Python-Dev] HAVE_OLD_CPP and the token-pasting operator Message-ID: <14694.43521.924155.15736@cj42289-a.reston1.va.home.com> operator.c includes a couple of macros that are defined to either use the ANSI token-pasting operator (##) or the old /**/ trick. Since I know macros in other source files are just using the token-pasting operator, and I've not heard anyone scream, should I just remove the old style macros since we're requiring ANSI C now? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sat Jul 8 06:31:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 00:31:27 -0400 Subject: [Python-Dev] Include/pyport.h now exists Message-ID: Checkin comment below. Would someone who understands (& can test! I can't yet) autoconfig please follow up on the last part? The stuff I checked in "fails safe", i.e. the lack of autoconfig support should not cause problems on any of your platforms. figured-it-was-best-to-just-do-it-and-apologize-later-ly y'rs - tim Cray J90 fixes for long ints. This was a convenient excuse to create the pyport.h file recently discussed! Please use new Py_ARITHMETIC_RIGHT_SHIFT when right-shifting signed int and you *need* sign-extension. This is #define'd in pyport.h, keying off new config symbol SIGNED_RIGHT_SHIFT_ZERO_FILLS. If you're running on a platform that needs that symbol #define'd, the std tests never would have worked for you (in particular, at least test_long would have failed). The autoconfig stuff got added to Python after my Unix days, so I don't know how that works. Would someone please look into doing & testing an auto-config of the SIGNED_RIGHT_SHIFT_ZERO_FILLS symbol? It needs to be defined if & only if, e.g., (-1) >> 3 is not -1. From tim_one at email.msn.com Sat Jul 8 06:33:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 00:33:42 -0400 Subject: [Python-Dev] HAVE_OLD_CPP and the token-pasting operator In-Reply-To: <14694.43521.924155.15736@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > operator.c includes a couple of macros that are defined to either > use the ANSI token-pasting operator (##) or the old /**/ trick. Since > I know macros in other source files are just using the token-pasting > operator, and I've not heard anyone scream, should I just remove the > old style macros since we're requiring ANSI C now? Yes! We should at least pretend we're living in the 1900's by now . From tim_one at email.msn.com Sat Jul 8 09:01:37 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 03:01:37 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <200007062157.QAA01227@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > ... (Is a summary of these [C9X] names online somewhere?) ISO refuses to put current stds online, so I'll reword an anonymous source (shhh! & some of this may be a little out of date): Exact-width typedefs: int8_t int16_t int32_t int64_t uint8_t uint16_t uint32_t uint64_t It's allowed that a given platform not define *any* of these. Therefore portable code can never rely on having exactly N bits regardless of N. Minimum-width typedefs: int_least8_t int_least16_t int_least32_t int_least64_t uint_least8_t uint_least16_t uint_least32_t uint_least64_t *All* of these must be defined (so even teensy platforms have to fake at least 64 bits). Fastest minimum-width typedefs: int_fast8_t int_fast16_t int_fast32_t int_fast64_t uint_fast8_t uint_fast16_t uint_fast32_t uint_fast64_t All of these must exist. What's the difference between these and minimum-width? For example, on a Cray J90 the least8_t will be a char, but since the HW supports no byte operations, the fast8_t will likely be 64 bits wide. Pointer<->int casting intptr_t uintptr_t These are signed & unsigned int types such that a valid void* p can be cast to them and back again, yielding a result == p. Very curiously, the last draft std I saw allowed for neither to be defined! Fattest types intmax_t uintmax_t The biggest int type (note that this may be fatter than "long long"!). Must be defined. Limit macros The names of these match the regexp (re.VERBOSE): U? INT (8|16|32|64) _ (MIN|MAX) | U? INT_ (LEAST|FAST) (8|16|32|64) _ (MIN|MAX) | INTPTR_ (MIN|MAX) | UINTPTR_MAX | INTMAX_ (MIN|MAX) | UINTMAX_MAX Macros for literals The names match the regexp: U? INT (8|16|32|64) _C Each of these 8 macros takes an integer literal argument, and expands it to whatever gibberish the platform needs to make a valid literal of at least the specified width. Also INTMAX_C(lit) and UINTMAX_C(lit), to do likewise for the fattest type (intmax_t or uintmax_t) supported by the platform. Macros for format specifiers There are many dozens of these! They address the problem that it's great you can now ask for, e.g., an int_fast32_t, but you still have no idea how big it is so also no idea what to stick in printf or scanf formats to do correct I/O on values of that type. Other limits ptrdiff_t: PTRDIFF_MIN PTRDIFF_MAX sig_atomic_t: SIG_ATOMIC_MIN SIG_ATOMIC_MAX size_t: SIZE_MAX wchar_t: WCHAR_MIN WCHAR_MAX wint_t: WINT_MIN WINT_MAX I don't expect Python needs more than half a dozen of these, but haven't given it sufficient thought. If somebody else beats me to it, I would be pleased . the-very-need-for-names-like-intmax_max-is-a-strong-argument- for-euthanasia-ly y'rs - tim From tim_one at email.msn.com Sat Jul 8 09:09:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 03:09:36 -0400 Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: <20000708064203.D7FBC1CD45@dinsdale.python.org> Message-ID: [various patches from Fred Drake, w/ the comment > ANSI-fied sources, converted to four-space indentation. ] Fred, you appear to be 4-space indenting C source. Is that allowed? Last I think I heard, Guido was still clinging to his schizophrenia on this topic (4-space for .py and no hard tabs, 8-space for .c/.h and hard tabs). god-knows-i'd-like-'em-to-be-the-same-ly y'rs - tim From moshez at math.huji.ac.il Sat Jul 8 10:07:30 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 8 Jul 2000 11:07:30 +0300 (IDT) Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: Message-ID: On Sat, 8 Jul 2000, Tim Peters wrote: > [various patches from Fred Drake, w/ the comment > > ANSI-fied sources, converted to four-space indentation. > ] > > Fred, you appear to be 4-space indenting C source. Is that allowed? Last I > think I heard, Guido was still clinging to his schizophrenia on this topic > (4-space for .py and no hard tabs, 8-space for .c/.h and hard tabs). I have never seen a formal statement from Guido about it, but I always assumed Python's C sources are linux kernel style...No? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From thomas at xs4all.net Sat Jul 8 10:28:47 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 8 Jul 2000 10:28:47 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules linuxaudiodev.c,2.2,2.3 In-Reply-To: <200007080606.XAA22987@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Fri, Jul 07, 2000 at 11:06:01PM -0700 References: <200007080606.XAA22987@slayer.i.sourceforge.net> Message-ID: <20000708102847.N26534@xs4all.nl> On Fri, Jul 07, 2000 at 11:06:01PM -0700, Fred L. Drake wrote: > Modified Files: > linuxaudiodev.c > Log Message: > Add method names to PyArg_ParseTuple() calls for better error messages. > Convert to four-space indents. Aren't tabs preferred as C-source indents, instead of 4-spaces ? At least, that's what I see in Python/*.c and Object/*.c, but I only vaguely recall it from the style document... -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From ping at lfw.org Sat Jul 8 11:35:05 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sat, 8 Jul 2000 02:35:05 -0700 (PDT) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: <200007070034.CAA02914@python.inrialpes.fr> Message-ID: On Fri, 7 Jul 2000, Vladimir Marangozov wrote: > Okay. Since you've already altered the error list in errcode.h, > I think that the best thing to do is to re-introduce E_INDENT > but for the "missing indentation" case (reported to the user as > "expected an indented block"), then return E_INDENT from AddToken() > and revert back its signature. Thus all additional error cases you've > detected so far would be handled fine in pythonrun.c. I think i'd rather leave the patch as it is. I can see that what you're suggesting would eliminate the need for the expected_ret argument to PyParser_AddToken(), but i think there's more value in exposing the expected token to pythonrun -- it leaves open the possibility for further more detailed and helpful messages in the future, without having to create separate error codes for each. It seems right that these situations should fall under the E_SYNTAX error code (otherwise we'd have to say that E_SYNTAX means "syntax error except for missing-indentation errors" etc.). E_SYNTAX is the general error code for "we got a token but the parser wouldn't accept it". (E_TABSPACE, E_TOODEEP, and E_DEDENT are errors at the token level.) And i don't see a lot of motivation to *avoid* passing back the expected token. There isn't anyone else depending on the interface to PyParser_AddToken (parser.h is a private header file). Hmm. Is that sufficiently convincing? -- ?!ng "To be human is to continually change. Your desire to remain as you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From Vladimir.Marangozov at inrialpes.fr Sat Jul 8 11:43:41 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 8 Jul 2000 11:43:41 +0200 (CEST) Subject: [Python-Dev] Better SyntaxError messages In-Reply-To: from "Ka-Ping Yee" at Jul 08, 2000 02:35:05 AM Message-ID: <200007080943.LAA09790@python.inrialpes.fr> Ka-Ping Yee wrote: > > And i don't see a lot of motivation to *avoid* passing back the > expected token. There isn't anyone else depending on the interface > to PyParser_AddToken (parser.h is a private header file). > > Hmm. Is that sufficiently convincing? Yes. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Sat Jul 8 11:55:07 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 8 Jul 2000 02:55:07 -0700 Subject: [Python-Dev] CVS: python/dist/src/Include pyport.h,NONE,2.1 Python.h,2.21,2.22 longintrepr.h,2.8,2.9 In-Reply-To: <200007080417.VAA05755@slayer.i.sourceforge.net>; from tim_one@users.sourceforge.net on Fri, Jul 07, 2000 at 09:17:24PM -0700 References: <200007080417.VAA05755@slayer.i.sourceforge.net> Message-ID: <20000708025506.A29590@lyra.org> On Fri, Jul 07, 2000 at 09:17:24PM -0700, Tim Peters wrote: >... > #ifndef Py_PYPORT_H > #define Py_PYPORT_H 1 > > /************************************************************************** > Symbols and macros to supply platform-independent interfaces to basic > C-language operations whose spellings vary across platforms. > > Please try to make documentation here as clear as possible: by definition, > the stuff here is trying to illuminate C's darkest corners. > > Config #defines referenced here: > > SIGNED_RIGHT_SHIFT_ZERO_FILLS > Meaning: To be defined iff i>>j does not extend the sign bit when i is a > signed integral type and i < 0. > Used in: Py_ARITHMETIC_RIGHT_SHIFT > **************************************************************************/ Note that it would be nice for pyport.h to *also* contain all the Include/my* stuff. i.e. it isn't just about C-language operations, but also about the (un)available libraries. IOW, stop the propagation of my* and drop those tweaky things into pyport. Cheers, -g -- Greg Stein, http://www.lyra.org/ From skip at mojam.com Sat Jul 8 12:32:40 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 8 Jul 2000 05:32:40 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> References: <14691.49563.78765.683762@beluga.mojam.com> <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> Message-ID: <14695.840.448508.397722@beluga.mojam.com> Regarding list comprehensions I recently proposed this as a possible option: >> * bundle up another patch for people to examine and comment on to which Fredrik replied /F> I'd vote for [that] Since Fredrik's voice is the only one I heard, and on the off-chance that the CNRI/BeOpen discussions and resulting 1.6 release push things out a bit (allowing a feature thaw) I'll oblige. The attached patch to add list comprehensions affects the following files: Doc/ref/ref5.tex Doc/tut/tut.tex Grammar/Grammar Include/graminit.h Lib/test/test_grammar.py Lib/test/output/test_grammar Python/compile.c Python/graminit.c About half the patch is the change to the (generated) graminit.c. The rest is actually fairly simple. i-really-hate-seeing-those-M's-when-i-cvs-update-ly y'rs, Skip -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: listcomp.patch URL: From effbot at telia.com Sat Jul 8 15:01:21 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 15:01:21 +0200 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe References: <000001bfe79d$ac720ae0$060210ac@private> Message-ID: <005801bfe8dc$9ef3f320$f2a6b5d4@hagrid> barry scott wrote: > os.popen fails to work if pythonw.exe is used to start python. This is > true for 1.5.2 and 1.6a2. > > The root cause of the problem is in the Microsoft C RTL implementation > of _popen(). _popen() will fail if there is not a valid file descriptor > for stdin or stdout. > > The following replacement for WinMain.c works around the problem. > I also ensure a valid descriptor for stderr for completeness. > > This was compiled and test under VC++ 6.0 SP3 on Windows 2000. +1 from me. unless mark|bill|trent|.+ objects, I'll check it in later. cheers /F PS. I've uploaded it to the SF patch manager: http://sourceforge.net/patch/index.php?patch_id=100764&group_id=5470 From gstein at lyra.org Sat Jul 8 15:14:18 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 8 Jul 2000 06:14:18 -0700 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe In-Reply-To: <005801bfe8dc$9ef3f320$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jul 08, 2000 at 03:01:21PM +0200 References: <000001bfe79d$ac720ae0$060210ac@private> <005801bfe8dc$9ef3f320$f2a6b5d4@hagrid> Message-ID: <20000708061417.E29590@lyra.org> Bill has done a ton of stuff with popen() on Windows. I'm CC'ing him to make sure that he sees this. Cheers, -g On Sat, Jul 08, 2000 at 03:01:21PM +0200, Fredrik Lundh wrote: > barry scott wrote: > > os.popen fails to work if pythonw.exe is used to start python. This is > > true for 1.5.2 and 1.6a2. > > > > The root cause of the problem is in the Microsoft C RTL implementation > > of _popen(). _popen() will fail if there is not a valid file descriptor > > for stdin or stdout. > > > > The following replacement for WinMain.c works around the problem. > > I also ensure a valid descriptor for stderr for completeness. > > > > This was compiled and test under VC++ 6.0 SP3 on Windows 2000. > > +1 from me. > > unless mark|bill|trent|.+ objects, I'll check it in later. > > cheers /F > > PS. I've uploaded it to the SF patch manager: > http://sourceforge.net/patch/index.php?patch_id=100764&group_id=5470 > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Sat Jul 8 15:29:34 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 09:29:34 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: References: <200007062157.QAA01227@cj20424-a.reston1.va.home.com> Message-ID: <14695.11454.283571.492775@cj42289-a.reston1.va.home.com> Tim Peters writes: > ISO refuses to put current stds online, so I'll reword an anonymous source > (shhh! & some of this may be a little out of date): The URL I posted has a pointer to a copy of the "Final Committee Draft," which is probably sufficient. PDF and PostScript were both available. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Sat Jul 8 15:32:55 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 09:32:55 -0400 (EDT) Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: References: <20000708064203.D7FBC1CD45@dinsdale.python.org> Message-ID: <14695.11655.433199.734714@cj42289-a.reston1.va.home.com> Tim Peters writes: > Fred, you appear to be 4-space indenting C source. Is that allowed? Last I > think I heard, Guido was still clinging to his schizophrenia on this topic > (4-space for .py and no hard tabs, 8-space for .c/.h and hard tabs). I seem to recall that Guido had caved on this, mostly because he received enough complaints about too much code getting shoved way over to the right, in a column a dozen of fewer characters wide (which is seriously hard to decode). I don't remember if this was on the list or in a meeting. If I'm mis-remembering, then we should presure him on this until he does cave. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Sat Jul 8 15:32:03 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 08 Jul 2000 08:32:03 -0500 Subject: [Python-Dev] String coercion References: <3965BBE5.D67DD838@lemburg.com> <200007071244.HAA03694@cj20424-a.reston1.va.home.com> <39661CAF.9252D734@prescod.net> <200007072102.QAA05114@cj20424-a.reston1.va.home.com> <396661F4.6541AB42@prescod.net> <20000708013216.M26534@xs4all.nl> Message-ID: <39672D53.899D4BEB@prescod.net> Thomas Wouters wrote: > > ... > > The right hand side of the operation determines what the result is ? No, either side determines what the result is. This is not magic. It's just like floating point coercion or complex number coercion. > Somehow > I find that confusing and counter-intuitive, but perhaps I'm too used to > __add__ vs. __radd__ ;) This can be easily defined in terms of add and radd: class PaulsString: def __init__( self, str ): self.str=str def __add__( self, foo ): return self.str + str( foo ) def __radd__( self, bar ): return str( bar ) + self.str print PaulsString("abcdef")+5 print open+PaulsString("ghijkl") abcdef5 ghijkl Here's an even simpler definition: class PaulsString: def __init__( self, str ): self.str=str def __coerce__( self, other ): return (self.str, str( other )) Ping says: > As it stands, with both 8-bit strings and Unicode strings, i think > this would result in too much hidden complexity -- thinking about this > can wait until we have only one string type. I don't see any hidden complexity. Python has features specifically designed to allow this sort of thing on a per-type basis. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From guido at beopen.com Sat Jul 8 16:34:14 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 09:34:14 -0500 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe In-Reply-To: Your message of "Thu, 06 Jul 2000 23:58:17 +0100." <000001bfe79d$ac720ae0$060210ac@private> References: <000001bfe79d$ac720ae0$060210ac@private> Message-ID: <200007081434.JAA07087@cj20424-a.reston1.va.home.com> > os.popen fails to work if pythonw.exe is used to start python. This is > true for 1.5.2 and 1.6a2. > > The root cause of the problem is in the Microsoft C RTL implementation > of _popen(). _popen() will fail if there is not a valid file descriptor > for stdin or stdout. > > The following replacement for WinMain.c works around the problem. > I also ensure a valid descriptor for stderr for completeness. > > This was compiled and test under VC++ 6.0 SP3 on Windows 2000. Let's also test it on Windows 98, 95 and NT. If it works for all, I'm +1. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Sat Jul 8 15:35:08 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 09:35:08 -0400 (EDT) Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: References: Message-ID: <14695.11788.491744.539193@cj42289-a.reston1.va.home.com> Moshe Zadka writes: > I have never seen a formal statement from Guido about it, but I always > assumed Python's C sources are linux kernel style...No? Python's sources are Guido's style. Any similarities with the Linux kernel are coincidental. I've seen a comparison, but don't remember much about it. Most developers don't even know where to look to find out the rules for Linux kernel style. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Sat Jul 8 16:39:51 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 09:39:51 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules linuxaudiodev.c,2.2,2.3 In-Reply-To: Your message of "Sat, 08 Jul 2000 10:28:47 +0200." <20000708102847.N26534@xs4all.nl> References: <200007080606.XAA22987@slayer.i.sourceforge.net> <20000708102847.N26534@xs4all.nl> Message-ID: <200007081439.JAA07139@cj20424-a.reston1.va.home.com> > Aren't tabs preferred as C-source indents, instead of 4-spaces ? At least, > that's what I see in Python/*.c and Object/*.c, but I only vaguely recall it > from the style document... Yes, you're right. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From effbot at telia.com Sat Jul 8 15:46:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 15:46:05 +0200 Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs References: <20000708064203.D7FBC1CD45@dinsdale.python.org> <14695.11655.433199.734714@cj42289-a.reston1.va.home.com> Message-ID: <039f01bfe8e2$deb32ac0$f2a6b5d4@hagrid> fred wrote: > Tim Peters writes: > > Fred, you appear to be 4-space indenting C source. Is that allowed? Last I > > think I heard, Guido was still clinging to his schizophrenia on this topic > > (4-space for .py and no hard tabs, 8-space for .c/.h and hard tabs). > > I seem to recall that Guido had caved on this, mostly because he > received enough complaints about too much code getting shoved way over > to the right, in a column a dozen of fewer characters wide (which is > seriously hard to decode). I don't remember if this was on the list > or in a meeting. > If I'm mis-remembering, then we should presure him on this until he > does cave. ;) guido? I think we need an official BDFL statement here... From guido at beopen.com Sat Jul 8 17:08:48 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 10:08:48 -0500 Subject: [Python-Dev] Encodings In-Reply-To: Your message of "Fri, 07 Jul 2000 18:32:13 MST." <20000707183213.P29590@lyra.org> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> Message-ID: <200007081508.KAA07351@cj20424-a.reston1.va.home.com> > Please... toss the changeable default. If everybody knows the default > encoding is "ascii" and they want something else, then they know what to do. > But when the default can change, then it can't be relied on. The coder is > going to have to do an explicit encoding anyways. So why have a default? I couldn't have said it better. It's okay for now to have it changeable at the C level -- with endless caveats that it should be set only once before any use, and marked as an experimental feature. But the Python access and the reliance on the environment should go. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Sat Jul 8 17:14:06 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 10:14:06 -0500 Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: Your message of "Fri, 07 Jul 2000 19:49:20 -0400." <14694.27776.620365.621524@cj42289-a.reston1.va.home.com> References: <14694.17186.868952.214837@anthem.concentric.net> <14694.27776.620365.621524@cj42289-a.reston1.va.home.com> Message-ID: <200007081514.KAA07398@cj20424-a.reston1.va.home.com> > Barry: Perhaps the right solution is to hard-code python-mode to > always set indent-tabs-mode to nil, the indentation to 4, and retabify > when it loads a file? ;) Oh, and do it again when it saves, so > nobody can screw up their modules. ;) That would be fine if it weren't for triple-quoted strings... At the very least someone should run Lib/tabnanny.py on the Lib tree and fix all complaints! There are still complaints about mailbox.py and shlex.py. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Sat Jul 8 16:26:27 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 10:26:27 -0400 (EDT) Subject: [Python-Dev] where did httplib.HTTPS go? In-Reply-To: <200007081514.KAA07398@cj20424-a.reston1.va.home.com> References: <14694.17186.868952.214837@anthem.concentric.net> <14694.27776.620365.621524@cj42289-a.reston1.va.home.com> <200007081514.KAA07398@cj20424-a.reston1.va.home.com> Message-ID: <14695.14867.517707.59800@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > At the very least someone should run Lib/tabnanny.py on the Lib tree > and fix all complaints! There are still complaints about mailbox.py > and shlex.py. I'll do this. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Sat Jul 8 17:00:33 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sat, 8 Jul 2000 11:00:33 -0400 (EDT) Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs References: <20000708064203.D7FBC1CD45@dinsdale.python.org> Message-ID: <14695.16913.984694.3842@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> Fred, you appear to be 4-space indenting C source. Is that TP> allowed? Last I think I heard, Guido was still clinging to TP> his schizophrenia on this topic (4-space for .py and no hard TP> tabs, 8-space for .c/.h and hard tabs). Emacs CC Mode has a "python" style which defines 8-space hard-tab indentation. This was the blessed style for Python's C code. I distinctly remember Guido agreeing to 4 space indents for Python 1.7 (or new code) but that it wasn't worth going back and changing existing code at this time. If Fred's doing a code cleansing then it's probably okay that he also adjust the indentation. Most important is consistency within the file. -Barry From tim_one at email.msn.com Sat Jul 8 17:17:49 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 11:17:49 -0400 Subject: [Python-Dev] CVS: python/dist/src/Include pyport.h ... In-Reply-To: <20000708025506.A29590@lyra.org> Message-ID: [Greg Stein] > Note that it would be nice for pyport.h to *also* contain all the > Include/my* stuff. i.e. it isn't just about C-language > operations, but also about the (un)available libraries. > > IOW, stop the propagation of my* and drop those tweaky things > into pyport. Sounds good to me, but I'm not going to make A Project out of that for myself. Kinda like getting rid of Py_PROTO and ANSI-fying, I'm just going to chip away at it as it's convenient when working on other things. pyproto.h isn't "my" file! Everyone have at it. best-way-to-get-everyone-on-the-same-page-is-to-have-everyone- write-part-of-it-ly y'rs - tim From tim_one at email.msn.com Sat Jul 8 17:29:06 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 11:29:06 -0400 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe In-Reply-To: <005801bfe8dc$9ef3f320$f2a6b5d4@hagrid> Message-ID: [/F] > +1 from me. > > unless mark|bill|trent|.+ objects, I'll check it in later. > > cheers /F > > PS. I've uploaded it to the SF patch manager: > http://sourceforge.net/patch/index.php?patch_id=100764&group_id=5470 Where I assigned it to you, but didn't accept it for sytle reasons: Assigned to effbot. I would have changed the status to accepted, except the coding style is one Guido won't accept: uses C++ comments in places, "if" braces in the wrong places, "extra" whitespace at each end of arglists, "if(" instead of "if (". I expect that arguing about style is futile. not-to-mention-a-waste-of-time-ly y'rs - tim From paul at prescod.net Sat Jul 8 17:34:16 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 08 Jul 2000 10:34:16 -0500 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] Message-ID: <396749F8.F98D2F8C@prescod.net> For those that don't read comp.lang.python. -------- Original Message -------- Subject: Re: Splitting c.l.py... Date: Sat, 08 Jul 2000 03:52:44 GMT From: "Neil Hodgson" Organization: BigPond Internet Services (http://www.bigpond.net.au) To: python-list at python.org Newsgroups: comp.lang.python References: <3dituj9cdi.fsf at kronos.cnri.reston.va.us> <39661DE1.A409330C at roguewave.com> <20000707140442.B4771 at kronos.cnri.reston.va.us> > Beats me. Hmm... here's a possibility: ... Essentially the newsgroup would > be a read-only view of the python-dev mailing list. But would it be of interest to anyone? python-dev has a much worse signal-to-noise ratio than comp.lang.python IMHO. One morning this week I opened up my mailer in the morning to see over 100 messages in python-dev and less than 80 in c.l.py. The traffic in python-dev alternates between checkin chat (there's a CVS lock here, that patch breaks on X, when will you finish Y?) and language/library design issues. I can see a reason for some of the detailed design issues to be decided on the same forum as the checkin chat with a limited group of people, but some of the larger issues should be debated in a wider forum. Was there any reason for "urllib.browse() issues" to be on python-dev? Possibly comp.lang.python is also a bad forum for discussing future changes to Python and should concentrate on solving peoples current problems and avoiding long winded discussions on new functionality. So a comp.lang.python.future (or similar mailing list) could provide a way for /all/ Pythoneers to be involved in the evolution of the language. Neil -- http://www.python.org/mailman/listinfo/python-list From tim_one at email.msn.com Sat Jul 8 17:36:32 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 11:36:32 -0400 Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: <14695.11655.433199.734714@cj42289-a.reston1.va.home.com> Message-ID: [Tim] > Fred, you appear to be 4-space indenting C source. Is that > allowed? Last I think I heard, Guido was still clinging to > his schizophrenia on this topic (4-space for .py and no hard > tabs, 8-space for .c/.h and hard tabs). [Fred] > I seem to recall that Guido had caved on this, mostly because he > received enough complaints about too much code getting shoved way over > to the right, in a column a dozen of fewer characters wide (which is > seriously hard to decode). I don't remember if this was on the list > or in a meeting. > If I'm mis-remembering, then we should presure him on this until he > does cave. ;) Guido, you need to Pronounce on this! I personally prefer 4-space no-hard-tabs everywhere, but given the way most editors work, the most important thing is that there's no variation within a given file type (e.g., that all .c files do the same, and all .py files do the same, but it's bearable for .c and .py files to differ -- which latter has been the case until now). From petersc at stud.ntnu.no Sat Jul 8 19:39:55 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Sat, 08 Jul 2000 17:39:55 +0000 Subject: indentation in .c files (was Re: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules linuxaudiodev.c,2.2,2.3) Message-ID: <3967676B.41E1CC5C@stud.ntnu.no> [Guido on a mail from Thomas Wouters] > > > Aren't tabs preferred as C-source indents, instead of 4-spaces ? At least, > > that's what I see in Python/*.c and Object/*.c, but I only vaguely recall it > > from the style document... > > Yes, you're right. Does that mean I should load up a revised version of my ANSI-fying patches for posixmodule and mmapmodule? Assuming Fred knew what he did, I also changed to -s 4 -t 8 ... Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From fdrake at beopen.com Sat Jul 8 18:01:39 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 12:01:39 -0400 (EDT) Subject: indentation in .c files (was Re: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules linuxaudiodev.c,2.2,2.3) In-Reply-To: <3967676B.41E1CC5C@stud.ntnu.no> References: <3967676B.41E1CC5C@stud.ntnu.no> Message-ID: <14695.20579.776070.898183@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > Does that mean I should load up a revised version of my > ANSI-fying patches for posixmodule and mmapmodule? ANSI-fication is clearly good. Whether or not 4-space indents go in is appearantly dependent on who checks in the patch. So leave them in if you've already done the work. ;) > Assuming Fred knew what he did, I also changed to -s 4 -t 8 ... Now, if we could get the rest of PythonLabs to make that assumption, we'd be in pretty good shape! ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Sat Jul 8 18:05:16 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 08 Jul 2000 18:05:16 +0200 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> Message-ID: <3967513C.BAF459FB@lemburg.com> Guido van Rossum wrote: > > > Please... toss the changeable default. If everybody knows the default > > encoding is "ascii" and they want something else, then they know what to do. > > But when the default can change, then it can't be relied on. The coder is > > going to have to do an explicit encoding anyways. So why have a default? > > I couldn't have said it better. It's okay for now to have it > changeable at the C level -- with endless caveats that it should be > set only once before any use, and marked as an experimental feature. > But the Python access and the reliance on the environment should go. Sorry, but I'm really surprised now: I've put many hours of work into this, hacked up encoding support for locale.py, went through endless discussions, proposed the changable default as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy ... and now all it takes is one single posting to render all that work useless ??? Instead of tossing things we should be *constructive* and come up with a solution to the hash value problem, e.g. I would like to make the hash value be calculated from the UTF-16 value in a way that is compatible with ASCII strings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Sat Jul 8 18:13:12 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 12:13:12 -0400 (EDT) Subject: [Python-Dev] SourceForge administration Message-ID: <14695.21272.269311.720751@cj42289-a.reston1.va.home.com> I was just browsing the SourceForge support requests, and it looks like no CVS-related requests have been dealt with for about 48 hours. So it's not that they're ignoring us, it's that they're ignoring support requests. If anyone knows anyone there, can ou ping them and ask if the company picnic has been going on all this time? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Sat Jul 8 18:24:08 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 12:24:08 -0400 (EDT) Subject: [Python-Dev] Encodings In-Reply-To: <3967513C.BAF459FB@lemburg.com> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> Message-ID: <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Sorry, but I'm really surprised now: I've put many hours of > work into this, hacked up encoding support for locale.py, > went through endless discussions, proposed the changable default > as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy My recollection was that the purpose of the changable default was so that we could experiment with different defaults more easily, not that we'd keep it changable. I'm not an expert on these issues and have tried to stay out of the way on the discussion, but the idea of a changable default just seems like we're asking for trouble. I'm sorry that you feel your efforts have been wasted; I don't think anyone tried to spend your time without careful consideration, but it is important that we all understand what we have gained from this experiment. Before you implemented the changable default, we all had the opportunity to presume to know how things would work with it, and could bitch or plead about it as we felt appropriate. Now that it's been tried, we have a little more real experiance with it, and can point to the evidence that's been presented here as we each make our arguments on the topic. So I'd have to say that your efforts have *not* been wasted; we now have a very good idea of what's involved and whether "it works." I, for one, am glad that the experiment was done (and expecially that it was done by someone who knows more about this than me!). > Instead of tossing things we should be *constructive* and come > up with a solution to the hash value problem, e.g. I would > like to make the hash value be calculated from the UTF-16 > value in a way that is compatible with ASCII strings. This may be the right thing for the hash value; I don't know. But I think this is in some ways separate from the changable defaults question. This approach can be taken for getting hash values right without having a changable default encoding. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From effbot at telia.com Sat Jul 8 18:45:07 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 18:45:07 +0200 Subject: [Python-Dev] SRE's match objects are missing .regs ?! References: <396478D8.26CBD0FA@lemburg.com> <20000706083223.A29375@newcnri.cnri.reston.va.us> Message-ID: <002a01bfe8fb$e0834d80$f2a6b5d4@hagrid> amk wrote: > .regs was never documented in the library reference, nor in the > docstrings in libre.tex; it was an underlying implementation detail > some people happened to take advantage of. If /F wants to add it in > order to be nice, fine; I certainly wouldn't bother to do that. I'm feel nice today. it'll be in the next release. From tim_one at email.msn.com Sat Jul 8 19:02:06 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 13:02:06 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: <14695.11454.283571.492775@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > The URL I posted has a pointer to a copy of the "Final Committee > Draft," [for C9X] which is probably sufficient. PDF and PostScript > were both available. Worth repeating: http://lglwww.epfl.ch/~wolf/c/c9x_changes.html PDF and plain-text versions can be gotten from http://wwwold.dkuug.dk/jtc1/sc22/open/n2794/ These are much better than the things I was working from (don't tell, but since I knew some of the people on the committee, I went rummaging around their home pages looking for committee working docs). "whatever-it-takes"-is-pythonic-ly y'rs - tim From paul at prescod.net Sat Jul 8 19:01:24 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 08 Jul 2000 12:01:24 -0500 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> Message-ID: <39675E64.305A6B8@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Sorry, but I'm really surprised now: I've put many hours of > work into this, hacked up encoding support for locale.py, > went through endless discussions, proposed the changable default > as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy > ... and now all it takes is one single posting to render all that > work useless ??? I thought that the compromise was ASCII. Having the default be changable could lead to defacto forks in that language. I, for one, am sorry I didn't say something earlier but as Greg said, the changable default sort of drifted from something that was useful for testing to something we started making design decisions based upon. I thought I had missed a decision somewhere along the line to make it a permanent feature. Also, as I said, a changable default is probably worth considering for I/O boundaries. If 90% of the text on a Japanese user's computer is in Shift-JIS, then things like .rc and .ini files should be in that encoding. Or they could be in XML and the XML parser could handle encoding issues for you... Here's the central point: How can we write code if we don't know whether "..."+u"..." is going to trigger a UnicodeException because of some environment variable a user has set? To be safe, we need to specify the encoding explicitly....which renders auto-coercion useless. I am trying to be constructive, but I see the hash value problem as being unrelated to this very basic point. First and foremost, coercion has to be predictable. -- Paul Prescod - Not encumbered by corporate consensus Pop stars come and pop stars go, but amid all this change there is one eternal truth: Whenever Bob Dylan writes a song about a guy, the guy is guilty as sin. - http://www.nj.com/page1/ledger/e2efc7.html From fdrake at beopen.com Sat Jul 8 19:11:03 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 13:11:03 -0400 (EDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: References: <14695.11454.283571.492775@cj42289-a.reston1.va.home.com> Message-ID: <14695.24743.906316.151151@cj42289-a.reston1.va.home.com> Tim Peters writes: > Worth repeating: > > http://lglwww.epfl.ch/~wolf/c/c9x_changes.html ... > These are much better than the things I was working from (don't tell, but > since I knew some of the people on the committee, I went rummaging around > their home pages looking for committee working docs). And to think that first link was just the first thing that Google listed. ;) It is nice -- I found that before and it was nicer than a lot of the other C9X pages I looked at. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gmcm at hypernet.com Sat Jul 8 19:19:13 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 8 Jul 2000 13:19:13 -0400 Subject: [Python-Dev] C coding style In-Reply-To: References: <14695.11655.433199.734714@cj42289-a.reston1.va.home.com> Message-ID: <1249045739-16239476@hypernet.com> > [Tim] > > Fred, you appear to be 4-space indenting C source. Is that > > allowed? Last I think I heard, Guido was still clinging to his > > schizophrenia on this topic (4-space for .py and no hard tabs, > > 8-space for .c/.h and hard tabs). Blah blah blah. Jeez, guys. The following options will make indent produce something that's so close to Guido's style, he'd probably never notice that it's not exactly his style: -br -bap -nce -ss -i8 -ci8 -lp -ts8 -psl -npcs -nbc -ip8 -ncs -nfca why-be-anal-when-the-computer-can-do-it-for-you-ly y'rs - Gordon From petersc at stud.ntnu.no Sat Jul 8 21:27:50 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Sat, 08 Jul 2000 19:27:50 +0000 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix Message-ID: <396780B6.67247E2C@stud.ntnu.no> I am trying to fix the duplicate argument bug in the compiler. [example] >>> def f(a,a): print a ... >>> f(1,2) 2 [/example] My problem is that I get a segfault whenever I try to raise an com_error from com_arglist. I have attached a very short patch. Thanks for any hint, Peter P.S.: Is this on topic for python-dev? If not, where should I send such a request? -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de -------------- next part -------------- diff -c -d -T --recursive python/dist/src/Python/compile.c python-mod/dist/src/Python/compile.c *** python/dist/src/Python/compile.c Mon Jul 3 21:39:47 2000 --- python-mod/dist/src/Python/compile.c Sat Jul 8 19:13:42 2000 *************** *** 3102,3109 **** name = nbuf; sprintf(nbuf, ".%d", i); complex = 1; } ! com_newlocal(c, name); c->c_argcount++; if (++i >= nch) break; --- 3103,3120 ---- name = nbuf; sprintf(nbuf, ".%d", i); complex = 1; + } + + nameval = PyString_InternFromString(name); + if (nameval == NULL) { + c->c_errors++; } ! if (PyDict_GetItem(c->c_locals, nameval)) { ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); ! } ! com_newlocal_o(c, nameval); ! Py_DECREF(nameval); ! c->c_argcount++; if (++i >= nch) break; From fdrake at beopen.com Sat Jul 8 19:37:21 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 13:37:21 -0400 (EDT) Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix In-Reply-To: <396780B6.67247E2C@stud.ntnu.no> References: <396780B6.67247E2C@stud.ntnu.no> Message-ID: <14695.26321.650518.552363@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > P.S.: Is this on topic for python-dev? If not, where should > I send such a request? *I* think this is a good place for this. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From effbot at telia.com Sat Jul 8 21:12:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 21:12:45 +0200 Subject: [Python-Dev] changing the locale.py interface? Message-ID: <00c901bfe910$836758c0$f2a6b5d4@hagrid> http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100765&group_id=5470 Patch #100765 tightens up the new parts of the locale.py interface, and adds support for platform-dependent locale mechanisms. Here's a summary of the changes: - merged setlocale and set_locale. the internal setlocale function is overridden by a python version which accepts *either* a string (old behaviour) or a locale tuple. - renamed a few methods (for consistency): get_locale => getlocale get_default_locale => getdefaultlocale set_to_default => resetlocale (!) - the _locale implementation module can now implement an optional _getdefaultlocale function. if that function isn't available, a POSIX-based approach is used (check LANG and other environment variables). comments? From thomas at xs4all.net Sat Jul 8 21:21:50 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 8 Jul 2000 21:21:50 +0200 Subject: [Python-Dev] Include/pyport.h now exists In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 08, 2000 at 12:31:27AM -0400 References: Message-ID: <20000708212149.P26534@xs4all.nl> On Sat, Jul 08, 2000 at 12:31:27AM -0400, Tim Peters wrote: > Would someone who understands (& can test! I can't yet) autoconfig please > follow up on the last part? The stuff I checked in "fails safe", i.e. the > lack of autoconfig support should not cause problems on any of your > platforms. Can't say I understand all of autoconf but I read enough of the info pages to be able to do this ! :-) I couldn't find an existing test that covers this, so I used your example to make one; patch attached. It detects my linux box properly as 'doesn't zero-fill when right-shifting a negative number', but I haven't a Cray J90 handy to test the opposite ;) Feel free to change the wording to something a bit less... wordy, though ;) Oh, and don't forget to run autoheader & automake before checking in. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- *** src-lm+rm/configure.in Wed Jul 5 12:38:09 2000 --- src/configure.in Sat Jul 8 20:18:35 2000 *************** *** 1136,1141 **** --- 1136,1154 ---- # check for endianness AC_C_BIGENDIAN + # Check whether signed-right-shift fills the left hand bits with the sign + # bit, or with zero (like the Cray J90 does, according to Tim Peters.) + signed_rshift_0fills="unknown" + AC_MSG_CHECKING(whether right-shift of negative number pads with zeros) + AC_TRY_RUN([ + int main() + { + exit(((-1)>>3 == -1) ? 1 : 0); + } + ],AC_DEFINE(SIGNED_RIGHT_SHIFT_ZERO_FILLS) signed_rshift_0fills="yes", + signed_rshift_0fills="no") + AC_MSG_RESULT($signed_rshift_0fills) + # THIS MUST BE LAST, IT CAN BREAK OTHER TESTS! # Add sys/socket.h to confdefs.h cat >> confdefs.h <<\EOF From barry at scottb.demon.co.uk Sat Jul 8 21:31:37 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sat, 8 Jul 2000 20:31:37 +0100 Subject: [Python-Dev] Fix to allow os.popen to work from pythonw.exe In-Reply-To: Message-ID: <000801bfe913$224c9d40$060210ac@private> The C++ comments are in the original source. I'm happy to use any style if that makes it easier to get patches accepted. BArry > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Tim Peters > Sent: 08 July 2000 16:29 > To: Fredrik Lundh; Barry Scott; PythonDev > Subject: RE: [Python-Dev] Fix to allow os.popen to work from pythonw.exe > > > [/F] > > +1 from me. > > > > unless mark|bill|trent|.+ objects, I'll check it in later. > > > > cheers /F > > > > PS. I've uploaded it to the SF patch manager: > > http://sourceforge.net/patch/index.php?patch_id=100764&group_id=5470 > > Where I assigned it to you, but didn't accept it for sytle reasons: > > Assigned to effbot. I would have changed the status to > accepted, except the coding style is one Guido won't accept: > uses C++ comments in places, "if" braces in the wrong places, > "extra" whitespace at each end of arglists, "if(" instead of > "if (". > > I expect that arguing about style is futile. > > not-to-mention-a-waste-of-time-ly y'rs - tim > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From billtut at microsoft.com Sat Jul 8 22:03:17 2000 From: billtut at microsoft.com (Bill Tutt) Date: Sat, 8 Jul 2000 13:03:17 -0700 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD296@RED-MSG-50> Ah, yes, the dreaded popen bug. A) If you really want to fix the problem everywhere then create a patch to popen for windows only that uses the code from the win32popen.cpp code. It includes code to handle Windows 9x as well. Not to mention the fact that this patch doesn't fix os.popen() in the following case: C/C++/whatever language binary that is a GUI app (windows subsystem) that embeds Python. (aka PythonWin.exe) The win32popen.cpp code works for all platforms and all cases, so a big -1 on this patch since it isn't doesn't handle all cases for the platforms the patch does work on. B) The -1's below really should be: INVALID_HANDLE_VALUE ! if (_get_osfhandle(0) == -1) ! dup2(null_file, 0); ! ! if (_get_osfhandle(1) == -1) ! dup2(null_file, 1); ! ! if (_get_osfhandle(2) == -1) ! dup2(null_file, 2); ! ! close(null_file); ! ! return Py_Main(__argc, __argv); } Wishing he could throttle the person who wrote popen in the CRT, Bill p.s. Just to clarify: Win32popen.cpp is all of the real work. Win32popenWin9x.* is the Win9x helper .exe so that you can use popen. <> <> <> begin 600 win32popen.cpp M(VEN8VQU9&4@(G=I;F1O=W,N:"(-"@T*+R\@0&1O8PT*#0HC:6YC;'5D92`B M4'ET:&]N+F at B#0HC:6YC;'5D92`B;6%L;&]C+F at B#0HC:6YC;'5D92`B:6\N M:"(-"B-I;F-L=61E(")F8VYT;"YH(@T*(VEN8VQU9&4@(E!Y5VEN5'EP97,N M:"(-"@T*(V1E9FEN92!$;&Q%>'!O'1EDUO9'5L95!A=&A;73L)#0H-"B\O(%1H97-E('1E;&P at 7U!Y4&]P96XH M*2!W971H97(@=&\@PT*"6-H87(@*F-M9'-T4]B:F5C="`J9BPJ M4%R9U]087)S951U<&QE*&%R M9W,L(")S?',Z<&]P96XB+`T*"0D)"0D)("`F8VUDPT*"0E0>45R&-?5F%L M=65%5!O<&5N*&-M9'-T M5!O<&5N*&-M9'-T4]B:F5C="`J4'E0;W!E;C(H4'E/8FIE8W0@*G-E;&8L M(%!Y3V)J96-T("`J87)G45X8U]686QU M945R4]B:F5C="`@*F%R9W,I#0I[#0H)8VAAPT*"0E0>45R&-?5F%L M=65%4]B:F5C="`@*F%R9W,I M#0I[#0H)8VAAPT* M"0E0>45R&-?5F%L=65%D-O;G-O;&53<&%W;B`](")W:6XS,G!O<&5N5VEN.7 at N97AE M(%PB(CL-"@EI;G0@:3L-"@EI;G0@>#L-"@T*"6EF("AI(#T at 1V5T16YV:7)O M;FUE;G1687)I86)L92 at B0T]-4U!%0R(L3E5,3"PP*2D-"B`@("![#0H)"7,Q M(#T@*&-H87(@*BE?86QL;V-A*&DI.PT*"0EI9B`H(2AX(#T at 1V5T16YV:7)O M;FUE;G1687)I86)L92 at B0T]-4U!%0R(L(',Q+"!I*2DI#0H)"0ER971U#L-"@D):68@*"%G7V952AS,BP@>"D[#0H) M"0ES<')I;G1F*`T*"0D)"7,R+`T*"0D)"2(E2!C;60N97AE("\@8V]M;6%N M9"YC;VT@:6X@=&AE('!A=&@-"@DO+R!.;W<@=V4G;&P@:G5S="!EF5O9BA35$%25%5024Y&3RDI.PT*"7-I4W1APT*"0DO+R!#;&]S92!T:&4@ M:&%N9&QE4]B:F5C="`J M7U!Y4&]P96XH8VAAF5O9BA314-54DE465]!5%1224)55$53*3L-"@ES84%T='(N M8DEN:&5R:71(86YD;&4@/2!44E5%.PT*"7-A071T5=I;E]3971! M4$E%PT*"0EC87-E(%]/7U=2 M3TY,62!\(%]/7U1%6%0Z#0H)"0DO+R!#87-E(&9O'0@;6]D92X-"@D)"69D,2`](%]O<&5N7V]S9FAA M;F1L92 at H;&]N9REH0VAI;&13=&1I;E=R1'5P+"!M;V1E*3L-"@D)"68Q(#T@ M7V9D;W!E;BAF9#$L(")W(BD[#0H)"0EF(#T at 4'E&:6QE7T9R;VU&:6QE*&8Q M+"!C;61S=')I;F49I;&5?1G)O;49I;&4H9C$L(&-M M9'-TF4H M9BP@,"D[#0H)"0DO+R!792!D;VXG="!C87)E(&%B;W5T('1H97-E('!I<&5S M(&%N>6UO2!M;V1E+ at T*"0D)9F0Q(#T at 7V]P96Y?;W-F:&%N9&QE*"AL M;VYG*6A#:&EL9%-T9&EN5W)$=7`L(&UO9&4I.PT*"0D)9C$@/2!?9F1O<&5N M*&9D,2P@(G=B(BD[#0H)"0EF(#T at 4'E&:6QE7T9R;VU&:6QE*&8Q+"!C;61S M=')I;F49I;&5?4V5T0G5F4VEZ92AF M+"`P*3L-"@D)"2\O(%=E(&1O;B=T(&-APT*"2`@("!C:&%R("IM,2P@*FTR M.PT*"2`@("!0>4]B:F5C="`J<#$L("IP,CL-"@D@("`@#0H)("`@(&EF("AM M;V1E("8F(%]/7U1%6%0I#0H)"7L-"@D)"6TQ/2)R(CL-"@D)"6TR/2)W(CL- M"@D)?0T*"2`@("!E;'-E#0H)"7L-"@D)"6TQ/2)R8B([#0H)"0EM,CTB=V(B M.PT*"0E]#0H-"@D@("`@9F0Q(#T at 7V]P96Y?;W-F:&%N9&QE*"AL;VYG*6A# M:&EL9%-T9&EN5W)$=7`L(&UO9&4I.PT*"2`@("!F,2`](%]F9&]P96XH9F0Q M+"!M,BD[#0H)("`@(&9D,B`](%]O<&5N7V]S9FAA;F1L92 at H;&]N9REH0VAI M;&13=&1O=7129$1U<"P@;6]D92D[#0H)("`@(&8R(#T at 7V9D;W!E;BAF9#(L M(&TQ*3L-"@D@("`@<#$@/2!0>49I;&5?1G)O;49I;&4H9C$L(&-M9'-T49I;&5?1G)O;49I;&4H9C(L(&-M9'-T5]"=6EL9%9A;'5E*")/3R(L<#$L<#(I.PT* M"2`@("!B49I;&5? M1G)O;49I;&4H9C(L(&-M9'-TF4H<#,L(#`I.PT* M"2`@("!F(#T at 4'E?0G5I;&1686QU92 at B3T]/(BQP,2QP,BQP,RD[#0H)("`@ M(&)R96%K.PT*"7T-"@E]#0H-"@EI9B`H;B`]/2!03U!%3E\T*0T*"7L-"@D) M:68@*"%?4'E0;W!E;D-R96%T95!R;V-E2!T M:&4 at 8VAI;&0@2&%N9&QE(BD[#0H-"@ER971U71H;VX@=VEN,S)P:7!E(&UO9'5L95QN(@T*(G1O('=O M"X@($ET(&ES M7&XB#0HB;F]T(&1EPT*"2`@ M($UEF5O9BAS:2D[#0H@("!S:2YD=T9L86=S("`@(#T at 4U1!4E1&7U5315-41$A! M3D1,15,[#0H@("!S:2YH4W1D26YP=70@(#T at 1V5T4W1D2&%N9&QE("A35$1? M24Y0551?2$%.1$Q%*3L-"B`@('-I+FA3=&1/=71P=70@/2!'9713=&1(86YD M;&4@*%-41%]/5510551?2$%.1$Q%*3L-"B`@('-I+FA3=&1% Ah, yes, the dreaded popen bug. A) If you really want to fix the problem everywhere then create a patch to popen for windows only that uses the code from the win32popen.cpp code. It includes code to handle Windows 9x as well. Not to mention the fact that this patch doesn't fix os.popen() in the following case: C/C++/whatever language binary that is a GUI app (windows subsystem) that embeds Python. (aka PythonWin.exe) The win32popen.cpp code works for all platforms and all cases, so a big -1 on this patch since it isn't doesn't handle all cases for the platforms the patch does work on. B) The -1's below really should be: INVALID_HANDLE_VALUE ! if (_get_osfhandle(0) == -1) ! dup2(null_file, 0); ! ! if (_get_osfhandle(1) == -1) ! dup2(null_file, 1); ! ! if (_get_osfhandle(2) == -1) ! dup2(null_file, 2); ! ! close(null_file); ! ! return Py_Main(__argc, __argv); } Wishing he could throttle the person who wrote popen in the CRT, Bill p.s. Just to clarify: Win32popen.cpp is all of the real work. Win32popenWin9x.* is the Win9x helper .exe so that you can use popen. <> <> <> begin 600 win32popen.cpp M(VEN8VQU9&4@(G=I;F1O=W,N:"(-"@T*+R\@0&1O8PT*#0HC:6YC;'5D92`B M4'ET:&]N+F at B#0HC:6YC;'5D92`B;6%L;&]C+F at B#0HC:6YC;'5D92`B:6\N M:"(-"B-I;F-L=61E(")F8VYT;"YH(@T*(VEN8VQU9&4@(E!Y5VEN5'EP97,N M:"(-"@T*(V1E9FEN92!$;&Q%>'!O'1EDUO9'5L95!A=&A;73L)#0H-"B\O(%1H97-E('1E;&P at 7U!Y4&]P96XH M*2!W971H97(@=&\@PT*"6-H87(@*F-M9'-T4]B:F5C="`J9BPJ M4%R9U]087)S951U<&QE*&%R M9W,L(")S?',Z<&]P96XB+`T*"0D)"0D)("`F8VUDPT*"0E0>45R&-?5F%L M=65%5!O<&5N*&-M9'-T M5!O<&5N*&-M9'-T4]B:F5C="`J4'E0;W!E;C(H4'E/8FIE8W0@*G-E;&8L M(%!Y3V)J96-T("`J87)G45X8U]686QU M945R4]B:F5C="`@*F%R9W,I#0I[#0H)8VAAPT*"0E0>45R&-?5F%L M=65%4]B:F5C="`@*F%R9W,I M#0I[#0H)8VAAPT* M"0E0>45R&-?5F%L=65%D-O;G-O;&53<&%W;B`](")W:6XS,G!O<&5N5VEN.7 at N97AE M(%PB(CL-"@EI;G0@:3L-"@EI;G0@>#L-"@T*"6EF("AI(#T at 1V5T16YV:7)O M;FUE;G1687)I86)L92 at B0T]-4U!%0R(L3E5,3"PP*2D-"B`@("![#0H)"7,Q M(#T@*&-H87(@*BE?86QL;V-A*&DI.PT*"0EI9B`H(2AX(#T at 1V5T16YV:7)O M;FUE;G1687)I86)L92 at B0T]-4U!%0R(L(',Q+"!I*2DI#0H)"0ER971U#L-"@D):68@*"%G7V952AS,BP@>"D[#0H) M"0ES<')I;G1F*`T*"0D)"7,R+`T*"0D)"2(E2!C;60N97AE("\@8V]M;6%N M9"YC;VT@:6X@=&AE('!A=&@-"@DO+R!.;W<@=V4G;&P@:G5S="!EF5O9BA35$%25%5024Y&3RDI.PT*"7-I4W1APT*"0DO+R!#;&]S92!T:&4@ M:&%N9&QE4]B:F5C="`J M7U!Y4&]P96XH8VAAF5O9BA314-54DE465]!5%1224)55$53*3L-"@ES84%T='(N M8DEN:&5R:71(86YD;&4@/2!44E5%.PT*"7-A071T5=I;E]3971! M4$E%PT*"0EC87-E(%]/7U=2 M3TY,62!\(%]/7U1%6%0Z#0H)"0DO+R!#87-E(&9O'0@;6]D92X-"@D)"69D,2`](%]O<&5N7V]S9FAA M;F1L92 at H;&]N9REH0VAI;&13=&1I;E=R1'5P+"!M;V1E*3L-"@D)"68Q(#T@ M7V9D;W!E;BAF9#$L(")W(BD[#0H)"0EF(#T at 4'E&:6QE7T9R;VU&:6QE*&8Q M+"!C;61S=')I;F49I;&5?1G)O;49I;&4H9C$L(&-M M9'-TF4H M9BP@,"D[#0H)"0DO+R!792!D;VXG="!C87)E(&%B;W5T('1H97-E('!I<&5S M(&%N>6UO2!M;V1E+ at T*"0D)9F0Q(#T at 7V]P96Y?;W-F:&%N9&QE*"AL M;VYG*6A#:&EL9%-T9&EN5W)$=7`L(&UO9&4I.PT*"0D)9C$@/2!?9F1O<&5N M*&9D,2P@(G=B(BD[#0H)"0EF(#T at 4'E&:6QE7T9R;VU&:6QE*&8Q+"!C;61S M=')I;F49I;&5?4V5T0G5F4VEZ92AF M+"`P*3L-"@D)"2\O(%=E(&1O;B=T(&-APT*"2`@("!C:&%R("IM,2P@*FTR M.PT*"2`@("!0>4]B:F5C="`J<#$L("IP,CL-"@D@("`@#0H)("`@(&EF("AM M;V1E("8F(%]/7U1%6%0I#0H)"7L-"@D)"6TQ/2)R(CL-"@D)"6TR/2)W(CL- M"@D)?0T*"2`@("!E;'-E#0H)"7L-"@D)"6TQ/2)R8B([#0H)"0EM,CTB=V(B M.PT*"0E]#0H-"@D@("`@9F0Q(#T at 7V]P96Y?;W-F:&%N9&QE*"AL;VYG*6A# M:&EL9%-T9&EN5W)$=7`L(&UO9&4I.PT*"2`@("!F,2`](%]F9&]P96XH9F0Q M+"!M,BD[#0H)("`@(&9D,B`](%]O<&5N7V]S9FAA;F1L92 at H;&]N9REH0VAI M;&13=&1O=7129$1U<"P@;6]D92D[#0H)("`@(&8R(#T at 7V9D;W!E;BAF9#(L M(&TQ*3L-"@D@("`@<#$@/2!0>49I;&5?1G)O;49I;&4H9C$L(&-M9'-T49I;&5?1G)O;49I;&4H9C(L(&-M9'-T5]"=6EL9%9A;'5E*")/3R(L<#$L<#(I.PT* M"2`@("!B49I;&5? M1G)O;49I;&4H9C(L(&-M9'-TF4H<#,L(#`I.PT* M"2`@("!F(#T at 4'E?0G5I;&1686QU92 at B3T]/(BQP,2QP,BQP,RD[#0H)("`@ M(&)R96%K.PT*"7T-"@E]#0H-"@EI9B`H;B`]/2!03U!%3E\T*0T*"7L-"@D) M:68@*"%?4'E0;W!E;D-R96%T95!R;V-E2!T M:&4 at 8VAI;&0@2&%N9&QE(BD[#0H-"@ER971U71H;VX@=VEN,S)P:7!E(&UO9'5L95QN(@T*(G1O('=O M"X@($ET(&ES M7&XB#0HB;F]T(&1EPT*"2`@ M($UEF5O9BAS:2D[#0H@("!S:2YD=T9L86=S("`@(#T at 4U1!4E1&7U5315-41$A! M3D1,15,[#0H@("!S:2YH4W1D26YP=70@(#T at 1V5T4W1D2&%N9&QE("A35$1? M24Y0551?2$%.1$Q%*3L-"B`@('-I+FA3=&1/=71P=70@/2!'9713=&1(86YD M;&4@*%-41%]/5510551?2$%.1$Q%*3L-"B`@('-I+FA3=&1% Oops, silly outlook. I need to get around to writing that VBA macro that warns me if the attachment encoding isn't specified. Ugh. If anybody out there can't get the uuencoded version to decode in their mailer the files are at: http://lima.mudlib.org/~rassilon/popen Bill From barry at scottb.demon.co.uk Sat Jul 8 22:37:04 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sat, 8 Jul 2000 21:37:04 +0100 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD296@RED-MSG-50> Message-ID: <001301bfe91c$46ddcb80$060210ac@private> Bill, Your code is a far better solution. > B) The -1's below really should be: INVALID_HANDLE_VALUE Check with the implementation and MSDN you will see that the return type is long and the error condition is -1. INVALID_HANDLE_VALUE is not of type long and will give a compile warning C4047. Barry From effbot at telia.com Sat Jul 8 22:52:21 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 22:52:21 +0200 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD296@RED-MSG-50> Message-ID: <016a01bfe91e$6a6ecc00$f2a6b5d4@hagrid> bill wrote: > A) If you really want to fix the problem everywhere then create a > patch to popen for windows only that uses the code from the > win32popen.cpp code. It includes code to handle Windows 9x as > well. excellent! I'll take over from here. From billtut at microsoft.com Sat Jul 8 22:54:36 2000 From: billtut at microsoft.com (Bill Tutt) Date: Sat, 8 Jul 2000 13:54:36 -0700 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD299@RED-MSG-50> Heh, if the CRT really returns a long from the get OS handle function, then its typed wrong. :) For Win32 sizeof(HANDLE) == sizeof(long), that isn't the case for Win64. Bill -----Original Message----- From: Barry Scott [mailto:barry at scottb.demon.co.uk] Sent: Saturday, July 08, 2000 1:37 PM To: Bill Tutt; python-dev at python.org Subject: RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 Bill, Your code is a far better solution. > B) The -1's below really should be: INVALID_HANDLE_VALUE Check with the implementation and MSDN you will see that the return type is long and the error condition is -1. INVALID_HANDLE_VALUE is not of type long and will give a compile warning C4047. Barry From effbot at telia.com Sat Jul 8 23:04:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 23:04:19 +0200 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD296@RED-MSG-50> Message-ID: <019501bfe920$18cee220$f2a6b5d4@hagrid> bill wrote: > Just to clarify: > Win32popen.cpp is all of the real work. > Win32popenWin9x.* is the Win9x helper .exe so that you can use popen. stupid question: what exactly does the RC file do here: STRINGTABLE DISCARDABLE BEGIN 2000 "Dummy" // Needed to version branding works! END (couldn't really parse that comment ;-) From guido at beopen.com Sun Jul 9 00:06:06 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 17:06:06 -0500 Subject: [Python-Dev] Encodings In-Reply-To: Your message of "Sat, 08 Jul 2000 18:05:16 +0200." <3967513C.BAF459FB@lemburg.com> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> Message-ID: <200007082206.RAA08314@cj20424-a.reston1.va.home.com> > Guido van Rossum wrote: > > I couldn't have said it better. It's okay for now to have it > > changeable at the C level -- with endless caveats that it should be > > set only once before any use, and marked as an experimental feature. > > But the Python access and the reliance on the environment should go. [MAL replies] > Sorry, but I'm really surprised now: I've put many hours of > work into this, hacked up encoding support for locale.py, > went through endless discussions, proposed the changable default > as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy > ... and now all it takes is one single posting to render all that > work useless ??? I'm sorry too. As Fred Drake explained, the changeable default was an experiment. I won't repeat his excellent response. I am perhaps to blame for the idea that the character set of 8-bit strings in C can be derived in some whay from the locale -- but the main reason I brought it up was as a counter-argument to the Latin-1 fixed default that effbot arged for. I never dreamed that you could actually find out the name of the character set given the locale! > Instead of tossing things we should be *constructive* and come > up with a solution to the hash value problem, e.g. I would > like to make the hash value be calculated from the UTF-16 > value in a way that is compatible with ASCII strings. I think you are proposing to drop the following rule: if a == b then hash(a) == hash(b) or also if hash(a) != hasb(b) then a != b This is very fundamental for dictionaries! Note that it is currently broken: >>> d = {'\200':1} >>> d['\200'] 1 >>> u'\200' == '\200' 1 >>> d[u'\200'] Traceback (most recent call last): File "", line 1, in ? KeyError: ? >>> While you could fix this with a variable encoding, it would be very hard, probably involving the string to Unicode before taking its hash, and this would slow down the hash calculation for 8-bit strings considerably (and these are fundamental for the speed of the language!). So I am for restoring ASCII as the one and only fixed encoding. (Then you can fix your hash much easier!) Side note: the KeyError handling is broken. The bad key should be run through repr() (probably when the error is raised than when it is displayed). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Sun Jul 9 00:09:52 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 17:09:52 -0500 Subject: [Python-Dev] RE: Python-checkins digest, Vol 1 #615 - 2 msgs In-Reply-To: Your message of "Sat, 08 Jul 2000 11:36:32 -0400." References: Message-ID: <200007082209.RAA08356@cj20424-a.reston1.va.home.com> > [Fred] > > I seem to recall that Guido had caved on this, mostly because he > > received enough complaints about too much code getting shoved way over > > to the right, in a column a dozen of fewer characters wide (which is > > seriously hard to decode). I don't remember if this was on the list > > or in a meeting. > > If I'm mis-remembering, then we should presure him on this until he > > does cave. ;) [Tim] > Guido, you need to Pronounce on this! > > I personally prefer 4-space no-hard-tabs everywhere, but given the way most > editors work, the most important thing is that there's no variation within a > given file type (e.g., that all .c files do the same, and all .py files do > the same, but it's bearable for .c and .py files to differ -- which latter > has been the case until now). Sorry, I still like -s8 -t8 for C code best. Just like the Linux kernel, if someone asks. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Sun Jul 9 00:19:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 17:19:02 -0500 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: Your message of "Sat, 08 Jul 2000 10:34:16 EST." <396749F8.F98D2F8C@prescod.net> References: <396749F8.F98D2F8C@prescod.net> Message-ID: <200007082219.RAA08379@cj20424-a.reston1.va.home.com> I don't know what to do about this, but Neil H's point that we might want to separate the operational issues from the deep discussions makes some sense. Maybe there's even room for three lists: operational, current code and patches, and future features. But in reality, the difference between the various lists isn't the topic: it's the group of people. The fact that people are only allowed into python-dev based on merit etc. (really a process of co-optation) makes a difference: I feel much more comfortable discussing both operational issues and future features here than I do in the general newsgroup, because I approximately know my audience. When posting to c.l.py these days I usually feel a lot of pressure about how my writings will be perceived by newbies, critics, members of other cultures, the press, and so on. Sure, they can read the python-dev archives, but few do, and (except for Gerrit Holl) I haven't had any feedback from outsiders to posts made here. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From effbot at telia.com Sat Jul 8 23:24:53 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 23:24:53 +0200 Subject: [Python-Dev] new popen for win32! Message-ID: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> just a few questions before I prepare the patch... - first, a stupid question: is the popen2 and popen3 versions replacements for the corresponding functions in the popen2 module. (or to put it another way: should the popen2 module be modified to use these functions on Windows?) - should this go into the "nt" (posix) module, or should I create a new module? - "win32popenWin9x.exe" is a rather unwieldy name for a file. does anyone have a better suggestion? python_popen.exe py_popen9x.exe popenStub.exe ...? - I'm using VC5 on this box, so I should probably avoid checking in my modified project files. any VC6-wielding volunteers out there? From effbot at telia.com Sat Jul 8 23:33:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 8 Jul 2000 23:33:19 +0200 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <200007082206.RAA08314@cj20424-a.reston1.va.home.com> Message-ID: <01d901bfe924$26b42d60$f2a6b5d4@hagrid> guido wrote: > I am perhaps to blame for the idea that the character set of 8-bit > strings in C can be derived in some whay from the locale -- but the > main reason I brought it up was as a counter-argument to the Latin-1 > fixed default that effbot arged for. note that this work isn't exactly wasted; the default encoding mechanisms can (and should) be used to handle unicode args to system API's like open (etc). we just have to figure out how to design the internal API's. cannot be that hard, can it? > I never dreamed that you could actually find out the name of the > character set given the locale! never underestimate the malbot. (btw, this magic now works on windows too! ;-) >>> import locale >>> print locale.getdefaultlocale() ('sv_SE', 'cp1252') From gmcm at hypernet.com Sat Jul 8 23:42:11 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 8 Jul 2000 17:42:11 -0400 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <200007082219.RAA08379@cj20424-a.reston1.va.home.com> References: Your message of "Sat, 08 Jul 2000 10:34:16 EST." <396749F8.F98D2F8C@prescod.net> Message-ID: <1249029961-17188506@hypernet.com> [Guido] > I don't know what to do about this, but Neil H's point that we > might want to separate the operational issues from the deep > discussions makes some sense. Maybe there's even room for three > lists: operational, current code and patches, and future > features. > > But in reality, the difference between the various lists isn't > the topic: it's the group of people. There are at least 3 and maybe 6 or more of us who still read c.l.py (though I've dropped back to newsgroup so I can skip the braindead threads). As a partial solution, perhaps we could use some self-discipline and sometimes say "kick it to c.l.py". I, for one, would be willing to _help_ (not "assume responsibility for"!) monitoring threads of this sort and summarizing back to the dev list. For ideas on which Guido is > -0, I think this might be a good way to guage reaction. - Gordon From thomas at xs4all.net Sun Jul 9 00:01:36 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 00:01:36 +0200 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <1249029961-17188506@hypernet.com>; from gmcm@hypernet.com on Sat, Jul 08, 2000 at 05:42:11PM -0400 References: <396749F8.F98D2F8C@prescod.net> <200007082219.RAA08379@cj20424-a.reston1.va.home.com> <1249029961-17188506@hypernet.com> Message-ID: <20000709000135.Q26534@xs4all.nl> On Sat, Jul 08, 2000 at 05:42:11PM -0400, Gordon McMillan wrote: > There are at least 3 and maybe 6 or more of us who still read > c.l.py (though I've dropped back to newsgroup so I can skip > the braindead threads). As a partial solution, perhaps we > could use some self-discipline and sometimes say "kick it to > c.l.py". I, for one, would be willing to _help_ (not "assume > responsibility for"!) monitoring threads of this sort and > summarizing back to the dev list. Agreed, though I think it should go the other way, too. And it isn't just about discussing new features or bugs; people, or at least involved people, like to see that there are actually people working on improving Python ;) Whether it's a new feature, a bugfix, a radical or a subtle change, whether it leads to anything or not, they like to see Python isn't dead ;) The deminishing number of 'core developers' posting in c.l.py was one of the reasons I started reading the python-dev archives, anyway. The problem with making python-dev more accessible is that it makes python-dev more accessible, as well ;-P As Guido said, he hardly gets any non-python-dev responses to python-dev postings, and that's pretty understandable. The step from reading something in the web-based archives and replying to them is pretty large. It isn't impossible (I've responded to something I saw in the archives a few times, though not directly to Go--ehr, Guido ;) but it definately helps lessen the responses. Anyway, I try to keep up with python-list and python-dev both, so I'll help with occasionally gatewaying things ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Sun Jul 9 01:24:16 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 18:24:16 -0500 Subject: [Python-Dev] Encodings In-Reply-To: Your message of "Sat, 08 Jul 2000 23:33:19 +0200." <01d901bfe924$26b42d60$f2a6b5d4@hagrid> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <200007082206.RAA08314@cj20424-a.reston1.va.home.com> <01d901bfe924$26b42d60$f2a6b5d4@hagrid> Message-ID: <200007082324.SAA08736@cj20424-a.reston1.va.home.com> > > I never dreamed that you could actually find out the name of the > > character set given the locale! > > never underestimate the malbot. > > (btw, this magic now works on windows too! ;-) > > >>> import locale > >>> print locale.getdefaultlocale() > ('sv_SE', 'cp1252') That seems actually pretty useful for explicit conversions! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Sun Jul 9 01:34:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 08 Jul 2000 18:34:02 -0500 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix In-Reply-To: Your message of "Sat, 08 Jul 2000 19:27:50 GMT." <396780B6.67247E2C@stud.ntnu.no> References: <396780B6.67247E2C@stud.ntnu.no> Message-ID: <200007082334.SAA08816@cj20424-a.reston1.va.home.com> > diff -c -d -T --recursive python/dist/src/Python/compile.c python-mod/dist/src/Python/compile.c > *** python/dist/src/Python/compile.c Mon Jul 3 21:39:47 2000 > --- python-mod/dist/src/Python/compile.c Sat Jul 8 19:13:42 2000 > *************** > *** 3102,3109 **** > name = nbuf; > sprintf(nbuf, ".%d", i); > complex = 1; > } > ! com_newlocal(c, name); > c->c_argcount++; > if (++i >= nch) > break; > --- 3103,3120 ---- > name = nbuf; > sprintf(nbuf, ".%d", i); > complex = 1; > + } > + > + nameval = PyString_InternFromString(name); > + if (nameval == NULL) { > + c->c_errors++; > } > ! if (PyDict_GetItem(c->c_locals, nameval)) { > ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); > ! } > ! com_newlocal_o(c, nameval); > ! Py_DECREF(nameval); > ! > c->c_argcount++; > if (++i >= nch) > break; > I get a compile error: nameval undeclared. Which version are you working off? Please use the SourceForge CVS tree! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From effbot at telia.com Sun Jul 9 00:59:39 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 00:59:39 +0200 Subject: [Python-Dev] Re: Patch #100752 - Make atoi work for negative bases Message-ID: <03af01bfe930$34e6b4a0$f2a6b5d4@hagrid> should this patch perhaps be rejected and/or postponed? http://sourceforge.net/patch/?func=detailpatch&patch_id=100752&group_id=5470 (iirc, guido was -1 on this one, right?) From petersc at stud.ntnu.no Sun Jul 9 04:28:33 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Sun, 09 Jul 2000 02:28:33 +0000 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix References: <396780B6.67247E2C@stud.ntnu.no> <200007082334.SAA08816@cj20424-a.reston1.va.home.com> Message-ID: <3967E351.826FE29F@stud.ntnu.no> Guido van Rossum wrote: > > I get a compile error: nameval undeclared. Which version are you > working off? Please use the SourceForge CVS tree! Oops. I forget one chunk of the patch which is related to the bugfix. By the way, I am using the CVS tree. It's just a 'PyObject *nameval;' declaration. I have attached a more complete patch. I still can't figure where the compiler segfaults. Good night (or good morning), Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de -------------- next part -------------- diff -c -d -T --recursive python/dist/src/Python/compile.c python-mod/dist/src/Python/compile.c *** python/dist/src/Python/compile.c Mon Jul 3 21:39:47 2000 --- python-mod/dist/src/Python/compile.c Sun Jul 9 02:04:26 2000 *************** *** 3092,3097 **** --- 3092,3098 ---- node *ch = CHILD(n, i); node *fp; char *name; + PyObject *nameval; if (TYPE(ch) == STAR || TYPE(ch) == DOUBLESTAR) break; REQ(ch, fpdef); /* fpdef: NAME | '(' fplist ')' */ *************** *** 3103,3109 **** sprintf(nbuf, ".%d", i); complex = 1; } ! com_newlocal(c, name); c->c_argcount++; if (++i >= nch) break; --- 3104,3118 ---- sprintf(nbuf, ".%d", i); complex = 1; } ! nameval = PyString_InternFromString(name); ! if (nameval == NULL) { ! c->c_errors++; ! } ! if (PyDict_GetItem(c->c_locals, nameval)) { ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); ! } ! com_newlocal_o(c, nameval); ! Py_DECREF(nameval); c->c_argcount++; if (++i >= nch) break; From fdrake at beopen.com Sun Jul 9 02:58:56 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 8 Jul 2000 20:58:56 -0400 (EDT) Subject: [Python-Dev] Py_PROTO elimination in Include/ Message-ID: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com> I've removed Py_PROTO from the headers in the Include/ directory, with the exceptions of the my*.h headers. I'll leave it for others to fix those, merging with pyport.h as appropriate. I think I'll stop for a bite to eat. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein at lyra.org Sun Jul 9 03:10:28 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 8 Jul 2000 18:10:28 -0700 Subject: [Python-Dev] Re: Patch #100752 - Make atoi work for negative bases In-Reply-To: <03af01bfe930$34e6b4a0$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jul 09, 2000 at 12:59:39AM +0200 References: <03af01bfe930$34e6b4a0$f2a6b5d4@hagrid> Message-ID: <20000708181028.M29590@lyra.org> On Sun, Jul 09, 2000 at 12:59:39AM +0200, Fredrik Lundh wrote: > should this patch perhaps be rejected and/or postponed? > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100752&group_id=5470 > > (iirc, guido was -1 on this one, right?) "A polite, but firm, -1" is what he said. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jul 9 03:10:04 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 8 Jul 2000 18:10:04 -0700 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Sat, Jul 08, 2000 at 08:58:56PM -0400 References: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com> Message-ID: <20000708181004.L29590@lyra.org> On Sat, Jul 08, 2000 at 08:58:56PM -0400, Fred L. Drake, Jr. wrote: > > I've removed Py_PROTO from the headers in the Include/ directory, woo! Time to create that pydeprecated.h header and move Py_PROTO there :-) (for use by third-party modules) Good work, Fred! Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Sun Jul 9 03:51:05 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 21:51:05 -0400 Subject: [Python-Dev] Re: Patch #100752 - Make atoi work for negative bases In-Reply-To: <03af01bfe930$34e6b4a0$f2a6b5d4@hagrid> Message-ID: [/F] > should this patch perhaps be rejected and/or postponed? > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100752&group_id=5470 I see Guido rejected it. I saw that because I just logged in to reject it . From tim_one at email.msn.com Sun Jul 9 04:04:44 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 22:04:44 -0400 Subject: [Python-Dev] new popen for win32! In-Reply-To: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > just a few questions before I prepare the patch... > > - first, a stupid question: is the popen2 and popen3 > versions replacements for the corresponding functions > in the popen2 module. > > (or to put it another way: should the popen2 module > be modified to use these functions on Windows?) > > - should this go into the "nt" (posix) module, or should > I create a new module? It's hard to answer because I've forgotten how I *expected* things to work when I first moved to Windows. So, in an ass-backwards sense, that's the answer : if I "import os" and do os.popen, I expect it to work. Or, IOW, I expect the same popen-related code to work in the same ways via the same spelling regardless of OS. As is, I hardly ever use anything popen-related under Windows today because it usually craps out or hangs. There's no point to keeping Windows code around that doesn't work! > - "win32popenWin9x.exe" is a rather unwieldy name for a > file. does anyone have a better suggestion? > > python_popen.exe > py_popen9x.exe > popenStub.exe > > ...? Assuming this lives in Python's directories, no need to mention pyxxx. How about w9xpopen.exe Then it's an 8.3 name and will save mounds of directory space too . > - I'm using VC5 on this box, so I should probably avoid > checking in my modified project files. any VC6-wielding > volunteers out there? Tell me exactly what it is I'm volunteering for, and probably "yes". Certainly yes if you want me to "updgade" your VC5 .dsp/.dsw files to VC6 and mail 'em back to you, or to make the same changes in my VC6 files and check them in. From nhodgson at bigpond.net.au Sun Jul 9 04:30:49 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Sun, 9 Jul 2000 12:30:49 +1000 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] References: <396749F8.F98D2F8C@prescod.net> <200007082219.RAA08379@cj20424-a.reston1.va.home.com> Message-ID: <011d01bfe94d$b2fb7200$8119fea9@neil> Guido writes, > I feel much more comfortable > discussing both operational issues and future features here than I do > in the general newsgroup, because I approximately know my audience. > When posting to c.l.py these days I usually feel a lot of pressure > about how my writings will be perceived by newbies, critics, members > of other cultures, the press, and so on. I'd like to separate out the problem here. Is it that there is a need to keep politically damaging opinions private so the Python community is not seen to be disparaging some other project like Tk or Expat? Is it that it is more acceptable for you to make mistakes in front of a restricted audience? > Sure, they can read the > python-dev archives, but few do, and (except for Gerrit Holl) I > haven't had any feedback from outsiders to posts made here. How is the average Python user to learn of python-dev? I did know that python-dev existed before being invited on but had never been interested enough to find it. I just tried to find out about python-dev from the top level of python.org. Searched the Mailing Lists, Community and SIGs pages. Searched the FAQ. Even ran a search using the search page over the python.org web site with no relevant result. If it is desirable for more people to know about what happens on python-dev, then access to the archives should be made easier. My understanding is that currently anyone can write to python-dev but only invitees can subscribe. The inversion of the normal pattern of restricted mail list access does make some sense in allowing temporary inclusion of people involved in a discussion. But it denies outsiders the ability to sensibly read python-dev. Web archives are a poor imitation of a mail readers ability to filter threads and topics. The problem for me here is that knowledge of what is going to happen to Python is kept by the Python developers away from the Python users. Neil From tim_one at email.msn.com Sun Jul 9 05:22:13 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 23:22:13 -0400 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <011d01bfe94d$b2fb7200$8119fea9@neil> Message-ID: [Neil Hodgson] > ... > The problem for me here is that knowledge of what is going > to happen to Python is kept by the Python developers away from > the Python users. This is a bit funny, because users can know *much* more about what's coming up in Python now than they ever could in earlier days! The source tree, the patches, and the discussions are all there to be seen, for anyone who cares to make the effort. If users want to be spoon-fed, that's fine, but it's sure not my job to do that (albeit that it used to be a hobby of mine -- and one I hope to resume). When lambda, map and filter were added to Python 5 or 6 years ago, it was a complete surprise. The surprise level has gone down every year since. I expect that for P3K we should move toward a more formal and conventional scheme of writing detailed proposals, and actively soliciting coherent public review. The chaos of a general large newsgroup prevents accomplishing much of anything, though. if-newsgroups-are-the-answer-the-problem-isn't-python-development-ly y'rs - tim From tim_one at email.msn.com Sun Jul 9 05:22:16 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 8 Jul 2000 23:22:16 -0400 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <20000708181004.L29590@lyra.org> Message-ID: I just removed all other occurrences of Py_PROTO and Py_FPROTO in the source tree. Fred, there's still at least one reference in the docs, but I expect you can grep for that more efficiently than I can point it out. [Greg Stein] > Time to create that pydeprecated.h header and move Py_PROTO there :-) > (for use by third-party modules) Be Guido's guest . From fdrake at beopen.com Sun Jul 9 06:51:35 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 00:51:35 -0400 (EDT) Subject: [Python-Dev] __SC__ #define? Message-ID: <14696.1239.522305.588599@cj42289-a.reston1.va.home.com> Does anyone know the purpose of the __SC__ define that's tested in Include/object.h or Objects/floatobject.c? I don't see anywhere in the Python sources where it can be set, and those are the only two places it gets tested. In object.h, it's used to determine the proper definition of statichere, and in floatobject.h it's used to determine if an ANSI prototype should be used. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sun Jul 9 07:15:56 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 01:15:56 -0400 Subject: [Python-Dev] Include/pyport.h now exists In-Reply-To: <20000708212149.P26534@xs4all.nl> Message-ID: [Tim] > Would someone who understands (& can test! I can't yet) > autoconfig please follow up on the last part? [Thomas Wouters] > Can't say I understand all of autoconf but I read enough of the > info pages to be able to do this ! :-) I couldn't find an existing > test that covers this, so I used your example to make one; patch > attached. It detects my linux box properly as 'doesn't zero-fill > when right-shifting a negative number', but I haven't a Cray J90 > handy to test the opposite ;) Only Marc Poinot can test on the J90 now. I tested the logic of the patch by switching the sense of the #ifdef in pyport.h, and it works fine on my box (the point to the #ifdef is to avoid the slow code on platforms that don't *need* the slow code). Don't worry about this -- and we already know for sure that signed right shifts do zero-fill on Marc's platform (perfectly acceptable according to the C std!). > Feel free to change the wording to something a bit less... wordy, > though ;) > Oh, and don't forget to run autoheader & automake before checking in. This helps, but my original request still stands: would somone who can *do* (all of) this please follow up on it? I'm running a Windows laptop in a hotel room -- I can't run Unix-specific config stuff (like autoheader or automake) at all. By "test" I didn't mean test the patch, but get the rest of the Unix config cruft built and test (just) whether the Unix config stuff works. From tim_one at email.msn.com Sun Jul 9 07:23:02 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 01:23:02 -0400 Subject: [Python-Dev] C coding style In-Reply-To: <1249045739-16239476@hypernet.com> Message-ID: [Gordon McMillan] > Jeez, guys. The following options will make indent produce > something that's so close to Guido's style, he'd probably never > notice that it's not exactly his style: > > -br -bap -nce -ss -i8 -ci8 -lp -ts8 -psl -npcs -nbc -ip8 -ncs -nfca Harrumph. Python doesn't recognize *any* of those switches. and-i-use-python-for-everything-ly y'rs - tim From tim_one at email.msn.com Sun Jul 9 07:23:03 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 01:23:03 -0400 Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: Message-ID: [Tim, pushing the adoption of some C9X-like typedefs in Python's source] > ... > the-committee-wasn't-just-jerking-off-the-last-10-years-ly y'rs - > tim [Ken Manheimer] > (The obvious question is, where they doing those other things at the same > time, or during breaks?) It varies by member. For example, the Reverend Tom MacDonald jerked off non-stop the entire time (& I've copied him on this for confirmation). But a surprising number of the members have never jerked off at all! Rev Tom, after 118 years serving on X3J11, do you think C9X is a good thing or a bad thing? And do you still get off on it regardless? And what does God think about C9X? community-involvement-ly y'rs - tim From fdrake at beopen.com Sun Jul 9 07:25:50 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 01:25:50 -0400 (EDT) Subject: [Python-Dev] __SC__ #define? In-Reply-To: <14696.1239.522305.588599@cj42289-a.reston1.va.home.com> References: <14696.1239.522305.588599@cj42289-a.reston1.va.home.com> Message-ID: <14696.3294.579121.909885@cj42289-a.reston1.va.home.com> Fred L. Drake, Jr. writes: > Does anyone know the purpose of the __SC__ define that's tested in > Include/object.h or Objects/floatobject.c? I don't see anywhere in > the Python sources where it can be set, and those are the only two > places it gets tested. > In object.h, it's used to determine the proper definition of > statichere, and in floatobject.h it's used to determine if an ANSI > prototype should be used. Ok, the use in floatobject.c can be removed; if defined, an ANSI signature was being used, which we want to be doing unconditionally at this point. So I'm removing the test there. The use in object.h is more confusing; the log messages are not terribly useful. If anyone understands this one; I'd appreciate a pointer. Appearantly (based on the message associated with the floatobject.c use), the define has something to do with a Macintosh compiler. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sun Jul 9 07:54:46 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 01:54:46 -0400 Subject: [Python-Dev] __SC__ #define? In-Reply-To: <14696.1239.522305.588599@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr.] > Does anyone know the purpose of the __SC__ define that's tested in > Include/object.h or Objects/floatobject.c? Beats me. The symbol __SC__ appears to be predinfed by the Symantec C compiler. It shows up in several bits of interesting code via google, like #if defined(__MWERKS__) || defined (__SC__) #define BRAIN_DEAD_INLINING // define this to declare "hot" #endif // functions as macros instead // of C++ inline functions Alas, like most other older & widely-ported C programs, Python's use of magical & undocumented preprocessor symbols is a god-awful mess. most-developers-would-be-shot-except-they're-so-hard-to- replace-ly y'rs - tim From tim_one at email.msn.com Sun Jul 9 08:06:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 02:06:18 -0400 Subject: Release scheduloe (was RE: [Python-Dev] list comprehensions again...) In-Reply-To: <200007070238.EAA03292@python.inrialpes.fr> Message-ID: [Vladimir Marangozov] > ... [lots of reasonable stuff snipped] ... > ... > I believe that staying in an undetermined Z-state for more than a week > without a set of clearly defined options is not really what we all want, > but maybe you have some additional considerations that may explain the > ongoing patience about this lag... CNRI is involved too. They've chosen so far not to say anything public about what they're after here, and we can't speak for them. *Presuming* to speak for them could not have a good outcome, either. So we remain silent too. None of this is open to debate anyway -- except that if the delay goes on forever, vote with your keyboard by grabbing the Python source and making your own release <0.9 wink>! in-the-meantime-lots-of-good-patches-are-getting-in-ly y'rs - tim From tim_one at email.msn.com Sun Jul 9 08:22:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 02:22:52 -0400 Subject: [Python-Dev] Re: [I18n-sig] Unicode experience In-Reply-To: <14694.19489.449195.619187@beluga.mojam.com> Message-ID: [Skip Montanaro] > Halleluhah! Never thought I'd get Perl programming help here! Skip, if you can't get Perl help on Python-Dev, where *could* you get it?! Passing out Perl help is one of Python-Dev's most important functions. never-leave-home-ly y'rs - tim From tim_one at email.msn.com Sun Jul 9 09:02:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 03:02:36 -0400 Subject: [Python-Dev] RE: [Patches] [Patch #100745] Fix PR #384, fixesUTF-8 en/decode In-Reply-To: Message-ID: > ... > what if sizeof(long) == 2 and sizeof(long long) == 4? That a long can hold at least 32 bits is required by the (current) C std. "long long" is std in C9X, and must hold at least 64 bits. From tim_one at email.msn.com Sun Jul 9 09:05:28 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 03:05:28 -0400 Subject: [Python-Dev] Microsoft adopts Python Message-ID: I take back everything bad I ever said about clueless support droids . -----Original Message----- From: python-help-admin at python.org Sent: Thursday, July 06, 2000 4:46 PM To: python Subject: [Python-Help] programming python I called Microsoft Support and asked for his advice how to learn programming C++ as a complete novice and he recommended to contact your organization for learning first Python. ... From thomas at xs4all.net Sun Jul 9 11:24:32 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 11:24:32 +0200 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <011d01bfe94d$b2fb7200$8119fea9@neil>; from nhodgson@bigpond.net.au on Sun, Jul 09, 2000 at 12:30:49PM +1000 References: <396749F8.F98D2F8C@prescod.net> <200007082219.RAA08379@cj20424-a.reston1.va.home.com> <011d01bfe94d$b2fb7200$8119fea9@neil> Message-ID: <20000709112432.T26534@xs4all.nl> On Sun, Jul 09, 2000 at 12:30:49PM +1000, Neil Hodgson wrote: > > When posting to c.l.py these days I usually feel a lot of pressure > > about how my writings will be perceived by newbies, critics, members > > of other cultures, the press, and so on. > I'd like to separate out the problem here. Is it that there is a need to > keep politically damaging opinions private so the Python community is not > seen to be disparaging some other project like Tk or Expat? Is it that it is > more acceptable for you to make mistakes in front of a restricted audience? Without pretending I can channel Guido as good as the others here ;) I think I know what Guido means: he's afraid of a Prophet Effect, like in the Life of Brian ;) The public image of Guido is a godly one, of stability and steady progress, no nasty suprises. If he were to suggest something radical on c.l.py, like the removal of lambda, classes, or case sensitivity, he'd have a small uprising in his mailbox: half the people on c.l.py would run away from Python screaming (or after screaming loudly in c.l.py,) and the other half would instantly start defending Guido's opinion, having convinced themselves it's a good idea. If he did it here, two things are different: Less people see his insane outburst, and before most people see it, a few developers will have replied, with well-argumented critique, with sooths both types of 'followers' who do happen to read it. (I mean no disrespect towards c.l.py readers, of course, and the stereotype doesn't hold in individual cases. Some of my best friends are c.l.py-readers! But I'm trying to make a point here ;) The other thing is that the audience that does read it right away, the developers, are much more critical towards Guido's opinion, and used to arguing about it in a friendly manner, with Guido and amongst eachother. So Guido has to be less careful about what he says, because he knows python-dev won't take him too seriously anyway ;) At-least-that's-what-I'd-think-if-I'd-written-the-perfect-programming- -language-and-had-to-develop-it-further-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From martin at loewis.home.cs.tu-berlin.de Sun Jul 9 11:26:36 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 9 Jul 2000 11:26:36 +0200 Subject: [Python-Dev] changing the locale.py interface? Message-ID: <200007090926.LAA01406@loewis.home.cs.tu-berlin.de> > comments? Looks good to me. Where is the patch to the documentation documenting all that ?-) Regards, Martin From mwh21 at cam.ac.uk Sun Jul 9 12:06:36 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Sun, 9 Jul 2000 11:06:36 +0100 (BST) Subject: [Python-Dev] __SC__ #define? In-Reply-To: <14696.3294.579121.909885@cj42289-a.reston1.va.home.com> Message-ID: On Sun, 9 Jul 2000, Fred L. Drake, Jr. wrote: > Ok, the use in floatobject.c can be removed; if defined, an ANSI > signature was being used, which we want to be doing unconditionally at > this point. So I'm removing the test there. > The use in object.h is more confusing; the log messages are not > terribly useful. If anyone understands this one; I'd appreciate a > pointer. Appearantly (based on the message associated with the > floatobject.c use), the define has something to do with a Macintosh > compiler. As Tim said, it's probably the Symantec C compiler, which is as far as I know dead (it was more or less dead when I was last playing around programming on the Mac, and that was several years ago). So unless someone screams "I still use Symantec!", I'd say nuke it. hmm-email-over-modem-and-telnet---joy-ly y'rs M. From mwh21 at cam.ac.uk Sun Jul 9 12:14:04 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Sun, 9 Jul 2000 11:14:04 +0100 (BST) Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <1249029961-17188506@hypernet.com> Message-ID: On Sat, 8 Jul 2000, Gordon McMillan wrote: > [Guido] > > I don't know what to do about this, but Neil H's point that we > > might want to separate the operational issues from the deep > > discussions makes some sense. Maybe there's even room for three > > lists: operational, current code and patches, and future > > features. > > > > But in reality, the difference between the various lists isn't > > the topic: it's the group of people. > > There are at least 3 and maybe 6 or more of us who still read > c.l.py (though I've dropped back to newsgroup so I can skip > the braindead threads). As a partial solution, perhaps we > could use some self-discipline and sometimes say "kick it to > c.l.py". I, for one, would be willing to _help_ (not "assume > responsibility for"!) monitoring threads of this sort and > summarizing back to the dev list. I think this is a good idea. I think it is important that comp.lang.python continues to have *some* interesting content, and that the impression is mantained that (reasonable) opinions expressed there are listened to, so that bright & curious people who happen along stick around and maybe move on to actually contributing to Python (yes, this is somewhat autobiographical - two of my first three posts to c.l.py were answered by Guido and David Ascher...). > For ideas on which Guido is > -0, I think this might be a good > way to guage reaction. So do I, and I'd also be willing to help monitor c.l.py (though not right now; due to a broken ethernet port, my access is a bit sporadic, and I'm having trouble keeping up with python-dev). Cheers, M. From effbot at telia.com Sun Jul 9 12:34:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 12:34:48 +0200 Subject: [Python-Dev] what about the SF task manager? Message-ID: <010b01bfe991$53af7280$f2a6b5d4@hagrid> has anyone here used the SF task/project manager? does it work? maybe we should switch SF's version on for python, so that people can list things they should get around to finish some day? ;-) (we could use the patch manager for this purpose, of course -- #100764 is one current example) in the long run, I'd much rather see something based on roundup (which is the best issue tracking system I've ever seen, period), but I guess nobody has time to deal with that right now... From effbot at telia.com Sun Jul 9 13:11:11 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 13:11:11 +0200 Subject: [Python-Dev] os.spawnv problem Message-ID: <011901bfe996$668ac580$f2a6b5d4@hagrid> according to the MSDN docs and my local header files, spawnv and friends return an integer, which contains the process's exit code. according to posixmodule.c (trent?), they return an intptr_t. unfortunately, this little change causes some inter- resting problems; spawnv tells me that my program returns the following exit code: 2167387144924954624 or, in another base: 0x1E141B2000000000L unless anyone can explain what those upper bit mean, and why they are relevant, I suggest casting the return code down to an int. From barry at scottb.demon.co.uk Sun Jul 9 13:50:40 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 9 Jul 2000 12:50:40 +0100 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 In-Reply-To: <019501bfe920$18cee220$f2a6b5d4@hagrid> Message-ID: <000201bfe99b$e7dff4c0$060210ac@private> > stupid question: what exactly does the RC file do here: > > STRINGTABLE DISCARDABLE > BEGIN > 2000 "Dummy" // Needed to version branding works! > END > > (couldn't really parse that comment ;-) I expect that the release engineering process will replace "Dummy" with the assigned version for the build. BArry From effbot at telia.com Sun Jul 9 15:12:04 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 15:12:04 +0200 Subject: [Python-Dev] os.spawnv problem References: <011901bfe996$668ac580$f2a6b5d4@hagrid> Message-ID: <014a01bfe9a7$4b8b64e0$f2a6b5d4@hagrid> I wrote: > according to posixmodule.c (trent?), they return an > intptr_t. > > unfortunately, this little change causes some inter- > resting problems; spawnv tells me that my program > returns the following exit code: > > 2167387144924954624 > > or, in another base: > > 0x1E141B2000000000L > > unless anyone can explain what those upper bit mean, > and why they are relevant, I suggest casting the return > code down to an int. nevermind; I found the problem: the preprocessor doesn't complain if you're comparing variables that doesn't exist, so the following code didn't quite do what the programmer had expected: #if SIZEOF_LONG == SIZE_VOID_P return Py_BuildValue("l", spawnval); #else return Py_BuildValue("L", spawnval); #endif (SIZE_VOID_P is not defined, and you cannot really expect Py_BuildValue to do the right thing if spawnval is an integer). patch coming. From akuchlin at cnri.reston.va.us Sun Jul 9 16:12:44 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 9 Jul 2000 10:12:44 -0400 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <20000709000135.Q26534@xs4all.nl>; from thomas@xs4all.net on Sun, Jul 09, 2000 at 12:01:36AM +0200 References: <396749F8.F98D2F8C@prescod.net> <200007082219.RAA08379@cj20424-a.reston1.va.home.com> <1249029961-17188506@hypernet.com> <20000709000135.Q26534@xs4all.nl> Message-ID: <20000709101244.B21174@newcnri.cnri.reston.va.us> On Sun, Jul 09, 2000 at 12:01:36AM +0200, Thomas Wouters wrote: >Agreed, though I think it should go the other way, too. And it isn't just >about discussing new features or bugs; people, or at least involved people, >like to see that there are actually people working on improving Python ;) People *do* report problems, suggest new features, or provide bugfixes on comp.lang.python, and it would be a pity to miss them; we just have to encourage people to submit through the appropriate channels. python-list is, I think, no longer a language hacking list, and that's probably a good thing. (Remember the person who once said they were shy about posting to python-list because all the discussion was so advanced?) Note for 2.0 final: the docs should mention how to submit patches, the existence of python-dev, etc. I can write a Misc/HACKING file. I'm not sure how to prevent people from inadvertently duplicating ongoing python-dev work, such as the recent case where someone mentioned adding history support to the readline module, which Skip was already doing. A summary of python-dev/CVS activity might be nice. --amk From fdrake at beopen.com Sun Jul 9 16:20:43 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 10:20:43 -0400 (EDT) Subject: [Python-Dev] __SC__ #define? In-Reply-To: References: <14696.3294.579121.909885@cj42289-a.reston1.va.home.com> Message-ID: <14696.35387.635950.631415@cj42289-a.reston1.va.home.com> Michael Hudson writes: > As Tim said, it's probably the Symantec C compiler, which is as far as I > know dead (it was more or less dead when I was last playing around > programming on the Mac, and that was several years ago). > > So unless someone screams "I still use Symantec!", I'd say nuke it. How about "If someone screams, we can add it back." I checking in the change now. Thanks, Michael & Tim! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Sun Jul 9 17:23:10 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 10:23:10 -0500 Subject: [Python-Dev] __SC__ #define? In-Reply-To: Your message of "Sun, 09 Jul 2000 11:06:36 +0100." References: Message-ID: <200007091523.KAA10316@cj20424-a.reston1.va.home.com> > So unless someone screams "I still use Symantec!", I'd say nuke it. Wait till Jack Jansen reads his email. In fact, he can nuke it himself if he doesn't need it... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Sun Jul 9 17:26:28 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 10:26:28 -0500 Subject: [Python-Dev] what about the SF task manager? In-Reply-To: Your message of "Sun, 09 Jul 2000 12:34:48 +0200." <010b01bfe991$53af7280$f2a6b5d4@hagrid> References: <010b01bfe991$53af7280$f2a6b5d4@hagrid> Message-ID: <200007091526.KAA10343@cj20424-a.reston1.va.home.com> [effbot] > has anyone here used the SF task/project manager? Not me. > does it work? Dunno. > maybe we should switch SF's version on for python, so > that people can list things they should get around to > finish some day? ;-) It's an idea. Currently these are hidden in the old TODO wizard and the "request" category in the Jitterbug-based bugs list on python.org... > (we could use the patch manager for this purpose, of > course -- #100764 is one current example) :-) > in the long run, I'd much rather see something based > on roundup (which is the best issue tracking system > I've ever seen, period), but I guess nobody has time > to deal with that right now... I've never seen roundup, either, but it is sure getting good press... Maybe one of my fellow PythonLabs employees can set it up on pythonlabs.com? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Sun Jul 9 16:34:48 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 10:34:48 -0400 (EDT) Subject: [Python-Dev] __SC__ #define? In-Reply-To: <200007091523.KAA10316@cj20424-a.reston1.va.home.com> References: <200007091523.KAA10316@cj20424-a.reston1.va.home.com> Message-ID: <14696.36232.876446.324645@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > > So unless someone screams "I still use Symantec!", I'd say nuke it. > > Wait till Jack Jansen reads his email. In fact, he can nuke it > himself if he doesn't need it... Er, too late. I can add it back if he needs it. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Sun Jul 9 17:35:07 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 10:35:07 -0500 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: Your message of "Sat, 08 Jul 2000 23:22:16 -0400." References: Message-ID: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> > I just removed all other occurrences of Py_PROTO and Py_FPROTO in the source > tree. Great work, Tim! There's one problem: several large patches that are waiting for us in the SF patch manager won't work any more because they reference context that you ripped out. I'm thinking of the augmented assignment and the list comprehensions patch, and I think Thomas Wouters' patch for [a:b:c] meaning range(a,b,c) is also broken now. I think your patch status guidelines suggest that these patches should be labeled out of date until the author uploads a new version... BTW, the more delay 2.0 incurs because of the negotiations between CNRI and BeOpen, the more sense it makes to me to add those language features! Last night I changed the status of the list comprehensions and augmented assignment patches to Open. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From barry at scottb.demon.co.uk Sun Jul 9 16:56:31 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 9 Jul 2000 15:56:31 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python Message-ID: <000001bfe9b5$de7168f0$060210ac@private> I read in the archives the problem with import of a 1.5 extension into newer Python release crashing say new Python. A solution that works is to use a new naming scheme for the initialisation entry point. Currently it is "init" + module-name with "_d" appended if it is debug image. Change "init" to "init16", "init20" and you can import the old 1.5 linked extension without a crash, you get an error reported instead. BArry From skip at mojam.com Sun Jul 9 16:17:41 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 9 Jul 2000 09:17:41 -0500 (CDT) Subject: [Python-Dev] Microsoft adopts Python In-Reply-To: References: Message-ID: <14696.35205.331898.137663@beluga.mojam.com> [ MS recommending Python before C++ ] Tim> I take back everything bad I ever said about clueless support Tim> droids . Maybe it was Bill Tutt on the phone! ;-) Skip From skip at mojam.com Sun Jul 9 16:23:41 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 9 Jul 2000 09:23:41 -0500 (CDT) Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: References: <1249029961-17188506@hypernet.com> Message-ID: <14696.35565.198655.899292@beluga.mojam.com> >> As a partial solution, perhaps we could use some self-discipline and >> sometimes say "kick it to c.l.py". Michael> .... I think it is important that comp.lang.python continues Michael> to have *some* interesting content, and that the impression is Michael> mantained that (reasonable) opinions expressed there are Michael> listened to, .... Whatever happened to the c.l.py weekly summary? David Ascher, Aaron Watters & Fredrik Lundh I think were doing it for a long time. It seems that with the python-dev archives on the web that perhaps the weekly editor could occasionally point toward specific threads to provide a high-signal intersection of the two lists. To expose interesting c.l.py threads to python-dev folks who may not track the group closely any more, perhaps the weekly summary could be posted here as well. Skip From fdrake at beopen.com Sun Jul 9 17:54:38 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 11:54:38 -0400 (EDT) Subject: [Python-Dev] Objects/ ANSI-fied Message-ID: <14696.41022.709280.192971@cj42289-a.reston1.va.home.com> Ok, the Objects/ directory has been ANSI-fied, and I've noticed /F slaving away in the Modules/ directory, so I'll get out of the way for a little bit. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Sun Jul 9 16:33:19 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 9 Jul 2000 09:33:19 -0500 (CDT) Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> References: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> Message-ID: <14696.36143.297072.353525@beluga.mojam.com> Guido> There's one problem: several large patches that are waiting for Guido> us in the SF patch manager won't work any more because they Guido> reference context that you ripped out. I'm thinking of the Guido> augmented assignment and the list comprehensions patch ... I will do a cvs update and generate a new patch today. Skip From effbot at telia.com Sun Jul 9 18:10:49 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 18:10:49 +0200 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] References: <1249029961-17188506@hypernet.com> <14696.35565.198655.899292@beluga.mojam.com> Message-ID: <003001bfe9c0$46517780$f2a6b5d4@hagrid> skip wrote: > > >> As a partial solution, perhaps we could use some self-discipline and > >> sometimes say "kick it to c.l.py". > > Michael> .... I think it is important that comp.lang.python continues > Michael> to have *some* interesting content, and that the impression is > Michael> mantained that (reasonable) opinions expressed there are > Michael> listened to, .... > > Whatever happened to the c.l.py weekly summary? David Ascher, Aaron Watters > & Fredrik Lundh I think were doing it for a long time. I'm still doing the daily edition: http://hem.passagen.se/eff/url.htm http://hem.passagen.se/eff/url-archive.htm Andrew took over the weekly edition a while ago (the latest issue is june 27, I think). For the daily edition, most of the interesting material comes from other sources (oreillynet, linuxdev.net, etc). comp.lang.python varies wildly; some weeks, there are lots of good stuff. Other weeks, I cannot find anything relevant at all... From skip at mojam.com Sun Jul 9 16:38:21 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 9 Jul 2000 09:38:21 -0500 (CDT) Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) Message-ID: <14696.36445.834366.510392@beluga.mojam.com> Interesting feature request from c.l.py... Skip -------------- next part -------------- An embedded message was scrubbed... From: Olmy Subject: Feature Request: IPv6 support built into 1.6/2.0 Date: Sun, 9 Jul 2000 10:47:03 -0500 (CDT) Size: 1360 URL: From effbot at telia.com Sun Jul 9 18:21:17 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 18:21:17 +0200 Subject: [Python-Dev] Objects/ ANSI-fied References: <14696.41022.709280.192971@cj42289-a.reston1.va.home.com> Message-ID: <004b01bfe9c1$b9354820$f2a6b5d4@hagrid> fred wrote: > Ok, the Objects/ directory has been ANSI-fied, and I've noticed /F > slaving away in the Modules/ directory, so I'll get out of the way for > a little bit. ;) well, I've been checking in Peter Schneider-Kamp's patches. but most of the remaining modules are Unix-only, and I'm on a Win95 box right now. so if anyone wants to make a stab at the patches in the 100768-100787 range, please go ahead. (fred, to give you more things to do, I just assigned Rob's big spelling patch to you, since large parts of it affect the documentation) cheers /F From effbot at telia.com Sun Jul 9 18:27:24 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 18:27:24 +0200 Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) References: <14696.36445.834366.510392@beluga.mojam.com> Message-ID: <005901bfe9c2$9232e740$f2a6b5d4@hagrid> > Interesting feature request from c.l.py... checking the eff-bot archive. wait a sec... yes, here it is: ftp://ftp.kame.net/pub/kame/misc/ has patches for 1.5.2 netbsd (and iirc, debian?) folks has also been working on this; here's one note: http://mail-index.netbsd.org/netbsd-bugs/2000/01/19/0017.html "of course, need to submit IPv6 support patch to original author (did in the past but he looked busy)" are they talking about guido, perhaps? From thomas at xs4all.net Sun Jul 9 18:25:03 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 18:25:03 +0200 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <14696.36143.297072.353525@beluga.mojam.com>; from skip@mojam.com on Sun, Jul 09, 2000 at 09:33:19AM -0500 References: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> <14696.36143.297072.353525@beluga.mojam.com> Message-ID: <20000709182503.X26534@xs4all.nl> On Sun, Jul 09, 2000 at 09:33:19AM -0500, Skip Montanaro wrote: > Guido> There's one problem: several large patches that are waiting for > Guido> us in the SF patch manager won't work any more because they > Guido> reference context that you ripped out. I'm thinking of the > Guido> augmented assignment and the list comprehensions patch ... > I will do a cvs update and generate a new patch today. Same here. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sun Jul 9 18:32:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 18:32:25 +0200 Subject: [Python-Dev] new popen for win32! [status update] References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> Message-ID: <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> current status: > - should this go into the "nt" (posix) module, or should > I create a new module? I just checked in a new version of posixmodule.c, which uses Bill's implementation instead of _popen. works just fine, on the boxes I've tested it on. > - "win32popenWin9x.exe" is a rather unwieldy name for a > file. does anyone have a better suggestion? > > python_popen.exe > py_popen9x.exe > popenStub.exe > > ...? tim suggested "w9xpopen.exe", which as good as it gets. I've checked in the PC/w9xpopen.c file, but I haven't up- dated the build files (see below): > - I'm using VC5 on this box, so I should probably avoid > checking in my modified project files. any VC6-wielding > volunteers out there? tim will fix this. > - first, a stupid question: is the popen2 and popen3 > versions replacements for the corresponding functions > in the popen2 module. > > (or to put it another way: should the popen2 module > be modified to use these functions on Windows?) the new posix code exports popen2, popen3, and popen4 on windows. I'll provide patches for popen2.py later (gotta do some more testing first). cheers /F From effbot at telia.com Sun Jul 9 18:44:24 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 18:44:24 +0200 Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) References: <14696.36445.834366.510392@beluga.mojam.com> <005901bfe9c2$9232e740$f2a6b5d4@hagrid> Message-ID: <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid> I wrote: > ftp://ftp.kame.net/pub/kame/misc/ has patches for 1.5.2 the patch looks fairly clean to to me. if anyone wants to check with the original author, and update the patch for 2.0, I'm definitely +1 on this one. From jeremy at alum.mit.edu Sun Jul 9 18:42:22 2000 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Sun, 9 Jul 2000 12:42:22 -0400 Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: <20000709101244.B21174@newcnri.cnri.reston.va.us> Message-ID: >I'm not sure how to prevent people from inadvertently duplicating >ongoing python-dev work, such as the recent case where someone >mentioned adding history support to the readline module, which Skip >was already doing. A summary of python-dev/CVS activity might be >nice. This sounds very good! In the Perl world, there is a weekly summary of discussion on the perl5-porters list. It seems to be written by Mark-Jason Dominus most (all?) of the time. We could do the same thing if we could find people to do it. Perhaps a weekly Python-dev URL? If we had enough reporters, it might not be too much work. Volunteers? I'd be happy to coordinate. Jeremy From fdrake at beopen.com Sun Jul 9 18:48:56 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 12:48:56 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib webbrowser.py,NONE,1.1 In-Reply-To: <200007091645.JAA26779@slayer.i.sourceforge.net> References: <200007091645.JAA26779@slayer.i.sourceforge.net> Message-ID: <14696.44280.536157.31030@cj42289-a.reston1.va.home.com> Fred L. Drake writes: > Update of /cvsroot/python/python/dist/src/Lib The bogus lock in the Lib/ directory is clear; one of the SF guys was out of town for a few days. (Don't know about the others.) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sun Jul 9 19:01:23 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 13:01:23 -0400 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> Message-ID: [Tim] > I just removed all other occurrences of Py_PROTO and Py_FPROTO > in the source tree. [Guido] > Great work, Tim! If I have demacrofied more than others, it is because I've stood on the throat of Fred Drake . > There's one problem: several large patches that are waiting for us > in the SF patch manager won't work any more because they reference > context that you ripped out. Revolution, eggs, break, sorry. > I'm thinking of the augmented assignment and the list comprehensions > patch, and I think Thomas Wouters' patch for [a:b:c] meaning > range(a,b,c) is also broken now. > > I think your patch status guidelines suggest that these patches should > be labeled out of date until the author uploads a new version... Yes. > BTW, the more delay 2.0 incurs because of the negotiations between > CNRI and BeOpen, the more sense it makes to me to add those language > features! Last night I changed the status of the list comprehensions > and augmented assignment patches to Open. That makes sense to me, and not just because I've been keen on augmented assignment since before Python 1.0, and keen on listcomps since they first came up. Perhaps the person assigned to these patches would care to keep their statuses up to date? Not naming any names here , but if patch ownership means anything, it means owning the next step in the patch process. resisting-a-bad-precedent-ly y'rs - tim From tim_one at email.msn.com Sun Jul 9 19:04:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 13:04:42 -0400 Subject: [Python-Dev] new popen for win32! [status update] In-Reply-To: <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> Message-ID: [/F] > I just checked in a new version of posixmodule.c, which > uses Bill's implementation instead of _popen. works just > fine, on the boxes I've tested it on. > ... Thank you, Frederik! This stuff looks great. I believe I've got everything I need now to update the MSVC6 project files and installer and assorted readmes, and I'll do that later today (several hours from now). have-to-pause-once-a-week-to-eat-ly y'rs - tim From effbot at telia.com Sun Jul 9 19:37:35 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 19:37:35 +0200 Subject: [Python-Dev] new popen for win32! [status update] References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> Message-ID: <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> following up on myself: > > - first, a stupid question: is the popen2 and popen3 > > versions replacements for the corresponding functions > > in the popen2 module. > > > > (or to put it another way: should the popen2 module > > be modified to use these functions on Windows?) > > the new posix code exports popen2, popen3, and popen4 > on windows. I'll provide patches for popen2.py later (gotta > do some more testing first). the current api is: popen2.popen2(command, bufsize=default) popen2.popen3(command, bufsize=default) vs. nt.popen2(command, mode="t") nt.popen3(command, mode="t") the perfect compromise would of course be popen2(command, mode="t", bufsize=default) (similar to plain open). I suggest the popen2 api's to: def popen2.popen2(command, mode="t", bufsize=-1): if type(mode) is type(0) and bufsize==-1: bufsize = mode mode = "t" ... def nt.popen2(command, mode, bufsize=-1): if bufsize != -1: raise ValueError, "cannot set buffer size on windows" comments? From skip at mojam.com Sun Jul 9 18:03:00 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 9 Jul 2000 11:03:00 -0500 (CDT) Subject: [Python-Dev] patch for os.path.commonprefix (changes semantics - pls review) Message-ID: <14696.41524.306876.462534@beluga.mojam.com> os.path.commonprefix seems broken to me. If you ask it to return the common prefix of "/home/swen/spam" and "/home/swan/eggs", it returns "/home/sw". Since we are talking file paths, not strings, I think the common prefix should be "/home". Since my patch changes the semantics of the function, I submitted a patch via SF that implements what I believe to be the correct behavior instead of just checking in the change, so people could comment on it. Also, since the version in ntpath.py was the same as the version in posixpath.py I modified both, replacing "/" with os.sep (is that correct?). Note that I can't check that it returns something useful on NT, though I suspect it will. There is no commonprefix function in macpath.py. Is this a function that would have no meaning on the Mac? The patch is available for review at http://sourceforge.net/patch/?func=detailpatch&patch_id=100788&group_id=5470 Skip From effbot at telia.com Sun Jul 9 19:48:41 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 9 Jul 2000 19:48:41 +0200 Subject: [Python-Dev] patch for os.path.commonprefix (changes semantics - pls review) References: <14696.41524.306876.462534@beluga.mojam.com> Message-ID: <015e01bfe9cd$ee090800$f2a6b5d4@hagrid> skip wrote: > Also, since the version in ntpath.py was the same as the version in > posixpath.py I modified both, replacing "/" with os.sep (is that correct?). see my comment on the site (in short: you should split on either os.sep or os.altsep, or normalize before splitting. and don't forget UNC names: \\machine\directory...). From thomas at xs4all.net Sun Jul 9 20:49:21 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 20:49:21 +0200 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 09, 2000 at 01:01:23PM -0400 References: <200007091535.KAA13650@cj20424-a.reston1.va.home.com> Message-ID: <20000709204921.Y26534@xs4all.nl> On Sun, Jul 09, 2000 at 01:01:23PM -0400, Tim Peters wrote: > Perhaps the person assigned to these patches would care to keep > their statuses up to date? Not naming any names here , [..] Well, augmented assignment isn't assigned to anyone yet, so I guess I'll keep it up to date ;) Besides, it can be tricky to keep a patch up to date if you didn't write it yourself: you might fail to notice tiny details the original author had in the back of his head. Not that this particular clash was hard to resolve, of course, it was mostly context-clash, plus the issue of writing the patch ANSI style itself ;) Unless of course being assigned to a patch means you have to know it as well as the author(s), in which case I hush up and wait for Guido to assign you to the augassign patch ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sun Jul 9 20:54:01 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 20:54:01 +0200 Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) In-Reply-To: <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jul 09, 2000 at 06:44:24PM +0200 References: <14696.36445.834366.510392@beluga.mojam.com> <005901bfe9c2$9232e740$f2a6b5d4@hagrid> <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid> Message-ID: <20000709205401.Z26534@xs4all.nl> On Sun, Jul 09, 2000 at 06:44:24PM +0200, Fredrik Lundh wrote: > I wrote: > > ftp://ftp.kame.net/pub/kame/misc/ has patches for 1.5.2 > the patch looks fairly clean to to me. > if anyone wants to check with the original author, and update > the patch for 2.0, I'm definitely +1 on this one. Out of curiousity, what does the patch rely on ? I toyed around with IPv6 a while back (err, make that 3 years back. Gosh, does time fly!) and setting it up was pretty involved, getting the right client libraries and stuff. Is there anything like a standard interface, nowadays, or will the socket (or is that 'socket6' ?) library have to worry about all kinds of different interfaces ? I'd check the patch out, had I the time ;P I might get it late next week or so. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Sun Jul 9 21:04:20 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 15:04:20 -0400 (EDT) Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) In-Reply-To: <20000709205401.Z26534@xs4all.nl> References: <14696.36445.834366.510392@beluga.mojam.com> <005901bfe9c2$9232e740$f2a6b5d4@hagrid> <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid> <20000709205401.Z26534@xs4all.nl> Message-ID: <14696.52404.703807.177420@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > Out of curiousity, what does the patch rely on ? I toyed around with IPv6 a > while back (err, make that 3 years back. Gosh, does time fly!) and setting > it up was pretty involved, getting the right client libraries and stuff. > Is there anything like a standard interface, nowadays, or will the socket > (or is that 'socket6' ?) library have to worry about all kinds of different There's a standard API for both "normal" and advanced features of IPv6 sockets defined in some IETF documents; I'm not sure of their current state, but they've been in development for a while, so they might even be RFCs by now. > I'd check the patch out, had I the time ;P I might get it late next week or > so. I may look at them in a few days as well. Multiple opinions may be very valuable on a topic as detailed and pervasive as this! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From petersc at stud.ntnu.no Sun Jul 9 23:13:15 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Sun, 09 Jul 2000 21:13:15 +0000 Subject: [Python-Dev] PROTO_LIST in Modules/md5.h Message-ID: <3968EAEB.A06D9A38@stud.ntnu.no> Is this still needed with ANSI? Thanks, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From thomas at xs4all.net Sun Jul 9 21:16:42 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 21:16:42 +0200 Subject: [Python-Dev] PROTO_LIST in Modules/md5.h In-Reply-To: <3968EAEB.A06D9A38@stud.ntnu.no>; from petersc@stud.ntnu.no on Sun, Jul 09, 2000 at 09:13:15PM +0000 References: <3968EAEB.A06D9A38@stud.ntnu.no> Message-ID: <20000709211641.B26534@xs4all.nl> On Sun, Jul 09, 2000 at 09:13:15PM +0000, Peter Schneider-Kamp wrote: > Is this still needed with ANSI? No, and it isn't necessary with K&R C either, just if you wish to use both at the same time ;) It's the same as the Py_PROTO macro, and should be removed, yes. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Sun Jul 9 21:19:29 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 15:19:29 -0400 (EDT) Subject: [Python-Dev] PROTO_LIST in Modules/md5.h In-Reply-To: <3968EAEB.A06D9A38@stud.ntnu.no> References: <3968EAEB.A06D9A38@stud.ntnu.no> Message-ID: <14696.53313.296096.777677@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > Is this still needed with ANSI? No, but this is imported code, so perhaps it makes sense to leave that in. (Both md5.c and md5.h are imported, and are the only places that have this.) I won't object to ANSI-fying these two files, but I'm not sure it makes sense, either. These may as well be an external library. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Sun Jul 9 21:21:41 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 15:21:41 -0400 (EDT) Subject: [Python-Dev] Out of loop... Message-ID: <14696.53445.235099.144979@cj42289-a.reston1.va.home.com> Ok, it's been a busy week, and my wife & kids are just about back. I'll be largely out of touch here for about 24 hours. It's time to play with the kids! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sun Jul 9 21:38:05 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 15:38:05 -0400 Subject: [Python-Dev] Py_PROTO elimination in Include/ In-Reply-To: <20000709204921.Y26534@xs4all.nl> Message-ID: [Tim] > Perhaps the person assigned to these patches would care to keep > their statuses up to date? Not naming any names here , [..] [Thomas Wouters, with his heart in the right place but on the wrong track] > Well, augmented assignment isn't assigned to anyone yet, so I guess > I'll keep it up to date ;) Keeping a patch up to date is different than keeping the patch *status* up to date. I was talking about the latter. When Guido (or anyone else) notices that a patch is out of date, I am gently suggesting that they change the SourceForge Patch Manager Status field to "Out of date" themself (rather than, e.g., leaving the status "Open" and posting to Python-Dev that the status is wrong now -- the latter is an instance of the "active mailing list write-only black hole" we moved to SF to get away from). From thomas at xs4all.net Sun Jul 9 21:40:59 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 21:40:59 +0200 Subject: [Python-Dev] Out of loop... In-Reply-To: <14696.53445.235099.144979@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Sun, Jul 09, 2000 at 03:21:41PM -0400 References: <14696.53445.235099.144979@cj42289-a.reston1.va.home.com> Message-ID: <20000709214058.D26534@xs4all.nl> On Sun, Jul 09, 2000 at 03:21:41PM -0400, Fred L. Drake, Jr. wrote: > Ok, it's been a busy week, and my wife & kids are just about back. > I'll be largely out of touch here for about 24 hours. It's time to > play with the kids! Damn, this scares me. Even at my real-life job we don't warn eachother when we're out of the loop for a day or so. We've had a colleague go on a vacation, and not be missed for like a week before anyone started wondering where he was ;-) And here is Fred apologizing for spending a day with his family. Is it too late for me to opt out ?!? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Sun Jul 9 21:47:37 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 15:47:37 -0400 (EDT) Subject: [Python-Dev] Out of loop... In-Reply-To: <20000709214058.D26534@xs4all.nl> References: <14696.53445.235099.144979@cj42289-a.reston1.va.home.com> <20000709214058.D26534@xs4all.nl> Message-ID: <14696.55001.491151.543374@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > Damn, this scares me. Even at my real-life job we don't warn eachother when > we're out of the loop for a day or so. We've had a colleague go on a > vacation, and not be missed for like a week before anyone started wondering > where he was ;-) And here is Fred apologizing for spending a day with his > family. Is it too late for me to opt out ?!? You have to realize -- right now, email is the *primary* communications mechanism for PythonLabs, both internally and with the community. If we don't know that someone is away from their mail, we expect rapid response. Given my past week, there've been very few hours I've been away from my mail. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sun Jul 9 22:03:06 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 16:03:06 -0400 Subject: [Python-Dev] Out of loop... In-Reply-To: <20000709214058.D26534@xs4all.nl> Message-ID: [Fred L. Drake, Jr.] > Ok, it's been a busy week, and my wife & kids are just about back. > I'll be largely out of touch here for about 24 hours. It's time to > play with the kids! [Thomas Wouters, understandly terrified by the implications] > ... > And here is Fred apologizing for spending a day with his family. Is it > too late for me to opt out ?!? Far too late, yes. Your ours for life now (and probably longer, if CNRI has any say in the matter <0.9 wink>). [Fred again, rationalizing] > You have to realize -- right now, email is the *primary* communications > mechanism for PythonLabs, both internally and with the community. Actually, the community may not realize that we don't have an office, Jeremy and Barry live in a different state than Guido and Fred, and Tim is living in a hotel (although I think I've been careful to whine about the latter often enough here ). The *important* thing to notice, though, is that Fred is still replying to email instantly even after swearing on all that is holy that he'd be out of touch for 24 hours. pythonlabs-has-zero-tolerance-for-wimps-ly y'rs - tim From guido at beopen.com Sun Jul 9 23:52:13 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 16:52:13 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Sun, 09 Jul 2000 15:56:31 +0100." <000001bfe9b5$de7168f0$060210ac@private> References: <000001bfe9b5$de7168f0$060210ac@private> Message-ID: <200007092152.QAA14143@cj20424-a.reston1.va.home.com> > I read in the archives the problem with import of a 1.5 extension > into newer Python release crashing say new Python. > > A solution that works is to use a new naming scheme for the > initialisation entry point. Currently it is "init" + module-name > with "_d" appended if it is debug image. > > Change "init" to "init16", "init20" and you can import the old > 1.5 linked extension without a crash, you get an error reported > instead. Nice idea... Unfortunately it means that every module must be changed. If we want to do this, we'd best introduce a macro! E.g. (untested): #define Py_INIT(modname) DL_EXPORT(void) init20##modname() --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Sun Jul 9 23:53:42 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 16:53:42 -0500 Subject: [Python-Dev] Objects/ ANSI-fied In-Reply-To: Your message of "Sun, 09 Jul 2000 11:54:38 -0400." <14696.41022.709280.192971@cj42289-a.reston1.va.home.com> References: <14696.41022.709280.192971@cj42289-a.reston1.va.home.com> Message-ID: <200007092153.QAA14165@cj20424-a.reston1.va.home.com> > Ok, the Objects/ directory has been ANSI-fied, and I've noticed /F > slaving away in the Modules/ directory, so I'll get out of the way for > a little bit. ;) Great! Sounds like everybody is getting the hint that 2.0 needs to have some distinguishing characteristics compared to 1.6... :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From tim_one at email.msn.com Sun Jul 9 22:55:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 16:55:52 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <20000628010407.T29590@lyra.org> Message-ID: [Tim] > OTOH, we're also interested in *helping* SF get better! SF is > as much an Open Source project as Python, and it could become > an incredible resource for the entire OS community. [Greg Stein [mailto:gstein at lyra.org] Sent: Wednesday, June 28, 2000 4:04 AM] > This last statement is (unfortunately) not quite true. SourceForge is > developed in a closed, cathedral environment. There is no CVS > access to it, and all the developers work at VA Linux. Strictly speaking, > the *output* of this closed development is GPL'd. But it isn't what you > would expect. Ah! You were reading my stmt as a claim about SF, rather than as a warning about the new status of Python . Just kidding. I was talking out of my ass there, and appreciate the correction. From tim_one at email.msn.com Sun Jul 9 22:55:45 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 16:55:45 -0400 Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: <20000627101658.E7257@activestate.com> Message-ID: [Trent Mick Sent: Tuesday, June 27, 2000 1:17 PM] > What are the chances of getting other meta data fields on patches, i.e. > changes to the patch manager? A question for SourceForge. > Categorizing patches could really help as a filter. For instance, I > may be a Unicode genius and would like to see the patches associated > with it. There's already a "Category" field on SF patches, but the main view doesn't show it (you have to look at an individual patch to see it) and there's apparently no way to filter on it either. Also think you have to be an admin to create a new category. I'll confess in advance, though, that I expect each additional field will just be one more field set incorrectly on the vast minority of patches. > ... > Perhaps ownership (i.e. 'assigned to') of the patch should transfer > to the person responsible for later taking to patch out of 'postponed' > status. Yes; thank you; I'll post a revision later today. The intent was always that "assigned to" be the most likely person to take action next. From guido at beopen.com Mon Jul 10 00:02:37 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 17:02:37 -0500 Subject: [Python-Dev] new popen for win32! [status update] In-Reply-To: Your message of "Sun, 09 Jul 2000 19:37:35 +0200." <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> Message-ID: <200007092202.RAA14221@cj20424-a.reston1.va.home.com> > the current api is: > > popen2.popen2(command, bufsize=default) > popen2.popen3(command, bufsize=default) > > vs. > > nt.popen2(command, mode="t") > nt.popen3(command, mode="t") Not commenting on the question here, but on the return tuple: should it be (i,o,e) or (o,i,e)? The popen2 module uses the latter, but that's hard to remember for Unix-droids: it corresponds to (1,0,2) in file descriptors. So if it's not too late, let's do (i,o,e). (I tried to read the posixmodule.c source but got lost...) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From tim_one at email.msn.com Sun Jul 9 23:07:40 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 17:07:40 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Message-ID: [Fred L. Drake, Jr. Sent: Wednesday, June 28, 2000 9:30 AM] > ... > the only problem I've had with IE5 is accessing a project's anonymous > FTP area from the project page (IE5 just froze completely). This happens to me too. And a new problem popped up early this weekend (maybe Friday already): when I click the "Browse CVS Repository" link near the bottom right of http://sourceforge.net/cvs/?group_id=5470 IE5 pops up a box asking me whether I really want to download file "cvsweb". Useless! This used to work fine, and I sure haven't changed my IE setup. Clearing the browser caches didn't help. The link resolves to http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi?cvsroot=python today, and I don't know whether it resolved to something different last week. Also have no idea how browsers decide what to do -- it's not simple & straightforward, like e.g. floating-point arithmetic . .cgi is not an extension registered on my machine either. From petersc at stud.ntnu.no Mon Jul 10 01:17:44 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Sun, 09 Jul 2000 23:17:44 +0000 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix References: <396780B6.67247E2C@stud.ntnu.no> <200007082334.SAA08816@cj20424-a.reston1.va.home.com> Message-ID: <39690818.917030DE@stud.ntnu.no> While "slaving away" on the Modules/ directory (thanks for the term - it made my day ), I still haven't got a clue why Python crashes on me when I throw an error on duplicate arguments like in: [example] >>> def f(a, a): print a segfault [/example] Any help is again appreciated. Or should I just load up that mini patch to SF and wait for some unlucky guy that assigns it on himself <0.5 wink>? okay, back to Modules/r* - z* Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de -------------- next part -------------- diff -c -d -T --recursive python/dist/src/Python/compile.c python-mod/dist/src/Python/compile.c *** python/dist/src/Python/compile.c Mon Jul 3 21:39:47 2000 --- python-mod/dist/src/Python/compile.c Sun Jul 9 02:04:26 2000 *************** *** 3092,3097 **** --- 3092,3098 ---- node *ch = CHILD(n, i); node *fp; char *name; + PyObject *nameval; if (TYPE(ch) == STAR || TYPE(ch) == DOUBLESTAR) break; REQ(ch, fpdef); /* fpdef: NAME | '(' fplist ')' */ *************** *** 3103,3109 **** sprintf(nbuf, ".%d", i); complex = 1; } ! com_newlocal(c, name); c->c_argcount++; if (++i >= nch) break; --- 3104,3118 ---- sprintf(nbuf, ".%d", i); complex = 1; } ! nameval = PyString_InternFromString(name); ! if (nameval == NULL) { ! c->c_errors++; ! } ! if (PyDict_GetItem(c->c_locals, nameval)) { ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); ! } ! com_newlocal_o(c, nameval); ! Py_DECREF(nameval); c->c_argcount++; if (++i >= nch) break; From guido at beopen.com Mon Jul 10 00:27:33 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 17:27:33 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib popen2.py,1.9,1.10 In-Reply-To: Your message of "Sun, 09 Jul 2000 10:59:34 MST." <200007091759.KAA04874@slayer.i.sourceforge.net> References: <200007091759.KAA04874@slayer.i.sourceforge.net> Message-ID: <200007092227.RAA14284@cj20424-a.reston1.va.home.com> > - changed nt.popen2/popen3/popen4 return values > to match the popen2 module (stdout first, not > stdin). Really? Isn't that a horrid order? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 00:31:58 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 17:31:58 -0500 Subject: [Python-Dev] Feature Request: IPv6 support built into 1.6/2.0 (fwd) In-Reply-To: Your message of "Sun, 09 Jul 2000 15:04:20 -0400." <14696.52404.703807.177420@cj42289-a.reston1.va.home.com> References: <14696.36445.834366.510392@beluga.mojam.com> <005901bfe9c2$9232e740$f2a6b5d4@hagrid> <00bc01bfe9c4$f17e20a0$f2a6b5d4@hagrid> <20000709205401.Z26534@xs4all.nl> <14696.52404.703807.177420@cj42289-a.reston1.va.home.com> Message-ID: <200007092231.RAA14305@cj20424-a.reston1.va.home.com> I remember that someone from Japan (the KAME folks?) submitted IPv6 patches before -- maybe a year ago. Unfortunately, they had only tested it on one platform (*bsd?), and the porting instructions they gave didn't work at all on any platform I had access to (Solaris, Linux). If the portability of the new patches is up to snuff, I'd be all for integrating this. Ideally, it would detect at configure time whether IPv6 support is available and do the right thing. I suppose there's a POSIX standard for IPv6 socket extensions etc. somewhere? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Sun Jul 9 23:35:26 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 23:35:26 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14695.840.448508.397722@beluga.mojam.com>; from skip@mojam.com on Sat, Jul 08, 2000 at 05:32:40AM -0500 References: <14691.49563.78765.683762@beluga.mojam.com> <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> <14695.840.448508.397722@beluga.mojam.com> Message-ID: <20000709233525.E26534@xs4all.nl> On Sat, Jul 08, 2000 at 05:32:40AM -0500, Skip Montanaro wrote: > Since Fredrik's voice is the only one I heard, and on the off-chance that > the CNRI/BeOpen discussions and resulting 1.6 release push things out a bit > (allowing a feature thaw) I'll oblige. I have a couple of questions regarding this patch, if you don't mind. I didn't appoint myself arbiter of new code, and I'm certainly not a kind of spanish inquisition, but I really have to scratch my head when reading this patch (and the resulting code.) I hope you don't take it personal ;P Also, I'm not criticising the new feature, just wondering about the implementation. For one, the Grammar for list comprehensions: '[' [testlist [list_iter]] ']' Should that really be 'testlist' ? As far as I can see, it should be 'test' rather than 'testlist'. This is kind of nit-picky, but the presence of the list_iter part completely changes the meaning of the testlist in front of it: [1,2,3,4,5] is a list of 5 elements, but [1,2,3,4,5 if 1] is a list of one element, which is a 5-element tuple. I'd say the Grammar would be more like this: atom: '(' [testlist] ')' | '[' [listmaker] ']' | '{' [dictmaker] '}' | '' testlist '' | NAME | NUMBER | STRING+ listmaker: test ( list_iter | (',' test)* [',']) list_iter: list_for | list_if list_for: 'for' exprlist 'in' testlist [list_iter] list_if: 'if' test [list_iter] And by coincidence this is also fits very nicely with what the 'range-literal' patch does ;-) Another issue is the code- and logic-duplication of the patch to compile.c: it looks like a large part was just copied from com_for_node, and the block-stuff commented out. Why is it commented out, by the way ? Don't exceptions or something need the block setup ? If the block-setup was kept in, it might be easier to split the com_for_node into a function that compiles the header, and one that compiles the suite, and make com_list_for compile its own 'suite'. I'm hoping that's possible, because it would keep the code a lot cleaner, and it would make it easier for me to implement 'for i in x;j in y' and have it work for list comprehensions too ;-) Also, the patch creates a list, stores it locally, and calls append() to it inside the inner loop. Isn't it possible for the patch to build the list on the stack, pushing individual elements on the stack and calling BUILD_LIST at the end ? The for loops counts the number of loops anyway ;) and it would get rid of the fairly ugly tmpname thing altogether, I think. However, the logic of when to ROT_THREE and ROT_TWO and what not might run away from under us ;-P (But I'm facing that anyway, with the parallel-forloop) Alternatively, it would be nice to store the lists' append() in a local vrbl, to reduce the number of lookups ;-P Oh, and lastly, the patch is just screaming for a re-indent all over, and of some wel-placed comments... some of it was quite difficult to follow, compared to the rest of the code. Just-showing-I-care-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Mon Jul 10 00:34:52 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 17:34:52 -0500 Subject: [Python-Dev] PROTO_LIST in Modules/md5.h In-Reply-To: Your message of "Sun, 09 Jul 2000 15:19:29 -0400." <14696.53313.296096.777677@cj42289-a.reston1.va.home.com> References: <3968EAEB.A06D9A38@stud.ntnu.no> <14696.53313.296096.777677@cj42289-a.reston1.va.home.com> Message-ID: <200007092234.RAA14334@cj20424-a.reston1.va.home.com> > Peter Schneider-Kamp writes: > > Is this still needed with ANSI? > > No, but this is imported code, so perhaps it makes sense to leave > that in. (Both md5.c and md5.h are imported, and are the only places > that have this.) > I won't object to ANSI-fying these two files, but I'm not sure it > makes sense, either. These may as well be an external library. I'd say ANSIfy them. While they are derived from external code, they have been hacked enough, and the MD5 algorithm isn't going to change any time soon, so we might as well reformat them and generally clean them up according to our current taste. Of course, it's not high priority stuff, but sometimes it helps putting our "mark" on code. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jack at oratrix.nl Sun Jul 9 23:50:52 2000 From: jack at oratrix.nl (Jack Jansen) Date: Sun, 09 Jul 2000 23:50:52 +0200 Subject: [Python-Dev] Venting some steam on current developments Message-ID: <20000709215057.95047E2673@oratrix.oratrix.nl> I'm getting pretty depressed at the way Python development is proceeding at the moment. I spent all evening tonight on what seemed to be an almost trivial task: fixing the default unicode conversion on the Mac. All the machinery is there, the MacOS API has some nice conversion routines so I thought it'd be a question of putting in a few hooks and be done, but that turned out not to be so. The first problem (for which I can't blame the Python community, I guess:-) is that the names mac_roman and such are not official IANA names for the Mac encodings. Actually, it turns out there _are_ no official names, so the Mac APIs to turn encodings into names work wonderful for things including all ISO encodings, windows encodings, etc, but not for the native mac encodings. Sigh. Okay, we do this ourselves. Then I spent an hour recompiling Python because this *&^^$%&*^%$ setdefaultencoding didn't show up in sys for no conceivable reason. It turns out it is *deleted* in site.py after using it once. A comment in sysmodule.c would have been rather nice here... And then I found out that locale uses only environment variables to obtain all the basic encoding info in the first place, so that also has to be fixed up seriously. So many things are changing at the moment, and there seems to be so little thought of any platform that isn't linux or windows, that I think Python's portability to minority platforms is being seriously threatened. And at least I follow closely what is happening, I really don't want to think of the poor people who do BeOS or WinCE or Palm Python. Or even some of the lesser-used Unix ports. I'm fed up, I'll continue hacking tomorrow, if I don't have to spend yet another evening trying to get Python to compile again:-( -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From thomas at xs4all.net Sun Jul 9 23:55:47 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 9 Jul 2000 23:55:47 +0200 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 09, 2000 at 05:07:40PM -0400 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Message-ID: <20000709235547.F26534@xs4all.nl> On Sun, Jul 09, 2000 at 05:07:40PM -0400, Tim Peters wrote: > And a new problem popped up early this weekend (maybe Friday already): when > I click the "Browse CVS Repository" link near the bottom right of > > http://sourceforge.net/cvs/?group_id=5470 > > IE5 pops up a box asking me whether I really want to download file "cvsweb". > Useless! This used to work fine, and I sure haven't changed my IE setup. > Clearing the browser caches didn't help. The link resolves to > > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi?cvsroot=python > > today, and I don't know whether it resolved to something different last > week. Also have no idea how browsers decide what to do -- it's not simple & > straightforward, like e.g. floating-point arithmetic . .cgi is not an > extension registered on my machine either. Actually, it's supposed to be simple and straightforward. Unfortunately, certain Windows programs decided not to play along ;) HTTP responses contain a header 'Content-Type', which should be a mimetype for the file the HTTP response accompanies. They may also contain a 'Content-Disposition' header, which contains a suggested filename for when writing the file to disk. Now, the Content-Type thing is working okay nowadays, even though you can override it (sometimes) using the 'helpers' or 'applications' settings in your browser ;) But the Content-Disposition header creates a ton of confusion on IE. Some versions of IE seem to think that when it's present, a file should *always* be saved to disk, instead of shown, regardless of mimetype and/or helper applications. Also, some versions of IE go completely bananas if the Content-Disposition header is listed before the Content-Type header, and gives a very strange response: a 'page not found' error without saying which page it was trying to download ;) I know all this for a fact, because we provide our customers with 'Secure Webmail', a web interface to their email (next to normal interfaces, of course.) And for a long while our helpdesk was forced to tell our IE-using users to switch to Netscape, because IE was giving the above errors, and more. Eventually, my boss and I spent two days with a couple of windows boxes trying to figure out why this was happening. by tcpdumping and tracing exactly what was being sent and received. (Not that easy, given that it was 1) a switched network on our side, 2) a special load-balancing-switch on the server side, and 3) 'Secure' Webmail, using SSL ;) We managed to track the above bugs when using non-SSL connections, but a few bugs remained in SSL only, and we never figured out how or why :P The bugs are really obscure: IE sometimes giving an error when clicking on 'new mailbox', but usually it went fine. IE giving a popup with some unclear error message out of the blue. Sometimes showing images, sometimes offering them for download. All in all, I'm no longer suprised when something dynamic (CGI scripts, php/asp/jsp pages, whatever) refuses to work properly with IE ;) Quite a depressing thing to know, this, but you can't always blame the website-owners or the software developers. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Mon Jul 10 00:08:21 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 18:08:21 -0400 Subject: [Python-Dev] Revision 2 of Patch Manager guidelines Message-ID: I believe the attached addresses all questions (but no "new feature requests") that were raised. Note especially the new threat to do "random assignment" of incoming patches, the new request that you comment on patches assigned to you at least weekly, and the new request that you take yourself off of patches you're assigned to but not actively pursuing. We already have patches just sitting there without action or comment for no apparent reason, and *something* has to force those to move along. at-least-now-we-can-see-which-patches-those-are-ly y'rs - tim Intended use of SourceForge patch status & "assigned to" fields --------------------------------------------------------------- revision 2 09-Jul-2000 In general, the status field should be close to self-explanatory, and the "assigned to" field should be the person responsible for taking the next step in the patch process. Both fields are expected to change value over the life of a patch; the normal workflow is detailed below. When you've got the time and the ability, feel free to move any patch that catches your eye along, whether or not it's been assigned to you. And if you're assigned to a patch but aren't going to take reasonably quick action (for whatever reason), please assign it to someone else ASAP: at those times you can't actively help, actively get out of the way. If you're an expert in some area and know that a patch in that area is both needed and non-controversial, just commit your changes directly -- no need then to get the patch mechanism involved in it. You should add a comment to every patch assigned to you at least once a week, if only to say that you realize it's still on your plate. This rule is meant to force your attention periodically: patches get harder & harder to deal with the longer they sit. Open The initial status of all patches. The patch is under consideration, but has not been reviewed yet. The status will normally change to Accepted or Rejected next. The person submitting the patch should (if they can) assign it to the person they most want to review it. Else the patch will be assigned via [xxx a list of expertise areas should be developed] [xxx but since this hasn't happened and volunteers are too few, random assignment is better than nothing: if you're a Python developer, expect to get assigned out of the blue!] Discussion of major patches is carried out on the Python-Dev mailing list. For simple patches, the SourceForge comment mechanism should be sufficient. [xxx an email gateway would be great, ditto Ping's Roundup] Accepted The powers that be accepted the patch, but it hasn't been applied yet. [xxx flesh out -- Guido Bottleneck avoidable here?] The status will normally change to Closed next. The person changing the status to Accepted should, at the same time, assign the patch to whoever they believe is most likely to be able & willing to apply it (the submitter if possible). Closed The patch has been accepted and applied. The previous status was Accepted, or possibly Open if the submitter was Guido (or moral equivalent in some particular area of expertise). Rejected The patch has been reviewed and rejected. When the objections are addressed, the status may change to Open again. The person changing the status to Rejected should assign the patch back to the submitter, or if it's clear the patch will never be accepted, assign it to None. Note that SourceForge allows the submitter to overwrite the patch with a new version. Out of date Previous status was Open or Accepted or Postponed, but the patch no longer works. Please enter a comment when changing the status to "Out of date", to record the nature of the problem and the previous status. Also assign it back to the submitter, as they need to upload a new version (note that SourceForge will not allow anyone other than the original submitter to update the patch). Postponed The previous status was Open or Accepted, but for some reason (e.g., pending release) the patch should not be reviewed or applied until further notice. The status will normally change to Open or Accepted next. Please enter a comment when changing the status to Postponed, to record the reason, the previous status, and the conditions under which the patch should revert to Open or Accepted. Also assign the patch to whoever is most likely able and willing to decide when the status should change again. Deleted Bit bucket. Use only if it's OK for the patch and its SourceForge history to disappear. As of 09-July-2000, SF does not actually throw away Deleted patches, but that may change. From thomas at xs4all.net Mon Jul 10 00:26:44 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 00:26:44 +0200 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix In-Reply-To: <39690818.917030DE@stud.ntnu.no>; from petersc@stud.ntnu.no on Sun, Jul 09, 2000 at 11:17:44PM +0000 References: <396780B6.67247E2C@stud.ntnu.no> <200007082334.SAA08816@cj20424-a.reston1.va.home.com> <39690818.917030DE@stud.ntnu.no> Message-ID: <20000710002644.G26534@xs4all.nl> On Sun, Jul 09, 2000 at 11:17:44PM +0000, Peter Schneider-Kamp wrote: > While "slaving away" on the Modules/ directory (thanks for > the term - it made my day ), I still haven't got a > clue why Python crashes on me when I throw an error on > duplicate arguments like in: > >>> def f(a, a): print a > segfault > Any help is again appreciated. Hm, strange. It works fine here. Do you get the segfault every time ? Anyway, a possible problem is that PyString_InternFromString might return NULL, and you later PyDict_GetItem() with it (not sure if that's a problem), and you pass it to com_newlocal_o (not sure if that's a problem either), and then you Py_DECREF it. And if you pass NULL to that macro you do have a problem :) You should use Py_XDECREF() if you aren't sure wether the object is NULL or not. If your python left a corefile, you can easily find out if that was the problem by using gdb on it. 'gdb ./python core', wait 'till it finishes loading, and type 'bt'. It should give you reversed (from a python point of view) backtrace from the time of the crash. > ! nameval = PyString_InternFromString(name); > ! if (nameval == NULL) { > ! c->c_errors++; > ! } > ! if (PyDict_GetItem(c->c_locals, nameval)) { > ! com_error(c, PyExc_SyntaxError,"double identifier in function definition"); > ! } > ! com_newlocal_o(c, nameval); > ! Py_DECREF(nameval); -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Mon Jul 10 00:33:21 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 9 Jul 2000 18:33:21 -0400 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <20000709215057.95047E2673@oratrix.oratrix.nl> Message-ID: Random question: why isn't the Mac code checked into the main CVS tree? I don't know anything about Mac development, and because the code for it is invisible to me too, have no idea how any change may affect your life (e.g., if Guido hadn't remembered its Mac connection, I would have deleted the USE_STACKCHECK stuff -- for which there is no conceivable use via staring at every file in the CVS true -- not even a doc like "stuff you shouldn't screw with because it's important on the Mac" ). BTW, I heartily agree that the lack of official IANA names for Mac encodings is not my fault. sympathetic-but-too-ignorant-to-help-ly y'rs - tim From paul at prescod.net Mon Jul 10 00:38:24 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 09 Jul 2000 17:38:24 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> Message-ID: <3968FEE0.E1345788@prescod.net> Guido van Rossum wrote: > > ... > Nice idea... Unfortunately it means that every module must be > changed. If we want to do this, we'd best introduce a macro! > E.g. (untested): > > #define Py_INIT(modname) DL_EXPORT(void) init20##modname() Why is it that the init function names has to change for each module? Why not PyModuleMain or something? -- Paul Prescod - Not encumbered by corporate consensus "Computer Associates is expected to come in with better than expected earnings." Bob O'Brien, quoted in - http://www.fool.com/news/2000/foth000316.htm From dberlin at redhat.com Mon Jul 10 00:45:08 2000 From: dberlin at redhat.com (Daniel Berlin+list.python-dev) Date: 09 Jul 2000 18:45:08 -0400 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: "Tim Peters"'s message of "Sun, 9 Jul 2000 18:33:21 -0400" References: Message-ID: <86d7kmly8b.fsf@dan2.cygnus.com> "Tim Peters" writes: > Random question: why isn't the Mac code checked into the main CVS tree? I > don't know anything about Mac development, and because the code for it is > invisible to me too, have no idea how any change may affect your life (e.g., > if Guido hadn't remembered its Mac connection, I would have deleted the > USE_STACKCHECK stuff -- for which there is no conceivable use via staring at > every file in the CVS true -- not even a doc like "stuff you shouldn't screw > with because it's important on the Mac" ). Also, Jack, you said you pity those on lesser known platforms like BeOS. Well, on BeOS, most stuff is posix compliant enough that things like Unicode will work (besides that BeOS has native support for unicode in it's own API's) the way they are written. The only stuff we worry about is dynamic loading of shared libs, and threading. WinCE is probably going to run into the same issues Windows does, more or less. I'm gonna say that Macs are mainly the oddball here, and that mou are running into issues mainly because nobody has had to deal with them, cause it doesn't take that much work to make it work on our favorite platform. > > BTW, I heartily agree that the lack of official IANA names for Mac encodings > is not my fault. > I'll take the blame for this one. I've got broad shoulders. > sympathetic-but-too-ignorant-to-help-ly y'rs - tim > > > From effbot at telia.com Mon Jul 10 00:57:16 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 00:57:16 +0200 Subject: [Python-Dev] new popen for win32! [status update] References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> <200007092202.RAA14221@cj20424-a.reston1.va.home.com> Message-ID: <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> guido wrote: > > the current api is: > > > > popen2.popen2(command, bufsize=default) > > popen2.popen3(command, bufsize=default) > > > > vs. > > > > nt.popen2(command, mode="t") > > nt.popen3(command, mode="t") > > Not commenting on the question here, but on the return tuple: should > it be (i,o,e) or (o,i,e)? The popen2 module uses the latter, but > that's hard to remember for Unix-droids: it corresponds to (1,0,2) in > file descriptors. So if it's not too late, let's do (i,o,e). > > (I tried to read the posixmodule.c source but got lost...) oh, I just changed things around the other way (assuming that "popen2" was some kind of standard). changing things is trivial, decided what's the right way to do it is harder. here's another idea: one way to solve this would be to deprecate "popen2", and move that functionality into the os module -- with the return values sorted out. that is, let's introduce: f = os.popen(cmd, mode, bufsize) w, r = os.popen2(cmd, mode, bufsize) w, r, e = os.popen3(cmd, mode, bufsize) w, r = os.popen4(cmd, mode, bufsize) # windows only, at the moment and mark popen2 as obsolete. whaddayathink? From alex_c at MIT.EDU Mon Jul 10 00:54:44 2000 From: alex_c at MIT.EDU (Alexander S Coventry) Date: Sun, 9 Jul 2000 18:54:44 -0400 (EDT) Subject: [Python-Dev] Problem with 'import site' on Linux In-Reply-To: <20000709221002.A1FB71CF57@dinsdale.python.org> (python-dev-request@python.org) References: <20000709221002.A1FB71CF57@dinsdale.python.org> Message-ID: <200007092254.SAA289432@w20-575-115.mit.edu> The function _locale._getdefaultlocale seems to only be defined if python is compiled for windows, but an attempt is made to call it regardless of the OS in locale.getdefaultlocale. This is causing 'import site' to fail when I start python. I am not sure what ought to be called instead; in my version, for now, I am going to amend the try: except: block that this code is wrapped in so that it catches AttributeError's, as well. The code I'm referring to is around line 262 in Lib/locale.py, and line 343 in Modules/_localemodule.c Alex. From effbot at telia.com Mon Jul 10 01:11:38 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 01:11:38 +0200 Subject: [Python-Dev] Problem with 'import site' on Linux References: <20000709221002.A1FB71CF57@dinsdale.python.org> <200007092254.SAA289432@w20-575-115.mit.edu> Message-ID: <033001bfe9fb$09a16b20$f2a6b5d4@hagrid> alexander wrote: > The function _locale._getdefaultlocale seems to only be defined if > python is compiled for windows, but an attempt is made to call it > regardless of the OS in locale.getdefaultlocale. This is causing > 'import site' to fail when I start python. I am not sure what ought to > be called instead; in my version, for now, I am going to amend the try: > except: block that this code is wrapped in so that it catches > AttributeError's, as well. > > The code I'm referring to is around line 262 in Lib/locale.py, and line > 343 in Modules/_localemodule.c I'll fix this in the repository. the except clause should catch AttributeError, not NameError. sorry /F From effbot at telia.com Mon Jul 10 01:12:16 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 01:12:16 +0200 Subject: [Python-Dev] Venting some steam on current developments References: <20000709215057.95047E2673@oratrix.oratrix.nl> Message-ID: <033301bfe9fb$209d3520$f2a6b5d4@hagrid> jack wrote: > The first problem (for which I can't blame the Python community, I > guess:-) is that the names mac_roman and such are not official IANA > names for the Mac encodings. Actually, it turns out there _are_ no > official names, so the Mac APIs to turn encodings into names work > wonderful for things including all ISO encodings, windows encodings, > etc, but not for the native mac encodings. Sigh. Okay, we do this > ourselves. > Then I spent an hour recompiling Python because this *&^^$%&*^%$ > setdefaultencoding didn't show up in sys for no conceivable reason. It > turns out it is *deleted* in site.py after using it once. A comment in > sysmodule.c would have been rather nice here... mail problems? didn't I send you a couple of mails discussing what needed to be done, including where you could reach me over the weekend? did you see my changes to the locale module? I rewrote the darn thing to make it easier to deal with this on non-posix platforms, and posted the locale.py patch to the patch manager (the CVS repository had a stale lock, so I couldn't check it in before today). heck, I even sent you some pseudocode that showed one way to implement parts of _getdefaultlocale for the mac, and still you claim that we're ignoring non unix/windows platforms? you could have asked for help a little earlier, you know... From billtut at microsoft.com Mon Jul 10 01:06:50 2000 From: billtut at microsoft.com (Bill Tutt) Date: Sun, 9 Jul 2000 16:06:50 -0700 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC Wi nMain.c,1.3,1.4 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD29A@RED-MSG-50> Heh. Part of the win32 extension building process is to stamp version resources into binaries. That's what the rc file is for. Bill From barry at scottb.demon.co.uk Mon Jul 10 01:15:49 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Mon, 10 Jul 2000 00:15:49 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007092152.QAA14143@cj20424-a.reston1.va.home.com> Message-ID: <000401bfe9fb$9e5050b0$060210ac@private> The key problem here is that the python engine needs to verify the version of python that the extension supports before allowing the extension to do anything dangerous. Maybe the solution is a pair of functions and a bit of protocol. The first function is used for version checking. int check_version_##module_name(); The second function will do the init as today. init init##module_name(); Based on the outcome of calling the check_version function python can decide if it should call the init function. Issues with the check_version function that I can think of are: * how is a python version represented? * should the check_version function be passed the calling python's version? This would allow smart extensions to adapt to the invoking python's version dependent features. Barry From mhammond at skippinet.com.au Mon Jul 10 01:48:49 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 9 Jul 2000 19:48:49 -0400 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PC WinMain.c,1.3,1.4 In-Reply-To: <019501bfe920$18cee220$f2a6b5d4@hagrid> Message-ID: > stupid question: what exactly does the RC file do here: > > STRINGTABLE DISCARDABLE > BEGIN > 2000 "Dummy" // Needed to version branding works! > END > > (couldn't really parse that comment ;-) The "to" should be "so" - that will make it parse better, but probably still doesnt answer your question :-) Greg wrote a script that I use to brand .DLL/.EXE files with a version resource - eg, I brand the win32all package _after_ the final build - the version strings are written after it has been built and tested. However, this code fails for .DLL/.EXE files without any resources at all. This dummy resource gets around that problem. It can safely be ignored for inclusion into the core... Mark. From mhammond at skippinet.com.au Mon Jul 10 01:48:52 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 9 Jul 2000 19:48:52 -0400 Subject: [Python-Dev] new popen for win32! In-Reply-To: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> Message-ID: > - first, a stupid question: is the popen2 and popen3 > versions replacements for the corresponding functions > in the popen2 module. I believe Bill was first :-) Note that the param order may be different, and should be made the same. > (or to put it another way: should the popen2 module > be modified to use these functions on Windows?) IMO, yes. > - should this go into the "nt" (posix) module, or should > I create a new module? for no good reason, I would lean towards the NT module, but a seperate source file. > - "win32popenWin9x.exe" is a rather unwieldy name for a > file. does anyone have a better suggestion? I think the name can be unwieldy, as no one will ever execute this directly. The name should reflect its purpose, so no one says "hey - I never run this .exe, so I can remove it. > py_popen9x.exe I agree with Tim that "popen9x.exe" is fine. > - I'm using VC5 on this box, so I should probably avoid > checking in my modified project files. any VC6-wielding > volunteers out there? If its not done by the time I return to Oz, I will be happy to do it. However, I bet Bill beats me too it (unless someone explains to Tim what is expected of him, and off he goes :-) Mark. From petersc at stud.ntnu.no Mon Jul 10 04:14:05 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 02:14:05 +0000 Subject: [Python-Dev] compile.c: problem with duplicate argument bugfix References: <396780B6.67247E2C@stud.ntnu.no> <200007082334.SAA08816@cj20424-a.reston1.va.home.com> <39690818.917030DE@stud.ntnu.no> <20000710002644.G26534@xs4all.nl> Message-ID: <3969316D.467C85FA@stud.ntnu.no> Thomas Wouters wrote: > > Hm, strange. It works fine here. Do you get the segfault every time ? What system? Which version (I guess this day's CVS)? I get the segfault every time the error should be thrown. > Anyway, a possible problem is that PyString_InternFromString might return > NULL, and you later PyDict_GetItem() with it (not sure if that's a problem), > and you pass it to com_newlocal_o (not sure if that's a problem either), and > then you Py_DECREF it. And if you pass NULL to that macro you do have a > problem :) You should use Py_XDECREF() if you aren't sure wether the object > is NULL or not. No, that does not seem to be the problem. The segfault happens in PyErr_NormalizeException where PyClass_Check(type) accesses type->ob_type. I'm giving up for today. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From esr at thyrsus.com Mon Jul 10 02:40:09 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 9 Jul 2000 20:40:09 -0400 Subject: [Python-Dev] urllib.browse() issues In-Reply-To: ; from pingster@ilm.com on Fri, Jul 07, 2000 at 03:26:13PM -0700 References: <20000707103308.8074FE2673@oratrix.oratrix.nl> Message-ID: <20000709204009.A4566@thyrsus.com> Ka-Ping Yee : > Hmm, i rather like this idea. Actually, i like it enough to > suggest that "launch" would be a good interface to external > applications -- > > launch.filebrowser("/home") > launch.webbrowser("http://www.python.org/", newwindow=1) > launch.mailreader() > launch.mailcomposer("python-dev at python.org", subject="Spam") > launch.textviewer("README") > launch.texteditor("spam.py") > launch.shell("/usr") > launch.remoteshell("unseen.python.org", port=23) > > On Unix this would take advantage of (and formalize) the PAGER, > EDITOR, BROWSER, etc. environment variables; on Windows they > could look at registry settings, and for Mac, they could use IC. I like it. -- Eric S. Raymond ..every Man has a Property in his own Person. This no Body has any Right to but himself. The Labour of his Body, and the Work of his Hands, we may say, are properly his. .... The great and chief end therefore, of Mens uniting into Commonwealths, and putting themselves under Government, is the Preservation of their Property. -- John Locke, "A Treatise Concerning Civil Government" From guido at beopen.com Mon Jul 10 03:49:26 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 20:49:26 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Sun, 09 Jul 2000 17:38:24 EST." <3968FEE0.E1345788@prescod.net> References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> Message-ID: <200007100149.UAA16917@cj20424-a.reston1.va.home.com> > Guido van Rossum wrote: > > > > ... > > Nice idea... Unfortunately it means that every module must be > > changed. If we want to do this, we'd best introduce a macro! > > E.g. (untested): > > > > #define Py_INIT(modname) DL_EXPORT(void) init20##modname() Paul Prescod replies: > Why is it that the init function names has to change for each module? > Why not PyModuleMain or something? Because Python supports a configuration time option to link modules statically. BArry Scott replies: > The key problem here is that the python engine needs to > verify the version of python that the extension supports > before allowing the extension to do anything dangerous. > > Maybe the solution is a pair of functions and a bit of > protocol. > > The first function is used for version checking. > > int check_version_##module_name(); > > The second function will do the init as today. > > init init##module_name(); > > Based on the outcome of calling the check_version function > python can decide if it should call the init function. > > Issues with the check_version function that I can think of > are: > > * how is a python version represented? > * should the check_version function be passed the calling > python's version? This would allow smart extensions to > adapt to the invoking python's version dependent features. There are endless variations on this theme. What's missing at the moment is a bit of requirements analysis. What's the problem we're trying to solve here? So far, the only problem that came up was that on Windows, you get an obscure crash when trying to load an extension built for Python 1.5(.x). Do we really need a whole new version negotiating architecture? You can already get the version string by looking at Py_GetVersion() -- this also answers the question of how a version is represented. On Windows, link-time compatibility is broken whenever we change the second digit of the version number, e.g. 15, 16, 20. On Unix, there's also a different version (the API version, see modsupport.h) which is checked when the module initializes itself (it's hidden in the call to Py_InitModule() that the module makes). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 04:09:04 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 09 Jul 2000 21:09:04 -0500 Subject: [Python-Dev] new popen for win32! [status update] In-Reply-To: Your message of "Mon, 10 Jul 2000 00:57:16 +0200." <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> <200007092202.RAA14221@cj20424-a.reston1.va.home.com> <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> Message-ID: <200007100209.VAA16999@cj20424-a.reston1.va.home.com> > oh, I just changed things around the other way (assuming that > "popen2" was some kind of standard). > > changing things is trivial, decided what's the right way to do it > is harder. here's another idea: > > one way to solve this would be to deprecate "popen2", and move > that functionality into the os module -- with the return values > sorted out. that is, let's introduce: > > f = os.popen(cmd, mode, bufsize) > w, r = os.popen2(cmd, mode, bufsize) > w, r, e = os.popen3(cmd, mode, bufsize) > w, r = os.popen4(cmd, mode, bufsize) # windows only, at the moment > > and mark popen2 as obsolete. > > whaddayathink? Ah, I finally see the problem here. Sigh... Both orders are equally logical -- depending on your point of view! This is of course because pipes have a read end and a write end. So stdin is read by the child but written by the parent, and stdout is written by the child and read by the parent. From fdrake at beopen.com Mon Jul 10 04:38:01 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 22:38:01 -0400 (EDT) Subject: [Python-Dev] PROTO_LIST in Modules/md5.h In-Reply-To: <200007092234.RAA14334@cj20424-a.reston1.va.home.com> References: <3968EAEB.A06D9A38@stud.ntnu.no> <14696.53313.296096.777677@cj42289-a.reston1.va.home.com> <200007092234.RAA14334@cj20424-a.reston1.va.home.com> Message-ID: <14697.14089.167736.898381@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > Of course, it's not high priority stuff, but sometimes it helps > putting our "mark" on code. :-) Hey, we should talk to my dog. She knows all about marking her territory. ;-) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tmacd at eintelligence-inc.com Mon Jul 10 05:27:05 2000 From: tmacd at eintelligence-inc.com (Tom MacDonald) Date: Sun, 9 Jul 2000 22:27:05 -0500 (CDT) Subject: [Python-Dev] Collection of typedefs for integral types In-Reply-To: from "Tim Peters" at Jul 09, 2000 01:23:03 AM Message-ID: <200007100327.e6A3R5F25974@sundeva.eintelligence-inc.com> > [Tim, pushing the adoption of some C9X-like typedefs in Python's source] > > ... > > the-committee-wasn't-just-jerking-off-the-last-10-years-ly y'rs - > > tim > > [Ken Manheimer] > > (The obvious question is, where they doing those other things at the same > > time, or during breaks?) > > It varies by member. For example, the Reverend Tom MacDonald jerked off > non-stop the entire time (& I've copied him on this for confirmation). But > a surprising number of the members have never jerked off at all! You know me Tim. Ever since you showed me the pictures of mad dog and butcher vachon I can't stop. Interesting question but the committee never took a role call vote on that question. > Rev Tom, after 118 years serving on X3J11, do you think C9X is a good thing > or a bad thing? And do you still get off on it regardless? And what does > God think about C9X? If I have to boil C99 down to either good or bad, I'll pick good. It cleans up a lot of fuzzy words from C89, addresses some missing features that should be there (e.g., variable length arrays, long long, hex floating constants, // comments, , intmax_t, mixed declarations and code, designated initializers). There are features, though, that I wish were not there. The biggest being the complex type. This seems a tad ironic since I pushed for complex early on in the C99 process. I didn't realize that IEEE arithmetic made a complex type grow like the blob - even an imaginary type is there for those that want everything IEEE arithmetic has to offer. I18N was added (I think). I never could figure out if we made everybody that spoke their own language happy or not. It sure made C99 a lot bigger. Almost all of it in the library - though an implementation can support identifiers containing international characters. I don't like the following features: flexible array members, the number of new functions and operators required to support IEEE arithmetic, the LIA compatibility annex, and C99 style boolean support. I like the rest of it. However, no matter what I think, I don't see any vendors rushing to implement C99. Instead vendors are picking some C99 features and implementing those. So, perhaps the the answer to the question of whether C99 is good or bad is only interesting if someone actually implements it. Actually, you need several vendors to implement it. One reason C89 was so successful is that all vendors implemented it. I still like C. In my new job I'm using C++ all the time. I'm probably getting old and can't appreciate all this stuff C++ does for me under the covers, but I can never figure out which overloaded function or operator is actually instantiated by template such-n-such. With C, I can always see what's going on. So yes, I sill got off on it. I asked God what he thought about C99 and he said he didn't have an opinion on C99 cause he always uses python. Rev. Tom From fdrake at beopen.com Mon Jul 10 05:59:26 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sun, 9 Jul 2000 23:59:26 -0400 (EDT) Subject: [Python-Dev] ANSI-fication patches Message-ID: <14697.18974.492954.234194@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp recently submitted a large number of patches to make the C sources in the Modules/ directory ANSI compliant. I've passed most of these back to him for checkin, but for a number of them he commented that he had not tested them (presumably because he doesn't have SGI hardware, or some of the esoteric libraries shipped with IRIX). If someone could look at the ones that are still unassigned and comment on their passing tests, that would be great. Just add a comment to the patch or mark it accepted and pass it back to Peter ("nowonder" on SF). Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From moshez at math.huji.ac.il Mon Jul 10 07:04:05 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 10 Jul 2000 08:04:05 +0300 (IDT) Subject: [Python-Dev] [Fwd: Re: Splitting c.l.py...] In-Reply-To: Message-ID: On Sun, 9 Jul 2000, Jeremy Hylton wrote: > In the Perl world, there is a weekly summary of discussion on the > perl5-porters list. It seems to be written by Mark-Jason Dominus most > (all?) of the time. We could do the same thing if we could find people to > do it. Perhaps a weekly Python-dev URL? If we had enough reporters, it > might not be too much work. > > Volunteers? I'd be happy to coordinate. I can volunteer, but I'd like to know a week in advance (and not every week, obviously) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From moshez at math.huji.ac.il Mon Jul 10 07:15:21 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 10 Jul 2000 08:15:21 +0300 (IDT) Subject: [Python-Dev] Out of loop... In-Reply-To: <20000709214058.D26534@xs4all.nl> Message-ID: On Sun, 9 Jul 2000, Thomas Wouters wrote: > On Sun, Jul 09, 2000 at 03:21:41PM -0400, Fred L. Drake, Jr. wrote: > > > Ok, it's been a busy week, and my wife & kids are just about back. > > I'll be largely out of touch here for about 24 hours. It's time to > > play with the kids! > > Damn, this scares me. Even at my real-life job we don't warn eachother when > we're out of the loop for a day or so. We've had a colleague go on a > vacation, and not be missed for like a week before anyone started wondering > where he was ;-) And here is Fred apologizing for spending a day with his > family. Is it too late for me to opt out ?!? Fred does it only out of courtesy. The PSU keeps track of all Python-Dev members, in case on of them is needed. If you need to find some Python-Dev member, just contact your local PSU representative. if-you-don't-know-who-he-is-you-got-a-*big*-problem-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. From petersc at stud.ntnu.no Mon Jul 10 09:47:44 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 07:47:44 +0000 Subject: [Python-Dev] CVS read/write access Message-ID: <39697FA0.ADD1BB17@stud.ntnu.no> Thanks to Fred I now have 35 of my own patches assigned to me. Unfortunately trying to checkout read/write in order to be able to commit later I get this: nowonder at mobility:~/python > export CVS_RSH=ssh nowonder at mobility:~/python > export CVSROOT=nowonder at cvs.python.sourceforge.net:/cvsroot/python nowonder at mobility:~/python > cvs co python nowonder at cvs.python.sourceforge.net's password: Sorry, you don't have read/write access to the history file /cvsroot/python/CVSROOT/history Permission denied nowonder at mobility:~/python > As I also see no way to change the status of my patches, maybe some UserPermissions still need to be set. Maybe something like ? CVS write: yes ? Patch Manager: Tech & Admin But then I don't really know that much about sourceforge. For my own pet project (LegoVision) I just got one developer ;-) Thanks anyway, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From tim_one at email.msn.com Mon Jul 10 08:14:56 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 02:14:56 -0400 Subject: [Python-Dev] CVS read/write access In-Reply-To: <39697FA0.ADD1BB17@stud.ntnu.no> Message-ID: [Peter Schneider-Kamp] > Thanks to Fred I now have 35 of my own patches assigned to me. > Unfortunately trying to checkout read/write in order to be > able to commit later I get this: > > nowonder at mobility:~/python > export CVS_RSH=ssh > nowonder at mobility:~/python > export > CVSROOT=nowonder at cvs.python.sourceforge.net:/cvsroot/python Perhaps CVSROOT should have :ext: at the start? Here's mine: set CVSROOT=:ext:tim_one at cvs.python.sourceforge.net:/cvsroot/python Monkey see, monkey do, usually works best for software written by apes . > nowonder at mobility:~/python > cvs co python > nowonder at cvs.python.sourceforge.net's password: > Sorry, you don't have read/write access to the history file > /cvsroot/python/CVSROOT/history > Permission denied > nowonder at mobility:~/python > > As I also see no way to change the status of my patches, maybe > some UserPermissions still need to be set. > Maybe something like > > ? CVS write: yes > ? Patch Manager: Tech & Admin Bingo on this one: your Patch Manager permissions were set to "Tech only". I think that's the default. I've changed them to "Tech & Admin" for nowonder, so that problem should be solved now. > But then I don't really know that much about sourceforge. For my own > pet project (LegoVision) I just got one developer ;-) Ya, but at least you can release it when you want to . grass-is-greener-ly y'rs - tim From petersc at stud.ntnu.no Mon Jul 10 10:27:47 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 08:27:47 +0000 Subject: [Python-Dev] CVS read/write access References: Message-ID: <39698903.1EFDBFBA@stud.ntnu.no> Tim Peters wrote: > > Perhaps CVSROOT should have > > :ext: > > at the start? Here's mine: > > set CVSROOT=:ext:tim_one at cvs.python.sourceforge.net:/cvsroot/python No, doesn't change a thing. Unfortunately. > Monkey see, monkey do, usually works best for software written by apes > . Just what I did. Just that I looked at the CVS Howto. But I think the problem is somewhere else. > Bingo on this one: your Patch Manager permissions were set to "Tech only". > I think that's the default. I've changed them to "Tech & Admin" for > nowonder, so that problem should be solved now. Yes, thanx alot! Wasn't there something about CVS write access though? > > But then I don't really know that much about sourceforge. For my own > > pet project (LegoVision) I just got one developer ;-) > > Ya, but at least you can release it when you want to . Ooh, where is the point in the license telling me I cannot release Python, too <1.5 wink>? just-joking-but-wait-a-month-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From tim_one at email.msn.com Mon Jul 10 09:02:39 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 03:02:39 -0400 Subject: [Python-Dev] CVS read/write access In-Reply-To: <39698903.1EFDBFBA@stud.ntnu.no> Message-ID: >> Perhaps CVSROOT should have >> >> :ext: >> >> at the start? Here's mine: >> >> set CVSROOT=:ext:tim_one at cvs.python.sourceforge.net:/cvsroot/python [Peter S-K] > No, doesn't change a thing. Unfortunately. I was well beyond my area of competence with the first suggestion . You could get a real OS like me (Win98SE), or hope that one of your Unixish compatriots helps out. Maybe it would help if you told them other stuff about your setup (OS, version, CVS version, whether CVS works in other contexts for you, etc). > ... Wasn't there something about CVS write access though? *Everyone* on the Member Admin page has "Yes" under "CVS write", and there are no controls there even to change that to "No". Maybe it's one of these 4-hour SourceForge delay thingies? Doubt it, but it's a darned good excuse for me to go to sleep now . > Ooh, where is the point in the license telling me I cannot > release Python, too <1.5 wink>? > > just-joking-but-wait-a-month-ly y'rs > Peter Indeed, if we still haven't released Python after another month, I'm going to leave BeOpen PythonLabs and go to work somewhere I can <0.6 wink>. From effbot at telia.com Mon Jul 10 09:18:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 09:18:45 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules md5.h,2.5,2.6 md5c.c,2.3,2.4 References: <200007100421.VAA16454@slayer.i.sourceforge.net> Message-ID: <004201bfea3f$17b154c0$f2a6b5d4@hagrid> Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv16446 > > Modified Files: > md5.h md5c.c > Log Message: > > Guido said include these in the Great ANSI-fication, so here they are! weren't you supposed to drop out of sight for a while? besides, I'd assigned these patches to myself, and applied them locally. just thought I'd get some sleep before I checked them in again. (iow, please check the patch archive before hacking along. someone else might be working on the same thing) From petersc at stud.ntnu.no Mon Jul 10 11:27:49 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 09:27:49 +0000 Subject: [Python-Dev] CVS read/write access References: Message-ID: <39699715.E3368F53@stud.ntnu.no> Tim Peters wrote: > > I was well beyond my area of competence with the first suggestion . > You could get a real OS like me (Win98SE), or hope that one of your Unixish > compatriots helps out. Maybe it would help if you told them other stuff > about your setup (OS, version, CVS version, whether CVS works in other > contexts for you, etc). No, this is a python/sourceforge thing. cvs/ssh/sourceforge works just fine: nowonder at mobility:~/python > export CVS_RSH=ssh nowonder at mobility:~/python > export CVSROOT=nowonder at cvs.legovision.sourceforge.net:/cvsroot/legovision nowonder at mobility:~/python > cvs co legovision nowonder at cvs.legovision.sourceforge.net's password: cvs server: Updating legovision U legovision/LICENSE.txt U legovision/README.html cvs server: Updating legovision/LookingLego U legovision/LookingLego/ImageProcessing.cpp U legovision/LookingLego/ImageProcessing.h U legovision/LookingLego/InfraRed.cpp U legovision/LookingLego/InfraRed.h [cut - that's enough] > *Everyone* on the Member Admin page has "Yes" under "CVS write", and there > are no controls there even to change that to "No". Maybe it's one of these > 4-hour SourceForge delay thingies? Doubt it, but it's a darned good excuse > for me to go to sleep now . 6 hours that is, but possible. Hadn't thought of that one. I'll just wait some hours and try again (sounds like "okay, I'll reinstall Windows 98SE and try again" :}). I'll save some bandwidth until then, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From effbot at telia.com Mon Jul 10 09:46:36 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 09:46:36 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules md5.h,2.5,2.6 md5c.c,2.3,2.4 Message-ID: <008901bfea43$34f14a00$f2a6b5d4@hagrid> I wrote: > besides, I'd assigned these patches to myself, and applied > them locally. just thought I'd get some sleep before I checked > them in again. > > (iow, please check the patch archive before hacking along. > someone else might be working on the same thing) oh, I see. these patches were marked as "accepted", so they didn't show up on the main page. this is clearly a drawback of the "open => accepted => closed" scheme; you have to check several places before you know if something is being worked on... (having an "all except closed, rejected, delete" selection would be nice. roundup can do that, of course ;-) From gstein at lyra.org Mon Jul 10 10:32:50 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 01:32:50 -0700 Subject: [Python-Dev] CVS: python/dist/src/Modules posixmodule.c,2.143,2.144 In-Reply-To: <200007091310.GAA27888@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Sun, Jul 09, 2000 at 06:10:48AM -0700 References: <200007091310.GAA27888@slayer.i.sourceforge.net> Message-ID: <20000710013250.P29590@lyra.org> hmm. should that be PyLong_FromVoidPtr() ? It will return the appropriate object type based on the size of a void*. Cheers, -g On Sun, Jul 09, 2000 at 06:10:48AM -0700, Fredrik Lundh wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv27646/Modules > > Modified Files: > posixmodule.c > Log Message: > > > - fixed pointer size test in spawn functions. also added > cast to make sure Py_BuildValue gets the right thing. > > this change eliminates bogus return codes from successful > spawn calls (e.g. 2167387144924954624 instead of 0). > > Index: posixmodule.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v > retrieving revision 2.143 > retrieving revision 2.144 > diff -C2 -r2.143 -r2.144 > *** posixmodule.c 2000/07/08 22:48:53 2.143 > --- posixmodule.c 2000/07/09 13:10:40 2.144 > *************** > *** 1541,1548 **** > return posix_error(); > else > ! #if SIZEOF_LONG == SIZE_VOID_P > ! return Py_BuildValue("l", spawnval); > #else > ! return Py_BuildValue("L", spawnval); > #endif > } > --- 1541,1548 ---- > return posix_error(); > else > ! #if SIZEOF_LONG == SIZEOF_VOID_P > ! return Py_BuildValue("l", (long) spawnval); > #else > ! return Py_BuildValue("L", (LONG_LONG) spawnval); > #endif > } > *************** > *** 1649,1656 **** > (void) posix_error(); > else > ! #if SIZEOF_LONG == SIZE_VOID_P > ! res = Py_BuildValue("l", spawnval); > #else > ! res = Py_BuildValue("L", spawnval); > #endif > > --- 1649,1656 ---- > (void) posix_error(); > else > ! #if SIZEOF_LONG == SIZEOF_VOID_P > ! res = Py_BuildValue("l", (long) spawnval); > #else > ! res = Py_BuildValue("L", (LONG_LONG) spawnval); > #endif > > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 10 10:43:29 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 01:43:29 -0700 Subject: [Python-Dev] CVS read/write access In-Reply-To: <39699715.E3368F53@stud.ntnu.no>; from petersc@stud.ntnu.no on Mon, Jul 10, 2000 at 09:27:49AM +0000 References: <39699715.E3368F53@stud.ntnu.no> Message-ID: <20000710014329.Q29590@lyra.org> I lost the original note, but I recall that it said you couldn't write the "history" file. If so, then it is a problem that the SF Admins must solve. It means that you haven't been placed into the appropriate group or somesuch on SF. Log a support request with the copy of your output. Cheers, -g On Mon, Jul 10, 2000 at 09:27:49AM +0000, Peter Schneider-Kamp wrote: > Tim Peters wrote: > > > > I was well beyond my area of competence with the first suggestion . > > You could get a real OS like me (Win98SE), or hope that one of your Unixish > > compatriots helps out. Maybe it would help if you told them other stuff > > about your setup (OS, version, CVS version, whether CVS works in other > > contexts for you, etc). > > No, this is a python/sourceforge thing. cvs/ssh/sourceforge works just > fine: > > nowonder at mobility:~/python > export CVS_RSH=ssh > nowonder at mobility:~/python > export > CVSROOT=nowonder at cvs.legovision.sourceforge.net:/cvsroot/legovision > nowonder at mobility:~/python > cvs co legovision > nowonder at cvs.legovision.sourceforge.net's password: > cvs server: Updating legovision > U legovision/LICENSE.txt > U legovision/README.html > cvs server: Updating legovision/LookingLego > U legovision/LookingLego/ImageProcessing.cpp > U legovision/LookingLego/ImageProcessing.h > U legovision/LookingLego/InfraRed.cpp > U legovision/LookingLego/InfraRed.h > [cut - that's enough] > > > *Everyone* on the Member Admin page has "Yes" under "CVS write", and there > > are no controls there even to change that to "No". Maybe it's one of these > > 4-hour SourceForge delay thingies? Doubt it, but it's a darned good excuse > > for me to go to sleep now . > > 6 hours that is, but possible. Hadn't thought of that one. I'll > just wait some hours and try again (sounds like "okay, I'll > reinstall Windows 98SE and try again" :}). > > I'll save some bandwidth until then, > Peter > -- > Peter Schneider-Kamp ++47-7388-7331 > Herman Krags veg 51-11 mailto:peter at schneider-kamp.de > N-7050 Trondheim http://schneider-kamp.de > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 10 11:09:31 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:09:31 -0700 Subject: [Python-Dev] Re: CVS: python/dist/src/Lib locale.py,1.7,1.8 In-Reply-To: <200007091713.KAA02613@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Sun, Jul 09, 2000 at 10:13:00AM -0700 References: <200007091713.KAA02613@slayer.i.sourceforge.net> Message-ID: <20000710020930.T29590@lyra.org> This checkin was *very* hard to review. In fact, I just gave up. The problem is that you did functional changes *AND* white space changes. A bunch of lines appear changed, but they're just whitespace change. The *real* changes are hidden in there somewhere. Can I request (from everyone) to do white space changes *only*, or to do functional changes *only*. It will make it a lot easier on the people who are reviewing the checkins. thx! -g On Sun, Jul 09, 2000 at 10:13:00AM -0700, Fredrik Lundh wrote: > Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2501/Lib > > Modified Files: > locale.py > Log Message: > > > - merged setlocale and set_locale. the internal setlocale > function is overridden by a python version which accepts > *either* a string (old behaviour) or a locale tuple. > > - renamed a few methods (for consistency): > > get_locale => getlocale > get_default_locale => getdefaultlocale > set_to_default => resetlocale (!) > > - the _locale implementation module can now implement > an optional _getdefaultlocale function. if that function > isn't available, a POSIX-based approach is used (checking > LANG and other environment variables, as usual). -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Mon Jul 10 11:16:13 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 11:16:13 +0200 Subject: [Python-Dev] Re: CVS: python/dist/src/Lib locale.py,1.7,1.8 References: <200007091713.KAA02613@slayer.i.sourceforge.net> <20000710020930.T29590@lyra.org> Message-ID: <00b901bfea4f$7f24d720$f2a6b5d4@hagrid> greg wrote: > This checkin was *very* hard to review. In fact, I just gave up. > > The problem is that you did functional changes *AND* white space changes. A > bunch of lines appear changed, but they're just whitespace change. The > *real* changes are hidden in there somewhere. my current editor setup strips bogus trailing whitespace all by itself. once they're gone, it's a bit hard to put them back... the important changes are in getdefaultlocale and the overriding setlocale function. From gstein at lyra.org Mon Jul 10 11:20:48 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:20:48 -0700 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007100149.UAA16917@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Sun, Jul 09, 2000 at 08:49:26PM -0500 References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> Message-ID: <20000710022047.V29590@lyra.org> On Sun, Jul 09, 2000 at 08:49:26PM -0500, Guido van Rossum wrote: > > Guido van Rossum wrote: > > > > > > ... > > > Nice idea... Unfortunately it means that every module must be > > > changed. If we want to do this, we'd best introduce a macro! > > > E.g. (untested): > > > > > > #define Py_INIT(modname) DL_EXPORT(void) init20##modname() > > Paul Prescod replies: > > > Why is it that the init function names has to change for each module? > > Why not PyModuleMain or something? > > Because Python supports a configuration time option to link modules > statically. Not to mention that the .so is loaded into the process' address space. I don't think that you can have two symbols in the space with the same name. But hey... even if you can: the static link option Guido mentions is definitely the kicker. Cheers, -g -- Greg Stein, http://www.lyra.org/ From petersc at stud.ntnu.no Mon Jul 10 13:29:29 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Mon, 10 Jul 2000 11:29:29 +0000 Subject: [Python-Dev] file closed! (was Re: CVS read/write access) References: <39699715.E3368F53@stud.ntnu.no> <20000710014329.Q29590@lyra.org> Message-ID: <3969B399.FC5E1AC2@stud.ntnu.no> Greg Stein wrote: > > If so, then it is a problem that the SF Admins must solve. It means that you > haven't been placed into the appropriate group or somesuch on SF. Log a ----- It was the group. But 20 minutes after I found out I checked again and suddenly python had appeared. Must have been this cron delay. Sorry-for-wasting-your-time Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gstein at lyra.org Mon Jul 10 11:35:24 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:35:24 -0700 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 09, 2000 at 05:07:40PM -0400 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Message-ID: <20000710023523.Y29590@lyra.org> bah. just file feature requests for them to use ViewCVS. cvsweb is a piece of crap anyways :-) Cheers, -g On Sun, Jul 09, 2000 at 05:07:40PM -0400, Tim Peters wrote: > [Fred L. Drake, Jr. > Sent: Wednesday, June 28, 2000 9:30 AM] > > ... > > the only problem I've had with IE5 is accessing a project's anonymous > > FTP area from the project page (IE5 just froze completely). > > This happens to me too. > > And a new problem popped up early this weekend (maybe Friday already): when > I click the "Browse CVS Repository" link near the bottom right of > > http://sourceforge.net/cvs/?group_id=5470 > > IE5 pops up a box asking me whether I really want to download file "cvsweb". > Useless! This used to work fine, and I sure haven't changed my IE setup. > Clearing the browser caches didn't help. The link resolves to > > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi?cvsroot=python > > today, and I don't know whether it resolved to something different last > week. Also have no idea how browsers decide what to do -- it's not simple & > straightforward, like e.g. floating-point arithmetic . .cgi is not an > extension registered on my machine either. -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 10 11:40:58 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:40:58 -0700 Subject: [Python-Dev] [OT] IE5 weirdness (was: Sourceforge Interface Concerns) In-Reply-To: <20000709235547.F26534@xs4all.nl>; from thomas@xs4all.net on Sun, Jul 09, 2000 at 11:55:47PM +0200 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> <20000709235547.F26534@xs4all.nl> Message-ID: <20000710024058.Z29590@lyra.org> On Sun, Jul 09, 2000 at 11:55:47PM +0200, Thomas Wouters wrote: >... >... Content-Type and Content-Disposition discussion ... >... > All in all, I'm no longer suprised when something dynamic (CGI scripts, > php/asp/jsp pages, whatever) refuses to work properly with IE ;) Quite a > depressing thing to know, this, but you can't always blame the > website-owners or the software developers. No doubt. I'm there with you. While working on the DAV stuff, I found that it totally bombs on a GET on a DAV resource when the Last-Modified header is not returned. (!!) Of course, dynamic scripts practically never return that, so I had to insert the following in my httpd.conf: Header set Last-Modified "Fri, 03 Mar 2000 06:32:31 GMT" Pretty fuggin broken, if you ask me :-) Oh. Even more broken: it makes you send the time. It doesn't display it in the Windows Explorer / Web Folder like you would expect. The "Modified" column is simply blank. *boggle* Cheers, -g -- Greg Stein, http://www.lyra.org/ From jack at oratrix.nl Mon Jul 10 11:45:41 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 10 Jul 2000 11:45:41 +0200 Subject: [Python-Dev] Symantec C compiler Message-ID: <20000710094541.9A02C37186D@snelboot.oratrix.nl> Folks, there are talks in python-dev of cleaning out ifdefs for the Symantec C compiler (__SC__). So, if anyone still uses it: scream loudly now or remain forever silent. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From gstein at lyra.org Mon Jul 10 11:49:05 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 02:49:05 -0700 Subject: [Python-Dev] [OT] version branding (was: CVS: python/dist/src/PC WinMain.c,1.3,1.4) In-Reply-To: ; from mhammond@skippinet.com.au on Sun, Jul 09, 2000 at 07:48:49PM -0400 References: <019501bfe920$18cee220$f2a6b5d4@hagrid> Message-ID: <20000710024905.A29590@lyra.org> On Sun, Jul 09, 2000 at 07:48:49PM -0400, Mark Hammond wrote: > > stupid question: what exactly does the RC file do here: > > > > STRINGTABLE DISCARDABLE > > BEGIN > > 2000 "Dummy" // Needed to version branding works! > > END > > > > (couldn't really parse that comment ;-) > > The "to" should be "so" - that will make it parse better, but probably > still doesnt answer your question :-) > > Greg wrote a script that I use to brand .DLL/.EXE files with a version > resource - eg, I brand the win32all package _after_ the final build - the > version strings are written after it has been built and tested. Heh. I wrote that after going through gyration after frustrating gyration with the Site Server "Build Team". Those guys had their little fiefdom and were responsible for building the product. You had to conform to their idiotic concepts and tools. Well, one of the worst was this complicated set of include files, macros, and other small tools to construct a version resource in the .rc file. Well, during the build process, you had to make sure that the "write the current version into so it can be picked up by the version.rc include stuff" actually got run. Of course, when you're developing code, what is the "current version"? etc etc. It was a horrible mess. So I ripped it all out and post-processed the DLL/EXE files. "ah. it built fine, passes the initial test suite, let's brand it and release for full testing." Slick as hell. Of course, the Build Team sure didn't like that. Much too easy. Might put them out of a job... :-) -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Mon Jul 10 12:00:36 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 12:00:36 +0200 Subject: [Python-Dev] Unicode maintainer wanted (was: Encodings) References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> Message-ID: <39699EC4.C4B30FC8@lemburg.com> "Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > Sorry, but I'm really surprised now: I've put many hours of > > work into this, hacked up encoding support for locale.py, > > went through endless discussions, proposed the changable default > > as compromise to make all parties (ASCII, UTF-8 and Latin-1) happy > > My recollection was that the purpose of the changable default was so > that we could experiment with different defaults more easily, not that > we'd keep it changable. That was the original idea -- noone actually did test this, though, after the hooks were in place... Then Guido (or was it someone else?) came up with the idea of making the default encoding depend on the default locale active at Python startup time and it turned out to satisfy proponents of all three encodings. Guido gave his OK in private mail, Fredrik was satisfied, a few people supported the decision in private mail and the rest made their agreement clear via collective silence. I then tried to hack up ways of extracting the encoding information from the locale settings -- not exactly an easy task and one which involved much research, two or three design cycles (in public on python-dev) and much refinement on the locale name mappings. All this took quite a lot of my time which I felt was worth investing to get all proponents happy. I, for one, still think that the fixed UTF-8 encoding was the best choice of all possibilities. Coding the locale stuff was meant as signal for compromise from my part and now the whole idea get's marked as failed experiment... > I'm not an expert on these issues and have tried to stay out of the > way on the discussion, but the idea of a changable default just seems > like we're asking for trouble. > I'm sorry that you feel your efforts have been wasted; I don't think > anyone tried to spend your time without careful consideration, but it > is important that we all understand what we have gained from this > experiment. > Before you implemented the changable default, we all had the > opportunity to presume to know how things would work with it, and > could bitch or plead about it as we felt appropriate. Now that it's > been tried, we have a little more real experiance with it, and can > point to the evidence that's been presented here as we each make our > arguments on the topic. > So I'd have to say that your efforts have *not* been wasted; we now > have a very good idea of what's involved and whether "it works." I, > for one, am glad that the experiment was done (and expecially that it > was done by someone who knows more about this than me!). Thanks, Fred, but your words won't change my decision to leave Unicode support to someone else. I don't support the recent decisions that were made and don't feel strong enough for Unicode to take all the blame for things which don't work like some people expect them to. Here's a TODO list for my successor(s): * change hash value calculation to work on the Py_UNICODE data instead of creating a default encoded cached object (what now is .utf8str) * change .utf8str to hold a default encoded string instead of an UTF-8 string (+ rename .utf8str to .defencstr) * document the new stuff in locale.py and TeX the codecs.py APIs (the docstrings are there -- they just need to be converted to the Python TeX style) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 10 11:14:41 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 11:14:41 +0200 Subject: [Python-Dev] Venting some steam on current developments References: <20000709215057.95047E2673@oratrix.oratrix.nl> Message-ID: <39699401.790447E8@lemburg.com> Jack Jansen wrote: > > I'm getting pretty depressed at the way Python development is > proceeding at the moment. You're not the only one. > I spent all evening tonight on what seemed > to be an almost trivial task: fixing the default unicode conversion on > the Mac. All the machinery is there, the MacOS API has some nice > conversion routines so I thought it'd be a question of putting in a > few hooks and be done, but that turned out not to be so. > > The first problem (for which I can't blame the Python community, I > guess:-) is that the names mac_roman and such are not official IANA > names for the Mac encodings. Actually, it turns out there _are_ no > official names, so the Mac APIs to turn encodings into names work > wonderful for things including all ISO encodings, windows encodings, > etc, but not for the native mac encodings. Sigh. Okay, we do this > ourselves. What exactly is your problem here ? The Python codec engine does know about the Mac encodings and even provides mapping tables for them. > Then I spent an hour recompiling Python because this *&^^$%&*^%$ > setdefaultencoding didn't show up in sys for no conceivable reason. It > turns out it is *deleted* in site.py after using it once. A comment in > sysmodule.c would have been rather nice here... There are lots of comments about it in site.py. sys.setdefaultencoding() is meant to be used *only* in site.py-- that's why it gets removed after having made the final decision on the default encoding. > And then I found out that locale uses only environment variables to > obtain all the basic encoding info in the first place, so that also > has to be fixed up seriously. That's not because we don't like Macs, it's simply because the people hacking on the code don't have Macs around to hack something up. But we did politely ask for someone with Mac-knowledge to add the needed support to locale.py. I did the Unix stuff, Fredrik added Windows support and we hoped that Just or you would add Mac support. Note that site.py will simply choose ASCII as default encoding in case it can't figure out what the current default encoding on the platform is -- there's no breakage there... Since all this support is written in Python there should be really no problem adding new hooks to it. > So many things are changing at the moment, and there seems to be so > little thought of any platform that isn't linux or windows, that I > think Python's portability to minority platforms is being seriously > threatened. And at least I follow closely what is happening, I really > don't want to think of the poor people who do BeOS or WinCE or Palm > Python. Or even some of the lesser-used Unix ports. > > I'm fed up, I'll continue hacking tomorrow, if I don't have to spend > yet another evening trying to get Python to compile again:-( -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jack at oratrix.nl Mon Jul 10 12:08:36 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 10 Jul 2000 12:08:36 +0200 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: Message by "Tim Peters" , Sun, 9 Jul 2000 18:33:21 -0400 , Message-ID: <20000710100837.6232337186D@snelboot.oratrix.nl> > Random question: why isn't the Mac code checked into the main CVS tree? The number one problem at the moment is that cvs-over-ssh doesn't work on the mac. So I currently do a diff on the mac, send the patches to unix, patch, submit. This is okay for the once in a while I have a patch to the core, but not for normal mac development. It'll also fail for non-text files. There's a very good free ssh for the Mac, but it's console-only, and there's a pretty abysmal commercial ssh which could possibly be beaten into forwarding connections, but it's expensive (and it doesn't work:-). I hope the situation will become better shortly. > BTW, I heartily agree that the lack of official IANA names for Mac encodings > is not my fault. Ok, fair enough. Who shall we blame then? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From mal at lemburg.com Mon Jul 10 12:19:21 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 12:19:21 +0200 Subject: [Python-Dev] Encodings References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <200007082206.RAA08314@cj20424-a.reston1.va.home.com> Message-ID: <3969A329.E4D870DD@lemburg.com> Guido van Rossum wrote: > > > Instead of tossing things we should be *constructive* and come > > up with a solution to the hash value problem, e.g. I would > > like to make the hash value be calculated from the UTF-16 > > value in a way that is compatible with ASCII strings. > > I think you are proposing to drop the following rule: > > if a == b then hash(a) == hash(b) > > or also > > if hash(a) != hasb(b) then a != b > > This is very fundamental for dictionaries! The rule is fine for situations where a and b have the same type, but you can't expect coercion to be consistent with it. > Note that it is currently > broken: > > >>> d = {'\200':1} > >>> d['\200'] > 1 > >>> u'\200' == '\200' > 1 > >>> d[u'\200'] > Traceback (most recent call last): > File "", line 1, in ? > KeyError: ? > >>> That's because hash(unicode) currently get's calculated using the UTF-8 encoding as basis, while the compare uses the default encoding -- this needs to be changed, of course. > While you could fix this with a variable encoding, it would be very > hard, probably involving the string to Unicode before taking its hash, > and this would slow down the hash calculation for 8-bit strings > considerably (and these are fundamental for the speed of the > language!). > > So I am for restoring ASCII as the one and only fixed encoding. (Then > you can fix your hash much easier!) > > Side note: the KeyError handling is broken. The bad key should be run > through repr() (probably when the error is raised than when it is > displayed). Agreed. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jack at oratrix.nl Mon Jul 10 12:25:16 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 10 Jul 2000 12:25:16 +0200 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: Message by "Fredrik Lundh" , Mon, 10 Jul 2000 01:12:16 +0200 , <033301bfe9fb$209d3520$f2a6b5d4@hagrid> Message-ID: <20000710102516.7732437186E@snelboot.oratrix.nl> > did you see my changes to the locale module? I rewrote the darn > thing to make it easier to deal with this on non-posix platforms, and > posted the locale.py patch to the patch manager (the CVS repository > had a stale lock, so I couldn't check it in before today). > > heck, I even sent you some pseudocode that showed one way to > implement parts of _getdefaultlocale for the mac, and still you claim > that we're ignoring non unix/windows platforms? You're absolutely right, the tone of my previous message was a bit over the top. I hadn't seen your most recent fixes to _locale (which would have shown me the right way to do this for the Mac) nor the discussion on python-dev over the weekend (which would have made me aware of the site.py/sys.setdefaultencoding interaction). Sorry, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From fredrik at pythonware.com Mon Jul 10 12:48:22 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 12:48:22 +0200 Subject: [Python-Dev] CVS: python/dist/src/Modules posixmodule.c,2.143,2.144 References: <200007091310.GAA27888@slayer.i.sourceforge.net> <20000710013250.P29590@lyra.org> Message-ID: <00a201bfea5c$5ee72280$0900a8c0@SPIFF> greg wrote: > --- posixmodule.c 2000/07/09 13:10:40 2.144 > --- 1541,1548 ---- > return posix_error(); > else > ! #if SIZEOF_LONG == SIZEOF_VOID_P > ! return Py_BuildValue("l", (long) spawnval); > #else > ! return Py_BuildValue("L", (LONG_LONG) spawnval); > #endif > } > hmm. should that be PyLong_FromVoidPtr() ? It will return the appropriate > object type based on the size of a void*. I have no idea; I just fixed the typo... the spawn return value is an int according to the docs and my copy of the header files, so I'll leave it to trent to sort this one out. (it's probably a win64 oddity, and he's the only one here with a win64 box). cheers /F From fredrik at pythonware.com Mon Jul 10 14:10:07 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 14:10:07 +0200 Subject: [Python-Dev] new popen for win32! [status update] References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> <200007092202.RAA14221@cj20424-a.reston1.va.home.com> <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> <200007100209.VAA16999@cj20424-a.reston1.va.home.com> Message-ID: <00de01bfea67$cb12c800$0900a8c0@SPIFF> guido wrote: > So the best order to keep our sanity is really to return > (stdin,stdout,stderr), with the understanding that, as this is the > parent, stdin must be *written* and stdout/stderr must be *read*. ok. > I still can't figure out whether this is what your latest patch does that's what it's supposed to do, at least ;-) the popen2 module now assumes that if the os module exports a popen2 function, it returns the file descriptors in a "sane" order. (same goes for popen3 and popen4, of course). > (wouldn't it make sense if os.popen2 and os.popen3 were also available > on Unix?) definitely. I suggest moving the bulk of popen2.py to os.py (alternatively, to a separate "posixpopen.py" module which is imported from os.py on posix platforms). the popen2 module itself is then reduced to a thin wrapper, and marked as deprecated. comments? From guido at beopen.com Mon Jul 10 15:29:41 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 08:29:41 -0500 Subject: [Python-Dev] non-integer arguments to simple slices in 1.6? Message-ID: <200007101329.IAA18009@cj20424-a.reston1.va.home.com> I got the following email from Scott Johnston which suggests an interesting idea (for 2.0, of course, as that's what we're all working on now). basically, Scott proposes to deprecate __getslice__ (and its friends, __setslice__ and __delslice__) in favor of passing the slice arguments unadorned to __getitem__ if __getslice__ is not defined. On the surface, this seems reasonable to me, except that it doesn't help for extension classes... Any other comments? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------- Forwarded Message (reformatted) Date: Mon, 10 Jul 2000 00:03:07 -0700 From: "Scott F. Johnston" To: guido at python.org Subject: non-integer arguments to simple slices in 1.6? For python 1.6/2.0, have you considered unifying the slice operations? I'd like to be able to use simple "[:]" slice syntax on a class using non-integer indices, and without having negative indices automatically "wrapped". I can do this with the complex slice "[::]" syntax, but adding the extra colon and having two different slicing methods seems inconsistent. (One trapped in __getitem__ receiving unmutated objects in a slice object, the other in __getslice__ receiving mutated ints only.) There is an easy way of unifying this: Allow single-colon slices to be passed unmutated to a __getitem__ method as a slice object IF AND ONLY IF the class doesn't provide a __getslice__ method. (And allow the args to be any object as in the current [::] syntax.) Currently, trying to slice an object without a getslice method raises an error. If my __getitem__ handler is set to handle a [::] slice, why not let it handle [:] slices as well? This would be a good way of slowly depricating the __*slice__ operations. Optimally, I shouldn't have to test for SliceType in my __*item__ methods, and all slices would go unmutated to __*slice__ with an additional step term, but that would break a lot of legacy code. Thanks, - --S ------- End of Forwarded Message From moshez at math.huji.ac.il Mon Jul 10 14:52:58 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 10 Jul 2000 15:52:58 +0300 (IDT) Subject: [Python-Dev] non-integer arguments to simple slices in 1.6? In-Reply-To: <200007101329.IAA18009@cj20424-a.reston1.va.home.com> Message-ID: On Mon, 10 Jul 2000, Guido van Rossum wrote: > I got the following email from Scott Johnston which suggests an > interesting idea (for 2.0, of course, as that's what we're all working > on now). basically, Scott proposes to deprecate __getslice__ (and its > friends, __setslice__ and __delslice__) in favor of passing the slice > arguments unadorned to __getitem__ if __getslice__ is not defined. > > On the surface, this seems reasonable to me, except that it doesn't > help for extension classes... +1. Solving extension classes can be done similarily to the way "in" is solved. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From guido at beopen.com Mon Jul 10 16:08:43 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 09:08:43 -0500 Subject: [Python-Dev] new popen for win32! [status update] In-Reply-To: Your message of "Mon, 10 Jul 2000 14:10:07 +0200." <00de01bfea67$cb12c800$0900a8c0@SPIFF> References: <01cf01bfe922$f585a6c0$f2a6b5d4@hagrid> <007b01bfe9c3$4b657ca0$f2a6b5d4@hagrid> <015401bfe9cc$5f0dbfc0$f2a6b5d4@hagrid> <200007092202.RAA14221@cj20424-a.reston1.va.home.com> <030401bfe9f9$08c01dc0$f2a6b5d4@hagrid> <200007100209.VAA16999@cj20424-a.reston1.va.home.com> <00de01bfea67$cb12c800$0900a8c0@SPIFF> Message-ID: <200007101408.JAA18274@cj20424-a.reston1.va.home.com> > > (wouldn't it make sense if os.popen2 and os.popen3 were also available > > on Unix?) > > definitely. I suggest moving the bulk of popen2.py to os.py (alternatively, > to a separate "posixpopen.py" module which is imported from os.py on > posix platforms). > > the popen2 module itself is then reduced to a thin wrapper, and marked > as deprecated. > > comments? Sounds good to me. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Mon Jul 10 15:31:38 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 09:31:38 -0400 (EDT) Subject: [Python-Dev] Re: CVS: python/dist/src/Lib locale.py,1.7,1.8 In-Reply-To: <20000710020930.T29590@lyra.org> References: <200007091713.KAA02613@slayer.i.sourceforge.net> <20000710020930.T29590@lyra.org> Message-ID: <14697.53306.858387.422925@bitdiddle.concentric.net> >>>>> "GS" == Greg Stein writes: GS> Can I request (from everyone) to do white space changes *only*, GS> or to do functional changes *only*. It will make it a lot easier GS> on the people who are reviewing the checkins. Only if you checkin in your own whitespaces changes! <0.7 wink> Jeremy From thomas at xs4all.net Mon Jul 10 16:32:33 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 16:32:33 +0200 Subject: [Python-Dev] parallel for-loops. Message-ID: <20000710163233.I26534@xs4all.nl> I've attached a patch that adds yet another new feature to Python ;P It's the 'parallel for loop' thing that's come past here and on python-list a few times. Guido sent me the suggested Grammar patch and I went from there, so if I got any of the details wrong, please yell at me, loudly. Here's how it works: >>> for x in [1,2,3,4,5]; y in ['a','b','c','d','e','f','g']: ... print x, y ... 1 a 2 b 3 c 4 d 5 e >>> The two loops are traversed in parallel, like in for x, y in map(None, [1,2,3,4,5], ['a','b','c','d','e','f','g']) *except* that the first IndexError of any of the lists terminates the loop. The syntax is not limited to two lists in parallel, of course! There is no specific limit forced by this patch, so the limit is either the available memory, or the max number of child nodes (32k or so) whichever comes first ;) The patch works internally by passing a tuple of sequences as argument to FOR_LOOP, instead of just a single sequence as before. Likewise, the result of the FOR_LOOP operation is a tuple, which is then unpacked into the proper variables. This is done for all for loops, even single-list ones, so all for-loops take a slight performance hit with this patch. (A tuple-build on entering the loop, and a few iterations, a tuple build and a tuple unpack, even for the common case. I didn't measure it, though.) If this is deemed undesirable, it would be trivial to add a new bytcode, FORMORE_LOOP or such, that handles the multiple-list type of for loop. I almost went ahead and did that, but decided I'd try for a patch that *doesn't* add bytecodes for a change ;) Unfortunately, the patch is binary incompatible, so the bytecode magic does have to be changed. Don't forget to type 'make' inside 'Grammar' after applying it. I'll do some more testing on this, write some docs and some tests, and if noone here has convinced me otherwise, upload it to sourceforge ;) The patch is really suprisingly small and elegant, thanks to Python's extreme simplicity! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- Index: Grammar/Grammar =================================================================== RCS file: /cvsroot/python/python/dist/src/Grammar/Grammar,v retrieving revision 1.35 diff -c -r1.35 Grammar *** Grammar/Grammar 2000/03/28 23:49:00 1.35 --- Grammar/Grammar 2000/07/10 14:06:26 *************** *** 54,60 **** compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | funcdef | classdef if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] while_stmt: 'while' test ':' suite ['else' ':' suite] ! for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite] try_stmt: ('try' ':' suite (except_clause ':' suite)+ #diagram:break ['else' ':' suite] | 'try' ':' suite 'finally' ':' suite) # NB compile.c makes sure that the default except clause is last --- 54,60 ---- compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | funcdef | classdef if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] while_stmt: 'while' test ':' suite ['else' ':' suite] ! for_stmt: 'for' exprlist 'in' testlist (';' exprlist 'in' testlist)* ':' suite ['else' ':' suite] try_stmt: ('try' ':' suite (except_clause ':' suite)+ #diagram:break ['else' ':' suite] | 'try' ':' suite 'finally' ':' suite) # NB compile.c makes sure that the default except clause is last Index: Python/ceval.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/ceval.c,v retrieving revision 2.183 diff -c -r2.183 ceval.c *** Python/ceval.c 2000/07/09 03:09:56 2.183 --- Python/ceval.c 2000/07/10 14:06:28 *************** *** 1473,1481 **** continue; case FOR_LOOP: ! /* for v in s: ... ! On entry: stack contains s, i. ! On exit: stack contains s, i+1, s[i]; but if loop exhausted: s, i are popped, and we jump */ w = POP(); /* Loop index */ --- 1473,1481 ---- continue; case FOR_LOOP: ! /* for v1 in s1; v2 in s2: ... ! On entry: stack contains t(s), i. ! On exit: stack contains t(s), i+1, t(s[i]); but if loop exhausted: s, i are popped, and we jump */ w = POP(); /* Loop index */ *************** *** 2548,2566 **** loop_subscript(v, w) PyObject *v, *w; { ! PySequenceMethods *sq = v->ob_type->tp_as_sequence; ! int i; ! if (sq == NULL || sq->sq_item == NULL) { ! PyErr_SetString(PyExc_TypeError, "loop over non-sequence"); return NULL; } i = PyInt_AsLong(w); ! v = (*sq->sq_item)(v, i); ! if (v) ! return v; ! if (PyErr_ExceptionMatches(PyExc_IndexError)) ! PyErr_Clear(); ! return NULL; } /* Extract a slice index from a PyInt or PyLong, the index is bound to --- 2548,2585 ---- loop_subscript(v, w) PyObject *v, *w; { ! PyObject *res; ! long i; ! int j, len; ! ! if (!PyTuple_Check(v)) { ! PyErr_SetString(PyExc_SystemError, "bad (internal) arg to for loop"); return NULL; } + + len = PyTuple_Size(v); + res = PyTuple_New(len); i = PyInt_AsLong(w); ! ! for (j = 0; j < len; j++) { ! PyObject *u = PyTuple_GET_ITEM(v, j); ! PySequenceMethods *sq = u->ob_type->tp_as_sequence; ! if (sq == NULL || sq->sq_item == NULL) { ! Py_DECREF(res); ! PyErr_SetString(PyExc_TypeError, "loop over non-sequence"); ! return NULL; ! } ! u = (*sq->sq_item)(u, i); ! if (u) { ! PyTuple_SET_ITEM(res, j, u); ! continue; ! } ! if (PyErr_ExceptionMatches(PyExc_IndexError)) ! PyErr_Clear(); ! Py_DECREF(res); ! return NULL; ! } ! return res; } /* Extract a slice index from a PyInt or PyLong, the index is bound to Index: Python/compile.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v retrieving revision 2.114 diff -c -r2.114 compile.c *** Python/compile.c 2000/07/09 03:09:56 2.114 --- Python/compile.c 2000/07/10 14:06:29 *************** *** 2433,2443 **** int break_anchor = 0; int anchor = 0; int save_begin = c->c_begin; REQ(n, for_stmt); ! /* 'for' exprlist 'in' exprlist ':' suite ['else' ':' suite] */ com_addfwref(c, SETUP_LOOP, &break_anchor); block_push(c, SETUP_LOOP); ! com_node(c, CHILD(n, 3)); v = PyInt_FromLong(0L); if (v == NULL) c->c_errors++; --- 2433,2457 ---- int break_anchor = 0; int anchor = 0; int save_begin = c->c_begin; + int inum, i; + REQ(n, for_stmt); ! /* 'for' exprlist 'in' exprlist (';' exprlist 'in' testlist)* ! ':' suite ['else' ':' suite] */ ! ! if (NCH(n) % 2) { ! /* Uneven number of children, so it includes 'else' clause */ ! inum = ((NCH(n) - 5) / 4); ! } else { ! /* No 'else' clause */ ! inum = ((NCH(n) - 2) / 4); ! } com_addfwref(c, SETUP_LOOP, &break_anchor); block_push(c, SETUP_LOOP); ! for (i = 1; i <= inum; i++) ! com_node(c, CHILD(n, i*4 - 1)); ! com_addoparg(c, BUILD_TUPLE, inum); ! com_pop(c, inum-1); v = PyInt_FromLong(0L); if (v == NULL) c->c_errors++; *************** *** 2448,2456 **** com_addoparg(c, SET_LINENO, n->n_lineno); com_addfwref(c, FOR_LOOP, &anchor); com_push(c, 1); ! com_assign(c, CHILD(n, 1), OP_ASSIGN); c->c_loops++; ! com_node(c, CHILD(n, 5)); c->c_loops--; com_addoparg(c, JUMP_ABSOLUTE, c->c_begin); c->c_begin = save_begin; --- 2462,2473 ---- com_addoparg(c, SET_LINENO, n->n_lineno); com_addfwref(c, FOR_LOOP, &anchor); com_push(c, 1); ! com_addoparg(c, UNPACK_TUPLE, inum); ! com_push(c, inum-1); ! for (i = 1; i <= inum; i++) ! com_assign(c, CHILD(n, i*4 - 3), OP_ASSIGN); c->c_loops++; ! com_node(c, CHILD(n, inum*4 + 1)); c->c_loops--; com_addoparg(c, JUMP_ABSOLUTE, c->c_begin); c->c_begin = save_begin; *************** *** 2458,2465 **** com_pop(c, 2); /* FOR_LOOP has popped these */ com_addbyte(c, POP_BLOCK); block_pop(c, SETUP_LOOP); ! if (NCH(n) > 8) ! com_node(c, CHILD(n, 8)); com_backpatch(c, break_anchor); } --- 2475,2483 ---- com_pop(c, 2); /* FOR_LOOP has popped these */ com_addbyte(c, POP_BLOCK); block_pop(c, SETUP_LOOP); ! if (NCH(n) % 2) { ! com_node(c, CHILD(n, inum*4 + 3)); ! } com_backpatch(c, break_anchor); } Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.140 diff -c -r2.140 import.c *** Python/import.c 2000/07/09 03:09:56 2.140 --- Python/import.c 2000/07/10 14:06:31 *************** *** 65,71 **** /* XXX Perhaps the magic number should be frozen and a version field added to the .pyc file header? */ /* New way to come up with the magic number: (YEAR-1995), MONTH, DAY */ ! #define MAGIC (50428 | ((long)'\r'<<16) | ((long)'\n'<<24)) /* Magic word as global; note that _PyImport_Init() can change the value of this global to accommodate for alterations of how the --- 65,71 ---- /* XXX Perhaps the magic number should be frozen and a version field added to the .pyc file header? */ /* New way to come up with the magic number: (YEAR-1995), MONTH, DAY */ ! #define MAGIC (50710 | ((long)'\r'<<16) | ((long)'\n'<<24)) /* Magic word as global; note that _PyImport_Init() can change the value of this global to accommodate for alterations of how the From guido at beopen.com Mon Jul 10 17:32:44 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 10:32:44 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure Message-ID: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> I decided to build the simple embedding demo in Demo/embed/. After fixing the Makefile (checkins coming), I ended up with one problem: the 'import site.py' failed error. When using -v I get this traceback: 'import site' failed; traceback: Traceback (most recent call last): File "/usr/local/lib/python2.0/site.py", line 146, in ? sys.setdefaultencoding('ascii') LookupError: no codec search functions registered: can't find encoding Is there some part of the initialization that I'm forgetting? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Mon Jul 10 16:38:40 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 16:38:40 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Demo/embed Makefile,1.3,1.4 In-Reply-To: <200007101435.HAA09733@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Mon, Jul 10, 2000 at 07:35:15AM -0700 References: <200007101435.HAA09733@slayer.i.sourceforge.net> Message-ID: <20000710163840.J26534@xs4all.nl> On Mon, Jul 10, 2000 at 07:35:15AM -0700, Guido van Rossum wrote: > Log Message: > Adapted for Python 2.0 under RH Linux. [..] > # XXX edit LIBS (in particular) to match $(blddir)/Modules/Makefile > ! LIBS= -lnsl -ldl -lreadline -ltermcap -lieee -lpthread -lutil You probably want -lcrypt in there, too, just in case. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm at hypernet.com Mon Jul 10 16:41:37 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Mon, 10 Jul 2000 10:41:37 -0400 Subject: [Python-Dev] non-integer arguments to simple slices in 1.6? In-Reply-To: <200007101329.IAA18009@cj20424-a.reston1.va.home.com> Message-ID: <1248882392-26064718@hypernet.com> [Guido] > I got the following email from Scott Johnston which suggests an > interesting idea (for 2.0, of course, as that's what we're all > working on now). basically, Scott proposes to deprecate > __getslice__ (and its friends, __setslice__ and __delslice__) in > favor of passing the slice arguments unadorned to __getitem__ if > __getslice__ is not defined. > > On the surface, this seems reasonable to me, except that it > doesn't help for extension classes... We have a problem here, but I think it's in the fact that currently certain slices end up in __getitem__ and some in __getslice__. IOW, I think that __getitem__ should return an item, and this fix (while clever) just compounds a mistake. - Gordon From guido at beopen.com Mon Jul 10 17:43:26 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 10:43:26 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Demo/embed Makefile,1.3,1.4 In-Reply-To: Your message of "Mon, 10 Jul 2000 16:38:40 +0200." <20000710163840.J26534@xs4all.nl> References: <200007101435.HAA09733@slayer.i.sourceforge.net> <20000710163840.J26534@xs4all.nl> Message-ID: <200007101543.KAA25995@cj20424-a.reston1.va.home.com> > > ! LIBS= -lnsl -ldl -lreadline -ltermcap -lieee -lpthread -lutil > > You probably want -lcrypt in there, too, just in case. No, I put *shared* at the earliest convenience in Setup (in fact there's one commented out that I enabled). I recommend everyone else to do the same. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Mon Jul 10 16:47:06 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 16:47:06 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> Message-ID: <3969E1EA.27E7F508@lemburg.com> Guido van Rossum wrote: > > I decided to build the simple embedding demo in Demo/embed/. After > fixing the Makefile (checkins coming), I ended up with one problem: > the 'import site.py' failed error. When using -v I get this traceback: > > 'import site' failed; traceback: > Traceback (most recent call last): > File "/usr/local/lib/python2.0/site.py", line 146, in ? > sys.setdefaultencoding('ascii') > LookupError: no codec search functions registered: can't find encoding > > Is there some part of the initialization that I'm forgetting? Looks like the 'import encodings' failed. Could you check this with -vv ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Mon Jul 10 17:50:49 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 10:50:49 -0500 Subject: [Python-Dev] non-integer arguments to simple slices in 1.6? In-Reply-To: Your message of "Mon, 10 Jul 2000 10:41:37 -0400." <1248882392-26064718@hypernet.com> References: <1248882392-26064718@hypernet.com> Message-ID: <200007101550.KAA26343@cj20424-a.reston1.va.home.com> > We have a problem here, but I think it's in the fact that > currently certain slices end up in __getitem__ and some in > __getslice__. > > IOW, I think that __getitem__ should return an item, and this > fix (while clever) just compounds a mistake. Agreed in an ideal world, but it's done like this for backwards compatibility. The proper solution would be for __getslice__ to always get the raw values given to the slice, but so that __getslice__ takes an optional third argument which gets the 3rd slice value if present. So x[i:j] results in x.__getslice__(i,j) while x[i:j:k] results in x.__getslice__(i,j,k). Missing values are replaced with None, so that x[:] results in x.__getslice__(None, None) and x[::] in x.__getslice__(None, None, None). This is pretty backwards incompatible! Perhaps to the devil with b/w compat? Note that C extensions also get too much service for slicing. It seems a somewhat tedious project to clean all of this up... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Mon Jul 10 16:52:53 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 16:52:53 +0200 Subject: [Python-Dev] parallel for-loops. In-Reply-To: <20000710163233.I26534@xs4all.nl>; from thomas@xs4all.net on Mon, Jul 10, 2000 at 04:32:33PM +0200 References: <20000710163233.I26534@xs4all.nl> Message-ID: <20000710165253.K26534@xs4all.nl> On Mon, Jul 10, 2000 at 04:32:33PM +0200, Thomas Wouters wrote: > I'll do some more testing on this, write some docs and some tests, And already found a bug ;) If anyone is testing this, and can't get 'else' clauses to work, change this: > ! com_node(c, CHILD(n, inum*4 + 3)); into this: > ! com_node(c, CHILD(n, inum*4 + 4)); -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Mon Jul 10 16:56:56 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 10 Jul 2000 17:56:56 +0300 (IDT) Subject: [Python-Dev] parallel for-loops. In-Reply-To: <20000710163233.I26534@xs4all.nl> Message-ID: On Mon, 10 Jul 2000, Thomas Wouters wrote: > Here's how it works: > > >>> for x in [1,2,3,4,5]; y in ['a','b','c','d','e','f','g']: > ... print x, y > ... > 1 a > 2 b > 3 c > 4 d > 5 e > >>> +1 on the concept anyway > If this is deemed undesirable, it would be trivial to add a new bytcode, > FORMORE_LOOP or such, that handles the multiple-list type of for loop. I > almost went ahead and did that, but decided I'd try for a patch that > *doesn't* add bytecodes for a change ;) Unfortunately, the patch is binary > incompatible, so the bytecode magic does have to be changed. It's all right, any patch would be binary incompatible > I'll do some more testing on this, write some docs and some tests, and if > noone here has convinced me otherwise, upload it to sourceforge ;) The patch > is really suprisingly small and elegant, thanks to Python's extreme > simplicity! Hmmmm... I still think there should be a FOR_MORELOOP, but I think this specific patch should be uploaded to SF so we can play with this a bit. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From guido at beopen.com Mon Jul 10 18:22:40 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 11:22:40 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: Your message of "Mon, 10 Jul 2000 08:00:35 MST." <200007101500.IAA13372@slayer.i.sourceforge.net> References: <200007101500.IAA13372@slayer.i.sourceforge.net> Message-ID: <200007101622.LAA01140@cj20424-a.reston1.va.home.com> > Moves some test code into the scope of if __name__ == '__main__', where it > won't get loaded when we're using the classes in this module. Eric, I believe you are mistaken, or at least expressing yourself unclearly in the checkin comment. While the test function *objects* indeed aren't created in your new version, it doesn't actually save any time when loading the module: all the code in a module is parsed, or all the bytecode is unmarshalled, regardless of whether it is executed. All you save in performance is a LOAD_CONST, a MAKE_FUNCTION, and a STORE_NAME -- all of which don't really do any work. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 18:30:57 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 11:30:57 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 16:47:06 +0200." <3969E1EA.27E7F508@lemburg.com> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> Message-ID: <200007101630.LAA01307@cj20424-a.reston1.va.home.com> (There's a linux question at the bottom.) > > I decided to build the simple embedding demo in Demo/embed/. After > > fixing the Makefile (checkins coming), I ended up with one problem: > > the 'import site.py' failed error. When using -v I get this traceback: > > > > 'import site' failed; traceback: > > Traceback (most recent call last): > > File "/usr/local/lib/python2.0/site.py", line 146, in ? > > sys.setdefaultencoding('ascii') > > LookupError: no codec search functions registered: can't find encoding > > > > Is there some part of the initialization that I'm forgetting? > > Looks like the 'import encodings' failed. Could you check this > with -vv ? Thanks for the hint. Seems I've got it nailed down: it's looking for the struct module: [...] import codecs # precompiled from /usr/local/lib/python2.0/codecs.pyc # trying /usr/local/lib/python2.0/struct.so # trying /usr/local/lib/python2.0/structmodule.so # trying /usr/local/lib/python2.0/struct.py # trying /usr/local/lib/python2.0/struct.pyc # trying /usr/local/lib/python2.0/plat-linux2/struct.so # trying /usr/local/lib/python2.0/plat-linux2/structmodule.so # trying /usr/local/lib/python2.0/plat-linux2/struct.py # trying /usr/local/lib/python2.0/plat-linux2/struct.pyc # trying /usr/local/lib/python2.0/lib-tk/struct.so # trying /usr/local/lib/python2.0/lib-tk/structmodule.so # trying /usr/local/lib/python2.0/lib-tk/struct.py # trying /usr/local/lib/python2.0/lib-tk/struct.pyc # trying /usr/local/lib/python2.0/lib-dynload/struct.so # trying /usr/local/lib/python2.0/lib-dynload/structmodule.so 'import site' failed; traceback: Traceback (most recent call last): File "/usr/local/lib/python2.0/site.py", line 146, in ? sys.setdefaultencoding('ascii') LookupError: no codec search functions registered: can't find encoding [...] But the bizarre thing is that the last file it tries (/usr/local/lib/python2.0/lib-dynload/structmodule.so) actually exists!!! OK, so there's code masking the ImportError in import_encodings() in codecs.c. I disabled that (hmm, maybe this should be disabled automatically when -v is used!). Now I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.0/site.py", line 146, in ? sys.setdefaultencoding('ascii') File "/usr/local/lib/python2.0/encodings/__init__.py", line 30, in ? import codecs,aliases File "/usr/local/lib/python2.0/codecs.py", line 10, in ? import struct,types,__builtin__ ImportError: /usr/local/lib/python2.0/lib-dynload/structmodule.so: undefined symbol: PyString_Type OK, I've managed to fix it by a change to the way I build Python: I'm now linking the struct module (and everything in Setup up to and including _codecs) statically. But I guess what's really missing is some kind of flag that tells the linker to export all symbols in the libpython2.0.a file... Is there a way? (I feel so stupid!) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Mon Jul 10 17:44:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 17:44:39 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> Message-ID: <3969EF67.29B9DC05@lemburg.com> Guido van Rossum wrote: > > (There's a linux question at the bottom.) > > > > I decided to build the simple embedding demo in Demo/embed/. After > > > fixing the Makefile (checkins coming), I ended up with one problem: > > > the 'import site.py' failed error. When using -v I get this traceback: > > > > > > 'import site' failed; traceback: > > > Traceback (most recent call last): > > > File "/usr/local/lib/python2.0/site.py", line 146, in ? > > > sys.setdefaultencoding('ascii') > > > LookupError: no codec search functions registered: can't find encoding > > > > > > Is there some part of the initialization that I'm forgetting? > > > > Looks like the 'import encodings' failed. Could you check this > > with -vv ? > > Thanks for the hint. Seems I've got it nailed down: it's looking for > the struct module: > > [...] > import codecs # precompiled from /usr/local/lib/python2.0/codecs.pyc > # trying /usr/local/lib/python2.0/struct.so > # trying /usr/local/lib/python2.0/structmodule.so > # trying /usr/local/lib/python2.0/struct.py > # trying /usr/local/lib/python2.0/struct.pyc > # trying /usr/local/lib/python2.0/plat-linux2/struct.so > # trying /usr/local/lib/python2.0/plat-linux2/structmodule.so > # trying /usr/local/lib/python2.0/plat-linux2/struct.py > # trying /usr/local/lib/python2.0/plat-linux2/struct.pyc > # trying /usr/local/lib/python2.0/lib-tk/struct.so > # trying /usr/local/lib/python2.0/lib-tk/structmodule.so > # trying /usr/local/lib/python2.0/lib-tk/struct.py > # trying /usr/local/lib/python2.0/lib-tk/struct.pyc > # trying /usr/local/lib/python2.0/lib-dynload/struct.so > # trying /usr/local/lib/python2.0/lib-dynload/structmodule.so > 'import site' failed; traceback: > Traceback (most recent call last): > File "/usr/local/lib/python2.0/site.py", line 146, in ? > sys.setdefaultencoding('ascii') > LookupError: no codec search functions registered: can't find encoding > [...] > > But the bizarre thing is that the last file it tries > (/usr/local/lib/python2.0/lib-dynload/structmodule.so) actually > exists!!! > > OK, so there's code masking the ImportError in import_encodings() in > codecs.c. I disabled that (hmm, maybe this should be disabled > automatically when -v is used!). Hard to do since the setting of the verbosity flag is not available to Python code. > Now I get this traceback: > > Traceback (most recent call last): > File "/usr/local/lib/python2.0/site.py", line 146, in ? > sys.setdefaultencoding('ascii') > File "/usr/local/lib/python2.0/encodings/__init__.py", line 30, in ? > import codecs,aliases > File "/usr/local/lib/python2.0/codecs.py", line 10, in ? > import struct,types,__builtin__ > ImportError: /usr/local/lib/python2.0/lib-dynload/structmodule.so: undefined symbol: PyString_Type > > OK, I've managed to fix it by a change to the way I build Python: I'm > now linking the struct module (and everything in Setup up to and > including _codecs) statically. > > But I guess what's really missing is some kind of flag that tells the > linker to export all symbols in the libpython2.0.a file... Is there a > way? (I feel so stupid!) From pf at artcom-gmbh.de Mon Jul 10 17:44:13 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Mon, 10 Jul 2000 17:44:13 +0200 (MEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_userstring,1.1,1.2 In-Reply-To: <200007101414.HAA08212@slayer.i.sourceforge.net> from Jeremy Hylton at "Jul 10, 2000 7:14:43 am" Message-ID: Hi, Jeremy Hylton: > Modified Files: > test_userstring > Log Message: > expect message "no regression test case for method 'encode' [...] > test_userstring > + no regression test case for method 'encode' > + no regression test case for method 'isalnum' > + no regression test case for method 'isalpha' Hmmmm..... Wouldn't it be better to actually write some simple test cases for these methods and add them to 'Lib/test/test_string.py' (if not already done)? My initial idea to put this check into 'test_userstring.py' was to discover missing test cases for new methods that should be copied from test_string.py in order to keep UserString in sync with new functionality added to the builtin string types. Regards, Peter From thomas at xs4all.net Mon Jul 10 17:56:42 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 17:56:42 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <3969EF67.29B9DC05@lemburg.com>; from mal@lemburg.com on Mon, Jul 10, 2000 at 05:44:39PM +0200 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> Message-ID: <20000710175642.L26534@xs4all.nl> On Mon, Jul 10, 2000 at 05:44:39PM +0200, M.-A. Lemburg wrote: > Guido van Rossum wrote: > > import struct,types,__builtin__ > > ImportError: /usr/local/lib/python2.0/lib-dynload/structmodule.so: undefined symbol: PyString_Type [...] > > But I guess what's really missing is some kind of flag that tells the > > linker to export all symbols in the libpython2.0.a file... Is there a > > way? (I feel so stupid!) > >From man ld: > -export-dynamic > When creating an ELF file, add all symbols to the > dynamic symbol table. Normally, the dynamic symbol > table contains only symbols which are used by a dy? > namic object. This option is needed for some uses > of dlopen. > (Not sure whether this is what you're looking for, though.) I think it is. The funny bit is that it should be included in LDFLAGS by default, on Linux. BSDI and some other operating systems need it too (at least newer versions) and gave the same error with shared libraries if the flag was omitted (old BSDI was COFF with fake-shared-libraries, new BSDI is ELF) I didn't bother to check, but does the embed Makefile include python's Makefile* stuff from $prefix/config ? Does it contain -export-dynamic ? If so, very pecurliar... ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Mon Jul 10 18:14:09 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 12:14:09 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_userstring,1.1,1.2 In-Reply-To: References: <200007101414.HAA08212@slayer.i.sourceforge.net> Message-ID: <14697.63057.193077.537823@bitdiddle.concentric.net> >>>>> "PF" == Peter Funk writes: PF> Hmmmm..... Wouldn't it be better to actually write some simple PF> test cases for these methods and add them to PF> 'Lib/test/test_string.py' (if not already done)? PF> My initial idea to put this check into 'test_userstring.py' was PF> to discover missing test cases for new methods that should be PF> copied from test_string.py in order to keep UserString in sync PF> with new functionality added to the builtin string types. That sounds like a good testing strategy, but I'm not sure I agree with a test that fails because it has failed to track a new feature. The current test suite does a mediocre job of testing all features or achieving code coverage. It's annoying that this test is reported as a failure when the module is, in fact, working properly. In the long term, a revision of the testing setup so that different classes of errors can be reported might be useful. The failure to test an encode method could be reported as a warning (non-fatal) instead of an error (fatal). I also don't like the implementation strategy, which causes code to be duplicated in test_string.py and test_userstring.py. I'll add a third module that can be loaded by either test module to perform the specific tests. Finally, test_string doesn't test encode either. Someone want to add a test for that? Jeremy From thomas at xs4all.net Mon Jul 10 18:15:54 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 18:15:54 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules posixmodule.c,2.148,2.149 In-Reply-To: <200007101559.IAA22393@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Mon, Jul 10, 2000 at 08:59:33AM -0700 References: <200007101559.IAA22393@slayer.i.sourceforge.net> Message-ID: <20000710181554.M26534@xs4all.nl> On Mon, Jul 10, 2000 at 08:59:33AM -0700, Fredrik Lundh wrote: > Modified Files: > posixmodule.c > Log Message: > -- get rid of a compiler warning on unix. (as reported > for #100836, but implemented in a different way) > - static PyObject * > - posix_strintint(PyObject *args, char *format, > - int (*func)(const char *, int, int)) [..] Why not get rid of posix_strint() in the same manner ? posix_strint() isn't used at all, currently. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Mon Jul 10 19:22:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 12:22:36 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 17:44:39 +0200." <3969EF67.29B9DC05@lemburg.com> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> Message-ID: <200007101722.MAA01227@cj20424-a.reston1.va.home.com> > > OK, so there's code masking the ImportError in import_encodings() in > > codecs.c. I disabled that (hmm, maybe this should be disabled > > automatically when -v is used!). > > Hard to do since the setting of the verbosity flag is not > available to Python code. Actually, it is: see pydebug.h, included by Python.h: extern DL_IMPORT(int) Py_VerboseFlag; > >From man ld: > > -E > > -export-dynamic > When creating an ELF file, add all symbols to the > dynamic symbol table. Normally, the dynamic symbol > table contains only symbols which are used by a dy? > namic object. This option is needed for some uses > of dlopen. > > (Not sure whether this is what you're looking for, though.) Thanks -- yes, that did it! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 19:25:12 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 12:25:12 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 17:56:42 +0200." <20000710175642.L26534@xs4all.nl> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> Message-ID: <200007101725.MAA01255@cj20424-a.reston1.va.home.com> > I didn't bother to check, but does the embed Makefile include python's > Makefile* stuff from $prefix/config ? Does it contain -export-dynamic ? If > so, very pecurliar... ;-P Makefile includes are notoriously unportable, aren't they? The embed/Makefile is a lame excuse for a Makefile -- it has XXX comments all over the place telling you to edit things to match the Python main Makefile... :-( My fault -- feel free to fix! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Mon Jul 10 18:35:50 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 12:35:50 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101622.LAA01140@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 11:22:40AM -0500 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> Message-ID: <20000710123550.A8478@thyrsus.com> Guido van Rossum : > I believe you are mistaken, or at least expressing yourself unclearly > in the checkin comment. While the test function *objects* indeed > aren't created in your new version, it doesn't actually save any time > when loading the module: all the code in a module is parsed, or all > the bytecode is unmarshalled, regardless of whether it is executed. > All you save in performance is a LOAD_CONST, a MAKE_FUNCTION, and a > STORE_NAME -- all of which don't really do any work. OK, correction accepted. But this is still a good idea for documentation purposes, no? -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. From effbot at telia.com Mon Jul 10 18:45:27 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 18:45:27 +0200 Subject: [Python-Dev] why isn't SRE a shared module? Message-ID: <007901bfea8e$8ee9b600$f2a6b5d4@hagrid> from Modules/Setup.in: # The modules listed here can't be built as shared libraries for # various reasons; therefore they are listed here instead of in the # normal order. # Some modules that are normally always on: regex regexmodule.c regexpr.c # Regular expressions, GNU Emacs style pcre pcremodule.c pypcre.c # Regular expressions, Perl style (for re.py) posix posixmodule.c # posix (UNIX) system calls signal signalmodule.c # signal(2) _sre _sre.c # Fredrik Lundh's new regular expressions possibly a stupid question, but what exactly is SRE doing in there? From jim at interet.com Mon Jul 10 18:43:03 2000 From: jim at interet.com (James C. Ahlstrom) Date: Mon, 10 Jul 2000 12:43:03 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> Message-ID: <3969FD17.487DA96A@interet.com> I just got back from vacation, so I am catching up. The following concerns Windows only, not *.so files on Unix. Background: Existing foo.pyd Windows extensions will crash the new Python because foo.pyd will load python15.dll, and python.exe will load python20.dll. MarkH explained why: [Mark] > The 1.5 module is linked against Python15.dll. When Python.exe (linked > against Python16.dll) starts up, it initializes the Python data structures > in Python16.dll. When Python then imports foo.pyd (linked against > Python15.dll), it immediately tries to call the functions in that DLL (such > as getting the thread state). As Python has not been initialized in that > DLL, we immediately die. This is really bad. Normally under Windows, DLL names do not change unless the API exported is changed in a major way. For example, there have been several versions of mfc42.dll without changing the name. [Mark continues] > Ironically, if Python1x.dll was simply named "Python.dll", there is a > _reasonable_ chance it would work fine. The cost of doing this tho, is > that you can not have Python 1.5 and Python 1.6 "side by side" on the same > machine. What this means is that if the new Python 2.0 (1.6?) simply names its DLL python15.dll just as before, everything Just Works almost. That is, it Just Works provided that foo.pyd only calls Python C functions whose interface has not changed. You can support Python 1.5 and 1.6 by removing the python*.dll from the Windows directories, and putting it in the directory of python.exe so it goes with the proper executable. Guido van Rossum wrote: > There are endless variations on this theme. What's missing at the > moment is a bit of requirements analysis. What's the problem we're > trying to solve here? So far, the only problem that came up was that > on Windows, you get an obscure crash when trying to load an extension > built for Python 1.5(.x). Yes, and this is a major problem, and is un-Windows-like. > Do we really need a whole new version > negotiating architecture? No, just keep the old name "python15.dll". Old foo.pyd will still work if they use only Python C functions with the same interface. Individual *.pyd authors will have to advise users whether they need to upgrade to new *.pyd versions or not. > You can already get the version string by > looking at Py_GetVersion() -- this also answers the question of how a > version is represented. True. And on Windows, there is a standard Version resource string which gives the DLL version, and can be read without loading the DLL. This string is referenced by the Wise (and other) installers to decide whether a DLL is newer and should be replaced. > On Windows, link-time compatibility is broken whenever we change the > second digit of the version number, e.g. 15, 16, 20. Yikes, lets not let that happen! JimA From effbot at telia.com Mon Jul 10 19:07:15 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 19:07:15 +0200 Subject: [Python-Dev] new unicode hash calculation References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> Message-ID: <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> mal wrote: > * change hash value calculation to work on the Py_UNICODE data > instead of creating a default encoded cached object (what > now is .utf8str) it this what you had in mind? static long unicode_hash(PyUnicodeObject *self) { register int len; register Py_UNICODE *p; register long x; if (self->hash != -1) return self->hash; len = PyUnicode_GET_SIZE(self); p = PyUnicode_AS_UNICODE(self); x = *p << 7; while (--len >= 0) x = (1000003*x) ^ *p++; x ^= a->ob_size; if (x == -1) x = -2; self->hash = x; return x; } From jeremy at beopen.com Mon Jul 10 19:24:27 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 13:24:27 -0400 (EDT) Subject: [Python-Dev] string.join and bad sequences In-Reply-To: <200007101708.KAA08018@slayer.i.sourceforge.net> References: <200007101708.KAA08018@slayer.i.sourceforge.net> Message-ID: <14698.1739.660431.756932@bitdiddle.concentric.net> I added a test case to Lib/test/string_tests.py that uses a sequence that returns the wrong answer from __len__. I've used this test in a number of places to make sure the interpreter doesn't dump core when it hits a bad user-defined sequence. class Sequence: def __init__(self): self.seq = 'wxyz' def __len__(self): return len(self.seq) def __getitem__(self, i): return self.seq[i] class BadSeq2(Sequence): def __init__(self): self.seq = ['a', 'b', 'c'] def __len__(self): return 8 The test of string.join and " ".join don't dump core, but they do raise an IndexError. I wonder if that's the right thing to do, because the other places where it is handled no exception is raised. The question boils down to the semantics of the sequence protocol. The string code defintion is: if __len__ returns X, then the length is X thus, __getitem__ should succeed for range(0, X) if it doesn't, raise an IndexError The other code (e.g. PySequence_Tuple) definition is: if __len__ return X, then the length is <= X if __getitem__ succeeds for range(0, X), then length is indeed X if it does not, then length is Y + 1 for highest Y where Y is greatest index that actually works The definition in PySequence_Tuple seemed quite clever when I first saw it, but I like it less now. If a user-defined sequence raises IndexError when len indicates it should not, the code is broken. The attempt to continue anyway is masking an error in user code. I vote for fixing PySequence_Tuple and the like to raise an IndexError. Jeremy From tim_one at email.msn.com Mon Jul 10 19:26:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 13:26:36 -0400 Subject: [Python-Dev] file closed! (was Re: CVS read/write access) In-Reply-To: <3969B399.FC5E1AC2@stud.ntnu.no> Message-ID: [Peter Schneider-Kamp] > ... > It was the group. But 20 minutes after I found out I checked again > and suddenly python had appeared. Must have been this cron delay. Yes, this sure fits the symptoms described at: http://sourceforge.net/docs/site/delay.php ... Updates to these other systems happen via cron 4 times per day, so changes made on the web site will appear to be live, but will not take effect until the next cron update. ... This includes all functions relating to mail aliases, shell passwords, user additions, group member changes, cvs repository creation, etc a-fine-art-to-knowing-when-sitting-on-your-ass-is-the-solution-ly y'rs - tim From mal at lemburg.com Mon Jul 10 19:30:20 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 19:30:20 +0200 Subject: [Python-Dev] new unicode hash calculation References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> Message-ID: <396A082C.77B4D71D@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > * change hash value calculation to work on the Py_UNICODE data > > instead of creating a default encoded cached object (what > > now is .utf8str) > > it this what you had in mind? > > static long > unicode_hash(PyUnicodeObject *self) > { > register int len; > register Py_UNICODE *p; > register long x; > > if (self->hash != -1) > return self->hash; > len = PyUnicode_GET_SIZE(self); > p = PyUnicode_AS_UNICODE(self); > x = *p << 7; > while (--len >= 0) > x = (1000003*x) ^ *p++; > x ^= a->ob_size; > if (x == -1) > x = -2; > self->hash = x; > return x; > } > > Well, sort of. It should be done in such a way that Unicode strings which only use the lower byte produce the same hash value as normal 8-bit strings -- is this the case for the above code ? My first idea was to apply a kind of two pass scan which first only uses the lower byte and then the higher byte to calculate a hash value. Both passes would use the same algorithm as the one for 8-bit strings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 10 19:32:31 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 10 Jul 2000 19:32:31 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <200007101722.MAA01227@cj20424-a.reston1.va.home.com> Message-ID: <396A08AF.655B4836@lemburg.com> Guido van Rossum wrote: > > > > OK, so there's code masking the ImportError in import_encodings() in > > > codecs.c. I disabled that (hmm, maybe this should be disabled > > > automatically when -v is used!). > > > > Hard to do since the setting of the verbosity flag is not > > available to Python code. > > Actually, it is: see pydebug.h, included by Python.h: > > extern DL_IMPORT(int) Py_VerboseFlag; Yes... I meant: it is not available from Python. (mx.Tools publishes an interface to this flag: sys.verbosity() which also allows setting the value at runtime.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Mon Jul 10 20:38:46 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 13:38:46 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: Your message of "Mon, 10 Jul 2000 12:35:50 -0400." <20000710123550.A8478@thyrsus.com> References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> Message-ID: <200007101838.NAA01448@cj20424-a.reston1.va.home.com> > From: "Eric S. Raymond" > Guido van Rossum : > > I believe you are mistaken, or at least expressing yourself unclearly > > in the checkin comment. While the test function *objects* indeed > > aren't created in your new version, it doesn't actually save any time > > when loading the module: all the code in a module is parsed, or all > > the bytecode is unmarshalled, regardless of whether it is executed. > > All you save in performance is a LOAD_CONST, a MAKE_FUNCTION, and a > > STORE_NAME -- all of which don't really do any work. > > OK, correction accepted. But this is still a good idea for documentation > purposes, no? Actually, it makes manual testing of the module a little harder: from inside Python, I used to be able to say >>> import urllib >> urllib.test() With your change that doesn't work any more, so I'd rather see you revert it back... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 20:43:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 13:43:29 -0500 Subject: [Python-Dev] why isn't SRE a shared module? In-Reply-To: Your message of "Mon, 10 Jul 2000 18:45:27 +0200." <007901bfea8e$8ee9b600$f2a6b5d4@hagrid> References: <007901bfea8e$8ee9b600$f2a6b5d4@hagrid> Message-ID: <200007101843.NAA01635@cj20424-a.reston1.va.home.com> > from Modules/Setup.in: > > # The modules listed here can't be built as shared libraries for > # various reasons; therefore they are listed here instead of in the > # normal order. > > # Some modules that are normally always on: > > regex regexmodule.c regexpr.c # Regular expressions, GNU Emacs style > pcre pcremodule.c pypcre.c # Regular expressions, Perl style (for re.py) > posix posixmodule.c # posix (UNIX) system calls > signal signalmodule.c # signal(2) > _sre _sre.c # Fredrik Lundh's new regular expressions > > possibly a stupid question, but what exactly is SRE doing > in there? I think the comments are confusing. The first comment has it right -- I think posix and signal *must* be static. I'm not so sure about the rest... It's just recommended to link them statically because you'll end up loading them into 99% of all Python processes anyway. Of course, that's no longer true fo regex or pcre so they should be moved down anyway. It's up to you if you want to suggest special status for _sre.c... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 20:51:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 13:51:05 -0500 Subject: [Python-Dev] new unicode hash calculation In-Reply-To: Your message of "Mon, 10 Jul 2000 19:07:15 +0200." <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> Message-ID: <200007101851.NAA01792@cj20424-a.reston1.va.home.com> > mal wrote: > > > * change hash value calculation to work on the Py_UNICODE data > > instead of creating a default encoded cached object (what > > now is .utf8str) [effbot] > it this what you had in mind? > > static long > unicode_hash(PyUnicodeObject *self) > { > register int len; > register Py_UNICODE *p; > register long x; > > if (self->hash != -1) > return self->hash; > len = PyUnicode_GET_SIZE(self); > p = PyUnicode_AS_UNICODE(self); > x = *p << 7; > while (--len >= 0) > x = (1000003*x) ^ *p++; > x ^= a->ob_size; > if (x == -1) > x = -2; > self->hash = x; > return x; > } You mean this (fixed a->ob_size, restored comment): static long unicode_hash(PyUnicodeObject *self) { /* Since Unicode objects compare equal to their ASCII string counterparts, they should also use the ASCII strings as basis for their hash value. This is needed to assure that strings and Unicode objects behave in the same way as dictionary keys. */ register int len; register Py_UNICODE *p; register long x; if (self->hash != -1) return self->hash; len = PyUnicode_GET_SIZE(self); p = PyUnicode_AS_UNICODE(self); x = *p << 7; while (--len >= 0) x = (1000003*x) ^ *p++; x ^= PyUnicode_GET_SIZE(self); if (x == -1) x = -2; self->hash = x; return x; } --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 20:58:07 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 13:58:07 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Mon, 10 Jul 2000 12:43:03 -0400." <3969FD17.487DA96A@interet.com> References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> <3969FD17.487DA96A@interet.com> Message-ID: <200007101858.NAA01814@cj20424-a.reston1.va.home.com> [James Ahlstrom makes a plea for keeping the DLL name unchanged (python15.dll) so that existing extensions don't have to be rebuilt if they don't make calls to API functions that changed.] The problem with this is that it's hard to say whether this is the case. We haven't made an effort to keep the APIs compatible, because we were planning to change the DLL name to be incompatible. I guess we'd need a Microsoft style testing department that collects a large set of existing 1.5 style extensions, builds a Python 2.0 DLL named python15.dll, and tests whether all those 1.5 style extensions work correctly. Seems a lot of work to me. Plus, we'd have to check whether we didn't change any of the object lay-outs that are accessible via macros... Frankly, I'd rather declare incompatibility than do all the work. What's it good for? We're not forcing people to upgrade if their favorite DLLs haven't been upgraded yet... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 21:02:37 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 14:02:37 -0500 Subject: [Python-Dev] new unicode hash calculation In-Reply-To: Your message of "Mon, 10 Jul 2000 19:30:20 +0200." <396A082C.77B4D71D@lemburg.com> References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> <396A082C.77B4D71D@lemburg.com> Message-ID: <200007101902.OAA01883@cj20424-a.reston1.va.home.com> > Well, sort of. It should be done in such a way that Unicode > strings which only use the lower byte produce the same hash > value as normal 8-bit strings -- is this the case for the > above code ? I already checked it -- it does, for ASCII or Latin-1 as the default encoding. Good enough for me. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Mon Jul 10 20:25:19 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 14:25:19 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101838.NAA01448@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 01:38:46PM -0500 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> Message-ID: <20000710142519.A8794@thyrsus.com> Guido van Rossum : > With your change that doesn't work any more, so I'd rather see you > revert it back... How do I do that in CVS-land? BTW, this patch was mostly just a test to verify that my CVS access mechanics work. So I'm not miffed at being asked to back it out. Also BTW, my access mechanics are a Python script called `forgetool' that automates away a bunch of CVS housekeeping -- setting CVSROOT properly on a per-project basis is one of the things it does. I'll write some docs and release it shortly. -- Eric S. Raymond The conclusion is thus inescapable that the history, concept, and wording of the second amendment to the Constitution of the United States, as well as its interpretation by every major commentator and court in the first half-century after its ratification, indicates that what is protected is an individual right of a private citizen to own and carry firearms in a peaceful manner. -- Report of the Subcommittee On The Constitution of the Committee On The Judiciary, United States Senate, 97th Congress, second session (February, 1982), SuDoc# Y4.J 89/2: Ar 5/5 From effbot at telia.com Mon Jul 10 20:31:01 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 20:31:01 +0200 Subject: [Python-Dev] new unicode hash calculation References: <200007072024.WAA02272@loewis.home.cs.tu-berlin.de> <3966669D.B436CD39@prescod.net> <20000707183213.P29590@lyra.org> <200007081508.KAA07351@cj20424-a.reston1.va.home.com> <3967513C.BAF459FB@lemburg.com> <14695.21928.918081.199053@cj42289-a.reston1.va.home.com> <39699EC4.C4B30FC8@lemburg.com> <00db01bfea91$ab3380e0$f2a6b5d4@hagrid> <396A082C.77B4D71D@lemburg.com> <200007101902.OAA01883@cj20424-a.reston1.va.home.com> Message-ID: <012f01bfea9d$0a1cfc20$f2a6b5d4@hagrid> mal wrote: > It should be done in such a way that Unicode strings which > only use the lower byte produce the same hash value as > normal 8-bit strings -- is this the case for the above code ? yup. it's the same algorithm as for 8-bit strings, but using larger characters. as long as the high bits are zero, it (obviously) gives the same result. guido: > Good enough for me. I'll interpret that as a "okay, check it in". From guido at beopen.com Mon Jul 10 21:26:25 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 14:26:25 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: Your message of "Mon, 10 Jul 2000 14:25:19 -0400." <20000710142519.A8794@thyrsus.com> References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> Message-ID: <200007101926.OAA02072@cj20424-a.reston1.va.home.com> > How do I do that in CVS-land? cvs admin -o Or you could retrieve the previous version and check it in on top, with a comment such as "eating my words". :-) > BTW, this patch was mostly just a test to verify that my CVS access > mechanics work. So I'm not miffed at being asked to back it out. Thanks. > Also BTW, my access mechanics are a Python script called `forgetool' > that automates away a bunch of CVS housekeeping -- setting CVSROOT > properly on a per-project basis is one of the things it does. I'll > write some docs and release it shortly. I thought that you almost never have to set the CVSROOT variable once you've established your project work tree -- it's all stored in CVS/Root anyway. I believe CVSROOT is only used when you do a "cvs checkout" and that doesn't happen very often... --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 10 21:36:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 14:36:05 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 19:32:31 +0200." <396A08AF.655B4836@lemburg.com> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <200007101722.MAA01227@cj20424-a.reston1.va.home.com> <396A08AF.655B4836@lemburg.com> Message-ID: <200007101936.OAA02180@cj20424-a.reston1.va.home.com> > Yes... I meant: it is not available from Python. (mx.Tools > publishes an interface to this flag: sys.verbosity() which > also allows setting the value at runtime.) It would make a lot of sense for the sys module to allow access to the values of all the Python command line options, and perhaps to allow changing them. Anybody interested in designing an API here? Some requirements would be platform independence, extensibility, and necessarily the ability to work even in an environment without command line flags (since it still has the corresponding internal flags). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Mon Jul 10 20:50:32 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 14:50:32 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101926.OAA02072@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 02:26:25PM -0500 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> <200007101926.OAA02072@cj20424-a.reston1.va.home.com> Message-ID: <20000710145031.A8888@thyrsus.com> Guido van Rossum : > I thought that you almost never have to set the CVSROOT variable once > you've established your project work tree -- it's all stored in > CVS/Root anyway. I believe CVSROOT is only used when you do a "cvs > checkout" and that doesn't happen very often... It's also needed when you login for anonymous access. Forgetool is intended for people like me who need to manage access to multiple SourceForge projects, some as a developer and some anonymously. It manages some local state about which projects you have developer access to and uses that to set CVSROOT and CVS_RSH correctly. Forgetool also supplies boilerplate for commands to copy files to the project HTTP directory. Things it will do soon: 1) Manage shared session keys so you don't have to type a password on each command. 2) Remote scripting of module releases. The basic idea is to make forgetool a Swiss-army knife for SourceForge developers who need to remote-script various common operations. This capability is not a big deal when you are active in one or two projects -- but I run thirty-five (yes, that's 35) projects that are waiting to move to SourceForge the day I can script the release process. -- Eric S. Raymond Every election is a sort of advance auction sale of stolen goods. -- H.L. Mencken From gstein at lyra.org Mon Jul 10 20:50:14 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 11:50:14 -0700 Subject: [Python-Dev] Re: CVS: python/dist/src/Lib locale.py,1.7,1.8 In-Reply-To: <14697.53306.858387.422925@bitdiddle.concentric.net>; from jeremy@beopen.com on Mon, Jul 10, 2000 at 09:31:38AM -0400 References: <200007091713.KAA02613@slayer.i.sourceforge.net> <20000710020930.T29590@lyra.org> <14697.53306.858387.422925@bitdiddle.concentric.net> Message-ID: <20000710115014.G29590@lyra.org> On Mon, Jul 10, 2000 at 09:31:38AM -0400, Jeremy Hylton wrote: > >>>>> "GS" == Greg Stein writes: > > GS> Can I request (from everyone) to do white space changes *only*, > GS> or to do functional changes *only*. It will make it a lot easier > GS> on the people who are reviewing the checkins. > > Only if you checkin in your own whitespaces changes! <0.7 wink> hehe... I will! I will! :-) [ just been busy folding mod_dav into Apache 2.0. that is pretty much done now... ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul at prescod.net Mon Jul 10 20:54:05 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 10 Jul 2000 13:54:05 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> <20000710022047.V29590@lyra.org> Message-ID: <396A1BCD.E08FB64D@prescod.net> Greg Stein wrote: > > > Because Python supports a configuration time option to link modules > > statically. Of course. I wasn't thinking. But here's another naive question, on what platforms is it significantly better to statically link and how is it significantly better? > Not to mention that the .so is loaded into the process' address space. I > don't think that you can have two symbols in the space with the same name. I've never been clear on that issue. It seems like an unreasonably strict constraint. Adding a function called "doit" to one library could break another dynamically library that happens to have the same name defined? I'd call that a bug in the dynamic loading infrastructure (and certainly not a problem on Windows!)! -- Paul Prescod - Not encumbered by corporate consensus "Computer Associates is expected to come in with better than expected earnings." Bob O'Brien, quoted in - http://www.fool.com/news/2000/foth000316.htm From paul at prescod.net Mon Jul 10 21:00:19 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 10 Jul 2000 14:00:19 -0500 Subject: [Python-Dev] file closed! (was Re: CVS read/write access) References: <39699715.E3368F53@stud.ntnu.no> <20000710014329.Q29590@lyra.org> <3969B399.FC5E1AC2@stud.ntnu.no> Message-ID: <396A1D43.A0F8FF50@prescod.net> Peter Schneider-Kamp wrote: > > Greg Stein wrote: > > > > If so, then it is a problem that the SF Admins must solve. It means that you > > haven't been placed into the appropriate group or somesuch on SF. Log a > ----- > > It was the group. But 20 minutes after I found out I checked again > and suddenly python had appeared. Must have been this cron delay. I had the same symptoms and the same solution (wait a few hours) when I joined pyxml. We should remember it in the future. -- Paul Prescod - Not encumbered by corporate consensus "Computer Associates is expected to come in with better than expected earnings." Bob O'Brien, quoted in - http://www.fool.com/news/2000/foth000316.htm From guido at beopen.com Mon Jul 10 22:14:50 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 10 Jul 2000 15:14:50 -0500 Subject: [Python-Dev] string.join and bad sequences In-Reply-To: Your message of "Mon, 10 Jul 2000 13:24:27 -0400." <14698.1739.660431.756932@bitdiddle.concentric.net> References: <200007101708.KAA08018@slayer.i.sourceforge.net> <14698.1739.660431.756932@bitdiddle.concentric.net> Message-ID: <200007102014.PAA02382@cj20424-a.reston1.va.home.com> > I added a test case to Lib/test/string_tests.py that uses a sequence > that returns the wrong answer from __len__. I've used this test in a > number of places to make sure the interpreter doesn't dump core when > it hits a bad user-defined sequence. > > class Sequence: > def __init__(self): self.seq = 'wxyz' > def __len__(self): return len(self.seq) > def __getitem__(self, i): return self.seq[i] > > class BadSeq2(Sequence): > def __init__(self): self.seq = ['a', 'b', 'c'] > def __len__(self): return 8 > > The test of string.join and " ".join don't dump core, but they do > raise an IndexError. I wonder if that's the right thing to do, > because the other places where it is handled no exception is raised. > > The question boils down to the semantics of the sequence protocol. > > The string code defintion is: > if __len__ returns X, then the length is X > thus, __getitem__ should succeed for range(0, X) > if it doesn't, raise an IndexError > > The other code (e.g. PySequence_Tuple) definition is: > if __len__ return X, then the length is <= X > if __getitem__ succeeds for range(0, X), then length is indeed X > if it does not, then length is Y + 1 for highest Y > where Y is greatest index that actually works > > The definition in PySequence_Tuple seemed quite clever when I first > saw it, but I like it less now. If a user-defined sequence raises > IndexError when len indicates it should not, the code is broken. The > attempt to continue anyway is masking an error in user code. > > I vote for fixing PySequence_Tuple and the like to raise an > IndexError. I'm not sure I agree. When Steve Majewski proposed variable-length sequences, we ended up conceding that __len__ is just a hint. The actual length can be longer or shorter. The map and filter functions allow this, and so do min/max and others that go over sequences, and even (of course) the for loop. (In fact, the preferred behavior is not to call __len__ at all but just try x[0], x[1], x[2], ... until IndexError is hit.) If I read your description of PySequence_Tuple(), it accepts a __len__ that overestimates but not one that understestimates. That's wrong. (In Majewski's example, a tar file wrapper would claim to have 0 items but iterating over it in ascending order would access all the items in the file. Claiming some arbitrary integer as __len__ would be wrong.) So string.join(BadSeq2(), "") or "".join(BadSeq2()) should return "abc". --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Mon Jul 10 21:55:55 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 21:55:55 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <396A1BCD.E08FB64D@prescod.net>; from paul@prescod.net on Mon, Jul 10, 2000 at 01:54:05PM -0500 References: <000001bfe9b5$de7168f0$060210ac@private> <200007092152.QAA14143@cj20424-a.reston1.va.home.com> <3968FEE0.E1345788@prescod.net> <200007100149.UAA16917@cj20424-a.reston1.va.home.com> <20000710022047.V29590@lyra.org> <396A1BCD.E08FB64D@prescod.net> Message-ID: <20000710215555.Q26534@xs4all.nl> On Mon, Jul 10, 2000 at 01:54:05PM -0500, Paul Prescod wrote: [Quoting Guido, IIRC] > > > Because Python supports a configuration time option to link modules > > > statically. > Of course. I wasn't thinking. But here's another naive question, on what > platforms is it significantly better to statically link and how is it > significantly better? Well, platforms that do not support dynamic linking/loading, for one ! :-) Not that frequent nowadays, but still something to take into account. Also, some platforms, like BSDI until not that long ago, use a binary format like COFF, which doesn't support shared libraries all that well. It's more of a hack (and a slightly insecure one, at that) than a structural solution. Which is why BSDI moved to ELF, thankfully :-) Also, shared libraries are an aditional performance hit, because of the extra layer of indirection (sometimes more than one) and on some architectures different memory layout. So people might choose to link (some) modules static for that reason. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From barry at scottb.demon.co.uk Mon Jul 10 22:09:20 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Mon, 10 Jul 2000 21:09:20 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007100149.UAA16917@cj20424-a.reston1.va.home.com> Message-ID: <000701bfeaaa$bb8dde40$060210ac@private> > There are endless variations on this theme. What's missing at the > moment is a bit of requirements analysis. What's the problem we're > trying to solve here? So far, the only problem that came up was that > on Windows, you get an obscure crash when trying to load an extension > built for Python 1.5(.x). Do we really need a whole new version > negotiating architecture? You can already get the version string by > looking at Py_GetVersion() -- this also answers the question of how a > version is represented. I post the first mail as I think it reflects poorly on Python if it crashes for this preventable reason. How important this problem is depends on how many users it will affect. Is it only a few .pyd that fail or all of them? Will a few users see this or lots of them? I'd hope one requirement is not to look bad in the eyes of the python users. When the old extension calls Py_GetVersion() it will be the python15.dll:Py_GetVersion(). Not the new one. Integer version values would be nicer to handle then hacking a string up. Barry From esr at thyrsus.com Mon Jul 10 22:28:55 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 16:28:55 -0400 Subject: [Python-Dev] Changes to ConfigParser Message-ID: <20000710162855.A9245@thyrsus.com> Earlier today, I committed a patch to ConfigParser that adds three new methods to the class. Here is the documentation: \begin{methoddesc}{has_option}{section, option} If the given section exists, and contains the given option. return 1; otherwise return 0. (New in 1.6) \end{methoddesc} \begin{methoddesc}{set}{section, option, value} If the given section exists, set the given option to the specified value; otherwise raise \exception{NoSectionError}. (New in 1.6) \end{methoddesc} \begin{methoddesc}{write}{fileobect} Write a representation of the configuration to the specified file object. This representation can be parsed by a future \method{read()} call. (New in 1.6) \end{methoddesc} These new methods are additions to the class, and do not change any existing code. Nevertheless Guido sent me a heads-up that I had committed a marginal violation of Python etiquette by changing the module without the explicit sign-off of the maintainers. For this I apologize, specifically to Andrew Kuchling and Barry Warsaw. Please note that I specifically refrained from fixing a bug in the existing code that was exposed by the new methods, in order to avoid the risk of breaking compatibility. Now I want to explain what I'm doing, specifically the next steps in my plan, and make sure there is a consensus to support it. I am working on a program called `forgetool' that is intended as a front end to SourceForge. It will keep your CVSROOT set properly as you hop between multiple projects, make it easy to do uploads to project HTTP directories without remembering a lot of boilerplate, enable remote scripting of releases, and in general serve as a SourceForge developer's Swiss-army knife. To do these things, forgetool needs to maintain some local state that is conveniently represented in the format of a Windows .ini file. More, it needs to be able to *update* .ini files as well as parse them. Accordingly, forgetool subclasses ConfigParser into EnhancedConfigParser adding the above methods. After testing them, I copied this code into ConfigParser for others to use. Two more things remain to be done: First, for completeness there ought to be remove_section and remove_option methods (though forgetool does not yet use them). I have documented these as follows: \begin{methoddesc}{remove_option}{section, option} Remove the specified \var{option} from the specified \var{section}. If the section does not exist, raise \exception{NoSectionError}. If the option existed to be removed, return 1; otherwise return 0. (New in 1.6) \end{methoddesc} \begin{methoddesc}{remove_section}{section} Remove the specified \var{section} from the configuration. If the section in fact existed, return 1. Otherwise return 0. \end{methoddesc} Second, the new methods expose a bug in the existing code. Because the case of section and option names is folded on input, the new write() method emits edited configurations with their case smashed. I think the existing code should be fixed to preserve case, with string.lower() being applied at key lookup time. Does anybody have a problem with these changes? Barry? Andrew? Again, I apologize for offending the local norms. I'm still learning... -- Eric S. Raymond If gun laws in fact worked, the sponsors of this type of legislation should have no difficulty drawing upon long lists of examples of criminal acts reduced by such legislation. That they cannot do so after a century and a half of trying -- that they must sweep under the rug the southern attempts at gun control in the 1870-1910 period, the northeastern attempts in the 1920-1939 period, the attempts at both Federal and State levels in 1965-1976 -- establishes the repeated, complete and inevitable failure of gun laws to control serious crime. -- Senator Orrin Hatch, in a 1982 Senate Report From akuchlin at mems-exchange.org Mon Jul 10 22:29:55 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 10 Jul 2000 16:29:55 -0400 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162855.A9245@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 10, 2000 at 04:28:55PM -0400 References: <20000710162855.A9245@thyrsus.com> Message-ID: <20000710162955.C7313@kronos.cnri.reston.va.us> On Mon, Jul 10, 2000 at 04:28:55PM -0400, Eric S. Raymond wrote: >Does anybody have a problem with these changes? Barry? Andrew? *blink* I've never even touched the ConfigParser module, so I don't know why Guido thought I had any interest in it. The first check-in comment for the module is "This was originally written by Ken and later revamped by Barry." --amk From esr at thyrsus.com Mon Jul 10 22:43:04 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 16:43:04 -0400 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162955.C7313@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Mon, Jul 10, 2000 at 04:29:55PM -0400 References: <20000710162855.A9245@thyrsus.com> <20000710162955.C7313@kronos.cnri.reston.va.us> Message-ID: <20000710164304.B9337@thyrsus.com> Andrew Kuchling : > *blink* I've never even touched the ConfigParser module, so I don't > know why Guido thought I had any interest in it. The first check-in > comment for the module is "This was originally written by Ken and > later revamped by Barry." Doh. Sorry. My bad. It is Ken, not Andrew. -- Eric S. Raymond A ``decay in the social contract'' is detectable; there is a growing feeling, particularly among middle-income taxpayers, that they are not getting back, from society and government, their money's worth for taxes paid. The tendency is for taxpayers to try to take more control of their finances .. -- IRS Strategic Plan, (May 1984) From fdrake at beopen.com Mon Jul 10 23:00:37 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:00:37 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules md5.h,2.5,2.6 md5c.c,2.3,2.4 In-Reply-To: <004201bfea3f$17b154c0$f2a6b5d4@hagrid> References: <200007100421.VAA16454@slayer.i.sourceforge.net> <004201bfea3f$17b154c0$f2a6b5d4@hagrid> Message-ID: <14698.14709.491272.693396@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > weren't you supposed to drop out of sight for a while? I did; I just poked my head round the corner when they were all asleep! ;-) But I've been out of touch for most of the day, so they've had as much of my time as they can handle for a couple of hours. Maybe I can get some of this email deleted! > besides, I'd assigned these patches to myself, and applied > them locally. just thought I'd get some sleep before I checked > them in again. > > (iow, please check the patch archive before hacking along. > someone else might be working on the same thing) Ah, I'd checked the open patches, but was in too much of a rush. Sorry! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Mon Jul 10 23:05:48 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:05:48 -0400 (EDT) Subject: [Python-Dev] CVS: python/dist/src/Modules posixmodule.c,2.143,2.144 In-Reply-To: <20000710013250.P29590@lyra.org> References: <200007091310.GAA27888@slayer.i.sourceforge.net> <20000710013250.P29590@lyra.org> Message-ID: <14698.15020.771347.741561@cj42289-a.reston1.va.home.com> Greg Stein writes: > hmm. should that be PyLong_FromVoidPtr() ? It will return the appropriate > object type based on the size of a void*. Greg, I see that the PyLong_FromVoidPtr() isn't documented -- are you volunteering? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Mon Jul 10 23:12:31 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 17:12:31 -0400 (EDT) Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length Message-ID: <14698.15423.878220.203259@bitdiddle.concentric.net> Tuple, List, String, and Dict have a PyXXX_Size method. The abstract object interface uses PySequence_Length. This is inconsistent and hard to remember. Can we add PySequence_Size and mark Length as deprecated? Jeremy From gstein at lyra.org Mon Jul 10 23:16:38 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 14:16:38 -0700 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <200007101725.MAA01255@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 12:25:12PM -0500 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> Message-ID: <20000710141638.R29590@lyra.org> On Mon, Jul 10, 2000 at 12:25:12PM -0500, Guido van Rossum wrote: > > I didn't bother to check, but does the embed Makefile include python's > > Makefile* stuff from $prefix/config ? Does it contain -export-dynamic ? If > > so, very pecurliar... ;-P > > Makefile includes are notoriously unportable, aren't they? The > embed/Makefile is a lame excuse for a Makefile -- it has XXX comments > all over the place telling you to edit things to match the Python main > Makefile... :-( My fault -- feel free to fix! We're using includes in the Apache 2.0 makefiles. I'm not sure whether this is going to make Apache 2.0 less portable or not. There haven't been any issues yet, though. (I think the makefile organization came from PHP; assuming that is as portable as Apache 1.3, then makefile includes are pretty darn portable) IMO, I say "start using makefile includes" and see who screams. VPATH is not portable, though. Cheers, -g -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Mon Jul 10 23:22:22 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 23:22:22 +0200 Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length References: <14698.15423.878220.203259@bitdiddle.concentric.net> Message-ID: <025001bfeab4$f07251e0$f2a6b5d4@hagrid> jeremy wrote: > Tuple, List, String, and Dict have a PyXXX_Size method. The abstract > object interface uses PySequence_Length. This is inconsistent and > hard to remember. Can we add PySequence_Size and mark Length as > deprecated? don't forget PyObject_Length and PyMapping_Length... From fdrake at beopen.com Mon Jul 10 23:20:04 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:20:04 -0400 (EDT) Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <20000710023523.Y29590@lyra.org> References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> <20000710023523.Y29590@lyra.org> Message-ID: <14698.15876.760261.661549@cj42289-a.reston1.va.home.com> Greg Stein writes: > bah. just file feature requests for them to use ViewCVS. cvsweb is a piece > of crap anyways :-) I've heard you say this before, but I've never had any problems with cvsweb. The display seems fine and I've never missed a feature. If you're being serious and not just plugging your own code, you need to be specific about the problems, and how ViewCVS is better. The problem with had with ViewCVS at python.org was the use of a single file for the script; parsing the whole thing for every run was just too slow. Part of that is the machine, part was configuration, and part was an overly high cost to the convenient installation. The last of those is in your court (possibly fixed by a more recent version; I don't know). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein at lyra.org Mon Jul 10 23:29:54 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 14:29:54 -0700 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <14698.15876.760261.661549@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 10, 2000 at 05:20:04PM -0400 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> <20000710023523.Y29590@lyra.org> <14698.15876.760261.661549@cj42289-a.reston1.va.home.com> Message-ID: <20000710142954.S29590@lyra.org> On Mon, Jul 10, 2000 at 05:20:04PM -0400, Fred L. Drake, Jr. wrote: > > Greg Stein writes: > > bah. just file feature requests for them to use ViewCVS. cvsweb is a piece > > of crap anyways :-) > > I've heard you say this before, but I've never had any problems with > cvsweb. The display seems fine and I've never missed a feature. If > you're being serious and not just plugging your own code, you need to > be specific about the problems, and how ViewCVS is better. From fdrake at beopen.com Mon Jul 10 23:29:00 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:29:00 -0400 (EDT) Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <39699401.790447E8@lemburg.com> References: <20000709215057.95047E2673@oratrix.oratrix.nl> <39699401.790447E8@lemburg.com> Message-ID: <14698.16412.396383.814694@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > There are lots of comments about it in site.py. > sys.setdefaultencoding() is meant to be used *only* in site.py-- > that's why it gets removed after having made the final decision The fact that it gets removed and is only provided as a hook for site.py needs to be documented in comments in sysmodule.c. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From effbot at telia.com Mon Jul 10 23:34:41 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 10 Jul 2000 23:34:41 +0200 Subject: [Python-Dev] Sourceforge Interface Concerns References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com><20000710023523.Y29590@lyra.org> <14698.15876.760261.661549@cj42289-a.reston1.va.home.com> Message-ID: <027801bfeab6$aa6115e0$f2a6b5d4@hagrid> fred drake: > I've heard you say this before, but I've never had any problems with > cvsweb. The display seems fine and I've never missed a feature. If > you're being serious and not just plugging your own code, you need to > be specific about the problems, and how ViewCVS is better. it works with MSIE5, for a start. and it's written by greg, in python. that's all I need to know ;-) the IE problem could be a configuration problem, of course. unless tim beats me to it, I'll submit a support request some day... From fdrake at beopen.com Mon Jul 10 23:34:04 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 17:34:04 -0400 (EDT) Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <20000710100837.6232337186D@snelboot.oratrix.nl> References: <20000710100837.6232337186D@snelboot.oratrix.nl> Message-ID: <14698.16716.343786.196699@cj42289-a.reston1.va.home.com> Jack Jansen writes: > pretty abysmal commercial ssh which could possibly be beaten into > forwarding connections, but it's expensive (and it doesn't work:-). And port-forwarding isn't likely to help, either. ;( The remote CVS protocol can be used directly over a socket, but the standard CVS client isn't written to work that way with authentication. It really wants to talk to another process via a pipe (such as rsh or ssh); I have no idea how feasible this is on the Mac (because of my ignorance, not because I don't think the Mac can do it). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas at xs4all.net Mon Jul 10 23:34:16 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Jul 2000 23:34:16 +0200 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <027801bfeab6$aa6115e0$f2a6b5d4@hagrid>; from effbot@telia.com on Mon, Jul 10, 2000 at 11:34:41PM +0200 References: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com><20000710023523.Y29590@lyra.org> <14698.15876.760261.661549@cj42289-a.reston1.va.home.com> <027801bfeab6$aa6115e0$f2a6b5d4@hagrid> Message-ID: <20000710233416.S26534@xs4all.nl> On Mon, Jul 10, 2000 at 11:34:41PM +0200, Fredrik Lundh wrote: > the IE problem could be a configuration problem, of course. unless > tim beats me to it, I'll submit a support request some day... I seriously doubt it, unless cvsweb has an option 'break IE5'. (Or 'unbreak IE5', if you so wish ;) The symptoms Tim described exactly match one of the known bugs in IE. It might be fixed in a newer version of cvsweb, of course. If anyone is going to submit a support request, feel free to pass them my email for information on that bug ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Mon Jul 10 14:34:33 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 10 Jul 2000 07:34:33 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000709233525.E26534@xs4all.nl> References: <14691.49563.78765.683762@beluga.mojam.com> <002f01bfe6d8$8d821460$f2a6b5d4@hagrid> <14695.840.448508.397722@beluga.mojam.com> <20000709233525.E26534@xs4all.nl> Message-ID: <14697.49881.701839.36716@beluga.mojam.com> Thomas> I have a couple of questions regarding this patch, if you don't Thomas> mind.... Thomas, I don't mind at all. I will remind folks that I am more the messenger than the messiah on this one, however. Greg Ewing (greg at cosc.canterbury.ac.nz) is the author of the change, so will be much better equipped than me to reply to your comments. I'm more a fan of the construct who happened to be in the right place at the right time. All I did was update Greg's patch to work with 1.5.2+ (which became 1.6alpha, which became 2.0beta). Thomas> For one, the Grammar for list comprehensions: Thomas> '[' [testlist [list_iter]] ']' Thomas> Should that really be 'testlist'? Thomas> [1,2,3,4,5] Thomas> is a list of 5 elements, but Thomas> [1,2,3,4,5 if 1] Thomas> is a list of one element, which is a 5-element tuple. I'll take a look at it. I'm not much of a parser person and my reading of the grammar is hampered by the fact that Grammar/Grammar and the grammar in the language reference manual no longer mesh very well. (Is that something that can be remedied?) I notice that in the comment at the top of com_list_comprehension Greg said: atom: '[' test list_iter ']' which suggests that you are onto something and that the 'testlist' variant is either a typo or a mistake that wasn't corrected in a later version of Greg's thinking ... Thomas> I'd say the Grammar would be more like this: Thomas> atom: '(' [testlist] ')' | '[' [listmaker] ']' | '{' [dictmaker] '}' | '' testlist '' | NAME | NUMBER | STRING+ Thomas> listmaker: test ( list_iter | (',' test)* [',']) Thomas> list_iter: list_for | list_if Thomas> list_for: 'for' exprlist 'in' testlist [list_iter] Thomas> list_if: 'if' test [list_iter] Thomas> And by coincidence this is also fits very nicely with what the Thomas> 'range-literal' patch does ;-) If we're going to have both we should probably have them work together, I agree. Thomas> Another issue is the code- and logic-duplication of the patch to Thomas> compile.c: it looks like a large part was just copied from Thomas> com_for_node, and the block-stuff commented out. Why is it Thomas> commented out, by the way ? Don't exceptions or something need Thomas> the block setup ? If the block-setup was kept in, it might be Thomas> easier to split the com_for_node into a function that compiles Thomas> the header, and one that compiles the suite, and make Thomas> com_list_for compile its own 'suite'. I'm hoping that's Thomas> possible, because it would keep the code a lot cleaner, and it Thomas> would make it easier for me to implement 'for i in x;j in y' and Thomas> have it work for list comprehensions too ;-) Come up with an alternate patch that does what you want. I think very few people have actually looked at Greg's patch closely and that his original patch was more a proof of concept than a ready-for-primetime chunk of code. Thomas> Also, the patch creates a list, stores it locally, and calls Thomas> append() to it inside the inner loop. Isn't it possible for the Thomas> patch to build the list on the stack, pushing individual Thomas> elements on the stack and calling BUILD_LIST at the end ? The Thomas> for loops counts the number of loops anyway ;) and it would get Thomas> rid of the fairly ugly tmpname thing altogether, I Thomas> think. However, the logic of when to ROT_THREE and ROT_TWO and Thomas> what not might run away from under us ;-P (But I'm facing that Thomas> anyway, with the parallel-forloop) Dunno. Thomas> Alternatively, it would be nice to store the lists' append() in Thomas> a local vrbl, to reduce the number of lookups ;-P Oh, and Thomas> lastly, the patch is just screaming for a re-indent all over, Thomas> and of some wel-placed comments... some of it was quite Thomas> difficult to follow, compared to the rest of the code. Yes, it does need to be reindented. Greg, can you give us some feedback on Thomas's comments when you get a chance? -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From gstein at lyra.org Tue Jul 11 00:11:07 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 15:11:07 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101926.OAA02072@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 02:26:25PM -0500 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> <200007101926.OAA02072@cj20424-a.reston1.va.home.com> Message-ID: <20000710151106.U29590@lyra.org> On Mon, Jul 10, 2000 at 02:26:25PM -0500, Guido van Rossum wrote: > > How do I do that in CVS-land? > > cvs admin -o I don't think the use of "cvs admin" should ever be encouraged. > Or you could retrieve the previous version and check it in on top, > with a comment such as "eating my words". :-) This is usually best, and it tracks what is actually occurring. Note that Eric's use of "cvs admin" did not generate a checkin email. Only by going and looking at the file, did I see that he has actually reverted the change. Committing over the top would generate a checkin message, so people can track the state of things. >... > > Also BTW, my access mechanics are a Python script called `forgetool' > > that automates away a bunch of CVS housekeeping -- setting CVSROOT > > properly on a per-project basis is one of the things it does. I'll > > write some docs and release it shortly. > > I thought that you almost never have to set the CVSROOT variable once > you've established your project work tree -- it's all stored in > CVS/Root anyway. I believe CVSROOT is only used when you do a "cvs > checkout" and that doesn't happen very often... This is correct. CVSROOT never needs to be set or to be changed once you have a working directory. In fact, with Python, I usually do the following: $ cvs ... co python $ mv python x $ mv x/dist/src python $ rm -r x The extra "dist/src" in the local filesystem is just annoying :-) Point is: CVS knows that my new python/ directory actually corresponds to python/dist/src/ in the CVS repository because of the CVS/* files. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jul 11 00:16:41 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 15:16:41 -0700 Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <14698.16412.396383.814694@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Jul 10, 2000 at 05:29:00PM -0400 References: <20000709215057.95047E2673@oratrix.oratrix.nl> <39699401.790447E8@lemburg.com> <14698.16412.396383.814694@cj42289-a.reston1.va.home.com> Message-ID: <20000710151641.V29590@lyra.org> On Mon, Jul 10, 2000 at 05:29:00PM -0400, Fred L. Drake, Jr. wrote: > > M.-A. Lemburg writes: > > There are lots of comments about it in site.py. > > sys.setdefaultencoding() is meant to be used *only* in site.py-- > > that's why it gets removed after having made the final decision > > The fact that it gets removed and is only provided as a hook for > site.py needs to be documented in comments in sysmodule.c. Um. I thought the current consensus was to remove setdefaultencoding() altogether and just stick with an ASCII default encoding. I don't think we should let people change the default if that is going to break other parts of the Python interpreter. It could also seriously mess up code that is expecting that hard-coded ASCII default. Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw at beopen.com Tue Jul 11 00:20:54 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 10 Jul 2000 18:20:54 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection (I think) Message-ID: <14698.19526.232315.802728@anthem.concentric.net> While running through the test suite with Purify, I ran across the following script which core dumps the current CVS snapshot. You need to have gc enabled to trigger this. I'm running on Solaris 2.6, using gcc 2.8.1. It also cores my Linux build of Python from CVS using egcs-2.91.66. -Barry -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: core.py URL: -------------- next part -------------- -------------------- snip snip -------------------- Program received signal SIGSEGV, Segmentation fault. 0x18659c in gc_list_remove (node=0x48028c) at ./gcmodule.c:86 86 node->gc_prev->gc_next = node->gc_next; (gdb) where #0 0x18659c in gc_list_remove (node=0x48028c) at ./gcmodule.c:86 #1 0x186fb4 in visit_reachable (op=0x480298, roots=0xefffe648) at ./gcmodule.c:194 #2 0x1227b0 in list_traverse (o=0x494ae4, visit=0x186f08 , arg=0xefffe648) at listobject.c:1339 #3 0x18710c in move_root_reachable (reachable=0xefffe648) at ./gcmodule.c:212 #4 0x187dc8 in collect (young=0x4026c0, old=0x4026cc) at ./gcmodule.c:390 #5 0x1883fc in collect_generations () at ./gcmodule.c:481 #6 0x1884e4 in _PyGC_Insert (op=0x4d48fc) at ./gcmodule.c:500 #7 0x147220 in PyTuple_New (size=1) at tupleobject.c:96 #8 0x148348 in tupleslice (a=0x4e40d4, ilow=1, ihigh=2) at tupleobject.c:294 #9 0xfbc80 in PySequence_GetSlice (s=0x4e40d4, i1=1, i2=2) at abstract.c:897 #10 0x8a100 in Exception__init__ (self=0x4d736c, args=0x4e40d4) at exceptions.c:217 #11 0xb0754 in call_builtin (func=0x445ce0, arg=0x4e40d4, kw=0x0) at ceval.c:2404 #12 0xb03fc in PyEval_CallObjectWithKeywords (func=0x445ce0, arg=0x4e40d4, kw=0x0) at ceval.c:2369 #13 0xb0e9c in call_function (func=0x445ce0, arg=0x4e40d4, kw=0x0) at ceval.c:2484 #14 0xb03bc in PyEval_CallObjectWithKeywords (func=0x44ad34, arg=0x4e46bc, kw=0x0) at ceval.c:2367 #15 0x101988 in PyInstance_New (class=0x44f8ec, arg=0x4e46bc, kw=0x0) at classobject.c:472 #16 0xb07b8 in call_builtin (func=0x44f8ec, arg=0x4e46bc, kw=0x0) at ceval.c:2407 #17 0xb03fc in PyEval_CallObjectWithKeywords (func=0x44f8ec, arg=0x4e46bc, kw=0x0) at ceval.c:2369 #18 0xc6c30 in PyErr_NormalizeException (exc=0xefffedf8, val=0xefffedfc, tb=0xefffee00) at errors.c:190 #19 0xaba18 in eval_code2 (co=0x4b5c08, globals=0x4a5b94, locals=0x0, args=0x462a1c, argcount=2, kws=0x462a24, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1846 #20 0xa7f3c in eval_code2 (co=0x4b7eb0, globals=0x466824, locals=0x0, args=0x4e4b78, argcount=4, kws=0x4e4b88, kwcount=0, defs=0x4dcec8, defcount=1, owner=0x0) at ceval.c:1587 #21 0xa7f3c in eval_code2 (co=0x47d1f8, globals=0x466824, locals=0x0, args=0x4bac00, argcount=4, kws=0x0, kwcount=0, defs=0x4dcd18, defcount=1, owner=0x0) at ceval.c:1587 #22 0xb13c0 in call_function (func=0x4dcc2c, arg=0x4babf4, kw=0x0) at ceval.c:2529 #23 0xb03bc in PyEval_CallObjectWithKeywords (func=0x4dcc2c, arg=0x4babf4, kw=0x0) at ceval.c:2367 #24 0xfe284 in PyObject_CallObject (o=0x4dcc2c, a=0x4babf4) at abstract.c:1360 #25 0x1c42f4 in call (function=0x2cdbe0 "_sub", args=0x4babf4) at ./_sre.c:1458 #26 0x1c4514 in pattern_sub (self=0x4ea2a0, args=0x4e605c) at ./_sre.c:1474 #27 0xb0754 in call_builtin (func=0x4d42b0, arg=0x4e605c, kw=0x0) at ceval.c:2404 #28 0xb03fc in PyEval_CallObjectWithKeywords (func=0x4d42b0, arg=0x4e605c, kw=0x0) at ceval.c:2369 #29 0xa90f0 in eval_code2 (co=0x479378, globals=0x466824, locals=0x0, args=0x45d600, argcount=3, kws=0x45d60c, kwcount=0, defs=0x48e598, defcount=1, owner=0x0) at ceval.c:1688 #30 0xa7f3c in eval_code2 (co=0x47a6e8, globals=0x45b14c, locals=0x45b14c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1587 #31 0x8e71c in PyEval_EvalCode (co=0x47a6e8, globals=0x45b14c, locals=0x45b14c) at ceval.c:298 #32 0xe6f9c in run_node (n=0x4644f8, filename=0xeffffb26 "/tmp/core.py", globals=0x45b14c, locals=0x45b14c) at pythonrun.c:895 #33 0xe6eac in run_err_node (n=0x4644f8, filename=0xeffffb26 "/tmp/core.py", globals=0x45b14c, locals=0x45b14c) at pythonrun.c:880 #34 0xe6df0 in PyRun_File (fp=0x42e728, filename=0xeffffb26 "/tmp/core.py", start=257, globals=0x45b14c, locals=0x45b14c) at pythonrun.c:868 #35 0xe5218 in PyRun_SimpleFile (fp=0x42e728, filename=0xeffffb26 "/tmp/core.py") at pythonrun.c:578 #36 0xe4804 in PyRun_AnyFile (fp=0x42e728, filename=0xeffffb26 "/tmp/core.py") at pythonrun.c:459 #37 0x85584 in Py_Main (argc=3, argv=0xeffff9fc) at main.c:271 #38 0x84848 in main (argc=3, argv=0xeffff9fc) at python.c:10 From bwarsaw at beopen.com Tue Jul 11 00:24:58 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 10 Jul 2000 18:24:58 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> <200007101926.OAA02072@cj20424-a.reston1.va.home.com> <20000710151106.U29590@lyra.org> Message-ID: <14698.19770.699007.508033@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: | $ cvs ... co python | $ mv python x | $ mv x/dist/src python | $ rm -r x GS> The extra "dist/src" in the local filesystem is just annoying GS> :-) GS> Point is: CVS knows that my new python/ directory actually GS> corresponds to python/dist/src/ in the CVS repository because GS> of the CVS/* files. cvs ... co -d python python/dist/src will do the same thing, much more easily! -Barry From gstein at lyra.org Tue Jul 11 00:33:14 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 10 Jul 2000 15:33:14 -0700 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162855.A9245@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 10, 2000 at 04:28:55PM -0400 References: <20000710162855.A9245@thyrsus.com> Message-ID: <20000710153314.W29590@lyra.org> On Mon, Jul 10, 2000 at 04:28:55PM -0400, Eric S. Raymond wrote: > Earlier today, I committed a patch to ConfigParser that adds three new > methods to the class. Here is the documentation: Excellent! I have a few subclasses of ConfigParser that do these things, too. Glad to see it in the standard distro :-) >... > These new methods are additions to the class, and do not change any > existing code. Nevertheless Guido sent me a heads-up that I had > committed a marginal violation of Python etiquette by changing the > module without the explicit sign-off of the maintainers. API changes probably ought to be discussed on this list (which includes the maintainers of any code). Basic point: the "maintainer(s)" is usually quite unclear since we avoid attribution within the source if at all possible. Posing the suggested change here allows for changing maintainers (note that Fred has done a tone of work on ConfigParser, and I've submitted a few changes myself, too!), and it allows for broader input. However, bug fixes and minor reworking should probably be allowed regardless of the maintainer. I'd hate to end up at a point where the Python interpreter is partitioned into a bunch of little fiefdoms, where you must pay a toll to enter. >... > Two more things remain to be done: > > First, for completeness there ought to be remove_section and remove_option > methods (though forgetool does not yet use them). I have documented these > as follows: +1 >... > Second, the new methods expose a bug in the existing code. Because > the case of section and option names is folded on input, the new > write() method emits edited configurations with their case smashed. I > think the existing code should be fixed to preserve case, with > string.lower() being applied at key lookup time. +1 The string.lower() at lookup time shifts the performance response, but I don't really see config state as performance-intensive. Cheers, -g -- Greg Stein, http://www.lyra.org/ From m.favas at per.dem.csiro.au Tue Jul 11 00:44:20 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Tue, 11 Jul 2000 06:44:20 +0800 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? Message-ID: <396A51C4.894E1550@per.dem.csiro.au> No problems (apart from the usual test failures) with the CVS from 10 July, but with CVS from 11 July I get core dumps at random points in "make test" which seem to point to a problem with the GC code. Sample dbx output: (Platform is DEC (Compaq) Alpha, Compaq C T6.3-125 (dtk) on Digital UNIX V4.0F (Rev. 1229)) dbx version 3.11.10 Type 'help' for help. Core file created by program "python" thread 0xb signal Segmentation fault at >*[__nxm_thread_kill, 0x3ff805c7ca8] ret r31, (r26), 1 (dbx) where > 0 __nxm_thread_kill(0x3ffc01b3c10, 0x1200f47dc, 0x0, 0x11fffeed0, 0x3ff8059c724) [0x3ff805c7ca8] 1 pthread_kill(0x1200ea970, 0x1, 0x0, 0x11fffeee0, 0x3ffc01b36c0) [0x3ff805ad6f4] 2 (unknown)() [0x3ff8059712c] 3 (unknown)() [0x3ff807e370c] 4 exc_unwind(0x11fffaf28, 0xabadabad00beed00, 0x3ff80592b90, 0x11fffb1c8, 0x3ff807e3acc) [0x3ff807e380c] 5 exc_raise_signal_exception(0x86, 0x0, 0x120159490, 0x1, 0x1) [0x3ff807e3ac8] 6 (unknown)() [0x3ff805af254] 7 (unknown)() [0x12015948c] 8 (unknown)() [0x12014f36c] 9 (unknown)() [0x120159844] 10 _PyGC_Insert(0x7f, 0x6f, 0x120111690, 0x2, 0x140155e20) [0x120159d04] This _PyGC_Insert always appears here in the trace - sometimes called from PyTuple_New, sometimes from PyMethod_New... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From petersc at stud.ntnu.no Tue Jul 11 03:05:10 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Tue, 11 Jul 2000 01:05:10 +0000 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? References: <396A51C4.894E1550@per.dem.csiro.au> Message-ID: <396A72C6.6810C95E@stud.ntnu.no> Mark Favas wrote: > > No problems (apart from the usual test failures) with the CVS from 10 > July, but with CVS from 11 July I get core dumps at random points in > "make test" which seem to point to a problem with the GC code. Sample > dbx output: I wouldn't bet my life on it, but I don't think the GC code is responsible. The only changes checked in during the last days were the "long n = 0;" initialization and my ANSI-fication (which I just reviewed and which should be harmless). don't-have-a-clue-though-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From tim_one at email.msn.com Tue Jul 11 01:10:19 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 19:10:19 -0400 Subject: [Python-Dev] Messy gc death Message-ID: With the latest CVS (as of 6:30pm EDT), the std test suite blows up under Windows release & debug builds, like so (this is debug): Adding parser accelerators ... Done. test_grammar test_opcodes test_operations test_builtin test_exceptions test_types test_MimeWriter test_al test test_al skipped -- an optional feature could not be imported test_array test_atexit with a memory error. However, test_atexit works fine in isolation, so this isn't a nice little local bug. The death is in this function from gcmodule.c: static int visit_decref(PyObject *op, void *data) { if (op && PyObject_IS_GC(op)) { ***********this line************** PyObject_AS_GC(op)->gc_refs--; } return 0; } data is NULL at this point, and op appears to be a legit memory address, but the fields in op make no sense: _ob_next is 0x24, _ob_prev is 1, and ob_type is the MS "landfill" value 0xfdfdfdfd (MS debug libraries set malloc'ed memory to that). Chasing the bogus ob_type address is the cause of the meltdown. Here's the traceback: visit_decref(_object * 0x0082ad60, void * 0x00000000) line 151 + 12 bytes list_traverse(PyListObject * 0x0082af7c, int (_object *, void *)* 0x1e14ee2d visit_decref(_object *, void *), void * 0x00000000) line 1339 + 11 bytes subtract_refs(_gc_head * 0x1e1dae18 generation0) line 167 + 17 bytes collect(_gc_head * 0x1e1dae18 generation0, _gc_head * 0x1e1dae28 generation1) line 383 + 9 bytes collect_generations() line 481 + 15 bytes _PyGC_Insert(_object * 0x0082ca6c) line 501 PyDict_New() line 111 + 9 bytes PyModule_New(char * 0x0063f160) line 29 + 5 bytes PyImport_AddModule(char * 0x0063f160) line 449 + 9 bytes PyImport_ExecCodeModuleEx(char * 0x0063f160, _object * 0x0082b4c0, char * 0x0063eea8) line 482 + 9 bytes load_source_module() line 758 + 17 bytes load_module(char * 0x0063f160, _iobuf * 0x1025a908, char * 0x0063f004, int 1) line 1240 + 17 bytes import_submodule(_object * 0x1e1e5bc0 __Py_NoneStruct, char * 0x0063f160, char * 0x0063f160) line 1793 + 33 bytes load_next(_object * 0x1e1e5bc0 __Py_NoneStruct, _object * 0x1e1e5bc0 __Py_NoneStruct, char * * 0x0063f274, char * 0x0063f160, int * 0x0063f15c) line 1641 + 17 bytes import_module_ex() line 1483 + 35 bytes PyImport_ImportModuleEx(char * 0x007d0eec, _object * 0x007e541c, _object * 0x007e541c, _object * 0x1e1e5bc0 __Py_NoneStruct) line 1527 + 21 bytes builtin___import__() line 47 + 21 bytes call_builtin(_object * 0x00761fd0, _object * 0x008033ac, _object * 0x00000000) line 2404 + 11 bytes PyEval_CallObjectWithKeywords(_object * 0x00761fd0, _object * 0x008033ac, _object * 0x00000000) line 2369 + 17 bytes eval_code2(PyCodeObject * 0x007e34f0, _object * 0x007e541c, _object * 0x007e541c, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * 0x00000000) line 1425 + 15 bytes PyEval_EvalCode(PyCodeObject * 0x007e34f0, _object * 0x007e541c, _object * 0x007e541c) line 303 + 31 bytes PyImport_ExecCodeModuleEx(char * 0x0063f75c, _object * 0x007e34f0, char * 0x0063f4a4) line 506 + 17 bytes load_source_module() line 758 + 17 bytes load_module(char * 0x0063f75c, _iobuf * 0x1025a8e8, char * 0x0063f600, int 1) line 1240 + 17 bytes import_submodule(_object * 0x1e1e5bc0 __Py_NoneStruct, char * 0x0063f75c, char * 0x0063f75c) line 1793 + 33 bytes load_next(_object * 0x1e1e5bc0 __Py_NoneStruct, _object * 0x1e1e5bc0 __Py_NoneStruct, char * * 0x0063f870, char * 0x0063f75c, int * 0x0063f758) line 1641 + 17 bytes import_module_ex() line 1483 + 35 bytes PyImport_ImportModuleEx(char * 0x007da7dc, _object * 0x0076edbc, _object * 0x0079f59c, _object * 0x0079942c) line 1527 + 21 bytes builtin___import__() line 47 + 21 bytes call_builtin(_object * 0x00761fd0, _object * 0x007e987c, _object * 0x00000000) line 2404 + 11 bytes PyEval_CallObjectWithKeywords(_object * 0x00761fd0, _object * 0x007e987c, _object * 0x00000000) line 2369 + 17 bytes eval_code2(PyCodeObject * 0x00854060, _object * 0x0076edbc, _object * 0x00000000, _object * * 0x0084cee4, int 4, _object * * 0x0084cef4, int 0, _object * * 0x0084a3e0, int 1, _object * 0x00000000) line 1690 + 26 bytes eval_code2(PyCodeObject * 0x00854fb0, _object * 0x0076edbc, _object * 0x00000000, _object * * 0x00771e6c, int 0, _object * * 0x00771e6c, int 0, _object * * 0x008493d0, int 8, _object * 0x00000000) line 1590 + 88 bytes eval_code2(PyCodeObject * 0x00854990, _object * 0x0076edbc, _object * 0x0076edbc, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * 0x00000000) line 1590 + 88 bytes PyEval_EvalCode(PyCodeObject * 0x00854990, _object * 0x0076edbc, _object * 0x0076edbc) line 303 + 31 bytes run_node(_node * 0x007d25d0, char * 0x00760dd9, _object * 0x0076edbc, _object * 0x0076edbc) line 895 + 17 bytes run_err_node(_node * 0x007d25d0, char * 0x00760dd9, _object * 0x0076edbc, _object * 0x0076edbc) line 880 + 21 bytes PyRun_File(_iobuf * 0x1025a888, char * 0x00760dd9, int 257, _object * 0x0076edbc, _object * 0x0076edbc) line 869 + 38 bytes PyRun_SimpleFile(_iobuf * 0x1025a888, char * 0x00760dd9) line 578 + 26 bytes PyRun_AnyFile(_iobuf * 0x1025a888, char * 0x00760dd9) line 459 + 13 bytes Py_Main(int 2, char * * 0x00760da0) line 273 + 34 bytes main(int 2, char * * 0x00760da0) line 10 + 13 bytes mainCRTStartup() line 338 + 17 bytes No wonder Python needs Stackless to run on a Palm . anyone-got-a-clue?-ly y'rs - tim From m.favas at per.dem.csiro.au Tue Jul 11 02:07:09 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Tue, 11 Jul 2000 08:07:09 +0800 Subject: [Python-Dev] Messy gc death (Was: Core dump in garbage collection: PyGC_Insert???) Message-ID: <396A652D.254B7FE8@per.dem.csiro.au> Throwing a -g flag at the compilation and poking at the resultant core, I get two different traces, depending on where it crashed during "make test". The first is the the same trace as Tim, viz: Core file created by program "python" thread 0x11 signal Segmentation fault at >*[__nxm_thread_kill, 0x3ff805c7ca8] ret r31, (r26), 1 (dbx) where > 0 __nxm_thread_kill(0x3ffc01b3c10, 0x1200f4ccc, 0x0, 0x11fffeed0, 0x3ff8059c724) [0x3ff805c7ca8] 1 pthread_kill(0x1200ea6b0, 0x1, 0x0, 0x11fffeee0, 0x3ffc01b36c0) [0x3ff805ad6f4] 2 (unknown)() [0x3ff8059712c] 3 (unknown)() [0x3ff807e370c] 4 exc_unwind(0x11fffc568, 0xabadabad00beed00, 0x4f, 0x11fffc808, 0x3ff807e3acc) [0x3ff807e380c] 5 exc_raise_signal_exception(0x86, 0x0, 0x12015bdf0, 0x1, 0x1) [0x3ff807e3ac8] 6 (unknown)() [0x3ff805af254] 7 visit_decref(op = 0x1405f0d40, data = (nil)) ["./gcmodule.c":151, 0x12015bdec] 8 list_traverse(o = 0x1405e0818, visit = 0x12015bde0, arg = (nil)) ["listobject.c":1339, 0x120151c10] 9 subtract_refs(containers = 0x140019b30) ["./gcmodule.c":165, 0x12015be54] 10 collect(young = 0x140019b30, old = 0x140019b48) ["./gcmodule.c":383, 0x12015c53c] 11 collect_generations() ["./gcmodule.c":481, 0x12015c84c] 12 _PyGC_Insert(op = 0x140430158) ["./gcmodule.c":500, 0x12015c8c0] and the second is: Core file created by program "python" thread 0xb signal Segmentation fault at >*[__nxm_thread_kill, 0x3ff805c7ca8] ret r31, (r26), 1 (dbx) where > 0 __nxm_thread_kill(0x3ffc01b3c10, 0x1200f4ccc, 0x0, 0x11fffeed0, 0x3ff8059c724) [0x3ff805c7ca8] 1 pthread_kill(0x1200ea6b0, 0x1, 0x0, 0x11fffeee0, 0x3ffc01b36c0) [0x3ff805ad6f4] 2 (unknown)() [0x3ff8059712c] 3 (unknown)() [0x3ff807e370c] 4 exc_unwind(0x11fffbea8, 0xabadabad00beed00, 0x3ff80592b90, 0x11fffc148, 0x3ff807e3acc) [0x3ff807e380c] 5 exc_raise_signal_exception(0x86, 0x0, 0x12015bce0, 0x1, 0x1) [0x3ff807e3ac8] 6 (unknown)() [0x3ff805af254] 7 gc_list_remove(node = 0x140472728) ["./gcmodule.c":86, 0x12015bcdc] 8 visit_reachable(op = 0x140472740, roots = 0x11fffcaa0) ["./gcmodule.c":194, 0x12015bf04] 9 list_traverse(o = 0x140447518, visit = 0x12015bed0, arg = 0x11fffcaa0) ["listobject.c":1339, 0x120151c10] 10 move_root_reachable(reachable = 0x11fffcaa0) ["./gcmodule.c":212, 0x12015bf6c] 11 collect(young = 0x140019b60, old = 0x140019b60) ["./gcmodule.c":390, 0x12015c558] 12 collect_generations() ["./gcmodule.c":466, 0x12015c76c] 13 _PyGC_Insert(op = 0x140449b98) ["./gcmodule.c":500, 0x12015c8c0] -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From esr at thyrsus.com Tue Jul 11 02:34:35 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 20:34:35 -0400 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710153314.W29590@lyra.org>; from gstein@lyra.org on Mon, Jul 10, 2000 at 03:33:14PM -0700 References: <20000710162855.A9245@thyrsus.com> <20000710153314.W29590@lyra.org> Message-ID: <20000710203435.A9793@thyrsus.com> Greg Stein : > The string.lower() at lookup time shifts the performance response, but I > don't really see config state as performance-intensive. That's my thinking as well. -- Eric S. Raymond The common argument that crime is caused by poverty is a kind of slander on the poor. -- H. L. Mencken From greg at cosc.canterbury.ac.nz Tue Jul 11 02:31:55 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Tue, 11 Jul 2000 12:31:55 +1200 (NZST) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14697.49881.701839.36716@beluga.mojam.com> Message-ID: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> Thomas> '[' [testlist [list_iter]] ']' Thomas> Should that really be 'testlist'? I can't remember my exact thinking at the time, but probably I decided that, for consistency with the rest of the language, the most general form of expression possible, without making the grammar ambiguous, should be allowed. Personally, I don't mind very much either way, but if it were changed I expect you'd get complaints that things like [x,y for x in (1,2,3) for y in (4,5,6)] didn't do what the programmer expected. Thomas> And by coincidence this is also fits very nicely with what the Thomas> 'range-literal' patch does ;-) I'm not familiar with that one, so I can't comment. Thomas> it looks like a large part was just copied from Thomas> com_for_node, and the block-stuff commented out. As Skip said, it was a proof-of-concept, and I wanted to get it working with as few changes to existing code as possible, both because I wasn't sure I understood it well enough to mess with it, and to minimise the chance of conflict with other patches. Thomas> Why is it Thomas> commented out, by the way ? Don't exceptions or something need Thomas> the block setup ? If the block-setup was kept in, it might be The block setup is used to handle breaking out of the for loop. Since it's impossible to put a 'break' inside a list constructor, the block setup is not needed -- or at least that's what I decided at the time. I don't *think* that leaving it out will upset the exception mechanism, but I'm not absolutely sure. Can anyone who knows more about how it works comment? In any case, I agree that the two for-loop compiling procedures could and should be refactored somehow. Thomas> Isn't it possible for the Thomas> patch to build the list on the stack, pushing individual Thomas> elements on the stack and calling BUILD_LIST at the end ? Unfortunately, no. The compiler needs to know the maximum amount of stack used by the procedure, and in the case of a list comprehension, the list size is not known until run time. However, things could still be improved greatly. My recommendation would be to define a new opcode such as LIST_APPEND which would take an item off the top of the stack, reach down stack items and append it to the list found there. That would get rid of the temporary variable as well. Thomas> lastly, the patch is just screaming for a re-indent all over, I sort of hoped that, with it becoming an official feature, someone would go over the code manually afterwards, rather than just applying the patch and leaving it at that. If it's deemed that "someone" should be me, let me know and I'll see what I can do. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From fdrake at beopen.com Tue Jul 11 02:47:58 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 20:47:58 -0400 (EDT) Subject: [Python-Dev] Venting some steam on current developments In-Reply-To: <20000710151641.V29590@lyra.org> References: <20000709215057.95047E2673@oratrix.oratrix.nl> <39699401.790447E8@lemburg.com> <14698.16412.396383.814694@cj42289-a.reston1.va.home.com> <20000710151641.V29590@lyra.org> Message-ID: <14698.28350.493348.220791@cj42289-a.reston1.va.home.com> Greg Stein writes: > Um. I thought the current consensus was to remove setdefaultencoding() > altogether and just stick with an ASCII default encoding. I'm most happy with this. My comment was really that it did need a comment there, even in it's temporary existence. But ripping the whole mess out is definately the best solution. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Jul 11 02:50:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 10 Jul 2000 20:50:40 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <20000710151106.U29590@lyra.org> References: <200007101500.IAA13372@slayer.i.sourceforge.net> <200007101622.LAA01140@cj20424-a.reston1.va.home.com> <20000710123550.A8478@thyrsus.com> <200007101838.NAA01448@cj20424-a.reston1.va.home.com> <20000710142519.A8794@thyrsus.com> <200007101926.OAA02072@cj20424-a.reston1.va.home.com> <20000710151106.U29590@lyra.org> Message-ID: <14698.28512.30573.289668@cj42289-a.reston1.va.home.com> Greg Stein writes: > $ cvs ... co python > $ mv python x > $ mv x/dist/src python > $ rm -r x Try: cvs ... co -d python python/dist/src > The extra "dist/src" in the local filesystem is just annoying :-) Agreed! I've never used that form in my work area. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr at thyrsus.com Tue Jul 11 03:10:00 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 10 Jul 2000 21:10:00 -0400 Subject: [Python-Dev] Re: SourceForge In-Reply-To: <396A6F7D.66D5F085@valinux.com>; from dbressler@valinux.com on Mon, Jul 10, 2000 at 05:51:09PM -0700 References: <20000707133533.E17746@valinux.com> <20000707182448.A31259@thyrsus.com> <39667D29.1A4FB1BB@valinux.com> <20000709214138.I4566@thyrsus.com> <396A4CFC.CEE2419A@valinux.com> <20000710203719.B9793@thyrsus.com> <396A6F7D.66D5F085@valinux.com> Message-ID: <20000710211000.A10068@thyrsus.com> Dan Bressler : > I'm trying to sync schedules -- If we could set it for Tuesday evening, July > 18th, that would work best. OK. Python folks who will be at the Monterey conference; Dan Bressler, one of the managers of SourceForge, is amenable to an evening meeting with this gang on Tuesday the 18th. I gather Tim Purdue, currently the lead programmer on the project, will be there. The exact time is still to be worked out. Anybody got a proposal? -- Eric S. Raymond "I hold it, that a little rebellion, now and then, is a good thing, and as necessary in the political world as storms in the physical." -- Thomas Jefferson, Letter to James Madison, January 30, 1787 From nascheme at enme.ucalgary.ca Tue Jul 11 03:15:37 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Mon, 10 Jul 2000 19:15:37 -0600 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <396A72C6.6810C95E@stud.ntnu.no>; from Peter Schneider-Kamp on Tue, Jul 11, 2000 at 01:05:10AM +0000 References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> Message-ID: <20000710191537.A5853@keymaster.enme.ucalgary.ca> On Tue, Jul 11, 2000 at 01:05:10AM +0000, Peter Schneider-Kamp wrote: > I wouldn't bet my life on it, but I don't think the GC code is > responsible. Its hard to say. The GC code will probably pick up on a lot of problems because it touches many objects. On the other hand, it could be my bug. I'm prettly limited here as my computer is somewhere between Calgary and Reston as I type this. I will try to find the problem though. Neil From nascheme at enme.ucalgary.ca Tue Jul 11 03:28:33 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Mon, 10 Jul 2000 19:28:33 -0600 Subject: [Python-Dev] GC core dump caused by stringobject changes? Message-ID: <20000710192833.B5853@keymaster.enme.ucalgary.ca> These seem to be the changes that trigger the bug. My problem or someone elses? No time to look in detail right now. :( Neil diff -ru py-old/dist/src/Objects/stringobject.c py/dist/src/Objects/stringobject.c --- py-old/dist/src/Objects/stringobject.c Mon Jul 10 17:25:54 2000 +++ py/dist/src/Objects/stringobject.c Mon Jul 10 21:18:35 2000 @@ -744,106 +744,66 @@ int seqlen = 0; int sz = 100; int i, slen; - PyObject *seq; + PyObject *orig, *seq, *item; - if (!PyArg_ParseTuple(args, "O:join", &seq)) + if (!PyArg_ParseTuple(args, "O:join", &orig)) return NULL; - seqlen = PySequence_Length(seq); - if (seqlen < 0 && PyErr_Occurred()) + seq = PySequence_Fast(orig, ""); + if (seq == NULL) { + if (PyErr_ExceptionMatches(PyExc_TypeError)) + PyErr_Format(PyExc_TypeError, + "sequence expected, %.80s found", + orig->ob_type->tp_name); return NULL; + } + seqlen = PySequence_Length(seq); if (seqlen == 1) { - /* Optimization if there's only one item */ - PyObject *item = PySequence_GetItem(seq, 0); - if (item == NULL) - return NULL; - if (!PyString_Check(item) && - !PyUnicode_Check(item)) { - PyErr_SetString(PyExc_TypeError, - "first argument must be sequence of strings"); - Py_DECREF(item); - return NULL; - } + item = PySequence_Fast_GET_ITEM(seq, 0); + Py_INCREF(item); return item; } + if (!(res = PyString_FromStringAndSize((char*)NULL, sz))) return NULL; p = PyString_AsString(res); - /* optimize for lists. all others (tuples and arbitrary sequences) - * just use the abstract interface. - */ - if (PyList_Check(seq)) { - for (i = 0; i < seqlen; i++) { - PyObject *item = PyList_GET_ITEM(seq, i); - if (!PyString_Check(item)){ - if (PyUnicode_Check(item)) { - Py_DECREF(res); - return PyUnicode_Join( - (PyObject *)self, - seq); - } - PyErr_Format(PyExc_TypeError, - "sequence item %i not a string", - i); - goto finally; - } - slen = PyString_GET_SIZE(item); - while (reslen + slen + seplen >= sz) { - if (_PyString_Resize(&res, sz*2)) - goto finally; - sz *= 2; - p = PyString_AsString(res) + reslen; - } - if (i > 0) { - memcpy(p, sep, seplen); - p += seplen; - reslen += seplen; + for (i = 0; i < seqlen; i++) { + item = PySequence_Fast_GET_ITEM(seq, i); + if (!PyString_Check(item)){ + if (PyUnicode_Check(item)) { + Py_DECREF(res); + Py_DECREF(item); + return PyUnicode_Join((PyObject *)self, + seq); } - memcpy(p, PyString_AS_STRING(item), slen); - p += slen; - reslen += slen; + PyErr_Format(PyExc_TypeError, + "sequence item %i: expected string, %.80s found", + i, item->ob_type->tp_name); + Py_DECREF(item); + Py_DECREF(seq); + goto finally; } - } - else { - for (i = 0; i < seqlen; i++) { - PyObject *item = PySequence_GetItem(seq, i); - if (!item) - goto finally; - if (!PyString_Check(item)){ - if (PyUnicode_Check(item)) { - Py_DECREF(res); - Py_DECREF(item); - return PyUnicode_Join( - (PyObject *)self, - seq); - } + slen = PyString_GET_SIZE(item); + while (reslen + slen + seplen >= sz) { + if (_PyString_Resize(&res, sz*2)) { Py_DECREF(item); - PyErr_Format(PyExc_TypeError, - "sequence item %i not a string", - i); + Py_DECREF(seq); goto finally; } - slen = PyString_GET_SIZE(item); - while (reslen + slen + seplen >= sz) { - if (_PyString_Resize(&res, sz*2)) { - Py_DECREF(item); - goto finally; - } - sz *= 2; - p = PyString_AsString(res) + reslen; - } - if (i > 0) { - memcpy(p, sep, seplen); - p += seplen; - reslen += seplen; - } - memcpy(p, PyString_AS_STRING(item), slen); - Py_DECREF(item); - p += slen; - reslen += slen; + sz *= 2; + p = PyString_AsString(res) + reslen; + } + if (i > 0) { + memcpy(p, sep, seplen); + p += seplen; + reslen += seplen; } + memcpy(p, PyString_AS_STRING(item), slen); + Py_DECREF(item); + p += slen; + reslen += slen; } if (_PyString_Resize(&res, reslen)) goto finally; From tim_one at email.msn.com Tue Jul 11 03:47:12 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 21:47:12 -0400 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <20000710191537.A5853@keymaster.enme.ucalgary.ca> Message-ID: [Peter Schneider-Kamp] > I wouldn't bet my life on it, but I don't think the GC code is > responsible. [Neil Schemenauer] > Its hard to say. I'll second that . > The GC code will probably pick up on a lot of problems because it touches > many objects. On the other hand, it could be my bug. I'm prettly > limited here as my computer is somewhere between Calgary and > Reston as I type this. I will try to find the problem though. I also doubt it's gc's fault: the recent patches to the gc code were absolutely vanilla, this all worked fine (at least for me) yesterday, and it's failing for multiple people on multiple platforms today. (BTW, Barry, your core.py does not fail under my Windows build.) I haven't had more time tonight to look at it, though, and won't tomorrow either. "Somehow or other" the list of objects it's crawling over is totally hosed (length 3, first one is a legit string object, last two seemingly random trash). If I remembered how to do this with CVS, I'd just do a mindless binary search over the last day's patches, rebuilding until the problem goes away ... OK, if back out *only* Jeremy's patch to stringobject.c: http://www.python.org/pipermail/python-checkins/2000-July/006424.html all my Windows gc failures go away. I picked on that patch because it's the only non-trivial patch that's gone in recently to a popular part of the code. Jeremy, want to double-check your refcounts ? suggestive-but-not-yet-proven-ly y'rs - tim From tim_one at email.msn.com Tue Jul 11 04:00:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 22:00:47 -0400 Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <20000710191537.A5853@keymaster.enme.ucalgary.ca> Message-ID: [Peter Schneider-Kamp] > I wouldn't bet my life on it, but I don't think the GC code is > responsible. [Neil Schemenauer] > Its hard to say. I'll second that . > The GC code will probably pick up on a lot of problems because it touches > many objects. On the other hand, it could be my bug. I'm prettly > limited here as my computer is somewhere between Calgary and > Reston as I type this. I will try to find the problem though. I also doubt it's gc's fault: the recent patches to the gc code were absolutely vanilla, this all worked fine (at least for me) yesterday, and it's failing for multiple people on multiple platforms today. (BTW, Barry, your core.py does not fail under my Windows build.) I haven't had more time tonight to look at it, though, and won't tomorrow either. "Somehow or other" the list of objects it's crawling over is totally hosed (length 3, first one is a legit string object, last two seemingly random trash). If I remembered how to do this with CVS, I'd just do a mindless binary search over the last day's patches, rebuilding until the problem goes away ... OK, if I back out *only* Jeremy's very recent patch to stringobject.c: http://www.python.org/pipermail/python-checkins/2000-July/006424.html all my Windows gc failures go away. I picked on that patch because it's the only non-trivial patch that's gone in recently to a popular part of the code. Jeremy, want to double-check your refcounts ? suggestive-but-not-yet-proven-ly y'rs - tim From akuchlin at cnri.reston.va.us Tue Jul 11 04:34:04 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Mon, 10 Jul 2000 22:34:04 -0400 Subject: [Python-Dev] GC core dump caused by stringobject changes? In-Reply-To: <20000710192833.B5853@keymaster.enme.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Mon, Jul 10, 2000 at 07:28:33PM -0600 References: <20000710192833.B5853@keymaster.enme.ucalgary.ca> Message-ID: <20000710223404.A3195@newcnri.cnri.reston.va.us> On Mon, Jul 10, 2000 at 07:28:33PM -0600, Neil Schemenauer wrote: >These seem to be the changes that trigger the bug. My problem or >someone elses? No time to look in detail right now. :( >+ seq = PySequence_Fast(orig, ""); ... >+ item = PySequence_Fast_GET_ITEM(seq, i); ... >+ Py_DECREF(item); I think item shouldn't be DECREF'ed at all. Looking at what PySequence_Fast does, it either INCREF's its argument if it's a list or tuple and returns it, or coerces it to a tuple. It doesn't look like PySequence_Fast increments the refcount of what it returns. seq does need to be DECREF'ed, though: >>> import sys >>> L=['a', 'b', 'c'] >>> sys.getrefcount(L) 2 >>> for i in range(1000): a = ' '.join(L) ... >>> sys.getrefcount(L) 1002 >>> --amk From jeremy at beopen.com Tue Jul 11 05:19:32 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 23:19:32 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <20000710191537.A5853@keymaster.enme.ucalgary.ca> References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> Message-ID: <14698.37444.952060.876122@bitdiddle.concentric.net> >>>>> "NS" == Neil Schemenauer writes: NS> On Tue, Jul 11, 2000 at 01:05:10AM +0000, Peter Schneider-Kamp NS> wrote: >> I wouldn't bet my life on it, but I don't think the GC code is >> responsible. NS> Its hard to say. The GC code will probably pick up on a lot of NS> problems because it touches many objects. On the other hand, it NS> could be my bug. My first guess would be something other than the GC. When I was working on the string_join fix this afternoon, a couple of my interim versions had refcount problems that lead to core dumps in the garbage collector. The GC catches lots of memory problems because it's touching all the objects; that doesn't mean its to blame for all those problems. Which leads me to ask, Barry, did you run purify on an interpreter with the latest stringobject.c? Jeremy From tim_one at email.msn.com Tue Jul 11 05:25:15 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 10 Jul 2000 23:25:15 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <027801bfeab6$aa6115e0$f2a6b5d4@hagrid> Message-ID: [/F, on ViewCVS's virtues] > it works with MSIE5, for a start. > > and it's written by greg, in python. that's all I need to know ;-) > > the IE problem could be a configuration problem, of course. unless > tim beats me to it, I'll submit a support request some day... And I will unless you beat me to it . In the meantime, I downloaded stinking Netscape last night. Works fine. IE5 was having major problems displaying the SF Member Options page too (large table). And SF ftp access froze. And the new thing with displaying the CVS repository. They all work OK under NS. Surprised me, as my previous experiences with NS were a bloody nightmare of crashes and corruption! BTW, I'm certain I didn't do anything to change my IE5 config (& the SF CVS access worked fine on Friday). From jeremy at beopen.com Tue Jul 11 05:31:33 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 10 Jul 2000 23:31:33 -0400 (EDT) Subject: [Python-Dev] GC core dump caused by stringobject changes? In-Reply-To: <20000710223404.A3195@newcnri.cnri.reston.va.us> References: <20000710192833.B5853@keymaster.enme.ucalgary.ca> <20000710223404.A3195@newcnri.cnri.reston.va.us> Message-ID: <14698.38165.629676.33065@bitdiddle.concentric.net> Right on both counts and now fixed! Jeremy From ping at lfw.org Mon Jul 10 11:23:55 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 10 Jul 2000 02:23:55 -0700 (PDT) Subject: [Python-Dev] String coercion In-Reply-To: <39672D53.899D4BEB@prescod.net> Message-ID: On Sat, 8 Jul 2000, Paul Prescod wrote: > Ping says: > > As it stands, with both 8-bit strings and Unicode strings, i think > > this would result in too much hidden complexity -- thinking about this > > can wait until we have only one string type. > > I don't see any hidden complexity. Python has features specifically > designed to allow this sort of thing on a per-type basis. Well... what happens when the other operand is a Unicode string? Do you also do automatic coercion when adding something to a Unicode string? When you add one to an arbitrary object, how do you convert the other object into a Unicode string? When you add an 8-bit string and Unicode together, what do you get? It's not that i don't think you might be able to come up with consistent rules. I just suspect that when you do, it might amount to more hidden stuff than i'm comfortable with. Of course you could also just use Itpl.py :) or a built-in version of same (Am i half-serious? Half-kidding? Well, let's just throw it out there...). Instead of: print PaulsString("abcdef")+5 print open+PaulsString("ghijkl") with Itpl.py it would just be: printpl("abcdef${5}") printpl("${open}ghijkl") A built-in Itpl-like operator might almost be justifiable, actually... i mean, we already have "%(open)sghijkl" % globals() Well, i don't know. Perhaps it looks too frighteningly like Perl. Anyway, the rules as implemented (see http://www.lfw.org/python/ for the actual Itpl.py module) are: 1. $$ becomes $ 2. ${ } around any expression evaluates the expression 3. $ followed by identifier, followed by zero or more of: a. .identifier b. [identifier] c. (identifier) evaluates the expression What i'm getting at with this approach is that you are clear from the start that the goal is a string: you have this string thing, and you're going to insert some stringified expressions and objects into it. I think it's clearer & less error-prone for interpolation to be its own operation, rather than overloading +. It also means you could start with a Unicode string with $s in it, and you would be assured of ending up with a Unicode string, for example. -- ?!ng From bwarsaw at beopen.com Tue Jul 11 06:07:54 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 00:07:54 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> <14698.37444.952060.876122@bitdiddle.concentric.net> Message-ID: <14698.40346.841864.110547@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> Which leads me to ask, Barry, did you run purify on an JH> interpreter with the latest stringobject.c? Yes. And I did get other memory errors before the core, which I should have looked at more carefully. Looks like that might have been it. My fault for encouraging you to check your changes in without looking at them, and then I had to disappear for a few hours. I've got them now and am looking at the code (I see a missing decref, but that should only leak memory). Will Purify shortly. -Barry From moshez at math.huji.ac.il Tue Jul 11 06:36:11 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 11 Jul 2000 07:36:11 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib urllib.py,1.96,1.97 In-Reply-To: <200007101500.IAA13372@slayer.i.sourceforge.net> Message-ID: On Mon, 10 Jul 2000, Eric S. Raymond wrote: > Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv11503/dist/src/Lib > > Modified Files: > urllib.py > Log Message: > Moves some test code into the scope of if __name__ == '__main__', where it > won't get loaded when we're using the classes in this module. Why? It's only parsed once (under usual conditions) per installation, it's cost in memory is not so high, and it's cool to be able to test via ''' import urllib urllib.main() ''' -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From bwarsaw at beopen.com Tue Jul 11 06:56:54 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 00:56:54 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> <14698.37444.952060.876122@bitdiddle.concentric.net> Message-ID: <14698.43286.502470.136885@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: >>>>> "NS" == Neil Schemenauer writes: NS> Its hard to say. The GC code will probably pick up on a lot NS> of problems because it touches many objects. On the other NS> hand, it could be my bug. It also appears to mask many problems. I just compiled out the gcmodule (which is sadly undocumented, I believe) and I've just gotten a number of new memory leaks. This is basically running a very simple Python script: -------------------- snip snip -------------------- '-'.join(('one',)) '-'.join((u'one',)) -------------------- snip snip -------------------- Will investigate further, but at first blush, they might be real cycles created in the exception initialization code. But anyway... JH> Which leads me to ask, Barry, did you run purify on an JH> interpreter with the latest stringobject.c? ...I'd actually expect the above script to leak *seq twice in the current CVS string_join(). It doesn't, but then neither does including the missing decrefs cause the objects to be decref'd extra times. Interesting. Still I think string_join() needs to be patched in two places to decref *seq (first, in the seqlen==1 clause, and later just before the return PyUnicode_Join()). I'll check in a patch, but would appreciate a proofread. -Barry From fdrake at beopen.com Tue Jul 11 07:52:33 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 01:52:33 -0400 (EDT) Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: References: <027801bfeab6$aa6115e0$f2a6b5d4@hagrid> Message-ID: <14698.46625.240075.125009@cj42289-a.reston1.va.home.com> Tim Peters writes: > OK under NS. Surprised me, as my previous experiences with NS were a bloody > nightmare of crashes and corruption! BTW, I'm certain I didn't do anything > to change my IE5 config (& the SF CVS access worked fine on Friday). You have to realize that they probably test with Netscape, but rarely if ever with IE. That's a function of audience. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From moshez at math.huji.ac.il Tue Jul 11 07:55:13 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 11 Jul 2000 08:55:13 +0300 (IDT) Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162855.A9245@thyrsus.com> Message-ID: On Mon, 10 Jul 2000, Eric S. Raymond wrote: > First, for completeness there ought to be remove_section and remove_option > methods (though forgetool does not yet use them). I have documented these > as follows: > > \begin{methoddesc}{remove_option}{section, option} > Remove the specified \var{option} from the specified \var{section}. > If the section does not exist, raise \exception{NoSectionError}. > If the option existed to be removed, return 1; otherwise return 0. Ummm..encoding success/failure as return values is not usually a good idea. Why not raise KeyError if there is no such option in the section? > \begin{methoddesc}{remove_section}{section} > Remove the specified \var{section} from the configuration. > If the section in fact existed, return 1. Otherwise return 0. Ditto. Raise a NoSectionError. IF someone wants to ignore the error, they can either check if it exists, or trap the error. > Does anybody have a problem with these changes? I'm +0 -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From fdrake at beopen.com Tue Jul 11 07:58:02 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 01:58:02 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <14698.43286.502470.136885@anthem.concentric.net> References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> <14698.37444.952060.876122@bitdiddle.concentric.net> <14698.43286.502470.136885@anthem.concentric.net> Message-ID: <14698.46954.479303.841718@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > It also appears to mask many problems. I just compiled out the > gcmodule (which is sadly undocumented, I believe) and I've just gotten Neil, Can you provide something for this module? Plain text is fine if you prefer; I can add the LaTeX markup. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pf at artcom-gmbh.de Tue Jul 11 09:12:29 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 11 Jul 2000 09:12:29 +0200 (MEST) Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: <20000710162855.A9245@thyrsus.com> from "Eric S. Raymond" at "Jul 10, 2000 4:28:55 pm" Message-ID: Hi, Eric S. Raymond: > Earlier today, I committed a patch to ConfigParser that adds three new > methods to the class. Here is the documentation: [...] Applying the well known dictionary API to config info can help to to avoid reinventing a new API to deal with configuration info. What I would love to see, is a class 'ConfigDict' derived from 'UserDict.UserDict', which contains the section-names as keys and section-objects as values, where section-objects are also dictionaries containing the option-names as keys. The new class 'ConfigDict' should then provide a 'read()' or 'parse()' method (or take an optional filename as constructor argument) and would also provide 'write' and/or 'save' method(s). Hypothecical examples of use: rcfilename = os.path.join(os.environ.get("HOME", "."), ".myFoorc") cnf = ConfigParser.ConfigDict(rcfilename) # or alternatively: cnf = ConfigParser.ConfigDict() cnf.read(open(rcfilename, "r")) # ... accessing the configuration if cnf.has_key("FONT_SETTINGS"): try: size = int(cnf["FONT_SETTINGS"]["size"]) except KeyError: size = 10 # ... adding a section: cnf["new_section"] = {} # ... adding an option to the default section: cnf["screensize"] = "%dx%d" % (width, height) # ... cnf["FONT_SETTINGS"]["size"] = 10 # removing an option: del cnf["FONT_SETTINGS"]["fontname"] # removing a section or an option from the default section: del cnf["old_section"] del cnf["foo_bar"] # ... cnf.save() # only if instantiated using a filename argument # or alternatively: cnf.write(open(".myrc", "w")) [...] > To do these things, forgetool needs to maintain some local state that is > conveniently represented in the format of a Windows .ini file. More, > it needs to be able to *update* .ini files as well as parse them. This is a very common need. I agree, that this functionality should be provided by the standard library. Recently we had some discussion about a 'userpref' module, which should fill another related gap: provide a portable way to determine the rcfilename. a dot-rc file is the unix way to store this kind of information, on Windows a application specific ini file probaly belongs into another local directory (there is no $HOME) and on the Mac it probably belongs into a preferences folder ... still a lot of work to do. :-( Regards, Peter From gstein at lyra.org Tue Jul 11 11:08:18 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 02:08:18 -0700 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 11, 2000 at 08:55:13AM +0300 References: <20000710162855.A9245@thyrsus.com> Message-ID: <20000711020817.V29590@lyra.org> On Tue, Jul 11, 2000 at 08:55:13AM +0300, Moshe Zadka wrote: > On Mon, 10 Jul 2000, Eric S. Raymond wrote: > > First, for completeness there ought to be remove_section and remove_option > > methods (though forgetool does not yet use them). I have documented these > > as follows: > > > > \begin{methoddesc}{remove_option}{section, option} > > Remove the specified \var{option} from the specified \var{section}. > > If the section does not exist, raise \exception{NoSectionError}. > > If the option existed to be removed, return 1; otherwise return 0. > > Ummm..encoding success/failure as return values is not usually a good > idea. Why not raise KeyError if there is no such option in the section? Eric is defining it as "okay" to remove a non-existent option. If you want to know whether it was there, then check the return code. In most cases, you just want to say "just make sure it isn't there any more." IOW, I much prefer Eric's behavior spec over something that will generate an exception. > > \begin{methoddesc}{remove_section}{section} > > Remove the specified \var{section} from the configuration. > > If the section in fact existed, return 1. Otherwise return 0. > > Ditto. Raise a NoSectionError. IF someone wants to ignore the error, they > can either check if it exists, or trap the error. Same as above. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jul 11 11:10:09 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 02:10:09 -0700 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: ; from pf@artcom-gmbh.de on Tue, Jul 11, 2000 at 09:12:29AM +0200 References: <20000710162855.A9245@thyrsus.com> Message-ID: <20000711021008.W29590@lyra.org> On Tue, Jul 11, 2000 at 09:12:29AM +0200, Peter Funk wrote: > Hi, > > Eric S. Raymond: > > Earlier today, I committed a patch to ConfigParser that adds three new > > methods to the class. Here is the documentation: > [...] > Applying the well known dictionary API to config info can help to > to avoid reinventing a new API to deal with configuration info. > > What I would love to see, is a class 'ConfigDict' derived from > 'UserDict.UserDict', which contains the section-names as keys and > section-objects as values, where section-objects are also dictionaries > containing the option-names as keys. Then go ahead and code it. I guarantee that you'll have your wish if you code it. Otherwise, I'll lay very low odds on all the new module suggestions in your email. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Tue Jul 11 11:32:44 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 11 Jul 2000 11:32:44 +0200 (CEST) Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length In-Reply-To: <025001bfeab4$f07251e0$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 10, 2000 11:22:22 PM Message-ID: <200007110932.LAA14002@python.inrialpes.fr> Fredrik Lundh wrote: > > jeremy wrote: > > > Tuple, List, String, and Dict have a PyXXX_Size method. The abstract > > object interface uses PySequence_Length. This is inconsistent and > > hard to remember. Can we add PySequence_Size and mark Length as > > deprecated? > > don't forget PyObject_Length and PyMapping_Length... Why deprecate? There's nothing wrong with these names. However, for conveniency, it would make sense to have PyXXX_Size macros, synonyms for the PyXXX_Length functions. Or vice versa. Have _Length macros, synonyms for _Size functions. However, this is not backwards (binary) compatible, which I believe is harmless for a new release, but the recent Windows DLL thread reminds that bin compatibility accross versions is somewhat important. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Tue Jul 11 12:10:36 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 03:10:36 -0700 Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length In-Reply-To: <200007110932.LAA14002@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Tue, Jul 11, 2000 at 11:32:44AM +0200 References: <025001bfeab4$f07251e0$f2a6b5d4@hagrid> <200007110932.LAA14002@python.inrialpes.fr> Message-ID: <20000711031036.E29590@lyra.org> On Tue, Jul 11, 2000 at 11:32:44AM +0200, Vladimir Marangozov wrote: > Fredrik Lundh wrote: > > > > jeremy wrote: > > > > > Tuple, List, String, and Dict have a PyXXX_Size method. The abstract > > > object interface uses PySequence_Length. This is inconsistent and > > > hard to remember. Can we add PySequence_Size and mark Length as > > > deprecated? > > > > don't forget PyObject_Length and PyMapping_Length... > > Why deprecate? There's nothing wrong with these names. > However, for conveniency, it would make sense to have > PyXXX_Size macros, synonyms for the PyXXX_Length functions. Because having both names is even worse than having inconsistent names. The question will always arise "what is the difference? why should I use one over the other?" You can tell people they are the same until you're blue in the face -- the question will still come up. Maybe after a while, the question won't come up any more. But then you have to answer, "okay. so they're exactly the same. why have two of them, then?" :-) > Or vice versa. Have _Length macros, synonyms for _Size functions. > However, this is not backwards (binary) compatible, which I > believe is harmless for a new release, but the recent Windows > DLL thread reminds that bin compatibility accross versions > is somewhat important. Binary compatibility in Open Source software is a pipe dream. There is absolutely no sense in trying to worry about it, and even more sense to explicitly bail out with "that doesn't work." Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jul 11 12:35:34 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 03:35:34 -0700 Subject: [Python-Dev] Changes to ConfigParser In-Reply-To: ; from pf@artcom-gmbh.de on Tue, Jul 11, 2000 at 12:10:41PM +0200 References: <20000711021008.W29590@lyra.org> Message-ID: <20000711033534.K29590@lyra.org> On Tue, Jul 11, 2000 at 12:10:41PM +0200, Peter Funk wrote: > Greg Stein : > > On Tue, Jul 11, 2000 at 09:12:29AM +0200, Peter Funk wrote: > > > Hi, > > > > > > Eric S. Raymond: > > > > Earlier today, I committed a patch to ConfigParser that adds three new > > > > methods to the class. Here is the documentation: > > > [...] > > > Applying the well known dictionary API to config info can help to > > > to avoid reinventing a new API to deal with configuration info. > > > > > > What I would love to see, is a class 'ConfigDict' derived from > > > 'UserDict.UserDict', which contains the section-names as keys and > > > section-objects as values, where section-objects are also dictionaries > > > containing the option-names as keys. > > > > Then go ahead and code it. I guarantee that you'll have your wish if you > > code it. Otherwise, I'll lay very low odds on all the new module suggestions > > in your email. > > Okay: I just had a look into the implementation of ConfigParser and > stumbled over the '%(foo)' macro expansion features. If I go ahead and > implement these within (below) my ConfigDict.__getitem__ method, this > will lead to the problem, that > cnf['some_section']['foo'] = 'feeble' > cnf['some_section']['bar'] = 'baz' > cnf['some_section']['some_option'] = '%(foo)/paf/%(bar)' > print cnf['some_section']['some_option'] > might surprise users with the dictionary model in their head. > They might expect this to print '%(foo)/paf/%(bar)' instead of > 'feeble/paf/baz'. > > Any suggestions? It is a configuration dictionary. Users can simply deal with it :-) I'm not sure it is a big problem to worry about. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Tue Jul 11 14:41:18 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 11 Jul 2000 14:41:18 +0200 (CEST) Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length In-Reply-To: <20000711031036.E29590@lyra.org> from "Greg Stein" at Jul 11, 2000 03:10:36 AM Message-ID: <200007111241.OAA21491@python.inrialpes.fr> Greg Stein wrote: > > > Why deprecate? There's nothing wrong with these names. > > However, for conveniency, it would make sense to have > > PyXXX_Size macros, synonyms for the PyXXX_Length functions. > > Because having both names is even worse than having inconsistent names. The > question will always arise "what is the difference? why should I use one > over the other?" You can tell people they are the same until you're blue in > the face -- the question will still come up. Maybe after a while, the > question won't come up any more. But then you have to answer, "okay. so > they're exactly the same. why have two of them, then?" :-) Okay, then deprecate them if there are no other objections. But binary compatibility aside, if we don't provide _Length macros, this would break tons of legacy source code, so both must be there for some (long) time. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gward at mems-exchange.org Tue Jul 11 14:39:44 2000 From: gward at mems-exchange.org (Greg Ward) Date: Tue, 11 Jul 2000 08:39:44 -0400 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <200007101725.MAA01255@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 10, 2000 at 12:25:12PM -0500 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> Message-ID: <20000711083943.A27423@ludwig.cnri.reston.va.us> On 10 July 2000, Guido van Rossum said: > Makefile includes are notoriously unportable, aren't they? The > embed/Makefile is a lame excuse for a Makefile -- it has XXX comments > all over the place telling you to edit things to match the Python main > Makefile... :-( My fault -- feel free to fix! I think the mere existence of an "include" directive is pretty well-established. What's not portable, in my experience, is relying in neat-o semantics supplied by GNU make and (maybe? can't remember) SGI's decent make (smake I think? plain make under IRIX 4 and 5 was hopelessly brain-damaged). Specifically, GNU make will treat a missing include file not as an error, but something that should be rebuilt using the usual dependency rules. Apparently this is useful for including header dependency info in the Makefile, but of course it ties you right to GNU make. If you believe the "Recursive Make Considered Harmful" paper, it's probably better to rely on the ability to include Makefile fragments than to invoke make recursively. (It sound plausible to me, but I haven't tried out the ideas from that paper seriously yet.) Greg From guido at beopen.com Tue Jul 11 15:48:15 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 08:48:15 -0500 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: Your message of "Mon, 10 Jul 2000 14:16:38 MST." <20000710141638.R29590@lyra.org> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> <20000710141638.R29590@lyra.org> Message-ID: <200007111348.IAA04699@cj20424-a.reston1.va.home.com> > We're using includes in the Apache 2.0 makefiles. I'm not sure whether this > is going to make Apache 2.0 less portable or not. There haven't been any > issues yet, though. > > (I think the makefile organization came from PHP; assuming that is as > portable as Apache 1.3, then makefile includes are pretty darn portable) > > IMO, I say "start using makefile includes" and see who screams. VPATH is not > portable, though. The difference is that Apache and PHP only need to be portable to server-class machines. Python also runs on (1) very ancient hardware; (2) some Cray-class machines; (3) non-Unix hardware with enough Unix emulation to be able to run the configure script (I believe the BeOS port falls in this category, and of course cygwin). Call me conservative, --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Tue Jul 11 14:59:44 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 08:59:44 -0400 (EDT) Subject: [Python-Dev] Core dump in garbage collection: _PyGC_Insert??? In-Reply-To: <14698.40346.841864.110547@anthem.concentric.net> References: <396A51C4.894E1550@per.dem.csiro.au> <396A72C6.6810C95E@stud.ntnu.no> <20000710191537.A5853@keymaster.enme.ucalgary.ca> <14698.37444.952060.876122@bitdiddle.concentric.net> <14698.40346.841864.110547@anthem.concentric.net> Message-ID: <14699.6720.758571.615919@bitdiddle.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "JH" == Jeremy Hylton writes: JH> Which leads me to ask, Barry, did you run purify on an BAW> Looks like that might have been it. My fault for encouraging BAW> you to check your changes in without looking at them, and then BAW> I had to disappear for a few hours. I was in a rush, too. I should have waited until after my softball game. Jeremy From esr at thyrsus.com Tue Jul 11 15:08:17 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 11 Jul 2000 09:08:17 -0400 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <200007111348.IAA04699@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 08:48:15AM -0500 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> <20000710141638.R29590@lyra.org> <200007111348.IAA04699@cj20424-a.reston1.va.home.com> Message-ID: <20000711090817.A11533@thyrsus.com> Guido van Rossum : > > IMO, I say "start using makefile includes" and see who screams. VPATH is > > not portable, though. > > [No,] Call me conservative, I'm -1 on this also. I've had too many bad experiences dealing with variance in the semantics of inclusion. -- Eric S. Raymond What is a magician but a practicing theorist? -- Obi-Wan Kenobi, 'Return of the Jedi' From thomas at xs4all.net Tue Jul 11 15:17:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 15:17:41 +0200 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <200007111348.IAA04699@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 08:48:15AM -0500 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> <20000710141638.R29590@lyra.org> <200007111348.IAA04699@cj20424-a.reston1.va.home.com> Message-ID: <20000711151740.T26534@xs4all.nl> On Tue, Jul 11, 2000 at 08:48:15AM -0500, Guido van Rossum wrote: > > IMO, I say "start using makefile includes" and see who screams. VPATH is not > > portable, though. > The difference is that Apache and PHP only need to be portable to > server-class machines. Python also runs on (1) very ancient hardware; > (2) some Cray-class machines; (3) non-Unix hardware with enough Unix > emulation to be able to run the configure script (I believe the BeOS > port falls in this category, and of course cygwin). Actually, I was referring to the trick PIL and other extension modules use to build their own Makefile based on Python's. I'm not sure how portable that particular Makefile is, however. I'm one of those types that use 'gmake' on systems that do not have GNU make as the default make ;-) And forgive me for saying this, but I think providing a good, self-configuring but slightly unportable Makefile.pre.in *and* a README (and/or example) that shows how to do it by hand on old/incapacitated systems, is preferable over just providing a completely unportable Makefile and a README that shows how to do it on other systems :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Tue Jul 11 16:40:32 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 09:40:32 -0500 Subject: [Python-Dev] list comprehensions again... In-Reply-To: Your message of "Tue, 11 Jul 2000 12:31:55 +1200." <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> Message-ID: <200007111440.JAA05205@cj20424-a.reston1.va.home.com> > [x,y for x in (1,2,3) for y in (4,5,6)] Hm, I suppose the programmer meant the same as [(x,y) for x in (1,2,3) for y in (4,5,6)] Would it be really bad if we forced them to write it that way? Side note: the suggested syntax here (for i in seq1 for j in seq2) looks like a potential alternative for the currently proposed parallel for loop syntax (for i in seq1; j in seq2). Only problem: the for-for variant could be mistaken by someone used to see nested loops as meaning the same as for i in seq1: for j in seq2: ... Undecided and unhelpful, --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From akuchlin at mems-exchange.org Tue Jul 11 15:54:43 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 11 Jul 2000 09:54:43 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: ; from pingster@ilm.com on Thu, Jul 06, 2000 at 02:16:07PM -0700 References: <20000706171159.A25398@kronos.cnri.reston.va.us> Message-ID: <20000711095443.D27228@kronos.cnri.reston.va.us> On Thu, Jul 06, 2000 at 02:16:07PM -0700, Ka-Ping Yee quoted me: >> I'd suggest adding poll() to 2.0, and will submit a patch if given the >> go-ahead. But where should it go? A whole module for it seems >> excessive; should it go in posixmodule, or maybe select? I've completed a patch, SF#100852, to add os.poll() based on Sam Rushing's code with various modifications; I'd like a reviewer to look it over, after which I'll check it in. http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 I'm not happy with the interface -- you pass in a list of (file descriptor, event mask) 2-tuples -- but it seems the only way to expose all of poll()'s functionality. I thought about allowing a lone file descriptor as well as a tuple, in which you'd assume an event mask of POLLIN | POLLPRI | POLLOUT (all the common events), but it seemed like too much magic. Also, is there a C utility function to handle the "pass an integer or an object with a fileno() method" protocol for me? Should there be one? --amk From guido at beopen.com Tue Jul 11 16:58:46 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 09:58:46 -0500 Subject: [Python-Dev] Re: SourceForge In-Reply-To: Your message of "Mon, 10 Jul 2000 21:10:00 -0400." <20000710211000.A10068@thyrsus.com> References: <20000707133533.E17746@valinux.com> <20000707182448.A31259@thyrsus.com> <39667D29.1A4FB1BB@valinux.com> <20000709214138.I4566@thyrsus.com> <396A4CFC.CEE2419A@valinux.com> <20000710203719.B9793@thyrsus.com> <396A6F7D.66D5F085@valinux.com> <20000710211000.A10068@thyrsus.com> Message-ID: <200007111458.JAA05267@cj20424-a.reston1.va.home.com> > Dan Bressler : > > I'm trying to sync schedules -- If we could set it for Tuesday evening, July > > 18th, that would work best. > > OK. Python folks who will be at the Monterey conference; Dan > Bressler, one of the managers of SourceForge, is amenable to an > evening meeting with this gang on Tuesday the 18th. I gather Tim > Purdue, currently the lead programmer on the project, will be there. > > The exact time is still to be worked out. Anybody got a proposal? I'm not sure what time we'll be arriving in Monterey -- we have our plane tickets to San Jose and I know we're going to spend Tuesday daytime at the BeOpen headquarters in Santa Clara, but I don't know yet what mode of transportation we're going to take to Monterey and at what time. Given that Dan prefers Tuesday evening I'll try to press for leaving early enough so that there's some evening left! Looking forward to this meeting, --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Tue Jul 11 16:04:06 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 16:04:06 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111440.JAA05205@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 09:40:32AM -0500 References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> <200007111440.JAA05205@cj20424-a.reston1.va.home.com> Message-ID: <20000711160406.D25805@xs4all.nl> On Tue, Jul 11, 2000 at 09:40:32AM -0500, Guido van Rossum wrote: > > [x,y for x in (1,2,3) for y in (4,5,6)] > Hm, I suppose the programmer meant the same as > > [(x,y) for x in (1,2,3) for y in (4,5,6)] > Would it be really bad if we forced them to write it that way? Actually, the change in Grammar wouldn't enforce that. (At least, I think not.) Because the 'for' splits and disambiguates before the ',' in the first tuple, the parser will always see it as such, and it's probably pretty hard to convince the parser not to :-) Because of the way 'testlist' and 'test' are defined, it's easy to use them interchangeably. I think, anyway. I'm still new at this parsing thing :-) But the Gramar uses 'testlist' to mean the contents of the list itself, so it seems logical to me that this should be the case wether or not 'testlist' is followed by 'list_iter' -- currently, the presense of list_iter changes (the interpretation of) it from the contents of a list to a tuple. Like I said, it was nit-picky ;) > Side note: the suggested syntax here (for i in seq1 for j in seq2) > looks like a potential alternative for the currently proposed parallel > for loop syntax (for i in seq1; j in seq2). > Only problem: the for-for variant could be mistaken by someone used to > see nested loops as meaning the same as > > for i in seq1: > for j in seq2: ... I personally prefer 'for i in seq1; j in seq2' because it's a lot less ambiguous. More importantly, however, the meaning in the cited list-comprehension example is different ! [x,y for x in (1,2,3) for y in (4,5,6)] is actually turned into a pair of nested loops: tmp = [] for x in (1,2,3): for y in (4,5,6): tmp.append(x,y) (Quite literally so, in fact ;) So it's *not* the same as the parallel-loop-for: tmp = [] for x in (1,2,3); y in (4,5,6): tmp.append(x,y) For that reason alone, I'd go for the 2nd syntax ;) Unless, of course, you have a proposed new syntax for the nested-for-loop in list comprehensions :-) > Undecided and unhelpful, Helpfully deciding-ly'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From petersc at stud.ntnu.no Tue Jul 11 18:16:16 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Tue, 11 Jul 2000 16:16:16 +0000 Subject: merging my*.h into pyport.h (was: Re: [Python-Dev] Py_PROTO elimination in Include/) References: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com> Message-ID: <396B4850.A3D1A1A2@stud.ntnu.no> "Fred L. Drake, Jr." wrote: > > I've removed Py_PROTO from the headers in the Include/ directory, > with the exceptions of the my*.h headers. I'll leave it for others to > fix those, merging with pyport.h as appropriate. What do you think would be appropriate? I have been toying around with the my*.h headers a bit and loaded up a "proof of concept" patch that makes all my*.h obsolete. concerns with the patch: - messing around with a lot if non-linux #ifdef sections (can somebody have a look at that?) - possibly including unneeded headers (is that a problem?) - undocumented (I can take care of that when the time comes) hoping-for-feedback-ly y'rs Peter P.S.: What's the status of sre? I just ask because test_re keeps nagging all the time. :-] -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From petersc at stud.ntnu.no Tue Jul 11 18:19:40 2000 From: petersc at stud.ntnu.no (Peter Schneider-Kamp) Date: Tue, 11 Jul 2000 16:19:40 +0000 Subject: merging my*.h into pyport.h (was: Re: [Python-Dev] Py_PROTO elimination in Include/) References: <14695.52816.467277.614076@cj42289-a.reston1.va.home.com> <396B4850.A3D1A1A2@stud.ntnu.no> Message-ID: <396B491C.C3ABFFE2@stud.ntnu.no> Peter Schneider-Kamp wrote: > > - messing around with a lot if non-linux #ifdef sections make that: a lot of non-linux #ifdef sections sorry, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From guido at beopen.com Tue Jul 11 17:23:45 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 10:23:45 -0500 Subject: [Python-Dev] Python License may be discussed at Python Consortium Meeting Message-ID: <200007111523.KAA05408@cj20424-a.reston1.va.home.com> While there still isn't much to report regarding the negotiations between BeOpen and CNRI about Python releases and licenses, I thought I should point out that there is some progress. BeOpen is taking a stance that all Python users should appreciate -- I'd summarize it as "keep the old Python license or bust". CNRI is trying to argue for a new license that is identical to the JPython license (http://www.jpython.org/jplicense.html) with removal of paragraph 3 (requirement to prominent display changes w.r.t. CNRI's version) and paragraph 4 (trademark restrictions). In our views, this license is unusable for several reasons -- it's not GPL-compatible, it's not Open Source compliant, and on previous occasions members of the Python community have reacted strongly against it. I promise that BeOpen won't accept CNRI's current proposal. It's impossible to say whether CNRI will accept BeOpen's position; as a precaution, assuming the issue is still open next week, we've added discussion of the license to the agenda of the Python Consortium meeting in Monterey (see below). I can't say what will happen if the negotiations break off -- but I hope that the discussion at the meeting will open CNRI's eyes. I hope that employees of consortium member companies will do everything they can to ensure that their company is represented at the meeting for this important discussion! Feel free to write me for more background information. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------- Forwarded Message Date: Mon, 10 Jul 2000 15:09:29 -0400 From: Albert Vezza To: consortium-members at python.org cc: rkahn at cnri.reston.va.us, Barbara Fuller Subject: [Py-Consortium] Python Consortium Meeting Python Consortium Members, There will be an important Python Consortium meeting on the July 21st following the O'Reilly Open Source Conference in Monterey, California. The meeting will be held at the Marriott which is adjacent to the Monterey Convention center. This is a discussion meeting and all items on the agenda will be fully explored along with any other important items that are brought to the table. If any member has an important issue they would like to see explored please let me know. Please RSVP to bfuller at foretec.com with the name of the attendees. Best regards, Al ---------------------------------------------------------- Proposed Agenda 8:00 Continental Breakfast 9:00 Python Consortium and Its Continuing Role 10:00 Transition of the Python Development Activity 12:00 Lunch 1:00 Management of the Python.Org Site 3:00 The future Python license 4:00 The desired development path for Python 2.0 5:00 Adjourn Albert Vezza Vice President Corporation for National Research Initiatives 1895 Preston White Drive Suite 100 Reston, VA 20191-5434 Internet mail: avezza at cnri.reston.va.us Tel: (703) 620-8990 Fax: (703) 620-0913 Natick, MA Office Tel: (508) 650 4020 Fax: (508) 650 4639 ------- End of Forwarded Message From gvwilson at nevex.com Tue Jul 11 16:42:55 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 10:42:55 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111440.JAA05205@cj20424-a.reston1.va.home.com> Message-ID: > > [x,y for x in (1,2,3) for y in (4,5,6)] > Hm, I suppose the programmer meant the same as > [(x,y) for x in (1,2,3) for y in (4,5,6)] > Would it be really bad if we forced them to write it that way? Strongly prefer the latter, as it permits: [[x,y] for x in (1,2,3) for y in (4,5,6)] (either now or in future). Would it also permit: [{x:y} for x in (1,2,3) for y in (4,5,6)] i.e. dict construction using list comprehension? I'd use this in quite a few places. > Side note: the suggested syntax here (for i in seq1 for j in seq2) > looks like a potential alternative for the currently proposed parallel > for loop syntax (for i in seq1; j in seq2). > > Only problem: the for-for variant could be mistaken by someone used to > see nested loops as meaning the same as > > for i in seq1: > for j in seq2: ... Until yesterday's posting, I assumed that this is what for-for loops would do, i.e. that they'd deliver a cross-product rather than one-from-each. Was going to ask whether: for i in seq1 and j in seq2: foo would be clearer, but then realized that people might assume it implied that: for i in seq1 or j in seq2: foo would also work, meaning either "while either list is non-empty" or "cross-product". Random thoughts, Greg From guido at beopen.com Tue Jul 11 17:57:10 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 10:57:10 -0500 Subject: [Python-Dev] Bug fixing policy (was Re: Changes to ConfigParser) In-Reply-To: Your message of "Mon, 10 Jul 2000 15:33:14 MST." <20000710153314.W29590@lyra.org> References: <20000710162855.A9245@thyrsus.com> <20000710153314.W29590@lyra.org> Message-ID: <200007111557.KAA05666@cj20424-a.reston1.va.home.com> Greg Stein writes: > > > API changes probably ought to be discussed on this list (which includes the > maintainers of any code). Basic point: the "maintainer(s)" is usually quite > unclear since we avoid attribution within the source if at all possible. > Posing the suggested change here allows for changing maintainers (note that > Fred has done a tone of work on ConfigParser, and I've submitted a few > changes myself, too!), and it allows for broader input. > > However, bug fixes and minor reworking should probably be allowed regardless > of the maintainer. I'd hate to end up at a point where the Python > interpreter is partitioned into a bunch of little fiefdoms, where you must > pay a toll to enter. > > Excellent summary. I would add that if a maintainer is actively maintaining their code, it's not polite to check in changes to their code. It's better to give them a chance to fix it first. (The maintainer them should attribute the fix to whoever first mailed it to them, if they use the fix.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Tue Jul 11 18:09:16 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 11:09:16 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Tue, 11 Jul 2000 09:54:43 -0400." <20000711095443.D27228@kronos.cnri.reston.va.us> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> Message-ID: <200007111609.LAA05816@cj20424-a.reston1.va.home.com> > >> I'd suggest adding poll() to 2.0, and will submit a patch if given the > >> go-ahead. But where should it go? A whole module for it seems > >> excessive; should it go in posixmodule, or maybe select? > > I've completed a patch, SF#100852, to add os.poll() based on Sam > Rushing's code with various modifications; I'd like a reviewer to look > it over, after which I'll check it in. > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 > > I'm not happy with the interface -- you pass in a list of (file > descriptor, event mask) 2-tuples -- but it seems the only way to > expose all of poll()'s functionality. I thought about allowing a lone > file descriptor as well as a tuple, in which you'd assume an event > mask of POLLIN | POLLPRI | POLLOUT (all the common events), but it > seemed like too much magic. I haven't read the patch in detail, but this approach seems reasonable. Somehow I don't understand why we need poll() when we have select(), however. Select() is portable, poll() is Unix specific, but it seems to provide the same functionality. What am I missing? > Also, is there a C utility function to handle the "pass an integer or > an object with a fileno() method" protocol for me? Should there be > one? This is a nice refactoring opportunity. The code probably exists in many places, e.g. selectmodule.c. It should be a function in fileobject.c, I suppose. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fredrik at pythonware.com Tue Jul 11 17:15:06 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 11 Jul 2000 17:15:06 +0200 Subject: [Python-Dev] Adding poll() system call References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> Message-ID: <000701bfeb4a$cbf101e0$0900a8c0@SPIFF> guido wrote: > Somehow I don't understand why we need poll() when we have select(), > however. Select() is portable, poll() is Unix specific, but it seems > to provide the same functionality. What am I missing? quoting from http://www.nightmare.com/medusa/ A major design problem with select(2) is that an fd_set is usually of a fixed maximum size, on many operating systems the kernel needs to rebuilt to raise this limit; even on those that have dynamically adjustable limits, you still need to re- compile your application (because FD_SETSIZE is a macro). From skip at mojam.com Tue Jul 11 04:48:42 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 10 Jul 2000 21:48:42 -0500 (CDT) Subject: [Python-Dev] More Symantec symbols Message-ID: <14698.35594.999203.707698@beluga.mojam.com> Picking up where the __SC__ thread left off, I noticed the following other Symantec symbols in the Python sources just now: ./Include/Python.h:48:#ifdef SYMANTEC__CFM68K__ ./Include/Python.h:65:#ifdef SYMANTEC__CFM68K__ ./Include/mymalloc.h:47:#ifdef SYMANTEC__CFM68K__ ./Include/mymath.h:8:#ifdef SYMANTEC__CFM68K__ ./Include/mymath.h:27:#ifdef SYMANTEC__CFM68K__ ./Python/dynload_mac.c:18:#ifdef SYMANTEC__CFM68K__ /* Really an older version of Universal Headers */ ./Python/errors.c:15:#ifdef SYMANTEC__CFM68K__ Should these be zapped as well or is this something wholely unrelated to the old Symantec compiler issue? Skip From akuchlin at mems-exchange.org Tue Jul 11 17:28:47 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 11 Jul 2000 11:28:47 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <200007111609.LAA05816@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 11:09:16AM -0500 References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> Message-ID: <20000711112847.G27228@kronos.cnri.reston.va.us> On Tue, Jul 11, 2000 at 11:09:16AM -0500, Guido van Rossum wrote: >Somehow I don't understand why we need poll() when we have select(), >however. Select() is portable, poll() is Unix specific, but it seems >to provide the same functionality. What am I missing? In addition to /F's quote, poll() also scales better since it only lists the file descriptors of interest, while select() builds a bitmap, turns on bits for the fds of interest, and then afterward you have to scan the whole bitmap again. It's O(maximum fd), while poll is O(# of fds), making it more useful for writing more scalable network servers that service thousands of clients at the same time. (At the very highest end, even poll() begins to scale badly since you list "all the open fds", not "all the open fds which have activity". At that point you're supposed to switch to async I/O, but probably you'd have switched from Python to C long before that point.) >This is a nice refactoring opportunity. The code probably exists in >many places, e.g. selectmodule.c. It should be a function in >fileobject.c, I suppose. OK; I'll write up a separate patch to do this and submit it first. (Looks like only select, _tkinter, and poll need this functionality.) --amk From skip at mojam.com Tue Jul 11 16:05:03 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 09:05:03 -0500 (CDT) Subject: [Python-Dev] once enabled gc won't go away until explicitly disabled? Message-ID: <14699.10639.15423.982767@beluga.mojam.com> I had been running with --with-cycle-gc, then the mystery bug hit yesterday, so last night I was working on other stuff and wanted to disable it. I tried removing config.cache and then executing configure as ./configure --with-threads but gc was still there. Then I explicitly commented out the gc line in Modules/Setup.config. Still no luck. Finally, I configured as ./configure --with-threads --without-cycle-gc and then it went away. Is this the correct behavior? Skip From bwarsaw at beopen.com Tue Jul 11 17:38:55 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 11:38:55 -0400 (EDT) Subject: [Python-Dev] once enabled gc won't go away until explicitly disabled? References: <14699.10639.15423.982767@beluga.mojam.com> Message-ID: <14699.16271.147279.134444@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> I had been running with --with-cycle-gc, then the mystery bug SM> hit yesterday, so last night I was working on other stuff and SM> wanted to disable it. I tried removing config.cache and then SM> executing configure as SM> ./configure --with-threads SM> but gc was still there. Then I explicitly commented out the SM> gc line in Modules/Setup.config. Still no luck. Finally, I SM> configured as SM> ./configure --with-threads --without-cycle-gc SM> and then it went away. SM> Is this the correct behavior? Yes, although both gc and threads are enabled by default in the current betas (so you don't need --with-threads). Whether they'll be enabled for the final release is still TBD. -Barry From guido at beopen.com Tue Jul 11 18:48:47 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 11:48:47 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Tue, 11 Jul 2000 17:15:06 +0200." <000701bfeb4a$cbf101e0$0900a8c0@SPIFF> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <000701bfeb4a$cbf101e0$0900a8c0@SPIFF> Message-ID: <200007111648.LAA06034@cj20424-a.reston1.va.home.com> > guido wrote: > > Somehow I don't understand why we need poll() when we have select(), > > however. Select() is portable, poll() is Unix specific, but it seems > > to provide the same functionality. What am I missing? > > quoting from http://www.nightmare.com/medusa/ > > A major design problem with select(2) is that an fd_set is > usually of a fixed maximum size, on many operating systems > the kernel needs to rebuilt to raise this limit; even on those > that have dynamically adjustable limits, you still need to re- > compile your application (because FD_SETSIZE is a macro). OK. +1 from me. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Tue Jul 11 17:52:05 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 11:52:05 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <20000711112847.G27228@kronos.cnri.reston.va.us> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> Message-ID: <14699.17061.139324.335138@bitdiddle.concentric.net> If we're adding poll to enhance scalability, I'd like to see a more efficient interface that generates the poll_fd* separately from calling poll. The interface would be something like this: obj = poll.new() # generate a new pollfd array obj.register(f1, POLLIN | POLLOUT) obj.register(f2, POLLOUT) obj.poll() obj.unregister(f2) obj.poll() I think this would be a lot more efficient when the files being polled don't change very often. Jeremy From thomas at xs4all.net Tue Jul 11 17:52:31 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 17:52:31 +0200 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <14699.17061.139324.335138@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 11, 2000 at 11:52:05AM -0400 References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> Message-ID: <20000711175231.V26534@xs4all.nl> On Tue, Jul 11, 2000 at 11:52:05AM -0400, Jeremy Hylton wrote: > The interface would be something like this: > obj = poll.new() # generate a new pollfd array I would suggest 'poll.Poller()' or some such, for similarity with pickle and such. 'new()' looks a bit C++ish to me ;) Definately +1 on the idea tho ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Tue Jul 11 17:53:14 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 11:53:14 -0400 (EDT) Subject: [Python-Dev] SyntaxError patches Message-ID: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> Ping has a really nice patch to generate better error messages for SyntaxError on SourceForge (#100734). This provides better messages, but keeps all these errors as plain SyntaxError exceptions. At one point, we were discussing having specializations of SyntaxError, and I posted a patch that defined IndentationError and TabError. With Ping's changes, using these instead of plain SyntaxError is trivial. Should I include that, or only change the error messages using Ping's patch? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Jul 11 17:56:42 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 11:56:42 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <20000711175231.V26534@xs4all.nl> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> <20000711175231.V26534@xs4all.nl> Message-ID: <14699.17338.219363.10153@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > I would suggest 'poll.Poller()' or some such, for similarity with pickle and > such. 'new()' looks a bit C++ish to me ;) Definately +1 on the idea tho ;) Both have precedents in the standard library; the MD5 and SHA hash modules both provide a new() function to create the objects. It's not clear that the class-like name is terribly appropriate since a C type could not be subclassed. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Tue Jul 11 16:35:53 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 09:35:53 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111440.JAA05205@cj20424-a.reston1.va.home.com> References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> <200007111440.JAA05205@cj20424-a.reston1.va.home.com> Message-ID: <14699.12489.875905.520781@beluga.mojam.com> Guido> [(x,y) for x in (1,2,3) for y in (4,5,6)] Guido> Would it be really bad if we forced them to write it that way? For that matter, perhaps requiring parens for all tuple definitions in Py3k wouldn't be a bad idea. Skip From thomas at xs4all.net Tue Jul 11 17:09:05 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 17:09:05 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from gvwilson@nevex.com on Tue, Jul 11, 2000 at 10:42:55AM -0400 Message-ID: <20000711181021.G25805@xs4all.nl> [Note: removing known python-dev members from CC: line. I apologize if that's inconvenient, but otherwise Mailman might not let the posting through. Also, Greg Ewing already received this msg, which had a typo in the To: line. Sorry, Greg ;-P] On Tue, Jul 11, 2000 at 10:42:55AM -0400, Greg Wilson wrote: > > > [x,y for x in (1,2,3) for y in (4,5,6)] > > Hm, I suppose the programmer meant the same as > > [(x,y) for x in (1,2,3) for y in (4,5,6)] > > Would it be really bad if we forced them to write it that way? Oh, yeah, I forgot to say why I disliked it, asside from it being hard to do: Isn't the idea that ()'s do not create tuples, ','s do ? To make something clear, though, '[x,y for x in (1,2,3) for y in (4,5,6)]' creates [(1, 4), (1, 5), (1, 6), (2, 4), (2, 5), (2, 6), (3, 4), (3, 5), (3, 6)] and *not* '[1, 4, 2, 5, 3, 6]', in case anyone was thinking that ! That would be the only reason I'd go for forcing '(x,y)' somehow: disambiguation. But then, tuple-creation is slightly ambiguous already, so allowing the ()'s to be left out here as well, seems pretty natural to me. > Strongly prefer the latter, as it permits: > [[x,y] for x in (1,2,3) for y in (4,5,6)] > (either now or in future). Would it also permit: > [{x:y} for x in (1,2,3) for y in (4,5,6)] > i.e. dict construction using list comprehension? I'd use this in quite a > few places. The first is a good example, though it creates a list of lists, not a single list. The second would create a list of dicts, not a single dict. If you want to create a single dict, this would be better syntax: {x:y for x in (1,2,3) for y in (4,5,6)} AKA dict-comprehensions ;) Unless '[' .. ']' is changed from list-creator to comprehensions-function, and the resulting object is determined by the first expression within the listcomp... That makes it a lot less logical, to me :P > Until yesterday's posting, I assumed that this is what for-for loops would > do, i.e. that they'd deliver a cross-product rather than one-from-each. Well, what would be the use ? You can do that using nested for-loops already. So it looks a tad different, so what ;) (Or are you talking about for-for-loops in list comprehensions instead ?) > Was going to ask whether: > > for i in seq1 and j in seq2: > foo > would be clearer, but then realized that people might assume it implied > that: > for i in seq1 or j in seq2: > foo > would also work, meaning either "while either list is non-empty" or > "cross-product". Well, the problem with *that* syntax is that it's already valid ! Imagine seq1 being a sequence, and seq2.__contains__ returning a sequence. Also, the parser would have a hard time figuring out what version of the for loop to use: is this 'for' exprlist 'in' testlist where 'testlist' contains 'and' and/or 'in', or 'for' exprlist 'in' testlist ('and' exprlist 'in' testlist)* ? I'm not sure if it's possible to use the 2nd form at all! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From akuchlin at mems-exchange.org Tue Jul 11 18:18:17 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 11 Jul 2000 12:18:17 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <14699.17061.139324.335138@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 11, 2000 at 11:52:05AM -0400 References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> Message-ID: <20000711121817.J27228@kronos.cnri.reston.va.us> On Tue, Jul 11, 2000 at 11:52:05AM -0400, Jeremy Hylton wrote: >obj = poll.new() # generate a new pollfd array >obj.register(f1, POLLIN | POLLOUT) >obj.register(f2, POLLOUT) >obj.poll() >obj.unregister(f2) >obj.poll() Very interesting, and probably worth doing because all that list parsing *is* a silly waste of CPU. But could poll still live in the posixmodule, then, or be a module of its own? [1] As a side issue, is posixmodule.c getting ungainly, at 5333 lines of source code? Should something be done about this? (Splitting it into several C files that get #included, or get linked together, for example.) --amk [1] Ironic footnote: Sam mentioned that Egroups doesn't actually use the pollmodule.c in the Medusa distribution, because they already have a module named "poll" that does something completely different. From fdrake at beopen.com Tue Jul 11 18:22:43 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 12:22:43 -0400 (EDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> References: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> Message-ID: <14699.18899.148734.462266@cj42289-a.reston1.va.home.com> I wrote: > At one point, we were discussing having specializations of > SyntaxError, and I posted a patch that defined IndentationError and > TabError. With Ping's changes, using these instead of plain > SyntaxError is trivial. Should I include that, or only change the > error messages using Ping's patch? I've attached a combined patch, in case any is interested. This does not include updated documentation, and could use additional tests. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: indentation-error.patch URL: From guido at beopen.com Tue Jul 11 19:52:43 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 12:52:43 -0500 Subject: [Python-Dev] list comprehensions again... In-Reply-To: Your message of "Tue, 11 Jul 2000 17:09:05 +0200." <20000711181021.G25805@xs4all.nl> References: <20000711181021.G25805@xs4all.nl> Message-ID: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Oops. I was simply mistaken on what the for-for syntax in list comprehensions did! Ideally, list comprehensions should support both parallel and nested for loops, but I'm not sure how to decide to parse them if they both occur. E.g. what is this? [(x,y+z) for x in (1,2,3,4,5,6); for y in "abc" for z in "de"] For me, the semicolon separates much stronger than the for, so (to me) this feels like (applying parentheses to show grouping): (for x); (for y for z) and would yield: [(1, "ad"), (2, "ae"), (3, "bd"), (4, "be"), (5, "cd"), (6, "ce")] But is that the most useful? And how do you write the other grouping? I mean: (for x; for y) (for z) which could yield: [(1, "ad"), (1, "ae"), (2, "bd"), (2, "be"), (3, "cd"), (3, "ce")] A more practical question: if we're going to introduce [::], list comprehensions, and parallel for loops, what would be the best way to introduce the patches so that each patch changes as little as possible of the code introduced by the previous patch? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From dbressler at valinux.com Tue Jul 11 19:03:09 2000 From: dbressler at valinux.com (Dan Bressler) Date: Tue, 11 Jul 2000 10:03:09 -0700 Subject: [Python-Dev] Re: SourceForge References: <20000707133533.E17746@valinux.com> <20000707182448.A31259@thyrsus.com> <39667D29.1A4FB1BB@valinux.com> <20000709214138.I4566@thyrsus.com> <396A4CFC.CEE2419A@valinux.com> <20000710203719.B9793@thyrsus.com> <396A6F7D.66D5F085@valinux.com> <20000710211000.A10068@thyrsus.com> <200007111458.JAA05267@cj20424-a.reston1.va.home.com> Message-ID: <396B534D.3C4A4E3A@valinux.com> If you're going to be in Santa Clara during the day, do you want to stay in the area and meet us in the evening? (Our offices are right in the neighborhood.) Guido van Rossum wrote: > > Dan Bressler : > > > I'm trying to sync schedules -- If we could set it for Tuesday evening, July > > > 18th, that would work best. > > > > OK. Python folks who will be at the Monterey conference; Dan > > Bressler, one of the managers of SourceForge, is amenable to an > > evening meeting with this gang on Tuesday the 18th. I gather Tim > > Purdue, currently the lead programmer on the project, will be there. > > > > The exact time is still to be worked out. Anybody got a proposal? > > I'm not sure what time we'll be arriving in Monterey -- we have our > plane tickets to San Jose and I know we're going to spend Tuesday > daytime at the BeOpen headquarters in Santa Clara, but I don't know > yet what mode of transportation we're going to take to Monterey and at > what time. Given that Dan prefers Tuesday evening I'll try to press > for leaving early enough so that there's some evening left! > > Looking forward to this meeting, > > --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Tue Jul 11 19:09:07 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 13:09:07 -0400 (EDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <20000711121817.J27228@kronos.cnri.reston.va.us> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> <20000711121817.J27228@kronos.cnri.reston.va.us> Message-ID: <14699.21683.305409.97490@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Tue, Jul 11, 2000 at 11:52:05AM -0400, Jeremy Hylton wrote: >obj = poll.new() # generate a new pollfd array >obj.register(f1, POLLIN | POLLOUT) >obj.register(f2, POLLOUT) >obj.poll() >obj.unregister(f2) >obj.poll() AMK> Very interesting, and probably worth doing because all that AMK> list parsing *is* a silly waste of CPU. But could poll still AMK> live in the posixmodule, then, or be a module of its own? [1] The select module has exactly the same problem and could use the same interface. They could both live in their own module. I'm not sure what to call it. Possibilities include: - add it to the current select module - new name, e.g. asyncio, fileevent - call it _asyncore and expose it through the asyncore module Jeremy From gvwilson at nevex.com Tue Jul 11 19:09:11 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 13:09:11 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz Message-ID: I sent the message below to the 11 developers here in the office this morning. They all have 10+ years experience with C, and 2-3 years with C++, Java, or both. None have used Python (I'm working on it :-), but two have extensive Perl experience, and one worked on and with functional languages in grad school. The question was: OK, folks, language question. Given the statement: for x in [10, 20, 30]; y in [1, 2]: print x+y (note that the second list is shorter than the first), would you expect to see: (A) 'x' and 'y' move forward at the same rate: 11 22 (B) 'y' goes through the second list once for each value of 'x': 11 12 21 22 31 32 (C) an error message because the two lists are not the same length? Votes to me, please. Thanks, Greg *Everyone* voted (B). As useful as this capability is, I therefore think the proposed syntax is likely to mislead. Hope it's helpful, Greg From thomas at xs4all.net Tue Jul 11 19:22:03 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 19:22:03 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111752.MAA06413@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 11, 2000 at 12:52:43PM -0500 References: <20000711181021.G25805@xs4all.nl> <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Message-ID: <20000711192202.B7340@xs4all.nl> On Tue, Jul 11, 2000 at 12:52:43PM -0500, Guido van Rossum wrote: > Ideally, list comprehensions should support both parallel and nested > for loops, but I'm not sure how to decide to parse them if they both > occur. E.g. what is this? > > [(x,y+z) for x in (1,2,3,4,5,6); for y in "abc" for z in "de"] Well, listcomprehensions are currently almost a simple rewrite, so this is fairly easy to parse: the ; binds more tightly than the last 'for', and 'for' loops and 'if' branches parse left-to-right without possibilities of 'else'. [..] > But is that the most useful? And how do you write the other grouping? > I mean: > (for x; for y) (for z) > which could yield: > [(1, "ad"), (1, "ae"), (2, "bd"), (2, "be"), (3, "cd"), (3, "ce")] This might be a problem. Also, even providing the 'nested for' in listcomprehensions might be a problem, for exactly the reason you yourself showed: it's not that easy to see what it actually does. Can we get away with not including the nested-for syntax ? I mean, "don't do that then" is something that really appeals to me, and I think it applies here: If you want nested-for loops in creating a list, use a real for loop :P Also, on 4th or 5th pass, I'm still not sure about the whole list comprehensions syntax... I know what problem they are supposed to solve, and I think they succeed in that. But the syntax is pretty ambiguous, and not too pythonic at that. For instance, the endless mixing possibilities of 'for' and 'if' without delimiters or ways to group them can be pretty confusing. Some documentation on that might help, though. Also, it would be nice if list comprehensions could be used to initialize *part* of a list, something like this: ['a', 'b', c for c in ['C', 'D', 'E'], 'f', 'g'] (which would create ['a', 'b', 'C', 'D', 'E', 'f', 'g']) But that creates a legion of other confusalities... Perhaps adding a new/different delimiter to list comprehensions would be a good idea ? :P Disclaimer, though: I didn't follow the list-comprehension discussions on python-list, last year, that closely. I noticed the syntax and thought "that cool.", but that's about it. Was any other syntax proposed ? > A more practical question: if we're going to introduce [::], list > comprehensions, and parallel for loops, what would be the best way to > introduce the patches so that each patch changes as little as possible > of the code introduced by the previous patch? parallel-for-loops -> list comprehensions -> range-literals Unless list comprehensions do not adopt the parallel for loop syntax, in which case the order isn't that important. They don't really touch in that much places, not even the range-literals and list comprehensions patch. The Grammar and a single line in compile.c, if I recall correctly. The rest is just offset and fluff. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Tue Jul 11 20:24:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 13:24:05 -0500 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: Your message of "Tue, 11 Jul 2000 13:09:11 -0400." References: Message-ID: <200007111824.NAA06758@cj20424-a.reston1.va.home.com> > I sent the message below to the 11 developers here in the office this > morning. They all have 10+ years experience with C, and 2-3 years with > C++, Java, or both. None have used Python (I'm working on it :-), but two > have extensive Perl experience, and one worked on and with functional > languages in grad school. The question was: > > OK, folks, language question. Given the statement: > > for x in [10, 20, 30]; y in [1, 2]: > print x+y > > (note that the second list is shorter than the first), would you > expect to see: > > (A) 'x' and 'y' move forward at the same rate: > > 11 > 22 > > (B) 'y' goes through the second list once for each value of 'x': > > 11 > 12 > 21 > 22 > 31 > 32 > > (C) an error message because the two lists are not the same length? > > Votes to me, please. > > Thanks, > Greg > > *Everyone* voted (B). As useful as this capability is, I therefore think > the proposed syntax is likely to mislead. Thanks for user testing! I just wished you had shown it to them with two lists of the same length. That's the normal case, and I believe that the different length must have tricked them into believing that it couldn't possibly be (A). I'd like to run the experiment with that change. Do you have another set of guinea pigs around? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Tue Jul 11 18:07:39 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 11:07:39 -0500 (CDT) Subject: [Python-Dev] once enabled gc won't go away until explicitly disabled? In-Reply-To: <14699.16271.147279.134444@anthem.concentric.net> References: <14699.10639.15423.982767@beluga.mojam.com> <14699.16271.147279.134444@anthem.concentric.net> Message-ID: <14699.17995.992200.367742@beluga.mojam.com> BAW> Yes, although both gc and threads are enabled by default in the BAW> current betas (so you don't need --with-threads). Whether they'll BAW> be enabled for the final release is still TBD. Ah, yes, now I remember. I don't suppose there's any way to coax 'configure --help' into dumping out the default values, is there? I think it would be a very useful feature. Skip From skip at mojam.com Tue Jul 11 18:09:58 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 11:09:58 -0500 (CDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> References: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> Message-ID: <14699.18134.550769.266956@beluga.mojam.com> Fred> At one point, we were discussing having specializations of Fred> SyntaxError, and I posted a patch that defined IndentationError Fred> and TabError. I think you should go for it. As long as they are subclasses of SyntaxError no existing code should break. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From gvwilson at nevex.com Tue Jul 11 20:45:51 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 14:45:51 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007111824.NAA06758@cj20424-a.reston1.va.home.com> Message-ID: [Greg's list comprehension experiment deleted] > Guido: > I just wished you had shown it to them with two lists of the same > length. That's the normal case, and I believe that the different > length must have tricked them into believing that it couldn't possibly > be (A). > I'd like to run the experiment with that change. Do you have another > set of guinea pigs around? Yes, I'll have a roomful of people Thursday morning (practicing my talk for Monterey). If someone would like to rephrase the example, I'd be happy to do a show-of-hands poll. Thanks, Greg From guido at beopen.com Tue Jul 11 22:03:12 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 11 Jul 2000 15:03:12 -0500 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: Your message of "Tue, 11 Jul 2000 14:45:51 -0400." References: Message-ID: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> > Yes, I'll have a roomful of people Thursday morning (practicing my talk > for Monterey). If someone would like to rephrase the example, I'd be > happy to do a show-of-hands poll. Suppose this code: for i in (1, 2, 3): print i prints this: 1 2 3 What do you think the following code would print? for i in (10, 20, 30); j in (1, 2, 3): print i+j A. 11 22 33 B. 11 12 13 21 22 23 31 32 33 I'm afraid the answer will be the same, if these are again numerical analysts -- these people live by nested DO loops. :-( --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Tue Jul 11 19:38:23 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 12:38:23 -0500 (CDT) Subject: [Python-Dev] patch assignments? Message-ID: <14699.23439.483525.515059@beluga.mojam.com> I just noticed a patch assignment made to me on June 30th: http://sourceforge.net/patch/?func=detailpatch&patch_id=100688&group_id=5470 with a comment from Tim on July 10th about it having been assigned to me. In the flood of patch submissions and updates I guess I missed this. The SF patch change mails say *nothing* as far as I can tell about what the nature of the change of status of a patch is. With all changes going through the patches mailing list, more interesting stuff can get lost in the sea of stuff I'm not particularly interested in. Consequently, I would have hit 'd' seeing a subject like "Add 'isatty(fd)' to posixmodule". Has anyone asked SF for a more complete patch mailing? If not, I will probably unsubscribe from patches at python.org so I can be assured that those notices I get are actually for me. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From pingster at ilm.com Tue Jul 11 21:11:58 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 12:11:58 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> Message-ID: On Tue, 11 Jul 2000, Greg Ewing wrote: > Thomas> '[' [testlist [list_iter]] ']' > Thomas> Should that really be 'testlist'? > [...] > if it were changed I expect > you'd get complaints that things like > > [x,y for x in (1,2,3) for y in (4,5,6)] Well, i imagine this would yield [x, 4, 5, 6, 4, 5, 6, 4, 5, 6] right? I think i vote for "produce parens only if i write parens". Hmm, another question. When someone writes: [x, y for x in 1, 2, 3 for y in 4, 5, 6] ...what should they get? (a) SyntaxError (b) [(1, 4), (1, 5), (1, 6), (2, 4), (2, 5), (2, 6), (3, 4), (3, 5), (3, 6)] (c) [x, 4, 5, 6, 4, 5, 6, 4, 5, 6] (d) [x, y, 2, 3, 5, 6] If we go with above rule of "produce parens only if i write parens", then the answer has to be (d). That is, commas bind last in a list (which seems consistent with normal practice...). Does this make sense or seem confusing to you? If it's too confusing, we can choose (a) and require that the first part of a list comprehension has to be a single test. -- ?!ng From pingster at ilm.com Tue Jul 11 21:15:26 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 12:15:26 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: Message-ID: On Tue, 11 Jul 2000, Greg Wilson wrote: > (either now or in future). Would it also permit: > > [{x:y} for x in (1,2,3) for y in (4,5,6)] > > i.e. dict construction using list comprehension? I'd use this in quite a > few places. The above would produce [{1: 4}, {1: 5}, {1: 6}, {2: 4}, {2: 5}, {2: 6}, {3: 4}, {3: 5}, {3: 6}] If, on the other hand, you tried to make a single dictionary with {x: y for x in (1, 2, 3) for y in (4, 5, 6)} it doesn't make a lot of sense (multiple y's for the same x?). The only thing i could imagine it producing, perhaps, is {1: 6, 2: 6, 3: 6} -- ?!ng From bwarsaw at beopen.com Tue Jul 11 21:29:43 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 15:29:43 -0400 (EDT) Subject: [Python-Dev] Memory leak tracking Message-ID: <14699.30119.262274.258429@anthem.concentric.net> Folks, I've been doing a fair bit of Purify-cation on the Python source tree. Things are looking pretty good in general, but I have a question for you all. When I compile out gc, I get more leaks in the core, namely in exceptions.c. Turning on gc clears all of these up; e.g. all the memory gets freed eventually. My suspicion therefore is that there are a number of cycles created during the initialization of the built-in exceptions. How important is it to fix these problems when gc is disabled? It's not a lot of memory (like <5000 bytes or so for running one of the regr tests) and it'll take some time to track them down and figure out what the right fix is. Given everything all the other more interesting work to do, it doesn't seem worth it. So far we haven't seen any showstopping gc bugs reported yet, so I'm hopeful it'll remain enabled by default in 2.0. Please let me know what you think. If the concensus is to fix them, I keep working on them. I do still plan on looking at the few memory problems still left even with gc turned on. -Barry From pingster at ilm.com Tue Jul 11 21:26:54 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 12:26:54 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 11 Jul 2000, Guido van Rossum wrote: > [(x,y+z) for x in (1,2,3,4,5,6); for y in "abc" for z in "de"] > > For me, the semicolon separates much stronger than the for, so (to me) > this feels like (applying parentheses to show grouping): > > (for x); (for y for z) When written like the above, i agree that the semicolon separates more strongly. Perhaps we should rearrange the syntax to make the semicolon more interior? This also addresses Greg's poll: > > for x in [10, 20, 30]; y in [1, 2]: > print x+y [...] > *Everyone* voted (B). How about writing this as: for x; y in [10, 20, 30]; [1, 2]: print x + y > And how do you write the other grouping? As a result, this provides a way to write parallel loops within list comprehensions, although it might not be very clear until you're familiar with the way it's written above. At least it's possible: [(x, y+z) for x; y in (1, 2, 3, 4, 5, 6); "abc" for z in "de"] If colons were introduced, would that help keep things clear? [(x, y+z): for x; y in (1, 2, 3, 4, 5, 6); "abc": for z in "de"] This would then be directly reminiscent of for x; y in (1, 2, 3, 4, 5, 6); "abc": for z in "de": list.append((x, y+z)) which provides the appropriate meaning. I don't like extra punctuation, but i'm not sure what else to do here since "for" alone is a very weak separator. -- ?!ng From pingster at ilm.com Tue Jul 11 21:40:22 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 12:40:22 -0700 (PDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: Message-ID: On Tue, 11 Jul 2000, Greg Wilson wrote: > for x in [10, 20, 30]; y in [1, 2]: > print x+y [...] > (A) 'x' and 'y' move forward at the same rate: > (B) 'y' goes through the second list once for each value of 'x': > (C) an error message because the two lists are not the same length? [...] > *Everyone* voted (B). Okay, i just thought of another answer to this. Scream at me if you find this hideous. for x in [10, 20, 30] while y in [1, 2]: print x+y My previous message proposed colons to separate the clauses of a list comprehension, which i now realize makes dict comprehensions impossible (or at least a little strange-looking). If we use "while", the lack of semicolons means that we can do parallel loops in list-comps without colons, which in turn enables dict-comps. -- ?!ng From thomas at xs4all.net Tue Jul 11 21:51:00 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 21:51:00 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from pingster@ilm.com on Tue, Jul 11, 2000 at 12:26:54PM -0700 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Message-ID: <20000711215100.C7340@xs4all.nl> On Tue, Jul 11, 2000 at 12:26:54PM -0700, Ka-Ping Yee wrote: > This would then be directly reminiscent of > > for x; y in (1, 2, 3, 4, 5, 6); "abc": > for z in "de": > list.append((x, y+z)) > > which provides the appropriate meaning. > I don't like extra punctuation, but i'm not sure what else to do > here since "for" alone is a very weak separator. Agreed, though I think ';' is the wrong punctuation for this... It's always been a statement-seperator, and now it's used to seperate parts of a statement, like a normal comma. I still think 'for x in a; y in b' is better than this, but I'm not sure how to liase it with list comprehensions' "nested for". But then, I'm not sure about any of the list comp syntax right now :-) To paraphrase Guido, I got myself in quite a mess ;-) Anyone object if I pull this discussion into c.l.py ? I'm not sure if any new ideas pop up, but it might give some more data to work with ;-P And I don't think any of this is urgent in any way, I doubt anything more will get done until after ORA OSCON, anyway. And maybe some of you guys that are actually going there can discuss it face to face ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw at beopen.com Tue Jul 11 21:54:16 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 15:54:16 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> Message-ID: <14699.31592.410628.754071@anthem.concentric.net> Sorry, but I'm being to think that both the list comprehensions and parallel for loops are looking pretty dodgy. I wonder what newbies are going to think when they see this stuff? If the semantics aren't obvious to us, they definitely will not be to them. Range literals I can see as being worth it. I wonder if parallel for loops can't be handled more gracefully with a function -- isn't it just a nice wrapper around a specific call to map() anyway? List comprehensions do seem to need more syntactic support, but the ambiguity of the semantics bothers me. monkey-wretched-ly y'rs, -Barry From gvwilson at nevex.com Tue Jul 11 21:59:52 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 15:59:52 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711215100.C7340@xs4all.nl> Message-ID: > Thomas wrote: > Anyone object if I pull this discussion into c.l.py? Rather than asking for suggestions, would it make sense to prepare one or more examples of multi-loops and output, then ask people to vote on which ones they would expect to match up with which? Likely to be lower bandwidth, and it'd be an interesting experiment in language design procedures in its own right :-). Greg From fdrake at beopen.com Tue Jul 11 22:11:54 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 16:11:54 -0400 (EDT) Subject: [Python-Dev] Showing stale locks under cvsweb Message-ID: <14699.32650.73594.921249@cj42289-a.reston1.va.home.com> I've just received a response to my "bug report" at SourceForge about stale locks needing to be visible in cvsweb. They categorized it as "Irrelevant" and said the cvsweb people were the ones to contact (seems reasonable; now I know that there *are* cvsweb people!). I've found the right people and sent a note to them, with a copy to Greg Stein as well, noting that ViewCVS should support a similar feature. I'll let everyone know what happens regarding this if/when I get a response. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Tue Jul 11 22:20:36 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 16:20:36 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> References: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> Message-ID: <14699.33172.319800.354377@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> I'm afraid the answer will be the same, if these are again GvR> numerical analysts -- these people live by nested DO loops. :-( If we end up calling this new feature list comprehensions, we might create the expectation that they behave like list comprehensions in other languages. Haskell is one language with comprehensions and they behave the way that the numerical analysts expect them to behave. Maybe we should chalk it up to numerical analysts and funtional programmers being weird, but they may be on to something. Here's a short excerpt from the Gentle Introduction to Haskell: http://www.haskell.org/tutorial/goodies.html (Sec. 2.4.1) >[ f x | x <- xs ] >This expression can intuitively be read as "the list of all f x such >that x is drawn from xs." The similarity to set notation is not a >coincidence. The phrase x <- xs is called a generator, of which more >than one is allowed, as in: > >[ (x,y) | x <- xs, y <- ys ] > >This list comprehension forms the cartesian product of the two lists >xs and ys. The elements are selected as if the generators were >"nested" from left to right (with the rightmost generator varying >fastest); thus, if xs is [1,2] and ys is [3,4], the result is >[(1,3),(1,4),(2,3),(2,4)]. Jeremy From rushing at nightmare.com Tue Jul 11 22:26:53 2000 From: rushing at nightmare.com (Sam Rushing) Date: Tue, 11 Jul 2000 13:26:53 -0700 (PDT) Subject: [Python-Dev] Adding poll() system call In-Reply-To: <26950820@toto.iv> Message-ID: <14699.33549.656358.89869@seattle.nightmare.com> Andrew Kuchling writes: > (At the very highest end, even poll() begins to scale badly since you > list "all the open fds", not "all the open fds which have activity". > At that point you're supposed to switch to async I/O, but probably > you'd have switched from Python to C long before that point.) Lots of good info on these issues is available here: http://www.kegel.com/c10k.html Linux and FreeBSD are growing new kernel-event-delivery mechanisms that promise better scalability and efficiency. Win32's had it from the beginning. For the eGroups coroutine scheduler ( http://www.egroups.com/group/python-coro ) I wrote a more efficient poll wrapper, but it's also very bare. Might be a starting point. This stuff hasn't been used yet, so the driver module has fallen way behind. Compare coro2.py to 'coro.py' in the egroups coro dist. http://www.nightmare.com/stuff/coro_poll.c http://www.nightmare.com/stuff/coro2.py In coro_poll.c, there's a single struct pollfd array, that should probably be PyObject-ified. -Sam From klm at digicool.com Tue Jul 11 22:33:01 2000 From: klm at digicool.com (Ken Manheimer) Date: Tue, 11 Jul 2000 16:33:01 -0400 (EDT) Subject: [Python-Dev] Objects/ ANSI-fied In-Reply-To: <200007092153.QAA14165@cj20424-a.reston1.va.home.com> Message-ID: On Sun, 9 Jul 2000, Guido van Rossum wrote: > > Ok, the Objects/ directory has been ANSI-fied, and I've noticed /F > > slaving away in the Modules/ directory, so I'll get out of the way for > > a little bit. ;) > > Great! Sounds like everybody is getting the hint that 2.0 needs to > have some distinguishing characteristics compared to 1.6... :-) Hmm. I just realized an interesting take on 2.0's "distinguishing features". Check out the volume of python-dev traffic - reflecting what's to me, at least, incredibly high pace and high fiber collaboration. Python 2.0 could be about a new process, as much as it is about the license policy changes that better enable it, or the productivity it seems to be promoting. (I'm not silly enough to suggest that the version change could happen solely on the basis of a new process - there really do seem to be genuine results, here...) (And if BeOpen happens to be looking for a product, and you can bottle this, they might like to have it.-) Seriously, maybe BeOpen should concentrate on helping teams to better employ available resources - look at how good they're doing with you guys. Well, ok, what they're doing right is leaving you guys mostly alone - maybe your payoff for them would be to clue them into what works, and they can do some work to deliver it to others. Might could help you all, too, in solidifying what's going on...) Ken klm at digicool.com From paul at prescod.net Tue Jul 11 22:44:06 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 15:44:06 -0500 Subject: [Python-Dev] list comprehensions again... References: Message-ID: <396B8716.C1C9EE3C@prescod.net> I'm sorry to muddy the waters, but perhaps a solution is to try and stay as close to regular Python syntax as possible. I am thinking of a nested comprehension as a regular nested for-loop that has an expression rather than a suite as its body: Nested (List): [for x in (0,10,20,30): for y in (0,1,2,3): x+y] [0,11,22,33] Parallel (Tuple): (for x in (0,10,20,30) and y in (0,1,2,3): x+y) (0,11,22,33) Parallel (Dict): {for x in (0,10,20,30) and y in range (0,1,2,3): x,y} The dict one needs a little explaining. A dict comprehension is a comprehension where the delimiters are curly braces and the generated items are required to be pairs. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From thomas at xs4all.net Tue Jul 11 22:47:49 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 22:47:49 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from gvwilson@nevex.com on Tue, Jul 11, 2000 at 03:59:52PM -0400 References: <20000711215100.C7340@xs4all.nl> Message-ID: <20000711224749.C7345@xs4all.nl> On Tue, Jul 11, 2000 at 03:59:52PM -0400, Greg Wilson wrote: > > Thomas wrote: > > Anyone object if I pull this discussion into c.l.py? > Rather than asking for suggestions, would it make sense to prepare one or > more examples of multi-loops and output, then ask people to vote on which > ones they would expect to match up with which? Likely to be lower > bandwidth, and it'd be an interesting experiment in language design > procedures in its own right :-). That's exactly what I had in mind, yes ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Tue Jul 11 22:49:44 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 15:49:44 -0500 Subject: [Python-Dev] list comprehensions again... References: <396B8716.C1C9EE3C@prescod.net> Message-ID: <396B8868.B58F3F0C@prescod.net> Paul Prescod wrote: > > ... > (for x in (0,10,20,30) and y in (0,1,2,3): > x+y) > (0,11,22,33) Sorry, replace the "and" with ";" or "while" to resolve the ambiguity: Nested (List): [for x in (0,10,20,30): for y in (0,1,2,3): x+y] [0,11,22,33] Parallel (Tuple): (for x in (0,10,20,30) ; y in (0,1,2,3): x+y) (0,11,22,33) Parallel (Dict): {for x in (0,10,20,30) ; y in range (0,1,2,3): x,y} -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Tue Jul 11 23:16:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 11 Jul 2000 23:16:42 +0200 Subject: [Python-Dev] Problems with the new unicodectype.c References: Message-ID: <021201bfeb7d$515c3520$f2a6b5d4@hagrid> tim wrote: > I believe we also need a way to split unicodedatabase.c into multiple files, > as > 64K lines in a source file is unreasonable (Python can't handle a > source file that large either, and Python is the *definition* of > reasonableness here ), and the MS compiler spits out a warning about > its sheer size. just a heads-up: I've been hacking a little on a new unicode database. the results this far are quite promising: CTYPE: is*, to* functions 118k => 13k CNAME: code <=> name mappings (\N{name}) 440k => 160k CINFO: remaining unicode properties 590k => 42k (approximate code size with the old and new code, on Windows) on the source side, 3300k source files are replaced with about 600k (generated by a script, directly from the uni- code.txt data file). note that the CNAME and CINFO parts are optional; you only need CTYPE to build a working Python interpreter. integrating this with 2.0 should be relatively straightforward, but don't expect it to happen before next week or so... cheers /F From fdrake at beopen.com Tue Jul 11 23:20:38 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 17:20:38 -0400 (EDT) Subject: [Python-Dev] O'Reilly conference Message-ID: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> So who's going to the O'Reilly conference next week? The PythonLabs crew expects to be there, and we just might have some goodies. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pingster at ilm.com Tue Jul 11 23:31:24 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 14:31:24 -0700 (PDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 11 Jul 2000, Guido van Rossum wrote: > What do you think the following code would print? > > for i in (10, 20, 30); j in (1, 2, 3): > print i+j [...] > I'm afraid the answer will be the same, if these are again numerical > analysts -- these people live by nested DO loops. :-( What do you think the answer would be for for i; j in (10, 20, 30); (1, 2, 3): print i+j ? Would you consider posing this question? -- ?!ng From effbot at telia.com Tue Jul 11 23:39:22 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 11 Jul 2000 23:39:22 +0200 Subject: [Python-Dev] O'Reilly conference References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <025201bfeb80$829976e0$f2a6b5d4@hagrid> fred wrote: > So who's going to the O'Reilly conference next week? Portions of the Secret Labs crew expects to be there, and they just might have some goodies. ;) cheers /F From DavidA at ActiveState.com Tue Jul 11 23:48:52 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 11 Jul 2000 14:48:52 -0700 (Pacific Daylight Time) Subject: [Python-Dev] O'Reilly conference In-Reply-To: <025201bfeb80$829976e0$f2a6b5d4@hagrid> Message-ID: On Tue, 11 Jul 2000, Fredrik Lundh wrote: > fred wrote: > > > So who's going to the O'Reilly conference next week? A bunch of ActiveState folks, naturally. We'll have an _early_ demo of Komodo and friends, will be recruiting, etc. If anyone wants to guarantee that they talk to me about anything, it's best to let me know early. --david PS: Anyone who'se going w/ young kids who might want to do fun things w/ mine (& my wife =) should let me know. It's easier to deal w/ lots of kids than w/ a few, somehow... Andy Robinson's family will be there. From thomas at xs4all.net Tue Jul 11 23:47:38 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 23:47:38 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.31592.410628.754071@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Jul 11, 2000 at 03:54:16PM -0400 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> Message-ID: <20000711234737.D7340@xs4all.nl> On Tue, Jul 11, 2000 at 03:54:16PM -0400, Barry A. Warsaw wrote: > Sorry, but I'm being to think that both the list comprehensions and > parallel for loops are looking pretty dodgy. I wonder what newbies > are going to think when they see this stuff? If the semantics aren't > obvious to us, they definitely will not be to them. > Range literals I can see as being worth it. I wonder if parallel for > loops can't be handled more gracefully with a function -- isn't it > just a nice wrapper around a specific call to map() anyway? Well, not really. It doesn't create a new list, only a tuple to hold lists to iter over (in order to pass it to the opcode as a single PyObject) and similar for the resulting objects. It's definately more efficient than the map() solution (and different, see below ;) I agree that all this together looks dodgy, but I think there is a simple way to view it... I still think 'for x in a; y in b:' is the right syntax for parallel for loops. It's almost "only" syntactic sugar for 'for x,y in map(None, a, b)' but it's fairly straightforward, and in large blocks of code it might look a lot better. It also has the benifit of not padding the shortest list to the size of the longest one: getting that behaviour with a map requires an aditional 'filter' or such. Whether it does or doesn't do what people actually expect I don't know, but with all due respect to Greg for doing the usability test, I don't think it carries that much meaning: We should be testing Python newbies, not people who haven't tried Python at all, yet. Unfortunately, I don't have such a batch at hand either ;) (My colleagues either refuse to learn Python, or haven't stayed newbie for more than a few hours :-) Given that you can already do the nested-for-loop with a nested for loop, and it doesn't suffer (much) in way of readability or pythonity, I think most people will realize that the parallel for loop does actually do a parallel for-each. A number of Python features, like (the lack of) nested namespaces and the way assignment works, seem counter-intuitive (or at least lesser-intuitive) at first, but there simply isn't a better way to handle them and maintain Python's simplicity. I think this is one of those cases. Note that this doesn't include list comprehensions ! I find the syntax confusing myself, but it doesn't look like we can fix it by stealing the best syntax of parallel-for loops for it ;) Also, list comprehensions don't add *that* much. They provide an easier way to create a list, but they don't eradicate the need for map, reduce or filter, because there is no way to comprehend an already created list. I like Paul's proposal that makes list comprehensions look more like normal 'for' loops, requiring indentation and all, but I'm not sure if they're going to work... This definately requires more thought ;-) I think I'll post a (very) short summary of the entire discussion and some examples for people to vote about, and perhaps express their opinion, on c.l.py. Sometime tomorrow ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm at hypernet.com Tue Jul 11 23:47:56 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 11 Jul 2000 17:47:56 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.31592.410628.754071@anthem.concentric.net> Message-ID: <1248770416-32799859@hypernet.com> Barry A. Warsaw wrote: > Sorry, but I'm being to think that both the list comprehensions > and parallel for loops are looking pretty dodgy. I'm with Barry here (despite the public humiliation the association involves). My expectations (from examples) correlates to accompanying explanations no better than random choice. I *thought* I liked Greg Ewing's original proposal, but at this point I see syntactic salts of ammonia around one very clear idiom (nested fors) and one less intuitive but unambiguous idiom (map). I like the set notation, but there's a big impedance mismatch to Python. I'd be tempted to spell "cartesian product" as a product. To put it another way: - syntactic sugar for nested "for" loops would be nice, but there's no crying need for it - the current spelling of parallel loops is awkward and probably does warrant syntactic sugar (despite Greg Wilson's experiment that it's not what's expected). If list comprehensions are going to do *both*, the difference in how they're spelled will have to be obvious and intuitive, or we might as well just keep explaining how to use map. - Gordon From gstein at lyra.org Tue Jul 11 23:53:29 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 14:53:29 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from pingster@ilm.com on Tue, Jul 11, 2000 at 12:11:58PM -0700 References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> Message-ID: <20000711145329.T29590@lyra.org> On Tue, Jul 11, 2000 at 12:11:58PM -0700, Ka-Ping Yee wrote: >... > Does this make sense or seem confusing to you? > > If it's too confusing, we can choose (a) and require that the first > part of a list comprehension has to be a single test. If it is too confusing, then drop the darn feature. We're adding syntax that is sure to make Python programs a lot less readable when they are used. People will always say "now, what exactly does that do?" Adding new, complex features does not equate with positive forward progress. This whole notion of list comprehensions seems rather dubious, especially given the wildly varying ideas of what the different syntaxes mean. Sure, maybe we can decide on what it *should* mean, but people will continue to be confused by what they *think* it would mean. Drop the dumb thing altogether. What's the motivation? Bleh. -1 Cheers, -g -- Greg Stein, http://www.lyra.org/ From thomas at xs4all.net Tue Jul 11 23:54:01 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 11 Jul 2000 23:54:01 +0200 Subject: [Python-Dev] O'Reilly conference In-Reply-To: <025201bfeb80$829976e0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jul 11, 2000 at 11:39:22PM +0200 References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> <025201bfeb80$829976e0$f2a6b5d4@hagrid> Message-ID: <20000711235401.E7340@xs4all.nl> On Tue, Jul 11, 2000 at 11:39:22PM +0200, Fredrik Lundh wrote: > fred wrote: > > So who's going to the O'Reilly conference next week? > Portions of the Secret Labs crew expects to be there, and > they just might have some goodies. ;) Goodies!? Argh! Can I send a colleague over to gather some of the goodies for me ? I'm not important enough to go to OSCON, only our resident Perl guru is... But we'd need him back or our company stops functioning, so I'll only send him over if you promise not to hurt him :) Otherwise, I'll have to stay Python-goodieless until the next IPC... -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw at beopen.com Tue Jul 11 23:55:56 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 17:55:56 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> Message-ID: <14699.38892.155046.60218@anthem.concentric.net> >>>>> "Gordo" == Gordon McMillan writes: Gordo> I'm with Barry here (despite the public humiliation the Gordo> association involves). For both of us, of course. :) -Barry From jack at oratrix.nl Tue Jul 11 23:55:12 2000 From: jack at oratrix.nl (Jack Jansen) Date: Tue, 11 Jul 2000 23:55:12 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Message by "James C. Ahlstrom" , Mon, 10 Jul 2000 12:43:03 -0400 , <3969FD17.487DA96A@interet.com> Message-ID: <20000711215517.E9C71E2673@oratrix.oratrix.nl> Excuse my ignorance, but isn't the whole problem that the python 1.6 DLL is in the system search path even when you are running Python 1.7? MacPython solves this problem by keeping the PythonCore dll in the application directory, so it'll be found by a Python executable in the same directory but not by a python executable living elsewhere. And even if you import a dynamic module that was meant for and older or newer version of Python you'll get a decent error message: because all PythonCore's have the same name the imported module will link against the one already loaded and complain bitterly about missing externals (all assuming the current PythonCore and the module aren't compatible). This is a bit of a simplification, because MacOS doesn't really use the dll filename for matching the library, and there are extreme cases where you can end up with two PythonCore's in one process (but they don't happen to the average user), but this is the general idea.... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From gstein at lyra.org Wed Jul 12 00:03:11 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 15:03:11 -0700 Subject: [Python-Dev] O'Reilly conference In-Reply-To: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jul 11, 2000 at 05:20:38PM -0400 References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <20000711150311.V29590@lyra.org> On Tue, Jul 11, 2000 at 05:20:38PM -0400, Fred L. Drake, Jr. wrote: > > So who's going to the O'Reilly conference next week? The PythonLabs > crew expects to be there, and we just might have some goodies. ;) I'll be there Tue, Wed, Thu. Cheers, -g -- Greg Stein, http://www.lyra.org/ From pingster at ilm.com Wed Jul 12 00:02:17 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 15:02:17 -0700 (PDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <14699.33172.319800.354377@bitdiddle.concentric.net> Message-ID: On Tue, 11 Jul 2000, Jeremy Hylton wrote: > If we end up calling this new feature list comprehensions, we might > create the expectation that they behave like list comprehensions in > other languages. Good point. > >[ f x | x <- xs ] [...] > >[ (x,y) | x <- xs, y <- ys ] The closest translations for these i can imagine are [ f(x), for x in xs ] [ (x,y), for x in xs, for y in ys ] I'd say the above has to be about my favourite for ease of reading. I think the following grammar would work: listmaker: test [',' (list_iter | [test (',' test)* [',']])] list_iter: list_for | list_if list_for: 'for' exprlist 'in' testlist [',' list_iter] list_if: 'if' test [',' list_iter] -- ?!ng From paul at prescod.net Wed Jul 12 00:11:29 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 17:11:29 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> Message-ID: <396B9B91.E33D8C58@prescod.net> Thomas Wouters wrote: > > .... They provide an easier way to create a list, but they don't > eradicate the need for map, reduce or filter, because there is no way to > comprehend an already created list. What do you mean? I think I see examples of list comprehensions working on existing lists on this page: http://www.cosc.canterbury.ac.nz/~greg/python/listcomp/ numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] evens = [x for x in numbers if x % 2 == 0] # filter mult3 = [3 * x for x in numbers] # map Reduce is somewhat of a different beast... -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gstein at lyra.org Wed Jul 12 00:29:52 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 15:29:52 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.38892.155046.60218@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Jul 11, 2000 at 05:55:56PM -0400 References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> <14699.38892.155046.60218@anthem.concentric.net> Message-ID: <20000711152951.X29590@lyra.org> On Tue, Jul 11, 2000 at 05:55:56PM -0400, Barry A. Warsaw wrote: > > >>>>> "Gordo" == Gordon McMillan writes: > > Gordo> I'm with Barry here (despite the public humiliation the > Gordo> association involves). > > For both of us, of course. :) Looks like all of us scrappy long-hairs are in this together. :-) As I posted in another note: this stuff introduces too much confusion and unknowns, for a small benefit. Create parallel() or product() or whatever to munge the lists. Not new syntax. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Wed Jul 12 00:30:46 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 15:30:46 -0700 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <20000711215517.E9C71E2673@oratrix.oratrix.nl>; from jack@oratrix.nl on Tue, Jul 11, 2000 at 11:55:12PM +0200 References: <20000711215517.E9C71E2673@oratrix.oratrix.nl> Message-ID: <20000711153046.Y29590@lyra.org> On Tue, Jul 11, 2000 at 11:55:12PM +0200, Jack Jansen wrote: > Excuse my ignorance, but isn't the whole problem that the python 1.6 > DLL is in the system search path even when you are running Python 1.7? Yes, and as has been discussed endlessly before: it needs to be there. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Wed Jul 12 00:26:12 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 11 Jul 2000 18:26:12 -0400 Subject: [Python-Dev] patch assignments? In-Reply-To: <14699.23439.483525.515059@beluga.mojam.com> Message-ID: [Skip Montanaro] > I just noticed a patch assignment made to me on June 30th: > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100688&group_id=5470 > > with a comment from Tim on July 10th about it having been assigned to me. Correction: My comment was made on July 9th, which is also the day it got assigned to you (look at the topmost line of the Patch History section at the bottom). This is one of those patches that had just sat there since June 30th without anyone picking it up. On July 9th I went thru those and assigned (most of) them "at random". > In the flood of patch submissions and updates I guess I missed > this. Na, you noticed it within 48 hours > > The SF patch change mails say *nothing* as far as I can tell about what > the nature of the change of status of a patch is. That's right. It sucks. Best clue is whether you're *explicitly* listed on the "To" line. > With all changes going through the patches mailing list, more interesting > stuff can get lost in the sea of stuff I'm not particularly interested in. > Consequently, I would have hit 'd' seeing a subject like "Add 'isatty(fd)' > to posixmodule". I hit 'd' (well, my mailer's equivalent) for almost all patch mail coming from SF. Feel free to do the same! What I suggest instead: if you're a Python developer on SF, patches *will* eventually get assigned to you. So log on at least once a week, and view the patches filtering on your "Unix name" via the "User" dropdown list. Then you'll know exactly what's on your plate. And if you're not going to do it, take yourself off. Do the latter too often, though, and you'll probably get threatening email from Guido . > Has anyone asked SF for a more complete patch mailing? Dunno, but there's some hope we can discuss this w/ them in person in CA next week. The SF patch manager has more problems than just that for a project with as many active developers as Python. > If not, I will probably unsubscribe from patches at python.org so I can be > assured that those notices I get are actually for me. I wouldn't hold my breath waiting for large changes to SF's software. From jack at oratrix.nl Wed Jul 12 00:30:57 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 00:30:57 +0200 Subject: [Python-Dev] More Symantec symbols In-Reply-To: Message by Skip Montanaro , Mon, 10 Jul 2000 21:48:42 -0500 (CDT) , <14698.35594.999203.707698@beluga.mojam.com> Message-ID: <20000711223102.84CA0E2673@oratrix.oratrix.nl> Recently, Skip Montanaro said: > > Picking up where the __SC__ thread left off, I noticed the following other > Symantec symbols in the Python sources just now: > > ./Include/Python.h:48:#ifdef SYMANTEC__CFM68K__ > [...] > Should these be zapped as well or is this something wholely unrelated to the > old Symantec compiler issue? Yes, go ahead and zap them. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paul at prescod.net Wed Jul 12 00:48:05 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 17:48:05 -0500 Subject: [Python-Dev] list comprehensions again... References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> <14699.38892.155046.60218@anthem.concentric.net> <20000711152951.X29590@lyra.org> Message-ID: <396BA425.2EF3B11F@prescod.net> Greg Stein wrote: > > Looks like all of us scrappy long-hairs are in this together. :-) > > As I posted in another note: this stuff introduces too much confusion and > unknowns, for a small benefit. Create parallel() or product() or whatever to > munge the lists. Not new syntax. Parallel iteration and list comprehensions are separate. I do prefer a parallel() (merge?) builtin to the semicolon syntax, myself. You could even define xparallel which is the lazy version (as in xrange). There's no way you are going to invent functions that do everything that list comprehensions do, however. And compared to map and filter, list comprehensions are positively crystal clear. Would it help to think of list comprehensions not so much as a vote for a new idea as a vote AGAINST lambda, map and filter? numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] mult3 = [3 * x for x in numbers] evens = [x for x in numbers if x % 2 == 0] numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] mult3 = map( lambda x: 3 * x, numbers) evens = filter( lambda x: x%2==0, numbers) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From bwarsaw at beopen.com Wed Jul 12 01:02:06 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 19:02:06 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> Message-ID: <14699.42862.320480.372351@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> I agree that all this together looks dodgy, but I think there TW> is a simple way to view it... I still think TW> 'for x in a; y in b:' TW> is the right syntax for parallel for loops. It's almost "only" TW> syntactic sugar for TW> 'for x,y in map(None, a, b)' But wouldn't some variation on for x, y in a, b: invoke resonance with the classic idiom? Okay, now I'm reduced to arguing syntax (and syntax which I haven't thought out much :). TW> but it's fairly straightforward, and in large blocks of code TW> it might look a lot better. It also has the benifit of not TW> padding the shortest list to the size of the longest one: TW> getting that behaviour with a map requires an aditional TW> 'filter' or such. So I guess if that's the behavior I want, I'd use map, right? There's probably no good way to spell both. -Barry From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 01:35:54 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 01:35:54 +0200 (CEST) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.18899.148734.462266@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jul 11, 2000 12:22:43 PM Message-ID: <200007112335.BAA23181@python.inrialpes.fr> Fred L. Drake, Jr. wrote: > > I've attached a combined patch, in case any is interested. This > does not include updated documentation, and could use additional > tests. +1. Go ahaid. I'd make TabError -> TabSpaceError (like the C preprocessor symbol) though. > + static char > + TabError__doc__[] = "Improper mixture of spaces and tabs."; TabSpaceError__doc__[] = "Improper mixture of tabs and spaces."; -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Wed Jul 12 01:54:06 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 16:54:06 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.42862.320480.372351@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Jul 11, 2000 at 07:02:06PM -0400 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> <14699.42862.320480.372351@anthem.concentric.net> Message-ID: <20000711165406.A29590@lyra.org> On Tue, Jul 11, 2000 at 07:02:06PM -0400, Barry A. Warsaw wrote: > > >>>>> "TW" == Thomas Wouters writes: > > TW> I agree that all this together looks dodgy, but I think there > TW> is a simple way to view it... I still think > > TW> 'for x in a; y in b:' > > TW> is the right syntax for parallel for loops. It's almost "only" > TW> syntactic sugar for > > TW> 'for x,y in map(None, a, b)' > > But wouldn't some variation on > > for x, y in a, b: > > invoke resonance with the classic idiom? Okay, now I'm reduced to > arguing syntax (and syntax which I haven't thought out much :). for x, y in a, b: won't work. "a, b" is a tuple constructor. The for-loop will iterate over a two-item tuple, and unpack each item (a and b) into the x,y variables. Try again or punt :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From skip at mojam.com Wed Jul 12 00:28:04 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 17:28:04 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.31592.410628.754071@anthem.concentric.net> References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> Message-ID: <14699.40820.255217.346654@beluga.mojam.com> BAW> Range literals I can see as being worth it. I wonder if parallel BAW> for loops can't be handled more gracefully with a function -- isn't BAW> it just a nice wrapper around a specific call to map() anyway? I believe Thomas proposed range literals to avoid calling the range() function... Regarding a wrapper around map(), you will need a pretty hairy wrapper, since you can do some pretty complex things with Greg's version of list comprehensions. Here's the list comprehensions code from test_grammar.py: nums = [1, 2, 3, 4, 5] strs = ["Apple", "Banana", "Coconut"] spcs = [" Apple", " Banana ", "Coco nut "] print [s.strip() for s in spcs] print [3 * x for x in nums] print [x for x in nums if x > 2] print [i, s for i in nums for s in strs] print [i, s for i in nums for s in [f for f in strs if "n" in f]] suppliers = [ (1, "Boeing"), (2, "Ford"), (3, "Macdonalds") ] parts = [ (10, "Airliner"), (20, "Engine"), (30, "Cheeseburger") ] suppart = [ (1, 10), (1, 20), (2, 20), (3, 30) ] print [ (sname, pname) for (sno, sname) in suppliers for (pno, pname) in parts for (sp_sno, sp_pno) in suppart if sno == sp_sno and pno == sp_pno ] and what it produces: ['Apple', 'Banana', 'Coco nut'] [3, 6, 9, 12, 15] [3, 4, 5] [(1, 'Apple'), (1, 'Banana'), (1, 'Coconut'), (2, 'Apple'), (2, 'Banana'), (2, 'Coconut'), (3, 'Apple'), (3, 'Banana'), (3, 'Coconut'), (4, 'Apple'), (4, 'Banana'), (4, 'Coconut'), (5, 'Apple'), (5, 'Banana'), (5, 'Coconut')] [(1, 'Banana'), (1, 'Coconut'), (2, 'Banana'), (2, 'Coconut'), (3, 'Banana'), (3, 'Coconut'), (4, 'Banana'), (4, 'Coconut'), (5, 'Banana'), (5, 'Coconut')] [('Boeing', 'Airliner'), ('Boeing', 'Engine'), ('Ford', 'Engine'), ('Macdonalds', 'Cheeseburger')] Here's my equivalent code: 1. map(string.strip, spcs) 2. newnums = [] for n in nums: newnums.append(3*n) return newnums 3. newnums = [] for n in nums: if n > 2: newnums.append(n) return newnums 4. l = [] for i in nums: for s in strs: l.append((i,s)) return l 5. l = [] fl = [] for f in strs: if "n" in f: fl.append(f) for i in nums: for s in fl: l.append((i,s)) return l 6. ... the join is left as an exercise for the reader ... ;-) It seems like fairly powerful stuff and generally tends to reduce the amount of code the user writes. Is it more or less understandable than the current alternatives? That's the $64K question. I think in most cases it is. I think map and filter are more difficult to use and understand than the example list comprehensions from the test suite, but perhaps that's just my bias. I was never much of a Lisper, so it took me a good year or two before I got comfortable with anything more than the simplest uses of map. I probably still can't locate more than two or three instances in my own code where I've used filter. The nested for loops like the fourth and fifth examples seem to stretch out vertically and require the use of temporary variables that add complexity to the constructs. Skip From skip at mojam.com Wed Jul 12 00:30:43 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 17:30:43 -0500 (CDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.42862.320480.372351@anthem.concentric.net> References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> <14699.42862.320480.372351@anthem.concentric.net> Message-ID: <14699.40979.693147.384500@beluga.mojam.com> BAW> So I guess if that's the behavior I want, I'd use map, right? BAW> There's probably no good way to spell both. Yes, but you probably map() and filter() in your sleep with your Lisp experience... ;-) S From pingster at ilm.com Wed Jul 12 02:01:24 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 17:01:24 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711165406.A29590@lyra.org> Message-ID: On Tue, 11 Jul 2000, Greg Stein wrote: > On Tue, Jul 11, 2000 at 07:02:06PM -0400, Barry A. Warsaw wrote: [...] > > But wouldn't some variation on > > > > for x, y in a, b: > > > > invoke resonance with the classic idiom? Okay, now I'm reduced to > > arguing syntax (and syntax which I haven't thought out much :). > > for x, y in a, b: > > won't work. "a, b" is a tuple constructor. The for-loop will iterate over a > two-item tuple, and unpack each item (a and b) into the x,y variables. That's why i suggested the above, with semicolons instead of commas. Other ideas for a separator symbol are welcomed... but i think the semicolon may be the only reasonable option left. -- ?!ng "We're going to turn this team around 360 degrees." -- Jason Kidd, upon being drafted by the Dallas Mavericks From skip at mojam.com Wed Jul 12 00:36:32 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 17:36:32 -0500 (CDT) Subject: [Python-Dev] O'Reilly conference In-Reply-To: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <14699.41328.521867.559541@beluga.mojam.com> Fred> So who's going to the O'Reilly conference next week? The Fred> PythonLabs crew expects to be there, and we just might have some Fred> goodies. ;) I wish I had known about it sooner (or realized the confluence of different streams in my life). Turns out I'm in San Francisco this week... Skip From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 02:11:06 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 02:11:06 +0200 (CEST) Subject: [Python-Dev] Memory leak tracking In-Reply-To: <14699.30119.262274.258429@anthem.concentric.net> from "Barry A. Warsaw" at Jul 11, 2000 03:29:43 PM Message-ID: <200007120011.CAA23273@python.inrialpes.fr> Barry A. Warsaw wrote: > > How important is it to fix these problems when gc is disabled? > ... > Please let me know what you think. If the concensus is to fix them, I > keep working on them. I do still plan on looking at the few memory > problems still left even with gc turned on. I think that if we start relaxing our attention w.r.t. refcount policies, cyclic refs and the resulting mem leaks _in_the_core_, just because gc helps in hiding bad practice, we'll suffer more than you would in the attempt to fix these things. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Wed Jul 12 02:09:31 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 17:09:31 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: ; from pingster@ilm.com on Tue, Jul 11, 2000 at 05:01:24PM -0700 References: <20000711165406.A29590@lyra.org> Message-ID: <20000711170930.E29590@lyra.org> On Tue, Jul 11, 2000 at 05:01:24PM -0700, Ka-Ping Yee wrote: > On Tue, 11 Jul 2000, Greg Stein wrote: > > On Tue, Jul 11, 2000 at 07:02:06PM -0400, Barry A. Warsaw wrote: > [...] > > > But wouldn't some variation on > > > > > > for x, y in a, b: > > > > > > invoke resonance with the classic idiom? Okay, now I'm reduced to > > > arguing syntax (and syntax which I haven't thought out much :). > > > > for x, y in a, b: > > > > won't work. "a, b" is a tuple constructor. The for-loop will iterate over a > > two-item tuple, and unpack each item (a and b) into the x,y variables. > > That's why i suggested the above, with semicolons instead of commas. > Other ideas for a separator symbol are welcomed... but i think the > semicolon may be the only reasonable option left. hehe... I have another "reasonable option" :-) -- Greg Stein, http://www.lyra.org/ From nascheme at enme.ucalgary.ca Wed Jul 12 02:13:52 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 11 Jul 2000 18:13:52 -0600 Subject: [Python-Dev] Memory leak tracking In-Reply-To: <200007120011.CAA23273@python.inrialpes.fr>; from Vladimir Marangozov on Wed, Jul 12, 2000 at 02:11:06AM +0200 References: <14699.30119.262274.258429@anthem.concentric.net> <200007120011.CAA23273@python.inrialpes.fr> Message-ID: <20000711181352.A13655@keymaster.enme.ucalgary.ca> Perhaps gc.set_debug(gc.DEBUG_LEAK) would be helpful. Yes, real docs are coming. :) Neil From bwarsaw at beopen.com Wed Jul 12 02:20:44 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 20:20:44 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> <14699.38892.155046.60218@anthem.concentric.net> <20000711152951.X29590@lyra.org> <396BA425.2EF3B11F@prescod.net> Message-ID: <14699.47580.918825.55340@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Would it help to think of list comprehensions not so much as a PP> vote for a new idea as a vote AGAINST lambda, map and filter? If you mean specifically map/filter with lambda, yes. But map/filter with are pretty straightforward I think. It's the lambda that's confusing. -Barry From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 02:26:07 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 02:26:07 +0200 (CEST) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 11, 2000 03:03:12 PM Message-ID: <200007120026.CAA23349@python.inrialpes.fr> Guido van Rossum wrote: > > What do you think the following code would print? May I answer this? :-) > > for i in (10, 20, 30); j in (1, 2, 3): > print i+j > > A. > > 11 > 22 > 33 > > B. > 11 > 12 > 13 > 21 > 22 > 23 > 31 > 32 > 33 > > I'm afraid the answer will be the same, if these are again numerical > analysts -- these people live by nested DO loops. :-( Without being a numerical analyst, I would respond B. That's what this syntax suggests to me. Someone proposed `for ... while ...' which clearly suggests something different than nested loops, and in that case, if I don't know what it is, I'll read the docs. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From skip at mojam.com Wed Jul 12 00:57:25 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 17:57:25 -0500 (CDT) Subject: [Python-Dev] os.path.commonprefix testers needed for DOS, NT and Mac Message-ID: <14699.42581.843754.542783@beluga.mojam.com> Those of you with DOS, Windows/NT or Mac boxes, please take a look at the following patch: https://sourceforge.net/patch/?func=detailpatch&patch_id=100788&group_id=5470 It fixes posixpath.commonprefix to chunk its input by path components instead of by characters, so the prefix it returns should be a valid path. I can only check on Linux (I sort of expect other Unix variants will work as well). I corrected ntpath.py (which was the same as the version in posixpath.py) and added it to dospath.py and macpath.py. I can't really test any of them. Would those of you who can, please try it out and get back to me with a "yea" or a "nay" (with corrections, if possible)? Thanks, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From paul at prescod.net Wed Jul 12 02:35:13 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 19:35:13 -0500 Subject: [Python-Dev] list comprehensions again... References: <14699.31592.410628.754071@anthem.concentric.net> <1248770416-32799859@hypernet.com> <14699.38892.155046.60218@anthem.concentric.net> <20000711152951.X29590@lyra.org> <396BA425.2EF3B11F@prescod.net> <14699.47580.918825.55340@anthem.concentric.net> Message-ID: <396BBD41.A68E4477@prescod.net> "Barry A. Warsaw" wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> Would it help to think of list comprehensions not so much as a > PP> vote for a new idea as a vote AGAINST lambda, map and filter? > > If you mean specifically map/filter with lambda, yes. But map/filter > with are pretty straightforward I think. It's the lambda that's > confusing. Okay, but at least half of the time I want to use map/filter I want to do: map( lambda x: x.foo(), lst ) Python is an OO-ish language after all! Anyhow, with list comprehensions we could dump map/filter and probably lambda. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Wed Jul 12 02:44:10 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 19:44:10 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> Message-ID: <396BBF5A.B22837C@prescod.net> Thomas Wouters wrote: > > ... > > Well, not really. It doesn't create a new list, only a tuple to hold lists > to iter over (in order to pass it to the opcode as a single PyObject) and > similar for the resulting objects. It's definately more efficient than the > map() solution (and different, see below ;) Nevertheless, I think it is worth asking whether a parallel() or merge() function can do the same thing. It's not like the semicolon syntax screams out the right answer. The parallel function could return an iteratable object that generates tuples on demand. A function can be used in contexts other than a for loop. If we make functions like parallel and range not only builtin but non-overridable, we can do all sorts of optimizations in the bytecode compiler (and other compilers). In other words we can "inline" them when they are used in simple contexts. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gstein at lyra.org Wed Jul 12 02:50:56 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 11 Jul 2000 17:50:56 -0700 Subject: [Python-Dev] Memory leak tracking In-Reply-To: <200007120011.CAA23273@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Wed, Jul 12, 2000 at 02:11:06AM +0200 References: <14699.30119.262274.258429@anthem.concentric.net> <200007120011.CAA23273@python.inrialpes.fr> Message-ID: <20000711175056.I29590@lyra.org> On Wed, Jul 12, 2000 at 02:11:06AM +0200, Vladimir Marangozov wrote: > Barry A. Warsaw wrote: > > > > How important is it to fix these problems when gc is disabled? > > ... > > Please let me know what you think. If the concensus is to fix them, I > > keep working on them. I do still plan on looking at the few memory > > problems still left even with gc turned on. > > I think that if we start relaxing our attention w.r.t. refcount policies, > cyclic refs and the resulting mem leaks _in_the_core_, just because gc > helps in hiding bad practice, we'll suffer more than you would in the > attempt to fix these things. Agreed. The core should never create refcount problems. With or without GC, that is just bad policy. Cheers, -g -- Greg Stein, http://www.lyra.org/ From pingster at ilm.com Wed Jul 12 02:47:00 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 17:47:00 -0700 (PDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396BBD41.A68E4477@prescod.net> Message-ID: On Tue, 11 Jul 2000, Paul Prescod wrote: > > map( lambda x: x.foo(), lst ) > > Python is an OO-ish language after all! Anyhow, with list comprehensions > we could dump map/filter and probably lambda. Yeah, that would be quite nice. [x.foo(), for x in lst] What beauty! -- ?!ng From petrilli at amber.org Wed Jul 12 02:57:37 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Tue, 11 Jul 2000 20:57:37 -0400 Subject: [Python-Dev] O'Reilly conference In-Reply-To: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jul 11, 2000 at 05:20:38PM -0400 References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <20000711205737.A20771@trump.amber.org> Fred L. Drake, Jr. [fdrake at beopen.com] wrote: > > So who's going to the O'Reilly conference next week? The PythonLabs > crew expects to be there, and we just might have some goodies. ;) A good number of the Digicool people will be there, including: - Me, and who else really matters, ya' know? :-) - Jim Fulton - Paul Everitt - Gary Graham And I think one or two other people are going :-) Chris -- | Christopher Petrilli | petrilli at amber.org From pingster at ilm.com Wed Jul 12 03:05:10 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 11 Jul 2000 18:05:10 -0700 (PDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396BA425.2EF3B11F@prescod.net> Message-ID: On Tue, 11 Jul 2000, Paul Prescod wrote: > > Parallel iteration and list comprehensions are separate. I do prefer a > parallel() (merge?) builtin to the semicolon syntax, myself. You could > even define xparallel which is the lazy version (as in xrange). I like this idea. This whole parallel iteration thing could be solved with a single built-in and no syntax changes. for x, y in parallel([10, 20, 30], [1, 2]): Or "zip", since you're zipping the lists together (i foresee potential geometric or concurrency-related interpretations of "parallel"): for x, y in zip([10, 20, 30], [1, 2]): [(x, y+z), for (x, y) in zip((1, 2, 3, 4, 5, 6), "abc"), for z in "de"] Taking this all together provides one coherent solution: - zip() built-in produces a lazy list-zipper object - list-comps are written [, , , ...] where each is "for x in y" or "if z" Advantages: - no semicolons; semicolons remain solely statement separators - no possible confusion between parallel and nested iteration - comma remains the top-level separator within lists, so grouping of list-comp clauses is clear - dict-comp is possible and straightforward if we really want it - looks much prettier than map/lambda :) How's that for a serious proposal? -- ?!ng From akuchlin at cnri.reston.va.us Wed Jul 12 03:29:23 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 11 Jul 2000 21:29:23 -0400 Subject: [Python-Dev] O'Reilly conference In-Reply-To: <14699.41328.521867.559541@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 11, 2000 at 05:36:32PM -0500 References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> <14699.41328.521867.559541@beluga.mojam.com> Message-ID: <20000711212923.A15998@newcnri.cnri.reston.va.us> On a related note, is anyone else from python-dev going to be going to the Ottawa Linux Symposium nex week? --amk From gmcm at hypernet.com Wed Jul 12 03:58:02 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 11 Jul 2000 21:58:02 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396B8868.B58F3F0C@prescod.net> Message-ID: <1248755410-33702453@hypernet.com> Paul Prescod wrote: > Nested (List): > > [for x in (0,10,20,30): > for y in (0,1,2,3): > x+y] > [0,11,22,33] Not what I'd expect at all. - Gordon From gmcm at hypernet.com Wed Jul 12 03:58:02 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 11 Jul 2000 21:58:02 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: References: <20000711165406.A29590@lyra.org> Message-ID: <1248755408-33702560@hypernet.com> Ka-Ping Yee wrote: > On Tue, 11 Jul 2000, Greg Stein wrote: > > for x, y in a, b: > > > > won't work. "a, b" is a tuple constructor. The for-loop will > > iterate over a two-item tuple, and unpack each item (a and b) > > into the x,y variables. > > That's why i suggested the above, with semicolons instead of > commas. Other ideas for a separator symbol are welcomed... but i > think the semicolon may be the only reasonable option left. for x, y in a, b: for x, y in a; b: speechless-ly y'rs - Gordon From gmcm at hypernet.com Wed Jul 12 03:58:02 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 11 Jul 2000 21:58:02 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396BBD41.A68E4477@prescod.net> Message-ID: <1248755407-33702623@hypernet.com> Paul Prescod wrote: > Python is an OO-ish language after all! Anyhow, with list > comprehensions we could dump map/filter and probably lambda. I see more lambdas used in Tkinter code than anywhere else. Not a list in sight. - Gordon From esr at thyrsus.com Wed Jul 12 04:44:01 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 11 Jul 2000 22:44:01 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: References: <200007111440.JAA05205@cj20424-a.reston1.va.home.com> Message-ID: <20000711224401.A1107@thyrsus.com> Greg Wilson : > > Side note: the suggested syntax here (for i in seq1 for j in seq2) > > looks like a potential alternative for the currently proposed parallel > > for loop syntax (for i in seq1; j in seq2). > > > > Only problem: the for-for variant could be mistaken by someone used to > > see nested loops as meaning the same as > > > > for i in seq1: > > for j in seq2: ... > > Until yesterday's posting, I assumed that this is what for-for loops would > do, i.e. that they'd deliver a cross-product rather than one-from-each. This seems like the natural interpretation to me, also. I therefore prefer the semicolon sequence. -- Eric S. Raymond To stay young requires the unceasing cultivation of the ability to unlearn old falsehoods. -- Lazarus Long From esr at thyrsus.com Wed Jul 12 05:17:51 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 11 Jul 2000 23:17:51 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.12489.875905.520781@beluga.mojam.com> References: <200007110031.MAA06530@s454.cosc.canterbury.ac.nz> <200007111440.JAA05205@cj20424-a.reston1.va.home.com> <14699.12489.875905.520781@beluga.mojam.com> Message-ID: <20000711231751.A1265@thyrsus.com> Skip Montanaro : > > Guido> [(x,y) for x in (1,2,3) for y in (4,5,6)] > Guido> Would it be really bad if we forced them to write it that way? > > For that matter, perhaps requiring parens for all tuple definitions in Py3k > wouldn't be a bad idea. +1. IMO, naked tuples assignments are Perlish -- initially cute, but confusing. Syntactic junk food. -- Eric S. Raymond The common argument that crime is caused by poverty is a kind of slander on the poor. -- H. L. Mencken From tim_one at email.msn.com Wed Jul 12 04:59:41 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 11 Jul 2000 22:59:41 -0400 Subject: [Python-Dev] Windows build broken in exceptions.c Message-ID: exceptions.c(93) : error C2026: string too big, trailing characters truncated Error executing cl.exe. The platform (MSVC6) docs for C2026: After adjacent strings are concatenated, a string cannot be longer than 2048 characters. However, those docs aren't accurate: if I break the giant docstring into two pieces, like so (implicitly concatenated): "sub-giant piece one" "sub-giant piece two" everything is fine. The compiler only gripes about a single string literal > 2K. I guessed that might be true because it seems more of a "catch runaway string" gimmick than a reasonable compiler limit. Anyway, I hesitate to check in that MSVC6 workaround if the same problem is just going to crop up on other platforms. Has it popped up for anyone else? One alternative is to keep strings short and paste them together at runtime in the module init fnc. From greg at cosc.canterbury.ac.nz Wed Jul 12 05:02:09 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 12 Jul 2000 15:02:09 +1200 (NZST) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711192202.B7340@xs4all.nl> Message-ID: <200007120302.PAA06664@s454.cosc.canterbury.ac.nz> Thomas Wouters wrote: > But the syntax is pretty ambiguous, and not > too pythonic at that. For instance, the endless mixing possibilities of > 'for' and 'if' without delimiters or ways to group them can be pretty > confusing. I don't think it's so confusing if you think about LCs the right way. You're meant to be able to think of them as a declarative construct, e.g. [(x, y) for x in a for y in b if y > 3] means "a list of all tuples (x, y) such that x is in a and y is in b and y > 3". Assuming no side effects, the result doesn't depend on what order the loops and tests are nested in, so (unless you're concerned about speed) you don't need to think in terms of loops at all, just a set of conditions. The syntax I chose was the most pythonic one I could think of that worked. It would probably look better with some sort of separator, but I wouldn't like to use anything stronger than a comma (semicolons inside a statement just don't look right to me), which means something like [(x, y) for x in a, for y in b, if y > 3] But then it looks a bit redundant having to repeat the 'for' each time, so you'd really want it to be more like [(x, y) for x in a, y in b, y > 3] which is hopelessly ambiguous. So I gave up on commas altogether. > it would be nice if list comprehensions could be used to initialize > *part* of a list, It would, but would the greatly increased implementation complexity be worth it? (And don't forget to allow range-literals the same privilege!-) > Can we get away with not including the nested-for syntax? I'd be really disappointed if LCs only made it in in such an emasculated form. It would remove a huge amount of their power, and I would have serious doubts that what was left would be worth bothering with. Heavens, next thing you know, someone will suggest adding a lambda without nested scoping... :-) > parallel-for-loops -> list comprehensions -> range-literals That's sensible, but I wouldn't like to see LCs get held up waiting for a consensus on PFLs to emerge. I think that if we just make sure that LCs and normal FLs share the same piece of compiler code, whatever is done to FLs later will get inherited by LCs automatically... sort of... Concerning PFLs, it seems to me that earlier language design decisions have pretty well scuttled any hope of coming up with a natural-looking and compatible PFL syntax. So we're going to have to settle for (a) an incompatible one, (b) an unnatural looking one, or (c) none at all. In category (b), my suggestion of the day is: for {var, ...} in expr e.g. for {x, y} in a, b Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 05:11:12 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 05:11:12 +0200 (CEST) Subject: [Python-Dev] Include/pyport.h now exists In-Reply-To: <20000708212149.P26534@xs4all.nl> from "Thomas Wouters" at Jul 08, 2000 09:21:50 PM Message-ID: <200007120311.FAA10295@python.inrialpes.fr> Thomas Wouters wrote: > > [Tim] > > Would someone who understands (& can test! I can't yet) autoconfig please > > follow up on the last part? The stuff I checked in "fails safe", i.e. the > > lack of autoconfig support should not cause problems on any of your > > platforms. > > Can't say I understand all of autoconf but I read enough of the info pages > to be able to do this ! :-) I couldn't find an existing test that covers > this, so I used your example to make one; patch attached. It detects my > linux box properly as 'doesn't zero-fill when right-shifting a negative > number', but I haven't a Cray J90 handy to test the opposite ;) > > Feel free to change the wording to something a bit less... wordy, though ;) > Oh, and don't forget to run autoheader & automake before checking in. I've checked this in, but I haven't figured out whether and how I could assign an open (non assigned) patch to myself and close it. If I am missing something, please let me know. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw at beopen.com Wed Jul 12 05:23:00 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 23:23:00 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> Message-ID: <14699.58516.791911.405213@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: BAW> Range literals I can see as being worth it. I wonder if BAW> parallel for loops can't be handled more gracefully with a BAW> function -- isn't it just a nice wrapper around a specific BAW> call to map() anyway? SM> I believe Thomas proposed range literals to avoid calling the SM> range() function... Right, and that seems totally cool to me. Simple syntax, clear semantics. SM> Regarding a wrapper around map(), you will need a pretty hairy SM> wrapper, since you can do some pretty complex things with SM> Greg's version of list comprehensions. I meant the parallel for loops as a shortcut for map(). List comprehensions do seem more powerful, however: | print [s.strip() for s in spcs] | print [3 * x for x in nums] Cool so far. | print [x for x in nums if x > 2] Uh oh, starting to look like Perl... | print [i, s for i in nums for s in strs] | print [i, s for i in nums for s in [f for f in strs if "n" in f]] Yow! No one will accuse Python of only having one way to do it anymore! Even without the curse-word-symbols, I fear excessive scalp exposing head-scratching when I see this in code. -Barry From bwarsaw at beopen.com Wed Jul 12 05:25:01 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 23:25:01 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <20000711165406.A29590@lyra.org> Message-ID: <14699.58637.724595.543978@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> That's why i suggested the above, with semicolons instead of KY> commas. Other ideas for a separator symbol are KY> welcomed... but i think the semicolon may be the only KY> reasonable option left. vertical bar? From jeremy at beopen.com Wed Jul 12 05:29:36 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 11 Jul 2000 23:29:36 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.58516.791911.405213@anthem.concentric.net> References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> Message-ID: <14699.58912.789947.837917@bitdiddle.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: BAW> | print [i, s for i in nums for s in strs] BAW> | print [i, s for i in nums for s in [f for f in strs if "n" in f]] BAW> Yow! No one will accuse Python of only having one way to do it BAW> anymore! Even without the curse-word-symbols, I fear excessive BAW> scalp exposing head-scratching when I see this in code. I think these examples demonstrate the need for some punctuation, though perhaps not curse-word-symbols. I really like the vertical bar that Haskell uses to separate the variables being assigned to from the generator expression. It's a very familiar notation from mathematics. There also needs to be some punctuation to separate each generator expression when there is more than one. Commas and semicolons both seem reasonable viewed in isolation; commas are problematic because they are already used for tuple creation. Jeremy From akuchlin at cnri.reston.va.us Wed Jul 12 05:29:04 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 11 Jul 2000 23:29:04 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.58516.791911.405213@anthem.concentric.net>; from bwarsaw@beopen.com on Tue, Jul 11, 2000 at 11:23:00PM -0400 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> Message-ID: <20000711232904.A16338@newcnri.cnri.reston.va.us> On Tue, Jul 11, 2000 at 11:23:00PM -0400, Barry A. Warsaw wrote: >Yow! No one will accuse Python of only having one way to do it >anymore! Even without the curse-word-symbols, I fear excessive scalp >exposing head-scratching when I see this in code. Agreed; unless some clearer phrasing emerges, I'll vote -1 on list comprehensions, since they offer too much potential for obfuscation. --amk From bwarsaw at beopen.com Wed Jul 12 05:32:41 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 23:32:41 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> <396BBF5A.B22837C@prescod.net> Message-ID: <14699.59097.346202.496529@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Nevertheless, I think it is worth asking whether a parallel() PP> or merge() function can do the same thing. It's not like the PP> semicolon syntax screams out the right answer. The parallel PP> function could return an iteratable object that generates PP> tuples on demand. A function can be used in contexts other PP> than a for loop. Right. I think I'm beginning to like an explicit function (builtin or not) better than the syntax change. -Barry From gvwilson at nevex.com Wed Jul 12 05:33:51 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 11 Jul 2000 23:33:51 -0400 (EDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711234737.D7340@xs4all.nl> Message-ID: > Thomas Wouters wrote: > I still think > > 'for x in a; y in b:' > > is the right syntax for parallel for loops. It's almost "only" > syntactic sugar for > > 'for x,y in map(None, a, b)' > > but it's fairly straightforward, and in large blocks of code it might > look a lot better. Is there a built-in function in Python to combine sequences elementwise? If I can write: for x,y in pairwise(a, b): foo(x,y) and if the compiler is smart enough to avoid actually constructing the pairwise list, then perhaps new syntax is unnecessary? > Given that you can already do the nested-for-loop with a nested for > loop, and it doesn't suffer (much) in way of readability or pythonity, > I think most people will realize that the parallel for loop does > actually do a parallel for-each. I disagree. That doesn't mean people can't be taught/won't remember that multi-loops are executed in step, rather that by cross product, but I believe most people will guess wrong the first time they see the current notation. Thanks, Greg From fdrake at beopen.com Wed Jul 12 05:41:59 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 11 Jul 2000 23:41:59 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure.in,1.134,1.135 In-Reply-To: <200007120302.UAA13467@slayer.i.sourceforge.net> References: <200007120302.UAA13467@slayer.i.sourceforge.net> Message-ID: <14699.59655.736149.252369@cj42289-a.reston1.va.home.com> Vladimir Marangozov writes: > Closes patch #100832 > (but I can't assign it to myself, nor close it -- sorry) Vladimir, I just checked your permissions for the patch manager, and everything is enabled. You should just be able to set the status and assignment in the pull-down menus at the top of the form, and the values are updated when you click on "Submit Changes" at the bottom of the page. Did this not work for you, or was it not clear that that's the way to do it? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Wed Jul 12 05:44:47 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 11 Jul 2000 23:44:47 -0400 (EDT) Subject: [Python-Dev] zip() and list-comprehension with commas References: <396BA425.2EF3B11F@prescod.net> Message-ID: <14699.59823.710880.896491@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> I like this idea. This whole parallel iteration thing could KY> be solved with a single built-in and no syntax changes. KY> for x, y in parallel([10, 20, 30], [1, 2]): KY> Or "zip", since you're zipping the lists together (i foresee KY> potential geometric or concurrency-related interpretations of KY> "parallel"): Definitely +1 on concept. The nice bit is that parallel() or zip() can return objects that iterate efficiently. -0 on zip(), +0 on parallel(), +0 on making them builtins. Alternatives (as Greg I think brought up): pairwise(), maybe zipper() for zip() since it's more evocative. -Barry From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 05:53:30 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 05:53:30 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure.in,1.134,1.135 In-Reply-To: <14699.59655.736149.252369@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jul 11, 2000 11:41:59 PM Message-ID: <200007120353.FAA25150@python.inrialpes.fr> Fred L. Drake, Jr. wrote: > > Vladimir Marangozov writes: > > Closes patch #100832 > > (but I can't assign it to myself, nor close it -- sorry) > > Vladimir, > I just checked your permissions for the patch manager, and > everything is enabled. You should just be able to set the status and > assignment in the pull-down menus at the top of the form, and the > values are updated when you click on "Submit Changes" at the bottom of > the page. > Did this not work for you, or was it not clear that that's the way > to do it? The latter. Thanks for the clarification. I'll check this out. Besides, I think I screwed the logic of this patch as now I get a "no" answer while it should be "yes" on my combo. So I definitely need to assign this patch to myself and fix it! -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at beopen.com Wed Jul 12 07:50:27 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 00:50:27 -0500 Subject: [Python-Dev] Memory leak tracking In-Reply-To: Your message of "Tue, 11 Jul 2000 15:29:43 -0400." <14699.30119.262274.258429@anthem.concentric.net> References: <14699.30119.262274.258429@anthem.concentric.net> Message-ID: <200007120550.AAA12465@cj20424-a.reston1.va.home.com> Barry Warsaw: > When I compile out gc, I get more leaks in the core, namely in > exceptions.c. Turning on gc clears all of these up; e.g. all the > memory gets freed eventually. My suspicion therefore is that there > are a number of cycles created during the initialization of the > built-in exceptions. Vladimir Marangozov: > I think that if we start relaxing our attention w.r.t. refcount policies, > cyclic refs and the resulting mem leaks _in_the_core_, just because gc > helps in hiding bad practice, we'll suffer more than you would in the > attempt to fix these things. Let me explain something about the new GC code. It does *not* hide missed DECREFs. If you miss a DECREF, the GC code thinks there's a global pointer to the object that keeps it alive, and will not release the object. I don't know what Barry found, but I suspect they are genuine cycles created during the exception initialization. It's easy enough to create cycles, e.g. form module -> class -> function -> module, or module -> function -> module, when defining classes or functions. The new GC code is *intended* to clean up exactly such cycles! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From bwarsaw at beopen.com Wed Jul 12 07:05:52 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 01:05:52 -0400 (EDT) Subject: [Python-Dev] Memory leak tracking References: <14699.30119.262274.258429@anthem.concentric.net> <200007120550.AAA12465@cj20424-a.reston1.va.home.com> Message-ID: <14699.64688.697935.541901@anthem.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> I don't know what Barry found, but I suspect they are genuine GvR> cycles created during the exception initialization. It's GvR> easy enough to create cycles, e.g. form module -> class -> GvR> function -> module, or module -> function -> module, when GvR> defining classes or functions. GvR> The new GC code is *intended* to clean up exactly such GvR> cycles! I suspect this is exactly what's happening. I'd have to spend more time to know exactly what's happening, but this jives with the observed behavior. If so, the only thing we could do is try to break the cycles manually at shutdown time and have the normal decrefs free all the memory. I'm not sure it's worth the effort. 1) it isn't much memory; 2) it only leaks when gc is disabled; 3) it's a one time cost, not e.g. a leak every time you spawn a thread. That last is interesting, because I believe at least on Solaris, there /is/ a leak for each new thread, but I haven't had time to find it yet. That one's worth tracking down. For the others, it's actually quite nice to see gc doing it's job! Other than that, running the test suite, the current CVS seems to have a very clean bill of health memory usage-wise. -Barry From moshez at math.huji.ac.il Wed Jul 12 07:22:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 08:22:06 +0300 (IDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: Message-ID: On Tue, 11 Jul 2000, Ka-Ping Yee wrote: > On Tue, 11 Jul 2000, Paul Prescod wrote: > > > > Parallel iteration and list comprehensions are separate. I do prefer a > > parallel() (merge?) builtin to the semicolon syntax, myself. You could > > even define xparallel which is the lazy version (as in xrange). > > I like this idea. This whole parallel iteration thing could be solved > with a single built-in and no syntax changes. > > for x, y in parallel([10, 20, 30], [1, 2]): > > Or "zip", since you're zipping the lists together (i foresee potential > geometric or concurrency-related interpretations of "parallel"): +1 on prefering a builtin to a syntax change > for x, y in zip([10, 20, 30], [1, 2]): > > [(x, y+z), for (x, y) in zip((1, 2, 3, 4, 5, 6), "abc"), for z in "de"] +1 on that too...really clear -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 07:38:13 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 07:38:13 +0200 (CEST) Subject: [Python-Dev] Memory leak tracking In-Reply-To: <200007120550.AAA12465@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 12, 2000 12:50:27 AM Message-ID: <200007120538.HAA23814@python.inrialpes.fr> Guido van Rossum wrote: > > Let me explain something about the new GC code. It does *not* hide > missed DECREFs. If you miss a DECREF, the GC code thinks there's a > global pointer to the object that keeps it alive, and will not release > the object. > Sure. > I don't know what Barry found, but I suspect they are genuine cycles > created during the exception initialization. It's easy enough to > create cycles, e.g. form module -> class -> function -> module, or > module -> function -> module, when defining classes or functions. > > The new GC code is *intended* to clean up exactly such cycles! My point is that it is better not to rely on the GC code for the core if we're not crystal clear when and why cycles are created. And even if we spot them all (and mark these locations in the source), it is always better to try breaking the cycles explicitely. It's a fact that we're not crystal clear where all these cycles are created (be they genuine, easily introduced or not). This is not a good thing and I don't want to support the idea of tolerating this situation. I wish I had Purify to help Barry cleaning this up... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From moshez at math.huji.ac.il Wed Jul 12 08:00:53 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 09:00:53 +0300 (IDT) Subject: [Python-Dev] list comprehensions again... In-Reply-To: <20000711231751.A1265@thyrsus.com> Message-ID: On Tue, 11 Jul 2000 esr at thyrsus.com wrote: > Skip Montanaro : > > > > Guido> [(x,y) for x in (1,2,3) for y in (4,5,6)] > > Guido> Would it be really bad if we forced them to write it that way? > > > > For that matter, perhaps requiring parens for all tuple definitions in Py3k > > wouldn't be a bad idea. > > +1. IMO, naked tuples assignments are Perlish -- initially cute, but > confusing. Syntactic junk food. I disagree. That would make the readable def fib(n): a, b = 0, 1 for i in range(n): a, b = b, a+b return a, b old_rabbits, young_rabbits = fib(100) (Ditto for GCD) A mess of parenthesis. Commas build tuples. Parenthesis fix precedence. Never the two shall mix. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Wed Jul 12 08:09:11 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 09:09:11 +0300 (IDT) Subject: [Python-Dev] File Object Copy Message-ID: I've found a need for the following function: def copyfile(fin, fout): while 1: buf = fin.read(4096) if not buf: break fout.write(buf) In several different places (modules I've written, SimpleHTTPServer uses it, urllib has that code inlined somewhere, etc.) (Of course, 4096 should be a parameter, but that's nits) Can anyone suggest a module in which this function would belong? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From andy at reportlab.com Wed Jul 12 08:52:05 2000 From: andy at reportlab.com (Andy Robinson) Date: Wed, 12 Jul 2000 07:52:05 +0100 Subject: [Python-Dev] zlib not compiled by default Message-ID: At present, zlib is available in Win32, but users need to uncomment the line in Modules/Setup and recompile on Unix. ReportLab now has 100+ subscribed users in our user group (so I presume at least 5x more users), and we use zlib heavily to compress images and PDF files. It can run without it, but at the expense of bloated output. Are there many other applications which use compression? If so, would it do be feasible to include it by default from version 1.6? Andy Robinson p.s. I can submit a patch if needed :-) From pf at artcom-gmbh.de Wed Jul 12 09:13:32 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 12 Jul 2000 09:13:32 +0200 (MEST) Subject: [Python-Dev] File Object Copy In-Reply-To: from Moshe Zadka at "Jul 12, 2000 9: 9:11 am" Message-ID: Hi, Moshe Zadka: > I've found a need for the following function: > > def copyfile(fin, fout): > while 1: > buf = fin.read(4096) > if not buf: > break > fout.write(buf) > > In several different places (modules I've written, SimpleHTTPServer uses > it, urllib has that code inlined somewhere, etc.) > > (Of course, 4096 should be a parameter, but that's nits) > > Can anyone suggest a module in which this function would belong? A very similar function lives at a somewhat hidden flat in the third floor of the standard library building. ;-) It is called 'shutil.copyfile'. See '......html/lib/module-shutil.html' for more information. 'shutil.copyfile' however takes filenames as arguments and contains the loop sketched above as inline code. I see two possibilities: 1. It would be easy to skip the open and close operations in 'shutil.copyfile', if either 'src' or 'dst' are already open file objects instead of strings. 2. Or you factor out the copy loop operation above and rename it into 'copycontent' or 'copybytes' or whatever. Regards, Peter From moshez at math.huji.ac.il Wed Jul 12 09:21:08 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 10:21:08 +0300 (IDT) Subject: [Python-Dev] File Object Copy In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Peter Funk wrote: > 'shutil.copyfile' however takes filenames as arguments and contains > the loop sketched above as inline code. I see two possibilities: > 1. It would be easy to skip the open and close operations in > 'shutil.copyfile', if either 'src' or 'dst' are already open > file objects instead of strings. -0: Too much Perl-like DWIM magic > 2. Or you factor out the copy loop operation above and rename it into > 'copycontent' or 'copybytes' or whatever. Of course it should be factored out: but the question remains, why shell utils? Do you really think copybytes belongs there? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Wed Jul 12 09:26:02 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 09:26:02 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src configure.in,1.134,1.135 In-Reply-To: <200007120353.FAA25150@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Wed, Jul 12, 2000 at 05:53:30AM +0200 References: <14699.59655.736149.252369@cj42289-a.reston1.va.home.com> <200007120353.FAA25150@python.inrialpes.fr> Message-ID: <20000712092602.F7340@xs4all.nl> On Wed, Jul 12, 2000 at 05:53:30AM +0200, Vladimir Marangozov wrote: > Besides, I think I screwed the logic of this patch as now I get a "no" > answer while it should be "yes" on my combo. So I definitely need to > assign this patch to myself and fix it! Actually, almost everyone should see 'no' in response to the statement 'checking if signed-right-shift zero-fills', except for Cray J90's and possibly other strange hardware. In any case, if 'test_long' succeeds for you, all is well. If you want it to say 'yes' instead of 'no' and still mean the same thing, swap the logic, and change the question to 'whether right-shift pads with sign bit' or some such. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From ping at lfw.org Tue Jul 11 19:31:59 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Tue, 11 Jul 2000 10:31:59 -0700 (PDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> Message-ID: On Tue, 11 Jul 2000, Fred L. Drake, Jr. wrote: > At one point, we were discussing having specializations of > SyntaxError, and I posted a patch that defined IndentationError and > TabError. I guess the question is, will we ever want to catch or distinguish just IndentationError or TabError exceptions in particular from within a Python program? I can't personally think of any situations where i would need more detail than SyntaxError (whatever the error is, i'll just want to say "syntax error" and show the message)... unless... should the expected token type be passed *all* the way back to the user level so that e.g. an IDE can provide a UI hint as to how to correct the syntax error? -- ?!ng From pf at artcom-gmbh.de Wed Jul 12 09:52:42 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 12 Jul 2000 09:52:42 +0200 (MEST) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <14699.59823.710880.896491@anthem.concentric.net> from "Barry A. Warsaw" at "Jul 11, 2000 11:44:47 pm" Message-ID: Hi, Barry A. Warsaw: > >>>>> "KY" == Ka-Ping Yee writes: > > > KY> I like this idea. This whole parallel iteration thing could > KY> be solved with a single built-in and no syntax changes. > > KY> for x, y in parallel([10, 20, 30], [1, 2]): > > KY> Or "zip", since you're zipping the lists together (i foresee > KY> potential geometric or concurrency-related interpretations of > KY> "parallel"): > > Definitely +1 on concept. The nice bit is that parallel() or zip() > can return objects that iterate efficiently. -0 on zip(), +0 on > parallel(), +0 on making them builtins. +1 on the concept. -1 on calling it 'zip' (I was first thinking of Info ZIP and zlib). -0 on calling it 'parallel' (makes me thinking of threads and processes). What about calling this function 'permute()'? Here is a strawman to play with: def permute(*args): """takes several sequences as arguments and returns a list of tuples, where each tuple contains an element of each sequence permutated through all possible combinations.""" if len(args) == 1: return map(lambda x:(x,), args[0]) else: res = []; cdr = apply(permute, args[1:]) for left in args[0]: for right in cdr: res.append((left,) + right) return res for x, y in permute([10, 20, 30], [1, 2]): print "x, y =", x, y BTW: How comes, that Ping very often invents or introduces very clever ideas and concepts, but also very often chooses unclear names for them? Is it just me not being a native english speaker? Regards, Peter From peter at schneider-kamp.de Wed Jul 12 12:00:33 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 12 Jul 2000 10:00:33 +0000 Subject: [Python-Dev] zip() and list-comprehension with commas References: Message-ID: <396C41C1.5A1C7652@schneider-kamp.de> Ka-Ping Yee wrote: > > Taking this all together provides one coherent solution: > > - zip() built-in produces a lazy list-zipper object +1 on this. no performance hit (probably a small gain), "zip" is imho the right name (see e.g. haskell). also answers on c.l.py could be shorter, saving considerable bandwidth > > - list-comps are written [, , , ...] > where each is "for x in y" or "if z" +0.5 on the concept, some questions: -------------------------------------------------------------------- I know special character are evil, but in this case I think [ | , , ...] would be on order of magnitude easier to read. Why not? -------------------------------------------------------------------- Would [x,y , for x in list1, if x > 1, if y > 2, for y in list2] be allowed? In other words: Should there be some rules of ordering? What would the above list comprehension produce for list1 = list2 = [1, 2, 3]? -------------------------------------------------------------------- Would the following be allowed (and desirable)? y = 3 [ x + y , for x in [1, 2, 3], if x > 1] producing [5, 6] -------------------------------------------------------------------- I don't know Python's parser, so I am sorry if this is a non-issue: How does it resolve the ambiguity between [, , ...] and [, , , ...]? Especially something like [x, y, z, for x in l1, for y in l2, for z in l3] concerns me. -------------------------------------------------------------------- that's it for now, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From effbot at telia.com Wed Jul 12 10:14:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 10:14:42 +0200 Subject: [Python-Dev] SyntaxError patches References: Message-ID: <00ba01bfebd9$3cfb5c80$f2a6b5d4@hagrid> ping wrote: > On Tue, 11 Jul 2000, Fred L. Drake, Jr. wrote: > > At one point, we were discussing having specializations of > > SyntaxError, and I posted a patch that defined IndentationError and > > TabError. > > I guess the question is, will we ever want to catch or distinguish > just IndentationError or TabError exceptions in particular from > within a Python program? TabError maybe (retabify and try again -- but if you'll implement that, you might as well untabify before compiling), but I cannot see any reason to handle IndentationError. Also sucks from a documentation perspective... I'm -1 (on this part of the patch). > I can't personally think of any situations where i would need more > detail than SyntaxError (whatever the error is, i'll just want to > say "syntax error" and show the message)... unless... should the > expected token type be passed *all* the way back to the user level > so that e.g. an IDE can provide a UI hint as to how to correct the > syntax error? and in that case, the IDE won't be interested in actually showing the exception type to anyone... It's probably better to add extra info to the exception object, such as an "error tag" which is guaranteed to stay the same, no matter what the message is changed into (I'd love to have this in Python- Works, for example). guess it's time to grep for SyntaxError exceptions... From effbot at telia.com Wed Jul 12 10:19:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 10:19:23 +0200 Subject: [Python-Dev] Windows build broken in exceptions.c References: Message-ID: <00c401bfebd9$e6d347e0$f2a6b5d4@hagrid> tim wrote: > exceptions.c(93) : error C2026: string too big, trailing characters > truncated and incidentally, I just got: SyntaxError: expression too long from python. but back to the original topic: what does the ANSI standard say about this? what is, for example, the limits for integer arrays? (my unicode database experiments results in a couple of big ones. and for best performance, they really have to be that big...) From peter at schneider-kamp.de Wed Jul 12 12:16:54 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 12 Jul 2000 10:16:54 +0000 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: Message-ID: <396C4596.C64D4EE6@schneider-kamp.de> Peter Funk wrote: > > What about calling this function 'permute()'? -1 on this: We are not looking for all possible pairings but for the (possibly lazy) equivalent of map(None, list1, list2, ...). > BTW: How comes, that Ping very often invents or introduces very clever > ideas and concepts, but also very often chooses unclear names for them? > Is it just me not being a native english speaker? I still think "zip" is okay, but that's probably my Haskell background. And no, I don't think it has to do something with not being a native English speaker. It's probably more the context you associate with "zip". I can't comment on earlier cases, though. heading-to-work-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mwh21 at cam.ac.uk Wed Jul 12 10:27:50 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Wed, 12 Jul 2000 09:27:50 +0100 (BST) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Peter Funk wrote: > BTW: How comes, that Ping very often invents or introduces very > clever ideas and concepts, but also very often chooses unclear names > for them? Is it just me not being a native english speaker? In this case it's you not being a functional programmer; `zip' seems perfectly natural to the part of my brain that speaks Haskell. Think zip as in "zipper"; this more sense to me than naming a compression algorithm "zip"... Cheers, M. From pf at artcom-gmbh.de Wed Jul 12 10:27:01 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 12 Jul 2000 10:27:01 +0200 (MEST) Subject: [Python-Dev] SyntaxError patches In-Reply-To: from Ka-Ping Yee at "Jul 11, 2000 10:31:59 am" Message-ID: > On Tue, 11 Jul 2000, Fred L. Drake, Jr. wrote: > > At one point, we were discussing having specializations of > > SyntaxError, and I posted a patch that defined IndentationError and > > TabError. Ka-Ping Yee: > I guess the question is, will we ever want to catch or distinguish > just IndentationError or TabError exceptions in particular from > within a Python program? I don't believe this. > I can't personally think of any situations where i would need more > detail than SyntaxError (whatever the error is, i'll just want to > say "syntax error" and show the message)... unless... should the > expected token type be passed *all* the way back to the user level > so that e.g. an IDE can provide a UI hint as to how to correct the > syntax error? That sounds rather complicated anyway, but it would certainly be nice for people using (or should I say needing?) an IDE. BTW: The following mistake has happened to me to in the past (I'm using the VI improved editor unter X11): If cut'n'pasting methods around between classes, sometimes I unintentionally copy a space character too much, so that the 'def' of the copied method is intended one blank to much to the right. Hmmmm... I should make this clearer using an example: ### class Foo(Bar): def pasted_method(self, ....) #---^ note this additional blank here (resulting in a 5 space indent). # ...a screenful of indented code snipped here... def another_method(self, baz, bang): #--------------------------------------^ # Python 1.5.2 barfs here with "SyntaxError: invalid token" ### This is not very intuitive and hard to see. The first time I stumbled about this it has taken me quite some time to discover my mistake. I wonder, if the error message could be improved. That would be a very valuable improvement for newbies. However this example might proove that the idea an IDE would be able to provide UI-hints for fixing errors is doomed to fail in the general case. Regards, Peter. From ping at lfw.org Wed Jul 12 10:36:25 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 01:36:25 -0700 (PDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C41C1.5A1C7652@schneider-kamp.de> Message-ID: On Wed, 12 Jul 2000, Peter Schneider-Kamp wrote: > +1 on this. no performance hit (probably a small gain), > "zip" is imho the right name (see e.g. haskell). Indeed, a nice coincidence. :) > -------------------------------------------------------------------- > > I know special character are evil, but in this case I think > [ | , , ...] > would be on order of magnitude easier to read. Why not? Alas, the vertical bar is already a bitwise-or operator, and couldn't safely be placed next to the . Hmm. How much of that "order of magnitude" comes from "|" looking like the math notation, and how much from the mere fact that "|" is distinguished from ","? Semicolon might be worth considering here, actually: [f(x); for x in l] > -------------------------------------------------------------------- > > Would [x,y , for x in list1, if x > 1, if y > 2, for y in list2] > be allowed? In other words: Should there be some rules of ordering? > What would the above list comprehension produce for > list1 = list2 = [1, 2, 3]? I would say raise SyntaxError on this example. Also, the way you've written the example would depend on an existing variable named 'y' because you put "if y > 2" outside of "for y in list2". If the existing variable was <= 2, you'd get an empty list. For the following, i'm assuming you intended to put "if y > 2" last. As for the SyntaxError, i think it's a good idea because the example could be ambiguous. You would have to either say [(x, y), for x in list1, if x > 1, for y in list2, if y > 2] or [x] + [y, for x in list1, if x > 1, for y in list2, if y > 2] The first would produce [(2, 3), (3, 3)], and the second would depend on the initial value of x and look like [x, 3, 3]. > -------------------------------------------------------------------- > > Would the following be allowed (and desirable)? > y = 3 > [ x + y , for x in [1, 2, 3], if x > 1] > producing [5, 6] Absolutely. > -------------------------------------------------------------------- > > I don't know Python's parser, so I am sorry if this is a non-issue: > How does it resolve the ambiguity between > [, , ...] and [, , , ...]? > Especially something like > [x, y, z, for x in l1, for y in l2, for z in l3] concerns me. I guess it depends how the argument about parens-around-tuples finally resolves, but personally i'd say that more than one expr before an attempted iteration clause should cause a SyntaxError. It would have to be written: [(x, y, z), for x in l1, for y in l2, for z in l3] -- ?!ng From mal at lemburg.com Wed Jul 12 10:32:00 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 12 Jul 2000 10:32:00 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: <396C4596.C64D4EE6@schneider-kamp.de> Message-ID: <396C2D00.BDA23AF2@lemburg.com> Peter Schneider-Kamp wrote: > > Peter Funk wrote: > > > > What about calling this function 'permute()'? > > -1 on this: We are not looking for all possible pairings but for the > (possibly lazy) equivalent of map(None, list1, list2, ...). > > > BTW: How comes, that Ping very often invents or introduces very clever > > ideas and concepts, but also very often chooses unclear names for them? > > Is it just me not being a native english speaker? > > I still think "zip" is okay, but that's probably my Haskell background. > And no, I don't think it has to do something with not being a native > English speaker. It's probably more the context you associate with > "zip". > I can't comment on earlier cases, though. Just for completeness: mx.Tools already has these APIs: tuples(sequence) Returns much the same as apply(map,(None,)+tuple(sequence)) does, except that the resulting list will always have the length of the first sub-sequence in sequence. The function returns a list of tuples (a[0], b[0], c[0],...), (a[1], b[1], c[1],...), ... with missing elements being filled in with None. Note that the function is of the single argument type meaning that calling tuples(a,b,c) is the same as calling tuples((a,b,c)). tuples() can be used as inverse to lists(). lists(sequence) Same as tuples(sequence), except that a tuple of lists is returned. Can be used as inverse to tuples(). and these have also proven useful: dict(items) Constructs a dictionary from the given items sequence. The sequence items must contain sequence entries with at least two values. The first one is interpreted as key, the second one as associated object. Remaining values are ignored. irange(object[,indices]) Builds a tuple of tuples (index,object[index]). If a sequence indices is given, the indices are read from it. If not, then the index sequence defaults to trange(len(object)). Note that object can be any object that can handle object[index], e.g. lists, tuples, string, dictionaries, even your own objects, if they provide a __getitem__-method. This makes very nifty constructions possible and extracting items from another sequence becomes a piece of cake. Give it a try ! You'll soon love this little function. indices(object) Returns the same as tuple(range(len(object))) -- a tad faster and a lot easier to type. I'm sure Python could steal a few of those ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Wed Jul 12 10:37:53 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 01:37:53 -0700 Subject: [Python-Dev] Memory leak tracking In-Reply-To: <14699.64688.697935.541901@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 12, 2000 at 01:05:52AM -0400 References: <14699.30119.262274.258429@anthem.concentric.net> <200007120550.AAA12465@cj20424-a.reston1.va.home.com> <14699.64688.697935.541901@anthem.concentric.net> Message-ID: <20000712013753.P29590@lyra.org> On Wed, Jul 12, 2000 at 01:05:52AM -0400, Barry A. Warsaw wrote: >... > I suspect this is exactly what's happening. I'd have to spend more > time to know exactly what's happening, but this jives with the > observed behavior. If so, the only thing we could do is try to break > the cycles manually at shutdown time and have the normal decrefs free > all the memory. > > I'm not sure it's worth the effort. 1) it isn't much memory; 2) it > only leaks when gc is disabled; 3) it's a one time cost, not > e.g. a leak every time you spawn a thread. > > That last is interesting, because I believe at least on Solaris, there > /is/ a leak for each new thread, but I haven't had time to find it > yet. That one's worth tracking down. For the others, it's actually > quite nice to see gc doing it's job! > > Other than that, running the test suite, the current CVS seems to have > a very clean bill of health memory usage-wise. Please try to consider the embedded case, too. If Python interpreters are created/destroyed, or modules are loaded/thrown out, or whatever... are there leaks? Any leak can be a disaster in embedded cases. Now... no need to be defensive :-) ... just pointing out there is another consideration when thinking about leaks. Cheers, -g -- Greg Stein, http://www.lyra.org/ From ping at lfw.org Wed Jul 12 10:40:55 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 01:40:55 -0700 (PDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Peter Funk wrote: > ### > class Foo(Bar): > def pasted_method(self, ....) > #---^ note this additional blank here (resulting in a 5 space indent). > # ...a screenful of indented code snipped here... > def another_method(self, baz, bang): > #--------------------------------------^ > # Python 1.5.2 barfs here with "SyntaxError: invalid token" > ### > > This is not very intuitive and hard to see. The first time I stumbled > about this it has taken me quite some time to discover my mistake. Gee. Well, with the SyntaxError patch, at least the error message is much better (even though the arrow still points to the wrong place): >>> class foo: ... def foo(self): ... pass ... def foo(bar): File "", line 4 def foo(bar): ^ SyntaxError: dedent does not match any outer indentation level Not sure why the arrow points there... i would have expected it to point at the beginning of the line, since it did successfully detect that the indentation was wrong. Maybe i'll investigate. -- ?!ng From effbot at telia.com Wed Jul 12 10:41:47 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 10:41:47 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: Message-ID: <00fc01bfebdd$05eed060$f2a6b5d4@hagrid> michael wrote: > > In this case it's you not being a functional programmer; `zip' seems > perfectly natural to the part of my brain that speaks Haskell. > > Think zip as in "zipper"; this more sense to me than naming a compression > algorithm "zip"... > footnote: merriam webster says: ... 1. to move, act, or function with speed and vigor ... 5. to close or open with or as if with a zipper ... I also checked two british dictionaries; the older only mentioned the first sense, the newer only the second. fwiw, the newer claims to be based on a "detailed ana- lysis of how modern English is really used". go figure. From mal at lemburg.com Wed Jul 12 10:36:38 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 12 Jul 2000 10:36:38 +0200 Subject: [Python-Dev] APIs for internal flags References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <200007101722.MAA01227@cj20424-a.reston1.va.home.com> <396A08AF.655B4836@lemburg.com> <200007101936.OAA02180@cj20424-a.reston1.va.home.com> Message-ID: <396C2E16.38DAAE58@lemburg.com> Guido van Rossum wrote: > > > Yes... I meant: it is not available from Python. (mx.Tools > > publishes an interface to this flag: sys.verbosity() which > > also allows setting the value at runtime.) > > It would make a lot of sense for the sys module to allow access to the > values of all the Python command line options, and perhaps to allow > changing them. > > Anybody interested in designing an API here? Some requirements would > be platform independence, extensibility, and necessarily the ability > to work even in an environment without command line flags (since it > still has the corresponding internal flags). For starters, here's what mx.Tools defines: sys.verbosity([level]) If level is given, the value of the interpreter's verbosity flag is set to level and the previous value of that flag is returned. Otherwise, the current value is returned. You can use this function to e.g. enable verborse lookup output to stderr for import statements even when the interpreter was not invoked with '-v' or '-vv' switch or to force verbosity to be switched off. sys.debugging([level]) If level is given, the value of the interpreter's debugging flag is set to level and the previous value of that flag is returned. Otherwise, the current value is returned. You can use this function to check whether the interpreter was called with '-d' flag or not. Some extensions use this flag to enable/disable debugging log output (e.g. all the mx Extensions). sys.optimization([level]) If level is given, the value of the interpreter's optimization flag is set to level and the previous value of that flag is returned. Otherwise, the current value is returned. You can use this function to e.g. compile Python scripts in optimized mode even though the interpreter was not started with -O. Perhaps a more generic interface would be nicer, but given that not all flags are really useful and some of them may not be altered after initialization, I find the per flag interfaces fit rather well (they also have the advantage of being able to add code on a per flag basis, which may become useful for future additions). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Wed Jul 12 10:43:38 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 01:43:38 -0700 Subject: [Python-Dev] File Object Copy In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jul 12, 2000 at 10:21:08AM +0300 References: Message-ID: <20000712014338.Q29590@lyra.org> On Wed, Jul 12, 2000 at 10:21:08AM +0300, Moshe Zadka wrote: > On Wed, 12 Jul 2000, Peter Funk wrote: > > 'shutil.copyfile' however takes filenames as arguments and contains > > the loop sketched above as inline code. I see two possibilities: > > 1. It would be easy to skip the open and close operations in > > 'shutil.copyfile', if either 'src' or 'dst' are already open > > file objects instead of strings. > > -0: Too much Perl-like DWIM magic > > > 2. Or you factor out the copy loop operation above and rename it into > > 'copycontent' or 'copybytes' or whatever. > > Of course it should be factored out: but the question remains, why shell > utils? Do you really think copybytes belongs there? Add shutil.copyfileob(src_file_ob, dst_file_ob). shutil.copyfile() can call it after opening the files. Does that function make absolute sense there? Tough question. It sure happens to work well, considered the dependent function copyfile(). I imagine there are a bazillion functions that could be re-factored. No sense getting overly concerned. Put the bugger in shutil for now. Step two: propose a new organization. Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul at prescod.net Wed Jul 12 10:52:41 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 03:52:41 -0500 Subject: [Python-Dev] list comprehensions again... References: <1248755410-33702453@hypernet.com> Message-ID: <396C31D9.4658CFD7@prescod.net> Gordon McMillan wrote: > > Paul Prescod wrote: > > > Nested (List): > > > > [for x in (0,10,20,30): > > for y in (0,1,2,3): > > x+y] > > [0,11,22,33] > > Not what I'd expect at all. No, I'm just an idiot. What you expect is what I meant. No excuse. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Wed Jul 12 11:04:27 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 11:04:27 +0200 Subject: [Python-Dev] File Object Copy References: <20000712014338.Q29590@lyra.org> Message-ID: <011401bfebe0$2f388c60$f2a6b5d4@hagrid> moshe wrote: > > > 1. It would be easy to skip the open and close operations in > > > 'shutil.copyfile', if either 'src' or 'dst' are already open > > > file objects instead of strings. > > > > -0: Too much Perl-like DWIM magic footnote: it's definitely an accepted pydiom: aifc.py: if type(f) == type(''): f = __builtin__.open(f, 'rb') binhex.py: if type(ofp) == type(''): ofname = ofp ofp = open(ofname, 'w') mimify.py: if type(infile) == type(''): ifile = open(infile) pstats.py: elif type(arg) == type(""): f = open(arg, 'rb') etc. it's a reasonable way to make your code a bit more reusable (it's rude to expect every chunk of potentially usable data to have a filename...). From peter at schneider-kamp.de Wed Jul 12 12:59:09 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 12 Jul 2000 10:59:09 +0000 Subject: [Python-Dev] zip() and list-comprehension with commas References: Message-ID: <396C4F7D.288B561D@schneider-kamp.de> Ka-Ping Yee wrote: > > On Wed, 12 Jul 2000, Peter Schneider-Kamp wrote: > > +1 on this. no performance hit (probably a small gain), > > "zip" is imho the right name (see e.g. haskell). > > Indeed, a nice coincidence. :) off-topic: I am still thinking about higher order functions in Python: e.g.: map(+ 1, [1, 2, 3]) instead of map(lambda x: x + 1, [1, 2, 3]) don't have a clue how to do that yet. > Alas, the vertical bar is already a bitwise-or operator, and > couldn't safely be placed next to the . [...] > Semicolon might be worth considering here, actually: [f(x); for x in l] Better than just a comma anyway. Okay for me. > [(x, y), for x in list1, if x > 1, for y in list2, if y > 2] [...] > The first would produce [(2, 3), (3, 3)], and the second would > It would have to be written: > > [(x, y, z), for x in l1, for y in l2, for z in l3] but that's loosing some of it's beauty for me. if we'd use the semicolon [ x, y, z; for x in l1, for y in l2, for z in l3] looks better to me. okay, really heading off to work now, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From moshez at math.huji.ac.il Wed Jul 12 11:06:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 12:06:06 +0300 (IDT) Subject: [Python-Dev] File Object Copy In-Reply-To: <20000712014338.Q29590@lyra.org> Message-ID: On Wed, 12 Jul 2000, Greg Stein wrote: > Add shutil.copyfileob(src_file_ob, dst_file_ob). shutil.copyfile() can call > it after opening the files. Done. Can someone who is able to checkin assign it to themselves? > Does that function make absolute sense there? Tough question. It sure > happens to work well, considered the dependent function copyfile(). I > imagine there are a bazillion functions that could be re-factored. No sense > getting overly concerned. > > Put the bugger in shutil for now. Step two: propose a new organization. Hmmmm...orthogonal to new organization, urllib and BaseHTTPServer need to be modified to call it. I'll do it as soon as the patch is accepted (100868) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Wed Jul 12 11:08:26 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 12:08:26 +0300 (IDT) Subject: [Python-Dev] File Object Copy In-Reply-To: <011401bfebe0$2f388c60$f2a6b5d4@hagrid> Message-ID: On Wed, 12 Jul 2000, Fredrik Lundh wrote: > footnote: it's definitely an accepted pydiom: Yes, but one I personally do not like > > aifc.py: > if type(f) == type(''): > f = __builtin__.open(f, 'rb') > > binhex.py: > if type(ofp) == type(''): > ofname = ofp > ofp = open(ofname, 'w') > > mimify.py: > if type(infile) == type(''): > ifile = open(infile) > > pstats.py: > elif type(arg) == type(""): > f = open(arg, 'rb') > > etc. > > it's a reasonable way to make your code a bit more reusable > (it's rude to expect every chunk of potentially usable data to > have a filename...). Of course -- that's why I think most code should use file-like objects. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul at prescod.net Wed Jul 12 11:25:33 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:25:33 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> Message-ID: <396C398D.9F85F8A8@prescod.net> "Barry A. Warsaw" wrote: > [Python is becoming Perl] > | print [i, s for i in nums for s in strs] Let me try my syntax on this example: print [for i in nums: for s in strs: i, s] I don't see that as being any worse than the procedural syntax. > | print [i, s for i in nums for s in [f for f in strs if "n" in f]] I don't see this as being a realistic example. First, let me ask whether you think that reasonable programmers are actually going to come up with this. Why wouldn't they use a temporary variable for s? When nesting gets deep, reasonable programmers try to unroll it, whether it is in a.b.c.d.e or a(b(c(d(e())))) or list comps. In fact, we know that most UNreasonable programmers can be swayed with arguments from efficiency. You are computing the value of s over and over again "num" times. It makes no sense to do it that way. I think that my syntax would make this clearer (of course I would!): print [ for i in nums: for s in [for f in strs: if "n" in f: f] (i,s)] You can see that nothing from the outer loop is being used in the inner one, so what's the point in having it there? Better: s=[for f in strs: if "n" in f: f] print [for i in nums: (i,s)] Which to me is a nicer way of saying what we today say as: map( None, nums, [s]*len(nums)] If you want to confuse a newbie, I'll claim that the "map" version will do it more than the list comp. version. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From ping at lfw.org Wed Jul 12 11:35:21 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 02:35:21 -0700 (PDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Peter Funk wrote: > > BTW: How comes, that Ping very often invents or introduces very clever > ideas and concepts, Gee, thanks. :) I feel a group hug coming on. > but also very often chooses unclear names for them? > Is it just me not being a native english speaker? I don't know. Perhaps my florx bignal zupkin isn't very moognacious? Shlarp mixon ru, but tralorping weefibbledon groxit zanquar bladu. Bladu bladu. Woom! Greefon sip habligor? (Chalar icko neevour, & blafare ort lirriless.) Bladiblipifiribble a wompy idea: >>> def klaatu(): # Verata nikto. ... phwee File "", line 2 phwee ^ HolyGrailError: see the violence inherent in the system Ruinon flast. Elninfrawok? - Glidimon. - Fip milang freebik. Ip nane (varblig nane) refilk ruzzin. - Zom plut 'klaatu()' ix 'klaatu(spam)' etc. - Hilliban dreef? Neems 'ploo' girdar oioizoik: >>> 3 3 >>> 4 4 >>> 5 HolyGrailError: five is right out >>> [1:4] [1, 2, 5] Jodinat greidar fablo! Ruinon flast; ruinon flast. Thorvon whananadak yum, onk triplation is dortiful. <0.5 wink> Ecky-ecky-ecky-ecky-pikang-zoop-boing? -- ?!ng From paul at prescod.net Wed Jul 12 11:29:30 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:29:30 -0500 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: Message-ID: <396C3A7A.75CA43B3@prescod.net> Peter Funk wrote: > > ... > > +1 on the concept. > -1 on calling it 'zip' (I was first thinking of Info ZIP and zlib). > -0 on calling it 'parallel' (makes me thinking of threads and processes). > > What about calling this function 'permute()'? But zip is not permute! zip( [0,1,2,3,4],[0,10,20,30,40])=[0,11,22,33,44] Anyhow, I kind of like the names tuples() and lists(), as proposed by MAL. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From ping at lfw.org Wed Jul 12 11:47:16 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 02:47:16 -0700 (PDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <396C3A7A.75CA43B3@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > > But zip is not permute! > > zip( [0,1,2,3,4],[0,10,20,30,40])=[0,11,22,33,44] You mean zip([0,1,2,3,4], [0,10,20,30,40]) -> [(0,0), (1,10), (2,20), (3,30), (4,40)] (It's late... maybe we all need some sleep.) :) -- ?!ng From paul at prescod.net Wed Jul 12 11:41:43 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:41:43 -0500 Subject: [Python-Dev] zip() and list-comprehension with commas References: <396C41C1.5A1C7652@schneider-kamp.de> Message-ID: <396C3D57.61328C2D@prescod.net> Peter Schneider-Kamp wrote: > > > Would [x,y , for x in list1, if x > 1, if y > 2, for y in list2] > be allowed? In other words: Should there be some rules of ordering? Would this syntax make the answer clearer: [for x in list1: if x > 1: if y > 2: for y in list2: x,y] I don't think that makes sense unless y is externally bound. > Would the following be allowed (and desirable)? > y = 3 > [ x + y , for x in [1, 2, 3], if x > 1] > producing [5, 6] y = 3 [for x in [1, 2, 3]: if x > 1: x + y] Sure, getting around Python's name binding "issues" is one of the (side) benefits of list comprehensions. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From jack at oratrix.nl Wed Jul 12 11:44:46 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 11:44:46 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message by Michael Hudson , Wed, 12 Jul 2000 09:27:50 +0100 (BST) , Message-ID: <20000712094447.2275337186D@snelboot.oratrix.nl> parallel()/zip() have an other advantage: it would be easy to extend to let the loop continue until the longest of the items, with a keyword argument: parallel((1, 2), (3, 4, 5), missing=None) # or extend, or some other name would return ((1, 3), (2, 4), (None, 5)) By the way: -1 on the name zip() and -0 on the name parallel(), but +1 on the concept. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paul at prescod.net Wed Jul 12 11:44:07 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:44:07 -0500 Subject: [Python-Dev] zip() and list-comprehension with commas References: Message-ID: <396C3DE7.367B569D@prescod.net> Ka-Ping Yee wrote: > > > As for the SyntaxError, i think it's a good idea because the > example could be ambiguous. You would have to either say > > [(x, y), for x in list1, if x > 1, for y in list2, if y > 2] > > or > > [x] + [y, for x in list1, if x > 1, for y in list2, if y > 2] The easy way to avoid the ambiguity is to dump the comma and use colons as Guido intended. [for x in list1: if x > 1: for y in list2: if y > 2: (x,y)] -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From jack at oratrix.nl Wed Jul 12 11:49:56 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 11:49:56 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message by Ka-Ping Yee , Wed, 12 Jul 2000 02:35:21 -0700 (PDT) , Message-ID: <20000712094956.A456437186D@snelboot.oratrix.nl> > Ecky-ecky-ecky-ecky-pikang-zoop-boing? > > > -- ?!ng Shouldn't that be "Ecky-ecky-ecky-ecky-pikang-zoop-boing'ly yours," ? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paul at prescod.net Wed Jul 12 11:55:11 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 04:55:11 -0500 Subject: [Python-Dev] New builtins References: <396C4596.C64D4EE6@schneider-kamp.de> <396C2D00.BDA23AF2@lemburg.com> Message-ID: <396C407F.CAB2584A@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Just for completeness: mx.Tools already has these APIs: > > tuples(sequence) > Returns much the same as apply(map,(None,)+tuple(sequence)) does, Like it. > lists(sequence) > Same as tuples(sequence), except that a tuple of lists is returned. Like it. > dict(items) > Constructs a dictionary from the given items sequence. Like it. In my opinion, these are naturals for built-in functions. Cool! These I'm not as sure about: > irange(object[,indices]) > Builds a tuple of tuples (index,object[index]). Isn't this just tuples( indices( object ), object ) > indices(object) > Returns the same as tuple(range(len(object))) -- Could be obsoleted by the range-building syntax: [0..len(object)] would do the same thing. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gstein at lyra.org Wed Jul 12 12:01:56 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:01:56 -0700 Subject: [Python-Dev] File Object Copy In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jul 12, 2000 at 12:06:06PM +0300 References: <20000712014338.Q29590@lyra.org> Message-ID: <20000712030156.U29590@lyra.org> On Wed, Jul 12, 2000 at 12:06:06PM +0300, Moshe Zadka wrote: > On Wed, 12 Jul 2000, Greg Stein wrote: > > > Add shutil.copyfileob(src_file_ob, dst_file_ob). shutil.copyfile() can call > > it after opening the files. > > Done. Can someone who is able to checkin assign it to themselves? Checked in, and the patch is now closed. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Wed Jul 12 12:05:56 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:05:56 -0700 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: ; from ping@lfw.org on Wed, Jul 12, 2000 at 02:35:21AM -0700 References: Message-ID: <20000712030556.V29590@lyra.org> All right. Now this is just whacked. "Step *away* from the drugs and nobody will get hurt." Damn, Ping. You rock. -g On Wed, Jul 12, 2000 at 02:35:21AM -0700, Ka-Ping Yee wrote: > On Wed, 12 Jul 2000, Peter Funk wrote: > > > > BTW: How comes, that Ping very often invents or introduces very clever > > ideas and concepts, > > Gee, thanks. :) I feel a group hug coming on. > > > but also very often chooses unclear names for them? > > Is it just me not being a native english speaker? > > I don't know. Perhaps my florx bignal zupkin isn't very moognacious? > > Shlarp mixon ru, but tralorping weefibbledon groxit zanquar bladu. > Bladu bladu. Woom! Greefon sip habligor? (Chalar icko neevour, & > blafare ort lirriless.) > > Bladiblipifiribble a wompy idea: > > >>> def klaatu(): # Verata nikto. > ... phwee > File "", line 2 > phwee > ^ > HolyGrailError: see the violence inherent in the system > > Ruinon flast. Elninfrawok? > > - Glidimon. > - Fip milang freebik. Ip nane (varblig nane) refilk ruzzin. > - Zom plut 'klaatu()' ix 'klaatu(spam)' etc. > - Hilliban dreef? > > Neems 'ploo' girdar oioizoik: > > >>> 3 > 3 > >>> 4 > 4 > >>> 5 > HolyGrailError: five is right out > >>> [1:4] > [1, 2, 5] > > Jodinat greidar fablo! Ruinon flast; ruinon flast. Thorvon > whananadak yum, onk triplation is dortiful. <0.5 wink> > > Ecky-ecky-ecky-ecky-pikang-zoop-boing? > > > -- ?!ng > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Wed Jul 12 12:10:48 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:10:48 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396C398D.9F85F8A8@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 04:25:33AM -0500 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> <396C398D.9F85F8A8@prescod.net> Message-ID: <20000712031048.W29590@lyra.org> On Wed, Jul 12, 2000 at 04:25:33AM -0500, Paul Prescod wrote: >... > If you want to confuse a newbie, I'll claim that the "map" version will > do it more than the list comp. version. Just because map() might confuse people doesn't mean it is now okay to introduce *more* confusion. "Gee, officer... there isn't a law against driving stoned. So I figured driving all whacked out on heroin is okay, too." Cheers, -g -- Greg Stein, http://www.lyra.org/ From ping at lfw.org Wed Jul 12 12:14:54 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 12 Jul 2000 03:14:54 -0700 (PDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C3DE7.367B569D@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > > The easy way to avoid the ambiguity is to dump the comma and use colons > as Guido intended. > > [for x in list1: > if x > 1: > for y in list2: > if y > 2: > (x,y)] Does indentation matter, and are you proposing blocks of "real" code in there? I suspect that writing it this way is going to tempt people to include more code, maybe expect to be able to write "else" clauses, put in "break", etc. I think if you do it this way, the above is so close to how you'd write it without list comprehensions that it largely eliminates the succinctness that motivated list comprehensions in the first place. -- ?!ng From gstein at lyra.org Wed Jul 12 12:13:58 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:13:58 -0700 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: ; from andy@reportlab.com on Wed, Jul 12, 2000 at 07:52:05AM +0100 References: Message-ID: <20000712031358.X29590@lyra.org> On Wed, Jul 12, 2000 at 07:52:05AM +0100, Andy Robinson wrote: >... > Are there many other applications which > use compression? If so, would it do > be feasible to include it by default > from version 1.6? I believe the correct approach would be to have ./configure look for zlib. If present, then it should include the module into the build. [ this auto-build style could apply to many modules, actually ] There would need to be a way to override this auto-build of a module. >... > p.s. I can submit a patch if needed :-) This would be great. I'd recommend a patch against configure.in and associated files. (Modules/Setup.* ?) Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Wed Jul 12 12:18:03 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 12 Jul 2000 12:18:03 +0200 Subject: [Python-Dev] New builtins References: <396C4596.C64D4EE6@schneider-kamp.de> <396C2D00.BDA23AF2@lemburg.com> <396C407F.CAB2584A@prescod.net> Message-ID: <396C45DB.B58D9B51@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > Just for completeness: mx.Tools already has these APIs: > > > > tuples(sequence) > > Returns much the same as apply(map,(None,)+tuple(sequence)) does, > > Like it. > > > lists(sequence) > > Same as tuples(sequence), except that a tuple of lists is returned. > > Like it. > > > dict(items) > > Constructs a dictionary from the given items sequence. > > Like it. > > In my opinion, these are naturals for built-in functions. Cool! > > These I'm not as sure about: > > > irange(object[,indices]) > > Builds a tuple of tuples (index,object[index]). > > Isn't this just tuples( indices( object ), object ) Yep, but less to write... > > indices(object) > > Returns the same as tuple(range(len(object))) -- > > Could be obsoleted by the range-building syntax: > > [0..len(object)] > > would do the same thing. True, except that I find indices(obj) more intuitive (and its just one function call). Technical note: tuples build faster than lists. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Wed Jul 12 12:19:07 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 13:19:07 +0300 (IDT) Subject: [Python-Dev] SF again: Patch assignments Message-ID: Can anyone send me a clear explanation how to assign a patch to someone? I've spent 10 minutes roomaging around SF to no avail. sf-can-be-frustrating-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From pf at artcom-gmbh.de Wed Jul 12 12:16:24 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 12 Jul 2000 12:16:24 +0200 (MEST) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: from Ka-Ping Yee at "Jul 12, 2000 2:36:33 am" Message-ID: > On Wed, 12 Jul 2000, Peter Funk wrote: > > BTW: How comes, that Ping very often invents or introduces very clever > > ideas and concepts, but also very often chooses unclear names for them? > > Is it just me not being a native english speaker? > Ka-Ping Yee schrieb: > Sorry for the silly reply. :) Honestly, i'm curious, though. > What kinds of things have been unclear to you before? It would > be instructive for me to know... Sorry: I take that back. It was just me. I've justed browsed through your articles in the 2000 python-dev archive and the only thing I found is your 'Notifier' class proposal containing method names like 'denotify'. (http://www.python.org/pipermail/python-dev/2000-April/010367.html http://www.python.org/pipermail/python-dev/2000-April/010368.html) Obviously my memory was blurred. Regards, Peter From gstein at lyra.org Wed Jul 12 12:41:31 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 03:41:31 -0700 Subject: [Python-Dev] SF again: Patch assignments In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jul 12, 2000 at 01:19:07PM +0300 References: Message-ID: <20000712034131.B29590@lyra.org> On Wed, Jul 12, 2000 at 01:19:07PM +0300, Moshe Zadka wrote: > > Can anyone send me a clear explanation how to assign a patch to someone? > I've spent 10 minutes roomaging around SF to no avail. I just click on the patch itself. In the screen that comes up, there is a drop-box for "Assigned To:" where I can select a person. After selecting the appropriate victim, I hit the "Submit Changes" button at the bottom of the page. Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul at prescod.net Wed Jul 12 12:48:35 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 05:48:35 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> <396C398D.9F85F8A8@prescod.net> <20000712031048.W29590@lyra.org> Message-ID: <396C4D03.D4F1F8E7@prescod.net> Greg Stein wrote: > > On Wed, Jul 12, 2000 at 04:25:33AM -0500, Paul Prescod wrote: > >... > > If you want to confuse a newbie, I'll claim that the "map" version will > > do it more than the list comp. version. > > Just because map() might confuse people doesn't mean it is now okay to > introduce *more* confusion. But the map version is a very common convention! If we can make a common convention more readable, that's a net win. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From peter at schneider-kamp.de Wed Jul 12 15:09:12 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 12 Jul 2000 13:09:12 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules flmodule.c,1.40,1.41 fmmodule.c,1.14,1.15 References: <200007121043.DAA27255@slayer.i.sourceforge.net> Message-ID: <396C6DF8.42C314E1@schneider-kamp.de> Sjoerd Mullender wrote: > > Fixed up some ANSIfications. oops. One typo and one wrong replace. I was probably getting tired ,-) Thnx Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gstein at lyra.org Wed Jul 12 13:15:14 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 12 Jul 2000 04:15:14 -0700 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396C4D03.D4F1F8E7@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 05:48:35AM -0500 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> <396C398D.9F85F8A8@prescod.net> <20000712031048.W29590@lyra.org> <396C4D03.D4F1F8E7@prescod.net> Message-ID: <20000712041513.C29590@lyra.org> On Wed, Jul 12, 2000 at 05:48:35AM -0500, Paul Prescod wrote: > Greg Stein wrote: > > > > On Wed, Jul 12, 2000 at 04:25:33AM -0500, Paul Prescod wrote: > > >... > > > If you want to confuse a newbie, I'll claim that the "map" version will > > > do it more than the list comp. version. > > > > Just because map() might confuse people doesn't mean it is now okay to > > introduce *more* confusion. > > But the map version is a very common convention! If we can make a common > convention more readable, that's a net win. Agreed, to a point. The counter-point is: "let's introduce syntax to make FOO more readable. great. now lets introduce syntax to make BAR more readable. sweet. how about BAZ?" There are a lot of common idioms in Python. How many do you want to add *syntax* for? Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Wed Jul 12 14:19:14 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 07:19:14 -0500 Subject: [Python-Dev] APIs for internal flags In-Reply-To: Your message of "Wed, 12 Jul 2000 10:36:38 +0200." <396C2E16.38DAAE58@lemburg.com> References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <200007101722.MAA01227@cj20424-a.reston1.va.home.com> <396A08AF.655B4836@lemburg.com> <200007101936.OAA02180@cj20424-a.reston1.va.home.com> <396C2E16.38DAAE58@lemburg.com> Message-ID: <200007121219.HAA13436@cj20424-a.reston1.va.home.com> [me] > > Anybody interested in designing an API here? Some requirements would > > be platform independence, extensibility, and necessarily the ability > > to work even in an environment without command line flags (since it > > still has the corresponding internal flags). [MAL] > For starters, here's what mx.Tools defines: > > sys.verbosity([level]) > sys.debugging([level]) > sys.optimization([level]) [...] +1 on the concept. All the other routines in sys seem to have 'set' or 'get' in their name (e.g. get/setdefaultencoding). Maybe we should conform to that? You could argue over names, e.g. get/setverbosity, get/setdebuglevel, get/setoptlevel. Are there any other flags that you might want to know about? -i,-c,-x irrelevant -S possibly -t yes --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul at prescod.net Wed Jul 12 13:21:56 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 06:21:56 -0500 Subject: [Python-Dev] zip() and list-comprehension with commas References: Message-ID: <396C54D4.A7855CC4@prescod.net> Ka-Ping Yee wrote: > > ... > > Does indentation matter, I'd say no. It is an expression in parens. Arguably, we could make the actual line breaks optional also: [for x in list1: if x > 1: for y in list2: if y > 2: (x,y)] > and are you proposing blocks of "real" code in there? No. Just expressions. > I suspect that writing it this way > is going to tempt people to include more code, maybe expect > to be able to write "else" clauses, put in "break", etc. Miscomprehensions of this sort will not last long. It won't fail silently! else might be a useful extension. (future version!) abs=[for x in nums: if x>0: x else: -x] There is the danger of introducing the ambiguous else. > I think if you do it this way, the above is so close to how > you'd write it without list comprehensions that it largely > eliminates the succinctness that motivated list comprehensions > in the first place. It sounds like you are saying that the real benefit of list comprehensions is that they allow you to avoid newlines! Anyhow, if you don't like the newlines, I think we can make them optional without losing anything. Then this syntax is as compact as the original. The colon syntax is very clear about the fact that the lists are not evaluated in parallel. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Wed Jul 12 13:27:44 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 06:27:44 -0500 Subject: [Python-Dev] list comprehensions again... References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <14699.40820.255217.346654@beluga.mojam.com> <14699.58516.791911.405213@anthem.concentric.net> <396C398D.9F85F8A8@prescod.net> <20000712031048.W29590@lyra.org> <396C4D03.D4F1F8E7@prescod.net> <20000712041513.C29590@lyra.org> Message-ID: <396C5630.AEB894B5@prescod.net> Greg Stein wrote: > > ... > > Agreed, to a point. > > The counter-point is: "let's introduce syntax to make FOO more readable. > great. now lets introduce syntax to make BAR more readable. sweet. how about > BAZ?" > > There are a lot of common idioms in Python. How many do you want to add > *syntax* for? In this case, we're replacing four conventions: map( None, a, [b]*len(a)) map( lambda x: ... ) filter( lambda x: ...) a=[] for i in j: a.append( something( i )) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From akuchlin at cnri.reston.va.us Wed Jul 12 13:59:15 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Wed, 12 Jul 2000 07:59:15 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <20000712031358.X29590@lyra.org>; from gstein@lyra.org on Wed, Jul 12, 2000 at 03:13:58AM -0700 References: <20000712031358.X29590@lyra.org> Message-ID: <20000712075915.A17856@newcnri.cnri.reston.va.us> On Wed, Jul 12, 2000 at 03:13:58AM -0700, Greg Stein wrote: >[ this auto-build style could apply to many modules, actually ] I'm working on a patch for using a setup.py file and the Distutils to build the standard library; Setup.in then contains only those few modules needed to run the Distutils, and you'd never need to modify it. Not done yet, though... --amk From thomas at xs4all.net Wed Jul 12 14:07:37 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 14:07:37 +0200 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <396B9B91.E33D8C58@prescod.net>; from paul@prescod.net on Tue, Jul 11, 2000 at 05:11:29PM -0500 References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> <20000711234737.D7340@xs4all.nl> <396B9B91.E33D8C58@prescod.net> Message-ID: <20000712140737.G7340@xs4all.nl> On Tue, Jul 11, 2000 at 05:11:29PM -0500, Paul Prescod wrote: > Thomas Wouters wrote: > > .... They provide an easier way to create a list, but they don't > > eradicate the need for map, reduce or filter, because there is no way to > > comprehend an already created list. > What do you mean? I think I see examples of list comprehensions working > on existing lists on this page: > http://www.cosc.canterbury.ac.nz/~greg/python/listcomp/ > numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] > evens = [x for x in numbers if x % 2 == 0] # filter > mult3 = [3 * x for x in numbers] # map Yes, sorry, I don't know what posessed me to say that, I was obviously mistaken. What can I say, it was late, I was exhausted ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Wed Jul 12 14:06:29 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 07:06:29 -0500 Subject: [Python-Dev] List comp. sci fi Message-ID: <396C5F45.A8267A96@prescod.net> There is this idea on the edge of my brain that has to get out. I'm afraid of overloading the idea too much while people are still uncomfortable with the basics but at the same time I think that it is exciting that there could be more power in list comprehensions than pure syntactic sugar. What if list comprehensions were lazy? They would be objects that generate the items one at a time. Does this kill two birds with one stone? Or just conflate two separate ideas? Consider: naturals=[for num in [0:sys.maxint]] # does not construct list!! evens=[for num in naturals: if num%2==0: num ] # ditto!! chunks=[for chunk in file.read( 2048 ): chunk] # ditto!! databaseRecords=[for rec in SQL.Execute( "..." ): rec ] ditto!! Let's presume that name bindings are lexical and cyclic garbage collection works as we expect it to. Converting lazy behavior to eager is easy: chunkList=tuple( chunks ) I'm not up to it right now, but I'm sure that there is a nice way to combine sre and lazy comprehensions to get objects that return "hits" in a string one at a time. How to implement this? Stackless Python. As my friend Joy says: Go for the big one or stay at home. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gvwilson at nevex.com Wed Jul 12 14:10:52 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 12 Jul 2000 08:10:52 -0400 (EDT) Subject: [Python-Dev] second experiment Message-ID: I'm giving a talk at the U. of Toronto tomorrow, and would like to re-run the "what does it do?" experiment with list comprehensions and simultaneous loops. I propose asking the following: The program: for x in [10, 20, 30]: print x prints: 10 20 30 and the program: for x in [10, 20, 30]: for y in [1, 2, 3]: print x+y prints: 11 12 13 21 22 23 31 32 33 Match each of the following: (A) for x in [10, 20, 30]; y in [1, 2, 3]: print x+y (B) for (x,y) in zip([10, 20, 30], [1, 2, 3]): print x+y (C) for (x in [10, 20, 30]) and (y in [1, 2, 3]): print x+y (D) something else to their output: (1) 11 22 33 (2) 11 12 13 21 22 23 31 32 33 (3) "Run-Time Error" Questions: 1. What should option (D) be? 2. Should the lists be the same length, or different lengths? I think the latter is the trickier case (equally reasonable to say "iterate for length of shortest" and "error if lists' lengths unequal") --- is that worth testing? 3. Can someone provide a couple of list comprehension alternatives as well? Reactions? Greg From guido at beopen.com Wed Jul 12 15:18:04 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 08:18:04 -0500 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: Your message of "Wed, 12 Jul 2000 03:13:58 MST." <20000712031358.X29590@lyra.org> References: <20000712031358.X29590@lyra.org> Message-ID: <200007121318.IAA14063@cj20424-a.reston1.va.home.com> > On Wed, Jul 12, 2000 at 07:52:05AM +0100, Andy Robinson wrote: > >... > > Are there many other applications which > > use compression? If so, would it do > > be feasible to include it by default > > from version 1.6? > > I believe the correct approach would be to have ./configure look for zlib. > If present, then it should include the module into the build. > [ this auto-build style could apply to many modules, actually ] > > There would need to be a way to override this auto-build of a module. > > >... > > p.s. I can submit a patch if needed :-) > > This would be great. I'd recommend a patch against configure.in and > associated files. (Modules/Setup.* ?) Greg subtly points out the difficulty with your proposal: this requires an external library that may not be available. In the past we've had enough complaints from people who failed to realize that if the build failed because of a missing external library, they could just disable the module that needs it. So I'm not for simply having it enabled in Setup.in by default. I would love to have a mechanism (run by configure or maybe better by makesetup) that automatically determines if a particular external library package is available. Come to think of it, in first approximation, makesetup could easily parse the -I, -L and -l options you specify for a particular extension and only build it if it can find all those... But it's a bit of work! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Wed Jul 12 15:21:18 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 08:21:18 -0500 Subject: [Python-Dev] File Object Copy In-Reply-To: Your message of "Wed, 12 Jul 2000 12:08:26 +0300." References: Message-ID: <200007121321.IAA14098@cj20424-a.reston1.va.home.com> > > footnote: it's definitely an accepted pydiom: > > Yes, but one I personally do not like > > > aifc.py: > > if type(f) == type(''): > > f = __builtin__.open(f, 'rb') > > etc. > > > > it's a reasonable way to make your code a bit more reusable > > (it's rude to expect every chunk of potentially usable data to > > have a filename...). > > Of course -- that's why I think most code should use file-like objects. Agreed. The quoted examples are all kludges in my book. (The API designer initially accepted only a filename, then realized this was a bad choice, and fixed it in a backwards compatible way instead of fixing it right. There are just as many examples where it's done right, I just can't think of any. :-) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Wed Jul 12 14:24:19 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 12 Jul 2000 08:24:19 -0400 (EDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: References: Message-ID: <14700.25459.555611.544163@bitdiddle.concentric.net> >>>>> "KPY" == Ka-Ping Yee writes: KPY> Gee. Well, with the SyntaxError patch, at least the error KPY> message is much better (even though the arrow still points to KPY> the wrong place): >>> class foo: ... def foo(self): ... pass ... def foo(bar): File "", line 4 def foo(bar): ^ SyntaxError: dedent does not match any outer indentation level The error message is different and given a little phrasebook that translates between the exception and English, it may actually be better <0.3 wink>. I don't know what a dedent is. Nor do I know what "outer indentation levels" are or how they might apply to the line "def foo(bar):". I think the error message is trying to say "indentation does not match surrounding context," but other than "does not match" the words are obscure. Jeremy From jeremy at beopen.com Wed Jul 12 14:29:59 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 12 Jul 2000 08:29:59 -0400 (EDT) Subject: [Python-Dev] Windows build broken in exceptions.c In-Reply-To: <00c401bfebd9$e6d347e0$f2a6b5d4@hagrid> References: <00c401bfebd9$e6d347e0$f2a6b5d4@hagrid> Message-ID: <14700.25799.891112.727921@bitdiddle.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> tim wrote: >> exceptions.c(93) : error C2026: string too big, trailing >> characters truncated FL> and incidentally, I just got: FL> SyntaxError: expression too long FL> from python. Hey! That's cool. In earlier versions, you would have gotten a core dump. Jeremy From guido at beopen.com Wed Jul 12 15:27:51 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 08:27:51 -0500 Subject: [Python-Dev] SF again: Patch assignments In-Reply-To: Your message of "Wed, 12 Jul 2000 03:41:31 MST." <20000712034131.B29590@lyra.org> References: <20000712034131.B29590@lyra.org> Message-ID: <200007121327.IAA14145@cj20424-a.reston1.va.home.com> > > Can anyone send me a clear explanation how to assign a patch to someone? > > I've spent 10 minutes roomaging around SF to no avail. > > I just click on the patch itself. In the screen that comes up, there is a > drop-box for "Assigned To:" where I can select a person. After selecting the > appropriate victim, I hit the "Submit Changes" button at the bottom of the > page. Moshe didn't see the drop-box because his permissions didn't include assigning patches. I've fixed this (as a policy, we give everyone with checkin permissions tech&admin permissions for the patch manager, but that's not the SF default, so it must be done manually). This is the second or third post from a new SF developer asking about this. We really need to set up our own SF FAQ soon! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Wed Jul 12 14:44:00 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 14:44:00 +0200 Subject: [Python-Dev] second experiment In-Reply-To: ; from gvwilson@nevex.com on Wed, Jul 12, 2000 at 08:10:52AM -0400 References: Message-ID: <20000712144400.H7340@xs4all.nl> On Wed, Jul 12, 2000 at 08:10:52AM -0400, Greg Wilson wrote: > (A) for x in [10, 20, 30]; y in [1, 2, 3]: > print x+y > > (B) for (x,y) in zip([10, 20, 30], [1, 2, 3]): > print x+y > > (C) for (x in [10, 20, 30]) and (y in [1, 2, 3]): > print x+y Hm, grouping them... Hadn't thought of that. That's going to be gruesome to implement, but it might just be possible. It isn't possible to use this 'and'-syntax without parentheses, in any case. > (D) something else for x in [10, 20, 30] while y in [1, 2, 3]: print x+y for x; y in [10, 20, 20]; [1, 2, 3]: print x+y > to their output: I'd suggest additional output, too: 4) 1 2 3 5) 10 20 30 And tell them they can match more than one construct to the same output ;-) > 2. Should the lists be the same length, or different lengths? I think the > latter is the trickier case (equally reasonable to say "iterate for > length of shortest" and "error if lists' lengths unequal") --- is that > worth testing? Probably... I'm not sure howmuch time you want to keep them busy. This is supposed to be intuitive, which means they shouldn't be pressured to find the right answer. > 3. Can someone provide a couple of list comprehension alternatives as > well? I'm not going there for a while. I'm dazed and confused about list comprehensions, that's for sure. Well, you can try seeing whether they think one of these should be zipped or cartesian product: [ x,y for x in [1, 2, 3] for y in [10, 20, 30] ] [ x;y for x in [1, 2, 3]; for y in [10, 20, 30] ] No use checking for commas, we'd have to re-write Pythons' parser or Grammar entirely to allow that. See my upcoming post on the various proposed alterantive syntaxes and why they aren't going to work ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw at beopen.com Wed Jul 12 15:05:40 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 09:05:40 -0400 (EDT) Subject: [Python-Dev] File Object Copy References: <200007121321.IAA14098@cj20424-a.reston1.va.home.com> Message-ID: <14700.27940.592190.150292@anthem.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> Of course -- that's why I think most code should use file-like >> objects. GvR> Agreed. The quoted examples are all kludges in my book. GvR> (The API designer initially accepted only a filename, then GvR> realized this was a bad choice, and fixed it in a backwards GvR> compatible way instead of fixing it right. There are just as GvR> many examples where it's done right, I just can't think of GvR> any. :-) rfc822.Message() -Barry From fredrik at pythonware.com Wed Jul 12 15:13:40 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 15:13:40 +0200 Subject: [Python-Dev] File Object Copy References: <200007121321.IAA14098@cj20424-a.reston1.va.home.com> Message-ID: <007a01bfec02$ffb5af90$0900a8c0@SPIFF> guido wrote: > > > it's a reasonable way to make your code a bit more reusable > > > (it's rude to expect every chunk of potentially usable data to > > > have a filename...). > > > > Of course -- that's why I think most code should use file-like objects. > > Agreed. The quoted examples are all kludges in my book. (The API > designer initially accepted only a filename, then realized this was a > bad choice, and fixed it in a backwards compatible way instead of > fixing it right. There are just as many examples where it's done > right, I just can't think of any. :-) really? personally, I think that inventing new method names just because the language doesn't happen to support method overloading is a much bigger kludge ;-) (just like multiple inheritance, overloading can surely be abused by overambitious designers, but *not* having it is way too limiting) otoh, unless someone wants to remove overloading emulation from the modules I mentioned, this is probably a bit off-topic... cheers /F From jack at oratrix.nl Wed Jul 12 15:19:59 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 15:19:59 +0200 Subject: [Python-Dev] second experiment In-Reply-To: Message by Greg Wilson , Wed, 12 Jul 2000 08:10:52 -0400 (EDT) , Message-ID: <20000712131959.D823037186D@snelboot.oratrix.nl> > 1. What should option (D) be? for (x, y) in [(10, 1), (20, 2), (30, 3)]: print x+y And I think it should be the first question, being the currently existing idiom. If non-pythoneers understand the current semantics but not the new ones there's a problem. Oh yes, maybe you should add an answer 4: I haven't the faintest idea. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From gvwilson at nevex.com Wed Jul 12 15:26:13 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 12 Jul 2000 09:26:13 -0400 (EDT) Subject: [Python-Dev] second experiment In-Reply-To: <20000712131959.D823037186D@snelboot.oratrix.nl> Message-ID: > > 1. What should option (D) be? > > for (x, y) in [(10, 1), (20, 2), (30, 3)]: > print x+y > > And I think it should be the first question, being the currently > existing idiom. Very good point --- thanks. Greg From bwarsaw at beopen.com Wed Jul 12 15:35:09 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 09:35:09 -0400 (EDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) References: <20000712094447.2275337186D@snelboot.oratrix.nl> Message-ID: <14700.29709.259658.864250@anthem.concentric.net> >>>>> "JJ" == Jack Jansen writes: JJ> parallel()/zip() have an other advantage: it would be easy to JJ> extend to let the loop continue until the longest of the JJ> items, with a keyword argument: parallel((1, 2), (3, 4, 5), JJ> missing=None) # or extend, or some other name would return JJ> ((1, 3), (2, 4), (None, 5)) Yes, yes, yes! JJ> By the way: -1 on the name zip() and -0 on the name JJ> parallel(), but +1 on the concept. Is weave() perhaps a better name? -Barry From jack at oratrix.nl Wed Jul 12 15:57:35 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 15:57:35 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message by bwarsaw@beopen.com (Barry A. Warsaw) , Wed, 12 Jul 2000 09:35:09 -0400 (EDT) , <14700.29709.259658.864250@anthem.concentric.net> Message-ID: <20000712135736.2DA9737186D@snelboot.oratrix.nl> > JJ> By the way: -1 on the name zip() and -0 on the name > JJ> parallel(), but +1 on the concept. > > Is weave() perhaps a better name? My mental model tends to be transpose(), but that will definitely throw off mathematicians. Maybe we need an anti?!ng to come up with a good name:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From skip at mojam.com Wed Jul 12 05:59:28 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 11 Jul 2000 22:59:28 -0500 (CDT) Subject: [Python-Dev] Really dumb test observation Message-ID: <14699.60704.857942.610871@beluga.mojam.com> I was working on Python module coverage test generation tonight (sample results in the morning!). I noticed that coverage of the random module wasn't very good (30%-40% lines executed). There was no regression test case for that module, but I saw there was a random.test() function, so I created the following simple regression test: import random random.test() Statement coverage jumped immediately to nearly 90%. Seems to me that if a module defines a test() function and we have no regression test file for the module, that the above trick may increase code coverage significantly. (Actually, perhaps in these cases the test() function and related bits should be copied to the relevant regression test file to avoid invisible coupling between the module and its regression test output.) Skip From thomas at xs4all.net Wed Jul 12 16:13:28 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 16:13:28 +0200 Subject: [Python-Dev] listcomp / par-for (summary) Message-ID: <20000712161328.I7340@xs4all.nl> I'm gonna try and summarize all the opinions and suggestions in the listcomprehensions thread-from-hell (mutt's thread-sorted view was going bananas ;) but I'm certain I missed some suggestions and opinions, so I apologize in advance ;) Basically, what's been said is that list comprehensions as they are, are too confusing. I haven't hear that many people say that, but not many people objected to those that did say it, and plenty of alternative syntaxes were proposed. The same goes for parallel-for. It isn't terribly obvious whether the proposed syntax implements a cartesian product (as a nested for loop does) or a cross-section. There seem to be less divergent thoughts about this, though. A builtin (zip() or such) is preferred by a number of people, but not that many alternative syntaxes came along. As said, the currently implemented list-comprehension syntax was too unclear, especially when nesting the 'for's and 'if's too deeply. One of the proposals was to enforce the use of ()'s and add commas to make the 'for's and 'if's more readable: [(x,y) for x in a, y in b, if y > 3] That is not going to work. Enforcing the parentheses is possible, but only if you *always* enforce them, even if they don't create a tuple: [([x,y]) for x in a] (which would create a list of lists, not a list of tuples of lists.) And the problem with enforcing it is that we have to split open a *lot* of the Grammar, in order to disambiguate the syntax. Ain't a recursive descent parser great ? :) Secondly, the use of commas to seperate the for and if statements is not possible. The parser will see the commas as part of the iter-list of the previous for statement. The same goes for all other seperators that already have a meaning inside a 'testlist': commas, vertical bars, ampersands, circumflexes, etc. About the only character that already had a meaning inside Python that's usable at this point is the semi-colon, because it's only used as a statement seperator, not part of an expression list. Of course, using a new character that hasn't a meaning yet also works. And the same also goes for keywords in the same place. 'and' won't work, for instance, because it's already part of 'exprlist' and 'testlist', but 'while' does work, because it's currently only valid as a statement, not in an expression. So we end up with the following possibly syntaxes: [ <...> ] and [ ; ; ; <...> ] and perhaps the use of Python blocks and such: [ : : <....> ] Though I think that is a bit of a far cry from the original proposal. All the other proposals simply won't work without a massive re-ordering of the Grammar or rewriting the entire parser into something more versatile (and complicated) than a simple recursive descent parser. And the exact same story can be told for the parallel-for loop: for x in a and y in b: will not work because the 'exprlist' in 'for' will eat up 'a and y in b'. Likewise for for x in a | y in b: for x|y in a|b: for x,y in a|b: etc. The unnatural for {x,y} in a, b: would work, but it'd require special-casing the use of {}'s, and might suggest 'dict-unpacking' to people. for x;y in a;b: probably will work, too. Actually, yes, this will work, even though I haven't tested it... It also makes seeing howmany lists you are looping over pretty easy. Hmm, I might even like this more than the currently implemented syntax, even if it's slightly less readable. The range-literal thing ([:10:2] -> [0,2,4,6,8]) seems to be acceptable, I believe ? It might 'merely' be syntactic sugar for a builtin, but it's such pretty sugar ! :-) And it's not possible to shadow the builtin like with range. (Though I have one possible addition to the range syntax: range tuples, like so: (20:10:3) They could just generate a rangeobject, like xrange does... That could be a fair bit of memory savings ;) But I have to admit the syntax isn't as obvious as [19:15:-1]) If I were to tally votes, I'd say the general consensus (for as far as there is one ;-) is rougly like this: list comprehensions: -1/-0 parallel for: -0 range literal: +0 Correct me if I'm wrong ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Wed Jul 12 16:19:47 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 09:19:47 -0500 (CDT) Subject: [Python-Dev] Re: test_posixpath fails In-Reply-To: <14699.58277.811263.365468@bitdiddle.concentric.net> References: <14699.58277.811263.365468@bitdiddle.concentric.net> Message-ID: <14700.32387.330444.979191@beluga.mojam.com> Jeremy> If I run the new test on my Linux box, I get two errors. The Jeremy> second error looks innocuous, but the first one looks like a Jeremy> real bug. Jeremy, Mea culpa. I wrote the commonprefix test assuming the adoption of my new (corrected) semantics. Looks like you are using the stock version that examines prefixes character-by-character, which can return path prefixes that don't exist. Try applying this patch: https://sourceforge.net/patch/?func=detailpatch&patch_id=100788&group_id=5470 Skip Jeremy> Jeremy >> python Lib/test/test_posixpath.py Jeremy> error! Jeremy> evaluated: posixpath.commonprefix(["/home/swenson/spam", "/home/swen/spam"]) Jeremy> should be: /home Jeremy> returned: /home/swen Jeremy> error! Jeremy> evaluated: posixpath.commonprefix(["/home/swen/spam", "/home/swen/eggs"]) Jeremy> should be: /home/swen Jeremy> returned: /home/swen/ Jeremy> 2 errors. From fdrake at beopen.com Wed Jul 12 16:20:28 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 12 Jul 2000 10:20:28 -0400 (EDT) Subject: [Python-Dev] Re: CVS: python/dist/src/Include abstract.h,2.21,2.22 In-Reply-To: <200007121256.FAA00462@slayer.i.sourceforge.net> References: <200007121256.FAA00462@slayer.i.sourceforge.net> Message-ID: <14700.32428.442840.683994@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > change abstract size functions PySequence_Size &c. > add macros for backwards compatibility with C source ... > + #define PyObject_Length(O) PyObject_Size((O)) Jeremy, This should probably be: #define PyObject_Length PyObject_Size without the parameters. This form can be used in the all the places where it can now, including passing a function reference. Seems like a good idea to offer as little potential breakage as possible. Are you planning to update the API reference, or should I do that? I'll be glad to do it; I've never liked the difference in the naming either! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Wed Jul 12 16:24:31 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 09:24:31 -0500 (CDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <14699.59823.710880.896491@anthem.concentric.net> References: <396BA425.2EF3B11F@prescod.net> <14699.59823.710880.896491@anthem.concentric.net> Message-ID: <14700.32671.461502.666561@beluga.mojam.com> BAW> Alternatives (as Greg I think brought up): pairwise(), maybe BAW> zipper() for zip() since it's more evocative. "zip" already has a lot of compression connotations. How about "stitch", as in "stitch two lists together"? Skip From nhodgson at bigpond.net.au Wed Jul 12 16:30:08 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Thu, 13 Jul 2000 00:30:08 +1000 Subject: [Python-Dev] Proxy settings for urllib on Win32 Message-ID: <004501bfec0d$ae1bca10$8119fea9@neil> Is there any reason why urllib uses environment variables for proxy settings on Win32? Its quite unlikely they will be set up and there is a standard registry location for this information. I've added retrieval of registry settings to my copy of urllib and it seems to work OK athough I'm not running off CVS and I recall the winreg module has changed recently. Here is the code going just after the "if os.name == 'mac'" proxy handling. elif os.name == 'nt': def getproxies(): """Return a dictionary of scheme -> proxy server URL mappings. Win32 uses the registry to store proxies. """ proxies = {} try: import winreg internetSettings = winreg.OpenKey(winreg.HKEY_CURRENT_USER, "Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings"); proxyEnable = winreg.QueryValueEx(internetSettings, "ProxyEnable")[0] if proxyEnable: # Returned as Unicode but problems occur if not converted to ASCII proxyServer = str(winreg.QueryValueEx(internetSettings, "ProxyServer")[0]) if ";" in proxyServer: # Individual per-protocol settings for p in string.split(proxyServer,";"): protocol, address = string.split(p, "=") proxies[protocol] = '%s://%s' % (protocol, address) else: # Use one setting for all protocols proxies['http'] = 'http://%s' % proxyServer proxies['ftp'] = 'ftp://%s' % proxyServer internetSettings.Close() except: # proxies already set up to be empty so nothing to do pass return proxies Neil From esr at thyrsus.com Wed Jul 12 16:56:31 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Wed, 12 Jul 2000 10:56:31 -0400 Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14699.18134.550769.266956@beluga.mojam.com> References: <14699.17130.908682.514720@cj42289-a.reston1.va.home.com> <14699.18134.550769.266956@beluga.mojam.com> Message-ID: <20000712105631.A1472@thyrsus.com> Skip Montanaro : > Fred> At one point, we were discussing having specializations of > Fred> SyntaxError, and I posted a patch that defined IndentationError > Fred> and TabError. > > I think you should go for it. As long as they are subclasses of SyntaxError > no existing code should break. For whatever it's worth, I agree. -- Eric S. Raymond According to the National Crime Survey administered by the Bureau of the Census and the National Institute of Justice, it was found that only 12 percent of those who use a gun to resist assault are injured, as are 17 percent of those who use a gun to resist robbery. These percentages are 27 and 25 percent, respectively, if they passively comply with the felon's demands. Three times as many were injured if they used other means of resistance. -- G. Kleck, "Policy Lessons from Recent Gun Control Research," From skip at mojam.com Wed Jul 12 16:40:23 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 09:40:23 -0500 (CDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: References: Message-ID: <14700.33623.201717.133682@beluga.mojam.com> Michael> Think zip as in "zipper"; this more sense to me than naming a Michael> compression algorithm "zip"... Unfortunately, regardless of your background or mine, most of the unwashed masses who will be (and are being) attracted to Python have only seen "zip" in computer contexts as it relates to file compression. To add weight to the connection, Python now has a "zipfile" module... Skip From MarkH at ActiveState.com Wed Jul 12 16:42:43 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Wed, 12 Jul 2000 10:42:43 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <3969FD17.487DA96A@interet.com> Message-ID: Sorry for the delay in responding to this stuff - Im at the MS PDC, and demoing a new Python compiler that I'm suddenly allowed to talk about - but that isnt the point of this mail :-] > This is really bad. Normally under Windows, DLL names do not change > unless the API exported is changed in a major way. For example, > there have been several versions of mfc42.dll without changing the > name. Yes, and each of these versions has broken various programs. Of all people, Im surprised to see you falling for the MS hype, Jim. MS have openly admitted, on a number of occasions, that Windows has "DLL hell", and has made a huge effort to address this in the .NET framework. The Python community has itself been bitten by "bogus" MFC42.dll files that MS profess to be compatible. If MS can't get it right with their resources, I don't like our chances! > What this means is that if the new Python 2.0 (1.6?) simply names > its DLL python15.dll just as before, everything Just Works almost. > That is, it Just Works provided that foo.pyd only calls Python > C functions whose interface has not changed. IMO, this constrains us too much. We can't afford this - we simply dont have the resources. > You can support Python 1.5 and 1.6 by removing the python*.dll > from the Windows directories, and putting it in the directory > of python.exe so it goes with the proper executable. We have discussed this over and over and over, ad nauseum. If you believe the earlier discussions were bunk, please refute them. Otherwise, simply re-asserting something that we have previously proven to be incorrect doesnt help anyone. > > trying to solve here? So far, the only problem that came up was that > > on Windows, you get an obscure crash when trying to load an extension > > built for Python 1.5(.x). > > Yes, and this is a major problem, and is un-Windows-like. :-) "Major Crashes" are un-Windows like? What is happening to this group - It amusing that this statement could be made without the Linux geeks making smart-arsed comments :-) Looks like Billy Boy really _is_ taking over the world :-) > No, just keep the old name "python15.dll". Old foo.pyd will > still work if they use only Python C functions with the same > interface. And as long as we go to extraordinary efforts to maintain binary compatibility. We are under resourced as it is - I dont believe we can do this. > Individual *.pyd authors will have to advise users whether > they need to upgrade to new *.pyd versions or not. This is where we are now. I agree that we should not crash, but it seems to me you havent solved anything - individual .pyd authors needing to tell users about each individual .pyd isnt a solution. > > You can already get the version string by > > looking at Py_GetVersion() -- this also answers the question of how a > > version is represented. > > True. And on Windows, there is a standard Version resource > string which gives the DLL version, and can be read without > loading the DLL. This string is referenced by the Wise (and > other) installers to decide whether a DLL is newer and should > be replaced. Im not sure how this helps us. Do you mean that "initfoo" should use the Windows resource/version APIs to determine if it can load? > > On Windows, link-time compatibility is broken whenever we change the > > second digit of the version number, e.g. 15, 16, 20. > > Yikes, lets not let that happen! Ideally, I agree. However, Im not sure how we can make this happen! Any ideas on how we can achieve this? And I mean in a practical sense, rather than with a hand-waving abstract theory - ie, specifically what developement practices should change, or be put in place, to ensure this? Mark. From bwarsaw at beopen.com Wed Jul 12 16:45:38 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 10:45:38 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> Message-ID: <14700.33938.765976.193911@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> I believe the correct approach would be to have ./configure GS> look for zlib. If present, then it should include the module GS> into the build. [ this auto-build style could apply to many GS> modules, actually ] It would have to check the libz version number. Older versions will core Python. -Barry From bwarsaw at beopen.com Wed Jul 12 16:46:19 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 10:46:19 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> <20000712075915.A17856@newcnri.cnri.reston.va.us> Message-ID: <14700.33979.832366.278311@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> I'm working on a patch for using a setup.py file and the AK> Distutils to build the standard library; Setup.in then AK> contains only those few modules needed to run the Distutils, AK> and you'd never need to modify it. Not done yet, though... +10 From MarkH at ActiveState.com Wed Jul 12 16:47:40 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Wed, 12 Jul 2000 10:47:40 -0400 Subject: [Python-Dev] PyXXX_Size vs. PyXXX_Length In-Reply-To: <14698.15423.878220.203259@bitdiddle.concentric.net> Message-ID: > Tuple, List, String, and Dict have a PyXXX_Size method. The abstract > object interface uses PySequence_Length. This is inconsistent and > hard to remember. Can we add PySequence_Size and mark Length as > deprecated? I definately prefer "length" - for example, with Unicode, PyUnicode_Size() implies the number of bytes (the size of the data structure) while PyUnicode_Length() implies the number of characters. Mark. From skip at mojam.com Wed Jul 12 16:50:54 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 09:50:54 -0500 (CDT) Subject: [Python-Dev] no test_posix, test_os or test_sys? Message-ID: <14700.34254.159786.213828@beluga.mojam.com> I decided I better examine the posix.isatty patch assigned to me before Guido kicks me out... I was a little annoyed it didn't include a new test case. I figured, "oh well, I'll just add one to test_posix.py". Oh Lord! No test_posix.py or test_os.py! (No test_sys.py either!) These are some of the most heavily used modules in Python. They deserve test cases... Unless someone has strenuous objections, I'm going to post something on c.l.py asking for volunteers to write test cases for each of these three. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From thomas at xs4all.net Wed Jul 12 16:58:52 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 16:58:52 +0200 Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: <14700.34254.159786.213828@beluga.mojam.com>; from skip@mojam.com on Wed, Jul 12, 2000 at 09:50:54AM -0500 References: <14700.34254.159786.213828@beluga.mojam.com> Message-ID: <20000712165852.J7340@xs4all.nl> On Wed, Jul 12, 2000 at 09:50:54AM -0500, Skip Montanaro wrote: > I decided I better examine the posix.isatty patch assigned to me before > Guido kicks me out... I was a little annoyed it didn't include a new test > case. I wasn't entirely certain how to test this. Can we rely on stdin/stdout being a terminal, inside tests ? I think not. It can be tested by test_pty and/or test_openpty, but then failure can mean two things: pty.openpty() failed, or isatty() failed. Or we can open an fd and make sure os.isatty() returns 0 for that. None of it seemed very sensible. (I did write the test_pty/test_openpty modules with this in mind, though: ## # Please uncomment these if os.isatty() is added. ## if not os.isatty(master_fd): ## raise TestFailed, "master_fd is not a tty" ## if not os.isatty(slave_fd): ## raise TestFailed, "slave_fd is not a tty" So if you accept the patch, please uncomment those lines ;) However, isatty() is a *very* simple wrapper around a very basic C function, so I didn't think it warranted a test case. (Like you pointed out, none of the other functions in posixmodule have test cases.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Wed Jul 12 17:01:46 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 10:01:46 -0500 (CDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14700.25459.555611.544163@bitdiddle.concentric.net> References: <14700.25459.555611.544163@bitdiddle.concentric.net> Message-ID: <14700.34906.286143.800770@beluga.mojam.com> SyntaxError: dedent does not match any outer indentation level Isn't something like "line indented incorrectly" sufficient to alert the programmer to an indentation on that line? Perhaps Python doesn't need to tell which direction to push the line. Skip From akuchlin at mems-exchange.org Wed Jul 12 17:06:37 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 12 Jul 2000 11:06:37 -0400 Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: <14700.34254.159786.213828@beluga.mojam.com>; from skip@mojam.com on Wed, Jul 12, 2000 at 09:50:54AM -0500 References: <14700.34254.159786.213828@beluga.mojam.com> Message-ID: <20000712110637.E1363@kronos.cnri.reston.va.us> On Wed, Jul 12, 2000 at 09:50:54AM -0500, Skip Montanaro wrote: >No test_posix.py or test_os.py! (No test_sys.py either!) These are some of >the most heavily used modules in Python. They deserve test cases... Note that you might want to break it up into subtests; for example, test_fork.py tests os.fork() already. So you could have one test case for file-related operations, another for uid-related, etc. A full test_os.py would be huge and ungainly. (I've speculated about adding a unit testing framework, similar to the one we use internally at the MEMS Exchange; the discipline of using it makes writing a test more time-consuming, but the tests also wind up being more comprehensive.) --amk From skip at mojam.com Wed Jul 12 17:11:44 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 10:11:44 -0500 (CDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C4F7D.288B561D@schneider-kamp.de> References: <396C4F7D.288B561D@schneider-kamp.de> Message-ID: <14700.35504.551569.956243@beluga.mojam.com> Peter> off-topic: Peter> I am still thinking about higher order functions in Python: Peter> e.g.: map(+ 1, [1, 2, 3]) instead of map(lambda x: x + 1, [1, 2, 3]) Peter> don't have a clue how to do that yet. That would be [x + 1 for x in [1,2,3]] of course... ;-) Skip From jack at oratrix.nl Wed Jul 12 17:16:19 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 17:16:19 +0200 Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: Message by Andrew Kuchling , Wed, 12 Jul 2000 11:06:37 -0400 , <20000712110637.E1363@kronos.cnri.reston.va.us> Message-ID: <20000712151620.1C31437186D@snelboot.oratrix.nl> > Note that you might want to break it up into subtests; for example, > test_fork.py tests os.fork() already. So you could have one test case > for file-related operations, another for uid-related, etc. A full > test_os.py would be huge and ungainly. +1. If the tests would also do the import in the right way, i.e. test_os_symlink would do a "from os import symlink", then on each platform it would only try the tests that are relevant to the platform, while the others would be skipped with an "optional feature couldn't be imported", in stead of crashing the whole test_os. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido at beopen.com Wed Jul 12 18:26:58 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 11:26:58 -0500 Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: Your message of "Wed, 12 Jul 2000 09:50:54 EST." <14700.34254.159786.213828@beluga.mojam.com> References: <14700.34254.159786.213828@beluga.mojam.com> Message-ID: <200007121626.LAA14732@cj20424-a.reston1.va.home.com> > Unless someone has strenuous objections, I'm going to post something on > c.l.py asking for volunteers to write test cases for each of these three. +10 --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Wed Jul 12 17:30:48 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 10:30:48 -0500 (CDT) Subject: [Python-Dev] Basic Python statement coverage results Message-ID: <14700.36648.674422.519358@beluga.mojam.com> I added Python statement coverage using my trace module to the stuff that is run nightly on my web site. When you get a chance, please visit http://www.musi-cal.com/~skip/python/Python/dist/src/ From esr at thyrsus.com Wed Jul 12 17:49:45 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Wed, 12 Jul 2000 11:49:45 -0400 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> References: <200007112003.PAA08204@cj20424-a.reston1.va.home.com> Message-ID: <20000712114945.F1607@thyrsus.com> Guido van Rossum : > What do you think the following code would print? > > for i in (10, 20, 30); j in (1, 2, 3): > print i+j I think thre confusion over ambiguous syntax is telling us that what we need here is to bite the bullet and add a keyword to the language so there is a clear distinction from existing concepts. I make so bold as to sugest this: for i in (10, 20, 30) with j in (1, 2, 3): print i+j However, I have to say that having meditated on this design problem at some length I now think proliferating new control structures is the wrong answer. Instead, I propose that we look for ways to make smarter data structures drive control. Concretely. this approach would make `with' a data contructor, throw out the parallel-loop syntax, and write the following: >>> [2] with [3] [(2, 3)] >>> (10, 20, 30) with (1, 2, 3) ((10, 1), (20, 2), (30, 3)) >>> for (i, j) in (10, 20, 30) with (1, 2, 3): print i + j This doesn't instantly give us a way to interpret for (i, j) in (10, 20, 30, 40) with (1, 2): print i + j But suppose that the semantics of `with' were that it joins parallel arguments as far as it can and stops whenever it runs out of elements in any one argument. Then, >>> (10, 20, 30, 40) with (1, 2) ((10, 1), (20,2)) Problem solved. Now let's make life easier. The `with' keyword can actually become an n-adic intrinsic function, analogous to `range'. Now we write >>> for (i, j) in with((10, 20, 30, 40), (1, 2)): print i + j Presto! All need for parallel loops has now disappeared. If anyone doubts this, I will cheerfully produce source code for with(). -- Eric S. Raymond It is proper to take alarm at the first experiment on our liberties. We hold this prudent jealousy to be the first duty of citizens and one of the noblest characteristics of the late Revolution. The freemen of America did not wait till usurped power had strengthened itself by exercise and entangled the question in precedents. They saw all the consequences in the principle, and they avoided the consequences by denying the principle. We revere this lesson too much ... to forget it -- James Madison. From esr at thyrsus.com Wed Jul 12 17:55:07 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Wed, 12 Jul 2000 11:55:07 -0400 Subject: [Python-Dev] list comprehensions again... In-Reply-To: <14699.31592.410628.754071@anthem.concentric.net> References: <200007111752.MAA06413@cj20424-a.reston1.va.home.com> <14699.31592.410628.754071@anthem.concentric.net> Message-ID: <20000712115507.G1607@thyrsus.com> Barry A. Warsaw : > Range literals I can see as being worth it. I wonder if parallel for > loops can't be handled more gracefully with a function -- isn't it > just a nice wrapper around a specific call to map() anyway? > > List comprehensions do seem to need more syntactic support, but the > ambiguity of the semantics bothers me. I agree with both evaluations, and have just posted a proposal to replace parallel for-loops with a new data constructor. (I still like list comprehensions. But they need to be cleaner.) -- Eric S. Raymond Question with boldness even the existence of a God; because, if there be one, he must more approve the homage of reason, than that of blindfolded fear.... Do not be frightened from this inquiry from any fear of its consequences. If it ends in the belief that there is no God, you will find incitements to virtue in the comfort and pleasantness you feel in its exercise... -- Thomas Jefferson, in a 1787 letter to his nephew From effbot at telia.com Wed Jul 12 17:43:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 17:43:45 +0200 Subject: [Python-Dev] more SyntaxError subclasses! Message-ID: <009a01bfec17$f7fe3be0$f2a6b5d4@hagrid> here are a bunch of other syntax error subclasses that might be useful: class StatementError(SyntaxError): "you cannot use this statement here" class AssignmentError(StatementError): "you cannot assign to this target" class CompilerError(SyntaxError): "sorry, this is a compiler restriction, not really a language restriction" class LimitError(CompilerError): "exceeded compiler limit" class TokenError(SyntaxError): "you cannot use this token here" class FunctionError(SyntaxError): "there's something wrong with this function/method declaration" class ArgumentError(FunctionError): "the argument declaration isn't correct" here's how they're used in the current interpreter (before the TabError/IndentationError patches): ArgumentError: "duplicate keyword argument" ArgumentError: "keyword can't be an expression" ArgumentError: "non-default argument follows default argument" ArgumentError: "non-keyword arg after keyword arg" AssignmentError: "can't assign to ()" AssignmentError: "can't assign to []" AssignmentError: "can't assign to function call" AssignmentError: "can't assign to lambda" AssignmentError: "can't assign to literal" AssignmentError: "can't assign to operator" LimitError: "expression too long" LimitError: "more than 255 arguments" StatementError: "'break' outside loop" StatementError: "'continue' not properly in loop" StatementError: "'return' outside function" StatementError: "default 'except:' must be last" StatementError: "name is local and global" SyntaxError: "invalid syntax" SyntaxError: "unexpected EOF while parsing" SyntaxError: "unknown parsing error" TabError: "inconsistent use of tabs and spaces in indentation" TokenError: "invalid token" comments? (I'm extra interested in arguments from people who think TabError and IndentationError is a good idea, but that this one sucks. I'm not sure I want to hear from people who thinks that this one is a great idea ;-) ... on a more serious note, I think it would be great to add a distinct attribute to the SyntaxError instance (an error number, most likely). this could be used by an IDE to provide concise info without having to parse the error message. I'll post a more complete proposal later... cheers /F From effbot at telia.com Wed Jul 12 17:32:51 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 17:32:51 +0200 Subject: [Python-Dev] Proxy settings for urllib on Win32 References: <004501bfec0d$ae1bca10$8119fea9@neil> Message-ID: <009901bfec17$f7bb1860$f2a6b5d4@hagrid> neil wrote: > Is there any reason why urllib uses environment variables for proxy > settings on Win32? Its quite unlikely they will be set up and there is a > standard registry location for this information. probably only laziness -- winreg is a recent addition, after all. > I've added retrieval of registry settings to my copy of urllib and it > seems to work OK athough I'm not running off CVS and I recall the winreg > module has changed recently. Here is the code going just after the "if > os.name == 'mac'" proxy handling. +1 from here. cheers /F From paul at prescod.net Wed Jul 12 17:39:51 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 10:39:51 -0500 Subject: [Python-Dev] listcomp / par-for (summary) References: <20000712161328.I7340@xs4all.nl> Message-ID: <396C9147.F4A4BE4F@prescod.net> Thanks for the summary. Here's my 1p. Thomas Wouters wrote: > >... > > Basically, what's been said is that list comprehensions as they are, are too > confusing. I haven't hear that many people say that, but not many people > objected to those that did say it, and plenty of alternative syntaxes were > proposed. I think that a lot of the confusion came with the conflation with parallel-for. Any concept is hard to follow when the syntax is changing hourly. -- Re: alternatives for listcomp: Another option is: [ : : <....>: ] -- RE: parallel for: Are there any arguments AGAINST using something like zip for a parallel for-loop a function? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Wed Jul 12 17:40:11 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 10:40:11 -0500 Subject: [Python-Dev] listcomp / par-for (summary) References: <20000712161328.I7340@xs4all.nl> Message-ID: <396C915B.8B1A3A1B@prescod.net> Here's my other 1p. > The range-literal thing ([:10:2] -> [0,2,4,6,8]) seems to be acceptable, I > believe ? It might 'merely' be syntactic sugar for a builtin, but it's > such pretty sugar ! :-) Let me play devil's advocate to make sure this is fleshed out enough. How's this for obfuscation: [0:10][0:10][0:10] --- And arguing from analogy, shouldn't range(0:bignum)[0:10:2] be [0:10:2] > And it's not possible to shadow the builtin like with range. You probably shouldn't be able to shadow most builtins period. > (Though I have one possible addition to the range syntax: range tuples, like > so: > > (20:10:3) I presume you meant (10:20:3). Right? > They could just generate a rangeobject, like xrange does... That could be a > fair bit of memory savings ;) But I have to admit the syntax isn't as > obvious as [19:15:-1]) I don't follow you here. Anyhow, I like the idea that there should be a syntax that does the rangeobject thing and it makes sense that it needs to be immutable. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Wed Jul 12 17:31:10 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 12 Jul 2000 17:31:10 +0200 Subject: [Python-Dev] simple syntax error bombs interpreter Message-ID: <009101bfec16$35495fe0$f2a6b5d4@hagrid> using my latest Python 2.0 build, the interpreter bombs if I type the following two commands: >>> def a(b): ... global b ... (1.5.2 says "name is local and global"). From paul at prescod.net Wed Jul 12 17:44:45 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 10:44:45 -0500 Subject: [Python-Dev] Unit testing... References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> Message-ID: <396C926D.F223E686@prescod.net> Andrew Kuchling wrote: > > ... > > (I've speculated about adding a unit testing framework, similar to the > one we use internally at the MEMS Exchange; the discipline of using it > makes writing a test more time-consuming, but the tests also wind up > being more comprehensive.) I think PyUnit/JUnit and friends are in vogue these days. There is some virtue in having a framework that could be used also by extension module writers so that there is some consistency about finding and invoking tests. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Wed Jul 12 18:01:37 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 11:01:37 -0500 Subject: [Python-Dev] zip() and list-comprehension with commas References: <396BA425.2EF3B11F@prescod.net> <14699.59823.710880.896491@anthem.concentric.net> <14700.32671.461502.666561@beluga.mojam.com> Message-ID: <396C9661.3EF03755@prescod.net> Skip Montanaro wrote: > > BAW> Alternatives (as Greg I think brought up): pairwise(), maybe > BAW> zipper() for zip() since it's more evocative. > > "zip" already has a lot of compression connotations. How about "stitch", as > in "stitch two lists together"? "Stitch" and "with" are okay, but I'd like to hear someone debunk the names used today by MAL. They seemed very logical to me. I'd just change the semantics to be lazy in a couple of cases. >>> tuple([1,2,3]) (1,2,3) >>> tuples([1,2,3],[4,5,6]) >>> list((1,2,3)) [1,2,3] >>> lists((1,2,3),(4,5,6)) >>> dict([(1,2),(3,4),(5,6)]) {1:2,3:4,5:6} -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 18:13:19 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 18:13:19 +0200 (CEST) Subject: [Python-Dev] Re: merging my*.h into pyport.h In-Reply-To: <396B4850.A3D1A1A2@stud.ntnu.no> from "Peter Schneider-Kamp" at Jul 11, 2000 04:16:16 PM Message-ID: <200007121613.SAA29910@python.inrialpes.fr> Peter Schneider-Kamp wrote: > > What do you think would be appropriate? I have been toying around > with the my*.h headers a bit and loaded up a "proof of concept" patch > that makes all my*.h obsolete. Where's the patch? ... Ah, found it - assigned to / postponed by nowonder. This include business is tricky. I for one am against seeing mymalloc.h moved to pyport.h. It doesn't belong there and deserves a file on its own. If my*.[ch] files really disturb you, you can make them obsolete by renaming them to py*.[ch] :-). ~/python/dev> ls Include/my* Include/mymalloc.h Include/myproto.h Include/mytime.h Include/mymath.h Include/myselect.h - feel free to move to pyport.h both myproto.h and mymath.h (as you did) - mymalloc.h shouldn't be touched. You may eventyally want to rename it to pymalloc.h - not sure what to do with mytime.h and myselect.h - not sure whether it's worth renaming my*.c to py*.c > > P.S.: What's the status of sre? I just ask because test_re > keeps nagging all the time. :-] The problem is that /F has no idea where this bug comes from, and the suspicions he had about memory glitches in the SRE code haven't been confirmed by Barry's Purify analyses so far. I did some testing too, but found only unrelated buglets. I second Barry's opinion that the memory picture of the CVS snapshot is good enough. So this seems to be a bug related with the logic of the code, in an area where Barry and I have already publicly qualified ourselves as clueless. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From skip at mojam.com Wed Jul 12 18:25:57 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 11:25:57 -0500 (CDT) Subject: [Python-Dev] no test_posix, test_os or test_sys? In-Reply-To: <20000712165852.J7340@xs4all.nl> References: <14700.34254.159786.213828@beluga.mojam.com> <20000712165852.J7340@xs4all.nl> Message-ID: <14700.39957.204774.928368@beluga.mojam.com> Thomas> (I did write the test_pty/test_openpty modules with this in Thomas> mind, though: Thomas> ## # Please uncomment these if os.isatty() is added. Thomas> ## if not os.isatty(master_fd): Thomas> ## raise TestFailed, "master_fd is not a tty" Thomas> ## if not os.isatty(slave_fd): Thomas> ## raise TestFailed, "slave_fd is not a tty" Thomas> So if you accept the patch, please uncomment those lines ;) Will do. Thomas> However, isatty() is a *very* simple wrapper around a very basic Thomas> C function, so I didn't think it warranted a test case. (Like Thomas> you pointed out, none of the other functions in posixmodule have Thomas> test cases.) My message wasn't motivated so much with the missing test case for isatty, but that there are no regression tests at all for os, posix or sys. Skip From thomas at xs4all.net Wed Jul 12 18:26:56 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 18:26:56 +0200 Subject: [Python-Dev] listcomp / par-for (summary) In-Reply-To: <396C915B.8B1A3A1B@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 10:40:11AM -0500 References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> Message-ID: <20000712182656.K7340@xs4all.nl> On Wed, Jul 12, 2000 at 10:40:11AM -0500, Paul Prescod wrote: > > The range-literal thing ([:10:2] -> [0,2,4,6,8]) seems to be acceptable, > > I believe ? It might 'merely' be syntactic sugar for a builtin, but it's > > such pretty sugar ! :-) > Let me play devil's advocate to make sure this is fleshed out enough. > > How's this for obfuscation: > [0:10][0:10][0:10] Sure, but it's not more obfuscated than a long line of map(lambda ... reduce(filter(map(lambda ... ))) -- it's definately easier to parse for humans ! The parser won't have any trouble with it, if that's what you mean: >>> [:200:2][0:20] [0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38] >>> [:200:2][0:20][10:20] [20, 22, 24, 26, 28, 30, 32, 34, 36, 38] > --- > And arguing from analogy, shouldn't > > range(0:bignum)[0:10:2] be [0:10:2] Yes, it should, but there is no way to enforce it, currently, because range can be shadowed by a local or global variable. And it doesn't have to be unintended, either. With range literals, that's no longer possible. > > And it's not possible to shadow the builtin like with range. > You probably shouldn't be able to shadow most builtins period. Why not ? It would introduce a number of problems: adding new builtin functions would be as cagey as adding new reserved words (in effect, all builtins *become* reserved words.) So it would break a ton of code. It would make extending the builtins practically impossible. It would be very confusing for current Python programmers. Etcetera. > > (Though I have one possible addition to the range syntax: range tuples, > > like so: > > > > (20:10:3) > I presume you meant (10:20:3). Right? Yes, sorry. > > They could just generate a rangeobject, like xrange does... That could be a > > fair bit of memory savings ;) But I have to admit the syntax isn't as > > obvious as [19:15:-1]) > I don't follow you here. Anyhow, I like the idea that there should be a > syntax that does the rangeobject thing and it makes sense that it needs > to be immutable. Well, when I look at '(10:20:3)', it doesn't look like a range, to me. Mostly because it has no precedent in Python: ()'s are used for grouping, and for function calls. They do not create tuples! :) In fact, the '(10:20:3)' syntax reminds me more of dates or machine-addresses than it does of ranges. For that reason I think it's better to live with xrange() ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From DavidA at ActiveState.com Wed Jul 12 18:32:43 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 12 Jul 2000 09:32:43 -0700 (Pacific Daylight Time) Subject: [Python-Dev] more SyntaxError subclasses! In-Reply-To: <009a01bfec17$f7fe3be0$f2a6b5d4@hagrid> Message-ID: On Wed, 12 Jul 2000, Fredrik Lundh wrote: > here are a bunch of other syntax error subclasses that > might be useful: +1. > (I'm extra interested in arguments from people who think TabError > and IndentationError is a good idea, but that this one sucks. I'm > not sure I want to hear from people who thinks that this one is a > great idea ;-) Sorry. =) > on a more serious note, I think it would be great to add a distinct > attribute to the SyntaxError instance (an error number, most likely). > this could be used by an IDE to provide concise info without having > to parse the error message. Indeed. From DavidA at ActiveState.com Wed Jul 12 18:34:36 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 12 Jul 2000 09:34:36 -0700 (Pacific Daylight Time) Subject: [Python-Dev] ! Message-ID: Keeping up w/ python dev, patches and checkins is getting to be a huge amount of work! Should we _thank_ lawyers for turning what was a small intense rush in getting things done before a release into a long intense rush? Perish the thought... +1 on the new python-dev community! --david From mwh21 at cam.ac.uk Wed Jul 12 18:48:16 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 12 Jul 2000 17:48:16 +0100 Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: "Fredrik Lundh"'s message of "Wed, 12 Jul 2000 17:31:10 +0200" References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> Message-ID: "Fredrik Lundh" writes: > using my latest Python 2.0 build, the interpreter > bombs if I type the following two commands: > > >>> def a(b): > ... global b > ... Hmm. Mine doesn't. What platform, stack, etc? > (1.5.2 says "name is local and global"). That's what mine says. "ConflictingScopeError" anyone? It's not a syntax error in my book... Cheers, M. From thomas at xs4all.net Wed Jul 12 18:59:20 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 18:59:20 +0200 Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: ; from mwh21@cam.ac.uk on Wed, Jul 12, 2000 at 05:48:16PM +0100 References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> Message-ID: <20000712185920.M7340@xs4all.nl> On Wed, Jul 12, 2000 at 05:48:16PM +0100, Michael Hudson wrote: > "Fredrik Lundh" writes: > > using my latest Python 2.0 build, the interpreter > > bombs if I type the following two commands: > > > > >>> def a(b): > > ... global b > > ... > Hmm. Mine doesn't. What platform, stack, etc? Mine does crash. The crash seems to be caused by a refcounting bug: the error gets detected, com_error() gets called, creates the appropriate error object, control flows back the way it was supposed to, but between com_error and PyErr_PrintEx() the error gets eradicated, resulting in a segmentation fault. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Wed Jul 12 18:57:57 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 11:57:57 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: Message-ID: <396CA395.D43D9570@prescod.net> Mark Hammond wrote: > > ... > > > On Windows, link-time compatibility is broken whenever we change the > > > second digit of the version number, e.g. 15, 16, 20. > > > > Yikes, lets not let that happen! > > Ideally, I agree. However, Im not sure how we can make this happen! Any > ideas on how we can achieve this? And I mean in a practical sense, rather > than with a hand-waving abstract theory - ie, specifically what > developement practices should change, or be put in place, to ensure this? Someone who is very interested in this backwards compatibility issue could make a stub Python15.dll that exposes the old API with the exact same (old) semantics. If it turns out to be easy, great. If it turns out to be difficult then we know that the APIs changed too much for it to be practical. If programs start crashing, we blame the person who promised backwads compatibility. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From mwh21 at cam.ac.uk Wed Jul 12 19:01:47 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 12 Jul 2000 18:01:47 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: "Mark Hammond"'s message of "Wed, 12 Jul 2000 10:42:43 -0400" References: Message-ID: "Mark Hammond" writes: > Sorry for the delay in responding to this stuff - Im at the MS PDC, and > demoing a new Python compiler that I'm suddenly allowed to talk about - but > that isnt the point of this mail :-] ? I'm curious now! [snip] > > > trying to solve here? So far, the only problem that came up was that > > > on Windows, you get an obscure crash when trying to load an extension > > > built for Python 1.5(.x). > > > > Yes, and this is a major problem, and is un-Windows-like. > > :-) "Major Crashes" are un-Windows like? What is happening to this > group - It amusing that this statement could be made without the Linux > geeks making smart-arsed comments :-) Looks like Billy Boy really _is_ > taking over the world :-) I was tempted, it has to be said. I did point a friend at it and giggle. nothing-useful-to-say-ly y'rs M. From thomas at xs4all.net Wed Jul 12 19:04:44 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 19:04:44 +0200 Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: <20000712185920.M7340@xs4all.nl>; from thomas@xs4all.net on Wed, Jul 12, 2000 at 06:59:20PM +0200 References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> <20000712185920.M7340@xs4all.nl> Message-ID: <20000712190444.N7340@xs4all.nl> On Wed, Jul 12, 2000 at 06:59:20PM +0200, Thomas Wouters wrote: > On Wed, Jul 12, 2000 at 05:48:16PM +0100, Michael Hudson wrote: > > "Fredrik Lundh" writes: > > Hmm. Mine doesn't. What platform, stack, etc? > > Mine does crash. Eh, Linux (RedHat 6.1), both 2.0b1-CVS-tree (recent) and python 1.6a2 (couple of weeks old) that is. Traceback of the exception is: #0 PyErr_NormalizeException (exc=0xbffff718, val=0xbffff71c, tb=0xbffff720) at errors.c:170 #1 0x8065501 in PyErr_PrintEx (set_sys_last_vars=1) at pythonrun.c:686 #2 0x80654d6 in PyErr_Print () at pythonrun.c:676 #3 0x80652fa in PyRun_SimpleString (command=0x821fc58 "def a(b): global b\n") at pythonrun.c:601 #4 0x8052a01 in Py_Main (argc=3, argv=0xbffff7d4) at main.c:256 #5 0x8052606 in main (argc=3, argv=0xbffff7d4) at python.c:10 though I doubt it's really helpful, as the actual bug is elsewhere. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mwh21 at cam.ac.uk Wed Jul 12 19:21:14 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 12 Jul 2000 18:21:14 +0100 Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: Thomas Wouters's message of "Wed, 12 Jul 2000 19:04:44 +0200" References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> <20000712185920.M7340@xs4all.nl> <20000712190444.N7340@xs4all.nl> Message-ID: Thomas Wouters writes: > On Wed, Jul 12, 2000 at 06:59:20PM +0200, Thomas Wouters wrote: > > On Wed, Jul 12, 2000 at 05:48:16PM +0100, Michael Hudson wrote: > > > "Fredrik Lundh" writes: > > > Hmm. Mine doesn't. What platform, stack, etc? > > > > Mine does crash. > > Eh, Linux (RedHat 6.1), both 2.0b1-CVS-tree (recent) and python 1.6a2 > (couple of weeks old) that is. Oh yeah; the same. Python built from a checkout about half an hour ago (so there's probably only been twenty or so checkins since then...). Next question: gc or not gc? My not crashing one had gc on, am now building one with gc off ... [just got to _sre.c] ... Nope. Steady as a rock. I'll leave this one to someone who has a problem! Cheers, M. From moshez at math.huji.ac.il Wed Jul 12 19:26:34 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 20:26:34 +0300 (IDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <20000712114945.F1607@thyrsus.com> Message-ID: On Wed, 12 Jul 2000 esr at thyrsus.com wrote: > Presto! All need for parallel loops has now disappeared. If anyone > doubts this, I will cheerfully produce source code for with(). Ummm.....you mean def with(*args): apply(map, (None,)+args) ;-) (Actually, this isn't right, since map() adds None's instead of stopping. But that should be a considered a design bug in map() anyway) What would people think about xmap(), which acts anologously to xrange(), IOW calculate lazilly instead of eagerly? Or even, calculate "on demand", without caching: class xmap: def __init__(self, func, *args): self.func = func self.args = args def __getitem__(self, i): arg = [None]*len(self.args) for j in range(len(self.args)): arg[j] = self.args[j][i] return apply(self.func, arg) Wouldn't this solve the parallel iteration problem? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul at prescod.net Wed Jul 12 19:25:36 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 12:25:36 -0500 Subject: [Python-Dev] Ranges References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> Message-ID: <396CAA0F.FE42AFD0@prescod.net> Thomas Wouters wrote: > > > How's this for obfuscation: > > > [0:10][0:10][0:10] > > Sure, but it's not more obfuscated than a long line of map(lambda ... > reduce(filter(map(lambda ... ))) I'm just commenting on the overloaded syntax of list construction and truncation. No big deal. > > And arguing from analogy, shouldn't > > > > range(0:bignum)[0:10:2] be [0:10:2] > > Yes, it should, but there is no way to enforce it, currently, because range > can be shadowed by a local or global variable. And it doesn't have to be > unintended, either. With range literals, that's no longer possible. That's not what I mean. Ignore the range. My point is, if list construction and truncation are going to be parallel, they should be really parallel. [0,1,2,3,4,5,6,7,8,10][0:5:2]==[0:5:2] I don't understand "extended slicing" so I don't know why the former doesn't work today. > > You probably shouldn't be able to shadow most builtins period. > > Why not ? It would introduce a number of problems: adding new builtin > functions would be as cagey as adding new reserved words (in effect, all > builtins *become* reserved words.) I said "most", not "all". Over time they could migrate from being builtin to being non-overridable. No one should define a function (not method, but function) called "map" or "dir". In practice, I haven't seen such a thing. If we make a "tuples" function then for a year or two it is fair game for overriding, the it becomes frozen. > For that reason I think it's better to live with xrange() ;) You could also use a lazy list comprehension (if we made list comprehensions lazy): [for x in [0:10:20]: x] That would make people think twice about using xrange (as it should...xrange isn't usually as efficient as they think!) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From moshez at math.huji.ac.il Wed Jul 12 19:32:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 12 Jul 2000 20:32:06 +0300 (IDT) Subject: [Python-Dev] listcomp / par-for (summary) In-Reply-To: <396C915B.8B1A3A1B@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > > And it's not possible to shadow the builtin like with range. > > You probably shouldn't be able to shadow most builtins period. I vehemently disagree. One reason we can add builtins to our hearts contents is that builtins do not interfere with current code base in a way that keywords do. OTOH, I see no reason to reward this behaviour: I'm currently considering an optimization to the interpreter which would mean that most code would run faster, but code that shadows builtins would run slower. (This ideas is bouncing around my head for a long while. I'll post here when I have some semblence of design ready) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From Vladimir.Marangozov at inrialpes.fr Wed Jul 12 21:29:43 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 12 Jul 2000 21:29:43 +0200 (CEST) Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: <009101bfec16$35495fe0$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 12, 2000 05:31:10 PM Message-ID: <200007121929.VAA09996@python.inrialpes.fr> Fredrik Lundh wrote: > > using my latest Python 2.0 build, the interpreter > bombs if I type the following two commands: > > >>> def a(b): > ... global b > ... > > (1.5.2 says "name is local and global"). > > > Yes. This is because PyErr_PrintEx() is invoked with a NULL exception. And the exception has been cleared cleared in get_inprogress_dict(). The appended patch should fix it. Let me know whether it works for you. Jeremy, what's the point of calling PyErr_Clear() in get_inprogress_dict()? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 ------------------------------[ cut here ]---------------------------- *** CVS/Objects/object.c Wed Jul 12 17:27:41 2000 --- dev/Objects/object.c Wed Jul 12 21:21:52 2000 *************** *** 356,362 **** } inprogress = PyDict_GetItem(tstate_dict, _PyCompareState_Key); if (inprogress == NULL) { - PyErr_Clear(); inprogress = PyDict_New(); if (inprogress == NULL) return NULL; --- 356,361 ---- From pingster at ilm.com Wed Jul 12 21:26:51 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 12:26:51 -0700 (PDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14700.25459.555611.544163@bitdiddle.concentric.net> Message-ID: On Wed, 12 Jul 2000, Jeremy Hylton wrote: > File "", line 4 > def foo(bar): > ^ > SyntaxError: dedent does not match any outer indentation level [...] > I don't know what a dedent is. Nor do I know what "outer indentation > levels" are or how they might apply to the line "def foo(bar):". Sorry, this is a transcript from my locally compiled Python. The actual patch says "unindent" rather than "dedent". (In this situation Python 1.5 prints a line to stderr saying "inconsistent dedent" but the SyntaxError only says "invalid syntax".) The intended meaning is "this line is less indented than the previous one, but i can't determine what block it goes with because there's no surrounding block indented at the same level". In short form, this became: "unindent does not match any outer indentation level". -- ?!ng From pingster at ilm.com Wed Jul 12 21:31:01 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 12:31:01 -0700 (PDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <396C2D00.BDA23AF2@lemburg.com> Message-ID: tuples(), lists(), dict(), and indices() look pretty generally useful to me. I agree that they look like good candidates for builtins. On Wed, 12 Jul 2000, M.-A. Lemburg wrote: > irange(object[,indices]) > Builds a tuple of tuples (index, object[index]). If a sequence > indices is given, the indices are read from it. If not, then > the index sequence defaults to trange(len(object)). This one in particular looks really fabulous. +1 to put this in builtins. In order of usefulness (just imho of course): irange +1 tuples +0.5 indices +0.5 dict +0 lists +0 -- ?!ng From thomas at xs4all.net Wed Jul 12 21:40:03 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 21:40:03 +0200 Subject: [Python-Dev] SyntaxError patches In-Reply-To: ; from pingster@ilm.com on Wed, Jul 12, 2000 at 12:26:51PM -0700 References: <14700.25459.555611.544163@bitdiddle.concentric.net> Message-ID: <20000712214003.P7340@xs4all.nl> On Wed, Jul 12, 2000 at 12:26:51PM -0700, Ka-Ping Yee wrote: > On Wed, 12 Jul 2000, Jeremy Hylton wrote: > > File "", line 4 > > def foo(bar): > > SyntaxError: dedent does not match any outer indentation level > [...] > > I don't know what a dedent is. Nor do I know what "outer indentation > > levels" are or how they might apply to the line "def foo(bar):". > The intended meaning is "this line is less indented than the previous > one, but i can't determine what block it goes with because there's > no surrounding block indented at the same level". In short form, this > became: "unindent does not match any outer indentation level". If the objective is to make error messages more accessible understandable to newbies, how about: Can't figure out where this statement belongs or Can't figure out what block this statement belongs to or Can't figure out where you wanted to place this line or There seems to be something wrong with the indentation of this line etc. Or they could be more Monty Python-esque. Anyone use the unix util 'screen', and its 'nethack' mode ? Excellent tool, both ways :-) Since these are syntax errors, not runtime errors, I'd say it's safe to use a more accusing stance to the viewer (that is, they're very likely to be the cause !) and I don't really see why all error messages should be mathematically correct, and thus phrased in some kind of lawyerese ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From pingster at ilm.com Wed Jul 12 21:48:54 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 12:48:54 -0700 (PDT) Subject: [Python-Dev] Ranges In-Reply-To: <396CAA0F.FE42AFD0@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > That's not what I mean. Ignore the range. My point is, if list > construction and truncation are going to be parallel, they should be > really parallel. > > [0,1,2,3,4,5,6,7,8,10][0:5:2]==[0:5:2] Did you think they were different? I thought they *were* parallel. I would expect: >>> range(0, 5, 2) [0, 2, 4] >>> [0:5:2] [0, 2, 4] >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] [0, 2, 4] >>> range(1000)[0:5:2] [0, 2, 4] Right? Am i misunderstanding how [x:y:z] should work? -- ?!ng From paul at prescod.net Wed Jul 12 22:03:29 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 15:03:29 -0500 Subject: [Python-Dev] Ranges References: Message-ID: <396CCF11.B5593E2C@prescod.net> Ka-Ping Yee wrote: > > >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] > [0, 2, 4] Well, today this is syntactically correct but it doesn't work as you (or I) predict. I don't know if that's because nobody has implemented it yet or if extended slices mean something other than what I think you and I think they should mean: Python 2.0b1 (#12, Jul 1 2000, 13:14:33) Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] Traceback (most recent call last): File "", line 1, in ? TypeError: sequence index must be integer The documentation on extended slicing is very thin, but if it doesn't do this, I'm not sure what it does! -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From pingster at ilm.com Wed Jul 12 22:22:07 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 13:22:07 -0700 (PDT) Subject: [Python-Dev] Ranges In-Reply-To: <396CCF11.B5593E2C@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > Python 2.0b1 (#12, Jul 1 2000, 13:14:33) > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] > Traceback (most recent call last): > File "", line 1, in ? > TypeError: sequence index must be integer Yeah. At the moment, [:] calls __getslice__ but [::] calls __getitem__ (ick). The list object is getting a call to __getitem__(slice(0, 5, 2)) and __getitem__ wants an integer. I was assuming this would get cleaned up along with the introduction of [x:y:z]-style range-makers (i recall Guido posting a suggestion for how to do so a little while back). Ah, yes: http://www.python.org/pipermail/python-dev/2000-July/012681.html The issues were - handling [:] and [::] consistently - allowing non-integer indices - letting user-defined objects do their own handling of negative indices I believe the two possibilities were __getitem__ gets either an index or a special slice object __getslice__ is deprecated (when missing, __getitem__ gets the slice args) and __getitem__ always gets an index __getslice__ gets three arguments, all optional, defaulting to None The latter isn't backward-compatible, but it makes a heckuva lot more sense. -- ?!ng From barry at scottb.demon.co.uk Wed Jul 12 22:30:45 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Wed, 12 Jul 2000 21:30:45 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Message-ID: <000001bfec40$0eb3a6e0$060210ac@private> > This is where we are now. I agree that we should not crash, but it seems > to me you havent solved anything - individual .pyd authors needing to tell > users about each individual .pyd isnt a solution. At least if Python can detect that a .PYD is out of date you know to ask for a newer .PYD or build it yourself. A crash is bad PR for the .PYD and Python. > > > You can already get the version string by > > > looking at Py_GetVersion() -- this also answers the question of how a > > > version is represented. > > > > True. And on Windows, there is a standard Version resource > > string which gives the DLL version, and can be read without > > loading the DLL. This string is referenced by the Wise (and > > other) installers to decide whether a DLL is newer and should > > be replaced. > > Im not sure how this helps us. Do you mean that "initfoo" should use the > Windows resource/version APIs to determine if it can load? As I pointed out you cannot use Py calls from a .PYD to find out the version as the .PYD calls the function in the old PYTHON15.DLL not the new one. BArry From paul at prescod.net Wed Jul 12 19:44:29 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 12:44:29 -0500 Subject: [Python-Dev] re: list comprehension / pop quiz References: Message-ID: <396CAE7D.B85AA3FB@prescod.net> Moshe Zadka wrote: > > What would people think about xmap(), which acts anologously to xrange(), > IOW calculate lazilly instead of eagerly? Or even, calculate "on demand", > without caching: > .... > Wouldn't this solve the parallel iteration problem? I don't think that using a function called "xmap" to build tuples is very intuitive to start with. What's so wrong with a builtin called "tuples()"? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Wed Jul 12 20:10:56 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 13:10:56 -0500 Subject: [Python-Dev] Par-for/range References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> Message-ID: <396CB4B0.EE284A39@prescod.net> Thomas Wouters wrote: > > ... > > For that reason I think it's better to live with xrange() ;) Thinking some more... If we had first class range syntax then it would be relatively easy to recognize the pattern for i in [x:y:z]: .... Then we could generate a special FOR_INTS bytecode. I've heard that "C" has a pretty efficient implementation of that construct. That would wipe out 96.3% of the need for xrange or tuplerange or whatever you want to call it. We could probably deprecate both functions and let the rare person who really wants an xrange use a class or math.xrange() or mxtools.xrange() or a lazy list comprehension (if we invent those!). Plus, if your loops are so large that they need xrange, you would probably get an interesting speedup from using a real C for-loop instead of an object! I mean for small values xrange is slower than range and when you think about what range is doing under the covers. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gvwilson at nevex.com Wed Jul 12 22:47:44 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Wed, 12 Jul 2000 16:47:44 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <396CAE7D.B85AA3FB@prescod.net> Message-ID: > Paul Prescod wrote: > I don't think that using a function called "xmap" to build tuples is > very intuitive to start with. What's so wrong with a builtin called > "tuples()"? I'm nervous about the readability of "tuple/tuples" and "map/xmap", having sometimes misread "xrange" for "range". (We take marks off student assignments that contain functions whose names only differ by one letter, don't we?) Greg From mwh21 at cam.ac.uk Wed Jul 12 23:03:53 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 12 Jul 2000 22:03:53 +0100 Subject: [Python-Dev] Par-for/range In-Reply-To: Paul Prescod's message of "Wed, 12 Jul 2000 13:10:56 -0500" References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> <396CB4B0.EE284A39@prescod.net> Message-ID: Paul Prescod writes: > Thinking some more... > > If we had first class range syntax then it would be relatively easy to > recognize the pattern > > for i in [x:y:z]: > .... > > Then we could generate a special FOR_INTS bytecode. I've heard that "C" > has a pretty efficient implementation of that construct. Hmm, yes, but how on earth would you implement that in ceval.c? You'd need another eval loop inside the code for FOR_INTS! (unless I'm being dense, of course). > That would wipe out 96.3% of the need for xrange or tuplerange or > whatever you want to call it. We could probably deprecate both functions > and let the rare person who really wants an xrange use a class or > math.xrange() or mxtools.xrange() or a lazy list comprehension (if we > invent those!). > > Plus, if your loops are so large that they need xrange, you would > probably get an interesting speedup from using a real C for-loop instead > of an object! I mean for small values xrange is slower than range and > when you think about what range is doing under the covers. To invent more statistics on the spot, I'll declare that loop overhead is a problem in about 3.4% of all interesting loops; what we need is a way to execute the body quicker... Cheers, M. From thomas at xs4all.net Wed Jul 12 23:19:42 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 23:19:42 +0200 Subject: [Python-Dev] Par-for/range In-Reply-To: <396CB4B0.EE284A39@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 01:10:56PM -0500 References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> <396CB4B0.EE284A39@prescod.net> Message-ID: <20000712231942.Q7340@xs4all.nl> On Wed, Jul 12, 2000 at 01:10:56PM -0500, Paul Prescod wrote: > Thomas Wouters wrote: > > For that reason I think it's better to live with xrange() ;) > If we had first class range syntax then it would be relatively easy to > recognize the pattern > > for i in [x:y:z]: > .... > > Then we could generate a special FOR_INTS bytecode. I've heard that "C" > has a pretty efficient implementation of that construct. Yes. This was one of the reasons Guido was interested in this. (We talked about this in private email before I implemented it ;) > Plus, if your loops are so large that they need xrange, you would > probably get an interesting speedup from using a real C for-loop instead > of an object! I mean for small values xrange is slower than range and > when you think about what range is doing under the covers. Well, with the new 'sq_contains' PySequenceMethods member, the operation: number in xrange(19,23578294,3)*393 # for instance ;) also gets very efficient. A *lot* more efficient than using the equivalent [ra::ge] syntax in any case. That would be one reason to add at least a 'BUILD_XRANGE' bytecode, so when the compiler is made sufficiently intelligent, it could issue 'BUILD_XRANGE' opcodes instead of BUILD_RANGE opcodes for if x in [:y:z]: and other instances where the resulting list isn't stored anywhere, so will never be modified. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Wed Jul 12 23:28:26 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 12 Jul 2000 23:28:26 +0200 Subject: [Python-Dev] Par-for/range In-Reply-To: ; from mwh21@cam.ac.uk on Wed, Jul 12, 2000 at 10:03:53PM +0100 References: <20000712161328.I7340@xs4all.nl> <396C915B.8B1A3A1B@prescod.net> <20000712182656.K7340@xs4all.nl> <396CB4B0.EE284A39@prescod.net> Message-ID: <20000712232826.R7340@xs4all.nl> On Wed, Jul 12, 2000 at 10:03:53PM +0100, Michael Hudson wrote: > Paul Prescod writes: > > Thinking some more... > > > > If we had first class range syntax then it would be relatively easy to > > recognize the pattern > > > > for i in [x:y:z]: > > .... > > > > Then we could generate a special FOR_INTS bytecode. I've heard that "C" > > has a pretty efficient implementation of that construct. > Hmm, yes, but how on earth would you implement that in ceval.c? You'd > need another eval loop inside the code for FOR_INTS! (unless I'm > being dense, of course). Nah. We can't use the C for-loop for this, unless the bytecode interpreter is entirely rewritten. The FOR_INT opcode would be something like: on entry, stack contains r, i where r is range-object specifying (start/)step/end, i is loop counter i is incremented by step, checked against end, and if loop hasn't ended yet, r, new 'i' and old 'i' are pushed on the stack, so it contains: r, i+step, i and the rest of the bytecode can remain the same (assign top value to name, etc.) > To invent more statistics on the spot, I'll declare that loop overhead > is a problem in about 3.4% of all interesting loops; what we need is a > way to execute the body quicker... define 'problem' ;) If we can speed things up while keeping the functionality the same, the syntax clearer and the code only slightly more complicated, why not ? :-) Granted, though, if the issue is overall code speed, this isn't going to cut it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gward at mems-exchange.org Wed Jul 12 23:43:39 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 12 Jul 2000 17:43:39 -0400 Subject: [Python-Dev] Demo/embed causes 'import site' failure In-Reply-To: <20000711151740.T26534@xs4all.nl>; from thomas@xs4all.net on Tue, Jul 11, 2000 at 03:17:41PM +0200 References: <200007101532.KAA25812@cj20424-a.reston1.va.home.com> <3969E1EA.27E7F508@lemburg.com> <200007101630.LAA01307@cj20424-a.reston1.va.home.com> <3969EF67.29B9DC05@lemburg.com> <20000710175642.L26534@xs4all.nl> <200007101725.MAA01255@cj20424-a.reston1.va.home.com> <20000710141638.R29590@lyra.org> <200007111348.IAA04699@cj20424-a.reston1.va.home.com> <20000711151740.T26534@xs4all.nl> Message-ID: <20000712174339.A5836@ludwig.cnri.reston.va.us> On 11 July 2000, Thomas Wouters said: > Actually, I was referring to the trick PIL and other extension modules use > to build their own Makefile based on Python's. I'm not sure how portable > that particular Makefile is, however. I'm one of those types that use > 'gmake' on systems that do not have GNU make as the default make ;-) Makefile.pre.in is obsolete. See http://www.python.org/sigs/distutils-sig/ > And forgive me for saying this, but I think providing a good, > self-configuring but slightly unportable Makefile.pre.in *and* a README > (and/or example) that shows how to do it by hand on old/incapacitated > systems, is preferable over just providing a completely unportable Makefile > and a README that shows how to do it on other systems :-) Agreed, but of course the instructions are different (and much easier!) now. Greg From jack at oratrix.nl Wed Jul 12 23:51:17 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 12 Jul 2000 23:51:17 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib dospath.py,1.13,1.14 macpath.py,1.22,1.23 ntpath.py,1.24,1.25 posixpath.py,1.31,1.32 In-Reply-To: Message by Skip Montanaro , Wed, 12 Jul 2000 09:56:00 -0700 , <200007121656.JAA09687@slayer.i.sourceforge.net> Message-ID: <20000712215122.B4E13E2679@oratrix.oratrix.nl> Skip, one bug in posixpath.commonprefix already: you use os.sep where you should use '/'. The pathname-manging routines in xxxpath have always worked on different platforms too (so you can interpret, say, a tarfile on MSDOS), and if I remember correctly this is especially important for posixpath because it's used in some of the url modules. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From bckfnn at worldonline.dk Wed Jul 12 23:48:11 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Wed, 12 Jul 2000 21:48:11 GMT Subject: [Python-Dev] Ranges In-Reply-To: References: Message-ID: <396ce4b5.20282194@smtp.worldonline.dk> [Paul Prescod] >Ka-Ping Yee wrote: >> >> >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] >> [0, 2, 4] > >Well, today this is syntactically correct but it doesn't work as you (or >I) predict. I don't know if that's because nobody has implemented it yet >or if extended slices mean something other than what I think you and I >think they should mean In current JPython: JPython 1.1+07 on java1.3.0 (JIT: null) Copyright (C) 1997-1999 Corporation for National Research Initiatives >>> [0,1,2,3,4,5,6,7,8,9,10][0:5:2] [0, 2, 4] [Ka-Ping Yee} >Ah, yes: http://www.python.org/pipermail/python-dev/2000-July/012681.html > >The issues were > > - handling [:] and [::] consistently > - allowing non-integer indices > - letting user-defined objects do their own handling of negative indices > >I believe the two possibilities were > > __getitem__ gets either an index or a special slice object > __getslice__ is deprecated (when missing, __getitem__ gets the slice args) > >and > > __getitem__ always gets an index > __getslice__ gets three arguments, all optional, defaulting to None > >The latter isn't backward-compatible, but it makes a heckuva lot >more sense. AFAICT JPython already follows the first of the two possibilities. (I'm not suggesting what python-the-language should do but I too find the current behaviour of item/slice is IMO confusing). regards, finn JPython 1.1+07 on java1.3.0 (JIT: null) Copyright (C) 1997-1999 Corporation for National Research Initiatives >>> >>> class S1: ... def __getitem__(self, i): ... print "s1.__getitem__", i ... >>> a = S1() >>> >>> a[1] s1.__getitem__ 1 >>> a[:] s1.__getitem__ None:None:1 >>> a[1:2] s1.__getitem__ 1:2:1 >>> a[1:2:3] s1.__getitem__ 1:2:3 >>> a['a':'z'] s1.__getitem__ 'a':'z':1 >>> a['a':'z':2] s1.__getitem__ 'a':'z':2 >>> >>> >>> class S2: ... def __getslice__(self, i, a): ... print "s2.__getslice__", i, a ... def __len__(self): ... return 10 ... >>> a = S2() >>> >>> a[1] Traceback (innermost last): File "", line 1, in ? AttributeError: __getitem__ >>> a[:] s2.__getslice__ 0 2147483647 >>> a[1:2] s2.__getslice__ 1 2 >>> a[1:2:3] Traceback (innermost last): File "", line 1, in ? AttributeError: __getitem__ >>> a['a':'z'] s2.__getslice__ a z >>> a['a':'z':2] Traceback (innermost last): File "", line 1, in ? AttributeError: __getitem__ >>> a[-1:4] s2.__getslice__ -1 4 >>> >>> class S3: ... def __getitem__(self, i): ... print "s3.__getitem__", i ... def __getslice__(self, i, a): ... print "s3.__getslice__", i, a ... >>> a = S3() >>> >>> a[1] s3.__getitem__ 1 >>> a[:] s3.__getslice__ 0 2147483647 >>> a[1:2] s3.__getslice__ 1 2 >>> a[1:2:3] s3.__getitem__ 1:2:3 >>> a['a':'z'] s3.__getslice__ a z >>> a['a':'z':2] s3.__getitem__ 'a':'z':2 >>> From MarkH at ActiveState.com Thu Jul 13 00:11:58 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Wed, 12 Jul 2000 18:11:58 -0400 Subject: [Python-Dev] Python .NET (was Preventing 1.5 extensions crashing under 1.6/2.0 Python) In-Reply-To: Message-ID: > "Mark Hammond" writes: > > > Sorry for the delay in responding to this stuff - Im at the MS PDC, and > > demoing a new Python compiler that I'm suddenly allowed to > talk about - but > > that isnt the point of this mail :-] > > ? I'm curious now! There is a Python compiler available for the Microsoft .NET framework. Much of the press will have details on this emerging. A CNET article can be found at http://news.cnet.com/news/0-1003-200-2240702.html?tag=st.ne.1430735..ni This new compiler could be compared, conceptually, with JPython - it is a completely new implementation of Python. It has a compiler that generates native Windows .DLL/.EXE files. It uses a runtime that consists of a few thousand lines of C# (C-Sharp) code. The Python programs can be debugged at the source level with Visual Studio 7, as well as stand-alone debuggers for this environment. Python can sub-class VB or C# classes, and vice-versa. Unfortunately, there will not be a public release of their SDK for a couple of months - so the only people able to use this compiler are people who attended the PDC, and hence have the pre-beta SDK on their conference CDs. The compiler is looking pretty reasonable. pystone.py (amongst others, of course) compiles and runs. Im not going to tell you the results yet, 'cos they arent too good ;-) However, this should be quite exciting for the Python community. The general feel of the conference here is that the MS .NET technology is exciting and a good thing. I predict that the Windows community will embrace this technology, and having Python be a first-class citizen is a good thing! It _is_ a radical change, so I predict it wont be really significant on windows for a couple of years yet. Future work on this compiler will be under the ActiveState banner. However, the compiler and the runtime are all open source. The compiler is written in CPython, and uses win32com to get at the Reflection::Emit APIs provided by .NET. All the existing work has been done mainly by me, with some code and advice from Greg. Now the NDA is lifted, I hope (some of) the Python community will get behind this, and take advantage of the open-sourceness of the compiler and runtime, and help us turn this into an excellent language for this environment. All good stuff! Mark. From MarkH at ActiveState.com Thu Jul 13 00:14:13 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Wed, 12 Jul 2000 18:14:13 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <000001bfec40$0eb3a6e0$060210ac@private> Message-ID: > > This is where we are now. I agree that we should not crash, > > but it seems to me you havent solved anything - individual > > .pyd authors needing to tell users about each individual > > .pyd isnt a solution. > At least if Python can detect that a .PYD is out of date you know > to ask for a newer .PYD or build it yourself. A crash is bad PR for > the .PYD and Python. We all agree on this - hence this discussion. My point was that I'm not clear how the proposal moved us closer to this goal. > > > True. And on Windows, there is a standard Version resource > > > string which gives the DLL version, and can be read without > > > loading the DLL. This string is referenced by the Wise (and > > > other) installers to decide whether a DLL is newer and should > > > be replaced. > > > > Im not sure how this helps us. Do you mean that "initfoo" > > should use the Windows resource/version APIs to determine > > if it can load? > As I pointed out you cannot use Py calls from a .PYD to find out > the version as the .PYD calls the function in the old PYTHON15.DLL > not the new one. Firstly, this doesn't answer my question, so I'm not sure why you needed to restate this assertion. I can only assume that the answer to my question, in your opinion, is "yes"? Secondly, I'm not sure why this is a problem. Sure, we can't use the version number, but the extension could, for example, call Py_IsInitialized() - this is likely to be a good indication if our linked DLL is the "correct" one for this process. The problem is not intractable - someone who cares enough should put together a patch, test it, and submit it. Talk-is-cheap-ly, Mark. From gward at mems-exchange.org Thu Jul 13 00:18:53 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 12 Jul 2000 18:18:53 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007121318.IAA14063@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 12, 2000 at 08:18:04AM -0500 References: <20000712031358.X29590@lyra.org> <200007121318.IAA14063@cj20424-a.reston1.va.home.com> Message-ID: <20000712181853.A7355@ludwig.cnri.reston.va.us> On 12 July 2000, Guido van Rossum said: > I would love to have a mechanism (run by configure or maybe better by > makesetup) that automatically determines if a particular external > library package is available. Come to think of it, in first > approximation, makesetup could easily parse the -I, -L and -l options > you specify for a particular extension and only build it if it can > find all those... The Distutils "config" command is *achingly* close to supporting this kind of trickery. (Yes, I finally buckled and started implementing Autoconf in Python. Turned out not to be too hard.) I promised I'll think really hard about how to get it working really well next week, when I'm on holiday... ;-) Greg From peter at schneider-kamp.de Thu Jul 13 02:42:28 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 13 Jul 2000 00:42:28 +0000 Subject: [Python-Dev] simple syntax error bombs interpreter References: <200007121929.VAA09996@python.inrialpes.fr> Message-ID: <396D1074.48F7554A@schneider-kamp.de> Vladimir Marangozov wrote: > > Fredrik Lundh wrote: > > > > using my latest Python 2.0 build, the interpreter > > bombs if I type the following two commands: > > > > >>> def a(b): > > ... global b > > ... > > > > (1.5.2 says "name is local and global"). > > > > That's the same kind of situation I had with my >>> def f(a,a): ... print a segfault > The appended patch should fix it. Let me know whether it works for you. The appended patch works for me. Now my "duplicate arguments" error also works fine. Is there an issue with removing the PyErr_Clear()? Does it serve any just purpose? if-not-please-get-rid-of-it-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul at prescod.net Thu Jul 13 00:52:56 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 17:52:56 -0500 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators for matrix computation] Message-ID: <396CF6C8.94B84B9B@prescod.net> You can guess my instinctive reaction...still, I feel for these guys competing with pricy domain-specific software. -------- Original Message -------- Subject: Discussion: Introducing new operators for matrix computation Date: Wed, 12 Jul 2000 19:32:32 GMT From: hzhu at knowledgetrack.com (Huaiyu Zhu) Reply-To: hzhu at users.sourceforge.net Organization: Giganews.Com - Premium News Outsourcing To: python-list at python.org Newsgroups: comp.lang.python We are at a crucial juncture concerning introduction of new operators into Python for matrix computation, 1. Experiences with Matlab show that different operators for matrix and elementwise operators are very important 2. It is difficult to add .* and ./ as . is already a valid token. It seems that next candidate on the standard keyboard is @. 3. Gregory Lielens has just implemented a patch that could parse additional operators containing @ a at b is equivalent to a*b, overloaded using __mmul__ and __rmmul__ a@/b a/b __mrdiv__ and __rmrdiv__ a/@b b/a __mldiv__ and __rmldiv__ a@@b a**b __mpow__ and __rmpow__ He indicates similar constructions can be added easily. We intend to add these operators together with Thomas Wouters's augmented assignment operators (+=,*=, etc) to MatPy, but before that several decisions need to be made. First, the main choices: 1. Use a*b as matrix mul, and a@*b as elementwise mul. Pros: - Consistent with Matlab. - Consistent with current MatPy. - Convenient for matrix computations. Cons: - Inconsistent with NumPy - How to differentiate left and right div (matlab a\b and a/b)? 2. Use a@*b as matrix mul, and a*b as elementwise mul. Pros: - Consistent with NumPy - Can use a@/b and a/@b as matlab a/b and a\b. - Can use a at b as inner product so that a at b works irrespective of whether a and b are row or col operators. Cons: - Inconsistent with current MatPy. Need great effort to switch. - Using two symbol operator for matrix mul is cumbersome for long formulas. - It kind of looks ugly. 3. Use a at b as matrix mul, and a*b as elementwise mul. This has most of the pros and cons of choice 2, except Pros: - Single symbol operators for matrix mul and element mul. Cons: - Can't use a at b as inner product. Just to add to the agony, here are a few contrary views: 1. Consistency with Matlab is not necessarily good. In Matlab operators default to matrix (cf * and .*) but functions default to elementwise (cf exp and expm). In Python ** is defined by __pow__. Should it be consistent with pow the function or ** the operator? 2. Consistency with NumPy is not necessarily good. Currently one can use MatPy and NumPy at the same time. a*b will be matrixwise for MatPy and elementwise for NumPy. This is convenient when each usage is dominant in some part of a program. Removing this difference and MatPy will lose a lot of appeal when it is needed. 3. Although it is relatively difficult to switch the usage in MatPy, it is still a good time if we deem this to be A Good Thing. When the status is changed to beta from alpha it would be next to impossible to switch. To throw you completely off the track, here is one additional feature request that would great please mathematicians and greatly annoy computer scientists: Use ^ and @^ for matrix power. Currently ^ is defined as xor which is of sufficiently low level that is unlikely to occur with matrix computations. Note that this is not in our plan right now. One other thing that will be of great efficiency value (whenver somebody comes forward to do it) is to parse := as assignment. This way we can let a=b be simple reference assignment without creating a new Matrix object. The implementors of both previous patches have cautioned that Guido is unlikely to adopt the patch for the .* or @* operators. But I'm quite confident that he can be persuaded. There is a large number of users of Matlab and Octave (maybe even more than users of Python), and there is no fundamental reason they cannot use Python for doing the same thing, provided that we are allowed to add this little additional operator. :-) What other incentives are needed to persuade Guido? Here's a quote from Gregory, > they make a huge difference in readability of code dealing with linear > algebra, in particular when using small matrices. Such operators explain > partly the popularity of Matlab-like tools, imho. I can argue that linear algebra is very important for Python, perhaps even more important than complex numbers, but this is off topic. So all your comments, suggestions and flames a invited. I just have a small request: As this is getting too long, please reply separately to different parts of this article, so that the discussion threads remain manageable. -- Huaiyu Zhu hzhu at users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net -- http://www.python.org/mailman/listinfo/python-list From esr at thyrsus.com Thu Jul 13 01:23:25 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 19:23:25 -0400 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: ; from ping@lfw.org on Wed, Jul 12, 2000 at 02:35:21AM -0700 References: Message-ID: <20000712192325.F799@thyrsus.com> Ka-Ping Yee : > Jodinat greidar fablo! Ruinon flast; ruinon flast. Thorvon > whananadak yum, onk triplation is dortiful. <0.5 wink> > > Ecky-ecky-ecky-ecky-pikang-zoop-boing? > > > -- ?!ng :pingspeak: n. [Python development list] Attractive but incomprehensible babble. Pingspeak is distinguished from lower-quality nonsense by being at least phonotactically plausible, as if the author is writing in a language you don't know. -- Eric S. Raymond Every election is a sort of advance auction sale of stolen goods. -- H.L. Mencken From esr at thyrsus.com Thu Jul 13 01:26:55 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 19:26:55 -0400 Subject: [Python-Dev] File Object Copy In-Reply-To: <20000712014338.Q29590@lyra.org>; from gstein@lyra.org on Wed, Jul 12, 2000 at 01:43:38AM -0700 References: <20000712014338.Q29590@lyra.org> Message-ID: <20000712192655.G799@thyrsus.com> Greg Stein : > Put the bugger in shutil for now. Step two: propose a new organization. I agree. -- Eric S. Raymond Everything you know is wrong. But some of it is a useful first approximation. From esr at thyrsus.com Thu Jul 13 01:40:53 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 19:40:53 -0400 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <14700.29709.259658.864250@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 12, 2000 at 09:35:09AM -0400 References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> Message-ID: <20000712194053.J799@thyrsus.com> Barry A. Warsaw : > Is weave() perhaps a better name? I *like* it. Better than the `with()' I independently invented. I think the fact that three people indeoendently invented with()/parallel()/weave()/zip() in responmse to the syntax discussion is in itself pretty good evidence that a generator builtin would be better than new syntax. -- Eric S. Raymond In recent years it has been suggested that the Second Amendment protects the "collective" right of states to maintain militias, while it does not protect the right of "the people" to keep and bear arms. If anyone entertained this notion in the period during which the Constitution and the Bill of Rights were debated and ratified, it remains one of the most closely guarded secrets of the eighteenth century, for no known writing surviving from the period between 1787 and 1791 states such a thesis. -- Stephen P. Halbrook, "That Every Man Be Armed", 1984 From esr at thyrsus.com Thu Jul 13 01:42:52 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 19:42:52 -0400 Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C9661.3EF03755@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 11:01:37AM -0500 References: <396BA425.2EF3B11F@prescod.net> <14699.59823.710880.896491@anthem.concentric.net> <14700.32671.461502.666561@beluga.mojam.com> <396C9661.3EF03755@prescod.net> Message-ID: <20000712194252.K799@thyrsus.com> Paul Prescod : > "Stitch" and "with" are okay, but I'd like to hear someone debunk the > names used today by MAL. They seemed very logical to me. I'd just change > the semantics to be lazy in a couple of cases. I would be happy with weave(), with(), or MAL's names. I think zip is best avoided for reasons already discussed. -- Eric S. Raymond "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), From klm at digicool.com Thu Jul 13 01:54:59 2000 From: klm at digicool.com (Ken Manheimer) Date: Wed, 12 Jul 2000 19:54:59 -0400 (EDT) Subject: [Python-Dev] zip() and list-comprehension with commas In-Reply-To: <396C9661.3EF03755@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > Skip Montanaro wrote: > > > > BAW> Alternatives (as Greg I think brought up): pairwise(), maybe > > BAW> zipper() for zip() since it's more evocative. > > > > "zip" already has a lot of compression connotations. How about "stitch", as > > in "stitch two lists together"? > > "Stitch" and "with" are okay, but I'd like to hear someone debunk the > names used today by MAL. They seemed very logical to me. I'd just change > the semantics to be lazy in a couple of cases. > > >>> tuple([1,2,3]) > (1,2,3) > > >>> tuples([1,2,3],[4,5,6]) > > > >>> list((1,2,3)) > [1,2,3] > > >>> lists((1,2,3),(4,5,6)) > > > >>> dict([(1,2),(3,4),(5,6)]) > {1:2,3:4,5:6} How about this different name, with a somewhat different approach: Name is "furl", with inverse "unfurl". First argument is the target-type of the result: >>> furl([], (1, 2, 3), [4, 5, 6,]) [[1,4], [2,5], [3,6]] >>> furl((), [1,2,3],(4,5,6)) ((1,4), (2,5), (3,6)) >>> furl({}, (1,2,3), "abc") {1:'a', 2:'b', 3:'c'} >>> unfurl([], [1,4], [2,5], [3,6]) [[1, 2, 3], [4, 5, 6]] >>> unfurl((), [1,4], [2,5], [3,6]) ((1, 2, 3), (4, 5, 6)) >>> unfurl((), {1:'a', 2:'b', 3:'c'}) ((1, 2, 3), ('a', 'b', 'c')) Being explicit about the type of the result, rather than keying on the type of both arguments, means you're not surprised by an exception when one of your vars had a tuple and the other had a list. Better explicit than implicit, ay? I'm not at all opposed yielding generators, like in skip's example. Seems like comprehensions and simple notations for infinite generators - "[1..]" - would deliver the benefits of concise, arbitrarily elaborate stream sources where xrange, alone, falls way short. I really like "furl" - it may help to appreciate the charm if you say it out loud a few times: "furl". "furl". "furl". Ahhh. :-) Ken From akuchlin at cnri.reston.va.us Thu Jul 13 02:13:44 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Wed, 12 Jul 2000 20:13:44 -0400 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators for matrix computation] In-Reply-To: <396CF6C8.94B84B9B@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 05:52:56PM -0500 References: <396CF6C8.94B84B9B@prescod.net> Message-ID: <20000712201344.A1974@newcnri.cnri.reston.va.us> On Wed, Jul 12, 2000 at 05:52:56PM -0500, Paul Prescod quoted: >From: hzhu at knowledgetrack.com (Huaiyu Zhu) >The implementors of both previous patches have cautioned that Guido is >unlikely to adopt the patch for the .* or @* operators. But I'm quite >confident that he can be persuaded. There is a large number of users of Why not simply write a new parser for this application that generates the desired semantics? Maintaining a complete fork of the Python source might not be necessary if Jeremy's Python parsing/compiling framework could be easily modified to implement the new operators. (While a Python variant isn't something I'm enthused about, one language can't be all things to all people, and I don't see why matrix operations are so important as to get extra specialized operators; lots of people use Python for text processing or for COM, so why shouldn't special syntax be added for *those* applications? Having a special parser also means that other matrix-specific language changes could be made.) --amk From guido at beopen.com Thu Jul 13 03:38:28 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 20:38:28 -0500 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Your message of "Wed, 12 Jul 2000 19:40:53 -0400." <20000712194053.J799@thyrsus.com> References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> <20000712194053.J799@thyrsus.com> Message-ID: <200007130138.UAA01580@cj20424-a.reston1.va.home.com> > Barry A. Warsaw : > > Is weave() perhaps a better name? [ESR] > I *like* it. Better than the `with()' I independently invented. > > I think the fact that three people indeoendently invented > with()/parallel()/weave()/zip() in responmse to the syntax discussion > is in itself pretty good evidence that a generator builtin would be better > than new syntax. Yes, I agree. Main reason: it's trivial to combine this with list comprehensions, while the ';' notation had real problems there. My bid for a name: splice(). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Thu Jul 13 03:06:57 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 21:06:57 -0400 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <200007130138.UAA01580@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 12, 2000 at 08:38:28PM -0500 References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> <20000712194053.J799@thyrsus.com> <200007130138.UAA01580@cj20424-a.reston1.va.home.com> Message-ID: <20000712210657.Q799@thyrsus.com> Guido van Rossum : > Yes, I agree. Main reason: it's trivial to combine this with list > comprehensions, while the ';' notation had real problems there. Perhaps this frees up semicolon for use in the list-comprehension constructor syntax. BTW, I think whoever it was that suggested lazy eval for comprehensions was right on -- but that ties into the larger issue of generators and continuations. Really, a list comprehension ought to be syntactic sugar for an Icon-like generator object. > My bid for a name: splice(). Wearing my English-usage-pedant hat, I must regretfully judge this inferior to weave(). The reason has to do with the spatial geometry implied by the verbs. You *splice* two ropes together end-to-end; the proper data-structure analogy is with concatenation, and indeed splice() in Perl is a sort of generalized slice'n'dicer for sequences. On the other hand, you *weave* two threads together side by side to form a parallel bundle. Much closer image. OTOH, MAL's group of related constructors is pretty cool. -- Eric S. Raymond The real point of audits is to instill fear, not to extract revenue; the IRS aims at winning through intimidation and (thereby) getting maximum voluntary compliance -- Paul Strassel, former IRS Headquarters Agent Wall St. Journal 1980 From pingster at ilm.com Thu Jul 13 03:07:33 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 18:07:33 -0700 (PDT) Subject: [Python-Dev] co_lnotab and SET_LINENO Message-ID: Now that we have co_lnotab, why do we still generate SET_LINENO opcodes? -- ?!ng From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 03:26:23 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 03:26:23 +0200 (CEST) Subject: [Python-Dev] co_lnotab and SET_LINENO In-Reply-To: from "Ka-Ping Yee" at Jul 12, 2000 06:07:33 PM Message-ID: <200007130126.DAA10951@python.inrialpes.fr> Ka-Ping Yee wrote: > > Now that we have co_lnotab, why do we still generate > SET_LINENO opcodes? It has been discussed before. To summarize: - because these opcodes generate the callbacks from C to Python - the debugger relies on them - I haven't had the time to look seriously at the debugger and make it work without them. (this relates with breakpoints setting which requires generating callbacks for every source line) And this is where we are. If you're volunteering to look into this, I'll spend some time summarizing the pointers about this thread + the existing code in the area. Otherwise, I won't bother -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one at email.msn.com Thu Jul 13 03:38:00 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 12 Jul 2000 21:38:00 -0400 Subject: [Python-Dev] ! In-Reply-To: Message-ID: [David Ascher] > Keeping up w/ python dev, patches and checkins is getting to be a huge > amount of work! > > Should we _thank_ lawyers for turning what was a small intense rush in > getting things done before a release into a long intense rush? Perish the > thought... > > +1 on the new python-dev community! Except it's largely still the same python-dev community: the perceived zoom in productivity is entirely due to my forcing patch management onto SourceForge -- well, either that, or that the laywers keep Guido so busy that he can't take time to interfere with progress anymore . whatever-the-cause-don't-jinx-it-ly y'rs - tim From guido at beopen.com Thu Jul 13 04:41:06 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 12 Jul 2000 21:41:06 -0500 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Your message of "Wed, 12 Jul 2000 21:06:57 -0400." <20000712210657.Q799@thyrsus.com> References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> <20000712194053.J799@thyrsus.com> <200007130138.UAA01580@cj20424-a.reston1.va.home.com> <20000712210657.Q799@thyrsus.com> Message-ID: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> > > My bid for a name: splice(). > > Wearing my English-usage-pedant hat, I must regretfully judge this > inferior to weave(). The reason has to do with the spatial geometry > implied by the verbs. > > You *splice* two ropes together end-to-end; the proper data-structure > analogy is with concatenation, and indeed splice() in Perl is a sort > of generalized slice'n'dicer for sequences. > > On the other hand, you *weave* two threads together side by side to > form a parallel bundle. Much closer image. Oops. I see now that splice isn't the right thing. But the first meaning of weave that comes to me suggest a 2D interlacing of threads that gives the wrong impression here (I know there are others but I'm much less familiar with them). I looked in a thesaurus and found a few potential alternatives: twine entwine intertwine interweave interlace interspeerse If none of these appeal, I say let's use zip and end this impossibly long thread. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From DavidA at ActiveState.com Thu Jul 13 03:44:13 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 12 Jul 2000 18:44:13 -0700 (Pacific Daylight Time) Subject: [Python-Dev] ! In-Reply-To: Message-ID: > > +1 on the new python-dev community! > > Except it's largely still the same python-dev community: It's the same group of people, behaving differently. Social change in action. It's a new community. =) > the perceived zoom > in productivity is entirely due to my forcing patch management onto > SourceForge -- well, either that, or that the laywers keep Guido so busy > that he can't take time to interfere with progress anymore . Actually, it's decentralization of responsibilities and power, and more people having full-time jobs doing the stuff. The lawyers help too =). --david From klm at digicool.com Thu Jul 13 03:47:33 2000 From: klm at digicool.com (Ken Manheimer) Date: Wed, 12 Jul 2000 21:47:33 -0400 (EDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: Guido: > I looked in a thesaurus and found a few potential alternatives: > > twine > entwine > intertwine > interweave > interlace > interspeerse > > If none of these appeal, I say let's use zip and end this impossibly > long thread. I have real doubts about using zip because of the extremely prominent "compression" connotations - it's one of the few things that neophyte as well as experienced computer users are exposed to, with winzip etc. I actually like interlace a lot. I also like "furl" - especially when you say it: "Furl. Furl. Furl." :-) Ken klm at digicool.com From bwarsaw at beopen.com Thu Jul 13 03:49:44 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 21:49:44 -0400 (EDT) Subject: [Python-Dev] zip() and list-comprehension with commas References: <396BA425.2EF3B11F@prescod.net> <14699.59823.710880.896491@anthem.concentric.net> <14700.32671.461502.666561@beluga.mojam.com> <396C9661.3EF03755@prescod.net> Message-ID: <14701.8248.42404.797966@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> "Stitch" and "with" are okay, but I'd like to hear someone PP> debunk the names used today by MAL. They seemed very logical PP> to me. I'd just change the semantics to be lazy in a couple of PP> cases. I don't like the fact that this will give you two pairs of built-ins that differ only by the last letter. It seems too easy to mistype or misread. OTOH, I've argued for a dict() built-in before. -Barry From bwarsaw at beopen.com Thu Jul 13 03:58:49 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 21:58:49 -0400 (EDT) Subject: [Python-Dev] Python .NET (was Preventing 1.5 extensions crashing under 1.6/2.0 Python) References: Message-ID: <14701.8793.942357.20599@anthem.concentric.net> >>>>> "MH" == Mark Hammond writes: MH> This new compiler could be compared, conceptually, with MH> JPython - it is a completely new implementation of Python. All this sounds very cool Mark, thanks for giving us an initial rundown! So what are you calling this particular Python interpreter? #Python? Naw... NPython? Naw... :) -Barry From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 04:03:14 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 04:03:14 +0200 (CEST) Subject: [Python-Dev] co_lnotab and SET_LINENO In-Reply-To: <200007130126.DAA10951@python.inrialpes.fr> from "Vladimir Marangozov" at Jul 13, 2000 03:26:23 AM Message-ID: <200007130203.EAA11217@python.inrialpes.fr> Vladimir Marangozov wrote: > > Ka-Ping Yee wrote: > > > > Now that we have co_lnotab, why do we still generate > > SET_LINENO opcodes? > > It has been discussed before. To summarize: > > - because these opcodes generate the callbacks from C to Python > - the debugger relies on them > - I haven't had the time to look seriously at the debugger and > make it work without them. (this relates with breakpoints setting > which requires generating callbacks for every source line) > > And this is where we are. If you're volunteering to look into this, > I'll spend some time summarizing the pointers about this thread + > the existing code in the area. Otherwise, I won't bother OK, if someone wants to play with this, see: http://starship.python.net/~vlad/lineno/ for (working at the time) patches Discussions on python-dev: - http://www.python.org/pipermail/python-dev/2000-April/subject.html Subject: "Why do we need Traceback Objects?" - http://www.python.org/pipermail/python-dev/1999-August/002252.html I'd be happy to discuss the topic again, offline, with any volunteer(s) willing to take over (and to look closely at the debugger issue -- I don't use the debugger and I can't make the time for it). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From skip at mojam.com Thu Jul 13 04:14:37 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 12 Jul 2000 21:14:37 -0500 (CDT) Subject: [Python-Dev] Python .NET (was Preventing 1.5 extensions crashing under 1.6/2.0 Python) In-Reply-To: <14701.8793.942357.20599@anthem.concentric.net> References: <14701.8793.942357.20599@anthem.concentric.net> Message-ID: <14701.9741.273410.914425@beluga.mojam.com> BAW> So what are you calling this particular Python interpreter? BAW> #Python? Naw... NPython? Naw... :) How about McPython? 95-billion-served-ly y'rs, Skip From esr at thyrsus.com Thu Jul 13 04:54:09 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 12 Jul 2000 22:54:09 -0400 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <200007130241.VAA01765@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 12, 2000 at 09:41:06PM -0500 References: <20000712094447.2275337186D@snelboot.oratrix.nl> <14700.29709.259658.864250@anthem.concentric.net> <20000712194053.J799@thyrsus.com> <200007130138.UAA01580@cj20424-a.reston1.va.home.com> <20000712210657.Q799@thyrsus.com> <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: <20000712225409.W799@thyrsus.com> Guido van Rossum : > twine > entwine Not bad. > intertwine > interweave Too long. > interlace Nah. Interlace is something you do with video. > interspeerse Too long. > If none of these appeal, I say let's use zip and end this impossibly > long thread. zip() has known problems -- people *will* associate it with compression. Which is too bad, it's a great image. -- Eric S. Raymond In every country and in every age, the priest has been hostile to liberty. He is always in alliance with the despot, abetting his abuses in return for protection to his own. -- Thomas Jefferson, 1814 From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 05:04:04 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 05:04:04 +0200 (CEST) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: <20000712225409.W799@thyrsus.com> from "Eric S. Raymond" at Jul 12, 2000 10:54:09 PM Message-ID: <200007130304.FAA11483@python.inrialpes.fr> Eric S. Raymond wrote: > > Guido van Rossum : > > twine > > entwine > > Not bad. Ugh. Never heard about these <0.8 wink>. Make it simple and explicit for non-english speakers too, please. I'm-about-to-whine-so-I-propose-"combine()"-ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From pingster at ilm.com Thu Jul 13 05:01:59 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 20:01:59 -0700 (PDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: These verbs have the following meanings to me: >>> splice([1, 2, 3], [4, 5, 6]) [1, 2, 3, 4, 5, 6] >>> weave([1, 2, 3], [4, 5, 6]) [1, 4, 2, 5, 3, 6] >>> interlace([1, 2, 3], [4, 5, 6]) [1, 4, 2, 5, 3, 6] I also did a little surveying. I got opinions that "interlace" was especially misleading; "zip" was deemed to evoke compression too strongly; and "parallel" evoked concurrency too strongly. The people i asked generally agreed with the interpretations i used above, though one thought that weave() would produce [[1, 4], [2, 5], [3, 6]]. I'm afraid i have to say that "with" is a horrible name for a function, as it's a preposition. Verbs work best for function names, and nouns are next best. Prepositions are very awkward. One person i asked even said that of all the various options, he still liked "map(None, ...)" best because all the others had potentially conflicting connotations. I personally still like "zip", but i must defer to empirical results. "tuples" may be the clearest option. "twine" seems plausible (though it makes me think of twisting and rotation). (By the way, let's not forget irange. Go, irange, go!) -- ?!ng From pingster at ilm.com Thu Jul 13 05:09:09 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 20:09:09 -0700 (PDT) Subject: [Python-Dev] Re: Iterating in parallel In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Ka-Ping Yee wrote: > One person i asked even said that of all the various options, > he still liked "map(None, ...)" best because all the others had > potentially conflicting connotations. I forgot to add: when i said "map(None, ...)" was ugly, this person suggested "munge()", indicating that he'd prefer a completely obscure name to a name that might risk an alternate interpretation. He liked "munge()" and "twine()" best, considered "tuples()" acceptable, and declared "zip()" unacceptable but "zipper()" acceptable. -- ?!ng From pingster at ilm.com Thu Jul 13 05:37:32 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 12 Jul 2000 20:37:32 -0700 (PDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Ken Manheimer wrote: > > I also like "furl" - especially when you say it: > "Furl. Furl. Furl." But furling is like rolling something up. *sigh* More words: marry knit stitch merge weld meld ladder Considered but rejected: adhere, braid, mesh, lash, crosslink, bind, conjoin, unite, tie, squeeze. Hm. None really beat "zip" for me in terms of the visualization (except perhaps "marry"). -- ?!ng From bwarsaw at beopen.com Thu Jul 13 05:45:29 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 23:45:29 -0400 (EDT) Subject: [Python-Dev] Iterating in parallel References: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: <14701.15193.695315.549635@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> I personally still like "zip", but i must defer to empirical KY> results. "tuples" may be the clearest option. "twine" seems KY> plausible (though it makes me think of twisting and rotation). Let me throw one more out, in honor of our fearless leader's recent life change: marry(). Usually only done in pairs, and with two big sequences, I get the image of a big Unification Church event :) -Barry From bwarsaw at beopen.com Thu Jul 13 05:54:34 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 12 Jul 2000 23:54:34 -0400 (EDT) Subject: [Python-Dev] Iterating in parallel References: Message-ID: <14701.15738.293596.60350@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> Hm. None really beat "zip" for me in terms of the KY> visualization (except perhaps "marry"). You and I think too much alike ?!ng. And if that doesn't scare you now, you should have a talk with Gordon. -Barry From esr at thyrsus.com Thu Jul 13 06:09:29 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 00:09:29 -0400 Subject: [Python-Dev] Re: Iterating in parallel In-Reply-To: ; from pingster@ilm.com on Wed, Jul 12, 2000 at 08:37:32PM -0700 References: Message-ID: <20000713000929.B3212@thyrsus.com> Ka-Ping Yee : > On Wed, 12 Jul 2000, Ken Manheimer wrote: > > > > I also like "furl" - especially when you say it: > > "Furl. Furl. Furl." > > But furling is like rolling something up. > > *sigh* More words: > > marry > knit > stitch > merge > weld > meld > ladder > > Considered but rejected: adhere, braid, mesh, lash, crosslink, bind, > conjoin, unite, tie, squeeze. > > Hm. None really beat "zip" for me in terms of the visualization > (except perhaps "marry"). `knit' would work for me. -- Eric S. Raymond Whether the authorities be invaders or merely local tyrants, the effect of such [gun control] laws is to place the individual at the mercy of the state, unable to resist. -- Robert Anson Heinlein, 1949 From paul at prescod.net Thu Jul 13 06:02:28 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 23:02:28 -0500 Subject: [Python-Dev] Iterating in parallel References: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> <14701.15193.695315.549635@anthem.concentric.net> Message-ID: <396D3F54.39DD165F@prescod.net> "Barry A. Warsaw" wrote: > > ... > > Let me throw one more out, in honor of our fearless leader's recent > life change: marry(). Usually only done in pairs, and with two big > sequences, I get the image of a big Unification Church event :) Isn't it somewhat of a political statement to allow marriages of three or more items? I always presumed that this function was n-ary, like map. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From esr at thyrsus.com Thu Jul 13 06:26:00 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 00:26:00 -0400 Subject: [Python-Dev] Iterating in parallel In-Reply-To: <396D3F54.39DD165F@prescod.net>; from paul@prescod.net on Wed, Jul 12, 2000 at 11:02:28PM -0500 References: <200007130241.VAA01765@cj20424-a.reston1.va.home.com> <14701.15193.695315.549635@anthem.concentric.net> <396D3F54.39DD165F@prescod.net> Message-ID: <20000713002600.E3212@thyrsus.com> Paul Prescod : > > Let me throw one more out, in honor of our fearless leader's recent > > life change: marry(). Usually only done in pairs, and with two big > > sequences, I get the image of a big Unification Church event :) > > Isn't it somewhat of a political statement to allow marriages of three > or more items? I always presumed that this function was n-ary, like map. Perhaps we should call it "menage()"? :-) (Eric looks back on some fond memories. And no, you *don't* get the details.) -- Eric S. Raymond Let us hope our weapons are never needed --but do not forget what the common people knew when they demanded the Bill of Rights: An armed citizenry is the first defense, the best defense, and the final defense against tyranny. If guns are outlawed, only the government will have guns. Only the police, the secret police, the military, the hired servants of our rulers. Only the government -- and a few outlaws. I intend to be among the outlaws. -- Edward Abbey, "Abbey's Road", 1979 From DavidA at ActiveState.com Thu Jul 13 06:24:19 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 12 Jul 2000 21:24:19 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Iterating in parallel In-Reply-To: <20000713002600.E3212@thyrsus.com> Message-ID: > Perhaps we should call it "menage()"? :-) > > (Eric looks back on some fond memories. And no, you *don't* get the details.) ObJoke: A friend of mine in college was walking through a supermarket with her girlfriend (they were both highschool students at the time) and her girlfriend's mom. As she is walking down the aisle, the girlfriend had a sudden feeling of reliving a past experience, as if life was repeating itself and she was seeing things over again. She turned to her mom down the aisle and shouted: Hey, mom, I just had a 'maynage a troah!' I love misunderstood French. --david From paul at prescod.net Thu Jul 13 06:26:15 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 23:26:15 -0500 Subject: [Python-Dev] List comprehensions Message-ID: <396D44E7.F87983AB@prescod.net> I want to summarize my feelings on the list-comp syntax issue. There is no syntax for list comprehensions that will inherently scream "cartesian product, not parallel". The only way to do it is by analogy to what they already know: Python. [for x: if y(x): for z: (x,y,z)] -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From moshez at math.huji.ac.il Thu Jul 13 06:44:40 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 13 Jul 2000 07:44:40 +0300 (IDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <396CAE7D.B85AA3FB@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > Moshe Zadka wrote: > > > > What would people think about xmap(), which acts anologously to xrange(), > > IOW calculate lazilly instead of eagerly? Or even, calculate "on demand", > > without caching: > > .... > > Wouldn't this solve the parallel iteration problem? > > I don't think that using a function called "xmap" to build tuples is > very intuitive to start with. What's so wrong with a builtin called > "tuples()"? The name isn't so important -- what is more important is the lazy aspect of the thing. (And anyway, map/xmap is more general then tuples: def tuples(*lists): apply(map, (None,)+lists) ) and I see no reason not to support the stronger construct -- tuples could be build above it. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul at prescod.net Thu Jul 13 06:31:06 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 23:31:06 -0500 Subject: [Python-Dev] re: list comprehension / pop quiz References: Message-ID: <396D460A.96CCC807@prescod.net> Moshe Zadka wrote: > > ... > > The name isn't so important -- what is more important is the lazy aspect > of the thing. Names are always important. Is an xmap like an x-man? > (And anyway, map/xmap is more general then tuples: > > def tuples(*lists): > apply(map, (None,)+lists) > ) and I see no reason not to support the stronger construct -- tuples > could be build above it. I agree. I just think that the stronger construct should be called "lazy list comprehension". list comps. are much more general than maps and also easier to read. As you've pointed out, making them lazy also makes them more powerful. I don't think that there is any need for the eager equivalent because it is so easy to resolve a lazy one to an eager one in the rare case that that's what you need. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From klm at digicool.com Thu Jul 13 08:25:30 2000 From: klm at digicool.com (Ken Manheimer) Date: Thu, 13 Jul 2000 02:25:30 -0400 (EDT) Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Ken Manheimer wrote: > Guido: > > > I looked in a thesaurus and found a few potential alternatives: > > [...] > > interlace > > [...] > > If none of these appeal, I say let's use zip and end this impossibly > > long thread. > > I actually like interlace a lot. Huh - how about "lace"? I like that even more than "interlace" - shorter, and with a particular, visceral appeal when thinking about laces that tie clothing together, like shoelaces. Lacing shoes means interleaving the laces, and unlacing them means un-interleaving them. Extraordinarily close visceral/physical analogue for the interlacing of the list/tuple arguments. For those that didn't see my posting in the thread "Re: zip() and list-comprehension with commas", i think it's a good idea to be explicit about the type of the results, rather than inferring them from the types of the arguments. Seem like there are so many contexts where lists and tuples are interchangeable that it's too easy for a variable to contain one when you expect the other - and the reorganizing routine would wind up raising unexpected errors, or unpredictable results, too often. Better to be explicit. And dictionaries seem like reasonable targets for lacing. >>> lace([], (1, 2, 3), [4, 5, 6,]) Lace [[1,4], [2,5], [3,6]] -%- \ / >>> lace((), [1,2,3],(4,5,6)) X ((1,4), (2,5), (3,6)) / \ \ / >>> lace({}, (1,2,3), "abc") X {1:'a', 2:'b', 3:'c'} (_) >>> unlace([], [1,4], [2,5], [3,6]) unlace [[1, 2, 3], [4, 5, 6]] \ / | | >>> unlace((), [1,4], [2,5], [3,6]) | | ((1, 2, 3), (4, 5, 6)) | | | | >>> unlace((), {1:'a', 2:'b', 3:'c'}) | | ((1, 2, 3), ('a', 'b', 'c')) |__| Also, i like having generators as the results of lacing things... I wonder whether this will have any inherent meaning for non-english speakers? Then again, i'm not sure 'tuple' had a lot of meaning for a lot of english or non-english speakers - people get used to it, as long as it's not using a word commonly known to have a *different* meaning in context (eg, "zip"). Ken From paul at prescod.net Thu Jul 13 08:07:30 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 01:07:30 -0500 Subject: [Python-Dev] strncpy Message-ID: <396D5CA2.DBBBDC2C@prescod.net> Tim, Re: Patch #100874 Thanks for the quick disposition. I'll fix the style errors. It's just so hard to concentrate on style when you're trying to fit code into the 5 character margin left by Guido's indentation style. Grrrr. ceval reminds me of old BBS messages written on a Commodore-64, but read on a 17" monitor. About this: > char buf[500]; > ... followed by an unchecked sprintf into buf. > > This is a security hole: Python doesn't restrict identifiers to > being no longer than 500 chars, so a hacker can easily trick this > code into overwriting the buffer bounds. I was prepared to be paranoid about this but then I saw this comment: /* XXX There are several unchecked sprintf or strcat calls in this file. XXX The only way these can become a danger is if some C code in the XXX Python source (or in an extension) uses ridiculously long names XXX or riduculously deep nesting in format strings. */ I interpreted that as "Python enforces reasonable identifier lengths, and only C code can violate it. I'm surprised to learn that Python doesn't have a max identifier length #defined somewhere. Especially since there is a defacto (probably undocumented) length limit for names in C extensions (according to the comment above). > Easy but tedious to > fix (e.g., #define the buf length, and use runtime code in > conjunction with strncpy to guarantee buf's bounds are respected). Let me suggest two non-tedious solutions so you can shoot them down: 1. sprintf(buf, "Local variable referenced " "before assignment: %.128s", namestr); Rationale: if you don't know what variable I'm talking about after 128 characters, you've got bigger problems than I can help with. I see this solution elsewhere in the code. 2. Add an implementation of snprintf to our code and fix the other hundred or so sprintf occurrences to use it. Most of them are safe but it couldn't hurt to pass cleanly through those heuristic security checkers Here's one: http://www.ijs.si/software/snprintf/ And there is one in Apache. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 08:09:50 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 01:09:50 -0500 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> Message-ID: <396D5D2E.4844F7FF@prescod.net> Paul Prescod wrote: > > Re: Patch #100874 Also, the LOAD_FAST and DELETE_FAST cases are identical when an exception is thrown. Should I make a small function as I would usually do or is that "bad style" in ceval. Moving code out of the switch probably helps keep commonly used code local and uncommon code "unlocal". -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From bwarsaw at beopen.com Thu Jul 13 09:00:17 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 03:00:17 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) Message-ID: <14701.26881.172217.870049@anthem.concentric.net> At our Pythonlabs meeting today, we decided we needed a more formal and organized way to track all the language and other changes being discussed on python-dev. Someone else (I don't remember who) suggested an IETF-like approach. I like that as a model, but am not sure how much of that formalism we need to adopt (or is even appropriate for us). Since my finger was slowest reaching my nose, I got elected Editor. On the positive side of that, I get to make the early decisions that will be cursed for generations of Python hackers to come. In any event, here's what I've just checked in. These things are called PEPs or Python Enhancement Proposals. Each has a number assigned to it by the Editor (me) which never changes over the lifetime of the proposal. The format is very loosely defined right now, but I'm sure will undergo formalization itself over time. Essentially, each PEP starts with a bunch of RFC822 style headers. Required headers are PEP: the number assigned by the editor Title: the title as given by the owner of the PEP Version: usually $Revision$ Owner: the owner/champion/shepherd of the PEP Status: the status as chosen from a currently very ill-defined set Optional headers are Python-Version: what version of Python this pertains to PEP 0 (zero) is the index of PEPs. PEP 1 will be the PEP Guidelines document (essentially this email message when it reflects back to my mailbox). I'll continue to own both these for the time being. PEP 200 is the Python 2.0 release schedule. Jeremy Hylton will own this one. PEP 201 discusses the parallel iteration feature. I currently own this one, and have fleshed this out completely based on my understanding of the issues as of 2:45am 13-Jul-2000. Use this as an example of the PEP format until PEP 1 is completed. PEP 202 will cover list comprehensions. I think Tim Peters volunteered to own this one. PEP 203 will cover augmented assignments. Thomas Wouters, we were thinking about you owning this one. My thoughts for these documents are that they will be almost completely self-contained, so that someone freshly coming on the issue can read the PEP, understand what the problem is, how the proposed solution works, and where to go to find more information. Wading through, or even following, the python-dev mailing list or archives should not be necessary. Another advantage is that these things will live in the Python CVS tree, so they will be diff-able, modifiable by anybody with check-in privileges, and will have the complete history in their CVS logs. What I don't want to do: argue about meta issues, such as whether PEPs are a good acronym, or whether we should use plain text or XML, or whether I've had enough sleep lately. They probably aren't, but I couldn't think of anything better; plain text is readable and writable by everybody and I didn't want to waste time trying to write a DTD; I haven't, so what's new? You can find the current set of documents under nondist/peps in the CVS tree. Please take a look, especially at pep-0201.txt which is nearest to being complete. Time for sleep. -Barry From paul at prescod.net Thu Jul 13 08:12:57 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 01:12:57 -0500 Subject: permuting several lists (was Re: [Python-Dev] zip() andlist-comprehension with commas) References: Message-ID: <396D5DE9.A0990F3F@prescod.net> Ken Manheimer wrote: > > ... > > Seem like there are so many contexts > where lists and tuples are interchangeable that it's too easy for a > variable to contain one when you expect the other - and the > reorganizing routine would wind up raising unexpected errors, or > unpredictable results, too often. Well, we (at least you and I) agree that we should use a generator, so you don't really have any control over the outer data structure without using a cast. I think it is safe to default the inner data structure to tuple. Tuples are safe because errors involving them cause TypeErrors whereas accidental writes to shared lists cause weird mutation bugs. Here are some variants you can get using recently proposed features: List of tuples: >>> list( lace( a, b, c )) A tuple of tuples: >>> tuple( lace( a, b, c)) A tuple of lists: >>> tuple( [for x in lace( a, b, c)]: list(x) ) A list of lists: >>> list( [for x in lace( a, b, c)]: list(x) ) A dictionary: >>> dict( lace( a, b, c )) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 08:13:52 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 01:13:52 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <396D5E20.69F228EC@prescod.net> I'm not clear on the role of opinions in this process. Do all of the opinions about a proposal go in the PEP: * "I hate this, here's why" * "I have a minor enhancement proposal" * "Here is my competing proposal" -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From fredrik at pythonware.com Thu Jul 13 09:09:57 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 09:09:57 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <013601bfec99$5a9af780$0900a8c0@SPIFF> barry wrote: > You can find the current set of documents under nondist/peps in the > CVS tree. Please take a look, especially at pep-0201.txt which is > nearest to being complete. can you perhaps post these somewhere on the python.org and/or pythonlabs.com sites? hiding them down in the CVS tree isn't optimal, especially when SF's CVS viewer doesn't work for roughly 86% of all web users... cheers /F From bwarsaw at beopen.com Thu Jul 13 09:11:07 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 03:11:07 -0400 (EDT) Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> Message-ID: <14701.27531.782443.22776@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Add an implementation of snprintf to our code and fix the PP> other hundred or so sprintf occurrences to use it. Most of PP> them are safe but it couldn't hurt to pass cleanly through PP> those heuristic security checkers PP> Here's one: PP> http://www.ijs.si/software/snprintf/ PP> And there is one in Apache. And one in Mailman, ripped from GNU screen. Because it's GPL'd it's not appropriate for Python, but could serve as another source of inspiration. So far, of the platforms people try to run Mailman on, I've only found it necessary for Solaris 2.5. -Barry From tim_one at email.msn.com Thu Jul 13 10:28:34 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 13 Jul 2000 04:28:34 -0400 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <013601bfec99$5a9af780$0900a8c0@SPIFF> Message-ID: [Barry] > You can find the current set of documents under nondist/peps in the > CVS tree. Please take a look, especially at pep-0201.txt which is > nearest to being complete. [/F] > can you perhaps post these somewhere on the python.org > and/or pythonlabs.com sites? In time, yes. For now we're just trying to get it started. Note that we can't currently change anything on python.org, and I'm not sure we're yet able to get at pythonlabs.com most days either <0.9 wink>. > hiding them down in the CVS tree isn't optimal, especially > when SF's CVS viewer doesn't work for roughly 86% of all > web users... Plus me ! Barry didn't say so, but he could have: the things for which he created PEPs are, as far as Guido is concerned, all going to be in the 2.0 release (yup! augmented assignments and list comprehensions and ... that other thing ). So we have a crucial need to make sense out of their respective Python-Dev messes *now* (as the "list comprehension guy", who was out of the loop yesterday for moving, out most of today for a mtg, and will be out tomorrow again for personal reasons, I despair of ever making coherent sense out of the 100+ msgs I haven't got to on the topic yet, inexplicably splintered along multiple Subject lines). So, like with the move to the SF patch manager, we're just moving to *something* we aren't yet certain is totally broken. It will work if all of us do . btw-the-truly-*new*-content-in-all-these-msgs-could-probably-fit-in-a- paragraph-ly y'rs - python's collective memory for lack of a pep From ping at lfw.org Thu Jul 13 09:35:29 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 00:35:29 -0700 (PDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: <396D3F54.39DD165F@prescod.net> Message-ID: On Wed, 12 Jul 2000, Paul Prescod wrote: > > Isn't it somewhat of a political statement to allow marriages of three > or more items? I always presumed that this function was n-ary, like map. I *knew* someone was going to make a comment like this. ...which is why it was so much fun to propose it. :) -- ?!ng From moshez at math.huji.ac.il Thu Jul 13 09:36:09 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 13 Jul 2000 10:36:09 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: On Thu, 13 Jul 2000, Barry A. Warsaw wrote: > You can find the current set of documents under nondist/peps in the > CVS tree. Please take a look, especially at pep-0201.txt which is > nearest to being complete. Personally, I'm +1 on pop-0201 as it stands. Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] Otherwise user-code will probably have to special case more often. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From ping at lfw.org Thu Jul 13 09:48:54 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 00:48:54 -0700 (PDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: On Thu, 13 Jul 2000, Barry A. Warsaw wrote: > > These things are called PEPs or Python Enhancement Proposals. Excellent. I think having these things documented in a persistent way is a fabulous idea. > PEP 201 discusses the parallel iteration feature. I currently own > this one, and have fleshed this out completely based on my > understanding of the issues as of 2:45am 13-Jul-2000. Use this as an > example of the PEP format until PEP 1 is completed. Great. Thanks for doing all this work! May i suggest small edits? pep-0201.txt says: | exhausted. The for-loop can also be explicitly exited with a | `break' statement, and for-loops can have else: clauses, but these | is has no bearing on this PEP. These is has no sensible sentence, either. :) Barry is has no sleep lately too? | should raise an IndexError when the sequence is exhausted. This | protocol is current undocumented -- a defect in Python's | documentation hopefully soon corrected. "current undocumented" -> "currently undocumented" | For loops are described in the language reference manual here | http://www.python.org/doc/devel/ref/for.html | | An example for-loop Colons after "here" and "for-loop". | class _Marriage: | def __init__(self, args, kws): Shouldn't that be "_Mawwage"? I apologize... i'm having way too much fun at your expense. -- ?!ng From moshez at math.huji.ac.il Thu Jul 13 09:46:31 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 13 Jul 2000 10:46:31 +0300 (IDT) Subject: [Python-Dev] Ranges In-Reply-To: Message-ID: On Wed, 12 Jul 2000, Ka-Ping Yee wrote: > I believe the two possibilities were > > __getitem__ gets either an index or a special slice object > __getslice__ is deprecated (when missing, __getitem__ gets the slice args) > > and > > __getitem__ always gets an index > __getslice__ gets three arguments, all optional, defaulting to None > > The latter isn't backward-compatible, but it makes a heckuva lot > more sense. Right. I'd be +1 on the latter if we didn't have to be backwards compatible. OTOH: How many people do you know who deal with slices in __getitem__, besides the numpy people? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From ping at lfw.org Thu Jul 13 09:52:17 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 00:52:17 -0700 (PDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: Message-ID: On Thu, 13 Jul 2000, Moshe Zadka wrote: > > Personally, I'm +1 on pop-0201 as it stands. Sure, looks great. Me too. > Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] > Otherwise user-code will probably have to special case more often. Yes, i agree with this stance on the issue. -- ?!ng From moshez at math.huji.ac.il Thu Jul 13 09:56:16 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 13 Jul 2000 10:56:16 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007121318.IAA14063@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 12 Jul 2000, Guido van Rossum wrote: > Greg subtly points out the difficulty with your proposal: this > requires an external library that may not be available. In the past > we've had enough complaints from people who failed to realize that if > the build failed because of a missing external library, they could > just disable the module that needs it. So I'm not for simply having > it enabled in Setup.in by default. Currently there are two external libraries one needs to build a "good" Python interpreter: zlib, and expat. Well, now that Python releases from BeOpen, and not CNRI, perhaps it will be deemed all right to put them in the source distribution, and by default have a Setup.in that builds on them? Perhaps even include a "last known good" Tcl/Tk? Rational: There are several kinds of people who build Python interpreters. Let me divide them into two groups, jokingly called "users" and "pushers". "Users" build Python interpreter for self consumption (or for consumption of a relatively small group of people). They sometimes don't know C, have a flaky internet connection, and do not have too much time. For them, Python should build out of the box. "Pushers", or packagers, are people who build a python interpreter on a platform and distribute it. Examples include BeOpen for the Windows installer, the nice folks at Red Hat for rpms, and some Debian packager for debs. These people usually configure the Python interpreter, and decided what needs to be built, so it's all right to let them edit Setup. addicted-to-python-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From ping at lfw.org Thu Jul 13 10:21:41 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 01:21:41 -0700 (PDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: Message-ID: On Thu, 13 Jul 2000, Ka-Ping Yee wrote: > > Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] > > Otherwise user-code will probably have to special case more often. > > Yes, i agree with this stance on the issue. Oh -- alternatively: >>> marry([0, 1, 2]) TypeError: marry() requires at least two arguments Notice, by the way, that marry() neither limits its arguments to only two, nor does it place any restrictions on the gender of its arguments. Indeed, this has truly far-reaching implications, as PEP 201 would then make Python the first programming language in the history of computing to directly acknowledge freedom of sexual orientation in its standard library. The excellent PR alone would clearly make this one a winner. -- ?!ng From gstein at lyra.org Thu Jul 13 10:54:25 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 01:54:25 -0700 Subject: [Python-Dev] strncpy In-Reply-To: <396D5CA2.DBBBDC2C@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 01:07:30AM -0500 References: <396D5CA2.DBBBDC2C@prescod.net> Message-ID: <20000713015424.X29590@lyra.org> On Thu, Jul 13, 2000 at 01:07:30AM -0500, Paul Prescod wrote: >... > > Easy but tedious to > > fix (e.g., #define the buf length, and use runtime code in > > conjunction with strncpy to guarantee buf's bounds are respected). > > Let me suggest two non-tedious solutions so you can shoot them down: > > 1. > > sprintf(buf, "Local variable referenced " > "before assignment: %.128s", > namestr); > > Rationale: if you don't know what variable I'm talking about after 128 > characters, you've got bigger problems than I can help with. I see this > solution elsewhere in the code. > > 2. > > Add an implementation of snprintf to our code and fix the other hundred > or so sprintf occurrences to use it. Most of them are safe but it > couldn't hurt to pass cleanly through those heuristic security checkers > > Here's one: > > http://www.ijs.si/software/snprintf/ > > And there is one in Apache. Actually, I looked into this a few months ago. There isn't a need to bulk up Python with a complete snprintf() solution. We really only use a couple format codes for generating error strings. Please see my note at: http://www.python.org/pipermail/python-dev/2000-April/010051.html Cheers, -g -- Greg Stein, http://www.lyra.org/ From moshez at math.huji.ac.il Thu Jul 13 10:52:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 13 Jul 2000 11:52:06 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: Message-ID: On Thu, 13 Jul 2000, Ka-Ping Yee wrote: [about what marry() should do with one argument] > Oh -- alternatively: > > >>> marry([0, 1, 2]) > TypeError: marry() requires at least two arguments Ummmmm......this seems a bit of an arbitrary restriction.... (Though I suppose this could be argued for from "the face of ambiguity refuse to guess") -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul at prescod.net Thu Jul 13 09:50:13 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 02:50:13 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: Message-ID: <396D74B5.5110A26D@prescod.net> Ka-Ping Yee wrote: > > ... > > Indeed, this has truly far-reaching implications, as PEP 201 would > then make Python the first programming language in the history of > computing to directly acknowledge freedom of sexual orientation in > its standard library. If Larry Wall can blatantly court the Christian vote, and Javasoft can go after the Asians, we'll have to build some coalitions of our own! Seriously though: I have some concern with implying that it works for only two lists. Our users may still be stuck in that 20th century point of view that, when stretched, might accept two lists of the same type but never three. Compare marry to "zip". The first time you see "zip", you figure out that it has nothing to do with zipping files, just by looking at the usage. But you could see, and use, "marry" over and over and over again and never realize that it works for three+ lists. How big of a problem is this? You decide. funny-how-whimsical-names-are--so-annoying-in-Perl -ly 'yrs -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 09:53:07 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 02:53:07 -0500 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> Message-ID: <396D7563.9DB73E1E@prescod.net> Greg Stein wrote: > > Actually, I looked into this a few months ago. >... Oh yeah? Where is the Python Enhancment Proposal? If we don't care about floating point, I think that there are about a dozen snprintf's we could steal (legally) around the Web. The author of the one I found says: > In retrospect, it appears that a lot of effort was wasted by > many people for not being aware of what others are doing. Sigh. Greg proposes: > %.###s -- switch to %s Isn't %.###s useful? If some yahoo gives us a 200 character variable name, is it really useful to quote it all back? For NameErrors and UnboundLocalErrors in ceval, I'm just going to use PyString_Format. If that's not solid, we're in big trouble. Okay, it isn't so fast but we're talking about relatively rare exceptions -- not IndexError or AttributeError. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gstein at lyra.org Thu Jul 13 11:31:59 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 02:31:59 -0700 Subject: [Python-Dev] strncpy In-Reply-To: <396D7563.9DB73E1E@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 02:53:07AM -0500 References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> Message-ID: <20000713023159.B29590@lyra.org> On Thu, Jul 13, 2000 at 02:53:07AM -0500, Paul Prescod wrote: > Greg Stein wrote: > > > > Actually, I looked into this a few months ago. >... > If we don't care about floating point, I think that there are about a > dozen snprintf's we could steal (legally) around the Web. The author of > the one I found says: We don't care about anything except for %d, %s, possibly %c and %x. > > In retrospect, it appears that a lot of effort was wasted by > > many people for not being aware of what others are doing. Sigh. IMO, there is a complexity tradeoff. A short formatter for a few codes, or pick up a complete implementation? And we *do* have some specific requirements. We need to format into a PyStringObject rather than a user-provided buffer/len like snprintf() does. > Greg proposes: > > %.###s -- switch to %s > > Isn't %.###s useful? If some yahoo gives us a 200 character variable > name, is it really useful to quote it all back? They did it, we can send it back. No biggy. The *reason* the %.###s is in there is to prevent buffer overruns. It isn't there for "nice output / truncation." Logically, it doesn't need to be there. > For NameErrors and UnboundLocalErrors in ceval, I'm just going to use > PyString_Format. If that's not solid, we're in big trouble. Okay, it > isn't so fast but we're talking about relatively rare exceptions -- not > IndexError or AttributeError. PyString_Format() requires Python objects for arguments. That is a completely different beast from PyErr_Format() (or the PyErr_SafeFormat that I described in that email). If you're going to create a PyStringObject for the format and one for the argument, then pass it to PyString_Format, then toast those temporaries... then you're going about it wrong. :-) A simple, *safe* string formatter for C types is needed within the core. Cheers, -g -- Greg Stein, http://www.lyra.org/ From jack at oratrix.nl Thu Jul 13 11:52:36 2000 From: jack at oratrix.nl (Jack Jansen) Date: Thu, 13 Jul 2000 11:52:36 +0200 Subject: permuting several lists (was Re: [Python-Dev] zip() and list-comprehension with commas) In-Reply-To: Message by Guido van Rossum , Wed, 12 Jul 2000 21:41:06 -0500 , <200007130241.VAA01765@cj20424-a.reston1.va.home.com> Message-ID: <20000713095237.5570E37186D@snelboot.oratrix.nl> > twine > entwine > intertwine > interweave > interlace > interspeerse intertwine() and interlace() both give me the right feeling. Although with interlace I might be tempted to pass it two 320x480 bitmaps and assume an NTSC image will come out:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paul at prescod.net Thu Jul 13 10:01:24 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 03:01:24 -0500 Subject: [Python-Dev] Exceptions References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> Message-ID: <396D7754.96D6CCE7@prescod.net> Greg Stein wrote: > > If you're going to create a PyStringObject for the format and one for the > argument, then pass it to PyString_Format, then toast those temporaries... > then you're going about it wrong. :-) You're right. It's too late... Anyhow, this whole process seems wrong. Shouldn't the exceptions know what their appropriate error messages are and take the arguments for their format strings as arguments? There shouldn't be duplicated error messages spread throughout the code. It's brutal for consistency. You probably discussed this six months ago also. Anyhow, I think that that's the answer to Fredrik's (implicit) question about how decide when to make new exceptions. If it requires a new docstring or message string/format then it should be a new exception. We had relatively few exceptions before because they were just strings. Now that they are objects we should expect them to proliferate as they tend to in other languages where objects are exceptions. We should start tightening up the parameters we expect them to take for their constructors too. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From ping at lfw.org Thu Jul 13 12:19:59 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 03:19:59 -0700 (PDT) Subject: [Python-Dev] listcomp / par-for (summary) In-Reply-To: <20000712161328.I7340@xs4all.nl> Message-ID: On Wed, 12 Jul 2000, Thomas Wouters wrote: > As said, the currently implemented list-comprehension syntax was too > unclear, especially when nesting the 'for's and 'if's too deeply. One of the > proposals was to enforce the use of ()'s and add commas to make the 'for's > and 'if's more readable: > > [(x,y) for x in a, y in b, if y > 3] > > That is not going to work. Actually, it will (read on). > Enforcing the parentheses is possible, but only > if you *always* enforce them, even if they don't create a tuple: > > [([x,y]) for x in a] They don't always have to be enforced (read on). > Secondly, the use of commas to seperate the for and if statements is not > possible. The parser will see the commas as part of the iter-list of the > previous for statement. No, this really can be done. I was kinda suspicious when i read the above statements, so i proceeded to hack the grammar to see if i could implement the syntax i proposed. It is possible, and it turns out it's quite easy and straightforward. (No personal attack intended, Thomas -- sorry -- just wanted to show that it *is* possible.) All of the following syntaxes are possible (i've tried and tested a Python capable of each one): 1. [ <...> ] 2. [ , , , <...> ] 3. [ ; , , <...> ] 4. [ ; ; ; <...> ] For example, using a Python with "comma-comma" syntax (number 2), i get: >>> a = range(5) >>> b = range(10, 50, 10) >>> a [0, 1, 2, 3, 4] >>> b [10, 20, 30, 40] >>> [x*2, for x in a] [0, 2, 4, 6, 8] >>> [x, y, for x in a, for y in b, if y > 3] File "", line 1 [x, y, for x in a, for y in b, if y > 3] ^ SyntaxError: invalid syntax >>> [(x, y), for x in a, for y in b, if y > 3] [(0, 10), (0, 20), (0, 30), (0, 40), (1, 10), (1, 20), (1, 30), (1, 40), (2, 10), (2, 20), (2, 30), (2, 40), (3, 10), (3, 20), (3, 30), (3, 40), (4, 10), (4, 20), (4, 30), (4, 40)] >>> [[x, y], for x in a] [[0, 40], [1, 40], [2, 40], [3, 40], [4, 40]] >>> [([x, y]), for x in a] [[0, 40], [1, 40], [2, 40], [3, 40], [4, 40]] >>> [([x, y],), for x in a] [([0, 40],), ([1, 40],), ([2, 40],), ([3, 40],), ([4, 40],)] >>> def marry(*args): return apply(map, (None,)+args)[:min(map(len, args))] ... >>> [x + y, for x in a, for y in b] [10, 20, 30, 40, 11, 21, 31, 41, 12, 22, 32, 42, 13, 23, 33, 43, 14, 24, 34, 44] >>> [x + y, for x, y in marry(a, b)] [10, 21, 32, 43] >>> The above shows that we can indeed enforce parentheses around the initial test, while not requiring extra parentheses when no tuple is being constructed. Similarly, as you would expect, using a comma between clauses requires you to add parens if the expression after "in" contains bare commas. Otherwise everything works normally. I also tested stuff like [] [1] [1,] [1,,] [1,2] [1,2,] [1,2,,] and the modified Pythons behaved fine. The grammar rules for comma-comma syntax are: atom: '(' [testlist] ')' | '[' [test [',' (testlist | list_iter)]] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ list_iter: (list_for | list_if) list_for: 'for' exprlist 'in' test [',' list_iter] list_if: 'if' test [',' list_iter] Or for semicolon-comma syntax (number 3 above): atom: '(' [testlist] ')' | '[' [testlist [';' list_iter]] ']' | '{' [dictmaker] '}' | '`' testlist '`' | NAME | NUMBER | STRING+ list_iter: (list_for | list_if) list_for: 'for' exprlist 'in' test [',' list_iter] list_if: 'if' test [',' list_iter] I won't post the changes to Python/compile.c for each case here, but they were pretty minor changes from Greg Ewing's original patch. Comma-comma syntax is my current favourite, with semicolon-comma a close second (but definitely second). -- ?!ng From mal at lemburg.com Thu Jul 13 12:16:56 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 12:16:56 +0200 Subject: [Python-Dev] Re: New builtins References: Message-ID: <396D9717.25E82B0B@lemburg.com> Ka-Ping Yee wrote: > > tuples(), lists(), dict(), and indices() look pretty generally useful > to me. I agree that they look like good candidates for builtins. > > On Wed, 12 Jul 2000, M.-A. Lemburg wrote: > > irange(object[,indices]) > > Builds a tuple of tuples (index, object[index]). If a sequence > > indices is given, the indices are read from it. If not, then > > the index sequence defaults to trange(len(object)). > > This one in particular looks really fabulous. +1 to put this in builtins. > > In order of usefulness (just imho of course): > > irange +1 > tuples +0.5 > indices +0.5 > dict +0 > lists +0 If you want these in the standard dist, just go ahead and steal them from mx.Tools -- I don't have time to look into this right now (and of course I already have them as builtins ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 13 12:30:19 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 12:30:19 +0200 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <396D5D2E.4844F7FF@prescod.net> Message-ID: <396D9A3B.B6985C97@lemburg.com> Paul Prescod wrote: > > Paul Prescod wrote: > > > > Re: Patch #100874 > > Also, the LOAD_FAST and DELETE_FAST cases are identical when an > exception is thrown. Should I make a small function as I would usually > do or is that "bad style" in ceval. Moving code out of the switch > probably helps keep commonly used code local and uncommon code > "unlocal". Before going down this road you should do some serious performance testing. ceval is *very* touchy about the order of the opcodes and adding indirection doesn't necessarily help (the compiler inlines the code again ;-). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 13 12:37:21 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 12:37:21 +0200 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <14701.27531.782443.22776@anthem.concentric.net> Message-ID: <396D9BE1.843BA74@lemburg.com> "Barry A. Warsaw" wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> Add an implementation of snprintf to our code and fix the > PP> other hundred or so sprintf occurrences to use it. Most of > PP> them are safe but it couldn't hurt to pass cleanly through > PP> those heuristic security checkers > > PP> Here's one: > > PP> http://www.ijs.si/software/snprintf/ > > PP> And there is one in Apache. > > And one in Mailman, ripped from GNU screen. Because it's GPL'd it's > not appropriate for Python, but could serve as another source of > inspiration. So far, of the platforms people try to run Mailman on, > I've only found it necessary for Solaris 2.5. Isn't there one in FreeBSD which we could use (Python's license being very BSDish, this should be possible, I guess). Anyway, I think most platforms have their own snprintf() in the C lib, so the code would hardly ever be needed -- perhaps its even safe to revert to sprintf() on those platforms via a macro snprintf(). The reasoning here is simple: if the platform doesn't provide it, it's quite possibly unsafe in a network environment anyway, because many programs will use sprintf() instead of snprintf() and thus won't do much buffer overflow checking. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping at lfw.org Thu Jul 13 12:41:45 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 13 Jul 2000 03:41:45 -0700 (PDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: <20000713095237.5570E37186D@snelboot.oratrix.nl> Message-ID: On Thu, 13 Jul 2000, Jack Jansen wrote: > > intertwine() and interlace() both give me the right feeling. Although with > interlace I might be tempted to pass it two 320x480 bitmaps and assume an NTSC > image will come out:-) Sorry for flip-flopping on this -- to Paul especially -- but parallel() is looking better and better as i compare it with these other alternatives. It seems clear that the most common use of this thing is in a parallel-iteration idiom, and that it would be quite rarely used as part of an expression elsewhere. Given that, consider: for x, y, z in marry(a, b, c): print x + y + z for x, y, z in twine(a, b, c): print x + y + z for x, y, z in lace(a, b, c): print x + y + z for x, y, z in zip(a, b, c): print x + y + z for x, y, z in parallel(a, b, c): print x + y + z Which one makes its behaviour most obvious to you? For me, parallel() really stands out. It's so strong that it could outweigh the potential connotation of concurrency. (In fact, it *is* sort of concurrent. If each list were a generator, they would all be running concurrently to produce the triplets we're requesting.) (If "parallel" disturbs you too much, the concept of parallel *movement* inspires me to suggest "march", which has all of that good walking-together-in-lock-step feeling, with none of the twisty feeling i get from "twine" or "lace" or the alternating-back-and-forth feeling i get from "weave" or "interlace".) -- ?!ng From paul at prescod.net Thu Jul 13 10:08:08 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 03:08:08 -0500 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <396D5D2E.4844F7FF@prescod.net> <396D9A3B.B6985C97@lemburg.com> Message-ID: <396D78E8.70926D96@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Before going down this road you should do some serious > performance testing. ceval is *very* touchy about the order > of the opcodes and adding indirection doesn't necessarily > help (the compiler inlines the code again ;-). I'm not changing the order of the opcodes, just error handling. Anyhow, would performance results on my single computer be meaningful? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 10:09:11 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 03:09:11 -0500 Subject: [Python-Dev] Iterating in parallel References: Message-ID: <396D7927.EC241464@prescod.net> Ka-Ping Yee wrote: > > ... > > (If "parallel" disturbs you too much, the concept of parallel > *movement* inspires me to suggest "march", which has all of that > good walking-together-in-lock-step feeling, with none of the > twisty feeling i get from "twine" or "lace" or the > alternating-back-and-forth feeling i get from "weave" or "interlace".) If only as much thought had gone into choosing the name for "lambda"....or was that an earlier gay-pride statement? (yes, I know where it comes from) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 13:10:15 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 13:10:15 +0200 (CEST) Subject: [Python-Dev] Re: Iterating in parallel In-Reply-To: <20000713000929.B3212@thyrsus.com> from "Eric S. Raymond" at Jul 13, 2000 12:09:29 AM Message-ID: <200007131110.NAA12470@python.inrialpes.fr> Eric S. Raymond wrote: > > [Ping] > > Hm. None really beat "zip" for me in terms of the visualization > > (except perhaps "marry"). > > `knit' would work for me. I was thinking also about cross(), xcross() stop-that-noise-about-Marry-'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 13:40:33 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 13:40:33 +0200 (CEST) Subject: [Python-Dev] Iterating in parallel In-Reply-To: from "Ka-Ping Yee" at Jul 13, 2000 03:41:45 AM Message-ID: <200007131140.NAA12523@python.inrialpes.fr> Ka-Ping Yee wrote: > > ... Given that, consider: > > for x, y, z in marry(a, b, c): print x + y + z > > for x, y, z in twine(a, b, c): print x + y + z > > for x, y, z in lace(a, b, c): print x + y + z > > for x, y, z in zip(a, b, c): print x + y + z > > for x, y, z in parallel(a, b, c): print x + y + z > > Which one makes its behaviour most obvious to you? None. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From esr at thyrsus.com Thu Jul 13 14:01:13 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 08:01:13 -0400 Subject: [Python-Dev] Re: Iterating in parallel In-Reply-To: <200007131110.NAA12470@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Thu, Jul 13, 2000 at 01:10:15PM +0200 References: <20000713000929.B3212@thyrsus.com> <200007131110.NAA12470@python.inrialpes.fr> Message-ID: <20000713080113.A4157@thyrsus.com> Vladimir Marangozov : > > > Hm. None really beat "zip" for me in terms of the visualization > > > (except perhaps "marry"). > > > > `knit' would work for me. > > I was thinking also about cross(), xcross() Now that really sounds like a Cartesian-product operator. -- Eric S. Raymond The abortion rights and gun control debates are twin aspects of a deeper question --- does an individual ever have the right to make decisions that are literally life-or-death? And if not the individual, who does? From gvwilson at nevex.com Thu Jul 13 14:07:29 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Thu, 13 Jul 2000 08:07:29 -0400 (EDT) Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: Message-ID: > > I don't think that using a function called "xmap" to build tuples is > > very intuitive to start with. What's so wrong with a builtin called > > "tuples()"? 1. Trailing single-character difference between "tuple()" and "tuples()". (We'd take marks off students for naming things this way, wouldn't we?) 2. Need separate functions for creating tuples, lists, dicts, etc. I liked Ken M.'s idea of one function that took a type argument, and stitched/married/wove/welded/whatever'd its arguments to create something of that type, as it would require only one new function. Greg From gvwilson at nevex.com Thu Jul 13 14:13:41 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Thu, 13 Jul 2000 08:13:41 -0400 (EDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: Message-ID: > Ka-Ping Yee wrote: > Sorry for flip-flopping on this -- to Paul especially -- but > parallel() is looking better and better as i compare it with these > other alternatives. Strong -1 on parallel() unless it really performs concurrent execution. I'd take any of the other suggestions (except "zip()") over this. Greg From m.favas at per.dem.csiro.au Thu Jul 13 14:28:24 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Thu, 13 Jul 2000 20:28:24 +0800 Subject: [Python-Dev] re: list comprehension / pop quiz Message-ID: <396DB5E8.6F12ACA4@per.dem.csiro.au> Greg Wilson wrote: 2. Need separate functions for creating tuples, lists, dicts, etc. I liked Ken M.'s idea of one function that took a type argument, and stitched/married/wove/welded/whatever'd its arguments to create something of that type, as it would require only one new function. I'd like to endorse Ken's idea very strongly - and suggest the name "plait" (which can clearly operate on 2, 3, 4, or more strands - and can produce beautiful effects... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From esr at thyrsus.com Thu Jul 13 15:15:46 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 09:15:46 -0400 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <396DB5E8.6F12ACA4@per.dem.csiro.au>; from m.favas@per.dem.csiro.au on Thu, Jul 13, 2000 at 08:28:24PM +0800 References: <396DB5E8.6F12ACA4@per.dem.csiro.au> Message-ID: <20000713091546.A5094@thyrsus.com> Mark Favas : > I'd like to endorse Ken's idea very strongly - and suggest the name > "plait" (which can clearly operate on 2, 3, 4, or more strands - and can > produce beautiful effects... plait() is *good*. -- Eric S. Raymond No one is bound to obey an unconstitutional law and no courts are bound to enforce it. -- 16 Am. Jur. Sec. 177 late 2d, Sec 256 From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 15:16:04 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 15:16:04 +0200 (CEST) Subject: [Python-Dev] co_lnotab and SET_LINENO (fwd) Message-ID: <200007131316.PAA12706@python.inrialpes.fr> Maybe I should foward this to c.l.py as a CFP, detailing somewhat the issue and ask for contributions from people who are using the debugger? Guido? I won't do it if there's no a serious intent of including it, though. The contributions would require inspection, testing & possibly further improvements. I do volunteer for championing discussions and testing of this (relatively minor, but delicate) feature. > > Vladimir Marangozov wrote: > > > > Ka-Ping Yee wrote: > > > > > > Now that we have co_lnotab, why do we still generate > > > SET_LINENO opcodes? > > > > It has been discussed before. To summarize: > > > > - because these opcodes generate the callbacks from C to Python > > - the debugger relies on them > > - I haven't had the time to look seriously at the debugger and > > make it work without them. (this relates with breakpoints setting > > which requires generating callbacks for every source line) > > > > And this is where we are. If you're volunteering to look into this, > > I'll spend some time summarizing the pointers about this thread + > > the existing code in the area. Otherwise, I won't bother > > OK, if someone wants to play with this, see: > > http://starship.python.net/~vlad/lineno/ for (working at the time) patches > > Discussions on python-dev: > > - http://www.python.org/pipermail/python-dev/2000-April/subject.html > Subject: "Why do we need Traceback Objects?" > - http://www.python.org/pipermail/python-dev/1999-August/002252.html > > I'd be happy to discuss the topic again, offline, with any volunteer(s) > willing to take over (and to look closely at the debugger issue -- > I don't use the debugger and I can't make the time for it). > -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 15:29:04 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 15:29:04 +0200 (CEST) Subject: [Python-Dev] more SyntaxError subclasses! In-Reply-To: <009a01bfec17$f7fe3be0$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 12, 2000 05:43:45 PM Message-ID: <200007131329.PAA12745@python.inrialpes.fr> Fredrik Lundh wrote: > > here are a bunch of other syntax error subclasses that > might be useful: Fredrik, I don't want to let this thread die, since I'm firmly +1 on your proposal and the recent patches about more detailed syntax errors are ... well, recent . That said, what's your next proposal about making more progress on this? :-) > > I'll post a more complete proposal later... > Ah, okay. I'll be waiting for it. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas at xs4all.net Thu Jul 13 15:26:27 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 15:26:27 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.26881.172217.870049@anthem.concentric.net>; from bwarsaw@beopen.com on Thu, Jul 13, 2000 at 03:00:17AM -0400 References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <20000713152627.T7340@xs4all.nl> On Thu, Jul 13, 2000 at 03:00:17AM -0400, Barry A. Warsaw wrote: > PEP 203 will cover augmented assignments. Thomas Wouters, we were > thinking about you owning this one. Fine by me, though if it's a ploy to try and make me less involved with the other issues, it's bound to fail! :-) I'll see if my girlfriend lets me flesh out a PEP tonight. Where should I send it, by the way ? SF PM ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw at beopen.com Thu Jul 13 15:34:27 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 09:34:27 -0400 (EDT) Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <14701.27531.782443.22776@anthem.concentric.net> <396D9BE1.843BA74@lemburg.com> Message-ID: <14701.50531.652359.831584@anthem.concentric.net> >>>>> "M" == M writes: M> Anyway, I think most platforms have their own snprintf() in the M> C lib, so the code would hardly ever be needed -- perhaps its M> even safe to revert to sprintf() on those platforms via a macro M> snprintf(). Perhaps, but i think you're right, most platforms should have their own snprintf() by now. For those that don't, why re-invent the wheel? Find one with an acceptable license and drop it in. -Barry From thomas at xs4all.net Thu Jul 13 15:34:34 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 15:34:34 +0200 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <20000713091546.A5094@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 13, 2000 at 09:15:46AM -0400 References: <396DB5E8.6F12ACA4@per.dem.csiro.au> <20000713091546.A5094@thyrsus.com> Message-ID: <20000713153434.U7340@xs4all.nl> On Thu, Jul 13, 2000 at 09:15:46AM -0400, Eric S. Raymond wrote: > Mark Favas : > > I'd like to endorse Ken's idea very strongly - and suggest the name > > "plait" (which can clearly operate on 2, 3, 4, or more strands - and can > > produce beautiful effects... > plait() is *good*. Hmm... 'plait'. I don't even know what that means. I've read it before, but don't know what it means... something like 'cloth' or 'plaid' ?. And it sounds like 'plate'. I seriously prefer 'marry()', because it's widely known what marriage is. Also, it is more descriptive of what it should do: it shouldn't produce [1,4,2,5,3,6], but [(1,4),(2,5),(3,6)], or it's useless for tuple-unpacking in for-loops. And to hell with religious objections<1.1 wink> Actually, I try to respect other people's religions, having none myself, but I seriously think religion has no place in language design. A UNIX machine has processes, and those processes have children. But those child-processes have only a single parent! Did anyone ever question that ? Marry() is descriptive, and a common term, and if people refuse to marry() more than two lists, that's their choice. It's perfect. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fredrik at pythonware.com Thu Jul 13 15:54:27 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 15:54:27 +0200 Subject: [Python-Dev] re: list comprehension / pop quiz References: Message-ID: <002b01bfecd1$dcf7ca90$0900a8c0@SPIFF> (hmm. doesn't python-dev look a whole lot like python-list these days? maybe this thread, and its cousins, could be moved over to comp.lang.python for a while?) greg wrote: > 2. Need separate functions for creating tuples, lists, dicts, etc. I > liked Ken M.'s idea of one function that took a type argument, and > stitched/married/wove/welded/whatever'd its arguments to create > something of that type, as it would require only one new function. fwiw, I think it's about as unpythonish as it can be... what other function takes an instance of an object to figure out what object factory to call? and why force people to make a decision (list or tuple) that shouldn't matter in 99.9% of all cases? and wasn't this supposed to return a generator, not a sequence object? and "zip" is a pretty good name... in most cases, it will be perfectly clear from the context that it's not being used to compress things (sure, "zip" is a command name that happens to do something that this "zip" function won't do -- but the same thing applies to "dir", "del", "copy", "type", just to name a few...) btw, doesn't numpy provide something like this? reshape? From Vladimir.Marangozov at inrialpes.fr Thu Jul 13 16:53:44 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 13 Jul 2000 16:53:44 +0200 (CEST) Subject: [Python-Dev] GC paper Message-ID: <200007131453.QAA12964@python.inrialpes.fr> FYI (Neil et al.) You may want to read an interesting paper from the ECOOP'95 proceedings, entitled: "Incremental Mature Garbage Collection Using the Train Algorithm" I've put it here: http://sirac.inrialpes.fr/~marangoz/tmp/09520235.pdf Combined with an object malloc of ours, the GC scheme may benefit from the idea(s). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw at beopen.com Thu Jul 13 16:51:17 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 10:51:17 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <396D5E20.69F228EC@prescod.net> Message-ID: <14701.55141.272357.604260@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> I'm not clear on the role of opinions in this process. Do all PP> of the opinions about a proposal go in the PEP: | * "I hate this, here's why" | * "I have a minor enhancement proposal" | * "Here is my competing proposal" In some sense yes, but it's the job of the owner/shepherd to follow the various threads, and include debate about the proposal as open issues. This would all lead to one of these conclusions: - we've reached consensus and now need just implement the proposal - we've reached an impasse and the BDFL will rule by decree - the proposal is hopeless flawed and the idea should be dropped - we need more information or research - we're defering the proposal to a future release -Barry From akuchlin at mems-exchange.org Thu Jul 13 16:59:49 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 13 Jul 2000 10:59:49 -0400 Subject: [Python-Dev] Adding poll() system call In-Reply-To: <14699.21683.305409.97490@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 11, 2000 at 01:09:07PM -0400 References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> <20000711121817.J27228@kronos.cnri.reston.va.us> <14699.21683.305409.97490@bitdiddle.concentric.net> Message-ID: <20000713105949.B14938@kronos.cnri.reston.va.us> On Tue, Jul 11, 2000 at 01:09:07PM -0400, Jeremy Hylton wrote: > AMK> Very interesting, and probably worth doing because all that > AMK> list parsing *is* a silly waste of CPU. But could poll still > AMK> live in the posixmodule, then, or be a module of its own? [1] > >The select module has exactly the same problem and could use the same >interface. They could both live in their own module. >I'm not sure what to call it. Possibilities include: > >- add it to the current select module >- new name, e.g. asyncio, fileevent >- call it _asyncore and expose it through the asyncore module I want to finish off the patch to add poll(), but don't know how to proceed. The decision to use Jeremy's more efficient API seems clear; my only question at this point is where to put it. I'd argue for adding it to the select module. Any strenuous objections? --amk From bwarsaw at beopen.com Thu Jul 13 17:07:01 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 11:07:01 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <14701.56085.908913.979451@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> Great. Thanks for doing all this work! Sure thing! KY> May i suggest small edits? No. ...oh wait. As editor my first response should always be an automatic `no' (isn't that right Jeremy?). But if you insist :) KY> These is has no sensible sentence, either. :) Barry is has no KY> sleep lately too? Point good making nawpli gatch sensible snooperscope. Rewritten for stop making sense lessly. Thanks! KY> "current undocumented" -> "currently undocumented" Fixed. KY> Colons after "here" and "for-loop". Fixed. | | class _Marriage: | | def __init__(self, args, kws): KY> Shouldn't that be "_Mawwage"? Be glad I didn't include the _Consummate class. KY> I apologize... i'm having way too much fun at your expense. It's a dirty job, but somebody needs to do it. And Gordon's been too quietly lately. -Barry From billtut at microsoft.com Thu Jul 13 17:08:10 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 13 Jul 2000 08:08:10 -0700 Subject: [Python-Dev] Unicode character name hashing Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CB@RED-MSG-50> I just had a rather unhappy epiphany this morning. F1, and f2 in ucnhash.c might not work on machines where sizeof(long) != 32 bits. When sizeof(long) != 32 bits, x will probably not overflow like it did on my IA-32 box thereby possibly giving the code fits. If some kind soul could test the ucnhash.c stuff running on the Cray Tim's always talking about, and an Alpha running Unix that'd be awesome. Thanks, Bill From jeremy at beopen.com Thu Jul 13 17:14:47 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 11:14:47 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.26881.172217.870049@anthem.concentric.net> References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <14701.56551.680037.481536@bitdiddle.concentric.net> At our meeting yesterday Tim suggested that each enhancement or language feature have two documents -- a specification and a rationale. It looks like Barry did not adopt that suggestion explicitly, but I think it's still a good approach for writing a single PEP. Each PEP should have a brief technical specification of the new feature. For a feature like augmented assignment, it would need to specify the syntax and semantics of each operation on each type and on the overloading mechanism for classes, e.g. is "a += b += c" valid syntactically and what does it mean. The PEP should also have a rationale that describes why the specification is the way it is. It should discuss alternatives that were considered and why there were not adopted. Other topics appropriate for the rationale might be motivation (why do we want this feature at all?) and comparison (what do other languages do?). The Scheme language has a similar mechanism called Scheme Requests for Implementation (SRFI), . It is not exactly the same, because Scheme seems to have no end of proposals that include specification and rationale; they just can't agree on a standard set <0.2 wink>. We might adopt some of their processes for the PEPs. Two things that each SRFI that PEPs don't yet have are: - a mail archive attached to the PEP that contains relevant discussion. A mail archive seems valuable for people interested in the next level of detail, but I'm not sure what mechanism to use to create one. (It also seems valuable because the old "search dejanews" certainly isn't stable in the long-term.) Maybe PEP authors could maintain their own archives. - a copyright notice. As a strawman, I propose that the owner/author of each PEP retains copyright, but must publish it under the OpenContent license, . Jeremy From bwarsaw at beopen.com Thu Jul 13 17:24:38 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 11:24:38 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <20000713152627.T7340@xs4all.nl> Message-ID: <14701.57142.361876.857890@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: >> PEP 203 will cover augmented assignments. Thomas Wouters, we >> were thinking about you owning this one. TW> Fine by me, though if it's a ploy to try and make me less TW> involved with the other issues, it's bound to fail! :-) Not at all! Tim practically bum rushed me to gain control of PEP202, and Jeremy all but begged for PEP200. I figured PEP201 was the one that I understood the best (not saying much :) and I needed one to flesh out as an example. BTW, PEP204 is up for grabs too. It's titled "Range Literals". TW> Where should I send it, by the way ? SF PM ? Well, you've got checkin privs so I'd say just write it and check it in. If people without checkin privs want to submit new PEPs, feel free to send them directly to me. Changes to existing PEPs should be sent to the owner, who can either make the changes themselves or send me context diffs. TW> I'll see if my girlfriend lets me flesh out a PEP TW> tonight. witty-but-crud-remark-omitted...-ba-dum-dum-ly y'rs, -Barry From jeremy at beopen.com Thu Jul 13 17:29:20 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 11:29:20 -0400 (EDT) Subject: [Python-Dev] simple syntax error bombs interpreter In-Reply-To: <200007121929.VAA09996@python.inrialpes.fr> References: <009101bfec16$35495fe0$f2a6b5d4@hagrid> <200007121929.VAA09996@python.inrialpes.fr> Message-ID: <14701.57424.510413.580401@bitdiddle.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> Fredrik Lundh wrote: >> using my latest Python 2.0 build, the interpreter bombs if I >> type the following two commands: >> >> >>> def a(b): ... global b ... >> >> (1.5.2 says "name is local and global"). >> >> >> VM> Yes. This is because PyErr_PrintEx() is invoked with a NULL VM> exception. And the exception has been cleared cleared in VM> get_inprogress_dict(). VM> The appended patch should fix it. Let me know whether it works VM> for you. VM> Jeremy, what's the point of calling PyErr_Clear() in VM> get_inprogress_dict()? Looks like it was just a bug. Jeremy From guido at beopen.com Thu Jul 13 18:28:54 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 13 Jul 2000 11:28:54 -0500 Subject: [Python-Dev] Adding poll() system call In-Reply-To: Your message of "Thu, 13 Jul 2000 10:59:49 -0400." <20000713105949.B14938@kronos.cnri.reston.va.us> References: <20000706171159.A25398@kronos.cnri.reston.va.us> <20000711095443.D27228@kronos.cnri.reston.va.us> <200007111609.LAA05816@cj20424-a.reston1.va.home.com> <20000711112847.G27228@kronos.cnri.reston.va.us> <14699.17061.139324.335138@bitdiddle.concentric.net> <20000711121817.J27228@kronos.cnri.reston.va.us> <14699.21683.305409.97490@bitdiddle.concentric.net> <20000713105949.B14938@kronos.cnri.reston.va.us> Message-ID: <200007131628.LAA09799@cj20424-a.reston1.va.home.com> > I want to finish off the patch to add poll(), but don't know how to > proceed. The decision to use Jeremy's more efficient API seems clear; > my only question at this point is where to put it. I'd argue for > adding it to the select module. Any strenuous objections? +1 --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Thu Jul 13 16:08:52 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 13 Jul 2000 09:08:52 -0500 (CDT) Subject: [Python-Dev] List comprehensions In-Reply-To: <396D44E7.F87983AB@prescod.net> References: <396D44E7.F87983AB@prescod.net> Message-ID: <14701.52596.651140.884121@beluga.mojam.com> >>>>> "Paul" == Paul Prescod writes: Paul> I want to summarize my feelings on the list-comp syntax Paul> issue. There is no syntax for list comprehensions that will Paul> inherently scream "cartesian product, not parallel". The only way Paul> to do it is by analogy to what they already know: Python. Paul> [for x: if y(x): for z: (x,y,z)] Agreed, however, your use of colons connotes the following to me l = [] for x in something: if y(x): for z in something_else: l.append((x,y,z)) return l Skip From skip at mojam.com Thu Jul 13 16:22:32 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 13 Jul 2000 09:22:32 -0500 (CDT) Subject: [Python-Dev] Iterating in parallel In-Reply-To: References: <20000713095237.5570E37186D@snelboot.oratrix.nl> Message-ID: <14701.53416.577920.628245@beluga.mojam.com> Ping> It seems clear that the most common use of this thing is in a Ping> parallel-iteration idiom, and that it would be quite rarely used Ping> as part of an expression elsewhere. Given that, consider: Ping> for x, y, z in marry(a, b, c): print x + y + z Ping> for x, y, z in twine(a, b, c): print x + y + z Ping> for x, y, z in lace(a, b, c): print x + y + z Ping> for x, y, z in zip(a, b, c): print x + y + z Ping> for x, y, z in parallel(a, b, c): print x + y + z Ping> Which one makes its behaviour most obvious to you? for x, y, z in stitch(a, b, c): print x + y + z ;-) -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From bwarsaw at beopen.com Thu Jul 13 17:53:38 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 11:53:38 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: <14701.58882.943772.897826@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> At our meeting yesterday Tim suggested that each enhancement JH> or language feature have two documents -- a specification and JH> a rationale. It looks like Barry did not adopt that JH> suggestion explicitly, but I think it's still a good approach JH> for writing a single PEP. Agreed. I think a single document can contain both spec and rationale. JH> Each PEP should have a brief technical specification of the JH> new feature. For a feature like augmented assignment, it JH> would need to specify the syntax and semantics of each JH> operation on each type and on the overloading mechanism for JH> classes, e.g. is "a += b += c" valid syntactically and what JH> does it mean. Yes. JH> The PEP should also have a rationale that describes why the JH> specification is the way it is. It should discuss JH> alternatives that were considered and why there were not JH> adopted. Other topics appropriate for the rationale might be JH> motivation (why do we want this feature at all?) and JH> comparison (what do other languages do?). Yes. JH> The Scheme language has a similar mechanism called Scheme JH> Requests for Implementation (SRFI), JH> . It is not exactly the same, JH> because Scheme seems to have no end of proposals that include JH> specification and rationale; they just can't agree on a JH> standard set <0.2 wink>. We might adopt some of their JH> processes for the PEPs. Great pointer, thanks. Would you like to co-own PEP001 and help me flesh out the guidelines? There are lots of good ideas in the SRFI's, but we should tailor them toward the Python community. JH> Two things that each SRFI that PEPs don't yet have are: JH> - a mail archive attached to the PEP that contains relevant JH> discussion. A mail archive seems valuable for people JH> interested in the next level of detail, but I'm not sure what JH> mechanism to use to create one. (It also seems valuable JH> because the old "search dejanews" certainly isn't stable in JH> the long-term.) Maybe PEP authors could maintain their own JH> archives. One thing mentioned in teh SRFI's is that each gets its own mailing list. That might not be a bad idea. I definitely had the notion that a PEP would contain URLs to other information (a References section). JH> - a copyright notice. As a strawman, I propose that the JH> owner/author JH> of each PEP retains copyright, but must publish it under the JH> OpenContent license, . Looks good to me. -Barry From thomas at xs4all.net Thu Jul 13 17:55:03 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 17:55:03 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.56551.680037.481536@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 11:14:47AM -0400 References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: <20000713175503.V7340@xs4all.nl> On Thu, Jul 13, 2000 at 11:14:47AM -0400, Jeremy Hylton wrote: > - a mail archive attached to the PEP that contains relevant > discussion. A mail archive seems valuable for people interested in > the next level of detail, but I'm not sure what mechanism to use to > create one. (It also seems valuable because the old "search > dejanews" certainly isn't stable in the long-term.) Maybe PEP > authors could maintain their own archives. Oh, good idea ! It'll also give me a good place to dump the two/three threads I have been saving in my inbox ;) Barry, Tim, I was also keeping the discussions on parallel-iteration and list-comprehensions. If you need those, I can send them as a nice little (hee hee) mailbox. > - a copyright notice. As a strawman, I propose that the owner/author > of each PEP retains copyright, but must publish it under the > OpenContent license, . Is there any reason not to include them in the standard Python licence, the same as the documentation ? It is documentation, after all, even if it's about unimplemented features ;) But then, I'm not a bloody lawyer, so what do I know. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Thu Jul 13 19:04:30 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 13 Jul 2000 13:04:30 -0400 Subject: [Python-Dev] more SyntaxError subclasses! In-Reply-To: <200007131329.PAA12745@python.inrialpes.fr> Message-ID: [Vladimir Marangozov] > Fredrik, I don't want to let this thread die, since I'm firmly +1 > on your proposal and the recent patches about more detailed syntax > errors are ... well, recent . That said, what's your next > proposal about making more progress on this? :-) PEP! Unless someone picks up on a thread instantly and implements it, it *always* fades away, doomed to reincarnate as if it were a new idea year after year after year, all the same arguments, all the same rebuttals, all the same greatness and noise . [/F] > I'll post a more complete proposal later... PEP it. Barry will be delighted to give it a Unique Global Identifier so that next year I can just say RTFPEP207-ly y'rs - tim. RTFPEP201-ly y'rs - tim From mal at lemburg.com Thu Jul 13 18:07:36 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 18:07:36 +0200 Subject: [Python-Dev] strncpy References: <396D5CA2.DBBBDC2C@prescod.net> <396D5D2E.4844F7FF@prescod.net> <396D9A3B.B6985C97@lemburg.com> <396D78E8.70926D96@prescod.net> Message-ID: <396DE948.F73C5C76@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > Before going down this road you should do some serious > > performance testing. ceval is *very* touchy about the order > > of the opcodes and adding indirection doesn't necessarily > > help (the compiler inlines the code again ;-). > > I'm not changing the order of the opcodes, just error handling. > > Anyhow, would performance results on my single computer be meaningful? Sure. If your changes cause a performance drop of more than 10% in pystone then this would be a sign of having to rethink the restructuring. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Thu Jul 13 18:10:19 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 12:10:19 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <20000713175503.V7340@xs4all.nl> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713175503.V7340@xs4all.nl> Message-ID: <14701.59883.957987.423016@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > Is there any reason not to include them in the standard Python licence, the > same as the documentation ? It is documentation, after all, even if it's In the IETF world, the Internet Society gets copyright of everything, so there's precedent for this. I don't think the author-based model isn't exactly what we're looking for. For specifications, there's usually an editor (the shephard, not the PEP Editor, in this case) who's name goes on there, with the copyright belonging to the organization under whose auspices the specification was written. For the W3C, the editors are named, and the copyright belongs to MIT, Inria, and Keio U. For us, the shephard is the editor and copyright should belong to the Python community (somehow; IANAL, so don't ask me how to do *that*). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Thu Jul 13 18:12:59 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 12:12:59 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.55141.272357.604260@anthem.concentric.net> References: <14701.26881.172217.870049@anthem.concentric.net> <396D5E20.69F228EC@prescod.net> <14701.55141.272357.604260@anthem.concentric.net> Message-ID: <14701.60043.481087.545575@bitdiddle.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "PP" == Paul Prescod writes: PP> I'm not clear on the role of opinions in this process. Do all of PP> the opinions about a proposal go in the PEP: PP> | * "I hate this, here's why" PP> | * "I have a minor enhancement proposal" PP> | * "Here is my competing proposal" BAW> In some sense yes, but it's the job of the owner/shepherd to BAW> follow the various threads, and include debate about the BAW> proposal as open issues. This would all lead to one of these BAW> conclusions: BAW> - we've reached consensus and now need just implement the BAW> proposal BAW> - we've reached an impasse and the BDFL will rule by decree BAW> - the proposal is hopeless flawed and the idea should be BAW> dropped BAW> - we need more information or research BAW> - we're defering the proposal to a future release This is the reason I suggested maintaining a separate mail archive of discussion. The PEP ought to represent a coherent proposal. It should discuss alternatives, but it should not be a compendium of all discussion and every possible idea. I would like to see something like the IETF model -- "rough consensus and running code" -- adopted. Python will be differently clearly, because the whole slogan is "We don't believe in kings, presidents, or voting. We believe in rough consensus and running code."[1] In the Python community, we do believe in at least one benevolent dictator for life. I propose the following guidlines: The PEP author is responsible for developing what he or she believes is a complete and coherent proposal. To be adopted, the PEP must constitute either the consensus opinion of the community (as determined by the PEP editor, Barry "Jon Postel" Warsaw) *or* be endorsed by Guido. It seems possible that we could have two different proposals for the same feature, which suggests we might want to have some notation about the final status of a PEP, e.g. accepted, rejected, etc., or that we have something like Internet drafts that will become PEPs only if adopted. Jeremy Note 1: People have suggested that it's actually the opposite: running consensus and rough code. From fdrake at beopen.com Thu Jul 13 18:15:41 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 12:15:41 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.60043.481087.545575@bitdiddle.concentric.net> References: <14701.26881.172217.870049@anthem.concentric.net> <396D5E20.69F228EC@prescod.net> <14701.55141.272357.604260@anthem.concentric.net> <14701.60043.481087.545575@bitdiddle.concentric.net> Message-ID: <14701.60205.465686.14824@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > Note 1: People have suggested that it's actually the opposite: running > consensus and rough code. When you have rough code, consensus tens to involve running competing ideas into the ground, right? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Thu Jul 13 14:25:48 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 07:25:48 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: <396DB54C.71F9332D@prescod.net> Jeremy Hylton wrote: > > ... > > - a mail archive attached to the PEP that contains relevant > discussion. A mail archive seems valuable for people interested in > the next level of detail, but I'm not sure what mechanism to use to > create one. (It also seems valuable because the old "search > dejanews" certainly isn't stable in the long-term.) Maybe PEP > authors could maintain their own archives. Here's a low-tech solution to get us started: Set up a mailbox for each PEP at pythonlabs or python.org and have people "CC:" that mail address, e.g. CC: pep202 at python.org. Run the changed ones through one of the mail to Web gateways daily. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 14:27:02 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 07:27:02 -0500 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> Message-ID: <396DB596.6F7C2C76@prescod.net> Skip Montanaro wrote: > > Paul> [for x: if y(x): for z: (x,y,z)] > > Agreed, however, your use of colons connotes the following to me > > l = [] > for x in something: > if y(x): > for z in something_else: > l.append((x,y,z)) > return l Yes, that's right. I forgot the "in something" and "in something_else" parts but your interpretation was still correct (a fault tolerant notation!!). [for x in something: if y(x): for z in something_else: (x,y,z)] -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From akuchlin at mems-exchange.org Thu Jul 13 18:44:12 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 13 Jul 2000 12:44:12 -0400 Subject: [Python-Dev] Unicode character name hashing In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CB@RED-MSG-50>; from billtut@microsoft.com on Thu, Jul 13, 2000 at 08:08:10AM -0700 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CB@RED-MSG-50> Message-ID: <20000713124412.D14938@kronos.cnri.reston.va.us> On Thu, Jul 13, 2000 at 08:08:10AM -0700, Bill Tutt wrote: >If some kind soul could test the ucnhash.c stuff running on the Cray Tim's >always talking about, and an Alpha running Unix that'd be awesome. If you want to test it on an Alpha, you could sign up for the Compaq test drive I posted about a while back; you get a 30-day account on your choice of Alphas running Tru64 4/5 or Linux. --amk From mal at lemburg.com Thu Jul 13 19:03:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 19:03:08 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <396DF64C.23833C61@lemburg.com> "Barry A. Warsaw" wrote: > > At our Pythonlabs meeting today, we decided we needed a more formal > and organized way to track all the language and other changes being > discussed on python-dev. Someone else (I don't remember who) > suggested an IETF-like approach. I like that as a model, but am not > sure how much of that formalism we need to adopt (or is even > appropriate for us). Someone on the reportlab list recently mentioned that SF supports subprojects via the task manager... wouldn't this be the ideal platform for managing PEPs ? > Wading > through, or even following, the python-dev mailing list or archives > should not be necessary. How about adding a PEP number to the subject line, e.g. "Re: [Python-Dev]:PEP999 Python Enhancement Proposals (PEPs)" ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Thu Jul 13 19:29:30 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 19:29:30 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> Message-ID: <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> greg wrote: > We don't care about anything except for %d, %s, possibly %c and %x. how about: PyObject * PyErr_SafeFormat(PyObject *exception, const char *format, ...) { va_list vargs; int n; const char* p; char* s; PyObject* string; /* figure out how large buffer we need */ va_start(vargs, format); n = 0; for (p = format; *p; p++) { if (*p == '%') { while (*++p && *p != '%' && !isalpha(*p)) ; switch (*p) { case 'c': va_arg(vargs, int); /* fall through... */ case '%': n++; break; case 'd': case 'i': case 'x': va_arg(vargs, int); n = n + 20; break; case 's': s = va_arg(vargs, char*); n = n + strlen(s); break; default: n = n + strlen(p); goto expand; } } else n = n + 1; } expand: string = PyString_FromStringAndSize(NULL, n); if (!string) return NULL; /* fill it in */ va_start(vargs, format); s = PyString_AsString(string); p = format; for (p = format; *p; p++) { if (*p == '%') { while (*++p && *p != '%' && !isalpha(*p)) ; switch (*p) { case 'c': *s++ = va_arg(vargs, int); break; case 'd': case 'i': itoa(va_arg(vargs, int), s, 10); s = s + strlen(s); break; case 'x': itoa(va_arg(vargs, int), s, 16); s = s + strlen(s); break; case 's': strcpy(s, va_arg(vargs, char*)); s = s + strlen(s); break; case '%': *s++ = '%'; break; default: strcpy(s, p-1); s = s + strlen(s); goto end; } } else *s++ = *p; } end: _PyString_Resize(&string, s - PyString_AsString(string)); PyErr_SetObject(exception, string); Py_XDECREF(string); return NULL; } From effbot at telia.com Thu Jul 13 19:42:26 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 19:42:26 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> Message-ID: <011b01bfecf2$15952580$f2a6b5d4@hagrid> barry wrote: > I like that as a model, but am not sure how much of that formalism > we need to adopt (or is even appropriate for us). I hope PEPs won't replace the existing "small proposal, >0, patch, >0, commit" fast-track mechanism... (FTPEPs) From effbot at telia.com Thu Jul 13 19:45:00 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 19:45:00 +0200 Subject: [Python-Dev] more SyntaxError subclasses! References: Message-ID: <011c01bfecf2$17838800$f2a6b5d4@hagrid> tim wrote: > > I'll post a more complete proposal later... > > PEP it. I hope to FTPEP this one (the error tag part, not the "tons of syntaxerror variants" part) more later. From fdrake at beopen.com Thu Jul 13 19:44:51 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 13:44:51 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <011b01bfecf2$15952580$f2a6b5d4@hagrid> References: <14701.26881.172217.870049@anthem.concentric.net> <011b01bfecf2$15952580$f2a6b5d4@hagrid> Message-ID: <14702.19.539033.987227@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > I hope PEPs won't replace the existing "small proposal, >0, > patch, >0, commit" fast-track mechanism... (FTPEPs) The PEP process is not meant for small enhancements, but for things like list comprehensions, where there are real issues with determining the appropriate syntax and semantics. For small stuff, submit a patch using SF. For fixing a bug, either submit a patch or just fix it, depending on whether its within your pervue & how confident you are that your patch is appropriately portable. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at beopen.com Thu Jul 13 20:12:50 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 14:12:50 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <011b01bfecf2$15952580$f2a6b5d4@hagrid> Message-ID: <14702.1698.288014.78586@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: >> I like that as a model, but am not sure how much of that >> formalism we need to adopt (or is even appropriate for us). FL> I hope PEPs won't replace the existing "small proposal, >0, FL> patch, >0, commit" fast-track mechanism... (FTPEPs) I agree. PEPs are for those proposals that Tim's already seen 5 times before and never got any agreement on. :) From HZhu at knowledgetrack.com Thu Jul 13 20:33:04 2000 From: HZhu at knowledgetrack.com (Huaiyu Zhu) Date: Thu, 13 Jul 2000 11:33:04 -0700 (PDT) Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators for matrix computation] In-Reply-To: <20000712201344.A1974@newcnri.cnri.reston.va.us> Message-ID: On Wed, 12 Jul 2000, Andrew Kuchling wrote: > Why not simply write a new parser for this application that generates > the desired semantics? Maintaining a complete fork of the Python > source might not be necessary if Jeremy's Python parsing/compiling > framework could be easily modified to implement the new operators. I wonder how orthogonal would this be against the main development? Would it require a rebuild for each new release. Would it also require a patch each time? > > (While a Python variant isn't something I'm enthused about, one > language can't be all things to all people, and I don't see why matrix > operations are so important as to get extra specialized operators; > lots of people use Python for text processing or for COM, so why > shouldn't special syntax be added for *those* applications? Having a > special parser also means that other matrix-specific language changes > could be made.) Well, linear algebra is not just another special domain. It is almost as elementary as arithmetic. Vectors and matrices are fundamental concepts in mathematics that underlies almost all of "scientific computation". They distill centuries of research in science and engineering, especially computation techniques. It is unlikely that adding linear algebra support would open up a flood gate for similar constructs. Look it this way. Text processing do have their special syntaxes. A string is written as "string" instead of ['s','t','r','i','n','g']. There is even the new sep.join(list). There are also lists and dicts for to build structures for discrete maths. If we had requested that new syntax for Fourier analysis or fractal generation that would be comparable to text processing or COM. Python actually has the chance of being all things to most people. The other half of the computing crowd only needs a few very basic asistance to come across. This crowd consists of people who design bridges and missiles, figure out weather patterns or DNA structures, detect credit card fraud or defects on a microchip, design speach recognition systems or network traffic balance algorithms and machines that learn to play games. Science and technology have great power to penatrate many aspects of life. And imagine if most of that is implemented in a laguage that can also be taught in schools. Huaiyu PS. I suppose I am allowed to post to python-dev without invitation, but not subscribing to it? I find this rather strange. From effbot at telia.com Thu Jul 13 20:38:35 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 20:38:35 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: Message-ID: <01c601bfecf9$90cc8e80$f2a6b5d4@hagrid> ?!ng wrote: > > Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] > > Otherwise user-code will probably have to special case more often. as in # normal case for (x,) in zip([0, 1, 2]): ... vs. # special case for x in zip([0, 1, 2]): ... ? From jim at interet.com Thu Jul 13 20:34:03 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 14:34:03 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: Message-ID: <396E0B9B.DD74EF5@interet.com> Mark Hammond wrote: > Yes, and each of these versions has broken various programs. Of all > people, Im surprised to see you falling for the MS hype, Jim. My experience is that it often works. I have also (who hasn't?) had the experience that mysterious bugs disappear by installing the newest DLLs. > > What this means is that if the new Python 2.0 (1.6?) simply names > > its DLL python15.dll just as before, everything Just Works almost. > > That is, it Just Works provided that foo.pyd only calls Python > > C functions whose interface has not changed. > > IMO, this constrains us too much. We can't afford this - we simply dont > have the resources. I guess I haven't made myself clear. I am not proposing that we freeze the C interface. I am not proposing that we scrutinize any *.pyd's for incompatabilities. I am proposing that we leave the "python15.dll" name the same. I am proposing that the various *.pyd authors themselves either provide newer versions, or declare that their *.pyd needs no newer version of python15.dll. It is a matter of odds. If we necessarily rename python15.dll for each version release, Python has a 100% chance of failing with an obscure error or crashing if it uses any *.pyd at all unless all *.pyd are replaced with new versions. If we do not rename python15.dll, then a *.pyd may or may not fail. My guess (only a guess) is that many will work OK. > > You can support Python 1.5 and 1.6 by removing the python*.dll > > from the Windows directories, and putting it in the directory > > of python.exe so it goes with the proper executable. > > We have discussed this over and over and over, ad nauseum. If you believe > the earlier discussions were bunk, please refute them. Otherwise, simply > re-asserting something that we have previously proven to be incorrect > doesnt help anyone. Putting python15.dll in with python.exe works fine for just using the interpreter python.exe, and it works fine for Python extensions. It fails when the client for python15.dll is not python.exe, but is some other client such as COM. That is, it fails to support Python embedding in general. I proposed that someone who needed multiple Python versions could use this solution provided that he/she had no use for embedding. Not as a general policy. > > Yes, and this is a major problem, and is un-Windows-like. > > :-) "Major Crashes" are un-Windows like? What is happening to this > group - It amusing that this statement could be made without the Linux > geeks making smart-arsed comments :-) Looks like Billy Boy really _is_ > taking over the world :-) I am a Linux geek myself. And Windows is more and more stable all the time. And yes, Bill is taking over the world and I doubt DoJ can stop him. JimA From tim_one at email.msn.com Thu Jul 13 21:34:07 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 13 Jul 2000 15:34:07 -0400 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14702.1698.288014.78586@anthem.concentric.net> Message-ID: [Barry] > I agree. PEPs are for those proposals that Tim's already seen 5 times > before and never got any agreement on. :) Boost that to 50 and I'll agree . Also for proposals not necessarily originated by developers: we also have a history of losing "good ideas", just because the person fighting for them is not a developer, can't really address how to implement it, and no developer at the time "adopts" it. It's no good asking for examples, because *we've* all forgotten them <0.9 wink>. From jim at interet.com Thu Jul 13 20:38:39 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 14:38:39 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <20000711215517.E9C71E2673@oratrix.oratrix.nl> Message-ID: <396E0CAF.DA3A8740@interet.com> Jack Jansen wrote: > > Excuse my ignorance, but isn't the whole problem that the python 1.6 > DLL is in the system search path even when you are running Python 1.7? Yes, but it is necessary to put the DLL in the system search path to support Python embedding. That is, to support an arbitrary client of the DLL, such as another DLL, COM object, etc. JimA From jim at interet.com Thu Jul 13 20:43:38 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 14:43:38 -0400 Subject: [Python-Dev] O'Reilly conference References: <14699.36774.938027.57751@cj42289-a.reston1.va.home.com> Message-ID: <396E0DDA.530ADB62@interet.com> "Fred L. Drake, Jr." wrote: > > So who's going to the O'Reilly conference next week? The PythonLabs Sorry, can't make it. High air fares, gone too much already. JimA From mal at lemburg.com Thu Jul 13 20:44:27 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 20:44:27 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <01c601bfecf9$90cc8e80$f2a6b5d4@hagrid> Message-ID: <396E0E0B.C8D446BC@lemburg.com> Fredrik Lundh wrote: > > ?!ng wrote: > > > Re: open issues: marry([0, 1, 2]) should return [(1,), (2,), (3,)] > > > Otherwise user-code will probably have to special case more often. > > as in > > # normal case > for (x,) in zip([0, 1, 2]): > ... > > vs. > > # special case > for x in zip([0, 1, 2]): > ... > > ? Uhm, why should marry() be defined for a single argument ? IMHO, this only masks program errors. BTW: >>> from mx.Tools import NewBuiltins >>> marry = tuples >>> john = lists >>> marry([0,1,2]) Traceback (innermost last): File "", line 1, in ? TypeError: sequence elements must be sequences >>> marry([0,1,2],[3,4,5]) [(0, 3), (1, 4), (2, 5)] >>> john([0,1,2],[3,4,5]) ([0, 3], [1, 4], [2, 5]) ... the code is there. I'd say: use it :-) (Who invented those silly function names ?) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy at beopen.com Thu Jul 13 20:50:04 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 14:50:04 -0400 (EDT) Subject: [Python-Dev] SyntaxError patches In-Reply-To: <14700.34906.286143.800770@beluga.mojam.com> References: <14700.25459.555611.544163@bitdiddle.concentric.net> <14700.34906.286143.800770@beluga.mojam.com> Message-ID: <14702.3932.157846.676297@bitdiddle.concentric.net> >>>>> "SM" == Skip Montanaro writes: SyntaxError: dedent does not match any outer indentation level SM> Isn't something like "line indented incorrectly" sufficient to SM> alert the programmer to an indentation on that line? Perhaps SM> Python doesn't need to tell which direction to push the line. I like this error message best. It may not provided as much information as possible, but it seems to provide as much information as is really needed and as much as can be reasonably understood. Jeremy From jim at interet.com Thu Jul 13 20:49:40 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 14:49:40 -0400 Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> Message-ID: <396E0F44.59B63956@interet.com> Greg Stein wrote: > > On Wed, Jul 12, 2000 at 07:52:05AM +0100, Andy Robinson wrote: > >... > > Are there many other applications which > > use compression? If so, would it do > > be feasible to include it by default > > from version 1.6? > > I believe the correct approach would be to have ./configure look for zlib. > If present, then it should include the module into the build. I think that what Andy wants is to have zlib always distributed with Python, and always available. JimA From bwarsaw at beopen.com Thu Jul 13 20:53:25 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 14:53:25 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> <396E0F44.59B63956@interet.com> Message-ID: <14702.4133.886431.381684@anthem.concentric.net> >>>>> "JCA" == James C Ahlstrom writes: JCA> I think that what Andy wants is to have zlib always JCA> distributed with Python, and always available. We've argued about that before, although I'm not sure if we did so on python-dev. I argued for this, in the context of distutils, but I think Guido doesn't want to maintain this external library. We'd have to do that if we distribute it with Python. -Barry From jeremy at beopen.com Thu Jul 13 21:00:54 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 15:00:54 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: References: <200007121318.IAA14063@cj20424-a.reston1.va.home.com> Message-ID: <14702.4582.530066.817107@bitdiddle.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> On Wed, 12 Jul 2000, Guido van Rossum wrote: >> Greg subtly points out the difficulty with your proposal: this >> requires an external library that may not be available. In the >> past we've had enough complaints from people who failed to >> realize that if the build failed because of a missing external >> library, they could just disable the module that needs it. So >> I'm not for simply having it enabled in Setup.in by default. MZ> Currently there are two external libraries one needs to build a MZ> "good" Python interpreter: zlib, and expat. Well, now that MZ> Python releases from BeOpen, and not CNRI, perhaps it will be MZ> deemed all right to put them in the source distribution, and by MZ> default have a Setup.in that builds on them? Perhaps even MZ> include a "last known good" Tcl/Tk? I don't see the need to include the source code from other projects or libraries in a regular Python release. Rather, I'd like to see something like the Windows installer, which packages up third-party software like Tcl/Tk. I'm working on a nightly build system for Python that will produce a tar ball and some Linux RPMs, based in part on the very good work that Oliver Andrich did. One of the first things I discovered is that Expat isn't packaged very well for Linux systems, but that seemed easy to fix: http://www.pythonlabs.com/download/misc/rpm/expat-1.1-1.i386.rpm http://www.pythonlabs.com/download/misc/rpm/expat-1.1-1.src.rpm I'm sure there are other platforms and Linux distributions with different packaging mechanisms, but Windows and Linuxes-supporting-RPM seems like a good start. Jeremy From jeremy at beopen.com Thu Jul 13 21:10:28 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 15:10:28 -0400 (EDT) Subject: [Python-Dev] Unit testing... In-Reply-To: <396C926D.F223E686@prescod.net> References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> Message-ID: <14702.5156.863478.268256@bitdiddle.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Andrew Kuchling wrote: >> ... >> >> (I've speculated about adding a unit testing framework, similar >> to the one we use internally at the MEMS Exchange; the discipline >> of using it makes writing a test more time-consuming, but the >> tests also wind up being more comprehensive.) PP> I think PyUnit/JUnit and friends are in vogue these days. There PP> is some virtue in having a framework that could be used also by PP> extension module writers so that there is some consistency about PP> finding and invoking tests. I think there are several unit testing frameworks for Python. Would you be willing to survey the state of these projects and suggest one for adoption? I think the current regrtest script is a bit krufty; it's certainly hard to read. Two features I'd like to see in an improved testing framework are the ability to test syntax errors, e.g. check that def foo(a): global a raises a syntax error and does not dump core. It would also be good to include tests for modules like httplib that might fail for reasons that have nothing to do with the code itself. (Perhaps one could finesse the issue by building a test suite using the SimpleHTTPServer.) I don't think there's a good way to report a non-fatal error like, "couldn't run the httplib test because the network appears to be down." Jeremy From DavidA at ActiveState.com Thu Jul 13 21:16:14 2000 From: DavidA at ActiveState.com (David Ascher) Date: Thu, 13 Jul 2000 12:16:14 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Unit testing... In-Reply-To: <14702.5156.863478.268256@bitdiddle.concentric.net> Message-ID: > I think there are several unit testing frameworks for Python. Would > you be willing to survey the state of these projects and suggest one > for adoption? I think the current regrtest script is a bit krufty; > it's certainly hard to read. doctest.py! From gvwilson at nevex.com Thu Jul 13 21:17:41 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Thu, 13 Jul 2000 15:17:41 -0400 (EDT) Subject: [Python-Dev] multi-loop quiz results Message-ID: I gave 20+ grad students in computer engineering and computer science (plus a couple of profs) the questionnaire below. A summary of results is: * Everyone understood the existing syntax (A). * Most assumed that that the 'zip()' function version would yield cross-product iteration (B). This surprised me a lot, particularly as I think we all agree that 'zip()' is the most suggestive possible name for this function. * Versions (D), (F), and (H) show that semi-colon separated targets imply cross-product iteration, but 'and' and 'while' imply simultaneous iteration. * Version (G) shows that using 'and' suggests that the sequences being iterated over must have the same length. The questionnaire and a table of responses are included below (100 characters wide). Greg ---------------------------------------------------------------------- The single and double loop below print the output shown: for x in [10, 20, 30]: for x in [10, 20, 30]: print x for y in [1, 2, 3]: print x+y 10 11 20 12 30 13 21 22 23 31 32 33 Match each of the following to its output. (Note that several examples may print the same thing.) (1) (2) (3) (4) (5) (6) 11 11 11 11 error ?? 22 12 22 12 33 13 21 21 22 22 31 23 32 31 32 33 (A) for (x, y) in [[10, 1], [20, 2], [30, 3]]: 11 0 0 0 0 0 print x+y (B) for [x, y] in zip([10, 20, 30], [1, 2, 3]): 2 6 0 0 0 3 print x+y (C) for [x, y] in zip([10, 20, 30], [1, 2]): 0 0 1 4 4 2 print x+y (D) for x in [10, 20, 30]; y in [1, 2, 3]: 3 7 0 0 1 0 print x+y (E) for x in [10, 20, 30]; y in [1, 2]: 1 0 2 6 2 0 print x+y (F) for (x in [10, 20, 30]) and (y in [1, 2, 3]): 7 4 0 0 0 0 print x+y (G) for (x in [10, 20, 30]) and (y in [1, 2]): 0 0 1 2 6 2 print x+y (H) for x in [10, 20, 30] while y in [1, 2, 3]: 2 7 0 0 1 1 print x+y (I) for x in [10, 20, 30] while y in [1, 2]: 0 1 0 7 2 1 print x+y (J) for x; y in [10, 20, 30]; [1, 2, 3]: 2 3 0 1 3 2 print x+y (K) for x; y in [10, 20, 30]; [1, 2]: 0 1 0 3 5 2 print x+y From paul at prescod.net Thu Jul 13 19:27:07 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:27:07 -0500 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> <396E08E0.7536A665@lemburg.com> Message-ID: <396DFBEB.2363922C@prescod.net> "M.-A. Lemburg" wrote: > > ... > > Is it really necessary to have all the "code" inside the square > brackets ? That's what a list comprehension is! Check the defacto PEP: http://www.cosc.canterbury.ac.nz/~greg/python/listcomp/ I take it you are against list comprehensions. > I always thought of list comprehension as a fast way to > just throw together a list, not as a way to "program" the > list contents. IMHO, that should be done using explicit > statements in the way Skip describes above. > > I would be completely satisfied with e.g. [0..10], [0..10:2] > and [10..0]. Those are not list comprehensions but "range literals." Actually, the syntax we are using is [0:10], [0:10:2], [10:0]. I prefer dotdot, but Guido chose the colon a decade ago. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From akuchlin at mems-exchange.org Thu Jul 13 21:25:14 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 13 Jul 2000 15:25:14 -0400 Subject: [Python-Dev] Unit testing... In-Reply-To: <14702.5156.863478.268256@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 03:10:28PM -0400 References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> <14702.5156.863478.268256@bitdiddle.concentric.net> Message-ID: <20000713152514.G14938@kronos.cnri.reston.va.us> On Thu, Jul 13, 2000 at 03:10:28PM -0400, Jeremy Hylton wrote: >I think there are several unit testing frameworks for Python. Would >you be willing to survey the state of these projects and suggest one >for adoption? I'm not particularly interested in looking at other tools, since I'm quite content with mems.tools.unittest, the one that Greg wrote. Earlier this week Neil S. added code coverage support for it using Skip's coverage code, so we can see which lines of code aren't getting exercised. --amk From gvwilson at nevex.com Thu Jul 13 21:26:15 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Thu, 13 Jul 2000 15:26:15 -0400 (EDT) Subject: [Python-Dev] Unit testing... In-Reply-To: <14702.5156.863478.268256@bitdiddle.concentric.net> Message-ID: On Thu, 13 Jul 2000, Jeremy Hylton wrote: >>> Andrew Kuchling wrote: >>> (I've speculated about adding a unit testing framework... >> Paul Prescod writes: >> I think PyUnit/JUnit and friends are in vogue these days. > Jeremy Hylton wrote: > I think there are several unit testing frameworks for Python. Would > you be willing to survey the state of these projects and suggest one > for adoption? Greg Wilson writes: We (Software Carpentry judges, plus a few invited others) are trying to select a narrower set of requirements for the "test tool" category. The current front runner is some sort of unit testing framework based on Kent Beck's xUnit, combined with coverage analysis so that you get a measure of code coverage. We'd be very interested in input from anyone on this list who has experience with either Steve Purcell or Cayte Lindner's PyUnit frameworks, or has worked with tools that do this double task, or has ideas about what they'd like --- the more input we get, the more likely we are to build what you want. Please contact me (gvwilson at nevex.com) or Alex Samuel (samuel at codesourcery.com). Thanks, Greg p.s. Purcell's version is http://pyunit.sourceforge.net/ Lindner's is ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip From effbot at telia.com Thu Jul 13 21:39:56 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 13 Jul 2000 21:39:56 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <01c601bfecf9$90cc8e80$f2a6b5d4@hagrid> <396E0E0B.C8D446BC@lemburg.com> Message-ID: <026c01bfed02$2188e380$f2a6b5d4@hagrid> mal wrote: > Uhm, why should marry() be defined for a single argument ? because map is defined for a single argument? > ... the code is there. I'd say: use it :-) well, yes. if zip/marry/whatever is just a map without the first argument, that's definitely true ;-) in case someone wants to play: Index: Python/bltinmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v retrieving revision 2.170 diff -u -r2.170 bltinmodule.c --- Python/bltinmodule.c 2000/07/12 13:03:02 2.170 +++ Python/bltinmodule.c 2000/07/13 19:32:37 @@ -963,9 +963,10 @@ static PyObject * -builtin_map(self, args) +mapzip(self, args, zip) PyObject *self; PyObject *args; + int zip; { typedef struct { PyObject *seq; @@ -977,20 +978,31 @@ sequence *seqs = NULL, *sqp; int n, len; register int i, j; + int first_seq; n = PyTuple_Size(args); - if (n < 2) { - PyErr_SetString(PyExc_TypeError, - "map() requires at least two args"); - return NULL; + if (zip) { + if (n < 1) { + PyErr_SetString(PyExc_TypeError, + "zip() requires at least one arg"); + return NULL; + } + func = Py_None; + first_seq = 0; + } else { + if (n < 2) { + PyErr_SetString(PyExc_TypeError, + "map() requires at least two args"); + return NULL; + } + func = PyTuple_GetItem(args, 0); + first_seq = 1; + n--; } - func = PyTuple_GetItem(args, 0); - n--; - if (func == Py_None && n == 1) { /* map(None, S) is the same as list(S). */ - return PySequence_List(PyTuple_GetItem(args, 1)); + return PySequence_List(PyTuple_GetItem(args, first_seq)); } if ((seqs = PyMem_NEW(sequence, n)) == NULL) { @@ -1002,20 +1014,15 @@ int curlen; PySequenceMethods *sqf; - if ((sqp->seq = PyTuple_GetItem(args, i + 1)) == NULL) + if ((sqp->seq = PyTuple_GetItem(args, i + first_seq)) == NULL) goto Fail_2; sqp->sqf = sqf = sqp->seq->ob_type->tp_as_sequence; if (sqf == NULL || sqf->sq_length == NULL || - sqf->sq_item == NULL) - { - static char errmsg[] = - "argument %d to map() must be a sequence object"; - char errbuf[sizeof(errmsg) + 25]; - - sprintf(errbuf, errmsg, i+2); - PyErr_SetString(PyExc_TypeError, errbuf); + sqf->sq_item == NULL) { + PyErr_Format(PyExc_TypeError, + "argument %d to map() must be a sequence object", i+2); goto Fail_2; } @@ -1118,6 +1125,16 @@ return NULL; } + +static PyObject * +builtin_map(self, args) + PyObject *self; + PyObject *args; +{ + return mapzip(self, args, 0); +} + + static char map_doc[] = "map(function, sequence[, sequence, ...]) -> list\n\ \n\ @@ -1130,6 +1147,22 @@ static PyObject * +builtin_zip(self, args) + PyObject *self; + PyObject *args; +{ + return mapzip(self, args, 1); +} + + +static char zip_doc[] = +"zip(sequence[, sequence, ...]) -> list\n\ +\n\ +Return a list of the items of the sequence (or a list of tuples if more\n\ +than one sequence)."; + + +static PyObject * builtin_setattr(self, args) PyObject *self; PyObject *args; @@ -2327,6 +2360,7 @@ {"unichr", builtin_unichr, 1, unichr_doc}, {"vars", builtin_vars, 1, vars_doc}, {"xrange", builtin_xrange, 1, xrange_doc}, + {"zip", builtin_zip, 1, zip_doc}, {NULL, NULL}, }; From jeremy at beopen.com Thu Jul 13 21:37:39 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 15:37:39 -0400 (EDT) Subject: [Python-Dev] Unit testing... In-Reply-To: <20000713152514.G14938@kronos.cnri.reston.va.us> References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> <14702.5156.863478.268256@bitdiddle.concentric.net> <20000713152514.G14938@kronos.cnri.reston.va.us> Message-ID: <14702.6787.986976.271026@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Thu, Jul 13, 2000 at 03:10:28PM -0400, Jeremy Hylton wrote: >> I think there are several unit testing frameworks for Python. >> Would you be willing to survey the state of these projects and >> suggest one for adoption? AMK> I'm not particularly interested in looking at other tools, I didn't mean that I wanted you to do it :-). Are you saying that you personally aren't interested or that the rest of us shouldn't be interested in either? AMK> since I'm quite content with mems.tools.unittest, the one that AMK> Greg wrote. Earlier this week Neil S. added code coverage AMK> support for it using Skip's coverage code, so we can see which AMK> lines of code aren't getting exercised. I'm not at all familiar with this code. Has it been released? Is it open source? Could it be used for the Python test suite? Jeremy From mal at lemburg.com Thu Jul 13 21:51:59 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 21:51:59 +0200 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> <396E08E0.7536A665@lemburg.com> <396DFBEB.2363922C@prescod.net> Message-ID: <396E1DDF.1861EE80@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > Is it really necessary to have all the "code" inside the square > > brackets ? > > That's what a list comprehension is! Check the defacto PEP: > > http://www.cosc.canterbury.ac.nz/~greg/python/listcomp/ > > I take it you are against list comprehensions. If it means writing code in square brackets: yes -- I don't see any real benefit other than confusing the reader... it doesn't even gain any performance (I would have thought that constant ranges like [0:10] would generate [0,1,2,3,4,5,6,7,8,9] and make this a constant, but that doesn't seem to be the case). > > I always thought of list comprehension as a fast way to > > just throw together a list, not as a way to "program" the > > list contents. IMHO, that should be done using explicit > > statements in the way Skip describes above. > > > > I would be completely satisfied with e.g. [0..10], [0..10:2] > > and [10..0]. > > Those are not list comprehensions but "range literals." Oh, so I won't get these with list comprehension ? Hmm, then I'm posting on the wrong thread, I guess ;-) > Actually, the > syntax we are using is [0:10], [0:10:2], [10:0]. I prefer dotdot, but > Guido chose the colon a decade ago. Say, wouldn't it make more sense to have these notations generate tuples (which are immutable and could thus be stored as constants) rather than lists ?! for x in (0:10): print x Hmm, looks strange, perhaps not such a good notation.... for x in (0..10): print x or even: for x in 0..10: print x Oh, now this looks much better :-) The for-loop opcode could even make some use of this by not generating a tuple at all (it could use a special mutable counter like the one available in my speedup patch for 1.5: http://starship.python.net/~lemburg/mxPython-1.5.patch.gz [see the ceval part of the patch -- it uses the counter object the patch also contains which provides a mutable integer implementation for just this purpose] The patch also includes some other performance enhancements such as a small dictionary enhancement and many other things which have already made it into 2.0) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Thu Jul 13 19:34:44 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:34:44 -0500 Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> <396E0F44.59B63956@interet.com> <14702.4133.886431.381684@anthem.concentric.net> Message-ID: <396DFDB4.A257245C@prescod.net> "Barry A. Warsaw" wrote: > > ... > > We've argued about that before, although I'm not sure if we did so on > python-dev. I argued for this, in the context of distutils, but I > think Guido doesn't want to maintain this external library. We'd have > to do that if we distribute it with Python. I don't understand the last sentence???? Distributing a library with Python requires no more than "cp". Do we maintain TK on Windows? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 19:35:01 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:35:01 -0500 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <396DFDC5.6780A710@prescod.net> Huaiyu Zhu wrote: > > ... > > I wonder how orthogonal would this be against the main development? Would > it require a rebuild for each new release. Would it also require a patch > each time? I think that the idea is that you could install new syntaxes in the same way you install new modules...of course only after careful consideration!!! > Look it this way. Text processing do have their special syntaxes. Okay, but probably 90% of Python programmers do text processing at some point. Not so for matrix calculation. You believe that the Python world would grow greatly if we did matrices natively. I don't know if I believe that. I'm not entirely against your proposal but you've got to expect major pushback on such large-scale syntax and semantic changes. > PS. I suppose I am allowed to post to python-dev without invitation, but not > subscribing to it? I find this rather strange. Yes, it is rather strange. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From m.favas at per.dem.csiro.au Thu Jul 13 22:15:34 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Fri, 14 Jul 2000 04:15:34 +0800 Subject: [Python-Dev] Unicode character name hashing Message-ID: <396E2366.66F62B24@per.dem.csiro.au> [Bill has epiphany] >I just had a rather unhappy epiphany this morning. >F1, and f2 in ucnhash.c might not work on machines where sizeof(long) >!= 32 bits. I get the following from test_ucn on an Alpha running Tru64 Unix: python Lib/test/test_ucn.py UnicodeError: Unicode-Escape decoding error: Invalid Unicode Character Name This is with the current CVS - and it's been failing this test for some time now. I'm happy to test any fixes... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From mal at lemburg.com Thu Jul 13 20:22:24 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 13 Jul 2000 20:22:24 +0200 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> Message-ID: <396E08E0.7536A665@lemburg.com> Paul Prescod wrote: > > Skip Montanaro wrote: > > > > Paul> [for x: if y(x): for z: (x,y,z)] > > > > Agreed, however, your use of colons connotes the following to me > > > > l = [] > > for x in something: > > if y(x): > > for z in something_else: > > l.append((x,y,z)) > > return l > > Yes, that's right. I forgot the "in something" and "in something_else" > parts but your interpretation was still correct (a fault tolerant > notation!!). > > [for x in something: if y(x): for z in something_else: (x,y,z)] Is it really necessary to have all the "code" inside the square brackets ? I always thought of list comprehension as a fast way to just throw together a list, not as a way to "program" the list contents. IMHO, that should be done using explicit statements in the way Skip describes above. I would be completely satisfied with e.g. [0..10], [0..10:2] and [10..0]. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at mems-exchange.org Thu Jul 13 22:46:42 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Thu, 13 Jul 2000 16:46:42 -0400 Subject: [Python-Dev] Unit testing... In-Reply-To: <14702.6787.986976.271026@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 03:37:39PM -0400 References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> <14702.5156.863478.268256@bitdiddle.concentric.net> <20000713152514.G14938@kronos.cnri.reston.va.us> <14702.6787.986976.271026@bitdiddle.concentric.net> Message-ID: <20000713164642.A15987@kronos.cnri.reston.va.us> On Thu, Jul 13, 2000 at 03:37:39PM -0400, Jeremy Hylton wrote: >I didn't mean that I wanted you to do it :-). Are you saying that you >personally aren't interested or that the rest of us shouldn't be >interested in either? I'm personally not interested in doing the work, that's all. Someone should definitely do this, though; a better standard testing framework would be very useful. >I'm not at all familiar with this code. Has it been released? Is it >open source? Could it be used for the Python test suite? Not formally released, no; an old version is hiding inside Quixote (http://www.mems-exchange.org/exchange/software/files/quixote/) as test.unittest.py, because it was used to write the included test suites. I could go try to get a licence for it, but you know what that'll be like. (My, aren't I sounding bitter today...) --amk From thomas at xs4all.net Thu Jul 13 23:07:00 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 23:07:00 +0200 Subject: [Python-Dev] multi-loop quiz results In-Reply-To: ; from gvwilson@nevex.com on Thu, Jul 13, 2000 at 03:17:41PM -0400 References: Message-ID: <20000713230659.W7340@xs4all.nl> On Thu, Jul 13, 2000 at 03:17:41PM -0400, Greg Wilson wrote: > I gave 20+ grad students in computer engineering and computer science > (plus a couple of profs) the questionnaire below. A summary of > results is: > * Versions (D), (F), and (H) show that semi-colon separated targets > imply cross-product iteration, but 'and' and 'while' imply > simultaneous iteration. Really ? Looking at it, it looks like 'while' also implies cross-product: > (H) > for x in [10, 20, 30] while y in [1, 2, 3]: 2 7 0 0 1 1 > print x+y > > (I) > for x in [10, 20, 30] while y in [1, 2]: 0 1 0 7 2 1 > print x+y 'and' does seem to be the 'right' thing, but mostly in the awkward extra-grouped variant... Apparently using a builtin instead of a syntax change is a good thing. Hopefully it will at least get people thinking, instead of assuming. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Thu Jul 13 19:40:25 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:40:25 -0500 Subject: [Python-Dev] Unit testing... References: <14700.34254.159786.213828@beluga.mojam.com> <20000712110637.E1363@kronos.cnri.reston.va.us> <396C926D.F223E686@prescod.net> <14702.5156.863478.268256@bitdiddle.concentric.net> Message-ID: <396DFF09.191A04EE@prescod.net> Jeremy Hylton wrote: > > ... > > I think there are several unit testing frameworks for Python. No, not the right guy. I'm pretty low-tech when it comes to testing. I just write long scripts that use many methods and then check coverage. I was hoping that someone else would jump in and point out the many virtues of the trendy XUnit testing framework. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Thu Jul 13 19:51:04 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 12:51:04 -0500 Subject: [Python-Dev] List comprehensions References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> <396E08E0.7536A665@lemburg.com> <396DFBEB.2363922C@prescod.net> <396E1DDF.1861EE80@lemburg.com> Message-ID: <396E0188.33861CC7@prescod.net> "M.-A. Lemburg" wrote: > > If it means writing code in square brackets: yes -- > I don't see any real benefit other than confusing the reader... > it doesn't even gain any performance We've discussed making them lazy, which would improve performance in some cases...especially with infinite lists. :) > Oh, so I won't get these with list comprehension ? Hmm, then > I'm posting on the wrong thread, I guess ;-) Well, I didn't want to say it, but... > Say, wouldn't it make more sense to > have these notations generate tuples (which are immutable and > could thus be stored as constants) rather than lists ?! I think that the notation should create a generator. > The for-loop opcode could even make some use of this by not generating > a tuple at all (it could use a special mutable counter like the > one available in my speedup patch for 1.5: We discussed this yesterday. Anyhow, you don't need to use tuples to get the speedup. You just have to recognize the pattern in a peephole optimizer. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From jim at interet.com Thu Jul 13 23:42:11 2000 From: jim at interet.com (James C. Ahlstrom) Date: Thu, 13 Jul 2000 17:42:11 -0400 Subject: [Python-Dev] zlib not compiled by default References: <20000712031358.X29590@lyra.org> <396E0F44.59B63956@interet.com> <14702.4133.886431.381684@anthem.concentric.net> Message-ID: <396E37B3.39C9BEC7@interet.com> "Barry A. Warsaw" wrote: > > >>>>> "JCA" == James C Ahlstrom writes: > > JCA> I think that what Andy wants is to have zlib always > JCA> distributed with Python, and always available. > > We've argued about that before, although I'm not sure if we did so on > python-dev. I argued for this, in the context of distutils, but I > think Guido doesn't want to maintain this external library. We'd have > to do that if we distribute it with Python. I don't think distributing zlib means we have to maintain it. Well, I guess we would have to get the new zlib version before each release, and re-write the interface functions if they change. Hmmm... Actually, I thought the issue was the megabyte size of the distribution. JimA From esr at thyrsus.com Thu Jul 13 23:54:29 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 17:54:29 -0400 Subject: [Python-Dev] List comprehensions In-Reply-To: <396E0188.33861CC7@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 12:51:04PM -0500 References: <396D44E7.F87983AB@prescod.net> <14701.52596.651140.884121@beluga.mojam.com> <396DB596.6F7C2C76@prescod.net> <396E08E0.7536A665@lemburg.com> <396DFBEB.2363922C@prescod.net> <396E1DDF.1861EE80@lemburg.com> <396E0188.33861CC7@prescod.net> Message-ID: <20000713175429.A6605@thyrsus.com> Paul Prescod : > > Say, wouldn't it make more sense to > > have these notations generate tuples (which are immutable and > > could thus be stored as constants) rather than lists ?! > > I think that the notation should create a generator. I heartily agree. -- Eric S. Raymond To stay young requires the unceasing cultivation of the ability to unlearn old falsehoods. -- Lazarus Long From billtut at microsoft.com Thu Jul 13 23:44:34 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 13 Jul 2000 14:44:34 -0700 Subject: [Python-Dev] RE: Unicode character name hashing Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CF@RED-MSG-50> Does this patch happen to fix it? I'm afraid my skills relating to signed overflow is a bit rusty... :( Bill =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/ucnhash.c,v retrieving revision 1.2 diff -u -r1.2 ucnhash.c --- ucnhash.c 2000/06/29 00:06:39 1.2 +++ ucnhash.c 2000/07/13 21:41:07 @@ -30,12 +30,12 @@ len = cch; p = (unsigned char *) key; - x = 1694245428; + x = (long)0x64fc2234; while (--len >= 0) - x = (1000003*x) ^ toupper(*(p++)); + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); x ^= cch + 10; - if (x == -1) - x = -2; + if (x == (long)0xFFFFFFFF) + x = (long)0xfffffffe; x %= k_cHashElements; /* ensure the returned value is positive so we mimic Python's % operator */ if (x < 0) @@ -52,12 +52,12 @@ len = cch; p = (unsigned char *) key; - x = -1917331657; + x = (long)0x8db7d737; while (--len >= 0) - x = (1000003*x) ^ toupper(*(p++)); + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); x ^= cch + 10; - if (x == -1) - x = -2; + if (x == (long)0xFFFFFFFF) + x = (long)0xfffffffe; x %= k_cHashElements; /* ensure the returned value is positive so we mimic Python's % operator */ if (x < 0) -----Original Message----- From: Mark Favas [mailto:m.favas at per.dem.csiro.au] Sent: Thursday, July 13, 2000 1:16 PM To: python-dev at python.org; Bill Tutt Subject: Unicode character name hashing [Bill has epiphany] >I just had a rather unhappy epiphany this morning. >F1, and f2 in ucnhash.c might not work on machines where sizeof(long) >!= 32 bits. I get the following from test_ucn on an Alpha running Tru64 Unix: python Lib/test/test_ucn.py UnicodeError: Unicode-Escape decoding error: Invalid Unicode Character Name This is with the current CVS - and it's been failing this test for some time now. I'm happy to test any fixes... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From thomas at xs4all.net Thu Jul 13 23:53:56 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 13 Jul 2000 23:53:56 +0200 Subject: [Python-Dev] [PEP204] Range Literals Message-ID: <20000713235356.X7340@xs4all.nl> On Thu, Jul 13, 2000 at 11:24:38AM -0400, Barry A. Warsaw wrote: > BTW, PEP204 is up for grabs too. It's titled "Range Literals". As I already wrote Barry, I'll do this one -- but only if it's a no-brainer. The patch is already written and I hadn't heard complaints about the syntax, but now I hear some rumbling about how it should be a generator instead of a list constructor. I don't feel like digging into that particular dungball, though, having no experience what so ever with iterators, generators or languages that implement those. (So I'm a C and Python programmar by heart. Sue me.) That isn't to say I think it's a bad idea, not at all. I just don't want to do it :-) But if anyone else wants to implement it, and do so before 2.0, yell now, and you can take over the entire range-literal thing as well. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Thu Jul 13 23:56:53 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 00:56:53 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <01c601bfecf9$90cc8e80$f2a6b5d4@hagrid> Message-ID: On Thu, 13 Jul 2000, Fredrik Lundh wrote: > as in > > # normal case > for (x,) in zip([0, 1, 2]): > ... > > vs. > > # special case > for x in zip([0, 1, 2]): > ... > I'm sorry, I don't buy that. # "special case" for x in [0, 1, 2]: ... # "special case" do_something_that_requires_a_list_of_tuples(zip(*lists)) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From fdrake at beopen.com Fri Jul 14 00:01:22 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 18:01:22 -0400 (EDT) Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: <20000713235356.X7340@xs4all.nl> References: <20000713235356.X7340@xs4all.nl> Message-ID: <14702.15410.306511.372250@cj42289-a.reston1.va.home.com> Thomas Wouters writes: > As I already wrote Barry, I'll do this one -- but only if it's a no-brainer. > The patch is already written and I hadn't heard complaints about the syntax, > but now I hear some rumbling about how it should be a generator instead of a > list constructor. I don't feel like digging into that particular dungball, > though, having no experience what so ever with iterators, generators or Don't confuse being the PEP shephard with being the implementor, though *having* an implementation is important. Who does it is secondary. Can't the implementation be to create an xrange object instead of a list? Seems easy enough on first glance. But then, I've been carefully ignoring that whole discussion. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From moshez at math.huji.ac.il Fri Jul 14 00:03:54 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 01:03:54 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: On Thu, 13 Jul 2000, Jeremy Hylton wrote: > I don't see the need to include the source code from other projects or > libraries in a regular Python release. Rather, I'd like to see > something like the Windows installer, which packages up third-party > software like Tcl/Tk. But I'm exactly concerned with minority platforms here: people who have packagers can manage without our help. Are you going to make an installer for Solaris? AIX? Then at least help these people build Python from source -- with "known compatible versions". I *don't* think it should be done for beta versions, only as an alternative release -- a "rich source release". (If I have some time, I might try to build something like that for 2.0 final, at any rate.) I'm currently drawing a list for extensions to include: -- zlib -- Tcl/Tk -- expat -- PIL -- Anything else? I really want something with "everything" in it. My motivation: I work on quite a few Unixes at work (AIX, Solaris, HP and probably more to come). Installing Python on any of these is a pain -- exactly because of the need to download 5-6 packages, and install them iteratively. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From guido at beopen.com Fri Jul 14 01:05:12 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 13 Jul 2000 18:05:12 -0500 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: Your message of "Thu, 13 Jul 2000 23:53:56 +0200." <20000713235356.X7340@xs4all.nl> References: <20000713235356.X7340@xs4all.nl> Message-ID: <200007132305.SAA11276@cj20424-a.reston1.va.home.com> > As I already wrote Barry, I'll do this one -- but only if it's a no-brainer. > The patch is already written and I hadn't heard complaints about the syntax, > but now I hear some rumbling about how it should be a generator instead of a > list constructor. I don't feel like digging into that particular dungball, > though, having no experience what so ever with iterators, generators or > languages that implement those. (So I'm a C and Python programmar by heart. > Sue me.) It should be sweet and simple. Make it return a list, just like range(). The whole point is that an optimizer can recognize that you are doing "for i in [0:10]: ...", and use a generator anyway -- but that's a thing for later to implement. Also, don't bother with (::) to return an xrange as has been proposed. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From moshez at math.huji.ac.il Fri Jul 14 00:13:49 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 01:13:49 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: On Thu, 13 Jul 2000, Jeremy Hylton wrote: > Two things that each SRFI that PEPs don't yet have are: > > - a mail archive attached to the PEP that contains relevant > discussion. A mail archive seems valuable for people interested in > the next level of detail, but I'm not sure what mechanism to use to > create one. (It also seems valuable because the old "search > dejanews" certainly isn't stable in the long-term.) Maybe PEP > authors could maintain their own archives. I'm sure Roundup is up to this > - a copyright notice. As a strawman, I propose that the owner/author > of each PEP retains copyright, but must publish it under the > OpenContent license, . F**k licenses, they're more trouble then they're worth. Why not simply decree that it must be put in the public domain? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From esr at thyrsus.com Fri Jul 14 00:32:20 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 18:32:20 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: ; from moshez@math.huji.ac.il on Fri, Jul 14, 2000 at 01:03:54AM +0300 References: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: <20000713183220.A6899@thyrsus.com> Moshe Zadka : > I'm currently drawing a list for extensions to include: > > -- zlib > -- Tcl/Tk > -- expat > -- PIL > -- Anything else? > > I really want something with "everything" in it. > > My motivation: I work on quite a few Unixes at work (AIX, Solaris, HP and > probably more to come). Installing Python on any of these is a pain -- > exactly because of the need to download 5-6 packages, and install them > iteratively. I'm with Moshe on this one -- and I'll go further: I think the `rich' distribution ought to be the default mode, and would be willing to take on substantial work to help it happen. I agree with his choice of initial modules, too, and would certainly add ncurses, and would be sorely tempted to add libpng. Moshe's desire is a logical consequence of the "batteries are included" philosophy which is one of Python's central strengths. A good language *ought* to guarantee all its developers and users fuss-free access to a rich kit of state-of-the-art open source tools and libraries. If this means taking on the complexities of tracking several auxiliary libraries and making sure there is a consistent Python API to them as they evolve, so be it. That's our job, gentlemen. -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. From gstein at lyra.org Fri Jul 14 00:27:25 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 15:27:25 -0700 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14701.56551.680037.481536@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 11:14:47AM -0400 References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> Message-ID: <20000713152725.Z29590@lyra.org> On Thu, Jul 13, 2000 at 11:14:47AM -0400, Jeremy Hylton wrote: >... > - a copyright notice. As a strawman, I propose that the owner/author > of each PEP retains copyright, but must publish it under the > OpenContent license, . All right. This just gets me. Why must we assert copyrights on these things? Come on, people. Aren't we seeing Python 2.0 release problems because of copyrights? It isn't like this stuff is Intellectual Property or anything. It's just a summary of where the discussion is! It's a communication mechanism to bring people up to speed on the issues, concerns, and approaches. But something that needs to be copyrighted? Geez. That's just a bit much. Cheers, -g -- Greg Stein, http://www.lyra.org/ From moshez at math.huji.ac.il Fri Jul 14 00:31:35 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 01:31:35 +0300 (IDT) Subject: [Python-Dev] Re: extra packages (was: zlib not compiled by default) In-Reply-To: <20000713153251.A29590@lyra.org> Message-ID: On Thu, 13 Jul 2000, Greg Stein wrote: > On Fri, Jul 14, 2000 at 01:03:54AM +0300, Moshe Zadka wrote: > >... > > I'm currently drawing a list for extensions to include: > > > > -- zlib > > -- Tcl/Tk > > -- expat > > -- PIL > > -- Anything else? > > > > I really want something with "everything" in it. > > Don't forget pure-Python packages. > > I'd also add: mx*, and PyXML Right. The list goes on and on, but I think we can change the world with only 10 packages. and-i'm-forgetting-numpy-which-i-always-wanted-to-be-in-the-core-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Fri Jul 14 00:33:19 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 01:33:19 +0300 (IDT) Subject: [Python-Dev] Re: extra packages (was: zlib not compiled by default) In-Reply-To: <20000713153251.A29590@lyra.org> Message-ID: On Fri, Jul 14, 2000 at 01:03:54AM +0300, Moshe Zadka wrote: > I'm currently drawing a list for extensions to include: > > -- zlib > -- Tcl/Tk > -- expat > -- PIL > -- Anything else? > > I really want something with "everything" in it. Question to PythonLabs team: should I PEP this, or is this considered non-PEPable? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gstein at lyra.org Fri Jul 14 00:32:51 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 15:32:51 -0700 Subject: [Python-Dev] extra packages (was: zlib not compiled by default) In-Reply-To: ; from moshez@math.huji.ac.il on Fri, Jul 14, 2000 at 01:03:54AM +0300 References: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: <20000713153251.A29590@lyra.org> On Fri, Jul 14, 2000 at 01:03:54AM +0300, Moshe Zadka wrote: >... > I'm currently drawing a list for extensions to include: > > -- zlib > -- Tcl/Tk > -- expat > -- PIL > -- Anything else? > > I really want something with "everything" in it. Don't forget pure-Python packages. I'd also add: mx*, and PyXML Cheers, -g -- Greg Stein, http://www.lyra.org/ From jeremy at beopen.com Fri Jul 14 01:09:12 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 19:09:12 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <20000713152725.Z29590@lyra.org> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> Message-ID: <14702.19480.746784.235766@bitdiddle.concentric.net> >>>>> "GS" == Greg Stein writes: GS> It isn't like this stuff is Intellectual Property or GS> anything. It's just a summary of where the discussion is! It's a GS> communication mechanism to bring people up to speed on the GS> issues, concerns, and approaches. This may not be material to the discussion: It's not just a summary of discussion. It's a real proposal, including specification for the feature and rationale for the spec. GS> But something that needs to be copyrighted? Geez. That's just a GS> bit much. I think it stinks, but I'd hate to see distribution of these documents hampered because someone comes along and denies us the right to use it. I'd be satisfied with a statement of copyright or the notice "placed in the public domain" attached to each of them. My only concern is that without some explicit expression of rights, some party might try to prevent us from distributing a PEP. Jeremy From fdrake at beopen.com Fri Jul 14 01:07:21 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 19:07:21 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <20000713152725.Z29590@lyra.org> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> Message-ID: <14702.19369.605446.28207@cj42289-a.reston1.va.home.com> Greg Stein writes: > Why must we assert copyrights on these things? Come on, people. Aren't we > seeing Python 2.0 release problems because of copyrights? No. *Licensing* is distinct from copyright, and that's where we see problems. The copyrights are indisputable, but are not a problem. > It isn't like this stuff is Intellectual Property or anything. It's just a Let's not get into that one! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jul 14 01:11:27 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 13 Jul 2000 19:11:27 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <14702.19480.746784.235766@bitdiddle.concentric.net> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> <14702.19480.746784.235766@bitdiddle.concentric.net> Message-ID: <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > I think it stinks, but I'd hate to see distribution of these documents > hampered because someone comes along and denies us the right to use > it. I'd be satisfied with a statement of copyright or the notice > "placed in the public domain" attached to each of them. The copyright and license are both required to ensure permission to use, distribute, etc. There are a few "open content" licenses, and a reference to one of those should be sufficient. I don't know which one to recommend, however; that would require spending a little time reading them. > My only concern is that without some explicit expression of rights, > some party might try to prevent us from distributing a PEP. You hit that nail! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From m.favas at per.dem.csiro.au Fri Jul 14 01:22:48 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Fri, 14 Jul 2000 07:22:48 +0800 Subject: [Python-Dev] Re: extra packages (was: zlib not compiled by default) Message-ID: <396E4F48.71AD4103@per.dem.csiro.au> I'd like to see Pmw in there as well - and definitely numpy. Whatever _did_ happen to the proposal that it become part of the core...? -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From peter at schneider-kamp.de Fri Jul 14 04:38:33 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 14 Jul 2000 02:38:33 +0000 Subject: [Python-Dev] Pythonb at SourceForge FAQ Message-ID: <396E7D29.7AC68EA6@schneider-kamp.de> I started a small FAQ. Where should I put this? HTML file attached. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From gstein at lyra.org Fri Jul 14 02:45:54 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 13 Jul 2000 17:45:54 -0700 Subject: [Python-Dev] Pythonb at SourceForge FAQ In-Reply-To: <396E7D29.7AC68EA6@schneider-kamp.de>; from peter@schneider-kamp.de on Fri, Jul 14, 2000 at 02:38:33AM +0000 References: <396E7D29.7AC68EA6@schneider-kamp.de> Message-ID: <20000713174554.R29590@lyra.org> Since we don't have ready access to python.org, I would suggest turning on the Python web pages at SF and placing it there. (of course, with obvious links from python.sourceforge.net to python.org) Having a FAQ about Python/SF at SF makes sense to me :-) Cheers, -g On Fri, Jul 14, 2000 at 02:38:33AM +0000, Peter Schneider-Kamp wrote: > I started a small FAQ. Where should I put this? > > HTML file attached. > > Peter > -- > Peter Schneider-Kamp ++47-7388-7331 > Herman Krags veg 51-11 mailto:peter at schneider-kamp.de > N-7050 Trondheim http://schneider-kamp.de > > Python at SourceForge - Frequently Asked Questions > > 0. Contents > > [1]1. General > > 1. [2]What is SourceForge? > 2. [3]Where do I find Python there? > > [4]2. CVS > > 1. [5]How do I check out a CVS version of Python? > 2. [6]What settings should I use? > 3. [7]Troubleshooting: "Permission Denied" > 4. [8]Where can I learn more about CVS? > > [9]3. Patches > > 1. [10]How to make a patch? > 2. [11]How to submit patches? > 3. [12]How to change the status of a patch? > > [13]A. Appendix > > 1. [14]Patch Manager Guidelines [09.07.2000] > 2. [15]Python Patch Submission Guidelines [29.06.2000] > > 1. General > > 1.1.: > > Q: What is SourceForge? > > A: > > [16]SourceForge is a free hosting service for [17]OpenSource projects. > The main website is found at > > [18]http://sourceforge.net > > 1.2.: > > Q: Where can I find Python on SourceForge? > > A: > > The [19]Python project page can be found at > > [20]http://sourceforge.net/projects/python > > 2. CVS > > 2.1.: > > Q: How do I check out a CVS version of Python? > > A: > > If you are not a SourceForge-recognized Python developer you can > still check out an anonymous CVS version (read-only) of Python: > > export > CVSROOT=:pserver:anonymous at cvs.python.sourceforge.net:/cvsroot/pyth > on > cvs login > cvs -z3 co python > > If you are indeed a developer you can check out a read/write version > with ssh: > > export CVS_RSH=ssh > export > CVSROOT=sf_username at cvs.python.sourceforge.net:/cvsroot/python > cvs -z3 co python > > 2.2.: > > Q: What setting should I use? > > A: > > That is, of course, hard to answer in the general case. I use the > following .cvsrc file: > > diff -c > update -d > > This defaults diff to context diffs (almost a requirement as > everything else is harder to read) and tells update to automatically > checkout new subdirectories. > > 2.3.: > > Q: I get the following error message: > > Sorry, you don't have read/write access to the history file > /cvsroot/python/CVSROOT/history > Permission denied > > A: > > If you are not a developer, you don't have read/write access. You have > to check out an anonymous copy. If you are a developer you have to be > in the SourceForge group "python". You can check this with the > following commands: > > ssh -l sf_username shell.sourceforge.net > groups > > If you have just recently (< 6 hours) been added to the Python > project, you probably have to wait for the SourceForge servers to > synch up. This can take up to 6 hours. > > 2.4.: > > Q: Where can I learn more about CVS? > > A: > > For SourceForge specific information consult their CVS documentation > at > > [21]http://sfdocs.sourceforge.net/sfdocs > > For general (and more advanced) information consult the free CVS Book > at > > [22]http://cvsbook.red-bean.com/cvsbook.html#Introduction > > 3. Patches > > 3.1.: > > Q: How to make a patch? > > A: > > If you are using CVS (anonymous or developer) you can use CVS to make > the patches for you. Just edit your local copy and enter the following > command: > > cvs diff | tee ~/name_of_the_patch.diff > > Else you can use the diff util which comes with most operating systems > (a Windows version is available as part of the cygwin tools). > > > 3.2.: > > Q: How to submit a patch? > > A: > > Please read the [23]Patch Submission Guidelines at > > [24]http://www.python.org/patches > > A [25]recent copy can be found in the Appendix of this FAQ. > > > 3.3.: > > Q: How to change the status of a patch? > > A: > > To change the status of a patch or assign it to somebody else you have > to be a) a SourceForge-recognized Python developer and b) a patch > administrator. Unfortunately the SourceForge default for developers is > not to be patch administrators. Contact one of the project > administrators if the following does not work for you. > > Click on the patch itself. In the screen that comes up, there is a > drop-box for "Assigned To:" and a drop-box for "Status:" where you can > select a new responsible developer or a new status respectively. After > selecting the appropriate victim and status, hit the "Submit Changes" > button at the bottom of the page. > > For more information about the use of the "Status:" and "Assigned To:" > fields consult the [26]Patch Manager Guidelines. A recent copy can be > found in the Appendix of this FAQ. > > A. Appendix > > A.1.: Patch Manager Guidelines > > Intended use of SourceForge patch status & "assigned to" fields > > revision 2 09-Jul-2000 > > In general, the status field should be close to self-explanatory, and > the "Assigned to:" field should be the person responsible for taking > the next step in the patch process. Both fields are expected to > change value over the life of a patch; the normal workflow is detailed > below. > > When you've got the time and the ability, feel free to move any patch > that catches your eye along, whether or not it's been assigned to > you. And if you're assigned to a patch but aren't going to take > reasonably quick action (for whatever reason), please assign it to > someone else ASAP: at those times you can't actively help, actively > get out of the way. > > If you're an expert in some area and know that a patch in that area is > both needed and non-controversial, just commit your changes directly > -- no need then to get the patch mechanism involved in it. > > You should add a comment to every patch assigned to you at least once > a week, if only to say that you realize it's still on your plate. > This rule is meant to force your attention periodically: patches get > harder & harder to deal with the longer they sit. > > Open > > The initial status of all patches. > The patch is under consideration, but has not been reviewed yet. > The status will normally change to Accepted or Rejected next. > The person submitting the patch should (if they can) assign it to > the person they most want to review it. > Else the patch will be assigned via [xxx a list of expertise areas > should be developed] [xxx but since this hasn't happened and > volunteers are too few, random assignment is better than nothing: > if you're a Python developer, expect to get assigned out of the > blue!] > Discussion of major patches is carried out on the Python-Dev > mailing list. For simple patches, the SourceForge comment > mechanism should be sufficient. [xxx an email gateway would be > great, ditto Ping's Roundup] > > Accepted > > The powers that be accepted the patch, but it hasn't been applied > yet. [xxx flesh out -- Guido Bottleneck avoidable here?] > The status will normally change to Closed next. > The person changing the status to Accepted should, at the same > time, assign the patch to whoever they believe is most likely to be > able & willing to apply it (the submitter if possible). > > Closed > > The patch has been accepted and applied. > The previous status was Accepted, or possibly Open if the submitter > was Guido (or moral equivalent in some particular area of > expertise). > > Rejected > > The patch has been reviewed and rejected. > When the objections are addressed, the status may change to Open > again. > The person changing the status to Rejected should assign the patch > back to the submitter, or if it's clear the patch will never be > accepted, assign it to None. > Note that SourceForge allows the submitter to overwrite the patch > with a new version. > > Out of date > > Previous status was Open or Accepted or Postponed, but the patch no > longer works. > Please enter a comment when changing the status to "Out of date", > to record the nature of the problem and the previous status. > Also assign it back to the submitter, as they need to upload a new > version (note that SourceForge will not allow anyone other than the > original submitter to update the patch). > > Postponed > > The previous status was Open or Accepted, but for some reason > (e.g., pending release) the patch should not be reviewed or applied > until further notice. > The status will normally change to Open or Accepted next. > Please enter a comment when changing the status to Postponed, to > record the reason, the previous status, and the conditions under > which the patch should revert to Open or Accepted. Also assign the > patch to whoever is most likely able and willing to decide when the > status should change again. > > Deleted > > Bit bucket. > Use only if it's OK for the patch and its SourceForge history to > disappear. > As of 09-July-2000, SF does not actually throw away Deleted > patches, but that may change. > > A.2.: Python Patch Submission Guidelines > > New: CNRI is no longer involved in Python patches. We no longer > request legal disclaimers. Also, We're now using the SourceForge Patch > Manager (a single mailing list became unmanageable). > > Many people contribute patches to Python. We've set up a new system to > deal with these. Here are the main guidelines: > * Submit your patch to the [27]patch manager interface at > [28]SourceForge. We strongly recommend that you [29]register with > SourceForge before submitting a patch. If you send patches > directly to Guido you introduce an extra delay. Ditto for the > "patches at python.org" mailing list address; this address should no > longer be used for patch submission. The patch manager is for > patches only; if you have a problem or suggestion but don't know > how to write the code for it, use the [30]Python Bugs List > instead. The bugs list is searchable; if you have a problem and > you're not sure if it has been reported or fixed already, this is > the first place to look. (There used to be a separate TODO list; > we now prefer that you use the bugs list for suggestions and > requests too.) > > > Submit documentation patches the same way. When adding the patch, > be sure to set the "Category" field to "documentation". For > documentation errors without patches, please use the [31]Python > Bugs List instead. > * We like context diffs. We grudgingly accept unified diffs. > Straight ("ed-style") diffs are right out! If you don't know how > to generate context diffs, you're probably not qualified to > produce high-quality patches anyway <0.5 wink>. > * We appreciate it if you send patches relative to the [32]current > CVS tree. These are our latest sources. It's almost a year since > Python 1.5.2 was released, and many source files have been touched > in more or less significant ways; a patch relative to Python 1.5.2 > can cause a lot of extra pain to apply right. Even a patch > relative to the latest alpha or beta release may be way out of > date. > * Please add a succinct message to your SourceForge entry that > explains what the patch is about that we can use directly as a > checkin message. Ideally, such a message explains the problem and > describes the fix in a few lines. > * For patches that add or change functionality: please also update > the documentation and the testcases (the Lib/test subdirectory). > For new modules, we appreciate a new test module (typically > test/test_spam.py). In this case, there's no need to mail the > documentation to a different address (in fact, in order to verify > that the bundle is complete, it's easier to mail everything > together). > * There are a variety of additional [33]style requirements. Please > have a look at these before writing new code. Also have a look at > the general [34]Python Style Guide. > > References > > 1. file://localhost/tmp/sf-faq.html#general > 2. file://localhost/tmp/sf-faq.html#g1 > 3. file://localhost/tmp/sf-faq.html#g2 > 4. file://localhost/tmp/sf-faq.html#cvs > 5. file://localhost/tmp/sf-faq.html#c1 > 6. file://localhost/tmp/sf-faq.html#c2 > 7. file://localhost/tmp/sf-faq.html#c3 > 8. file://localhost/tmp/sf-faq.html#c4 > 9. file://localhost/tmp/sf-faq.html#patches > 10. file://localhost/tmp/sf-faq.html#p1 > 11. file://localhost/tmp/sf-faq.html#p2 > 12. file://localhost/tmp/sf-faq.html#p3 > 13. file://localhost/tmp/sf-faq.html#appendix > 14. file://localhost/tmp/sf-faq.html#a1 > 15. file://localhost/tmp/sf-faq.html#a2 > 16. http://sourceforge.net/ > 17. http://opensource.org/ > 18. http://sourceforge.net/ > 19. http://sourceforge.net/projects/python > 20. http://sourceforge.net/projects/python > 21. http://sfdocs.sourceforge.net/sfdocs > 22. http://cvsbook.red-bean.com/cvsbook.html#Introduction > 23. http://www.python.org/patches > 24. http://www.python.org/patches > 25. file://localhost/tmp/sf-faq.html#a2 > 26. file://localhost/tmp/sf-faq.html#a1 > 27. http://sourceforge.net/patch/?group_id=5470 > 28. http://sourceforge.net/project/?group_id=5470 > 29. http://sourceforge.net/account/register.php > 30. http://www.python.org/search/search_bugs.html > 31. http://www.python.org/search/search_bugs.html > 32. http://sourceforge.net/cvs/?group_id=5470 > 33. http://www.python.org/patches/style.html > 34. http://www.python.org/doc/essays/styleguide.html -- Greg Stein, http://www.lyra.org/ From jeremy at beopen.com Fri Jul 14 02:59:40 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 20:59:40 -0400 (EDT) Subject: [Python-Dev] Pythonb at SourceForge FAQ In-Reply-To: <396E7D29.7AC68EA6@schneider-kamp.de> References: <396E7D29.7AC68EA6@schneider-kamp.de> Message-ID: <14702.26108.53369.420712@bitdiddle.concentric.net> You could check it into the Python distribution under Misc. I can arrange for it to be displayed at pythonlabs.com. Jeremy From peter at schneider-kamp.de Fri Jul 14 05:26:04 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 14 Jul 2000 03:26:04 +0000 Subject: http://python.sourceforge.net (was: Re: [Python-Dev] Pythonb at SourceForge FAQ) References: <396E7D29.7AC68EA6@schneider-kamp.de> <20000713174554.R29590@lyra.org> Message-ID: <396E884C.B55E4737@schneider-kamp.de> Hi Greg! I made a small link page (to python.org, sourceforge.net/projects/python and sf-faq.html) and loaded it up together with the faq (sf-faq.html). Anyone with a bit more feeling for design than me should feel free to improve it. Peter Greg Stein wrote: > > Since we don't have ready access to python.org, I would suggest turning on > the Python web pages at SF and placing it there. > > (of course, with obvious links from python.sourceforge.net to python.org) > > Having a FAQ about Python/SF at SF makes sense to me :-) > > Cheers, > -g -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From huaiyu_zhu at yahoo.com Fri Jul 14 03:30:02 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Thu, 13 Jul 2000 18:30:02 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] Message-ID: Paul Prescod wrote: > I think that the idea is that you could install new syntaxes in the same > way you install new modules...of course only after careful > consideration!!! This is much more than I has bargained for. Separting syntax with sematics is really the way to go. > I'm not entirely against your proposal but you've got to expect major > pushback on such large-scale syntax and semantic changes. Well, I was only asking for some additional operators, which wouldn't affect a single line of existing code. Everyone says no you can't get it, that's too much, but on the other hand you should get a parser to change the syntax anyway you want. So if I ask more I shall get the bit I wanted. When would this wonderful new parser be available so that I can change the syntax beyond recognition? :-) > > Look it this way. Text processing do have their special syntaxes. > > Okay, but probably 90% of Python programmers do text processing at some > point. Not so for matrix calculation. You believe that the Python world > would grow greatly if we did matrices natively. I don't know if I > believe that. I don't believe python should be bond to this heritage as much as perl does. Maybe those who do matrix have not joined yet. To justify support by the number of existing users sounds like a self-fulfilling prophacy. Think about how many users would do text precessing if they have to write regular expressions as layers of composite functions? How many would use arithmetic if they have to write add(mul(1,2),div(2.,3.))? Now compare what's written in matlab/octave (X'*X)\(X'*y) with what's written in python matrixmultiply(inverse(matrixmultiply(transpose(X), X)), (matrixmultiply(transpose(X), y[:,NewAxis]))) Now look at the total number of users of matlab/octave, and ask: Is python really so inferior that most of them wouldn't switch to python? To change this status does not even need native support of matrix. The only thing required is that there be enough binary operators to be overridden by applications - any application that needs additional binary operators. > > PS. I suppose I am allowed to post to python-dev without invitation, but > > not subscribing to it? I find this rather strange. > > Yes, it is rather strange. But I can see its use now. I have to get your reply from web and cut and paste in order to reply again. :-( Huaiyu From peter at schneider-kamp.de Fri Jul 14 05:29:59 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 14 Jul 2000 03:29:59 +0000 Subject: [Python-Dev] Pythonb at SourceForge FAQ References: <396E7D29.7AC68EA6@schneider-kamp.de> <14702.26108.53369.420712@bitdiddle.concentric.net> Message-ID: <396E8937.6FA299D2@schneider-kamp.de> Jeremy Hylton wrote: > > You could check it into the Python distribution under Misc. I can > arrange for it to be displayed at pythonlabs.com. Been there, done that. Following Greg's advice I put it up on http://python.sourceforge.net. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul at prescod.net Fri Jul 14 00:44:29 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 17:44:29 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> <14702.19480.746784.235766@bitdiddle.concentric.net> <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> Message-ID: <396E464D.F6D841ED@prescod.net> "Fred L. Drake, Jr." wrote: > > ... > > The copyright and license are both required to ensure permission to > use, distribute, etc. There are a few "open content" licenses, and a > reference to one of those should be sufficient. I don't know which > one to recommend, however; that would require spending a little time > reading them. Let me recommend my favorite: "Placed in the public domain." -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 00:48:38 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 17:48:38 -0500 Subject: [Python-Dev] [PEP204] Range Literals References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> Message-ID: <396E4746.DE25EFD4@prescod.net> Guido van Rossum wrote: > > ... > It should be sweet and simple. Make it return a list, just like > range(). The whole point is that an optimizer can recognize that you > are doing "for i in [0:10]: ...", and use a generator anyway -- but > that's a thing for later to implement. > > Also, don't bother with (::) to return an xrange as has been proposed. If Guido has decided that the design that has already been implemented is the right one, what's the point of the PEP? Someone just needs to review the patch and check it in! -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 00:48:39 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 17:48:39 -0500 Subject: [Python-Dev] [PEP204] Range Literals References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> Message-ID: <396E4747.9D055A96@prescod.net> Guido van Rossum wrote: > > .. > > It should be sweet and simple. Make it return a list, just like > range(). The whole point is that an optimizer can recognize that you > are doing "for i in [0:10]: ...", and use a generator anyway -- but > that's a thing for later to implement. Why disallow this: fives=[0:maxint:5] As Fred points out, we've already got the underlying object implementation in the src! MAL also pointed out that immutable objects (like xranges) can be safely precomputed and reused. Finally, whatever the answer is, it should probably be the same as list comprehensions. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 00:49:12 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 17:49:12 -0500 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <396E4768.A77473AA@prescod.net> Huaiyu Zhu wrote: > > ... > > So if I ask more I shall get the bit I wanted. When would this wonderful > new parser be available so that I can change the syntax beyond recognition? > :-) It all depends on who works on it and how hard they work. I really can't predict. There some Python features that I thought were years away and appeared from nowhere (cyclic gc) and others that seem perpetually on the verge of being available (e.g. a compiler that achieves order of magnitude performance improvements). If I had to pick a version number out of the wind I would say 2.1 or 2.2. I would predict the same timeline for any new operators. By the way, there is already a language specifically designed to allow people with particular interests to extend the syntax fairly arbitrarily. It is called REBOL. I think TCL is also a little more forgiving about syntactic variance. There may be others. > I don't believe python should be bond to this heritage as much as perl does. > Maybe those who do matrix have not joined yet. To justify support by the > number of existing users sounds like a self-fulfilling prophacy. It isn't the existing users. It's the users that we see around us. I don't remember anyone ever asking me for help using Python for matrices, at any company I have ever worked at. Obviously you live in a different world. Either of our perceptions could be skewed. Perhaps the best bet would be for you to make a matrix variant of Python so popular that we could see the audience in terms of downloads and discussions. > Now compare what's written in matlab/octave > > (X'*X)\(X'*y) > > with what's written in python > > matrixmultiply(inverse(matrixmultiply(transpose(X), X)), > (matrixmultiply(transpose(X), y[:,NewAxis]))) There must be a more compact syntax! Even without knowing the semantics: from matrix import tickmult, backslash backslash( tickmult( X, X ), tickmult( X, y )) > Now look at the total number of users of matlab/octave, and ask: Is python > really so inferior that most of them wouldn't switch to python? I have no idea. If the primary difference between expensive matrix packages and Python is syntax, perhaps you and I should incorporate and exploit that market inefficiency. :) > To change this status does not even need native support of matrix. The only > thing required is that there be enough binary operators to be overridden by > applications - any application that needs additional binary operators. Michael Hudson has a tagline that made me laugh out loud: I saw `cout' being shifted "Hello world" times to the left and stopped right there. -- Steve Gonedes He's talking about the random-seeming overloadings you get in C++ because there are so many overloadable operators and they are so poorly defined. Anyhow, what if I want a different syntax for the XML operators. "->" and "<-" might be useful. I am half-tempted to suggest a system where anyone could add new operators, perhaps in quotes or back-ticks or something but I am very afraid of what happens when the people who evented "cout shifting" get their hands on it! > But I can see its use now. I have to get your reply from web and cut and > paste in order to reply again. :-( How long until some enterprising Python programmer makes a utility that polls the website, and generates an email version of each message as it appears? :) -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From jeremy at beopen.com Fri Jul 14 04:28:10 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 13 Jul 2000 22:28:10 -0400 (EDT) Subject: [Python-Dev] urllib vs. cgi Message-ID: <14702.31418.483935.810948@bitdiddle.concentric.net> I was doing a little Web programming this evening and discovered an annoying asymmetry. The urllib module has a urlencode function that translates a dictionary of form entries into a URL query string. I wanted the inverse "urldecode" that turns the query string into the dictionary. There isn't one. But I guessed that CGI programmers had to have a function to do this! It seems there is one called cgi.parse_qs. This wasn't an obvious place to look, because I wasn't doing CGI programming at all. (I was writing a screen-scraped for SourceForge.) Any opinions on adding a symmetrical urldecode to urllib? I'm not thrilled by duplicating code, but the cgi module is big and hairy and urllib seems like the obvious place for it. Jeremy From esr at thyrsus.com Fri Jul 14 04:44:10 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 22:44:10 -0400 Subject: [Python-Dev] urllib vs. cgi In-Reply-To: <14702.31418.483935.810948@bitdiddle.concentric.net>; from jeremy@beopen.com on Thu, Jul 13, 2000 at 10:28:10PM -0400 References: <14702.31418.483935.810948@bitdiddle.concentric.net> Message-ID: <20000713224410.A7548@thyrsus.com> Jeremy Hylton : > Any opinions on adding a symmetrical urldecode to urllib? I'm not > thrilled by duplicating code, but the cgi module is big and hairy and > urllib seems like the obvious place for it. +0. It doesn't thrill me, but I can't argue with your analysis either. -- Eric S. Raymond The two pillars of `political correctness' are, a) willful ignorance, and b) a steadfast refusal to face the truth -- George MacDonald Fraser From esr at snark.thyrsus.com Fri Jul 14 04:46:37 2000 From: esr at snark.thyrsus.com (Eric S. Raymond) Date: Thu, 13 Jul 2000 22:46:37 -0400 Subject: [Python-Dev] ConfigParser changes Message-ID: <200007140246.WAA07574@snark.thyrsus.com> I've seen a couple plus responses to my proposed ConfigParser enhancements, no minuses, and the thread has petered out. If nobody hands me a -1, I'm going to merge them in in a day or so. Speak now... -- Eric S. Raymond "The state calls its own violence `law', but that of the individual `crime'" -- Max Stirner From bwarsaw at beopen.com Fri Jul 14 05:57:09 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 23:57:09 -0400 (EDT) Subject: [Python-Dev] Re: extra packages (was: zlib not compiled by default) References: <20000713153251.A29590@lyra.org> Message-ID: <14702.36757.14686.842685@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> Question to PythonLabs team: should I PEP this, or is this MZ> considered non-PEPable? I think it /is/ worth a PEP and have assigned #206 to you Moshe. -Barry From bwarsaw at beopen.com Fri Jul 14 05:59:38 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 13 Jul 2000 23:59:38 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: <14702.36906.418249.461209@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I'm currently drawing a list for extensions to include: | -- zlib For sure. | -- Tcl/Tk I've always wanted it in every Python distribution I build, and this one in particular is a pain to add. | -- expat | -- PIL | -- Anything else? readline. My fear is that these extension modules might end up like pcre though. We start with the standard stuff and then start to slowly fork it as we find we need extras. Then we're stuck maintaining our version separately and folding in patches as the original moves forward. Yuck. Does distutils come to the rescue here? Am I being overly paranoid? -Barry From moshez at math.huji.ac.il Fri Jul 14 06:05:05 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 07:05:05 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14702.36906.418249.461209@anthem.concentric.net> Message-ID: On Thu, 13 Jul 2000, Barry A. Warsaw wrote: [about libraries to distribute with Python] > | -- Anything else? > > readline. -1 on that. I just thought of that before I got out of bed, and decided putting something GPLed there might be trouble. > My fear is that these extension modules might end up like pcre > though. We start with the standard stuff and then start to slowly > fork it as we find we need extras. Then we're stuck maintaining our > version separately and folding in patches as the original moves > forward. Yuck. Well, we managed writing Tcl/Tk wrappers without changing Tcl/Tk. Why should it be different if it's in the source distribution? The temptation? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From bwarsaw at beopen.com Fri Jul 14 06:06:43 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 14 Jul 2000 00:06:43 -0400 (EDT) Subject: [Python-Dev] [PEP204] Range Literals References: <20000713235356.X7340@xs4all.nl> Message-ID: <14702.37331.302346.67441@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> As I already wrote Barry, I'll do this one -- but only if it's TW> a no-brainer. The patch is already written and I hadn't heard TW> complaints about the syntax, but now I hear some rumbling TW> about how it should be a generator instead of a list TW> constructor. I don't feel like digging into that particular TW> dungball, though, having no experience what so ever with TW> iterators, generators or languages that implement those. (So TW> I'm a C and Python programmar by heart. Sue me.) TW> That isn't to say I think it's a bad idea, not at all. I just TW> don't want to do it :-) But if anyone else wants to implement TW> it, and do so before 2.0, yell now, and you can take over the TW> entire range-literal thing as well. Thomas, it would be wonderful if you could write up what you already know about range literals. Feel free to sprinkle `TBD's (to be done, or to be decided) in places you're uncomfortable about. We'll worry about filling those in or re-assigning later. -Barry P.S. I'd rather use TBD than XXX as is the Dutch convention. The USA is much more prudish than the Europeans, and I'd hate for our PEPs to get blocked from all those Python 8 year olds accessing our documents from the public libraries. :) From bwarsaw at beopen.com Fri Jul 14 06:09:48 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 14 Jul 2000 00:09:48 -0400 (EDT) Subject: [Python-Dev] [PEP204] Range Literals References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> <396E4747.9D055A96@prescod.net> Message-ID: <14702.37516.832386.689911@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Why disallow this: PP> fives=[0:maxint:5] PP> As Fred points out, we've already got the underlying object PP> implementation in the src! PP> MAL also pointed out that immutable objects (like xranges) can PP> be safely precomputed and reused. PP> Finally, whatever the answer is, it should probably be the PP> same as list comprehensions. This is why you want a PEP, Paul! -Barry From bwarsaw at beopen.com Fri Jul 14 06:37:27 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 14 Jul 2000 00:37:27 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default References: <14702.36906.418249.461209@anthem.concentric.net> Message-ID: <14702.39175.2260.890343@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> -1 on that. I just thought of that before I got out of bed, MZ> and decided putting something GPLed there might be trouble. Ah, good point. I keep forgetting about that :) -Barry From paul at prescod.net Fri Jul 14 06:06:52 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 23:06:52 -0500 Subject: [Python-Dev] Request for Opinions Message-ID: <396E91DC.D767EF6F@prescod.net> I don't want to PEP this, I want to discuss it. In fact, I think we are supposed to discuss it four more times before I PEP it. And Tim has to participate in each discussion, right? There is a language called "XPath" for navigating XML trees. It makes your life a lot easier. XPath is to XML trees as SQL is to relational databases. Imagine working with relational databases by looping over records with no query language! I think that some portion of XPath should go into Python 2. 4Thought has a large, sophisticated implementation of the entire XPath language. They use Bison (not PyBison!) and FLEX for parsing performance. I guess there is about 2000 lines of C/yacc. The resulting binary is XXX. There is also about 2000 lines of Python code. On the one hand, this strikes me as a lot of code for one subpackage (xpath) of a package (xml). On the other hand, XPath is pretty stable so once the code is done, it is pretty stable and also self contained. It wasn't something we invented and will be tweaking forever. Rather it is a simple API to something relatively static. (XPath has extension mechanisms so it can solve new problems without growing syntactically) Is this an appropriate extension to Python, like pyexpat? We have three options: 1. use the relatively large 4XPath as is 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) that can be implemented in a couple of hundred lines of Python code (this code is mostly done already, in a module called TinyXPath) 3. try to scale 4XPath back by moving its parser to SRE, and making some of its features "options" that can be added separately (not clear how easy this is) What do you think? -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov at inrialpes.fr Fri Jul 14 06:47:43 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 14 Jul 2000 06:47:43 +0200 (CEST) Subject: [Python-Dev] test_extcall Message-ID: <200007140447.GAA28593@python.inrialpes.fr> test_extcall.py contains the following code generating a cycle that cannot be broken explicitely: ... # what about willful misconduct? def saboteur(**kw): kw['x'] = locals() <-- yields cyclic kw: {'x': {'kw': {...}}, 'a': 1} d = {} saboteur(a=1, **d) ... Whoever wrote this test: is locals() absolutely necessary? Also, is there a good reason for not implementing GC for module objects? They are containers after all... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Fri Jul 14 07:16:32 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 14 Jul 2000 07:16:32 +0200 (CEST) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396E91DC.D767EF6F@prescod.net> from "Paul Prescod" at Jul 13, 2000 11:06:52 PM Message-ID: <200007140516.HAA28633@python.inrialpes.fr> Paul Prescod wrote: > > We have three options: > > 1. use the relatively large 4XPath as is > > 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) > that can be implemented in a couple of hundred lines of Python code > (this code is mostly done already, in a module called TinyXPath) > > 3. try to scale 4XPath back by moving its parser to SRE, and making > some of its features "options" that can be added separately (not clear > how easy this is) > > What do you think? Well, I think that the code you're talking about fits best the 4Suite and, for the moment, as a user I would download and install the whole suite from FourThought. You're talking about XPath, but there are also XLink, XPointer, XML Base and other incoming X'es. What's the motivation behind decoupling 4XPath from the 4Suite and making a second (eventually smaller) version of it for the Python lib? I don't really see the point (note: I haven't followed the XML-SIG lately). I'd like to see this discussion focusing on more ambitious goals, like including and providing support for a complete, rich and up to date XML package, which is what the 4Suite basically is. I'm not sure we're ready to discuss this right now, though, so I'd suggest to PEP it anyway. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Mark.Favas at per.dem.csiro.au Fri Jul 14 07:18:42 2000 From: Mark.Favas at per.dem.csiro.au (Favas, Mark (EM, Floreat)) Date: Fri, 14 Jul 2000 13:18:42 +0800 Subject: [Python-Dev] FW: Unicode character name hashing Message-ID: Forgot to copy Python-Dev... -----Original Message----- From: Mark Favas [mailto:m.favas at per.dem.csiro.au] Sent: Friday, 14 July 2000 7:00 AM To: Bill Tutt Subject: Re: Unicode character name hashing Just tried it, and got the same message: test_ucn test test_ucn crashed -- exceptions.UnicodeError : Unicode-Escape decoding error: Invalid Unicode Character Name Cheers, Mark Bill Tutt wrote: > > Does this patch happen to fix it? > I'm afraid my skills relating to signed overflow is a bit rusty... :( > > Bill > > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/ucnhash.c,v > retrieving revision 1.2 > diff -u -r1.2 ucnhash.c > --- ucnhash.c 2000/06/29 00:06:39 1.2 > +++ ucnhash.c 2000/07/13 21:41:07 > @@ -30,12 +30,12 @@ > > len = cch; > p = (unsigned char *) key; > - x = 1694245428; > + x = (long)0x64fc2234; > while (--len >= 0) > - x = (1000003*x) ^ toupper(*(p++)); > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); > x ^= cch + 10; > - if (x == -1) > - x = -2; > + if (x == (long)0xFFFFFFFF) > + x = (long)0xfffffffe; > x %= k_cHashElements; > /* ensure the returned value is positive so we mimic Python's % > operator */ > if (x < 0) > @@ -52,12 +52,12 @@ > > len = cch; > p = (unsigned char *) key; > - x = -1917331657; > + x = (long)0x8db7d737; > while (--len >= 0) > - x = (1000003*x) ^ toupper(*(p++)); > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); > x ^= cch + 10; > - if (x == -1) > - x = -2; > + if (x == (long)0xFFFFFFFF) > + x = (long)0xfffffffe; > x %= k_cHashElements; > /* ensure the returned value is positive so we mimic Python's % > operator */ > if (x < 0) > > -----Original Message----- > From: Mark Favas [mailto:m.favas at per.dem.csiro.au] > Sent: Thursday, July 13, 2000 1:16 PM > To: python-dev at python.org; Bill Tutt > Subject: Unicode character name hashing > > [Bill has epiphany] > >I just had a rather unhappy epiphany this morning. > >F1, and f2 in ucnhash.c might not work on machines where sizeof(long) >!= > 32 bits. > > I get the following from test_ucn on an Alpha running Tru64 Unix: > > python Lib/test/test_ucn.py > UnicodeError: Unicode-Escape decoding error: Invalid Unicode Character > Name > > This is with the current CVS - and it's been failing this test for some > time now. I'm happy to test any fixes... > > -- > Email - m.favas at per.dem.csiro.au Mark C Favas > Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining > Fax - +61 8 9383 9891 Private Bag No 5, Wembley > WGS84 - 31.95 S, 115.80 E Western Australia 6913 -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From huaiyu_zhu at yahoo.com Fri Jul 14 07:53:38 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Thu, 13 Jul 2000 22:53:38 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <396E4768.A77473AA@prescod.net> Message-ID: On Thu, 13 Jul 2000, Paul Prescod wrote: > It all depends on who works on it and how hard they work. I really can't So can some one answer this question for sure: Is it definitely possible to introduce .* ./ etc without much more difficulty than introducing @* and @/ and so on? If this is the case we do not need a new symbol. > Perhaps the best bet would be for you to make a matrix variant of Python > so popular that we could see the audience in terms of downloads and > discussions. That's exact what I'm doing. By far the largest hurdle to MatPy was the lack of binary operators. 2/3 of user discussions is on the the most economic usage of existing symbols. 1/3 of discussion is on how to make it work on Windows, because of relative imports and case insensitivity. To attract users I really need to let octave users know its existence, but this would be futile before we get symbols for both matrix and element operations. Here are a few indications of user support. Some Windows users have enthusiastically followed it for more than a month despite having to rename several files and change module names for each release. It was only fixed last weekend. I'd regard this as a testament of its usefulness and potential. People have also hacked the python parser and the interactive interpreter to support additional features. Some have also promised to supply additional C implementations of numerical procedures. All I had promised for this was to make an easy interface for matrix computation that works with Python, for my own use. Right now the only remaining hurdle to this goal is the lack of suitable symbols, and we are on the verge of overcoming it. > There must be a more compact syntax! Even without knowing the semantics: > > from matrix import tickmult, backslash > backslash( tickmult( X, X ), tickmult( X, y )) You are almost there. :-) The current MatPy expression is solve (X.H() * X, X.H() * y) > > Now look at the total number of users of matlab/octave, and ask: Is python > > really so inferior that most of them wouldn't switch to python? > > I have no idea. If the primary difference between expensive matrix > packages and Python is syntax, perhaps you and I should incorporate and > exploit that market inefficiency. :) The market is efficient. Matlab does worth that much (or even more). It does take that much human labor to get to that stage, so sadly we can't get rich by following them. On the other hand, open source may beat them easily, as long as 1. we are using a better language which has more potential 2. users have incentive to contribute because it's already useful 3. there's no big hurdle beyond what's already in Numerical Recipe I'm sure I can recruit enough developers to solve any numerical problem, as long as you don't ask them to hack the python parser! That's what I ask the python developers for. > Michael Hudson has a tagline that made me laugh out loud: > > I saw `cout' being shifted "Hello world" times to the left and > stopped right there. > -- Steve Gonedes If this was a notation used in a century's worth of mathemetical papers, it might not seem that strange. Could C++ stream IO ever make into just one mainstream math paper? > How long until some enterprising Python programmer makes a utility that > polls the website, and generates an email version of each message as it > appears? :) The same length of time that takes an enterprising Python programmer to find the principal axes of a set of data using eigen decomposition. :-) think-domain-specific-ly y'rs Huaiyu From tim_one at email.msn.com Fri Jul 14 08:15:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 14 Jul 2000 02:15:27 -0400 Subject: [Python-Dev] Windows build broken in exceptions.c In-Reply-To: <00c401bfebd9$e6d347e0$f2a6b5d4@hagrid> Message-ID: >> exceptions.c(93) : error C2026: string too big, trailing characters >> truncated [Fredrik Lundh Sent: Wednesday, July 12, 2000 4:19 AM] > but back to the original topic: what does the ANSI standard > say about this? A conforming C compiler isn't required to accept string literals longer than 509 characters (and that's *after* concatenating adjacent strings). An excellent summary (although not a rationale) can be found here: http://www-ccs.ucsd.edu/c/portable.html Read it carefully, and my bet is you'll realize you've never seen a portable C program! For example, ever #include a file whose basename was longer than 6 characters or used mixed case? Then you're in the unsupported fast lane . > what is, for example, the limits for integer arrays? There are (small!) limits both on physical source lines and on the size of initialized objects. See the above and *you* try to figure it out . > (my unicode database experiments results in a couple of big > ones. and for best performance, they really have to be that > big...) The std guarantees only the feeblest of compile-time abilities, so you're (the generic "you", i.e. "us") very unlikely to write this stuff in a way the std guarantees will work. But it's not worth worrying about (within reason), until we hit an actual compiler that complains. The only way to be completely sure is to stick to tiny compile-time entities and paste them together at runtime. and-even-then-it's-not-really-sure-ly y'rs - tim From mwh21 at cam.ac.uk Fri Jul 14 08:21:13 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 14 Jul 2000 07:21:13 +0100 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: bwarsaw@beopen.com's message of "Fri, 14 Jul 2000 00:37:27 -0400 (EDT)" References: <14702.36906.418249.461209@anthem.concentric.net> <14702.39175.2260.890343@anthem.concentric.net> Message-ID: bwarsaw at beopen.com (Barry A. Warsaw) writes: > >>>>> "MZ" == Moshe Zadka writes: > > MZ> -1 on that. I just thought of that before I got out of bed, > MZ> and decided putting something GPLed there might be trouble. > > Ah, good point. I keep forgetting about that :) It's been one of those things that "I will get round to sometime" for a long while now to write a (PD) replacement line editor in Python (thinking partly that it would be nice not to be "encumbered" by the GPL and that if it was written in a suitable style it might be possible to make it more "hookable" and provide eg. fancier completion). Unfortunately I know nothing about any of the issues involved, so I'd have to do a lot of reading first... Anyone else think this is a good idea/crazy? Cheers, M. From Mark.Favas at per.dem.csiro.au Fri Jul 14 08:30:13 2000 From: Mark.Favas at per.dem.csiro.au (Favas, Mark (EM, Floreat)) Date: Fri, 14 Jul 2000 14:30:13 +0800 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators for matrix comput ation] Message-ID: Speaking as a research scientist with my computational chemistry/visualization hat down around my ears, I'd certainly welcome such operators, as would a couple of my colleagues to whom I introduced Python. One was a heavy user of Sather until the steam went out of it, then C++ for a time, now Python+NumPy - and loving it! A set of matrix operators would expand Python's sphere of use - scientists process numbers as well as text... From fdrake at beopen.com Fri Jul 14 08:52:28 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 02:52:28 -0400 (EDT) Subject: [Python-Dev] ConfigParser changes In-Reply-To: <200007140246.WAA07574@snark.thyrsus.com> References: <200007140246.WAA07574@snark.thyrsus.com> Message-ID: <14702.47276.262761.585951@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > I've seen a couple plus responses to my proposed ConfigParser > enhancements, no minuses, and the thread has petered out. I don't see the patch on SourceForge, so go ahead and check them in. I think everyone agrees that the basic functionality is useful, and has been requested before. +1 from me. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein at lyra.org Fri Jul 14 09:15:39 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 00:15:39 -0700 Subject: [Python-Dev] Request for Opinions In-Reply-To: <396E91DC.D767EF6F@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 11:06:52PM -0500 References: <396E91DC.D767EF6F@prescod.net> Message-ID: <20000714001539.T29590@lyra.org> On Thu, Jul 13, 2000 at 11:06:52PM -0500, Paul Prescod wrote: >... > We have three options: > > 1. use the relatively large 4XPath as is > > 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) > that can be implemented in a couple of hundred lines of Python code > (this code is mostly done already, in a module called TinyXPath) > > 3. try to scale 4XPath back by moving its parser to SRE, and making > some of its features "options" that can be added separately (not clear > how easy this is) > > What do you think? I think this is for the XML SIG. I don't know why it is here. SIGs discuss and design, then roll up their final decisions. I haven't seen a clear consensus or decision from the XML SIG yet. You've got your TinyXPath module, but (forget who) has another module for much the same thing. There was a discussion of APIs. A discussion of how/where SRE could play into the game. IMO, these are all a bunch of points for the XML SIG, not python-dev. Cheers, -g -- Greg Stein, http://www.lyra.org/ From moshez at math.huji.ac.il Fri Jul 14 09:13:46 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 10:13:46 +0300 (IDT) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396E91DC.D767EF6F@prescod.net> Message-ID: On Thu, 13 Jul 2000, Paul Prescod wrote: > There is a language called "XPath" for navigating XML trees. It makes > your life a lot easier. XPath is to XML trees as SQL is to relational > databases. Imagine working with relational databases by looping over > records with no query language! I think that some portion of XPath > should go into Python 2. I agree -- XPath would be cool to work with. > 4Thought has a large, sophisticated implementation of the entire XPath > language. They use Bison (not PyBison!) and FLEX for parsing > performance. The output of Bison is covered by the GPL, and flex requires a runtime library. We want a rich Python, but there's no reason for a billionaire > 1. use the relatively large 4XPath as is This seems to have a significant cost for the Python distribution > 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) > that can be implemented in a couple of hundred lines of Python code > (this code is mostly done already, in a module called TinyXPath) +0 on that. > 3. try to scale 4XPath back by moving its parser to SRE, and making > some of its features "options" that can be added separately (not clear > how easy this is) If you think someone will do this, this is great. If not, there isn't much point in discussing it, is there? <0.9 wink> -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gstein at lyra.org Fri Jul 14 09:19:37 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 00:19:37 -0700 Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: ; from Mark.Favas@per.dem.csiro.au on Fri, Jul 14, 2000 at 02:30:13PM +0800 References: Message-ID: <20000714001937.U29590@lyra.org> On Fri, Jul 14, 2000 at 02:30:13PM +0800, Favas, Mark (EM, Floreat) wrote: > Speaking as a research scientist with my computational > chemistry/visualization hat down around my ears, I'd certainly welcome such > operators, as would a couple of my colleagues to whom I introduced Python. > One was a heavy user of Sather until the steam went out of it, then C++ for > a time, now Python+NumPy - and loving it! A set of matrix operators would > expand Python's sphere of use - scientists process numbers as well as > text... We can always gain new users by adding domain-specific operators. Take that to the extreme, though, and you'll have a mess of complicated operators that don't create a unified whole, that don't work well across various types, and are hard to understand for the majority of users. What then? Well, you *lose* users. Gain the domain-specific, lose the rest. New users are great. Adding complexity to gain them is counter-productive from a longer term viewpoint. Cheers, -g p.s. and allowing user-programmable syntax? you're truly kidding, right? -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Fri Jul 14 09:27:41 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 00:27:41 -0700 Subject: [Python-Dev] Re: CVS: python/dist/src/Misc sf-faq.html,1.2,1.3 In-Reply-To: <200007140622.XAA32744@slayer.i.sourceforge.net>; from marangoz@users.sourceforge.net on Thu, Jul 13, 2000 at 11:22:57PM -0700 References: <200007140622.XAA32744@slayer.i.sourceforge.net> Message-ID: <20000714002740.V29590@lyra.org> Um. Why did you go and do this? Looking at the original HTML, it appears that Peter was using the Mozilla editor to create the page. With your revamping, will he continue to be able to do that? When he next edits the page, will it just revert back to the original? Did you discuss doing this big change with Peter? We just got done with a discussion about how/where people should feel free to make changes and what kinds of changes. Something drastic like this should have at least been run by the author. Otherwise, it is a bit disrespectful. In this case, it may also break his continued maintenance of it (need to check w/ Peter tho). -g On Thu, Jul 13, 2000 at 11:22:57PM -0700, Vladimir Marangozov wrote: > Update of /cvsroot/python/python/dist/src/Misc > In directory slayer.i.sourceforge.net:/tmp/cvs-serv32383 > > Modified Files: > sf-faq.html > Log Message: > Gosh - clean up that messy HTML; make it valid XHTML instead. > > > Index: sf-faq.html > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Misc/sf-faq.html,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -C2 -r1.2 -r1.3 > *** sf-faq.html 2000/07/14 01:43:31 1.2 > --- sf-faq.html 2000/07/14 06:22:54 1.3 > *************** > *** 1,406 **** > ! > ! > > ! > ! > ... > ! > ! ! "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > ! > > ! Python at SourceForge - Frequently Asked Questions > ! > -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Fri Jul 14 09:36:06 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 14 Jul 2000 09:36:06 +0200 (CEST) Subject: [Python-Dev] Re: http://python.sourceforge.net In-Reply-To: <396E884C.B55E4737@schneider-kamp.de> from "Peter Schneider-Kamp" at Jul 14, 2000 03:26:04 AM Message-ID: <200007140736.JAA29096@python.inrialpes.fr> Peter Schneider-Kamp wrote: > > Hi Greg! > > I made a small link page (to python.org, sourceforge.net/projects/python > and sf-faq.html) and loaded it up together with the faq (sf-faq.html). > > Anyone with a bit more feeling for design than me should feel free to > improve it. Thanks! You'd have to chmod g+w the new files first, though. I can't Mr Proper them. In a moment of great annoyance I'll also try to enhance the pages. BTW, please make a HTML Tidy pass (http://www.w3.org/People/Raggett/tidy/) over the HTML files, at least, if they're edited with your favorite editor. Or you may want to use Amaya for editing HTML (http://www.w3.org/Amaya/) but it still core dumps from time to time . It's improving though... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas at xs4all.net Fri Jul 14 09:44:12 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 09:44:12 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: ; from huaiyu_zhu@yahoo.com on Thu, Jul 13, 2000 at 10:53:38PM -0700 References: <396E4768.A77473AA@prescod.net> Message-ID: <20000714094412.Z7340@xs4all.nl> On Thu, Jul 13, 2000 at 10:53:38PM -0700, Huaiyu Zhu wrote: > On Thu, 13 Jul 2000, Paul Prescod wrote: > > It all depends on who works on it and how hard they work. I really can't > So can some one answer this question for sure: > Is it definitely possible to introduce .* ./ etc without much more > difficulty than introducing @* and @/ and so on? No, I don't think it's possible without significantly restructuring the Grammar. However, Vladimir may prove me wrong, he has before ! :-) The problem is the recursive-descent parser Python is using, I don't think it can see the difference between 2. / 2 and 2 ./ 2 or a. / b and a ./ b Because the dot is already a pretty overloaded character: it does float-creation, rendering the first example ambiguous, and it does attribute-lookup, rendering the second ambiguous. However, I haven't tried it, it might be possible to make it work even with the current parser. > If this is the case we do not need a new symbol. Actually, you do need a new symbol, several in fact. You don't need to introduce a new *character*, but you get several new symbols: ./, .*, etc. I'm not sure if using the dot for this, too, is such a good idea, even if it's possible: yet another possible meaning for '.' ? I think using '@' is preferable. At least non-matrix people will know when to run screaming, when they see that ! :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov at inrialpes.fr Fri Jul 14 09:49:17 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 14 Jul 2000 09:49:17 +0200 (CEST) Subject: [Python-Dev] Re: CVS: python/dist/src/Misc sf-faq.html,1.2,1.3 In-Reply-To: <20000714002740.V29590@lyra.org> from "Greg Stein" at Jul 14, 2000 12:27:41 AM Message-ID: <200007140749.JAA29121@python.inrialpes.fr> Greg Stein wrote: > > Um. Why did you go and do this? Looking at the original HTML, it appears > that Peter was using the Mozilla editor to create the page. With your > revamping, will he continue to be able to do that? When he next edits the > page, will it just revert back to the original? This shouldn't be a problem for Peter. He can revert that with the editor of his choice; if its not conformant to the standards, I'll clean the files occasionally if you don't mind. Sorry for being sensible on this topic, working next to the W3C people and being an INRIA webmaster. I'm just trying to give the example about the culture. Unfortunately, I must reckon that the tools are following slowly, but everybody will jump in sooner or later... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas at xs4all.net Fri Jul 14 09:46:18 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 09:46:18 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <396E4768.A77473AA@prescod.net>; from paul@prescod.net on Thu, Jul 13, 2000 at 05:49:12PM -0500 References: <396E4768.A77473AA@prescod.net> Message-ID: <20000714094618.A7340@xs4all.nl> On Thu, Jul 13, 2000 at 05:49:12PM -0500, Paul Prescod wrote: > Huaiyu Zhu wrote: > > But I can see its use now. I have to get your reply from web and cut and > > paste in order to reply again. :-( > How long until some enterprising Python programmer makes a utility that > polls the website, and generates an email version of each message as it > appears? :) You can already download the email version: the archives in mbox format. You'll have to download the entire month of conversation, possibly again and again if you're following a running converstation, and you'll lose the threading information (In-Reply-To: headers) but 'reply' should work fine. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein at lyra.org Fri Jul 14 10:02:20 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 01:02:20 -0700 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <20000714094412.Z7340@xs4all.nl>; from thomas@xs4all.net on Fri, Jul 14, 2000 at 09:44:12AM +0200 References: <396E4768.A77473AA@prescod.net> <20000714094412.Z7340@xs4all.nl> Message-ID: <20000714010220.Y29590@lyra.org> On Fri, Jul 14, 2000 at 09:44:12AM +0200, Thomas Wouters wrote: > On Thu, Jul 13, 2000 at 10:53:38PM -0700, Huaiyu Zhu wrote: > > On Thu, 13 Jul 2000, Paul Prescod wrote: > > > > It all depends on who works on it and how hard they work. I really can't > > > So can some one answer this question for sure: > > > Is it definitely possible to introduce .* ./ etc without much more > > difficulty than introducing @* and @/ and so on? > > No, I don't think it's possible without significantly restructuring the > Grammar. However, Vladimir may prove me wrong, he has before ! :-) The > problem is the recursive-descent parser Python is using, I don't think it > can see the difference between The issue isn't with recursive-descent, and this would be a relatively easy change. You would introduce a new token "./" to accomplish this (call it DOTSLASH). Thus, . / maps to (DOT, SLASH,) while ./ maps to (DOTSLASH,). Python already does this to differentiate between < and <<. Most languages do, actually. What is really weird is that Python sees the ellipsis value/operator/ whatever-the-heck-it-is as three individual DOT tokens rather than a single token. Thus, the following two statements are equal: a[...] a[. . .] Whacky :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Fri Jul 14 10:06:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 14 Jul 2000 04:06:42 -0400 Subject: Copyright & licenses (was RE: [Python-Dev] Python Enhancement Proposals (PEPs)) In-Reply-To: <14702.19369.605446.28207@cj42289-a.reston1.va.home.com> Message-ID: [Greg Stein] > Why must we assert copyrights on these things? Come on, people. Aren't > we seeing Python 2.0 release problems because of copyrights? [Fred L. Drake, Jr.] > No. *Licensing* is distinct from copyright, and that's where we see > problems. The question of who is to be the next copyright holder will become a bone of contention too before this is over, don't you think? What to do with all the current copyright notices is already a point of negotiation (e.g., should CWI really have a notice in files that didn't even exist yet under their tenure? etc. Note that when I added pyport.h to the project, I put in only a BeOpen copyright: *someone* is bound to gripe about that too, provided I ever admit to it in public ). I personally would like to get Python out of the copyright *and* license games forever, by releasing Python to the public domain (as, e.g., Ralph Griswold did with the Icon language from the start -- and enjoyed a hassle-free life ever after; yes, at least one closed-source copyrighted commercial version of Icon did appear, but that was no skin off Prof. Griswold's nose; he kept working on the PD one, and the commercial version eventually gave up -- heck, rather than see their work wasted, they contributed most of what they did back to the PD Icon Project!). I don't believe there's any real downside to PD in America so long as you're not afraid to compete on merit alone. Don't know about international law, though. > The copyrights are indisputable, but are not a problem. Pshaw -- everything's disputable . and-everything's-a-problem-ly y'rs - tim From tim_one at email.msn.com Fri Jul 14 10:06:44 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 14 Jul 2000 04:06:44 -0400 Subject: [Python-Dev] Request for Opinions In-Reply-To: <396E91DC.D767EF6F@prescod.net> Message-ID: [Paul Prescod] > I don't want to PEP this, I want to discuss it. In fact, I think we are > supposed to discuss it four more times before I PEP it. And Tim has to > participate in each discussion, right? No to the latter. I read everything. That's why I never have time to respond anymore <0.5 wink>. Discussions are great! Just be aware that if the discussion doesn't flow directly to a patch that's applied to the distribution, and you're still keen on the idea, without a PEP it will be *worse* for you than if the discussion had never occurred. That's because the people who *did* read the discussion the first time around are exponentially less likely to say anything (or even pay attention!) on each of the next 500 times the topic pops up again. So if this discussion doesn't reach a conclusion you like, PEP it or you may as well forget it forever (well, maybe not that long -- augmented assignments appear to be getting in after a mere 9 years of thrice-yearly strident from-scratch endlessly redundant advocacy ). From fredrik at pythonware.com Fri Jul 14 10:21:46 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 10:21:46 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <010401bfed6c$8d905300$0900a8c0@SPIFF> Huaiyu Zhu wrote: > Look it this way. Text processing do have their special syntaxes. what special syntax? regular expressions are a *sublanguage* in Python. everything else is done through methods and ordinary sequence operators. From peter at schneider-kamp.de Fri Jul 14 12:44:40 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 14 Jul 2000 10:44:40 +0000 Subject: [Python-Dev] Re: http://python.sourceforge.net References: <200007140736.JAA29096@python.inrialpes.fr> Message-ID: <396EEF18.163475CD@schneider-kamp.de> Vladimir Marangozov wrote: > > Thanks! You'd have to chmod g+w the new files first, though. > I can't Mr Proper them. In a moment of great annoyance I'll > also try to enhance the pages. Done that. > BTW, please make a HTML Tidy pass (http://www.w3.org/People/Raggett/tidy/) > over the HTML files, at least, if they're edited with your favorite editor. Ok, I did. Unfortunately before reading the checkins ... > Or you may want to use Amaya for editing HTML (http://www.w3.org/Amaya/) > but it still core dumps from time to time . It's improving though... Is that what you used for sf-faq.html? There is one thing I don't like about all this xml*, meta and other special tags. I used to write .html files with my favorite text editor: my little home page

My Little Home Page

Here goes the content. With XHTML I'll probably end up with something like this: my little home page

My Little Home Page

Here goes the content. Talk about readability and maintainability. I know the header is worst, but the generated sources (from Page Composer, Frontpage, Amaya or your favorite tool) are always a pain in the ass if it comes to reading them. And yes, I am one of those who used to do their html in . compiling-amaya-though-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gstein at lyra.org Fri Jul 14 10:51:17 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 01:51:17 -0700 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <396E0B9B.DD74EF5@interet.com>; from jim@interet.com on Thu, Jul 13, 2000 at 02:34:03PM -0400 References: <396E0B9B.DD74EF5@interet.com> Message-ID: <20000714015117.C29590@lyra.org> On Thu, Jul 13, 2000 at 02:34:03PM -0400, James C. Ahlstrom wrote: > Mark Hammond wrote: >... > I guess I haven't made myself clear. I am not proposing > that we freeze the C interface. I am not proposing that we > scrutinize any *.pyd's for incompatabilities. > > I am proposing that we leave the "python15.dll" name the same. > I am proposing that the various *.pyd authors themselves either > provide newer versions, or declare that their *.pyd needs no > newer version of python15.dll. As a .pyd part-time author, I'm going to punt *every* time and suggest people upgrade. I don't have time or inclination to piss around to figure out whether my PYD is compatible forwards/backwards across revisions. > It is a matter of odds. If we necessarily rename python15.dll > for each version release, Python has a 100% chance of failing > with an obscure error or crashing if it uses any *.pyd at all > unless all *.pyd are replaced with new versions. > > If we do not rename python15.dll, then a *.pyd may or may not > fail. My guess (only a guess) is that many will work OK. This is completely untenable. *) change the python DLL name failure mode: old modules simply won't load, or they'll fail drastically *) don't change the name failure mode: old modules may work, may have *subtle* bugs, or they may fail miserably As a user, I want complete guaranteed success or guaranteed failure. That half-way ground where my application may silently be broken is simply unacceptable. You're free to start creating releases in this way. Personally, I don't want to spend this kind of time and effort, for dubious benefit. I'm also not going to try to impose that upon PYD authors. And yes: this is all just IMO. One more vote in the crowd.. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gregory.lielens at fft.be Fri Jul 14 11:57:37 2000 From: gregory.lielens at fft.be (Gregory Lielens) Date: Fri, 14 Jul 2000 11:57:37 +0200 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators formatrix computation] References: <396DFDC5.6780A710@prescod.net> Message-ID: <396EE411.B3CB33A9@fft.be> Paul Prescod wrote: > > Huaiyu Zhu wrote: > > > > ... > > > > I wonder how orthogonal would this be against the main development? Would > > it require a rebuild for each new release. Would it also require a patch > > each time? > > I think that the idea is that you could install new syntaxes in the same > way you install new modules...of course only after careful > consideration!!! It seems potentially more dangerous than statically adding a new operator, no? If two modules install incompatible changes of syntax, for exmaple if they demand both @ as operator, they will be considered as incompatible? On the other hand, if @ is buil-in, it can be overloaded depending on the type of the operands, which seems safer...I am not sure, but it seems that if syntax is module-dependent, things becomes really complex... > > Look it this way. Text processing do have their special syntaxes. > > Okay, but probably 90% of Python programmers do text processing at some > point. Not so for matrix calculation. You believe that the Python world > would grow greatly if we did matrices natively. I don't know if I > believe that. Well, that kind of change could potentially attract all the numeric community...which is probably a minority (and becoming smaller, based on the evolution of the number of science students in belgium) compared to the rest of the comp world, but still a significant minority. At least, it will attract one person for sure: me :-) Anyway, it seems that that audience (numeric people) was targeted by python since the beginning, because why the hell include complex numbers as built-in type if not? They are of a less general usefullness than matrices, imho, the last can at least be used for graphic stuff... Greg. From ping at lfw.org Fri Jul 14 12:09:10 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Fri, 14 Jul 2000 03:09:10 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: Message-ID: On Thu, 13 Jul 2000, Huaiyu Zhu wrote: > > You are almost there. :-) The current MatPy expression is > solve (X.H() * X, X.H() * y) I was about to suggest something similar, but you beat me to it. I think that expression looks great. If you can say it that concisely, i don't think you need to throw in extra operators at all (let alone a half-dozen of them that are incomprehensible to anyone outside of the Matlab community). I actually believe solve(X.H()*X, X.H()*y) is *clearer* than (X'*X)\(X'*y) (What does the backslash mean? What does the tick mark mean? At least solve() is clear, and if i understood what H() stood for, it would mean more than a tick mark.) -- ?!ng From m.favas at per.dem.csiro.au Fri Jul 14 12:55:44 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Fri, 14 Jul 2000 18:55:44 +0800 Subject: [Python-Dev] Introducing new operators for matrix computation Message-ID: <396EF1B0.8CB53FD3@per.dem.csiro.au> Greg Stein wrote: >New users are great. Adding complexity to gain them is >counter-productive from a longer term viewpoint. > >Cheers, >-g > >p.s. and allowing user-programmable syntax? you're truly kidding, >right? The p.s. is one of the reasons I support putting useful matrix operators into the core - user-programmable syntax will only lead to even more complexity/confusion/fragmentation, and should be resisted strongly... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From effbot at telia.com Fri Jul 14 13:51:43 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 13:51:43 +0200 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: Message-ID: <009501bfed89$e415ce40$f2a6b5d4@hagrid> moshe wrote: > > # normal case > > for (x,) in zip([0, 1, 2]): > > ... > > > > # special case > > for x in zip([0, 1, 2]): > > ... > > I'm sorry, I don't buy that. > > # "special case" > for x in [0, 1, 2]: > ... > > # "special case" > do_something_that_requires_a_list_of_tuples(zip(*lists)) we sure have a major disconnect here -- wasn't the source of this discussion the need to be able to loop over multiple sequences in parallel? isn't "for" what you'd usually use when looping over things? From billtut at microsoft.com Fri Jul 14 14:30:35 2000 From: billtut at microsoft.com (Bill Tutt) Date: Fri, 14 Jul 2000 05:30:35 -0700 Subject: [Python-Dev] RE: Unicode character name hashing Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2D5@RED-MSG-50> After making use of the test drive Alphas by Compaq, I just uploaded a patch to SF that should fix this nasty issue. Ugh. Not fun.... If anybody else cares about identical string hash values across 32 v. 64 bit architectures, check out the patch. Bill -----Original Message----- From: Mark Favas [mailto:m.favas at per.dem.csiro.au] Sent: Thursday, July 13, 2000 4:00 PM To: Bill Tutt Subject: Re: Unicode character name hashing Just tried it, and got the same message: test_ucn test test_ucn crashed -- exceptions.UnicodeError : Unicode-Escape decoding error: Invalid Unicode Character Name Cheers, Mark Bill Tutt wrote: > > Does this patch happen to fix it? > I'm afraid my skills relating to signed overflow is a bit rusty... :( > > Bill > > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/ucnhash.c,v > retrieving revision 1.2 > diff -u -r1.2 ucnhash.c > --- ucnhash.c 2000/06/29 00:06:39 1.2 > +++ ucnhash.c 2000/07/13 21:41:07 > @@ -30,12 +30,12 @@ > > len = cch; > p = (unsigned char *) key; > - x = 1694245428; > + x = (long)0x64fc2234; > while (--len >= 0) > - x = (1000003*x) ^ toupper(*(p++)); > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); > x ^= cch + 10; > - if (x == -1) > - x = -2; > + if (x == (long)0xFFFFFFFF) > + x = (long)0xfffffffe; > x %= k_cHashElements; > /* ensure the returned value is positive so we mimic Python's % > operator */ > if (x < 0) > @@ -52,12 +52,12 @@ > > len = cch; > p = (unsigned char *) key; > - x = -1917331657; > + x = (long)0x8db7d737; > while (--len >= 0) > - x = (1000003*x) ^ toupper(*(p++)); > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); > x ^= cch + 10; > - if (x == -1) > - x = -2; > + if (x == (long)0xFFFFFFFF) > + x = (long)0xfffffffe; > x %= k_cHashElements; > /* ensure the returned value is positive so we mimic Python's % > operator */ > if (x < 0) > > -----Original Message----- > From: Mark Favas [mailto:m.favas at per.dem.csiro.au] > Sent: Thursday, July 13, 2000 1:16 PM > To: python-dev at python.org; Bill Tutt > Subject: Unicode character name hashing > > [Bill has epiphany] > >I just had a rather unhappy epiphany this morning. > >F1, and f2 in ucnhash.c might not work on machines where sizeof(long) >!= > 32 bits. > > I get the following from test_ucn on an Alpha running Tru64 Unix: > > python Lib/test/test_ucn.py > UnicodeError: Unicode-Escape decoding error: Invalid Unicode Character > Name > > This is with the current CVS - and it's been failing this test for some > time now. I'm happy to test any fixes... > > -- > Email - m.favas at per.dem.csiro.au Mark C Favas > Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining > Fax - +61 8 9383 9891 Private Bag No 5, Wembley > WGS84 - 31.95 S, 115.80 E Western Australia 6913 -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From paul at prescod.net Fri Jul 14 12:07:43 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:07:43 -0500 Subject: [Python-Dev] Request for Opinions References: <200007140516.HAA28633@python.inrialpes.fr> Message-ID: <396EE66F.59D0D45F@prescod.net> Vladimir Marangozov wrote: > >... > > Well, I think that the code you're talking about fits best the 4Suite > and, for the moment, as a user I would download and install the whole suite > from FourThought. Why? 4XPath is entirely separable and compatible with Python's current XML support. > You're talking about XPath, but there are also XLink, XPointer, XML Base > and other incoming X'es. Sure, there are a million XML-world specs. XPath is the one that makes navigating XML trees easy. We've put an XML tree package (miniDOM) in Python 2.0. Therefore XPath is the one that makes our XML tree package easy to navigate. > ... > I'd like to see this discussion focusing on more ambitious goals, like > including and providing support for a complete, rich and up to date XML > package, which is what the 4Suite basically is. Well, it's not very ambitious to propose projects that are already pretty much done! 4Suite is great and its mostly done. Now we're talking about making *Python* more complete. > I'm not sure we're ready > to discuss this right now, though, so I'd suggest to PEP it anyway. Why aren't we ready to dicuss it? -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 12:08:51 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:08:51 -0500 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> Message-ID: <396EE6B3.B86BED76@prescod.net> Greg Stein wrote: > > ... > > I think this is for the XML SIG. I don't know why it is here. SIGs discuss > and design, then roll up their final decisions. Okay, so we can agree in the XML SIG that we love XPath and then "check in" 4K of Bison/FLEX/C/Python code without consulting anyone else? I don't see any harm in consulting PythonDev....it's not like every string decision is entirely settled in string-sig and every internationalization feature in il8n-sig. There are also integration issues. Adopting a large package is one such. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From guido at beopen.com Fri Jul 14 16:07:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:07:29 -0500 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: Your message of "Fri, 14 Jul 2000 00:06:43 -0400." <14702.37331.302346.67441@anthem.concentric.net> References: <20000713235356.X7340@xs4all.nl> <14702.37331.302346.67441@anthem.concentric.net> Message-ID: <200007141407.JAA12817@cj20424-a.reston1.va.home.com> > P.S. I'd rather use TBD than XXX as is the Dutch convention. The USA > is much more prudish than the Europeans, and I'd hate for our PEPs to > get blocked from all those Python 8 year olds accessing our documents > from the public libraries. :) XXX is not a Dutch invention -- I picked up the habit from the X11 source code base. I believe it's fairly common in open source projects, and there are so many XXX'es throughout Python already that it's better not to try and change. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Fri Jul 14 16:13:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:13:29 -0500 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: Your message of "Fri, 14 Jul 2000 00:37:27 -0400." <14702.39175.2260.890343@anthem.concentric.net> References: <14702.36906.418249.461209@anthem.concentric.net> <14702.39175.2260.890343@anthem.concentric.net> Message-ID: <200007141413.JAA12883@cj20424-a.reston1.va.home.com> I just want to make it crystal clear that I'm *against* (that's a -999, only overridable by a bus) inclusion of 3rd party library source code in the Python source distribution. Exceptions can only be made if the particular 3rd party code needs to be modified before it is usable from Python (e.g. some checksum algorithms, and PCRE) or if there is no reasonably accessible distribution available on the web. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Fri Jul 14 16:17:53 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:17:53 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: Your message of "Thu, 13 Jul 2000 19:11:27 -0400." <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> <14702.19480.746784.235766@bitdiddle.concentric.net> <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> Message-ID: <200007141417.JAA12935@cj20424-a.reston1.va.home.com> > > My only concern is that without some explicit expression of rights, > > some party might try to prevent us from distributing a PEP. According to a discussion I just had with Tim about a different issue, putting it in the public domain is just as good a safeguard against this particular problem. But we have an additional requirement here: we want to prevent others from distributing mutilated versions of our standard documents. I believe some form of open copyright is the best protection against that. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul at prescod.net Fri Jul 14 12:10:56 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:10:56 -0500 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators formatrix computation] References: <396DFDC5.6780A710@prescod.net> <396EE411.B3CB33A9@fft.be> Message-ID: <396EE730.6183423F@prescod.net> Gregory Lielens wrote: > > ... > > It seems potentially more dangerous than statically adding a new > operator, no? If two modules > install incompatible changes of syntax, for exmaple if they demand both > @ as operator, they will be considered as incompatible? I think that the idea is that one module would be in the Matrix sublanguage and another would be in an XML sublanguage. That way your context shifts are clear. Presumably the first or second line of the file says what sublanguage you are using. > Anyway, it seems that that audience (numeric people) was targeted by > python since the beginning, because why the hell include complex numbers > as built-in type if not? They are of a less general usefullness than > matrices, imho, the last can at least be used for graphic stuff... Okay, but look at the syntactic support complex numbers needed. Just "j". The same for string processing. We just reused most of the existing operators. If you guys made a really kick-ass matrix package that everyone loved and didn't need any new syntax, Guido might be tempted to make matrices a built-in type also! The funny thing is that most of the Python syntax that I don't use today is ALREADY for matrix operations: foo[x,y:a,b] foo()[...] -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 12:11:45 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:11:45 -0500 Subject: [Python-Dev] Re: http://python.sourceforge.net References: <200007140736.JAA29096@python.inrialpes.fr> <396EEF18.163475CD@schneider-kamp.de> Message-ID: <396EE761.9ADE5325@prescod.net> Peter Schneider-Kamp wrote: > >... > > With XHTML I'll probably end up with something like this: I don't know what you mean by probably, but about half of the stuff in your document is optional. Here's a fairly minimal XHTML representation: > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > > > my little home page > > >

My Little Home Page

> Here goes the content. > > Other than the first three lines, it is almost the same as your original HTML. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From esr at thyrsus.com Fri Jul 14 15:35:08 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 09:35:08 -0400 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: <200007141407.JAA12817@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 09:07:29AM -0500 References: <20000713235356.X7340@xs4all.nl> <14702.37331.302346.67441@anthem.concentric.net> <200007141407.JAA12817@cj20424-a.reston1.va.home.com> Message-ID: <20000714093508.A8842@thyrsus.com> Guido van Rossum : > XXX is not a Dutch invention -- I picked up the habit from the X11 > source code base. I believe it's fairly common in open source > projects, and there are so many XXX'es throughout Python already that > it's better not to try and change. Guido is correct. XXX as a to-be-done marker was already known to me and well established in the U.S. in 1990, when I collected the following entry: @hd{XXX} @pr{X-X-X} @g{n.} @p{} A marker that attention is needed. Commonly used in program comments to indicate areas that are kluged up or need to be. Some hackers liken `XXX' to the notional heavy-porn movie rating. Compare @es{FIXME}. @comment from Bob Page , 16 Dec 1990 -- Eric S. Raymond No matter how one approaches the figures, one is forced to the rather startling conclusion that the use of firearms in crime was very much less when there were no controls of any sort and when anyone, convicted criminal or lunatic, could buy any type of firearm without restriction. Half a century of strict controls on pistols has ended, perversely, with a far greater use of this weapon in crime than ever before. -- Colin Greenwood, in the study "Firearms Control", 1972 From esr at thyrsus.com Fri Jul 14 15:39:31 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 09:39:31 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007141413.JAA12883@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 09:13:29AM -0500 References: <14702.36906.418249.461209@anthem.concentric.net> <14702.39175.2260.890343@anthem.concentric.net> <200007141413.JAA12883@cj20424-a.reston1.va.home.com> Message-ID: <20000714093931.B8842@thyrsus.com> Guido van Rossum : > I just want to make it crystal clear that I'm *against* (that's a > -999, only overridable by a bus) inclusion of 3rd party library source > code in the Python source distribution. Exceptions can only be made > if the particular 3rd party code needs to be modified before it is > usable from Python (e.g. some checksum algorithms, and PCRE) or if > there is no reasonably accessible distribution available on the web. OK, I'm confused now. Moshe, are we talking about including 3rd-party code, or simply changing the build process so that RPMs and Debian packages have some additional requires and possibly include some unmodified binary libraries from third parties? -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. From paul at prescod.net Fri Jul 14 12:13:24 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 05:13:24 -0500 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> Message-ID: <396EE7C4.17DEF722@prescod.net> Greg Stein wrote: > > ... > > I haven't seen a clear consensus or decision from the XML SIG yet. By the way, one of the major reasons there is no clear consensus from the XML SIG yet is because we are hung up on an issue of fact. Is it technically and politically feasible to put 4XPath into the Python distribution. Our discussions over there will be radically different if everybody over here says "sure, that's no problem." -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From guido at beopen.com Fri Jul 14 16:37:46 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:37:46 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Thu, 13 Jul 2000 14:34:03 -0400." <396E0B9B.DD74EF5@interet.com> References: <396E0B9B.DD74EF5@interet.com> Message-ID: <200007141437.JAA13178@cj20424-a.reston1.va.home.com> Ignoring most that's been said in this thread, would it be possible for the installer to detect the presence of python15.dll in the system directory and offer to delete it? --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul at prescod.net Fri Jul 14 15:42:50 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 08:42:50 -0500 Subject: [Python-Dev] Python Enhancement Proposals (PEPs) References: <14701.26881.172217.870049@anthem.concentric.net> <14701.56551.680037.481536@bitdiddle.concentric.net> <20000713152725.Z29590@lyra.org> <14702.19480.746784.235766@bitdiddle.concentric.net> <14702.19615.825753.613680@cj42289-a.reston1.va.home.com> <200007141417.JAA12935@cj20424-a.reston1.va.home.com> Message-ID: <396F18DA.A3EE25BF@prescod.net> Guido van Rossum wrote: > > ... > > But we have an additional requirement here: we want to prevent others > from distributing mutilated versions of our standard documents. What about the Annotated Python Enhancement Proposals? I don't see what the big deal is. People can find the real ones the same way they find the real Python distribution. Mutilated ones do not hurt us much and are not that likely in the first place. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From guido at beopen.com Fri Jul 14 16:52:16 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 09:52:16 -0500 Subject: [Python-Dev] ConfigParser changes In-Reply-To: Your message of "Thu, 13 Jul 2000 22:46:37 -0400." <200007140246.WAA07574@snark.thyrsus.com> References: <200007140246.WAA07574@snark.thyrsus.com> Message-ID: <200007141452.JAA13252@cj20424-a.reston1.va.home.com> > I've seen a couple plus responses to my proposed ConfigParser > enhancements, no minuses, and the thread has petered out. > > If nobody hands me a -1, I'm going to merge them in in a day or so. > Speak now... Cool. One possible suggestion (just for your contemplation): if you're only adding methods, would it make sense to make a subclass, so that from the class one uses it is clear whether one intends to modify the options or just to read them? That would enable future optimizations. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gvwilson at nevex.com Fri Jul 14 15:59:18 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 09:59:18 -0400 (EDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <200007141417.JAA12935@cj20424-a.reston1.va.home.com> Message-ID: > Guido (on copyrights, public domain, etc.): > But we have an additional requirement here: we want to prevent others > from distributing mutilated versions of our standard documents. I > believe some form of open copyright is the best protection against > that. We're using the Open Publication License for Software Carpentry for exactly this reason. I once had to get the IEEE's copyright lawyer involved in a dispute where some material I had written had been slightly modified and then posted on the web under someone else's name --- still occasionally have to deal with fallout from copies of copies of copies of the distorted version. Greg From jeremy at beopen.com Fri Jul 14 16:03:58 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 10:03:58 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: References: <14702.4582.530066.817107@bitdiddle.concentric.net> Message-ID: <14703.7630.267201.436909@bitdiddle.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I'm currently drawing a list for extensions to include: MZ> -- zlib -- Tcl/Tk -- expat -- PIL -- Anything else? MZ> I really want something with "everything" in it. Then your list is much too short. Everything is a lot. You also need OpenSSL, NumPy, PyXML, and kjBuckets. And that's just getting started. My worry about the list of things to include is where exactly to cut the list short. The crucial modules are going to be different for every person. You mentioned PIL as one of your first four extensions. I've used PIL exactly once, and then only as a brief experiment. When I took a poll on c.l.py about the RADIUS authentication module, I got one response saying it was vitally important and everyone needs it. (I think that respondents definition of everyone was "everyone who operates an ISP or campus network.") So add radius to your list. Jeremy From guido at beopen.com Fri Jul 14 17:05:39 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:05:39 -0500 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: Your message of "Thu, 13 Jul 2000 17:48:38 EST." <396E4746.DE25EFD4@prescod.net> References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> <396E4746.DE25EFD4@prescod.net> Message-ID: <200007141505.KAA13385@cj20424-a.reston1.va.home.com> > If Guido has decided that the design that has already been implemented > is the right one, what's the point of the PEP? Someone just needs to > review the patch and check it in! Right! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Fri Jul 14 16:22:56 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 10:22:56 -0400 Subject: [Python-Dev] ConfigParser changes In-Reply-To: <200007141452.JAA13252@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 09:52:16AM -0500 References: <200007140246.WAA07574@snark.thyrsus.com> <200007141452.JAA13252@cj20424-a.reston1.va.home.com> Message-ID: <20000714102256.A9019@thyrsus.com> Guido van Rossum : > One possible suggestion (just for your contemplation): if you're only > adding methods, would it make sense to make a subclass, so that from > the class one uses it is clear whether one intends to modify the > options or just to read them? That would enable future optimizations. Yes, and I even know what I'd call the class: ConfigEditor. Unfortunately this plan it trips on a historical fact; one (1) of the write methods, add_section(), already existed in ConfigParser. Moving it to a ConfigEditor subclass would break backward compatibility. And I think it would be just too ugly to move all but one of the write methods into ConfigEditor and leave add_section() in the base class. If not for this problem I would be more than happy to do as you suggest. -- Eric S. Raymond "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy From moshez at math.huji.ac.il Fri Jul 14 16:14:11 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 17:14:11 +0300 (IDT) Subject: [Python-Dev] Python Enhancement Proposals (PEPs) In-Reply-To: <009501bfed89$e415ce40$f2a6b5d4@hagrid> Message-ID: On Fri, 14 Jul 2000, Fredrik Lundh wrote: > we sure have a major disconnect here -- wasn't the source > of this discussion the need to be able to loop over multiple > sequences in parallel? Yes > isn't "for" what you'd usually use when looping over things? Yes. The thing is, you don't need to cater to people who want to iterate over one sequence -- you can already do that easily in current day Python. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Fri Jul 14 16:20:17 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 16:20:17 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: ; from ping@lfw.org on Fri, Jul 14, 2000 at 03:09:10AM -0700 References: Message-ID: <20000714162017.B7340@xs4all.nl> On Fri, Jul 14, 2000 at 03:09:10AM -0700, Ka-Ping Yee wrote: > I actually believe > solve(X.H()*X, X.H()*y) > is *clearer* than > (X'*X)\(X'*y) > (What does the backslash mean? What does the tick mark mean? > At least solve() is clear, and if i understood what H() stood > for, it would mean more than a tick mark.) More importantly, how are they grouped ? Is '* a single operator, or is ' a binary operator and * an unary operator ? Or is ' a postfix unary operator and * the binary operator ? Does the backslash escape the opening paren for some reason, or is it an operator on its own ? Oh, wait, I see it now ! It's a string literal of the new 'X' type, containing '*X)\(X', multiplied by y! I wonder what that 'X' type string is... Maybe a built-in regular expression ? Confusing-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Fri Jul 14 16:20:11 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 17:20:11 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14703.7630.267201.436909@bitdiddle.concentric.net> Message-ID: On Fri, 14 Jul 2000, Jeremy Hylton wrote: > MZ> I really want something with "everything" in it. > > Then your list is much too short. Everything is a lot. "Everything" is different from everything. <"wink"> > You also need OpenSSL, NumPy, PyXML, and kjBuckets. And that's just > getting started. I want to aim for "top 10 packages". And anyway, having distutils should make this a snap -- the only thing we have to do is match versions. > My worry about the list of things to include is where exactly to cut > the list short. The crucial modules are going to be different for > every person. You mentioned PIL as one of your first four extensions. > I've used PIL exactly once, and then only as a brief experiment. When > I took a poll on c.l.py about the RADIUS authentication module, I got > one response saying it was vitally important and everyone needs it. > (I think that respondents definition of everyone was "everyone who > operates an ISP or campus network.") So add radius to your list. My list is of course tentative, but once my PEP hits the CVS archive, I intend to poll c.l.py for opinions on what packages to include. I've seen quite a few questions in c.l.py over PIL, and only one about RADIUS, but that's just anecdotal evidence. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gvwilson at nevex.com Fri Jul 14 16:24:14 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 10:24:14 -0400 (EDT) Subject: [Python-Dev] request for minor enhancement Message-ID: I would like 'min' and 'max' to be in-fix binary operators, with '__min__' and '__max__' as the associated overloadable method names, and 'min=' and 'max=' as the in-place forms. I find myself re-defining them in almost every module I write, and believe that their semantics and implementation would be unproblematic? Reactions? Thanks, Greg From guido at beopen.com Fri Jul 14 17:29:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:29:02 -0500 Subject: [Python-Dev] Request for Opinions In-Reply-To: Your message of "Fri, 14 Jul 2000 05:13:24 EST." <396EE7C4.17DEF722@prescod.net> References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE7C4.17DEF722@prescod.net> Message-ID: <200007141529.KAA13625@cj20424-a.reston1.va.home.com> > By the way, one of the major reasons there is no clear consensus from > the XML SIG yet is because we are hung up on an issue of fact. Is it > technically and politically feasible to put 4XPath into the Python > distribution. Our discussions over there will be radically different if > everybody over here says "sure, that's no problem." I have no idea what 4XPath is. Assuming it is a separately maintained and distributed 3rd party library, the answer is no for the source distribution and yes for binary distributions. I know you've argued about this before but it's pointless, I don't want to have 3rd party code checked in as part of the Python CVS tree or distributed as part of a Python source distribution. However, one thing we *could* do is collect convenient links to the source code of the latest versions of all the necessary or popular 3rd party libraries -- or even redistribute copies from our website if their license allows it. We could also create a "sumo" (meaning so big it contains everything) source distribution that contains Python and all needed 3rd party libraries. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Fri Jul 14 17:33:16 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:33:16 -0500 Subject: [Python-Dev] Pythonb at SourceForge FAQ In-Reply-To: Your message of "Thu, 13 Jul 2000 17:45:54 MST." <20000713174554.R29590@lyra.org> References: <396E7D29.7AC68EA6@schneider-kamp.de> <20000713174554.R29590@lyra.org> Message-ID: <200007141533.KAA13655@cj20424-a.reston1.va.home.com> > > 3.3.: > > > > Q: How to change the status of a patch? > > > > A: > > > > To change the status of a patch or assign it to somebody else you have > > to be a) a SourceForge-recognized Python developer and b) a patch > > administrator. Unfortunately the SourceForge default for developers is > > not to be patch administrators. Contact one of the project > > administrators if the following does not work for you. > > > > Click on the patch itself. In the screen that comes up, there is a > > drop-box for "Assigned To:" and a drop-box for "Status:" where you can > > select a new responsible developer or a new status respectively. After > > selecting the appropriate victim and status, hit the "Submit Changes" > > button at the bottom of the page. Note: if are sure that you have the right permissions and a drop-box does not appear, check that you are actually logged in to SF! > > For more information about the use of the "Status:" and "Assigned To:" > > fields consult the [26]Patch Manager Guidelines. A recent copy can be > > found in the Appendix of this FAQ. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Fri Jul 14 17:38:52 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:38:52 -0500 Subject: [Python-Dev] urllib vs. cgi In-Reply-To: Your message of "Thu, 13 Jul 2000 22:44:10 -0400." <20000713224410.A7548@thyrsus.com> References: <14702.31418.483935.810948@bitdiddle.concentric.net> <20000713224410.A7548@thyrsus.com> Message-ID: <200007141538.KAA13713@cj20424-a.reston1.va.home.com> > Jeremy Hylton : > > Any opinions on adding a symmetrical urldecode to urllib? I'm not > > thrilled by duplicating code, but the cgi module is big and hairy and > > urllib seems like the obvious place for it. [ESR] > +0. It doesn't thrill me, but I can't argue with your analysis either. +0. Ditto. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gregory.lielens at fft.be Fri Jul 14 16:43:51 2000 From: gregory.lielens at fft.be (Gregory Lielens) Date: Fri, 14 Jul 2000 16:43:51 +0200 Subject: [Python-Dev] [Fwd: Discussion: Introducing new operators formatrix computation] References: <396DFDC5.6780A710@prescod.net> <396EE411.B3CB33A9@fft.be> <396EE730.6183423F@prescod.net> Message-ID: <396F2727.E301FBB4@fft.be> > Okay, but look at the syntactic support complex numbers needed. Just > "j". The same for string processing. We just reused most of the existing > operators. If you guys made a really kick-ass matrix package that > everyone loved and didn't need any new syntax, Guido might be tempted to > make matrices a built-in type also! Right, but I think that making a kick-ass matrix package without syntax modification is not possible... Indeed, what characterize the numeric languages around (e.g. matlab, octave, yorick, r-lab, ...) is precisely the presence of a syntax able to naturrally express linear algebra expression. All of them introduce easy matrix concatenation, multiplication, division and bloc-adressing...By the way, all matrix package are more or less cloning the matlab way, with minor differences (except for yorick, which have a more general syntax able to deal with multidimensional arrays cleanly, but probably make things less easy with 2D matrix). I think that such convergence comes probably from the fact that the Matlab way is the good way for numeric stuff... > The funny thing is that most of the Python syntax that I don't use today > is ALREADY for matrix operations: > > foo[x,y:a,b] > foo()[...] This is inevitable, I agree that numeric stuff is completely off-topic for a lot of peoples...But unicode support is also an excess-feature for numerical code. Of course, when you write something which must compute linear regressions and you want to ask input to a user which only speek japanese...In fact, what attracts me in Python the first time I've heard of it (3 weeks ago, so do not take my words too seriously...) is that it seems to be able to do numeric stuff quite well, except for matrix...the Python+NumPy package improve that, but not to the point of beeing matlab-like. Python+NumPy+MatPy is better in that sense, but still lack some operators to be THE solution...I tried to implement those operators as a way to check how python is extensible (a must, as the intended use of this - or anoteher numeric language) is to serve as command tools for c++ Finite element software, and I was surprise how easy it was...So here they are! I do not really see a problem in adding new operators, except when - it slows down the old ones, and I do not think it could be noticed in the present case...more ifs in the source code is certainly not something to worry about... - it makes python code unintelligible, and this is not relevant either: No numeric -> do not use them, but if you do numeric stuff, everything becomes clearer. - it makes python source more complex: true, but so little than I think it makes no practical difference. It is really a small change, after all I was able to implement it in a matter of day after looking for the fist time in the code...Arguably, this change is of the same order of magnitude as the 1.0j stuff...perhaps smaller - It is a hole which will unleash the craziest operators , and makes python look like binary with expressions soup like k=(a*$$^b)%/(@~c): That's the only risk I would be affraid of, but as already mentioned, linear algebra is a well established field , used almost everywhere in numerics and we have a bunch of languages which already support these kind of operators... From guido at beopen.com Fri Jul 14 17:45:08 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:45:08 -0500 Subject: [Python-Dev] PyErr_SafeFormat In-Reply-To: Your message of "Thu, 13 Jul 2000 19:29:30 +0200." <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> Message-ID: <200007141545.KAA13821@cj20424-a.reston1.va.home.com> > greg wrote: > > We don't care about anything except for %d, %s, possibly %c and %x. > > how about: I would suggest to build this into PyErr_Format, which is what everybody already uses. Instant safety. Need some more analysis of what format codes are actually used, and support for %.200s which is currently used often. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Fri Jul 14 17:05:04 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 11:05:04 -0400 Subject: [Python-Dev] request for minor enhancement In-Reply-To: ; from gvwilson@nevex.com on Fri, Jul 14, 2000 at 10:24:14AM -0400 References: Message-ID: <20000714110504.A9206@thyrsus.com> Greg Wilson : > I would like 'min' and 'max' to be in-fix binary operators, with '__min__' > and '__max__' as the associated overloadable method names, and 'min=' and > 'max=' as the in-place forms. I find myself re-defining them in almost > every module I write, and believe that their semantics and implementation > would be unproblematic? > > Reactions? +0 -- Eric S. Raymond "As to the species of exercise, I advise the gun. While this gives [only] moderate exercise to the body, it gives boldness, enterprise, and independence to the mind. Games played with the ball and others of that nature, are too violent for the body and stamp no character on the mind. Let your gun, therefore, be the constant companion to your walks." -- Thomas Jefferson, writing to his teenaged nephew. From guido at beopen.com Fri Jul 14 17:58:28 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 10:58:28 -0500 Subject: [Python-Dev] request for minor enhancement In-Reply-To: Your message of "Fri, 14 Jul 2000 10:24:14 -0400." References: Message-ID: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> > I would like 'min' and 'max' to be in-fix binary operators, with '__min__' > and '__max__' as the associated overloadable method names, and 'min=' and > 'max=' as the in-place forms. I find myself re-defining them in almost > every module I write, and believe that their semantics and implementation > would be unproblematic? You seem to propose two independent things. 1. in-fix min and max: you want to write "x min y" instead min(x, y). Why? It's not a notation I'm familiar with. Plus it's incompatible, since min would have to be a reserved word and it would break all existing code using min(). 2. __min__ and __max__ to override the semantics. Sure, this can be added regardless of (1). But do you want to override min(a, b) or min(sequence)? Note that min() and max() are variadic functions -- you can write min(a,b,c,d,e) which is the same as min([a,b,c,d,e]). 3. min= and max=? Ah, I see, like += and -=. Since I don't see much hope for (1) this is irrelevant. (But it's a good proposal for a generic syntax for other operators that are spelled with a reserved word.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Fri Jul 14 17:01:43 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 11:01:43 -0400 (EDT) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396EE6B3.B86BED76@prescod.net> References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE6B3.B86BED76@prescod.net> Message-ID: <14703.11095.264917.268373@bitdiddle.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Greg Stein wrote: >> ... >> >> I think this is for the XML SIG. I don't know why it is >> here. SIGs discuss and design, then roll up their final >> decisions. PP> Okay, so we can agree in the XML SIG that we love XPath and then PP> "check in" 4K of Bison/FLEX/C/Python code without consulting PP> anyone else? Yes. You've got it exactly. How do you think lambda made its way into the language? Seriously -- you've already seen Guido's response. I think there's no chance of adding third-party code to the Python CVS repository or source distribution. The only way I could imagine it happening is if there was strong consensus from the XML SIG. So Greg's suggestion is a good one. Jeremy From moshez at math.huji.ac.il Fri Jul 14 17:08:28 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 18:08:28 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007141413.JAA12883@cj20424-a.reston1.va.home.com> Message-ID: On Fri, 14 Jul 2000, Guido van Rossum wrote: > I just want to make it crystal clear that I'm *against* (that's a > -999, only overridable by a bus) inclusion of 3rd party library source > code in the Python source distribution. Exceptions can only be made > if the particular 3rd party code needs to be modified before it is > usable from Python (e.g. some checksum algorithms, and PCRE) or if > there is no reasonably accessible distribution available on the web. I took it that you're alright with a "sumo" distribution, which is core Python with + lots of goodies. I think it would be neat if the sumo distribution would be released together with the thin distribution from PythonLabs, and that Python-Dev would help support it. I *don't* think we need to maintain any such thing in the CVS tree -- only in the .tar.gz we let the world download. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gvwilson at nevex.com Fri Jul 14 17:17:17 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 11:17:17 -0400 (EDT) Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> Message-ID: > > Greg Wilson wrote: > > I would like 'min' and 'max' to be in-fix binary operators, with '__min__' > > and '__max__' as the associated overloadable method names, and 'min=' and > > 'max=' as the in-place forms. > On Fri, 14 Jul 2000, Guido van Rossum wrote: > > 1. in-fix min and max: you want to write "x min y" instead min(x, y). > Why? It's not a notation I'm familiar with. Plus it's incompatible, > since min would have to be a reserved word and it would break all > existing code using min(). I got there by working backwards to make things consistent. I want overloadable '__min__' and 'min=', and everything else that has these forms is binary infix (I think). > 2. __min__ and __max__ to override the semantics. Sure, this can be > added regardless of (1). But do you want to override min(a, b) or > min(sequence)? Note that min() and max() are variadic functions -- > you can write min(a,b,c,d,e) which is the same as min([a,b,c,d,e]). '+', '*', and the bitwise operators are equally variadic --- is confusion avoided by using punctuation for the infix binary form, and a named function for the general form? If the answer is 'yes', then my crystal ball predicts the following exchange: Greg: So let's adopt the notation '?' for 'min' and 'max', as used in C* and other parallel languages. We can then use '?=' for the infix forms, and reserve 'min()' and 'max()' as built-ins for the variadic forms. After all, it's just an historical accident that 'min' and 'max' aren't treated with the same respect as '+' and 'or'. Someone: Uck! I've never seen that before! It looks like line noise! It's not worth complexifying the core language with new operators for this special case. Greg: ...which is exactly the response I've twice typed in, and deleted, on the "linear algebra operators" thread. If 'min' and 'max' (which are used for strings as well as numbers) aren't worth new operators, I don't think matrices are either (and I probably do more matrix algebra than most people on this list). > 3. min= and max=? Ah, I see, like += and -=. Since I don't see much > hope for (1) this is irrelevant. (But it's a good proposal for a > generic syntax for other operators that are spelled with a reserved > word.) Thanks, Greg p.s. if min(a,b,c,d,e) is the same as min([a,b,c,d,e]), then what is the meaning of min([a,b,c,d,e], [g,h,i,j,k])? From moshez at math.huji.ac.il Fri Jul 14 17:18:31 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 18:18:31 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <20000714093931.B8842@thyrsus.com> Message-ID: On Fri, 14 Jul 2000, Eric S. Raymond wrote: > Guido van Rossum : > > I just want to make it crystal clear that I'm *against* (that's a > > -999, only overridable by a bus) inclusion of 3rd party library source > > code in the Python source distribution. Exceptions can only be made > > if the particular 3rd party code needs to be modified before it is > > usable from Python (e.g. some checksum algorithms, and PCRE) or if > > there is no reasonably accessible distribution available on the web. > > OK, I'm confused now. > > Moshe, are we talking about including 3rd-party code, or simply > changing the build process so that RPMs and Debian packages have some > additional requires and possibly include some unmodified binary > libraries from third parties? Neither. Let me explain: I *don't* care about RPM and Debian packages, nor about windows installers. Those who create such packages have time on their hands, and usually a pretty good Python and C knowledge. What I do care about, is that when building a complete Python interpreter from source on a UNIX system, one has the option of downloading the sumo package, type "./configure;make;make install", drink a cup of coffee, and have a Python installation which does what he needs. Take me, for example. I've decided to write a GUI in Python, and I need to -- download Tcl 8.0 (because that's what Python 1.5.2 works with), and compile it -- download Tk 8.0 and compile it -- Edit the Modules/Setup file to point to my Tcl/Tk installation -- Compile Python Now, if I find out later (as I have) that PIL would make my life easier, I need to download PIL, edit *it* so it builds against my Tcl/Tk, and install it. (Eventually, I decided to go without PIL because I don't have the time) Then I want to prototype some XML manipulation in Python. So I have to find out where expat lives, compile it, and only then I can get PyExpat to work. Now, if I were using Debian, I'd simply spend some quality time with apt-get and get over this. But I'm using Solaris, and later I might need to port to AIX. So I'm using source distributions, and it is simply painful. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From akuchlin at mems-exchange.org Fri Jul 14 17:20:02 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 14 Jul 2000 11:20:02 -0400 Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: ; from gvwilson@nevex.com on Fri, Jul 14, 2000 at 11:17:17AM -0400 References: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> Message-ID: <20000714112002.E28819@kronos.cnri.reston.va.us> On Fri, Jul 14, 2000 at 11:17:17AM -0400, Greg Wilson wrote: >I want overloadable '__min__' and 'min=', and everything else that has these >forms is binary infix (I think). One exception to the binary infix form: 'if foo' will call foo.__nonzero__. --amk From MarkH at ActiveState.com Fri Jul 14 17:21:29 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Fri, 14 Jul 2000 11:21:29 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007141437.JAA13178@cj20424-a.reston1.va.home.com> Message-ID: > Ignoring most that's been said in this thread, would it be possible > for the installer to detect the presence of python15.dll in the system > directory and offer to delete it? This should only be done if the installer can be very sure that the user _tried_ to uninstall 1.5, but this DLL remains. This could be done in a number of ways, none of which are foolproof (eg, you could check for a 1.5 registry key, but of the user has added their own PythonPath entries, for example, the installer wont remove them (as it didnt add them) - meaning you end up with a partial 1.5 registry tree remaining. A big of experimentation could provide something that works in a majority of cases. IMO, it is very important 1.5 and x.x can coexist on the same machine; especially in the light of this thread, where it should be obvious that many extension wont be available for post 1.5 releases until quite some time after that core release hits the street... Mark. \ From akuchlin at mems-exchange.org Fri Jul 14 17:23:15 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 14 Jul 2000 11:23:15 -0400 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14703.7630.267201.436909@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jul 14, 2000 at 10:03:58AM -0400 References: <14702.4582.530066.817107@bitdiddle.concentric.net> <14703.7630.267201.436909@bitdiddle.concentric.net> Message-ID: <20000714112315.F28819@kronos.cnri.reston.va.us> On Fri, Jul 14, 2000 at 10:03:58AM -0400, Jeremy Hylton wrote: >the list short. The crucial modules are going to be different for >every person. You mentioned PIL as one of your first four extensions. That's why I think this is a mug's game; people have wildly differing needs, and you can't meet them all. The correct fix is to make it easy to automatically download & install packages automatically; distributions then become simple lists. "You want to do Web development? Grab Cookie.py, wizard.py, DocumentTemplate, ..." "Numeric work? NumPy, PhysicalValue, Snow, ..." --amk From guido at beopen.com Fri Jul 14 18:24:56 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 11:24:56 -0500 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: Your message of "Fri, 14 Jul 2000 18:08:28 +0300." References: Message-ID: <200007141624.LAA14130@cj20424-a.reston1.va.home.com> > I took it that you're alright with a "sumo" distribution, which is core > Python with + lots of goodies. I think it would be neat if the sumo > distribution would be released together with the thin distribution from > PythonLabs, and that Python-Dev would help support it. Yes, we here at PythonLabs don't know enough about all the different 3rd party packages to know what to add and how to ensure that it builds easily. I suppose it should also have a top-level super-Makefile and a suggested Modules/Setup file (with all the 3rd packages enabled and correct pointers to source directories). > I *don't* think we need to maintain any such thing in the CVS tree -- only > in the .tar.gz we let the world download. Agreed. I have to add that I'm +0 on this idea -- it would seem that if we distribute a sumo RPM distribution we'd help way more people. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Fri Jul 14 18:26:49 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 11:26:49 -0500 Subject: [Python-Dev] zlib not compiled by default In-Reply-To: Your message of "Fri, 14 Jul 2000 18:18:31 +0300." References: Message-ID: <200007141626.LAA14154@cj20424-a.reston1.va.home.com> > Neither. Let me explain: I *don't* care about RPM and Debian packages, nor > about windows installers. Those who create such packages have time on > their hands, and usually a pretty good Python and C knowledge. What I do > care about, is that when building a complete Python interpreter from > source on a UNIX system, one has the option of downloading the sumo > package, type "./configure;make;make install", drink a cup of coffee, and > have a Python installation which does what he needs. > > Take me, for example. I've decided to write a GUI in Python, and I need to > -- download Tcl 8.0 (because that's what Python 1.5.2 works with), and > compile it > -- download Tk 8.0 and compile it > -- Edit the Modules/Setup file to point to my Tcl/Tk installation > -- Compile Python > > Now, if I find out later (as I have) that PIL would make my life easier, > I need to download PIL, edit *it* so it builds against my Tcl/Tk, and > install it. (Eventually, I decided to go without PIL because I don't have > the time) > > Then I want to prototype some XML manipulation in Python. So I have to > find out where expat lives, compile it, and only then I can get PyExpat > to work. > > Now, if I were using Debian, I'd simply spend some quality time with > apt-get and get over this. But I'm using Solaris, and later I might need > to port to AIX. So I'm using source distributions, and it is simply > painful. Bah, Solaris. Who still uses that old crap? :-) Or you could wait for ActivePython, which promises a binary distribution of Python 2.0 for Solaris. http://www.activestate.com/Products/ActivePython.html --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Fri Jul 14 17:39:26 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 11:39:26 -0400 Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: ; from gvwilson@nevex.com on Fri, Jul 14, 2000 at 11:17:17AM -0400 References: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> Message-ID: <20000714113926.B9381@thyrsus.com> Greg Wilson : > Greg: So let's adopt the notation '?' for 'min' and > 'max', as used in C* and other parallel languages. We can > then use '?=' for the infix forms, and reserve > 'min()' and 'max()' as built-ins for the variadic forms. > After all, it's just an historical accident that 'min' and > 'max' aren't treated with the same respect as '+' and 'or'. I would support something like this. What's really going on here, IMO, is that you're groping towards giving Python a complete set of notations for lattice algebra. My ma\thematician head likes this idea. -- Eric S. Raymond Men trained in arms from their infancy, and animated by the love of liberty, will afford neither a cheap or easy conquest. -- From the Declaration of the Continental Congress, July 1775. From jeremy at beopen.com Fri Jul 14 17:36:00 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 11:36:00 -0400 (EDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <200007141624.LAA14130@cj20424-a.reston1.va.home.com> References: <200007141624.LAA14130@cj20424-a.reston1.va.home.com> Message-ID: <14703.13152.88286.674722@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> I *don't* think we need to maintain any such thing in the CVS >> tree -- only in the .tar.gz we let the world download. GvR> Agreed. GvR> I have to add that I'm +0 on this idea -- it would seem that if GvR> we distribute a sumo RPM distribution we'd help way more GvR> people. I think it's significantly harder to create a .tar.gz file with a configure script and a makefile that builds Python and all the third-party libraries it depends on. Does the zlib source belong in the .tar.gz? How about OpenSSL? Tcl/Tk? libc? There are at least two problems with putting anything other than Python in a .tar.gz that we distribute. First, the user who grabs it may already have some of the third-party extensions installed. Second, we have a version-skew nightmare because each library is updated at its own pace. This is why Andrew is still correct! >>>>> "AMK" == Andrew Kuchling writes: AMK> The correct fix is to make it easy to AMK> automatically download & install packages automatically; AMK> distributions then become simple lists. "You want to do Web AMK> development? Grab Cookie.py, wizard.py, DocumentTemplate, ..." AMK> "Numeric work? NumPy, PhysicalValue, Snow, AMK> ..." The distutils plus platform-specific package management like RPM and Debian packages are the right solution. We can produce a Python package that indicates its dependence on readline, Tcl/Tk, or anything else. We can also provide a collection of Python packages via distutils that addresses the needs of particular audiences -- Web slingers, numerical analysts, etc. Jeremy From effbot at telia.com Fri Jul 14 17:39:08 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 17:39:08 +0200 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> Message-ID: <00f001bfeda9$a7d0d400$f2a6b5d4@hagrid> paul wrote: > We have three options: > > 1. use the relatively large 4XPath as is > > 2. use a tiny subset of XPath (analogous SQL with only simple SELECT) > that can be implemented in a couple of hundred lines of Python code > (this code is mostly done already, in a module called TinyXPath) > > 3. try to scale 4XPath back by moving its parser to SRE, and making > some of its features "options" that can be added separately (not clear > how easy this is) > > What do you think? if there's a migration path from (2) to (1) (interface-wise, at least), I'd vote for (2). or (2)+(3), if that makes sense. (I know I've promised to look at (1)+(3), but I haven't quite gotten there yet...) From effbot at telia.com Fri Jul 14 17:33:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 17:33:19 +0200 Subject: [Python-Dev] request for minor enhancement / linear algebra References: Message-ID: <00ef01bfeda9$a753b4c0$f2a6b5d4@hagrid> greg wrote: > p.s. if min(a,b,c,d,e) is the same as min([a,b,c,d,e]), then what is the > meaning of min([a,b,c,d,e], [g,h,i,j,k])? same as min([[a,b,c,d,e], [g,h,i,j,k]]), of course. From thomas at xs4all.net Fri Jul 14 17:33:43 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 17:33:43 +0200 Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: <20000714112002.E28819@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Fri, Jul 14, 2000 at 11:20:02AM -0400 References: <200007141558.KAA13924@cj20424-a.reston1.va.home.com> <20000714112002.E28819@kronos.cnri.reston.va.us> Message-ID: <20000714173343.C7340@xs4all.nl> On Fri, Jul 14, 2000 at 11:20:02AM -0400, Andrew Kuchling wrote: > On Fri, Jul 14, 2000 at 11:17:17AM -0400, Greg Wilson wrote: > >I want overloadable '__min__' and 'min=', and everything else that has > >these forms is binary infix (I think). > One exception to the binary infix form: 'if foo' will call > foo.__nonzero__. And another: int(foo) (and other, implicit conversions) call foo.__int__. However, I think overloading 'min' and 'max' should fall under the rich comparisons PEP. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From uche.ogbuji at fourthought.com Fri Jul 14 17:38:59 2000 From: uche.ogbuji at fourthought.com (Uche Ogbuji) Date: Fri, 14 Jul 2000 09:38:59 -0600 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE7C4.17DEF722@prescod.net> <200007141529.KAA13625@cj20424-a.reston1.va.home.com> Message-ID: <396F3413.608AF907@fourthought.com> Even though I'm one of the 4XPath developers, I've largely stayed on the sidelines because I've never been on python-dev, and I don't know how such matters are usually considered. Guido's response gives good guidance, and my ideas are expressed in-line. Guido van Rossum wrote: > > > By the way, one of the major reasons there is no clear consensus from > > the XML SIG yet is because we are hung up on an issue of fact. Is it > > technically and politically feasible to put 4XPath into the Python > > distribution. Our discussions over there will be radically different if > > everybody over here says "sure, that's no problem." > > I have no idea what 4XPath is. Assuming it is a separately maintained > and distributed 3rd party library, the answer is no for the source > distribution and yes for binary distributions. Paul did suggest a couple of other options. One was to make 4XPath easier to integrate into Python (by moving to SRE or otherwise removing the lex/yacc dependencuy), and this is a possibility. However, I don't know how you gauge what a "third-party" module is. My guess would be that it's a matter of copyright. If so, that might be an obstacle, but maybe not an insurmountable one. The other solution was to write an XPath-lite, probably all in Python to go with minidom in the Python distro. This would be the path of least resistance, but we are still discussion on xml-sig the useful subset of XPath. Is there any clear statement of policiy for including modules? Even a mailing-list archive entry? I don't expect one because this is open-source/BDFL world where the policy usually lies in a highly-respectable head, but it could certainly guide this conversation either here or on xml-sig. > We could also create a "sumo" (meaning so big it contains everything) > source distribution that contains Python and all needed 3rd party > libraries. Not a bad idea as a stop-gap answer to CPAN. -- Uche Ogbuji Principal Consultant uche.ogbuji at fourthought.com +01 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python From guido at beopen.com Fri Jul 14 18:47:03 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 11:47:03 -0500 Subject: [Python-Dev] Request for Opinions In-Reply-To: Your message of "Fri, 14 Jul 2000 09:38:59 CST." <396F3413.608AF907@fourthought.com> References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE7C4.17DEF722@prescod.net> <200007141529.KAA13625@cj20424-a.reston1.va.home.com> <396F3413.608AF907@fourthought.com> Message-ID: <200007141647.LAA14305@cj20424-a.reston1.va.home.com> > Even though I'm one of the 4XPath developers, I've largely stayed on the > sidelines because I've never been on python-dev, and I don't know how > such matters are usually considered. Guido's response gives good > guidance, and my ideas are expressed in-line. Thanks for responding! > Guido van Rossum wrote: > > > > > By the way, one of the major reasons there is no clear consensus from > > > the XML SIG yet is because we are hung up on an issue of fact. Is it > > > technically and politically feasible to put 4XPath into the Python > > > distribution. Our discussions over there will be radically different if > > > everybody over here says "sure, that's no problem." > > > > I have no idea what 4XPath is. Assuming it is a separately maintained > > and distributed 3rd party library, the answer is no for the source > > distribution and yes for binary distributions. > > Paul did suggest a couple of other options. One was to make 4XPath > easier to integrate into Python (by moving to SRE or otherwise removing > the lex/yacc dependencuy), and this is a possibility. However, I don't > know how you gauge what a "third-party" module is. My guess would be > that it's a matter of copyright. If so, that might be an obstacle, but > maybe not an insurmountable one. The other solution was to write an > XPath-lite, probably all in Python to go with minidom in the Python > distro. This would be the path of least resistance, but we are still > discussion on xml-sig the useful subset of XPath. > > Is there any clear statement of policiy for including modules? Even a > mailing-list archive entry? I don't expect one because this is > open-source/BDFL world where the policy usually lies in a > highly-respectable head, but it could certainly guide this conversation > either here or on xml-sig. My policy for including modules is that Python becomes the only distribution point of the code, and the code is maintained through the Python CVS tree (possibly by the original author). This places restrictions on the copyright notice. There are exceptions (e.g. cPickle.c has a life of its own in the Zope world, although the modules frequently get re-sync'ed), but they are rare and must serve very special purposes. Unless I'm mistaken, 4XPath leads a separate life so can't be included. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gvwilson at nevex.com Fri Jul 14 17:49:12 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 11:49:12 -0400 (EDT) Subject: [Python-Dev] Re: request for minor enhancement / linear algebra In-Reply-To: <20000714113926.B9381@thyrsus.com> Message-ID: > > Greg: So let's adopt the notation '?' for 'min' and > > 'max', as used in C* and other parallel languages. We can > > then use '?=' for the infix forms, and reserve > > 'min()' and 'max()' as built-ins for the variadic forms. > > After all, it's just an historical accident that 'min' and > > 'max' aren't treated with the same respect as '+' and 'or'. > Eric Raymond: > I would support something like this. What's really going on here, > IMO, is that you're groping towards giving Python a complete set of > notations for lattice algebra. My mathematician head likes this > idea. Greg: I was actually trying to convince people that adding operators one by one (even well-defined ones that lots of people would use) would be a bad idea. Our two main reasons for choosing Python for Software Carpentry were its simplicity (it can be taught quickly) and its availability (widely portable, open source). I (and my customers) would enjoy doing matrix algebra using mathematical notation in Python, but one-at-a-time extensions are going to reduce the chances of people choosing Python for their projects. Saying, "But you don't have to use these new operators if you don't want to," is a red herring --- if I want to understand/modify other people's code, I'll have to learn 'em (just as I've had to learn most of Perl's syntax, one painful special case at a time, in order to use the LDAP, XML, CGI, and imaging libraries). So: I would like this (linear algebra, min/max, other notation) to happen, but only if there's an extensible, scalable framework for user-defined libraries to add operators to Python, in the same way that they can now add new classes. "Extend, or extend not --- there is no special case." Thanks, Greg From effbot at telia.com Fri Jul 14 17:56:26 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 17:56:26 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <396E0B9B.DD74EF5@interet.com> <200007141437.JAA13178@cj20424-a.reston1.va.home.com> Message-ID: <01b201bfedac$12353d20$f2a6b5d4@hagrid> guido wrote: > Ignoring most that's been said in this thread, would it be possible > for the installer to detect the presence of python15.dll in the system > directory and offer to delete it? would the average user know when to click "Yes" ? From moshez at math.huji.ac.il Fri Jul 14 17:50:55 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 18:50:55 +0300 (IDT) Subject: [Python-Dev] request for minor enhancement In-Reply-To: Message-ID: On Fri, 14 Jul 2000, Greg Wilson wrote: > I would like 'min' and 'max' to be in-fix binary operators, with '__min__' > and '__max__' as the associated overloadable method names, and 'min=' and > 'max=' as the in-place forms. I find myself re-defining them in almost > every module I write, and believe that their semantics and implementation > would be unproblematic? I'm -1 on that. I'm a mathematician by schooling, and I must say max(1,2) reads much more naturally to me then 1 max 2 And "max=" just looks..... i max= 5? Come on, isn't i = max(i, 5) much more readable? Re: overloading: it is useful only for lattices, as any linear order can just use the definition max(i,j) == k iff (i==k or j==k) and i<=k and j<=k Until Python recognizes the fact that not everything is linearly ordered (AKA, rich comparisons, which should be done as a PEP really), it would be futile to deal with lattices. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From fdrake at beopen.com Fri Jul 14 17:56:00 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 11:56:00 -0400 (EDT) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396EE66F.59D0D45F@prescod.net> References: <200007140516.HAA28633@python.inrialpes.fr> <396EE66F.59D0D45F@prescod.net> Message-ID: <14703.14352.411905.934970@cj42289-a.reston1.va.home.com> [Note that I've simplified the headers, but cross-posted to python-dev and xml-sig. *Please* follow up to xml-sig!] Paul Prescod writes: > Why aren't we ready to dicuss it? I think the XML crew should discuss these things first. PyXML has generally been treated as a catch all for various neat XML stuff, but looking at it as a careful extension of the core XML support means we need to think about it that way, including the line between what's in the core and what isn't. I think it's very valuable to listen to the experts on this topic (which I think is predominantly you, the FourThought crew, and Lars, with Sean playing a secondary role since he's usually too busy to participate in the discussions). I'd like to see this discussed in the SIG with an eye to creating two non-experimental packages: 1. XML support for the Python standard library, and 2. an XML extension package that adds support for more recommendations and candidate recommendations. There should still be something like the current PyXML, which contains all the neat stuff that doesn't fall in one of the other two categories. I think a PEP and further discussions in the XML-SIG are in order before we add more material into the standard library. I'm firmly committed to getting the "right stuff" in there, but I don't want to rush headlong into adding things before they're ready and agreed upon. I'd love to see you or one of the other Python+XML leaders be editor for a PEP on this topic. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Fri Jul 14 17:57:26 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 10:57:26 -0500 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE7C4.17DEF722@prescod.net> <200007141529.KAA13625@cj20424-a.reston1.va.home.com> Message-ID: <396F3866.97D1752@prescod.net> Guido van Rossum wrote: > >... > > I have no idea what 4XPath is. Assuming it is a separately maintained > and distributed 3rd party library, the answer is no for the source > distribution and yes for binary distributions. 4XPath is currently separately maintained. If it became part of the Python source, I would expect that to become the canonical version. The issue here isn't third party libraries its quantity of source and the fact that it is a mix of Bison/FLEX/C/Python. If it were six hundred lines of pure Python I think we would have checked it in already! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Fri Jul 14 18:02:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 18:02:48 +0200 Subject: [Python-Dev] re: list comprehension / pop quiz References: <396DB5E8.6F12ACA4@per.dem.csiro.au> <20000713091546.A5094@thyrsus.com> <20000713153434.U7340@xs4all.nl> Message-ID: <01ed01bfedac$f5f81fa0$f2a6b5d4@hagrid> thomas wrote: > > plait() is *good*. > > Hmm... 'plait'. I don't even know what that means. it's yoghurt, right? From moshez at math.huji.ac.il Fri Jul 14 18:04:41 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 19:04:41 +0300 (IDT) Subject: [Python-Dev] zlib not compiled by default In-Reply-To: <14703.13152.88286.674722@bitdiddle.concentric.net> Message-ID: On Fri, 14 Jul 2000, Jeremy Hylton wrote: > I think it's significantly harder to create a .tar.gz file with a > configure script and a makefile that builds Python and all the > third-party libraries it depends on. Does the zlib source belong in > the .tar.gz? How about OpenSSL? Tcl/Tk? libc? Yes to all popular ones but "libc". > There are at least two problems with putting anything other than > Python in a .tar.gz that we distribute. First, the user who grabs it > may already have some of the third-party extensions installed. And I'm not suggesting to install any third-party extension publicly! Everything should be installled in Python's tree. > Second, we have a version-skew nightmare because each library is > updated at its own pace. No, we release a known-good version. Users who need more sophistication can build their own. > This is why Andrew is still correct! For well packaged platforms, like, well, Linux and FreeBSD. But on Solaris, it's much harder to find the readline library in an already packaged form, and the dependancy mechanism there sucks anyway. > AMK> The correct fix is to make it easy to > AMK> automatically download & install packages automatically; > AMK> distributions then become simple lists. "You want to do Web > AMK> development? Grab Cookie.py, wizard.py, DocumentTemplate, ..." > AMK> "Numeric work? NumPy, PhysicalValue, Snow, > AMK> ..." > > The distutils plus platform-specific package management like RPM and > Debian packages are the right solution. For Linux, plus add ports to cover FreeBSD. Anyone using any other UNIX is SOL right now. I agree that a "web-oriented sumo distribution", "numeric-oriented sumo distribution", .... etc. would be cool. If we had infinite resources, I'd be +10 on that -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Fri Jul 14 18:13:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 18:13:45 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> Message-ID: <02c701bfedae$7db6fd20$f2a6b5d4@hagrid> guido wrote: > > > We don't care about anything except for %d, %s, possibly %c and %x. > > > > how about: > > I would suggest to build this into PyErr_Format, which is what > everybody already uses. Instant safety. Need some more analysis of > what format codes are actually used greg's original mail mentioned %d, %i, %s, %c and %x, which is what I implemented. (if my code stumbles upon any other formatting code, it simply copies the rest of the formatting string to the output string.) it also looks as if PyErr_Format is undocumented, so we could solve this by simply writing some documentation ;-) > and support for %.200s which is currently used often. note that the code intentionally ignores the .200 part; as greg pointed out, they're only used today to make sure the message doesn't overflow PyErr_Format's buffer... but it's easy to fix. patch coming. From esr at thyrsus.com Fri Jul 14 18:21:40 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 12:21:40 -0400 Subject: [Python-Dev] re: list comprehension / pop quiz In-Reply-To: <01ed01bfedac$f5f81fa0$f2a6b5d4@hagrid>; from effbot@telia.com on Fri, Jul 14, 2000 at 06:02:48PM +0200 References: <396DB5E8.6F12ACA4@per.dem.csiro.au> <20000713091546.A5094@thyrsus.com> <20000713153434.U7340@xs4all.nl> <01ed01bfedac$f5f81fa0$f2a6b5d4@hagrid> Message-ID: <20000714122140.A9722@thyrsus.com> Fredrik Lundh : > thomas wrote: > > > plait() is *good*. > > > > Hmm... 'plait'. I don't even know what that means. > > it's yoghurt, right? No, *I* wrote `plait() is *good*.' In English, `plait' is a slightly unusual word with a meaning almost indistinguishable from `braid'. The difference is that the primary use of `braid' has to do with hair, while `plait' is associated with ribbons or other forms of ornament. -- Eric S. Raymond [W]hat country can preserve its liberties, if its rulers are not warned from time to time that [the] people preserve the spirit of resistance? Let them take arms...The tree of liberty must be refreshed from time to time, with the blood of patriots and tyrants. -- Thomas Jefferson, letter to Col. William S. Smith, 1787 From guido at beopen.com Fri Jul 14 19:14:44 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 14 Jul 2000 12:14:44 -0500 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Your message of "Fri, 14 Jul 2000 17:56:26 +0200." <01b201bfedac$12353d20$f2a6b5d4@hagrid> References: <396E0B9B.DD74EF5@interet.com> <200007141437.JAA13178@cj20424-a.reston1.va.home.com> <01b201bfedac$12353d20$f2a6b5d4@hagrid> Message-ID: <200007141714.MAA14470@cj20424-a.reston1.va.home.com> > > Ignoring most that's been said in this thread, would it be possible > > for the installer to detect the presence of python15.dll in the system > > directory and offer to delete it? > > would the average user know when to click "Yes" ? Whenever they don't have a 1.5 installation that they are interested in preserving. Hm, the registry probably points to where that would live if it existed, so the installer (or a custom program run automatically by it) can do more probing if it needs to. I guess the user should think about whether they want their Python COM things to use 1.5 or 2.0. Only the one they choose should install its DLL in the system directory; the other one should have its DLL in its own directory. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From skip at mojam.com Fri Jul 14 18:15:49 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 14 Jul 2000 11:15:49 -0500 Subject: [Python-Dev] A bit of a delay on stuff on my plate... Message-ID: <200007141615.LAA11548@dolphin.mojam.com> I ran into a little snag yesterday on the way to making a few changes (particularly the *path.commonprefix stuff). I mislaid my computer. Actually, I left it (in its briefcase, with my cell phone and Palm - in short, essentially my entire electronic existence) in a meeting in Los Altos and didn't realize it until I got to the SF airport. Fortunately, it was retrieved, but I am sans electronica for a day or two until it gets shipped out to me. I'll take care of everything that's on my plate when I get my electronic life reassembled. I've already assigned some tasks to volunteers who are helping with regression test writing for the posix, *path and sys modules. Hopefully they'll make some progress in my absence... Skip From huaiyu_zhu at yahoo.com Fri Jul 14 18:29:17 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 09:29:17 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <010401bfed6c$8d905300$0900a8c0@SPIFF> Message-ID: On Fri, 14 Jul 2000, Fredrik Lundh wrote: > Huaiyu Zhu wrote: > > Look it this way. Text processing do have their special syntaxes. > > what special syntax? > > regular expressions are a *sublanguage* in Python. everything else > is done through methods and ordinary sequence operators. Following is the quote of my previous post: > > (While a Python variant isn't something I'm enthused about, one > language can't be all things to all people, and I don't see why matrix > operations are so important as to get extra specialized operators; > lots of people use Python for text processing or for COM, so why > shouldn't special syntax be added for *those* applications? Having a > special parser also means that other matrix-specific language changes > could be made.) Well, linear algebra is not just another special domain. It is almost as elementary as arithmetic. Vectors and matrices are fundamental concepts in mathematics that underlies almost all of "scientific computation". They distill centuries of research in science and engineering, especially computation techniques. It is unlikely that adding linear algebra support would open up a flood gate for similar constructs. Look it this way. Text processing do have their special syntaxes. A string is written as "string" instead of ['s','t','r','i','n','g']. There is even the new sep.join(list). There are also lists and dicts for to build structures for discrete maths. If we had requested that new syntax for Fourier analysis or fractal generation that would be comparable to text processing or COM. Python actually has the chance of being all things to most people. The other half of the computing crowd only needs a few very basic asistance to come across. This crowd consists of people who design bridges and missiles, figure out weather patterns or DNA structures, detect credit card fraud or defects on a microchip, design speach recognition systems or network traffic balance algorithms and machines that learn to play games. Science and technology have great power to penatrate many aspects of life. And imagine if most of that is implemented in a laguage that can also be taught in schools. Huaiyu From ping at lfw.org Fri Jul 14 18:31:49 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Fri, 14 Jul 2000 09:31:49 -0700 (PDT) Subject: [Python-Dev] request for minor enhancement / linear algebra In-Reply-To: Message-ID: On Fri, 14 Jul 2000, Greg Wilson wrote: > > p.s. if min(a,b,c,d,e) is the same as min([a,b,c,d,e]), then what is the > meaning of min([a,b,c,d,e], [g,h,i,j,k])? Why, [(a,g), (b,h), (c,i), (d,j), (e,k)], of course. killing two birds with one (planet-sized) stone, -- ?!ng From huaiyu_zhu at yahoo.com Fri Jul 14 18:51:59 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 09:51:59 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <20000714162017.B7340@xs4all.nl> Message-ID: > > (X'*X)\(X'*y) > > > (What does the backslash mean? What does the tick mark mean? > > At least solve() is clear, and if i understood what H() stood > > for, it would mean more than a tick mark.) > > More importantly, how are they grouped ? Is '* a single operator, or is ' a > binary operator and * an unary operator ? Or is ' a postfix unary operator > and * the binary operator ? Does the backslash escape the opening paren for > some reason, or is it an operator on its own ? > > Oh, wait, I see it now ! It's a string literal of the new 'X' type, > containing '*X)\(X', multiplied by y! I wonder what that 'X' type string > is... Maybe a built-in regular expression ? What does this mean? s = 1.2; g = 4.4; t = 6. a = s/2 + t/3 + 1/g Ah, that means a is the operation that globally substitute '2' followed by one or more space followed by ' t' with string '3 + 1'. :-) It seems many in this list visually parse an expression in the following order, arithmetic, structure, user defined. However, for anyone who's done any numerical computation, matrix is part of arithmetic, with as much justification as complex numbers (theoretically even more justification). Whether it's user defined or built in, it has the same precedence as arithmetic. Imagine if users are forced to write the above as a = add(add(div(s,2), div(t,3)), div(1,g)) to avoid confusion with regular expression! When we talk about CP4E, don't forget math 4E. And matrix is pivotal to that goal. As to the original expression in matlab, ' is a postfix operator and \ is an ordinary binary operator, as in undergraduate math books. Huaiyu From paul at prescod.net Fri Jul 14 18:51:12 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 11:51:12 -0500 Subject: [Python-Dev] Request for Opinions References: <396E91DC.D767EF6F@prescod.net> <20000714001539.T29590@lyra.org> <396EE6B3.B86BED76@prescod.net> <14703.11095.264917.268373@bitdiddle.concentric.net> Message-ID: <396F4500.E80ABB39@prescod.net> Jeremy Hylton wrote: > > ... > > Seriously -- you've already seen Guido's response. I think there's no > chance of adding third-party code to the Python CVS repository or > source distribution. The only way I could imagine it happening is if > there was strong consensus from the XML SIG. So Greg's suggestion is > a good one. I don't see the XML SIG overriding/convincing Guido on that issue, so it wasn't really the issue I was asking about. I need to know what sorts of packages Python's maintainers are willing to adopt. As extreme examples, if I write a 50,000 line persistence package that many people asked for, would it go into Python? If I write an extension module in Pascal, could that go into Python? Obviously the 4XPath example is not that extreme so I'm trying to get opinions. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 18:51:21 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 11:51:21 -0500 Subject: [Python-Dev] linear algebra References: Message-ID: <396F4509.30069096@prescod.net> Greg Wilson wrote: > > .... Saying, "But you don't have to use these new operators if > you don't want to," is a red herring --- if I want to understand/modify > other people's code, I'll have to learn 'em (just as I've had to learn > most of Perl's syntax, one painful special case at a time, in order to use > the LDAP, XML, CGI, and imaging libraries). > > So: I would like this (linear algebra, min/max, other notation) to happen, > but only if there's an extensible, scalable framework for user-defined > libraries to add operators to Python, in the same way that they can now > add new classes. I don't want to come to someone else's code and have to learn a bunch of operators that they invented, for the same reason that you don't want to learn all of Perl's built-in special cases. I would support a framework to compile and load well-defined, independent, Python-based languages (PyMatrix, XSLPy) onto a shared Python virtual machine. OTOH, I would freak out if I loaded a module that proported to be Python and found it had a bunch of operators not defined in the Python specification. I'll leave that experiment to REBOL and see what happens. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Fri Jul 14 18:56:54 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 11:56:54 -0500 Subject: [Python-Dev] Request for Opinions References: <200007140516.HAA28633@python.inrialpes.fr> <396EE66F.59D0D45F@prescod.net> <14703.14352.411905.934970@cj42289-a.reston1.va.home.com> Message-ID: <396F4656.6396D7C8@prescod.net> "Fred L. Drake, Jr." wrote: > > I think a PEP and further discussions in the XML-SIG are in order > before we add more material into the standard library. I'm firmly > committed to getting the "right stuff" in there, but I don't want to > rush headlong into adding things before they're ready and agreed > upon. My impression was that we discussed this in the SIG last week but the discussion petered out when we realized that none of us knew whether it was even feasible to add something the size of 4XPath to Python. Nobody could say it would or would not be a problem which makes planning impossible and further discussion a useless cycle of "wouldn't it be nice, but it may or may not be possible, but wouldn't it be nice, but it may or may not be ...". -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From fdrake at beopen.com Fri Jul 14 19:06:43 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 13:06:43 -0400 (EDT) Subject: [Python-Dev] Request for Opinions In-Reply-To: <396F4656.6396D7C8@prescod.net> References: <200007140516.HAA28633@python.inrialpes.fr> <396EE66F.59D0D45F@prescod.net> <14703.14352.411905.934970@cj42289-a.reston1.va.home.com> <396F4656.6396D7C8@prescod.net> Message-ID: <14703.18595.926991.596182@cj42289-a.reston1.va.home.com> Paul Prescod writes: > My impression was that we discussed this in the SIG last week but the > discussion petered out when we realized that none of us knew whether it > was even feasible to add something the size of 4XPath to Python. Nobody > could say it would or would not be a problem which makes planning Then this falls into the "Fred's falling behind on his email again" category, and my remarks can be safely ignored until I've done my homework. Sorry for the confusion. ;( But I still think a PEP documenting the rationale for any decision is valuable. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From huaiyu_zhu at yahoo.com Fri Jul 14 19:11:29 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 10:11:29 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: Message-ID: On Fri, 14 Jul 2000, Ka-Ping Yee wrote: > > You are almost there. :-) The current MatPy expression is > > solve (X.H() * X, X.H() * y) > > I was about to suggest something similar, but you beat me to it. > > I think that expression looks great. If you can say it that > concisely, i don't think you need to throw in extra operators > at all (let alone a half-dozen of them that are incomprehensible > to anyone outside of the Matlab community). Well, the Matlab community includes most scientists and enginears and educators and students of science and engineering who can afford Matlab, or who has enough computer literacy to know how to install Octave (or to install Linux so that Octave comes with it). Many are learning Linux just for this purpose alone. At least several of my former students did. Back to topic. Here's the quote from my c.l.py post: This is not a call for a special language for matrix only. But we do need enough binary operators to override with. The additional operators might be useful at other places as well. In matlab the following operations are all different from each other a+b a.+b a-b a.-b a*b a.*b a/b a./b a\b a.\b a^b a.^b What python operators can we override for them all? Just one additional symbol for so many new binary operators is a good bargain, IMO. I think cleanness is one of the main virtue of python, but it is lacking in numerical computation. To give an example of the difference it makes, I'll quote from my original post asking for matrix in python (with corrections) [example of matlab and python codes you've seen. end quote] So why do we need new operators? Because we are using * as matrixmultiply so we need .* as elementwise multiply. From esr at thyrsus.com Fri Jul 14 19:36:20 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 13:36:20 -0400 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: ; from huaiyu_zhu@yahoo.com on Fri, Jul 14, 2000 at 10:11:29AM -0700 References: Message-ID: <20000714133620.A10054@thyrsus.com> Huaiyu Zhu : > This is not a call for a special language for matrix only. But we do need > enough binary operators to override with. The additional operators might be > useful at other places as well. > > In matlab the following operations are all different from each other > > a+b a.+b > a-b a.-b > a*b a.*b > a/b a./b > a\b a.\b > a^b a.^b > > What python operators can we override for them all? Just one additional > symbol for so many new binary operators is a good bargain, IMO. Put this way, I'm more inclined to support it. I might even be tempted to add .| and .& for lattice algebras. I agree that supporting user-defined syntax threatens to fragment the language. To avoid that, perhaps it would be best to leave what are in effect user-definable hooks in Python's lexical space. This could address Greg's desire for an infix max and min as well. The design question becomes: what undefined binary tokens do we want to add the the language core? With what precedence? What is the compiler to assume about associativity? -- Eric S. Raymond Ideology, politics and journalism, which luxuriate in failure, are impotent in the face of hope and joy. -- P. J. O'Rourke From effbot at telia.com Fri Jul 14 19:36:16 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 19:36:16 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <036101bfedba$048fdbe0$f2a6b5d4@hagrid> before this goes out of hand, let me just say that there might be good reasons for adding more operators for Python, but your "why cannot I have special syntax when everyone else got it" approach doesn't really work: > What does this mean? > > s = 1.2; g = 4.4; t = 6. > a = s/2 + t/3 + 1/g > > Ah, that means a is the operation that globally substitute '2' followed by > one or more space followed by ' t' with string '3 + 1'. :-) huh? Python doesn't support the s/// syntax (you're thinking about Perl or awk, right?) ...and: > a\b a.\b huh? Python doesn't have a backslash operator. ...and: > Look it this way. Text processing do have their special syntaxes. A string > is written as "string" instead of ['s','t','r','i','n','g']. huh? Python doesn't have a character type (C, C++) > There is even the new sep.join(list). huh? that's a method call, not special syntax... > If we had requested that new syntax for Fourier analysis or fractal > generation that would be comparable to text processing or COM. huh? Python doesn't have special syntax for text processing (Perl, Icon) or COM (C#, Visual Basic) if you cannot get your Python facts right, why should I trust you when you say that "Python needs this or that"? From effbot at telia.com Fri Jul 14 19:54:43 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 19:54:43 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> Message-ID: <038101bfedbc$983c81c0$f2a6b5d4@hagrid> guido wrote: > Need some more analysis of what format codes are actually used, > and support for %.200s which is currently used often. possibly stupid idea: would it make sense to add custom formatting codes, like: %S => char*, string, clip if excessively long %T => PyObject*, show name of type, clip if excessively long where "clip" means: truncate at 80 characters, and add "..." to indicate that the string was truncated. this covers most of the places where %.\d+s are used (in the Python core, at least...) From gvwilson at nevex.com Fri Jul 14 19:48:50 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Fri, 14 Jul 2000 13:48:50 -0400 (EDT) Subject: [Python-Dev] Re: linear algebra In-Reply-To: <396F4509.30069096@prescod.net> Message-ID: > > Greg Wilson wrote: > > > > .... Saying, "But you don't have to use these new operators if > > you don't want to," is a red herring --- if I want to understand/modify > > other people's code, I'll have to learn 'em (just as I've had to learn > > most of Perl's syntax, one painful special case at a time, in order to use > > the LDAP, XML, CGI, and imaging libraries). > > > > So: I would like this (linear algebra, min/max, other notation) to happen, > > but only if there's an extensible, scalable framework for user-defined > > libraries to add operators to Python, in the same way that they can now > > add new classes. > Paul Prescod wrote: > > I don't want to come to someone else's code and have to learn a bunch > of operators that they invented, for the same reason that you don't > want to learn all of Perl's built-in special cases. Greg Wilson writes: I strongly agree. If there isn't a "new operator definition" mechanism that maintains Python's simplicity, then I believe we should stick to functions and methods, rather than introducing "just a few" new operators for linear algebra (or regular expressions, or [your favorite topic goes here]). > Eric Raymond wrote: > > I agree that supporting user-defined syntax threatens to fragment the > language. To avoid that, perhaps it would be best to leave what are in > effect user-definable hooks in Python's lexical space. > > The design question becomes: what undefined binary tokens do we want > to add the the language core? With what precedence? What is the > compiler to assume about associativity? This is an interesting alternative I hadn't thought of --- add operators, with associated special methods and in-place assignment forms, but do not provide a "standard" definition (i.e. leave all functionality open to the user). Thanks, Greg From paul at prescod.net Fri Jul 14 20:02:09 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 13:02:09 -0500 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: <20000714133620.A10054@thyrsus.com> Message-ID: <396F55A1.10828D06@prescod.net> "Eric S. Raymond" wrote: > > ... > > I agree that supporting user-defined syntax threatens to fragment the language. > To avoid that, perhaps it would be best to leave what are in effect > user-definable hooks in Python's lexical space. I really don't see how it is better to fragment the semantic space by encouraging people to project random meanings onto operators with no intrinsic meanings. Given the choice, I would prefer to have the language explicitly fragment into domain-specific variants with their own grammars. At least then I know that I'm really dealing with a new language that is Pythonic, but not Python. DTML, a Python XSL and this matrix Python are examples of languages that might benefit from an easy way to be hosted on the Python VM and interact with pure Python modules. Also a statically typed Python variant might be intersting. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From akuchlin at mems-exchange.org Fri Jul 14 20:02:36 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 14 Jul 2000 14:02:36 -0400 Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: <20000714133620.A10054@thyrsus.com>; from esr@thyrsus.com on Fri, Jul 14, 2000 at 01:36:20PM -0400 References: <20000714133620.A10054@thyrsus.com> Message-ID: <20000714140236.H28819@kronos.cnri.reston.va.us> On Fri, Jul 14, 2000 at 01:36:20PM -0400, Eric S. Raymond wrote: >Huaiyu Zhu : >> This is not a call for a special language for matrix only. But we do need >> enough binary operators to override with. The additional operators might be >> useful at other places as well. > >I agree that supporting user-defined syntax threatens to fragment the language. >To avoid that, perhaps it would be best to leave what are in effect >user-definable hooks in Python's lexical space. Huaiyu Zhu thinks that better matrix operators will attract a significant new of new users; I'm doubtful of this claim. We're both just guessing, since neither of us has actual evidence to support our respective points of view. Given that uncertainty, there seems little impetus for adding new operators; Python will have to live with them for a long time, even if the matrix work withers after a short time, or never really catches on. It should be possible to try out new operators *right now*, with no core changes. I believe Jeremy's compiler code, written in pure Python, can parse a module and generate the corresponding bytecodes. Therefore, you could take that code and hack it to support 'a .| b', by generating equivalent code to a.__dotbar__(b), or whatever. The only visible difference is that some error messages would be obscure; 2 .| 1 would get a '2 has no attribute __dotbar__' exception; this isn't significant. So, rather than add a whole bunch of new operators to the core, I'd first want to see the alternative syntax implemented through a hacked parser and *in use by a significant community*, and then we can consider what bits from it to add to the core. --amk From esr at thyrsus.com Fri Jul 14 20:47:12 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 14 Jul 2000 14:47:12 -0400 Subject: [Python-Dev] Re: linear algebra In-Reply-To: ; from gvwilson@nevex.com on Fri, Jul 14, 2000 at 01:48:50PM -0400 References: <396F4509.30069096@prescod.net> Message-ID: <20000714144712.A10278@thyrsus.com> Greg Wilson : > This is an interesting alternative I hadn't thought of --- add operators, > with associated special methods and in-place assignment forms, but do not > provide a "standard" definition (i.e. leave all functionality open to the > user). Yes. This steers a Pythonic middle path between user-definable syntax (too big a can of worms) and doing nothing at all to help out constituencies like the MatLab people. Overloading otherwise undefined special method names for operators is a well-understood way to add functionality to classes. Lrt's use it. -- Eric S. Raymond Rapists just *love* unarmed women. And the politicians who disarm them. From jeremy at beopen.com Fri Jul 14 20:40:43 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 14:40:43 -0400 (EDT) Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: <20000714140236.H28819@kronos.cnri.reston.va.us> References: <20000714133620.A10054@thyrsus.com> <20000714140236.H28819@kronos.cnri.reston.va.us> Message-ID: <14703.24235.5194.840166@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> It should be possible to try out new operators *right now*, AMK> with no core changes. I believe Jeremy's compiler code, AMK> written in pure Python, can parse a module and generate the AMK> corresponding bytecodes. Therefore, you could take that code AMK> and hack it to support 'a .| b', by generating equivalent code AMK> to a.__dotbar__(b), or whatever. The only visible difference AMK> is that some error messages would be obscure; 2 .| 1 would get AMK> a '2 has no attribute __dotbar__' exception; this isn't AMK> significant. There is one hitch. There is a corresponding bytecode op for each of the builtin operators. When Python sees 'm * x + b', it generates BINARY_MULTIPLY and BINARY_ADD opcode. If you wanted to add a new binary operator, you couldn't add a new opcode for it. Instead, you'd have to generate explicit instructions to check for the attr and then call it. This isn't a big problem, although the resulting interpreter is probably slower than one with builtin opcodes. Not sure how much slower. AMK> So, rather than add a whole bunch of new operators to the core, AMK> I'd first want to see the alternative syntax implemented AMK> through a hacked parser and *in use by a significant AMK> community*, and then we can consider what bits from it to add AMK> to the core. This seems like a reasonable approach to me. You basically build a frontend that compiles the Python+extensions into standard Python bytecode. Jeremy From moshez at math.huji.ac.il Fri Jul 14 20:41:27 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 14 Jul 2000 21:41:27 +0300 (IDT) Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: <14703.24235.5194.840166@bitdiddle.concentric.net> Message-ID: On Fri, 14 Jul 2000, Jeremy Hylton wrote: > AMK> So, rather than add a whole bunch of new operators to the core, > AMK> I'd first want to see the alternative syntax implemented > AMK> through a hacked parser and *in use by a significant > AMK> community*, and then we can consider what bits from it to add > AMK> to the core. > > This seems like a reasonable approach to me. You basically build a > frontend that compiles the Python+extensions into standard Python > bytecode. Wouldn't it be better to compile the Python+extensions into standard Python? Something that would work at the parse tree level? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From jeremy at beopen.com Fri Jul 14 20:49:24 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 14:49:24 -0400 (EDT) Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: References: <14703.24235.5194.840166@bitdiddle.concentric.net> Message-ID: <14703.24756.648338.160796@bitdiddle.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> On Fri, 14 Jul 2000, Jeremy Hylton wrote: AMK> So, rather than add a whole bunch of new operators to the core, AMK> I'd first want to see the alternative syntax implemented AMK> through a hacked parser and *in use by a significant AMK> community*, and then we can consider what bits from it to add AMK> to the core. >> This seems like a reasonable approach to me. You basically >> build a frontend that compiles the Python+extensions into >> standard Python bytecode. MZ> Wouldn't it be better to compile the Python+extensions into MZ> standard Python? Something that would work at the parse tree MZ> level? That's a lot of work! I'm not aware of any tools that generate Python source code from a parser tree. The Python bytecode is so high-level that it is pretty easy to understand. The parse tree generated by Python's builtin parser is really hard to work with. So it definitely makes sense to use the transformer that Greg & Bill wrote to get a decent abstract syntax. At that point, you can either generate bytecode directly or write a new code generate that generates source from the AST. Jeremy From alex_c at MIT.EDU Fri Jul 14 22:30:14 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Fri, 14 Jul 2000 16:30:14 -0400 (EDT) Subject: [Python-Dev] posixpath module. Message-ID: <200007142030.QAA156803@w20-575-116.mit.edu> (Cc'd to python-dev, this time, since you're incommunicado.) I have a preliminary version of test_posixpath.py. You can see it at http://puffin.lcs.mit.edu:8080/Lib/test/test_posixpath.py I don't have any negative tests with garbage input. I'm thinking that that's not so important anyway, because in python programs tend to break with garbage input, but of course I'm really punting mainly out of temporary boredom. :) Should posixpath.normpath resolve '/..' to '/'? My linux box does. Alex. From thomas at xs4all.net Fri Jul 14 22:36:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 14 Jul 2000 22:36:08 +0200 Subject: [Python-Dev] posixpath module. In-Reply-To: <200007142030.QAA156803@w20-575-116.mit.edu>; from alex_c@MIT.EDU on Fri, Jul 14, 2000 at 04:30:14PM -0400 References: <200007142030.QAA156803@w20-575-116.mit.edu> Message-ID: <20000714223607.D7340@xs4all.nl> On Fri, Jul 14, 2000 at 04:30:14PM -0400, Alex Coventry wrote: > Should posixpath.normpath resolve '/..' to '/'? My linux box does. Yes. At least, every UNIX box I ever heard of does that, and I'm sure it's listed in some standard or other. (the '.' and '..' directories on UNIX filesystems aren't magic, they are just hard links to the appropriate directory. '..' on '/' simply points to the same directory as '.' on '/', and '/' itself.) I think the same goes for URLs, though I'm not as sure on that. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Fri Jul 14 22:48:45 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 14 Jul 2000 16:48:45 -0400 (EDT) Subject: [Python-Dev] Patch Manager screen scraper Message-ID: <14703.31917.642280.604366@bitdiddle.concentric.net> I wrote a small script to extract patch meta data from the SourceForge patch manager and install them in a local Postgres database. This code might be useful for other folks, although the second half (the Postgres half) depends on having PyGreSQL installed. I'm posting the current source here in case anyone else wants to fiddle. It's definitely rough. Attached is the code and the DB schema. Jeremy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patchtool.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-schema.txt URL: From paul at prescod.net Fri Jul 14 22:56:52 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 14 Jul 2000 15:56:52 -0500 Subject: [Python-Dev] posixpath module. References: <200007142030.QAA156803@w20-575-116.mit.edu> Message-ID: <396F7E94.FF4D4C0B@prescod.net> Alex Coventry wrote: > > (Cc'd to python-dev, this time, since you're incommunicado.) Skip is having computer problems. Lost computer problems. :) -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Fri Jul 14 23:02:30 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 14 Jul 2000 23:02:30 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> <02c701bfedae$7db6fd20$f2a6b5d4@hagrid> Message-ID: <000d01bfedd7$122db480$f2a6b5d4@hagrid> > patch coming. not quite ready to be checked in, but good enough to take on a test drive: http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From gstein at lyra.org Fri Jul 14 23:18:02 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 14 Jul 2000 14:18:02 -0700 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007141714.MAA14470@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 12:14:44PM -0500 References: <396E0B9B.DD74EF5@interet.com> <200007141437.JAA13178@cj20424-a.reston1.va.home.com> <01b201bfedac$12353d20$f2a6b5d4@hagrid> <200007141714.MAA14470@cj20424-a.reston1.va.home.com> Message-ID: <20000714141801.T29590@lyra.org> On Fri, Jul 14, 2000 at 12:14:44PM -0500, Guido van Rossum wrote: > > > Ignoring most that's been said in this thread, would it be possible > > > for the installer to detect the presence of python15.dll in the system > > > directory and offer to delete it? > > > > would the average user know when to click "Yes" ? > > Whenever they don't have a 1.5 installation that they are interested > in preserving. Hm, the registry probably points to where that would > live if it existed, so the installer (or a custom program run > automatically by it) can do more probing if it needs to. Who says they have a 1.5 installation on their system? Maybe the DLL arrived through some third-party application that happens to use/embed Python. Any python*.dll probably should be ignored. Cheers, -g -- Greg Stein, http://www.lyra.org/ From huaiyu_zhu at yahoo.com Fri Jul 14 23:28:09 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 14:28:09 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <036101bfedba$048fdbe0$f2a6b5d4@hagrid> Message-ID: On Fri, 14 Jul 2000, Fredrik Lundh wrote: > before this goes out of hand, let me just say that there might be good > reasons for adding more operators for Python, but your "why cannot I > have special syntax when everyone else got it" approach doesn't really > work: > Well, these quotings are getting out of hand. Please read the c.l.py thread and see where all this comes from. My posts have been repeatedly forwarded here out of context. Note that the (X'*X)\(X'*y) syntax is Matlab, not python. I mentioned text processing and COM because it was claimed that requesting additional binary operators for matrix is similar to requesting special syntax for text processing and COM. I have repeatedly stated here and elsewhere, that I do NOT want special syntax. I only want a few more binary operators that bear resemblance to the existing ones. I want them in such a way that as long as you do not use them, NOTHING would be changed. However several people continuously said: you cannot get that because that's too much of a request, however you should get your own complete parser so that you can make any syntax as you want, even if it is incompatible. I find this very strange. Maybe the audience here do not appreciate it, but "matrix people" are not some aliens, and matrix computation need to be compatible with everything else in python. If I'm only going to do matrix but nothing else, why wouldn't I just stick with octave? > if you cannot get your Python facts right, why should I trust you > when you say that "Python needs this or that"? Maybe if you read all the original posts you would find these "wrong facts" just disappears. You might also find that many people did not get the fact right about what is being asked in these threads. One sure way to get the facts right is to get MatPy, unar, type make install, and see what you get. It's not that difficult, at least easier than writing these emails. Huaiyu -- Huaiyu Zhu hzhu at users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net From huaiyu_zhu at yahoo.com Sat Jul 15 00:04:52 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 15:04:52 -0700 (PDT) Subject: [Fwd: Re: [Python-Dev] Introducing new operators for matrix computation] In-Reply-To: <396F5819.D3C20E40@prescod.net> Message-ID: I like this idea as well. I only need to clarify two things: 1. Is this available right now? Where to get it? 2. Will this be guaranteed to be compatible with future development of python? My doubt is: If this is the case why the augmented assinment needs to be a patch? The development of MatPy has been quite rapid since it started over a month ago. Right now we are ready to go into feature addition phase that will be even faster. The only uncertainty is what operators we will have. We got our own patch yesterday. We'd like to settle on this very quickly. Once these are settled, we'll just included it in the MatPy distribution. After we get enough usage the whole NumPy-MatPy packages might be included in core python just as string or re. Given that there is a conference next week, perhaps we can't fix it in a week. But we'll decide soon after that. I will not argue any more here about how many new users python may attract with matrix. With proper tools I would be able to prove by fact. Although we seek the core developer opinions here, we do not really need approval to go ahead. But the danger is that a bad choice may stuck with python for ever when this thing gets incorporated into main distribution. Switching the meaning of the operators would be almost completely impossible, unlike the regex and re case. So even if you don't make use of matrix now, you might still want to give a thought on how it should be done. Huaiyu On Fri, 14 Jul 2000, Paul Prescod wrote: > I like this idea! > > -------- Original Message -------- > Subject: Re: [Python-Dev] Introducing new operators for matrix > computation > Date: Fri, 14 Jul 2000 14:02:36 -0400 > From: Andrew Kuchling > Reply-To: akuchlin at mems-exchange.org > To: python-dev at python.org > References: > > <20000714133620.A10054 at thyrsus.com> > > On Fri, Jul 14, 2000 at 01:36:20PM -0400, Eric S. Raymond wrote: > >Huaiyu Zhu : > >> This is not a call for a special language for matrix only. But we do need > >> enough binary operators to override with. The additional operators might be > >> useful at other places as well. > > > >I agree that supporting user-defined syntax threatens to fragment the language. > >To avoid that, perhaps it would be best to leave what are in effect > >user-definable hooks in Python's lexical space. > > Huaiyu Zhu thinks that better matrix operators will attract a > significant new of new users; I'm doubtful of this claim. We're both > just guessing, since neither of us has actual evidence to support our > respective points of view. Given that uncertainty, there seems little > impetus for adding new operators; Python will have to live with them > for a long time, even if the matrix work withers after a short time, > or never really catches on. > > It should be possible to try out new operators *right now*, with no > core changes. I believe Jeremy's compiler code, written in pure > Python, can parse a module and generate the corresponding bytecodes. > Therefore, you could take that code and hack it to support 'a .| b', > by generating equivalent code to a.__dotbar__(b), or whatever. The > only visible difference is that some error messages would be obscure; > 2 .| 1 would get a '2 has no attribute __dotbar__' exception; this > isn't significant. > > So, rather than add a whole bunch of new operators to the core, I'd > first want to see the alternative syntax implemented through a hacked > parser and *in use by a significant community*, and then we can > consider what bits from it to add to the core. > > --amk > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From alex_c at MIT.EDU Sat Jul 15 00:08:39 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Fri, 14 Jul 2000 18:08:39 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <396F7E94.FF4D4C0B@prescod.net> (message from Paul Prescod on Fri, 14 Jul 2000 15:56:52 -0500) References: <200007142030.QAA156803@w20-575-116.mit.edu> <396F7E94.FF4D4C0B@prescod.net> Message-ID: <200007142208.SAA157802@w20-575-116.mit.edu> > Skip is having computer problems. Lost computer problems. :) Yeah, sorry, that's what I meant. :) Alex. From fdrake at beopen.com Sat Jul 15 00:26:49 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 18:26:49 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <200007142030.QAA156803@w20-575-116.mit.edu> References: <200007142030.QAA156803@w20-575-116.mit.edu> Message-ID: <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> Alex Coventry writes: > I don't have any negative tests with garbage input. I'm thinking that > that's not so important anyway, because in python programs tend to break > with garbage input, but of course I'm really punting mainly out of > temporary boredom. :) If an exception is expected, it should test that it gets the right failure. This is especially important in a regression test, so that failing cases don't silently becoming non-failing cases. > Should posixpath.normpath resolve '/..' to '/'? My linux box does. I don't understand; in what context? "/" on my box contains "..", which is itself. There's nothing special about it in the "path algebra," but it may be a useful reduction. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From huaiyu_zhu at yahoo.com Sat Jul 15 00:44:20 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 15:44:20 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <20000714133620.A10054@thyrsus.com> Message-ID: On Fri, 14 Jul 2000, Eric S. Raymond wrote: > Huaiyu Zhu : > > This is not a call for a special language for matrix only. But we do need > > enough binary operators to override with. The additional operators > > might be useful at other places as well. > > > > In matlab the following operations are all different from each other > > > > a+b a.+b > > a-b a.-b > > a*b a.*b > > a/b a./b > > a\b a.\b > > a^b a.^b > > > > What python operators can we override for them all? Just one additional > > symbol for so many new binary operators is a good bargain, IMO. > > Put this way, I'm more inclined to support it. I might even be tempted > to add .| and .& for lattice algebras. > > I agree that supporting user-defined syntax threatens to fragment the > language. To avoid that, perhaps it would be best to leave what are in > effect user-definable hooks in Python's lexical space. Completely agree. That's what the issue is about. More information is given below in my quote from c.l.p. > This could address Greg's desire for an infix max and min as well. > > The design question becomes: what undefined binary tokens do we > want to add the the language core? With what precedence? What is > the compiler to assume about associativity? Given what's quoted below, would you think . is the best choice? Not to say its attractiveness to all the matlab crowd. ------------------------ start quote ----------------------------- On Thu, 13 Jul 2000 16:35:57 -0600, Bjorn Pettersen wrote: >I fully understand your desire to make the syntax for your domain >specific notation as intuitive as possible. For people who don't know >matlab however, .+ et. al. have no pre-defined meaning. Since + has a >predefined meaning of addition, most people when overloading it will do >"additive" things with it, e.g. concatenating to sequences. Since .+ >doesn't have a pre-defined meaning I'm afraid people will override it >with random semantics... > >If you want to do matlab syntax, perhaps a better approach would be to >write your own expression parser? > Hmm, I see what you mean: If a certain syntax is not meaningful to all the users, don't expose it to all of them lest they came up with random incompatible usages. Sounds reasonable, but ... Point 1. We _can_ assign a universal meaning to dot operators, as "componentwise operators". For example [1, 2] + [3, 4] # [1, 2, 3, 4] [1, 2] .+ [3, 4] # [4, 6] ['a','b'] * 2 # ['a','b','a','b'] ["a","b"] .* 2 # ['aa', 'bb'] {'a':1, 'b':1} .+ {'a':1, 'c':1} # {'a':2, 'b':1, 'c': 1} 'abc' .+ 'def' # exception: you must define string.__dot_add__ This could be useful in all sorts of situations. Of course people can still override it with incompatible meanings at their own discretion, just as they could do to anything else. Point 2. If users in completely disjoint domains override a certain type of binary operators with incompatible meanings, is there great harm? Providing a few operators for user adoptation might even prevent grotesque overriding of more core operators. After all, there is almost endless supply of names for classes, modules, function and so on, but there is almost no binary operators free for adoption. Point 3. A special parser could work, (and if the patch under discussion is not accepted we'll just keep it around for use with matrix computation), as long as it is made quite orthogonal to other parts of the language. This way people using it will not be left behind other developments of the language. However, I still think a unified parser with overridable operators present a smaller risk of fragmentation. Huaiyu From alex_c at MIT.EDU Sat Jul 15 00:42:49 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Fri, 14 Jul 2000 18:42:49 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> (fdrake@beopen.com) References: <200007142030.QAA156803@w20-575-116.mit.edu> <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> Message-ID: <200007142242.SAA12205@mint-square.mit.edu> > If an exception is expected, it should test that it gets the right > failure. This is especially important in a regression test, so that > failing cases don't silently becoming non-failing cases. You're right, of course. I'll get back to them at some point. > in what context? "/" on my box contains "..", which is itself. > There's nothing special about it in the "path algebra," but it may > be a useful reduction. For instance: >>> import posixpath >>> posixpath.normpath('/..') '/..' I would have thought '/' would be a better result to return. My impression was that normpath is used to tell whether two paths are actually the same, and if that's the case, its current behaviour is going to give false negatives. On the other hand, the code seems to explicitly ignore multiple leading /'s, and that will also give some false mismatches, so I must be confused somewhere... Alex. From effbot at telia.com Sat Jul 15 01:06:41 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 01:06:41 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <000901bfede8$2d0103a0$f2a6b5d4@hagrid> Huaiyu Zhu wrote: > Given what's quoted below, would you think . is the best choice? if what you're saying means that: >>> 1.+2. 3.0 becomes: >>> 1.+2. Traceback (innermost last): File "", line 1, in ? TypeError: __dotadd__ nor __rdotadd__ defined for these operands it's clearly not a good choice. From huaiyu_zhu at yahoo.com Sat Jul 15 01:33:13 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 16:33:13 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <000901bfede8$2d0103a0$f2a6b5d4@hagrid> Message-ID: On Sat, 15 Jul 2000, Fredrik Lundh wrote: > Huaiyu Zhu wrote: > > Given what's quoted below, would you think . is the best choice? > > if what you're saying means that: > > >>> 1.+2. > 3.0 > > becomes: > > >>> 1.+2. > Traceback (innermost last): > File "", line 1, in ? > TypeError: __dotadd__ nor __rdotadd__ defined for these operands > > it's clearly not a good choice. > > > To quote from my c.l.py post: On Fri, 14 Jul 2000 11:38:51 -0600, Bjorn Pettersen wrote: > >Well, this could actually be generally useful, but not with the .+ >syntax (since the dot would interfer with methods on the sequence >object). My impression from the python-dev list is that this is not the case. Some say it is easy to distinguish a. + b a .+ b Some say it is difficult. But the first is a syntax error anyway. The only real danger is 3. + a 3 .+ a But in this case pointwise operation does not make sense. So I suppose the following rules would resolve all the ambiguities: Dot binds with preceding number. Otherwise it binds with following operator. Otherwise it is a member indicator. Otherwise it is syntax error. Examples: 2.+b a.+b <-- only this is new a.b a.3 Huaiyu From fdrake at beopen.com Sat Jul 15 01:52:50 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 14 Jul 2000 19:52:50 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <200007142242.SAA12205@mint-square.mit.edu> References: <200007142030.QAA156803@w20-575-116.mit.edu> <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> <200007142242.SAA12205@mint-square.mit.edu> Message-ID: <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> Alex Coventry writes: > I would have thought '/' would be a better result to return. My I agree, feel free to propose a patch! > impression was that normpath is used to tell whether two paths are > actually the same, and if that's the case, its current behaviour is > going to give false negatives. On the other hand, the code seems to > explicitly ignore multiple leading /'s, and that will also give some > false mismatches, so I must be confused somewhere... I'd call that a bug until someone can justify the current behavior. I'd love to see a patch for that as well. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From huaiyu_zhu at yahoo.com Sat Jul 15 02:09:20 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 17:09:20 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <036101bfedba$048fdbe0$f2a6b5d4@hagrid> Message-ID: On Fri, 14 Jul 2000, Fredrik Lundh wrote: > > is written as "string" instead of ['s','t','r','i','n','g']. > > huh? Python doesn't have a character type (C, C++) Likewise, matlab doesn't have a number type, only matrices. Generalization from number to matrix is definitely a smaller step than generalization from character to string. Matrix is more suitable for a builtin type than complex number is, because it is conceptually much simpler. The whole field of linear algebra is built on eight statements, two of them can be derived from the other. You can't even define all the concepts like upper or lower case, white space, tab, symbol, character and number and identifier and concatenation and so on in just eight statements, let alone to state all the rules of text processing. The issue arises because one generalization is more familiar to one group of people but the other is to other people. And people tend to regard what they are not familiar with as "specific domain". Huaiyu From moshez at math.huji.ac.il Sat Jul 15 02:43:42 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 03:43:42 +0300 (IDT) Subject: [Python-Dev] Introducing new operators for matrix computation In-Reply-To: <14703.24756.648338.160796@bitdiddle.concentric.net> Message-ID: On Fri, 14 Jul 2000, Jeremy Hylton wrote: > I'm not aware of any tools that generate Python > source code from a parser tree. Sounds like an interesting project. Hmmmm....another item on the todo list. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From HZhu at knowledgetrack.com Sat Jul 15 03:42:11 2000 From: HZhu at knowledgetrack.com (Huaiyu Zhu) Date: Fri, 14 Jul 2000 18:42:11 -0700 (PDT) Subject: [Python-Dev] List comprehension syntax Message-ID: I just read the whole thread on list comprehension. Here's my proposed syntax, given by examples. This notation is very safe as it has been used in mathematics for years. a = [1, 2, 3]; b = [4, 5, 6] #---------------------------------------------------- # Parallel loops: c = tuples(a,b) # c = [(1,4), (2,5), (3,6)] c = lists(a,b) # c = [[1,4], [2,5], [3,6]] c = xtuples(a,b) # c = ((1,4), (2,5), (3,6)) c = xlists(a,b) # c = ([1,4], [2,5], [3,6]) #---------------------------------------------------- # prefix x has the same effect as in xrange in loops for pair in xtuples(a,b): print pair # print (1,4); print (2,5); print (3,6) for pair in xtuples(a,b): print pair # print [1,4]; print [2,5]; print [3,6] for i, j in xlists(a,b): pass #---------------------------------------------------- # list comprehension - all elements that satisfy conditions c = [x*2, y: x, y in xtuples(a,b)] # c = [(2,4), (4,5), (6,6)] c = [[x, y]: x, y in xtuples(a,b)] # c = [[1,4], [2,5], [3,6]] c = [x: x in a+b; x%2=0] # c = [2, 4, 6] c = [x in a+b: x%2=0] # ditto c = [x,y: x, y in xtuples(a,b); x>1; x+y<8] # c = [(2,5)] c = [x,y in xtuples(a,b): x>1; x+y<8] # ditto #---------------------------------------------------- # Corresponding to old syntax c = [x in a: f(x)] # c = filter(f, x) c = [f(x): x in a] # c = map(f, a) #---------------------------------------------------- # Iterated loops (all elements that satisfy condition): c = [x, y: x in a; y in b] # c = [(1,4), (1,5), (1,6), (2,4), (2,5), ...] c = [[x,y]: x in a; y in b] # c = [[1,4], [1,5], [1,6], [2,4], [2,5], ...] for i, j in [i, j: i in a; j in b]: print i, j # print 1,4; print 1,5; ... for i in a; j in b: print i, j # ditto -- Huaiyu Zhu hzhu at users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net From effbot at telia.com Sat Jul 15 10:46:28 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 10:46:28 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <001e01bfee39$2b738200$f2a6b5d4@hagrid> Huaiyu Zhu wrote: > The only real danger is > > 3. + a > 3 .+ a > > But in this case pointwise operation does not make sense. really? what if "a" is a froob? class froob: def __add__(self, other): return other + 1.0 def __dotadd__(self, other): return other + 1.0 >>> a = froob() >>> print 3+a() 4.0 >>> print 3.+a() SyntaxError: sorry, that doesn't make sense. try inserting a space. >>> print 3. + a() 4.0 >>> print 3.0+a() 4.0 From effbot at telia.com Sat Jul 15 10:49:57 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 10:49:57 +0200 Subject: [Python-Dev] Introducing new operators for matrix computation References: Message-ID: <004101bfee39$aa2d3820$f2a6b5d4@hagrid> moshe wrote: > Jeremy: > > > I'm not aware of any tools that generate Python > > source code from a parser tree. > > Sounds like an interesting project. Hmmmm....another item on the todo > list. http://bicyclerepair.sourceforge.net/ From huaiyu_zhu at yahoo.com Sat Jul 15 11:54:13 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Sat, 15 Jul 2000 02:54:13 -0700 (PDT) Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <001e01bfee39$2b738200$f2a6b5d4@hagrid> Message-ID: On Sat, 15 Jul 2000, Fredrik Lundh wrote: > > The only real danger is > > > > 3. + a > > 3 .+ a > > > > But in this case pointwise operation does not make sense. > > really? what if "a" is a froob? Really. Because 3 is a single point. It doesn't matter what a is. > >>> print 3.+a() > SyntaxError: sorry, that doesn't make sense. try inserting a space. Why isn't this 3. + a()? Hmm, I can see my bad habit of writing long posts so that they are often quoted only partially. Here's the missing half: So I suppose the following rules would resolve all the ambiguities: Dot binds with preceding number. Otherwise it binds with following operator. Otherwise it is a member indicator. Otherwise it is syntax error. Examples: 2.+b a.+b <-- only this is new a.b a.3 Huaiyu From effbot at telia.com Sat Jul 15 12:11:53 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 12:11:53 +0200 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] References: Message-ID: <007e01bfee45$1a581ec0$f2a6b5d4@hagrid> > On Sat, 15 Jul 2000, Fredrik Lundh wrote: > > > > The only real danger is > > > > > > 3. + a > > > 3 .+ a > > > > > > But in this case pointwise operation does not make sense. > > > > really? what if "a" is a froob? > > Really. Because 3 is a single point. It doesn't matter what a is. you're inventing an entirely new language here. > > >>> print 3.+a() > > SyntaxError: sorry, that doesn't make sense. try inserting a space. > > Why isn't this 3. + a()? yeah, why? the answer is in the python documentation. > Hmm, I can see my bad habit of writing long posts so that they are often > quoted only partially. Here's the missing half: sure, I read the missing half. doesn't change a thing. please move further discussion to comp.lang.python. this discussion doesn't belong on python-dev. From paul at prescod.net Sat Jul 15 13:00:58 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 06:00:58 -0500 Subject: [Python-Dev] Re: linear algebra References: <396F4509.30069096@prescod.net> <20000714144712.A10278@thyrsus.com> Message-ID: <3970446A.318FDF4E@prescod.net> "Eric S. Raymond" wrote: > > ... > > > Overloading otherwise undefined special method names for operators is > a well-understood way to add functionality to classes. Lrt's use it. I don't know why you think that this is well-understood. Nevertheless, let's propose we add some fixed list of operators: .+ .* ./ .\ Would you propose that: "abc" .+ "c" => "abc".find( "c") "def" .* ".e." => re.match( "def", ".e." ) " " / ["a","b","c","d","e"] => " ".join( [...] ) "a b c" .\ " " => "a b c d e".split( " " ) To me, these bindings look like the kind of things I'd expect in P3rL, because the relationship between the syntax and the behavior is mostly random. In other words, you can't just invent a bunch of operators and THEN figure out how they are going to be used in various domains. You need to invent the operators *for* the domains. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Sat Jul 15 13:22:46 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 13:22:46 +0200 Subject: [Python-Dev] Re: linear algebra References: <396F4509.30069096@prescod.net> <20000714144712.A10278@thyrsus.com> <3970446A.318FDF4E@prescod.net> Message-ID: <000701bfee4f$01960820$f2a6b5d4@hagrid> paul wrote: > To me, these bindings look like the kind of things I'd expect in P3rL, > because the relationship between the syntax and the behavior is mostly > random. I saw cout being shifted "Hello world" times to the left and stopped right there. -- Steve Gonedes (which is the last I'm going to say on this topic. at least in public; I'll save the "over my dead body" stuff for guido's private mailbox). cheers /F From gstein at lyra.org Sat Jul 15 13:22:38 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 15 Jul 2000 04:22:38 -0700 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: <007e01bfee45$1a581ec0$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jul 15, 2000 at 12:11:53PM +0200 References: <007e01bfee45$1a581ec0$f2a6b5d4@hagrid> Message-ID: <20000715042238.K29590@lyra.org> On Sat, Jul 15, 2000 at 12:11:53PM +0200, Fredrik Lundh wrote: >... > please move further discussion to comp.lang.python. this > discussion doesn't belong on python-dev. Fredrik -- I've been reading your notes a bit, and you're being antagonistic, belligerent, and unfair. I'm not sure it is called for. As for the discussion being here? It isn't his fault. Somebody *else* brought it here, and he is merely trying to respond to the questions and concerns that have been brought up in this forum. I think he has got every right to do that. You should chill out and back off. Cheers, -g -- Greg Stein, http://www.lyra.org/ From martin at loewis.home.cs.tu-berlin.de Sat Jul 15 14:32:59 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 15 Jul 2000 14:32:59 +0200 Subject: [Python-Dev] request for minor enhancement / linear algebra Message-ID: <200007151232.OAA18450@loewis.home.cs.tu-berlin.de> > I got there by working backwards to make things consistent. I want > overloadable '__min__' and 'min=', and everything else that has > these forms is binary infix (I think). If min was overloadable, it would fall in the same category as cmp, divmod, getattr, hasattr, hash, hex, int, len, long, oct, pow, repr, setattr, str the category being "overloadable builtins". Of those, cmp, divmod, getattr, hasattr, pow and setattr take more than one argument. divmod and pow are truly binary in the sense that both __foo__ and __rfoo__ are tried. So if min was overloadable, there would be no need for it being infix; it should attempt both __min__ and __rmin__, though. Actually, it shouldn't - instead, it should invoke __min__ on every argument. > '+', '*', and the bitwise operators are equally variadic --- is > confusion avoided by using punctuation for the infix binary form, > and a named function for the general form? An infix operator, by nature, cannot be variadic. 1+2+3 is not a single operation returning 6, but two operation invocations. Likewise, >>> import operator >>> operator.add(1,2,3) Traceback (most recent call last): File "", line 1, in ? TypeError: function requires exactly 2 arguments; 3 given Unlike that, min(1,2,3) *is* an atomic operation. If it was overloadable, I would *not* expect that first __min__(1,2) is computed, and then __min__(1,3). Instead, I'd expect it to be done as a whole. Now, the question is: if the first argument does not provide __min__, how exactly should __min__ be invoked on the other arguments? One solution would be that min(a,b,c) does a.__min__([a,b,c]) b.__min__([a,b,c]) c.__min__([a,b,c]) Regards, Martin From effbot at telia.com Sat Jul 15 15:57:03 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 15:57:03 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? Message-ID: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> as tim pointed out in an earlier thread (on SRE), the \xnn escape code is something of a kludge. I just noted that the unicode string type supports \x as well as \u, with slightly different semantics: \u -- exactly four hexadecimal characters are read. \x -- 1 or more hexadecimal characters are read, and the result is casted to a Py_UNICODE character. I'm pretty sure this is an optimal design, but I'm not sure how it should be changed: 1. treat \x as a hexadecimal byte, not a hexadecimal character. or in other words, make sure that ord("\xabcd") == ord(u"\xabcd") fwiw, this is how it's done in SRE's parser (see the python-dev archives for more background). 2. ignore \x. after all, \u is much cleaner. u"\xabcd" == "\\xabcd" u"\u0061" == "\x61" == "\x0061" == "\x00000061" 3. treat \x as an encoding error. 4. read no more than 4 characters. (a comment in the code says that \x reads 0-4 characters, but the code doesn't match that comment) u"\x0061bcd" == "abcd" 5. leave it as it is (just fix the comment). comments? From effbot at telia.com Sat Jul 15 16:09:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 16:09:25 +0200 Subject: [Python-Dev] decoding errors when comparing strings Message-ID: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> with the locale aware encoding mechanisms switched off (sys.getdefaultencoding() == "ascii"), I stumbled upon some interesting behaviour: first something that makes sense: >>> u"abc" == "abc" 1 >>> u"???" == "abc" 0 but how about this one: >>> u"abc" == "???" Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII decoding error: ordinal not in range(128) or this one: >>> u"???" == "???" Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII decoding error: ordinal not in range(128) ignoring implementation details for a moment, is this really the best we can do? From gmcm at hypernet.com Sat Jul 15 16:17:20 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 15 Jul 2000 10:17:20 -0400 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] In-Reply-To: References: <036101bfedba$048fdbe0$f2a6b5d4@hagrid> Message-ID: <1248451855-51961207@hypernet.com> Huaiyu Zhu wrote: > The whole field of linear algebra is built on eight statements, > two of them can be derived from the other. You can't even define > all the concepts like upper or lower case, white space, tab, > symbol, character and number and identifier and concatenation and > so on in just eight statements, let alone to state all the rules > of text processing. You claimed elsewhere that these arguments were quoted out of context, yet you bring them up again. So let's nail this, alright? Text processing doesn't use any new operators. It reuses some arithmetic operators. Everything else is done with methods or functions. If that's what a linear algebra extension used, there would be nothing to discuss. Or you could take something like the regex route: pyLinearAlgebra.evaluate(r'(X`*X)\(X`*y)', X=X, y=y) ... and there would be nothing to discuss. But you want new operators, and that's a can of worms. They need to be spelled sensibly and in a way that doesn't conflict with current Python punctuation / operators. They need precedence rules built into the grammar. If the precedence rules aren't right, the operators are damn near useless, because it will take so many parens to get the right result, you might as well be using one of the above techniques. > The issue arises because one generalization is more familiar to > one group of people but the other is to other people. And people > tend to regard what they are not familiar with as "specific > domain". Python isn't a matrix manipulation language. Like any language that does in-fix, adding operators is a tricky business and affects everybody, whether they know it or not. - Gordon From effbot at telia.com Sat Jul 15 17:46:02 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 17:46:02 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? Message-ID: <002101bfee73$c8531100$f2a6b5d4@hagrid> (except for the unicode object module, that is). as I've mentioned earlier, I'm working on an alternative unicode database, which includes a ucnhash replacement. my first thought was to emulate the existing api, but it has two small problems: -- it returns pointers into the database. this means that you cannot compress the names at all, if you want to be thread- safe (which you have to be, in this case). -- it exposes low-level implementation details, such as the hash table size, etc. I'm not sure if I can emulate that in any sane way under the new database design. so if nobody uses this, I'd rather change the unicodeobject.c file to use the new API directly... From thomas at xs4all.net Sat Jul 15 18:01:30 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 15 Jul 2000 18:01:30 +0200 Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: <200007141505.KAA13385@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 14, 2000 at 10:05:39AM -0500 References: <20000713235356.X7340@xs4all.nl> <200007132305.SAA11276@cj20424-a.reston1.va.home.com> <396E4746.DE25EFD4@prescod.net> <200007141505.KAA13385@cj20424-a.reston1.va.home.com> Message-ID: <20000715180130.H7340@xs4all.nl> On Fri, Jul 14, 2000 at 10:05:39AM -0500, Guido van Rossum wrote: > > If Guido has decided that the design that has already been implemented > > is the right one, what's the point of the PEP? Someone just needs to > > review the patch and check it in! > Right! Well, uhm, what now, then ? Should I finish PEP204 ? It's about half done, but throwing it away isn't a problem. I used it to get used to writing PEPs, anyway ;) I still have a question regarding the range literals patch, though, as I noted in the comment on SF: [...] the patch contains some code duplication (about the entire build_range function, plus get_len_of_range()) I'm not sure how to properly solve that: is it okay for compile.c to rely on something from bltinmodule.c ? If not, should I move the common functionality into listobject.c ? There is also the question regarding (::) and generators. Should I finish the PEP for the sake of that ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Sat Jul 15 18:10:03 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 19:10:03 +0300 (IDT) Subject: [Python-Dev] [PEP204] Range Literals In-Reply-To: <20000715180130.H7340@xs4all.nl> Message-ID: On Sat, 15 Jul 2000, Thomas Wouters wrote: > There is also the question regarding (::) and generators. Should I finish > the PEP for the sake of that ? I think we decided we don't need those. The only reason people need generators is for extra efficiency in for i in range(10^6): if i==5: break But the compiler can do that for the [::] version, since it's non-overridable. About the refactoring: my advice is to refactor first, and ask questions later <0.6 wink> -- after you mess with the code, just moving a function around takes about 3 seconds. (I'd put it in listobject.c first -- but just pick a place) From mal at lemburg.com Sat Jul 15 18:58:45 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 18:58:45 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> Message-ID: <39709844.595B84F6@lemburg.com> Fredrik Lundh wrote: > > as tim pointed out in an earlier thread (on SRE), the > \xnn escape code is something of a kludge. > > I just noted that the unicode string type supports \x > as well as \u, with slightly different semantics: > > \u -- exactly four hexadecimal characters are read. > > \x -- 1 or more hexadecimal characters are read, and > the result is casted to a Py_UNICODE character. \x is there in Unicode for compatibility with the 8-bit string implementation and in sync with ANSI C. Guido wanted these semantics when I asked him about it during the implementation phase. > I'm pretty sure this is an optimal design, but I'm not sure > how it should be changed: > > 1. treat \x as a hexadecimal byte, not a hexadecimal > character. or in other words, make sure that > > ord("\xabcd") == ord(u"\xabcd") > > fwiw, this is how it's done in SRE's parser (see the > python-dev archives for more background). > > 2. ignore \x. after all, \u is much cleaner. > > u"\xabcd" == "\\xabcd" > u"\u0061" == "\x61" == "\x0061" == "\x00000061" > > 3. treat \x as an encoding error. > > 4. read no more than 4 characters. (a comment in the > code says that \x reads 0-4 characters, but the code > doesn't match that comment) > > u"\x0061bcd" == "abcd" > > 5. leave it as it is (just fix the comment). I'd suggest 5 -- makes converting 8-bit strings using \x to Unicode a tad easier. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jul 15 19:03:30 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 19:03:30 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> Message-ID: <39709962.1C0A576E@lemburg.com> Fredrik Lundh wrote: > > (except for the unicode object module, that is). I don't think so... it's very new and the C API isn't documented. > as I've mentioned earlier, I'm working on an alternative unicode > database, which includes a ucnhash replacement. > > my first thought was to emulate the existing api, but it has two > small problems: > > -- it returns pointers into the database. this means that you > cannot compress the names at all, if you want to be thread- > safe (which you have to be, in this case). > > -- it exposes low-level implementation details, such as the hash > table size, etc. I'm not sure if I can emulate that in any sane > way under the new database design. > > so if nobody uses this, I'd rather change the unicodeobject.c > file to use the new API directly... Please don't drop the idea of an on-demand loadable module though. The current design used by Bill Tutt is to load the ucnhash module (which contains the mappings) only when it is needed -- most code won't need it. BTW, does you database use the on-demand loading feature ? I don't think that having the Unicode database linked statically in the Python interpreter is a good idea -- at least not until Unicode takes over ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Sat Jul 15 17:37:01 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 15 Jul 2000 10:37:01 -0500 (CDT) Subject: [Python-Dev] what to call this zip() function? In-Reply-To: References: Message-ID: <14704.34077.358194.82087@beluga.mojam.com> Nothing has really jumped out as the "right" way to express the proposed builtin that does map(None, l1, l2, l3, l4) How about collate? What we're doing is effectively what a copy machine does when it collates multiple copies of its input... Skip From mal at lemburg.com Sat Jul 15 19:15:05 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 19:15:05 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> Message-ID: <39709C19.A9A27625@lemburg.com> Fredrik Lundh wrote: > > with the locale aware encoding mechanisms switched off > (sys.getdefaultencoding() == "ascii"), I stumbled upon some > interesting behaviour: > > first something that makes sense: > > >>> u"abc" == "abc" > 1 > > >>> u"???" == "abc" > 0 > > but how about this one: > > >>> u"abc" == "???" > Traceback (most recent call last): > File "", line 1, in ? > UnicodeError: ASCII decoding error: ordinal not in range(128) > > or this one: > > >>> u"???" == "???" > Traceback (most recent call last): > File "", line 1, in ? > UnicodeError: ASCII decoding error: ordinal not in range(128) > > ignoring implementation details for a moment, is this really the > best we can do? This is merely due to the fact that on your Latin-1 platform, "?" and u"?" map to the same ordinals. The unicode-escape codec (which is used by the Python parser) takes single characters in the whole 8-bit range as Unicode ordinals, so u"?" really maps to unichr(ord("?")). The alternative would be forcing usage of escapes for non-ASCII Unicode character literals and issuing an error for all non-ASCII ones. BTW, I have a feeling that we should mask the decoding errors during compares in favour of returning 0... ...otherwise the current dictionary would bomb (it doesn't do any compare error checking !) in case a Unicode string happens to have the same hash value as an 8-bit string key. (Can't test this right now, but this is what should happen according to the C sources.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Sat Jul 15 19:24:56 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 12:24:56 -0500 Subject: [Python-Dev] decoding errors when comparing strings References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> Message-ID: <39709E68.820634C6@prescod.net> Fredrik Lundh wrote: > > ... > > but how about this one: > > >>> u"???" == "???" > Traceback (most recent call last): > File "", line 1, in ? > UnicodeError: ASCII decoding error: ordinal not in range(128) As soon as you find a character out of the ASCII range in one of the strings, I think that you should report that the two strings are unequal. We can't have exceptions popping out of dictionaries and other "blind compare" situations. Is there any precedent for throwing an exception on cmp? Also, is it really necessary to allow raw non-ASCII characters in source code though? We know that they aren't portable across editing environments, so one person's happy face will be another person's left double-dagger. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Sat Jul 15 19:36:38 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 19:36:38 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> <39709962.1C0A576E@lemburg.com> Message-ID: <005c01bfee83$4bafc480$f2a6b5d4@hagrid> mal wrote: > > (except for the unicode object module, that is). > > I don't think so... it's very new and the C API isn't > documented. great. I'll just pretend it doesn't exist. > > so if nobody uses this, I'd rather change the unicodeobject.c > > file to use the new API directly... > > Please don't drop the idea of an on-demand loadable module > though. The current design used by Bill Tutt is to load the > ucnhash module (which contains the mappings) only when it > is needed -- most code won't need it. > > BTW, does you database use the on-demand loading feature ? > I don't think that having the Unicode database linked statically > in the Python interpreter is a good idea -- at least not until > Unicode takes over ;-) but of course... everything except the "ctype" info is loaded from PYD/SO's, just as before. the only difference is that the files are slightly smaller :-) -rw-r--r-- 1 500 everyone 443392 Jul 15 18:55 ucnhash.pyd -rw-r--r-- 1 500 everyone 161280 Jul 15 18:53 uninames.pyd -rw-r--r-- 1 500 everyone 594944 Jul 11 23:03 unicodedata.pyd -rw-r--r-- 1 500 everyone 42496 Jul 15 15:25 unidata.pyd -rw-r--r-- 1 500 everyone 118329 Jul 13 21:01 unicodectype.obj -rw-r--r-- 1 500 everyone 10961 Jul 15 15:23 unictype.obj (names and sizes may change slightly before the final patch, but you get the idea). cheers /F From effbot at telia.com Sat Jul 15 19:54:47 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 19:54:47 +0200 Subject: [Python-Dev] [patch #100889] a smaller unicode name database Message-ID: <006a01bfee85$c787f3a0$f2a6b5d4@hagrid> my unicode database compression project has resulted in its first patch: https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100899&group_id=5470 this patch replaces "ucnhash" (sorry bill!) with a new module called "uninames". on my windows box, the new module is about 1/3 of the old one (about 160k). YMMV, as usual. From effbot at telia.com Sat Jul 15 20:00:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 20:00:48 +0200 Subject: [Python-Dev] [patch #100889] a smaller unicode name database References: <006a01bfee85$c787f3a0$f2a6b5d4@hagrid> Message-ID: <007401bfee86$9dd566e0$f2a6b5d4@hagrid> > my unicode database compression project has resulted in its first > patch: > > https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100899&group_id=5470 two additional comments: first, the patch was too large for sourceforge (>512000 bytes), so I've uploaded it to the secret effbot site instead: http://w1.132.telia.com/~u13208596/uninames-patch.txt second, the uninames module provides two public Python functions: getname(code) returns the character name corresponding to the given character code, or None if the name is not known. getcode(name) returns the character code for the given character name. again, it returns None if the code is not known. Q: should I raise exceptions instead of returning None? Q: what other functions would be useful? getallnames()? anything else? cheers /F From mal at lemburg.com Sat Jul 15 19:57:45 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 19:57:45 +0200 Subject: [Python-Dev] Linker problems on Linux Message-ID: <3970A619.D2CA39AA@lemburg.com> I just tried to compile the current CVS version on Linux. The compile went fine, but when I started Python, I got: 'import site' failed; use -v for traceback Python 2.0b1 (#1, Jul 15 2000, 19:22:33) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) Traceback (most recent call last): File "/home/lemburg/bin/pyinteractive.py", line 7, in ? import mx.Tools File "/home/lemburg/projects/mx/Tools/__init__.py", line 24, in ? from Tools import * File "/home/lemburg/projects/mx/Tools/Tools.py", line 10, in ? from mxTools import * File "/home/lemburg/projects/mx/Tools/mxTools/__init__.py", line 1, in ? from mxTools import * ImportError: /home/lemburg/projects/mx/Tools/mxTools/mxTools.so: undefined symbol: PyObject_Length >>> Why isn't PyObject_Length being exported anymore ??? I hve the funny feeling that the API name cosmetics applied to xxx_Length() got someone carried away a bit ;-) We shouldn't drop binary compatibility on *all* platforms just for the sake of style... I remember very well how Guido opposed to any binary incompatible changes in earlier versions of Python and can't really believe that this strategy has suddenly changed for 2.0. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jul 15 19:59:56 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 19:59:56 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709C19.A9A27625@lemburg.com> Message-ID: <3970A69C.3361B209@lemburg.com> "M.-A. Lemburg" wrote: > > BTW, I have a feeling that we should mask the decoding errors > during compares in favour of returning 0... > > ...otherwise the current dictionary would bomb (it doesn't do any > compare error checking !) in case a Unicode string happens to have > the same hash value as an 8-bit string key. (Can't test this right now, > but this is what should happen according to the C sources.) Here's the test: >>> s = '?' >>> u = u'?' >>> hash(s) -880683291 >>> hash(u) -880683291 >>> d = {s:1} >>> d[s] 1 >>> d[u] Traceback (most recent call last): File "", line 1, in ? KeyError>>> >>> Looks strange, doesn't it... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jul 15 20:02:31 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 20:02:31 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> <39709962.1C0A576E@lemburg.com> <005c01bfee83$4bafc480$f2a6b5d4@hagrid> Message-ID: <3970A737.6B13B543@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > so if nobody uses this, I'd rather change the unicodeobject.c > > > file to use the new API directly... > > > > Please don't drop the idea of an on-demand loadable module > > though. The current design used by Bill Tutt is to load the > > ucnhash module (which contains the mappings) only when it > > is needed -- most code won't need it. > > > > BTW, does you database use the on-demand loading feature ? > > I don't think that having the Unicode database linked statically > > in the Python interpreter is a good idea -- at least not until > > Unicode takes over ;-) > > but of course... > > everything except the "ctype" info is loaded from PYD/SO's, just as > before. the only difference is that the files are slightly smaller :-) > > -rw-r--r-- 1 500 everyone 443392 Jul 15 18:55 ucnhash.pyd > -rw-r--r-- 1 500 everyone 161280 Jul 15 18:53 uninames.pyd > > -rw-r--r-- 1 500 everyone 594944 Jul 11 23:03 unicodedata.pyd > -rw-r--r-- 1 500 everyone 42496 Jul 15 15:25 unidata.pyd > > -rw-r--r-- 1 500 everyone 118329 Jul 13 21:01 unicodectype.obj > -rw-r--r-- 1 500 everyone 10961 Jul 15 15:23 unictype.obj > > (names and sizes may change slightly before the final patch, but you > get the idea). Cool :-) (I'd suggest keeping the original names, BTW) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sat Jul 15 20:10:07 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 20:10:07 +0200 Subject: [Python-Dev] what to call this zip() function? References: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: <007d01bfee87$eb2c2e00$f2a6b5d4@hagrid> skip wrote: > Nothing has really jumped out as the "right" way to express the proposed > builtin that does > > map(None, l1, l2, l3, l4) > > How about collate? What we're doing is effectively what a copy machine does > when it collates multiple copies of its input... let's see: merriam webster has the following to say: collate: ... to assemble in proper order; especially : to assemble (as printed sheets) in order for binding ... "binding"? sounds familiar. let's take a look at the language reference: ... Assignment statements are used to (re)bind names to values ... The for statement is used to iterate over the elements of a sequence ... Each item in turn is assigned to the target list using the standard rules for assignments ... +1 from here. From mal at lemburg.com Sat Jul 15 20:09:49 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 15 Jul 2000 20:09:49 +0200 Subject: [Python-Dev] [patch #100889] a smaller unicode name database References: <006a01bfee85$c787f3a0$f2a6b5d4@hagrid> <007401bfee86$9dd566e0$f2a6b5d4@hagrid> Message-ID: <3970A8ED.28CEC0FE@lemburg.com> Fredrik Lundh wrote: > > > my unicode database compression project has resulted in its first > > patch: > > > > https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100899&group_id=5470 > > two additional comments: > > first, the patch was too large for sourceforge (>512000 bytes), so > I've uploaded it to the secret effbot site instead: > > http://w1.132.telia.com/~u13208596/uninames-patch.txt > > second, the uninames module provides two public Python functions: I'd name this: unicodenames (we shouldn't be afraid of long module names ;-). > getname(code) returns the character name corresponding to > the given character code, or None if the name is not known. > > getcode(name) returns the character code for the given character > name. again, it returns None if the code is not known. > > Q: should I raise exceptions instead of returning None? Yes... getname() with an unkown code means that an unassigned code is being requested: this is a ValueError. getcode(name) should raise a ValueError exception too, since the requested name may be unsupported by Python's version of the Unicode lib (vers. 3.0). BTW, did you make the lookups case insensitive ? (Would be useful, IMHO.) > Q: what other functions would be useful? getallnames()? anything > else? Perhaps a dictionary like interface written on top of the above two APIs (in Python, of course). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Sat Jul 15 20:14:19 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 21:14:19 +0300 (IDT) Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: On Sat, 15 Jul 2000, Skip Montanaro wrote: > > Nothing has really jumped out as the "right" way to express the proposed > builtin that does > > map(None, l1, l2, l3, l4) > > How about collate? What we're doing is effectively what a copy machine does > when it collates multiple copies of its input... Collate is great! +0 on that. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Sat Jul 15 20:21:52 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 20:21:52 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> <39709962.1C0A576E@lemburg.com> <005c01bfee83$4bafc480$f2a6b5d4@hagrid> <3970A737.6B13B543@lemburg.com> Message-ID: <008b01bfee89$8e731460$f2a6b5d4@hagrid> mal wrote: > Cool :-) oh, just wait until I've gotten my head around Christian's superoptimizations ;-) > (I'd suggest keeping the original names, BTW) unicodedata and unicodectype are okay, but frankly, isn't "ucnhash" overly cryptic? how about "unicodenames"? From effbot at telia.com Sat Jul 15 20:30:07 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 20:30:07 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> Message-ID: <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> paul wrote: > As soon as you find a character out of the ASCII range in one of the > strings, I think that you should report that the two strings are > unequal. sounds reasonable -- but how do you flag "unequal" in cmp? which value is "larger" if all that we know is that they're different... > We can't have exceptions popping out of dictionaries and other "blind > compare" situations. Is there any precedent for throwing an exception > on cmp? not really. it's a bit amusing that "a" == x works for all built-in types, except unicode strings... (not to mention that "a" < x works, in a way...) > Also, is it really necessary to allow raw non-ASCII characters in source > code though? We know that they aren't portable across editing > environments, so one person's happy face will be another person's left > double-dagger. I suppose changing that would break code. maybe it's time to reopen the "pragma encoding" thread? (I'll dig up my old proposal, and post it under a new subject). From ping at lfw.org Sat Jul 15 20:34:57 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sat, 15 Jul 2000 11:34:57 -0700 (PDT) Subject: [Python-Dev] what to call this zip() function? Message-ID: Skip Montanaro wrote: > How about collate? The analogy with a photocopying machine is pretty good, but i'm afraid this will play havoc with those who see "collate" in terms of determining sort order. * * * With me acting as the user and a willing guinea pig playing the part of the Python interpreter, i got the following results: >>> a = [1, 2, 3] >>> b = [4, 5, 6] >>> c = [7, 8, 9] >>> for x, y, z in twine(a, b, c): ... print x, y, z 1 5 9 2 6 7 3 4 8 >>> for x, y, z in weave(a, b, c): ... print x, y, z 1 5 7 2 4 8 3 None 9 None 6 None >>> for x, y, z in parallel(a, b, c): ... print x, y, z 1 4 7 2 5 8 3 6 9 * * * On Fri, 14 Jul 2000, Eric S. Raymond wrote: > No, *I* wrote `plait() is *good*.' > > In English, `plait' is a slightly unusual word with a meaning almost > indistinguishable from `braid'. ...which is almost entirely the *wrong* meaning, imho. Here are the pictures i get from the words suggested so far. splice furl _______ --> <-- / _____ \ --------= =------- / / \ \ \_______/ / ___________/ twine /|\ lace -%- \|/ \ / \ X /|\ / \ \|/ \ / \ X /|\ (_) \|/ braid / \ / plait | | plait | / (sense 2) | _______|_ (sense 1) \ / \ |/| | \ | | _______|_ / \ / |/| | | / | | \ / \ | | \ | / \ / weave -|-----|-----|- interlace -----------> interweave | | | | | interleave <----------- knit ----|-----|---- -----------> | | | | | <----------- -|-----|-----|- -----------> | | | | | <----------- ----|-----|---- -----------> | | | | | <----------- -|-----|-----|- parallel --------------- march ------ o-> - - - --------------- ------ o-> - - - --------------- ------ o-> - - - --------------- ------ o-> - - - zip o o merge | | | marry o o (herd?) | | | o o \ | / o-o \|/ o-o | o-o | o-o | o-o v * * * It's fairly clear to me that, of the names that evoke images of some sort, only "parallel", "march", and "merge" are actually accurate. "zip" and "marry" are nearly accurate except that they usually give the impression that only two things are being joined. Of these five options, "zip" and "parallel" have potentially misleading meanings. "merge" sounds the most neutral to me. "tuples" is also very neutral (though it doesn't really suggest *how* the tuples are obtained). Therefore, i'm down to "merge", "tuples", or "march" (maybe "herd"); i'd be quite happy with "parallel" or "zip" but others have already come out strongly against those two. * * * Finally, on the lighter side... more ideas from my twisted mind. for x, y, z in rearrange(a, b, c)? for x, y, z in herd(a, b, c)? for x, y, z in mutilate(a, b, c)? for x, y, z in harass(a, b, c)? for x, y, z in abuse(a, b, c)? for x, y, z in torture(a, b, c)? A friend also suggested a name reminiscent of our discussion. for x, y, z in flamewar(a, b, c): print x, y, z You want an argument? Oh, this is abuse. Arguments are down the hall. -- ?!ng From ping at lfw.org Sat Jul 15 20:36:48 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sat, 15 Jul 2000 11:36:48 -0700 (PDT) Subject: [Python-Dev] Re: what to call this zip() function? In-Reply-To: Message-ID: On Sat, 15 Jul 2000, Ka-Ping Yee wrote: > zip o o merge | | | > marry o o (herd?) | | | > o o \ | / > o-o \|/ > o-o | > o-o | > o-o | > o-o v Oh yes. "meld" also falls in the "merge"/"herd" category. -- ?!ng From alex_c at MIT.EDU Sat Jul 15 20:32:00 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Sat, 15 Jul 2000 14:32:00 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> (fdrake@beopen.com) References: <200007142030.QAA156803@w20-575-116.mit.edu> <14703.37801.644447.63587@cj42289-a.reston1.va.home.com> <200007142242.SAA12205@mint-square.mit.edu> <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> Message-ID: <200007151832.OAA63801@w20-575-115.mit.edu> Should posixpath.expandvars throw a SyntaxError if it encounters unbalanced curly braces? >>> import posixpath >>> posixpath.expandvars('/dir1/dir${DIR_NUM/dir2') '/dir1/dir${DIR_NUM/dir2' >>> Alex. From paul at prescod.net Sat Jul 15 20:37:43 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 13:37:43 -0500 Subject: [Python-Dev] what to call this zip() function? References: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: <3970AF77.385853E0@prescod.net> Skip Montanaro wrote: > > Nothing has really jumped out as the "right" way to express the proposed > builtin that does > > map(None, l1, l2, l3, l4) > > How about collate? What we're doing is effectively what a copy machine does > when it collates multiple copies of its input... +1 on collate! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From thomas at xs4all.net Sat Jul 15 20:44:10 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 15 Jul 2000 20:44:10 +0200 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <3970A619.D2CA39AA@lemburg.com>; from mal@lemburg.com on Sat, Jul 15, 2000 at 07:57:45PM +0200 References: <3970A619.D2CA39AA@lemburg.com> Message-ID: <20000715204410.I7340@xs4all.nl> On Sat, Jul 15, 2000 at 07:57:45PM +0200, M.-A. Lemburg wrote: > I just tried to compile the current CVS version on Linux. > The compile went fine, but when I started Python, I got: > 'import site' failed; use -v for traceback > Python 2.0b1 (#1, Jul 15 2000, 19:22:33) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > Traceback (most recent call last): > File "/home/lemburg/bin/pyinteractive.py", line 7, in ? > import mx.Tools > File "/home/lemburg/projects/mx/Tools/__init__.py", line 24, in ? > from Tools import * > File "/home/lemburg/projects/mx/Tools/Tools.py", line 10, in ? > from mxTools import * > File "/home/lemburg/projects/mx/Tools/mxTools/__init__.py", line 1, in ? > from mxTools import * > ImportError: /home/lemburg/projects/mx/Tools/mxTools/mxTools.so: undefined symbol: PyObject_Length > Why isn't PyObject_Length being exported anymore ??? PyObject_Length is changed into a #define, to PyObject_Size. This preserves the API but not the ABI ;) GCC has a construct to make one function an alias for another: PyObject * PyObject_Length() __attribute__((alias("PyObject_Size"))); But this is not likely to work in other compilers, and not on all architectures to start with. The most portable solution is probably to make PyObject_Length() a wrapper for PyObject_Size, and hope the compiler knows how to handle that most efficiently. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm at hypernet.com Sat Jul 15 20:44:48 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 15 Jul 2000 14:44:48 -0400 Subject: [Python-Dev] what to call this zip() function? In-Reply-To: Message-ID: <1248435790-52927448@hypernet.com> Ka-Ping Yee wrote: > You want an argument? Oh, this is abuse. Arguments are down the > hall. Now that's my kind of company! Drop in anytime, Barry. No appointment necessary.... - Gordon From paul at prescod.net Sat Jul 15 20:48:20 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 13:48:20 -0500 Subject: [Python-Dev] Pre-PEP Idea Message-ID: <3970B1F4.D4D8BAE9@prescod.net> Hopefully this transcript will speak for itself...mostly. >>> help | The help function allows you to read help on Python's various | functions, objects, instructions and modules. You have two options: | | 1. Use help( obj ) to browse the help attached to some function, | module, class or other object. e.g. help( dir ) | | 2. Use help( "somestring" ) to browse help on one of the predefined | help topics, unassociated with any particular object: | | help( "intro" ) - What is Python? | help( "keywords" ) - What are the keywords? | help( "syntax" ) - What is the overall syntax? | help( "operators" ) - What operators are available? | help( "types" ) - What types are built-in (not extension types)? | help( "exceptions" ) - What exceptions can be raised? | help( "modules" ) - What modules are in the standard library? | help( "copyright" ) - Who owns Python? | help( "moreinfo" ) - Where is there more information? | help( "changes" ) - What changed in Python 2.0? | help( "extensions" ) - What extensions are installed? | help( "faq" ) - What questions are frequently asked? | help( "ack" ) - Who has done work on Python lately? | help( "language" ) - Change the language of the help function >>> >>> help( "keywords" ) | "if" - Conditional execution | "while" - Loop while a condition is true | "for" - Loop over a sequence of values (often numbers) | "try" - Set up an exception handler | "def" - Define a named function | "class" - Define a class | "assert" - Check that some code is working as you expect it to. | "pass" - Do nothing | "del" - Delete a data value | "print" - Print a value | "return" - Return information from a function | "raise" - Raise an exception | "break" - Terminate a loop | "continue" - Skip to the next loop statement | "import" - Import a module | "global" - Declare a variable global | "exec" - Execute some dynamically generated code | "lambda" - Define an unnamed function | For more information, type e.g. help("assert") >>> >>> help( dir ) | dir([object]) -> list of strings | Return an alphabetized list of names comprising (some of) the attributes | of the given object. Without an argument, the names in the current scope | are listed. With an instance argument, only the instance attributes are | returned. With a class argument, attributes of the base class are not | returned. For other types or arguments, this may list members or methods. >>> >>> import pickle >>> help( pickle ) | create portable serialized representations of Python objects. | See module cPickle for a (much) faster implementation. | See module copy_reg for a mechanism for registering custom picklers. | Classes: | Pickler | Unpickler | Functions: | dump(object, file) | dumps(object) -> string | load(file) -> object | loads(string) -> object | Misc variables: | __version__ | format_version | compatible_formats >>> -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From moshez at math.huji.ac.il Sat Jul 15 20:50:55 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 21:50:55 +0300 (IDT) Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> Message-ID: On Sat, 15 Jul 2000, Fredrik Lundh wrote: > paul wrote: > > As soon as you find a character out of the ASCII range in one of the > > strings, I think that you should report that the two strings are > > unequal. > > sounds reasonable -- but how do you flag "unequal" in cmp? which > value is "larger" if all that we know is that they're different... We can say something like "beyond the ASCII range, every unicode character is larger then any regular 8-bit character", and compare lexicographically. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Sat Jul 15 20:55:07 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 21:55:07 +0300 (IDT) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B1F4.D4D8BAE9@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Hopefully this transcript will speak for itself...mostly. > > >>> help +0. Here's what I think would make it +1: -- have all that wonderful stuff in help.py -- have the startup code of the *interactive interpreter only* do "from help import help" at the beginning. by-all-means-PEP-it-*i've*-seen-it-a-gazillion-times-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Sat Jul 15 21:08:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 21:08:58 +0200 Subject: [Python-Dev] Pre-PEP Idea References: <3970B1F4.D4D8BAE9@prescod.net> Message-ID: <010e01bfee90$224df960$f2a6b5d4@hagrid> paul wrote: > Hopefully this transcript will speak for itself...mostly. > > >>> help > | The help function allows you to read help on Python's various > | functions, objects, instructions and modules. heh. so that's why I'm having a slight headache; paul is in there stealing my ideas? ;-) ... I got stuck on whether this is best implemented as a true builtin, or just patched into the builtins dictionary by site.py... why not just post a site.py patch, and forget about the PEP for now? 1) plus a sys.sethelphook function which allow the environ- ment to override the default behaviour; for example, if you're typing help("intro") in PythonWorks' console window, you pro- bably want to get nicely formatted help in the "info" panel, not in the console window itself. From Vladimir.Marangozov at inrialpes.fr Sat Jul 15 21:13:04 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 15 Jul 2000 21:13:04 +0200 (CEST) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B1F4.D4D8BAE9@prescod.net> from "Paul Prescod" at Jul 15, 2000 01:48:20 PM Message-ID: <200007151913.VAA03550@python.inrialpes.fr> Paul Prescod wrote: > > Hopefully this transcript will speak for itself...mostly. > Very nice, Paul! PEP it without hesitation. I'm all for it! We'll discuss subsequently what's the best way to implement interactive help screens. don't-forget-to-add-man()-for-Tom-Christiansen-<0.8 wink>'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul at prescod.net Sat Jul 15 21:13:55 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 14:13:55 -0500 Subject: [Python-Dev] Pre-PEP Idea References: Message-ID: <3970B7F3.28F64A3E@prescod.net> Moshe Zadka wrote: > > ... > > -- have all that wonderful stuff in help.py > -- have the startup code of the *interactive interpreter only* do > "from help import help" at the beginning. Sorry, that's a part I should have explanied more. help is not a magical function/statement but an instance with a repr that does the right thing. And yes, it will probably only be loaded at the repl. Or it could be a 10-line instance that loads its content when it is actually used. That might allow python -c "import help" Here's a sample definition. class helploader: def __repr__( self ): global help from helptext import help return repr( help ) def __call__( self ): global help from helptext import help return repr( help ) help=helploader() -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Sat Jul 15 21:22:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 21:22:42 +0200 Subject: [Python-Dev] posixpath module. References: <200007142030.QAA156803@w20-575-116.mit.edu><14703.37801.644447.63587@cj42289-a.reston1.va.home.com><200007142242.SAA12205@mint-square.mit.edu> <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> <200007151832.OAA63801@w20-575-115.mit.edu> Message-ID: <012f01bfee92$0e21df40$f2a6b5d4@hagrid> alex wrote: > > Should posixpath.expandvars throw a SyntaxError if it encounters > unbalanced curly braces? > > >>> import posixpath > >>> posixpath.expandvars('/dir1/dir${DIR_NUM/dir2') > '/dir1/dir${DIR_NUM/dir2' > >>> probably not; code using it might not be prepared to handle an exception... what does the Unix shell do in this case? (intuitively, I'd treat ${FOO as $FOO, say: _varprog = re.compile(r'\$(\{[^{}$]*\}|{?\w+|)') but that's me...) From moshez at math.huji.ac.il Sat Jul 15 21:19:11 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 22:19:11 +0300 (IDT) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B7F3.28F64A3E@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Moshe Zadka wrote: > > > > ... > > > > -- have all that wonderful stuff in help.py > > -- have the startup code of the *interactive interpreter only* do > > "from help import help" at the beginning. > > Sorry, that's a part I should have explanied more. > > help is not a magical function/statement but an instance with a repr > that does the right thing. And yes, it will probably only be loaded at > the repl. Or it could be a 10-line instance that loads its content when > it is actually used. That might allow > > python -c "import help" > > Here's a sample definition. > > class helploader: > def __repr__( self ): > global help > from helptext import help > return repr( help ) > def __call__( self ): > global help > from helptext import help > return repr( help ) > help=helploader() BTW, that should probably be CCed to the doc-sig, because that information has to come from somewhere. doc-sig traffic kind of died after the initial IPC8-induced burst. Fred, any plans on seriously reviving doc-sig? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul at prescod.net Sat Jul 15 21:19:41 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 14:19:41 -0500 Subject: [Python-Dev] Pre-PEP Idea References: <3970B1F4.D4D8BAE9@prescod.net> <010e01bfee90$224df960$f2a6b5d4@hagrid> Message-ID: <3970B94D.40F5032A@prescod.net> Fredrik Lundh wrote: > > ... > > heh. so that's why I'm having a slight headache; paul is > in there stealing my ideas? ;-) I should have just let you invent it! > I got stuck on whether this is best implemented as a true > builtin, or just patched into the builtins dictionary by site.py... six of one, half dozen of the other. * builtin means a little more consistency across environments * ptach means a little less code on startup What do you think of my ten-line bootstrapper idea. I weigh the former slightly higher then the latter. Plus, I could perhaps put a helpful message in the bootstrapper to help people debug site.py and PYTHONPATH problems. :) > 1) plus a sys.sethelphook function which allow the environ- > ment to override the default behaviour; for example, if you're > typing help("intro") in PythonWorks' console window, you pro- > bably want to get nicely formatted help in the "info" panel, > not in the console window itself. Good idea. And eventually some way for extensions to register themselves...and a pager. Do we have pager code hanging around? Some docstrings are already long and we have no mechanism for breaking them up .... -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From alex_c at MIT.EDU Sat Jul 15 21:23:55 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Sat, 15 Jul 2000 15:23:55 -0400 (EDT) Subject: [Python-Dev] posixpath module. In-Reply-To: <012f01bfee92$0e21df40$f2a6b5d4@hagrid> (effbot@telia.com) References: <200007142030.QAA156803@w20-575-116.mit.edu><14703.37801.644447.63587@cj42289-a.reston1.va.home.com><200007142242.SAA12205@mint-square.mit.edu> <14703.42962.643187.956510@cj42289-a.reston1.va.home.com> <200007151832.OAA63801@w20-575-115.mit.edu> <012f01bfee92$0e21df40$f2a6b5d4@hagrid> Message-ID: <200007151923.PAA64675@w20-575-115.mit.edu> > > Should posixpath.expandvars throw a SyntaxError if it encounters > > unbalanced curly braces? > > probably not; code using it might not be prepared > to handle an exception... > > what does the Unix shell do in this case? It gives an error: athena% echo ${HOME Missing }. athena% echo ${HOME} /afs/athena.mit.edu/user/a/l/alex_c athena% You're probably right about backwards compatibility being worth more than compatibility with Unix in this case, though. Alex. From paul at prescod.net Sat Jul 15 21:24:21 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 14:24:21 -0500 Subject: [Python-Dev] Pre-PEP Idea References: <3970B1F4.D4D8BAE9@prescod.net> <010e01bfee90$224df960$f2a6b5d4@hagrid> Message-ID: <3970BA65.5DBFB39A@prescod.net> Fredrik Lundh wrote: > > ... > > why not just post a site.py patch, and forget about the > PEP for now? Also, how should I include a new module in a patch? Do I do a directory diff? Or just checkin the stupid thing? -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From moshez at math.huji.ac.il Sat Jul 15 21:41:13 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 22:41:13 +0300 (IDT) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B94D.40F5032A@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Good idea. And eventually some way for extensions to register > themselves...and a pager. Do we have pager code hanging around? Some > docstrings are already long and we have no mechanism for breaking them > up .... Do you mean this: import sys def pager(lines, length=23): while lines: sys.stdout.writelines(lines[:length]) lines = lines[length:] if lines: raw_input("--more--") def main(): pager(open(sys.argv[1]).readlines()) if __name__ == '__main__': main() -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Sat Jul 15 21:58:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 21:58:25 +0200 Subject: [Python-Dev] Pre-PEP Idea References: <3970B1F4.D4D8BAE9@prescod.net> <010e01bfee90$224df960$f2a6b5d4@hagrid> <3970BA65.5DBFB39A@prescod.net> Message-ID: <016001bfee97$0b67fd20$f2a6b5d4@hagrid> paul wrote: > Also, how should I include a new module in a patch? Do I do a directory > diff? Or just checkin the stupid thing? I had the same problem for the "uninames" patch. I ended up using "diff -N" on local, empty files. hopefully, someone out there might have a better solution? (the docs imply that "cvs -N" might work, but it sure didn't work for me...) From paul at prescod.net Sat Jul 15 22:03:15 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 15:03:15 -0500 Subject: [Python-Dev] Pre-PEP Idea References: Message-ID: <3970C383.9D844BF3@prescod.net> Moshe Zadka wrote: > > Do you mean this: > > import sys > > def pager(lines, length=23): > while lines: > sys.stdout.writelines(lines[:length]) > lines = lines[length:] > if lines: > raw_input("--more--") > > def main(): > pager(open(sys.argv[1]).readlines()) > Okay, okay, it didn't turn out so hard. :) I was just about to write it myself. Is there a way to get a single key portably, rather than requiring a return? Not a biggee. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Sat Jul 15 22:04:30 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 15:04:30 -0500 Subject: [Python-Dev] Pre-PEP Idea References: <200007151913.VAA03550@python.inrialpes.fr> Message-ID: <3970C3CE.804A8BF@prescod.net> Vladimir Marangozov wrote: > > Paul Prescod wrote: > > > > Hopefully this transcript will speak for itself...mostly. > > > > Very nice, Paul! > PEP it without hesitation. I'm all for it! We'll discuss subsequently > what's the best way to implement interactive help screens. > > don't-forget-to-add-man()-for-Tom-Christiansen-<0.8 wink>'ly y'rs No joke, in the interactive environment I am going to add apropos and man as aliases. Or at least messages that say: "try help". -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Sat Jul 15 22:16:16 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 15:16:16 -0500 Subject: [Python-Dev] Pre-PEP Idea References: Message-ID: <3970C690.42CA22FF@prescod.net> Moshe Zadka wrote: > > BTW, that should probably be CCed to the doc-sig, because that information > has to come from somewhere. True enough. Let me get some infrastructure in place and sic them on it. It may also be good to ask for volunteers in c.l.py. Here are my ideas about content: 1. There is the list of hardcoded strings that are probably just triple-quoted strings. 2. There are docstrings. 3. If you happen to know a filename, you can reach into the HTML docs like this: help( "docs:lib/module-grp.html") 4. Docstrings can "redirect" to the HTML docs like this: def myfunc(): """No docs here! Please see """ ... Here's what the HTML-converted output will look like (not perfect but not bad): next[1] up[2] previous[3] Python Library Reference contents[4] modules[5] index[6] Next: 8.1 posix [7] Up: Python Library Reference[8] Previous: 7.15.1 Completer Objects[9] ------------------------------------------------------------------------ 8. Unix Specific Services The modules described in this chapter provide interfaces to features that are unique to the Unix operating system, or in some cases to some or many variants of it. Here's an overview: posix[10] The most common POSIX system calls (normally used via module os[11]). pwd[12] The password database (getpwnam() and friends). grp[13] The group database (getgrnam() and friends). crypt[14] The crypt() function used to check Unix passwords. dl[15] Call C functions in shared objects. dbm[16] The standard ``database'' interface, based on ndbm. gdbm[17] GNU's reinterpretation of dbm. termios[18] POSIX style tty control. ------------------------------------------------------------------------ next[30] up[31] previous[32] Python Library Reference contents[33] modules[34] index[35] Next: 8.1 posix [36] Up: Python Library Reference[37] Previous: 7.15.1 Completer Objects[38] ------------------------------------------------------------------------ See About this document...[39] for information on suggesting changes. [1] docs:lib/module-posix.html [2] docs:lib/lib.html [3] docs:lib/completer-objects.html ... Thanks Fred and Guido. The htmllib code is pretty close for what I need! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From moshez at math.huji.ac.il Sat Jul 15 22:21:14 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 15 Jul 2000 23:21:14 +0300 (IDT) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970C383.9D844BF3@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Is there a way to get a single key portably, rather than > requiring a return? Not that I know of. coding-during-commercials-is-fun-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Sat Jul 15 22:29:21 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 15 Jul 2000 22:29:21 +0200 Subject: [Python-Dev] [patch #100889] a smaller unicode name database References: <006a01bfee85$c787f3a0$f2a6b5d4@hagrid> <007401bfee86$9dd566e0$f2a6b5d4@hagrid> <3970A8ED.28CEC0FE@lemburg.com> Message-ID: <018c01bfee9b$5ce953c0$f2a6b5d4@hagrid> mal wrote: > > second, the uninames module provides two public Python functions: > > I'd name this: unicodenames (we shouldn't be afraid of long > module names ;-). ok. > getname() with an unkown code means that an unassigned > code is being requested: this is a ValueError. > > getcode(name) should raise a ValueError exception too, since the > requested name may be unsupported by Python's version of the > Unicode lib (vers. 3.0). ok. > BTW, did you make the lookups case insensitive ? (Would be > useful, IMHO.) sure. both getcode and \N are case insensitive. > Perhaps a dictionary like interface written on top of > the above two APIs (in Python, of course). sounds like something for a "unicodeutils.py" module ;-) maybe later... ... if anyone would like to play with this, I just updated the patch at: http://w1.132.telia.com/~u13208596/uninames-patch.txt (the module is renamed, the patch isn't...) note: the patch doesn't update the build files. Should be pretty obvious how to do that... From huaiyu_zhu at yahoo.com Sat Jul 15 22:30:31 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Sat, 15 Jul 2000 13:30:31 -0700 (PDT) Subject: [Python-Dev] More discussion on new infix operators In-Reply-To: <1248451855-51961207@hypernet.com> Message-ID: I would like to redirect this discussion to deal with solvable problems, rather than going on at several fronts, not all of them immediately resolvable. I'll provide some background, summarize what I've learned in these discussions, and finally present some options and comments. The issue arises from the attempt to introduce matrix operations into python. This may be an unfamiliar subject here, and we can't hope to agree upon how fundamental or useful it is. So let's just regard it as some mysterious thing that engineers like to do [1]. It happens that in this domain the familiar arithmetic operators split into two personalities, matrix-wise and element-wise. Both are used frequently, often within the same formula. There are several successful commercial and free languages for numerical computation. Many of them use the Matlab approach: ordinary operators for matrix operation, dot-operators for element-wise operation. These languages are very elegant and powerful within the domain of their applications. The problem is, many of them are not object oriented. Most people do not use matrix as part of a math course, but as a method for solving real problems. So they are forced to use Perl, shell scripts or embedded or embedding C/C++ to integrate these calculations into their applications. There is no need to explain here why people would want to use Python as the glue language. You may also agree that calling other languages within Python cannot beat using native Python modules written in C. A great deal of work has been done to build the Numerical package. Although the situation improves tremendously, it still do not appeal to most users of the dedicated matrix languages, for two reasons. One is that NumPy emphasizes on multi-array rather than matrix [2]. The other is the lack of support to distinguish the two personalities of operators. The MatPy project was started to solve these problems. It defines matrix classes that wrap around the Numeric classes, so that ordinary operators default to matrix-wise operations, solving the first problem. The second problem cannot be solved without any change to Python syntax, because there simply isn't enough binary operators available. It is necessary to add new operators. They can all live in the area of current "invalid syntax" so they would not interfere with existing code. We made a patch to the parser to add new operators, and I started a discussion on the best allocation of these operators, when the discussion was also brought here. So much for the background. From these discussions I believe the following is clear (please correct me). 1. It is not much more difficult to add .* style operators than to add @* style operators, even though . is overused and @ is unused. 2. There already exists some facilities for changing syntax within pure python. But I don't remember any mention of where it is, and it seems people do not agree on its usability status at the moment. 3. Most here do not want additional operators in the core language until they see it successfully used in at least one domain. There is also an argument that operators that are only meaningful in one domain would acquire completely incomprehensible semantics in all other domains. 4. There are three types of suggestion for matrix computation: 1) Do not make any syntax change. This includes two proposals: 1.a) Use function calls like dotmul(a,b). 1.b) Define Element and Matrix classes in parallel, with methods for casting. Use a.Element()*b.Element() in place of a.*b. 2) Add additional operators. These operators have fixed precedence as their original counterparts but their semantics can be overridden in applications. They are encouraged to preserve the object-wise and element-wise distinctions. 2.a) Add @* type operators. 2.b) Add .* type operators. 3) User a patched parser. This also allows additional syntactic changes: 3.a) Only as a temporary measure until it is accepted to core language. 3.b) Each application can have their own syntax with some marker on each module to indicate which is which. 3.c) Just develop a different language. 5. Will introducing dot operators conflict with any existing language structures? It does not affect member indicators, because that's always between two names. It may interfere with a trailing decimal point, but that can be fixed by a simple rule (3.*a means 3. * a). Now to the options with my own comments. 1.a) is unacceptable because infix operators improve readability tremendously compared with prefix operators. 1.b) is unacceptable because it is too long and involves at least two method calls and object initialization for each operation. 2.a) was our original plan, and we have a patch for doing so. It is less than optimal aesthetically, and we were not sure to use it for matrix or element-wise operations. It is not intended to be submitted to the core language until the matrix package itself is ready to do so, although it couldn't possibly be changed at that time. 2.b) is my personal favorite. As ESR pointed out, there are also potential applications in other areas. To prevent incompatible semantics, it could be encouraged to be used only in "dual personality" situations. Whenever possible, the dot operators default to "element-wise operation" for any composite objects. For example [1,2] + [10,20] == [1,2,10,20] [1,2] .+ [10,20] == [11,22] 3) is not a good option in this case. First, it is overkill. Linear algebra is a very mature field and only a handful of well-known operators are called for. These operations are written in science and engineering books for years and are very unlikely to change anytime soon. Second, it presents greater danger of incompatibility and fragmentation. Unlike different semantics, different syntax cannot even live within the same module. Third, the very reason people would want to use python for matrix computation is because it is an integral part of their application that need to work with everything else smoothly. The situation now is that MatPy project has to move on, no matter what. It will introduce some kind of binary infix operators just to be viable (unless some entirely new argument comes along). But there do not seem to be additional big hurdles on either algorithm or man power to impede its further development. I hope, and I do believe personally, that it will acquire wide-spread usage once such basic facilities are provided, and will eventually be integrated into the core language. It would be next to impossible to change operators at that moment. Therefore I am most interested in hearing any thoughts on whether there exist any mortal danger for introducing the dot operators. For example, will it be confused with any planned new language features? Arguments on whether this would open the floodgate for other feature requests is unlikely to change the course of MatPy development because we agreed not to talk about how specific the domain is [1]. That's all I could think of at this moment. I'd like to thank your patience for reading so far. I am grateful for all the rational and very helpful opinions I heard here, and I eagerly expect more. Huaiyu [1] I'd be glad to provide easy introduction to numerical computation through email to anyone who would spend half an hour experimenting. [2] The easiest (but not quite accurate) way to describe the difference is to compare with lists and strings: If you are doing text processing you want a dedicated string type, rather than a list of characters, although theoretically the latter can do just about everything the former can. From thomas at xs4all.net Sat Jul 15 23:52:27 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 15 Jul 2000 23:52:27 +0200 Subject: [Python-Dev] More discussion on new infix operators In-Reply-To: ; from huaiyu_zhu@yahoo.com on Sat, Jul 15, 2000 at 01:30:31PM -0700 References: <1248451855-51961207@hypernet.com> Message-ID: <20000715235226.J7340@xs4all.nl> On Sat, Jul 15, 2000 at 01:30:31PM -0700, Huaiyu Zhu wrote: > 1.a) is unacceptable because infix operators improve readability > tremendously compared with prefix operators. Where's the usability study to prove that ? Seriously, though, claiming it is 'unacceptable' without providing arguments ? Why is it unacceptable ? This solution has proven perfectly acceptable for regular expressions, amongst other things. We have Perl gurus, addicted to perl's builtin regexp syntax, join us all the time. And you bet those perl people are addicted to short and confusing notations! > 1.b) is unacceptable because it is too long and involves at least two method > calls and object initialization for each operation. Not necessarily, it depends on your implementation. I would suggest something as follows (probably highly inaccurate because I know didley squat about matrices, but I'll give it a try): class Matrix: "A container class to hold matrices." def __init__(self, ): self.matrix = self.elementwise = ElementwiseMatrix(self.matrix) def __mul__(self, val): return self.matrix.normalmultiply(val) <...> class ElementwiseMatrix: "A container class to hold matrices, implementing elementwise operators." def __init__(self, matrix): self.matrix = matrix def __mul__(self, val): return self.matrix.elementwisemultiply(val) <...> This will allow you to do something like this, given that 'a' and 'b' are Matrices: a.elementwise * b.elementwise to yield a new Matrix (or whatever would be most convenient.) With the Cycle-GC patch, which is in 2.0, you can rewrite them a bit and add some circular references (or you can do that now, if you don't mind having a manual '.destroy()' method) so you can retrieve 'a' if you only have 'a.elementwise'. (Though I would suggest making the front-ends for the real matrix as small as possible, not containing any data themselves, and just create a new one whenever necessary. You just need to be sure not to use 'is' on the front-ends, then, but that's all.) And like this, you can use 'ae = a.elementwise' and pass 'ae' around and operate on it. And this also works immediately with augmented assignment, which might be in 2.0. As for performance, two method calls and an object initialization aren't really a problem, are they ? If you're looking for speed in many little calculations, Python is the wrong language. If you're looking for speed in large calculations, you won't notice this extra overhead. And in the proposal above, the overhead is reduced anyway. And like this, I'd say the whole thing is a lot more Pythonic! And it clearly reflects the 'dual personality' of matrices. > I hope, and I do believe personally, that it will acquire wide-spread usage > once such basic facilities are provided, and will eventually be integrated > into the core language. It would be next to impossible to change operators > at that moment. Therefore I am most interested in hearing any thoughts on > whether there exist any mortal danger for introducing the dot operators. > For example, will it be confused with any planned new language features? Well, I can (and will!) only speak for myself, but in my opinion, the addition of the 'dot' operators would conflict more with the core of the language than any specific feature. The entire philosophy of Python is to keep it as clear and simple and easy to understand as possible. In that light, even the use of the '%' symbol as the printf-operator is a mistake, and I actually agree with that -- even though it's extremely useful. It will be hard to explain to people who have no notion of strings, let alone printf() ;-) The 'dot' operators, though, remind me of the stories about ANSI C and how Microsoft tried to convince the ANSI committee in charge of C to include keywords specifically for the intel architecture. ('near', 'far', and two others, I forget. They are (were?) necessary to deal with the way DOS (and Windows ?) handles Intel's segmented memory model.) Even at that time, the PC was the most used computer around, but the committee decided against including these keywords. The PC might have have been the most used C programming platform, but the committee argued that no single platform should have that much impact on the programming language. (*) I think the 'dot' operators are in the same position. It might bring a lot of people to see the light if it had special matrix syntax, and that syntax might even be applicable in a few other areas without causing too much confusions. And I'd be happy for those people if they did see the light ;) But it stays a single domain, and Python isn't just about drawing as many people to Python as possible. At least, not in my humble opinion. In short, I'm -0 on this idea. If the BDFL is indeed benificial in your case, I won't put up a fight, but I wouldn't add it myself. But-then-I'm-only-+0-on-augmented-assignment-myself<0.3 wink>-ly y'rs, (* This story comes from Peter v.d. Linden's Deep C Secrets. I'm sure Tim, having sat on that committee under one alias or another, can tell this story much more accurately ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sun Jul 16 00:01:56 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 00:01:56 +0200 Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970BA65.5DBFB39A@prescod.net>; from paul@prescod.net on Sat, Jul 15, 2000 at 02:24:21PM -0500 References: <3970B1F4.D4D8BAE9@prescod.net> <010e01bfee90$224df960$f2a6b5d4@hagrid> <3970BA65.5DBFB39A@prescod.net> Message-ID: <20000716000155.K7340@xs4all.nl> On Sat, Jul 15, 2000 at 02:24:21PM -0500, Paul Prescod wrote: > Fredrik Lundh wrote: > > why not just post a site.py patch, and forget about the > > PEP for now? > Also, how should I include a new module in a patch? Do I do a directory > diff? Or just checkin the stupid thing? You can supposedly use 'cvs add' to add the name, and then *not* commit ;) If you then use cvs diff, it should show up. Alternatively, and this is probably best, checkout a new copy of the tree (or simply do a 'cp -pPR') and diff between those two. In franctic times, it can be a hassle to get them both up to date, but if you're just going for a diff that adds a new file, that doesn't matter. (I remember trying to create a good patch in the weekend of July 1st. It was horrible, by the time an update had finished, things it had updated at the start were already changed again :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Sun Jul 16 00:20:49 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 00:20:49 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> <39709962.1C0A576E@lemburg.com> <005c01bfee83$4bafc480$f2a6b5d4@hagrid> <3970A737.6B13B543@lemburg.com> <008b01bfee89$8e731460$f2a6b5d4@hagrid> Message-ID: <3970E3C1.B8718924@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Cool :-) > > oh, just wait until I've gotten my head around Christian's > superoptimizations ;-) BTW, I didn't see your generator script in the patch... could you explain what the tables contain and how they are built ? > > (I'd suggest keeping the original names, BTW) > > unicodedata and unicodectype are okay, but frankly, isn't > "ucnhash" overly cryptic? True. > how about "unicodenames"? Sounds ok to me :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sun Jul 16 00:27:16 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 00:27:16 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: Message-ID: <3970E544.ED8C7213@lemburg.com> Moshe Zadka wrote: > > On Sat, 15 Jul 2000, Fredrik Lundh wrote: > > > paul wrote: > > > As soon as you find a character out of the ASCII range in one of the > > > strings, I think that you should report that the two strings are > > > unequal. > > > > sounds reasonable -- but how do you flag "unequal" in cmp? which > > value is "larger" if all that we know is that they're different... > > We can say something like "beyond the ASCII range, every unicode character > is larger then any regular 8-bit character", and compare > lexicographically. The usual method in the Python compare logic is to revert to the type name for compares in case coercion fails... I think this is the right description in this case: decoding fails and thus coercion becomes impossible. PyObject_Compare() has the logic, we'd just have to reenable it for Unicode which currently is handled as special case to pass through the decoding error. Note that Unicode objects which don't coerce would then always compare larger than 8-bit strings ("unicode" > "string"). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sun Jul 16 00:56:33 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 00:56:33 +0200 Subject: [Python-Dev] Linker problems on Linux References: <3970A619.D2CA39AA@lemburg.com> <20000715204410.I7340@xs4all.nl> Message-ID: <3970EC21.1112C71@lemburg.com> Thomas Wouters wrote: > > On Sat, Jul 15, 2000 at 07:57:45PM +0200, M.-A. Lemburg wrote: > > > I just tried to compile the current CVS version on Linux. > > The compile went fine, but when I started Python, I got: > > > 'import site' failed; use -v for traceback > > Python 2.0b1 (#1, Jul 15 2000, 19:22:33) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > > Traceback (most recent call last): > > File "/home/lemburg/bin/pyinteractive.py", line 7, in ? > > import mx.Tools > > File "/home/lemburg/projects/mx/Tools/__init__.py", line 24, in ? > > from Tools import * > > File "/home/lemburg/projects/mx/Tools/Tools.py", line 10, in ? > > from mxTools import * > > File "/home/lemburg/projects/mx/Tools/mxTools/__init__.py", line 1, in ? > > from mxTools import * > > ImportError: /home/lemburg/projects/mx/Tools/mxTools/mxTools.so: undefined symbol: PyObject_Length > > > Why isn't PyObject_Length being exported anymore ??? > > PyObject_Length is changed into a #define, to PyObject_Size. This preserves > the API but not the ABI ;) GCC has a construct to make one function an alias > for another: > > PyObject * PyObject_Length() __attribute__((alias("PyObject_Size"))); > > But this is not likely to work in other compilers, and not on all > architectures to start with. The most portable solution is probably to make > PyObject_Length() a wrapper for PyObject_Size, and hope the compiler knows > how to handle that most efficiently. Right, there will have to be an exported API PyObject_Length() which then does nothing other than to call PyObject_Size(). There's an example of how this can be done in ceval.c (see the PyEval_CallObject() API). Why hasn't anyone objected to simply dropping such an important API without proper backwards compatibility workaround ? The situation on Windows is already bad enough with extensions compiled against 1.5 causing a segfault... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Sun Jul 16 01:09:01 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 15 Jul 2000 19:09:01 -0400 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <3970EC21.1112C71@lemburg.com> Message-ID: [M.-A. Lemburg] > ... > Why hasn't anyone objected to simply dropping such an important > API without proper backwards compatibility workaround ? If I knew it was happening, I would have whined. And I expect Guido would have screamed. So let's fix it, and move on. I expect patch review isn't as good as it used to be because of the clumsy SourceForge interface, so nobody noticed. > The situation on Windows is already bad enough with extensions > compiled against 1.5 causing a segfault... Hey, your now-buggy old extensions aren't our fault . it's-windows-segfaults-are-a-feature-ly y'rs - tim From thomas at xs4all.net Sun Jul 16 01:53:44 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 01:53:44 +0200 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <3970EC21.1112C71@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 12:56:33AM +0200 References: <3970A619.D2CA39AA@lemburg.com> <20000715204410.I7340@xs4all.nl> <3970EC21.1112C71@lemburg.com> Message-ID: <20000716015344.M7340@xs4all.nl> On Sun, Jul 16, 2000 at 12:56:33AM +0200, M.-A. Lemburg wrote: > Right, there will have to be an exported API PyObject_Length() which > then does nothing other than to call PyObject_Size(). There's an > example of how this can be done in ceval.c (see the PyEval_CallObject() > API). Agreed. I've uploaded a patch that does this to SF. Someone please review it and apply it if desired. I need to head to bed or I won't get breakfast in bed tomorrow ;) > Why hasn't anyone objected to simply dropping such an important > API without proper backwards compatibility workaround ? I claim naivete for myself ;-) I remember seeing the patch go past, and wondering briefly if that wouldn't break binary compatibility. And I remember thinking "Naah, they wouldn't have approved it if that was an issue." :) Green-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bckfnn at worldonline.dk Sun Jul 16 02:02:04 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Sun, 16 Jul 2000 00:02:04 GMT Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <14704.34077.358194.82087@beluga.mojam.com> References: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: <3970fb6d.33279713@smtp.worldonline.dk> On Sat, 15 Jul 2000 10:37:01 -0500 (CDT), you wrote: > >Nothing has really jumped out as the "right" way to express the proposed >builtin that does > > map(None, l1, l2, l3, l4) How about paste? Properly only makes any sense to users who know the unix command tho. regards, finn From paul at prescod.net Sun Jul 16 03:14:30 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 20:14:30 -0500 Subject: [Python-Dev] Help command Message-ID: <39710C75.A7DB127F@prescod.net> Okay, I wrote the help command today. The transcript before was just a Microsoft-style "Technology Preview." I'm pretty happy with the extent to which I can pull in HTML and get lots of content from Fred's HTML distribution immediately. The only trick is finding out where the documentation is. I know that Unix users have a variety of installation patterns and I have no idea if this works at all on the Macintosh. Please help! Here's my current scheme: if os.environ.has_key("PYTHONDOCS"): self.docdir=os.environ["PYTHONDOCS"] else: if os.environ.has_key("PYTHONHOME"): pyhome=os.environ["PYTHONHOME"] else: pyhome=os.path.split( sys.executable )[0] self.docdir=os.path.join( pyhome, "doc" ) testfile=os.path.join( os.path.join( self.docdir, "lib" ), "index.html") if not os.path.exists( testfile ): raise EnvironmentError, ("Cannot find documentation directory" + self.docdir ) -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Sun Jul 16 03:44:55 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 15 Jul 2000 20:44:55 -0500 Subject: [Python-Dev] Help command Message-ID: <39711397.1D3F38A1@prescod.net> Would anyone scream if I just checked this help module in? You can play with it without a site.py patch. Just import it "by hand". A patch is somewhat cumbersome for a new module and a lot less people would try it if they had to hunt down and install a particular patch. I could check it in, we could try it out for a week and then just as easily I could delete it if people don't like it. There is no impact on any other code. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From tim_one at email.msn.com Sun Jul 16 03:52:19 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 15 Jul 2000 21:52:19 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2CB@RED-MSG-50> Message-ID: [Bill Tutt] > I just had a rather unhappy epiphany this morning. > F1, and f2 in ucnhash.c might not work on machines where > sizeof(long) != 32 bits. If "not work" means "may not return the same answer as when a long does have exactly 32 bits", then yes, it's certain not to work. Else I don't know -- I don't understand the (undocumented) postconditions (== what does "work" mean, exactly?) for these functions. If getting the same bits is what's important, f1 can be repaired by inserting this new block: /* cut back to 32 bits */ x &= 0xffffffffL; if (x & 0x80000000L) { /* if negative as a 32-bit thing, extend sign bit to full precision */ x -= 0x80000000L; /* subtract 2**32 in a portable way */ x -= 0x80000000L; /* by subtracting 2**31 twice */ } between the existing x ^= cch + 10; and if (x == -1) This assumes that negative numbers are represented in 2's-complement, but should deliver the same bits in the end on any machine for which that's true (I don't know of any Python platform for which it isn't). The same shoe work for f2 after replacing its negative literal with a 0x...L bit pattern too. The assumption about 2's-comp, and the new "if" block, could be removed by making these functions compute with and return unsigned longs instead. I don't know why they're using signed longs now (the bits produced are exactly the same either way, up until the "%" operation, at which point C is ill-defined when using signed long). BTW, you can test stuff like this on Win32 by cloning the function and using _int64 instead of long in the copy, then see whether they get the same results. From gstein at lyra.org Sun Jul 16 05:47:10 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 15 Jul 2000 20:47:10 -0700 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 15, 2000 at 07:09:01PM -0400 References: <3970EC21.1112C71@lemburg.com> Message-ID: <20000715204710.B29590@lyra.org> On Sat, Jul 15, 2000 at 07:09:01PM -0400, Tim Peters wrote: > [M.-A. Lemburg] > > ... > > Why hasn't anyone objected to simply dropping such an important > > API without proper backwards compatibility workaround ? > > If I knew it was happening, I would have whined. And I expect Guido would > have screamed. So let's fix it, and move on. I expect patch review isn't > as good as it used to be because of the clumsy SourceForge interface, so > nobody noticed. That has nothing to do with it. A full discussion occurred here on what to do. The consensus was reached and the code was changed. I knew it was happening, and I hardly ever look at the Patch Manager. In other words, you can't place the blame there. Personally, I had no issue with it at all. Python 1.5 extensions are not compatible with Python 1.6. We knew that already. So if they have to recompile anyways, then they are going to pick up the macro redefinition. No big deal. > > The situation on Windows is already bad enough with extensions > > compiled against 1.5 causing a segfault... Unrelated FUD. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jul 16 05:55:40 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 15 Jul 2000 20:55:40 -0700 Subject: [Python-Dev] Help command In-Reply-To: <39711397.1D3F38A1@prescod.net>; from paul@prescod.net on Sat, Jul 15, 2000 at 08:44:55PM -0500 References: <39711397.1D3F38A1@prescod.net> Message-ID: <20000715205540.C29590@lyra.org> On Sat, Jul 15, 2000 at 08:44:55PM -0500, Paul Prescod wrote: > Would anyone scream if I just checked this help module in? You can play > with it without a site.py patch. Just import it "by hand". A patch is > somewhat cumbersome for a new module and a lot less people would try it > if they had to hunt down and install a particular patch. I could check > it in, we could try it out for a week and then just as easily I could > delete it if people don't like it. There is no impact on any other code. +1. check the sucker in. I would doubt that anybody has a problem with the *idea*. We can quibble over details much easier with it actually part of the distro. Cheers, -g -- Greg Stein, http://www.lyra.org/ From moshez at math.huji.ac.il Sun Jul 16 06:59:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 07:59:06 +0300 (IDT) Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <3970fb6d.33279713@smtp.worldonline.dk> Message-ID: On Sun, 16 Jul 2000, Finn Bock wrote: > On Sat, 15 Jul 2000 10:37:01 -0500 (CDT), you wrote: > > > > >Nothing has really jumped out as the "right" way to express the proposed > >builtin that does > > > > map(None, l1, l2, l3, l4) > > How about paste? Properly only makes any sense to users who know the > unix command tho. I've been using UNIX for the past 5 years, and have only a dim recollection on paste (when I start doing things that require "cut" and "paste" I usually rich for my big guns like Python (and Perl before that)) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Sun Jul 16 07:02:27 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 08:02:27 +0300 (IDT) Subject: [Python-Dev] Help command In-Reply-To: <39710C75.A7DB127F@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Okay, I wrote the help command today. The transcript before was just a > Microsoft-style "Technology Preview." I'm pretty happy with the extent > to which I can pull in HTML and get lots of content from Fred's HTML > distribution immediately. The only trick is finding out where the > documentation is. I know that Unix users have a variety of installation > patterns and I have no idea if this works at all on the Macintosh. > Please help! In a Red Hat installation, they don't install the HTML docs at all. But then, you don't want to know what I think of Red Hat (demonstrating Python on Red Hat systems usually requires me to resort to slight-of-hand tricks every now and then) In a Debian installation, they live in /usr/doc/python/... (In short, have it a compiled in default. Whoever packages it will decide) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Sun Jul 16 07:03:32 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 08:03:32 +0300 (IDT) Subject: [Python-Dev] Help command In-Reply-To: <39711397.1D3F38A1@prescod.net> Message-ID: On Sat, 15 Jul 2000, Paul Prescod wrote: > Would anyone scream if I just checked this help module in? You can play > with it without a site.py patch. Just import it "by hand". A patch is > somewhat cumbersome for a new module and a lot less people would try it > if they had to hunt down and install a particular patch. I'm +1, as long as the module says on the top ''' # experimental module -- might change interface or die without notice ''' Or something to that effect -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From tim_one at email.msn.com Sun Jul 16 07:24:15 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 01:24:15 -0400 Subject: [Python-Dev] Help command In-Reply-To: <39711397.1D3F38A1@prescod.net> Message-ID: [Paul Prescod] > Would anyone scream if I just checked this help module in? Sure, but who cares? I won't scream at you, and I've been so bitchy lately nobody will even respond to me anymore . Do it! Agree with Moshe that a disclaimer about its experimental nature be prominently displayed at the top, lest we get locked into supporting its initial flawlets forever. From tim_one at email.msn.com Sun Jul 16 07:49:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 01:49:27 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2D5@RED-MSG-50> Message-ID: [Bill Tutt] > After making use of the test drive Alphas by Compaq, I just > uploaded a patch to SF that should fix this nasty issue. > Ugh. Not fun.... Ah, I replied earlier before seeing this. Please see my earlier response for a simpler change that will actually work . Briefly, > > len = cch; > > p = (unsigned char *) key; > > - x = 1694245428; > > + x = (long)0x64fc2234; No point to this change (although there *is* for the *negative* literal in f2). And (for f2) note that the way to spell a long literal is with "L" at the end, not via casting an int literal to long. > > while (--len >= 0) > > - x = (1000003*x) ^ toupper(*(p++)); > > + x = ((0xf4243 * x) & 0xFFFFFFFF) ^ toupper(*(p++)); No point to either of the changes here (you're effectively doing a mod 2**32 on each step, but that isn't necessary -- doing just one at the end (after the loop) is equivalent). > > x ^= cch + 10; > > - if (x == -1) > > - x = -2; > > + if (x == (long)0xFFFFFFFF) > > + x = (long)0xfffffffe; This is wrong in too many ways to count . But your tests won't show the failure unless x *does* happen to equal -1 at the end of the preceding, and you're extremely unlikely to bump into that in a small batch of test cases. Short course: on the 32-bit long machine, x will be -2 after this block then. But on the 64-bit long machine, x will be 2**32-2 (a large and unrelated positive long). The change I suggested is simpler & avoids all those problems; alas, like the above, it also assumes 2's-complement representation of negative longs. From esr at thyrsus.com Sun Jul 16 08:27:38 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Sun, 16 Jul 2000 02:27:38 -0400 Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <14704.34077.358194.82087@beluga.mojam.com> References: <14704.34077.358194.82087@beluga.mojam.com> Message-ID: <20000716022738.B1517@thyrsus.com> Skip Montanaro : > Nothing has really jumped out as the "right" way to express the proposed > builtin that does > > map(None, l1, l2, l3, l4) > > How about collate? What we're doing is effectively what a copy machine does > when it collates multiple copies of its input... At least as good as "knit" and "plait". Better than "weave" (sorry, Barry) and without the unhelpful connotations of "marry" and "zip". A bit long, though. -- Eric S. Raymond Everything you know is wrong. But some of it is a useful first approximation. From esr at thyrsus.com Sun Jul 16 08:40:25 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Sun, 16 Jul 2000 02:40:25 -0400 Subject: [Python-Dev] what to call this zip() function? In-Reply-To: References: Message-ID: <20000716024025.C1517@thyrsus.com> Ka-Ping Yee : > The analogy with a photocopying machine is pretty good, but > i'm afraid this will play havoc with those who see "collate" in > terms of determining sort order. *ouch* Damn. Ping is right. He just blew "collate" out of the water, folks. > It's fairly clear to me that, of the names that evoke images > of some sort, only "parallel", "march", and "merge" are actually > accurate. "zip" and "marry" are nearly accurate except that they > usually give the impression that only two things are being joined. Well argued (and cool pictures, too!). I think parallel, zip, and marry are out for various reasons of connotative overload, so we're down to "merge", "meld", and "knit". -- Eric S. Raymond The end move in politics is always to pick up a gun. -- R. Buckminster Fuller From effbot at telia.com Sun Jul 16 10:25:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 10:25:05 +0200 Subject: [Python-Dev] what to call this zip() function? References: <20000716024025.C1517@thyrsus.com> Message-ID: <004b01bfeeff$59f28380$f2a6b5d4@hagrid> eric: > ping: > > The analogy with a photocopying machine is pretty good, but > > i'm afraid this will play havoc with those who see "collate" in > > terms of determining sort order. > > *ouch* > > Damn. Ping is right. He just blew "collate" out of the water, folks. is this the end of Python development? just imagine what this crowd would have done if guido had asked you *before* he added things like: dir ("hey, dir should give you a list of filenames") cgi ("the computer graphics crowd won't like that") del ("removes files, right?") compile ("but people will think that it generates machine code") global ("but it's not truly global. how about regional or domestic?") hash ("that's a data type, right?") ("or perhaps something from the The Amsterdam Aloha Seed Bank?") hex ("now wait. it's not clear from the name if it con- verts a hex string to an integer, or the other way around. oh, it's the latter. sorry, but that will confuse perl pro- grammers") type ("is that some variation of print, or?") copy ("I'd say most people expect it to copy entire files") and so on... ... maybe something completely random? how about: ymr116c ("sorry, this will confuse the hell out of yeast researchers") ... how about a new rule: if the group fails to reach consensus on a name, especially if they're not discussion the semantics at all, just pick the original name. "zip", in other words. simple zip patches has already been posted to this list. why not take them on a test drive, and see if the *semantics* are what you want them to be? (in the meantime, maybe someone could run the zip/collate/etc thing by comp.lang.python. maybe people are smarter than we think?) From effbot at telia.com Sun Jul 16 10:33:02 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 10:33:02 +0200 Subject: [Python-Dev] RE: Unicode character name hashing References: Message-ID: <005f01bfef00$75fcbf40$f2a6b5d4@hagrid> tim wrote: > If "not work" means "may not return the same answer as when a long does have > exactly 32 bits", then yes, it's certain not to work. Else I don't know -- > I don't understand the (undocumented) postconditions (== what does "work" > mean, exactly?) for these functions. he's using the hash function to look things up in a static table... fwiw, "ucnhash" might be slightly obsolete (see my "unicodenames" patch for a smaller replacement). as far as I can tell, my hash function should work on a 64-bit machine... ...on the other hand, it currently assumes that an "int" is at least 32 bits. should I change this? do we still pretend to support 16-bit computers? From moshez at math.huji.ac.il Sun Jul 16 10:29:42 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 11:29:42 +0300 (IDT) Subject: [Python-Dev] what to call this zip() function? In-Reply-To: <004b01bfeeff$59f28380$f2a6b5d4@hagrid> Message-ID: On Sun, 16 Jul 2000, Fredrik Lundh wrote: > how about a new rule: if the group fails to reach consensus > on a name, especially if they're not discussion the semantics > at all, just pick the original name. > > "zip", in other words. +1. The dir() example shows that pkzip is a non-issue. (After all, we have a dircache module which has no connection to the builtin dir(), and no one seems to have any problems with that) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From billtut at microsoft.com Sun Jul 16 10:35:56 2000 From: billtut at microsoft.com (Bill Tutt) Date: Sun, 16 Jul 2000 01:35:56 -0700 Subject: [Python-Dev] RE: Unicode character name hashing Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2DE@RED-MSG-50> Not that any of this is terribly important given F bot's new patch, except for wrt to the perfect hash generation code. But... > Tim wrote: > [Bill Tutt] > > I just had a rather unhappy epiphany this morning. > > F1, and f2 in ucnhash.c might not work on machines where > > sizeof(long) != 32 bits. > If "not work" means "may not return the same answer as when a long does have > exactly 32 bits", then yes, it's certain not to work. Else I don't know -- > I don't understand the (undocumented) postconditions (== what does "work" > mean, exactly?) for these functions. "Works" means that f1, and f2 must always generate the same bits no matter what platform they're executed on > If getting the same bits is what's important, f1 can be repaired by > inserting this new block: > /* cut back to 32 bits */ > x &= 0xffffffffL; > if (x & 0x80000000L) { > /* if negative as a 32-bit thing, extend sign bit to full precision */ > x -= 0x80000000L; /* subtract 2**32 in a portable way */ > x -= 0x80000000L; /* by subtracting 2**31 twice */ > } > between the existing > x ^= cch + 10; > and > if (x == -1) > This assumes that negative numbers are represented in 2's-complement, but > should deliver the same bits in the end on any machine for which that's true > (I don't know of any Python platform for which it isn't). The same shoe > work for f2 after replacing its negative literal with a 0x...L bit pattern > too. > The assumption about 2's-comp, and the new "if" block, could be removed by > making these functions compute with and return unsigned longs instead. I > don't know why they're using signed longs now (the bits produced are exactly > the same either way, up until the "%" operation, at which point C is > ill-defined when using signed long). The SF patch does indeed use unsigned longs. Bill From thomas at xs4all.net Sun Jul 16 11:01:51 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 11:01:51 +0200 Subject: [Python-Dev] Help command In-Reply-To: ; from moshez@math.huji.ac.il on Sun, Jul 16, 2000 at 08:02:27AM +0300 References: <39710C75.A7DB127F@prescod.net> Message-ID: <20000716110151.N7340@xs4all.nl> On Sun, Jul 16, 2000 at 08:02:27AM +0300, Moshe Zadka wrote: > On Sat, 15 Jul 2000, Paul Prescod wrote: > > Okay, I wrote the help command today. The transcript before was just a > > Microsoft-style "Technology Preview." I'm pretty happy with the extent > > to which I can pull in HTML and get lots of content from Fred's HTML > > distribution immediately. The only trick is finding out where the > > documentation is. I know that Unix users have a variety of installation > > patterns and I have no idea if this works at all on the Macintosh. > > Please help! > In a Red Hat installation, they don't install the HTML docs at all. > But then, you don't want to know what I think of Red Hat (demonstrating > Python on Red Hat systems usually requires me to resort to slight-of-hand > tricks every now and then) Don't forget that RedHat isn't impervious to outside influence. Adding this help thing might make them realize installing the HTML docs is a good idea ;-) And who knows, they might even add documentation for their snackmodule. +1 on the whole idea from me, too. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sun Jul 16 11:21:59 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 11:21:59 +0200 Subject: [Python-Dev] is anyone using the ucnhash C API? References: <002101bfee73$c8531100$f2a6b5d4@hagrid> <39709962.1C0A576E@lemburg.com> <005c01bfee83$4bafc480$f2a6b5d4@hagrid> <3970A737.6B13B543@lemburg.com> <008b01bfee89$8e731460$f2a6b5d4@hagrid> <3970E3C1.B8718924@lemburg.com> Message-ID: <007d01bfef07$4e53fd80$f2a6b5d4@hagrid> mal wrote: > BTW, I didn't see your generator script in the patch... could > you explain what the tables contain and how they are built ? I'm working on the ctype/data portions right now; I'll update the patch along the way, including the generator script when it's ready. (in other words, treat this patch as experimental until it includes the entire database). From mal at lemburg.com Sun Jul 16 11:29:44 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 11:29:44 +0200 Subject: [Python-Dev] Linker problems on Linux References: <3970EC21.1112C71@lemburg.com> <20000715204710.B29590@lyra.org> Message-ID: <39718088.A4172516@lemburg.com> Greg Stein wrote: > > On Sat, Jul 15, 2000 at 07:09:01PM -0400, Tim Peters wrote: > > [M.-A. Lemburg] > > > ... > > > Why hasn't anyone objected to simply dropping such an important > > > API without proper backwards compatibility workaround ? > > > > If I knew it was happening, I would have whined. And I expect Guido would > > have screamed. So let's fix it, and move on. I expect patch review isn't > > as good as it used to be because of the clumsy SourceForge interface, so > > nobody noticed. > > That has nothing to do with it. A full discussion occurred here on what to > do. The consensus was reached and the code was changed. I don't believe that Guido reached any consensus on this... he has always tried to make releases as binary compatible as possible (which is a very user friendly way of designing software). > I knew it was happening, and I hardly ever look at the Patch Manager. In > other words, you can't place the blame there. > > Personally, I had no issue with it at all. Python 1.5 extensions are not > compatible with Python 1.6. We knew that already. So if they have to > recompile anyways, then they are going to pick up the macro redefinition. Sure they are... what makes you think that 1.5 extensions won't work with 1.6 ? Ok, you get annoying warnings, but it's still better as temporary solution than putting out a new version of Python which won't work together with most existing extensions simply due to linker problems. > No big deal. Ok, Greg, you pay the support bill ;-) > > > The situation on Windows is already bad enough with extensions > > > compiled against 1.5 causing a segfault... > > Unrelated FUD. Why unrelated ? Why FUD ? The problem is real (until we check in the fix). Anyway, enough ranting ;-) ... I'll review Thomas Wouters patch and then check it in. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Sun Jul 16 11:34:50 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 11:34:50 +0200 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <39718088.A4172516@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 11:29:44AM +0200 References: <3970EC21.1112C71@lemburg.com> <20000715204710.B29590@lyra.org> <39718088.A4172516@lemburg.com> Message-ID: <20000716113449.P7340@xs4all.nl> On Sun, Jul 16, 2000 at 11:29:44AM +0200, M.-A. Lemburg wrote: > Anyway, enough ranting ;-) ... I'll review Thomas Wouters patch > and then check it in. Wait a couple of minutes. I didn't follow your instructions closely enough, the new patch does ;-) (old patch just added back the functions as wrappers, but didn't #define them as the PyEval_CallObject one did.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Sun Jul 16 11:43:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 11:43:39 +0200 Subject: [Python-Dev] SF login names Message-ID: <397183CB.6415C6BC@lemburg.com> Is there a login name to real name mapping available on SF ? I'm just asking because login names such as "VizNut" or "nowonder" don't carry enough information to identify the person behind it and I think it would be nice to know who you are talking to in patch dicsussions ;-) Perhaps the initial submission comment should include the full name of the patch author ?! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Sun Jul 16 11:47:57 2000 From: billtut at microsoft.com (Bill Tutt) Date: Sun, 16 Jul 2000 02:47:57 -0700 Subject: [Python-Dev] [patch #100889] a smaller unicode name database] Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2DF@RED-MSG-50> From: "Fredrik Lundh" > > my unicode database compression project has resulted in its first > > patch: > > > > https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100899&gro up_id=5470 > two additional comments: > first, the patch was too large for sourceforge (>512000 bytes), so > I've uploaded it to the secret effbot site instead: > http://w1.132.telia.com/~u13208596/uninames-patch.txt > second, the uninames module provides two public Python functions: > getname(code) returns the character name corresponding to > the given character code, or None if the name is not known. > > getcode(name) returns the character code for the given character > name. again, it returns None if the code is not known. Getcode/getname need to use Py_UCS4 instead of int. Smaller data sizes are definitely cool, but as MAL mentioned you didn't include the genration code, nor an explanation about how the stuff works. Looking good so far! Bill From thomas at xs4all.net Sun Jul 16 11:51:31 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 11:51:31 +0200 Subject: [Python-Dev] SF login names In-Reply-To: <397183CB.6415C6BC@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 11:43:39AM +0200 References: <397183CB.6415C6BC@lemburg.com> Message-ID: <20000716115131.Q7340@xs4all.nl> On Sun, Jul 16, 2000 at 11:43:39AM +0200, M.-A. Lemburg wrote: > Is there a login name to real name mapping available on SF ? There's the search engine: the input field with a selector above it, in the bottom left corner. You can type in 'BigBrassBalz' and select 'people', hit 'search', and it'll tell you that's Tim Peters, and provide a link with more information. > I'm just asking because login names such as "VizNut" or > "nowonder" don't carry enough information to identify the person > behind it and I think it would be nice to know who you are > talking to in patch dicsussions ;-) Well, sometimes the realname isn't even that much help ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sun Jul 16 12:01:40 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 12:01:40 +0200 Subject: [Python-Dev] SF login names References: <397183CB.6415C6BC@lemburg.com> Message-ID: <00c101bfef0c$dad680c0$f2a6b5d4@hagrid> mal wrote: > Is there a login name to real name mapping available on SF ? use the search box in the lower left; just change "software/group" to "people", and type the login name... > I'm just asking because login names such as "VizNut" or > "nowonder" don't carry enough information to identify the > person behind it here's a few: viznut = randall hopper nowonder = peter schneider-kamp flight = gregor hoffleit effbot = dunno htrd = toby dickenson ...and the "what the heck does that mean" award goes to: nyamatongwe = neil hodgson cheers /F From mal at lemburg.com Sun Jul 16 12:07:32 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 12:07:32 +0200 Subject: [Python-Dev] SF login names References: <397183CB.6415C6BC@lemburg.com> <00c101bfef0c$dad680c0$f2a6b5d4@hagrid> Message-ID: <39718964.1679361C@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Is there a login name to real name mapping available on SF ? > > use the search box in the lower left; just change "software/group" > to "people", and type the login name... Thanks for the hint. > > I'm just asking because login names such as "VizNut" or > > "nowonder" don't carry enough information to identify the > > person behind it > > here's a few: > > viznut = randall hopper > nowonder = peter schneider-kamp > flight = gregor hoffleit > effbot = dunno > htrd = toby dickenson > > ...and the "what the heck does that mean" award goes to: > > nyamatongwe = neil hodgson :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sun Jul 16 13:04:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 13:04:45 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> Message-ID: <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> mal wrote: > > 1. treat \x as a hexadecimal byte, not a hexadecimal > > character. or in other words, make sure that > > > > ord("\xabcd") == ord(u"\xabcd") > > > > fwiw, this is how it's done in SRE's parser (see the > > python-dev archives for more background). ... > > 5. leave it as it is (just fix the comment). > > I'd suggest 5 -- makes converting 8-bit strings using \x > to Unicode a tad easier. if that's the main argument, you really want alternative 1. with alternative 5, the contents of the string may change if you add a leading "u". alternative 1 is also the only reasonable way to make ordinary strings compatible with SRE (see the earlier discussion for why SRE has to be strict on this one...) so let's change the question into a proposal: for maximum compatibility with 8-bit strings and SRE, let's change "\x" to mean "binary byte" in unicode string literals too. From effbot at telia.com Sun Jul 16 13:28:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 13:28:19 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> <02c701bfedae$7db6fd20$f2a6b5d4@hagrid> <000d01bfedd7$122db480$f2a6b5d4@hagrid> Message-ID: <00ff01bfef18$f3914260$f2a6b5d4@hagrid> I wrote: > not quite ready to be checked in, but good enough to take > on a test drive: > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 anyone looked at this? should I check it in, and see what happens? From moshez at math.huji.ac.il Sun Jul 16 13:27:21 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 14:27:21 +0300 (IDT) Subject: [Python-Dev] PyErr_SafeFormat In-Reply-To: <00ff01bfef18$f3914260$f2a6b5d4@hagrid> Message-ID: On Sun, 16 Jul 2000, Fredrik Lundh wrote: > anyone looked at this? I did. It looked all right, except for the "default" in the switch statements. or-maybe-i-didn't-understand-it-at-all-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Sun Jul 16 13:37:40 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 13:37:40 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: Message-ID: <011501bfef1a$40495880$f2a6b5d4@hagrid> moshe wrote: > On Sun, 16 Jul 2000, Fredrik Lundh wrote: > > > anyone looked at this? > > I did. It looked all right, except for the "default" in the switch > statements. what's wrong with the default clause? the idea is that if it stumbles upon a formatting code it doesn't understand, it copies the rest of the format string to the output string (it cannot just skip unknown codes, since there's no way to know what's in the argument list...) if you can think of a better approach, let me know asap. cheers /F From moshez at math.huji.ac.il Sun Jul 16 13:55:18 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 14:55:18 +0300 (IDT) Subject: [Python-Dev] PyErr_SafeFormat In-Reply-To: <011501bfef1a$40495880$f2a6b5d4@hagrid> Message-ID: On Sun, 16 Jul 2000, Fredrik Lundh wrote: > what's wrong with the default clause? That it wasn't clear... > the idea is that if it stumbles upon a formatting code it doesn't > understand, it copies the rest of the format string to the output > string (it cannot just skip unknown codes, since there's no way > to know what's in the argument list...) Seems reasonable. I'm +1 on that as long as you take the above paragraph and stick it in a comment somewhere in the patch. aw-to-hel-with-documentation-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From mal at lemburg.com Sun Jul 16 14:13:57 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 14:13:57 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> Message-ID: <3971A705.B23AD7D3@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > > 1. treat \x as a hexadecimal byte, not a hexadecimal > > > character. or in other words, make sure that > > > > > > ord("\xabcd") == ord(u"\xabcd") > > > > > > fwiw, this is how it's done in SRE's parser (see the > > > python-dev archives for more background). > ... > > > 5. leave it as it is (just fix the comment). > > > > I'd suggest 5 -- makes converting 8-bit strings using \x > > to Unicode a tad easier. > > if that's the main argument, you really want alternative 1. > > with alternative 5, the contents of the string may change > if you add a leading "u". Ah ok, now I understand what you meant "\xfffe" will turn out as "\xfe", while u"\xfffe" results in u"\ufffe". > alternative 1 is also the only reasonable way to make ordinary > strings compatible with SRE (see the earlier discussion for why > SRE has to be strict on this one...) > > so let's change the question into a proposal: > > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. Hmm, this is probably not in sync with C9X (see section 6.4.4.4), but then perhaps we should depreciate usage of \xXX in the context of Unicode objects altogether. Our \uXXXX notation is far superior to what C9X tries to squeeze into \x (IMHO at least). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sun Jul 16 14:25:12 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 14:25:12 +0200 Subject: [Python-Dev] PyErr_SafeFormat References: <396D5CA2.DBBBDC2C@prescod.net> <20000713015424.X29590@lyra.org> <396D7563.9DB73E1E@prescod.net> <20000713023159.B29590@lyra.org> <007b01bfecef$ecb3abc0$f2a6b5d4@hagrid> <200007141545.KAA13821@cj20424-a.reston1.va.home.com> <02c701bfedae$7db6fd20$f2a6b5d4@hagrid> <000d01bfedd7$122db480$f2a6b5d4@hagrid> <00ff01bfef18$f3914260$f2a6b5d4@hagrid> Message-ID: <3971A9A8.705AA86E@lemburg.com> Fredrik Lundh wrote: > > I wrote: > > > not quite ready to be checked in, but good enough to take > > on a test drive: > > > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 > > anyone looked at this? > > should I check it in, and see what happens? The patch needs some docs which go into api.tex. Right now, all formatting codes supported by printf() are allowed. Your patch changes this into a useful, but far more limited set of codes. In the end, I would prefer the solution I mentioned a few days ago: add checks to configure which determine the availability of snprintf() and then put a macro def into pyport.h which either uses snprintf() (if available) or simply drops the length argument and sticks with sprintf(). Since snprintf() will become a standard anyway, why try to emulate its behaviour ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Sun Jul 16 14:45:02 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 15:45:02 +0300 (IDT) Subject: [Python-Dev] PyErr_SafeFormat In-Reply-To: <3971A9A8.705AA86E@lemburg.com> Message-ID: On Sun, 16 Jul 2000, M.-A. Lemburg wrote: > In the end, I would prefer the solution I mentioned a few days > ago: add checks to configure which determine the availability > of snprintf() and then put a macro def into pyport.h which > either uses snprintf() (if available) or simply drops the > length argument and sticks with sprintf(). > > Since snprintf() will become a standard anyway, why try to > emulate its behaviour ? I'm -1 on that approach. Python tries to cater to low-end C compilers as well, and even when snprintf() will become a standard, it will take time to become a widely available standard. /F's patch works *right* *now* on almost every C compiler. python-turned-ansi-only-when-c9x-is-on-the-brink-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From barry at scottb.demon.co.uk Sun Jul 16 14:46:56 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 16 Jul 2000 13:46:56 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <20000714141801.T29590@lyra.org> Message-ID: <000001bfef23$ec90ce30$060210ac@private> I've been looking at the code to see how hard it is to implement my two function solution to the mismatched extensions crash. I can do the work to generate a patch if the following analysis and design is acceptable. Requirements as I see it are: 1. Python extensions must match the python core to work correctly 2. Python must only load an extension that is compatible with its API 3. Extensions written against python15 do not have to work against python16 etc. 4. No Python Core resources available for implementing backward compatibility for API changes. 5. Extension writers prefer new version of Python to refuse to load old extensions rather the risk subtle bugs through compatibility code in core. I'll use XXX to stand in for the extension name. The changes require that pointers to two functions are returned rather the one to initXXX. The function prefixes "init" and "APIversion" might be made more python specific rather then generic. I propose: - PythonExtensionInitModuleXXX - PythonExtenaionApiVersionXXX The current code calls _PyImport_GetDynLoadFunc that is implemented once for each OS. There are 9 implemented currently. Each does the prepend of "init" to the "shortname" function name. If two function pointers are to be returned then the single function _PyImport_GetDynLoadFunc will need to change into a pair of functions to prevent the possiblity of loading the shared lib twice. _PyImport_GetDynLoadModule return a handle to a dynamically loaded module _PyImport_GetDynLoadFunction return a pointer to a function from a module _PyImport_LoadDynamicModule would call _PyImport_GetDynLoadModule once to load the module and then call _PyImport_GetDynLoadFunction twice to get the pair of function pointers. [Q: _PyImport_LoadDynamicModule may still crash if the Python cannot catch failures in the OS load mechanism.] _PyImport_GetDynLoadFunction will no longer prefix the "init" as that is part of the algorithm of _PyImport_LoadDynamicModule. _PyImport_GetDynLoadFunction would do any name manging that the OS requires to load find the symbol. Prefixing of "_" for example on some unixes. Each extension module implements PythonExtensionInitModuleXXX and PythonExtensionApiVersionXXX. PythonExtensionInitModuleXXX is implemented as before. PythonExtensionApiVersionXXX returns the value PYTHON_API_VERSION as defined in modsupport.h. [Q: Is PYTHON_API_VERSION the corrent symbol?] int PythonExtensionApiVersionXXX() { return PYTHON_API_VERSION; } void PythonExtensionInitModuleXXX() { /* init stuff for module XXX */ } _PyImport_LoadDynamicModule will: 1. Try to load the module - on failure reports an error 2. Try to find PythonExtensionInitModuleXXX from module - on failure report not a python extension - no initXXX function 3. Try to find PythonExtensionApiVersionXXX from module - on failure report its an old extension - please upgrade 4. Call PythonExtensionApiVersionXXX and compare to PYTHON_API_VERSION - if not equal report its an old extension - please upgrade 5. Call PythonExtensionInitModuleXXX Comments please? BArry From bckfnn at worldonline.dk Sun Jul 16 14:42:01 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Sun, 16 Jul 2000 12:42:01 GMT Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> Message-ID: <39719b4f.12749973@smtp.worldonline.dk> [Fredrik Lundh] >mal wrote: > >> > 1. treat \x as a hexadecimal byte, not a hexadecimal >> > character. or in other words, make sure that >> >=20 >> > ord("\xabcd") =3D=3D ord(u"\xabcd") >> >=20 >> > fwiw, this is how it's done in SRE's parser (see the >> > python-dev archives for more background). >... >> > 5. leave it as it is (just fix the comment). >>=20 >> I'd suggest 5 -- makes converting 8-bit strings using \x >> to Unicode a tad easier. > >if that's the main argument, you really want alternative 1. > >with alternative 5, the contents of the string may change >if you add a leading "u". > >alternative 1 is also the only reasonable way to make ordinary >strings compatible with SRE (see the earlier discussion for why >SRE has to be strict on this one...) > >so let's change the question into a proposal: > > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. This would potentially break JPython where the \x is already used to introduce 16-bit chars in ordinary strings. OTOH the implementation of \x in JPython is so full of bugs and inconsistencies that I'm +1 on your proposal. regards, finn From gmcm at hypernet.com Sun Jul 16 15:07:55 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sun, 16 Jul 2000 09:07:55 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007141437.JAA13178@cj20424-a.reston1.va.home.com> References: Your message of "Thu, 13 Jul 2000 14:34:03 -0400." <396E0B9B.DD74EF5@interet.com> Message-ID: <1248369603-56908500@hypernet.com> There seems to be some confusion about this subject. Clarification: An extension compiled for 1.5 will, when loaded by 1.6 / 2.0 either: - fail to load (python15.dll not found) - crash (python15.dll found) This is because the typical way of building an extension on Windows has you link against the import lib for the current version of Python. An import lib is nothing like a static lib - it's a bit of stub code (which gets statically linked in) which automatically does the dynamic load of the associated dll. In other words, python15.lib (the import lib) automatically loads python15.dll at runtime. 1) One proposed solution was to remove the version number from the python dll, and rely on binary compatibility. As Mark said, this would "probably" work. The problem being that moving from "probably" to "certainly" is very difficult. And a failure would be every bit as messy as the current situation (crash - except you've removed any easy way of diagnosing the situation). 2) Another was to stop putting pythonxx.dll in the system directory - that breaks COM support. 3) Another is to have the 1.6 / 2.0 installer remove any other versions of the python dll from the system directory. But that breaks having multiple versions of python installed (which *does* work). 4) Another would be to build extensions with the version number in the name (eg, kjbuckets15.dll), with some added magic to the c-extension import code (so "import kjbuckets" evaluates to loading "kjbuckets" + sys.winver-with-the-dot- removed + ['.dll' | '.pyd']). I don't think this would break anything (but it would tax the capabilities of your typical Windows developer ). 5) The last "solution" I can think of is the Tcl stubs mechanism. In this scenario, the extension would not link against any import lib for python at all. It would rely on getting a pointer to a (large) table of pointers to python-exported functions and symbols in the initmodule call. There's a lot of drudge work involved in setting this up. It does mean that binary compatibility can always be maintained, or if it's decided to break binary compatibility, failure can be made "graceful" . (It also means that embedders could statically link in python, and still dynamically load extensions). Unfortunately, this solution still doesn't help with the transition from 1.5 to 1.6 / 2.0. 6) Of course, we can also do nothing. This is not as bad as it has been painted. Extensions on Windows are supposed to live in the DLLs subdirectory (although certain package writers don't follow this convention); and since this is a new install, it's a new directory. So we tell users not to move extensions from their old install into the new one. Extension writers who don't follow this convention (you know who you are) can figure out their own responses. In an ideal world, I rather like #5 (stubs), but I vote for #4 (version number in the extension module name) or #6 (get a life). - Gordon From nhodgson at bigpond.net.au Sun Jul 16 15:24:23 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Sun, 16 Jul 2000 23:24:23 +1000 Subject: [Python-Dev] SF login names References: <397183CB.6415C6BC@lemburg.com> <00c101bfef0c$dad680c0$f2a6b5d4@hagrid> Message-ID: <038501bfef29$295f9210$8119fea9@neil> > ...and the "what the heck does that mean" award goes to: > > nyamatongwe = neil hodgson About as off-topic as possible ;) nyama="meat" and ngwe="piece of land" so maybe place with good hunting. Its a hill in South-East Zimbabwe and I haven't managed to get there yet. Place names make good account and password names as they can be fairly obscure but still memorable. I expected to fix SourceForge up with a more obvious name once the account was working but its a pain to change stuff on SF so haven't done so. Neil From paul at prescod.net Sun Jul 16 15:49:45 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 08:49:45 -0500 Subject: [Python-Dev] Help command References: Message-ID: <3971BD79.D4F378CD@prescod.net> Moshe Zadka wrote: > > ... > > In a Red Hat installation, they don't install the HTML docs at all. What docs are installed? As I recall, "man Python" was similarly useless on my last Red Hat machine. Hopefully that's been fixed but of course we don't deliver our docs in man format. It was very frustrating to find Python "hidden" like that when I knew that Red Hat uses it extensively themselves. I also wanted it to have an icon in their little start menu thing. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Sun Jul 16 15:51:06 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 08:51:06 -0500 Subject: [Python-Dev] htmllib Message-ID: <3971BDCA.1D69F1CB@prescod.net> I'm having a problem with htmllib. It worked fine in the alpha but not now. I presume it is either sre or unicode. Before I "dig in", is htmllib supposed to work or is someone still working on incompatibilities between it and sre/unicode. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Sun Jul 16 16:04:43 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 09:04:43 -0500 Subject: [Python-Dev] what to call this zip() function? References: <20000716024025.C1517@thyrsus.com> <004b01bfeeff$59f28380$f2a6b5d4@hagrid> Message-ID: <3971C0FB.9EDDF76@prescod.net> Fredrik Lundh wrote: > > ... > > (in the meantime, maybe someone could run the zip/collate/etc > thing by comp.lang.python. maybe people are smarter than we > think?) Agree that the universe will not collapse no matter what name we choose. Unless it has a totally backwards name, people will see it in use and figure it out. We could just do a straight-up vote and be done with it. There is clearly no right or wrong answer, just answers that appeal to various people. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From moshez at math.huji.ac.il Sun Jul 16 16:08:58 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 16 Jul 2000 17:08:58 +0300 (IDT) Subject: [Python-Dev] Help command In-Reply-To: <3971BD79.D4F378CD@prescod.net> Message-ID: On Sun, 16 Jul 2000, Paul Prescod wrote: > > In a Red Hat installation, they don't install the HTML docs at all. > > What docs are installed? The LaTeX files. Did I say how much I enjoy working on Red Hat machines yet? linux-users-should-use-a-real-distribution-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Sun Jul 16 16:09:47 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 16:09:47 +0200 Subject: [Python-Dev] Help command In-Reply-To: <3971BD79.D4F378CD@prescod.net>; from paul@prescod.net on Sun, Jul 16, 2000 at 08:49:45AM -0500 References: <3971BD79.D4F378CD@prescod.net> Message-ID: <20000716160947.T7340@xs4all.nl> On Sun, Jul 16, 2000 at 08:49:45AM -0500, Paul Prescod wrote: > Moshe Zadka wrote: > > In a Red Hat installation, they don't install the HTML docs at all. > What docs are installed? As I recall, "man Python" was similarly useless > on my last Red Hat machine. Hopefully that's been fixed but of course we > don't deliver our docs in man format. It was very frustrating to find > Python "hidden" like that when I knew that Red Hat uses it extensively > themselves. I also wanted it to have an icon in their little start menu > thing. Last I checked, the documentation came in a seperate RPM apckage, And it was just the TeX files, not HTML. And it was just the Library Reference in /usr/doc/python-docs-1.5.2/Doc/, not Doc/lib as one would expect. Oh, there seems to be the Language Reference as well, in /usr/doc/python-docs-1.5.2/Doc/ref/, but those are in FrameMaker format (ref*.doc files. Never heard of FrameMaker myself.) In short, ferget it ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From dberlin at redhat.com Sun Jul 16 16:21:11 2000 From: dberlin at redhat.com (Daniel Berlin+list.python-dev) Date: 16 Jul 2000 10:21:11 -0400 Subject: [Python-Dev] Help command In-Reply-To: Moshe Zadka's message of "Sun, 16 Jul 2000 17:08:58 +0300 (IDT)" References: Message-ID: Moshe Zadka writes: > On Sun, 16 Jul 2000, Paul Prescod wrote: > > > > In a Red Hat installation, they don't install the HTML docs at all. > > > > What docs are installed? > > The LaTeX files. Did I say how much I enjoy working on Red Hat machines > yet? > Yeah, and we love you too. J/K. If you like, I can yell at the people responsible for this, but i'm sure they'll just flame me. --Dan From gmcm at hypernet.com Sun Jul 16 16:57:45 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sun, 16 Jul 2000 10:57:45 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <000001bfef23$ec90ce30$060210ac@private> References: <20000714141801.T29590@lyra.org> Message-ID: <1248363013-57304903@hypernet.com> Barry Scott wrote: > I've been looking at the code to see how hard it is to > implement my two function solution to the mismatched > extensions crash. > > I can do the work to generate a patch if the following > analysis and design is acceptable. > > Requirements as I see it are: > > 1. Python extensions must match the python core to work correctly Not necessarily. > 2. Python must only load an extension that is compatible with its > API > 3. Extensions written against python15 do not have to work > against python16 etc. > 4. No Python Core resources available for implementing backward > compatibility for API changes. > 5. Extension writers prefer new version of Python to refuse to > load > old extensions rather the risk subtle bugs through > compatibility code in core. > > I'll use XXX to stand in for the extension name. > > The changes require that pointers to two functions are > returned rather the one to initXXX. You may be making things more complex than they need to be. On (most?) *nixen, a dynamic load is basically a runtime link. If the link fails (a symbol has disappeared), the module won't load. IOW, I think it's really only when an API call has changed semantics that you need to worry. [Some unixen still don't support dynamic loading; others, eg AIX, do it sufficiently differently to cause havoc with portability; but I think it's fair to say it's a "runtime link".] Further, it's now common practice to have xxx.so be a link to xxx.major.minor.shoesize.so, so diagnosis is relatively easy. In other words, aren't we *only* worried about Windows? If not, then: > int PythonExtensionApiVersionXXX() > { > return PYTHON_API_VERSION; > } is rather restrictive, since you can't write a module at 2.1 time that declares itself compatible with 2.0. Better to pass in the running version, and return yes / no. Now on Windows, since a good chunk of the "link" was done at compile time, the only possible answer is return arg == PYTHON_API_VERSION; But if we're only worried about Windows, I think hacking the Windows load code to turn import kjbuckets into a LoadLibraryEx of kjbuckets+2digitversion+extension does the same thing with less pain. OTOH, I'm willing to live with a procedural solution: - the installer creates a fresh DLLs subdirectory - users are warned not to move extensions into the new DLLs directory, but to get new ones - extension writers who don't use the DLLs directory can - be glad they coded defensively - be sorry they didn't. - Gordon From paul at prescod.net Sun Jul 16 16:20:29 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 09:20:29 -0500 Subject: [Python-Dev] Help command References: Message-ID: <3971C4AD.74EFAD90@prescod.net> Moshe Zadka wrote: > > On Sun, 16 Jul 2000, Paul Prescod wrote: > > > > In a Red Hat installation, they don't install the HTML docs at all. > > > > What docs are installed? > > The LaTeX files. Did I say how much I enjoy working on Red Hat machines > yet? > > linux-users-should-use-a-real-distribution-ly y'rs, Z. Does "man python" work yet? Or maybe my installation was just messed up. As an aside, I think that there are three reasons that it would be nice if we delivered the Python documentation in man format: 1. man(1) die-hards (blow-hards!) would be happy 2. man open() etc. would return Python information which is a way of advertising Python 3. documenting every function in every programming language in a common namespace is a ridiculous idea and by contributing to the problem we can do our part to kill a tool that has lived long past its time. :) -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Sun Jul 16 17:33:13 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 10:33:13 -0500 Subject: [Python-Dev] Help command References: Message-ID: <3971D5B9.A39DA465@prescod.net> "Daniel Berlin+list.python-dev" wrote: > > ... > > If you like, I can yell at the people responsible for this, but i'm > sure they'll just flame me. Wouldn't it make sense for the people packaging the software to talk directly to the people creating the software? I want to put an interactive intepreter dependency on the HTML documentation. I need a guarantee that future Red Hats will install the help files properly. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From thomas at xs4all.net Sun Jul 16 17:58:35 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 17:58:35 +0200 Subject: [Python-Dev] Help command In-Reply-To: <3971C4AD.74EFAD90@prescod.net>; from paul@prescod.net on Sun, Jul 16, 2000 at 09:20:29AM -0500 References: <3971C4AD.74EFAD90@prescod.net> Message-ID: <20000716175835.Y7340@xs4all.nl> On Sun, Jul 16, 2000 at 09:20:29AM -0500, Paul Prescod wrote: > Does "man python" work yet? Or maybe my installation was just messed up. Nope. > As an aside, I think that there are three reasons that it would be nice > if we delivered the Python documentation in man format: > 1. man(1) die-hards (blow-hards!) would be happy Hey, I resemble that remark ! I actually use the Perl manpages every now and then, because it's hard to find stuff about operators and special variables in perldoc. But then, there is hardly any need for that in Python ;) > 2. man open() etc. would return Python information which is a way of > advertising Python 'man open()' would probably return the 'open' command (catagory 1) from the 'open' package, at least on Linux :-) On other systems, it would most likely show the 'open' system call, not the python call. You'd have to fix manpath to search python paths before system paths for that ;) I'm not against supplying the Python library reference in man-form, I'm just not very sure what form it would have or how useful it would be. > 3. documenting every function in every programming language in a common > namespace is a ridiculous idea and by contributing to the problem we can > do our part to kill a tool that has lived long past its time. :) Say what you will, man(1) is a great tool for what it does. Info sucks for that, so does HTML. Info is a nice way to bundle a package's information, and to supply introductions and extended manuals in a way that 'man' cannot, but man stays the quickest quick-ref, man! (But I agree, adding TCL and Perl (and Python!) functions in the common manpath is a silly idea. Lets keep it for the C/POSIX API, commands and the system files ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sun Jul 16 18:12:00 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 18:12:00 +0200 Subject: [Python-Dev] htmllib References: <3971BDCA.1D69F1CB@prescod.net> Message-ID: <001d01bfef40$9383d860$f2a6b5d4@hagrid> paul wrote: > I'm having a problem with htmllib. It worked fine in the alpha but not > now. I presume it is either sre or unicode. Before I "dig in", is > htmllib supposed to work or is someone still working on > incompatibilities between it and sre/unicode. probably SRE. try replacing "import re" with "import pre; re = pre" in htmllib.py, and see if the problem goes away. From tim_one at email.msn.com Sun Jul 16 18:49:51 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 12:49:51 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2DE@RED-MSG-50> Message-ID: [Bill Tutt] > Not that any of this is terribly important given F bot's new patch ... Ack! Nevermind. Old and in the way. From tim_one at email.msn.com Sun Jul 16 18:49:53 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 12:49:53 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <005f01bfef00$75fcbf40$f2a6b5d4@hagrid> Message-ID: [/F] > fwiw, "ucnhash" might be slightly obsolete (see my "unicodenames" patch > for a smaller replacement). as far as I can tell, my hash function should > work on a 64-bit machine... Will look at it once I find it . > ...on the other hand, it currently assumes that an "int" is at > least 32 bits. > > should I change this? Absolutely! "long" is the only way current C has to spell "at least 32". A natural opportunity to put some C9X-derived typedefs into pyport.h, like typedef long Py_int_fast32_t; typedef unsigned long Py_uint_fast32_t; That may be a lie on some 64-bit machines, but it's a benign lie (i.e., will still *work*), and people working on those machines can slop in the #ifdef's they need to cut those back to int (or even short) when appropriate. > do we still pretend to support 16-bit computers? I don't, but we're interested in minimizing the amount of telepathy needed to understand the code regardless. Guido most often used "long" to mean "at least 32" elsewhere in the codebase (this is why the Reference Manual guarantees that a Python int is at least 32 bits, i.e. because C guarantees "long" is) -- in accord with good C practice at the time, and, as it turned out, with what ISO/ANSI standardized. "int" doesn't mean anything to me when I see it except "huh -- this code is probably going to break someday" <0.5 wink>. The C9X typedefs allow to remove all guessing about intent. From effbot at telia.com Sun Jul 16 19:18:37 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 19:18:37 +0200 Subject: [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> Message-ID: <004101bfef49$e2c0cb00$f2a6b5d4@hagrid> > so let's change the question into a proposal: > > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. I've prepared a small patch. If nobody objects, I'll check it in next weekend, or so... http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100912&group_id=5470 From mal at lemburg.com Sun Jul 16 19:58:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 19:58:23 +0200 Subject: [Python-Dev] RE: Unicode character name hashing References: Message-ID: <3971F7BF.321997AA@lemburg.com> Tim Peters wrote: > [hash function in unicodename] > > ...on the other hand, it currently assumes that an "int" is at > > least 32 bits. > > > > should I change this? > > Absolutely! "long" is the only way current C has to spell "at least 32". Note that Unicode code which needs enough bits to hold a UCS4 value should always use the Py_UCS4 type (see unicodeobject.h)... any changes needed to assure the 32-bit nature should then be made to the Py_UCS4 typedef. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sun Jul 16 19:59:33 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 19:59:33 +0200 Subject: [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> <004101bfef49$e2c0cb00$f2a6b5d4@hagrid> Message-ID: <3971F805.D6937139@lemburg.com> Fredrik Lundh wrote: > > > so let's change the question into a proposal: > > > > for maximum compatibility with 8-bit strings and SRE, > > let's change "\x" to mean "binary byte" in unicode string > > literals too. > > I've prepared a small patch. If nobody objects, I'll check > it in next weekend, or so... > > http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100912&group_id=5470 There were objections from Finn Bock and myself: \xXXXX is defined to mean "read all hex chars until the next non-hex char and then cast to the underlying type (char or wchar_t)" in C9X. Don't know about Java... Finn ? Not that this definition is optimal, but we should stick to what the standard says and only depreciate usage of \xXXXX in favour of \uXXXX. Code using escapes like "\xABCD" which then results in "\xCD" is broken anyway -- having u"\xABCD" return "\uABCD" wouldn't make much of a difference (+ the bug would become pretty obvious if viewed in a Unicode aware viewer: Asian characters are very easy to recognize in ASCII text ;-) Would it be hard to make JPython support \uXXXX ? (Or does it already ?) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From DavidA at ActiveState.com Sun Jul 16 20:15:17 2000 From: DavidA at ActiveState.com (David Ascher) Date: Sun, 16 Jul 2000 11:15:17 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Pre-PEP Idea In-Reply-To: <3970B7F3.28F64A3E@prescod.net> Message-ID: > help is not a magical function/statement but an instance with a repr > that does the right thing. And yes, it will probably only be loaded at > the repl. Or it could be a 10-line instance that loads its content when > it is actually used. That might allow Geez, guys, that's one of the first things I did for Python! The URL is long dead, but i think there's a version in the contrib ftp directory. I think I called it ihelp. I used the emacs info files, so is way out of date. --david PS: Then again, these days I'd rather work out an API for a help lookup mechanims that the twelve IDEs could all use, rather than encourage people to stick with glass tty's =). From tim_one at email.msn.com Sun Jul 16 20:14:02 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 14:14:02 -0400 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: <3971A705.B23AD7D3@lemburg.com> Message-ID: [/F] > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. [MAL] > Hmm, this is probably not in sync with C9X (see section 6.4.4.4), The behavior of \x in C9X is nearly incomprehensible -- screw it. > but then perhaps we should depreciate usage of \xXX in the context > of Unicode objects altogether. Our \uXXXX notation is far > superior to what C9X tries to squeeze into \x (IMHO at least). \x is a hack inherited from the last version of C, put in back when they knew they had to do *something* to support "big characters" but had no real idea what. C9X was not allowed to break anything in the std it built on, so they kept all the old implementation-defined \x behavior, and made it even more complicated so it would make some kind sense with the new C9X character gimmicks. Python is stuck trying to make sense out of its ill-considered adoption of old-C's \x notation too. Letting it mean "a byte" regardless of context should make it useless enough that people will eventually learn to avoid it . Note that C9X also has \u and \U notations, and \u in C9X means what it does in Python, except that C9X explicitly punts on what happens for \u values in these (inclusive) ranges: \u0000 - \u0020 \u007f - \u009f \ud800 - \udfff \U is used in C9X for 8-digit (hex) characters, deferring to ISO 10646. If C9X didn't *have* to keep \x around, I'm sure they would have tossed it. From jeremy at beopen.com Sun Jul 16 20:24:20 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Sun, 16 Jul 2000 14:24:20 -0400 (EDT) Subject: [Python-Dev] Linker problems on Linux In-Reply-To: References: <3970EC21.1112C71@lemburg.com> Message-ID: <14705.64980.579728.132423@bitdiddle.concentric.net> >>>>> "TP" == Tim Peters writes: TP> [M.-A. Lemburg] >> ... Why hasn't anyone objected to simply dropping such an >> important API without proper backwards compatibility workaround ? TP> If I knew it was happening, I would have whined. And I expect TP> Guido would have screamed. Actually, I wasn't sure we had reached consensus on the list before I checked it in, so I got an explicit okay from Guido before I made the changes. I know I didn't think about binary compatibility, and suspect that Guido overlooked it as well. TP> So let's fix it, and move on. I TP> expect patch review isn't as good as it used to be because of TP> the clumsy SourceForge interface, so nobody noticed. We got reviews of the patch, too. Fred suggested a small cleanup of the original patch. That said, I don't object to binary compatibility. I'm +0 on the patch. Jeremy From dberlin at redhat.com Sun Jul 16 20:23:43 2000 From: dberlin at redhat.com (Daniel Berlin+list.python-dev) Date: 16 Jul 2000 14:23:43 -0400 Subject: [Python-Dev] Help command In-Reply-To: Paul Prescod's message of "Sun, 16 Jul 2000 10:33:13 -0500" References: <3971D5B9.A39DA465@prescod.net> Message-ID: Paul Prescod writes: > "Daniel Berlin+list.python-dev" wrote: > > > > ... > > > > If you like, I can yell at the people responsible for this, but i'm > > sure they'll just flame me. > > Wouldn't it make sense for the people packaging the software to talk > directly to the people creating the software? Let me find out who owns that RPM. I'm just on the same mailing lists as the development department and whatnot. (I'm a GDB engineer, Cygnus was bought by redhat) > I want to put an > interactive intepreter dependency on the HTML documentation. I need a > guarantee that future Red Hats will install the help files properly. From tim_one at email.msn.com Sun Jul 16 20:24:56 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 14:24:56 -0400 Subject: [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? In-Reply-To: <3971F805.D6937139@lemburg.com> Message-ID: [/F] > for maximum compatibility with 8-bit strings and SRE, > let's change "\x" to mean "binary byte" in unicode string > literals too. > > I've prepared a small patch. If nobody objects, I'll check > it in next weekend, or so... > > [patch 100912] [MAL] > There were objections from Finn Bock and myself: \xXXXX is > defined to mean "read all hex chars until the next non-hex char > and then cast to the underlying type (char or wchar_t)" in C9X. Python and C9X are different languages -- Python isn't obligated to ape C9X's backward-compatibility hacks. > Don't know about Java... Finn ? Java doesn't have \x notation, period -- Java isn't insane . Finn was talking about JPython's attempts to make sense of Python's \x notation. > Not that this definition is optimal, but we should stick to what > the standard says ... Why? It's a standard for a different language. Most of what C9X says about \x boils down to "implementation-defined" anyway, and that's unPythonic on the face of it. From effbot at telia.com Sun Jul 16 20:34:29 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 20:34:29 +0200 Subject: [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> <004101bfef49$e2c0cb00$f2a6b5d4@hagrid> <3971F805.D6937139@lemburg.com> Message-ID: <007701bfef54$848a2300$f2a6b5d4@hagrid> mal wrote: > There were objections from Finn Bock and myself: \xXXXX is > defined to mean "read all hex chars until the next non-hex char > and then cast to the underlying type (char or wchar_t)" in C9X. finn wrote: "the implementation of \x in JPython is so full of bugs and inconsistencies that I'm +1 on your proposal." since when is +1 an objection? ;-) > Not that this definition is optimal, but we should stick to what > the standard says and only depreciate usage of \xXXXX in favour > of \uXXXX. Code using escapes like "\xABCD" which then results > in "\xCD" is broken anyway -- having u"\xABCD" return "\uABCD" > wouldn't make much of a difference (+ the bug would become pretty > obvious if viewed in a Unicode aware viewer: Asian characters are > very easy to recognize in ASCII text ;-) as Tim pointed out in the SRE thread, the only standard that means something here is Python 1.5.2. And in Python 1.5.2, \u means read as many hex digits as you can, and cast the result to a character. I'd say it's more important to be compatible with Python (1.5.2 string literals, SRE regular expression literals), than to be com- patible with C9X... From tim_one at email.msn.com Sun Jul 16 20:29:46 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 14:29:46 -0400 Subject: [Python-Dev] RE: Unicode character name hashing In-Reply-To: <3971F7BF.321997AA@lemburg.com> Message-ID: [MAL] > Note that Unicode code which needs enough bits to hold a UCS4 > value should always use the Py_UCS4 type (see unicodeobject.h)... > any changes needed to assure the 32-bit nature should then > be made to the Py_UCS4 typedef. That's fine. The Py_UCS4 typedef should in turn be defined by direct reference to a C9X-derived typedef from pyport.h: the latter is where 32-bitness "should be" defined. Then the only changes ever needed will be to pyport.h (where people will *expect* such changes to get made). From mal at lemburg.com Sun Jul 16 20:33:45 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 20:33:45 +0200 Subject: [Python-Dev] [patch #100912] should we keep the \xnnnn escape in unicode strings? References: <004201bfee64$8f8101c0$f2a6b5d4@hagrid> <39709844.595B84F6@lemburg.com> <00ef01bfef15$a74175e0$f2a6b5d4@hagrid> <004101bfef49$e2c0cb00$f2a6b5d4@hagrid> <3971F805.D6937139@lemburg.com> <007701bfef54$848a2300$f2a6b5d4@hagrid> Message-ID: <39720009.970A7159@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > There were objections from Finn Bock and myself: \xXXXX is > > defined to mean "read all hex chars until the next non-hex char > > and then cast to the underlying type (char or wchar_t)" in C9X. > > finn wrote: > > "the implementation of \x in JPython is so full of bugs > and inconsistencies that I'm +1 on your proposal." > > since when is +1 an objection? ;-) Ooops, I must have overlooked that one. > > Not that this definition is optimal, but we should stick to what > > the standard says and only depreciate usage of \xXXXX in favour > > of \uXXXX. Code using escapes like "\xABCD" which then results > > in "\xCD" is broken anyway -- having u"\xABCD" return "\uABCD" > > wouldn't make much of a difference (+ the bug would become pretty > > obvious if viewed in a Unicode aware viewer: Asian characters are > > very easy to recognize in ASCII text ;-) > > as Tim pointed out in the SRE thread, the only standard that > means something here is Python 1.5.2. And in Python 1.5.2, > \u means read as many hex digits as you can, and cast the > result to a character. > > I'd say it's more important to be compatible with Python (1.5.2 > string literals, SRE regular expression literals), than to be com- > patible with C9X... Ok, ok, go ahead :-) (please also update the docs, if there are any on this subject -- a grep didn't show anything up on \xXXX) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sun Jul 16 20:40:46 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 16 Jul 2000 20:40:46 +0200 Subject: [Python-Dev] [patch #100889] a smaller unicode name database References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD2DF@RED-MSG-50> Message-ID: <00b301bfef55$ba8992a0$f2a6b5d4@hagrid> bill wrote: > Smaller data sizes are definitely cool, but as MAL mentioned you didn't > include the genration code, nor an explanation about how the stuff works. brute force ;-) seriously, it's a pretty simple design. here's an overview: The unicodenames database consists of two parts: a name database which maps character codes to names, and a code database, mapping names to codes. * The Name Database (getname) First, the 10538 text strings are split into 42193 words, and combined into a 4949-word lexicon (a 29k byte array). Each word is given a unique index number (common words get lower numbers), and there's a "lexicon offset" table mapping from numbers to words (10k). To get back to the original text strings, I use a "phrase book". For each original string, the phrase book stores a a list of word numbers. Numbers 0-127 are stored in one byte, higher numbers (less common words) use two bytes. At this time, about 65% of the words can be represented by a single byte. The result is a 56k array. The final data structure is an offset table, which maps code points to phrase book offsets. Instead of using one big table, I split each code point into a "page number" and a "line number" on that page. offset = line[ (page[code>>SHIFT]< From peter at schneider-kamp.de Sun Jul 16 23:11:25 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 16 Jul 2000 21:11:25 +0000 Subject: [Python-Dev] [PEP204] Range Literals References: Message-ID: <397224FD.B30D1368@schneider-kamp.de> Moshe Zadka wrote: > > I think we decided we don't need those. The only reason people need > generators is for extra efficiency in >From following the recent discussion here (and from my Haskell brain part) I thought that generators are also useful for stuff like: even = (0:sys.maxint:2) first20even = even[:20] Having spend the weekend falling into cold mountain lakes, I may of course be mistaken about this. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From jack at oratrix.nl Sun Jul 16 22:03:44 2000 From: jack at oratrix.nl (Jack Jansen) Date: Sun, 16 Jul 2000 22:03:44 +0200 Subject: [Python-Dev] ascii default encoding Message-ID: <20000716200349.BD9A059214@oratrix.oratrix.nl> Now that the default encoding for 8-bit strings has gone back to "ascii", shouldn't the initialization of strop.whitespace and friends only range over 0..128 in stead of 0..256? On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but the \312 causes problems because it can't be converted from/to unicode as long as the default encoding is ascii... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From paul at prescod.net Sun Jul 16 22:05:53 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 15:05:53 -0500 Subject: [Python-Dev] [PEP204] Range Literals References: <397224FD.B30D1368@schneider-kamp.de> Message-ID: <397215A1.5ED50D9@prescod.net> Peter Schneider-Kamp wrote: > > ... > > I thought that generators are also useful for stuff like: > > even = (0:sys.maxint:2) > first20even = even[:20] Yes but I doubt Guido would take that usage scenariou very seriously. He's been fairly disinterested in lazy behavior for a long time. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gvwilson at nevex.com Sun Jul 16 22:08:30 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Sun, 16 Jul 2000 16:08:30 -0400 (EDT) Subject: [Python-Dev] More discussion on new infix operators In-Reply-To: <20000715235226.J7340@xs4all.nl> Message-ID: > > On Sat, Jul 15, 2000 at 01:30:31PM -0700, Huaiyu Zhu wrote: > > > 1.a) is unacceptable because infix operators improve readability > > tremendously compared with prefix operators. > On Sat, 15 Jul 2000, Thomas Wouters wrote: > > Where's the usability study to prove that ? I'm with Huaiyu on this one --- scientists and engineers have had Lisp-style prefix notation thrown at them many times, and have always resisted it (just as most computer science departments have :-). Greg From mal at lemburg.com Sun Jul 16 22:10:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 22:10:08 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib onlinehelp.py,NONE,1.1 References: <200007161953.MAA30130@slayer.i.sourceforge.net> Message-ID: <397216A0.EE5BB26E@lemburg.com> [New onlinehelp module] Great work ! Wouldn't it make sense to hook the new [whatever it is called now... browser.py] into the module as standard way of displaying the help text provided PYTHONHELPBROWSER is set to one of the supported browsers ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sun Jul 16 22:14:54 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 22:14:54 +0200 Subject: [Python-Dev] ascii default encoding References: <20000716200349.BD9A059214@oratrix.oratrix.nl> Message-ID: <397217BE.29F69C28@lemburg.com> Jack Jansen wrote: > > Now that the default encoding for 8-bit strings has gone back to > "ascii", shouldn't the initialization of strop.whitespace and friends > only range over 0..128 in stead of 0..256? > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but > the \312 causes problems because it can't be converted from/to unicode > as long as the default encoding is ascii... string.py is depreciated -- please use string methods instead. Note that the 8-bit string methods are locale aware in case the C lib APIs isspace() and isalpha() support locales. You may have to adjust the locale setting to POSIX for these APIs to return ASCII only values. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Sun Jul 16 22:18:42 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 15:18:42 -0500 Subject: [Python-Dev] Checked in... Message-ID: <397218A2.A90BCAB3@prescod.net> onlinehelp.py is checked in. Here's the docstring: This module is experimental and could be removed or radically changed at any time. It is intended specifically for the standard interpreter command line but is intended to be compatible with and useful for other (e.g. GUI, handheld) environments. Help with those other environments is appreciated. Please remember to set PYTHONDOCS to the location of your HTML files: e.g. set PYTHONDOCS=c:\python\docs PYTHONDOCS=/python/docs The docs directory should have a lib subdirectory with "index.html" in it. If it has *.tex then you have the documentation *source* distribution, not the runtime distribution. The module exposes one object: "help". "help" has a repr that does something useful if you just type: >>> from onlinehelp import help >>> help Of course one day the first line will be done automatically by site.py or something like that. help can be used as a function. The function takes the following forms of input: help( "string" ) -- built-in topic or global help( ) -- docstring from object or type help( "doc:filename" ) -- filename from Python documentation Type help to get the rest of the instructions. You can also use the module as a command line program: python onlinehelp.py "if" -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From martin at loewis.home.cs.tu-berlin.de Sun Jul 16 22:57:47 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 16 Jul 2000 22:57:47 +0200 Subject: [Python-Dev] Linker problems on Linux Message-ID: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> >> Why hasn't anyone objected to simply dropping such an important >> API without proper backwards compatibility workaround ? > If I knew it was happening, I would have whined. And I expect Guido > would have screamed. Although I ran into this as well, I don't think it is as bad as it sounds. The API has not been changed; only modules compiled for 1.5 (*) won't run in current CVS python - you have to recompile. Even if you restore the PySequence_Length as a Python entry point, you still get a warning that the ABI version mismatches. I haven't thoroughly checked, yet, but I believe that there is no way that Python 2 can guarantee binary compatibility for all 1.5.x modules. For example, if you have a 1.5.2-compiled type in an extension module, and that type happens to implement PySequenceMethods, then applying 'a in b' will likely crash: Python 2 will check for the sq_contains field, but that is past the end of the function table in the old module. So I think it is actually a good thing if an important ABI is not supported anymore. Instead of getting random crashes, you get an error on import. I wish there was a better way to gracefully fail when importing 1.5 modules on Windows. The approach of calling the entry not 'initxxx' but 'init2xxx' would work, but is quite inconvenient. Regards, Martin (*) modules compiled with last week's CVS python won't work, either, but if you have any of these, you know how to recompile things :-) From paul at prescod.net Sun Jul 16 22:58:22 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 15:58:22 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib onlinehelp.py,NONE,1.1 References: <200007161953.MAA30130@slayer.i.sourceforge.net> <397216A0.EE5BB26E@lemburg.com> Message-ID: <397221EE.D248C6D3@prescod.net> "M.-A. Lemburg" wrote: > > [New onlinehelp module] > > Great work ! > > Wouldn't it make sense to hook the new [whatever it is called > now... browser.py] into the module as standard way of displaying > the help text provided PYTHONHELPBROWSER is set to one of > the supported browsers ? Not for me. I would prefer to see the raw text rather than having a new window pop up. I would be happy to provide a mode that does this but I would rather it wasn't the default. Also, some of the text is docstrings. Presumably I wouldn't launch a browser for those, so the interface becomes somewhat inconsistent. How about this: if I taught urllib (or something) to translate doc: URLs into real URLs then you could do something like: browser.browse( "doc:lib/lambda" ) Maybe that would help...more thought needed. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From mhammond at skippinet.com.au Sun Jul 16 23:14:38 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 16 Jul 2000 17:14:38 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <200007141714.MAA14470@cj20424-a.reston1.va.home.com> Message-ID: > I guess the user should think about whether they want their Python COM > things to use 1.5 or 2.0. Only the one they choose should install its > DLL in the system directory; the other one should have its DLL in its > own directory. This may be a good idea - however, it is not necessary. Whatever version of Python was used to register the COM object is also used to execute it. Thus, you can have different objects on the same machine, each of which uses different Python versions. Indeed, the same process could potentially load 2 seperate versions of Python - this should work fine (although it has never been tested by me!) Mark. From mhammond at skippinet.com.au Sun Jul 16 23:14:40 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 16 Jul 2000 17:14:40 -0400 Subject: [Python-Dev] Help command In-Reply-To: <39710C75.A7DB127F@prescod.net> Message-ID: > Okay, I wrote the help command today. The transcript before was just a > Microsoft-style "Technology Preview." I'm pretty happy with the extent > to which I can pull in HTML and get lots of content from Fred's HTML ... > Here's my current scheme: Note that on Windows, there is a help key in the registry that points to the various help files. The core installer uses this, as does the win32all installer. Pythonwin reads this key to populate the "Help" menu. Mark. From gstein at lyra.org Sun Jul 16 23:19:22 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 14:19:22 -0700 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 16, 2000 at 02:14:02PM -0400 References: <3971A705.B23AD7D3@lemburg.com> Message-ID: <20000716141921.K29590@lyra.org> To me, this says punt the \x construct from Unicode objects altogether. If it is broken, then why try to retain it? I *do* find it useful in the regular string objects. For Unicode, I would totally understand needing to use \u instead. Cheers, -g On Sun, Jul 16, 2000 at 02:14:02PM -0400, Tim Peters wrote: > [/F] > > for maximum compatibility with 8-bit strings and SRE, > > let's change "\x" to mean "binary byte" in unicode string > > literals too. > > [MAL] > > Hmm, this is probably not in sync with C9X (see section 6.4.4.4), > > The behavior of \x in C9X is nearly incomprehensible -- screw it. > > > but then perhaps we should depreciate usage of \xXX in the context > > of Unicode objects altogether. Our \uXXXX notation is far > > superior to what C9X tries to squeeze into \x (IMHO at least). > > \x is a hack inherited from the last version of C, put in back when they > knew they had to do *something* to support "big characters" but had no real > idea what. C9X was not allowed to break anything in the std it built on, so > they kept all the old implementation-defined \x behavior, and made it even > more complicated so it would make some kind sense with the new C9X character > gimmicks. > > Python is stuck trying to make sense out of its ill-considered adoption of > old-C's \x notation too. Letting it mean "a byte" regardless of context > should make it useless enough that people will eventually learn to avoid it > . > > Note that C9X also has \u and \U notations, and \u in C9X means what it does > in Python, except that C9X explicitly punts on what happens for \u values in > these (inclusive) ranges: > > \u0000 - \u0020 > \u007f - \u009f > \ud800 - \udfff > > \U is used in C9X for 8-digit (hex) characters, deferring to ISO 10646. > > If C9X didn't *have* to keep \x around, I'm sure they would have tossed it. > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From thomas at xs4all.net Sun Jul 16 23:19:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 23:19:08 +0200 Subject: [Python-Dev] ascii default encoding In-Reply-To: <397217BE.29F69C28@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 10:14:54PM +0200 References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> Message-ID: <20000716231908.A7340@xs4all.nl> On Sun, Jul 16, 2000 at 10:14:54PM +0200, M.-A. Lemburg wrote: > Jack Jansen wrote: > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but > > the \312 causes problems because it can't be converted from/to unicode > > as long as the default encoding is ascii... > string.py is depreciated -- please use string methods instead. You mean 'deprecated'. And please wait with deprecating string.py until all functionality is indeed available through string methods. And please don't do that :) I don't think " ".letters really makes sense... Besides, 'string.join' is a good compromise for the people who don't like " ".join() :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sun Jul 16 23:25:53 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 23:25:53 +0200 Subject: [Python-Dev] Linker problems on Linux In-Reply-To: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Sun, Jul 16, 2000 at 10:57:47PM +0200 References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> Message-ID: <20000716232553.B7340@xs4all.nl> On Sun, Jul 16, 2000 at 10:57:47PM +0200, Martin v. Loewis wrote: > For example, if you have a 1.5.2-compiled type in an extension module, > and that type happens to implement PySequenceMethods, then applying 'a > in b' will likely crash: Python 2 will check for the sq_contains > field, but that is past the end of the function table in the old > module. Nope. This is specifically fixed by the new tp_flags structmember (which was 'unused' before, so reading *that* will work ok) and the PyType_HasFeature macro. All code that wants to access one of the really new struct members (currently, bf_getcharbuffer, sq_contains and the cycle-gc stuff. And my augmented assignment patch adds another 13 ;) should check tp_flags first. See the comment in Include/object.h regarding this. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From martin at loewis.home.cs.tu-berlin.de Sun Jul 16 23:26:45 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 16 Jul 2000 23:26:45 +0200 Subject: [Python-Dev] onlinehelp unforgiving Message-ID: <200007162126.XAA25108@loewis.home.cs.tu-berlin.de> After installing the current Python CVS, I tried to do >>> from onlinehelp import help Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.0/onlinehelp.py", line 323, in ? help=Help(sys.stdout,24) File "/usr/local/lib/python2.0/onlinehelp.py", line 216, in __init__ raise EnvironmentError, error EnvironmentError: Cannot find documentation directory /usr/local/bin/doc. Set the PYTHONDOCS environment variable to point to a "doc" directory. It should have a subdirectory "Lib" with a file named "index.html". I was mainly interested in seeing the doc string retriever in real life. To do so, I'm in the process of obtaining a set of html files (hopefully typing make in the Doc directory will give me those). Still, I think that module should work without HTML help installed, and only fail if somebody tries to access the documentation. Or, there should be a function doc() in addition to help() for retrieving and printing doc strings. I'd actually prefer the second option: >>> doc(xml) Core XML support for Python. This package contains three sub-packages: dom -- The W3C Document Object Model. This supports DOM Level 1 + Namespaces. parser -- Python wrappers for XML parsers (currently only supports Expat). sax -- The Simple API for XML, developed by XML-Dev, led by David Megginson and ported to Python by Lars Marius Garshol. This supports the SAX 2 API. should work even without any documentation installed. In any case, I think this (or the help function) should be builtin. Regards, Martin From thomas at xs4all.net Sun Jul 16 23:33:17 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 23:33:17 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: <20000716141921.K29590@lyra.org>; from gstein@lyra.org on Sun, Jul 16, 2000 at 02:19:22PM -0700 References: <3971A705.B23AD7D3@lemburg.com> <20000716141921.K29590@lyra.org> Message-ID: <20000716233317.C7340@xs4all.nl> On Sun, Jul 16, 2000 at 02:19:22PM -0700, Greg Stein wrote: > To me, this says punt the \x construct from Unicode objects altogether. If > it is broken, then why try to retain it? > I *do* find it useful in the regular string objects. For Unicode, I would > totally understand needing to use \u instead. Don't forget the -U option to python, which turns all strings into Unicode strings. So it's broken now, that's no reason to break it some more ;) I also thought the long-term idea was to make all strings unicode strings. Making the two strings different in more than implementation is probably a bad idea. I'm with Tim here: screw the retarded compatibility. Make \x make sense in normal strings and unicode strings both, but in a way that breaks as little as possible: if it always results in one byte in 8bit strings, it should do the same, IMHO, in unicode strings. I'm also for making \x take at most four bytes, like the documentation states, instead of hassling with a perl-like construct such as C has. I would be very, very suprised if anyone was using \x29E8F28DA727 and expects it to work like \x27. We can use the beta cycle to see if it breaks anything. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Sun Jul 16 23:34:00 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 16 Jul 2000 23:34:00 +0200 Subject: [Python-Dev] ascii default encoding References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> Message-ID: <39722A48.B8DADEB5@lemburg.com> Thomas Wouters wrote: > > On Sun, Jul 16, 2000 at 10:14:54PM +0200, M.-A. Lemburg wrote: > > Jack Jansen wrote: > > > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but > > > the \312 causes problems because it can't be converted from/to unicode > > > as long as the default encoding is ascii... > > > string.py is depreciated -- please use string methods instead. > > You mean 'deprecated'. Hmm, my Webster says "to lessen in value" -- that's what I had in mind... > And please wait with deprecating string.py until all > functionality is indeed available through string methods. And please don't > do that :) I don't think " ".letters really makes sense... "Depreciated" means that you should not use it in new code -- perhaps someday string.py will disappear, even though I doubt that. > Besides, 'string.join' is a good compromise for the people who > don't like " ".join() Tim Peters will have to take the blame for this one ;-) I don't find delimiter.join(sequence) awkward or funny -- using methods for this has added value: it defines an interface which other objects could support as well and thus makes your code polymorph. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Sun Jul 16 23:42:29 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 16 Jul 2000 23:42:29 +0200 Subject: [Python-Dev] ascii default encoding In-Reply-To: <39722A48.B8DADEB5@lemburg.com>; from mal@lemburg.com on Sun, Jul 16, 2000 at 11:34:00PM +0200 References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> <39722A48.B8DADEB5@lemburg.com> Message-ID: <20000716234228.E7340@xs4all.nl> On Sun, Jul 16, 2000 at 11:34:00PM +0200, M.-A. Lemburg wrote: > "Depreciated" means that you should not use it in new code -- > perhaps someday string.py will disappear, even though I doubt > that. The common term for that is 'deprecated', not 'depreciated'. Really :) There once was someone who posted a patch to linux-kernel to fix all those bloody typos everyone made. Almost all instances of 'depreciated' where spelled 'deprecated' ! Deprecate: 1.To express disapproval of; deplore. 2.To belittle; depreciate. Deprecate \Dep"re*cate\: To pray against, as an evil; to seek to avert by prayer; to desire the removal of; to seek deliverance from; to express deep regret for; to disapprove of strongly. The difference is minor, but there really is one. Come on Eric, show us the hackers dictionary on this ;) > > Besides, 'string.join' is a good compromise for the people who > > don't like " ".join() > Tim Peters will have to take the blame for this one ;-) I don't > find delimiter.join(sequence) awkward or funny -- using methods > for this has added value: it defines an interface which other > objects could support as well and thus makes your code polymorph. Indeed. And is there any harm in providing conveniency functions for those that prefer more obvious code ? There is hardly any doubt what string.join(s, sep) does. And some people prefer it that way. They don't care that it's really 'return sep.join(s)' behind their backs. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein at lyra.org Mon Jul 17 00:00:48 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:00:48 -0700 Subject: [Python-Dev] onlinehelp unforgiving In-Reply-To: <200007162126.XAA25108@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Sun, Jul 16, 2000 at 11:26:45PM +0200 References: <200007162126.XAA25108@loewis.home.cs.tu-berlin.de> Message-ID: <20000716150048.N29590@lyra.org> +1 with Martin. There is more to online help than the HTML stuff. Cheers, -g On Sun, Jul 16, 2000 at 11:26:45PM +0200, Martin v. Loewis wrote: > After installing the current Python CVS, I tried to do > > >>> from onlinehelp import help > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/local/lib/python2.0/onlinehelp.py", line 323, in ? > help=Help(sys.stdout,24) > File "/usr/local/lib/python2.0/onlinehelp.py", line 216, in __init__ > raise EnvironmentError, error > EnvironmentError: Cannot find documentation directory /usr/local/bin/doc. > Set the PYTHONDOCS environment variable to point to a "doc" directory. > It should have a subdirectory "Lib" with a file named "index.html". > > I was mainly interested in seeing the doc string retriever in real > life. To do so, I'm in the process of obtaining a set of html files > (hopefully typing make in the Doc directory will give me those). > > Still, I think that module should work without HTML help installed, > and only fail if somebody tries to access the documentation. Or, there > should be a function doc() in addition to help() for retrieving and > printing doc strings. > > I'd actually prefer the second option: > > >>> doc(xml) > Core XML support for Python. > > This package contains three sub-packages: > > dom -- The W3C Document Object Model. This supports DOM Level 1 + > Namespaces. > > parser -- Python wrappers for XML parsers (currently only supports Expat). > > sax -- The Simple API for XML, developed by XML-Dev, led by David > Megginson and ported to Python by Lars Marius Garshol. This > supports the SAX 2 API. > > should work even without any documentation installed. In any case, I > think this (or the help function) should be builtin. > > Regards, > Martin > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 17 00:04:10 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:04:10 -0700 Subject: [Python-Dev] urllib and doc: (was: CVS: python/dist/src/Lib onlinehelp.py,NONE,1.1) In-Reply-To: <397221EE.D248C6D3@prescod.net>; from paul@prescod.net on Sun, Jul 16, 2000 at 03:58:22PM -0500 References: <200007161953.MAA30130@slayer.i.sourceforge.net> <397216A0.EE5BB26E@lemburg.com> <397221EE.D248C6D3@prescod.net> Message-ID: <20000716150410.O29590@lyra.org> On Sun, Jul 16, 2000 at 03:58:22PM -0500, Paul Prescod wrote: >... > How about this: if I taught urllib (or something) to translate doc: URLs > into real URLs then you could do something like: > > browser.browse( "doc:lib/lambda" ) > > Maybe that would help...more thought needed. urllib should NOT try to parse a "doc:" scheme. Any scheme in urllib should ONLY be IANA-registered schemes, and the resulting URL should follow the appropriate RFCs. If doc: is ever registered, then go ahead and teach it to urllib. Until then, I'll scream and shout and be very annoying :-) Big -1 on this from me. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Mon Jul 17 00:01:48 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 00:01:48 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49 References: <200007162139.OAA18443@slayer.i.sourceforge.net> Message-ID: <397230CC.D8380547@lemburg.com> Greg Stein wrote: > > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv18430 > > Modified Files: > unicodeobject.c > Log Message: > stop messing around with goto and just write the macro correctly. > > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.48 > retrieving revision 2.49 > diff -C2 -r2.48 -r2.49 > *** unicodeobject.c 2000/07/16 18:47:43 2.48 > --- unicodeobject.c 2000/07/16 21:39:49 2.49 > *************** > *** 632,640 **** > } > > ! #define UTF8_ERROR(details) do { \ > ! if (utf8_decoding_error(&s, &p, errors, details)) \ > ! goto onError; \ > ! goto nextChar; \ > ! } while (0) > > PyObject *PyUnicode_DecodeUTF8(const char *s, > --- 632,641 ---- > } > > ! #define UTF8_ERROR(details) \ > ! if (1) { \ > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > ! goto onError; \ > ! continue; \ > ! } else Greg, this doesn't work... UTF8_ERROR is used in if-clauses and the above may alter the else-branches in subtle ways which are just as hard to detect as the original bug. The goto may not be the greatest in style, but it doesn't have the above caveats. Please revert the checkin. > > PyObject *PyUnicode_DecodeUTF8(const char *s, > *************** > *** 732,737 **** > } > s += n; > - nextChar: > - /* empty */; > } > > --- 733,736 ---- > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Mon Jul 17 00:09:25 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:09:25 -0700 Subject: [Python-Dev] ascii default encoding In-Reply-To: <20000716234228.E7340@xs4all.nl>; from thomas@xs4all.net on Sun, Jul 16, 2000 at 11:42:29PM +0200 References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> <39722A48.B8DADEB5@lemburg.com> <20000716234228.E7340@xs4all.nl> Message-ID: <20000716150925.Q29590@lyra.org> Thomas is quite correct. "Deprecated" is the proper term. -g On Sun, Jul 16, 2000 at 11:42:29PM +0200, Thomas Wouters wrote: > On Sun, Jul 16, 2000 at 11:34:00PM +0200, M.-A. Lemburg wrote: > > > "Depreciated" means that you should not use it in new code -- > > perhaps someday string.py will disappear, even though I doubt > > that. > > The common term for that is 'deprecated', not 'depreciated'. Really :) There > once was someone who posted a patch to linux-kernel to fix all those bloody > typos everyone made. Almost all instances of 'depreciated' where spelled > 'deprecated' ! > > Deprecate: > > 1.To express disapproval of; deplore. > 2.To belittle; depreciate. > > Deprecate \Dep"re*cate\: > To pray against, as an evil; to seek to avert by prayer; to desire the > removal of; to seek deliverance from; to express deep regret for; to > disapprove of strongly. > > The difference is minor, but there really is one. Come on Eric, show us the > hackers dictionary on this ;) > > > > Besides, 'string.join' is a good compromise for the people who > > > don't like " ".join() > > > Tim Peters will have to take the blame for this one ;-) I don't > > find delimiter.join(sequence) awkward or funny -- using methods > > for this has added value: it defines an interface which other > > objects could support as well and thus makes your code polymorph. > > Indeed. And is there any harm in providing conveniency functions for those > that prefer more obvious code ? There is hardly any doubt what > > string.join(s, sep) > > does. And some people prefer it that way. They don't care that it's really > 'return sep.join(s)' behind their backs. > > -- > Thomas Wouters > > Hi! I'm a .signature virus! copy me into your .signature file to help me spread! > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Mon Jul 17 01:10:20 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:10:20 -0500 Subject: [Python-Dev] Checked in... In-Reply-To: Your message of "Sun, 16 Jul 2000 15:18:42 EST." <397218A2.A90BCAB3@prescod.net> References: <397218A2.A90BCAB3@prescod.net> Message-ID: <200007162310.SAA05749@cj20424-a.reston1.va.home.com> > onlinehelp.py is checked in. Here's the docstring: Sorry Paul, but checking things in is not the appropriate way to start a discussion. Without a prior discussion of requirements and design alternatives I don't think that it should be checked in, even labeled experimental. The proper thing to do if you want feedback on the source code is to post the source code somewhere (here). There are simply too many people with too many ideas for this to work -- Python would become a work designed by committee. I'm on my way to Monterey and don't have time to comment on the contents right now, but please follow the procedure! (And I *know* that the procedure isn't carefully documented -- that's one more reason to be conservative in your checkins.) Annoyed, --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Mon Jul 17 00:13:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 00:13:39 +0200 Subject: [Python-Dev] ascii default encoding References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> <39722A48.B8DADEB5@lemburg.com> <20000716234228.E7340@xs4all.nl> Message-ID: <39723393.BD32D592@lemburg.com> Thomas Wouters wrote: > > On Sun, Jul 16, 2000 at 11:34:00PM +0200, M.-A. Lemburg wrote: > > > "Depreciated" means that you should not use it in new code -- > > perhaps someday string.py will disappear, even though I doubt > > that. > > The common term for that is 'deprecated', not 'depreciated'. Really :) There > once was someone who posted a patch to linux-kernel to fix all those bloody > typos everyone made. Almost all instances of 'depreciated' where spelled > 'deprecated' ! > > Deprecate: > > 1.To express disapproval of; deplore. > 2.To belittle; depreciate. ^^^^^^^^^^ This is what I was referring to :-) > Deprecate \Dep"re*cate\: > To pray against, as an evil; to seek to avert by prayer; to desire the > removal of; to seek deliverance from; to express deep regret for; to > disapprove of strongly. I wouldn't want to pray against string.py ;-) Here's what my Merriam-Webster has to say: Depreciate: 1. to lessen in price or value 2. undervalue, belittle, disparage > The difference is minor, but there really is one. Come on Eric, show us the > hackers dictionary on this ;) It seems that one is stronger than the other. I'll stick with the weaker one ;-) > > > Besides, 'string.join' is a good compromise for the people who > > > don't like " ".join() > > > Tim Peters will have to take the blame for this one ;-) I don't > > find delimiter.join(sequence) awkward or funny -- using methods > > for this has added value: it defines an interface which other > > objects could support as well and thus makes your code polymorph. > > Indeed. And is there any harm in providing conveniency functions for those > that prefer more obvious code ? There is hardly any doubt what > > string.join(s, sep) > > does. And some people prefer it that way. They don't care that it's really > 'return sep.join(s)' behind their backs. Fine... but it'll cause a performance hit when used in tight loops (function call + method lookup). They should use somehting like: spacejoin = ' '.join spacejoin(sequence) instead. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Mon Jul 17 00:17:50 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:17:50 -0700 Subject: [Python-Dev] binary incompatibility and tp_flags (was: Linker problems on Linux) In-Reply-To: <20000716232553.B7340@xs4all.nl>; from thomas@xs4all.net on Sun, Jul 16, 2000 at 11:25:53PM +0200 References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> Message-ID: <20000716151750.R29590@lyra.org> On Sun, Jul 16, 2000 at 11:25:53PM +0200, Thomas Wouters wrote: > On Sun, Jul 16, 2000 at 10:57:47PM +0200, Martin v. Loewis wrote: > > > For example, if you have a 1.5.2-compiled type in an extension module, > > and that type happens to implement PySequenceMethods, then applying 'a > > in b' will likely crash: Python 2 will check for the sq_contains > > field, but that is past the end of the function table in the old > > module. > > Nope. This is specifically fixed by the new tp_flags structmember (which was > 'unused' before, so reading *that* will work ok) and the PyType_HasFeature > macro. All code that wants to access one of the really new struct members > (currently, bf_getcharbuffer, sq_contains and the cycle-gc stuff. And my > augmented assignment patch adds another 13 ;) should check tp_flags first. > > See the comment in Include/object.h regarding this. Actually, those flags should only be used if you are attempting to maintain binary compatibility. At the point where you say "okay. binary compatibility is hereby broken.", then we go and remove the flags for the new structure members. The concept is pretty simple: *) if an extension was compiled before the addition of the new member, then the core should not attempt to access it. to detect this case, the core looks at the flag bit, which will be zero. *) when the extension is recompiled, the struct grows according to the new definition. -) The extension may still have zero in there, so Python still won't look, even though it could -) The extension added Py_TPFLAGS_DEFAULT and picks up the bit that says the new struct member is there. It is probably NULL, unless the author has filled in a value. The last API bump was to 1009 for "Unicode API added". I'm not sure why Guido bumped it since the *addition* of an API shouldn't create binary incompatibility. Regardless, I think we have introduced several semantic incompatibilities or even signature changes in the APIs. We should do a bump for safety's sake and we should toss the two Py_TPFLAGS_HAVE_* macros (and the corresponding tests within the core interpreter). Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Mon Jul 17 01:14:57 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:14:57 -0500 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: Your message of "Sun, 16 Jul 2000 23:33:17 +0200." <20000716233317.C7340@xs4all.nl> References: <3971A705.B23AD7D3@lemburg.com> <20000716141921.K29590@lyra.org> <20000716233317.C7340@xs4all.nl> Message-ID: <200007162314.SAA05833@cj20424-a.reston1.va.home.com> > I'm with Tim here: screw the retarded compatibility. Make \x make sense in > normal strings and unicode strings both, but in a way that breaks as little > as possible: if it always results in one byte in 8bit strings, it should do > the same, IMHO, in unicode strings. I'm also for making \x take at most four > bytes, like the documentation states, instead of hassling with a perl-like > construct such as C has. I would be very, very suprised if anyone was using > \x29E8F28DA727 and expects it to work like \x27. Haven't read Tim's post, but I agree to screw compatibility here, and I see two reasonable ways out: (1) \x takes up to 2 hex chars in 8-bit strings and up to 4 hex chars in Unicode. (2) \x takes up to 4 hex chars in all strings. The presence of -U and ease of JPython compatibility both suggest that (2) is best. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From effbot at telia.com Mon Jul 17 00:25:39 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 00:25:39 +0200 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> Message-ID: <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> guido wrote: > > > onlinehelp.py is checked in. Here's the docstring: > > Sorry Paul, but checking things in is not the appropriate way to start > a discussion. Without a prior discussion of requirements and design > alternatives I don't think that it should be checked in, even labeled > experimental. in paul's defence, note that tim, greg stein, and moshe all told paul to go ahead and check it in... (you'll find their posts in the "help command" thread) cheers /F From effbot at telia.com Mon Jul 17 00:28:43 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 00:28:43 +0200 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? References: <3971A705.B23AD7D3@lemburg.com> <20000716141921.K29590@lyra.org> <20000716233317.C7340@xs4all.nl> <200007162314.SAA05833@cj20424-a.reston1.va.home.com> Message-ID: <004d01bfef75$34bd5a60$f2a6b5d4@hagrid> guido wrote: > Haven't read Tim's post, but I agree to screw compatibility here, and > I see two reasonable ways out: I think tim and thomas both meant "screw C9X compatibility", not "screw 1.5.2 compatibility". (maybe we should continue this discussion when you're back from OSCON? it's not that critical...) From effbot at telia.com Mon Jul 17 00:35:56 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 00:35:56 +0200 Subject: [Python-Dev] ascii default encoding References: <20000716200349.BD9A059214@oratrix.oratrix.nl> Message-ID: <008501bfef76$362902e0$f2a6b5d4@hagrid> jack wrote: > Now that the default encoding for 8-bit strings has gone back to > "ascii", shouldn't the initialization of strop.whitespace and friends > only range over 0..128 in stead of 0..256? > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but > the \312 causes problems because it can't be converted from/to unicode > as long as the default encoding is ascii... on windows and unix boxes, the default locale is "posix" (aka "C"), which in practice means "plain ascii". the only way to end up with non-ascii characters in whitespace/uppercase/lowercase/etc is to explicitly change the locale (by calling locale.setlocale). how does this work on the mac? do the mac libraries use another default locale? one slightly radical way to solve this would be to modify the loops in stropmodule.c/initstrop (changing 256 to 128). From guido at beopen.com Mon Jul 17 01:32:27 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:32:27 -0500 Subject: [Python-Dev] Checked in... In-Reply-To: Your message of "Mon, 17 Jul 2000 00:25:39 +0200." <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> Message-ID: <200007162332.SAA06030@cj20424-a.reston1.va.home.com> > in paul's defence, note that tim, greg stein, and moshe > all told paul to go ahead and check it in... > > (you'll find their posts in the "help command" thread) Sigh. Sorry Paul. Now I'm annoyed at Tim, Greg & Moshe. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From gstein at lyra.org Mon Jul 17 00:37:36 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:37:36 -0700 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) In-Reply-To: <397230CC.D8380547@lemburg.com>; from mal@lemburg.com on Mon, Jul 17, 2000 at 12:01:48AM +0200 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> Message-ID: <20000716153736.T29590@lyra.org> On Mon, Jul 17, 2000 at 12:01:48AM +0200, M.-A. Lemburg wrote: > Greg Stein wrote: >... > > ! #define UTF8_ERROR(details) \ > > ! if (1) { \ > > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > > ! goto onError; \ > > ! continue; \ > > ! } else > > Greg, this doesn't work... UTF8_ERROR is used in if-clauses > and the above may alter the else-branches in subtle ways which > are just as hard to detect as the original bug. The goto may > not be the greatest in style, but it doesn't have the above > caveats. Nope. It *does* work. Note the "else" on the end there. That creates the proper binding. All uses of the UTF8_ERROR() macro have a semicolon after them (like any normal statement does(!)). This expands the macro to: if (1) { ... } else ; /* this is the semicolon I referred to */ Therefore, it creates a complete if/else statement, and any surrounding if/else statements will bind as expected. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 17 00:41:38 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 16 Jul 2000 15:41:38 -0700 Subject: [Python-Dev] Checked in... In-Reply-To: <200007162310.SAA05749@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Sun, Jul 16, 2000 at 06:10:20PM -0500 References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> Message-ID: <20000716154138.U29590@lyra.org> To defend Paul here a bit, we did start some discussion here, and at least some of us said "the concept is fine, so check it in. we can totally revamp as necessary." CVS is a much better communication/testing vehicle than the damn Patch Manager or posting modules at some private web site. And we can always "cvs rm" a module. Another alternative would be to create /nondist/sandbox/ and have people toss modules-for-discussion or modules-in-progress into that area. We can dork around as much as needed. When the module is "ready", then we add it into the /dist/ branch. CVS is a great tool for this. Let's not try to create roadblocks that prevent effective work. Cheers, -g On Sun, Jul 16, 2000 at 06:10:20PM -0500, Guido van Rossum wrote: > > onlinehelp.py is checked in. Here's the docstring: > > Sorry Paul, but checking things in is not the appropriate way to start > a discussion. Without a prior discussion of requirements and design > alternatives I don't think that it should be checked in, even labeled > experimental. > > The proper thing to do if you want feedback on the source code is to > post the source code somewhere (here). There are simply too many > people with too many ideas for this to work -- Python would become a > work designed by committee. > > I'm on my way to Monterey and don't have time to comment on the > contents right now, but please follow the procedure! (And I *know* > that the procedure isn't carefully documented -- that's one more > reason to be conservative in your checkins.) > > Annoyed, > > --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Mon Jul 17 01:39:03 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:39:03 -0500 Subject: [Python-Dev] should we keep the \xnnnn escape in unicode strings? In-Reply-To: Your message of "Mon, 17 Jul 2000 00:28:43 +0200." <004d01bfef75$34bd5a60$f2a6b5d4@hagrid> References: <3971A705.B23AD7D3@lemburg.com> <20000716141921.K29590@lyra.org> <20000716233317.C7340@xs4all.nl> <200007162314.SAA05833@cj20424-a.reston1.va.home.com> <004d01bfef75$34bd5a60$f2a6b5d4@hagrid> Message-ID: <200007162339.SAA06110@cj20424-a.reston1.va.home.com> > guido wrote: > > Haven't read Tim's post, but I agree to screw compatibility here, and > > I see two reasonable ways out: > > I think tim and thomas both meant "screw C9X compatibility", > not "screw 1.5.2 compatibility". Oops again. > (maybe we should continue this discussion when you're back > from OSCON? it's not that critical...) Yes please! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Mon Jul 17 01:00:46 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Sun, 16 Jul 2000 19:00:46 -0400 Subject: [Python-Dev] ascii default encoding In-Reply-To: <20000716234228.E7340@xs4all.nl> References: <20000716200349.BD9A059214@oratrix.oratrix.nl> <397217BE.29F69C28@lemburg.com> <20000716231908.A7340@xs4all.nl> <39722A48.B8DADEB5@lemburg.com> <20000716234228.E7340@xs4all.nl> Message-ID: <20000716190046.A3833@thyrsus.com> Thomas Wouters : > Deprecate: > > 1.To express disapproval of; deplore. > 2.To belittle; depreciate. > > Deprecate \Dep"re*cate\: > To pray against, as an evil; to seek to avert by prayer; to desire the > removal of; to seek deliverance from; to express deep regret for; to > disapprove of strongly. > > The difference is minor, but there really is one. Come on Eric, show us the > hackers dictionary on this ;) Your wish is my command... @hd{deprecated} @g{adj.} @p{} Said of a program or feature that is considered obsolescent and in the process of being phased out, usually in favor of a specified replacement. Deprecated features can, unfortunately, linger on for many years. This term appears with distressing frequency in standards documents when the committees writing the documents realize that large amounts of extant (and presumably happily working) code depend on the feature(s) that have passed out of favor. See also @es{dusty deck}. @comment ESR 1983 -- Eric S. Raymond This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. From tim_one at email.msn.com Mon Jul 17 00:46:35 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 18:46:35 -0400 Subject: [Python-Dev] Checked in... In-Reply-To: <200007162310.SAA05749@cj20424-a.reston1.va.home.com> Message-ID: [Paul Prescod] >> onlinehelp.py is checked in. Here's the docstring: [Guido] > Sorry Paul, but checking things in is not the appropriate way to start > a discussion. There was a discussion, overwhelmingly positive, and then to make further progress Paul asked here whether it wouldn't be easier to just check something in so we could all kick the tires. At least three of us (four if you count me twice, as I tend to do ) said "sure!". > ... > Annoyed, I can understand that too . But as Paul said, it's a self-contained module that "can't" break anything else, and he did ask first, so maybe you could look on it a bit more kindly this once. From guido at beopen.com Mon Jul 17 01:53:41 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 16 Jul 2000 18:53:41 -0500 Subject: [Python-Dev] Checked in... In-Reply-To: Your message of "Sun, 16 Jul 2000 15:41:38 MST." <20000716154138.U29590@lyra.org> References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <20000716154138.U29590@lyra.org> Message-ID: <200007162353.SAA06185@cj20424-a.reston1.va.home.com> [Greg] > To defend Paul here a bit, we did start some discussion here, and at least > some of us said "the concept is fine, so check it in. we can totally revamp > as necessary." I can't even go away for a weekend and they start checking stuff in behind my back. ;-) > CVS is a much better communication/testing vehicle than the damn Patch > Manager or posting modules at some private web site. > > And we can always "cvs rm" a module. Actually, this leaves a turd in the Attic directory. Adding something to the CVS repository gives it a false legitimacy -- not everybody reads the "experimental feature" comment. > Another alternative would be to create /nondist/sandbox/ and have people > toss modules-for-discussion or modules-in-progress into that area. We can > dork around as much as needed. When the module is "ready", then we add it > into the /dist/ branch. I like this much better! > CVS is a great tool for this. Let's not try to create roadblocks that > prevent effective work. Sure. But let's be careful with what we check in, especially into the "dist" source tree. This is not a place for random experiments. I've seen a few examples recently where it seemed some kind of discussion was being carried out by checkins. Regardless of who's right or wrong, that's the wrong medium for such a process. [Tim] > There was a discussion, overwhelmingly positive, and then to make further > progress Paul asked here whether it wouldn't be easier to just check > something in so we could all kick the tires. At least three of us (four if > you count me twice, as I tend to do ) said "sure!". > > > ... > > Annoyed, > > I can understand that too . But as Paul said, it's a self-contained > module that "can't" break anything else, and he did ask first, so maybe you > could look on it a bit more kindly this once. Sure. I recommend the use of the nondist CVS tree for experiments. But to me the dist subtree is sacred and should only contain code we believe we agree on. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul at prescod.net Mon Jul 17 01:06:24 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:06:24 -0500 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> Message-ID: <39723FF0.D6BFD9F1@prescod.net> Okay, I've removed it and attached it to this email but I still think that's a pretty cumbersome way to proceed. I've already made one modification. Future ones will need to be distributed as email patches. As a new module that won't be the basis of anything, and with significant interest, I don't see the danger in a checkin. Anyhow, this version should not require the PYTHONDOCS environment variable unless you try to refer to a help topic that requires the online help. Still, in the future, I don't see the benefit in duplicating the documentation for all of the statements and operators. If you want that documentation, you'll probably need the HTML installed. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html -------------- next part -------------- """ Online help module. This module is experimental and could be removed or radically changed at any time. It is intended specifically for the standard interpreter command line but is intended to be compatible with and useful for other (e.g. GUI, handheld) environments. Help with those other environments is appreciated. Please remember to set PYTHONDOCS to the location of your HTML files: e.g. set PYTHONDOCS=c:\python\docs PYTHONDOCS=/python/docs The docs directory should have a lib subdirectory with "index.html" in it. If it has *.tex then you have the documentation *source* distribution, not the runtime distribution. The module exposes one object: "help". "help" has a repr that does something useful if you just type: >>> from onlinehelp import help >>> help Of course one day the first line will be done automatically by site.py or something like that. help can be used as a function. The function takes the following forms of input: help( "string" ) -- built-in topic or global help( ) -- docstring from object or type help( "doc:filename" ) -- filename from Python documentation Type help to get the rest of the instructions. You can also use the module as a command line program: python onlinehelp.py if """ # todo: consider following links: # help( 3 ) -> follows link 3 in the last-displayed doc # help( 4 ) -> follows link 4 in the last-displayed doc # ... import htmllib # todo: add really basic tr/td support import formatter import os, sys import re prompt="--more-- (enter for more, q to quit) " topics={} # all built-in (non-HTML, non-docstring) topics go in here commands="" # only used at the top level def topLevelCommand( name, description, text ): """ this function is just for use at the top-level to make sure that every advertised top-level topic has a description and every description has text. Maybe we can generalize it later.""" global commands topics[name]=text if description[0]=="[": placeholder="(dummy)" elif description[0]=="<": placeholder="link" else: placeholder="" commands=commands+'help( "%s" ) %s - %s\n' % \ (name, placeholder, description ) topLevelCommand( "intro", "What is Python? Read this first!", """Welcome to Python, the easy to learn, portable, object oriented programming language. [info on how to use help] [info on intepreter]""" ) topLevelCommand( "keywords", "What are the keywords?", "") topLevelCommand( "syntax", "What is the overall syntax?", "[placeholder]") topLevelCommand( "operators", "What operators are available?", "" ) topLevelCommand( "builtins", "What functions, types, etc. are built-in?", "") topLevelCommand( "modules", "What modules are in the standard library?", "") topLevelCommand( "copyright", "Who owns Python?", "[who knows]") topLevelCommand( "moreinfo", "Where is there more information?", "[placeholder]") topLevelCommand( "changes", "What changed in Python 2.0?", "[placeholder]" ) topLevelCommand( "extensions", "What extensions are installed?", "[placeholder]") topLevelCommand( "faq", "What questions are frequently asked?", "[placeholder]") topLevelCommand( "ack", "Who has done work on Python lately?", "[placeholder for list of people who contributed patches]") topics[ "prompt" ]="""""" topics[ "types" ]="""""" topics["everything"]= \ """
The help function allows you to read help on Python's various 
functions, objects, instructions and modules. You have two options:

1. Use help( obj ) to browse the help attached to some function, module
class or other object. e.g. help( dir )

2. Use help( "somestring" ) to browse help on one of the predefined 
help topics, unassociated with any particular object:

%s
""" % commands topics[ "keywords" ]=\ """
"if"       - Conditional execution
"while"    - Loop while a condition is true
"for"      - Loop over a sequence of values (often numbers)
"try"      - Set up an exception handler
"def"      - Define a named function
"class"    - Define a class
"assert"   - Check that some code is working as you expect it to.
"pass"     - Do nothing
"del"      - Delete a data value
"print"    - Print a value
"return"   - Return information from a function
"raise"    - Raise an exception
"break"    - Terminate a loop
"continue" - Skip to the next loop statement
"import"   - Import a module
"global"   - Declare a variable global
"exec"     - Execute some dynamically generated code
"lambda"   - Define an unnamed function

For more information, type e.g. help("assert")
""" topics[ "if" ]="""""" topics[ "while" ]="""""" topics[ "for" ]="""""" topics[ "try" ]="""""" topics[ "def" ]="""""" topics[ "class" ]="""""" topics[ "assert" ]="""""" topics[ "pass" ]="""""" topics[ "del" ]="""""" topics[ "print" ]="""""" topics[ "return" ]="""""" topics[ "raise" ]="""""" topics[ "break" ]="""""" topics[ "continue" ]="""""" topics[ "import" ]="""""" topics[ "global" ]="""""" topics[ "exec" ]="""""" topics[ "lambda" ]="""""" envir_var="PYTHONDOCS" class Help: def __init__( self, out, line_length, docdir=None ): self.out=out self.line_length=line_length self.Parser=htmllib.HTMLParser self.Formatter=formatter.AbstractFormatter self.Pager=Pager self.Writer=formatter.DumbWriter self.docdir=docdir def initDocDir( self ): if os.environ.has_key(envir_var): self.docdir=os.environ[envir_var] else: if os.environ.has_key("PYTHONHOME"): pyhome=os.environ["PYTHONHOME"] else: pyhome=os.path.split( sys.executable )[0] self.docdir=os.path.join( pyhome, "doc" ) testfile=os.path.join( os.path.join( self.docdir, "lib" ), "index.html") if not os.path.exists( testfile ): error = \ """Cannot find documentation directory %s. Set the %s environment variable to point to a "doc" directory. It should have a subdirectory "Lib" with a file named "index.html". """ % (self.docdir, envir_var ) raise EnvironmentError, error def __repr__( self ): self( "everything" ) return "" def __call__( self, ob, out=None ): try: self.call( ob, out ) return 1 except (KeyboardInterrupt, EOFError): return 0 def call( self, ob, out ): self.pager=out or self.Pager( self.out, self.line_length ) if type( ob ) in (type(""),type(u"")): if ob.startswith( "<" ): ob=ob[1:] if ob.endswith( ">" ): ob=ob[:-1] self.write( 'Topic: help( "%s" )\n' % ob ) if ob.startswith("doc:"): path=ob[4:] if not self.docdir: self.initDocDir() fullpath=os.path.join( self.docdir, path ) data=open( fullpath ).read() index=ob.rfind( "/" ) self.writeHTML( ob[:index], data ) else: try: info=topics[ob] docrlmatch=re.search( "(]+>)", info.split("\n")[0] ) if docrlmatch: # a first-line redirect self( docrlmatch.group(1) ) else: self.writeHTML( "", info ) except KeyError: glo=__builtins__.__dict__.get( ob, 0 ) if glo: self( glo ) else: sys.stderr.write( "No such topic "+`ob` ) return None else: self.write( 'Topic: help( %s )\n' % ob ) if hasattr( ob, "__doc__" ): self.writeText(ob.__doc__) else: self.writeText( type( ob ).__doc__ ) def writeHTML( self, base, str ): parser=self.Parser(self.Formatter( self.Writer( self ))) parser.feed( str ) # calls self.write automatically for i in range( len( parser.anchorlist) ): self.pager.write( "[%s] %s/%s\n" %(i+1, base,parser.anchorlist[i] )) self.pager.flush() self.out.write( "\n" ) def writeText( self, str ): self.pager.write( str ) self.pager.flush() self.out.write( "\n" ) def write( self, str ): self.pager.write( str ) from cStringIO import StringIO class Pager: numlines=1 def __init__(self, out, pagesize=24, linestart="" ): self.out=out self.pagesize=pagesize self.buf=StringIO() self.linestart=linestart def close(self ): self.flush() def flush(self ): data=self.buf.getvalue().rstrip() # dump trailing ws while data.endswith( "\n|" ): # dump trailing lines data=data[:-2] self.out.write( data ) self.buf=StringIO() def write(self, str ): lines=str.split( "\n" ) self.buf.write( lines[0] ) for line in lines[1:]: self.buf.write( "\n| " ) self.buf.write( line ) if self.numlines and not self.numlines%(self.pagesize): dat=self.buf.getvalue().strip() self.out.write( "| " ) self.out.write( dat ) self.out.write( "\n" ) j=raw_input(prompt) if j and j[0]=="q": raise EOFError self.buf=StringIO() self.numlines=self.numlines+1 help=Help(sys.stdout,24) def test(): rc = 1 rc = rc and help( "everything" ) rc = rc and help( "exec" ) rc = rc and help( "doc:lib/unix.html" ) rc = rc and help( "doc:lib/module-tty.html" ) rc = rc and help( "doc:ref/print.html" ) rc = rc and help( "faq" ) rc = rc and help( dir ) repr( help ) if __name__=="__main__": if len( sys.argv )!=2: print "Usage: %s or %s test" % ( sys.argv[0], sys.argv[0] ) sys.exit(0) elif sys.argv[1]=="test": test() else: help( sys.argv[1] ) From paul at prescod.net Mon Jul 17 01:11:07 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:11:07 -0500 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <20000716154138.U29590@lyra.org> <200007162353.SAA06185@cj20424-a.reston1.va.home.com> Message-ID: <3972410B.4847D37B@prescod.net> Okay, everybody seems to like the nondist idea, should it be nondist/src/onlinehelp.py # simple nondist/src/help/onlinehelp.py # its own directory -- in case it splits into two modules nondist/src/Lib/onlinehelp.py # code proposed for standard library -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From tim_one at email.msn.com Mon Jul 17 01:12:48 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 16 Jul 2000 19:12:48 -0400 Subject: [Python-Dev] Checked in... In-Reply-To: <200007162353.SAA06185@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > I recommend the use of the nondist CVS tree for experiments. But to me > the dist subtree is sacred and should only contain code we believe we > agree on. That's easy to agree with too, but I need to make a confession here: my belief is that consensus will *never* be reached on anything having to do with doc presentation. Whether it's "structured text", or just what to put in a docstring, the Python community has an unbroken string of failures to agree on anything. Against that, Python has had an obvious need for better online help since the first day I used it, and anticipating that Paul's approach would never reach consensus, my vote to "sure! check it in!" was secretly based on "better anything than (10 more years of) poke-and-hope 'print thing.__doc__'". So this was a very special case to me. I don't cheat often, but when I do I make sure you're not looking <0.9 wink>. at-least-you're-annoyed-at-the-right-person-now-ly y'rs - tim From paul at prescod.net Mon Jul 17 01:22:08 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:22:08 -0500 Subject: [Python-Dev] Checked in... References: Message-ID: <397243A0.5F4AEE4F@prescod.net> Tim Peters wrote: > > ... > > That's easy to agree with too, but I need to make a confession here: my > belief is that consensus will *never* be reached on anything having to do > with doc presentation. Whether it's "structured text", or just what to put > in a docstring, the Python community has an unbroken string of failures to > agree on anything. I'm not quite as pessimistic as you but part of my rationale was anything, no matter how crappy, would be better than nothing, which is what we have years of. I don't care if its: help=""" Try http://www.python.org. Have a nice day! """ help=NameError is just rude! I am optimistic that having a user-friendly way to find out about objects will get the ball rolling for more docstrings, along with Ka Ping's code to put docstrings on the Web and some IDE's docstring reporting. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov at inrialpes.fr Mon Jul 17 01:43:41 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 17 Jul 2000 01:43:41 +0200 (CEST) Subject: [Python-Dev] intallation & help system Message-ID: <200007162343.BAA23397@python.inrialpes.fr> I've just installed the latest Gnome release (http://www.gnome.org) and I must say that I was really pleased (not to say, impressed) by two things: 1. Installation All I had to type was: ~> lynx -source http://go-gnome.com | sh This went on downloading and executing an installation script, which figured out automatically the system I am running on (RedHat 6.2), then asked me to select the nearest mirror and downloaded and installed the right set of packages for RH-6.2. Very cool! I'd like to see something similar for Python. 2. Integrated Help System You guys should definitely try out the Gnome help browser, if you haven't seen it already. This is a very good source of inspiration for implementing and integrated help for Python. The gnome-help browser is a unified interface to man, info and HTML docs. It introduces some 'magic' naming schemes (explained in ghelp:help-browser) For instance: a) http: ... The usual http: naming conventions for accessing documents through HTTP b) file: ... The usual file naming scheme for accessing local files) c) whatis: ... Do a substring search of document names Examples - whatis:ls whatis:xman d) toc: ... Load a table of contents of available documents Examples - toc: toc:man toc:info toc:ghelp e) man: ... Load a manual page Examples - man:ls man:ls(1) f) info: ... Load a GNU info page Examples - info:emacs info:emacs#Top g) ghelp: ... Load a Gnome help page for an application Examples - ghelp:help-browser If you're still unclear on how to implement an integrated help system for Python, replace 'ghelp' by 'python' or 'pyhelp' and steal everything else from the Gnome help system <0.5 wink>. happy-with-open-source'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul at prescod.net Mon Jul 17 01:39:03 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:39:03 -0500 Subject: [Python-Dev] Pre-PEP Idea References: Message-ID: <39724797.21AC2263@prescod.net> David Ascher wrote: > > ... > > Geez, guys, that's one of the first things I did for Python! I guess I'm cleaning up your unfinished project then. :) Anyhow, we can't expect Windows and Mac Python users to have info installed. > PS: Then again, these days I'd rather work out an API for a help lookup > mechanims that the twelve IDEs could all use, rather than encourage people > to stick with glass tty's =). I think that's the long-term goal. But the interpreter is the canonical Python user interface. Once we get information flowing into there, it will be easier to repurpose the information for the GUIs. Anyhow, I find this pretty useful: $ python onlinehelp.py dir Topic: help( ) | dir([object]) -> list of strings | | Return an alphabetized list of names comprising (some of) the attributes | of the given object. Without an argument, the names in the current scope | are listed. With an instance argument, only the instance attributes are | returned. With a class argument, attributes of the base class are not | returned. For other types or arguments, this may list members or methods. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Mon Jul 17 01:48:01 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 18:48:01 -0500 Subject: [Python-Dev] intallation & help system References: <200007162343.BAA23397@python.inrialpes.fr> Message-ID: <397249B1.7FD6EFF6@prescod.net> Vladimir Marangozov wrote: > >.. > > 2. Integrated Help System > > ... > > If you're still unclear on how to implement an integrated help system > for Python, replace 'ghelp' by 'python' or 'pyhelp' and steal everything > else from the Gnome help system <0.5 wink>. Okay, but Python needs a help system that is tty compatible. More advanced help systems should of course be provided by the IDEs. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Vladimir.Marangozov at inrialpes.fr Mon Jul 17 02:02:43 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 17 Jul 2000 02:02:43 +0200 (CEST) Subject: [Python-Dev] intallation & help system In-Reply-To: <397249B1.7FD6EFF6@prescod.net> from "Paul Prescod" at Jul 16, 2000 06:48:01 PM Message-ID: <200007170002.CAA23476@python.inrialpes.fr> Paul Prescod wrote: > > Vladimir Marangozov wrote: > > > >.. > > > > 2. Integrated Help System > > > > ... > > > > If you're still unclear on how to implement an integrated help system > > for Python, replace 'ghelp' by 'python' or 'pyhelp' and steal everything > > else from the Gnome help system <0.5 wink>. > > Okay, but Python needs a help system that is tty compatible. This is not a problem. I can get all this info on a tty instead of in a window. BTW, part of the Gnome installation process is tty-based. If there's a problem of some kind, ESR would solve them in no time, being an ncurses expert :-). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul at prescod.net Mon Jul 17 02:03:21 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 19:03:21 -0500 Subject: [Python-Dev] intallation & help system References: <200007170002.CAA23476@python.inrialpes.fr> Message-ID: <39724D49.135F0684@prescod.net> Vladimir Marangozov wrote: > > ... > > This is not a problem. I can get all this info on a tty instead of > in a window. BTW, part of the Gnome installation process is tty-based. > If there's a problem of some kind, ESR would solve them in no time, > being an ncurses expert :-). I still think that there is something important in not requiring anything beyond a command line, stdin and stdout for the basic help system. Curses won't run on the palm pilot! It should also be possible to plug in more sophisticated UIs where they are available. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gmcm at hypernet.com Mon Jul 17 02:08:48 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sun, 16 Jul 2000 20:08:48 -0400 Subject: [Python-Dev] ascii default encoding In-Reply-To: <39723393.BD32D592@lemburg.com> Message-ID: <1248329948-59293691@hypernet.com> M.-A. Lemburg, > Thomas Wouters wrote: [deprecate / depreciate] > It seems that one is stronger than the other. I'll stick with the > weaker one ;-) One is passive. Your new car depreciates in value, whether Guido says it should or not. > > > > Besides, 'string.join' is a good compromise for the people > > > > who don't like " ".join() > Fine... but it'll cause a performance hit when used in tight > loops (function call + method lookup). They should use somehting > like: > > spacejoin = ' '.join > spacejoin(sequence) > > instead. It's become very obvious that you haven't read c.l.py in quite awhile. - Gordon From paul at prescod.net Mon Jul 17 03:32:34 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 20:32:34 -0500 Subject: [Python-Dev] urllib and doc: (was: CVS: python/dist/src/Lib onlinehelp.py,NONE,1.1) References: <200007161953.MAA30130@slayer.i.sourceforge.net> <397216A0.EE5BB26E@lemburg.com> <397221EE.D248C6D3@prescod.net> <20000716150410.O29590@lyra.org> Message-ID: <39726232.BE95113@prescod.net> Greg Stein wrote: > > ... > > urllib should NOT try to parse a "doc:" scheme. Any scheme in urllib should > ONLY be IANA-registered schemes, and the resulting URL should follow the > appropriate RFCs. > > If doc: is ever registered, then go ahead and teach it to urllib. Until > then, I'll scream and shout and be very annoying :-) Actually, the URL specs are specifically designed to be extensible and to allow local, community-oriented URL (or URN) prefixes. It is a deficiency of urllib that it cannot be taught to deal with new URLs without changing its code. You can extend Java's URL handler or Windows URL handler "externally." Anyhow, I am light years ahead from doing anything in that vein. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From mhammond at skippinet.com.au Mon Jul 17 03:42:36 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 16 Jul 2000 21:42:36 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <1248369603-56908500@hypernet.com> Message-ID: [Gordon, responding to Barry] > In an ideal world, I rather like #5 (stubs), but I vote for #4 > (version number in the extension module name) or #6 (get a > life). #6 sounds good. But as I'm still experiencing a life in Orlando (with a couple of teenage girls dragging a couple of grumpy old Dads around Universal studios), I'll throw something in :-) Barry's idea sounds reasonable - although a little more elaborate than is necessary. Barry calls for all extension authors to modify their extension code. I can't see a simple solution that avoids this. However, the solution seems a little over-elaborate. If we are asking them to change their code, can we investigate whether asking them to insert a simple: if (!Py_IsInitialized()) Py_FatalError("Bad Python version"); /* Never returns */ works OK? I believe it will, as long as Python's fatal error handler doesnt make thread-state assumptions. Too-much-of-a-life-to-check-ly, Mark. From skip at mojam.com Mon Jul 17 03:24:26 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 16 Jul 2000 20:24:26 -0500 (CDT) Subject: [Python-Dev] Help command In-Reply-To: <20000716175835.Y7340@xs4all.nl> References: <3971C4AD.74EFAD90@prescod.net> <20000716175835.Y7340@xs4all.nl> Message-ID: <14706.24650.876236.67230@beluga.mojam.com> Thomas> On Sun, Jul 16, 2000 at 09:20:29AM -0500, Paul Prescod wrote: >> Does "man python" work yet? Or maybe my installation was just messed >> up. Thomas> Nope. It does on Mandrake 6.1 (a RH derivative). Skip From ping at lfw.org Mon Jul 17 07:28:24 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sun, 16 Jul 2000 22:28:24 -0700 (PDT) Subject: [Python-Dev] Checked in... In-Reply-To: <200007162332.SAA06030@cj20424-a.reston1.va.home.com> Message-ID: On Sun, 16 Jul 2000, Guido van Rossum wrote: > > in paul's defence, note that tim, greg stein, and moshe > > all told paul to go ahead and check it in... > > Sigh. Sorry Paul. Now I'm annoyed at Tim, Greg & Moshe. Uh, i'm afraid you'll have to add me to the list. I wanted to encourage Paul to proceed at full speed (even though i didn't get around to it before seeing the messages from the others). I've felt similarly: anything that works reasonably is better than nothing, even if it's not perfect. That said, i have been doing some stuff in this area -- check out http://www.lfw.org/python/ for inspect.py and htmldoc.py. The former in particular is useful for extracting docstrings and argument specs in a nice way. My plan was to complete htmldoc.py and try to get in into the distribution so that anyone could browse documentation on the standard library. It would include an option to start a little webserver with a one-line command so that doc pages could be automatically generated on your own modules as you work on them. The next step in the plan was to provide text output so you could ask about modules from the shell prompt (like a "man" command specific to Python) and a function call you could use from inside the interpreter to get quick help as well. -- ?!ng From martin at loewis.home.cs.tu-berlin.de Mon Jul 17 08:48:50 2000 From: martin at loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 17 Jul 2000 08:48:50 +0200 Subject: [Python-Dev] Compiling the online documentation In-Reply-To: <20000716233459.D7340@xs4all.nl> (message from Thomas Wouters on Sun, 16 Jul 2000 23:34:59 +0200) References: <200007162126.XAA25108@loewis.home.cs.tu-berlin.de> <20000716233459.D7340@xs4all.nl> Message-ID: <200007170648.IAA00903@loewis.home.cs.tu-berlin.de> Thomas Wouters wrote: > Only if you have TeX/LaTeX *and* latex2html installed :P I've failed to find > an RPM for latex2html up til now, and I'm too lazy to hunt down the sources > and compile it myself. I found one at ftp://ftp.cs.tu-berlin.de/pub/linux/Mirrors/contrib.redhat.com/noarch/noarch/latex2html-99.1-1.noarch.rpm This, in turn, needs giftrans-1.12.2-4.i386.rpm. With both packages installed, I tried to run make in Doc/html again, only to get PAPER=letter ../tools/mkhtml.sh api -html_version 4.0 latex2html -init_file /usr/src/python/Doc/perl/l2hinit.perl -dir api -html_version 4.0 /usr/src/python/Doc/api/api.tex Too many arguments for undef operator at /usr/bin/latex2html line 2771, near "$trans)" Too many arguments for undef operator at /usr/bin/latex2html line 3076, near "$etmp)" BEGIN not safe after errors--compilation aborted at /usr/bin/latex2html line 4404. This is with perl 5.6; which perl version is required for latex2html? Regards, Martin From mal at lemburg.com Mon Jul 17 09:55:02 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 09:55:02 +0200 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> Message-ID: <3972BBD6.A81B2577@lemburg.com> Greg Stein wrote: > > On Mon, Jul 17, 2000 at 12:01:48AM +0200, M.-A. Lemburg wrote: > > Greg Stein wrote: > >... > > > ! #define UTF8_ERROR(details) \ > > > ! if (1) { \ > > > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > > > ! goto onError; \ > > > ! continue; \ > > > ! } else > > > > Greg, this doesn't work... UTF8_ERROR is used in if-clauses > > and the above may alter the else-branches in subtle ways which > > are just as hard to detect as the original bug. The goto may > > not be the greatest in style, but it doesn't have the above > > caveats. > > Nope. It *does* work. Note the "else" on the end there. That creates the > proper binding. Greg, I did see the "else", but that does two things: it breaks the code if there's no semicolon after the UT8F_ERROR() macro and it produces warnings which relate to the fact that the "else" part is ambiguous: if (condition) UTF8_ERROR(); else {...} expands to: if (condition) if (1) {...} else ; else {...} And gcc doesn't like it: unicodeobject.c: In function `PyUnicode_FromEncodedObject': unicodeobject.c:424: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:429: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c: In function `PyUnicode_DecodeUTF8': unicodeobject.c:673: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:687: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:698: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:710: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c:716: warning: suggest explicit braces to avoid ambiguous `else' unicodeobject.c: In function `PyUnicode_EncodeUTF8': unicodeobject.c:829: warning: suggest parentheses around arithmetic in operand of | unicodeobject.c: At top level: unicodeobject.c:755: warning: `utf8_encoding_error' defined but not used > All uses of the UTF8_ERROR() macro have a semicolon after them (like any > normal statement does(!)). This expands the macro to: > > if (1) { > ... > } else > ; /* this is the semicolon I referred to */ > > Therefore, it creates a complete if/else statement, and any surrounding > if/else statements will bind as expected. The goto solution is much cleaner and also easier to understand. Please revert the change you made (or I will ;-). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Mon Jul 17 10:09:53 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 10:09:53 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: Message-ID: <003f01bfefc6$64840540$f2a6b5d4@hagrid> mark wrote: > If we are asking them to change their code, can we investigate whether > asking them to insert a simple: > > if (!Py_IsInitialized()) > Py_FatalError("Bad Python version"); /* Never returns */ > > works OK? I believe it will, as long as Python's fatal error handler > doesnt make thread-state assumptions. I'm probably missing something here, but is there any reason you cannot add this code to Py_InitModule4 instead: PyObject *m, *d, *v; PyMethodDef *ml; + if (!Py_IsInitialized()) + Py_FatalError("Bad Python version"); /* Never returns */ if (module_api_version != PYTHON_API_VERSION) fprintf(stderr, api_version_warning, From mal at lemburg.com Mon Jul 17 10:06:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 10:06:50 +0200 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> Message-ID: <3972BE9A.3C09AC97@lemburg.com> > Okay, I've removed it and attached it to this email but I still think > that's a pretty cumbersome way to proceed. I've already made one > modification. Future ones will need to be distributed as email patches. > As a new module that won't be the basis of anything, and with > significant interest, I don't see the danger in a checkin. The standard procedure has always been to put the code and the docs somewhere up on the web to support future developments. You only have to publish the pointers every now and then. It was worked great in the past. I don't see any reason it shouldn't work now. I agree with Guido that dist/ shouldn't be used for developing new software, but also agree with Paul et al. that this is a valueable addition to the standard lib. > Anyhow, this version should not require the PYTHONDOCS environment > variable unless you try to refer to a help topic that requires the > online help. Still, in the future, I don't see the benefit in > duplicating the documentation for all of the statements and operators. > If you want that documentation, you'll probably need the HTML installed. You may want to have a look at my hack.py utility which already provides a convenient way of printing the doc strings *and* the published interface: http://starship.python.net/?lemburg/hack.py It needs to be modified a bit to work with SRE since it uses the old regs array (the tool was written for regex which had this array, then ported to re, which also had the array, but didn't document it; SRE doesn't have it anymore... sigh). Here's an example: >>> hack.docs(os) Module : _exit : _exit(status) Exit to the system with specified status, without normal exit processing. chdir : chdir(path) -> None Change the current working directory to the specified path. chmod : chmod(path, mode) -> None Change the access permissions of a file. chown : chown(path, uid, gid) -> None Change the owner and group id of path to the numeric uid and gid. close : close(fd) -> None Close a file descriptor (for low level IO). dup : dup(fd) -> fd2 Return a duplicate of a file descriptor. dup2 : dup2(fd, fd2) -> None Duplicate file descriptor. execv : execv(path, args) Execute an executable path with arguments, replacing current process. path: path of executable file args: tuple or list of strings execve : execve(path, args, env) Execute a path with arguments and environment, replacing current process. path: path of executable file args: tuple or list of arguments env: dictonary of strings mapping to strings fdopen : fdopen(fd, [, mode='r' [, bufsize]]) -> file_object Return an open file object connected to a file descriptor. fork : fork() -> pid Fork a child process. Return 0 to child process and PID of child to parent process. fstat : fstat(fd) -> (mode, ino, dev, nlink, uid, gid, size, atime, mtime, ctime) Like stat(), but for an open file descriptor. ftruncate : ftruncate(fd, length) -> None Truncate a file to a specified length. getcwd : getcwd() -> path Return a string representing the current working directory. getegid : getegid() -> egid Return the current process's effective group id. geteuid : geteuid() -> euid Return the current process's effective user id. getgid : getgid() -> gid Return the current process's group id. getpgrp : getpgrp() -> pgrp Return the current process group id. getpid : getpid() -> pid Return the current process id getppid : getppid() -> ppid Return the parent's process id. getuid : getuid() -> uid Return the current process's user id. kill : kill(pid, sig) -> None Kill a process with a signal. link : link(src, dst) -> None Create a hard link to a file. listdir : listdir(path) -> list_of_strings Return a list containing the names of the entries in the directory. path: path of directory to list The list is in arbitrary order. It does not include the special entries '.' and '..' even if they are present in the directory. lseek : lseek(fd, pos, how) -> newpos Set the current position of a file descriptor. lstat : lstat(path) -> (mode,ino,dev,nlink,uid,gid,size,atime,mtime,ctime) Like stat(path), but do not follow symbolic links. mkdir : mkdir(path [, mode=0777]) -> None Create a directory. mkfifo : mkfifo(file, [, mode=0666]) -> None Create a FIFO (a POSIX named pipe). nice : nice(inc) -> new_priority Decrease the priority of process and return new priority. open : open(filename, flag [, mode=0777]) -> fd Open a file (for low level IO). Module path : Common pathname manipulations, Posix version. Instead of importing this module directly, import os and refer to this module as os.path. pipe : pipe() -> (read_end, write_end) Create a pipe. popen : popen(command [, mode='r' [, bufsize]]) -> pipe Open a pipe to/from a command returning a file object. putenv : putenv(key, value) -> None Change or add an environment variable. read : read(fd, buffersize) -> string Read a file descriptor. readlink : readlink(path) -> path Return a string representing the path to which the symbolic link points. remove : remove(path) -> None Remove a file (same as unlink(path)). rename : rename(old, new) -> None Rename a file or directory. rmdir : rmdir(path) -> None Remove a directory. setgid : setgid(gid) -> None Set the current process's group id. setpgid : setpgid(pid, pgrp) -> None Call the system call setpgid(). setpgrp : setpgrp() -> None Make this process a session leader. setsid : setsid() -> None Call the system call setsid(). setuid : setuid(uid) -> None Set the current process's user id. stat : stat(path) -> (mode,ino,dev,nlink,uid,gid,size,atime,mtime,ctime) Perform a stat system call on the given path. strerror : strerror(code) -> string Translate an error code to a message string. symlink : symlink(src, dst) -> None Create a symbolic link. system : system(command) -> exit_status Execute the command (a string) in a subshell. tcgetpgrp : tcgetpgrp(fd) -> pgid Return the process group associated with the terminal given by a fd. tcsetpgrp : tcsetpgrp(fd, pgid) -> None Set the process group associated with the terminal given by a fd. times : times() -> (utime, stime, cutime, cstime, elapsed_time) Return a tuple of floating point numbers indicating process times. umask : umask(new_mask) -> old_mask Set the current numeric umask and return the previous umask. uname : uname() -> (sysname, nodename, release, version, machine) Return a tuple identifying the current operating system. unlink : unlink(path) -> None Remove a file (same as remove(path)). utime : utime(path, (atime, utime)) -> None Set the access and modified time of the file to the given values. wait : wait() -> (pid, status) Wait for completion of a child process. waitpid : waitpid(pid, options) -> (pid, status) Wait for completion of a give child process. write : write(fd, string) -> byteswritten Write a string to a file descriptor. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 17 10:11:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 10:11:37 +0200 Subject: [Python-Dev] ascii default encoding References: <1248329948-59293691@hypernet.com> Message-ID: <3972BFB9.180C9502@lemburg.com> Gordon McMillan wrote: > > M.-A. Lemburg, > > > Thomas Wouters wrote: > > [deprecate / depreciate] > > > It seems that one is stronger than the other. I'll stick with the > > weaker one ;-) > > One is passive. Your new car depreciates in value, whether > Guido says it should or not. Ok ok... :-) I'll remove the "i" from "depreciated" and will instead try to add the "n" to "unkown" -- promised ;-) > > > > > Besides, 'string.join' is a good compromise for the people > > > > > who don't like " ".join() > > > Fine... but it'll cause a performance hit when used in tight > > loops (function call + method lookup). They should use somehting > > like: > > > > spacejoin = ' '.join > > spacejoin(sequence) > > > > instead. > > It's become very obvious that you haven't read c.l.py in quite > awhile. That's true -- don't have time for that anymore. I usually only scan the newsgroup for articles related to my mx stuff and database/datetime related things. For me, python-dev has become the new home. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Mon Jul 17 10:18:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 10:18:05 +0200 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> Message-ID: <007501bfefc7$8aff9800$f2a6b5d4@hagrid> mal wrote: > It needs to be modified a bit to work with SRE since it > uses the old regs array (the tool was written for regex > which had this array, then ported to re, which also had the > array, but didn't document it; SRE doesn't have it anymore... > sigh). the next SRE checkin has it... coming later today, assuming that I can find the new little bug I just introduced... while you're waiting, feel free to use "pre" instead. From mal at lemburg.com Mon Jul 17 10:15:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 10:15:50 +0200 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> <007501bfefc7$8aff9800$f2a6b5d4@hagrid> Message-ID: <3972C0B6.2C80DF9C@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > It needs to be modified a bit to work with SRE since it > > uses the old regs array (the tool was written for regex > > which had this array, then ported to re, which also had the > > array, but didn't document it; SRE doesn't have it anymore... > > sigh). > > the next SRE checkin has it... coming later today, assuming > that I can find the new little bug I just introduced... Cool :-) > while you're waiting, feel free to use "pre" instead. Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 17 10:26:54 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 10:26:54 +0200 Subject: [Python-Dev] binary incompatibility and tp_flags (was: Linker problems on Linux) References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> Message-ID: <3972C34E.A470B748@lemburg.com> Greg Stein wrote: > > On Sun, Jul 16, 2000 at 11:25:53PM +0200, Thomas Wouters wrote: > > On Sun, Jul 16, 2000 at 10:57:47PM +0200, Martin v. Loewis wrote: > > > > > For example, if you have a 1.5.2-compiled type in an extension module, > > > and that type happens to implement PySequenceMethods, then applying 'a > > > in b' will likely crash: Python 2 will check for the sq_contains > > > field, but that is past the end of the function table in the old > > > module. > > > > Nope. This is specifically fixed by the new tp_flags structmember (which was > > 'unused' before, so reading *that* will work ok) and the PyType_HasFeature > > macro. All code that wants to access one of the really new struct members > > (currently, bf_getcharbuffer, sq_contains and the cycle-gc stuff. And my > > augmented assignment patch adds another 13 ;) should check tp_flags first. > > > > See the comment in Include/object.h regarding this. > > Actually, those flags should only be used if you are attempting to maintain > binary compatibility. > > At the point where you say "okay. binary compatibility is hereby broken.", > then we go and remove the flags for the new structure members. I can't remember anyone saying something in that direction. > The last API bump was to 1009 for "Unicode API added". I'm not sure why > Guido bumped it since the *addition* of an API shouldn't create binary > incompatibility. He bumped it so that extensions can switch on the API number and then decide whether to use the new API or not... there are extensions out there which want to be compatible to 1.5.2 *and* 2.0. E.g. my mx stuff has a special portability file (mxpyapi.h) which is meant to achieve exactly this... > Regardless, I think we have introduced several semantic incompatibilities or > even signature changes in the APIs. We should do a bump for safety's sake > and we should toss the two Py_TPFLAGS_HAVE_* macros (and the corresponding > tests within the core interpreter). I can only speak for my mx stuff, but that still works greats with the 2.0 API -- except for the missing PyObject_Length() API, but that'll go back in as soon as Thomas has modified his patch on SF. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Mon Jul 17 10:40:33 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 10:40:33 +0200 Subject: [Python-Dev] binary incompatibility and tp_flags (was: Linker problems on Linux) In-Reply-To: <3972C34E.A470B748@lemburg.com>; from mal@lemburg.com on Mon, Jul 17, 2000 at 10:26:54AM +0200 References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> <3972C34E.A470B748@lemburg.com> Message-ID: <20000717104033.F7340@xs4all.nl> On Mon, Jul 17, 2000 at 10:26:54AM +0200, M.-A. Lemburg wrote: > I can only speak for my mx stuff, but that still works greats > with the 2.0 API -- except for the missing PyObject_Length() > API, but that'll go back in as soon as Thomas has modified > his patch on SF. I already did that ;) About 5 minutes after you added the comment about it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein at lyra.org Mon Jul 17 11:05:32 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:05:32 -0700 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) In-Reply-To: <3972BBD6.A81B2577@lemburg.com>; from mal@lemburg.com on Mon, Jul 17, 2000 at 09:55:02AM +0200 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> Message-ID: <20000717020531.X29590@lyra.org> On Mon, Jul 17, 2000 at 09:55:02AM +0200, M.-A. Lemburg wrote: > Greg Stein wrote: >... > > Nope. It *does* work. Note the "else" on the end there. That creates the > > proper binding. > > Greg, I did see the "else", but that does two things: it breaks > the code if there's no semicolon after the UT8F_ERROR() macro The current *and* the previous macro would break if there was no semicolon. No difference here. > and it produces warnings which relate to the fact that the "else" > part is ambiguous: > > if (condition) UTF8_ERROR(); > else {...} > > expands to: > > if (condition) > if (1) {...} > else ; > else {...} That is not ambiguous. > And gcc doesn't like it: > > unicodeobject.c: In function `PyUnicode_FromEncodedObject': > unicodeobject.c:424: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:429: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c: In function `PyUnicode_DecodeUTF8': > unicodeobject.c:673: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:687: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:698: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:710: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c:716: warning: suggest explicit braces to avoid ambiguous `else' > unicodeobject.c: In function `PyUnicode_EncodeUTF8': > unicodeobject.c:829: warning: suggest parentheses around arithmetic in operand of | > unicodeobject.c: At top level: > unicodeobject.c:755: warning: `utf8_encoding_error' defined but not used Agreed. It produces warnings. gcc is being stupid here because there is no ambiguity. It is saying "well, gee golly, you might have a problem" but we really don't. gcc is trying to be too smart. But hey... if it wants to produce warnings... then fine. We can work around the dumb thing. > > All uses of the UTF8_ERROR() macro have a semicolon after them (like any > > normal statement does(!)). This expands the macro to: > > > > if (1) { > > ... > > } else > > ; /* this is the semicolon I referred to */ > > > > Therefore, it creates a complete if/else statement, and any surrounding > > if/else statements will bind as expected. > > The goto solution is much cleaner and also easier to understand. Arguable. > Please revert the change you made (or I will ;-). I will, but only to shut gcc up. It is flat out wrong. -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 17 11:16:56 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:16:56 -0700 Subject: [Python-Dev] Checked in... In-Reply-To: <3972410B.4847D37B@prescod.net>; from paul@prescod.net on Sun, Jul 16, 2000 at 06:11:07PM -0500 References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <20000716154138.U29590@lyra.org> <200007162353.SAA06185@cj20424-a.reston1.va.home.com> <3972410B.4847D37B@prescod.net> Message-ID: <20000717021656.Z29590@lyra.org> On Sun, Jul 16, 2000 at 06:11:07PM -0500, Paul Prescod wrote: > Okay, everybody seems to like the nondist idea, should it be > > nondist/src/onlinehelp.py > # simple > nondist/src/help/onlinehelp.py > # its own directory -- in case it splits into two modules > nondist/src/Lib/onlinehelp.py > # code proposed for standard library There isn't any need for organization. The area is not going to be heavily trafficked. If somebody comes along with something "big", then they can place it into a subdir. Even then, it could be questionable. The audience for this stuff is python-dev. nondist/src/ is still a bit official. As I mentioned in my note, /nondist/sandbox/ is a good candidate -- it is very clear that we are talking about stuff that is just messing around. Therefore, I'd suggest /nondist/sandbox/onlinehelp.py Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Mon Jul 17 11:15:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 11:15:53 +0200 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> Message-ID: <3972CEC9.1842AD7F@lemburg.com> Greg Stein wrote: > > > The goto solution is much cleaner and also easier to understand. > > Arguable. > > > Please revert the change you made (or I will ;-). > > I will, but only to shut gcc up. It is flat out wrong. Thank you :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Mon Jul 17 11:17:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 11:17:41 +0200 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) In-Reply-To: <20000717020531.X29590@lyra.org>; from gstein@lyra.org on Mon, Jul 17, 2000 at 02:05:32AM -0700 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> Message-ID: <20000717111741.H7340@xs4all.nl> On Mon, Jul 17, 2000 at 02:05:32AM -0700, Greg Stein wrote: > On Mon, Jul 17, 2000 at 09:55:02AM +0200, M.-A. Lemburg wrote: > > and it produces warnings which relate to the fact that the "else" > > part is ambiguous: > > > > if (condition) UTF8_ERROR(); > > else {...} > > > > expands to: > > > > if (condition) > > if (1) {...} > > else ; > > else {...} > > That is not ambiguous. Nope. The example was flawed. *this* is ambiguous: if (condition) UTF8_ERROR(); And that's exactly what gcc is whining about: if (s + n > e) UTF8_ERROR("unexpected end of data"); It's very clearly defined what happens, here, but gcc can't see the macro as is, and mis-placing 'else's is a very common error. Especially combined with macros :) In absense of a standard-defined error-reporting tool, gcc -Wall does a very good job. And don't start about lint, the versions of lint I've seen were much more picky ;) > > The goto solution is much cleaner and also easier to understand. > Arguable. Even more arguable is the coding style issue ;) I haven't seen this 'if (1) {} else' trick used in macros elsewhere, not in Python and not in other code. Granted, those pieces of code didn't need to call continue, but I personally prefer the goto over the weird macro. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Mon Jul 17 11:23:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 11:23:26 +0200 Subject: [Python-Dev] binary incompatibility and tp_flags (was: Linker problems on Linux) References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> <3972C34E.A470B748@lemburg.com> <20000717104033.F7340@xs4all.nl> Message-ID: <3972D08E.B2F38679@lemburg.com> Thomas Wouters wrote: > > On Mon, Jul 17, 2000 at 10:26:54AM +0200, M.-A. Lemburg wrote: > > > I can only speak for my mx stuff, but that still works greats > > with the 2.0 API -- except for the missing PyObject_Length() > > API, but that'll go back in as soon as Thomas has modified > > his patch on SF. > > I already did that ;) About 5 minutes after you added the comment about it. Checked in. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Mon Jul 17 11:30:02 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:30:02 -0700 Subject: [Python-Dev] binary incompatibility and tp_flags In-Reply-To: <3972C34E.A470B748@lemburg.com>; from mal@lemburg.com on Mon, Jul 17, 2000 at 10:26:54AM +0200 References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> <3972C34E.A470B748@lemburg.com> Message-ID: <20000717023002.C29590@lyra.org> On Mon, Jul 17, 2000 at 10:26:54AM +0200, M.-A. Lemburg wrote: > Greg Stein wrote: >... > > Actually, those flags should only be used if you are attempting to maintain > > binary compatibility. > > > > At the point where you say "okay. binary compatibility is hereby broken.", > > then we go and remove the flags for the new structure members. > > I can't remember anyone saying something in that direction. Never said anyone did :-) ... just said, "*when* it happens, then we have some stuff that we can clean out." > > The last API bump was to 1009 for "Unicode API added". I'm not sure why > > Guido bumped it since the *addition* of an API shouldn't create binary > > incompatibility. > > He bumped it so that extensions can switch on the API number > and then decide whether to use the new API or not... there are > extensions out there which want to be compatible to 1.5.2 *and* > 2.0. E.g. my mx stuff has a special portability file (mxpyapi.h) > which is meant to achieve exactly this... Hrm. This is a bit weird then. Modules will produce errors when they really don't need to. I understand that it would be handy to say "hey, does the Unicode stuff exist", but that same mechanism is going to produce errors at module-init time when stuff is loaded. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jul 17 11:39:50 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:39:50 -0700 Subject: [Python-Dev] if/else and macros In-Reply-To: <20000717111741.H7340@xs4all.nl>; from thomas@xs4all.net on Mon, Jul 17, 2000 at 11:17:41AM +0200 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> Message-ID: <20000717023950.E29590@lyra.org> On Mon, Jul 17, 2000 at 11:17:41AM +0200, Thomas Wouters wrote: > On Mon, Jul 17, 2000 at 02:05:32AM -0700, Greg Stein wrote: > > On Mon, Jul 17, 2000 at 09:55:02AM +0200, M.-A. Lemburg wrote: > > > > and it produces warnings which relate to the fact that the "else" > > > part is ambiguous: > > > > > > if (condition) UTF8_ERROR(); > > > else {...} > > > > > > expands to: > > > > > > if (condition) > > > if (1) {...} > > > else ; > > > else {...} > > > > That is not ambiguous. > > Nope. The example was flawed. *this* is ambiguous: > > if (condition) UTF8_ERROR(); > > And that's exactly what gcc is whining about: > > if (s + n > e) > UTF8_ERROR("unexpected end of data"); Oh come on. This is getting silly. Neither of those examples are ambiguous. C has a very strict definition of what happens. In your examples, it expands to: if (condition) if (1) { ... } else ; GCC spits out a warning to tell the person "oh hey... I'm associating that else with the second 'if' command... but I'm going to spit out a warning just in case that isn't want you really meant." There is no ambiguity. Zero. I repeat: none. GCC is simply *assuming* that you may have messed up, so it spits out a warning. But ambiguity? Not at all. Cheers, -g -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Mon Jul 17 11:45:18 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 11:45:18 +0200 Subject: [Python-Dev] if/else and macros (was: CVS: python/dist/src/Objects unicodeobject.c,2.48,2.49) References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> Message-ID: <000d01bfefd3$b924d540$f2a6b5d4@hagrid> thomas wrote: > Even more arguable is the coding style issue ;) I haven't seen this 'if (1) > {} else' trick used in macros elsewhere, not in Python and not in other > code hey, it's saving a whopping ten lines of code, or so ;-) If I'd written that code, I'd spelled it out... and come to think of it, I *did* write the original version of that code! FYI, I don't like that macro. Instead of arguing about how it should look, just get rid of it. here's how the original code looked: if (ch < 0x80) goto bogus; /* illegal UTF-8 encoding */ ... bogus: PyErr_SetString( PyExc_ValueError, "invalid UTF-8 code" ); ... I would have implemented the changes like this: if (ch < 0x80) { detail = "illegal encoding"; goto bogus; } ... bogus: if (!utf8_decoding_error(&s, &p, errors, detail)) goto ignore; ... This solution gets rids of the macro mess, and what's more important, it moves exception handling out of the inner loop. (yes, it's using goto's, but it's a decoding loop, and it should be as fast as it possibly can -- especially if you're feeding it valid data!) The result is smaller source, smaller code, a smaller inner loop, faster decoding, and less discussion on this list. From gstein at lyra.org Mon Jul 17 11:57:56 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 02:57:56 -0700 Subject: [Python-Dev] if/else and macros In-Reply-To: <000d01bfefd3$b924d540$f2a6b5d4@hagrid>; from effbot@telia.com on Mon, Jul 17, 2000 at 11:45:18AM +0200 References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> Message-ID: <20000717025756.G29590@lyra.org> On Mon, Jul 17, 2000 at 11:45:18AM +0200, Fredrik Lundh wrote: >... > This solution gets rids of the macro mess, and what's more > important, it moves exception handling out of the inner loop. > > (yes, it's using goto's, but it's a decoding loop, and it should > be as fast as it possibly can -- especially if you're feeding it > valid data!) > > The result is smaller source, smaller code, a smaller inner loop, > faster decoding, and less discussion on this list. Can't just out of the loop. One of the possible results of the error is to ignore it and continue. Or to insert a particular character and continue. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Mon Jul 17 12:04:12 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 12:04:12 +0200 Subject: [Python-Dev] binary incompatibility and tp_flags References: <200007162057.WAA07075@loewis.home.cs.tu-berlin.de> <20000716232553.B7340@xs4all.nl> <20000716151750.R29590@lyra.org> <3972C34E.A470B748@lemburg.com> <20000717023002.C29590@lyra.org> Message-ID: <3972DA1C.E273F9C7@lemburg.com> Greg Stein wrote: > > On Mon, Jul 17, 2000 at 10:26:54AM +0200, M.-A. Lemburg wrote: > > Greg Stein wrote: > >... > > > Actually, those flags should only be used if you are attempting to maintain > > > binary compatibility. > > > > > > At the point where you say "okay. binary compatibility is hereby broken.", > > > then we go and remove the flags for the new structure members. > > > > I can't remember anyone saying something in that direction. > > Never said anyone did :-) ... just said, "*when* it happens, then we have > some stuff that we can clean out." Ah, ok :) > > > The last API bump was to 1009 for "Unicode API added". I'm not sure why > > > Guido bumped it since the *addition* of an API shouldn't create binary > > > incompatibility. > > > > He bumped it so that extensions can switch on the API number > > and then decide whether to use the new API or not... there are > > extensions out there which want to be compatible to 1.5.2 *and* > > 2.0. E.g. my mx stuff has a special portability file (mxpyapi.h) > > which is meant to achieve exactly this... > > Hrm. This is a bit weird then. Modules will produce errors when they really > don't need to. > > I understand that it would be handy to say "hey, does the Unicode stuff > exist", but that same mechanism is going to produce errors at module-init > time when stuff is loaded. The modules produce API warnings at startup, but they still continue to work like before and this is important since there are many people out there which are used to updating their software via RPM (or other packagers) and don't know how to compile source files. My comment about the API number bump was referring to using added functionality if available -- there could be #ifdef sections in the source files to enable/disable e.g. Unicode support. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Mon Jul 17 12:42:59 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 05:42:59 -0500 Subject: [Python-Dev] Checked in... References: Message-ID: <3972E333.363CD227@prescod.net> Ka-Ping Yee wrote: > >... > > My plan was to complete htmldoc.py and try to get in into the > distribution so that anyone could browse documentation on the > standard library. +1 > It would include an option to start a little > webserver with a one-line command so that doc pages could be > automatically generated on your own modules as you work on them. +0 > The next step in the plan was to provide text output so you > could ask about modules from the shell prompt (like a "man" > command specific to Python) and a function call you could use > from inside the interpreter to get quick help as well. Not sure how to interpret this. If it depends on the aforementioned web server, I'm -1. If it calls the htmldoc code directly, I'm +1. I'd love to have the interpreter build on your docstring-formatting heuristics and that docstring-language plugin feature we discussed to allow people to experiment with semi-structured docstring formats. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Mon Jul 17 13:17:00 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 06:17:00 -0500 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> Message-ID: <3972EB2C.66EAB279@prescod.net> "M.-A. Lemburg" wrote: > > ... > > You may want to have a look at my hack.py utility which already > provides a convenient way of printing the doc strings *and* > the published interface: > > http://starship.python.net/?lemburg/hack.py Yes, that's got some pretty nice ideas. I may get the same features from Ka-Ping's htmldoc so that we don't have two pieces of code doing the same thing. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From peter at schneider-kamp.de Mon Jul 17 15:36:35 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 17 Jul 2000 13:36:35 +0000 Subject: [Python-Dev] SourceForge down? Message-ID: <39730BE3.B1A83A59@schneider-kamp.de> Since yesterday evening I cannot get to the Python pages at SourceForge. That is sometimes I cannot even log in to SourceForge. Other times it just takes minutes to load a page. Do you experience something similar? Or is it just me? Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mal at lemburg.com Mon Jul 17 13:40:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 13:40:50 +0200 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> <3972EB2C.66EAB279@prescod.net> Message-ID: <3972F0C2.E0266A0C@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > You may want to have a look at my hack.py utility which already > > provides a convenient way of printing the doc strings *and* > > the published interface: > > > > http://starship.python.net/~lemburg/hack.py > > Yes, that's got some pretty nice ideas. I may get the same features from > Ka-Ping's htmldoc so that we don't have two pieces of code doing the > same thing. Do you have a pointer for it ? (I'm always interested in new tools which support auto-documentation.) Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Mon Jul 17 13:44:55 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 13:44:55 +0200 Subject: [Python-Dev] SourceForge down? In-Reply-To: <39730BE3.B1A83A59@schneider-kamp.de>; from peter@schneider-kamp.de on Mon, Jul 17, 2000 at 01:36:35PM +0000 References: <39730BE3.B1A83A59@schneider-kamp.de> Message-ID: <20000717134455.J7340@xs4all.nl> On Mon, Jul 17, 2000 at 01:36:35PM +0000, Peter Schneider-Kamp wrote: > Since yesterday evening I cannot get to the Python pages at > SourceForge. That is sometimes I cannot even log in to > SourceForge. Other times it just takes minutes to load > a page. I had similar problems yesterday during the day. I've reported it to staff at sourceforge.net, and they confirmed something looked messed up. Sometime during the (european) evening things started working properly again. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Mon Jul 17 13:46:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 13:46:26 +0200 Subject: [Python-Dev] SourceForge down? References: <39730BE3.B1A83A59@schneider-kamp.de> Message-ID: <3972F212.5E5A7E4B@lemburg.com> Peter Schneider-Kamp wrote: > > Since yesterday evening I cannot get to the Python pages at > SourceForge. That is sometimes I cannot even log in to > SourceForge. Other times it just takes minutes to load > a page. > > Do you experience something similar? Or is it just me? Works fine for me... you sometimes just have to wait a few minutes for the response :-( -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Mon Jul 17 13:52:14 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 06:52:14 -0500 Subject: [Python-Dev] Checked in... References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> <3972EB2C.66EAB279@prescod.net> <3972F0C2.E0266A0C@lemburg.com> Message-ID: <3972F36E.4A03E71B@prescod.net> "M.-A. Lemburg" wrote: > > > Do you have a pointer for it ? (I'm always interested in new > tools which support auto-documentation.) http://www.lfw.org/python/ -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From mal at lemburg.com Mon Jul 17 14:09:42 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 14:09:42 +0200 Subject: [Python-Dev] htmldoc.py + inspect.py References: <397218A2.A90BCAB3@prescod.net> <200007162310.SAA05749@cj20424-a.reston1.va.home.com> <003f01bfef74$c6bd4200$f2a6b5d4@hagrid> <200007162332.SAA06030@cj20424-a.reston1.va.home.com> <39723FF0.D6BFD9F1@prescod.net> <3972BE9A.3C09AC97@lemburg.com> <3972EB2C.66EAB279@prescod.net> <3972F0C2.E0266A0C@lemburg.com> <3972F36E.4A03E71B@prescod.net> Message-ID: <3972F786.42FA2BE1@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > > > Do you have a pointer for it ? (I'm always interested in new > > tools which support auto-documentation.) > > http://www.lfw.org/python/ The output looks cool given that none of the standard lib Python module doc-strings were explicitely written to be rendered by this tool. But what I particularly like is the inspect.py module. That would make a great addition to the standard lib ! Note to Ping: your files are missing a clear license notice. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From infoez at macauweb.com Mon Jul 17 15:30:16 2000 From: infoez at macauweb.com (Sin Hang Kin) Date: Mon, 17 Jul 2000 21:30:16 +0800 Subject: [Python-Dev] Will Python die? Message-ID: <003f01bfeff3$26ac9840$770da8c0@bbs> See subject. I am really worry, before putting more effort to it, can any body explain the current status of python 2? Unicode is a must for my work, without it, python is useless. So I need python 2, if 2.0 will die, I better switch beforehand. Sorry!!! but it is very important. Rgs, Kent Sin --------------------------------- kentsin.weblogs.com kentsin.imeme.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at beopen.com Mon Jul 17 15:44:53 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 17 Jul 2000 09:44:53 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory In-Reply-To: <200007171050.DAA28047@slayer.i.sourceforge.net> References: <200007171050.DAA28047@slayer.i.sourceforge.net> Message-ID: <14707.3541.488523.886708@bitdiddle.concentric.net> Paul, You created a nondist subdirectory in the nondist tree. I don't think this is what you intended. Jeremy From mal at lemburg.com Mon Jul 17 15:43:51 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 15:43:51 +0200 Subject: [Python-Dev] Will Python die? References: <003f01bfeff3$26ac9840$770da8c0@bbs> Message-ID: <39730D97.323ADC08@lemburg.com> > Sin Hang Kin wrote: > > See subject. > I am really worry, before putting more effort to it, can any body explain the current status of python 2? In short: no way ;-) For the long story read on here: http://www.pythonlabs.com/tech/python2.html http://www.pythonlabs.com/tech/ http://www.pythonlabs.com/plans.html > Unicode is a must for my work, without it, python is useless. So I need python 2, if 2.0 will die, I better switch beforehand. Python2 has native Unicode support -- probably one of the most advanced there currently is among scripting languages. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Mon Jul 17 15:50:48 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 15:50:48 +0200 Subject: [Python-Dev] Will Python die? In-Reply-To: <003f01bfeff3$26ac9840$770da8c0@bbs>; from infoez@macauweb.com on Mon, Jul 17, 2000 at 09:30:16PM +0800 References: <003f01bfeff3$26ac9840$770da8c0@bbs> Message-ID: <20000717155048.K7340@xs4all.nl> On Mon, Jul 17, 2000 at 09:30:16PM +0800, Sin Hang Kin wrote: > I am really worry, before putting more effort to it, can any body explain > the current status of python 2? > Unicode is a must for my work, without it, python is useless. So I need > python 2, if 2.0 will die, I better switch beforehand. > Sorry!!! but it is very important. You betcha it's important ! What do those five people at PythonLabs do when Python dies ? They'd be out of a job ! Can't have that, now can we ;) Seriously, though: Python is not dead. Python 2 is not dead. CNRI and BeOpen are trying to resolve some 'issues', and the last news is that CNRI is going to release Python 1.6. I assume it'll be based off the 1.6 alphas, and those included unicode. BeOpen / PythonLabs will probably start by releasing Python 2.0. This'll likely have to wait until 1.6 is released, but the python dev team is working hard to make 2.0 a complete release on its own. It will include unicode, probably with less bugs and problems than 1.6 ;-) It will also include a ton of other things, which are being worked on right now. (Some of the things that might be included in 2.0 are list comprehensions (a way to replace map, filter and reduce), augmented assignment (x += y and such), online help() facility for the interpreter, possibly some new library modules, and many enhancements to the current standard library.) However, because of the issues between CNRI and BeOpen, it's completely unclear when Python 2.0 will be released. (Or, indeed, when CNRI's Python 1.6 will be released.) If you need the unicode support now, I'd suggest grabbing the CVS tree and see how it suits your needs. If it doesn't, give people here some feedback, so they can fix the problems or suggest ways to work around it. There are likely to be some changes to unicode (the functionality of '\x' and '\u' for instance) but the code is pretty solid as it is. Hope that helps ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Mon Jul 17 16:13:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 17 Jul 2000 10:13:52 -0400 Subject: [Python-Dev] SourceForge down? In-Reply-To: <39730BE3.B1A83A59@schneider-kamp.de> Message-ID: [Peter Schneider-Kamp] > Since yesterday evening I cannot get to the Python pages at > SourceForge. That is sometimes I cannot even log in to > SourceForge. Other times it just takes minutes to load > a page. > > Do you experience something similar? Or is it just me? Was true for me too all day, via the web interface. cmdline CVS worked fine, though. Couldn't get at patches. Off to CA for a week! If anyone wants to make progress on the patches assigned to me, be my guest ; from tim_one@email.msn.com on Mon, Jul 17, 2000 at 10:13:52AM -0400 References: <39730BE3.B1A83A59@schneider-kamp.de> Message-ID: <20000717163829.L7340@xs4all.nl> On Mon, Jul 17, 2000 at 10:13:52AM -0400, Tim Peters wrote: > Off to CA for a week! If anyone wants to make progress on the patches > assigned to me, be my guest myself (at least temporarily) off them!). I would take you off the patches, but I doubt anyone else would pick them up anyway ;) Some need an executive decision, I think, like the EXTENDED_ARG patch (which isn't assigned to you, yet) and the array.pop/count/etc patch. Some just need some discussion, and there isn't likely to be a lot of decision-making-discussion while almost all of PythonLabs and undoubtly the most of python-dev are at OSCON. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From peter at schneider-kamp.de Mon Jul 17 18:59:25 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 17 Jul 2000 16:59:25 +0000 Subject: [Python-Dev] SourceForge down? References: <39730BE3.B1A83A59@schneider-kamp.de> <20000717163829.L7340@xs4all.nl> Message-ID: <39733B6D.E4B83607@schneider-kamp.de> Thomas Wouters wrote: > > I would take you off the patches, but I doubt anyone else would pick them up > anyway ;) Some need an executive decision, I think, like the EXTENDED_ARG > patch (which isn't assigned to you, yet) and the array.pop/count/etc patch. And the {l,r}just with pad character patch (which isn't assigned to Tim either). > Some just need some discussion, and there isn't likely to be a lot of > decision-making-discussion while almost all of PythonLabs and undoubtly the > most of python-dev are at OSCON. Not if we want to keep our heads <0.99 wink>. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul at prescod.net Mon Jul 17 17:56:51 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 10:56:51 -0500 Subject: [Python-Dev] Will Python die? References: <003f01bfeff3$26ac9840$770da8c0@bbs> Message-ID: <39732CC3.4E1620C5@prescod.net> Python cannot die while its license permits anyone to improve it and there are still thousands of users. If Python were in any danger, there are dozens of people who could take over its advancement, including its current maintainer, Guido, at his new job! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Mon Jul 17 18:17:55 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 11:17:55 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> Message-ID: <397331B3.E12E9F31@prescod.net> Jeremy Hylton wrote: > > Paul, > > You created a nondist subdirectory in the nondist tree. I don't think > this is what you intended. Yeah, I know. Working in the middle of the night. I tried to remove it immediately but obviously didn't succeed. If its still there, maybe someone can enlighten me on how to dump it. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Mon Jul 17 18:44:01 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 18:44:01 +0200 Subject: [Python-Dev] if/else and macros References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> <20000717025756.G29590@lyra.org> Message-ID: <009501bff00e$3d3bc980$f2a6b5d4@hagrid> greg wrote: > > The result is smaller source, smaller code, a smaller inner loop, > > faster decoding, and less discussion on this list. > > Can't just out of the loop. One of the possible results of the error is to > ignore it and continue. Or to insert a particular character and continue. of course -- if you decide not to break the loop, just jump back in. I just fixed the UTF8 decoder: before: source: 5108 lines object size: 173,151 bytes after: source: 5106 lines object size: 171,630 bytes just give me four more months ;-) From ping at lfw.org Mon Jul 17 18:48:50 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 17 Jul 2000 09:48:50 -0700 (PDT) Subject: [Python-Dev] htmldoc.py + inspect.py In-Reply-To: <3972F786.42FA2BE1@lemburg.com> Message-ID: On Mon, 17 Jul 2000, M.-A. Lemburg wrote: > > But what I particularly like is the inspect.py module. That > would make a great addition to the standard lib ! Yes, i consider inspect.py pretty much done, and hoped it would be considered for the standard library. I proposed it a little while ago (http://www.python.org/pipermail/python-dev/2000-May/011031.html); but it was set aside during the feature freeze. If we are in a position to consider it again now, then yes, i'd like to suggest it for the standard library. > Note to Ping: your files are missing a clear license notice. I thought we didn't have to add the contribution release form anymore because that was for CNRI? Anyway, i added a comment. Is it sufficient? # I, Ka-Ping Yee, the author of this contribution, hereby grant to anyone and # everyone a nonexclusive, irrevocable, royalty-free, worldwide license to # reproduce, distribute, perform and/or display publicly, prepare derivative # versions, and otherwise use this contribution as part of the Python software # and its related documentation, or any derivative versions thereof, at no cost # to anyone, and to authorize others to do so. -- ?!ng From bwarsaw at beopen.com Mon Jul 17 19:16:22 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 13:16:22 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> Message-ID: <14707.16230.872435.656875@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Yeah, I know. Working in the middle of the night. I tried to PP> remove it immediately but obviously didn't succeed. If its PP> still there, maybe someone can enlighten me on how to dump it. You can't. Somebody with access to the repository will have to remove it, but even then, if someone else has already done and update and gotten the new dir, it'll mess up their working directories. Best to just leave it empty and let "cvs up -P" prune it out. -Barry From ping at lfw.org Mon Jul 17 19:31:21 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 17 Jul 2000 10:31:21 -0700 (PDT) Subject: [Python-Dev] Checked in... In-Reply-To: <3972E333.363CD227@prescod.net> Message-ID: On Mon, 17 Jul 2000, Paul Prescod wrote: > Ka-Ping Yee wrote: > > My plan was to complete htmldoc.py and try to get in into the > > distribution so that anyone could browse documentation on the > > standard library. > > +1 Yay. :) > > It would include an option to start a little > > webserver with a one-line command so that doc pages could be > > automatically generated on your own modules as you work on them. > > +0 I'd like Python to come packaged in such a way that people can easily deploy it in an organization along with whatever stuff they develop. So being able to very easily generate and see docs on their own modules, integrated with the view of docs for the rest of the standard library, would be a nice thing. It makes a Python environment easier to support. > > The next step in the plan was to provide text output so you > > could ask about modules from the shell prompt (like a "man" > > command specific to Python) and a function call you could use > > from inside the interpreter to get quick help as well. > > Not sure how to interpret this. If it depends on the aforementioned web > server, I'm -1. If it calls the htmldoc code directly, I'm +1. Did you mean you wanted it to generate HTML and then use htmllib, like you did, to turn it into text? I hadn't thought of that. The way i imagined it, it wouldn't depend on htmldoc or the web server at all. It would call inspect.py to get its info and just format some text on its own. Before you posted onlineHelp (great work, by the way!), i was thinking of calling it "pydoc", and envisioning something like: >>> import pydoc # or have site.py take care of this >>> pydoc.doc(urllib) ---- module urllib: Open an arbitrary URL. See the following document for more info on URLs: "Names and Addresses, URIs, URLs, URNs, URCs", at http://www.w3.org/pub/WWW/Addressing/Overview.html . . . ---- functions: urlopen(url, data=None) urlretrieve(url, filename=None, reporthook=Nne) . . . ---- classes: class URLopener: Class to open URLs. . . . etc. and also the same output from the shell command % pydoc urllib ---- module urllib: Open an arbitrary URL. See the following document for more info on URLs: "Names and Addresses, URIs, URLs, URNs, URCs", at http://www.w3.org/pub/WWW/Addressing/Overview.html . . . etc. This is basically identical to how you were describing the onlinehelp/help commands. I didn't think of using the external (TeX/HTML) documentation though... that's a clever idea. So: - use doc pages only? - use internal info only? - separate scripts for each? - use both? - use doc pages if installed, then fall back to internal info? One other note: how about leaving the job of listing the text to to an external app like "less"/"more", as determined by the PAGER environment variable, allowing customization? The code we use to figure out what program to run should eventually move into launch.textviewer. Perhaps this would then provide interactive apps (e.g. IDLE) the opportunity to simply replace (or hook into) launch.textviewer. > I'd love > to have the interpreter build on your docstring-formatting heuristics > and that docstring-language plugin feature we discussed to allow people > to experiment with semi-structured docstring formats. Sure. Not a high priority for me, but once we have the module, it's easy to extend and experiment. -- ?!ng From peter at schneider-kamp.de Mon Jul 17 21:45:44 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 17 Jul 2000 19:45:44 +0000 Subject: [Python-Dev] Will Python die? References: <003f01bfeff3$26ac9840$770da8c0@bbs> <39732CC3.4E1620C5@prescod.net> Message-ID: <39736268.306B8DF0@schneider-kamp.de> Paul Prescod wrote: > > Python cannot die while its license permits anyone to improve it and > there are still thousands of users. If Python were in any danger, there > are dozens of people who could take over its advancement, including its > current maintainer, Guido, at his new job! Tim once (0.9-winking-ly) mentioned the possibility of voting with the "keyboard by grabbing the Python source and making your own release". I don't wanna do this on my own (and get zapped from a lightning bolt thrown by the powers that are), but what would be the pros and cons of an inofficial (maybe 1.8?) alpha-in-between-release? I think the CVS tree is in a relative stable state, so if this is going to take another 1 1/2 months, this might be a good time. just-thinking-and-winking-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mal at lemburg.com Mon Jul 17 19:46:01 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 19:46:01 +0200 Subject: [Python-Dev] htmldoc.py + inspect.py References: Message-ID: <39734659.16D327D9@lemburg.com> Ka-Ping Yee wrote: > > On Mon, 17 Jul 2000, M.-A. Lemburg wrote: > > > > But what I particularly like is the inspect.py module. That > > would make a great addition to the standard lib ! > > Yes, i consider inspect.py pretty much done, and hoped it would be > considered for the standard library. I proposed it a little while ago > (http://www.python.org/pipermail/python-dev/2000-May/011031.html); > but it was set aside during the feature freeze. > > If we are in a position to consider it again now, then yes, i'd like > to suggest it for the standard library. Don't know if we are in such a position, but it's worth putting on the list of candidates. Perhaps you should simply put up a patch to SF which includes the module -- this will give it some more exposure and assure that the idea is not lost. > > Note to Ping: your files are missing a clear license notice. > > I thought we didn't have to add the contribution release form > anymore because that was for CNRI? Sure, but there may be others who would like to use it, right ;-) As long as there's no license on a file, you bascially cannot legally copy it without first getting the authors permission. > Anyway, i added a comment. Is it sufficient? > > # I, Ka-Ping Yee, the author of this contribution, hereby grant to anyone and > # everyone a nonexclusive, irrevocable, royalty-free, worldwide license to > # reproduce, distribute, perform and/or display publicly, prepare derivative > # versions, and otherwise use this contribution as part of the Python software > # and its related documentation, or any derivative versions thereof, at no cost > # to anyone, and to authorize others to do so. This only gives the right to use the module in case it becomes part of the standard lib :-( I usually put the old Python license into the files (with changed names of course). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ping at lfw.org Mon Jul 17 20:01:58 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 17 Jul 2000 11:01:58 -0700 (PDT) Subject: [Python-Dev] htmldoc.py + inspect.py In-Reply-To: <39734659.16D327D9@lemburg.com> Message-ID: On Mon, 17 Jul 2000, M.-A. Lemburg wrote: > This only gives the right to use the module in case it becomes > part of the standard lib :-( Fixed. # I, Ka-Ping Yee, the author of this contribution, hereby grant to anyone and # everyone a nonexclusive, irrevocable, royalty-free, worldwide license to # reproduce, distribute, perform and/or display publicly, prepare derivative # versions, and otherwise use this contribution in any fashion, or any # derivative versions thereof, at no cost to anyone, and to authorize others # to do so. This software is provided "as is", with NO WARRANTY WHATSOEVER, # not even a warranty of merchantability or fitness for any particular purpose. Geez. Is that enough words yet? All i wanted to say was "go play". :) -- ?!ng From thomas at xs4all.net Mon Jul 17 20:01:16 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 20:01:16 +0200 Subject: [Python-Dev] 'shadowing' builtins Message-ID: <20000717200116.P7340@xs4all.nl> This is probably the wrong time, given that most of y'all are likely on their way to OSCON ;) But the perl-hugging hippy colleague of mine that is currently at OSCON gave (as in 'handed') me this idea on shadowing builtins. He decided to go to David Beazly's python introduction, and he was suprised at how you can do 'None = 4'. And when I explained it's harmless (because it's local, not global) he was suprised it didn't generate a warning. And, well, why doesn't it generate a warning ? Only with an, uhm, '-w' option or so, of course, or perhaps add it to the '-t' option. It would be also a compile-time-check. It might require a seperate lookup table (haven't looked at it at all, yet) that duplicates the 'builtin' namespace, but I'd think it's worth it. Or is this an old and already-shot-down idea ? :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Mon Jul 17 20:04:19 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 17 Jul 2000 20:04:19 +0200 Subject: [Python-Dev] if/else and macros References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> <20000717025756.G29590@lyra.org> <009501bff00e$3d3bc980$f2a6b5d4@hagrid> Message-ID: <39734AA3.7B33EE44@lemburg.com> Fredrik Lundh wrote: > > greg wrote: > > > The result is smaller source, smaller code, a smaller inner loop, > > > faster decoding, and less discussion on this list. > > > > Can't just out of the loop. One of the possible results of the error is to > > ignore it and continue. Or to insert a particular character and continue. > > of course -- if you decide not to break the loop, just > jump back in. This is getting silly, really ;-) Jumping out of loops is ok, but jumping back in is not: you can never know whether the optimizer rearranges the loop code, so jumping *into* loop constructs is not going to be portable. I'll remove the macro completely and also fix the UTF16 codec which has the same continue problem. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Mon Jul 17 20:04:22 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 13:04:22 -0500 Subject: [Python-Dev] Checked in... References: Message-ID: <39734AA5.C6ACA757@prescod.net> Ka-Ping Yee wrote: > > ... > > I'd like Python to come packaged in such a way that people can > easily deploy it in an organization along with whatever stuff > they develop. So being able to very easily generate and see docs > on their own modules, integrated with the view of docs for the > rest of the standard library, would be a nice thing. It makes a > Python environment easier to support. Agreed. I'm just not sure if it requires a webserver. You could set up a makefile to recognize when an HTML doc is out of sync with its Python. > The way i imagined it, it wouldn't depend on htmldoc or the web > server at all. It would call inspect.py to get its info and just > format some text on its own. I didn't know about the clean separation of htmldoc and inspect when I wrote that. You're right, it should call inspect directly. > This is basically identical to how you were describing the > onlinehelp/help commands. I didn't think of using the external > (TeX/HTML) documentation though... that's a clever idea. So: > > - use doc pages only? That's not doable unless there is a process to get docstrings into doc pages -- which is a great idea but probably some ways away. > - use internal info only? Where do I get information on statements and "topics" (like slicing, as a topic). > - separate scripts for each? Maybe internally. Ideally not at the user interface layer. > - use doc pages if installed, then fall back to internal info? My model, which you may or may not have noticed yet, is to use docstrings for objects that have docstrings, but the docstrings can point to HTML documentation in the circumstance where the canonical doc is maintained in HTML. In that case, I magically go to the HTML, rather than showing the reference. My personal feeling is that over time a lot of the library documentation should move inline for ease of maintenance and reduction of duplication. But that won't happen until we integrate inspect.py and latex2html. I have some ideas about that too. It's the opposite of the current scheme. We should put pointers from the LaTeX into the modules. A preprocessor would use inspect.py to generate a combined LaTeX that merges inline (LaTeX) and out-of-line (docstring) information. Then we start moving bits of the documentation into docstrings a little at a time. Anything that uses LaTeX features that are "funky" can stay in LaTeX until we invent a structured docstring syntax (whenever). > One other note: how about leaving the job of listing the text to > to an external app like "less"/"more", as determined by the PAGER > environment variable, allowing customization? The code we use to > figure out what program to run should eventually move into > launch.textviewer. I'm happy to do this on platforms that support it. I'm somewhat nervous about popen on non-Unix systems...maybe I should write a text file and then launch the pager on that. > Perhaps this would then provide interactive apps (e.g. IDLE) the > opportunity to simply replace (or hook into) launch.textviewer. Good idea. One tricky issue is what format to use, though. troff/man is great for Unix TTY, HTML is great for GUIs and raw text is the lowest common denominiator. Do I want to get into n*m translations? Maybe, maybe not. Or maybe HTML is the lowest common denominator and Unix TTY users should use lynx? -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Mon Jul 17 20:18:44 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 13:18:44 -0500 Subject: [Python-Dev] 'shadowing' builtins References: <20000717200116.P7340@xs4all.nl> Message-ID: <39734E04.C7D29873@prescod.net> Thomas Wouters wrote: > > ... > > He decided to go to David Beazly's python introduction, and he was suprised > at how you can do 'None = 4'. And when I explained it's harmless (because > it's local, not global) he was suprised it didn't generate a warning. And, > well, why doesn't it generate a warning ? Only with an, uhm, '-w' option or > so, of course, or perhaps add it to the '-t' option. It would be also a > compile-time-check. It might require a seperate lookup table (haven't looked > at it at all, yet) that duplicates the 'builtin' namespace, but I'd think > it's worth it. A few thoughts: * None, map and other such long-term, ancient built-ins should not be directly overridable. I don't think we need a warning mode. Just outlaw it. We can do this with a semantic check in the compiler. * Those with a good reason to shadow them would do it by assignment to the module's dict or __builtins__. The "feature" would still be there if you need it, but it would be syntactically distinct. Or maybe we need to disallow it entirely to allow optimizers to attack this important special case. * Python badly needs a warning infrastructure. If I had time, that would be my first PEP. I'd rather the former tightening up was not hostage to a warning infrastructure that nobody gets around to implementing, though. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Mon Jul 17 20:21:25 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 13:21:25 -0500 Subject: [Python-Dev] Will Python die? References: <003f01bfeff3$26ac9840$770da8c0@bbs> <39732CC3.4E1620C5@prescod.net> <39736268.306B8DF0@schneider-kamp.de> Message-ID: <39734EA5.BBF96453@prescod.net> Peter Schneider-Kamp wrote: > > ... > > Tim once (0.9-winking-ly) mentioned the possibility of voting with the > "keyboard by grabbing the Python source and making your own release". As long as Tim and Guido are thinking about this possibility, I don't want to waste my brain cells considering it. I don't have as much information as they do and I'm only a little bit smarter than them anyhow. :) Seriously, I don't know enough about the licensing issues. I don't know exactly what CNRI "owns" and what we need from them to proceed. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Mon Jul 17 20:23:34 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 13:23:34 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> Message-ID: <39734F26.5799F13D@prescod.net> "Barry A. Warsaw" wrote: > > ... > > You can't. Gah. That sucks. > Somebody with access to the repository will have to remove > it, You mean an SF employee? > but even then, if someone else has already done and update and > gotten the new dir, it'll mess up their working directories. Best to > just leave it empty and let "cvs up -P" prune it out. Not in the long run. It's just messy. There's a mistake I won't make again (this week). -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From effbot at telia.com Mon Jul 17 20:44:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 20:44:25 +0200 Subject: [Python-Dev] if/else and macros References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> <20000717025756.G29590@lyra.org> <009501bff00e$3d3bc980$f2a6b5d4@hagrid> <39734AA3.7B33EE44@lemburg.com> Message-ID: <003101bff01f$193c5520$f2a6b5d4@hagrid> mal wrote: > This is getting silly, really ;-) indeed. > Jumping out of loops is ok, but jumping back in is not: you can > never know whether the optimizer rearranges the loop code, so > jumping *into* loop constructs is not going to be portable. sorry, but that's bullshit. if the optimizer cannot figure out where basic blocks start and end, it's broken beyond repair. quoting the ANSI C rationale: "The Committee considered proposals for forbidding a goto into a block from outside, since such a restriction would make possible much easier flow optimization and would avoid the whole issue of initializing auto storage (see ?3.1.2.4). The Committee rejected such a ban out of fear of invalidating working code (however un- disciplined) and out of concern for those producing machine- generated C." From bwarsaw at beopen.com Mon Jul 17 20:54:11 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 14:54:11 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> Message-ID: <14707.22099.762232.325117@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: >> You can't. PP> Gah. That sucks. Welcome to CVS. What did Greg Wilson say at IPC8? Paraphrasing: CVS is the worst tool everybody uses. :) >> Somebody with access to the repository will have to remove it, PP> You mean an SF employee? Yup, you need to make an admin request to do anything with the repository, like remove directories, move files, or clear locks. >> but even then, if someone else has already done and update and >> gotten the new dir, it'll mess up their working directories. >> Best to just leave it empty and let "cvs up -P" prune it out. PP> Not in the long run. It's just messy. PP> There's a mistake I won't make again (this week). Been there, done that. :) -Barry From bwarsaw at beopen.com Mon Jul 17 21:06:13 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 15:06:13 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration Message-ID: <14707.22821.945571.314619@anthem.concentric.net> I've made a final pass through PEP 201, Parallel Iteration. For those of you without easy access to the CVS tree, I'm including it below. You can also access it through the web at http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/python/nondist/peps/pep-0201.txt?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=python High bit: Guido strongly prefers zip() as the name of the built-in. All the suggestions so far have pluses and minuses, and in the absence of a clear winner, he'd just as soon go with the Haskell name. I agree. Please see the new reference implementation, which includes a __len__() method, and the discussion of the rejected elaborations. There's still the open issue of what zip(sequence_a) should return. I'd like to reach closure on this sometime soon after the guys get back from California. -Barry -------------------- snip snip -------------------- PEP: 201 Title: Parallel Iteration Version: $Revision: 1.2 $ Owner: bwarsaw at beopen.com (Barry A. Warsaw) Python-Version: 2.0 Status: Draft Introduction This PEP describes the `parallel iteration' proposal for Python 2.0, previously known as `parallel for loops'. This PEP tracks the status and ownership of this feature, slated for introduction in Python 2.0. It contains a description of the feature and outlines changes necessary to support the feature. This PEP summarizes discussions held in mailing list forums, and provides URLs for further information, where appropriate. The CVS revision history of this file contains the definitive historical record. Standard For-Loops Motivation for this feature has its roots in a concept described as `parallel for loops'. A standard for-loop in Python iterates over every element in the sequence until the sequence is exhausted. A `break' statement inside the loop suite causes an explicit loop exit. For-loops also have else: clauses which get executed when the loop exits normally (i.e. not by execution of a break). For-loops can iterate over built-in types such as lists and tuples, but they can also iterate over instance types that conform to an informal sequence protocol. This protocol states that the instance should implement the __getitem__() method, expecting a monotonically increasing index starting at 0, and this method should raise an IndexError when the sequence is exhausted. This protocol is currently undocumented -- a defect in Python's documentation hopefully soon corrected. For-loops are described in the Python language reference manual[1]. An example for-loop: >>> for i in (1, 2, 3): print i ... 1 2 3 In this example, the variable `i' is called the `target', and is assigned the next element of the list, each time through the loop. Parallel For-Loops Parallel for-loops are non-nested iterations over two or more sequences, such that at each pass through the loop, one element from each sequence is taken to compose the target. This behavior can already be accomplished in Python through the use of the map() built-in function: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> for i in map(None, a, b): print i ... (1, 4) (2, 5) (3, 6) Here, map() returns a list of N-tuples, where N is the number of sequences in map()'s argument list (after the initial `None'). Each tuple is constructed of the i-th elements from each of the argument lists, specifically in this example: >>> map(None, a, b) [(1, 4), (2, 5), (3, 6)] The for-loop simply iterates over this list as normal. While the map() idiom is a common one in Python, it has several disadvantages: - It is non-obvious to programmers without a functional programming background. - The use of the magic `None' first argument is non-obvious. - It has arbitrary, often unintended, and inflexible semantics when the lists are not of the same length: the shorter sequences are padded with `None'. >>> c = (4, 5, 6, 7) >>> map(None, a, c) [(1, 4), (2, 5), (3, 6), (None, 7)] For these reasons, several proposals were floated in the Python 2.0 beta time frame for providing a better spelling of parallel for-loops. The initial proposals centered around syntactic changes to the for statement, but conflicts and problems with the syntax were unresolvable, especially when parallel for-loops were combined with another proposed feature called `list comprehensions' (see pep-0202.txt). The Proposed Solution The proposed solution is to introduce a new built-in sequence generator function, available in the __builtin__ module. This function is to be called `zip' and has the following signature: zip(seqa, [seqb, [...]], [pad=]) zip() takes one or more sequences and weaves their elements together, just as map(None, ...) does with sequences of equal length. The optional keyword argument `pad', if supplied, is a value used to pad all shorter sequences to the length of the longest sequence. If `pad' is omitted, then weaving stops when the shortest sequence is exhausted. It is not possible to pad short lists with different pad values, nor will zip() ever raise an exception with lists of different lengths. To accomplish either behavior, the sequences must be checked and processed before the call to zip(). Lazy Execution For performance purposes, zip() does not construct the list of tuples immediately. Instead it instantiates an object that implements a __getitem__() method and conforms to the informal for-loop protocol. This method constructs the individual tuples on demand. Examples Here are some examples, based on the reference implementation below. >>> a = (1, 2, 3, 4) >>> b = (5, 6, 7, 8) >>> c = (9, 10, 11) >>> d = (12, 13) >>> zip(a, b) [(1, 5), (2, 6), (3, 7), (4, 8)] >>> zip(a, d) [(1, 12), (2, 13)] >>> zip(a, d, pad=0) [(1, 12), (2, 13), (3, 0), (4, 0)] >>> zip(a, d, pid=0) Traceback (most recent call last): File "", line 1, in ? File "/usr/tmp/python-iKAOxR", line 11, in zip TypeError: unexpected keyword arguments >>> zip(a, b, c, d) [(1, 5, 9, 12), (2, 6, 10, 13)] >>> zip(a, b, c, d, pad=None) [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)] >>> map(None, a, b, c, d) [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)] Reference Implementation Here is a reference implementation, in Python of the zip() built-in function and helper class. These would ultimately be replaced by equivalent C code. class _Zipper: def __init__(self, args, kws): # Defaults self.__padgiven = 0 if kws.has_key('pad'): self.__padgiven = 1 self.__pad = kws['pad'] del kws['pad'] # Assert no unknown arguments are left if kws: raise TypeError('unexpected keyword arguments') self.__sequences = args self.__seqlen = len(args) def __getitem__(self, i): ret = [] exhausted = 0 for s in self.__sequences: try: ret.append(s[i]) except IndexError: if not self.__padgiven: raise exhausted = exhausted + 1 if exhausted == self.__seqlen: raise ret.append(self.__pad) return tuple(ret) def __len__(self): # If we're padding, then len is the length of the longest sequence, # otherwise it's the length of the shortest sequence. if not self.__padgiven: shortest = -1 for s in self.__sequences: slen = len(s) if shortest < 0 or slen < shortest: shortest = slen return shortest longest = 0 for s in self.__sequences: slen = len(s) if slen > longest: longest = slen return longest def __str__(self): ret = [] i = 0 while 1: try: ret.append(self[i]) except IndexError: break i = i + 1 return str(ret) __repr__ = __str__ def zip(*args, **kws): return _Zipper(args, kws) Rejected Elaborations Some people have suggested that the user be able to specify the type of the inner and outer containers for the zipped sequence. This would be specified by additional keyword arguments to zip(), named `inner' and `outer'. This elaboration is rejected for several reasons. First, there really is no outer container, even though there appears to be an outer list container the example above. This is simply an artifact of the repr() of the zipped object. User code can do its own looping over the zipped object via __getitem__(), and build any type of outer container for the fully evaluated, concrete sequence. For example, to build a zipped object with lists as an outer container, use >>> list(zip(sequence_a, sequence_b, sequence_c)) for tuple outer container, use >>> tuple(zip(sequence_a, sequence_b, sequence_c)) This type of construction will usually not be necessary though, since it is expected that zipped objects will most often appear in for-loops. Second, allowing the user to specify the inner container introduces needless complexity and arbitrary decisions. You might imagine that instead of the default tuple inner container, the user could prefer a list, or a dictionary, or instances of some sequence-like class. One problem is the API. Should the argument to `inner' be a type or a template object? For flexibility, the argument should probably be a type object (i.e. TupleType, ListType, DictType), or a class. For classes, the implementation could just pass the zip element to the constructor. But what about built-in types that don't have constructors? They would have to be special-cased in the implementation (i.e. what is the constructor for TupleType? The tuple() built-in). Another problem that arises is for zips greater than length two. Say you had three sequences and you wanted the inner type to be a dictionary. What would the semantics of the following be? >>> zip(sequence_a, sequence_b, sequence_c, inner=DictType) Would the key be (element_a, element_b) and the value be element_c, or would the key be element_a and the value be (element_b, element_c)? Or should an exception be thrown? This suggests that the specification of the inner container type is needless complexity. It isn't likely that the inner container will need to be specified very often, and it is easy to roll your own should you need it. Tuples are chosen for the inner container type due to their (slight) memory footprint and performance advantages. Open Issues - What should "zip(a)" do? Given a = (1, 2, 3); zip(a) three outcomes are possible. 1) Returns [(1,), (2,), (3,)] Pros: no special casing in the implementation or in user code, and is more consistent with the description of it's semantics. Cons: this isn't what map(None, a) would return, and may be counter to user expectations. 2) Returns [1, 2, 3] Pros: consistency with map(None, a), and simpler code for for-loops, e.g. for i in zip(a): instead of for (i,) in zip(a): Cons: too much complexity and special casing for what should be a relatively rare usage pattern. 3) Raises TypeError Pros: None Cons: needless restriction Current scoring seems to generally favor outcome 1. - The name of the built-in `zip' may cause some initial confusion with the zip compression algorithm. Other suggestions include (but are not limited to!): marry, weave, parallel, lace, braid, interlace, permute, furl, tuples, lists, stitch, collate, knit, plait, and with. All have disadvantages, and there is no clear unanimous choice, therefore the decision was made to go with `zip' because the same functionality is available in other languages (e.g. Haskell) under the name `zip'[2]. References [1] http://www.python.org/doc/devel/ref/for.html [2] http://www.haskell.org/onlinereport/standard-prelude.html#$vzip TBD: URL to python-dev archives Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: From thomas at xs4all.net Mon Jul 17 21:38:04 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 21:38:04 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net>; from bwarsaw@beopen.com on Mon, Jul 17, 2000 at 03:06:13PM -0400 References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <20000717213804.Q7340@xs4all.nl> On Mon, Jul 17, 2000 at 03:06:13PM -0400, Barry A. Warsaw wrote: > There's still the open issue of what zip(sequence_a) should return. I'd vote for [(a,), (b,), (c,)], that is, still return tuples. It's consistent with the use in the case of multiple sequences. We already have map(None, sequence_a) that does it the non-obvious way ;) In the map case it's easily explained: it turns the sequence into a list. In the case of zip(), that isn't necessary (and not the point of the function, anyway.) I-still-wish-it-were-marry()-ly y'rs, ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Mon Jul 17 21:39:14 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 17 Jul 2000 21:39:14 +0200 Subject: [Python-Dev] Will Python die? In-Reply-To: <39734EA5.BBF96453@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 01:21:25PM -0500 References: <003f01bfeff3$26ac9840$770da8c0@bbs> <39732CC3.4E1620C5@prescod.net> <39736268.306B8DF0@schneider-kamp.de> <39734EA5.BBF96453@prescod.net> Message-ID: <20000717213914.R7340@xs4all.nl> On Mon, Jul 17, 2000 at 01:21:25PM -0500, Paul Prescod wrote: > Peter Schneider-Kamp wrote: > I don't have as much information as they do and I'm only a little bit > smarter than them anyhow. :) Yeah, I'm only a little bit smarter than Guido divided by Tim, too. Or-is-that-Guido-minus-Tim-ly y'rs, ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Mon Jul 17 22:04:54 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 17 Jul 2000 22:04:54 +0200 Subject: [Python-Dev] if/else and macros References: <200007162139.OAA18443@slayer.i.sourceforge.net> <397230CC.D8380547@lemburg.com> <20000716153736.T29590@lyra.org> <3972BBD6.A81B2577@lemburg.com> <20000717020531.X29590@lyra.org> <20000717111741.H7340@xs4all.nl> <000d01bfefd3$b924d540$f2a6b5d4@hagrid> <20000717025756.G29590@lyra.org> <009501bff00e$3d3bc980$f2a6b5d4@hagrid> <39734AA3.7B33EE44@lemburg.com> <003101bff01f$193c5520$f2a6b5d4@hagrid> Message-ID: <007201bff02a$46f02860$f2a6b5d4@hagrid> I wrote: > sorry, but that's bullshit. or in slightly fewer words: "goto != longjmp" From Vladimir.Marangozov at inrialpes.fr Mon Jul 17 22:15:40 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 17 Jul 2000 22:15:40 +0200 (CEST) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net> from "Barry A. Warsaw" at Jul 17, 2000 03:06:13 PM Message-ID: <200007172015.WAA25033@python.inrialpes.fr> Barry A. Warsaw wrote: > > > I've made a final pass through PEP 201, Parallel Iteration. Nice! I think that a broader audience needs to read this. Why not asking for reactions on c.l.py? > High bit: Guido strongly prefers zip() as the name of the built-in. > All the suggestions so far have pluses and minuses, and in the absence > of a clear winner, he'd just as soon go with the Haskell name. I > agree. I don't feel comfortable with it. Period. You might want to see what http://www.dict.org has to say about it. Looking at the examples for this builtin function, and without thinking too much about the name, I'd call it - fold(). zip-gun'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gmcm at hypernet.com Mon Jul 17 22:22:45 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Mon, 17 Jul 2000 16:22:45 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <1248257113-63674673@hypernet.com> Barry A. Warsaw wrote: [PEP 201, Parallel Iteration] > Open Issues > > - What should "zip(a)" do? Given > > a = (1, 2, 3); zip(a) > > three outcomes are possible. How about a fourth: zip(a) is the same as zip(a, []) ? Look at it this way: what should zip(a, pad=None) return? Obviously: [(1, None), (2, None), (3, None)] So what should zip(a) return? Don't special case it, just return []. With only one arg, zip has clearly lost meaning. That is, it's clearly a degenerate case, and not worth a bunch of special casing. although-we-do-special-case-Barry-ly y'rs - Gordon From esr at thyrsus.com Mon Jul 17 23:01:15 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Mon, 17 Jul 2000 17:01:15 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net> References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <20000717170114.B7624@thyrsus.com> Barry A. Warsaw : > High bit: Guido strongly prefers zip() as the name of the built-in. > All the suggestions so far have pluses and minuses, and in the absence > of a clear winner, he'd just as soon go with the Haskell name. I agree. Grumble. Not too happy with the conclusion, but can't argue with the logic. I somewhat reluctantly agree. -- Eric S. Raymond Gun Control: The theory that a woman found dead in an alley, raped and strangled with her panty hose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound. -- L. Neil Smith From skip at mojam.com Mon Jul 17 21:58:11 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 17 Jul 2000 14:58:11 -0500 (CDT) Subject: [Python-Dev] 'shadowing' builtins In-Reply-To: <20000717200116.P7340@xs4all.nl> References: <20000717200116.P7340@xs4all.nl> Message-ID: <14707.25939.889361.800800@beluga.mojam.com> Thomas> He decided to go to David Beazly's python introduction, and he Thomas> was suprised at how you can do 'None = 4'. And when I explained Thomas> it's harmless (because it's local, not global) he was suprised Thomas> it didn't generate a warning. And, well, why doesn't it generate Thomas> a warning? I wrote a script some time ago to print these warnings. Search http://www.musi-cal.com/~skip/python/ for the string "hiding builtin names"... Skip From peter at schneider-kamp.de Tue Jul 18 01:39:31 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 17 Jul 2000 23:39:31 +0000 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <200007172015.WAA25033@python.inrialpes.fr> Message-ID: <39739933.DFFAAFD9@schneider-kamp.de> Vladimir Marangozov wrote: > > I don't feel comfortable with it. Period. > You might want to see what http://www.dict.org has to say about it. > > Looking at the examples for this builtin function, and without thinking > too much about the name, I'd call it - fold(). Please, don't!!! As far as I can remember, fold is the "reduce of the functional languages". At least it is that in Haskell. Here's a quote from the Journal of Functional Programming (July 1999): "In functional programming, fold is a standard operator that encapsulates a simple pattern of recursion for processing lists." BTW: I still like zip() and as someone said: dir and del have the same problem/not-a-problem Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Vladimir.Marangozov at inrialpes.fr Tue Jul 18 00:05:06 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 18 Jul 2000 00:05:06 +0200 (CEST) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <39739933.DFFAAFD9@schneider-kamp.de> from "Peter Schneider-Kamp" at Jul 17, 2000 11:39:31 PM Message-ID: <200007172205.AAA25258@python.inrialpes.fr> Peter Schneider-Kamp wrote: > > [me] > > Looking at the examples for this builtin function, and without thinking > > too much about the name, I'd call it - fold(). > > Please, don't!!! As far as I can remember, fold is the "reduce of the > functional languages". At least it is that in Haskell. > > Here's a quote from the Journal of Functional Programming (July 1999): > "In functional programming, fold is a standard operator that > encapsulates a simple pattern of recursion for processing lists." Okay, but weren't we paying less attention to historical facts in language design? Guido regrets map() that slipped through, for instance. My opinion is a newbie opinion. I just can't believe that we can't find a more intuitive name for this function! From peter at schneider-kamp.de Tue Jul 18 02:11:03 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 00:11:03 +0000 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <3973A097.B85D6775@schneider-kamp.de> "Barry A. Warsaw" wrote: > > I've made a final pass through PEP 201, Parallel Iteration. For those > of you without easy access to the CVS tree, I'm including it below. > You can also access it through the web at Great work. It's a pleasure to read. > High bit: Guido strongly prefers zip() as the name of the built-in. > All the suggestions so far have pluses and minuses, and in the absence > of a clear winner, he'd just as soon go with the Haskell name. I > agree. I agree (giving +1 would be blasphemy, right?). One important remark: What about unzip()? Shouldn't there be the reverse function? One example (which I really wrote not so long ago in an ANN context): def normalize(seq): # scale to values in 0..1 return map(lambda x, max=max(seq), min=min(seq): (x-min)/(max-min), seq) # from file with: x1 y1 z1\nx2 y2 z2\n etc. data = [[1.0, 2.0, 3.0], [-1.0, 1.0, -1.0], [-1.0, -2.0, -3.0], [2.0, 3.0, 1.0]] # zip related data fields, normalize that field, unzip data = unzip(map(normalize,zip(data))) > Please see the new reference implementation, which includes a > __len__() method, and the discussion of the rejected elaborations. > There's still the open issue of what zip(sequence_a) should return. I think zip([1, 2, 3]) should give ((1), (2), (3)). My reasons? 1) It feels right to me. 2) It is the way Lisp (or Scheme, don't remember) deals with it. [Haskell's zip-unzip is limited to two lists] By the way, yet another example for unzip(): mylist = [(1,), (2,), (3,)] What looks better? a) newlist = map(lambda x:x[0], mylist) b) newlist = unzip(mylist) advocating-unzip-as-an-overridable-builtin-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From effbot at telia.com Tue Jul 18 00:24:21 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 18 Jul 2000 00:24:21 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <200007172205.AAA25258@python.inrialpes.fr> Message-ID: <006f01bff03d$c1f20c00$f2a6b5d4@hagrid> > I just can't believe that we can't find a more intuitive name > for this function! ...and I cannot believe that you're trying to reopen this discussion once again :-( (or is this a trick by Guido to make sure we don't do any real work while he's on the conference? ;-) "After consultation with Guido, zip() is chosen as the name of this built-in." -- seen on the python-checkins list. From peter at schneider-kamp.de Tue Jul 18 02:21:16 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 00:21:16 +0000 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <200007172205.AAA25258@python.inrialpes.fr> Message-ID: <3973A2FC.2CD26F44@schneider-kamp.de> Vladimir Marangozov wrote: > > What's the problem with `folding' sequences element-wise in Python? > > What's the problem with `zipping' sequences element-wise in Python? > > Which one of the 2 questions above makes more sense? The first. But it gives me the wrong impression: fold the list [1, 2, 3]: \ / f(1,f(2,f(3))) for some function f fold the lists [1, 2, 3] and [4, 5, 6] elementwise: \ / f(f(3,f(6)),f(f(2,f(5)),f(1,f(4)))) for some function f I'd just wonder what to fold the lists with. Even if my judgement is biased by my Haskell organ, I still think that taking the name of an important list operator from different languages for a completely different list operation is way worse than using the name of a file compression utility as a list operator. just-my-cents(0.02)-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From Vladimir.Marangozov at inrialpes.fr Tue Jul 18 00:38:32 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 18 Jul 2000 00:38:32 +0200 (CEST) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <006f01bff03d$c1f20c00$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 18, 2000 12:24:21 AM Message-ID: <200007172238.AAA25374@python.inrialpes.fr> Fredrik Lundh wrote: > > > I just can't believe that we can't find a more intuitive name > > for this function! > > ...and I cannot believe that you're trying to reopen this discussion > once again :-( :-) Sorry, but it was discussed during a short period of time (despite the huge number of posts in that time slice) and I wasn't really available for participating seriously in the discussion. So now I'm taking the opportunity to read the PEP without much external pression, as well as to say what I think and to think what I say. Note that I suggested Barry to sumbit this PEP to a broader audience for collection external opinions on all aspects of the PEP. If there are several people with CS background that don't feel good with this name, there's something wrong with it. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gmcm at hypernet.com Tue Jul 18 00:44:44 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Mon, 17 Jul 2000 18:44:44 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <200007172238.AAA25374@python.inrialpes.fr> References: <006f01bff03d$c1f20c00$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jul 18, 2000 12:24:21 AM Message-ID: <1248248594-64187019@hypernet.com> Vladimir.Marangozov wrote: > Fredrik Lundh wrote: > > > > > I just can't believe that we can't find a more intuitive name > > > for this function! > > > > ...and I cannot believe that you're trying to reopen this > > discussion once again :-( > > :-) Sorry, but it was discussed during a short period of time > (despite the huge number of posts in that time slice) and I > wasn't really available for participating seriously in the > discussion. So now I'm taking the opportunity to read the PEP > without much external pression, as well as to say what I think > and to think what I say. > > Note that I suggested Barry to sumbit this PEP to a broader > audience for collection external opinions on all aspects of the > PEP. If there are several people with CS background that don't > feel good with this name, there's something wrong with it. To me, "zip" in the context of computers means compress. But it's a stupid name for compress. And one look at the args makes it obvious it's not a compress. So I expect that your typical newbie will do one, and only one "Huh??? Oh - zip as in zipper, not zip as in PKZIP" and never have to post again. wishfully-y'rs - Gordon From Vladimir.Marangozov at inrialpes.fr Tue Jul 18 01:11:47 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 18 Jul 2000 01:11:47 +0200 (CEST) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248248594-64187019@hypernet.com> from "Gordon McMillan" at Jul 17, 2000 06:44:44 PM Message-ID: <200007172311.BAA25445@python.inrialpes.fr> Gordon McMillan wrote: > > To me, "zip" in the context of computers means compress. > But it's a stupid name for compress. And one look at the args > makes it obvious it's not a compress. So I expect that your > typical newbie will do one, and only one "Huh??? Oh - zip as > in zipper, not zip as in PKZIP" and never have to post again. Right. > > wishfully-y'rs My wish is to add fold() as one of the suggested names in the PEP, then let this PEP spend some time in c.l.py. Give people a chance to catch up, please. That's how the PEP process is intended to work. The name hasn't been cast in stone. It's in the PEP, not in CVS. end-of-story-ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul at prescod.net Tue Jul 18 01:10:53 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 18:10:53 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <3973927D.D2D37DE0@prescod.net> I would say that you should make the ambiguous single-param case illegal. For one of the examples you say: > for i in zip(a): Why would you ever do that??? The only way that would make sense to me if zip([[1],[2]])==zip([1],[2]), which I would dislike. Use zip(*[[1],[2]]) instead. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul at prescod.net Tue Jul 18 01:11:17 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 18:11:17 -0500 Subject: [Python-Dev] Votes Message-ID: <39739295.4AEB5195@prescod.net> I'm going to wait for four positive votes or one from Guido before I take the following action cd nondist cvs add sandbox cd sandbox cvs add onlinehelp.py cvs add inspect.py -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From peter at schneider-kamp.de Tue Jul 18 03:19:33 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 01:19:33 +0000 Subject: [Python-Dev] Votes References: <39739295.4AEB5195@prescod.net> Message-ID: <3973B0A5.AE63E45F@schneider-kamp.de> Paul Prescod wrote: > > I'm going to wait for four positive votes or one from Guido before I > take the following action Don't know if my one counts, but you can have it anyway: +1 on nondist/sandbox Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From akuchlin at mems-exchange.org Tue Jul 18 01:57:32 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 17 Jul 2000 19:57:32 -0400 (EDT) Subject: [Python-Dev] Python-dev summary: Jul 1-15 Message-ID: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Note: this is an experiment in whether I can make a useful, interesting, somewhat coherent summary of python-dev activity. Things I'm not sure of: * Accuracy. I skipped past some threads such as the list comprehensions one, and may be unaware of a resolution. * How many links are needed? Should I try to link to several posts per thread, SF patches, etc.? That makes more work for me, but also makes the summary more useful. * Bi-weekly OK? I think it's a reasonable frequency. I'll check my e-mail tomorrow; if no one screams loudly, I'll post it. (My connectivity is poor enough that I don't want to do major editing on it, or be able to respond to many e-mails in detail.) ================== Python-dev summary, July 1-15, 2000: The 2-week period started with reactions to Guido's June 30 announcement that the 2.0b1 release would be delayed for an indefinite period due to legal wrangling. This gave everyone a second chance to contribute more patches while waiting for the release, and the activity level remained high. Two dominant issues for this time period were Unicode-related issues, and list comprehensions. The Unicode issues, as usual, turned on the question of where strings and Unicode strings should be interchangeable. A discussion in the thread "Minidom and Unicode" considered whether it's legal to return a Unicode string from __repr__. The consensus was that it should be legal, despite fears of breaking code that expects only an 8-bit string, and the CVS tree was patched accordingly. Python's interpreter mode uses repr() to display the results of expressions, and it will convert Unicode strings to ASCII, using the unicode-escape encoding. The following code, typed into the interpreter, will print 'abc\u3456'. class C: def __repr__(self): return u'abc\u3456' print repr( C() ) Hashing also presented a problem. As M.-A. Lemburg explained in http://www.python.org/pipermail/python-dev/2000-July/012150.html: The problem comes from the fact that the default encoding can be changed to a locale specific value (site.py does the lookup for you), e.g. given you have defined LANG to be us_en, Python will default to Latin-1 as default encoding. This results in '???' == u'???', but hash('???') != hash(u'???'), which is in conflict with the general rule about objects having the same hash value if they compare equal. The resolution seems to be simply removing the ability to change the default encoding and adopt ASCII as the fixed default; if you want to use other encodings, you must specify them explicitly. List comprehensions originated as a patch from Greg Ewing that's now being kept up-to-date versus the CVS tree by Skip Montanaro. Originally they weren't on the roadmap for 1.6, but with the greater version number jump to 2.0, GvR is more willing to incorporate larger changes. List comprehensions provide a more concise way to create lists in situations where map() and filter() would currently be used. To take some examples from the patched-for-list-comphrensions version of the Python Tutorial: >>> spcs = [" Apple", " Banana ", "Coco nut "] >>> print [s.strip() for s in spcs] ['Apple', 'Banana', 'Coco nut'] >>> vec1 = [2, 4, 6] >>> vec2 = [4, 3, -9] >>> print [x*y for x in vec1 for y in vec2] [8, 6, -18, 16, 12, -36, 24, 18, -54] A lengthy subthread about intuitiveness sprang from the second example, and from a patch from Thomas Wouters that implements parallel 'for' loops. The patch makes "for x in [1,2]; y in ['a','b']" cause x,y to be 1,'a', and then 2,'b'. The thread circulated around whether people would expect this syntax to produce the Cartesian product of the two lists: (1,'a'), (1, 'b'), (2, 'a'), (2, 'b'). No clear answer or final syntax has emerged yet, though Greg Wilson has been trying out syntaxes on Python-unaware people and asking them what they'd expect: http://www.python.org/pipermail/python-dev/2000-July/012810.html It was also suggested to add a new built-in function for parallel 'for' loops instead of new syntax, so you would code 'for x,y in zip([1,2], ['a','b']):'. A lengthy and very dull discussion ensued about the name 'zip': should it be 'plait', 'knit', 'parallel', or even 'marry'? Some new procedures for Python development were set out: Tim Peters wrote some guidelines for using SourceForge's patch manager: http://www.python.org/pipermail/python-dev/2000-July/012635.html Barry Warsaw announced a series of Python Extension Proposal (PEP) documents, which play the role of RFCs for significant changes to Python: http://www.python.org/pipermail/python-dev/2000-July/013059.html Mark Hammond gave the first glimpse of a fourth Python implementation: "This new compiler could be compared, conceptually, with JPython - it is a completely new implementation of Python. It has a compiler that generates native Windows .DLL/.EXE files. It uses a runtime that consists of a few thousand lines of C# (C-Sharp) code. The Python programs can be debugged at the source level with Visual Studio 7, as well as stand-alone debuggers for this environment. Python can sub-class VB or C# classes, and vice-versa." http://www.python.org/pipermail/python-dev/2000-July/013019.html Other bits: Skip Montanaro experimented with using code coverage tools to measure the effectiveness of the Python test suite, by seeing which lines of code (both C and Python) that are exercised by the tests. A summary of the results is at: http://www.musi-cal.com/~skip/python/Python/dist/src/summary.html Skip also added support to the readline module for saving and loading command histories. ESR suggested adding a standard lexer to the core, and /F suggested an extension to regular expressions that would make them more useful for tokenizing: http://www.python.org/pipermail/python-dev/2000-July/012032.html CVS problems were briefly a distraction, with dangling locks preventing commits to the Lib/ and Modules/ subdirectories for a few days. Despite such glitches, the move to SourceForge has accelerated development overall, as more people can make check-ins and review them. For some time Tim Peters has been suggesting removing the Py_PROTO macro and making the sources require ANSI C; mostly this is because the macro breaks the C cross-referencing support in Tim's editor. :) The ball finally started rolling on this, and snowballed into a massive set of patches to use ANSI C prototypes everywhere. Fred Drake and Peter Schneider-Kamp rose to the occasion and edited the prototypes in dozens of files. Jeremy Hylton pointed out that "Tuple, List, String, and Dict have a Py*_Size method. The abstract object interface uses PySequence_Length. This is inconsistent and hard to remember," and suggested that *_Size be made the standard form, and *_Length will be deprecated. Just before the cutoff date, Paul Prescod proposed a new help() function for interactive use, and began implementing it: http://www.python.org/pipermail/python-dev/2000-July/013346.html Huaiyu Zhu suggested adding new operators to support matrix math: http://www.python.org/pipermail/python-dev/2000-July/013364.html A slew of minor patches and bugfixes were made, too. Some highlights: * Ka-Ping Yee improved the syntax error messages. * ESR made various changes to ConfigParser.py * Some of Sam Rushing's patches from Medusa were applied to add os.setreuid() and friends; AMK is working on adding the poll() system call. * /F was his usual "patching machine" self, integrating PythonWin's win32popen function so that os.popen will now work correctly on Windows as well as Unix, writing PyErr_SafeFormat() to prevent buffer overflows, and proposing some patches to reduce the 600K size of the Unicode character database. Some fun posts came up during the near-endless zip()/plait()/whatever naming thread: http://www.python.org/pipermail/python-dev/2000-July/012920.html: "BTW: How comes, that Ping very often invents or introduces very clever ideas and concepts, but also very often chooses unclear names for them? Is it just me not being a native english speaker?" "I don't know. Perhaps my florx bignal zupkin isn't very moognacious?" -- Peter Funk and Ka-Ping Yee, 12 Jul 2000 http://www.python.org/pipermail/python-dev/2000-July/013050.html, while everyone was trying to think up alternative names for zip(): "Let me throw one more out, in honor of our fearless leader's recent life change: marry(). Usually only done in pairs, and with two big sequences, I get the image of a big Unification Church event :)" "Isn't it somewhat of a political statement to allow marriages of three or more items? I always presumed that this function was n-ary, like map." -- Barry Warsaw and Paul Prescod From bwarsaw at beopen.com Tue Jul 18 02:04:02 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 20:04:02 -0400 (EDT) Subject: [Python-Dev] Votes References: <39739295.4AEB5195@prescod.net> Message-ID: <14707.40690.705582.995282@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> I'm going to wait for four positive votes or one from Guido PP> before I take the following action | cd nondist | cvs add sandbox | cd sandbox | cvs add onlinehelp.py | cvs add inspect.py +1 And since I'm the only one left minding the store, while everyone else goes off galavanting in sunny California, you can read that as +1000 :) nothing-like-a-dose-of-al-haig-to-make-you-feel-important-til-the-boss-comes- home-ly y'rs, -Barry From gstein at lyra.org Tue Jul 18 02:13:17 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 17:13:17 -0700 Subject: [Python-Dev] htmldoc.py + inspect.py In-Reply-To: ; from ping@lfw.org on Mon, Jul 17, 2000 at 11:01:58AM -0700 References: <39734659.16D327D9@lemburg.com> Message-ID: <20000717171317.P29590@lyra.org> On Mon, Jul 17, 2000 at 11:01:58AM -0700, Ka-Ping Yee wrote: > On Mon, 17 Jul 2000, M.-A. Lemburg wrote: > > This only gives the right to use the module in case it becomes > > part of the standard lib :-( > > Fixed. > > # I, Ka-Ping Yee, the author of this contribution, hereby grant to anyone and > # everyone a nonexclusive, irrevocable, royalty-free, worldwide license to > # reproduce, distribute, perform and/or display publicly, prepare derivative > # versions, and otherwise use this contribution in any fashion, or any > # derivative versions thereof, at no cost to anyone, and to authorize others > # to do so. This software is provided "as is", with NO WARRANTY WHATSOEVER, > # not even a warranty of merchantability or fitness for any particular purpose. > > Geez. Is that enough words yet? All i wanted to say was "go play". :) Here is short for you: # Written by Ka-Ping Yee. Public Domain. No warranties. Can't get any easier than that. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jul 18 02:21:23 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 17:21:23 -0700 Subject: [Python-Dev] Votes In-Reply-To: <39739295.4AEB5195@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 06:11:17PM -0500 References: <39739295.4AEB5195@prescod.net> Message-ID: <20000717172123.Q29590@lyra.org> On Mon, Jul 17, 2000 at 06:11:17PM -0500, Paul Prescod wrote: > I'm going to wait for four positive votes or one from Guido before I > take the following action > > cd nondist > cvs add sandbox > cd sandbox > cvs add onlinehelp.py > cvs add inspect.py Considering that I suggested /nondist/sandbox/ it probably stands to reason that you had my +1 all along :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul at prescod.net Tue Jul 18 02:27:46 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 19:27:46 -0500 Subject: [Python-Dev] Python-dev summary: Jul 1-15 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: <3973A482.48023039@prescod.net> I like it. I don't see anything about range literals, though. Probably buried in the list comp. discussion. I can't remember anything else you might have missed off the top of my head. I liked the part where someone asked: "What causes these CVS locks?" and Tim replied: "Skip, apparently." Luckily you cut off before I get zapped with a lightening bolt for checking in inappropriately. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul at prescod.net Tue Jul 18 02:30:08 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 19:30:08 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> Message-ID: <3973A510.86D2AF54@prescod.net> "Barry A. Warsaw" wrote: > > >>>>> "PP" == Paul Prescod writes: > > >> You can't. > > PP> Gah. That sucks. > > Welcome to CVS. What did Greg Wilson say at IPC8? Paraphrasing: CVS > is the worst tool everybody uses. :) Okay, but it isn't entirely CVS' fault. Not *entirely*. Shouldn't out CVS space be writeable by one of us. Okay, that person could royally screw everything up but hey, that's the whole point of Unix, isn't it? -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From klm at digicool.com Tue Jul 18 02:40:33 2000 From: klm at digicool.com (Ken Manheimer) Date: Mon, 17 Jul 2000 20:40:33 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <3973A097.B85D6775@schneider-kamp.de> Message-ID: On Tue, 18 Jul 2000, Peter Schneider-Kamp wrote: > One important remark: > What about unzip()? Shouldn't there be the reverse function? > One example (which I really wrote not so long ago in an ANN context): Evan Simpson (a colleague here at digicool, who'd be a good addition to python-dev) noticed that unzip is unnecessary - zip is its own inverse. Since this is a worthwhile observation, i'll indulge a bit and present it in evan's terms - particularly noting a different packaging that i think is pretty cool, as methods on sequences. > From evan at digicool.com Mon Jul 17 20:17:30 2000 > Date: Mon, 17 Jul 2000 14:36:18 -0400 > From: Evan Simpson > To: Ken Manheimer > Subject: Next Braid > > How's this: > > ([1, 2, 3], ['a', 'b', 'c']).braid() == ((1, 'a'), (2, 'b'), (3, 'c')) > [[1, 2, 3], ['a', 'b', 'c']].braid() == [(1, 'a'), (2, 'b'), (3, 'c')] > > and > > [[1,2,3], ['a']].braid(None) == [(1, 'a'), (2, None), (3, None)] > > Also, notice that if 's' is a rectangular sequence of sequences, then for > all 'a' and 'b': > > s.braid()[a][b] == s[b][a] by definition, so > > s.braid().braid()[a][b] == s.braid()[b][a] == s[a][b] and therefore, > > braid is its own inverse, and we don't need unbraid. > > Cheers, > > Evan @ digicool & 4-am I can't do better than that, but i have one further elaboration i'd like to see. If the subject sequence already contains some elements, the result sequence is a copy of the originals with the new braided, whoops zipped elements appended - this way, braids can be cumulative. >>> [(1, 3), (2, 4)].braid(('a', 'b'), ('x', 'y')) [(1, 3, 'a', 'x'), (2, 4, 'b', 'y')] Anyway, we don't need an unzip/unbraid. ! Ken klm at digicool.com From klm at digicool.com Tue Jul 18 02:43:38 2000 From: klm at digicool.com (Ken Manheimer) Date: Mon, 17 Jul 2000 20:43:38 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: Message-ID: Whoops, i got my section wrong. Disregard the last part. On Mon, 17 Jul 2000, Ken Manheimer wrote: > On Tue, 18 Jul 2000, Peter Schneider-Kamp wrote: > > > One important remark: > > What about unzip()? Shouldn't there be the reverse function? > > One example (which I really wrote not so long ago in an ANN context): > > Evan Simpson (a colleague here at digicool, who'd be a good addition > to python-dev) noticed that unzip is unnecessary - zip is its own > inverse. Since this is a worthwhile observation, i'll indulge a bit > and present it in evan's terms - particularly noting a different > packaging that i think is pretty cool, as methods on sequences. > > > From evan at digicool.com Mon Jul 17 20:17:30 2000 > > Date: Mon, 17 Jul 2000 14:36:18 -0400 > > From: Evan Simpson > > To: Ken Manheimer > > Subject: Next Braid > > > > How's this: > > > > ([1, 2, 3], ['a', 'b', 'c']).braid() == ((1, 'a'), (2, 'b'), (3, 'c')) > > [[1, 2, 3], ['a', 'b', 'c']].braid() == [(1, 'a'), (2, 'b'), (3, 'c')] > > > > and > > > > [[1,2,3], ['a']].braid(None) == [(1, 'a'), (2, None), (3, None)] > > > > Also, notice that if 's' is a rectangular sequence of sequences, then for > > all 'a' and 'b': > > > > s.braid()[a][b] == s[b][a] by definition, so > > > > s.braid().braid()[a][b] == s.braid()[b][a] == s[a][b] and therefore, > > > > braid is its own inverse, and we don't need unbraid. > > > > Cheers, > > > > Evan @ digicool & 4-am > > I can't do better than that, but i have one further elaboration i'd > like to see. If the subject sequence already contains some elements, > the result sequence is a copy of the originals with the new braided, > whoops zipped elements appended - this way, braids can be cumulative. > > >>> [(1, 3), (2, 4)].braid(('a', 'b'), ('x', 'y')) > [(1, 3, 'a', 'x'), (2, 4, 'b', 'y')] > > Anyway, we don't need an unzip/unbraid. ! > > Ken > klm at digicool.com > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From mhammond at skippinet.com.au Tue Jul 18 04:16:51 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 17 Jul 2000 22:16:51 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <003f01bfefc6$64840540$f2a6b5d4@hagrid> Message-ID: [Fredrik] > I'm probably missing something here, but is there any reason > you cannot add this code to Py_InitModule4 instead: > > PyObject *m, *d, *v; > PyMethodDef *ml; > + if (!Py_IsInitialized()) > + Py_FatalError("Bad Python version"); /* Never returns */ Py_InitModule4() is inside Pythonxx.dll - so it _will_ be initialized. The point of putting this code inside the .pyd is that the .pyd will be calling the Py_IsInitialized() from Python15.dll - and this DLL has never been initialized. Putting it inside Py_InitModule4() will never trigger an error... Mark. From pingster at ilm.com Tue Jul 18 04:37:08 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Mon, 17 Jul 2000 19:37:08 -0700 (PDT) Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: On Mon, 17 Jul 2000, Andrew Kuchling wrote: > Note: this is an experiment in whether I can make a useful, > interesting, somewhat coherent summary of python-dev activity. Very nice job! Well done. Thanks for doing all the work! > * Accuracy. I skipped past some threads such as the list > comprehensions one, and may be unaware of a resolution. As Paul mentioned, there was some talk about range literals. There was some stuff about augmented assignment too, i believe? Thomas Wouters tried to summarize the list-comp, parallel-iteration, and range-literal threads, to which i responded with an alternative proposal. Huaiyu Zhu also presented a fairly complete list-comp proposal (though i think the syntax is not quite implementable). Eric suggested adding a cross-platform "browse" routine to urllib. Some discussion ensued; some names for a separate module were proposed including "webbrowser.py"; some people suggested using the "start" command on Windows instead; i suggested a "launch" module for launching other kinds of external applications as well as web browsers; i don't remember if any resolution was reached. Paul started a small thread on automatic coercion of any type to string. There was some discussion of rearranging newsgroup and mailing list traffic, choosing more distinct purposes for comp.lang.python and python-dev, etc. A suggestion to make string.atoi work for negative bases was politely but quickly squashed. There were random gripes about SourceForge. Moshe suggested a file-copy routine that accepted objects; Greg Stein checked it in. Paul raised the issue of bringing an XPath implementation into Python. Paul made a fairly detailed proposal for an online help mechanism (this happened on July 15 at the end of your time window; more discussion ensued). -- ?!ng "Smoking kills. If you're killed, you've lost a very important part of your life." -- Brooke Shields From gmcm at hypernet.com Tue Jul 18 04:38:37 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Mon, 17 Jul 2000 22:38:37 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: References: <003f01bfefc6$64840540$f2a6b5d4@hagrid> Message-ID: <1248234561-65031149@hypernet.com> Mark Hammond wrote: > [Fredrik] > > I'm probably missing something here, but is there any reason > > you cannot add this code to Py_InitModule4 instead: > > > > PyObject *m, *d, *v; > > PyMethodDef *ml; > > + if (!Py_IsInitialized()) > > + Py_FatalError("Bad Python version"); /* Never returns */ > > Py_InitModule4() is inside Pythonxx.dll - so it _will_ be > initialized. The point of putting this code inside the .pyd is > that the .pyd will be calling the Py_IsInitialized() from > Python15.dll - and this DLL has never been initialized. Putting > it inside Py_InitModule4() will never trigger an error... Florida sun getting to you? Or the teenage girls? Or just being in the wrong hemisphere (so all the blood rushes to your feet)? initXXX() (normally) calls Py_InitModule4, so it would be the one in whatever XXXmodule loaded. - Gordon From gmcm at hypernet.com Tue Jul 18 04:38:37 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Mon, 17 Jul 2000 22:38:37 -0400 Subject: [Python-Dev] Votes In-Reply-To: <14707.40690.705582.995282@anthem.concentric.net> Message-ID: <1248234559-65031252@hypernet.com> Barry A. Warsaw wrote: > +1 > > And since I'm the only one left minding the store, while everyone > else goes off galavanting in sunny California, you can read that > as +1000 :) > > nothing-like-a-dose-of-al-haig-to-make-you-feel-important-til-the > -boss-comes- home-ly y'rs, -Barry C'mon Barry, you didn't verb a single noun! - Gordon From mhammond at skippinet.com.au Tue Jul 18 04:42:49 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 17 Jul 2000 22:42:49 -0400 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: <1248234561-65031149@hypernet.com> Message-ID: > Florida sun getting to you? Or the teenage girls? Or just being > in the wrong hemisphere (so all the blood rushes to your feet)? > > initXXX() (normally) calls Py_InitModule4, so it would be the > one in whatever XXXmodule loaded. Doh! All of the above - plus an unshakable belief that while on vacation I never need to check my facts before spouting off. But-fortunately-that-all-ends-tomorrow-ly, Mark. From bwarsaw at beopen.com Tue Jul 18 05:27:21 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 23:27:21 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> Message-ID: <14707.52889.135983.472187@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Okay, but it isn't entirely CVS' fault. Not PP> *entirely*. Shouldn't out CVS space be writeable by one of PP> us. Okay, that person could royally screw everything up but PP> hey, that's the whole point of Unix, isn't it? Yeah, but it's only necessary because CVS doesn't let you do those tasks through it's interface. Well, kind of a pointless argument because it probably won't change on SF any time soon, and who among us is actively hacking on CVS? :) -Barry From esr at thyrsus.com Tue Jul 18 06:06:44 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jul 2000 00:06:44 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: References: <3973A097.B85D6775@schneider-kamp.de> Message-ID: <20000718000644.A8911@thyrsus.com> Ken Manheimer : > > ([1, 2, 3], ['a', 'b', 'c']).braid() == ((1, 'a'), (2, 'b'), (3, 'c')) > > [[1, 2, 3], ['a', 'b', 'c']].braid() == [(1, 'a'), (2, 'b'), (3, 'c')] > > > > and > > > > [[1,2,3], ['a']].braid(None) == [(1, 'a'), (2, None), (3, None)] This is rather cool -- I especially like the implied feature of deriving the type of the result from the type of the outermost level of the object. I would be +1 on making zip/braid a sequence method rather than a function. -- Eric S. Raymond I don't like the idea that the police department seems bent on keeping a pool of unarmed victims available for the predations of the criminal class. -- David Mohler, 1989, on being denied a carry permit in NYC From gstein at lyra.org Tue Jul 18 05:55:50 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 20:55:50 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory In-Reply-To: <14707.52889.135983.472187@anthem.concentric.net>; from bwarsaw@beopen.com on Mon, Jul 17, 2000 at 11:27:21PM -0400 References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> <14707.52889.135983.472187@anthem.concentric.net> Message-ID: <20000717205550.Z29590@lyra.org> On Mon, Jul 17, 2000 at 11:27:21PM -0400, Barry A. Warsaw wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> Okay, but it isn't entirely CVS' fault. Not > PP> *entirely*. Shouldn't out CVS space be writeable by one of > PP> us. Okay, that person could royally screw everything up but > PP> hey, that's the whole point of Unix, isn't it? > > Yeah, but it's only necessary because CVS doesn't let you do those > tasks through it's interface. Well, kind of a pointless argument > because it probably won't change on SF any time soon, and who among us > is actively hacking on CVS? :) I'm actively involved with CVS's successor. Does that count? :-) -- Greg Stein, http://www.lyra.org/ From bwarsaw at beopen.com Tue Jul 18 05:56:42 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 17 Jul 2000 23:56:42 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> <14707.52889.135983.472187@anthem.concentric.net> <20000717205550.Z29590@lyra.org> Message-ID: <14707.54650.959052.870977@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> I'm actively involved with CVS's successor. Does that count? GS> :-) Only if I get to play with it! From esr at thyrsus.com Tue Jul 18 06:15:51 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jul 2000 00:15:51 -0400 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: <20000718001551.C8911@thyrsus.com> Ka-Ping Yee : > Eric suggested adding a cross-platform "browse" routine to urllib. > Some discussion ensued; some names for a separate module were > proposed including "webbrowser.py"; some people suggested using > the "start" command on Windows instead; i suggested a "launch" > module for launching other kinds of external applications as well > as web browsers; i don't remember if any resolution was reached. Fred Drake coded up a new version after I critiqued the original. He and I agreed it was good, and we didn't see any -1s on adding it to the library. Fred, did you ever commit that sucker? -- Eric S. Raymond The possession of arms by the people is the ultimate warrant that government governs only with the consent of the governed. -- Jeff Snyder From paul at prescod.net Tue Jul 18 06:00:36 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 17 Jul 2000 23:00:36 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> <14707.52889.135983.472187@anthem.concentric.net> Message-ID: <3973D664.747D3886@prescod.net> "Barry A. Warsaw" wrote: > > ... > > Yeah, but it's only necessary because CVS doesn't let you do those > tasks through it's interface. Well, kind of a pointless argument > because it probably won't change on SF any time soon, and who among us > is actively hacking on CVS? :) I mean CVS stores our information as a bunch of files on a hard disk. Those files use the Unix UGO security model. You are some one trusted (one or the other) should be in the PythonAdmins Unix group and you or that person should be able to physically change files in our directories using your shell account. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From gstein at lyra.org Tue Jul 18 06:17:17 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 17 Jul 2000 21:17:17 -0700 Subject: [Python-Dev] CVS: python/nondist/nondist - New directory In-Reply-To: <3973D664.747D3886@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 11:00:36PM -0500 References: <200007171050.DAA28047@slayer.i.sourceforge.net> <14707.3541.488523.886708@bitdiddle.concentric.net> <397331B3.E12E9F31@prescod.net> <14707.16230.872435.656875@anthem.concentric.net> <39734F26.5799F13D@prescod.net> <14707.22099.762232.325117@anthem.concentric.net> <3973A510.86D2AF54@prescod.net> <14707.52889.135983.472187@anthem.concentric.net> <3973D664.747D3886@prescod.net> Message-ID: <20000717211717.C29590@lyra.org> On Mon, Jul 17, 2000 at 11:00:36PM -0500, Paul Prescod wrote: > "Barry A. Warsaw" wrote: > > > > ... > > > > Yeah, but it's only necessary because CVS doesn't let you do those > > tasks through it's interface. Well, kind of a pointless argument > > because it probably won't change on SF any time soon, and who among us > > is actively hacking on CVS? :) > > I mean CVS stores our information as a bunch of files on a hard disk. > Those files use the Unix UGO security model. You are some one trusted > (one or the other) should be in the PythonAdmins Unix group and you or > that person should be able to physically change files in our directories > using your shell account. "should" != "current state of things" :-) The CVS repositories aren't opened up like that on SF, AFAIK. So yes, "should" is quite true, but that doesn't help us now :-( As Barry said... unless SF changes that policy, then we just deal with it. We could make an SF admin request to torch the nondist/nondist directory from the repository. Cheers, -g -- Greg Stein, http://www.lyra.org/ From moshez at math.huji.ac.il Tue Jul 18 07:54:15 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 08:54:15 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: On Mon, 17 Jul 2000, Barry A. Warsaw wrote: [On the builtin that resembles lambda *args: map(None, *args)] > High bit: Guido strongly prefers zip() as the name of the built-in. > All the suggestions so far have pluses and minuses, and in the absence > of a clear winner, he'd just as soon go with the Haskell name. I > agree. > > Please see the new reference implementation, which includes a > __len__() method, and the discussion of the rejected elaborations. > There's still the open issue of what zip(sequence_a) should return. I'm +1 on that. One thing that bugs me is that we're adding a builtin type. Why not stick with the Python implementation? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Tue Jul 18 08:11:58 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 08:11:58 +0200 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: <200007172357.TAA16970@newcnri.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Mon, Jul 17, 2000 at 07:57:32PM -0400 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: <20000718081158.T7340@xs4all.nl> On Mon, Jul 17, 2000 at 07:57:32PM -0400, Andrew Kuchling wrote: > List comprehensions originated as a patch from Greg Ewing that's now > being kept up-to-date versus the CVS tree by Skip Montanaro. > Originally they weren't on the roadmap for 1.6, but with the greater > version number jump to 2.0, GvR is more willing to incorporate larger > changes. It may be worth mentioning that augmented assignment is also being considered for 2.0, and possibly other operators (we still haven't heard from Guido on that, I believe, and there was at least one +1 from Eric.) Also, maybe the outcome of small CNRI/BeOpen thread would be nice to mention? CNRI says they will release python 1.6, and python 2.0 will probably (possibly ?) be released by BeOpen after that ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From klm at digicool.com Tue Jul 18 08:16:07 2000 From: klm at digicool.com (Ken Manheimer) Date: Tue, 18 Jul 2000 02:16:07 -0400 (EDT) Subject: [Python-Dev] pdbtrack.el - alt approach to emacs-based python debugging Message-ID: <14707.63015.14103.987843@korak.digicool.com> You emacs inhabitants out there may be interested in pdbtrack.el, a little alternative for source-file python debugging in emacs: http://www.zope.org/Wikis/klm/PDBTrack With pdbtrack, whenever you run pdb, emacs tracks (*) the current source file line, centered in another emacs window. It keys on the process output, cuing on the stack trace format and the pdb prompt, so it's pretty unlikely to misfire. That's all it does - it lacks a lot of GUD features, like putting highlighting glyphs on the current line, providing debugging commands from inside the source file buffer, etc. On the other hand, it's also very trim, code-lines-wise - a total of 122 lines, without any GUD connection, and that includes 59 lines that are only for working around a bug in mainline emacs' make-local-hook. (Incorporating the GUD-style features may not be too hard - since it touches the buffer where the debugging was started, as well as the source file buffers, it could set up the necessary state and bindings per session. But i'm not particularly driven to pursue that - tracking the current line in the source file seems to be most of what i need...) The fundamental difference between pdbtrack and GUD/pdb.el is that pdbtrack doesn't require you to launch the debugging session from a particular buffer - it tracks from any comint buffers where you run python. This fits the way i tend to use the debugger - generally, i do more-or-less elaborate interactions with my application *before* i go into the debugger, to set up the context and/or explore my way to the debugging start point. With GUD i have to start the session directly in the debugger. And then, when i finish a GUD session, (i believe) the context is lost. When debugging in a regular shell buffer (and the python-mode py-shell, etc), i drop back into python, wander around, and often launch back into the debugger, with the accumulated state. pdbtrack tracks wherever and whenver you're running pdb in emacs. (I posted more description yesterday to the python and the zope lists: http://www.python.org/pipermail/python-list/2000-July/108654.html ) If this proves to be of general interest and acceptance, i'd love to see it considered for inclusion with python-mode... Ken klm at digicool.com ((*) "whenever you run *pdb*, emacs *tracks*" - that's why i almost called it "zip":->) From thomas at xs4all.net Tue Jul 18 08:16:18 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 08:16:18 +0200 Subject: [Python-Dev] Votes In-Reply-To: <39739295.4AEB5195@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 06:11:17PM -0500 References: <39739295.4AEB5195@prescod.net> Message-ID: <20000718081618.U7340@xs4all.nl> On Mon, Jul 17, 2000 at 06:11:17PM -0500, Paul Prescod wrote: > I'm going to wait for four positive votes or one from Guido before I > take the following action > cd nondist > cvs add sandbox > cd sandbox > cvs add onlinehelp.py > cvs add inspect.py +1. There. You have it ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Tue Jul 18 08:31:52 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 09:31:52 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248257113-63674673@hypernet.com> Message-ID: (assume a = [1, 2, 3]) On Mon, 17 Jul 2000, Gordon McMillan wrote: > How about a fourth: zip(a) is the same as zip(a, []) ? Huh??????????????????? > Look at it this way: what should zip(a, pad=None) return? [(1,), (2,), (3,)], of course > Obviously: [(1, None), (2, None), (3, None)] Why? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Tue Jul 18 08:56:01 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 09:56:01 +0300 (IDT) Subject: [Python-Dev] Votes In-Reply-To: <39739295.4AEB5195@prescod.net> Message-ID: On Mon, 17 Jul 2000, Paul Prescod wrote: > I'm going to wait for four positive votes or one from Guido before I > take the following action > > cd nondist > cvs add sandbox > cd sandbox > cvs add onlinehelp.py > cvs add inspect.py Here's one -- +1 -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From mal at lemburg.com Tue Jul 18 09:48:04 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 18 Jul 2000 09:48:04 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration References: Message-ID: <39740BB3.C80C7CA8@lemburg.com> Moshe Zadka wrote: > > (assume a = [1, 2, 3]) > > On Mon, 17 Jul 2000, Gordon McMillan wrote: > > > How about a fourth: zip(a) is the same as zip(a, []) ? > > Huh??????????????????? I think he meant: zip((a,[])) > > Look at it this way: what should zip(a, pad=None) return? > > [(1,), (2,), (3,)], of course > > > Obviously: [(1, None), (2, None), (3, None)] > > Why? Good question ;-) Here's another one: why should zip() have this special case at all ? I mean, have you ever seen a zipper with only one part ? Ok, there is one-hand clapping, but I wouldn't consider this the normal mode of operation ;-) IMHO, all the special casing does is mask programming errors. And another one: zip() as defined is an operation which is -- in some respects -- the inverse of itself, yet the name does not carry this information. You can't zip a zipper twice. The mathematical operation behind it is called transposition (you view the sequence of sequences as matrix), so in that light the natural name would be transpose()... tranpose(transpose(matrix))) has the same structure as matrix itself. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Tue Jul 18 10:04:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 18 Jul 2000 10:04:05 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <003f01bfefc6$64840540$f2a6b5d4@hagrid> <1248234561-65031149@hypernet.com> Message-ID: <00cd01bff08e$c0849580$f2a6b5d4@hagrid> gordon wrote: > initXXX() (normally) calls Py_InitModule4, so it would be the > one in whatever XXXmodule loaded. exactly my point... so, would this work? Index: Python/modsupport.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/modsupport.c,v retrieving revision 2.48 diff -u -r2.48 modsupport.c --- Python/modsupport.c 2000/07/09 03:09:56 2.48 +++ Python/modsupport.c 2000/07/18 07:55:03 @@ -51,6 +51,8 @@ { PyObject *m, *d, *v; PyMethodDef *ml; + if (!Py_IsInitialized()) + Py_FatalError("Interpreter not initialized (version mismatch?)"); if (module_api_version != PYTHON_API_VERSION) fprintf(stderr, api_version_warning, name, PYTHON_API_VERSION, name, module_api_version); "Fatal Python error: Interpreter not initialized" might not be too helpful, but it's surely better than "PyThreadState_Get: no current thread"... From tim_one at email.msn.com Tue Jul 18 10:00:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 18 Jul 2000 04:00:18 -0400 Subject: [Python-Dev] Will Python die? In-Reply-To: <39736268.306B8DF0@schneider-kamp.de> Message-ID: [Peter Schneider-Kamp] > Tim once (0.9-winking-ly) mentioned the possibility of voting with the > "keyboard by grabbing the Python source and making your own release". > > I don't wanna do this on my own (and get zapped from a lightning bolt > thrown by the powers that are), but what would be the pros and cons > of an inofficial (maybe 1.8?) alpha-in-between-release? I don't see any pros at this time, although I'm typing on my laptop while sitting on the sidewalk in the dark in front of a Howard Johnson's with my hair dripping wet, so Guido can sleep in peace in the room we're sharing, and this after a hellish 12-hour trip to get to the God-forsaken State of California, so I'm not seeing many pros of any kind at the moment . The Python Consortium meeting is this Friday, and the license hassles are on the agenda. While not privy to all the details myself, I can't imagine that any side in this debate can afford to *allow* the impasse to continue longer than that. So I'd advise a bit more patience. I intend to stay all up night, listening for secrets Guido may spill in his sleep. the-con-is-making-a-confused-release-even-more-confused-ly y'rs - tim From mal at lemburg.com Tue Jul 18 10:07:24 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 18 Jul 2000 10:07:24 +0200 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python References: <003f01bfefc6$64840540$f2a6b5d4@hagrid> <1248234561-65031149@hypernet.com> <00cd01bff08e$c0849580$f2a6b5d4@hagrid> Message-ID: <3974103C.AE2D2320@lemburg.com> Fredrik Lundh wrote: > > gordon wrote: > > initXXX() (normally) calls Py_InitModule4, so it would be the > > one in whatever XXXmodule loaded. > > exactly my point... > > so, would this work? Hmm, as I see it this patch would have to be in 1.5.2 to be of any use for the problem mentioned in the subject line: the 1.5 extension links against python15.dll and thus calls the Py_InitModule() of that DLL, not the one in python20.dll which would have the logic below. Anyway, it's a good start for future versions of Python. > Index: Python/modsupport.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Python/modsupport.c,v > retrieving revision 2.48 > diff -u -r2.48 modsupport.c > --- Python/modsupport.c 2000/07/09 03:09:56 2.48 > +++ Python/modsupport.c 2000/07/18 07:55:03 > @@ -51,6 +51,8 @@ > { > PyObject *m, *d, *v; > PyMethodDef *ml; > + if (!Py_IsInitialized()) > + Py_FatalError("Interpreter not initialized (version mismatch?)"); > if (module_api_version != PYTHON_API_VERSION) > fprintf(stderr, api_version_warning, > name, PYTHON_API_VERSION, name, module_api_version); > > "Fatal Python error: Interpreter not initialized" might not be too helpful, > but it's surely better than "PyThreadState_Get: no current thread"... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Tue Jul 18 10:09:59 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 11:09:59 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory In-Reply-To: <14707.54650.959052.870977@anthem.concentric.net> Message-ID: On Mon, 17 Jul 2000, Barry A. Warsaw wrote: > > >>>>> "GS" == Greg Stein writes: > > GS> I'm actively involved with CVS's successor. Does that count? > > GS> :-) > > Only if I get to play with it! Yeah, Greg, what's up with davlib.py? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gstein at lyra.org Tue Jul 18 10:38:25 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 01:38:25 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/nondist - New directory In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 18, 2000 at 11:09:59AM +0300 References: <14707.54650.959052.870977@anthem.concentric.net> Message-ID: <20000718013825.F29590@lyra.org> On Tue, Jul 18, 2000 at 11:09:59AM +0300, Moshe Zadka wrote: > On Mon, 17 Jul 2000, Barry A. Warsaw wrote: > > >>>>> "GS" == Greg Stein writes: > > > > GS> I'm actively involved with CVS's successor. Does that count? > > > > GS> :-) > > > > Only if I get to play with it! > > Yeah, Greg, what's up with davlib.py? Euh. What about it? It is moving along fine. I wouldn't call it stable enough for inclusion into the standard distro, though. What is there is fine, but I think more APIs will be needed to pick up stuff from the new/upcoming DAV extension specs. Cheers, -g p.s. http://subversion.tigris.org/ is the CVS successor I'm talking about -- Greg Stein, http://www.lyra.org/ From peter at schneider-kamp.de Tue Jul 18 12:37:25 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 10:37:25 +0000 Subject: [Python-Dev] Will Python die? References: Message-ID: <39743365.73CC983E@schneider-kamp.de> Tim Peters wrote: > > I don't see any pros at this time, although I'm typing on my laptop while > sitting on the sidewalk in the dark in front of a Howard Johnson's with my > hair dripping wet, so Guido can sleep in peace in the room we're sharing, > and this after a hellish 12-hour trip to get to the God-forsaken State of > California, so I'm not seeing many pros of any kind at the moment . > The Python Consortium meeting is this Friday, and the license hassles are on > the agenda. While not privy to all the details myself, I can't imagine that > any side in this debate can afford to *allow* the impasse to continue longer > than that. Okay, that sounds better than nothing. Meanwhile the question "what happened to 1.6?" starts popping up in c.l.py more often. > So I'd advise a bit more patience. I intend to stay all up night, listening > for secrets Guido may spill in his sleep. Be sure to write a secret transcript of *everything*. We might use it the next time we want to add some special syntax to Python being-more-patient-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From moshez at math.huji.ac.il Tue Jul 18 11:02:30 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 12:02:30 +0300 (IDT) Subject: [Python-Dev] Will Python die? In-Reply-To: Message-ID: On Tue, 18 Jul 2000, Tim Peters wrote: > [Peter Schneider-Kamp] > > Tim once (0.9-winking-ly) mentioned the possibility of voting with the > > "keyboard by grabbing the Python source and making your own release". > > > > I don't wanna do this on my own (and get zapped from a lightning bolt > > thrown by the powers that are), but what would be the pros and cons > > of an inofficial (maybe 1.8?) alpha-in-between-release? > > I don't see any pros at this time I agree with Tim -- your 1.8 would face backwards- and forwards- compatabilitiy issues CVS versions do not have to face. >, although I'm typing on my laptop while > sitting on the sidewalk in the dark in front of a Howard Johnson's with my > hair dripping wet, so Guido can sleep in peace in the room we're sharing, > and this after a hellish 12-hour trip to get to the God-forsaken State of > California, so I'm not seeing many pros of any kind at the moment . Sounds like loads of fun....next you should get into the room and wake up Guido. That should be even more fun. > So I'd advise a bit more patience. I intend to stay all up night, listening > for secrets Guido may spill in his sleep. I don't think you should. there-are-some-things-bots-were-not-meant-to-know-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From peter at schneider-kamp.de Tue Jul 18 13:23:38 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 11:23:38 +0000 Subject: [Python-Dev] PEP 201 - Parallel iteration References: Message-ID: <39743E3A.249212D5@schneider-kamp.de> Ken Manheimer wrote: > > Evan Simpson (a colleague here at digicool, who'd be a good addition > to python-dev) noticed that unzip is unnecessary - zip is its own > inverse. Since this is a worthwhile observation, i'll indulge a bit > and present it in evan's terms - particularly noting a different > packaging that i think is pretty cool, as methods on sequences. Yeah, but this is only true if we let zip() be a sequence method (or a function taking a sequence): for x,y in [[1, 2, 3], [4, 5, 6]].zip(): for x,y in zip([[1, 2, 3], [4, 5, 6]]): for x,y in zip([1, 2, 3], [4, 5, 6]): To be fair I'll do second one: a = [1, 2, 3] b = [4, 5, 6] c = [7, 8, 9] for x,y,z in [a, b, c].zip(): for x,y,z in zip([a, b, c]): for x,y,z in zip(a, b, c): I still think the third form is more explicit, but I am +0 on making zip() a sequence method. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From fredrik at pythonware.com Tue Jul 18 11:46:27 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 18 Jul 2000 11:46:27 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <39743E3A.249212D5@schneider-kamp.de> Message-ID: <011701bff09d$0bc5b020$0900a8c0@SPIFF> peter wrote: > I still think the third form is more explicit, but I am > +0 on making zip() a sequence method. Remember the "string join" debate? There is no sequence base class in Python (it's an informal inter- face, not a type), so where would you put that method? As specified, "zip" has a *single* implementation which takes any number of objects implementing the sequence interface, and return an object implementing the same interface. Can it be much simpler? -1 on a method. Python is moving towards more genericness (if you accept an integer/sequence/string, you should be able to deal with any kind of integer/sequence/string). Adding a method would be a move in the opposite direction. From jack at oratrix.nl Tue Jul 18 11:54:26 2000 From: jack at oratrix.nl (Jack Jansen) Date: Tue, 18 Jul 2000 11:54:26 +0200 Subject: [Python-Dev] ascii default encoding In-Reply-To: Message by "Fredrik Lundh" , Mon, 17 Jul 2000 00:35:56 +0200 , <008501bfef76$362902e0$f2a6b5d4@hagrid> Message-ID: <20000718095427.0F3CE37186D@snelboot.oratrix.nl> > > On the Macintosh string.whitespace is '\011\012\013\014\015 \312', but > > the \312 causes problems because it can't be converted from/to unicode > > as long as the default encoding is ascii... > > on windows and unix boxes, the default locale is "posix" (aka "C"), > which in practice means "plain ascii". the only way to end up with > non-ascii characters in whitespace/uppercase/lowercase/etc is to > explicitly change the locale (by calling locale.setlocale). On the Mac, under CodeWarrior, the default locale (and, actually, the only locale) is "C", and it uses the mac-roman charset, so including the upper 128 characters. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From thomas at xs4all.net Tue Jul 18 11:59:47 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 11:59:47 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <39743E3A.249212D5@schneider-kamp.de>; from peter@schneider-kamp.de on Tue, Jul 18, 2000 at 11:23:38AM +0000 References: <39743E3A.249212D5@schneider-kamp.de> Message-ID: <20000718115947.Y7340@xs4all.nl> On Tue, Jul 18, 2000 at 11:23:38AM +0000, Peter Schneider-Kamp wrote: > Ken Manheimer wrote: > > Evan Simpson (a colleague here at digicool, who'd be a good addition > > to python-dev) noticed that unzip is unnecessary - zip is its own > > inverse. Since this is a worthwhile observation, i'll indulge a bit > > and present it in evan's terms - particularly noting a different > > packaging that i think is pretty cool, as methods on sequences. > for x,y,z in [a, b, c].zip(): -1. Completely counter-intuitive, in my opinion... It would be nice if having a list of lists to marry() is a common operation, but I doubt it is. Having to create one just for the sake of zip() looks silly to me. > for x,y,z in zip([a, b, c]): -1. What's the point ? What's the difference ? What would 'zip([a,b,c],[d,e,f])' do ? > for x,y,z in zip(a, b, c): Still +0 on this. I still prefer the altered syntax 'for' loop :-) And marry() over zip(). But I can live with this. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Tue Jul 18 12:18:31 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 12:18:31 +0200 Subject: [Python-Dev] PEP 204 - Range Literals Message-ID: <20000718121831.A7340@xs4all.nl> I've attached the first draft of PEP 204, Range Literals, which I just uploaded to CVS as well. If anyone finds time to review it, or the proposed implementation (patch #100902 on SourceForge) please do. I'm not sure what to do with the patch... Guido said as much as 'apply it'(*), but I doubt anyone really looked at it yet ;) I wrote this using 'joe', which is still my favorite editor, because despite many, many minutes of effort, xemacs simply refused to do what I wanted it to do. How do you 're-flow' a paragraph, for instance, or enable word wrapping, or better yet: word wrapping with autoindentation ? If anyone has a quick-and-dirty howto on [x]emacs, feel free to share ;) (* In http://www.python.org/pipermail/python-dev/2000-July/013234.html) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pep-0204.txt URL: From fredrik at pythonware.com Tue Jul 18 12:21:54 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 18 Jul 2000 12:21:54 +0200 Subject: [Python-Dev] ascii default encoding References: <20000718095427.0F3CE37186D@snelboot.oratrix.nl> Message-ID: <013501bff0a1$ff35cca0$0900a8c0@SPIFF> jack wrote: > On the Mac, under CodeWarrior, the default locale (and, actually, the only > locale) is "C", and it uses the mac-roman charset, so including the upper 128 > characters. I could have sworn that the "C" locale only included characters in the ASCII range [1], but a more careful reading of the specification indicates that the behaviour is only *defined* for characters in the ASCII range... two alternatives: -- limit the string constants to the portable range (0..127). if you want more characters, you have to explicitly call locale.setlocale(..., "C"). -- leave it as it is. this means that code that does things like "if char in string.whitespace" will break if char is unicode, and you're running on a mac. on second thought, it's probably better to just fix mixed string com- parisions... (so that instead of throwing an exception, unichr(202) will simply be != chr(202)...) 1) not quite true: the portable character set only lists all characters in the ASCII character set, it doesn't define what code points they should use. From thomas at xs4all.net Tue Jul 18 13:00:59 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 13:00:59 +0200 Subject: [Python-Dev] Patches Message-ID: <20000718130059.B7340@xs4all.nl> Now that everyone of importance is off to sunny California, how about we put some of the patches that have been idling on the SF PM to the vote ? If Barry objects we can always organize some gigs for him away from the 'office' ;) I'd personally like to hear some votes/opinions on the range literal patch, but it seems to me there are others that only require some voting and second opinions: - Add 'isatty(fd)' to posixmodule. Do Macs and Windows machines have an isatty() function that makes sense to include ? - Better error message with UnboundLocalError Patch looks okay to me, and Tim already said he liked the idea. - arraymodule: adding count, extend, index, pop, remove I believe there was some discussion about this before, don't know the outcome. - new EXTENDED_ARG opcode, elimiate 16-bit oparg limit Probably needs Guido and/or Tim decreeing whether the change is worth it - safe version of PyErr_Format +0 on that, but what do I know. Don't know if it's actually safe ;) - Optional pad character for rjust, ljust Definately +1, but I have a nagging feeling there is a better way to do it: Why wasn't this implemented before ? What are people using instead of string.rjust(string, padchar) ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm at hypernet.com Tue Jul 18 14:26:02 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 18 Jul 2000 08:26:02 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <39740BB3.C80C7CA8@lemburg.com> Message-ID: <1248199317-67151042@hypernet.com> M.-A. Lemburg wrote: > Moshe Zadka wrote: > > > > (assume a = [1, 2, 3]) > > > > On Mon, 17 Jul 2000, Gordon McMillan wrote: > > > > > How about a fourth: zip(a) is the same as zip(a, []) ? > > > > Huh??????????????????? > > I think he meant: zip((a,[])) No I didn't. Sigh. >>pad([1,2,3], [1], pad=None) [(1,1), (2,None), (3,None)] >>pad([1,2,3], [], pad=None) [(1,None), (2,None), (3,None)] (If you don't agree with that, you don't agree with the PEP). So I'm proposing that the 2nd positional arg, if not present, be treated as []. That makes: >>zip([1,2,3], pad=None) [(1,None), (2,None), (3,None) >>zip([1,2,3]) [] The other possibility is to make Evan Simpson's dream come true, so >>zip([(1,None), (2,None), (3,None)]) [[1,2,3],[None,None,None]] But then you'd have to throw an exception if the (single) arg wasn't a rectangular sequence of sequences. Also, since lately Guido's on a kick to get rid of auto-tupling/untupling of args, I think you need to use apply(zip, tuple(...)) or the *args syntax to accomplish this. > Here's another one: why should zip() have this special case > at all ? I mean, have you ever seen a zipper with only one > part ? Ok, there is one-hand clapping, but I wouldn't consider > this the normal mode of operation ;-) IMHO, all the special > casing does is mask programming errors. Which doesn't answer the question posed in the PEP. All of the proposed responses are special cases. The one I've seen mentioned most often: >>zip([1,2,3]) [(1,),(2,),(3,)] is very much as special case, as you can see if you ask "what happens when I add a pad arg?". However, if the dev list is having so much trouble deciding how it should decay, I'll vote for throwing an exception. > And another one: zip() as defined is an operation which is -- in > some respects -- the inverse of itself, yet the name does not > carry this information. You can't zip a zipper twice. The > mathematical operation behind it is called transposition (you > view the sequence of sequences as matrix), so in that light the > natural name would be transpose()... tranpose(transpose(matrix))) > has the same structure as matrix itself. But zip takes some number of sequences, not necessarily of the same length. That's not a matrix. I think if you go that route, the user has to first insure they're all the same length and then package them into a sequence. It might have its uses, but not as a replacement for map(None, ...). - Gordon From gmcm at hypernet.com Tue Jul 18 14:26:02 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 18 Jul 2000 08:26:02 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: References: <1248257113-63674673@hypernet.com> Message-ID: <1248199315-67151142@hypernet.com> Moshe Zadka wrote: > (assume a = [1, 2, 3]) > > On Mon, 17 Jul 2000, Gordon McMillan wrote: > > > How about a fourth: zip(a) is the same as zip(a, []) ? > > Huh??????????????????? > > > Look at it this way: what should zip(a, pad=None) return? > > [(1,), (2,), (3,)], of course Then why does the PEP say: >>> zip(a, b, c, d, pad=None) [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)] >>> map(None, a, b, c, d) [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)] If you want no padding, you don't specify a pad arg. pad=None means "pad with None". > > Obviously: [(1, None), (2, None), (3, None)] > > Why? To be consistent. - Gordon From moshez at math.huji.ac.il Tue Jul 18 15:18:03 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 16:18:03 +0300 (IDT) Subject: [Python-Dev] Patches In-Reply-To: <20000718130059.B7340@xs4all.nl> Message-ID: On Tue, 18 Jul 2000, Thomas Wouters wrote: > Now that everyone of importance is off to sunny California, how about we put > some of the patches that have been idling on the SF PM to the vote ? If > Barry objects we can always organize some gigs for him away from the > 'office' ;) Or we can unleash Gordon upon him...seems to be the only thing which strikes terror into his heart (after meeting Gordon, I can understand why) > I'd personally like to hear some votes/opinions on the range literal patch, Didn't Guido urge you to check it in? > - Add 'isatty(fd)' to posixmodule. +1 on that > - Better error message with UnboundLocalError > Patch looks okay to me, and Tim already said he liked the idea. But it seems he had a quibble with the style -- so it's better to wait until he approves. I think we *should* assign it to him, and bug him about it. Any other opinions? > - arraymodule: adding count, extend, index, pop, remove > I believe there was some discussion about this before, don't know the > outcome. I'm +1, but I remember Tim and Guido had something to say about it, so it's safest to wait for them > - new EXTENDED_ARG opcode, elimiate 16-bit oparg limit > Probably needs Guido and/or Tim decreeing whether the change is worth it Agreed > - safe version of PyErr_Format > +0 on that, but what do I know. Don't know if it's actually safe ;) I'm +1. As far as I could read, it is safe. That's the safest we can get without serious stress-tests. This, again, brings up the problem of regression testing for APIs, which is a different topic. (Anyone wants to PEP it?) > - Optional pad character for rjust, ljust > Definately +1, but I have a nagging feeling there is a better way to do it: > Why wasn't this implemented before ? What are people using instead of > string.rjust(string, padchar) ? Probably hand calculations: l = len(s) return s+'p'*(just-l) It's possible.... In fact, putting an implementation of pad() like that in the string.py module would be wonderful, because it would work with both regular strings and unicode. However, string.py is looking as though as it's going to be deprecated. In short, I'd want Guido/Tim/effbot/MAL opinions here before we make a move. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From peter at schneider-kamp.de Tue Jul 18 16:21:59 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 14:21:59 +0000 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> Message-ID: <39746807.DFA2B329@schneider-kamp.de> Thomas Wouters wrote: > > Now that everyone of importance is off to sunny California, how about we put > some of the patches that have been idling on the SF PM to the vote ? If > Barry objects we can always organize some gigs for him away from the > 'office' ;) I am +0 on voting. I don't like the silence on the checkins mailing list. > I'd personally like to hear some votes/opinions on the range literal patch, > but it seems to me there are others that only require some voting and second > opinions: Wasn't there a decision from the BDFL? > - arraymodule: adding count, extend, index, pop, remove > I believe there was some discussion about this before, don't know the > outcome. Guido said something like (hope I got it right): count, index and remove should be implemented in a faster way, but that would take a lot more code and not be worth it. who would use index, count and remove on arrays anyway? so better leave them out, pop is okay though. extend would be worth adding. Tim said something like (hope I got this one right, too): better to have count, index and remove at all than not to have them. I would use them. I interpret that as a -0 from Guido and a +1 from Tim, but - as always - YMMV. My opinion is that an array is only really useful if it supports as much of the list interface as possible. As I understand things arrays are lists where you trade the ability to store any element against some increase in speed. For the slow count, index and remove functions I have three proposals (in order of decreasing appeal to me): 1) just put em in, they are in any case not slower than the Python code you would use to emulate them. +1 2) put them in and add some warnings to the docs that say they are slow. +0 3) do it the fast way. that would be a lot of work and - as Guido pointed out - probably not worth it. I'd do it if it was neccessary though. -0 > - safe version of PyErr_Format > +0 on that, but what do I know. Don't know if it's actually safe ;) -0 on that, I'd rather use snprintf when available, sprintf when not. > - Optional pad character for rjust, ljust > Definately +1, but I have a nagging feeling there is a better way to do it: > Why wasn't this implemented before ? What are people using instead of > string.rjust(string, padchar) ? +1 in any case, but I think we should wait for the new version which supports padstrings, too. also I think there is still no docs/test cases. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From moshez at math.huji.ac.il Tue Jul 18 14:34:38 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 15:34:38 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248199315-67151142@hypernet.com> Message-ID: On Tue, 18 Jul 2000, Gordon McMillan wrote: [about zip(a, pad=None) ] > > > Obviously: [(1, None), (2, None), (3, None)] > > > > Why? > > To be consistent. But when there is only one list, all lists are of the same size, so the pad argument is moot. (Consistent with all other cases where all lists are the same size) Or maybe we're talking about a different situation? Can you show a fake Python session which demonstrates your point? confused-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Tue Jul 18 15:33:48 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 15:33:48 +0200 Subject: [Python-Dev] Patches In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 18, 2000 at 04:18:03PM +0300 References: <20000718130059.B7340@xs4all.nl> Message-ID: <20000718153348.B7345@xs4all.nl> On Tue, Jul 18, 2000 at 04:18:03PM +0300, Moshe Zadka wrote: > On Tue, 18 Jul 2000, Thomas Wouters wrote: > > I'd personally like to hear some votes/opinions on the range literal patch, > Didn't Guido urge you to check it in? I have *no* idea :) The 'Right!' seemed to imply that, but I doubt he'd let me check it in without *someone* reviewing it ;) > > - Better error message with UnboundLocalError > > Patch looks okay to me, and Tim already said he liked the idea. > But it seems he had a quibble with the style -- so it's better to wait > until he approves. I think we *should* assign it to him, and bug him > about it. Any other opinions? The style issue is history. The new version is style-conforming, I think, asside from a small bug in the definition of the helper function (see the comment, Paul ;) That doesn't mean Tim shouldn't check it first, though. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Tue Jul 18 15:44:01 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 16:44:01 +0300 (IDT) Subject: [Python-Dev] posixpath.normpath Message-ID: Simple question: what should a) posixpath.normpath("..") b) posixpath.normpath("/..") return? Anyone? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From peter at schneider-kamp.de Tue Jul 18 17:44:04 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 15:44:04 +0000 Subject: [Python-Dev] Will Python die? References: Message-ID: <39747B44.4284A38B@schneider-kamp.de> Moshe Zadka wrote: > > I agree with Tim -- your 1.8 would face backwards- and forwards- > compatabilitiy issues CVS versions do not have to face. I basically agree. An official release would be a Bad Thing(TM). But at least some information should leak to the masses to prevent slashdot threads like that: http://slashdot.org/comments.pl?sid=00/07/17/0312221&threshold=-1&commentsort=0&mode=flat&cid=41 Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From moshez at math.huji.ac.il Tue Jul 18 15:46:07 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 16:46:07 +0300 (IDT) Subject: [Python-Dev] Will Python die? In-Reply-To: <39747B44.4284A38B@schneider-kamp.de> Message-ID: On Tue, 18 Jul 2000, Peter Schneider-Kamp wrote: > But at least some information should leak to the masses to prevent > slashdot threads like that: > > http://slashdot.org/comments.pl?sid=00/07/17/0312221&threshold=-1&commentsort=0&mode=flat&cid=41 My fault -- I stopped reading /. Can you summarize the thread? -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From peter at schneider-kamp.de Tue Jul 18 18:06:37 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Tue, 18 Jul 2000 16:06:37 +0000 Subject: [Python-Dev] Will Python die? References: Message-ID: <3974808D.5D49575D@schneider-kamp.de> Moshe Zadka wrote: > > My fault -- I stopped reading /. Can you summarize the thread? The thread is about if Visual Python is an alternative for Visual Basic or, if not, it can be used as that. A subthread of this thread dealt with Pythons release schedule: "Speaking of Python, does anyone know what's up with Python 1.6^H^H2.0? A while back, python.org had said that version 1.6 would be out on June 1. Then there was an announcement, mid-June that it would be delayed. Then at the end of June, this link was placed on python.org, and it was stated that the Python interpreter, version 1.6, was renamed to 2.0, and the first beta would be available on July 1. Now, on July 17, that link has been removed from python.org (although the webpage still exists), and the release schedule is gone!" Quoting from relevant replies: "python 1.6 will be out in august check the downloads page of www.python.org or checkout the pythonlabs at www.beopen.com where most of the core python developers opened shop" "Yeah, the Python 1.6 download page says that Python 1.6 beta1 will be done on July 1, and beta 2 on July 14. It's July 17 now, and the only available download is alpha 2...." read-what-you-want-from-that-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gvwilson at nevex.com Tue Jul 18 16:11:30 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 18 Jul 2000 10:11:30 -0400 (EDT) Subject: [Python-Dev] Re: PEP 201 - Parallel iteration In-Reply-To: <200007172015.WAA25033@python.inrialpes.fr> Message-ID: I realize it's late in the day, but could the name of the concept (not the function) be changed from "parallel iteration" to something that doesn't imply concurrent execution quite so strongly? I think the use of "parallel" is very likely to mislead, particularly scientists and engineers who actually have parallel loops in their jumped-up Fortran and C++ systems. Thanks, Greg From akuchlin at cnri.reston.va.us Tue Jul 18 16:13:21 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 18 Jul 2000 10:13:21 -0400 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: ; from pingster@ilm.com on Mon, Jul 17, 2000 at 07:37:08PM -0700 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> Message-ID: <20000718101321.D21354@newcnri.cnri.reston.va.us> Thanks to everyone who made some suggestions. The more minor edits have been made, but I haven't added any of the threads I missed because doing a long stretch of Emacs editing in this lame Windows terminal program will drive me insane, so I just posted the summary to python-list. How is it possible for Microsoft to not get a VT100-compatible terminal program working correctly? VT100s have been around since, when, the 1970s? Can anyone suggest a Windows terminal program that *doesn't* suck dead bunnies through a straw? --amk From skip at mojam.com Tue Jul 18 16:18:31 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 18 Jul 2000 09:18:31 -0500 (CDT) Subject: [Python-Dev] Patches In-Reply-To: <20000718130059.B7340@xs4all.nl> References: <20000718130059.B7340@xs4all.nl> Message-ID: <14708.26423.536040.581684@beluga.mojam.com> Thomas> Now that everyone of importance is off to sunny California, how Thomas> about we put some of the patches that have been idling on the SF Thomas> PM to the vote ? As someone who has been assigned some patches that are still open (isatty, normpath fix, history functions for readline), I'm still pretty much in the dark about what my rights and responsibilities are. Am I supposed to eyeball a patch and check it in if it looks okay (compiles, doesn't break "make test", etc)? Am I supposed to bring it up for discussion on python-dev? Something entirely different (blow up a bush, perhaps)? I just submitted a feature request for the patch manager at SF. I asked for the following: 1. better selection/exclusion predicates for the filtering function 2. filtering based on assignee/submitter 3. display of a patch's state in the table If you'd like to review it and add your own two cents, it's at https://sourceforge.net/forum/message.php?msg_id=41288 Skip From gvwilson at nevex.com Tue Jul 18 16:36:02 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 18 Jul 2000 10:36:02 -0400 (EDT) Subject: [Python-Dev] CVS / Subversion / language choice In-Reply-To: <3973A510.86D2AF54@prescod.net> Message-ID: > > Welcome to CVS. What did Greg Wilson say at IPC8? Paraphrasing: CVS > > is the worst tool everybody uses. :) "CVS is the suckiest tool that developers have to use on a daily basis." (It was actually one of my students at Los Alamos --- and it was one of the few times there's been a round of applause in a class I've taught :-). BTW, if you haven't seen Subversion: http://subversion.tigris.org It's worth checking out (if only to see what's keeping Greg Stein off the streets and out of trouble). The project's aim is to produce a "better CVS", i.e. fix some of the known warts, and web-enable it using WebDAV. I like their goals (fairly conservative, but therefore also fairly likely to be accepted), and their use of ASCII art in PDFs :-). The thing that surprised me was their decision to do their first implementation in C, rather than getting something together quickly in a scripting language, and then re-writing modules for performance when/as necessary. I asked Brian Behlendorf about this; he said the reasons were: > ...we're focusing on C in the short run is to take away any religious > wars concerning python vs java vs perl - C, as crappy as it is, is > still a pretty neutral language when it comes to deployment, as > everyone has a C compiler but not everyone wants to install python. > Also, the server side will mostly consist of an Apache plugin and a > driver for the actual database format, so keeping it all in C and all > in the same process is attractive. > > Also, the developers I've got working on it are very comfortable in C, > and I'm trusting that they considered it and elected to just write in > C directly. These were pretty much the same reasons Larry McVoy gave me when I asked him why BitKeeper was using C rather than a scripting language. I'd be interested in knowing whether this attitude is still the norm, or whether there is evidence of a general shift toward the prototyping/filling-in model. I have a progress report to write for Software Carpentry, and... (In the interests of conserving bandwidth, please reply directly; I'll summarize and re-post if there's sufficient interest.) Thanks, Greg From thomas at xs4all.net Tue Jul 18 16:42:24 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 16:42:24 +0200 Subject: [Python-Dev] Patches In-Reply-To: <14708.26423.536040.581684@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 18, 2000 at 09:18:31AM -0500 References: <20000718130059.B7340@xs4all.nl> <14708.26423.536040.581684@beluga.mojam.com> Message-ID: <20000718164224.D7345@xs4all.nl> On Tue, Jul 18, 2000 at 09:18:31AM -0500, Skip Montanaro wrote: > Thomas> Now that everyone of importance is off to sunny California, how > Thomas> about we put some of the patches that have been idling on the SF > Thomas> PM to the vote ? > As someone who has been assigned some patches that are still open (isatty, > normpath fix, history functions for readline), Don't forget: you can assign them to someone else if you feel you have too much, or if you aren't the right person, or just don't feel like dealing with that patch. > I'm still pretty much in the dark about what my rights and > responsibilities are. Am I supposed to eyeball a patch and check it in if > it looks okay (compiles, doesn't break "make test", etc)? Yes, at the least. Also whether it complies to coding style, includes a test (when necessary), etc. > Am I supposed to bring it up for discussion on > python-dev? Possibly. I donno. That used to be done on patches, I gather, but that list is kind of defunct, now. That's partly why I wrote the first posting in this thread, to bring some of those patches to attention. I don't think you're intended to be the Guardian Angel of those patches, though, just the one checking them out. If you aren't sure, post here (or patches at python.org), I guess. If you can't figure out what to do, assign it to Tim. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From esr at thyrsus.com Tue Jul 18 18:36:31 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jul 2000 12:36:31 -0400 Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <20000718171739.F7345@xs4all.nl> References: <20000718121831.A7340@xs4all.nl> <20000718110823.B10480@thyrsus.com> <20000718171739.F7345@xs4all.nl> Message-ID: <20000718123631.B10741@thyrsus.com> Thomas Wouters : > Well, I guess I agree. The above was just a bit of 'Red Red Wine' induced > brainstorm, but on reflection it does seem logical. The one-dimensionality > of range and xrange always bothered me ;) The biggest problem is, however, > how to create a 'range' of a specific type of object, given a start, step > and end object. A new PyNumberMethods member 'int_range' ? Or some kind of > 'newobject_fromnumber' protocol ? Let's worry about that later. For now, throwing an exception is OK. > How about we checkin the current patch, which does what the PEP describes, > and continue the PEP for the sake of these issues ? :) +1. -- Eric S. Raymond If I were to select a jack-booted group of fascists who are perhaps as large a danger to American society as I could pick today, I would pick BATF [the Bureau of Alcohol, Tobacco, and Firearms]. -- U.S. Representative John Dingell, 1980 From skip at mojam.com Tue Jul 18 20:55:01 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 18 Jul 2000 13:55:01 -0500 (CDT) Subject: [Python-Dev] what happened with the python-list addresses? Message-ID: <14708.43013.274067.569324@beluga.mojam.com> I don't want to create a storm on c.l.py, so I post here. I noticed a bunch of "email addresses" that look like "aahz at netcom.com.bbs@openbazaar.net" in recent digests. Is there some sort of runaway gateway? Who is openbazaar.net? Sounds like something ESR would be involved with, though I can't reach an obvious web site in that domain and they appear to be located in Taiwan. Skip From skip at mojam.com Tue Jul 18 16:19:51 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 18 Jul 2000 09:19:51 -0500 (CDT) Subject: [Python-Dev] Patches In-Reply-To: <20000718130059.B7340@xs4all.nl> References: <20000718130059.B7340@xs4all.nl> Message-ID: <14708.26503.552322.616643@beluga.mojam.com> Thomas> - Optional pad character for rjust, ljust Thomas> Definately +1, but I have a nagging feeling there is a better Thomas> way to do it: Why wasn't this implemented before ? What are Thomas> people using instead of string.rjust(string, padchar) ? Perhaps it's just obscure (to me). I don't believe I've ever used [lr]just. Skip From esr at thyrsus.com Tue Jul 18 17:08:23 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jul 2000 11:08:23 -0400 Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <20000718121831.A7340@xs4all.nl> References: <20000718121831.A7340@xs4all.nl> Message-ID: <20000718110823.B10480@thyrsus.com> Thomas Wouters : > I wrote this using 'joe', which is still my favorite editor, because despite > many, many minutes of effort, xemacs simply refused to do what I wanted it > to do. How do you 're-flow' a paragraph, Esc-g > for instance, or enable word > wrapping, or better yet: word wrapping with autoindentation ? Esc-x set-variable auto-fill 1 To always enable it in text mode, add (setq text-mode-hook '(lambda () (auto-fill-mode 1))) to your .emacs file. Emacs will detect your indent level and honor it. > One possible solution to the discrepancy of requiring the `end' > argument in range literals is to allow the range syntax to create > a `generator', rather than a list, such as the `xrange' builtin > function does. However, a generator would not be a list, and it > would be impossible, for instance, to assign to items in the > generator, or append to it. Not so. Appending to the generator object, or assigning to it, would simply force eager rather than lazy evaluation of the generator. This would have to throw an exception on infinite generators. But all this is academic until Python has continuations, really. For finite cases eager vs. lazy only makes a difference in the timing of computations, not their result. While this could be semantically significant for some list comprehensions, it won't be for range literals. (You might want to go look at Haskell or Icon to learn more about how lazy and eager evaluation interact.) > Should it be possible to mix range syntax with normal list > literals, creating a single list, like so: > > >>> [5, 6, 1:6, 7, 9] > to create > [5, 6, 1, 2, 3, 4, 5, 7, 9] I'm completely neutral on this. > However, as the syntax and semantics of list comprehensions are > still subject of hot debate, these issues are probably best > addressed by the `list comprehensions' PEP. Agreed. > Range literals accept objects other than integers: it performs > PyInt_AsLong() on the objects passed in, so as long as the objects > can be coerced into integers, they will be accepted. The > resulting list, however, is always composed of standard integers. > > Should range literals create a list of the passed-in type ? It > might be desirable in the cases of other builtin types, such as > longs and strings: > > >>> [ 1L : 2L<<64 : 2<<32L ] > >>> ["a":"z":"b"] > >>> ["a":"z":2] > > However, this might be too much `magic' to be obvious. It might > also present problems with user-defined classes: even if the base > class can be found and a new instance created, the instance may > require additional arguments to __init__, causing the creation to > fail. +1. Whenever possible, builtins ought to do something intuitive with any type that is passed in, and range literals have an obvious and intuitive definition for any well-ordered base type. I think it would be more surprising if this did *not* work for well-ordered scalar types. I don't view the issue for user-defined classes as a showstopper; it would be OK, and semantically reasonable, to throw an exception in this case. > The PyList_FromRange() and PyList_GetLenOfRange() functions need > to be classified: are they part of the API, or should they be made > private functions ? No opinion. -- Eric S. Raymond ...the Federal Judiciary...an irresponsible body, working like gravity by night and by day, gaining a little today and a little tomorrow, and advancing its noiseless step like a thief over the field of jurisdiction until all shall be usurped from the States; and the government of all be consolidated into one. From esr at thyrsus.com Tue Jul 18 17:11:57 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jul 2000 11:11:57 -0400 Subject: [Python-Dev] Patches In-Reply-To: <20000718130059.B7340@xs4all.nl> References: <20000718130059.B7340@xs4all.nl> Message-ID: <20000718111157.C10480@thyrsus.com> Thomas Wouters : > I'd personally like to hear some votes/opinions on the range literal patch, > but it seems to me there are others that only require some voting and second > opinions: I just posted a detailed response on that. > - Add 'isatty(fd)' to posixmodule. > Do Macs and Windows machines have an isatty() function that makes sense to > include ? Unknown to me. I'm +1 on adding this anyway. > - Better error message with UnboundLocalError > Patch looks okay to me, and Tim already said he liked the idea. +0. > - arraymodule: adding count, extend, index, pop, remove > I believe there was some discussion about this before, don't know the > outcome. Is there a PEP? I suspect from looking at the names that I would be +0 on this, but I wonder why pop() and no push()? > - new EXTENDED_ARG opcode, elimiate 16-bit oparg limit > Probably needs Guido and/or Tim decreeing whether the change is worth it > > - safe version of PyErr_Format > +0 on that, but what do I know. Don't know if it's actually safe ;) > > - Optional pad character for rjust, ljust > Definately +1, but I have a nagging feeling there is a better way to do it: > Why wasn't this implemented before ? What are people using instead of > string.rjust(string, padchar) ? No opinion on these. -- Eric S. Raymond He that would make his own liberty secure must guard even his enemy from oppression: for if he violates this duty, he establishes a precedent that will reach unto himself. -- Thomas Paine From thomas at xs4all.net Tue Jul 18 16:59:46 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 16:59:46 +0200 Subject: [Python-Dev] Patches In-Reply-To: <20000718111157.C10480@thyrsus.com>; from esr@thyrsus.com on Tue, Jul 18, 2000 at 11:11:57AM -0400 References: <20000718130059.B7340@xs4all.nl> <20000718111157.C10480@thyrsus.com> Message-ID: <20000718165945.E7345@xs4all.nl> On Tue, Jul 18, 2000 at 11:11:57AM -0400, esr at thyrsus.com wrote: > > - arraymodule: adding count, extend, index, pop, remove > > I believe there was some discussion about this before, don't know the > > outcome. > > Is there a PEP? I suspect from looking at the names that I would > be +0 on this, but I wonder why pop() and no push()? No PEP, it's pre-PEP. The methods names are not in question, because they mirror the current *list* method names ;) and push() is spelled 'append()' in Python. Here's what pop() does: >>> x = [1,2,3,4,5] >>> x.pop() 5 >>> x [1, 2, 3, 4] The question is mostly whether count(), index() and maybe remove() are worth adding to the arrayobject, given their inefficient implementation. (An efficient implementation would require a fair bit of code, but on the plus side, that same code could then be used for 'sq_contains', which currently is appallingly inefficient.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Tue Jul 18 18:00:31 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 18 Jul 2000 19:00:31 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248199317-67151042@hypernet.com> Message-ID: On Tue, 18 Jul 2000, Gordon McMillan wrote: > (If you don't agree with that, you don't agree with the PEP). I agree with that. Luckily, I've snipped it, so it's not valid as evidence > So I'm proposing that the 2nd positional arg, if not present, be > treated as []. That makes: That's a special case! > Which doesn't answer the question posed in the PEP. All of > the proposed responses are special cases. The one I've seen > mentioned most often: > >>zip([1,2,3]) > [(1,),(2,),(3,)] > is very much as special case, as you can see if you ask > "what happens when I add a pad arg?". I disagree: you agree that if you add a pad argument when the lists are all the same size it doesn't matter (if you don't agree with this, you don't agree with the PEP). Now, when there is only one list, the lists are all the same size. QED. > However, if the dev list is having so much trouble deciding how > it should decay, I'll vote for throwing an exception. I'm starting to agree -- I'm thinking like a mathematician, which not everyone in the world are (sadly) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Tue Jul 18 17:17:39 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 17:17:39 +0200 Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <20000718110823.B10480@thyrsus.com>; from esr@thyrsus.com on Tue, Jul 18, 2000 at 11:08:23AM -0400 References: <20000718121831.A7340@xs4all.nl> <20000718110823.B10480@thyrsus.com> Message-ID: <20000718171739.F7345@xs4all.nl> On Tue, Jul 18, 2000 at 11:08:23AM -0400, esr at thyrsus.com wrote: > Thomas Wouters : > > One possible solution to the discrepancy of requiring the `end' > > argument in range literals is to allow the range syntax to create > > a `generator', rather than a list, such as the `xrange' builtin > > function does. However, a generator would not be a list, and it > > would be impossible, for instance, to assign to items in the > > generator, or append to it. > Not so. Appending to the generator object, or assigning to it, would > simply force eager rather than lazy evaluation of the generator. This > would have to throw an exception on infinite generators. > (You might want to go look at Haskell or Icon to learn more about > how lazy and eager evaluation interact.) Well, I had an xrange() like generator in mind. There currently isn't a very good way for a generator to turn itself into a list, unless it's some kind of polymorphic object that behaves one way until it gets assigned to... In which case I wouldn't want to meet it in a dark alley, alone, at night, without my language reference printout. I don't have the human resources to do an in-depth study of generators (or other languages) right now. The idiots I have to cooperate with at work (from our parent company) are sucking all life out of me, in a bad way ;P > > Should range literals create a list of the passed-in type ? It > > might be desirable in the cases of other builtin types, such as > > longs and strings: [..] > > However, this might be too much `magic' to be obvious. It might > > also present problems with user-defined classes: even if the base > > class can be found and a new instance created, the instance may > > require additional arguments to __init__, causing the creation to > > fail. > +1. Whenever possible, builtins ought to do something intuitive with > any type that is passed in, and range literals have an obvious and > intuitive definition for any well-ordered base type. I think it > would be more surprising if this did *not* work for well-ordered > scalar types. Well, I guess I agree. The above was just a bit of 'Red Red Wine' induced brainstorm, but on reflection it does seem logical. The one-dimensionality of range and xrange always bothered me ;) The biggest problem is, however, how to create a 'range' of a specific type of object, given a start, step and end object. A new PyNumberMethods member 'int_range' ? Or some kind of 'newobject_fromnumber' protocol ? How about we checkin the current patch, which does what the PEP describes, and continue the PEP for the sake of these issues ? :) > I don't view the issue for user-defined classes as a showstopper; > it would be OK, and semantically reasonable, to throw an exception > in this case. Agreed. And thanx for the emacs pointers ! :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Tue Jul 18 20:07:58 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 18 Jul 2000 13:07:58 -0500 (CDT) Subject: [Python-Dev] Patches In-Reply-To: References: <20000718130059.B7340@xs4all.nl> Message-ID: <14708.40190.852802.966575@beluga.mojam.com> Moshe> In fact, putting an implementation of pad() like that in the Moshe> string.py module would be wonderful, because it would work with Moshe> both regular strings and unicode. However, string.py is looking Moshe> as though as it's going to be deprecated. In short, I'd want Moshe> Guido/Tim/effbot/MAL opinions here before we make a move. Don't know about the powers that be, but I don't see how you can realistically deprecate string.py until you deprecate map(). My most frequent use of map() is the simple newlist = map(string.strip, oldlist) where oldlist is a list of strings. (Replace "strip" by "upper", "lower", etc, depending on your needs.) As far as I'm aware, there's no clean way to do that with string methods. Skip From effbot at telia.com Tue Jul 18 21:37:39 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 18 Jul 2000 21:37:39 +0200 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> Message-ID: <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> > > - safe version of PyErr_Format > > +0 on that, but what do I know. Don't know if it's actually safe ;) > > -0 on that, I'd rather use snprintf when available, sprintf when not. strange argument. why is it okay to crash Python on Windows, pure SUSv2 platforms, pure ANSI C platforms, etc? besides, snprintf doesn't do the same thing as my PyErr_Format replacement... From gstein at lyra.org Tue Jul 18 21:41:44 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 12:41:44 -0700 Subject: [Python-Dev] Terminal programs (was: Python-dev summary: Jul 1-15) In-Reply-To: <20000718101321.D21354@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Tue, Jul 18, 2000 at 10:13:21AM -0400 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> Message-ID: <20000718124144.M29590@lyra.org> On Tue, Jul 18, 2000 at 10:13:21AM -0400, Andrew Kuchling wrote: > Thanks to everyone who made some suggestions. The more minor > edits have been made, but I haven't added any of the threads I missed > because doing a long stretch of Emacs editing in this lame Windows terminal > program will drive me insane, so I just posted the summary to python-list. > > How is it possible for Microsoft to not get a VT100-compatible > terminal program working correctly? VT100s have been around since, > when, the 1970s? Can anyone suggest a Windows terminal program that > *doesn't* suck dead bunnies through a straw? yes. I use "Tera Term Pro" with the SSH extensions. That gives me an excellent Telnet app, and it gives me SSH. I have never had a problem with it. [ initially, there is a little tweakiness with creating the "known_hosts" file, but you just hit "continue" and everything is fine after that. ] Tera Term Pro can be downloaded from some .jp address. I think there is a 16-bit vs 32-bit program. I use the latter. The SSL stuff is located in Oz, me thinks. I've got it on the laptop. Great stuff. Cheers, -g -- Greg Stein, http://www.lyra.org/ From nascheme at enme.ucalgary.ca Tue Jul 18 22:37:03 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 18 Jul 2000 14:37:03 -0600 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: <20000718101321.D21354@newcnri.cnri.reston.va.us>; from Andrew Kuchling on Tue, Jul 18, 2000 at 10:13:21AM -0400 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> Message-ID: <20000718143703.A15498@keymaster.enme.ucalgary.ca> On Tue, Jul 18, 2000 at 10:13:21AM -0400, Andrew Kuchling wrote: > Can anyone suggest a Windows terminal program that *doesn't* suck dead > bunnies through a straw? I like putty. You can do a google search for it or grab it off my website: http://www.enme.ucalgary.ca/~nascheme/putty.exe http://www.enme.ucalgary.ca/~nascheme/pscp.exe http://www.enme.ucalgary.ca/~nascheme/putty.zip It's a single exectutable that does telnet, SSH and raw TCP connections (very nice when your away from home). It sucks much less than the Windows telnet. Hmm, I wonder if MS was motivated to make logging into a Unix machine as painful as possible? Neil From paul at prescod.net Tue Jul 18 22:50:57 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 18 Jul 2000 15:50:57 -0500 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> Message-ID: <3974C331.4FAFD48D@prescod.net> Thomas Wouters wrote: > >... > > .... > > - Better error message with UnboundLocalError > Patch looks okay to me, and Tim already said he liked the idea. Tim might as well look at it. I'm a little paranoid about changing ceval. I fixed the static typo you pointed out. Re: range literal: I think you need to assign it to some "core" to look at. Yes, Guido likes the idea but nobody has verified the implementation. Maybe it isn't an issue of core/non-core but more just a requirement for a second opinion. I would advise against checking in without it. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From thomas at xs4all.net Tue Jul 18 23:28:33 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 18 Jul 2000 23:28:33 +0200 Subject: [Python-Dev] 'shadowing' builtins In-Reply-To: <39734E04.C7D29873@prescod.net>; from paul@prescod.net on Mon, Jul 17, 2000 at 01:18:44PM -0500 References: <20000717200116.P7340@xs4all.nl> <39734E04.C7D29873@prescod.net> Message-ID: <20000718232833.F4283@xs4all.nl> On Mon, Jul 17, 2000 at 01:18:44PM -0500, Paul Prescod wrote: > Thomas Wouters wrote: > > He decided to go to David Beazly's python introduction, and he was suprised > > at how you can do 'None = 4'. And when I explained it's harmless (because > > it's local, not global) he was suprised it didn't generate a warning. And, > > well, why doesn't it generate a warning ? Only with an, uhm, '-w' option or > > so, of course, or perhaps add it to the '-t' option. It would be also a > > compile-time-check. It might require a seperate lookup table (haven't looked > > at it at all, yet) that duplicates the 'builtin' namespace, but I'd think > > it's worth it. > * None, map and other such long-term, ancient built-ins should not be > directly overridable. I don't think we need a warning mode. Just outlaw > it. We can do this with a semantic check in the compiler. My first reaction was 'Ack, eek, argh, nonono'. So I decided to sleep over it. And my reaction is still 'Ack. eek, argh, nonono' ;) If it's optional, like a '-ww' option, sure. But by default ? Please don't. One of python's great features is that it's so damned consistent. Having some builtins overridable and others not would not only break a lot of code, it would also confuse a lot of people. There is no particular reason to disallow assigning to map() for programs where map() is not used, for instance. I often find myself doing 'list = <...>' for small scripts, eventhough I realize while I'm typing that 'list' is a builtin function. Part of the reasons is that 'list' is an incredibly descriptive name, and my code often gets read by colleagues who still need to get infected by the Python virus. (Though, I have to admit, it *is* slowly spreading ;) Nevertheless, I wouldn't do that in large projects, and that's where I invision the '-w' option would be best used. 'This might become a problem'. > * Those with a good reason to shadow them would do it by assignment to > the module's dict or __builtins__. The "feature" would still be there if > you need it, but it would be syntactically distinct. Or maybe we need to > disallow it entirely to allow optimizers to attack this important > special case. Perhaps, as an option. With an optimizer. I wouldn't do it for the sake of it; only do it if the user asks for it. > * Python badly needs a warning infrastructure. If I had time, that > would be my first PEP. I'd rather the former tightening up was not > hostage to a warning infrastructure that nobody gets around to > implementing, though. I might be tempted to suggest a compile-only command line switch, too. Doing it through a small script is a tad cumbersome, especially if you just want a compile-run with (for instance) -w or -t, to see if you have any obvious problems. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Tue Jul 18 23:45:19 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 18 Jul 2000 16:45:19 -0500 Subject: [Python-Dev] 'shadowing' builtins References: <20000717200116.P7340@xs4all.nl> <39734E04.C7D29873@prescod.net> <20000718232833.F4283@xs4all.nl> Message-ID: <3974CFEF.C55AC9B@prescod.net> Thomas Wouters wrote: > > ... > > My first reaction was 'Ack, eek, argh, nonono'. So I decided to sleep over > it. And my reaction is still 'Ack. eek, argh, nonono' ;) If it's optional, > like a '-ww' option, sure. But by default ? Please don't. One of python's > great features is that it's so damned consistent. Having some builtins > overridable and others not would not only break a lot of code, it would also > confuse a lot of people. Most people probably do not even know that the built-in functions can be shadowed. That's precisely the problem. I don't think that enforcing a rule that they expect to already be enforced will confuse them. As your friend pointed out, NOT enforcing the rule confuses them. > There is no particular reason to disallow assigning to map() for programs > where map() is not used, for instance. I often find myself doing 'list = > <...>' for small scripts, eventhough I realize while I'm typing that 'list' > is a builtin function. Part of the reasons is that 'list' is an incredibly > descriptive name, and my code often gets read by colleagues who still need > to get infected by the Python virus. Using the same word for two different things is more likely to confuse them than help them. Anyhow, constructor functions and type names need to be unified (for consistency) and type names and class names need to be unified (for consistency). And class names start with an upper case letter. So the need to override list() is scheduled to go away (eventually!) > Nevertheless, I wouldn't do that in large projects, and that's where I > invision the '-w' option would be best used. 'This might become a problem'. It is just as likely a problem in a small project than ina a big one. The shadowing is local, after all. It isn't a problem that "gets worse" as the program grows. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From esr at thyrsus.com Wed Jul 19 00:11:48 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jul 2000 18:11:48 -0400 Subject: [Python-Dev] what happened with the python-list addresses? In-Reply-To: <14708.43013.274067.569324@beluga.mojam.com> References: <14708.43013.274067.569324@beluga.mojam.com> Message-ID: <20000718181148.F1283@thyrsus.com> Skip Montanaro : > > I don't want to create a storm on c.l.py, so I post here. I noticed a bunch > of "email addresses" that look like "aahz at netcom.com.bbs@openbazaar.net" in > recent digests. Is there some sort of runaway gateway? Who is > openbazaar.net? Sounds like something ESR would be involved with, though I > can't reach an obvious web site in that domain and they appear to be located > in Taiwan. > > Skip I know nothing about it. -- Eric S. Raymond What, then is law [government]? It is the collective organization of the individual right to lawful defense." -- Frederic Bastiat, "The Law" From peter at schneider-kamp.de Wed Jul 19 02:04:00 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 00:04:00 +0000 Subject: [Python-Dev] PEP 204 - Range Literals References: <20000718121831.A7340@xs4all.nl> Message-ID: <3974F070.CC18BED0@schneider-kamp.de> Thomas Wouters wrote: > > I've attached the first draft of PEP 204, Range Literals, which I just > uploaded to CVS as well. If anyone finds time to review it, or the proposed > implementation (patch #100902 on SourceForge) please do. I'm not sure what > to do with the patch... Guido said as much as 'apply it'(*), but I doubt > anyone really looked at it yet ;) Well, I can't say I really looked at it (the patch touches areas where I would deny me all too much expertise), but as far as I could understand it, it looks fine to me. This considered, I am still +1 on it. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From jack at oratrix.nl Wed Jul 19 00:09:39 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 19 Jul 2000 00:09:39 +0200 Subject: [Python-Dev] posixpath.normpath In-Reply-To: Message by Moshe Zadka , Tue, 18 Jul 2000 16:44:01 +0300 (IDT) , Message-ID: <20000718220944.ECF41126BD4@oratrix.oratrix.nl> Recently, Moshe Zadka said: > Simple question: what should > > a) posixpath.normpath("..") .. What else could it return? > b) posixpath.normpath("/..") This I'm a bit less sure about. Does anyone remember the Newcastle Connection a.k.a Unix United? It was a distributed filesystem where other hosts were reachable through /.. . Think of something analogous to going from foo.bar.nl to the root of bletch.bar.nl by doing /../bletch/ . The newcastle connection is long dead (at least, I assume it is) but unless the Posix standard unequivocally specifies that /.. == /. I think I'd keep it as-is. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack at oratrix.nl Wed Jul 19 00:13:35 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 19 Jul 2000 00:13:35 +0200 Subject: [Python-Dev] what happened with the python-list addresses? In-Reply-To: Message by Skip Montanaro , Tue, 18 Jul 2000 13:55:01 -0500 (CDT) , <14708.43013.274067.569324@beluga.mojam.com> Message-ID: <20000718221340.50A58126BD4@oratrix.oratrix.nl> Recently, Skip Montanaro said: > openbazaar.net? Sounds like something ESR would be involved with, [...] On the premise that anything with "bazaar" has to do with ESR? Hmm, then I could try asking him for a refund on that overpriced and leaky teapot I got in Egypt last year... :-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From peter at schneider-kamp.de Wed Jul 19 02:13:52 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 00:13:52 +0000 Subject: [Python-Dev] PEP 206 - NumPy Message-ID: <3974F2C0.F028CE48@schneider-kamp.de> I know this has probably been discussed many times, but a) I haven't been around that long and b) there is a TBD in nondist/peps/pep-206.txt :-] What would it take to include NumPy with the "Batteries included" release of Python? BTW: What about kjBuckets and some other modules that have been proposed? They are not in the PEP. ducking-behind-a-shuttle-style-ceramic-tile-heat-absorber-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From barry at scottb.demon.co.uk Wed Jul 19 00:15:10 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Tue, 18 Jul 2000 23:15:10 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python In-Reply-To: Message-ID: <000601bff105$a3770500$060210ac@private> mark commenting on Gordon commenting on Barry... > If we are asking them to change their code, can we investigate whether > asking them to insert a simple: > > if (!Py_IsInitialized()) > Py_FatalError("Bad Python version"); /* Never returns */ > > works OK? I believe it will, as long as Python's fatal error handler > doesnt make thread-state assumptions. I think this code will crash. 1. Python20.dll loads and is initialised. 2. python20.dll loads old_extension.pyd 3. old_extension.pyd causes python15.dll to load At this point we have two copies of python in memory. 4. old_extension.pyd calls Py_IsInitialized() which is bound to the function in python15.dll. 5. FALSE is return as python15.dll has not been initialised. 6. Py_FatalError which is bound in python15.dll is called. May well crash, certainly does not communicate to python20.dll You could just: if (!Py_IsInitialized()) return; Which prevents the module being created and hence gets an already implemented error message. The down side is that does not work for .PYD that have already been shipped for 1.5. Also if we wish to solve this class of problem for unix as well this does not work. Barry From barry at scottb.demon.co.uk Wed Jul 19 00:36:15 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Tue, 18 Jul 2000 23:36:15 +0100 Subject: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python Message-ID: <000701bff108$950ec9f0$060210ac@private> Mark's comment about what I'd come up with being too complex inspired this simpler solution. Change the init function name to a new name PythonExtensionInit_ say. Pass in the API version for the extension writer to check. If the version is bad for this extension returns without calling any python functions. Add a return code that is true if compatible, false if not. If compatible the extension can use python functions and report and problems it wishes. int PythonExtensionInit_XXX( int invoking_python_api_version ) { if( invoking_python_api_version != PYTHON_API_VERSION ) { /* python will report that the module is incompatible */ return 0; } /* setup module for XXX ... */ /* say this extension is compatible with the invoking python */ return 1; } All 1.5 extensions fail to load on later python 2.0 and later. All 2.0 extensions fail to load on python 1.5. All new extensions work only with python of the same API version. Document that failure to setup a module could mean the extension is incompatible with this version of python. Small code change in python core. But need to tell extension writers what the new interface is and update all extensions within the python CVS tree. Barry From effbot at telia.com Wed Jul 19 00:52:11 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 19 Jul 2000 00:52:11 +0200 Subject: [Python-Dev] uPEP: encoding directive References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> Message-ID: <016501bff10a$d09bc660$f2a6b5d4@hagrid> > [paul] > > Also, is it really necessary to allow raw non-ASCII characters in source > > code though? We know that they aren't portable across editing > > environments, so one person's happy face will be another person's left > > double-dagger. > > [me] > I suppose changing that would break code. maybe it's time > to reopen the "pragma encoding" thread? > > (I'll dig up my old proposal, and post it under a new subject). as brief as I can make it: 1. add support for "compiler directives". I suggest the following syntax, loosely based on XML: #?python key=value [, key=value ...] (note that "#?python" will be treated as a token after this change. if someone happens to use comments that start with #?python, they'll get a "SyntaxError: bad #?python compiler directive"...) 2. for now, only accept compiler directives if they appear before the first "real" statement. 3. keys are python identifiers (NAME tokens), values are simple literals (STRING, NUMBER) 4. key/value pairs are collected in a dictionary. 5. for now, we only support the "encoding" key. it is used to determine how string literals (STRING tokens) are converted to string or unicode string objects. 6. the encoding value can be any of: "undefined" or not defined at all: plain string: copy source characters as is unicode string: expand 8-bit source characters to unicode characters (i.e. treat them as ISO Latin 1) "ascii" plain string: characters in the 128-255 range gives a SyntaxError (illegal character in string literal). unicode string: same as for plain string any other ascii-compatible encoding (the ISO 8859 series, Mac Roman, UTF-8, and others): plain string: characters in the 128-255 range gives a SyntaxError (illegal character in string literal). unicode string: characters in the 128-255 range are decoded, according to the given encoding. string has been decoded, any other encoding (UCS-2, UTF-16) undefined (or SyntaxError: illegal encoding) to be able to flag this as a SyntaxError, I assume we can add an "ASCII compatible" flag to the encoding files. 7. only the contents of string literals can be encoded. the tokenizer still works on 7-bit ASCII (hopefully, this will change in future versions). 8. encoded string literals are decoded before Python looks for backslash escape codes. I think that's all. Comments? I've looked at the current implementation rather carefully, and it shouldn't be that hard to come up with patches that implement this scheme. From Vladimir.Marangozov at inrialpes.fr Wed Jul 19 01:37:09 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 19 Jul 2000 01:37:09 +0200 Subject: [Python-Dev] [Fwd: Python-dev summary: July 1-15] Message-ID: <3974EA25.EF4B86C7@inrialpes.fr> Forgot to cc: the list. Vladimir Marangozov wrote: > > David Bolen wrote: > > > > Andrew Kuchling writes: > > > > > This is a first experiment in whether I can make a useful, > > > interesting, somewhat coherent summary of python-dev activity. > > > If reaction is favorable, and time permits, it may become a biweekly > > > posting. > > > > This seems quite useful - is there any "proper" way to send feedback > > on mail on python-dev without actually being on the list? > > > > Yes. It's the comp.lang.python newsgroup. Pick up an issue, give it > a meaningful subject line (eg. Subject: Re: PEP 201 - Parallel iteration) > and discuss it. Most people on python-dev read the newsgroup regularly > and forward to the python-dev list some of the issues that have been > brought here. So there's feedback from the group to python-dev > and there's a natural selection of the topics that need python-dev's > attention. This "selection" is a matter of experience -- some topics > are recurrent in Python's life and not all posters in c.l.py are aware > that they have been discussed extensively in the past. > > The reverse wasn't true and the python-dev summary documents are intended > to inform a broader audience, notably the Python community, on its > current activities. The natural place for discussing all topics brought > on python-dev is the comp.lang.python newsgroup. This is also the place > where the python-dev members are looking for feedback. For instance, > read the PEP documents -- they summarize recent and past proposals for > various enhancements. All python-dev members are interested in seeing > them discussed by the community. So don't hesitate to take a stance on > a PEP if you think that you could share an educated opinion. > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw at beopen.com Wed Jul 19 01:34:17 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 19:34:17 -0400 (EDT) Subject: [Python-Dev] what happened with the python-list addresses? References: <14708.43013.274067.569324@beluga.mojam.com> Message-ID: <14708.59769.955591.282115@anthem.concentric.net> >>>>> "SM" == Skip Montanaro writes: SM> I don't want to create a storm on c.l.py, so I post here. I SM> noticed a bunch of "email addresses" that look like SM> "aahz at netcom.com.bbs@openbazaar.net" in recent digests. Is SM> there some sort of runaway gateway? Who is openbazaar.net? SM> Sounds like something ESR would be involved with, though I SM> can't reach an obvious web site in that domain and they appear SM> to be located in Taiwan. No clue from me, unfortunately. Thomas Wouters noticed the same thing and the postmaster identified in the headers has been notified. -Barry From gstein at lyra.org Wed Jul 19 02:26:13 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 17:26:13 -0700 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: <20000718143703.A15498@keymaster.enme.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Tue, Jul 18, 2000 at 02:37:03PM -0600 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> <20000718143703.A15498@keymaster.enme.ucalgary.ca> Message-ID: <20000718172613.I7033@lyra.org> On Tue, Jul 18, 2000 at 02:37:03PM -0600, Neil Schemenauer wrote: > On Tue, Jul 18, 2000 at 10:13:21AM -0400, Andrew Kuchling wrote: > > Can anyone suggest a Windows terminal program that *doesn't* suck dead > > bunnies through a straw? > > I like putty. You can do a google search for it or grab it off my > website: > > http://www.enme.ucalgary.ca/~nascheme/putty.exe > http://www.enme.ucalgary.ca/~nascheme/pscp.exe > http://www.enme.ucalgary.ca/~nascheme/putty.zip > > It's a single exectutable that does telnet, SSH and raw TCP connections > (very nice when your away from home). It sucks much less than the > Windows telnet. Hmm, I wonder if MS was motivated to make logging into > a Unix machine as painful as possible? Well it also sucks when you're trying to connect to a MUD. Has nothing to do with Unix :-) Face it: their telnet just blows chunks... hehe... Cheers, -g -- Greg Stein, http://www.lyra.org/ From alex_c at MIT.EDU Wed Jul 19 02:22:45 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Tue, 18 Jul 2000 20:22:45 -0400 (EDT) Subject: [Python-Dev] PEP 206 - NumPy In-Reply-To: <3974F2C0.F028CE48@schneider-kamp.de> (message from Peter Schneider-Kamp on Wed, 19 Jul 2000 00:13:52 +0000) References: <3974F2C0.F028CE48@schneider-kamp.de> Message-ID: <200007190022.UAA107087@w20-575-115.mit.edu> > BTW: What about kjBuckets and some other modules that have > been proposed? They are not in the PEP. I used to use kjbuckets.kjSet a lot, but when I switched to bleeding-edge python, I decided to try a roll-your-own using python dictionaries because I expected (for no good reason -- I've never looked at the python source for this :) the hashing implementation had improved. I haven't done any formal benchmarking, but for the one application where I decided to do this, that one change made for a tremendous speed up. The class I used instead of kjbuckets.kjSet is at http://puffin.lcs.mit.edu:8080/cgi-bin/cvsweb/mouse/tools/Set.py?rev=1.6&content-type=text/x-cvsweb-markup Alex. From gstein at lyra.org Wed Jul 19 02:48:03 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 17:48:03 -0700 Subject: [Python-Dev] uPEP: encoding directive In-Reply-To: <016501bff10a$d09bc660$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jul 19, 2000 at 12:52:11AM +0200 References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> Message-ID: <20000718174803.L7033@lyra.org> On Wed, Jul 19, 2000 at 12:52:11AM +0200, Fredrik Lundh wrote: >... > as brief as I can make it: Sounds reasonable to me. PEP it, and let's see what the BDFL has to say about the general direction. Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Wed Jul 19 03:09:24 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 18 Jul 2000 21:09:24 -0400 (EDT) Subject: [Python-Dev] posixpath.normpath In-Reply-To: References: Message-ID: <14708.65476.123678.27693@beowolf.beopen.com> Moshe Zadka writes: > Simple question: what should > > a) posixpath.normpath("..") ".." > b) posixpath.normpath("/..") "/" -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Wed Jul 19 03:45:24 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 18 Jul 2000 20:45:24 -0500 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> <14708.40190.852802.966575@beluga.mojam.com> Message-ID: <39750834.B068CA61@prescod.net> Skip Montanaro wrote: > > ... > newlist = map(string.strip, oldlist) > > As far as I'm aware, there's no clean way to do that with string methods. Once we have list comprehensions, there will be: newlist = [for x in oldlist: x.strip()] I think the list-comp version is much more readable and "generic". -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From gmcm at hypernet.com Tue Jul 18 21:11:37 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 18 Jul 2000 15:11:37 -0400 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: References: <1248199317-67151042@hypernet.com> Message-ID: <1248148993-1712008@hypernet.com> Moshe wrote: > I disagree: you agree that if you add a pad argument when the > lists are all the same size it doesn't matter (if you don't agree > with this, you don't agree with the PEP). Now, when there is only > one list, the lists are all the same size. QED. I would agree if we were talking about transpose(matrix, [pad]). Then: transpose([(1,2,3)]) -> [(1,), (2,), (3,)] and transpose([(1,), (2,), (3,)]) -> [(1,2,3)] That is, a 3X1 transposes to a 1X3 and vice versa. But zip doesn't take a matrix, it takes some number of sequences. Oh heck, I'll agree anyway. But I dread explaining why 1) it doesn't behave like map(None, [1,2,3]) 2) why zip(((1,2),(3,4))) doesn't yield [(1,3), (2,4)] but [((1,2),), ((3,4),)] instead! So: document zip as taking 2 or more sequences, and throw an exception if fed only one. - Gordon From bwarsaw at beopen.com Wed Jul 19 05:42:53 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:42:53 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> Message-ID: <14709.9149.395757.2952@anthem.concentric.net> >>>>> "Gordo" == Gordon McMillan writes: Gordo> How about a fourth: zip(a) is the same as zip(a, []) ? I don't like it. The way I view zip() is that the length of the elements returned by __getitem__() should always be equal to the number of sequences passed in as parameters. Thus it seems most natural to me that >>> zip((1, 2, 3)) [(1,), (2,), (3,)] >>> zip((1, 2, 3), pad=None) [(1,), (2,), (3,)] When I talk about "special casing", there's two ways to look at it. One possibility is that the implementation of zip has to explicitly check that the number of sequences is 1 and then `do something special' if so. To support Gordon's proposal, or the map()-equivalent, or the raise-an-exception proposal, that would be the case. The second possibility is that user code must `appear' to special case the situation when the number of sequences is exactly 1. I.e. >>> for (i,) in zip((1, 2, 3)): instead of the more natural (because it's less to type and because of the map() heritage): >>> for i in zip((1, 2, 3)): The first example isn't really special casing though. Personally, I think this is going to come up so infrequently that it's not worth it. -Barry From bwarsaw at beopen.com Wed Jul 19 05:44:16 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:44:16 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <1248199317-67151042@hypernet.com> Message-ID: <14709.9232.893964.219712@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I disagree: you agree that if you add a pad argument when the MZ> lists are all the same size it doesn't matter (if you don't MZ> agree with this, you don't agree with the PEP). Now, when MZ> there is only one list, the lists are all the same size. QED. Bingo. -Barry From bwarsaw at beopen.com Wed Jul 19 05:47:32 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:47:32 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <1248248594-64187019@hypernet.com> <200007172311.BAA25445@python.inrialpes.fr> Message-ID: <14709.9428.832622.474548@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> My wish is to add fold() as one of the suggested names in the VM> PEP Done. VM> then let this PEP spend some time in c.l.py. Will do. I just updated the reference implementation. I want to finish going through the comments in this forum and then I'll post to c.l.py. -Barry From bwarsaw at beopen.com Wed Jul 19 05:58:28 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:58:28 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <3973A097.B85D6775@schneider-kamp.de> Message-ID: <14709.10084.225732.826719@anthem.concentric.net> >>>>> "KM" == Ken Manheimer writes: KM> Evan Simpson (a colleague here at digicool, who'd be a good KM> addition to python-dev) noticed that unzip is unnecessary - KM> zip is its own inverse. Only if the sequences are of the same length. I've added this to the PEP, using the extended call syntax. Note that when the sequences are of the same length, zip() is reversible: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> x = zip(a, b) >>> y = zip(*x) # alternatively, apply(zip, x) >>> z = zip(*y) # alternatively, apply(zip, y) >>> x [(1, 4), (2, 5), (3, 6)] >>> y [(1, 2, 3), (4, 5, 6)] >>> z [(1, 4), (2, 5), (3, 6)] >>> x == z 1 It is not possible to reverse zip this way when the sequences are not all the same length. -Barry From bwarsaw at beopen.com Wed Jul 19 05:59:03 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 18 Jul 2000 23:59:03 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <39743E3A.249212D5@schneider-kamp.de> <011701bff09d$0bc5b020$0900a8c0@SPIFF> Message-ID: <14709.10119.28590.73144@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> Remember the "string join" debate? Yup! FL> -1 on a method. Agreed. -Barry From bwarsaw at beopen.com Wed Jul 19 06:00:17 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 00:00:17 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> Message-ID: <14709.10193.715558.561239@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I'm +1 on that. One thing that bugs me is that we're adding a MZ> builtin type. Why not stick with the Python implementation? I've been thinking a little bit about the other generators, especially irange(). I wonder if we shouldn't just be putting zip() and friends in their own Python module and not make them builtins? -Barry From peter at schneider-kamp.de Wed Jul 19 08:17:49 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 06:17:49 +0000 Subject: [Python-Dev] Patches References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> Message-ID: <3975480D.29F6A89C@schneider-kamp.de> Fredrik Lundh wrote: > > > -0 on that, I'd rather use snprintf when available, sprintf when not. > > strange argument. why is it okay to crash Python on Windows, > pure SUSv2 platforms, pure ANSI C platforms, etc? I was assuming that most modern systems have a sprintf function available. If this is not the case, my argument is indeed void. I was extrapolating from the fact that it's available on the systems I work on (linux, sunos, solaris). > besides, snprintf doesn't do the same thing as my PyErr_Format > replacement... Yes, but it would by possible to use snprintf in PyErr_Format. +1 on the patch. We cannot neglect Windows (unfortunately). Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From moshez at math.huji.ac.il Wed Jul 19 06:28:00 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 07:28:00 +0300 (IDT) Subject: [Python-Dev] posixpath.normpath In-Reply-To: <20000718220944.ECF41126BD4@oratrix.oratrix.nl> Message-ID: On Wed, 19 Jul 2000, Jack Jansen wrote: > > Recently, Moshe Zadka said: > > Simple question: what should > > > > a) posixpath.normpath("..") > > .. > > What else could it return? > > > b) posixpath.normpath("/..") > > This I'm a bit less sure about. Does anyone remember the Newcastle > Connection a.k.a Unix United? It was a distributed filesystem where > other hosts were reachable through /.. . Think of something analogous > to going from foo.bar.nl to the root of bletch.bar.nl by doing > /../bletch/ . > > The newcastle connection is long dead (at least, I assume it is) but > unless the Posix standard unequivocally specifies that /.. == /. I > think I'd keep it as-is. Reason I'm asking: I don't like the posixpath.normpath patch, and thinking of rewriting it into a competitor. Those two sound reasonable, but I'll wait for more opinions... -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Wed Jul 19 06:32:00 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 07:32:00 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <1248148993-1712008@hypernet.com> Message-ID: On Tue, 18 Jul 2000, Gordon McMillan wrote: > So: document zip as taking 2 or more sequences, and throw > an exception if fed only one. Agreed: it seems too much ambiguos. I mean, I didn't think it ambiguous, and neither did Gordon and /F -- only each of us saw a different unambiguouity which show it is. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Wed Jul 19 06:37:29 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 07:37:29 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.10193.715558.561239@anthem.concentric.net> Message-ID: On Wed, 19 Jul 2000, Barry A. Warsaw wrote: > >>>>> "MZ" == Moshe Zadka writes: > > MZ> I'm +1 on that. One thing that bugs me is that we're adding a > MZ> builtin type. Why not stick with the Python implementation? > > I've been thinking a little bit about the other generators, especially > irange(). I wonder if we shouldn't just be putting zip() and friends > in their own Python module and not make them builtins? I'm +1. def-irange(seq):-zip(xrange(len(seq)), seq)-ly y'rs, Z. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Wed Jul 19 08:02:19 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 08:02:19 +0200 Subject: [Python-Dev] 'shadowing' builtins In-Reply-To: <3974CFEF.C55AC9B@prescod.net>; from paul@prescod.net on Tue, Jul 18, 2000 at 04:45:19PM -0500 References: <20000717200116.P7340@xs4all.nl> <39734E04.C7D29873@prescod.net> <20000718232833.F4283@xs4all.nl> <3974CFEF.C55AC9B@prescod.net> Message-ID: <20000719080218.G4283@xs4all.nl> On Tue, Jul 18, 2000 at 04:45:19PM -0500, Paul Prescod wrote: > Thomas Wouters wrote: > > My first reaction was 'Ack, eek, argh, nonono'. So I decided to sleep over > > it. And my reaction is still 'Ack. eek, argh, nonono' ;) If it's optional, > > like a '-ww' option, sure. But by default ? Please don't. One of python's > > great features is that it's so damned consistent. Having some builtins > > overridable and others not would not only break a lot of code, it would also > > confuse a lot of people. > Most people probably do not even know that the built-in functions can be > shadowed. That's precisely the problem. I don't think that enforcing a > rule that they expect to already be enforced will confuse them. As your > friend pointed out, NOT enforcing the rule confuses them. No. He didn't know the scoping rules, and that was all he was worried about. He was only confused because it didn't generate a warning when he thought it should. Making it impossible to shadow builtins by default would confuse a lot more people, because suddenly they can't use the variable names they want, and they can't figure out why. "list" is a builtin ?? > Using the same word for two different things is more likely to confuse > them than help them. Anyhow, constructor functions and type names need > to be unified (for consistency) and type names and class names need to > be unified (for consistency). And class names start with an upper case > letter. So the need to override list() is scheduled to go away > (eventually!) My code never does that. My code simply does not use 'list'. As for the other style issues, There also wasn't a *need* to override list, it was merely convenience. And Python is a very, very convenient language... let's not change that :P > > Nevertheless, I wouldn't do that in large projects, and that's where I > > invision the '-w' option would be best used. 'This might become a problem'. > It is just as likely a problem in a small project than ina a big one. > The shadowing is local, after all. It isn't a problem that "gets worse" > as the program grows. Actually, no, it depends on where and how you use it. In large programs, my functions get larger too, on average. I'm talking 10 lines -> 100 lines here. Also don't forget the global namespace, which affects a lot more code in large programs. And lastly, small programs are only edited by me, or sometimes quick-fixed by a colleague. Large programs get edited by a fair group of people, over a number of years. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Wed Jul 19 08:13:00 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 08:13:00 +0200 Subject: [Python-Dev] posixpath.normpath In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 18, 2000 at 04:44:01PM +0300 References: Message-ID: <20000719081300.H4283@xs4all.nl> On Tue, Jul 18, 2000 at 04:44:01PM +0300, Moshe Zadka wrote: > a) posixpath.normpath("..") '..'. > b) posixpath.normpath("/..") '/'. I *think* this is POSIXly defined, but I'm not sure. However, this is the behaviour on all UNIX machines I've ever seen, and also in protocols like HTTP that take a URL with forward slashes and possibly '..'s. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Wed Jul 19 08:14:52 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 09:14:52 +0300 (IDT) Subject: [Python-Dev] posixpath.normpath In-Reply-To: <20000719081300.H4283@xs4all.nl> Message-ID: On Wed, 19 Jul 2000, Thomas Wouters wrote: > On Tue, Jul 18, 2000 at 04:44:01PM +0300, Moshe Zadka wrote: > > > a) posixpath.normpath("..") > > '..'. > > > b) posixpath.normpath("/..") > > '/'. I *think* this is POSIXly defined, but I'm not sure. However, this is > the behaviour on all UNIX machines I've ever seen, and also in protocols > like HTTP that take a URL with forward slashes and possibly '..'s. OK. I've posted a patch which corrects posixpath.normpath and competes with 100900. Now Skip gets to decide which of them he likes better... -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From mwh21 at cam.ac.uk Wed Jul 19 08:19:42 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 19 Jul 2000 07:19:42 +0100 Subject: [Python-Dev] what happened with the python-list addresses? In-Reply-To: bwarsaw@beopen.com's message of "Tue, 18 Jul 2000 19:34:17 -0400 (EDT)" References: <14708.43013.274067.569324@beluga.mojam.com> <14708.59769.955591.282115@anthem.concentric.net> Message-ID: bwarsaw at beopen.com (Barry A. Warsaw) writes: > >>>>> "SM" == Skip Montanaro writes: > > SM> I don't want to create a storm on c.l.py, so I post here. I > SM> noticed a bunch of "email addresses" that look like > SM> "aahz at netcom.com.bbs@openbazaar.net" in recent digests. Is > SM> there some sort of runaway gateway? Who is openbazaar.net? > SM> Sounds like something ESR would be involved with, though I > SM> can't reach an obvious web site in that domain and they appear > SM> to be located in Taiwan. > > No clue from me, unfortunately. Thomas Wouters noticed the same thing > and the postmaster identified in the headers has been notified. It's stopped now, it seems; killfiling on Organization: OpenBazaar was an effective stop gap measure. Cheers, M. From mwh21 at cam.ac.uk Wed Jul 19 08:30:54 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 19 Jul 2000 07:30:54 +0100 Subject: [Python-Dev] Python-dev summary: Jul 1-15 In-Reply-To: Andrew Kuchling's message of "Tue, 18 Jul 2000 10:13:21 -0400" References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> Message-ID: Andrew Kuchling writes: > Thanks to everyone who made some suggestions. The more minor > edits have been made, but I haven't added any of the threads I missed > because doing a long stretch of Emacs editing in this lame Windows terminal > program will drive me insane, so I just posted the summary to python-list. > > How is it possible for Microsoft to not get a VT100-compatible > terminal program working correctly? VT100s have been around since, > when, the 1970s? Can anyone suggest a Windows terminal program that > *doesn't* suck dead bunnies through a straw? Windows 2000's is (much!) better. Putty is also good; it lives at http://www.chiark.greenend.org.uk/~sgtatham/putty/ Cheers, M. From moshez at math.huji.ac.il Wed Jul 19 08:38:45 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 09:38:45 +0300 (IDT) Subject: [Python-Dev] PEP 206 - NumPy In-Reply-To: <3974F2C0.F028CE48@schneider-kamp.de> Message-ID: On Wed, 19 Jul 2000, Peter Schneider-Kamp wrote: > I know this has probably been discussed many times, but > a) I haven't been around that long and > b) there is a TBD in nondist/peps/pep-206.txt :-] > > What would it take to include NumPy with the "Batteries included" > release of Python? Well, as maintainer of 206, I'd like to answer that: user requests. I haven't done any numeric programming for some time now, so I'm out of touch with this world. I'm planning of preparing 206 for c.l.py discussion this weekend. > BTW: What about kjBuckets and some other modules that have > been proposed? They are not in the PEP. Well, my usual rule is that anyone proposing a new module must do the web research necessary to find out where is the official place to download a known working version from. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From gstein at lyra.org Wed Jul 19 08:53:17 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 23:53:17 -0700 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.10193.715558.561239@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 19, 2000 at 12:00:17AM -0400 References: <14707.22821.945571.314619@anthem.concentric.net> <14709.10193.715558.561239@anthem.concentric.net> Message-ID: <20000718235317.A7561@lyra.org> On Wed, Jul 19, 2000 at 12:00:17AM -0400, Barry A. Warsaw wrote: > >>>>> "MZ" == Moshe Zadka writes: > > MZ> I'm +1 on that. One thing that bugs me is that we're adding a > MZ> builtin type. Why not stick with the Python implementation? > > I've been thinking a little bit about the other generators, especially > irange(). I wonder if we shouldn't just be putting zip() and friends > in their own Python module and not make them builtins? Which are you proposing: 1) implement in a Python module. clients use some_module.zip() 2) implement in a Python module. insert into builtins. clients use zip(). ?? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Wed Jul 19 08:55:59 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 18 Jul 2000 23:55:59 -0700 Subject: [Python-Dev] Patches In-Reply-To: <3975480D.29F6A89C@schneider-kamp.de>; from peter@schneider-kamp.de on Wed, Jul 19, 2000 at 06:17:49AM +0000 References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> Message-ID: <20000718235559.B7561@lyra.org> On Wed, Jul 19, 2000 at 06:17:49AM +0000, Peter Schneider-Kamp wrote: > Fredrik Lundh wrote: > > > > > -0 on that, I'd rather use snprintf when available, sprintf when not. Falling back to sprintf() is just untenable. > > strange argument. why is it okay to crash Python on Windows, > > pure SUSv2 platforms, pure ANSI C platforms, etc? > > I was assuming that most modern systems have a sprintf function (I presume you meant snprintf here) Yes, most do, but it isn't quite the same... > available. If this is not the case, my argument is indeed void. > > I was extrapolating from the fact that it's available on the > systems I work on (linux, sunos, solaris). > > > besides, snprintf doesn't do the same thing as my PyErr_Format > > replacement... > > Yes, but it would by possible to use snprintf in PyErr_Format. still not quite the same. /F's PyErr_Format returns an arbitrary length string. snprintf() would be cut at some pre-specified limit. Cheers, -g -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Wed Jul 19 09:42:41 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 19 Jul 2000 09:42:41 +0200 Subject: [Python-Dev] Python-dev summary: Jul 1-15 References: <200007172357.TAA16970@newcnri.cnri.reston.va.us> <20000718101321.D21354@newcnri.cnri.reston.va.us> Message-ID: <008001bff156$7b503a00$f2a6b5d4@hagrid> michael hudson: > > How is it possible for Microsoft to not get a VT100-compatible > > terminal program working correctly? VT100s have been around since, > > when, the 1970s? Can anyone suggest a Windows terminal program that > > *doesn't* suck dead bunnies through a straw? > > Windows 2000's is (much!) better. much better, but still not good enough. fwiw, I'm using CRT ($35, big deal), which is about as good as it can get: http://www.vandyke.com/products/crt/ From tim_one at email.msn.com Wed Jul 19 07:12:11 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 19 Jul 2000 01:12:11 -0400 Subject: [Python-Dev] RE: Discussion: Introducing new operators for matrix computation In-Reply-To: Message-ID: Sleeping in the same room with Guido for a night did not make it easier to channel him, but it did make it easier to cloud his mind: Guido is not opposed to adding new operator symbols to core Python. As of breakfast Tuesday, anyway, and there are witnesses, so he'll have trouble changing his mind (well, it will be clumsy for him to *admit* it if he changes his mind ...). But but but (you knew it wouldn't be *that* easy!): + Everybody concerned that new operators are "not Pythonic" please swallow it -- it is Pythonic, cuz Guido said it is <0.9 wink -- but see following points too>. Contribute by helping to come up with a complete and Pythonically beautiful implementation instead. + Please keep this off of Python-Dev. Doesn't belong there (at least not yet). Interested parties can form a mailing list, or try to discuss it on comp.lang.python (my personal hope is that you try the latter, and stick to one Subject line). + There *must* be a PEP for this. Guido won't read any more of the debate -- it's too voluminous, repetitive and contentious. He'll eventually read a PEP, though, *after* some sort of consensus is reached. A PEP requires a champion. I hope Huaiyu Zhu volunteers for this, as he's argued his case eloquently and rationally. The champion doesn't need to know how to implement it, but does need to summarize sometimes-opposing positions dispassionately. + There are things Guido will & won't tolerate. Guessing which is an interesting & educational challenge . For example, adding a new operator like .+ is fine, as the maximal-munch rule for lexing can resolve formal ambiguities easily. OTOH, *any* new operator symbol containing a backslash is dead before arrival -- backslash has purely "meta" meanings in Python today. If the goal is to make Python look exactly like some other language, forget it. It's still Python, with some light syntactic sugar to make life in special domains sweeter. + This one is from me, but it's a safe bet you can view at as precognitive channeling if you oppose it: anyone suggesting to, e.g., make ".+" mean something new and exciting for ints or floats or strings or ... will be shot. There are probably no operations on the builtin types used frequently enough to merit new syntactic shorthands (excepting, perhaps, that if P3K changes the meaning of integer division, a new "//" operator for flooring division was looked upon kindly in the past). The new operators are for convenience in special domains (where the case for them is indeed very strong), not an excuse to turn current Python into a cryptic mess. + Also from me: forget about user-defined precedence and associativity. The PEP must define these once & for all, and that's that. + The set of new operator symbols cannot be open-ended (as it is in, e.g., Haskell). There are at least 4 variants of Python tranlators already in existence, and Guido wants the set of operator symbols fixed so that a variety of parsing techniques can be used in their natural forms without trickery. IOW, the full set of operator symbols must-- as it is today --be a fixed finite set known in advance. + If the numerical folk can't reach consensus on the set of operators and what they should mean, my bet is that Guido will let this die rather than get sucked into Pronouncing on each of the points in dispute. After all, he has little personal use for this stuff: if the people who *do* want it can't agree, it's not worth having. how's-that-for-a-mysterious-announcement?-ly y'rs - tim From tim_one at email.msn.com Wed Jul 19 07:12:14 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 19 Jul 2000 01:12:14 -0400 Subject: [Python-Dev] Patches In-Reply-To: <14708.26423.536040.581684@beluga.mojam.com> Message-ID: [Skip Montanaro] > As someone who has been assigned some patches that are still open (isatty, > normpath fix, history functions for readline), I'm still pretty > much in the dark about what my rights and responsibilities are. You have responsibility for keeping Python in perfect condition, and the right to be as confused as you like . > Am I supposed to eyeball a patch and check it in if it looks okay > (compiles, doesn't break "make test", etc)? Am I supposed to bring > it up for discussion on python-dev? Something entirely different > (blow up a bush, perhaps)? You're responsible for "taking the next step". What that step is depends on *your* good judgment: if you feel confident that the patch is fine, sure, check it in and close it. If you're confident that the patch sucks, reject it, explain why in a comment, and assign it back to the submitter. If you're uncertain, do neither of those: bring it up on Python-Dev, or if you think you know who *can* resolve your uncertainties, make a comment and assign it to them. > I just submitted a feature request for the patch manager at SF. > I asked for the following: > > 1. better selection/exclusion predicates for the filtering function > 2. filtering based on assignee/submitter > 3. display of a patch's state in the table > > If you'd like to review it and add your own two cents, it's at > > https://sourceforge.net/forum/message.php?msg_id=41288 We (PythonLabs) met with three of the Source Forge developers late Tuesday afternoon. They're perfectly reasonable and perfectly overburdened too. The one & only thing we got them to promise to implement Real Soon Now is a new checkbox on the Project Admin page, saying to send *all* patch email to the patches email address. By itself, this doesn't help anything. What it does do is enable *us* to build on the SF patch pages via automated "screen scraper" programs. Ka-Ping Yee wrote one of those but didn't post it here, to generate *useful* email when a msg from SourceForge tickles it. Jeremy Hylton posted a program here to scrape the SF pages and download the info into a local database. We can build better display and filtering tools (likely cmdline) ourselves on top of these. The SF people would be happy to too, but they appear not to have the bandwidth for it now. forthrightly y'rs - tim From python at horizon.com Wed Jul 19 10:22:40 2000 From: python at horizon.com (python at horizon.com) Date: 19 Jul 2000 08:22:40 -0000 Subject: [Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation] Message-ID: <20000719082240.17706.qmail@science.horizon.com> ESR was kind enough to suggest that this idea was worthy of a larger audience, so here is my Very Humble Opinion Indeed... (My knowledge of Python is limited to buying the O'Reilly book and meaning to read it one of these days, so I may be missing something REALLY elementary here.) But if you want extensible infix operators without burdening people trying to read the code too much, consider this: For each existing operator #, there is an infinite family of user-definable operators @#, @@#, etc. These get progressivley less readable, so I don't think you'd *want* to go past @@, but hey, it's there if you want. Each one has the same precedence and associativity as the bare operator #, so there are no new rules for anyone to learn. "a @* b * c @@* d" would associate to the left as usual, producing "((a @* b) * c) @@* d". You should probably extend this to unary operators, so someone could, for example, define unary @- to be complex conjugate. An alternative precednece rule would put * > @* > @@* > ... > + > @+ > ..., which also avoids requiring people to learn much of anything new, but I think people trying to write parsers would object strenuously to an infinite number of precedence levels. You need some way to define all of these functions, but I assume that's just a Small Matter of Programming for the uber-studly programmers here, leaping from tree to tree in the mighty forests of British Columbia... Oh wait a minute, I'm sorry. That's just getting silly. A language I worked on a Long Time Ago used backquotes to turn operators into normal functions so a + b was `+`(a,b), and the syntax was also used when defining such functions, but I'm sure Python has some existing scheme for referring to built-in operators that could be extended. Anyway, just food for thought. (If that isn't enough extra operators, you can also add *@. And then even @*@. @@*@ and @*@@ are for the terminally masochistic, and anyone who'd go beyond that should be kept away from computers and sharp objects until they're feeling better.) "Better get a bu.}}}}NO CARRIER From jack at oratrix.nl Wed Jul 19 10:37:26 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 19 Jul 2000 10:37:26 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/sf-html sf-faq.html,1.4,1.5 In-Reply-To: Message by Peter Schneider-Kamp , Tue, 18 Jul 2000 14:43:26 -0700 , <200007182143.OAA02155@slayer.i.sourceforge.net> Message-ID: <20000719083726.9343137186E@snelboot.oratrix.nl> Peter, could you add a Macintosh section saying that it's currently quite impossible to use cvs over ssh, at least: as far as we know, and that any reports of getting it to work and/or pointers to more info would be appreciated? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From effbot at telia.com Wed Jul 19 10:55:41 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 19 Jul 2000 10:55:41 +0200 Subject: [Python-Dev] RE: Discussion: Introducing new operators for matrix computation References: Message-ID: <018301bff15f$1f1acb20$f2a6b5d4@hagrid> tim wrote: > + There are things Guido will & won't tolerate. Guessing which is an > interesting & educational challenge . For example, adding a new > operator like > > .+ > > is fine, as the maximal-munch rule for lexing can resolve formal ambiguities > easily. Only if you're thinking as a compiler... ;-) Besides, the proposed way to resolve "3.+x" means that the meaning of an operator would change depending on the preceeding operand (and the other way around). Sure sounds like Perl to me... > This one is from me, but it's a safe bet you can view at as precognitive > channeling if you oppose it: anyone suggesting to, e.g., make ".+" mean > something new and exciting for ints or floats or strings Why not strings? As Perl has showed, *everyone* is doing string processing. If we're gonna add stuff, why not cater to the masses? For a start, how about: match = string .~ pattern I'm sure we can do something fun with ?, the sre scanner, and list comprehensions too... > There are at least 4 variants of Python translators Fwiw, a recent sunworld article says six. And don't forget syntax checking development environments (afaik, at least two of them does that, or will in a near future). > Please keep this off of Python-Dev. Okay, okay. Last time I tried to say that, everyone shouted at me. On the other hand, now that Python has dropped from spot 10 down to 15 on the sourceforge top activity list, it's about time python-dev went back to actually doing things, instead of just talking about what could be done... ;-) From thomas at xs4all.net Wed Jul 19 13:25:55 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 13:25:55 +0200 Subject: [Python-Dev] ANSIfication ? Message-ID: <20000719132554.B9897@xs4all.nl> Is there any particular reason the ANSIfication stopped before it reached Python/, other than time issues ? If not, good, because I'm busy ANSIfying that directory ;) I'll post some patches later today, except for ceval.c and compile.c: the work I'm doing is relative to the range-literal patch, so I'm gonna wait until that one's accepted before uploading those ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From peter at schneider-kamp.de Wed Jul 19 15:43:47 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 13:43:47 +0000 Subject: [Python-Dev] ANSIfication ? References: <20000719132554.B9897@xs4all.nl> Message-ID: <3975B093.C2F125BD@schneider-kamp.de> Thomas Wouters wrote: > > Is there any particular reason the ANSIfication stopped before it reached > Python/, other than time issues ? If not, good, because I'm busy ANSIfying I don't think so. After ANSIfying the whole Module/ directory I was fed up. I'd guess the same applies to Fred who slaved away in Objects/ ... Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From bwarsaw at beopen.com Wed Jul 19 14:29:53 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 08:29:53 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <14709.10193.715558.561239@anthem.concentric.net> <20000718235317.A7561@lyra.org> Message-ID: <14709.40769.935694.167265@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: >> other generators, especially irange(). I wonder if we >> shouldn't just be putting zip() and friends in their own Python >> module and not make them builtins? GS> Which are you proposing: GS> 1) implement in a Python module. clients use some_module.zip() Yes. GS> 2) implement in a Python module. insert into builtins. clients GS> use zip(). No. -Barry From bwarsaw at beopen.com Wed Jul 19 14:50:56 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 08:50:56 -0400 (EDT) Subject: [Python-Dev] RE: Discussion: Introducing new operators for matrix computation References: Message-ID: <14709.42032.689117.684055@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> + There *must* be a PEP for this. There already is: PEP 211, Adding New Operators to Python. And it's been assigned to Greg Wilson, although he may want to re-assign it. It's currently just boilerplate. -Barry From alex_c at MIT.EDU Wed Jul 19 15:36:59 2000 From: alex_c at MIT.EDU (Alex Coventry) Date: Wed, 19 Jul 2000 09:36:59 -0400 (EDT) Subject: [Python-Dev] posixpath.normpath In-Reply-To: (message from Moshe Zadka on Wed, 19 Jul 2000 07:28:00 +0300 (IDT)) References: Message-ID: <200007191336.JAA18516@nerd-xing.mit.edu> FWIW, I vote for Moshe's patch. Alex. From paul at prescod.net Wed Jul 19 02:37:29 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 18 Jul 2000 19:37:29 -0500 Subject: [Python-Dev] PEP 204 - Range Literals References: <20000718121831.A7340@xs4all.nl> Message-ID: <3974F849.A83AC7CB@prescod.net> Should range literals create a list of the passed-in type ? It might be desirable in the cases of other builtin types, such as longs and strings: >>> [ 1L : 2L<<64 : 2<<32L ] >>> ["a":"z":"b"] >>> ["a":"z":2] However, this might be too much `magic' to be obvious. Well the step argument is of debatable utility for strings but ["0":"9"] seems mildly useful. Also, it makes sense to create a range of floating point numbers. If we were going to do this, we would probably have an overloadable operator: string.__range__( start=None, end=None, step=None ) It could return a sequence of whatever kind. I'm not clear why we can't implement it as a function call to __builtins__.range . -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From thomas at xs4all.net Wed Jul 19 14:55:28 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 14:55:28 +0200 Subject: [Python-Dev] HAVE_STDARG_PROTOTYPES Message-ID: <20000719145528.C9897@xs4all.nl> I'm currently assuming HAVE_STDARG_PROTOTYPES, as defined by configure comes implicitly with ANSI C compilers. (It defines the way to handle variable-argument functions, and I think the '...' method is standard ANSI C. Please correct me if I'm wrong.) However, I'm not sure what the ANSI standard says on the subject of va_list: there is a define that checks whether va_list is an array of some sort, or not. Is that K&R-C compatibility we can throw out, or should I keep it ? (it's not that much, so I'm keeping it for now.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Wed Jul 19 16:39:50 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 16:39:50 +0200 Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <3974F849.A83AC7CB@prescod.net>; from paul@prescod.net on Tue, Jul 18, 2000 at 07:37:29PM -0500 References: <20000718121831.A7340@xs4all.nl> <3974F849.A83AC7CB@prescod.net> Message-ID: <20000719163950.D9897@xs4all.nl> On Tue, Jul 18, 2000 at 07:37:29PM -0500, Paul Prescod wrote: > I'm not clear why we can't implement it as a function call to > __builtins__.range . I did that mostly because of the error messages. Giving the range() error messages when using [1:100] is a bit confusing. Can't think of any other reason, though. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Wed Jul 19 17:43:13 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 19 Jul 2000 10:43:13 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_openpty.py,1.1,1.2 test_pty.py,1.2,1.3 In-Reply-To: <200007191451.HAA13863@slayer.i.sourceforge.net> References: <200007191451.HAA13863@slayer.i.sourceforge.net> Message-ID: <14709.52369.695950.390400@beluga.mojam.com> Thomas, Thanks for ANSIfying isatty and uncommenting it isatty tests. I had uncommented the tests here, but forgot to check them in... Skip From paul at prescod.net Wed Jul 19 18:09:05 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 11:09:05 -0500 Subject: [Python-Dev] uPEP: encoding directive References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> Message-ID: <3975D2A1.5DDA10E6@prescod.net> I'd prefer if you would separate out the compile directives PEP from the encoding PEP. I'm +1 on compiler directives. I'm -0 on literal encodings. It seems like more effort than is necessary. If we're going to restrict people to ASCII-like encodings, we could just restrict them to ASCII and get it over with. Also, I don't like that the default mode is non-portable. The default should be ASCII. Yes, this could cause backwards-compatibility problems. Maybe problems should be reported with warning. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul at prescod.net Wed Jul 19 18:09:45 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 11:09:45 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> Message-ID: <3975D2C9.66FE16C2@prescod.net> "Barry A. Warsaw" wrote: > >... > > > The second possibility is that user code must `appear' to special case > the situation when the number of sequences is exactly 1. I.e. > > >>> for (i,) in zip((1, 2, 3)): > > instead of the more natural (because it's less to type and because of > the map() heritage): > > >>> for i in zip((1, 2, 3)): Why are you using zip in this case? If you *know* that you are going to get back 1-tuples then you must know that the input is a single list (i.e. you aren't using "apply"). So why are you using zip at all? -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul at prescod.net Wed Jul 19 18:10:34 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 11:10:34 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <14709.10193.715558.561239@anthem.concentric.net> Message-ID: <3975D2FA.74795C3@prescod.net> "Barry A. Warsaw" wrote: > > ... > > I've been thinking a little bit about the other generators, especially > irange(). I wonder if we shouldn't just be putting zip() and friends > in their own Python module and not make them builtins? I prefer builtins (or in some cases methods) for this type of slice and dice functionality. It's not related to some particular datatype or domain. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul at prescod.net Wed Jul 19 18:11:39 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 11:11:39 -0500 Subject: [Python-Dev] PEP 204 - Range Literals References: <20000718121831.A7340@xs4all.nl> Message-ID: <3975D33B.6F4F0C8C@prescod.net> Should range literals create a list of the passed-in type ? It might be desirable in the cases of other builtin types, such as longs and strings: >>> [ 1L : 2L<<64 : 2<<32L ] >>> ["a":"z":"b"] >>> ["a":"z":2] However, this might be too much `magic' to be obvious. Well the step argument is of debatable utility for strings but ["0":"9"] seems mildly useful. Also, it makes sense to create a range of floating point numbers. If we were going to do this, we would probably have an overloadable operator: string.__range__( start=None, end=None, step=None ) It could return a sequence of whatever kind. I'm not clear why we can't implement it as a function call to __builtins__.range . -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From ping at lfw.org Wed Jul 19 18:46:39 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 19 Jul 2000 09:46:39 -0700 (PDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.10193.715558.561239@anthem.concentric.net> Message-ID: On Wed, 19 Jul 2000, Barry A. Warsaw wrote: > > I've been thinking a little bit about the other generators, especially > irange(). I wonder if we shouldn't just be putting zip() and friends > in their own Python module and not make them builtins? I'd say put both zip() and irange() in builtins. They're useful enough. (Ideally range(), zip(), and irange() would all make generators one day, and xrange() could be deprecated.) I would prefer zip() and irange() to make generators now -- because this means you could *pass* them generators, and they wouldn't force their arguments to enumerate everything first! For example, make readlines() a generator too and you've got for lnum, line in irange(file.readlines()): print "%5d: %s" % (lnum, line), How pretty is that? There's no issue with using generators in place of lists, as far as i can tell, since (as has already been suggested) you just turn the generator into a real list if somebody calls one of the methods on it or uses it where a tuple is expected. -- ?!ng From ping at lfw.org Wed Jul 19 18:58:56 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 19 Jul 2000 09:58:56 -0700 (PDT) Subject: [Python-Dev] PEP 204 - Range Literals In-Reply-To: <3974F849.A83AC7CB@prescod.net> Message-ID: On Tue, 18 Jul 2000, Paul Prescod wrote: > Should range literals create a list of the passed-in type ? It > might be desirable in the cases of other builtin types, such as > longs and strings: > > >>> [ 1L : 2L<<64 : 2<<32L ] > >>> ["a":"z":"b"] > >>> ["a":"z":2] > > However, this might be too much `magic' to be obvious. Too much magic. Remember the analogy is with the slice operator: lst[start:end]. Only integers work there, and only integers are acceptable to range() now, so it's simpler and happier all around to keep the range literals to just integers too. > Well the step argument is of debatable utility for strings but ["0":"9"] > seems mildly useful. Also, it makes sense to create a range of floating > point numbers. Not useful enough, i think, to be worth it. If you need to do a range check, you can still say "a" <= x <= "z". When working with ranges or regions on the number line, you probably want something more specifically designed for that. (For example, you might want to talk about open, closed, or half-open intervals.) If we're going to consider the feature, E's CoordinateSpaces and Regions are worth a serious look. Hmm. I don't have a good reference on that. I'll post one when i find it. -- ?!ng From moshez at math.huji.ac.il Wed Jul 19 18:56:51 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 19:56:51 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: Message-ID: On Wed, 19 Jul 2000, Ka-Ping Yee wrote: > On Wed, 19 Jul 2000, Barry A. Warsaw wrote: > > > > I've been thinking a little bit about the other generators, especially > > irange(). I wonder if we shouldn't just be putting zip() and friends > > in their own Python module and not make them builtins? > > I'd say put both zip() and irange() in builtins. They're useful enough. One of the things I love about Python is the clean namespaces. Each builtin function takes away some of the cleanliness. It's a tradeof, but I think we should be wary of tossing stuff into builtins just because we can't find a good place for them. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Wed Jul 19 19:15:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 19 Jul 2000 19:15:23 +0200 Subject: [Python-Dev] uPEP: encoding directive References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> <3975D2A1.5DDA10E6@prescod.net> Message-ID: <001801bff1a4$ed941a20$f2a6b5d4@hagrid> paul wrote: > If we're going to restrict people to ASCII-like encodings, we > could just restrict them to ASCII and get it over with. Sorry, you lost me there... in what part(s) of the source file should we restrict users to pure ASCII? (in string literals? unicode string literals? the entire script?) From peter at schneider-kamp.de Wed Jul 19 21:27:37 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Wed, 19 Jul 2000 19:27:37 +0000 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> Message-ID: <39760129.9BA42B7E@schneider-kamp.de> Bjorn Pettersen wrote: > > I think the PEPs are a great idea, but it would be even better if they > were more accessible... How about putting them up on the beopen or > python.org site? (That way the faq can refer to them for recurring > discussions with all the arguments archived in the PEP...) How about putting them on sourceforge? python.sourceforge.net/peps/pep-0206.txt and friends What do you think? Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul at prescod.net Wed Jul 19 19:32:38 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 12:32:38 -0500 Subject: [Python-Dev] uPEP: encoding directive References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> <3975D2A1.5DDA10E6@prescod.net> <001801bff1a4$ed941a20$f2a6b5d4@hagrid> Message-ID: <3975E636.4FCF61ED@prescod.net> Fredrik Lundh wrote: > > paul wrote: > > If we're going to restrict people to ASCII-like encodings, we > > could just restrict them to ASCII and get it over with. > > Sorry, you lost me there... in what part(s) of the source file > should we restrict users to pure ASCII? > > (in string literals? unicode string literals? the entire script?) The entire script. If we're going to require a Japanse user to use 3 bytes to encode some character then we might as well require them to use backslash syntax. I mean if we're going to be revolutionary, then we could take the XML route. * require the encoding pragma to be the first line * auto-detect one-byte, two-byte based on #? * figure out precise encoding from directive Otherwise, I'm not sure if we're making enough progress. Westerners probably won't bother to put in the directive as long as their code works fine without it. -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From paul at prescod.net Wed Jul 19 19:36:10 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 12:36:10 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: Message-ID: <3975E70A.F9F8BE42@prescod.net> Moshe Zadka wrote: > > ... > > One of the things I love about Python is the clean namespaces. Each > builtin function takes away some of the cleanliness. It's a tradeof, but I > think we should be wary of tossing stuff into builtins just because we > can't find a good place for them. I feel the same way, but I hate importing basic functionality necessary for every single script, no matter what the domain. I wish there weren't so many exceptions directly in builtins. They should go in a sub-module __builtins__.exceptions . -- Paul Prescod - Not encumbered by corporate consensus Just how compassionate can a Republican get before he has to leave the GOP and join Vegans for Global Justice? ... One moment, George W. Bush is holding a get-to-know-you meeting with a bunch of gay Republicans. The next he is holding forth on education or the environment ... It is enough to make a red-blooded conservative choke on his spotted-owl drumstick. - April 29th, Economist From effbot at telia.com Wed Jul 19 19:45:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 19 Jul 2000 19:45:23 +0200 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> Message-ID: <00b801bff1a9$248f4780$f2a6b5d4@hagrid> greg wrote: > > Yes, but it would by possible to use snprintf in PyErr_Format. > > still not quite the same. /F's PyErr_Format returns an arbitrary length > string. snprintf() would be cut at some pre-specified limit. if I understood GvR correctly, the only remaining issue here is whether we need more formatting codes (PyErr_Format is undocumented, so I'm not sure we need to be backwards compatible with code outside the interpreter...) in an earlier post, I suggested adding a couple of PyErr_Format- specific formatting codes: possibly stupid idea: would it make sense to add custom formatting codes, like: %S => char*, string, clip if excessively long %T => PyObject*, show name of type, clip if excessively long where "clip" means: truncate at 80 characters, and add "..." to indicate that the string was truncated. this covers most of the places where %.\d+s are used (in the Python core, at least...) comments? From bwarsaw at beopen.com Wed Jul 19 20:46:13 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 14:46:13 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> <3975D2C9.66FE16C2@prescod.net> Message-ID: <14709.63349.415183.336374@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Why are you using zip in this case? If you *know* that you are PP> going to get back 1-tuples then you must know that the input PP> is a single list (i.e. you aren't using "apply"). So why are PP> you using zip at all? It was just an example, but I agree, you probably wouldn't use zip in this situation. My question is, why would you ever use zip with one parameter? To me, that's an argument for letting zip(a) return 1-tuples, not raising an exception. -Barry From bwarsaw at beopen.com Wed Jul 19 20:48:20 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 14:48:20 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14709.10193.715558.561239@anthem.concentric.net> Message-ID: <14709.63476.37009.258626@anthem.concentric.net> >>>>> "KY" == Ka-Ping Yee writes: KY> (Ideally range(), zip(), and irange() would all make KY> generators one day, and xrange() could be deprecated.) I agree! So maybe what we need is a general generator type written in C. Could the xrange type be subverted to this purpose? -Barry From thomas at xs4all.net Wed Jul 19 21:13:06 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 21:13:06 +0200 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <39760129.9BA42B7E@schneider-kamp.de>; from peter@schneider-kamp.de on Wed, Jul 19, 2000 at 07:27:37PM +0000 References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> Message-ID: <20000719211306.F9897@xs4all.nl> On Wed, Jul 19, 2000 at 07:27:37PM +0000, Peter Schneider-Kamp wrote: > Bjorn Pettersen wrote: > > I think the PEPs are a great idea, but it would be even better if they > > were more accessible... How about putting them up on the beopen or > > python.org site? (That way the faq can refer to them for recurring > > discussions with all the arguments archived in the PEP...) > How about putting them on sourceforge? > python.sourceforge.net/peps/pep-0206.txt and friends +1 if we can do it automatically. +0 if it has to be done by whoever commits new versions ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Wed Jul 19 21:17:37 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 21:17:37 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.63476.37009.258626@anthem.concentric.net>; from bwarsaw@beopen.com on Wed, Jul 19, 2000 at 02:48:20PM -0400 References: <14709.10193.715558.561239@anthem.concentric.net> <14709.63476.37009.258626@anthem.concentric.net> Message-ID: <20000719211736.G9897@xs4all.nl> On Wed, Jul 19, 2000 at 02:48:20PM -0400, Barry A. Warsaw wrote: > >>>>> "KY" == Ka-Ping Yee writes: > KY> (Ideally range(), zip(), and irange() would all make > KY> generators one day, and xrange() could be deprecated.) > I agree! So maybe what we need is a general generator type written in > C. Could the xrange type be subverted to this purpose? Not likely. You'd have to write the assignment functions (changing the object into a list-type if that is done) and most of the other stuff has to be rewritten: almost all of xrange() is specific for PyInt's. It stores step, start, end and repeater (for 'xrange * 10') as longs, and calculates return values for getitem and repr and the like from those. Other than a standard object boilerplate, it's pretty useless for more generic generators. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Wed Jul 19 21:47:42 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 14:47:42 -0500 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> <3975D2C9.66FE16C2@prescod.net> <14709.63349.415183.336374@anthem.concentric.net> Message-ID: <397605DE.C0DF661C@prescod.net> Barry A. Warsaw" wrote: >... > > It was just an example, but I agree, you probably wouldn't use zip in > this situation. My question is, why would you ever use zip with one > parameter? To me, that's an argument for letting zip(a) return > 1-tuples, not raising an exception. Your logic is impeccable. Also, consider this: zip( "mybigfile.xml" ) -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From bwarsaw at beopen.com Wed Jul 19 22:12:57 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 16:12:57 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14709.10193.715558.561239@anthem.concentric.net> <14709.63476.37009.258626@anthem.concentric.net> <20000719211736.G9897@xs4all.nl> Message-ID: <14710.3017.560649.169558@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> Other than a standard object boilerplate, it's pretty useless TW> for more generic generators. Urg. Oh well. From bwarsaw at beopen.com Wed Jul 19 22:14:59 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 16:14:59 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> <3975D2C9.66FE16C2@prescod.net> <14709.63349.415183.336374@anthem.concentric.net> <397605DE.C0DF661C@prescod.net> Message-ID: <14710.3139.869652.473413@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> zip( "mybigfile.xml" ) Newbie: "Why doesn't this compress my file for me?" Paul: "!" :) -Barry From thomas at xs4all.net Wed Jul 19 22:24:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 22:24:08 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <397605DE.C0DF661C@prescod.net>; from paul@prescod.net on Wed, Jul 19, 2000 at 02:47:42PM -0500 References: <14707.22821.945571.314619@anthem.concentric.net> <1248257113-63674673@hypernet.com> <14709.9149.395757.2952@anthem.concentric.net> <3975D2C9.66FE16C2@prescod.net> <14709.63349.415183.336374@anthem.concentric.net> <397605DE.C0DF661C@prescod.net> Message-ID: <20000719222408.L9897@xs4all.nl> On Wed, Jul 19, 2000 at 02:47:42PM -0500, Paul Prescod wrote: > Also, consider this: > zip( "mybigfile.xml" ) That's kinda like 'dir()', isn't it ? "I don't have those files in my directory!!?" Nevertheless, yet another reason to use marry() No confusion there! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Wed Jul 19 22:40:16 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 23:40:16 +0300 (IDT) Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) In-Reply-To: <00b801bff1a9$248f4780$f2a6b5d4@hagrid> Message-ID: On Wed, 19 Jul 2000, Fredrik Lundh wrote: > possibly stupid idea: would it make sense to add custom > formatting codes, like: > > %S => char*, string, clip if excessively long > %T => PyObject*, show name of type, clip if excessively long > > where "clip" means: > > truncate at 80 characters, and add "..." to indicate > that the string was truncated. I'm +0 on those. Seems like useful things. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Wed Jul 19 22:47:41 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 19 Jul 2000 23:47:41 +0300 (IDT) Subject: [Python-Dev] PEP 201 - Parallel iteration In-Reply-To: <14709.63349.415183.336374@anthem.concentric.net> Message-ID: On Wed, 19 Jul 2000, Barry A. Warsaw wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> Why are you using zip in this case? If you *know* that you are > PP> going to get back 1-tuples then you must know that the input > PP> is a single list (i.e. you aren't using "apply"). So why are > PP> you using zip at all? > > It was just an example, but I agree, you probably wouldn't use zip in > this situation. My question is, why would you ever use zip with one > parameter? Or, in other words, anyone using zip() with one parameter is plain nuts or made a bug. > To me, that's an argument for letting zip(a) return > 1-tuples, not raising an exception. I fail to see the logic. To me, that points at the exception route: if it's probably a bug, yell loudly. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Wed Jul 19 22:49:55 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Jul 2000 22:49:55 +0200 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) In-Reply-To: <00b801bff1a9$248f4780$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jul 19, 2000 at 07:45:23PM +0200 References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> Message-ID: <20000719224955.M9897@xs4all.nl> On Wed, Jul 19, 2000 at 07:45:23PM +0200, Fredrik Lundh wrote: > possibly stupid idea: would it make sense to add custom > formatting codes, like: > > %S => char*, string, clip if excessively long > %T => PyObject*, show name of type, clip if excessively long > > where "clip" means: > > truncate at 80 characters, and add "..." to indicate > that the string was truncated. > > this covers most of the places where %.\d+s are used (in > the Python core, at least...) +0, but I haven't enough experience with this kind of thing to have a real opinion. I guess it's better than nothing ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw at beopen.com Wed Jul 19 23:10:34 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 19 Jul 2000 17:10:34 -0400 (EDT) Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14709.63349.415183.336374@anthem.concentric.net> Message-ID: <14710.6474.635823.308717@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I fail to see the logic. To me, that points at the exception MZ> route: if it's probably a bug, yell loudly. Hmm, thinking about the ambiguity your brought up with zip-with-no-args, which I agree with more than zip-with-one-arg, I might be willing to concede the exception for anything less than 2 sequences provided. At the very least, I will work this into the PEP so Guido can rule by (informed) decree. -Barry From jack at oratrix.nl Thu Jul 20 00:03:19 2000 From: jack at oratrix.nl (Jack Jansen) Date: Thu, 20 Jul 2000 00:03:19 +0200 Subject: [Python-Dev] PyArg_ParseTuple format specifiers again Message-ID: <20000719220324.73E3E191AA8@oratrix.oratrix.nl> Of course, after I added the H specifier to PyArg_ParseTuple it turns out that solved ninetysomething% of my problems, but it turns out that what I really need is not an "unsigned short" converter but a "16 bit" converter, i.e. something that will happily accept anything from -32768 to 65535 without complaints. (The old "h" format, in other words). I need this because all the MacOS API modules are machine generated, both the C modules and the .py files with all the constants in it, and some header file authors use -1 to mean "16 1 bits", some use 0xffff. And I really don't want to hand-massage 40K lines of C and 6K lines of Python everytime a new MacOS release comes out.... And I also need such a format char for 8 bit values. Does anyone mind if I change the H specifier to do no value checking other than making sure it fits in 16 bits, and add a B specifier for unchecked bytes? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From paul at prescod.net Thu Jul 20 00:53:42 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 17:53:42 -0500 Subject: [Python-Dev] Perl rewrite Message-ID: <39763176.47254BEF@prescod.net> Interesting.... http://www.perl.org/ http://slashdot.org/article.pl?sid=00/07/19/203221&mode=nested -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From petrilli at amber.org Thu Jul 20 02:41:58 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Wed, 19 Jul 2000 20:41:58 -0400 Subject: [Python-Dev] Perl rewrite In-Reply-To: <39763176.47254BEF@prescod.net>; from paul@prescod.net on Wed, Jul 19, 2000 at 05:53:42PM -0500 References: <39763176.47254BEF@prescod.net> Message-ID: <20000719204158.A20244@trump.amber.org> Paul Prescod [paul at prescod.net] wrote: > Interesting.... > > http://www.perl.org/ > http://slashdot.org/article.pl?sid=00/07/19/203221&mode=nested I must say that Larry Wall's "keynote" was um... interesting. :-) Perhaps Guido will summarize it :-) Chris -- | Christopher Petrilli | petrilli at amber.org From paul at prescod.net Thu Jul 20 03:06:47 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 19 Jul 2000 20:06:47 -0500 Subject: [Python-Dev] Perl rewrite References: <39763176.47254BEF@prescod.net> <20000719204158.A20244@trump.amber.org> Message-ID: <397650A7.9A32E3B@prescod.net> Christopher Petrilli wrote: > >... > > I must say that Larry Wall's "keynote" was um... interesting. :-) > Perhaps Guido will summarize it :-) Then we'll have to wait a week! What are the high points? -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From petrilli at amber.org Thu Jul 20 08:20:06 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Thu, 20 Jul 2000 02:20:06 -0400 Subject: [Python-Dev] Perl rewrite In-Reply-To: <397650A7.9A32E3B@prescod.net>; from paul@prescod.net on Wed, Jul 19, 2000 at 08:06:47PM -0500 References: <39763176.47254BEF@prescod.net> <20000719204158.A20244@trump.amber.org> <397650A7.9A32E3B@prescod.net> Message-ID: <20000720022005.B20244@trump.amber.org> Paul Prescod [paul at prescod.net] wrote: > Christopher Petrilli wrote: > > > >... > > > > I must say that Larry Wall's "keynote" was um... interesting. :-) > > Perhaps Guido will summarize it :-) > > Then we'll have to wait a week! What are the high points? He knows how to snap, and beat sticks together... :-) Chris -- | Christopher Petrilli | petrilli at amber.org From paul at prescod.net Thu Jul 20 08:35:28 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 01:35:28 -0500 Subject: [Python-Dev] PEP-able Message-ID: <39769DB0.BCE7FB38@prescod.net> PEP: ??? Title: Computed Attributes Version: $Revision: 1.0 $ Owner: paul at prescod.net Python-Version: 2.0 Status: Incomplete Introduction This PEP describes a feature to make it easier to use Python attribute set/get/del syntax to fetch the results of a computation or to invoke computation. This feature has been emulated using __getattr__/__setattr__/__delattr__ but this approach suffers severe usability and performance concerns. Syntax Special methods should declare themselves with declarations of the following form: class x: def __get_foo__(self ): ... def __set_foo__(self, value ): ... def __del_foo__(self ): ... They are used like this: fooval=x.foo x.foo=fooval+5 del x.foo Semantics References of the sort x.y should be taken, if x is an instance type of a class with a __get_y__ method as being equivalent to a call to that method. Code that assigns to y should instead call __set_y__ if that method is defined on x's class. Code that deletes x.y should call __del_y__ if that method is defined on x's class. It is disallowed to actually have an attribute named y in the dictionary for reasons that will become clear when we discuss the implementation. It is not required that every special method have two more matching special methods. If one is declared then the other two operations are effectively prohibited and will raise an exception. This is an easy way to make read-only (or even write-only or delete-only) attributes. An implementation of __get_y__ takes precedence over an implementation of __getattr__ based on the principle that __getattr__ is supposed to be invoked only after finding an appropriate attribute has failed. This is important for acceptable performance. An implementation of __set_y__ takes precedence over an implementation of __setattr__ in order to be consistent. The opposite choice seems fairly feasible also, however. The same goes for __del_y__. Proposed Implementation There is a new object called a computed attribute object. It has three attributes: get, set, delete. In PyClass_New, methods of the appropriate form will be detected and converted into objects (just like unbound method objects). Matching methods go in the same computed attribute object and missing methods are replaced with a stub that throws the TypeError. If there are any computed attributes at all, a flag is set. Let's call it "I_have_computed_attributes" for now. A get proceeds as usual until just before the object is returned. In addition to the current check whether the returned object is a method it would also check whether a returned object is a computed attribute. If so, it would invoke the getter method and return the value. To remove a computed attribute object you could directly fiddle with the dictionary. A set proceeds by checking the "I_have_computed_attributes" flag. If it is not set, everything proceeds as it does today. If it is set then we must do a dictionary get on the requested object name. If it returns a computed method attribute then we call the setter function with the value. If it returns any other object then we discard the result and continue as we do today. The I_have_computed_attributes flag is intended to eliminate the performance degradation of an extra "get" per "set" for objects not using this feature. You might note that I have not proposed any logic to keep this flag up to date as attributes are added and removed from the instance's dictionary. This is consistent with current Python. If you add a __setattr__ method to an object after it is in use, that method will not behave as it would if it were available at "compile" time. The implementation of delete is analogous to the implementation of set. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 08:51:33 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 01:51:33 -0500 Subject: [Python-Dev] Consistency questions Message-ID: <3976A175.12D4DB53@prescod.net> #1. Why does can I overwrite the "standard output object" with assignment syntax sys.stdout=mystdoutobj But I have to add a profile function with function syntax: sys.setprofile( myprofilefunc ) #2. Why doesn't dir( obj ) return inherited methods? -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From peter at schneider-kamp.de Thu Jul 20 10:53:11 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 20 Jul 2000 08:53:11 +0000 Subject: [Python-Dev] questionnaire about zip and for loops Message-ID: <3976BDF7.82FB6C56@schneider-kamp.de> This is a slightly reduced version of a questionnaire run by Greg Wilson on some CS grad students. I'd like to use the readers of comp.lang.python as guinea pigs this time. PLEASE SEND THE RESULTS TO mailto:peter at schneider-kamp.de - DON'T SEND THEM TO THE LIST Thanks for your time, Peter ----------------------------------------------------------------------------------------- The single and double loop below print the output shown: for x in [10, 20, 30]: for x in [10, 20, 30]: print x for y in [1, 2, 3]: print x+y 10 11 20 12 30 13 21 22 23 31 32 33 Match each of the following example for-loops to an output. Only make one cross per line. Please consider each example on its own. (Note that several examples may print the same thing.) (1) (2) (3) (4) (5) (6) 11 11 11 11 error ?? 22 12 22 12 33 13 21 21 22 22 31 23 32 31 32 33 (A) for (x, y) in [[10, 1], [20, 2], [30, 3]]: o o o o o o print x+y (B) for [x, y] in zip([10, 20, 30], [1, 2, 3]): o o o o o o print x+y (C) for [x, y] in zip([10, 20, 30], [1, 2]): o o o o o o print x+y (D) for x; y in [10, 20, 30]; [1, 2, 3]: o o o o o o print x+y (E) for x; y in [10, 20, 30]; [1, 2]: o o o o o o print x+y (F) for x in [10, 20, 30]; y in [1, 2, 3]: o o o o o o print x+y (G) for x in [10, 20, 30]; y in [1, 2]: o o o o o o print x+y -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mwh21 at cam.ac.uk Thu Jul 20 09:00:26 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 20 Jul 2000 08:00:26 +0100 Subject: [Python-Dev] PEP-able In-Reply-To: Paul Prescod's message of "Thu, 20 Jul 2000 01:35:28 -0500" References: <39769DB0.BCE7FB38@prescod.net> Message-ID: Paul Prescod writes: > PEP: ??? > Title: Computed Attributes > Version: $Revision: 1.0 $ > Owner: paul at prescod.net > Python-Version: 2.0 > Status: Incomplete +1! (you beat me to it...) M. -- On the other hand, the following areas are subject to boycott in reaction to the rampant impurity of design or execution, as determined after a period of study, in no particular order: ... http://www.naggum.no/profile.html From peter at schneider-kamp.de Thu Jul 20 11:44:31 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 20 Jul 2000 09:44:31 +0000 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> Message-ID: <3976C9FF.A7799738@schneider-kamp.de> Thomas Wouters wrote: > > On Wed, Jul 19, 2000 at 07:27:37PM +0000, Peter Schneider-Kamp wrote: > > > > How about putting them on sourceforge? > > python.sourceforge.net/peps/pep-0206.txt and friends > > +1 if we can do it automatically. +0 if it has to be done by whoever commits > new versions ;) I can do it (and keep up with the changes) for now. But in the long run this probably should be automated. I only see the password barrier: scp pep-*.txt nowonder at shell.sourceforge.net:/home/groups/python/htdocs/peps will make me enter my password/passphrase. How would one go about doing something like that? One "solution" I can think of is to checkout a copy of nondist/peps from the CVS to htdocs/peps. Then the peps could be held up to date by running cvs up in that directory once a day (or 4 times a day). But this would require some action of SF to add it to their cron, wouldn't it?! Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From thomas at xs4all.net Thu Jul 20 10:35:46 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 10:35:46 +0200 Subject: [Python-Dev] Consistency questions In-Reply-To: <3976A175.12D4DB53@prescod.net>; from paul@prescod.net on Thu, Jul 20, 2000 at 01:51:33AM -0500 References: <3976A175.12D4DB53@prescod.net> Message-ID: <20000720103546.N9897@xs4all.nl> On Thu, Jul 20, 2000 at 01:51:33AM -0500, Paul Prescod wrote: > #1. Why does can I overwrite the "standard output object" with > assignment syntax > sys.stdout=mystdoutobj > But I have to add a profile function with function syntax: > sys.setprofile( myprofilefunc ) There is a slight difference in semantics: sys.stdout is occasionally read by a function or stmt that wants to write to stdout. Changing it doesn't actually change something in the interpreter. sys.setprofile(), however, has to change something in the current threadstate. It's not something that's read from the sys module every time it's used, but rather an accompanying variable that has to be set as well. > #2. Why doesn't dir( obj ) return inherited methods? Because inherited methods (and other inherited attributes) aren't stored in an instance's __dict__. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm at hypernet.com Thu Jul 20 15:43:33 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 20 Jul 2000 09:43:33 -0400 Subject: [Python-Dev] PEP-able In-Reply-To: <39769DB0.BCE7FB38@prescod.net> Message-ID: <1248021882-9357610@hypernet.com> Paul Prescod wrote: [Title: Computed Attributes] > Semantics > It is disallowed to actually have an attribute named y in the > dictionary for reasons that will become clear when we discuss > the implementation. What happens here (and when): class A: y = None class B(A): def __XXX_y__(self): ... > An implementation of __get_y__ takes precedence over an > implementation of __getattr__ based on the principle that > __getattr__ is supposed to be invoked only after finding an > appropriate attribute has failed. This is important for > acceptable performance. Hmmm. Current Python: search for y fails, try __getattr__. Proposed: search for y fails, try the __get_y__, then __getattr__. We've still done the same work before trying the hook, so how is performance affected? Or are you proposing to try the hook first, thus improving performance for hooked attributes at the price of degrading performance for all non- hooked attributes? > Proposed Implementation > > There is a new object called a computed attribute object. It > has three attributes: get, set, delete. In PyClass_New, > methods of the appropriate form will be detected and > converted into objects (just like unbound method objects). > Matching methods go in the same computed attribute object and > missing methods are replaced with a stub that throws the > TypeError. If there are any computed attributes at all, a > flag is set. Let's call it "I_have_computed_attributes" for > now. class A: def __get_y__(self): ... class B(A): def __set_y__(self, value): .... Notice a problem here? Is it B's author's intent to make a read- only attribute read-write (in which case the accessor object probably needs to get copied from A.__dict__ to B.__dict__ so as not to interfere with other derived classes)? Or do we assume he wants to make it write-only, and to make it read- write does he need to do: class B(A): def __set_y__(self, value): .... def __get_y__(self): return A.__get_y__(self) (which involves another wrinkle, because there is no attribute "__get_y__" in class A). - Gordon From skip at mojam.com Thu Jul 20 16:12:02 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 20 Jul 2000 09:12:02 -0500 (CDT) Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <3976C9FF.A7799738@schneider-kamp.de> References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> Message-ID: <14711.2226.242735.766934@beluga.mojam.com> Peter> But in the long run this probably should be automated. I only see Peter> the password barrier: Peter> scp pep-*.txt nowonder at shell.sourceforge.net:/home/groups/python/htdocs/peps Peter> will make me enter my password/passphrase. Peter> How would one go about doing something like that? Assuming you are running on some Unix flavor, use ssh-agent to start your X session: ssh-agent startx and in your .xinitrc file (or equivalent) execute ssh-add References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> Message-ID: <14711.2370.880455.337906@beluga.mojam.com> >> #2. Why doesn't dir( obj ) return inherited methods? Thomas> Because inherited methods (and other inherited attributes) Thomas> aren't stored in an instance's __dict__. dir() *could* be smarter and walk up the chain starting at __class__ looking for useful stuff to include. Unfortunately, dir() is written in C so it's harder to modify than it ought to be... Skip From guido at beopen.com Thu Jul 20 16:52:00 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 20 Jul 2000 07:52:00 -0700 Subject: [Python-Dev] Fw: CVS commit backout trivia Message-ID: <008601bff25a$0f770520$3e2c4fce@beopen.com> I haven't tried the suggestion below but seems like a good idea, and could be added to our SF FAQ... --Guido ----- Original Message ----- From: "Mitchell Morris" To: Sent: Wednesday, July 19, 2000 3:52 PM Subject: CVS commit backout trivia > I was reading through the python-dev archives today and saw a message from > you dated 2000-07-10 about backing out a CVS commit with "cvs admin -o" and > wanted to point out that there is a more history-friendly mechanism: "cvs > update -j -j filename". The update > command will apply the diffs between and in reverse > order. That way you don't branch or set sticky tags that have to be cleaned > up after. > > hoping-this-is-of-some-miniscule-help-ly y'rs > +Mitchell From paul at prescod.net Thu Jul 20 17:12:38 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 10:12:38 -0500 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> Message-ID: <397716E6.F19E25BE@prescod.net> Gordon McMillan wrote: > > What happens here (and when): > class A: > y = None > class B(A): > def __XXX_y__(self): > ... I would say that the latter would just take precedence over the former as if you had typed: class B(A): __XXX_y__=ComputedAttribute( foo, bar, baz ) > Hmmm. Current Python: search for y fails, try __getattr__. > Proposed: search for y fails, try the __get_y__, then > __getattr__. We've still done the same work before trying the > hook, so how is performance affected? Actually, I was justifying Python's current behavior as much as I was the current behavior. A truly general __getattr__ would access all attribute tests, not just non-existent attributes and thus be symmetric with setattr. But that would also be slow as hell. > class A: > def __get_y__(self): > ... > class B(A): > def __set_y__(self, value): > .... My first instinct is just to disallow this and figure it out after we have some more usage information/implementation resources. We could just say that all methods must be defined in the same class and if not. In other words, the methods "shadow each other" as a group. This is no more messy than inherited __getattr__ s. My second thought is to have the constructor for computed attributes objects look for a computed attribute higher in the tree and copy in the appropriate fields. Prohibiting it might be clearest for all concerned. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From thomas at xs4all.net Thu Jul 20 17:21:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 17:21:08 +0200 Subject: [Python-Dev] Consistency questions In-Reply-To: <14711.2370.880455.337906@beluga.mojam.com>; from skip@mojam.com on Thu, Jul 20, 2000 at 09:14:26AM -0500 References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> Message-ID: <20000720172108.S9897@xs4all.nl> On Thu, Jul 20, 2000 at 09:14:26AM -0500, Skip Montanaro wrote: > >> #2. Why doesn't dir( obj ) return inherited methods? > Thomas> Because inherited methods (and other inherited attributes) > Thomas> aren't stored in an instance's __dict__. > dir() *could* be smarter and walk up the chain starting at __class__ looking > for useful stuff to include. Unfortunately, dir() is written in C so it's > harder to modify than it ought to be... I would suggest adding a second, optional argument to dir(), 'recurse' or such, to add that behaviour. I think I can add that code to dir() if it's deemed a good idea ;) Turning it on by default would probably break too much code. Opinions ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From trentm at ActiveState.com Thu Jul 20 17:29:37 2000 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 20 Jul 2000 08:29:37 -0700 Subject: [Python-Dev] PyArg_ParseTuple format specifiers again In-Reply-To: <20000719220324.73E3E191AA8@oratrix.oratrix.nl> References: <20000719220324.73E3E191AA8@oratrix.oratrix.nl> Message-ID: <20000720082937.A22151@ActiveState.com> On Thu, Jul 20, 2000 at 12:03:19AM +0200, Jack Jansen wrote: > Of course, after I added the H specifier to PyArg_ParseTuple it turns > out that solved ninetysomething% of my problems, but it turns out that > what I really need is not an "unsigned short" converter but a "16 bit" > converter, i.e. something that will happily accept anything from > -32768 to 65535 without complaints. (The old "h" format, in other > words). > That is too bad that the unsigned OR signed decision could not be made. > I need this because all the MacOS API modules are machine generated, > both the C modules and the .py files with all the constants in it, and > some header file authors use -1 to mean "16 1 bits", some use > 0xffff. And I really don't want to hand-massage 40K lines of C and 6K > lines of Python everytime a new MacOS release comes out.... Very fair. > > And I also need such a format char for 8 bit values. > > Does anyone mind if I change the H specifier to do no value checking > other than making sure it fits in 16 bits, and add a B specifier for > unchecked bytes? Now I think that the best answer is to have a separate PyArg_UncheckedParseTuple() that gives you what you want Jack. Or, maybe more easily, PyArg_ParseTuple could revert to the 1.5.2 form and not do bounds checking and a new PyArg_CheckedParseTuple could do bounds checking. Actually, yes, the latter is a better idea. It would allow us to clean up the L as unsigned long rather than LONG_LONG issue if we wanted. Thereafter PyArg_CheckedParseTuple would be the preferred method if possible. Hence, PyArg_ParseTuple(): b - byte h - short i - int l - long L - LONG_LONG Pros: - This is as in 1.5.2. All the values are either not bounds checked at all or (maybe a little better) checked to be within [XXX_MIN, UXXX_MAX], i.e. in the range of the union of the signed and unsigned ranges. This will be backward compatible and only break code that had an overflow bug in it anyway. - It should make Jack happy, except that he would now have to go change all his 'H's back to 'h's. :( PyArg_CheckedParseTuple(): b - signed byte B - unsigned byte h - signed short H - unsigned short i - signed int I - unsigned int l - signed long L - unsigned long q - signed LONG_LONG Q - unsigned LONG_LONG Pros: - b,h,i,l and the capital equivs are the same as the formatters in the struct module for consistency - the use of capital for unsigned version of all the variables is intuitive (or at least straight forward and consistent) - q,Q for a 'quad' or long long is better than the current 'L' Cons: - New function may raise questions of "which do I use PyArg_ParseTuple or PyArg_CheckedParseTuple?" This is a documentation issue. - New function may require parallel maintenance in both functions. Or maybe not if one is made to use the other (efficiency prob?) - 'L' has changed meaning from one function to the other. I would propose just leaving is as is for 2.0 (unless the code breakage is okay) and then change 'L' in PyArg_ParseTuple to mean 'unsigned long' in Py3k. I can code this up after the O'Reilly conference if people (Jack, Guido, Tim, others?) think that this is a good idea. Trent -- Trent Mick TrentM at ActiveState.com From mal at lemburg.com Thu Jul 20 17:33:54 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 17:33:54 +0200 Subject: [Python-Dev] Will Python die? References: <3974808D.5D49575D@schneider-kamp.de> Message-ID: <39771BE2.A80ADD92@lemburg.com> Peter Schneider-Kamp wrote: > > Moshe Zadka wrote: > > > > My fault -- I stopped reading /. Can you summarize the thread? > > The thread is about if Visual Python is an alternative for > Visual Basic or, if not, it can be used as that. > > A subthread of this thread dealt with Pythons release schedule: > "Speaking of Python, does anyone know what's up with Python 1.6^H^H2.0? > A while back, python.org had said that version 1.6 would be out on > June 1. Then there was an announcement, mid-June that it would be > delayed. Then at the end of June, this link was placed on python.org, > and it was stated that the Python interpreter, version 1.6, was > renamed to 2.0, and the first beta would be available on July 1. Now, > on July 17, that link has been removed from python.org (although the > webpage still exists), and the release schedule is gone!" > > Quoting from relevant replies: > "python 1.6 will be out in august > check the downloads page of www.python.org > or checkout the pythonlabs at www.beopen.com > where most of the core python developers opened shop" > > "Yeah, the Python 1.6 download page says that Python 1.6 beta1 will be > done on July 1, and beta 2 on July 14. It's July 17 now, and the only > available download is alpha 2...." You may not have noticed, but the 2.0beta1 is already available to the public: just download the most recent CVS version (or the tarball from David Ascher's starship page). About the schedule: I think we'll know more after the Python Consortium Meeting. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 20 17:37:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 17:37:50 +0200 Subject: [Python-Dev] map() for methods References: <20000718130059.B7340@xs4all.nl> <14708.40190.852802.966575@beluga.mojam.com> Message-ID: <39771CCE.F70A48D4@lemburg.com> Skip Montanaro wrote: > > Moshe> In fact, putting an implementation of pad() like that in the > Moshe> string.py module would be wonderful, because it would work with > Moshe> both regular strings and unicode. However, string.py is looking > Moshe> as though as it's going to be deprecated. In short, I'd want > Moshe> Guido/Tim/effbot/MAL opinions here before we make a move. > > Don't know about the powers that be, but I don't see how you can > realistically deprecate string.py until you deprecate map(). My most > frequent use of map() is the simple > > newlist = map(string.strip, oldlist) > > where oldlist is a list of strings. (Replace "strip" by "upper", "lower", > etc, depending on your needs.) > > As far as I'm aware, there's no clean way to do that with string methods. True, we'll need somthing like this for methods too... e.g. like the following API in mx.Tools: method_mapply(objects,methodname[,args=(),kw={}]) Creates a tuple of values by applying the given arguments to each object's method. The objects are processed as given in the sequence objects. A simple application is e.g. method_mapply([a,b,c],'method', (x,y)) resulting in a tuple (a.method(x,y), b.method(x,y), c.method(x,y)). Thanks to Aaron Waters for suggesting this function. The name is clumsy... suggestions welcome :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 20 17:49:20 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 17:49:20 +0200 Subject: [Python-Dev] Coercion (RE: Discussion: Introducing new operators for matrix computation) References: Message-ID: <39771F80.90DD0C99@lemburg.com> [Adding new operators] Just a side note before everyone forgets: I think we'll need to carefully redefine coercion *before* adding any new slots/operators/etc. to Python. The current model where coercion is centralized won't scale well with the new operators. My (old) proposal for this (see my Python Pages) was to decentralize coercion and make the coercion process part of the operators task. Thoughts ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Thu Jul 20 17:50:58 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 20 Jul 2000 10:50:58 -0500 (CDT) Subject: [Python-Dev] Consistency questions In-Reply-To: <20000720172108.S9897@xs4all.nl> References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> <20000720172108.S9897@xs4all.nl> Message-ID: <14711.8162.800169.884936@beluga.mojam.com> Thomas> I would suggest adding a second, optional argument to dir(), Thomas> 'recurse' or such, to add that behaviour. I think I can add that Thomas> code to dir() if it's deemed a good idea ;) Turning it on by Thomas> default would probably break too much code. I don't think so. I suspect most people use dir() interactively to see what attributes an object supports and would appreciate the improved functionality. Besides, we are talking 2.0 here. Nothing wrong with a little breakage... ;-) Skip From jack at oratrix.nl Thu Jul 20 17:51:39 2000 From: jack at oratrix.nl (Jack Jansen) Date: Thu, 20 Jul 2000 17:51:39 +0200 Subject: [Python-Dev] PyArg_ParseTuple format specifiers again In-Reply-To: Message by Trent Mick , Thu, 20 Jul 2000 08:29:37 -0700 , <20000720082937.A22151@ActiveState.com> Message-ID: <20000720155140.73BA837186E@snelboot.oratrix.nl> Hmm. I think that having separate PyArg_ParseTuple and PyArg_UncheckedParseTuple is absolute overkill. Also, I think the functionality of having the checks is a fine one, I was at the time grumbling about it being a backward-incompatible change, and moreover one that caused me a lot of work at a time that I had more than enough other things to do. But now that the work is done I see no reason to revert it. If we'd want to do a complete set of arguments for each of 8, 16 and 32 bit integers we would have 3 specifiers: signed, unsigned and bitpattern. As it stands now we have: signed unsign bitpattern 8bit - b - 16bit h H - 32bit - - l (note the last one: 32bit values are in essence not checked because the parser happily stuffs 0xffffffff into a long). What I would be happy with is to have "natural" (unsigned for char, signed for other types) and bitpattern, so natural bitpattern 8bit b B 16bit h H 32bit l L I agree about breaking L: it's there but in the standard distribution it isn't used a single time. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From mal at lemburg.com Thu Jul 20 17:58:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 17:58:39 +0200 Subject: [Python-Dev] PEP 201 - Parallel iteration References: <14707.22821.945571.314619@anthem.concentric.net> <14709.10193.715558.561239@anthem.concentric.net> <20000718235317.A7561@lyra.org> Message-ID: <397721AF.9F6D023E@lemburg.com> Greg Stein wrote: > > On Wed, Jul 19, 2000 at 12:00:17AM -0400, Barry A. Warsaw wrote: > > >>>>> "MZ" == Moshe Zadka writes: > > > > MZ> I'm +1 on that. One thing that bugs me is that we're adding a > > MZ> builtin type. Why not stick with the Python implementation? > > > > I've been thinking a little bit about the other generators, especially > > irange(). I wonder if we shouldn't just be putting zip() and friends > > in their own Python module and not make them builtins? > > Which are you proposing: > > 1) implement in a Python module. clients use some_module.zip() > 2) implement in a Python module. insert into builtins. clients use zip(). FYI, mx.Tools implements 1) + 2). I usually put the "rom mx.Tools import NewBuiltins" at the top of the module source file so that it becomes clear that the module uses the set of new builtins available through mx.Tools. YMMV. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 20 18:07:11 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 18:07:11 +0200 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> Message-ID: <397723AF.4B11379A@lemburg.com> Fredrik Lundh wrote: > > greg wrote: > > > > Yes, but it would by possible to use snprintf in PyErr_Format. > > > > still not quite the same. /F's PyErr_Format returns an arbitrary length > > string. snprintf() would be cut at some pre-specified limit. > > if I understood GvR correctly, the only remaining issue here > is whether we need more formatting codes > > (PyErr_Format is undocumented, so I'm not sure we need to > be backwards compatible with code outside the interpreter...) > > comments? How about this: You add your new PyErr_Format() replacement with the existing subset of codes, but instead of bailing out when the function sees a format code it doesn't understand, you use sprintf() or snprintf() (where available) to format the unkown code ?! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From donb at init.com Thu Jul 20 18:11:38 2000 From: donb at init.com (Donald Beaudry) Date: Thu, 20 Jul 2000 12:11:38 -0400 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> <397716E6.F19E25BE@prescod.net> Message-ID: <200007201611.MAA26587@zippy.init.com> Paul Prescod wrote, > My first instinct is just to disallow this and figure it out after > we have some more usage information/implementation resources. We > could just say that all methods must be defined in the same class > and if not. In other words, the methods "shadow each other" as a > group. One way of doing that, which I feel also makes things a bit more obvious, is to allow only a single routine per attribute: __attr_XXX__. Here's an example: def __attr_foo__(self, op, value=None): if op is 'get': return self.compute() elif op is 'set': self.adjust(value) else: self.do_the_del_thing() String interning makes the op tests quite fast. > My second thought is to have the constructor for computed attributes > objects look for a computed attribute higher in the tree and copy in > the appropriate fields. That sounds fragile and would create "book keeping" problems if maintaining the current level of dynamic attribute magic is desired. > Prohibiting it might be clearest for all concerned. I agree that prohibiting it is the right idea. The question is how. Permitting only one routine per attribute lets the traditional attribute lookup rules work and thus prevents head scratching when trying to find the code that actually maintains an attribute. The cost is some additional burden on the writer of the __attr_XXX method (and some magic to distinguish the del case). -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb at init.com Lexington, MA 02421 ...Will hack for sushi... From peter at schneider-kamp.de Thu Jul 20 20:51:21 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 20 Jul 2000 18:51:21 +0000 Subject: [Python-Dev] PEPs on the web Message-ID: <39774A29.86E469BB@schneider-kamp.de> I have put up the PEPs on http://python.sourceforge.net/peps/ Three questions remain: 1) Is that okay? No one cried out aloud and I got some agreement. 2) Should I put a link from http://python.sourceforge.net ? 3) What about making those PEPs xhtml (or something like that)? Pros: - links from pep-000.txt - links from the other peps Cons: - harder to read in checkins - harder to edit (maybe we could use as little markup as possible?) Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gmcm at hypernet.com Thu Jul 20 19:03:13 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 20 Jul 2000 13:03:13 -0400 Subject: [Python-Dev] Consistency questions In-Reply-To: <14711.8162.800169.884936@beluga.mojam.com> References: <20000720172108.S9897@xs4all.nl> Message-ID: <1248009902-10078204@hypernet.com> Skip Montanaro wrote: > > Thomas> I would suggest adding a second, optional argument to > dir(), Thomas> 'recurse' or such, to add that behaviour. I > think I can add that Thomas> code to dir() if it's deemed a > good idea ;) Turning it on by Thomas> default would probably > break too much code. > > I don't think so. I suspect most people use dir() interactively > to see what attributes an object supports and would appreciate > the improved functionality. Besides, we are talking 2.0 here. > Nothing wrong with a little breakage... ;-) In the std lib: cmd.py (already looks in __class__ and __bases__), rlcompleter (doesn't), rexec (only invoked on modules?). It seems a gratuitous breakage, since it's additional behavior, not fixed behavior. - Gordon From gmcm at hypernet.com Thu Jul 20 19:03:13 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 20 Jul 2000 13:03:13 -0400 Subject: [Python-Dev] Computed-attributes In-Reply-To: <397716E6.F19E25BE@prescod.net> Message-ID: <1248009900-10078307@hypernet.com> Paul Prescod wrote: > Gordon McMillan wrote: > > > > What happens here (and when): > > class A: > > y = None > > class B(A): > > def __XXX_y__(self): > > ... > > I would say that the latter would just take precedence over the > former as if you had typed: > > class B(A): > __XXX_y__=ComputedAttribute( foo, bar, baz ) OK. I gather that the ComputedAttribute is actually named after the attribute. So in this situation, "y" is found in B.__dict__, and is a ComputedAttribute which hides A's (normal) attribute. Then: class A: def __init__(self): self.y = class B(A): def __set_y__(self, value): ... def __init__(self): A.__init__(self) means that the hook in B will be invoked when A.__init__ runs. I wonder what "gotchas" lie in wait ;-). > > Hmmm. Current Python: search for y fails, try __getattr__. > > Proposed: search for y fails, try the __get_y__, then > > __getattr__. We've still done the same work before trying the > > hook, so how is performance affected? I hadn't realized when I wrote that that the ComputedAttribute would have the attribute's name. That does make getattr faster. But: > Actually, I was justifying Python's current behavior as much as I > was the current behavior. A truly general __getattr__ would > access all attribute tests, not just non-existent attributes and > thus be symmetric with setattr. But that would also be slow as > hell. I use __getattr__ most often to do lazy evaluation. So: def __getattr__(self, nm): if nm == 'doohickies': rslt = self.doohickies = return rslt Yes, you can do this either way, but I rather like the fact that it's a last resort hook. > > class A: > > def __get_y__(self): > > ... > > class B(A): > > def __set_y__(self, value): > > .... > > My first instinct is just to disallow this and figure it out > after we have some more usage information/implementation > resources. We could just say that all methods must be defined in > the same class and if not. In other words, the methods "shadow > each other" as a group. > > This is no more messy than inherited __getattr__ s. Not at all. The complexity of doing __getattr__ and __setattr__ hooks is all in the class you implement them in. There's no *new* complexity in going to base class implementations - you just chain as usual. The only surprise might be that if the hapless subclasser doesn't realize that some base class has a __setattr__ hook set. I'm not against this proposal. But I think there are *no* "safe" ways of doing attr hacks; and simply getting to "safer" may be a whole lot of work. [I also note that there are quite a few Python developers who want their users to say "x = obj.getx()", but want Python to create the accessor method "getx(self)" (if they haven't written one) and outlaw "x = obj.x". I have no sympathy for them, but they exist.] - Gordon From gmcm at hypernet.com Thu Jul 20 19:03:13 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 20 Jul 2000 13:03:13 -0400 Subject: [Python-Dev] Consistency questions In-Reply-To: <20000720172108.S9897@xs4all.nl> References: <14711.2370.880455.337906@beluga.mojam.com>; from skip@mojam.com on Thu, Jul 20, 2000 at 09:14:26AM -0500 Message-ID: <1248009898-10078427@hypernet.com> Thomas Wouters wrote: [ Why doesn't dir( obj ) return inherited methods? ] > I would suggest adding a second, optional argument to dir(), > 'recurse' or such, to add that behaviour. I think I can add that > code to dir() if it's deemed a good idea ;) Turning it on by > default would probably break too much code. I strongly agree with the last sentence. I'm only +0 on the enhancement (Mark's got that in PythonWin, and I hardly ever use it). - Gordon From mal at lemburg.com Thu Jul 20 19:05:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 19:05:37 +0200 Subject: [Python-Dev] PEP-able References: <39769DB0.BCE7FB38@prescod.net> Message-ID: <39773161.1DA45DE6@lemburg.com> Paul Prescod wrote: > > PEP: ??? > Title: Computed Attributes > Version: $Revision: 1.0 $ > Owner: paul at prescod.net > Python-Version: 2.0 > Status: Incomplete > > Introduction > > This PEP describes a feature to make it easier to use Python > attribute set/get/del syntax to fetch the results of a computation > or to invoke computation. This feature has been emulated using > __getattr__/__setattr__/__delattr__ but this approach suffers > severe usability and performance concerns. > > Syntax > > Special methods should declare themselves with declarations of the > following form: > > class x: > def __get_foo__(self ): ... def __set_foo__(self, value ): ... > def __del_foo__(self ): ... > > They are used like this: > > fooval=x.foo > x.foo=fooval+5 > del x.foo I don't get the point: how is this better than defining explicit access methods ? get_foo(self) set_foo(self, value) del_foo(self) These not only define a distinct interface, but also provide more flexibility, e.g. get_foo() could have a default argument. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 20 19:13:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 19:13:23 +0200 Subject: [Python-Dev] Consistency questions References: <3976A175.12D4DB53@prescod.net> Message-ID: <39773333.ABFDD65D@lemburg.com> Paul Prescod wrote: > > #1. Why does can I overwrite the "standard output object" with > assignment syntax > > sys.stdout=mystdoutobj > > But I have to add a profile function with function syntax: > > sys.setprofile( myprofilefunc ) .set/get APIs usually interface to C flags or variables which are not meant to be used directly (often due to performance reasons). > #2. Why doesn't dir( obj ) return inherited methods? Maybe because inherited methods are not local to the object. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mwh21 at cam.ac.uk Thu Jul 20 19:17:54 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 20 Jul 2000 18:17:54 +0100 Subject: [Python-Dev] Consistency questions In-Reply-To: "Gordon McMillan"'s message of "Thu, 20 Jul 2000 13:03:13 -0400" References: <20000720172108.S9897@xs4all.nl> <1248009902-10078204@hypernet.com> Message-ID: "Gordon McMillan" writes: > Skip Montanaro wrote: > > > > > Thomas> I would suggest adding a second, optional argument to > > dir(), Thomas> 'recurse' or such, to add that behaviour. I > > think I can add that Thomas> code to dir() if it's deemed a > > good idea ;) Turning it on by Thomas> default would probably > > break too much code. > > > > I don't think so. I suspect most people use dir() interactively > > to see what attributes an object supports and would appreciate > > the improved functionality. Besides, we are talking 2.0 here. > > Nothing wrong with a little breakage... ;-) > > In the std lib: > cmd.py (already looks in __class__ and __bases__), > rlcompleter (doesn't), Yes it does! (at least in CVS; that was my first patch to Python...) > rexec (only invoked on modules?). > > It seems a gratuitous breakage, since it's additional behavior, > not fixed behavior. Gentle agreement. Cheers, M. -- After a heavy night, I travelled on, my face toward home - the comma being by no means guaranteed. -- paraphrased from cam.misc From paul at prescod.net Thu Jul 20 19:21:07 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:21:07 -0500 Subject: [Python-Dev] map() for methods References: <20000718130059.B7340@xs4all.nl> <14708.40190.852802.966575@beluga.mojam.com> <39771CCE.F70A48D4@lemburg.com> Message-ID: <39773503.8738E2F5@prescod.net> "M.-A. Lemburg" wrote: > > > True, we'll need somthing like this for methods too... e.g. > like the following API in mx.Tools: > > method_mapply(objects,methodname[,args=(),kw={}]) > ... > > The name is clumsy... suggestions welcome :-) How about this name: "list comprehension." -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From thomas at xs4all.net Thu Jul 20 20:36:17 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 20:36:17 +0200 Subject: [Python-Dev] Coercion (RE: Discussion: Introducing new operators for matrix computation) In-Reply-To: <39771F80.90DD0C99@lemburg.com>; from mal@lemburg.com on Thu, Jul 20, 2000 at 05:49:20PM +0200 References: <39771F80.90DD0C99@lemburg.com> Message-ID: <20000720203617.U9897@xs4all.nl> On Thu, Jul 20, 2000 at 05:49:20PM +0200, M.-A. Lemburg wrote: > [Adding new operators] > Just a side note before everyone forgets: I think we'll > need to carefully redefine coercion *before* adding any > new slots/operators/etc. to Python. > The current model where coercion is centralized won't > scale well with the new operators. My (old) proposal for this > (see my Python Pages) was to decentralize coercion and > make the coercion process part of the operators task. > Thoughts ? Agreed. I also think, but that's a personal opinion, that adding new operators should be done carefully, and I'm not sure if 2.0 is the right time for it. It depends on how far away 2.0 is, of course, not just to make sure the operators are implemented right, with clear semantics and everything, but also to give everyone a chance to accept the idea of new operators ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Thu Jul 20 20:40:35 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 20:40:35 +0200 Subject: [Python-Dev] PEPs on the web In-Reply-To: <39774A29.86E469BB@schneider-kamp.de>; from peter@schneider-kamp.de on Thu, Jul 20, 2000 at 06:51:21PM +0000 References: <39774A29.86E469BB@schneider-kamp.de> Message-ID: <20000720204034.V9897@xs4all.nl> On Thu, Jul 20, 2000 at 06:51:21PM +0000, Peter Schneider-Kamp wrote: > I have put up the PEPs on http://python.sourceforge.net/peps/ > 1) Is that okay? No one cried out aloud and I got some agreement. I don't see why not. It certainly seems the right place for it ! And it's not like they were a corporate secret before. > 2) Should I put a link from http://python.sourceforge.net ? I'd say so, yeah. > 3) What about making those PEPs xhtml (or something like that)? > Pros: > - links from pep-000.txt > - links from the other peps > Cons: > - harder to read in checkins > - harder to edit > (maybe we could use as little markup as possible?) Definate -1 from here. I like plaintext. It also works just fine for RFCs. I don't mind if the reference section (which should be the only place that contains URIs ;) is written in a markup language to facilitate HTMLization, or maybe just straight HTML, but I don't feel like escaping all those '>'s in there. However, if they can be converted to HTML automatically, based on minor clues and/or whitespace-layout, fine by me ;) I wouldn't mind adding things like paragraph markers and such, I just dont like to edit HTML newer than 1.1 ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Thu Jul 20 19:27:19 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:27:19 -0500 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> <397723AF.4B11379A@lemburg.com> Message-ID: <39773677.B3543269@prescod.net> "M.-A. Lemburg" wrote: > >... > > You add your new PyErr_Format() replacement with the existing > subset of codes, but instead of bailing out when the function > sees a format code it doesn't understand, you use sprintf() > or snprintf() (where available) to format the unkown code ?! I think its too magical and could hide security holes under too many levels of conditional behavior. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 19:49:09 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:49:09 -0500 Subject: [Python-Dev] PEP-able References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> Message-ID: <39773B95.2B70EBBC@prescod.net> "M.-A. Lemburg" wrote: > > .. > > I don't get the point: how is this better than defining > explicit access methods ? > > get_foo(self) > set_foo(self, value) > del_foo(self) It's more verbose for the client programmer and it forces them to "know" that there is magical processing going on under the covers. I'm going to provide examples of where we do or would use a feature like this in extension modules so that you can see that I'm just trying to extend the fun to Python programmers (not just extension writers). There are about a million places in Python's implementation where extension modules do computation like: def __setattr__( name, val ): if attribute_to_set=="__class__": assert PyClass_Check( val ): elif attribute_to_set=="__dict__": assert PyDict_Check( val ): One could imagine a circumstance in which we decide to "trap" sys.stdin=o so that if it HASN'T been set we could use a more efficient stdout writing protocol internal to the interpreter implementation. In general, it is useful when you want to migrate from an attribute-setting situation to a computational situation without changing existing code. You can also think of the various places where the interpreter traps when you try to write to a read-only attribute. In pyexpat, when you assign to certain variables we "push" that information down to expat itself (set variables in expat). Imagine trying to read or write an attribute over COM or CORBA. Why should Python programmers have to use foo.set("a", 5) when VB programmers just say foo.a=5? Mark Hammond currently does this with __getattr__ I believe. It would be more efficient better to auto-generate getter and setter methods. In general, its useful for proxy situations where the set of attribute you want to proxy are known in advance. It's just a cleaner, Pythonic way to do something that is already common either using __getattr__ hacks or in extension modules. > These not only define a distinct interface, but also provide > more flexibility, e.g. get_foo() could have a default argument. I'm not taking away anyone's right to use methods. The logical extension of your argument is that we should always use getter/setter methods in case we need to add arguments to them later. That's the Java stance but I think we can differentiate ourselves from Java with clearer code. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 19:52:28 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:52:28 -0500 Subject: [Python-Dev] Computed-attributes References: <1248009900-10078307@hypernet.com> Message-ID: <39773C5C.D9C07572@prescod.net> Gordon McMillan wrote: > > ... > Then: > > class A: > def __init__(self): > self.y = > class B(A): > def __set_y__(self, value): > ... > def __init__(self): > A.__init__(self) > > means that the hook in B will be invoked when A.__init__ > runs. I wonder what "gotchas" lie in wait ;-). Python is full of these gotchas. (__setattr__ has the same problem, for example). It's amazing that anything ever works. :) For any lurkers: my tongue is firmly in my cheek! > [I also note that there are quite a few Python developers who > want their users to say "x = obj.getx()", but want Python to > create the accessor method "getx(self)" (if they haven't written > one) and outlaw "x = obj.x". I have no sympathy for them, but > they exist.] Java-heads. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 19:56:27 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:56:27 -0500 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> <397716E6.F19E25BE@prescod.net> <200007201611.MAA26587@zippy.init.com> Message-ID: <39773D4B.495E1C4B@prescod.net> Don Beaudry! The master returns to check on the upstarts. Donald Beaudry wrote: > > ... > > One way of doing that, which I feel also makes things a bit more > obvious, is to allow only a single routine per attribute: __attr_XXX__. My first reaction was negative but it does simplify a bunch of stuff. Inheritance is straightforward, calling a base class is straightforward, implementation is simpler. Overall, I like it! > I agree that prohibiting it is the right idea. The question is how. > Permitting only one routine per attribute lets the traditional > attribute lookup rules work and thus prevents head scratching when > trying to find the code that actually maintains an attribute. The > cost is some additional burden on the writer of the __attr_XXX method > (and some magic to distinguish the del case). Don't follow that. Why not just have "get"/"set"/"del" opcodes? -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From moshez at math.huji.ac.il Thu Jul 20 20:58:54 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 20 Jul 2000 21:58:54 +0300 (IDT) Subject: [Python-Dev] Coercion (RE: Discussion: Introducing new operators for matrix computation) In-Reply-To: <39771F80.90DD0C99@lemburg.com> Message-ID: On Thu, 20 Jul 2000, M.-A. Lemburg wrote: > The current model where coercion is centralized won't > scale well with the new operators. My (old) proposal for this > (see my Python Pages) was to decentralize coercion and > make the coercion process part of the operators task. > > Thoughts ? > Yes. Coercion should be PEPed. It definitely qualifies for PEPing. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From paul at prescod.net Thu Jul 20 20:57:10 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 13:57:10 -0500 Subject: [Python-Dev] Computed-attributes References: <1248009900-10078307@hypernet.com> Message-ID: <39774B86.2D6317AB@prescod.net> Gordon McMillan wrote: > > ... > Then: > > class A: > def __init__(self): > self.y = > class B(A): > def __set_y__(self, value): > ... > def __init__(self): > A.__init__(self) > > means that the hook in B will be invoked when A.__init__ > runs. I wonder what "gotchas" lie in wait ;-). Python is full of these gotchas. (__setattr__ has the same problem, for example). It's amazing that anything ever works. :) For any lurkers: my tongue is firmly in my cheek! > [I also note that there are quite a few Python developers who > want their users to say "x = obj.getx()", but want Python to > create the accessor method "getx(self)" (if they haven't written > one) and outlaw "x = obj.x". I have no sympathy for them, but > they exist.] Java-heads. What do you think of Don B's idea. It simplifies things somewhat. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 19:27:19 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:27:19 -0500 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> <397723AF.4B11379A@lemburg.com> Message-ID: <39773677.B3543269@prescod.net> "M.-A. Lemburg" wrote: > >... > > You add your new PyErr_Format() replacement with the existing > subset of codes, but instead of bailing out when the function > sees a format code it doesn't understand, you use sprintf() > or snprintf() (where available) to format the unkown code ?! I think its too magical and could hide security holes under too many levels of conditional behavior. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 19:56:27 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:56:27 -0500 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> <397716E6.F19E25BE@prescod.net> <200007201611.MAA26587@zippy.init.com> Message-ID: <39773D4B.495E1C4B@prescod.net> Don Beaudry! The master returns to check on the upstarts. Donald Beaudry wrote: > > ... > > One way of doing that, which I feel also makes things a bit more > obvious, is to allow only a single routine per attribute: __attr_XXX__. My first reaction was negative but it does simplify a bunch of stuff. Inheritance is straightforward, calling a base class is straightforward, implementation is simpler. Overall, I like it! > I agree that prohibiting it is the right idea. The question is how. > Permitting only one routine per attribute lets the traditional > attribute lookup rules work and thus prevents head scratching when > trying to find the code that actually maintains an attribute. The > cost is some additional burden on the writer of the __attr_XXX method > (and some magic to distinguish the del case). Don't follow that. Why not just have "get"/"set"/"del" opcodes? -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Thu Jul 20 19:58:19 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 12:58:19 -0500 Subject: [Python-Dev] Consistency questions References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> <20000720172108.S9897@xs4all.nl> <14711.8162.800169.884936@beluga.mojam.com> Message-ID: <39773DBB.9480F7BF@prescod.net> Skip Montanaro wrote: > > ... > > I don't think so. I suspect most people use dir() interactively to see what > attributes an object supports and would appreciate the improved > functionality. Besides, we are talking 2.0 here. Nothing wrong with a > little breakage... ;-) I think that Thomas is right that there is going to be a fair bit of code that manually worked around this limitation in dir and now will get two copies of some attributes. What do you think about attrs( foo ) It's more descriptive anyhow. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From moshez at math.huji.ac.il Thu Jul 20 21:04:15 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 20 Jul 2000 22:04:15 +0300 (IDT) Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) In-Reply-To: <39773677.B3543269@prescod.net> Message-ID: [M.-A. Lemburg] > You add your new PyErr_Format() replacement with the existing > subset of codes, but instead of bailing out when the function > sees a format code it doesn't understand, you use sprintf() > or snprintf() (where available) to format the unkown code ?! [Paul Prescod] > I think its too magical and could hide security holes under too many > levels of conditional behavior. FWIW, I agree with Paul -- if an unknown format code is used, it will be plainly seen in the exception, so we will know *exactly* what popular format codes we forgot to add. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From moshez at math.huji.ac.il Thu Jul 20 21:09:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 20 Jul 2000 22:09:06 +0300 (IDT) Subject: [Python-Dev] PEPs on the web In-Reply-To: <39774A29.86E469BB@schneider-kamp.de> Message-ID: On Thu, 20 Jul 2000, Peter Schneider-Kamp wrote: > 2) Should I put a link from http://python.sourceforge.net ? +1 and more! > 3) What about making those PEPs xhtml (or something like that)? > Pros: > - links from pep-000.txt > - links from the other peps > Cons: > - harder to read in checkins > - harder to edit > (maybe we could use as little markup as possible?) -1. RFCs got to rule the 'net with text alone. If it's good enough for the IETF, it's good enough for us. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From effbot at telia.com Thu Jul 20 21:46:18 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 20 Jul 2000 21:46:18 +0200 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> Message-ID: <008901bff283$2d55d2a0$f2a6b5d4@hagrid> peter wrote: > 3) What about making those PEPs xhtml (or something like that)? > Pros: > - links from pep-000.txt > - links from the other peps > Cons: > - harder to read in checkins > - harder to edit > (maybe we could use as little markup as possible?) please stick to plain text sources. here's a little script that converts text PEP's to HTML. feel free to add it to your uploading scripts. # convert PEP's to (X)HTML import cgi, glob, os, re fixpat = re.compile("((http|ftp):[-_a-zA-Z0-9/.+?~:]+)|(pep-\d+(.txt)?|.") def fixanchor(match): text = match.group(0) link = None if text[:5] == "http:" or text[:4] == "ftp:": link = text elif text[:3] == "pep": link = os.path.splitext(text)[0] + ".html" if link: return "%s" % (link, cgi.escape(text)) return cgi.escape(match.group(0)) def fixfile(infile, outfile): # convert plain text pep to minimal XHTML markup fi = open(infile) fo = open(outfile, "w") fo.write("\n") # head header = [] fo.write("\n") while 1: line = fi.readline() if not line or ":" not in line: break key, value = line.split(":", 1) value = value.strip() header.append((key, value)) if key.lower() == "title": fo.write("%s\n" % cgi.escape(value)) fo.write("\n") # body fo.write("\n") fo.write("
\n")
    for k, v in header:
        fo.write("%s: %s\n" % (cgi.escape(k), cgi.escape(v)))
    title = 0
    while 1:
        line = fi.readline()
        if not line:
            break
        if line[:1] == "\f":
            fo.write("
\n")
            title = 1
        else:
            line = fixpat.sub(fixanchor, line)
            if title:
                fo.write("
%s
\n" % line)
            else:
                fo.write(line)
            title = 0
    fo.write("
\n") fo.write("\n") fo.write("\n") for file in glob.glob("pep-*.txt"): print file, "..." fixfile(file, os.path.splitext(file)[0] + ".html") cheers /F From huaiyu_zhu at yahoo.com Thu Jul 20 21:42:44 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Thu, 20 Jul 2000 12:42:44 -0700 (PDT) Subject: [Python-Dev] Coercion (RE: Discussion: Introducing new operators for matrix computation) In-Reply-To: <20000720203617.U9897@xs4all.nl> Message-ID: On Thu, 20 Jul 2000, Thomas Wouters wrote: > On Thu, Jul 20, 2000 at 05:49:20PM +0200, M.-A. Lemburg wrote: > > [Adding new operators] > > > Just a side note before everyone forgets: I think we'll > > need to carefully redefine coercion *before* adding any > > new slots/operators/etc. to Python. > > > The current model where coercion is centralized won't > > scale well with the new operators. My (old) proposal for this > > (see my Python Pages) was to decentralize coercion and > > make the coercion process part of the operators task. > > > Thoughts ? > Just a note. The additional operators for numerical computation have exactly the same properties as the conventional math operators. Their default on numbers are identical. Don't know if this is relevant, though. > Agreed. I also think, but that's a personal opinion, that adding new > operators should be done carefully, and I'm not sure if 2.0 is the right > time for it. It depends on how far away 2.0 is, of course, not just to make > sure the operators are implemented right, with clear semantics and > everything, but also to give everyone a chance to accept the idea of new > operators ;P Any timeline? Huaiyu From donb at init.com Thu Jul 20 21:48:45 2000 From: donb at init.com (Donald Beaudry) Date: Thu, 20 Jul 2000 15:48:45 -0400 Subject: [Python-Dev] Computed-attributes References: <1248021882-9357610@hypernet.com> <397716E6.F19E25BE@prescod.net> <200007201611.MAA26587@zippy.init.com> <39773D4B.495E1C4B@prescod.net> Message-ID: <200007201948.PAA29206@zippy.init.com> Paul Prescod wrote, > Donald Beaudry wrote: > > The cost is some additional burden on the writer of the __attr_XXX > > method (and some magic to distinguish the del case). > > Don't follow that. Why not just have "get"/"set"/"del" opcodes? Sorry about that... it was an editing problem. At first I was going to propose that the __attr_XXX method take just one optional argument: the set value. If it was there do a set, if not do a get. The problem was how to do the del (magic?). Then I had the bright idea of using the op parameter but never removed my "magic" comment. The "additional burden" I was refering to was that of writing a method which must first decide what to do. Personally, I call this a feature since it forces all maintenance of a given attribute into a single place. Others might argue that the code in a single purpose setter, getter, or deller would read better. -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb at init.com Lexington, MA 02421 ...So much code, so little time... From thomas at xs4all.net Thu Jul 20 22:13:00 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 20 Jul 2000 22:13:00 +0200 Subject: [Python-Dev] ANSIfication again ;) Message-ID: <20000720221300.W9897@xs4all.nl> I just went over all of the Python source, using this little program (which I called findkrc.py): import sys, string for file in sys.argv[1:] d = open(file).read() if string.find(d, ";\n{") <> -1 or string.find(d, "()\n{") <> -1: print file (using find -name '*.[ch]' -print | xargs ./findkrc.py) And I fixed almost all of the instances of K&R C syntax. However, I found a lot of instances of the 2nd type: empty argument list. However, as far as I remember, ANSI C states that should be written as '(void)'. Is that a non-issue, and should I not bother fixing those ? (Most of the files in Modules/ has one or more instances of those.) I also found a number of files which were already converted to ANSI syntax, but with one function leftover. Should I bother uploading a patch for those, or can I just commit them ? They're only a few lines per file, after all. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jul 20 22:49:30 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 22:49:30 +0200 Subject: [Python-Dev] __set_foo__ et al. (PEP-able) References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> <39773B95.2B70EBBC@prescod.net> Message-ID: <397765DA.133518A2@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > .. > > > > I don't get the point: how is this better than defining > > explicit access methods ? > > > > get_foo(self) > > set_foo(self, value) > > del_foo(self) > > It's more verbose for the client programmer and it forces them to "know" > that there is magical processing going on under the covers. Magical processing is usually not a very good design, IMHO (no, I don't like the Unicode auto-conversions ;-). > I'm going to > provide examples of where we do or would use a feature like this in > extension modules so that you can see that I'm just trying to extend the > fun to Python programmers (not just extension writers). > > There are about a million places in Python's implementation where > extension modules do computation like: > > def __setattr__( name, val ): > if attribute_to_set=="__class__": > assert PyClass_Check( val ): > elif attribute_to_set=="__dict__": > assert PyDict_Check( val ): But that's just an implementation detail (you either do the lookup via a mapping, e.g. the instance dict, or by switching on the attribute name)... in C and with only a few cases, the switching technique is faster than the lookup. > One could imagine a circumstance in which we decide to "trap" > sys.stdin=o so that if it HASN'T been set we could use a more efficient > stdout writing protocol internal to the interpreter implementation. > > In general, it is useful when you want to migrate from an > attribute-setting situation to a computational situation without > changing existing code. > > You can also think of the various places where the interpreter traps > when you try to write to a read-only attribute. > > In pyexpat, when you assign to certain variables we "push" that > information down to expat itself (set variables in expat). > > Imagine trying to read or write an attribute over COM or CORBA. Why > should Python programmers have to use foo.set("a", 5) when VB > programmers just say foo.a=5? Mark Hammond currently does this with > __getattr__ I believe. It would be more efficient better to > auto-generate getter and setter methods. > > In general, its useful for proxy situations where the set of attribute > you want to proxy are known in advance. > > It's just a cleaner, Pythonic way to do something that is already common > either using __getattr__ hacks or in extension modules. It's also *much* slower: you'd have to check objects for e.g. obj.__set_foo__ prior to every obj.foo=1 assignment. I think that these techniques are better implemented by writing a special proxy which then does your proposed mapping for a predefined set of attributes. mx.Proxy would be a good code base for these kind of experiments, but a simple Python prototype would do as well. > > These not only define a distinct interface, but also provide > > more flexibility, e.g. get_foo() could have a default argument. > > I'm not taking away anyone's right to use methods. The logical extension > of your argument is that we should always use getter/setter methods in > case we need to add arguments to them later. That's the Java stance but > I think we can differentiate ourselves from Java with clearer code. Well, you can't really say what is best in the general case. I usually use the direct attribute access method for information containers and the method access for more elaborate objects (ones which care about the data format, apply extra checks, depend on state, etc.). Very often these methods set more than just one attribute, so using __set_foo__ wouldn't work here. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Thu Jul 20 23:14:00 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 20 Jul 2000 23:14:00 +0200 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <008901bff283$2d55d2a0$f2a6b5d4@hagrid> Message-ID: <015101bff28f$6dad9200$f2a6b5d4@hagrid> minor nit: - fo.write("
\n") + fo.write("
\n") From paul at prescod.net Thu Jul 20 23:18:08 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 16:18:08 -0500 Subject: [Python-Dev] __set_foo__ et al. (PEP-able) References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> <39773B95.2B70EBBC@prescod.net> <397765DA.133518A2@lemburg.com> Message-ID: <39776C90.67FAFFD8@prescod.net> "M.-A. Lemburg" wrote: > > > def __setattr__( name, val ): > > if attribute_to_set=="__class__": > > assert PyClass_Check( val ): > > elif attribute_to_set=="__dict__": > > assert PyDict_Check( val ): > > But that's just an implementation detail (you either do the > lookup via a mapping, e.g. the instance dict, or by switching > on the attribute name)... in C and with only a few cases, the > switching technique is faster than the lookup. That's not the case. In this case, Guido is doing type checking on sets. You can only do that in Python with an __setattr__ hack. > > It's just a cleaner, Pythonic way to do something that is already common > > either using __getattr__ hacks or in extension modules. > > It's also *much* slower: you'd have to check objects for > e.g. obj.__set_foo__ prior to every obj.foo=1 assignment. It's much, much faster for than __getattr__ for gets. It's probably no slower than __setattr__ for sets because you aren't switching on the attribute name in Python. Anyhow gets are much more common than sets so speeding them up is a big win. > I think that these techniques are better implemented by > writing a special proxy which then does your proposed > mapping for a predefined set of attributes. Proxies are slow and introduce a host of their own "issues." In practice, I've never seen anyone implement this pattern with proxies unless the proxies were doing something else already (e.g. COM). They always use a direct __getattr__/__setattr__. > I usually use the direct attribute access method for > information containers and the method access for more > elaborate objects (ones which care about the data format, > apply extra checks, depend on state, etc.). Very often > these methods set more than just one attribute, so using > __set_foo__ wouldn't work here. Don't follow. Here's an example that: * cares about data format * applies extra checks * is state dependent * sets more than one attribute internally def __set_enddate__( self, val ): if len(val)==3 and val>self.start_date self.endday, self.endmonth, self.endyear=val else: raise TypeError def __get_enddate__(self, val): return self.endday, self.endmonth, self.endyear obj.enddate=(15, 12, 2000) print obj.endday print obj.endmonth print obj.endyear d,m,y=obj.enddate -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From mal at lemburg.com Thu Jul 20 23:42:32 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 23:42:32 +0200 Subject: [Python-Dev] __set_foo__ et al. (PEP-able) References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> <39773B95.2B70EBBC@prescod.net> <397765DA.133518A2@lemburg.com> <39776C90.67FAFFD8@prescod.net> Message-ID: <39777248.9FE80D68@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > > def __setattr__( name, val ): > > > if attribute_to_set=="__class__": > > > assert PyClass_Check( val ): > > > elif attribute_to_set=="__dict__": > > > assert PyDict_Check( val ): > > > > But that's just an implementation detail (you either do the > > lookup via a mapping, e.g. the instance dict, or by switching > > on the attribute name)... in C and with only a few cases, the > > switching technique is faster than the lookup. > > That's not the case. In this case, Guido is doing type checking on sets. > You can only do that in Python with an __setattr__ hack. Huh ? "if attribute_to_set == ..." looks like a switch on attribute name to me. > > > It's just a cleaner, Pythonic way to do something that is already common > > > either using __getattr__ hacks or in extension modules. > > > > It's also *much* slower: you'd have to check objects for > > e.g. obj.__set_foo__ prior to every obj.foo=1 assignment. > > It's much, much faster for than __getattr__ for gets. It's probably no > slower than __setattr__ for sets because you aren't switching on the > attribute name in Python. Anyhow gets are much more common than sets so > speeding them up is a big win. __get_foo__ causes a Python function call and this is about the most costly activity there is in Python's internals. > > I think that these techniques are better implemented by > > writing a special proxy which then does your proposed > > mapping for a predefined set of attributes. > > Proxies are slow and introduce a host of their own "issues." In > practice, I've never seen anyone implement this pattern with proxies > unless the proxies were doing something else already (e.g. COM). They > always use a direct __getattr__/__setattr__. Sure, I meant proxies as good starting point for meta classes which deal with your proposed technique. BTW, proxies written in C are fast -- __getattr__ in C is within practical range. > > I usually use the direct attribute access method for > > information containers and the method access for more > > elaborate objects (ones which care about the data format, > > apply extra checks, depend on state, etc.). Very often > > these methods set more than just one attribute, so using > > __set_foo__ wouldn't work here. > > Don't follow. Here's an example that: (Note: I described my personal style -- not as general rule or guideline.) > * cares about data format > * applies extra checks > * is state dependent > * sets more than one attribute internally > > def __set_enddate__( self, val ): > if len(val)==3 and val>self.start_date > self.endday, self.endmonth, self.endyear=val > else: > raise TypeError > > def __get_enddate__(self, val): > return self.endday, self.endmonth, self.endyear > > obj.enddate=(15, 12, 2000) > print obj.endday > print obj.endmonth > print obj.endyear > > d,m,y=obj.enddate Well, yes. It works. But tell me: how are you going to debug this ? Assignments will suddenly raise exceptions and the traceback won't be of any use for programmers to find the true error location. Too much magic and too many possibilities for overloading dots ;-) (I've never understood why Javascript causes a new URL to be shown when your assign to top.window.location.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From peter at schneider-kamp.de Fri Jul 21 01:49:02 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Thu, 20 Jul 2000 23:49:02 +0000 Subject: [Python-Dev] ANSIfication again ;) References: <20000720221300.W9897@xs4all.nl> Message-ID: <39778FEE.88427388@schneider-kamp.de> Thomas Wouters wrote: > > And I fixed almost all of the instances of K&R C syntax. However, I found a > lot of instances of the 2nd type: empty argument list. However, as far as I > remember, ANSI C states that should be written as '(void)'. Is that a > non-issue, and should I not bother fixing those ? (Most of the files in > Modules/ has one or more instances of those.) Yes, I think that's right. I just looked at them and thought: Oh, no parameters - no work ;-) But then even "gcc -pedantic -ansi" doesn't care about this. Take that as a +0. > I also found a number of files which were already converted to ANSI syntax, > but with one function leftover. Should I bother uploading a patch for those, > or can I just commit them ? They're only a few lines per file, after all. I'd guess that if you feel that it's right and there is no functional change involved no one will object. not-feeling-competent-enough-for-a-straight-"just-do-it"-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mal at lemburg.com Thu Jul 20 23:56:07 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jul 2000 23:56:07 +0200 Subject: [Python-Dev] uPEP: encoding directive References: <004a01bfee66$49808ea0$f2a6b5d4@hagrid> <39709E68.820634C6@prescod.net> <00cb01bfee8a$b4e57f60$f2a6b5d4@hagrid> <016501bff10a$d09bc660$f2a6b5d4@hagrid> Message-ID: <39777577.316F1B9@lemburg.com> Fredrik Lundh wrote: > > > [paul] > > > Also, is it really necessary to allow raw non-ASCII characters in source > > > code though? We know that they aren't portable across editing > > > environments, so one person's happy face will be another person's left > > > double-dagger. > > > > [me] > > I suppose changing that would break code. maybe it's time > > to reopen the "pragma encoding" thread? > > > > (I'll dig up my old proposal, and post it under a new subject). > > as brief as I can make it: > 1. add support for "compiler directives". I suggest the following > syntax, loosely based on XML: > > #?python key=value [, key=value ...] > > (note that "#?python" will be treated as a token after this change. > if someone happens to use comments that start with #?python, > they'll get a "SyntaxError: bad #?python compiler directive"...) > > 2. for now, only accept compiler directives if they appear before > the first "real" statement. > > 3. keys are python identifiers (NAME tokens), values are simple > literals (STRING, NUMBER) > > 4. key/value pairs are collected in a dictionary. > > [...] I like the proposal, but how would you implement this ? Note that strings are decoded in compiler.c after having run the source through the tokenizer (which eliminates the comments). You'd have to carry the encoding information through to the compiler somehow. There's also a different problem to this: dynamic compilation. What encoding should eval() and exec use or expect ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Fri Jul 21 00:02:14 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 21 Jul 2000 00:02:14 +0200 Subject: [Python-Dev] converting PEPs to HTML References: <39774A29.86E469BB@schneider-kamp.de> <008901bff283$2d55d2a0$f2a6b5d4@hagrid> Message-ID: <003901bff296$377cb880$f2a6b5d4@hagrid> I've hacked a little more on the conversion script. here's the resulting HTML files: http://w1.132.telia.com/~u13208596/peps/ and here's the script itself: http://w1.132.telia.com/~u13208596/peps/pepfixup.py enjoy /F From effbot at telia.com Fri Jul 21 00:08:36 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 21 Jul 2000 00:08:36 +0200 Subject: [Python-Dev] ANSIfication again ;) References: <20000720221300.W9897@xs4all.nl> <39778FEE.88427388@schneider-kamp.de> Message-ID: <004901bff297$0f4c37e0$f2a6b5d4@hagrid> peter wrote: > thomas wrote: > > However, as far as I remember, ANSI C states that should be written > > as '(void)'. Is that a non-issue, and should I not bother fixing those ? > > (Most of the files in Modules/ has one or more instances of those.) > > Yes, I think that's right. I just looked at them and thought: Oh, no > parameters - no work ;-) > > But then even "gcc -pedantic -ansi" doesn't care about this. > Take that as a +0. strictly speaking, (void) and () are two different things: "If the function does not expect any arguments, you write only the keyword void void reset(void); no arguments, no return ... "You can also declare a function and not provide information about the number or types of its arguments. Do not write declarations within the parentheses of the function decoration. double bessel(); no argument information (from http://www-ccs.ucsd.edu/c/function.html) but I guess it's up to you if you want to be more pedantic than -pedantic... From paul at prescod.net Fri Jul 21 00:03:34 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 20 Jul 2000 17:03:34 -0500 Subject: [Python-Dev] __set_foo__ et al. (PEP-able) References: <39769DB0.BCE7FB38@prescod.net> <39773161.1DA45DE6@lemburg.com> <39773B95.2B70EBBC@prescod.net> <397765DA.133518A2@lemburg.com> <39776C90.67FAFFD8@prescod.net> <39777248.9FE80D68@lemburg.com> Message-ID: <39777736.EB18917E@prescod.net> "M.-A. Lemburg" wrote: > > Paul Prescod wrote: > > > > "M.-A. Lemburg" wrote: > > > > > > > def __setattr__( name, val ): > > > > if attribute_to_set=="__class__": > > > > assert PyClass_Check( val ): > > > > elif attribute_to_set=="__dict__": > > > > assert PyDict_Check( val ): > > > > > That's not the case. In this case, Guido is doing type checking on sets. > > You can only do that in Python with an __setattr__ hack. > > Huh ? "if attribute_to_set == ..." looks like a switch on > attribute name to me. But he's doing the switch not for performance reasons but to check the data value before allowing the assignment! In Python you might do it for the same basic reason. > __get_foo__ causes a Python function call and this is about > the most costly activity there is in Python's internals. You wouldn't use __get_foo__ unless you *needed to do some computation*. Therefore you shouldn't compare it to anything OTHER than a Python function call. The appropriate comparision is to __getattr__ with a big switch statement or code. > Well, yes. It works. But tell me: how are you going to debug > this ? Assignments will suddenly raise exceptions and the > traceback won't be of any use for programmers to find the > true error location. Assignments can raise exceptions today. Try assigning to tuple slot. The traceback will go through the code that did the assignment. It won't be at the bottom of the traceback but it will appear. The traceback will be MORE useful than the altenatives of either a proxy or __getattr__. > Too much magic and too many possibilities for overloading > dots ;-) Python already gives you the ability to do this magic and we do it all over the place. The question is whether to make it a little more reliable, performant and consistent or not. > (I've never understood why Javascript causes a new URL to be shown > when your assign to top.window.location.) Well a Python web-browser could implement the same poor design decision *today*. I am going to make it easier but I'm not going to force people to use it! -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From skip at mojam.com Fri Jul 21 00:05:04 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 20 Jul 2000 17:05:04 -0500 (CDT) Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <39778FEE.88427388@schneider-kamp.de> References: <20000720221300.W9897@xs4all.nl> <39778FEE.88427388@schneider-kamp.de> Message-ID: <14711.30608.650773.223155@beluga.mojam.com> [ () vs. (void) in ANSI C ] Peter> But then even "gcc -pedantic -ansi" doesn't care about this. I doubt it should. "()" is perfectly valid ANSI C isn't it? As I recall it means "I know nothing about this function's input parameters, so I won't check it." On the other hand, "(void)" means "This function takes precisely zero input args". Skip From pingster at ilm.com Fri Jul 21 00:09:30 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 20 Jul 2000 15:09:30 -0700 (PDT) Subject: [Python-Dev] realpath? Message-ID: We have normpath() and readlink(), but how about realpath()? Seems like a good thing to have in the posixmodule. The man page for the C routine says: char *realpath (const char *file_name, char *resolved_name); DESCRIPTION realpath resolves all links, symbolic links, and references to ``.'' and ``..'' in file_name and stores it in resolved_name. It can handle both relative and absolute path names. For absolute path names and the relative names whose resolved name cannot be expressed relatively (for example, ../../reldir), it returns the resolved absolute name. resolved_name should point to a buffer (MAXPATHLEN) bytes in length to contain the fully resolved path name. -- ?!ng From effbot at telia.com Fri Jul 21 00:21:08 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 21 Jul 2000 00:21:08 +0200 Subject: [Python-Dev] [patch #100927] Fix for broken gethostbyname("0") Message-ID: <005d01bff298$d2fcd900$f2a6b5d4@hagrid> this patch by Pekka Pessi adds support for "0" and "-1" to gethostbyname: "0" (a string, not an integer) is the same thing as "" (INADDR_ANY) "-1" is the same thing as "". (INADDR_BROADCAST) Pekka hasn't followed up on my comments on the patch page, so I thought I'd take the question to this forum in- stead: -- why is gethostbyname "broken" if it doesn't support the magic strings "0" and "-1"? I'm tempted to reject the patch, but I'm probably missing something here... From gstein at lyra.org Fri Jul 21 00:26:33 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 20 Jul 2000 15:26:33 -0700 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <14711.2226.242735.766934@beluga.mojam.com>; from skip@mojam.com on Thu, Jul 20, 2000 at 09:12:02AM -0500 References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> Message-ID: <20000720152633.H8820@lyra.org> On Thu, Jul 20, 2000 at 09:12:02AM -0500, Skip Montanaro wrote: > > Peter> But in the long run this probably should be automated. I only see > Peter> the password barrier: > > Peter> scp pep-*.txt nowonder at shell.sourceforge.net:/home/groups/python/htdocs/peps > Peter> will make me enter my password/passphrase. > > Peter> How would one go about doing something like that? > > ... ssh-agent ... Easier than ssh-agent is to create an "authorized_keys" file. Log onto the shell box and type "mkdir .ssh". Next, copy the .ssh/identity.pub file from your local machine to .ssh/authorized_keys on shell.sourceforge.net. From effbot at telia.com Fri Jul 21 00:31:22 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 21 Jul 2000 00:31:22 +0200 Subject: [Python-Dev] realpath? References: Message-ID: <006b01bff29a$3ca51380$f2a6b5d4@hagrid> ?!ng wrote: > We have normpath() and readlink(), but how about realpath()? > > Seems like a good thing to have in the posixmodule. it's in SUSv2, so +1 from me. but don't forget #if defined(HAVE_REALPATH). what's the best way to emulate this one on Windows, btw? From peter at schneider-kamp.de Fri Jul 21 02:53:25 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 21 Jul 2000 00:53:25 +0000 Subject: [Python-Dev] [ANNOUNCE] Python Enhancement Proposals on the Web Message-ID: <39779F05.3181C5E5@schneider-kamp.de> The so called PEPs (Python Enhancement Proposals) are now available on the web at http://python.sourceforge.net/peps Thanks to /F who hacked up a small pep2html converter you can browse them as hypertext rather than as the plain text they are. PEPs that already carry some content include: 0201 Parallel Iteration bwarsaw 0203 Augmented Assignments twouters 0204 Range Literals twouters 0206 2.0 Batteries Included moshez Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gstein at lyra.org Fri Jul 21 00:54:52 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 20 Jul 2000 15:54:52 -0700 Subject: [Python-Dev] Re: [patch #100895 ] PyErr_Format In-Reply-To: ; from moshez@math.huji.ac.il on Thu, Jul 20, 2000 at 10:04:15PM +0300 References: <39773677.B3543269@prescod.net> Message-ID: <20000720155451.K8820@lyra.org> On Thu, Jul 20, 2000 at 10:04:15PM +0300, Moshe Zadka wrote: > > [M.-A. Lemburg] > > You add your new PyErr_Format() replacement with the existing > > subset of codes, but instead of bailing out when the function > > sees a format code it doesn't understand, you use sprintf() > > or snprintf() (where available) to format the unkown code ?! > > [Paul Prescod] > > I think its too magical and could hide security holes under too many > > levels of conditional behavior. > > FWIW, I agree with Paul -- if an unknown format code is used, it will be > plainly seen in the exception, so we will know *exactly* what popular > format codes we forgot to add. Agreed. Just punt on unknown codes. The "failure mode" is obvious and the fix is easy. We don't need complexity to resolve something which is obvious and easy. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Fri Jul 21 00:57:41 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 20 Jul 2000 15:57:41 -0700 Subject: [patch #100895 ] PyErr_Format (was: Re: [Python-Dev] Patches) In-Reply-To: <00b801bff1a9$248f4780$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jul 19, 2000 at 07:45:23PM +0200 References: <20000718130059.B7340@xs4all.nl> <39746807.DFA2B329@schneider-kamp.de> <006c01bff0ef$ee2ade20$f2a6b5d4@hagrid> <3975480D.29F6A89C@schneider-kamp.de> <20000718235559.B7561@lyra.org> <00b801bff1a9$248f4780$f2a6b5d4@hagrid> Message-ID: <20000720155741.L8820@lyra.org> On Wed, Jul 19, 2000 at 07:45:23PM +0200, Fredrik Lundh wrote: >... > if I understood GvR correctly, the only remaining issue here > is whether we need more formatting codes I would say "no. let's wait and implement when a need is discovered." > (PyErr_Format is undocumented, so I'm not sure we need to > be backwards compatible with code outside the interpreter...) > > in an earlier post, I suggested adding a couple of PyErr_Format- > specific formatting codes: > > possibly stupid idea: would it make sense to add custom > formatting codes, like: > > %S => char*, string, clip if excessively long > %T => PyObject*, show name of type, clip if excessively long > > where "clip" means: > > truncate at 80 characters, and add "..." to indicate > that the string was truncated. > > this covers most of the places where %.\d+s are used (in > the Python core, at least...) > > comments? Punt. Keep it clean and simple. If a long value goes in, then so be it. There isn't a need for us to clean up after somebody's horrendous long-identifier code. The only reason stuff like %.300s exists is to prevent buffer overflows. It isn't because we are parents looking after little children :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From donb at init.com Fri Jul 21 02:33:11 2000 From: donb at init.com (Donald Beaudry) Date: Thu, 20 Jul 2000 20:33:11 -0400 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> Message-ID: <200007210033.UAA31657@zippy.init.com> Greg Stein wrote, > Easier than ssh-agent is to create an "authorized_keys" file. Log onto the > shell box and type "mkdir .ssh". Next, copy the .ssh/identity.pub file from > your local machine to .ssh/authorized_keys on shell.sourceforge.net. > > From then on, SF will used the auth'd key rather than asking for your > password. That's mostly correct, but... you are assuming that the private side of the key (.ssh/identity on the local host) has not been encrypted with a passphrase. If it has, the scp command will prompt for it instead of the remote password. When using an encrypted private key ssh-agent is the answer. Personally, I am pretty paranoid about my private keys so (now ;) I always encrypt them. As a loose rule, I wont give anyone access to my systems (accept a public key) unless they at least tell me that their private key has been encrypted. How much trouble could could be caused by unauthorized access to your SF account? How secure is your private key? -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb at init.com Lexington, MA 02421 ...Will hack for sushi... From moshez at math.huji.ac.il Fri Jul 21 06:21:02 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 21 Jul 2000 07:21:02 +0300 (IDT) Subject: [Python-Dev] [patch #100927] Fix for broken gethostbyname("0") In-Reply-To: <005d01bff298$d2fcd900$f2a6b5d4@hagrid> Message-ID: On Fri, 21 Jul 2000, Fredrik Lundh wrote: > this patch by Pekka Pessi adds support for "0" and "-1" > to gethostbyname: > > "0" (a string, not an integer) is the same thing as "" > (INADDR_ANY) > > "-1" is the same thing as "". > (INADDR_BROADCAST) > > Pekka hasn't followed up on my comments on the patch > page, so I thought I'd take the question to this forum in- > stead: > > -- why is gethostbyname "broken" if it doesn't > support the magic strings "0" and "-1"? > > I'm tempted to reject the patch, but I'm probably missing > something here... I'm -1 on the patch too. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From thomas at xs4all.net Fri Jul 21 07:59:15 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 21 Jul 2000 07:59:15 +0200 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <200007210033.UAA31657@zippy.init.com>; from donb@init.com on Thu, Jul 20, 2000 at 08:33:11PM -0400 References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> Message-ID: <20000721075915.Y9897@xs4all.nl> On Thu, Jul 20, 2000 at 08:33:11PM -0400, Donald Beaudry wrote: > Greg Stein wrote, > > Easier than ssh-agent is to create an "authorized_keys" file. Log onto the > > shell box and type "mkdir .ssh". Next, copy the .ssh/identity.pub file from > > your local machine to .ssh/authorized_keys on shell.sourceforge.net. > > > > From then on, SF will used the auth'd key rather than asking for your > > password. > That's mostly correct, but... you are assuming that the private side > of the key (.ssh/identity on the local host) has not been encrypted > with a passphrase. If it has, the scp command will prompt for it > instead of the remote password. When using an encrypted private key > ssh-agent is the answer. > Personally, I am pretty paranoid about my private keys so (now ;) I > always encrypt them. As a loose rule, I wont give anyone access to my > systems (accept a public key) unless they at least tell me that their > private key has been encrypted. And that's perfectly sensible. I'm not a crypto-junkie in any way, but using ssh with non-passphrase-protected is dangerous stuff. We do use it, at XS4ALL, actually, for scripts to execute commands on remote machines, but we do it with seperate keysets, and restricted per host. Nevertheless, if one of those private keys ever gets stolen, it's very likely the thief can get access to semi-sensitive parts of our system. Using a authorized_keys scheme with an unencrypted private key makes your private key, something you 'have', your password, without coupling it to something you 'know'. So anyone who steals your private key can pretend to be you ;) For more security, I'd suggest a cronjob that connects to your ssh-agent first, and just bails out if you haven't an ssh-agent running. (That means a private key is only useful on a machine that also has an accompanying ssh-agent running, and the 'hacker' can assume your privileges. This is the case for the common root access hole, but not so if the machine is rebooted, for instance, to gain that root access, or if it's only a file-stealing hole instead of a full-access hole ;) Then again, I'm a system administrator for a high-profile ISP. I might be a tad paranoid myself ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Fri Jul 21 08:13:54 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 21 Jul 2000 08:13:54 +0200 Subject: [Python-Dev] [patch #100927] Fix for broken gethostbyname("0") In-Reply-To: <005d01bff298$d2fcd900$f2a6b5d4@hagrid>; from effbot@telia.com on Fri, Jul 21, 2000 at 12:21:08AM +0200 References: <005d01bff298$d2fcd900$f2a6b5d4@hagrid> Message-ID: <20000721081354.Z9897@xs4all.nl> On Fri, Jul 21, 2000 at 12:21:08AM +0200, Fredrik Lundh wrote: > Pekka hasn't followed up on my comments on the patch > page, so I thought I'd take the question to this forum in- > stead: > > -- why is gethostbyname "broken" if it doesn't > support the magic strings "0" and "-1"? > I'm tempted to reject the patch, but I'm probably missing > something here... Well, '0' is a valid ipaddress. Strange, but valid. An ipaddress needn't contain any dots ;) it's just a 32bit value, after all. The dot-notation is for convenience, mostly: centurion:~ > ping 0 PING 0 (0.0.0.0) from 127.0.0.1 : 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.1 ms (This is also the reason '127.0.0.1' can be written as '127.1') You can also type things like 'http://2224488794' in most browsers. Go ahead, try it ;) So I'd say: accept "0". It's valid behaviour. However, -1 is something else: centurion:~ > ping -- -1 ping: unknown host -1 I can see where it comes from, as it should be interpreted as 0xFFFFFFFF, but it's not a convention I'm aware of. And it's also not 'an ipaddress in dot notation', because there can't be negative values in an ipaddress even if you leave out the dots. All in all, I'm +1 on the first, -1 on the second. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Fri Jul 21 08:18:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 21 Jul 2000 08:18:08 +0200 Subject: [Python-Dev] Consistency questions In-Reply-To: <39773DBB.9480F7BF@prescod.net>; from paul@prescod.net on Thu, Jul 20, 2000 at 12:58:19PM -0500 References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> <20000720172108.S9897@xs4all.nl> <14711.8162.800169.884936@beluga.mojam.com> <39773DBB.9480F7BF@prescod.net> Message-ID: <20000721081808.A9897@xs4all.nl> On Thu, Jul 20, 2000 at 12:58:19PM -0500, Paul Prescod wrote: > I think that Thomas is right that there is going to be a fair bit of > code that manually worked around this limitation in dir and now will get > two copies of some attributes. What do you think about > attrs( foo ) Hm, "methods and attributes are different things, right ?" I catch my newbie colleagues thinking that all the time ;P How about 'ls' ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov at inrialpes.fr Fri Jul 21 14:27:45 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 21 Jul 2000 14:27:45 +0200 (CEST) Subject: [Python-Dev] object allocator Message-ID: <200007211227.OAA04028@python.inrialpes.fr> I've spent some time recently in reviving the pymalloc project, and now that Python has GC and is fairly clean w.r.t. its allocators, I think I'm going to suggest the inclusion of pymalloc as an object allocator (i.e. obmalloc). Three main reasons motivate this suggestion: 1. obmalloc keeps under control the memory allocated for most objects; 2. it compensates for the space overhead induced by GC; 3. it gives worthy speedups. To give it a try, see: http://starship.beopen.com/crew/vlad/pymalloc/ It's basically a VMM aware, generalized free list implementation which handles dynamically small mem blocks (small = under 64 bytes for combos with 4-byte pointers). This accounts for > 95% of all object structs allocated by Python. Thread safety is disabled (just like the other object-specific allocators). There's no profiling for the moment. I'm going to rewrite entirely the stats code, but still, give it a try in the meantime. I have only rough numbers, but my preliminary tests indicate that for memory consuming scripts, GC increases the peak mem usage by more than 5% (5 to 15% and up) compared to no-GC, and obmalloc decreases that to something in between GC and no-GC. Sometimes also below no-GC. This is due to the fact that obmalloc does not introduce per block overhead for every allocation, as standard libc mallocs do. I consistently get speedups of 3%-20% for long-enough running scripts (on Linux, Solaris and AIX). Regarding space, for low-mem consuming scripts, obmalloc increases the mem usage (reservation) as it preallocates & suballocates 256k blocks, but I'm not interested in low-mem consuming scripts. Things start to be interesting for higher mem consumptions. Just an example with regrtest.py on my setup: The (peak) requested memory is about 4 MB. GC adds 150 KB more compared to no-GC. With GC and with obmalloc, I sometimes get 100k less compared to no-GC. This is optimistic, but I won't argue more about it, because these are all virtual memory numbers. All this needs to be pursued, probably PEP'ed, but I think I can already emit my opinion about a compromise: If obmalloc.c gets in 2.0, I am okay to leave GC enabled for 2.0 final. Probably obmalloc needs to go in pair with GC. And Neil & al. can make use of it as a basis for further enhancements of the GC code (note that most of the object mem is now under Python's control). That said, it would be nice if you could test this code on your combos and report some results and impressions back here. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From nascheme at enme.ucalgary.ca Fri Jul 21 15:32:22 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 21 Jul 2000 07:32:22 -0600 Subject: [Python-Dev] object allocator In-Reply-To: <200007211227.OAA04028@python.inrialpes.fr>; from Vladimir Marangozov on Fri, Jul 21, 2000 at 02:27:45PM +0200 References: <200007211227.OAA04028@python.inrialpes.fr> Message-ID: <20000721073222.B25293@keymaster.enme.ucalgary.ca> Nice work Vladimir. I will definately check this out in more detail when I get my home computer back. I'm hoping we can group objects with gc_prev and gc_next pointers and reduce the memory overhead. Neil From skip at mojam.com Fri Jul 21 16:36:31 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 21 Jul 2000 09:36:31 -0500 (CDT) Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) In-Reply-To: <200007210033.UAA31657@zippy.init.com> References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> Message-ID: <14712.24559.935141.849089@beluga.mojam.com> Donald> That's mostly correct, but... you are assuming that the private Donald> side of the key (.ssh/identity on the local host) has not been Donald> encrypted with a passphrase. If it has, the scp command will Donald> prompt for it instead of the remote password. When using an Donald> encrypted private key ssh-agent is the answer. Okay, someone has to admit ignorance. Might as well be me. ;-) 1. How can I tell if my .ssh/identity file has been encrypted? 2. If it hasn't, how do I encrypt it? When I run ssh-add, it prompts me for my passphrase. Is that sufficient to suggest I have an encrypted identity file? Skip From donb at init.com Fri Jul 21 16:44:47 2000 From: donb at init.com (Donald Beaudry) Date: Fri, 21 Jul 2000 10:44:47 -0400 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> <14712.24559.935141.849089@beluga.mojam.com> Message-ID: <200007211444.KAA04701@zippy.init.com> Skip Montanaro wrote, > Okay, someone has to admit ignorance. Might as well be me. ;-) > > 1. How can I tell if my .ssh/identity file has been encrypted? > 2. If it hasn't, how do I encrypt it? > > When I run ssh-add, it prompts me for my passphrase. Is that > sufficient to suggest I have an encrypted identity file? Yes. You will only be asked for a passphrase if your identity is encrypted. I dont know the answer to your first two questions. -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb at init.com Lexington, MA 02421 ...So much code, so little time... From peter at schneider-kamp.de Fri Jul 21 19:19:37 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Fri, 21 Jul 2000 17:19:37 +0000 Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> <14712.24559.935141.849089@beluga.mojam.com> Message-ID: <39788629.85DE5CD7@schneider-kamp.de> Skip Montanaro wrote: > > Okay, someone has to admit ignorance. Might as well be me. ;-) > > 1. How can I tell if my .ssh/identity file has been encrypted? If you are prompted for a passphrase and giving that passphrase let's you work, then everything should be fine with your identity. > 2. If it hasn't, how do I encrypt it? You choose the passphrase when you generate the key with ssh-keygen. To change it call: ssh-keygen -p Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul at prescod.net Fri Jul 21 18:25:39 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 11:25:39 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 Message-ID: <39787983.9682ABC5@prescod.net> I don't have a PEP number for this yet but I wanted to go through another round of comments after changing the mechanism according to Don Beaudry's suggestions. The name has been changed because every attribute is computed at some point or another. The important thing is that we are defining methods that trap sets/gets to attributes. PEP: ??? Title: Attribute Access Handlers Version: $Revision: 1.0 $ Owner: paul at prescod.net Python-Version: 2.0 Status: Incomplete Introduction It is possible (and even relatively common) in Python code and in extension modules to "trap" when an instance's client code attempts to set an attribute and execute code instead. In other words it is possible to allow users to use attribute assignment/ retrieval/deletion syntax even though the underlying implementation is doing some computation rather than directly modifying a binding. This PEP describes a feature that makes it easier, more efficient and safer to implement these handlers in Python than it is today. Justification Scenario 1: You have a deployed class that works on an attribute named "stdout". After a while, you think it would be better to check that stdout is really an object with a "write" method at the moment of assignment. Rather than change to a setstdout method (which would be incompatible with deployed code) you would rather trap the assignment and check the object's type. Scenario 2: You want to be as compatible as possible with an object model that has a concept of attribute assignment. It could be the W3C Document Object Model or a particular COM interface (e.g. the PowerPoint interface). In that case you may well want attributes in the model to show up as attributes in the Python interface, even though the underlying implementation may not use attributes at all. Scenario 3: A user wants to make an attribute read-only. In short, this feature allows programmers to separate the interface of their module from the underlying implementation for whatever purpose. Again, this is not a new feature but merely a new syntax for an existing convention. Syntax Special methods should declare themselves with declarations of the following form: class x: def __attr_XXX__(self, op, val ): if op=="get": return someComputedValue(self.internal) elif op=="set": self.internal=someComputedValue(val) elif op=="del": del self.internal Client code looks like this: fooval=x.foo x.foo=fooval+5 del x.foo Semantics Attribute references of all three kinds should call the method. The op parameter can be "get"/"set"/"del". Of course this string will be interned so the actual checks for the string will be very fast. It is disallowed to actually have an attribute named XXX in the same instance as a method named __attr_XXX__. An implementation of __attr_XXX__ takes precedence over an implementation of __getattr__ based on the principle that __getattr__ is supposed to be invoked only after finding an appropriate attribute has failed. An implementation of __attr_XXX__ takes precedence over an implementation of __setattr__ in order to be consistent. The opposite choice seems fairly feasible also, however. The same goes for __del_y__. Proposed Implementation There is a new object called a computed attribute object. It has three attributes: get, set, delete. In PyClass_New, methods of the appropriate form will be detected and converted into objects (just like unbound method objects). Matching methods go in the same computed attribute object and missing methods are replaced with a stub that throws the TypeError. If there are any computed attributes at all, a flag is set. Let's call it "I_have_computed_attributes" for now. A get proceeds as usual until just before the object is returned. In addition to the current check whether the returned object is a method it would also check whether a returned object is a computed attribute. If so, it would invoke the getter method and return the value. To remove a computed attribute object you could directly fiddle with the dictionary. A set proceeds by checking the "I_have_computed_attributes" flag. If it is not set, everything proceeds as it does today. If it is set then we must do a dictionary get on the requested object name. If it returns a computed method attribute then we call the setter function with the value. If it returns any other object then we discard the result and continue as we do today. Note that having a computed attribute will affect attribute setting performance for all sets on a particular instance, but no more so than today. Gets are more efficient than they are today with __getattr__. The I_have_computed_attributes flag is intended to eliminate the performance degradation of an extra "get" per "set" for objects not using this feature. You might note that I have not proposed any logic to keep this flag up to date as attributes are added and removed from the instance's dictionary. This is consistent with current Python. If you add a __setattr__ method to an object after it is in use, that method will not behave as it would if it were available at "compile" time. The dynamism is arguably not worth the extra implementation effort. The implementation of delete is analogous to the implementation of set. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From nascheme at enme.ucalgary.ca Fri Jul 21 19:19:54 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 21 Jul 2000 11:19:54 -0600 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <39787983.9682ABC5@prescod.net>; from Paul Prescod on Fri, Jul 21, 2000 at 11:25:39AM -0500 References: <39787983.9682ABC5@prescod.net> Message-ID: <20000721111954.A27901@keymaster.enme.ucalgary.ca> On Fri, Jul 21, 2000 at 11:25:39AM -0500, Paul Prescod wrote: > PEP: ??? > Title: Attribute Access Handlers > Version: $Revision: 1.0 $ > Owner: paul at prescod.net > Python-Version: 2.0 > Status: Incomplete So far I'm a strong +1. I dislike the all or nothing approach of __setattr__ and the performance cost associated with it. Support for "attribute access handlers" should largely eliminate the need for writing attribute access wrappers (getters and setters). The benefits are that code is simpler (you can use object attributes directly for outside the class), performance is better, and you always have the option of computing the value in the future without changing code that uses the object. Neil From Vladimir.Marangozov at inrialpes.fr Fri Jul 21 19:26:15 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 21 Jul 2000 19:26:15 +0200 (CEST) Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <39787983.9682ABC5@prescod.net> from "Paul Prescod" at Jul 21, 2000 11:25:39 AM Message-ID: <200007211726.TAA04540@python.inrialpes.fr> Paul Prescod wrote: > > I don't have a PEP number for this yet but I wanted to go through > another round of comments after changing the mechanism according to Don > Beaudry's suggestions. > > The name has been changed because every attribute is computed at some > point or another. The important thing is that we are defining methods > that trap sets/gets to attributes. Paul, this is clearly unclear <0.1 wink>. I for one don't get it. The whole point of __getattr__, __setattr__ is to trap attribute accesses and assignment. Python lets you trap the attribute binding process through these two functions. At yes, it is common case, because people want to specialize the binding rules in an object's namespace. However, this is defined only for Python's instance objects. If this is intended to generalize the concept for builtin objects, then you reach the object model deficiencies (metacalass, type dochotomy, etc.) which is not a trivial problem. If you're running after performance, because this programmable trapping occurs only in Python, well, state it explicitely in your writing. I believe that you're running after the generalization. I am not sure that what's in this per-PEP is a generic solution though. Because you're discussing handlers written in Pythonland (and this is also unclear in your writing). Simply put, these handlers would be invoked by hooks taken into account by the C code. Except hooking dict lookups with Python or C handlers, I don't see the point of this PEP. If the handlers are written in Python, this is what you get with __getattr__ and __setattr__. If you think C handlers, well, tell us about it explicitely. or-I-am-missing-the-point-completely y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gmcm at hypernet.com Fri Jul 21 19:45:27 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Fri, 21 Jul 2000 13:45:27 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <39787983.9682ABC5@prescod.net> Message-ID: <1247920968-15427430@hypernet.com> > I don't have a PEP number for this yet but I wanted to go through > another round of comments after changing the mechanism according > to Don Beaudry's suggestions. [snip] > Proposed Implementation > > There is a new object called a computed attribute object. It > has three attributes: get, set, delete. raise InternalInconsistencyError - Gordon From effbot at telia.com Fri Jul 21 20:31:53 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 21 Jul 2000 20:31:53 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0200.txt,1.1,1.2 References: <200007211813.LAA12850@slayer.i.sourceforge.net> Message-ID: <001a01bff341$f63119a0$f2a6b5d4@hagrid> some comments: > + * SyntaxError enhancements - Fredrik Lundh > + http://www.python.org/pipermail/python-dev/2000-July/012981.html ouch. what part of this "proposal" has been accepted? hopefully the latter part (the "error number" part). > + * snprintf - owner??? > + Use snprintf to avoid buffer overflows. Need configure hackery > + to discovery if it is available on the current platform and a > + default implementation if it is not. > + http://www.python.org/pipermail/python-dev/2000-April/010051.html > + This function is expected to be part of C9X (check). patch #100895, I hope. note that snprintf and this implementation are not equivalent (the safe version of PyErr_Format allocates a buffer large enough to hold the message). ... btw, don't forget patch #100941 (a bug fix to the new windows popen code). I'm working on a slightly modified version of David's patch -- should be ready for check in on monday... From paul at prescod.net Fri Jul 21 20:39:19 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 13:39:19 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <200007211726.TAA04540@python.inrialpes.fr> Message-ID: <397898D7.1D16A2B@prescod.net> Vladimir Marangozov wrote: > >... > Paul, this is clearly unclear <0.1 wink>. I for one don't get it. > The whole point of __getattr__, __setattr__ is to trap attribute > accesses and assignment. Sure, but ALL attribute accesses and assignment. What if you just want to trap one or two or ten? > However, this is defined only for Python's instance objects. If this > is intended to generalize the concept for builtin objects, then you > reach the object model deficiencies (metacalass, type dochotomy, etc.) > which is not a trivial problem. This feature has nothing to do with built-in types. Built-in types *always* use the getattr convention anyhow. > If you're running after performance, because this programmable trapping > occurs only in Python, well, state it explicitely in your writing. I mentioned performance explicitly in the introduction: > This PEP describes a feature that makes it easier, more efficient > and safer to implement these handlers in Python than it is today. Performance is only one of the goals. Clarity is the more major one. Safety is another. When you start combining __getattr__ with multiply inherited base class __getattr__ and so forth you get into a real mess. This proposal does not have that problem. > If the handlers are written in Python, this is what you get with __getattr__ > and __setattr__. If you think C handlers, well, tell us about it explicitely. The proposal explicitly says that the propsal allows nothing that getattr and setattr do not already allow. If you're looking for something that they do that this doesn't, you won't find it. Rather: > This PEP describes a feature that makes it easier, more efficient > and safer to implement these handlers in Python than it is today. Not a new ability, just a more structured way to exercise it. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Fri Jul 21 20:49:23 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 13:49:23 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <1247920968-15427430@hypernet.com> Message-ID: <39789B33.4C01AC03@prescod.net> Gordon McMillan wrote: > > [snip] > > > Proposed Implementation > > > > There is a new object called a computed attribute object. It > > has three attributes: get, set, delete. > > raise InternalInconsistencyError Good point. Here's a fix for that and something else I left out before. There is a new object type called a computed attribute object. Objects of this type have the following attributes: name (e.g. XXX, not __attr__XXX__ method (pointer to a method object In PyClass_New, methods of the appropriate form will be detected and converted into objects (just like unbound method objects). If there are any computed attributes in an instance at all, a flag is set. Let's call it "I_have_computed_attributes" for now. Derived classes inherit the flag from base classes. Instances inherit the flag from classes. -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From donb at init.com Fri Jul 21 20:54:13 2000 From: donb at init.com (Donald Beaudry) Date: Fri, 21 Jul 2000 14:54:13 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <200007211726.TAA04540@python.inrialpes.fr> Message-ID: <200007211854.OAA06814@zippy.init.com> Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) wrote, > Paul, this is clearly unclear <0.1 wink>. I for one don't get it. > The whole point of __getattr__, __setattr__ is to trap attribute > accesses and assignment. Python lets you trap the attribute binding > process through these two functions. At yes, it is common case, > because people want to specialize the binding rules in an object's > namespace. The __getattr__ and __setattr__ mechanism is useful but hard to use. Paul's proposal suggests makeing it easier to override access for a single attribute.... or am I unclear on what you are unclear about? > However, this is defined only for Python's instance objects. If this > is intended to generalize the concept for builtin objects, then you > reach the object model deficiencies (metacalass, type dochotomy, etc.) > which is not a trivial problem. Whoa.... where did that come from. While the idea behind Paul's proposal could easily be applied to builtin objects (I've been using the technique for years) he's not even mentioning them in the proposal. It would still be up to the extension writer to decide how best to implement tp_setattr and tp_getattr. Only the instanceobject's tp_setattr and tp_getattr would need to change. > If you're running after performance, because this programmable > trapping occurs only in Python, well, state it explicitely in your > writing. I dont see performance as the big issue here. What I do see is a tidying up of a common usage of the current __setattr__/__getattr__ mechanism. For better or worse, it will make it much easier to write code which controls access to an attribute. > I believe that you're running after the generalization. I am not > sure that what's in this per-PEP is a generic solution > though. Because you're discussing handlers written in Pythonland > (and this is also unclear in your writing). Simply put, these > handlers would be invoked by hooks taken into account by the C > code. Except hooking dict lookups with Python or C handlers, I don't > see the point of this PEP. Wow! What does Paul's proposal have to do with hooking dict lookups? ...or is that what you are wondering? If that's what you are wondering, wonder no more. There is no connection. > If the handlers are written in Python, this is what you get with > __getattr__ and __setattr__. If you think C handlers, well, tell us > about it explicitely. Ah... now I see where *you* think Paul is going. To implement this, I would write up a little object called attrobject which would be very similar to a instancemethod. When the class is created I would check for methods whos names matched the __attr__XXX pattern. For each of these methods I would create an attrobject to wrap it then stick that back in the class dictionary under the name XXX. The tp_getattr method would then go through it's normal lookup procedure. But, before returning the result it would check the type of the object. If the object is an attrobject, the associated method would be called. The result of that call would be return from tp_getattr. The tp_setattr changes are where Paul's proposal loses. To make this work it becomes necessary to first attempt a "modified" getattr to determine if an attrobject exist for this attribute. I say "modified" getattr because in this case we dont really want to evaluate the attrobject. If no attrobject exists for the named attribute the set operation proceed as usual. If one does exist, it's associated method is called with the specified value. What hurts here is that it is now necessary to do that "modified" getattr on each set operation. If this is what you mean by "C handlers", then that's what Paul (in my opinion) is saying. Otherwise... -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb at init.com Lexington, MA 02421 ...Will hack for sushi... From donb at init.com Fri Jul 21 21:00:00 2000 From: donb at init.com (Donald Beaudry) Date: Fri, 21 Jul 2000 15:00:00 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <1247920968-15427430@hypernet.com> Message-ID: <200007211900.PAA06902@zippy.init.com> try: "Gordon McMillan" wrote, > > Proposed Implementation > > > > There is a new object called a computed attribute object. It > > has three attributes: get, set, delete. > > raise InternalInconsistencyError except InternalInconsistencyError: see_previous_posts_suggesting_get_set_del_all_be_moved_to_a_single_method() -- Donald Beaudry Ab Initio Software Corp. 201 Spring Street donb at init.com Lexington, MA 02421 ...So much code, so little time... From bwarsaw at beopen.com Fri Jul 21 21:17:57 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 21 Jul 2000 15:17:57 -0400 (EDT) Subject: [Python-Dev] Where to put the PEPs? (was: Re: Python-dev summary: July 1-15) References: <20000718100813.C21354@newcnri.cnri.reston.va.us> <3974E8CD.55215FD9@inrialpes.fr> <3975E180.1AFD30D@roguewave.com> <39760129.9BA42B7E@schneider-kamp.de> <20000719211306.F9897@xs4all.nl> <3976C9FF.A7799738@schneider-kamp.de> <14711.2226.242735.766934@beluga.mojam.com> <20000720152633.H8820@lyra.org> <200007210033.UAA31657@zippy.init.com> <20000721075915.Y9897@xs4all.nl> Message-ID: <14712.41445.595701.546261@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> And that's perfectly sensible. I'm not a crypto-junkie in any TW> way, but using ssh with non-passphrase-protected is dangerous TW> stuff. We do use it, at XS4ALL, actually, for scripts to TW> execute commands on remote machines, but we do it with TW> seperate keysets, and restricted per host. Right, that's the way to do it. Remember that you can have multiple keypairs associated with your shell account, so if you /really/ wanted to do this (and I don't suggest it), then generate a new keypair, leave the new private key unpassphrase protected, and upload the new keypair to SF. Use this keypair only for SF so if it's cracked your exposure is minimized. As paranoid as I am, I usually generate new keypairs when I travel with my ssh client. I use that keypair only for that trip and discard it when I get back. -Barry From bwarsaw at beopen.com Fri Jul 21 21:30:33 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 21 Jul 2000 15:30:33 -0400 (EDT) Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> Message-ID: <14712.42201.725616.586420@anthem.concentric.net> >>>>> "PS" == Peter Schneider-Kamp writes: PS> I have put up the PEPs on http://python.sourceforge.net/peps/ Very cool, thanks! And thanks to /F for his conversion script PS> 1) Is that okay? No one cried out aloud and I got some PS> agreement. Yes, but I would make a couple of suggestions. 1) Let's change the project homepage to point to python.sourceforge.net with a prominent link back to www.python.org. Otherwise, /finding/ these peps and the other useful information isn't as convenient. 2) I'm not crazy about the front page for python.sourceforge.net. Do the links go with the blue box above or below the link? The first box say "On this site..." Which is this site? python.sourceforge.net or the site pointed to by the link above (or below :)? Do the blue boxes serve any real purpose? PS> 2) Should I put a link from http://python.sourceforge.net ? Which of course you did, so thanks! PS> 3) What about making those PEPs xhtml (or something like PS> that)? | Pros: | - links from pep-000.txt | - links from the other peps | Cons: | - harder to read in checkins | - harder to edit | (maybe we could use as little markup as possible?) Definitely -1 as other have said. PEPs should be plain text. /F's conversion script is perfect. -Barry From paul at prescod.net Fri Jul 21 21:36:47 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 14:36:47 -0500 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> Message-ID: <3978A64F.249C22F3@prescod.net> "Barry A. Warsaw" wrote: > > 2) I'm not crazy about the front page for python.sourceforge.net. > Do the links go with the blue box above or below the link? The > first box say "On this site..." Which is this site? > python.sourceforge.net or the site pointed to by the link above (or > below :)? Do the blue boxes serve any real purpose? A clear title at the top would be good. The other titles don't need to be in all caps. The blue tables are not necessary. Keep it simple Schneider-Kamp :) Still, what is there is so much better than what was there before that I feel bad complaining. It's definately an important development! -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From gmcm at hypernet.com Fri Jul 21 21:58:20 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Fri, 21 Jul 2000 15:58:20 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <397898D7.1D16A2B@prescod.net> Message-ID: <1247912995-15907044@hypernet.com> Paul Prescod wrote: > Performance is only one of the goals. Clarity is the more major > one. Safety is another. When you start combining __getattr__ with > multiply inherited base class __getattr__ and so forth you get > into a real mess. This proposal does not have that problem. You're doing some obsfucating here. Overriding a method with multiple base class implementations of that method with the desire to chain to one or more of the base class implementations of that method is a mess. It's not more of a mess because the method is named __getattr__. The obvious solution has nothing to do with the language - it's to use has-a instead of is-a. This proposal changes those semantics. Hooking an attribute masks anything in a base class with that name. That's probably a good thing, but it should be made explicit since that's not the way __getattr__ behaves. Similarly, there's a difference from __setattr__. If you assign to the instance.__dict__, the hook will no longer apply for that instance / attribute. Also note that while this is *safer* than __xxxattr__, it's still not *safe*. Infinite recursion is less likely, but still easily achieved. Truth-in-PEPs-ly y'rs - Gordon From paul at prescod.net Fri Jul 21 22:38:25 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 15:38:25 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <1247912995-15907044@hypernet.com> Message-ID: <3978B4C1.99BDD4CF@prescod.net> Gordon McMillan wrote: > > ... > > You're doing some obsfucating here. Overriding a method with > multiple base class implementations of that method with the > desire to chain to one or more of the base class > implementations of that method is a mess. It's not more of a > mess because the method is named __getattr__. > ... Solving the particular problem I am trying to solve is extremely messy in a deep hiearchy with one or more __getattr__ implementations. You must know about all of the parent getattrs and understand their semantics enough to to decide what order to call them in. If you think of getattr as "just another method" then there is no problem but it isn't just another method. It's a method that is used to implement a variety of radically different patterns. > This proposal changes those semantics. Hooking an attribute > masks anything in a base class with that name. That's > probably a good thing, but it should be made explicit since > that's not the way __getattr__ behaves. I don't see the difference. def __attr_XXX__( self, op, va ): Parent.__attr_XXX__( self, op, val ) You can still chain if you want. > Similarly, there's a difference from __setattr__. If you assign to > the instance.__dict__, the hook will no longer apply for that > instance / attribute. That's true. > Also note that while this is *safer* than __xxxattr__, it's still > not *safe*. Infinite recursion is less likely, but still easily > achieved. The ability to recurse infinitely is a property of methods in general, not this method in particular. Okay, it is a little more likely because of a logic flaw but I don't see that as being unsafe. I see the current __getattr__ hacks as being unsafe because in a deep inheritance hierarchy a seemingly insignicant addition in one place will break code somewhere else. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From gmcm at hypernet.com Fri Jul 21 23:27:29 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Fri, 21 Jul 2000 17:27:29 -0400 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <3978B4C1.99BDD4CF@prescod.net> Message-ID: <1247907646-16228779@hypernet.com> Paul Prescod wrote: > Gordon McMillan wrote: > > This proposal changes those semantics. Hooking an attribute > > masks anything in a base class with that name. That's probably > > a good thing, but it should be made explicit since that's not > > the way __getattr__ behaves. > > I don't see the difference. > > def __attr_XXX__( self, op, va ): > Parent.__attr_XXX__( self, op, val ) > > You can still chain if you want. You can? Your proposal only specified that when the class object is being created, method names of the form __attr_XXX__ would cause stuff to happen in the way the class is built. You never said that accesses to things named __YYY_XXX__ on another object would also get transformed into something else. Also, what if the base class just has "attr" - not a hook at all? It will be masked by the hook (which is the difference in behavior I was pointing out). > > Similarly, there's a difference from __setattr__. If you assign > > to the instance.__dict__, the hook will no longer apply for > > that instance / attribute. > > That's true. > > > Also note that while this is *safer* than __xxxattr__, it's > > still not *safe*. Infinite recursion is less likely, but still > > easily achieved. > > The ability to recurse infinitely is a property of methods in > general, not this method in particular. Okay, it is a little more > likely because of a logic flaw but I don't see that as being > unsafe. And earlier I said: > > Overriding a method with > > multiple base class implementations of that method with the > > desire to chain to one or more of the base class > > implementations of that method is a mess. It's not more of a > > mess because the method is named __getattr__. ... So I guess we're even, since we've used the same argument both ways. > I see the current __getattr__ hacks as being unsafe because in a > deep inheritance hierarchy a seemingly insignicant addition in > one place will break code somewhere else. Deep inheritance hierarchies are unpythonic <0.001 wink>. - Gordon From paul at prescod.net Fri Jul 21 23:54:24 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 16:54:24 -0500 Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <1247907646-16228779@hypernet.com> Message-ID: <3978C690.ED273B22@prescod.net> Gordon McMillan wrote: > > You can? Your proposal only specified that when the class > object is being created, method names of the form > __attr_XXX__ would cause stuff to happen in the way the class > is built. You never said that accesses to things named > __YYY_XXX__ on another object would also get transformed > into something else. I would say that __attr_XXX__ causes two things to go into the __dict__: __attr_XXX___ = XXX = So you can call __attr_XXX__ directly just as you can call __getattr__ directly or __init__ etc. > Deep inheritance hierarchies are unpythonic <0.001 wink>. I'm told that in Zope even shallow hiearchies that use __getattr__ cause problems. I proposed this idea about three years ago. I'm only bringing it up again now because of a problem getting the DOM to work with Zope because of Zope's use of __getattr__. I'm told this has gotten better recently but I still see it as a symptom of a problem. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From bckfnn at worldonline.dk Fri Jul 21 23:59:53 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Fri, 21 Jul 2000 21:59:53 GMT Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <39787983.9682ABC5@prescod.net> References: <39787983.9682ABC5@prescod.net> Message-ID: <3978c7bf.10449886@smtp.worldonline.dk> [Paul Prescod on computed attributes] I'm not sure how well this is connected, but I would like to describe an existing feature of JPython that allow for computed attributes. The implementation of every python object have three methods (a little simplified): public PyObject _doget(PyObject container) { return this; } public boolean _doset(PyObject container, PyObject value) { return false; } public boolean _dodel(PyObject container) { return false; } As part of the implementation of __getattr__, the _doget method is always called: public PyObject __findattr__(String name) { ... PyObject ret = __class__.lookup(name, false); if (ret != null) return ret._doget(this); return null; } This way each computed attribute get controll when accessed, modified and deleted. The hooks primary purpose is to support JPythons use of java bean properties, fields and methods. It is currently not available from within python, so it is not possible to define "def _doget(..)" in a python class. All this is just a datapoint. regards, finn From bwarsaw at beopen.com Sat Jul 22 02:16:37 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 21 Jul 2000 20:16:37 -0400 (EDT) Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 References: <39787983.9682ABC5@prescod.net> <3978c7bf.10449886@smtp.worldonline.dk> Message-ID: <14712.59365.265600.645342@anthem.concentric.net> >>>>> "FB" == Finn Bock writes: FB> This way each computed attribute get controll when accessed, FB> modified and deleted. The hooks primary purpose is to support FB> JPythons use of java bean properties, fields and methods. It FB> is currently not available from within python, so it is not FB> possible to define "def _doget(..)" in a python class. FB> All this is just a datapoint. But a good one, and perhaps one to model CPython on. There are also similarities here with the Zope Acquisition model, which uses __of__ instead. So this is clearly a functionality that is very useful in some contexts. JPython's __findattr__ hook might also be useful because it allows interposition on the lookup of all names, i.e. not just missing names. In any event, we should look to JPython as an example of how it might be done, but once a formal mechanism is adopted for CPython, we'll add it to the language spec and update JPython to support the same mechanism. -Barry From hzhu at rocket.knowledgetrack.com Sat Jul 22 04:08:22 2000 From: hzhu at rocket.knowledgetrack.com (Huaiyu Zhu) Date: Fri, 21 Jul 2000 19:08:22 -0700 Subject: [Python-Dev] Re: questionnaire about zip and for loops In-Reply-To: <3976BDF7.82FB6C56@schneider-kamp.de> References: <3976BDF7.82FB6C56@schneider-kamp.de> Message-ID: <200007220208.TAA00997@rocket.knowledgetrack.com> You need to add a Reply-To: line so people wouldn't send to the list by mistake. It is also difficult for many editors and mailers to deal with long lines. Huaiyu In comp.lang.python, you wrote: >This is a slightly reduced version of a questionnaire run by Greg Wilson on some CS >grad students. > >I'd like to use the readers of comp.lang.python as guinea pigs this time. > >PLEASE SEND THE RESULTS TO mailto:peter at schneider-kamp.de - DON'T SEND THEM TO THE LIST > >Thanks for your time, >Peter > >----------------------------------------------------------------------------------------- > >The single and double loop below print the output shown: > >for x in [10, 20, 30]: for x in [10, 20, 30]: > print x for y in [1, 2, 3]: > print x+y >10 11 >20 12 >30 13 > 21 > 22 > 23 > 31 > 32 > 33 > >Match each of the following example for-loops to an output. Only make one cross per line. >Please consider each example on its own. >(Note that several examples may print the same thing.) > > > (1) (2) (3) (4) (5) (6) > > 11 11 11 11 error ?? > 22 12 22 12 > 33 13 21 > 21 22 > 22 31 > 23 32 > 31 > 32 > 33 > >(A) >for (x, y) in [[10, 1], [20, 2], [30, 3]]: x o o o o o > print x+y > >(B) >for [x, y] in zip([10, 20, 30], [1, 2, 3]): x o o o o o > print x+y > >(C) >for [x, y] in zip([10, 20, 30], [1, 2]): o o x o o o > print x+y > >(D) >for x; y in [10, 20, 30]; [1, 2, 3]: o o o o x o > print x+y > >(E) >for x; y in [10, 20, 30]; [1, 2]: o o o o x o > print x+y > >(F) >for x in [10, 20, 30]; y in [1, 2, 3]: o x o o o o > print x+y > >(G) >for x in [10, 20, 30]; y in [1, 2]: o o o x o o > print x+y > > >-- >Peter Schneider-Kamp ++47-7388-7331 >Herman Krags veg 51-11 mailto:peter at schneider-kamp.de >N-7050 Trondheim http://schneider-kamp.de > From peter at schneider-kamp.de Sat Jul 22 06:59:38 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 04:59:38 +0000 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> Message-ID: <39792A39.B5C71052@schneider-kamp.de> "Barry A. Warsaw" wrote: > > >>>>> "PS" == Peter Schneider-Kamp writes: > > PS> I have put up the PEPs on http://python.sourceforge.net/peps/ > > Very cool, thanks! And thanks to /F for his conversion script > > PS> 1) Is that okay? No one cried out aloud and I got some > PS> agreement. > > Yes, but I would make a couple of suggestions. > > 1) Let's change the project homepage to point to > python.sourceforge.net with a prominent link back to > www.python.org. Otherwise, /finding/ these peps and the other > useful information isn't as convenient. > > 2) I'm not crazy about the front page for python.sourceforge.net. > Do the links go with the blue box above or below the link? The > first box say "On this site..." Which is this site? > python.sourceforge.net or the site pointed to by the link above (or > below :)? Do the blue boxes serve any real purpose? I'm no big bad designer guy. I didn't like it either, but I figured that (as it is in the CVS) someone would come around and put something nicer there. Well, I've tried my luck once again. Hope this one is better: http://python.sourceforge.net feedback-appreciating-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From peter at schneider-kamp.de Sat Jul 22 07:03:39 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 05:03:39 +0000 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> Message-ID: <39792B2B.DA3D36DC@schneider-kamp.de> "Barry A. Warsaw" wrote: > > 1) Let's change the project homepage to point to > python.sourceforge.net with a prominent link back to > www.python.org. Otherwise, /finding/ these peps and the other > useful information isn't as convenient. Ah yes. If this is considered to be a Wise Idea(TM), then could someone with admin rights change this? ain't-no-project-admin-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From paul at prescod.net Sat Jul 22 05:07:48 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 21 Jul 2000 22:07:48 -0500 Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> <39792A39.B5C71052@schneider-kamp.de> Message-ID: <39791004.95AA6994@prescod.net> Peter Schneider-Kamp wrote: > >... > > Well, I've tried my luck once again. Hope this one is better: > http://python.sourceforge.net It's a beaut! Uncluttered and clean. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From bwarsaw at beopen.com Sat Jul 22 05:48:12 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 21 Jul 2000 23:48:12 -0400 (EDT) Subject: [Python-Dev] PEPs on the web References: <39774A29.86E469BB@schneider-kamp.de> <14712.42201.725616.586420@anthem.concentric.net> <39792A39.B5C71052@schneider-kamp.de> Message-ID: <14713.6524.705655.958481@anthem.concentric.net> >>>>> "PS" == Peter Schneider-Kamp writes: PS> I'm no big bad designer guy. I didn't like it either, but I PS> figured that (as it is in the CVS) someone would come around PS> and put something nicer there. PS> Well, I've tried my luck once again. Hope this one is better: PS> http://python.sourceforge.net Perfect! >> 1) Let's change the project homepage to point to >> python.sourceforge.net with a prominent link back to >> www.python.org. Otherwise, /finding/ these peps and the other >> useful information isn't as convenient. PS> Ah yes. If this is considered to be a Wise Idea(TM), then PS> could someone with admin rights change this? Done. Thanks, -Barry From bwarsaw at beopen.com Sat Jul 22 06:47:32 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sat, 22 Jul 2000 00:47:32 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP Message-ID: <14713.10084.165489.836569@anthem.concentric.net> I've long wanted to make the print statement able to handle alternative output files in a more convenient syntax. Yes you can rebind sys.stdout, but that is often very clumsy to get right in the face of exceptions. All the talk about extra operators has made me giddy (no, not geddy :) so my proposal is to allow `@' after the print keyword using syntax such as: print @ sys.stderr, 'hello' The thing between the @ and the , must be an expression yeilding an object with a write() method, otherwise you'd get a runtime exception (probably TypeError). Thus, these two are equivalent: print @ sys.stdout, 'wassup?' print 'wassup?' It makes it quite convenient to do things like: f = open('log, 'w') print @ f, 'starting' do_something_that_expects_to_print_to_stdout() print @ f, 'ending' etc., etc. I started hacking on the grammar to play with this, but haven't gotten very far, and I'm way too tired to continue tonight. I'd continue though if there's positive feedback. Thoughts? -Barry From moshez at math.huji.ac.il Sat Jul 22 08:49:57 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 22 Jul 2000 09:49:57 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.10084.165489.836569@anthem.concentric.net> Message-ID: On Sat, 22 Jul 2000, Barry A. Warsaw wrote: > I've long wanted to make the print statement able to handle > alternative output files in a more convenient syntax. Yes you can > rebind sys.stdout, but that is often very clumsy to get right in the > face of exceptions. Then why not go the other way, and get sys.stdout-rebinding easier to get right? something like sys.push_stdout(fileobj) try: print and stuff finally: sys.pop_stdout() > Thoughts? Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating Python way too much. -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From tim_one at email.msn.com Sat Jul 22 09:06:59 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 03:06:59 -0400 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <20000720221300.W9897@xs4all.nl> Message-ID: [posted & mailed] [Thomas Wouters] > ... > However, I found a lot of instances of the 2nd type: empty argument > list. However, as far as I remember, ANSI C states that should be > written as '(void)'. Yes. > I also found a number of files which were already converted to > ANSI syntax, but with one function leftover. Should I bother' uploading > a patch for those, or can I just commit them ? Commit. hard-not-to-make-the-sig-look-concise-after-that!-ly y'rs - tim From mhammond at skippinet.com.au Sat Jul 22 09:18:13 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 22 Jul 2000 17:18:13 +1000 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: Message-ID: > Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating > Python way too much. I've gotta agree here - I really am quite concerned about all the cool-but-not-really-necessary stuff being proposed. I fear that Python will no longer be the small, simple to understand system that drew many of us to it in the first place. OTOH, I have great faith that Guido will simply reject most of these ideas, regardless of the huge amount of work being spent on their PEPs, etc. At least, I _hope_ he does! Our-simple-Python-is-turning-into-Medusa-ly, Mark. From tim_one at email.msn.com Sat Jul 22 09:30:00 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 03:30:00 -0400 Subject: [Python-Dev] map() for methods In-Reply-To: <39771CCE.F70A48D4@lemburg.com> Message-ID: [Skip Montanaro] > Don't know about the powers that be, but I don't see how you can > realistically deprecate string.py until you deprecate map(). My most > frequent use of map() is the simple > > newlist = map(string.strip, oldlist) > > where oldlist is a list of strings. (Replace "strip" by > "upper", "lower", etc, depending on your needs.) > > As far as I'm aware, there's no clean way to do that with > string methods. Sorry if someone pointed this out already (2K+ msgs backed up!): newlist = [s.strip() for s in oldlist] Not that that's a reason to deprecate string.py, but this use of "map" is not a reason not to deprecate it either. Ditto for "map". From gstein at lyra.org Sat Jul 22 10:27:48 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 22 Jul 2000 01:27:48 -0700 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.10084.165489.836569@anthem.concentric.net>; from bwarsaw@beopen.com on Sat, Jul 22, 2000 at 12:47:32AM -0400 References: <14713.10084.165489.836569@anthem.concentric.net> Message-ID: <20000722012748.E10086@lyra.org> On Sat, Jul 22, 2000 at 12:47:32AM -0400, Barry A. Warsaw wrote: >... > All the talk about extra operators has made me giddy (no, not geddy :) > so my proposal is to allow `@' after the print keyword using syntax > such as: > > print @ sys.stderr, 'hello' Ick. -1 Use sys.stderr.write('hello\n') Cheers, -g -- Greg Stein, http://www.lyra.org/ From thomas at xs4all.net Sat Jul 22 10:32:05 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 10:32:05 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.10084.165489.836569@anthem.concentric.net>; from bwarsaw@beopen.com on Sat, Jul 22, 2000 at 12:47:32AM -0400 References: <14713.10084.165489.836569@anthem.concentric.net> Message-ID: <20000722103204.G9897@xs4all.nl> On Sat, Jul 22, 2000 at 12:47:32AM -0400, Barry A. Warsaw wrote: > I've long wanted to make the print statement able to handle > alternative output files in a more convenient syntax. Yes you can > rebind sys.stdout, but that is often very clumsy to get right in the > face of exceptions. > print @ sys.stderr, 'hello' No offense, but I'd rather deprecate 'print' than see this. For me, 'print' is for debugging purposes only (and possibly very teensy scripts.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From peter at schneider-kamp.de Sat Jul 22 12:33:29 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 10:33:29 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.7,1.8 References: <200007212003.NAA02595@slayer.i.sourceforge.net> Message-ID: <39797879.C63724A8@schneider-kamp.de> Barry Warsaw wrote: > > + 212 pep-0212.txt Additional Builtin Generators bwarsaw Whatever happened to 212? If you don't have anything ready yet I can commit an empty version. Just tell me. BTW: I cannot ssh to shell.sourceforge.net. It worked fine 5 hours ago. CVS over ssh works fine though. I sent a support request. I tried from different machines from different countries, with password or key identification (it never got so far). Is anyone experiencing similar problems? eating-breakfast-soon-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From thomas at xs4all.net Sat Jul 22 10:47:13 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 10:47:13 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 22, 2000 at 03:06:59AM -0400 References: <20000720221300.W9897@xs4all.nl> Message-ID: <20000722104713.H9897@xs4all.nl> On Sat, Jul 22, 2000 at 03:06:59AM -0400, Tim Peters wrote: > > I also found a number of files which were already converted to > > ANSI syntax, but with one function leftover. Should I bother' uploading > > a patch for those, or can I just commit them ? > Commit. Well, I already did that ;) I've also ANSIfied everything in Python/ and Parser/, and the couple of declarations in PC/ that were still using empty argument lists. The changes fall in two categories: those I can test (and have tested and seem to work fine) and those that I can't test because I haven't such expensive hardware. I'll upload the latter category, and I'm perfectly willing to upload the former one, too, but I wonder if anyone is actually going to review them ? If not, well, there's not much use in uploading them, is there ? Also, there is an issue with extern function declarations: should we change all those to full prototypes ? Some aren't too obvious (like the ^*@#$&** readline functions, which don't have prototypes to start with, and the info pages are not very helpful) and in one spot a function of the wrong type is passed to PyAddCallback, resulting in a new warning during -Wall ;) A cast can fix that, though. And then there is the question whether all those externs are really necessary. They seem to be put in because one OS or another was missing them in a header file, but giving them prototypes from a Linux system might give more warnings on other platforms: a 'const char **' is not the same pointer as a 'char **', even though a 'const char *' is the same as a 'char *'. Perhaps these prototyped function declarations should be put in pyport.h, instead, surrounded by platform #ifdefs ? Make-me-checkin-all-these-changes-and-I'll-end-up-next-to-Guido-on-the- -SourceForge-CVS-stats-ly y'rs, ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sat Jul 22 10:54:54 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 22 Jul 2000 10:54:54 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP References: Message-ID: <00d601bff3ba$8300d640$f2a6b5d4@hagrid> mark wrote: > I've gotta agree here - I really am quite concerned about all the > cool-but-not-really-necessary stuff being proposed. I fear that Python > will no longer be the small, simple to understand system that drew many of > us to it in the first place. that's only because you're a lazy guy, and don't want to have to implement one weird thing after another in your compiler, just be- cause someone submitted a patch to CPython ;-) (seriously, I *strongly* agree with what you're saying, but you already knew that, of course... or maybe that's just because I'm a lazy guy, and don't want to implement one weird thing after an- other in my tools) > OTOH, I have great faith that Guido will simply reject most of these ideas, > regardless of the huge amount of work being spent on their PEPs, etc. At > least, I _hope_ he does! well, if he doesn't, we can always join the Perl6 project... > Our-simple-Python-is-turning-into-Medusa-ly, hey, what's wrong with Sam's Medusa server? ;-) From thomas at xs4all.net Sat Jul 22 10:51:58 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 10:51:58 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.7,1.8 In-Reply-To: <39797879.C63724A8@schneider-kamp.de>; from peter@schneider-kamp.de on Sat, Jul 22, 2000 at 10:33:29AM +0000 References: <200007212003.NAA02595@slayer.i.sourceforge.net> <39797879.C63724A8@schneider-kamp.de> Message-ID: <20000722105158.I9897@xs4all.nl> On Sat, Jul 22, 2000 at 10:33:29AM +0000, Peter Schneider-Kamp wrote: > Barry Warsaw wrote: > > + 212 pep-0212.txt Additional Builtin Generators bwarsaw > Whatever happened to 212? If you don't have anything ready yet > I can commit an empty version. Just tell me. 'Whatever happened' is that Barry assigned himself to that PEP just yesterday, and has been too busy with all those other things to check even the template in ;) > BTW: I cannot ssh to shell.sourceforge.net. It worked fine 5 hours > ago. CVS over ssh works fine though. I sent a support request. > Is anyone experiencing similar problems? Ayup: centurion:~/python/python-anon/dist/src/Python > ssh -v shell.sourceforge.net SSH Version 1.2.27 [i586-unknown-linux], protocol version 1.5. Standard version. Does not use RSAREF. centurion.xs4all.nl: Reading configuration data /home/thomas/.ssh/config centurion.xs4all.nl: Applying options for * centurion.xs4all.nl: Reading configuration data /etc/ssh/ssh_config centurion.xs4all.nl: Applying options for * centurion.xs4all.nl: ssh_connect: getuid 500 geteuid 0 anon 0 centurion.xs4all.nl: Connecting to shell.sourceforge.net [198.186.203.36] port 22. centurion.xs4all.nl: Allocated local port 1013. centurion.xs4all.nl: Connection established. Connection closed by foreign host. 'ssh' is broken, or they have nameserver difficulties and a fascist-loggingly sshd, or the machines is just overtaxed or so. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sat Jul 22 11:03:51 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 22 Jul 2000 11:03:51 +0200 Subject: [Python-Dev] ANSIfication again ;) References: <20000720221300.W9897@xs4all.nl> <20000722104713.H9897@xs4all.nl> Message-ID: <00fd01bff3bb$c2f47da0$f2a6b5d4@hagrid> thomas wrote: > Make-me-checkin-all-these-changes-and-I'll-end-up-next-to-Guido-on-the- > -SourceForge-CVS-stats-ly y'rs, ;-) don't worry -- after the consortium meeting yesterday, he'll probably change the copyright on all files again... From effbot at telia.com Sat Jul 22 11:08:36 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 22 Jul 2000 11:08:36 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/sf-html at.gif,NONE,1.1 py.gif,NONE,1.1 sf.gif,NONE,1.1 index.html,1.2,1.3 References: <200007220253.TAA12076@slayer.i.sourceforge.net> Message-ID: <010701bff3bc$6be16cc0$f2a6b5d4@hagrid> peter wrote: > GIF89aT looks like you checked them in as text files... From peter at schneider-kamp.de Sat Jul 22 13:04:30 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 11:04:30 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.7,1.8 References: <200007212003.NAA02595@slayer.i.sourceforge.net> <39797879.C63724A8@schneider-kamp.de> <20000722105158.I9897@xs4all.nl> Message-ID: <39797FBE.A91CAFC6@schneider-kamp.de> Thomas Wouters wrote: > > 'Whatever happened' is that Barry assigned himself to that PEP just > yesterday, and has been too busy with all those other things to check even > the template in ;) I guessed so. I have checked in an empty template. > > Is anyone experiencing similar problems? > > Ayup: glad-it's-not-just-me-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From peter at schneider-kamp.de Sat Jul 22 13:28:34 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sat, 22 Jul 2000 11:28:34 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/sf-html at.gif,NONE,1.1 py.gif,NONE,1.1 sf.gif,NONE,1.1 index.html,1.2,1.3 References: <200007220253.TAA12076@slayer.i.sourceforge.net> <010701bff3bc$6be16cc0$f2a6b5d4@hagrid> Message-ID: <39798562.CEF75D2D@schneider-kamp.de> Fredrik Lundh wrote: > > looks like you checked them in as text files... oops. i removed them and added them as binary files. having-put-this-in-the-faq-so-I-can-remember-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From tim_one at email.msn.com Sat Jul 22 11:29:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 05:29:47 -0400 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <20000722104713.H9897@xs4all.nl> Message-ID: [Thomas Wouters] > ... > I've also ANSIfied everything in Python/ and Parser/, and the couple of > declarations in PC/ that were still using empty argument lists. > > The changes fall in two categories: those I can test (and have tested and > seem to work fine) and those that I can't test because I haven't such > expensive hardware. Didn't we go thru this before? If "expensive hardware" means SGI, Guido said commit SGI ANSIfication patches. > I'll upload the latter category, and I'm perfectly willing to upload > the former one, too, Does "upload" mean "submit a patch" or "commit"? Commit. > but I wonder if anyone is actually going to review them ? Don't want a patch for this. Commit. > ... > Also, there is an issue with extern function declarations: should > we change all those to full prototypes ? Every function call should have a prototype in scope. That's the answer to the question you meant to ask . > Some aren't too obvious (like the ^*@#$&** readline functions, which > don't have prototypes to start with, and the info pages are not very > helpful) and in one spot a function of the wrong type is passed to > PyAddCallback, resulting in a new warning during -Wall ;) A cast > can fix that, though. > > > And then there is the question whether all those externs are really > necessary. ... Every function call should have a prototype in scope. There is no other goal here -- ANSIfication is for a reason, not just to say "it's been ANSIfied". If this causes warnings, good! It's turning up bugs in the code then. Casts are rarely the correct way to fix those, though (e.g., *why* is a function of the wrong type being passed? don't cast the warning away without understanding that fully). > ... [...] ... Too much detail for me. Fix them or don't, but I don't think it needs this much discussion. If you don't know how to fix some particular one, try posting a focused single-issue msg about that particular one. > ... > Make-me-checkin-all-these-changes-and-I'll-end-up-next-to-Guido-on-the- > -SourceForge-CVS-stats-ly y'rs, ;-) Heh -- nothing would please him more! From thomas at xs4all.net Sat Jul 22 11:30:28 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 11:30:28 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <00fd01bff3bb$c2f47da0$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jul 22, 2000 at 11:03:51AM +0200 References: <20000720221300.W9897@xs4all.nl> <20000722104713.H9897@xs4all.nl> <00fd01bff3bb$c2f47da0$f2a6b5d4@hagrid> Message-ID: <20000722113028.J9897@xs4all.nl> On Sat, Jul 22, 2000 at 11:03:51AM +0200, Fredrik Lundh wrote: > > Make-me-checkin-all-these-changes-and-I'll-end-up-next-to-Guido-on-the- > > -SourceForge-CVS-stats-ly y'rs, ;-) > don't worry -- after the consortium meeting yesterday, he'll > probably change the copyright on all files again... Yeah, about the consortium meeting... any idea when the general public and grunts like us (well, me, in any case) get to hear the results ? The subject is pretty dear to us, you see ;-P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sat Jul 22 11:38:16 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 11:38:16 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 22, 2000 at 05:29:47AM -0400 References: <20000722104713.H9897@xs4all.nl> Message-ID: <20000722113816.K9897@xs4all.nl> On Sat, Jul 22, 2000 at 05:29:47AM -0400, Tim Peters wrote: > [Thomas Wouters] > > The changes fall in two categories: those I can test (and have tested and > > seem to work fine) and those that I can't test because I haven't such > > expensive hardware. > Didn't we go thru this before? If "expensive hardware" means SGI, Guido > said commit SGI ANSIfication patches. OS/2, NT, etc, are quite a bit different from SGI. SGI is UNIX, which I grok. I can't claim the same for NT ;P > Does "upload" mean "submit a patch" or "commit"? Commit. upload means submit a patch. I was nearly done uploading them, too! I guess I'll mark them as 'accepted' and commit them instead. > > but I wonder if anyone is actually going to review them ? > Don't want a patch for this. Commit. Will do. I'll need to generate new ones for compile.c and ceval.c, though, because these were done relative to the range-literals patch. > Every function call should have a prototype in scope. That's the answer to > the question you meant to ask . Each time you post one of these 'go ahead and do it' messages, I go ahead and do it, thinking to myself, "he said that before". And then the next time I see something I'm not quite sure about, I think "he said to go ahead and do it... but that was not about 'this', it was about the slightly different 'that' instead." ;P Simply-trying-not-to-overstep-my-bounds-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Sat Jul 22 12:13:03 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 22 Jul 2000 12:13:03 +0200 Subject: [Python-Dev] slightly OT: perl and tcl teams are reorganizing Message-ID: <018501bff3c5$70b54ce0$f2a6b5d4@hagrid> tcl: http://dev.ajubasolutions.com/community/coreteam/ perl: http://www.perl.org/perl6/ http://www.news.perl.org/perl-news.cgi?item=964033768%7C25110 From tim_one at email.msn.com Sat Jul 22 12:15:43 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 06:15:43 -0400 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <20000722113816.K9897@xs4all.nl> Message-ID: [Tim] >> Didn't we go thru this before? If "expensive hardware" means SGI, Guido >> said commit SGI ANSIfication patches. [Thomas Wouters] > OS/2, NT, etc, are quite a bit different from SGI. SGI is UNIX, which I > grok. I can't claim the same for NT ;P NT is expensive hardware? That MS .NET project is more ambitious than I thought . >> commit ... commit ... commit > Will do. Excellent. > ... > Each time you post one of these 'go ahead and do it' messages, I go > ahead and do it, thinking to myself, "he said that before". And then > the next time I see something I'm not quite sure about, I think "he > said to go ahead and do it... but that was not about 'this', it was > about the slightly different 'that' instead." ;P > > Simply-trying-not-to-overstep-my-bounds-ly y'rs, There's no way to find out your bounds *except* by going beyond them -- which, happily enough, is also the way to expand your bounds. If we didn't think you were a perfectly wonderful human being, you wouldn't have gotten commit access to begin with. Do note that Guido has yelled at people only a few times here so far, and all of those on the receiving end are still here -- including me. But then he was surely wrong to yell at me . an-exaggerated-sense-of-one's-own-importance-is-a-virtue- in-this-field-ly y'rs - tim From tim_one at email.msn.com Sat Jul 22 12:15:45 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 06:15:45 -0400 Subject: Consortium mtg non-news (was RE: [Python-Dev] ANSIfication again ;)) In-Reply-To: <20000722113028.J9897@xs4all.nl> Message-ID: [Thomas Wouters] > ... about the consortium meeting... any idea when the general public and > grunts like us (well, me, in any case) get to hear the results ? > The subject is pretty dear to us, you see ;-P Me too! Guido went to the consortium mtg on Friday, but Fred, Jeremy and I are not consortium members, so didn't attend -- we spent 12+ hours fighting to get home from California instead (Jeremy, you missed some delightful midnight freeway gridlock heading into VA), and haven't heard from Guido either. There was some good reason for optimism before the mtg. The only email Guido sent after the mtg was some bad news about PythonLabs office space, so I assume he didn't think good news was worth mentioning <0.9 wink>. may-as-well-study-the-entrails-of-a-pigeon-ly y'rs - tim From esr at thyrsus.com Sat Jul 22 12:55:46 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Sat, 22 Jul 2000 06:55:46 -0400 Subject: Consortium mtg non-news (was RE: [Python-Dev] ANSIfication again ;)) In-Reply-To: References: <20000722113028.J9897@xs4all.nl> Message-ID: <20000722065546.A18263@thyrsus.com> Tim Peters : > [Thomas Wouters] > > ... about the consortium meeting... any idea when the general public and > > grunts like us (well, me, in any case) get to hear the results ? > > The subject is pretty dear to us, you see ;-P > > Me too! Guido went to the consortium mtg on Friday, but Fred, Jeremy and I > are not consortium members, so didn't attend -- we spent 12+ hours fighting > to get home from California instead (Jeremy, you missed some delightful > midnight freeway gridlock heading into VA), and haven't heard from Guido > either. There was some good reason for optimism before the mtg. The only > email Guido sent after the mtg was some bad news about PythonLabs office > space, so I assume he didn't think good news was worth mentioning <0.9 > wink>. I won't steal Guido's thunder, but I will say that the meeting went well in all important respects (aside from being boring for long periods :-)). I think all the surprises will be pleasant ones. -- Eric S. Raymond Power concedes nothing without a demand. It never did, and it never will. Find out just what people will submit to, and you have found out the exact amount of injustice and wrong which will be imposed upon them; and these will continue until they are resisted with either words or blows, or with both. The limits of tyrants are prescribed by the endurance of those whom they oppress. -- Frederick Douglass, August 4, 1857 From effbot at telia.com Sat Jul 22 14:28:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 22 Jul 2000 14:28:19 +0200 Subject: [Python-Dev] slightly OT: perl and tcl teams are reorganizing References: <018501bff3c5$70b54ce0$f2a6b5d4@hagrid> Message-ID: <022601bff3d8$551ccea0$f2a6b5d4@hagrid> first this: > http://dev.ajubasolutions.com/community/coreteam/ ...new, larger, "batteries included" releases... and then I stumbled upon this little quote on comp.lang.tcl: > > IMO, it's obvious: Tcl needs to go where people are going. Glueing to > > each and every technology under the sun, and that includes Python and > > Perl. Closing the door out of fear of being overtaken by others would > > be a big mistake. > > And let us not forget that Guido himself posted a message to c.l.t > suggesting that python and tcl pool their work at the lower level > implementation. hmm. what exactly am I missing here? ;-) From akuchlin at cnri.reston.va.us Sat Jul 22 15:25:30 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 22 Jul 2000 09:25:30 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: ; from mhammond@skippinet.com.au on Sat, Jul 22, 2000 at 05:18:13PM +1000 References: Message-ID: <20000722092530.A24247@newcnri.cnri.reston.va.us> On Sat, Jul 22, 2000 at 05:18:13PM +1000, Mark Hammond quoted: >> Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating >> Python way too much. and then wrote: >I've gotta agree here - I really am quite concerned about all the >cool-but-not-really-necessary stuff being proposed. I fear that Python Seconded from me. IMHO it's only worth adding a new feature if it multiplies power by a significant amount; if it just adds a tiny increment, it's not worth adding a small bit of extra complexity, extra code, and having to resync JPython and Python# (does that project have a name yet?). The urge to add little tiny things that make microtask X convenient is what made Perl -- and Sendmail, and DTML, and ... -- what they are today. --amk From guido at python.org Sat Jul 22 15:35:38 2000 From: guido at python.org (Guido van Rossum) Date: Sat, 22 Jul 2000 06:35:38 -0700 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722113028.J9897@xs4all.nl> <20000722065546.A18263@thyrsus.com> Message-ID: <003301bff3e1$bd5dde60$360bfea9@beopen.com> The meeting went well. Some major conclusions: - The latest license proposed by CNRI (attached) is acceptable to the consortium members and to OSI (the Open Source Initiative); Eric Raymond (who is on the OSI board) believes there will be no trouble getting it approved as Open Source at the next board meeting, which happens to be next Friday. There are remaining lingering grumblings from Richard Stallman, but these all seem to hinge on slight misreadings on his side; we believe the license is GPL compatible. We will work this out with Stallman over the next few weeks. - The python.org website will be hosted at SourceForge. As a community resource, it will be run in a way that does not advantage any one party (read: no banner ads). We will expedite transformation to Zope (Digital Creations has offered to help!), but the first priority is to get the existing site moved. Pending the move, the PythonLabs folks will be able to maintain the site as it currently exists at CNRI, like before. - Python 1.6 (a CNRI release with PythonLabs' help) will come out with CNRI's Open Source License in two phases: a beta around August 1st, and a final release mid-August (of course this schedule is subject to the usual qualifications). This will release all of the work on Python done at CNRI since 1.5.2 was released to the public -- a significant step. - Python 2.0 (a BeOpen PythonLabs release) will start with a beta release 1-2 weeks after 1.6 final is released; we're striving for a short beta cycle. New language features will include list comprehensions, range literals, the zip() function, and augmented assignment. I would like to thank all who helped reaching this conclusion: CNRI's Bob Kahn for traveling out west to discuss these issues in person, Eric Raymond and Bruce Perens for their useful contributions to the negotiations, BeOpen's Bob Weiner for taking care of the bulk of the negotiations, and the consortium member representatives for making the meeting a success! --Guido van Rossum [Note that I'm cc'ing Kahn, Perens and the consortium mailing list; please take these off your CC list when replying to this message in the python-dev list!!!] -------------- next part -------------- A non-text attachment was scrubbed... Name: PYTHON1.6revised.doc Type: application/msword Size: 23040 bytes Desc: not available URL: From paul at prescod.net Sat Jul 22 16:54:17 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 09:54:17 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> Message-ID: <3979B599.7274105C@prescod.net> "Barry A. Warsaw" wrote: > > I've long wanted to make the print statement able to handle > alternative output files in a more convenient syntax. Yes you can > rebind sys.stdout, but that is often very clumsy to get right in the > face of exceptions. Why not use outputfile.write directly? print is such a hack already. What are we trying to get at, really? What are the virtues of print, what are the virtues of "outputfile.write" and how can we combine them? -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Sat Jul 22 17:37:29 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 10:37:29 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <20000722092530.A24247@newcnri.cnri.reston.va.us> Message-ID: <3979BFB9.419EC323@prescod.net> Andrew Kuchling wrote: > > On Sat, Jul 22, 2000 at 05:18:13PM +1000, Mark Hammond quoted: > >> Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating > >> Python way too much. > and then wrote: > >I've gotta agree here - I really am quite concerned about all the > >cool-but-not-really-necessary stuff being proposed. I fear that Python > > Seconded from me. I think that this class vague complaints are a little unfair. We've had a wide range of proposals from extra functions to minor new syntax to new magical methods to radically new control flow features. It isn't helpful to lump them altogether and condemn them because Barry broke the cardinal rule of never using an at-symbol in a feature syntax. (shame on you Barry!) List which proposed features you like and don't like and why! That's the only way your concerns could really be addressed. > IMHO it's only worth adding a new feature if it > multiplies power by a significant amount; I think it is also worthwhile to recognize "conventions" that could be made clearer with first-class syntax. List comprehensions replace the map/lambda convention (and would IMHO, allow map/filter, at-least, to be deprecated). Range literals replace the for i in range(...) convention and so forth. Those of us who have already internalized the conventions are more likely to see new syntax as an intrusion rather than as a long-term clarification. > The urge to add little tiny things that make microtask X convenient is > what made Perl -- and Sendmail, and DTML, and ... -- what they are > today. Many languages (including some of the ones you mention) also suffer from the syndrome where a first-class feature has been left out so you have to memorize some stupid and non-intuitive "convention" rather than doing things in a straightforward way. I strongly feel that map/lambda and in fact most uses of map fall into this category. The concept is fine but the syntax sucks. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Sat Jul 22 17:39:30 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 10:39:30 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <20000722092530.A24247@newcnri.cnri.reston.va.us> Message-ID: <3979C032.357FCAF4@prescod.net> Andrew Kuchling wrote: > > On Sat, Jul 22, 2000 at 05:18:13PM +1000, Mark Hammond quoted: > >> Ummm...between this and Hyauiu's proposal, I'm afraid we're bloating > >> Python way too much. > and then wrote: > >I've gotta agree here - I really am quite concerned about all the > >cool-but-not-really-necessary stuff being proposed. I fear that Python > > Seconded from me. I think that this class vague complaints are a little unfair. We've had a wide range of proposals from extra functions to minor new syntax to new magical methods to radically new control flow features. It isn't helpful to lump them altogether and condemn them because Barry broke the cardinal rule of never using an at-symbol in a feature syntax. (shame on you Barry!) List which proposed features you like and don't like and why! That's the only way your concerns could really be addressed. > IMHO it's only worth adding a new feature if it > multiplies power by a significant amount; I think it is also worthwhile to recognize "conventions" that could be made clearer with first-class syntax. List comprehensions replace the map/lambda convention (and would IMHO, allow map/filter, at-least, to be deprecated). Range literals replace the for i in range(...) convention and so forth. Those of us who have already internalized the conventions are more likely to see new syntax as an intrusion rather than as a long-term clarification. > The urge to add little tiny things that make microtask X convenient is > what made Perl -- and Sendmail, and DTML, and ... -- what they are > today. Many languages (including some of the ones you mention) also suffer from the syndrome where a first-class feature has been left out so you have to memorize some stupid and non-intuitive "convention" rather than doing things in a straightforward way. I strongly feel that map/lambda and in fact most uses of map fall into this category. The concept is fine but the syntax sucks. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From gmcm at hypernet.com Sat Jul 22 18:00:23 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 22 Jul 2000 12:00:23 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <3979B599.7274105C@prescod.net> Message-ID: <1247840871-20245181@hypernet.com> Paul Prescod wrote: > print is such a hack already. > > What are we trying to get at, really? What are the virtues of > print, what are the virtues of "outputfile.write" and how can we > combine them? The answer to that is contained in the answer to "Why did Guido make print a keyword?". occaisionally-encumbered-by-bouts-of-rationality-ly y'rs -Gordon From paul at prescod.net Sat Jul 22 18:20:52 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 11:20:52 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <20000722092530.A24247@newcnri.cnri.reston.va.us> Message-ID: <3979C9E4.E66FE451@prescod.net> Andrew Kuchling wrote: > > .... > > The urge to add little tiny things that make microtask X convenient is > what made Perl -- and Sendmail, and DTML, and ... -- what they are > today. I also wanted to say that Perl and Sendmail (don't know about DTML) suffer much more from poor design than from feature creep. It isn't just about quantity of features -- quality also matters. The group of people who spent a week arguing about the name "zip" would never allow "eval" to mean "evaluate string" and "catch exceptions" nor make unadorned variable name mean "file handle" nor make :0:c a "command". Common Lisp and Linux are victims of feature creep. Perl and Sendmail just suck. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Sat Jul 22 18:29:48 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 11:29:48 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> Message-ID: <3979CBFC.2EED0234@prescod.net> Gordon McMillan wrote: > > ... > > The answer to that is contained in the answer to "Why did > Guido make print a keyword?". I would guess that he invented print before sys.stdout. :) The main reason I use print (for debugging) is because a) it doesn't require me to coerce variables to strings explicitly. That's why I want autocoercion everywhere. b) it doesn't require me to import sys. That's an argument for making stdout (or sys!) a builtin c) it just seems less technical for newbies than the unpronouncable string of consonants "std". Overall, I think the language would be better off if print were gone. There are more generalized ways to do what it does. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From akuchlin at cnri.reston.va.us Sat Jul 22 18:36:03 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 22 Jul 2000 12:36:03 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <003301bff3e1$bd5dde60$360bfea9@beopen.com>; from guido@python.org on Sat, Jul 22, 2000 at 06:35:38AM -0700 References: <20000722113028.J9897@xs4all.nl> <20000722065546.A18263@thyrsus.com> <003301bff3e1$bd5dde60$360bfea9@beopen.com> Message-ID: <20000722123603.A24658@newcnri.cnri.reston.va.us> On Sat, Jul 22, 2000 at 06:35:38AM -0700, Guido van Rossum wrote: >- Python 1.6 (a CNRI release with PythonLabs' help) will come out with >CNRI's Open Source License in two phases: a beta around August 1st, and a >final release mid-August (of course this schedule is subject to the usual >qualifications). This will release all of the work on Python done at CNRI >since 1.5.2 was released to the public -- a significant step. Glad there's some resolution to this, and apparently a favorable one! (I haven't read the licence yet -- no way to read Word on this Linux laptop.) So, what version does the current CVS tree represent? Is it what will become 1.6, or will some things be removed from the CVS tree in order to make the 1.6 release? From reading the feature lists, it looks like none of the 2.0 features are checked in yet, so I'd wager that the CVS tree is 1.6. I guess what I'm wondering is how 1.6/2.0 development will be organized; finishing 1.6, and postponing augmented assignment/list comprehensions/whatever until 2.0, seems like the best course, since it means we won't have to wrestle with 2 development branches. --amk From thomas at xs4all.net Sat Jul 22 19:34:45 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 19:34:45 +0200 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000722123603.A24658@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jul 22, 2000 at 12:36:03PM -0400 References: <20000722113028.J9897@xs4all.nl> <20000722065546.A18263@thyrsus.com> <003301bff3e1$bd5dde60$360bfea9@beopen.com> <20000722123603.A24658@newcnri.cnri.reston.va.us> Message-ID: <20000722193445.M9897@xs4all.nl> On Sat, Jul 22, 2000 at 12:36:03PM -0400, Andrew Kuchling wrote: > On Sat, Jul 22, 2000 at 06:35:38AM -0700, Guido van Rossum wrote: > >- Python 1.6 (a CNRI release with PythonLabs' help) will come out with > >CNRI's Open Source License in two phases: a beta around August 1st, and a > >final release mid-August (of course this schedule is subject to the usual > >qualifications). This will release all of the work on Python done at CNRI > >since 1.5.2 was released to the public -- a significant step. > So, what version does the current CVS tree represent? Is it what will > become 1.6, or will some things be removed from the CVS tree in order > to make the 1.6 release? From reading the feature lists, it looks > like none of the 2.0 features are checked in yet, so I'd wager that > the CVS tree is 1.6. How I read it, and what I understood from Jeremy's unofficial response last week, is that 1.6 will be everything that was included while Guido (and Barry, Jeremy and Fred) worked at CNRI. That can probably be seen as everything before the CVS tree moved to SourceForge, plus a bit. I'd suspect some of the half-developed features and most of the bugfixes will move into 1.6 as well, but that's just because that makes sense to me -- so it might not be what CNRI wants ;) > I guess what I'm wondering is how 1.6/2.0 development will be > organized; finishing 1.6, and postponing augmented assignment/list > comprehensions/whatever until 2.0, seems like the best course, since > it means we won't have to wrestle with 2 development branches. In the above interpretation, the current CVS tree is 2.0-to-be. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Sat Jul 22 19:41:03 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 13:41:03 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000722123603.A24658@newcnri.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > ... > (I haven't read the licence yet -- no way to read Word on this > Linux laptop.) Plain text below, or see http://hdl.handle.net/1895.22/1011. I like the old Python license better -- but then I'm relatively sane . > So, what version does the current CVS tree represent? Is it what will > become 1.6, or will some things be removed from the CVS tree in order > to make the 1.6 release? From reading the feature lists, it looks > like none of the 2.0 features are checked in yet, so I'd wager that > the CVS tree is 1.6. Guido said "This [1.6] will release all of the work on Python done at CNRI since 1.5.2 was released to the public". The great recent burst of Python-Dev activity in the CVS tree was not done at CNRI, or the bulk of it even by people with any connection present or past to CNRI. > I guess what I'm wondering is how 1.6/2.0 development will be > organized; finishing 1.6, and postponing augmented assignment/list > comprehensions/whatever until 2.0, seems like the best course, since > it means we won't have to wrestle with 2 development branches. I *expect* that only BeOpen PythonLabs, and perhaps CNRI, will wrestle with 1.6, working from a snapshot of the CVS tree as of the day after Guido et alia left. As Guido also said, 1.6 will be "a CNRI release with PythonLabs' help". There's no technical argument behind any of this, so don't even try to start a fruitful discussion . For example, consider all the patches added since then that did not come with CNRI's disclaimer -- mucking with that retroactively would slow everything (both 1.6 and 2.0!) down. And that's not the only artificial hassle: you should know better than most the nature of the issues involved in a CNRI release. Python-Dev should focus on 2.0! At heart, it's specifically Guido who owes CNRI a 1.6 release. No loss to Python-Dev, as by now he's forgotten how to write code anyway . birthing-pains-ly y'rs - tim PYTHON 1.6, Beta 1 CNRI LICENSE AGREEMENT IMPORTANT: PLEASE READ THE FOLLOWING AGREEMENT CAREFULLY. BY CLICKING ON THE "ACCEPT" BUTTON WHERE INDICATED, OR BY COPYING, INSTALLING OR OTHERWISE USING THE SOFTWARE, YOU ARE DEEMED TO HAVE AGREED TO THE TERMS AND CONDITIONS OF THIS AGREEMENT. 1. This LICENSE AGREEMENT is between the Corporation for National Research Initiatives, having an office at 1895 Preston White Drive, Reston, VA 20191 ("CNRI"), and the Individual or Organization ("Licensee") accessing and otherwise using Python 1.6, beta 1 software in source or binary form and its associated documentation, as released at the www.python.org Internet site on July __, 2000 ("Software"). 2. Subject to the terms and conditions of this License Agreement, CNRI hereby grants Licensee a non-exclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use the Software alone or in any derivative version, provided, however, that CNRI's License Agreement and CNRI's notice of copyright, i.e., "Copyright (c) 1995 - 2000 Corporation for National Research Initiatives; All Rights reserved" are both retained in the Software, alone or in any derivative version prepared by Licensee. Alternately, in lieu of CNRI's License Agreement, Licensee may substitute the following text (omitting the quotes): "Python 1.6, beta 1, is made available subject to the terms and conditions in CNRI's License Agreement. This Agreement may be located on the Internet using the following unique, persistent identifier (known as a handle): 1895.22/1011. This Agreement may also be obtained from a proxy server on the Internet using the following URL: http://hdl.handle.net/1895.22/1011". 3. In the event Licensee prepares a derivative work that is based on or incorporates the Software or any part thereof, and wants to make the derivative work available to the public as provided herein, then Licensee hereby agrees to indicate in any such work the nature of the modifications made to CNRI's Software. 4. CNRI is making the Software available to Licensee on an "AS IS" basis. CNRI MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, CNRI MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 5. CNRI SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF THE SOFTWARE FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. SOME STATES DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY SO THE ABOVE DISCLAIMER MAY NOT APPLY TO LICENSEE. 6. This License Agreement will automatically terminate upon a material breach of its terms and conditions. 7. This License Agreement shall be governed by and interpreted in all respects by the law of the State of Virginia, excluding conflict of law provisions. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between CNRI and Licensee. Licensee may not use CNRI trademarks or trade name in a trademark sense to endorse or promote products or services of Licensee, or any third party. 8. By clicking on the "ACCEPT" button where indicated, or by copying, installing or otherwise using the software, Licensee agrees to be bound by the terms and conditions of this License Agreement. ACCEPT From effbot at telia.com Sat Jul 22 20:07:22 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 22 Jul 2000 20:07:22 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> Message-ID: <031101bff407$b05879c0$f2a6b5d4@hagrid> gordon wrote: > The answer to that is contained in the answer to "Why did > Guido make print a keyword?". from the archives: http://www.egroups.com/message/python-list/20 Date: Sat Dec 7, 1991 11:00pm From: Guido van Rossum Subject: Why print is a built-in statement From thomas at xs4all.net Sat Jul 22 20:36:10 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sat, 22 Jul 2000 20:36:10 +0200 Subject: [Python-Dev] SF Patch Manager Message-ID: <20000722203610.N9897@xs4all.nl> I noticed the SF PM was updated to send out comment-summaries and patch status along with the notification something was changed (and it's lovely, yay!) However, at roughly the same time, the PM stopped sending mail to patches at python.org when a new patch was submitted. Was the patches-notification-address changed, or is that feature disabled now ? (Or perhaps the PM update zapped the old address ?) Never-satisfied-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Sat Jul 22 21:45:01 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 14:45:01 -0500 Subject: [Python-Dev] onlinehelp.py Message-ID: <3979F9BD.EE44A896@prescod.net> I've updated onlinehelp.py with some nice new features built on cool code other people wrote. It's checked in. 1. Richard Chamberlain's wrote textdoc.py which builds on Ka-Ping Yee's inspect.py. Together, they allow me to get a lot more introspective information from modules and clsses even though they may not have docstrings. It will even use comments as docstrings. Thanks to Richard who wrote textdoc.py specifically for this purpose. >>> help( foo.__init__ ) | __init__(self, qName, namespaceURI='', localName=None) | no doc string 2. If you ask for help on a string that it doesn't "know about", it will attempt to import it. >>> help( "profile" ) | profile | Class for profiling Python code. | | Modules: | | marshal, os, sys, time | | Classes: | | class HotProfile(Profile): | | The fastest derived profile example. It does not calculate | caller-callee relationships, and does not calculate cumulative ... 3. It will also try to find the string as a sub-attr of a module. This part is really cool: >>> help( "xml.dom.minidom.AttributeList.items" ) (note that xml.dom.minidom is a package, AttributeList is a class, items, is a method) All features are available from the Unix or Windows command line: python onlinehelp.py xml.dom.minidom.AttributeList.items Have fun! The rest of the message is an example transcript. >>> help( "xml" ) Topic: help( ) | xml | Core XML support for Python. | | This package contains three sub-packages: | | dom -- The W3C Document Object Model. This supports DOM Level 1 + | Namespaces. | | parser -- Python wrappers for XML parsers (currently only supports Expat ). | | sax -- The Simple API for XML, developed by XML-Dev, led by David | Megginson and ported to Python by Lars Marius Garshol. This | supports the SAX 2 API. | | Modules: | | dom, sax >>> help( "xml.dom" ) Topic: help( ) | xml.dom | W3C Document Object Model implementation for Python. | | The Python mapping of the Document Object Model is documented in <...>. | | This package contains the following modules: | | minidom -- A simple implementation of the Level 1 DOM with namespace | support added (based on the Level 2 specification). | | Modules: | | minidom, pulldom >>> help( "xml.dom.minidom" ) | Topic: help( ) | xml.dom.minidom | no doc string | | Modules: | | pulldom, string, types | | Classes: | | class Attr(Node): | | no doc string | | Methods: | | __init__(self, qName, namespaceURI='', localName=None, prefix=None) | no doc string | | __setattr__(self, name, value) | no doc string | | class AttributeList: | | the attribute list is a transient interface to the underlying --more-- (enter for more, q to quit) q 0 >>> help( "xml.dom.minidom.AttributeList" ) | Topic: help( xml.dom.minidom.AttributeList ) | class AttributeList: | | the attribute list is a transient interface to the underlying | dictionaries. mutations here will change the underlying element's | dictionary | | Methods: | | __cmp__(self, other) | no doc string | | __delitem__(self, attname_or_tuple) | no doc string | | __getitem__(self, attname_or_tuple) | #FIXME: is it appropriate to return .value? | | __init__(self, attrs, attrsNS) | no doc string | | __len__(self) | no doc string | | __setitem__(self, attname, value) --more-- (enter for more, q to quit) q >>> help( "xml.dom.minidom.AttributeList.items" ) Topic: help( ) | items(self) | no doc string | 1 >>> -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From bwarsaw at beopen.com Sat Jul 22 22:02:21 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sat, 22 Jul 2000 16:02:21 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> Message-ID: <14713.64973.585633.87443@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Why not use outputfile.write directly? Because it's less readable. log.write('post to %s from %s, size=%d\n' % (listname, sender, len(msg))) vs print 'post to', listname, 'from', sender, 'size=', len(msg) With the former, you have to know about the rules for string interpolation, you have to make sure you've got your tuple is the right length, you have to remember to add the trailing newline. PP> print is such a hack already. Maybe, but how often do /you/ use it? It's an incredibly convenient hack. PP> What are we trying to get at, really? What are the virtues of PP> print, what are the virtues of "outputfile.write" and how can PP> we combine them? Some one else outlined these: print autoconverts to string, it adds the trailing newline, it's easy for newbies to learn and it's very readable. I have no problem with the print statement, but it doesn't matter because it's never going away. I know all about the idiom for temporarily binding sys.stdout around print statements. /That/ is a hack because you're making a non-local change to the system, potentially affecting code you're not even aware of. So my extended print suggestion doesn't add any new keywords or operators (forget about `@' specifically -- it's a red herring) and I don't think it makes the statement any less readable, and in fact improves usability for little extra cognitive or code complexity costs. -Barry From bwarsaw at beopen.com Sat Jul 22 22:07:08 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sat, 22 Jul 2000 16:07:08 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> <3979CBFC.2EED0234@prescod.net> Message-ID: <14713.65260.762631.233327@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Overall, I think the language would be better off if print PP> were gone. There are more generalized ways to do what it PP> does. Really? We can start by fixing the nearly 5000 occurances of it in the Python distribution or the 230 occurances in Mailman. How often does print show up in your own code? print is incredibly convenient; I'd hate to write CGI scripts without it. Why not make it just a little more so? -Barry From paul at prescod.net Sat Jul 22 22:13:51 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 15:13:51 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> Message-ID: <397A007F.CF8DEBE2@prescod.net> "Barry A. Warsaw" wrote: > > ... > Because it's less readable. > > log.write('post to %s from %s, size=%d\n' % (listname, sender, len(msg))) > > vs > > print 'post to', listname, 'from', sender, 'size=', len(msg) Okay, how about log.writeln("Post to ", listname, " from ", sender, " size=", len( msg )) or (with auto string-coercion): log.writeln("Post to "+listname+" from "+sender+" size="+len( msg )) > With the former, you have to know about the rules for string > interpolation, you have to make sure you've got your tuple is the > right length, you have to remember to add the trailing newline. Nevertheless, every Python programmer needs to learn the ".write" way in order to do reasonable text processing. So print's idiosyncracies are just one more thing to learn. In the long run, print hurts newbies more than it helps them because it confuses them into thinking its useful and then frustrates them when they learn its a hack that always appends trailing whitespace. > So my extended print suggestion doesn't add any new keywords or > operators (forget about `@' specifically -- it's a red herring) and I > don't think it makes the statement any less readable, and in fact > improves usability for little extra cognitive or code complexity > costs. I don't see what proposal you are promoting that doesn't have "@" in it? -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Sat Jul 22 22:25:34 2000 From: paul at prescod.net (Paul Prescod) Date: Sat, 22 Jul 2000 15:25:34 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> <3979CBFC.2EED0234@prescod.net> <14713.65260.762631.233327@anthem.concentric.net> Message-ID: <397A033E.40CF8DA1@prescod.net> "Barry A. Warsaw" wrote: > > ... > Really? We can start by fixing the nearly 5000 occurances of it in > the Python distribution or the 230 occurances in Mailman. How often > does print show up in your own code? Print almost never shows up in my production code because I always want to allow the option of redirecting the output and assigning sys.stdout is a hack for all of the reasons you've pointed out. I do use print constantly for debug output but the whole point there is that I don't have to set up a file object. I wouldn't use it even there if Python auto-coerced strings and moved stdout into __builtins__. Or else stdout.println could auto-coerce a list of objects. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From tim_one at email.msn.com Sun Jul 23 00:06:29 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 22 Jul 2000 18:06:29 -0400 Subject: [Python-Dev] SF Patch Manager In-Reply-To: <20000722203610.N9897@xs4all.nl> Message-ID: [Thomas Wouters] > I noticed the SF PM was updated to send out comment-summaries and > patch status along with the notification something was changed > (and it's lovely, yay!) However, at roughly the same time, the PM > stopped sending mail to patches at python.org when a new patch was > submitted. That's not it -- the last email in the patches archive from SourceForge was at Thu, 20 Jul 2000 15:40:33 -0700: http://www.python.org/pipermail/patches/2000-July/001221.html and is one of the new-style, more-informative msgs. > Was the patches-notification-address changed, No. > or is that feature disabled now ? No. > (Or perhaps the PM update zapped the old address ?) No. Good guesses, but everything we can affect on the SF end looks good. Just a few *hours* ago, I enabled another new SF feature: email should be sent to patches at python.org for *every* change to patch status now. Doesn't appear to be happening, though. From mhammond at skippinet.com.au Sun Jul 23 00:36:57 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 23 Jul 2000 08:36:57 +1000 Subject: [Python-Dev] Feature bloat in Python (was some PEP thing!) In-Reply-To: <3979BFB9.419EC323@prescod.net> Message-ID: [Paul] > I think that this class vague complaints are a little unfair. That is why we have these lists - so people _can_ disagree. > We've had > a wide range of proposals from extra functions to minor new syntax to > new magical methods to radically new control flow features. Yep - and I still lump them _all_ in the same category. I don't believe I have seen a _single_ PEP I would support (except maybe the "batteries included" one, as it doesn't change the language, just the distribution.) Is that specific enough? > It isn't helpful to lump them altogether and condemn them because Barry > broke the cardinal rule of never using an at-symbol in a feature syntax. Why do you believe I did? Where on earth did you get the impression this has anything to do with the "@" symbol? You seem to be the only one constantly raising this. Even when Barry says it is a red-herring, you wont let it die. I apologize to Barry for picking on his mail; this was not a reflection on the proposal as such, it was just the unfortunate straw that broke the serpent's back. I have changed the subject line to reflect this. > List which proposed features you like and don't > like and why! That's the only way your concerns could really be > addressed. Please re-read my original mail. I said "cool-but-not-really-necessary" features; other people have followed up and clearly understood that I was talking about code-bloat, and not that the features themselves necessarily suck. Each feature, in isolation, could possibly be bashed into something I support. When these are all combined I start having serious reservations. An example of the sum of the parts being significantly greater than the value added to the whole. > I think it is also worthwhile to recognize "conventions" that could be > made clearer with first-class syntax. List comprehensions replace the > map/lambda convention (and would IMHO, allow map/filter, at-least, to be > deprecated). Range literals replace the for i in range(...) convention > and so forth. Hrm - but in a later mail, you state: > Common Lisp and Linux are victims of feature creep. Perl and Sendmail > just suck. If we ignore the obvious bigotry in your statement (Perl and Sendmail "just suck" ?? Tell that to the orders of magnitude more people who use them than Python!) you have just addressed my concerns fairly succinctly. Maybe if you had made them in the same email you could have seen the conundrum? > Those of us who have already internalized the conventions are more > likely to see new syntax as an intrusion rather than as a long-term > clarification. Agreed - hence this debate is useful. However, I will state that the reason I skipped Perl and went for Python all those years ago was that the intent of Python code, even before I knew the language, was clear. This is a key feature of Python, and a selling point I always in my own advocacy efforts. Most of these proposals are watering that down, IMO. But I happily admit that neither you or I are able to make meaningful statements about that - we are too close it. > things in a straightforward way. I strongly feel that map/lambda and in > fact most uses of map fall into this category. The concept is fine but > the syntax sucks. Agreed. So when someone presents a solution that is obvious to the readers of this list, we will be well on our way. This hasn't happened yet. If you can't quickly and quietly win this friendly audience over, IMO the proposal has failed. If any proposal causes even a small thread on this forum that boils down to "but its not clear to me what this should do", then I would have thought it self-evident that the proposal sucks. Convincing us that it _should_ be obvious if only we were all a little brighter and more willing to accept change for changes sake doesn't help anyone, least of all the person making these statements. (Let me be clear that this last statement is not directed personally at Paul!) Standing-by-everything-I-said-ly, Mark. From thomas at xs4all.net Sun Jul 23 02:24:53 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 02:24:53 +0200 Subject: [Python-Dev] ANSIfication. Message-ID: <20000723022452.Q9897@xs4all.nl> I'm done checking in the ansification patches. It doesn't fix everything, for a couple of reasons: - Some function-declarations and function-pointers store functions I don't have access to, like the 'sv' and 'gl' modules, and the 'gl' module seems half auto-generated. - the 'dl' module does some nasty things which I don't feel deserve a prototype. (loading a function using dl_sym, and calling it with 10 char* arguments.) - Some prototypes aren't standardized. This is only really a problem with getopt(), called from Modules/main.c. On some systems, it's 'char **', on some it's 'const char **', and those two pointers are not compatible. (Or did they fix that in C9X ? Somehow I doubt it.) - Readline is a mess. I can start adding prototypes, but the standard readline include files don't do that either, and I'm not terribly sure on some of the prototypes, having never worked with readline myself. The infopages try to be as vague as possible on what kind of function the second argument to 'rl_bind' is, for instance ;) I've fixed the passing of 'PyErr_CheckSignals(void)' to Py_AddPendingCall (which wants a function that takes a void* argument instead) by passing a static wrapper function instead, in both instances (Modules/signalmodule.c and Parser/intrcheck.c.) I'm also tempted to suggest to remove most of the 'extern's, and possibly add them to pyport.h if they are still an issue. Most of the current externs for library functions seem to me like old cruft, though I have no way of telling how old they are. The getopt() prototype would be solved that way, in any case, by removing it and relying on the appropriate include file defining it. Here's an example of what I think is old cruft: posixmodule.c: /* XXX These are for SunOS4.1.3 but shouldn't hurt elsewhere */ extern int rename(const char *, const char *); extern int pclose(FILE *); extern int lstat(const char *, struct stat *); extern int symlink(const char *, const char *); extern int fsync(int fd); There are a couple of more things that might be candidate for cleanup or removal now, by the way. The 'ANY' #define in Include/mymalloc.h, and the type(s) derived from it, for instance. I'm not sure how 'standard' the void* type is, but I thought it was ANSI mandated ? If anyone wants to look at one or more of the above problems, here's how you can find them: find . -name '*.[ch]' | xargs fgrep extern | fgrep '()' find . -name '*.[ch]' | xargs fgrep ')()' Night-night-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fdrake at beopen.com Sun Jul 23 04:42:29 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 22 Jul 2000 22:42:29 -0400 (EDT) Subject: [Python-Dev] ANSIfication ? In-Reply-To: <3975B093.C2F125BD@schneider-kamp.de> References: <20000719132554.B9897@xs4all.nl> <3975B093.C2F125BD@schneider-kamp.de> Message-ID: <14714.23445.744869.80794@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > I don't think so. After ANSIfying the whole Module/ directory I was fed > up. > I'd guess the same applies to Fred who slaved away in Objects/ ... I was also tired & had more important things to do. ;) If this hasn't already been done (I'm still several hundreds of messages behind), then feel free to barge ahead! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nhodgson at bigpond.net.au Sun Jul 23 05:26:43 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Sun, 23 Jul 2000 13:26:43 +1000 Subject: [Python-Dev] Python Consortium Meeting News References: Message-ID: <01e601bff455$d31d3f10$8119fea9@neil> I don't like this new license as it is much more complex than the old license. Its about 4 times longer and appears to me to attempt to claim a licensing relationship with third parties who use software written in Python. Is Python going to use this license forever, or is it just for 1.6? Neil From moshez at math.huji.ac.il Sun Jul 23 07:09:15 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 23 Jul 2000 08:09:15 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397A007F.CF8DEBE2@prescod.net> Message-ID: On Sat, 22 Jul 2000, Paul Prescod wrote: > "Barry A. Warsaw" wrote: > > > > ... > > Because it's less readable. > > > > log.write('post to %s from %s, size=%d\n' % (listname, sender, len(msg))) > > > > vs > > > > print 'post to', listname, 'from', sender, 'size=', len(msg) > > Okay, how about > > log.writeln("Post to ", listname, " from ", sender, " size=", len( msg > )) Better yet, have writeln auto put spaces, and you have log.writeln("Post to", listname, "from", sender, "size=%s" % len(msg)) But I'm -0 on that, preferring a new sys function, called writeln writeln("......") writeln(file=logfile, "fffffff", "ffff") and of course writeln(nl=0, "ffffff") to simulate print "ffffff", That would be extremely readable, require no new syntax and no additional builtins. Reference implementation: def writeln(*args, **kw): import sys file = sys.stdout end = '\n' if kw.has_key("file"): file = kw['file'] del kw['file'] if kw.has_key("nl"): if not kw['nl']: end = ' ' del kw['nl'] file.write(" ".join(map(str, args))+end) -- Moshe Zadka There is no GOD but Python, and HTTP is its prophet. http://advogato.org/person/moshez From tim_one at email.msn.com Sun Jul 23 07:25:14 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 01:25:14 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <01e601bff455$d31d3f10$8119fea9@neil> Message-ID: [Neil Hodgson] > I don't like this new license as it is much more complex than > the old license. Then I'd say you're normal! The principals on "our side" of the negotiation view this license as something of a triumph, simply because it's so much less obnoxious than the proposals that preceded it. Not speaking for my employer, I think we lost. OTOH, python.org will no longer be held hostage. > Its about 4 times longer and appears to me to attempt to claim a > licensing relationship with third parties who use software written in > Python. > > Is Python going to use this license forever, or is it just for 1.6? Who knows? It's all hifalutin legalese. Note that the text Guido sent out is not the same as the text it references at http://hdl.handle.net/1895.22/1011 either. I believe it's the latter that's out of date, and the text Guido sent is friendlier to users. Still, one way to read the Guido version is that 2.0 and everything after is a "derivative work", so must (paragraph 2) include the 1.6 CNRI license, and (paragraph 3) "indicate in any such work the nature of the modifications made to CNRI?s Software". OTOH, I can see at least two other ways to read it! Perhaps a consortium member who already paid a lawyer would care to pass on their confusion . looks-infectious-to-me-ly y'rs - tim From paul at prescod.net Sun Jul 23 08:13:50 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 01:13:50 -0500 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: Message-ID: <397A8D1E.CB6F140D@prescod.net> Mark Hammond wrote: > > [Paul] > > I think that this class vague complaints are a little unfair. > > That is why we have these lists - so people _can_ disagree. I didn't mean to say otherwise. > > > It isn't helpful to lump them altogether and condemn them because Barry > > broke the cardinal rule of never using an at-symbol in a feature syntax. > > Why do you believe I did? Where on earth did you get the impression this > has anything to do with the "@" symbol? It was a joke. Obviously all of your concern does not stem from one character. On the other hand, I don't think that it is a coincidence that you jumped on the one recent proposal with a syntax that adds a character to the Python repertoire. It's ugly so its an easy target. Or to put it another way, it was *likely* to be the straw that broke the camel's back because it could change the look of Python most radically. > You seem to be the only one > constantly raising this. Even when Barry says it is a red-herring, you > wont let it die. I don't see how a fundamental element of the proposed syntax can be a red-herring! You might as well claim that the new matrix operators are a red herring in the discussion of new matrix operators. If Barry has proposed another syntax I haven't seen it. > Please re-read my original mail. I said "cool-but-not-really-necessary" > features; other people have followed up and clearly understood that I was > talking about code-bloat, and not that the features themselves necessarily > suck. Each feature, in isolation, could possibly be bashed into something > I support. When these are all combined I start having serious > reservations. An example of the sum of the parts being significantly > greater than the value added to the whole. So your opinion is that no new syntax should be added to Python unless it offers massive new functionality. But any syntax that offers massive new functionality (e.g. static type declarations, multimethods, meta-object-protocol) is going to be considered too severe of a change and/or un-Pythonic. > > I think it is also worthwhile to recognize "conventions" that could be > > made clearer with first-class syntax. List comprehensions replace the > > map/lambda convention (and would IMHO, allow map/filter, at-least, to be > > deprecated). Range literals replace the for i in range(...) convention > > and so forth. > > Hrm - but in a later mail, you state: > > Common Lisp and Linux are victims of feature creep. Perl and Sendmail > > just suck. > > If we ignore the obvious bigotry in your statement (Perl and Sendmail "just > suck" ?? Are we now in a society where it is inappropriate to criticize technologies? > Tell that to the orders of magnitude more people who use them > than Python!) I do and have. > you have just addressed my concerns fairly succinctly. Maybe > if you had made them in the same email you could have seen the conundrum? Not at all. There are lots of cool technologies that have grown far beyond their original incarnations: * Unix/Linux * Apache * Zope * EMACS * Common Lisp The important thing isn't the size of the system but the consistency and quality of its design. I was not attracted to Python because it was small but because it was self-consistent. The requirement that every new feature be consistent with the others *makes* it small. TCL is pretty small too, but I have no interest in using it. Scheme is extremely small and I had to give up on it despite my initial attraction. > Agreed - hence this debate is useful. However, I will state that the > reason I skipped Perl and went for Python all those years ago was that the > intent of Python code, even before I knew the language, was clear. This is > a key feature of Python, and a selling point I always in my own advocacy > efforts. Agreed. And do you see code with heavy map/filter/reduce usage as clear? How about code with long getattr functions, doing a dozen tricks at once? My attribute access function proposal (to take one at random :) ) could significantly clarify the code generated by makepy, which I often use as "template code" for COM programming. You talk about clarity and minimalism as if they were the same thing. It is *exactly my point* that sometimes you *trade* clarity for minimalism. On the one end of the spectrum is Common Lisp and on the other is the lambda calculus. I agree that we want to stay close to the middle. > Most of these proposals are watering that down, IMO. But I happily admit > that neither you or I are able to make meaningful statements about that - > we are too close it. If we can't make meaningful statements about usability, Python is doomed. > Agreed. So when someone presents a solution that is obvious to the readers > of this list, we will be well on our way. This hasn't happened yet. If > you can't quickly and quietly win this friendly audience over, IMO the > proposal has failed. If any proposal causes even a small thread on this > forum that boils down to "but its not clear to me what this should do", > then I would have thought it self-evident that the proposal sucks. There is no construct in the Python programming language that is self-evident *in its entirety* including all corner cases. There are a few which you can "feel around" based on knowledge from other programming languages but even those have many Pythonic twists that you can only learn by reading the documentation. Even the "for" statement would have taken a long, complicated, intricate debate on python-dev to work out the current semantics, including IndexError, else:, and mutability. The try statement is even more complex. I can't even believe that something like a=[2:30] is comparable to the various complexities *already in the language*. If Python were half as big as it is today (e.g. no classes, no exception handling), we would be having a big debate about whether to add the missing features. In other words, you have raised the bar on adding features to Python so high that it can never be met. Nothing non-trivial is ever intuitively obvious, including every edge condition and interaction. It just doesn't happen. > Convincing us that it _should_ be obvious if only we were all a little > brighter and more willing to accept change for changes sake doesn't help > anyone, least of all the person making these statements. I don't know what you are talking about. Which of these proposals require you to be a little brighter? a=[1:50] # Range literals a+=[51:60] # Augmented assignment j=[for k in a: if k%2: k*2] # list comprehensions k=zip( [1,2,3,4], [5,6,7,8] ) # parallel iteration d = dict( k ) # new builtin function Which proposals require too much intelligence? Which ones would you not be able to "sight read" coming from Java or Perl? And how do they really compare (for sight-reading) to the contemporary equivalents: a=range(1,50) a=a+range(51,60) j=[] for k in a: if k%2: j.append( k*2 ) array1=[1,2,3,4] array2=[5,6,7,8] k=[] k=map(None, array1, array2 ) d={} for name,val in k: d[name]=val Is this latter code really clearer and easier to read -- even for a newbie -- than the former? Okay, Pep 207, 208, 209 and 213 are likely to be more complex. That's because they are cleaning up parts of the language that are already relatively complex. They aren't adding significant new functionality nor syntax. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From peter at schneider-kamp.de Sun Jul 23 10:21:33 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 23 Jul 2000 08:21:33 +0000 Subject: [Python-Dev] extended print statement, uPre-PEP References: Message-ID: <397AAB0D.1803F60C@schneider-kamp.de> First I want to say, that I use the print statement mainly for debugging and for "print func.__doc__" in the shell, but I would be very unhappy to see it go away. quasi patch for readline: Moshe Zadka wrote: > > Reference implementation: > > def writeln(*args, **kw): > import sys > file = sys.stdout > end = '\n' + joinstring = ' ' > if kw.has_key("file"): > file = kw['file'] > del kw['file'] + if kw.has_key("join"): + joinstring = kw['join'] + del kw['join'] > if kw.has_key("nl"): > if not kw['nl']: ! end = joinstring > del kw['nl'] ! file.write(joinstring.join(map(str, args))+end) Or this one : def writeln(*args, **kw): import sys file = sys.stdout end = '' if kw.has_key("file"): sys.stdout = kw['file'] del kw['file'] if kw.has_key("nl"): if not kw['nl']: end = ',' del kw['nl'] exec("print "+", ".join(map(repr,args))+end) having-slept-for-three-hours-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From moshez at math.huji.ac.il Sun Jul 23 08:29:21 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 23 Jul 2000 09:29:21 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397AAB0D.1803F60C@schneider-kamp.de> Message-ID: On Sun, 23 Jul 2000, Peter Schneider-Kamp wrote: > First I want to say, that I use the print statement mainly > for debugging and for "print func.__doc__" in the shell, > but I would be very unhappy to see it go away. Nobody is suggesting it it went away (though writeln(func.__doc__) is not much longer) -- just that we don't add more craft for that... -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From nhodgson at bigpond.net.au Sun Jul 23 08:29:49 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Sun, 23 Jul 2000 16:29:49 +1000 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: <397A8D1E.CB6F140D@prescod.net> Message-ID: <00c601bff46f$67f6fbd0$8119fea9@neil> > I don't know what you are talking about. Which of these proposals > require you to be a little brighter? > ... *** This one. > j=[for k in a: if k%2: k*2] # list comprehensions > ... > Which proposals require too much intelligence? Which ones would you not > be able to "sight read" coming from Java or Perl? And how do they really > compare (for sight-reading) to the contemporary equivalents: Maybe I'm trapped in my past here but my "sight reading" of list comprehensions brings back memories of BCPL which would have propagated the result of the loop (IIRC, the last expression evaluated within the loop) as the result of the expression. Its hardly obvious what this does based on experience with most current languages including C++, Java or VB. The counter-example given for this in current Python is much more readable to users of these languages. OTOH list comprehensions would be a more significant capability upgrade than the other changes to me and is thus worthy of a larger syntax change. Neil From paul at prescod.net Sun Jul 23 08:34:36 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 01:34:36 -0500 Subject: [Python-Dev] Consistency questions References: <3976A175.12D4DB53@prescod.net> <20000720103546.N9897@xs4all.nl> <14711.2370.880455.337906@beluga.mojam.com> <20000720172108.S9897@xs4all.nl> <14711.8162.800169.884936@beluga.mojam.com> <39773DBB.9480F7BF@prescod.net> <20000721081808.A9897@xs4all.nl> Message-ID: <397A91FC.AEB8DA7B@prescod.net> Thomas Wouters wrote: > >.... > Hm, "methods and attributes are different things, right ?" I catch > my newbie colleagues thinking that all the time ;P How about if we added a function that would help them to see the error of their ways? We could call it "attrs". -- Paul Prescod - Not encumbered by corporate consensus "Hardly anything more unwelcome can befall a scientific writer than having the foundations of his edifice shaken after the work is finished. I have been placed in this position by a letter from Mr. Bertrand Russell..." - Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox) From paul at prescod.net Sun Jul 23 08:36:32 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 01:36:32 -0500 Subject: [Python-Dev] [Fwd: Re: merge (Re: zip or marry etc)] Message-ID: <397A9270.3340DE88@prescod.net> This is the first name I've seen that is clearly self-descriptive: maketuples. It is a little bit wordy but it is also pretty darn clear about what is going on! -------- Original Message -------- Subject: Re: merge (Re: zip or marry etc) Date: 20 Jul 2000 11:53:49 -0400 From: Dan Schmidt Organization: Harmonix Musick Systems To: python-list at python.org Newsgroups: comp.lang.python References: <20000718100813.C21354 at newcnri.cnri.reston.va.us> <39763FF4.2CA5BF75 at schneider-kamp.de> <8l59pa$6ff$1 at slb1.atl.mindspring.net> <8l6vc5$c07$1 at slb6.atl.mindspring.net> <+MLEAgA0Lxd5EwDd at jessikat.fsnet.co.uk> ... zip is fine with me, but if we were to choose a brand-new name, I like the make_pairs that someone proposed, or, since I guess it can work on more than two lists, make_tuples. Or how about tuple_up? :) -- Dan Schmidt | http://www.dfan.org Honest Bob CD now available! | http://www.dfan.org/honestbob/cd.html -- http://www.python.org/mailman/listinfo/python-list From bwarsaw at beopen.com Sun Jul 23 09:07:18 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 03:07:18 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> Message-ID: <14714.39334.615638.738713@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> I don't see what proposal you are promoting that doesn't have PP> "@" in it? Forget about @, let's use >> instead. What I mean by "red herring" is that it doesn't much matter what the token after print is -- we can argue about that all we want later. As long as the token can't appear in that position with any other meaningful semantics, you're fine. I've got a very rough set of patches that implement this, and here's an example that really works. I'll flesh the patches out and post them to SF. -Barry -------------------- snip snip --------------------print.py import sys from StringIO import StringIO listname = 'mylist' sender = 'barry at beopen.com' msg = 'x' * 1000 print 'post to', listname, 'from', sender, 'size=', len(msg) print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg) log = StringIO() print >> log, 'post to', listname, 'from', sender, 'size=', len(msg) print log.getvalue(), -------------------- snip snip -------------------- % ./python /tmp/print.py post to mylist from barry at beopen.com size= 1000 post to mylist from barry at beopen.com size= 1000 post to mylist from barry at beopen.com size= 1000 From mhammond at skippinet.com.au Sun Jul 23 09:08:56 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 23 Jul 2000 17:08:56 +1000 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <397A8D1E.CB6F140D@prescod.net> Message-ID: > > > It isn't helpful to lump them altogether and condemn them > > > because Barry broke the cardinal rule of never using an > > > at-symbol in a feature syntax. > > Why do you believe I did? Where on earth did you get the > > impression this has anything to do with the "@" symbol? > It was a joke. What exactly was the joke? You sound quite serious to me! > Obviously all of your concern does not stem from one > character. On the other hand, I don't think that it is a coincidence > that you jumped on the Sorry, but I don't think you are in a position to make statements about my thought processes. > It's ugly so its an easy target. You should notice that I have not made a single specific comment about this proposal. You have no clue as to my feelings on Barry's proposal. > I don't see how a fundamental element of the proposed syntax can be a > red-herring! I thought your comments on this were a joke? > So your opinion is that no new syntax should be added to Python unless > it offers massive new functionality. But any syntax that offers massive > new functionality (e.g. static type declarations, multimethods, > meta-object-protocol) is going to be considered too severe of a change > and/or un-Pythonic. Where have I made comment on "too severe" or "too un-Pythonic"? I do agree that changes to Python should offer significant benefits, as another contributor to this thread has already stated. > > If we ignore the obvious bigotry in your statement (Perl and > > Sendmail "just suck" ?? > Are we now in a society where it is inappropriate to criticize > technologies? Are we now in a society where "just suck" is a learned and reasonable critisism of a technology? Or one where bigotry, in any form, is acceptable? > > Tell that to the orders of magnitude more people who use them > > than Python!) > > I do and have. *sigh* Telling people their preferred tools "just suck" is unlikely to be effective advocacy. > Agreed. And do you see code with heavy map/filter/reduce usage as clear? Nope. Proposals to clean this up are clearly good. I have avoided making specific comments about specific proposals in these diatribes. However, the existing proposals to "solve" this, IMO, don't. > How about code with long getattr functions, doing a dozen tricks at > once? I have never seen a getattr function doing many tricks. Many attributes for sure, but almost always using the same trick. > My attribute access function proposal (to take one at random :) ) > could significantly clarify the code generated by makepy, which I often > use as "template code" for COM programming. I dont think this is a good example. makepy generated code is not meant to be readable. The fact it often is (and that I often recommend it be read) is a necessity caused by lack of reasonable documentation or alternative tools. I agree your proposal could make makepy generated code more readable; but as the point of makepy generated code is functional, I would probably keep it just as it is! makepy is, IMO, a perfect example of where getattr would still be preferred over your proposal. This is not to say I dont see merit in your proposal; I just don't think makepy is a good example. > > Most of these proposals are watering that down, IMO. But I > > happily admit that neither you or I are able to make > > meaningful statements about that - we are too close it. > If we can't make meaningful statements about usability, Python is > doomed. Im confused. You asserted that we are probably too familiar with Python to make meaningful statements about how newbies will find these syntax changes. I simply agreed, but pointed out that you are also in no position to make the counter claim. Now you are asserting we can make such statements? > I can't even believe that something like > > a=[2:30] > > is comparable to the various complexities *already in the language*. If > Python were half as big as it is today (e.g. no classes, no exception > handling), we would be having a big debate about whether to add the > missing features. I respectfully disagree. To me: a = range(2,30) is just as good, and much clearer. To compare this syntactic sugar to the language having no classes or exceptions is absurd. > I don't know what you are talking about. Which of these proposals > require you to be a little brighter? Neil has already answered. But I must concede - I am not bright enough for many of these. > a=[1:50] # Range literals I admit I _could_ guess at this. > a+=[51:60] # Augmented assignment IMO, a poor example. a+=1 _is_ obvious. a+=[51:60] is, IMO, clearly not. a += range(51,60) is better. > j=[for k in a: if k%2: k*2] # list comprehensions Yep - I admit it - I'm not bright enough. > k=zip( [1,2,3,4], [5,6,7,8] ) # parallel iteration Ditto - I have "winzip", and even zip.exe. I fully understand that the only zips I have encountered on the computer relate to compression. So presumably this is something related to list compression? > d = dict( k ) # new builtin function NFI about this? Is this a copy operation? What is the type of "k" in this example? > Which proposals require too much intelligence? Fortunately, I'm not insecure about my intelligence. [OTOH, I'm also not delusional about it ;-] I suggest most of them. > And how do they really compare (for sight-reading) to > the contemporary equivalents: > a=range(1,50) Worse. > a=a+range(51,60) Worse. > j=[] > for k in a: > if k%2: > j.append( k*2 ) Worse. > > array1=[1,2,3,4] > array2=[5,6,7,8] > k=[] > k=map(None, array1, array2 ) Better. Replace map with a loop, and it goes back to worse. > d={} > for name,val in k: > d[name]=val Worse. > Is this latter code really clearer and easier to read -- even for a > newbie -- than the former? IMO, yes. But as you earlier asserted, to which I agreed, but you then recanted, I dont believe either of us can speak for newbies. Anyway, I believe we have both made our points, and in the interests of preventing this from becoming a real flame-fest, I will refrain from further comments in this vein, and simply place my faith in the benevolent dictator. Thanking-God-Python-isnt-being-designed-by-this-committee-ly Mark. From peter at schneider-kamp.de Sun Jul 23 11:13:19 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 23 Jul 2000 09:13:19 +0000 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> Message-ID: <397AB72F.FC51AEDE@schneider-kamp.de> "Barry A. Warsaw" wrote: > > print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg) I saw `cout' being shifted "Hello world" times to the left and stopped right there. -- Steve Gonedes BTW: I think "print >> sys.stdout" is counter-intuitive, as it looks like something is flowing from print to sys.stdout. This would confuse C++-aware folk heavily. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From peter at schneider-kamp.de Sun Jul 23 11:31:39 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Sun, 23 Jul 2000 09:31:39 +0000 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: Message-ID: <397ABB7B.7867860@schneider-kamp.de> Mark Hammond wrote: > > Anyway, I believe we have both made our points, and in the interests of > preventing this from becoming a real flame-fest, I will refrain from > further comments in this vein, and simply place my faith in the benevolent > dictator. I don't want put oil in the fire. That said, I wouldn't place to much faith in the BDFL rejecting those features. Not after this statement: "- Python 2.0 (a BeOpen PythonLabs release) will start with a beta release 1-2 weeks after 1.6 final is released; we're striving for a short beta cycle. New language features will include list comprehensions, range literals, the zip() function, and augmented assignment." of-course-maybe-I-should-read-"will"-as-"could"-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From m.favas at per.dem.csiro.au Sun Jul 23 09:34:00 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Sun, 23 Jul 2000 15:34:00 +0800 Subject: [Python-Dev] _cursesmodule linking, and portability Message-ID: <397A9FE8.DC1EBB6@per.dem.csiro.au> Earlier today I uploaded a patch to SF for _cursesmodule.c so that it would link on Tru64 Unix (Version 4.0F). The problem was that the function has_key() is not present on this platform (nor, apparently, on SGI or Sun). Moshe queried whether this patch was required to link against ncurses on Tru64. ncurses does not exist on Tru64. Access to the functionality of V 4 of the X/Open curses API spec is enabled by the macro _XOPEN_SOURCE_EXTENDED - neither the header file nor the (only) curses library have any reference to has_key(). I am not a curses person (except when... ), so I do not know whether has_key() is part of the _standard_ (new?) curses, but I am concerned that the _cursesmodule.c code exposes this interface for all but SGI, Sun and Tru64 systems. What happens when Python code is written that uses this function? It will fail on at least these three platforms... Should the has_key() function be removed, or a wrapper written for those systems that don't support this function? -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From moshez at math.huji.ac.il Sun Jul 23 09:40:20 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 23 Jul 2000 10:40:20 +0300 (IDT) Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: <397A9FE8.DC1EBB6@per.dem.csiro.au> Message-ID: On Sun, 23 Jul 2000, Mark Favas wrote: > Earlier today I uploaded a patch to SF for _cursesmodule.c so that it > would link on Tru64 Unix (Version 4.0F). The problem was that the > function has_key() is not present on this platform (nor, apparently, on > SGI or Sun). Moshe queried whether this patch was required to link > against ncurses on Tru64. ncurses does not exist on Tru64. I see. I think ESR (who is the new curses maintainer) decided to support only ncurses. You might convince him a) to support Tru64 curses too b) to tell you how to compile ncurses for the Tru64 At any rate, thank you for the quick response. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From effbot at telia.com Sun Jul 23 10:15:52 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 10:15:52 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> Message-ID: <005901bff47e$3ffa7b20$f2a6b5d4@hagrid> paul wrote: > Nevertheless, every Python programmer needs to learn the ".write" way in > order to do reasonable text processing. So print's idiosyncracies are > just one more thing to learn. ...and since people need to learn how to write classes to write larger programs, we can disallow statements and functions on the module level... ...and since people need to learn how to balance parentheses to write larger data structures, we might as well reintroduce braces... ...and since people need to learn C++ and Java anyway, to solve performance problems or interface with low-level stuff, we might as well give up the whole project. >>> usability_guidelines.index("they have to learn it anyway") Traceback (most recent call last): ValueError: list.index(x): x not in list (fwiw, this is related to why adding TabError and IndentationError was a rather lousy idea...) From effbot at telia.com Sun Jul 23 10:12:38 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 10:12:38 +0200 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: Message-ID: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> mark wrote: > If you can't quickly and quietly win this friendly audience over, IMO the > proposal has failed. If any proposal causes even a small thread on this > forum that boils down to "but its not clear to me what this should do", > then I would have thought it self-evident that the proposal sucks. > Convincing us that it _should_ be obvious if only we were all a little > brighter and more willing to accept change for changes sake doesn't > help anyone, least of all the person making these statements from the new Tcl Code Team rules: "A project can also be proposed by someone outside the Tcl Core Team, but it can't be approved without an advocate on the Tcl Core Team who will take personal responsibility for it. A project must have support from at least 2 members of the Tcl Core Team (including the proposer); if anyone in the Tcl Core Team objects to the proposal, then there must be at least 4 members in favor (including the proposer). If there are two or more "no" votes then the proposal is rejected, regardless of the number of people in favor. "The idea here is that the Tcl Core Team can only work effectively if it is highly collegial; any project that generates significant contro- versy should not go into the Tcl core." and for the record, I'm fully prepared to vote "no" on list comprehensions, augumented assignments, range literals, and every trace of a new operator that changes how python code is tokenized and parsed. not that it will change anything: > Thanking-God-Python-isnt-being-designed-by-this-committee-ly ...with two major releases with only a few weeks in between, I'm afraid we'll see the usual "do we really need this?" rule being replaced with "what can we add to make sure people know there's really a difference?". obviously, things with fancy names and existing patches are on the top of that list :-( From m.favas at per.dem.csiro.au Sun Jul 23 10:10:35 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Sun, 23 Jul 2000 16:10:35 +0800 Subject: [Python-Dev] _cursesmodule linking, and portability] Message-ID: <397AA87B.7B00DEF@per.dem.csiro.au> Should have included python-dev on this one - must be a Sunday afternoon... It's still the case that, under the current implementation, Sun and SGI platforms do not expose the has_key() function. My patch just adds Tru64 (nee Digital Unix, nee OSF/1) to that group... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 -------------- next part -------------- An embedded message was scrubbed... From: Mark Favas Subject: Re: [Python-Dev] _cursesmodule linking, and portability Date: Sun, 23 Jul 2000 15:57:42 +0800 Size: 1861 URL: From effbot at telia.com Sun Jul 23 10:26:24 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 10:26:24 +0200 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: <397A8D1E.CB6F140D@prescod.net> <00c601bff46f$67f6fbd0$8119fea9@neil> Message-ID: <007601bff47f$b1191c20$f2a6b5d4@hagrid> neil wrote: > > > j=[for k in a: if k%2: k*2] # list comprehensions > > Maybe I'm trapped in my past here but my "sight reading" of list > comprehensions brings back memories of BCPL which would have propagated the > result of the loop (IIRC, the last expression evaluated within the loop) as > the result of the expression. Its hardly obvious what this does based on > experience with most current languages including C++, Java or VB. and my "sight reading" of this is that j is an anonymous function with a rather meaningless for-loop in it... From moshez at math.huji.ac.il Sun Jul 23 10:20:54 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 23 Jul 2000 11:20:54 +0300 (IDT) Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> Message-ID: On Sun, 23 Jul 2000, Fredrik Lundh wrote: > and for the record, I'm fully prepared to vote "no" on list comprehensions, > augumented assignments, range literals, and every trace of a new operator > that changes how python code is tokenized and parsed. I wouldn't go that far, but I'd vote "not until after 2.0" on everything except range literals. The idea being that range literals is something that has discussed since before I knew of Python (which is an objective measurement of course), and we've known what form they'll take for that long. List comprehensions, augmented assignments and new operators are something with an effect on the language that I personally cannot appreciate without more testing. > ...with two major releases with only a few weeks in between, I'm afraid we'll > see the usual "do we really need this?" rule being replaced with "what can we > add to make sure people know there's really a difference?". Well, I'm less cynical -- I do believe that we won't put any features without careful thought about the side effects of usability and readability. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From thomas at xs4all.net Sun Jul 23 11:00:18 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 11:00:18 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14714.39334.615638.738713@anthem.concentric.net>; from bwarsaw@beopen.com on Sun, Jul 23, 2000 at 03:07:18AM -0400 References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> Message-ID: <20000723110018.R9897@xs4all.nl> On Sun, Jul 23, 2000 at 03:07:18AM -0400, Barry A. Warsaw wrote: > Forget about @, let's use >> instead. What I mean by "red herring" is > that it doesn't much matter what the token after print is -- we can > argue about that all we want later. As long as the token can't appear > in that position with any other meaningful semantics, you're fine. > print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg) Eventhough I said I'd prefer deprecating 'print' over doing something like this, I can actually see this work. '>>' on files has two meanings: the C++ one, and the UNIX one. I'm still not sure if it's a good idea, but given this example and the arguments for it, I'm not violently opposed anymore. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sun Jul 23 11:01:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 11:01:41 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397AB72F.FC51AEDE@schneider-kamp.de>; from peter@schneider-kamp.de on Sun, Jul 23, 2000 at 09:13:19AM +0000 References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397AB72F.FC51AEDE@schneider-kamp.de> Message-ID: <20000723110141.S9897@xs4all.nl> On Sun, Jul 23, 2000 at 09:13:19AM +0000, Peter Schneider-Kamp wrote: > "Barry A. Warsaw" wrote: > > print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg) > BTW: I think "print >> sys.stdout" is counter-intuitive, as it looks > like something is flowing from print to sys.stdout. This would > confuse C++-aware folk heavily. Nonsense. This isn't C++, it's Python, and the step for this isn't as great as for other 'strange' features in Python. Furthermore, their observation is true. Something *is* flowing from print to sys.stdout. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov at inrialpes.fr Sat Jul 22 20:20:39 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 22 Jul 2000 20:20:39 +0200 (CEST) Subject: [Python-Dev] object allocator In-Reply-To: <20000721073222.B25293@keymaster.enme.ucalgary.ca> from "Neil Schemenauer" at Jul 21, 2000 07:32:22 AM Message-ID: <200007221820.UAA01386@python.inrialpes.fr> Neil Schemenauer wrote: > > Nice work Vladimir. I will definately check this out in more detail > when I get my home computer back. I'm hoping we can group objects with > gc_prev and gc_next pointers and reduce the memory overhead. I am hoping for more. The major problem with the existing GC algorithm is related with the big number of objects landing in the older generation, which atomic traversal may cause dalays. That's why I mentioned the GC paper discussing this same problem. As for obmalloc, hey python-dev, make some time to check this out! We get more control, more speed and a priori less memory consumption. This is the only small piece of code that I have seen for a while that can boost the overall speed so much, given the current state of CPython. On my Linux, Pentium III 550, regrtest.py drops from 45 secs to 40 secs. I am particularly interested in feedback from Windows users -- the only popular setup I haven't tested so far... The malloc algorithm has been rewritten. Everything is incremental now, even the free list preallocation in an object's pool. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Sat Jul 22 19:56:03 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sat, 22 Jul 2000 19:56:03 +0200 (CEST) Subject: [Python-Dev] Pre-PEP: Attribute Access Handlers v2 In-Reply-To: <200007211726.TAA04540@python.inrialpes.fr> from "Vladimir Marangozov" at Jul 21, 2000 07:26:15 PM Message-ID: <200007221756.TAA01359@python.inrialpes.fr> [me] > > Paul Prescod wrote: > > > > I don't have a PEP number for this yet but I wanted to go through > > another round of comments after changing the mechanism according to Don > > Beaudry's suggestions. > > ... > > Paul, this is clearly unclear <0.1 wink>. Thanks (Paul, Don, Gordon) for clarifying this pre-PEP. As I see it, this aims at providing builtin support for the following (simplified & quickly hacked) __getattr__ version: def new_getattr(self, name, rec=0): hookname = "__get_%s__" % name if not rec and hasattr(self, hookname): hook = new_getattr(self, hookname, rec=1) return hook(self) # builtin __getattr__ follows ... if self.__dict__.has_key(name): return self.__dict__[name] if self.__class__.__dict__.has_key(name): return self.__class__.__dict__[name] # ... return class_lookup(self, name) raise AttributeError, name class C: def __get_hi__(self): return "coucou" def __getattr__(self, name): return new_getattr(self, name) >>> c = C() >>> c.hi "coucou" and its setattr, delattr counterparts. But people are already massively using __getattr__ as method dispatchers, so as I understand it, this is not just about "Attribute Access Handlers". You're looking for a "Normative Naming Scheme and Builtin Support for Attribute Access Handlers", no more, no less. Okay, so make this clear in the PEP. The presented scenarios don't make this clear, IMO. I asked myself what's the enhancement here... Also, it would be useful if you could include a Python implementation of the concept, stating explicitely where the existing functionality ends, and where the proposed enhancement starts, so that people can play with it. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From esr at thyrsus.com Sun Jul 23 14:10:58 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 23 Jul 2000 08:10:58 -0400 Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: <397A9FE8.DC1EBB6@per.dem.csiro.au>; from m.favas@per.dem.csiro.au on Sun, Jul 23, 2000 at 03:34:00PM +0800 References: <397A9FE8.DC1EBB6@per.dem.csiro.au> Message-ID: <20000723081058.D9463@thyrsus.com> Mark Favas : > Earlier today I uploaded a patch to SF for _cursesmodule.c so that it > would link on Tru64 Unix (Version 4.0F). The problem was that the > function has_key() is not present on this platform (nor, apparently, on > SGI or Sun). Moshe queried whether this patch was required to link > against ncurses on Tru64. ncurses does not exist on Tru64. Access to the > functionality of V 4 of the X/Open curses API spec is enabled by the > macro _XOPEN_SOURCE_EXTENDED - neither the header file nor the (only) > curses library have any reference to has_key(). I am not a curses person > (except when... ), so I do not know whether has_key() is part of > the _standard_ (new?) curses, but I am concerned that the > _cursesmodule.c code exposes this interface for all but SGI, Sun and > Tru64 systems. What happens when Python code is written that uses this > function? It will fail on at least these three platforms... Should the > has_key() function be removed, or a wrapper written for those systems > that don't support this function? OK. The story is this: 1. has_key() is unique to ncurses. It's not specified in the X/Open curses API. 2. We added it for a reason :-). It's hard to write programs that adapt to different numbers of function keys without it -- and this is still an issue. because that number still varies even though all the world is a VT100 emulator these days. So I recommend trying to add has_key to the curses module interface in Python, conditionalized on whether you can pick it out of the local curses headers. You can use the implementation in ncurses as a model. -- Eric S. Raymond You know why there's a Second Amendment? In case the government fails to follow the first one. -- Rush Limbaugh, in a moment of unaccustomed profundity 17 Aug 1993 From moshez at math.huji.ac.il Sun Jul 23 14:21:31 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 23 Jul 2000 15:21:31 +0300 (IDT) Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: <20000723081058.D9463@thyrsus.com> Message-ID: On Sun, 23 Jul 2000, Eric S. Raymond wrote: > OK. The story is this: > > 1. has_key() is unique to ncurses. It's not specified in the > X/Open curses API. > > 2. We added it for a reason :-). It's hard to write programs that adapt to > different numbers of function keys without it -- and this is still an issue. > because that number still varies even though all the world is a VT100 > emulator these days. > > So I recommend trying to add has_key to the curses module interface in Python, > conditionalized on whether you can pick it out of the local curses headers. This sounds just like what Mark did. Or maybe I'm reading you wrong. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mal at lemburg.com Sun Jul 23 14:28:36 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 23 Jul 2000 14:28:36 +0200 Subject: [Python-Dev] ANSIfication. References: <20000723022452.Q9897@xs4all.nl> Message-ID: <397AE4F4.E1A9DDE0@lemburg.com> Thomas Wouters wrote: > > I'm also tempted to suggest to remove most of the 'extern's, and possibly > add them to pyport.h if they are still an issue. Most of the current externs > for library functions seem to me like old cruft, though I have no way of > telling how old they are. The getopt() prototype would be solved that way, > in any case, by removing it and relying on the appropriate include file > defining it. > > Here's an example of what I think is old cruft: > posixmodule.c: > /* XXX These are for SunOS4.1.3 but shouldn't hurt elsewhere */ > extern int rename(const char *, const char *); > extern int pclose(FILE *); > extern int lstat(const char *, struct stat *); > extern int symlink(const char *, const char *); > extern int fsync(int fd); I'd suggest doing this in two steps: 1. move the externs to pyport.h (which is the right place for these platform dependent defines and includes) and add #if 0 ... #endif around them 2. check whether these are still needed during the beta phase and if no one complains remove the cruft completely Alternatively, you could also add specific platform dependent #ifdefs to pyport.h which only enable the externs on those platforms where they are needed. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sun Jul 23 14:34:41 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 23 Jul 2000 14:34:41 +0200 Subject: [Python-Dev] Python Consortium Meeting News References: Message-ID: <397AE661.17E19867@lemburg.com> Tim Peters wrote: > > [Neil Hodgson] > > I don't like this new license as it is much more complex than > > the old license. > > Then I'd say you're normal! The principals on "our side" of the negotiation > view this license as something of a triumph, simply because it's so much > less obnoxious than the proposals that preceded it. Not speaking for my > employer, I think we lost. OTOH, python.org will no longer be held hostage. > > > Its about 4 times longer and appears to me to attempt to claim a > > licensing relationship with third parties who use software written in > > Python. > > > > Is Python going to use this license forever, or is it just for 1.6? > > Who knows? It's all hifalutin legalese. Note that the text Guido sent out > is not the same as the text it references at > http://hdl.handle.net/1895.22/1011 either. I believe it's the latter that's > out of date, and the text Guido sent is friendlier to users. Still, one way > to read the Guido version is that 2.0 and everything after is a "derivative > work", so must (paragraph 2) include the 1.6 CNRI license, and (paragraph 3) > "indicate in any such work the nature of the modifications made to CNRI?s > Software". OTOH, I can see at least two other ways to read it! Perhaps a > consortium member who already paid a lawyer would care to pass on their > confusion . Looks like we're going to have a license bloat here ;-) BTW, what happened to the CWI copyright ? It seems to be missing completely from the CNRI text... could be that we'll have to fight with three different license texts which all apply to 2.0 in the future. Why not simply make Python public-domain instead ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Sun Jul 23 15:16:12 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 15:16:12 +0200 Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: ; from moshez@math.huji.ac.il on Sun, Jul 23, 2000 at 03:21:31PM +0300 References: <20000723081058.D9463@thyrsus.com> Message-ID: <20000723151612.T9897@xs4all.nl> On Sun, Jul 23, 2000 at 03:21:31PM +0300, Moshe Zadka wrote: > On Sun, 23 Jul 2000, Eric S. Raymond wrote: > > So I recommend trying to add has_key to the curses module interface in > > Python, conditionalized on whether you can pick it out of the local > > curses headers. > This sounds just like what Mark did. Or maybe I'm reading you wrong. I think what Eric means is moving the ncurses 'has_key' function into the cursesmodule directly, so that there is an implementation for it on all platforms. (Unsure if that's feasible, though.) Or if he doesn't, he doesn't realize that it's already conditional, and hence not too useful in cursesmodule -- you can't rely on it being there. How about a fake has_key for systems that have strict XPG4 or SVr4 curses, that assumes the terminal in question has a minimal set of function keys ? I'm thinking 'vt100' here, given the abundance of vt100(-derived) terminals, but a smaller set would be fine, too, I think. Oh, and perhaps an autoconf test on has_key is a better idea than a platform specific #ifdef -- if people port ncurses to that platform, they'd get has_key after all. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From paul at prescod.net Sun Jul 23 17:10:00 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 10:10:00 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> Message-ID: <397B0AC8.C6780D33@prescod.net> "Barry A. Warsaw" wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> I don't see what proposal you are promoting that doesn't have > PP> "@" in it? > > Forget about @, let's use >> instead. Okay, but we're still inventing a new token that doesn't exist otherwise in the language. There are two reasons I oppose this. 1. On the one hand, we are making the print statement even more of a special "syntax region" than it already is. In my opinion that's newbie *unfriendly*. They learn how ">>" works in one place and then when they look around for somewhere else to use it, they won't find it. I think that that is profoundly unpythonic. 2. On the other hand, I oppose special case hacks *in general* because when you solve a problem in one place, it doesn't solve it elsewhere. The benefits of print are: * no requirement for parens * newline by default * easy string coercion and interpolation * less thinking about whitepspace Okay, but what about when I want these features elsewhere in the Python language? At least the last three should should be available everywhere in Python. In fact, we can do better than print: Yours: print >> sys.stdout, 'post to', listname, 'from', sender, \ 'size=', len(msg) My proposal: writeln( $"post to ${listname} from ${sender} size=${len(msg)}" ) (or) log.writeln( $"post to ${listname} from ${sender} size=${len(msg)}") Note that I have more control over whitespace than in your example. I am also reusing conventions from other popular languages. The interpolation is available *wherever* string processing is done and it uses standard Python features to redirect the output. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Sun Jul 23 17:31:03 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 10:31:03 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <005901bff47e$3ffa7b20$f2a6b5d4@hagrid> Message-ID: <397B0FB7.56982655@prescod.net> Fredrik Lundh wrote: > > paul wrote: > > Nevertheless, every Python programmer needs to learn the ".write" way in > > order to do reasonable text processing. So print's idiosyncracies are > > just one more thing to learn. > > ...and since people need to learn how to write classes to write > larger programs, we can disallow statements and functions on the > module level... My first reaction was: "Great, you've demonstrated that any argument can be extended and parodied into meaningless. Big deal." But on second thought, you haven't even done that. Everything you learn about statements and functions is directly useful when you learn classes. It builds naturally. There is no conflict. Print is a magical syntax zone where everything works differently: * "," means concatenate, * objects are automatically coerced to strings, * newlines appear out of nowhere * parentheses change the behavior radically * (soon maybe) ">>" is used to redirect object invocations Nothing you learn there will help you to learn stderr.write(...) which works completely differently. > >>> usability_guidelines.index("they have to learn it anyway") > Traceback (most recent call last): > ValueError: list.index(x): x not in list Oh really? I thought that this was in the guidelines: "There should be one-- and preferably only one --obvious way to do it.." Of course it must be balanced with everything else in the guidelines, but it should be a factor. Also: "Special cases aren't special enough to break the rules." What could be more special than a unique syntax zone for writing out text to a stream? -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From m.favas at per.dem.csiro.au Sun Jul 23 17:39:52 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Sun, 23 Jul 2000 23:39:52 +0800 Subject: [Python-Dev] _cursesmodule linking, and portability References: <20000723081058.D9463@thyrsus.com> <20000723151612.T9897@xs4all.nl> Message-ID: <397B11C8.8377D2A7@per.dem.csiro.au> Thomas Wouters wrote: > > On Sun, Jul 23, 2000 at 03:21:31PM +0300, Moshe Zadka wrote: > > On Sun, 23 Jul 2000, Eric S. Raymond wrote: > > > > So I recommend trying to add has_key to the curses module interface in > > > Python, conditionalized on whether you can pick it out of the local > > > curses headers. > > > This sounds just like what Mark did. Or maybe I'm reading you wrong. > > I think what Eric means is moving the ncurses 'has_key' function into the > cursesmodule directly, so that there is an implementation for it on all > platforms. (Unsure if that's feasible, though.) Or if he doesn't, he doesn't > realize that it's already conditional, and hence not too useful in > cursesmodule -- you can't rely on it being there. > > How about a fake has_key for systems that have strict XPG4 or SVr4 curses, > that assumes the terminal in question has a minimal set of function keys ? > I'm thinking 'vt100' here, given the abundance of vt100(-derived) terminals, > but a smaller set would be fine, too, I think. > > Oh, and perhaps an autoconf test on has_key is a better idea than a platform > specific #ifdef -- if people port ncurses to that platform, they'd get > has_key after all. This seems to be the way to go. In a nutshell: from what Eric says, has_key() is a needed functionality in the curses module/package. This function is not supplied by the standard curses libraries on the Sun, SGI and Compaq/DEC Unix platforms (and, I guess, any other platforms that implement only the X/Open curses API). The code in _cursesmodule.c as it currently stands has specific support for Sun and SGI, (and compilation support for Compaq/DEC). For Sun and SGI, exposure of this has_key() function at the Python level is #ifdef'ed out (and my patch just adds Compaq/DEC to this set). If this functionality is indeed vital, there should either be an equivalent written in Python present (inside a try: - except: clause) in the curses package for those platforms not providing it natively, or code for has_key() provided in the _cursesmodule.c itself. And an autoconf test does indeed seem the best way to determine whether has_key() exists, rather than platform #ifdefs. Alternatively, support for Sun, SGI, etc should be dropped from the _cursesmodule.c code and a comment to that effect made in Setup.in. The current comment specifies only that the System V version of curses ("often supplied by the ncurses library") is required. -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From akuchlin at cnri.reston.va.us Sun Jul 23 17:56:27 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 23 Jul 2000 11:56:27 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.65260.762631.233327@anthem.concentric.net>; from bwarsaw@beopen.com on Sat, Jul 22, 2000 at 04:07:08PM -0400 References: <1247840871-20245181@hypernet.com> <3979CBFC.2EED0234@prescod.net> <14713.65260.762631.233327@anthem.concentric.net> Message-ID: <20000723115627.B27195@newcnri.cnri.reston.va.us> On Sat, Jul 22, 2000 at 04:07:08PM -0400, Barry A. Warsaw wrote: >print is incredibly convenient; I'd hate to write CGI scripts without >it. Why not make it just a little more so? Bad example; quick-and-dirty CGI scripts may get away with using print. However, if you want decent error handling, such as not outputting a partial page if you get an exception, you need to either not use print, or replace sys.stdout to trap output from 'print' and only send the output once it's all been generated. --amk From effbot at telia.com Sun Jul 23 18:14:13 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 18:14:13 +0200 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <005901bff47e$3ffa7b20$f2a6b5d4@hagrid> <397B0FB7.56982655@prescod.net> Message-ID: <002601bff4c1$0c179200$f2a6b5d4@hagrid> paul wrote: > Oh really? I thought that this was in the guidelines: > > "There should be one-- and preferably only one --obvious way to do it.." > > Of course it must be balanced with everything else in the guidelines, > but it should be a factor. Also: > > "Special cases aren't special enough to break the rules." you obviously didn't read the 10-year old post I pointed to: "...everything else I could think of had other disadvantages. Perhaps printing is one of these things that are important enough to warrant more than one way to do things, even in Python..." ::: I don't know if your recent campaign to remove things from Python is an attempt to compensate for all the PEP stuff, or if you really think Python will become easier to use if we start removing the stuff that makes it easy to use... ...but instead of speculating, I'm just going to quote someone else: "I will refrain from further comments in this vein, and simply place my faith in the benevolent dictator." ::: now back to PEP200. From akuchlin at cnri.reston.va.us Sun Jul 23 18:07:53 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 23 Jul 2000 12:07:53 -0400 Subject: [Python-Dev] _cursesmodule linking, and portability In-Reply-To: <397B11C8.8377D2A7@per.dem.csiro.au>; from m.favas@per.dem.csiro.au on Sun, Jul 23, 2000 at 11:39:52PM +0800 References: <20000723081058.D9463@thyrsus.com> <20000723151612.T9897@xs4all.nl> <397B11C8.8377D2A7@per.dem.csiro.au> Message-ID: <20000723120753.C27195@newcnri.cnri.reston.va.us> On Sun, Jul 23, 2000 at 11:39:52PM +0800, Mark Favas wrote: >just adds Compaq/DEC to this set). If this functionality is indeed >vital, there should either be an equivalent written in Python present Indeed; this week I'll look at translating the ncurses has_key() to Python code. Dropping support for Solaris/IRIX/Tru64 would be excessively harsh. --amk From m.favas at per.dem.csiro.au Sun Jul 23 18:58:54 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Mon, 24 Jul 2000 00:58:54 +0800 Subject: [Python-Dev] ANSIfication breaks socketmodule compile... Message-ID: <397B244E.24ADFEE1@per.dem.csiro.au> The recent bout of ANSIfication seems to have raised a couple of issues with socketmodule: 1) It now won't compile on Tru64, because the declaration of "gethostname" on line 114 conflicts with that in the system unistd.h header file. 114 declares the second parameter as size_t, unistd.h declares it as int (unless the macro _XOPEN_SOURCE_EXTENDED is defined, but that's another can of worms...). The simple fix here is to add another !(defined(__osf__) to the preceding #if line. 2) There'll be an issue on those platforms where the second parameter _is_ declared as type size_t, because the gethostname function is called at line 1402 with the second parameter cast to an int, rather than a size_t... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From effbot at telia.com Sun Jul 23 20:07:31 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 20:07:31 +0200 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile Message-ID: <006c01bff4d1$67022800$f2a6b5d4@hagrid> file signalmodule.c, line 146: #if RETSIGTYPE != void return 0; #endif is that really a valid preprocessor expression? if I understand the ANSI specification correctly, it should be interpreted as "0 != 0" (in other words, it doesn't quite do what the author expected), but MSVC 5.0 thinks that this is fatal error. From effbot at telia.com Sun Jul 23 20:11:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 20:11:48 +0200 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile Message-ID: <007701bff4d1$92f90a00$f2a6b5d4@hagrid> file signalmodule.c, line 146: #if RETSIGTYPE != void return 0; #endif is that really a valid preprocessor expression? if I understand the ANSI specification correctly, it should be interpreted as "0 != 0" (in other words, it doesn't quite do what the author expected), but MSVC 5.0 thinks that this is fatal error. I suggest removing it -- if people are using ANSI C compilers on non-POSIX platforms, they might as well live with a warning... Index: Modules/signalmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/signalmodule.c,v retrieving revision 2.48 diff -c -r2.48 signalmodule.c *** Modules/signalmodule.c 2000/07/22 23:49:30 2.48 --- Modules/signalmodule.c 2000/07/23 18:02:02 *************** *** 94,100 **** static RETSIGTYPE (*old_siginthandler)(int) = SIG_DFL; - static PyObject * signal_default_int_handler(PyObject *self, PyObject *args) --- 94,99 ---- *************** *** 143,151 **** siginterrupt(sig_num, 1); #endif signal(sig_num, signal_handler); ! #if RETSIGTYPE != void ! return 0; ! #endif } --- 142,148 ---- siginterrupt(sig_num, 1); #endif signal(sig_num, signal_handler); ! return; } From paul at prescod.net Sun Jul 23 20:06:51 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 13:06:51 -0500 Subject: [Python-Dev] print References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <005901bff47e$3ffa7b20$f2a6b5d4@hagrid> <397B0FB7.56982655@prescod.net> <002601bff4c1$0c179200$f2a6b5d4@hagrid> Message-ID: <397B343B.B00F2A67@prescod.net> Lest this get (more) out of hand, I'm not proposing that print could be deprecated in the forseeable future. We can, however, make it easier to write to file objects (and cstring objects, and...) rather than making print *more* of a special syntax zone than it already is. If we do our jobs well then people may see the writeln function/method as a simpler, more flexible alternative to print and use it of their own accord. Fredrik Lundh wrote: > > ... > > you obviously didn't read the 10-year old post I pointed to: > > "...everything else I could think of had other disadvantages. > Perhaps printing is one of these things that are important > enough to warrant more than one way to do things, even > in Python..." I absolutely did, that's why I said: > > Of course it must be balanced with everything else in the guidelines, > > but it should be a factor. Do you disagree???? To put it another way: you can tell me that you disagree with my conclusions about print without stating that the guidelines I am using to argue it are somehow inappropriate. So you balance the various guidelines differently than I do. Fine! We can agree to that without claiming that the other person's arguments are invalid. Having a single, obvious way to do something is *one factor we should keep in mind*. Do you disagree???? In the same message you quoted, Guido admitted that his weightings are questionable. Maybe he still stands by them. Maybe he doesn't. He sure isn't going to get mad at me (as you are) merely for raising the question! > I don't know if your recent campaign to remove things from Python is > an attempt to compensate for all the PEP stuff, or if you really think > Python will become easier to use if we start removing the stuff that > makes it easy to use... > > ...but instead of speculating, I'm just going to quote someone else: Funny, it looks like you have already speculated! I happen to think that the print special syntax zone does not make Python easier to use *in the long run* and I offer the following frequently asked questions as evidence: "How do I make print not put a newline at the end?" "Okay, now how do I make it not put whitespace at the end?" "Why is print a statement at all?" and the following infrequently asked questions: "Why can't I have a method named print?" "Why is the syntax for writing to stdout so different from the syntax for writing to stderr?" "Why are the arguments to print automatically coerced but not those for (e.g.) write?" "Why does (e.g.) dir take parentheses but print doesn't?" "I just want to append a few variables to a string. Why isn't it as easy to glue them together as it is to print them out? Shouldn't the comma insert a space?" In REXX, the print statement would print out the names of variables that weren't assigned yet. That made it really easy to do: print hello world The question is whether it made things easier for new programmers *in the long run*. I claim no there and here. (I'm told the Amiga had the string "Hello World" hardcoded in ROM some where :) ). > "I will refrain from further comments in this vein, and simply > place my faith in the benevolent dictator." Two adults should be able to disagree about a Python keyword without getting freaked out. I happen to think that part of what makes Guido a good BDFL is that he listens to people's opinions and he isn't going to get that if every language change proposal is shouted down as heresy, nor if those opposed just don't contribute on principle. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From effbot at telia.com Sun Jul 23 20:16:10 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 23 Jul 2000 20:16:10 +0200 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c Message-ID: <008b01bff4d2$1a1ed140$f2a6b5d4@hagrid> w_byte is a macro that either calls C's putc, or w_more. putc takes an int, and all calls to w_byte make sure they're passing the right thing. however, w_more is defined to take a char, which results in warnings from MSVC5. quick fix: change w_more to take an integer too: Index: Python/marshal.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/marshal.c,v retrieving revision 1.53 diff -c -r1.53 marshal.c *** Python/marshal.c 2000/07/22 18:47:25 1.53 --- Python/marshal.c 2000/07/23 18:07:07 *************** *** 55,61 **** else w_more(c, p) static void ! w_more(char c, WFILE *p) { int size, newsize; if (p->str == NULL) --- 55,61 ---- else w_more(c, p) static void ! w_more(int c, WFILE *p) { int size, newsize; if (p->str == NULL) *************** *** 69,75 **** p->ptr = PyString_AS_STRING((PyStringObject *)p->str) + size; p->end = PyString_AS_STRING((PyStringObject *)p->str) + newsize; ! *p->ptr++ = c; } } --- 69,75 ---- p->ptr = PyString_AS_STRING((PyStringObject *)p->str) + size; p->end = PyString_AS_STRING((PyStringObject *)p->str) + newsize; ! *p->ptr++ = (char) c; } } From moshez at math.huji.ac.il Sun Jul 23 20:27:16 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 23 Jul 2000 21:27:16 +0300 (IDT) Subject: [Python-Dev] ANSIfication breaks socketmodule compile... In-Reply-To: <397B244E.24ADFEE1@per.dem.csiro.au> Message-ID: On Mon, 24 Jul 2000, Mark Favas wrote: > The recent bout of ANSIfication seems to have raised a couple of issues > with socketmodule: > > 1) It now won't compile on Tru64, because the declaration of > "gethostname" on line 114 conflicts with that in the system unistd.h > header file. 114 declares the second parameter as size_t, unistd.h > declares it as int (unless the macro _XOPEN_SOURCE_EXTENDED is defined, > but that's another can of worms...). The simple fix here is to add > another !(defined(__osf__) to the preceding #if line. Hmmmm....gethostname() prototype should probably be left to system includes, and not defined at all (except maybe in pyport.h under heavy #ifdef guard) > 2) There'll be an issue on those platforms where the second parameter > _is_ declared as type size_t, because the gethostname function is called > at line 1402 with the second parameter cast to an int, rather than a > size_t... This is plain wrong! The cast should probably be deleted. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From tim_one at email.msn.com Sun Jul 23 20:29:56 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 14:29:56 -0400 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: <006c01bff4d1$67022800$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > file signalmodule.c, line 146: > > #if RETSIGTYPE != void > return 0; > #endif > > is that really a valid preprocessor expression? No. Checked in a fix a few minutes ago. > if I understand the ANSI specification correctly, it should be > interpreted as "0 != 0" (in other words, it doesn't quite do what > the author expected), No, it's simply not C. "void" has no meaning at all in a constant integer expression (which is what must appear after #if). > but MSVC 5.0 thinks that this is fatal error. Ditto 6.0, and they're both right . From thomas at xs4all.net Sun Jul 23 21:40:06 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 21:40:06 +0200 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: <006c01bff4d1$67022800$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jul 23, 2000 at 08:07:31PM +0200 References: <006c01bff4d1$67022800$f2a6b5d4@hagrid> Message-ID: <20000723214006.U9897@xs4all.nl> On Sun, Jul 23, 2000 at 08:07:31PM +0200, Fredrik Lundh wrote: > file signalmodule.c, line 146: > #if RETSIGTYPE != void > return 0; > #endif > is that really a valid preprocessor expression? According to how I interpreted gcc's documentation, yes. And it works, too, with gcc. I'll readily admit gcc isn't the perfect example of ANSIness though. > if I understand the ANSI specification correctly, it should be interpreted > as "0 != 0" (in other words, it doesn't quite do what the author expected), > but MSVC 5.0 thinks that this is fatal error. I guess I should've mentioned this seperately, in my posting last night ;) Ohwell, I doubt I would've come up with something as good as Tim's solution even if I knew the above wasn't valid. As for the other point, I'd say drop the support for 'int'-returning systems altogether. If such systems are still in use, they would've been generating warnings for a long time now. Apparently noone noticed. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Sun Jul 23 21:43:33 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 15:43:33 -0400 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: <008b01bff4d2$1a1ed140$f2a6b5d4@hagrid> Message-ID: > w_byte is a macro that either calls C's putc, or w_more. > > putc takes an int, and all calls to w_byte make sure they're > passing the right thing. > > however, w_more is defined to take a char, which results in > warnings from MSVC5. > > quick fix: change w_more to take an integer too: > ... And I see you checked that in. Good! I later replaced part of it, via a new mini-subsystem that may tick somebody off, so I'll explain that here so people can yell at me now: 1. asserts are a fundamental tool of good C practice, but are very rarely used in Python source. To encourage their use, I added an include of to Python.h, so that assert is always available. 2. Added a new Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) macro to pyport.h, which is also always available. This casts VALUE from type WIDE to type NARROW, but assert-fails if info is lost due to the cast and Py_DEBUG is #define'd (when we're not in Py_DEBUG mode, it just expands to (NARROW)(VALUE)). Note: this kind of thing is much easier to do in C++, because of inline functions and being able to templatize those on the types involved (i.e., the compiler can figure out which specific checker to expand at compile-time, rather than making you redundantly-- and hence possibly incorrectly --name the types "by hand" again). 3. It's nice that eyeballing every call to marshal's w_byte allows one to infer that the derived calls to w_more are safe, but it's much better to let the compiler check that. So I replaced the raw cast with an invocation of Py_SAFE_DOWNCAST. Doesn't cost anything except in Py_DEBUG mode. From tim_one at email.msn.com Sun Jul 23 21:55:17 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 15:55:17 -0400 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: <20000723214006.U9897@xs4all.nl> Message-ID: [Thomas Wouters] > ... > As for the other point, I'd say drop the support for > 'int'-returning systems altogether. If such systems are still > in use, they would've been generating warnings for a long time > now. Apparently noone noticed. The Unix(tm)-ish autoconfigure stuff came after my Unixish days, and I still don't have a Unixish system available so I've got scant idea how it works. From thomas at xs4all.net Sun Jul 23 22:16:35 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 22:16:35 +0200 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 23, 2000 at 03:55:17PM -0400 References: <20000723214006.U9897@xs4all.nl> Message-ID: <20000723221635.V9897@xs4all.nl> On Sun, Jul 23, 2000 at 03:55:17PM -0400, Tim Peters wrote: > [Thomas Wouters] > > As for the other point, I'd say drop the support for > > 'int'-returning systems altogether. If such systems are still > > in use, they would've been generating warnings for a long time > > now. Apparently noone noticed. > > The Unix(tm)-ish autoconfigure stuff came after my Unixish days, and I still > don't have a Unixish system available so I've got scant idea how it works. > >From what I can dope out, RETSIGTYPE isn't mentioned in configure.in at all, > but gets pulled out of thin air by magic anyway by the time "configure" is > built: > echo "$ac_t""$ac_cv_type_signal" 1>&6 > cat >> confdefs.h < #define RETSIGTYPE $ac_cv_type_signal > EOF Autoconf consists of standard and user-defined rules. The standard ones are things like checking the availability of ANSI types, and usually consist of a single m4 macro: # Type availability checks AC_TYPE_MODE_T AC_TYPE_OFF_T AC_TYPE_PID_T AC_TYPE_SIGNAL AC_TYPE_SIZE_T AC_TYPE_UID_T 'AC_TYPE_SIGNAL' expands in those 40 lines of code in configure that check the return type of signal handlers. User-defined rules are like the one I wrote for right-shifting-zero-fills, and are a tad longer: there are a few 'component' macros that check for headers, functions or libraries, and you can write your own little test-program to switch on. All the macros get expanded into a shell script that compiles (and executes, when necessary) test programs. > This *suggests* it's "still an issue" under Unixy things, but beats me. > void is ANSI, int isn't. If any Unixoid swears it's OK to nuke RETSIGTYPE, > I'd be delighted to do it. configure is also built to run on any system with an almost-working K&R C compiler and something remotely resembling proto-UNIX ;) It doesn't care much about standards, because it's build in order to easily support systems that *aren't* following the standards. All in all, if the ANSI standard says signal-handlers should return void, by all means, remove the switch altogether. I removed the whole HAVE_STDARG_PROTOTYPES switch for ANSI variable-arg lists for exactly the same reason. I just wasn't sure if the return type of signal handers was defined by ANSI C. In fact, we can probably remove a lot more checks from configure.in and the code that #ifdefs on the result, if we decide to really eradicate every trace of non-ANSI code. However, it's not winning anything more than a few seconds of 'configure' time and a few milliseconds of 'cpp' time, so it's probably not worth it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Sun Jul 23 22:31:47 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 22:31:47 +0200 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 23, 2000 at 03:43:33PM -0400 References: <008b01bff4d2$1a1ed140$f2a6b5d4@hagrid> Message-ID: <20000723223147.W9897@xs4all.nl> On Sun, Jul 23, 2000 at 03:43:33PM -0400, Tim Peters wrote: > Note: this kind of thing is much easier to do in C++, because of > inline functions and being able to templatize those on the types > involved (i.e., the compiler can figure out which specific checker to > expand at compile-time, rather than making you redundantly-- and hence > possibly incorrectly --name the types "by hand" again). Is that a veiled suggestion to compile Python as C++ ? ;) I actually tried to do that, and it almost worked. Some of the current code uses a few C++ reserved words ('new', 'class') that need to be renamed, and a couple of expressions need some additional parentheses. (The Py_INCREF/DECREF macros, for instance, produced some incomprehensible g++ error.) (I tried compiling with g++ to find any lingering K&R C prototypes. And it worked, it found a few for me I hadn't realized were wrong.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Sun Jul 23 22:32:10 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 16:32:10 -0400 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: <20000723221635.V9897@xs4all.nl> Message-ID: [Thomas Wouters] > ... > All in all, if the ANSI standard says signal-handlers should > return void, by all means, remove the switch altogether. I removed > the whole HAVE_STDARG_PROTOTYPES switch for ANSI variable-arg lists > for exactly the same reason. I just wasn't sure if the return type > of signal handers was defined by ANSI C. Yes, it is. Almost nothing *else* about signals is defined to work in a portable way, but handlers are defined to return void. > In fact, we can probably remove a lot more checks from > configure.in and the code that #ifdefs on the result, if we decide > to really eradicate every trace of non-ANSI code. However, it's not > winning anything more than a few seconds of 'configure' time and a few > milliseconds of 'cpp' time, so it's probably not worth it. I don't really care about extra crap in the configure scripts, except to the extent that they baffle people porting to new platforms (the Talmudic distinctions drawn to support 197 incompatible flavors of Unix leave people on other systems scratching their heads until the earlier of wearing their fingernails away or passing out from blood loss ). What I *really* care about is getting RETSIGTYPE out of our *source* code. Macros do damage! They're hard to figure out, hard to write safely, full of surprises even so, and frustrate the heck out of single-stepping in the debugger. Unforunately, they're necessary to write robust cross-platform C code. But every one we can nuke is one less knife in the heart. Hmm ... I'll leave the Unix config stuff alone, but get rid of RETSIGTYPE in the rest of the tree. Objections? From thomas at xs4all.net Sun Jul 23 22:41:07 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 23 Jul 2000 22:41:07 +0200 Subject: [Python-Dev] ANSIfication problems: signalmodule.c doesn't compile In-Reply-To: ; from tim_one@email.msn.com on Sun, Jul 23, 2000 at 04:32:10PM -0400 References: <20000723221635.V9897@xs4all.nl> Message-ID: <20000723224107.R9892@xs4all.nl> On Sun, Jul 23, 2000 at 04:32:10PM -0400, Tim Peters wrote: > What I *really* care about is getting RETSIGTYPE out of our *source* code. > Macros do damage! They're hard to figure out, hard to write safely, full of > surprises even so, and frustrate the heck out of single-stepping in the > debugger. Unforunately, they're necessary to write robust cross-platform C > code. But every one we can nuke is one less knife in the heart. Agreed. And each one makes it harder to port to new systems ;) (I wish I had access to such a hard-to-do new system... I like a little challenge ;) > Hmm ... I'll leave the Unix config stuff alone, but get rid of RETSIGTYPE in > the rest of the tree. Objections? Sounds like a good idea to me. Does config.h get exported to extention code, by the way ? If it is, keeping it in is probably a good idea. It doesn't look like it is, though, so I'm tempted to remote the autoconf check anyway. All your reasons for removing the macros from the source go for configure.in, too, especially when porting to new systems. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Sun Jul 23 23:11:30 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 17:11:30 -0400 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: <20000723223147.W9897@xs4all.nl> Message-ID: [Tim] > Note: this kind of thing is much easier to do in C++ ... [Thomas Wouters] > Is that a veiled suggestion to compile Python as C++ ? ;) Na, just a data point. If P3K is a reimplementation from the ground up, C++ is certainly worth considering. At the O'Reilly conference, it was announced that the Perl rewrite in C++ (codenamed Topaz) has been abandoned. I didn't attend that session, but my impression from others is that they attempted to model Perl objects directly by C++ objects, and were frustrated by the consequent lack of low-level control. That's more ambitious than I would have tried. Using C++ just as "a better C" actually works, keeping the OO stuff simple and internal (e.g., I'd still expose a plain-C interface, and ignore the last 5 years of new C++ features <0.5 wink -- whether any given compiler handles them correctly is still too much of a crap shoot>). So not really C++, but maybe C++--. > I actually tried to do that, and it almost worked. Some of the current > code uses a few C++ reserved words ('new', 'class') that need to be > renamed, and a couple of expressions need some additional parentheses. > (The Py_INCREF/DECREF macros, for instance, produced some > incomprehensible g++ error.) It would be good to clean that stuff up, to ease future experiments. I haven't used C since 1994, *except* when working on Python, so stuff like "new" and "class" used in non-C++ ways bothers my eyeballs. mutual-back-scratching-ly y'rs - tim From tim_one at email.msn.com Mon Jul 24 00:23:48 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 18:23:48 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14713.64973.585633.87443@anthem.concentric.net> Message-ID: [Barry A. Warsaw] > ... > log.write('post to %s from %s, size=%d\n' % (listname, > sender, len(msg))) > > vs > > print 'post to', listname, 'from', sender, 'size=', len(msg) > > With the former, you have to know about the rules for string > interpolation, you have to make sure you've got your tuple is the > right length, you have to remember to add the trailing newline. OTOH, they don't produce the same output! The comma after "from %s" is missing in the latter, and the latter adds an extra space after "size=". These very much relate to the endlessly repeated newcomer questions Paul sketched, such as "how can I get rid of the trailing newline?", "how can I print to a different file?", and (IIRC, Paul missed this one) "how can I get *rid* of the space between two items?". The uncomfortable truth is that getting the output you want, to the destination you want, is usually a lot less hassle in Perl. Paul latched on to the heart of Perl's convenience with his [Paul] > log.writeln($"post to ${listname} from ${sender}, size=${len(msg)}") where I've put back the comma from Barry's original. Perhaps Barry will counter with print >> log, $"post to ${listname} from ${sender}, size=${len(msg)}" Then I'd counter-counter with print >> log, $"post to $listname from $sender, size=${len(msg)}" But there's not a new suggestion in this whole thing -- even ">>" specifically was suggested long ago for this purpose. I can't say whether Guido ever read those suggestions, but I don't recall him ever responding. ABC *did* have auto-stringifying expression interpolation in its strings, so presumably he didn't like it there. I know I didn't like it in ABC, but for an avoidable reason: it used the same character for both "interpolate this" left and right brackets, which often made it hard to see exactly what was being interpolated. I've always been surprised that Guido retained that latter property in Python's shorthand for repr (a function that doesn't *merit* a shorthand if ever there was one ): >>> print ``1+2`+`3+4`` '37' >>> I'm not sure how Python's parser manages to get that straight! In Precodese, it would be (except that $(x) is presumably str(x) rather than repr(x)): print $"$($(1+2)+$(3+4))" which at least makes the grouping clear. I'm all for it. in-principle-if-not-in-every-detail-ly y'rs - tim From tim_one at email.msn.com Mon Jul 24 02:55:10 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 20:55:10 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <397AE661.17E19867@lemburg.com> Message-ID: [M.-A. Lemburg] > BTW, what happened to the CWI copyright ? It seems to be missing > completely from the CNRI text... could be that we'll have > to fight with three different license texts which all apply > to 2.0 in the future. > > Why not simply make Python public-domain instead ? CNRI wanted a new licence, and CNRI wrote the new license text. Their motivations and reasoning were-- and remain --a mystery to me (not in the sense that I didn't understand them, but in the plainer sense that I was never told -- everything they said on the subject consisted of the single msg Guido forwarded to c.l.py, which said nothing specific -- perhaps they said more at the consortium mtg? don't know). Can only suggest you direct questions to the people Guido named in his announcement (Dr. Kahn at CNRI, Bob Weiner at BeOpen). From bwarsaw at beopen.com Mon Jul 24 04:07:40 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 22:07:40 -0400 (EDT) Subject: [Python-Dev] Evolving Python (was Re: Feature bloat in Python ...) References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> Message-ID: <14715.42220.655527.947800@anthem.concentric.net> I think we're going about this all wrong. We all have our pet peeves, syntax gripes, missing functionality, etc. about Python. We're all so quick to identify these problems and expect everybody else to agree with us. We proposal solutions or enhancements to the language that of course, everybody should immediately agree on. But we never get consensus. Given the size of the developer community, and the diversity of applications and experience, we never will on any of these features. If we put each PEP and pre-PEP up for a vote here, I'll bet every one would fail. The Perl6 and Tcl crews should take a lesson here. You cannot design a language by committee. I'm beginning to think that our role on python-dev is different than we thought. I think for a particular proposal for a new language feature, or core language functionality, it is our job to explore the details and ramifications as much as possible. These should be summarized in a PEP, and it must have running code or a working patch. Guido can't possibly follow every thread in this mailing list and he shouldn't have to. But he can read a PEP, apply a patch, play with the new feature and decide yeah, nay, lukewarm-but-needs-more-work. We need to make Guido's job as language designer and BDFL easier, not harder. Sniping at each other means he has to get involved in petty crap among his advisors. This is what I'd hoped the PEPs and python-dev would be for: to encourage people to explore ways to improve the language and for people to work together to write good proposals and build good code. Even if it's eventually rejected. If you have a language feature that you're willing to champion, then I encourage you to write a PEP and develop a patch. Post the patch to SF so others can play with it. Without working code, a language proposal should by default be considered incomplete. Tired-and-venting-ly, -Barry From paul at prescod.net Mon Jul 24 04:11:57 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 21:11:57 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: Message-ID: <397BA5ED.D3C33699@prescod.net> Tim Peters wrote: > > ... > > I'm not sure how Python's parser manages to get that straight! In > Precodese, it would be (except that $(x) is presumably str(x) rather than > repr(x)): > > print $"$($(1+2)+$(3+4))" > > which at least makes the grouping clear. I'm all for it. Egad. It's enough to make me think twice about my own proposal. :) Nevertheless, I agree it's clearer than your tick-example which almost made me run for my plotted plant. As happy as I am to have it called Prescod-ese, I admit to influence from some languages that (otherwise) suck. :) credit-where-due 'ly yrs -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Mon Jul 24 04:42:48 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 21:42:48 -0500 Subject: [Python-Dev] pep-dev References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> Message-ID: <397BAD28.E4BF7E54@prescod.net> "Barry A. Warsaw" wrote: > > ... > > I'm beginning to think that our role on python-dev is different than > we thought. I think for a particular proposal for a new language > feature, or core language functionality, it is our job to explore the > details and ramifications as much as possible. These should be > summarized in a PEP, and it must have running code or a working patch. This isn't directly a followup but you've touched on something I've been thinking. I have been thinking for several days that PEPs give us a clear dividing line between what could go on in Python-dev and what could go on in a theoretical "other mailing list" with an open subscription. I called this once "Python syntax" but instead we could call it pep-dev. If we make a pep-dev mailing list where anyone could contribute then we could have a lot more input from the Python community but the list could still be focused enough that current python-dev'ers would feel like they weren't wading through a million TKinter and curses questions. Python-dev itself could be reserved for final implementation questions once a feature has been accepted. Guido wouldn't need to read every message in PEP-dev because the whole point is to come up with a PEP that he *could* read. In fact, nobody would read every message of PEP-dev (well, maybe Thomas Wouters, he seems to have infinite energy). Each message could be clearly labelled as relating to this PEP or that one and if you aren't interested, you could just ignore that thread. Messages that are not about a PEP would be strongly frowned upon. Discussing curly-brace delimiters is fine -- as long as the end result is a PEP that ensures that we never, ever have to discuss it again because it clearly states all of the arguments for and against. (okay, maybe I'm dreaming) Even if you hate the features being proposed in PEPs, it seems really useful to describe each of them once so that we have something to point at and say: "Yeah, we've thought about it in detail and Guido decided against it. Raising it again won't help." There are also some issues that really should be worked out somewhere, like our standard package hierarchy (if any) and the class hierarchy we will use after type/class unification. And a formal definition of some of our implicit interfaces...etc. etc. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From bwarsaw at beopen.com Mon Jul 24 04:49:47 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 22:49:47 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> Message-ID: <14715.44747.65722.305555@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> log.writeln("Post to ", listname, " from ", sender, " size=", PP> len( msg )) That could work, if we added writeln() to all file-like objects. One advantage of extending print is that the write() method is already a documented (and existing) interface. PP> or (with auto string-coercion): PP> log.writeln("Post to "+listname+" from "+sender+" size="+len( PP> msg )) Isn't adding auto string-coercion a more radical suggestion than extending print? -Barry From tim_one at email.msn.com Mon Jul 24 04:55:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 22:55:36 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397BA5ED.D3C33699@prescod.net> Message-ID: [Tim] > ... > I'm not sure how Python's parser manages to get that [``1+2`+`3+4``] > straight! In Prescodese, it would be (except that $(x) is presumably > str(x) rather than repr(x)): > > print $"$($(1+2)+$(3+4))" > > which at least makes the grouping clear. I'm all for it. [Paul Prescod] > Egad. It's enough to make me think twice about my own proposal. :) > > Nevertheless, I agree it's clearer than your tick-example which almost > made me run for my plotted plant. Yes, both examples suck, but distinct left & right bracketing characters at least make the extremes tractable. They also make the usual cases obvious, as some of us have learned from languages that suck . > As happy as I am to have it called Prescod-ese, I admit to influence > from some languages that (otherwise) suck. :) Indeed, if Perl got the philosophy wrong but many details right, then Python may be open to the opposite critique. BTW, triple-quoted strings got added to Python after I whined (& whined, & whined) on c.l.py that I was writing some block-output generating programs in Perl because pasting screen-width strings with explicit newlines together was driving me nuts in Python. Wouldn't be the first time we stole the heart of a decent detail from Perl! Python's "%(name)format" % dict is great (& better than Perl) for fine-grained control of formatting, but we're missing Perl's ease in the vast area between that and what plain "print" can do. Perl's got nothing to be ashamed of here: Larry looked at the mass of insanely convoluted quoting and interpolation rules from the Unix shells and from Tcl, and came up with something downright Pythonic in its uniformity and simplicity. Except he couldn't resist pushing it too far (e.g., trying to *guess* whether "[]" are literal characters or an indexing operator in "$a[$b]"). BTW, at the time, half the people on c.l.py complained that triple-quoted strings were unnecessary feature bloat too. Jeez, if I cared about what was *necessary*, I'd program in Scheme <0.3 wink>. BTW too, in "There should be one-- and preferably only one --obvious way to do it", "obvious" doesn't mean instantly understandable to someone from Mars. Nothing in computer languages is obvious in that sense. It means more "easy to learn and hard to forget once you know it", and that the vast majority of people who know the language are likely to spell it the same way. Sequence slicing is the perfect example: newbies are routinely baffled by it, but once they get it they never lose it, and all of us use it. Pushing and popping sys.stdout doesn't qualify as obvious that way, ditto the twenty ways to paste the output you want together by hand now (note that whenever this pops up on c.l.py, about as many alternatives are suggested as there are responses -- unPythonic). we-can-leave-python-alone-when-it-finishes-becoming-python-ly y'rs - tim From bwarsaw at beopen.com Mon Jul 24 05:01:42 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:01:42 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <397A007F.CF8DEBE2@prescod.net> Message-ID: <14715.45462.695712.12998@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> But I'm -0 on that, preferring a new sys function, called MZ> writeln MZ> That would be extremely readable, require no new syntax and no MZ> additional builtins. MZ> Reference implementation: Add a `sep' keyword, check for residual keyword arguments, and I might be +0 on that. Of course, now you're in the realm of... so-easy-i'll-just-cut-and-paste-this-into-my-own-app-ly y'rs, -Barry -------------------- snip snip -------------------- def writeln(*args, **kws): import sys file = sys.stdout sep = ' ' end = '\n' if kws.has_key('file'): file = kws['file'] del kws['file'] if kws.has_key('nl'): if not kws['nl']: end = ' ' del kws['nl'] if kws.has_key('sep'): sep = kws['sep'] del kws['sep'] if kws: raise TypeError('unexpected keywords') file.write(sep.join(map(str, args)) + end) From bwarsaw at beopen.com Mon Jul 24 05:02:54 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:02:54 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> Message-ID: <14715.45534.435629.993813@anthem.concentric.net> >>>>> "BAW" == Barry A Warsaw writes: BAW> I've got a very rough set of patches that implement this, and BAW> here's an example that really works. I'll flesh the patches BAW> out and post them to SF. I've now done this, so at least there's working code you can play with. -Barry From bwarsaw at beopen.com Mon Jul 24 05:10:07 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:10:07 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> Message-ID: <14715.45967.555713.668818@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: >> have PP> "@" in it? Forget about @, let's use >> instead. PP> Okay, but we're still inventing a new token that doesn't exist PP> otherwise in the language. No we're not! From token.h: #define RIGHTSHIFT 35 PP> There are two reasons I oppose this. PP> 1. On the one hand, we are making the print statement even PP> more of a special "syntax region" than it already is. In my PP> opinion that's newbie *unfriendly*. They learn how ">>" works PP> in one place and then when they look around for somewhere else PP> to use it, they won't find it. I think that that is profoundly PP> unpythonic. Where would people look to use >> in this sense elsewhere? PP> 2. On the other hand, I oppose special case hacks *in general* PP> because when you solve a problem in one place, it doesn't PP> solve it elsewhere. The benefits of print are: | * no requirement for parens | * newline by default | * easy string coercion and interpolation | * less thinking about whitepspace PP> Okay, but what about when I want these features elsewhere in PP> the Python language? At least the last three should should be PP> available everywhere in Python. Don't these things mostly crop up in printing, in one form or another. I can imagine you might want to use something like #3.5 or #4 when, e.g. building a string to be used as a regex, but in that case, you already have #3.5 and #4, and probably don't want #2. (We won't even touch #1 in that context :). -Barry From bwarsaw at beopen.com Mon Jul 24 05:12:33 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:12:33 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <1247840871-20245181@hypernet.com> <3979CBFC.2EED0234@prescod.net> <14713.65260.762631.233327@anthem.concentric.net> <20000723115627.B27195@newcnri.cnri.reston.va.us> Message-ID: <14715.46113.795737.74175@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> Bad example; quick-and-dirty CGI scripts may get away with AK> using print. However, if you want decent error handling, such AK> as not outputting a partial page if you get an exception, you AK> need to either not use print, or replace sys.stdout to trap AK> output from 'print' and only send the output once it's all AK> been generated. You're right, of course. I think extended print would make writing stuff like this more readable. -Barry From bwarsaw at beopen.com Mon Jul 24 05:21:59 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:21:59 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.64973.585633.87443@anthem.concentric.net> Message-ID: <14715.46679.547126.183981@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: | [Paul] | log.writeln($"post to ${listname} from ${sender}, size=${len(msg)}") TP> where I've put back the comma from Barry's original. Perhaps TP> Barry will counter with | print >> log, $"post to ${listname} from ${sender}, size=${len(msg)}" Actually, I'd counter with something quite similar, but much more Pythonic. print >> log, 'post to %(listname)s from %(sender)s, size=%(msglen)s' % { 'listname': listname, 'sender' : sender, 'msglen' : len(msg), } variants of which I use all the time! TP> But there's not a new suggestion in this whole thing -- even TP> ">>" specifically was suggested long ago for this purpose. :) -Barry From bwarsaw at beopen.com Mon Jul 24 05:29:21 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Sun, 23 Jul 2000 23:29:21 -0400 (EDT) Subject: [Python-Dev] pep-dev References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> <397BAD28.E4BF7E54@prescod.net> Message-ID: <14715.47121.177301.678752@anthem.concentric.net> I think this is a very good idea Paul. -Barry From tim_one at email.msn.com Mon Jul 24 05:40:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 23 Jul 2000 23:40:18 -0400 Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14715.46679.547126.183981@anthem.concentric.net> Message-ID: [Paul] > log.writeln($"post to ${listname} from ${sender}, size=${len(msg)}") [Tim] > where I've put back the comma from Barry's original. Perhaps > Barry will counter with > > print >> log, $"post to $listname from $sender, size=$(len(msg))" [Barry] > Actually, I'd counter with something quite similar, but much more > Pythonic. > > print >> log, 'post to %(listname)s from %(sender)s, > size=%(msglen)s' % { > 'listname': listname, > 'sender' : sender, > 'msglen' : len(msg), > } > > variants of which I use all the time! Me too, but because there's nothing better: Perl people think it's *entirely* Pythonic to, e.g., need to type "listname" three times where they only need to type it once <1/3 wink>. That much redundancy on a single line of code is not helpful at all. This is simply an area where Perl is friendlier & easier. As I mentioned in another msg, Python's %(name)format shines when format is non-trivial; alas, plain unqualified %s formats account for the vast bulk of uses in my experience. From paul at prescod.net Mon Jul 24 05:41:39 2000 From: paul at prescod.net (Paul Prescod) Date: Sun, 23 Jul 2000 22:41:39 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> <14715.45967.555713.668818@anthem.concentric.net> Message-ID: <397BBAF3.683DE578@prescod.net> "Barry A. Warsaw" wrote: > > No we're not! From token.h: > > #define RIGHTSHIFT 35 Okay, okay, you're inventing a new semantic for an existing token. > Where would people look to use >> in this sense elsewhere? You've got me. Maybe nowhere. Maybe they'll just ask why >> is a binary operator except in print. Maybe they'll see a=j>>k and think it has something to do with string printing. That's reasonable if you don't have the C-family background. Maybe they just look back after six months and say: "Why the hell did I learn that >> hack if it is never going to be used anywhere else in the language?" Maybe they'll just be sitting in the front row of my Python class and say: "that looks like somewhat of a hack and it reminds me of one of the ugliest features of C++" and I won't have any answer except to say: "yes its a hack, but believe me Python isn't really a hacky language...there are just a few." We all have different design aesthetics. I would rather see a hundred clean features added to Python's syntax rather than one hack. You'll recall that when you announced the addition of string methods I told you that you had cleaned up one of my two big Python embarrassments. print is the other. Renumbering: > 1 no requirement for parens > 2 newline by default > 3 easy string coercion > 4 easy string interpolation > 5 less thinking about whitespace > > Don't these things mostly crop up in printing, in one form or > another. I can imagine you might want to use something like #4 or > #5 when, e.g. building a string to be used as a regex, but in that > case, you already have #4 and #5, and probably don't want #2. (We > won't even touch #1 in that context :). I don't follow. Consider: I'm building up a string to be used to search my phones database. (Prescod, Paul): phone=555-1211, fax=555-2121 Don't I want 3, 4 and 5? Why do you say I "already have them?" def lookup( query ) regex=$"${person.lastname},${person.firstname}: .*${query}=(\w+)" .... lookup( "phone" ) lookup( "fax" ) Sure, I could set up a tuple or a dict but you pointed out yesterday that that is inconvenient. If it's too inconvenient for people who are printing things then I think it's too inconvenient for everyone. (yes, I'm confident that there is a bug in my regexp logic -- you get the picture!) -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From skip at mojam.com Mon Jul 24 06:12:17 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 23 Jul 2000 23:12:17 -0500 (CDT) Subject: [Python-Dev] map() for methods In-Reply-To: References: <39771CCE.F70A48D4@lemburg.com> Message-ID: <14715.49697.141824.636846@beluga.mojam.com> A couple people have responded to my comment about deprecating the string without deprecating map(). Most recently, Tim stated: >> As far as I'm aware, there's no clean way to do that with string >> methods. Tim> Sorry if someone pointed this out already (2K+ msgs backed up!): Tim> newlist = [s.strip() for s in oldlist] I realized that list comprehensions were possible, but they aren't yet in the language, so I didn't think them a fair substitute for map(string.strip, oldlist) If you get list comprehensions in there in some guise, then sure, deprecate away... Skip From skip at mojam.com Mon Jul 24 06:24:16 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 23 Jul 2000 23:24:16 -0500 (CDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <3979C032.357FCAF4@prescod.net> References: <20000722092530.A24247@newcnri.cnri.reston.va.us> <3979C032.357FCAF4@prescod.net> Message-ID: <14715.50416.423999.54454@beluga.mojam.com> Paul> I think it is also worthwhile to recognize "conventions" that Paul> could be made clearer with first-class syntax. List comprehensions Paul> replace the map/lambda convention (and would IMHO, allow Paul> map/filter, at-least, to be deprecated). Range literals replace Paul> the for i in range(...) convention and so forth. Range literals would also allow compilers such as Python2C to optimize Python ints to C ints. It can't do this today without assuming that range() and xrange return a sequence of ints. I guess I'll stick my neck way out there with Barry and say I rather like his "print @" proposal. Most new Python programmers learn about print earlier than a combination of somefile.write() + the "%" operator. While it might mostly be syntactic sugar, it is generally easier for new folks to understand. I suspect (though won't bother to check) that most of the I/O in the Python tutorial uses print instead of sys.stdout.write as well. Extending print's semantics to other file-like objects makes sense to me. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "To get what you want you must commit yourself for sometime" - fortune cookie From skip at mojam.com Mon Jul 24 06:34:53 2000 From: skip at mojam.com (Skip Montanaro) Date: Sun, 23 Jul 2000 23:34:53 -0500 (CDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <3979C9E4.E66FE451@prescod.net> References: <20000722092530.A24247@newcnri.cnri.reston.va.us> <3979C9E4.E66FE451@prescod.net> Message-ID: <14715.51053.852304.213936@beluga.mojam.com> Paul> Common Lisp and Linux are victims of feature creep. Perl and Paul> Sendmail just suck. Whoa there! Not to get into an off-topic shouting match of tit-for-tat, but Sendmail's syntax dates from a time when things were a lot less uniform than they are today. Machines were a helluva lot slower, had lots less memory and faced a decidedly less uniform email environment than later tools did. I don't believe early versions of Sendmail had "frozen" config files either, so parsing fast (probably with a very crude, ad hoc parser) was important. The universe of email possibilities -- both in addressing and connectivity -- was much broader than it is today. You had !-paths, Bitnet, SMTP, CSNet, direct connections, store-and-forward and fewer standards (like RFC-822 and its descendants). Unlike more recent tools, Sendmail did it all. That very few people ever have to stare at a raw sendmail.cf file anymore is a big credit to the Sendmail gang in my opinion... Skip From moshez at math.huji.ac.il Mon Jul 24 07:02:32 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 24 Jul 2000 08:02:32 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14715.45462.695712.12998@anthem.concentric.net> Message-ID: On Sun, 23 Jul 2000, Barry A. Warsaw wrote: > Add a `sep' keyword, check for residual keyword arguments, and I might > be +0 on that. Of course, now you're in the realm of... > > so-easy-i'll-just-cut-and-paste-this-into-my-own-app-ly y'rs, Well, I know Python, being very quick to write in, makes this awfully easy. But I still thing people would use import sys sys.writeln("hello", first_name, last_name+",") rather then def writeln(*args, **kws): ... writeln(...) Actually, I'm beginning to think we need a utils.py module for this, and the cool generator stuff. If we decide we need this in the builtins, the builtin module could do the equivalent of "from utils import *" or-we-could-just-make-python-harder-to-write-in-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From moshez at math.huji.ac.il Mon Jul 24 07:21:03 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 24 Jul 2000 08:21:03 +0300 (IDT) Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: Message-ID: On Sun, 23 Jul 2000, Tim Peters wrote: > At the O'Reilly conference, it was announced that the Perl rewrite in C++ > (codenamed Topaz) has been abandoned. I didn't attend that session, but my > impression from others is that they attempted to model Perl objects directly > by C++ objects, and were frustrated by the consequent lack of low-level > control. As another data-point, I've heard from reliable sources that Topaz was written to use bleeding edge C++, including all manners of weird templates. C++ I might be able to live with, but a very least common denominator C++ -- otherwise you hurt the well-known Python portability, which is a major strength. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From klm at digicool.com Mon Jul 24 07:29:36 2000 From: klm at digicool.com (Ken Manheimer) Date: Mon, 24 Jul 2000 01:29:36 -0400 (EDT) Subject: [Python-Dev] aargh Message-ID: <14715.54336.634634.776495@korak.digicool.com> I'm feeling some dismay reading over recent postings to python-dev. Particularly some of the rancor in the print discussion, and "Thank god guido is still in charge, and not going to go crazy", countered by "but guido said he was going to do this or that, ha" - i found myself thinking that (1) i'm glad i'm not in guido's place, and (2) geeze, aren't we making guido job harder, not easier? What the heck is going on? I think people are sounding off too much, posing features and opinions when they don't *need* to do so. People should think twice before posing new python features - and hold off, a lot more of the time. Treat every single thing you propose as if it costs something significant - because it does! Not only does it take bandwidth - which could be concentrated on crucial ideas - but if the feature does fly, it means sacrificing some established familiarity, a valuable commodity in the language business. Change costs, and usually needs to be worth a lot to be worth the while! Those of you offering lots of clever changes - what are you doing? Do you really think they're all so important, or are you just pleased to be finding neat little ideas? Everyone needs to hold out for what they at least consider outstandingly important. Ken klm at digicool.com From thomas at xs4all.net Mon Jul 24 07:36:02 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 24 Jul 2000 07:36:02 +0200 Subject: [Python-Dev] pep-dev In-Reply-To: <397BAD28.E4BF7E54@prescod.net>; from paul@prescod.net on Sun, Jul 23, 2000 at 09:42:48PM -0500 References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> <397BAD28.E4BF7E54@prescod.net> Message-ID: <20000724073602.Y9897@xs4all.nl> On Sun, Jul 23, 2000 at 09:42:48PM -0500, Paul Prescod wrote: > "Barry A. Warsaw" wrote: > > I'm beginning to think that our role on python-dev is different than > > we thought. I think for a particular proposal for a new language > > feature, or core language functionality, it is our job to explore the > > details and ramifications as much as possible. These should be > > summarized in a PEP, and it must have running code or a working patch. For the record, this has always been how I saw PEPs, with the slight distinction that sometimes Guido would come along and offer divine guidance, and the PEP would reflect Guido's opinion in the end. There is nothing wrong with it reflecting the community's opinion, though, as long as the champion is able to grasp all of it. Guido's 'guidance' could just be his judgement of the final result ;) Though on some subjects, this might require a fair ammount of Guido-channeling on the side of the champion, in order not to waste too much time on things Guido will not allow anyway. Things like user-defined syntax in the core language. > Guido wouldn't need to read every message in PEP-dev because the whole > point is to come up with a PEP that he *could* read. In fact, nobody > would read every message of PEP-dev (well, maybe Thomas Wouters, he > seems to have infinite energy). Not at all ! I have been purposely ignoring most of the numerous messages on python-list about new operators, user-defined operators and multimethods. I even have trouble following python-dev sometimes ;) especially in the longer-posted threads. I seem to have near-endless energy discussing the finer points of coding style and standards, and actually toying with code, merely because programming is one of my great passions, and the only one I can't really relieve at work or with my girlfriend ;) > Each message could be clearly labelled as relating to this PEP or that one > and if you aren't interested, you could just ignore that thread. Excellent idea. We should have realized before that python-list and python-dev are too much 'involved' fora for proto-ideas: everyone worries (on both lists) that what someone else proposes is going to be accepted without counterword, so everyone has something to add or counter. I would suggest plenty of drafts before a PEP is accepted, though, and give everyone on python-list and python-dev time to get their own comments added to the PEP. If python.org is still being held hostage, I can create a couple of lists for this purpose (but Barry already knows that ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From esr at thyrsus.com Mon Jul 24 07:55:00 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 01:55:00 -0400 Subject: [Python-Dev] aargh In-Reply-To: <14715.54336.634634.776495@korak.digicool.com>; from klm@digicool.com on Mon, Jul 24, 2000 at 01:29:36AM -0400 References: <14715.54336.634634.776495@korak.digicool.com> Message-ID: <20000724015500.A14548@thyrsus.com> Ken Manheimer : > I think people are sounding off too much, posing features and opinions > when they don't *need* to do so. People should think twice before > posing new python features - and hold off, a lot more of the time. OK, the recent discussion has been chaotic. But it's had two results I think are valuable. 1. We killed off a bad syntax (for parallel iterations) and replaced it with a clean builtin function that will genuinely add to the language without adding undue complications (zip). 2. The PEPs will direct, and perhaps make unnecessary, a lot of future discussion on language extensions. Even failed PEPs will be valuable if they show that certain propositions that look initially attractive can't be well defined or can't justify their complexity overhead. Personally, I also think the case for range literals has been made even if the other PEPs fail on various grounds. -- Eric S. Raymond A ``decay in the social contract'' is detectable; there is a growing feeling, particularly among middle-income taxpayers, that they are not getting back, from society and government, their money's worth for taxes paid. The tendency is for taxpayers to try to take more control of their finances .. -- IRS Strategic Plan, (May 1984) From bwarsaw at beopen.com Mon Jul 24 07:45:18 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 24 Jul 2000 01:45:18 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> <14715.45967.555713.668818@anthem.concentric.net> <397BBAF3.683DE578@prescod.net> Message-ID: <14715.55278.925626.187181@anthem.concentric.net> | def lookup( query ) | regex=$"${person.lastname},${person.firstname}: .*${query}=(\w+)" | .... So let me try to guess what you mean here. I really have no idea if I'm right. $"..." is some new type of syntax that says to do magic name lookup and interpolation when creating the string. person.lastname must be an attribute on some object bound to the variable `person'. Where does `person' come from? I guess you'd use the normal namespace rules, so if I saw this function in your code I'd have to assume that person appears in the globals (because putting it in builtins is bad form and I don't see it in the function's locals). But you really don't need any of that new magic stuff or new syntax (or is it a new string type?). The nugget of interesting new functionality here is that your doing attribute lookup inside a string interpolation, and /that/ might be a cool thing to have. E.g. def lookup(query): regex = '%(person.lastname)s,%(person.firstname)s: .*%(query)s=(\w+)' \ % vars() seems reasonable to me, and doesn't add nearly as much new or magical stuff as your example above. -Barry From tim_one at email.msn.com Mon Jul 24 08:18:55 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 24 Jul 2000 02:18:55 -0400 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > ... > ...with two major releases with only a few weeks in between, I'm > afraid we'll see the usual "do we really need this?" rule being > replaced with "what can we add to make sure people know there's > really a difference?". FWIW, and as I understand it, at one point in the negotiations with CNRI, the idea was raised (by them) that the only way to release Python 2.0 with a different license than CNRI's new 1.6 license was indeed to make major changes so that "people know there's really a difference". I don't know whether that still applies, but at the time it sure seemed to intensify Guido's sense of urgency about these proposals <0.9 wink>. > obviously, things with fancy names and existing patches are on > the top of that list :-( And, in most cases, not only fancy names and patches, but also years of favorable preceding discussion. In particular, none of the things you mentioned (list comprehensions, augumented assignments, range literals) is in any sense new, or has escaped being debated to death multiple times. The only new thing in the debates this year was a convincing argument that the syntax for lockstep "for" loops probably sucked. the-"do-we-need-this?"-parts-were-decided-before-ly y'rs - tim From moshez at math.huji.ac.il Mon Jul 24 08:38:12 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 24 Jul 2000 09:38:12 +0300 (IDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14715.44747.65722.305555@anthem.concentric.net> Message-ID: On Sun, 23 Jul 2000, Barry A. Warsaw wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> log.writeln("Post to ", listname, " from ", sender, " size=", > PP> len( msg )) > > That could work, if we added writeln() to all file-like objects. One > advantage of extending print is that the write() method is already a > documented (and existing) interface. No, this is an advantage for having "writeln" as a function rather then a method. > Isn't adding auto string-coercion a more radical suggestion than > extending print? Well, I'm not sure which one I fear more -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From paul at prescod.net Mon Jul 24 09:01:18 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 02:01:18 -0500 Subject: [Python-Dev] aargh References: <14715.54336.634634.776495@korak.digicool.com> Message-ID: <397BE9BE.14517764@prescod.net> Ken Manheimer wrote: > > ... > > Those of you offering lots of clever changes - what are you doing? Do > you really think they're all so important, or are you just pleased to > be finding neat little ideas? Everyone needs to hold out for what > they at least consider outstandingly important. Why? When did sharing ideas hurt anyone? If Guido likes them, he'll put them in. If he doesn't, we're wasting our own time. I think that trying to improve Python is a pretty good way to waste my time. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Mon Jul 24 09:23:30 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 02:23:30 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> <14715.45967.555713.668818@anthem.concentric.net> <397BBAF3.683DE578@prescod.net> <14715.55278.925626.187181@anthem.concentric.net> Message-ID: <397BEEF2.AF9E1C74@prescod.net> "Barry A. Warsaw" wrote: > > ... > The nugget of interesting new > functionality here is that your doing attribute lookup inside a string > interpolation, and /that/ might be a cool thing to have. Attribute lookup is just a special case of expressions. What if I needed to do a function call? *You* were the one that prompted me to think up this syntax (actually I probably remembered some it from some work Ping did years ago...) The original example had a function call in it. There is no nice way to integrate a function call (or method call) into ""%vars(). That's what gave rise this this: print >> log, 'post to %(listname)s from %(sender)s, size=%(msglen)s' % { 'listname': listname, 'sender' : sender, 'msglen' : len(msg), } It seems we're going around in circles, though. You were the one that said that the percent operator is inconvenient way back here: http://www.python.org/pipermail/python-dev/2000-July/013837.html I think you were right back then! Also, I agree with Tim that what we have is great for all kinds of corner cases but a pain for a lot of the common ones. Other minor problems include: 1. "Why do I have to say the s in %()s when I'm using the s formatting code 97.68% of the time?" I shouldn't need to. To me, the s looks like a pluralization of listname and sender. A template should have clear delimiters so that it is straightforward to read. 2. "Why do I have to tell it what namespace to evaluate in when 93.5% of the time, it's vars()?" Anyhow, you may be right that a less severe change is possible. I went with the dollar sign syntax because a) it is very much like many other languages that many programmers have used and b) because it didn't have the backwards compatibility issues of trying to stay compatible with printf (especially that trailing-s thing). -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From ping at lfw.org Mon Jul 24 11:13:42 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 24 Jul 2000 02:13:42 -0700 (PDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <397BA5ED.D3C33699@prescod.net> Message-ID: On Sun, 23 Jul 2000, Paul Prescod wrote: > As happy as I am to have it called Prescod-ese, I admit to influence > from some languages that (otherwise) suck. :) I agree that formatting and interpolation is one area where Perl is much stronger, and it should be easy to do such things in Python. > credit-where-due 'ly yrs I kind of hate to do this, but i can't restrain myself from pointing out that i *did* propose just this solution quite recently, in: http://www.python.org/pipermail/python-dev/2000-July/012764.html I wrote a module to do this a few years ago (1996, i think). It supported attribute lookup, item lookup, and expressions. (No one has yet mentioned the issue of escaping the dollar sign, which i handled by doubling it.) See the exact rules described, with examples, at http://www.lfw.org/python/Itpl.html If you want to play, just download http://www.lfw.org/python/Itpl15.py and try the itpl() function in the module. I would be quite pleased if (for example) $"" performed the equivalent of a function call to itpl() on the enclosed string. Apologetically (& only *gently* indignant), -- ?!ng From fredrik at pythonware.com Mon Jul 24 11:18:33 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 24 Jul 2000 11:18:33 +0200 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: Message-ID: <00cd01bff550$244f9f90$0900a8c0@SPIFF> tim wrote: > > obviously, things with fancy names and existing patches are on > > the top of that list :-( > > And, in most cases, not only fancy names and patches, but also years of > favorable preceding discussion. In particular, none of the things you > mentioned (list comprehensions, augumented assignments, range literals) is > in any sense new, or has escaped being debated to death multiple times. yeah, but what concerns me here is that we're talking about a release within 4-6 weeks, but we don't even have all the PEPs in place... ::: I cannot really comment on the list comprehension syntax since the PEP isn't there yet, but if I remember the syntax correctly, maybe "list confusions" is a better name than "list comprehensions". I surely don't understand them... "execute a piece of code and do something magic with the result of the last expression"? The lambda syntax is bad enough (it should really support an optional "return"), and I'd rather not see more of that... makes me think of nasty C bugs (and Perl, but that's another story). I'm somewhere between -1 and -0 on this one; I would very much prefer if we left that one out for 2.1, and considered adding real blocks instead. ::: The augumented assignment proposal is okay. I've never seen this as a real problem -- if I find myself writing: somethingverylong = somethingverylong + 1 there's probably a design flaw somewhere. But they're easy to read and grok -- even if you haven't used C or Java before, it's pretty clear from context what they're doing. I'm +0 on this one. ::: The range literal syntax is questionable; the proposal claims that the advantages are: "clarity of purpose" -- really? I'd say it's far from clear that slices really are the same thing as integer lists. They're also somewhat hard to read... "efficiency" -- sorry, but this a bogus argument. it's perfectly possible to do this optimization in the interpreter (a method caching interpreter could for example treat for/in/range as a method of the local namespace) "consistency" -- this is basically the first argument once again, claiming that it's "logical" that ranges and slices are the same thing. I'm not so sure... I'm -0 on this one. Changing it to require a "subject" for the slicing (e.g. int[0:10]) would make me +0. ::: I'm also beginning to like Barry's ">> file" proposal. It's like the augumented assignment syntax -- it's easy to understand what it's doing when you see it in context. (it really should be "print #file", of course ;-) ::: finally, based on the title along, I'm totally +1 on PEP-209. From nhodgson at bigpond.net.au Mon Jul 24 12:13:00 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Mon, 24 Jul 2000 20:13:00 +1000 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: <00cd01bff550$244f9f90$0900a8c0@SPIFF> Message-ID: <039101bff557$bf947280$8119fea9@neil> > The augumented assignment proposal is okay. I've never seen this > as a real problem -- if I find myself writing: This is the third time I've seen this misspelling on the list. Is the collective Python subconscious trying to morph "augmented assignments" into "argumented assignments"? Neil From peter at schneider-kamp.de Mon Jul 24 14:40:31 2000 From: peter at schneider-kamp.de (Peter Schneider-Kamp) Date: Mon, 24 Jul 2000 12:40:31 +0000 Subject: [Python-Dev] Re: Variables in strings.. References: <81324605608.20000724121203@buz.ch> Message-ID: <397C393F.E4AFEBB4@schneider-kamp.de> Gabriel Ambuehl wrote: > > print "Hello $name" > would do the job. Now the only solution I could find in Python was > this awful > print "Hello %(name)s" % var() There is of course: print "Hello", name print "Hello", name[1] But that is probably not what you ask for. There is a thread about extending the print statement right now at the python-dev mailing list: http://www.python.org/pipermail/python-dev/2000-July/thread.html Part of this thread deals with what you are looking for. You may want to read the whole thread, but a good point to start is Tim's first post in that subthread: http://www.python.org/pipermail/python-dev/2000-July/013895.html > syntax which, after all, doesn't even seem to support lists as > print "Hello %(name[1])s" % var() > just raises a KeyError. May anyone point me to some more comfortable > ways than just endless concatenation of strings and lists which doesn't really > help for readibility (which is one of the main points why I'm > switching from Perl to Python)? As far as I have understood matters, the $name $(name[1]) syntax woul be able to do what you want. But then I have not really followed that thread closely. Peter P.S.: To python-dev: Wouldn't it be better to discuss this on python-list (or pep-dev)? -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From mal at lemburg.com Mon Jul 24 12:53:27 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 12:53:27 +0200 Subject: [Python-Dev] string formatting (extended print statement, uPre-PEP) References: Message-ID: <397C2027.CE8D411B@lemburg.com> Ka-Ping Yee wrote: > > On Sun, 23 Jul 2000, Paul Prescod wrote: > > As happy as I am to have it called Prescod-ese, I admit to influence > > from some languages that (otherwise) suck. :) > > I agree that formatting and interpolation is one area where Perl is > much stronger, and it should be easy to do such things in Python. > > > credit-where-due 'ly yrs > > I kind of hate to do this, but i can't restrain myself from pointing > out that i *did* propose just this solution quite recently, in: > > http://www.python.org/pipermail/python-dev/2000-July/012764.html > > I wrote a module to do this a few years ago (1996, i think). It > supported attribute lookup, item lookup, and expressions. (No one > has yet mentioned the issue of escaping the dollar sign, which i > handled by doubling it.) > > See the exact rules described, with examples, at > > http://www.lfw.org/python/Itpl.html > > If you want to play, just download > > http://www.lfw.org/python/Itpl15.py > > and try the itpl() function in the module. > > I would be quite pleased if (for example) $"" performed the > equivalent of a function call to itpl() on the enclosed string. Any reason this can't be emulated using the existing "..." % mapping syntax ? You'd just have to provide a smart mapping which evaluates the %(something)s tags in the format string to a string ready for insertion... something may even contain balanced parenthesis, so even function calls are within range. Note that a = 1 b = 2 print "We have %(a)s apples and %(b)s oranges" % locals() is already possible today without any additional magic. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Mon Jul 24 12:57:40 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 24 Jul 2000 03:57:40 -0700 Subject: [Python-Dev] Re: Feature bloat in Python In-Reply-To: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jul 23, 2000 at 10:12:38AM +0200 References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> Message-ID: <20000724035739.J10898@lyra.org> On Sun, Jul 23, 2000 at 10:12:38AM +0200, Fredrik Lundh wrote: > mark wrote: > > If you can't quickly and quietly win this friendly audience over, IMO the > > proposal has failed. If any proposal causes even a small thread on this > > forum that boils down to "but its not clear to me what this should do", > > then I would have thought it self-evident that the proposal sucks. > > Convincing us that it _should_ be obvious if only we were all a little > > brighter and more willing to accept change for changes sake doesn't > > help anyone, least of all the person making these statements > > from the new Tcl Code Team rules: > > "A project can also be proposed by someone outside the Tcl Core > Team, but it can't be approved without an advocate on the Tcl > Core Team who will take personal responsibility for it. A project > must have support from at least 2 members of the Tcl Core Team > (including the proposer); if anyone in the Tcl Core Team objects > to the proposal, then there must be at least 4 members in favor > (including the proposer). If there are two or more "no" votes then > the proposal is rejected, regardless of the number of people in > favor. > > "The idea here is that the Tcl Core Team can only work effectively > if it is highly collegial; any project that generates significant contro- > versy should not go into the Tcl core." Compare/contrast to Apache: Big changes / non-bug fixes "require consensus approval before the change can be committed." "An action item requiring consensus approval must receive at least 3 binding +1 votes and no vetos." Apache requires at least one maintainer for any code in the distro (sounds like Tcl will also require one). Changes require (3) people to agree/approve them (Tcl appears to say 2, unless a veto arrives and makes it 4). Vetos are very harsh in Apache and can be made and held (forever) by a *single* person. Most vetos occur simply because a particular patch/commit has some repercussion that the author didn't see, or there is an obviously "better" (for your particular definition of "better") way to do the thing. But a veto is also quite permanent, binding, and respected. As a result, Apache does tend to be cooperative to avoid vetoes on designs, but they do happen. Something that Mark didn't seem to make clear (but I believe he intended): If we have problems understanding how something will work, then how can we possibly expect it will be understood by Python users who (almost by definition of their absence on this list) have less experience with Python than we do? or: If it isn't obvious to us, then it will be opaque to the majority of users. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Mon Jul 24 14:51:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 07:51:02 -0500 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: Your message of "Sun, 23 Jul 2000 20:55:10 -0400." References: Message-ID: <200007241251.HAA14668@cj20424-a.reston1.va.home.com> All questions asked in this thread so far were answered correctly by Tim Peters. I'm only happy with the new license insofar as it represents a consensus between CNRI, the members of the Python Consortium and OSI that was very hard to reach. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Mon Jul 24 14:48:39 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 24 Jul 2000 14:48:39 +0200 Subject: [Python-Dev] ANSIfication problems: warnings in marshal.c In-Reply-To: ; from moshez@math.huji.ac.il on Mon, Jul 24, 2000 at 08:21:03AM +0300 References: Message-ID: <20000724144839.B266@xs4all.nl> On Mon, Jul 24, 2000 at 08:21:03AM +0300, Moshe Zadka wrote: > On Sun, 23 Jul 2000, Tim Peters wrote: > > At the O'Reilly conference, it was announced that the Perl rewrite in C++ > > (codenamed Topaz) has been abandoned. I didn't attend that session, but my > > impression from others is that they attempted to model Perl objects directly > > by C++ objects, and were frustrated by the consequent lack of low-level > > control. > As another data-point, I've heard from reliable sources that Topaz was > written to use bleeding edge C++, including all manners of weird > templates. > C++ I might be able to live with, but a very least common denominator C++ > -- otherwise you hurt the well-known Python portability, which is a major > strength. Tim himself stated that himself, in the very mail you half-quoted ;) C++ has some nice features, and it has a lot of (IMHO) not very nice features. Though I have to admit I'm not that up to speed in C++ features, I have seen C++ code do things that scared me shitless. They also have me wondering how efficient the generated code can be. Using C++ will hurt portability regardless, though. Not only because there are less C++ compilers than C compilers, but also because less people know C++ than C, and the *act* of porting gets harder. However, I do see some merit in making the current code compilable for a C++ compiler, and perhaps offering some extentions in the form of templates or such like Tim suggested. I haven't looked at that CXX thing, though, and I don't know if it (or direct extention code written C++) would benifit from a C++-compilable Python. In the mean time, it helps finding old prototype-less functions ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From fredrik at pythonware.com Mon Jul 24 15:02:04 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 24 Jul 2000 15:02:04 +0200 Subject: [Python-Dev] Evolving Python (was Re: Feature bloat in Python ...) References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> Message-ID: <01c201bff56f$5daf0770$0900a8c0@SPIFF> barry wrote: > I'm beginning to think that our role on python-dev is different than > we thought. I think for a particular proposal for a new language > feature, or core language functionality, it is our job to explore the > details and ramifications as much as possible. if this is true, I really want a separate list for those of us who'd rather work on improving the implementation and the standard library. after all, adding more syntactic fl^H^Hstuff isn't the only way to improve Python... (and I'm pretty sure it's not the best way to improve it, either) From skip at mojam.com Mon Jul 24 15:50:22 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 24 Jul 2000 08:50:22 -0500 (CDT) Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <00cd01bff550$244f9f90$0900a8c0@SPIFF> References: <00cd01bff550$244f9f90$0900a8c0@SPIFF> Message-ID: <14716.18846.944097.966109@beluga.mojam.com> Fredrik> I cannot really comment on the list comprehension syntax since Fredrik> the PEP isn't there yet, but if I remember the syntax Fredrik> correctly, maybe "list confusions" is a better name than "list Fredrik> comprehensions". I surely don't understand them... Let me take a crack at explaining list comprehensions one more time. There is a patch available to play with, btw: https://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470 As current implemented (which is probably not precisely what people have been talking about), a list comprehension is simply a create a new list from one or more other lists to new using a series of constraint expressions. Working through some simple examples from the modified test_grammar.py: * multiplying a list by a constant... >>> nums = [1,2,3,4,5] >>> print [3*x for x in nums] [3, 6, 9, 12, 15] You can read this as, "for all values 3x such that x is in nums". * selecting a subset of a list... >>> print [x for x in nums if x > 2] [3, 4, 5] You can read this as, "for all values x such that x is in nums and x is greater than 2". * combining two lists... >>> strs = ["Apple", "Banana", "Coconut"] >>> print [i, s for i in nums for s in strs] [(1, 'Apple'), (1, 'Banana'), (1, 'Coconut'), (2, 'Apple'), (2, 'Banana'), (2, 'Coconut'), (3, 'Apple'), (3, 'Banana'), (3, 'Coconut'), (4, 'Apple'), (4, 'Banana'), (4, 'Coconut'), (5, 'Apple'), (5, 'Banana'), (5, 'Coconut')] You can read this as, "for all pairs (i,s) such that i is in nums and s is in strs". * nesting list comprehensions ... >>> print [i, s for i in nums for s in [f for f in strs if "n" in f]] [(1, 'Banana'), (1, 'Coconut'), (2, 'Banana'), (2, 'Coconut'), (3, 'Banana'), (3, 'Coconut'), (4, 'Banana'), (4, 'Coconut'), (5, 'Banana'), (5, 'Coconut')] You can read this as, "for all pairs (i,s) such that is is in nums as s is in the subset of nums that contains the letter 'n'". I don't think it's so different than the notation mathematicians use to describe and build sets. We don't have the luxury of convenient glyphs that mean "there exists" and "for all", however. As has been pointed out, the syntax is constrained by the demands of the current parser and preexisting expression syntax. For instance, we can't currently put "and" between the different clauses to clearly indicate that we are not nesting for statements without creating ambiguities. I don't know, perhaps that's simply an argument for stronger parsing technology for Python. If so, and a stronger parser would allow a more readable implementation of list comprehensions, I'd be in favor of delaying their introduction until such a parser was in place. I'm not the person to make the decisions about a new parser. Would (for example) a yacc/bison and lex/flex based parser be completely out of the question in the 2.1 to 2.2 timeframe? Would it allow a more expressive grammar? What portability issues would be involved? Skip From skip at mojam.com Mon Jul 24 16:09:45 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 24 Jul 2000 09:09:45 -0500 (CDT) Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) In-Reply-To: <14716.18846.944097.966109@beluga.mojam.com> References: <00cd01bff550$244f9f90$0900a8c0@SPIFF> <14716.18846.944097.966109@beluga.mojam.com> Message-ID: <14716.20009.223815.39832@beluga.mojam.com> me> ... a list comprehension is simply a create a new list ... should be ... a list comprehension is simply a way to create a new list ... Also, in me> We don't have the luxury of convenient glyphs that mean "there me> exists" and "for all", however. I should have included "such that". It has, indeed, been a few years since I cracked a math book of any kind... ;-) Skip From jim at interet.com Mon Jul 24 16:20:16 2000 From: jim at interet.com (James C. Ahlstrom) Date: Mon, 24 Jul 2000 10:20:16 -0400 Subject: [Python-Dev] aargh References: <14715.54336.634634.776495@korak.digicool.com> Message-ID: <397C50A0.F63E7E8D@interet.com> Ken Manheimer wrote: > thinking that (1) i'm glad i'm not in guido's place, and (2) geeze, > aren't we making guido job harder, not easier? > I think people are sounding off too much, posing features and opinions > when they don't *need* to do so. People should think twice before > posing new python features - and hold off, a lot more of the time. > Treat every single thing you propose as if it costs something > significant - because it does! Way to go Ken!! I couldn't agree more!! No one can object to trying to improve Python. But there is insufficient fear and loathing of feature bloat and complexity. Members of this group are smart and can easily handle advanced features, but the same can not be said of c.l.p nor application programmers in general. Excess advanced features will hamper widespread acceptance of Python. JimA From akuchlin at mems-exchange.org Mon Jul 24 16:20:26 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 24 Jul 2000 10:20:26 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: ; from tim_one@email.msn.com on Sat, Jul 22, 2000 at 01:41:03PM -0400 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> Message-ID: <20000724102026.A4196@kronos.cnri.reston.va.us> On Sat, Jul 22, 2000 at 01:41:03PM -0400, Tim Peters wrote: >since 1.5.2 was released to the public". The great recent burst of >Python-Dev activity in the CVS tree was not done at CNRI, or the bulk of it >even by people with any connection present or past to CNRI. The problem there is Unicode support, which has changed quite a bit since that time -- the default encoding, if nothing else. 1.6 will probably need to have Unicode disabled, or have support that's incompatible with 2.0, or someone will have to backport the current code to 1.6. (Better you guys than me, though...) --amk From akuchlin at mems-exchange.org Mon Jul 24 16:25:17 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 24 Jul 2000 10:25:17 -0400 Subject: [Python-Dev] Evolving Python In-Reply-To: <01c201bff56f$5daf0770$0900a8c0@SPIFF>; from fredrik@pythonware.com on Mon, Jul 24, 2000 at 03:02:04PM +0200 References: <005801bff47e$3f9eeda0$f2a6b5d4@hagrid> <14715.42220.655527.947800@anthem.concentric.net> <01c201bff56f$5daf0770$0900a8c0@SPIFF> Message-ID: <20000724102517.B4196@kronos.cnri.reston.va.us> On Mon, Jul 24, 2000 at 03:02:04PM +0200, Fredrik Lundh wrote: >if this is true, I really want a separate list for those of us who'd >rather work on improving the implementation and the standard >library. Seconded. There's lots of unsexy but useful stuff to be done simply making the core distribution a bit more solid or a bit faster, the demos a bit more up-to-date, the docs a bit more complete, &c. I think that part of my dislike of new language features stems from the redirection of effort away from such basic tasks. Can hardly wait until PEP-related discussion finds its new home, whether on c.l.p or on a pep-dev list. --amk From fdrake at beopen.com Mon Jul 24 16:33:54 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 24 Jul 2000 10:33:54 -0400 (EDT) Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724102026.A4196@kronos.cnri.reston.va.us> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> Message-ID: <14716.21458.361479.350602@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > The problem there is Unicode support, which has changed quite a bit And CNRI did handle the contracting for the Unicode support, so it's reasonable for it to be in there. But I wasn't at the consortium meeting, so don't know if any specific technical decisions were made there (I'd expect not). I was trapped on an airplane high above the earth, locked in battle with a recent version of LaTeX2HTML. ;( -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nowonder at pool.informatik.rwth-aachen.de Mon Jul 24 19:26:06 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Mon, 24 Jul 2000 17:26:06 +0000 Subject: [Python-Dev] object allocator References: <200007211227.OAA04028@python.inrialpes.fr> Message-ID: <397C7C2E.44DCBA39@pool.informatik.rwth-aachen.de> Hei Vladimir! I have taken the liberty to submit your obmalloc.c as a patch on SourceForge. I have done this to make it easier for others to try it. It should build out of the box. > All this needs to be pursued, probably PEP'ed, but I think I can > already emit my opinion about a compromise: Let's wait with PEP'ing until there has been at least some discussion. > That said, it would be nice if you could test this code on your combos > and report some results and impressions back here. Right now I can only say that it runs fine on SuSE Linux 6.4. Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From bwarsaw at beopen.com Mon Jul 24 17:30:47 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 24 Jul 2000 11:30:47 -0400 (EDT) Subject: [Python-Dev] extended print statement, uPre-PEP References: <14713.10084.165489.836569@anthem.concentric.net> <3979B599.7274105C@prescod.net> <14713.64973.585633.87443@anthem.concentric.net> <397A007F.CF8DEBE2@prescod.net> <14714.39334.615638.738713@anthem.concentric.net> <397B0AC8.C6780D33@prescod.net> <14715.45967.555713.668818@anthem.concentric.net> <397BBAF3.683DE578@prescod.net> <14715.55278.925626.187181@anthem.concentric.net> <397BEEF2.AF9E1C74@prescod.net> Message-ID: <14716.24871.915663.693288@anthem.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> 1. "Why do I have to say the s in %()s when I'm using the s PP> formatting code 97.68% of the time?" I shouldn't need to. To PP> me, the s looks like a pluralization of listname and sender. A PP> template should have clear delimiters so that it is PP> straightforward to read. PP> 2. "Why do I have to tell it what namespace to evaluate in PP> when 93.5% of the time, it's vars()?" >>>>> "KY" == Ka-Ping Yee writes: KY> I kind of hate to do this, but i can't restrain myself from KY> pointing out that i *did* propose just this solution quite KY> recently, in: KY> http://www.python.org/pipermail/python-dev/2000-July/012764.html KY> I wrote a module to do this a few years ago (1996, i think). KY> It supported attribute lookup, item lookup, and expressions. KY> (No one has yet mentioned the issue of escaping the dollar KY> sign, which i handled by doubling it.) I think I've been lulled into conflating two different issues. As I see it doing the interpolation is separate from where the output goes, however it's clear that ?!ng's printpl() function could grow the optional keyword arguments that Moshe suggested. Still, I think it makes sense for them to be two separate proposals (with cross references if necessary). I've decided to PEP the extended print syntax and would be more than happy to assign a PEP number for a string interpolation proposal, if someone else volunteers to champion it. -Barry From mal at lemburg.com Mon Jul 24 17:28:36 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 17:28:36 +0200 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> Message-ID: <397C60A4.A4A9513C@lemburg.com> Andrew Kuchling wrote: > > On Sat, Jul 22, 2000 at 01:41:03PM -0400, Tim Peters wrote: > >since 1.5.2 was released to the public". The great recent burst of > >Python-Dev activity in the CVS tree was not done at CNRI, or the bulk of it > >even by people with any connection present or past to CNRI. > > The problem there is Unicode support, which has changed quite a bit > since that time -- the default encoding, if nothing else. 1.6 will > probably need to have Unicode disabled, or have support that's > incompatible with 2.0, or someone will have to backport the current > code to 1.6. (Better you guys than me, though...) Hmm, why shouldn't it be possible to use the current version of Unicode support in 1.6 ? AFAIK, most of the patching was done by Fredrik and myself and we were not related to CNRI or BeOpen in any way at the time of the move to BeOpen. Wouldn't it suffice for Fredrik and me to send in a wet-sign for the Unicode patches since that date ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 24 17:39:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 17:39:53 +0200 Subject: [Python-Dev] Python CVS License ? Message-ID: <397C6349.7B441A80@lemburg.com> I was wondering what the license terms are for the current CVS snapshot... There's a lot of code in there which carries its own license or copyright, e.g. the Unicode stuff still only has the note "(c) Copyright CNRI, All Rights Reserved. NO WARRANTY." and the SRE modules are "Copyright (c) 1997-2000 by Secret Labs AB. All rights reserved.". As it stands, I guess the current CVS tree is not legally copyable or usable by anyone who wants decent Unicode support. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Mon Jul 24 22:13:10 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 15:13:10 -0500 Subject: [Python-Dev] Re: Feature bloat in Python (was some PEP thing!) References: <00cd01bff550$244f9f90$0900a8c0@SPIFF> Message-ID: <397CA356.4CF1F82B@prescod.net> Fredrik Lundh wrote: > >... > > yeah, but what concerns me here is that we're talking about a > release within 4-6 weeks, but we don't even have all the PEPs > in place... I do not believe it is a goal to implement all PEP-ed features in Python 2.0. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Mon Jul 24 18:17:47 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 11:17:47 -0500 Subject: [Python-Dev] Sorry Message-ID: <397C6C2B.ED72DF2F@prescod.net> I hate to bring up the zip name thing again but I'm strongly leaning toward something of the form: mktuples maketuples totuples gentuples tupleorama -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From Jasbahr at origin.EA.com Mon Jul 24 19:07:58 2000 From: Jasbahr at origin.EA.com (Asbahr, Jason) Date: Mon, 24 Jul 2000 12:07:58 -0500 Subject: [Python-Dev] Python Consortium Meeting News Message-ID: <11A17AA2B9EAD111BCEA00A0C9B4179305CB54FC@molach.origin.ea.com> Depending on the release schedule for 2.0, we may have to ship our product with Python 1.6, and Unicode is one of the key features we need from this release. I hope Marc is right that the current version of the Unicode support can be incorporated into the 1.6 official release. Cheers, Jason Asbahr Origin Systems, Inc. jasbahr at origin.ea.com -----Original Message----- From: M.-A. Lemburg [mailto:mal at lemburg.com] Sent: Monday, July 24, 2000 10:29 AM To: akuchlin at mems-exchange.org Cc: python-dev at python.org Subject: Re: [Python-Dev] Python Consortium Meeting News Andrew Kuchling wrote: > > On Sat, Jul 22, 2000 at 01:41:03PM -0400, Tim Peters wrote: > >since 1.5.2 was released to the public". The great recent burst of > >Python-Dev activity in the CVS tree was not done at CNRI, or the bulk of it > >even by people with any connection present or past to CNRI. > > The problem there is Unicode support, which has changed quite a bit > since that time -- the default encoding, if nothing else. 1.6 will > probably need to have Unicode disabled, or have support that's > incompatible with 2.0, or someone will have to backport the current > code to 1.6. (Better you guys than me, though...) Hmm, why shouldn't it be possible to use the current version of Unicode support in 1.6 ? AFAIK, most of the patching was done by Fredrik and myself and we were not related to CNRI or BeOpen in any way at the time of the move to BeOpen. Wouldn't it suffice for Fredrik and me to send in a wet-sign for the Unicode patches since that date ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ _______________________________________________ Python-Dev mailing list Python-Dev at python.org http://www.python.org/mailman/listinfo/python-dev From guido at beopen.com Mon Jul 24 18:45:30 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 11:45:30 -0500 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: Your message of "Mon, 24 Jul 2000 17:28:36 +0200." <397C60A4.A4A9513C@lemburg.com> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> Message-ID: <200007241645.LAA15974@cj20424-a.reston1.va.home.com> > Hmm, why shouldn't it be possible to use the current > version of Unicode support in 1.6 ? AFAIK, most of the patching > was done by Fredrik and myself and we were not related to > CNRI or BeOpen in any way at the time of the move to BeOpen. I would expect that untangling the patches from the ANSIfication would be too much work. I'm not too interested in doing that. > Wouldn't it suffice for Fredrik and me to send in a wet-sign > for the Unicode patches since that date ? I suppose so (but I can't speak for CNRI any more). One possibility, if there are people interested in helping out with 1.6, would be to create a branch on SF. But since this needs to be a branch relative to an old version, I'm not sure exactly how to do that. (The problem with checking out by date is that CVS gives you all the *deleted* files back, even if they were deleted at the selected date. Sigh.) Regarding incompatibilities between 1.6 and 2.0: we can simply mark the Unicode support in 1.6 as experimental, and announce that relying on the default conversion beyond ASCII in 1.6 causes forward compatibility problems. I plan to release 2.0 pretty soon after 2.0! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Mon Jul 24 18:47:34 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 11:47:34 -0500 Subject: [Python-Dev] Python CVS License ? In-Reply-To: Your message of "Mon, 24 Jul 2000 17:39:53 +0200." <397C6349.7B441A80@lemburg.com> References: <397C6349.7B441A80@lemburg.com> Message-ID: <200007241647.LAA15998@cj20424-a.reston1.va.home.com> > I was wondering what the license terms are for the current > CVS snapshot... > > There's a lot of code in there which carries > its own license or copyright, e.g. the Unicode stuff still > only has the note "(c) Copyright CNRI, All Rights Reserved. > NO WARRANTY." and the SRE modules are "Copyright (c) 1997-2000 by > Secret Labs AB. All rights reserved.". > > As it stands, I guess the current CVS tree is not legally > copyable or usable by anyone who wants decent Unicode support. And that's probably a good thing. It's a development tree -- please don't make releases of it! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From paul at prescod.net Mon Jul 24 18:09:58 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 24 Jul 2000 11:09:58 -0500 Subject: [Python-Dev] extended print statement, uPre-PEP References: Message-ID: <397C6A56.389B56CC@prescod.net> Ka-Ping Yee wrote: > > On Sun, 23 Jul 2000, Paul Prescod wrote: > > As happy as I am to have it called Prescod-ese, I admit to influence > > from some languages that (otherwise) suck. :) > > I agree that formatting and interpolation is one area where Perl is > much stronger, and it should be easy to do such things in Python. > > > credit-where-due 'ly yrs > > I kind of hate to do this, but i can't restrain myself from pointing > out that i *did* propose just this solution quite recently, in: > > http://www.python.org/pipermail/python-dev/2000-July/012764.html Sorry, for whatever reason I didn't actually read that message. It's sitting in the middle of a bunch of other messages I have marked as unread. You're right, you definately get credit for the idea and I'll let you take the flames when we introduce it to comp.lang.python. :) Why don't you PEP it? -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From thomas at xs4all.net Mon Jul 24 18:10:49 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 24 Jul 2000 18:10:49 +0200 Subject: [Python-Dev] ANSIfication. In-Reply-To: <397AE4F4.E1A9DDE0@lemburg.com>; from mal@lemburg.com on Sun, Jul 23, 2000 at 02:28:36PM +0200 References: <20000723022452.Q9897@xs4all.nl> <397AE4F4.E1A9DDE0@lemburg.com> Message-ID: <20000724181049.C266@xs4all.nl> On Sun, Jul 23, 2000 at 02:28:36PM +0200, M.-A. Lemburg wrote: [ Me complaining about externs everywhere ] > I'd suggest doing this in two steps: > 1. move the externs to pyport.h (which is the right place for > these platform dependent defines and includes) and > add #if 0 ... #endif around them > 2. check whether these are still needed during the beta phase and > if no one complains remove the cruft completely > Alternatively, you could also add specific platform dependent > #ifdefs to pyport.h which only enable the externs on those > platforms where they are needed. I did a bit of both. Those that already had a proper platform #ifdef or comment, I left in. The others are moved into a #if 0 block. If noone objects to the current setup, I'll start moving around the rest, too. If anyone has access to BeOS, Solaris and/or SGI, please try to see if the decls are really necessary, still :P Those are the 'unchecked' ones I included. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein at lyra.org Mon Jul 24 21:30:54 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 24 Jul 2000 12:30:54 -0700 Subject: [Python-Dev] [jon@latchkey.com: [ANNOUNCE] Jakarta-ORO Project] Message-ID: <20000724123054.W10898@lyra.org> The Java ORO stuff is now under the Apache Software Foundation license. I'm posting here because the licensing of the ORO stuff came up at the Consortium meeting the other day re: its inclusion in JPython. Information is available at The Apache Jakarta project also has a lighter weight regexp engine under the ASF license (depending on how much "stuff" is needed). Info at Please forward to the JPython lists as appropriate. Cheers, -g ----- Forwarded message from Jon Stevens ----- Reply-To: members at apache.org Date: Mon, 24 Jul 2000 12:07:05 -0700 Subject: [ANNOUNCE] Jakarta-ORO Project From: Jon Stevens To: just keeping you all in the loop. push yet another project onto the stack. :-) -jon ---------- From: Jon Stevens Reply-To: general at jakarta.apache.org Date: Mon, 24 Jul 2000 11:49:36 -0700 To: Cc: "Daniel F. Savarese" Subject: [ANNOUNCE] Jakarta-ORO Project Hey All, Thanks to a generous code donation by Daniel F. Savarese, we now have a full featured regex package for Java under a BSD/Apache license. "The Jakarta-ORO Java classes are a set of text-processing Java classes that provide Perl5 compatible regular expressions, AWK-like regular expressions, glob expressions, and utility classes for performing substitutions, splits, filtering filenames, etc. This library is the successor to the OROMatcher, AwkTools, PerlTools, and TextTools libraries from ORO, Inc. (www.oroinc.com). They have been donated to the Jakarta Project by Daniel Savarese (www.savarese.org), the copyright holder of the ORO libraries. Daniel will continue to participate in their development under the Jakarta Project." Come and get it: -jon ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/ From ping at lfw.org Mon Jul 24 20:48:04 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 24 Jul 2000 11:48:04 -0700 (PDT) Subject: [Python-Dev] extended print statement, uPre-PEP In-Reply-To: <14716.24871.915663.693288@anthem.concentric.net> Message-ID: On Mon, 24 Jul 2000, Barry A. Warsaw wrote: > Still, I think it makes sense for them to be two separate proposals > (with cross references if necessary). I've decided to PEP the > extended print syntax and would be more than happy to assign a PEP > number for a string interpolation proposal, if someone else volunteers > to champion it. Okay, i'll do it. -- ?!ng From barry at scottb.demon.co.uk Mon Jul 24 22:38:15 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Mon, 24 Jul 2000 21:38:15 +0100 Subject: [Python-Dev] if/else and macros In-Reply-To: <20000717023950.E29590@lyra.org> Message-ID: <000001bff5af$17dffb60$060210ac@private> > > > ! #define UTF8_ERROR(details) \ > > > ! if (1) { \ > > > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > > > ! goto onError; \ > > > ! continue; \ > > > ! } else Try defining the macro this way: #define UTF8_ERROR(details) \ do { \ if (utf8_decoding_error(&s, &p, errors, (details))) \ goto onError; \ continue; \ } while(0) BArry From guido at beopen.com Mon Jul 24 22:00:39 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 15:00:39 -0500 Subject: [Python-Dev] "Michael Bryan Becraft": Brainbench Test in Python Message-ID: <200007242000.PAA17136@cj20424-a.reston1.va.home.com> Anyone interested? Please write directly to him. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------- Forwarded Message Date: Fri, 14 Jul 2000 13:31:23 -0400 From: "Michael Bryan Becraft" To: Subject: Brainbench Test in Python Dear sir, I am developing a test in Python 1.5 for assessing the skills of Python programmers, and wonder if anyone within your organisation would be interested in reviewing the test questions for us. I need at least one more reviewer, a task which generally takes 4-6 hours. The pay for the task would be $200 total (I realise that is not much), but would appreciate the input if there are any interested colleagues. If anyone is interested in what we do with online certifications, they can register to take free tests at our site. Thanks for your time, Mike Becraft Michael Bryan Becraft Assessment Development Manager - Brainbench Telephone: (703) 437-7849 Facsimile: (703) 437-7801 http://www.brainbench.com mailto:michael.becraft at brainbench.com ------- End of Forwarded Message From jeremy at beopen.com Mon Jul 24 22:55:26 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 24 Jul 2000 16:55:26 -0400 (EDT) Subject: [Python-Dev] Sorry In-Reply-To: <397C6C2B.ED72DF2F@prescod.net> References: <397C6C2B.ED72DF2F@prescod.net> Message-ID: <14716.44350.785087.111127@bitdiddle.concentric.net> Let's not discuss names on python-dev! Barry is writing the PEP on the subject. If you've got name ideas, send them to him. He can post of a summary of name discussions if it becomes an issue. Jeremy From bwarsaw at beopen.com Mon Jul 24 23:08:15 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 24 Jul 2000 17:08:15 -0400 (EDT) Subject: [Python-Dev] [jon@latchkey.com: [ANNOUNCE] Jakarta-ORO Project] References: <20000724123054.W10898@lyra.org> Message-ID: <14716.45119.543707.536193@anthem.concentric.net> >>>>> "GS" == Greg Stein writes: GS> The Java ORO stuff is now under the Apache Software Foundation GS> license. I'm posting here because the licensing of the ORO GS> stuff came up at the Consortium meeting the other day re: its GS> inclusion in JPython. Information is available at GS> Excellent. I knew this was going to happen and had been watching the Jakarta pages for it's public announcement. Thanks for posting about it. This and the release of JPython under the same license as CPython will mean an OSD compliant version of JPython without the silly dual licenses. I'm hoping this can all happen soon so we can move JPython development to SourceForge and start working on it again. GS> Please forward to the JPython lists as appropriate. | Cheers, Done, thanks. -Barry From effbot at telia.com Mon Jul 24 23:25:30 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 24 Jul 2000 23:25:30 +0200 Subject: [Python-Dev] [ Patch #100895 ] safe version of PyErr_Format Message-ID: <014501bff5b5$b4965520$f2a6b5d4@hagrid> not sure about the outcome here; should I go ahead and check it in? (properly ANSIfied, of course): http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From esr at thyrsus.com Mon Jul 24 23:40:19 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 17:40:19 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <200007241645.LAA15974@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 24, 2000 at 11:45:30AM -0500 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> Message-ID: <20000724174019.E31538@thyrsus.com> Guido van Rossum : > I plan to release 2.0 pretty soon after 2.0! Hm. I take it, then, that your time machine is back from the shop? -- Eric S. Raymond Sometimes the law defends plunder and participates in it. Sometimes the law places the whole apparatus of judges, police, prisons and gendarmes at the service of the plunderers, and treats the victim -- when he defends himself -- as a criminal. -- Frederic Bastiat, "The Law" From guido at beopen.com Tue Jul 25 00:35:53 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 17:35:53 -0500 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: Your message of "Mon, 24 Jul 2000 17:40:19 -0400." <20000724174019.E31538@thyrsus.com> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> Message-ID: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> > Guido van Rossum : > > I plan to release 2.0 pretty soon after 2.0! ESR > Hm. I take it, then, that your time machine is back from the shop? Argh. You know that I meant "after 1.6". Here's my current timeline (I'll post this on the web when we have access): - 1.6beta1 out around August 1 - 1.6final around August 15 - 2.0beta1 around August 30 - various betas - 2.0final around September 30 Obviously not every PEP will be included in 2.0. I plan on including these: zip(); list comprehensions; augmented assignments; range literals. Also whatever's in pep-0200. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Mon Jul 24 23:36:19 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 23:36:19 +0200 Subject: [Python-Dev] [ Patch #100895 ] safe version of PyErr_Format References: <014501bff5b5$b4965520$f2a6b5d4@hagrid> Message-ID: <397CB6D3.207B3599@lemburg.com> Fredrik Lundh wrote: > > not sure about the outcome here; should I go ahead > and check it in? (properly ANSIfied, of course): > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 +0 I would still like to see the snprintf() fallback solution somewhere in there, but what the heck... go ahead ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Tue Jul 25 00:47:52 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 24 Jul 2000 17:47:52 -0500 Subject: [Python-Dev] [ Patch #100895 ] safe version of PyErr_Format In-Reply-To: Your message of "Mon, 24 Jul 2000 23:25:30 +0200." <014501bff5b5$b4965520$f2a6b5d4@hagrid> References: <014501bff5b5$b4965520$f2a6b5d4@hagrid> Message-ID: <200007242247.RAA17840@cj20424-a.reston1.va.home.com> > not sure about the outcome here; should I go ahead > and check it in? (properly ANSIfied, of course): > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 I'm for it, but don't know of all the consequences. It would be helpful to create a test suite that triggered all the calls to PyErr_Format() that exist in the core. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From mal at lemburg.com Mon Jul 24 23:54:38 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jul 2000 23:54:38 +0200 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> Message-ID: <397CBB1E.D5AE9DF1@lemburg.com> Guido van Rossum wrote: > > Here's my current timeline > (I'll post this on the web when we have access): > > - 1.6beta1 out around August 1 > - 1.6final around August 15 > - 2.0beta1 around August 30 > - various betas > - 2.0final around September 30 > > Obviously not every PEP will be included in 2.0. I plan on including > these: zip(); list comprehensions; augmented assignments; range > literals. Also whatever's in pep-0200. How about adding XML support as the "Big New Feature" to 2.0 instead of 1.6 (if I remember correctly, XML was added after the BeOpen move, right) ? Not that I have anything against XML going into 1.6, but this would make the new version number a little more understandable. BTW, how rock solid is Python's builtin XML support ? I'm asking because I want to make our product XML aware and the various different parser implementations out there gave me a rather unsecure feeling about which one to go after... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Tue Jul 25 00:04:33 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 00:04:33 +0200 Subject: [Python-Dev] if/else and macros In-Reply-To: <000001bff5af$17dffb60$060210ac@private>; from barry@scottb.demon.co.uk on Mon, Jul 24, 2000 at 09:38:15PM +0100 References: <20000717023950.E29590@lyra.org> <000001bff5af$17dffb60$060210ac@private> Message-ID: <20000725000433.D266@xs4all.nl> On Mon, Jul 24, 2000 at 09:38:15PM +0100, Barry Scott wrote: > > > > ! #define UTF8_ERROR(details) \ > > > > ! if (1) { \ > > > > ! if (utf8_decoding_error(&s, &p, errors, (details))) \ > > > > ! goto onError; \ > > > > ! continue; \ > > > > ! } else > > Try defining the macro this way: > #define UTF8_ERROR(details) \ > do { \ > if (utf8_decoding_error(&s, &p, errors, (details))) \ > goto onError; \ > continue; \ > } while(0) That isn't going to work, and is the entire reason for the 'if' construction rather than the 'do {} while' one: the 'continue' applies to the innermost loop, the 'do {} while(0)', producing some decidedly unpredicted behaviour. Anyhow, I believe it's fixed more adequately now, or someone is going to ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Tue Jul 25 00:20:18 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 24 Jul 2000 18:20:18 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python Message-ID: <14716.49442.232191.940532@bitdiddle.concentric.net> I'm starting to work on PEP 200, the release schedule for 2.0. As part of that document, I'd like to write down some rules for contributing code to that release. I've come up with some guidelines based on the discussion we've had on python-dev since moving to SourceForge as well as some offline discussions at PythonLabs. I've included them below for comment and review. Once we have reached some agreement on what the rules should be, I'll add them to PEP 200 and check them in. Jeremy Use good sense when committing changes. You should know what we mean by good sense or we wouldn't have given you commit privileges <0.5 wink>. Some specific examples of good sense include: - Do whatever the dictator tells you. - Discuss any controversial changes on python-dev first. If you get a lot of +1 votes and no -1 votes, make the change. If you get a some -1 votes, think twice; consider asking Guido what he thinks. - If the change is to code you contributed, it probably makes sense for you to fix it. - If the change affects code someone else wrote, it probably makes sense to ask him or her first. - You can use the SF Patch Manager to submit a patch and assign it to someone for review. Any significant new feature must be described in a PEP and approved before it is checked in. Any significant code addition, such as a new module or large patch, MUST include test cases for the regression test and documentation. A patch should not be checked in until the tests and documentation are ready. If you fix a bug, you SHOULD write a test case that would have caught the bug. If you commit a patch from the SF Patch Manager or fix a bug from the Jitterbug database, be sure to reference the patch/bug number in the CVS log message. Also be sure to change the status in the patch manager or bug database. It is not acceptable for any checked in code to cause the regression test to fail. If a checkin causes a failure, it MUST be fixed within 24 hours or it will be backed out. All contributed C code MUST be ANSI C. If possible check it with two different compilers, e.g. gcc and MSVC. All contributed Python code MUST follow Guido's Python style guide. http://www.python.org/doc/essays/styleguide.html It is understood that any code contributed will be released under an Open Source license. Do not contribute code if it can't be released this way. From m.favas at per.dem.csiro.au Tue Jul 25 00:21:34 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Tue, 25 Jul 2000 06:21:34 +0800 Subject: [Python-Dev] Status of re...??? Message-ID: <397CC16E.89E1446B@per.dem.csiro.au> test_re has been failing (and not just failing, but failing incorrectly ) for some time now (test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou"). What's the future for re - is it planned to remove it from 2.0? -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From jeremy at beopen.com Tue Jul 25 00:30:44 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 24 Jul 2000 18:30:44 -0400 (EDT) Subject: [Python-Dev] Status of re...??? In-Reply-To: <397CC16E.89E1446B@per.dem.csiro.au> References: <397CC16E.89E1446B@per.dem.csiro.au> Message-ID: <14716.50068.826877.488769@bitdiddle.concentric.net> Good question! I'm at a complete loss about what's going on with the re module. There is no point in having a test that is supposed to fail, because it's impossible to tell the difference between an expected failure and an unexpected failure. I just proposed some guidelines for contributing code, which probably cross your message in transit, that included a guideline that no checked in code should cause the regression test to fail. If the problem is known SRE bugs, I think the re test should be temporarily changed to eliminate the known bugs. If SRE is later fixed, the test cases can be restored. What is the current schedule for fixing SRE? I need to know for the release schedule. Jeremy From m.favas at per.dem.csiro.au Tue Jul 25 00:36:05 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Tue, 25 Jul 2000 06:36:05 +0800 Subject: [Python-Dev] Failing regression tests... Message-ID: <397CC4D5.D6EC87E@per.dem.csiro.au> [Jeremy Hylton just wrote:] I just proposed some guidelines for contributing code, which probably cross your message in transit, that included a guideline that no checked in code should cause the regression test to fail. I know 64-bit platforms aren't mainstream (yet), but test_ucn has also been failing (test test_ucn crashed -- exceptions.UnicodeError : Unicode-Escape decoding error: Invalid Unicode Character Name) for quite a while now on these beasts. Bill Tutt proposed a patch, which Tim critiqued, while at the same time /F was producing another way of doing it , and... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From esr at thyrsus.com Tue Jul 25 01:09:35 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 19:09:35 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <200007242235.RAA17731@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Mon, Jul 24, 2000 at 05:35:53PM -0500 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> Message-ID: <20000724190935.G31538@thyrsus.com> Guido van Rossum : > > Guido van Rossum : > > > I plan to release 2.0 pretty soon after 2.0! > > ESR > > Hm. I take it, then, that your time machine is back from the shop? > > Argh. You know that I meant "after 1.6". Yes. But the joke was not resistible. > Here's my current timeline > (I'll post this on the web when we have access): > > - 1.6beta1 out around August 1 > - 1.6final around August 15 > - 2.0beta1 around August 30 > - various betas > - 2.0final around September 30 A timetable. Excellent. Now I know when I have to get my stuff done (curses docs, enhanced Berkeley DB support). > Obviously not every PEP will be included in 2.0. I plan on including > these: zip(); list comprehensions; augmented assignments; range > literals. Also whatever's in pep-0200. All this makes me happy, except that I'm a touch dubious about list comprehensions now. Still like the idea, still think the syntax ought to be clearer somehow. -- Eric S. Raymond "As to the species of exercise, I advise the gun. While this gives [only] moderate exercise to the body, it gives boldness, enterprise, and independence to the mind. Games played with the ball and others of that nature, are too violent for the body and stamp no character on the mind. Let your gun, therefore, be the constant companion to your walks." -- Thomas Jefferson, writing to his teenaged nephew. From mal at lemburg.com Tue Jul 25 01:05:20 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 25 Jul 2000 01:05:20 +0200 Subject: [Python-Dev] Failing regression tests... References: <397CC4D5.D6EC87E@per.dem.csiro.au> Message-ID: <397CCBB0.A8D7F6DC@lemburg.com> Mark Favas wrote: > > [Jeremy Hylton just wrote:] > I just proposed some guidelines for contributing code, which probably > cross your message in transit, that included a guideline that no > checked in code should cause the regression test to fail. > > I know 64-bit platforms aren't mainstream (yet), but test_ucn has also > been failing (test test_ucn crashed -- exceptions.UnicodeError : > Unicode-Escape decoding error: Invalid Unicode Character Name) for quite > a while now on these beasts. Bill Tutt proposed a patch, which Tim > critiqued, while at the same time /F was producing another way of doing > it , and... The patch is there on SF... but AFAIK, Fredrik has not yet finished work on it. I would rather like to see /Fs new module in the distribution because of its reduced size. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Tue Jul 25 01:05:39 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 24 Jul 2000 18:05:39 -0500 (CDT) Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724190935.G31538@thyrsus.com> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> Message-ID: <14716.52163.222710.772833@beluga.mojam.com> Eric> A timetable. Excellent. Now I know when I have to get my stuff Eric> done (curses docs, enhanced Berkeley DB support). Eric, you are aware that there is a libdb 2.0 module floating around already, right? >> Obviously not every PEP will be included in 2.0. I plan on including >> these: zip(); list comprehensions; augmented assignments; range >> literals. Also whatever's in pep-0200. Skip From jeremy at beopen.com Tue Jul 25 01:57:10 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 24 Jul 2000 19:57:10 -0400 (EDT) Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> Message-ID: <14716.55254.609098.924791@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: GvR> Obviously not every PEP will be included in 2.0. I plan on GvR> including these: zip(); list comprehensions; augmented GvR> assignments; range literals. Also whatever's in pep-0200. Given the release schedule you mentioned, we need to start making progress on the PEPs. I suggest we aim for completed design documents for these features by Aug. 9; that leaves three weeks between completion of design document and first beta release. Jeremy From esr at thyrsus.com Tue Jul 25 02:07:17 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 20:07:17 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <14716.52163.222710.772833@beluga.mojam.com>; from skip@mojam.com on Mon, Jul 24, 2000 at 06:05:39PM -0500 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> Message-ID: <20000724200717.A32163@thyrsus.com> Skip Montanaro : > > Eric> A timetable. Excellent. Now I know when I have to get my stuff > Eric> done (curses docs, enhanced Berkeley DB support). > > Eric, you are aware that there is a libdb 2.0 module floating around > already, right? I'm in touch with the authors, Robin Dunn and Greg Smith. Robin wrote the 2.0 module; Greg updated it for the latest version of libdn, 3.1.55. They both recommend using Greg's version. We've discussed the following plan: 1. Import Greg's 3.x module into the Python core. 2. Adapt Robin's dbShelve stuff to work with Greg's code. (My high-level goal in all this is to give shelves many-readers/one-writer locking so they can be used as session databases by Python CGI scripts). 3. Document it all. Both Greg and Robin are enthusiastic about having this code in the core and are willing to put it under the distribution's license. Yes, there is a test suite. The only problem with this plan is that I don't understand the Python distribution's module build system and step 1 looks kind of hairy. Is this stuff documented anywhere? -- Eric S. Raymond The price of liberty is, always has been, and always will be blood. The person who is not willing to die for his liberty has already lost it to the first scoundrel who is willing to risk dying to violate that person's liberty. Are you free? -- Andrew Ford From akuchlin at cnri.reston.va.us Tue Jul 25 02:17:21 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Mon, 24 Jul 2000 20:17:21 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724200717.A32163@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 24, 2000 at 08:07:17PM -0400 References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> Message-ID: <20000724201721.A9990@newcnri.cnri.reston.va.us> On Mon, Jul 24, 2000 at 08:07:17PM -0400, Eric S. Raymond wrote: >1. Import Greg's 3.x module into the Python core. ... >The only problem with this plan is that I don't understand the Python >distribution's module build system and step 1 looks kind of hairy. Is >this stuff documented anywhere? Try reading the comments at the top of Modules/Setup.in. For a very simple module that's only a file or two, like posixmodule.c or the md5 module, you can simply add an appropriate line to Setup.in. But I vaguely recall that the 3.x bsddb module is a bunch of files -- if that's the case, I'm not sure what to do. For PCRE, I wrote a script which munges several source files into one big pypcre.c, but this is messy and probably was a mistake. I'm not sure what's involved in extending the system to support building in subdirectories of Modules/. (Maybe a line like "pcre pcre/pcre.c pcre/compile.c pcre/study.c ..." in Setup.in would just magically work?) --amk From nowonder at pool.informatik.rwth-aachen.de Tue Jul 25 09:02:51 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Tue, 25 Jul 2000 07:02:51 +0000 Subject: [Python-Dev] guidelines for contributing to Python References: <14716.49442.232191.940532@bitdiddle.concentric.net> Message-ID: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Jeremy Hylton wrote: > > If you fix a bug, you SHOULD write a test case that would have caught > the bug. Two questions: - Where should a test for a bug in Python/compile.c go? - Do we really need to carry around a test for (almost) every bug? > If you commit a patch from the SF Patch Manager or fix a bug from the > Jitterbug database, be sure to reference the patch/bug number in the > CVS log message. Also be sure to change the status in the patch > manager or bug database. "Be sure to have access to the bug database." I don't think I have. BTW: Is there some reason why we don't switch to the SF bug stuff? [Disclaimer: I have no experience with that part of SF, I am just plain curious] Peter P.S.: I don't like this SHOUTING should, must etc. -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From fdrake at beopen.com Tue Jul 25 07:15:35 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 01:15:35 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: <14717.8823.421584.948836@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > P.S.: I don't like this SHOUTING should, must etc. I don't either, but I think I know where it came from. There's an IETF RFC that carefully defines these terms as they relate to standards compliance, and IETF documents use them this way (capitalized). I think we should follow the W3C lead on this one: they adopt the IETF RFC but state that the terms are not specially cased; they are shown as normal English words. (I think the RFC doesn't actually require the capitalization, but I'm not certain offhand.) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Tue Jul 25 07:19:44 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 01:19:44 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: <14717.9072.475757.832530@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > Two questions: > - Where should a test for a bug in Python/compile.c go? > - Do we really need to carry around a test for (almost) every bug? I'd rather carry around the test cases than lose them. These are important for regression tests where a large part of the point is that the implementation doesn't regress and allow an old bug (or it's symptoms) to resurface without being detected. > "Be sure to have access to the bug database." I don't think I have. This sort of thing is a serious problem. > BTW: Is there some reason why we don't switch to the SF bug stuff? > [Disclaimer: I have no experience with that part of SF, I am > just plain curious] I think the SourceForge developers may be looking into importing a Jitterbug database; once that's possible we should definately move that service over. Jitterbug *really* sucks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From dan at cgsoftware.com Tue Jul 25 07:26:13 2000 From: dan at cgsoftware.com (Daniel Berlin) Date: Mon, 24 Jul 2000 22:26:13 -0700 (PDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: On Tue, 25 Jul 2000, Peter Schneider-Kamp wrote: > Jeremy Hylton wrote: > > > > If you fix a bug, you SHOULD write a test case that would have caught > > the bug. > > Two questions: > - Where should a test for a bug in Python/compile.c go? > - Do we really need to carry around a test for (almost) every bug? Yes. It's the only way to make sure it doesn't happen again. GCC has about 6000 regression tests currently, fer instance. Each came about as part of a bug reported (usually what happens is someone takes the preprocessed source sent in with the bug report, and distills it down to about 100-1024 bytes worth of code that demonstrate the bug.). --Dan From bwarsaw at beopen.com Tue Jul 25 07:35:46 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 01:35:46 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python References: <14716.49442.232191.940532@bitdiddle.concentric.net> Message-ID: <14717.10034.65655.779012@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> All contributed Python code MUST follow Guido's Python style JH> guide. http://www.python.org/doc/essays/styleguide.html I'd like to create two new PEPs, one which would be a Python coding style guide, based on Guido's seminal essay, but updated, and a C coding style guide for modules and core C code. I'd probably eventually like to add one for Java code in the JPython core as well. Any objections to PEPing these, even though it may be a little while before they're fleshed out? Anybody else care to champion them? If not, I will do it. -Barry From bwarsaw at beopen.com Tue Jul 25 07:38:26 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 01:38:26 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python References: <14716.49442.232191.940532@bitdiddle.concentric.net> <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.9072.475757.832530@cj42289-a.reston1.va.home.com> Message-ID: <14717.10194.305692.8974@anthem.concentric.net> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> I think the SourceForge developers may be looking into Fred> importing a Jitterbug database; once that's possible we Fred> should definately move that service over. Jitterbug Fred> *really* sucks! I've been using the SF bug tracker for Mailman and it definitely sucks less than Jitterbug. Not perfect, but very usable. One thing I'd like to see (and I've made a request for this), is the ability to link bugs and patches. Very often a Mailman user will post a bug report and a dever will post a patch to fix the bug. It'd be nice if there could be a direct crosslink between the two. And if SF can import a Jitterbug database, that'd be a huge win! -Barry From bwarsaw at beopen.com Tue Jul 25 07:40:32 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 01:40:32 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: <14717.10320.356127.243997@anthem.concentric.net> >>>>> "DB" == Daniel Berlin writes: DB> Yes. It's the only way to make sure it doesn't happen again. DB> GCC has about 6000 regression tests currently, fer instance. DB> Each came about as part of a bug reported (usually what DB> happens is someone takes the preprocessed source sent in with DB> the bug report, and distills it down to about 100-1024 bytes DB> worth of code that demonstrate the bug.). Absolutely agreed. I can't even count the number of times that my regression test suite saved much embarrassment with CC Mode. Python is a big complex system with many interacting pieces. A butterfly change here can cause a hurricane breakage elsewhere. It's exactly this kind of thing the regression tests will catch. -Barry From paul at prescod.net Tue Jul 25 09:15:10 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 25 Jul 2000 02:15:10 -0500 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <397CBB1E.D5AE9DF1@lemburg.com> Message-ID: <397D3E7E.520C7440@prescod.net> "M.-A. Lemburg" wrote: > > ... > > BTW, how rock solid is Python's builtin XML support ? I'm asking > because I want to make our product XML aware and the various > different parser implementations out there gave me a rather > unsecure feeling about which one to go after... If by "rock solid" you mean "doesn't crash and doesn't leak memory" then yeah, I think its pretty rock solid but someone like you should kick PyExpat's Unicode tires more forcefully than they have been kicked. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From paul at prescod.net Tue Jul 25 09:19:43 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 25 Jul 2000 02:19:43 -0500 Subject: [Python-Dev] Python Consortium Meeting News References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <397CBB1E.D5AE9DF1@lemburg.com> Message-ID: <397D3F8F.44EB162A@prescod.net> "M.-A. Lemburg" wrote: > > ... > > BTW, how rock solid is Python's builtin XML support ? I'm asking > because I want to make our product XML aware and the various > different parser implementations out there gave me a rather > unsecure feeling about which one to go after... If by "rock solid" you mean "doesn't crash and doesn't leak memory" then yeah, I think its pretty rock solid but someone like you should kick PyExpat's Unicode tires more forcefully than they have been kicked. -- Paul Prescod - Not encumbered by corporate consensus New from Computer Associates: "Software that can 'think', sold by marketers who choose not to." From moshez at math.huji.ac.il Tue Jul 25 09:30:53 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 10:30:53 +0300 (IDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <14717.9072.475757.832530@cj42289-a.reston1.va.home.com> Message-ID: On Tue, 25 Jul 2000, Fred L. Drake, Jr. wrote: > I think the SourceForge developers may be looking into importing a > Jitterbug database; once that's possible we should definately move > that service over. Jitterbug *really* sucks! In the mean time, could anyone send an explanation about Jitterbug? (where it is, what should we look for, etc.) -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From tim_one at email.msn.com Tue Jul 25 10:16:50 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 04:16:50 -0400 Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: Message-ID: [Moshe Zadka] > In the mean time, could anyone send an explanation about > Jitterbug? (where it is, what should we look for, etc.) Jitterbug is the bug-tracking system Python currently uses (at python.org). That's why it would be keen if SourceForge could import all its info by magic. From mal at lemburg.com Tue Jul 25 10:54:15 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 25 Jul 2000 10:54:15 +0200 Subject: [Python-Dev] Python's new builtin XML support (Python Consortium Meeting News) References: <20000722123603.A24658@newcnri.cnri.reston.va.us> <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <397CBB1E.D5AE9DF1@lemburg.com> <397D3F8F.44EB162A@prescod.net> Message-ID: <397D55B7.4C7B664C@lemburg.com> Paul Prescod wrote: > > "M.-A. Lemburg" wrote: > > > > ... > > > > BTW, how rock solid is Python's builtin XML support ? I'm asking > > because I want to make our product XML aware and the various > > different parser implementations out there gave me a rather > > unsecure feeling about which one to go after... > > If by "rock solid" you mean "doesn't crash and doesn't leak memory" then > yeah, I think its pretty rock solid but someone like you should kick > PyExpat's Unicode tires more forcefully than they have been kicked. I will once I find time to look into these things :-) My concern was basically about design changes (I always assume that code going into the core doesn't crash and tries not to leak memory ;-) -- before trying to come up with an integration scheme I wan't to be sure that the backend will remain functional across at least two Python versions. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Tue Jul 25 10:59:46 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 11:59:46 +0300 (IDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: Message-ID: On Tue, 25 Jul 2000, Tim Peters wrote: > [Moshe Zadka] > > In the mean time, could anyone send an explanation about > > Jitterbug? (where it is, what should we look for, etc.) > > Jitterbug is the bug-tracking system Python currently uses (at python.org). > That's why it would be keen if SourceForge could import all its info by > magic. No, I meant something along the lines of "the jitterbug database is at the following URL:, to get a list of the currently-open bugs, do this, to get a list of the bugs which are related to some area do that" and so on. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From nowonder at pool.informatik.rwth-aachen.de Tue Jul 25 13:36:56 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Tue, 25 Jul 2000 11:36:56 +0000 Subject: [Python-Dev] guidelines for contributing to Python References: Message-ID: <397D7BD8.9584187F@pool.informatik.rwth-aachen.de> Moshe Zadka wrote: > > No, I meant something along the lines of "the jitterbug database is at the > following URL:, to get a list of the currently-open bugs, do this, to get > a list of the bugs which are related to some area do that" and so on. Non-authoritative answer: the jitterbug database is at the following URL: http://www.python.org/python-bugs [parrot.python.org at 132.151.19.90] to get a list of the currently-open bugs, click on open (between the second last and the last horizontal ruler) to get a list of the bugs which are related to some area, enter an appropriate regular expression and press "Select Messages", then select open (or whatever category you'd like to view) hope-that-helps-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From nowonder at pool.informatik.rwth-aachen.de Tue Jul 25 13:39:11 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Tue, 25 Jul 2000 11:39:11 +0000 Subject: [Python-Dev] guidelines for contributing to Python References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> Message-ID: <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> Okay, so where do I put that test for Python/compile.c? BTW: Someone with the right permissions might want to close open bug 81 (duplicate keyword args) Peter "Barry A. Warsaw" wrote: > > Absolutely agreed. I can't even count the number of times that my > regression test suite saved much embarrassment with CC Mode. Python > is a big complex system with many interacting pieces. A butterfly > change here can cause a hurricane breakage elsewhere. It's exactly > this kind of thing the regression tests will catch. -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From fdrake at beopen.com Tue Jul 25 13:32:30 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 07:32:30 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <14717.10034.65655.779012@anthem.concentric.net> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> Message-ID: <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > I'd like to create two new PEPs, one which would be a Python coding > style guide, based on Guido's seminal essay, but updated, and a C > coding style guide for modules and core C code. I'd probably > eventually like to add one for Java code in the JPython core as well. Why would these be PEPs? I know some of us had discussed that a style guide should be written as part of the standard documentation. The PEPs exist largely for developers of Python's interpreters and standard library. The style guide is for a larger audience, so needs to be part of the standard documentation. I stated at some point that I would convert Guido's "essay"; perhaps that should move up the list of priorities so that the other people interested can work with it; I seem to recall that you, Greg Wilson, and possibly Jeremy were interested. > Any objections to PEPing these, even though it may be a little while > before they're fleshed out? Anybody else care to champion them? If > not, I will do it. I'm willing if this is part of the standard documentation. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Tue Jul 25 14:38:19 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 07:38:19 -0500 Subject: [Python-Dev] ANSIfication. In-Reply-To: Your message of "Sun, 23 Jul 2000 02:24:53 +0200." <20000723022452.Q9897@xs4all.nl> References: <20000723022452.Q9897@xs4all.nl> Message-ID: <200007251238.HAA19158@cj20424-a.reston1.va.home.com> > I'm done checking in the ansification patches. It doesn't fix everything, > for a couple of reasons: Thanks for doing all this work, Thomas! Frankly, I think that for *any* functions that are in some external library (e.g. libc), Python should never provide a function prototype at all. The standard headers should provide the prototypes! There used to be a bunch of systems out there where the standard headers were inadequate for one reason or another -- e.g. some systems didn't bother to declare int functions, and Python was taking pointers to such functions. But this should all long be gone... I don't mind breaking some ports in a minor way by removing *all* prototypes for standard library functions. (Ditto for non-standard external libraries like readline.) I recall that more recently there were also some cases where a prototype wasn't in scope because the right combination of magical #defines wasn't present, especially for functions that weren't in the old POSIX or C standards. Adding prototypes for these is wrong: we should figure out the right #defines and define these in Python.h or config.h! > There are a couple of more things that might be candidate for cleanup or > removal now, by the way. The 'ANY' #define in Include/mymalloc.h, and the > type(s) derived from it, for instance. I'm not sure how 'standard' the void* > type is, but I thought it was ANSI mandated ? Yes, void* is ANSI. Get rid of all references to ANY. (Ages ago, on K&R systems ANY had to defined as char *.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Tue Jul 25 14:49:03 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 07:49:03 -0500 Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: Your message of "Tue, 25 Jul 2000 07:32:30 -0400." <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> Message-ID: <200007251249.HAA19269@cj20424-a.reston1.va.home.com> > Why would these be PEPs? I know some of us had discussed that a > style guide should be written as part of the standard documentation. > The PEPs exist largely for developers of Python's interpreters and > standard library. The style guide is for a larger audience, so needs > to be part of the standard documentation. Good point. But... > I stated at some point that I would convert Guido's "essay"; perhaps > that should move up the list of priorities so that the other people > interested can work with it; I seem to recall that you, Greg Wilson, > and possibly Jeremy were interested. The issue is that a new PEP feels much more lightweight than a new manual section. > > Any objections to PEPing these, even though it may be a little while > > before they're fleshed out? Anybody else care to champion them? If > > not, I will do it. > > I'm willing if this is part of the standard documentation. The Python style guide should probably go into the standard docs. The C style guide might as well be one of the meta-PEPs, like the index (maybe call it PEP 0100). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Tue Jul 25 13:57:49 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 07:57:49 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <200007251249.HAA19269@cj20424-a.reston1.va.home.com> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> <200007251249.HAA19269@cj20424-a.reston1.va.home.com> Message-ID: <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > The issue is that a new PEP feels much more lightweight than a new > manual section. There are a number of smaller manuals now (doc, dist, inst). > The C style guide might as well be one of the meta-PEPs, like the > index (maybe call it PEP 0100). Should it? I would expect it to be part of a single style guide or a chapter in the Extending & Embedding manual. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas at xs4all.net Tue Jul 25 14:21:20 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 14:21:20 +0200 Subject: [Python-Dev] ANSIfication. In-Reply-To: <200007251238.HAA19158@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 07:38:19AM -0500 References: <20000723022452.Q9897@xs4all.nl> <200007251238.HAA19158@cj20424-a.reston1.va.home.com> Message-ID: <20000725142120.G266@xs4all.nl> On Tue, Jul 25, 2000 at 07:38:19AM -0500, Guido van Rossum wrote: > Thanks for doing all this work, Thomas! I can't take all the credit, Fred and Peter did a lot of it, too. Also, my girlfriend's decision to spend the weekend catching up on her sleep mattered a lot ;) > Frankly, I think that for *any* functions that are in some external > library (e.g. libc), Python should never provide a function prototype > at all. The standard headers should provide the prototypes! Impeccable timing, Guido ! I competely agree, and this is why: I was just trying to figure out how to solve that problem on the one Solaris box we have. (An aging old beast, probably with a messed-up installation -- all SunOS experience we had has fled in horror when we moved to BSDI and Linux ;) I was encountering a lot of undeclared functions, and was dutifuly adding them to the SOLARIS block in pyport.h, when I found out that SOLARIS isn't defined :P I spent half an hour looking for a reliable way to detect the SunOS version, or even whether it's some Sun product at all, and failed. I'm not sure if that's a problem with Solaris or with that specific installation of it (Solaris 2.5.6, by the way,) but it convinced me to just forget about auto-detecting these cases. Dropping the prototypes altogether, and merely keeping the prototype-pyport-section for *real* problems, rather than warnings caused by missing declarations, would suit me fine ! > Yes, void* is ANSI. Get rid of all references to ANY. (Ages ago, > on K&R systems ANY had to defined as char *.) Okidoki. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From skip at mojam.com Tue Jul 25 14:21:24 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 07:21:24 -0500 (CDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> Message-ID: <14717.34372.437370.172614@beluga.mojam.com> Peter> Okay, so where do I put that test for Python/compile.c? I suggest Lib/test/test_compile.py, with a corresponding output file in Lib/test/output/test_compile, assuming it's a test that can be written in Python. (If not, the group (or someone in it) probably needs to figure out a C-based testing framework.) I wouldn't worry that it's a lone test for the time being. It will likely gain friends as time goes on. Skip From moshez at math.huji.ac.il Tue Jul 25 14:36:34 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 15:36:34 +0300 (IDT) Subject: [Python-Dev] Features for Python 2.0 Message-ID: Earlier today (from my prespective ), Guido said that Python 2.0 is supposed to include zip(), list comprehensions, range literals and augmented assignments. In private mail, Guido said the list is open to downwards debate, so I'm opening it. Would anyone feel really bad if we postpone list comprehensions and augmented assignments to a later version? I'm a bit afraid of those features, since they are quite large, and it is yet uncertain how programs which use those features will look. (OTOH, zip will simply replace some map(None) and iterating in parallel by index, and [0:10:2] will replace range(0, 10, 2), so we have a pretty good idea about their effects) -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at beopen.com Tue Jul 25 15:43:58 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 08:43:58 -0500 Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: Your message of "Tue, 25 Jul 2000 07:57:49 -0400." <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> <200007251249.HAA19269@cj20424-a.reston1.va.home.com> <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> Message-ID: <200007251343.IAA19755@cj20424-a.reston1.va.home.com> > There are a number of smaller manuals now (doc, dist, inst). OK. Since you've offered to do this, I have no objection. > > The C style guide might as well be one of the meta-PEPs, like the > > index (maybe call it PEP 0100). > > Should it? I would expect it to be part of a single style guide or > a chapter in the Extending & Embedding manual. E&E is for writing 3rd party modules. This is for the core code. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From moshez at math.huji.ac.il Tue Jul 25 14:51:56 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 15:51:56 +0300 (IDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> Message-ID: On Tue, 25 Jul 2000, Fred L. Drake, Jr. wrote: > Should it? I would expect it to be part of a single style guide or > a chapter in the Extending & Embedding manual. Definitely not a chapter in the extending and embedding manual: the average Python extender doesn't give a hoot about what Guido thinks about C programming, even though he should -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at beopen.com Tue Jul 25 15:53:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 08:53:05 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:36:34 +0300." References: Message-ID: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> > Would anyone feel really bad if we postpone list comprehensions and > augmented assignments to a later version? I'm a bit afraid of those > features, since they are quite large, and it is yet uncertain how programs > which use those features will look. (OTOH, zip will simply replace some > map(None) and iterating in parallel by index, and [0:10:2] will replace > range(0, 10, 2), so we have a pretty good idea about their effects) If you folks hadn't wasted so much time discussion augmented print statements and new operators, we could have had the augmented assignments and list comprehensions checked in already! If you have a specific objection, raise it. Drop the meta issues. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From moshez at math.huji.ac.il Tue Jul 25 15:00:07 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 16:00:07 +0300 (IDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 25 Jul 2000, Guido van Rossum wrote: > > Would anyone feel really bad if we postpone list comprehensions and > > augmented assignments to a later version? I'm a bit afraid of those > > features, since they are quite large, and it is yet uncertain how programs > > which use those features will look. (OTOH, zip will simply replace some > > map(None) and iterating in parallel by index, and [0:10:2] will replace > > range(0, 10, 2), so we have a pretty good idea about their effects) > > If you folks hadn't wasted so much time discussion augmented print > statements and new operators, we could have had the augmented > assignments and list comprehensions checked in already! > > If you have a specific objection, raise it. Drop the meta issues. OK, here's a possible confusion point in augmented assignments: Sometimes c = a a += b assert a is c fails, and sometimes not, depending on a's type. This is just begging for trouble. Maybe it will cause massive confusion, maybe it won't. I know I'll usually be wary of using it. List comprehensions' problems is that we cannot find a syntax that we all agree is readable. Perhaps the answer is not list comprehensions, but lexical scoping combined with steroid versions of map and filter, together with zip to bind things together. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From thomas at xs4all.net Tue Jul 25 15:20:44 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 15:20:44 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 25, 2000 at 04:00:07PM +0300 References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: <20000725152044.H266@xs4all.nl> On Tue, Jul 25, 2000 at 04:00:07PM +0300, Moshe Zadka wrote: > OK, here's a possible confusion point in augmented assignments: > Sometimes > c = a > a += b > assert a is c > fails, and sometimes not, depending on a's type. This is just begging > for trouble. Maybe it will cause massive confusion, maybe it won't. I know > I'll usually be wary of using it. In my very honest opinion, that's overstating it a bit. It isn't much more confusing than the failure of c = a + b assert c is a + b for some types, but not for others. Not to mention that a + b can produce an entirely different object than b + a depending on the types. Now, how's that for confusing ! Has anyone ever seen a problem caused by that ? I haven't, and I doubt the augmented assignment is going to cause such problems. I *have* seen something like this: c = a.extend(b) Though that was a real silly mistake on the programmers part, and hasn't repeated itself. All in all, the only way we are really going to spot these pitfalls, realistic or not, is by *using* the new syntax, and letting 'newbies' use it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Tue Jul 25 16:24:08 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:24:08 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 16:00:07 +0300." References: Message-ID: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> > Sometimes > > c = a > a += b > assert a is c > > fails, and sometimes not, depending on a's type. This is just begging > for trouble. Maybe it will cause massive confusion, maybe it won't. I know > I'll usually be wary of using it. Don't worry about this. Python doesn't guarantee the semantics for 'is' independent on the type anyway. E.g.: a = b[:] assert a is b may fail or succeed depending on the type (try it with strings, tuples and lists). > List comprehensions' problems is that we cannot find a syntax that we all > agree is readable. Perhaps the answer is not list comprehensions, but > lexical scoping combined with steroid versions of map and filter, together > with zip to bind things together. I'm about 3000 messages behind in that particular discussion. I still really like Greg Ewing's original syntax: [x for x in seq] with extensions to [x+y for x in seq1 for y in seq2] [x for x in seq if pred(x)] [x, x*2 for x in seq] (General meta-comment on PEPs: these long intros explaining the problem are a detriment to finding the actual proposal. Perhaps we could have a one-paragraph explanation for the need, then a concrete proposal, then motivation and rationale and background, and then raised objections plus responses? Currently the rationale seems to be coming up front, which distracts from the proposal.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Tue Jul 25 15:28:37 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 15:28:37 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251353.IAA19818@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 08:53:05AM -0500 References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: <20000725152837.I266@xs4all.nl> On Tue, Jul 25, 2000 at 08:53:05AM -0500, Guido van Rossum wrote: > If you folks hadn't wasted so much time discussion augmented print > statements and new operators, we could have had the augmented > assignments and list comprehensions checked in already! I don't think the augmented assignment patch is ready to be checked in, though ! There are a number of crude hacks that might be solved better: the 2-argument opcodes, for instance, could posisbly be avoided by abusing the proposed 'extended_arg' opcode. And the patch re-uses the binary opcodes as augmented-assignment opcodes, merely because those #defines were already available in both ceval.c and compile.c: this would 'break' if we wanted to incorporate a new operator in augmented-assignment without adding a new 'normal' opcode for that operator. I'm still working on the PEP, really :) It's just a pretty long one, trying to explain all the intricate details and the simple elegance of the solution . Perhaps it'll inspire some discussion in the details of the patch, too. Humb-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Tue Jul 25 15:30:16 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 16:30:16 +0300 (IDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> Message-ID: On Tue, 25 Jul 2000, Guido van Rossum wrote: > > List comprehensions' problems is that we cannot find a syntax that we all > > agree is readable. Perhaps the answer is not list comprehensions, but > > lexical scoping combined with steroid versions of map and filter, together > > with zip to bind things together. > > I'm about 3000 messages behind in that particular discussion. I still > really like Greg Ewing's original syntax: > > [x for x in seq] I think the main problem with this syntax was that there is no seperator between the expression and the "for". Not a parser issue, but a human one: the same reason there is a colon after the "if" keyword. Now, [x; for x in seq] and [x: for x in seq] each had their objections. These will all probably be in the PEP, so I'll shut up now. > [x+y for x in seq1 for y in seq2] > [x for x in seq if pred(x)] > [x, x*2 for x in seq] And what about [x+y for x in seq1 for y in seq2 if y>2 if x<3] or [x+y for x in seq1 if x<3 for y in seq2 if y>2] What is allowed? Aren't we being a bit too TIMTOWTDIish here? (From there on, the discussion diverged) -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From skip at mojam.com Tue Jul 25 15:33:42 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 08:33:42 -0500 (CDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: <14717.38710.261186.468871@beluga.mojam.com> Guido> If you folks hadn't wasted so much time discussion augmented Guido> print statements and new operators, we could have had the Guido> augmented assignments and list comprehensions checked in already! I hate to play the role of Obvious Man, but I will point out that the list comprehensions patch was assigned to Guido on July 8, who promptly postponed it... ;-) Skip From jeremy at beopen.com Tue Jul 25 15:39:58 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 09:39:58 -0400 (EDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> Message-ID: <14717.39086.748350.672470@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> Would anyone feel really bad if we postpone list comprehensions >> and augmented assignments to a later version? I'm a bit afraid of >> those features, since they are quite large, and it is yet >> uncertain how programs which use those features will look. (OTOH, >> zip will simply replace some map(None) and iterating in parallel >> by index, and [0:10:2] will replace range(0, 10, 2), so we have a >> pretty good idea about their effects) GvR> If you folks hadn't wasted so much time discussion augmented GvR> print statements and new operators, we could have had the GvR> augmented assignments and list comprehensions checked in GvR> already! Not so fast Mr. Van Rossum! We need to get the specifications for these features written first. Barry should be updating the PEP guidelines today, and Tim and Thomas have been assigned PEPs on the two most controversial features. Yesterday, I proposed we set Aug. 9 as the deadline for completing the specs. Until we have the specs, I don't think we need to have lots of long-winded debates about whether the features scare people :-). Jeremy From thomas at xs4all.net Tue Jul 25 15:37:30 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 15:37:30 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251424.JAA19917@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 09:24:08AM -0500 References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> Message-ID: <20000725153730.J266@xs4all.nl> On Tue, Jul 25, 2000 at 09:24:08AM -0500, Guido van Rossum wrote: > (General meta-comment on PEPs: these long intros explaining the > problem are a detriment to finding the actual proposal. Perhaps we > could have a one-paragraph explanation for the need, then a concrete > proposal, then motivation and rationale and background, and then > raised objections plus responses? Currently the rationale seems to be > coming up front, which distracts from the proposal.) You can put Barry in Cardinal Fang's chair for that one ! :) He suggested to use his PEP201, Parallel Iteration, as a working example of a PEP. And PEP201 starts with a relatively long introduction of how for-loops and the current map(None, seq1, seq2) work. I've been meaning to ask people about the format, layout and style of the PEPs, but kept deferring it until after PEP-203 ;P Jeremy and Tim mentioned a Rationale section, but didn't give any clues as to what it should look like, and where and/or how it should be placed in the rest of the PEP. It's also hard to keep the PEP both concise and easy to read for those not initiated in the confusing ways of the Python ;-) Who are we writing PEPs for ? For you, Guido ? For the python-dev team as a whole ? For python-list ? For the whole of the Python community ? A collection of parts of one or more of the above ? Answer that question and the faults in all current PEPs become obvious ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From esr at thyrsus.com Tue Jul 25 02:35:55 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 24 Jul 2000 20:35:55 -0400 Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724201721.A9990@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Mon, Jul 24, 2000 at 08:17:21PM -0400 References: <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> Message-ID: <20000724203555.A32412@thyrsus.com> Andrew Kuchling : > Try reading the comments at the top of Modules/Setup.in. For a very > simple module that's only a file or two, like posixmodule.c or the md5 > module, you can simply add an appropriate line to Setup.in. But I > vaguely recall that the 3.x bsddb module is a bunch of files -- if > that's the case, I'm not sure what to do. Looks like just one to me, though there is some auxiliary called config.c to me that I don't understand. Here, I'll enclose the stuff; it's not large. -- Eric S. Raymond ...Virtually never are murderers the ordinary, law-abiding people against whom gun bans are aimed. Almost without exception, murderers are extreme aberrants with lifelong histories of crime, substance abuse, psychopathology, mental retardation and/or irrational violence against those around them, as well as other hazardous behavior, e.g., automobile and gun accidents." -- Don B. Kates, writing on statistical patterns in gun crime -------------- next part -------------- A non-text attachment was scrubbed... Name: py-bsddb3-2.1.0.tar.gz Type: application/octet-stream Size: 65086 bytes Desc: not available URL: From guido at beopen.com Tue Jul 25 16:40:53 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:40:53 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:28:37 +0200." <20000725152837.I266@xs4all.nl> References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> <20000725152837.I266@xs4all.nl> Message-ID: <200007251440.JAA20085@cj20424-a.reston1.va.home.com> > There are a number of crude hacks that might be solved better: the > 2-argument opcodes, for instance, could posisbly be avoided by abusing the > proposed 'extended_arg' opcode. And the patch re-uses the binary opcodes as > augmented-assignment opcodes, merely because those #defines were already > available in both ceval.c and compile.c: this would 'break' if we wanted to > incorporate a new operator in augmented-assignment without adding a new > 'normal' opcode for that operator. > > I'm still working on the PEP, really :) It's just a pretty long one, trying > to explain all the intricate details and the simple elegance of the solution > . Perhaps it'll inspire some discussion in the details of the patch, > too. Suggestion: write the VM spec first, and check that in when you're done. I bet that writing down the VM spec will clarify a lot, since it will specify the semantics (the syntax we all know). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From bwarsaw at beopen.com Tue Jul 25 15:43:05 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 09:43:05 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python References: <14716.49442.232191.940532@bitdiddle.concentric.net> <14717.10034.65655.779012@anthem.concentric.net> <14717.31438.492467.643693@cj42289-a.reston1.va.home.com> <200007251249.HAA19269@cj20424-a.reston1.va.home.com> <14717.32957.229312.449849@cj42289-a.reston1.va.home.com> <200007251343.IAA19755@cj20424-a.reston1.va.home.com> Message-ID: <14717.39273.635728.922559@anthem.concentric.net> Okay Fred, if you want to make them manuals instead of PEPs, I don't object. -Barry From moshez at math.huji.ac.il Tue Jul 25 15:43:57 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 16:43:57 +0300 (IDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <20000725152044.H266@xs4all.nl> Message-ID: On Tue, 25 Jul 2000, Thomas Wouters wrote: > All in all, the only way we are really going to spot these pitfalls, > realistic or not, is by *using* the new syntax, and letting 'newbies' use > it. Without arguing with the specifics, I'm against this attitude: what will you do if you find newbies always stumble over those issues? You can't take it out, because you're commited to backwards compatability. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From effbot at telia.com Tue Jul 25 15:52:39 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 25 Jul 2000 15:52:39 +0200 Subject: [Python-Dev] Features for Python 2.0 References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> Message-ID: <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> guido wrote: > [x for x in seq] > [x+y for x in seq1 for y in seq2] > [x for x in seq if pred(x)] > [x, x*2 for x in seq] stupid question: does the last one mean that a python parser has to stack an infinite number of tokens before it can figure out if it has a list or a list comprehension? did Python just turn into something that is much harder to parse? From guido at beopen.com Tue Jul 25 16:49:22 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:49:22 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 09:39:58 -0400." <14717.39086.748350.672470@bitdiddle.concentric.net> References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> <14717.39086.748350.672470@bitdiddle.concentric.net> Message-ID: <200007251449.JAA20159@cj20424-a.reston1.va.home.com> > Not so fast Mr. Van Rossum! We need to get the specifications for > these features written first. Barry should be updating the PEP > guidelines today, and Tim and Thomas have been assigned PEPs on the > two most controversial features. Yesterday, I proposed we set Aug. 9 > as the deadline for completing the specs. They are not controversial with *me*, and the complaints about either that were repeated today don't impress me much. The only concerns I have are: - Should we allow [x, y for x in s1 for y in s2] or should we require that to be written as [(x, y) for x in s1 for y in s2]? - What does a += b += c mean? Plus doubts about the cleanliness of the implementations given by the currently proposed patches, e.g. Thomas' doubt about the use of so many new opcodes (which I think is actually fine). > Until we have the specs, I don't think we need to have lots of > long-winded debates about whether the features scare people :-). Agreed. Besides, our priorities should be focused on the 1.6 release first. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Tue Jul 25 16:54:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:54:02 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:37:30 +0200." <20000725153730.J266@xs4all.nl> References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <20000725153730.J266@xs4all.nl> Message-ID: <200007251454.JAA20180@cj20424-a.reston1.va.home.com> > Who are we writing PEPs for ? For you, Guido ? For the python-dev team as a > whole ? For python-list ? For the whole of the Python community ? A > collection of parts of one or more of the above ? Answer that question and > the faults in all current PEPs become obvious ;) The PEPs should be written for review of proposed changes for those who are serious about language design and implementation. I consider myself an element of that set but not its only member! For this audience, exactness and conciseness of description count; "selling" the feature to the general audience is not desirable. A rationale is necessary; this should include a motivation for the feature and discussion of (reasonable) alternatives and objections that have been brougt up (if any). A PEP should also be the place to point to when someone starts rehashing an old discussion. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From thomas at xs4all.net Tue Jul 25 15:56:43 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 15:56:43 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 25, 2000 at 04:43:57PM +0300 References: <20000725152044.H266@xs4all.nl> Message-ID: <20000725155642.K266@xs4all.nl> On Tue, Jul 25, 2000 at 04:43:57PM +0300, Moshe Zadka wrote: > On Tue, 25 Jul 2000, Thomas Wouters wrote: > > All in all, the only way we are really going to spot these pitfalls, > > realistic or not, is by *using* the new syntax, and letting 'newbies' use > > it. > Without arguing with the specifics, I'm against this attitude: what will > you do if you find newbies always stumble over those issues? You can't > take it out, because you're commited to backwards compatability. I didn't suggest we turned augmented assignment 'on' in beta phase, and removed it if it turned out too confusing. I was thinking more along the lines of the recent 'usability study' of parallel loops. Urging people to install the patch just to see how it works, and if it works how they expected. The point is we can argue all year long about how will be confusing because of , and too confusing for users of , and this too confusing if you come from language. We probably all are right, too ! But in the end we have to decide whether the new functionality is worth the extra confusion. And part of that is determining how confusing the new syntax and semantics really are, for those used to Python and those new to Python. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Tue Jul 25 16:57:35 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:57:35 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:52:39 +0200." <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> Message-ID: <200007251457.JAA20217@cj20424-a.reston1.va.home.com> > guido wrote: > > > [x for x in seq] > > [x+y for x in seq1 for y in seq2] > > [x for x in seq if pred(x)] > > [x, x*2 for x in seq] > > stupid question: does the last one mean that a python parser has > to stack an infinite number of tokens before it can figure out if it > has a list or a list comprehension? > > did Python just turn into something that is much harder to parse? This is a (minor) open issue; I'd be happy with requiring [(x, x*2) for x in seq] --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Tue Jul 25 16:59:58 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 09:59:58 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 16:43:57 +0300." References: Message-ID: <200007251459.JAA20243@cj20424-a.reston1.va.home.com> > > All in all, the only way we are really going to spot these pitfalls, > > realistic or not, is by *using* the new syntax, and letting 'newbies' use > > it. > > Without arguing with the specifics, I'm against this attitude: what will > you do if you find newbies always stumble over those issues? You can't > take it out, because you're commited to backwards compatability. Thomas and Moshe, stop worrying (and arguing) about this! For these two proposals that has long been resolved. What I expect from you two is suggestions on how to best implement this. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From guido at beopen.com Tue Jul 25 17:01:13 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 10:01:13 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 15:56:43 +0200." <20000725155642.K266@xs4all.nl> References: <20000725152044.H266@xs4all.nl> <20000725155642.K266@xs4all.nl> Message-ID: <200007251501.KAA20258@cj20424-a.reston1.va.home.com> > I didn't suggest we turned augmented assignment 'on' in beta phase, and > removed it if it turned out too confusing. I was thinking more along the > lines of the recent 'usability study' of parallel loops. Urging people to > install the patch just to see how it works, and if it works how they > expected. > > The point is we can argue all year long about how will be confusing > because of , and too confusing for users of , and this > too confusing if you come from language. We probably all are right, > too ! But in the end we have to decide whether the new functionality is > worth the extra confusion. And part of that is determining how confusing the > new syntax and semantics really are, for those used to Python and those new > to Python. Oh please. Augmented assignment is about the most requested feature. Every other language that Python newbies are likely familiar with has it in exactly the same form. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jeremy at beopen.com Tue Jul 25 16:27:40 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 10:27:40 -0400 (EDT) Subject: [Python-Dev] guidelines for contributing to Python In-Reply-To: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> References: <14716.49442.232191.940532@bitdiddle.concentric.net> <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> Message-ID: <14717.41948.876878.174423@bitdiddle.concentric.net> >>>>> "PSK" == Peter Schneider-Kamp writes: >> If you commit a patch from the SF Patch Manager or fix a bug from >> the Jitterbug database, be sure to reference the patch/bug number >> in the CVS log message. Also be sure to change the status in the >> patch manager or bug database. PSK> "Be sure to have access to the bug database." I don't think I PSK> have. If you don't have access to Jitterbug, you can send me email and I'll make the change. Jeremy From sjoerd at oratrix.nl Tue Jul 25 16:27:18 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Tue, 25 Jul 2000 16:27:18 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: Your message of Thu, 20 Jul 2000 22:13:00 +0200. <20000720221300.W9897@xs4all.nl> References: <20000720221300.W9897@xs4all.nl> Message-ID: <20000725142719.0341831047C@bireme.oratrix.nl> On Thu, Jul 20 2000 Thomas Wouters wrote: > > I just went over all of the Python source, using this little program > (which I called findkrc.py): > > import sys, string > > for file in sys.argv[1:] > d = open(file).read() > if string.find(d, ";\n{") <> -1 or string.find(d, "()\n{") <> -1: > print file > > (using find -name '*.[ch]' -print | xargs ./findkrc.py) > > And I fixed almost all of the instances of K&R C syntax. However, I found a > lot of instances of the 2nd type: empty argument list. However, as far as I > remember, ANSI C states that should be written as '(void)'. Is that a > non-issue, and should I not bother fixing those ? (Most of the files in > Modules/ has one or more instances of those.) There is a difference between a function *declaration* and a function *definition*. The former, a function declaration, tells the compiler, this is the type of the function (and its arguments). In a function declaration it is useful to make the distinction between "no arguments" and "unknown arguments". This is done by using the "void" keyword. So int foo(); means that there is a function named "foo" that returns an int and with unknown arguments. int bar(void); means that there is a function named "bar" that returns an int and that doesn't take any arguments. However in a function definition you *must* specify the arguments. So if you define a function int foo() { ... } it is clear that foo doesn't have any arguments. There is no difference with int foo(void) { ... } -- Sjoerd Mullender From effbot at telia.com Tue Jul 25 16:40:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 25 Jul 2000 16:40:48 +0200 Subject: [Python-Dev] Features for Python 2.0 References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> <200007251457.JAA20217@cj20424-a.reston1.va.home.com> Message-ID: <00b401bff646$54389080$f2a6b5d4@hagrid> guido wrote: > This is a (minor) open issue; I'd be happy with requiring > > [(x, x*2) for x in seq] doesn't really change anything, does it? the (x, x*2) could still be a value tuple or an assignment target. I'm no parser expert, but doesn't this mean that we're ruling out certain kinds of parsers? From effbot at telia.com Tue Jul 25 17:01:35 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 25 Jul 2000 17:01:35 +0200 Subject: [Python-Dev] Features for Python 2.0 References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> <200007251457.JAA20217@cj20424-a.reston1.va.home.com> <00b401bff646$54389080$f2a6b5d4@hagrid> Message-ID: <00dc01bff649$4049ff20$f2a6b5d4@hagrid> I wrote: > guido wrote: > > This is a (minor) open issue; I'd be happy with requiring > > > > [(x, x*2) for x in seq] > > doesn't really change anything, does it? the (x, x*2) could > still be a value tuple or an assignment target. umm. not sure "assignment target" was the right term here; what I'm trying to say is that you cannot tell what you're parsing until you've seen the "for" keyword. or in other words, the "n" in "when you see 'x', you have to read 'n' more tokens before you can tell what 'x' is" suddenly became much larger... (after all, I've successfully parsed Python code with a very simple non-backtracking recursive-descent parser -- and I'm not sure I can teach that one to recognize list comprehensions...) (and yes, I'm sure this can be expressed in [AELRS]+\(\d+\) notation, but I'm not gonna try ;-) From fdrake at beopen.com Tue Jul 25 16:57:25 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 10:57:25 -0400 (EDT) Subject: [Python-Dev] Python Consortium Meeting News In-Reply-To: <20000724203555.A32412@thyrsus.com> References: <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> Message-ID: <14717.43733.134803.961463@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Looks like just one to me, though there is some auxiliary called config.c > to me that I don't understand. Here, I'll enclose the stuff; it's Don't worry about config.c -- that's generated from the Setup files. As long as the right line appears in Setup.in, that's sufficient. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas at xs4all.net Tue Jul 25 17:02:15 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 17:02:15 +0200 Subject: [Python-Dev] ANSIfication again ;) In-Reply-To: <20000725142719.0341831047C@bireme.oratrix.nl>; from sjoerd@oratrix.nl on Tue, Jul 25, 2000 at 04:27:18PM +0200 References: <20000720221300.W9897@xs4all.nl> <20000725142719.0341831047C@bireme.oratrix.nl> Message-ID: <20000725170215.P224@xs4all.nl> On Tue, Jul 25, 2000 at 04:27:18PM +0200, Sjoerd Mullender wrote: > On Thu, Jul 20 2000 Thomas Wouters wrote: > > for file in sys.argv[1:] > > d = open(file).read() > > if string.find(d, ";\n{") <> -1 or string.find(d, "()\n{") <> -1: > > print file > There is a difference between a function *declaration* and a function > *definition*. The script I included only finds function *definitions*, not declarations, and definitions is what I was talking about. > So if you define a function > int foo() > { > it is clear that foo doesn't have any arguments. There is no difference > with > int foo(void) > { And that was exactly what I was asking :) I know there is no difference between the two, and the question was: should I fix them anyway ? I got at least one (maybe more, I forget) affirmatives, so I fixed them. (The ones I could find, that is.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Tue Jul 25 18:12:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 11:12:05 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 17:01:35 +0200." <00dc01bff649$4049ff20$f2a6b5d4@hagrid> References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> <200007251457.JAA20217@cj20424-a.reston1.va.home.com> <00b401bff646$54389080$f2a6b5d4@hagrid> <00dc01bff649$4049ff20$f2a6b5d4@hagrid> Message-ID: <200007251612.LAA20609@cj20424-a.reston1.va.home.com> > > guido wrote: > > > This is a (minor) open issue; I'd be happy with requiring > > > > > > [(x, x*2) for x in seq] [effbot] > > doesn't really change anything, does it? the (x, x*2) could > > still be a value tuple or an assignment target. [effbot again] > umm. not sure "assignment target" was the right term here; what > I'm trying to say is that you cannot tell what you're parsing until > you've seen the "for" keyword. > > or in other words, the "n" in "when you see 'x', you have to read > 'n' more tokens before you can tell what 'x' is" suddenly became > much larger... > > (after all, I've successfully parsed Python code with a very simple > non-backtracking recursive-descent parser -- and I'm not sure I > can teach that one to recognize list comprehensions...) > > (and yes, I'm sure this can be expressed in [AELRS]+\(\d+\) > notation, but I'm not gonna try ;-) Don't worry. Greg Ewing had no problem expressing this in Python's own grammar, which is about as restricted as parsers come. (It's LL(1), which is equivalent to pure recursive descent with one lookahead token, i.e. no backtracking.) Here's Greg's grammar: atom: ... | '[' [testlist [list_iter]] ']' | ... list_iter: list_for | list_if list_for: 'for' exprlist 'in' testlist [list_iter] list_if: 'if' test [list_iter] Note that before, the list syntax was '[' [testlist] ']'. Let me explain it in different terms: The parser parses a series comma-separated expressions. Previously, it was expecting ']' as the sole possible token following this. After the change, 'for' is another possible following token. This is no problem at all for any parser that knows how to parse matching parentheses! If you'd rather not support [x, y for ...] because it's ambiguous (to the human reader, not to the parser!), we can change the grammar to something like: '[' test [',' testlist | list_iter] ']' (Note that | binds less than concatenation, and [...] means an optional part.) To merge with range literals, we'd have to go for: '[' test [':' test [':' test] | ',' testlist | list_iter ] ']' Another modification is needed to support [:x] and [:x:y], but that's a separate path through the parser entirely: atom: ... | '[' range | test [ range | ',' testlist | list_iter ] ']' | ... range: ':' test [':' test] --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From jim at interet.com Tue Jul 25 17:24:54 2000 From: jim at interet.com (James C. Ahlstrom) Date: Tue, 25 Jul 2000 11:24:54 -0400 Subject: [Python-Dev] InfoWorld July 17 looks at Zope and Python Message-ID: <397DB146.C68F9CD0@interet.com> See that issue for a review of Zope. Python is mentioned in connection with Zope. JimA From akuchlin at mems-exchange.org Tue Jul 25 17:32:41 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 11:32:41 -0400 Subject: [Python-Dev] Re: Berkeley DB In-Reply-To: <20000724203555.A32412@thyrsus.com>; from esr@thyrsus.com on Mon, Jul 24, 2000 at 08:35:55PM -0400 References: <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> Message-ID: <20000725113241.D32196@kronos.cnri.reston.va.us> On Mon, Jul 24, 2000 at 08:35:55PM -0400, Eric S. Raymond wrote: >Looks like just one to me, though there is some auxiliary called config.c >to me that I don't understand. Here, I'll enclose the stuff; it's >not large. Ah, it looks much simpler than I thought; there's one C file, so adding the C code is just a matter of dropping db_wrap.c into Modules, and adding the single line in the package's Setup.in to Modules/Setup.in. There are a bunch of *.py files, though; might it be worth creating a subpackage for BerkeleyDB in order to keep from cluttering up the library root? db_wrap.c is also an obscure name, and it would be nice to change it. --amk From gvwilson at nevex.com Tue Jul 25 17:39:48 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 25 Jul 2000 11:39:48 -0400 (EDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Message-ID: > Moshe Zadka wrote: > Would anyone feel really bad if we postpone list comprehensions and > augmented assignments to a later version? I would like augmented assignments as soon as possible. I would also like to volunteer to repeat the "simultaneous loop" syntax experiment with list comprehensions, i.e. see whether what's being proposed lines up with people's pre-existing intuitions. Greg From fdrake at beopen.com Tue Jul 25 17:40:42 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 11:40:42 -0400 (EDT) Subject: [Python-Dev] Re: Berkeley DB In-Reply-To: <20000725113241.D32196@kronos.cnri.reston.va.us> References: <20000724102026.A4196@kronos.cnri.reston.va.us> <397C60A4.A4A9513C@lemburg.com> <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> Message-ID: <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > cluttering up the library root? db_wrap.c is also an obscure name, > and it would be nice to change it. _bsddb seems reasonable. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Tue Jul 25 18:47:18 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 11:47:18 -0500 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: Your message of "Tue, 25 Jul 2000 11:39:48 -0400." References: Message-ID: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> > I would also like to volunteer to repeat the "simultaneous loop" syntax > experiment with list comprehensions, i.e. see whether what's being > proposed lines up with people's pre-existing intuitions. Please do! Though I have no doubt of the outcome: [x+y for x in [10, 20, 30] for y in [1, 2, 3]] will be almost universally understood to mean [11, 12, 13, 21, 22, 23, 31, 32, 33]. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From esr at thyrsus.com Tue Jul 25 17:58:47 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 11:58:47 -0400 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: ; from gvwilson@nevex.com on Tue, Jul 25, 2000 at 11:39:48AM -0400 References: Message-ID: <20000725115847.C1785@thyrsus.com> Greg Wilson : > I would also like to volunteer to repeat the "simultaneous loop" syntax > experiment with list comprehensions, i.e. see whether what's being > proposed lines up with people's pre-existing intuitions. I think that's n excellent idea. User testing! bWhat a concept! -- Eric S. Raymond "Rightful liberty is unobstructed action, according to our will, within limits drawn around us by the equal rights of others." -- Thomas Jefferson From moshez at math.huji.ac.il Tue Jul 25 17:51:54 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 18:51:54 +0300 (IDT) Subject: [Python-Dev] Product iteration Message-ID: A large part of the problem in list comprehensions (I think) is that we need to allow more then one "for" term, so we can iterate over the product of several lists. Why not solve that the same way we solved the parallel iteration problem, by using a function, called, say, "product". Then list comprehensions can limited to be (in pseudo formal grammar): '[' expr 'for' var 'in' seq [ 'if' pred ] ']' Such that "var" can be anything that can today be in a for loop, e.g., (x, (y, z)) Then we wouldn't have the irksome problem of how for's and if's intermix: the predicate at the end can be an and'ed sequence of predicates. Reference implemntation: class _Producter: def __init__(self, lists): if not lists: raise TypeError("must receive at least one list") self.lists = lists self.lengths = map(len, lists) self.n_lists = len(lists) def __getitem__(self, i): if i<0: raise ValueError("only non-negative indices supported") ret = [None] * self.n_lists for j in range(self.n_lists): i, i_j = divmod(i, self.lengths[j]) ret[j] = self.lists[j][i_j] if i != 0: raise IndexError("not that many items") return tuple(ret) def product(*lists): return _Producter(lists) -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From esr at thyrsus.com Tue Jul 25 18:03:27 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 12:03:27 -0400 Subject: [Python-Dev] Re: Berkeley DB In-Reply-To: <14717.46330.703979.141406@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jul 25, 2000 at 11:40:42AM -0400 References: <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> Message-ID: <20000725120327.D1785@thyrsus.com> Fred L. Drake, Jr. : > > Andrew Kuchling writes: > > cluttering up the library root? db_wrap.c is also an obscure name, > > and it would be nice to change it. > > _bsddb seems reasonable. There is already a bsddbmodule.c. Can somebody explain why some module names have a leading underscore and some don't? -- Eric S. Raymond "Extremism in the defense of liberty is no vice; moderation in the pursuit of justice is no virtue." -- Barry Goldwater (actually written by Karl Hess) From esr at thyrsus.com Tue Jul 25 18:07:27 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 12:07:27 -0400 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251647.LAA20899@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 11:47:18AM -0500 References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> Message-ID: <20000725120726.F1785@thyrsus.com> Guido van Rossum : > > I would also like to volunteer to repeat the "simultaneous loop" syntax > > experiment with list comprehensions, i.e. see whether what's being > > proposed lines up with people's pre-existing intuitions. > > Please do! > > Though I have no doubt of the outcome: > > [x+y for x in [10, 20, 30] for y in [1, 2, 3]] > > will be almost universally understood to mean > > [11, 12, 13, 21, 22, 23, 31, 32, 33]. This is my expectation as well. -- Eric S. Raymond The abortion rights and gun control debates are twin aspects of a deeper question --- does an individual ever have the right to make decisions that are literally life-or-death? And if not the individual, who does? From fdrake at beopen.com Tue Jul 25 17:56:05 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 11:56:05 -0400 (EDT) Subject: [Python-Dev] Re: Berkeley DB In-Reply-To: <20000725120327.D1785@thyrsus.com> References: <200007241645.LAA15974@cj20424-a.reston1.va.home.com> <20000724174019.E31538@thyrsus.com> <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> Message-ID: <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > There is already a bsddbmodule.c. Can somebody explain why some module names > have a leading underscore and some don't? I was under the impression that db_wrap was an implementation detail for some Python code; module names with a leading underscore are not intended to be directly used by anything other than a Python wrapper module. The existing bsddb module *is* the public interface; if db_wrap is a direct replacment, it should be called bsddb instead of _bsddb. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From akuchlin at mems-exchange.org Tue Jul 25 18:03:19 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 12:03:19 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <14717.47253.118639.700872@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jul 25, 2000 at 11:56:05AM -0400 References: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> Message-ID: <20000725120319.E32196@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 11:56:05AM -0400, Fred L. Drake, Jr. wrote: >module. The existing bsddb module *is* the public interface; if >db_wrap is a direct replacment, it should be called bsddb instead of >_bsddb. It's not; in fact, db_wrap.c is SWIG-generated code while the old bsddb module was a hand-written extension. Is it OK to add a SWIG-generated module to the core? (I have an irrational dislike SWIG's trick of encoding pointers as strings, because it provides a way to deliberately engineer core dumps; it's just sort of unsettling.) --amk From bwarsaw at beopen.com Tue Jul 25 18:09:50 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 12:09:50 -0400 (EDT) Subject: [Python-Dev] Product iteration References: Message-ID: <14717.48078.888579.564219@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> A large part of the problem in list comprehensions (I think) MZ> is that we need to allow more then one "for" term, so we can MZ> iterate over the product of several lists. All this belongs in PEP 202. Can we please stop discussing it here until that PEP is done? Tim Peters owns it, so until he assigns it to someone else, I suggest that if you have an opinion on list comprehensions, send your comments to him. Let Tim collect all the comments and write the PEP. didn't-mean-to-pick-on-moshe-ly y'rs, -Barry From thomas at xs4all.net Tue Jul 25 18:18:16 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 18:18:16 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251440.JAA20085@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 09:40:53AM -0500 References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> <20000725152837.I266@xs4all.nl> <200007251440.JAA20085@cj20424-a.reston1.va.home.com> Message-ID: <20000725181815.L266@xs4all.nl> On Tue, Jul 25, 2000 at 09:40:53AM -0500, Guido van Rossum wrote: > > I'm still working on the PEP, really :) It's just a pretty long one, trying > > to explain all the intricate details and the simple elegance of the solution > > . Perhaps it'll inspire some discussion in the details of the patch, > > too. > Suggestion: write the VM spec first, and check that in when you're > done. I bet that writing down the VM spec will clarify a lot, since > it will specify the semantics (the syntax we all know). The syntax isn't a problem, the exact semantics are ;) But I'll try the reverse method of the proposal, see where it leads. It'll be a quick and short technical description to start with, though, and I'm not entirely clear on whether that should be the PEP or not ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Tue Jul 25 18:22:44 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 12:22:44 -0400 (EDT) Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> Message-ID: <14717.48852.392171.944585@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> I would also like to volunteer to repeat the "simultaneous loop" >> syntax experiment with list comprehensions, i.e. see whether >> what's being proposed lines up with people's pre-existing >> intuitions. GvR> Please do! GvR> Though I have no doubt of the outcome: GvR> [x+y for x in [10, 20, 30] for y in [1, 2, 3]] GvR> will be almost universally understood to mean GvR> [11, 12, 13, 21, 22, 23, 31, 32, 33]. For reference, here is the what Haskell does with the same definition. Prelude> [ x+y | x <- [10, 20, 30], y <- [1, 2, 3]] [11,12,13,21,22,23,31,32,33] Jeremy PS I still find the Haskell more readable because it has some simple syntax that identifies what role each part of the expression plays. The producer is to the left of the vertical bar and each generator is identified by a "<-". From thomas at xs4all.net Tue Jul 25 18:22:55 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 18:22:55 +0200 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251449.JAA20159@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 09:49:22AM -0500 References: <200007251353.IAA19818@cj20424-a.reston1.va.home.com> <14717.39086.748350.672470@bitdiddle.concentric.net> <200007251449.JAA20159@cj20424-a.reston1.va.home.com> Message-ID: <20000725182255.M266@xs4all.nl> On Tue, Jul 25, 2000 at 09:49:22AM -0500, Guido van Rossum wrote: > - What does a += b += c mean? I don't want to start a discussion on this, but I just want to say: the current implementation considers it a syntax error, and I think that's a very reasonable thing to do. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw at beopen.com Tue Jul 25 18:25:07 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 12:25:07 -0400 (EDT) Subject: [Python-Dev] Features for Python 2.0 PEP References: <200007251424.JAA19917@cj20424-a.reston1.va.home.com> <20000725153730.J266@xs4all.nl> Message-ID: <14717.48995.148454.146372@anthem.concentric.net> >>>>> "TW" == Thomas Wouters writes: TW> You can put Barry in Cardinal Fang's chair for that one ! :) TW> He suggested to use his PEP201, Parallel Iteration, as a TW> working example of a PEP. And PEP201 starts with a relatively TW> long introduction of how for-loops and the current map(None, TW> seq1, seq2) work. Yes, but as with any `first' it takes a little while to flesh things out. I'll soon have a revision that edits much of that out. PEP 1 is nearly ready so hopefully that'll answer most of the style questions. -Barry From jeremy at beopen.com Tue Jul 25 18:29:34 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 12:29:34 -0400 (EDT) Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725120319.E32196@kronos.cnri.reston.va.us> References: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> Message-ID: <14717.49262.480392.948763@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Tue, Jul 25, 2000 at 11:56:05AM -0400, Fred L. Drake, AMK> Jr. wrote: >> module. The existing bsddb module *is* the public interface; if >> db_wrap is a direct replacment, it should be called bsddb instead >> of _bsddb. AMK> It's not; in fact, db_wrap.c is SWIG-generated code while the AMK> old bsddb module was a hand-written extension. Is it OK to add AMK> a SWIG-generated module to the core? (I have an irrational AMK> dislike SWIG's trick of encoding pointers as strings, because AMK> it provides a way to deliberately engineer core dumps; it's AMK> just sort of unsettling.) Indeed! The stock SWIG produces dangerous code for pointers and inefficient code for returning multiple values. The code it produces is hard to read at least in part because it is indented incorrectly. I don't think any of these features are acceptable for a core module. I have some patches and typemaps for SWIG that do a better job, but it's still not great. If people are interested, I can post to the list. The two primary changes are to use PyCObjects for pointers and to generate better code for returning tuples. (The current code generates a return tuple incrementally; for each value, it creates a new tuple and appends it to the old return value.) Jeremy PS Andrew: The patched version of SWIG might still be installed in the depot at CNRI. You could try it out. From fdrake at beopen.com Tue Jul 25 18:29:02 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 12:29:02 -0400 (EDT) Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725120319.E32196@kronos.cnri.reston.va.us> References: <200007242235.RAA17731@cj20424-a.reston1.va.home.com> <20000724190935.G31538@thyrsus.com> <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> Message-ID: <14717.49230.549418.726681@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > It's not; in fact, db_wrap.c is SWIG-generated code while the old > bsddb module was a hand-written extension. Is it OK to add a > SWIG-generated module to the core? (I have an irrational dislike > SWIG's trick of encoding pointers as strings, because it provides a > way to deliberately engineer core dumps; it's just sort of > unsettling.) You're right -- SWIG code stinks for exactly this reason. I think Jeremy did some work to avoid this, but I imagine that's no longer available (it's at CNRI). It seems to me that the right thing is to fix SWIG (probably as part of the next generation of the tool). I'm not sure what Dave's current plans are, or if there's any expectation for the schedule. I don't see anything relevant at www.swig.org, but I might be missing something obvious to SWIG users. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From akuchlin at mems-exchange.org Tue Jul 25 18:46:51 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 12:46:51 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <14717.49262.480392.948763@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 25, 2000 at 12:29:34PM -0400 References: <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> Message-ID: <20000725124651.F32196@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 12:29:34PM -0400, Jeremy Hylton wrote: >I don't think any of these features are acceptable for a core module. So what should we do WRT BerkeleyDB? The existing module in Python only really supports BSDDB 1.85. Robin Dunn's module, and the enhanced version of it by Greg someone-or-other, uses SWIG. Options I can think of: 1) Give up and do nothing 2) Try fixing SWIG. 3) Include the SWIG-generated code as it stands 4) Write a custom new BerkeleyDB extension. (In time for 2.0b1? Iffy...) I think the only solution is to do the job right and do #4, though it might wind up being postponed until Python 2.1, or whatever comes after 2.0. --amk From guido at beopen.com Tue Jul 25 19:51:39 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 12:51:39 -0500 Subject: [Python-Dev] Berkeley DB In-Reply-To: Your message of "Tue, 25 Jul 2000 12:46:51 -0400." <20000725124651.F32196@kronos.cnri.reston.va.us> References: <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> Message-ID: <200007251751.MAA21417@cj20424-a.reston1.va.home.com> > 1) Give up and do nothing > 2) Try fixing SWIG. > 3) Include the SWIG-generated code as it stands > 4) Write a custom new BerkeleyDB extension. (In time for 2.0b1? Iffy...) > > I think the only solution is to do the job right and do #4, though it > might wind up being postponed until Python 2.1, or whatever comes > after 2.0. Is the existing 3rd party BerkeleyDB broken, or just stylistically too bad for inclusion in the core? If the latter, we could remove bsddb from the core and refer to the 3rd party module -- assuming it has a website and all. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From fdrake at beopen.com Tue Jul 25 18:55:56 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 25 Jul 2000 12:55:56 -0400 (EDT) Subject: [Python-Dev] Berkeley DB In-Reply-To: <200007251751.MAA21417@cj20424-a.reston1.va.home.com> References: <14716.52163.222710.772833@beluga.mojam.com> <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> <200007251751.MAA21417@cj20424-a.reston1.va.home.com> Message-ID: <14717.50844.387001.258809@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > Is the existing 3rd party BerkeleyDB broken, or just stylistically too > bad for inclusion in the core? If the latter, we could remove bsddb > from the core and refer to the 3rd party module -- assuming it has a > website and all. Pointing to the new extension from the documentation is certainly reasonable under any circumstance, with a note about why it may be interesting or useful as an alternate implementation. Does anyone have a URL I can use? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Tue Jul 25 18:59:55 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 25 Jul 2000 18:59:55 +0200 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> Message-ID: <397DC78B.B31FF0CE@lemburg.com> Guido van Rossum wrote: > > > I would also like to volunteer to repeat the "simultaneous loop" syntax > > experiment with list comprehensions, i.e. see whether what's being > > proposed lines up with people's pre-existing intuitions. > > Please do! > > Though I have no doubt of the outcome: > > [x+y for x in [10, 20, 30] for y in [1, 2, 3]] > > will be almost universally understood to mean > > [11, 12, 13, 21, 22, 23, 31, 32, 33]. Just a note about the syntax: why does the above have the expression and the "for" notation reversed ? Wouldn't it make much more sense to write something more lambda function like, e.g. [for (x,y) in zip([10,20,30], [1,2,3]): x+y] or [for x in range(100): x*2] ? I believe the above would cause much less confusion since it resembles standard Python "for" loop notation (making it intuitive for Python programmers) and is in syntax very similar to what "lambda" uses: lambda : List comprehension would then become something like: [for in : ] -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at mems-exchange.org Tue Jul 25 19:01:35 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 13:01:35 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <200007251751.MAA21417@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 12:51:39PM -0500 References: <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> <200007251751.MAA21417@cj20424-a.reston1.va.home.com> Message-ID: <20000725130135.G32196@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 12:51:39PM -0500, Guido van Rossum wrote: >Is the existing 3rd party BerkeleyDB broken, or just stylistically too >bad for inclusion in the core? If the latter, we could remove bsddb The latter. The existing module still works fine, particularly if you just need a DBM-like file that can also be traversed in sorted-key order, but it's not compatible with the current BerkeleyDB code. --amk From jeremy at beopen.com Tue Jul 25 19:08:30 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 13:08:30 -0400 (EDT) Subject: [Python-Dev] Makefile and dependencies Message-ID: <14717.51598.566139.423603@bitdiddle.concentric.net> The Python Makefiles do not contain enough dependency information to do incremental builds safely. If you change a .h file, none of the .c files that use it will be re-compiled unless they were also changed. This makes it a bit more tedious to test new code, because you need to do a make clean to be sure you're getting everything. I know next-to-nothing about makefiles. Is there anyone with some expertise in this area who could contribute better dependency information? Or is the lack of dependency information a conscious decision? Jeremy From guido at beopen.com Tue Jul 25 20:09:00 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 13:09:00 -0500 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: Your message of "Tue, 25 Jul 2000 13:08:30 -0400." <14717.51598.566139.423603@bitdiddle.concentric.net> References: <14717.51598.566139.423603@bitdiddle.concentric.net> Message-ID: <200007251809.NAA21636@cj20424-a.reston1.va.home.com> > The Python Makefiles do not contain enough dependency information to > do incremental builds safely. If you change a .h file, none of the .c > files that use it will be re-compiled unless they were also changed. > This makes it a bit more tedious to test new code, because you need to > do a make clean to be sure you're getting everything. > > I know next-to-nothing about makefiles. Is there anyone with some > expertise in this area who could contribute better dependency > information? Or is the lack of dependency information a conscious > decision? No, it's gradually been degraded. There's a "make depend" target that's broken beyond repair. I hope someone helps you to fix this! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From nascheme at enme.ucalgary.ca Tue Jul 25 19:29:34 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 25 Jul 2000 11:29:34 -0600 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: <200007251809.NAA21636@cj20424-a.reston1.va.home.com>; from Guido van Rossum on Tue, Jul 25, 2000 at 01:09:00PM -0500 References: <14717.51598.566139.423603@bitdiddle.concentric.net> <200007251809.NAA21636@cj20424-a.reston1.va.home.com> Message-ID: <20000725112934.A23143@keymaster.enme.ucalgary.ca> Guido, would you be interested in a non-recursive Python Makefile? I don't have a patch yet and I'm not sure it is possible to make it portable. Neil From moshez at math.huji.ac.il Tue Jul 25 19:32:43 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Tue, 25 Jul 2000 20:32:43 +0300 (IDT) Subject: [Python-Dev] Makefile and dependencies In-Reply-To: <14717.51598.566139.423603@bitdiddle.concentric.net> Message-ID: On Tue, 25 Jul 2000, Jeremy Hylton wrote: > The Python Makefiles do not contain enough dependency information to > do incremental builds safely. If you change a .h file, none of the .c > files that use it will be re-compiled unless they were also changed. > This makes it a bit more tedious to test new code, because you need to > do a make clean to be sure you're getting everything. > > I know next-to-nothing about makefiles. Is there anyone with some > expertise in this area who could contribute better dependency > information? Or is the lack of dependency information a conscious > decision? Well, there could probably be an improvement, but not one that would *ensure* safe incremental builds. The fundamental problems is that it's using recursive make, which tends to have this problem. (Anyone has a URL handy for Recursive Make Considered Harmful?). In the mean time, perhaps running makedepend on the makefiles can improve the situation. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at beopen.com Tue Jul 25 20:33:38 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 13:33:38 -0500 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: Your message of "Tue, 25 Jul 2000 11:29:34 CST." <20000725112934.A23143@keymaster.enme.ucalgary.ca> References: <14717.51598.566139.423603@bitdiddle.concentric.net> <200007251809.NAA21636@cj20424-a.reston1.va.home.com> <20000725112934.A23143@keymaster.enme.ucalgary.ca> Message-ID: <200007251833.NAA21781@cj20424-a.reston1.va.home.com> > Guido, would you be interested in a non-recursive Python Makefile? I > don't have a patch yet and I'm not sure it is possible to make it > portable. Actually, the recursive version works just fine for me. It's the dependencies that aren't properly set. (Each .c file should depend on most .h files, and that info is missing from the sub-Makefiles; the toplevel Makefile just recurses into directories.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From trentm at ActiveState.com Tue Jul 25 19:37:36 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 10:37:36 -0700 Subject: C testing framework (was: Re: [Python-Dev] guidelines for contributing to Python) In-Reply-To: <14717.34372.437370.172614@beluga.mojam.com> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> <14717.34372.437370.172614@beluga.mojam.com> Message-ID: <20000725103736.B577@ActiveState.com> On Tue, Jul 25, 2000 at 07:21:24AM -0500, Skip Montanaro wrote: > > assuming it's a test that can be written in > Python. (If not, the group (or someone in it) probably needs to figure out > a C-based testing framework.) I already have a simple starter implementation for this with a couple stupid limitations. Would y'all like to see it? As well, this has been discussed a couple of times before: single email: http://www.python.org/pipermail/python-dev/2000-May/010750.html start of a later thread: http://www.python.org/pipermail/python-dev/2000-June/011622.html Show it? PEP it? Forget it? Trent -- Trent Mick TrentM at ActiveState.com From guido at beopen.com Tue Jul 25 20:42:32 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 13:42:32 -0500 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: Your message of "Tue, 25 Jul 2000 20:32:43 +0300." References: Message-ID: <200007251842.NAA21899@cj20424-a.reston1.va.home.com> > Well, there could probably be an improvement, but not one that would > *ensure* safe incremental builds. I don't believe that at all. The problem is that the submakefiles (in Parser, Objects, Python, and Modules) don't specify all dependencies on the header files in Include. If proper dependencies were added, the recursive make strategy would be totally fine. The toplevel Makefile always descends into each subdirectory to do whatever needs to be done there; there are some tricks so that the subdirectories know what to do and whether the toplevel libpython$(VERSION).a needs to be updated. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) From tim_one at email.msn.com Tue Jul 25 19:50:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 13:50:47 -0400 Subject: [PEP 202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: <14717.48078.888579.564219@anthem.concentric.net> Message-ID: [Moshe] > A large part of the problem in list comprehensions (I think) > is that we need to allow more then one "for" term, so we can > iterate over the product of several lists. ... [Barry A. Warsaw] > All this belongs in PEP 202. Can we please stop discussing it here > until that PEP is done? But closed discussions are not the way to build a PEP: it's a PEP champion's job to *summarize* significant opposing viewpoints in the rationale, but there's no way to judge "significant" without intense community involvement. Vigorous open discussion is vital to any stds process. > Tim Peters owns it, so until he assigns it to someone else, I suggest > that if you have an opinion on list comprehensions, send your comments > to him. Let Tim collect all the comments and write the PEP. This is not how I want to do it. In the particular case of list comprehensions, everyone (well, everyone both conscious and sane ) is sick of the debate because it's been going on for *years*, and was almost purely repetitive long before Greg Ewing made his first patch. In this case I happen to think Moshe is trying to solve "a problem" likely nobody else sees as a problem, but I can't tell without seeing how others react to his (bizarre ) suggestion. A PEP isn't a dumping ground for every random suggestion that comes along, either -- open discussion is needed to narrow things down to the truly serious alternatives. A PEP writer's job should be more editor than arbiter: Guido is the only BDFL here! All that said, I have an enormous backlog of listcomp msgs still to plow through, and I'm going to flatly ignore any in the future unless they have PEP 202 in the Subject line (as this retitled msg has). A pep-dev mailing list is clearly a very good idea, but until one is set up I'm afraid python-dev is the only natural place to bear the unbearable (to some) pep-dev traffic. From trentm at ActiveState.com Tue Jul 25 20:00:00 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 11:00:00 -0700 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <397DC78B.B31FF0CE@lemburg.com> References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> Message-ID: <20000725110000.C577@ActiveState.com> On Tue, Jul 25, 2000 at 06:59:55PM +0200, M . -A . Lemburg wrote: > Wouldn't it make much more sense to write something > more lambda function like, e.g. > > [for (x,y) in zip([10,20,30], [1,2,3]): x+y] or [for x in [10,20,30]: for y in [1,2,3]: x+y] > > or > > [for x in range(100): x*2] > > List comprehension would then become something like: > > [for in : ] > For what it is worth, I like that. I can easily digest either though, so I think that this is a question for user testing. Trent -- Trent Mick TrentM at ActiveState.com From skip at mojam.com Tue Jul 25 20:05:24 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 13:05:24 -0500 (CDT) Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725130135.G32196@kronos.cnri.reston.va.us> References: <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> <200007251751.MAA21417@cj20424-a.reston1.va.home.com> <20000725130135.G32196@kronos.cnri.reston.va.us> Message-ID: <14717.55012.596068.67219@beluga.mojam.com> Andrew> The latter. The existing module still works fine, particularly Andrew> if you just need a DBM-like file that can also be traversed in Andrew> sorted-key order, but it's not compatible with the current Andrew> BerkeleyDB code. The only thing that's needed to use the current bsddb module interface with libdb 2.x is to include db_185.h instead of db.h. You don't get all the 2.x functionality, but you do get the less buggy libdb implementation. I've been using it like that for a couple years. Skip From bwarsaw at beopen.com Tue Jul 25 20:10:52 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 14:10:52 -0400 (EDT) Subject: [Python-Dev] Makefile and dependencies References: <14717.51598.566139.423603@bitdiddle.concentric.net> Message-ID: <14717.55340.327775.690317@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> I know next-to-nothing about makefiles. Is there anyone with JH> some expertise in this area who could contribute better JH> dependency information? Or is the lack of dependency JH> information a conscious decision? makedepend is the way to go and is probably compatible with GNU and non-GNU makes. -Barry From skip at mojam.com Tue Jul 25 20:09:58 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 13:09:58 -0500 (CDT) Subject: C testing framework (was: Re: [Python-Dev] guidelines for contributing to Python) In-Reply-To: <20000725103736.B577@ActiveState.com> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> <14717.34372.437370.172614@beluga.mojam.com> <20000725103736.B577@ActiveState.com> Message-ID: <14717.55286.1741.361478@beluga.mojam.com> [c-based testing framework] Trent> Show it? PEP it? Forget it? I say show it. I see no reason to make a PEP unless there are a number of potential immediate alternatives. It doesn't affect the functionality of the distribution, only its quality. If something better comes along later, Trent's can be replaced. Skip From jeremy at beopen.com Tue Jul 25 20:25:56 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 14:25:56 -0400 (EDT) Subject: C testing framework (was: Re: [Python-Dev] guidelines for contributing to Python) In-Reply-To: <20000725103736.B577@ActiveState.com> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> <14717.34372.437370.172614@beluga.mojam.com> <20000725103736.B577@ActiveState.com> Message-ID: <14717.56244.101761.909713@bitdiddle.concentric.net> >>>>> "TM" == Trent Mick writes: TM> single email: TM> http://www.python.org/pipermail/python-dev/2000-May/010750.html TM> start of a later thread: TM> http://www.python.org/pipermail/python-dev/2000-June/011622.html TM> Show it? PEP it? Forget it? One or more of the first two. All the feedback first time around was positive, but it was suggested too close to the purported 1.6 feature freeze deadline. Let's put it back on track for 2.0. Jeremy From effbot at telia.com Tue Jul 25 20:31:10 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 25 Jul 2000 20:31:10 +0200 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> Message-ID: <002001bff666$832b18c0$f2a6b5d4@hagrid> mal wrote: > Wouldn't it make much more sense to write something > more lambda function like, e.g. > > [for (x,y) in zip([10,20,30], [1,2,3]): x+y] > > or > > [for x in range(100): x*2] fwiw, I read that as: [ for x in range(100): x * 2 ] which makes no sense at all. From trentm at ActiveState.com Tue Jul 25 20:27:13 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 11:27:13 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs machine with >= 32bit longs Message-ID: <20000725112713.D577@ActiveState.com> I was assigned this patch a while back to try on some 64-bit systems. Fine, I can do that but I have since seen a number of message on python-dev regarding it: - Fredrik had a new, better replacement? Fredrik? - The name changed to unicodedata? MAL? - Bill, you said that the patch is no longer necessary? Anyway, can someone familiar with the patch tell me if I should check it on 64-bit systems (Win64, Linux64) and then who I should pass the patch on to? OR should I just mark it Out of Date or Rejected? Thanks, Trent -- Trent Mick TrentM at ActiveState.com From skip at mojam.com Tue Jul 25 20:41:17 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 13:41:17 -0500 (CDT) Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <002001bff666$832b18c0$f2a6b5d4@hagrid> References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> <002001bff666$832b18c0$f2a6b5d4@hagrid> Message-ID: <14717.57165.155081.532709@beluga.mojam.com> >> [for x in range(100): x*2] Fredrik> fwiw, I read that as: Fredrik> [ Fredrik> for x in range(100): Fredrik> x * 2 Fredrik> ] Fredrik> which makes no sense at all. It makes perfect sense. You read it correctly as far as I can tell. Using Greg's patch, I get what you'd expect from a simple for loop: >>> [x*2 for x in range(10)] [0, 2, 4, 6, 8, 10, 12, 14, 16, 18] It occurred to me a little bit ago to suggest that we just allow complete statements within list constructors. The semantics would be that any objects left on the stack at the end of the statements would constitute the elements of the list. Is that too weird? Skip From effbot at telia.com Tue Jul 25 20:57:16 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 25 Jul 2000 20:57:16 +0200 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com><397DC78B.B31FF0CE@lemburg.com><002001bff666$832b18c0$f2a6b5d4@hagrid> <14717.57165.155081.532709@beluga.mojam.com> Message-ID: <000c01bff66a$2a451540$f2a6b5d4@hagrid> skip wrote: > The semantics would be that any objects left on the stack > at the end of the statements would constitute the elements > of the list. Is that too weird? yes. From billtut at microsoft.com Tue Jul 25 21:08:57 2000 From: billtut at microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 12:08:57 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD329@RED-MSG-50> Well, Fredrik's changes aren't checked in yet, so checking it all in doesn't hurt. The other relevant question is since Fredrik's code will eventually get in, do we want to yank the code that generates it? (Tools/perfecthash) If we keep it, then that part of the patch should go in. If we don't keep it, that's fine too. You'd need to test it on Linux64. Win64's integer types are 32bits, and the C code doesn't use long longs. The easiest way of testing it of course is to apply the ucnhash.c patch to your tree and run test_ucn.py. :) Bill -----Original Message----- From: Trent Mick [mailto:trentm at ActiveState.com] Sent: Tuesday, July 25, 2000 11:27 AM To: Jeremy Hylton; Bill Tutt; M . -A . Lemburg; Mark Favas; Fredrik Lundh Cc: python-dev at python.org Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs machine with >= 32bit longs I was assigned this patch a while back to try on some 64-bit systems. Fine, I can do that but I have since seen a number of message on python-dev regarding it: - Fredrik had a new, better replacement? Fredrik? - The name changed to unicodedata? MAL? - Bill, you said that the patch is no longer necessary? Anyway, can someone familiar with the patch tell me if I should check it on 64-bit systems (Win64, Linux64) and then who I should pass the patch on to? OR should I just mark it Out of Date or Rejected? Thanks, Trent -- Trent Mick TrentM at ActiveState.com _______________________________________________ Python-Dev mailing list Python-Dev at python.org http://www.python.org/mailman/listinfo/python-dev From esr at thyrsus.com Tue Jul 25 21:28:32 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 15:28:32 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: ; from moshez@math.huji.ac.il on Tue, Jul 25, 2000 at 06:51:54PM +0300 References: Message-ID: <20000725152832.A2019@thyrsus.com> Moshe Zadka : > > A large part of the problem in list comprehensions (I think) is that we > need to allow more then one "for" term, so we can iterate over the product > of several lists. Why not solve that the same way we solved the parallel > iteration problem, by using a function, called, say, "product". > > Then list comprehensions can limited to be (in pseudo formal grammar): > > '[' expr 'for' var 'in' seq [ 'if' pred ] ']' > > Such that "var" can be anything that can today be in a for loop, e.g., > > (x, (y, z)) > > Then we wouldn't have the irksome problem of how for's and if's intermix: > the predicate at the end can be an and'ed sequence of predicates. *KLANNGGG!!!* <-- the sound of the sacred two-by-four of enlightenment belatedly whacking Eric upside the head Dammit, I should have seen this sooner; the whole debate about parallel loops and zip() was a flare-lit clue. Gentlemen, we've been going entirely down the wrong path trying to express list comprehensions via a syntax in imperative style. What they want to be is an applicative sublanguage in functional style -- and mostly about data composition rather than the expression of iteration per se. zip() is part of this. Finding a way to handle conditionals ain't hard; in fact, it's already in the language! The right way to say [x**2 for x in range(1, 99) if isprime(x)] is like this: [x**2 for x in filter(isprime, range(1, 99)] Look at the implications: there is no longer any need for special syntax (or for python-dev debates over special syntax, or newbie confusion over special syntax) on the right side of the for. We get all the power of list comprehensions from one simple [for ... in ...] construct exactly parallel to the for ... in that Python programmers already understand. So instead of trying to fix list comprehensions with syntactic hacks, we can extend it by having a properly rich and orthogonal set of constructor functions. filter, zip, product, and lambda are good enough to cover anything the presently proposed comprehension syntax can handle. But there's a difference, because unfreezing and extending a syntax is a heckuva lot harder than inventing new functional constructors. If you notice that this looks a lot like LISP or F or Haskell, you win. These languages got comprehensions right on the basis of a lot of experience in depth. We can learn from their example. -- Eric S. Raymond An armed society is a polite society. Manners are good when one may have to back up his acts with his life. -- Robert A. Heinlein, "Beyond This Horizon", 1942 From skip at mojam.com Tue Jul 25 21:18:43 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 14:18:43 -0500 (CDT) Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <000c01bff66a$2a451540$f2a6b5d4@hagrid> References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> <002001bff666$832b18c0$f2a6b5d4@hagrid> <14717.57165.155081.532709@beluga.mojam.com> <000c01bff66a$2a451540$f2a6b5d4@hagrid> Message-ID: <14717.59411.881986.179947@beluga.mojam.com> >> The semantics would be that any objects left on the stack at the end >> of the statements would constitute the elements of the list. Is that >> too weird? Fredrik> yes. That was my initial reaction, which was why I didn't post it when I had the idea, only when I saw your interpretation... S From akuchlin at mems-exchange.org Tue Jul 25 21:37:06 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 15:37:06 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725152832.A2019@thyrsus.com>; from esr@thyrsus.com on Tue, Jul 25, 2000 at 03:28:32PM -0400 References: <20000725152832.A2019@thyrsus.com> Message-ID: <20000725153706.B11657@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 03:28:32PM -0400, Eric S. Raymond wrote: >[x**2 for x in filter(isprime, range(1, 99)] ... >filter, zip, product, and lambda are good enough to cover anything the >presently proposed comprehension syntax can handle. ... but not so elegantly, if the filter needs variables from the current scope. Consider removing all numbers in that range that are a multiple of a variable 'n'; you'd have to write: [x**2 for x in filter(lambda x, number = n: (x%n)!=0, range(1,99)) ] This uses the default argument hack to pass the value of 'n' into the scope of the lambda-created function as the parameter 'number'. Icky... I'd rather see extra syntax than more use of this kludge! --amk From skip at mojam.com Tue Jul 25 21:43:00 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 14:43:00 -0500 (CDT) Subject: [PEP 202] Re: [Python-Dev] Product iteration In-Reply-To: <20000725152832.A2019@thyrsus.com> References: <20000725152832.A2019@thyrsus.com> Message-ID: <14717.60868.260948.186346@beluga.mojam.com> Eric> Dammit, I should have seen this sooner; the whole debate about Eric> parallel loops and zip() was a flare-lit clue. Gentlemen, we've Eric> been going entirely down the wrong path trying to express list Eric> comprehensions via a syntax in imperative style. What they want Eric> to be is an applicative sublanguage in functional style -- and Eric> mostly about data composition rather than the expression of Eric> iteration per se. Part of the motivation for list comprehensions as I recall is that we'd like to get away from such a strong reliance on map, reduce and filter. Although powerful concepts, as implemented in Python they tend to be inefficient in many cases, are not powerful enough (incomplete set of functions perhaps?) for the Lispers and are too confusing for non-Lispers, especially when used in complex ways (more than two of them used in the same expression constitutes complex usage to my feeble brain). (I PEP'd the subject so Guido and Tim can find it easily.) Skip From gmcm at hypernet.com Tue Jul 25 21:56:35 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 25 Jul 2000 15:56:35 -0400 Subject: [PEP 202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: References: <14717.48078.888579.564219@anthem.concentric.net> Message-ID: <1247567499-36688181@hypernet.com> [Tim] > In this case I happen to think Moshe is trying to solve "a > problem" likely nobody else sees as a problem, but I can't tell > without seeing how others react to his (bizarre ) > suggestion. FWIW, I like the original Greg Ewing syntax best. Reason: list comprehensions are declarative, and his syntax *looks* declarative. Procedural syntax inside those [...] is wacko, just as d = { ['one'] = 1, ['two'] = 2 } would be. Also, extra punctuation is just noise. PEP202-now-closed-ly y'rs - Gordon From effbot at telia.com Tue Jul 25 23:01:18 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 25 Jul 2000 23:01:18 +0200 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com><397DC78B.B31FF0CE@lemburg.com><002001bff666$832b18c0$f2a6b5d4@hagrid><14717.57165.155081.532709@beluga.mojam.com><000c01bff66a$2a451540$f2a6b5d4@hagrid> <14717.59411.881986.179947@beluga.mojam.com> Message-ID: <002101bff67b$7fba7680$f2a6b5d4@hagrid> skip wrote: > Fredrik> yes. > > That was my initial reaction, which was why I didn't post it when I had the > idea, only when I saw your interpretation... fwiw, the syntax implemented by the patch is the best one I've seen this far. it wasn't that syntax I had in mind when I talked about list confusions... ::: however, I think I prefer [(x, x*2) for x in seq] over [x, x*2 for x in seq] (it doesn't only help me scan it, it also simplifies a piece of code that I happen to have here...) the bot says +0. From guido at beopen.com Tue Jul 25 23:59:43 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 16:59:43 -0500 Subject: [Python-Dev] patches activity In-Reply-To: Your message of "Tue, 25 Jul 2000 16:10:26 EST." <200007252110.QAA24625@server1.lfw.org> References: <200007252110.QAA24625@server1.lfw.org> Message-ID: <200007252159.QAA24008@cj20424-a.reston1.va.home.com> I take it that Ping's script to scrape patches works, and the SF folks have fixed the sending of email on changed patches. So now we get every notification twice. Ping, do you have a better address where we can send the raw email? --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From thomas at xs4all.net Tue Jul 25 23:03:23 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Tue, 25 Jul 2000 23:03:23 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment Message-ID: <20000725230322.N266@xs4all.nl> No, this isn't the first full draft of the PEP :P While writing up the proposed VM changes, I came to the conclusion my patch was all wrong, and I would like some input in case I forgot something. The current patch introduces the following bytecodes: GETSET_SUBSCR GETSET_SLICE GETSET_SLICE+1 GETSET_SLICE+2 GETSET_SLICE+3 GETSET_ATTR GETSET_NAME GETSET_FAST GETSET_GLOBAL Each bytecode does the loading of the object, the actual operation it is supposed to perform, and the storing in the original place. All opcodes get an argument to specify which operation should be performed, which is also where the need for 2-argument opcodes comes from: the NAME/FAST/GLOBAL opcodes need both a name-index and an opcode argument. My excuse for this design is similar to Guido's excuse for the current Python parser: I was young, I was foolish, and I didn't know how to reuse things, only how to *add* things ;) I was also intimidated by the whole idea of a stack, having never really programmed in a low-level programming language before. I now realize only 11 new opcodes are necessary, and it can even be reduced to 1, by splitting the operation into seperate LOAD, , and STORE instructions, with a few ROT_TWO and ROT_THREE's mixed in. could be a new bytecode for each operation (11 in total) or a single 'AUGOP' bytecode with an argument to specify the operation. I think it's less elegant from the bytecode point of view, but it does require a lot less changes in ceval/compile. There is only one significant difference between the current version and this, and that's behaviour in the face of threads. I had originally seen augmented assignment as a way to increment a counter 'thread-safe': the load and store operation are done in one bytecode, and can thus not be interrupted by a thread switch. But after thinking about it, it doesn't make that much sense. It only works for builtin types, not for classes defining a __op_ab__, and possibly not for extention types. In fact, there might be some possibility for a thread switch even in builtin types, though I have never looked at that. Opinions ? Is the semi-reliability in the face of threads a good idea ? Did I miss anything important about the current implementation ? Should I forget about this idea and keep the patch as it is (and go back to my PEP) or should I rewrite the patch and then rewrite the PEP ? This alternate implementation would eradicate my next-to-last objection to including the patch, I think, but we'll discuss the last one, the naming of the __hooks__, after I finish the bloody PEP ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mwh21 at cam.ac.uk Tue Jul 25 23:12:17 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 25 Jul 2000 22:12:17 +0100 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Thomas Wouters's message of "Tue, 25 Jul 2000 23:03:23 +0200" References: <20000725230322.N266@xs4all.nl> Message-ID: Thomas Wouters writes: [opcodes for augmented assignment] > I now realize only 11 new opcodes are necessary, and it can even be reduced > to 1, by splitting the operation into seperate LOAD, , and STORE > instructions, with a few ROT_TWO and ROT_THREE's mixed in. could > be a new bytecode for each operation (11 in total) or a single 'AUGOP' > bytecode with an argument to specify the operation. Can you really do a[b:c] += d with ROT_THREE & ROT_TWO? I thought one couldn't when I was doing the first patch, but maybe I'm wrong. > I think it's less elegant from the bytecode point of view, but it does > require a lot less changes in ceval/compile. There is only one significant > difference between the current version and this, and that's behaviour in the > face of threads. And size of bytecode! > I had originally seen augmented assignment as a way to increment a counter > 'thread-safe': the load and store operation are done in one bytecode, and > can thus not be interrupted by a thread switch. But after thinking about it, > it doesn't make that much sense. It only works for builtin types, not for > classes defining a __op_ab__, and possibly not for extention types. In fact, > there might be some possibility for a thread switch even in builtin types, > though I have never looked at that. > > Opinions ? Is the semi-reliability in the face of threads a good idea ? IMHO, yes. > Did I miss anything important about the current implementation ? > Should I forget about this idea and keep the patch as it is (and go > back to my PEP) or should I rewrite the patch and then rewrite the > PEP ? For now, I'd just write the PEP. Cheers, M. -- On the other hand, the following areas are subject to boycott in reaction to the rampant impurity of design or execution, as determined after a period of study, in no particular order: ... http://www.naggum.no/profile.html From nascheme at enme.ucalgary.ca Tue Jul 25 23:13:34 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 25 Jul 2000 15:13:34 -0600 Subject: [Python-Dev] Makefile and dependencies In-Reply-To: <200007251833.NAA21781@cj20424-a.reston1.va.home.com>; from Guido van Rossum on Tue, Jul 25, 2000 at 01:33:38PM -0500 References: <14717.51598.566139.423603@bitdiddle.concentric.net> <200007251809.NAA21636@cj20424-a.reston1.va.home.com> <20000725112934.A23143@keymaster.enme.ucalgary.ca> <200007251833.NAA21781@cj20424-a.reston1.va.home.com> Message-ID: <20000725151334.A24845@keymaster.enme.ucalgary.ca> On Tue, Jul 25, 2000 at 01:33:38PM -0500, Guido van Rossum wrote: > Actually, the recursive version works just fine for me. It's the > dependencies that aren't properly set. (Each .c file should depend on > most .h files, and that info is missing from the sub-Makefiles; the > toplevel Makefile just recurses into directories.) Isn't it a lot easier to maintain inter-directory dependencies with a non-recursive Makefile? Also, build times should be quicker. Perhaps it is not worth the effort. Neil From trentm at ActiveState.com Tue Jul 25 23:28:05 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 14:28:05 -0700 Subject: [Python-Dev] patches activity In-Reply-To: <200007252159.QAA24008@cj20424-a.reston1.va.home.com> References: <200007252110.QAA24625@server1.lfw.org> <200007252159.QAA24008@cj20424-a.reston1.va.home.com> Message-ID: <20000725142804.A7183@ActiveState.com> On Tue, Jul 25, 2000 at 04:59:43PM -0500, Guido van Rossum wrote: > I take it that Ping's script to scrape patches works, and the SF folks > have fixed the sending of email on changed patches. So now we get > every notification twice. As well, would it be possible in your processing to normalize text paragraphs to 80 columns. nit nit nit Thanks, Trent p.s. Thanks for doing this, Ping. It helps a lot. -- Trent Mick TrentM at ActiveState.com From guido at beopen.com Wed Jul 26 00:32:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 17:32:36 -0500 Subject: [Python-Dev] patches activity In-Reply-To: Your message of "Tue, 25 Jul 2000 14:28:05 MST." <20000725142804.A7183@ActiveState.com> References: <200007252110.QAA24625@server1.lfw.org> <200007252159.QAA24008@cj20424-a.reston1.va.home.com> <20000725142804.A7183@ActiveState.com> Message-ID: <200007252232.RAA24277@cj20424-a.reston1.va.home.com> > > As well, would it be possible in your processing to normalize text paragraphs > to 80 columns. nit nit nit > Code for that is in IDLE: Tools/idle/FormatParagraph.py, function reformat_paragraph(). > p.s. Thanks for doing this, Ping. It helps a lot. Yes! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From mal at lemburg.com Tue Jul 25 23:45:25 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 25 Jul 2000 23:45:25 +0200 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> <002001bff666$832b18c0$f2a6b5d4@hagrid> Message-ID: <397E0A75.6F49041E@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > Wouldn't it make much more sense to write something > > more lambda function like, e.g. > > > > [for (x,y) in zip([10,20,30], [1,2,3]): x+y] > > > > or > > > > [for x in range(100): x*2] > > fwiw, I read that as: > > [ > for x in range(100): > x * 2 > ] > > which makes no sense at all. Why doesn't that make sense ? Is this just a gut feeling or explainable ? IMHO, the meaning of the differen parts is intuitively understandable from the fact that Python's standard "for" notation works in the same way. OTOH, the notation "x*2 for x in range(100)" looks strange to me and probably to others too, because it doesn't make clear what "x" really refers to until you read on... this is Python not Forth or Haskell ! BTW, is it the missing append operator (the one that pushes x*2 onto the list) that's bothering you ? Note that we could also extend the above by allowing multiple such constructs separated by commas: data = (1.3, 1.2, 1.1) l = [for x in data: 3*x, for x in data: x/10] -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Tue Jul 25 23:47:05 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 17:47:05 -0400 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <002101bff67b$7fba7680$f2a6b5d4@hagrid> Message-ID: I didn't read this because it doesn't have PEP202 in the Subject line <0.9 wink>. Nevertheless, FWIW, I prefer [(x, x*2) for x in seq] too. > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Fredrik Lundh > Sent: Tuesday, July 25, 2000 5:01 PM > To: Skip Montanaro > Cc: python-dev at python.org > Subject: Re: [Python-Dev] List comprehension syntax (Features for Python > 2.0) > > > skip wrote: > > Fredrik> yes. > > > > That was my initial reaction, which was why I didn't post it > when I had the > > idea, only when I saw your interpretation... > > fwiw, the syntax implemented by the patch is the best > one I've seen this far. it wasn't that syntax I had in mind > when I talked about list confusions... > > ::: > > however, I think I prefer > > [(x, x*2) for x in seq] > > over > > [x, x*2 for x in seq] > > (it doesn't only help me scan it, it also simplifies a piece of > code that I happen to have here...) > > the bot says +0. > > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev From esr at thyrsus.com Tue Jul 25 23:57:59 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 17:57:59 -0400 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <397DC78B.B31FF0CE@lemburg.com>; from mal@lemburg.com on Tue, Jul 25, 2000 at 06:59:55PM +0200 References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> Message-ID: <20000725175759.B2019@thyrsus.com> M.-A. Lemburg : > I believe the above would cause much less confusion since > it resembles standard Python "for" loop notation (making it > intuitive for Python programmers) and is in syntax very > similar to what "lambda" uses: > > lambda : > > List comprehension would then become something like: > > [for in : ] I agree with this proposal. It harmonizes well with the use of applicative or functional notation. -- Eric S. Raymond To make inexpensive guns impossible to get is to say that you're putting a money test on getting a gun. It's racism in its worst form. -- Roy Innis, president of the Congress of Racial Equality (CORE), 1988 From esr at thyrsus.com Tue Jul 25 23:59:37 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 17:59:37 -0400 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <14717.57165.155081.532709@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 25, 2000 at 01:41:17PM -0500 References: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> <397DC78B.B31FF0CE@lemburg.com> <002001bff666$832b18c0$f2a6b5d4@hagrid> <14717.57165.155081.532709@beluga.mojam.com> Message-ID: <20000725175937.C2019@thyrsus.com> Skip Montanaro : > It occurred to me a little bit ago to suggest that we just allow complete > statements within list constructors. The semantics would be that any > objects left on the stack at the end of the statements would constitute the > elements of the list. Is that too weird? Not only is it non-weird, I think it is finally pushing in the right direction. -- Eric S. Raymond Rapists just *love* unarmed women. And the politicians who disarm them. From esr at thyrsus.com Wed Jul 26 00:08:18 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:08:18 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725153706.B11657@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Tue, Jul 25, 2000 at 03:37:06PM -0400 References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> Message-ID: <20000725180818.D2019@thyrsus.com> Andrew Kuchling : > On Tue, Jul 25, 2000 at 03:28:32PM -0400, Eric S. Raymond wrote: > >[x**2 for x in filter(isprime, range(1, 99)] > ... > >filter, zip, product, and lambda are good enough to cover anything the > >presently proposed comprehension syntax can handle. > > ... but not so elegantly, if the filter needs variables from the > current scope. Consider removing all numbers in that range that are a > multiple of a variable 'n'; you'd have to write: > > [x**2 for x in filter(lambda x, number = n: (x%n)!=0, range(1,99)) ] > > This uses the default argument hack to pass the value of 'n' into the > scope of the lambda-created function as the parameter 'number'. > Icky... I'd rather see extra syntax than more use of this kludge! Wrong answer. The right answer is to fix lambda (or some variant of lambda) to be a true lexical closure. -- Eric S. Raymond Question with boldness even the existence of a God; because, if there be one, he must more approve the homage of reason, than that of blindfolded fear.... Do not be frightened from this inquiry from any fear of its consequences. If it ends in the belief that there is no God, you will find incitements to virtue in the comfort and pleasantness you feel in its exercise... -- Thomas Jefferson, in a 1787 letter to his nephew From akuchlin at mems-exchange.org Wed Jul 26 00:01:16 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 25 Jul 2000 18:01:16 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180818.D2019@thyrsus.com>; from esr@thyrsus.com on Tue, Jul 25, 2000 at 06:08:18PM -0400 References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> Message-ID: <20000725180116.A12239@kronos.cnri.reston.va.us> On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond wrote: >Wrong answer. The right answer is to fix lambda (or some variant of lambda) >to be a true lexical closure. Hm... hmmmm... fixing this has been suggested before, but always foundered on the fact that creating a closure required a cycle, which would leak memory. Now we have an optional GC that should handle this, so maybe fixing it can be revisited. (But this would mean that GC is essentially no longer optional -- maybe too radical a thing to do before we're sure about the new GC. 2.1, maybe?) --amk From esr at thyrsus.com Wed Jul 26 00:14:22 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:14:22 -0400 Subject: [PEP 202] Re: [Python-Dev] Product iteration In-Reply-To: <14717.60868.260948.186346@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 25, 2000 at 02:43:00PM -0500 References: <20000725152832.A2019@thyrsus.com> <14717.60868.260948.186346@beluga.mojam.com> Message-ID: <20000725181422.E2019@thyrsus.com> Skip Montanaro : > Part of the motivation for list comprehensions as I recall is that we'd like > to get away from such a strong reliance on map, reduce and filter. In that case, the the lesson is that this is a bad road to go down. The cost of moving away from a functional syntax, in this case, seems to be dubious thickets of syntactic ugliness, Mind you, I'm not a functional-language bigot; I'm not after turning Python into LISP. Python has taught me the limits of the LISP approach to the world. But I think the lesson from this particular debate is that it's not really possible to do better than functional syntax for expressing the kinds of things that want to go on the right side of a comprehension. -- Eric S. Raymond Live free or die; death is not the worst of evils. -- General George Stark. From tim_one at email.msn.com Wed Jul 26 00:08:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 18:08:47 -0400 Subject: [PEP202 listcomps] (was RE: [Python-Dev] List comprehension syntax (Features for Python 2.0)) In-Reply-To: <397E0A75.6F49041E@lemburg.com> Message-ID: [MAL, on /F's complaints about [for x in range(100): x*2] ] > ... > IMHO, the meaning of the differen parts is intuitively > understandable from the fact that Python's standard "for" > notation works in the same way. > > OTOH, the notation "x*2 for x in range(100)" looks strange to me > and probably to others too, because it doesn't make clear what "x" > really refers to until you read on... this is Python not Forth or > Haskell ! The feature is taken from Haskell, which in turn adapted it from SETL. Both follow the long-established ordering of mathematical set-builder notation, where the *expression* is leftmost. It's the expression that's important, not the incidental details of the iterators -- there's more than a century of user experience behind that <0.6 wink>. I'll note that everything "looks strange" the first time you see it. It's more important that it feels right after you grasp it. That's the case here! When I see [x**2 for x in range(100)] I (being a left-to-right reader) immediately grasp "ah, it's a list of squares". Write it [for x in range(100): x*2] and it's simply harder to grasp (indeed, *that* "looks strange" to me -- it looks like somebody started to write a "for" loop and made a typo). In any case, this particular point was debated to death more than a year ago, and Guido already Pronounced on it. > ... > Note that we could also extend the above by allowing multiple > such constructs separated by commas: > > data = (1.3, 1.2, 1.1) > l = [for x in data: 3*x, > for x in data: x/10] Sure, and we could write u[...] for Unicode lists too . I see no advantage in the above over the simpler construct, i.e. l = [3*x for x in data] + [x/10 for x in data] except that it may be easier for a dirt-dumb implementation to optimize the former. From jeremy at beopen.com Wed Jul 26 00:15:31 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 18:15:31 -0400 (EDT) Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us> References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: <14718.4483.735535.296724@bitdiddle.concentric.net> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond AMK> wrote: >> Wrong answer. The right answer is to fix lambda (or some variant >> of lambda) to be a true lexical closure. AMK> Hm... hmmmm... fixing this has been suggested before, but AMK> always foundered on the fact that creating a closure required a AMK> cycle, which would leak memory. Now we have an optional GC AMK> that should handle this, so maybe fixing it can be revisited. AMK> (But this would mean that GC is essentially no longer optional AMK> -- maybe too radical a thing to do before we're sure about the AMK> new GC. 2.1, maybe?) I was thinking this would be a post 2.0 PEP. Jeremy From esr at thyrsus.com Wed Jul 26 00:26:28 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:26:28 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Tue, Jul 25, 2000 at 06:01:16PM -0400 References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: <20000725182628.H2019@thyrsus.com> Andrew Kuchling : > On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond wrote: > >Wrong answer. The right answer is to fix lambda (or some variant of lambda) > >to be a true lexical closure. > > Hm... hmmmm... fixing this has been suggested before, but always > foundered on the fact that creating a closure required a cycle, which > would leak memory. Now we have an optional GC that should handle > this, so maybe fixing it can be revisited. (But this would mean that > GC is essentially no longer optional -- maybe too radical a thing to > do before we're sure about the new GC. 2.1, maybe?) I think there's enough controversy about comprehensions at this point to warrant not rushing out an implementation we might regret. (Heh. Look at me telling *Guido* to go slow and careful...heh.) -- Eric S. Raymond To make inexpensive guns impossible to get is to say that you're putting a money test on getting a gun. It's racism in its worst form. -- Roy Innis, president of the Congress of Racial Equality (CORE), 1988 From mwh21 at cam.ac.uk Wed Jul 26 00:19:05 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 25 Jul 2000 23:19:05 +0100 Subject: [Python-Dev] Product iteration In-Reply-To: "Eric S. Raymond"'s message of "Tue, 25 Jul 2000 18:08:18 -0400" References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> Message-ID: "Eric S. Raymond" writes: > Wrong answer. The right answer is to fix lambda (or some variant of > lambda) to be a true lexical closure. And presumably local functions too? Otherwise that's also the wrong answer... Cheers, M. -- 40. There are two ways to write error-free programs; only the third one works. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html From esr at thyrsus.com Wed Jul 26 00:33:18 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:33:18 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <14717.55012.596068.67219@beluga.mojam.com>; from skip@mojam.com on Tue, Jul 25, 2000 at 01:05:24PM -0500 References: <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> <200007251751.MAA21417@cj20424-a.reston1.va.home.com> <20000725130135.G32196@kronos.cnri.reston.va.us> <14717.55012.596068.67219@beluga.mojam.com> Message-ID: <20000725183318.I2019@thyrsus.com> Skip Montanaro : > The only thing that's needed to use the current bsddb module interface with > libdb 2.x is to include db_185.h instead of db.h. You don't get all the 2.x > functionality, but you do get the less buggy libdb implementation. I've > been using it like that for a couple years. It shouldn't be difficult to write a configure test to autoconfigure this. But I think a previous poster was right to suggest writing a custom interface for the 3.x code instead. -- Eric S. Raymond "Rightful liberty is unobstructed action, according to our will, within limits drawn around us by the equal rights of others." -- Thomas Jefferson From esr at thyrsus.com Wed Jul 26 00:35:22 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 18:35:22 -0400 Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725124651.F32196@kronos.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Tue, Jul 25, 2000 at 12:46:51PM -0400 References: <20000724200717.A32163@thyrsus.com> <20000724201721.A9990@newcnri.cnri.reston.va.us> <20000724203555.A32412@thyrsus.com> <20000725113241.D32196@kronos.cnri.reston.va.us> <14717.46330.703979.141406@cj42289-a.reston1.va.home.com> <20000725120327.D1785@thyrsus.com> <14717.47253.118639.700872@cj42289-a.reston1.va.home.com> <20000725120319.E32196@kronos.cnri.reston.va.us> <14717.49262.480392.948763@bitdiddle.concentric.net> <20000725124651.F32196@kronos.cnri.reston.va.us> Message-ID: <20000725183522.J2019@thyrsus.com> Andrew Kuchling : > I think the only solution is to do the job right and do #4, though it > might wind up being postponed until Python 2.1, or whatever comes > after 2.0. I'm inclined to agree...sadly, I don't yet have the chops to do this myself. -- Eric S. Raymond The right to buy weapons is the right to be free. -- A.E. Van Vogt, "The Weapon Shops Of Isher", ASF December 1942 From trentm at ActiveState.com Wed Jul 26 00:39:12 2000 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 25 Jul 2000 15:39:12 -0700 Subject: [Python-Dev] Summary or failing regression tests... Message-ID: <20000725153912.A21409@ActiveState.com> Here is a list of the regrtests that are currently failing for me on Linux32 and Win32. Is anybody looking at test_mmap, test_userstring, test_winreg, and test_winreg2? Skip, You and Jeremy(?) were talking about test_posixpath on Linux. It looks like the sames errors you were talking about occur on Win32. I didn't look too closely, can you? Fredrik, are you aware of the test_sre failure on Win32? Am I doing something wrong to be getting this? On Linux32: - test_fork1 This fails/hangs/crashes inconsistently because (some little bird told me) the fork stuff and threads are incompatible. Am I right? Now that we are turning threads on by default what is the proper thing to do here? SHould test_fork1 be changed to skip if threads are enabled? On Win32: - test_mmap one liner: test test_mmap crashed -- exceptions.WindowsError : [Errno 6] The handle is invalid full output: Position of foo: 1.0 pages Length of file: 2.0 pages Contents of byte 0: '\000' Contents of first 3 bytes: '\000\000\000' Modifying file's content... Contents of byte 0: '3' Contents of first 3 bytes: '3\000\000' Contents of second page: foobar Regex match on mmap (page start, length of match): 1.0 6 Seek to zeroth byte Seek to 42nd byte Seek to last byte Try to seek to negative position... Try to seek beyond end of mmap... Try to seek to negative position... Attempting resize() Traceback (most recent call last): File "..\Lib\test\test_mmap.py", line 114, in ? test_both() File "..\Lib\test\test_mmap.py", line 100, in test_both m.resize( 512 ) WindowsError: [Errno 6] The handle is invalid - test_posixpath one liner: test test_posixpath failed -- Writing: 'error!', expected: 'No err' full output: error! evaluated: posixpath.commonprefix(["/home/swenson/spam", "/home/swen/spam"]) should be: /home returned: /home/swen error! evaluated: posixpath.commonprefix(["/home/swen/spam", "/home/swen/eggs"]) should be: /home/swen returned: /home/swen/ 2 errors. - test_re one liner: test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou" full output: Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Traceback (most recent call last): File "..\Lib\test\test_re.py", line 122, in ? raise TestFailed, "symbolic reference" test_support.TestFailed: symbolic reference discussion: This has been discussed a litle by Mark Favas and Jeremy with no conclusion. http://www.python.org/pipermail/python-dev/2000-July/013963.html - test_sre one liner: test test_sre failed -- Writing: '=== Failed incorrectly', expected: "===grouping error ('(" full output: Running tests on sre.search and sre.match Running tests on sre.sub Running tests on symbolic references Traceback (most recent call last): File "..\Lib\test\test_sre.py", line 124, in ? raise TestFailed, "symbolic reference" test_support.TestFailed: symbolic reference discussion: This has been discussed a litle by Mark Favas and Jeremy with no conclusion http://www.python.org/pipermail/python-dev/2000-July/013963.html - test_userstring one liner: test test_userstring failed -- Writing: "'a'", expected: '' full output: 'a' <> 'A' <> '\012' <> 'abc' <> 'aBc123' <> 'abc\012' <> 'a' <> 'A' <> '\012' <> '123abc456' <> 'a1b3c' <> 'aBc000 ' <> 'abc\012' <> - test_winreg one liner: test test_winreg failed -- Unread: '\012' full output: (this works when run standalone) - test_winreg2 (crashes) full output: Fatal Python error: PyThreadState_Get: no current thread abnormal program termination Thanks, Trent -- Trent Mick TrentM at ActiveState.com From nowonder at pool.informatik.rwth-aachen.de Wed Jul 26 02:47:21 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Wed, 26 Jul 2000 00:47:21 +0000 Subject: [Python-Dev] Summary or failing regression tests... References: <20000725153912.A21409@ActiveState.com> Message-ID: <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> Trent Mick wrote: > > On Linux32: > - test_fork1 > This fails/hangs/crashes inconsistently because (some little bird told me) > the fork stuff and threads are incompatible. Am I right? Now that we are > turning threads on by default what is the proper thing to do here? SHould > test_fork1 be changed to skip if threads are enabled? That works fine to me (--with-threads). Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From effbot at telia.com Wed Jul 26 00:55:27 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 00:55:27 +0200 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs machine with >= 32bit longs References: <20000725112713.D577@ActiveState.com> Message-ID: <004801bff68b$6e364280$f2a6b5d4@hagrid> trent wrote: > I was assigned this patch a while back to try on some 64-bit systems. Fine, I > can do that but I have since seen a number of message on python-dev regarding > it: > > - Fredrik had a new, better replacement? Fredrik? my patch is here: http://w1.132.telia.com/~u13208596/uninames-patch.txt (it's ~600k, which is more than sourceforge can handle) if you have some time to spare, feel tree to try it out on your favourite 64-bit platform (I haven't had time to test it on our alphas, but I'm pretty sure it'll work). the patch doesn't update the build files, so you need to do some manual tweaking to make sure the unicodenames module is built. if everything works as it should, the resulting interpreter should survive test_ucn.py even if ucnhash.pyd (.so) is nowhere to be seen... From effbot at telia.com Wed Jul 26 01:00:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 01:00:58 +0200 Subject: [Python-Dev] Summary or failing regression tests... References: <20000725153912.A21409@ActiveState.com> Message-ID: <005601bff68c$340d3b80$f2a6b5d4@hagrid> trent wrote: > Fredrik, are you aware of the test_sre failure on Win32? Am I doing something > wrong to be getting this? > Traceback (most recent call last): > File "..\Lib\test\test_sre.py", line 124, in ? > raise TestFailed, "symbolic reference" > test_support.TestFailed: symbolic reference hmm. *I* don't get that error (Win32, MSVC 5.0). If everything works as it should, test_re and test_sre should produce what's in output/test_s?re does anyone else see this error on Linux? From trentm at activestate.com Wed Jul 26 00:55:00 2000 From: trentm at activestate.com ('Trent Mick') Date: Tue, 25 Jul 2000 15:55:00 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD329@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD329@RED-MSG-50> Message-ID: <20000725155500.B21409@ActiveState.com> On Tue, Jul 25, 2000 at 12:08:57PM -0700, Bill Tutt wrote: > Well, Fredrik's changes aren't checked in yet, so checking it all in doesn't > hurt. > > The other relevant question is since Fredrik's code will eventually get in, > do we want to yank the code that generates it? > (Tools/perfecthash) If we keep it, then that part of the patch should go in. > If we don't keep it, that's fine too. > > You'd need to test it on Linux64. Win64's integer types are 32bits, and the > C code doesn't use long longs. > The easiest way of testing it of course is to apply the ucnhash.c patch to > your tree and run test_ucn.py. :) Okay. I tried it and with the patch test_ucn.py passes fine. I am going to add a comment to the patch on SourceForge and then assigned it back to.... hmmmm... eenie meenie minie... Bill! Is that alright? Trent -- Trent Mick TrentM at ActiveState.com From billtut at microsoft.com Wed Jul 26 00:53:22 2000 From: billtut at microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 15:53:22 -0700 Subject: [PEP 202] Re: [Python-Dev] Product iteration Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32C@RED-MSG-50> > From: Eric S. Raymond [mailto:esr at thyrsus.com] > Skip Montanaro : > > Part of the motivation for list comprehensions as I recall is that we'd like > > to get away from such a strong reliance on map, reduce and filter. > In that case, the the lesson is that this is a bad road to go down. > The cost of moving away from a functional syntax, in this case, seems > to be dubious thickets of syntactic ugliness, > Mind you, I'm not a functional-language bigot; I'm not after turning Python > into LISP. Python has taught me the limits of the LISP approach to the world. > But I think the lesson from this particular debate is that it's not really > possible to do better than functional syntax for expressing the kinds of things > that want to go on the right side of a comprehension. Amen. I personally liked the Haskell syntax Jeremy posted earlier. It just makes sense visually. Bill From nascheme at enme.ucalgary.ca Wed Jul 26 00:57:28 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 25 Jul 2000 16:57:28 -0600 Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us>; from Andrew Kuchling on Tue, Jul 25, 2000 at 06:01:16PM -0400 References: <20000725152832.A2019@thyrsus.com> <20000725153706.B11657@kronos.cnri.reston.va.us> <20000725180818.D2019@thyrsus.com> <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: <20000725165728.A25611@keymaster.enme.ucalgary.ca> On Tue, Jul 25, 2000 at 06:01:16PM -0400, Andrew Kuchling wrote: > On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond wrote: > >Wrong answer. The right answer is to fix lambda (or some variant of lambda) > >to be a true lexical closure. > > Hm... hmmmm... fixing this has been suggested before, but always > foundered on the fact that creating a closure required a cycle, which > would leak memory. Now we have an optional GC that should handle > this, so maybe fixing it can be revisited. (But this would mean that > GC is essentially no longer optional -- maybe too radical a thing to > do before we're sure about the new GC. 2.1, maybe?) I would like to get the memory consumption down before making GC standard. Hopefully Vladimir and I can team up to accomplish this. still-waiting-for-my-home-machine-ly Neil From tim_one at email.msn.com Wed Jul 26 00:57:44 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 18:57:44 -0400 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: <20000725152832.A2019@thyrsus.com> Message-ID: [Eric S. Raymond] > ... > The right way to say > > [x**2 for x in range(1, 99) if isprime(x)] > > is like this: > > [x**2 for x in filter(isprime, range(1, 99)] > ... > If you notice that this looks a lot like LISP or F or Haskell, you win. Win some, lose some: the original looks much more like Haskell, from which Greg Ewing borrowed list comprehensions: [x**2, x <- [1..98], isprime(x)] (Note: that's from memory, as I don't have Haskell on my laptop; while a detail may be wrong (in particular, I don't recall how Haskell spells "square"), the thrust is not: Haskell allows an arbitrary sequence of iterators and predicates, exactly as does the proposal. It's formally defined in terms of expansion to masses of lambdas and applications, but the whole point to the Haskell spelling is to raise the expressiveness above the LISP level] > These languages got comprehensions right on the basis of a lot of > experience in depth. We can learn from their example. Indeed, we're trying to . This is much more a Haskell than a LISP feature, and follows Haskell in using special syntax to relieve the monotony of relentlessly uniform function composition. It derives in turn from SETL, which followed common set-theoretic notation. This "grabbed" Guido; LISP spellings never did, and I bet never will. Indeed, your latter spelling is so close to the current map(lambda x: x**2, filter(isprime, range(1, 99)) as to make little difference. From trentm at activestate.com Wed Jul 26 01:02:59 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 25 Jul 2000 16:02:59 -0700 Subject: [Python-Dev] Summary or failing regression tests... In-Reply-To: <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> Message-ID: <20000725160259.C21409@ActiveState.com> On Wed, Jul 26, 2000 at 12:47:21AM +0000, Peter Schneider-Kamp wrote: > Trent Mick wrote: > > > > On Linux32: > > - test_fork1 > > This fails/hangs/crashes inconsistently because (some little bird told me) > > the fork stuff and threads are incompatible. Am I right? Now that we are > > turning threads on by default what is the proper thing to do here? SHould > > test_fork1 be changed to skip if threads are enabled? > > That works fine to me (--with-threads). > 'test_fork1' works for me when run as: ./python Lib/test/regrtest.py but hangs when run as: ./python Lib/test/test_fork1.py or ./python Lib/test/regrtest.py test_fork1 I don't know why? Trent -- Trent Mick TrentM at ActiveState.com From tim_one at email.msn.com Wed Jul 26 01:03:59 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 19:03:59 -0400 Subject: Closures (was RE: [Python-Dev] Product iteration) In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > Hm... hmmmm... fixing this has been suggested before, but always > foundered on the fact that creating a closure required a cycle, which > would leak memory. Now we have an optional GC that should handle > this, so maybe fixing it can be revisited. (But this would mean that > GC is essentially no longer optional -- maybe too radical a thing to > do before we're sure about the new GC. 2.1, maybe?) Definitely PEP material: let's please, please, please not have this entire debate again. BTW, I'm having trouble believing the release schedule for 1.6 and 2.0 without this, so definitely post-2.0 on those grounds alone. From billtut at microsoft.com Wed Jul 26 01:03:00 2000 From: billtut at microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 16:03:00 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> Well, I can't check it in, so assigning it back to me would be fairly pointless. Someone should also chime in on the Tools/perfecthash stuff as well. If we want to keep it, I'll see if I can come up with an example using Python's tokens since the data set is way smaller. :) Bill -----Original Message----- From: 'Trent Mick' [mailto:trentm at activestate.com] Sent: Tuesday, July 25, 2000 3:55 PM To: Bill Tutt Cc: Jeremy Hylton; M . -A . Lemburg; Mark Favas; Fredrik Lundh; python-dev at python.org Subject: Re: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs On Tue, Jul 25, 2000 at 12:08:57PM -0700, Bill Tutt wrote: > Well, Fredrik's changes aren't checked in yet, so checking it all in doesn't > hurt. > > The other relevant question is since Fredrik's code will eventually get in, > do we want to yank the code that generates it? > (Tools/perfecthash) If we keep it, then that part of the patch should go in. > If we don't keep it, that's fine too. > > You'd need to test it on Linux64. Win64's integer types are 32bits, and the > C code doesn't use long longs. > The easiest way of testing it of course is to apply the ucnhash.c patch to > your tree and run test_ucn.py. :) Okay. I tried it and with the patch test_ucn.py passes fine. I am going to add a comment to the patch on SourceForge and then assigned it back to.... hmmmm... eenie meenie minie... Bill! Is that alright? Trent -- Trent Mick TrentM at ActiveState.com From trentm at activestate.com Wed Jul 26 01:06:37 2000 From: trentm at activestate.com ('Trent Mick') Date: Tue, 25 Jul 2000 16:06:37 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> Message-ID: <20000725160637.A21687@ActiveState.com> On Tue, Jul 25, 2000 at 04:03:00PM -0700, Bill Tutt wrote: > Well, I can't check it in, so assigning it back to me would be fairly > pointless. Very sneaky. I defaulted to Jeremy. Trent -- Trent Mick TrentM at ActiveState.com From guido at beopen.com Wed Jul 26 02:12:23 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 19:12:23 -0500 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs In-Reply-To: Your message of "Tue, 25 Jul 2000 16:03:00 MST." <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> Message-ID: <200007260012.TAA31561@cj20424-a.reston1.va.home.com> > Well, I can't check it in, so assigning it back to me would be fairly > pointless. Someone should also chime in on the Tools/perfecthash stuff as > well. If we want to keep it, I'll see if I can come up with an example > using Python's tokens since the data set is way smaller. :) I've learned from the sad NumPy experience that it's really bad to generate code and then throw away the generator and start editing the generated code... So please keep the generator up-to-date! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From bwarsaw at beopen.com Wed Jul 26 01:13:56 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 25 Jul 2000 19:13:56 -0400 (EDT) Subject: [PEP202 listcomps] (was RE: [Python-Dev] List comprehension syntax (Features for Python 2.0)) References: <397E0A75.6F49041E@lemburg.com> Message-ID: <14718.7988.542661.35195@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> I'll note that everything "looks strange" the first time you TP> see it. It's more important that it feels right after you TP> grasp it. It's the "Pink Floyd" syndrome. A new band of mine is searching for a name, and all of them seem dumb the first time you say them. 35 years and tens of millions of records later, and even "Pink Floyd" seems like a brilliant name for a band. hoping-to-have-the-same-problem-ly y'rs, -Barry From mhammond at skippinet.com.au Wed Jul 26 01:12:03 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 26 Jul 2000 09:12:03 +1000 Subject: [Python-Dev] Berkeley DB In-Reply-To: <20000725120319.E32196@kronos.cnri.reston.va.us> Message-ID: > Is it OK to add a SWIG-generated module to the core? That is a little tricky. Longer term it should be reasonable. However, there are a few reasonable objections that I will have trouble defending (the most obvious one being a more complex build system) > (I have an irrational dislike SWIG's trick of encoding pointers > as strings, I think your fear is completely rational! However, take heart in the fact that I have _many_ SWIG extension modules, and have _never_ had SWIG generate a pointer on me. It often takes some hoop jumping, and requires some hand-coded helpers, but SWIG still saves me time, while providing a rock-solid interface. If SWIG code does end up in the core, I would prefer to see SWIG pointers banned! Mark. From effbot at telia.com Wed Jul 26 01:21:14 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 01:21:14 +0200 Subject: [Python-Dev] Re: Summary or failing regression tests... References: <20000725153912.A21409@ActiveState.com> Message-ID: <007601bff68f$0871dfa0$f2a6b5d4@hagrid> as for your other errors (still on Win95, MSVC 5.0): > - test_mmap > one liner: > test test_mmap crashed -- exceptions.WindowsError : [Errno 6] The handle is invalid same here (but a different error code?) > - test_posixpath > one liner: > test test_posixpath failed -- Writing: 'error!', expected: 'No err' nope. > - test_re > one liner: > test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou" nope. but are you sure you've updated the output directory lately? the "=== Failed incorrectly" part is expected, the abc stuff is not. > Traceback (most recent call last): > File "..\Lib\test\test_re.py", line 122, in ? > raise TestFailed, "symbolic reference" > test_support.TestFailed: symbolic reference nope. > - test_sre > one liner: > test test_sre failed -- Writing: '=== Failed incorrectly', expected: "===grouping error ('(" nope. but again, the expected stuff looks wrong. > Traceback (most recent call last): > File "..\Lib\test\test_sre.py", line 124, in ? > raise TestFailed, "symbolic reference" > test_support.TestFailed: symbolic reference nope. > - test_userstring > one liner: > test test_userstring failed -- Writing: "'a'", expected: '' nope -- but the output indicates that you're testing against an old copy of UserString.py > > - test_winreg > one liner: > test test_winreg failed -- Unread: '\012' nope. > - test_winreg2 (crashes) > full output: > Fatal Python error: PyThreadState_Get: no current thread > > abnormal program termination almost. I got other interesting errors when I had an old winreg.pyd in the path. if I remove that one, the test runs, prints HKEY_CLASSES_ROOT, and then starts consuming 99.99% CPU (not sure if it terminates; I need my cycles for more important stuff...) From billtut at microsoft.com Wed Jul 26 01:14:03 2000 From: billtut at microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 16:14:03 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> The patch for the generator is up to date. The question is "Should we keep Tools/perfecthash in CVS after Fredrick checks in his new unicode name support?" Bill -----Original Message----- From: Guido van Rossum [mailto:guido at beopen.com] Sent: Tuesday, July 25, 2000 5:12 PM To: Bill Tutt Cc: python-dev at python.org Subject: Re: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs > Well, I can't check it in, so assigning it back to me would be fairly > pointless. Someone should also chime in on the Tools/perfecthash stuff as > well. If we want to keep it, I'll see if I can come up with an example > using Python's tokens since the data set is way smaller. :) I've learned from the sad NumPy experience that it's really bad to generate code and then throw away the generator and start editing the generated code... So please keep the generator up-to-date! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Wed Jul 26 02:19:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 19:19:05 -0500 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: Your message of "Tue, 25 Jul 2000 18:57:44 -0400." References: Message-ID: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> > It derives in turn from SETL, which followed common set-theoretic > notation. This "grabbed" Guido; LISP spellings never did, and I bet > never will. I've never used or even seen SETL, but there is a connection: SETL had a profound influence on the designers of ABC, in particular Lambert Meertens, who spent a sabbatical year working with the folks at New York University who wrote the first validated Ada compiler in SETL. (http://www.faqs.org/faqs/computer-lang/Ada/comp-lang-ada/part2/ question 4.2.2, to save you the Google search.) I happen to have a standing invitation to come give a talk there... Since I'm posting in this thread anyway, I am with Tim -- I like Greg Ewing's proposed syntax best, for the reasons Tim stated. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Wed Jul 26 02:23:12 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 19:23:12 -0500 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs In-Reply-To: Your message of "Tue, 25 Jul 2000 16:14:03 MST." <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> Message-ID: <200007260023.TAA31667@cj20424-a.reston1.va.home.com> > The patch for the generator is up to date. The question is "Should we keep > Tools/perfecthash in CVS after Fredrick checks in his new unicode name > support?" Oh, never mind. I'd say keep it around -- it's a cool thing for which eventually someone will find a use! (But it should really be up to Andrew -- if he prefers to have it on his webpage instead, we should honor that.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From effbot at telia.com Wed Jul 26 01:27:17 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 01:27:17 +0200 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32D@RED-MSG-50> <200007260012.TAA31561@cj20424-a.reston1.va.home.com> Message-ID: <009101bff691$d9b3e700$f2a6b5d4@hagrid> guido wrote: > > Well, I can't check it in, so assigning it back to me would be fairly > > pointless. Someone should also chime in on the Tools/perfecthash stuff as > > well. If we want to keep it, I'll see if I can come up with an example > > using Python's tokens since the data set is way smaller. :) > > I've learned from the sad NumPy experience that it's really bad to > generate code and then throw away the generator and start editing the > generated code... So please keep the generator up-to-date! note that if #100899 goes in instead, Bill's tweak of Andrew's original code won't be needed for anything related to unicode. the perfect hash module is still a useful tool (not that I ever got it to do a decent job on the unicode database. Bill's either very lucky, or he's got a really fast computer... ;-) From akuchlin at cnri.reston.va.us Wed Jul 26 01:58:28 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 25 Jul 2000 19:58:28 -0400 Subject: [Python-Dev] is this obsolete? In-Reply-To: <200007260023.TAA31667@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Tue, Jul 25, 2000 at 07:23:12PM -0500 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> <200007260023.TAA31667@cj20424-a.reston1.va.home.com> Message-ID: <20000725195828.A19959@newcnri.cnri.reston.va.us> On Tue, Jul 25, 2000 at 07:23:12PM -0500, Guido van Rossum wrote: >Oh, never mind. I'd say keep it around -- it's a cool thing for which >eventually someone will find a use! (But it should really be up to >Andrew -- if he prefers to have it on his webpage instead, we should >honor that.) It seems too esoteric to take up space in the Tools/ directory, so I'd suggest taking it out. I'll look at Bill's changes and grab interesting bits for my copy, though. --amk From effbot at telia.com Wed Jul 26 02:09:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 02:09:48 +0200 Subject: [Python-Dev] decoding errors when comparing strings Message-ID: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> (revisiting an old thread on mixed string comparisions) summary: the current interpreter throws an "ASCII decoding error" exception if you compare 8-bit and unicode strings, and the 8-bit string happen to contain a character in the 128-255 range. this is not only confusing for users, it also confuses the hell out of Python itself. for example: >>> a = u"?" >>> b = "?" >>> hash(a) -283818363 >>> hash(b) -283818363 >>> a == b Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII decoding error: ordinal not in range(128) >>> d = {} >>> d[a] = "a" >>> d[b] = "b" >>> len(d) UnicodeError: ASCII decoding error: ordinal not in range(128) oops. ::: it's clear that we should do something about this, but it's not entirely clear what do to. quoting from the earlier thread: [paul] > As soon as you find a character out of the ASCII range in one of the > strings, I think that you should report that the two strings are > unequal. [me] > sounds reasonable -- but how do you flag "unequal" in cmp? which > value is "larger" if all that we know is that they're different... [moshe] > We can say something like "beyond the ASCII range, every unicode character > is larger then any regular 8-bit character", and compare > lexicographically. [mal] > The usual method in the Python compare logic is to revert to > the type name for compares in case coercion fails... I think > this is the right description in this case: decoding fails and > thus coercion becomes impossible. > > PyObject_Compare() has the logic, we'd just have to reenable > it for Unicode which currently is handled as special case to > pass through the decoding error. > > Note that Unicode objects which don't coerce would then always > compare larger than 8-bit strings ("unicode" > "string"). ::: having digested this for a week or two, I'm leaning towards moshe's proposal. even if mal's proposal will give the same result in practice, I'm not entirely happy with the idea that the actual contents of a variable (and not just its type) should determine whether the "last resort" type name comparision should be used. a third alternative would be to keep the exception, and make the dictionary code exception proof. having looked at the code, I'm afraid this might be easier said than done... ::: comments? From billtut at microsoft.com Wed Jul 26 02:27:09 2000 From: billtut at microsoft.com (Bill Tutt) Date: Tue, 25 Jul 2000 17:27:09 -0700 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs mach ine with >= 32bit longs Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD330@RED-MSG-50> > From: Fredrik Lundh [mailto:effbot at telia.com] > note that if #100899 goes in instead, Bill's tweak of Andrew's > original code won't be needed for anything related to unicode. > the perfect hash module is still a useful tool (not that I ever > got it to do a decent job on the unicode database. Bill's either > very lucky, or he's got a really fast computer... ;-) The secret to getting it to work is to start with a high step rate, find your initial solution so you can test code. Then you set the code up to search for a smaller solution while you're off doing weekend things. Given the number of Unicode character names there wasn't any other way to do it. Smaller key spaces may not care about finding a smaller multiplier solution. I do like my work computer though. Dual 733Mhz with 512MB of ram. Have to have lots of ram to test a web app that caches 30 MB of data out of the database, while still running DevStudio, VSS, etc.... :) Bill From guido at beopen.com Wed Jul 26 05:02:14 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 22:02:14 -0500 Subject: [Python-Dev] is this obsolete? In-Reply-To: Your message of "Tue, 25 Jul 2000 19:58:28 -0400." <20000725195828.A19959@newcnri.cnri.reston.va.us> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD32E@RED-MSG-50> <200007260023.TAA31667@cj20424-a.reston1.va.home.com> <20000725195828.A19959@newcnri.cnri.reston.va.us> Message-ID: <200007260302.WAA31854@cj20424-a.reston1.va.home.com> > It seems too esoteric to take up space in the Tools/ directory, so I'd > suggest taking it out. I'll look at Bill's changes and grab > interesting bits for my copy, though. OK. Please take it out yourself! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Wed Jul 26 05:11:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 25 Jul 2000 22:11:05 -0500 Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: Your message of "Wed, 26 Jul 2000 02:09:48 +0200." <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> Message-ID: <200007260311.WAA31872@cj20424-a.reston1.va.home.com> > (revisiting an old thread on mixed string comparisions) I think it's PEP time for this one... > summary: the current interpreter throws an "ASCII decoding > error" exception if you compare 8-bit and unicode strings, and > the 8-bit string happen to contain a character in the 128-255 > range. Doesn't bother me at all. If I write a user-defined class that raises an exception in __cmp__ you can get the same behavior. The fact that the hashes were the same is a red herring; there are plenty of values with the same hash that aren't equal. I see the exception as a useful warning that the program isn't sufficiently Unicode aware to work correctly. That's a *good* thing in my book -- I'd rather raise an exception than silently fail. Note that it can't break old code unless you try to do new things with the old code: the old code coudn't have supported Unicode because it doesn't exist in Python 1.5.2. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From greg at cosc.canterbury.ac.nz Wed Jul 26 04:49:16 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 14:49:16 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: Message-ID: <200007260249.OAA09513@s454.cosc.canterbury.ac.nz> Moshe Zadka said: > [x; for x in seq] > > and > > [x: for x in seq] Having both the separator and the following 'for' looks somewhat redundant to my eyes. By the way, have people tried looking at some examples in an editor with syntax highlighting? You may find that the various parts stand out more clearly then -- I certainly do. > And what about > > [x+y for x in seq1 for y in seq2 if y>2 if x<3] > > or > > [x+y for x in seq1 if x<3 for y in seq2 if y>2] > > What is allowed? Both are allowed, and both are useful. They produce the same result, but the second one is more efficient. So you can either write declaratively and not worry about the order, or if you're concerned about speed, you can fine-tune the order of the clauses. > Aren't we being a bit too TIMTOWTDIish here? No more than being able to say either x = (a+b); y = (c+d); h = sqrt(x*x + y*y) or h = sqrt((a+b)*(a+b) + (c+d)*(c+d)) Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From greg at cosc.canterbury.ac.nz Wed Jul 26 04:52:31 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 14:52:31 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: <005e01bff63f$9bbb9e40$f2a6b5d4@hagrid> Message-ID: <200007260252.OAA09516@s454.cosc.canterbury.ac.nz> > did Python just turn into something that is much harder to parse? Guido has already answered this, but just to make sure, I tried it out on my test implementation: s454% ./python Python 1.5.2 (#11, Sep 11 1999, 16:11:20) [GCC 2.8.1] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> seq = [1,2,3,4,5] >>> [x, x*2 for x in seq] [(1, 2), (2, 4), (3, 6), (4, 8), (5, 10)] >>> Yep, it works! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From greg at cosc.canterbury.ac.nz Wed Jul 26 04:59:14 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 14:59:14 +1200 (NZST) Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <20000725110000.C577@ActiveState.com> Message-ID: <200007260259.OAA09520@s454.cosc.canterbury.ac.nz> Trent Mick suggested: > [for x in [10,20,30]: for y in [1,2,3]: x+y] When designing the syntax, I decided to put the target expression first, because I wanted it to read declaratively. Also I think it's clearer when you can see right up front what it's going to be a list *of*. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From greg at cosc.canterbury.ac.nz Wed Jul 26 05:03:07 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 15:03:07 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: <14717.57165.155081.532709@beluga.mojam.com> Message-ID: <200007260303.PAA09523@s454.cosc.canterbury.ac.nz> Skip Montanaro suggested: > we just allow complete > statements within list constructors. The semantics would be that any > objects left on the stack at the end of the statements would constitute the > elements of the list. Is that too weird? It's too procedural, and too Forth-like. I think it's actually an advantage that the iterator clauses don't look *exactly* like their procedural counterparts, because it's less likely to fool you into thinking that you can put arbitrary statements there. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From greg at cosc.canterbury.ac.nz Wed Jul 26 05:07:10 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 15:07:10 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: <20000725152832.A2019@thyrsus.com> Message-ID: <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> "Eric S. Raymond" said: > What they want to be is an applicative sublanguage in functional > style Um, that might be what *you* want them to be, but it's the complete opposite of what *I* want them to be, which is a way of getting away from all those convoluted combinator constructs! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From gvwilson at nevex.com Wed Jul 26 05:08:49 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 25 Jul 2000 23:08:49 -0400 (EDT) Subject: [Python-Dev] list comprehension quiz Message-ID: Hi, folks. In order to put the list comprehension syntax questionnaire together, I would be grateful if anyone with a favorite syntax could send me their equivalent of the following scraps of Python (or other scraps and their equivalents, if you think there are interesting cases that I'm not covering). In order to save bandwidth, please mail me directly --- I will summarize and post the questionnaire itself. Thanks, Greg -- 1 ---------------------------------------- input = [1, 2, 3, 4, 5] output = [] for num in input: output.append(2 * num) >>> [2, 4, 6, 8, 10] -- 2 ---------------------------------------- input = [1, 2, 3, 4, 5] output = [] for num in input: if is_odd(num): output.append(num) >>> [1, 3, 5] -- 3 ---------------------------------------- input = [1, 2, 3, 4, 5] output = 0 for num in input: output = output + num >>> 15 -- 4 ---------------------------------------- tens = [10, 20, 30] units = [ 1, 2] output = [] for t in tens: for u in units: output.append(u + t) >>> [11, 12, 21, 22, 31, 32] -- 5 ---------------------------------------- tens = [10, 20, 30] units = [ 1, 2, 3, 4, 5] output = [] lim = min(len(tens), len(units)) for i in range(0, lim): output.append(max(tens[i], units[i])) >>> [10, 20, 30] -- 6 ---------------------------------------- phones = {229 : 'Greg', 231 : 'Toni', 268 : 'Jaq', 271 : 'Hassan'} output = [] for p in phones.keys(): if p > 250: output.append(phones[p]) >>> ['Hassan', 'Jaq'] From greg at cosc.canterbury.ac.nz Wed Jul 26 05:12:54 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 15:12:54 +1200 (NZST) Subject: [Python-Dev] Names for things In-Reply-To: <14718.7988.542661.35195@anthem.concentric.net> Message-ID: <200007260312.PAA09530@s454.cosc.canterbury.ac.nz> bwarsaw at beopen.com (Barry A. Warsaw): > 35 years and tens of millions of records later, and even "Pink Floyd" seems > like a brilliant name for a band. And "Monty Python" is such an obviously good name for a comedy show... and "Python" for a programming language! Guido obviously used his time machine to plant the name in our minds a few decades ago to give us time to get used to the idea. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From tim_one at email.msn.com Wed Jul 26 05:11:53 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 25 Jul 2000 23:11:53 -0400 Subject: [Python-Dev] Features for Python 2.0 In-Reply-To: <200007251647.LAA20899@cj20424-a.reston1.va.home.com> Message-ID: [Greg Wilson] > I would also like to volunteer to repeat the "simultaneous loop" syntax > experiment with list comprehensions, i.e. see whether what's being > proposed lines up with people's pre-existing intuitions. [Guido] > Please do! > > Though I have no doubt of the outcome: > > [x+y for x in [10, 20, 30] for y in [1, 2, 3]] > > will be almost universally understood to mean > > [11, 12, 13, 21, 22, 23, 31, 32, 33]. I'm not sure about that! Greg hangs out with functional programmers and old Fortran-heads. Fortran has a handy construct called "implied DO (loops)" in I/O statements, and in those the *innermost* (leftmost) shorthand loop varies fastest. So I expect the Fortran'ers to guess [11, 21, 31, 12, 22, ...] I agree the experiment is worth trying, but I'm not sure we're observing anything other than experienced programmers' prior language-dependent conditioning ... which would also explain why neither Greg's functional nor Fortran guinea pigs had any concept of lockstep iteration across multiple loop controls. BTW, an MxN slice of a 2D array A in Fortran will often show up in an I/O stmt as ... ((A(I,J), I=1,M), J=1,N) ... and the "innermost fastest" rule relates directly to Fortran's oddball decision to use column-major array storage: the natural way to write the I/O using implied DOs caters to varying the first index fastest (== contiguous memory locations under column-major storage). It's not like there's a *profound* reason behind this . From esr at thyrsus.com Wed Jul 26 05:34:26 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Jul 2000 23:34:26 -0400 Subject: [Python-Dev] PEP202 In-Reply-To: <200007260307.PAA09527@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Jul 26, 2000 at 03:07:10PM +1200 References: <20000725152832.A2019@thyrsus.com> <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> Message-ID: <20000725233426.B3540@thyrsus.com> Greg Ewing : > > What they want to be is an applicative sublanguage in functional > > style > > Um, that might be what *you* want them to be, but it's the > complete opposite of what *I* want them to be, which is a > way of getting away from all those convoluted combinator > constructs! So your theory is that non-intuitive procedural syntax so complex that it *needs* usability testing is better. Riiiight... -- Eric S. Raymond "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy From akuchlin at cnri.reston.va.us Wed Jul 26 05:40:31 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 25 Jul 2000 23:40:31 -0400 Subject: [Python-Dev] Names for things In-Reply-To: <200007260312.PAA09530@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Jul 26, 2000 at 03:12:54PM +1200 References: <14718.7988.542661.35195@anthem.concentric.net> <200007260312.PAA09530@s454.cosc.canterbury.ac.nz> Message-ID: <20000725234031.A20602@newcnri.cnri.reston.va.us> Regarding naming... I would recommend not wasting any more time on the naming issue. (This is a recurring theme in my posts -- remember, I spent about 0.3 microseconds thinking about whether "Python" would be a good name for a programming language, and I've never regretted it.) -- Guido van Rossum, 25 Nov 1998 From greg at cosc.canterbury.ac.nz Wed Jul 26 05:52:25 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Wed, 26 Jul 2000 15:52:25 +1200 (NZST) Subject: [Python-Dev] PEP202 In-Reply-To: <20000725233426.B3540@thyrsus.com> Message-ID: <200007260352.PAA09543@s454.cosc.canterbury.ac.nz> > So your theory is that non-intuitive procedural syntax so complex that > it *needs* usability testing is better. It seems that our brains work in different ways here. What's clear to you is obscure to me, and vice versa. (I'm not the one that thinks it needs usability testing, by the way - that's a different Greg.) Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From jeremy at beopen.com Wed Jul 26 05:57:38 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 25 Jul 2000 23:57:38 -0400 (EDT) Subject: [Python-Dev] PEP202 In-Reply-To: <20000725233426.B3540@thyrsus.com> References: <20000725152832.A2019@thyrsus.com> <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> <20000725233426.B3540@thyrsus.com> Message-ID: <14718.25010.135008.849218@bitdiddle.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> Greg Ewing : [>> ESR wrote:] >> > What they want to be is an applicative sublanguage in >> > functional style >> >> Um, that might be what *you* want them to be, but it's the >> complete opposite of what *I* want them to be, which is a way of >> getting away from all those convoluted combinator constructs! ESR> So your theory is that non-intuitive procedural syntax so ESR> complex that it *needs* usability testing is better. ESR> Riiiight... Wow! There's so much jargon being slung here I don't know what's going on. (For the second time in the last few weeks, I feel like a bit player in a movie where all the major roles are played by Peter Sellers. ) Seriously, I don't understand how to apply terms like "applicative sublanguage in functional style" or "procedural syntax" to a concept like list comprehensions. The basic idea is to express the elements of list using a set-like notation similar to the one used by mathematicians. I don't know whether to call that applicative, functional, or procedural; perhaps none of them applu. Maybe it's just late, but I suspect that these high-level terms don't inform the debate much. I think we can all agree on two things: 1. Greg and Eric have different goals, which is fine. 2. Usability testing is always a good thing. To paraphrase Fred Brooks, even the best language designers aren't so omniscient as to get it right the first time. Jeremy From skip at mojam.com Wed Jul 26 06:35:20 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 25 Jul 2000 23:35:20 -0500 (CDT) Subject: [Python-Dev] PEP202 In-Reply-To: <14718.25010.135008.849218@bitdiddle.concentric.net> References: <20000725152832.A2019@thyrsus.com> <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> <20000725233426.B3540@thyrsus.com> <14718.25010.135008.849218@bitdiddle.concentric.net> Message-ID: <14718.27272.221884.457831@beluga.mojam.com> Jeremy> 2. Usability testing is always a good thing. To paraphrase Fred Jeremy> Brooks, even the best language designers aren't so omniscient Jeremy> as to get it right the first time. Though Guido came damn close... ;-) S From esr at thyrsus.com Wed Jul 26 06:55:26 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 26 Jul 2000 00:55:26 -0400 Subject: [Python-Dev] PEP202 -- glossary of terms In-Reply-To: <14718.25010.135008.849218@bitdiddle.concentric.net>; from jeremy@beopen.com on Tue, Jul 25, 2000 at 11:57:38PM -0400 References: <20000725152832.A2019@thyrsus.com> <200007260307.PAA09527@s454.cosc.canterbury.ac.nz> <20000725233426.B3540@thyrsus.com> <14718.25010.135008.849218@bitdiddle.concentric.net> Message-ID: <20000726005526.A3796@thyrsus.com> Jeremy Hylton : > Seriously, I don't understand how to apply terms like "applicative > sublanguage in functional style" or "procedural syntax" to a concept > like list comprehensions. The basic idea is to express the elements > of list using a set-like notation similar to the one used by > mathematicians. I don't know whether to call that applicative, > functional, or procedural; perhaps none of them applu. Maybe it's > just late, but I suspect that these high-level terms don't inform the > debate much. Partly this is my error; I should have said "conventional" or "infix" where I said "procedural". I was writing too fast -- procedural languages are conventional in a different way, but I was referring to conventional syntax. More generally, I guess I have to apologize for excessive use of jargon without enough context. The crowd on this list is so fearsomely competent that I tend to forget that most of you don't have a technical specialty in language design. Here's a brief glossary of relevant language-designer jargon: functional style: Refers to a language in which everything is pure function calls, without side-effects or variables. Backus's F is one of the better-known examples. LISP would be functional if there were no (setq ...). The advantage of functional language is the same as their disadvantage: no side-effects. Makes them easy to reason about, but you have to jump through hoops to do statefulness. procedural style: A procedural language has procedures that operate on variables. Explicit statefulness and side-effects are basic to such languages. applicative sublanguage: This is more about syntax. To say a syntax is applicative is to say that it *looks* like cascaded function calls, as opposed (for example) to using infix syntax or keywords. (This is oversimplifying a little; Haskell combines keywords with a syntax that could be called applicative, but Haskell is weird by design that way.) imperative vs. declarative: In an imperative language, you tell the machine to do stuff. In a declarative language you specify a desired end state and let the language implementation deduce how to generate it. A good example of a declarative sublanguage familiar to most Python programers is Tk widget layout. List comprehensions are declarative in style, even though they analyze down to a series of imperative actions. Most of Python is much more straightforwardly imperative. One of the heuristics of good language design is that boundaries between imperative and declarative sublanguages are always tricky -- users have a strong tendency to try to port concepts across the boundary and get confused. This is behind some of the confusion about comprehensions. conventional: Means different things in different contexts. When speaking of syntax, it means pseudo-algebraic syntax with infix notation and keyords. In other contexts, it can mean procedural rather than functional, or manual memory management rather than garbage collection, or fixed-extent vs. unlimited-extent. The archetypal conventional language is Algol-60. For you young 'uns out there, think Pascal. -- Eric S. Raymond From moshez at math.huji.ac.il Wed Jul 26 06:54:50 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 26 Jul 2000 07:54:50 +0300 (IDT) Subject: [Python-Dev] Meta: pep-dev (was Re: [PEP 2-0-2 listcomps] (was RE: [Python-Dev] Product iteration)) In-Reply-To: Message-ID: (Added hiphens in 2-0-2 to keep out of the timbot's radar) On Tue, 25 Jul 2000, Tim Peters wrote: > A pep-dev mailing list is clearly a very good idea, but until one is set up > I'm afraid python-dev is the only natural place to bear the unbearable (to > some) pep-dev traffic. It seems that the correct solution is not a big "pep-dev", but rather a "pep-[1-9][0-9]*-dev" lists, one for each pep. So I'll just sit back quietly and wait for ?!in to suggest roundup for this. Then we'll Barry see how he can easily make mailman do this. <202 wink> last-man-coding-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From moshez at math.huji.ac.il Wed Jul 26 09:09:51 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 26 Jul 2000 10:09:51 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <20000725180116.A12239@kronos.cnri.reston.va.us> Message-ID: On Tue, 25 Jul 2000, Andrew Kuchling wrote: > On Tue, Jul 25, 2000 at 06:08:18PM -0400, Eric S. Raymond wrote: > >Wrong answer. The right answer is to fix lambda (or some variant of lambda) > >to be a true lexical closure. > > Hm... hmmmm... fixing this has been suggested before, but always > foundered on the fact that creating a closure required a cycle, which > would leak memory. Now we have an optional GC that should handle > this, so maybe fixing it can be revisited. (But this would mean that > GC is essentially no longer optional -- maybe too radical a thing to > do before we're sure about the new GC. 2.1, maybe?) I think I'd rather have this solved by weak references then by building cycles. Cycles are evil even in the face of GC -- you have undetermined finalization. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From nowonder at pool.informatik.rwth-aachen.de Wed Jul 26 10:10:40 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Wed, 26 Jul 2000 08:10:40 +0000 Subject: [Python-Dev] Summary or failing regression tests... References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> Message-ID: <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> Trent Mick wrote: > > 'test_fork1' works for me when run as: > ./python Lib/test/regrtest.py > > but hangs when run as: > ./python Lib/test/test_fork1.py > or > ./python Lib/test/regrtest.py test_fork1 On my system there is no problem: nowonder at mobility:~/python/python/dist/src > ./python Lib/test/test_fork1.py nowonder at mobility:~/python/python/dist/src > ./python Lib/test/regrtest.py test_fork1 test_fork1 1 test OK. I am using a (somewhat modified) SuSE 6.4 distribution with an old 2.2.13 kernel. What does your's look like? Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From effbot at telia.com Wed Jul 26 09:49:44 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 09:49:44 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> <200007260311.WAA31872@cj20424-a.reston1.va.home.com> Message-ID: <00a601bff6d6$12f14820$f2a6b5d4@hagrid> guido wrote: > > summary: the current interpreter throws an "ASCII decoding > > error" exception if you compare 8-bit and unicode strings, and > > the 8-bit string happen to contain a character in the 128-255 > > range. > > Doesn't bother me at all. If I write a user-defined class that raises > an exception in __cmp__ you can get the same behavior. The fact that > the hashes were the same is a red herring; there are plenty of values > with the same hash that aren't equal. > > I see the exception as a useful warning that the program isn't > sufficiently Unicode aware to work correctly. That's a *good* thing > in my book -- I'd rather raise an exception than silently fail. I assume that means you're voting for alternative 3: "a third alternative would be to keep the exception, and make the dictionary code exception proof." because the following isn't exactly good behaviour: >>> a = "?" >>> b = unicode(a, "iso-8859-1") >>> d = {} >>> d[a] = "a" >>> d[b] = "b" >>> len(d) UnicodeError: ASCII decoding error: ordinal not in range(128) >>> len(d) 2 (in other words, the dictionary implementation misbehaves if items with the same hash value cannot be successfully compared) From tim_one at email.msn.com Wed Jul 26 10:09:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 26 Jul 2000 04:09:27 -0400 Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: <00a601bff6d6$12f14820$f2a6b5d4@hagrid> Message-ID: [Guido] > ... > I see the exception as a useful warning that the program isn't > sufficiently Unicode aware to work correctly. That's a *good* thing > in my book -- I'd rather raise an exception than silently fail. [Fredrik Lundh] > I assume that means you're voting for alternative 3: > > "a third alternative would be to keep the exception, and make > the dictionary code exception proof." > > because the following isn't exactly good behaviour: > > >>> a = "?" > >>> b = unicode(a, "iso-8859-1") > >>> d = {} > >>> d[a] = "a" > >>> d[b] = "b" > >>> len(d) > UnicodeError: ASCII decoding error: ordinal not in range(128) > >>> len(d) > 2 > > (in other words, the dictionary implementation misbehaves if items > with the same hash value cannot be successfully compared) Hmm. That's a bug in the dict implementation that's independent of Unicode issues, then -- and I can provoke similar behavior with classes that raise exceptions from __cmp__, without using Unicode anywhere. So, ya, the dict bugs have to be fixed. Nobody needs to vote on *that* part . I'll look into it "soon", unless somebody else does first. From mal at lemburg.com Wed Jul 26 10:11:40 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 26 Jul 2000 10:11:40 +0200 Subject: [Python-Dev] test_fork1.py failing (Summary or failing regression tests...) References: <20000725153912.A21409@ActiveState.com> Message-ID: <397E9D3C.9181A0E0@lemburg.com> Trent Mick wrote: > > Here is a list of the regrtests that are currently failing for me on Linux32 > and Win32. Is anybody looking at test_mmap, test_userstring, test_winreg, > and test_winreg2? > > Skip, You and Jeremy(?) were talking about test_posixpath on Linux. It looks > like the sames errors you were talking about occur on Win32. I didn't look > too closely, can you? > > Fredrik, are you aware of the test_sre failure on Win32? Am I doing something > wrong to be getting this? > > On Linux32: > - test_fork1 > This fails/hangs/crashes inconsistently because (some little bird told me) > the fork stuff and threads are incompatible. Am I right? Now that we are > turning threads on by default what is the proper thing to do here? SHould > test_fork1 be changed to skip if threads are enabled? Does this mean that a stock Python 1.6/2.0 interpreter will not properly do fork() on Linux32 (even when using threads) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jul 26 10:41:06 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 26 Jul 2000 10:41:06 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> Message-ID: <397EA422.3E785467@lemburg.com> Fredrik Lundh wrote: > > (revisiting an old thread on mixed string comparisions) > > summary: the current interpreter throws an "ASCII decoding > error" exception if you compare 8-bit and unicode strings, and > the 8-bit string happen to contain a character in the 128-255 > range. > > this is not only confusing for users, it also confuses the hell > out of Python itself. for example: > > >>> a = u"?" > >>> b = "?" > >>> hash(a) > -283818363 > >>> hash(b) > -283818363 > >>> a == b > Traceback (most recent call last): > File "", line 1, in ? > UnicodeError: ASCII decoding error: ordinal not in range(128) > >>> d = {} > >>> d[a] = "a" > >>> d[b] = "b" > >>> len(d) > UnicodeError: ASCII decoding error: ordinal not in range(128) > > oops. This is due to the fact that the Python dictionary lookup implementation doesn't properly treat exceptions raised during object compares -- this should probably be changed (e.g. the lookup procedure could clear the error just before returning to caller) ?! The Unicode implementation only makes this bug in the core visible because before that raising exceptions during compares was not a common thing to do. > ::: > > it's clear that we should do something about this, but it's > not entirely clear what do to. > > quoting from the earlier thread: > > [paul] > > As soon as you find a character out of the ASCII range in one of the > > strings, I think that you should report that the two strings are > > unequal. > > [me] > > sounds reasonable -- but how do you flag "unequal" in cmp? which > > value is "larger" if all that we know is that they're different... > > [moshe] > > We can say something like "beyond the ASCII range, every unicode character > > is larger then any regular 8-bit character", and compare > > lexicographically. > > [mal] > > The usual method in the Python compare logic is to revert to > > the type name for compares in case coercion fails... I think > > this is the right description in this case: decoding fails and > > thus coercion becomes impossible. > > > > PyObject_Compare() has the logic, we'd just have to reenable > > it for Unicode which currently is handled as special case to > > pass through the decoding error. > > > > Note that Unicode objects which don't coerce would then always > > compare larger than 8-bit strings ("unicode" > "string"). > > ::: > > having digested this for a week or two, I'm leaning towards > moshe's proposal. > > even if mal's proposal will give the same result in practice, I'm > not entirely happy with the idea that the actual contents of a > variable (and not just its type) should determine whether the > "last resort" type name comparision should be used. This has been the standard way of processing for years: if coercion fails (for whatever reason), go ahead and fall back to the type name compare. > a third alternative would be to keep the exception, and make > the dictionary code exception proof. having looked at the code, > I'm afraid this might be easier said than done... Right. Plus we'd have to be *very* careful about not introducing a performance problem here instead (after all, dict lookups are at the heart of what makes Python so cool). Note that we should look into this independent of the Unicode discussion: user code may very well raise exceptions too and the result would be a lingering exception state just like in the example above. > ::: > > comments? I'd say: mask the coercion error during compare in the standard way and remove the special casing for Unicode in PyObject_Compare(). Then as second step: rethink coercion altogether and possibly fix the situation in the compare operator of either strings or Unicode. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mhammond at skippinet.com.au Wed Jul 26 10:45:48 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 26 Jul 2000 18:45:48 +1000 Subject: [Python-Dev] Product iteration In-Reply-To: Message-ID: > I think I'd rather have this solved by weak references then by building > cycles. Cycles are evil even in the face of GC -- you have undetermined > finalization. It's worth pointing out that Python actually guarantees you may have undetermined finalization - it's just not an implementation requirement that it be that way. But-it-phrases-it-a-little-differently-than-that- ly, Mark. From effbot at telia.com Wed Jul 26 10:55:46 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 26 Jul 2000 10:55:46 +0200 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> Message-ID: <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> guido wrote: > > It derives in turn from SETL, which followed common set-theoretic > > notation. This "grabbed" Guido; LISP spellings never did, and I bet > > never will. > > I've never used or even seen SETL, but there is a connection: SETL had > a profound influence on the designers of ABC, in particular Lambert > Meertens, who spent a sabbatical year working with the folks at New > York University who wrote the first validated Ada compiler in SETL. found this one: http://www-robotics.eecs.lehigh.edu/~bacon/setlprog.ps.gz interesting reading. SETL sure has a pythonic feel... with a few improvements, of course (like the [start next end] range literals... too late to fix that in python, I suppose...) and personally, I prefer their "tuple former" syntax over the the current PEP202 proposal: [expression : iterator] [n : n in [1:100]] [(x**2, x) : x in [1:5]] [a : a in y if a > 5] (all examples are slightly pythonified; most notably, they use "|" or "st" (such that) instead of "if") the expression can be omitted if it's the same thing as the loop variable, *and* there's at least one "if" clause: [a in y if a > 5] also note that their "for-in" statement can take qualifiers: for a in y if a > 5: ... is there any special reason why we cannot use colon instead of "for"? From mal at lemburg.com Wed Jul 26 11:11:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 26 Jul 2000 11:11:37 +0200 Subject: [Python-Dev] decoding errors when comparing strings References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> <200007260311.WAA31872@cj20424-a.reston1.va.home.com> Message-ID: <397EAB49.8B5B0505@lemburg.com> Guido van Rossum wrote: > > > (revisiting an old thread on mixed string comparisions) > > I think it's PEP time for this one... > > > summary: the current interpreter throws an "ASCII decoding > > error" exception if you compare 8-bit and unicode strings, and > > the 8-bit string happen to contain a character in the 128-255 > > range. > > Doesn't bother me at all. If I write a user-defined class that raises > an exception in __cmp__ you can get the same behavior. The fact that > the hashes were the same is a red herring; there are plenty of values > with the same hash that aren't equal. > > I see the exception as a useful warning that the program isn't > sufficiently Unicode aware to work correctly. That's a *good* thing > in my book -- I'd rather raise an exception than silently fail. > > Note that it can't break old code unless you try to do new things with > the old code: the old code coudn't have supported Unicode because it > doesn't exist in Python 1.5.2. Hmm, so you do want exceptions to be raised for coercion errors during compare ? For the record: PyObject_Compare() currently only does coercion for number slot compatible types (ok, all Python instances have these slots...). Unicode objects are handled in a special case to allow the PyUnicode_Compare() API to do all necessary conversions and then proceed with the compare. The coercion proposal will have to deal with all this in 2.1. My version of the proposal (see Python Pages) puts all the power into the hands of the operators themselves rather than using a centralized coercion method. In this scenario, the special casing in PyObject_Compare() for Unicode would no longer be necessary, since the Unicode compare slot could then take care of the needed conversions (essentially PyUnicode_Compare() would beceom that slot). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From nowonder at pool.informatik.rwth-aachen.de Wed Jul 26 13:24:44 2000 From: nowonder at pool.informatik.rwth-aachen.de (Peter Schneider-Kamp) Date: Wed, 26 Jul 2000 11:24:44 +0000 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> Message-ID: <397ECA7C.E872636C@pool.informatik.rwth-aachen.de> [Fredrik Lundh] > > and personally, I prefer their "tuple former" syntax over the the > current PEP202 proposal: > > [expression : iterator] > > [n : n in [1:100]] > [(x**2, x) : x in [1:5]] > [a : a in y if a > 5] Funny. I send a mail to Tim this morning with a similar proposal: [Peter] > > Not being too happy with the proposed syntaxes I came up > with a new one. > > I think it is much better to parse (for human readers), > but I am open about ';' as the delimiter. ':' would feel > very fine to me, too. > > Syntax: > [; , , ...] > > Example for semantics: > [x+y; x in [1, 2, 3], x <= 2, y in [10, 20, 30], y in [5, 10, 20]] > == [11, 21, 12, 22] > > How to implement this example: > (only a sketch, this will probably be too slow to > really do it like this, but maybe you get the idea > that it is at least possible to do it) > 1) set baselist_for_x and baselist_for_y to > something special (None?) indicating all possible > values for x and y (they are unconstrained) > 2) on encountering "x in [1, 2, 3]" set > baselist_for_x to [1, 2, 3] > 3) on encountering "x <= 2" filter baselist_for_x > and get [1, 2] > 4) on encountering "y in [10, 20, 30]" set > baselist_for_y to [10, 20, 30] > 5) on encountering "y in [5, 10, 20] see that > baselist_for_y != special value (None?) and so > filter baselist_for_y and get [10, 20] > 6) produce cross product of baselist_for_x > and baselist_for_y > 7) apply expression to elements of cross product > > The general idea is to start with lists of all > possible values (represented by a special value) > and use the conditions in the list comprehension > to constrain that list. If we don't want to deal > with infinite lists (and therefore lazy stuff) > we could through an ConstraintError on the following: > > >>> [x; x > 10000] > ConstraintError: missing sequence constraint for x The difference (besides ';' against ':') is the use of commas for seperation and not using if. [Fredrik Lundh] > is there any special reason why we cannot use colon instead > of "for"? There seem to be some reasons, but I am not sure I have understood them. Probably I'll best quote from Tim's reply: [Tim Peters] > That said, I can guarantee Guido will hate that in > > > [x+y; x in [1, 2, 3], x <= 2, y in [10, 20, 30], y in [5, 10, 20]] > > you have > y in [...] > meaning iteration in one position but have it meaning a filter in another. No. I have it mean filter in all cases. That's just implementation. [Tim Peters] > The syntax is also deadly ambiguous: > x <= 2 > is a legit Python expression today, but so is > x <= 2, y > and so is > x <= 2, y in [10, 20, 30] > and so is > x <= 2, y in [10, 20, 30], y > etc. This syntax is simply unparsable given the uses for commas in Python's > existing expression syntax. That's one reason "for" and "if" have been in > every other proposal for at least the last year . Wouldn't it be possible to just parse the first part (before the delimiter - be it ';' or ':') as an expression and allow a tuple of boolean expressions after the delimiter? Picture list comprehensions as list constraints. With [x,y: x in list1, y in list2, x > 10, odd(y)] I say that I want to have all tuples of x and y who satisfy the following constraints: - x is an element of list1 and greater than 10 - y is an element of list2 and odd For the parser the following cases would both be valid: [x+y: x in list1, y in list2] [(x+y): (x in list1, y in list2)] The latter would be what Python sees, but given that parentheses are optional for expressions and tuple building the former would be legal python. [Tim Peters] > Don't mean to be discouraging, but looks like you missed the first year of > this debate! Actually I think I did. But then I didn't even know about Python 4 months ago. newbie-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From gmcm at hypernet.com Wed Jul 26 11:32:11 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Wed, 26 Jul 2000 05:32:11 -0400 Subject: [Python-Dev] PEP202 In-Reply-To: <20000725233426.B3540@thyrsus.com> References: <200007260307.PAA09527@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Wed, Jul 26, 2000 at 03:07:10PM +1200 Message-ID: <1247518565-39631569@hypernet.com> > So your theory is that non-intuitive procedural syntax ... C'mon Eric. The only intuitive syntax is: - the grunt - the scream - the laugh - "Well Helloooo sailor" -and-3-of-those-are-ambiguous-ly y'rs - Gordon From mal at lemburg.com Wed Jul 26 12:32:32 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 26 Jul 2000 12:32:32 +0200 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> Message-ID: <397EBE40.54E76DF4@lemburg.com> Fredrik Lundh wrote: > > SETL sure has a pythonic feel... > > with a few improvements, of course (like the [start next end] > range literals... too late to fix that in python, I suppose...) > > and personally, I prefer their "tuple former" syntax over the the > current PEP202 proposal: > > [expression : iterator] > > [n : n in [1:100]] > [(x**2, x) : x in [1:5]] > [a : a in y if a > 5] > > (all examples are slightly pythonified; most notably, they > use "|" or "st" (such that) instead of "if") > > the expression can be omitted if it's the same thing as the > loop variable, *and* there's at least one "if" clause: > > [a in y if a > 5] > > also note that their "for-in" statement can take qualifiers: > > for a in y if a > 5: > ... > > is there any special reason why we cannot use colon instead > of "for"? For mathematicians the [ : ] or [ | ] looks natural since it's their every day style of writing sets, but I doubt that CP4E users get the grasp of this. Anyway, whatever syntax you choose, please make sure that the and the parts are very well visibily separated. [ for in ] doesn't fall in that category, IMHO. Hehe, this is starting to get the feel of SQL with their horrible SELECT syntax: SELECT FROM WHERE ORDER BY etc. pp. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From m.favas at per.dem.csiro.au Wed Jul 26 12:40:04 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Wed, 26 Jul 2000 18:40:04 +0800 Subject: [Python-Dev] Sub-package import mechanism now broken? Message-ID: <397EC004.A73F815@per.dem.csiro.au> Have the sub-package import semantics changed, or is import broken in the current CVS? (still works in my last version of 1.6a2, and, yes, /usr/local/lib/python2.0/site-packages Python 2.0b1 (#208, Jul 26 2000, 14:54:31) [C] on osf1V4 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> import Pmw >>> from xml import * >>> from xml.sax import saxlib Traceback (most recent call last): File "", line 1, in ? ImportError: cannot import name saxlib >>> from xml.parsers.xmlproc import xmlproc Traceback (most recent call last): File "", line 1, in ? ImportError: No module named parsers.xmlproc >>> -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From guido at beopen.com Wed Jul 26 14:57:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 07:57:02 -0500 Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: Your message of "Wed, 26 Jul 2000 09:49:44 +0200." <00a601bff6d6$12f14820$f2a6b5d4@hagrid> References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> <200007260311.WAA31872@cj20424-a.reston1.va.home.com> <00a601bff6d6$12f14820$f2a6b5d4@hagrid> Message-ID: <200007261257.HAA01308@cj20424-a.reston1.va.home.com> > > I see the exception as a useful warning that the program isn't > > sufficiently Unicode aware to work correctly. That's a *good* thing > > in my book -- I'd rather raise an exception than silently fail. > > I assume that means you're voting for alternative 3: > > "a third alternative would be to keep the exception, and make > the dictionary code exception proof." Yes. > because the following isn't exactly good behaviour: > > >>> a = "?" > >>> b = unicode(a, "iso-8859-1") > >>> d = {} > >>> d[a] = "a" > >>> d[b] = "b" > >>> len(d) > UnicodeError: ASCII decoding error: ordinal not in range(128) > >>> len(d) > 2 > > (in other words, the dictionary implementation misbehaves if items > with the same hash value cannot be successfully compared) Good point. This would happen if you used flakey class instances as keys as well! (Note that the exception really happens on the d[b] = "b" statement; but because the dict implementation doesn't check for exceptions, it gets reported too late. We've seen this kind of bugs before in Python.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Wed Jul 26 15:00:33 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 08:00:33 -0500 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: Your message of "Wed, 26 Jul 2000 10:55:46 +0200." <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> Message-ID: <200007261300.IAA01335@cj20424-a.reston1.va.home.com> > is there any special reason why we cannot use colon instead > of "for"? Would conflict with the proposed syntax for range literals. Both [0:10] and [x : x in seq] have the same syntactical form. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Wed Jul 26 15:02:02 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 08:02:02 -0500 Subject: [Python-Dev] decoding errors when comparing strings In-Reply-To: Your message of "Wed, 26 Jul 2000 11:11:37 +0200." <397EAB49.8B5B0505@lemburg.com> References: <00eb01bff695$d0fa7c60$f2a6b5d4@hagrid> <200007260311.WAA31872@cj20424-a.reston1.va.home.com> <397EAB49.8B5B0505@lemburg.com> Message-ID: <200007261302.IAA01353@cj20424-a.reston1.va.home.com> > Hmm, so you do want exceptions to be raised for coercion errors > during compare ? Sure, fine. > For the record: > PyObject_Compare() currently only does coercion for number > slot compatible types (ok, all Python instances have these > slots...). Unicode objects are handled in a special case to > allow the PyUnicode_Compare() API to do all necessary conversions > and then proceed with the compare. > > The coercion proposal will have to deal with all this in 2.1. > > My version of the proposal (see Python Pages) puts all the power > into the hands of the operators themselves rather than using > a centralized coercion method. In this scenario, the special > casing in PyObject_Compare() for Unicode would no longer > be necessary, since the Unicode compare slot could then take > care of the needed conversions (essentially PyUnicode_Compare() > would beceom that slot). This all sounds okay to me -- I've signed off on that design (in principle) years ago... --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Wed Jul 26 15:12:20 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 08:12:20 -0500 Subject: [Python-Dev] Product iteration In-Reply-To: Your message of "Wed, 26 Jul 2000 10:09:51 +0300." References: Message-ID: <200007261312.IAA01454@cj20424-a.reston1.va.home.com> > > Hm... hmmmm... fixing this has been suggested before, but always > > foundered on the fact that creating a closure required a cycle, which > > would leak memory. Now we have an optional GC that should handle > > this, so maybe fixing it can be revisited. (But this would mean that > > GC is essentially no longer optional -- maybe too radical a thing to > > do before we're sure about the new GC. 2.1, maybe?) > > I think I'd rather have this solved by weak references then by building > cycles. Cycles are evil even in the face of GC -- you have undetermined > finalization. But in this case, there aren't any custom finalizers involved in the cycle (although there may be some *hanging off* the cycle). E.g. after: def f(): def g(): pass f() we have (taking some notational liberties and simplifications): globals = {'f': f} f.func_globals = globals locals = {'g': g} g.func_globals = locals # or maybe g.func_parent = locals In other words the cycles are between a dictionary and a function object: globals <--> f locals <--> g I don't see any finalization issues. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From moshez at math.huji.ac.il Wed Jul 26 14:21:00 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 26 Jul 2000 15:21:00 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <200007261312.IAA01454@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 26 Jul 2000, Guido van Rossum wrote: > > I think I'd rather have this solved by weak references then by building > > cycles. Cycles are evil even in the face of GC -- you have undetermined > > finalization. > > But in this case, there aren't any custom finalizers involved in the > cycle (although there may be some *hanging off* the cycle). Yes, but those finalizers hanging off the cycle would occur in some random time in the future, not right now, hence rendering the def f(): fp = open("fff") pass idiom dangerous, since you're not sure how long fp will remain open. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at beopen.com Wed Jul 26 15:31:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 08:31:29 -0500 Subject: [Python-Dev] Product iteration In-Reply-To: Your message of "Wed, 26 Jul 2000 15:21:00 +0300." References: Message-ID: <200007261331.IAA01752@cj20424-a.reston1.va.home.com> > > But in this case, there aren't any custom finalizers involved in the > > cycle (although there may be some *hanging off* the cycle). > > Yes, but those finalizers hanging off the cycle would occur in some random > time in the future, not right now, hence rendering the > > def f(): > fp = open("fff") > pass > > idiom dangerous, since you're not sure how long fp will remain open. Aha. You're complaining about the finalizers being postponed arbitrarily. I thought you were complaining about the issue of finalization order *within* the cycle. Since this is still an improvement over current practice (where a finalizer hanging off a cycle may never be called) and there are no serialization issues, I don't see the problem. If you want to use weak references, please try to specify *in detail* which objects would have weak references to which other objects and how the system would resolve these... I'm never sure that things can be made 100% safe using this technique, so it may help to spell it out for me! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From m.favas at per.dem.csiro.au Wed Jul 26 15:11:11 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Wed, 26 Jul 2000 21:11:11 +0800 Subject: [Python-Dev] Sub-package import mechanism now broken? No, but... Message-ID: <397EE36F.59615826@per.dem.csiro.au> Opps - the import mechanism is not broken, it's just that the xml package in lib/site-packages no longer gets found, because of the new xml package in lib. This will still break existing code, unless the xml package in lib is renamed, has the same functionality as the PyXML package that installs in lib/site-packages, or has a method of handing off to the, um, more extensive site-package version... -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From jack at oratrix.nl Wed Jul 26 15:30:01 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 26 Jul 2000 15:30:01 +0200 Subject: [Python-Dev] ANSIfication. In-Reply-To: Message by Guido van Rossum , Tue, 25 Jul 2000 07:38:19 -0500 , <200007251238.HAA19158@cj20424-a.reston1.va.home.com> Message-ID: <20000726133002.4D95937186E@snelboot.oratrix.nl> > Frankly, I think that for *any* functions that are in some external > library (e.g. libc), Python should never provide a function prototype > at all. The standard headers should provide the prototypes! They should, but what if they don't? That's what I like about the pyport.h: it allows Python to build out of the box but still keeps all the cruft needed because some platforms don't have their act together in a single place. I know that I'm not expected to understand sections of pyport.h that are for platforms I'm not familiar with... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido at beopen.com Wed Jul 26 16:33:18 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 09:33:18 -0500 Subject: [Python-Dev] ANSIfication. In-Reply-To: Your message of "Wed, 26 Jul 2000 15:30:01 +0200." <20000726133002.4D95937186E@snelboot.oratrix.nl> References: <20000726133002.4D95937186E@snelboot.oratrix.nl> Message-ID: <200007261433.JAA02431@cj20424-a.reston1.va.home.com> [Guido] > > Frankly, I think that for *any* functions that are in some external > > library (e.g. libc), Python should never provide a function prototype > > at all. The standard headers should provide the prototypes! [Jack] > They should, but what if they don't? That's what I like about the > pyport.h: it allows Python to build out of the box but still keeps > all the cruft needed because some platforms don't have their act > together in a single place. I know that I'm not expected to > understand sections of pyport.h that are for platforms I'm not > familiar with... Exactly! But the point is that over the last 10 years we've collected an enormous amount of cruft in this area that's not needed any more, because platforms improve. So my proposal is to remove all the cruft for which we don't have positive confirmation that it's needed somewhere, and then add back whatever's necessary to support all esoteric platforms again. Not-saying-what's-considered-esoteric-ly, --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From moshez at math.huji.ac.il Wed Jul 26 15:33:46 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 26 Jul 2000 16:33:46 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <200007261331.IAA01752@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 26 Jul 2000, Guido van Rossum wrote: > Since this is still an improvement over current practice (where a > finalizer hanging off a cycle may never be called) and there are no > serialization issues, I don't see the problem. Today inner functions don't create cycles involving local variables. Lexical scoping would change that. > If you want to use weak references, please try to specify *in detail* > which objects would have weak references to which other objects and > how the system would resolve these... I'm never sure that things can > be made 100% safe using this technique, so it may help to spell it out > for me! OK, how's that: inner functions have weak reference to variables in the same scope def f(): x = 1 def g(): pass g would have only a weak reference to "x". I'm changing "no reference" to "weak reference", so I'm not incrementing effective reference counting. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at beopen.com Wed Jul 26 16:44:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 09:44:05 -0500 Subject: [Python-Dev] Product iteration In-Reply-To: Your message of "Wed, 26 Jul 2000 16:33:46 +0300." References: Message-ID: <200007261444.JAA02518@cj20424-a.reston1.va.home.com> > Today inner functions don't create cycles involving local variables. > Lexical scoping would change that. Fair enough. To resolve this, an inner function should only have a reference to the outer function if it actually references the outer function's locals -- which can be determined at compile time. > > If you want to use weak references, please try to specify *in detail* > > which objects would have weak references to which other objects and > > how the system would resolve these... I'm never sure that things can > > be made 100% safe using this technique, so it may help to spell it out > > for me! > > OK, how's that: inner functions have weak reference to variables in the > same scope > > def f(): > x = 1 > def g(): > pass Insert "print x" in the body of g, and "return g" in the body of f. > > g would have only a weak reference to "x". > > I'm changing "no reference" to "weak reference", so I'm not incrementing > effective reference counting. Ehm, I'm always confused by the semantics of weak references (you could say that I haven't a clue about them), so you'd have to do better than this. In any case, in your proposal the weak reference to x would go away when f returns, so if g is exported from f, it breaks! def f(): x = 1 def g(): print x g() return g gee = f() gee() This would first print 1 (the call to g() inside f()) and then raise a NameError (probably a new subclass e.g. UnboundOuterNameError). This behavior is unacceptable, at least to the people who have been clamoring most for this feature (the Schemers): it is expected that x is kept alive as long as g lives. So, try again! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From fdrake at beopen.com Wed Jul 26 15:44:18 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 26 Jul 2000 09:44:18 -0400 (EDT) Subject: [Python-Dev] Sub-package import mechanism now broken? No, but... In-Reply-To: <397EE36F.59615826@per.dem.csiro.au> References: <397EE36F.59615826@per.dem.csiro.au> Message-ID: <14718.60210.729406.658995@cj42289-a.reston1.va.home.com> Mark Favas writes: > Opps - the import mechanism is not broken, it's just that the xml > package in lib/site-packages no longer gets found, because of the new > xml package in lib. This will still break existing code, unless the xml > package in lib is renamed, has the same functionality as the PyXML I expect we'll be making the package in site-packages an extension provider for the xml package in the standard library. I'm planning to discuss this issue at today's PythonLabs meeting. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From moshez at math.huji.ac.il Wed Jul 26 15:56:12 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 26 Jul 2000 16:56:12 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <200007261444.JAA02518@cj20424-a.reston1.va.home.com> Message-ID: On Wed, 26 Jul 2000, Guido van Rossum wrote: > > OK, how's that: inner functions have weak reference to variables in the > > same scope > > > > def f(): > > x = 1 > > def g(): > > pass > > Insert "print x" in the body of g, and "return g" in the body of f. What are you trying to do, simulate classes via closures? I don't see any reason for this to work. However, this should work def powers_of(n): return map(lambda x: n**x, range(10)) > Ehm, I'm always confused by the semantics of weak references (you > could say that I haven't a clue about them), so you'd have to do > better than this. > > In any case, in your proposal the weak reference to x would go away > when f returns, so if g is exported from f, it breaks! Exactly. But breaks cleanly, of course (what yo suggested works great) > This behavior is unacceptable, at least to the people who have been > clamoring most for this feature (the Schemers): it is expected that > x is kept alive as long as g lives. Ummmm....to put it harshly f**k Schemers (I'm speaking as a latent schemer myself, so I can be harsh): I don't want lexical scoping to simulate classes, Python's got a wonderful object system. I want lexical scoping to make the common case of map(lambda) or def _(...): .... map(_, ....) less horrible (IOW, without the lambda x,n=n,y=y,something=other: hack) The only question about lexical scoping is "what are we trying to do?". I'm trying to have a working map(). You (seem to be) trying to simulate objects via closures. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From trentm at activestate.com Wed Jul 26 18:30:24 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 26 Jul 2000 09:30:24 -0700 Subject: [Python-Dev] test_fork1 failing --with-threads (for some people)... In-Reply-To: <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> Message-ID: <20000726093024.C26632@ActiveState.com> On Wed, Jul 26, 2000 at 08:10:40AM +0000, Peter Schneider-Kamp wrote: > I am using a (somewhat modified) SuSE 6.4 distribution > with an old 2.2.13 kernel. > > What does your's look like? > [trentm at molotok ~]$ cat /proc/version Linux version 2.2.12-20smp (root at porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Mon Sep 27 10:34:45 EDT 1999 RedHat dist Trent -- Trent Mick TrentM at ActiveState.com From trentm at ActiveState.com Wed Jul 26 18:32:32 2000 From: trentm at ActiveState.com (Trent Mick) Date: Wed, 26 Jul 2000 09:32:32 -0700 Subject: [Python-Dev] test_fork1.py failing (Summary or failing regression tests...) In-Reply-To: <397E9D3C.9181A0E0@lemburg.com> References: <20000725153912.A21409@ActiveState.com> <397E9D3C.9181A0E0@lemburg.com> Message-ID: <20000726093232.D26632@ActiveState.com> On Wed, Jul 26, 2000 at 10:11:40AM +0200, M . -A . Lemburg wrote: > Trent Mick wrote: > > > > On Linux32: > > - test_fork1 > > This fails/hangs/crashes inconsistently because (some little bird told me) > > the fork stuff and threads are incompatible. Am I right? Now that we are > > turning threads on by default what is the proper thing to do here? SHould > > test_fork1 be changed to skip if threads are enabled? > > Does this mean that a stock Python 1.6/2.0 interpreter will > not properly do fork() on Linux32 (even when using threads) ? > As I said: *some little bird told me*. (I think it was David.) I don't know, Marc-Andre. I am just waving a flag. Ignorantly yours, Trent -- Trent Mick TrentM at ActiveState.com From trentm at activestate.com Wed Jul 26 18:37:26 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 26 Jul 2000 09:37:26 -0700 Subject: [Python-Dev] List comprehension syntax (Features for Python 2.0) In-Reply-To: <200007260259.OAA09520@s454.cosc.canterbury.ac.nz> References: <20000725110000.C577@ActiveState.com> <200007260259.OAA09520@s454.cosc.canterbury.ac.nz> Message-ID: <20000726093726.E26632@ActiveState.com> On Wed, Jul 26, 2000 at 02:59:14PM +1200, Greg Ewing wrote: > Trent Mick suggested: > > > [for x in [10,20,30]: for y in [1,2,3]: x+y] > > When designing the syntax, I decided to put the target > expression first, because I wanted it to read declaratively. > Also I think it's clearer when you can see right up front > what it's going to be a list *of*. > Yes, I expressed liking someones (MAL's? Skip's?) suggested: [for x in [1,2,3]: x] Over the currently favoured [x for x in [1,2,3]] However, given Tim's response to that thread (list comprehensions are declarative, the important thing is for the synxtax to be memorable after initial familiarity), I am inclined to retract my opinion and support: [x for x in [1,2,3]] and its ilk. Mainly, I don't want to get pulled into the debate. It has been debated and there are too many cooks in the kitchen. Trent -- Trent Mick TrentM at ActiveState.com From nowonder at nowonder.de Wed Jul 26 20:40:07 2000 From: nowonder at nowonder.de (Peter Schneider-Kamp) Date: Wed, 26 Jul 2000 18:40:07 +0000 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> Message-ID: <397F3087.D4E38ED2@nowonder.de> Trent Mick wrote: > > Linux version 2.2.12-20smp (root at porky.devel.redhat.com) (gcc version > egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Mon Sep 27 10:34:45 > EDT 1999 Could SMP be involved? Do you get the same on a non-SMP system? Do others have the same problem with SMP systems? Peter Linux version 2.2.13 (root at mobility) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Fri Mar 3 00:43:36 CET 2000 -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From trentm at activestate.com Wed Jul 26 19:27:13 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 26 Jul 2000 10:27:13 -0700 Subject: [Python-Dev] testing Fredrik's UCN patch on Linux64 (works! :) In-Reply-To: <004801bff68b$6e364280$f2a6b5d4@hagrid> References: <20000725112713.D577@ActiveState.com> <004801bff68b$6e364280$f2a6b5d4@hagrid> Message-ID: <20000726102713.D27257@ActiveState.com> > > - Fredrik had a new, better replacement? Fredrik? > > my patch is here: > http://w1.132.telia.com/~u13208596/uninames-patch.txt > > (it's ~600k, which is more than sourceforge can handle) > > if you have some time to spare, feel tree to try it out on your > favourite 64-bit platform (I haven't had time to test it on our > alphas, but I'm pretty sure it'll work). Happy to try it.... > > the patch doesn't update the build files, so you need to do some > manual tweaking to make sure the unicodenames module is built. > I.e. just slap a unicodenames line in Modules/Setup? [trentm at nickel src]$ ./python Lib/test/test_ucn.py Testing General Unicode Character Name, and case insensitivity... done. Testing misc. symbols for unicode character name expansion.... done. Testing unicode character name expansion strict error handling.... done. [trentm at nickel src]$ ./python Lib/test/regrtest.py test_ucn test_ucn 1 test OK. It works. Do I need to try it on Win64. It is more of a pain to try it there because the Win64 build system is a big f***ing mess. Trent -- Trent Mick TrentM at ActiveState.com From trentm at activestate.com Wed Jul 26 20:04:52 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 26 Jul 2000 11:04:52 -0700 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <397F3087.D4E38ED2@nowonder.de> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> Message-ID: <20000726110452.A27966@ActiveState.com> On Wed, Jul 26, 2000 at 06:40:07PM +0000, Peter Schneider-Kamp wrote: > Trent Mick wrote: > > > > Linux version 2.2.12-20smp (root at porky.devel.redhat.com) (gcc version > > egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Mon Sep 27 10:34:45 > > EDT 1999 > > Could SMP be involved? Do you get the same on a non-SMP system? > Do others have the same problem with SMP systems? > Yup, it looks like that is a possibility. I tried test_fork1 a few times on: [trentm at ladder src]$ cat /proc/version Linux version 2.2.14 (root at ladder.ActiveState.com) (gcc version 2.95.2 19991024 (release)) #1 Mon Mar 6 16:49:17 PST 2000 (a Mandrake box)... and it works fine: [trentm at ladder src]$ ./python Lib/test/test_fork1.py [trentm at ladder src]$ ./python Lib/test/regrtest.py test_fork1 test_fork1 1 test OK. [trentm at ladder src]$ So...... who knows more about SMP issues and why we have them? I am inexperienced and clueless here. Trent -- Trent Mick TrentM at ActiveState.com From klm at digicool.com Wed Jul 26 21:16:31 2000 From: klm at digicool.com (Ken Manheimer) Date: Wed, 26 Jul 2000 15:16:31 -0400 (EDT) Subject: [Python-Dev] PEP202 -- glossary of terms In-Reply-To: <20000726005526.A3796@thyrsus.com> Message-ID: On Wed, 26 Jul 2000, Eric S. Raymond wrote: > functional style: > > Refers to a language in which everything is pure function calls, without > side-effects or variables. Backus's F is one of the better-known > examples. LISP would be functional if there were no (setq ...). Typo, i think: that would probably be "FP". Quite cool language, from the guy also primary in bringing us fortran. > The advantage of functional language is the same as their disadvantage: > no side-effects. Makes them easy to reason about, but you have to jump > through hoops to do statefulness. I think "easy to reason about" in this case is mostly in the line of rigorous mathematic reasoning - algebraic/provability - than it is about approachability for novices/non-mathematicians! My impression is that in functional programming, you use functions to manipulate functions to get results - combinators, which are extremely powerful, expressively and mathematically, are also quite difficult to approach for the uninitiated. (I always thought APL presented similar challenges, but in the medium of programs as arrays/matrices.) I think one big advantage of the procedural style is how much easier it is for people to get what loops do, where applicative (map/reduce/apply) and combinatory logic operators are a lot harder. And list comprehensions as proposed capitalize on the greater approachability of loops. However, i do think a function like zip()/pairwise()/whatever can help for the tricky bit where the loop approach breaks down... (And i would be surprised if jeremy, who was steeped in MIT's scheme-based programming fundamentals curriculum, was asking for definitions. ?) Ken klm at digicool.com From bckfnn at worldonline.dk Wed Jul 26 21:42:29 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Wed, 26 Jul 2000 19:42:29 GMT Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <397f38e5.12750954@smtp.worldonline.dk> CPythons unicode compare function contains some code to compare surrogate characters in code-point order (I think). This is properly a very neat feature but is differs from java's way of comparing strings. Python 2.0b1 (#0, Jul 26 2000, 21:29:11) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> print u'\ue000' < u'\ud800' 1 >>> print ord(u'\ue000') < ord(u'\ud800') 0 >>> Java (and JPython) compares the 16-bit characters numericly which result in: JPython 1.1+08 on java1.3.0 (JIT: null) Copyright (C) 1997-1999 Corporation for National Research Initiatives >>> print u'\ue000' < u'\ud800' 0 >>> print ord(u'\ue000') < ord(u'\ud800') 0 >>> I don't think I can come up with a solution that allow JPython to emulate CPython on this type of comparison. regards, finn From thomas at xs4all.net Wed Jul 26 22:02:17 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 26 Jul 2000 22:02:17 +0200 Subject: [PEP202 listcomps] (was RE: [Python-Dev] Product iteration) In-Reply-To: <200007261300.IAA01335@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jul 26, 2000 at 08:00:33AM -0500 References: <200007260019.TAA31620@cj20424-a.reston1.va.home.com> <00e701bff6df$4c9c12e0$f2a6b5d4@hagrid> <200007261300.IAA01335@cj20424-a.reston1.va.home.com> Message-ID: <20000726220216.O266@xs4all.nl> On Wed, Jul 26, 2000 at 08:00:33AM -0500, Guido van Rossum wrote: > > is there any special reason why we cannot use colon instead > > of "for"? > Would conflict with the proposed syntax for range literals. Both > > [0:10] > > and > [x : x in seq] > have the same syntactical form. Much, much worse: the latter *is* a range literal. It's not likely to produce anything useful, depending on 'x', but it is a valid range literal. (It'll create a range from 'x' to '0', if 'x' is not in 'seq', or '1', if 'x' is in 'seq', using step 1.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Wed Jul 26 22:50:32 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 26 Jul 2000 22:50:32 +0200 Subject: [Python-Dev] ANSIfication. In-Reply-To: <20000726133002.4D95937186E@snelboot.oratrix.nl>; from jack@oratrix.nl on Wed, Jul 26, 2000 at 03:30:01PM +0200 References: <20000726133002.4D95937186E@snelboot.oratrix.nl> Message-ID: <20000726225032.P266@xs4all.nl> On Wed, Jul 26, 2000 at 03:30:01PM +0200, Jack Jansen wrote: > > Frankly, I think that for *any* functions that are in some external > > library (e.g. libc), Python should never provide a function prototype > > at all. The standard headers should provide the prototypes! > They should, but what if they don't? That's what I like about the > pyport.h: it allows Python to build out of the box but still keeps all the > cruft needed because some platforms don't have their act together in a > single place. I know that I'm not expected to understand sections of > pyport.h that are for platforms I'm not familiar with... That's kind-of what I wrote in my reply to Guido. There is only one problem with this, though, and that's finding platform-identifying #defines. I don't have enough experience with portable software to assume anything, and I unable to find anything identifying the platform on the one Solaris 2.6 box we have (and don't use, because it's Solaris ;) I haven't tried finding any on the Linux or BSDI boxes we do use, but I think Linux glibc2 is recognizable -- but that's also the system most likely to be up to date ! If anyone can give some hints on identifying platforms, or finding out whether a given prototype is included in the header files, please do :P Until then, I don't think we can do much else with the *current* prototypes than remove them. And if anyone needs those #defines, they'll have to figure out how to uniquely identify their architecture, first. Actually... I think it's possible for autoconf to find out if a prototype is included by trying to take the address of a function... but that's kind of a severe method, and doesn't say anything about what the prototype should look like. And is there really any danger of real bugs being caused by missing prototypes ? Most (well, at least *some*) testing is done on Linux systems, on which I have yet to find a prototype missing from the std. include files. It'll generate some warnings on some other operating systems, but that's all, I think. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jeremy at beopen.com Wed Jul 26 23:47:12 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 26 Jul 2000 14:47:12 -0700 (PDT) Subject: [Python-Dev] Product iteration In-Reply-To: References: <200007261444.JAA02518@cj20424-a.reston1.va.home.com> Message-ID: <14719.23648.966686.131625@mailhost.beopen.com> Moshe Zadka writes: > On Wed, 26 Jul 2000, Guido van Rossum wrote: > > > > OK, how's that: inner functions have weak reference to variables in the > > > same scope > > > > > > def f(): > > > x = 1 > > > def g(): > > > pass > > > > Insert "print x" in the body of g, and "return g" in the body of f. > > What are you trying to do, simulate classes via closures? I don't see any > reason for this to work. > There's not simulation going on. He's just expecting closures to work. I think that any proposal for changed scoping needs to do lexical scoping properly, including closures. If it doesn't, I vote -1. The argument about finalization is specious. You should not write code that depends on current finalization semantics to do things like closing files. It's relying on an implementation-dependent feature that is not part of the language spec. (Just try it on JPython.) Jeremy From esr at thyrsus.com Thu Jul 27 00:09:59 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 26 Jul 2000 18:09:59 -0400 Subject: [Python-Dev] Product iteration In-Reply-To: <14719.23648.966686.131625@mailhost.beopen.com>; from jeremy@beopen.com on Wed, Jul 26, 2000 at 02:47:12PM -0700 References: <200007261444.JAA02518@cj20424-a.reston1.va.home.com> <14719.23648.966686.131625@mailhost.beopen.com> Message-ID: <20000726180959.A6654@thyrsus.com> Jeremy Hylton : > The argument about finalization is specious. You should not write > code that depends on current finalization semantics to do things like > closing files. It's relying on an implementation-dependent feature > that is not part of the language spec. (Just try it on JPython.) I strongly agree. -- Eric S. Raymond Morality is always the product of terror; its chains and strait-waistcoats are fashioned by those who dare not trust others, because they dare not trust themselves, to walk in liberty. -- Aldous Huxley From trentm at ActiveState.com Thu Jul 27 01:01:57 2000 From: trentm at ActiveState.com (Trent Mick) Date: Wed, 26 Jul 2000 16:01:57 -0700 Subject: [Python-Dev] Re: C testing framework In-Reply-To: <14717.55286.1741.361478@beluga.mojam.com> References: <397D3B9B.9BB3CAC1@pool.informatik.rwth-aachen.de> <14717.10320.356127.243997@anthem.concentric.net> <397D7C5F.2AAF8AB6@pool.informatik.rwth-aachen.de> <14717.34372.437370.172614@beluga.mojam.com> <20000725103736.B577@ActiveState.com> <14717.55286.1741.361478@beluga.mojam.com> Message-ID: <20000726160157.A26692@ActiveState.com> On Tue, Jul 25, 2000 at 01:09:58PM -0500, Skip Montanaro wrote: > > [c-based testing framework] > > Trent> Show it? PEP it? Forget it? > > I say show it. I see no reason to make a PEP unless there are a number of > potential immediate alternatives. It doesn't affect the functionality of > the distribution, only its quality. If something better comes along later, > Trent's can be replaced. Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp Patch: *** /home/trentm/main/contrib/python/dist/src/Lib/test/test_capi.py Wed Jul 26 15:39:35 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/Lib/test/test_capi.py Wed Jul 26 10:37:31 2000 *************** *** 0 **** --- 1,17 ---- + import sys + import test_support + import _test + + # import and run the _test module tests (tests for the Python/C API) + # + # (any exported function beginning with 'test_') + + for name in dir(_test): + if name.startswith('test_'): + test = getattr(_test, name) + if test_support.verbose: + print "internal", name + try: + test() + except _test.error: + raise test_support.TestFailed, sys.exc_info()[1] *** /home/trentm/main/contrib/python/dist/src/Lib/test/output/test_capi Wed Jul 26 15:39:35 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/Lib/test/output/test_capi Wed Jul 26 10:36:37 2000 *************** *** 0 **** --- 1 ---- + test_capi *** /home/trentm/main/contrib/python/dist/src/Modules/_testmodule.c Wed Jul 26 15:39:35 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/Modules/_testmodule.c Wed Jul 26 15:39:31 2000 *************** *** 0 **** --- 1,64 ---- + //--------------------------------------------------------------------------- + // C Extension module to test Python interpreter C APIs. + // + // The 'test_*' functions exprted by this module are run as part of + // the standard Python regression test (via test_capi.py). + //--------------------------------------------------------------------------- + + #include "Python.h" + #include "marshal.h" + + #define TEST_FILENAME "__test_filename" // filename used for testing + + PyObject *TestError; + + + /* test defines from config.h (particularly the SIZEOF_* defines) + + The ones derived from autoconf on the UNIX-like OSes can be relied + upon, but the Microsoft platform have these hardcoded. Better safe + than sorry. + */ + PyObject* + test_config(PyObject *self, PyObject *args) + { + /*XXX could probably break these out to allow the error message to be + * better, as well could test more config.h settings */ + if (SIZEOF_INT != sizeof(int) || + SIZEOF_LONG != sizeof(long) || + #ifdef HAVE_LONG_LONG + SIZEOF_LONG_LONG != sizeof(LONG_LONG) || + #endif + SIZEOF_VOID_P != sizeof(void*) || + SIZEOF_TIME_T != sizeof(time_t)) { + PyErr_SetString(TestError, + "SIZEOF_* configuration defines are not all correct"); + return NULL; + } + + Py_INCREF(Py_None); + return Py_None; + } + + + + + /* must defined special structure to define methods and attributes to Python */ + static PyMethodDef TestMethods[] = { + {"test_config", test_config, METH_VARARGS}, + {NULL, NULL} /* sentinel */ + }; + + + /* must define intialization function, often 'init' */ + DL_EXPORT(void) + init_test(void) + { + PyObject *m, *d; + + m = Py_InitModule("_test", TestMethods); + + TestError = PyErr_NewException("_test.error", NULL, NULL); + d = PyModule_GetDict(m); + PyDict_SetItemString(d, "error", TestError); + } *** /home/trentm/main/contrib/python/dist/src/Modules/Setup.in Fri Jun 30 09:05:22 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/Modules/Setup.in Wed Jul 26 14:30:37 2000 *************** *** 426,431 **** --- 426,436 ---- #EXPAT_DIR=/usr/local/src/expat #pyexpat pyexpat.c -I$(EXPAT_DIR)/xmlparse -L$(EXPAT_DIR) -lexpat + # internal C API testing module (tests exprted by this module are + # called as part of the test suite) + *shared* + _test _testmodule.c + *static* # Example -- included for reference only: # xx xxmodule.c *** /home/trentm/main/contrib/python/dist/src/PCbuild/_test.dsp Wed Jul 26 15:39:35 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/PCbuild/_test.dsp Wed Jul 26 14:30:03 2000 *************** *** 0 **** --- 1,100 ---- + # Microsoft Developer Studio Project File - Name="_test" - Package Owner=<4> + # Microsoft Developer Studio Generated Build File, Format Version 6.00 + # ** DO NOT EDIT ** + + # TARGTYPE "Win32 (x86) Dynamic-Link Library" 0x0102 + + CFG=_test - Win32 Debug + !MESSAGE This is not a valid makefile. To build this project using NMAKE, + !MESSAGE use the Export Makefile command and run + !MESSAGE + !MESSAGE NMAKE /f "_test.mak". + !MESSAGE + !MESSAGE You can specify a configuration when running NMAKE + !MESSAGE by defining the macro CFG on the command line. For example: + !MESSAGE + !MESSAGE NMAKE /f "_test.mak" CFG="_test - Win32 Debug" + !MESSAGE + !MESSAGE Possible choices for configuration are: + !MESSAGE + !MESSAGE "_test - Win32 Release" (based on "Win32 (x86) Dynamic-Link Library") + !MESSAGE "_test - Win32 Debug" (based on "Win32 (x86) Dynamic-Link Library") + !MESSAGE + + # Begin Project + # PROP AllowPerConfigDependencies 0 + # PROP Scc_ProjName "" + # PROP Scc_LocalPath "" + CPP=cl.exe + MTL=midl.exe + RSC=rc.exe + + !IF "$(CFG)" == "_test - Win32 Release" + + # PROP BASE Use_MFC 0 + # PROP BASE Use_Debug_Libraries 0 + # PROP BASE Output_Dir "Release" + # PROP BASE Intermediate_Dir "Release" + # PROP BASE Target_Dir "" + # PROP Use_MFC 0 + # PROP Use_Debug_Libraries 0 + # PROP Output_Dir "." + # PROP Intermediate_Dir "x86-temp-release\_test" + # PROP Ignore_Export_Lib 0 + # PROP Target_Dir "" + F90=df.exe + # ADD BASE CPP /nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_TEST_EXPORTS" /YX /FD /c + # ADD CPP /nologo /MD /W3 /GX /Zi /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /YX /FD /c + # ADD BASE MTL /nologo /D "NDEBUG" /mktyplib203 /win32 + # ADD MTL /nologo /D "NDEBUG" /mktyplib203 /win32 + # ADD BASE RSC /l 0x409 /d "NDEBUG" + # ADD RSC /l 0x409 /d "NDEBUG" + BSC32=bscmake.exe + # ADD BASE BSC32 /nologo + # ADD BSC32 /nologo + LINK32=link.exe + # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 + # ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /out:"./_test.pyd" /export:init_test + # SUBTRACT LINK32 /pdb:none + + !ELSEIF "$(CFG)" == "_test - Win32 Debug" + + # PROP BASE Use_MFC 0 + # PROP BASE Use_Debug_Libraries 1 + # PROP BASE Output_Dir "Debug" + # PROP BASE Intermediate_Dir "Debug" + # PROP BASE Target_Dir "" + # PROP Use_MFC 0 + # PROP Use_Debug_Libraries 1 + # PROP Output_Dir "." + # PROP Intermediate_Dir "x86-temp-debug\_test" + # PROP Ignore_Export_Lib 0 + # PROP Target_Dir "" + F90=df.exe + # ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_TEST_EXPORTS" /YX /FD /GZ /c + # ADD CPP /nologo /MDd /W3 /Gm /GX /Zi /Od /I "..\Include" /I "..\PC" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /YX /FD /GZ /c + # ADD BASE MTL /nologo /D "_DEBUG" /mktyplib203 /win32 + # ADD MTL /nologo /D "_DEBUG" /mktyplib203 /o "NUL" /win32 + # ADD BASE RSC /l 0x409 /d "_DEBUG" + # ADD RSC /l 0x409 /d "_DEBUG" + BSC32=bscmake.exe + # ADD BASE BSC32 /nologo + # ADD BSC32 /nologo + LINK32=link.exe + # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept + # ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /out:"./_test_d.pyd" /pdbtype:sept /export:init_test + # SUBTRACT LINK32 /pdb:none + + !ENDIF + + # Begin Target + + # Name "_test - Win32 Release" + # Name "_test - Win32 Debug" + # Begin Source File + + SOURCE=..\Modules\_testmodule.c + # ADD CPP /I "..\Include" /I "..\PC" + # End Source File + # End Target + # End Project *** /home/trentm/main/contrib/python/dist/src/PCbuild/pcbuild.dsw Wed Jul 26 15:10:27 2000 --- /home/trentm/main/Apps/Perlium/Python/dist/src/PCbuild/pcbuild.dsw Wed Jul 26 15:13:22 2000 *************** *** 33,38 **** --- 33,53 ---- ############################################################################### + Project: "_test"=".\_test.dsp" - Package Owner=<4> + + Package=<5> + {{{ + }}} + + Package=<4> + {{{ + Begin Project Dependency + Project_Dep_Name python20 + End Project Dependency + }}} + + ############################################################################### + Project: "_tkinter"=".\_tkinter.dsp" - Package Owner=<4> Package=<5> -- Trent Mick TrentM at ActiveState.com From guido at beopen.com Thu Jul 27 02:38:55 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 26 Jul 2000 19:38:55 -0500 Subject: [Python-Dev] The State of Python Message-ID: <200007270038.TAA03951@cj20424-a.reston1.va.home.com> I've placed the slides of my talk at the O'Reilly Open Source Convention on-line at our BeOpen PythonLabs website: http://www.pythonlabs.com/talks.html We're also very close to announcing news regarding a new Python license, Python 1.6 and 2.0 release schedules, and a transition of the python.org website to hosting by VA Linux. The announcement is waiting for final negotiations about GPL compatibility of the new license; BeOpen's CTO, Bob Weiner, is confident that the issue will be resolved one way or another by Friday. A preview of what we will announce: - A new license for Python 1.6 and later: the "CNRI Open Source License", approved by the Open Source Initiative; - Release plans for Python 1.6: the last CNRI release, to be issued with help from BeOpen; - Release plans for Python 2.0: the first release to be issued by BeOpen; - A transition for the python.org website: it will be hosted by VA Linux (home of SourceForge), under supervision of the Python Consortium and myself, maintained by the Python community. Please hold your breath a little longer! A re-release of JPython using the CNRI Open Source License is possible a little later, pending further negotiations with CNRI. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From m.favas at per.dem.csiro.au Thu Jul 27 03:22:36 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Thu, 27 Jul 2000 09:22:36 +0800 Subject: [Python-Dev] is this obselete?: [Patch #100888] Fix UCNs machine with >= 32bit longs References: <20000725112713.D577@ActiveState.com> <004801bff68b$6e364280$f2a6b5d4@hagrid> Message-ID: <397F8EDC.328DDF1C@per.dem.csiro.au> Fredrik Lundh wrote: > > trent wrote: > > I was assigned this patch a while back to try on some 64-bit systems. Fine, I > > can do that but I have since seen a number of message on python-dev regarding > > it: > > > > - Fredrik had a new, better replacement? Fredrik? > > my patch is here: > http://w1.132.telia.com/~u13208596/uninames-patch.txt > > (it's ~600k, which is more than sourceforge can handle) > > if you have some time to spare, feel tree to try it out on your > favourite 64-bit platform (I haven't had time to test it on our > alphas, but I'm pretty sure it'll work). > > the patch doesn't update the build files, so you need to do some > manual tweaking to make sure the unicodenames module is built. > > if everything works as it should, the resulting interpreter should > survive test_ucn.py even if ucnhash.pyd (.so) is nowhere to be > seen... > > I've just tried /F's patch on my Alpha (Tru64 Unix, V4.0F), and everything seems fine - compiles, passes test_ucn (and the rest). -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From jeremy at beopen.com Thu Jul 27 05:07:02 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 26 Jul 2000 23:07:02 -0400 (EDT) Subject: [Python-Dev] failures in the regression tests Message-ID: <14719.42838.895374.783407@bitdiddle.concentric.net> I am trying to keep track of failures in the regression test suite. At the moment, all the available tests work correctly on my Linux box. I understand there are still problems with test_fork1 on some SMP Linux boxes. (I believe this error has been around for many months.) And that the test_winreg and test_winreg32 tests are failing on Windows builds. If you are aware of any other tests that are failing, please let me know. (Preferably by private email.) We need to get the tests fixed quickly. As I write in PEP 200 (Python 2.0 release schedule): >Failing test cases need to get fixed > > We need to resolve errors in the regression test suite quickly. > Changes should not be committed to the CVS tree unless the > regression test runs cleanly with the changes applied. If it > fails, there may be bugs lurking in the code. (There may be bugs > anyway, but that's another matter.) If the test cases are known > to fail, they serve no useful purpose. Jeremy From fdrake at beopen.com Thu Jul 27 05:05:21 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 26 Jul 2000 23:05:21 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <397F3087.D4E38ED2@nowonder.de> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> Message-ID: <14719.42737.305992.235671@cj42289-a.reston1.va.home.com> Peter Schneider-Kamp writes: > Could SMP be involved? Do you get the same on a non-SMP system? > Do others have the same problem with SMP systems? I mentioned the possibility at our PythonLabs meeting today that this may be related; when I observed problems with test_fork1, it was on an SMP linux box running Mandrake 7.0 with the stock SMP kernel. I have *not* seen the problem pop up on the uniprocessor I have now. I think Barry may have access to an SMP Sparc machine; if so, we'll be checking it out there. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jul 27 05:09:39 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 26 Jul 2000 23:09:39 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <20000726110452.A27966@ActiveState.com> References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> <20000726110452.A27966@ActiveState.com> Message-ID: <14719.42995.823876.5177@cj42289-a.reston1.va.home.com> Trent Mick writes: > So...... who knows more about SMP issues and why we have them? I am > inexperienced and clueless here. Another possible issue is that at one point configure was using GNU Pth instead of LinuxThreads by default. Since Pth is fairly young, there may be issues there as well. Pth is no longer preferred over LinuxThreads. For non-Linux users: LinuxThreads is the default pthreads implementation on Linux, and GNU Pth is a new "portable" implementation that I understand is very young and unstable. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Thu Jul 27 05:23:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 26 Jul 2000 23:23:52 -0400 Subject: [Python-Dev] failures in the regression tests In-Reply-To: <14719.42838.895374.783407@bitdiddle.concentric.net> Message-ID: On Win98, with the CVS version as of 11:15pm EDT, in both debug and release builds: 59 tests OK. 3 tests failed: test_mmap test_winreg test_winreg2 26 tests skipped: test_al test_bsddb test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_grp test_gzip test_imgfile test_li nuxaudiodev test_minidom test_nis test_openpty test_popen2 test_pty test_pwd tes t_pyexpat test_signal test_sunaudiodev test_timing test_zlib Seems odd that test_popen2 is still being skipped (I thought we were fixing popen & friends under Windows, but lost track of that). > ... > If you are aware of any other tests that are failing, please let me > know. (Preferably by private email.) Like I'm going to trust you to keep Windows details straight . From thomas at xs4all.net Thu Jul 27 06:04:42 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 06:04:42 +0200 Subject: [Python-Dev] test_fork1 on SMP? In-Reply-To: <14719.42737.305992.235671@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Wed, Jul 26, 2000 at 11:05:21PM -0400 References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> <14719.42737.305992.235671@cj42289-a.reston1.va.home.com> Message-ID: <20000727060442.Q266@xs4all.nl> On Wed, Jul 26, 2000 at 11:05:21PM -0400, Fred L. Drake, Jr. wrote: > > Peter Schneider-Kamp writes: > > Could SMP be involved? Do you get the same on a non-SMP system? > > Do others have the same problem with SMP systems? > I think Barry may have access to an SMP Sparc machine; if so, we'll > be checking it out there. I have also seen test_fork1 failures on BSDI, using a SMP machine, but I haven't tried it on non-SMP (we don't have too many of those). However, all our BSDI kernels are the same, having been built for SMP. Meetings permitting (which is doubtful, today :-() I'll see if I can pin that down. It would, however, be fairly peculiar if test_fork1 breaks on all SMP-supporting systems... I don't really recall a reason for thread semantics to change reliably based on kernel/cpu settings, and it would be silly for them to do so! But I'll admit threads are silly, period ;-) 6-AM-and-preparing-for-a-full-10-hour-day-of-meetings-:-S-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tim_one at email.msn.com Thu Jul 27 06:32:02 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 00:32:02 -0400 Subject: [Python-Dev] test_fork1 on SMP? In-Reply-To: <20000727060442.Q266@xs4all.nl> Message-ID: [Thomas Wouters] > I have also seen test_fork1 failures on BSDI, using a SMP machine, but > I haven't tried it on non-SMP (we don't have too many of those). > However, all our BSDI kernels are the same, having been built for SMP. > Meetings permitting (which is doubtful, today :-() I'll see if I can > pin that down. > > It would, however, be fairly peculiar if test_fork1 breaks on all > SMP-supporting systems... I don't really recall a reason for thread > semantics to change reliably based on kernel/cpu settings, and it would > be silly for them to do so! But I'll admit threads are silly, period ;-) Silly? Without threads your clothes would fall off . I wonder whether the "fork" part is a red herring here. It's extremely rare to see a thread bug that actually requires a multi-headed machine to trigger (in fact, I don't believe I've ever seen one), but the nature of races in flawed threaded code is often such that you're a million times more *likely* to hit a bad timing window on a multi-headed machine than on a time-sliced single-headed box. And this is particularly true under operating systems that are reluctant to switch threads on a singled-headed box. For example, 1.5.2's dreaded invalid_tstate bug had never been reported on a single-headed box until I spent several *hours* hand-crafting an extreme test case to provoke it on one (and that was after I was sure I had located the timing hole "by thought", so knew exactly what I needed to do to trigger it -- 'twas very hard to provoke it on a one-headed box even then!). > 6-AM-and-preparing-for-a-full-10-hour-day-of-meetings-:-S-ly y'rs, So long as you still put in your 18 hours on Python today, we're happy to let you engage in all the recreational activities you like . generously y'rs - tim From moshez at math.huji.ac.il Thu Jul 27 06:39:54 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 27 Jul 2000 07:39:54 +0300 (IDT) Subject: [Python-Dev] Product iteration In-Reply-To: <14719.23648.966686.131625@mailhost.beopen.com> Message-ID: On Wed, 26 Jul 2000, Jeremy Hylton wrote: > The argument about finalization is specious. You should not write > code that depends on current finalization semantics to do things like > closing files. It's relying on an implementation-dependent feature > that is not part of the language spec. (Just try it on JPython.) I know, and I'm not. But the thing is, there are plenty of users of CPython which do rely on this feature -- so you're going to break people's code. Not nice. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mhammond at skippinet.com.au Thu Jul 27 06:47:07 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu, 27 Jul 2000 14:47:07 +1000 Subject: [Python-Dev] Product iteration In-Reply-To: Message-ID: > I know, and I'm not. But the thing is, there are plenty of users of > CPython which do rely on this feature -- so you're going to break > people's code. Not nice. No - we will simply be pointing out their already broken code. We arent breaking anything! I have no problem with this at all. The sooner we point out the broken code the better. The last thing we want is for obviously and documented broken code to suddenly be considered non-broken simply by the volume of poor code out there... Either way, I think you are overstating the problem. The main scenario is closing resources, and for most users these are unlikely to be so scarce that delaying their finalization will cause problems. If someone is writing a web-server, for example, and assumes that files or sockets are automatically closed, and they open them at such a rate that true GC causes them a problem, then IMO they have got what they deserve ;-) Mark. From bwarsaw at beopen.com Thu Jul 27 06:58:00 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 27 Jul 2000 00:58:00 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> <14719.42737.305992.235671@cj42289-a.reston1.va.home.com> Message-ID: <14719.49496.935765.730596@anthem.concentric.net> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> Barry may have access to an SMP Sparc machine; if so, we'll Fred> be checking it out there. I thought I did, but nope, it's a single processor. What about SF? -Barry From guido at beopen.com Thu Jul 27 07:59:15 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 00:59:15 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Tue, 25 Jul 2000 23:03:23 +0200." <20000725230322.N266@xs4all.nl> References: <20000725230322.N266@xs4all.nl> Message-ID: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> I've been thinking a bit about this myself, and I think it's good idea to show the bytecodes generated for the various cases, just to make sure that we understand the semantics. I'll just use +=, but the same list applies to all 11 binary operators (**, *, /, %, +, -, |, &, ^, <<, >>). I'm making up opcodes -- the different variants of LOAD and STORE don't matter. On the right I'm displaying the stack contents after execution of the opcode (push appends to the end). I'm writing 'result' to indicate the result of the += operator. a += b LOAD a [a] LOAD b [a, b] AUGADD [result] STORE a [] a.attr += b LOAD a [a] DUP [a, a] GETATTR 'attr' [a, a.attr] LOAD b [a, a.attr, b] AUGADD [a, result] SETATTR 'attr' [] a[i] += b LOAD a [a] DUP [a, a] LOAD i [a, a, i] DUP [a, a, i, i] ROT3 [a, i, a, i] GETITEM [a, i, a[i]] LOAD b [a, i, a[i], b] AUGADD [a, i, result] SETITEM [] I'm leaving the slice variant out; I'll get to that in a minute. If the right hand side is more complicated than in the example, the line 'LOAD b' is simply replaced by code that calculates the value of the expression; this always ends up eventually pushing a single value onto the stack, leaving anything below it alone, just like the 'LOAD b' opcode. Ditto for the index expression ('i' in the example). Similarly, for the cases a.attr and a[i], if instead of a there's a more complicated expression (e.g. sys.modules[name].foo().bar += 1) the initial 'LOAD a' is replaced by code that loads the object on the stack -- in this example, sys.modules[name].foo(). Only the final selector (".attr", "[i]") is special. (Terminology: a selector is something that addresses a possibly writable component of a container object, e.g. a[i] or a.attr; a[i:j] is also a selector. f() could be seen as a selector but cannot be used on the left hand side of an assignment.) There are two more forms of potential interest. First, what should happen to a tuple assignment? a, b, c += x (Which is exactly the same as "(a, b, c) += x".) I think this should be a compile-time error. If t and u are tuples, "t += u" means the same as "t = t+u"; but if we apply this rule we would get "(a, b, c) = (a, b, c) + u", which is only valid if u is an empty tuple (or a class instance with unusual coercion behavior). But when u is empty, it's not useful (nothing changes), so it's unlikely that someone would have this intention. More likely, the programmer was hoping that this would be the same as "a+=x; b+=x; c+=x" -- but that's the same misconception as expecting "a, b, c = 0" to mean "a = b = c = 0" so we don't need to cater to it. Second, what should happen to a slice assignment? The basic slice form is: a[i:j] += b but there are others: Python's slice syntax allows an arbitrary comma-separated sequence of single indexes, regular slices (lo:hi), extended slices (lo:hi:step), and "ellipsis" tokens ('...') between the square brackets. Here's an extreme example: a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] += 1 First, let me indicate what code is generated for such a form when it's used in a regular expression or assignment. Any such form *except* basic slices (a[i:j], a[:j], a[i:], and a[:]) is translated into code that uses GETITEM or SETITEM with an index that is formed from a simple translation of the actual expressions. - If there are two or more comma-separated values, the index is a tuple of the translations of the individual values. - An ellipsis ("...") is translated into the builtin object Ellipsis. - A non-slice is translated into itself. - A slice is translated into a "slice object", this is a built-in object representing the lower and upper bounds and step. There is also a built-in function, slice(), taking 1-3 arguments in the same way as range(). Thus: - "lo:hi" is equivalent to slice(lo, hi); - "lo:hi:step" is equivalent to slice(lo, hi, step); - omitted values are replaced with None, so e.g. ":hi" is equivalent to slice(None, hi). So, the extreme example above means exactly the same as a[x], where x is a tuple with the following items: slice(None, None) Ellipsis slice(None, None, None) slice(0, 10, 2) slice(None, 10, None) 1 slice(2, None) slice(None, None, -1) Why all this elaboration? Because I want to use this to give a standardized semantics even to basic slices. If a[lo:hi:step] is translated the same as a[slice(lo, hi, step)], then we can give a[lo:hi] the same translation as a[slice(lo, hi)], and thus the slice case for augmented assignment can generate the same code (apart from the slice-building operations) as the index case. Thus (writing 'slice' to indicate the slice object built from i and j): a[i:j] += b LOAD a [a] DUP [a, a] LOAD i [a, a, i] ** LOAD j [a, a, i, j] ** BUILD_SLICE 2 [a, a, slice] ** DUP [a, a, slice, slice] ROT3 [a, slice, a, slice] GETITEM [a, slice, a[slice]] LOAD b [a, slice, a[slice], b] AUGADD [a, slice, result] SETITEM [] Comparing this to the code for "a[i] += b", only the three lines marked with ** are really different, and all that these do is to push a single object representing the slice onto the stack. I won't show the code for "a[i:j:k] += b" or for "a[i:j, k:l]", but it's clear how these should be done. Postscript (unrelated to augmented assignment) It would be nice if the SLICE bytecodes were removed altogether and instead slice() objects would be created for all slices, even basic ones. (I believe this was proposed in this list at some point.) The original SLICE opcodes were introduced in ancient times, when basic slices were the only accepted slice syntax. This would mean that all objects supporting slices would have to support the *mapping* interface instead of (or in addition to) the sequence interface; the mapping interface would have to determine whether a getitem / setitem call was really a slice call and do the right thing. In particular, for backward compatibility, class instances could have a mapping interface whose internal getitem function checks if the argument is a slice object whose step is None and whose lo and hi are None or integers; then if a __getslice__ method exists, it could call that, in all other cases it could call __getitem__. None of the other built-in objects that support slices would have to be changed; the GETITEM opcode could notice that an object supports the sequence interface but not the mapping interface, and then look for a basic slice or an integer and do the right thing. Problems with this are mostly related to the existing C API for slices, like PySequence_GetSlice(), which propagate the various restrictions. Too-much-rambling-reduces-the-chance-of-useful-responses-ly, --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From bwarsaw at beopen.com Thu Jul 27 07:01:38 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 27 Jul 2000 01:01:38 -0400 (EDT) Subject: [Python-Dev] Product iteration References: <14719.23648.966686.131625@mailhost.beopen.com> Message-ID: <14719.49714.427661.775934@anthem.concentric.net> >>>>> "MZ" == Moshe Zadka writes: MZ> I know, and I'm not. But the thing is, there are plenty of MZ> users of CPython which do rely on this feature -- so you're MZ> going to break people's code. Not nice. Nope, the code is already broken. They just don't know it yet. -Barry From moshez at math.huji.ac.il Thu Jul 27 07:06:00 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 27 Jul 2000 08:06:00 +0300 (IDT) Subject: [Python-Dev] was Re: Type inference now simplicity (fwd) Message-ID: I think most of the people here aren't reading c.l.py, so here are some feelings from "the community" -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez ---------- Forwarded message ---------- Date: Wed, 26 Jul 2000 21:14:34 GMT From: Shae Erisson To: python-list at python.org Newsgroups: comp.lang.python Subject: was Re: Type inference now simplicity Neil Hodgson wrote: > I found this article quite depressing. One of the effects of .NET appears > to be the homogenisation of programming languages. When the platform > emphasises compilation, compiler helpful warts like variable declaration and > "option fast" start appearing. There is a place for languages with optional > typing but there is also a place for a language that tries to stay very > simple. > > VB has been on a long journey of complexification which has been great > for many but has left some people behind. One of my mates works as a > manager/bureaucrat - programming isn't a significant part of his job but > over the years he's been able to write bits of dBase, Excel macros and HTML > with embedded JavaScript. Excel moved from a simple macro language to a > simplified VB variant (OK, so far) to using full VB (getting worse) and then > VB starts gaining C++ features (bad). So this bloke has stopped programming > in Excel - just too hard now. Adding 'programming in the large' features > appears good to help the more advanced users but it introduces unwanted > complexity for others. JavaScript was the last refuge of simplicity but now > Microsoft (and Netscape) are moving it into the same zone as Python, VB and > C#. I expect a new simple language will appear, gain some users and then > embark on the same journey to complexity. I agree with this. With Python, I'm opposed to the idea of adding autoincrement operators like += etc. I'm opposed to adding the extra for loop stuff like "for [x,y,z] in [a,b,c]." And I'm opposed to it because it seems like sugar to me. I've always loved Python's simplicity, and I hope it stays that way. Adding new operators and new syntax will make Python harder to read, and harder to learn. I don't want that. Simplicity always seems to improve things. Usually, I can improve by removing rather than adding. Concepts like WikiWiki, Refactoring, etc. appeal to me tremendously. -- Shae Matijs Erisson - http://www.webwitches.com/~shae/ VirtualPairProgramming Wanted - Linux/Emacs/Python/Speak Freely .fi: rakastan ohjelmointia - python kengitt?? aasia -- http://www.python.org/mailman/listinfo/python-list From guido at beopen.com Thu Jul 27 08:11:28 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 01:11:28 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 00:59:15 EST." <200007270559.AAA04753@cj20424-a.reston1.va.home.com> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> Message-ID: <200007270611.BAA04802@cj20424-a.reston1.va.home.com> I should add something about the assumed pseudo thread-safety of a+=b. I think this assumption is bogus, since we have to load a, do some stuff, and then store a, and we can't guarantee that the stuff we do is atomic -- in face we *know* it's not if it involves a user-defined method. Simply put: a += 1 IS NOT ATOMIC! Note that C doesn't guarantee that a++ is atomic either, even if a is declared volatile. (I believe there's an atomic data type, but I don't think it guarantees atomic ++. That would be very expensive because the VM cache would have to be flushed on multiprocessor machines. The only docs I found are at http://www.gnu.org/manual/glibc-2.0.6/html_node/libc_365.html.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From tim_one at email.msn.com Thu Jul 27 07:17:03 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 01:17:03 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <14719.49496.935765.730596@anthem.concentric.net> Message-ID: > >>>>> "Fred" == Fred L Drake, Jr writes: > > Fred> Barry may have access to an SMP Sparc machine; if so, we'll > Fred> be checking it out there. [Barry] > I thought I did, but nope, it's a single processor. What about SF? In parallel, could someone summarize the symptoms? Exactly how does it fail? Does it fail the same way across all platforms on which it does fail? Does it fail every time on all platforms on which it fails, or fail only some of the time on all platforms on which it fails, or fails some of the time on some of the platforms on which it fails but fails all of the time on the rest of the platforms on which it fails ? If there exists a platform on which it fails but it doesn't fail every time on that platform, that would be strong evidence of a timing hole. Those usually require thought to identify and repair. I'll voluteer to eyeball the code and do some thinking, but not unless the symptoms suggest that's worthwhile. ignorantly y'rs - tim From thomas at xs4all.net Thu Jul 27 09:21:44 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 09:21:44 +0200 Subject: [Python-Dev] test_fork1 on SMP? In-Reply-To: ; from tim_one@email.msn.com on Thu, Jul 27, 2000 at 12:32:02AM -0400 References: <20000727060442.Q266@xs4all.nl> Message-ID: <20000727092144.R266@xs4all.nl> On Thu, Jul 27, 2000 at 12:32:02AM -0400, Tim Peters wrote: > [Thomas Wouters] > > I have also seen test_fork1 failures on BSDI, using a SMP machine, but > > I haven't tried it on non-SMP (we don't have too many of those). > > However, all our BSDI kernels are the same, having been built for SMP. > > Meetings permitting (which is doubtful, today :-() I'll see if I can > > pin that down. > > > > It would, however, be fairly peculiar if test_fork1 breaks on all > > SMP-supporting systems... I don't really recall a reason for thread > > semantics to change reliably based on kernel/cpu settings, and it would > > be silly for them to do so! But I'll admit threads are silly, period ;-) > Silly? Without threads your clothes would fall off . Clothes ? What clothes ? I'm stuck in meetings all day, remember, and those require a suit and tie. And I have suit nor tie ;) > I wonder whether the "fork" part is a red herring here. It's extremely rare > to see a thread bug that actually requires a multi-headed machine to trigger > (in fact, I don't believe I've ever seen one), but the nature of races in > flawed threaded code is often such that you're a million times more *likely* > to hit a bad timing window on a multi-headed machine than on a time-sliced > single-headed box. Actually, I got the impression the 'bug' wasn't only present on multi-headed Linux machines with an SMP kernel, but single-headed Linux machines with an SMP kernel as well. You see, in Linux, the extra logic required for SMP is optional, at compile time. It changes a lot in the scheduler, but I'm not sure if it should be visible from outside. I haven't actually tested it on a UP machine with SMP kernel, though. And anyway, I thought the test_fork1 test tested for fork() behaviour in threads. It spawns a thread, fork()s one of those threads, and tests to see if the other threads still exist after the fork(), in the new child. The entire test is done in Python code, so how the scheduler and/or race conditions come into play isn't too obvious to me. Except of course the whole test if flawed. > > 6-AM-and-preparing-for-a-full-10-hour-day-of-meetings-:-S-ly y'rs, > So long as you still put in your 18 hours on Python today, we're happy to > let you engage in all the recreational activities you like . I'll clock the hours I spend thinking about Python in those meetings, so not to worry ;) Dreaming-Python-makes-it-24h-a-day-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Thu Jul 27 09:32:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 09:32:42 +0200 Subject: [Python-Dev] Product iteration References: Message-ID: <005f01bff79c$daa0e6c0$f2a6b5d4@hagrid> moshe wrote: > On Wed, 26 Jul 2000, Jeremy Hylton wrote: > > > The argument about finalization is specious. You should not write > > code that depends on current finalization semantics to do things like > > closing files. It's relying on an implementation-dependent feature > > that is not part of the language spec. (Just try it on JPython.) > > I know, and I'm not. But the thing is, there are plenty of users of > CPython which do rely on this feature -- so you're going to break > people's code. Not nice. one problem is that there are many places when you don't know if you can close the file or not -- whoever handed you the file handle might expect it to remain open after you've done with it. That's why people use stuff like: self.fp = None # close if I'm the last user ::: But wouldn't fp = fopen(...); if (!fp && (errno == EMFILE || errno == ENFILE)) { py_force_gc(); fp = fopen(...); } solve this, at least for simple scripts? From effbot at telia.com Thu Jul 27 09:39:40 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 09:39:40 +0200 Subject: [Python-Dev] failures in the regression tests References: Message-ID: <007b01bff79d$d3f5f120$f2a6b5d4@hagrid> tim wrote: > Seems odd that test_popen2 is still being skipped (I thought we were fixing > popen & friends under Windows, but lost track of that). well, didn't you volunteer to fix the last few things for Win9X? ;-) (the w9xpopen.exe needs to be built and installed in the proper place, but I'm using VC5 and would really prefer if someone with VC6 took care of that...) From effbot at telia.com Thu Jul 27 09:44:30 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 09:44:30 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> Message-ID: <008301bff79e$806d3f80$f2a6b5d4@hagrid> finn bock wrote: > Java (and JPython) compares the 16-bit characters numericly which result in: > > JPython 1.1+08 on java1.3.0 (JIT: null) > Copyright (C) 1997-1999 Corporation for National Research Initiatives > >>> print u'\ue000' < u'\ud800' > 0 > >>> print ord(u'\ue000') < ord(u'\ud800') > 0 > >>> > > I don't think I can come up with a solution that allow JPython to emulate > CPython on this type of comparison. since we don't really support surrogates (or anything else related to 32-bit unicode) anywhere else, I'd rather change CPython to emulate JPython here. (just #ifdef out the neat stuff, and don't switch it on again before we've sorted all other 32-bit unicode issues...) From effbot at telia.com Thu Jul 27 09:53:52 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 09:53:52 +0200 Subject: [Python-Dev] failures in the regression tests References: Message-ID: <009d01bff79f$d0b5cf60$f2a6b5d4@hagrid> tim wrote: > Seems odd that test_popen2 is still being skipped (I thought we were fixing > popen & friends under Windows, but lost track of that). umm. looks like I forgot to check in my test_popen2.py changes. the original code skipped the test if it couldn't find os.fork... ::: if you don't have w9xpopen in place, the test will "crash": test test_popen2 crashed -- exceptions.OSError : [Errno 2] No such file or directory From mal at lemburg.com Thu Jul 27 09:58:16 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 09:58:16 +0200 Subject: [Python-Dev] test_fork1 on SMP? References: <20000725153912.A21409@ActiveState.com> <397E3519.83E6CA14@pool.informatik.rwth-aachen.de> <20000725160259.C21409@ActiveState.com> <397E9D00.6E80A08F@pool.informatik.rwth-aachen.de> <20000726093024.C26632@ActiveState.com> <397F3087.D4E38ED2@nowonder.de> <14719.42737.305992.235671@cj42289-a.reston1.va.home.com> <20000727060442.Q266@xs4all.nl> Message-ID: <397FEB98.17176FF0@lemburg.com> Thomas Wouters wrote: > > On Wed, Jul 26, 2000 at 11:05:21PM -0400, Fred L. Drake, Jr. wrote: > > > > Peter Schneider-Kamp writes: > > > Could SMP be involved? Do you get the same on a non-SMP system? > > > Do others have the same problem with SMP systems? > > > I think Barry may have access to an SMP Sparc machine; if so, we'll > > be checking it out there. > > I have also seen test_fork1 failures on BSDI, using a SMP machine, but I > haven't tried it on non-SMP (we don't have too many of those). However, all > our BSDI kernels are the same, having been built for SMP. Meetings > permitting (which is doubtful, today :-() I'll see if I can pin that down. > > It would, however, be fairly peculiar if test_fork1 breaks on all > SMP-supporting systems... I don't really recall a reason for thread > semantics to change reliably based on kernel/cpu settings, and it would be > silly for them to do so! But I'll admit threads are silly, period ;-) Could you be more specific about which aspect of test_fork1.py fails ? After looking at the code it seems that it's not the os.fork() itself that is not working, but some particular combination of using os.fork() on a process with multiple threads running. If the latter is the case, then I'd propose to simply switch off threads for SMP machines (is there a compile time switch we could use for this ?) until we have figured out what causes the problem. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 27 10:02:49 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 10:02:49 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> Message-ID: <397FECA9.56BB1C50@lemburg.com> Guido van Rossum wrote: > > I should add something about the assumed pseudo thread-safety of a+=b. > > I think this assumption is bogus, since we have to load a, do some > stuff, and then store a, and we can't guarantee that the stuff we do > is atomic -- in face we *know* it's not if it involves a user-defined > method. > > Simply put: > > a += 1 IS NOT ATOMIC! > > Note that C doesn't guarantee that a++ is atomic either, even if a is > declared volatile. (I believe there's an atomic data type, but I > don't think it guarantees atomic ++. That would be very expensive > because the VM cache would have to be flushed on multiprocessor > machines. The only docs I found are at > http://www.gnu.org/manual/glibc-2.0.6/html_node/libc_365.html.) If that's the case, then why do we need augemented assignments at all ? (I understood the atomicness being the main argument for introducing augmented assigns.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jul 27 10:22:31 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 10:22:31 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> Message-ID: <397FF146.2D307063@lemburg.com> Finn Bock wrote: > > CPythons unicode compare function contains some code to compare surrogate > characters in code-point order (I think). This is properly a very neat > feature but is differs from java's way of comparing strings. > > Python 2.0b1 (#0, Jul 26 2000, 21:29:11) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > >>> print u'\ue000' < u'\ud800' > 1 > >>> print ord(u'\ue000') < ord(u'\ud800') > 0 > >>> > > Java (and JPython) compares the 16-bit characters numericly which result in: > > JPython 1.1+08 on java1.3.0 (JIT: null) > Copyright (C) 1997-1999 Corporation for National Research Initiatives > >>> print u'\ue000' < u'\ud800' > 0 > >>> print ord(u'\ue000') < ord(u'\ud800') > 0 > >>> > > I don't think I can come up with a solution that allow JPython to emulate > CPython on this type of comparison. The code originally worked the same way as what Java does here. Bill Tutt then added ideas from some IBM Java lib which turns the UTF-16 comparison into a true UCS-4 comparison. This really has nothing to do with being able to support surrogates or not (as Fredrik mentioned), it is the correct behaviour provided UTF-16 is used as encoding for UCS-4 values in Unicode literals which is what Python currently does. BTW, does Java support UCS-4 ? If not, then Java is wrong here ;-) Comparing Unicode strings is not as trivial as one might think: private point areas introduce a great many possibilities of getting things wrong and the fact that many characters can be expressed by combining other characters adds to the confusion. E.g. for sorting, we'd need full normalization support for Unicode and would have to come up with some smart strategy to handle private code point areas. All this is highly non-trivial and will probably not get implemented for a while (other issues are more important right now, e.g. getting the internals to use the default encoding instead of UTF-8). For now I'd suggest leaving Bill's code activated because it does the right thing for Python's Unicode implementation (which is built upon UTF-16). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Thu Jul 27 11:06:23 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 11:06:23 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007270559.AAA04753@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 12:59:15AM -0500 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> Message-ID: <20000727110622.S266@xs4all.nl> On Thu, Jul 27, 2000 at 12:59:15AM -0500, Guido van Rossum wrote: > I'm making up opcodes -- the different variants of LOAD and STORE > don't matter. On the right I'm displaying the stack contents after > execution of the opcode (push appends to the end). I'm writing > 'result' to indicate the result of the += operator. I take it you rather see a 'AUGOP' bytecode than a 'GETSET_' bytecode, that does the loading, operation and storing ? Not that I disagree, not at all, I just want to have that clear ;) > There are two more forms of potential interest. First, what should > happen to a tuple assignment? > > a, b, c += x > > (Which is exactly the same as "(a, b, c) += x".) Here's what happens now: >>> (a, b, c) += 1,2,3 SyntaxError: no augmented assignment to tuple (Isn't a reference implementation a cool thing ? ;) > Second, what should happen to a slice assignment? The basic slice > form is: > a[i:j] += b > but there are others: Python's slice syntax allows an arbitrary [yadah] What's so special about slice assignment ? You yourself (though Tim) suggested the following: x += y is effectively (minus order and number of evaluations) x = x.__add_ab__(y) Where __add_ab__() is the Python method, if 'x' is a python class, or plain '__add__' if 'x' doesn't have an '__add_ab__', or 'y.__radd__' if x doesn't have __add__. Similarly, if 'x' is a builtin, tp_as_number->nb_inplace_add is used, or tp_as_number->nb_add, etc. (Or sq_concat, if it's a seq and the operator is add.) The __add_ab__ method, or the C equivalent, can decide for itself whether it should return 'self', thus making the operation truly in-place, or a new instance of an object. This may seem as a complicated and unexpected way to do things, but it makes it possible to transparently support __add__ and __radd__ too, because they already return new objects. And you (through Tim) literally scolded me for trying to suggest x[1:10] += y being something like x = x.__add_slice_ab__(y, slice(1,10)) Instead, it should become x[1:10] = x[1:10] + y (Or rather, to keep the same order of evaluation:) tmp1 = y # in case of a more complicated expression tmp2 = x[1:10] x[1:10] = tmp2.__add_ab__(tmp1) The whole story about how complicated, convoluted and confusing Python's slicing is, though interesting and correct, is not connected to augmented assignment ;) > a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] += 1 Becomes tmp1 = a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] = tmp1.__add_ab__(1) > It would be nice if the SLICE bytecodes were removed altogether and > instead slice() objects would be created for all slices, even basic > ones. (I believe this was proposed in this list at some point.) The > original SLICE opcodes were introduced in ancient times, when basic > slices were the only accepted slice syntax. Agreed, however! You can't just make all slices use a sliceobject, for two reasons: a C extention type can use both the sequence and the mapping interface, and might not expect basic slices to be turned into a slice object. For instance, it's mapping interface may raise a TypeError, "Slices not supported", when it encounters a slice. Choosing mapping over sequence methods may break all that code. The same goes for Python classes. The other reason is usability. The current __get_slice__(self, start, end) sytnax is very convenient for nearly all uses of slices. Possibly because the builtin types don't handle extended slices currently, and possibly because the slice-object way is not generally known. (Just recently, there was someone asking on python-list on how to use slices. I'm not sure if he got a proper answer, but I've never seen such questions on the subject of basic slices!) If we do get a new __get_slice__ that handles all slices, I suggest doing it like this: class X: def __get_newslice__(self, (start, end, step)): where the type of start, end and step is not defined. This can be done with slice objects and sequence-unpacking, of course, but it makes it a lot more usable. Back-to-my-meetings-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From effbot at telia.com Thu Jul 27 12:12:48 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 12:12:48 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> Message-ID: <002101bff7b3$38232fe0$f2a6b5d4@hagrid> mal wrote: > This really has nothing to do with being able to support > surrogates or not (as Fredrik mentioned), it is the correct > behaviour provided UTF-16 is used as encoding for UCS-4 values > in Unicode literals which is what Python currently does. Really? I could have sworn that most parts of Python use UCS-2, not UTF-16. Built-ins like ord, unichr, len; slicing; string methods; regular expressions, etc. all clearly assume that a Py_UNICODE is a unicode code point. My point is that we shouldn't pretend we're supporting UTF-16 if we don't do that throughout. As far as I can tell, cmp() is the *only* unicode function that thinks the internal storage is UTF-16. Everything else assumes UCS-2. And for Python 2.0, it's surely easier to fix cmp() than to fix everything else. (this is the same problem as 8-bit/unicode comparisions, where the current consensus is that it's better to raise an exception if it looks like the programmer doesn't know what he was doing, rather than pretend it's another encoding). ::: To summarize, here's the "character encoding guidelines" for Python 2.0: In Unicode context, 8-bit strings contain ASCII. Characters in the 0x80-0xFF range are invalid. 16-bit strings contain UCS-2. Characters in the 0xD800-0xDFFF range are invalid. If you want to use any other encoding, use the codecs pro- vided by the Unicode subsystem. If you need to use Unicode characters that cannot be represented as UCS-2, you cannot use Python 2.0's Unicode subsystem. Anything else is just a hack. From pf at artcom-gmbh.de Thu Jul 27 12:08:07 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Thu, 27 Jul 2000 12:08:07 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: from Mark Hammond at "Jul 27, 2000 2:47: 7 pm" Message-ID: Hi all, This rant is about automatically reclaimed resources like file descriptors. First let me cite a few sentences from the ancient book "Programming Python" written by Mark Lutz (p.122). Since this was the very first available book on Python, it could be considered as some kind of Python Programmers Guide. Much existing code today relies on the lessons teached there: """The short answer is that all files in this program are closed automatically: there's no need to call the file object "close" method. [...] More specifically, Python uses a reference count garbage collection strategy to reclaim memory behind the scenes. [...] each time we set 'input' to a new file in the for loop above, its previous value can be reclaimed. [...] When a file object is reclaimed, the file is automatically closed [...] We usually don't need to close such files manually; [...] """ A typical code example (simplified from a real application) : >>> import os, rfc822 >>> posters = {} >>> for arti in os.listdir('/var/spool/news/comp/lang/python'): ... poster = rfc822.Message(open(arti)).get("From") ... posters[poster] = posters.get(poster, 0) + 1 ... >>> for poster, howoften in posters.items(): ... print poster, "posted", howoften, "times to clp." ... I'm in no way convinced to consider code like above as broken. This simple automatic and deterministic behaviour of C-Python is part of the attractive elegance of Python and one of the major advantages over other languages like Java, that IMO suck beans. I've *NOT* tried scripts like the example above with JPython. But if JPython would run out of available file descriptors with such a simple application, then I think JPython or the Java VM are broken. Jeremy Hylton : > The argument about finalization is specious. You should not write > code that depends on current finalization semantics to do things like > closing files. It's relying on an implementation-dependent feature > that is not part of the language spec. (Just try it on JPython.) Eric S. Raymond" : > I strongly agree. Mark Hammond (answering to Moshe): > No - we will simply be pointing out their already broken code. We arent > breaking anything! > > I have no problem with this at all. The sooner we point out the broken > code the better. The last thing we want is for obviously and documented > broken code to suddenly be considered non-broken simply by the volume of > poor code out there... > > Either way, I think you are overstating the problem. The main scenario is > closing resources, and for most users these are unlikely to be so scarce > that delaying their finalization will cause problems. If someone is > writing a web-server, for example, and assumes that files or sockets are > automatically closed, and they open them at such a rate that true GC causes > them a problem, then IMO they have got what they deserve ;-) no no no. This time I have to agree with Moshe and disagree with Mark, Jeremy, Eric. Or I've missed the point. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From thomas at xs4all.net Thu Jul 27 12:22:24 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 12:22:24 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <397FECA9.56BB1C50@lemburg.com>; from mal@lemburg.com on Thu, Jul 27, 2000 at 10:02:49AM +0200 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> Message-ID: <20000727122223.T266@xs4all.nl> On Thu, Jul 27, 2000 at 10:02:49AM +0200, M.-A. Lemburg wrote: > Guido van Rossum wrote: > > I should add something about the assumed pseudo thread-safety of a+=b. > > Simply put: > > > > a += 1 IS NOT ATOMIC! > If that's the case, then why do we need augemented assignments > at all ? > (I understood the atomicness being the main argument for > introducing augmented assigns.) Nah, that was just something that emerged from my implementation, and only stood up in the face of simple builtin objects. I probably shouldn't have mentioned this ;-P I can't say anything about Guido's reasons for augmented assignment, but mine are ease-of-use, ease of use, and the ease of usage. And-python-is-all-about-ease-of-use-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jul 27 12:30:53 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 12:30:53 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> Message-ID: <39800F5D.C8ECF801@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > This really has nothing to do with being able to support > > surrogates or not (as Fredrik mentioned), it is the correct > > behaviour provided UTF-16 is used as encoding for UCS-4 values > > in Unicode literals which is what Python currently does. > > Really? I could have sworn that most parts of Python use > UCS-2, not UTF-16. The design specifies that Py_UNICODE refers to UTF-16. To make life easier, the implementation currently assumes UCS-2 in many parts, but this is should only be considered a temporary situation. Since supporting UTF-16 poses some real challenges (being a variable length encoding), full support for surrogates was postponed to some future implementation. > Built-ins like ord, unichr, len; slicing; > string methods; regular expressions, etc. all clearly assume > that a Py_UNICODE is a unicode code point. > > My point is that we shouldn't pretend we're supporting > UTF-16 if we don't do that throughout. We should keep that design detail in mind though. > As far as I can tell, cmp() is the *only* unicode function > that thinks the internal storage is UTF-16. > > Everything else assumes UCS-2. True. > And for Python 2.0, it's surely easier to fix cmp() than to > fix everything else. Also true :-) > (this is the same problem as 8-bit/unicode comparisions, where > the current consensus is that it's better to raise an exception > if it looks like the programmer doesn't know what he was doing, > rather than pretend it's another encoding). Perhaps you are right and we should #if 0 the comparison sections related to UTF-16 for now. I'm not sure why Bill needed the cmp() function to support surrogates... Bill ? Still, it will have to be reenabled sometime in the future when full surrogate support is added to Python. > ::: > > To summarize, here's the "character encoding guidelines" for > Python 2.0: > > In Unicode context, 8-bit strings contain ASCII. Characters > in the 0x80-0xFF range are invalid. 16-bit strings contain > UCS-2. Characters in the 0xD800-0xDFFF range are invalid. The latter is not true. In fact, thanks to Bill, the UTF-8 codec supports processing surrogates already and will output correct UTF-8 code even for Unicode strings containing surrogates. > If you want to use any other encoding, use the codecs pro- > vided by the Unicode subsystem. If you need to use Unicode > characters that cannot be represented as UCS-2, you cannot > use Python 2.0's Unicode subsystem. See above. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Thu Jul 27 15:09:37 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 08:09:37 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 10:02:49 +0200." <397FECA9.56BB1C50@lemburg.com> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> Message-ID: <200007271309.IAA06750@cj20424-a.reston1.va.home.com> > > Simply put: > > > > a += 1 IS NOT ATOMIC! > > > If that's the case, then why do we need augemented assignments > at all ? > > (I understood the atomicness being the main argument for > introducing augmented assigns.) Huh? Where did you get that idea? Can you point to a message where this was indicated? The reason for introducing it is that it's been the single-most requested feature ever since Python's inception. I think the reason it's been requested so much is that it's a waste of typing skills as well as (and more importantly) unnecessary extra effort to deduce what's going on in code like a.b.f().x[i] = a.b.f().x[i] + 1 Another important reason is that in cases like a[long_and_expensive_call()] = a[long_and_expensive_call()] + 1 you want to avoid doing the long_and_expensive_call() twice. Introducing a temp variable reduces the readability of the code. Note that my proposed semantics guarantee that in a[long_and_expensive_call()] += 1 the index is computed only once -- but this is not the same as atomicity (which has to do with other threads, signal handlers and similar asynchronous things). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Vladimir.Marangozov at inrialpes.fr Thu Jul 27 14:22:13 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 27 Jul 2000 14:22:13 +0200 (CEST) Subject: [Python-Dev] failures in the regression tests In-Reply-To: from "Tim Peters" at Jul 26, 2000 11:23:52 PM Message-ID: <200007271222.OAA02394@python.inrialpes.fr> Tim Peters wrote: > > On Win98, with the CVS version as of 11:15pm EDT, in both debug and release > builds: > > 59 tests OK. > 3 tests failed: test_mmap test_winreg test_winreg2 Make that 58/4 because of test_re which failure is hidden in output/test_re. /F - do you know at least what's going on? The SRE engine is a already a recurrent theme on this list, so I won't repeat what has been said, but if you can't sched some light on the errors, maybe documenting a little more the SRE code and its design would help the knowledgeable here to look at it and provide some help? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at beopen.com Thu Jul 27 15:37:24 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 08:37:24 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 11:06:23 +0200." <20000727110622.S266@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> Message-ID: <200007271337.IAA09101@cj20424-a.reston1.va.home.com> > I take it you rather see a 'AUGOP' bytecode than a 'GETSET_' bytecode, > that does the loading, operation and storing ? Not that I disagree, not at > all, I just want to have that clear ;) Yes, mostly because there are so many variants based on the kind of loading and storing: for each load-type operator you need 11 GETSET operators, and there are many different load operators: local, global, unspecified (== local by dict instead), by attribute, by index, or by slice... I am still neutral on the choice between a single AUGOP with an argument that takes an argument specifying the opcode, and 11 new operators: AUGASS_ADD, ... (Actually, the latter seem the most logical given that we also have BINARY_ADD, ...) > Here's what happens now: > > >>> (a, b, c) += 1,2,3 > SyntaxError: no augmented assignment to tuple > > (Isn't a reference implementation a cool thing ? ;) Very nice. Don't touch that part. > > Second, what should happen to a slice assignment? The basic slice > > form is: > > > a[i:j] += b > > > but there are others: Python's slice syntax allows an arbitrary [yadah] > > What's so special about slice assignment ? The only special thing about slice assignment is that there are 12 extra opcodes to deal with slices in the non-augmented-assignment case. I was making a case for avoiding this explosion, but somehow I got lost in my own train of thought. :( > You yourself (though Tim) > suggested the following: > > x += y > > is effectively (minus order and number of evaluations) > > x = x.__add_ab__(y) > > Where __add_ab__() is the Python method, if 'x' is a python class, or plain > '__add__' if 'x' doesn't have an '__add_ab__', or 'y.__radd__' if x doesn't > have __add__. Similarly, if 'x' is a builtin, tp_as_number->nb_inplace_add is > used, or tp_as_number->nb_add, etc. (Or sq_concat, if it's a seq and the > operator is add.) > > The __add_ab__ method, or the C equivalent, can decide for itself whether it > should return 'self', thus making the operation truly in-place, or a new > instance of an object. This may seem as a complicated and unexpected way to > do things, but it makes it possible to transparently support __add__ and > __radd__ too, because they already return new objects. > > And you (through Tim) literally scolded me for trying to suggest > > x[1:10] += y > > being something like > > x = x.__add_slice_ab__(y, slice(1,10)) > > Instead, it should become > > x[1:10] = x[1:10] + y > > (Or rather, to keep the same order of evaluation:) > > tmp1 = y # in case of a more complicated expression > tmp2 = x[1:10] > x[1:10] = tmp2.__add_ab__(tmp1) > > The whole story about how complicated, convoluted and confusing Python's > slicing is, though interesting and correct, is not connected to augmented > assignment ;) > > > a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] += 1 > > Becomes > > tmp1 = a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] > a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] = tmp1.__add_ab__(1) Yes. I should have realized earlier on that my pseudo code was just spelling out the necessary DUP etc. opcodes to avoid calculating the location of 'a' or the index(es) twice. Looking at my pseudo code for "a[i:j] += b" again, I realize that there's no reason to treat basic slices different than in other contexts -- it can be done with just DUP, ROT3 and ROT4: a[i:j] += b LOAD a [a] DUP [a, a] LOAD i [a, a, i] DUP [a, a, i, i] ROT3 [a, i, a, i] LOAD j [a, i, a, i, j] DUP [a, i, a, i, j, j] ROT4 [a, i, j, a, i, j] GETSLICE [a, i, j, slice] LOAD b [a, i, j, slice, b] AUGADD [a, i, j, result] SETSLICE [] So we need a new opcode ROT4 (or ROT_FOUR to be consistent in the spelling). > > It would be nice if the SLICE bytecodes were removed altogether and > > instead slice() objects would be created for all slices, even basic > > ones. (I believe this was proposed in this list at some point.) The > > original SLICE opcodes were introduced in ancient times, when basic > > slices were the only accepted slice syntax. > > Agreed, however! You can't just make all slices use a sliceobject, for two > reasons: a C extention type can use both the sequence and the mapping > interface, and might not expect basic slices to be turned into a slice > object. For instance, it's mapping interface may raise a TypeError, "Slices > not supported", when it encounters a slice. Choosing mapping over sequence > methods may break all that code. The same goes for Python classes. That's right. The backwards compatibility issues are the most daunting. > The other reason is usability. The current __get_slice__(self, start, end) > sytnax is very convenient for nearly all uses of slices. Possibly because > the builtin types don't handle extended slices currently, and possibly > because the slice-object way is not generally known. (Just recently, there > was someone asking on python-list on how to use slices. I'm not sure if he > got a proper answer, but I've never seen such questions on the subject of > basic slices!) > > If we do get a new __get_slice__ that handles all slices, I suggest doing it > like this: > > class X: > def __get_newslice__(self, (start, end, step)): > > where the type of start, end and step is not defined. This can be done with > slice objects and sequence-unpacking, of course, but it makes it a lot more > usable. Another alternative that tries to preserve compatibility is to call __getslice__(self, start, end) when the step is None, but __getslice__(self, start, end, step) when it isn't. Old code will raise a reasonable exception when a step is specified, while step-aware code can specify the step as a default argument value of 1 or None. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Thu Jul 27 15:41:25 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 08:41:25 -0500 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: Your message of "Thu, 27 Jul 2000 12:12:48 +0200." <002101bff7b3$38232fe0$f2a6b5d4@hagrid> References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> Message-ID: <200007271341.IAA09455@cj20424-a.reston1.va.home.com> > As far as I can tell, cmp() is the *only* unicode function > that thinks the internal storage is UTF-16. > > Everything else assumes UCS-2. > > And for Python 2.0, it's surely easier to fix cmp() than to > fix everything else. Agreed (I think). > (this is the same problem as 8-bit/unicode comparisions, where > the current consensus is that it's better to raise an exception > if it looks like the programmer doesn't know what he was doing, > rather than pretend it's another encoding). > > ::: > > To summarize, here's the "character encoding guidelines" for > Python 2.0: > > In Unicode context, 8-bit strings contain ASCII. Characters > in the 0x80-0xFF range are invalid. 16-bit strings contain > UCS-2. Characters in the 0xD800-0xDFFF range are invalid. > > If you want to use any other encoding, use the codecs pro- > vided by the Unicode subsystem. If you need to use Unicode > characters that cannot be represented as UCS-2, you cannot > use Python 2.0's Unicode subsystem. > > Anything else is just a hack. I wouldn't go so far as raising an exception when a comparison involves 0xD800-0xDFFF; after all we don't raise an exception when an ASCII string contains 0x80-0xFF either (except when converting to Unicode). The invalidity of 0xD800-0xDFFF means that these aren't valid Unicode code points; it doesn't mean that we should trap all attempts to use these values. That ways, apps that need UTF-16 awareness can code it themselves. Why? Because I don't want to proliferate code that explicitly traps 0xD800-0xDFFF throughout the code. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Thu Jul 27 15:44:26 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 08:44:26 -0500 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Your message of "Thu, 27 Jul 2000 12:08:07 +0200." References: Message-ID: <200007271344.IAA09722@cj20424-a.reston1.va.home.com> > This rant is about automatically reclaimed resources like file descriptors. > > First let me cite a few sentences from the ancient book "Programming Python" > written by Mark Lutz (p.122). Since this was the very first available book > on Python, it could be considered as some kind of Python Programmers Guide. > Much existing code today relies on the lessons teached there: > > """The short answer is that all files in this program are closed > automatically: there's no need to call the file object "close" method. > [...] > More specifically, Python uses a reference count garbage collection > strategy to reclaim memory behind the scenes. > [...] > each time we set 'input' to a new file in the for loop above, its > previous value can be reclaimed. > [...] > When a file object is reclaimed, the file is automatically closed > [...] > We usually don't need to close such files manually; > [...] > """ At the time Mark wrote, this was true. When JPython was introduced, I realized that I couldn't guarantee this in all implementations, so I removed that part of the language spec (at least in my head, and in the collective memory of the Python community). In any case, Moshe used this argument to defend weak binding to references to outer variables from inside inner functions; but that breaks closures, which is unacceptable. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From mwh21 at cam.ac.uk Thu Jul 27 14:55:19 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Thu, 27 Jul 2000 13:55:19 +0100 (BST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271337.IAA09101@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 27 Jul 2000, Guido van Rossum wrote: > > Here's what happens now: > > > > >>> (a, b, c) += 1,2,3 > > SyntaxError: no augmented assignment to tuple > > > > (Isn't a reference implementation a cool thing ? ;) > > Very nice. Don't touch that part. I think quite a lot of the code I wrote in compile.c for my augmented assignment patch lives on in Thomas's patch, and I was very conservative; if I couldn't work out what something should mean, I banned it (eg. a += b += c is a syntax error too). On reflection, I think I got this right. The error messages could be imporoved, I suspect. [snip to a very nearly completely different topic] > Another alternative that tries to preserve compatibility is to call > __getslice__(self, start, end) when the step is None, but > __getslice__(self, start, end, step) when it isn't. Old code will > raise a reasonable exception when a step is specified, while > step-aware code can specify the step as a default argument value of > 1 or None. Good idea. Are lists and tuples going to support seq[a:b:c] anytime soon? Patches welcome, I'd guess... Cheers, M. From thomas at xs4all.net Thu Jul 27 15:00:36 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 15:00:36 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271337.IAA09101@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 08:37:24AM -0500 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> Message-ID: <20000727150036.Z224@xs4all.nl> On Thu, Jul 27, 2000 at 08:37:24AM -0500, Guido van Rossum wrote: > > I take it you rather see a 'AUGOP' bytecode than a 'GETSET_' bytecode, > > that does the loading, operation and storing ? Not that I disagree, not at > > all, I just want to have that clear ;) > Yes, mostly because there are so many variants based on the kind of > loading and storing: for each load-type operator you need 11 GETSET > operators, and there are many different load operators: local, global, > unspecified (== local by dict instead), by attribute, by index, or by > slice... Except if you add a new type of bytecode, the 2-argument type. Which is what my implementation currently does. It necessitates just 9 new bytecodes that way: GETSET_SUBSCR, SLICE+0 through SLICE+3, NAME, FAST, GLOBAL and ATTR. The last four need 2 arguments, one for the name-index (or local vrbl number) and one for the actual operation. > I am still neutral on the choice between a single AUGOP with an > argument that takes an argument specifying the opcode, and 11 new > operators: AUGASS_ADD, ... (Actually, the latter seem the most > logical given that we also have BINARY_ADD, ...) Agreed. However, there isn't enough place in the current bytecode ranges for 9 consecutive non-argument opcodes. I'm also not sure how scarce a commodity opcodes are. Then again, it can also be 'undone' later. > > What's so special about slice assignment ? > The only special thing about slice assignment is that there are 12 > extra opcodes to deal with slices in the non-augmented-assignment > case. I was making a case for avoiding this explosion, but somehow I > got lost in my own train of thought. :( There's no explosion in the augmented assignment case, anyhow: either it's just 4 opcodes for handling slices, or it reuses the current opcodes. > So we need a new opcode ROT4 (or ROT_FOUR to be consistent in the > spelling). Yes. How about a ROT_ANY argument opcode while we're at it ? would specify the number to rotate... you could even encode *how* to rotate in that argument. (using the upper byte, imposing a sensible limit of 255 for the number of rotations ;-) > > class X: > > def __get_newslice__(self, (start, end, step)): > > where the type of start, end and step is not defined. This can be done with > > slice objects and sequence-unpacking, of course, but it makes it a lot more > > usable. > Another alternative that tries to preserve compatibility is to call > __getslice__(self, start, end) when the step is None, but > __getslice__(self, start, end, step) when it isn't. Old code will > raise a reasonable exception when a step is specified, while > step-aware code can specify the step as a default argument value of > 1 or None. Yes, that's very reasonable. I would suggest making the error 'special', in this case, though. So that you don't get a TypeError about incorrect number of arguments, but rather a 'object does not support extended slices' or some such TypeError. Actually, it might be worth doing it like this: Try to call __getslice__ with unconverted start, stop and step If it fails with a TypeError, and step is not None, raise the above error Else, convert start and stop to ints like the current normal slice behaviour, and try __getslice__ the old way. Or is that too much magic ? I don't think it'll break anything written in Python code, but I'm not sure what to do with the C API... But it's easier to break the API than Python code, me thinks. Break-over-godda-run-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Thu Jul 27 15:02:05 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 15:02:05 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: ; from mwh21@cam.ac.uk on Thu, Jul 27, 2000 at 01:55:19PM +0100 References: <200007271337.IAA09101@cj20424-a.reston1.va.home.com> Message-ID: <20000727150204.A224@xs4all.nl> On Thu, Jul 27, 2000 at 01:55:19PM +0100, Michael Hudson wrote: > I think quite a lot of the code I wrote in compile.c for my augmented > assignment patch lives on in Thomas's patch, and I was very conservative; > if I couldn't work out what something should mean, I banned it Yup, that's all yours. I wouldn't have known how to ban it anyway, and I wouldn't have known where to start *anything* without your patch, Michael! Gratefully-y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jul 27 15:01:51 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 15:01:51 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> <200007271309.IAA06750@cj20424-a.reston1.va.home.com> Message-ID: <398032BF.1F9A09ED@lemburg.com> Guido van Rossum wrote: > > > > Simply put: > > > > > > a += 1 IS NOT ATOMIC! > > > > > If that's the case, then why do we need augemented assignments > > at all ? > > > > (I understood the atomicness being the main argument for > > introducing augmented assigns.) > > Huh? Where did you get that idea? Can you point to a message where > this was indicated? It was advertised this way by Thomas: http://www.python.org/pipermail/python-list/2000-June/060680.html And since assignments in Python are thread safe, I thought it would only be natural for augemented assigns to also be thread safe which would have been a real advantage, since a=a+1 is not thread safe. All other uses simply boil down to reducing typing efforts, IMHO. (But that shouldn't keep you from adding it to the language ;-) Some comments: > The reason for introducing it is that it's been the single-most > requested feature ever since Python's inception. I think the reason > it's been requested so much is that it's a waste of typing skills as > well as (and more importantly) unnecessary extra effort to deduce > what's going on in code like > > a.b.f().x[i] = a.b.f().x[i] + 1 This can be written as: result = a.b.f().x result[i] = result[i] + 1 > Another important reason is that in cases like > > a[long_and_expensive_call()] = a[long_and_expensive_call()] + 1 Dito for this one: i = long_and_expensive_call() a[i] = a[i] + 1 > you want to avoid doing the long_and_expensive_call() twice. > Introducing a temp variable reduces the readability of the code. Not really... in fact if the name makes it clear what it refers too, it can augment the readbility. Besdies, a.b.f().x[i] isn't good style to begin with ;-) > Note that my proposed semantics guarantee that in > > a[long_and_expensive_call()] += 1 > > the index is computed only once -- but this is not the same as > atomicity (which has to do with other threads, signal handlers and > similar asynchronous things). Nevermind... I just wanted to hint at the added value of making these assignments atomic operations and not just an optimization of a = a + 1. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Thu Jul 27 16:12:58 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 09:12:58 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 13:55:19 +0100." References: Message-ID: <200007271412.JAA12251@cj20424-a.reston1.va.home.com> > Good idea. Are lists and tuples going to support seq[a:b:c] anytime soon? It's on my wish list, but can't be done for 2.0. > Patches welcome, I'd guess... Yes. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Thu Jul 27 16:22:48 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 09:22:48 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 15:00:36 +0200." <20000727150036.Z224@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> Message-ID: <200007271422.JAA13096@cj20424-a.reston1.va.home.com> > > Yes, mostly because there are so many variants based on the kind of > > loading and storing: for each load-type operator you need 11 GETSET > > operators, and there are many different load operators: local, global, > > unspecified (== local by dict instead), by attribute, by index, or by > > slice... > > Except if you add a new type of bytecode, the 2-argument type. Which is what > my implementation currently does. It necessitates just 9 new bytecodes that > way: GETSET_SUBSCR, SLICE+0 through SLICE+3, NAME, FAST, GLOBAL and ATTR. > The last four need 2 arguments, one for the name-index (or local vrbl > number) and one for the actual operation. But the two-arg opcode format slows down the opcode decoding -- and that's the most time-critical part of all of ceval.c! > > I am still neutral on the choice between a single AUGOP with an > > argument that takes an argument specifying the opcode, and 11 new > > operators: AUGASS_ADD, ... (Actually, the latter seem the most > > logical given that we also have BINARY_ADD, ...) > > Agreed. However, there isn't enough place in the current bytecode ranges for > 9 consecutive non-argument opcodes. I'm also not sure how scarce a commodity > opcodes are. Then again, it can also be 'undone' later. There's no need for them to be consecutive! (The BINARY_* family isn't even consecutive!) I say, just some open ranges, like 54-59 and 73-79. > Yes. How about a ROT_ANY argument opcode while we're at it ? would > specify the number to rotate... you could even encode *how* to rotate in > that argument. (using the upper byte, imposing a sensible limit of 255 for > the number of rotations ;-) No, let's not overgeneralize. > > Another alternative that tries to preserve compatibility is to call > > __getslice__(self, start, end) when the step is None, but > > __getslice__(self, start, end, step) when it isn't. Old code will > > raise a reasonable exception when a step is specified, while > > step-aware code can specify the step as a default argument value of > > 1 or None. > > Yes, that's very reasonable. I would suggest making the error 'special', > in this case, though. So that you don't get a TypeError about incorrect > number of arguments, but rather a 'object does not support extended slices' > or some such TypeError. Yes. > Actually, it might be worth doing it like this: > > Try to call __getslice__ with unconverted start, stop and step > If it fails with a TypeError, and step is not None, raise the above error > Else, convert start and stop to ints like the current normal slice > behaviour, and try __getslice__ the old way. No, trying to call something and retrying if it fails is a bad idea: the code might fail for a very different reason, and retrying it might mask the bug, or execute a side effect twice... There's no reason why we can't check whether the step is None; it's already impossible to find out whether a particular slice was "lo:hi:None" or "lo:hi:" (once extended slice mode is used). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From nascheme at enme.ucalgary.ca Thu Jul 27 15:50:58 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 27 Jul 2000 07:50:58 -0600 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: ; from Tim Peters on Thu, Jul 27, 2000 at 01:17:03AM -0400 References: <14719.49496.935765.730596@anthem.concentric.net> Message-ID: <20000727075058.A25450@keymaster.enme.ucalgary.ca> On Thu, Jul 27, 2000 at 01:17:03AM -0400, Tim Peters wrote: > If there exists a platform on which it fails but it doesn't fail every time > on that platform, that would be strong evidence of a timing hole. Those > usually require thought to identify and repair. I'll voluteer to > eyeball the code and do some thinking, but not unless the symptoms suggest > that's worthwhile. > > ignorantly y'rs - tim Here is some code that seems to hang on Linux UP machines. Sometimes it prints PIDS for a while and other times it stops after only a few. I don't know if that counts. I raised this issue over a month ago. Tim, your getting forgetful. :) Neil import threading import os, sys class MyThread(threading.Thread): def start(self): threading.Thread.start(self) def run(self): while 1: if os.fork() == 0: print os.getpid() os._exit(0) os.wait() MyThread().start() MyThread().start() MyThread().start() From billtut at microsoft.com Thu Jul 27 15:55:59 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 06:55:59 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33A@RED-MSG-50> Fredrik wrote: > since we don't really support surrogates (or anything else > related to 32-bit unicode) anywhere else, I'd rather change > CPython to emulate JPython here. That's not entirely true. UTF-8 encoding supports surrogates. No reason that we couldn't put the code into a unicode helper function module. If I get a chance to finish my port of the simple Unicode compression thing that'll support surrogates as well. We're eventually going to need one of these anyway for additional Unicode related algorithms. Collation, etc... Bill From effbot at telia.com Thu Jul 27 16:05:25 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 16:05:25 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> <200007271341.IAA09455@cj20424-a.reston1.va.home.com> Message-ID: <006901bff7d3$c06d1e40$f2a6b5d4@hagrid> > [me] > > To summarize, here's the "character encoding guidelines" for > > Python 2.0: > > > > In Unicode context, 8-bit strings contain ASCII. Characters > > in the 0x80-0xFF range are invalid. 16-bit strings contain > > UCS-2. Characters in the 0xD800-0xDFFF range are invalid. > > > > If you want to use any other encoding, use the codecs pro- > > vided by the Unicode subsystem. If you need to use Unicode > > characters that cannot be represented as UCS-2, you cannot > > use Python 2.0's Unicode subsystem. > > > > Anything else is just a hack. [guido] > I wouldn't go so far as raising an exception when a comparison > involves 0xD800-0xDFFF; after all we don't raise an exception when an > ASCII string contains 0x80-0xFF either (except when converting to > Unicode). that's what the "unicode context" qualifier means: 8-bit strings can contain anything, unless you're using them as unicode strings. > The invalidity of 0xD800-0xDFFF means that these aren't valid Unicode > code points; it doesn't mean that we should trap all attempts to use > these values. That ways, apps that need UTF-16 awareness can code it > themselves. > > Why? Because I don't want to proliferate code that explicitly traps > 0xD800-0xDFFF throughout the code. you only need to check "on the way in", and leave it to the decoders to make sure they generate UCS-2 only. the original unicode implementation did just that, but Bill and Marc-Andre recently lowered the shields: the UTF-8 decoder now generates UTF-16 encoded data. (so does \N{}, but that's a non-issue: (oddly enough, the UTF-16 decoder won't accept anything that isn't UCS-2 ;-) my proposal is to tighten this up in 2.0: ifdef out the UTF-16 code in the UTF-8 decoder, and ifdef out the UTF-16 stuff in the compare function. let's wait until 2.1 before we support the full unicode character set (and I'm pretty sure "the right way" is UCS-4 storage and a unified string implementation, but let's discuss that later). patch coming. From jeremy at beopen.com Thu Jul 27 16:06:17 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 27 Jul 2000 10:06:17 -0400 (EDT) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: References: Message-ID: <14720.16857.900370.320050@bitdiddle.concentric.net> >>>>> "PF" == Peter Funk writes: PF> Hi all, This rant is about automatically reclaimed resources PF> like file descriptors. PF> First let me cite a few sentences from the ancient book PF> "Programming Python" written by Mark Lutz (p.122). Since this PF> was the very first available book on Python, it could be PF> considered as some kind of Python Programmers Guide. Feel free to think of it as a guide, but don't think of it as a specification! (It is, as you mention, fairly old.) The only official word on reclaiming externel resource is the Python Language Reference -- http://www.python.org/doc/current/ref/. >Some objects contain references to "external" resources such as open >files or windows. It is understood that these resources are freed when >the object is garbage-collected, but since garbage collection is not >guaranteed to happen, such objects also provide an explicit way to >release the external resource, usually a close() method. Programs are >strongly recommended to explicitly close such objects. The >`try...finally' statement provides a convenient way to do this. If this isn't clear enough, we could revise it for the next release of the documentation. As Guido said, the code is broken, not JPython. Jeremy From effbot at telia.com Thu Jul 27 16:10:09 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 16:10:09 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> <200007271341.IAA09455@cj20424-a.reston1.va.home.com> <006901bff7d3$c06d1e40$f2a6b5d4@hagrid> Message-ID: <007601bff7d4$60a644e0$f2a6b5d4@hagrid> I wrote: > now generates UTF-16 encoded data. (so does \N{}, but > that's a non-issue: ...because all characters in the current name database have 16-bit codes. From Vladimir.Marangozov at inrialpes.fr Thu Jul 27 15:52:40 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 27 Jul 2000 15:52:40 +0200 (CEST) Subject: [Python-Dev] was Re: Type inference now simplicity (fwd) In-Reply-To: from "Moshe Zadka" at Jul 27, 2000 08:06:00 AM Message-ID: <200007271352.PAA02626@python.inrialpes.fr> Moshe Zadka wrote: > > [c.l.py posting deleted] > > [Moshe, concluding] > > Adding new operators and new syntax will make Python harder to read, and > harder to learn. I don't want that. > To some extent, I share these feelings. But only to some extent, because in my eyes it's all a matter of priority. I'll try to elaborate quickly. Before going into extending Python with features, it's more important to make the current implementation rock solid, a.k.a "commercial quality". Presently, this is not really the case and there are already long-standing known issues that nobody gets excited about. Solving these issues is of paramount importance for the acceptance of Python in .com software and generally speaking, its proliferation. For instance: 1. It is unacceptable that Python blows when a generated code object happens to be greater than 2 bytes. If this doesn't get fixed in the VM, the compiler should at least check for this overflow and refuse to emit the bytecode stream. 2. It is unacceptable that Python leaks memory or happens to core dump, without having optional emergency procedures. In this regard, I highly value robust (commercial) software which, for example, pops up a window on low-memory conditions inviting me to free more mem by quitting other apps and gives me the choice to abort the current execution or resume it. Python core dumps on several known situations, notably those that involve recursive calls. 3. I consider very-high priority the recently discussed integrated help system. 4. I consider high priority the opportunity to get more performance in terms of system resources: memory & execution speed. And this is why I'm working on it as time permits. I find unacceptable the fact that there are already some potential improvements on the table which have not been considered seriously so far: removal of SET_LINENO, GC + malloc integration, etc. 5. I find unwise the whole process of enriching the core, whithout a global vision on a modular and extensible core architecture. Adding 10 additional opcodes for augmented assignment is considered nuts. The addition of opcodes for extended calls is already a fact, although I never use them and I don't need them. Other enhancements have been proposed and they come on top of the system, making it quite heavy. And I don't use Unicode - so why it isn't optional? Because there's no a truly modular architecture in place. I hope that python-dev will eventually realize that all these issues are more important that augmented assignment, zip(), and other recently discussed enhancements. IMO, the latter are crap compared to the concerns above. and-I'm-not-talking-about-types-or-Py3K'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From billtut at microsoft.com Thu Jul 27 16:18:56 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 07:18:56 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33B@RED-MSG-50> > From: M.-A. Lemburg [mailto:mal at lemburg.com] > Fredrik Lundh wrote: > > > > mal wrote: > > > This really has nothing to do with being able to support > > > surrogates or not (as Fredrik mentioned), it is the correct > > > behaviour provided UTF-16 is used as encoding for UCS-4 values > > > in Unicode literals which is what Python currently does. > > > > Really? I could have sworn that most parts of Python use > > UCS-2, not UTF-16. > The design specifies that Py_UNICODE refers to UTF-16. To make > life easier, the implementation currently assumes UCS-2 in > many parts, but this is should only be considered a > temporary situation. Since supporting UTF-16 poses some > real challenges (being a variable length encoding), full > support for surrogates was postponed to some future > implementation. Heh. Now you're being silly. Supporting UTF-16 isn't that difficult. You always know whether the character is a low surrogate or a high surrogate. The interesting question is whether or not you have your builtin Unicode object expose each 16-bit character as is, or you support iterating over Py_UCS4 characters, or you want to have a wrapping object that does the right thing here. This might be the way to go. > > Built-ins like ord, unichr, len; slicing; > > string methods; regular expressions, etc. all clearly assume > > that a Py_UNICODE is a unicode code point. > > > > My point is that we shouldn't pretend we're supporting > > UTF-16 if we don't do that throughout. > We should keep that design detail in mind though. > > As far as I can tell, cmp() is the *only* unicode function > > that thinks the internal storage is UTF-16. > > > Everything else assumes UCS-2. No, its UTF-16, it just doesn't yet handle surrogates in all of the appropriate places. :) The unicodename stuff also needs to support future named surrogate characters now. > > And for Python 2.0, it's surely easier to fix cmp() than to > > fix everything else. > Also true :-) Everything but the regular expressions would be fairly simple to add UTF-16 support to. I'd imagine that adding support for \u10FFFF in the regular expression syntax wouldn't be that hard either. > > (this is the same problem as 8-bit/unicode comparisions, where > > the current consensus is that it's better to raise an exception > > if it looks like the programmer doesn't know what he was doing, > > rather than pretend it's another encoding). > Perhaps you are right and we should #if 0 the comparison > sections related to UTF-16 for now. I'm not sure why Bill > needed the cmp() function to support surrogates... Bill ? I didn't need it to. I happened upon the code on the IBM website, so I figured I'd point it out and see what people thought of sticking it into the Python Unicode stuff. :) (Wishing Python 2.0 would ship with Unicode collation support) See the earlier comment about creating a wrapping class that handles UTF-16 issues better. > Still, it will have to be reenabled sometime in the > future when full surrogate support is added to Python. Bill From moshez at math.huji.ac.il Thu Jul 27 16:26:04 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 27 Jul 2000 17:26:04 +0300 (IDT) Subject: [Python-Dev] was Re: Type inference now simplicity (fwd) In-Reply-To: <200007271352.PAA02626@python.inrialpes.fr> Message-ID: On Thu, 27 Jul 2000, Vladimir Marangozov wrote: > Before going into extending Python with features, it's more important > to make the current implementation rock solid, a.k.a "commercial quality". > Presently, this is not really the case and there are already long-standing > known issues that nobody gets excited about. Solving these issues is of > paramount importance for the acceptance of Python in .com software and > generally speaking, its proliferation. I agree. > For instance: > > 1. It is unacceptable that Python blows when a generated code object > happens to be greater than 2 bytes. If this doesn't get fixed in > the VM, the compiler should at least check for this overflow and > refuse to emit the bytecode stream. Can you elaborate on that? At least the numeric typo error makes this a guessing job > 2. It is unacceptable that Python leaks memory or happens to core dump, > without having optional emergency procedures. In this regard, I highly > value robust (commercial) software which, for example, pops up a window > on low-memory conditions inviting me to free more mem by quitting other > apps and gives me the choice to abort the current execution or resume it. Personally, I don't. If there is no memory, Python should quit gracefully (throwing MemoryError exception is fine by me -- core dumping is not) > Python core dumps on several known situations, notably those that > involve recursive calls. This doesn't have to do with low-memory conditions, this is because Python uses the C stack. Finally putting in stackless will make this the same as low-memory conditions, and we already covered that 3. I consider very-high priority the recently discussed integrated help > system. I don't. It's in the "useful, but not necessary". What *is* necessary is a good IDE, with integrated help. IDLE is being worked on, as is ActiveState's Komodo and my Bwian vapourware. > 4. I consider high priority the opportunity to get more performance in > terms of system resources: memory & execution speed. And this is why > I'm working on it as time permits. I find unacceptable the fact that > there are already some potential improvements on the table which have > not been considered seriously so far: removal of SET_LINENO, GC + malloc > integration, etc. I totally agree -- and even more so. I hope to have the time to work on serious Python optimization, notable things like method caching, optimizing built-in function calls, etc. > 5. I find unwise the whole process of enriching the core, whithout a > global vision on a modular and extensible core architecture. Adding > 10 additional opcodes for augmented assignment is considered nuts. > The addition of opcodes for extended calls is already a fact, although > I never use them and I don't need them. Other enhancements have been > proposed and they come on top of the system, making it quite heavy. > And I don't use Unicode - so why it isn't optional? Because > there's no a truly modular architecture in place. Ummm.....most of unicode *is* optional: the codec package and various unicode modules are optional. u"" strings have new syntax, which is really needed. > I hope that python-dev will eventually realize that all these issues are > more important that augmented assignment I completely agree. > zip() zip() and friends (irange, product) have been suggested to live in a seperate Python module, hence completely optional. If you're talking about time usage, well, it's not your time -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From effbot at telia.com Thu Jul 27 16:43:34 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 16:43:34 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33B@RED-MSG-50> Message-ID: <009801bff7d9$0e90d580$f2a6b5d4@hagrid> bill wrote: > Heh. Now you're being silly. Supporting UTF-16 isn't that difficult. You > always know whether the character is a low surrogate or a high surrogate. sorry, but you're being silly. using variable-width encoding for interal storage is difficult, slow, and just plain stupid on modern hardware. (image processing people stopped doing stupid things like that ages ago, and trust me -- a typical image contains many more pixels than a typical text ;-) after all, if variable-width internal storage had been easy to deal with, we could have used UTF-8 from the start... (and just like the Tcl folks, we would have ended up rewriting the whole thing in the next release ;-) From billtut at microsoft.com Thu Jul 27 16:24:48 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 07:24:48 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33C@RED-MSG-50> -----Original Message----- > From: Guido van Rossum [mailto:guido at beopen.com] > The invalidity of 0xD800-0xDFFF means that these aren't valid Unicode > code points; it doesn't mean that we should trap all attempts to use > these values. That ways, apps that need UTF-16 awareness can code it > themselves. 0xD800-0xDFFF are valid code points. They just aren't characters that you normally want to render all on their own. :) > Why? Because I don't want to proliferate code that explicitly traps > 0xD800-0xDFFF throughout the code. Err... I don't think you have much choice in the long term. Its not like the code is all that difficult, and certain cases might be able to use helper functions to help centralize that particular part of code. Bill From effbot at telia.com Thu Jul 27 16:50:53 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 16:50:53 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33B@RED-MSG-50> <009801bff7d9$0e90d580$f2a6b5d4@hagrid> Message-ID: <00a601bff7da$12aca9e0$f2a6b5d4@hagrid> I wrote: > (image processing people stopped doing stupid things like that > ages ago, and trust me -- a typical image contains many more > pixels than a typical text ;-) ...contains characters. sorry folks, my thinkahead fifo buffer appears to be broken today. time for a reboot. From billtut at microsoft.com Thu Jul 27 16:43:44 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 07:43:44 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33D@RED-MSG-50> Fredik wrote: > the original unicode implementation did just that, but Bill and > Marc-Andre recently lowered the shields: the UTF-8 decoder > now generates UTF-16 encoded data. (so does \N{}, but > that's a non-issue:=20 > my proposal is to tighten this up in 2.0: ifdef out the UTF-16 > code in the UTF-8 decoder, and ifdef out the UTF-16 stuff in > the compare function. Commenting the UTF-16 stuff out in the compare function is a valid point, given our current Unicode string object. I disagree strongly with disabling the surrogate support in UTF-8, and we should fix the UTF-16 decoder. Since the decoder/encoder support doesn't hurt any other piece of code by emitting surrogate pairs, I don't see why you want to disable the code. > (oddly enough, the UTF-16 decoder won't accept anything > that isn't UCS-2 ;-) Well that's an easy bug to fix. > let's wait until 2.1 before we support the full unicode character > set (and I'm pretty sure "the right way" is UCS-4 storage and a > unified string implementation, but let's discuss that later). I've mentioned this before, but why discuss this later? Indeed why would we want to fix it for 2.1? Esp. if we move to UCS-4 storage in a minor release. Why not just get the Unicode support correct this time around. Save the poor users of the Python Unicode support from going nuts when we make these additional confusing changes later. If you think you want to move to UCS-4 later, don't wait, do it know. Add support for special surrogate handling later if we must, but please oh please don't change the storage mechanism in memory in a later relase. Java and Win32 are all UTF-16 based, and those extra 16-bits are actually wasted for nearly every common Unicode data you'd hope to handle. I think using UTF-16 as an internal storage mechanism actually makes sense. Whether or not you want to have your character type expose an array of 16-bit values, or the appearance of an array of UCS-4 characters is a separate issue. An issue I think should be answered now, instead of fixing it later. Bill From billtut at microsoft.com Thu Jul 27 16:49:06 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 07:49:06 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33E@RED-MSG-50> Fredrik: > sorry, but you're being silly. using variable-width encoding for > interal storage is difficult, slow, and just plain stupid on modern > hardware. So use UCS-4 internal storage now. UTF-16 just seems like a handy internal storage mechanism to pick since Win32 and Java use it for their native string processing. > (image processing people stopped doing stupid things like that > ages ago, and trust me -- a typical image contains many more > pixels than a typical text ;-) > after all, if variable-width internal storage had been easy to deal > with, we could have used UTF-8 from the start... (and just like > the Tcl folks, we would have ended up rewriting the whole thing > in the next release ;-) Oh please, UTF-16 is substantially simpler to deal with than UTF-8. I would go nuts if our internal storage mechanism was UTF-8. Bill From Vladimir.Marangozov at inrialpes.fr Thu Jul 27 17:03:51 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 27 Jul 2000 17:03:51 +0200 (CEST) Subject: [Python-Dev] was Re: Type inference now simplicity (fwd) In-Reply-To: from "Moshe Zadka" at Jul 27, 2000 05:26:04 PM Message-ID: <200007271503.RAA02899@python.inrialpes.fr> Moshe Zadka wrote: > > > For instance: > > > > 1. It is unacceptable that Python blows when a generated code object > > happens to be greater than 2 bytes. If this doesn't get fixed in > > the VM, the compiler should at least check for this overflow and > > refuse to emit the bytecode stream. > > Can you elaborate on that? At least the numeric typo error makes this > a guessing job I won't :-) Of course I meant the case where the size doesn't fit in 2 bytes, i.e. > 32k > > Python core dumps on several known situations, notably those that > > involve recursive calls. > > This doesn't have to do with low-memory conditions, this is because Python > uses the C stack. I know, it has been discussed to death. So what? Live with it (the C stack) and fix the code, as it has been done for recursive comparisons and marshal. The point of my mail isn't in the details, though... As you might guess, I haven't been exhaustive regarding the current state of the (C) implementation. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From effbot at telia.com Thu Jul 27 17:35:27 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 17:35:27 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33E@RED-MSG-50> Message-ID: <00cb01bff7e0$79e74d80$f2a6b5d4@hagrid> bill wrote: > So use UCS-4 internal storage now. UTF-16 just seems like a handy internal > storage mechanism to pick since Win32 and Java use it for their native > string processing. umm. the Java docs I have access to doesn't mention surrogates at all (they do point out that a character is 16-bit, and they don't provide an \U escape). on the other hand, MSDN says: Windows 2000 provides support for basic input, output, and simple sorting of surrogates. However, not all Windows 2000 system components are surrogate compatible. Also, surrogates are not supported in Windows 95/98 or in Windows NT 4.0. and then mentions all the usual problems with variable-width encodings... > > after all, if variable-width internal storage had been easy to deal > > with, we could have used UTF-8 from the start... (and just like > > the Tcl folks, we would have ended up rewriting the whole thing > > in the next release ;-) > > Oh please, UTF-16 is substantially simpler to deal with than UTF-8. in what way? as in "one or two words" is simpler than "one, two, three, four, five, or six bytes"? or as in "nobody will notice anyway..." ;-) ::: if UCS-2/BMP was good enough for NT 4.0, Unicode 1.1, and Java 1.0, it's surely good enough for Python 2.0 ;-) (and if I understand things correctly, 2.1 isn't that far away...) From effbot at telia.com Thu Jul 27 17:53:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 17:53:45 +0200 Subject: [Python-Dev] more unicode: \U support? Message-ID: <012f01bff7e2$e0443820$f2a6b5d4@hagrid> would it be a good idea to add \UXXXXXXXX (8 hex digits) to 2.0? (only characters in the 0000-ffff range would be accepted in the current version, of course). From thomas at xs4all.net Thu Jul 27 17:48:03 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 17:48:03 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271422.JAA13096@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 09:22:48AM -0500 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> Message-ID: <20000727174803.U266@xs4all.nl> On Thu, Jul 27, 2000 at 09:22:48AM -0500, Guido van Rossum wrote: [about INPLACE_ADD/SUBTRACT/ETC] > There's no need for them to be consecutive! (The BINARY_* family > isn't even consecutive!) I say, just some open ranges, like 54-59 and > 73-79. [and about ROT_ANY] > No, let's not overgeneralize. Roger dodger, wilco dilco, milli vanilli. > > Try to call __getslice__ with unconverted start, stop and step > > If it fails with a TypeError, and step is not None, raise the above error > > Else, convert start and stop to ints like the current normal slice > > behaviour, and try __getslice__ the old way. > > No, trying to call something and retrying if it fails is a bad idea: > the code might fail for a very different reason, and retrying it might > mask the bug, or execute a side effect twice... Yeah, I realized that too, while listening one of my colleagues trying to make some point or other. Hrm... So backwards compatibility is out ? I'm not sure howmany Python code uses slice-objects, but I would consider it a (personal ;) failure if slicing has to be *broken* before it can be fixed. If we can't figure out whether a function supports the 'new syntax' reliably, I don't see how we can transform the error message either. I'll bet inspecting the __getitem__ method to find out whether it supports the one or the other is way too much of a runtime penalty to suffer at each index. So the only workable way to support all combinations of __getitem__ and __getslice__ is by adding a new builtin, __getitems__ ? (too confusing a name... __getanything__ ? :P) Feeble-(after-all-those-meetings)-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Thu Jul 27 19:03:39 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 12:03:39 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 17:48:03 +0200." <20000727174803.U266@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> Message-ID: <200007271703.MAA00802@cj20424-a.reston1.va.home.com> > > No, trying to call something and retrying if it fails is a bad idea: > > the code might fail for a very different reason, and retrying it might > > mask the bug, or execute a side effect twice... > > Yeah, I realized that too, while listening one of my colleagues trying to > make some point or other. Hrm... So backwards compatibility is out ? I'm not > sure howmany Python code uses slice-objects, but I would consider it a > (personal ;) failure if slicing has to be *broken* before it can be fixed. Huh? I thought I proposed a b/w compat solution: IF there is a __getslice__ method: IF the slice step is None: call __getslice__(lo, hi) ELSE: # the slice step is not None call __getslice__(lo, hi, step) What's wrong with that? > If we can't figure out whether a function supports the 'new syntax' > reliably, I don't see how we can transform the error message either. I'll > bet inspecting the __getitem__ method to find out whether it supports the > one or the other is way too much of a runtime penalty to suffer at each > index. No, we don't deal with __getitem__; if *it* doesn't support a tuple containing slice objects, tough luck. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From skip at mojam.com Thu Jul 27 18:03:29 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 27 Jul 2000 11:03:29 -0500 (CDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <398032BF.1F9A09ED@lemburg.com> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> <200007271309.IAA06750@cj20424-a.reston1.va.home.com> <398032BF.1F9A09ED@lemburg.com> Message-ID: <14720.23889.451562.474003@beluga.mojam.com> >> Another important reason is that in cases like >> >> a[long_and_expensive_call()] = a[long_and_expensive_call()] + 1 M-A> Dito for this one: M-A> i = long_and_expensive_call() M-A> a[i] = a[i] + 1 Only if you know that long_and_expensive_call() has no side effects! Skip From mal at lemburg.com Thu Jul 27 18:09:05 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 18:09:05 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <200007270611.BAA04802@cj20424-a.reston1.va.home.com> <397FECA9.56BB1C50@lemburg.com> <200007271309.IAA06750@cj20424-a.reston1.va.home.com> <398032BF.1F9A09ED@lemburg.com> <14720.23889.451562.474003@beluga.mojam.com> Message-ID: <39805EA1.9DA9BEF@lemburg.com> Skip Montanaro wrote: > > > >> Another important reason is that in cases like > >> > >> a[long_and_expensive_call()] = a[long_and_expensive_call()] + 1 > > M-A> Dito for this one: > > M-A> i = long_and_expensive_call() > M-A> a[i] = a[i] + 1 > > Only if you know that long_and_expensive_call() has no side effects! If it does, then you'll have to write the long version anyway, if it doesn't I don't see a problem, if you don't know then you shouldn't use the function anyway ;-)) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Thu Jul 27 18:13:16 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 18:13:16 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271703.MAA00802@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 12:03:39PM -0500 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> Message-ID: <20000727181315.B224@xs4all.nl> On Thu, Jul 27, 2000 at 12:03:39PM -0500, Guido van Rossum wrote: > > So backwards compatibility is out ? I'm not sure howmany Python code > > uses slice-objects, but I would consider it a (personal ;) failure if > > slicing has to be *broken* before it can be fixed. > Huh? I thought I proposed a b/w compat solution: > IF there is a __getslice__ method: > IF the slice step is None: > call __getslice__(lo, hi) > ELSE: # the slice step is not None > call __getslice__(lo, hi, step) > What's wrong with that? Well, what happens if __getslice__ and __getitem__ both exist, and __getitem__ is used to handle extended slices, but __getslice__ isn't (yet)? Currently, if it's a single item, __getitem__ is called. If it's a basic slice, __getslice__ is called. If it's an extended slice, __getitem__ is called. In the above picture, __getslice__ would be called instead, with the 'wrong' number of arguments, and the use of extended slices would break. > > If we can't figure out whether a function supports the 'new syntax' > > reliably, I don't see how we can transform the error message either. I'll > > bet inspecting the __getitem__ method to find out whether it supports the > > one or the other is way too much of a runtime penalty to suffer at each > > index. > No, we don't deal with __getitem__; if *it* doesn't support a tuple > containing slice objects, tough luck. Sorry, that was my feebleness popping up. I was talking about __getslice__. How do we find out if __getslice__ accepts 4 arguments, rather than 3 ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Thu Jul 27 18:22:48 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 18:22:48 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <20000727181315.B224@xs4all.nl>; from thomas@xs4all.net on Thu, Jul 27, 2000 at 06:13:16PM +0200 References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> Message-ID: <20000727182248.V266@xs4all.nl> On Thu, Jul 27, 2000 at 06:13:16PM +0200, Thomas Wouters wrote: > Sorry, that was my feebleness popping up. I was talking about __getslice__. > How do we find out if __getslice__ accepts 4 arguments, rather than 3 ? Actually, it wasn't the feebleness as much as the two different things you seem to be wanting, Guido ;) Previously (in another thread, and perhaps in the start of this thread as well) you argued that an index should always call __getitem__, with a slice object if it's a slice of some kind, *even a basic one*. So that we lose __getslice__ and rather teach people to use __getslice__. So now you want to *extend* the 'special case' to extended, 3-argument slices, but *not* Ellipses and tupled-slices (which aren't really tuples, because you can do (1, 2:5, ...)) -- or am I reading this wrong ? :) Don't worry, Guido, it isn't just you, I failed to grasp what those managers were trying to tell me today, too... I may just be too dense, today. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Thu Jul 27 19:25:44 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 12:25:44 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 18:13:16 +0200." <20000727181315.B224@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> Message-ID: <200007271725.MAA17990@cj20424-a.reston1.va.home.com> > > IF there is a __getslice__ method: > > IF the slice step is None: > > call __getslice__(lo, hi) > > ELSE: # the slice step is not None > > call __getslice__(lo, hi, step) > > > What's wrong with that? > > Well, what happens if __getslice__ and __getitem__ both exist, and > __getitem__ is used to handle extended slices, but __getslice__ isn't (yet)? > Currently, if it's a single item, __getitem__ is called. If it's a basic > slice, __getslice__ is called. If it's an extended slice, __getitem__ is > called. > > In the above picture, __getslice__ would be called instead, with the 'wrong' > number of arguments, and the use of extended slices would break. Good point. Sigh. I suppose we could inspect the __getslice__ method's argument count (it *is* available somewher) but that seems a hack (and could still break if default arguments were used for something else). Another solution: require a class variable to indicate the class's awareness: e.g. you must define __getslice_takes_three_args__ when __getslice__(lo, hi, step) is supported, otherwise the call goes to __getitem__(slice(lo, hi, step)). This is a bit like the feature flag bits in the type struct. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Thu Jul 27 19:30:51 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 12:30:51 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 18:22:48 +0200." <20000727182248.V266@xs4all.nl> References: <20000725230322.N266@xs4all.nl> <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> <20000727182248.V266@xs4all.nl> Message-ID: <200007271730.MAA21788@cj20424-a.reston1.va.home.com> > Actually, it wasn't the feebleness as much as the two different things you > seem to be wanting, Guido ;) Previously (in another thread, and perhaps in > the start of this thread as well) you argued that an index should always > call __getitem__, with a slice object if it's a slice of some kind, *even a > basic one*. So that we lose __getslice__ and rather teach people to use > __getslice__. That would be nice, but it would be b/w incompatible, so now we're trying (again) to figure out how to still support __getslice__. My proposal is to try and be b/w compatible if __getslice__ exists. See my previous mail. > So now you want to *extend* the 'special case' to extended, 3-argument > slices, but *not* Ellipses and tupled-slices (which aren't really tuples, > because you can do (1, 2:5, ...)) -- or am I reading this wrong ? :) Not sure what you mean by that. (1, 2:5, ...) by itself is illegal syntax; the special slice syntax can only occur directly in an indexing context, e.g. a[1, 2:5, ...]. > Don't worry, Guido, it isn't just you, I failed to grasp what those managers > were trying to tell me today, too... I may just be too dense, today. I hope they weren't telling you to stop working on Python! You seem made for this work... --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From tim_one at email.msn.com Thu Jul 27 18:59:04 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 12:59:04 -0400 Subject: Refcount vs GC semantics (was RE: [Python-Dev] Product iteration) In-Reply-To: Message-ID: Plea: could we try to get an accurate subject line on at least 1 msg in 10? Thanks. [Moshe] > I know, and I'm not. But the thing is, there are plenty of users of > CPython which do rely on this feature -- so you're going to break > people's code. Not nice. [Mark Hammond] > No - we will simply be pointing out their already broken code. We > arent breaking anything! > > I have no problem with this at all. The sooner we point out the > broken code the better. The last thing we want is for obviously and > documented broken code to suddenly be considered non-broken simply by > the volume of poor code out there... Spoken like a man who has never maintained a language implementation used by hordes of unhappy users <0.5 wink>. The bitching about "breaking" .append(1,2,3) was nothing compared to what this would stir up, and when the first "important" customer seriously threatens to walk, vendors usually back down out of a healthy sense of self-preservation. Been there so many times it even makes me want to puke . > Either way, I think you are overstating the problem. I agree with that too. I don't think CPython could get away with this, but you have a new implementation and users will see this as a basis on which they compete. The *convenience* of CPython's (accidental but real!) semantics here is undeniable. Still, I don't see it coming up much except wrt temp files, and if that becomes An Issue for you, you can always special-case the snot out of them. users-don't-read-manuals-but-they-do-pay-the-bills-ly y'rs - tim From ping at lfw.org Thu Jul 27 19:10:51 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 27 Jul 2000 10:10:51 -0700 (PDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 27 Jul 2000, Guido van Rossum wrote: > Second, what should happen to a slice assignment? My vote is: nothing! (Read on.) > The basic slice form is: > > a[i:j] += b What does this mean? I don't see how it could be any different from: a[j:j] = b If people want to insert sequences into other sequences, they should use this form; if they want to insert an element into a sequence, they should be encouraged to use an .insert() method. In other words, we already have perfectly good ways of doing this (more importantly, there are already clear and simple ways to implement such behaviour in your own objects). > a[:, ..., ::, 0:10:2, :10:, 1, 2:, ::-1] += 1 What on earth could this mean? And why would anyone want it? I can't even imagine what the simpler case a[i:j:k] += 1 would do... unless you wish to propose element-wise operators (e.g. add 1 to each of the elements that would participate in the slice) and i think that might be a whole new can of worms. It wasn't clear to me that this was your intent, though. It looks to me like going through various contortions to support augmented assignment to slices is not going to be worth the trouble. May i suggest >>> a[i:j] += b SyntaxError: augmented assignment to a slice is not allowed just like >>> (a, b, c) += 1,2,3 SyntaxError: augmented assignment to a tuple is not allowed ? -- ?!ng From effbot at telia.com Thu Jul 27 19:20:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 19:20:05 +0200 Subject: [Python-Dev] [ Patch #100990 ] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <002101bff7b3$38232fe0$f2a6b5d4@hagrid> <200007271341.IAA09455@cj20424-a.reston1.va.home.com> <006901bff7d3$c06d1e40$f2a6b5d4@hagrid> Message-ID: <017901bff7ee$eadb9740$f2a6b5d4@hagrid> > my proposal is to tighten this up in 2.0: ifdef out the UTF-16 > code in the UTF-8 decoder, and ifdef out the UTF-16 stuff in > the compare function. > patch coming. http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100990&group_id=5470 From ping at lfw.org Thu Jul 27 19:25:38 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 27 Jul 2000 10:25:38 -0700 (PDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271725.MAA17990@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 27 Jul 2000, Guido van Rossum wrote: > I suppose we could inspect the __getslice__ method's argument count > (it *is* available somewher) but that seems a hack (and could still > break if default arguments were used for something else). Yuck! > Another solution: require a class variable to indicate the class's > awareness: e.g. you must define __getslice_takes_three_args__ when > __getslice__(lo, hi, step) is supported, otherwise the call goes to > __getitem__(slice(lo, hi, step)). Here's another solution: if you're going to revamp the whole item/slice-getting interface, which is what this pretty much amounts to, use a separate interface. Old interface: __getitem__(index) # I get an ITEM. __getitem__(slice-object) # I get a SLICE or an ITEM. (!) __getslice__(lo, hi, step) # I get a SLICE. New interface: __get__(index) # I get an ITEM. __get__(slice-object) # I get a SLICE or an ITEM. (!) To be honest, the whole collision between slices and items makes me rather uncomfortable. I would prefer to separate them: one method for getting *items*, one method for getting *slices*. Neither of the interfaces above handles this correctly for the case of multidimensional arrays. So, how about: __get__(index, ...) # I want an ITEM. __getslice__(slice-object, ...) # I want a SLICE. I think an interface like this would be much easier to program against. The return value is better defined: __get__ always returns a single item; __getslice__ always returns some kind of collection of items (usually, if not always, the same type as the original collection being sliced). This would require detection of whether any of the components of a multidimensional (i.e. tuple) index were slices, but i think the improved consistency is well worth it. __getslice__ is called if any slices are involved; __get__ is called otherwise. Here are some examples for illustration: a[i] a.__get__(i) a[i, j] a.__get__(i, j) a[i:j] a.__getslice__(slice(i, j)) a[i:j:k] a.__getslice__(slice(i, j, k)) a[i, j, k] a.__get__(i, j, k) a[i, j, k:l] a.__getslice__(i, j, slice(k, l)) I can't imagine ever wanting to define custom behaviour for __getslice__ *without* implementing __get__ or __getitem__, so the presence of a __get__ method can be used to detect whether we should use the new interface. -- ?!ng From tim_one at email.msn.com Thu Jul 27 19:17:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 13:17:22 -0400 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007270611.BAA04802@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > ... > Note that C doesn't guarantee that a++ is atomic either, even if a is > declared volatile. For people who don't know, or may have forgotten, threads are not a part of std C or C++: those languages say nothing whatsoever about behavior in the presence of threads. And this is still true in C99! ANSI/ISO committees work by consensus, and there are so many goofy thread models out there consensus will never be reached (keep that in mind as you ponder how PEPs should proceed <0.6 wink>). > (I believe there's an atomic data type, but I don't think it > guarantees atomic ++. You may be thinking of sig_atomic_t? That relates to a technical meaning for "atomic" in signal handlers, a meaning that has nothing to do with threads. In effect, sig_atomic_t is simply a volatile integral type small enough so that read and write each take one machine instruction (so, e.g., a 64-bit int would not serve as a suitable sig_atomic_t on a 32-bit machine, as it would have to be read and written "in pieces", and an interrupting signal could cause an interrupted read or write to use inconsistent pieces). From ping at lfw.org Thu Jul 27 19:31:56 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Thu, 27 Jul 2000 10:31:56 -0700 (PDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Message-ID: On Thu, 27 Jul 2000, Ka-Ping Yee wrote: > So, how about: > > __get__(index, ...) # I want an ITEM. > __getslice__(slice-object, ...) # I want a SLICE. Addendum: For __set__ and __setslice__, since there may be a variable number of index arguments, it seems the value to set must *precede* the indices. The full interface: __get__(*indices) __set__(value, *indices) __del__(*indices) __getslice__(*slices) __setslice__(value, *slices) __delslice__(*slices) I prefer putting the indices last to passing in a tuple of indices for the following reasons: 1. It would be annoying and slightly slower to have to declare __get__((index,)) instead of __get__(index). 2. I want to encourage prediction of the number of indices. Since most multidimensional types are likely to have a fixed number of dimensions, it's better to have an interface look like, e.g. __get__(x, y, z) # Clearly a 3-dimensional array! instead of __get__(indices) # Don't know how many dimensions. The error is caught earlier, and the expectations of the programmer are more visible. To implement a variable number of dimensions, of course one can always write __get__(*indices) but this would not be the conventional thing to write: it would make clear that there is something special going on here. -- ?!ng From tim_one at email.msn.com Thu Jul 27 19:26:31 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 13:26:31 -0400 Subject: [Python-Dev] test_fork1 on SMP? In-Reply-To: <20000727092144.R266@xs4all.nl> Message-ID: [Thomas Wouters] > ... > And anyway, I thought the test_fork1 test tested for fork() behaviour in > threads. It spawns a thread, Four threads, actually. > fork()s one of those threads, It forks "the main" thread, which is in addition to the four it spawns. > and tests to see if the other threads still exist after the fork(), > in the new child. The entire test is done in Python code, so how > the scheduler and/or race conditions come into play isn't too > obvious to me. Except of course the whole test if flawed. The test uses loops and time.sleep instead of proper synchronization, so its behavior is at best probabilistic, depending entirely on timing accidents (*likely* accidents, but accidents all the same). But I don't have a machine here that supports fork at all, so I can't run it, and I don't know how it fails on the machines it fails on. If it's failing with a thread exiting with a non-zero exit code, then I'd say the timing uncertainties in the *Python* code are irrelevant, and it's the failing platform's fork implementation that's broken. From bckfnn at worldonline.dk Thu Jul 27 20:01:01 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Thu, 27 Jul 2000 18:01:01 GMT Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <397FF146.2D307063@lemburg.com> References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> Message-ID: <398065f3.6724599@smtp.worldonline.dk> [M.-A. Lemburg] >BTW, does Java support UCS-4 ? If not, then Java is wrong >here ;-) Java claims to use unicode 2.1 [*]. I couldn't locate anything describing if this is UCS-2 or UTF-16. I think unicode 2.1 includes UCS-4. The actual level of support for UCS-4 is properly debatable. - The builtin char is 16bit wide and can obviously not support UCS-4. - The Character class can report if a character is a surrogate: >>> from java.lang import Character >>> Character.getType("\ud800") == Character.SURROGATE 1 - As reported, direct string comparison ignore surrogates. - The BreakIterator does not handle surrogates. It does handle combining characters and it seems a natural place to put support for surrogates. - The Collator class offers different levels of normalization before comparing string but does not seem to support surrogates. This class seems a natural place for javasoft to put support for surrogates during string comparison. These findings are gleaned from the sources of JDK1.3 [*] http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#25310 regards, finn From tim_one at email.msn.com Thu Jul 27 20:20:26 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 14:20:26 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <20000727075058.A25450@keymaster.enme.ucalgary.ca> Message-ID: [Neil Schemenauer] > Here is some code that seems to hang on Linux UP machines. > Sometimes it prints PIDS for a while and other times it stops > after only a few. Well, that sucks! Does "UP" mean uniprocessor in this context? > I don't know if that counts. I raised this issue over a month > ago. Tim, your getting forgetful. :) Getting? I'm very old. I think. But even if I had a memory, I usually ignore Unix-specific posts (i.e., I can't run code with a .fork(), so can only sit back & admire the perversity of those who both can & do ). From billtut at microsoft.com Thu Jul 27 20:23:27 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 11:23:27 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD343@RED-MSG-50> > umm. the Java docs I have access to doesn't mention surrogates > at all (they do point out that a character is 16-bit, and they don't > provide an \U escape). When Java does support surrogates, it seems likely that for backward compatibility reasons that they'll start paying attention to surrogates. Altering to a 32-bit int would break too much of their users code. > on the other hand, MSDN says: > Windows 2000 provides support for basic input, output, and > simple sorting of surrogates. However, not all Windows 2000 > system components are surrogate compatible. Also, surrogates > are not supported in Windows 95/98 or in Windows NT 4.0. > and then mentions all the usual problems with variable-width > encodings... Which means it supports UTF-16, and the support can only get better. > > > after all, if variable-width internal storage had been easy to deal > > > with, we could have used UTF-8 from the start... (and just like > > > the Tcl folks, we would have ended up rewriting the whole thing > > > in the next release ;-) > >=20 > > Oh please, UTF-16 is substantially simpler to deal with than UTF-8. > in what way? as in "one or two words" is simpler than "one, two, > three, four, five, or six bytes"? > or as in "nobody will notice anyway..." ;-) As in it's very easy to determine arbitrarily which byte of the surrogate you're dealing with based on its 16-bit value. You can't say that about UTF-8. > if UCS-2/BMP was good enough for NT 4.0, Unicode 1.1, and Java 1.0, > it's surely good enough for Python 2.0 ;-) > > (and if I understand things correctly, 2.1 isn't that far away...) They were, since UTF-16 didn't exist at the time. :) I think we both want Python's unicode support to eventually support surrogate range characters. Let me see if I can reiterate what we're both trying to say. What you're saying: * We might switch to UCS-4 when we support this extra stuff because variable length encodings are annoying. My counter point: Switching to UCS-4 isn't backward compatible. If you want to avoid variable length encoding then start with UCS-4 from the beginning. BUT, keeping in mind that Windows, and Java are either right now, or likely to be UTF-16 systems. What I'm saying: * Just use UTF-16 and be done with it. Windows is using it, and Java if it isn't already is definitely likely to do so. Your counter point: Supporting UTF-16 is complicated, and we don't want to do all of this for Python 2.0. (Especially anything that involves writing a Unicode string object that hides the surrogate as two 16-bit entities) My response: This is true. I've never suggested we do all of the UTF-16 support for Python 2.0. The UTF-16 code point order comparision patch I submitted was just something I noticed online, and submitted the patch more for feedback and comments rather then wanting, or needing the patch to get in. However, that doesn't mean bad things will happen if we allow the UTF-8/16 (en/de)coders handle surrogate characters. The Python code can worry about this variable length encoding on its own. The core should still be able to UTF-8 the unicode string so that it can be pickled however. Did I get what you're saying right, and do you understand what I'm getting at? Bill -----Original Message----- From: Fredrik Lundh [mailto:effbot at telia.com] Sent: Thursday, July 27, 2000 8:35 AM To: Bill Tutt Cc: python-dev at python.org Subject: Re: [Python-Dev] UTF-16 code point comparison This message uses a character set that is not supported by the Internet Service. To view the original message content, open the attached message. If the text doesn't display correctly, save the attachment to disk, and then open it using a viewer that can display the original character set. << File: message.txt >> From billtut at microsoft.com Thu Jul 27 20:29:34 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 11:29:34 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD344@RED-MSG-50> > From: bckfnn at worldonline.dk [mailto:bckfnn at worldonline.dk] > - The BreakIterator does not handle surrogates. It does handle > combining characters and it seems a natural place to put support > for surrogates. > - The Collator class offers different levels of normalization before > comparing string but does not seem to support surrogates. This class > seems a natural place for javasoft to put support for surrogates > during string comparison. Both of these aren't surprising given that there aren't any officially allocated characters in surrogate land (but they're coming fast), and the most likely first allocations are to the combined CJK glyph space which doesn't really have anything to collate. :) Bill From tim_one at email.msn.com Thu Jul 27 20:36:23 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 14:36:23 -0400 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD33C@RED-MSG-50> Message-ID: [Guido] >> Why? Because I don't want to proliferate code that explicitly traps >> 0xD800-0xDFFF throughout the code. [Bill Tutt] > Err... I don't think you have much choice in the long term. When the Unicode push started, it was agreed that we would ignore surrogates "for now". I sounded a caution then that I will repeat: the Unicode folks made a bad engineering decision, based on the (Eurocentric) assumption that 64K was a large enough space to meet their stated goals. Don't know how long it will take this half of the world to realize it, but UCS-4 is inevitable. From tim_one at email.msn.com Thu Jul 27 20:41:15 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 14:41:15 -0400 Subject: [Python-Dev] more unicode: \U support? In-Reply-To: <012f01bff7e2$e0443820$f2a6b5d4@hagrid> Message-ID: [/F] > would it be a good idea to add \UXXXXXXXX > (8 hex digits) to 2.0? > > (only characters in the 0000-ffff range would > be accepted in the current version, of course). In which case there seems darned little point to it now . From guido at beopen.com Thu Jul 27 21:44:42 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 14:44:42 -0500 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: Your message of "Thu, 27 Jul 2000 14:36:23 -0400." References: Message-ID: <200007271944.OAA29768@cj20424-a.reston1.va.home.com> > When the Unicode push started, it was agreed that we would ignore surrogates > "for now". I sounded a caution then that I will repeat: the Unicode folks > made a bad engineering decision, based on the (Eurocentric) assumption that > 64K was a large enough space to meet their stated goals. Don't know how > long it will take this half of the world to realize it, but UCS-4 is > inevitable. If we can put it off long enough until RAM and disk space have become twice as cheap, I'm happy. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From billtut at microsoft.com Thu Jul 27 20:52:04 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 11:52:04 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD345@RED-MSG-50> > From: Tim Peters [mailto:tim_one at email.msn.com] > When the Unicode push started, it was agreed that we would ignore surrogates > "for now". I sounded a caution then that I will repeat: the Unicode folks > made a bad engineering decision, based on the (Eurocentric) assumption that > 64K was a large enough space to meet their stated goals. Don't know how > long it will take this half of the world to realize it, but UCS-4 is > inevitable. On new systems perhaps, but important existing systems (Win32, and probably Java) are stuck with that bad decision and have to use UTF-16 for backward compatability purposes. Surrogates aren't as far out as you might think. (The next rev of the Unicode spec) That's certainly sooner than Win32 going away. :) Bill From effbot at telia.com Thu Jul 27 21:04:36 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 21:04:36 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0160.txt,1.3,1.4 References: <200007271846.LAA27298@slayer.i.sourceforge.net> Message-ID: <021d01bff7fd$8258afa0$f2a6b5d4@hagrid> fred wrote: > Remove the ugly form-feed characters some people use with Emacs. note that those "ugly" form-feeds become nice
and

in the HTML versions... From effbot at telia.com Thu Jul 27 21:05:01 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 27 Jul 2000 21:05:01 +0200 Subject: [Python-Dev] more unicode: \U support? References: Message-ID: <021e01bff7fd$93c34de0$f2a6b5d4@hagrid> tim wrote: > [/F] > > would it be a good idea to add \UXXXXXXXX > > (8 hex digits) to 2.0? > > > > (only characters in the 0000-ffff range would > > be accepted in the current version, of course). > > In which case there seems darned little point to it now . with Python's approach to escape codes, it's not exactly easy to *add* a new escape code -- you risk breaking code that for some reason (intentional or not) relies on u"\U12345678" to end up as a backslash followed by 9 characters... not very likely, but I've seen stranger things... (btw, can you walk over to Guido's office and tell him why \x should ignore anything but the last two hex digits, no matter what string type we're using...) From bwarsaw at beopen.com Thu Jul 27 21:24:38 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 27 Jul 2000 15:24:38 -0400 (EDT) Subject: [Python-Dev] PEP 201, zip() builtin Message-ID: <14720.35958.632383.574511@anthem.concentric.net> Folks, Here is the latest PEP 201, updated based on conversations with Guido yesterday. Notice that there are no more Open Issues. See instead the BDFL Pronouncements section. Plan on seeing a C-based implementation checked into the CVS devel tree soon. If you want to comment on this PEP, you must include "PEP 201" in the Subject: header. Enjoy, -Barry -------------------- snip snip -------------------- PEP: 201 Title: Parallel Iteration Version: $Revision: 1.10 $ Author: bwarsaw at beopen.com (Barry A. Warsaw) Python-Version: 2.0 Status: Draft Created: 13-Jul-2000 Post-History: 27-Jul-2000 Introduction This PEP describes the `parallel iteration' proposal for Python 2.0, previously known as `parallel for loops'. This PEP tracks the status and ownership of this feature, slated for introduction in Python 2.0. It contains a description of the feature and outlines changes necessary to support the feature. This PEP summarizes discussions held in mailing list forums, and provides URLs for further information, where appropriate. The CVS revision history of this file contains the definitive historical record. Motivation Standard for-loops in Python iterate over every element in a sequence until the sequence is exhausted[1]. However, for-loops iterate over only a single sequence, and it is often desirable to loop over more than one sequence, in a lock-step, "Chinese Menu" type of way. The common idioms used to accomplish this are unintuitive and inflexible. This PEP proposes a standard way of performing such iterations by introducing a new builtin function called `zip'. Parallel For-Loops Parallel for-loops are non-nested iterations over two or more sequences, such that at each pass through the loop, one element from each sequence is taken to compose the target. This behavior can already be accomplished in Python through the use of the map() built-in function: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> for i in map(None, a, b): print i ... (1, 4) (2, 5) (3, 6) >>> map(None, a, b) [(1, 4), (2, 5), (3, 6)] The for-loop simply iterates over this list as normal. While the map() idiom is a common one in Python, it has several disadvantages: - It is non-obvious to programmers without a functional programming background. - The use of the magic `None' first argument is non-obvious. - It has arbitrary, often unintended, and inflexible semantics when the lists are not of the same length: the shorter sequences are padded with `None'. >>> c = (4, 5, 6, 7) >>> map(None, a, c) [(1, 4), (2, 5), (3, 6), (None, 7)] For these reasons, several proposals were floated in the Python 2.0 beta time frame for providing a better spelling of parallel for-loops. The initial proposals centered around syntactic changes to the for statement, but conflicts and problems with the syntax were unresolvable, especially when parallel for-loops were combined with another proposed feature called `list comprehensions' (see pep-0202.txt). The Proposed Solution The proposed solution is to introduce a new built-in sequence generator function, available in the __builtin__ module. This function is to be called `zip' and has the following signature: zip(seqa, [seqb, [...]]) zip() takes one or more sequences and weaves their elements together, just as map(None, ...) does with sequences of equal length. The weaving stops when the shortest sequence is exhausted. Return Value zip() returns a real Python list, the same way map() does. Examples Here are some examples, based on the reference implementation below. >>> a = (1, 2, 3, 4) >>> b = (5, 6, 7, 8) >>> c = (9, 10, 11) >>> d = (12, 13) >>> zip(a, b) [(1, 5), (2, 6), (3, 7), (4, 8)] >>> zip(a, d) [(1, 12), (2, 13)] >>> zip(a, b, c, d) [(1, 5, 9, 12), (2, 6, 10, 13)] Note that when the sequences are of the same length, zip() is reversible: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> x = zip(a, b) >>> y = zip(*x) # alternatively, apply(zip, x) >>> z = zip(*y) # alternatively, apply(zip, y) >>> x [(1, 4), (2, 5), (3, 6)] >>> y [(1, 2, 3), (4, 5, 6)] >>> z [(1, 4), (2, 5), (3, 6)] >>> x == z 1 It is not possible to reverse zip this way when the sequences are not all the same length. Reference Implementation Here is a reference implementation, in Python of the zip() built-in function. These would ultimately be replaced by equivalent C code. def zip(*args): if not args: raise TypeError('zip() expects one or more sequence arguments') ret = [] # find the length of the shortest sequence shortest = min(*map(len, args)) for i in range(shortest): item = [] for s in args: item.append(s[i]) ret.append(tuple(item)) return ret BDFL Pronouncements Note: the BDFL refers to Guido van Rossum, Python's Benevolent Dictator For Life. - The function's name. An earlier version of this PEP included an open issue listing 20+ proposed alternative names to zip(). In the face of no overwhelmingly better choice, the BDFL strongly prefers zip() due to it's Haskell[2] heritage. See version 1.7 of this PEP for the list of alteratives. - zip() shall be a built-in function. - Optional padding. An earlier version of this PEP proposed an optional `pad' keyword argument, which would be used when the argument sequences were not the same length. This is similar behavior to the map(None, ...) semantics except that the user would be able to specify pad object. This has been rejected by the BDFL in favor of always truncating to the shortest sequence. - Lazy evaluation. An earlier version of this PEP proposed that zip() return a built-in object that performed lazy evaluation using __getitem__() protocol. This has been strongly rejected by the BDFL in favor of returning a real Python list. If lazy evaluation is desired in the future, the BDFL suggests an xzip() function be added. - zip() with no arguments. the BDFL strongly prefers this raise a TypeError exception. - zip() with one argument. the BDFL strongly prefers that this return a list of 1-tuples. - Inner and outer container control. An earlier version of this PEP contains a rather lengthy discussion on a feature that some people wanted, namely the ability to control what the inner and outer container types were (they are tuples and list respectively in this version of the PEP). Given the simplified API and implementation, this elaboration is rejected. For a more detailed analysis, see version 1.7 of this PEP. References [1] http://www.python.org/doc/current/ref/for.html [2] http://www.haskell.org/onlinereport/standard-prelude.html#$vzip TBD: URL to python-dev archives Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: From fdrake at beopen.com Thu Jul 27 21:23:27 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 27 Jul 2000 15:23:27 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0160.txt,1.3,1.4 In-Reply-To: <021d01bff7fd$8258afa0$f2a6b5d4@hagrid> References: <200007271846.LAA27298@slayer.i.sourceforge.net> <021d01bff7fd$8258afa0$f2a6b5d4@hagrid> Message-ID: <14720.35887.525712.225755@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > note that those "ugly" form-feeds become nice
and

> in the HTML versions... They are no longer needed for that. I tossed the
because I thought it was ugly and distracting, but that can be changed if people prefer to have them. The

for headings is there. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nascheme at enme.ucalgary.ca Thu Jul 27 21:23:22 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 27 Jul 2000 13:23:22 -0600 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: ; from Tim Peters on Thu, Jul 27, 2000 at 02:20:26PM -0400 References: <20000727075058.A25450@keymaster.enme.ucalgary.ca> Message-ID: <20000727132322.A27400@keymaster.enme.ucalgary.ca> On Thu, Jul 27, 2000 at 02:20:26PM -0400, Tim Peters wrote: > [Neil Schemenauer] > > Here is some code that seems to hang on Linux UP machines. > > Sometimes it prints PIDS for a while and other times it stops > > after only a few. > > Well, that sucks! Does "UP" mean uniprocessor in this context? Yes. Neil From bwarsaw at beopen.com Thu Jul 27 21:27:43 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 27 Jul 2000 15:27:43 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0160.txt,1.3,1.4 References: <200007271846.LAA27298@slayer.i.sourceforge.net> <021d01bff7fd$8258afa0$f2a6b5d4@hagrid> Message-ID: <14720.36143.764784.551163@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: >> Remove the ugly form-feed characters some people use with >> Emacs. | note that those "ugly" form-feeds become nice
and

| in the HTML versions... This was a compromise between Jeremy and I (PEP 1 co-authors). No form-feeds, but section headers start in column 0 while the bodies start indented 4 spaces. -Barry From tim_one at email.msn.com Thu Jul 27 21:26:03 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 15:26:03 -0400 Subject: [Python-Dev] more unicode: \U support? In-Reply-To: <021e01bff7fd$93c34de0$f2a6b5d4@hagrid> Message-ID: [/F] > would it be a good idea to add \UXXXXXXXX > (8 hex digits) to 2.0? > > (only characters in the 0000-ffff range would > be accepted in the current version, of course). [Tim] > In which case there seems darned little point to it now . [/F] > with Python's approach to escape codes, it's not exactly easy > to *add* a new escape code -- you risk breaking code that for > some reason (intentional or not) relies on u"\U12345678" to end > up as a backslash followed by 9 characters... > > not very likely, but I've seen stranger things... Ah! You're right, I'm wrong. +1 on \U12345678 now. > (btw, can you walk over to Guido's office and tell him why \x > should ignore anything but the last two hex digits, no matter > what string type we're using...) No, but I can mail to his office, and am doing so. Guido, are you opposing us on this? If so, it would save time if you explained just the specific point you're wrong about . From esr at thyrsus.com Thu Jul 27 21:56:03 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jul 2000 15:56:03 -0400 Subject: [Python-Dev] PEP 201 In-Reply-To: <14720.35958.632383.574511@anthem.concentric.net>; from bwarsaw@beopen.com on Thu, Jul 27, 2000 at 03:24:38PM -0400 References: <14720.35958.632383.574511@anthem.concentric.net> Message-ID: <20000727155603.D9683@thyrsus.com> Barry A. Warsaw : > Here is the latest PEP 201, updated based on conversations with Guido > yesterday. Notice that there are no more Open Issues. Excellent. I have no remaining issues or hesitations about this PEP and am happy to see it resolved. Three cheers for Guido and everybody else who worked hard to make this fly! -- Eric S. Raymond The right to buy weapons is the right to be free. -- A.E. Van Vogt, "The Weapon Shops Of Isher", ASF December 1942 From tim_one at email.msn.com Thu Jul 27 21:45:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 15:45:47 -0400 Subject: [Python-Dev] PEP 201, zip() builtin In-Reply-To: <14720.35958.632383.574511@anthem.concentric.net> Message-ID: [Barry A. Warsaw] > -------------------- snip snip -------------------- > PEP: 201 > Title: Parallel Iteration Could we please change "Parallel" to, e.g., "Lockstep" throughout? Greg Wilson correctly pointed out that "parallel" in the context of loops means something very different to the scientific branch of the Python community. Easier to fix this now that after it's spread to the docs. > ... > However, for-loops iterate over only a single sequence, and it > is often desirable to loop over more than one sequence, in a > lock-step, "Chinese Menu" type of way. Just as you realized how inappropriate "parallel" was right here . > # find the length of the shortest sequence > shortest = min(*map(len, args)) Clearer as > shortest = min(map(len, args)) However, this implies that all sequences must tell the truth about their lengths, but the iteration protocol actually terminates via a sequence raising IndexError. I believe we want zip to follow the iteration protocol, in effect breaking out of the outer loop as soon as some s[i] raises IndexError. This was agreed to by all (incl. the BDFL) in some other year's debates over this. > prefers zip() due to it's Haskell[2] heritage. See version 1.7 "its", not "it's" > - Lazy evaluation. An earlier version of this PEP proposed that > zip() return a built-in object that performed lazy evaluation > using __getitem__() protocol. This has been strongly rejected > by the BDFL in favor of returning a real Python list. If lazy > evaluation is desired in the future, the BDFL suggests an xzip() > function be added. Which he'll then fight tooth and nail . > ... Nice job, Barry! Thank you. From guido at beopen.com Thu Jul 27 22:49:01 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 27 Jul 2000 15:49:01 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 10:10:51 MST." References: Message-ID: <200007272049.PAA30143@cj20424-a.reston1.va.home.com> [Guido] > > Second, what should happen to a slice assignment? [Ping] > My vote is: nothing! (Read on.) > > > The basic slice form is: > > > > a[i:j] += b > > What does this mean? I don't see how it could be any different from: > > a[j:j] = b Apparently you haven't used NumPy arrays (matrices). I haven't either, but I hear they overload + so that A+B is elementwise addition, and you can write A+1 to add 1 to each element of A. Thus, for a NumPy programmer, A += 1 would certainly look like A = A+1, and similar for A += B. > It looks to me like going through various contortions to support > augmented assignment to slices is not going to be worth the trouble. > > May i suggest > > >>> a[i:j] += b > SyntaxError: augmented assignment to a slice is not allowed That's what I thought too until I realized that for NumPy arrays slice+= makes sense. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Vladimir.Marangozov at inrialpes.fr Thu Jul 27 21:55:06 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 27 Jul 2000 21:55:06 +0200 (CEST) Subject: [Python-Dev] PEP 201, zip() builtin In-Reply-To: <14720.35958.632383.574511@anthem.concentric.net> from "Barry A. Warsaw" at Jul 27, 2000 03:24:38 PM Message-ID: <200007271955.VAA03850@python.inrialpes.fr> Barry A. Warsaw wrote: > > > Folks, > > Here is the latest PEP 201, updated based on conversations with Guido > yesterday. Notice that there are no more Open Issues. See instead > the BDFL Pronouncements section. Plan on seeing a C-based > implementation checked into the CVS devel tree soon. > > If you want to comment on this PEP, you must include "PEP 201" in the > Subject: header. Yes! I have a comment: "Long live BDFL!!!" Happy to see the 1st PEP closed! moving-forward'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas at xs4all.net Thu Jul 27 22:05:08 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 22:05:08 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271730.MAA21788@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 12:30:51PM -0500 References: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> <20000727182248.V266@xs4all.nl> <200007271730.MAA21788@cj20424-a.reston1.va.home.com> Message-ID: <20000727220508.C224@xs4all.nl> On Thu, Jul 27, 2000 at 12:30:51PM -0500, Guido van Rossum wrote: > > Actually, it wasn't the feebleness as much as the two different things you > > seem to be wanting, Guido ;) Previously (in another thread, and perhaps in > > the start of this thread as well) you argued that an index should always > > call __getitem__, with a slice object if it's a slice of some kind, *even a > > basic one*. So that we lose __getslice__ and rather teach people to use > > __getslice__. > That would be nice, but it would be b/w incompatible, so now we're > trying (again) to figure out how to still support __getslice__. My > proposal is to try and be b/w compatible if __getslice__ exists. See > my previous mail. Yes. So what we're talking about is a better way to do indexing all together, all types in one shot. ('indexes', 'slices' and 'collections' ? I'm not sure how to name the first and the last one, if not that.) And not just indexing, but setting and deleting at the same time, right ? So the most preferred way is to pass a single argument which is either: - A single object (directly what was passed in) for a single index. - A slice-object if any kind of single-slice was passed in, which holds the zero-to-three objects that the slice was 'created' with. - A tuple of zero or more of either of the above two. While I'm writing this down, I'm not sure if it's such a good idea. Isn't this placing a tad too much into one function ? It might require some severe logic to support this all, especially if you give 'special' meanings to some indexes. And we're inserting a new catch-all method -- a set of them, actually: get, set and del -- and that while Paul is trying to solve the other catch-all Python has, __getattr__/__setattr__. Then again, the use of this method is quite different from __getattr__/__setattr__... Most classes will commit to either a sequence-type or a mapping-type, and not even bother with extended slices or tuple-indexes. And lets not forget the convenience of writing those methods: __getitem__ is intuitive, both in name and semantics. So is __getslice__. The passing of a slice object to __getitem__ is a tad less intuitive, and a tuple of index/slice objects even less. I'm tempted to suggest a single change: when __getslice__ is not defined, pass a slice object (with no step, as if the slice had a trailing ':') to __getitem__, and document it properly. (and make builtin objects accept sliceobjects too !) Perhaps try to slowly deprecate getslice__. Give plenty __of examples of using __getitem__ and slice objects in the standard documentation. Also, I think it makes sense to make slice objects indexable, so that you can do: start, end, step = sliceobj instead of the less intuitive start, end, step = sliceobj.start, sliceobj.end, sliceobj.step But I've never used slice objects myself, so I can't really say whether it's a good idea. I suspect this is all for 2.1 or later, though. (As for what ?!ng suggested, the variable-args __hooks__, I don't see a difference between __getitem__(self, *val) and __getitem__(self, val) where val is a tuple. The same reasoning stands.) > > So now you want to *extend* the 'special case' to extended, 3-argument > > slices, but *not* Ellipses and tupled-slices (which aren't really tuples, > > because you can do (1, 2:5, ...)) -- or am I reading this wrong ? :) > > Not sure what you mean by that. (1, 2:5, ...) by itself is illegal > syntax; the special slice syntax can only occur directly in an > indexing context, e.g. a[1, 2:5, ...]. Exactly my point ;P Ferget it, not important. What I was trying to say was that: x[1, 2, 4:10:2] isn't the same as x[(1, 2, 4:10:2)] So the first isn't really indexing with a tuple -- because you can't do the 2nd. But the result as passed to __getitem__ *is* a tuple, so forget what I said ;) > > Don't worry, Guido, it isn't just you, I failed to grasp what those managers > > were trying to tell me today, too... I may just be too dense, today. > I hope they weren't telling you to stop working on Python! You seem > made for this work... Heh, nono, they don't have any say over what I do with Python. I'd force them to join the Python Consortium before I'd let them have any say over that ;) I don't do any *work* with Python, other than waiting for Barry to bring Mailman 2.0 out of beta so we can start a 'product line' on that, instead of Majordomo. It has nothing to do with Python but everything with my colleagues ;-) In fact, the only people who even know what Python is are my direct colleagues, my co-System-administrators, one of which is my direct boss. I didn't even see those people today, because half the meetings today and yesterday were with a bunch of product developers and the senior VP of technology (that's his translated title), and the other half was with the workers council, the management team and the CEO (sort of) of the company. And besides, even if they did try to tell me to stop with Python, it would go like the first episode of Red Dwarf, where Lister comes out of stasis and Holly, the shipboard computer, tries to tell him everyone's dead and he's been in stasis for 3 million years. "So where is everyone, Hol ?" "They're dead, Dave." "Who, the captain ?" "Everyone, Dave." "What, Petersen ?" "Yes, Dave. Everyone. Everyone is dead." "Not Kochansky!" "Yes, Dave. Everyone is dead. Dead is everyone. Is everyone dead. Dead everyone is." "Wait. What are you trying to tell me here, Hol ?" "You have to quit with Python, even in your free time." "What are you trying to tell me ?" ... And if that failed, I'd quit. I don't work here to get dictated how to do my work, and I certainly don't work here to get dictated how to live my life *outside* of work. I realize that's how PythonLabs operates but it's not how we run things in the old country, Guido ! :) No, all work I did and am doing on and with Python was hobby work. Which is just fine with me, for the moment, because it means I can slow down the pace whenever I want to. (Not that I've had that urge yet.) Can't-imagine-working-full-time-on-or-with-Python---two-week-bliss!- -seven-week-burnout-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas at xs4all.net Thu Jul 27 22:12:42 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 22:12:42 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: ; from ping@lfw.org on Thu, Jul 27, 2000 at 10:10:51AM -0700 References: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> Message-ID: <20000727221242.W266@xs4all.nl> On Thu, Jul 27, 2000 at 10:10:51AM -0700, Ka-Ping Yee wrote: > On Thu, 27 Jul 2000, Guido van Rossum wrote: > > The basic slice form is: > > > > a[i:j] += b > What does this mean? I don't see how it could be any different from: > a[j:j] = b a[i:j] += b means exactly the same as: a[i:j] = a[i:j] + b Whether it does anything other than raising an exception depends entirely on the types of a and b ! > I can't even imagine what the simpler case > a[i:j:k] += 1 > would do... unless you wish to propose element-wise operators (e.g. > add 1 to each of the elements that would participate in the slice) That's entirely user-defined. Augmented assignment simply extends Pythons extremely liberal (my cultural heritage tempts me to say 'communist';) semantics in these cases. a[i:j:k] += 1 is exactly a[i:j:k] = a[i:j:k] + 1 If 'a' is a Python class, this would turn into (forgetting about order of evaluation, for a second): a.__setitem__(slice(i, j, k), a[slice(i, j, k)].__add_ab__(1)) > It looks to me like going through various contortions to support > augmented assignment to slices is not going to be worth the trouble. > May i suggest > >>> a[i:j] += b > SyntaxError: augmented assignment to a slice is not allowed Sure, but it doesn't make sense unless 'a[i:j] = a[i:j] + b' raises similar problems. Why this arbitrary border ? Because you can't imagine people wanting it ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jul 27 22:22:09 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 22:22:09 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <398065f3.6724599@smtp.worldonline.dk> Message-ID: <398099F1.B6B1D281@lemburg.com> Finn Bock wrote: > > [M.-A. Lemburg] > > >BTW, does Java support UCS-4 ? If not, then Java is wrong > >here ;-) > > Java claims to use unicode 2.1 [*]. I couldn't locate anything describing if > this is UCS-2 or UTF-16. I think unicode 2.1 includes UCS-4. The actual > level of support for UCS-4 is properly debatable. > > - The builtin char is 16bit wide and can obviously not support UCS-4. > - The Character class can report if a character is a surrogate: > >>> from java.lang import Character > >>> Character.getType("\ud800") == Character.SURROGATE > 1 >>> unicodedata.category(u'\ud800') 'Cs' ... which means the same thing only in Unicode3 standards notation. Make me think: perhaps we should add the Java constants to unicodedata base. Is there a list of those available somewhere ? > - As reported, direct string comparison ignore surrogates. I would guess that this'll have to change as soon as JavaSoft folks realize that they need to handle UTF-16 and not only UCS-2. > - The BreakIterator does not handle surrogates. It does handle > combining characters and it seems a natural place to put support > for surrogates. What is a BreakIterator ? An iterator to scan line/word breaks ? > - The Collator class offers different levels of normalization before > comparing string but does not seem to support surrogates. This class > seems a natural place for javasoft to put support for surrogates > during string comparison. We'll need something like this for 2.1 too: first some standard APIs for normalization and then a few unicmp() APIs to use for sorting. We might even have to add collation sequences somewhere because this is a locale issue as well... sometimes it's even worse with different strategies used for different tasks within one locale, e.g. in Germany we sometimes sort the Umlaut ? as "ae" and at other times as extra character. > These findings are gleaned from the sources of JDK1.3 > > [*] > http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#25310 > Thanks for the infos, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Thu Jul 27 22:23:49 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 27 Jul 2000 22:23:49 +0200 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <200007271944.OAA29768@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jul 27, 2000 at 02:44:42PM -0500 References: <200007271944.OAA29768@cj20424-a.reston1.va.home.com> Message-ID: <20000727222349.X266@xs4all.nl> On Thu, Jul 27, 2000 at 02:44:42PM -0500, Guido van Rossum wrote: > > When the Unicode push started, it was agreed that we would ignore surrogates > > "for now". I sounded a caution then that I will repeat: the Unicode folks > > made a bad engineering decision, based on the (Eurocentric) assumption that > > 64K was a large enough space to meet their stated goals. Don't know how > > long it will take this half of the world to realize it, but UCS-4 is > > inevitable. > If we can put it off long enough until RAM and disk space have become > twice as cheap, I'm happy. I think 'speed' is more of an issue than 'price'. (price lowers much faster than speed rises.) However, I have to admit I've been lagging behind on the latest technologies, RAM-bus or SCRAM-jet or whatever they were called, which is supposed to allow a 1Ghz or thereabouts bus-architecture. (Which doesn't make RAM that speed, yet, but at least it evades the current bus bottleneck ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jul 27 22:29:59 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 27 Jul 2000 22:29:59 +0200 Subject: [Python-Dev] more unicode: \U support? References: Message-ID: <39809BC7.FD8E9C35@lemburg.com> Tim Peters wrote: > > [/F] > > would it be a good idea to add \UXXXXXXXX > > (8 hex digits) to 2.0? > > > > (only characters in the 0000-ffff range would > > be accepted in the current version, of course). I don't really get the point of adding \uXXXXXXXX when the internal format used is UTF-16 with support for surrogates. What should \u12341234 map to in a future implementation ? Two Python (UTF-16) Unicode characters ? > [Tim] > > In which case there seems darned little point to it now . > > [/F] > > with Python's approach to escape codes, it's not exactly easy > > to *add* a new escape code -- you risk breaking code that for > > some reason (intentional or not) relies on u"\U12345678" to end > > up as a backslash followed by 9 characters... > > > > not very likely, but I've seen stranger things... > > Ah! You're right, I'm wrong. +1 on \U12345678 now. See http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#100850 for how Java defines \uXXXX... We're following an industry standard here ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Thu Jul 27 22:35:11 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 13:35:11 -0700 Subject: [Python-Dev] more unicode: \U support? Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD347@RED-MSG-50> Actually, it'd be \U10FFFF, no need for 8 digits. Java doesn't support surrogates yet, so what Java does for \u doesn't make any difference. :) \U10FFFF should expand to either one character in UCS-4, or two characters in UTF-16/UCS-2. No particular reason why it can't work for 2.0. This is similar to the UTF-8 issue wrt surrogates. Bill From mwh21 at cam.ac.uk Thu Jul 27 22:41:02 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 27 Jul 2000 21:41:02 +0100 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Guido van Rossum's message of "Thu, 27 Jul 2000 09:12:58 -0500" References: <200007271412.JAA12251@cj20424-a.reston1.va.home.com> Message-ID: Guido van Rossum writes: > > Good idea. Are lists and tuples going to support seq[a:b:c] anytime soon? > > It's on my wish list, but can't be done for 2.0. This would involve the list type implementing the mapping API wouldn't it? This would seem to be a little on the silly side. Never mind; here's a quick-hack patch that "seems to work" for lists: Index: listobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/listobject.c,v retrieving revision 2.83 diff -u -c -r2.83 listobject.c *** listobject.c 2000/07/25 12:56:38 2.83 --- listobject.c 2000/07/27 20:38:50 *************** *** 1400,1405 **** --- 1400,1441 ---- (objobjproc)list_contains, /*sq_contains*/ }; + static PyObject* + list_subscript(PyObject* list, PyObject* item) + { + if (PyInt_Check(item)) { + return list_item((PyListObject*)list,PyInt_AS_LONG(item)); + } else if (PySlice_Check(item)) { + int start, stop, step, cur, i; + PyObject* result; + PyObject* it; + + if (PySlice_GetIndices((PySliceObject*)item,PyList_Size(list),&start,&stop,&step) < 0) { + PyErr_SetString(PyExc_TypeError, "slice indices must be integers"); + return NULL; + } + + result = PyList_New((stop-start)/step+1); + + for (cur = start, i = 0; cur < stop; cur += step, i++) { + it = PyList_GET_ITEM(list,cur); + Py_INCREF(it); + PyList_SET_ITEM(result,i,it); + } + + return result; + } else { + PyErr_SetString(PyExc_TypeError, "list indices must be integers"); + return NULL; + } + }; + + static PyMappingMethods list_as_mapping = { + (inquiry)list_length, + (binaryfunc)list_subscript, + (objobjargproc)NULL + }; + PyTypeObject PyList_Type = { PyObject_HEAD_INIT(&PyType_Type) 0, *************** *** 1414,1420 **** (reprfunc)list_repr, /*tp_repr*/ 0, /*tp_as_number*/ &list_as_sequence, /*tp_as_sequence*/ ! 0, /*tp_as_mapping*/ 0, /*tp_hash*/ 0, /*tp_call*/ 0, /*tp_str*/ --- 1450,1456 ---- (reprfunc)list_repr, /*tp_repr*/ 0, /*tp_as_number*/ &list_as_sequence, /*tp_as_sequence*/ ! &list_as_mapping, /*tp_as_mapping*/ 0, /*tp_hash*/ 0, /*tp_call*/ 0, /*tp_str*/ Have I missed anything obvious? I'd upload it to SF, but I don't really want something I've put such little effort into to be seriously considered... Cheers, M. -- 112. Computer Science is embarrassed by the computer. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html From tim_one at email.msn.com Thu Jul 27 22:57:58 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 16:57:58 -0400 Subject: [Python-Dev] more unicode: \U support? In-Reply-To: <39809BC7.FD8E9C35@lemburg.com> Message-ID: [/F] > would it be a good idea to add \UXXXXXXXX > (8 hex digits) to 2.0? > > (only characters in the 0000-ffff range would > be accepted in the current version, of course). [Tim agreed two msgs later; Guido agreed in private] [MAL] > I don't really get the point of adding \uXXXXXXXX No: Fredrik's suggestion is with an uppercase U. He is not proposing to extend the (lowercase) \u1234 notation. > when the internal format used is UTF-16 with support for surrogates. > > What should \u12341234 map to in a future implementation ? > Two Python (UTF-16) Unicode characters ? \U12345678 is C99's ISO 10646 notation; as such, it can't always be mapped to UTF-16. > See > > http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc .html#100850 > > for how Java defines \uXXXX... Which I pushed for from the start, and nobody is seeking to change. > We're following an industry standard here ;-) \U12345678 is also an industry standard, but in a more recent language (than Java) that had more time to consider the eventual implications of Unicode's limitations. We reserve the notation now so that it's possible to outgrow Unicode later. From tim_one at email.msn.com Thu Jul 27 23:01:39 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 17:01:39 -0400 Subject: [Python-Dev] more unicode: \U support? In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD347@RED-MSG-50> Message-ID: [Bill Tutt] > Actually, it'd be \U10FFFF, no need for 8 digits. Nope, \U is taken from the new C standard, and requires exactly 8 hex digits. It's a notation for ISO 10646, not for Unicode. > Java doesn't support surrogates yet, so what Java does for \u doesn't > make any difference. :) \u in Python was meant to mimic Java exactly, if for nothing else then for the sake of JPython. From esr at thyrsus.com Thu Jul 27 23:38:59 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 27 Jul 2000 17:38:59 -0400 Subject: [Python-Dev] Request for guidance on documentation Message-ID: <20000727173859.A10337@thyrsus.com> I have now made two passes through the docs for the new curses module, correcting minor errors and adding explanatory material. The question is what to do next, and that turns on whether discursive tutorial sections are are considered fit for inclusion in the library reference. If they are, I'll rewrite the existing curses HOWTO and slide it in there, perhaps adding some stuff from the "Introduction to ncurses" HTML tutorial I wrote lo those many moons ago for the ncurses distribution. Can anybody point me at the TeX source for the curses HOWTO? Also, I'm not sure where the material for curses.textbox should go. New section? Or a subsection in the curses document? -- Eric S. Raymond 'Faith' means not _wanting_ to know what is true. -- Nietzsche, Der Antichrist From trentm at ActiveState.com Fri Jul 28 00:00:56 2000 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 27 Jul 2000 15:00:56 -0700 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: References: <14719.49496.935765.730596@anthem.concentric.net> Message-ID: <20000727150056.B26555@ActiveState.com> On Thu, Jul 27, 2000 at 01:17:03AM -0400, Tim Peters wrote: > In parallel, could someone summarize the symptoms? Exactly how does it > fail? Does it fail the same way across all platforms on which it does fail? > Does it fail every time on all platforms on which it fails, or fail only > some of the time on all platforms on which it fails, or fails some of the > time on some of the platforms on which it fails but fails all of the time on > the rest of the platforms on which it fails ? > > If there exists a platform on which it fails but it doesn't fail every time > on that platform, that would be strong evidence of a timing hole. Those > usually require thought to identify and repair. I'll voluteer to > eyeball the code and do some thinking, but not unless the symptoms suggest > that's worthwhile. > > ignorantly y'rs - tim Here is what I have found: Machine: [trentm at molotok ~/main/contrib/python.build/dist/src]$ cat /proc/version Linux version 2.2.12-20smp (root at porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Mon Sep 27 10:34:45 EDT 1999 Note that this is an SMP machine. General symptoms: test_fork1 did *not* fail for me all the time. In fact it seemed, in this run of testing, to pass fine a number of time in a row and then some magical switch flipped and now it fails every time. I don't know what the 'switch' case is, nor do I know how to flip it on and off. This failing everytime is modulo debugging print statements that I have put in test_fork1.py. This indicates that it is a timing issue. Instumented test_fork1.py: -------------------------------------------------------------------------- import os, sys, time, thread try: os.fork except AttributeError: raise ImportError, "os.fork not defined -- skipping test_fork1" LONGSLEEP = 2 SHORTSLEEP = 0.5 NUM_THREADS = 4 alive = {} stop = 0 def f(id): while not stop: alive[id] = os.getpid() print 'thread %s: pid=%s' % (str(id), str(alive[id])) try: time.sleep(SHORTSLEEP) except IOError: pass def main(): print 'start main' for i in range(NUM_THREADS): thread.start_new(f, (i,)) print 'before sleep' time.sleep(LONGSLEEP) print 'after sleep (threads should be started now)' a = alive.keys() a.sort() assert a == range(NUM_THREADS) prefork_lives = alive.copy() print 'before fork' cpid = os.fork() print 'after fork' if cpid == 0: print 'child: start' # Child time.sleep(LONGSLEEP) n = 0 for key in alive.keys(): if alive[key] != prefork_lives[key]: n = n+1 print 'child: done, exit_value=%d' % n os._exit(n) else: print 'parent: start' # Parent spid, status = os.waitpid(cpid, 0) print 'parent: done waiting for child(pid=%d,status=%d)' %\ (spid, status) assert spid == cpid assert status == 0, "cause = %d, exit = %d" % (status&0xff, status>>8) global stop # Tell threads to die print 'parent: tell threads to die' stop = 1 time.sleep(2*SHORTSLEEP) # Wait for threads to die print 'parent: done (expect threads to be dead by now, hack)' main() -------------------------------------------------------------------------- A couple of test runs: *** This test run passed: [trentm at molotok ~/main/contrib/python.build/dist/src]$ ./python Lib/test/test_fork1.py start main before sleep thread 0: pid=26416 thread 1: pid=26417 thread 2: pid=26418 thread 3: pid=26419 thread 0: pid=26416 thread 1: pid=26417 thread 2: pid=26418 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 thread 3: pid=26419 thread 1: pid=26417 thread 0: pid=26416 after sleep (threads should be started now) before fork after fork thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 parent: start after fork child: start thread 0: pid=26416 thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 thread 1: pid=26417 thread 3: pid=26419 thread 0: pid=26416 thread 2: pid=26418 child: done, exit_value=0 parent: done waiting for child(pid=26420,status=0) parent: tell threads to die parent: done (expect threads to be dead by now, hack) *** This test run seg faulted but completed: [trentm at molotok ~/main/contrib/python.build/dist/src]$ ./python Lib/test/test_fork1.py start main before sleep thread 0: pid=26546 thread 1: pid=26547 thread 2: pid=26548 thread 3: pid=26549 thread 1: pid=26547 thread 3: pid=26549 thread 2: pid=26548 thread 0: pid=26546 thread 2: pid=26548 thread 0: pid=26546 thread 1: pid=26547 thread 3: pid=26549 thread 3: pid=26549 thread 1: pid=26547 thread 2: pid=26548 thread 0: pid=26546 after sleep (threads should be started now) before fork after fork parent: start after fork child: start Segmentation fault (core dumped) [trentm at molotok ~/main/contrib/python.build/dist/src]$ child: done, exit_value=0 [trentm at molotok ~/main/contrib/python.build/dist/src]$ *** This test hung on the last statement: [trentm at molotok ~/main/contrib/python.build/dist/src]$ ./python Lib/test/test_fork1.py start main before sleep thread 0: pid=26753 thread 1: pid=26754 thread 2: pid=26755 thread 3: pid=26756 thread 2: pid=26755 thread 3: pid=26756 thread 0: pid=26753 thread 1: pid=26754 thread 0: pid=26753 thread 2: pid=26755 thread 3: pid=26756 thread 1: pid=26754 thread 0: pid=26753 thread 3: pid=26756 thread 2: pid=26755 thread 1: pid=26754 after sleep (threads should be started now) before fork thread 0: pid=26753 after fork thread 2: pid=26755 parent: start thread 3: pid=26756 thread 1: pid=26754 after fork child: start thread 0: pid=26753 thread 3: pid=26756 thread 1: pid=26754 thread 2: pid=26755 thread 0: pid=26753 thread 3: pid=26756 thread 1: pid=26754 thread 2: pid=26755 thread 0: pid=26753 thread 3: pid=26756 thread 1: pid=26754 thread 2: pid=26755 thread 0: pid=26753 child: done, exit_value=0 parent: done waiting for child(pid=26757,status=0) Those are the only three run cases that I get. Trent -- Trent Mick TrentM at ActiveState.com From billtut at microsoft.com Fri Jul 28 00:25:01 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 15:25:01 -0700 Subject: [Python-Dev] more unicode: \U support? Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD34A@RED-MSG-50> [Tim stating that we need 8 digits to mimic C99's \U notation due to the ISO 10646 UCS-4 stuff.] Heh, I suppose. ISO has approved the following document for the next rev of 10646 though. "Proposal to restrict the range of code positions to the values up to U-0010FFFF": http://anubis.dkuug.dk/jtc1/sc2/wg2/docs/n2175.htm FYI, Bill From tim_one at email.msn.com Fri Jul 28 00:51:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 18:51:27 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <20000727150056.B26555@ActiveState.com> Message-ID: [Trent Mick, rallies to the cry for a summary of symptoms, which I'll summarize as On Linux version 2.2.12-20smp (root at porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP test_fork1 has one of three outcomes, varying across runs: 1. no problem 2. segfault 3. hang ] Thank you! In no case did the test fail on the particular thing it's *trying* to test: that after a fork, spawned threads don't show up in the child. So it's failing in unanticipated ways (when it does fail), and, to my eyes, ways that are very unlikely to be Python's fault. Everyone pursuing the other "fork bug" please note that test_fork1 doesn't import threading or use any mutexes -- it just spawns threads, forks once, and .sleeps() a lot. As with the other bug, would be interesting to recode test_fork1 in C and see whether it still segfaults and/or hangs. Should be easier to do for this test than the other one, since the *only* thread gimmick test_fork1 uses is thread.start_new(). We'll either discover that it still fails, in which case it's clearly not something Python caused and we'll have something pretty simple to pass on to the platform folks; or that it doesn't, in which case it's *really* interesting . Does anyone have test_fork1 failures on other flavors of SMP? From jeremy at beopen.com Fri Jul 28 01:08:33 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 27 Jul 2000 19:08:33 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: References: <20000727150056.B26555@ActiveState.com> Message-ID: <14720.49393.792630.426570@bitdiddle.concentric.net> >>>>> "TP" == Tim Peters writes: TP> unlikely to be Python's fault. Everyone pursuing the other TP> "fork bug" please note that test_fork1 doesn't import threading TP> or use any mutexes -- it just spawns threads, forks once, and TP> .sleeps() a lot. I don't think the "other" "fork bug" uses any more thread gimmicks than the bug you're considering. The test script that Neil posted did use the threading module, but it works just as well with the thread module. It only uses start_new_thread. The big difference between the two bugs is that the one Neil posted results in deadlock rather than a segfault. So they may well be completely different. For both bugs, though, a mutex and a condition variable are being use: The interpreter lock is being acquired and released in both cases. My current theory is that Python isn't dealing with the interpreter lock correctly across a fork. If some thread other than the one calling fork holds the interpreter lock mutex, the lock will be held forever in the child thread. If the child thread isn't making progress, the parent thread won't make progress either. Jeremy Here's a simplified test case: import os import thread def f(): while 1: if os.fork() == 0: print "%s %s" % (thread.get_ident(), os.getpid()) os._exit(0) os.wait() thread.start_new_thread(f, ()) thread.start_new_thread(f, ()) f() From trentm at ActiveState.com Fri Jul 28 01:17:47 2000 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 27 Jul 2000 16:17:47 -0700 Subject: [Python-Dev] failures in the regression tests In-Reply-To: <14719.42838.895374.783407@bitdiddle.concentric.net> References: <14719.42838.895374.783407@bitdiddle.concentric.net> Message-ID: <20000727161747.A27222@ActiveState.com> On Wed, Jul 26, 2000 at 11:07:02PM -0400, Jeremy Hylton wrote: > I am trying to keep track of failures in the regression test suite. > At the moment, all the available tests work correctly on my Linux > box. I understand there are still problems with test_fork1 on some > SMP Linux boxes. (I believe this error has been around for many > months.) And that the test_winreg and test_winreg32 tests are failing > on Windows builds. > > If you are aware of any other tests that are failing, please let me > know. (Preferably by private email.) We need to get the tests fixed > quickly. As I write in PEP 200 (Python 2.0 release schedule): Configuration: WinNT 4.00.1381 IE 5.500.2314.1003 MSVC 6.0 Dual Xeon processors (500Mhz?) Python CVS as of this morning Failures: test_mmap test_winreg test_winreg2 test_popen2 *** test_mmap: C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\test_mmap.py Position of foo: 1.0 pages Length of file: 2.0 pages Contents of byte 0: '\000' Contents of first 3 bytes: '\000\000\000' Modifying file's content... Contents of byte 0: '3' Contents of first 3 bytes: '3\000\000' Contents of second page: foobar Regex match on mmap (page start, length of match): 1.0 6 Seek to zeroth byte Seek to 42nd byte Seek to last byte Try to seek to negative position... Try to seek beyond end of mmap... Try to seek to negative position... Attempting resize() Traceback (most recent call last): File "..\Lib\test\test_mmap.py", line 114, in ? test_both() File "..\Lib\test\test_mmap.py", line 100, in test_both m.resize( 512 ) WindowsError: [Errno 6] The handle is invalid Fredrik (Win65, MSVC 5.0) tells me he gets the same failure but with a different error code. *** test_popen2 C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\test_popen2.py testing popen2... Traceback (most recent call last): File "..\Lib\test\test_popen2.py", line 22, in ? main() File "..\Lib\test\test_popen2.py", line 20, in main popen2._test() File "C:\trentm\tmp\python\dist\src\lib\popen2.py", line 148, in _test assert r.read() == teststr AssertionError I haven't looked at this one. *** test_winreg C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\regrtest.py test_winreg test_winreg test test_winreg failed -- Unread: '\012' 1 test failed: test_winreg This is just failing because Lib/test/output/test_winreg has one blank line at the end that it should not. I am going to checkin a fix soon (if I can remember how, seeing as I let everyone else checkin all my previous patches :) *** test_winreg2 C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\regrtest.py test_winreg2 test_winreg2 test test_winreg2 failed -- Writing: ' ', expected: '' 1 test failed: test_winreg2 C:\trentm\tmp\python\dist\src\PCbuild>python ..\Lib\test\test_winreg2.py Test Passed: testKeyDict_Values Test Passed: testKeyDict_Items Test Passed: testGetValueNames Test Passed: testSetDwordBigEndian Test Passed: testGetSubkeyNames Test Passed: testResourceRequirementsListType Test Passed: testLoad Test Passed: testDeleteKey Test Passed: testValueDict_Length Test Passed: testResourceDescriptionType Test Passed: testSetMultiSz Test Passed: testSetFullResourceDescription HKEY_CLASSES_ROOT HKEY_CURRENT_USER HKEY_LOCAL_MACHINE HKEY_USERS HKEY_CURRENT_CONFIG HKEY_DYN_DATA HKEY_PERFORMANCE_DATA Test Passed: testHives Test Passed: testDWordType Test Passed: testRemote Test Passed: testKeyDict_DelItem Test Failed: testSetIntValue Traceback (most recent call last): File "..\Lib\test\test_winreg2.py", line 297, in ? func() File "..\Lib\test\test_winreg2.py", line 178, in testSetIntValue key.deleteKey( "HKLM\\Software\\a\\b") AttributeError: 'RegKey' instance has no attribute 'deleteKey' Test Passed: testResourceLinkType Test Passed: testNoneType Test Passed: testValueDict_Map Test Passed: testSetResourceList Test Passed: testKeyDict_Length Test Passed: testKeyDict_ClearKeys Test Passed: testDWordBigEndianType Test Passed: testOpen Test Passed: testSetBinaryData Test Passed: testStringType Test Failed: testSetBinaryValue Traceback (most recent call last): File "..\Lib\test\test_winreg2.py", line 297, in ? func() File "..\Lib\test\test_winreg2.py", line 183, in testSetBinaryValue key.setValue( "abcd", array.array( 'c', "PPPPPPPPPPPPPPP") ) NameError: array Test Passed: testSetResourceRequirementsList Test Passed: testValueDict_Items Test Passed: testShortcuts Test Passed: testUnicodeValueName Test Passed: testGetValueDataFromEnum Test Passed: testValueDict_Get Test Passed: testValueDict_GetItem Test Passed: testValueDict_Keys Test Passed: testKeyDict_HasKey Test Passed: testExpandStringType Test Passed: testValueDict_HasKey Test Passed: testCreateKey Test Passed: testGetBinaryData Test Passed: testKeyDict_Get Test Passed: testSave Test Passed: testValueDict_ClearKeys Test Passed: testCmp Test Passed: testLinkType Test Passed: testSetExpandString Test Passed: testKeyDict_GetItem Test Passed: testRepr Test Passed: testClose Test Passed: testSetLink Test Passed: testGetValueDataFromName Test Passed: testUnicodeKeyName Test Passed: testKeyDict_Map Test Passed: testGetValueNameDataAndType Test Passed: testOpenFailure Test Passed: testSetDword Test Passed: testOpenKeyWithFlags Test Passed: testSetNone Test Passed: testKeyDict_Keys Test Passed: testMultiStringType Test Passed: testSetStringValue Test Passed: testValueDict_DelItem Test Passed: testNonZero Test Passed: testFlush Test Passed: testGetSubkeys Test Passed: testDeleteValue Test Passed: testSetString Test Passed: testValueDict_Values This is funny I was getting a more serious crash before. So was Fredrik. Trent -- Trent Mick TrentM at ActiveState.com From nhodgson at bigpond.net.au Fri Jul 28 01:21:01 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Fri, 28 Jul 2000 09:21:01 +1000 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: Message-ID: <013901bff821$55dd02e0$8119fea9@neil> > Getting? I'm very old. I think. But even if I had a memory, I usually > ignore Unix-specific posts (i.e., I can't run code with a .fork(), so can > only sit back & admire the perversity of those who both can & do ). IIRC ActiveState contributed to Perl a version of fork that works on Win32. Has anyone looked at this? Could it be grabbed for Python? This would help heal one of the more difficult platform rifts. Emulating fork for Win32 looks quite difficult to me but if its already done... Neil From trentm at ActiveState.com Fri Jul 28 01:36:01 2000 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 27 Jul 2000 16:36:01 -0700 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) In-Reply-To: <013901bff821$55dd02e0$8119fea9@neil> References: <013901bff821$55dd02e0$8119fea9@neil> Message-ID: <20000727163601.A32039@ActiveState.com> On Fri, Jul 28, 2000 at 09:21:01AM +1000, Neil Hodgson wrote: > IIRC ActiveState contributed to Perl a version of fork that works on > Win32. Has anyone looked at this? Could it be grabbed for Python? This would > help heal one of the more difficult platform rifts. Emulating fork for Win32 > looks quite difficult to me but if its already done... > I just asked Sarathy about this and he direct me to 'perldoc perlfork' (If you have ActivePerl 5.6 installed then you can look it up.) I have attached it here. The emulation of fork() in Win32 is not a perfect solution (e.g. sockets are not dupped, etc.). Trent ------------------- snip --------------------------- NAME perlfork - Perl's fork() emulation SYNOPSIS Perl provides a fork() keyword that corresponds to the Unix system call of the same name. On most Unix-like platforms where the fork() system call is available, Perl's fork() simply calls it. On some platforms such as Windows where the fork() system call is not available, Perl can be built to emulate fork() at the interpreter level. While the emulation is designed to be as compatible as possible with the real fork() at the the level of the Perl program, there are certain important differences that stem from the fact that all the pseudo child "processes" created this way live in the same real process as far as the operating system is concerned. This document provides a general overview of the capabilities and limitations of the fork() emulation. Note that the issues discussed here are not applicable to platforms where a real fork() is available and Perl has been configured to use it. DESCRIPTION The fork() emulation is implemented at the level of the Perl interpreter. What this means in general is that running fork() will actually clone the running interpreter and all its state, and run the cloned interpreter in a separate thread, beginning execution in the new thread just after the point where the fork() was called in the parent. We will refer to the thread that implements this child "process" as the pseudo-process. To the Perl program that called fork(), all this is designed to be transparent. The parent returns from the fork() with a pseudo-process ID that can be subsequently used in any process manipulation functions; the child returns from the fork() with a value of `0' to signify that it is the child pseudo-process. Behavior of other Perl features in forked pseudo-processes Most Perl features behave in a natural way within pseudo-processes. $$ or $PROCESS_ID This special variable is correctly set to the pseudo-process ID. It can be used to identify pseudo-processes within a particular session. Note that this value is subject to recycling if any pseudo-processes are launched after others have been wait()-ed on. %ENV Each pseudo-process maintains its own virtual enviroment. Modifications to %ENV affect the virtual environment, and are only visible within that pseudo-process, and in any processes (or pseudo-processes) launched from it. chdir() and all other builtins that accept filenames Each pseudo-process maintains its own virtual idea of the current directory. Modifications to the current directory using chdir() are only visible within that pseudo-process, and in any processes (or pseudo-processes) launched from it. All file and directory accesses from the pseudo-process will correctly map the virtual working directory to the real working directory appropriately. wait() and waitpid() wait() and waitpid() can be passed a pseudo-process ID returned by fork(). These calls will properly wait for the termination of the pseudo-process and return its status. kill() kill() can be used to terminate a pseudo-process by passing it the ID returned by fork(). This should not be used except under dire circumstances, because the operating system may not guarantee integrity of the process resources when a running thread is terminated. Note that using kill() on a pseudo-process() may typically cause memory leaks, because the thread that implements the pseudo-process does not get a chance to clean up its resources. exec() Calling exec() within a pseudo-process actually spawns the requested executable in a separate process and waits for it to complete before exiting with the same exit status as that process. This means that the process ID reported within the running executable will be different from what the earlier Perl fork() might have returned. Similarly, any process manipulation functions applied to the ID returned by fork() will affect the waiting pseudo-process that called exec(), not the real process it is waiting for after the exec(). exit() exit() always exits just the executing pseudo-process, after automatically wait()-ing for any outstanding child pseudo-processes. Note that this means that the process as a whole will not exit unless all running pseudo-processes have exited. Open handles to files, directories and network sockets All open handles are dup()-ed in pseudo-processes, so that closing any handles in one process does not affect the others. See below for some limitations. Resource limits In the eyes of the operating system, pseudo-processes created via the fork() emulation are simply threads in the same process. This means that any process-level limits imposed by the operating system apply to all pseudo-processes taken together. This includes any limits imposed by the operating system on the number of open file, directory and socket handles, limits on disk space usage, limits on memory size, limits on CPU utilization etc. Killing the parent process If the parent process is killed (either using Perl's kill() builtin, or using some external means) all the pseudo-processes are killed as well, and the whole process exits. Lifetime of the parent process and pseudo-processes During the normal course of events, the parent process and every pseudo-process started by it will wait for their respective pseudo-children to complete before they exit. This means that the parent and every pseudo-child created by it that is also a pseudo-parent will only exit after their pseudo-children have exited. A way to mark a pseudo-processes as running detached from their parent (so that the parent would not have to wait() for them if it doesn't want to) will be provided in future. CAVEATS AND LIMITATIONS BEGIN blocks The fork() emulation will not work entirely correctly when called from within a BEGIN block. The forked copy will run the contents of the BEGIN block, but will not continue parsing the source stream after the BEGIN block. For example, consider the following code: BEGIN { fork and exit; # fork child and exit the parent print "inner\n"; } print "outer\n"; This will print: inner rather than the expected: inner outer This limitation arises from fundamental technical difficulties in cloning and restarting the stacks used by the Perl parser in the middle of a parse. Open filehandles Any filehandles open at the time of the fork() will be dup()-ed. Thus, the files can be closed independently in the parent and child, but beware that the dup()-ed handles will still share the same seek pointer. Changing the seek position in the parent will change it in the child and vice-versa. One can avoid this by opening files that need distinct seek pointers separately in the child. Forking pipe open() not yet implemented The `open(FOO, "|-")' and `open(BAR, "-|")' constructs are not yet implemented. This limitation can be easily worked around in new code by creating a pipe explicitly. The following example shows how to write to a forked child: # simulate open(FOO, "|-") sub pipe_to_fork ($) { my $parent = shift; pipe my $child, $parent or die; my $pid = fork(); die "fork() failed: $!" unless defined $pid; if ($pid) { close $child; } else { close $parent; open(STDIN, "<&=" . fileno($child)) or die; } $pid; } if (pipe_to_fork('FOO')) { # parent print FOO "pipe_to_fork\n"; close FOO; } else { # child while () { print; } close STDIN; exit(0); } And this one reads from the child: # simulate open(FOO, "-|") sub pipe_from_fork ($) { my $parent = shift; pipe $parent, my $child or die; my $pid = fork(); die "fork() failed: $!" unless defined $pid; if ($pid) { close $child; } else { close $parent; open(STDOUT, ">&=" . fileno($child)) or die; } $pid; } if (pipe_from_fork('BAR')) { # parent while () { print; } close BAR; } else { # child print "pipe_from_fork\n"; close STDOUT; exit(0); } Forking pipe open() constructs will be supported in future. Global state maintained by XSUBs External subroutines (XSUBs) that maintain their own global state may not work correctly. Such XSUBs will either need to maintain locks to protect simultaneous access to global data from different pseudo-processes, or maintain all their state on the Perl symbol table, which is copied naturally when fork() is called. A callback mechanism that provides extensions an opportunity to clone their state will be provided in the near future. Interpreter embedded in larger application The fork() emulation may not behave as expected when it is executed in an application which embeds a Perl interpreter and calls Perl APIs that can evaluate bits of Perl code. This stems from the fact that the emulation only has knowledge about the Perl interpreter's own data structures and knows nothing about the containing application's state. For example, any state carried on the application's own call stack is out of reach. Thread-safety of extensions Since the fork() emulation runs code in multiple threads, extensions calling into non-thread-safe libraries may not work reliably when calling fork(). As Perl's threading support gradually becomes more widely adopted even on platforms with a native fork(), such extensions are expected to be fixed for thread-safety. BUGS * Having pseudo-process IDs be negative integers breaks down for the integer `-1' because the wait() and waitpid() functions treat this number as being special. The tacit assumption in the current implementation is that the system never allocates a thread ID of `1' for user threads. A better representation for pseudo-process IDs will be implemented in future. * This document may be incomplete in some respects. AUTHOR Support for concurrent interpreters and the fork() emulation was implemented by ActiveState, with funding from Microsoft Corporation. This document is authored and maintained by Gurusamy Sarathy . SEE ALSO the section on "fork" in the perlfunc manpage, the perlipc manpage -- Trent Mick TrentM at ActiveState.com From mhammond at skippinet.com.au Fri Jul 28 02:11:51 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 28 Jul 2000 10:11:51 +1000 Subject: [Python-Dev] failures in the regression tests In-Reply-To: <20000727161747.A27222@ActiveState.com> Message-ID: > Failures: > test_mmap Im looking at this > test_winreg > test_winreg2 And intend looking at these after. Mark. From billtut at microsoft.com Fri Jul 28 02:15:23 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 27 Jul 2000 17:15:23 -0700 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD34C@RED-MSG-50> [ActivePerl's hack for fork()] Oh gack. I think I'd rather just not go down this road. This is one huge ugly hack. :( Having to maintain separate environments, and separate working directories. *shiver* Bill From tim_one at email.msn.com Fri Jul 28 02:32:00 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 27 Jul 2000 20:32:00 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <14720.49393.792630.426570@bitdiddle.concentric.net> Message-ID: [Jeremy Hylton] > ... > For both bugs, though, a mutex and a condition variable are being use: Oh ya -- now that you mention it, I wrote that code -- but more than 7 years ago! How could a failure have gone undetected for so long? > The interpreter lock is being acquired and released in both cases. > > My current theory is that Python isn't dealing with the interpreter > lock correctly across a fork. If some thread other than the one > calling fork holds the interpreter lock mutex, Let's flesh out the most likely bad case: the main thread gets into posix_fork one of the spawned threads (say, thread 1) tries to acquire the global lock thread 1 gets into PyThread_acquire_lock thread 1 grabs the pthread mutex guarding "the global lock" the main thread executes fork() while thread 1 holds the mutex in the original process, everything's still cool: thread 1 still exists there, and it releases the mutex it acquired (after seeing that the "is it locked?" flag is set), yadda yadda yadda. but in the forked process, things are not cool: the (cloned) mutex guarding the global lock is still held What happens next in the child process is interesting : there is only one thread in the child process, and it's still in posix_fork. There it sets the main_thread and main_pid globals, and returns to the interpreter loop. That the forked pthread_mutex is still locked is irrelevant at this point: the child process won't care about that until enough bytecodes pass that its sole thread offers to yield. It doesn't bash into the already-locked cloned pthread mutex until it executes PyThread_release_lock as part of offering to yield. Then the child hangs. Don't know about this specific implementation, but phtread mutex acquires were usually implemented as busy-loops in my day (which is one reason Python locks were *not* modeled directly as pthread mutexes). So, in this scenario, the child hangs in a busy loop after an accidental amount of time passes after the fork. Matches your symptoms? It doesn't match Trent's segfault, but one nightmare at a time ... From mhammond at skippinet.com.au Fri Jul 28 04:06:10 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 28 Jul 2000 12:06:10 +1000 Subject: [Python-Dev] FW: [Patch #101006] fix mmapmodule test failures Message-ID: Hi all, I just uploaded a patch of mmapmodule to fix the test failures. The patch is not trivial, so I didnt just check it in. However, the patch also isnt _that_ large, so if some Windows people could give it a quick eyeball I would appreciate it. http://sourceforge.net/patch/?func=detailpatch&patch_id=101006&group_id=547 0 [Doh: Just noticed - the clode block that handles the DuplicateHandle() function failing needs to Py_DECREF the new object - Damn! So ignore that particular bug in the patch :-] Thanks, Mark. From greg at cosc.canterbury.ac.nz Fri Jul 28 05:02:29 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Fri, 28 Jul 2000 15:02:29 +1200 (NZST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <20000727150036.Z224@xs4all.nl> Message-ID: <200007280302.PAA09779@s454.cosc.canterbury.ac.nz> > Try to call __getslice__ with unconverted start, stop and step > If it fails with a TypeError, and step is not None, raise the above error > Else, convert start and stop to ints like the current normal slice > behaviour, and try __getslice__ the old way. NO!!! If my __getslice__ method has a bug which results in a type error, I want to get a traceback about it, not have it silently swallowed. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From greg at cosc.canterbury.ac.nz Fri Jul 28 05:10:07 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Fri, 28 Jul 2000 15:10:07 +1200 (NZST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271422.JAA13096@cj20424-a.reston1.va.home.com> Message-ID: <200007280310.PAA09782@s454.cosc.canterbury.ac.nz> Guido van Rossum : > But the two-arg opcode format slows down the opcode decoding -- and > that's the most time-critical part of all of ceval.c! I don't see why that has to be so, as long as you don't try to pre-fetch the extra argument before switching on the opcode. Just leave it up to each branch of the switch to fetch another argument if needed. In fact, why not do that for one-argument opcodes as well? If what you say is true, that should make argument decoding even faster than it is now! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From greg at cosc.canterbury.ac.nz Fri Jul 28 05:52:33 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Fri, 28 Jul 2000 15:52:33 +1200 (NZST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Message-ID: <200007280352.PAA09790@s454.cosc.canterbury.ac.nz> Ka-Ping Yee : > __get__(index, ...) # I want an ITEM. > __getslice__(slice-object, ...) # I want a SLICE. I like this (although it would be safer if the new-style __getslice__ had a new name as well). > This would require detection of whether any of the components > of a multidimensional (i.e. tuple) index were slices Doesn't the parser know this already? By the way, if you're going to make a clear separation between items and slices, then either *none* or *all* of the members of a multidimensional index should be slices, and mixing them should be an error! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From mhammond at skippinet.com.au Fri Jul 28 05:57:44 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 28 Jul 2000 13:57:44 +1000 Subject: [Python-Dev] New winreg module really an improvement? Message-ID: Ive just updated the test suite so that test_winreg2.py actually works. It appears that the new winreg.py module is still in a state of flux, but all work has ceased. The test for this module has lots of placeholders that are not filled in. Worse, the test code was checked in an obviously broken state (presumably "to be done", but guess who the bunny who had to do it was :-( Browsing the source made it clear that the module docstrings are still incomplete (eg "For information on the key API, open a key and look at its docstring."). As far as I can tell, there is no documentation in the library reference for this module (but the underlying _winreg module does have reasonable documentation) This is the first time I have had a serious look at the new winreg module, and the first time I have had to use it. I found it quite unintuitive, and it took me quite some time to update the test suite for what should have been a trivial case: Eg, the specific example I had a problem with was: key[value] Returns a result that includes the key index! This would be similar to a dictionary index _always_ returning the tuple, and the first element of the tuple is _always_ the key you just indexed. Has anyone else actually looked at or played with this, and still believe it is an improvement over _winreg? I personally find it unintuitive, and will personally continue to use _winreg. If we can't find anyone to complete it, document it, and stand up and say they really like it, I suggest we pull it. Still-can't-see-the-added-value-ly, Mark. From fdrake at beopen.com Fri Jul 28 06:49:28 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 28 Jul 2000 00:49:28 -0400 (EDT) Subject: [Python-Dev] New winreg module really an improvement? In-Reply-To: References: Message-ID: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> Mark Hammond writes: > It appears that the new winreg.py module is still in a state of flux, but > all work has ceased. The test for this module has lots of placeholders > that are not filled in. Worse, the test code was checked in an obviously > broken state (presumably "to be done", but guess who the bunny who had to > do it was :-( It was supposed to be Paul Prescod, since it was his module. > This is the first time I have had a serious look at the new winreg module, > and the first time I have had to use it. I found it quite unintuitive, and > it took me quite some time to update the test suite for what should have > been a trivial case: Interesting; I'd understood from Paul that you'd given approval to this module. > Has anyone else actually looked at or played with this, and still believe > it is an improvement over _winreg? I personally find it unintuitive, and > will personally continue to use _winreg. If we can't find anyone to > complete it, document it, and stand up and say they really like it, I > suggest we pull it. Paul, this is very much on your plate to make Mark happy with it, or it goes! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mhammond at skippinet.com.au Fri Jul 28 07:04:53 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 28 Jul 2000 15:04:53 +1000 Subject: [Python-Dev] New winreg module really an improvement? In-Reply-To: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> Message-ID: > Interesting; I'd understood from Paul that you'd given approval to > this module. Actually, it was more more along the lines of me promising to spend some time "over the next few days", and not getting to it. However, I believe it was less than a week before it was just checked in. I also sent a copy of the .NET registry API at that time, suggesting that it may be a better reference API, and one that VB, C# etc programmers will (over time) be familiar with. [Now I can admit it was the .NET API :-] Then the checkin just appeared! The end result was that I was never quite happy, but I felt personally responsible as I didnt find the time to look into this. I felt that I couldn't object, as I had let the team down. I fear this may be a general symptom of the new flurry of activity; no-one with a real job can keep up with this list, meaning valuable feedback on many proposals is getting lost. For example, DigiCool have some obviously smart people, but they are clearly too busy to offer feedback on anything lately. That is a real shame, and a good resource we are missing out on. > Paul, this is very much on your plate to make Mark happy > with it, or it goes! The comments about the documentation etc are easy to fix. I am quite interested to hear from people like Gordon and Bill about their thoughts. I am willing to accept the fact that just because I don't personally like it doesn't mean it sucks ;-) Mark. From bckfnn at worldonline.dk Fri Jul 28 07:15:17 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Fri, 28 Jul 2000 05:15:17 GMT Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <398099F1.B6B1D281@lemburg.com> References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <398065f3.6724599@smtp.worldonline.dk> <398099F1.B6B1D281@lemburg.com> Message-ID: <39811268.1131747@smtp.worldonline.dk> [M.-A. Lemburg] >Finn Bock wrote: >> >> [M.-A. Lemburg] >> >> >BTW, does Java support UCS-4 ? If not, then Java is wrong >> >here ;-) >> >> Java claims to use unicode 2.1 [*]. I couldn't locate anything describing if >> this is UCS-2 or UTF-16. I think unicode 2.1 includes UCS-4. The actual >> level of support for UCS-4 is properly debatable. >> >> - The builtin char is 16bit wide and can obviously not support UCS-4. >> - The Character class can report if a character is a surrogate: >> >>> from java.lang import Character >> >>> Character.getType("\ud800") == Character.SURROGATE >> 1 > >>>> unicodedata.category(u'\ud800') >'Cs' > >... which means the same thing only in Unicode3 standards >notation. > >Make me think: perhaps we should add the Java constants to >unicodedata base. Is there a list of those available >somewhere ? UNASSIGNED = 0 UPPERCASE_LETTER LOWERCASE_LETTER TITLECASE_LETTER MODIFIER_LETTER OTHER_LETTER NON_SPACING_MARK ENCLOSING_MARK COMBINING_SPACING_MARK DECIMAL_DIGIT_NUMBER LETTER_NUMBER OTHER_NUMBER SPACE_SEPARATOR LINE_SEPARATOR PARAGRAPH_SEPARATOR CONTROL FORMAT PRIVATE_USE SURROGATE DASH_PUNCTUATION START_PUNCTUATION END_PUNCTUATION CONNECTOR_PUNCTUATION OTHER_PUNCTUATION MATH_SYMBOL CURRENCY_SYMBOL MODIFIER_SYMBOL OTHER_SYMBOL >> - As reported, direct string comparison ignore surrogates. > >I would guess that this'll have to change as soon as JavaSoft >folks realize that they need to handle UTF-16 and not only >UCS-2. Predicting the future can be difficult, but here is my take: javasoft will never change the way String.compareTo works. String.compareTo is documented as: """ Compares two strings lexicographically. The comparison is based on the Unicode value of each character in the strings. ... """ Instead they will mark it as a very naive string comparison and suggest users to use the Collator classes for anything but the simplest cases. >> - The BreakIterator does not handle surrogates. It does handle >> combining characters and it seems a natural place to put support >> for surrogates. > >What is a BreakIterator ? An iterator to scan line/word breaks ? Yes, as well as character breaks. It already contains the framework for marking two chars next to each other as one. >> - The Collator class offers different levels of normalization before >> comparing string but does not seem to support surrogates. This class >> seems a natural place for javasoft to put support for surrogates >> during string comparison. > >We'll need something like this for 2.1 too: first some >standard APIs for normalization and then a few unicmp() >APIs to use for sorting. > >We might even have to add collation sequences somewhere because >this is a locale issue as well... sometimes it's even worse >with different strategies used for different tasks within one >locale, e.g. in Germany we sometimes sort the Umlaut ? as "ae" >and at other times as extra character. Info: The java Collator class is configured with - a locale and - a strengh parameter IDENTICAL; all difference are significant. PRIMARY (a vs b) SECONDARY (a vs ?) TERTIARY (a vs A) - a decomposition (http://www.unicode.org/unicode/reports/tr15/) NO_DECOMPOSITION CANONICAL_DECOMPOSITION FULL_DECOMPOSITION regards, finn From tim_one at email.msn.com Fri Jul 28 07:24:11 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 28 Jul 2000 01:24:11 -0400 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD345@RED-MSG-50> Message-ID: [Tim] > ... Don't know how long it will take this half of the world to > realize it, but UCS-4 is inevitable. [Bill Tutt] > On new systems perhaps, but important existing systems (Win32, > and probably Java) are stuck with that bad decision and have to > use UTF-16 for backward compatability purposes. Somehow that doesn't strike me as a good reason for Python to mimic them . > Surrogates aren't as far out as you might think. (The next rev of > the Unicode spec) But indeed, that's the *point*: they exhausted their 64K space in just a few years. Now the same experts say that adding 4 bits to the range will suffice for all time; I don't buy it; they picked 4 bits because that's what the surrogate mechanism was defined earlier to support. > That's certainly sooner than Win32 going away. :) I hope it stays around forever -- it's a great object lesson in what optimizing for yesterday's hardware can buy you . From bwarsaw at beopen.com Fri Jul 28 07:50:57 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 28 Jul 2000 01:50:57 -0400 (EDT) Subject: [Python-Dev] PEP 201, zip() builtin References: <14720.35958.632383.574511@anthem.concentric.net> Message-ID: <14721.8001.902979.957977@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> Could we please change "Parallel" to, e.g., "Lockstep" TP> throughout? Greg Wilson correctly pointed out that "parallel" TP> in the context of loops means something very different to the TP> scientific branch of the Python community. Easier to fix this TP> now that after it's spread to the docs. I know, and I guess I never came up with anything better which is why I didn't change it. "Lockstep" it is. TP> Just as you realized how inappropriate "parallel" was right TP> here . Heh. >> # find the length of the shortest sequence shortest = >> min(*map(len, args)) TP> Clearer as >> shortest = min(map(len, args)) A little experimentation leftover. Good catch. TP> However, this implies that all sequences must tell the truth TP> about their lengths, but the iteration protocol actually TP> terminates via a sequence raising IndexError. I believe we TP> want zip to follow the iteration protocol, in effect breaking TP> out of the outer loop as soon as some s[i] raises IndexError. TP> This was agreed to by all (incl. the BDFL) in some other TP> year's debates over this. Yup, I always intended the C implementation to obey the undocumented iteration protocol. But it /is/ better if the PEP's implementation were closer to the eventual C code, so I've swapped in a replacement. >> prefers zip() due to it's Haskell[2] heritage. See version 1.7 TP> "its", not "it's" Good catch. >> - Lazy evaluation. An earlier version of this PEP proposed >> that zip() return a built-in object that performed lazy >> evaluation using __getitem__() protocol. This has been >> strongly rejected by the BDFL in favor of returning a real >> Python list. If lazy evaluation is desired in the future, the >> BDFL suggests an xzip() function be added. TP> Which he'll then fight tooth and nail . :) >> ... TP> Nice job, Barry! Thank you. My pleasure! -Barry From moshez at math.huji.ac.il Fri Jul 28 07:49:30 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 28 Jul 2000 08:49:30 +0300 (IDT) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007271725.MAA17990@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 27 Jul 2000, Guido van Rossum wrote: > Another solution: require a class variable to indicate the class's > awareness: e.g. you must define __getslice_takes_three_args__ when > __getslice__(lo, hi, step) is supported, otherwise the call goes to > __getitem__(slice(lo, hi, step)). I don't think it can work: what about inheritance? Think of these two cases: class A: __getslice_takes_3_args__ def __getslice__(...): ... class B(A): def __getslice__(...): ... # something completely different and class C(A): def __getslice__(self, *args): # do something apply(A.__getslice__, (self,)+args) > This is a bit like the feature flag bits in the type struct. Which are ugly as hell too.....and only work because builtin types have a flat inheritance. oh-well-python-3000-is-just-around-the-corner-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From nowonder at nowonder.de Fri Jul 28 09:57:53 2000 From: nowonder at nowonder.de (Peter Schneider-Kamp) Date: Fri, 28 Jul 2000 07:57:53 +0000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.13,1.14 References: <200007280549.WAA02159@slayer.i.sourceforge.net> Message-ID: <39813D01.C3680553@nowonder.de> Barry Warsaw wrote: > > Update of /cvsroot/python/python/nondist/peps > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2151 > > Modified Files: > pep-0000.txt Hi Barry! I don't know if it is possible to run pep2html.py on your system (I have only used it on Linux), but it would be nice if you could do that after committing changes to the PEPs. Thanks, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter at schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de From bwarsaw at beopen.com Fri Jul 28 08:43:34 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 28 Jul 2000 02:43:34 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.13,1.14 References: <200007280549.WAA02159@slayer.i.sourceforge.net> <39813D01.C3680553@nowonder.de> Message-ID: <14721.11158.464598.572935@anthem.concentric.net> >>>>> "PS" == Peter Schneider-Kamp writes: PS> I don't know if it is possible to run pep2html.py on your PS> system (I have only used it on Linux), but it would be nice PS> if you could do that after committing changes to the PEPs. Hmm, I get the following exception when running on Python 2.0b1. Too sleepy to track this down right now. -B -------------------- snip snip -------------------- % python pep2html.py pep-0200.txt ... Traceback (most recent call last): File "pep2html.py", line 132, in ? main() File "pep2html.py", line 113, in main fixfile(file, os.path.splitext(file)[0] + ".html") File "pep2html.py", line 100, in fixfile line = fixpat.sub(lambda x, c=infile: fixanchor(c, x), line) TypeError: function requires exactly 3 arguments; 2 given From trentm at activestate.com Fri Jul 28 09:12:49 2000 From: trentm at activestate.com (Trent Mick) Date: Fri, 28 Jul 2000 00:12:49 -0700 Subject: [Python-Dev] failures in the regression tests In-Reply-To: References: <20000727161747.A27222@ActiveState.com> Message-ID: <20000728001249.A3056@ActiveState.com> On Fri, Jul 28, 2000 at 10:11:51AM +1000, Mark Hammond wrote: > And intend looking at these after. > > test_winreg Mark, you saw that I checked in a patch to Lib/test/output/test_winreg to make test_winreg pass, right? I did not check the test for content I just compared the output file with a newly generated (regrtest.py -g) output file. Trent -- Trent Mick TrentM at ActiveState.com From mal at lemburg.com Fri Jul 28 12:16:09 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 12:16:09 +0200 Subject: [Python-Dev] more unicode: \U support? References: Message-ID: <39815D69.1317A927@lemburg.com> Tim Peters wrote: > > [/F] > > would it be a good idea to add \UXXXXXXXX > > (8 hex digits) to 2.0? > > > > (only characters in the 0000-ffff range would > > be accepted in the current version, of course). > > [Tim agreed two msgs later; Guido agreed in private] > > [MAL] > > I don't really get the point of adding \uXXXXXXXX > > No: Fredrik's suggestion is with an uppercase U. He is not proposing to > extend the (lowercase) \u1234 notation. Ah, ok. So there will be no incompatibility with Java et al. > > when the internal format used is UTF-16 with support for surrogates. > > > > What should \u12341234 map to in a future implementation ? > > Two Python (UTF-16) Unicode characters ? > > \U12345678 is C99's ISO 10646 notation; as such, it can't always be mapped > to UTF-16. Sure it can: you'd have to use surrogates. Whether this should happen is another question, but not one which we'll have to deal with now, since as Fredrik proposed, \UXXXXXXXX will only work for 0-FFFF and raise an exception for all higher values. > > See > > > > http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc > .html#100850 > > > > for how Java defines \uXXXX... > > Which I pushed for from the start, and nobody is seeking to change. > > > We're following an industry standard here ;-) > > \U12345678 is also an industry standard, but in a more recent language (than > Java) that had more time to consider the eventual implications of Unicode's > limitations. We reserve the notation now so that it's possible to outgrow > Unicode later. Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Fri Jul 28 12:21:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 12:21:08 +0200 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: <013901bff821$55dd02e0$8119fea9@neil> Message-ID: <39815E94.462F65EF@lemburg.com> Neil Hodgson wrote: > > > Getting? I'm very old. I think. But even if I had a memory, I usually > > ignore Unix-specific posts (i.e., I can't run code with a .fork(), so can > > only sit back & admire the perversity of those who both can & do ). > > IIRC ActiveState contributed to Perl a version of fork that works on > Win32. Has anyone looked at this? Could it be grabbed for Python? This would > help heal one of the more difficult platform rifts. Emulating fork for Win32 > looks quite difficult to me but if its already done... This would indeed be a *very* useful addition and help porting os.fork() applications to Win32. (Ok, in the long run they would have to be converted to multi-threaded apps due to the process creation overhead on Win32, but for short term porting to Win32 this would be a Cool Thing, IMHO.) Can this code be grabbed from somewhere ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Fri Jul 28 13:42:12 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 06:42:12 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Fri, 28 Jul 2000 15:10:07 +1200." <200007280310.PAA09782@s454.cosc.canterbury.ac.nz> References: <200007280310.PAA09782@s454.cosc.canterbury.ac.nz> Message-ID: <200007281142.GAA03952@cj20424-a.reston1.va.home.com> > Guido van Rossum : > > > But the two-arg opcode format slows down the opcode decoding -- and > > that's the most time-critical part of all of ceval.c! > > I don't see why that has to be so, as long as you don't try > to pre-fetch the extra argument before switching on the > opcode. Just leave it up to each branch of the switch to > fetch another argument if needed. Sure. That's not how the patch is currently implemented though -- it adds this to the main opcode decoding: if (HAS_2ARG(opcode)) oparg2 = NEXTARG(); > In fact, why not do that for one-argument opcodes as well? > If what you say is true, that should make argument decoding > even faster than it is now! Yes -- but also would cause about 30-40 copies of the same code (which could be a single macro call). This could easily be tested and timed though. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Fri Jul 28 13:47:29 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 06:47:29 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Fri, 28 Jul 2000 15:52:33 +1200." <200007280352.PAA09790@s454.cosc.canterbury.ac.nz> References: <200007280352.PAA09790@s454.cosc.canterbury.ac.nz> Message-ID: <200007281147.GAA04007@cj20424-a.reston1.va.home.com> > Ka-Ping Yee : > > > __get__(index, ...) # I want an ITEM. > > __getslice__(slice-object, ...) # I want a SLICE. > > I like this (although it would be safer if the new-style > __getslice__ had a new name as well). > > > This would require detection of whether any of the components > > of a multidimensional (i.e. tuple) index were slices > > Doesn't the parser know this already? Yes. > By the way, if you're going to make a clear separation between items > and slices, then either *none* or *all* of the members of a > multidimensional index should be slices, and mixing them should > be an error! Huh? The way I understand this, mixing indices and slices is used all the time to reduce the dimensionality of an array. E.g. if A is a 2-dimensional array, A[0] is a 1-dim vector, and so are A[0, 1:-1] and A[:-1, 1]. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From thomas at xs4all.net Fri Jul 28 12:49:34 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 12:49:34 +0200 Subject: [Python-Dev] Developer activity (Was: New winreg module really an improvement?) In-Reply-To: ; from mhammond@skippinet.com.au on Fri, Jul 28, 2000 at 03:04:53PM +1000 References: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> Message-ID: <20000728124933.A266@xs4all.nl> On Fri, Jul 28, 2000 at 03:04:53PM +1000, Mark Hammond wrote: [ Something about something changing very fast, not giving Mark the chance to react to it ] > I fear this may be a general symptom of the new flurry of activity; no-one > with a real job can keep up with this list, meaning valuable feedback on > many proposals is getting lost. For example, DigiCool have some obviously > smart people, but they are clearly too busy to offer feedback on anything > lately. That is a real shame, and a good resource we are missing out on. Well, the same goes for Guido. Much though I liked the discussion about slices (and about augmented assignment) yesterday, it took me completely by suprise. And I'm not sure what the end result is, either. I don't even know whether it's finished or not, and it's not that easy to find out: it could be restin', pinin' for the fjords, or it could be nailed to its perch, it could be an ex-thread. And if it has ceased to be, well, it didn't amount to much, I think. Some opinions, and a simple (but effective, as far as I can tell) patch from Michael on one of the sub-issues. And I believe that's where PEPs are supposed to come in. They summarise the discussions, so that cool and smart people can look through it, see the proposal, see the pros and cons, and add their own. I'm not sure if it'll *work* like that, given that PEPs take some effort to create, and the format is still not too clear (at least, not to me.) And then there is the stuff that keeps popping up and isn't really PEPable: segfaults, tests failing, problem areas not covered by tests, unexpected behaviour noone has come around to fix or can figure out how to fix, etc. Maybe we need a TODO list, to store these issues ? Noone else is keeping track, I think, unless it's done in the Jitterbug buglist -- and I can't really work with jitterbug, myself. Items on the TODO list that stay on too long and start repetetive discussions are clearly candidates for PEPs, but others are just longstanding bugs that need to be properly investigated and fixed (probably elaborately) and noone disagrees with that. And if the 'fix' is non-obvious and involved, and generates too much discussion, it can always be PEPulated ;-) And if the TODO list needs a maintainer, someone that keeps track of all 'issues' that need closer examination, I'd be happy to volunteer. My idea would be to limit it to python-dev, unless someone forwards c.l.py traffic or other traffic that points out TODO-listable issues. (Or maybe SF has a good tool for this ? Not being a project admin, I've never seen the 'project manager', so I'm not sure if it has anything like a 'wishlist' ?) PS: Mark, I *do* have a real job, honest ;) I just get to be near my mail for about 14 hours a day. (I waste 4 hours to work/home travel, 6 hours to sleep/eating.) You should try working for an ISP, too! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido at beopen.com Fri Jul 28 14:06:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:06:05 -0500 Subject: [Python-Dev] New winreg module really an improvement? In-Reply-To: Your message of "Fri, 28 Jul 2000 15:04:53 +1000." References: Message-ID: <200007281206.HAA04102@cj20424-a.reston1.va.home.com> I vaguely remember that I wasn't happy with the way this was handled either, but was too busy at the time to look into it. (I can't say whether I'm happy with the module or not, since I've never tried to use it. But I do feel unhappy about the process.) Note that Paul recently updated most of the docstrings, so he can't be blamed alone, and I'm sure fixes to the docstrings are welcome. Mark, could you spend some time explaining what you think should be changed in the module? I think it's not too late to change it -- after all there aren't any real users of the module out. (I note that Greg Ward chose the same route as you -- he uses _winreg, not winreg.) I vaguely remember that Paul Prescod's main gripe with the _winreg API was that it's not object-oriented enough -- but that seems his main gripe about most code these days. :-) Paul, how much experience with using the Windows registry did you have when you designed the new API? --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Fri Jul 28 14:26:07 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:26:07 -0500 Subject: [Python-Dev] UTF-16 code point comparison In-Reply-To: Your message of "Fri, 28 Jul 2000 05:15:17 GMT." <39811268.1131747@smtp.worldonline.dk> References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <398065f3.6724599@smtp.worldonline.dk> <398099F1.B6B1D281@lemburg.com> <39811268.1131747@smtp.worldonline.dk> Message-ID: <200007281226.HAA04140@cj20424-a.reston1.va.home.com> > Predicting the future can be difficult, but here is my take: > javasoft will never change the way String.compareTo works. > String.compareTo is documented as: > """ > Compares two strings lexicographically. The comparison is based on > the Unicode value of each character in the strings. ... > """ (Noting that their definition of "character" is probably "a 16-bit value of type char", and has only fleeting resemblance to what is or is not defined as a character by the Unicode standard.) > Instead they will mark it as a very naive string comparison and suggest > users to use the Collator classes for anything but the simplest cases. Without having digested the entire discussion, this sounds like a good solution for Python too. The "==" operator should compare strings based on a simple-minded representation-oriented definition, and all the other stuff gets pushed into separate methods or classes. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Vladimir.Marangozov at inrialpes.fr Fri Jul 28 13:34:07 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 13:34:07 +0200 (CEST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007281142.GAA03952@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 28, 2000 06:42:12 AM Message-ID: <200007281134.NAA05764@python.inrialpes.fr> Guido van Rossum wrote: > > > In fact, why not do that for one-argument opcodes as well? > > If what you say is true, that should make argument decoding > > even faster than it is now! > > Yes -- but also would cause about 30-40 copies of the same code (which > could be a single macro call). This could easily be tested and timed > though. > Yes, and we won't be able to conclude anything. This is micro-optimization which doesn't give meaningful results. Actually, when I played last time with the main loop (it was for 1.5.2 I believe) duplicating the second argfetch doesn't give any speedup. Mainly because the code for the 2nd byte fetch is already in the processor's cache. Consequently, testing and fetching the 2nd argbyte (or skipping it) is faster when it's done before the big switch. If it's done per opcode, the cache may be invalidated. Micro-optimization doesn't worth the effort. As to the 2-byte arg limit, I think I'd be happy if the compiler raises an exception if this limit is exceeded. unrelated-with-PEP-203'ly y's -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at beopen.com Fri Jul 28 14:38:34 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:38:34 -0500 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) In-Reply-To: Your message of "Fri, 28 Jul 2000 12:21:08 +0200." <39815E94.462F65EF@lemburg.com> References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> Message-ID: <200007281238.HAA04294@cj20424-a.reston1.va.home.com> > > IIRC ActiveState contributed to Perl a version of fork that works > > on Win32. Has anyone looked at this? Could it be grabbed for > > Python? This would help heal one of the more difficult platform > > rifts. Emulating fork for Win32 looks quite difficult to me but if > > its already done... > This would indeed be a *very* useful addition and help porting > os.fork() applications to Win32. (Ok, in the long run they would > have to be converted to multi-threaded apps due to the process > creation overhead on Win32, but for short term porting to Win32 > this would be a Cool Thing, IMHO.) I have only one word: yuck! Portable Python code should not rely on fork. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Fri Jul 28 14:41:41 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:41:41 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Fri, 28 Jul 2000 13:34:07 +0200." <200007281134.NAA05764@python.inrialpes.fr> References: <200007281134.NAA05764@python.inrialpes.fr> Message-ID: <200007281241.HAA04335@cj20424-a.reston1.va.home.com> > > Yes -- but also would cause about 30-40 copies of the same code (which > > could be a single macro call). This could easily be tested and timed > > though. > > Yes, and we won't be able to conclude anything. This is micro-optimization > which doesn't give meaningful results. Actually, when I played last time > with the main loop (it was for 1.5.2 I believe) duplicating the second > argfetch doesn't give any speedup. Mainly because the code for > the 2nd byte fetch is already in the processor's cache. Consequently, > testing and fetching the 2nd argbyte (or skipping it) is faster when > it's done before the big switch. If it's done per opcode, the cache may > be invalidated. Fair enough (for one particular CPU at least). > Micro-optimization doesn't worth the effort. As to the 2-byte arg limit, > I think I'd be happy if the compiler raises an exception if this limit > is exceeded. That would be a good first step indeed! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Fri Jul 28 14:53:54 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 07:53:54 -0500 Subject: [Python-Dev] Developer activity (Was: New winreg module really an improvement?) In-Reply-To: Your message of "Fri, 28 Jul 2000 12:49:34 +0200." <20000728124933.A266@xs4all.nl> References: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> <20000728124933.A266@xs4all.nl> Message-ID: <200007281253.HAA04381@cj20424-a.reston1.va.home.com> [Mark H] > > I fear this may be a general symptom of the new flurry of activity; no-one > > with a real job can keep up with this list, meaning valuable feedback on > > many proposals is getting lost. For example, DigiCool have some obviously > > smart people, but they are clearly too busy to offer feedback on anything > > lately. That is a real shame, and a good resource we are missing out on. [Thomas W] > Well, the same goes for Guido. Not sure what you mean. I'm too busy to offer feedback on anything? Give me a break! I probably spend 4 hours reading and responding to python-dev each day. > Much though I liked the discussion about > slices (and about augmented assignment) yesterday, it took me completely by > suprise. And I'm not sure what the end result is, either. I don't even know > whether it's finished or not, and it's not that easy to find out: it could > be restin', pinin' for the fjords, or it could be nailed to its perch, it > could be an ex-thread. And if it has ceased to be, well, it didn't amount to > much, I think. Some opinions, and a simple (but effective, as far as I can > tell) patch from Michael on one of the sub-issues. It's still open. I was trying to respond to your own post where you considered a redesign of the augmented assignment bytecode. I still think the proposed redesign is a good one (always use LOAD a, LOAD b, AUGASS, STORE b; or LOADSLICE, LOAD b, AUGASS, STORESLICE etc.) > And I believe that's where PEPs are supposed to come in. They summarise the > discussions, so that cool and smart people can look through it, see the > proposal, see the pros and cons, and add their own. I'm not sure if it'll > *work* like that, given that PEPs take some effort to create, and the format > is still not too clear (at least, not to me.) Don't worry too much about the format! Just write in a style that you think works for you. We're specifying the format to ensure that PEPs contain all the necessary information and are easily readable; I hope the rules aren't seen as stifling for PEP authors! > And then there is the stuff > that keeps popping up and isn't really PEPable: segfaults, tests failing, > problem areas not covered by tests, unexpected behaviour noone has come > around to fix or can figure out how to fix, etc. > > Maybe we need a TODO list, to store these issues ? Noone else is keeping > track, I think, unless it's done in the Jitterbug buglist -- and I can't > really work with jitterbug, myself. Items on the TODO list that stay on too > long and start repetetive discussions are clearly candidates for PEPs, but > others are just longstanding bugs that need to be properly investigated and > fixed (probably elaborately) and noone disagrees with that. And if the 'fix' > is non-obvious and involved, and generates too much discussion, it can > always be PEPulated ;-) > > And if the TODO list needs a maintainer, someone that keeps track of all > 'issues' that need closer examination, I'd be happy to volunteer. My idea > would be to limit it to python-dev, unless someone forwards c.l.py traffic > or other traffic that points out TODO-listable issues. Actually, Jeremy is the officially appointed 2.0 release manager, and as far as I can tell he's doing a good job of keeping track of open issues. He's also working on transferring the JitterBug database to the SF Bug Tracker, so we can shut off Jitterbug. > (Or maybe SF has a good tool for this ? Not being a project admin, I've > never seen the 'project manager', so I'm not sure if it has anything like a > 'wishlist' ?) The SF Bug Trackerwould work, I think. > PS: Mark, I *do* have a real job, honest ;) I just get to be near my mail > for about 14 hours a day. (I waste 4 hours to work/home travel, 6 hours to > sleep/eating.) You should try working for an ISP, too! 4 hours travel time? That gets you across the country! This job must be real important for you...! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From skip at mojam.com Fri Jul 28 14:17:46 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 28 Jul 2000 07:17:46 -0500 (CDT) Subject: [Python-Dev] urllib - {quote,unquote} vs. {quote_plus,unquote_plus} Message-ID: <14721.31210.734864.412520@beluga.mojam.com> I realize there is a symmetry between the functionality of urllib.{quote,unquote} and urllib.{quote_plus,unquote_plus}, but why doesn't unquote function like unquote_plus and map "+" to " "? Skip From thomas at xs4all.net Fri Jul 28 14:24:29 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 14:24:29 +0200 Subject: [Python-Dev] Developer activity (Was: New winreg module really an improvement?) In-Reply-To: <200007281253.HAA04381@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 28, 2000 at 07:53:54AM -0500 References: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> <20000728124933.A266@xs4all.nl> <200007281253.HAA04381@cj20424-a.reston1.va.home.com> Message-ID: <20000728142429.B266@xs4all.nl> On Fri, Jul 28, 2000 at 07:53:54AM -0500, Guido van Rossum wrote: > > Well, the same goes for Guido. > Not sure what you mean. I'm too busy to offer feedback on anything? > Give me a break! I probably spend 4 hours reading and responding to > python-dev each day. Unless I misinterpreted you, *you yourself* said this, Guido. (I can look this up if you wish.) PEPs are there so you (and others, like me) don't have to follow the details of each discussion. I didn't mean to imply you (or anyone else) don't consider python-dev important enough to follow, absolutely not. I just meant that we can't expect you (or anyone) to give feedback on *everything*, given the pace of messages yesterday (or any of the other bursts of activity.) Reading all messages is something else than understanding the issues, considering them and proposing new solutions or new ways of viewing them. > > Much though I liked the discussion about slices (and about augmented > > assignment) yesterday, it took me completely by suprise. And I'm not > > sure what the end result is, either. > I still think the proposed redesign is a good one (always use LOAD a, LOAD > b, AUGASS, STORE b; or LOADSLICE, LOAD b, AUGASS, STORESLICE etc.) So do I. I think thread-safety should be solved differently, even though I think it should be solved, somehow. ThreadSafeDict, with explicit grab/release lock ? :P But that was the other sub-thread. In this particular case, I was referring to the slicing thing, but I'm probably too impatient and urging on these issues. (Actually, I know I am. I'm just a tad worried things like this will go on and on and get lost and etc, etc, etc.) I'll be implementing the seperate AUGMENTED_ADD/SUBTRACT/etc ops this weekend, I think, and removing the 2-argument opcodes etc. > > And if the TODO list needs a maintainer, someone that keeps track of all > > 'issues' that need closer examination, I'd be happy to volunteer. My idea > > would be to limit it to python-dev, unless someone forwards c.l.py traffic > > or other traffic that points out TODO-listable issues. > Actually, Jeremy is the officially appointed 2.0 release manager, and > as far as I can tell he's doing a good job of keeping track of open > issues. He's also working on transferring the JitterBug database to > the SF Bug Tracker, so we can shut off Jitterbug. Ah, yes, hadn't considered the 2.0 release manager, probably because I hadn't figured it as a job for him -- some of these issues go beyond 2.0. Never-saw-a-release-manager-before-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From akuchlin at cnri.reston.va.us Fri Jul 28 14:29:19 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 28 Jul 2000 08:29:19 -0400 Subject: [Python-Dev] Re: [Patch #100740] gzip: readline(), readlines() patch In-Reply-To: <200007281025.DAA28944@delerium.i.sourceforge.net>; from noreply@sourceforge.net on Fri, Jul 28, 2000 at 03:25:36AM -0700 References: <200007281025.DAA28944@delerium.i.sourceforge.net> Message-ID: <20000728082919.A10938@newcnri.cnri.reston.va.us> On Fri, Jul 28, 2000 at 03:25:36AM -0700, noreply at sourceforge.net wrote: >Patch #100740 has been updated. >gvanrossum wrote: >Almost right. The docs for file objects specifically imply that a >negative arg to readline() or a zero arg to readlines() is the same as >no args; your defaults are sys.maxint so an explicit -1 or 0 won't do >the right thing. (This is important for wrapper classes that want to Which docs say this? I looked at Doc/lib/libstdtypes.tex to get the semantics: \begin{methoddesc}[file]{readline}{\optional{size}} ... If the \var{size} argument is present and non-negative, it is a maximum byte count (including the trailing newline) and an incomplete line may be returned. ... \end{methoddesc} \begin{methoddesc}[file]{readlines}{\optional{sizehint}} ... If the optional \var{sizehint} argument is present, instead of reading up to \EOF{}, whole lines totalling approximately \var{sizehint} bytes (possibly after rounding up to an internal buffer size) are read. \end{methoddesc} Neither text mentions the special cases for -1 and 0 in each function. Fixing the patch to get this right is trivial, but I think the docs need to be updated to mention this. --amk From akuchlin at cnri.reston.va.us Fri Jul 28 14:34:19 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 28 Jul 2000 08:34:19 -0400 Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <20000727173859.A10337@thyrsus.com>; from esr@thyrsus.com on Thu, Jul 27, 2000 at 05:38:59PM -0400 References: <20000727173859.A10337@thyrsus.com> Message-ID: <20000728083419.B10938@newcnri.cnri.reston.va.us> On Thu, Jul 27, 2000 at 05:38:59PM -0400, Eric S. Raymond wrote: >correcting minor errors and adding explanatory material. The question >is what to do next, and that turns on whether discursive tutorial sections >are are considered fit for inclusion in the library reference. That's up to Fred to decide. I suspect the answer is no, since it would make the library reference too large and ungainly if every section had a tutorial. Regular expressions, socket programming, and XML processing are all sizable topics in their own right that would be covered. I will re-raise the idea of adding the HOWTOs to the documentation subtree, though; Fred & I have discussed it before, and decided not to for reasons that I can't remember. >Can anybody point me at the TeX source for the curses HOWTO? I'l mail it to you privately. >Also, I'm not sure where the material for curses.textbox should go. New >section? Or a subsection in the curses document? Probably a subsection, but again, Fred has final ruling on that. --amk From fdrake at beopen.com Fri Jul 28 15:24:41 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 28 Jul 2000 09:24:41 -0400 (EDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <20000728083419.B10938@newcnri.cnri.reston.va.us> References: <20000727173859.A10337@thyrsus.com> <20000728083419.B10938@newcnri.cnri.reston.va.us> Message-ID: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> On Thu, Jul 27, 2000 at 05:38:59PM -0400, Eric S. Raymond wrote: > correcting minor errors and adding explanatory material. The question > is what to do next, and that turns on whether discursive tutorial sections > are are considered fit for inclusion in the library reference. Andrew Kuchling writes: > That's up to Fred to decide. I suspect the answer is no, since it > would make the library reference too large and ungainly if every Hey, it's large & unweildy now. ;-) But I think you're right. Improving the curses HOWTO separately from the reference documentation makes sense. > I will re-raise the idea of adding the HOWTOs to the documentation > subtree, though; Fred & I have discussed it before, and decided not to > for reasons that I can't remember. I don't recall exactly, but I think it had a bit to do with the release scheduling (perhaps this was when the documentation was release lockstep with CPython?) and editorial control -- as long as you're willing to act as HOWTO editor, you should be able to release regardless of whether there's anything new to release in the standard library. Eric again: > Also, I'm not sure where the material for curses.textbox should go. New > section? Or a subsection in the curses document? curses.textbox should be documented in a \section like any other module. It can be placed in libcurses.tex along with the other curses-related modules. Is curses.wrapper documented, or is it an implementation detail? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at beopen.com Fri Jul 28 16:33:32 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 09:33:32 -0500 Subject: [Python-Dev] Re: [Patch #100740] gzip: readline(), readlines() patch In-Reply-To: Your message of "Fri, 28 Jul 2000 08:29:19 -0400." <20000728082919.A10938@newcnri.cnri.reston.va.us> References: <200007281025.DAA28944@delerium.i.sourceforge.net> <20000728082919.A10938@newcnri.cnri.reston.va.us> Message-ID: <200007281433.JAA04585@cj20424-a.reston1.va.home.com> > >Almost right. The docs for file objects specifically imply that a > >negative arg to readline() or a zero arg to readlines() is the same as > >no args; your defaults are sys.maxint so an explicit -1 or 0 won't do > >the right thing. (This is important for wrapper classes that want to > > Which docs say this? I looked at Doc/lib/libstdtypes.tex to get the > semantics: > > \begin{methoddesc}[file]{readline}{\optional{size}} > ... If the \var{size} argument is present and > non-negative, it is a maximum byte count (including the trailing > newline) and an incomplete line may be returned. ... > \end{methoddesc} I read this that any negative argument has the same effect as an absent argument. I suggested -1 as a typical negative number. The doc could be more explicit though. > \begin{methoddesc}[file]{readlines}{\optional{sizehint}} > ... If the optional \var{sizehint} argument is > present, instead of reading up to \EOF{}, whole lines totalling > approximately \var{sizehint} bytes (possibly after rounding up to an > internal buffer size) are read. > \end{methoddesc} Here you're right -- I got the 0 from the code. It should be documented. > Neither text mentions the special cases for -1 and 0 in each function. > Fixing the patch to get this right is trivial, but I think the docs > need to be updated to mention this. Agreed. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From pf at artcom-gmbh.de Fri Jul 28 15:37:56 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Fri, 28 Jul 2000 15:37:56 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: <14720.16857.900370.320050@bitdiddle.concentric.net> from Jeremy Hylton at "Jul 27, 2000 10: 6:17 am" Message-ID: Hi, Jeremy Hylton wrote: [...] > Feel free to think of it as a guide, but don't think of it as a > specification! (It is, as you mention, fairly old.) The only ------------------------------------------^^^^^^^^^^^ This was my argument to harden Moshes point, that *MUCH* code written until today relies on this advertised behaviour! > official word on reclaiming externel resource is the Python Language > Reference -- http://www.python.org/doc/current/ref/. > > >Some objects contain references to "external" resources such as open > >files or windows. It is understood that these resources are freed when > >the object is garbage-collected, but since garbage collection is not > >guaranteed to happen, such objects also provide an explicit way to > >release the external resource, usually a close() method. Programs are > >strongly recommended to explicitly close such objects. The > >`try...finally' statement provides a convenient way to do this. > > If this isn't clear enough, we could revise it for the next release of > the documentation. As Guido said, the code is broken, not JPython. Thank you: This paragraph is indeed clear enough. :-( And I must admit, that the above cited paragraph is at least as old as Mark Lutz book (I've just restored Python1.2/Doc to check this out, since I couldn't believe that in the first place: damned time machine!) I must have overlooked this particular paragraph in the past and so may many other users of Python (At least Mark Lutz ;-) ?) However I disagree with this paragraph. IMO one of the major strenghts of Python (in its reference implementation C-Python) has today compared to other languages (Java) is this particular behaviour. The argument made in the last sentence of the paragraph cited from the reference manual is bogus: In order to be able to call a close() method you have to keep an explicit reference to the object in question. This usually requires many lines of source code where previously only one line was needed: func(constructor("foo").method()) has to be recoded as try: ref = constructor("foo") func(ref.method()) finally: ref.close() if constructor happens to keep external resources. This is a factor of five (in LOC) of code bloat and is absolutely unacceptable. And in GUI programs you usually have *many* objects, that keep external resources like windows, files and the like. If this kind of coding is required to make existing Python apps running reliable under 'JPython', then this will render 'JPython' (and any other Python implementation without proper reliable reclaiming) pretty useless for me. (and may be to other members of the Python community) For me all those nifty new features currently discussed here (augmented ass., list comprehensions...) are not all *that* useful, compared to this important convience of the current C-Python implementation. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From moshez at math.huji.ac.il Fri Jul 28 15:45:20 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 28 Jul 2000 16:45:20 +0300 (IDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> Message-ID: On Fri, 28 Jul 2000, Fred L. Drake, Jr. wrote: > I don't recall exactly, but I think it had a bit to do with the > release scheduling (perhaps this was when the documentation was > release lockstep with CPython?) and editorial control -- as long as > you're willing to act as HOWTO editor, you should be able to release > regardless of whether there's anything new to release in the standard > library. Neither of those reasons are enough not to put the HOWTOs in the CVS tree. Editors can keep the version in the CVS current via the patch manager, and release them as they need to. However, people who d/l Python will automatically download the HOWTOs. Think of perldoc lol (lists of lists) -- definitely "HOWTO" material, but in the Perl standard docs. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From guido at beopen.com Fri Jul 28 16:54:07 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 09:54:07 -0500 Subject: [Python-Dev] Developer activity (Was: New winreg module really an improvement?) In-Reply-To: Your message of "Fri, 28 Jul 2000 14:24:29 +0200." <20000728142429.B266@xs4all.nl> References: <14721.4312.3724.961606@cj42289-a.reston1.va.home.com> <20000728124933.A266@xs4all.nl> <200007281253.HAA04381@cj20424-a.reston1.va.home.com> <20000728142429.B266@xs4all.nl> Message-ID: <200007281454.JAA04789@cj20424-a.reston1.va.home.com> > > > Well, the same goes for Guido. > > > Not sure what you mean. I'm too busy to offer feedback on anything? > > Give me a break! I probably spend 4 hours reading and responding to > > python-dev each day. > > Unless I misinterpreted you, *you yourself* said this, Guido. (I can look > this up if you wish.) PEPs are there so you (and others, like me) don't > have to follow the details of each discussion. I didn't mean to imply you > (or anyone else) don't consider python-dev important enough to follow, > absolutely not. I just meant that we can't expect you (or anyone) to give > feedback on *everything*, given the pace of messages yesterday (or any of > the other bursts of activity.) You were commenting on Digital Creation's total absence. I am busy, but I am still very much involved in everything that goes on here, hence my reaction of "no fair!" That said, *nobody* can deal with 500 messages in one weekend, so the creations of PEPs should be received enthusiastically by all. > Reading all messages is something else than understanding the issues, > considering them and proposing new solutions or new ways of viewing them. And believe me, whereever I can, I do! > So do I. I think thread-safety should be solved differently, even though I > think it should be solved, somehow. ThreadSafeDict, with explicit > grab/release lock ? :P Library issue. > But that was the other sub-thread. In this particular case, I was referring > to the slicing thing, but I'm probably too impatient and urging on these > issues. (Actually, I know I am. I'm just a tad worried things like this will > go on and on and get lost and etc, etc, etc.) The slicing reorg is all pie-in-the-sky. Good for a post-2.0 PEP. > I'll be implementing the seperate AUGMENTED_ADD/SUBTRACT/etc ops this > weekend, I think, and removing the 2-argument opcodes etc. Good! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From Vladimir.Marangozov at inrialpes.fr Fri Jul 28 16:04:03 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 16:04:03 +0200 (CEST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007281241.HAA04335@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 28, 2000 07:41:41 AM Message-ID: <200007281404.QAA06091@python.inrialpes.fr> Guido van Rossum wrote: > > > [me, on micro-optimizing the main loop] > > Fair enough (for one particular CPU at least). Since we're at it, it's worth mentioning another conclusion we came across at the time: the cache effects in the main loop are significant -- it is more important to try keeping at best the main loop small enough, so that those effects are minimized. An experiment I did at the time which gave some delta-speedup: I folded most of the UNOP & BINOP opcodes since they differ only by the functon they call and they duplicate most of the opcode body. Like this: Original: case BINARY_POWER: w = POP(); v = POP(); x = PyNumber_Power(v, w, Py_None); Py_DECREF(v); Py_DECREF(w); PUSH(x); if (x != NULL) continue; break; case BINARY_MULTIPLY: w = POP(); v = POP(); x = PyNumber_Multiply(v, w); Py_DECREF(v); Py_DECREF(w); PUSH(x); if (x != NULL) continue; break; ... Folded version: case BINARY_POWER: w = POP(); v = POP(); x = PyNumber_Power(v, w, Py_None); goto end_binop; case BINARY_MULTIPLY: w = POP(); v = POP(); x = PyNumber_Multiply(v, w); goto end_binop; ... end_binop: Py_DECREF(v); Py_DECREF(w); PUSH(x); if (x != NULL) continue; break; This reduced the code size of ceval.c, which resulted in less cache effects and gave more speed, despite the additional jumps. It possibly results in less page-faults too, although this is unlikely. Which makes me think that, if we want to do something about cache effects, it is probably not a bad idea to just "reorder" the bytecodes in the big switch by decreasing frequency (we have some stats about this -- I believe Skip and MAL have discussed the opcodes' frequency and the charts lie somewhere in the archives). I remember Marc-Andre had done something in this direction and reported some perf improvements too. Since reordering the opcodes doesn't really hurt, if I'm about to do something with the main loop, it'll be only this. > > > Micro-optimization doesn't worth the effort. As to the 2-byte arg limit, > > I think I'd be happy if the compiler raises an exception if this limit > > is exceeded. > > That would be a good first step indeed! I'll try to have a look, if someone else is not more reactive than me. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at beopen.com Fri Jul 28 17:05:48 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 10:05:48 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Fri, 28 Jul 2000 16:04:03 +0200." <200007281404.QAA06091@python.inrialpes.fr> References: <200007281404.QAA06091@python.inrialpes.fr> Message-ID: <200007281505.KAA04865@cj20424-a.reston1.va.home.com> > Since we're at it, it's worth mentioning another conclusion we came across > at the time: the cache effects in the main loop are significant -- it is > more important to try keeping at best the main loop small enough, so that > those effects are minimized. Yes, that's what Tim keeps hammering on too. > An experiment I did at the time which gave some delta-speedup: > I folded most of the UNOP & BINOP opcodes since they differ only by the > functon they call and they duplicate most of the opcode body. Like this: [...] > This reduced the code size of ceval.c, which resulted in less cache effects > and gave more speed, despite the additional jumps. It possibly results in > less page-faults too, although this is unlikely. I expect this is wholly attributable to the reduced code size. Most binary operators aren't used frequently enough to make a difference in other ways. If you put the common code at the end of the code for binary '+', that would optimize the most common operator. > Which makes me think that, if we want to do something about cache effects, > it is probably not a bad idea to just "reorder" the bytecodes in the big > switch by decreasing frequency (we have some stats about this -- I believe > Skip and MAL have discussed the opcodes' frequency and the charts lie > somewhere in the archives). I remember Marc-Andre had done something in > this direction and reported some perf improvements too. Since reordering > the opcodes doesn't really hurt, if I'm about to do something with the > main loop, it'll be only this. Go for it -- sounds good! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From fdrake at beopen.com Fri Jul 28 16:06:00 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 28 Jul 2000 10:06:00 -0400 (EDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> Message-ID: <14721.37704.872570.141761@cj42289-a.reston1.va.home.com> Moshe Zadka writes: > Neither of those reasons are enough not to put the HOWTOs in the CVS tree. > Editors can keep the version in the CVS current via the patch manager, > and release them as they need to. However, people who d/l Python will > automatically download the HOWTOs. Think of perldoc lol (lists of lists) > -- definitely "HOWTO" material, but in the Perl standard docs. I'm happy to have them under CVS; I think the big issue is *where*. I'm not convinced they belong in the same portion of the tree as the standard documentation. Here's a thought: we currently have dist/ src/ Doc/ Instead, we could have: dist/ docs/ howto/ standard/ src/ The howto/ tree could be the howto collection Andrew maintains, and standard/ could be the XML version of the documentation once I've converted everything (which just shouldn't been in src/ to begin with). The documentation tools would become a separate component (which I've been thinking about for a while now), used by both the standard documentation and the howtos. Another option would be to simply create a new SourceForge project for HOWTO documents. That would be Andrew's baby, so would have to be his preferred approach. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr at thyrsus.com Fri Jul 28 16:21:09 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 10:21:09 -0400 Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: ; from moshez@math.huji.ac.il on Fri, Jul 28, 2000 at 04:45:20PM +0300 References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> Message-ID: <20000728102109.B14644@thyrsus.com> Moshe Zadka : > Neither of those reasons are enough not to put the HOWTOs in the CVS tree. > Editors can keep the version in the CVS current via the patch manager, > and release them as they need to. However, people who d/l Python will > automatically download the HOWTOs. Think of perldoc lol (lists of lists) > -- definitely "HOWTO" material, but in the Perl standard docs. I agree. There should be a HOWTO directory in the CVS tree. -- Eric S. Raymond Strict gun laws are about as effective as strict drug laws...It pains me to say this, but the NRA seems to be right: The cities and states that have the toughest gun laws have the most murder and mayhem. -- Mike Royko, Chicago Tribune From esr at thyrsus.com Fri Jul 28 16:26:23 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 10:26:23 -0400 Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <14721.37704.872570.141761@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jul 28, 2000 at 10:06:00AM -0400 References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> <14721.37704.872570.141761@cj42289-a.reston1.va.home.com> Message-ID: <20000728102623.D14644@thyrsus.com> Fred L. Drake, Jr. : > I'm happy to have them under CVS; I think the big issue is *where*. > I'm not convinced they belong in the same portion of the tree as the > standard documentation. > Here's a thought: we currently have > > dist/ > src/ > Doc/ > > Instead, we could have: > > dist/ > docs/ > howto/ > standard/ > src/ > > The howto/ tree could be the howto collection Andrew maintains, and > standard/ could be the XML version of the documentation once I've > converted everything (which just shouldn't been in src/ to begin > with). This seems eminently reasonable to me. -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. From akuchlin at mems-exchange.org Fri Jul 28 16:21:32 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 28 Jul 2000 10:21:32 -0400 Subject: [Python-Dev] Howto docs In-Reply-To: <14721.37704.872570.141761@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jul 28, 2000 at 10:06:00AM -0400 References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> <14721.37704.872570.141761@cj42289-a.reston1.va.home.com> Message-ID: <20000728102132.A29083@kronos.cnri.reston.va.us> On Fri, Jul 28, 2000 at 10:06:00AM -0400, Fred L. Drake, Jr. wrote: > Instead, we could have: > dist/ > docs/ > howto/ > standard/ > src/ If you want to do this reorganization, fine, but it seems like it'll be a long way off. Why not just put them in nondist/doc/howto? (Other documentation could be put in nondist/doc -- I could even dig out the grimoire and add it, if someone would be interested in updating and maintaining it.) On the other hand, the documentation maintainers might be a different set of people from code maintainers, and we might not want them checking in code changes, so having the docs as a completely separate project would allow finer control of this. On the third hand, we do have the python-checkins list to keep an eye on what's happening. I'd vote for nondist/doc/howto. --amk From esr at thyrsus.com Fri Jul 28 16:32:56 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 10:32:56 -0400 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007281505.KAA04865@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Fri, Jul 28, 2000 at 10:05:48AM -0500 References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> Message-ID: <20000728103256.E14644@thyrsus.com> Guido van Rossum : > > Which makes me think that, if we want to do something about cache effects, > > it is probably not a bad idea to just "reorder" the bytecodes in the big > > switch by decreasing frequency (we have some stats about this -- I believe > > Skip and MAL have discussed the opcodes' frequency and the charts lie > > somewhere in the archives). I remember Marc-Andre had done something in > > this direction and reported some perf improvements too. Since reordering > > the opcodes doesn't really hurt, if I'm about to do something with the > > main loop, it'll be only this. > > Go for it -- sounds good! Allow me to also suggest liberal use of "inline" for small helper functions called from within the main interpreter loop. The nonlocality produced by subroutine calls plays hell with small caches. Side observation: the fact that micro-optimizations are giving us measurable speedups tells us that the higher-level architecture and algoirithms are very well tuned. Take a bow, Guido! -- Eric S. Raymond "Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action." -- George Washington, in a speech of January 7, 1790 From esr at thyrsus.com Fri Jul 28 16:42:23 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 10:42:23 -0400 Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jul 28, 2000 at 09:24:41AM -0400 References: <20000727173859.A10337@thyrsus.com> <20000728083419.B10938@newcnri.cnri.reston.va.us> <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> Message-ID: <20000728104223.G14644@thyrsus.com> Fred L. Drake, Jr. : > curses.textbox should be documented in a \section like any other > module. It can be placed in libcurses.tex along with the other > curses-related modules. Ah! I didn't realize multiple suggestions could live in the same file under our conventions. Guess I'll have to go reread the Documentation HOWTO. > Is curses.wrapper documented, or is it an implementation detail? I'll document it. -- Eric S. Raymond No matter how one approaches the figures, one is forced to the rather startling conclusion that the use of firearms in crime was very much less when there were no controls of any sort and when anyone, convicted criminal or lunatic, could buy any type of firearm without restriction. Half a century of strict controls on pistols has ended, perversely, with a far greater use of this weapon in crime than ever before. -- Colin Greenwood, in the study "Firearms Control", 1972 From mal at lemburg.com Fri Jul 28 16:39:21 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 16:39:21 +0200 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> <200007281238.HAA04294@cj20424-a.reston1.va.home.com> Message-ID: <39819B19.F5624BD0@lemburg.com> Guido van Rossum wrote: > > > > IIRC ActiveState contributed to Perl a version of fork that works > > > on Win32. Has anyone looked at this? Could it be grabbed for > > > Python? This would help heal one of the more difficult platform > > > rifts. Emulating fork for Win32 looks quite difficult to me but if > > > its already done... > > > This would indeed be a *very* useful addition and help porting > > os.fork() applications to Win32. (Ok, in the long run they would > > have to be converted to multi-threaded apps due to the process > > creation overhead on Win32, but for short term porting to Win32 > > this would be a Cool Thing, IMHO.) > > I have only one word: yuck! > > Portable Python code should not rely on fork. I wasn't talking about "portable" code, but about "porting" code to Win32. I happen to use an application which manages a few processes and spawns these using .fork(). It would nice to have a .fork() like API on Win32 to experiment with. Anyway, I would already be happy if I could just look at the code from ActiveState... if it's Perl all the way I probably don't want to look any further into this ;-) BTW, I'm not too familiar with IPC on Win32. What would be the best strategy to this on the Windows platforms ? I remember that Skip once posted a comparison of Unix Domain sockets and TCP Sockets on Unix which showed that UD sockets are much faster than TCP sockets. On Win32 these don't exist and I suppose that TCP sockets are too slow for my server. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Fri Jul 28 16:59:57 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 16:59:57 +0200 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> Message-ID: <39819FED.41C11063@lemburg.com> Guido van Rossum wrote: > > > Since we're at it, it's worth mentioning another conclusion we came across > > at the time: the cache effects in the main loop are significant -- it is > > more important to try keeping at best the main loop small enough, so that > > those effects are minimized. > > Yes, that's what Tim keeps hammering on too. +1 from here ;-) I have done quite a bit of testing with the old 1.5 ceval loop (patch still available in case someone wants to look at it) and found these things: 1. It pays off to special case LOAD_FAST by handling it before going into the switch at all, since this is the one most often used opcode in Python. 2. Reordering the opcodes has some noticable effect on performance too, even though it is very touchy to cache lines. 3. Splitting the big switch in two with the first one holding the most of often used opcodes while the second one takes care of the more esoteric ones helps keeping the inner loop in the CPU cache and thus increases performance. From esr at thyrsus.com Fri Jul 28 17:26:46 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 28 Jul 2000 11:26:46 -0400 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <39819FED.41C11063@lemburg.com>; from mal@lemburg.com on Fri, Jul 28, 2000 at 04:59:57PM +0200 References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> Message-ID: <20000728112646.A15634@thyrsus.com> M.-A. Lemburg : > LOAD_FAST(124) : 19323126 ================================ > SET_LINENO(127) : 15055591 ======================== > LOAD_CONST(100) : 9254683 =============== > LOAD_NAME(101) : 8218954 ============= > LOAD_GLOBAL(116) : 7174876 =========== > STORE_FAST(125) : 5927769 ========= > POP_TOP( 1) : 5587424 ========= > CALL_FUNCTION(131) : 5404709 ======== > JUMP_IF_FALSE(111) : 5289262 ======== > COMPARE_OP(106) : 4495179 ======= > LOAD_ATTR(105) : 3481878 ===== > BINARY_ADD( 23) : 3420811 ===== > RETURN_VALUE( 83) : 2221212 === > STORE_NAME( 90) : 2176228 === > STORE_ATTR( 95) : 2085338 === > BINARY_SUBSCR( 25) : 1834612 === > JUMP_ABSOLUTE(113) : 1648327 == > STORE_SUBSCR( 60) : 1446307 == > JUMP_FORWARD(110) : 1014821 = > BINARY_SUBTRACT( 24) : 910085 = > POP_BLOCK( 87) : 806160 = > STORE_GLOBAL( 97) : 779880 = > FOR_LOOP(114) : 735245 = > SETUP_LOOP(120) : 657432 = > BINARY_MODULO( 22) : 610121 = > 32( 32) : 530811 > 31( 31) : 530657 > BINARY_MULTIPLY( 20) : 392274 > SETUP_EXCEPT(121) : 285523 Some thoughts: 1. That looks as close to a Poisson distribution as makes no difference. I wonder what that means? 2. Microtuning in the implementations of the top 3 opcodes looks indicated, as they seem to constitute more than 50% of all calls. 3. On the other hand, what do you get when you weight these by average time per opcode? -- Eric S. Raymond "The bearing of arms is the essential medium through which the individual asserts both his social power and his participation in politics as a responsible moral being..." -- J.G.A. Pocock, describing the beliefs of the founders of the U.S. From thomas at xs4all.net Fri Jul 28 17:32:56 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 17:32:56 +0200 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <20000728112646.A15634@thyrsus.com>; from esr@thyrsus.com on Fri, Jul 28, 2000 at 11:26:46AM -0400 References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <20000728112646.A15634@thyrsus.com> Message-ID: <20000728173256.C266@xs4all.nl> On Fri, Jul 28, 2000 at 11:26:46AM -0400, Eric S. Raymond wrote: > > LOAD_FAST(124) : 19323126 ================================ > > SET_LINENO(127) : 15055591 ======================== > 1. That looks as close to a Poisson distribution as makes no difference. > I wonder what that means? It means there's still room for optimization! Other than that, probably not much. I also think that the similarity vanishes if you take into account that SET_LINENO does nothing, and LOAD_FAST is a basic operation and should be grouped with LOAD_NAME and LOAD_GLOBAL. > 2. Microtuning in the implementations of the top 3 opcodes looks indicated, > as they seem to constitute more than 50% of all calls. Actually, I believe there was talk of removing SET_LINENO altogether... or am I mistaken in that ? In any case, you can do it by using -OO. > 3. On the other hand, what do you get when you weight these by average > time per opcode? My guess is that *_NAME moves on up, as they already are pretty high up, and BINARY_* and UNARY_*, go *way* up: imagine all those classes that implement __add__ and __not__. Even if you have but a few of those calls, they effectively are (Python) function calls. In other words, those are pretty meaningless. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov at inrialpes.fr Fri Jul 28 17:47:50 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 17:47:50 +0200 (CEST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <39819FED.41C11063@lemburg.com> from "M.-A. Lemburg" at Jul 28, 2000 04:59:57 PM Message-ID: <200007281547.RAA06456@python.inrialpes.fr> M.-A. Lemburg wrote: > > If you need help, I can dig up those old tools and patches... Yes, please do. I think I'll come up with a patch posted to SF for your collective review. [Eric Reymond, on opcode stats by MAL] > > LOAD_FAST(124) : 19323126 ================================ > > SET_LINENO(127) : 15055591 ======================== > > LOAD_CONST(100) : 9254683 =============== > > LOAD_NAME(101) : 8218954 ============= > > ... > > Some thoughts: > > 1. That looks as close to a Poisson distribution as makes no difference. > I wonder what that means? Well, it's difficult to say what this means without looking at the tools that were used to generate these stats. > > 2. Microtuning in the implementations of the top 3 opcodes looks indicated, > as they seem to constitute more than 50% of all calls. Imagine what will happen if SET_LINENO disappears But this is very tricky business which is more complicated than it looks like... > > 3. On the other hand, what do you get when you weight these by average > time per opcode? I haven't run 100M opcodes, but you may want to have a look at some old micro-profiling I did long time ago: http://starship.python.net/~vlad/tprof/ The relevant file for the main loop is: http://starship.python.net/~vlad/tprof/pybench-0.6/python-151-orig-thr/__t.eval_code2_ceval.c I am not sure this makes any sense by now, though. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Fri Jul 28 18:07:21 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 18:07:21 +0200 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <20000728112646.A15634@thyrsus.com> Message-ID: <3981AFB9.26AEB1D1@lemburg.com> "Eric S. Raymond" wrote: > > M.-A. Lemburg : > > LOAD_FAST(124) : 19323126 ================================ > > SET_LINENO(127) : 15055591 ======================== > > LOAD_CONST(100) : 9254683 =============== > > LOAD_NAME(101) : 8218954 ============= > > LOAD_GLOBAL(116) : 7174876 =========== > > STORE_FAST(125) : 5927769 ========= > > POP_TOP( 1) : 5587424 ========= > > CALL_FUNCTION(131) : 5404709 ======== > > JUMP_IF_FALSE(111) : 5289262 ======== > > COMPARE_OP(106) : 4495179 ======= > > LOAD_ATTR(105) : 3481878 ===== > > BINARY_ADD( 23) : 3420811 ===== > > RETURN_VALUE( 83) : 2221212 === > > STORE_NAME( 90) : 2176228 === > > STORE_ATTR( 95) : 2085338 === > > BINARY_SUBSCR( 25) : 1834612 === > > JUMP_ABSOLUTE(113) : 1648327 == > > STORE_SUBSCR( 60) : 1446307 == > > JUMP_FORWARD(110) : 1014821 = > > BINARY_SUBTRACT( 24) : 910085 = > > POP_BLOCK( 87) : 806160 = > > STORE_GLOBAL( 97) : 779880 = > > FOR_LOOP(114) : 735245 = > > SETUP_LOOP(120) : 657432 = > > BINARY_MODULO( 22) : 610121 = > > 32( 32) : 530811 > > 31( 31) : 530657 > > BINARY_MULTIPLY( 20) : 392274 > > SETUP_EXCEPT(121) : 285523 > > Some thoughts: > > 1. That looks as close to a Poisson distribution as makes no difference. > I wonder what that means? I'd say that there are good chances on applying optimizations to the Python byte code -- someone with enough VC should look into this on a serious basis ;-) I think that highly optimized Python byte code compilers/ interpreters would make nice commercial products which complement the targetted Python+Batteries distros. > 2. Microtuning in the implementations of the top 3 opcodes looks indicated, > as they seem to constitute more than 50% of all calls. Separating out LOAD_FAST from the switch shows a nice effect. SET_LINENO is removed by -OO anyway, so there's really no use in optimizing this one. In my hacked up version I've also moved the signal handler into the second switch (along with SET_LINENO). The downside of this is that your program will only "see" signals if it happens to execute one of the less common opcodes, on the plus side you get an additional boost in performance -- if your app doesn't rely on signals to work, this is also a great way to squeeze out a little more performance. > 3. On the other hand, what do you get when you weight these by average > time per opcode? Haven't tested this, but even by simply reordering the cases according to the above stats you get a positive response from pybench and pystone. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at mems-exchange.org Fri Jul 28 18:13:12 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 28 Jul 2000 12:13:12 -0400 Subject: [Python-Dev] Reordering opcodes In-Reply-To: <3981AFB9.26AEB1D1@lemburg.com>; from mal@lemburg.com on Fri, Jul 28, 2000 at 06:07:21PM +0200 References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <20000728112646.A15634@thyrsus.com> <3981AFB9.26AEB1D1@lemburg.com> Message-ID: <20000728121312.E29083@kronos.cnri.reston.va.us> On Fri, Jul 28, 2000 at 06:07:21PM +0200, M.-A. Lemburg wrote: >I'd say that there are good chances on applying optimizations >to the Python byte code -- someone with enough VC should look >into this on a serious basis ;-) At OLS I saw David S. Miller's keynote. Miller's been a Linux kernel hacker for quite a long time, and has been responsible for much of the Sparc and MIPS port, maintains the networking stack, etc. In his talk he mentioned that occasionally he gets really tired of kernel-space work, and has to do something in user-space for a change of pace; in that vein he rewrote GCC's Sparc64 backend, and recently wrote an nVidia driver for XFree86. My first thought when he said that was "Gosh, he should look at ceval.c!" --amk From billtut at microsoft.com Fri Jul 28 18:42:56 2000 From: billtut at microsoft.com (Bill Tutt) Date: Fri, 28 Jul 2000 09:42:56 -0700 Subject: [Python-Dev] UTF-16 code point comparison Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD34D@RED-MSG-50> > From: Tim Peters [mailto:tim_one at email.msn.com] > [Tim] > > ... Don't know how long it will take this half of the world to > > realize it, but UCS-4 is inevitable. > > [Bill Tutt] > > On new systems perhaps, but important existing systems (Win32, > > and probably Java) are stuck with that bad decision and have to > > use UTF-16 for backward compatability purposes. > Somehow that doesn't strike me as a good reason for Python to mimic them > . So don't. If you think UTF-16 is yet another bad engineering decision, then take the hit now of making Python's unicode support natively UCS-4 so we don't have a backward compatability problem when the next Unicode or ISO 10646 revision comes out. Just realize and accept the cost of doing so. (constant conversions for a nice big chunk of your users.) > > Surrogates aren't as far out as you might think. (The next rev of > > the Unicode spec) > But indeed, that's the *point*: they exhausted their 64K space in just a > few years. Now the same experts say that adding 4 bits to the range will > suffice for all time; I don't buy it; they picked 4 bits because that's what > the surrogate mechanism was defined earlier to support. I don't think the experts are saying the extra 4 bits will suffice for all time, but it should certainly suffice until we meet aliens form a different planet. :) > > That's certainly sooner than Win32 going away. :) > I hope it stays around forever -- it's a great object lesson in what > optimizing for yesterday's hardware can buy you . Heh. A dev manager from Excel made the exact same comment to me just yesterday. :) Bill From thomas at xs4all.net Fri Jul 28 18:45:12 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 18:45:12 +0200 Subject: [Python-Dev] buglet in unary ops on classes. Message-ID: <20000728184512.D266@xs4all.nl> While poking around looking for something else, I found this little buglet: >>> class X: ... def __getattr__(self, val): ... print "getattr:", val ... raise AttributeError >>> x = X() >>> ~x getattr: __invert__ Traceback (most recent call last): File "", line 1, in ? File "", line 4, in __getattr__ AttributeError The unary ops all do this (raising AttributeError), but the binary ops do not: >>> x+1 getattr: __coerce__ getattr: __add__ Traceback (most recent call last): File "", line 1, in ? TypeError: __add__ nor __radd__ defined for these operands Shouldn't this translation be done for unary ops as well ? Is it safe to assume that instance_getattr() only returns NULL if the attribute is not found ? PyInstance_DoBinOp() takes this assumption wrt. PyObject_GetAttr(), and I don't really see a problem with it. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Vladimir.Marangozov at inrialpes.fr Fri Jul 28 19:01:31 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 19:01:31 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <3981AFB9.26AEB1D1@lemburg.com> from "M.-A. Lemburg" at Jul 28, 2000 06:07:21 PM Message-ID: <200007281701.TAA06630@python.inrialpes.fr> M.-A. Lemburg wrote: > > Separating out LOAD_FAST from the switch shows a nice effect. > SET_LINENO is removed by -OO anyway, so there's really no > use in optimizing this one. Actually, I think that instead of fighting with SET_LINENO for the standard setup, it would make sense to change the invocation options to something more standard: 1) python - code without SET_LINENO 2) python -g - code for debugging, with SET_LINENO 3) python -O - code without doc-strings. The point is that currently there's no optimization of the code stream at all, in the sense of classic compiler optimization (code block-level optimizations, loop unrolling, etc). And SET_LINENO is actually useful only for debugging (with pdb, etc). What about this as a sane proposal for SET_LINENO? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From trentm at ActiveState.com Fri Jul 28 19:10:15 2000 From: trentm at ActiveState.com (Trent Mick) Date: Fri, 28 Jul 2000 10:10:15 -0700 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) In-Reply-To: <39815E94.462F65EF@lemburg.com> References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> Message-ID: <20000728101015.A6542@ActiveState.com> On Fri, Jul 28, 2000 at 12:21:08PM +0200, M . -A . Lemburg wrote: > > > > IIRC ActiveState contributed to Perl a version of fork that works on > > Win32. Has anyone looked at this? Could it be grabbed for Python? This would > > help heal one of the more difficult platform rifts. Emulating fork for Win32 > > looks quite difficult to me but if its already done... > > This would indeed be a *very* useful addition and help porting > os.fork() applications to Win32. (Ok, in the long run they would > have to be converted to multi-threaded apps due to the process > creation overhead on Win32, but for short term porting to Win32 > this would be a Cool Thing, IMHO.) > > Can this code be grabbed from somewhere ? > It is all in ActivePerl. You can download the source code: http://www.activestate.com/Products/ActivePerl/Download.html Besides, I would guess (and I *am* guessing, I don't know this) that the Perl fork stuff is fairly closely tied to Perl, i.e. it may not be easy at all to yank it out and plug it into Python. However, I echo the Bill's and Guido's sentiments. Having a hacked emulation of fork encourages people to use it. Once someone has their favorite UNIX app it running on Win32 with the fake-fork they will have little incentive to port it properly using threads. There will then be calls to improve to Win32 fork implementation... and that is the wrong support path. Trent -- Trent Mick TrentM at ActiveState.com From mal at lemburg.com Fri Jul 28 20:12:48 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 28 Jul 2000 20:12:48 +0200 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> <20000728101015.A6542@ActiveState.com> Message-ID: <3981CD20.BD53BFF0@lemburg.com> Trent Mick wrote: > > On Fri, Jul 28, 2000 at 12:21:08PM +0200, M . -A . Lemburg wrote: > > > > > > IIRC ActiveState contributed to Perl a version of fork that works on > > > Win32. Has anyone looked at this? Could it be grabbed for Python? This would > > > help heal one of the more difficult platform rifts. Emulating fork for Win32 > > > looks quite difficult to me but if its already done... > > > > This would indeed be a *very* useful addition and help porting > > os.fork() applications to Win32. (Ok, in the long run they would > > have to be converted to multi-threaded apps due to the process > > creation overhead on Win32, but for short term porting to Win32 > > this would be a Cool Thing, IMHO.) > > > > Can this code be grabbed from somewhere ? > > > > It is all in ActivePerl. You can download the source code: > > http://www.activestate.com/Products/ActivePerl/Download.html Thanks. > Besides, I would guess (and I *am* guessing, I don't know this) that the Perl > fork stuff is fairly closely tied to Perl, i.e. it may not be easy at all to > yank it out and plug it into Python. > > However, I echo the Bill's and Guido's sentiments. Having a hacked > emulation of fork encourages people to use it. Once someone has their > favorite UNIX app it running on Win32 with the fake-fork they will have > little incentive to port it properly using threads. There will then be calls > to improve to Win32 fork implementation... and that is the wrong support > path. You're probably right... :-/ BTW, (pardon my ignorance) what is the most portable way to do the equivalent of a os.system("cmd &") as native OS API call ? [On Unix, "cmd &" starts a new process which runs in the background and detached from the calling process.] I've looked at .execve and .spawnve, but they both replace the current process. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Fri Jul 28 20:33:38 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 28 Jul 2000 20:33:38 +0200 Subject: [Python-Dev] Fork on Win32 - was (test_fork1 failing...) References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> <20000728101015.A6542@ActiveState.com> <3981CD20.BD53BFF0@lemburg.com> Message-ID: <008d01bff8c2$5c99f240$f2a6b5d4@hagrid> mal wrote: > BTW, (pardon my ignorance) what is the most portable way to > do the equivalent of a os.system("cmd &") as native OS > API call ? [On Unix, "cmd &" starts a new process which runs > in the background and detached from the calling process.] > > I've looked at .execve and .spawnve, but they both replace > the current process. on windows, spawn(P_NOWAIT) does what you want. here's an example from the eff-bot guide: # # os-spawn-example-2.py import os import string def run(program, *args, **kw): # find executable mode = kw.get("mode", os.P_WAIT) for path in string.split(os.environ["PATH"], os.pathsep): file = os.path.join(path, program) + ".exe" try: return os.spawnv(mode, file, (file,) + args) except os.error: pass raise os.error, "cannot find executable" run("python", "hello.py", mode=os.P_NOWAIT) From Vladimir.Marangozov at inrialpes.fr Fri Jul 28 21:24:36 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 21:24:36 +0200 (CEST) Subject: [Python-Dev] further optimising the micro-optimisations for cache locality (fwd) Message-ID: <200007281924.VAA06918@python.inrialpes.fr> FYI. It would be interesting to collect some feedback on these ideas for popular combos. Who knows... Forwarded message: > From morton at dennisinter.com Fri Jul 28 20:48:29 2000 > From: morton at dennisinter.com (Damien Morton) > To: > Subject: further optimising the micro-optimisations for cache locality > Date: Fri, 28 Jul 2000 14:34:29 -0400 > Message-ID: > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > Importance: Normal > > Folded version: > > case BINARY_ADD: > w = POP(); > v = POP(); > x = PyNumber_Add(v, w); > goto end_binop; > > case BINARY_MULTIPLY: > w = POP(); > v = POP(); > x = PyNumber_Multiply(v, w); > goto end_binop; > > ... > end_binop: > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > > Further folded version: > > > > case BINARY_POWER: > f = PyNumber_Add; > goto do_binop; > > case BINARY_MULTIPLY: > f = PyNumber_Multiply; > goto do_binop; > > ... > do_binop: > w = POP(); > v = POP(); > x = f(v, w); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > > Further Further folded version: > (i havent looked at the mainloop code, but can guess its structure) > > i assume 'op' is the opcode we are swtching on > > // the function to call for this op > (void *)() op_func[] = { ..., PyNumber_Add, PyNumber_Multiply, ... }; > > // the kind of op this func describes > unsigned char op_type[] = { ..., DO_BINOP1, DO_BINOP2, DO_UNOP, ... }; > > // these two tables will be cached because of the frequency the are accessed > // ive used a table of pointers and a table of bytes to reduce the memory > required > // because the tables are small, locality within and between the tables isnt > important > // might be an idea to force the tables into contiguous memory somehow > // i could also have used a table of structs, but alignment would increase > memory usage > > unsigned char op; > > switch(op_type[op]) { > case DO_BINOP1: > w = POP(); > v = POP(); > x = op_func[op](v, w); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > case DO_BINOP2: > w = POP(); > v = POP(); > x = op_func[op](v, w, Py_None); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > case DO_UNOP: > v = POP(); > x = op_func[op](v); > Py_DECREF(v); > PUSH(x); > if (x != NULL) continue; > break; > > ===================== original message ================================= > Guido van Rossum wrote: > > > > > [me, on micro-optimizing the main loop] > > > > Fair enough (for one particular CPU at least). > > Since we're at it, it's worth mentioning another conclusion we came across > at the time: the cache effects in the main loop are significant -- it is > more important to try keeping at best the main loop small enough, so that > those effects are minimized. > > An experiment I did at the time which gave some delta-speedup: > I folded most of the UNOP & BINOP opcodes since they differ only by the > functon they call and they duplicate most of the opcode body. Like this: > > Original: > case BINARY_POWER: > w = POP(); > v = POP(); > x = PyNumber_Power(v, w, Py_None); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > > case BINARY_MULTIPLY: > w = POP(); > v = POP(); > x = PyNumber_Multiply(v, w); > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > ... > > > Folded version: > > case BINARY_POWER: > w = POP(); > v = POP(); > x = PyNumber_Power(v, w, Py_None); > goto end_binop; > > case BINARY_MULTIPLY: > w = POP(); > v = POP(); > x = PyNumber_Multiply(v, w); > goto end_binop; > > ... > end_binop: > Py_DECREF(v); > Py_DECREF(w); > PUSH(x); > if (x != NULL) continue; > break; > > > This reduced the code size of ceval.c, which resulted in less cache effects > and gave more speed, despite the additional jumps. It possibly results in > less page-faults too, although this is unlikely. > > Which makes me think that, if we want to do something about cache effects, > it is probably not a bad idea to just "reorder" the bytecodes in the big > switch by decreasing frequency (we have some stats about this -- I believe > Skip and MAL have discussed the opcodes' frequency and the charts lie > somewhere in the archives). I remember Marc-Andre had done something in > this direction and reported some perf improvements too. Since reordering > the opcodes doesn't really hurt, if I'm about to do something with the > main loop, it'll be only this. > > > > > > Micro-optimization doesn't worth the effort. As to the 2-byte arg limit, > > > I think I'd be happy if the compiler raises an exception if this limit > > > is exceeded. > > > > That would be a good first step indeed! > > I'll try to have a look, if someone else is not more reactive than me. > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 > -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From thomas at xs4all.net Fri Jul 28 21:41:54 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 28 Jul 2000 21:41:54 +0200 Subject: [Python-Dev] further optimising the micro-optimisations for cache locality (fwd) In-Reply-To: <200007281924.VAA06918@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Fri, Jul 28, 2000 at 09:24:36PM +0200 References: <200007281924.VAA06918@python.inrialpes.fr> Message-ID: <20000728214154.G266@xs4all.nl> On Fri, Jul 28, 2000 at 09:24:36PM +0200, Vladimir Marangozov wrote: > It would be interesting to collect some feedback on these ideas for > popular combos. Who knows... I like these ideas, though I think anything beyond 'further folded' requires a seperate switch for the non-common operators and those that do a tad more than call a function with a certain number of arguments and push the result on the stack. Re-numbering the ops into fast-ops and slow-ops, as well as argument-ops and nonargument-ops. (I hope all non-argument ops fall in the 'fast' category, or it might get tricky ;-P) I'm also wondering whether they really speed things up. The confusion might force the compiler to generate *less* efficient code. Then again, it removes some of the burden from the compiler, too, so it probably depends very heavily on the compiler whether this is going to have a positive effect. > > // the function to call for this op > > (void *)() op_func[] = { ..., PyNumber_Add, PyNumber_Multiply, ... }; > > > > // the kind of op this func describes > > unsigned char op_type[] = { ..., DO_BINOP1, DO_BINOP2, DO_UNOP, ... }; > > > > // these two tables will be cached because of the frequency the are > > // accessed > > // ive used a table of pointers and a table of bytes to reduce the > > // memory required because the tables are small, locality within and > > // between the tables isnt important > > // might be an idea to force the tables into contiguous memory somehow > > // i could also have used a table of structs, but alignment would > > // increase memory usage I'm not so sure about any of these comments, given that we do jump to a function right after accessing these tables. I suggest heavy testing, and I can offer only two architectures myself (linux-i386 and solaris-sparc-gcc.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From trentm at activestate.com Fri Jul 28 22:02:07 2000 From: trentm at activestate.com (Trent Mick) Date: Fri, 28 Jul 2000 13:02:07 -0700 Subject: [Python-Dev] build problems under MSVC 5.0 In-Reply-To: <019e01bfe1ec$728c6c00$f2a6b5d4@hagrid> References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> <20000629095343.B21926@activestate.com> <019e01bfe1ec$728c6c00$f2a6b5d4@hagrid> Message-ID: <20000728130207.A7348@ActiveState.com> On Thu, Jun 29, 2000 at 07:07:02PM +0200, Fredrik Lundh wrote: > trent wrote: > > I think (am I wrong?) to generalize that the intention for both Win32 and > > Win64 is to have _beginthread return an unsigned pointer-sized integer: hence > > uintptr_t. > > > > This would eliminate the #ifdef but would require a typedef for uintptr_t on > > Win32. This can be done in PC/config.h (I already did this for intptr_t, > > because I needed *that* elsewhere.) Does this also need to be generalized to > > typedef uintptr_t whereever it is not defined, i.e. in the autoconf files. > > > > I can look at this this weekend, if that is soon enough. > > I suggest checking in the #ifdef as a stopgap measure, if you > promise to come up with the right thing (whatever that is) in > time for 1.6 final. > > Should I go ahead and check it in? > Fredrik, I have put the "right thing" (I hope) up on SourceForge and assigned it to you: http://sourceforge.net/patch/?func=detailpatch&patch_id=101010&group_id=5470 I explained what I think is the right idea in the preceeding email in this thread: http://www.python.org/pipermail/python-dev/2000-June/011800.html Could you try the patch and then assign it back to me for check in? (Or just check it in yourself) Thanks, Trent -- Trent Mick TrentM at ActiveState.com From Vladimir.Marangozov at inrialpes.fr Fri Jul 28 22:20:02 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 28 Jul 2000 22:20:02 +0200 (CEST) Subject: [Python-Dev] further optimising the micro-optimisations for cache locality (fwd) In-Reply-To: <20000728214154.G266@xs4all.nl> from "Thomas Wouters" at Jul 28, 2000 09:41:54 PM Message-ID: <200007282020.WAA07138@python.inrialpes.fr> Thomas Wouters wrote: > > On Fri, Jul 28, 2000 at 09:24:36PM +0200, Vladimir Marangozov wrote: > > > It would be interesting to collect some feedback on these ideas for > > popular combos. Who knows... > > I like these ideas, though I think anything beyond 'further folded' requires > a seperate switch for the non-common operators and those that do a tad more > than call a function with a certain number of arguments and push the result > on the stack. I agree. Note that all we can get though this game is some dubious percents that we shouldn't ignore, but which persistency in the long term is quite questionable. There's no way that, to pick a guy at random, Tim won't confirm this! And just like Guido, I'm not ready to trade code cleanliness for dubious speed. However, I take the opportunity to invite you again to "heavy test" the object allocator's candidate -- obmalloc.c, which, in my educated understanding of the current C implementation is the only piece of code that is capable of increasing Python's overall performance by > 10% assuming that your script involves object allocations. It is my strong belief that this perfomance comes for free, by instrumenting Python at its most inner internals, not on top of it! Of course, improvements to this code are welcome and I'd be happy to discuss them in this forum. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mwh21 at cam.ac.uk Fri Jul 28 22:58:11 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 28 Jul 2000 21:58:11 +0100 Subject: [Python-Dev] extended slicing for lists In-Reply-To: Michael Hudson's message of "27 Jul 2000 21:41:02 +0100" References: <200007271412.JAA12251@cj20424-a.reston1.va.home.com> Message-ID: Michael Hudson writes: > Guido van Rossum writes: > > > > Good idea. Are lists and tuples going to support seq[a:b:c] anytime > > > soon? > > > > It's on my wish list, but can't be done for 2.0. > > This would involve the list type implementing the mapping API wouldn't > it? This would seem to be a little on the silly side. Never mind; > here's a quick-hack patch that "seems to work" for lists: [snip] I've now put this (or a slightly less buggy version) onto sourceforge. Guido said (after I bothered him in private email) that he'd expect that: >>> l = range(10) >>> l[2:10:2] = [0]*5 >>> l [0, 1, 0, 3, 0, 5, 0, 7, 0, 9] >>> And also: >>> l = range(10) >>> l[4:-1:-1] = range(5) >>> l [4, 3, 2, 1, 0, 5, 6, 7, 8, 9] >>> (and presumably del l[a:b:c]) Now I'd expect *that* as well, but I was wondering what should happen if the lengths of the lists don't match up ... just bail? That would be easiest, but it doesn't quite gel well with current behaviour for simple slices. Presuming an error, what about these (assuming d is a list of the wrong length): l[a:b:-1] = d l[a:b:1] = d l[a:b:] = d I think these should probably be errors too, but I'd welcome any opinions people have. Cheers, M. -- A witty saying proves nothing. -- Voltaire From bwarsaw at beopen.com Fri Jul 28 23:24:57 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 28 Jul 2000 17:24:57 -0400 (EDT) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> Message-ID: <14721.64041.139313.716754@anthem.concentric.net> >>>>> "M" == M writes: M> These stats were created using an instrumented Python M> interpreter running real applications (and recording all M> executed opcodes to a file), so they can be considered close M> enough to what Python typically does in its inner loop. M> If you need help, I can dig up those old tools and patches... If you can update them for the current CVS, I'd suggest uploading them to SF. I'd then be willing to run Mailman for a while on an instrumented Python to see what it does. -Barry From guido at beopen.com Sat Jul 29 04:02:38 2000 From: guido at beopen.com (Guido van Rossum) Date: Fri, 28 Jul 2000 21:02:38 -0500 Subject: [Python-Dev] Python License News Message-ID: <200007290202.VAA05626@cj20424-a.reston1.va.home.com> Bob Weiner (BeOpen's CTO, my boss) told me that he's very close to reaching a compromise with CNRI about the new Python license. There's only one remaining issue before Richard Stallman is willing to declare the license GPL-compatible. We expect that this wrinkle will be worked out with CNRI's president Bob Kahn on Monday. Tim Peters knows more, you just have to ask the right way. :-) Gotta run, --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From mhammond at skippinet.com.au Sat Jul 29 05:07:38 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 29 Jul 2000 13:07:38 +1000 Subject: [Python-Dev] Python License News In-Reply-To: <200007290202.VAA05626@cj20424-a.reston1.va.home.com> Message-ID: [Trimmed to list for the sake of Tim's modesty] > Tim Peters knows more, you just have to ask the right way. :-) Tim - tell us about your testicles again! Is-that-correct-ly, Mark. From fdrake at beopen.com Sat Jul 29 06:05:17 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 29 Jul 2000 00:05:17 -0400 (EDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <20000728104223.G14644@thyrsus.com> References: <20000727173859.A10337@thyrsus.com> <20000728083419.B10938@newcnri.cnri.reston.va.us> <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> <20000728104223.G14644@thyrsus.com> Message-ID: <14722.22525.140359.615231@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Ah! I didn't realize multiple suggestions could live in the same file > under our conventions. Guess I'll have to go reread the Documentation > HOWTO. Multiple sections can live in the same file if they are sufficiently tightly related. For example, curses and curses.ascii, pyexpat and pyexpat.errors, pickle and cPickle, StringIO and cStringIO. I don't know that this is discussed in "Documenting Python," but should be; I'll fix that for Python 2.0. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Sat Jul 29 08:14:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 29 Jul 2000 02:14:18 -0400 Subject: [Python-Dev] Python License News In-Reply-To: Message-ID: [Guido] > Tim Peters knows more, you just have to ask the right way. :-) [Mark Hammond] > Tim - tell us about your testicles again! > > Is-that-correct-ly, Works for me. I had thought they were permanently enlarged, but I detect signs that, should the temperature in Virginia ever fall below 80F, and the relative humidity below a gazillion or two percent, they may return to a familiar state. I grew up in a cold climate, and this may just be a bizarre attempt to shed excess heat. I expect to set up a home page soon with a charming and practical photographic essay on this topic . As to the Python license, Guido said > We expect that this wrinkle will be worked out with CNRI's > president Bob Kahn on Monday. and given the history of this I'd rather wait until then to see whether expectations pan out -- and discussing the license before we're allowed to *show* it would be frustrating for everyone anyway. That said, this is certainly a harder license for a non-lawyer to understand than was the CWI license, but I expect CNRI would counter that their license is more likely than CWI's to stand up in court. If such things interest you, feel free to speculate . Some things *everyone* should agree are good: + Eric Raymond informed us that the board of the Open Source Initiative had voted to certify the license as fully Open Source compliant. http://www.opensource.org/osd.html That was a happy day! But it's already become a slightly different license than they voted on, so I bet we have to seek OSI certification again. + I've seen Richard Stallman's remaining objections, and they're of a technical nature (meaning that to BeOpen PythonLabs they don't seem like they *should* be a sticking point; but CNRI may not agree). As many dozens of current Python projects rely on GPL compatibility, BeOpen will not accept a license that RMS rejects (and, I'll add, he's made the *reasons* for his objections clear, and has gone the extra mile to suggest specific changes). + My previous employers used Python in proprietary ("closed source") ways, and I *believe* the proposed license still allows that. But there are new (relative to the CWI Python license) requirements, and I don't understand what some of the license text means, so don't take my guess on that! Anyone who intends using Python 1.6 or beyond in proprietary ways would be well advised to have their lawyers study the license carefully, as no party to this negotiation was in your shoes or visibly (to me) looking out for you. (And, no, I was not a party to any of it) + There is still no clause specifically prohibiting ActiveState from using Python . Or anyone else. ordered-the-champagne-but-not-drinking-it-yet-ly y'rs - tim From ping at lfw.org Sat Jul 29 08:57:22 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Fri, 28 Jul 2000 23:57:22 -0700 (PDT) Subject: [Python-Dev] extended slicing for lists In-Reply-To: Message-ID: On 28 Jul 2000, Michael Hudson wrote: > >>> l = range(10) > >>> l[2:10:2] = [0]*5 > >>> l > [0, 1, 0, 3, 0, 5, 0, 7, 0, 9] > >>> Hmph. I'd be perfectly comfortable with >>> l[2:10:2] = [0]*5 TypeError: lists cannot assign to stepped slices I can't see this being a commonly desired feature. If it were perfectly clear what should happen in all cases, i'd be okay with it -- but the ambiguity you get when the length of the right side doesn't match the length of the indicated slice is sufficient for me to suggest just dropping it: better to avoid confusion altogether. > (and presumably del l[a:b:c]) That seems reasonable and well-defined. A separate question: does l[::-1] return l reversed? That is, are the defaults for omitted start/end exchanged if step is negative? This would seem to be quite useful -- having to say l[len(l)-1:-1:-1] would be a royal pain. -- ?!ng From moshez at math.huji.ac.il Sat Jul 29 08:51:21 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 29 Jul 2000 09:51:21 +0300 (IDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: <14722.22525.140359.615231@cj42289-a.reston1.va.home.com> Message-ID: On Sat, 29 Jul 2000, Fred L. Drake, Jr. wrote: > > Eric S. Raymond writes: > > Ah! I didn't realize multiple suggestions could live in the same file > > under our conventions. Guess I'll have to go reread the Documentation > > HOWTO. > > Multiple sections can live in the same file if they are sufficiently > tightly related. For example, curses and curses.ascii, pyexpat and > pyexpat.errors, pickle and cPickle, StringIO and cStringIO. > I don't know that this is discussed in "Documenting Python," but > should be; I'll fix that for Python 2.0. Let me just say what Fred said in a different way: from the processing engine POV, there's just *one file* with lots of include directives. The division into file is just to make life easier for us -- so if two sections are related, it's easier to keep them in the same file. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From effbot at telia.com Sat Jul 29 09:42:14 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 29 Jul 2000 09:42:14 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib SimpleHTTPServer.py,1.10,1.11 References: <200007290515.WAA25057@slayer.i.sourceforge.net> Message-ID: <002401bff930$8439f340$f2a6b5d4@hagrid> is it worth replacing a couple of lines of obvious code with a reference to a little-used module? and if I want to, how do I tweak the block size? > *** SimpleHTTPServer.py 2000/05/21 16:25:29 1.10 > --- SimpleHTTPServer.py 2000/07/29 05:15:56 1.11 > *************** > *** 16,19 **** > --- 16,20 ---- > import urllib > import cgi > + import shutil > from StringIO import StringIO > > *************** > *** 152,161 **** > > """ > ! > ! BLOCKSIZE = 8192 > ! while 1: > ! data = source.read(BLOCKSIZE) > ! if not data: break > ! outputfile.write(data) > > def guess_type(self, path): > --- 153,157 ---- > > """ > ! shutil.copyfileobj(source, outputfile) > > def guess_type(self, path): > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins From moshez at math.huji.ac.il Sat Jul 29 09:51:00 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 29 Jul 2000 10:51:00 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib SimpleHTTPServer.py,1.10,1.11 In-Reply-To: <002401bff930$8439f340$f2a6b5d4@hagrid> Message-ID: On Sat, 29 Jul 2000, Fredrik Lundh wrote: > is it worth replacing a couple of lines of obvious code > with a reference to a little-used module? I believe so. So did everyone when the thread came up on Python-Dev a couple of weeks ago -- I haven't followed up with the checkin for so long because of technical problems (AKA lack of computer). > and if I want to, how do I tweak the block size? Just like you would in the old days: subclass SimpleHTTPServer, and substitute the copyfile method with a call to shutil.copyfile with a non-default size. (IOW, it's easier then what it was before). From mwh21 at cam.ac.uk Sat Jul 29 11:07:43 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 29 Jul 2000 10:07:43 +0100 Subject: [Python-Dev] extended slicing for lists In-Reply-To: Ka-Ping Yee's message of "Fri, 28 Jul 2000 23:57:22 -0700 (PDT)" References: Message-ID: The patch is here, btw: http://sourceforge.net/patch/?func=detailpatch&patch_id=100998&group_id=5470 Ka-Ping Yee writes: > On 28 Jul 2000, Michael Hudson wrote: > > >>> l = range(10) > > >>> l[2:10:2] = [0]*5 > > >>> l > > [0, 1, 0, 3, 0, 5, 0, 7, 0, 9] > > >>> > > Hmph. I'd be perfectly comfortable with > > >>> l[2:10:2] = [0]*5 > TypeError: lists cannot assign to stepped slices > > I can't see this being a commonly desired feature. If it > were perfectly clear what should happen in all cases, i'd > be okay with it -- but the ambiguity you get when the length > of the right side doesn't match the length of the indicated > slice is sufficient for me to suggest just dropping it: > better to avoid confusion altogether. Well, the BDFL spoke. > > (and presumably del l[a:b:c]) > > That seems reasonable and well-defined. Yes. > A separate question: does l[::-1] return l reversed? Yes. All that cleverness is in PySlice_GetIndices, so this patch gets it for free. > That is, are the defaults for omitted start/end exchanged if step is > negative? This would seem to be quite useful -- having to say > l[len(l)-1:-1:-1] would be a royal pain. Well, you could probably always say l[sys.maxint:0:-1] (your example returns the empty list!) but yes, I think l[::-1] is one of the neater bits of new behaviour. Cheers, M. -- "declare"? my bogometer indicates that you're really programming in some other language and trying to force Common Lisp into your mindset. this won't work. -- Erik Naggum, comp.lang.lisp From moshez at math.huji.ac.il Sat Jul 29 12:17:14 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 29 Jul 2000 13:17:14 +0300 (IDT) Subject: [Python-Dev] test turds? Message-ID: Hi! Recently I patched a bug in whichdb. Following Tim's advice "each bug we find is a bug in the regression testing", I decided to write a test case for whichdb. However, the problem is that I'm not sure where I can create files, which must not be leftovers from the test suite. Does anyone know of a test which creates files, and how it deals with them? Thanks. awake-when-it's-night-in-*civilized*-places-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mwh21 at cam.ac.uk Sat Jul 29 12:41:30 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 29 Jul 2000 11:41:30 +0100 Subject: [Python-Dev] extended slicing for lists In-Reply-To: Michael Hudson's message of "29 Jul 2000 10:07:43 +0100" References: Message-ID: Michael Hudson writes: > The patch is here, btw: > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100998&group_id=5470 And has now been updated to support assignments & deletions. I'm happy with deletions, but assignments seem to be a bit counter-intuitive - for example both of Guido's examples: >>> l = range(10) >>> l[2:10:2] = [0]*5 >>> l [0, 1, 0, 3, 0, 5, 0, 7, 0, 9] >>> l = range(10) >>> l[4:-1:-1] = range(5) >>> l [4, 3, 2, 1, 0, 5, 6, 7, 8, 9] are wrong! >>> l[2:10:2] = [0]*5 Traceback (most recent call last): File "", line 1, in ? ValueError: attempt to assign list of size 5 to extended slice of size 4 >>> l[4:-1:-1] = range(5) Traceback (most recent call last): File "", line 1, in ? ValueError: attempt to assign list of size 5 to extended slice of size 0 So I'd really appreciate it if people could play around with the patch and see if (a) they can break it (b) they like the way assignments behave (I am already hooked on the indexing & deletion). now-all-we-need-is-a-slice-expression-for-sorting-ly y'rs M. -- 59. In English every word can be verbed. Would that it were so in our programming languages. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html From mhammond at skippinet.com.au Sat Jul 29 15:13:57 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 29 Jul 2000 23:13:57 +1000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/LibSimpleHTTPServer.py,1.10,1.11 In-Reply-To: Message-ID: > > and if I want to, how do I tweak the block size? [Moshe] > Just like you would in the old days: subclass SimpleHTTPServer, and > substitute the copyfile method with a call to shutil.copyfile with a > non-default size. (IOW, it's easier then what it was before). I think thats a little of an overkill. It requires duplicating the entire method for the sake of one constant. def copyfile(self, source, outputfile): BLOCKSIZE = 8192 to def copyfile(self, source, outputfile, blocksize = 8192): is much more reasonable IMO. Mark. From moshez at math.huji.ac.il Sat Jul 29 15:26:06 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 29 Jul 2000 16:26:06 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/LibSimpleHTTPServer.py,1.10,1.11 In-Reply-To: Message-ID: On Sat, 29 Jul 2000, Mark Hammond wrote: > and if I want to, how do I tweak the block size? [Moshe] > Just like you would in the old days: subclass SimpleHTTPServer, and > substitute the copyfile method with a call to shutil.copyfile with a > non-default size. (IOW, it's easier then what it was before). [Mark] > I think thats a little of an overkill. It requires duplicating the entire > method for the sake of one constant. But Mark, the "entire method" is simply a call to shutil.copyfileobj (well, that and a docstring). So "duplicating" it is the only thing possible, unless you want to define a class variable "BLOCKSIZE". It can be supported without duplicating the functionality of shutil.copyfileobj, but that sure sounds like an overkill.... -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mhammond at skippinet.com.au Sat Jul 29 15:37:45 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 29 Jul 2000 23:37:45 +1000 Subject: [Python-Dev] Re: [Python-checkins] CVS:python/dist/src/LibSimpleHTTPServer.py,1.10,1.11 In-Reply-To: Message-ID: > But Mark, the "entire method" is simply a call to shutil.copyfileobj OK - I looked at it before I updated CVS! Oops :-) > unless you want to define a class variable "BLOCKSIZE". It can > be supported without duplicating the functionality of shutil.copyfileobj, > but that sure sounds like an overkill.... Huh? Well, shutil.copyfileobj appears to have a "length" param, which is exactly what was being asked for (although possibly a poor choice of a name!). It is still more resonable to add a default param than to require a subclass. The shutil author clearly thought so! Mark. From moshez at math.huji.ac.il Sat Jul 29 15:52:36 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 29 Jul 2000 16:52:36 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS:python/dist/src/LibSimpleHTTPServer.py,1.10,1.11 In-Reply-To: Message-ID: On Sat, 29 Jul 2000, Mark Hammond wrote: [About SimpleHTTPServer.copyfile always using the default block-size] > It is still more resonable to add a default param than to require a > subclass. The shutil author clearly thought so! Ani Zatar! I'm the shutil.copyfileobj function author, and the circumstances are different. SimpleHTTPServer.copyfile is called by the methods which are not overridable (in the sense of overriding them being supported), so there is no sense in adding a default parameter -- you need to have something persistent in the class for that: and that is either a variable or method. PS. The "Ani Zatar" part is in case some Israeli reads the archive: it's a non-funny joke in Hebrew, and I won't translate it. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From mmorris at pop.mindspring.com Sat Jul 29 08:19:59 2000 From: mmorris at pop.mindspring.com (Mitchell Morris) Date: Fri, 28 Jul 2000 23:19:59 -0700 Subject: [Python-Dev] Fire, may I present accellerant. Accellerant, this is fire. Message-ID: <20000729061933.LUNZ24904.mail.rdc1.wa.home.com@finin> In general I try to keep my head down. I recently needed some support for regression testing as part of a stealth Python introduction-cum-advocacy effort. I wound up using Steve Purcell's pyunit testing framework, and thought it was a shame that it wasn't part of the standard distribution. To that end ... PEP: eric-the-half-a-pep Title: Guido-blessed unit/regression test framework Version: 0 Target of Opportunity: mmorris at mindspring.com (Mitchell Morris) Python-Version: 2.0 Status: pre-pre-pre-Draft Introduction This proto-PEP advocates that there should be, in the standard library, a unit/regression test framework. This Guido-blessed framework would provide test semantics both useful and standardized. In addition to being a useful structure in it's own right, it would provide an obvious direction for development projects to prepare and use their own regression test policies. Why Should I Care? Software developers have known for quite some time that the majority of our time is spent identifying and correcting errors. Various suggestions for reducing this burden have been explored and most of them have been rejected. One thing that seems to provide some benefit is writing test plans and running them against the software product. This doesn't necessarily eliminate bugs, but it does allow us to find some of them and insure they don't reoccur as we correct later ones. One variation of this process is to extend the test plan as other defects are identified and corrected. Part of the correction would be updating the test suite to include a test that would have identified and exercised the defect. In this way the test plan grows to verify that correct behavior increases monotonically. This kind of test plan also allows very aggressive refactoring, in that the developer can make sweeping changes to module internals with great confidence that things will either (a) not break elsewhere, or (b) break loudly when the unit tests fail. Given the (relative) success of test plans and Python's general friendliness to rapid development and refactoring, there should be a standard tool in all distributions to encourage this dynamic. But ... Smalltalk and Java are Evil! Kent Beck has recently generated a lot of press by writing about his development methodology which he calls "Extreme Programming"[1]. Aside from the unfortunate connotations to sports which would still be completely anonymous without ESPN2, there are a number of useful tools emerging from the XP camp. One of the prime tenets is that developers write their classes and their unit tests at the same time. According to XP, these unit tests have to run at 100% for the code to be acceptable for integration. The design of the testing framework generated by XP is fairly simple: individual tests check the correct functionality of a single quantum of testable behavior, usually public behavior. These individual tests can be aggregated into suites, which are also runnable. Suites can be aggregated as well. Tools are provided to execute these tests and suites in both text and GUI formats. Kent Beck and Erich Gamma wrote a paper called "Test Infected"[2] to demonstrate how the code and tests are developed in tandem. This paper, written as a script for a pair programming session, shows how the various pieces of the JUnit implementation work together. (JUnit is the XP testing tool for Java.) We've Already Got One, Thanks. The current distribution has a regression testing framework, in Lib/test/regrtest.py, which addresses some of these same issues. The obvious question is why not use the tool which is already there? The current tool presents several issues that make this a less-than-exemplary solution: it doesn't allow for graphical manipulation, it separates test and expected result into separate files stored in separate locations, and it tries to generate the tests as well as run them. The objections to regrtest.py then boil down to the it's philosophy. We've Got More Than We Can Stand, Thanks. Really. Also for our consideration is doctest.py, contributed by the inestimable Tim Peters. doctest.py presents a simple straightforward means to embed the individual tests into the production code itself as commentary. This suggests that the separation of test and result presents a cognitive dissonance in other people besides just me. doctest.py doesn't provide any mechanism, however, for aggregating several modules into a single test run, nor does it provide a GUI. Once again, additional effort could obviously provide the missing functionality. On the other hand, doctest.py isn't currently part of the standard distribution. What's All This Then? The point of this proposal is Steve Purcell's pyunit package[3]. This is a Python implementation of XP's xUnit specification. It provides a means for running individual tests, aggregating individual tests into larger suites, running those tests in both text and GUI modes, and keeps the tests and expected results together in a single source module. You Have A Point? Yes: pyunit should be part of the standard library. pyunit documentation should be included in the distribution. New development should be encouraged to use pyunit. We should all rub pyunit all over our bodies as often as we can. Even if it isn't pyunit, Python should have a documented standard component for unit and regression testing, and we should encourage new development to use it, and we should demand that core development include it. References 1 -- XP Wiki see also: 2 -- Beck, Kent and Gamma, Erich, "Test Infected" 3 -- pyunit project at Source Forge pyromanically y'rs +Mitchell From guido at python.org Sat Jul 29 19:39:01 2000 From: guido at python.org (Guido van Rossum) Date: Sat, 29 Jul 2000 12:39:01 -0500 Subject: [Python-Dev] Bookstand at LA Python conference Message-ID: <200007291739.MAA06848@cj20424-a.reston1.va.home.com> The next Python conference will be in Long Beach (Los Angeles). We're looking for a bookstore to set up a bookstand like we had at the last conference. Does anybody have a suggestion? See http://www.python9.com for conference info! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Sat Jul 29 20:04:41 2000 From: guido at beopen.com (Guido van Rossum) Date: Sat, 29 Jul 2000 13:04:41 -0500 Subject: [Python-Dev] Should repr() of string should observe locale? Message-ID: <200007291804.NAA07155@cj20424-a.reston1.va.home.com> There have been some requests (Francois Pinard, recently Alexander Voinov) that repr() of a string should not use escape sequences for characters that are printable according to the locale. I don't have the time to write a PEP or implement it (although it should be simple enough) but it needs to be recorded as a feature that I think is good (that's at least a +0). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From moshez at math.huji.ac.il Sat Jul 29 19:08:58 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 29 Jul 2000 20:08:58 +0300 (IDT) Subject: [Python-Dev] Should repr() of string should observe locale? In-Reply-To: <200007291804.NAA07155@cj20424-a.reston1.va.home.com> Message-ID: On Sat, 29 Jul 2000, Guido van Rossum wrote: > There have been some requests (Francois Pinard, recently Alexander > Voinov) that repr() of a string should not use escape sequences for > characters that are printable according to the locale. > > I don't have the time to write a PEP or implement it (although it > should be simple enough) but it needs to be recorded as a feature that > I think is good (that's at least a +0). I don't. Most people who are requesting it are requesting it for the purpose of the interactive Python session. I think there is general agreement that there should be a way to better control the REPL from Python (my, now lost, sys.display patch, for example). Wouldn't that solve the problem? -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From fdrake at beopen.com Sat Jul 29 21:01:52 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 29 Jul 2000 15:01:52 -0400 (EDT) Subject: [Python-Dev] Request for guidance on documentation In-Reply-To: References: <14722.22525.140359.615231@cj42289-a.reston1.va.home.com> Message-ID: <14723.10784.479056.30153@cj42289-a.reston1.va.home.com> Moshe Zadka writes: > Let me just say what Fred said in a different way: from the processing > engine POV, there's just *one file* with lots of include directives. > The division into file is just to make life easier for us -- so if > two sections are related, it's easier to keep them in the same file. Almost, but not quite. The division into files allows us to reorganize the sections into chapters differently with simple edits; I've found that very useful a couple of times! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From klm at digicool.com Sat Jul 29 21:53:17 2000 From: klm at digicool.com (Ken Manheimer) Date: Sat, 29 Jul 2000 15:53:17 -0400 (EDT) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <200007281701.TAA06630@python.inrialpes.fr> Message-ID: On Fri, 28 Jul 2000 Vladimir.Marangozov at inrialpes.fr wrote: > M.-A. Lemburg wrote: > > > > Separating out LOAD_FAST from the switch shows a nice effect. > > SET_LINENO is removed by -OO anyway, so there's really no > > use in optimizing this one. > > Actually, I think that instead of fighting with SET_LINENO > for the standard setup, it would make sense to change the > invocation options to something more standard: > > 1) python - code without SET_LINENO > 2) python -g - code for debugging, with SET_LINENO > 3) python -O - code without doc-strings. > > The point is that currently there's no optimization of the > code stream at all, in the sense of classic compiler optimization > (code block-level optimizations, loop unrolling, etc). > > And SET_LINENO is actually useful only for debugging (with pdb, etc). > > What about this as a sane proposal for SET_LINENO? I would be firmly -1 on this proposal. Without a major payoff - say, double or better performance improvements - i think it's a bad idea to disable debugging in the common case. Python already has -o and -oo - aren't they sufficient? (Maybe i'm misremembering, but i recall that removing SET_LINENO didn't yield a whole lot of performance improvement. Actually, i have the impression it's been a canonical example of how casual optimizations don't do what you expect - but i may be off base here.) I see the ability to debug at whim, even when you didn't expect having to do so, as being a major win, part of the incremental development process. For me, it's a virtue up there with "having the source" in making it easier to fix my own and other people's mistakes. (The inconvenience of having to rerun with debugging enabled is magnified greatly when dealing with connecting to longrunning processes, as i tend to do with zope under zeo and medusa. Then i'm really screwed if someone forgot to start with optional debugging enabled.) If you can replace SET_LINENO's functionality with something that doesn't have the same overhead, great! I have the impression from your recent comments along these lines that that isn't happening immediately... Ken klm at digicool.com From akuchlin at mems-exchange.org Sat Jul 29 22:34:57 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Sat, 29 Jul 2000 16:34:57 -0400 Subject: [Python-Dev] SF most active project listing Message-ID: I was curious about how "most active project" is defined, and took a look at the SF code. It's computed by the util/db_project_weekly_metric.pl script, which sums up a bunch of parameters to get a number. The parameters are: 3 * # of forum postings 4 * # of tasks 3 * # of bugs 10 * # of patches 5 * # of support 1 * # of CVS commits 5 * # of developers 5 * # of file releases .3 * # of downloads All of these numbers seem to be counted over the past week. I suspect the code has a mathematical bug: the queries use, for example, log(4*count(project_task.project_task_id)) for counting things. However, IIRC, log ab = log a + log b, so the multipliers just add a constant to every project's number, and therefore it's a flat sum of all the parameters. IMHO that should be 4*log(count(....)), and will report it. --amk From tim_one at email.msn.com Sat Jul 29 22:05:14 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 29 Jul 2000 16:05:14 -0400 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: Message-ID: [Ken Manheimer] > ... > (Maybe i'm misremembering, but i recall that removing SET_LINENO > didn't yield a whole lot of performance improvement. That's correct, it's rarely more than just a few percent. > Actually, i have the impression it's been a canonical example of > how casual optimizations don't do what you expect - but i may be > off base here.) Well, it did what *I* expected . There are the "state lottery" and "penny saved is a penny earned" schools of optimization. They appeal, respectively, to "no guts, no glory" and "slow and steady wins the race" types. Both are valuable, although the true merits of the latter don't become apparent until after it's been pursued consistently for years. Python hasn't done that (there's been no consistency of effort, just manic "speed it up" bursts), and neither has it pursued any Major Schemes since LOAD_FAST was introduced. The most interesting dropped project "in the middle" was Skip Montanaro's Rattlesnake, which aimed to change the VM from a stack to a register model. > I see the ability to debug at whim, even when you didn't expect having > to do so, as being a major win, part of the incremental development > process. Same here! But I'm a little warped : I worked on optimization for a living for so many years, that one reason I was attracted to Python is that it didn't do *any* optimization to screw up my view of what my code was doing. Any debugger that claims to work well with "for real" optimized code in any language is lying. So the only optimizations I've ever supported in default-mode Python are things the user can't detect via semantics or usability. So I'm also -1 on [Vladimir] > 1) python - code without SET_LINENO > 2) python -g - code for debugging, with SET_LINENO > 3) python -O - code without doc-strings. unless SET_LINENO isn't needed for debugging. The speedup -O yields today is real and consistent, but rarely makes a difference worth worrying about (the only times it's mattered for me were in extremely well-tested CPU-bound programs that I intended to run for days straight, and then I appreciated the few hours it saved). python-the-choice-for-a-slow-generation-ly y'rs - tim From tim_one at email.msn.com Sat Jul 29 22:16:26 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 29 Jul 2000 16:16:26 -0400 Subject: [Python-Dev] SF most active project listing In-Reply-To: Message-ID: [Andrew Kuchling] > I was curious about how "most active project" is defined, and took a > look at the SF code. It's computed by the > util/db_project_weekly_metric.pl script, which sums up a bunch of > parameters to get a number. The parameters are: > > 3 * # of forum postings > 4 * # of tasks > 3 * # of bugs > 10 * # of patches > 5 * # of support > 1 * # of CVS commits > 5 * # of developers > 5 * # of file releases > .3 * # of downloads > > All of these numbers seem to be counted over the past week. Since it's Perl (or PHP?), I hope they remembered to change what "past week" means each week . Hmm: since they weight patches at 10 times the value of a commit, I guess they value projects where lots of people are unhappy but can't agree on what to do about it . > I suspect the code has a mathematical bug: the queries use, for > example, log(4*count(project_task.project_task_id)) for counting > things. However, IIRC, log ab = log a + log b, so the multipliers > just add a constant to every project's number, and therefore it's a > flat sum of all the parameters. IMHO that should be > 4*log(count(....)), and will report it. Ha! *Another* bug they wouldn't have had if they had written it in Python instead! Ya, ya, I'm lying, but if we all agree to say it's the truth, maybe they'll fall for it. agreeing-with-your-analysis-but-unsure-why-they're-taking-a-log- at-all-ly y'rs - tim From ping at lfw.org Sun Jul 30 01:22:50 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sat, 29 Jul 2000 16:22:50 -0700 (PDT) Subject: [Python-Dev] extended slicing for lists In-Reply-To: Message-ID: Michael Hudson wrote: > Ka-Ping Yee writes: > > [...] sufficient for me to suggest just dropping it: > > better to avoid confusion altogether. > > Well, the BDFL spoke. Hence my mock-indignant "hmph". :) > > having to say l[len(l)-1:-1:-1] would be a royal pain. > > Well, you could probably always say > > l[sys.maxint:0:-1] > > (your example returns the empty list!) Hey, wait a second. To get l[start:end:step], you start with 'start' and keep adding 'step' until you get to -- but not including -- 'end', right? So l[len(l)-1:-1:-1] should return the entire list reversed, not the empty list. range() demonstrates the behaviour nicely: >>> size = 5 >>> range(size-1,-1,-1) [4, 3, 2, 1, 0] Wouldn't l[sys.maxint:0:-1] return all but the first element of l in reverse order? >>> range(size-1,0,-1) [4, 3, 2, 1] Note that we should deprecate the use of sys.maxint (preferring None) in this situation, since if the step is less than -1, the elements you get ought to depend on the value of sys.maxint % step. I'd expect: >>> l = [0, 1, 2, 3, 4, 5] >>> l[5:0:-3] [5, 2] >>> l[6:0:-3] [4, 1] >>> l[7:0:-3] [3, 0] >>> l[8:0:-3] [5, 2] hence >>> l[sys.maxint:0:-3] [???, ???] # depends on sys.maxint % 3 My guiding principle is that the indices should always match what you get from range(), and if start or end are missing, you get the items you would have gotten if you extend the sequence out forever. -- ?!ng From Vladimir.Marangozov at inrialpes.fr Sun Jul 30 04:39:26 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sun, 30 Jul 2000 04:39:26 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: from "Tim Peters" at Jul 29, 2000 04:05:14 PM Message-ID: <200007300239.EAA21825@python.inrialpes.fr> [Tim & Ken voting -1 and arguing about] > [Vladimir] > > 1) python - code without SET_LINENO > > 2) python -g - code for debugging, with SET_LINENO > > 3) python -O - code without doc-strings. > > unless SET_LINENO isn't needed for debugging. To be honest, I was -1 myself shortly after sending the message. The consequences, at least for IDLE, make this truly insane, unless, as you both pointed out, SET_LINENO's functionality is achieved without it. As a matter of fact, its functionality *can* be achieved, at least for debugging purposes. That is, for generating the callbacks from the main loop to a Python function, called on every new source line. This is what basically the patch I ended up with does. To clarify the current state of the challenge to remove SET_LINENO, here's a short summary of the idea we dicussed previously and which I implemented (the patch does look scary without explanation ). Consider the following code sequence diagram (current state), assuming that each position is an opcode, arguments included: 0 1 2 3 01234567890123456780123456780123 co_code -> [#....#......#....#..#....#....] where '.' - an opcode ^ '#' - SET_LINENO IP (instruction pointer) Whenever a sys.settrace function is set, it is called on every # and this is basically how the debugger gets control for each source line. It finds out the source line by reading it from the current frame - f.lineno Now, here's the picture with the patch intended to obviate SET_LINENO: 0 1 2 3 01234567890123456780123456780123 co_code -> [........................] the same co_code w/o SET_LINENO copy of -> [+...+.....+...+.+...+...] '+' is a 1-byte CALL_TRACE opcode co_code ^ overriding the 1st opcode of each internal to IP new source line eval_code2() Whenever a sys.settrace function is set, a copy of the original code stream is created and the IP is redirected to execute the copy before entering the main loop. In this copy, the 1st instruction for each line is set to CALL_TRACE. These locations are computed from the co_lnotab table. CALL_TRACE updates f.lineno and invokes the sys.settrace function. On return from sys.settrace, it reads the opcode byte it has overwritten from the original co_code and jumps directly to the argument fetch before the big switch. All this works like a charm, except that, a priori, it has 2 drawbacks regarding full compatibility with the current state with SET_LINENO: a) f.lineno is not updated on a regular basis like SET_LINENO does; only when sys.settrace is set & CALL_TRACE is called. b) the IP is redirected to the copy of co_code before entering the main loop. In practical terms, this means that only entire code objects are traceable, that is, tracing can't start in the middle of a code object. I am not sure whether these 2 things hurt. If so, probably a) hurts more than b), but this is where I stopped working on this at the time, being short of more ideas... If you have one, you're welcome :-) P!ng?? Florx bignal zupkin moognacious today? If not, this scheme probably looses due to a) and b) and SET_LINENO has to stay, at least, for full backward compatibility. Conclusion: the functionality is achieved, full back/compat is not :-/ -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one at email.msn.com Sun Jul 30 09:53:15 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 03:53:15 -0400 Subject: [Python-Dev] Should repr() of string should observe locale? In-Reply-To: Message-ID: [Guido] > There have been some requests (Francois Pinard, recently Alexander > Voinov) that repr() of a string should not use escape sequences for > characters that are printable according to the locale. > > I don't have the time to write a PEP or implement it (although it > should be simple enough) but it needs to be recorded as a feature > that I think is good (that's at least a +0). [Moshe Zadka] > I don't. Most people who are requesting it are requesting it for the > purpose of the interactive Python session. I think there is general > agreement that there should be a way to better control the REPL from > Python (my, now lost, sys.display patch, for example). Wouldn't that > solve the problem? Because str(list) and str(dict) and str(tuple) end up calling repr() on the items they contain, even simple stmts like e.g. print list_of_goofy_foreign_i.e._not_plain_ascii_strings produce unreadable octal escapes instead of the goofy foreign non-ascii characters goofy foreigners want . That's one of the Lost Pythonic Theses, btw: Goofy is better than unreadable. Hooking the REPL loop doesn't help with that, in part because an explicit print would sidestep the hook, and the rest because it's a real problem in non-interactive mode too. So there are problems other than just Fran\347ois's, including your desire to hook the P in REPL, and including that str(list) and str(dict) and str(tuple) applying repr to their containees causes horrible output for many a user-defined class too (so much so that many classes code __repr__ to do what __str__ is *supposed* to do) -- but they're arguably all distinct problems. That said, I'm -1 too, because Guido once sensibly agreed that strings produced by repr should restrict themselves to the characters C guarantees can be written and read faithfully in text-mode I/O, excluding the tab character (or, iow, each character c in a string produced by repr should have ord(c) in range(32, 128)). Give that up and text-mode pickles (plus anything else repr is used deliberately for in a text file) lose their guarantee of cross-platform portability at the C level (not to mention losing x-platform human readability); etc. The problem isn't that repr sticks in backslash escapes, the problem is that repr gets called when repr is inappropriate. There was extensive debate about that in Python-Dev earlier this year (and the year before, and ...). Thanks to the lack of PEPs in those benighted days, I bet we get to do it all over again . I can't make time for this round, though. In brief: Breaking repr's contract to produce printable ASCII is unacceptable damage to me, no matter what the short-term perceived benefit. A principled solution appeared to require a combination of (at least) making the P in the REPL loop hookable, and making the builtin container types pass on whichever of {str, repr} they were passed *to*; the latter is problematic when the containee is a string, though, because str(string) produces a string without delimiters to say "hey, I'm a string!", making the output pretty unreadable in the context of the containee; further fiddling of some sort is needed. if-the-current-repr-didn't-exist-we'd-have-to-reinvent-it-and- we-still-wouldn't-want-to-invoke-either-repr-much-of-the- time-anyway-ly y'rs - tim From akuchlin at cnri.reston.va.us Sun Jul 30 14:07:18 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 30 Jul 2000 08:07:18 -0400 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <200007300239.EAA21825@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jul 30, 2000 at 04:39:26AM +0200 References: <200007300239.EAA21825@python.inrialpes.fr> Message-ID: <20000730080718.A22903@newcnri.cnri.reston.va.us> Hasn't backward compatibility already been broken for 2.0? So why not break it a little more? It always seemed odd to me that the current line number is always kept up to date, even though 99.999% of the time, no one will care. Why not just keep a small table that holds the offset in the bytecode at which each line starts, and look it up when it's needed? --amk From guido at beopen.com Sun Jul 30 16:02:38 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 09:02:38 -0500 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: Your message of "Sun, 30 Jul 2000 08:07:18 -0400." <20000730080718.A22903@newcnri.cnri.reston.va.us> References: <200007300239.EAA21825@python.inrialpes.fr> <20000730080718.A22903@newcnri.cnri.reston.va.us> Message-ID: <200007301402.JAA08591@cj20424-a.reston1.va.home.com> > Hasn't backward compatibility already been broken for 2.0? So why not > break it a little more? Sure -- within reason. > It always seemed odd to me that the current line number is always kept > up to date, even though 99.999% of the time, no one will care. Why > not just keep a small table that holds the offset in the bytecode at > which each line starts, and look it up when it's needed? That already exists. Search for co_lnotab, and for PyCode_Addr2Line(). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From m.favas at per.dem.csiro.au Sun Jul 30 15:54:15 2000 From: m.favas at per.dem.csiro.au (Mark Favas) Date: Sun, 30 Jul 2000 21:54:15 +0800 Subject: [Python-Dev] checkins and regression tests Message-ID: <39843387.9F35D544@per.dem.csiro.au> It'd be nice if the newly checked-in test were run through the test framework before being checked in - the latest test_mmap.py fails due to the "inconsistent tab-space" problem... Mark -- Email - m.favas at per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 From guido at beopen.com Sun Jul 30 17:34:06 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 10:34:06 -0500 Subject: [Python-Dev] urllib - {quote,unquote} vs. {quote_plus,unquote_plus} In-Reply-To: Your message of "Fri, 28 Jul 2000 07:17:46 EST." <14721.31210.734864.412520@beluga.mojam.com> References: <14721.31210.734864.412520@beluga.mojam.com> Message-ID: <200007301534.KAA12762@cj20424-a.reston1.va.home.com> > I realize there is a symmetry between the functionality of > urllib.{quote,unquote} and urllib.{quote_plus,unquote_plus}, but why doesn't > unquote function like unquote_plus and map "+" to " "? The +/space mapping is unique to CGI query strings. The unquote function is used in a lot of places to decode parts of URLs (e.g. throughout urllib.py itself), e.g. the hostname or (more likely) the pathname can be encoded using %xx, and there a + does *not* mean a space. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Sun Jul 30 17:42:49 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 10:42:49 -0500 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Your message of "Fri, 28 Jul 2000 15:37:56 +0200." References: Message-ID: <200007301542.KAA12794@cj20424-a.reston1.va.home.com> > IMO one of the major strenghts of Python (in its reference implementation > C-Python) has today compared to other languages (Java) is this particular > behaviour. ["this behavior": closing files as soon as they go out of scope] > The argument made in the last sentence of the paragraph cited from > the reference manual is bogus: In order to be able to call a close() > method you have to keep an explicit reference to the object in question. > This usually requires many lines of source code where previously only > one line was needed: > > func(constructor("foo").method()) > has to be recoded as > try: > ref = constructor("foo") > func(ref.method()) > finally: > ref.close() > if constructor happens to keep external resources. This is a factor of > five (in LOC) of code bloat and is absolutely unacceptable. Only if you expect that func() may fail *and* that there may be an outer try/except that keeps the program alive for much longer. Normally it becomes the totally acceptable ref = constructor("foo") func(ref.method()) ref.close() I would recommend the try/finally version only if func() is *expected* to fail for some I/O related reason. And in much Python code (e.g. most scripts and throw-away programming) even the one-liner is totally acceptable. > If this kind of coding is required to make existing Python apps running > reliable under 'JPython', then this will render 'JPython' (and any other > Python implementation without proper reliable reclaiming) pretty useless > for me. (and may be to other members of the Python community) This sounds like a bit of an exaggeration to me. The fact of the matter is that we can't guarantee this, and in fact there are lots of gotcha's with expecting this behavior (e.g. when you catch an exception while a file object is local, the exception handling may easily keep it alive longer than expected. It's also very easy to forget other references to the object. Listen, I'm sorry for causing your worldview on this point to collapse, but it's no big deal, okay?! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Sun Jul 30 17:52:31 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 10:52:31 -0500 Subject: [Python-Dev] Howto docs In-Reply-To: Your message of "Fri, 28 Jul 2000 10:21:32 -0400." <20000728102132.A29083@kronos.cnri.reston.va.us> References: <14721.35225.65706.82099@cj42289-a.reston1.va.home.com> <14721.37704.872570.141761@cj42289-a.reston1.va.home.com> <20000728102132.A29083@kronos.cnri.reston.va.us> Message-ID: <200007301552.KAA12837@cj20424-a.reston1.va.home.com> > On the other hand, the documentation maintainers might be a different > set of people from code maintainers, and we might not want them > checking in code changes, so having the docs as a completely separate > project would allow finer control of this. On the third hand, we do > have the python-checkins list to keep an eye on what's happening. > > I'd vote for nondist/doc/howto. Short term, definitely. Long term, I feel that making it a separate SF project might be a good idea. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From guido at beopen.com Sun Jul 30 18:39:57 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 11:39:57 -0500 Subject: [Python-Dev] buglet in unary ops on classes. In-Reply-To: Your message of "Fri, 28 Jul 2000 18:45:12 +0200." <20000728184512.D266@xs4all.nl> References: <20000728184512.D266@xs4all.nl> Message-ID: <200007301639.LAA16514@cj20424-a.reston1.va.home.com> > While poking around looking for something else, I found this little buglet: > > >>> class X: > ... def __getattr__(self, val): > ... print "getattr:", val > ... raise AttributeError > > >>> x = X() > >>> ~x > getattr: __invert__ > Traceback (most recent call last): > File "", line 1, in ? > File "", line 4, in __getattr__ > AttributeError > > The unary ops all do this (raising AttributeError), but the binary ops do > not: > > >>> x+1 > getattr: __coerce__ > getattr: __add__ > Traceback (most recent call last): > File "", line 1, in ? > TypeError: __add__ nor __radd__ defined for these operands > > Shouldn't this translation be done for unary ops as well ? Is it safe to > assume that instance_getattr() only returns NULL if the attribute is not > found ? PyInstance_DoBinOp() takes this assumption wrt. PyObject_GetAttr(), > and I don't really see a problem with it. In general, I'm against changing exceptions. There are situations conceivable where an AttributeError from a custom __getattr__ is caused by a bug in that __getattr__ or in something it calls, and it's important not to destroy the traceback in that case. The TypeError for a binary operator violates this principle. This is because the coercion process has to try several things that may fail with an AttributeError. Saving the tracebacks is just too much work. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From pf at artcom-gmbh.de Sun Jul 30 17:55:39 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Sun, 30 Jul 2000 17:55:39 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: <200007301542.KAA12794@cj20424-a.reston1.va.home.com> from Guido van Rossum at "Jul 30, 2000 10:42:49 am" Message-ID: Hi, Guido van Rossum: > > IMO one of the major strenghts of Python (in its reference implementation > > C-Python) has today compared to other languages (Java) is this particular > > behaviour. > > ["this behavior": closing files as soon as they go out of scope] > > > The argument made in the last sentence of the paragraph cited from > > the reference manual is bogus: In order to be able to call a close() > > method you have to keep an explicit reference to the object in question. > > This usually requires many lines of source code where previously only > > one line was needed: > > > > func(constructor("foo").method()) > > has to be recoded as > > try: > > ref = constructor("foo") > > func(ref.method()) > > finally: > > ref.close() > > if constructor happens to keep external resources. This is a factor of > > five (in LOC) of code bloat and is absolutely unacceptable. > > Only if you expect that func() may fail *and* that there may be an > outer try/except that keeps the program alive for much longer. In a GUI this is usually the case: For example Pmw contains such a default handler, which catches all otherwise uncaught exceptions and prevents the application from bombing. > Normally it becomes the totally acceptable > > ref = constructor("foo") > func(ref.method()) > ref.close() Sigh. This is still a factor of three. But LOCs are not my major point: An application programmer has to know, whether the object in question uses external resources or not, or he has to use the inconvinient 'close()' or 'destroy()' anyway, if he want's to make sure. [...] > And in much Python code (e.g. most scripts and throw-away programming) > even the one-liner is totally acceptable. Only if the "constructor().method()" idiom is not contained in a loop. Ancient Unix systems allowed only 20 files open at the same time. Although this has been increased to 120 or so in the mean time, you will easily ran out of file descriptors with the simple throw-away script posted in my first rant in this thread: >>> import os, rfc822 >>> posters = {} >>> for arti in os.listdir('/var/spool/news/comp/lang/python'): ... poster = rfc822.Message(open(arti)).get("From") ... posters[poster] = posters.get(poster, 0) + 1 ... >>> for poster, howoften in posters.items(): ... print poster, "posted", howoften, "times to clp." ... I believe scripts like this one are very common in the industry, since this idioms were advertised by several books (I still have to look up Martin v.Loewis "Das Pythonbuch", but IRC it contained subsection comparing Pythons garbage collection with Java GC and advertised the advantages of ref count GC) > > If this kind of coding is required to make existing Python apps running > > reliable under 'JPython', then this will render 'JPython' (and any other > > Python implementation without proper reliable reclaiming) pretty useless > > for me. (and may be to other members of the Python community) > > This sounds like a bit of an exaggeration to me. May be. Since Tkinter has been ported to JPython, I theoretically could give this platform at least a try. But now I know in advance, where I've to expect serious problems. I believe a lot of my GUI code based on Tkinter/Pmw makes use of this behaviour which simply works as advertised by Mark Lutz (and possibly others). [...] > Listen, I'm sorry for causing your worldview on this point to > collapse, but it's no big deal, okay?! If it is only *my* worldview: sure. But their might be others, who have learned Python 3 or 4 years ago. May be by using C-Python, may be by using Mark Lutz book "Programming Python". Since C-Python is available on all major platforms and the implementation in fact guarantees this behaviour (Pheeew!), this is indeed no big deal. No need to use 'JPython'. ;-) Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From mwh21 at cam.ac.uk Sun Jul 30 18:14:51 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 30 Jul 2000 17:14:51 +0100 Subject: [Python-Dev] extended slicing for lists In-Reply-To: Ka-Ping Yee's message of "Sat, 29 Jul 2000 16:22:50 -0700 (PDT)" References: Message-ID: Ka-Ping Yee writes: > Hey, wait a second. To get l[start:end:step], you start with 'start' > and keep adding 'step' until you get to -- but not including -- 'end', > right? So l[len(l)-1:-1:-1] should return the entire list reversed, > not the empty list. Yes, but "-1" also means the last element of the list, so >>> range(10)[3:-1:2] [3, 5, 7] If you want "to the end" behaviour, use None (or nothing): >>> range(10)[5::-2] [5, 3, 1] >>> range(10)[5:None:-2] [5, 3, 1] (these two are indistinguishable) Also, can I plead my case in that this was not my decision - it's the logic implemented by PySlice_GetIndices. > range() demonstrates the behaviour nicely: > > >>> size = 5 > >>> range(size-1,-1,-1) > [4, 3, 2, 1, 0] > > Wouldn't l[sys.maxint:0:-1] return all but the first element of l in > reverse order? Yes. > >>> range(size-1,0,-1) > [4, 3, 2, 1] > > Note that we should deprecate the use of sys.maxint (preferring None) > in this situation, since if the step is less than -1, the elements > you get ought to depend on the value of sys.maxint % step. I'd expect: > > >>> l = [0, 1, 2, 3, 4, 5] > >>> l[5:0:-3] > [5, 2] > >>> l[6:0:-3] > [4, 1] > >>> l[7:0:-3] > [3, 0] > >>> l[8:0:-3] > [5, 2] Whereas at the moment you get: >>> l[5:0:-3] [5, 2] >>> l[6:0:-3] Traceback (most recent call last): File "", line 1, in ? TypeError: slice indices must be integers >>> l[7:0:-3] Traceback (most recent call last): File "", line 1, in ? TypeError: slice indices must be integers >>> l[8:0:-3] Traceback (most recent call last): File "", line 1, in ? TypeError: slice indices must be integers (which is definitely screwy). Perhaps I shouldn't use PySlice_GetIndices (but then if I don't use it for this patch, what on earth would you use it for?). At any rate PySlice_GetIndices needs mending to accept longs (in the style of PyObject_GetItem). > hence > > >>> l[sys.maxint:0:-3] > [???, ???] # depends on sys.maxint % 3 > > My guiding principle is that the indices should always match what > you get from range(), and if start or end are missing, you get the > items you would have gotten if you extend the sequence out forever. Aside from the interpretation of negative indices, I basically agree. Cheers, M. -- languages shape the way we think, or don't. -- Erik Naggum, comp.lang.lisp From guido at beopen.com Sun Jul 30 19:20:07 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 12:20:07 -0500 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: Your message of "Fri, 28 Jul 2000 18:07:21 +0200." <3981AFB9.26AEB1D1@lemburg.com> References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <20000728112646.A15634@thyrsus.com> <3981AFB9.26AEB1D1@lemburg.com> Message-ID: <200007301720.MAA17682@cj20424-a.reston1.va.home.com> > Separating out LOAD_FAST from the switch shows a nice effect. > SET_LINENO is removed by -OO anyway, so there's really no > use in optimizing this one. I tried this and found about three percent speed increase on pystone, for what that's worth. This is with python -OO on Linux x86. Note that removing the (now redundant) case from the switch seemed to make a small difference too. Alas, I have no time to play with optimizing the main loop in a more rigorous way... :-( Here's the patch I came up with: Index: ceval.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/ceval.c,v retrieving revision 2.187 diff -c -r2.187 ceval.c *** ceval.c 2000/07/25 12:56:38 2.187 --- ceval.c 2000/07/30 16:13:23 *************** *** 608,616 **** f->f_lasti = INSTR_OFFSET(); #endif opcode = NEXTOP(); ! if (HAS_ARG(opcode)) oparg = NEXTARG(); #ifdef DYNAMIC_EXECUTION_PROFILE #ifdef DXPAIRS dxpairs[lastopcode][opcode]++; --- 608,631 ---- f->f_lasti = INSTR_OFFSET(); #endif + get_opcode: opcode = NEXTOP(); ! if (HAS_ARG(opcode)) { oparg = NEXTARG(); + if (opcode == LOAD_FAST) { + x = GETLOCAL(oparg); + if (x != NULL) { + Py_INCREF(x); + PUSH(x); + goto get_opcode; + } + PyErr_SetObject(PyExc_UnboundLocalError, + PyTuple_GetItem(co->co_varnames, + oparg)); + goto on_error; + } + } + #ifdef DYNAMIC_EXECUTION_PROFILE #ifdef DXPAIRS dxpairs[lastopcode][opcode]++; *************** *** 1282,1300 **** } Py_INCREF(x); PUSH(x); - break; - - case LOAD_FAST: - x = GETLOCAL(oparg); - if (x == NULL) { - PyErr_SetObject(PyExc_UnboundLocalError, - PyTuple_GetItem(co->co_varnames, - oparg)); - break; - } - Py_INCREF(x); - PUSH(x); - if (x != NULL) continue; break; case STORE_FAST: --- 1297,1302 ---- From jeremy at beopen.com Sun Jul 30 18:30:18 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Sun, 30 Jul 2000 12:30:18 -0400 (EDT) Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <200007301530.KAA12747@cj20424-a.reston1.va.home.com> References: <14719.49496.935765.730596@anthem.concentric.net> <20000727075058.A25450@keymaster.enme.ucalgary.ca> <200007271455.JAA20686@cj20424-a.reston1.va.home.com> <14720.19413.201297.246838@bitdiddle.concentric.net> <200007271616.LAA27700@cj20424-a.reston1.va.home.com> <14720.22377.745878.821529@bitdiddle.concentric.net> <200007271746.MAA29479@cj20424-a.reston1.va.home.com> <14720.27358.569557.671132@bitdiddle.concentric.net> <200007301530.KAA12747@cj20424-a.reston1.va.home.com> Message-ID: <14724.22554.818853.722906@bitdiddle.concentric.net> This message duplicates some of my previous messages about the thread/fork deadlock. (Received report that some of my earlier messages appear to be lost.) I'm running a simpler version of Neil's test program that uses the thread module instead of the threading module. It's attached at the end of the message (test_fork2.py). It spawns five threads; then each thread, including the main thread, go into a while 1: loop that forks. The program locks up after about 100-200 forks. The process structure looks like this: > ps --forest PID TTY TIME CMD 684 pts/0 00:00:00 bash 783 pts/0 00:00:00 python 784 pts/0 00:00:00 \_ python 785 pts/0 00:00:00 | \_ python 786 pts/0 00:00:00 | \_ python 951 pts/0 00:00:00 | | \_ python 787 pts/0 00:00:05 | \_ python 788 pts/0 00:00:04 | \_ python 953 pts/0 00:00:00 | | \_ python 789 pts/0 00:00:00 | \_ python 952 pts/0 00:00:00 | \_ python 950 pts/0 00:00:00 \_ python 964 pts/0 00:00:00 ps top reports the following CPU activity: PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 787 jeremy 19 0 2048 2048 1940 R 0 52.8 0.7 0:06 python 788 jeremy 17 0 2048 2048 1940 R 0 44.2 0.7 0:06 python If I attached to process 787 with gdb, this is the stack trace I can see: #0 pthread_cond_wait (cond=0x80f297c, mutex=0x80f2988) at queue.h:25 #1 0x806fee3 in PyThread_acquire_lock (lock=0x80f2978, waitflag=1) at ../../Python/thread_pthread.h:311 #2 0x8054ec1 in PyEval_RestoreThread (tstate=0x80fb2f0) at ../../Python/ceval.c:171 #3 0x80c1242 in posix_wait (self=0x0, args=0x80f1cac) at ../../Modules/posixmodule.c:2849 #4 0x8059b83 in call_builtin (func=0x8103578, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2369 #5 0x8059a41 in PyEval_CallObjectWithKeywords (func=0x8103578, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2337 #6 0x80583b1 in eval_code2 (co=0x8144ec0, globals=0x80f25d4, locals=0x0, args=0x80f1cb8, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ../../Python/ceval.c:1675 #7 0x805a01d in call_function (func=0x8144cdc, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2491 #8 0x8059a21 in PyEval_CallObjectWithKeywords (func=0x8144cdc, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2335 #9 0x80b03aa in t_bootstrap (boot_raw=0x8142ad8) at ../../Modules/threadmodule.c:193 #10 0x4001ceca in pthread_start_thread (arg=0xbf3ffe60) at manager.c:213 After I collect the stack trace and restart the program, several other processes start running again: PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 786 jeremy 14 0 2048 2048 1928 R 0 24.6 0.7 0:09 python 788 jeremy 15 0 2048 2048 1928 R 0 24.6 0.7 0:34 python 787 jeremy 17 0 2048 2048 1928 R 0 24.4 0.7 0:34 python 783 jeremy 15 0 2048 2048 1928 R 0 23.8 0.7 0:09 python If I run the process again with thread debugging enabled (Py_DEBUG defined at compiel time and THREADDEBUG set to 1), I get the following trace: PyThread_init_thread called PyThread_allocate_lock() -> 0x80f2010 PyThread_acquire_lock(0x80f2010, 1) called PyThread_acquire_lock(0x80f2010, 1) -> 1 PyThread_release_lock(0x80f2010) called PyThread_allocate_lock called PyThread_allocate_lock() -> 0x80f6c58 PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 Adding parser accelerators ... Done. PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_allocate_lock called PyThread_allocate_lock() -> 0x80f6498 PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_start_new_thread called [lots of stuff omitted] 2051 2127 PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 1024 2130 PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_release_lock(0x80f6498) called [blocks] In this case, the deadlock occurs much more quickly. (Perhaps the extra I/O produced by the debugging output exacerbates the problem.) Jeremy PS If you don't have access to a Linux machine, you can use one of the Linux test machines on the SF compile farm. Log into linux.compile.sourceforge.net. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test_fork2.py URL: From guido at beopen.com Sun Jul 30 19:29:58 2000 From: guido at beopen.com (Guido van Rossum) Date: Sun, 30 Jul 2000 12:29:58 -0500 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: Your message of "Thu, 27 Jul 2000 22:05:08 +0200." <20000727220508.C224@xs4all.nl> References: <200007270559.AAA04753@cj20424-a.reston1.va.home.com> <20000727110622.S266@xs4all.nl> <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> <20000727182248.V266@xs4all.nl> <200007271730.MAA21788@cj20424-a.reston1.va.home.com> <20000727220508.C224@xs4all.nl> Message-ID: <200007301729.MAA17698@cj20424-a.reston1.va.home.com> > Yes. So what we're talking about is a better way to do indexing all > together, all types in one shot. ('indexes', 'slices' and 'collections' ? > I'm not sure how to name the first and the last one, if not that.) And not > just indexing, but setting and deleting at the same time, right ? Yes. > So the most preferred way is to pass a single argument which is either: > > - A single object (directly what was passed in) for a single index. > - A slice-object if any kind of single-slice was passed in, which holds the > zero-to-three objects that the slice was 'created' with. > - A tuple of zero or more of either of the above two. (Make that a tuple of two or more!) Indexing like a[] is illegal, and indexing like a[i] passes a non-tuple. > While I'm writing this down, I'm not sure if it's such a good idea. Isn't > this placing a tad too much into one function ? It might require some severe > logic to support this all, especially if you give 'special' meanings to some > indexes. And we're inserting a new catch-all method -- a set of them, > actually: get, set and del -- and that while Paul is trying to solve the > other catch-all Python has, __getattr__/__setattr__. Actually, __getitem__ *already* has to deal with -- the only case it doesn't get currently is the step-less single slice, which gets passed to __getslice__ -- and dies if it's not there. > And lets not forget the convenience of writing those methods: __getitem__ is > intuitive, both in name and semantics. So is __getslice__. The passing of a > slice object to __getitem__ is a tad less intuitive, and a tuple of > index/slice objects even less. Don't worry, that's already the case. > I'm tempted to suggest a single change: when __getslice__ is not defined, > pass a slice object (with no step, as if the slice had a trailing ':') to > __getitem__, and document it properly. Great! That's *exactly* what I've been proposing. > (and make builtin objects accept > sliceobjects too !) That gets a +1 from me too, in general (there's some doubt about the usefulness of things like ``L1[lo:ho:step] = L2''). > Perhaps try to slowly deprecate getslice__. Yes. > Give plenty > __of examples of using __getitem__ and slice objects > in the standard documentation. Sure. > Also, I think it makes sense to make slice > objects indexable, so that you can do: > > start, end, step = sliceobj > > instead of the less intuitive > > start, end, step = sliceobj.start, sliceobj.end, sliceobj.step > > But I've never used slice objects myself, so I can't really say whether it's > a good idea. Maybe that's a good idea. > I suspect this is all for 2.1 or later, though. Actually, the actual change (fall back on __*item__ with a slice object when __*slice__ doesn't exist) should be simple to add for 2.0. Just submit to the SF PM! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From thomas at xs4all.net Sun Jul 30 19:09:41 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 30 Jul 2000 19:09:41 +0200 Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007301729.MAA17698@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Sun, Jul 30, 2000 at 12:29:58PM -0500 References: <200007271337.IAA09101@cj20424-a.reston1.va.home.com> <20000727150036.Z224@xs4all.nl> <200007271422.JAA13096@cj20424-a.reston1.va.home.com> <20000727174803.U266@xs4all.nl> <200007271703.MAA00802@cj20424-a.reston1.va.home.com> <20000727181315.B224@xs4all.nl> <20000727182248.V266@xs4all.nl> <200007271730.MAA21788@cj20424-a.reston1.va.home.com> <20000727220508.C224@xs4all.nl> <200007301729.MAA17698@cj20424-a.reston1.va.home.com> Message-ID: <20000730190941.P13365@xs4all.nl> On Sun, Jul 30, 2000 at 12:29:58PM -0500, Guido van Rossum wrote: > > So the most preferred way is to pass a single argument which is either: > > > > - A single object (directly what was passed in) for a single index. > > - A slice-object if any kind of single-slice was passed in, which holds the > > zero-to-three objects that the slice was 'created' with. > > - A tuple of zero or more of either of the above two. > (Make that a tuple of two or more!) Indexing like a[] is illegal, and > indexing like a[i] passes a non-tuple. No sir: >>> class X: ... def __getitem__(self, val): ... return val ... >>> x = X() >>> x[()] () >>> x[1,] (1,) > > While I'm writing this down, I'm not sure if it's such a good idea. Isn't > > this placing a tad too much into one function ? It might require some severe > > logic to support this all, especially if you give 'special' meanings to some > > indexes. And we're inserting a new catch-all method -- a set of them, > > actually: get, set and del -- and that while Paul is trying to solve the > > other catch-all Python has, __getattr__/__setattr__. > Actually, __getitem__ *already* has to deal with -- the only case it > doesn't get currently is the step-less single slice, which gets passed > to __getslice__ -- and dies if it's not there. It should, but it doesn't, in most cases. God knows the code I wrote that had getitem and getslice didn't take slice objects into account, mostly because I didn't know how they worked ! Not to mention slice-tuples, which I didn't know were possible until you mentioned it ;) > > And lets not forget the convenience of writing those methods: __getitem__ is > > intuitive, both in name and semantics. So is __getslice__. The passing of a > > slice object to __getitem__ is a tad less intuitive, and a tuple of > > index/slice objects even less. > Don't worry, that's already the case. I know, I was arguing for an improvement, here :) > > I'm tempted to suggest a single change: when __getslice__ is not defined, > > pass a slice object (with no step, as if the slice had a trailing ':') to > > __getitem__, and document it properly. > > Great! That's *exactly* what I've been proposing. [snip more approvals] > > I suspect this is all for 2.1 or later, though. > Actually, the actual change (fall back on __*item__ with a slice > object when __*slice__ doesn't exist) should be simple to add for > 2.0. Just submit to the SF PM! That's what I thought. I'll see about that inbetween augmented assignment (which is not easy to do right, in retrospect. I almost uploaded a patch that evaluated 'x' in 'x += 1' twice ;) unless someone beats me to it, of course. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Sun Jul 30 20:19:53 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 30 Jul 2000 21:19:53 +0300 (IDT) Subject: [Python-Dev] Should repr() of string should observe locale? In-Reply-To: Message-ID: On Sun, 30 Jul 2000, Tim Peters identified loads of problems with Python, some of which I wish to address: > A principled solution appeared to require a combination of (at least) making > the P in the REPL loop hookable Oh yes. I think I want to PEP on this one. Barry, that's two numbers you owe me. still-commited-to-dumping-work-on-barry-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From tim_one at email.msn.com Sun Jul 30 20:55:09 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 14:55:09 -0400 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Message-ID: [Peter Funk] > ... > Only if the "constructor().method()" idiom is not contained in > a loop. Ancient Unix systems allowed only 20 files open at the > same time. Although this has been increased to 120 or so in > the mean time, you will easily ran out of file descriptors with > the simple throw-away script posted in my first rant in this > thread: > ... > I believe scripts like this one are very common in the industry, > since this idioms were advertised by several books (I still have > to look up Martin v.Loewis "Das Pythonbuch", but IRC it contained > subsection comparing Pythons garbage collection with Java GC and > advertised the advantages of ref count GC) You don't have to dig that deep: they're also common in the standard distribution, including at least two of mine (checkappend.py and tabnanny.py). There's a long copy/paste/modify tradition of not bothering to close file objects in multi-file tools, dating back at least to Guido's 1991 eptags.py . These aren't hard to "fix", but that isn't the point. A lot of code out there would start failing in data- and platform-dependent ways if CPython stopped cleaning up dead file objects "real soon" after they die, and there's no easy way to identify in advance which code that may be. It would piss off a lot of people! But I don't know why we're arguing about it. Nobody (AFAIK) has announced plans to take refcounting out of CPython, but that you can't *rely* on refcounting across Python implementations is ancient news (and a reality in practice since JPython). Guido certainly can't *require* that all implementations use refcounting! The Reference Manual has been clear about this for years, and other implementations already rely on what they were promised there: it's already too late to stop this from being a basis on which implementations will compete. as-if-microsoft-had-the-resources-to-take-on-beopen-anyway-ly y'rs - tim From Vladimir.Marangozov at inrialpes.fr Sun Jul 30 23:45:19 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sun, 30 Jul 2000 23:45:19 +0200 (CEST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007301720.MAA17682@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 30, 2000 12:20:07 PM Message-ID: <200007302145.XAA26775@python.inrialpes.fr> Guido van Rossum wrote: > > > Separating out LOAD_FAST from the switch shows a nice effect. > > SET_LINENO is removed by -OO anyway, so there's really no > > use in optimizing this one. > > I tried this and found about three percent speed increase on pystone, > for what that's worth. This is with python -OO on Linux x86. Note > that removing the (now redundant) case from the switch seemed to make > a small difference too. > > [patch deleted] Some speedup confirmed on my Linux PIII too. But you saved a round-trip around the ticker test. If this is acceptable, then let's do it for the opcodes involving only stack operations (probably not the JUMPs) _and_ which do not contain DECREFs which may trigger an external call. Here's the picture on my machine (I get the same picture with -OO): cvs - the original ceval.c in CVS load_fast - ceval.c with your patch top5 - ceval.c with my patch at SF moving 5 opcodes to the top top5-loadfast - my patch and your patch ~/python/dev>./python-cvs Lib/test/pystone.py Pystone(1.1) time for 120000 passes = 19.85 This machine benchmarks at 6045.34 pystones/second ~/python/dev>./python-load_fast Lib/test/pystone.py Pystone(1.1) time for 120000 passes = 19.61 This machine benchmarks at 6119.33 pystones/second ~/python/dev>./python-top5 Lib/test/pystone.py Pystone(1.1) time for 120000 passes = 18.87 This machine benchmarks at 6359.3 pystones/second ~/python/dev>./python-top5-load_fast Lib/test/pystone.py Pystone(1.1) time for 120000 passes = 19.08 This machine benchmarks at 6289.31 pystones/second Which shows, among others, that important cache effects are still here, bacause "python-top5-load_fast" is slower than "python-top5" alone... no-more-time-for-it-from-me-either'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From pf at artcom-gmbh.de Mon Jul 31 00:31:59 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Mon, 31 Jul 2000 00:31:59 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: from Tim Peters at "Jul 30, 2000 2:55: 9 pm" Message-ID: Hi, Tim Peters: > > [about Class().method()-idiom] [...] > You don't have to dig that deep: they're also common in the standard > distribution, including at least two of mine (checkappend.py and > tabnanny.py). There's a long copy/paste/modify tradition of not bothering > to close file objects in multi-file tools, dating back at least to Guido's > 1991 eptags.py . > > These aren't hard to "fix", but that isn't the point. A lot of code out > there would start failing in data- and platform-dependent ways if CPython > stopped cleaning up dead file objects "real soon" after they die, and > there's no easy way to identify in advance which code that may be. It would > piss off a lot of people! Thank you! Pheew. This applies in particular not only to file descriptors. This hits other limited resources also: color table entries, windows, network connections and so on. > But I don't know why we're arguing about it. Nobody (AFAIK) has announced > plans to take refcounting out of CPython, but that you can't *rely* on > refcounting across Python implementations is ancient news (and a reality in > practice since JPython). This topic was initially raised in the recent discussion about weak references which had a completely different subject line: "Product iteration". Mark Hammond wrote in this thread: MH> I have no problem with this at all. The sooner we point out the broken MH> code the better. The last thing we want is for obviously and documented MH> broken code to suddenly be considered non-broken simply by the volume of MH> poor code out there... Here I would say : "too late!" The volume of code is already there and from my POV this code simply doesn't look broken. I think it is but elegant, because it is usually shorter and was easier to write, because the programmer hasn't to bother too much about any external resources, which may have been used by some temp objects under the hood. > Guido certainly can't *require* that all implementations use refcounting! Okay. But this is "(for language lawyers)" anyway ;-). Anybody who want's to develop a seriously competing Python implementation is well advised to implement a similar "real soon" object recycling strategy regardless of what the Language Reference may tell them and what Guido "require". The existing code requires it. The current reliable automatic recycling behaviour in C-Python is so very very convenient, that I wouldn't want to do without it in practice. This is like having to use the staircase to go upstairs to the 10th floor in a building if there is an elevator with an open door just beside the first step. > The Reference Manual has been clear about this for years, and other > implementations already rely on what they were promised there: it's already > too late to stop this from being a basis on which implementations will > compete. Competing Python implementations? Hmmm.... Hmmm.... there is "stackless" but AFAIK it also uses refcounting... . ;-) Happy with C-Python, Peter From mhammond at skippinet.com.au Mon Jul 31 00:38:34 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 31 Jul 2000 08:38:34 +1000 Subject: [Python-Dev] checkins and regression tests In-Reply-To: <39843387.9F35D544@per.dem.csiro.au> Message-ID: > It'd be nice if the newly checked-in test were run through the test > framework before being checked in - the latest test_mmap.py fails due to > the "inconsistent tab-space" problem... That would be my fault. Thomas has already fixed it - thanks! However, Im a little confused by the error you saw. It certainly tested OK for me on both Linux and Windows, both when I checked it in, and as soon as I saw your message (but before updaing CVS). It also looks like it should have worked - a tab was used where 8 spaces should have been. I do find it a little ironic that Pythonwin has a number of features to detect this exact problem - but I didnt use Pythonwin to edit that :-( Oh well, all's well that ends well :-) Mark. From tim_one at email.msn.com Mon Jul 31 00:41:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 18:41:42 -0400 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007302145.XAA26775@python.inrialpes.fr> Message-ID: [Vladimir Marangozov] > ... > Which shows, among others, that important cache effects are > still here, bacause "python-top5-load_fast" is slower than > "python-top5" alone... I would rather call them "second-order effects" (SOE), as we can actually have no idea what causes them without a whale of a lot of work. They *could* be unfortunate accidents in the data or instruction caches, or *could* be that rearranging the code caused the compiler to spill a variable to memory that would have been better off in a register, or *could* be that the compiler optimizer runs out of steam in a different place than before and so generates sub-optimal code in any number of other respects, or *could* be that the sequence of jumps just happened to change in a way that causes one to get mis-predicted by the HW, or causes the HW prediction cache to flush at a bad moment, or etc etc etc. A gloss: almost all interesting optimizations a compiler performs, from register assignment to instruction scheduling, take exponential time to optimize "for real". No compiler can afford that much time (although there are some platform-specific "superoptimizers" out there that you can run for days over small pieces of code), so in practice compilers string together a long chain of fast but more-or-less fragile heuristic approaches, or even resort to general "mystery schemes" (like simulated annealing). Predicting what pops out the other end generally can't be done easier than by running the optimizer and *seeing* what pops out! So tiny changes can have wonderfully unexpected effects, and in general you cannot out-think them in advance. And as CPU HW has gotten ever-more complex, SOE has spread to cover a much larger territory than it used to (note that Intel doesn't even pretend to document the actual P3 timing rules anymore -- they've gotten too complicated to explain! compilers only work from an *approximation* to HW truth now). That said, there's good cross-platform reason to believe that Vladimir's "top 5" rearrangement is a helpful change, and more helpful than sucking out one popular opcode. It also has less potential to trigger harmful SOE, because it doesn't change the basic-block structure of the code (optimizers crawl over a graph of the basic blocks, and changes to the *topology* of the graph can cause heuristics to "get stuck" in new & exciting places <0.9 wink>; this is important in ceval because the loop is soooooo big -- optimizers are likely to fall into a state of unstable equilibrium when chewing over this much code). +1 on top5 because it's an easy change that's likely to help and unlikely to hurt. -0 on peeing away more time on micro-optimization right now. then-again-if-it's-the-only-way-guido-can-take-time-to-actually- work-on-python...-ly y'rs - tim From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 01:26:12 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 01:26:12 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <200007301402.JAA08591@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jul 30, 2000 09:02:38 AM Message-ID: <200007302326.BAA05861@python.inrialpes.fr> Guido van Rossum wrote: > > > Hasn't backward compatibility already been broken for 2.0? So why not > > break it a little more? > > Sure -- within reason. Ok folks. I've uploaded an updated patch on SF against CVS if you want to play with it. IDLE, at least, seems to be happy. I'm not sure whether something else relies on f.lineno and whether it is now broken because of the lack of lineno updates. (Note that you need to delete your .pyc files so that the compiler can regenerate the code without SET_LINENO; if SET_LINENO are in the code, you wouldn't see any difference...) -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one at email.msn.com Mon Jul 31 01:26:00 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 19:26:00 -0400 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Message-ID: Peter, what would you say if someone told you your Python programs would run, oh, 30% faster, but in return for that you could no longer rely on refcount semantics? What do you think *most* people would say? I don't know, but I'm certain I'd hear different answers from different people. Don't fall into the trap of believing that refcounting is a pure win! JPython and Vyper and the MS runtime aren't doing "real gc" just because they want to irritate people . There are tradeoffs here, and new Python code is probably more interesting to MS than old Python code. I personally don't think you'd find this a big deal if you had *always* needed to do explicit .close()-like calls in Python, and most programmers (across the world and across languages) have never used a language in which they *didn't* need to do explicit closes. Python has plenty of other attractions for them. MS may very well be delighted to leave the legacy Python market to BeOpen <0.9 wink>. remind-me-to-call-uncle-bill-in-the-morning-ly y'rs - tim From tim_one at email.msn.com Mon Jul 31 01:46:12 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 30 Jul 2000 19:46:12 -0400 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <20000730080718.A22903@newcnri.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > ... > It always seemed odd to me that the current line number is > always kept up to date, even though 99.999% of the time, no > one will care. Why not just keep a small table that holds > the offset in the bytecode at which each line starts, and > look it up when it's needed? As Guido said, we already do -- indeed, that's how Python manages to produce line numbers in tracebacks under -O mode (which inhibits generation of SET_LINENO opcodes). Your next job is to think about how, e.g., you can set a breakpoint on a specific line of code in the debugger. Take a quick peek at the implementation of SET_LINENO in ceval.c, and you'll see that's where the trace hook is implemented. No SET_LINENO, no trace callback. That's what Vladimir has been trying to solve: the trick is arranging to pay something at runtime for it only when you're actually using it. debuggers-always-need-dirty-tricks-ly y'rs - tim From nhodgson at bigpond.net.au Mon Jul 31 01:50:34 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Mon, 31 Jul 2000 09:50:34 +1000 Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) References: Message-ID: <015d01bffa80$f4bbced0$8119fea9@neil> > Don't fall into the trap of believing that refcounting is a pure win! > JPython and Vyper and the MS runtime aren't doing "real gc" just because > they want to irritate people . There are tradeoffs here, and new > Python code is probably more interesting to MS than old Python code. This aspect of GC is, however, irritating some C++ programmers who are an important MS customer group. This can be used to block C# and 'managed' C++ inside .NET with the argument "C# is /less/ safe because it is harder to ensure clean up so you'll leak resources". The base problem is that the only resource GC knows about is memory. There should be a way of attaching other resources such as file handles and data base connections to a similar mechanism. Neil From greg at cosc.canterbury.ac.nz Mon Jul 31 02:05:00 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Mon, 31 Jul 2000 12:05:00 +1200 (NZST) Subject: [Python-Dev] PEP 203 Augmented Assignment In-Reply-To: <200007281134.NAA05764@python.inrialpes.fr> Message-ID: <200007310005.MAA10150@s454.cosc.canterbury.ac.nz> > Yes, and we won't be able to conclude anything. This is micro-optimization > which doesn't give meaningful results. That's why I said "if what you say is true", i.e. if the claimed slowdown from the extra argument decoding step actually exists. There are two possibilities: (1) It really does slow down the execution of all bytescodes. In that case, move it into the handler code for the relevant bytecodes, where it won't affect the speed of anything else. (2) Otherwise, leave it where it is. Either way, I don't see any justification to reject the idea of having 2-arg opcodes because of speed, which is what the original post seemed to be saying. Or maybe I misunderstood. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 02:25:08 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 02:25:08 +0200 (CEST) Subject: 2-arg opcodes (was Re: [Python-Dev] PEP 203 Augmented Assignment) In-Reply-To: <200007310005.MAA10150@s454.cosc.canterbury.ac.nz> from "Greg Ewing" at Jul 31, 2000 12:05:00 PM Message-ID: <200007310025.CAA10819@python.inrialpes.fr> Greg Ewing wrote: > > Either way, I don't see any justification to reject the idea of > having 2-arg opcodes because of speed, which is what the > original post seemed to be saying. Or maybe I misunderstood. The latter. I was objecting to Guido's suggestion to time it and see... I'm not opposed to the idea, although it is likely to slow things down. But assuming we don't talk about performance, I don't see a reason for not thinking about a generalized scheme with variable-size arguments, (cf. classical CPU instruction sets) that is, instructions which operate on 1-, 2- or 4-byte arguments. if-you-wanna-fix-it-do-it-like-a-man-'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From greg at cosc.canterbury.ac.nz Mon Jul 31 02:25:55 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Mon, 31 Jul 2000 12:25:55 +1200 (NZST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007281547.RAA06456@python.inrialpes.fr> Message-ID: <200007310025.MAA10154@s454.cosc.canterbury.ac.nz> > Imagine what will happen if SET_LINENO disappears But this is > very tricky business which is more complicated than it looks like... Can someone summarise what the issues are with SET_LINENO? I had the impression that they're not needed for finding the line numbers in tracebacks. So what would we lose if they disappeared? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From mhammond at skippinet.com.au Mon Jul 31 03:45:01 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 31 Jul 2000 11:45:01 +1000 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007310025.MAA10154@s454.cosc.canterbury.ac.nz> Message-ID: > Can someone summarise what the issues are with SET_LINENO? > I had the impression that they're not needed for finding the > line numbers in tracebacks. So what would we lose if they > disappeared? The debugger (and quite possibly the profiler - I havent checked!) As Tim said only a few hours ago: --- Your next job is to think about how, e.g., you can set a breakpoint on a specific line of code in the debugger. Take a quick peek at the implementation of SET_LINENO in ceval.c, and you'll see that's where the trace hook is implemented. No SET_LINENO, no trace callback. That's what Vladimir has been trying to solve: the trick is arranging to pay something at runtime for it only when you're actually using it. debuggers-always-need-dirty-tricks-ly y'rs - tim --- Mark. From gvwilson at nevex.com Mon Jul 31 04:11:09 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Sun, 30 Jul 2000 22:11:09 -0400 (EDT) Subject: [Python-Dev] re-ordering op-codes / DDJ Message-ID: Hi, folks. Given how popular byte code interpreters are these days, I think "Doctor Dobb's Journal" would be very interested in an article if work is done on re-ordering/re-organizing the Python VM to improve performance. Interested parties please mail me directly... Thanks, Greg From greg at cosc.canterbury.ac.nz Mon Jul 31 04:18:26 2000 From: greg at cosc.canterbury.ac.nz (Greg Ewing) Date: Mon, 31 Jul 2000 14:18:26 +1200 (NZST) Subject: Ditching SET_LINENO (RE: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment)) In-Reply-To: Message-ID: <200007310218.OAA10165@s454.cosc.canterbury.ac.nz> > the trick is arranging to pay something > at runtime for it only when you're actually using it. When tracing is in effect, switch to another copy of ceval2() which contains extra code to do whatever grubby things are needed to detect the start of a line using the line starts table. (Search it before executing each opcode, expand it into a parallel array of flags, or whatever.) The two versions of ceval2() could be generated from the same source file with some #defines. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+ From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 04:34:08 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 04:34:08 +0200 (CEST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: from "Mark Hammond" at Jul 31, 2000 11:45:01 AM Message-ID: <200007310234.EAA11379@python.inrialpes.fr> Mark Hammond wrote: > > > Can someone summarise what the issues are with SET_LINENO? > > I had the impression that they're not needed for finding the > > line numbers in tracebacks. So what would we lose if they > > disappeared? > > The debugger (and quite possibly the profiler - I havent checked!) Addendum: the debugger in its current state. And the whole point of the solution we were thinking of is to make sure that the debugger (and other objects, like tracebacks) do read the line number only when the main loop fires a "line" event via a hook. Given the state of the art, however, nobody can guarantee that the line number is not fetched in legacy code from the frame directly, through f.lineno (for whatever purpose). Note that we can trap the access to the f.lineno attribute in frameobject.c, but the problem boils down to computing the line number from the current instruction, i.e. from 'f.lasti', because the only thing we have at our disposal is a table (co_lnotab) which maps line number offsets and instruction offsets (through delta increments). Note that the f.lasti attr is not updated as it should in the main loop, because it would infer a lot of overhead (to be up to date, it needs to be updated for every opcode). It is updated only for 'important' events: a trace hook, an exception, a Python function call. So, at the heart of the difficulty here is the fact that we can't figure out precisely where we are in the opcode stream, if we ask that from Python (because the program counter is not stored anywhere regularly). We need to get notified by the main loop. And whenever you ask 'f.lineno' from Python, well, you're asking this information from the Python side (without notification from the C side). Do you follow me up to this point? :-) Now, with SET_LINENO, we are sure that f.lineno is always up to date, because its purpose is to update f.lineno (on one hand) *and* to fire a "line" event from the main loop if a hook is in place. The compiler makes sure to insert SET_LINENO opcodes for each new source line (this is why, BTW, you can end up with 10 SET_LINENO in a row if you have 10 doc strings in a row that describe some Python function). Without SET_LINENO, we have to deal with these two problems: firing "line" events whenever a tracing function is set and updating f.lineno. We can manage to fire a "line" event (through the scheme I've explained previously, or similar), but we still can't (well, I don't see a reliable way so far) update f.lineno permanently. that's-all-'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 04:42:10 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 04:42:10 +0200 (CEST) Subject: Ditching SET_LINENO (RE: [Python-Dev] Reordering opcodes (PEP 203 In-Reply-To: <200007310218.OAA10165@s454.cosc.canterbury.ac.nz> from "Greg Ewing" at Jul 31, 2000 02:18:26 PM Message-ID: <200007310242.EAA11409@python.inrialpes.fr> Greg Ewing wrote: > > > the trick is arranging to pay something > > at runtime for it only when you're actually using it. > > When tracing is in effect, switch to another copy of ceval2() > which contains extra code to do whatever grubby things are > needed to detect the start of a line using the line > starts table. (Search it before executing each opcode, > expand it into a parallel array of flags, or whatever.) > > The two versions of ceval2() could be generated from the same > source file with some #defines. Huh? See my Addendum: to Mark's message that I just posted, which explains the whole story in detail. I forgot to change the subject line which still reads "Opcode reordering". Ah wait... from the archives: http://www.python.org/pipermail/python-dev/2000-July/014395.html If you think your suggestion still holds, then could you elaborate a bit more? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 05:35:49 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 05:35:49 +0200 (CEST) Subject: [Python-Dev] SET_LINENO = f.lineno + ticker + ... = ? In-Reply-To: <200007310242.EAA11409@python.inrialpes.fr> from "Vladimir Marangozov" at Jul 31, 2000 04:42:10 AM Message-ID: <200007310335.FAA11459@python.inrialpes.fr> [me, on explaining the deal with SET_LINENO] > > See my Addendum: to Mark's message that I just posted, which explains > the whole story in detail. I forgot to change the subject line which > still reads "Opcode reordering". Ah wait... from the archives: > > http://www.python.org/pipermail/python-dev/2000-July/014395.html > Which makes me think about the tstate->ticker. This is the only variable updated for every opcode. If we can manage to involve the ticker in the computation of f.lineno, having f.lasti and interp->checkinterval and whatever variables are logged somewhere, we're about to win. But it's likely to be messy, because thread states and frames would be involved. If this is possible, we'll trap f.lineno's access in frameobject.c and through this magic formula we could get an updated f.lineno on every Python request. Could someone think of a "magic formula" to compute the PC (the index of the current opcode), which is enough for computing f.lineno with PyCode_Addr2Line()? Guido? Tim? Anyone? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one at email.msn.com Mon Jul 31 06:23:56 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 31 Jul 2000 00:23:56 -0400 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007310234.EAA11379@python.inrialpes.fr> Message-ID: [Vladimir Marangozov] > ... > And the whole point of the solution we were thinking of is to > make sure that the debugger (and other objects, like > tracebacks) do read the line number only when the main loop > fires a "line" event via a hook. > > Given the state of the art, however, nobody can guarantee that > the line number is not fetched in legacy code from the frame > directly, through f.lineno (for whatever purpose). I really don't think we care about that. Guido, do we ? f_lineno is conceptually an internal implementation detail of frame objects, and Guido has often warned that if you access the internals you're on your own (I don't think even Michael's bytecodehacks cares about this one ). So long as all uses of f_lineno in the std distribution can be faked, I think it's fine to just get rid of that member. WRT your later msg, strongly doubt tstate->ticker will help: it's an integer in range(tstate->interp->checkinterval + 1), and wraps around over & over. Besides, the modular base (checkinterval) can be changed by the user at any time. tstate->ticker is thus but the circular shadow of a legion of ghosts. It isn't worth all these brain cells just to preserve an internal detail! OK, it would be worth it if it were easy -- but it's not. From thomas at xs4all.net Mon Jul 31 06:48:49 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 31 Jul 2000 06:48:49 +0200 Subject: [Python-Dev] checkins and regression tests In-Reply-To: ; from mhammond@skippinet.com.au on Mon, Jul 31, 2000 at 08:38:34AM +1000 References: <39843387.9F35D544@per.dem.csiro.au> Message-ID: <20000731064849.J266@xs4all.nl> On Mon, Jul 31, 2000 at 08:38:34AM +1000, Mark Hammond wrote: > > It'd be nice if the newly checked-in test were run through the test > > framework before being checked in - the latest test_mmap.py fails due to > > the "inconsistent tab-space" problem... > That would be my fault. Thomas has already fixed it - thanks! My shadow is still trying to catch up :) > However, Im a little confused by the error you saw. It certainly tested OK > for me on both Linux and Windows, both when I checked it in, and as soon as > I saw your message (but before updaing CVS). It also looks like it should > have worked - a tab was used where 8 spaces should have been. 'make test' runs 'python -tt' on the test scripts, at least on systems using Makefile. And '-tt' means you can't mix spaces and tabs even if you use 8-space tabstops. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From moshez at math.huji.ac.il Mon Jul 31 06:57:41 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 31 Jul 2000 07:57:41 +0300 (IDT) Subject: [Python-Dev] RE: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: Message-ID: On Sun, 30 Jul 2000, Tim Peters wrote: > But I don't know why we're arguing about it. Nobody (AFAIK) has announced > plans to take refcounting out of CPython, but that you can't *rely* on > refcounting across Python implementations is ancient news (and a reality in > practice since JPython). Well, to bring this back to the original: I proposed a variant of lexical scoping where an inner function has only a weak reference to its surroundin environment, so that def f(x): def g(): return x return g f(1)() Would fail with "UnboundOuterVariable", but the more commonly used def f(x): return map(lambda i,x=x: i*x, range(10)) Would turn into def f(x): return map(lambda i: i*x, range(10)) And work. Guido seemed to want to simulate classes by closures , and I tried to convince him that a) Python has a perfectly good class mechanism <3000 wink> b) non-weak references would cause cycles, which would mean that the currently working code: def f(file): file = open(file) def g(x): print x g(file.read()) Would fail is called in a loop if GC is not called too often. lexical-scoping-is-too-powerful-for-its-own-good-ly y'rs, Z. -- Moshe Zadka There is no IGLU cabal. http://advogato.org/person/moshez From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 07:54:08 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 07:54:08 +0200 (CEST) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: from "Tim Peters" at Jul 31, 2000 12:23:56 AM Message-ID: <200007310554.HAA11702@python.inrialpes.fr> Tim Peters wrote: > > [Vladimir Marangozov] > > ... > > And the whole point of the solution we were thinking of is to > > make sure that the debugger (and other objects, like > > tracebacks) do read the line number only when the main loop > > fires a "line" event via a hook. > > > > Given the state of the art, however, nobody can guarantee that > > the line number is not fetched in legacy code from the frame > > directly, through f.lineno (for whatever purpose). > > I really don't think we care about that. Guido, do we ? > > f_lineno is conceptually an internal implementation detail of frame objects, > and Guido has often warned that if you access the internals you're on your > own (I don't think even Michael's bytecodehacks cares about this one > ). So long as all uses of f_lineno in the std distribution can be > faked, I think it's fine to just get rid of that member. > > WRT your later msg, strongly doubt tstate->ticker will help: it's an > integer in range(tstate->interp->checkinterval + 1), and wraps around over & > over. Besides, the modular base (checkinterval) can be changed by the user > at any time. tstate->ticker is thus but the circular shadow of a legion of > ghosts. > > It isn't worth all these brain cells just to preserve an internal detail! It is! > OK, it would be worth it if it were easy -- but it's not. It is! I think I found the solution :-) Whenever f.f_lineno is accessed, the compiler generates a LOAD_ATTR relative to f. Therefore, updating f->f_lasti = INSTR_OFFSET() in LOAD_ATTR + trapping "lineno" access in frameobject.c with PyCode_Addr2Line(f->f_lasti) ensures that we'll always get the right line number. Of course, this makes the update of f->f_lasti for every LOAD_ATTR, but given the ranking of SET_LINENO compared to LOAD_ATTR in the DXP and MAL's frequency charts, I think this is a pure win! Et voila . I'll update my patch at SF later. now-back-to-work'ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From ping at lfw.org Mon Jul 31 08:38:45 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sun, 30 Jul 2000 23:38:45 -0700 (PDT) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: <200007310234.EAA11379@python.inrialpes.fr> Message-ID: Mark Hammond wrote: > > > Can someone summarise what the issues are with SET_LINENO? > > I had the impression that they're not needed for finding the > > line numbers in tracebacks. Yes, traceback info comes from c_lnotab and doesn't depend on SET_LINENO. Only tracing and f.lineno depend on SET_LINENO. > > So what would we lose if they disappeared? > > The debugger (and quite possibly the profiler - I havent checked!) I'm still a little puzzled on this one. The only way you can view a running Python program in the debugger is to have started it within the debugger, right? I don't think it's possible to attach a debugger to an already running program. Hence -- if you had to know beforehand that you were going to start the debugger anyway, then you clearly have the opportunity to say -g whenever you want to do debugging. It seems to me that any debugger (or IDLE et al.) can just start with #!/usr/bin/env python -g and we could then drop SET_LINENO by default. Am i missing something? On Mon, 31 Jul 2000, Vladimir Marangozov wrote: > Note that the f.lasti attr is not updated as it should in the main loop, > because it would infer a lot of overhead (to be up to date, it needs to > be updated for every opcode). It is updated only for 'important' events: > a trace hook, an exception, a Python function call. This is okay. The *only* time this is going to make any difference is when a function is trying to inspect the location of the PC within itself. (When the frame is being inspected from anywhere else, f.lasti will be up to date because it will have been set on function call.) I think we don't need to care so much about a function looking at its own f.lineno. Just use PyCode_Addr2Line on f.lasti whenever someone asks for f.lineno, and perhaps document the caveat for anyone weird enough to write navel-gazing functions. :) -- ?!ng From ping at lfw.org Mon Jul 31 08:47:59 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sun, 30 Jul 2000 23:47:59 -0700 (PDT) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: Message-ID: On Sat, 29 Jul 2000, Ken Manheimer wrote: > On Fri, 28 Jul 2000 Vladimir.Marangozov at inrialpes.fr wrote: > > 1) python - code without SET_LINENO > > 2) python -g - code for debugging, with SET_LINENO > > 3) python -O - code without doc-strings. [...] > I would be firmly -1 on this proposal. Funny -- i was just about to throw in a hearty +1. > I see the ability to debug at whim, even when you didn't expect having to > do so, as being a major win, part of the incremental development process. But you *can't* debug at whim, right? You have to have started the debugger, so it can hook sys.settrace, before you run your program. If you have to start the debugger anyway, then you can surely say -g. If you *didn't* start the debugger beforehand, the best you can get is a detailed traceback with function names and line numbers -- and you don't lose any of that when SET_LINENO goes away. Let's suppose: 1. -g is turned on by default in interactive mode, since we don't know if you're going to feel like tracing today. 2. Programs (like debuggers and IDEs) that know they're going to use sys.settrace, or which contain embedded interactive interpreters, begin with #!/usr/bin/env python -g 3. Other programs begin with the usual #!/usr/bin/env python Given this -- are there any debugging opportunities you're missing out on? I don't see any... -- ?!ng From MarkH at ActiveState.com Mon Jul 31 08:47:17 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Mon, 31 Jul 2000 16:47:17 +1000 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: Message-ID: > I'm still a little puzzled on this one. The only way you can view > a running Python program in the debugger is to have started it > within the debugger, right? Not really. > I don't think it's possible to attach > a debugger to an already running program. IDLE and Pythonwin are able to debug arbitary programs once they have started - and they are both written in Python. In addition, most debuggers have a technique for breaking into the debugger from code - ie, a hard break-point. pdb.set_trace() is how pdb does it. Pythonwin has one. IDLE either does, or will grow one. I can see a number of other problems: * You do not want to debug the IDE itself, just a tiny bit of code running under the IDE. Making the IDE take the full hit simply because it wants to run a debugger occasionally isnt fair. Also, people tend to start these IDEs once, and keep them running during a number of discrete tasks. Only a few of these tasks may involve firing up the debugger. Asking them to restart the IDE simply to enable the debugger would be a pain for the user. Worse, these IDEs are often started from a GUI, rather than from the command line. This would mean we need 2 (in Windows parlance) shortcuts - "IDLE" and "IDLE with debugging". The end result is that all IDEs will run with debugging enabled. * Python often is embedded, for example, in a Web Server, or used for CGI. It should be possible to debug these programs directly. It shouldnt be necessary to (eg) change the CGI settings so Python is invoked with a special flag whenever you want to use a debugger. It can be hard enought to setup CGI as it is, let alone trying to make it's behaviour depend on if a script needs to be debugged or not. * We should not force Python embedders to handle this themselves. For example, asking someone who embeds Python to support a command-line switch to enable debugging Python is a PITA. It may not even be possible. With Active Scripting, for example, the host may not know it is even using Python at all! It all seems to push the problem down to those who can least afford to manage it, and least equipped to understand how it needs to be tweaked for their particular situation. However, I could agree that the debugger itself trigger debuggable behaviour. I just dont believe this should be a startup-only switch. sys.set_debugging(1) would work for me. OTOH, a debugger always announces itself by calling sys.settrace(), so this is really all that is necessary (and debugging can be disabled whenever sys.settrace(None) is called, and no existing frames have their tracer set.) Mark. From pf at artcom-gmbh.de Mon Jul 31 09:43:55 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Mon, 31 Jul 2000 09:43:55 +0200 (MEST) Subject: automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration) In-Reply-To: from Tim Peters at "Jul 30, 2000 7:26: 0 pm" Message-ID: Good morning Tim, Tim Peters: > Peter, what would you say if someone told you your Python programs would > run, oh, 30% faster, but in return for that you could no longer rely on > refcount semantics? Personally I wouldn't go for that trade. Waiting three or four more months and buying new hardware usually gives the same speedup anyway. What really matters is programmer time, not program run time. At least most of the time. When I started programming (with punch cards 25 yrs ago) the situation was clearly different. But today? Computing power is so incredible cheap today... > What do you think *most* people would say? [...] Hard to say. But I believe people looking at Python are more interested in programmer productivity than in highly optimized performance. And don't having to worry about tedious and clumsy cleanup actions is an undeniable win in programmer productivity. This win is twofold: 1. you don't have to check, whether the objects provide a close() or a destroy() method. 2. you don't have to invent silly names for these otherwise anonymous objects. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From nowonder at nowonder.de Mon Jul 31 12:07:46 2000 From: nowonder at nowonder.de (Peter Schneider-Kamp) Date: Mon, 31 Jul 2000 10:07:46 +0000 Subject: [Python-Dev] TCP socket timeout module? Message-ID: <39854FF2.EC017E60@nowonder.de> How hard would it be to implement a functionality like this in socketmodule.c? Is such a functionality desirable? guess-this-has-been-discussed-a-thousand-times-before-ly y'rs Peter -------- Original Message -------- Subject: [ANN] TCP socket timeout module --> timeoutsocket.py Date: Sun, 30 Jul 2000 20:54:23 -0400 From: "Timothy O'Malley" Organization: Posted via Supernews, http://www.supernews.com To: python-list at python.org Newsgroups: comp.lang.python Numerous times I have seen people request a solution for TCP socket timeouts in conjunction with urllib. Recently, I found myself in the same boat. I wrote a server that would connect to skytel.com and send automated pages. Periodically, the send thread in the server would hang for a long(!) time. Yup -- I was bit by a two hour timeout built into tcp sockets. Thus, I wrote timeoutsocket.py With timeoutsocket.py, you can force *all* TCP sockets to have a timeout. And, this is all accomplished without interfering with the standard python library! Here's how to put a 20 second timeout on all TCP sockets for urllib: import timeoutsock import urllib timeoutsocket.setDefaultSocketTimeout(20) Just like that, any TCP connection made by urllib will have a 20 second timeout. If a connect(), read(), or write() blocks for more than 20 seconds, then a socket.Timeout error will be raised. Want to see how to use this in ftplib? import ftplib import timeoutsocket timeoutsocket.setDefaultSocketTimeout(20) Wasn't that easy! The timeoutsocket.py module acts as a shim on top of the standard socket module. Whenever a TCP socket is requested, an instance of TimeoutSocket is returned. This wrapper class adds timeout support to the standard TCP socket. Where can you get this marvel of modern engineering? http://www.timo-tasi.org/python/timeoutsocket.py And it will very soon be found on the Vaults of Parnassus. Good Luck! -- -- happy daze -tim O -- http://www.python.org/mailman/listinfo/python-list From mal at lemburg.com Mon Jul 31 10:13:46 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 10:13:46 +0200 Subject: [Python-Dev] SET_LINENO and python options References: <200007300239.EAA21825@python.inrialpes.fr> Message-ID: <3985353A.A8E0406C@lemburg.com> [Vladimir on removing SET_LINENO opcodes per default] Is there any reason why we can't just use traceback.tb_lineno() + maybe an equivalent C function instead of adding useless opcodes into the byte code stream ? The line number information is already stored in the co_lnotab table, so SET_LINENO is redundant in some respects. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 31 10:19:01 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 10:19:01 +0200 Subject: [Python-Dev] SPAM from "The Western Web Newsletter" References: <20000731020103.2B91B1CD4C@dinsdale.python.org> Message-ID: <39853675.96EA5731@lemburg.com> Could someone please add a filter to the Mailman lists to prevent these horse back advocates ?! Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Stefan.Debler at bitways.de Mon Jul 31 10:30:53 2000 From: Stefan.Debler at bitways.de (S.Debler (Bitways)) Date: Mon, 31 Jul 2000 10:30:53 +0200 Subject: [Python-Dev] Urgent inquiry for Paper bags! Message-ID: <200007310830.KAA04569@mcqueen.wolfsburg.de> Urgent inquiry for Paper bags, Dear Sirs, We are an international trading company, mainly serving the European industry. The Bitways Group purchases globally on own account and then resells the products to various clients. Our aim is to source globally and to offer our clients the best prices worldwide. From tim_one at email.msn.com Mon Jul 31 10:42:50 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 31 Jul 2000 04:42:50 -0400 Subject: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...) In-Reply-To: <14724.22554.818853.722906@bitdiddle.concentric.net> Message-ID: [Jeremy Hylton, with an excellent writeup of what he's found out about his test_fork2.py test] It's a baffler! AFAIK, nobody yet has thought of a way that a fork can screw up the state of the locks in the *parent* process (it must be easy to see how they can get screwed up in a child, because two of us already did ). But your hangs appear to be in parents, as the gdb stacktrace shows that a parent process is (presumably) hanging while trying to reacquire the global lock in the expansion of the Py_END_ALLOW_THREADS macro right after the pid = wait(&status); in posix_wait returns (#2 is from the macro expansion): #0 pthread_cond_wait (cond=0x80f297c, mutex=0x80f2988) at queue.h:25 #1 0x806fee3 in PyThread_acquire_lock (lock=0x80f2978, waitflag=1) at ../../Python/thread_pthread.h:311 #2 0x8054ec1 in PyEval_RestoreThread (tstate=0x80fb2f0) at ../../Python/ceval.c:171 #3 0x80c1242 in posix_wait (self=0x0, args=0x80f1cac) at ../../Modules/posixmodule.c:2849 However, the stacktrace shows that the parent in question is executing pthread_cond_wait, and this is the worst implementation of pthread_cond_wait in existence if it's using a busy loop to wait for the condition variable to get signaled! If this process keeps accumulating cycles, it either *is* the worst implementation in existence, or the process isn't actually hung and you just happened to capture the stack at a misleading time. The debug output may be misleading too: > ... > [lots of stuff omitted] Ouch -- wish you hadn't. Debug output is likely to come out-of-order, so without *all* of it we can't see exactly how far out of balance the acquire and release calls got. > 2051 2127 > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_release_lock(0x80f6498) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > PyThread_release_lock(0x80f6498) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > PyThread_release_lock(0x80f6498) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > 1024 2130 > PyThread_release_lock(0x80f6498) called > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > PyThread_acquire_lock(0x80f6498, 1) called > PyThread_acquire_lock(0x80f6498, 1) -> 1 > PyThread_release_lock(0x80f6498) called > [blocks] It's probably *not* blocking on the release: In this bunch of output, there are 7 calls to acquire, 5 calls to release, and 5 returns from acquire. That the # of release calls == the # of acquire returns suggests this output is "good enough", and if so that leaves two acquire calls waiting forever. Don't know what to do now. Obvious suggestions include putting many prints into test_fork2 so we get a better idea of what's happening, or going back to Trent's print-filled variant of test_fork1 (which I still think is an easier one to study, as it forks only once instead of unboundedly often). BTW, in *my* day, the answer to the question "what happens to a threaded program at a fork?" was to walk away laughing -- and not sure the reality of that has actually changed, regardless of how many more words they may have added to the pthreads docs in the meantime <0.7 wink>. silly-humans-ly y'rs - tim From mal at lemburg.com Mon Jul 31 10:48:51 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 10:48:51 +0200 Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) References: <200007281404.QAA06091@python.inrialpes.fr> <200007281505.KAA04865@cj20424-a.reston1.va.home.com> <39819FED.41C11063@lemburg.com> <14721.64041.139313.716754@anthem.concentric.net> Message-ID: <39853D73.ACBB54CA@lemburg.com> "Barry A. Warsaw" wrote: > > >>>>> "M" == M writes: > > M> These stats were created using an instrumented Python > M> interpreter running real applications (and recording all > M> executed opcodes to a file), so they can be considered close > M> enough to what Python typically does in its inner loop. > > M> If you need help, I can dig up those old tools and patches... > > If you can update them for the current CVS, I'd suggest uploading them > to SF. I'd then be willing to run Mailman for a while on an > instrumented Python to see what it does. I'll see what I can do... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 31 11:12:48 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 11:12:48 +0200 Subject: [Python-Dev] os.kill() on Win32 ? (Fork on Win32) References: <013901bff821$55dd02e0$8119fea9@neil> <39815E94.462F65EF@lemburg.com> <20000728101015.A6542@ActiveState.com> <3981CD20.BD53BFF0@lemburg.com> <008d01bff8c2$5c99f240$f2a6b5d4@hagrid> Message-ID: <39854310.4944366@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > BTW, (pardon my ignorance) what is the most portable way to > > do the equivalent of a os.system("cmd &") as native OS > > API call ? [On Unix, "cmd &" starts a new process which runs > > in the background and detached from the calling process.] > > > > I've looked at .execve and .spawnve, but they both replace > > the current process. > > on windows, spawn(P_NOWAIT) does what you want. here's > an example from the eff-bot guide: > > # > # os-spawn-example-2.py > > import os > import string > > def run(program, *args, **kw): > # find executable > mode = kw.get("mode", os.P_WAIT) > for path in string.split(os.environ["PATH"], os.pathsep): > file = os.path.join(path, program) + ".exe" > try: > return os.spawnv(mode, file, (file,) + args) > except os.error: > pass > raise os.error, "cannot find executable" > > run("python", "hello.py", mode=os.P_NOWAIT) Cool, so os.spawnve(os.P_NOWAIT, ...) looks like a portable alternative to os.fork() for the case where you do not rely on the parent process resources being available in the child process. Next, I'll have to find out how to kill a process given its process ID under Windows... wouldn't it be possible to write an emulation of os.kill() for Win32 platforms too ? (there's a SysInfo tool for Windows which says that OpenProcess(PROCESS_TERMINATE, FALSE, pid); will do the trick -- not sure if that works as expected though). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Mon Jul 31 11:16:56 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 11:16:56 +0200 Subject: [Python-Dev] UTF-16 code point comparison References: <397f38e5.12750954@smtp.worldonline.dk> <397FF146.2D307063@lemburg.com> <398065f3.6724599@smtp.worldonline.dk> <398099F1.B6B1D281@lemburg.com> <39811268.1131747@smtp.worldonline.dk> <200007281226.HAA04140@cj20424-a.reston1.va.home.com> Message-ID: <39854408.5D496075@lemburg.com> Guido van Rossum wrote: > > > Predicting the future can be difficult, but here is my take: > > javasoft will never change the way String.compareTo works. > > String.compareTo is documented as: > > """ > > Compares two strings lexicographically. The comparison is based on > > the Unicode value of each character in the strings. ... > > """ > > (Noting that their definition of "character" is probably "a 16-bit > value of type char", and has only fleeting resemblance to what is or > is not defined as a character by the Unicode standard.) > > > Instead they will mark it as a very naive string comparison and suggest > > users to use the Collator classes for anything but the simplest cases. > > Without having digested the entire discussion, this sounds like a good > solution for Python too. The "==" operator should compare strings > based on a simple-minded representation-oriented definition, and all > the other stuff gets pushed into separate methods or classes. This would probably be the best way to go: we'll need collation routines sooner or later anyway. Bill's "true UCS-4" compare could then become part of that lib. Should I #if 0 the current implementation of the UCS-4 compare in CVS ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From MarkH at ActiveState.com Mon Jul 31 11:47:14 2000 From: MarkH at ActiveState.com (Mark Hammond) Date: Mon, 31 Jul 2000 19:47:14 +1000 Subject: [Python-Dev] os.kill() on Win32 ? (Fork on Win32) In-Reply-To: <39854310.4944366@lemburg.com> Message-ID: > Next, I'll have to find out how to kill a process given > its process ID under Windows... wouldn't it be possible to hprocess = OpenProcess( accessFlags, bInherit, pid ); TerminateProcess(hprocess, exitCode); The hard bit on Win32 is finding the PID when you only have the process name (for example) but it sounds like you dont have that specific problem... Mark. From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 12:16:17 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 12:16:17 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <3985353A.A8E0406C@lemburg.com> from "M.-A. Lemburg" at Jul 31, 2000 10:13:46 AM Message-ID: <200007311016.MAA12484@python.inrialpes.fr> M.-A. Lemburg wrote: > > [Vladimir on removing SET_LINENO opcodes per default] > > Is there any reason why we can't just use traceback.tb_lineno() > + maybe an equivalent C function instead of adding useless opcodes > into the byte code stream ? > Yes - you seem to have missed half the story . How would you generate callbacks (fire "line" events) from within the mainloop when a sys.settrace function is set and the PC starts executing opcodes corresponding to a new line number? Note that we don't "add" any new opcodes, and in the scheme I presented CALL_TRACE is also internal to eval_code2(), like the copy of co_code, but I eventually decided to show it in opcodes.h. SET_LINENO is not generated anymore and is reduced to a NOOP in ceval, CALL_TRACE is introduced only for the callbacks. For b/w compatibility (of .pyc files) I think we can't just "get rid" of it. And now that the game is over with finding the solution to f.f_lineno's access, the proposal about "python -g" which preserves SET_LINENO makes sense (at least for visualizing SET_LINENO in a disassembly). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Mon Jul 31 12:21:09 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 12:21:09 +0200 Subject: [Python-Dev] os.kill() on Win32 ? (Fork on Win32) References: Message-ID: <39855315.4E14C432@lemburg.com> Mark Hammond wrote: > > > Next, I'll have to find out how to kill a process given > > its process ID under Windows... wouldn't it be possible to > > hprocess = OpenProcess( accessFlags, bInherit, pid ); > TerminateProcess(hprocess, exitCode); Would it make sense to add something like this to posixmodule.c as emulation of the Unix kill() on Win32 ? Here's the manpage for reference: SYNOPSIS #include #include int kill(pid_t pid, int sig); DESCRIPTION The kill system call can be used to send any signal to any process group or process. If pid is positive, then signal sig is sent to pid. If pid equals 0, then sig is sent to every process in the process group of the current process. If pid equals -1, then sig is sent to every process except for the first one, from higher numbers in the process table to lower. If pid is less than -1, then sig is sent to every process in the process group -pid. If sig is 0, then no signal is sent, but error checking is still performed. RETURN VALUE On success, zero is returned. On error, -1 is returned, and errno is set appropriately. > The hard bit on Win32 is finding the PID when you only have the process > name (for example) but it sounds like you dont have that specific > problem... Not really, since my server manages its own set of processes and knows the different PIDs. It keeps track of what the processes currently do and terminates the ones that act in unexpected ways, e.g. due to programming errors. On Unix this results in a high availability bug tolerant server application which allows running user written code. My future goal would be porting it to Win2k, provided the needed APIs are available (or can be emulated in some way). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas at xs4all.net Mon Jul 31 12:35:36 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 31 Jul 2000 12:35:36 +0200 Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <200007311016.MAA12484@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Mon, Jul 31, 2000 at 12:16:17PM +0200 References: <3985353A.A8E0406C@lemburg.com> <200007311016.MAA12484@python.inrialpes.fr> Message-ID: <20000731123536.K266@xs4all.nl> On Mon, Jul 31, 2000 at 12:16:17PM +0200, Vladimir Marangozov wrote: > SET_LINENO is not generated anymore and is reduced to a NOOP in ceval, > CALL_TRACE is introduced only for the callbacks. For b/w compatibility > (of .pyc files) I think we can't just "get rid" of it. Why not, except for the possible desirability of a -g flag that does use it? If you up the bytecode magic, which several other things in the pipeline are going to do anyway (augmented assignment, range literals, list comprehensions) old bytecode will be recompiled, and new bytecode will not be used on old interpreters. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Mon Jul 31 12:35:38 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 31 Jul 2000 12:35:38 +0200 Subject: [Python-Dev] SET_LINENO and python options References: <200007311016.MAA12484@python.inrialpes.fr> Message-ID: <3985567A.2E4FDC79@lemburg.com> Vladimir Marangozov wrote: > > M.-A. Lemburg wrote: > > > > [Vladimir on removing SET_LINENO opcodes per default] > > > > Is there any reason why we can't just use traceback.tb_lineno() > > + maybe an equivalent C function instead of adding useless opcodes > > into the byte code stream ? > > > > Yes - you seem to have missed half the story . How would you > generate callbacks (fire "line" events) from within the mainloop > when a sys.settrace function is set and the PC starts executing > opcodes corresponding to a new line number? Good question :-) You're right: I forgot about the trace function call in the SET_LINENO opcode. > Note that we don't "add" any new opcodes, and in the scheme I presented > CALL_TRACE is also internal to eval_code2(), like the copy of co_code, > but I eventually decided to show it in opcodes.h. With "add" I meant the SET_LINENO opcode... remove the "useless" from my comment above ;-) > SET_LINENO is not generated anymore and is reduced to a NOOP in ceval, > CALL_TRACE is introduced only for the callbacks. For b/w compatibility > (of .pyc files) I think we can't just "get rid" of it. > > And now that the game is over with finding the solution to f.f_lineno's > access, the proposal about "python -g" which preserves SET_LINENO makes > sense (at least for visualizing SET_LINENO in a disassembly). BTW, we already have "python -d" which sets the debugging flag. You could simply use that flag for generating the SET_LINENO opcodes. Still, I think that the SET_LINENO issue is not really all that important: we have "python -O" which removes the opcodes. Perhaps moving the opcode a bit further down in the big switch would help CPU caches for production code (running under "python -O")... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pf at artcom-gmbh.de Mon Jul 31 12:45:53 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Mon, 31 Jul 2000 12:45:53 +0200 (MEST) Subject: doctest.py and testing frameworks (was Re: [Python-Dev] Fire, may I present accellerant. Accellerant, thi...) In-Reply-To: <20000730215059.OSQC24904.mail.rdc1.wa.home.com@finin> from Mitchell Morris at "Jul 30, 2000 2:51:30 pm" Message-ID: Hi, Mitchell Morris wrote to me: > Peter: > > Thanks for reading my post, and I especially appreciate your taking > the time and effort to respond. I also appreciate that you didn't take > me to task for using "it's" instead of "its" as the possessive form. > (I've been completely reeducated now, I assure you). As I'm not > currently a subscriber to python-dev, I don't know if this should > have been replied to the list or directly to you, so I'm sending it to > you only. If you feel it appropriate, please redistribute it as you > wish. [...I wrote to Mitchell:...] > > I've used doctest in my own code and found the idea to integrate > > test cases as sequences of calling code and expected result tuples > > as documentation (exmaples of use) into the doc string of modules, > > classes and methods very appealing. > > > > However this promising approach needs further work: Especially > > GUI parts can't be tested this way and in larger contexts, it > > is indeed very tedious to place *all* test code into doc strings. > > Often you need to prepare a defined starting point for the tests > > of several methods. It is not easy to decide, where to put this. > > I used doctest rather extensively a little while ago, but it was only > the vanilla variant originally posted by Tim. I thought it was really an > excellent work, but ran into similar stumbling blocks. The largest > issue for me was the aggregation of several modules worth of tests > into larger chunks, but I now know (from what I had to build to > complete the test plan I was working with) that I would very shortly > have run into the problems of replicating the test environment: > preparing input files/directories/databases, creating all the > supplementary bits and pieces, etc ad nauseam. > > A secondary issue which none of these tools address yet, but I feel > will be significant eventually, is the explicit naming of inter-test > dependence. If my class B tests require using some functionality > from class A, I would want the A tests to succeed before trying the > B tests at all (assuming I'm going to run both A and B in a single > iteration). I suspect, then, that one of these candidates will require > additional work to be our complete solution; I want to make sure > that I/we are working on the best candidate possible before > spending the effort. > > > > > again, additional effort could obviously provide the missing > > > functionality. On the other hand, doctest.py isn't currently > > > part of the standard distribution. > > > > Yes. :-( > > This, I feel, represents a significant problem. We should have a > testing framework as part of the core distribution. I agree. > We have HTML > tokenizing, mail sending, RFC822 parsing, /bin/sh-like lexing, etc > etc but don't feel that providing test support to our community of > developer is appropriate? Bizarre. Perhaps even more bizarre is > that there is a non-trivial regrtest.py that is part of the distribution, > but it's hidden away and not documented. Perhaps because no one volunteered to write documentation for it. Writing docs is an tedious task especially if you are no native english speaker. > I think we are not > providing all the service to the Python community that we could > and should. You are welcome to do something about this. > One of the strengths of Python, in my experience, has been the > ease with which code is written. This makes it much easier to > convince yourself and others to refactor mercilessly; the kinds of > cruft that grow on C++ solutions are rarely seen in Python code > because we can repartition and rewrite our work much more easily. > Providing a standard means to verify functionality before refactoring > makes it much safer to proceed, since we can "prove" (for a very > loose definition of "prove") that we haven't broken anything that > anybody else cares about. I think this is a direction we should > encourage, both through example and explicit > direction/documentation. > > > > I attach my version of 'doctest' to this email. Do what you want with it. > > Currently I favour 'doctest' over 'pyunit'. > > If you don't mind, could you elaborate why you prefer doctest, or at > least what you find unpleasant about pyunit? I would like to include > this in the document for future reference, and you may even > convince me to change my vote for doctest.py instead. I must admit that I didn't had a look at PyUnit since January. I've just downloaded pyunit-1.2.0 and had a closer look at it. Nevertheless it is very hard to beat the elegance of Tim Peters approach to cut'n'paste test cases from the interpreter prompt. Although you usually get 2 lines for each test case, building the test cases is much easier in the first place. May be both approaches to unit testing can be integrated somehow? Steal the concept of 'fixtures' from PyUnit and steal the idea to define simple test cases in the doc strings from 'doctest'. It shouldn't be that hard to add a semiautomatic import hierarchy traversal tool. Regards, Peter From gvwilson at nevex.com Mon Jul 31 14:54:58 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Mon, 31 Jul 2000 08:54:58 -0400 (EDT) Subject: [Python-Dev] Internet Groupware for Scientific Collaboration Message-ID: [Not strictly related to Python development, but likely to be of interest to many readers of this list.] Jon Udell (architect of www.byte.com and O'Reilly's new Safari site, author of "Practical Internet Groupware", a Python fan) has prepared a report for Software Carpentry called "Internet Groupware for Scientific Collaboration". It is on-line at: http://www.software-carpentry.com/Groupware/report.html Hope you enjoy it, Greg Wilson From fdrake at beopen.com Mon Jul 31 17:01:14 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 31 Jul 2000 11:01:14 -0400 (EDT) Subject: [Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment) In-Reply-To: References: <200007310234.EAA11379@python.inrialpes.fr> Message-ID: <14725.38074.60946.579456@cj42289-a.reston1.va.home.com> Ka-Ping Yee writes: > (or IDLE et al.) can just start with > > #!/usr/bin/env python -g > > and we could then drop SET_LINENO by default. Am i missing something? This #! isn't portable; the program is only guaranteed to get one parameter from the #! line ("python" in this example). Some platforms are more forgiving and just use the rest of the command line (or a maximum of 32 characters), but that means you lose the "-g" on too many platforms. The other concerns that have been brought up are fairly important as well. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Vladimir.Marangozov at inrialpes.fr Mon Jul 31 17:37:16 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 31 Jul 2000 17:37:16 +0200 (CEST) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: <3985567A.2E4FDC79@lemburg.com> from "M.-A. Lemburg" at Jul 31, 2000 12:35:38 PM Message-ID: <200007311537.RAA22542@python.inrialpes.fr> M.-A. Lemburg wrote: > > BTW, we already have "python -d" which sets the debugging > flag. You could simply use that flag for generating the SET_LINENO > opcodes. You're right. In case someone is not on the patches list and wants to test this, here's the log message of the latest patch update: Date: 2000-Jul-31 07:57 By: marangoz Comment: Another rewrite, making this whole strategy b/w compatible according to the 1st incompatibility point a) described in: http://www.python.org/pipermail/p ython-dev/2000-July/014364.html Changes: 1. f.f_lineno is computed and updated on f_lineno attribute requests for f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated on *all* attribute accesses (in LOAD_ATTR in the main loop). 2. The standard setup does not generate SET_LINENO, but uses co_lnotab for computing the source line number (e.g. tracebacks) This is equivalent to the actual "python -O". 3. With "python -d", we fall back to the current version of the interpreter (with SET_LINENO) thus making it easy to test whether this patch fully replaces SET_LINENO's behavior. (modulo f->f_lineno accesses from legacy C code, but this is insane). IMO, this version already worths the pain to be truly tested and improved. One improvement is to define a nicer public C API for breakpoints: - PyCode_SetBreakPointAtLine(line) - PyCode_SetBreakPointAtAddr(addr) or similar, which would install a CALL_TRACE opcode in the appropriate location of the copy of co_code. Another idea is to avoid duplicating the entire co_code just for storing the CALL_TRACE opcodes. We can store them in the original and keep a table of breakpoints. Setting the breakpoints would occur whenever the sys.settrace hook is set. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470 -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From jeremy at beopen.com Mon Jul 31 18:48:32 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 31 Jul 2000 12:48:32 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.15,1.16 In-Reply-To: <200007311638.JAA27412@slayer.i.sourceforge.net> References: <200007311638.JAA27412@slayer.i.sourceforge.net> Message-ID: <14725.44512.46379.190368@bitdiddle.concentric.net> Barry, A couple of suggestions on assigning PEP numbers: Let's require at least an abstract before we assign a number. We've got a bunch of PEPs that have been assigned and never touched; all they've got is a title and a name. If we have an abstract, non-experts and non-channelers have a better chance of figuring out what the PEP is. We might also think about a deadline or time limit. If a PEP has no activity for N days (90?), it is automatically changed to status deferred. After it has been deferred, we can assign it to a new author. There's not much point in making a big list of topics that people would like to write about some day if they get the time. It looks like we now have seven PEPs with only a name and title. Jeremy From bwarsaw at beopen.com Mon Jul 31 18:56:03 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Mon, 31 Jul 2000 12:56:03 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.15,1.16 References: <200007311638.JAA27412@slayer.i.sourceforge.net> <14725.44512.46379.190368@bitdiddle.concentric.net> Message-ID: <14725.44963.961828.923053@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> A couple of suggestions on assigning PEP numbers: JH> Let's require at least an abstract before we assign a number. JH> We've got a bunch of PEPs that have been assigned and never JH> touched; all they've got is a title and a name. If we have an JH> abstract, non-experts and non-channelers have a better chance JH> of figuring out what the PEP is. JH> We might also think about a deadline or time limit. If a PEP JH> has no activity for N days (90?), it is automatically changed JH> to status deferred. After it has been deferred, we can assign JH> it to a new author. JH> There's not much point in making a big list of topics that JH> people would like to write about some day if they get the JH> time. It looks like we now have seven PEPs with only a name JH> and title. Strongly agree, and will follow these guidelines in the future. Can you add these to PEP 1? -Barry From jeremy at beopen.com Mon Jul 31 19:31:36 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 31 Jul 2000 13:31:36 -0400 (EDT) Subject: [Python-Dev] SF bug tracker Message-ID: <14725.47096.914241.264282@bitdiddle.concentric.net> Which interface do you like better: the SourceForge bug tracker or Jitterbug? I am leaning towards moving the bug database from Jitterbug at python.org to SF. The advantages of moving to SF are: - bugs, patches, and CVS all managed by the same service - bugs can be assigned to specific people for resolution - cleaner interface for searching bugs - bugs can be assigned a priority The primary disadvantage of SF is email support. Jitterbug can receive comments about a bug via email and add them to its database. The SF bug tracker does not. It works like the patch manager, requiring you to use the Web interface to add more information. The SF bug tracker will send an email message every time a bug entry is updated, but that's it. Please let me know what you think. Jeremy From guido at beopen.com Mon Jul 31 20:43:05 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 31 Jul 2000 13:43:05 -0500 Subject: [Python-Dev] SF bug tracker In-Reply-To: Your message of "Mon, 31 Jul 2000 13:31:36 -0400." <14725.47096.914241.264282@bitdiddle.concentric.net> References: <14725.47096.914241.264282@bitdiddle.concentric.net> Message-ID: <200007311843.NAA22953@cj20424-a.reston1.va.home.com> > Which interface do you like better: the SourceForge bug tracker or > Jitterbug? I am leaning towards moving the bug database from > Jitterbug at python.org to SF. > > The advantages of moving to SF are: > > - bugs, patches, and CVS all managed by the same service > - bugs can be assigned to specific people for resolution > - cleaner interface for searching bugs > - bugs can be assigned a priority > > The primary disadvantage of SF is email support. Jitterbug can > receive comments about a bug via email and add them to its database. > The SF bug tracker does not. It works like the patch manager, > requiring you to use the Web interface to add more information. > > The SF bug tracker will send an email message every time a bug entry > is updated, but that's it. I would like to add that as far as I can tell we've only received a very small number of Jitterbug bug reports via email. In fact, the only one I can find in my email archives that originated via email was PR#110, which was in fact a followup! (We got plenty of followups via email, but that was because with Jitterbug it was actually *easier* to use email than the web I/F.) (Of course, this is not counting the bugs sent directly to guido at python.org -- these are in the hundreds.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From klm at digicool.com Mon Jul 31 20:47:09 2000 From: klm at digicool.com (Ken Manheimer) Date: Mon, 31 Jul 2000 14:47:09 -0400 (EDT) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: Message-ID: On Sun, 30 Jul 2000, Ka-Ping Yee wrote: > On Sat, 29 Jul 2000, Ken Manheimer wrote: > > On Fri, 28 Jul 2000 Vladimir.Marangozov at inrialpes.fr wrote: > > > 1) python - code without SET_LINENO > > > 2) python -g - code for debugging, with SET_LINENO > > > 3) python -O - code without doc-strings. > [...] > > I would be firmly -1 on this proposal. > > Funny -- i was just about to throw in a hearty +1. > > > I see the ability to debug at whim, even when you didn't expect having to > > do so, as being a major win, part of the incremental development process. > > But you *can't* debug at whim, right? You have to have started the > debugger, so it can hook sys.settrace, before you run your program. > If you have to start the debugger anyway, then you can surely say -g. Nope. More often than not, if i'm developing something substantial, then my interpreter sessions will involve developing context, running something then having it fail, doing a pdb.pm() post mortem, and then doing a second run with pdb.run(). My life would be worse if i happened to forget to start python with the '-g' in the first place. This scenario happens even when i don't intend to be "developing", ie when i encounter bugs in random code i'm using. As it stands, i (and anyone) have recourse to poke around at will. This is the kind of thing that makes an interpreted language valuable to me in the first place, and why i'm willing to trade of a lot more than a few percent performance. (This all may be moot if the linenotab-based alternative pans out - then everyone can be happy.) > Let's suppose: > > 1. -g is turned on by default in interactive mode, since we > don't know if you're going to feel like tracing today. This would address my above concerns. > 2. Programs (like debuggers and IDEs) that know they're going > to use sys.settrace, or which contain embedded interactive > interpreters, begin with > > #!/usr/bin/env python -g > > 3. Other programs begin with the usual > > #!/usr/bin/env python > > Given this -- are there any debugging opportunities you're missing > out on? I don't see any... One important one would be connecting with a long-running process, eg something running under medusa via the medusa monitor client. Unfortunately, it looks like the monitor client currently doesn't use a pty, or uses it wrong, or something, so the debugger doesn't work right anyway - which has been a royal pain on many occasions! I could see it being worthwhile to run the server process in an economy mode, if the economy were big. For some definition of big, of course.-) Ken klm at digicool.com From thomas at xs4all.net Mon Jul 31 21:07:25 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 31 Jul 2000 21:07:25 +0200 Subject: [Python-Dev] SF bug tracker In-Reply-To: <14725.47096.914241.264282@bitdiddle.concentric.net>; from jeremy@beopen.com on Mon, Jul 31, 2000 at 01:31:36PM -0400 References: <14725.47096.914241.264282@bitdiddle.concentric.net> Message-ID: <20000731210725.N266@xs4all.nl> On Mon, Jul 31, 2000 at 01:31:36PM -0400, Jeremy Hylton wrote: > Which interface do you like better: the SourceForge bug tracker or > Jitterbug? I am leaning towards moving the bug database from > Jitterbug at python.org to SF. Without having too much experience with Jitterbug, and only the 'read' side at that, and slightly more experience, also only on the 'read' side, with the SF buglist, I can safely say I prefer the SF bug tracker. Jitterbug is totally alien to me, the different catagories boggle me, the overviews of each catagory boggle me, and I'm not sure if I've seen everything even after I browsed through each list. But as said, I have only little experience with Jitterbug. The SF buglist might not make it too clear from the first overview in what catagory a bug belongs, but it's easily selectable, and it's very obvious which bugs are open and how important they are. And it gives people more feedback on sourceforge, in case they don't read their mail ;-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bckfnn at worldonline.dk Mon Jul 31 21:50:58 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Mon, 31 Jul 2000 19:50:58 GMT Subject: [Python-Dev] SF bug tracker In-Reply-To: <200007311843.NAA22953@cj20424-a.reston1.va.home.com> References: <14725.47096.914241.264282@bitdiddle.concentric.net> <200007311843.NAA22953@cj20424-a.reston1.va.home.com> Message-ID: <3985d87b.12451444@smtp.worldonline.dk> [Guido van Rossum] >I would like to add that as far as I can tell we've only received a >very small number of Jitterbug bug reports via email. In that case you did not include the counts from JPythons jitterbug. Almost everything I have submitted there is through email. But do not take that as an endorsements of jitterbug. If the existing data can be moved then I'm +1 on doing so. regards, finn From trentm at ActiveState.com Mon Jul 31 22:41:26 2000 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 31 Jul 2000 13:41:26 -0700 Subject: [Python-Dev] test turds? In-Reply-To: ; from moshez@math.huji.ac.il on Sat, Jul 29, 2000 at 01:17:14PM +0300 References: Message-ID: <20000731134126.A1683@ActiveState.com> On Sat, Jul 29, 2000 at 01:17:14PM +0300, Moshe Zadka wrote: > Hi! > > Recently I patched a bug in whichdb. Following Tim's advice "each bug we > find is a bug in the regression testing", I decided to write a test case > for whichdb. However, the problem is that I'm not sure where I can create > files, which must not be leftovers from the test suite. Does anyone know test_support.TESTFN is a test filename that is intended to be used by Python test scripts. Currently it is just the file '@test' in the current directory. A better mechanism might be to use the tempfile.mktemp() module and function. > of a test which creates files, and how it deals with them? [.../dist/src/Lib/test]$ grep -l 'open\b' test_*.py test_array.py test_b1.py test_b2.py test_binhex.py test_bsddb.py test_cd.py test_cpickle.py test_dbm.py test_dl.py test_exceptions.py test_fcntl.py test_gdbm.py test_gl.py test_linuxaudiodev.py test_mmap.py test_pkg.py test_popen2.py test_pty.py test_rgbimg.py test_select.py test_sunaudiodev.py test_tokenize.py test_winreg.py test_winreg2.py test_zipfile.py test_zlib.py Trent From jack at oratrix.nl Mon Jul 31 23:01:00 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 31 Jul 2000 23:01:00 +0200 Subject: [Python-Dev] test turds? In-Reply-To: Message by Trent Mick , Mon, 31 Jul 2000 13:41:26 -0700 , <20000731134126.A1683@ActiveState.com> Message-ID: <20000731210105.6F6ADE266F@oratrix.oratrix.nl> Recently, Trent Mick said: > test_support.TESTFN is a test filename that is intended to be used by Python > test scripts. Currently it is just the file '@test' in the current directory. > A better mechanism might be to use the tempfile.mktemp() module and function. test_dbm.py (and possibly a few others) use /tmp/delete_me. This leaves a nasty turd on the Mac if the test fails. (Nasty because a file called /tmp/delete_me in the Python home directory confuses the hell out of cvs:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From skip at mojam.com Mon Jul 31 23:54:59 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 31 Jul 2000 16:54:59 -0500 (CDT) Subject: [Python-Dev] SET_LINENO and python options In-Reply-To: References: Message-ID: <14725.62899.678602.179470@beluga.mojam.com> Tim> The most interesting dropped project "in the middle" was Skip Tim> Montanaro's Rattlesnake, which aimed to change the VM from a stack Tim> to a register model. 'e's not dead, just restin'... ;-) Skip From jack at oratrix.nl Mon Jul 31 23:59:34 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 31 Jul 2000 23:59:34 +0200 Subject: [Python-Dev] test_re fails with re==pre Message-ID: <20000731215940.28A11E266F@oratrix.oratrix.nl> Test_re now works fine if re is sre, but it still fails if re is pre. Is this an artifact of the test harness or is there still some sort of incompatibility lurking in there? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++